Order-matching is a bad idea

[aphillips]

Complex translations example
https://github.com/WICG/manifest-incubations/blob/gh-pages/translations-explainer.md#complex-translations-example

To ensure translations for these complex constructs do not get out of sync with their counterparts in the original arrays, it’s imperative that developers pay close attention to both the number and order of array members.

For values that can be repeated/are arrays (e.g. icons, shortcuts, screenshots, and shortcuts/icons), the design relies and depends on matching the order and number of items to be localized in the core manifest to the items in the translations block. This is brittle and inconsistent with how translations are actually done (as well as with sparse population that is sometimes used with locale fallback). It means, among other things, that a manifest cannot be released unless and until every string is localized (or a placeholder provided).

It's not clear to me why the complex items don't just contain translations blocks, e.g.:

"shortcuts": [
  {
    "name": "Pet Me",
    "url": "/pet-me",
    "translations": {
        "fr": "Caressez-moi",
        "ja": "ヨシヨシして"
    }
  }
],

[loubrett]

That explainer is quite out of date sorry. The latest proposal (w3c/manifest#1045) doesn't rely on order matching - it has translation blocks for each localisable member within a complex object.

Example from the proposal:

{
    "shortcuts": [
        {
            "name": "Play Later",
            "localized_names": [{ "value": "Jugar Mas Tarde", "lang": "es" }],
            "url": "/play-later",
        }
    ]
}

[aphillips]

@loubrett Thanks.

Note that name does not have a language tag or direction of its own. Thinking out loud: is there a reason that name is privileged? The I18N purist in me thinks it would be better to have a set of localized names with one serving as the default, e.g.

{
   "defaultLocale": "en",
   "shortcuts": [
      {
         "url": "/play-later",
         "name": [
            {"lang": "en", "Play Later"},
            {"lang": "es", "Jugar Mas Tarde"},
            {"lang": "ar", "ألعب لاحقا", "dir":"rtl"}
         ]
      }
   ]
}

[loubrett]

name is an existing field so we unfortunately can't change it for backwards compatibility reasons. I guess the manifests top level lang and dir field apply to the name field.

Apps could put all translations in the localised_names field (including repeating whichever language is in the name field) in which case the name field would just be ignored, but it would still need to be there for backwards compatibility.

[aphillips]

Actually, I18N has a WG Note track document that discusses the design choices and implications called Localizable Manifests. It is mercifully short 😉 but addresses a number of considerations found in our issues list.