We found out access key in menu is not XP. In Windows, the menu "File" with access key (F) is displayed as "File" with a underline at "F" in EN and "XXXX(F)" a underline at "F" in JA where XXXX is Japanese "File". This is only true for Windows and Unix but not for MAC. There is NO access key in MAC. In MAC, the UI is just "File" and "XXXX". So, we need to seperate access key entities into a platform dependent dtd for different UI. Those platform specific UI resources shall be placed platform specific directoires which are win, mac, unix. Please see global\resources\locale for detail.
Reassign QA to myself.
I don't understand what needs to be done. Access keys are ignored on the mac so there is no reason not to have them since it makes development life easier. We already have platform specific chrome for things like Quit which differ across platforms.
Summary: Access key in menu is not XP → Menu labels in DTD files are not XP for Japanese
I should say navigator.dtd is XP for EN but not for JA or some other languages. Because the UI difference of access key for EN which is underline has done by the codes, the menu labels are the same across the platforms. But the menu labels for JA are different for MAC and Windows. Unless there are items different across platforms for EN, it may not make sense to have the same navigator.dtd file in three directories. This may be fixed on L10N side to keep a different copy of navigator.dtd for MAC and replace it in the packaging. We have to discuss more about this to see which way is the best. I change the summary to "Menu labels in DTD files are not XP for Japanese.".
I do not understand the problem here either. I would really like to know the problem clearly before any changes are made to the way we are handling the dtd files and platform issues for dtd.
Okay, let me try to explain the Mac-specific, JA-specific problem as it stands. I'll do this platform by platform by way of one particular string. We'll stick with 'File', and I'll use '_F_' to indicate the access key. Win EN = _F_ile X EN = _F_ile Mac EN = File Access key is ignored. So, in EN we can use the same DTD files across all platforms, safe in the knowledge the Mac will simply ignore the Access key. In Japanese, the word for 'File' is obviously different--it's a few double-byte kanji characters. For the sake of argument, we'll pretend the JA word is XXXX. However, we don't mess around with access keys, and 'F' remains the access key in JA. How do we indicate this to the JA user? We add the an indication of the access key to the end of the string, making it 'XXXX (_F_)'. That is to say, we change the menu label to show the 'F' character. Remember the 'F' character is not present in the JA string ('XXXX') so there's no other way to indicate it. This is absolutely standard practice when localizing JA Win and X. We're still attempting to use the same strings and DTD files across all platforms. It's essential that we do this. So our new table is like this: Win JA = XXXX (_F_) X JA = XXXX (_F_) Mac JA = XXXX (_F_) <-- This is the problem. Because the '(_F_)' is part of the menu label (remember, the JA user needs to know what access key can be used) it displays in Mac menus. Of course, the functionality is disabled, as is right and proper on Mac, but this means there is a mismatch between what is displayed and what can be done. We show the access keys, but they can't be used on Mac and look ridiculous. I'm hoping my explanation is clear. We have a range of options for solving the problem. Here are just a few of them: 1.Mac displays Menus as MenuItem (F) even though the accelerator key doesn't work on Mac. This is very ugly. 2.Mac displays Menus as MenuItem (F) and we try to make the accelerator keys work on Mac. This is not very Mac-like and so is ugly. 3.Mac gets clever and hides (_F_) the same way as it hides any indication of the shortcut key in EN. This means the appendage ' (F)' has to be removed at runtime. 4.Win and Unix lose their (F) indications. Not an option, I think. 5.In JA Win and Unix, the Access key is added dynamically to the end of the string, in the established form of ' (F)'. In ways, this might be the best option, but would require some 'iflocale=JA' coding.
I suggest we meet to talk this over in person. Can we get interested parties to attend a meeting? rchen or fergus would you like to setup a meeting with those that need to be there? Please include me.
Should invite the menu widget person also. I believe Saari is doing all the menu work although for XPMenus it might be hyatt. As far as I am concerned 3+5 are the only acceptable alternatives and they are the same except for wether the mac or windows implementations do the work. I vote for 5 because it tends to be easier to concate strings together rather than to break them up.
Will invite Saari.
I like the concatenation solution, too. It is reasonable if the access key letter is not in the label string, the access key letter is appended to the end of the label inside a bracket. This is true for all the non-Roman languages like Chinese, Japanese, and Korean applications on Windows and Unix. There is no need to have 'iflocale=JA' coding. The logic is: On Windows and Unix codes, add the following code: If the label doesn't contain the access key letter, then append the access key letter with with brackets to the end of label in run time. MAC will ignore access key and do nothings about access key.
After a discussion with shaver, another approach to this is to put the full string in the language specific DTDs. Then I can have the Mac code strip the characters out based on this heuristic ...endofstring(<accesskey>)" becomes endofstring" Is that ok with everyone?
Hi Christ, if concatenation solution is not so difficult, we still prefer concatenation. Because it is more logical to do that way, not the other way around. Think about this: if you specify a key letter for a menu labe which doesn't contain that letter, how do you tell user to use the access key? It is more than a localization issue, right? If the situation happens in a Roman language application, it is most likely an error caused by the wrong key letter. It can help QA to find it, too.
This is not a mac only issue. There are no guarantee all the menu text in any platform will use a access key which is part of the menu text, right ? If you really want to do striping (XXX) in the end, then please becareful and do it in the PRUnichar space instead in the char* space since ( and ) may be a 2nd byte of a 2 bytes characters in char* space.
Hi Christ, can you point out where the code is? I may be able to add the code and give it back to you for review and submit, if you don't have time to do it. Thanks.
Sorry Chris, wrong spelling.
mass-moving all m12 bugs to m13
This bug needs to be fixed before beta1. Chris, if you need any help from me. Please let me know.
rchen, how about you do the work here?
Chris, Please let me know which files and methods are related to this issue. I will do it on my side and give it back to you for review and submit.
I believe the code you need to look at lives in nsTitledButtonFrame.cpp. Look at UpdateAccessUnderline and mAccesskeyIndex. shaver wrote this code, so he is the best person to ask questions about it.
moving to m14
Hi Chris, I have done a piece of code. It seems working fine with me. I would like to give it to you and check in before M13 tree close.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
rchen checked this in today, so I'm marking as fixed.
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
This has a bug. - Step 1. Install Japanese Pack of M13 (2000011908) (http://www.nmt.ne.jp/~rwreki24/chrome/PR/m13-jlp-over1.zip) 2. Select [File] (Japanese is ¥Õ¥¡¥¤¥ë(F)) - Result [Opne File...] becomes [¥Õ¥¡¥¤¥ë¤ò³«¤¯...(O)]. This is incorrect. This should be [¥Õ¥¡¥¤¥ë¤ò³«¤¯(O)...]. [...] should be before accelarater key.
Status: RESOLVED → REOPENED
Clearing the resolution "fixed" since m_kato makes an excellent point. On Win and Unix, we should ignore the final ellipsis character and append the command key in front of it, rather than after it. This has been the accepted practice in all Japanese applications I have seen so far including our own 4.x products.
Resolution: FIXED → ---
Good catch! I will fix it. It's too late for M13. Will be in M14. I will fix it like: If there are ellipsis characters at the end, the access key character will be put before ellipsis characters. Any comments?
rchen, I'm reassigning this to you
Assignee: saari → rchen
Status: REOPENED → NEW
Should be in beta1
Putting on PDT+ radar for beta1.
Have the code fixed. Waitinng for check in.
checkin the fix.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: rchen → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.