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

[Naoto Sato]

Yoshito-san, comments inline.

Yoshito Umaoka wrote:
> 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.

If it's BCP47, "ja_JP_JP" or "no_NO_NY" is illegal because the variant 
subtag cannot be two-letter code.  I think limiting builder strictly to 
BCP47 is OK because developers can always use the old constructors.

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

Does LDML define the mappings between, say "-k-collatio-traditio" and 
"@collation=traditional"?  If it's clearly defined in the LDML, we can 
just say, Locale class implements -k extension as LDML's keywords.

> 
>> - 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?

The reason is, again BCP47 conformance.  If I understand it correctly, 
language subtag is mandatory in BCP47.

Thanks,
-- 
Naoto Sato