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

RESOLVED FIXED in mozilla1.8final

Status

()

RESOLVED FIXED
14 years ago
11 years ago

People

(Reporter: ville.pohjanheimo, Assigned: benjamin)

Tracking

unspecified
mozilla1.8final
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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

14 years ago
So, the actual intent of this bug is to add "en-US" to the locale preference
search order?
(Reporter)

Comment 2

14 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).
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

Comment 6

14 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

14 years ago
Created attachment 178264 [details] [diff] [review]
Add en-US as a low-level fallback before "anything"
Attachment #178264 - Flags: review?(darin)

Comment 8

14 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

14 years ago
The decision is arbitrary and depends on runtime startup order anyway, so I'm
not going to worry about it.
(Assignee)

Updated

14 years ago
Assignee: bugs → benjamin
Target Milestone: --- → Firefox1.1
(Assignee)

Comment 10

14 years ago
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 11

14 years ago
Any chance this could go into 1.03 as well?
(Assignee)

Comment 12

14 years ago
No.

Comment 13

14 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.
*** 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.