I've been meaning to write about this for a while. Even though it is not specifically about development, user experience is something that creative developers should take into account when developing websites, games or other interactive experiences. Let's look at a couple of different ways of offering the user localized content, and try to analyze whether these options fall flat on their face or offer enough flexibility to answer your client's and their customers's needs.

Clients that offer services in multiple countries require their content to be localized, and for a good reason: inhabitants of all regions of the world want to be respected and obtain content in their own language. And I agree, it's a simple matter of respect.

The usual suspects

The way localization is most often achieved is by detecting the user's country automatically. This can either be done by localizing the IP address (see an example), soon by simpler means with HTML5's geolocation (see an example) or by asking the user to select a country.

LaCie does just that.

I think that this last option is lazy, both on the company's and on the developer's part. The user should not have to make such choices, especially when there are ways to make such a selection invisible.

What happens from there is that the website content is presented in the language relative to the country. It mostly works, but there are some situations where this logic is not sufficient. Let's take the example of some European countries, like Belgium and Greece. In Belgium, French, Dutch (Flemish) and German are the official languages. In Greece, where obviously Greek is the language, there is also need for a specific alphabet.

From adidas's country selection page, if either Greece or Belgium is chosen, the user has no choice but to visit an English website.

To adidas's credit, there is the option to change country at any time, the site even offers you a choice whether or not you want the cookie to remember your country selection.

Some websites, such a Nike's may offer a simpler solution, only choose your language, not the country.

All these options ask an action from the user before they can even see your products or services, and that small irritant is the first interaction they have with your website.

The mistaken

In all online stores (let's not call these e-commerce no more, please?), there comes a moment where you want to write your shipping address to obtain your purchases. If you have offered your clients a multilingual website, it's just normal that the input fields should support special characters too, regardless of the language the client chose.

When I moved back from Amsterdam to Montréal, I had to change many addresses for many of my services, both physical and online.

Apple requires me to have a valid credit card in the country that I select, as their products availabilities are based on the locale. However, their form failed when I entered my address.

I get informed that the city, that I wrote "Montréal", contains illegal characters. Obviously, this turned out to be that I should not use the accent. This is ridiculous, the user should not be told there is something wrong when in fact there is not. How complicated is it really to handle accented characters? I mean, if you want to provide multilingual services, get your act together and do it everywhere.

The ignorant

There is also the peculiar case of Urban Outfitters. The american company has oftentimes been vilified for stealing designs from indie designers or for shamelessly using native names in their product names, so what I will present here should not come as a surprise.

In Québec, a law states that if a business has a brick and mortar store in the province, the business is responsible to also have a French side to it's website. As mentioned in my introduction, it's a matter of respect to your clients in the locale in which you offer your products and services.

Urban Outfitters did not, and when legally instructed to do so, they decided to simply not offer their clients in Québec with no access to their website whatsoever. Just go to the store.

That is one stupid way to use geolocation! You disrespect a locale and it's language, and at the same time you prevent those in the locale who can speak and read English from having access to your products. Great way to prevent sales!

The road ahead

Of these different approaches I make the following conclusion and add a recommendation for multilingual website and software creators: first, indeed do geolocation to offer the most relevant content to the user. Do give options to change not only the country, but also the language. Paypal is the closest to this idea. If you change your location to Canada, you can then change the language to the available languages is that country, namely French and English.

But here is where I want to get to with this post: why stop there? Indeed, do present the most logical languages relevant to that area, but do not block the other languages from being available, especially since you have them in the database already. I understand that it may be mostly be relevant for expats and travelers, but I strongly believe that this kind of market is growing.

The iTunes Store is built in order to lock you into a language depending on your country. Websites like YesAsia are built with the idea that the content should be available to everyone, even if the clients are not from Hong Kong, Japan or Korea, where their offices are. They offer not only options for locales and languages, but a reference to the value of the currency so the customers may have a general idea of what they will pay.

In the case of Paypal, as I said before languages are chosen by country. They have many more languages, they should offer them. I can understand that there may be issues in doing so. For example, English is not legally bounding in the Netherlands, so important options are not available, not even deleting an account. How about presenting all languages, and just like YesAsia does it, add a note that explains that whatever is said in translations, the version in the official language(s) of the locale prevail?

Ultimately, it's always about how much you really care about your clients. For example, Asian countries dislike it when they are presented with English text rather than localized. Ask your markets to help you make a better localized version of your products, don't just expect your clients to swallow whatever you feed them. This is the kind of stuff metrics will not really show in numbers, this is an analysis you can make from talking with your markets.

After two arduous months of work—and during the hassle of me moving to Amsterdam nonetheless!—we finally managed complete the production of the adidas Originals Women's Lookbook SS10!

Lots of thought went into the architecture of that project so it would be easy to debug. I chose a homebrew MVC pattern for the structure, which worked well. Looking at my colleague working with RobotLegs, I believe this is what I'll look into next.

The 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 had to be a check to see what alphabet was used, to make sure that the fonts were not embedded if said alphabet was non latin.

The video had to stream in this case since we needed to jump at any moment in time in the video. Also, we faced an inconvenience when trying to get a bitmap from a streaming video, the solutions were on the server side.

Integrating the whole project into an existing parent SWF was also a challenge, since the class definitions would be kept in the appdom memory and causing issues when loading the site a second time. The solution to this was to apply an application domain when loading the microsite (link 1, link 2).

As I was looking for solutions, I found that wiki that is discussing about things like thinking in AS3, metadata, singletons, application domains and all sorts of interesting subjects.

All in all, that project was a good challenge, one I had been looking forward to for a while now.

The embeddable version seen in this post actually has been produced by Département in Montréal.

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:

<localeMapping>
     <locale country="ca" language="en" alphabet="latin" />
     <locale country="cf" language="fr" alphabet="latin" />
     <locale country="fr" language="fr" alphabet="latin" />
     <locale country="jp" language="ja" alphabet="japanese" />
     <locale country="kr" language="ko" alphabet="korean" />
     <locale country="se" language="en" alphabet="latin" />
     <locale country="uk" language="en" alphabet="latin" />
     <locale country="us" language="en" alphabet="latin" />
</localeMapping>

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.