Version: (using KDE KDE 3.1) Installed from: Mandrake RPMs OS: Linux It seems that KAddressBook will try to use the first character of a label as the accelerators in contact editing mode. Say "R" for "Role:". But this is no use in many foreign languages. Take Chinese as an example, we will translate "Role:" into "ABCD:", here character "A" cannot be found in keyboard. It would be better assign accelerators directly in text, which means "&Role:".
Created attachment 1605 [details] Edit Contact Dialog in Chinese The text in Green circle means correct accelerators have been specified, red circle wrong. It seems that KAcceleratorManager cannot deal DBCS well, maybe in Arabic or Hebrew. Hardcode the Accelerators, please.
can you name what character are ok and which are not? And shall KAcceleratorManager create a character on it's own or would you prefer it to leave off the asian translations? Note that you can still put the (&L) in the translation. Those will be prefered by KAM
It is very easy to distinguish which characters can be used as accelerators. Only ASCII characters, or more generally speaking, keys that appears in keyboard, can be used as accelerators. Of course I could put "&L"s in translation , but the strings maybe used in elsewhere of the program, how can program do? Translators cannot tell exact accelerators which will be used in actual UI just from a msgid "Name:". Furthermore, think about following: msgid "Name:" msgstr "XXXX(&N):" those items will not pass the msgfmt -C check. KAM is good, only that it should not set accelerators to characters other than ASCII letters, for these characters cannot be PRESSed but INPUTed. For the better support for Japanese, Chinese, Korean, Arabic, and other languages that do not use Latin letter as their alphabet, KAM should not be used, unless it can deal such languages perfectly.
what I was thinking about: what do you think about a (&$) macro that you add to your translations where KAM will replace the &$ with a latin character? &$ is just an example. You're right that we should still use the & to mark msgids where an accel will be used even if KAM is in use.
"Name:" will be used elsewhere within the program, maybe tooltips(Example, please). If we translate it as "XXXX(&$):", what will be displayed in the tooltip? Maybe "XXXX(A):", which was too bad. I think the only way to solve it is to modifying the KAM itself. It will automaticlly insert "(&A)"s to the msgstr if no ASCII characters could be found. Furthermore, it would be better that it can recognize : and ... at the end of the string. That is: msgstr Expected result XXXX XXXX(&A) XXXX: XXXX(&A): XXXX... XXXX(&A)...
Subject: kdelibs/kdecore CVS commit by tokoe: KAccelManager uses now only ASCII characters for accels, so the asian translators can put stuff like msgid "Foobar" msgstr "XXXXXXX (A)" into the po file (with X = non-latin1 character) and KAM will automatically use 'A' as accel. CCMAIL:58647-done@bugs.kde.org M +1 -1 kaccelmanager.cpp 1.28 --- kdelibs/kdecore/kaccelmanager.cpp #1.27:1.28 @@ -581,5 +581,5 @@ int KAccelString::maxWeight(int &index, for (uint pos=0; pos<m_pureText.length(); ++pos) - if (!used.contains(m_pureText[pos].lower())) + if (used.find(m_pureText[pos], 0, FALSE) == -1 && m_pureText[pos].latin1() != 0) if (m_weight[pos] > max) {
No, such an result isn't what I have expected. Following arithmetic might help. accelerators_pool="a..z" ..... If '&' was found then use the character after '&' as the accelerate key remove the character from accelerators_pool else if no Latin characters was found then append "(&%c)", where %c is the first avaliable character in accelerators_pool See comment #5, "Foobar" will be used in elsewhere in the program, "XXXX (A)" is difficult for the user to understand.
but that won't happen for 3.2. At least you don't get wrong accels anymore
OK. Pend it to 3.3 or 4.0.
Although the original bug is 17 years old, it is still relevant. The bug seems to be at least fixed in the QWidgets based applications, but QML based applications seems to have the bug. Attached here is configuration dialog of Dolphin and update dialog of Discover, using QWidgets and QML respectively. In Dolphin's dialog, only the translated message of "Switch between split views panes with tab key" has its accelerator key assigned, as only that item of the configuration dialog has alphabet. All other texts are using 100% Hangul, so no accelerator keys were added. That actually hurts usability but I think this should be discussed in another bug. On the other hand, in Discover's update dialog, accelerator keys are allocated to composed Hangul which could not be used as an accelerator key. Only the translated message of "Plasma Addons" has alphabets in this case. All others are using 100% Hangul, but accelerator keys are nevertheless allocated. This is clearly a bug.
Created attachment 126655 [details] Discover's Korean screenshot, where accelerator keys are misallocated
Created attachment 126656 [details] Dolphin's Korean screenshot, only one accelerator key is allocated but there is no incorrect accelerator keys.
Given that the kdelibs is discontinued, I am going to report a new bug.