Re: [w3c/manifest] Application name section might need localization support (Issue #1088)

@jcayzac This section contains instructions on setting the application's name from the `name` and `short_name` fields present in the manifest, including instructions for what to do when the fields are missing or damaged. Since localization is not fleshed out in other parts of the specification, it's possible that changes to handle language negotiation or fallback might affect the instructions found here--this issue is thus kind of a "placeholder" to remind us all to review this in light of other changes regarding localization.

With regard to "the standard web content negotiation mechanism", that is one way to solve the localization problem. The Manifest spec doesn't document this as **the** mechanism to use (and there are good reasons why an implementation might embellish, change, or adopt an alternate approach). It might not be wise for Manifest to totally specify how the language is negotiated.

There are a couple of problems with the mechanism as you've outlined it:

- there is a trend for user agents to send smaller `accept-language` headers, possibly containing only the runtime locale of the localhost. This locale may not be supported by the application, in which case the server will need to perform defaulting or use other mechanisms (the spec mentions geotargetting, for example). There is still a good chance that the negotiation doesn't work the way the user would like. If my browser specifies `fr-FR` and you only have `en-US`, `es-ES` and `de-DE` (with English as the default), I might be disappointed if I would have preferred e.g. Spanish as my fallback. Less common languages are particularly beset in this way (if my system is set up to run in Basque, I want to fall back to `es` or maybe `fr`, not a variety of `en`).
- some applications might wish to have static manifest files rather than generating them dynamically, the better to edge cache or reduce server load. Since manifests can only currently be in exactly one language, this could mean having lots of files. Manifest has no mechanism for enumerating what is available, so the burden might fall onto the caller to find the right one.
- the spec also defines a `link` type. The page author might wish to specify a particular locale (commonly done when the page author wants the application to run in the same locale the calling page is using--usually chosen at the behest of the user--rather than that of the localhost of the user agent). The spec gives an example like `manifest.php?lang=fr`. While it might be out of scope for Manifest, there might be features of Manifest to assist in getting the right locale to the page author or end user, vs. having an opaque and application-specific mechanism that works differently for each application.

All of the above (and probably some other cases) suggest that, as we discuss whether and how to augment manifests with additional locale information or localization, we might need to come back and revisit application name defaulting rules 😄 

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

Message ID: <w3c/manifest/issues/1088/1549007636@github.com>