Closed Bug 54998 Opened 24 years ago Closed 24 years ago

RFE: UI language switching by command line option

Categories

(Core :: Internationalization, enhancement, P3)

All
Linux
enhancement

Tracking

()

VERIFIED FIXED
mozilla1.1alpha

People

(Reporter: masaki.katakai, Assigned: masaki.katakai)

References

Details

(Keywords: intl, relnote)

Attachments

(3 files)

As I posted a question to mozilla-unix and mozilla-i18n, we need a solution that UI language switching at startup time by command line option like, % mozilla -locale ja-JP When we bundle Netscape6 with Solaris, we provide language packs with Netscape6, then Netscape6 should be started automatically with proper UI language of user's desktop locale as well as other applications. We need to keep the consistency of desktop on UNIX platform. Normally UI language can be switched by $LANG and $LC_ALL environment variable. Also UI language can be selected on login screen. I believe most users expect this behavior on UNIX platform, and UNIX distributors also expect it.
Windows can also give information on which locale is used. But we'll need a mapping table between the language codes Windows/Unix returns, and the language packs in Mozilla.
Reassign to tao.
Assignee: nhotta → tao
Chrome registry -> hyatt. Also CC dveditz.
Assignee: tao → hyatt
David, Do you think it's possible to fix for RTM? If not possible, can we suggest the workaround below to UNIX/Linux distributors at RTM? Any suggestion? This is a reasonable workaround, 1) Prepare rdf files for each language user-locales.rdf.ja (contains ...:ja-JP:...) user-locales.rdf.ko (contains ...:ko-KR:...) user-locales.rdf.C (contains ...:en-US:...) ... 2) Prepare wrapped script, which will do if ~/.mozilla does not exit create ~/.mozilla/default/ copy user-locales.rdf.$LANGUAGE to ~/.mozilla/default/chrome/user-locales.rdf fi 3) the wrapped script start mozilla script
How about your group come up w/ a plan of implementing thte command line switch and have hyatt review it?
Unfortunately I found the workaround would not work. See AddLevelOfIndirection() in nsProfile.cpp. http://lxr.mozilla.org/mozilla/source/profile/src/nsProfile.cpp#994 It seems that it's not possible to guess the exact profile directory from shell script. Is there any reasonable workaround for MN6? Most enduser will be confused because UI language is English at first startup even when his/her desktop locale is not English. Enduser expects UI language is the same with desktop. I will attach the simplest patch for nsProfile.cpp. "-locale" argument will call SelectLocaleForProfile() when, - -locale option is specified, and - without profileManager User can choose the locale on it - will not touch existing profile User might have configured his/her language This works fine for me. When ~/.netscape exists, the migration of 4.x is done then user-locales.rdf is installed for the locale properly. When ~/.netscape does not exist, new profile directory is created and user-locales.rdf is installed properly. However, I don't think it's sufficient patch because I didn't touch other codes around handling of command line options, e.g. -help. I didn't check the specified language pack is installed or not. Also I'm not sure the behavior of -locale option is proper or not for end users. Any suggestion and help?
Attached patch patch for nsProfile.cpp (deleted) — Splinter Review
Why is the default language English? In a Japanese distribution make sure the *Japanese* langpack is installed first by reordering the installer's config.ini
Hi, Daniel. Thanks for comments. When Linux/UNIX distributors ship Mozilla and language packs in their distributions, Mozilla is normally installed under /usr/local, /usr/share or /opt, which is system directory and will be shared among various users. The users may use English of course. Also someone wants Japanese, the others may want Korean and Chinese. When a user starts his/her desktop in Japanese locale, the user expects Mozilla with Japanese. However, other user logs into the same machine and starts desktop in Korean, the user wants Korean messages. So even if the distribution is for Japanese, Linux/UNIX distributors should not decide and fix the UI language of Mozilla installed under system directory, which is not for specific user and specific language. That's difference from Windows and Mac. NS4.x uses X resource to switch UI language, so UI can be switched for users at runtime. So this problem does not happen. However, Mozilla has own selection, which will not pick up proper locale of desktop automatically. To switch to Japanese UI language, users need to choose View->Language and Contents->Japanese and need to start Mozilla again. Or start Mozilla with -profileManager command line option and need to select Japanese. It would be very painful for endusers and I believe it makes bad impression on many NS4.x users.
Hi, Masaki-san: The proposed patch, (attachment 18362 [details] [diff] [review]) sets (default) user profile locale instead of the global start up locale. It is a valid workaround for your first patch (in the Description field). You may need to get review from racham first to see if the proposed code change in nsProfile.cpp is in the right place and commandline option handling is valid. I can review the SelectLocaleForProfile() part. A better solution might be overriding the global locale w/ commandline switch.
Hi Tao-san, thank you for suggestion. I think we need to decide the spec of -locale option, also name '-locale' itself. I'm not sure why we should change global locale here. What will happen when we override the global locale here? user-locales.rdf of MOZILLA_BIN/chrome will be updated? What will happen when the user does not have write permission to MOZILLA_BIN? We can not use the workaround that preparing user-locales.rdf and copying it to user's profile directory because as I mentioned, it's not possible to guess the user's profile dir outside of Mozilla.
What I meant was to let the command switch take precedence over the global locale before user profile locale is loaded. You are right that Mozilla might not have write permission to the global install directory. IMO, you should be able to pass the command line switch to chrome registry's initialization code and determine when to use the indicated locale. You might want to check if such locale is installed.
Hi all, I like the idea of a -locale switch which over-rides the global locale, however I think it should also over ride any user profile locale as well. Thus when a user changes $LANG, the mozilla wrapper can use the -locale switch to ensure the locale mozilla chooses will be (if possible) $LANG. This is then a separate issue from that of profile creation/managing.
Interesting idea... If the wrapper script is what users run to invoke Mozilla, wouldn't this proposal disable all locale switching functions?
The idea of this was to make the -locale option able to use the users exising profile whilst overriding the user-locale.rdf It seems awkward for the user- locales.rdf to over-ride the option, as that would limit its usefulness as the profile would over-ride in all cases except when no profile exists. I was intending to use it in a similar fashion to Masaki, if ~/.mozilla does not exit mozilla-bin -locale $parsed_lang # if this over-rides global, it should create a profile with specified locale # and present any profile creation dialogs in the specified locale else mozilla-bin $1-$9 # allows the user to specify -locale [langcode], over-riding profile fi
Blocks: 60916
Hi John, thanks for comments. I'm still finding the correct behavior of '-locale' option. Actually just '-locale' option would give the impression that the existing profile will be updated. My first patch is only for creation time of new profile. Setting the global locale to the specified locale would be good since profileManager will be invoked in the specified language. However, in Linux, when Mozilla is installed under system directory, there would be a case that user can not access (overwrite) the rdf of Mozilla directory. The overwriting the global locale would be failed in that case. Even when user specify -locale option, the profileManager would be invoked in still English. When user installed Mozilla into user's directory, then profileManager would be invoked in the specified language. There is no consistency. I have no idea now how we handle the case. It would be better that we're thinking about switching skin also, e.g. '-theme' option. What is the best behavior of -locale and -theme options? Setting global locale is failed when Mozilla is installed in system directory, which makes things more complex. I'm not sure it would be right direction or not, but can we create 'global' profile under user's directory first? 1) Create 'global' profile under ~/.mozilla the exact profile of Mozilla dir will be copied to the 'global' profile 2) When -locale or -theme option is specified, set the locale and the theme to 'global' profile 3) profileManager will be invoked with the 'global' profile Even when the user doesn't have a permission of Mozilla directory, this will be succeeded, will be able to switch locale and theme. 4) Create the exact profile by default, or by the profileManager
The original request of this feature is to enforce the start-up locale so the profile manager or the default profile will use the locale from command line. Overriding either the global locale or user profile locale persistently seems overdone to me. Also, as Masaki-san pointed out, the user might not have write permission to the global installation directory/folder. As to the user profile locale, I think we should honor it since its the user's conscious decision. my 2c
I am not as familiar with the code as I should be, but my idea was based on the ability to change the global locale in memory, without modifying any 'global' preferences which would then affect other users (if they have have no profile). I suppose I see the -locale and -theme to be over-rides, changing the current instances behaviour without altering the configuration. This seems consistent with most unix programs where a config file is over-riden by command line switches. The other option is to make the global rdfs user-writable. As the user profile over rides global preferences, this makes ProfileManager language selectable within a startup script, by having alternatives available.
Yes, as John mentioned, if we could overwrite global locale in memory without modifying the exact files, profileManager would be invoked with the specified language and skin. Is this feature already provided? or will fixes for bug 42184 and bug 41057 provide the feature? Hyatt, any comments? If not, for example, we need to prepare 'global' profile in writable directory and use it for profileManager. However, the 'global' should be hidden for user, should not be shown in profileManager.
Added keywords intl, nsbeta1 This bug is potential showstopper for Sun
Keywords: intl, nsbeta1
Changed QA contact to katakai@japan.sun.com.
QA Contact: teruko → katakai
Is this really a show-stopper? If so, hyatt could supply chrome registry api that will allow you to override the selected locale in memory only.
Target Milestone: --- → mozilla0.9.1
Sun has downgraded this bug from "potential showstopper" to "not a showstopper"
Then pushing it off.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla1.1
P1 bug for Sun; setting Priority to P1
Priority: P3 → P1
Priority: P1 → P3
The priority and milestone fields are for engineers and their managers to schedule things. They should not be changed by others. If you disagree with a setting your Open Source recourse is to put up a convincing argument or to find someone else to do it. As a Netscaper you have the additional recourse of having your manager fight it out with the engineer's manager, but ultimately the Assignee is the one who will change the priority.
Linda, is mozilla1.1 target for this enhancement acceptable to Sun? If not, please help us understand when you need it, and why.
Attached patch proposed patch (deleted) — Splinter Review
Dear Profile, i18n/l10n experts, I've attached the patch and want you to review it. The basic idea is, - -lang option (need better option name) will overwrite the global locale (if MOZ_BIN/chrome/user-locales.rdf is writable) profileManager will be brought up with the specified language - Mozilla will be brought up with any profile (existing, newly created) with the specified language *unless* user selects language on profileManager Only when users select language on profileManager, the language will be used, -lang is ignored. For example, if profile "test" is now existing and English, but "mozilla -lang ja-JP -P test" will invoke Mozilla with ja-JP. When user selects a profile at "mozilla -lang ja-JP -profileManager", the profile will be changed to "ja-JP". However, when user selects language and region on ProfileManager, the language will be used instead of -lang option. This enhancement is very important for UNIX distributors. They should support multi user and multi language environment. So Mozilla should be installed in system directory to be shared (but not writable) also should not determine the default language. The language of UI usually follows the desktop language that user selected at login. 4.x supports this switching by X resource file but Mozilla does not support yet. To switch the UI language, there are two ways now, - start Mozilla, Select View-Languages and Web Contents Menu,restart Mozilla - start Mozilla with -profileManager option, create new profile, select language for the profile But these would not be acceptable by endusers.
> - -lang option (need better option name) will overwrite the global locale > (if MOZ_BIN/chrome/user-locales.rdf is writable) Does this mean that MOZ_BIN/chrome/user-locales.rdf must be writable for -lang to work _at all_?? If so it is less desirable for distributers and system admins; an issue that has already been raised. Or does it mean that -lang will only over-write/update the global locale if it is writable? This would then be an administration only concern, and distinct from this bug, but I dont see why an -option should ever write a preference to disk.
> Or does it mean that -lang will only over-write/update the global locale > if it is writable? Yes, when Mozilla is installed under user directory (by XPInstall or by unzip) and writable, this option will overwrite the global locale so that profileManager also should run in the specified language. > This would then be an administration only concern, and distinct > from this bug Yes, so if it's not writable, profileManager will not start in the specified language and it's limitation now.
Hi, Masaki-san: I tried the patch. Here is what I found: When "-lang foo" is used, both the global locale, "($MOZ_BIN}/chrome/user-locales.rdf", and the selected user profile locale are set to "foo". For network installation, this behavior might cause a "locale war" as mentioned earlier. For personal installation or unwritable global locale, this might be OK. However, end users need to know that his profile locale will be overridden to "foo": a release note material if we go for this patch. A (preferrable) alternative is to play the voodoo in the chrome url conversion code in nsChromeRegistry.cpp and use the switch in runtime only. Neither the global locale nor existing profile locale would be overwritten. My 2 cents.
Is that possible that we can solve this problem by moving the locale switching code into a small seperate command line. And that application simply perform whatever we do as we change the Viwe:Language menu and quit. And Sun can call that small program in the .cshrc everytime user login or switch locale ?
The patch only mucks with the profile settings, which seems ok. It does use the API that saves the settings though, which seems ok too, as long as the user knows that this is going on.
Hi, Masaki-san: Looks like you got (r=tao,sr=hyatt) for the patch. How do you like to take this bug over if you wanna stick w/ the patch?
Hi Tao and Hyatt, thank you very much for review and comments. I added the diff for --help option. I want to take this but I don't still have checkin privilege (bug 71137). So Tao-san, could you please take this over??
Blocks: 73732
OK, I'll get it in asap.
Assignee: hyatt → tao
Status: ASSIGNED → NEW
patch checked in for masaki-san. Reassign to him. Also, add "relnote" keyword. Please add such info to the release note: When "-lang foo" is used, both the global locale, "($MOZ_BIN}/chrome/user-locales.rdf", and the selected user profile locale are set to "foo". For network installation, this behavior might cause the global locale to be overwritten to different locales from time to time. In the worst case, the result is a "racing condition" on the global locale if multiple users attempt to overwrite it at the same time. For personal installation or unwritable global locale, this might be OK. In addition, end users need to know that his profile locale will be overridden to "foo":
Assignee: tao → katakai
Keywords: relnote
patch has been checked in. marked as FIXED.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
unable to verify this fix on nightly because of bug 76006. I'll try to verify after the bug is fixed.
Mark this as VERFIED. I (and many japanese users who tried 0.9 and Japanese Language Pack) have verified the fix on 0.9 with Japanese language pack (tmp available in www.mozilla.gr.jp). mozilla -lang ja-JP will start with japanese UI messages. However, I found global-region is still "US", <NS1707:selectedLocale resource="urn:mozilla:locale:US:global-region"/> I think this should also be "JP". I'll file new bug for this.
Status: RESOLVED → VERIFIED
I filed new bug 80230 for region issue.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: