From masayoshi.okutsu at oracle.com  Mon Mar  4 15:30:24 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 05 Mar 2013 08:30:24 +0900
Subject: <i18n dev> [8]Review request for 8004240
In-Reply-To: <512BF4FF.2070908@oracle.com>
References: <5127DFDB.1030900@oracle.com> <512AC97E.4020205@oracle.com>
	<512BB7BC.60905@oracle.com> <512BF4FF.2070908@oracle.com>
Message-ID: <51352E90.60001@oracle.com>

Looks good to me.

Masayoshi

On 2/26/2013 8:34 AM, Naoto Sato wrote:
> (modified the title)
>
> OK, so this is the review request for 8004240 fix. I changed the type 
> of 'adapterPreference' from 'Type[]' to 'List<Type>' and initialized 
> it with the 'unmodifiableList'.
>
> http://cr.openjdk.java.net/~naoto/8004240/webrev.00/
>
> Naoto
>
> On 2/25/13 11:13 AM, Naoto Sato wrote:
>> Thank you for the review. Please see my comments embedded below.
>>
>> On 2/24/13 6:16 PM, Masayoshi Okutsu wrote:
>>> For 8004240, I think adapterPreference should be changed to an
>>> unmodifiable List because getAdapterPreference() is called often.
>>
>> Agree. Will change the impl.
>>
>>>
>>> For 8008577, I think it's a spec change to 6336885, and that CCC
>>> approval is required. And should the CLDR adapter be initialized and be
>>> removed from the list if the initialization failed?
>>
>> I think which locale provider adapters are implemented (and enabled)
>> depends on each JRE's implementation, not the spec. However, since this
>> is going to change Oracle's JRE behavior (even from yet released jdk8
>> beta builds), I will file a CCC request for this.
>>
>> Anyway, I think I'll need to split this review request into two. Will do
>> it shortly.
>>
>> Naoto
>>
>>>
>>> Masayoshi
>>>
>>>
>>> On 2/23/2013 6:15 AM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the changes for the following CR:
>>>>
>>>> 8004240 : Return value from getAdapterPrefence() can be modified
>>>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004240)
>>>> 8008577 : Enable CLDR LocaleProviderAdapter by default
>>>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008577)
>>>>
>>>> The webrev is located at:
>>>> http://cr.openjdk.java.net/~naoto/8004240.8008577/webrev.00/
>>>>
>>>> Naoto
>>>
>>
>


From naoto.sato at oracle.com  Fri Mar  8 15:45:38 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 08 Mar 2013 15:45:38 -0800
Subject: <i18n dev> [8]Request for review - 8008576: Calendar mismatch using
	Host LocaleProviderAdapter
Message-ID: <513A7822.9010802@oracle.com>

Hello,

Please review the changes for the following CR:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008576

Here is the webrev for the changes:

http://cr.openjdk.java.net/~naoto/8008576/webrev.00/

The gist of the changes is to instantiate a calendar instance using the 
new Calendar.Builder class that suits the underlying OS's calendar for 
the current user's locale.

Naoto

From masayoshi.okutsu at oracle.com  Mon Mar 11 00:47:13 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 11 Mar 2013 16:47:13 +0900
Subject: <i18n dev> [8]Request for review - 8008576: Calendar mismatch
 using Host LocaleProviderAdapter
In-Reply-To: <513A7822.9010802@oracle.com>
References: <513A7822.9010802@oracle.com>
Message-ID: <513D8C01.9010107@oracle.com>

Here are my review comments.

- The Calendar.createCalendar comment says, "but it's not possible since 
JapaneseImperialCalendar is package private." If Calendar.Builder 
doesn't work, should the reason be different? Otherwise, the host locale 
adapters won't be able to create a JapaneseImperialCalendar, either.

- When building a Calendar with Calendar.Builder, the current time needs 
to be set (.setInstant(System.currentMillis())).

- The usage of term "POSIX locale" in Mac OS sounds strange. POSIX 
locale means C locale...

Otherwise, the change looks good to me.

Thanks,
Masayoshi

On 3/9/2013 8:45 AM, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following CR:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008576
>
> Here is the webrev for the changes:
>
> http://cr.openjdk.java.net/~naoto/8008576/webrev.00/
>
> The gist of the changes is to instantiate a calendar instance using 
> the new Calendar.Builder class that suits the underlying OS's calendar 
> for the current user's locale.
>
> Naoto


From naoto.sato at oracle.com  Mon Mar 11 16:04:41 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 11 Mar 2013 16:04:41 -0700
Subject: <i18n dev> [8]Request for review - 8008576: Calendar mismatch
 using Host LocaleProviderAdapter
In-Reply-To: <513D8C01.9010107@oracle.com>
References: <513A7822.9010802@oracle.com> <513D8C01.9010107@oracle.com>
Message-ID: <513E6309.8010007@oracle.com>

Thank you for the review. Please find my comments below:

On 3/11/13 12:47 AM, Masayoshi Okutsu wrote:
> Here are my review comments.
>
> - The Calendar.createCalendar comment says, "but it's not possible since
> JapaneseImperialCalendar is package private." If Calendar.Builder
> doesn't work, should the reason be different? Otherwise, the host locale
> adapters won't be able to create a JapaneseImperialCalendar, either.

The code intended to use the same code path for JRE as before, but on 
second thought, there is no reason not to use Calendar.Builder() even 
for JRE. Modified the fix as such.

> - When building a Calendar with Calendar.Builder, the current time needs
> to be set (.setInstant(System.currentMillis())).

Fixed.

> - The usage of term "POSIX locale" in Mac OS sounds strange. POSIX
> locale means C locale...

Right. But that's not under our control :-)

Revised webrev is located at:

http://cr.openjdk.java.net/~naoto/8008576/webrev.01/

Naoto

>
> Otherwise, the change looks good to me.
>
> Thanks,
> Masayoshi
>
> On 3/9/2013 8:45 AM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes for the following CR:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008576
>>
>> Here is the webrev for the changes:
>>
>> http://cr.openjdk.java.net/~naoto/8008576/webrev.00/
>>
>> The gist of the changes is to instantiate a calendar instance using
>> the new Calendar.Builder class that suits the underlying OS's calendar
>> for the current user's locale.
>>
>> Naoto
>


From masayoshi.okutsu at oracle.com  Tue Mar 12 01:44:49 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 12 Mar 2013 17:44:49 +0900
Subject: <i18n dev> [8]Request for review - 8008576: Calendar mismatch
 using Host LocaleProviderAdapter
In-Reply-To: <513E6309.8010007@oracle.com>
References: <513A7822.9010802@oracle.com> <513D8C01.9010107@oracle.com>
	<513E6309.8010007@oracle.com>
