[MASTER] some parts of Firefox are not localized

[marco.pallotta]

When you upgrade firefox to a new version the extension compatiblity checking process starts at firefox next restart but I noticed that the window saying that the compatibility process is starting isn't translated in Italian.
In launchpad (https://translations.launchpad.net/ubuntu/hardy/+lang/it) we can see that the italian translation status of firefox is 100% translated but I think it's wrong as I have explained above.

Tested with Ubuntu Hardy and firefox 3.0.7

Also, any notice at startup, like Firefox is already running is not translated.

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

[L10n-mozilla (l10n-mozilla)]

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.

[L10n-mozilla (l10n-mozilla)]

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

[L10n-mozilla (l10n-mozilla)]

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?

[Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs)]

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.

[Evan-yan-sun (evan-yan-sun)]

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.

[Evan-yan-sun (evan-yan-sun)]

Created an attachment (id=261383)
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.

[L10n-mozilla (l10n-mozilla)]

(From update of attachment 261383)
There are architectural bugs in the matchOS code that we're not going to support, r- on just switching it on.

[Evan-yan-sun (evan-yan-sun)]

(In reply to comment #8)
> (From update of attachment 261383 [details])
> 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?

[L10n-mozilla (l10n-mozilla)]

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.

[L10n-mozilla (l10n-mozilla)]

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

[Reed Loden (reed)]

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

[Reed Loden (reed)]

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

shouldn't*

[L10n-mozilla (l10n-mozilla)]

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.

[marco.pallotta (marco-pallotta)]

When you upgrade firefox to a new version the extension compatiblity checking process starts at firefox next restart but I noticed that the window saying that the compatibility process is starting isn't translated in Italian.
In launchpad (https://translations.launchpad.net/ubuntu/hardy/+lang/it) we can see that the italian translation status of firefox is 100% translated but I think it's wrong as I have explained above.

[Alexander Sack (asac)]

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

[marco.pallotta (marco-pallotta)]

Confirmed with firefox 3.0.10 too

[Micah Gersten (micahg)]

Moving to Firefox 3.0

[Bruno (bruno666-666)]

Confirmed for French translations and Firefox 3.0.12

The compatibility dialog and the profile manager are in English.

Steps to reproduce (for other languages) :
- check that upstream (or Launchpad) translation are completed
- check that files inside /<email address hidden>/fr.jar
 and /<email address hidden> are 100% translated (replace fr with your language code)
- try to launch the profile manager : firefox -ProfileManager

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

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

The compatibility dialog and the profile manager are in English.

[Micah Gersten (micahg)]

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:
https://bugzilla.mozilla.org/show_bug.cgi?id=331779

[marco.pallotta (marco-pallotta)]

Also not translated in Italian pop-up

"Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system"

A possible translation could be:

"Firefox è già in esecuzione, ma non stà rispondendo. Per aprire un nuova finestra dello stesso programma devi prima chiudere il processo Firefox esistente oppure eseguire un riavvio del sistema"

Tested with Hardy and Firefox 3.0.14

[Jean-Bernard Marcon (goofy-babelzilla)]

Please note that this series of missing translation are by no way the responsability of l10 teams. The *upstream process* is at stake.
I am unfortunately ignorant about how it is done technically, but I suggest all langpacks fro Firefox should be extracted from http://hg.mozilla.org/l10n-central/ and from nowhere else.

[L10n-mozilla (l10n-mozilla)]

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

[cameleon (el-cameleon-1)]

Same problem here, its so bad that the first windows that a user see (the profile manager) is not localized :-(
Any chance that it could be corrected for Lucid (actually, this is not the case)?

[Mathieu Marquer (slasher-fun)]

Adding firefox package as being affected in order to reflect this bug also appears in Lucid (with FF 3.6)

[cameleon (el-cameleon-1)]

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

[cameleon (el-cameleon-1)]

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

[Micah Gersten (micahg)]

Wrong upstream bug, will file a new one

[Adolfo Jayme Barrientos (fitojb)]

Can anyone still reproduce this with the latest Firefox?

[Adolfo Jayme Barrientos (fitojb)]

Never mind, I've just found another duplicate of this bug.

[Hendrik Schrieber (hennekn)]

Still a problem in Precise.

[Hendrik Schrieber (hennekn)]

Using Firefox 21.0.

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

Not yet fixed FF 26 - looks really sweet in W$. And btw: Thanks for reporting

[Ken (1clue)]

This problem still exists.

Even though I have the correctly-installed language pack, there are still issues with Firefox's English-US browser. It still favors British spelling, for example. I found a post about this with a solution:
https://support.mozilla.org/en-US/questions/960058

solution is here:
https://www.mozilla.org/en-US/firefox/all/

I have not yet installed the fully localized version of firefox, but it seems that we need this in order to get rid of the constant wrong-language problem.

Thanks.