Closed Bug 1246494 Opened 5 years ago Closed 4 years ago
[ja, ja-JP-mac] Remove localized version of Google searchplugin on Firefox desktop
See also bug 1244506: is there any specific reason to keep shipping a different .xml than en-US? Fennec is already doing it, desktop doesn't have specific partner's codes.
Summary: [ja, ja-JP-mac] Remove specific version of Google searchplugin → [ja, ja-JP-mac] Remove localized version of Google searchplugin on Firefox desktop
cc-ing Kev and Joanne. I thought we'd already said to kill this?
At least, Bug 1217296 is blocking to resolve this (according to bug 1244506#c4). I'm not sure if there is more blocker.
Reporting comment here (and my reply) for sake of completeness > (In reply to Makoto Kato [:m_kato] from comment #4) > > google.co.jp and google.com are different. After searching a word via .com > > searchplugin, we will hit several UX issues (ex. bug 1217296). So I don't > > think that we can remove it. > > That would definitely be a good reason. Having said that, bug 1217296 seems > to be a problem with the language setting on Google, not the domain itself. > > If I open a Private window and browse to google.co.jp, I would still get > Italian as language because of my accept-languages header, even if the > banner and domain say Google Japan. It's relatively easy to create a > searchplugin for google.com (harder to install it) and check if everything > works on your side.
(In reply to Mike Connor [:mconnor] from comment #1) > cc-ing Kev and Joanne. I thought we'd already said to kill this? We should remove all country-specific Google plugins, unless there is a good reason not to. This has always been Google's request of us, so +1 on removing, and there are other bugs where this has come up. This bug is pretty explicit, though, and I can't find any of the older ones. (In reply to Masahiko Imanaka [:marsf] from comment #2) > At least, Bug 1217296 is blocking to resolve this (according to bug > 1244506#c4). > I'm not sure if there is more blocker. Bug 1244506 seems to be a Google bug with IME support with English accept-langs that's independent of the search plugin, so I do not believe it should block. Are there any reasons why this plugin should be in the locale?
[Tracking Requested - why for this release]: There's no current justification for this plugin, and ja/ja-JP-mac should be using the core plugin with correct partner codes.
Tracked for 47 and updating status to reflect that.
@Mike Just to make sure we're doing the right thing: this removes the -ja version of Google and uses the en-US one. Since shortName is the same in both searchplugins, luckily no need to touch region.properties and default/searchorder. My plan is to land this in mozilla-release, then merge down in beta-aurora-central. Once landed in mozilla-release releng will still need to manually update the release shipping, since we can't have the same changeset in beta and release at this point in the cycle.
Attachment #8746551 - Flags: review?(mconnor)
Comment on attachment 8746551 [details] [diff] [review] bug1246494.patch Yes, this is the correct approach. Please make sure this is applied to both ja and ja-JP-mac. (I know you know, just want to make sure everyone knows that's what's up.)
Attachment #8746551 - Flags: review?(mconnor) → review+
Leaving only the release changesets (they have been merged down to beta-aurora-central) ja: https://hg.mozilla.org/releases/l10n/mozilla-release/ja/rev/5ff86cadfe9a ja-JP-mac: https://hg.mozilla.org/releases/l10n/mozilla-release/ja-JP-mac/rev/ab760b3dcdd1 We'll need relman to manually update the two Japanese versions to these changesets on release for a chemspill.
This is the first I've heard of this issue for 46. What is the impact here on users? What work are you proposing to uplift from other bugs? Does this really need a dot release? Note - We use the term "chemspill" for very fast response to serious security bugs, turning around a fix and release in about 1 day.
Ah, from irc conversation this is the same issue we were already aware of. I would like to make sure we know exactly what needs tracking/uplift so we don't miss any of the pieces.
OK, so as I understand it there is no actual uplift, just fiddle the l10n changesets in ship-it to : ja 5ff86cadfe9a ja-JP-mac ab760b3dcdd1 And rebuild (for desktop) If we end up doing a point release for android, we use the same changesets that we already shipped (we don't change them to match desktop)
Marking as a blocker for 46.0.1 now planned for next week. We will aim to go to build on monday.
Mike can you verify this worked as intended?
I tested the 46.0.1 candidate builds for Mac and Windows and they both work exactly as they should.
flod, I think this is fixed in 47 from what you say in comment 6. If that isn't right please me or ritu know and change the flag back to affected.
Yes. I was waiting for 46.0.1 to close this bug.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.