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

Thanks @marcoscaceres. In terms of the potential pitfalls you've noted (which are excellent call outs by the way), I've actually thought a bit about those and would love your opinion on them:

* In terms of fetches, as the Manifest is fetched late so as not to block, and only (at present) used at install time, it seems reasonable that the fetch for an additional language file would also be late and, more importantly, as needed. In other words, if my Accepts Language is other than the Manifest language and matches one of the external keys, only then would the external data be loaded. UAs would not be expected to download language files they don't need (much like how UAs only grab `icons`they can use).
* If the network request fails, the default language remains. Not ideal, but, again, this mirrors the behavior of ImageResource references.
* if the JSON is invalid, same thing.
* Regarding import loops, my feeling was that we would not allow a linked language file to include a `translations` member (and would likely have other reasonable limits as well, so as to avoid wholly redefining the app in a potentially destructive ways. If devs need to while redefine the app, they need to swap the Manifest using the current method (not `translations`).

I agree on keeping things simple, but I also cringe thinking about the potential manageability issues that could arise with multiple translations & features (e.g., shortcuts) in the same file. It's possible folks could turn to a build process to do the final merge of multiple files into the Manifest, but I don't know I want to push people that way unnecessarily.

-- 
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-817850548