We're updating the issue view to help you get more done. 

Finish API for well-formedness & validity

Description

Make the API public, and handle the following issues:

KeyTypeData.SpecialType It appears that the private SpecialType in KeyTypeData is mostly superfluous. It has a test for validity (which is actually wellformedness), but it only ever uses that to determine whether to canonicalize (which just lowercases). But every extension in a locale has lowercase form anyway when canonicalized, so these methods appears unnecessary. Any objections to my dropping those methods?

The LocaleValidityChecker now tests that rg values are <region>zzzz, where the <region> validity is up to the settings on the checker. Thus if the settings include deprecated regions, then they are allowed. Note, however, that if macroregions are allowed in the settings (eg to allow en-001), then they are also allowed in the rg values. Should I make that tighter?

"en-u" As far as I can see in ​https://tools.ietf.org/html/rfc6067, this degenerate case would be valid. However, we forbid it in our CLDR syntax. I don't see any strong reason to change that, but we should document it. Anyone disagree?

(split from )

Status

Assignee

Mark Davis

Reporter

Mark Davis

Components

Priority

assess