[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search
 
Modify

CLDR Ticket #5746(closed enhancement: fixed)

Opened 2 years ago

Last modified 21 months ago

clean up old and new locale sequence

Reported by: mark Owned by: mark
Component: xxx-spec Data Locale:
Phase: Review: yoshito
Weeks: Data Xpath:
Xref:

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:

  1. Have all methods that take the old syntax also take the new syntax, interpreted correctly.
  2. Have all methods that take the old syntax also take all aliases for keywords and types (eg islamicc).
  3. 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.
  4. Provide a method that tests a locale to determine which it is:
    1. well-formed
    2. valid - well-formed and only uses registered language subtags, extensions, keywords, types...
    3. canonical - valid and no deprecated codes, etc.

Attachments

Change History

comment:1 Changed 2 years ago by mark

  • Description modified (diff)

comment:2 Changed 2 years ago by emmons

  • 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

comment:3 Changed 2 years ago by mark

  • Description modified (diff)

comment:4 Changed 21 months ago by mark

I think this should be changed to a spec bug, and we can add the above as guidelines.

comment:5 Changed 21 months ago by mark

  • Component changed from design to spec

comment:6 Changed 21 months ago by mark

  • Review set to yoshito

comment:7 in reply to: ↑ description Changed 21 months ago by yoshito

  • Status changed from assigned to closed
  • Resolution set to fixed

Replying to mark:

Where the old API is supplied the bcp47 language code, or vice versa:

  1. Have all methods that take the old syntax also take the new syntax, interpreted correctly.


This might be OK if service only support valid CLDR locales.
ICU probably cannot do it.

  1. Have all methods that take the old syntax also take all aliases for keywords and types (eg islamicc).

This may work well in ICU, although it need to be done carefully (prevent performance regression, standardize locale cache, etc..)

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

I assume you're talking about ICU forLangaugeTag(). We discussed this carefully. forLanguageTag is not throwing any exception by design. If checking is necessary, use (U)Locale.Builder.

  1. Provide a method that tests a locale to determine which it is:
    1. well-formed
    2. valid - well-formed and only uses registered language subtags, extensions, keywords, types...
    3. canonical - valid and no deprecated codes, etc.

For BCP47 style identifiers, (U)Locale.Builder does 1 and 2 in ICU/JDK.

This is a recommendation in CLDR/LDML - So, I'm OK with it. But I don't think we can do all of above easily in ICU, because locale in ICU is too flexible.

View

Add a comment

Modify Ticket

Action
as closed
The ticket will be disowned. The resolution will be deleted. Next status will be 'new'
Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.