Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Server-side Java: Internationalize JSP-based Websites

Build Websites that speak in tongues

By Govind Seshadri, JavaWorld.com, 03/06/00

Page 2 of 6

Developing global Web applications

In this example, the Music Without Borders online store has been localized to support users not only in the US, but also in Germany, Sweden, and France. Listings 1 and 2 show the property files supporting the locales for the US and France. (You can obtain the property files for Germany and Sweden when you download the source code for the example in Resources.) As you can see, the property files essentially isolate all of the GUI elements from the JSP pages. The property files for bundles must follow some standard naming conventions. The suffix must always be properties. Also, since a locale is typically defined in Java via a country code and/or a language code and an optional variant, the name of the bundle has to correlate with the locale it serves. For instance, all of the following bundle prefixes are valid:

BundleName + "_" + localeLanguage + "_" + localeCountry + "_" + localeVariant
BundleName + "_" + localeLanguage + "_" + localeCountry
BundleName + "_" + localeLanguage
BundleName

Observe that the property file serving as the bundle for France (shown in Listing 2) was named Message_fr_FR.properties. Bundles pertaining to a specific country need to have both the language code and country code appear within the prefix. (I could also have used the optional application-specific variant and further specialized the file as Message_fr_FR_MAC.properties -- the bundle for all French-speaking Mac users from France. But I shall resist the temptation!) Similarly, the bundle containing the German labels is named Message_de_DE.properties, and so on. Resources contains links for obtaining valid country and language codes. For the overly curious, the following code shows the source you can use to create a classfile, serving the same purpose as the property file shown in Listing 2:

public class Message_fr_FR extends ListResourceBundle {
        public Object[][] getContents() {
                return contents;
        }
        static final Object[][] contents = {
                {"main.title", "Musique sans frontières"},
                {"main.subhead", "Sons du village global"},
            {"main.addLabel","Ajouter"},
             . . .
            {"cd.quantityLabel","Quantité"}
        }
}

You might wonder why the property file containing the English labels (shown in Listing 1) does not contain a country or language code in its prefix. Although I could have named the bundle Message_en_US.properties, I chose to simply call it Message.properties. Any bundle that contains neither country nor language code is treated as the default bundle and serves a specific purpose: it is picked up as a last resort if there is no other matching bundle for the requested locale. Observe that the literals used to identify resources remain the same within the bundles for all locales; only the values change for the corresponding locale. Now that I have isolated the GUI elements and localized them within the property files, I'll show how you can use them within a JSP page.

Listing 1: Message.properties

main.title=Music Without Borders
main.subhead=Sounds from the Global Village
main.addLabel=Add
main.qtyLabel=Quantity
main.bgcolor=#33CCFF
cart.bgcolor=#FFFFFF
cart.delLabel=Delete
cart.checkoutLabel=Checkout
checkout.bgcolor=#33CCFF
checkout.title=Music Without Borders Checkout
checkout.subhead=Thanks for your order!
checkout.totalLabel=Total
checkout.returnLabel=Shop some more!
dollar.exchRate=1.00
cd.albumLabel=Album
cd.artistLabel=Artist
cd.countryLabel=Country
cd.priceLabel=Price
cd.quantityLabel=Quantity

Listing 2: Message_fr_FR.properties

main.title=Musique sans frontières
main.subhead=Sons du village global
main.addLabel=Ajouter
main.qtyLabel=Quantité
main.bgcolor=#33CCFF
cart.bgcolor=#FFFFFF
cart.delLabel=Supprimer
cart.checkoutLabel=Passez à la caisse
checkout.bgcolor=#33CCFF
checkout.title= Caisse pour Musique sans frontières
checkout.subhead=Merci pour votre commande!
checkout.totalLabel=Total
checkout.returnLabel=Faites d'autres commandes!
dollar.exchRate=6.48
cd.albumLabel=Album
cd.artistLabel=Artiste
cd.countryLabel=Pays
cd.priceLabel=Prix
cd.quantityLabel=Quantité

The JSP page i18nDemo.jsp (shown in Listing 3) acts as the gateway to the online store. Its main task is to enable the user to select an appropriate language for viewing the site, as shown in Figure 1.

Figure 1. Gateway to the internationalized Web application