Viewing a history listing
|21:13, 28 June 2020||Verdy p||(Reply to use of the ampersand & in translated menu items)|
|20:03, 28 June 2020||Wladek92|
|19:57, 28 June 2020||Wladek92|
Hi all, I am doubtful about the use of the ampersand '&'. I guess it is used in menus to provide shortcuts ; so since EN '&Update' becomes '&Mettre à jour' in FR, the shortcut using 'M' could then not work with the code; am I wrong ?
Then should EN '&Update' becomes 'Mettre à jo&Ur' to respect the 'U', or do we translate in a transparent way into '&Mettre à jour' based on the first letter ?
such shortcuts are parsed specially in the text of the menu items to infer the key that will be mapped on the keyboard by the window menu manager. The assigned letters can be changed, but you MUST not write them with uppercase when the label has to be shown in lowercase.
These shortcuts are case-independant for the key-mapping (Usually Alt+letter or Alt+shift+letter), but not for the correct display. Note that this only works reliably for plain ASCII letters A-Z (or a-z) but not for any other letters that may be composed differently depending on the user's keybaord layout (even digits 0-9 don't work reliably). It's just a facility that avoids the applciation to define its keymapping separately.
In such situation you have to kwno which kind of application you are translating, to make suree that the window menu API will treat these shortcuts itself to assign the mappings.
If you can't use a distinctive letter from the label of the menu item, append a tabulation ("	") at end of the item label, then add "&" followed by the uppercase letter (in that case, that letter needs not be inside the translated item). For example when translating to Russia, Greek, Arabic, Hebrew, Chinese, you won't be able to map a distinctive letter on the menu item itself, the solution is then to append a tabulation and white "&letter" after the translated menu item (the shortcut will still be displayed but aligned to the other side of the menu item, with a minimum separation margin between the two sides, where it will be visible and properly underlined when needed).
Make sure you follow the model made for all menus inside the same application, don't attempt to unify these with translations made for other applications that may have their own API and may not support such parsed labels and may define their own keymapping separately.