JavaScript Internationalization and Localization

Internationalization (I18n) and localization (L10n) are two of the most important phases in software’s engineering
life cycle in order to create worldwide applications that function for different cultures, languages and locations.
I18n and L10n are usually controlled server side by managed programming languages such as Microsoft ASP.NET, where
resource files (*.resx) provide the foundation of the process and by using the Microsoft .net
framework the application can display the correct language and locale based on the user choice, IP
addresses, domains etc…

JavaScript, JSON, JQuery

Due to the steady increase of services provided by the Internet worldwide and the new technology tools and concepts,
the client side languages have become more complex. Software internationalization (I18n) and localization (L10n) have become very important criteria to address with the
overall globalization of an application. JavaScript, JSON, JQuery
are currently playing a major role in any website user interface (UI) layer. Let’s examine a very simple case that
shows the necessity of internationalization and localization of client-side routines: A multilingual application
ready to display and to handle any number of languages developed using ASP.NET and .NET framework. This website
uses JavaScript to validate users input and display warning or error messages in some cases such as “Email format
not valid”, “Only digits allowed”. Usually web applications use the client-side approach to validate user inputs
instead of server-side validation for performance reasons and to avoid non-necessary rounds between client and
server-sides.

In the above case, if the website UI displays Arabic, normally all client-side alerts should be displayed using the
same language. Based on this, the L18n/l10n becomes a must in order to ensure the application overall integrity.
The following approach describes one of the ways suggested to internationalize client-side languages:

First step is to create a JavaScript file that will be used to store the strings values in source language (English
for example). The internal key / value structure of the JavaScript file will be as following:

[code]var key=”value” ; (i.e. var EmailError= “Invalid Email Format!”)[/code]

Once all messages are added to the English JavaScript file, the file can be multiplied per language. For example if
the English file name is Resources.js, we can have Resource.ar-EG.js for the Arabic language with Egyptian locale,
Resources.fr-FR for French France, etc… And then we can change the values of the keys to the corresponding message
but in the new target language. The above Email error message will be displayed in Arabic as following:

[code]var EmailError=”بريدإلكتروني خطأ!”;[/code]

By now we have JavaScript resource files for each target language ready to be used. How can we select the correct
resource file based on the currently displayed language for the application?

For demo purpose, we can create a simple asp.net page with a language selector to switch between English and Arabic
to monitor the JavaScript language change based on the current language.

Also we can add a simple input field and a submit button.

The expected behavior should be receiving client-side messages in same language as the webpage overall UI : For
English UI Wrong email address will raise the error warning in English

For Arabic

Behind the scene, there are a few easy and quick steps to enable the above localization approach:

First, add a script manager control to the page and enable script localization attribute:

[code]<asp:ScriptManager
ID=”spManager”
runat=”server”
EnableScriptLocalization=”true”>[/code]

Add a reference to each JavaScript resource file created per language along with each resource UI Culture:

[code]<asp:ScriptReference Path=”/Scripts/StringResources.js” ResourceUICultures=”ar-EG” />[/code]

To retrieve the correct localized Message based on the user input a simple routine can be coded to validate the data
entered and raise the correct error or warning message accordingly

[code][JavaScript routine to validate Email Format] Alert([key]) ; Example: alert(“wrongFormat”);
[JavaScript routine to validate empty string for mandatory field] Alert([key]) ; Example: alert(“required”);[/code]

The above method calls the appropriate JavaScript resource file (i.e. Resources.ar-EG.js), selects the key inserted
in the alert and displays the key value. As mentioned above the application was able to select the correct resource
file by the help of Script Manager where we have a reference to all resources files registered by language /
locale. For demo purposes the list box used above is used to select between different languages just as en-US,
ar-EG etc..

The above simple demo shows one of the ways to internationalize and localize client-side programming languages and
highlights the importance of this process for multilingual applications.

SIDENOTE: GPI has developed a very strong Globalization Tool Suite – “G11Tool” which is able to identify areas inside server or
client-side programming languages that require localization and also externalizes the content from almost any file
format or programming language and exports them in ready to translate format such as ttx, *.resx and others. This
application saves our engineers and yours a lot of time, effort and money when globalizing your websites and
web-applications.

JavaScript, JSON, JQuery

Further GPI Resources on Software Translation Topics