XML and XSL offer an easy way to internationalize content

XML and XSL provide an effective mechanism for internationalizing content. By tweaking property files on the server, you can dynamically switch XSL files.

The idea of sourced XML data (business logic) is simple: Create an ASCII file or memory location that can be used by XSL style sheets (presentation logic) to show content for a browser, cell phone, or just about any calling device. But what if you have to build an internationalized product—say, one that offers content in English and Korean?

Allowing your server to switch XSL files dynamically is one solution. For instance, servers using a property file can control such things as your database URL and driver name. But along with those items, operations that produce views manipulated by the XSL parser should also be listed in the property file.

Serving up English and Korean content
Suppose your property file has a command of getLogin, which maps to an English US file, agentLogin_en_US.xsl:

When your application goes Korean, your server recognizes that the calling device’s language is set to ko and thus your internal command in the server becomes getLogin_ko. The property file now has an additional entry:

What about redundant logic in the multiple XSL files, if any? Well, there is none, because the Korean XSL file holds only the Korean strings defined as XSL parameters and imports the English XSL file. The English XSL file is still your main file, holding all of your logic, which for this application is HTML and JavaScript.

When you design your style sheets you should place all of the text that is displayed to the user into XSL parameters. Your server controls these parameters by changing the text dynamically.

More XML content

An example XSL setup
Let's look at how you might set up the XSL files to handle the delivery of both Korean and English content. Listing A shows the code for each file.

You may also hard-code the foreign language values, either by having the server provide the text values or by having the XSL files shipped with static content; both ways work just fine.

Easy debugging
By listing the operations in the property file, you command a powerful way of steering the request to a different style sheet that produces a different view of the data. This method also offers you an easy means to test content. QA engineers can simply change the property file's command pointer to a debug XSL file and resend the command. A debug XSL file can be set up to output the raw XML data (as received from the database), thus allowing the engineer to surmise (hopefully) that the data is valid in the XML stream. In my next article, I will explain how to set up your design to allow QA to test for any problems with XML-XSL.

Editor's Picks