1191399 - [translate] Smart keyboard shortcut localization

Status: RESOLVED DUPLICATE of bug 1280686

(Webtools Graveyard :: Pontoon, defect, P3)

Description

[Amir Aharoni]

Translatable strings that are keyboard shortcuts appear just like usual messages.

There are lots of these messages in the translation of Firefox and the interface for their translation could be much more convenient for the translator.

For example, Pontoon could:
* clearly show them as related to the string of the action
* automatically validate them to prevent duplication
* let the user choose one of the letters used in the string of the action
* not count them in the statistics if their translation is not required

There could be more optimizations.

Comment 1

[Tomer Cohen :tomer]

There are two kinds of keyboard shortcuts - Accesskeys and keybindings. While most people translate accesskeys, keybindings (such as Ctrl-P for the print dialog) are never translated by most locales, and should be marked with Do Not Translate flag - Would you like to file a different bug for these strings if you've not filed already?

Example from https://mxr.mozilla.org/l10n-mozilla-aurora/source/en-GB/browser/chrome/browser/browser.dtd#302
<!ENTITY newNavigatorCmd.label        "New Window">
<!ENTITY newNavigatorCmd.key        "N">
<!ENTITY newNavigatorCmd.accesskey      "N">

newNavigatorCmd.label is the string itself, .key is the keyboard shortcut for new window (Ctrl-N) and never get translated, and .accesskey is the keyboard shortcut that is the underlined letter in the .label and would be launched by pressing the letter inside the File menu (Alt-F in the English locale). 


(In reply to Amir Aharoni from comment #0)
> * clearly show them as related to the string of the action
As seen above, Accesskeys are strings prefixed by .accesskey. I'd suggest to implement the following algorithm to validate the letter exists in the label, or else we'd end up with something like "New Window (X)" because the .accesskey is set to "X" and doesn't exists in the label - 


if (key.accesskey is not null and key.label exists)
  if (key.accesskey exists in key.label[]) return true
  else return false

> * let the user choose one of the letters used in the string of the action

This sounds similar to the idea above - if you can identify a string and its accesskey, the accesskey should be a letter that exists in the label. Yet again, please note that there are some issues if you forbid the use of other keys, with problems such as with the "Inspect Element (Q)" in the en-US context menu. 

> * not count them in the statistics if their translation is not required

Note that .key are never translated by most locales. For example, Ctrl-P is always the print dialog and Ctrl-T would open a new tab on every locale. We can't remove them from the translation files or forbid changing them as there are some locales that prefer to translate them, for example to preserve the keyboard shortcuts of other applications on the same locale or to deal with missing keys in the keyboard (We had such problem in bug 452393). 

I'd suggest having a preferences to control the behavior the translation tool on such cases, with the following options:
 * Always keep keybindings as en-US - New keybindings will be set as the same value as en-US, external changes would be preserved but warn the user, keys won't be visible to the user.
 * Set keybindings as en-US - New keybindings will be set as the same value as en-US, external changes would be preserved, keys would be visible to the user (so could be changed). 
 * Do not set keybindings automatically - New keybindings will be kept as untranslated, keybindings will be always visible. 

> * automatically validate them to prevent duplication

This would be more difficult as some files contain multiple accesskeys that are equivalent but would never display at the same time, so it is non-issue. For example, the Edit menu contains A as accesskey for Select &All, but the same accesskey is set for &Addons in the Tools menu. I remember that the QA team had a tool that can warn on such problems, but it is not used as far as I know as part of the regular tests that run on CI, but maybe it could be used as a webservice or to build lists of strings that may be displayed on the same screens and cause this overlapping.

Comment 2

[Tomer Cohen :tomer]

In addition, as we've discussed earlier, I'd suggest to group all key.* together. While on the files these strings are displayed together and may have a comment above them, most tools doesn't show any indication of the relations between these strings.

Comment 3

[Khaled Hosny]

Please note that the naming is not consistent, sometimes access keys are named .key, sometimes developers just invent some new suffix and experience over the years is that it is impossible to get Mozilla developers to be consistent here.

Comment 4

[Марко М. Костић (Marko M. Kostić) [:Kostic]]

I just want to add that Pontoon should, at least, provide an option to always show "More details" so the translators can more easily differnate betwen an accesskey and a cmdkey. Currently, I need to click "More detais" for every string containting one letter so I could deduce if the string is accesskey which should be localized or an cmdkey which I just need to copy over from the original string.

This option could be located in the translator's profile settings.

Comment 5

[Matjaz Horvat [:mathjazz]]

Not related to this bug, but a response to Марко - we removed the "More details" button and now always display all metadata of the string we have.

Comment 6

[Марко М. Костић (Marko M. Kostić) [:Kostic]]

@mathjazz, that's great to hear. Thanks!

Comment 7

[Matjaz Horvat [:mathjazz]]

The upcoming FTL file format will match strings with corresponding accesskeys, consistently:
https://reviewboard.mozilla.org/r/68010/diff/4#0

We will build the UI to support advanced FTL features as part of bug 1280686. Resolving this as duplicate.