JavaScript's Lack of i18n Support and What It Means for You | 2

JavaScript's Lack of i18n Support and What It Means for You [con't]

Why So Little i18n Support?

It may seem like the ultimate oxymoron to have a web browser scripting language with so little i18n built in, but it's no oversight. The underlying philosophy of JavaScript was always to rely on platform services (i.e. O/S and browser) as much as possible, while requiring very little of the interpreter. This is important because it is well known that scripts -- which are interpreted and evaluated at runtime -- don't run nearly as fast as compiled languages. By relying on platform properties, the scripting engine can circumvent complicated calculations, as well as the need to support large data tables and time-consuming lookup algorithms.

The flipside of this architectural decision is that you the developer must write code with i18n in mind, so that scripts don't behave in unexpected ways. While all of the points raised in the Internationalizing a Locale-specific Application in Java article apply, perhaps the most troublesome and obvious sticking point is that of message translation. As described in the On-demand JavaScript Explained article, it is not difficult to store text for each language in a separate .js file and load the appropriate one at runtime. The following example sets the src property of the <SCRIPT> tag to a matching labels script, depending on the value of the language portion of the local identifier (IE: the en in en_US):

<head>
...
<script type="text/javascript" src='englishLabels.js' id="dynaScript"></script>
<script type="text/javascript" language="">
    function setLanguageScript()
    {
        var browserLocale  = navigator.language || navigator.browserLanguage;
        var languageScript = "";
        switch(browserLocale.substr(1,2))
        {
            case "fr":
                languageScript = "frenchLabels";
                break;
            case "de":
                languageScript = "germanLabels";
                break;
            case "it":
                languageScript = "italianLabels";
                break;
            default:
                //already handled
                return;
        }
        document.getElementById('dynaScript').src = languageScript + ".js";
    }
    function showLanguageScript()
    {
        alert("This page is using the " + document.getElementById('dynaScript').src + " script.");
    }
</script>
</head>
<body bgcolor="#FFFFFF" onload="setLanguageScript();showLanguageScript()">

By default, the dynaScript src points to the englishLabels.js script, but this value is overwritten should the locale language match one of the cases in the switch statement. The showLanguageScript() method confirms which script is loaded.

That is better than no i18n support at all, but in some ways, providing multiple language versions of a script is the opposite of how internationalization and localization of software are generally done. Unlike the application-level code of true i18n applications, which separate all localizable content from the source code and load display text from separate resource bundles or data stores, you still wind up with programming code that stores hard-coded display text. The inflexible nature of this approach becomes evident when you try to create a compound message, as in the following code:

Printing a properly formatted and grammatically correct string is simple enough: just call a few helper methods:

You have purchases 2 large widgets, at a cost of $90.24 dollars. Thank you for your order.

However, in other languages, the idea quickly falls apart. For instance, in French, the "large" adjective comes after the "widgets" subject. That's why compound messages are strongly discouraged in the realm of i18n programming!

A Better Way

After spending weeks discussing Java's excellent i18n support, perhaps our search for more effective alternatives should start there.

Harnessing the Power of Sever-Side Languages

One technique that capitalizes on the built-in functionality of server-side languages such as Java is to set JavaScript strings dynamically in server-side code and pass them to the client-side script. The lingoport JavaScript Internationalization -- the Good, the Bad, and the Ugly article presents it eloquently. What makes this technique work is that the server parses the page before sending it to the client, long before JavaScript is evaluated. This allows a server-side language to perform a lookup based on the client's locale -- perhaps even one of the client's choosing, via a dropdown list or other control -- and populate JavaScript string literals:

The rendered page source will contain the following translated text, in English:

...and in French:

The limitation to this technique is that it does not allow for any dynamic text retrieval because all of the values must be set before serving the page to the client. However, one of the perks of Ajax is that it permits seamless interaction between the browser and server. We'll be taking a look at implementing i18n using Ajax in the next article.

Have a suggestion for an article topic? Do you have a product or service that you'd like reviewed? Email it to Rob .

Rob Gravelle combined his love of programming and music to become a software guru and accomplished guitar player. He created systems that are used by Canada Border Services, CSIS and other Intelligence-related organizations. As a software consultant, Rob has developed Web applications for many businesses and recently created a MooTools version of PHPFreechat for ViziMetrics. Musically, Rob recently embarked on a solo music career, after playing with Ivory Knight since 2000. That band was rated as one Canada's top bands by Brave Words magazine (issue #92) and released two CDs. Rob's latest release is called "The Rabbit of Seville". Loosely based on Rossini's The Barber of Seville overture, Rob's amazing rendition includes a full orchestra and numerous guitar tracks. It is sold on his site as a high bitrate MP3 for only $0.99 cents! Rob is available for short-term software projects and recording session work. to inquire, but note that, due to the volume of emails received, he cannot respond to every email. Potential jobs and praise receive highest priority!

Original: August 4, 2010

[prev]

JavaScript's Lack of i18n Support and What It Means for You | 2

JavaScript's Lack of i18n Support and What It Means for You [con't]

Why So Little i18n Support?

A Better Way

Harnessing the Power of Sever-Side Languages

Find a programming school near you