[loc-en-dev] Comments on the locale enhancement proposal

[Steven R Loomis]

Comments here:

   As to compatibility, I think the principle here is: existing locales
   should have existing behavior.  So,  zh_Hans_CN and zh_Hant_TW would NOT
   be used as system default locales.

   You said:

        MO> "We should define a minimal set of changes that should go to
   JDK 7. I'm considering support of ISO 639 (new 2-letter and part 2-3)
   and script as the minimal set. We will be able to add more if the
   schedule allows."

   I would like to also consider the keyword support as well, to allow for
   interoperability with CLDR, and also to enable future selection of
   services. The JDK services are not being asked to implement any behavior
   at all with the keywords. It allows for a flexible selection of items
   that currently use variants (such as th_TH_TH or ja_JP_JP- those IDs
   would continue to work as they do now, of course.)

Regards,
Steven



                                                                                                                                                   
  From:       Masayoshi Okutsu <Masayoshi.Okutsu at Sun.COM>                                                                                          
                                                                                                                                                   
  To:         locale-enhancement-dev at openjdk.java.net                                                                                              
                                                                                                                                                   
  Date:       01/20/2009 12:27 AM                                                                                                                  
                                                                                                                                                   
  Subject:    [loc-en-dev] Comments on the locale enhancement proposal                                                                             
                                                                                                                                                   





Folks,

Finally I've spent some time to review the locale enhancement proposal.
Here are my comments on the proposal.

- Compatibility Strategy

I think we should have a cleaner and simpler strategy to support the
enhancements while keeping compatibility so that it's easier for non-i18n
people how to use new staff for the new features.

My proposal is:
      the existing interfaces should be kept fully compatible in both
      binaries and source code.
      the enhancements should be available only through new interfaces
      given by the builder pattern design which is flexible and extensible.
      the factory method for creating a Locale should be eliminated because
      having both factory methods and a builder is redundant.
      enum IDType should be eliminate and add methods with ID type names
      (e.g., toBCP47String() instead of toString(IDType.BCP47))
      support a method which performs conversions between old and new
      Locales. (best effort basis) e.g., zh_TW (old) -> zh_Hant_TW (new),
      zh_Hant (new) -> zh_TW (old)
- Development

We should define a minimal set of changes that should go to JDK 7. I'm
considering support of ISO 639 (new 2-letter and part 2-3) and script as
the minimal set. We will be able to add more if the schedule allows.

- 6.1 Script

The 4-arg Locale constructor examples in the table should be removed.

new Locale("", "", "US").toString() should return "" for compatibility,
assuming that new Locale("", "", US") is a typo of new Locale("", "",
"US").

- 7. Locale Resource/Service Lookup

Should the script part be treated as additional information to the language
to disambiguate the writing system? So the zh_Hans_CN look-up sequence
should be zh_Hans_CN -> zh_CN -> zh_Hans -> zh? (zh_CN and zh shouldn't
exist to avoid conflicts with zh_Hant_CN and other zh_* sequences, though.)

Should country really be added to the lang_script? (e.g., zh_Hant ->
zh_Hant_TW)

Should script be added to language? (e.g., pa -> pa_Guru)

The *_NO look-up sequences should be consistent with the no and nb ones. So
the sequences should be:

no_NO -> nb_NO -> no -> nb
no_NO_NY -> nn_NO -> no_NO -> nn -> no
nn_NO -> no_NO_NY -> nn -> no
nb_NO -> no_NO -> nb -> no

- 5.3. Locale Builder
- 8. Summary Proposed API Changes
- LocaleBuilder API

The builder class should be a nested class of Locale. (LocaleBuilder should
be Locale.Builder.)

The builder methods should return the builder object so that it can support
a fluent interface.

I prefer build() instead of getLocale().


That's all for today.

Thanks,
Masayoshi