Hide Forgot
Description of problem: While using the Web Editor, the Alt+up and Alt+down keyboard shortcuts to move to the next and previous strings respectively currently do not work. How reproducible: Steps to Reproduce: 1. Go to translate.zanata.org 2. Log-in and select a project to work on 3. Open a file to translate in the Editor 4. Focus on an entry to make it editable 5. Press Alt+Up to move to the next entry or Press Alt+Down to move to the previous entry Actual results: The focus stays on the current entry Expected results: The focus should move in the direction as per the shortcuts used Additional info: 1. Also replicated for the current development version - 1.4 2. Tested on entries which are not the first or last entries on the page
Correction: These shortcuts do not work with the Right Alt key only, for some browser versions.
Navigation to previous and next translation unit(s) works for me in translation editor when using Alt_L modifier (tested with firefox-6.0.2-1.fc15.x86_64 & chromium 13.0.782.215-1.fc15.x86_64). Note: above behaviour doesn't work with Alt_R modifier.
Navigation to previous and next entry works works for me in translation editor only while using Alt_L modifier. With Alt_R it doesn't work. Browser: firefox-3.6.20-2.el6_1.x86_64 OS: el6.x86_64
One user has mentioned that he could not replicate the bug using firefox-6.0.2-1.fc15.x86_64, although another user (comment #2) could replicate with the same version.
From Comment 2 and Comment 3, required behaviour of navigation to next and previous translation unit(s) works with Alt_L (i.e. Alt left) modifier, and hence expected results are obtained. From Comment 1, Comment 2 and Comment 3, required behaviour of navigation to next and previous translation unit(s) doesn't work with Alt_R (i.e. Alt right) modifier, and hence expected results are not obtained.
It maybe the keyboard layout problem. sandeep, what's your keyboard layout? Does the Right Alt is shown as "AltGr"? Or please type following in a terminal window: 1. xev 2. And press following: alt_L-UP alt_R-UP 3. close xev 4. Paste the result, which should somewhat looks like: KeyPress event, serial 33, synthetic NO, window 0x5800001, root 0xb1, subw 0x0, time 24921477, (144,19), root:(146,109), state 0x0, keycode 108 (keysym 0xffea, Alt_R), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0x5800001, root 0xb1, subw 0x0, time 24921596, (144,19), root:(146,109), state 0x8, keycode 111 (keysym 0xff52, Up), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x5800001, root 0xb1, subw 0x0, time 24921651, (144,19), root:(146,109), state 0x8, keycode 111 (keysym 0xff52, Up), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0x5800001, root 0xb1, subw 0x0, time 24921785, (144,19), root:(146,109), state 0x8, keycode 116 (keysym 0xff54, Down), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x5800001, root 0xb1, subw 0x0, time 24921872, (144,19), root:(146,109), state 0x8, keycode 116 (keysym 0xff54, Down), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
(In reply to comment #6) > It maybe the keyboard layout problem. > Yes. I agree with you. > sandeep, what's your keyboard layout? Does the Right Alt is shown as "AltGr"? > Yes, Right Alt is shown as "AltGr". This has been done to add "Rupee" currency sign to key bearing numeral '4'; and key to choose 3rd level was 'Right Alt'. xev output: ============ KeyPress event, serial 32, synthetic NO, window 0x3600001, root 0xb8, subw 0x0, time 636197, (790,272), root:(791,361), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 32, synthetic NO, window 0x3600001, root 0xb8, subw 0x0, time 636335, (790,272), root:(791,361), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False Therefore, required behaviour of navigation to next and previous translation unit(s) works with Alt_R (i.e. Alt right) modifier, and hence expected results are obtained. This concludes that this bug can't be reproduced henceforth.
Confirmed that the Right Alt+up/down works if the 'Indian Keyboard with Rupee Sign' is disabled. Unfortunately, for Indian users this won't be feasible. With the plans of using Alt_Gr on a much larger scale for various Indian input methods (also to be included in ibus), this particular shortcut may have to be explicitly restricted to the Left Alt.
(In reply to comment #7) > (In reply to comment #6) > > It maybe the keyboard layout problem. > > > > Yes. I agree with you. > > > sandeep, what's your keyboard layout? Does the Right Alt is shown as "AltGr"? > > > > > Yes, Right Alt is shown as "AltGr". > > This has been done to add "Rupee" currency sign to key bearing numeral '4'; and > key to choose 3rd level was 'Right Alt'. > > > xev output: > ============ > KeyPress event, serial 32, synthetic NO, window 0x3600001, > root 0xb8, subw 0x0, time 636197, (790,272), root:(791,361), > state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, > XKeysymToKeycode returns keycode: 92 > XLookupString gives 0 bytes: > XmbLookupString gives 0 bytes: > XFilterEvent returns: False > > KeyRelease event, serial 32, synthetic NO, window 0x3600001, > root 0xb8, subw 0x0, time 636335, (790,272), root:(791,361), > state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, > XKeysymToKeycode returns keycode: 92 > XLookupString gives 0 bytes: > XFilterEvent returns: False > > > Therefore, required behaviour of navigation to next and previous translation > unit(s) works with Alt_R (i.e. Alt right) modifier, and hence expected results > are obtained. > > This concludes that this bug can't be reproduced henceforth. Just as I suspected, "Normal" Alt produce 0x8, while AltGr produce 0x80 Thus Alt-Up is not the same with AltGr-Up BTW, does AltGr-Up, AltGr-Down, AltGr-PgUp, AltGr-PgDn clash with your input method or keyboard layout?
So, is this a request to enable AltGr-Up/Down/PgUp/PgDn, or to avoid them, and keep them free for input methods? Do we need to do anything?
Ideally to avoid Alt_Gr. At present it conflicts with the 'Indian Keyboard with the Rupee Sign'. However, going forward it will conflict with IBus as well, due to the Enhanced Inscript keyboards for the Indian languages with heavy usage of Alt_Gr. These are currently in the testing phase. https://fedorahosted.org/inscript2/
As modifier AltGr might clash when inputting Indic, this bug will be closed as WONTFIX