Message-ID: <513EEB01.6060800@oracle.com>

Here are my comments on the revised webrev, including a couple of 
oversights in my previous review.

- It's OK to use the existing code path of Calendar for JRE. I thought 
there might be some different reasons that Calendar.Builder wouldn't 
work for JRE.

- JRELocaleProviderAdapter.getCalendarProvider() should use the 
"CalendarData" language tag set.

- Should CalendarProviderImpl.isSupportedLocale always return true 
because it supposed to be able to create a GregorianCalendar as fallback?

- When Calendar uses the default TimeZone, it uses a reference to the 
default TimeZone rather than its clone. But instantiation of Calendar in 
the locale service adapters means to leak the instance outside of a 
Calendar. Could you remove the use of TimeZone.getDefaultRef in 
Calendar. (OK to keep it in java.util.Date)

- CalendarProvider.getInstance may throw an IllegalArgumentException 
which should be caught in Calendar.createCalendar. Note that 
Calendar.Builder.setCalendarType throws an IAE if any invalid calendar 
type is given.

- Calendar.Builder.setCalendarType() accepts "gregorian" as an alias of 
"gregory". It's not necessary to replace "gregorian" with "gregory" in 
HostLocaleProviderAdapterImpl (macosx). (String.replaceFirst is 
expensive. In that sense, replace('_', '-') is cheaper than 
replaceAll("_", "-").)

- I know we can't change the Mac OS X documentation, but the method name 
can be changed. How about convertMacOSLocaleToJavaLocale(String macos) 
or something else which doesn't contain PosixLocale?

Thanks,
Masayoshi

On 3/12/2013 8:04 AM, Naoto Sato wrote:
> Thank you for the review. Please find my comments below:
>
> On 3/11/13 12:47 AM, Masayoshi Okutsu wrote:
>> Here are my review comments.
>>
>> - The Calendar.createCalendar comment says, "but it's not possible since
>> JapaneseImperialCalendar is package private." If Calendar.Builder
>> doesn't work, should the reason be different? Otherwise, the host locale
>> adapters won't be able to create a JapaneseImperialCalendar, either.
>
> The code intended to use the same code path for JRE as before, but on 
> second thought, there is no reason not to use Calendar.Builder() even 
> for JRE. Modified the fix as such.
>
>> - When building a Calendar with Calendar.Builder, the current time needs
>> to be set (.setInstant(System.currentMillis())).
>
> Fixed.
>
>> - The usage of term "POSIX locale" in Mac OS sounds strange. POSIX
>> locale means C locale...
>
> Right. But that's not under our control :-)
>
> Revised webrev is located at:
>
> http://cr.openjdk.java.net/~naoto/8008576/webrev.01/
>
> Naoto
>
>>
>> Otherwise, the change looks good to me.
>>
>> Thanks,
>> Masayoshi
>>
>> On 3/9/2013 8:45 AM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the changes for the following CR:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008576
>>>
>>> Here is the webrev for the changes:
>>>
>>> http://cr.openjdk.java.net/~naoto/8008576/webrev.00/
>>>
>>> The gist of the changes is to instantiate a calendar instance using
>>> the new Calendar.Builder class that suits the underlying OS's calendar
>>> for the current user's locale.
>>>
>>> Naoto
>>
>


From naoto.sato at oracle.com  Tue Mar 12 15:26:40 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 12 Mar 2013 15:26:40 -0700
Subject: <i18n dev> [8]Request for review - 8008576: Calendar mismatch
 using Host LocaleProviderAdapter
In-Reply-To: <513EEB01.6060800@oracle.com>
References: <513A7822.9010802@oracle.com> <513D8C01.9010107@oracle.com>
	<513E6309.8010007@oracle.com> <513EEB01.6060800@oracle.com>
Message-ID: <513FABA0.4020706@oracle.com>

Webrev is updated according to your suggestions:

http://cr.openjdk.java.net/~naoto/8008576/webrev.02/

Please see each comment embedded below:

On 3/12/13 1:44 AM, Masayoshi Okutsu wrote:
> Here are my comments on the revised webrev, including a couple of
> oversights in my previous review.
>
> - It's OK to use the existing code path of Calendar for JRE. I thought
> there might be some different reasons that Calendar.Builder wouldn't
> work for JRE.

No, Calendar.Builder works fine with the JRE LocaleProviderAdapter. 
Issue was JapaneseImperialCalendar could not be instantiated from a 
sun.* package. Now I use Builder for consistency.

> - JRELocaleProviderAdapter.getCalendarProvider() should use the
> "CalendarData" language tag set.
>
> - Should CalendarProviderImpl.isSupportedLocale always return true
> because it supposed to be able to create a GregorianCalendar as fallback?

Fixed.

>
> - When Calendar uses the default TimeZone, it uses a reference to the
> default TimeZone rather than its clone. But instantiation of Calendar in
> the locale service adapters means to leak the instance outside of a
> Calendar. Could you remove the use of TimeZone.getDefaultRef in
> Calendar. (OK to keep it in java.util.Date)

Changed them to the public API, i.e., TimeZone.getDefault(), and removed 
the code that sets "sharedZone" field to "true". Kept the shared zone in 
the Calendar constructors intact, as they won't be leaked outside of 
Calendar.

>
> - CalendarProvider.getInstance may throw an IllegalArgumentException
> which should be caught in Calendar.createCalendar. Note that
> Calendar.Builder.setCalendarType throws an IAE if any invalid calendar
> type is given.

Added the try-catch clause. Fall back to the default impl when the 
exception occurs.

>
> - Calendar.Builder.setCalendarType() accepts "gregorian" as an alias of
> "gregory". It's not necessary to replace "gregorian" with "gregory" in
> HostLocaleProviderAdapterImpl (macosx). (String.replaceFirst is
> expensive. In that sense, replace('_', '-') is cheaper than
> replaceAll("_", "-").)

Applied your suggestions to the applicable sites. One question, though, 
is that why Calendar.getAvailableCalendarTypes() does not return 
aliases, as I could not eliminate all the replaceFirst("gregorian", 
"gregory") calls.

>
> - I know we can't change the Mac OS X documentation, but the method name
> can be changed. How about convertMacOSLocaleToJavaLocale(String macos)
> or something else which doesn't contain PosixLocale?

Fixed.

Naoto

