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

Status: REOPENED

(Core :: Internationalization, enhancement)

Description

[Mike Hommey [:glandium]]

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

Comment 1

[Simon Montagu :smontagu]

See bug 44070 comment 51 and following. We need to investigate whether turning on the pref. still causes a performance regression in startup time.

Comment 2

[Axel Hecht [:Pike]]

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.

Comment 3

[Axel Hecht [:Pike]]

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

Comment 4

[Axel Hecht [:Pike]]

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?

Comment 5

[Benjamin Smedberg]

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.

Comment 6

[Evan Yan]

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.

Comment 7

[Evan Yan]

Attachment: enable intl.locale.matchOS as default

I think we can take this as current solution before the thing mentioned in comment #5 come to true.

Comment 8

[Axel Hecht [:Pike]]

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.

Comment 9

[Evan Yan]

(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?

Comment 10

[Axel Hecht [:Pike]]

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.

Comment 11

[Axel Hecht [:Pike]]

Cancelling 1.9 blocking request, gecko feature freeze is through, and this one won't break it, IMHO.

Comment 12

[Reed Loden [:reed]]

Linux distros are actively using this pref. Are there reasons why they should be?

Comment 13

[Reed Loden [:reed]]

(In reply to comment #12)
> Linux distros are actively using this pref. Are there reasons why they should
> be?

shouldn't*

Comment 14

[Axel Hecht [:Pike]]

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.

Comment 15

[Alexander Sack]

(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.

Comment 16

[Micah Gersten]

Ubuntu Bug:
https://bugs.launchpad.net/bugs/339326

The compatibility dialog and the profile manager are in English.

Comment 17

[Axel Hecht [:Pike]]

(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?

Comment 18

[Vincent (caméléon)]

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

Comment 19

[Vincent (caméléon)]

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

Comment 20

[Micah Gersten]

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

Comment 21

[Gordon P. Hemsley [:GPHemsley]]

If I'm not mistaken, this issue came up in our discussion of BCP 47 today, so I'm adding it to our list.

Comment 22

[Axel Hecht [:Pike]]

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.

Comment 23

[Axel Hecht [:Pike]]

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

Comment 24

[Zibi Braniecki [:zbraniecki][:gandalf]]

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?

Comment 25

[Axel Hecht [:Pike]]

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.

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.