Last updated: 02 November 2016
Companies are always looking for ways to expand their business to gain more profit. One common way to increase your market reach is to provide localized versions of software for different markets around the world. The process of software localization involves translating software into different languages for specific countries or regions. In theory, this is simple. However, there are many potential pitfalls, including garbled texts, cut off sentences, and poor encoding of foreign languages. Moreover, the entire software may suddenly cease to work. Below are a few ways to avoid these issues:
Always plan ahead and test
Always plan for software localization long before a product is released to avoid rushing through it at the last minute. When making a scheduling timetable, companies should include time for localization testing. Localized versions of software need to be tested just as thoroughly as the English version. Comprehensive regression testing on all versions is mandatory for creating a quality product.
Create a step-by-step plan of the English test
The same plan used to test English software should also be implemented on localized software. Vital UI dialogs and performance must be tested and will prevent L10N testing delays in the company. Ideally, every translation should be tested with native language speakers to avoid inadvertent mistakes.
String encoding should be localization friendly
It’s always best to encode your string resources for your software in UTF-8 or other Unicode encoding from the start. This way, companies can prevent texts from being garbled and avoid wasting time on extra debugging work later.
Leaving plenty of text expansion space in foreign languages is crucial
As many languages may take up to 30% of space compared to English, text boxes in software should be designed to accommodate this additional space. Therefore, when changing language from English to a foreign language, the foreign texts may fit in the program’s user interface.
For rooting out hard-coded strings, always perform a pseudo localization technique
When using a separate branch, it is always best to use regular expressions when replacing all the string text letters employing one repeating character. Using this technique when building the software forces all the hard-coded texts to jump out, showing a string of IDs undefined in the string tables.
Ensure software localization and help localization is performed at similar times
It is best for a company to seek an experienced translation company to simultaneously handle their company’s software and help guide. Doing so helps maintain consistency and accuracy between their help documentation and software.
Take care about language-specific metrics
Switching the language is not the only thing that needs your attention. People choosing the language might work with other metrics than your company is used to. A different time zone, time and date formats, country-related units, and currencies are just few of them. Also, a particular expression might have another meaning that you are unaware of. Before switching language, think about the dependencies it might have and take into account the particularities of any single country.
Make sure third-party components are translated as well
Software publishers and embedded device manufacturers looking to integrate third-party software to enhance their offering should always take localization-readiness into account. This means that any third-party components you purchase should be localization-ready or, better yet, already localized into your chosen language(s).
As a leader in software licensing, protection, and entitlement management, Gemalto understands this space. Its Sentinel software monetization solutions are both available in several languages and are ready for custom translations.
Have I missed anything important? Share your experiences and recommended tools for easy software localization.