From dougfelt at google.com  Fri Jan  9 17:40:34 2009
From: dougfelt at google.com (Doug Felt)
Date: Fri, 9 Jan 2009 17:40:34 -0800
Subject: [loc-en-dev] unit tests
Message-ID: <146f39a80901091740w6ab86329qff18a3d366945f6e@mail.gmail.com>

I've started to write some unit tests for the syntax createLocale accepts,
based on Yoshito's writeup.  I think it's a good way to work through the
details so we can understand exactly what is supposed to happen.
I'm thinking about the best way to share this for discussion.  One
possibility is to check the tests in to our repository, so we can all try
them out.  They'll fail a good part of the time, since there's no
implementation (I'm developing something just to flesh this out, but we
might want to get the implementation from somewhere else).  This seems ok to
me as long as the tests and the main repository build.  This makes it easy
for us to update our local copies.

Another way is to pass the patches through this mailing list for discussion
first, and only apply them if people are happy with them.

What do folks think?

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090109/436b0ced/attachment.html 

From srloomis at us.ibm.com  Fri Jan  9 18:01:10 2009
From: srloomis at us.ibm.com (Steven R Loomis)
Date: Fri, 9 Jan 2009 18:01:10 -0800
Subject: [loc-en-dev] unit tests
In-Reply-To: <146f39a80901091740w6ab86329qff18a3d366945f6e@mail.gmail.com>
References: <146f39a80901091740w6ab86329qff18a3d366945f6e@mail.gmail.com>
Message-ID: <OFB6B41F03.89F4E814-ON8625753A.000A2BAF-8825753A.000AE727@us.ibm.com>

Hi Doug,
 I think it would be fine to check them into the repository first and just
paste the link here to fetch them over HTTP or mercurial. Something
buildable would be great to get things going.

Steven


Steven ?. Loomis                                Technical Lead (C/C++),
International Components for Unicode


                                                                                                                                     
  From:       Doug Felt <dougfelt at google.com>                                                                                        
                                                                                                                                     
  To:         locale-enhancement-dev at openjdk.java.net                                                                                
                                                                                                                                     
  Date:       01/09/2009 05:41 PM                                                                                                    
                                                                                                                                     
  Subject:    [loc-en-dev] unit tests                                                                                                
                                                                                                                                     





I've started to write some unit tests for the syntax createLocale accepts,
based on Yoshito's writeup.  I think it's a good way to work through the
details so we can understand exactly what is supposed to happen.

I'm thinking about the best way to share this for discussion.  One
possibility is to check the tests in to our repository, so we can all try
them out.  They'll fail a good part of the time, since there's no
implementation (I'm developing something just to flesh this out, but we
might want to get the implementation from somewhere else).  This seems ok
to me as long as the tests and the main repository build.  This makes it
easy for us to update our local copies.

Another way is to pass the patches through this mailing list for discussion
first, and only apply them if people are happy with them.

What do folks think?

Doug

From Naoto.Sato at Sun.COM  Mon Jan 12 12:19:40 2009
From: Naoto.Sato at Sun.COM (Naoto Sato)
Date: Mon, 12 Jan 2009 12:19:40 -0800
Subject: [loc-en-dev] unit tests
In-Reply-To: <OFB6B41F03.89F4E814-ON8625753A.000A2BAF-8825753A.000AE727@us.ibm.com>
References: <146f39a80901091740w6ab86329qff18a3d366945f6e@mail.gmail.com>
	<OFB6B41F03.89F4E814-ON8625753A.000A2BAF-8825753A.000AE727@us.ibm.com>
Message-ID: <496BA5DC.1080008@Sun.COM>

I agree.  As long as the repository can successfully be built, I think 
that would be fine.

Naoto

Steven R Loomis wrote:
> Hi Doug,
>  I think it would be fine to check them into the repository first and just
> paste the link here to fetch them over HTTP or mercurial. Something
> buildable would be great to get things going.
> 
> Steven
> 
> 
> Steven ?. Loomis                                Technical Lead (C/C++),
> International Components for Unicode
> 
> 
>                                                                                                                                      
>   From:       Doug Felt <dougfelt at google.com>                                                                                        
>                                                                                                                                      
>   To:         locale-enhancement-dev at openjdk.java.net                                                                                
>                                                                                                                                      
>   Date:       01/09/2009 05:41 PM                                                                                                    
>                                                                                                                                      
>   Subject:    [loc-en-dev] unit tests                                                                                                
>                                                                                                                                      
> 
> 
> 
> 
> 
> I've started to write some unit tests for the syntax createLocale accepts,
> based on Yoshito's writeup.  I think it's a good way to work through the
> details so we can understand exactly what is supposed to happen.
> 
> I'm thinking about the best way to share this for discussion.  One
> possibility is to check the tests in to our repository, so we can all try
> them out.  They'll fail a good part of the time, since there's no
> implementation (I'm developing something just to flesh this out, but we
> might want to get the implementation from somewhere else).  This seems ok
> to me as long as the tests and the main repository build.  This makes it
> easy for us to update our local copies.
> 
> Another way is to pass the patches through this mailing list for discussion
> first, and only apply them if people are happy with them.
> 
> What do folks think?
> 
> Doug


-- 
Naoto Sato


From y.umaoka at gmail.com  Tue Jan 13 19:24:18 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 14 Jan 2009 03:24:18 +0000
Subject: [loc-en-dev] =?windows-1252?q?=5BInvitation=5D_OpenJDK_Locale_Enh?=
	=?windows-1252?q?ancement_Project_Bi-Weely_Meeting_=40_Tue_Jan_20_?=
	=?windows-1252?q?7=3A30pm_=96_8pm_=28locale-enhancement-dev=40open?=
	=?windows-1252?q?jdk=2Ejava=2Enet=29?=
Message-ID: <0016361e87f00eabd1046068e07b@google.com>

locale-enhancement-dev at openjdk.java.net, you are invited to

Title: OpenJDK Locale Enhancement Project Bi-Weely Meeting
Time: Tue Jan 20 7:30pm ? 8pm (Timezone: Eastern Time)
Where: Teleconference
Calendar: locale-enhancement-dev at openjdk.java.net
Owner/Creator: y.umaoka at gmail.com

Description: Toll free from the US and Canada: (877)421-0033
International dialing: +1(770)615-1250

Toll free from Japan (KDD): 00531-11-3180
Toll free from Japan (Cable&Wireless): 0066-33-801263
Toll free from Japan (Softbank): 0044-22-112668
Toll free from Japan (NTT): 0034-800-900155

Other country dial-ins available on request

Passcode: 662122#

Meeting agenda page:  
http://sites.google.com/site/openjdklocale/meeting-agenda

You can view this event at  
http://www.google.com/calendar/event?action=VIEW&eid=b21uaDB0aXVrNTV1NHRpaTNlNWk1dmw0dTQgbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tY2I0MjQ2MTMwNjU1NGVjNzUyNzAwODg5YjgzOTMyNmQ2M2I1NjY0OA&ctz=America%2FNew_York&hl=en



You are receiving this courtesy email at the account  
locale-enhancement-dev at openjdk.java.net because you are an attendee of this  
event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
http://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/b6e2c2bb/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1581 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/b6e2c2bb/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1616 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/b6e2c2bb/attachment-0001.bin 

From y.umaoka at gmail.com  Tue Jan 13 19:26:51 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 14 Jan 2009 03:26:51 +0000
Subject: [loc-en-dev] =?windows-1252?q?=5BInvitation=5D_OpenJDK_Locale_Enh?=
	=?windows-1252?q?ancement_Project_Bi-Weely_Meeting_=40_Tue_Feb_3_7?=
	=?windows-1252?q?=3A30pm_=96_8pm_=28locale-enhancement-dev=40openj?=
	=?windows-1252?q?dk=2Ejava=2Enet=29?=
Message-ID: <000e0cd402ac237860046068e9e7@google.com>

locale-enhancement-dev at openjdk.java.net, you are invited to

Title: OpenJDK Locale Enhancement Project Bi-Weely Meeting
Time: Tue Feb 3 7:30pm ? 8pm (Timezone: Eastern Time)
Where: Teleconference
Calendar: locale-enhancement-dev at openjdk.java.net
Owner/Creator: y.umaoka at gmail.com

