Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorporate LTLI's requirements #70

Open
aphillips opened this issue May 12, 2022 · 2 comments
Open

Incorporate LTLI's requirements #70

aphillips opened this issue May 12, 2022 · 2 comments
Assignees

Comments

@aphillips
Copy link
Contributor

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.

@aphillips aphillips self-assigned this May 12, 2022
@xfq
Copy link
Member

xfq commented Dec 19, 2023

Related: w3c/ltli#16

@aphillips
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants