From takiguc at linux.vnet.ibm.com  Fri Nov  1 13:56:34 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 01 Nov 2019 22:56:34 +0900
Subject: <i18n dev> RFR: 8232161 Unexpected 1-way trip conversion
 entries on MS950 charset
In-Reply-To: <928774f8-9d20-bf75-fbc3-36c8a37b273c@oracle.com>
References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
 <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>
 <c7325c3fe01d3985cc879d2113bd9ce4@linux.vnet.ibm.com>
 <93bc5929-3995-764d-a39e-bafc7d82503a@oracle.com>
 <4573ea1e76d12d4a48f71c2536c18e62@linux.vnet.ibm.com>
 <928774f8-9d20-bf75-fbc3-36c8a37b273c@oracle.com>
Message-ID: <74fc2a0ee9fb0de5284b727b2b68a64c@linux.vnet.ibm.com>

Hello Sato-san.

I could not find any specific reason for this issue.
I said "1-way trip conversion", I should say "round trip conversion".
bestfit950.txt has many 1-way trip entries for Unicode to MS950 
conversion.
At least, I think round trip conversion needs to be consistent between 
Windows and Java.

Thanks,
Ichiroh Takiguchi

On 2019-10-31 01:25, naoto.sato at oracle.com wrote:
> Takiguchi-san,
> 
> Personally I am reluctant to make this change. If we were to introduce
> this, it will be a different encoding from the existing MS950, so
> either 1) we need a new encoding, or 2) make some switch between the
> encoding, possibly a system property. But neither seems worth doing,
> as :-
> 
> 1) JDK's conversion is not a bug per se.
> 2) Seems that Unicode.org's "best fit" was introduced around 2006?
> (From the date on the unicode.org
> (https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt),
> so JDK's mapping predates it.
> 3) Those code points are not a common ones (BOX DRAWINGS), and no
> customer had a complaint about it.
> 
> Please let me know if there are some rationale for fixing it.
> 
> BTW, as to the CSR, I don't see it was created.
> 
> Naoto
> 
> 
> On 10/29/19 11:35 AM, Ichiroh Takiguchi wrote:
>> Thanks, Sato-san.
>> 
>> There is no special meaning to the word "until now".
>> I rewrote charset related testcases, then I found this issue.
>> 
>> I read "Frequently Asked Questions about the CSR" [1],
>> I tried "Create CSR" operation, but I could not determine it worked or 
>> not...
>> (Select "Create CSR" from "More" menu)
>> It worked ?
>> 
>> [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> 
>> On 2019-10-29 03:03, naoto.sato at oracle.com wrote:
>>> Hi Takiguchi-san,
>>> 
>>> On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:
>>>> Hello.
>>>> 
>>>> I have no idea about compatibility impact.
>>>> 
>>>> But according to 
>>>> ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
>>>> These are BOX DRAWINGS characters.
>>>> 
>>>> 2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE 
>>>> HORIZONTAL;;;;
>>>> 255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT 
>>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND RIGHT DOUBLE;;;;
>>>> 2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT 
>>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND LEFT DOUBLE;;;;
>>>> 256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
>>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;;
>>>> 
>>>> I don't think it was used as valuable data until now.
>>>> I think it's necessary to evaluate compatibility.
>>> 
>>> What do you mean by "until now"? Are there customers claiming that it
>>> should be corrected? Since the current JDK's mapping is not incorrect
>>> per se (not just "best match"), I would like to know why this needs 
>>> to
>>> be fixed now.
>>> 
>>> Naoto
>>> 
>>>> 
>>>> To Sato-san,
>>>> if you have any question and suggestion, please let me know.
>>>> 
>>>> To other reviewers,
>>>> please let me know if you have any question and concern.
>>>> 
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> 
>>>> On 2019-10-19 16:36, Alan Bateman wrote:
>>>>> On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
>>>>>> Hello.
>>>>>> 
>>>>>> Could you review the fix ?
>>>>>> 
>>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161
>>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>>>>>> 
>>>>>> I have a concern about 1-way trip conversion entries (4 entries) 
>>>>>> on MS950 charset.
>>>>>> The detail information is in JDK-8232161 [1]
>>>>>> 
>>>>> Do you know any sense on the compatibility impact of changing this? 
>>>>> I
>>>>> think Naoto has the same question and we aren't sure if this one 
>>>>> with
>>>>> need a compatibility property. I think it will need a CSR.
>>>>> 
>>>>> -Alan

From naoto.sato at oracle.com  Tue Nov  5 16:34:05 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 5 Nov 2019 08:34:05 -0800
Subject: <i18n dev> Return value of DateFormatSymbols.getWeekdays()
In-Reply-To: <f0042889-594f-4ac9-b467-4c5178cdcd33.zhuoren.wz@alibaba-inc.com>
References: <f0042889-594f-4ac9-b467-4c5178cdcd33.zhuoren.wz@alibaba-inc.com>
Message-ID: <d6b29daf-0028-ccae-edaa-1a6a6a1024de@oracle.com>

Hi Zhuoren,

Thanks for looking into it. Recent JDK's locale data, including 11u/13 
are extracted from Unicode Consortium's CLDR project, and the file you 
modified was exactly from their repository. [1]

Since ROOT locale is the invariant language neutral locale, I think 
CLDR's intention was to obscure the language-ness in its names. Arguably 
"Sun", "Mon"... are English based, but less English than "Sunday", 
"Monday"... If you look at the month names, they are "M01", "M02" which 
are totally language neutral.

So I think it is correct as it is, and I don't think we would need to 
modify CLDR's locale data for JDK use. If you still think "Sunday" etc. 
should be used, I'd suggest you file a request at CLDR.

Naoto

[1] https://github.com/unicode-org/cldr/blob/latest/common/main/root.xml

On 11/4/19 10:31 PM, Wang Zhuo(Zhuoren) wrote:
> Hi,
> I am an engineer from Alibaba, and I have a question for return value of DateFormatSymbols.getWeekdays().
> When using DateFormatSymbols.getInstance(Locale.ROOT).getWeekdays(), on JDK13 or JDK11u we get short names, such as Sun, Mon. While I think the return value should be full names, such as Sunday, Monday. The comments of this method also indicate full names.
> DateFormatSymbols.java:
>      /**
>       * Weekday strings. For example: "Sunday", "Monday", etc.  An array
>       * of 8 strings, indexed by <code>Calendar.SUNDAY</code>,
>       * <code>Calendar.MONDAY</code>, etc.
>       * The element <code>weekdays[0]</code> is ignored.
>       * @serial
>       */
>      String weekdays[] = null;
> 
> This issue only exists in Local.ROOT, DateFormatSymbols.getInstance(Locale.US).getWeekdays() returns full names.
> I think it makes sense to return full names not short ones for Local.ROOT. What's your opinion?
> 
> It seems this issue is caused by abbreviated and wide dayWidth are set the same value in root.xml. I made a patch for this, please also review it http://cr.openjdk.java.net/~wzhuo/getWeekdays//webrev.00/
> 
> Regards,
> Zhuoren
> 
> 
> 
> 
> 

From naoto.sato at oracle.com  Tue Nov  5 20:48:36 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 5 Nov 2019 12:48:36 -0800
Subject: <i18n dev> [14] RFR: 8232871: Host Locale Provider on Mac does not
 return translated values of Japanese calendar
Message-ID: <83707e65-41cb-ec0d-4a3c-005ae94967ae@oracle.com>

Hello,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8232871

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8232871/webrev.00/

Implementation for getting calendar display names was missing in macOS's 
host adapter.

Naoto

From naoto.sato at oracle.com  Wed Nov  6 21:45:29 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 6 Nov 2019 13:45:29 -0800
Subject: <i18n dev> [14] RFR: 8233579: DateFormatSymbols.getShortMonths()
 return wrong string on es_CL, es_CO locales
Message-ID: <89efc1fb-1130-c533-4472-ae2c0dba1288@oracle.com>

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8233579

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8233579/webrev.00/

The problem was in the CLDR converter where it substitutes the context 
dependent style names with stand alone style names, if the former set of 
names are missing in a locale bundle. Corrected to not substitute, thus 
inherit from the parent bundles.

Naoto

From brent.christian at oracle.com  Wed Nov  6 23:27:35 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 6 Nov 2019 15:27:35 -0800
Subject: <i18n dev> [14] RFR: 8232871: Host Locale Provider on Mac does
 not return translated values of Japanese calendar
In-Reply-To: <83707e65-41cb-ec0d-4a3c-005ae94967ae@oracle.com>
References: <83707e65-41cb-ec0d-4a3c-005ae94967ae@oracle.com>
Message-ID: <6d45da8c-2fce-6925-8acf-a709339e47fa@oracle.com>

Hi, Naoto

Looks pretty good.  I have a few comments:

--
src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java

  572                     map = new HashMap<>();

FWIW, I believe the HashMap could be pre-sized using 'names.length'.


--
src/java.base/macosx/native/libjava/HostLocaleProviderAdapter_md.c

  457     jobjectArray ret = NULL;

Is 'ret' needed?


  713                 int sindex = cal == kCFJapaneseCalendar ? 
JAPANESE_MEIJI_INDEX : 0;

So here we are moving 'sindex' past earlier eras in 'cferas', in order 
to start at Meiji, yes?


  740                 if (wdays != NULL) {
  741                     array_length = (*env)->GetArrayLength(env, wdays);
  742                 } else {
  743                     array_length = dayCount + 1;

It doesn't look like 'array_length' is needed for the 'wdays != NULL' 
case.  In fact, could 740-743 be changed to:

if (wdays == NULL) {
     jsize array_length = dayCount + 1;

?

Thanks,
-Brent

On 11/5/19 12:48 PM, naoto.sato at oracle.com wrote:
> Hello,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8232871
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8232871/webrev.00/
> 
> Implementation for getting calendar display names was missing in macOS's 
> host adapter.
> 
> Naoto

From naoto.sato at oracle.com  Thu Nov  7 02:11:28 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 6 Nov 2019 18:11:28 -0800
Subject: <i18n dev> [14] RFR: 8232871: Host Locale Provider on Mac does
 not return translated values of Japanese calendar
In-Reply-To: <6d45da8c-2fce-6925-8acf-a709339e47fa@oracle.com>
References: <83707e65-41cb-ec0d-4a3c-005ae94967ae@oracle.com>
 <6d45da8c-2fce-6925-8acf-a709339e47fa@oracle.com>
Message-ID: <05bc6dda-199f-66b5-b0b2-38c0180c99c1@oracle.com>

Hi Brent,

Thank you for the review! Please see my comments below.

On 11/6/19 3:27 PM, Brent Christian wrote:
> Hi, Naoto
> 
> Looks pretty good.? I have a few comments:
> 
> -- 
> src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java 
> 
> 
>  ?572???????????????????? map = new HashMap<>();
> 
> FWIW, I believe the HashMap could be pre-sized using 'names.length'.

Modified to specify the initial capacity.

> 
> 
> -- 
> src/java.base/macosx/native/libjava/HostLocaleProviderAdapter_md.c
> 
>  ?457???? jobjectArray ret = NULL;
> 
> Is 'ret' needed?

Removed.

> 
> 
>  ?713???????????????? int sindex = cal == kCFJapaneseCalendar ? 
> JAPANESE_MEIJI_INDEX : 0;
> 
> So here we are moving 'sindex' past earlier eras in 'cferas', in order 
> to start at Meiji, yes?

Yes. While JDK's Japanese calendar provides eras since Meiji and 
"BeforeMeiji", which is a hypothetical era for all prior eras, macOS's 
Japanese calendar returns all Japanese eras. Copying should be done only 
for Meiji and after.

> 
> 
>  ?740???????????????? if (wdays != NULL) {
>  ?741???????????????????? array_length = (*env)->GetArrayLength(env, 
> wdays);
>  ?742???????????????? } else {
>  ?743???????????????????? array_length = dayCount + 1;
> 
> It doesn't look like 'array_length' is needed for the 'wdays != NULL' 
> case.? In fact, could 740-743 be changed to:
> 
> if (wdays == NULL) {
>  ??? jsize array_length = dayCount + 1;
> 
> ?

You're absolutely right. These are copied from Windows' counterpart and 
left over.

Here is the updated webrev:

https://cr.openjdk.java.net/~naoto/8232871/webrev.01/

Naoto

> 
> Thanks,
> -Brent
> 
> On 11/5/19 12:48 PM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8232871
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8232871/webrev.00/
>>
>> Implementation for getting calendar display names was missing in 
>> macOS's host adapter.
>>
>> Naoto

From huizhe.wang at oracle.com  Thu Nov  7 02:21:37 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 6 Nov 2019 18:21:37 -0800
Subject: <i18n dev> [14] RFR: 8233579:
 DateFormatSymbols.getShortMonths() return wrong string on es_CL,
 es_CO locales
In-Reply-To: <89efc1fb-1130-c533-4472-ae2c0dba1288@oracle.com>
References: <89efc1fb-1130-c533-4472-ae2c0dba1288@oracle.com>
Message-ID: <789b55f2-1219-e3c1-1402-c69ff609a4a0@oracle.com>

Looks good to me. It might be good to leave a note to the method about 
the change (e.g. why it no longer substitutes).

-Joe

On 11/6/19 1:45 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8233579
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8233579/webrev.00/
>
> The problem was in the CLDR converter where it substitutes the context 
> dependent style names with stand alone style names, if the former set 
> of names are missing in a locale bundle. Corrected to not substitute, 
> thus inherit from the parent bundles.
>
> Naoto


From naoto.sato at oracle.com  Thu Nov  7 02:34:31 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 6 Nov 2019 18:34:31 -0800
Subject: <i18n dev> [14] RFR: 8233579:
 DateFormatSymbols.getShortMonths() return wrong string on es_CL,
 es_CO locales
In-Reply-To: <789b55f2-1219-e3c1-1402-c69ff609a4a0@oracle.com>
References: <89efc1fb-1130-c533-4472-ae2c0dba1288@oracle.com>
 <789b55f2-1219-e3c1-1402-c69ff609a4a0@oracle.com>
Message-ID: <de510cbb-de09-2b3b-30c2-b4218974fc5e@oracle.com>

Hi Joe,

Thanks for the review! I tried to draft some comments, but thinking of 
it, it could be confusing to leave a comment for a removed (wrong) code. 
So instead of leaving code comments, I modified the JIRA issue 
mentioning it, so that maintainers later could find out the rationale.

Naoto

On 11/6/19 6:21 PM, Joe Wang wrote:
> Looks good to me. It might be good to leave a note to the method about 
> the change (e.g. why it no longer substitutes).
> 
> -Joe
> 
> On 11/6/19 1:45 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8233579
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8233579/webrev.00/
>>
>> The problem was in the CLDR converter where it substitutes the context 
>> dependent style names with stand alone style names, if the former set 
>> of names are missing in a locale bundle. Corrected to not substitute, 
>> thus inherit from the parent bundles.
>>
>> Naoto
> 

From huizhe.wang at oracle.com  Thu Nov  7 03:24:47 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 6 Nov 2019 19:24:47 -0800
Subject: <i18n dev> [14] RFR: 8233579:
 DateFormatSymbols.getShortMonths() return wrong string on es_CL,
 es_CO locales
In-Reply-To: <de510cbb-de09-2b3b-30c2-b4218974fc5e@oracle.com>
References: <89efc1fb-1130-c533-4472-ae2c0dba1288@oracle.com>
 <789b55f2-1219-e3c1-1402-c69ff609a4a0@oracle.com>
 <de510cbb-de09-2b3b-30c2-b4218974fc5e@oracle.com>
Message-ID: <91badbb9-bbf3-5587-5894-c8c7c082c014@oracle.com>

That sounds good. JIRA makes sense.

Best,
Joe

On 11/6/19 6:34 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> Thanks for the review! I tried to draft some comments, but thinking of 
> it, it could be confusing to leave a comment for a removed (wrong) 
> code. So instead of leaving code comments, I modified the JIRA issue 
> mentioning it, so that maintainers later could find out the rationale.
>
> Naoto
>
> On 11/6/19 6:21 PM, Joe Wang wrote:
>> Looks good to me. It might be good to leave a note to the method 
>> about the change (e.g. why it no longer substitutes).
>>
>> -Joe
>>
>> On 11/6/19 1:45 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8233579
>>>
>>> The proposed changeset is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8233579/webrev.00/
>>>
>>> The problem was in the CLDR converter where it substitutes the 
>>> context dependent style names with stand alone style names, if the 
>>> former set of names are missing in a locale bundle. Corrected to not 
>>> substitute, thus inherit from the parent bundles.
>>>
>>> Naoto
>>


From brent.christian at oracle.com  Thu Nov  7 19:26:30 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 7 Nov 2019 11:26:30 -0800
Subject: <i18n dev> [14] RFR: 8232871: Host Locale Provider on Mac does
 not return translated values of Japanese calendar
In-Reply-To: <05bc6dda-199f-66b5-b0b2-38c0180c99c1@oracle.com>
References: <83707e65-41cb-ec0d-4a3c-005ae94967ae@oracle.com>
 <6d45da8c-2fce-6925-8acf-a709339e47fa@oracle.com>
 <05bc6dda-199f-66b5-b0b2-38c0180c99c1@oracle.com>
Message-ID: <0163dcc2-45fb-7c95-67ac-6ab736ec007b@oracle.com>

Looks good.  -B

On 11/6/19 6:11 PM, naoto.sato at oracle.com wrote:
> 
> Here is the updated webrev:
> 
> https://cr.openjdk.java.net/~naoto/8232871/webrev.01/
> 


From naoto.sato at oracle.com  Tue Nov 12 17:10:14 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 12 Nov 2019 09:10:14 -0800
Subject: <i18n dev> [14] RFR: 8232860: Error formatting integer values with
 MessageFormat.format() using HOST provider
Message-ID: <75c71988-40c6-3948-a260-23b55c26a58e@oracle.com>

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8232860

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8232860/webrev.00/

Although this was reported for German locale, it is reproducible on any 
locale. The root cause of this issue was that the Host adapter for 
Windows returned the number pattern for number/integer instances, which 
always require fraction digits, i.e., '0'. Changing it to optional '#' 
will solve the issue.

Also, I modified the integer formatters to allow only integer processing 
(used to allow fractions as well).

Naoto

From letuyang at amazon.com  Fri Nov 15 23:19:46 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Fri, 15 Nov 2019 23:19:46 +0000
Subject: <i18n dev> Turkish Time Zone name string and translation
Message-ID: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>

Hi,

We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:

https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836

It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS issue for this, but I am not sure whether we should fix this bug, or there is an existing procedure for this kind of bug which requires language translation.

Letu




From naoto.sato at oracle.com  Sat Nov 16 00:27:05 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 15 Nov 2019 16:27:05 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
Message-ID: <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>

Hi Letu,

Please file a JBS issue for this (component: core-libs, subcomponent: 
java.util:i18n).

Naoto

On 11/15/19 3:19 PM, Yang, Letu wrote:
> Hi,
> 
> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
> 
> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
> 
> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS issue for this, but I am not sure whether we should fix this bug, or there is an existing procedure for this kind of bug which requires language translation.
> 
> Letu
> 
> 
> 

From letuyang at amazon.com  Sat Nov 16 01:56:35 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Sat, 16 Nov 2019 01:56:35 +0000
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>,
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
Message-ID: <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>

Hi Naoto

Thank you for the quick response! We will file a ticket later today.

Shall we make an effort on fixing and translating the strings, or you prefer to take care of it at Oracle?

Letu

On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
Hi Letu,

Please file a JBS issue for this (component: core-libs, subcomponent:
java.util:i18n).

Naoto

On 11/15/19 3:19 PM, Yang, Letu wrote:
> Hi,
>
> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
>
> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>
> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS issue for this, but I am not sure whether we should fix this bug, or there is an existing procedure for this kind of bug which requires language translation.
>
> Letu
>
>
>

From naoto.sato at oracle.com  Sat Nov 16 14:41:56 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Sat, 16 Nov 2019 06:41:56 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
Message-ID: <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>

Letu,

Please go ahead and fix the issue in English resource. As to the 
translation, Oracle l10n will translate it in appropriate locales.

Naoto

On 11/15/19 5:56 PM, Yang, Letu wrote:
> Hi Naoto
> 
> Thank you for the quick response! We will file a ticket later today.
> 
> Shall we make an effort on fixing and translating the strings, or you 
> prefer to take care of it at Oracle?
> 
> Letu
> 
> On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
> Hi Letu,
> 
> Please file a JBS issue for this (component: core-libs, subcomponent:
> java.util:i18n).
> 
> Naoto
> 
> On 11/15/19 3:19 PM, Yang, Letu wrote:
>> Hi,
>> 
>> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
>> 
>> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>> 
>> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I 
> am not sure whether we should fix this bug, or there is an existing 
> procedure for this kind of bug which requires language translation.
>> 
>> Letu
>> 
>> 
>> 

From martinrb at google.com  Sun Nov 17 21:49:52 2019
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 17 Nov 2019 13:49:52 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
Message-ID: <CA+kOe0_RySTOWVmLpbeE8DLus+ek+5Bxy6kfTiZ2MC2zFYqFXA@mail.gmail.com>

I've always wondered how the timezone-related translations are managed.
CLDR seems to be the master repository of such data, and projects like
OpenJDK are simply supposed to import that data.
But I looked at the CLDR sources, and there doesn't seem to be any "Turkey
Time" strings defined like there are for e.g. Turkmenistan.
Maybe that work never got done?

On Sat, Nov 16, 2019 at 6:44 AM <naoto.sato at oracle.com> wrote:

> Letu,
>
> Please go ahead and fix the issue in English resource. As to the
> translation, Oracle l10n will translate it in appropriate locales.
>
> Naoto
>
> On 11/15/19 5:56 PM, Yang, Letu wrote:
> > Hi Naoto
> >
> > Thank you for the quick response! We will file a ticket later today.
> >
> > Shall we make an effort on fixing and translating the strings, or you
> > prefer to take care of it at Oracle?
> >
> > Letu
> >
> > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
> > Hi Letu,
> >
> > Please file a JBS issue for this (component: core-libs, subcomponent:
> > java.util:i18n).
> >
> > Naoto
> >
> > On 11/15/19 3:19 PM, Yang, Letu wrote:
> >> Hi,
> >>
> >> We recently found an issue with the Time Zone name for
> ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own
> Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the
> Time Zone name string has not been updated yet:
> >>
> >>
> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
> >>
> >> It still returns "Eastern European Time" for the
> TimeZone.getDisplayName call, which has a summer time while Turkish Time
> does not. An entry for TRT need to be added to this file, and assign to
> both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated
> for other locales. I can create a JBS issue for this, but I
> > am not sure whether we should fix this bug, or there is an existing
> > procedure for this kind of bug which requires language translation.
> >>
> >> Letu
> >>
> >>
> >>
>

From letuyang at amazon.com  Mon Nov 18 04:54:37 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Mon, 18 Nov 2019 04:54:37 +0000
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
Message-ID: <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>

Hi Naoto,

Thank you for the clarification!

Xin from my team has filed a JBS and uploaded my webrev:
https://bugs.openjdk.java.net/browse/JDK-8234288
https://cr.openjdk.java.net/~xliu/8234288/webrev.00/

Letu

?On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:

    Letu,
    
    Please go ahead and fix the issue in English resource. As to the 
    translation, Oracle l10n will translate it in appropriate locales.
    
    Naoto
    
    On 11/15/19 5:56 PM, Yang, Letu wrote:
    > Hi Naoto
    > 
    > Thank you for the quick response! We will file a ticket later today.
    > 
    > Shall we make an effort on fixing and translating the strings, or you 
    > prefer to take care of it at Oracle?
    > 
    > Letu
    > 
    > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
    > Hi Letu,
    > 
    > Please file a JBS issue for this (component: core-libs, subcomponent:
    > java.util:i18n).
    > 
    > Naoto
    > 
    > On 11/15/19 3:19 PM, Yang, Letu wrote:
    >> Hi,
    >> 
    >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
    >> 
    >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
    >> 
    >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I 
    > am not sure whether we should fix this bug, or there is an existing 
    > procedure for this kind of bug which requires language translation.
    >> 
    >> Letu
    >> 
    >> 
    >> 
    


From mark at macchiato.com  Mon Nov 18 07:16:35 2019
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Mon, 18 Nov 2019 07:16:35 +0000
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <CA+kOe0_RySTOWVmLpbeE8DLus+ek+5Bxy6kfTiZ2MC2zFYqFXA@mail.gmail.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <CA+kOe0_RySTOWVmLpbeE8DLus+ek+5Bxy6kfTiZ2MC2zFYqFXA@mail.gmail.com>
Message-ID: <CAJ2xs_FBJi8xpR_maY571sbaRJjKHy5CoLoShtO-BBgXfsEgcw@mail.gmail.com>

You'd have to look at the spec. For most names a pattern plus the country
name is used. That can be overridden with a non-composed name where needed.

{phone}

On Sun, Nov 17, 2019, 21:50 Martin Buchholz <martinrb at google.com> wrote:

> I've always wondered how the timezone-related translations are managed.
> CLDR seems to be the master repository of such data, and projects like
> OpenJDK are simply supposed to import that data.
> But I looked at the CLDR sources, and there doesn't seem to be any "Turkey
> Time" strings defined like there are for e.g. Turkmenistan.
> Maybe that work never got done?
>
> On Sat, Nov 16, 2019 at 6:44 AM <naoto.sato at oracle.com> wrote:
>
> > Letu,
> >
> > Please go ahead and fix the issue in English resource. As to the
> > translation, Oracle l10n will translate it in appropriate locales.
> >
> > Naoto
> >
> > On 11/15/19 5:56 PM, Yang, Letu wrote:
> > > Hi Naoto
> > >
> > > Thank you for the quick response! We will file a ticket later today.
> > >
> > > Shall we make an effort on fixing and translating the strings, or you
> > > prefer to take care of it at Oracle?
> > >
> > > Letu
> > >
> > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
> > > Hi Letu,
> > >
> > > Please file a JBS issue for this (component: core-libs, subcomponent:
> > > java.util:i18n).
> > >
> > > Naoto
> > >
> > > On 11/15/19 3:19 PM, Yang, Letu wrote:
> > >> Hi,
> > >>
> > >> We recently found an issue with the Time Zone name for
> > ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own
> > Turkish Time (TRT) zone in 2016, although the tzdata had been updated,
> the
> > Time Zone name string has not been updated yet:
> > >>
> > >>
> >
> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
> > >>
> > >> It still returns "Eastern European Time" for the
> > TimeZone.getDisplayName call, which has a summer time while Turkish Time
> > does not. An entry for TRT need to be added to this file, and assign to
> > both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be
> updated
> > for other locales. I can create a JBS issue for this, but I
> > > am not sure whether we should fix this bug, or there is an existing
> > > procedure for this kind of bug which requires language translation.
> > >>
> > >> Letu
> > >>
> > >>
> > >>
> >
>

From naoto.sato at oracle.com  Mon Nov 18 16:00:01 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 18 Nov 2019 08:00:01 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <CAJ2xs_FBJi8xpR_maY571sbaRJjKHy5CoLoShtO-BBgXfsEgcw@mail.gmail.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <CA+kOe0_RySTOWVmLpbeE8DLus+ek+5Bxy6kfTiZ2MC2zFYqFXA@mail.gmail.com>
 <CAJ2xs_FBJi8xpR_maY571sbaRJjKHy5CoLoShtO-BBgXfsEgcw@mail.gmail.com>
Message-ID: <87dfcc98-f5d8-ca00-0d84-3fbc0c4253f7@oracle.com>

Thanks, Mark.

Apparently there seems to be a bug in CLDR converter code, which cannot 
generate the localized names for "Turkey" metazone. Thus the localized 
names from the legacy COMPAT locale data are being used. I will look 
into it.

Apart from this, what Letu found out stands by itself as a bug in COMPAT 
provider.

Naoto

On 11/17/19 11:16 PM, Mark Davis ?? wrote:
> You'd have to look at the spec. For most names a pattern plus the 
> country name is used. That can be overridden with a non-composed name 
> where needed.
> 
> {phone}
> 
> On Sun, Nov 17, 2019, 21:50 Martin Buchholz <martinrb at google.com 
> <mailto:martinrb at google.com>> wrote:
> 
>     I've always wondered how the timezone-related translations are managed.
>     CLDR seems to be the master repository of such data, and projects like
>     OpenJDK are simply supposed to import that data.
>     But I looked at the CLDR sources, and there doesn't seem to be any
>     "Turkey
>     Time" strings defined like there are for e.g. Turkmenistan.
>     Maybe that work never got done?
> 
>     On Sat, Nov 16, 2019 at 6:44 AM <naoto.sato at oracle.com
>     <mailto:naoto.sato at oracle.com>> wrote:
> 
>      > Letu,
>      >
>      > Please go ahead and fix the issue in English resource. As to the
>      > translation, Oracle l10n will translate it in appropriate locales.
>      >
>      > Naoto
>      >
>      > On 11/15/19 5:56 PM, Yang, Letu wrote:
>      > > Hi Naoto
>      > >
>      > > Thank you for the quick response! We will file a ticket later
>     today.
>      > >
>      > > Shall we make an effort on fixing and translating the strings,
>     or you
>      > > prefer to take care of it at Oracle?
>      > >
>      > > Letu
>      > >
>      > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com
>     <mailto:naoto.sato at oracle.com> wrote:
>      > > Hi Letu,
>      > >
>      > > Please file a JBS issue for this (component: core-libs,
>     subcomponent:
>      > > java.util:i18n).
>      > >
>      > > Naoto
>      > >
>      > > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      > >> Hi,
>      > >>
>      > >> We recently found an issue with the Time Zone name for
>      > ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to
>     their own
>      > Turkish Time (TRT) zone in 2016, although the tzdata had been
>     updated, the
>      > Time Zone name string has not been updated yet:
>      > >>
>      > >>
>      >
>     https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      > >>
>      > >> It still returns "Eastern European Time" for the
>      > TimeZone.getDisplayName call, which has a summer time while
>     Turkish Time
>      > does not. An entry for TRT need to be added to this file, and
>     assign to
>      > both "Europe/Istanbul" and "Asian/Istanbul". This also need to 
>     be updated
>      > for other locales. I can create a JBS issue for this, but I
>      > > am not sure whether we should fix this bug, or there is an existing
>      > > procedure for this kind of bug which requires language translation.
>      > >>
>      > >> Letu
>      > >>
>      > >>
>      > >>
>      >
> 

From mark at macchiato.com  Mon Nov 18 17:08:10 2019
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Mon, 18 Nov 2019 17:08:10 +0000
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <87dfcc98-f5d8-ca00-0d84-3fbc0c4253f7@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <CA+kOe0_RySTOWVmLpbeE8DLus+ek+5Bxy6kfTiZ2MC2zFYqFXA@mail.gmail.com>
 <CAJ2xs_FBJi8xpR_maY571sbaRJjKHy5CoLoShtO-BBgXfsEgcw@mail.gmail.com>
 <87dfcc98-f5d8-ca00-0d84-3fbc0c4253f7@oracle.com>
Message-ID: <CAJ2xs_FuTdyX-oGtago=YJQ1McG=EZr-f7FuUBg92GtWGEQmrg@mail.gmail.com>

Could you file a ticket at
https://unicode-org.atlassian.net/ ?

{phone}

On Mon, Nov 18, 2019, 16:02 <naoto.sato at oracle.com> wrote:

> Thanks, Mark.
>
> Apparently there seems to be a bug in CLDR converter code, which cannot
> generate the localized names for "Turkey" metazone. Thus the localized
> names from the legacy COMPAT locale data are being used. I will look
> into it.
>
> Apart from this, what Letu found out stands by itself as a bug in COMPAT
> provider.
>
> Naoto
>
> On 11/17/19 11:16 PM, Mark Davis ?? wrote:
> > You'd have to look at the spec. For most names a pattern plus the
> > country name is used. That can be overridden with a non-composed name
> > where needed.
> >
> > {phone}
> >
> > On Sun, Nov 17, 2019, 21:50 Martin Buchholz <martinrb at google.com
> > <mailto:martinrb at google.com>> wrote:
> >
> >     I've always wondered how the timezone-related translations are
> managed.
> >     CLDR seems to be the master repository of such data, and projects
> like
> >     OpenJDK are simply supposed to import that data.
> >     But I looked at the CLDR sources, and there doesn't seem to be any
> >     "Turkey
> >     Time" strings defined like there are for e.g. Turkmenistan.
> >     Maybe that work never got done?
> >
> >     On Sat, Nov 16, 2019 at 6:44 AM <naoto.sato at oracle.com
> >     <mailto:naoto.sato at oracle.com>> wrote:
> >
> >      > Letu,
> >      >
> >      > Please go ahead and fix the issue in English resource. As to the
> >      > translation, Oracle l10n will translate it in appropriate locales.
> >      >
> >      > Naoto
> >      >
> >      > On 11/15/19 5:56 PM, Yang, Letu wrote:
> >      > > Hi Naoto
> >      > >
> >      > > Thank you for the quick response! We will file a ticket later
> >     today.
> >      > >
> >      > > Shall we make an effort on fixing and translating the strings,
> >     or you
> >      > > prefer to take care of it at Oracle?
> >      > >
> >      > > Letu
> >      > >
> >      > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com
> >     <mailto:naoto.sato at oracle.com> wrote:
> >      > > Hi Letu,
> >      > >
> >      > > Please file a JBS issue for this (component: core-libs,
> >     subcomponent:
> >      > > java.util:i18n).
> >      > >
> >      > > Naoto
> >      > >
> >      > > On 11/15/19 3:19 PM, Yang, Letu wrote:
> >      > >> Hi,
> >      > >>
> >      > >> We recently found an issue with the Time Zone name for
> >      > ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to
> >     their own
> >      > Turkish Time (TRT) zone in 2016, although the tzdata had been
> >     updated, the
> >      > Time Zone name string has not been updated yet:
> >      > >>
> >      > >>
> >      >
> >
> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
> >      > >>
> >      > >> It still returns "Eastern European Time" for the
> >      > TimeZone.getDisplayName call, which has a summer time while
> >     Turkish Time
> >      > does not. An entry for TRT need to be added to this file, and
> >     assign to
> >      > both "Europe/Istanbul" and "Asian/Istanbul". This also need to
> >     be updated
> >      > for other locales. I can create a JBS issue for this, but I
> >      > > am not sure whether we should fix this bug, or there is an
> existing
> >      > > procedure for this kind of bug which requires language
> translation.
> >      > >>
> >      > >> Letu
> >      > >>
> >      > >>
> >      > >>
> >      >
> >
>

From naoto.sato at oracle.com  Mon Nov 18 17:07:18 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 18 Nov 2019 09:07:18 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
Message-ID: <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>

Hi Letu,

Here are my comments to your changes:

- You will need a regression test for this fix. Take a look at 
test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate 
test cases.

- Fix comment should follow the OpenJDK changeset guideline [1]

- As to the change itself, I would put "Turkey Summer Time"/"TRST" for 
the 3rd and 4th array elements. Even though Turkey time do not observe 
DST, names in those slots should reflect the DST (consistent to other names)

- time zone id "Turkey" (line 1050) should also point to TRT array.

Naoto

[1] http://openjdk.java.net/guide/producingChangeset.html

On 11/17/19 8:54 PM, Yang, Letu wrote:
> Hi Naoto,
> 
> Thank you for the clarification!
> 
> Xin from my team has filed a JBS and uploaded my webrev:
> https://bugs.openjdk.java.net/browse/JDK-8234288
> https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
> 
> Letu
> 
> ?On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
> 
>      Letu,
>      
>      Please go ahead and fix the issue in English resource. As to the
>      translation, Oracle l10n will translate it in appropriate locales.
>      
>      Naoto
>      
>      On 11/15/19 5:56 PM, Yang, Letu wrote:
>      > Hi Naoto
>      >
>      > Thank you for the quick response! We will file a ticket later today.
>      >
>      > Shall we make an effort on fixing and translating the strings, or you
>      > prefer to take care of it at Oracle?
>      >
>      > Letu
>      >
>      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
>      > Hi Letu,
>      >
>      > Please file a JBS issue for this (component: core-libs, subcomponent:
>      > java.util:i18n).
>      >
>      > Naoto
>      >
>      > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      >> Hi,
>      >>
>      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
>      >>
>      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      >>
>      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I
>      > am not sure whether we should fix this bug, or there is an existing
>      > procedure for this kind of bug which requires language translation.
>      >>
>      >> Letu
>      >>
>      >>
>      >>
>      
> 

From naoto.sato at oracle.com  Mon Nov 18 17:15:02 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 18 Nov 2019 09:15:02 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <CAJ2xs_FuTdyX-oGtago=YJQ1McG=EZr-f7FuUBg92GtWGEQmrg@mail.gmail.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <CA+kOe0_RySTOWVmLpbeE8DLus+ek+5Bxy6kfTiZ2MC2zFYqFXA@mail.gmail.com>
 <CAJ2xs_FBJi8xpR_maY571sbaRJjKHy5CoLoShtO-BBgXfsEgcw@mail.gmail.com>
 <87dfcc98-f5d8-ca00-0d84-3fbc0c4253f7@oracle.com>
 <CAJ2xs_FuTdyX-oGtago=YJQ1McG=EZr-f7FuUBg92GtWGEQmrg@mail.gmail.com>
Message-ID: <7392fc19-2e99-ee83-1f0c-0faa54ef61dc@oracle.com>

I should have been clearer, but the bug seems to be in the JDK tool 
which converts CLDR's xml into JDK's resource bundles. I implemented the 
CLDR's time zone names fallback spec with 
https://bugs.openjdk.java.net/browse/JDK-8181157, but again there seems 
to be a bug in the code.

Filed a JDK bug: https://bugs.openjdk.java.net/browse/JDK-8234347

Naoto

On 11/18/19 9:08 AM, Mark Davis ?? wrote:
> Could you file a ticket at
> https://unicode-org.atlassian.net/ ?
> 
> {phone}
> 
> On Mon, Nov 18, 2019, 16:02 <naoto.sato at oracle.com 
> <mailto:naoto.sato at oracle.com>> wrote:
> 
>     Thanks, Mark.
> 
>     Apparently there seems to be a bug in CLDR converter code, which cannot
>     generate the localized names for "Turkey" metazone. Thus the localized
>     names from the legacy COMPAT locale data are being used. I will look
>     into it.
> 
>     Apart from this, what Letu found out stands by itself as a bug in
>     COMPAT
>     provider.
> 
>     Naoto
> 
>     On 11/17/19 11:16 PM, Mark Davis ?? wrote:
>      > You'd have to look at the spec. For most names a pattern plus the
>      > country name is used. That can be overridden with a non-composed
>     name
>      > where needed.
>      >
>      > {phone}
>      >
>      > On Sun, Nov 17, 2019, 21:50 Martin Buchholz <martinrb at google.com
>     <mailto:martinrb at google.com>
>      > <mailto:martinrb at google.com <mailto:martinrb at google.com>>> wrote:
>      >
>      >? ? ?I've always wondered how the timezone-related translations
>     are managed.
>      >? ? ?CLDR seems to be the master repository of such data, and
>     projects like
>      >? ? ?OpenJDK are simply supposed to import that data.
>      >? ? ?But I looked at the CLDR sources, and there doesn't seem to
>     be any
>      >? ? ?"Turkey
>      >? ? ?Time" strings defined like there are for e.g. Turkmenistan.
>      >? ? ?Maybe that work never got done?
>      >
>      >? ? ?On Sat, Nov 16, 2019 at 6:44 AM <naoto.sato at oracle.com
>     <mailto:naoto.sato at oracle.com>
>      >? ? ?<mailto:naoto.sato at oracle.com
>     <mailto:naoto.sato at oracle.com>>> wrote:
>      >
>      >? ? ? > Letu,
>      >? ? ? >
>      >? ? ? > Please go ahead and fix the issue in English resource. As
>     to the
>      >? ? ? > translation, Oracle l10n will translate it in appropriate
>     locales.
>      >? ? ? >
>      >? ? ? > Naoto
>      >? ? ? >
>      >? ? ? > On 11/15/19 5:56 PM, Yang, Letu wrote:
>      >? ? ? > > Hi Naoto
>      >? ? ? > >
>      >? ? ? > > Thank you for the quick response! We will file a ticket
>     later
>      >? ? ?today.
>      >? ? ? > >
>      >? ? ? > > Shall we make an effort on fixing and translating the
>     strings,
>      >? ? ?or you
>      >? ? ? > > prefer to take care of it at Oracle?
>      >? ? ? > >
>      >? ? ? > > Letu
>      >? ? ? > >
>      >? ? ? > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com
>     <mailto:naoto.sato at oracle.com>
>      >? ? ?<mailto:naoto.sato at oracle.com <mailto:naoto.sato at oracle.com>>
>     wrote:
>      >? ? ? > > Hi Letu,
>      >? ? ? > >
>      >? ? ? > > Please file a JBS issue for this (component: core-libs,
>      >? ? ?subcomponent:
>      >? ? ? > > java.util:i18n).
>      >? ? ? > >
>      >? ? ? > > Naoto
>      >? ? ? > >
>      >? ? ? > > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      >? ? ? > >> Hi,
>      >? ? ? > >>
>      >? ? ? > >> We recently found an issue with the Time Zone name for
>      >? ? ? > ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to
>      >? ? ?their own
>      >? ? ? > Turkish Time (TRT) zone in 2016, although the tzdata had been
>      >? ? ?updated, the
>      >? ? ? > Time Zone name string has not been updated yet:
>      >? ? ? > >>
>      >? ? ? > >>
>      >? ? ? >
>      >
>     https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      >? ? ? > >>
>      >? ? ? > >> It still returns "Eastern European Time" for the
>      >? ? ? > TimeZone.getDisplayName call, which has a summer time while
>      >? ? ?Turkish Time
>      >? ? ? > does not. An entry for TRT need to be added to this file, and
>      >? ? ?assign to
>      >? ? ? > both "Europe/Istanbul" and "Asian/Istanbul". This also
>     need to
>      >? ? ?be updated
>      >? ? ? > for other locales. I can create a JBS issue for this, but I
>      >? ? ? > > am not sure whether we should fix this bug, or there is
>     an existing
>      >? ? ? > > procedure for this kind of bug which requires language
>     translation.
>      >? ? ? > >>
>      >? ? ? > >> Letu
>      >? ? ? > >>
>      >? ? ? > >>
>      >? ? ? > >>
>      >? ? ? >
>      >
> 

From letuyang at amazon.com  Thu Nov 21 05:43:46 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Thu, 21 Nov 2019 05:43:46 +0000
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
Message-ID: <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>

Hi Naoto,

Thank you for the suggestions!

I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/ 

Letu

?On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:

    Hi Letu,
    
    Here are my comments to your changes:
    
    - You will need a regression test for this fix. Take a look at 
    test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate 
    test cases.
    
    - Fix comment should follow the OpenJDK changeset guideline [1]
    
    - As to the change itself, I would put "Turkey Summer Time"/"TRST" for 
    the 3rd and 4th array elements. Even though Turkey time do not observe 
    DST, names in those slots should reflect the DST (consistent to other names)
    
    - time zone id "Turkey" (line 1050) should also point to TRT array.
    
    Naoto
    
    [1] http://openjdk.java.net/guide/producingChangeset.html
    
    On 11/17/19 8:54 PM, Yang, Letu wrote:
    > Hi Naoto,
    > 
    > Thank you for the clarification!
    > 
    > Xin from my team has filed a JBS and uploaded my webrev:
    > https://bugs.openjdk.java.net/browse/JDK-8234288
    > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
    > 
    > Letu
    > 
    > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
    > 
    >      Letu,
    >      
    >      Please go ahead and fix the issue in English resource. As to the
    >      translation, Oracle l10n will translate it in appropriate locales.
    >      
    >      Naoto
    >      
    >      On 11/15/19 5:56 PM, Yang, Letu wrote:
    >      > Hi Naoto
    >      >
    >      > Thank you for the quick response! We will file a ticket later today.
    >      >
    >      > Shall we make an effort on fixing and translating the strings, or you
    >      > prefer to take care of it at Oracle?
    >      >
    >      > Letu
    >      >
    >      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
    >      > Hi Letu,
    >      >
    >      > Please file a JBS issue for this (component: core-libs, subcomponent:
    >      > java.util:i18n).
    >      >
    >      > Naoto
    >      >
    >      > On 11/15/19 3:19 PM, Yang, Letu wrote:
    >      >> Hi,
    >      >>
    >      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
    >      >>
    >      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
    >      >>
    >      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I
    >      > am not sure whether we should fix this bug, or there is an existing
    >      > procedure for this kind of bug which requires language translation.
    >      >>
    >      >> Letu
    >      >>
    >      >>
    >      >>
    >      
    > 
    


From naoto.sato at oracle.com  Thu Nov 21 17:16:59 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 21 Nov 2019 09:16:59 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
Message-ID: <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>

Hi Letu,

The change in the resource bundle file looks good.

As to the regression test, I would avoid adding a separate file, instead 
add some variations for 
open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add 
some lines in "LocaleData" file, which contains the expected resources 
for the COMPAT locale provider.

Naoto

On 11/20/19 9:43 PM, Yang, Letu wrote:
> Hi Naoto,
> 
> Thank you for the suggestions!
> 
> I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/
> 
> Letu
> 
> ?On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
> 
>      Hi Letu,
>      
>      Here are my comments to your changes:
>      
>      - You will need a regression test for this fix. Take a look at
>      test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate
>      test cases.
>      
>      - Fix comment should follow the OpenJDK changeset guideline [1]
>      
>      - As to the change itself, I would put "Turkey Summer Time"/"TRST" for
>      the 3rd and 4th array elements. Even though Turkey time do not observe
>      DST, names in those slots should reflect the DST (consistent to other names)
>      
>      - time zone id "Turkey" (line 1050) should also point to TRT array.
>      
>      Naoto
>      
>      [1] http://openjdk.java.net/guide/producingChangeset.html
>      
>      On 11/17/19 8:54 PM, Yang, Letu wrote:
>      > Hi Naoto,
>      >
>      > Thank you for the clarification!
>      >
>      > Xin from my team has filed a JBS and uploaded my webrev:
>      > https://bugs.openjdk.java.net/browse/JDK-8234288
>      > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
>      >
>      > Letu
>      >
>      > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >
>      >      Letu,
>      >
>      >      Please go ahead and fix the issue in English resource. As to the
>      >      translation, Oracle l10n will translate it in appropriate locales.
>      >
>      >      Naoto
>      >
>      >      On 11/15/19 5:56 PM, Yang, Letu wrote:
>      >      > Hi Naoto
>      >      >
>      >      > Thank you for the quick response! We will file a ticket later today.
>      >      >
>      >      > Shall we make an effort on fixing and translating the strings, or you
>      >      > prefer to take care of it at Oracle?
>      >      >
>      >      > Letu
>      >      >
>      >      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
>      >      > Hi Letu,
>      >      >
>      >      > Please file a JBS issue for this (component: core-libs, subcomponent:
>      >      > java.util:i18n).
>      >      >
>      >      > Naoto
>      >      >
>      >      > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      >      >> Hi,
>      >      >>
>      >      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
>      >      >>
>      >      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      >      >>
>      >      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I
>      >      > am not sure whether we should fix this bug, or there is an existing
>      >      > procedure for this kind of bug which requires language translation.
>      >      >>
>      >      >> Letu
>      >      >>
>      >      >>
>      >      >>
>      >
>      >
>      
> 

From letuyang at amazon.com  Sat Nov 23 00:16:45 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Sat, 23 Nov 2019 00:16:45 +0000
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
 <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>
Message-ID: <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>

Hi Naoto,

Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/ 

Letu

?On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:

    Hi Letu,
    
    The change in the resource bundle file looks good.
    
    As to the regression test, I would avoid adding a separate file, instead 
    add some variations for 
    open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add 
    some lines in "LocaleData" file, which contains the expected resources 
    for the COMPAT locale provider.
    
    Naoto
    
    On 11/20/19 9:43 PM, Yang, Letu wrote:
    > Hi Naoto,
    > 
    > Thank you for the suggestions!
    > 
    > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/
    > 
    > Letu
    > 
    > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
    > 
    >      Hi Letu,
    >      
    >      Here are my comments to your changes:
    >      
    >      - You will need a regression test for this fix. Take a look at
    >      test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate
    >      test cases.
    >      
    >      - Fix comment should follow the OpenJDK changeset guideline [1]
    >      
    >      - As to the change itself, I would put "Turkey Summer Time"/"TRST" for
    >      the 3rd and 4th array elements. Even though Turkey time do not observe
    >      DST, names in those slots should reflect the DST (consistent to other names)
    >      
    >      - time zone id "Turkey" (line 1050) should also point to TRT array.
    >      
    >      Naoto
    >      
    >      [1] http://openjdk.java.net/guide/producingChangeset.html
    >      
    >      On 11/17/19 8:54 PM, Yang, Letu wrote:
    >      > Hi Naoto,
    >      >
    >      > Thank you for the clarification!
    >      >
    >      > Xin from my team has filed a JBS and uploaded my webrev:
    >      > https://bugs.openjdk.java.net/browse/JDK-8234288
    >      > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
    >      >
    >      > Letu
    >      >
    >      > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
    >      >
    >      >      Letu,
    >      >
    >      >      Please go ahead and fix the issue in English resource. As to the
    >      >      translation, Oracle l10n will translate it in appropriate locales.
    >      >
    >      >      Naoto
    >      >
    >      >      On 11/15/19 5:56 PM, Yang, Letu wrote:
    >      >      > Hi Naoto
    >      >      >
    >      >      > Thank you for the quick response! We will file a ticket later today.
    >      >      >
    >      >      > Shall we make an effort on fixing and translating the strings, or you
    >      >      > prefer to take care of it at Oracle?
    >      >      >
    >      >      > Letu
    >      >      >
    >      >      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
    >      >      > Hi Letu,
    >      >      >
    >      >      > Please file a JBS issue for this (component: core-libs, subcomponent:
    >      >      > java.util:i18n).
    >      >      >
    >      >      > Naoto
    >      >      >
    >      >      > On 11/15/19 3:19 PM, Yang, Letu wrote:
    >      >      >> Hi,
    >      >      >>
    >      >      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
    >      >      >>
    >      >      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
    >      >      >>
    >      >      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I
    >      >      > am not sure whether we should fix this bug, or there is an existing
    >      >      > procedure for this kind of bug which requires language translation.
    >      >      >>
    >      >      >> Letu
    >      >      >>
    >      >      >>
    >      >      >>
    >      >
    >      >
    >      
    > 
    


From naoto.sato at oracle.com  Sat Nov 23 00:38:12 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 22 Nov 2019 16:38:12 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
 <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>
 <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>
Message-ID: <d036620c-eb50-164b-1589-d3247cf71835@oracle.com>

Hi Letu,

You might want to add lines for "Turkey" zone as well in LocaleData?

Naoto

On 11/22/19 4:16 PM, Yang, Letu wrote:
> Hi Naoto,
> 
> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/
> 
> Letu
> 
> ?On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
> 
>      Hi Letu,
>      
>      The change in the resource bundle file looks good.
>      
>      As to the regression test, I would avoid adding a separate file, instead
>      add some variations for
>      open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add
>      some lines in "LocaleData" file, which contains the expected resources
>      for the COMPAT locale provider.
>      
>      Naoto
>      
>      On 11/20/19 9:43 PM, Yang, Letu wrote:
>      > Hi Naoto,
>      >
>      > Thank you for the suggestions!
>      >
>      > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/
>      >
>      > Letu
>      >
>      > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >
>      >      Hi Letu,
>      >
>      >      Here are my comments to your changes:
>      >
>      >      - You will need a regression test for this fix. Take a look at
>      >      test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate
>      >      test cases.
>      >
>      >      - Fix comment should follow the OpenJDK changeset guideline [1]
>      >
>      >      - As to the change itself, I would put "Turkey Summer Time"/"TRST" for
>      >      the 3rd and 4th array elements. Even though Turkey time do not observe
>      >      DST, names in those slots should reflect the DST (consistent to other names)
>      >
>      >      - time zone id "Turkey" (line 1050) should also point to TRT array.
>      >
>      >      Naoto
>      >
>      >      [1] http://openjdk.java.net/guide/producingChangeset.html
>      >
>      >      On 11/17/19 8:54 PM, Yang, Letu wrote:
>      >      > Hi Naoto,
>      >      >
>      >      > Thank you for the clarification!
>      >      >
>      >      > Xin from my team has filed a JBS and uploaded my webrev:
>      >      > https://bugs.openjdk.java.net/browse/JDK-8234288
>      >      > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
>      >      >
>      >      > Letu
>      >      >
>      >      > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >      >
>      >      >      Letu,
>      >      >
>      >      >      Please go ahead and fix the issue in English resource. As to the
>      >      >      translation, Oracle l10n will translate it in appropriate locales.
>      >      >
>      >      >      Naoto
>      >      >
>      >      >      On 11/15/19 5:56 PM, Yang, Letu wrote:
>      >      >      > Hi Naoto
>      >      >      >
>      >      >      > Thank you for the quick response! We will file a ticket later today.
>      >      >      >
>      >      >      > Shall we make an effort on fixing and translating the strings, or you
>      >      >      > prefer to take care of it at Oracle?
>      >      >      >
>      >      >      > Letu
>      >      >      >
>      >      >      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
>      >      >      > Hi Letu,
>      >      >      >
>      >      >      > Please file a JBS issue for this (component: core-libs, subcomponent:
>      >      >      > java.util:i18n).
>      >      >      >
>      >      >      > Naoto
>      >      >      >
>      >      >      > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      >      >      >> Hi,
>      >      >      >>
>      >      >      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
>      >      >      >>
>      >      >      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      >      >      >>
>      >      >      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I
>      >      >      > am not sure whether we should fix this bug, or there is an existing
>      >      >      > procedure for this kind of bug which requires language translation.
>      >      >      >>
>      >      >      >> Letu
>      >      >      >>
>      >      >      >>
>      >      >      >>
>      >      >
>      >      >
>      >
>      >
>      
> 

From letuyang at amazon.com  Sat Nov 23 05:55:35 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Sat, 23 Nov 2019 05:55:35 +0000
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <d036620c-eb50-164b-1589-d3247cf71835@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
 <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>
 <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>,
 <d036620c-eb50-164b-1589-d3247cf71835@oracle.com>
Message-ID: <32588966-0750-4916-8583-a4af328ecbcd@amazon.com>

Hi Naoto,

Added it in the new webrev https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks!

Letu


On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote:
Hi Letu,

You might want to add lines for "Turkey" zone as well in LocaleData?

Naoto

On 11/22/19 4:16 PM, Yang, Letu wrote:
> Hi Naoto,
>
> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/
>
> Letu
>
> ?On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>
>      Hi Letu,
>
>      The change in the resource bundle file looks good.
>
>      As to the regression test, I would avoid adding a separate file, instead
>      add some variations for
>      open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add
>      some lines in "LocaleData" file, which contains the expected resources
>      for the COMPAT locale provider.
>
>      Naoto
>
>      On 11/20/19 9:43 PM, Yang, Letu wrote:
>      > Hi Naoto,
>      >
>      > Thank you for the suggestions!
>      >
>      > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/
>      >
>      > Letu
>      >
>      > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >
>      >      Hi Letu,
>      >
>      >      Here are my comments to your changes:
>      >
>      >      - You will need a regression test for this fix. Take a look at
>      >      test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate
>      >      test cases.
>      >
>      >      - Fix comment should follow the OpenJDK changeset guideline [1]
>      >
>      >      - As to the change itself, I would put "Turkey Summer Time"/"TRST" for
>      >      the 3rd and 4th array elements. Even though Turkey time do not observe
>      >      DST, names in those slots should reflect the DST (consistent to other names)
>      >
>      >      - time zone id "Turkey" (line 1050) should also point to TRT array.
>      >
>      >      Naoto
>      >
>      >      [1] http://openjdk.java.net/guide/producingChangeset.html
>      >
>      >      On 11/17/19 8:54 PM, Yang, Letu wrote:
>      >      > Hi Naoto,
>      >      >
>      >      > Thank you for the clarification!
>      >      >
>      >      > Xin from my team has filed a JBS and uploaded my webrev:
>      >      > https://bugs.openjdk.java.net/browse/JDK-8234288
>      >      > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
>      >      >
>      >      > Letu
>      >      >
>      >      > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >      >
>      >      >      Letu,
>      >      >
>      >      >      Please go ahead and fix the issue in English resource. As to the
>      >      >      translation, Oracle l10n will translate it in appropriate locales.
>      >      >
>      >      >      Naoto
>      >      >
>      >      >      On 11/15/19 5:56 PM, Yang, Letu wrote:
>      >      >      > Hi Naoto
>      >      >      >
>      >      >      > Thank you for the quick response! We will file a ticket later today.
>      >      >      >
>      >      >      > Shall we make an effort on fixing and translating the strings, or you
>      >      >      > prefer to take care of it at Oracle?
>      >      >      >
>      >      >      > Letu
>      >      >      >
>      >      >      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
>      >      >      > Hi Letu,
>      >      >      >
>      >      >      > Please file a JBS issue for this (component: core-libs, subcomponent:
>      >      >      > java.util:i18n).
>      >      >      >
>      >      >      > Naoto
>      >      >      >
>      >      >      > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      >      >      >> Hi,
>      >      >      >>
>      >      >      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet:
>      >      >      >>
>      >      >      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      >      >      >>
>      >      >      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to  be updated for other locales. I can create a JBS issue for this, but I
>      >      >      > am not sure whether we should fix this bug, or there is an existing
>      >      >      > procedure for this kind of bug which requires language translation.
>      >      >      >>
>      >      >      >> Letu
>      >      >      >>
>      >      >      >>
>      >      >      >>
>      >      >
>      >      >
>      >
>      >
>
>

From naoto.sato at oracle.com  Sun Nov 24 02:09:14 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Sat, 23 Nov 2019 18:09:14 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <32588966-0750-4916-8583-a4af328ecbcd@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
 <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>
 <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>
 <d036620c-eb50-164b-1589-d3247cf71835@oracle.com>
 <32588966-0750-4916-8583-a4af328ecbcd@amazon.com>
Message-ID: <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com>

Looks good.

Naoto

On 11/22/19 9:55 PM, Yang, Letu wrote:
> Hi Naoto,
> 
> Added it in the new webrev 
> https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks!
> 
> Letu
> 
> 
> On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote:
> Hi Letu,
> 
> You might want to add lines for "Turkey" zone as well in LocaleData?
> 
> Naoto
> 
> On 11/22/19 4:16 PM, Yang, Letu wrote:
>> Hi Naoto,
>> 
>> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/
>> 
>> Letu
>> 
>> ?On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>> 
>>????? Hi Letu,
>>      
>>????? The change in the resource bundle file looks good.
>>      
>>????? As to the regression test, I would avoid adding a separate file, instead
>>????? add some variations for
>>????? open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add
>>????? some lines in "LocaleData" file, which contains the expected resources
>>????? for the COMPAT locale provider.
>>      
>>????? Naoto
>>      
>>????? On 11/20/19 9:43 PM, Yang, Letu wrote:
>>????? > Hi Naoto,
>>????? >
>>????? > Thank you for the suggestions!
>>????? >
>>????? > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/
>>????? >
>>????? > Letu
>>????? >
>>????? > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>>????? >
>>????? >????? Hi Letu,
>>????? >
>>????? >????? Here are my comments to your changes:
>>????? >
>>????? >????? - You will need a regression test for this fix. Take a look at
>>????? >????? test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate
>>????? >????? test cases.
>>????? >
>>????? >????? - Fix comment should follow the OpenJDK changeset guideline [1]
>>????? >
>>????? >????? - As to the change itself, I would put "Turkey Summer Time"/"TRST" for
>>????? >????? the 3rd and 4th array elements. Even though Turkey time do not observe
>>????? >????? DST, names in those slots should reflect the DST (consistent to other names)
>>????? >
>>????? >????? - time zone id "Turkey" (line 1050) should also point to TRT array.
>>????? >
>>????? >????? Naoto
>>????? >
>>????? >????? [1] http://openjdk.java.net/guide/producingChangeset.html
>>????? >
>>????? >????? On 11/17/19 8:54 PM, Yang, Letu wrote:
>>????? >????? > Hi Naoto,
>>????? >????? >
>>????? >????? > Thank you for the clarification!
>>????? >????? >
>>????? >????? > Xin from my team has filed a JBS and uploaded my webrev:
>>????? >????? > https://bugs.openjdk.java.net/browse/JDK-8234288
>>????? >????? > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
>>????? >????? >
>>????? >????? > Letu
>>????? >????? >
>>????? >????? > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>>????? >????? >
>>????? >????? >????? Letu,
>>????? >????? >
>>????? >????? >????? Please go ahead and fix the issue in English resource. As to the
>>????? >????? >????? translation, Oracle l10n will translate it in appropriate locales.
>>????? >????? >
>>????? >????? >????? Naoto
>>????? >????? >
>>????? >????? >????? On 11/15/19 5:56 PM, Yang, Letu wrote:
>>????? >????? >????? > Hi Naoto
>>????? >????? >????? >
>>????? >????? >????? > Thank you for the quick response! We will file a ticket later today.
>>????? >????? >????? >
>>????? >????? >????? > Shall we make an effort on fixing and translating the strings, or you
>>????? >????? >????? > prefer to take care of it at Oracle?
>>????? >????? >????? >
>>????? >????? >????? > Letu
>>????? >????? >????? >
>>????? >????? >????? > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
>>????? >????? >????? > Hi Letu,
>>????? >????? >????? >
>>????? >????? >????? > Please file a JBS issue for this (component: core-libs, subcomponent:
>>????? >????? >????? > java.util:i18n).
>>????? >????? >????? >
>>????? >????? >????? > Naoto
>>????? >????? >????? >
>>????? >????? >????? > On 11/15/19 3:19 PM, Yang, Letu wrote:
>>????? >????? >????? >> Hi,
>>????? >????? >????? >>
>>????? >????? >????? >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been  updated yet:
>>????? >????? >????? >>
>>????? >????? >????? >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>>????? >????? >????? >>
>>????? >????? >????? >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul".  This also need to? be updated for other locales. I can create a JBS 
> issue for this, but I
>>????? >????? >????? > am not sure whether we should fix this bug, or there is an existing
>>????? >????? >????? > procedure for this kind of bug which requires language translation.
>>????? >????? >????? >>
>>????? >????? >????? >> Letu
>>????? >????? >????? >>
>>????? >????? >????? >>
>>????? >????? >????? >>
>>????? >????? >
>>????? >????? >
>>????? >
>>????? >
>>      
>> 

From martinrb at google.com  Mon Nov 25 18:26:19 2019
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 25 Nov 2019 10:26:19 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <32588966-0750-4916-8583-a4af328ecbcd@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
 <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>
 <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>
 <d036620c-eb50-164b-1589-d3247cf71835@oracle.com>
 <32588966-0750-4916-8583-a4af328ecbcd@amazon.com>
Message-ID: <CA+kOe08cgKe8qqAhnhip91aSDbXtg1dCJfYBqa372YkMh08fsA@mail.gmail.com>

\ No newline at end of file

Please fix.

From letuyang at amazon.com  Mon Nov 25 18:43:10 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Mon, 25 Nov 2019 18:43:10 +0000
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <CA+kOe08cgKe8qqAhnhip91aSDbXtg1dCJfYBqa372YkMh08fsA@mail.gmail.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
 <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>
 <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>
 <d036620c-eb50-164b-1589-d3247cf71835@oracle.com>
 <32588966-0750-4916-8583-a4af328ecbcd@amazon.com>
 <CA+kOe08cgKe8qqAhnhip91aSDbXtg1dCJfYBqa372YkMh08fsA@mail.gmail.com>
Message-ID: <7C49485A-7967-4F56-B00F-A4D3B178C709@amazon.com>

Fixed in https://cr.openjdk.java.net/~xliu/8234288/webrev.04/ Thanks!

From: Martin Buchholz <martinrb at google.com>
Date: Monday, November 25, 2019 at 10:27 AM
To: "Yang, Letu" <letuyang at amazon.com>
Cc: "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>, "i18n-dev at openjdk.java.net" <i18n-dev at openjdk.java.net>, "naoto.sato at oracle.com" <naoto.sato at oracle.com>, Leo Jiang <li.jiang at oracle.com>, "Liu, Xin" <xxinliu at amazon.com>
Subject: Re: <i18n dev> Turkish Time Zone name string and translation


\ No newline at end of file
Please fix.

From naoto.sato at oracle.com  Mon Nov 25 21:16:55 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 25 Nov 2019 13:16:55 -0800
Subject: <i18n dev> [14] RFR: 8222756: Plural support in CompactNumberFormat
Message-ID: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com>

Hello,

CompactNumberFormat has been added since JDK 12 to support compact 
number formatting, such as 10_000 being formatted as "10K." [1] It works 
fine for English, however, not for other languages that take plural 
forms in formatted number prefixes/suffixes. In order to fix this, I 
filed the following CSR to extend the current CompactNumberFormat spec:

https://bugs.openjdk.java.net/browse/JDK-8232633

It basically accommodates the plural prefix/suffix forms into the 
existing compact patterns array, so that the existing compact number 
format works compatibly. The plural rules are solely based on the CLDR's 
plural language rules [2]

Here is the implementation of the CSR:

https://cr.openjdk.java.net/~naoto/8222756/webrev.00/

Please review the CSR as well as its implementation.

Naoto


[1] https://bugs.openjdk.java.net/browse/JDK-8177552
[2] https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules

From naoto.sato at oracle.com  Tue Nov 26 21:35:09 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 26 Nov 2019 13:35:09 -0800
Subject: <i18n dev> [14] RFR: 8222756: Plural support in
	CompactNumberFormat
In-Reply-To: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com>
References: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com>
Message-ID: <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com>

I modified CompactNumberFormat.java to simplify the syntax parsing:

https://cr.openjdk.java.net/~naoto/8222756/webrev.01/

Please review this webrev instead.

Naoto

On 11/25/19 1:16 PM, naoto.sato at oracle.com wrote:
> Hello,
> 
> CompactNumberFormat has been added since JDK 12 to support compact 
> number formatting, such as 10_000 being formatted as "10K." [1] It works 
> fine for English, however, not for other languages that take plural 
> forms in formatted number prefixes/suffixes. In order to fix this, I 
> filed the following CSR to extend the current CompactNumberFormat spec:
> 
> https://bugs.openjdk.java.net/browse/JDK-8232633
> 
> It basically accommodates the plural prefix/suffix forms into the 
> existing compact patterns array, so that the existing compact number 
> format works compatibly. The plural rules are solely based on the CLDR's 
> plural language rules [2]
> 
> Here is the implementation of the CSR:
> 
> https://cr.openjdk.java.net/~naoto/8222756/webrev.00/
> 
> Please review the CSR as well as its implementation.
> 
> Naoto
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8177552
> [2] 
> https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules