Programming Product Review | Send Java Around the World (Web Techniques, Sep 200

As far as multiple computing platforms are concerned, Java pretty much lives up to its "write once, run anywhere" slogan. When it comes to supporting applications that have to run anywhere on the planet, though, things didn't always look so great.


January 01, 2002
URL:http://www.drdobbs.com/programming-product-review-send-java-ar/184413658

Web Techniques: Figure 1

Figure 1


What's the problem here? The Sun Intertionalization Verifier is capable of identifying a wide range of localization-related issues hidden in your code.

Figure 1


Web Techniques: Figure 2

Figure 2


Let's go Dutch. The Translator component of the Sun toolkit lets you translate your resource bundle files in their original format.

Figure 2


Web Techniques: Figure 3

Figure 3


Easy on the untrained eye. Multilizer's translation utility separates your strings from the associated code, making things easier for translators not familiar with the intricacies of Java source files.

Figure 3


Programming Product Review | Send Java Around the World (Web Techniques, Sep 2000)

Send Java Around the World

By Michiel de Bruijn

As far as multiple computing platforms are concerned, Java pretty much lives up to its "write once, run anywhere" slogan. When it comes to supporting applications that have to run anywhere on the planet, though, things didn't always look so great.

Java's native mechanism for localization—resource bundles—is very awkward. And though it has been around since early versions of the Java Development Kit (JDK), support for the feature by mainstream IDEs is still quite limited. You can try to avoid resource bundles by maintaining separate source code for each language version, but you'll run into version and feature control nightmares. So, having strong localization support in or near your IDE is really the only way to deal seriously with the issue. But just as localization tools for the Microsoft and Apple platforms were quick to appear on the market, plenty of third-party help is now available for Java developers. Two products that take distinctly different approaches to the issue are the Java Internationalization and Localization Toolkit (or JILT to its friends) from Sun's China Technical Development Center, and the Multilizer Java edition from Finland-based Multilizer, Ltd.

100-Percent Pure Globalization

As the name already implies, JILT is pretty much a one-stop shop for making your applications work outside the U.S. Consisting of five components, it offers both a Swing-based user interface and full command-line functionality for use in automated processes.

Sun Java Internationalization and Localization Toolkit 2.0
Sun Microsystems
java.sun.com/products/jilkit
Free
Multilizer Java Edition Pro 2.0
Multilizer Ltd.
usa.multilizer.com
$390; Standard Edition: $190 (source available at additional cost)

The toolkit also exposes an API to allow easy integration with IDEs and other SDK components, but at this time no major commercial products are using this functionality. Still, having some do-it-yourself flexibility in a product is always a good thing.

JILT comes with its own Project Manager module, which offers make-like functionality to keep your source code and associated resources in sync. Its GUI also offers easy access to the other tools in the package. For source files that haven't been localized yet, the first tool you'll typically use is the Internationalization Verifier (or I18n Verifier, if you don't like spelling out insanely long words, but aren't put off by semiphonetic abbreviations). Based on default policies and, optionally, user-defined rules, this tool will generate a line-by-line report on internationalization issues with your code.

This isn't limited to identifying all strings that are likely candidates for localization, but will also tag issues like improper use of fonts and other locale-sensitive methods. This is great for inexperienced developers and seasoned localization pros alike: It's just too easy to overlook the fact that the width of a certain string in your user interface will vary wildly depending on the target language.

For example, Figure 1 shows I18n Verifier's comments on our simple test "hello world" applet when using the default system policies. The format in which the required changes are presented is extremely useful, and the breadth of the checks performed is helpful as well.

Next you'll need to address the identified issues, and the Message Tool is just what you need. Reusing the output of the I18n Verifier, the Message Tool lets you instantly define one or more resource bundles and convert your code to use these without a manual search-and-replace.

Even better, the Message Tool keeps track of the problems you've already dealt with and which ones remain. It also lets you "freeze" strings that don't need any localization, preventing overzealous translators from messing up your database connection strings and other constants.

Other powerful features include Message Tool's ability to automatically recognize message concatenation and generate the necessary code, as well as its support for extended and user-defined resource bundles. The only thing I found lacking was support for revision control, but I'm sure you could use the extension API to add that yourself, given enough time.

The Translator is JILT's final tool, unless you count the Resource Tool. The Resource Tool is a simple utility for converting resource bundles from one type of bundle to another. It's also the tool that the person doing the actual localization will use most.

Figure 2 shows the resource bundle file for our sample Java app as it's being translated into Dutch by the Resource Tool. As you can see, Sun didn't make much of an effort to hide the format of the actual source file from the translator. Developers won't consider this a problem, as they get to see the context of the translation, but it might confuse non-Java-enabled persons.

However, once you get over that hurdle, the Resource Tool works really well. If you load a dictionary file before beginning your translation, the app will suggest translations as you type. (When you download JILT, a sample English-to-Chinese dictionary is included.)

Once the translation is complete, the only thing left to do is compile the JILT-modified version of your source code, and distribute the results along with the resource bundle files you created for one or more locales. The productivity gains you can achieve with this freely downloadable toolkit are impressive.

The Magic Bullet Theory

Multilizer, brought to you by the Finnish company of the same name, takes an almost opposite approach from JILT. It does away with resource bundles completely, and instead provides you with its own set of JavaBeans that can instantly add localization functionality to your projects.

By simply adding references to Multilizer's Dictionary and Translator beans to your code, loading a dictionary file containing the translations for the existing strings in your program and instantiating the translator component, your app should get localized instantly.

This mode of operation certainly sounds attractive on paper, but does it work? To find out, I first modified our sample Java applet to include the Multilizer support code. Easy enough, so far.

The next step is using the Language Manager utility (see Figure 3) to create the dictionary file, and localize its contents. If you download the evaluation version of the Java edition from the Multilizer Web site, you'll find that for some strange reason the Language Manager isn't included. You'll have to download the Visual Basic edition to get it.

Other than that, the Language Manager translation process is pretty straightforward. As with JILT, you can benefit from existing dictionary files by having the program suggest previously used translations. Simple sample glossaries for English-to-Finnish translations are included with the product.

After saving the new dictionary and running your app, you'll find it is indeed fully localized, provided the right strings were extracted in the first place. You can control this process by specifying the names of the properties you want to localize, but unfortunately it's not possible to automatically exclude certain strings. You also can't automatically include nonproperty strings; you'll have to modify your code to accommodate those yourself.

Among Multilizer's more flexible features are its ability to switch languages at runtime, support for multiple dictionary formats, and the Multilizer Dictionary Server, which lets applications retrieve translation strings using TCP/IP from a central server. Performance will be directly related to network conditions in this case, but the added flexibility may be worth the trouble, especially for intranet applications.

Multilizer comes in two editions: Standard and Pro. The first supports only U.S./European character sets, whereas the latter adds support for any character set recognized by the target JVM. According to the FAQ on the Multilizer Web site, though, only Japanese is officially supported as of this writing.

Picking the Right Tool

Which one is the best to help you bring your Java applications to the global marketplace? As always, it depends on your exact circumstances. Although, in this case, the Sun toolkit clearly has an edge.

Not only can you download JILT for free, but the product functionality and quality are also impressive, and you don't need any proprietary code to get your app to work.

The Multilizer product, on the other hand, not only requires you to pull out your credit card—although it's reasonably priced—but also has some quality problems. The Java edition is packaged in a confusing way and lacks IDE integration. Also, despite sporting a 4.0 version number, the Language Manager utility has some very visible and annoying screen redraw problems. And the lack of an automatic nonproperty string extraction utility or the capability to manage fonts is definitely an issue.

Still, Multilizer will be just enough for some people. For example, if you have limited access to the source code of the application that needs to be localized, the product works very well. Also, if your localization team isn't very familiar with Java, they'll definitely prefer Multilizer over the JILT approach. Because both products are available online, you should be able to find the best solution for your situation quite quickly.


Michiel lives in Rotterdam, The Netherlands, and spends his days as a networking and development specialist for an international media group. He always welcomes questions and comments; reach him at [email protected].

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.