1246494 - [ja, ja-JP-mac] Remove localized version of Google searchplugin on Firefox desktop

Status: RESOLVED FIXED

(Mozilla Localizations :: ja / Japanese, defect)

Description

[Francesco Lodolo [:flod]]

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.

Comment 1

[Mike Connor [:mconnor]]

cc-ing Kev and Joanne. I thought we'd already said to kill this?

Comment 2

[Masahiko Imanaka [:marsf]]

At least, Bug 1217296 is blocking to resolve this (according to bug 1244506#c4).
I'm not sure if there is more blocker.

Comment 3

[Francesco Lodolo [:flod]]

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.

Comment 4

[Kev Needham [:kev]]

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

Comment 5

[Mike Connor [:mconnor]]

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

Comment 6

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked for 47 and updating status to reflect that.

Comment 7

[Francesco Lodolo [:flod]]

Attachment: bug1246494.patch

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

Comment 8

[Mike Connor [: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.)

Comment 9

[Francesco Lodolo [:flod]]

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.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

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)

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking as a blocker for 46.0.1 now planned for next week. We will aim to go to build on monday.

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Mike can you verify this worked as intended?

Comment 15

[Mike Kaply [:mkaply]]

I tested the 46.0.1 candidate builds for Mac and Windows and they both work exactly as they should.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 17

[Francesco Lodolo [:flod]]

Yes. I was waiting for 46.0.1 to close this bug.