Follow-up from "Add filter bar focus shortcut"

Context

The following discussion from !199329 (merged) should be addressed:

• @ms.mondrian started a discussion: (+9 comments)

  question (non-blocking): at first glance, it was not very clear to me what we're trying to communicate with (f). but maybe this is an existing pattern from other placeholder text? cc: @alyssatrinh

  also, i wonder if this could cause problems with translation. looping @opysaryuk in as i don't even know what to search to find the answer of this question. but i wonder would there be a language where, chaining (f) doesn't make sense?

• @opysaryuk

@ms.mondrian , thanks for the ping 🙇 Super interesting! 💡

There are three potential problems with localizability:

The (f) is dynamically appended to indicate the keyboard shortcut. I assume f is used to tell the user that we talk about a filter. // The closest i18n guideline we have in our i18n docs is about inserting text into other text dynamically using variables: https://docs.gitlab.com/development/i18n/externalization/#using-variables-to-insert-text-dynamically, but this MR is a slightly different edge case, i.e. not variables but logic (cc @mpehkonen worth documenting? WDYT?) There is a space being inserted into the text value. That space comes from the literal space character between {base} and ({this.filterSearchShortcutKey}) in the template string, here: !199329 (diffs). Also, opening and closing parentheses ( ) around f (which also gets int the text value as a key binding) are hardcoded in the same template string. // Regarding hardcoding characters (or spaces, punctuation, etc.), we do not have guidelines our i18n docs, but closest I saw is this doc by Mozilla: https://mozilla-l10n.github.io/documentation/localization/dev_best_practices.html#dont-hardcode-characters (cc @mpehkonen again: the Mozilla link had once been briefly mentioned in this issue: Localizability guidelines for product UI labels (gitlab-com/localization/localization-team#29). Worth documenting as well? wdyt?) (f) as a shortcut may or may not make sense in other languages, but if it works regardless of the user's languages preferences, this #3 is not a problem .

@JoFletcher , does the shortcut work regardless of what non-English language the user has selected in their Profile -> Preferences -> Localization ?

These problems are subtle, but when a user notices especially in ideographic languages like JA where they may not expect a space, it could be slight UX disruption

• @ms.mondrian

thanks @opysaryuk for the information. i learnt a lot like always. while we wait for @mpehkonen 's feedback, i got curious and checked on

does the shortcut work regardless of what non-English language the user has selected in their Profile -> Preferences -> Localization ?

yes it does. f works when i turned the app into mandarin 👍

• @mpehkonen

If we have not localized keyboard shortcuts in the past, 3 is the best way forward and causes the least amount of complexity in maintaining the localized keys. Let's say when we change a feature name or its translation, we will need to ensure that the shortcut works in the context of all other shortcuts available to the user at that instance. Any duplicates will break the functionality. Only having to maintain the complexity in one language is the ideal solution for a fast changing environment. Also different shortcut keys in different languages will make it harder to communicate between users of two different languages. My suggestion is to have the shortcut letter point to the simplest unique word describing the functionality (browser filter -> f ,for filtering) unless we have multiple filters accessible from the same screen in which case the differentiator becomes the target of the filtering.

For the parenthesis format, English parenthesis are generally acceptable when the content in the parenthesis is western characters, especially if parenthesis are at the end or beginning of the string.

• @opysaryuk

Adding @brendan777 and @alyssatrinh for feedback on UI copy UI text 🙏 (thank you for the ping @marcel.amirault !197008 (closed)

• @marcel.amirault

I was looking at the question in slack, and I think we can drop the (f) completely here. The shortcut for filters is f on every page, which is listed in the cheat sheet you get if you hit ? in GitLab (try it now!)

So if a page has a filter, f is already known as the shortcut key to take you there. Go to the MR list, Issues list, Commits list, tags list, etc... and f always takes you to the filter.

So all we need is for @brendan777 and @alyssatrinh to figure out what text they would prefer. Somes examples of what we already have in other areas are things like:

• Filter by branch name
• Search or filter results...
• Filter or search (3 characters minimum)

So perhaps something like these?

• Search for files (wildcards accepted) (if it fits in the text box)
• Search (wildcards accepted)

Design recommendation

Update the placeholder text per discussion in #558792 (comment 2683498611).

File tree browser on GDK with suggested placeholder text
Placeholder text: Filter files (*.vue, *.rb...)