Tuesday, September 20, 2011

4 Steps to make software localization easier

1. Make sure that the texts in the software are easy to translate.

In this context, “easy to translate” refers to the situation when it is easy to have the right things ready to be translated. This may not be as simple as it sounds, because the translatable parts are written inside the code. Luckily all development tools have guidelines to write software in a localization friendly way. We usually recommend people to follow the instructions of their development tool.

2. Design the user interface in a way that also the translated texts will fit well.

It’s good to remember that the same expression in different language will require different amount of space on computer screen. Actually this applies to all cases when something is translated from one language to another. The amount of letters in corresponding words in different languages can vary remarkably. For example, if the software developer has fixed the space reserved for the text to be equal to the English text, the localization to German may be problematic because, German expressions and phrases tend to be much longer than their English correspondents.

3. Make sure all file names and links contain language parameter.

Unfortunately this step is often left overlooked. The reason for this may be the fact that this is not related to the actual text translation. But like the definition says, software localization is much more than just translation. The point here is that it’s not enough to have all the texts translated, also the other language related material should be double checked.

4. Make sure that the translation is easy to outsource.

If localization project includes many languages, you will most likely send the text-to-be-translated to several persons. And normally the effort needed to go through the translation outsourcing is multiplied by the number of languages you want to support. Thus it’s important that this step is as simple as possible. Sending translation packages back and forth between multiple project participants is both frustrating, risky and unnecessary. Read more. Source: proz.com