From b400ac9a87f758a4a8d5fe373c96e07aba398eca Mon Sep 17 00:00:00 2001 From: Fabian Steeg Date: Tue, 12 Dec 2023 12:59:28 +0100 Subject: [PATCH] Add section to define the two types of language declaration (#136) Based on the W3C docs: https://www.w3.org/TR/international-specs/ & https://www.w3.org/International/questions/qa-text-processing-vs-metadata --- draft/index.html | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/draft/index.html b/draft/index.html index b35efb7..3ea52e6 100644 --- a/draft/index.html +++ b/draft/index.html @@ -914,10 +914,20 @@

Data Extension Responses

Internationalization Considerations

+

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. +

Language of the intended audience

- Following [[RFC9110]], services SHOULD support the Accept-Language header to let clients specify the preferred language in which user-facing text is returned. + 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. @@ -930,8 +940,8 @@

Language of the intended audience

Text-processing language

-

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, +

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.