-
-
Notifications
You must be signed in to change notification settings - Fork 36
Constraints on @locale values #452
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
Comments
I think we should instead use https://cldr-smoke.unicode.org/spec/main/ldml/tr35.html#Unicode_locale_identifier. |
@macchiati ULIs are one of the options listed. I do note that the requirements on ULIs have the disadvantage of not being strictly linked to the BCP47 grammar, that is, it is necessary to process the tag to know if it conforms. Implementations may not all have the ability to do the necessary validation and canonicalization. Perhaps we could say something like:
|
I'm not completely certain how to express it, but in practice the JS implementation will almost certainly apply this validation to language tags as that's what we use for the formatter's So any spec text which allows for that practice to continue would be good. |
@eemeli That validation is ULI (although it's probably not a good thing that it is separate from Unicode's definition, given that one or the other might change...) I'm hesitant to require every implementation everywhere to use ULI simply because some implementations won't support the various extensions and such--but can still use the language tag bits. Many specifications "require" users to be more strict than what implementations are required to enforce. The way to say that would be:
|
Depends on expression attributes being accepted (#450) |
We decided to make expression attributes reserved for future standardization. As a result, this item is out of scope for LDML45. |
|
In #450 we are considering the addition of a contextual expression attribute for the locale. Currently this says that the values must be a BCP47 language tag (or comma-separated sequence of tags, e.g. a language priority list). We should agree on the level of validation for conformance.
Generally speaking, we should probably require well-formed tags (according to BCP47's understanding of well-formed), at least at the syntax level.
We could require that the tags be valid (this requires checking that the subtags are in the registry)
We could require that the tags be valid Unicode Locale Identifiers (ULIs) (which has further canonicalization requirements)
Writing this issue to provide a separate place to discuss.
The text was updated successfully, but these errors were encountered: