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

[Doug Felt]

On Tue, Jan 20, 2009 at 4:04 PM, Masayoshi Okutsu
<Masayoshi.Okutsu at sun.com>wrote:

> 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. [...]
>

Can define one so we can understand what cases you intend to handle and how?


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