Application name section might need localization support

[aphillips]

Application's name
https://w3c.github.io/manifest/#application-s-name

The application's name is derived from either the name member or short_name member.

This section describes how the name is assigned from the name and short_name values (and how to name the application when these are not available). There is no discussion of localization here.

[jcayzac]

@aphillips I'm confused. Is this to support usecases where the manifest isn't fetched, but stored offline? If not, the current web manifest standard support localizability through the standard web content negotiation mechanism:

1. User agent sends the accept-language header (also accept, which affects what formats the server may return).
2. Server-side decides what resource to return.
3. User agent gets the best resource in the best resolved language.

For a web manifest, the server side would map the URL to a resource best matching the languages specified by the user agent (accept-language), or even filter the content of the manifest to strip any resource (icon etc) that is not in a format supported by the user agent (accept header). This has worked well for many years now.

[aphillips]

@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 😄