Closed Bug 1107278 Opened 7 years ago Closed 7 years ago

Localize the new searchbar UI for Firefox 35


(Firefox :: Search, defect)

Not set



Firefox 35
Tracking Status
firefox35 ? fixed
firefox36 --- unaffected
firefox37 --- unaffected


(Reporter: aryx, Assigned: florian)





(2 files)


The new one-click search is also shown to users which use an en-US build
with language packs on top which is the default setup e.g. on Ubuntu and
Xubuntu. The English strings are hardcoded and not available in the
translation files. Because of that, the users don't see localized but
English strings (e.g. the whole Search pane in the Preferences is
English). Should the strings be made localizable, at least for
localizers who want to work on them for Firefox 35 (currently in beta)?

Théo's opinion:
"We need to make sure this won't happen for 35, and I think we should discuss with RelEng to see if a chemspill release is scheduled and could include a fix."
The useragent's locale and accept languages can't be trusted. See bug 771999 comment 15.
(In reply to Archaeopteryx [:aryx] from comment #1)
> The useragent's locale and accept languages can't be trusted. See bug 771999
> comment 15.

What's the relation with this bug/feature? We're using a pref to enable/disable it.
From the firefox-dev mailing list:
"For the sake of the argument, that the patch wouldn't work for linux distros isn't surprising. The way it doesn't work is surprising to me, though. I would have expected the new UI to be off, as it doesn't make sense to have the en-US firefox-l10n.js in the build. Apparently at least for some distros though, it is, and just has the general.useragent.locale pref stripped from the file.

Is that a bug?"

The latter sentence can only be explained by the symptoms of bug 771999.
[Tracking Requested - why for this release]: From the discussions I had yesterday with Pike, flod, chofmann and gavin, it seems we'll want to land the strings of the new search UI in 35/beta so that the new UI can be released outside of the en-US locale sooner than 36.

The patch for this uplift would be something similar to the patch in bug 1103190 +
Nope, that comment just means that some distros are taking firefox-l10n.js from en-US (even if they shouldn't), and stripping the line about user-agent to avoid having general.useragent.locale=en-US

We're not using the user agent at any point to enable this feature
Assignee: nobody → florian
Summary: Make hardcoded one-click search string shipped with English (en-US) Firefox 34 localizable and uplift them/ship earlier than Firefox 36 to help Linux/language pack users → Localize the new searchbar UI for Firefox 35
Can we get to this?

I'm already seeing what I was hoping to not see, aka, loads of sign-offs with the l10n pref change, but without the strings. And the guy to fix it is on vacation (Dwayne's tool seems to actually not ignore the en-US contents of firefox-l10n.js)
(In reply to Axel Hecht [:Pike] from comment #6)
> Can we get to this?

Yes, I waited a bit here because there was a lot of back-and forth with UX around fixing bug 1108488 or bug 1109851 and I also needed the UX in bug 1106055 to then build a prototype (which I now have in bug 1106559) to be sure we were satisfied and willing to ship this in 35.

At this time I think it's too late for a solution with strings for bug 1108488 / bug 1109851 so I think we'll either figure out some low risk changes without strings, or delay until 37.

I'll try to have string patches up for this bug + bug 1106559 tonight ready for approvals.

Sorry for the delay.
See Also: → 1103190
I'm carrying forward felipe's review from bug 1107278 where the patch was the same except it also set to true by default for all locales.

Approval Request Comment
[Feature/regressing bug #]: bug 1088660
[User impact if declined]: New search user interface available only for en-US users, and shown in en-US for all locales on Ubuntu (and possibly a few other linux distributions).
[Describe test coverage new/current, TBPL]: The patch has landed on central for 36 in bug 1107278.
[Risks and why]: 
[String/UUID change made/needed]: This uplifts strings from 36 to 35, after discussing with gavin/Pike/flod/chofmann this is the right thing to do for 35.
Attachment #8535299 - Flags: review+
Attachment #8535299 - Flags: approval-mozilla-beta?
Note: we will be adding back support for editing search keywords in 35, so for the new search UI to be localized in 35, we actually need uplift the string patch from bug 1106559 in addition to the patch here.
Attachment #8535299 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Landed in

Backed out accidental change to browser/locales/en-US/firefox-l10n.js in
Closed: 7 years ago
Resolution: --- → FIXED
Points: --- → 2
Flags: qe-verify-
Flags: firefox-backlog+
Attached patch Test bustage fixSplinter Review
My push broke bc1 and bc2 tests on mozilla-beta. The cause is 2 lines of leftover duplicated code. I pushed the fix right away on beta with r+a=bustage-fix, but I think we should also take this cleanup on central and aurora where it's not really a bustage fix (I guess JS engine changes make the code work there anyway), so I'm requesting review.
Attachment #8535583 - Flags: review?(felipc)
Iteration: --- → 37.2
Attachment #8535583 - Flags: review?(felipc) → review+
Comment on attachment 8535583 [details] [diff] [review]
Test bustage fix

Approval Request Comment
[Feature/regressing bug #]: bug 1107278
[User impact if declined]: none. I would like to land this on aurora so that the code in 36 is consistent with the code in 35 and 37.
[Describe test coverage new/current, TBPL]: already landed on beta
[Risks and why]: very low
[String/UUID change made/needed]: none.
Attachment #8535583 - Flags: approval-mozilla-aurora?
Attachment #8535583 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Depends on: 1122983
You need to log in before you can comment on or make changes to this bug.