I18N Testing: Products that Use Java Resource Bundles

Print-friendly Version

Verifying that Messages Come from Locale-specific Message Files

The purpose of this type of testing is to verify that all appropriate strings have been internationalized and that innapropriate ones have not. This applies to button and menu labels, footer and other window text messages, and command line messages.

Simply checking the source code is not sufficient. In some cases it is unclear that a string should be messaged until a problem arises when the program is run. Even when a string in the source code is wrapped with the correct message call, the string must access the correct message class file.

Approach

A good approach is to bracket each message with a prefix and suffix, then create a modified message class file and install it in another locale. For multibyte locales, at least part of the prefix and suffix should contain multibyte characters.

Assume that the original message files are text files with lines of the form key=value. We assume that the message file is made into a .java file, then compiled to a .class file. When:

• the messages are translated using the prefix and suffix;
• the message file(s) are made into a .java file;
• the .java file is compiled to a Java ResourceBundle class file with the appropriate locale-specific suffix, and is properly installed in locale-specific locations or in the default location (since its the locale-specific suffix that is used)

For example, given a message file named xx.messages, after translation a script converts it to a file named MyClass.java. Then MyClass.java is compiled--assuming it will be installed in the ja locale--into MyClass_ja.class. This class file is then installed in the appropriate location so that the product can find it.

The prefix and suffix can be long enough to make the total message length up to 200% larger than the original message. These longer messages can also show that various widgets are able to resize to handle longer strings.

How to Test

• Access the default message files.
• Translate them using a prefix and suffix as discussed above.
• Convert the message file into a .java file. See the example below.
• Compile the translated message files to the proper .class files using the java command.
• Install the compiled message files at their proper locations in the desired locale. For Java ResourceBundles, you can install the files at the same location as the default or other locale-specific message files, since it is the locale-specific suffix that is used to find the message files.
• Use the setenv LANG XX command, where XX is the locale to be tested.
• Run the product from this test locale. Verify that all messages have the prefix and suffix you inserted, to indicate that they come from the modified message catalog.

Sample Programs

NOTE: These tools and scripts are customized for testing the messages in a certain product. These tools and scripts are working versions and will probably need customization for your product.

There are other approaches one could take to implement what these tools and scripts do.

In the examples below, message files and non-message files, both localizable and non-localizable, are all placed in two .java files. They are then compiled into a .<locale>.class file and installed. The locale-specific .class file is named XX_YY.class, where XX is the classname and YY is the suffix of the locale, such as fr or ja.

• This is the actual perl program that actually modifies each message file with the prefix and suffix.
• This program calls the perl program that modifies each message file with the prefix and suffix.
• This is the program that creates a .java file from the prefixed and suffixed message file (with the key=value format).
• This script calls the program above with the expected arguments
• This is a sample localizable message file before the script inserts prefixes and suffixes.
• This is a sample localizable message file after the script inserts prefixes and suffixes.
• Sample of parts of a .java file that is made as a result of running the script that converted the message file into a .java file. This was generated for the ja locale and some characters may not show correctly unless you have Japanese fonts on your system.