authenticationlangFor instance, a service could expose the following minimal service manifest: @@ -430,17 +437,6 @@
- Following [[RFC9110]], services SHOULD use the Accept-Language header to let clients select the language in which user-facing text is returned.
- They SHOULD use the Content-Language in their responses to expose the language each response is returned in.
-
- Examples of user-facing text in service responses are: the name of the service and the name of property configuration fields in the manifest, the name and description of entities, types and properties, - the contents of the entity preview pages, and the documentation linked in the manifest. -
-@@ -904,6 +900,48 @@
The following sections rely on terminology from the W3C internationalization best practices for spec developers, + in particular on the distinction of two types of language declaration:
++ The language of the intended audience, also referred to as language metadata, is used to describe the language(s) of the intended audience of resources as a whole. In the context of reconciliation, + this is relevant e.g. for setting the user interface language in a reconciliation client, providing user-facing text in the user's preferred language. +
++ The text-processing language on the other hand declares the single language in which a specific range of text is actually written in, to support features like text-to-speech, spell checking, or hyphenation. + In the context of reconciliation, this distinction is importat since the actual data being reconciled will often be in a different language than the client's user interface. +
+
+ Following [[RFC9110]], services SHOULD support the Accept-Language header to let clients specify the language of the intended audience in which user-facing text is returned.
+ If clients set the Accept-Language header, the requested language(s) MUST be provided as well-formed [[BCP 47]] language tags.
+ Services MAY use the Content-Language header in their responses to expose the language(s) of the intended audience(s) of each response.
+ If services set the Content-Language header, they MUST use valid (i.e. found in the [[IANA Language Subtag Registry]]) [[BCP 47]] tags.
+
+ Examples of user-facing text in service responses are: the name of the service and the name of property configuration fields in the manifest, the name and description of entities, types and properties, + the contents of the entity preview pages, and the documentation linked in the manifest. +
+All objects used in this protocol (entities, types, properties, queries, candidates, features, etc.) MAY declare an explicit text-processing language in a lang field.
+ The lang value MUST be a single valid (i.e. found in the [[IANA Language Subtag Registry]]) [[BCP 47]] language tag. This text-processing language applies to the natural language fields of the object: name, description,
+ query (for reconciliation queries), v and str (for property values). Nested objects inherit the text-processing language of their parent, and can override it by setting their own lang value
+ (see example below). A default text-processing language for any natural language string returned or processed by a service MAY be set in the lang field of the service manifest.
+ Client and service implementors SHOULD consider the text-processing language to ensure correct processing of natural language content.
In the following example, we first set the text-processing language for a reconciliation query to en, which is inherited by the first property, and overridden in the second property with zh-Hant:
+
+ + +@@ -933,22 +971,6 @@
All objects used in this protocol (entities, types, properties, queries, candidates, features, etc.) MAY declare an explicit
- text-processing languge in a lang field. The lang value MUST be a single well-formed [[BCP 47]] language tag. This text-processing languge applies to the natural language fields of the object: name, description,
- query (for reconciliation queries), v and str (for property values). Nested objects inherit the text-processing language of their parent, and can override it by setting their own lang value
- (see example below). Client and service implementors SHOULD consider the text-processing languge to ensure correct processing of natural language content.
In the following example, we first set the text-processing language for a reconciliation query to en, which is inherited by the first property, and overridden in the second property with zh-Hant:
-
- - -If no explicit text-processing language is given, the metadata language (the language of the intended audience) provided first (see service definition) is considered the default text-processing language.
-