Localization, and therefore the ability of your product to succeed in a desired market, is far more complex than just translating words. You also need to take into consideration the design, development and QA processes. And because of this you need to be prepared for localization before you even start supporting languages in your product. Because once that second language is added, it's there for the long run. This isn't a feature you can just erase from your backlog. It’s an inherent part of your product that you'll have to continue to support in every future version update.
So, here are our 8 things you need know early about localization:
UI Design Should Not Be Based On The Length of English Words
A five letter word in one language can easily become three times as long when translated to another language (we’re looking at you Hungary and Germany :) ) Therefore, in an interface where the space allocated for labels and texts is limited, like on a button, localization also means UI redesign. Now, you probably don't want to spend precious time on this so make sure in advance that you allow for plenty of space around labels, menu items, tabs, etc.
So be prepared for the day you find out how many letters are needed to write "settings" in German, (it’s “einstellungen” by the way).
Text Should Not Be Hard Coded Into the Product
In the world of fast-paced development, especially when localization might not be an early requirement, strings of copy are often hard coded into a product. However, later, when localization does become relevant, all the hard coded text throughout the product will have to be located, removed from the code and collected into a single file. This is done in order to allow easy switching between the copy of different languages. Going a step further, specifically in mobile apps and desktop software, moving these files to the server will give you the freedom to fix or update the copy live.
Testing Cycles Must Include Every Language
When your product is localized to multiple languages you will have to extend your QA cycles to include testing for each one. This is a significant additional task, especially if you support many languages.
Think about it this way: say you have a product with a total of 40 pages. Each one is going to have to be tested to verify that the copy is rendered correctly and nothing is broken in the UI. If you localize the same product to 5 additional languages, then that's 240 pages to check.
Let's say you have found a problem with a label in Japanese. You go back and make a few UI changes to fix that. Now you have to retest the page in every other language to make sure nothing else was broken as a result of the fix.
Professional Translation Is Needed
It’s hard to write great copy in any language. You can ask bilinguals on your team to help you with that, but there is a good reason that translation is a profession. Sooner or later you will need someone to tell you how to write in Japanese "I agree to the terms and conditions". There are many companies out there providing such services and there are a few things that you need to consider when hiring one of them:
- They have to be knowledgeable in your professional field - For example: if you are building a medical product your translation provider must have people familiar with medical terms for every language they translate to.
- You need a pain-free collaboration – Even if you add a single word in a new release, you will have to get the translation for it in every language. This means that the provider has to offer an easy and continuous way to collaborate with your team.
- They need to react fast - You don't want to delay a release because translations are not ready. It's your responsibility to provide the required content in advance, but they have to be able to respond on time.
- Good translation requires context - Sending the provider a text document that includes the new version's copy sounds simple enough. However, all the bilinguals out there will tell you, translation without context is translation without sense. Google Translate is testament to this.
Personally, I believe that the translator needs to see and preferably try your product to understand the real meaning of your words before translating them. I would be cautious of going with a provider who promises to give you high-quality translations based on nothing more than a text document.
Decisions Affecting Copy Have To Be Made Earlier
Until now you could make up your mind about the final copy shortly before release. I’m not saying you should, but, if you really, really wanted, you could. Unfortunately, you won't be able to do that anymore. Nope, you will have to leave enough time for the text to be translated, implemented and tested in all the languages you support.
Don’t say we didn't warn you :)
Localization Is a Task For Every Release
Unfortunately, localization isn't a one off task. Once you've decided to support multiple languages, you'll have to support them in every release. It’s an ongoing process and you'll need to treat it as such. Localizing your product to German and then releasing new features in English only is like adding an extra bathroom to the office, but not allowing half your staff to use it.
There Is More to Localization Than Just Language
The same way as Americans have no idea what to wear when it's 36 degrees celsius outside, most Europeans don't really know how large a 20 by 40-inch mirror is. It's also great to wish a happy thanksgiving to your audience, but your German users will probably say "Was is das?". Ok, they probably do know, it's just irrelevant to them. The bottom line is this: localization is much more than replacing the words. You have to be sensitive to the cultural differences between people. Hire a cultural advisor if needed, just don't annoy your users by declaring that you support their language without supporting their culture.
Appoint Someone to Be Your Localization Owner
We hope it's clear now how important localization is and that it's not a task that can be rushed through before each release. Unfortunately yelling out "Hey, did anyone take care of localization for this release?" the morning of the release isn't going to work.
You have to appoint this task to someone specific who will henceforth be responsible for it. This is the best way to make sure that you hit your deadlines, and that you maintain a consistently high level of quality across all the languages you support.
Special thanks to Hagai Galai for sharing from his extensive experience on this subject.