Note: Since we require all proposal document PRs to have an associated issue. This is the dedicated issue for i18n.getAvailableLanguages(). For which we have an open proposal document PR in #942
Background
Currently extensions can not easily get a list of supported languages without hardcoding them first or need to rely on fetch try and error.
Proposal
This is why we need an API like i18n.getAvailableLanguages() #942
An API which allows extensions to get a list of BCP47 language tags containing
the languages the browser can use and the extension provides resource files for.
Use cases
- Allow to list the languages for extension settings language pickers.
- Use the list of supported languages to match a specific website when applying a content script.
- Have this list independent of distribution (As some extension stores disallow certain language tags).
- Allow third parties to create polyfills for i18n.withLanguage() and i18n.setLanguage().
Regarding implementing i18n.getAvailableLanguages() before any of the other proposals (#258 and #274) 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.
Note: Since we require all proposal document PRs to have an associated issue. This is the dedicated issue for
i18n.getAvailableLanguages(). For which we have an open proposal document PR in #942Background
Currently extensions can not easily get a list of supported languages without hardcoding them first or need to rely on fetch try and error.
Proposal
This is why we need an API like
i18n.getAvailableLanguages()#942An API which allows extensions to get a list of BCP47 language tags containing
the languages the browser can use and the extension provides resource files for.
Use cases
Regarding implementing
i18n.getAvailableLanguages()before any of the other proposals (#258 and #274) first of all, #641 has been stalled for more than a year and has not seen any progress since. Other APIs like the proposedi18n.withLanguage()would go well withi18n.getAvailableLanguages(). Havingi18n.getAvailableLanguages()stuck in thei18n.setLanguage()proposal could block it's usage fori18n.withLanguage().There are many reasons this API is useful in isolation even before
i18n.withLanguage()andi18n.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 polyfilli18n.withLanguage()andi18n.setLanguage()Withi18n.getAvailableLanguages()one would be able to have a third party dependency polyfilling these potential future APIs. Thus especially now wheni18n.withLanguage()andi18n.setLanguage()are not available,i18n.getAvailableLanguages()would unlock these use cases.