The default bug view has changed. See this FAQ.

Please enable intl.locale.matchOS by default

NEW
Assigned to

Status

()

Core
Internationalization
--
enhancement
11 years ago
3 years ago

People

(Reporter: glandium, Assigned: smontagu)

Tracking

(Blocks: 1 bug)

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bcp47])

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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
(Assignee)

Comment 1

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

Comment 2

11 years ago
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?

Comment 3

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

Comment 4

11 years ago
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.

Comment 6

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

10 years ago
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.
Attachment #261383 - Flags: review?(benjamin)

Comment 8

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

Comment 9

10 years ago
(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

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

10 years ago
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*

Comment 14

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

8 years ago
(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

8 years ago
Ubuntu Bug:
https://bugs.launchpad.net/bugs/339326

The compatibility dialog and the profile manager are in English.

Updated

7 years ago

Comment 17

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

Updated

7 years ago

Comment 20

7 years ago
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: 356038
Whiteboard: [bcp47]
You need to log in before you can comment on or make changes to this bug.