Re: [w3c/manifest] Add optional `translations` member (#676)

I've got similar concerns about this (and just this week, we had a team having trouble localizing their manifest). I'm starting to think we could explicitly support translations of user-visible strings (like the name and description) in the manifest itself, which would implicitly give stores an indication of what languages the app supports.

The link above gives two localization suggestions:

1. Dynamically setting the language (using in-site UI to point at a different manifest URL for each language).
2. Using content-negotiation, or geotargeting, etc. on the server (serving a different manifest contents based on the user's chosen language).

Neither of these are great options. Option 1 interferes with the idea that "manifest == app". Depending on how the implementation keys apps off manifest URLs, changing the URL (even changing the query string) could cause the user agent to think of it as a different app. For example if you install `manifest.php?lang=en` on Chrome on Machine A, then install `manifest.php?lang=fr` on Chrome on Machine B, then Chrome Sync happens, we may consider these different apps and you'd end up with both versions on both machines. This is user-agent specific issue, but only because we haven't properly specified how apps are keyed. (#586)

Option 2 fixes that, but it means you have to have dynamic logic on the server side, which precludes any static hosting solutions like github.io. (Whereas the rest of the site UI can be localized in JavaScript, the manifest data cannot be.)

Finally, if the language solutions involve literally changing the bytes of the manifest, it means that when the user changes language, apps will remain in the originally installed language until the user agent re-pings the server with the new Accept-Language, redownloads the manifest, and updates the metadata. (On Chrome Desktop, we haven't even implemented updating yet, so you're stuck with your original language until you update.) Whereas if the manifest declaratively included all the translations, the user agent could automatically update all the UI with the correct strings as soon as the user changes language.

Therefore, I think it would be better if we actually let you put your localizations in the one manifest file itself. What are the downsides of this (besides potentially a much larger file)?

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