User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:22.214.171.124) Gecko/20060313 Debian/1.5.dfsg+126.96.36.199-4 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:184.108.40.206) Gecko/20060313 Debian/1.5.dfsg+220.127.116.11-4 Firefox/18.104.22.168 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.
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.
*** 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.
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 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.
(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.
Linux distros are actively using this pref. Are there reasons why they should be?
(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.