followBlog

Software Localization is tricky.

1 (1)

Localization is probably one of the most undervalued and overlooked aspects of software development. How hard could it be to load in a different language files after all? Sadly it’s not that easy, if done right.  

Languages are different

About a year ago we were working on 2 games for Let’s do it world 2013 international cleanup campaign, which had to be translated to 9 languages. Obviously we built the game around our native Estonian and English language and had it translated to the rest. Everything started going to hell when we discovered that basic phrases like “New game” or “Submit to highscore” might be up to 6 word sentences in some languages!

User Experience vs User Interface

Only viable solution was to rework the entire user interface to match the longest possible phrase. It definitely didn’t improve the general look of the UI.

In ideal conditions we should have built separate user interfaces for different languages for best visual. However time constraints rarely allow for ideal conditions and we had to settle with the best option available – buttons scaled to match the longest possible string.

Quality of translation

The strings from last example could probably have been rephrased, which is far beyond our area of expertise. Even if you have a basic grasp of the language, you should always use native speakers for the translation.

I can speak Russian on A2 Elementary level. It pretty much means I can ask for directions to the hotel and buy bread. My co-founder at Aplefly Games can speak almost fluent Russian. Naturally I turned to him when I needed the translation of word “loading” for an app. Even though he knew the word out of his head I decided to check it over with a native speaker. It turned out to be a good idea as his proposed word sure did mean “loading”…“loading a gun”.

Language presentation

A whole separate subject is how to present different languages. Most visually appealing would be to use flags, which would work if you are aiming a specific geographic region. In Europe it’s fine to represent Spanish with the flag of Spain and English with British flag. It won’t work if your product is directed to international market. Same thing happened with the games I mentioned earlier. At least minute we had to remake the language selection screen – first thing the user will see when opening the game.  The concern was valid, but the new representation didn’t look half a good. Driven by deadline, there was little we could do about it.

Automatic language detection

Automatic language detection is something often got wrong. Simply selecting the language based on user geographic location or nationality can lead to many false positives. Simply being in Tokyo does not mean I can speak nor read Japanese. I could be using a VPN.

Nor does being Estonian mean I want to use my software in Estonian. In matter of fact, most localization to small languages is often horrible, especially when you are used to English. Windows is a nice example – It’s filled with bogus phrases made up simply to have a match. This in turn means that many functions become completely incomprehensible.

For some reason Google decided to turn my gmail Estonian after they finished the translation. I never asked for it. I much prefer English as the language of the software as I’ve used it for years.

Only time when automatic languages detection is justified is if user already uses the operating system/environment in said language. It’s fine to use Estonian as a default language if users Android is in Estonian. However it can be hard or even impossible to detect in any other situation.

Arabic

Arabic localization is tricky enough to deserve its own paragraph. When working with arabic text, OSX recognizes it and adjust the typing experience accordingly (from right to left), which is great. Unless you are working with a set of strings you received from the translation company which need to be converted to your language file format and enriched with HTML. From my own experience I can say working with HTML in Arabic text can be real nightmare.

And it’s not just the text – Arabic version of the app/website should also be inverted from user interface point of view to feel natural.

Software localization should always be handled with care and not disregarded as something secondary. After all, it will be the bridge between your solution and a foreign customer.

Comments

comments