Re: [w3c/manifest] Add optional `translations` member (#676)

Playing a bit of catch-up here. I am not advocating for/against anything here, but re-raising this with the I18N WG. If I might suggest, this looks like an opportunity for a deeper discussion between our WGs (and maybe also ECMA-402 or Unicode's MessageFormat WG).

@mguica noted:

> The idea of a "main language" is needed for two reasons:

I agree that there should be a default language. This often corresponds with the *source* language (the language that developers working on the code write into resources and which is later translated). In most systems, this also corresponds to the `root` locale resource file. That is, the fallback when searching for translations and the fallback in the locale system (that formats your dates and numbers and such) are on the same hierarchy. That is, the `lang` is more likely to be `und` or blank rather than being (e.g.) `en` (or some other specific language).

@marcoscaceres is correct that most platforms have the advantage of being able to bundle separate resource files without the penalty of having to separately download each. Web applications often bundle or group languages into blocks to avoid having multiple HTTP GETs in order to populate their resources. 

I'll note that most localization processes are built around and have a strong preference for taking a "source file" and translating the contents to produce a "target language file". It is much more complicated for most localization teams to deal with multi-language files (and multilingual files are harder to work with--consider a file with Japanese, Arabic, Hindi, and French in it!). Even with good Unicode support, the chances for damage is higher when things are mixed together.

@FluorescentHallucinogen Thanks for pointing out the icon preferences example! Note that this might not be linked to locale, since a locale is not the same thing as a customer's physical location. Icon changes and other branding variations are often linked to country- or region-specific services or app versions instead (and other things, such as regulatory requirements or data retention policy is also often linked to business locality). 

Cycling back to the very start of the issue, note that language/locale matching is important here. Examples of language tags like `en`, `fr`, and `zh` ignore that there are often regional variations (`pt-BR` for example) or script variations (`sr-Cyrl`, `zh-Hans`, etc.) in the translations--or that app authors want to support more locales (without having to list them) than they provide localization for.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/676#issuecomment-1194594118
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/676/1194594118@github.com>