Issue 122640

Summary: Accelerators (mnemonics) missing in main menu in localized versions
Product: Native-Lang Reporter: Andrea Pescetti <pescetti>
Component: itAssignee: AOO issues mailing list <issues>
Status: CLOSED FIXED QA Contact:
Severity: Normal    
Priority: P3 CC: arielch, digro, hanya.runo, jsc, mechtilde, pmralbuquerque, rb.henschel, rgb.mldc
Version: 4.0.0-devKeywords: regression
Target Milestone: ---Flags: jsc: 4.0.0_release_blocker+
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Menus in Italian 4.0 dev snapshot none

Description Andrea Pescetti 2013-06-29 16:31:44 UTC
Created attachment 80950 [details]
Menus in Italian 4.0 dev snapshot

We've been telling translators that they can ignore "~" in translated strings (corresponding to keyboard accelerator, e.g., ALT-F-O to open a file, not to be confused with shortcuts, like CTRL-O, that are fine), following historical information.

This indeed works for the internal menu items (it seems that accelerators are assigned correctly), but not for the main menu items.

See attached screenshot for the Italian version; other versions have the same problem.

It would probably be good to fix at least the main menu in OpenOffice 4.0 final. Internal menu items have sporadic problems due probably to imperfections in the algorithm.

Only a few dozen strings should be impacted.
Comment 1 Regina Henschel 2013-06-29 16:59:19 UTC
In German r1497734 no access key is missing in the main menu.
Comment 2 Ariel Constenla-Haile 2013-06-29 17:13:41 UTC
(In reply to Andrea Pescetti from comment #0)
> Created attachment 80950 [details]
> Menus in Italian 4.0 dev snapshot
> 
> We've been telling translators that they can ignore "~" in translated
> strings (corresponding to keyboard accelerator, e.g., ALT-F-O to open a
> file, not to be confused with shortcuts, like CTRL-O, that are fine),
> following historical information.
> 
> This indeed works for the internal menu items (it seems that accelerators
> are assigned correctly), 

In most cases, yes; but not in general:

- New Impress document
- menu "~View" - "Sidebar" has no mnemonic character assigned.

This is a regression introduced by some change in the vcl code, may be in the way to Oracle 3.4 beta or before. In 3.0.0 (old version I have at hand), mnemonic are generated always:

- New Writer document
- Tools - Customize - Menus
- Add a new top level menu "New menu"
- Add the following menu items:

abc
abc
abc
abc
abc
abc

Save the changes, and open the new menubar's PopupMenu:

- in 3.0.0 you get

~abc
a~bc
ab~c
~abc
~abc
~abc

The algorithm was not perfect, but it was working. One could expect a desirable result of:

~abc
a~bc
ab~c
~abc
a~bc
ab~c

instead of the first letter as mnemonic when all letters are already taken.

- in 3.4.1 you get

~abc
a~bc
ab~c
abc
abc
abc

The regression here is visible: it's better to have repeated mnemonics than no mnemonic at all.

> but not for the main menu items.

Automatic mnemonics were never generated for the top level menu bar items, only for the its PopupMenus.

This could be added to the code (if possible - I'll have to check), and it would be useful for the case of user-customized menus (when the user customizes the menubar s/he has no idea about mnemonic character ~, so the new menubar item ends up without mnemonic).

But for the OpenOffice menubar, using automatic mnemonic generation will end up on the same top level menubar items having different mnemonic across the different applications.

> It would probably be good to fix at least the main menu in OpenOffice 4.0
> final.

IMO, for the top level menubar items, the only fix is to set the mnemonic character in the translation. This should be already in the translation memory, in officecfg/registry/data/org/openoffice/Office/UI.po
For example, ".uno:PickList" was in 3.4.* in two places:

https://translate.apache.org/es/OOo_34/translate.html#search=uno_PickList&sfields=locations
GenericCommands.xcu#..GenericCommands.UserInterface.Popups..uno_PickList.Label.value.text
StartModuleCommands.xcu#..StartModuleCommands.UserInterface.Popups..uno_PickList.Label.value.text

In 4.0.0 all commands with the same label were moved to GenericCommands.xcu, so now there is only one string to translate:
https://translate.apache.org/es/aoo40/translate.html#search=uno_PickList&sfields=locations

For example, in the 4.0.0 Spanish translation, the Window menubar item has no accelerator:
https://translate.apache.org/es/aoo40/translate.html#search=uno_WindowList&sfields=locations
The translator should pick a translation memory suggestion.
Comment 3 rgb 2013-06-29 17:48:49 UTC
(In reply to Ariel Constenla-Haile from comment #2)

> For example, in the 4.0.0 Spanish translation, the Window menubar item has
> no accelerator:
> https://translate.apache.org/es/aoo40/translate.
> html#search=uno_WindowList&sfields=locations
> The translator should pick a translation memory suggestion.

I set Ve~ntana (as on 3.4.1) on pootle. Accelerators are missing for menus Editar, Ver and Insertar too. 

I added accelerators on pootle to the following translations to match 3.4.1 ES menus

https://translate.apache.org/es/aoo40/translate.html#unit=13115179
https://translate.apache.org/es/aoo40/translate.html#unit=13115206
https://translate.apache.org/es/aoo40/translate.html#unit=15564714
Comment 4 Andrea Pescetti 2013-06-29 21:50:36 UTC
@Ariel: thanks a lot, I agree this is best fixed in Pootle and it's good to know that it's only a handful of strings for each affected language.

@RGB: the string in https://translate.apache.org/es/aoo40/translate.html#unit=15564714 does not seem fixed.
Comment 5 rgb 2013-06-29 22:09:48 UTC
(In reply to Andrea Pescetti from comment #4)
> @RGB: the string in
> https://translate.apache.org/es/aoo40/translate.html#unit=15564714 does not
> seem fixed.

Ops! it's now fixed.
Comment 7 rgb 2013-06-29 22:35:05 UTC
(In reply to Ariel Constenla-Haile from comment #6)
> This is the full list of top level menubar items:
> <snip>

All items have now the same 3.4.1 accelerators.
Comment 8 Andrea Pescetti 2013-06-30 11:21:04 UTC
I confirm that fixing the following strings in the Italian SDF file produced a build with all mnemonics enabled in all top-level menus.

..DrawImpressCommands.UserInterface.Popups..uno:SlideShowMenu ~Presentazione
..GenericCommands.UserInterface.Popups..uno:EditMenu          ~Modifica
..GenericCommands.UserInterface.Popups..uno:InsertMenu        ~Inserisci
..GenericCommands.UserInterface.Popups..uno:ToolsMenu         ~Strumenti
..GenericCommands.UserInterface.Popups..uno:ViewMenu          ~Visualizza
..GenericCommands.UserInterface.Popups..uno:WindowList        Fi~nestra

I've now made the corresponding changes in Pootle for Italian (I didn't commit the fixed SDF since it would have been overwritten of course).
Comment 9 hanya 2013-06-30 12:12:27 UTC
Fixed for ja. Slide Show did not have mnemonics.
Comment 10 Andrea Pescetti 2013-06-30 12:22:32 UTC
Detailed instructions about the broken mnemonics in main menu items, and how to quickly fix translations, have been sent to the l10n list:
http://markmail.org/message/wmgezxw6trotrksy

Suggesting as release blocker, for some reasonable definition (minimally, we should update all translations that are fixed in Pootle by tomorrow's deadline; at the other extreme, all translations should be fixed). The most reasonable solution is to fix all strings that would result in a regression; this is feasible since the 3.4.1 mnemonics are in Pootle's translation memory and can easily be retrieved.

Spanish "es" is fixed, Italian "it" is fixed, Greek "el" is fixed, Japanese "ja" is fixed, several languages (including English, French, German) do not need any fixes.
Comment 11 Andrea Pescetti 2013-06-30 12:23:27 UTC
Detailed instructions about the broken mnemonics in main menu items, and how to quickly fix translations, have been sent to the l10n list:
http://markmail.org/message/wmgezxw6trotrksy

Suggesting as release blocker, for some reasonable definition (minimally, we should update all translations that are fixed in Pootle by tomorrow's deadline; at the other extreme, all translations should be fixed). The most reasonable solution is to fix all strings that would result in a regression; this is feasible since the 3.4.1 mnemonics are in Pootle's translation memory and can easily be retrieved.

Spanish "es" is fixed, Italian "it" is fixed, Greek "el" is fixed, Japanese "ja" is fixed, several languages (including English, French, German) do not need any fixes.
Comment 12 Pedro Albuquerque 2013-06-30 13:51:25 UTC
Portugal accelerators reviewed and corrected.
Thanks
Comment 13 Dick Groskamp 2013-06-30 16:14:14 UTC
Dutch  (Nederlands) accelerators reviewed and corrected.
Thanks

_____
DiGro
Comment 14 Ariel Constenla-Haile 2013-07-01 05:30:56 UTC
(In reply to Ariel Constenla-Haile from comment #2)
> In most cases, yes; but not in general:
> 
> - New Impress document
> - menu "~View" - "Sidebar" has no mnemonic character assigned.
> 
> This is a regression introduced by some change in the vcl code, may be in
> the way to Oracle 3.4 beta or before. 

http://svn.apache.org/viewvc/openoffice/trunk/main/vcl/source/window/mnemonic.cxx?revision=1413471&view=markup#l331

331 	// #i87415# Duplicates mnemonics are bad for consistent keyboard accessibility
332 	// It's probably better to not have mnemonics for some widgets, than to have ambiguous ones.

This assumption is obviously wrong.
Comment 15 jsc 2013-07-01 06:40:53 UTC
set showstopper flag
Comment 16 Ariel Constenla-Haile 2013-07-01 07:00:32 UTC
The Tamil translation is rather confusing:

- automatic mnemonics are one on by default on the OO configuration, so you get labels with ~
- but the translation seems to use the same type of mnemonics as Japanese and Chinese: (~A-Z), test by grepping the SDF file:

grep --extended-regexp "\(~[A-Za-z0-9]\)" /build/aoo/src/clean/AOO34/extras/l10n/source/ta/localize.sdf

Can someone clarify?
Comment 17 Ariel Constenla-Haile 2013-07-01 07:10:05 UTC
(In reply to Ariel Constenla-Haile from comment #16)
> The Tamil translation is rather confusing:
> 
> - automatic mnemonics are one on by default on the OO configuration, so you
> get labels with ~
> - but the translation seems to use the same type of mnemonics as Japanese
> and Chinese: (~A-Z), test by grepping the SDF file:
> 
> grep --extended-regexp "\(~[A-Za-z0-9]\)"
> /build/aoo/src/clean/AOO34/extras/l10n/source/ta/localize.sdf

Also grep for "~" in the current trunk SDF, you get both mixed:

* sfx2 source\appl\newhelp.src TP_HELP_SEARCH PB_SEARCH ~கண்டுபிடிக்க
* .uno:ChangeFont எழுத்துருக்கள் (~F)...
Comment 18 Ariel Constenla-Haile 2013-07-01 21:52:41 UTC
(In reply to Ariel Constenla-Haile from comment #17)
> > The Tamil translation is rather confusing:

I opened a separated bug for Tamil, as it goes beyond the scope of top level menubar items: bug 122663
Comment 19 jsc 2013-07-05 09:40:02 UTC
this should be fixed with the latest translation update, needs verification
Comment 20 rgb 2013-07-11 20:34:44 UTC
(In reply to jsc from comment #19)
> this should be fixed with the latest translation update, needs verification

Verified for ES build:

AOO400m3(Build:9702)  -  Rev. 1499347
2013-07-03 14:08:16 (Wed, 03 Jul 2013) - Linux x86_64

(I'm not sure if it's right to set the status as "verified" right now or if we need to wait for confirmation from other languages)
Comment 21 Mechtilde 2013-08-14 05:42:55 UTC
add me to CC