Last Comment Bug 331779 - Please enable intl.locale.matchOS by default
: Please enable intl.locale.matchOS by default
Status: NEW
[bcp47]
:
Product: Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: x86 All
: -- enhancement with 3 votes (vote)
: ---
Assigned To: Simon Montagu :smontagu
:
Mentors:
: 352445 (view as bug list)
Depends on:
Blocks: bcp47
  Show dependency treegraph
 
Reported: 2006-03-26 10:23 PST by Mike Hommey [:glandium]
Modified: 2014-01-02 03:03 PST (History)
22 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
enable intl.locale.matchOS as default (1.52 KB, patch)
2007-04-12 08:36 PDT, Evan Yan
l10n: review-
Details | Diff | Splinter Review

Description Mike Hommey [:glandium] 2006-03-26 10:23:28 PST
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 2006-03-27 02:59:04 PST
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] 2006-09-10 11:32:05 PDT
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] 2006-09-13 02:31:50 PDT
*** Bug 352445 has been marked as a duplicate of this bug. ***
Comment 4 Axel Hecht [:Pike] 2006-09-13 06:40:40 PDT
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 [:bsmedberg] 2006-09-13 06:52:04 PDT
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 2007-04-10 07:45:18 PDT
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 2007-04-12 08:36:46 PDT
Created attachment 261383 [details] [diff] [review]
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] 2007-04-12 08:38:25 PDT
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 2007-04-12 08:43:14 PDT
(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] 2007-04-12 08:51:51 PDT
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] 2007-08-31 05:14:54 PDT
Cancelling 1.9 blocking request, gecko feature freeze is through, and this one won't break it, IMHO.
Comment 12 Reed Loden [:reed] (use needinfo?) 2008-12-15 16:46:15 PST
Linux distros are actively using this pref. Are there reasons why they should be?
Comment 13 Reed Loden [:reed] (use needinfo?) 2008-12-15 17:03:16 PST
(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] 2008-12-15 17:07:15 PST
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 2009-04-07 07:04:23 PDT
(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 2009-08-09 22:15:23 PDT
Ubuntu Bug:
https://bugs.launchpad.net/bugs/339326

The compatibility dialog and the profile manager are in English.
Comment 17 Axel Hecht [:Pike] 2009-12-03 01:11:53 PST
(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) 2010-08-10 01:19:20 PDT
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) 2010-08-10 01:21:17 PDT
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 2010-08-10 13:06:27 PDT
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] 2011-06-23 13:12:16 PDT
If I'm not mistaken, this issue came up in our discussion of BCP 47 today, so I'm adding it to our list.

Note You need to log in before you can comment on or make changes to this bug.