Switch OS X to another language, say Japanese, all system dialogs like
Open/Save/Print/... are not in Japanese. Bug 95478 may related. But it's more
serious here, cause we can not localize the current build to other languages.
how about other application? Do other applications show these Dialog in
reassign to ftang
Other app like Apple software, IE 5.1, ... switch to the current system
This needs to be fixed.
Comparing with other app on OS X, Apple app and IE, our current build can not
support OS X multi-language feature like others do. Our problems are:
1) As this bug originally reported, all system dialogs like Open/Save/Print/...
are always in English, no matter to switch to what language. This makes us
2) Another thing is, all other app including IE, once you switch the system
language, their UI will be in that language automatically, ie, all
menu/dialog/message will be in Japanese, French, ... whatever system language
you choose. All our UI (not the system dialog mentioned above) are always in
one language. Should we file another bug for this issue?
The problems are:
1. Mozilla's locale should defautl to the system's locale. ->
"Match browser's default locale/region to OS's default"
2. Mozilla does not listen to the system notification of locale (language) change
3. Mozilla can not switch (locale) chrome providers on the fly yet ->
(http://bugzilla.mozilla.org/show_bug.cgi?id=62174 "Dynamic locale switching")
Frank/Tao - is it going to be possible to provide a fix for this in the emojo
timeframe? If not, we really have to ask ourselves if we want to ship Mac OS X
localized products or not.
ok, I work with yxia and find out a solution. The solution only to got involved
in the localization process.
we need to change the language id inside the 'vers' resource (there are two ID
of them, we need both) of "Netscape 6" from USA to Japan (or other language).
The System dialog is display depend on that value. If the vaule is English, it
will display as English, if the value is Japan, it will display as Japanese.
reassign this bug back to yxia.
We don't need C++/C code change. We do need manual tweak in the localization
This means we have to touch the binary for localization. We can live with it
for the current release, but please consider possible fix for it.
For Mac OS 8/9, we didn't touch the binary for localization.
Another case is, if user is using US build and then installed Japanese language
pack, the user still can not see those dialogs in Japanese. Should I reassign
it back to you for future fix, Frank?
Ying will fix this in the JA localized build this time. Danielmc - make sure
this is fixed in your euro builds too. Next time, we'd like it fixed in the core
What did you guys use to Edit the resource in the Binary? OSX Resourcer?
Use ResEdit or Resourcer on OS 9, to edit the OS X app's rsrc ;-)
Frank, I can change the language id for Japanese release, I have same bugs in
bugscape, but I can not do anything for this bug now. Reassign this to you for
a future possible core fix. Again, for now, if user use US build on JA OS X,
they still see English dialogs. This is nothing about localization.
>This means we have to touch the binary for localization. We can live with it
>for the current release, but please consider possible fix for it.
resource fork in the Mac is not consider "binary" by Apple's standard
All other mac app localize by changing resource fork. This is not defined by
Netscape, but by Apple. Unless Apple change that story, we can do nothing.
>For Mac OS 8/9, we didn't touch the binary for localization.
You should, other wise, copy and paste won't work. Many other feature will be
broken. Setting 'vers' resource correctly is an Apple Macintosh standard, all
our system integration is depend on that value. Language pack and Script system
heavily depend on that value. Again, this is a system integration issue, it is
not defiend by Netscape, but defined by Apple.
>Another case is, if user is using US build and then installed Japanese language
>pack, the user still can not see those dialogs in Japanese. Should I reassign
>it back to you for future fix, Frank?
then user have to register it by using the language registration application
came with LAnguage Kit
>Use ResEdit or Resourcer on OS 9, to edit the OS X app's rsrc ;-)
Any tool which can change resource should be fine. How about MPW ?
* Region code. This identifies the script system for which this version of the
software is intended. See the chapter "Script Manager" in Inside Macintosh: Text
for information about the values represented by the various region codes that
can be specified here.
Actually a more up to date reference for doing this under OS X can be found in
the Mac OS X System Overview <http://developer.apple.com/techpubs/macosx/
Essentials/SystemOverview/index.html>. The specific sections of interest are
Application Packaging <http://developer.apple.com/techpubs/macosx/Essentials/
SystemOverview/AppPackaging/index.html> and Internationalizing Your App <http://
maybe this will be solved by providing multiple language bundle on MacOS.
nhotta, can you take a look at this one ?
It looks to me that system dialogs should be handled by the system. Not sure why
applications have to localize system dialogs.
The problem is we need to sync the sys dialog with our language pack (or sync
our language pack with the user prefere language)
CFBundleGetDevelopmentRegion . This api may help us to find out what region the
system want the app to run. (assume we provide some bundle)
My taking is to use the system locale as a reference to default settings of the
client's UI language and regional content. Users can choose not to follow the
system's default. We need to investigate how this change would affect the
application's locale, though.
1) At mozilla locale switch, notify the change to system.
2) Mozilla to switch locale according to the system locale preference.
Also need to investigate if we want to do runtime or requiring the app restart.
Edit Info.plist and adding CFBundleDevelopmentRegion, then the system dialog
uses that language instead of the global language set by the control panel.
Use this format:
The language code follows ISO 639-1 Alpha-2 2letter identifier codes.
Be sure not to place these strings in the middle of another key sequence....
Ying mentioned that this is possible by adding some virtual properties.
Ying what is the bug number? This can be a dup of that.
Considering bug's current status removing as a blocker for 102998
Should this be moved to the Localization component instead of Browser-General?