1166389 - Include all Android search engines in iOS

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect)

Description

[Brian Nicholson (:bnicholson)]

We need to use location-based search engines. I think mconnor has more details.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Sounds like Karen is OK with simple methods for determining the location

Comment 2

[Karen Rudnitski [:kar]]

yep, provided we feel we capture most of the users (which I would expect we would when users select their location when setting up their phone).

Comment 3

[Brian Nicholson (:bnicholson)]

We already have support for different languages and regions, so it's just a matter of importing the remaining search engines from Android.

Comment 4

[Brian Nicholson (:bnicholson)]

Attachment: Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/574

Comment 5

[Francesco Lodolo [:flod]]

I commented in the PR too, but: is there a reason for switching away from the list of locales actually localizing Firefox for iOS to a broader list?

Even if you want the latter, "locales with a build for desktop on aurora" is not the list you're looking for.

Desktop on aurora (95)
https://hg.mozilla.org/releases/mozilla-aurora/raw-file/default/browser/locales/all-locales

Android single-locale builds on aurora 
http://hg.mozilla.org/releases/mozilla-aurora/raw-file/default/mobile/android/locales/all-locales

And you'd still need to filter out ja-JP-mac.

Comment 6

[Brian Nicholson (:bnicholson)]

I pulled the URL directly from your email a month ago:

> To get the actual list of locales we ship on Android, at least on single-locale builds, use this
> http://hg.mozilla.org/releases/mozilla-aurora/file/default/browser/locales/all-locales
> 
> I can't guarantee the sanity of searchplugins outside of that list. Like: a locale not actually shipping
> can have any kind of stuff in that folder.

But I should have double-checked. Good catch!

