232907 - profile manager ignores language and locale selected by the user

Status: RESOLVED FIXED

(SeaMonkey :: Startup & Profiles, defect)

Description

[Tsahi Asher]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; he-IL; rv:1.6) Gecko/20040113

profile manager always uses the default language and content pack, regardless of
those selected by the user. e.g. if i install the he-IL language pack and the IL
content pack (which are installed with the same XPI) over the en-US mozilla, and
then select them for use in a new profile, the new profile still uses the en-US
language and US content pack

Reproducible: Always
Steps to Reproduce:
1.install a language pack over the mozilla installer distributed by mozilla.org
2.open profile manager and create a new profile
3.in the second screen of the profile wizard, clich the "select locale" button
and select the language you installed

Actual Results:  
new profile has an en-US interface

Expected Results:  
new profile should be in the language selected during profile creation.

this has been reproted for several languages at n.p.m.l10n, starting at
news://news.mozilla.org:119/buse4o$[e-mail]

Comment 1

[Benjamin Smedberg]

Is it possible to narrow down when this regressed? Even "works in 1.5, not in
1.6a" would be helpful.

Comment 2

[Tsahi Asher]

it worked in 1.5, i didn't check this on anything between then and 1.6.

Comment 3

[Prognathous]

Confirmed.

The user can still switch UI language using Preferences/Appearance, and since a
workaround exists, the Severity of this bug should, IMHO, be set to Normal
rather than Major.

Prog.

Comment 4

[Prognathous]

