"internationalization" section

[aphillips]

Internationalization
https://w3c.github.io/manifest/#internationalization

This section currently reads as follows:

It is expected that authors will localize the content of a manifest by using one of the following options:

• Dynamically setting the language:
  • This can include, for instance, asking the end-user what their preferred language is and dynamically adding or replacing the manifest link relationship to the document based on that language preference (e.g., using a URL like "manifest.php?lang=fr").
• Using content-negotiation, or geotargeting, etc. on the server:
  • The server that hosts the web application could attempt to predetermine the end-user's language by using geotargeting or by using content negotiation (e.g., using [RFC7540]'s "Accept-Language" header, or even a custom HTTP header).

Given the options above, developers need to be mindful of the end-user's privacy with respect to their preferred language: When the end-user has explicitly indicated their language preference to a web application (i.e., when not just using the user-agent default language settings), sending the end-user's preferred language in the clear over the wire is generally not OK. Doing so would reveal personal information about an end-user. As such, developers are encouraged to use [TLS] to reduce the chances of pervasive monitoring of their Web applications [RFC7258].

The I18N WG notes that (as noted in a number of our other issues), the manifest spec does not provide mechanisms for localization of the manifest. I18N has a WG Note specifically about manifests (https://www.w3.org/TR/localizable-manifests) which might be helpful in designing language support.

The suggestion to "replace the manifest link relationship" is slightly at odds with the later recommendation not to send a user's language preference over the wire in the clear, since path, file, or parameter values in the URL involve sending a language tag.

Note that dynamic setting of the locale for the application's runtime (which is mostly what is described here) is not the same thing as the localization of the information provided in the manifest, which is generally used to provide a representation of the application on the user's device when the application is not running (that is, the information is not dynamic after installation). Also, most users prefer that their language choice be "sticky" between sessions, so that they don't have to constantly choose or switch the language to meet their needs. Finally, they prefer that the manifest description (name, icon, etc.) match their local locale settings.

I18N WG thinks that it would be helpful for our groups to have some joint discussion, as there are multiple issues involved in negotiating and managing user locale preferences and a reasonable amount of experience in the I18N and localization community about what works.

[marcoscaceres]

@aphillips, meeting would be great. Should we find time during TPAC?

[dmurph]

@loubrett Are you going to be available during TPAC for a remote session? I'm guessing we would need to schedule the meeting early in Seville so it would be evening in Sydney.

[christianliebel]

@aphillips With #1101 being merged, can we close this?

[dmurph]

I think we can close this. During the joint discussion, @aphillips was present and the solution we came to is the one we spec'd.

Please re-open if the localization solution in #1101 doesn't work.

[aphillips]

I approved of #1101 at the time and we did discuss it. Thanks!!