Description: Toll free from the US and Canada: (877)421-0033
International dialing: +1(770)615-1250

Toll free from Japan (KDD): 00531-11-3180
Toll free from Japan (Cable&Wireless): 0066-33-801263
Toll free from Japan (Softbank): 0044-22-112668
Toll free from Japan (NTT): 0034-800-900155

Other country dial-ins available on request

Passcode: 662122#

Meeting agenda page:  
http://sites.google.com/site/openjdklocale/meeting-agenda

You can view this event at  
http://www.google.com/calendar/event?action=VIEW&eid=YmJyYjc4bXY2cmswdWgyMnBjdTFrMnA3YzggbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tOGM0OGYwNzg1NDM5ZjFmZDE2MmRmNDIwM2M5ZWUyOTVhMTA4YWJiOA&ctz=America%2FNew_York&hl=en



You are receiving this courtesy email at the account  
locale-enhancement-dev at openjdk.java.net because you are an attendee of this  
event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
http://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/8e49934e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1581 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/8e49934e/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1616 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/8e49934e/attachment-0001.bin 

From y.umaoka at gmail.com  Tue Jan 13 19:28:08 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 14 Jan 2009 03:28:08 +0000
Subject: [loc-en-dev] =?windows-1252?q?=5BInvitation=5D_OpenJDK_Locale_Enh?=
	=?windows-1252?q?ancement_Project_Bi-Weely_Meeting_=40_Tue_Feb_17_?=
	=?windows-1252?q?7=3A30pm_=96_8pm_=28locale-enhancement-dev=40open?=
	=?windows-1252?q?jdk=2Ejava=2Enet=29?=
Message-ID: <000e0cd4cd76c509c8046068ed2a@google.com>

locale-enhancement-dev at openjdk.java.net, you are invited to

Title: OpenJDK Locale Enhancement Project Bi-Weely Meeting
Time: Tue Feb 17 7:30pm ? 8pm (Timezone: Eastern Time)
Where: Teleconference
Calendar: locale-enhancement-dev at openjdk.java.net
Owner/Creator: y.umaoka at gmail.com

Description: Toll free from the US and Canada: (877)421-0033
International dialing: +1(770)615-1250

Toll free from Japan (KDD): 00531-11-3180
Toll free from Japan (Cable&Wireless): 0066-33-801263
Toll free from Japan (Softbank): 0044-22-112668
Toll free from Japan (NTT): 0034-800-900155

Other country dial-ins available on request

Passcode: 662122#

Meeting agenda page:  
http://sites.google.com/site/openjdklocale/meeting-agenda

You can view this event at  
http://www.google.com/calendar/event?action=VIEW&eid=bnBrNzFtamV2Z2ZmZXRxNnQ0aTRncnRybjggbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tYzc5ZmQxMzdjM2Y3ZTNlOGQ3ZDJkZjgyNDNjNDljY2NlZDMwZDNkMg&ctz=America%2FNew_York&hl=en



You are receiving this courtesy email at the account  
locale-enhancement-dev at openjdk.java.net because you are an attendee of this  
event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
http://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/0d8ce9ac/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1581 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/0d8ce9ac/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1616 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/0d8ce9ac/attachment-0001.bin 

From y.umaoka at gmail.com  Tue Jan 13 19:28:57 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 14 Jan 2009 03:28:57 +0000
Subject: [loc-en-dev] =?windows-1252?q?=5BInvitation=5D_OpenJDK_Locale_Enh?=
	=?windows-1252?q?ancement_Project_Bi-Weely_Meeting_=40_Tue_Mar_3_7?=
	=?windows-1252?q?=3A30pm_=96_8pm_=28locale-enhancement-dev=40openj?=
	=?windows-1252?q?dk=2Ejava=2Enet=29?=
Message-ID: <0016e64f90e8b0a507046068f024@google.com>

locale-enhancement-dev at openjdk.java.net, you are invited to

Title: OpenJDK Locale Enhancement Project Bi-Weely Meeting
Time: Tue Mar 3 7:30pm ? 8pm (Timezone: Eastern Time)
Where: Teleconference
Calendar: locale-enhancement-dev at openjdk.java.net
Owner/Creator: y.umaoka at gmail.com

Description: Toll free from the US and Canada: (877)421-0033
International dialing: +1(770)615-1250

Toll free from Japan (KDD): 00531-11-3180
Toll free from Japan (Cable&Wireless): 0066-33-801263
Toll free from Japan (Softbank): 0044-22-112668
Toll free from Japan (NTT): 0034-800-900155

Other country dial-ins available on request

Passcode: 662122#

Meeting agenda page:  
http://sites.google.com/site/openjdklocale/meeting-agenda

You can view this event at  
http://www.google.com/calendar/event?action=VIEW&eid=MmQ1cmF2aWtoMGlwZGJucjdyM2doMWpxdGcgbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tZWM3NTYwN2MwOTFhNjU4ZTQxOGI2MmM4MjZlZjlkNjRjMDA3OThjOA&ctz=America%2FNew_York&hl=en



You are receiving this courtesy email at the account  
locale-enhancement-dev at openjdk.java.net because you are an attendee of this  
event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
http://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/bd6f43a1/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1581 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/bd6f43a1/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1616 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/bd6f43a1/attachment-0001.bin 

From y.umaoka at gmail.com  Tue Jan 13 19:31:34 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 14 Jan 2009 03:31:34 +0000
Subject: [loc-en-dev] =?windows-1252?q?=5BInvitation=5D_OpenJDK_Locale_Enh?=
	=?windows-1252?q?ancement_Project_Bi-Weely_Meeting_=40_Tue_Mar_17_?=
	=?windows-1252?q?7=3A30pm_=96_8pm_=28locale-enhancement-dev=40open?=
	=?windows-1252?q?jdk=2Ejava=2Enet=29?=
Message-ID: <001636163d190b59b9046068facf@google.com>

locale-enhancement-dev at openjdk.java.net, you are invited to

Title: OpenJDK Locale Enhancement Project Bi-Weely Meeting
Time: Tue Mar 17 7:30pm ? 8pm (Timezone: Eastern Time)
Where: Teleconference
Calendar: locale-enhancement-dev at openjdk.java.net
Owner/Creator: y.umaoka at gmail.com

Description: Toll free from the US and Canada: (877)421-0033
International dialing: +1(770)615-1250

Toll free from Japan (KDD): 00531-11-3180
Toll free from Japan (Cable&Wireless): 0066-33-801263
Toll free from Japan (Softbank): 0044-22-112668
Toll free from Japan (NTT): 0034-800-900155

Other country dial-ins available on request

Passcode: 662122#

Meeting agenda page:  
http://sites.google.com/site/openjdklocale/meeting-agenda

You can view this event at  
http://www.google.com/calendar/event?action=VIEW&eid=bjAzbjVrbTJyZDh1YzQzYjZnY2RqdmZnY28gbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tZmRmMWJjMGJiOGMzZjQ5MTc5NWMzNWNiMGQwYmJiN2RkOTc3YTk2MA&ctz=America%2FNew_York&hl=en



You are receiving this courtesy email at the account  
locale-enhancement-dev at openjdk.java.net because you are an attendee of this  
event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
http://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/5fff1935/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1581 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/5fff1935/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1616 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/5fff1935/attachment-0001.bin 

From y.umaoka at gmail.com  Tue Jan 13 19:32:10 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 14 Jan 2009 03:32:10 +0000
Subject: [loc-en-dev] =?windows-1252?q?=5BInvitation=5D_OpenJDK_Locale_Enh?=
	=?windows-1252?q?ancement_Project_Bi-Weely_Meeting_=40_Tue_Mar_31_?=
	=?windows-1252?q?7=3A30pm_=96_8pm_=28locale-enhancement-dev=40open?=
	=?windows-1252?q?jdk=2Ejava=2Enet=29?=
Message-ID: <001636283736289b45046068fca2@google.com>

locale-enhancement-dev at openjdk.java.net, you are invited to

Title: OpenJDK Locale Enhancement Project Bi-Weely Meeting
Time: Tue Mar 31 7:30pm ? 8pm (Timezone: Eastern Time)
Where: Teleconference
Calendar: locale-enhancement-dev at openjdk.java.net
Owner/Creator: y.umaoka at gmail.com

