Re: [w3c/manifest] Add support for defining a theme color for both light & dark modes (prefers color scheme) (#975)

aphillips left a comment (w3c/manifest#975)

@dmurph A thing to be careful of is that locales ( == language tags) have fallback. For example, `fr-FR` => `fr` => `root` (default resources). This is another reason why we like language maps: the language tag is visible on the outside, making it easier for people managing translations or variations to spot/organize the translations.

Anything that's defined as UX should be localizable. Some things, such as icons, might only be localized in a few languages. Other things might be localized nearly all the time. The mechanism for localization should be orthogonal to the "mechanical" aspects of selecting the correct resource (size/orientation/etc.) and there should _always_ be a clear default resource that the developer writes (or is required to write) and that is used when locale-specific values are not provided or not available for a given request.

@marcoscaceres suggests that:
>  we change the key to a space-separated list of language tags

This could make things complicated, since the list must be parsed into tokens which are then prefix compared to the requested locale. In practice, localizers are more likely to want separate entries anyway. The rest of your example is good, from the point of view that there is a clear "source" (`icons`) for all of the `icons_localized` that acts as the `root` locale entry. The localized icons only override the source when provided.

```
{
  "icons": [{},{},{}],
  "icons_localized": {
    "fr": [{},{},{}],    // selected for fr, fr-FR, fr-BE, fr-*
    "fr-CA": [{},{},{}]  // selected for fr-CA
  }
}
```

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

Message ID: <w3c/manifest/issues/975/3861625815@github.com>