235058 - Content/language switching from UI is broken

Status: VERIFIED FIXED

(Core :: Internationalization: Localization, defect)

Description

[Robert Kaiser]

Since somewhere in the 1.7a development cycle, switching locale packs (content
packs / language packs) from the Appearance > Language / Content pref panel is
broken.
There is no working UI now for activating an installed L10n XPI pack. You have
to manually change selectedLocale lines in your profile's chrome.rdf for now.

I saw this in my trunk CVS build and a current nightly on Linux, Asa verified it
in a 1.7a candidate build.

Comment 1

[Robert Kaiser]

The workaround for getting it to work in the broken build in more detail:

Install the L10n pack (XPI file). Try to change language / content from the pref
panel. It seems to have no effect. Now:

1) Close Mozilla, including Quick Start.
2) Open chrome/chrome.rdf of your user profile.
3) Go through all lines that have "selectedLocale" in them, and
   a) replace "en-US" with your wanted language code (e.g. "de-AT")
   b) replace "US" with your wanted content code (e.g. "AT")
4) Save that changed file.
5) Delete the FastLoad file (XUL.mfl, XUL.mfasl) in your profile directory.
6) Launch Mozilla. It should have the language switched.

Comment 2

[Benjamin Smedberg]

See also bug 234109 (camino) and bug 230558.  These are all related, and I'm
having a lot of trouble pinning down what's going on... I don't think it's one
particular cause, but probably a collection of small changes that expose a
systemic problem in the chrome registry.

Could someone try starting with -UILocale with and without the profile manager,
and tell me whether that works?

Comment 3

[Michael Wolf]

May be the issue is related to that one of bug 232907,
http://bugzilla.mozilla.org/show_bug.cgi?id=232907
As I described there under Additional comment #11 the reason for the issue may
be in the file components/locale.xpt.

For testing this bug here I downloaded and installed the following nightly:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/experimental/2004-02-19-14-1.7a/mozilla-win32-1.7a-installer.exe

But, unfortunately there isn't the locale.xpt component more in the components
folder. Was it forgotten? 
BTW the link refers to nightly 2004-02-19-14, but in the title bar appears build
2004-02-19-13.

Comment 4

[Benjamin Smedberg]

Michael: I'm pretty sure your locale.xpt information doesn't affect this bug,
the "locale" being mentioned is an entiely different thing.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

taking, have patch

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

neil broke this in Bug 89576 on dec 19.

he removed the code that accessed the selected element via the dom
(getElementById etc), and accssed it now via the wsm. unfortunately the code is
broken (The urls are wrong).

Comment 7

[[e-mail]]

Comment on attachment 141883 [details] [diff] [review]
patch

Don't blame me, that line's always been wrong, blame
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/content-packs/re
sources/content/pref-contentpacks.xul&rev=1.2&root=/cvsroot&mark=75#75

Comment 8

[Robert Kaiser]

Neil: So you uncovered a bug that has essentially been there since we (or better
ben) invented content packs. Nice to know ;-)

And many thanks to biesi for finding that... Having that time-bomb in the code
for three years is bad enough - let's get it out of there...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 141883 [details] [diff] [review]
patch

sr=bzbarsky

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in pref-contentpacks.xul;
/cvsroot/mozilla/extensions/content-packs/resources/content/pref-contentpacks.xu
l,v  <--  pref-contentpacks.xul
new revision: 1.27; previous revision: 1.26
done

Comment 11

[Robert Kaiser]

Just tried switching on a current build on Linux. Verified fixed.

Comment 12

[Robert Kaiser]

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