>
> Thanks,
> Masayoshi
>
> On 3/12/2013 8:04 AM, Naoto Sato wrote:
>> Thank you for the review. Please find my comments below:
>>
>> On 3/11/13 12:47 AM, Masayoshi Okutsu wrote:
>>> Here are my review comments.
>>>
>>> - The Calendar.createCalendar comment says, "but it's not possible since
>>> JapaneseImperialCalendar is package private." If Calendar.Builder
>>> doesn't work, should the reason be different? Otherwise, the host locale
>>> adapters won't be able to create a JapaneseImperialCalendar, either.
>>
>> The code intended to use the same code path for JRE as before, but on
>> second thought, there is no reason not to use Calendar.Builder() even
>> for JRE. Modified the fix as such.
>>
>>> - When building a Calendar with Calendar.Builder, the current time needs
>>> to be set (.setInstant(System.currentMillis())).
>>
>> Fixed.
>>
>>> - The usage of term "POSIX locale" in Mac OS sounds strange. POSIX
>>> locale means C locale...
>>
>> Right. But that's not under our control :-)
>>
>> Revised webrev is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8008576/webrev.01/
>>
>> Naoto
>>
>>>
>>> Otherwise, the change looks good to me.
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 3/9/2013 8:45 AM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the changes for the following CR:
>>>>
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008576
>>>>
>>>> Here is the webrev for the changes:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8008576/webrev.00/
>>>>
>>>> The gist of the changes is to instantiate a calendar instance using
>>>> the new Calendar.Builder class that suits the underlying OS's calendar
>>>> for the current user's locale.
>>>>
>>>> Naoto
>>>
>>
>


From masayoshi.okutsu at oracle.com  Thu Mar 14 01:06:48 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 14 Mar 2013 17:06:48 +0900
Subject: <i18n dev> [8]Request for review - 8008576: Calendar mismatch
 using Host LocaleProviderAdapter
In-Reply-To: <513FABA0.4020706@oracle.com>
References: <513A7822.9010802@oracle.com> <513D8C01.9010107@oracle.com>
	<513E6309.8010007@oracle.com> <513EEB01.6060800@oracle.com>
	<513FABA0.4020706@oracle.com>
Message-ID: <51418518.2010509@oracle.com>

Looks good to me.

Thanks,
Masayoshi

On 3/13/2013 7:26 AM, Naoto Sato wrote:
> Webrev is updated according to your suggestions:
>
> http://cr.openjdk.java.net/~naoto/8008576/webrev.02/
>
> Please see each comment embedded below:
>
> On 3/12/13 1:44 AM, Masayoshi Okutsu wrote:
>> Here are my comments on the revised webrev, including a couple of
>> oversights in my previous review.
>>
>> - It's OK to use the existing code path of Calendar for JRE. I thought
>> there might be some different reasons that Calendar.Builder wouldn't
>> work for JRE.
>
> No, Calendar.Builder works fine with the JRE LocaleProviderAdapter. 
> Issue was JapaneseImperialCalendar could not be instantiated from a 
> sun.* package. Now I use Builder for consistency.
>
>> - JRELocaleProviderAdapter.getCalendarProvider() should use the
>> "CalendarData" language tag set.
>>
>> - Should CalendarProviderImpl.isSupportedLocale always return true
>> because it supposed to be able to create a GregorianCalendar as 
>> fallback?
>
> Fixed.
>
>>
>> - When Calendar uses the default TimeZone, it uses a reference to the
>> default TimeZone rather than its clone. But instantiation of Calendar in
>> the locale service adapters means to leak the instance outside of a
>> Calendar. Could you remove the use of TimeZone.getDefaultRef in
>> Calendar. (OK to keep it in java.util.Date)
>
> Changed them to the public API, i.e., TimeZone.getDefault(), and 
> removed the code that sets "sharedZone" field to "true". Kept the 
> shared zone in the Calendar constructors intact, as they won't be 
> leaked outside of Calendar.
>
>>
>> - CalendarProvider.getInstance may throw an IllegalArgumentException
>> which should be caught in Calendar.createCalendar. Note that
>> Calendar.Builder.setCalendarType throws an IAE if any invalid calendar
>> type is given.
>
> Added the try-catch clause. Fall back to the default impl when the 
> exception occurs.
>
>>
>> - Calendar.Builder.setCalendarType() accepts "gregorian" as an alias of
>> "gregory". It's not necessary to replace "gregorian" with "gregory" in
>> HostLocaleProviderAdapterImpl (macosx). (String.replaceFirst is
>> expensive. In that sense, replace('_', '-') is cheaper than
>> replaceAll("_", "-").)
>
> Applied your suggestions to the applicable sites. One question, 
> though, is that why Calendar.getAvailableCalendarTypes() does not 
> return aliases, as I could not eliminate all the 
> replaceFirst("gregorian", "gregory") calls.
>
>>
>> - I know we can't change the Mac OS X documentation, but the method name
>> can be changed. How about convertMacOSLocaleToJavaLocale(String macos)
>> or something else which doesn't contain PosixLocale?
>
> Fixed.
>
> Naoto
>
>>
>> Thanks,
>> Masayoshi
>>
>> On 3/12/2013 8:04 AM, Naoto Sato wrote:
>>> Thank you for the review. Please find my comments below:
>>>
>>> On 3/11/13 12:47 AM, Masayoshi Okutsu wrote:
>>>> Here are my review comments.
>>>>
>>>> - The Calendar.createCalendar comment says, "but it's not possible 
>>>> since
>>>> JapaneseImperialCalendar is package private." If Calendar.Builder
>>>> doesn't work, should the reason be different? Otherwise, the host 
>>>> locale
>>>> adapters won't be able to create a JapaneseImperialCalendar, either.
>>>
>>> The code intended to use the same code path for JRE as before, but on
>>> second thought, there is no reason not to use Calendar.Builder() even
>>> for JRE. Modified the fix as such.
>>>
>>>> - When building a Calendar with Calendar.Builder, the current time 
>>>> needs
>>>> to be set (.setInstant(System.currentMillis())).
>>>
>>> Fixed.
>>>
>>>> - The usage of term "POSIX locale" in Mac OS sounds strange. POSIX
>>>> locale means C locale...
>>>
>>> Right. But that's not under our control :-)
>>>
>>> Revised webrev is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8008576/webrev.01/
>>>
>>> Naoto
>>>
>>>>
>>>> Otherwise, the change looks good to me.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 3/9/2013 8:45 AM, Naoto Sato wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the changes for the following CR:
>>>>>
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008576
>>>>>
>>>>> Here is the webrev for the changes:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8008576/webrev.00/
>>>>>
>>>>> The gist of the changes is to instantiate a calendar instance using
>>>>> the new Calendar.Builder class that suits the underlying OS's 
>>>>> calendar
>>>>> for the current user's locale.
>>>>>
>>>>> Naoto
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Fri Mar 22 13:23:02 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 22 Mar 2013 13:23:02 -0700
Subject: <i18n dev> [8]Request for review: 7091601: Arabic Locale: can not
 set type of digit in application level
Message-ID: <514CBDA6.3090302@oracle.com>

