Bug ID: JDK-7025302 NLS: logging.properties translatability guideline violation

Type: Bug
Component: core-libs
Sub-Component: java.util.logging
Affected Version: 7

Priority: P3
Status: Closed
Resolution: Duplicate
OS: generic
CPU: generic

Submitted: 2011-03-07
Updated: 2011-05-03
Resolved: 2011-05-03

JDK 7
7Resolved

jdk/src/share/classes/sun/util/logging/resources/logging.properties contains resource strings in ALL CAPS words. The WPTG translatability guideline states NOT to translate anything that uses ALL CAPS words or StudlyCap words. They are automatically not translated.

ALL=ALL
SEVERE=SEVERE
WARNING=WARNING
INFO=INFO
CONFIG= CONFIG
FINE=FINE
FINER=FINER
FINEST=FINEST
OFF=OFF

After going through WPTG translation drop 1, this file became untranslated due to t13y guideline. This is a regression.

Temporary workaround is 7021691.

EVALUATION Closing as a duplicate of: 7021691 3/4 Most log level words are not translated in java logging after consulation with Michael F.

03-05-2011

EVALUATION I'm rewinding and reviewing the bidding here... Here's the test attached to 7021691: $ cat -n LogTest.java | expand | sed 's/^ //' 1 import java.util.logging.*; 2 3 public class LogTest{ 4 // Obtain a suitable logger. 5 private static Logger logger = Logger.getLogger("LogTest"); 6 public static void main(String argv[]) { 7 // Log a FINE tracing message 8 logger.fine("doing stuff"); 9 try{ 10 int[] p = new int[3]; 11 p[4] = 1; 12 } catch (Exception ex) { 13 // Log the exception 14 logger.log(Level.WARNING, "testing", ex); 15 logger.log(Level.SEVERE, "testing", ex); 16 logger.log(Level.INFO, "testing", ex); 17 } 18 logger.fine("done"); 19 } 20 } Here is the test's output in my locale: $ java LogTest Apr 26, 2011 1:37:15 PM LogTest main WARNING: testing java.lang.ArrayIndexOutOfBoundsException: 4 at LogTest.main(LogTest.java:11) Apr 26, 2011 1:37:15 PM LogTest main SEVERE: testing java.lang.ArrayIndexOutOfBoundsException: 4 at LogTest.main(LogTest.java:11) Apr 26, 2011 1:37:15 PM LogTest main INFO: testing java.lang.ArrayIndexOutOfBoundsException: 4 at LogTest.main(LogTest.java:11) So what this test is showing is that the Logger.log() calls on lines 14-16 output the level names as English: WARNING: testing SEVERE: testing INFO: testing and that's okay for my English locale. However, the t13y folks believe that this output should be localized as it was prior to JDK7-B130. The following bug: 7021691 3/4 Most log level words are not translated in java logging was filed to track the t13y issue for JDK7. The following bug: 7025303 3/3 NLS: t13y fix for 7021691 Most log level words are not translated in java logging was filed to add comments to get the uppercase words in the resource file translated as a short-term solution. The following bug: 7025302 3/3 NLS: logging.properties translatability guideline violation was filed to get a long-term solution in place for the uppercase words in the resource file. OK. I think that covers the test, the test failure and the various bugs involved. I'm going to ignore the fact that the comments added by 7025303 were ignored in the last t13y round. I agree that output like the following: WARNING: testing SEVERE: testing INFO: testing needs to have the level names, e.g., "SEVERE", translated. That's how it worked before and such a change would be noticeable and has been noticed in JDK7. When the Logging subsystem outputs a log message, it uses Level.getLocalizedName() to get the localized name: 229 /** 230 * Return the localized string name of the Level, for 231 * the current default locale. 232 * <p> 233 * If no localization information is available, the 234 * non-localized name is returned. 235 * 236 * @return localized name 237 */ 238 public String getLocalizedName() { 239 try { 240 ResourceBundle rb = ResourceBundle.getBundle(resourceBundleName); 241 return rb.getString(name); 242 } catch (Exception ex) { 243 return name; 244 } 245 } The name that is passed to the ResourceBundle.getString() function is the name of the Level object itself, i.e., the name that the Level object was assigned at creation time: $ grep "new Level" src/share/classes/java/util/logging/Level.java public static final Level OFF = new Level("OFF",Integer.MAX_VALUE, defaultBundle); public static final Level SEVERE = new Level("SEVERE",1000, defaultBundle); public static final Level WARNING = new Level("WARNING", 900, defaultBundle); public static final Level INFO = new Level("INFO", 800, defaultBundle); public static final Level CONFIG = new Level("CONFIG", 700, defaultBundle); public static final Level FINE = new Level("FINE", 500, defaultBundle); public static final Level FINER = new Level("FINER", 400, defaultBundle); public static final Level FINEST = new Level("FINEST", 300, defaultBundle); public static final Level ALL = new Level("ALL", Integer.MIN_VALUE, defaultBundle); I'm going to guess that this resourceBundle.getString() function uses the name to the lookup entries in the logging.properties resource file, e.g.: # The following ALL CAPS words should be translated. SEVERE=SEVERE So it seems to me that in order to change the logging.properties resource file to not use uppercase names, we also have to change the names of the standard Level objects. This would affect any existing code that used Level.parse() to lookup a Level by String value so Level.parse("SEVERE") would no longer work. I really don't think we want to go there. It seems to me that getting the uppercase strings in the logging.properties resource file is not only the short-term solution, but it is also the long-term solution. I'm recommending that: 7025302 3/3 NLS: logging.properties translatability guideline violation be closed as a duplicate of: 7021691 3/4 Most log level words are not translated in java logging Of course, it is up to the owners of 7021691 to make sure that the words in the logging.properties are actually translated as per the comments added by: 7025303 3/3 NLS: t13y fix for 7021691 Most log level words are not translated in java logging

02-05-2011