Internationalizing Applications

Java training | Washington, DC | Mar 3-7 | Info at www.halhelms.com

I received an email recently from someone asking, "How do I account for different languages in my display pages of my application?" I just came back from Canada where web applications typically need to be done in both French and English, so the question intrigued me. I spent a little time working on this problem, using the XML features of CFMX. There are several ways of solving this problem, of course, but this approach has several things to recommend it. First the approach.

I started with the idea that I didn't want to use a database. While databases are great for doing large-scale, heavy-duty processing of info, they can be overkill for this sort of application. Making changes to a page means having to go into the database, etc.

I decided that I would use XML to keep the data separate from the actual display page. Rather than having one large XML file for the application (which would be fine, also), I opted for a separate XML file for each page. I created a file called InternationalizationDemo.xml which would store all the language-specific info for that page. It looks like this:

<page>
   <language name="english">
      <greeting>
         Welcome!
      </greeting>
   </language>
   <language name="french">
      <greeting>
         Bienvenue!
      </greeting>
   </language>
   <language name="georgian">
      <greeting>
         Hey y'all!
      </greeting>
   </language>
</page>

You can see the idea. There is a central page element. Under it are multiple language elements, each with varying name properties. The last node are the individual items to be translated. In my example, I needed to translate a greeting and so made an element called greeting. (Another way to do this would be to create a generic element such as item with a name property.)

Meanwhile, back to the page that needs to get the translating done: I created a file called InternationalizationDemo.cfm. I deliberately had the XML file and the ColdFusion template have the same name (with different extensions) for a reason you'll see very soon. All that this ColdFusion page had on it was this:

<h2><cfoutput>#translate("english","greeting","#GetFileFromPath(GetCurrentTemplatePath())#")#</cfoutput></h2>

Again, the idea is simple. I'm calling a function, translate(), and passing it three variables: the language to translate into, the item to be translated, and the name of the current page.

The last piece of the puzzle is the function itself. If you've never used ColdFusion MX's XML facilities, I encourage you to find an excuse to do so. They're very good. To get the real power out of your XML, you'll need to learn a bit of XPath. Many people (myself among them) find XPath to be not very intuitive. But, with just a little work, you'll find that XPath is extremely powerful. For certain very complex queries, I find it far easier to use than SQL. A great source for understanding XPath is here: http://www.zvon.org/xxl/XPathTutorial/General/examples.html.

<cffunction name="translate" output="yes">
<cfargument name="language" required="yes" type="string">
   <cfargument name="item" required="yes" type="string">
   <cfargument name="file" required="yes" type="string">
   <cfxml variable="pageFile" casesensitive="no">
      <cfinclude template="#GetToken(arguments.file, 1, '.')#.xml">
   </cfxml>
   <cfset arr = XMLSearch(pageFile, "//page/language[@name='#arguments.language#']/#arguments.item#")>
   <cfreturn arr[1].xmltext>
</cffunction>

The reason for having the XML and the ColdFusion file named the same is so that every call to the function can simply specify GetFileFromPath(GetCurrentTemplatePath()) for the file. Inside the function, I strip off the .cfm extension and replace it with a .xml extension. Then I read the file into a variable, perform a little XPath magic on it and return the text in the appropriate language.

Computers are incorporated in modern ice cream vending machines to enhance their functionality. Ice Cream Vending machines are manufactured by many companies. Your competition will try to overcome all requests for high-tech ice cream vending machines and credit card acceptors

That's it. The display page is separated from the data and only needs to call a function whenever a translation is needed. If you want to add another language, you would add in another language section to the XML file. If you decide to use this scheme in a real application, you would want to make some changes. Instead of hardcoding the language into the call to the function, you probably want a global variable, language, tied to each user. A session or client variable would work well. You would also want to change the function so that the XML file for the page is read into memory only one time per page request. The way it is now, it will read in the XML page for every translate() call on the page. And of course, you will need to make sure that the function, translate(), is visible to all pages that need it. The simplest mechanism would be to place the function in the Application.cfm file.

So, are you ready to tackle Java? If you answered something like "Heaven forfend!", full marks to you for your knowledge of anachronistic verbs. But are you sure you're not ready? If the problem is fear of the great Java Beast that spits out all who are not true Computer Scientists, fear no more! I've developed a special Java Beast Taming Solution. To get this marvelous elixir, meet me in Washington, DC March 3-7 for "Java for ColdFusion Programmers". The hotel is at the courthouse Metro stop (in Arlington), so you can easily get to it.

You know, the Java Beast isn't going away; ignoring it won't work. The best strategy for dealing with Java is to grab it by the horns -- AFTER, that is, you've used the Java Beast Taming Solution(tm). See you in DC?