CLDR Ticket #5746(closed enhancement: fixed)
clean up old and new locale sequence
|Reported by:||mark||Owned by:||mark|
Description (last modified by mark) (diff)
It is too easy for even knowledgeable users of code using LDML locale syntax to make mistakes, eg
"Because you sent your code, I discovered that I have to use new ULocale("en@calendar=buddhist"), not ULocale.forLanguageTag("en@calendar=buddhist")."
We should supply guidelines for how to best interoperate with old and new syntax.
Here is my suggestion for cleanup (we can discuss this futher).
Where the old API is supplied the bcp47 language code, or vice versa:
- Have all methods that take the old syntax also take the new syntax, interpreted correctly.
- Have all methods that take the old syntax also take all aliases for keywords and types (eg islamicc).
- Where an API cannot successfully accept the alternate syntax, throw an exception if it is supplied so that people can detect that they are using the wrong method.
- Provide a method that tests a locale to determine which it is:
- valid - well-formed and only uses registered language subtags, extensions, keywords, types...
- canonical - valid and no deprecated codes, etc.
- Status changed from new to assigned
- Component changed from unknown to design
- Priority changed from assess to medium
- Milestone changed from UNSCH to 24
- Owner changed from anybody to mark
- Type changed from unknown to enhancement