10

Please set intl.locale.requested to "" by default

 4 years ago
source link: https://bugzilla.mozilla.org/show_bug.cgi?id=331779
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client
Open Bug 331779 Opened 15 years ago Updated 2 years ago

Please set intl.locale.requested to "" by default

Categories

(Core :: Internationalization, enhancement)

Core ▾
Internationalization ▾

Tracking

(REOPENED bug with no priority)

REOPENED

People

(Reporter: glandium, Assigned: smontagu)

References

(Blocks 1 open bug)

Details

(Whiteboard: [bcp47]) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.8.0.1) Gecko/20060313 Debian/1.5.dfsg+1.5.0.1-4 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.8.0.1) Gecko/20060313 Debian/1.5.dfsg+1.5.0.1-4 Firefox/1.5.0.1

Everything is in the summary...

Reproducible: Always
See bug 44070 comment 51 and following. We need to investigate whether turning on the pref. still causes a performance regression in startup time.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It'd be nice to have this for Firefox 3, this might enable us to get rid of firefox-l10n.js, at least in its not-per-locale form.
Flags: blocking1.9?
*** Bug 352445 has been marked as a duplicate of this bug. ***
Benjamin, I need your chrome registry start-up brain.

My current idea is for intl.locale.matchOS to work, we should set general.useragent.locale on the default branch to best match or leave it alone.

http://lxr.mozilla.org/mozilla/source/chrome/src/nsChromeRegistry.cpp#530
seems to be the place to look at, but I'm afraid my idea may end up in a deadlock between setting mSelectedLocale and CheckForNewChrome. Though I currently don't see that CheckForNewChrome would need mSelectedLocale to be right.

Not that I know the default pref branch well enough to understand if this really does the right thing. Do you? Or who would?
intl.locale.matchOS shouldn't be mucking with prefs. We really need a way for various clients to get "the current locale" without going through prefs, which obviously aren't going to be accurate.
should we re-consider enable intl.locale.matchOS as default?

The performance impact mentioned in bug 44070 comment #51 is five years ago. And I have tried enabling intl.locale.matchOS on our tinderbox for Solaris (http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox-Ports), no performance impact observed.

It's important because currently every OS distributions have to hold patch themselves, in order to have Firefox/Thunderbird can be launched in correct locale.
I think we can take this as current solution before the thing mentioned in comment #5 come to true.
Attachment #261383 - Flags: review?(benjamin)
Comment on attachment 261383 [details] [diff] [review]
enable intl.locale.matchOS as default

There are architectural bugs in the matchOS code that we're not going to support, r- on just switching it on.
Attachment #261383 - Flags: review?(benjamin) → review-
(In reply to comment #8)
> (From update of attachment 261383 [details] [diff] [review])
> There are architectural bugs in the matchOS code that we're not going to
> support, r- on just switching it on.
> 
do you mean the performance impact mentioned in comment #1?

The code implementing matchOS just does the wrong thing, at the wrong time. It's been a while since I looked, but we for sure shouldn't trigger that code by default. In particular, thinking about it, it did whacky stuff once it works on a OS version that is in a different language than the installed Firefox. Etc.
Cancelling 1.9 blocking request, gecko feature freeze is through, and this one won't break it, IMHO.
Flags: blocking1.9?
Linux distros are actively using this pref. Are there reasons why they should be?
QA Contact: amyy → i18n
(In reply to comment #12)
> Linux distros are actively using this pref. Are there reasons why they should
> be?

shouldn't*
Yes, there are. Ugh-y code, untested code path, perf, maybe others.

Whether those outweigh the benefits in the use case of a linux distro is a completely different question. Linux is the only platform we ship on as default, thus the multi-locale use-case is completely different there than on the other OSes. And they can hack stuff to make some problems smaller, or just buy it.

That doesn't mean that we should change our setting here for the builds we ship, as those target a particular locale.
(In reply to comment #14)
> Yes, there are. Ugh-y code, untested code path, perf, maybe others.

FWIW, its not completely untested. Distros use matchOS for quite some time, so we have some reason to believe that regressions due to this are not that severe.
Ubuntu Bug:
https://bugs.launchpad.net/bugs/339326

The compatibility dialog and the profile manager are in English.
(In reply to comment #16)
> Ubuntu Bug:
> https://bugs.launchpad.net/bugs/339326
> 
> The compatibility dialog and the profile manager are in English.

This and that have nothing to do with each other.

Please file a separate bug for updater and multi-locale builds not working, and CC me?
Sorry, I don't really understand what this bug is about if it doesn't deal with the localisation problem of the compatibility dialog and the profile manager. As it is still reference in https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/294187 , it would be great to correct the lauchpad bug if it is wrong...
Sorry, the bug given above is not correct, it is: "[MASTER] some parts of Firefox are not localized" at https://bugs.launchpad.net/bugs/339326
Sorry Axel, the LP bug was still set with this as upstream.  I took care of that and it won't come back now.  I'll follow a follow up bug later per comment 17
If I'm not mistaken, this issue came up in our discussion of BCP 47 today, so I'm adding it to our list.
Blocks: bcp47
Whiteboard: [bcp47]

The matchOS pref got removed, resolving WONTFIX.

The behavior is now controlled by a single pref, intl.locale.requested, and its default value is to not exist. "" does matchOS, any other value selects the given list of locales.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Please enable intl.locale.matchOS by default → Please set intl.locale.requested to "" by default

I'm tempted to just close this again. This needs way better rationale than just "I want this".

I'm not sure if this should be in Internationalization since I doubt the Intl module owner or peers should make this decision.
I feel like the role of the intl module is to enable things, and the l10n module sets the defaults to build a coherent experience.

This is about the selection of UI localization primarily, and this belongs to our l10n model, rather than intl capabilities.

Axel - would you be willing to take it into L10n component and make the decision?

Flags: needinfo?(l10n)

I don't think this should go out of Intl, given all the related bugs are here. The discussion what, if anything, belongs into Core::Localization probably doesn't belong into this bug.

Flags: needinfo?(l10n)
You need to log in before you can comment on or make changes to this bug.

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK