• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
JavaScript Internationalization I18n for Efficient Software Localization
 

JavaScript Internationalization I18n for Efficient Software Localization

on

  • 1,668 views

Source: http://www.lingoport.com/javascript-internationalization-%E2%80%93-the-good-the-bad-and-the-ugly ...

Source: http://www.lingoport.com/javascript-internationalization-%E2%80%93-the-good-the-bad-and-the-ugly
Given JavaScript’s status as the de facto browser client scripting language, and given the international nature of the Internet, it was inevitable that JavaScript and internationalization (i18n) would eventually cross paths. At Lingoport, we see a good deal of JavaScript in our client’s code that we internationalize. While JavaScript is not completely
without international capabilities and functionality, it does have its share of challenges and faults. This article briefly discusses some of what to expect of JavaScript in an international web application – what works (the good), what to watch out for (the bad), and what to avoid (the ugly).

Statistics

Views

Total Views
1,668
Views on SlideShare
1,666
Embed Views
2

Actions

Likes
0
Downloads
6
Comments
0

1 Embed 2

http://www.slashdocs.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    JavaScript Internationalization I18n for Efficient Software Localization JavaScript Internationalization I18n for Efficient Software Localization Document Transcript

    • 4/30/2010 JavaScript Internationalization for effic… JavaScript Internationalization – the Good, the Bad, and the Ugly Internationalization Articles March 27th, 2008 Given JavaScript’s status as the de facto browser client scripting language, and given the international nature of the Internet, it was inevitable that JavaScript and internationalization (i18n) would eventually cross paths. At Lingoport, we see a good deal of JavaScript in our client’s code that we internationalize. While JavaScript is not completely without international capabilities and functionality, it does have its share of challenges and faults. This article briefly discusses some of what to expect of JavaScript in an international web application – what works (the good), what to watch out for (the bad), and what to avoid (the ugly). The Good – Unicode Probably the best news about JavaScript and i18n is that it supports Unicode. This means you should never have to worry about character corruption provided you take care to make sure that JavaScript is using it. If a JavaScript script block is embedded in an HTM L file, it will automatically assume the character encoding of the enclosing page. Thus, if you have defined your HTM L character set as UTF-8 you have done all you need to do. If your JavaScript is included as a separate .js file, you can add a charset attribute to your script tag to specify the character encoding of the included file. For example, a JavaScript file called functions.js that is encoded in UTF-8 would be included like this: You can also include Unicode characters in any JavaScript regardless of encoding by defining the characters using Unicode escape definitions (u + 4 hexadecimal values that specify the Unicode character value in big-endian order). For example, you could define a string with a smiley face character like this: JavaScript is even smart enough to know the length of Unicode strings in terms of characters and not bytes. For example, smiley.length would return 1. The Bad – Strings One of the more annoying issues with JavaScript and i18n is dealing with embedded strings. As with any other programming language, embedded strings in an application’s code make it difficult if not impossible to localize. Unfortunately, JavaScript does not have the concept of a resource file, and strings that will be generated by JavaScript must be defined in the code. The easiest approach to deal with this issue is to define your JavaScript strings dynamically in server-side code (Java/JSP, ASPX, PHP, etc.). The following example defines some string resources in a JavaScript script block at the top of a JSP page: lingoport.com/javascript-internationali… 1/5
    • 4/30/2010 JavaScript Internationalization for effic… Assuming the currentLocale object is set to English (US), the resulting block should look like this: When currentLocale is set to German (Germany) it should change to this: For French (France): You get the idea. There are a couple things to keep in mind with this approach. First, any strings that are embedded in the files, whether JSP/ASPX/PHP/etc. or JavaScript .js files, must be externalized, i.e. the strings should be moved into the string resource block as demonstrated below, and replaced in the code with their variable names. Second, the JavaScript string resource block should be defined before any other embedded blocks or .js file includes that make use of these externalized strings. For example, the resource block should be defined before the following function is called: lingoport.com/javascript-internationali… 2/5
    • 4/30/2010 JavaScript Internationalization for effic… Note that this simple example doesn’t deal with more sophisticated functionality such as locale fallback, but this basic approach solves the simpler string resource-related issues common in JavaScript. The Ugly – Language, Dates/Times When it comes to language, JavaScript knows enough to be dangerous. That is, it knows what the browser’s default language is (it’s defined in navigator.language for Netscape-descendent browsers such as Firefox and in navigator.browserLanguage for Internet Explorer). On my English (US) system these get reported as “en-us” or “en_US.” It is tempting to think that this information is a useful indication of the preferred language of the user, and in many cases it will be, but it doesn’t allow for the possibility of a user preferring a language other than the browser default. On a related note, there are a small number of “locale-specific” methods in JavaScript, which deal with the presentation of dates and times as strings, but these are always formatted in a single format for the browser’s default locale. This also applies to the ability to parse date and time strings; they will only be parsed correctly if the strings are formatted according to the conventions of the browser’s default locale. Although these provide some minimal language support, it is actually best to ignore these and instead rely on the server to provide this functionality as much as possible. With the advent of AJAX, a higher level of i18n functionality becomes possible because of the ability to interact with the server in a more seamless fashion. Using AJAX to achieve this higher functionality in JavaScript will be discussed in a future article. Resources Internationalization Articles Internationalization Newsletter Internationalization Whitepapers Videos Webinars Subscribe Subscribe to our newsletter and white papers for free internationalization news, articles, and Webinar announcements sent via email. Click Here to Subscribe lingoport.com/javascript-internationali… 3/5
    • 4/30/2010 JavaScript Internationalization for effic… Contact Us Phone: +1.303.444.8020 Email: info@lingoport.com lingoport.com/javascript-internationali… 4/5
    • 4/30/2010 JavaScript Internationalization for effic… lingoport.com/javascript-internationali… 5/5