` with non-interactive content is not tabbable. Grid columns in the javadoc stylesheet has overflow: auto, which is failing Accessibility checks.
>> https://bugs.openjdk.org/browse/JDK-8325690
>
> psoujany has updated the pull request incrementally with one additional commit since the last revision:
>
> Add tabindex to tabbable elements
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java line 334:
> 332: cell.addStyle(rowStyle);
> 333: if (!matchFound) {
> 334: cell.put(HtmlAttr.ROLE, "tablist")
Looking into this further, I don't think the `role="tablist"` attribute is correct here. According to the [MDN documentation], a `tablist` is defined as a container for a set of `tabs`, which does not apply for table cells.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17819#discussion_r1625750412
From jlahoda at openjdk.org Tue Jun 4 11:57:13 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 4 Jun 2024 11:57:13 GMT
Subject: Integrated: 8325168: JShell should support Markdown comments
In-Reply-To:
References:
Message-ID:
On Fri, 2 Feb 2024 14:02:28 GMT, Jan Lahoda wrote:
> This is an attempt to add Markdown support in documentation comments to JShell.
>
> It works by converting the Markdown text to HTML during the process of resolving `{@inheritDoc}` tags.
This pull request has now been integrated.
Changeset: 8d3de45f
Author: Jan Lahoda
URL: https://git.openjdk.org/jdk/commit/8d3de45f4dfd60dc4e2f210cb0c085fcf6efb8e2
Stats: 2056 lines in 9 files changed: 1209 ins; 842 del; 5 mod
8325168: JShell should support Markdown comments
Reviewed-by: jjg
-------------
PR: https://git.openjdk.org/jdk/pull/17686
From hannesw at openjdk.org Tue Jun 4 17:24:02 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 4 Jun 2024 17:24:02 GMT
Subject: RFR: 8332039: Cannot invoke
"com.sun.source.util.DocTreePath.getTreePath()" because "path" is null
In-Reply-To:
References:
Message-ID:
On Thu, 23 May 2024 10:39:52 GMT, Hannes Walln?fer wrote:
> Please review a patch to fix a NPE thrown when a `@since` tag inherited by a nested class contains a nested inline tag. The solution is to make `CommentHelper.getDocTreePath(DocTree)` able to handle block tags inherited by nested classes.
I filed a follow-up issue to refactor the code for inherited and derived doc comments:
https://bugs.openjdk.org/browse/JDK-8333557
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19363#issuecomment-2148040277
From hannesw at openjdk.org Tue Jun 4 17:24:03 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 4 Jun 2024 17:24:03 GMT
Subject: Integrated: 8332039: Cannot invoke
"com.sun.source.util.DocTreePath.getTreePath()" because "path" is null
In-Reply-To:
References:
Message-ID:
On Thu, 23 May 2024 10:39:52 GMT, Hannes Walln?fer wrote:
> Please review a patch to fix a NPE thrown when a `@since` tag inherited by a nested class contains a nested inline tag. The solution is to make `CommentHelper.getDocTreePath(DocTree)` able to handle block tags inherited by nested classes.
This pull request has now been integrated.
Changeset: a706e35b
Author: Hannes Walln?fer
URL: https://git.openjdk.org/jdk/commit/a706e35b12addff987b489059be8f240c60fae75
Stats: 68 lines in 2 files changed: 49 ins; 3 del; 16 mod
8332039: Cannot invoke "com.sun.source.util.DocTreePath.getTreePath()" because "path" is null
Reviewed-by: jjg
-------------
PR: https://git.openjdk.org/jdk/pull/19363
From prappo at openjdk.org Wed Jun 5 11:47:58 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jun 2024 11:47:58 GMT
Subject: RFR: 8331947: Preview creates checkbox for JEP-less preview
feature [v4]
In-Reply-To:
References: <_kx1TJGenvZCMoSaeGX1HdxQQWR8t24OOqnrq0SpOmY=.31389dd4-1e6f-4c18-bf15-273520afb6b8@github.com>
Message-ID:
On Fri, 31 May 2024 10:01:17 GMT, Hannes Walln?fer wrote:
>> Please review a simple patch to exclude preview visitor classes meant to support future preview features from the Preview API page.
>>
>> The test adds an sample element annotated with the new `PreviewFeature.Feature.LANGUAGE_MODEL` constant (which does not have a `@JEP` annotation) to make sure it is not listed in the Preview API page. The test itself does not have to be modified, as it would fail without the change in `PreviewAPIListBuilder.java`.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
>
> Address review feedback
Approved with fuzz.
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 96:
> 94: return true;
> 95: }
> 96: // Preview features without JEP are not included.
Trivial: we don't need to mention "support" near "preview" and "features", right? Just checking.
test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java line 161:
> 159: """);
> 160:
> 161: // 8331947: Support preview features without JEP should not be included in Preview API page
Trivial: here it is phrased as "Support preview features", while in the actual test source file it is "Preview support feature".
-------------
Marked as reviewed by prappo (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19344#pullrequestreview-2098808073
PR Review Comment: https://git.openjdk.org/jdk/pull/19344#discussion_r1627545672
PR Review Comment: https://git.openjdk.org/jdk/pull/19344#discussion_r1627530580
From hannesw at openjdk.org Wed Jun 5 12:39:58 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 5 Jun 2024 12:39:58 GMT
Subject: RFR: 8331947: Preview creates checkbox for JEP-less preview
feature [v4]
In-Reply-To:
References: <_kx1TJGenvZCMoSaeGX1HdxQQWR8t24OOqnrq0SpOmY=.31389dd4-1e6f-4c18-bf15-273520afb6b8@github.com>
Message-ID:
On Wed, 5 Jun 2024 11:04:06 GMT, Pavel Rappo wrote:
>> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Address review feedback
>
> test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java line 161:
>
>> 159: """);
>> 160:
>> 161: // 8331947: Support preview features without JEP should not be included in Preview API page
>
> Trivial: here it is phrased as "Support preview features", while in the actual test source file it is "Preview support feature".
I agree the terminology in comments is somewhat inconsistent. I don't think there is an "official" term for these preview features. [In the CSR](https://bugs.openjdk.org/browse/JDK-8329634) they are summarized as follows: "Add a set of persistent preview visitors to support new language changes in development."
I think the essential property for our purpose is the "without JEP". I added the "support" adjective to make their purpose clearer, but I don't think it's essential.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19344#discussion_r1627680852
From hannesw at openjdk.org Wed Jun 5 12:43:01 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 5 Jun 2024 12:43:01 GMT
Subject: Integrated: 8331947: Preview creates checkbox for JEP-less preview
feature
In-Reply-To: <_kx1TJGenvZCMoSaeGX1HdxQQWR8t24OOqnrq0SpOmY=.31389dd4-1e6f-4c18-bf15-273520afb6b8@github.com>
References: <_kx1TJGenvZCMoSaeGX1HdxQQWR8t24OOqnrq0SpOmY=.31389dd4-1e6f-4c18-bf15-273520afb6b8@github.com>
Message-ID: <4-C4fdy0mVJi1DUKAW_ZigRR87uyYRoAqK7Y2xrhSdw=.5601a03c-0345-49a0-8f72-d0d310aea336@github.com>
On Wed, 22 May 2024 08:39:12 GMT, Hannes Walln?fer wrote:
> Please review a simple patch to exclude preview visitor classes meant to support future preview features from the Preview API page.
>
> The test adds an sample element annotated with the new `PreviewFeature.Feature.LANGUAGE_MODEL` constant (which does not have a `@JEP` annotation) to make sure it is not listed in the Preview API page. The test itself does not have to be modified, as it would fail without the change in `PreviewAPIListBuilder.java`.
This pull request has now been integrated.
Changeset: 765ad0e4
Author: Hannes Walln?fer
URL: https://git.openjdk.org/jdk/commit/765ad0e40bc522de4b2821ccc60b9139faf7376f
Stats: 97 lines in 8 files changed: 46 ins; 11 del; 40 mod
8331947: Preview creates checkbox for JEP-less preview feature
Reviewed-by: liach, prappo
-------------
PR: https://git.openjdk.org/jdk/pull/19344
From michael.osipov at innomotics.com Wed Jun 5 09:51:28 2024
From: michael.osipov at innomotics.com (Osipov, Michael)
Date: Wed, 5 Jun 2024 09:51:28 +0000
Subject: Missing element-list for
https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec
In-Reply-To:
References: <5947f22d-0c8d-4063-b721-42b7dd44ba4c@siemens.com>
<47A81E8E-1DFB-4CE1-A465-7FDE83F183DA@oracle.com>
Message-ID:
On 2024-05-31 21:38, Jonathan Gibbons wrote:
> Michael,
>
> There is no `element-list` file for any version of JDK before JDK 9.
> Before JDK 9, the appropriate information was in the `package-list`
> file. In JDK 9, with the introduction of modules, the format of the file
> was updated to include modules, and because this was an incompatible
> change, the file was renamed as well, to `element-list`.
>
> It is an annoying misconfiguration of `docs.oracle.com` that you are
> seeing `302 Moved Temporarily` instead of `404 Not Found` which would be
> a more semantically accurate response.
>
> That leaves the question of why whatever you were doing was looking for
> `element-list` in JDK 8. To answer that, we need more info, to determine
> whether it is just a command-line error on your part, or any error in
> the `javadoc` tool itself. What version of JDK and javadoc are you
> using; what external libraries were you referencing in `-link` or `-
> linkoffline` options; and what source level were you using, with either
> the `-source` or `--release` options?
John,
thanks for the elaboration. Let me better clarify what happens.
The code is question with a modification for you is available at:
https://github.com/michael-o/tomcatspnegoad/tree/javadoc-issue
Class net.sf.michaelo.tomcat.pac.asn1.AdIfRelevantAsn1Parser uses
com.sun.security.jgss.AuthorizationDataEntry and others use private Sun
classes which does not allow me to use -release for now, only -source.
The source is Java 8. When I run javadoc:javadoc with Zulu 8 all links
are generated successfully. Running Zulu 11 with extracted Javadoc call
(&"C:\Program Files\Zulu\zulu-11\bin\javadoc.exe" -verbose "@options"
"@packages") gives me no warning, even in verbose mode. It simply does
not link.
When trying Temurin 22.0.1 (&"C:\Temp\jdk-22.0.1+8\bin\javadoc.exe"
-verbose "@options" "@packages") it gives me:
> Warnung: URL https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec/element-list wurde umgeleitet an https://docs.oracle.com/en/java/javase/22/ - Aktualisieren Sie die Befehlszeilenoptionen, um diese Warnung zu unterdr?cken.
That is the redirect. Either I am misunderstanding or I have hit an edge
case for public classes outside of the standard JDK (Java namespaces).
Here is the input to Javadoc (@options, @packages) if you cannot try
yourself: https://gist.github.com/michael-o/212c6797b000914b9142f1f077b1d9df
I have tried:
> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
> Java version: 11.0.18, vendor: Azul Systems, Inc., runtime: C:\Program Files\Zulu\zulu-11
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
> Java version: 1.8.0_362, vendor: Azul Systems, Inc., runtime: C:\Program Files\Zulu\zulu-8\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
> Java version: 22.0.1, vendor: Eclipse Adoptium, runtime: C:\Temp\jdk-22.0.1+8
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Note: I have routed the Javadoc traffic through Fiddler and it clearly
following the misconfigured docs.oracle.com location:
> # Result Protocol Host URL Body Caching Content-Type Process Comments Custom
> 10 302 HTTPS docs.oracle.com /javase/8/docs/jre/api/security/jgss/spec/element-list 1 javadoc:24660
> # Result Protocol Host URL Body Caching Content-Type Process Comments Custom
> 12 200 HTTPS docs.oracle.com /en/java/javase/22/ 33 431 max-age=19052 text/html javadoc:24660
Regards,
Michael
From jonathan.gibbons at oracle.com Thu Jun 6 23:11:56 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 6 Jun 2024 16:11:56 -0700
Subject: [External] : Re: Missing element-list for
https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec
In-Reply-To:
References: <5947f22d-0c8d-4063-b721-42b7dd44ba4c@siemens.com>
<47A81E8E-1DFB-4CE1-A465-7FDE83F183DA@oracle.com>
Message-ID: <94c6cf1c-21f3-4fb6-9c5a-4bd6cada8e4b@oracle.com>
On 6/5/24 2:51 AM, Osipov, Michael wrote:
> On 2024-05-31 21:38, Jonathan Gibbons wrote:
>> Michael,
>>
>> There is no `element-list` file for any version of JDK before JDK 9.
>> Before JDK 9, the appropriate information was in the `package-list`
>> file. In JDK 9, with the introduction of modules, the format of the file
>> was updated to include modules, and because this was an incompatible
>> change, the file was renamed as well, to `element-list`.
>>
>> It is an annoying misconfiguration of `docs.oracle.com` that you are
>> seeing `302 Moved Temporarily` instead of `404 Not Found` which would be
>> a more semantically accurate response.
>>
>> That leaves the question of why whatever you were doing was looking for
>> `element-list` in JDK 8. To answer that, we need more info, to determine
>> whether it is just a command-line error on your part, or any error in
>> the `javadoc` tool itself. What version of JDK and javadoc are you
>> using; what external libraries were you referencing in `-link` or `-
>> linkoffline` options; and what source level were you using, with either
>> the `-source` or `--release` options?
> John,
>
> thanks for the elaboration. Let me better clarify what happens.
>
> The code is question with a modification for you is available at:
> https://urldefense.com/v3/__https://github.com/michael-o/tomcatspnegoad/tree/javadoc-issue__;!!ACWV5N9M2RV99hQ!L6MibNz6g0M99jnVOo2O_Zs2vP8-4CM-NS4WNUmHmL5dB30i0qaSfDJBHW4S_bxjOhImERJfBWGpStJ6WrwE0WAva10xtV86PQ$
>
> Class net.sf.michaelo.tomcat.pac.asn1.AdIfRelevantAsn1Parser uses
> com.sun.security.jgss.AuthorizationDataEntry and others use private Sun
> classes which does not allow me to use -release for now, only -source.
> The source is Java 8. When I run javadoc:javadoc with Zulu 8 all links
> are generated successfully. Running Zulu 11 with extracted Javadoc call
> (&"C:\Program Files\Zulu\zulu-11\bin\javadoc.exe" -verbose "@options"
> "@packages") gives me no warning, even in verbose mode. It simply does
> not link.
> When trying Temurin 22.0.1 (&"C:\Temp\jdk-22.0.1+8\bin\javadoc.exe"
> -verbose "@options" "@packages") it gives me:
>> Warnung: URLhttps://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec/element-list wurde umgeleitet anhttps://docs.oracle.com/en/java/javase/22/ - Aktualisieren Sie die Befehlszeilenoptionen, um diese Warnung zu unterdr?cken.
> That is the redirect. Either I am misunderstanding or I have hit an edge
> case for public classes outside of the standard JDK (Java namespaces).
> Here is the input to Javadoc (@options, @packages) if you cannot try
> yourself:https://urldefense.com/v3/__https://gist.github.com/michael-o/212c6797b000914b9142f1f077b1d9df__;!!ACWV5N9M2RV99hQ!L6MibNz6g0M99jnVOo2O_Zs2vP8-4CM-NS4WNUmHmL5dB30i0qaSfDJBHW4S_bxjOhImERJfBWGpStJ6WrwE0WAva12c46QzhA$
>
> I have tried:
>> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
>> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
>> Java version: 11.0.18, vendor: Azul Systems, Inc., runtime: C:\Program Files\Zulu\zulu-11
>> Default locale: de_DE, platform encoding: UTF-8
>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
>> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
>> Java version: 1.8.0_362, vendor: Azul Systems, Inc., runtime: C:\Program Files\Zulu\zulu-8\jre
>> Default locale: de_DE, platform encoding: Cp1252
>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>> Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
>> Maven home: C:\Entwicklung\Programme\apache-maven-3.8.8
>> Java version: 22.0.1, vendor: Eclipse Adoptium, runtime: C:\Temp\jdk-22.0.1+8
>> Default locale: de_DE, platform encoding: UTF-8
>> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Note: I have routed the Javadoc traffic through Fiddler and it clearly
> following the misconfigured docs.oracle.com location:
>> # Result Protocol Host URL Body Caching Content-Type Process Comments Custom
>> 10 302 HTTPS docs.oracle.com /javase/8/docs/jre/api/security/jgss/spec/element-list 1 javadoc:24660
>> # Result Protocol Host URL Body Caching Content-Type Process Comments Custom
>> 12 200 HTTPS docs.oracle.com /en/java/javase/22/ 33 431 max-age=19052 text/html javadoc:24660
>
> Regards,
>
> Michael
>
>
Michael,
I investigated a bit further, and I may have a solution for you.
The redirect is annoying, and sad to say, there is nothing I can do to
get it fixed in a timely manner.? But, I think you may be able to work
around it.? The answer is based on the content of the files in the gist
that you referenced in your message.
Look at these lines:
-link
'https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec'
-linkoffline
'https://docs.oracle.com/javase/8/docs/api'
'C:/Entwicklung/workspace-2023-06/tomcatspnegoad/tomcat90/target/javadoc-bundle-options'
I'm not sure what is in your `javadoc-bundle-options` file, but it
*ought* to be a local copy of the `package-list` found here:
https://docs.oracle.com/javase/8/docs/api/package-list
For the first option, the `-link` one, try changing it to:
-linkoffline
'https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec'
/path/to/file
where `/path/to/file` is a local copy of the file found here:
https://docs.oracle.com/javase/8/docs/jre/api/security/jgss/spec/package-list
which in reality is just:
com.sun.security.jgss
In other words, both options should be instances of the `-linkoffline`
option, which should be of the form:
-linkofflinehttps:/url/to/api /path/to/file
where `/path/to/file` is a local copy of the file downloaded from
`https:/url/to/api/package-list`
Note I am using `.../package-list` in this message because you are using
`-source 8`.? If you use a newer version of these APIs, you may need to
change `package-list` to `element-list`. (I believe the change happened
in JDK 11.)
For more details on the `-linkoffline` option, see
https://docs.oracle.com/en/java/javase/22/docs/specs/man/javadoc.html#option-linkoffline
-- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dholmes at openjdk.org Mon Jun 10 02:38:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Jun 2024 02:38:25 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
Message-ID:
Sets the version to 24/24-ea and the copyright year to 2025.
Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
This initial generation also picks up the unpublished changes from:
- JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
- JDK-8284500: Typo in Supported Named Extensions - BasicContraints
- JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class
Thanks
-------------
Commit messages:
- 8330205: Initial troff manpage generation for JDK 24
Changes: https://git.openjdk.org/jdk/pull/19617/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8330205
Stats: 66 lines in 28 files changed: 12 ins; 13 del; 41 mod
Patch: https://git.openjdk.org/jdk/pull/19617.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617
PR: https://git.openjdk.org/jdk/pull/19617
From alanb at openjdk.org Mon Jun 10 07:18:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jun 2024 07:18:11 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To:
References:
Message-ID: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>
On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
>
> This initial generation also picks up the unpublished changes from:
>
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class
>
> Thanks
Marked as reviewed by alanb (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118
From dholmes at openjdk.org Mon Jun 10 08:04:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Jun 2024 08:04:12 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>
References:
<3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>
Message-ID:
On Mon, 10 Jun 2024 07:15:51 GMT, Alan Bateman wrote:
>> Sets the version to 24/24-ea and the copyright year to 2025.
>>
>> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
>>
>> This initial generation also picks up the unpublished changes from:
>>
>> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
>> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
>> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
>>
>> Thanks
>
> Marked as reviewed by alanb (Reviewer).
Thanks for the review @AlanBateman !
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2157606095
From iris at openjdk.org Mon Jun 10 17:30:15 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 10 Jun 2024 17:30:15 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To:
References:
Message-ID:
On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
>
> This initial generation also picks up the unpublished changes from:
>
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
>
> Thanks
Marked as reviewed by iris (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2108383696
From dnguyen at openjdk.org Mon Jun 10 20:05:33 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
Message-ID:
This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
https://cr.openjdk.org/~dnguyen/output2/
-------------
Commit messages:
- Review comment edits
- Initial localization changes
Changes: https://git.openjdk.org/jdk/pull/19609/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8333827
Stats: 239 lines in 39 files changed: 133 ins; 57 del; 49 mod
Patch: https://git.openjdk.org/jdk/pull/19609.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/19609/head:pull/19609
PR: https://git.openjdk.org/jdk/pull/19609
From achung at openjdk.org Mon Jun 10 20:05:33 2024
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To:
References:
Message-ID:
On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote:
> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>
> Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/
Just a question about the reverted translations, otherwise LGTM
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
Any particular reason you know that the tool had the definitions adjusted? I see some of the changes look like like command line options not being translated, but it's a bit hard to tell. Do you know if the reverted words should be translated (and possibly will be re-translated in future drops?) or should they be left untranslated?
-------------
PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2105526180
PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2155723513
From jlu at openjdk.org Mon Jun 10 20:05:33 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To:
References:
Message-ID: <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote:
> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>
> Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/
Cannot speak to the translations themselves, but in general the changes LGTM pending the comments.
src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 1:
> 1: #
It looks like these .properties files need to have their copyright years bumped. I believe since the original was not bumped, the translation tool did not reflect the correct year in the localized versions.
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 66:
> 64: label.size=??(&Z):
> 65: label.source=??(&C):
> 66: label.outputbins=????(&P)?
Looks like the translation tool changed this from a colon (U+003A) to a full width colon (U+FF1A). There are l10n rules when it comes to punctuation, I am not sure if this is a result of that. It looks like the surrounding key/values are simply using (U+003A) colons. If we decide to revert this colon change, we need to also probably file a bug against the translation tool.
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 278:
> 276: UndeclaredElementInContentSpec = Contentmodell des Elements "{0}" verweist auf das nicht deklarierte Element "{1}".
> 277: UniqueNotationName = Deklaration f?r die Notation "{0}" ist nicht eindeutig. Ein jeweiliger Name darf nicht in mehreren Notationsdeklarationen deklariert werden.
> 278: ENTITYFailedInitializeGrammar = ENTITYDatatype-Validator: Nicht erfolgreich. Initialisierungsmethode muss mit einer g?ltigen Grammatikreferenz aufgerufen werden. \t
It looks like the _zh_CN_ file should also have the `\t` removed, but such changes are done by the translation tool. I think in this case, we should manually remove it, and then file a bug against the translation tool.
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 285:
> 283: VIRTUAL_MACHINE=Virtuelle Maschine
> 284: VM_ARGUMENTS=VM-Argumente
> 285: VMINTERNAL_FRAME_ACCESSIBLE_DESCRIPTION=Innerer Frame f?r das Monitoring einer Java Virtual Machine
This one-off change is consistent with the change in _src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java_.
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183:
> 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts
> 182:
> 183: help.usage = Verwendung: jshell ... ...\nM?gliche Optionen:\n --class-path Gibt an, wo die Benutzerklassendateien gespeichert sind\n --module-path Gibt an, wo die Anwendungsmodule gespeichert sind\n --add-modules (,)*\n Gibt aufzul?sende Module oder alle Module im\n Modulpfad an, wenn ALL-MODULE-PATHs lautet\n --enable-native-access\n Erm?glicht Ausf?hrung eingeschr?nkter nativer Methoden durch Code\n --enable-preview Code kann Vorschaufeatures in diesem Release nutzen\n --startup Ersetzung der Startdefinitionen mit einer Ausf?hrung\n --no-startup Startdefinitionen werden nicht ausgef?hrt\n --feedback Gibt den anf?nglichen Feedbackmodus an. Der Modus kann\n vordefiniert (Silent, Concise, Normal oder Verbose) oder\n v
orab benutzerdefiniert sein\n -q Stilles Feedback. Identisch mit: --feedback concise\n -s ?u?erst stilles Feedback. Identisch mit: --feedback silent\n -v Verbose-Feedback. Identisch mit: --feedback verbose\n -J ?bergibt an das Laufzeitsystem, hat aber keine Auswirkungen\n auf die Ausf?hrung von Code-Snippets. Um Kennzeichen anzugeben,\n die die Ausf?hrung von Code-Snippets beeinflussen, verwenden Sie\n -R. Verwenden Sie alternativ dazu -J mit\n --execution local.\n -R ?bergibt nur dann an das Laufzeitsystem, wenn\n Code-Snippets ausgef?hrt werden. Beispiel: -R-Dfoo=bar\n bedeutet, dass die Ausf?hrung des Snippets\n System.getProperty("foo") "bar" zur?ckgi
bt.\n -C ?bergibt an den Java-Compiler in JShell.\n Beispiel: -C-Xlint aktiviert alle empfohlenen\n LINT-Warnungen, und -C--release= kompiliert f?r\n Java SE N, wie wenn --release N angegeben wird.\n Verwenden Sie ein -C pro Compiler-Kennzeichen oder Kennzeichenargument\n --version Gibt Versionsinformationen aus und beendet den Vorgang\n --show-version Gibt Versionsinformationen aus und setzt den Vorgang fort\n --help, -?, -h Gibt diese Zusammenfassung der Standardoptionen aus und beendet den Vorgang\n --help-extra, -X Gibt Hilfetext zu Nicht-Standardoptionen aus und beendet den Vorgang\n\nEin Dateiargument kann ein Dateiname oder einer der vordefinierten Dateinamen sein: DEFAULT,\nPRINTING, TOOLING oder JAVASE.\nEine Ladedatei kann auch "-" zur Angabe einer Standardeingabe ohne interaktiven I/O sein.
\n\nWeitere Informationen zu den Auswertungskontextoptionen (--class-path,\n--module-path und --add-modules) finden Sie unter:\n\t/help context\n\nEin Pfad listet die zu durchsuchenden Verzeichnisse und Archive auf. Verwenden Sie unter Windows ein\nSemikolon (;), um Elemente im Pfad zu trennen. Verwenden Sie auf anderen Plattformen einen\nDoppelpunkt (:), um Elemente zu trennen.\n
> Any particular reason you know that the tool had the definitions adjusted? I see some of the changes look like like command line options not being translated, but it's a bit hard to tell. Do you know if the reverted words should be translated (and possibly will be re-translated in future drops?) or should they be left untranslated?
@alisenchung While these command line options are untranslated, which initially may seem confusing, it appears to be the translation tool standardizing the definitions with the Japanese and Chinese localized definitions. We should leave them untranslated.
-------------
PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2106349441
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632407907
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632376640
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632375726
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632377328
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632373349
From dnguyen at openjdk.org Mon Jun 10 20:05:33 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
References:
<6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
Message-ID:
On Sun, 9 Jun 2024 22:49:11 GMT, Justin Lu wrote:
>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>>
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>>
>> Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 1:
>
>> 1: #
>
> It looks like these .properties files need to have their copyright years bumped. I believe since the original was not bumped, the translation tool did not reflect the correct year in the localized versions.
Right, the source file has the copyright year of 2019, and these translated files reflect that, so I believe this is OK.
> src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 66:
>
>> 64: label.size=??(&Z):
>> 65: label.source=??(&C):
>> 66: label.outputbins=????(&P)?
>
> Looks like the translation tool changed this from a colon (U+003A) to a full width colon (U+FF1A). There are l10n rules when it comes to punctuation, I am not sure if this is a result of that. It looks like the surrounding key/values are simply using (U+003A) colons. If we decide to revert this colon change, we need to also probably file a bug against the translation tool.
Right, I agree. I'm OK with either decision too, but I'm leaning towards reverting this to standardize the colons since the rest are (U+003A). Maybe a reviewer from desktop can chime in once this PR is undrafted.
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 278:
>
>> 276: UndeclaredElementInContentSpec = Contentmodell des Elements "{0}" verweist auf das nicht deklarierte Element "{1}".
>> 277: UniqueNotationName = Deklaration f?r die Notation "{0}" ist nicht eindeutig. Ein jeweiliger Name darf nicht in mehreren Notationsdeklarationen deklariert werden.
>> 278: ENTITYFailedInitializeGrammar = ENTITYDatatype-Validator: Nicht erfolgreich. Initialisierungsmethode muss mit einer g?ltigen Grammatikreferenz aufgerufen werden. \t
>
> It looks like the _zh_CN_ file should also have the `\t` removed, but such changes are done by the translation tool. I think in this case, we should manually remove it, and then file a bug against the translation tool.
Yeah, I believe you're right. Noted as something else to file against the translation tool.
> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183:
>
>> 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts
>> 182:
>> 183: help.usage = Verwendung: jshell ... ...\nM?gliche Optionen:\n --class-path Gibt an, wo die Benutzerklassendateien gespeichert sind\n --module-path Gibt an, wo die Anwendungsmodule gespeichert sind\n --add-modules (,)*\n Gibt aufzul?sende Module oder alle Module im\n Modulpfad an, wenn ALL-MODULE-PATHs lautet\n --enable-native-access\n Erm?glicht Ausf?hrung eingeschr?nkter nativer Methoden durch Code\n --enable-preview Code kann Vorschaufeatures in diesem Release nutzen\n --startup Ersetzung der Startdefinitionen mit einer Ausf?hrung\n --no-startup Startdefinitionen werden nicht ausgef?hrt\n --feedback Gibt den anf?nglichen Feedbackmodus an. Der Modus kann\n vordefiniert (Silent, Concise, Normal oder Verbose) oder\n
vorab benutzerdefiniert sein\n -q Stilles Feedback. Identisch mit: --feedback concise\n -s ?u?erst stilles Feedback. Identisch mit: --feedback silent\n -v Verbose-Feedback. Identisch mit: --feedback verbose\n -J ?bergibt an das Laufzeitsystem, hat aber keine Auswirkungen\n auf die Ausf?hrung von Code-Snippets. Um Kennzeichen anzugeben,\n die die Ausf?hrung von Code-Snippets beeinflussen, verwenden Sie\n -R. Verwenden Sie alternativ dazu -J mit\n --execution local.\n -R ?bergibt nur dann an das Laufzeitsystem, wenn\n Code-Snippets ausgef?hrt werden. Beispiel: -R-Dfoo=bar\n bedeutet, dass die Ausf?hrung des Snippets\n System.getProperty("foo") "bar" zur?ckg
ibt.\n -C ?bergibt an den Java-Compiler in JShell.\n Beispiel: -C-Xlint aktiviert alle empfohlenen\n ...
This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633762275
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632401147
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633748812
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632401256
From jjg at openjdk.org Mon Jun 10 20:15:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 10 Jun 2024 20:15:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To:
References:
<6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
Message-ID: <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
On Sun, 9 Jun 2024 22:07:44 GMT, Damon Nguyen wrote:
>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183:
>>
>>> 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts
>>> 182:
>>> 183: help.usage = Verwendung: jshell ... ...\nM?gliche Optionen:\n --class-path Gibt an, wo die Benutzerklassendateien gespeichert sind\n --module-path Gibt an, wo die Anwendungsmodule gespeichert sind\n --add-modules (,)*\n Gibt aufzul?sende Module oder alle Module im\n Modulpfad an, wenn ALL-MODULE-PATHs lautet\n --enable-native-access\n Erm?glicht Ausf?hrung eingeschr?nkter nativer Methoden durch Code\n --enable-preview Code kann Vorschaufeatures in diesem Release nutzen\n --startup Ersetzung der Startdefinitionen mit einer Ausf?hrung\n --no-startup Startdefinitionen werden nicht ausgef?hrt\n --feedback Gibt den anf?nglichen Feedbackmodus an. Der Modus kann\n vordefiniert (Silent, Concise, Normal oder Verbose) oder\n
vorab benutzerdefiniert sein\n -q Stilles Feedback. Identisch mit: --feedback concise\n -s ?u?erst stilles Feedback. Identisch mit: --feedback silent\n -v Verbose-Feedback. Identisch mit: --feedback verbose\n -J ?bergibt an das Laufzeitsystem, hat aber keine Auswirkungen\n auf die Ausf?hrung von Code-Snippets. Um Kennzeichen anzugeben,\n die die Ausf?hrung von Code-Snippets beeinflussen, verwenden Sie\n -R. Verwenden Sie alternativ dazu -J mit\n --execution local.\n -R ?bergibt nur dann an das Laufzeitsystem, wenn\n Code-Snippets ausgef?hrt werden. Beispiel: -R-Dfoo=bar\n bedeutet, dass die Ausf?hrung des Snippets\n System.getProperty("foo") "bar" zur?ck
gibt.\n -C ?bergibt an den Java-Compiler in JShell.\n Beispiel: -C-Xlint aktiviert alle empfohlenen\n ...
>
> This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.
While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, ``, ``.
This change seems to be going backwards.
Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633774912
From prr at openjdk.org Mon Jun 10 20:23:22 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Jun 2024 20:23:22 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To:
References:
Message-ID: <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote:
> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/
src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 66:
> 64: label.size=G&r??e:
> 65: label.source=&Quelle:
> 66: label.outputbins=A&usgabef?cher:
How confident are we in this ?
google translate says that the old text referred to 'compartments' and the new one to 'areas' and I wonder why that is better ?
https://translate.google.com/?sl=auto&tl=en&text=Ausgabebereiche%0AAusgebefacher&op=translate
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 32:
> 30: border.jobattributes=????
> 31: border.media=??
> 32: border.output=??
What triggered this ? Just someone noticing it and deciding there's a better translation ?
What does it say ?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633781646
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633782742
From jjg at openjdk.org Mon Jun 10 20:23:23 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 10 Jun 2024 20:23:23 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To:
References:
Message-ID:
On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote:
> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 409:
> 407: compiler.err.unconditional.pattern.and.default=Switch umfasst sowohl ein nicht bedingtes Muster als auch ein Standardlabel
> 408:
> 409: compiler.err.unconditional.pattern.and.both.boolean.values=Switch umfasst sowohl boolesche Werte als auch ein nicht bedingtes Muster
Here and elsewhere in this file and other translations, I'm surprised `switch` is not being translated, and is being capitalized. In the English form, it is not being used as a keyword, although could maybe be seen as a short form of `switch' statement, in which case `switch` should be treated as a keyword and not translated or capitalized.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633782242
From dnguyen at openjdk.org Mon Jun 10 20:37:13 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:37:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To:
References:
Message-ID: <2-SMv3j3Eqrv7LVV6CbkZVEb3KFcahQR1_8AiJErDAQ=.07538bd6-9b25-45ed-b47f-8e9102ea8af9@github.com>
On Mon, 10 Jun 2024 20:20:26 GMT, Jonathan Gibbons wrote:
>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>>
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>>
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 409:
>
>> 407: compiler.err.unconditional.pattern.and.default=Switch umfasst sowohl ein nicht bedingtes Muster als auch ein Standardlabel
>> 408:
>> 409: compiler.err.unconditional.pattern.and.both.boolean.values=Switch umfasst sowohl boolesche Werte als auch ein nicht bedingtes Muster
>
> Here and elsewhere in this file and other translations, I'm surprised `switch` is not being translated, and is being capitalized. In the English form, it is not being used as a keyword, although could maybe be seen as a short form of `switch' statement, in which case `switch` should be treated as a keyword and not translated or capitalized.
Good catch. Seems to be across all files and I'm assuming it's for the reason you suggested. I'll bring this up to the go team. I have no way to fix this since I can't rely on google translate. This can be caught in a future update if the go team can successfully differentiate the difference between the word `switch` and a `switch keyword`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633796771
From dnguyen at openjdk.org Mon Jun 10 20:37:14 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:37:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
References:
<6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
<06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
Message-ID:
On Mon, 10 Jun 2024 20:12:42 GMT, Jonathan Gibbons wrote:
>> This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.
>
> While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, ``, ``.
>
> This change seems to be going backwards.
>
> Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.
The go translation team dictates which of these segments within a file actually get updated. I can manually revert the segments if preferred, but these changes will continue appearing for future drops with the current system.
I can potentially try to communicate to the other team to differentiate between keywords & option names versus some of these other words, but let me know how you'd like me to proceed with this.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633794362
From dnguyen at openjdk.org Mon Jun 10 20:40:15 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:40:15 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
References:
<4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
Message-ID: <0xmUIRy1V_ts7yyfm1kMaQfbzU5YoJSWAzD3QDNLY7U=.8e0e163e-d0c6-4f22-a92d-79de8c58e8f6@github.com>
On Mon, 10 Jun 2024 20:20:52 GMT, Phil Race wrote:
>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>>
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>>
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 32:
>
>> 30: border.jobattributes=????
>> 31: border.media=??
>> 32: border.output=??
>
> What triggered this ? Just someone noticing it and deciding there's a better translation ?
> What does it say ?
In the past, it was brought up in review that some of the words were translated to localized words that didn't exactly mean what the original English word meant. I believe Weijun Wang caught some of these in Chinese files in the past. I'm assuming these are cases where the go team is improving the translation, but I also can't exactly tell. We do suggest changes to the go team, so maybe this is evidence of them improving their tool.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633801033
From naoto at openjdk.org Mon Jun 10 20:49:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Jun 2024 20:49:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To:
References:
Message-ID:
On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote:
> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/
Did not look at each for translation accuracy (did some for Japanese), but looks good overall.
It's great to see diffs in native languages, rather than those cryptic `\uXXXX` notation!
-------------
Marked as reviewed by naoto (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2108722631
From dnguyen at openjdk.org Mon Jun 10 21:45:13 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 21:45:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To:
References:
Message-ID:
On Mon, 10 Jun 2024 20:46:46 GMT, Naoto Sato wrote:
> Did not look at each for translation accuracy (did some for Japanese), but looks good overall. It's great to see diffs in native languages, rather than those cryptic `\uXXXX` notation!
Justin's tool is responsible for this. Made the process quicker/simpler as well once everything was setup properly and working.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2159331304
From dnguyen at openjdk.org Mon Jun 10 21:45:14 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 21:45:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
References:
<6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
<06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
Message-ID: <8fptu16lcceBUEid012EvN4KHhrf3gjzPRgdOANg_Kk=.4d3d1e78-17f9-4248-89ca-99ca03370e71@github.com>
On Mon, 10 Jun 2024 20:12:42 GMT, Jonathan Gibbons wrote:
>> This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.
>
> While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, ``, ``.
>
> This change seems to be going backwards.
>
> Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.
@jonathan-gibbons I just realized that this change to the German file matches the file with the Japanese and Chinese localized files. By that I mean the "backwards" translations are also present for the Japanese and Chinese files.
However, the previous versions of the Japanese and Chinese files don't have these bits translated. So in summary, I can revert the German file back to German but the Japanese and Chinese files will still be English for these parts because I wouldn't know what to revert them to in their local language.
As a result, I actually think it might be better to change this German file as shown in the current version of the PR just to remain consistent with the other localized versions of this file. We can still bring this up to the go team as an issue, but I think this is the best solution now for this drop at least.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633859027
From joehw at openjdk.org Mon Jun 10 21:54:14 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 10 Jun 2024 21:54:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To:
References:
Message-ID:
On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen wrote:
> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/
One minor comment, otherwise the java.xml changes look good.
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 331:
> 329:
> 330: # Implementation Property DTD
> 331: JDK_DTD_DENY = JAXP00010008: DOCTYPE ist nicht zul?ssig, wenn die DTD-Eigenschaft auf "Ablehnen" gesetzt wurde. Weitere Informationen: Eigenschaft jdk.xml.dtd.support in java.xml/module-summary.
either drop the double quote in "Ablehnen" or use the literal without translation, that is, "deny".
-------------
Marked as reviewed by joehw (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2108813421
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633870136
From dnguyen at openjdk.org Mon Jun 10 21:58:29 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 21:58:29 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To:
References:
Message-ID:
> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/
Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
Remove double quotes
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/19609/files
- new: https://git.openjdk.org/jdk/pull/19609/files/9125337b..32d69e89
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/19609.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/19609/head:pull/19609
PR: https://git.openjdk.org/jdk/pull/19609
From cjplummer at openjdk.org Mon Jun 10 22:27:15 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 10 Jun 2024 22:27:15 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To:
References:
Message-ID:
On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen wrote:
>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>>
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>>
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>
> Remove double quotes
src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 325:
> 323: {"Unexpected event type", "Unerwarteter Ereignistyp: {0}"},
> 324: {"unknown", "unbekannt"},
> 325: {"Unmonitoring", "Monitoring von {0} aufheben"},
The English entry is:
{"Unmonitoring", "Unmonitoring {0} "},
But the German entry now says "Monitoring". I'm sure what the original "\u00DCberwachung" translates to, other than berwachung is monitoring. Now this resource is partly in English, and is the incorrect English.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633902362
From dnguyen at openjdk.org Mon Jun 10 22:51:14 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 22:51:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To:
References:
Message-ID:
On Mon, 10 Jun 2024 22:19:49 GMT, Chris Plummer wrote:
>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Remove double quotes
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 325:
>
>> 323: {"Unexpected event type", "Unerwarteter Ereignistyp: {0}"},
>> 324: {"unknown", "unbekannt"},
>> 325: {"Unmonitoring", "Monitoring von {0} aufheben"},
>
> The English entry is:
>
> {"Unmonitoring", "Unmonitoring {0} "},
>
> But the German entry now says "Monitoring". I'm sure what the original "\u00DCberwachung" translates to, other than berwachung is monitoring. Now this resource is partly in English, and is the incorrect English.
I don't know German, but when plugging `"Monitoring von {0} aufheben"` into google translate, I get `Unmonitoring` as well. Maybe `Monitoring` is a word that could also be used in German? No clue. The translation tool decided to make this change.
@sormuras do you have any input on this?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633925334
From jjg at openjdk.org Mon Jun 10 23:13:15 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 10 Jun 2024 23:13:15 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <8fptu16lcceBUEid012EvN4KHhrf3gjzPRgdOANg_Kk=.4d3d1e78-17f9-4248-89ca-99ca03370e71@github.com>
References:
<6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
<06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
<8fptu16lcceBUEid012EvN4KHhrf3gjzPRgdOANg_Kk=.4d3d1e78-17f9-4248-89ca-99ca03370e71@github.com>
Message-ID:
On Mon, 10 Jun 2024 21:38:18 GMT, Damon Nguyen wrote:
>> While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, ``, ``.
>>
>> This change seems to be going backwards.
>>
>> Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.
>
> @jonathan-gibbons I just realized that this change to the German file matches the file with the Japanese and Chinese localized files. By that I mean the "backwards" translations are also present for the Japanese and Chinese files.
>
> However, the previous versions of the Japanese and Chinese files don't have these bits translated. So in summary, I can revert the German file back to German but the Japanese and Chinese files will still be English for these parts because I wouldn't know what to revert them to in their local language.
>
> As a result, I actually think it might be better to change this German file as shown in the current version of the PR just to remain consistent with the other localized versions of this file. We can still bring this up to the go team as an issue, but I think this is the best solution now for this drop at least.
No one else except people reading this PR will spot inconsistencies between translations in different languages. So inconsistencies across languages will not be obvious to end users.
But anyone (end-user) using the tool in any one of these languages is likely to spot inconsistencies in the translations for that one language.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633937355
From dholmes at openjdk.org Tue Jun 11 00:50:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 00:50:28 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v2]
In-Reply-To:
References:
Message-ID:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
>
> This initial generation also picks up the unpublished changes from:
>
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
>
> Thanks
David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
- Merge
- 8330205: Initial troff manpage generation for JDK 24
-------------
Changes: https://git.openjdk.org/jdk/pull/19617/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=01
Stats: 53 lines in 28 files changed: 12 ins; 3 del; 38 mod
Patch: https://git.openjdk.org/jdk/pull/19617.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617
PR: https://git.openjdk.org/jdk/pull/19617
From dholmes at openjdk.org Tue Jun 11 01:02:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:02:39 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]
In-Reply-To:
References:
Message-ID:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
>
> This initial generation also picks up the unpublished changes from:
>
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
>
> Thanks
David Holmes has updated the pull request incrementally with one additional commit since the last revision:
Regenerated after merge
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/19617/files
- new: https://git.openjdk.org/jdk/pull/19617/files/8472c47d..e7563087
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=01-02
Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/19617.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617
PR: https://git.openjdk.org/jdk/pull/19617
From dholmes at openjdk.org Tue Jun 11 01:08:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:08:22 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]
In-Reply-To:
References:
Message-ID: <7aiYPjUq_qkJuy1jRAFfZTpNoCwaw9scrgKJkkbp6UA=.dcdfae3e-05c5-45af-81b4-8a434b2774ba@github.com>
On Mon, 10 Jun 2024 17:27:18 GMT, Iris Clark wrote:
>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Regenerated after merge
>
> Marked as reviewed by iris (Reviewer).
Thanks for the review @irisclark .
I've merged in the latest updates that also brought in part of the missing changes. If anything goes wrong I have another PR in preparation that also updates java.1
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2159577044
From dholmes at openjdk.org Tue Jun 11 01:08:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:08:22 GMT
Subject: Integrated: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To:
References:
Message-ID:
On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote:
> Sets the version to 24/24-ea and the copyright year to 2025.
>
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
>
> This initial generation also picks up the unpublished changes from:
>
> - ~~JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC~~ (covered by merge)
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
>
> Thanks
This pull request has now been integrated.
Changeset: 3a01b47a
Author: David Holmes
URL: https://git.openjdk.org/jdk/commit/3a01b47ac97714608356ce3faf797c37dc63e9af
Stats: 43 lines in 28 files changed: 2 ins; 3 del; 38 mod
8330205: Initial troff manpage generation for JDK 24
Reviewed-by: alanb, iris
-------------
PR: https://git.openjdk.org/jdk/pull/19617
From cstein at openjdk.org Tue Jun 11 05:46:16 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 05:46:16 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
References:
<4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
Message-ID:
On Mon, 10 Jun 2024 20:19:51 GMT, Phil Race wrote:
>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Remove double quotes
>
> src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 66:
>
>> 64: label.size=G&r??e:
>> 65: label.source=&Quelle:
>> 66: label.outputbins=A&usgabef?cher:
>
> How confident are we in this ?
> google translate says that the old text referred to 'compartments' and the new one to 'areas' and I wonder why that is better ?
>
> https://translate.google.com/?sl=auto&tl=en&text=Ausgabebereiche%0AAusgebefacher&op=translate
"Ausgabef?cher" is the best German translation here.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1634221518
From cstein at openjdk.org Tue Jun 11 05:58:16 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 05:58:16 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To:
References:
Message-ID: