Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Order-matching is a bad idea #71

Open
aphillips opened this issue Apr 6, 2023 · 4 comments
Open

Order-matching is a bad idea #71

aphillips opened this issue Apr 6, 2023 · 4 comments
Labels
i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on. translations

Comments

@aphillips
Copy link

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": "ヨシヨシして"
    }
  }
],
@aphillips aphillips added the i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on. label Apr 6, 2023
@loubrett
Copy link
Collaborator

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
Copy link
Author

@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
Copy link
Collaborator

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on. translations
Projects
None yet
Development

No branches or pull requests

3 participants