Personal Language

Research states that even newborns can recognize their own mother tongue, the language they have heard already before they were born. In the end of 2012 this was confirmed by a study at the PLU in Washington. It is actually quite astonishing that we have this kind of a sense for language so early on in our development. The way a newborn identifies sentences of her mother tongue might not be identical to how we grown-ups do it, but how they do it doesn’t matter, most important is that the special relationship is already there.

The same process might happen at the other end of our lives, but the other way round: Alzheimer’s patients might lose their ability to speak other languages than their mother tongue. We might forget all other languages we have spoken for years and perhaps mastered close to perfection, but the mother tongue stays with us.

So what do we do with this information? Maybe not that much in every day life, unless you work within geriatrics or are a language teacher. But this is yet another indicator of how important the mother tongue is for each one of us, how deep the connection to our primary language lies within ourselves. However, this is not something we would necessarily be aware of. Some of us might be more comfortable with speaking for example about professional topics in English than in our native language. Or we might consider ourselves even bilingual despite having learned a language only later on in their life. But deep down these newer languages won’t be so close to us as our mother tongue(s).

Then what, is all of this important to you? Well, for one you can take it for granted that merely understanding your message doesn’t guarantee that it will stick with your users. Common Sense Advisory’s research shows that people are also more inclined to buying from websites that speak to them in their mother tongue.

One of the ways to better attract users and make them stay longer on your website or use your app is to talk to them in the language that they have the longest lasting relationship with. And for most people on our planet, that language is not English.

Get Localization helps you talk with your clients by providing an easy solution for managing software localization and ordering professional translations.

Simple But Yet So Difficult To Translate: Placeholders In Software

I do some translating myself too. Already quite a long while ago I translated texts for a web application running on a small company’s website and came across a placeholder that didn’t have much information attached to it. I could see the placeholder’s name and the sentence it was embedded in. For that particular application, the placeholder name usually revealed what it was about. What I assumed it to be was the name of the user’s company/product. That made the sentence a bit difficult to translate due to Finnish grammatics, but I managed to build a somewhat natural sentence out of it anyway.

A while after that I browsed to the web site and saw what my translations looked like. Awful. The sentence structure was in some cases clumsy, in some cases the meaning was simply wrong. The placeholder didn’t stand for the user’s company/product, but for the website/service where it was used. And based on earlier translations in the translation memory I wasn’t the only translator who had been mistaken.

After that I sent an email to my contact person at one of the many agencies between me and the end client, and pointed this out. What happened? Nothing. The translations are still there. (But you shouldn’t really blame the project manager, as he was probably constantly swamped with email. Localization project managers usually are.)

What did I learn from this? Well, first of all it is critical to include enough information about placeholders for the translators. Even if they would be experienced users of the application, it might not become clear to them what different placeholders mean. Secondly, it’s important to have a translation process that supports communication and updates even after the initial translation has been finished. Communication has to be so easy that important issues aren’t left lying around even by mistake.

Ovi Store and Application Languages

Earlier today Nokia’s Developer organization (aptly named Nokia Developer) released a set of really interesting numbers.

See the article here: http://www.developer.nokia.com/Distribute/Ovi_Store_statistics.xhtml#article0

Let’s drill down behind the numbers and reflect for a second what they mean for selling and marketing your app. From astounding fact that Ovi Store is available in 190 markets to interesting tidbit that Turkey sees 1.6 downloads a week this article is a must read for anyone doing software localization.

90% of Ovi Store users have Ovi Store in their local languages (Ovi Store supports 32 languages)
So 9 out of 10 Ovi users see the store in their own language. What does that mean? First of all: your app needs to speak local language. We knew that already didn’t we? But secondly and even more importantly: your support and marketing material (like webpages) needs to speak user’s language. Localized apps and support material stand out in the crowd of English only apps and it makes it more likely that your app is promoted in country specific recommended lists (it also helps if you have a strong local brand).

The 10 most active markets are (in alphabetical order): China, Germany, India, Indonesia, Italy, Russia, Saudi Arabia, Turkey, the U.K. and Vietnam

To fully reach all top 10 most active markets your application needs to speak:

• Chinese (Simplified)
• German
• At least English, Hindi
• Indonesian
• Italian
• Russian
• Arabic
• Turkish
• Vietnamese

Only top 10 countries you can cover with English are India and UK. And Latin character set gets us only half-way through this list. We have Right-to-Left language Arabic and we have Top to Bottom languages like Chinese. And we have cyrillic alphabet in Russian. Surprisingly no Spanish speaking markets are in top 10 of Ovi Store, but Spain is mentioned as one of the top 15 countries along with France. For app developer this list is a good check list for answering following questions:

