Localization in any organization doesn’t limit only to translating and adapting source texts and other materials to a target market. A good and also cost-effective localization process starts earlier than in the moment when the developers send texts to translators. It naturally contains all necessary technical steps, but we’ll skip them this time and focus on the translatable texts themselves and what you can do to make them efficient from a localization point-of-view.
Many of these tips are quite general so they will help you improve your original texts too. They have been written especially with UI, help and support materials in mind – writing for your landing page might be a completely different ballgame but many of the rules apply there too.
Fluent and Correct
Would you trust a linguist to do code for you? I wouldn’t either (and I’m a linguist). Don’t put too much trust in your developer’s linguistic ability either.
Software and other web content are nowadays mostly written in English, which often is a good choice for localization and translation purposes, as the most translators around have English as one of their source languages. But other languages are used too.
Whichever your writing language of choice is, make sure the texts are well written. If your own or your developer’s English is not that good, have the texts edited by someone whose knowledge is more solid. “Engineering English” might create misunderstandings for your users, and those misunderstandings will get multiplied in localization.
Consistent Terminology
Stick to the terminology you choose and make everybody who is writing content also aware of it. This also means not using one term for several concepts. This might in many cases leave the translator wondering which of the concepts you’re referring to – and even get yourself in trouble when you want to mention those two concepts in the same sentence. Put a system in place to manage and spread terminology in your organization.
Reuse
At school, you learn that you shouldn’t be overly repetitive when writing, so you don’t make the reader bored. This is mostly true, I don’t want to argue with your elementary school teacher, but when writing software texts, repetition is your best friend. And this goes for basically any help and support texts too – or anything you write with localization in mind. Identify parts of text that appear in many places and don’t rewrite them. The commonly used localization tools identify what has been translated earlier and you can usually have those parts translated automatically. The more similarities the new texts have with old ones, the less their translation costs. Repeated terms and structures are easy for the translators.
Using the same terms and structures also makes things easy for your user: they will be more familiar with different parts of the UI and have a more fluent experience.
Be Concise
Don’t write overly long texts unless you have a true motivation for that. English is often shorter than many other languages, e.g. German translations tend to be around 3o% longer than English texts, so don’t aim at filling all available space already in the English version. Other than that, concise texts are mostly user-friendly, too. You don’t want your users to leave your page because of texts that take ages to read and are difficult to understand, right?
Localization cost is almost always directly tied to text length, so this point is also directly linked to your bottom line.
Text in Graphics
Cultural References
Funny slang words can nicely spice up a text, as will idiomatic expressions. And make you sound like someone who really masters the language. But at the same time, they make localization more difficult and might even be nearly impossible to translate. For translators, there are ways to get around that, but you don’t want to make translating more difficult and error-prone. The same goes rid of jargon and metaphors, you need to get rid of them.
A Final Pointer
Being customer centric pays off in localization too: if a text is optimal for a user in your own language area, it probably is easy to localize.
Photo by Thomas Lefevbre.
Get Localization Blog 