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

[Masayoshi Okutsu]

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090120/180fba72/attachment.html