Most APIs with multilingual support allow clients to specify which natural languages are preferred using the Accept-Language HTTP header. For example, Accept-Language: fr, en means the client prefers French but will accept English. If no Accept-Language header is present, the API assumes that all languages are equally acceptable.
As demonstrated in the following subsection, in all except JSON formats, it is easy for an API to respond with content in all available languages and for clients to parse the content consistently, because there is a unique, standard approach to language tagging in those formats.
Until a unique, standard approach to language tagging emerges for JSON, to simplify the JSON response, if no Accept-Language header is present, the API should respond with content in the single, default language. If an Accept-Language header is present, it should respond with content in a preferred language where possible, and use the default language otherwise.
XML uses the xml:lang attribute, for example:
<rdfs:label xml:lang="en">cat</rdfs:label>
<rdfs:label xml:lang="fr">chat</rdfs:label>
HTML uses the lang or xml:lang attributes, for example:
<span lang="en">cat</span>
<span lang="fr">chat</span>
N3, Turtle and N-Triples use language tags, for example:
"cat"@en
"chat"@fr
JSON-LD offers several ways to indicate the language of a string, whether by:
using a value object:
{
"rdfs:label": [
{
"@value": "cat",
"@language": "en"
},
{
"@value": "chat",
"@language": "fr"
}
]
}
using a language map:
{
"@context": {
"rdfs:label": { "@container": "@language" }
},
"rdfs:label": {
"en": "cat",
"fr": "chat"
}
}
associating a language with a term
{
"@context": {
"label_en": { "@id": "rdfs:label", "@language": "en" },
"label_fr": { "@id": "rdfs:label", "@language": "fr" }
},
"label_en": "cat",
"label_fr": "chat"
}