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 Japanese?

reassign to ftang

Other app like Apple software, IE 5.1, ... switch to the current system language properly.

This needs to be fixed.

adding nsbranch+

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 localization impossible. 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. -> http://bugzilla.mozilla.org/show_bug.cgi?id=44070, "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. cc. danielmc@netscape.com

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 process thought.

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?

removing nsbranch+

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 product.

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 ?

read http://developer.apple.com/techpubs/mac/Toolbox/Toolbox-454.html * 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:// developer.apple.com/techpubs/macosx/Essentials/SystemOverview/International/ index.html>.

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) see CFBundleGetDevelopmentRegion . This api may help us to find out what region the system want the app to run. (assume we provide some bundle) see http://developer.apple.com/techpubs/macosx/CoreFoundation/BundleServices/Bundle_Services/Functions/CFBundleGetD_opmentRegion.html

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.

Two cases, 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: <key>CFBundleDevelopmentRegion</key> <string>fr</string> The language code follows ISO 639-1 Alpha-2 2letter identifier codes. http://www.rtt.org/ISO/TC37/SC2/WG1/639/639-1-FDIS-nochar.html 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?