Think about data as locale-, scope and objective-invariant. The steep evolution of technology has finally allowed it to be managed as a strategic asset that combines every aspect of business – or at least in theory. Our current series of posts will take a look at what localization has to contribute, starting with the practical problem of optimizing web architectures.

Localization-ready website architectures

To get the most mileage out of your online presence and avoid money-consuming refactoring, localization-readiness needs to be an important consideration from the get-go. Regardless how complex your site is, there are several generic considerations.

• If not necessary, do not obfuscate localizable content, such as text and certain locale-dependent elements. HTML5, CSS3, preprocessors and other methods provide flexible methods for design and animation (in mobile environment, native code is often preferable, more on this in a subsequent post). Compiled and non-vectorized formats as well as baked subtitles take more time and effort to localize, and often hinder automation. Moreover, source assets very seldom come along with the deployable files, and prone to go missing. In this case, quality loss of the original art is inevitable.
• Consolidate and structure content. Successful startups, such as Prezi, use a centralized repository for all their localizable assets from UI to website with flags, version control and meta-data. Businesses that are smaller or their competency is not in IT may refrain from using such an elaborate system, but the point is still valid: content can be structured client-side as well. Otherwise your content will develop redundancies and it will replicate over every static page, making maintenance increasingly difficult.
• Consider the design decisions you make and the architecture you buy into. Only rely on client-side resources, such as fonts as a fallback option, and use a webfont that supports all the range of the Unicode plane that will be required. If your site features dynamic content, opt for a technology that has built-in rules at least for plurality differences.
• When authoring web content, keep context and linguistic restrictions in mind. Avoid concatenation (procedural content generation engines are a bit different), short length limits and prevent 1:n issues by using transparent wording.
• As a rule of thumb, separating code from data not only scores in elegance, but also in terms of modularity, reusability, maintainability and of course localizability.

Exhibit #1: Scenes of abject trauma

Architectures

Client-side custom JavaScript

JS is versatile and used on virtually every website in the universe, but we’ll now focus on its localization aspects. For smaller sites with relatively low traffic footprint it’s optimal for storing all language data and using only references in the static HTML files. Since this approach does all the work on the client, it’s relatively easy to put to work, it is low-cost and rapid to deploy with minimal infrastructural requirements.

HTML:

<span><%= msg.data.header.label %></span>

JS container:

define([], function() {
     return{
           "data": {
                "header": {
                     "en": "About Us",
                     "fr": "Qui sommes-nous"
                },
                …
     };
};

You need another simple function to store a cookie with the selected locale information, and upon page load/initialization, one that reads the current locale and a function that transverses the language tree and returns the data.

function locStringSet(strings, locale){
     var ret = {};
     if(_.isObject(strings) && !_.isEmpty(strings)){
                _.each(_.keys(strings), function(node, ind, list){
                     if(_.isObject(strings[node]) && !_.isEmpty(strings[node])){
                           ret[node] = {};
                           ret[node]["label"] = node;
                           _.each(_.keys(strings[node]), function(inner, ind, list){
                                if(inner === locale){
                                           ret[node]["label"] = strings[node][inner];
                                }
                                else if(_.isObject(strings[node][inner])){
                                           _.extend(ret[node], locStringSet(strings[node], locale));
                                }
                           });
                     }
           });
     }
     return ret;
}

The elegance of this approach is in its modularity: all HTML files can be stripped from CSS and JS once the main function is initialized on the first load. Note that this approach is clean and easy to maintain: contextual info is present (e.g. msg.data.header.label) and eliminates all unnecessary redundancy.

For the code to be localization-friendly, it is necessary to define string literals in a custom structure (see above), not explicitly within methods:

if ($("input#contact_name").val() == "") {
     alert("Please fill in all mandatory fields!");
     …

JS can be combined with server-side languages, such as PHP for more complex implementations, which we will deal with in our next post. Hope to see you next time!