No language/direction metadata for shortcuts?

[aphillips]

1.1.4 Creating shortcuts
https://w3c.github.io/manifest/#creating-shortcuts

Multiple examples are provided of creating a "shortcut" in a manifest. Here is one such:

  "shortcuts": [
    {
      "name": "Play Later",
      "description": "View the list of podcasts you saved for later",
      "url": "/play-later",
      "icons": [
        {
          "src": "/icons/play-later.svg",
          "type": "image/svg+xml"
        }
      ]
    },

The name and description fields do not have their own lang and dir values nor does the "shortcut" structure have the ability to provide an override. The whole manifest does have a lang and dir, but this doesn't allow for separate localizations nor for local overrides of the values. I18N normally recommends the ability to provide a local override when there is file-level metadata.

This design also suggests that some language is more privileged than all others or that large sections of the file must be repeated in order to localize the full experience described by the manifest.

[tomayac]

See #1045 and #676. There's a specific label already.

[tomayac]

Sorry, @aphillips, realizing that this is part of a bigger i18n-needs-resolution effort. Reopening.

[aphillips]

@tomayac thanks! Feel free to mark as duplicate any of the items I just filed or to link to on-going work.

[aarongustafson]

This is part & parcel of the translations work, no? Once we solve it for the manifest overall, it'll be solved for shortcuts. We don't need a before solution just for shortcuts.

[christianliebel]

#1101 would not introduce language/direction metadata for shortcuts; they will continue to inherit this information from the manifest itself, which seems very logical to me. However, specifying language/direction metadata for their localized versions would be possible.

@aphillips I’ve configured the PR to close this issue. If this is not sufficient, let me know.

[aphillips]

@christianliebel Ideally one could override the language or direction of the shortcut separately, but the need to do this should be rare. The localized values have the ability to override their own associated language tag (super rare) and provide their own direction (common for the localized case, but rare for the default value).

I don't think you need to overcomplicate the format to support this, given that, for most applications, the actual string will come from the localized versions (or the application will be entirely use the default).