Closed aphillips closed 1 year ago
I believe this is solved in the latest proposal (https://github.com/w3c/manifest/issues/1045):
"Language selection is generally done using Unicode’s “lookup” algorithm, meaning that it’s not a simple match. The solution may also be inadequate in that it doesn’t allow specifying per member direction and language override. If individual direction and language is a requirement, then the following object structure is more appropriate:
{ "text": "some text", "dir": "ltr|rtl|auto", "lang": "language-tag" }
"
Thanks for this. I haven't read #1045 fully yet, but the Unicode lookup algorithm would be appropriate for selecting translations. There are some different considerations about whether to incorporate all translations into a given manifest vs. using separate files (path-based localization), which may be more manageable when the number of localizations grows.
If you think this issue has been addressed, you're welcome to close it (do not remove our tags, which are used for tracking).
There was discussion about whether to have translations all in the manifest or in separate files. I think the decision was to keep it all in the one place to begin with for simplicity but to potentially keep the option open to allow using separate files in the future.
(general) https://github.com/WICG/manifest-incubations/blob/gh-pages/translations-explainer.md
There is no description for how language tags in the
translations
block are matched or how locale fallback is handled. At a minimum this should specify RFC4647 (BCP47) "Lookup" matching, although CLDR and Unicode locale matching is probably preferred.