Description: Toll free from the US and Canada: (877)421-0033
International dialing: +1(770)615-1250

Toll free from Japan (KDD): 00531-11-3180
Toll free from Japan (Cable&Wireless): 0066-33-801263
Toll free from Japan (Softbank): 0044-22-112668
Toll free from Japan (NTT): 0034-800-900155

Other country dial-ins available on request

Passcode: 662122#

Meeting agenda page:  
http://sites.google.com/site/openjdklocale/meeting-agenda

You can view this event at  
http://www.google.com/calendar/event?action=VIEW&eid=MnNmcGJqYmY2bTl1dmxrYzFzaWtwc29vdDggbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tODA3NjcyMjk4NTMyMDgzZWQzM2Y1MWQ5NDQ2NjFjODcwNWQxY2JlYg&ctz=America%2FNew_York&hl=en



You are receiving this courtesy email at the account  
locale-enhancement-dev at openjdk.java.net because you are an attendee of this  
event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
http://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/dd95a14b/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1581 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/dd95a14b/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1616 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/dd95a14b/attachment-0001.bin 

From y.umaoka at gmail.com  Tue Jan 13 19:33:02 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 14 Jan 2009 03:33:02 +0000
Subject: [loc-en-dev] =?windows-1252?q?=5BInvitation=5D_OpenJDK_Locale_Enh?=
	=?windows-1252?q?ancement_Project_Bi-Weely_Meeting_=40_Tue_Apr_14_?=
	=?windows-1252?q?7=3A30pm_=96_8pm_=28locale-enhancement-dev=40open?=
	=?windows-1252?q?jdk=2Ejava=2Enet=29?=
Message-ID: <00151750ee3847a0fa046068ff6f@google.com>

locale-enhancement-dev at openjdk.java.net, you are invited to

Title: OpenJDK Locale Enhancement Project Bi-Weely Meeting
Time: Tue Apr 14 7:30pm ? 8pm (Timezone: Eastern Time)
Where: Teleconference
Calendar: locale-enhancement-dev at openjdk.java.net
Owner/Creator: y.umaoka at gmail.com

Description: Toll free from the US and Canada: (877)421-0033
International dialing: +1(770)615-1250

Toll free from Japan (KDD): 00531-11-3180
Toll free from Japan (Cable&Wireless): 0066-33-801263
Toll free from Japan (Softbank): 0044-22-112668
Toll free from Japan (NTT): 0034-800-900155

Other country dial-ins available on request

Passcode: 662122#

Meeting agenda page:  
http://sites.google.com/site/openjdklocale/meeting-agenda

You can view this event at  
http://www.google.com/calendar/event?action=VIEW&eid=dDExcjR0M25zYmExNzNvZTNsbDZ0YTFzczAgbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tZTc5NmI1MzI4MTBkNTlmOTIyYjExNmUyZjA0YzBiNzgxNjViM2Q2Yw&ctz=America%2FNew_York&hl=en



You are receiving this courtesy email at the account  
locale-enhancement-dev at openjdk.java.net because you are an attendee of this  
event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
http://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/cab1abf8/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1581 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/cab1abf8/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1616 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/cab1abf8/attachment-0001.bin 

From y.umaoka at gmail.com  Tue Jan 13 19:33:37 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 14 Jan 2009 03:33:37 +0000
Subject: [loc-en-dev] =?windows-1252?q?=5BInvitation=5D_OpenJDK_Locale_Enh?=
	=?windows-1252?q?ancement_Project_Bi-Weely_Meeting_=40_Tue_Apr_28_?=
	=?windows-1252?q?7=3A30pm_=96_8pm_=28locale-enhancement-dev=40open?=
	=?windows-1252?q?jdk=2Ejava=2Enet=29?=
Message-ID: <000e0cd6b0065f29e104606901ad@google.com>

locale-enhancement-dev at openjdk.java.net, you are invited to

Title: OpenJDK Locale Enhancement Project Bi-Weely Meeting
Time: Tue Apr 28 7:30pm ? 8pm (Timezone: Eastern Time)
Where: Teleconference
Calendar: locale-enhancement-dev at openjdk.java.net
Owner/Creator: y.umaoka at gmail.com

Description: Toll free from the US and Canada: (877)421-0033
International dialing: +1(770)615-1250

Toll free from Japan (KDD): 00531-11-3180
Toll free from Japan (Cable&Wireless): 0066-33-801263
Toll free from Japan (Softbank): 0044-22-112668
Toll free from Japan (NTT): 0034-800-900155

Other country dial-ins available on request

Passcode: 662122#

Meeting agenda page:  
http://sites.google.com/site/openjdklocale/meeting-agenda

You can view this event at  
http://www.google.com/calendar/event?action=VIEW&eid=MmdnZmxib2JtcWcxY3J0cG82bXI5b20ydjggbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tMjIzZDI1NWFjMTRhYjRjM2Y4ZGUzOWY5NTkzYjVlMDk0NDhkZGVhZQ&ctz=America%2FNew_York&hl=en



You are receiving this courtesy email at the account  
locale-enhancement-dev at openjdk.java.net because you are an attendee of this  
event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
http://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/0212bb51/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1581 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/0212bb51/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1616 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/0212bb51/attachment-0001.bin 

From y.umaoka at gmail.com  Tue Jan 13 19:34:58 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 14 Jan 2009 03:34:58 +0000
Subject: [loc-en-dev] =?windows-1252?q?=5BInvitation=5D_OpenJDK_Locale_Enh?=
	=?windows-1252?q?ancement_Project_Bi-Weely_Meeting_=40_Tue_May_12_?=
	=?windows-1252?q?7=3A30pm_=96_8pm_=28locale-enhancement-dev=40open?=
	=?windows-1252?q?jdk=2Ejava=2Enet=29?=
Message-ID: <0016361e87782cc6590460690686@google.com>

locale-enhancement-dev at openjdk.java.net, you are invited to

Title: OpenJDK Locale Enhancement Project Bi-Weely Meeting
Time: Tue May 12 7:30pm ? 8pm (Timezone: Eastern Time)
Where: Teleconference
Calendar: locale-enhancement-dev at openjdk.java.net
Owner/Creator: y.umaoka at gmail.com

Description: Toll free from the US and Canada: (877)421-0033
International dialing: +1(770)615-1250

Toll free from Japan (KDD): 00531-11-3180
Toll free from Japan (Cable&Wireless): 0066-33-801263
Toll free from Japan (Softbank): 0044-22-112668
Toll free from Japan (NTT): 0034-800-900155

Other country dial-ins available on request

Passcode: 662122#

Meeting agenda page:  
http://sites.google.com/site/openjdklocale/meeting-agenda

You can view this event at  
http://www.google.com/calendar/event?action=VIEW&eid=ZWY5bmUzcXA0cDgxcjBnMG1wcDE1bmFsZWMgbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tMGM2MWY4Y2ViY2I2YjJkYmY2ZmY5ODJhMGRlNmI4ODI5YjU2OWIwNQ&ctz=America%2FNew_York&hl=en



You are receiving this courtesy email at the account  
locale-enhancement-dev at openjdk.java.net because you are an attendee of this  
event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
http://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/b9dde2e0/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1581 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/b9dde2e0/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1616 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/b9dde2e0/attachment-0001.bin 

From y.umaoka at gmail.com  Tue Jan 13 19:36:38 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 14 Jan 2009 03:36:38 +0000
Subject: [loc-en-dev] =?windows-1252?q?=5BInvitation=5D_=28No_Subject=29_?=
	=?windows-1252?q?=40_Tue_May_26_7=3A30pm_=96_8pm_=28locale-enhance?=
	=?windows-1252?q?ment-dev=40openjdk=2Ejava=2Enet=29?=
Message-ID: <000e0cd6ec922552410460690c30@google.com>

locale-enhancement-dev at openjdk.java.net, you are invited to

Title: (No Subject)
Time: Tue May 26 7:30pm ? 8pm (Timezone: Eastern Time)
Where: Teleconference
Calendar: locale-enhancement-dev at openjdk.java.net
Owner/Creator: y.umaoka at gmail.com

Description: Toll free from the US and Canada: (877)421-0033
International dialing: +1(770)615-1250

