JDK-8016127 : NLS: logging.properties translatability recommendation
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 7u60,8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-06-07
  • Updated: 2014-05-19
  • Resolved: 2013-09-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7u60 b01Fixed 8Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
This is a follow up to JDK-7025302. Even though we added comments to ask WPTG to translate the ALL CAPS words, they still come back untranslated. Our QA team reported bugs to WPTG, but they just said they don't translate ALL CAPS words, even if the comment asked to translate them.

Deployment team has a workaround and I am sharing it here, hoping you can find the solution doable for logging.properties. Thanks!

{ "security.dialog.notverified.subject", "Unknown" },

        // Show dialog
        if (Trace.isAutomationEnabled() == false) {

            if (rootCANotValid) {
                // note - security team wanted uper case "UNKNOWN"
                // here but all caps stings are not translated, so
                // the string is lowercase and translated and we
                // display it in upper case.
                subjectName = getMessage(

Our next jdk8 translation drop date is 8/22 (it's also message freeze date). I would be much appreciated if you could help to look into this by that time.
The changeset for this bug will also contain JDK-8024131

Translation team tried to use a workaround to get these strings translated. However, it's only translated in some languages but not all languages. The translators were trained to follow Oracle standard of NOT translating all caps words, and translators for some languages follows it strictly. So now, the strings are translated for zh_CN, zh_TW, ja, it only. I think we still need to adhere to Oracle standard of not using ALL CAPS words to avoid this issue. The message freeze is 9/5 (was 8/22). Thanks.

Hi Michael - is this bug still an issue for JDK 8? Or is the issue now resolved?

Yes, you may manually revert the 7u40 l10n files back to previous revision for now.

Add back 7u40 in the affect versions. Michael - thank you for working with WPTG to discuss the options to get capitalized strings be translated. I hope this will be resolved soon in time for jdk8. We were not aware of the 7u40 change reverting the translated strings back to English (sorry I saw the review request but we are new to the logging area and didn't know it's impacted). We need to get the translated logging.properties back in 7u40 as soon as possible. Are you okay if we revert the logging_xx.properties to the previous revision? This needs to be fixed in the next couple days.

WPTG has already updated 7u40 logging_xx.properties files. The translated strings are now back to English. I was discussing with WPTG and there is hope to apply some workaround on their side to get these translated. Currently, these resources are marked as non-translatable on their system, and there may be a way to manually mark them as translatable the next time we have a translation drop. I will continue to discuss with them about this option.

Michael - will WPTG update the logging_xx.properties files in 7u40 forest? I assume this is jdk8 only bug - can you confirm?

I just checked jdk8 repo. The current files are localized, but it's because I manually copy and paste the translated strings into the files from old translation as bug fix for 7021691. But the new translated logging_xx.properties files delivered by WPTG that's going to be pushed into jdk8 forest do not have these translations and our QA team is catching them in PIT testing. So, we still have to conform to Oracle's translatability standard unfortunately... The workaround is only applied to English locale in the deployment code because the the UX designer wants to have ALL CAPS text in English text. But, WPTG owns the translation for all Oracle products and they do not want ALL CAPS translation according to their policy.

Michael - the logging.properties has been translated. There is no plan to change the logging.properties and I think there is close to zero chance to modify it in the future. The only issue is when JRE supports a new language/locale. Is there any problem to leave it as it is (assuming no change to this file and no new locale/language is added to the JRE supported config)? I am not sure if the workaround the deployment uses would work for logging. In FR locale, what would "Grave".toUpperCase() do? ("Grave" is the french-translated version of "SEVERE" according to logging_fr.properties) Would it impact any existing application if it begins to print "GRAVE"? If we had to do anything, I think it would need to check if it's the defined list of levels (SEVERE, WARNING, etc) and in english/default locale, Level.getLocalizedName() will return its name.

Reassign to Daniel. core-libs owns logging.

Pretty cool idea for a work around. I still think it is INSANE that the WPTG folks won't translate ALL CAPS words even when we've provided a detailed justification for such translation. Unfortunately (or fortunately), I no longer work in this area. I left the Serviceability team several years ago. I'm going to assign this bug to Staffan Larsen who is the lead of the new Serviceability team in Stockholm. He'll figure out who should pick this up. Staffan, the trail starts with https://jbs.oracle.com/bugs/browse/JDK-7025302