<i18n dev> [9] RFR 8027289: [Windows zh_CN] NumberFormat: Incorrect sequence of loading currency symbol

[Masayoshi Okutsu]

The problem in the bug report is that the currency symbol is taken from 
the HOST locale provider where it is expected to come from the JRE 
locale provider. Hans/Hant of zh locales of JRE locales are all 
implicit. So I don't think zh locales with explicit Script have to be 
listed as available locales.

I also wonder if the Serbian locales with implicit Cyrl have the same 
problem.

Thanks,
Masayoshi

On 2/11/2014 2:00 AM, Naoto Sato wrote:
> I thought about it and probably it would make sense to utilize locale 
> matching mechanism in LocaleProviderAdapter, where it selects the most 
> preferred adapter. However, on the JRE's adapter side, it still needs 
> to declare that Hans/Hant locales in the supported locales list. This 
> fix is to address this latter part.
>
> Naoto
>
> On 2/10/14, 12:23 AM, Masayoshi Okutsu wrote:
>> I wonder if we can utilize the locale matching mechanism rather than
>> tweaking the makefile. zh-CN and zh-Hans-CN can be treated as
>> equivalents for looking up the JRE locales.
>>
>> Masayoshi
>>
>> On 2/5/2014 11:54 AM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review this fix:
>>>
>>> http://cr.openjdk.java.net/~naoto/8027289/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8027289
>>>
>>> The fix is to add Chinese locales with explicit scripts (Hans/Hant) in
>>> JRE's locale provider adapter's supported locales if corresponding
>>> implicit Chinese locales are supported.
>>>
>>> For build-dev engineers, I post this to your alias because the fix is
>>> in a make file.
>>>
>>> Naoto
>>