Terralíngua

Software localization – where your software is customized to suit a specific language or region – is a great way of expanding your business. But if you are not prepared, it may cause many hassles such as garbled text, wrong encoding, and crashes. All these frustrations may be avoided if you prepare well for the localization.

Plan In Advance

More often than not, the reason software applications fall apart at attempts on localization is because the application was not conceptualized with localization in mind. As a result, there were no provisions created for language change or other modifications required for localization. Planning in advance can prevent this.

Design your software with provisions for localization like character support for different languages, so that the grammar of these languages can also be incorporated. Along with content localization, you should also focus on testing localization so that your software localization is more effective. Build a detailed testing plan in English and use the same plan in the localized tests also.

Remember that the feel of your software should be like the locally built software for native users. They should be able to use it without feeling like it was built by someone unfamiliar with their culture. Planning ahead will ensure that your software has this local feel.

Leave Provision for Text Expansion

Languages other than English have a more extended character set, so just using English standards will not be enough if you want to make truly localized software. Using UTF-8 standards always is the best practice for software localization. This prevents extra conversion and garbling of text. Keeping provision for dynamic expansion of UI is also a good practice.

Never use hard coded strings, especially for date and time formats. This is because different countries use different date and time formats. Same goes with currency. Naming conventions may also be different for different countries. Some write the given name before the family name, and some the opposite. Some cultures even have just one name for a person.

Grammar varies from language to language. “Red pencil” in English translates to “crayon rouge” in French. So if you are thinking of concatenating strings, it will not work out for software localization. Keep in mind, no string should ever be overused.

Other Considerations

The GUI and other aspects of the software will be translated by professional translators, and not by your engineers. So if you make the context and the meanings of the translatable parts clear to them through comments, they will be able to do it more easily. Furthermore, they will be consistent with the context right from the beginning to the end of the translation.

Make sure that the translation company you choose is an experienced and expert one, so that they can help with the translation of your software as well as help in documentation and at the same time maintain consistency between the two.

Always remember changing the language does not fully localize the software unless you use the full locale for that region. For example, if the software is supposed to be in English, it can be used in the America or in Britain, but then the spelling and naming conventions would change for software localization, even though the language remains the same (color vs. colour, or elevator vs. lift). Internalization support is also important in your software. It will allow the native formats for currency, date, and time for individual regions to be shown in a way familiar to the region-specific users.

As is evident from this article, software localization is never complete unless it is aligned to the local customs, conventions, and culture of the region it is being localized for. While planning and designing your software, keep provisions for not only language support, but also for other region-specific local conventions to avoid last minute worries.