[loc-en-dev] Comments to the draft spec

[Yoshito Umaoka]

Naoto Sato wrote:
> Hello,
> 
> I am very sorry for the delay, but here are some of my comments/thoughts 
> regarding the draft spec.  Since we are shooting for the JDK7, I would 
> like to do something minimum, as Masayoshi said.
> 
> - I would like to keep the current constructors of the Locale class 
> intact.  The new Locale instances that represents BCP47 or LDML should 
> only be built by the Locale Builder.  I believe this is clear enough to 
> developers.

Agree.  No changes in the existing Local constructors and its behavior.

> 
> - IDType "JAVA" may not be needed.  Current Java locales can already be 
> instantiated through the existing Locale constructors.  Moreover I don't 
> think we need to support such as "ja_JP_JP"/"no_NY_NY" in the new 
> builder, which will make the implementation more complicated.
>

Yes, IDType "JAVA" might be redundant.  Actually, what we probably need 
is just BCP47.

I'm not sure not supporting "ja_JP_JP"/"no_NO_NY" in the builder makes 
sense.  The builder should be "super" interface for creating any 
possible Locale instances.

> - Question: should we support both BCP47 and LDML ids in the API spec? 
> Can we just have LDML ids as an implementation? E.g., if the id has 
> -k-calendar-japanese, we use Japanese calendar.  If we want LDML in the 
> API, we could add it after JDK7.
> 

I think most of people are interested in the compatibility between Java 
Locales and BCP47 language tags.  Immediate requirement is to get a 
Locale from a language tag without loss of data.

LDML keyword is just an implementation of BCP47 extensions.  At least, I 
think it's important to make Locale to store "extensions" without 
information loss.  Making i18n service classes to use the information 
(calendar=japanese) is yet another topic and we could defer a part of 
this effort after JDK7.

> - Make sure that the new locale builder requires to have the "language" 
> element, which is not true for the existing constructors.
> 

I'm not sure it makes sense.  We could do this, but any problems with 
"language" less Locale?  In the CLDR project, we realized we need such 
concept for handling locale specific behavior purely depending on 
region.  We moved out some data from the legacy language_region 
inheritance tree to another structure.  For example, currency, calendar 
types are in this category.

We could use "und" (undefined language) for such Locales.  Could you 
describe any "problematic" cases with empty language?

-Yoshito