(In reply to Francesco Lodolo [:flod] (traveling, back 10 Jun) from comment #5)
> I commented in the PR too, but: is there a reason for switching away from
> the list of locales actually localizing Firefox for iOS to a broader list?

Yes; even if the rest of the app isn't localized yet, locale-specific search engines are incrementally better than no localizations at all. Karen specifically mentioned en-GB as a case where we do not want to default to Yahoo, but we don't have en-GB localizations yet. Without this PR, all missing locales would fall back to Yahoo as default (along with the rest of en-US engines), which we don't want.

Comment 7

[Francesco Lodolo [:flod]]

(In reply to Brian Nicholson (:bnicholson) from comment #6)
> I pulled the URL directly from your email a month ago:

Argh, huge failure on my side (searched for all-locales in my URL history and got the browser one).

> Yes; even if the rest of the app isn't localized yet, locale-specific search
> engines are incrementally better than no localizations at all.

OK, that makes sense. I assumed that we were use these searchplugins based on the enabled locale, which doesn't seem to be the case.

Comment 8

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

(In reply to Francesco Lodolo [:flod] (traveling, back 10 Jun) from comment #7)
> OK, that makes sense. I assumed that we were use these searchplugins based
> on the enabled locale, which doesn't seem to be the case.

Correct me if I am wrong, but I think we are actually selecting the search plugin based on the active locale. We have a bug for doing this based on the user's location I think?

Comment 9

[Brian Nicholson (:bnicholson)]

(In reply to Stefan Arentz [:st3fan] from comment #8)
> Correct me if I am wrong, but I think we are actually selecting the search
> plugin based on the active locale. We have a bug for doing this based on the
> user's location I think?

That used to be this bug. Using the engines from the user's locale gives us parity with Android, and we decided that that was sufficient for v1 (see comment 2).

Comment 10

[Francesco Lodolo [:flod]]

(In reply to Stefan Arentz [:st3fan] from comment #8)
> Correct me if I am wrong, but I think we are actually selecting the search
> plugin based on the active locale. We have a bug for doing this based on the
> user's location I think?

I'm not the one making decisions here, but comment 0 says "We need to use location-based search engines"...

If we're not doing that, I feel that we should just import search engines for localizations that we actually support.

Comment 11

[Brian Nicholson (:bnicholson)]

(In reply to Francesco Lodolo [:flod] from comment #10)
> If we're not doing that, I feel that we should just import search engines
> for localizations that we actually support.

But as I mentioned in comment 6, Yahoo is the default engine only for en-US. All missing locales will fall back to en-US, meaning all missing locales will point to Yahoo. Is it not at least a slight improvement for locales to see more relevant engines specific to them, even if the rest of the app isn't localized? Why leave them out if they've already been created and approved for mobile?

Comment 12

[Francesco Lodolo [:flod]]

At this point I'm not following the discussion:
* We show search engines based on the locale, not location.
* We're already picking search engines for all locales that want to translate this product.

In which scenario would you use the searchplugins for, let's say, Zulu?

Comment 13

[Brian Nicholson (:bnicholson)]

(In reply to Francesco Lodolo [:flod] from comment #12)
> At this point I'm not following the discussion:
> * We show search engines based on the locale, not location.

Correct.

> * We're already picking search engines for all locales that want to
> translate this product.

Correct, but the PR here will change this to also include all engines in general that are available on Android, whether that locale is translated or not.

> In which scenario would you use the searchplugins for, let's say, Zulu?

Zulu doesn't have an Android searchplugins directory (https://hg.mozilla.org/releases/l10n/mozilla-aurora/zu/file/default/mobile), so we'll be falling back to en-US search engines in that case. For any locale that does have an Android searchplugins directory, however, we will use it.

In short: if there is no translation for a locale but we have searchplugins for that locale, the search engine list will be tailored to that locale, but the rest of the app will be translated as en-US.

Comment 14

[Francesco Lodolo [:flod]]

> Zulu doesn't have an Android searchplugins directory

Zulu was clearly a bad example (not supported by any of the two).
 
> In short: if there is no translation for a locale but we have searchplugins
> for that locale, the search engine list will be tailored to that locale, but
> the rest of the app will be translated as en-US.

Let's say Greek (el). Is supported on Android, but not localizing iOS. In which scenario do I get Greek searchplugins? 

The phone is set to Greek as main language, but we don't have Greek. The locale detected by the app will be 'el' (with English strings), not 'en-US'?

Comment 15

[Brian Nicholson (:bnicholson)]

(In reply to Francesco Lodolo [:flod] from comment #14)
> Let's say Greek (el). Is supported on Android, but not localizing iOS. In
> which scenario do I get Greek searchplugins? 
> 
> The phone is set to Greek as main language, but we don't have Greek. The
> locale detected by the app will be 'el' (with English strings), not 'en-US'?

Right -- we're using NSLocale.preferredLanguages() to get the language the user has selected at the OS level, then finding the search engines based on that language code. The translations inside the app don't affect the set of preferred languages.

Comment 16

[Francesco Lodolo [:flod]]

(In reply to Brian Nicholson (:bnicholson) from comment #15)
> Right -- we're using NSLocale.preferredLanguages() to get the language the
> user has selected at the OS level, then finding the search engines based on
> that language code. The translations inside the app don't affect the set of
> preferred languages.

OK, then it makes absolutely sense to use
http://hg.mozilla.org/releases/mozilla-aurora/file/default/browser/locales/all-locales

Comment 17

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Comment on attachment 8617026 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/574

LGTM Sorry for the delay I was on PTO yesterday.

Comment 18

[Francesco Lodolo [:flod]]

(In reply to Francesco Lodolo [:flod] from comment #16)
> OK, then it makes absolutely sense to use
> http://hg.mozilla.org/releases/mozilla-aurora/file/default/browser/locales/
> all-locales

One day I'm sure I'll manage to write the right URL (we need Android searchplugins, so /mobile)
http://hg.mozilla.org/releases/mozilla-aurora/raw-file/default/mobile/android/locales/all-locales

Comment 19

[Brian Nicholson (:bnicholson)]

https://github.com/mozilla/firefox-ios/commit/c8bce48af8c11f9357f17b2f7a77c242b46b6034