(In reply to comment #1)
> Is it possible to narrow down when this regressed?

This may not be possible. I can't activate the Hebrew language pack with 1.6b,
even if I use the Preferences/Appearance/Languages panel. The Hebrew/IL entry
appears with "(needs update)".

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208

Prog.

Comment 5

[Michael Wolf]

(In reply to comment #1)
> Is it possible to narrow down when this regressed? Even "works in 1.5, not in
> 1.6a" would be helpful.

For Moz 1.6a it still works, for 1.6b already not. My locale is Sorbian.
Originally I thought it was because the programmers deleted the invalid language
code (sb) in res/language.properties without replacing it by the recent one. But
the same problem occurs with Hebrew and Nynorsk. For both languages there are
language codes in the file res/language properties. Thus, there must be another
cause for this issue.  

Comment 6

[Karl Ove Hufthammer]

Note that the language for new profiles is always identical to the language used
in 'Profile Manager', not necessarily 'en-US'.

E.g., if you install the Hebrew langpack, manually switch to Hebrew for the
interface (using 'Preferences'), and create a new profile using 'Tools | Switch
Profile', Hebrew is used as the language for the new profile (regardless of what
language you select in the profile creation dialogues).

Comment 7

[Michael Wolf]

(In reply to comment #4)
> (In reply to comment #1)
> > Is it possible to narrow down when this regressed?
> 
> This may not be possible. I can't activate the Hebrew language pack with 1.6b,
> even if I use the Preferences/Appearance/Languages panel. The Hebrew/IL entry
> appears with "(needs update)".
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208
> 
> Prog.

Seems that you installed the language pack for Moz 1.6 final into Mozilla 1.6b.
Then the locale version numbers are mixed what causes the (needs update) error.

Comment 8

[Asa Dotzler [:asa]]

Can anyone narrow this down to the nightly build where it broke?

Comment 9

[Michael Wolf]

(In reply to comment #8)
> Can anyone narrow this down to the nightly build where it broke?

I tested the nightly 2003-12-01-09
ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-12-01-09-trunk/

It's the first 1.6b nightly I found a win32-installer.exe for. (or are there
older ones between 1.6a and 1.6b releases from November anywhere?). This nightly
already contains this bug.

Comment 10

[chris hofmann]

http://archive.mozilla.org/pub/mozilla/ has a bunch of older builds

Comment 11

[Michael Wolf]

I tested still another nightly
http://archive.mozilla.org/pub/mozilla/nightly/2003-11-12-12-trunk/
Thanks to Chris Hofmann (comment #10).
The same issue already. 

Then I had anyhow the idea to load the component "locale.xpt" from the
components folder into a text editor. I did this for my 1.6a, 1.6b and 1.6final
installations. The locale.xpt is a binary file, but there are relevent strings
legible; Ithink they are functions: *NewLocale, NewLocaleObject,
GetSystemLocale, GetApplicationLocale, GetLocaleFromAcceptLanguage* and so on.
And here is a difference between 1.6a on the one hand and 1.6b and 1.6 final on
the other hand: In Mozilla 1.6 these function(?)names have an upper-case first
character, in moz 1.6b and 1.6 final there is a lower-case character.
I know thio issue from the Calendar where is in the datapicker file calendar.xml
appeare the same issue: Anybody changed the first character from upper-case
GetApplicationLocale to getApplicationLocale or vice-versa (I don't more exactly
what is the current orthography). A similar issue seems to be here. Anyhow there
is e.g. *NewLocale* expected but Mozilla finds *newLocale* only.

Comment 12

[Michael Wolf]

(In reply to comment #11)
> I tested still another nightly
> http://archive.mozilla.org/pub/mozilla/nightly/2003-11-12-12-trunk/
> Thanks to Chris Hofmann (comment #10).
> The same issue already. 
> 
> Then I had anyhow the idea to load the component "locale.xpt" from the
> components folder into a text editor. I did this for my 1.6a, 1.6b and 1.6final
> installations. The locale.xpt is a binary file, but there are relevent strings
> legible; Ithink they are functions: *NewLocale, NewLocaleObject,
> GetSystemLocale, GetApplicationLocale, GetLocaleFromAcceptLanguage* and so on.
> And here is a difference between 1.6a on the one hand and 1.6b and 1.6 final on
> the other hand: In Mozilla 1.6 these function(?)names have an upper-case first

It must be here Mozilla 1.6a, of course. Sorry for the forgotten character. 

character, in moz 1.6b and 1.6 final there is a lower-case character.
> I know thio issue from the Calendar where is in the datapicker file calendar.xml
> appeare the same issue: Anybody changed the first character from upper-case
> GetApplicationLocale to getApplicationLocale or vice-versa (I don't more exactly
> what is the current orthography). A similar issue seems to be here. Anyhow there
> is e.g. *NewLocale* expected but Mozilla finds *newLocale* only.

Comment 13

[chris hofmann]

would need a patch to block 1.7a at this point...  renominate if anything shows
up quickly...

Comment 14

[Michael Wolf]

I want to ask what's the state of fixing for this bug? I've just downloaded
nightly 2004030509 and saw that the bug isn't fixed yet. After creating a new
profile for a language other than English the UI still starts in English, not in
the desired language. Is the suggestion about the cause of this bug, I uttered
in additional comment #11, right?

Comment 15

[chris hofmann]

bsmedberg,  any ideas on this one?

Comment 16

[Benjamin Smedberg]

No, unfortunately not. Although I have an up-to-date debug build, so I might be
able to poke in a debugger. I'm afraid this may have broken as long ago as the
profile-manager rewrite. I looked through possible checkins to the chrome
registry(ies) and there was nothing that looked especially dangerous.

The default locale is supposed to be set here:
http://lxr.mozilla.org/mozilla/source/profile/src/nsProfile.cpp#1724

Which is called from here:
http://lxr.mozilla.org/mozilla/source/profile/resources/content/createProfileWizard.js#212

(Michael, comment #11 is totally off-base, OS locales and localization are
totally different beasts.)

Comment 17

[chris hofmann]

jshin,  can you also help look at this.  trying to come up with ideas on how it
might have broken in 1.6 alpha...   saw this bug that might be related...

Comment 18

[chris hofmann]

jshin,  can you also help look at this.  trying to come up with ideas on how it
might have broken in 1.6 alpha...   saw this bug that might be related...
http://bugzilla.mozilla.org/show_bug.cgi?id=195093

Comment 19

[Jungshik Shin]

Ok. I'll take a look, but I'm afraid it'll take some time (because I'm tied up)

Comment 20

[Mike Kaply [:mkaply]]

This was a simple case problem.

When the profilemanager was reported, the data element in the XUL was changed to
profileRegion and profileLanguage, but they forgot to change the file selectLang.js.

Patch coming.

Comment 21

[Mike Kaply [:mkaply]]

Attachment: Change the case of the item queries

Choice two was to change the data items back but this required more changes.

Comment 22

[Mike Kaply [:mkaply]]

Fix checked in trunk and branch. I approved it :)