Closed Bug 14110 Opened 25 years ago Closed 25 years ago

Menu labels in DTD files are not XP for Japanese

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: rchen, Assigned: rchen)

References

Details

(Whiteboard: [PDT+]) 

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.
Blocks: 12394
QA Contact: ckritzer → rchen
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.
Assignee: davidm → saari
reassign
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.
Status: NEW → ASSIGNED
Target Milestone: M12
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.
Target Milestone: M13 → M14
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: 25 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
Status: NEW → ASSIGNED
Should be in beta1
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Have the code fixed. Waitinng for check in.
checkin the fix.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Verified.
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.