Toll free from Japan (KDD): 00531-11-3180
Toll free from Japan (Cable&Wireless): 0066-33-801263
Toll free from Japan (Softbank): 0044-22-112668
Toll free from Japan (NTT): 0034-800-900155

Other country dial-ins available on request

Passcode: 662122#

Meeting agenda page:  
http://sites.google.com/site/openjdklocale/meeting-agenda

You can view this event at  
http://www.google.com/calendar/event?action=VIEW&eid=cGVjYnYzY2V2MHNmM2NiaGF1M2Y5MDluNGMgbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tYzM5ZmU0MzY2MjMyMjliYzQ4MGE0ODkyMDkzYWZmZDJlNDg4NDhkMg&ctz=America%2FNew_York&hl=en



You are receiving this courtesy email at the account  
locale-enhancement-dev at openjdk.java.net because you are an attendee of this  
event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
http://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/f58f2c38/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1530 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/f58f2c38/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1565 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/f58f2c38/attachment-0001.bin 

From y.umaoka at gmail.com  Tue Jan 13 19:36:55 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Wed, 14 Jan 2009 03:36:55 +0000
Subject: [loc-en-dev] =?windows-1252?q?=5BUpdated_Invitation=5D_OpenJDK_Lo?=
	=?windows-1252?q?cale_Enhancement_Project_Bi-Weely_Meeting_=40_Tue?=
	=?windows-1252?q?_May_26_7=3A30pm_=96_8pm_=28locale-enhancement-de?=
	=?windows-1252?q?v=40openjdk=2Ejava=2Enet=29?=
Message-ID: <001517511b482616a20460690de8@google.com>

Details for the following event have changed:

Title: OpenJDK Locale Enhancement Project Bi-Weely Meeting
Time: Tue May 26 7:30pm ? 8pm (Timezone: Eastern Time)
Where: Teleconference
Calendar: locale-enhancement-dev at openjdk.java.net
Owner/Creator: y.umaoka at gmail.com

Description: Toll free from the US and Canada: (877)421-0033
International dialing: +1(770)615-1250

Toll free from Japan (KDD): 00531-11-3180
Toll free from Japan (Cable&Wireless): 0066-33-801263
Toll free from Japan (Softbank): 0044-22-112668
Toll free from Japan (NTT): 0034-800-900155

Other country dial-ins available on request

Passcode: 662122#

Meeting agenda page:  
http://sites.google.com/site/openjdklocale/meeting-agenda

You can view this event at  
http://www.google.com/calendar/event?action=VIEW&eid=cGVjYnYzY2V2MHNmM2NiaGF1M2Y5MDluNGMgbG9jYWxlLWVuaGFuY2VtZW50LWRldkBvcGVuamRrLmphdmEubmV0&tok=MTgjeS51bWFva2FAZ21haWwuY29tYzM5ZmU0MzY2MjMyMjliYzQ4MGE0ODkyMDkzYWZmZDJlNDg4NDhkMg&ctz=America%2FNew_York&hl=en



You are receiving this courtesy email at the account  
locale-enhancement-dev at openjdk.java.net because you are an attendee of this  
event.

To stop receiving future notifications for this event, decline this event.  
Alternatively you can sign up for a Google account at  
http://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/ed234945/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1581 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/ed234945/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1616 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090114/ed234945/attachment-0001.bin 

From y.umaoka at gmail.com  Tue Jan 13 19:53:37 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Tue, 13 Jan 2009 22:53:37 -0500
Subject: [loc-en-dev] Locale Enhancement Project call invitation
Message-ID: <496D61C1.5010700@gmail.com>

Hi folks,

I've just sent out a series of invitation messages for Bi-Weekly project 
meetings.  In the meetings, we'll discuss open design issues, task 
assignments, schedules and other topics related to this project.  I 
scheduled the first conference call next week.

-Yoshito


From Masayoshi.Okutsu at Sun.COM  Tue Jan 20 00:25:57 2009
From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu)
Date: Tue, 20 Jan 2009 17:25:57 +0900
Subject: [loc-en-dev] Comments on the locale enhancement proposal
Message-ID: <49758A95.2080909@sun.com>

Folks,

Finally I've spent some time to review the locale enhancement proposal. 
Here are my comments on the proposal.

- Compatibility Strategy

I think we should have a cleaner and simpler strategy to support the 
enhancements while keeping compatibility so that it's easier for 
non-i18n people how to use new staff for the new features.

My proposal is:

    * the existing interfaces should be kept fully compatible in both
      binaries and source code.
    * the enhancements should be available only through new interfaces
      given by the builder pattern design which is flexible and extensible.
    * the factory method for creating a Locale should be eliminated
      because having both factory methods and a builder is redundant.
    * enum IDType should be eliminate and add methods with ID type names
      (e.g., toBCP47String() instead of toString(IDType.BCP47))
    * support a method which performs conversions between old and new
      Locales. (best effort basis) e.g., zh_TW (old) -> zh_Hant_TW
      (new), zh_Hant (new) -> zh_TW (old)

- Development

We should define a minimal set of changes that should go to JDK 7. I'm 
considering support of ISO 639 (new 2-letter and part 2-3) and script as 
the minimal set. We will be able to add more if the schedule allows.

- 6.1 Script

The 4-arg Locale constructor examples in the table should be removed.

new Locale("", "", "US").toString() should return "" for compatibility, 
assuming that new Locale("", "", US") is a typo of new Locale("", "", "US").

- 7. Locale Resource/Service Lookup

Should the script part be treated as additional information to the 
language to disambiguate the writing system? So the zh_Hans_CN look-up 
sequence should be zh_Hans_CN -> zh_CN -> zh_Hans -> zh? (zh_CN and zh 
shouldn't exist to avoid conflicts with zh_Hant_CN and other zh_* 
sequences, though.)

Should country really be added to the lang_script? (e.g., zh_Hant -> 
zh_Hant_TW)

Should script be added to language? (e.g., pa -> pa_Guru)

The *_NO look-up sequences should be consistent with the no and nb ones. 
So the sequences should be:

no_NO -> nb_NO -> no -> nb
no_NO_NY -> nn_NO -> no_NO -> nn -> no
nn_NO -> no_NO_NY -> nn -> no
nb_NO -> no_NO -> nb -> no

- 5.3. Locale Builder
- 8. Summary Proposed API Changes
- LocaleBuilder API

The builder class should be a nested class of Locale. (LocaleBuilder 
should be Locale.Builder.)

The builder methods should return the builder object so that it can 
support a fluent interface.

I prefer build() instead of getLocale().


That's all for today.

Thanks,
Masayoshi



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

From dougfelt at google.com  Tue Jan 20 12:26:57 2009
From: dougfelt at google.com (Doug Felt)
Date: Tue, 20 Jan 2009 12:26:57 -0800
Subject: [loc-en-dev] Comments on the locale enhancement proposal
In-Reply-To: <49758A95.2080909@sun.com>
References: <49758A95.2080909@sun.com>
Message-ID: <146f39a80901201226u740f3a0bn7dde09b6f0817bcd@mail.gmail.com>

Comments inline.

On Tue, Jan 20, 2009 at 12:25 AM, Masayoshi Okutsu <Masayoshi.Okutsu at sun.com
> wrote:

>  Folks,
>
> Finally I've spent some time to review the locale enhancement proposal.
> Here are my comments on the proposal.
>
> - Compatibility Strategy
>
> I think we should have a cleaner and simpler strategy to support the
> enhancements while keeping compatibility so that it's easier for non-i18n
> people how to use new staff for the new features.
>
> My proposal is:
>
>    - the existing interfaces should be kept fully compatible in both
>    binaries and source code.
>
> Can you define more precisely what you mean?  Do you mean no API additions
to the Locale class?

>
>    -
>    - the enhancements should be available only through new interfaces
>    given by the builder pattern design which is flexible and extensible.
>    - the factory method for creating a Locale should be eliminated because
>    having both factory methods and a builder is redundant.
>
> Depends on the common use case.

>
>    -
>    - enum IDType should be eliminate and add methods with ID type names
>    (e.g., toBCP47String() instead of toString(IDType.BCP47))
>
> I lean this way too.

>
>    -
>    - support a method which performs conversions between old and new
>    Locales. (best effort basis) e.g., zh_TW (old) -> zh_Hant_TW (new), zh_Hant
>    (new) -> zh_TW (old)
>
> - Development
>
> We should define a minimal set of changes that should go to JDK 7. I'm
> considering support of ISO 639 (new 2-letter and part 2-3) and script as the
> minimal set. We will be able to add more if the schedule allows.
>

I think that's always been the assumption.

>
>
> - 6.1 Script
>
> The 4-arg Locale constructor examples in the table should be removed.
>

Yes.


>
>
> new Locale("", "", "US").toString() should return "" for compatibility,
> assuming that new Locale("", "", US") is a typo of new Locale("", "", "US").
>
> - 7. Locale Resource/Service Lookup
>

I think of there being two situations we might want to handle automatically:

1) old data, new identifiers
2) new data, old identifiers

