Closed Bug 232907 Opened 21 years ago Closed 20 years ago

profile manager ignores language and locale selected by the user

Categories

(SeaMonkey :: Startup & Profiles, defect)

Product:
SeaMonkey
Component:
Startup & Profiles
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: tsahi_75, Assigned: mkaply)

Details

(Keywords: fixed1.7, intl, l12y)

Attachments

(1 file)

Change the case of the item queries
968 bytes, patch
benjamin
: review+
Details | Diff | Splinter Review 
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$3lf1@ripley.netscape.com
Is it possible to narrow down when this regressed? Even "works in 1.5, not in
1.6a" would be helpful.
it worked in 1.5, i didn't check this on anything between then and 1.6.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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.
(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.
Flags: blocking1.7a?
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).
(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.
Can anyone narrow this down to the nightly build where it broke?
(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.
http://archive.mozilla.org/pub/mozilla/ has a bunch of older builds
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.
(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.
would need a patch to block 1.7a at this point...  renominate if anything shows
up quickly...
Flags: blocking1.7b?
Flags: blocking1.7a?
Flags: blocking1.7a-
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?
bsmedberg,  any ideas on this one?
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.)

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...
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
Ok. I'll take a look, but I'm afraid it'll take some time (because I'm tied up)
Keywords: intl, l12y
Flags: blocking1.7b?
Flags: blocking1.7b-
Flags: blocking1.7?
Flags: blocking1.7? → blocking1.7+
Flags: blocking1.7a-
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.
Assignee: nobody → mkaply
Choice two was to change the data items back but this required more changes.
Attachment #148197 - Flags: review+
Fix checked in trunk and branch. I approved it :)
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed1.7
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: