Interaction Design and Development

Of localization and locale mapping

Posted on 2010-02-21

When creating web content for international clients, it is more than likely that you will have to think of localized versions of your website. This mostly means that the copy has to be translated into multiple languages.

In this post I will try to present what I believe is a simple way to deal with localization and minimize file copying etc.

I learned of localization when I was working at an e-commerce production shop previously. That company had most of its clients in Canada and in the US, meaning that we only had to deal with a minimal amount of localization, namely "en-US", "en-CA" and "fr-CA".

If you have no idea what those codes are about, the first two letters represent the language (following the ISO 639-2 codes) and the las two letters represent the country (following the ISO 3166-1 codes).

Recently I had to complete projects for an employee that left the company I currently work for. I had actually never dealt with localization in Europe and obviously, that means a lot more languages. I also discovered that some countries reuse copy. For example, the swedish and greek localization of one of our client's site reuse the english copy. The way the project was set up at that moment was to have one directory per country, meaning that we had to remember to duplicate the english copy into all the directories that used that language as well.

A recipe for disasters.

Here is where the idea of mapping becomes useful. In the site's config file, I simply thought of adding a node that would contain the locale mapping, meaning what country is associated to what language etc.

XML:

The alphabet tag is not relative to any specific standard, but just actually the logic part of what I use to load the fonts and the CSS (see previous post).

So far as the logic goes, once the config file is loaded it is easy to associate a country with a language and load the related files. If a user comes to a website and there a script that detects France, it is then possible to know what to load: the french copy, the latin font set and the latin CSS. Same goes for any country.

Antti Kupila, a colleague of mine, believes that it is kind of cheating to reload a a whole website to change the locale. I agreed when he explained how to realize this.

Whenever a TextField is added in the application, it is registered and a reference to it is kept in memory somewhere. When the user changes the locale, there is no need to reload all assets, just the necessary copy, the font set and the CSS (or TextFormat, depending). Once all is loaded, update the TextFields.

Here you go Internets, another way to organize and simplify your life.

One response to “Of localization and locale mapping”

  1. […] localization worked like a charm with the locale mapping logic I wrote about before. The only issue I found is that since there were no specific fonts for non latin languages, there […]

Leave a Reply

Your email address will not be published. Required fields are marked *