The proposal tries to deal with both, by defining what we think the old data
and old identifiers mean in the new system.  So for example we assume that
old data tagged as 'zh_TW' is in fact in traditional Han and should be
presented as 'zh_Hant_TW' data; similarly that a request for 'zh_TW' data is
implicitly a request for traditional Han (as well as Taiwan) data since that
is what (we assume) it returns for existing appliations/jvms, and so should
be handled as a request for 'zh_Hant_TW' data.

We don't necessarily have to handle both situations (or either).

If we don't redefine old data as being locatable under the new identifiers,
this would be inconvenient for people shipping existing applications that
users might run on JVMs handling new locale identifiers-- they'd have to
tell such users to ensure, for example, that their system locale was set to
'zh_TW' and not 'zh_Hant_TW', otherwise an unmodified fallback system would
miss the old 'zh_TW' data.

If we don't allow old identifiers to locate new data, we'll have to tell
people to make their data available under both the new and old identifiers.
It's likely many clients will be dealing with old identifiers for some time
(e.g. handling an HTTP request that specifies a 'zh_TW' locale).  We could
tell them to copy their data, use an aliasing mechanism under the covers (as
ICU does), or convert the identifiers on the boundaries themselves
(converting 'zh_TW' to 'zh_Hant_TW' at the point they receive the HTTP
request), but they might not be happy with this.

