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)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
FIXED
mozilla1.8final
People
(Reporter: ville.pohjanheimo, Assigned: benjamin)
References
Details
Attachments
(1 file)
2.37 KB,
patch
|
darin.moz
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•20 years ago
|
||
So, the actual intent of this bug is to add "en-US" to the locale preference
search order?
Reporter | ||
Comment 2•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
*** Bug 285263 has been marked as a duplicate of this bug. ***
Comment 5•20 years ago
|
||
*** Bug 287208 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•20 years ago
|
||
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)
Assignee | ||
Comment 7•20 years ago
|
||
Attachment #178264 -
Flags: review?(darin)
Comment 8•20 years ago
|
||
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+
Assignee | ||
Comment 9•20 years ago
|
||
The decision is arbitrary and depends on runtime startup order anyway, so I'm
not going to worry about it.
Assignee | ||
Updated•20 years ago
|
Assignee: bugs → benjamin
Target Milestone: --- → Firefox1.1
Assignee | ||
Comment 10•20 years ago
|
||
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 11•20 years ago
|
||
Any chance this could go into 1.03 as well?
Assignee | ||
Comment 12•20 years ago
|
||
No.
Comment 13•20 years ago
|
||
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•20 years ago
|
||
*** Bug 289671 has been marked as a duplicate of this bug. ***
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•