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

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

By Rob Gravelle


[next]

Ubiquitous as JavaScript may be, many dissenters would rather eschew it in favor of full-fledged languages such as Java and ASP.NET. They cite many valid reasons, such as the difficulties associated with testing and debugging, and its weak typing to name a couple. Now add an atrocious lack of i18n support to that list. Compare it with Java's extensive integrated i18n functionality, and it's not hard to understand their reasoning. Unfortunately, there are simply too many good reasons to use client-side scripting to avoid JavaScript altogether. So, until the day that it supports i18n more fully, let's see what we can do to make it better.

How i18n Is Implemented in JavaScript

The JavaScript interpreter relies on the default locale of the browser to perform locale-sensitive operations, such as sorting as well as the formatting of numbers and date/time values. The default locale is available to JavaScript via the navigator object. Mozilla-based browsers such as Firefox store it in the language property, and Internet Explorer uses the browserLanguage. Here's a short script that displays the browser language. You can add it to any web page to see what language your browser is running under.

Here is what came up in my browsers:

Figure 1. Internet Explorer Browser Language

Figure 2. Firefox Browser Language

This value does not match my PC's default locale, which is set to English Canada (en_CA). That's because the browser locale is part and parcel of the particular browser build that you installed. For that reason, you have to be sure that you install a browser that's built for your particular locale. Otherwise, you could run into some issues.

There are a few locale-aware methods in JavaScript for displaying dates and times as strings, but again, these depend on the browser's default locale. They are:

  • toLocaleDateString(): Returns the date portion of a Date object as a string, using locale conventions
  • toLocaleTimeString(): Returns the time portion of a Date object as a string, using locale conventions
  • toLocaleString(): Returns both the date and time portions of a Date object as a string, using locale conventions

The following script shows the results of the three methods above when applied to today's date:

The above code outputs:

The dependence on the browser's locale is equally evident in JavaScript's ability to parse date and time strings; they will be parsed correctly only if the strings are formatted according to the conventions of the browser's default locale. For instance, calling Date.parse() with a value of "Apr 1, 2007" yields the correct result of 1175400000000 in a US locale browser. Conversely, trying to parse the same date string in the German formatting of "1. April 2007" returns the "NaN" ("Not a Number") global constant. That is not a good thing because you won't be able to work with that date at all. The only consolation here is that you can use the isNaN() method to test the validity of your date string against the browser's locale and react accordingly:

[next]