On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons <[email protected]> wrote:
> This is for JDK16, as a precursor to fixing JDK-8258002.
>
> While it is good to be using localized strings in the generated output, the
> significance for JDK-8258002 is that the strings are now obtained from a
> resource file, and not hardcoded in JavaScript file itself.
>
> The source file `search.js` is renamed to `search.js.template`, and (unlike
> other template files) is copied as-is into the generated image. The values in
> the template are resolved when javadoc is executed, depending on the locale
> in use at the time. Because of the change in the file's extension, two
> makefiles are updated to accommodate the new extension: one is for the
> "interim" javadoc used to generate the API docs; the other is for the primary
> javadoc in the main JDK image.
Looks good in general. `<Unnamed>` shouldn't be localized as it is an internal
tag (see inline comment).
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template
line 40:
> 38: var MIN_RESULTS = 3;
> 39: var MAX_RESULTS = 500;
> 40: var UNNAMED = "##REPLACE:doclet.search.unnamed##";
`<Unnamed>` is not a string that is ever shown to the user, it is what is used
by javadoc to denote the default package (see
`toolkit.util.DocletConstants.DEFAULT_PACKAGE_NAME`). This variable shouldn't
be localized as that would break behaviour for code in the default package (and
show the localized string as package name, instead of no package name).
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java
line 256:
> 254: sb.append(resources.getText(m.group("key")));
> 255: } catch (MissingResourceException e) {
> 256: sb.append(m.group());
Shouldn't we propagate an error here, or issue a warning? If a key is missing
localized properties the value from default properties should be used, so this
should never happen, right?
-------------
Changes requested by hannesw (Reviewer).
PR: https://git.openjdk.java.net/jdk16/pull/16
