Take navigator.xul and change a couple of strings to Japanese or to European
extended characters (using Unicode). On Win, all on-screen widgets look good,
on Mac, the menus and any HTML buttons or Menu popups are corrupted.
It looks like MacFE still expects either Shift-JIS or MacRoman, as appropriate.
It should be looking for and displaying Unicode characters.
Logging as XP Misc, although maybe it should be XUL.
Changing component to XPApps.
And assigning to Peter Trudelle. CC-ing L10n & I18n people. Changing to P2
also. Maybe it should be higher.
Setting TFV to M5. You'd think I'd make all these changes in one go, wouldn't
Clearing target milestone and resetting priority to p3. These fields are owned by
engineering, please do not touch them. Also, this should have been filed as three
separate bugs, one for each widget, not lumping everything together. Could you
split it up?
also, the severity of this bug is not critical, which is defined as "crashes,
loss of data, severe memory leak". Reassigning to fergus to split up and refile
with appropriate severities.
Okay. Changing to severity to major. And calling this one the Menu bug.
Others will follow for popup html menus and for html buttons.
Also assigning back to trudelle as split is done.
Peter, Fergus is also an engineer. Priority is high because we cannot pseudo
localize the product if this does not work correctly, and we have a pseudo
localization task for M5 (inherited from M4) that is blocked by this now.
Please, reset this bug, 5438 and 5439 accordingly
Okay, but we may not get to these for M5. Chofmann has dictated that we reduce
our individual bug lists to the top 2 bugs as of next Tuesday. In general,
bugs that affect everyone will be triaged with higher priority than those that
just affect I18N.
reassigning to saari as p2 for m5
Also, when I said 'engineering, I meant only the development team responsible
for fixing the bug. QA professionals are also engineers, but they own the
severities, not the priorities.
So how do I test this, being that I don't run an internationalized OS version?
Saari, try using generic extended characters. é and such like. Be aware,
though, that they need to be entered as UTF8 into the navigator.xul file.
Here's how to produce a UTF8 character on any Mac. Open a new Doc in composer.
Select View>Character Set>UTF-8
Type some extended characters--try using option-a for a 'å'. Save HTML. copy
the strings concerned and their encoding into navigator.xul and watch behaviour.
Note that many widgets work. Menus is one that doesn't.
saari, you can find the Japanese XUL file at the URL mentioned above.
Adding to QA Blocker radar.
and we get fergus over to saari's cube to help on this one?
I can definitely use some help. Everything I've tried so far hasn't had any
On my way to talk to Saari now.
So if anyone has insight on how to fix this, I'd love to hear it...
SetMenuItemTextEncoding is new with Appearance, and takes a script ID, which I
don't have at runtime anyway.
What is the right magic to get the menu manager to do this correctly?
Chris :- If you point me at some code, I can take a look at this and see if we
can get things up and running correctly.
Update: i have this partially working - there is still a problem with
hierarchical menus and Unicode. More later.
Anything I can help with? I can probably figure it out if I see the code that
does the right thing. In other words, is this checked in yet?
Nothing checked in yet. I fixed the problem with hierarchicals, but I'm having
problems with Japanese in the file menu at the moment. I'm going to send mail to
some ex-colleagues at Apple to get some more information.
There may need to be some re-thinking of the mac implementation of the menu code
- we can talk about that later, after I get information back from Apple.
I'll let you know if there is anything I need help with.
Ok, well one change I may check in is setting the menu item text with
SetMenuItemText(). That may help you.
Also, Mac menus arn't dynamic yet, so there will be more substantial changes to
them in the future.
is there enough work done to remove the block status? doing that now.
if this is wrong remark it blocker..
I don't think this can be considered a QA blocker - I don't think it is going to
be technically possible to use Unicode in Mac Menu drawing.
I talked to some ex-coworkers at Apple about ATSUI, the new Menu Manager and
Unicode Menus. According to them, the Menu Manager doesn't use ATSUI and
doesn't support Unicode drawing. The support we will be able to do for Unicode
menus on the Mac is going to be limited.
The code needs to convert the Unicode data into the encoding of the system
Script; however, we won't be able to have Japanese menu's on a US system. The
Unicode data will have to be limited to characters that can be displayed by the
moving to M7
Montse, when do you need to have this fixed?
Saari, do you have enough info now to fix it? I.e. convert from Unicode to
system script, and then pass to menu. If not, can you get the info from Tague,
I know we have calls to do this on Windows, how about Mac? Or should I be using
the OS stuff (is there a Unicode to Shift JIS converter in the OS now?)
Tague and Frank, please comment on whether we should use Mozilla's converters
or Mac converters (from Unicode to system script).
I think in cases like this, it makes much more sense for us to use the platform
encoding converters. Both Frank and I are using the platform encoding
converters in platform specific parts of the code (Frank for ATSUI drawing, me
for key/IME input into Unicode strings).
For purely platform-specific parts of the code, it is much easier to use the
platform encoding converters (if they exist), because they have knowledge about
the kind of conversions that need to be done at that level (system encoding to
Unicode). That knowledge isn't really built into the Mozilla encoding
OK, Saari, please use the Mac converter to convert from Unicode to the system
script. If you don't know how to do this, please contact tague or ftang.
Ok, what API should I be looking at? (sorry, not up to speed on TSM)
Created attachment 309 [details] [diff] [review]
bug fix patch
I have a patch for this which I sent to various Mac people to look at and
approve. I will check this in, once I get approval.
checked in a fix today, 6/2/98 - 5:30pm.
Note: we are only going to support drawing the menu bar (i.e. the menu label) in
the system script. This means that you will only be able to display a Japanese
menu bar on a Japanese system. The actual menu text will be multi-lingual.
Temporarily reopened, so I can reassign to Tague.
I'm doing my anal-rententive management thing and trying to track what bugs
my group is fixing. :-}
Verifyied against June 18 build.
Note that difference between native widgets and macos means that proper display
is only possible under KanjiTalk. JLK isn't enough for once.
What doesn't work on JLK. Just the menu bar or also the menu entries?
We know the menu bar is not multilingual, but do multilingual menu entries
display on JLK?
Just the menu bar. If we go down the route of registering it as JA application
(using language register hooks) then this would be rectified.
the menu items are "mono"-multilingual. any menu item can be displayed in any
macintosh script, but you can't mix two scripts in the same menu item. you can
have Japanese, German, Indic, Chinese menu items in the same XUL file, and they
will be displayed fine, but you couldn't do something like Save as... where
"save" was in Japanese and "as" was in chinese.
The actual menu bar is special. It will only draw in the system script, so you
can only support Japanese or Chinese in the menu bar. This won't work with just
a language kit, unless as fergus mentions, the user uses the lanugage kit
registration application and registers the application as a japanese or a
chinese application. whatever the application is registered as determines what
script can be displayed in the menu bar.
the only way around this limitation is to write a custom MDEF which does Unicode
drawing. that would be incredibly painful and too time consuming.
It's good to clarify what is implemented. Thanks.
The current implementation supports 99.99% of the cases that matter.
The menu bar will normally be mono-lingual for the current localization.
When the Mac app is localized, we should set the language setting appropriately.
And it will be very rare that a single entry (e.g. What's Related, document
title, bookmark) will contain characters from more than one script.
I think there is no reason to do a custom MDEF.