The Mozilla Firefox Browser

[MASTER] some parts of Firefox are not localized

Reported by marco.pallotta on 2009-03-07
116
This bug affects 18 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
New
Undecided
Unassigned
Ubuntu Translations
Medium
Unassigned
firefox (Ubuntu)
Medium
Unassigned

Bug Description

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.

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

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

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

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.

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.

description: updated

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

Micah Gersten (micahg) wrote :

Moving to Firefox 3.0

affects: firefox (Ubuntu) → firefox-3.0 (Ubuntu)

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

summary: - extention compatibility checking window isn't translated in Italian
+ some parts of Firefox are not localized
Changed in firefox-3.0 (Ubuntu):
status: New → Confirmed

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

The compatibility dialog and the profile manager are in English.

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

Changed in firefox-3.0 (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Changed in firefox:
status: Unknown → Confirmed
Micah Gersten (micahg) on 2009-09-25
description: updated

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

Micah Gersten (micahg) on 2009-11-01
summary: - some parts of Firefox are not localized
+ [MASTER] some parts of Firefox are not localized
Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged

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.

Adi Roiban (adiroiban) on 2009-11-01
Changed in ubuntu-translations:
status: New → Confirmed
importance: Undecided → Medium

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

David Planella (dpm) on 2009-12-03
Changed in ubuntu-translations:
status: Confirmed → Triaged
cameleon (el-cameleon-1) wrote :

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) wrote :

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

Changed in firefox (Ubuntu):
status: New → Confirmed

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

Micah Gersten (micahg) wrote :

Wrong upstream bug, will file a new one

Changed in firefox:
importance: Unknown → Undecided
status: Confirmed → New
Adolfo Jayme (fitoschido) wrote :

Can anyone still reproduce this with the latest Firefox?

no longer affects: firefox-3.0 (Ubuntu)
no longer affects: firefox-3.5 (Ubuntu)
Changed in firefox (Ubuntu):
status: Confirmed → Incomplete
Adolfo Jayme (fitoschido) wrote :

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

Changed in firefox (Ubuntu):
importance: Undecided → Medium
status: Incomplete → Triaged
Hendrik Knackstedt (hennekn) wrote :

Still a problem in Precise.

Hendrik Knackstedt (hennekn) wrote :

Using Firefox 21.0.

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

tags: added: langpack precise
tags: added: trusty
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.