[loc-en-dev] Comments to the draft spec
y.umaoka at gmail.com
Mon Feb 2 13:29:42 PST 2009
Naoto Sato wrote:
> 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
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?
More information about the locale-enhancement-dev