I think the approach here (Yoshito, tell me if I'm wrong) is to specify
explicitly the remappings necessary to support legacy data.


> Should the script part be treated as additional information to the language
> to disambiguate the writing system? So the zh_Hans_CN look-up sequence
> should be zh_Hans_CN -> zh_CN -> zh_Hans -> zh? (zh_CN and zh shouldn't
> exist to avoid conflicts with zh_Hant_CN and other zh_* sequences, though.)
>

The zh_CN data need not exist if there is zh_Hans_CN data, but it might
exist as legacy, so it needs to be part of the search.


> Should country really be added to the lang_script? (e.g., zh_Hant ->
> zh_Hant_TW)
>

This does seem odd.  I guess the issue addressed in section 7.3 is that some
clients might have followed the suggestion to make data available under
'zh_Hant_TW', but did not provide any under 'zh_Hant', even though 'zh_Hant'
was the intended semantics of the data.  I think it might be better to not
support this, unless there are clients who are in this situation and cannot
adapt.


>
> Should script be added to language? (e.g., pa -> pa_Guru)
>

I wonder about this too.  Perhaps Yoshito can describe a case in which this
behavior is needed.  I didn't notice a motivating case.


>
> The *_NO look-up sequences should be consistent with the no and nb ones. So
> the sequences should be:
>
> no_NO -> nb_NO -> no -> nb
> no_NO_NY -> nn_NO -> no_NO -> nn -> no
> nn_NO -> no_NO_NY -> nn -> no
> nb_NO -> no_NO -> nb -> no
>

I don't know enough about this.


>
> - 5.3. Locale Builder
> - 8. Summary Proposed API Changes
> - LocaleBuilder API
>
> The builder class should be a nested class of Locale. (LocaleBuilder should
> be Locale.Builder.)
>

I agree.

>
> The builder methods should return the builder object so that it can support
> a fluent interface.
>

I agree, this is typical for builders.

>
> I prefer build() instead of getLocale().
>

Me too.

>
>
>
> That's all for today.
>
> Thanks,
> Masayoshi
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090120/8b4b401c/attachment.html 

From y.umaoka at gmail.com  Tue Jan 20 13:46:46 2009
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Tue, 20 Jan 2009 16:46:46 -0500
Subject: [loc-en-dev] Comments on the locale enhancement proposal
In-Reply-To: <146f39a80901201226u740f3a0bn7dde09b6f0817bcd@mail.gmail.com>
References: <49758A95.2080909@sun.com>
	<146f39a80901201226u740f3a0bn7dde09b6f0817bcd@mail.gmail.com>
Message-ID: <1c8828620901201346l49c2ffe6wbe4f08730a61330c@mail.gmail.com>

I added my comments

On Tue, Jan 20, 2009 at 4:26 PM, Doug Felt <dougfelt at google.com> wrote:

> Comments inline.
>
> On Tue, Jan 20, 2009 at 12:25 AM, Masayoshi Okutsu <
> Masayoshi.Okutsu at sun.com> wrote:
>
>>  Folks,
>>
>> Finally I've spent some time to review the locale enhancement proposal.
>> Here are my comments on the proposal.
>>
>> - Compatibility Strategy
>>
>> I think we should have a cleaner and simpler strategy to support the
>> enhancements while keeping compatibility so that it's easier for non-i18n
>> people how to use new staff for the new features.
>>
>> My proposal is:
>>
>>    - the existing interfaces should be kept fully compatible in both
>>    binaries and source code.
>>
>> Can you define more precisely what you mean?  Do you mean no API additions
> to the Locale class?
>

I have no doubt about keeping the existing interfaces fully compatible.  And
it should be binary compatible (I meant, the existing code does not require
to recompile, that is, exact same API signature for the existing APIs).  But
I could not understand "source code".  Can you explain?  I guess internal
implementation changes should not affect to the old Java consumers.


>
>
>>    -
>>    - the enhancements should be available only through new interfaces
>>    given by the builder pattern design which is flexible and extensible.
>>    - the factory method for creating a Locale should be eliminated
>>    because having both factory methods and a builder is redundant.
>>
>> Depends on the common use case.
>
>>
>>    -
>>    - enum IDType should be eliminate and add methods with ID type names
>>    (e.g., toBCP47String() instead of toString(IDType.BCP47))
>>
>> I lean this way too.
>

I have no problems with this.


>
>
>>    -
>>    - support a method which performs conversions between old and new
>>    Locales. (best effort basis) e.g., zh_TW (old) -> zh_Hant_TW (new), zh_Hant
>>    (new) -> zh_TW (old)
>>
>> - Development
>>
>> We should define a minimal set of changes that should go to JDK 7. I'm
>> considering support of ISO 639 (new 2-letter and part 2-3) and script as the
>> minimal set. We will be able to add more if the schedule allows.
>>
>
> I think that's always been the assumption.
>

I'm not sure whether we can narrow the scope without introducing
inconsistency (or future incompatible changes).  I think we need further
discussion for defining the scope of JDK 7.


>
>
>>
>> - 6.1 Script
>>
>> The 4-arg Locale constructor examples in the table should be removed.
>>
>
> Yes.
>

I assume this means that we will encourage Java user to move to
factory/builder.


>
>
>
>>
>>
>> new Locale("", "", "US").toString() should return "" for compatibility,
>> assuming that new Locale("", "", US") is a typo of new Locale("", "", "US").
>>
>> - 7. Locale Resource/Service Lookup
>>
>
> I think of there being two situations we might want to handle
> automatically:
>
> 1) old data, new identifiers
> 2) new data, old identifiers
>
> The proposal tries to deal with both, by defining what we think the old
> data and old identifiers mean in the new system.  So for example we assume
> that old data tagged as 'zh_TW' is in fact in traditional Han and should be
> presented as 'zh_Hant_TW' data; similarly that a request for 'zh_TW' data is
> implicitly a request for traditional Han (as well as Taiwan) data since that
> is what (we assume) it returns for existing appliations/jvms, and so should
> be handled as a request for 'zh_Hant_TW' data.
>
> We don't necessarily have to handle both situations (or either).
>
> If we don't redefine old data as being locatable under the new identifiers,
> this would be inconvenient for people shipping existing applications that
> users might run on JVMs handling new locale identifiers-- they'd have to
> tell such users to ensure, for example, that their system locale was set to
> 'zh_TW' and not 'zh_Hant_TW', otherwise an unmodified fallback system would
> miss the old 'zh_TW' data.
>
> If we don't allow old identifiers to locate new data, we'll have to tell
> people to make their data available under both the new and old identifiers.
> It's likely many clients will be dealing with old identifiers for some time
> (e.g. handling an HTTP request that specifies a 'zh_TW' locale).  We could
> tell them to copy their data, use an aliasing mechanism under the covers (as
> ICU does), or convert the identifiers on the boundaries themselves
> (converting 'zh_TW' to 'zh_Hant_TW' at the point they receive the HTTP
> request), but they might not be happy with this.
>
> I think the approach here (Yoshito, tell me if I'm wrong) is to specify
> explicitly the remappings necessary to support legacy data.
>

Correct.  We'd like to give Java users options - keep the existing
resources/codes unchanged, while adopting new (we assume - better) locales
without any problems.


>
>
>
>> Should the script part be treated as additional information to the
>> language to disambiguate the writing system? So the zh_Hans_CN look-up
>> sequence should be zh_Hans_CN -> zh_CN -> zh_Hans -> zh? (zh_CN and zh
>> shouldn't exist to avoid conflicts with zh_Hant_CN and other zh_* sequences,
>> though.)
>>
>
> The zh_CN data need not exist if there is zh_Hans_CN data, but it might
> exist as legacy, so it needs to be part of the search.
>
>
>> Should country really be added to the lang_script? (e.g., zh_Hant ->
>> zh_Hant_TW)
>>
>
> This does seem odd.  I guess the issue addressed in section 7.3 is that
> some clients might have followed the suggestion to make data available under
> 'zh_Hant_TW', but did not provide any under 'zh_Hant', even though 'zh_Hant'
> was the intended semantics of the data.  I think it might be better to not
> support this, unless there are clients who are in this situation and cannot
> adapt.
>
>

Obviously, many of existing Java users tag "zh_TW" for Traditional Chinese
language contents, no matter it is actually for TW.  At the same time, some
others uses "zh_TW" specific for TW.  When these two use cases are mixed
with new locale ID with script, I think zh_Hant -> zh_Hant_TW would be
safer.  But, I agree that we should review whether we really need this or
not.


>
>> Should script be added to language? (e.g., pa -> pa_Guru)
>>
>
> I wonder about this too.  Perhaps Yoshito can describe a case in which this
> behavior is needed.  I didn't notice a motivating case.
>
>

When you do not want to fallback one script to another, this makes sense.
For example, some users may want to supply resources - pa_Guru and pa_Arab,
but no pa.  Anyway, I think Mark has some thoughts on this.


>
>
>> The *_NO look-up sequences should be consistent with the no and nb ones.
>> So the sequences should be:
>>
>> no_NO -> nb_NO -> no -> nb
>> no_NO_NY -> nn_NO -> no_NO -> nn -> no
>> nn_NO -> no_NO_NY -> nn -> no
>> nb_NO -> no_NO -> nb -> no
>>
>
> I don't know enough about this.
>

Existing Java documentation says no_NO is Bokmal (Norway) / no_NO_NY is
Nynorsk (Norway).  This design starts with mapping to the most preferrable
form - no_NO -> nb_NO / no_NO_NY -> nn_NO, then consuming the fallback chain
from there.  Then, visit the chain from no_*.  The philosophy behind this is
- no is not exactly equivalent nb / nn.

1. no_NO = nb_NO (by the existing Java's definition)
2. no_NO_NY = nn_NO (by the existing Java's definition)

I assume these are "aliases" in the Java world (but not true in BCP47 /
Unicode CLDR).

Thus, I prefer

no_NO (alias of nb_NO) -> nb_NO -> nb (-> (macro language mapping) no_NO) ->
no
no_NO_NY (alias of nn_NO) -> nn_NO -> nn -> (macro language mapping) no_NO
-> no

Anyway, we should discuss about this too.


>
>
>
>>
>> - 5.3. Locale Builder
>> - 8. Summary Proposed API Changes
>> - LocaleBuilder API
>>
>> The builder class should be a nested class of Locale. (LocaleBuilder
>> should be Locale.Builder.)
>>
>
> I agree.
>

I agree


>
>
>> The builder methods should return the builder object so that it can
>> support a fluent interface.
>>
>
> I agree, this is typical for builders.
>

I agree.


>
>
>> I prefer build() instead of getLocale().
>>
>
> Me too.
>

No objection.  I do not care about the method name much.

>
>
>>
>>
>> That's all for today.
>>
>> Thanks,
>> Masayoshi
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090120/4e5eeab1/attachment.html 

From dougfelt at google.com  Tue Jan 20 14:52:16 2009
From: dougfelt at google.com (Doug Felt)
Date: Tue, 20 Jan 2009 14:52:16 -0800
Subject: [loc-en-dev] Comments on the locale enhancement proposal
In-Reply-To: <1c8828620901201346l49c2ffe6wbe4f08730a61330c@mail.gmail.com>
References: <49758A95.2080909@sun.com>
	<146f39a80901201226u740f3a0bn7dde09b6f0817bcd@mail.gmail.com>
	<1c8828620901201346l49c2ffe6wbe4f08730a61330c@mail.gmail.com>
Message-ID: <146f39a80901201452i1d22756atbca1497c415fa470@mail.gmail.com>

My comments again.  I've omitted part of the thread.

On Tue, Jan 20, 2009 at 1:46 PM, Yoshito Umaoka <y.umaoka at gmail.com> wrote:

> I added my comments
>
> On Tue, Jan 20, 2009 at 4:26 PM, Doug Felt <dougfelt at google.com> wrote:
>
>> Comments inline.
>>
>> On Tue, Jan 20, 2009 at 12:25 AM, Masayoshi Okutsu <
>> Masayoshi.Okutsu at sun.com> wrote:
>>
>>>  Folks,
>>>
>>

>
>>> Should country really be added to the lang_script? (e.g., zh_Hant ->
>>> zh_Hant_TW)
>>>
>>
>> This does seem odd.  I guess the issue addressed in section 7.3 is that
>> some clients might have followed the suggestion to make data available under
>> 'zh_Hant_TW', but did not provide any under 'zh_Hant', even though 'zh_Hant'
>> was the intended semantics of the data.  I think it might be better to not
>> support this, unless there are clients who are in this situation and cannot
>> adapt.
>>
>>
>
> Obviously, many of existing Java users tag "zh_TW" for Traditional Chinese
> language contents, no matter it is actually for TW.  At the same time, some
> others uses "zh_TW" specific for TW.  When these two use cases are mixed
> with new locale ID with script, I think zh_Hant -> zh_Hant_TW would be
> safer.  But, I agree that we should review whether we really need this or
> not.
>

I think of this in terms of relabeling the data and remapping the requests.
I know, this is not how you've spec'd it.

If there is a resource labeled 'zh_TW' then I'd relabel it as follows:
- if there is no 'zh_Hant' data, treat it as 'zh_Hant'
- else if there is no 'zh_Hant_TW' data, treat it as 'zh_Hant_TW'

I think this produces essentially the same result as what you have.  I find
it a little more palatable since it's worded in terms of how to interpret
the ('legacy') data, not how to expand the requested ('new') locale id.

It does mean that people cannot use 'zh_Hant' to get traditional Chinese
while falling back to some default (chinese-speaking) country data (currency
and currency format, say) if there is zh_TW data.  If they expected 'zh' to
be populated with 'CN' data by default, they wouldn't get it.  The whole
notion of country-specific data independent of language doesn't fit the
simple locale id model well, though, so I'm not sure how much of a problem
this is.  Are there even consistent expectations to violate?


>
>>
>>> Should script be added to language? (e.g., pa -> pa_Guru)
>>>
>>
>> I wonder about this too.  Perhaps Yoshito can describe a case in which
>> this behavior is needed.  I didn't notice a motivating case.
>>
>>
>
> When you do not want to fallback one script to another, this makes sense.
> For example, some users may want to supply resources - pa_Guru and pa_Arab,
> but no pa.  Anyway, I think Mark has some thoughts on this.
>
>

This sounds like a new feature to me. We haven't supported this in the
past-- if users supplied resources 'zh_TW' and 'zh_CN' but no 'zh', and I
asked for 'zh', I'd get root (or default locale?) data.  I don't see an
argument from compatibility.  I think it would have to be justified as a new
feature.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090120/733d0780/attachment.html 

From Masayoshi.Okutsu at Sun.COM  Tue Jan 20 16:04:13 2009
From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu)
Date: Wed, 21 Jan 2009 09:04:13 +0900
Subject: [loc-en-dev] Comments on the locale enhancement proposal
In-Reply-To: <146f39a80901201226u740f3a0bn7dde09b6f0817bcd@mail.gmail.com>
References: <49758A95.2080909@sun.com>
	<146f39a80901201226u740f3a0bn7dde09b6f0817bcd@mail.gmail.com>
Message-ID: <4976667D.2010904@sun.com>

Comments inline.

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

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

It's OK to add new methods to Locale.

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

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

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

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

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

Masayoshi



From dougfelt at google.com  Tue Jan 20 16:13:53 2009
From: dougfelt at google.com (Doug Felt)
Date: Tue, 20 Jan 2009 16:13:53 -0800
Subject: [loc-en-dev] Comments on the locale enhancement proposal
In-Reply-To: <4976667D.2010904@sun.com>
References: <49758A95.2080909@sun.com>
	<146f39a80901201226u740f3a0bn7dde09b6f0817bcd@mail.gmail.com>
	<4976667D.2010904@sun.com>
Message-ID: <146f39a80901201613x3fa0146bgcd06a792a9f4c5b9@mail.gmail.com>

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

> Comments inline.
>
> On 1/21/2009 5:26 AM, Doug Felt wrote:
>
>> Comments inline.
>>
>> On Tue, Jan 20, 2009 at 12:25 AM, Masayoshi Okutsu <
>> Masayoshi.Okutsu at sun.com <mailto:Masayoshi.Okutsu at sun.com>> wrote:
>>
>>
>>
>>    My proposal is:
>>
>>        * the existing interfaces should be kept fully compatible in
>>          both binaries and source code.
>>
>> Can you define more precisely what you mean?  Do you mean no API additions
>> to the Locale class?
>>
>
> No semantic or behavior changes to the existing methods. I saw the
> toString() behavior change in the 6.1 Script table and the semantic changes
> to the Locale constructors. We should just describe the current behavior
> where it's necessary.
>
> It's OK to add new methods to Locale.
>
>
>>        * the factory method for creating a Locale should be
>>          eliminated because having both factory methods and a builder
>>          is redundant.
>>
>> Depends on the common use case.
>>
>
> You can do the same thing in the builder interface, something like this:
>
> new Locale.Builder().bcp47("...").build();
>
>
>>    - 7. Locale Resource/Service Lookup
>>
>>
>> I think of there being two situations we might want to handle
>> automatically:
>>
>> 1) old data, new identifiers
>> 2) new data, old identifiers
>>
>> The proposal tries to deal with both, by defining what we think the old
>> data and old identifiers mean in the new system.  So for example we assume
>> that old data tagged as 'zh_TW' is in fact in traditional Han and should be
>> presented as 'zh_Hant_TW' data; similarly that a request for 'zh_TW' data is
>> implicitly a request for traditional Han (as well as Taiwan) data since that
>> is what (we assume) it returns for existing appliations/jvms, and so should
>> be handled as a request for 'zh_Hant_TW' data.
>>
>> We don't necessarily have to handle both situations (or either).
>>
>
> I think it's obvious that we can't support old data with new identifiers
> perfectly, like zh_Hans_CN and zh_Hant_CN. When we can't support both, I
> prefer to define a simple algorithm to produce a look-up sequences with
> minimum exceptions. [...]
>

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


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

