a11yhelp strings should be externalised into lang files

[Teresa Monahan]

The a11yhelp dialog uses a keyMap to generate the strings for special keystrokes in the editor e.g. ALT+F10, SHIFT+CTRL+3.

var keyMap = {
	8: "BACKSPACE",
	9: "TAB",
	13: "ENTER",
	16: "SHIFT",
	17: "CTRL",
	18: "ALT",
	19: "PAUSE",
        ....};

However some of these values are translatable so they should be moved to the a11yhelp language files.

[Jakub Ś]

Based on Arabic language:

1. I have tried looking for translations for keys you have mentioned and haven't found translations for - alt, ctrl, enter and tab.
2. I have also checked Arabic Keyboards (​https://www.google.pl/search?q=arabic+keyboard&source=lnms&tbm=isch&sa=X&ei=0cONUoTPFaSP7AaiyoC4Aw&ved=0CAkQ_AUoAQ&biw=1920&bih=1018) and to my surprise all keys mentioned by you are in English (I got same results for German and Japanese keyboards).

If these keys are known and used Worldwide I don't think it is a good idea to translate them. IMHO this can only bring confusion thus it should be left the way it is.

@tmonahan could you comment on this?

[Teresa Monahan]

Replying to j.swiderski:

Hi, There are some languages where these strings should be translated. For example, the German keyboard uses German abbreviations as standard (​http://en.wikipedia.org/wiki/German_keyboard_layout). You can see that Strg is used for Ctrl. Also Shift is often translated to Maj on French keyboards and Mayus on Spanish keyboards.

In addition, the keyMap in the a11yhelp dialog includes entries like 'Left Arrow', 'Page Up', 'End', 'Add', 'Subtract', 'Open Bracket' etc which would definitely require translation if they were used as a keyboard shortcut in the editor.

[Jakub Ś]

Thanks for explanations. I'm confirming this ticket.

I definitely agree with Page Up like buttons because I see them translated.
German example is also a good example.

I'm a little bit concerned by "Shift is often translated". It would be nice to know what does it mean often - is it standard or some alternative but not very popular. Despite my concerns I believe once labels will be moved to language files they will either be translated by users or not.

[Jakub Ś]

Pushed changes into t/11196 ​git:468144a

[Olek Nowodziński]

Some entries in keyMap object literal are not named properly. Why

commaKey: "COMMA" 

while

period: "PERIOD"

?

All entries should use the "key" suffix or it should be removed.

I'm also pretty sure that appending translations to lang/en.js is enough for Wiktor to generate other entries (let's wait for him to express concerns).

[Frederico Caldeira Knabben]

We don't need the "Key" suffix, in fact.. .let's make these entries shorter.

[Olek Nowodziński]

​t/11196b

I cleaned up and unified keys in keyMap object literal, fixed typos in translations and reduced impact to lang/en.js file only.

[Jakub Ś]

Let's wait for Wiktor response.

1. I'm not sure if impact can be reduced to one file only. This is not how I understood it when talking to Wiktor.
2. I also don't think that changing "The keyboard button name for the Numpad 6 key." to "The label for "Numpad 6" key." is good. This message is context which has to explain translator in trnasifex what is he translating. Label can mean few things while "keyboard key" is one direct translation.

I think the only error were these “Key” suffixes I have added.

[Piotrek Koszuliński]

I pushed a commit adding entries to other language files.

[Olek Nowodziński]

​git:849a648 landed in master.