54998 - RFE: UI language switching by command line option

Status: VERIFIED FIXED

(Core :: Internationalization, enhancement, P3)

Description

[Masaki Katakai]

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.

Comment 1

[Karl Ove Hufthammer]

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.

Comment 2

[nhottanscp]

Reassign to tao.

Comment 3

[tao]

Chrome registry -> hyatt.

Also CC dveditz.

Comment 4

[Masaki Katakai]

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

Comment 5

[tao]

How about your group come up w/ a plan of implementing thte command line switch
and have hyatt review it?

Comment 6

[Masaki Katakai]

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?

Comment 7

[Masaki Katakai]

Attachment: patch for nsProfile.cpp

Comment 8

[Daniel Veditz [:dveditz]]

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

Comment 9

[Masaki Katakai]

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.

Comment 10

[tao]

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.

Comment 11

[Masaki Katakai]

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.

Comment 12

[tao]

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.

Comment 13

[John Vandenberg]

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.

Comment 14

[tao]

Interesting idea...

If the wrapper script is what users run to invoke Mozilla, wouldn't this proposal
disable all locale switching functions?

Comment 15

[John Vandenberg]

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

Comment 16

[Masaki Katakai]

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

Comment 17

[tao]

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

Comment 18

[John Vandenberg]

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.

Comment 19

[Masaki Katakai]

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.

Comment 20

[Linda Baliman]

Added keywords intl, nsbeta1

This bug is potential showstopper for Sun

Comment 21

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 22

[Peter Trudelle]

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.

Comment 23

[Linda Baliman]

Sun has downgraded this bug from "potential showstopper" to "not a showstopper"

Comment 24

[David Hyatt]

Then pushing it off.

Comment 25

[Linda Baliman]

P1 bug for Sun;  setting Priority to P1

Comment 26

[Daniel Veditz [:dveditz]]

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.

Comment 27

[Peter Trudelle]

Linda, is mozilla1.1 target for this enhancement acceptable to Sun?   If not,
please help us understand when you need it, and why.

Comment 28

[Masaki Katakai]

Attachment: proposed patch

Comment 29

[Masaki Katakai]

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.

Comment 30

[John Vandenberg]

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

Comment 31

[Masaki Katakai]

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

Comment 32

[tao]

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.

Comment 33

[Frank Tang]

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 ?

Comment 34

[David Hyatt]

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.

Comment 35

[tao]

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?

Comment 36

[Masaki Katakai]

Attachment: adding -lang option in usage (nsAppRunner.cpp), please review this too

Comment 37

[Masaki Katakai]

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

Comment 38

[tao]

OK, I'll get it in asap.

Comment 39

[tao]

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

Comment 40

[Masaki Katakai]

patch has been checked in. marked as FIXED.

Comment 41

[Masaki Katakai]

unable to verify this fix on nightly because of bug 76006.
I'll try to verify after the bug is fixed.

Comment 42

[Masaki Katakai]

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.

Comment 43

[Masaki Katakai]

I filed new bug 80230 for region issue.