Specify localization handling

[dotproto]

PR #61 introduces prose that more fully describes two manifest keys, name and short_name. The text for both of these keys tee up the topic of localization handling by stating "This property can be localized." The immediate question this phrasing raises is, "how?"

• Describe the default_locale manifest key
• Describe locale-specific messages files
• Describe how a locale JSON file is selected
• Describe how placeholders are replaced with localized text

Related prior art to consider when specifying localization behavior includes:

• The Locale Message Replacement section of the BECG's Browser Extensions spec.
• https://www.w3.org/TR/appmanifest/#ref-for-dfn-localizable-members-4

[carlosjeurissen]

Part of this also includes what language codes to support. This greatly varies between browsers. Google prefers es_419 for example, while microsoft edge uses es_MX.

Then there is the Naver Whale Store which doesn't allow submissions with non-country suffixes like:
zh_Hant, zh_Hans, zh_Hant_HK. sr_Latn and ca_valencia

[dotproto]

Thanks for calling out that browser and their respective stores don't all agree on the same set of language codes. That's definitely something we will need to figure out how to navigate. If we can't arrive at a consensus on a single set of language codes among browser vendors, we may have to specify around this issue.

[xfq]

Just FYI - the W3C Internationalization Working Group is working on a document for Developing Localizable Manifests.

[carlosjeurissen]

Something else to add here is the difference between the browser language (i18n.getUILanguage) and the language websites are requested in (i18n.getAcceptLanguages). Depending on what the extension does in the browser, there are cases when the extension prefers to use translations based on i18n.getAcceptLanguages instead of i18n.getUILanguage. For example, in content_script contexts.

[carlosjeurissen]

The issue in Naver Whale store related to language codes which are not accepted can be found here:
https://forum.whale.naver.com/topic/39749/

The reply from Naver Whale so far is that they don't plan to make changes here. Even tho it would be ideal to simply ignore the unsupported language codes.

[carlosjeurissen]

@dotproto We can add to your list of action items the following:
Defining how language fallbacks are used. Currently browsers have a very specific algorithm to fetch a translation.

As input, the messageId is given. And the browser knows the browser UI language. Say this is es_419. The browser will then first try finding a es_419/messages.json file, and if found and the message is there, use it. If not, it will look for a es/messages.json file and find the message in this file. If it's not present either, fall back to the language defined in default_locale.

[carlosjeurissen]

Something else to add here is the difference between the browser language (i18n.getUILanguage) and the language websites are requested in (i18n.getAcceptLanguages). Depending on what the extension does in the browser, there are cases when the extension prefers to use translations based on i18n.getAcceptLanguages instead of i18n.getUILanguage. For example, in content_script contexts.

A potential way to implement this would be to accept a language as input for i18n.getMessage. This would also make it easier for developer to allow the user to set a specific language used in the extension. See https://crbug.com/660704

[carlosjeurissen]

As mentioned here, related to localization. Seems it makes sense to deprecate i18n.getAcceptLanguages. See: #107

[carlosjeurissen]

As mentioned by @dotproto in this Google Group:
https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/6ff8460f-68df-4d50-8128-f50a8a84c9ccn%40chromium.org

The chrome web store and chromium used to tolerate comments in language locale messages.json files. Yet at least for the store dropped this support to align with manifest.json and standard json specs.