Hello,

Please review the changes for the following bug:

http://bugs.sun.com/view_bug.do?bug_id=7091601

The idea is to reflect the operating system's settings in the HOST 
locale provider adapter. Also fixed a bug in MacOSX code conversion for 
the zero digit. The webrev is available here:

http://cr.openjdk.java.net/~naoto/7091601/webrev.00/

Naoto

From michael.fang at oracle.com  Fri Mar 22 16:18:56 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Fri, 22 Mar 2013 16:18:56 -0700
Subject: <i18n dev> [8]Request for review: 8010521: jdk8 l10n resource file
 translation update
In-Reply-To: <512D554B.2040205@oracle.com>
References: <512D554B.2040205@oracle.com>
Message-ID: <514CE6E0.7030400@oracle.com>

Hello,

Please help to review the changes for the following CR:
http://bugs.sun.com/view_bug.do?bug_id=8010521

A list of English resource files are sent to translation group for 
translation update periodically that's why these l10n resource files 
have been updated.

You do not need to review the translation content at this time. We just 
need to make sure they do not break the build (which has been ensured 
with full test builds). Follow up i18n/l10n testing will be performed in 
promotion builds and i18n/l10n bugs will be reported and addressed.

The webrev is available here:
http://cr.openjdk.java.net/~mfang/8010521/

thanks,

-michael


From naoto.sato at oracle.com  Mon Mar 25 11:37:13 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 25 Mar 2013 11:37:13 -0700
Subject: <i18n dev> [8]Request for review: 8010521: jdk8 l10n resource
 file translation update
In-Reply-To: <514CE6E0.7030400@oracle.com>
References: <512D554B.2040205@oracle.com> <514CE6E0.7030400@oracle.com>
Message-ID: <51509959.7040400@oracle.com>

Hi Michael,

I haven't looked into the actual translations, but here are my comments 
to your changes. All are in the jdk repository:

- 
src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties: 
There seems to be no change in this file.

- 
src/share/classes/sun/tools/jconsole/resources/messages_[ja|zh_CN].properties: 
On the other hand, in these files, there are too many changes that 
looked the same. Are these correct?

- src/share/classes/sun/util/logging/resources/logging_*.properties: The 
comment says, "# The following ALL CAPS words should be translated." But 
some of them are translated, and others aren't. Need to figure out the 
correct way.

Naoto

On 3/22/13 4:18 PM, Michael Fang wrote:
> Hello,
>
> Please help to review the changes for the following CR:
> http://bugs.sun.com/view_bug.do?bug_id=8010521
>
> A list of English resource files are sent to translation group for
> translation update periodically that's why these l10n resource files
> have been updated.
>
> You do not need to review the translation content at this time. We just
> need to make sure they do not break the build (which has been ensured
> with full test builds). Follow up i18n/l10n testing will be performed in
> promotion builds and i18n/l10n bugs will be reported and addressed.
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8010521/
>
> thanks,
>
> -michael
>


From michael.fang at oracle.com  Mon Mar 25 12:50:12 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 25 Mar 2013 12:50:12 -0700
Subject: <i18n dev> [8]Request for review: 8010521: jdk8 l10n resource
 file translation update
In-Reply-To: <51509959.7040400@oracle.com>
References: <512D554B.2040205@oracle.com> <514CE6E0.7030400@oracle.com>
	<51509959.7040400@oracle.com>
Message-ID: <5150AA74.3050102@oracle.com>

Hi Naoto,

Thank you so much for your review. Please see my comments inline below.

thanks,

-michael

On 13?03?25? 11:37 ??, Naoto Sato wrote:
> Hi Michael,
>
> I haven't looked into the actual translations, but here are my 
> comments to your changes. All are in the jdk repository:
>
> - 
> src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties: 
> There seems to be no change in this file.
I looked at hg history of the English synth.properties file. There 
wasn't any changes to the English resource file. The l10n file changes 
are all related to translation corrections from translation team and 
there wasn't any correction for zh_TW.
>
> - 
> src/share/classes/sun/tools/jconsole/resources/messages_[ja|zh_CN].properties: 
> On the other hand, in these files, there are too many changes that 
> looked the same. Are these correct?
There also wasn't English file change for messages.properties. The diffs 
are related to changing the case of the letters. Ex:
-ONE_DAY=\ 1\u65e5
+ONE_DAY=\ 1\u65E5

The translation team returns the translation with upper case letters in 
the \uxxxx notation. But because the previous version of l10n files were 
manually edited by dev team to fix 7017818, the casing is most of the 
lines are different.

>
> - src/share/classes/sun/util/logging/resources/logging_*.properties: 
> The comment says, "# The following ALL CAPS words should be 
> translated." But some of them are translated, and others aren't. Need 
> to figure out the correct way.
I will work with translation team offline on this. The translation team 
said they would refer to the comments, but technically, they have a rule 
about *not* translating words that are made out of all capital letters. 
I believe their automated translation tool have automatically filtered 
out those resources during translation process.

Another option is to ask dev team not to use these ALL CAPS words in 
order to meet the t13y (translatability) requirements.
>
> Naoto
>
> On 3/22/13 4:18 PM, Michael Fang wrote:
>> Hello,
>>
>> Please help to review the changes for the following CR:
>> http://bugs.sun.com/view_bug.do?bug_id=8010521
>>
>> A list of English resource files are sent to translation group for
>> translation update periodically that's why these l10n resource files
>> have been updated.
>>
>> You do not need to review the translation content at this time. We just
>> need to make sure they do not break the build (which has been ensured
>> with full test builds). Follow up i18n/l10n testing will be performed in
>> promotion builds and i18n/l10n bugs will be reported and addressed.
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/8010521/
>>
>> thanks,
>>
>> -michael
>>
>


From naoto.sato at oracle.com  Mon Mar 25 13:03:20 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 25 Mar 2013 13:03:20 -0700
Subject: <i18n dev> [8]Request for review: 8010521: jdk8 l10n resource
 file translation update
In-Reply-To: <5150AA74.3050102@oracle.com>
References: <512D554B.2040205@oracle.com> <514CE6E0.7030400@oracle.com>
	<51509959.7040400@oracle.com> <5150AA74.3050102@oracle.com>
Message-ID: <5150AD88.2070808@oracle.com>

On 3/25/13 12:50 PM, Michael Fang wrote:
> Hi Naoto,
>
> Thank you so much for your review. Please see my comments inline below.
>
> thanks,
>
> -michael
>
> On 13?03?25? 11:37 ??, Naoto Sato wrote:
>> Hi Michael,
>>
>> I haven't looked into the actual translations, but here are my
>> comments to your changes. All are in the jdk repository:
>>
>> -
>> src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties:
>> There seems to be no change in this file.
> I looked at hg history of the English synth.properties file. There
> wasn't any changes to the English resource file. The l10n file changes
> are all related to translation corrections from translation team and
> there wasn't any correction for zh_TW.

