It's a request to support UI language switcher add-ons via WebExtensions. Add-ons as these are Locale Switcher and Simple Locale Switcher (the mine): https://addons.mozilla.org/en-US/firefox/addon/locale-switcher https://addons.mozilla.org/en-US/firefox/addon/simple-locale-switcher The Chrome API, so far I know, only provides the string i18n.getUILanguage to know the current language of the UI (the one what will be applied to new windows). As the access to about:config via WE isn't possible, a WebExtensions API for it should provide, at least: * The preferred language for the UI: the exact one set by the user via some prefs in about:config or via the -UILocale command-line parameter. * The list of all available languages for the UI: the one provided by the application plus any others available via language packs. * Be possible to change the preferred language. * Be possible to listen to events for the change of the preferred or the available languages. * Let to offer to the user to restart the application after switching the language, so the new language can be applied to the existent windows. This interaction with the user could be managed by the API itself, or let to add-ons manage the UI for it. Bug 1344786 is related to the latter. * To know if the preferred UI language is got from Firefox trying to match the language of the operative system instead of reading a fixed value (aka the intl.locale.matchOS pref is true, as it's shipped by default by most of Linux distributions). * I have not checked if the strings from chrome://global/locale/languageNames.properties and chrome://global/locale/regionNames.properties are accesible in some way for WebExtensions. If they aren't, it should be so add-ons don't require to ship with themselves all the languages names in all language. I have played a bit with WebExtensions experiments; I could give a try to it first.

I'm one of the engineers working on the Intl/L10n system in Gecko. I'd love to see what you're describing and can help you get the right API set. We just recently centralized Gecko around a single new API: mozilla::intl::LocaleService which reads, negotiates and serves the language selection. So, in order to *tell* the user what is the UI language (fallback chain), you just need to do: (mozI)LocaleService.getAppLocalesAsBCP47 (or AsLangTags depending on if you want to expose the Mozilla-like tags, or BCP47 compliant ones). In order to *change* the languages, that's a little bit more tricky, because the UI languages are negotiated between available ones and requested ones. So, you can easily change the *requested* languages - `LocaleService.setRequestedLocales(['de', 'pl', 'en-US']);` - but that will only affect the UI languages, if we have resources for them. I'm not sure how you'd want to facilitate it. You may want to use `LocaleService.getAvailableLocales` for the list of locales that the user can select from, and then when the user selects a new locale, update the requested locales. That, in result, should give you the expected behavior. > * I have not checked if the strings from chrome://global/locale/languageNames.properties and chrome://global/locale/regionNames.properties are accesible in some way for WebExtensions. If they aren't, it should be so add-ons don't require to ship with themselves all the languages names in all language. I would suggest not to use those (in fact, we should overall get rid of that), and use ICU instead which provides the list of languages and region names for us. Depending on if WebExtensions have access to C++ behind the door, you may use ICU directly, or we may want to expose some JS API on `mozIntl` to give you ability to translate those terms. > * To know if the preferred UI language is got from Firefox trying to match the language of the operative system instead of reading a fixed value (aka the intl.locale.matchOS pref is true, as it's shipped by default by most of Linux distributions). This is an interesting use case, I haven't thought about it yet. We currently use the concept of "empty list" of requested locales as an indication that the locale should be taken from the OS, so for example we have `LocaleService.setRequestedLocales([]);` to trigger "matchOS" behavior. We also have `OSPreferences.getSystemLocales` which you can use to retrieve the list of locales set by the user for the OS. But because of the way Gecko worked before our transition, in `LocaleService.getRequestedLocales` we'll return locale set by the user in the app, and if the user set `matchOS`, we'll take the OS locale. That means that there's no observable way to say if the locale is "matchOS" or not except of a dirty hack in form of reading the "intl.locale.matchOS" pref. Maybe we could just do `LocaleService.appLocaleMatchesOS` boolean attribute? All in all, I hope it helps you get started, and if you file bugs for features in LocaleService, I'll be happy to take them and add the APIs you need.

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #1) > We just recently centralized Gecko around a single new API: > mozilla::intl::LocaleService which reads, negotiates and serves the language > selection. I noted all that work only recently, and I didn't checked it yet. I expect to do it soon. > In order to *change* the languages, that's a little bit more tricky, because > the UI languages are negotiated between available ones and requested ones. > > So, you can easily change the *requested* languages - > `LocaleService.setRequestedLocales(['de', 'pl', 'en-US']);` - but that will > only affect the UI languages, if we have resources for them. > > I'm not sure how you'd want to facilitate it. Me neither, due to the fallback chain to set the language not being before exposed to changes, so I haven't thought about it. > You may want to use > `LocaleService.getAvailableLocales` for the list of locales that the user > can select from, and then when the user selects a new locale, update the > requested locales. That is the way that add-ons have been doing until it. I will continue with this approach to start. > All in all, I hope it helps you get started, and if you file bugs for > features in LocaleService, I'll be happy to take them and add the APIs you > need. I will do that. After that, being already familiar with LocaleService, I will try to write a WE experiment on top of it.

Hi folks, is there a chance, that benjamin smedbergs could update his famous "Locale-Switcher" extension http://benjamin.smedbergs.us/switch-locales/ to Webextensions? First to have a start on this in the new WE-world. Second, as an example how things can be done with the new environment. I'm curious to see some progress here. Thanks, Nick

I am still willing to work in a WE experiments for it, but from some comments in bug 1368507, I need some sort of confirmation that I will not waste my time doing it.

Hi Carlos, this has been added to the agenda for the November 28, 2017 WebExtensions APIs triage meeting. Would you be able to join us? Here’s a quick overview of what to expect at the triage: * We normally spend 5 minutes per bug * The more information in the bug, the better * The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details Relevant Links: * Wiki for the meeting: https://wiki.mozilla.org/Add-ons/Contribute/Triage * Meeting agenda: https://docs.google.com/document/d/1MduEIKmXDdj3p94PJDrPPPYvbSfEdrrMF-UhMnHPqEQ/edit#heading=h.edrw957gm8hg * Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

(In reply to Caitlin Neiman [:caitmuenster] from comment #5) > Hi Carlos, this has been added to the agenda for the November 28, 2017 > WebExtensions APIs triage meeting. Would you be able to join us? Via IRC, yes.

Heads up that this may want to wait for bug 1414390. We currently have a fairly limited API that allows to only set a single locale, like: `Services.intl.setRequestedLocales(["pl"]);`. The bug will allow us to work with locale lists: `Services.intl.setRequestedLocales(["de", "it", "fr"]);` which is what I believe we should use for this API here. It'll also make us sanitize language tags and reject badly formatted ones.

I'm going defer this gandalf for feedback since he knows a lot about the localisation framework and our plans here. I'm not sure what the API should like or how it would work. One big concern that the team was that some of the requested APIs "Let to offer to the user to restart the application after switching the language, so the new language can be applied to the existent windows.", we currently don't have a single API in WebExtensions that force a restart and we've done everything we can to make WebExtensions restartless and we'd like to keep that the case. The next concern is that while we don't require APIs to work on other platforms, we should consider it. I'm sure you can change language in Chrome and other browsers. Any API should try to take that into account and if possible use APIs that could possibly be ported. i.e. let's try to avoid adding something that has no chance of ever being ported through wierd naming or syntax. It sounds like based on comment 1, I think gandalf is all for it and willing to help out, so that's probably a good sign and we can probably mark this as approved, would that be case?

> "Let to offer to the user to restart the application after switching the language, so the new language can be applied to the existent windows." I would be against this part of the feature. I believe the only role of this API would be to expose: - `Services.locale.setRequestedLocales` - `Services.locale.getRequestedLocales` - `Services.locale.getAvailableLocales` - `Services.locale.getAppLocalesAsBCP47` (as "getAppLocales") > Any API should try to take that into account and if possible use APIs that could possibly be ported. i.e. let's try to avoid adding something that has no chance of ever being ported through wierd naming or syntax. I think that the notions of requested, available and applocale are quite universal. Handling a list of BCP47 strings in all of them also seems quite standardized and universal and I'd expect a potential Chrome API to look the same. The one thing that we do plan to extend to in the future for LocaleService is to allow for `categories` of locales. A use case is a user requesting ['pl', ru'] for Firefox, but ['en-US'] for devtools. We may want to add an argument to the APIs to allow for passing the category name the data is requested/set for. So any WebExtensions API should make room for such future extension, but that seems to be easy to do, just wanted to mention it :) > I think gandalf is all for it and willing to help out, so that's probably a good sign and we can probably mark this as approved, would that be case? Yes. Once we land bug 1414390. We will eventually have a UI for language switching, but I wouldn't mind allowing extensions to control that as well, and also before we get to land the Prefs UI.

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958