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

[Masayoshi Okutsu]

Comments inline.

On 1/21/2009 5:26 AM, Doug Felt wrote:
> Comments inline.
>
> On Tue, Jan 20, 2009 at 12:25 AM, Masayoshi Okutsu 
> <Masayoshi.Okutsu at sun.com <mailto:Masayoshi.Okutsu at sun.com>> wrote:
>
>
>
>     My proposal is:
>
>         * the existing interfaces should be kept fully compatible in
>           both binaries and source code.
>
> Can you define more precisely what you mean?  Do you mean no API 
> additions to the Locale class?

No semantic or behavior changes to the existing methods. I saw the 
toString() behavior change in the 6.1 Script table and the semantic 
changes to the Locale constructors. We should just describe the current 
behavior where it's necessary.

It's OK to add new methods to Locale.

>
>         * the factory method for creating a Locale should be
>           eliminated because having both factory methods and a builder
>           is redundant.
>
> Depends on the common use case.

You can do the same thing in the builder interface, something like this:

new Locale.Builder().bcp47("...").build();

>
>     - 7. Locale Resource/Service Lookup
>
>
> I think of there being two situations we might want to handle 
> automatically:
>
> 1) old data, new identifiers
> 2) new data, old identifiers
>
> The proposal tries to deal with both, by defining what we think the 
> old data and old identifiers mean in the new system.  So for example 
> we assume that old data tagged as 'zh_TW' is in fact in traditional 
> Han and should be presented as 'zh_Hant_TW' data; similarly that a 
> request for 'zh_TW' data is implicitly a request for traditional Han 
> (as well as Taiwan) data since that is what (we assume) it returns for 
> existing appliations/jvms, and so should be handled as a request for 
> 'zh_Hant_TW' data.
>
> We don't necessarily have to handle both situations (or either).

I think it's obvious that we can't support old data with new identifiers 
perfectly, like zh_Hans_CN and zh_Hant_CN. When we can't support both, I 
prefer to define a simple algorithm to produce a look-up sequences with 
minimum exceptions. If applications still want to support particular 
situations, they can subclass ResourceBundle.Control to generate any 
specific look-up sequences.

Masayoshi