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

Whoa there, @kenchris! Let's keep this simple. Although we should consider the development aspect of this, it's definitely not on the same level as the security disasters that can occur with getting CSP wrong (and hence the need for Reporting). Let's take minimum viable solution as a start then build up from there. We can leave it to the developer community to build good tooling to solve these kinds of problems, like Lighthouse does. We probably don't need to get the browser to do that.

@aarongustafson, 

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

I think this can be solved by a (relatively simple) generator and tooling. It Node, it would be super simple, while not requiring the fetching, and avoiding validations/network problems, etc.:

```JS
import { promises } from "fs";
const { readFile, writeFile } = promises
const translations = [];

// Modified the proposal to just use an array :)
for (const lang of ["zh", "jp", "fr", "and so on..."]) {
  const translation = await readFile(`./${lang}.json`);
  translations.push(translation)
}

const manifest = {
  "short_name": "whatever",
  lang: "en",
  translations,
};

await writeFile("manifest.json", JSON.stringify(manifest, null, 2));
```
 
Generally speaking, we need consider the division of labor here: we don't need to solve all the development problems in the browser. We can just offload that to tooling.  


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