This is Part 2 in the series of describing an approach that can be adopted to provide internationalization and localization support to web applications, specifically client-side intensive web applications. The original intent for this series was to look at the subject matter in terms of modern web-applications, but there’s no reason why this can’t be applied to traditional (non-application like) and mobile websites as well.
Translating software can be a lot of work and its process begs to ask several different questions such as:
- How do I support multiple languages in my application?
- What changes do I require to support multiple languages?
- What language should I start with?
This blog entry discusses some basic concepts as well as provides a few examples of the concepts in practice. While it is certainly not my intent to cover every detail, I hope it will give you an idea of what’s involved and get you started along the process with your own work.
Some Basic Terminology
There are a couple of basic things to understand though, before you create a multilingual application. Let’s agree on some basic definitions as these terms are often used interchangeably.
- Internationalization (i18n) – the process of enabling the application (e.g. backend of a website) to handle different languages, character sets, currencies, submit form data, search capabilities, etc.
- Localization (L10n) – involves translating the application (usually the front-end) into different languages ensuring all content (text and graphics) is translated in an accurate and culturally correct manner. It also ensures that appropriate locale of your target audience is chosen, for instance the Brazilian Portuguese language in contrast to the continental Portuguese language.
- Globalization – The combination of Internationalization and Localization
- Language – For example, English (ISO Code “en”), Spanish (ISO code “es”), etc.
- Locale – Canada. Note that French in France is not the same as French in Canada, e.g. “fr-FR” vs. “fr-CA”
The resource files nomenclature
Ideally the generated JSON-based resource file can be used when rendering static messages, dynamic messages, dialogs, etc. within the UI of the web application.
Consider the following example of a JSON-based resource file we introduced in Part 1 of this series:
|English Version (strings.en-US.json)||Spanish Version (strings.es-AR.json)|
The following table describes the type of resource strings and how they are used within the i18n library:
|Entry||Resource String Type||Usage|
Attribute Resource Type
In your web application user interface (UI), there are many components which will contain text (which require translation) that when once loaded remains unchanged (i.e. static). The attribute resource type provides a way to help load your translated text items (e.g. button text, labels, column headings, etc.) at application start-up time.
From your client-side mark-up you can simply add the attribute “data-res” with the appropriate resource entry as the key and the library will automatically load the translated text as the inner html of the DOM element.
However, if the resource key entry adheres to the following naming convention:
The library will load the translated text into the attribute name rather than using the default “innerHTML” property.
Group Resource Type
This type of entry is used to group items belonging to a similar context together. This allows us to avoid collisions of similar “key” references being made. For example, your web application may have several uses for a given string (e.g. key-> “all”). Although in English there is a single word for this key, in another language there may be multiple options available given the context in which the word is being use (e.g. In Spanish “todos”, “todas”).
Just as maleness or femaleness is an inherent characteristic of human beings and most animals, so is gender an inherent characteristic of nouns in some languages. Depending on the context in which a word is being used, it may be more linguistically accurate to use the male form versus the female form or vice versa.
As such, we can use the Group resource type to create context and re-use the same key in each of the different contexts. That way, we get the appropriate translations for each of the different languages our application supports.
String / Formatted String Resource Type
Once the initialization process has completed, you can ‘lookup’ string resources using their key names as shown below:
String resources are static in nature and will always produce the same result of the current active language.
On the other hands, Formatted String resources, are dynamic and allow you to include parameters at run-time which in effect allows you to create custom string values. Formatted String resources are used just like regular String resources except that you include parameters in the method invocation. See example below:
This version replaces any format items in a target specified string with the string representation of three specified objects. The target specific string is represented by the result of looking up the key “loggedIn.welcomeMessage”. This key produces the result “Welcome %s %s!”. The “%s” represent format items which will be replaced by the values of the parameters “fName” and “lName”.