Closed Bug 902173 Opened 7 years ago Closed 7 years ago
"[fr] Outils" wrongly translated to "Outils de développement" in menu since FF 23
Since Firefox 23, in the menu bar (which is hidden by default), next to "Bookmarks" ("Marque-pages" in French), "Outils" is now translated to "Outils de dévelopement" while it still contains things not related to development (like "Downloads"/"Téléchargements", "Add-ons"/"Modules complémentaires", etc.).
Confirmed on Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20100101 Firefox/23.0 on rev http://hg.mozilla.org/releases/mozilla-release/rev/2c423c4c6d0b
It's not hidden for Windows XP, Mac and Linux. See http://forums.mozfr.org/viewtopic.php?f=5&t=114085 Only Release is affected but I think there will be 23.0.1 (see bug 902349). Is it possible to uplift the fix to the Release branch?
Severity: normal → critical
We're not taking l10n updates on chem spills, and this would involve quite a bit of manual work on relman and releng. I'm not sure if this bug is bad enough to warrant that.
I think it's bad, it's a bug in the top menu, so it's very visible for users that have the menu displayed by default (mac/winXP/linux), even if they are maybe 15% of the users, that still makes a lot of people given the number of users of the French version.
(In reply to Axel Hecht [:Pike] from comment #3) > I'm not sure if this bug is bad enough to warrant that. It's not only a difference of meaning (Developer Tools is not Tools) but it's a highly visible change in the main UI except for Windows Vista and above.
Hey Gavin, we talked about this as a possible ride-along in a 23.0.1, but l10n & RelEng suggested that taking new translations in a dot build is unprecedented and therefore risky. Could we make a safe one-off patch for French here specifically, perferring an in-code string?
I actually might have an idea on how to make this possible through relbranches, but I need to dig through my dashboard code a bit deeper. Yep, contradicting myself withing 15 minutes.
Adding logic in the code to dynamically adjust the string for French only seems rather complicated and error-prone. I think we should focus on just taking the l10n fix if possible (I don't understand what makes that complicated).
(In reply to Scoobidiver from comment #5) > It's not only a difference of meaning (Developer Tools is not Tools) A French user says in http://forums.mozfr.org/viewtopic.php?f=5&t=114094: "I am disappointed by Firefox 23. My Tools menu has disappeared and I get instead a Developer Tools menu but I don't want to develop websites"
We're still discussing in email the possibility of how to do a French locale respin 23.0.1 with our infrastructure constraints. In the meantime any ideas on how to help spread the message that this is the same menu would be great - also let's make sure that FF24 and up are updated.
(In reply to firstname.lastname@example.org [:lsblakk] from comment #10) > In the meantime any ideas on how to help spread the message that this is the same > menu would be great There's no ambiguity at all and I don't know how it happened: http://transvision.mozfr.org/?repo=release&sourcelocale=en-US&locale=fr&search_type=strings&case_sensitive=case_sensitive&perfect_match=perfect_match&recherche=Tools > let's make sure that FF24 and up are updated. They are not affected: * 24 Beta: http://transvision.mozfr.org/?repo=beta&sourcelocale=en-US&locale=fr&search_type=entities&recherche=browser%2Fchrome%2Fbrowser%2Fbrowser.dtd%3AtoolsMenu.label * Aurora 25: http://transvision.mozfr.org/?repo=aurora&sourcelocale=en-US&locale=fr&search_type=entities&recherche=browser%2Fchrome%2Fbrowser%2Fbrowser.dtd%3AtoolsMenu.label * Nightly 26: http://transvision.mozfr.org/?repo=central&sourcelocale=en-US&locale=fr&search_type=entities&recherche=browser%2Fchrome%2Fbrowser%2Fbrowser.dtd%3AtoolsMenu.label I've also checked the Menu Bar in 24.0a2/20130805 (see the attached screenshot), 25.0a2/20130808 and 26.0a1/20130808. It's only in Release: http://transvision.mozfr.org/?sourcelocale=en-US&locale=fr&repo=release&search_type=entities&recherche=browser/chrome/browser/browser.dtd:toolsMenu.label
Alternative fix, we can not take both qa fixes to dev tools, http://hg.mozilla.org/releases/l10n/mozilla-beta/fr/rev/813ec95e1476 http://hg.mozilla.org/releases/l10n/mozilla-beta/fr/rev/9a201b33e322 and go back to http://hg.mozilla.org/releases/l10n/mozilla-beta/fr/rev/ba23c793ca7e, just taking the eBay fix.
(Answering for the French team as Théo is without internet this week I believe and most of the other people are probably on summer holidays) Taking just the eBay fix is fine, the rewording changes for dev tools that introduced the regression can be reverted to the wording in the previous version, these changes were not fixing typos, rather harmonizing vocabulary across the app.
Lukas, I heard you on the engineering call saying that we want to take this. Which way are we going to go? Is this just an edit on releng side, or should I prepare the new l10n-changesets (which would need a manual removal of mn and sw again)
Verified that this bug is fixed on Firefox 23.0.1 fr (20130814063812). Tested on Mac OS X 10.7.5, Windows 7 64bit and Ubuntu 13.04 32bit.
Henrik, is this something we should have caught with our l10n tests?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #16) > Henrik, is this something we should have caught with our l10n tests? Sorry, but there is nothing we can do here with Mozmill. Mostly because we don't have any kind of reference to compare to. The l10n team might have an idea for their own tools?
Flags: in-qa-testsuite?(hskupin) → in-qa-testsuite-
This was just an honest translation mistake, there's nothing but manual testing to catch those.
Now everything is OK on Firefox 23.0.1, I think this bug can be closed, no? Or does the fix needs to be retrofit to other branches (for Firefox 24, 25, etc.)?
Yep, thanks, fixed.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.