100346 - system dialogs always in English on OS X

Status: RESOLVED INACTIVE

(Core :: Internationalization, defect)

Description

[Ying-Lin Xia]

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.

Comment 1

[Frank Tang]

how about other application? Do other applications show these Dialog in 
Japanese?

Comment 2

[Frank Tang]

reassign to ftang

Comment 3

[Ying-Lin Xia]

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

Comment 4

[Jaime Rodriguez, Jr.]

This needs to be fixed.

Comment 5

[Michele Carlson]

adding nsbranch+

Comment 6

[Ying-Lin Xia]

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?

Comment 7

[tao]

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")

Comment 8

[Michele Carlson]

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. [e-mail]

Comment 9

[Frank Tang]

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. 

Comment 10

[Ying-Lin Xia]

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.

Comment 11

[Ying-Lin Xia]

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?

Comment 12

[Ying-Lin Xia]

removing nsbranch+

Comment 13

[Michele Carlson]

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.

Comment 14

[danielmc]

What did you guys use to Edit the resource in the Binary? OSX Resourcer?

Comment 15

[Ying-Lin Xia]

Use ResEdit or Resourcer on OS 9, to edit the OS X app's rsrc ;-)

Comment 16

[Ying-Lin Xia]

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.

Comment 17

[Frank Tang]

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

Comment 18

[Frank Tang]

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.

Comment 19

[Steve Dagley]

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

Comment 20

[Frank Tang]

maybe this will be solved by providing multiple language bundle on MacOS. 
nhotta, can you take a look at this one ?

Comment 21

[nhottanscp]

It looks to me that system dialogs should be handled by the system. Not sure why
applications have to localize system dialogs.

Comment 22

[Frank Tang]

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

Comment 23

[tao]

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.

Comment 24

[nhottanscp]

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.

Comment 25

[nhottanscp]

Edit Info.plist and adding CFBundleDevelopmentRegion, then the system dialog 
uses that language instead of the global language set by the control panel.

Comment 26

[danielmc]

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

Comment 27

[nhottanscp]

Ying mentioned that this is possible by adding some virtual properties.
Ying what is the bug number? This can be a dup of that.

Comment 28

[Ying-Lin Xia]

http://bugscape.netscape.com/show_bug.cgi?id=10850

Comment 29

[Steve Dagley]

Considering bug's current status removing as a blocker for 102998

Comment 30

[Greg K.]

Should this be moved to the Localization component instead of Browser-General?

Comment 31

[Zibi Braniecki [:zbraniecki][:gandalf]]

This has been fixed by Fluent integration