279952 - Extensions' default locale order causes weird behaviour (wrong language selected for extensions)

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Ville Pohjanheimo (inactive)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fi-FI; rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0+dfsg.1-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fi-FI; rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0+dfsg.1-2)

The behaviour of Firefox in the following explanation is of AFAIK quality:

If a localized extension has a default locale (first in it's install.rdf) that
is 1) not en-US and 2) is not localized onto the same locale as Firefox ->
Firefox chooses that extensions default locale as it's own default locale for
consecutive extensions until an extension is installed that either 1) does not
have that locale included or 2) includes Firefox's l10n locale.

This results in users getting confused as extensions can be in several
languages. Most of which are most probably *not understood* by the user.

Reproducible: Always

Steps to Reproduce:
1. On a clean fi-FI FF, install an extension that doesn't support fi-FI and has
a non en-US locale as it's default (first in install.rdf)
2. Firefox sets the extensions locale as default for the next extension too


Actual Results:  
Mysteriously (for Joe Average-user) Firefox extensions are often times in
various languages that are very foreign.

Expected Results:  
Extensions should always default to the locale of the browser, *then to en-US*
and not to the default of the extension. Ie. I should get my extensions in en-US
if fi-FI is not available.

Comment 1

[Benjamin Smedberg]

So, the actual intent of this bug is to add "en-US" to the locale preference
search order?

Comment 2

[Ville Pohjanheimo (inactive)]

Yes... now that I've had some more time to think about this, I think the point
would be to always have en-US as the fall-back locale.

Primary locale: browser's locale
Secondary locale: en-US

Reasoning:
en-US as a fall-back is based on the fact, that English is the most likely
language for a random person to know, among all languages. This is a (slightly)
western view, but only slightly as the set of languages includes all languages.

A longer term solution would have the localizers defining a fall-back list for
their l10n of Firefox (actually effects TB too).

Comment 3

[Tuukka Tolvanen (sp3000)]

Would it be feasible to pick something up from intl.accept_languages -- after
the browser's locale, but before the en-US fallback?

Comment 4

[Matthias Versen [:Matti]]

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

Comment 5

[Matthias Versen [:Matti]]

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

Comment 6

[Nickolay_Ponomarev]

Adding keywords to summary, changing OS->All (dupe is on win2000)

Comment 7

[Benjamin Smedberg]

Attachment: Add en-US as a low-level fallback before "anything"

Comment 8

[Darin Fisher]

Comment on attachment 178264 [details] [diff] [review]
Add en-US as a low-level fallback before "anything"

>+    if (LanguagesMatch(aPreferred, entry->provider)) {
>+      found = entry;
>+      continue;
>+    }

so, previously we'd only update found if !found, but now we
will be updating each time LanguagesMatch returns true.  is
that what we want?  it seems to me that the decision is rather
arbitrary, but it might be better to stay consistent with the
old behavior, or am i misunderstanding something?

r=darin

Comment 9

[Benjamin Smedberg]

The decision is arbitrary and depends on runtime startup order anyway, so I'm
not going to worry about it.

Comment 10

[Benjamin Smedberg]

Fixed on trunk.

Comment 11

[Richard Klein]

Any chance this could go into 1.03 as well?

Comment 12

[Benjamin Smedberg]

No.

Comment 13

[Greg Campbell]

I filed Bug 288670 to address the concerns of comment 3, and to try to find a
less arbitrary way of doing this.

Comment 14

[Tuukka Tolvanen (sp3000)]

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