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

[Masayoshi Okutsu]

I just want to avoid the situation that we miss the train and everything 
is left behind. Do you think it's difficult to split the entire work 
into some milestones?

Thanks,
Masayoshi

On 1/21/2009 9:18 AM, Steven R Loomis wrote:
> 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
>
>
>
>
>
>