We need to support setting engines by region. I'll summarize what I understand from that chat and Mike can correct any misunderstanding. The purpose of the overrides is to change the search urls/params based on the location of the user. e.g. When traveling in the US, you would get the US google and ebay searches. regionOverrides was added prior to all engines being shipped in Firefox, so some use of it was during build to include additional engines in a given build. He looked at what the 3 top locale builds were used in a given region, and provided the overrides for those. Currently regionOverrides is tied to the filename of the opensearch files. "US": { // filename: filename "google": "google-2018" }, That says, when in the US, use google-2018.xml instead of google.xml (which was used for all other regions) "BE": { "ebay": "ebay-be", "ebay-nl": "ebay-be", "ebay-fr": "ebay-be" }, Here, where ebay.xml is the default, change any region using the default to BE region. Also change nl and fr regions to be. All other regions remain as default. So, for example, ebay-de would not be changed, which is the complicated part of this. To support this for webextensions, I would propose the following structure: "regions": { // key is the region that the user is located in. "US": { // engineName: [ regions to change to US region ] "google": {override: ["*"]} // support * for all regions "ebay": {override: ["*"]}, }, "BE": { "ebay": {override: ["NL", "FR"], default: "BE"} } } By default, we [already] select the region engine for the locale that the users OS runs under. So a US user will always have US region search engines except for where they are overridden. So *-BE will load the BE region. We only need to handle overrides on that. With the BE example above, Firefox configured to run in *-NL, *-FR would load the ebay for BE when the user is located in the BE region. The "default" value is used for any region that is not supported in the ebay extension. Given the default here, a de-DE firefox user would NOT be switched to BE, but an es-AR user WOULD be switched to BE since the ebay extension does not have AR in it. One change in behavior with this example is that a en-US Firefox user would NOT be changed to BE when traveling there. Given the language dynamics of the US, I actually think that is the right behavior, but we'd need to verify that is ok to do with mkaply and/or BD. It is less likely that US users are going to know the other languages these overrides would use. If we do want the US to be overridden, then we just add "US" to the override list. The US region example says that all Firefox users will run the US region when located in the US. Note the use of upper case in the new format. locales are language-REGION, or en-US. Unfortunately, overall, list.json uses a mixed bag of full locale, region, and language. We're probably going to have to do some kind of fixup logic for the locale selection in extensions to get this right, or add an ability to pull a locale by region alone. Or maybe we can use a map in list.json for those regions that may have more than one language: "regionMap": { "CA": "en-CA" // because we could have fr-CA },

@mkaply, can you look over the above for any issues and/or corrections?

This looks good to me, but it begs the question how we are going to get the region in WebExtensions. Querying the search preference?

(In reply to Mike Kaply [:mkaply] from comment #2) > This looks good to me, but it begs the question how we are going to get the > region in WebExtensions. Querying the search preference? I have a plan over in bug 1488516 that might clarify that.

Duped because part of other bug, per mixedpuppy.