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

This is a topic we are trying to solve for in the context of the Microsoft Store and we recently revisited everything in this thread (and in [the awesome doc @mgiuca prepared](https://github.com/w3c/manifest/issues/676#issuecomment-441534555)) in that context. We evaluated the options on a couple of deltas:

* Ease of implementation, both with an without build processes in place,
* Compatibility with common localization workflows,
* Applicability in simple and complex cases, and
* Ability to inform a digital catalog of the available languages.

With all of this in mind, we were thinking it might make sense to offer developers a couple of approaches:

## Approach 1: Alternate manifests

This is the current recommendation and can work well for sites that have no issues maintaining/generating multiple static manifest files or who have the capability to dynamically generate a manifest on the server side. This is 3B in Matt’s doc and, in practice, could look like this for folks who want to be declarative: 

```html
<link rel="manifest" href="manifest.json">
<link rel="alternate manifest" href="fr/manifest.json" hreflang="fr">
```

or in a dynamic sense, using the `accept-language` header via server- or client-side logic ([which @marcoscaceres discussed back in 2014](https://github.com/w3c/manifest/issues/208#issuecomment-44298944)):

```html
<link rel="manifest" _href="manifest.json?lang={{ ACCEPT_LANGUAGE }}">_
```

This approach works well and has no compat issues because it’s the currently recommended approach. It serves many use cases, but a downside is that it does not allow app catalogs to know what languages are available. It also isn’t a great solution for folks that don’t have a system in place to generate dynamic manifests on the server or as part of some build step. For those use cases, there’s Approach 2.

## Approach 2: The `languages` (or `translations`) member

Based on the discussion, the `languages` member, indexed by language code, makes a lot of sense. It enables translations of individual fields to be done on an ad hoc basis with a straightforward fallback to the default language of the manifest itself. Adapted from Matt’s doc:

```json
{
  "name": "Good dog",
  "description": "An app for dogs",
  "icons": [],
  "screenshots": [],
  "lang": "en",
  "languages": {
    "fr": {
      "name": "Bon chien",
      "description": "Une application pour chiens",
      "icons": [],
      "screenshots": []
    }
  },
}
```

This approach is simple and straightforward, allowing devs to pick and choose which keys to redefine in the alternative languages (with `lang` being perhaps the lone exception, but perhaps we’d want to restrict `start_url` and others too).

One additional thought we had, after reflecting on what y’all had discussed, was whether it might be possible to have each language definition be either an object or an external reference to a json file containing the keys. Text is pretty small, of course, but this might enable the manifest to remain as small as possible (you might imagine that each translation could include a dozen screenshots, shortcuts, etc., which might become a manageability problem in the main mainfest file). UAs could then selectively choose which manifest language file to load when parsing the manifest file, based on the user’s language setting. This would look like 3A in Matt’s document:

manifest.json:

```json
{
  "name": "Good dog",
  "description": "An app for dogs",
  "icons": [],
  "screenshots": [],
  "lang": "en",
  "translations": {
    "fr": "manifest.fr.json"
  }
}
```

manifest.fr.json:

```json
{
  "name": "Bon chien",
  "description": "Une application pour chiens",
  "icons": [],
  "screenshots": []
}
```

If it is possible to enable the value supplied for each language to be either a URL or an object, this kind of flexibility could be quite useful to developers and the translation management systems they are having to work with. It could even lend itself to supporting the dynamic approach we currently recommend:

manifest.json:

```json
{
  "name": "Good dog",
  "description": "An app for dogs",
  "icons": [],
  "screenshots": [],
  "lang": "en",
  "translations": {
    "fr": "manifest.json?lang=fr"
  }
}
```

An additional benefit to Approach 2 is that the default manifest’s enumeration of the supported languages is easy to consume and can be used to expose that information on the app’s product description page.

Would appreciate y’all’s thoughts on the feasibility of a hybrid approach like this.

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