OK, then can you please remove this file from the changeset?

>>
>> -
>> src/share/classes/sun/tools/jconsole/resources/messages_[ja|zh_CN].properties:
>> On the other hand, in these files, there are too many changes that
>> looked the same. Are these correct?
> There also wasn't English file change for messages.properties. The diffs
> are related to changing the case of the letters. Ex:
> -ONE_DAY=\ 1\u65e5
> +ONE_DAY=\ 1\u65E5
>
> The translation team returns the translation with upper case letters in
> the \uxxxx notation. But because the previous version of l10n files were
> manually edited by dev team to fix 7017818, the casing is most of the
> lines are different.

Got it.

>
>>
>> - src/share/classes/sun/util/logging/resources/logging_*.properties:
>> The comment says, "# The following ALL CAPS words should be
>> translated." But some of them are translated, and others aren't. Need
>> to figure out the correct way.
> I will work with translation team offline on this. The translation team
> said they would refer to the comments, but technically, they have a rule
> about *not* translating words that are made out of all capital letters.
> I believe their automated translation tool have automatically filtered
> out those resources during translation process.
>
> Another option is to ask dev team not to use these ALL CAPS words in
> order to meet the t13y (translatability) requirements.

I think the rule of the translation team would only apply to plain 
English (or whatever language) sentences. In this case, they are log 
levels defined here 
(http://download.java.net/jdk8/docs/api/java/util/logging/Level.html), 
so both options of applying all caps rule or change them into lower 
cases would be wrong to me.

Anyway, if you need to integrate this changeset to keep the dead line, I 
am fine with the current one (without the empty change above). Please 
file a bug for the above logging issue for following up.

Naoto

>>
>> Naoto
>>
>> On 3/22/13 4:18 PM, Michael Fang wrote:
>>> Hello,
>>>
>>> Please help to review the changes for the following CR:
>>> http://bugs.sun.com/view_bug.do?bug_id=8010521
>>>
>>> A list of English resource files are sent to translation group for
>>> translation update periodically that's why these l10n resource files
>>> have been updated.
>>>
>>> You do not need to review the translation content at this time. We just
>>> need to make sure they do not break the build (which has been ensured
>>> with full test builds). Follow up i18n/l10n testing will be performed in
>>> promotion builds and i18n/l10n bugs will be reported and addressed.
>>>
>>> The webrev is available here:
>>> http://cr.openjdk.java.net/~mfang/8010521/
>>>
>>> thanks,
>>>
>>> -michael
>>>
>>
>


From michael.fang at oracle.com  Mon Mar 25 14:29:12 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 25 Mar 2013 14:29:12 -0700
Subject: <i18n dev> [8]Request for review: 8010521: jdk8 l10n resource
 file translation update
In-Reply-To: <5150AD88.2070808@oracle.com>
References: <512D554B.2040205@oracle.com> <514CE6E0.7030400@oracle.com>
	<51509959.7040400@oracle.com> <5150AA74.3050102@oracle.com>
	<5150AD88.2070808@oracle.com>
Message-ID: <5150C1A8.2040901@oracle.com>

Hi Naoto,

After further review, synth_zh_TW.properties webrev was correct.
45 lines changed: 0 ins; 0 del; 45 mod; 0 unchg

The dev team updated all synth_*.properties files to fix bug 7093156 and 
they saved the files with ^M windows new line characters. But the files 
delivered from translation team do not have these. So, all 45 lines were 
changed, but there were no content changes.

For logging_*.properties, I have reverted back the files to previous 
version currently in the repository to avoid the regression. I will then 
work with translation team offline about these files.

I have uploaded updated webrev: 
http://cr.openjdk.java.net/~mfang/8010521/webrev.jdk.01/
thanks,

-michael


On 13?03?25? 01:03 ??, Naoto Sato wrote:
> On 3/25/13 12:50 PM, Michael Fang wrote:
>> Hi Naoto,
>>
>> Thank you so much for your review. Please see my comments inline below.
>>
>> thanks,
>>
>> -michael
>>
>> On 13?03?25? 11:37 ??, Naoto Sato wrote:
>>> Hi Michael,
>>>
>>> I haven't looked into the actual translations, but here are my
>>> comments to your changes. All are in the jdk repository:
>>>
>>> -
>>> src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties: 
>>>
>>> There seems to be no change in this file.
>> I looked at hg history of the English synth.properties file. There
>> wasn't any changes to the English resource file. The l10n file changes
>> are all related to translation corrections from translation team and
>> there wasn't any correction for zh_TW.
>
> OK, then can you please remove this file from the changeset?
>
>>>
>>> -
>>> src/share/classes/sun/tools/jconsole/resources/messages_[ja|zh_CN].properties: 
>>>
>>> On the other hand, in these files, there are too many changes that
>>> looked the same. Are these correct?
>> There also wasn't English file change for messages.properties. The diffs
>> are related to changing the case of the letters. Ex:
>> -ONE_DAY=\ 1\u65e5
>> +ONE_DAY=\ 1\u65E5
>>
>> The translation team returns the translation with upper case letters in
>> the \uxxxx notation. But because the previous version of l10n files were
>> manually edited by dev team to fix 7017818, the casing is most of the
>> lines are different.
>
> Got it.
>
>>
>>>
>>> - src/share/classes/sun/util/logging/resources/logging_*.properties:
>>> The comment says, "# The following ALL CAPS words should be
>>> translated." But some of them are translated, and others aren't. Need
>>> to figure out the correct way.
>> I will work with translation team offline on this. The translation team
>> said they would refer to the comments, but technically, they have a rule
>> about *not* translating words that are made out of all capital letters.
>> I believe their automated translation tool have automatically filtered
>> out those resources during translation process.
>>
>> Another option is to ask dev team not to use these ALL CAPS words in
>> order to meet the t13y (translatability) requirements.
>
> I think the rule of the translation team would only apply to plain 
> English (or whatever language) sentences. In this case, they are log 
> levels defined here 
> (http://download.java.net/jdk8/docs/api/java/util/logging/Level.html), 
> so both options of applying all caps rule or change them into lower 
> cases would be wrong to me.
>
> Anyway, if you need to integrate this changeset to keep the dead line, 
> I am fine with the current one (without the empty change above). 
> Please file a bug for the above logging issue for following up.
>
> Naoto
>
>>>
>>> Naoto
>>>
>>> On 3/22/13 4:18 PM, Michael Fang wrote:
>>>> Hello,
>>>>
>>>> Please help to review the changes for the following CR:
>>>> http://bugs.sun.com/view_bug.do?bug_id=8010521
>>>>
>>>> A list of English resource files are sent to translation group for
>>>> translation update periodically that's why these l10n resource files
>>>> have been updated.
>>>>
>>>> You do not need to review the translation content at this time. We 
>>>> just
>>>> need to make sure they do not break the build (which has been ensured
>>>> with full test builds). Follow up i18n/l10n testing will be 
>>>> performed in
>>>> promotion builds and i18n/l10n bugs will be reported and addressed.
>>>>
>>>> The webrev is available here:
>>>> http://cr.openjdk.java.net/~mfang/8010521/
>>>>
>>>> thanks,
>>>>
>>>> -michael
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Mon Mar 25 14:41:44 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 25 Mar 2013 14:41:44 -0700
Subject: <i18n dev> [8]Request for review: 8010521: jdk8 l10n resource
 file translation update
In-Reply-To: <5150C1A8.2040901@oracle.com>
References: <512D554B.2040205@oracle.com> <514CE6E0.7030400@oracle.com>
	<51509959.7040400@oracle.com> <5150AA74.3050102@oracle.com>
	<5150AD88.2070808@oracle.com> <5150C1A8.2040901@oracle.com>
Message-ID: <5150C498.4050505@oracle.com>

On 3/25/13 2:29 PM, Michael Fang wrote:
> Hi Naoto,
>
> After further review, synth_zh_TW.properties webrev was correct.
> 45 lines changed: 0 ins; 0 del; 45 mod; 0 unchg
>
> The dev team updated all synth_*.properties files to fix bug 7093156 and
> they saved the files with ^M windows new line characters. But the files
> delivered from translation team do not have these. So, all 45 lines were
> changed, but there were no content changes.

Hmm, I wouldn't say it's "correct" from the repository point of view, as 
^M's are prohibited in OpenJDK source files 
(http://openjdk.java.net/projects/code-tools/jcheck/). Can you please 
file a bug against the English properties file?

>
> For logging_*.properties, I have reverted back the files to previous
> version currently in the repository to avoid the regression. I will then
> work with translation team offline about these files.

Great! Thank you for the follow-up.

>
> I have uploaded updated webrev:
> http://cr.openjdk.java.net/~mfang/8010521/webrev.jdk.01/

Looks good to me now.

Naoto

> thanks,
>
> -michael
>
>
> On 13?03?25? 01:03 ??, Naoto Sato wrote:
>> On 3/25/13 12:50 PM, Michael Fang wrote:
>>> Hi Naoto,
>>>
>>> Thank you so much for your review. Please see my comments inline below.
>>>
>>> thanks,
>>>
>>> -michael
>>>
>>> On 13?03?25? 11:37 ??, Naoto Sato wrote:
>>>> Hi Michael,
>>>>
>>>> I haven't looked into the actual translations, but here are my
>>>> comments to your changes. All are in the jdk repository:
>>>>
>>>> -
>>>> src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties:
>>>>
>>>> There seems to be no change in this file.
>>> I looked at hg history of the English synth.properties file. There
>>> wasn't any changes to the English resource file. The l10n file changes
>>> are all related to translation corrections from translation team and
>>> there wasn't any correction for zh_TW.
>>
>> OK, then can you please remove this file from the changeset?
>>
>>>>
>>>> -
>>>> src/share/classes/sun/tools/jconsole/resources/messages_[ja|zh_CN].properties:
>>>>
>>>> On the other hand, in these files, there are too many changes that
>>>> looked the same. Are these correct?
>>> There also wasn't English file change for messages.properties. The diffs
>>> are related to changing the case of the letters. Ex:
>>> -ONE_DAY=\ 1\u65e5
>>> +ONE_DAY=\ 1\u65E5
>>>
>>> The translation team returns the translation with upper case letters in
>>> the \uxxxx notation. But because the previous version of l10n files were
>>> manually edited by dev team to fix 7017818, the casing is most of the
>>> lines are different.
>>
>> Got it.
>>
>>>
>>>>
>>>> - src/share/classes/sun/util/logging/resources/logging_*.properties:
>>>> The comment says, "# The following ALL CAPS words should be
>>>> translated." But some of them are translated, and others aren't. Need
>>>> to figure out the correct way.
>>> I will work with translation team offline on this. The translation team
>>> said they would refer to the comments, but technically, they have a rule
>>> about *not* translating words that are made out of all capital letters.
>>> I believe their automated translation tool have automatically filtered
>>> out those resources during translation process.
>>>
>>> Another option is to ask dev team not to use these ALL CAPS words in
>>> order to meet the t13y (translatability) requirements.
>>
>> I think the rule of the translation team would only apply to plain
>> English (or whatever language) sentences. In this case, they are log
>> levels defined here
>> (http://download.java.net/jdk8/docs/api/java/util/logging/Level.html),
>> so both options of applying all caps rule or change them into lower
>> cases would be wrong to me.
>>
>> Anyway, if you need to integrate this changeset to keep the dead line,
>> I am fine with the current one (without the empty change above).
>> Please file a bug for the above logging issue for following up.
>>
>> Naoto
>>
>>>>
>>>> Naoto
>>>>
>>>> On 3/22/13 4:18 PM, Michael Fang wrote:
>>>>> Hello,
>>>>>
>>>>> Please help to review the changes for the following CR:
>>>>> http://bugs.sun.com/view_bug.do?bug_id=8010521
>>>>>
>>>>> A list of English resource files are sent to translation group for
>>>>> translation update periodically that's why these l10n resource files
>>>>> have been updated.
>>>>>
>>>>> You do not need to review the translation content at this time. We
>>>>> just
>>>>> need to make sure they do not break the build (which has been ensured
>>>>> with full test builds). Follow up i18n/l10n testing will be
>>>>> performed in
>>>>> promotion builds and i18n/l10n bugs will be reported and addressed.
>>>>>
>>>>> The webrev is available here:
>>>>> http://cr.openjdk.java.net/~mfang/8010521/
>>>>>
>>>>> thanks,
>>>>>
>>>>> -michael
>>>>>
>>>>
>>>
>>
>


From michael.fang at oracle.com  Mon Mar 25 16:30:02 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 25 Mar 2013 16:30:02 -0700
Subject: <i18n dev> [8]Request for review: 8010521: jdk8 l10n resource
 file translation update
In-Reply-To: <5150C498.4050505@oracle.com>
References: <512D554B.2040205@oracle.com> <514CE6E0.7030400@oracle.com>
	<51509959.7040400@oracle.com> <5150AA74.3050102@oracle.com>
	<5150AD88.2070808@oracle.com> <5150C1A8.2040901@oracle.com>
	<5150C498.4050505@oracle.com>
Message-ID: <5150DDFA.8070609@oracle.com>

Thanks Naoto for the review.

JDK-8010782 <https://jbs.oracle.com/bugs/browse/JDK-8010782> has been 
created to track the Windows new line character issue (^M)

thanks,

-michael

On 13?03?25? 02:41 ??, Naoto Sato wrote:
> On 3/25/13 2:29 PM, Michael Fang wrote:
>> Hi Naoto,
>>
>> After further review, synth_zh_TW.properties webrev was correct.
>> 45 lines changed: 0 ins; 0 del; 45 mod; 0 unchg
>>
>> The dev team updated all synth_*.properties files to fix bug 7093156 and
>> they saved the files with ^M windows new line characters. But the files
>> delivered from translation team do not have these. So, all 45 lines were
>> changed, but there were no content changes.
>
> Hmm, I wouldn't say it's "correct" from the repository point of view, 
> as ^M's are prohibited in OpenJDK source files 
> (http://openjdk.java.net/projects/code-tools/jcheck/). Can you please 
> file a bug against the English properties file?
>
>>
>> For logging_*.properties, I have reverted back the files to previous
>> version currently in the repository to avoid the regression. I will then
>> work with translation team offline about these files.
>
> Great! Thank you for the follow-up.
>
>>
>> I have uploaded updated webrev:
>> http://cr.openjdk.java.net/~mfang/8010521/webrev.jdk.01/
>
> Looks good to me now.
>
> Naoto
>
>> thanks,
>>
>> -michael
>>
>>
>> On 13?03?25? 01:03 ??, Naoto Sato wrote:
>>> On 3/25/13 12:50 PM, Michael Fang wrote:
>>>> Hi Naoto,
>>>>
>>>> Thank you so much for your review. Please see my comments inline 
>>>> below.
>>>>
>>>> thanks,
>>>>
>>>> -michael
>>>>
>>>> On 13?03?25? 11:37 ??, Naoto Sato wrote:
>>>>> Hi Michael,
>>>>>
>>>>> I haven't looked into the actual translations, but here are my
>>>>> comments to your changes. All are in the jdk repository:
>>>>>
>>>>> -
>>>>> src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties: 
>>>>>
>>>>>
>>>>> There seems to be no change in this file.
>>>> I looked at hg history of the English synth.properties file. There
>>>> wasn't any changes to the English resource file. The l10n file changes
>>>> are all related to translation corrections from translation team and
>>>> there wasn't any correction for zh_TW.
>>>
>>> OK, then can you please remove this file from the changeset?
>>>
>>>>>
>>>>> -
>>>>> src/share/classes/sun/tools/jconsole/resources/messages_[ja|zh_CN].properties: 
>>>>>
>>>>>
>>>>> On the other hand, in these files, there are too many changes that
>>>>> looked the same. Are these correct?
>>>> There also wasn't English file change for messages.properties. The 
>>>> diffs
>>>> are related to changing the case of the letters. Ex:
>>>> -ONE_DAY=\ 1\u65e5
>>>> +ONE_DAY=\ 1\u65E5
>>>>
>>>> The translation team returns the translation with upper case 
>>>> letters in
>>>> the \uxxxx notation. But because the previous version of l10n files 
>>>> were
>>>> manually edited by dev team to fix 7017818, the casing is most of the
>>>> lines are different.
>>>
>>> Got it.
>>>
>>>>
>>>>>
>>>>> - src/share/classes/sun/util/logging/resources/logging_*.properties:
>>>>> The comment says, "# The following ALL CAPS words should be
>>>>> translated." But some of them are translated, and others aren't. Need
>>>>> to figure out the correct way.
>>>> I will work with translation team offline on this. The translation 
>>>> team
>>>> said they would refer to the comments, but technically, they have a 
>>>> rule
>>>> about *not* translating words that are made out of all capital 
>>>> letters.
>>>> I believe their automated translation tool have automatically filtered
>>>> out those resources during translation process.
>>>>
>>>> Another option is to ask dev team not to use these ALL CAPS words in
>>>> order to meet the t13y (translatability) requirements.
>>>
>>> I think the rule of the translation team would only apply to plain
>>> English (or whatever language) sentences. In this case, they are log
>>> levels defined here
>>> (http://download.java.net/jdk8/docs/api/java/util/logging/Level.html),
>>> so both options of applying all caps rule or change them into lower
>>> cases would be wrong to me.
>>>
>>> Anyway, if you need to integrate this changeset to keep the dead line,
>>> I am fine with the current one (without the empty change above).
>>> Please file a bug for the above logging issue for following up.
>>>
>>> Naoto
>>>
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 3/22/13 4:18 PM, Michael Fang wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please help to review the changes for the following CR:
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8010521
>>>>>>
>>>>>> A list of English resource files are sent to translation group for
>>>>>> translation update periodically that's why these l10n resource files
>>>>>> have been updated.
>>>>>>
>>>>>> You do not need to review the translation content at this time. We
>>>>>> just
>>>>>> need to make sure they do not break the build (which has been 
>>>>>> ensured
>>>>>> with full test builds). Follow up i18n/l10n testing will be
>>>>>> performed in
>>>>>> promotion builds and i18n/l10n bugs will be reported and addressed.
>>>>>>
>>>>>> The webrev is available here:
>>>>>> http://cr.openjdk.java.net/~mfang/8010521/
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> -michael
>>>>>>
>>>>>
>>>>
>>>
>>
>

From masayoshi.okutsu at oracle.com  Thu Mar 28 08:03:37 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 29 Mar 2013 00:03:37 +0900
Subject: <i18n dev> [8]Request for review: 7091601: Arabic Locale: can
 not set type of digit in application level
In-Reply-To: <514CBDA6.3090302@oracle.com>
References: <514CBDA6.3090302@oracle.com>
Message-ID: <51545BC9.8090309@oracle.com>

Additional comments (to the CFStringRef to jchar[] conversion).

- There might be exceptional cases on zero digit handling in CLDR. One 
is that digits aren't sequential in "hanidec" which can't be supported 
with the current java.text classes. Another one is that digits are in a 
reversed order in "nkoo". I don't know if these are applicable to Mac 
OS, but it should be worth checking.

- I noticed that the native getCalendarID returns a jstring, but that 
the Java code appears to except an int.

- createCFLocale() seems to convert a jstring to char* and to 
CFStringRef. I wonder if this can be simplified.

Thanks,
Masayoshi

On 3/23/2013 5:23 AM, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following bug:
>
> http://bugs.sun.com/view_bug.do?bug_id=7091601
>
> The idea is to reflect the operating system's settings in the HOST 
> locale provider adapter. Also fixed a bug in MacOSX code conversion 
> for the zero digit. The webrev is available here:
>
> http://cr.openjdk.java.net/~naoto/7091601/webrev.00/
>
> Naoto


From naoto.sato at oracle.com  Thu Mar 28 10:34:17 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 28 Mar 2013 10:34:17 -0700
Subject: <i18n dev> [8]Request for review: 7091601: Arabic Locale: can
 not set type of digit in application level
In-Reply-To: <514CBDA6.3090302@oracle.com>
References: <514CBDA6.3090302@oracle.com>
Message-ID: <51547F19.4040305@oracle.com>

Updated the changeset according to an internal review (using 
CFStringGetCharacterAtIndex() instead of converting entire string on 
MacOSX). Here is the revised webrev:

http://cr.openjdk.java.net/~naoto/7091601/webrev.01/

Naoto

On 3/22/13 1:23 PM, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following bug:
>
> http://bugs.sun.com/view_bug.do?bug_id=7091601
>
> The idea is to reflect the operating system's settings in the HOST
> locale provider adapter. Also fixed a bug in MacOSX code conversion for
> the zero digit. The webrev is available here:
>
> http://cr.openjdk.java.net/~naoto/7091601/webrev.00/
>
> Naoto


From naoto.sato at oracle.com  Thu Mar 28 12:36:53 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 28 Mar 2013 12:36:53 -0700
Subject: <i18n dev> [8]Request for review: 7091601: Arabic Locale: can
 not set type of digit in application level
In-Reply-To: <51545BC9.8090309@oracle.com>
References: <514CBDA6.3090302@oracle.com> <51545BC9.8090309@oracle.com>
Message-ID: <51549BD5.80107@oracle.com>

Ah, did not see your email before I sent out the revised webrev. Please 
find my comments below:

On 3/28/13 8:03 AM, Masayoshi Okutsu wrote:
> Additional comments (to the CFStringRef to jchar[] conversion).
>
> - There might be exceptional cases on zero digit handling in CLDR. One
> is that digits aren't sequential in "hanidec" which can't be supported
> with the current java.text classes. Another one is that digits are in a
> reversed order in "nkoo". I don't know if these are applicable to Mac
> OS, but it should be worth checking.

I don't find any way to customize numbering system in MacOSX's system 
preference. All the default values are tied to the region in "Language & 
Text" settings panel. So as long as the HOST locale provider adapter is 
concerned, I think it is OK.

>
> - I noticed that the native getCalendarID returns a jstring, but that
> the Java code appears to except an int.

Hmm, the return value is a String object in the java code as well:

     private static native String getCalendarID(String langTag);

Otherwise I don't think it compiles, right?

>
> - createCFLocale() seems to convert a jstring to char* and to
> CFStringRef. I wonder if this can be simplified.

Since jstring is a reference to a Java String object, I think first it 
has to be convert into a C string, then it has to be turned into 
CFStringRef. There may be a direct call in Apple's JavaRuntimeSupport 
library routines, but we don't have any documentation for that.

Naoto

>
> Thanks,
> Masayoshi
>
> On 3/23/2013 5:23 AM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes for the following bug:
>>
>> http://bugs.sun.com/view_bug.do?bug_id=7091601
>>
>> The idea is to reflect the operating system's settings in the HOST
>> locale provider adapter. Also fixed a bug in MacOSX code conversion
>> for the zero digit. The webrev is available here:
>>
>> http://cr.openjdk.java.net/~naoto/7091601/webrev.00/
>>
>> Naoto
>


From sean.coffey at oracle.com  Thu Mar 28 19:25:41 2013
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Thu, 28 Mar 2013 19:25:41 -0700
Subject: <i18n dev> Review request for 8000529 : Regression :
 SimpleDateFormat incorrectly parses dates formatted with Z and z pattern
 letters
Message-ID: <5154FBA5.1080001@oracle.com>

Masayoshi,

this is a JDK 8 review request for an issue we touched on a good while 
back. As suggested by you, fix is to clear ZONE_OFFSET field of the 
calendar being built before attempting to set a DST_OFFSET value. I plan 
to backport to 7u-dev after a few weeks of soak time.

bug report : http://bugs.sun.com/view_bug.do?bug_id=8000529
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8000529.jdk8/

Regards,
Sean.

From masayoshi.okutsu at oracle.com  Thu Mar 28 19:54:04 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 29 Mar 2013 11:54:04 +0900
Subject: <i18n dev> Review request for 8000529 : Regression :
 SimpleDateFormat incorrectly parses dates formatted with Z and z pattern
 letters
In-Reply-To: <5154FBA5.1080001@oracle.com>
References: <5154FBA5.1080001@oracle.com>
Message-ID: <5155024C.6030803@oracle.com>

Looks good to me.

Masayoshi

On 3/29/2013 11:25 AM, Se?n Coffey wrote:
> Masayoshi,
>
> this is a JDK 8 review request for an issue we touched on a good while 
> back. As suggested by you, fix is to clear ZONE_OFFSET field of the 
> calendar being built before attempting to set a DST_OFFSET value. I 
> plan to backport to 7u-dev after a few weeks of soak time.
>
> bug report : http://bugs.sun.com/view_bug.do?bug_id=8000529
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8000529.jdk8/
>
> Regards,
> Sean.


From naoto.sato at oracle.com  Fri Mar 29 14:44:30 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 29 Mar 2013 14:44:30 -0700
Subject: <i18n dev> [8]Request for review: 7091601: Arabic Locale: can
 not set type of digit in application level
In-Reply-To: <51547F19.4040305@oracle.com>
References: <514CBDA6.3090302@oracle.com> <51547F19.4040305@oracle.com>
Message-ID: <51560B3E.1030804@oracle.com>

Revised the macosx portion of the changeset again. Reverted the code 
that obtains CFLocaleRef back to using CFLocaleCopyCurrent(), otherwise 
the user's cusomization would not be reflected. Here is the revised webrev:

http://cr.openjdk.java.net/~naoto/7091601/webrev.02/

Naoto

On 3/28/13 10:34 AM, Naoto Sato wrote:
> Updated the changeset according to an internal review (using
> CFStringGetCharacterAtIndex() instead of converting entire string on
> MacOSX). Here is the revised webrev:
>
> http://cr.openjdk.java.net/~naoto/7091601/webrev.01/
>
> Naoto
>
> On 3/22/13 1:23 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes for the following bug:
>>
>> http://bugs.sun.com/view_bug.do?bug_id=7091601
>>
>> The idea is to reflect the operating system's settings in the HOST
>> locale provider adapter. Also fixed a bug in MacOSX code conversion for
>> the zero digit. The webrev is available here:
>>
>> http://cr.openjdk.java.net/~naoto/7091601/webrev.00/
>>
>> Naoto
>