266567 - l10n .xpi's don't update intl.accept_languages pref

Status: RESOLVED INCOMPLETE

(Firefox :: Settings UI, defect)

Description

[sairuh (rarely reading bugmail)]

found using 2004102809-0.11 (firefox-1.0.en-US.linux-i686.tar.gz, on linux fc2).
after I install an localization .xpi, the ntl.accept_languages preference is not
updated --it only lists en-us and en.

1. for ease in locale switching, install the Locale Switcher extension.

2. install some l10n .xpi's (as extensions). for example, I installed the following:

firefox-1.0.es-ES.langpack.xpi
firefox-1.0.fr-FR.langpack.xpi
firefox-1.0.ru-RU.langpack.xpi
firefox-1.0.ja-JP.langpack.xpi
firefox-1.0.de-DE.langpack.xpi

3. quit and restart firefox.

4. from the main menu select Tools > Languages and choose a locale from 2.

5. quit and restart firefox again.

6. open Preferences > General > Languages and in the resulting dialog, look at
the listbox for "Languages in order of preference"

expected: the language[s] for the locale you're in should be listed.

actual results: the language for the locale is not listed. only en and en-us are
listed.

Comment 1

[Robin Monks]

Could this be related to bug 240466 ?

Comment 2

[Benjamin Smedberg]

Is this being set as a user preference? Once it is set as a user preference, the
default pref will not be read.

Comment 3

[Benjamin Smedberg]

This works for me on win32 builds if I have not set the user pref.

Comment 4

[sairuh (rarely reading bugmail)]

in comment 0 I used a non-installer version of en-us firefox. I retried this by
using the actual installer version
(firefox-1.0.en-US.linux-i686.installer.tar.gz), and I no longer see this problem.

so perhaps base firefox application (in my case en-us) needs to be an installer
problem. I can certainly live with that, so clearing the blocking-aviary1.0
flag. I don't mind if the blocking-aviary1.0-L10N flag is cleared (or minused),
but I'll leave that to l10n people to decide. but I think that not flipping this
pref in a non-installer build is kinda buggish...

Comment 5

[sairuh (rarely reading bugmail)]

> so perhaps base firefox application (in my case en-us) needs to be an installer
> problem.

duh, meant to say: "needs to be an installer build."

Comment 6

[sairuh (rarely reading bugmail)]

drat, scratch comment 4 and 5.

to be brief: in a simple situation where I had only one l10n xpi installed
(fr-fr) in the non-installer en-us build (ie, a new profile running on such
build), the French language pref did manage to appear in the pref dialog
(intl.accept_languages set correctly).

so I currently think that this might be due to a specific lang pack (xpi) --it
might take me a while to figure out which one or if it's something else (I need
to test some other things). but having several (5+) l10n xpi's could've messed
up/complicated my results I had seen earlier. :-P

Comment 7

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change

Comment 8

[Andre Klapper]

Is this still a problem after seven years?
If you still see this problem, please add a comment to this report and tell us your version and your operating system (Windows, Mac OS, Linux). If the problem does not happen anymore, please set the status of this report to RESOLVED > WORKSFORME. Thanks for your help!

Comment 9

[Andre Klapper]

Unfortunately closing this report as no further information has been provided.

Please feel free to reopen this report if you can provide the information asked for and if this still happens in a recent and supported version (currently 15.0 and 10.0.6esr). Thanks!