On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons <j...@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