Bug 588375

Adding the contents of an email I sent to the developer list describing the issues so that the information is captured in the bug report.

---------------------------------------------------

Unfortunately the bug and the one it was cloned from contain a number of 
extraneous issues unrelated to the actual problem so let me summarize 
the actual issue.

Summary
-------

If the locale is not en_US then a java.util.MissingResourceException is 
thrown with the message "Can't find bundle for base name LogMessages". 
Although the error is reported against the LogMessages property file the 
same problem exists for the UserMessages property file.

The error occurs because the messages are part of a ResourceBundle 
*family*. Resource bundles belong to families whose members share a 
common base name, but whose names also have additional components that 
identify their locales. If the locale specific bundle cannot be located 
then the family name is used (e.g. a name *without* a locale suffix).

For the example cited in the bug the following would happen:

1. Locale is set to de_DE

2. ResourceBundle.getBundle("LogMessages") tries to locate 
"LogMessages_de_DE" which fails.

3. ResourceBundle.getBundle("LogMessages") then tries to locate the 
default bundle "LogMessages" which also fails because only the locale 
specific "LogMessages_en" is available. It then throws an exception.

Solution
--------

The message bundles need to be installed without their locale suffix.

Issues
------

1) The message bundle can either be renamed in the source tree or via 
Ant during the build.

2) We might want to consider installing both the base bundle and the _en 
locale specific file even though they would have the same contents for 
clarity purposes. This would best be done via symlink but symlinks are 
only available on Unix platforms.

Recommendation
--------------

I would prefer to rename LogMessages_en and UserMessages_en in the 
source tree without the _en locale suffix because then it is clear this 
is the default base of the family. This is also consistent with how 
translations are typically handled in GNU Gettext (the most common i18n 
support package). In Gettext the "master" file is called a .pot file and 
it typically has the messages in english, it is then used to derive the 
locale specific .po files which have their locale embedded in their 
filename.

Would renaming the files in the source tree cause heartburn or problems 
elsewhere?

Since we probably don't want to depend on symlinks and it isn't really 
necessary to also install a _en or _en_US bundle (because if those 
aren't found it will default to the base bundle which is english) we can 
punt on installing the extra bundle.

I have implemented and tested both solutions (either renaming the files in the source tree or renaming them via ant.

If we want to rename in the source tree then:

% svn move LogMessages_en.properties LogMessages.properties 
% svn move UserMessages_en.properties UserMessages.properties 

Index: base/common/build.xml
===================================================================
--- base/common/build.xml	(revision 1111)
+++ base/common/build.xml	(working copy)
@@ -130,8 +130,8 @@
         </jar>
         <jar jarfile="${build.jars}/cmsbundle.jar">
             <fileset dir="${src.dir}">
-                <include name="LogMessages_en.properties"/>
-                <include name="UserMessages_en.properties"/>
+                <include name="LogMessages.properties"/>
+                <include name="UserMessages.properties"/>
             </fileset>
         </jar>
         <echo message="${end.build.jars.log.message}"/>


If we want to retain the existing file names but have ant install both the base family and the locale specfic files, then:

Index: base/common/build.xml
===================================================================
--- base/common/build.xml	(revision 1111)
+++ base/common/build.xml	(working copy)
@@ -128,9 +128,13 @@
                 <include name="com/netscape/cmscore/**"/>
             </fileset>
         </jar>
+	<copy file="${src.dir}/LogMessages.properties" tofile="${src.dir}/LogMessages_en.properties"/>
+	<copy file="${src.dir}/UserMessages.properties" tofile="${src.dir}/UserMessages_en.properties"/>
         <jar jarfile="${build.jars}/cmsbundle.jar">
             <fileset dir="${src.dir}">
+                <include name="LogMessages.properties"/>
                 <include name="LogMessages_en.properties"/>
+                <include name="UserMessages.properties"/>
                 <include name="UserMessages_en.properties"/>
             </fileset>
         </jar>

Created attachment 425257 [details]
patch if rename in svn

Created attachment 425258 [details]
patch if ant installs copy

I agree with changing the filenames will solve the problem. But as I described in Bug 583177 there is one more to rename.

Package: dogtag-pki-console-ui

File: build.xml
-pki-console-theme-${version}_en.jar
+pki-console-theme-${version}.jar


File: dogtag-pki-console-ui.spec

-ln -s pki-console-theme-%{version}_en.jar pki-console-theme_en.jar
+ln -s pki-console-theme-%{version}.jar pki-console-theme.jar

-ln -s ../pki-console-theme_en.jar cms-theme_en.jar
+ln -s ../pki-console-theme.jar cms-theme.jar



Package: pki-console

File: templates/pki_console_wrapper

-pki-console-theme_en.jar
+pki-console-theme.jar

-cms-theme_en.jar
+cms-theme.jar



Best regards,
Oli

Hi Oli:

Could you please describe why the jar files need to be renamed as well? Specifically what problems did you see because of the jar file names?

I have not been able to reproduce any failures when the locale is not en_US related to the jar names.

Created attachment 426908 [details]
rename LogMessages & UserMessages property files

This patch fixes the resource bundle names by renaming the files in SVN and updating the ant build.xml file to use the new names.

Oli has commented on the bug and asserted that is not sufficient and that some of the jar files also need to be renamed. I have not been able to find a logical reason for why a jar file with _en in it's base name would be a problem. Nor have I been able to reproduce any failures during installation, runtime, and with pkiconsole when both the system locale and user locale are de_DE (other than the problem with the resource bundle names).

My suggestion at the moment is to just fix the resource bundle names with this patch. Later if we identify and understand why the jar names would produce a failure when can produce a new patch to address that issue.

attachment (id=426908) +mharmsen

Installation successful with IPA v2 HEAD against pki-common-1.3.8-1.fc12.noarch after using system-config-language to set the locale to fr_FR.