Javadoc generated in English has German language indicated in HTML tag #1048
Assignees
Milestone
Comments
|
Setting the Javadoc |
odrotbohm
added a commit
that referenced
this issue
Apr 6, 2020
Not setting the Javadoc's locale explicitly has cause the release building machine's local to end up as lang attribute in the HTML tag. Most releases build by folks in Germany, the "de" value causes browsers to suggest to translate the page content from German into the user's browser language in case that's not German in the first place. We now explicitly set the value to en_US, as we know the content is English anyway. Getting this fixed has been a bit of a ride as it takes a special way of convincing the Javadoc tool actually receive the locale attribute. For whatever reason, the locale attribute needs to be the first attribute piped to the Javadoc tool (yeah, exactly^^), which is at odds with our usage of the <additionalJOptions /> usage to disable Javadoc linting. The options always appear *before* any other attributes handed to the Javadoc tool and thus caused the build to fail with: javadoc: error - option -locale must be first on the command line. Switching to rather use <additionalOptions /> (note the missing J) seems to pipe the attributes into the Javadoc tool in the order it would like to receive them.
mp911de
pushed a commit
that referenced
this issue
Apr 8, 2020
Not setting the Javadoc's locale explicitly has cause the release building machine's local to end up as lang attribute in the HTML tag. Most releases build by folks in Germany, the "de" value causes browsers to suggest to translate the page content from German into the user's browser language in case that's not German in the first place. We now explicitly set the value to en_US, as we know the content is English anyway. Getting this fixed has been a bit of a ride as it takes a special way of convincing the Javadoc tool actually receive the locale attribute. For whatever reason, the locale attribute needs to be the first attribute piped to the Javadoc tool (yeah, exactly^^), which is at odds with our usage of the <additionalJOptions /> usage to disable Javadoc linting. The options always appear *before* any other attributes handed to the Javadoc tool and thus caused the build to fail with: javadoc: error - option -locale must be first on the command line. Switching to rather use <additionalOptions /> (note the missing J) seems to pipe the attributes into the Javadoc tool in the order it would like to receive them.
mp911de
pushed a commit
that referenced
this issue
Apr 8, 2020
Not setting the Javadoc's locale explicitly has cause the release building machine's local to end up as lang attribute in the HTML tag. Most releases build by folks in Germany, the "de" value causes browsers to suggest to translate the page content from German into the user's browser language in case that's not German in the first place. We now explicitly set the value to en_US, as we know the content is English anyway. Getting this fixed has been a bit of a ride as it takes a special way of convincing the Javadoc tool actually receive the locale attribute. For whatever reason, the locale attribute needs to be the first attribute piped to the Javadoc tool (yeah, exactly^^), which is at odds with our usage of the <additionalJOptions /> usage to disable Javadoc linting. The options always appear *before* any other attributes handed to the Javadoc tool and thus caused the build to fail with: javadoc: error - option -locale must be first on the command line. Switching to rather use <additionalOptions /> (note the missing J) seems to pipe the attributes into the Javadoc tool in the order it would like to receive them.
This was referenced Apr 8, 2020
|
I just noticed in another project that this seems to be broken again in JDK 20+ after having been fixed for JDK 15. Can you verify and confirm? For me, this switch has no effect on JDK 21. See https://bugs.openjdk.org/browse/JDK-8222793. Actually, it is broken on 19+, not 20+. I just checked for myself, rather than believing what the last comment in the JDK issue says. The workaround is to set |
|
I am too busy for contributing a PR just now, but found this workaround for my project that does not require setting <!--
Avoid non-English javadoc generation. Due to https://bugs.openjdk.org/browse/JDK-8222793 reoccurring at
least in JDKs 19-21 and also being broken in some older JDKs, we cannot rely on just setting the locale
parameter, but also need the 'user.language' and 'user.country' parameters in 'additionalJOptions' as a
workaround.
-->
<locale>en</locale>
<additionalJOptions>
<additionalJOption>-J-Dfile.encoding=UTF-8</additionalJOption>
<additionalJOption>-J-Duser.language=en</additionalJOption>
<additionalJOption>-J-Duser.country=US</additionalJOption>
</additionalJOptions>See also eclipse-aspectj/aspectj@0cba9d1. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The generated javadoc for Spring Data Mongodb (although I have not checked the other Spring Data projects), is generating the HTML tag with the
delanguage. This causes Chrome to think it's in German and ask users if they want it translated. Thislangattribute should either be changed to the actual language or removed entirely.The text was updated successfully, but these errors were encountered: