Re: RFR: 8333582: Update CLDR to Version 46.0
On Tue, 29 Oct 2024 18:12:43 GMT, Naoto Sato wrote: > Upgrading the CLDR to version 46.0. A corresponding CSR has also been drafted. Spot checked the data and tests. Checked the provider changes, all LGTM. - Marked as reviewed by srl (Committer). PR Review: https://git.openjdk.org/jdk/pull/21772#pullrequestreview-2403110449
Re: RFR: 8341684: Typo in External Specifications link of java.util.Currency [v2]
On Wed, 9 Oct 2024 00:08:30 GMT, Justin Lu wrote: >> A trivial correction to the _j.util.Currency_ external specification ISO >> currency codes link. Browsers will auto resolve and correct the link, but it >> should still be fixed regardless. > > Justin Lu has updated the pull request incrementally with one additional > commit since the last revision: > > review: correct link Marked as reviewed by srl (Committer). - PR Review: https://git.openjdk.org/jdk/pull/21416#pullrequestreview-2357806205
Re: RFR: 8334653: ISO 4217 Amendment 177 Update [v3]
On Fri, 21 Jun 2024 01:58:05 GMT, Naoto Sato wrote: > Out of curiosity, what's the rationale behind the currency name change from > "Zimbabwe Dollar" (ISO 4217 definition) to "Zimbabwean Dollar"? I'm not sure. - PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1673107271
Re: RFR: 8334653: ISO 4217 Amendment 177 Update [v3]
On Thu, 20 Jun 2024 19:47:56 GMT, Naoto Sato wrote: >> I see your point. CLDR takes precedence over ISO4217 regarding currencies >> here? > > That is more consistent IMO CLDR is aware of this change but hasn't added it yet. We're mid cycle so it won't be much more than metadata this round due to timing. https://unicode-org.atlassian.net/issues/CLDR-17751 if you want to track. - PR Review Comment: https://git.openjdk.org/jdk/pull/19813#discussion_r1648094193
Re: RFR: 8334418: Update IANA Language Subtag Registry to Version 2024-06-14
On Mon, 17 Jun 2024 21:05:13 GMT, Justin Lu wrote: > Please review this PR, which is a trivial update of the IANA subtag registry > to version 2024-06-14. > Announcement: > https://mm.icann.org/pipermail/ietf-languages-announcements/2024-June/92.html Marked as reviewed by srl (Committer). - PR Review: https://git.openjdk.org/jdk/pull/19757#pullrequestreview-2125966725
Re: RFR: 8331866: Add warnings for locale data dependence [v2]
On Thu, 9 May 2024 17:58:34 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line >> 157: >> >>> 155: * Note that the CLDR locale data are subject to change. Users should >>> not assume >>> 156: * that the locale data remain the same across CLDR versions. >>> Otherwise, unexpected >>> 157: * incompatible behaviors may occur, such as an exception on parsing a >>> date. >> >> For those wondering what has changed from one version to another or whether >> a particular change might have an impact after reading this note, I wonder >> if some kind of notes or links might be helpful. A column to the table below >> to add some notes? I'm sure they can always look at the CLDR release notes. >> Just wonder if there's anything specific worth noting or a link. > > IMHO, adding an extra column to describe what has changed in CLDR would seem > impractical as the significance of the changes depends on each reader. > Instead, I added a sentence to navigate readers to CLDR's releases page for > the deltas. right.. there's never "no change".. and any change could potentially break users if they are expecting identical behavior. - PR Review Comment: https://git.openjdk.org/jdk/pull/19145#discussion_r1595799429
Re: RFR: 8331866: Add warnings for locale data dependence [v2]
On Thu, 9 May 2024 17:58:21 GMT, Naoto Sato wrote: >> In order to enlighten users to not depend on a particular version of the >> locale data, putting a note into the JDK vs. CLDR version chart would be >> appropriate. > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains three additional commits since > the last revision: > > - Addresses review comment > - Merge branch 'master' into JDK-8331866-localedata-dependence-warning > - initial commit Marked as reviewed by srl (Committer). - PR Review: https://git.openjdk.org/jdk/pull/19145#pullrequestreview-2048529136
Re: RFR: 8306116: Update CLDR to Version 44.0
On Tue, 31 Oct 2023 21:06:13 GMT, Naoto Sato wrote:
> Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44).
> Besides the data upgrade, regression tests are modified to accommodate the
> following CLDR fixes:
>
> CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar
> (https://unicode-org.atlassian.net/browse/CLDR-16534)
> CLDR-17042: Use exception list for new languages
> (https://unicode-org.atlassian.net/browse/CLDR-17042)
> CLDR-16586: en_ID shows IDR rather than Rp for currency
> (https://unicode-org.atlassian.net/browse/CLDR-16586)
> CLDR-16358: Mexico and Latin America countries should be using 12 hours time
> format (https://unicode-org.atlassian.net/browse/CLDR-16358)
> CLDR-16974: en_GB and en_AU: request to remove comma from MMMd format
> (https://unicode-org.atlassian.net/browse/CLDR-16974)
> CLDR-16857: Need updated translations for new Sierra Leone currency - SLL
> became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857)
LGTM!
make/jdk/src/classes/build/tools/cldrconverter/Bundle.java line 517:
> 515: }
> 516: map.put(realKey, value);
> 517: map.put("java.time." + realKey, value);
I'm assuming this was a workaround no longer needed?
src/java.base/share/legal/cldr.md line 1:
> 1: ## Unicode Common Local Data Repository (CLDR) v44
Short and sweet!
-
Marked as reviewed by srl (Committer).
PR Review: https://git.openjdk.org/jdk/pull/16439#pullrequestreview-1721048254
PR Review Comment: https://git.openjdk.org/jdk/pull/16439#discussion_r1387059253
PR Review Comment: https://git.openjdk.org/jdk/pull/16439#discussion_r1387059522
Re: RFR: 8318322: Update IANA Language Subtag Registry to Version 2023-10-16
On Tue, 17 Oct 2023 20:06:03 GMT, Justin Lu wrote: > This change updates the IANA subtag registry to the update released on > 2023-10-16. > > Announcement -> > https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/89.html Marked as reviewed by srl (Committer). - PR Review: https://git.openjdk.org/jdk/pull/16227#pullrequestreview-1685483927
Re: RFR: 8317979: Use TZ database style abbreviations in the CLDR locale provider [v3]
On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato wrote: >> CLDR provides very few short names for time zones, such as PST/PDT. This >> will typically end up substituting names from the COMPAT provider. Once the >> COMPAT is removed, they will be displayed in the GMT format, i.e., >> GMT+XX:YY. Although some of the short names in the COMPAT provider are >> somewhat questionable (less common ones are simply made up from the long >> names by taking the initials), it would not be desirable for them to fall >> back to the GMT format. >> To mitigate the situation, CLDR can use the abbreviated names from the TZ >> database, which contains legacy (major) short names as FORMAT. The CLDR >> provider can use them instead of the GMT offset style. This enhancement is a >> precursor to the future removal of the COMPAT provider. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Delay populating GMT format at runtime. Reflecting review comments. > CLDR provides very few short names for time zones, such as PST/PDT. This will > typically end up substituting names from the COMPAT provider. Once the COMPAT > is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. > Although some of the short names in the COMPAT provider are somewhat > questionable (less common ones are simply made up from the long names by > taking the initials), it would not be desirable for them to fall back to the > GMT format. To mitigate the situation, CLDR can use the abbreviated names > from the TZ database, which contains legacy (major) short names as FORMAT. > The CLDR provider can use them instead of the GMT offset style. This > enhancement is a precursor to the future removal of the COMPAT provider. This is intentional, because these short names may not be known to users. Do you have data that ja-JP, zh-CN, de-DE users expect and are familiar with `PST/PDT`? This is why CLDR fallback rules would fall back to `Los Angeles Time` for example in the longer name. It's not short, but it's understandable, and the numeric offset can work for short. I'd encourage engaging with CLDR-TC to discuss the short names upstream if you have data on the recognizability of these short names. In fact, CLDR probably has _too many_ short names for zones. - PR Comment: https://git.openjdk.org/jdk/pull/16206#issuecomment-1767240212
Re: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
On Tue, 19 Sep 2023 18:53:30 GMT, Naoto Sato wrote: >> look at https://www.unicode.org/Public/UCD/latest/ for example, it points >> you only to license.txt. > > We are checking on it and will update it if necessary. it was unnecessary to mention copyright.html or terms of use in the source license previously - PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330573202
Re: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v5]
On Tue, 19 Sep 2023 18:55:28 GMT, Naoto Sato wrote:
>> This PR is to incorporate the latest Unicode 15.1, which was released
>> yesterday. Besides the usual character data update, an upgraded
>> implementation of RegEx which reflects the Indic Conjunct Break specified in
>> the latest [Unicode Annex #29 ("Unicode Text
>> Segmentation")](https://unicode.org/reports/tr29/) is included. A
>> corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reflecting review comments
Marked as reviewed by srl (Committer).
-
PR Review: https://git.openjdk.org/jdk/pull/15728#pullrequestreview-1633987334
Re: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing should be restricted
On Mon, 18 Sep 2023 22:42:09 GMT, Justin Lu wrote: > Please review this PR which restricts sub-classing of the internal calendar > system in sun.util.calendar to only the existing implementations. > > As the implementation is long-standing and complete with no intent for future > sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted > accordingly (`JulianCalendar.Date` must now have package visibility). > > > This system has the following structure, > > `CalendarSystem` extended by `AbstractCalendar` extended by `BaseCalendar` > extended by > (`Gregorian, JulianCalendar, LocalGregorianCalendar`) > > `CalendarDate` extended by `BaseCalendar.Date` extended by > (`Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, > LocalGregorianCalendar.Date`) > > Additionally, CalendarUtils was made `final`, as it is a utility class > composed of static util methods. I added a question on https://bugs.openjdk.org/browse/JDK-8316435 as to the effect on future calendar systems. - PR Comment: https://git.openjdk.org/jdk/pull/15803#issuecomment-1726166576
Re: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
On Tue, 19 Sep 2023 16:57:57 GMT, Steven Loomis wrote: >> Naoto Sato has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 10 additional >> commits since the last revision: >> >> - Fix GensrcRegex.gmk >> - Merge branch 'master' into JDK-8296246-Unicode15.1 >> - Update >> make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java >> >>Co-authored-by: Andrey Turbanov >> - Update >> make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java >> >>Co-authored-by: Andrey Turbanov >> - TR29 final version >> - .md file update >> - Final 8/28 >> - Draft 8/11 >> - GenerateExtraProperties tool >> - initial commit > > src/java.base/share/legal/unicode.md line 49: > >> 47: -- >> 48: >> 49: Unicode® Copyright and Terms of Use > > You shouldn't need to pull in all of this — the entire license file is at > https://www.unicode.org/license.txt > > It looks like you are pulling in all of https://www.unicode.org/copyright.html > > You will notice that the license text no longer points you to > https://www.unicode.org/copyright.html > > (I worked on this change a bit) look at https://www.unicode.org/Public/UCD/latest/ for example, it points you only to license.txt. - PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330445143
Re: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
On Mon, 18 Sep 2023 18:33:20 GMT, Naoto Sato wrote:
>> This PR is to incorporate the latest Unicode 15.1, which was released
>> yesterday. Besides the usual character data update, an upgraded
>> implementation of RegEx which reflects the Indic Conjunct Break specified in
>> the latest [Unicode Annex #29 ("Unicode Text
>> Segmentation")](https://unicode.org/reports/tr29/) is included. A
>> corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by the merge/rebase. The pull request contains 10 additional commits since
> the last revision:
>
> - Fix GensrcRegex.gmk
> - Merge branch 'master' into JDK-8296246-Unicode15.1
> - Update
> make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>
>Co-authored-by: Andrey Turbanov
> - Update
> make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>
>Co-authored-by: Andrey Turbanov
> - TR29 final version
> - .md file update
> - Final 8/28
> - Draft 8/11
> - GenerateExtraProperties tool
> - initial commit
Marked as reviewed by srl (Committer).
make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
line 42:
> 40: * Parses extra properties files of UCD, and replaces the placeholders in
> 41: * the given template source file with the generated conditions, then emit
> 42: * the produced .java files. For example, if the properties file has:
Suggestion:
* Parses extra properties files of UCD, and replaces the placeholders in
* the given template source file with the generated conditions, then emits
* .java files. For example, if the properties file has:
src/java.base/share/legal/unicode.md line 6:
> 4: ```
> 5:
> 6: UNICODE LICENSE V3
very minor update
src/java.base/share/legal/unicode.md line 49:
> 47: --
> 48:
> 49: Unicode® Copyright and Terms of Use
You shouldn't need to pull in all of this — the entire license file is at
https://www.unicode.org/license.txt
It looks like you are pulling in all of https://www.unicode.org/copyright.html
You will notice that the license text no longer points you to
https://www.unicode.org/copyright.html
(I worked on this change a bit)
-
PR Review: https://git.openjdk.org/jdk/pull/15728#pullrequestreview-1633772463
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330434732
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330439566
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330441674
Re: RFR: 8307547: Support variant collations [v4]
On Fri, 12 May 2023 16:41:20 GMT, Steven Loomis wrote: >>> I'm just wondering where a developer might go to get a definitive list, >>> i.e. aside from this API note, how would they know that "-trad" or >>> "-traditional" can be used to configure the ordering. Locale.forLanguageTag >>> supports more than BCP 47 language tag strings so is this considered a >>> private use language tag. >> >> I think those should go into Oracle JDK's `Supported Locales` document. >> Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018) > >> > I'm just wondering where a developer might go to get a definitive list, >> > i.e. aside from this API note, how would they know that "-trad" or >> > "-traditional" can be used to configure the ordering. >> > Locale.forLanguageTag supports more than BCP 47 language tag strings so is >> > this considered a private use language tag. >> >> I think those should go into Oracle JDK's `Supported Locales` document. >> Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018) > > `-u-co` is defined > [here](https://www.unicode.org/reports/tr35/#UnicodeCollationIdentifier) > (UTS#35) and the keys are in the datafile [here (link to `main` > branch!)](https://github.com/unicode-org/cldr/blob/main/common/bcp47/collation.xml) > - note the `since=` attribute, these are very stable. > > @AlanBateman >> Locale.forLanguageTag supports more than BCP 47 language tag strings > > It should still be all valid BCP47 including extensions and private use (such > as x-lvalue). > >> so is this considered a private use language tag > > Not private use at all. The `-u-` subtag is registered, and the links above > are from the registrar, see > - https://www.rfc-editor.org/info/bcp47 > - https://www.rfc-editor.org/rfc/rfc6067 > Thanks @srl295 > I am just curious how CLDR handles the default switch of Swedish collation. > Now the `traditional` collation used to be `standard`, and `standard` used to > be `reformed`. How do apps specify their desired collation in Swedish, > regardless of CLDR versions? I don't know off the top of my head but digging around I found https://unicode-org.atlassian.net/browse/CLDR-7088 and cross linked some tickets. Can you ask around on those? - PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546050297
Re: RFR: 8307547: Support variant collations [v4]
On Fri, 12 May 2023 16:32:57 GMT, Naoto Sato wrote: > > I'm just wondering where a developer might go to get a definitive list, > > i.e. aside from this API note, how would they know that "-trad" or > > "-traditional" can be used to configure the ordering. Locale.forLanguageTag > > supports more than BCP 47 language tag strings so is this considered a > > private use language tag. > > I think those should go into Oracle JDK's `Supported Locales` document. > Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018) `-u-co` is defined [here](https://www.unicode.org/reports/tr35/#UnicodeCollationIdentifier) (UTS#35) and the keys are in the datafile [here (link to `main` branch!)](https://github.com/unicode-org/cldr/blob/main/common/bcp47/collation.xml) - note the `since=` attribute, these are very stable. - PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546013166
Re: RFR: 8307547: Support variant collations [v4]
On Thu, 11 May 2023 20:51:37 GMT, Naoto Sato wrote: >> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default >> collation for Swedish to the modern one. In order to provide a means for >> users who need the old collation, this PR intends to make `Collator` >> recognize the `co` Unicode locale extension so that multiple implementations >> for a locale can be provided. I would also like reviews for the >> corresponding CSR. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Added "reformed" tests Marked as reviewed by srl (Committer). - PR Review: https://git.openjdk.org/jdk/pull/13917#pullrequestreview-1424842005
Re: RFR: 8306323: Update license files in CLDR v43
On Tue, 18 Apr 2023 18:40:03 GMT, Naoto Sato wrote: > The upgrade to CLDR v43 was missing the license-related file updates. Here > are the supplemental updates. Marked as reviewed by srl (Committer). [testing] Marked as reviewed by srl (Committer). - PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390862217 Changes requested by srl (Committer). PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390862891 PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390863607
Re: RFR: 8306323: Update license files in CLDR v43
On Tue, 18 Apr 2023 20:15:32 GMT, Steven Loomis wrote: >> The upgrade to CLDR v43 was missing the license-related file updates. Here >> are the supplemental updates. > > Marked as reviewed by srl (Committer). - [Steven Loomis](https://openjdk.org/census#srl) (@srl295 - Committer) 🎉 - PR Comment: https://git.openjdk.org/jdk/pull/13517#issuecomment-1513743510
