multiple natural language text fields share language/direction [I18N]

[xfq]

https://www.w3.org/TR/appmanifest/#web-application-manifest

The manifest provides a number of members. These start with dir and lang, but the subsequent natural language members don't appear to have their own dir/lang associated with them . It may not be possible to produce a manifest that has different language or base direction strings in it. The members in question are:

• name
• short_name
• Shortcut item's name
• Shortcut item's short_name
• Shortcut item's description
• Image resource's label (note that it's not a localizable member currently)

---

Mirror issue in the MiniApps Manifest: w3c/miniapp-manifest#4

I would be happy to organize a joint meeting between WAM and MAM folks to find a common solution (and maybe with the i18n WG if needed) per https://www.w3.org/2021/04/01-miniapp-minutes.html (and https://www.w3.org/2020/08/26-manifest-minutes.html)

See also https://w3c.github.io/pub-manifest/#manifest-lang-dir-local

[aarongustafson]

Related: #676

[dmurph]

I think this issue deserves fully support by the manifest spec so that one manifest can serve multiple languages.

However, I wonder if, after #446 this is possible to handle through manifest updating. Manifests are usually served on already localized websites, so the manifest itself can be differentially-served based on the language.

If the user changes their language, the linked manifest would change, and the spec would allow any of these natural language text fields to be updated. Perhaps this is good enough support for CR?

[aarongustafson]

@dmurph I feel like translations (which is making progress) should resolve this. @xfq Have you looked at that proposal yet?

[dmurph]

That proposal seems pretty nice to me.

[xfq]

@dmurph I feel like translations (which is making progress) should resolve this. @xfq Have you looked at that proposal yet?

Yes, I looked at the proposal. If I understand correctly, the problem solved by that proposal is different from the problem to be solved in this issue. You can read my explanation for the miniapp folks in w3c/miniapp-manifest#12 (comment)

[aarongustafson]

Yes, I looked at the proposal. If I understand correctly, the problem solved by that proposal is different from the problem to be solved in this issue. You can read my explanation for the miniapp folks in w3c/miniapp-manifest#12 (comment)

I totally understand where you're coming from. We talked a bit about string replacement previously, which is how I've handled translations in the past, but the main issue is that it breaks backwards compatibility. I've also gotten pushback on maintaining separate translation files, so I suspect that will be a hard sell too.

[xfq]

According to my understanding (please correct me if I'm wrong):

• "string replacement" refers to something like the proposal in Allow name to be a String or Language Map #211 , and
• "maintaining separate translation files" refers to something like Chrome extensions, which creates a separate file/directory for each supported language or locale.

Both approaches intend to solve the problem of translation/localization, not the problem of the language and direction metadata of the strings itself. There is no way to override the language and direction for a specific natural language text field. See the "String metadata" part of w3c/miniapp-manifest#12 (comment) .

[xfq]

See also https://www.w3.org/TR/2020/REC-json-ld11-20200716/#example-77-overriding-default-language-and-default-base-direction-using-an-expanded-value for an example in JSON-LD.

[aarongustafson]

@xfq Sorry, I got distracted by the string replacements in that section you linked to. The translations approach would allow for dir to be adjusted for each set of translations and the language code for that block is the key for the in the ManifestOverride block. More on that in this PR. You’re right that it wouldn’t allow for arbitrary language (and direction) switching within a string, nor would it allow for arbitrary language shifts to be handled within the root manifest (e.g., description in English, name in Swahili), but it should do enough to allow for complete localization of an app in terms of the host OS.

Do you have specific use cases in mind where individual fields would need to exist in different languages? It might help to start with that.

The external files option is a follow-on proposal, but is not likely to land anytime soon (if it ever does).

[aarongustafson]

nor would it allow for arbitrary language shifts to be handled within the root manifest (e.g., description in English, name in Swahili)

Actually, I take that back. You might be able to do something like

{
  "dir": "ltr",
  "lang": "sw"
  "name": "Tembo",
  "translations": {
    "en": {
      "description": "Never forget where you put your keys with our revolutionary technology."
    }
  }
}

We need to define what happens when a key exists in translations that is not in the root Manifest, so… if we allowed you to define values that are undefined in the root Manifest, that might solve for your issue.

[aarongustafson]

@xfq Would the above solution work for your use case?

[xfq]

I don't think this works for our use cases. We have a document dedicated to string metadata related use cases: https://www.w3.org/International/articles/lang-bidi-use-cases/

[aarongustafson]

@xfq Thanks for that. I totally feel for you on the problem. Yeah, That’s going to be a really hard nut to crack in the Manifest, given that we only support text strings. Are you looking to resolve this within the JavaScript String constructor as well? It seems like once a solution is worked out there, we should be able to piggyback on that approach in the Manifest.

As this is not a problem we are going to solve in the Manifest spec and we are uncertain when a workable solution is likely to land, I am going to mark this as deferred. When a solution is created, I suspect we’ll update the Internationalization section. Please ping this thread again when there is a solution for JavaScript/JSON.

[aarongustafson]

The state of this is:

1. The forthcoming translations member will allow for individual member values (including direction) to be overwritten for individual language codes.
2. For shifts in natural language/direction within a string, we’re in the same boat as HTML attributes (and ECMA String) in that we are not able to support that at present beyond what’s possible in UTF-8 with Unicode BiDi support. Some higher-level approach for managing that will be necessary first and then we can reference that. This is not a problem the Web Apps team is scoped to solve, it’s something someone’s text editor should address.