From gitne at gmx.de Mon Mar 9 20:10:27 2015 From: gitne at gmx.de (Jacob Wisor) Date: Mon, 09 Mar 2015 21:10:27 +0100 Subject: RFR [jdk8u-dev]: Add pl localization to jar tool Message-ID: <54FDFE33.4070202@gmx.de> Hello there! I have added pl localization to the JAR tool. However, I did not find the make/common/Defs.gmk file which is referenced here: http://openjdk.java.net/groups/i18n. Please review this patch. More tools are coming! ;-) Regards, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: Add pl localization of JAR tool.patch Type: text/x-patch Size: 4554 bytes Desc: not available URL: From gitne at gmx.de Mon Mar 9 20:12:43 2015 From: gitne at gmx.de (Jacob Wisor) Date: Mon, 09 Mar 2015 21:12:43 +0100 Subject: RFR [jdk8u-dev/jdk]: Add de and pl localizations to native2ascii tool Message-ID: <54FDFEBB.1070501@gmx.de> Hello there! I have added de and pl localizations to the native2ascii tool. And, I have migrated the other existing localizations to property file resource bundles, just like in the other tools. Please review this patch. Regards, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: Add de and pl localizations to native2ascii tool.patch Type: text/x-patch Size: 15487 bytes Desc: not available URL: From masayoshi.okutsu at oracle.com Tue Mar 10 14:41:17 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 10 Mar 2015 23:41:17 +0900 Subject: [9] RFR: 8074791: Long-form date format incorrect month string for Finnish locale Message-ID: <54FF028D.1000007@oracle.com> Hi, Please review the fix for 8074791. This one is an oversight when introducing the format and stand-alone forms of month names in JDK 8. "ta" has been removed from the full and long date patterns. Bug report: https://bugs.openjdk.java.net/browse/JDK-8074791 Webrev: http://cr.openjdk.java.net/~okutsu/9/8074791/webrev.00 Thanks, Masayoshi From naoto.sato at oracle.com Tue Mar 10 17:01:02 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 10 Mar 2015 10:01:02 -0700 Subject: [9] RFR: 8074791: Long-form date format incorrect month string for Finnish locale In-Reply-To: <54FF028D.1000007@oracle.com> References: <54FF028D.1000007@oracle.com> Message-ID: <54FF234E.901@oracle.com> Looks good to me. Naoto On 3/10/15 7:41 AM, Masayoshi Okutsu wrote: > Hi, > > Please review the fix for 8074791. This one is an oversight when > introducing the format and stand-alone forms of month names in JDK 8. > "ta" has been removed from the full and long date patterns. > > Bug report: > https://bugs.openjdk.java.net/browse/JDK-8074791 > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8074791/webrev.00 > > Thanks, > Masayoshi > From naoto.sato at oracle.com Wed Mar 11 22:25:43 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 11 Mar 2015 15:25:43 -0700 Subject: [9] RFR: 8074350/8074351 Message-ID: <5500C0E7.4080305@oracle.com> Hello, Please review the following two enhancements in java.util.Currency class: 8074350: Support ISO 4217 "Current funds codes" table (A.2) [1] 8074351: Support for currencies with the 4 digits (or more) minor unit [2] The proposed change is located at: http://cr.openjdk.java.net/~naoto/8074350.8074351/webrev.00/ Naoto [1] https://bugs.openjdk.java.net/browse/JDK-8074350 [2] https://bugs.openjdk.java.net/browse/JDK-8074351 From masayoshi.okutsu at oracle.com Tue Mar 17 07:57:19 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 17 Mar 2015 16:57:19 +0900 Subject: [9] RFR: 8074350/8074351 In-Reply-To: <5500C0E7.4080305@oracle.com> References: <5500C0E7.4080305@oracle.com> Message-ID: <5507DE5F.9020708@oracle.com> Here are my comments. - Are there any reasons that the bit fields can't be relocated? Since the format version is changed, it should be OK to use contiguous 4 bits for fraction digits? - Use of these magic numbers should be avoided. make/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java + private static String[] currenciesWithDefinedMinorUnitDecimals = new String[10]; + for (int i = 0; i <= 9; i++) { src/java.base/share/classes/java/util/Currency.java + if (fraction > 9) { test/java/util/Currency/PropertiesTest.java + if (fraction > 9) { Otherwise, the changes look good to me. Masayoshi On 3/12/2015 7:25 AM, Naoto Sato wrote: > Hello, > > Please review the following two enhancements in java.util.Currency class: > > 8074350: Support ISO 4217 "Current funds codes" table (A.2) [1] > 8074351: Support for currencies with the 4 digits (or more) minor unit > [2] > > The proposed change is located at: > > http://cr.openjdk.java.net/~naoto/8074350.8074351/webrev.00/ > > Naoto > > [1] https://bugs.openjdk.java.net/browse/JDK-8074350 > [2] https://bugs.openjdk.java.net/browse/JDK-8074351 From naoto.sato at oracle.com Tue Mar 17 20:10:21 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 17 Mar 2015 13:10:21 -0700 Subject: [9] RFR: 8074350/8074351 In-Reply-To: <5507DE5F.9020708@oracle.com> References: <5500C0E7.4080305@oracle.com> <5507DE5F.9020708@oracle.com> Message-ID: <55088A2D.20607@oracle.com> Thanks. I modified the change based on your suggestion: http://cr.openjdk.java.net/~naoto/8074350.8074351/webrev.01/ Naoto On 3/17/15 12:57 AM, Masayoshi Okutsu wrote: > Here are my comments. > > - Are there any reasons that the bit fields can't be relocated? Since > the format version is changed, it should be OK to use contiguous 4 bits > for fraction digits? > > - Use of these magic numbers should be avoided. > > make/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java > + private static String[] currenciesWithDefinedMinorUnitDecimals = > new String[10]; > + for (int i = 0; i <= 9; i++) { > src/java.base/share/classes/java/util/Currency.java > + if (fraction > 9) { > test/java/util/Currency/PropertiesTest.java > + if (fraction > 9) { > > Otherwise, the changes look good to me. > > Masayoshi > > On 3/12/2015 7:25 AM, Naoto Sato wrote: >> Hello, >> >> Please review the following two enhancements in java.util.Currency class: >> >> 8074350: Support ISO 4217 "Current funds codes" table (A.2) [1] >> 8074351: Support for currencies with the 4 digits (or more) minor unit >> [2] >> >> The proposed change is located at: >> >> http://cr.openjdk.java.net/~naoto/8074350.8074351/webrev.00/ >> >> Naoto >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8074350 >> [2] https://bugs.openjdk.java.net/browse/JDK-8074351 > From masayoshi.okutsu at oracle.com Tue Mar 17 22:54:55 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 18 Mar 2015 07:54:55 +0900 Subject: [9] RFR: 8074350/8074351 In-Reply-To: <55088A2D.20607@oracle.com> References: <5500C0E7.4080305@oracle.com> <5507DE5F.9020708@oracle.com> <55088A2D.20607@oracle.com> Message-ID: <5508B0BF.4060406@oracle.com> Looks good to me. Masayoshi On 3/18/2015 5:10 AM, Naoto Sato wrote: > Thanks. I modified the change based on your suggestion: > > http://cr.openjdk.java.net/~naoto/8074350.8074351/webrev.01/ > > Naoto > > On 3/17/15 12:57 AM, Masayoshi Okutsu wrote: >> Here are my comments. >> >> - Are there any reasons that the bit fields can't be relocated? Since >> the format version is changed, it should be OK to use contiguous 4 bits >> for fraction digits? >> >> - Use of these magic numbers should be avoided. >> >> make/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java >> >> + private static String[] currenciesWithDefinedMinorUnitDecimals = >> new String[10]; >> + for (int i = 0; i <= 9; i++) { >> src/java.base/share/classes/java/util/Currency.java >> + if (fraction > 9) { >> test/java/util/Currency/PropertiesTest.java >> + if (fraction > 9) { >> >> Otherwise, the changes look good to me. >> >> Masayoshi >> >> On 3/12/2015 7:25 AM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the following two enhancements in java.util.Currency >>> class: >>> >>> 8074350: Support ISO 4217 "Current funds codes" table (A.2) [1] >>> 8074351: Support for currencies with the 4 digits (or more) minor unit >>> [2] >>> >>> The proposed change is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8074350.8074351/webrev.00/ >>> >>> Naoto >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8074350 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8074351 >> From gitne at gmx.de Wed Mar 18 23:07:30 2015 From: gitne at gmx.de (Jacob Wisor) Date: Thu, 19 Mar 2015 00:07:30 +0100 Subject: [jdk9] RFR: Add de and pl localizations to native2ascii tool In-Reply-To: <54FDFEBB.1070501@gmx.de> References: <54FDFEBB.1070501@gmx.de> Message-ID: <550A0532.4030101@gmx.de> Ping? I have migrated the patch to JDK 9, so this may be easier to review. This patch also fixes JDK-6568430 and some formatting. Please review. Thanks! Regards, Jacob On 03/09/2015 09:12 PM, Jacob Wisor wrote: > Hello there! > > I have added de and pl localizations to the native2ascii tool. And, I have > migrated the other existing localizations to property file resource bundles, > just like in the other tools. > > Please review this patch. > > Regards, > > Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: native2ascii.patch Type: text/x-patch Size: 25413 bytes Desc: not available URL: From masayoshi.okutsu at oracle.com Tue Mar 24 09:29:11 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 24 Mar 2015 18:29:11 +0900 Subject: [9] RFR: 8075173: DateFormat in german locale returns wrong value for month march Message-ID: <55112E67.6050003@oracle.com> Hi, Please review the fix for 8075173. There's an inconsistent month abbreviation between the traditional JDK resources and CLDR-derived ones. We decided to take the CLDR one, M?r. Bug report: https://bugs.openjdk.java.net/browse/JDK-8075173 Webrev: http://cr.openjdk.java.net/~okutsu/9/8075173/webrev.00/ Thanks, Masayoshi From gitne at gmx.de Tue Mar 24 16:12:12 2015 From: gitne at gmx.de (Jacob Wisor) Date: Tue, 24 Mar 2015 17:12:12 +0100 Subject: [9] RFR: 8075173: DateFormat in german locale returns wrong value for month march In-Reply-To: <55112E67.6050003@oracle.com> References: <55112E67.6050003@oracle.com> Message-ID: <55118CDC.1090105@gmx.de> Am 24.03.2015 um 10:29 schrieb Masayoshi Okutsu: > Hi, > > Please review the fix for 8075173. There's an inconsistent month abbreviation > between the traditional JDK resources and CLDR-derived ones. We decided to take > the CLDR one, M?r. After looking into the CLDR and comparing with some existing operating systems I am unsure whether the CLDR is actually correct, so that the abbreviated form should probably be Mrz indeed. Regardless of what some operating systems are printing, it just looks strange to me that the CLDR abbreviated form of M?rz is M?r. Usually, ??? (the umlauts) are dropped first when building abbreviated forms because they are an abbreviation themselves already and they should also be avoided in abbreviations in general. ? is short for AE, ? for OE, and ? for UE. The German judiciary system and the military are probably the heaviest users of abbreviations and the German language. And, while doing so they typically avoid having any umlauts or ? (U+00DF small letter sharp S) in any abbreviations. As always, I may be wrong and the DIN 5008 norm does sufficiently specify abbreviated month names. However, I do not have access to the full DIN 5008 text to verify because it is behind a pay wall. It is also very likely that the German administration (the bureaucracy) has evolved some "proper" form of abbreviation for months because it is full of abbreviations. However, a DIN or any German administrative regulation would apply to the de_DE locale only. I do not know how to deal with the default de locale and the other de_XX locales in this case. But, if Java is to follow the CLDR blindly then this discussions is obsolete, I guess. ;-) Regards, Jacob From gitne at gmx.de Tue Mar 24 16:37:04 2015 From: gitne at gmx.de (Jacob Wisor) Date: Tue, 24 Mar 2015 17:37:04 +0100 Subject: [9] RFR: 8075173: DateFormat in german locale returns wrong value for month march In-Reply-To: <55118CDC.1090105@gmx.de> References: <55112E67.6050003@oracle.com> <55118CDC.1090105@gmx.de> Message-ID: <551192B0.9050107@gmx.de> Am 24.03.2015 um 17:12 schrieb Jacob Wisor: > Am 24.03.2015 um 10:29 schrieb Masayoshi Okutsu: >> Hi, >> >> Please review the fix for 8075173. There's an inconsistent month abbreviation >> between the traditional JDK resources and CLDR-derived ones. We decided to take >> the CLDR one, M?r. > > After looking into the CLDR and comparing with some existing operating systems I > am unsure whether the CLDR is actually correct, so that the abbreviated form > should probably be Mrz indeed. > > Regardless of what some operating systems are printing, it just looks strange to > me that the CLDR abbreviated form of M?rz is M?r. Usually, ??? (the umlauts) are > dropped first when building abbreviated forms because they are an abbreviation > themselves already and they should also be avoided in abbreviations in general. > ? is short for AE, ? for OE, and ? for UE. The German judiciary system and the > military are probably the heaviest users of abbreviations and the German > language. And, while doing so they typically avoid having any umlauts or ? > (U+00DF small letter sharp S) in any abbreviations. > > As always, I may be wrong and the DIN 5008 norm does sufficiently specify > abbreviated month names. However, I do not have access to the full DIN 5008 text > to verify because it is behind a pay wall. It is also very likely that the > German administration (the bureaucracy) has evolved some "proper" form of > abbreviation for months because it is full of abbreviations. However, a DIN or > any German administrative regulation would apply to the de_DE locale only. I do > not know how to deal with the default de locale and the other de_XX locales in > this case. > > But, if Java is to follow the CLDR blindly then this discussions is obsolete, I > guess. ;-) Hmm, according to http://www.din-5008-richtlinien.de/datum.php "M?r." should be actually correct. So, the CLDR seems to be correct but missing the dot suffix. But then, the CLDR may have a policy on suffixes to abbreviations and this patch looks to be okay then. Regards, Jacob From michael.fang at oracle.com Tue Mar 24 17:31:24 2015 From: michael.fang at oracle.com (Michael Fang) Date: Tue, 24 Mar 2015 10:31:24 -0700 Subject: RFR [jdk8u-dev]: Add pl localization to jar tool In-Reply-To: <54FDFE33.4070202@gmx.de> References: <54FDFE33.4070202@gmx.de> Message-ID: <55119F6C.3090905@oracle.com> Hi Jabob, Thank you very much for contributing to the translation of native2ascii tool and jar tool. The information displayed on http://openjdk.java.net/groups/i18n was created prior to JDK8. Due to Makefile updates, the localization instruction does not work anymore. We need to fix this page ASAP. Currently, we are not able to support additional language translation in OpenJDK bundles without also including them in Oracle JDK bundles. To add additional localization to your environment, you could create a jar file with translated resource files and place the jar file under /lib/ext directory (works up to JDK8). thanks, -michael On 2015?03?09? 13:10, Jacob Wisor wrote: > Hello there! > > I have added pl localization to the JAR tool. However, I did not find > the make/common/Defs.gmk file which is referenced here: > http://openjdk.java.net/groups/i18n. > > Please review this patch. More tools are coming! ;-) > > Regards, > > Jacob From michael.fang at oracle.com Tue Mar 24 17:33:19 2015 From: michael.fang at oracle.com (Michael Fang) Date: Tue, 24 Mar 2015 10:33:19 -0700 Subject: RFR [jdk8u-dev]: Add pl localization to jar tool In-Reply-To: <55119F6C.3090905@oracle.com> References: <54FDFE33.4070202@gmx.de> <55119F6C.3090905@oracle.com> Message-ID: <55119FDF.7020909@oracle.com> Sorry for typo in your name, Jacob. -michael On 2015?03?24? 10:31, Michael Fang wrote: > Hi Jabob, > > Thank you very much for contributing to the translation of > native2ascii tool and jar tool. > > The information displayed on http://openjdk.java.net/groups/i18n was > created prior to JDK8. Due to Makefile updates, the localization > instruction does not work anymore. We need to fix this page ASAP. > > Currently, we are not able to support additional language translation > in OpenJDK bundles without also including them in Oracle JDK bundles. > To add additional localization to your environment, you could create a > jar file with translated resource files and place the jar file under > /lib/ext directory (works up to JDK8). > > thanks, > > -michael > > > On 2015?03?09? 13:10, Jacob Wisor wrote: >> Hello there! >> >> I have added pl localization to the JAR tool. However, I did not find >> the make/common/Defs.gmk file which is referenced here: >> http://openjdk.java.net/groups/i18n. >> >> Please review this patch. More tools are coming! ;-) >> >> Regards, >> >> Jacob From gitne at gmx.de Tue Mar 24 22:14:28 2015 From: gitne at gmx.de (Jacob Wisor) Date: Tue, 24 Mar 2015 23:14:28 +0100 Subject: RFR [jdk8u-dev]: Add pl localization to jar tool In-Reply-To: <55119F6C.3090905@oracle.com> References: <54FDFE33.4070202@gmx.de> <55119F6C.3090905@oracle.com> Message-ID: <5511E1C4.60604@gmx.de> Hello Michael, Am 24.03.2015 um 18:31 schrieb Michael Fang: > Hi Jabob, > > Thank you very much for contributing to the translation of native2ascii tool and > jar tool. > > The information displayed on http://openjdk.java.net/groups/i18n was created > prior to JDK8. Due to Makefile updates, the localization instruction does not > work anymore. We need to fix this page ASAP. Yeah, I have noticed this too, right after I had localized sun/tools/javac/resources/javac.properties only to find out that it is used by the outdated compiler only. I should have started with com/sun/tools/javac/resources/javac.properties. But anyway, now I have localized them both. > Currently, we are not able to support additional language translation in OpenJDK > bundles without also including them in Oracle JDK bundles. Why is this a problem? Everybody is free to use OpenJDK in their products, including Oracle. And, if you are referring to the fact that additional localizations may possibly require additional customer support then I will have to disappoint you: Various currently "supported" localizations are incomplete in various places, tools, and components, eg. like de or sv. So, "requiring additional support" is actually an invalid argument. Another possibility for Oracle - if Oracle /really/ wants to waste existing language support - is to foster a build infrastructure that drops localization support for certain locales at build time. It is odd and perhaps inconvenient but possible. > To add additional localization to your environment, you could create a jar file with translated > resource files and place the jar file under /lib/ext directory (works > up to JDK8). Yes, I know. But, this would be rather tedious for many people to install. Besides, this/these multi-language JAR file(s) would have to be hosted somewhere for people to find and download easily. Including all localizations into OpenJDK and then perhaps excluding them for Oracle JDK is probably the best way to go. Regards, Jacob > On 2015?03?09? 13:10, Jacob Wisor wrote: >> Hello there! >> >> I have added pl localization to the JAR tool. However, I did not find the >> make/common/Defs.gmk file which is referenced here: >> http://openjdk.java.net/groups/i18n. >> >> Please review this patch. More tools are coming! ;-) >> >> Regards, >> >> Jacob From naoto.sato at oracle.com Wed Mar 25 00:36:12 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 24 Mar 2015 17:36:12 -0700 Subject: [9] RFR: 8075173: DateFormat in german locale returns wrong value for month march In-Reply-To: <55112E67.6050003@oracle.com> References: <55112E67.6050003@oracle.com> Message-ID: <551202FC.8090209@oracle.com> Looks good to me. Naoto On 3/24/15 2:29 AM, Masayoshi Okutsu wrote: > Hi, > > Please review the fix for 8075173. There's an inconsistent month > abbreviation between the traditional JDK resources and CLDR-derived > ones. We decided to take the CLDR one, M?r. > > Bug report: > https://bugs.openjdk.java.net/browse/JDK-8075173 > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8075173/webrev.00/ > > Thanks, > Masayoshi From yuka.kamiya at oracle.com Wed Mar 25 04:49:34 2015 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Wed, 25 Mar 2015 13:49:34 +0900 Subject: [9] RFR: 8075173: DateFormat in german locale returns wrong value for month march In-Reply-To: <55112E67.6050003@oracle.com> References: <55112E67.6050003@oracle.com> Message-ID: <55123E5E.1010505@oracle.com> Hi, The fix looks good to me. Thanks, -- Yuka On 2015/03/24 18:29, Masayoshi Okutsu wrote: > Hi, > > Please review the fix for 8075173. There's an inconsistent month > abbreviation between the traditional JDK resources and CLDR-derived > ones. We decided to take the CLDR one, M?r. > > Bug report: > https://bugs.openjdk.java.net/browse/JDK-8075173 > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8075173/webrev.00/ > > Thanks, > Masayoshi From masayoshi.okutsu at oracle.com Wed Mar 25 08:27:44 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 25 Mar 2015 17:27:44 +0900 Subject: [9] RFR: 8075173: DateFormat in german locale returns wrong value for month march In-Reply-To: <551192B0.9050107@gmx.de> References: <55112E67.6050003@oracle.com> <55118CDC.1090105@gmx.de> <551192B0.9050107@gmx.de> Message-ID: <55127180.1000204@oracle.com> Hello Jacob, Thank you for your input. We plan to switch the default source of locale-dependent resources from the legacy JDK data to CLDR in JDK 9. So, it's likely we will follow CLDR blindly. :-) Thanks, Masayoshi On 3/25/2015 1:37 AM, Jacob Wisor wrote: > Am 24.03.2015 um 17:12 schrieb Jacob Wisor: >> Am 24.03.2015 um 10:29 schrieb Masayoshi Okutsu: >>> Hi, >>> >>> Please review the fix for 8075173. There's an inconsistent month >>> abbreviation >>> between the traditional JDK resources and CLDR-derived ones. We >>> decided to take >>> the CLDR one, M?r. >> >> After looking into the CLDR and comparing with some existing >> operating systems I >> am unsure whether the CLDR is actually correct, so that the >> abbreviated form >> should probably be Mrz indeed. >> >> Regardless of what some operating systems are printing, it just looks >> strange to >> me that the CLDR abbreviated form of M?rz is M?r. Usually, ??? (the >> umlauts) are >> dropped first when building abbreviated forms because they are an >> abbreviation >> themselves already and they should also be avoided in abbreviations >> in general. >> ? is short for AE, ? for OE, and ? for UE. The German judiciary >> system and the >> military are probably the heaviest users of abbreviations and the German >> language. And, while doing so they typically avoid having any umlauts >> or ? >> (U+00DF small letter sharp S) in any abbreviations. >> >> As always, I may be wrong and the DIN 5008 norm does sufficiently >> specify >> abbreviated month names. However, I do not have access to the full >> DIN 5008 text >> to verify because it is behind a pay wall. It is also very likely >> that the >> German administration (the bureaucracy) has evolved some "proper" >> form of >> abbreviation for months because it is full of abbreviations. However, >> a DIN or >> any German administrative regulation would apply to the de_DE locale >> only. I do >> not know how to deal with the default de locale and the other de_XX >> locales in >> this case. >> >> But, if Java is to follow the CLDR blindly then this discussions is >> obsolete, I >> guess. ;-) > > Hmm, according to http://www.din-5008-richtlinien.de/datum.php "M?r." > should be actually correct. So, the CLDR seems to be correct but > missing the dot suffix. But then, the CLDR may have a policy on > suffixes to abbreviations and this patch looks to be okay then. > > Regards, > Jacob From michael.fang at oracle.com Thu Mar 26 00:01:31 2015 From: michael.fang at oracle.com (Michael Fang) Date: Wed, 25 Mar 2015 17:01:31 -0700 Subject: RFR [jdk8u-dev]: Add pl localization to jar tool In-Reply-To: <5511E1C4.60604@gmx.de> References: <54FDFE33.4070202@gmx.de> <55119F6C.3090905@oracle.com> <5511E1C4.60604@gmx.de> Message-ID: <55134C5B.6030008@oracle.com> Hi Jacob, Thank you for your reply. According to http://www.oracle.com/technetwork/java/javase/java8locales-2095355.html, User Interface translation for JRE and JDK are different. JDK "tools" (ex: "javac", "native2ascii", "javadoc") are translated to ja and zh_CN only (except "jar"). JRE resources are translated to 10 languages. These languages are "supported" because we have linguistic resource to support them if bugs are filed. thanks, -michael On 2015?03?24? 15:14, Jacob Wisor wrote: > Hello Michael, > > Am 24.03.2015 um 18:31 schrieb Michael Fang: >> Hi Jabob, >> >> Thank you very much for contributing to the translation of >> native2ascii tool and >> jar tool. >> >> The information displayed on http://openjdk.java.net/groups/i18n was >> created >> prior to JDK8. Due to Makefile updates, the localization instruction >> does not >> work anymore. We need to fix this page ASAP. > > Yeah, I have noticed this too, right after I had localized > sun/tools/javac/resources/javac.properties only to find out that it is > used by the outdated compiler only. I should have started with > com/sun/tools/javac/resources/javac.properties. But anyway, now I have > localized them both. > >> Currently, we are not able to support additional language translation >> in OpenJDK >> bundles without also including them in Oracle JDK bundles. > > Why is this a problem? Everybody is free to use OpenJDK in their > products, including Oracle. And, if you are referring to the fact that > additional localizations may possibly require additional customer > support then I will have to disappoint you: Various currently > "supported" localizations are incomplete in various places, tools, and > components, eg. like de or sv. So, "requiring additional support" is > actually an invalid argument. > > Another possibility for Oracle - if Oracle /really/ wants to waste > existing language support - is to foster a build infrastructure that > drops localization support for certain locales at build time. It is > odd and perhaps inconvenient but possible. > >> To add additional localization to your environment, you could create >> a jar file with translated >> resource files and place the jar file under /lib/ext >> directory (works >> up to JDK8). > > Yes, I know. But, this would be rather tedious for many people to > install. Besides, this/these multi-language JAR file(s) would have to > be hosted somewhere for people to find and download easily. Including > all localizations into OpenJDK and then perhaps excluding them for > Oracle JDK is probably the best way to go. > > Regards, > Jacob > >> On 2015?03?09? 13:10, Jacob Wisor wrote: >>> Hello there! >>> >>> I have added pl localization to the JAR tool. However, I did not >>> find the >>> make/common/Defs.gmk file which is referenced here: >>> http://openjdk.java.net/groups/i18n. >>> >>> Please review this patch. More tools are coming! ;-) >>> >>> Regards, >>> >>> Jacob From aleksej.efimov at oracle.com Thu Mar 26 15:47:39 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 26 Mar 2015 18:47:39 +0300 Subject: RFR: 8075667: (tz) Support tzdata2015b Message-ID: <55142A1B.1070600@oracle.com> Hi, Please review the fix for adding the latest tzdata2015b to JDK9. The JTREG and JPRT tests were executed. No failures were observed, except one: test/sun/util/calendar/zi/TestZoneInfo310.java The failure was caused by the following tzdb rule addition to make/data/tzdata/asia: +Rule Palestine 2015 max - Mar lastFri 24:00 1:00 S And it was addressed by addition of another piece of workaround code to src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java. After this changes the test showed the PASS result. Thank you, Aleksej [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8075667 [2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015b/9/00 From masayoshi.okutsu at oracle.com Fri Mar 27 04:13:15 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 27 Mar 2015 13:13:15 +0900 Subject: RFR: 8075667: (tz) Support tzdata2015b In-Reply-To: <55142A1B.1070600@oracle.com> References: <55142A1B.1070600@oracle.com> Message-ID: <5514D8DB.1010204@oracle.com> Looks good except that data changes keep requiring additional workaround to the run-time code. We do need a fix for JDK-8014468. Masayoshi On 3/27/2015 12:47 AM, Aleksej Efimov wrote: > Hi, > > Please review the fix for adding the latest tzdata2015b to JDK9. > The JTREG and JPRT tests were executed. > No failures were observed, except one: > test/sun/util/calendar/zi/TestZoneInfo310.java > The failure was caused by the following tzdb rule addition to > make/data/tzdata/asia: > +Rule Palestine 2015 max - Mar lastFri 24:00 > 1:00 S > And it was addressed by addition of another piece of workaround code > to src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java. > After this changes the test showed the PASS result. > > Thank you, > Aleksej > > [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8075667 > [2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015b/9/00 From masayoshi.okutsu at oracle.com Fri Mar 27 08:48:58 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 27 Mar 2015 17:48:58 +0900 Subject: [9] RFR: 8075548: SimpleDateFormat formatting of "LLLL" in English is incorrect; should be identical to "MMMM" Message-ID: <5515197A.9060401@oracle.com> Hi, Please review the fix for 8075548. This change is to follow the fallback rules of the format-standalone names specified by the alias tag in CLDR. Bug report: https://bugs.openjdk.java.net/browse/JDK-8075548 Webrev: http://cr.openjdk.java.net/~okutsu/9/8075548/webrev.00 Thanks, Masayoshi From martinrb at google.com Fri Mar 27 19:31:05 2015 From: martinrb at google.com (Martin Buchholz) Date: Fri, 27 Mar 2015 12:31:05 -0700 Subject: [9] RFR: 8075548: SimpleDateFormat formatting of "LLLL" in English is incorrect; should be identical to "MMMM" In-Reply-To: <5515197A.9060401@oracle.com> References: <5515197A.9060401@oracle.com> Message-ID: Don't know much about Calendar, but: do you want below to try fallback twice? Eg. if it's still null after trying toStandaloneStyle(style), do you want to also try fallback to getBaseStyle(style) ? 2093 // Perform fallback here to follow the CLDR rules2094 if (val == null) {2095 if (isNarrowFormatStyle(style)) {2096 val = CalendarDataUtility.retrieveFieldValueName(calendarType,2097 field, fieldValue,2098 toStandaloneStyle(style),2099 locale);2100 } else if (isStandaloneStyle(style)) {2101 val = CalendarDataUtility.retrieveFieldValueName(calendarType,2102 field, fieldValue,2103 getBaseStyle(style),2104 locale);2105 }2106 } On Fri, Mar 27, 2015 at 1:48 AM, Masayoshi Okutsu < masayoshi.okutsu at oracle.com> wrote: > Hi, > > Please review the fix for 8075548. This change is to follow the fallback > rules of the format-standalone names specified by the alias tag in CLDR. > > Bug report: > https://bugs.openjdk.java.net/browse/JDK-8075548 > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8075548/webrev.00 > > Thanks, > Masayoshi > From naoto.sato at oracle.com Fri Mar 27 22:39:12 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 27 Mar 2015 15:39:12 -0700 Subject: [9] RFR: 8075548: SimpleDateFormat formatting of "LLLL" in English is incorrect; should be identical to "MMMM" In-Reply-To: References: <5515197A.9060401@oracle.com> Message-ID: <5515DC10.5050109@oracle.com> Hi Martin, I am not a Calendar expert, but I'd think if a query for narrow names fails, in some cases it would be useful not to fall back to longer names, say weekday names in chinese, ???..???or something like that. If they were mistakenly displayed at the calendar title row, it could all display '?' in that narrow field which seems meaningless. BTW, the fix looks good to me, Masayoshi. Naoto On 3/27/15 12:31 PM, Martin Buchholz wrote: > Don't know much about Calendar, but: > > do you want below to try fallback twice? Eg. if it's still null after > trying toStandaloneStyle(style), do you want to also try fallback to > getBaseStyle(style) ? > > 2093 // Perform fallback here to follow the CLDR rules2094 > if (val == null) {2095 if > (isNarrowFormatStyle(style)) {2096 val = > CalendarDataUtility.retrieveFieldValueName(calendarType,2097 > field, > fieldValue,2098 > toStandaloneStyle(style),2099 > locale);2100 > } else if (isStandaloneStyle(style)) {2101 val = > CalendarDataUtility.retrieveFieldValueName(calendarType,2102 > field, > fieldValue,2103 > getBaseStyle(style),2104 > locale);2105 > }2106 } > > > > On Fri, Mar 27, 2015 at 1:48 AM, Masayoshi Okutsu < > masayoshi.okutsu at oracle.com> wrote: > >> Hi, >> >> Please review the fix for 8075548. This change is to follow the fallback >> rules of the format-standalone names specified by the alias tag in CLDR. >> >> Bug report: >> https://bugs.openjdk.java.net/browse/JDK-8075548 >> Webrev: >> http://cr.openjdk.java.net/~okutsu/9/8075548/webrev.00 >> >> Thanks, >> Masayoshi >> From masayoshi.okutsu at oracle.com Mon Mar 30 05:02:45 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 30 Mar 2015 14:02:45 +0900 Subject: [9] RFR: 8075548: SimpleDateFormat formatting of "LLLL" in English is incorrect; should be identical to "MMMM" In-Reply-To: References: <5515197A.9060401@oracle.com> Message-ID: <5518D8F5.1010800@oracle.com> There are only two (context) forms of styles: FORMAT and STANDALONE. If one form fails, the fallback part will try the other form. It's not necessary to try again the first form. The code may become clearer if method toFormatStyle() was defined. But the operation is the same thing as getBaseStyle() which is used to get the width information (LONG, SHORT, NARROW) which is the same thing as its format form, e.g., Calendar.LONG == Calendar.LONG_FORMAT. Masayoshi On 3/28/2015 4:31 AM, Martin Buchholz wrote: > Don't know much about Calendar, but: > > do you want below to try fallback twice? Eg. if it's still null after > trying toStandaloneStyle(style), do you want to also try fallback to > getBaseStyle(style) ? > 2093 // Perform fallback here to follow the CLDR rules > 2094 if (val == null) { > 2095 if (isNarrowFormatStyle(style)) { > 2096 val = CalendarDataUtility.retrieveFieldValueName(calendarType, > 2097 field, fieldValue, > 2098 toStandaloneStyle(style), > 2099 locale); > 2100 } else if (isStandaloneStyle(style)) { > 2101 val = CalendarDataUtility.retrieveFieldValueName(calendarType, > 2102 field, fieldValue, > 2103 getBaseStyle(style), > 2104 locale); > 2105 } > 2106 } > > > On Fri, Mar 27, 2015 at 1:48 AM, Masayoshi Okutsu > > wrote: > > Hi, > > Please review the fix for 8075548. This change is to follow the > fallback rules of the format-standalone names specified by the > alias tag in CLDR. > > Bug report: > https://bugs.openjdk.java.net/browse/JDK-8075548 > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8075548/webrev.00 > > > Thanks, > Masayoshi > > From aleksej.efimov at oracle.com Mon Mar 30 12:23:36 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 30 Mar 2015 15:23:36 +0300 Subject: RFR: 8075667: (tz) Support tzdata2015b In-Reply-To: <5514D8DB.1010204@oracle.com> References: <55142A1B.1070600@oracle.com> <5514D8DB.1010204@oracle.com> Message-ID: <55194048.5070805@oracle.com> Thank you for the review Masayoshi. Agree that we need to avoid such workarounds - I will take a look at JDK-8014468 when will have some free cycles. Aleksej On 03/27/2015 07:13 AM, Masayoshi Okutsu wrote: > Looks good except that data changes keep requiring additional > workaround to the run-time code. We do need a fix for JDK-8014468. > > Masayoshi > > On 3/27/2015 12:47 AM, Aleksej Efimov wrote: >> Hi, >> >> Please review the fix for adding the latest tzdata2015b to JDK9. >> The JTREG and JPRT tests were executed. >> No failures were observed, except one: >> test/sun/util/calendar/zi/TestZoneInfo310.java >> The failure was caused by the following tzdb rule addition to >> make/data/tzdata/asia: >> +Rule Palestine 2015 max - Mar lastFri 24:00 >> 1:00 S >> And it was addressed by addition of another piece of workaround code >> to src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java. >> After this changes the test showed the PASS result. >> >> Thank you, >> Aleksej >> >> [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8075667 >> [2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015b/9/00 > From mandy.chung at oracle.com Mon Mar 30 21:37:00 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Mar 2015 14:37:00 -0700 Subject: native2ascii be removed from JDK? Message-ID: <5519C1FC.6010303@oracle.com> There are several existing ways to do native to ascii conversion. For example, IDEs like NetBeans and IntelliJ support the transparent native-to-ascii conversion. There is also maven native 2 ascii plugin. JEP 226 proposes to support UTF Properties file that will address the original motivation of creating the native2ascii tool. While native2ascii used to be a convenient tool for some developers to use, it may be time to remove it in JDK 9 and developers can use IDEs and Maven plugin and other build tools. Any thought? Mandy From joe.darcy at oracle.com Mon Mar 30 22:26:05 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 30 Mar 2015 15:26:05 -0700 Subject: native2ascii be removed from JDK? In-Reply-To: <5519C1FC.6010303@oracle.com> References: <5519C1FC.6010303@oracle.com> Message-ID: <5519CD7D.4000703@oracle.com> Hi Mandy, If there is agreement on this internally, I suggest floating a trial balloon on jdk9-dev. Cheers, -Joe On 3/30/2015 2:37 PM, Mandy Chung wrote: > There are several existing ways to do native to ascii conversion. For > example, IDEs like NetBeans and IntelliJ support the transparent > native-to-ascii conversion. There is also maven native 2 ascii plugin. > > JEP 226 proposes to support UTF Properties file that will address the > original motivation of creating the native2ascii tool. > > While native2ascii used to be a convenient tool for some developers to > use, it may be time to remove it in JDK 9 and developers can use IDEs > and Maven plugin and other build tools. > > Any thought? > > Mandy From martinrb at google.com Mon Mar 30 22:29:39 2015 From: martinrb at google.com (Martin Buchholz) Date: Mon, 30 Mar 2015 15:29:39 -0700 Subject: [9] RFR: 8075548: SimpleDateFormat formatting of "LLLL" in English is incorrect; should be identical to "MMMM" In-Reply-To: <5518D8F5.1010800@oracle.com> References: <5515197A.9060401@oracle.com> <5518D8F5.1010800@oracle.com> Message-ID: Thanks! I never did succeed in understanding the fallback logic... there might be ways to make the code more obviously correct later. On Sun, Mar 29, 2015 at 10:02 PM, Masayoshi Okutsu < masayoshi.okutsu at oracle.com> wrote: > There are only two (context) forms of styles: FORMAT and STANDALONE. If > one form fails, the fallback part will try the other form. It's not > necessary to try again the first form. > > The code may become clearer if method toFormatStyle() was defined. But the > operation is the same thing as getBaseStyle() which is used to get the > width information (LONG, SHORT, NARROW) which is the same thing as its > format form, e.g., Calendar.LONG == Calendar.LONG_FORMAT. > > Masayoshi > > > On 3/28/2015 4:31 AM, Martin Buchholz wrote: > > Don't know much about Calendar, but: > > do you want below to try fallback twice? Eg. if it's still null after > trying toStandaloneStyle(style), do you want to also try fallback to > getBaseStyle(style) ? > > 2093 // Perform fallback here to follow the CLDR rules2094 if (val == null) {2095 if (isNarrowFormatStyle(style)) {2096 val = CalendarDataUtility.retrieveFieldValueName(calendarType,2097 field, fieldValue,2098 toStandaloneStyle(style),2099 locale);2100 } else if (isStandaloneStyle(style)) {2101 val = CalendarDataUtility.retrieveFieldValueName(calendarType,2102 field, fieldValue,2103 getBaseStyle(style),2104 locale);2105 }2106 } > > > > On Fri, Mar 27, 2015 at 1:48 AM, Masayoshi Okutsu < > masayoshi.okutsu at oracle.com> wrote: > >> Hi, >> >> Please review the fix for 8075548. This change is to follow the fallback >> rules of the format-standalone names specified by the alias tag in CLDR. >> >> Bug report: >> https://bugs.openjdk.java.net/browse/JDK-8075548 >> Webrev: >> http://cr.openjdk.java.net/~okutsu/9/8075548/webrev.00 >> >> Thanks, >> Masayoshi >> > > >