From srloomis at us.ibm.com  Tue Jan 20 16:18:59 2009
From: srloomis at us.ibm.com (Steven R Loomis)
Date: Tue, 20 Jan 2009 16:18:59 -0800
Subject: [loc-en-dev] Comments on the locale enhancement proposal
In-Reply-To: <49758A95.2080909@sun.com>
References: <49758A95.2080909@sun.com>
Message-ID: <OF60C5D159.AF483336-ON88257545.0000E108-88257545.0001BCF1@us.ibm.com>

Comments here:

   As to compatibility, I think the principle here is: existing locales
   should have existing behavior.  So,  zh_Hans_CN and zh_Hant_TW would NOT
   be used as system default locales.

   You said:

        MO> "We should define a minimal set of changes that should go to
   JDK 7. I'm considering support of ISO 639 (new 2-letter and part 2-3)
   and script as the minimal set. We will be able to add more if the
   schedule allows."

   I would like to also consider the keyword support as well, to allow for
   interoperability with CLDR, and also to enable future selection of
   services. The JDK services are not being asked to implement any behavior
   at all with the keywords. It allows for a flexible selection of items
   that currently use variants (such as th_TH_TH or ja_JP_JP- those IDs
   would continue to work as they do now, of course.)

Regards,
Steven



                                                                                                                                                   
  From:       Masayoshi Okutsu <Masayoshi.Okutsu at Sun.COM>                                                                                          
                                                                                                                                                   
  To:         locale-enhancement-dev at openjdk.java.net                                                                                              
                                                                                                                                                   
  Date:       01/20/2009 12:27 AM                                                                                                                  
                                                                                                                                                   
  Subject:    [loc-en-dev] Comments on the locale enhancement proposal                                                                             
                                                                                                                                                   





Folks,

Finally I've spent some time to review the locale enhancement proposal.
Here are my comments on the proposal.

- Compatibility Strategy

I think we should have a cleaner and simpler strategy to support the
enhancements while keeping compatibility so that it's easier for non-i18n
people how to use new staff for the new features.

My proposal is:
      the existing interfaces should be kept fully compatible in both
      binaries and source code.
      the enhancements should be available only through new interfaces
      given by the builder pattern design which is flexible and extensible.
      the factory method for creating a Locale should be eliminated because
      having both factory methods and a builder is redundant.
      enum IDType should be eliminate and add methods with ID type names
      (e.g., toBCP47String() instead of toString(IDType.BCP47))
      support a method which performs conversions between old and new
      Locales. (best effort basis) e.g., zh_TW (old) -> zh_Hant_TW (new),
      zh_Hant (new) -> zh_TW (old)
- Development

We should define a minimal set of changes that should go to JDK 7. I'm
considering support of ISO 639 (new 2-letter and part 2-3) and script as
the minimal set. We will be able to add more if the schedule allows.

- 6.1 Script

The 4-arg Locale constructor examples in the table should be removed.

new Locale("", "", "US").toString() should return "" for compatibility,
assuming that new Locale("", "", US") is a typo of new Locale("", "",
"US").

- 7. Locale Resource/Service Lookup

Should the script part be treated as additional information to the language
to disambiguate the writing system? So the zh_Hans_CN look-up sequence
should be zh_Hans_CN -> zh_CN -> zh_Hans -> zh? (zh_CN and zh shouldn't
exist to avoid conflicts with zh_Hant_CN and other zh_* sequences, though.)

Should country really be added to the lang_script? (e.g., zh_Hant ->
zh_Hant_TW)

Should script be added to language? (e.g., pa -> pa_Guru)

The *_NO look-up sequences should be consistent with the no and nb ones. So
the sequences should be:

no_NO -> nb_NO -> no -> nb
no_NO_NY -> nn_NO -> no_NO -> nn -> no
nn_NO -> no_NO_NY -> nn -> no
nb_NO -> no_NO -> nb -> no

- 5.3. Locale Builder
- 8. Summary Proposed API Changes
- LocaleBuilder API

The builder class should be a nested class of Locale. (LocaleBuilder should
be Locale.Builder.)

The builder methods should return the builder object so that it can support
a fluent interface.

I prefer build() instead of getLocale().


That's all for today.

Thanks,
Masayoshi







From Masayoshi.Okutsu at Sun.COM  Wed Jan 21 00:31:10 2009
From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu)
Date: Wed, 21 Jan 2009 17:31:10 +0900
Subject: [loc-en-dev] Comments on the locale enhancement proposal
In-Reply-To: <146f39a80901201613x3fa0146bgcd06a792a9f4c5b9@mail.gmail.com>
References: <49758A95.2080909@sun.com>
	<146f39a80901201226u740f3a0bn7dde09b6f0817bcd@mail.gmail.com>
	<4976667D.2010904@sun.com>
	<146f39a80901201613x3fa0146bgcd06a792a9f4c5b9@mail.gmail.com>
