Closed Bug 1166389 Opened 5 years ago Closed 5 years ago

Include all Android search engines in iOS

Categories

(Firefox for iOS :: General, defect)

All
iOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
fennec + ---
fxios + ---

People

(Reporter: bnicholson, Assigned: bnicholson)

References

Details

Attachments

(1 file)

We need to use location-based search engines. I think mconnor has more details.
Sounds like Karen is OK with simple methods for determining the location
tracking-fennec: ? → +
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).
We already have support for different languages and regions, so it's just a matter of importing the remaining search engines from Android.
Assignee: nobody → bnicholson
Status: NEW → ASSIGNED
Summary: Geo-based search engines → Include all Android search engines in iOS
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.
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.
(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.
(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?
(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).
(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.
(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?
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?
(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.
> 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'?
(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.
(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 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.
Attachment #8617026 - Flags: review?(sarentz) → review+
(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
https://github.com/mozilla/firefox-ios/commit/c8bce48af8c11f9357f17b2f7a77c242b46b6034
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.