From bb8b9f2a6f8230f5790211696a6fa1f2515cce84 Mon Sep 17 00:00:00 2001 From: "@aphillips" Date: Fri, 7 Aug 2020 11:11:26 -0700 Subject: [PATCH] Add error and message handling section per: [I18N-ACTION-940] --- index.html | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/index.html b/index.html index 4235104..c7ae049 100644 --- a/index.html +++ b/index.html @@ -1625,6 +1625,25 @@
Background

When formatting numeric values for display, allow for culturally sensitive display, including the use of non-ASCII digits (digit shaping).

+

Localization

+ +

Localization [[LTLI]] enables users to employ software in the language and locale of their choice. Specifications for protocols and document formats need to consider how to provide the language and formatting that the end-user expects.

+ +

APIs and protocols SHOULD provide language independent identifiers for errors. For example, HTTP result codes, such as the familiar 404 help users communicate which error they received or look up a translation.

+ +

APIs and protocols SHOULD include language and direction metadata for all natural language messages, including errors, to ensure proper presentation, even if localization is not provided. See also [[STRING-META]]

+ +

All natural language fields or messages, including error messages, defined by a given API or protocol SHOULD be localized into the preferred locale of the user or, if that language is not available, supplied with a suitable fallback or default.

+ +

Specifications for APIs or protocols SHOULD define how the user's locale is determined (this is called language negotiation).

+ +

Specifications MAY define a specific default language for messages or errors in an API or protocol.

+ +

Note that specifications do not need to require that messages be returned in all possible or all available locales.

+ + +
+