Message-ID: <4976DD4E.4050307@sun.com>

On 1/21/2009 9:13 AM, Doug Felt wrote:
>
>
> On Tue, Jan 20, 2009 at 4:04 PM, Masayoshi Okutsu 
> <Masayoshi.Okutsu at sun.com <mailto:Masayoshi.Okutsu at sun.com>> wrote:
>
>     I think it's obvious that we can't support old data with new
>     identifiers perfectly, like zh_Hans_CN and zh_Hant_CN. When we
>     can't support both, I prefer to define a simple algorithm to
>     produce a look-up sequences with minimum exceptions. [...]
>
>
> Can define one so we can understand what cases you intend to handle 
> and how?

My preference is:

(1) Treat language+script as a writingsystem which produces sequence 
language_script -> language.

(2) Apply the traditional sequence production rule to 
writingsystem_country_variant

writingsystem_country_variant
writingsystem_country
writingsystem

each of which produces language_script -> language. Therefore, the 
entire sequence is:

language_script_country_variant
language_country_variant
language_script_country
language_country
language_script
language

For example, the sequence for zh_Hans_CN is:

zh_Hans_CN
zh_CN
zh_Hans
zh

while the proposed one is:

zh_Hans_CN
zh_Hans
zh_CN
zh

(3) If no script is given, the sequence is the same as the traditional one.

language_country_variant
language_country
language

(4) Exceptions are Norwegian and Hebrew.

no_NO -> nb_NO -> no -> nb
no_NO_NY -> nn_NO -> no_NO -> nn -> no
nn_NO -> no_NO_NY -> nn -> no
nb_NO -> no_NO -> nb -> no

he_IL -> iw_IL -> he -> iw
iw_IL -> he_IL -> iw -> he

Actually, these Norwegian and Hebrew sequences are what Naoto and I 
tried to support in JDK6. But we gave it up due to a compatibility 
problem reported by a customer. The problem is not the sequences, but 
the normalization in Locale: iw->he.

Masayoshi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090121/0ace7b53/attachment.html 

From Masayoshi.Okutsu at Sun.COM  Wed Jan 21 00:40:04 2009
From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu)
Date: Wed, 21 Jan 2009 17:40:04 +0900
Subject: [loc-en-dev] Comments on the locale enhancement proposal
In-Reply-To: <OF60C5D159.AF483336-ON88257545.0000E108-88257545.0001BCF1@us.ibm.com>
References: <49758A95.2080909@sun.com>
	<OF60C5D159.AF483336-ON88257545.0000E108-88257545.0001BCF1@us.ibm.com>
Message-ID: <4976DF64.70608@sun.com>

I just want to avoid the situation that we miss the train and everything 
is left behind. Do you think it's difficult to split the entire work 
into some milestones?

Thanks,
Masayoshi

On 1/21/2009 9:18 AM, Steven R Loomis wrote:
> Comments here:
>
>    As to compatibility, I think the principle here is: existing locales
>    should have existing behavior.  So,  zh_Hans_CN and zh_Hant_TW would NOT
>    be used as system default locales.
>
>    You said:
>
>         MO> "We should define a minimal set of changes that should go to
>    JDK 7. I'm considering support of ISO 639 (new 2-letter and part 2-3)
>    and script as the minimal set. We will be able to add more if the
>    schedule allows."
>
>    I would like to also consider the keyword support as well, to allow for
>    interoperability with CLDR, and also to enable future selection of
>    services. The JDK services are not being asked to implement any behavior
>    at all with the keywords. It allows for a flexible selection of items
>    that currently use variants (such as th_TH_TH or ja_JP_JP- those IDs
>    would continue to work as they do now, of course.)
>
> Regards,
> Steven
>
>
>
>                                                                                                                                                    
>   From:       Masayoshi Okutsu <Masayoshi.Okutsu at Sun.COM>                                                                                          
>                                                                                                                                                    
>   To:         locale-enhancement-dev at openjdk.java.net                                                                                              
>                                                                                                                                                    
>   Date:       01/20/2009 12:27 AM                                                                                                                  
>                                                                                                                                                    
>   Subject:    [loc-en-dev] Comments on the locale enhancement proposal                                                                             
>                                                                                                                                                    
>
>
>
>
>
> Folks,
>
> Finally I've spent some time to review the locale enhancement proposal.
> Here are my comments on the proposal.
>
> - Compatibility Strategy
>
> I think we should have a cleaner and simpler strategy to support the
> enhancements while keeping compatibility so that it's easier for non-i18n
> people how to use new staff for the new features.
>
> My proposal is:
>       the existing interfaces should be kept fully compatible in both
>       binaries and source code.
>       the enhancements should be available only through new interfaces
>       given by the builder pattern design which is flexible and extensible.
>       the factory method for creating a Locale should be eliminated because
>       having both factory methods and a builder is redundant.
>       enum IDType should be eliminate and add methods with ID type names
>       (e.g., toBCP47String() instead of toString(IDType.BCP47))
>       support a method which performs conversions between old and new
>       Locales. (best effort basis) e.g., zh_TW (old) -> zh_Hant_TW (new),
>       zh_Hant (new) -> zh_TW (old)
> - Development
>
> We should define a minimal set of changes that should go to JDK 7. I'm
> considering support of ISO 639 (new 2-letter and part 2-3) and script as
> the minimal set. We will be able to add more if the schedule allows.
>
> - 6.1 Script
>
> The 4-arg Locale constructor examples in the table should be removed.
>
> new Locale("", "", "US").toString() should return "" for compatibility,
> assuming that new Locale("", "", US") is a typo of new Locale("", "",
> "US").
>
> - 7. Locale Resource/Service Lookup
>
> Should the script part be treated as additional information to the language
> to disambiguate the writing system? So the zh_Hans_CN look-up sequence
> should be zh_Hans_CN -> zh_CN -> zh_Hans -> zh? (zh_CN and zh shouldn't
> exist to avoid conflicts with zh_Hant_CN and other zh_* sequences, though.)
>
> Should country really be added to the lang_script? (e.g., zh_Hant ->
> zh_Hant_TW)
>
> Should script be added to language? (e.g., pa -> pa_Guru)
>
> The *_NO look-up sequences should be consistent with the no and nb ones. So
> the sequences should be:
>
> no_NO -> nb_NO -> no -> nb
> no_NO_NY -> nn_NO -> no_NO -> nn -> no
> nn_NO -> no_NO_NY -> nn -> no
> nb_NO -> no_NO -> nb -> no
>
> - 5.3. Locale Builder
> - 8. Summary Proposed API Changes
> - LocaleBuilder API
>
> The builder class should be a nested class of Locale. (LocaleBuilder should
> be Locale.Builder.)
>
> The builder methods should return the builder object so that it can support
> a fluent interface.
>
> I prefer build() instead of getLocale().
>
>
> That's all for today.
>
> Thanks,
> Masayoshi
>
>
>
>
>
>   


From dougfelt at google.com  Thu Jan 22 10:02:56 2009
From: dougfelt at google.com (Doug Felt)
Date: Thu, 22 Jan 2009 10:02:56 -0800
Subject: [loc-en-dev] Updated mercurial repository
Message-ID: <146f39a80901221002n35481d9eqe9ff55f7d160f2aa@mail.gmail.com>

I've updated the locale-enhancement mercurial repository with some test code
for Locale API changes.  In the process I also brought the repository
up-to-date with the jdk7 repository.

The main point of this is so we can work on what the API signatures should
look like and what the semantics should be, not to develop the
implementation.  I put together a quick implementation of some of the
features so I could write tests and verify that they worked, but the
implementation is a throwaway.  The tests are incomplete, and the only API
tested is the locale id parsing.  There's clearly much more to do but I
wanted to get this started.

The tests are based on the old locale test framework that was used for the
original Locale tests (a decade ago?).  I'd rather use junit or something
similar, but I don't want to introduce dependencies on third-party
libraries.  If someone knows how these should be structured better, let me
know.

Please look at the tests and API and suggest changes.  Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090122/e3b1e24d/attachment.html