(In reply to Mike Connor [:mconnor] from comment #10)

Hey folks, we're going to have to go back to the drawing board on this
front. Locales like en-US are not regions, and MUST NOT (in the RFC sense)
be used to infer regions. Don't even use it as a fallback. Happy to
explain in more detail offline.

Lets do have that discussion, since I don't understand the distinction you're making here.

We're not inferring the users region from the locale, or at least nothing has changed in that aspect. I'm not familiar with the gritty details of how the search service decides on the region the user is in. To my understanding, we use the users locale as the base, then get the location (and thus region) they are in, and check to see if we need to override the defaults from their locale. IIUC We also update the regionOverrides, or maybe even the entire list.json, from some service.

What we are doing is using the l18n system already built into the webextension system as a way to deal with the various differences, which are in fact locale based. The search service can then override which locale is used base on the region the user is located in. The locale and override data from list.json already provided the capability to drive which locales are used to generate the manifest data from the extension to support all the current use cases contained in list.json.

The search service can also decide how it wants to failover if a given locale is not in the extension because the patches here provide a way to get a manifest in a specific locale. However, failover already works essentially like this:

1. user locale + override region if present
2. user locale
3. default locale defined by extension (unless extension has only one locale, then that)

#2 and #3 are simply how things work in extensions. #1 is driven by the search service.

For a en-US user traveling in CA, where CA has overrides, it would look like:

1. en-CA
2. en-US
3. whatever default_locale is in manifest

Given the above, a US user in CA could/would have different urls in extensions that provide an en-CA locale.

Google has a US specific search file, and another for everywhere else. Using the above, we would simply have en-US and en. Users traveling in the US would get the en-US locale if the override were:

regionOverrides: {
"US": { "google": "google-en-US" }
}

Likewise, currently an en-US user traveling to NL would get a different ebay url due to the NL override (exactly as-is in list.json):

"NL": {
"ebay": "ebay-nl"
},

Note: In the opensearch world, the above names are the filenames of the xml files. In the webextension world, the key is the extension name, the value is what we want to use. The value is parsed into the extension name and locale to be loaded from the extension.

Do you want to setup a meeting to discuss?

Dale will take over D9136
MDB will look at D9135 and maybe integrate into the refactor he is doing.
That leaves D9134 for right now, which can land without the others, so lets see about getting review started there.

I'm not sure what you're asking me for?

(In reply to Andrew Swan [:aswan] from comment #14)

I'm not sure what you're asking me for?

sorry, didn't realize that phab did not have you as reviewer.

As discussed in this morning's standup

• this is at least parity with what we've done before
• We'll have the flexibility to do more on the search service side as we move forward
• we're not going to be constrained by a * the use of locale codes if we need to handle weirder cases, e.g. en-US-de for an English version of a German site.
• we'll need to make sure at least the following items can be localized for variants:
  • search URLs
  • suggestion URLs (not discussed, but definitely true)
  • icons
  • display names
  • description text

So we're good to keep moving. I have an action to file a followup describing the business configuration requirements for the long term. That's looking like end of week.

This has merged from cedar, closing.

Can you please add some STRs to this issue or mark it as "qe-verify- " if no manual testing is needed ?

There's nothing on this that can be directly QEd, but the upcoming search changes (see bug 1517486) will likely have some QE elements.