Re: [w3c/manifest] [DRAFT—DO NOT MERGE/REVIEW] Add members for localization (PR #1101)

Perhaps we should clarify what "localize URLs" means.

Are we talking about:
* Localizing all fields that are URLs? (e.g. `start_url`, `scope`, potential future ones like the home scope of tabbed apps).
* Localizing all fields called "`url`", like the ones in icons and shortcuts?
* Something else?

I think we generally agree that we need to localize icons, but we're doing that at the `icons` level, not the `url` within icons (i.e. `icons_localized` with a local version of each icon dict, not `icons` with the icon dict including a `url_localized`. Allowing both of these creates two ways to do it which isn't ideal.)

Maybe it makes sense for URLs like shortcuts to be able to change based on language, but really the point of this initiative (I thought) was to be able to localize your app's metadata that gets displayed at the OS level, like name and icon, not to solve the problem of localizing all the content in the app. (If you can't configure your server to serve content based on headers, you can still make your service worker return localized content based on Accept-Language.) An app that relies purely on the manifest URLs to display content in the user's language is likely to be quite brittle.

I think we could run into major headaches if we allow `scope` to be localized. And by extension, `start_url`. (e.g. `scope` must be a superset of `start_url` - what happens if that's true in some languages but not others?)

I prefer if we just start with `name`, `short_name`, `description` and `icons` and go from there as needed.

> How does `dir` interact with the localised members? Can it safely be derived from language?

This was [discussed at TPAC](https://docs.google.com/document/d/1RIaeXT_-j8n4iGPI3odZyJTqtHCKqe3oWZTO-j21z9U/edit#heading=h.5i48hfw584ma) (search for "dir") - unfortunately when I asked this question, the answer was not recorded ("?"). From memory, @aphillips pointed out that we may not know the language's direction because languages are not set in stone. I think the overwhelmingly common case will be a known language, which means we should be able to derive `dir` from `lang` in all practical cases (and probably default to `ltr` if we don't recognize the language - the overwhelming majority of languages are LTR). We should have the `dir` member for being explicit, but I think in 99.9% of cases the site should not need to specify `dir` as it can be derived from language.

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

Message ID: <w3c/manifest/pull/1101/c1813836668@github.com>