Internationalize dynamic messages

Build flexible formatters for international applications with Java 1.1

By Todd Sundsted, JavaWorld.com, 02/10/98

This awkwardness comes from a number of sources -- some related to poor word selection and some related to differences in the syntax of the two languages.

From the perspective of the programmer rewriting the software in a new language, the words are usually the easiest part of the code to get right. For example, when you change the strings in the code from English to German, "Yes" becomes "Ja," "No" becomes "Nein," and so on. Pretty simple stuff. Even simple phrases, such as "Do you wish to proceed?" can be replaced in their entirety with the appropriate translation.

If translations were limited to these simplistic examples, there would be no problem. Consider, however, the following example of a compiler diagnostic:

"There are 3 errors in 2 files"

Unlike the earlier examples, this example contains two pieces of information that change depending on the result of the compilation: the number of errors and the number of source files compiled.

A naive implementation of the code to generate this diagnostic might look like this:

   String str = "There were " + nErrorCount +
                " errors in " + nFileCount +
                "."

In this case the variables nErrorCount and nFileCount hold the number of errors and the number of files, respectively.

Imagine that we wanted to make it possible to display this compiler diagnostic in other languages. Using resource bundles and the resource bundle API (which we covered in detail in last month's column), we could easily modify the code so that it doesn't contain any non-localized text.

   ResourceBundle res = ResourceBundle.getBundle("Strings");
   String str = res.getString("first") + " " + nErrorCount +
                res.getString("second") + " " + nFileCount +
                res.getString("third");

The resource bundle keys "first," "second," and "third" in the resource bundle named "Strings" are associated with the textural pieces that make up the diagnostic. Now, each piece of the original can be translated and placed in the appropriate resource bundle -- and the appropriate string will be constructed at runtime. We're in great shape, right?

Wrong!

The example above contains implicit assumptions about the position and order of the elements that make up the text. That might not seem like such a problem, but it is.

A closer look

Consider the following three phrases:

"You copied 3 files"

"You deleted 2 files"

"You moved 0 files"

These three statements are identical except for the operation (copied, deleted, and moved) and the number of files affected (3, 2, and 0). Let's call the operation, parameter zero {0}, and the number of files, parameter one {1}.

Here's the phrase with the operation and number of files affected replaced by parameter marker zero and one.

"You {0} {1} files"

What if, like the Japanese language, the English language required the verb to be at the end of the sentence? Our three phrases then become: