Issue 42964

Summary: Localized menu has problem matching menu shortcut with input from keyboard
Product: Internationalization Reporter: samphan
Component: codeAssignee: stefan.baltzer
Status: CLOSED FIXED QA Contact: issues@l10n <issues>
Severity: Trivial    
Priority: P3 CC: arthit, hin.stone, issues, jjc, markpeak, nusorn
Version: OOo 2.0Keywords: oooqa
Target Milestone: ---   
Hardware: PC   
OS: All   
URL: http://specs.openoffice.org/g11n/menu_keycodes/42964_Match_localized_menu_with_input_from_keyboard.odt
Issue Type: FEATURE Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 41707, 42982    

Description samphan 2005-02-17 07:27:06 UTC
If the menu is localized to non-latin language (in this case Thai), there will
be a problem with using menu shortcut if the keyboard language is different from
the menu language.

1) if the menu is in English and the keyboard layout is English - OK. For
example, you can type 'Alt-F' then 'O' to open a file.
2) If the menu is in Thai and the keyboard layout is Thai - OK. For example, you
can type 'Alt-ฟ' then 'ป' to open a file.

3) if the menu is in Thai but the keyboard layout is English, e.g. users is
currently typing something in English - there'll be a problem. You can't type
'Alt-ฟ' and 'ป' to open a file because the keyboard layout is currently English.
You can't type 'Alt-F' and 'O' either because the menu is in Thai. The user has
to switch the keyboard layout to Thai before they can use the menu shortcut
which is impracticle.

4) if the menu is in English but the keyboard layout is Thai, e.g. Thai users
who prefer to use English UI and are typing Thai - there's a similar problem.
You can't type 'Alt-F' and 'O' because the keyboard layout is currently Thai.
The user has to switch the keyboard layout to English before they can use the
menu shortcut which is impracticle.

I think the cause of this problem is that OOo use translated keyboard character
to find the menu item. The solution may be having OOo uses keyboard scan code
and associates the scan codes with the menu items instead.
Comment 1 arthit 2005-02-18 10:33:38 UTC
In my opinion,
shortcut keys set should be in the same language as the language of ui
(since they the shortcuts for ui!).

i.e. If the menu is in English, we shouldn't allow any other language shortcut
to be function.

----

I think I and Samphan agree the same in the above point.
But the thing he likes to mention, get it to be fixed, is

"How to trap the shortcut keys properly?
 No matter what the current keyboard layout is."

How to trap both
 1) key <Alt> + character 'F', and
 2) key <Alt> + character 'ด'
as the same "Alt-F"?

note:
  (1)'s keyboard layout is typical QWERTY (English).
  (2)'s keyboard layout is Kedmanee (Thai).
  in those layouts, character 'F' and character 'ด'
  use the same physical key (button).

If we can trap this properly,
the shortcut keys for the current UI language will always works,
no matter what the current keyboard layout is.


Is that your idea, P'Samphan?
Comment 2 samphan 2005-02-18 11:39:22 UTC
Yes, the code that handle menu short cut should work regardless of which
keyboard layout the user use. So the code should use keyboard scan code instead.
Comment 3 jjc 2005-03-31 11:37:10 UTC
We can distinguish two kinds of shortcut

a) menu shortcuts (Alt + underlined letter from the menu); these would obviously
be localized along with the menu

b) other keyboard shortcuts (e.g.Ctl + S for save); I don't think you want these
localized

In both these cases, they should work regardless of the currently active
keyboard layout, e.g.

a) the current keyboard layout is English, the menus are Thai, I should be able
to activate the shortcut without changing the keyboard layout to Thai and back

b) the current keyboard layout is Thai, there is a shortcut using an ASCII
character (e.g. Ctl + S), I should be able to activate the shortcut without
changing the keyboard layout to English and back

Note that Word 2003 does both a) and b).

Also note that a single menu may have two shortcuts on the same key but with
different shift states (e.g. Microsoft Word's File menu has a shortcut on ร and
a shortcut on ณ, which are both on the same key (the same key as I)).  In other
words, you need to consider the modifiers as well as the keycode.
Comment 4 arthit 2005-03-31 12:03:11 UTC
confirmed.
Comment 5 samphan 2005-03-31 12:07:00 UTC
Test using OOo 1.9.84 on Windows and 1.9.71.1 on Linux, I found that b) works,
e.g. while using Thai keyboard I can press 'Ctrl-A' to select all or 'Ctrl-S' to
save.
Comment 6 Martin Hollmichel 2005-05-11 16:13:46 UTC
set target to 2.0.1
Comment 7 falko.tesch 2005-10-04 14:24:16 UTC
FT: Spec has been added at
http://specs.openoffice.org/g11n/menu_keycodes/42964_Match_localized_menu_with_input_from_keyboard.odt

FT->SSA: Please start implementation. Thank you very much.
Comment 8 stephan_schaefer 2005-10-07 13:27:24 UTC
started
Comment 9 stephan_schaefer 2005-10-26 10:12:45 UTC
Fixed in CWS thaiissues. Mnemonics now always work regardless of the current
keyboard configuration.
On Windows it works in both ways, i.e. Thai localized menus with English
keyboard and English localized menus with Thai keyboard.
On UNIX only English localized menus with Thai keyboard will work. (There is no
way to map a (Thai-)Unicode to the corresponding scancode, so no comparison is
possible)
Comment 10 stephan_schaefer 2005-11-03 10:09:30 UTC
ssa->sba: please verify.

re-open issue and reassign to sba@openoffice.org
Comment 11 stephan_schaefer 2005-11-03 10:09:41 UTC
reassign to sba@openoffice.org
Comment 12 stephan_schaefer 2005-11-03 10:09:46 UTC
reset resolution to FIXED
Comment 13 stefan.baltzer 2005-11-14 17:47:37 UTC
SBA: Verified in CWS thaiissues.
Comment 14 stefan.baltzer 2006-04-07 16:15:20 UTC
SBA: OK in OOo 2.01. Still OK in OOo 2.02. Closed.
Comment 15 alotiste 2010-11-10 17:04:12 UTC
Created attachment 73370