Proposal: i18n.getAvailableLanguages()

[carlosjeurissen]

motivation for separate PR:
While a similar method has been proposed in https://github.com/w3c/webextensions/pull/641/changes#diff-a7a555f6d716353fea0a7a15523a1639b33556d7dee81e1e531c320a4f593fcfR70 as i18n.getAllLanguages. I believe splitting it into a separate proposal allows us to move faster for this specific method, considering just this method is already useful without i18n.setLanguage() and would be able to be used with the i18n.withLanguage() proposal. See #274.

A separate PR also allows us to dive deeper in the specifics of this method which seem very valuable.

open ends:

• should any other transformation other than _ to - be applied? ie, iw -> he?
  -> probably not, as this requires more advanced language negotiations in i18n.setLanguage() and i18n.withLanguage() and removes the use case for using fetch('messages.json').
• what if an invalid locale tag is used, like "_locales/b/messages.json"? Or a
  directory exists which does not contain a messages.json file?
  -> this seems to be mostly already handled when browsers validate the extension.
• what if the browser never intents to support a specific language in
  i18n.setLanguage('iw') or i18n.withLanguage('iw')? Should it be excluded
  in getAvailableLanguages?
  -> seems there are no real reasons a browser would avoid specific language tags with the exception of language tags not following bcp47 standards.
• do we want to reject if the extension is not localised, or return an empty array or return an array with the browser locale?
  -> when the extension is not localised, this method has zero use. It seems most intuitive to return a rejected promise in this case.
• do we want the returned list to be sorted alphabetically? Potentially put the default_locale at the top?
  -> sorting alphabetically by default seem to be enough to have same behaviour cross-browser. On the other hand, extension developers can easily use .sort() if requested. And may want to eventually sort the list based on human name.
• what about the name? @hanguokai suggested i18n.getAllLanguages(), @oliverdunk suggested i18n.getParsedLocalesDirectories before.
  -> other alternatives could be i18n.getAvailableResourceLanguages(). All and Available could be ambiguous.

[Rob--W]

Could you show an example of how the API would be used in practice for this use case?

I'm wondering what a browser-defined API can provide that is not already possible by the extension. I'd expect that the extension can pre-generate a list of supported languages in relation to the files output to _locales/, which would be far more efficient than what a browser can offer.

You have already mentioned this possibility in the "Existing Workarounds", so it is clear that you are aware of the possibility.

[carlosjeurissen]

Updated the proposal to include the practical example.

The browser-defined API would allow to list the intersection of languages the browser recognises and the extension includes. As mentioned, the set of resource files can be different depending on the extension store.

For Naver Whale specifically, I have a build script which removes unsupported resource files from the extension package after being built. There are even custom scenarios in which too many resource files requires the removal of the majority of resource files. In these scenarios, updating the set of supported languages in some JS file would add another layer of already complex build setup.

[oliverdunk]

Similar to Rob, I'm not convinced that there are use cases which justify the addition of this API.

Adding a build step which exposes the bundled languages to your extension at runtime seems reasonable to me. The API would not provide anything which you could not also achieve in this way.

I can see value if we add the ability to set your extension's locale programatically. At that point, it is useful to know which of your locale directories the browser has parsed. However, it would make sense to add both APIs at the same time (as we discussed in #641), instead of just adding this API in isolation.

[carlosjeurissen]

@oliverdunk thanks for taking a look at the proposal!

First of all, #641 has been stalled for more than a year and has not seen any progress since. Other APIs like the proposed i18n.withLanguage() would go well with i18n.getAvailableLanguages(). Having i18n.getAvailableLanguages() stuck in the i18n.setLanguage() proposal could block it's usage for i18n.withLanguage().

There are many reasons this API is useful in isolation even before i18n.withLanguage() and i18n.setLanguage() are available. besides the build step complexity listed above and the extension store compatibility. There is also the use case of being able to polyfill i18n.withLanguage() and i18n.setLanguage(). With i18n.getAvailableLanguages() one would be able to have a third party dependency polyfilling these potential future APIs. Thus especially now when i18n.withLanguage() and i18n.setLanguage() are not available, i18n.getAvailableLanguages() would unlock these use cases.