From y.umaoka at gmail.com Thu Jul 9 11:26:20 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Thu, 09 Jul 2009 14:26:20 -0400 Subject: [loc-en-dev] variant field casing Message-ID: <4A56364C.3000507@gmail.com> Hi folks, Variant field in Java Locale is case sensitive. For example - System.out.println(new Locale("th", "TH", "TH").equals(new Locale("th", "TH", "th"))); System.out.println(new Locale("th", "TH", "TH").equals(new Locale("th", "th", "TH"))); These statements print out the results - false true I cannot see any descriptions about variant field casing in the API doc. I think this behavior is problematic if we want to make Locale to handle language tags (which is case in-sensitive) properly. I propose to document that all locale fields are case insensitive and change the behavior. I know this is not backward compatible, but we probably should correct the behavior. By the way, IANA language subtag registry uses lower case letters for variant subtags. And the format used in the registry is the preferred casing. -Yoshito From Naoto.Sato at Sun.COM Fri Jul 10 15:36:18 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Fri, 10 Jul 2009 15:36:18 -0700 Subject: [loc-en-dev] variant field casing In-Reply-To: <4A56364C.3000507@gmail.com> References: <4A56364C.3000507@gmail.com> Message-ID: <4A57C262.1060602@sun.com> Sounds reasonable. I don't see any reason we should distinguish the variant's case. Naoto Yoshito Umaoka wrote: > Hi folks, > > Variant field in Java Locale is case sensitive. For example - > > System.out.println(new Locale("th", "TH", "TH").equals(new > Locale("th", "TH", "th"))); > System.out.println(new Locale("th", "TH", "TH").equals(new > Locale("th", "th", "TH"))); > > These statements print out the results - > > false > true > > I cannot see any descriptions about variant field casing in the API > doc. I think this behavior is problematic if we want to make Locale > to handle language tags (which is case in-sensitive) properly. I > propose to document that all locale fields are case insensitive and > change the behavior. I know this is not backward compatible, but we > probably should correct the behavior. > > By the way, IANA language subtag registry uses lower case letters for > variant subtags. And the format used in the registry is the preferred > casing. > > -Yoshito > From Masayoshi.Okutsu at Sun.COM Mon Jul 13 01:33:15 2009 From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu) Date: Mon, 13 Jul 2009 17:33:15 +0900 Subject: [loc-en-dev] variant field casing In-Reply-To: <4A56364C.3000507@gmail.com> References: <4A56364C.3000507@gmail.com> Message-ID: <4A5AF14B.8030700@sun.com> The API doc isn't clear at all, but the documentation gives some "impression" that the case is preserved for the variant argument. It's likely to encounter compatibility problems if we change the behavior. Masayoshi On 7/10/2009 3:26 AM, Yoshito Umaoka wrote: > Hi folks, > > Variant field in Java Locale is case sensitive. For example - > > System.out.println(new Locale("th", "TH", "TH").equals(new > Locale("th", "TH", "th"))); > System.out.println(new Locale("th", "TH", "TH").equals(new > Locale("th", "th", "TH"))); > > These statements print out the results - > > false > true > > I cannot see any descriptions about variant field casing in the API > doc. I think this behavior is problematic if we want to make Locale > to handle language tags (which is case in-sensitive) properly. I > propose to document that all locale fields are case insensitive and > change the behavior. I know this is not backward compatible, but we > probably should correct the behavior. > > By the way, IANA language subtag registry uses lower case letters for > variant subtags. And the format used in the registry is the preferred > casing. > > -Yoshito > From y.umaoka at gmail.com Mon Jul 20 10:58:03 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Mon, 20 Jul 2009 13:58:03 -0400 Subject: [loc-en-dev] variant field casing In-Reply-To: <4A5AF14B.8030700@sun.com> References: <4A56364C.3000507@gmail.com> <4A5AF14B.8030700@sun.com> Message-ID: <4A64B02B.2050405@gmail.com> In the conf call last week, we (Doug, Steven and myself) agreed followings - 1. Locale constructor does not normalize variant field value. So case is preserved. (Same as current behavior) 2. Locale#equals does case SENSITIVE compare for variant fields. (Same as current behavior) 3. Locale#Builder accept both uppercase/lowercase/mixed-case variant values (still need to satisfy BCP47 variant syntax), but always normalized to uppercase letters internally. Therefore, an instance of Locale created by Builder use uppercase letters for variant field always. 4. Locale#forLanguageTag normalizes a BCP47 variant value to uppercase. 5. Locale#toLanguageTag normalizes a Locale variant field value to lowercase. With this implementation, there is no backward compatibility issues. Java users who want to make Locales compatible/exchangeable with BCP47 language tags are recommended to use upper case variant value in Java Locale, otherwise, roundtrip will fail. Do you think this solution is acceptable? If you have any objections, please respond. -Yoshito > The API doc isn't clear at all, but the documentation gives some > "impression" that the case is preserved for the variant argument. It's > likely to encounter compatibility problems if we change the behavior. > > Masayoshi > > On 7/10/2009 3:26 AM, Yoshito Umaoka wrote: >> Hi folks, >> >> Variant field in Java Locale is case sensitive. For example - >> >> System.out.println(new Locale("th", "TH", "TH").equals(new >> Locale("th", "TH", "th"))); >> System.out.println(new Locale("th", "TH", "TH").equals(new >> Locale("th", "th", "TH"))); >> >> These statements print out the results - >> >> false >> true >> >> I cannot see any descriptions about variant field casing in the API >> doc. I think this behavior is problematic if we want to make Locale >> to handle language tags (which is case in-sensitive) properly. I >> propose to document that all locale fields are case insensitive and >> change the behavior. I know this is not backward compatible, but we >> probably should correct the behavior. >> >> By the way, IANA language subtag registry uses lower case letters for >> variant subtags. And the format used in the registry is the >> preferred casing. >> >> -Yoshito >> > From Masayoshi.Okutsu at Sun.COM Tue Jul 28 01:54:46 2009 From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu) Date: Tue, 28 Jul 2009 17:54:46 +0900 Subject: [loc-en-dev] variant field casing In-Reply-To: <4A64B02B.2050405@gmail.com> References: <4A56364C.3000507@gmail.com> <4A5AF14B.8030700@sun.com> <4A64B02B.2050405@gmail.com> Message-ID: <4A6EBCD6.3050007@sun.com> Let me confirm. The (existing) Locale variant field and the BCP47 variant value (field) are completely separated in the API. Am I correct? Thanks, Masayoshi On 7/21/2009 2:58 AM, Yoshito Umaoka wrote: > In the conf call last week, we (Doug, Steven and myself) agreed > followings - > > 1. Locale constructor does not normalize variant field value. So case > is preserved. (Same as current behavior) > 2. Locale#equals does case SENSITIVE compare for variant fields. (Same > as current behavior) > 3. Locale#Builder accept both uppercase/lowercase/mixed-case variant > values (still need to satisfy BCP47 variant syntax), but always > normalized to uppercase letters internally. Therefore, an instance of > Locale created by Builder use uppercase letters for variant field always. > 4. Locale#forLanguageTag normalizes a BCP47 variant value to uppercase. > 5. Locale#toLanguageTag normalizes a Locale variant field value to > lowercase. > > With this implementation, there is no backward compatibility issues. > Java users who want to make Locales compatible/exchangeable with BCP47 > language tags are recommended to use upper case variant value in Java > Locale, otherwise, roundtrip will fail. > > Do you think this solution is acceptable? If you have any objections, > please respond. > > -Yoshito > >> The API doc isn't clear at all, but the documentation gives some >> "impression" that the case is preserved for the variant argument. >> It's likely to encounter compatibility problems if we change the >> behavior. >> >> Masayoshi >> >> On 7/10/2009 3:26 AM, Yoshito Umaoka wrote: >>> Hi folks, >>> >>> Variant field in Java Locale is case sensitive. For example - >>> >>> System.out.println(new Locale("th", "TH", "TH").equals(new >>> Locale("th", "TH", "th"))); >>> System.out.println(new Locale("th", "TH", "TH").equals(new >>> Locale("th", "th", "TH"))); >>> >>> These statements print out the results - >>> >>> false >>> true >>> >>> I cannot see any descriptions about variant field casing in the API >>> doc. I think this behavior is problematic if we want to make Locale >>> to handle language tags (which is case in-sensitive) properly. I >>> propose to document that all locale fields are case insensitive and >>> change the behavior. I know this is not backward compatible, but we >>> probably should correct the behavior. >>> >>> By the way, IANA language subtag registry uses lower case letters >>> for variant subtags. And the format used in the registry is the >>> preferred casing. >>> >>> -Yoshito >>> >> > From y.umaoka at gmail.com Tue Jul 28 04:24:18 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 28 Jul 2009 07:24:18 -0400 Subject: [loc-en-dev] variant field casing In-Reply-To: <4A6EBCD6.3050007@sun.com> References: <4A56364C.3000507@gmail.com> <4A5AF14B.8030700@sun.com> <4A64B02B.2050405@gmail.com> <4A6EBCD6.3050007@sun.com> Message-ID: <4A6EDFE2.3040202@gmail.com> >Let me confirm. > >The (existing) Locale variant field and the BCP47 variant value (field) are completely separated in the API. Am I correct? Not correct. At this moment, there is no plan to change existing getVariant API and ResourceBundle behavior. New proposed Builder API has setVariant and the method set a variant field value (with BCP47 variant syntax check). -Yoshito From y.umaoka at gmail.com Tue Jul 28 16:51:39 2009 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Tue, 28 Jul 2009 19:51:39 -0400 Subject: [loc-en-dev] conf call on 7/28 Message-ID: <4A6F8F0B.9080305@gmail.com> Hi folks, I'm in Japan and trying to initiate the conf call - but had no moderator# handy. IBM VPN is up and down and I could not access the moderator# in time. For this reason, I could not start the call today.. -Yoshito From Masayoshi.Okutsu at Sun.COM Tue Jul 28 19:55:20 2009 From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu) Date: Wed, 29 Jul 2009 11:55:20 +0900 Subject: [loc-en-dev] variant field casing In-Reply-To: <4A6EDFE2.3040202@gmail.com> References: <4A56364C.3000507@gmail.com> <4A5AF14B.8030700@sun.com> <4A64B02B.2050405@gmail.com> <4A6EBCD6.3050007@sun.com> <4A6EDFE2.3040202@gmail.com> Message-ID: <4A6FBA18.4030208@sun.com> Let me ask another question. If you do: Locale locale = new Locale.Builder().setLanguage("es").setRegion("ES").setVariant("Traditional_WIN").create(); System.out.println(locale.getVariant()); what will that produce? ("Traditional_WIN" is an example from the Locale API doc.) Thanks, Masayoshi On 7/28/2009 8:24 PM, Yoshito Umaoka wrote: > >Let me confirm. > > > >The (existing) Locale variant field and the BCP47 variant value > (field) are completely separated in the API. Am I correct? > > Not correct. At this moment, there is no plan to change existing > getVariant API and ResourceBundle behavior. New proposed Builder API > has setVariant and the method set a variant field value (with BCP47 > variant syntax check). > > -Yoshito