Allow name to be a String or Language Map

[jasnell]

For the sake of i18n... allow the name property to optionally take the form of a json-ld style language map. e.g.,

{"name": "Like This"}

or

{"name": {
  "en": "Like This",
  "fr": "comme ça"
 }
}

[jhazen66]

I concur.

[jasnell]

Related to (but not duplicating) #208

[marcoscaceres]

@jasnell good suggestion. I guess the only thing missing then would be the default_locale.

{"name": {
  "en": "Like This",
  "fr": "comme ça"
 },
 "default_locale": "en"
}

I think I like this more than what FxOS does:

{
    "name": "foo",
    "locales": {
        "es": {
            "name": "El foo"
        }
    },
    "default_locale": "en"
}

Which is a total mess to write and maintain.

[kenchris]

Generally servers (and even app stores) should be able to generate the manifest in the local language, but I do see a use of this for packaged apps and for the ease of development.

So we need to define which properties support this. I don't want people to change behavior (say CSP!) given locale.

[jasnell]

An argument can be made for having one manifest doc per language (e.g. but that potentially causes unnecessary duplication of the rest of the metadata in the manifest. Sure, there are ways around that but if we make the basic assumption that manifest files are static documents, adding a simple language context would be easiest.

As for which properties ought to support it, "name" is currently the only language sensitive property in the manifest. You could, perhaps, say something about language sensitive extension properties but that would be overkill at this point. Keep it simple, limit it to just "name" for now.

As a point of reference, json-ld uses "@language" to establish the default lang. That @ is ugly tho. I would go with just "language" as opposed to "default_locale". Less to type :-)

So the two acceptable forms would be:

{
  "language": "en",
  "name": "Foo"
}

// or

{
  "language": "en",
  "name": {
    "en": "Foo",
    "es": "El Foo"
  },
  ...
}

Update: I take that back.. looking over at the other issue (#208) we'll likely (optionally) want to provide alternatives for the start_url and possible icons as well. For start_url, the same language map pattern can be used:

{
  ...,
  "language": "en",
  "start_url" : "/start.html",
  ...
}

// Or
{
  ...,
  "language": "en",
  "start_url" : {
    "en": "/en/start.html",
    "sp": "/sp/start.html"
  }
  ...
}

For icons, adding a "language" tag to the icon properties would suffice:

{
  ...,
  "language": "en",
  "icons": [{
        "src": "icon/en/lowres",
        "sizes": "64x64",
        "type": "image/webp",
        "language": "en"
      },
      {
        "src": "icon/sp/lowres",
        "sizes": "64x64",
        "type": "image/webp",
        "language": "sp"
      }
  ],
  ...
}

[marcoscaceres]

@jasnell yes, the model has to apply to all members (except for language or whatever we end up calling this). Making exceptions/special cases is annoying for all.

[marcoscaceres]

... though I agree it makes sense to special-case for things that are already objects, like icons 😉. That's also a good suggestion. I'm just really hopeful we can keep the structure really flat (i.e., 3 levels max). I've seen some of the manifests in the FxOS store and they are a JSON nightmare.

[marcoscaceres]

So... general rules for i18n:

1. if type of member is not object or array (i.e., string, number, etc.), then use a i18n-object whose members are case-insensitive BCP47 language tags.
2. if object - gets a lang property.

Need to work out what to do when language is missing from root. Need to also decide if BCP47 "lookup" is supported, etc.

[marcoscaceres]

Loosely related - hopefully we can end up with a unified model: #168

[kenchris]

I'm not so happy about that.

"csp":"..." is a string, and it shouldn't differ pet language / locale

[marcoscaceres]

@kenchris what difference does it make if it does? It's not really any different than changing it dynamically on the server (through, say, php).

[jasnell]

csp is not likely to vary from language to language unless, perhaps, the origins themselves are bound to language (e.g. en.example.org, sp.example.org)... but that would be... odd. Not sure what to recommend there.

[marcoscaceres]

@mounirlamouri would like your input on this. This has significant impact on the processing model.

[stasm]

One advantage of the approach Firefox OS uses is that the keys of the locales dictionary can be used as the canonical list of all languages the webapp is available in. With the approach suggested in this issue, there would be no single list of locales and the information about available languages would be split across the name and start_url members (and possibly more in the future) where it would be easier for it to get out of sync.

{
    "name": "foo",
    "locales": {
        "es": {
            "name": "El foo"
        }
    },
    "default_locale": "en"
}

Here, the languages the webapp is available in are es and en.

Having a canonical list of available languages is useful for client-side language negotiation, for instance with ECMA-402 Intl's SupportedLocales.

In Firefox OS, we're hoping to be able to use manifest.webapp files to convey the information about the available languages for webapps. See https://groups.google.com/forum/#!topic/mozilla.dev.gaia/K38ucraKX1k.

[marcoscaceres]

@stasm, wouldn't it make more sense to just have a available_langs property?

The structure that FxOS uses makes the JSON a nightmare to read and write, because it splits data across two places + adds a lot of deep nesting. It also forces developers to localize data that they might not otherwise have to in order to indicate the available languages.

[stasm]

@stasm, wouldn't it make more sense to just have a available_langs property?

Yes, that would indeed be ideal. Should I file a separate issue for this?

The structure that FxOS uses makes the JSON a nightmare to read and write, because it splits data across two places + adds a lot of deep nesting.

This is by no way representative but from my experience working with Mozilla products, there always has been an automation script that took care of building the right set locales into an application. We'd feed a config file to it and it would produce the right manifest/INI file/directory structure etc.

It also forces developers to localize data that they might not otherwise have to in order to indicate the available languages.

That's a good point!

[stasm]

Yes, that would indeed be ideal. Should I file a separate issue for this?

Alternatively, would you mind reopening #208?

[marcoscaceres]

Reopened #208

[chaals]

There seems to be some mixing of language and locale in the discussion. Are we actually talking about "language" optionally being a language-locale tuple, or keeping two things separate?

(we do different default things for en-RU and ru-RU, or ru-RU and ru-KZ)

[chaals]

copying here from #211 the idea that instead of a default-locale, the first one mentioned is the default

[h0ru5]

how about linking the alt-languaged ones, e.g.:

{
  "alt-lang" : {
      "tr" : "/locales/tr.manifest",
      "de" : "/locales/de.manifest",
      "..."
   }
}

[marcoscaceres]

Moving to V3 train. Want to see what comes back from a few weeks of manifest being in the wild with Chrome Beta.

[stasm]

My earlier comments here mixed the data required for language negotiation and the localization of the manifest fields themselves. With the language negotiation being discussed in #208, I don't think such mixing is a good idea. I agree with what @marcoscaceres said above in #211 (comment) that the current approach used in Firefox OS results in unwieldy JSON structures. It also requires a prior knowledge of which fields should be looked up in the locales section. The original proposal in this issue avoids both problems. I like it!

[marcoscaceres]

Closing this for now. See #208 (comment)

Once we get a better idea about how people are using this, we can reopen and add this to the spec.