User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7) Gecko/20040803 Firefox/0.9.3 Build Identifier: Thunderbird 0.8 branch 20040905 If you're installing an extension into Thunderbird (or Firefox), which provides multiple locales (e.g. en-US and de-DE), the application should register the the correct locale for the extension. The correct locale should be the actual used locale by the core application. Only if the extension does NOT provide the applications actual/"core" locale, we should fall back to another provided locale in the install.rdf. Reproducible: Always Steps to Reproduce: 1. Use an en-US Thunderbird 2. Install the attacht multilingual extension (en-US and de-DE) 3. restart Thunderbird and open the extension manager 4. open the extensions options dialog Actual Results: You'll get an German (de-DE) options dialog instead of an (en-US) English dialog. The extension is registered with the (false) de-DE locale. Expected Results: You should get registered an Englisch (en-US) locale for the extension, because of the applications core locale (en-US). It seems, the extension manager is registering the first locale out of the install.rdf. The applications actual/"core" locale is not used to identify the correct locale for the extension. IMHO this is a pain for users, who are using extensions. And we are propagating the extension feature all over the world....

Test extension for Thunderbird, which provides de-DE and en-US locales.

Mine. There are several manifestations of this bug going around, somehow the "default locale" clause of provider selection is missing some important bits in the chrome registry (although we're still better off than no locale at all being selected, though not by much).

I am not feeling especially charitable towards the command line service these days.

Comment on attachment 159171 [details] [diff] [review] work around the fucking command line service are you sure this does the right thing when |uiLocale| is not null? getter_Copies does not actually assign a value to uiLocale until the getter_Copies destructor runs. (this was an unfortunate result of the string rewrite from earlier this year -- see bug 234908)

Yeah, we shouldn't play ping-pong with regressions. I decided to ignore the rv from GetCmdLineValue since it never returns a meaningful failure code.

Comment on attachment 159252 [details] [diff] [review] Fix scoping but doesn't this change the logic? before: if cmdLineArgs and !uiLocale, we'd try the prefs. now, if cmdLineArgs and !uiLocale, we do nothing. is that what we want?

maybe this instead? if (cmdLineArgs) cmdLineArgs->GetCmdLineValue(UILOCALE_CMD_LINE_ARG, getter_Copies(uiLocale)); if (uiLocale) { useLocalePref = PR_FALSE; mSelectedLocale = uiLocale; } else if (prefs) { ...

Comment on attachment 159315 [details] [diff] [review] Scope and ifs, third time's the charm? r+sr=darin

I found the original reporter's behaviour in the 0.8 milestone of Thunderbird when I installed http://downloads.mozdev.org/mnenhy/mnenhy-0.6.0.104.xpi; Thunderbird in English, Mnenhy in German. Thinking that it might be related to the lack of a locale in Thunderbird's user agent string, I installed the Thunderbird 20040917 nightly, but still had the same problem. Somewhere along the way, I also installed MessageID-Finder 1.9.7, which was also in German. Changing the lines in: C:\WINDOWS\Application Data\Thunderbird\Profiles\xxxxxxxx.default\chrome\chrome.rdf from: <RDF:Seq RDF:about="urn:mozilla:locale:root"> <RDF:li RDF:resource="urn:mozilla:locale:de-AT"/> <RDF:li RDF:resource="urn:mozilla:locale:de-DE"/> <RDF:li RDF:resource="urn:mozilla:locale:en-GB"/> <RDF:li RDF:resource="urn:mozilla:locale:en-US"/> <RDF:li RDF:resource="urn:mozilla:locale:fr-FR"/> <RDF:li RDF:resource="urn:mozilla:locale:it-IT"/> <RDF:li RDF:resource="urn:mozilla:locale:pl-PL"/> </RDF:Seq> to: <RDF:Seq RDF:about="urn:mozilla:locale:root"> <RDF:li RDF:resource="urn:mozilla:locale:en-US"/> <RDF:li RDF:resource="urn:mozilla:locale:de-AT"/> <RDF:li RDF:resource="urn:mozilla:locale:de-DE"/> <RDF:li RDF:resource="urn:mozilla:locale:en-GB"/> <RDF:li RDF:resource="urn:mozilla:locale:fr-FR"/> <RDF:li RDF:resource="urn:mozilla:locale:it-IT"/> <RDF:li RDF:resource="urn:mozilla:locale:pl-PL"/> </RDF:Seq> results in both extensions being in English. Note that I have the same version of the Mnenhy extension installed in Firefox, but never had the problem there. This is with: Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20040913 Firefox/0.10 Mnenhy/0.6.0.104 and: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040917 Thunderbird/0.8 Mnenhy/0.6.0.104

I checked this in with bug 246014 when I merged that onto the trunk, so this patch is aviary-only now.

Comment on attachment 159315 [details] [diff] [review] Scope and ifs, third time's the charm? a=asa for aviary checkin.

Fixed on branch

Unless I badly misunderstood something, the patch does not solve this issue. I just tried the newest nightly build, which according to Burning Edge has this fix: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040922 Firefox/0.10 However, when installing Mouse Gestures 0.9.20040902 (an older version where de-AT is listed before en-US in install.rdf, get it from update.mozilla.org via "other releases" page) into a fresh profile, Firefox still selects de-AT for MozGest. You can see this because MozGest asks "English texts are available, use them?" (Clicking yes won't help, as selectLocaleForPackage was removed. Clicking no and it won't ask again, but stay on de-AT.) Also, if you do some gesture with RMB, you'll see "Mausgeste: ..." in the status bar, which is from the de-AT locale.

Sorry, false alarm! Today's lesson is: *Never* assume that the Burning Edge is accurate! The firefox 20040922 nightly does *not* have the fix. However, the tinderbox builds at ftp://ftp-new.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/sweetlou/ have it, and Firefox indeed selects en-US correctly for the MozGest build mentioned above. Resolving again.

*** Bug 262732 has been marked as a duplicate of this bug. ***

Is this fixed in 1.0? In the latest version of Forecastfox, there have been a lot of reports about it choosing seemingly random locales, when it should choose en-US.