[jdk16] RFR: JDK-8247994: Localize javadoc search

Hannes Wallnöfer hannesw at openjdk.java.net
Mon Dec 14 09:52:59 UTC 2020


On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons <jjg at openjdk.org> 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


More information about the core-libs-dev mailing list