Add option for localisation

[jstarpl]

I think it would be great if, from the get-go, we would have an option for these strings (which are user-presentable) to be localizable. Obviously, a fallback to a simple string is neccessary, but making sure that these strings can be localized in 1.0 of this spec will mean that localization will be at least taken into account by implementers in some basic way.

tmp-GraphicsDefinition/definition/definition/json-schema/lib/action.json

Lines 6 to 13 in a677653

	"label": {
	"type": "string",
	"description": "The name of the action. This is displayed to the user."
	},
	"description": {
	"type": "string",
	"description": "A longer description of the action. This is displayed to the user."
	},

W3C proposes this format: https://www.w3.org/TR/localizable-manifests/#language-maps for "Unitary manifests" , which I think is simple enough to use:

{
  "key": {
    "en": {"value": "Some string"}
    "fr": {"value": "Une variable de chaîne"}
  }
}

I think going for a "Unitary manifest" rather than using content negotiation at the HTTP level, makes sense since it will allow the end User Agent to make the decision which localization to use.

[nytamin]

I wonder if another approach could be the "hybrid approach": https://www.w3.org/TR/localizable-manifests/#hybrid ?

We could have a default manifest.json file but also allow for additional, localized manifest files, eg manifest-sv-se.json, manifest-de.json, manifest-en.json etc..

That way it would reduce the minimal implementation needed (just ignore the additional files), and no transforms needed by the Server when serving the manifests.

[nytamin]

Notes from a talk with @jstarpl:

It would probably be best to not go with the hybrid approach, and rather have all translations in the on manifest file, as this would add no requirements on the Server, and allows the Server to expose all translations in one go, putting the load of interpreting the localized data on the Controller - which should be well suited to handle this anyway.

[nytamin]

Notes from talk in the HTML group.
To minimize the impact for system that don't support localization at all, it was proposed to go with the following approach:

{
  label: "This is a label", // fallback, can be used by any system that doesn't support any localization
  label-localized: { // Optional, contains localizable strings
    "en": "This is a label",
    "sv-se": "Detta är en etikett",
    "fr": "Ceci est une étiquette"
  }
}