GNOME Bugzilla – Bug 436926
Keyboard bindings should be more easily definable for different locales
Last modified: 2018-02-08 12:55:41 UTC
From the Orca users list: http://mail.gnome.org/archives/orca-list/2007-April/msg00413.html "There is one quite annoying issue with orca which I would like to get fixed. After switching keyboard to Russian layout, orca stops responding to any commands. In order to make orca read something for me, I have to switch my keyboard back into English layout. That means that I have to use one more keystroke with orca when I am typing in Russian."
A potential solution to this, which I'm not sure I really think is a great idea, would be to mark the keysyms used in the keybindings for translation. For example, instead of: keyBindings.add( keybindings.KeyBinding( "q", 1 << settings.MODIFIER_ORCA, 1 << settings.MODIFIER_ORCA, self.inputEventHandlers["shutdownHandler"])) We could do: # Translators: this is the keybinding used to quit Orca. It is # meant to be a mnemonic in the locale of the user. When in doubt, # leave it as is. When changing it, please work to ensure a unique # mnemonic across all other strings marked for translation via the # "keybinding|" prefix. # # ONLY TRANSLATE THE PART AFTER THE PIPE CHARACTER | # keyBindings.add( keybindings.KeyBinding( Q_("keybinding|q"), 1 << settings.MODIFIER_ORCA, 1 << settings.MODIFIER_ORCA, self.inputEventHandlers["shutdownHandler"])) This requires care and understanding from the translator, though.
Note also that this applies to geographical layout as well (e.g., the laptop flat review keys rely upon keyboard position for them to be logically understood). The position of individual keys can differ from layout to layout, however. For example, qwerty vs. azerty layouts.
*** Bug 538693 has been marked as a duplicate of this bug. ***
Planning spam. Sorry!
Created attachment 209322 [details] [review] Patch to mark keys for translation Here is a patch that marks key binding keys for translation with the context 'keybinding'. This includes every letter, numbers for the bookmarks key bindings and punctuation keys. Not included are the keypad keys, Esc, F1 - F12, Tab, BackSpace, Return and Space. The numbers for the structural navigation of headings at level 1-6 should be translated, too. But currently the number is required to determine the heading level. Because of this it wouldn't be a good idea to translate this bindings.
Hy Marcus, Your patch basicaly good, but I found some issues when I tested in Precise (Ubuntu 12.04). If all system configurations are full good, patch works fine. Unfortunately you forgot add the src/orca/laptop_keyboardmap.py file in po/POTFILES.in file, so I doed this before I translated all strings with hungarian locale. Absolute sure need translating this lot of keyname strings? Normal english alphabetic letters are need translating with all languages (u, k, l, b, etc)? The translation need doing carefuly, not always Orca users doing the translation related work, so easy mistake a keybinding if the translator wrote normal localized character the translation. A typical example is the eacute character map. I known, if would like define equals phisical place the sayall command with english command, need replacing the semicolon string with eacute simbol in the hu.po file the msgstr field. But if a sighted translator doing the translation, possible write the ; character with semicolon character translation. I known, you correct say translators need write some special simbols with english names. Look my detailed test results. If the system locale is hungarian, and the first selected keyboard layout is hungarian, all localized keybindings works right. If I switch keyboard layout temporary from hungarian layout to english layout, all localized keybinding commands works right, because hungarian layout the default keyboard layout, and only temporary keyboard layout switch happened. You known, the default keyboard layout in GNOME3 the first keyboard layout in the GNOME Control Center keyboard layout preference tool/layouts page. But, if the english keyboard layout the default layout, but system locale is hungarian, the localized keybindings not working of course. Look a trivial example. Orca+semicolon (sayall command): with hungarian keyboard layout the semicolon character phisical place have eacute key name, so I wrote msgstr field this keyname, because original semicolon keybinding is conflicting with Orca+comma command. Why conflict? Because comma and semicolon characters have equals phisical place. If we would like write comma character, press simple comma, if we would like write semicolon character, press ALTGR+Comma. Similar the problem with f and bracketleft, g and bracketright characters, this is standard hungarian keyboard map. Because not have english keyboard layout eacute letter, sayall command doesn't work this situation. Gettext pass Orca of course with semicolon english string the eacute keyname because the language for example is hungarian, but because the default keyboard layout are not determined and not replace proper localized strings with default keyboard layout awailable translated string, this keyboard command doesn't work. So, need examining the first default keyboard layout, and pass Orca the correct keyname, depending keyboard layout the english locale keyname or the actual locale translated keyname. You understand what can I would like? If this situation are resolwed, this bug and other similar bugs entire resolved. You easy possible examining what the default keyboard layout, if you request following gsettings key: org.gnome.libgnomekbd.keyboard layouts For example, when I doed the prewious wrote extra test, this key showing me following value: ['us', 'hu'] First returned walue the default keyboard layout. Attila
Created attachment 209388 [details] [review] Fixed patch I have forgot most of the changed files to add to POTFILES.in. This patch includes the changes to POTFILES.in.
(In reply to comment #6) > Absolute sure need translating this lot of keyname strings? Normal english > alphabetic letters are need translating with all languages (u, k, l, b, etc)? Yes, this is needed. Orca can used by users that use a language that aren't based on a Latin alphabet. As example the original author about this bug is using the ru locale what is using Cyrillic. Because of this letters must be translatable, too. The same applies for numbers. On a AZERTY layout numbers must be entered with a Shift combination. As example to write 1 a French user have to enter Shift+&. If those user want to go to the previous heading of level 1 the user must press Shift+Shift+& what isn't possible. Here I think it would be good to translate '1' with '&' for the fr locale. > The translation need doing carefuly, not always Orca users doing the > translation related work, so easy mistake a keybinding if the translator wrote > normal localized character the translation. A typical example is the eacute > character map. I known, if would like define equals phisical place the sayall > command with english command, need replacing the semicolon string with eacute > simbol in the hu.po file the msgstr field. But if a sighted translator doing > the translation, possible write the ; character with semicolon character > translation. I know about this problem. But how I should explain this the translators in the comments? First I want to write something like "this key is for easy access" or something like. But then I have translated the laptop key bindings. Why is Orca+7 a left click and not Orca+8? I doesn't know why those keys are used. So I think it would be better if the developers extends the comments to explain why *this* key and not any other key. As example for Orca+Q I can guess that 'Q' is short for Quit. Or 'A' for Anchor and so on. I'm sure the laptop bindings should simulate the keypad. But if this is really true, the key '7' is one key too far left (on my PC keyboard). > Look my detailed test results. > If the system locale is hungarian, and the first selected keyboard layout is > hungarian, all localized keybindings works right. If I switch keyboard layout > temporary from hungarian layout to english layout, all localized keybinding > commands works right, because hungarian layout the default keyboard layout, and > only temporary keyboard layout switch happened. > You known, the default keyboard layout in GNOME3 the first keyboard layout in > the GNOME Control Center keyboard layout preference tool/layouts page. > But, if the english keyboard layout the default layout, but system locale is > hungarian, the localized keybindings not working of course. > Look a trivial example. This *could* be solved if there is a special function that translate the key bindings not by the locale, but by the selected layout. I know joanie want to be desktop independent. Because of this I doesn't know how to do this. How to get informations about the default layout from other desktops like Xfce, LXDE or KDE? And such a function have to determine what desktop is currently in use before the default layout is determined. The first part of this wouldn't be very easy. I think it would be impossible. I have seen so many different scripts for this job, mostly depending on a certain distribution and/or session-manager.
Hy Marcus, Not tryed the attached patch yet, but I think all changed file now are present in potfiles.in. I think need handling an another bug too, but this is possible only with next master version when will be not have UI freeze. When you opening Orca GUI preferences dialog and looks the keybindings page, the keynames simbols is present, some example: semicolon, slash, bracketleft, bracketright, period, etc. This is not happening because you marked translation the keynames, this is a general problem. When for example future I will be translating hungarian language with key names after the patch are committed, following text are will be presenting in GUI setup dialog the keybindings page, visual output are not will be beautiful: Semicolon replaced with eacute, bracketleft with odoubleacute, bracketright replace with uacute, etc. Visualy better look this situation following replacements in hungarian translated UI interface: Semicolon replace with é character, bracketleft replace with ő character, bracketright replaced with ú character, etc. So, need separate the general keybinding translation and the visual UI interface keybinding translation, and for example list shortcut feature need return too the UI interface have translations, not real key names (Orca+bracketleft, Orca+bracketright, Orca+semicolon, etc). Attila
Created attachment 209437 [details] [review] Fixed patch 2 This patch has changed translator comments. I have added a link to gdkkeysyms.h in git to inform translators how the different keys are named. For laptop bindings I have added a link to an image on Wikipedia to look where the keys are physical located. And I have removed two translatable string for Return. Return is Return on every layout. :-)
Created attachment 211063 [details] [review] Actualized patch for latest master version Hy Marcus, I doed an actual version with your patch, because Emacs Speak support is removed in Orca source tree, POTFILES.in file is changed. Tomorrow I try joining your patch and you sent me UI file keybindings related patch. If all works succesful, I sending the joined patch this bug. Attila