Hide Forgot
Cause: Naive attempt to add auto-mnemonics to buttons Consequence: non-existing keys suggested as shortcuts Fix: Manually choose mnemonics for OK/Cancel in affected languages Result: Short cuts suggested are achievable from the keyboard
Description of problem: [CCJK] Missing hotkeys for 'OK' and 'Cancel' button of LibreOffice. Version-Release number of selected component (if applicable): libreoffice-core-3.4.5.2-16.1.el6_3.x86_64 libreoffice-impress-3.4.5.2-16.1.el6_3.x86_64 libreoffice-draw-3.4.5.2-16.1.el6_3.x86_64 libreoffice-writer-3.4.5.2-16.1.el6_3.x86_64 libreoffice-calc-3.4.5.2-16.1.el6_3.x86_64 How reproducible: 100% Steps to Reproduce: 1. Install latest rhel6.4 client build. 2. Open libreoffice. 3. Click File->Print Settings. Actual results: [CCJK] Missing hotkeys for 'OK' and 'Cancel' button of LibreOffice Expected results: Should add hotkeys to them. Additional info:
Created attachment 684965 [details] Missing hotkeys for 'OK' and 'Cancel' button of LibreOffice
This is a translation thing, the translations for the language need to include the desired hotkeys, i.e. translations/source/zh-CN/vcl/source/src.po #: btntext.src#SV_BUTTONTEXT_OK.string.text msgid "OK" msgstr "确定" a) Presumably this is with *every* OK/Cancel button right ? b) I'm *guessing* this is zh-CN, right ? c) What strings does e.g. gtk use here ?, I mean what do we want them to say ? Did we ever have hotkeys for OK/Cancel in OpenOffice.org for zh-CN, as far as I can see the translations have never included any hotkeys there. So it seems to have been like that for a very long time ?
(In reply to comment #3) > This is a translation thing, the translations for the language need to > include the desired hotkeys, i.e. translations/source/zh-CN/vcl/source/src.po > #: btntext.src#SV_BUTTONTEXT_OK.string.text > msgid "OK" > msgstr "确定" > > a) Presumably this is with *every* OK/Cancel button right ? Yes for libreoffice > b) I'm *guessing* this is zh-CN, right ? Yes, also reproduced on zh_TW, ja_JP, ko_KR and Indic locales. > c) What strings does e.g. gtk use here ?, I mean what do we want them to say > If we want add the hotkeys to the button, please just add it like this 'xxx(O)', 'xxx(C)'; > > Did we ever have hotkeys for OK/Cancel in OpenOffice.org for zh-CN, as far > as I can see the translations have never included any hotkeys there. So it > seems to have been like that for a very long time ? If we don't want add the hotkeys for OK/Cacel buttons(also including other buttons), please just remove the underline '_' from the localized button text as it make no senses for leaving the underline there. attaching the screen-shot from gedit to compare. Thanks, Robert
Created attachment 686503 [details] gedit correct hotkeys
"please just remove the underline '_'" ah!, now I see the root of the problem. http://cgit.freedesktop.org/libreoffice/core/commit/?id=58f16ff09672f3e37156d0fc5e79e310b2c49c08 adds automnemonics to any un-mnemoniced OK/Cancel strings which is why it becomes a recent problem.
So the problem is we're suggesting impossible short-cuts because we're adding mnemonics to the translation in a simplistic way. We have um-mnemonic-ed original strings because OK/Cancel are expected to be um-mnemonic-ed on windows. Under GNOME we try and mnemonic those, leading to the problem. http://lists.freedesktop.org/archives/libreoffice/2013-January/044513.html upstream I'll simply add additional strings one set to be mnemonic-ed and one set to be left un-mnemonic-ed and translators can pick their preferre mnemonic. For RHEL-6, if I get the acks, I will simply work around it by patching our translations to have additional (~O) (~C) shortcut strings
Verified it's fixed on libreoffice-4.0.4.2-9.el6 with latest rhel6.5 build. Please see the attached screenshot. Moving to VERIFIED.
Created attachment 816992 [details] Fixed
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1594.html