search

w3c / bp-i18n-specdev

Internationalization Best Practices for Spec Developers
https://w3c.github.io/bp-i18n-specdev/
Other
26 stars 17 forks source link

Incorporate LTLI's requirements #70

Open aphillips opened 2 years ago

aphillips commented 2 years ago

See comment on #33. LTLI's requirements around BCP47 are much more specific and complete and address e.g. how JS handles Unicode locales in Intl (among other things). Time to synchronize our requirements.

xfq commented 11 months ago

Related: https://github.com/w3c/ltli/issues/16

aphillips commented 2 months ago

Prepping the merge, here are some notes:

ones that need adding to specdev:

Formulations such as "RFC 5646 or its successor" MAY be used, but only in cases where the specific document version is necessary. Specifications MUST NOT reference obsolete versions of [BCP47], such as [RFC1766] or [RFC3066]. Specifications that need to preserve compatibility with obsolete versions of [BCP47] MUST reference the production obs-language-tag in [BCP47]. Applications that provide language information as part of URIs (e.g. in the realm of RDF) SHOULD use [BCP47]. Specifications SHOULD NOT reference [BCP47]'s underlying standards that contribute to the IANA Language Subtag Registry, such as ISO639, ISO15924, ISO3066, or UN M.49. (well-formed vs. valid requirements) Specifications MAY reference registered extensions to [BCP47] as necessary. Specifications SHOULD NOT restrict the length of language tags or permit or encourage the removal of extensions. Specifications that define language tag matching or language negotiation MUST specify whether language ranges used are a basic language range or an extended language range.

​ Specifications that define language tag matching MUST specify whether the results of a matching operation contains a single result (lookup as defined in [RFC4647]), or a possibly-empty (zero or more) set of results (filtering as defined in [RFC4647]).

​ Specifications that define language tag matching MUST specify the matching algorithms available and the selection mechanism. Content authors SHOULD choose language tags that are canonical Unicode locale identifiers. Implementations SHOULD only emit language tags that are canonical Unicode locale identifiers and SHOULD normalize language tags that they consume using the rules for producing canonical tags. Content authors SHOULD NOT include language tag extensions in a language tag unless the specific application requires the additional tailoring. Specifications that present fields in a document format SHOULD require that data is formatted according to the language of the surrounding content. Specifications that present forms or receive input of non-linguistic fields in a document format or application SHOULD require that the values be presented to the user localized in the format of the language of the content or markup immediately surrounding the value.

​ Specifications that present, exchange, or allow the input of non-linguistic fields MUST use a locale-neutral format for storage and interchange.

​ Implementations SHOULD present non-linguistic fields in a document format or application using a format consistent with the language of the surrounding content and are encouraged to provide controls which are localized to the same locale for input or editing.

ones that need update in ltli:

Specifications for the Web that require language identification MUST refer to [BCP47]. Specifications SHOULD NOT refer to specific component RFCs of [BCP47].