-
-
Notifications
You must be signed in to change notification settings - Fork 250
Localization
Localization covers translating an interface into multiple languages, for international audiences.
JSON Schema is not designed to be interacted with by end users, and labels (the "title" and "description" keywords) are primarily targeted at developers. While there's no requirement for a schema to use any particular language, JSON Schemas are typically written in English.
This is partially because JSON is a bulk data format, not well intended for editing by users. It is primarily consumed by machines, and the de facto language of Internet protocols is English. Is it likely expected that the vocabulary the schema is describing will not change between languages, so it is reasonable to assume the title keywords shouldn't change any more than the API does.
Additionally, JSON Schema documents are not supposed to change frequently, and unless the author intends to translate strings to every anticipated language, storing localized strings in schema documents might not be well advised.
However, there's several alternatives that could be applied together to resolve these problems:
-
An ability to reference a separate translations file. This could be a gettext po file, or a parallel schema that updates more frequently, but is not required for validation.
-
Versions of keywords that support multiple language-tagged strings.
For example, a validation schema might link to an annotation-only schema, that has "title" as an object, with language tags as keys.
The Web typically requires different documents for different language versions of a resource. These documents may link to each other with a rel=alternate link specifying the target language. User agents that understand this link relationship can suggest to users there's an alternate version of the document in their native language, if one exists.
HTTP can have resources that can send one of several different variants, the selected version depends on the user's advertised preferences in Accept-Language. The specific version that the server selects is declared in a Content-Location header. This response can still include rel=alternate links, so that a user-agent unhappy with the negotiated result can select a more suitable version.