• What languages I should support with my app?
• Is my web page and marketing material available in all relevant languages?
• Am I addressing the right markets with my app?
• What does it mean for my application to support Right-to-Left/non-Latin character set languages?
• Is my beta test audience right?
• Is “Lucy in the Sky with Diamonds” sung by William Shatner the greatest song ever? (yes it is)

It would interesting to drill down even further to these numbers. What is the actual order of these countries? What are the top grossing countries? Hopefully we will get to see these numbers next time.

Other Ovi Store Facts

Series 40 accounts for 25% of the Ovi Store downloads. And number of Series 40 devices out there is mind-boggling: 650 million. Series 40 users would form the third biggest country by population in the world!

In China Ovi Store is 7 times bigger than Apple App Store.

Active users download something 8.5 times a month.

Interesting numbers, aren’t they? What is the most important or interesting of all the numbers? And what number you would like to see to support your app business?

Software Internationalization for Dummies

I had discussion today in Twitter regarding software i18n (i18n is a short for internationalization, and it means there’s 18 characters between letter ‘i’ and letter ‘n’). I was trying to find some simple, straightforward link that explains what this word monster actually means but I wasn’t able to find it. So here it goes:

Software Internationalization is a process to separate content from code so that it can be localized. Almost all programming languages and environments provide some kind of framework to do this. There is some popular examples like JavaScript that doesn’t provide i18n support out of the box. However, most well known JavaScript libraries such as jQuery do have plugins that provide the support.

As an example, the iPhone i18n framework provide a way to use following “strings” files that are then accessed from the code:

"Hello World" = "Hello World";


When this is translated, file is copied and typically saved under the corresponding language folder, in this example it would be Finnish strings file:

"Hello World" = "Heippa maailma";

Here we can see that “Hello World” is now translated to Finnish. Based on the language you’re using in your iPhone, the correct file is automatically loaded. It means that when in actual application code we use string “Hello World”, it will get automatically replaced with Finnish translation from the Finnish strings file (if your iPhone is in Finnish, of course).

The benefit of this whole process is that we don’t have to change the code when application goes to localization phase. Also in some cases, e.g. in HTML or other declarative languages we don’t have to duplicate the design or behavior to each localization variant as the languages reside in different files.

However, managing these i18n files will get tricky as soon as you have to deal with multiple languages, hundreds of strings and different character sets, file formats and versions. That’s why there’s new breed of software localization platforms that provide version management, editor, collaborative tools and API’s to manage these files more easily. You can learn more from Get Localization and this blog how to simplify the localization process as well.

If you wan’t to learn more? Please read the following blog post, it will give you more insights about the topic: 10 Internationalization tips for developers – I18N checklist

Leap of Faith: Translation Quality Control

(Photo by Joe Green)

Quality control is an integral part of software localization work. That sounds self-evident, right? Like something that has to be there, because you don’t want to end up on a list like this. But the big question is how (and of course, how much).

The common approach to quality control in localization has traditionally been translating-editing-proofreading (in industry jargon simply TEP). This process consists of two or more professionals, one who translates the text and the other who proofreads it. This often contains a lot of sending files back and forth and some discussions, maybe even arguments, about terminology or grammar. As with all human processes, the end results depend on the individuals involved, but basically traditional TEP offers a good chance of getting good quality results.

But does this great process happen in real translation life? Sure, but all too often you might not want to allocate enough budget to have two professionals on board and you skip the proofreading step. Or you think you don’t have enough time and skip the proofreading step. Or you buy the whole process from someone who says “all translations are proofread by a second professional”, but who still skips the proofreading step. So you end up with a translation that your translation subcontractor (who you found on the Internet without being able to check the references) says is OK, but you have no chance of checking if it really is. Unless you want to pay more and send it to a second vendor for review. Which not only costs money, but also takes time. And if you don’t have a nice budget in your hands, you are probably bound to skip localization testing too. Which means the quality of that single professional is what your end-users will see, be it good or bad.

It is easy to see that localization quality has risks attached to it. We haven’t even discussed style issues yet: good grammar and fabulous Shakespearian wordings might still not cut it, if the software doesn’t speak the kind of language expected by the buyers.

The end-users are of course the ones who should be happy with the localized texts. What if they would be the one who helped you in quality assurance? Heck, if you have a nice app with loyal users, there’s a fair chance they’d love your software even more having been allowed to participate in the process.

Still wondering what’s the fuzz around localization? See this Infograph by TNW

Thanks to TNW: