Closed Bug 279952 Opened 20 years ago Closed 20 years ago

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

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8final

People

(Reporter: ville.pohjanheimo, Assigned: benjamin)

References

Details

Attachments

(1 file)

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.
So, the actual intent of this bug is to add "en-US" to the locale preference search order?
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).
Would it be feasible to pick something up from intl.accept_languages -- after the browser's locale, but before the en-US fallback?
*** Bug 285263 has been marked as a duplicate of this bug. ***
*** Bug 287208 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Adding keywords to summary, changing OS->All (dupe is on win2000)
OS: Linux → All
Summary: Extensions' default locale order causes weird behaviour → Extensions' default locale order causes weird behaviour (wrong language selected for extensions)
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
Attachment #178264 - Flags: review?(darin) → review+
The decision is arbitrary and depends on runtime startup order anyway, so I'm not going to worry about it.
Assignee: bugs → benjamin
Target Milestone: --- → Firefox1.1
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Any chance this could go into 1.03 as well?
No.
I filed Bug 288670 to address the concerns of comment 3, and to try to find a less arbitrary way of doing this.
*** Bug 289671 has been marked as a duplicate of this bug. ***
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: