Often when companies decide to take on the world, they undertake the localization of their software product into multiple languages in parallel. This involves Graphical User Interface localization, or GUI localization .
But in some cases, either due to limited resources or budgets, young software companies prudently consider their options and end up localizing their product into one language first, before embarking on more. This was recently the case with a small software publisher that was localizing its highly technical engineering software for the first time.
Pseudo Translate Before GUI Localization
The first step taken was pseudo-translation. It ensured that no graphical user interface (GUI) text remained hard-coded and enough space was present in the dialog boxes to allow for text expansion after translation. With pseudo-translation, quality assurance time and dialog boxes resizing for all languages are minimized.
Start by Localizing into One Language
Our client also understood that GUI localization is not only a test of their internationalization efforts, but also a potentially tricky linguistic endeavor particularly given that their highly technical GUI strings can be misinterpreted when out the context.
So they proceeded with GUI localization into Spanish first. The first round of translation always invokes many contextual queries by the translators. Also, internationalization mistakes not detected during pseudo-translation are encountered and flagged throughout the GUI localization process. Using our translation management system (TMS) and its translation collaboration module, the translators entered their queries online, got answers from the client experts online, and answers were stored in the online TMS query database to be searched and used by future translators involved in localizing the product into other languages.
Fix Internationalization Issues
The first localization effort also involved optimizing guidelines specifying textual objects to translate or leave as is. Although these guidelines were provided at the start of the project by the client, throughout the translation, the translators did uncover many inconsistencies. These inconsistencies required reworking the macros and parsers that we wrote to prepare the GUI files for software localization. Given that only one language was in progress, we were able to make the necessary corrections with a minimal amount of rework. Had multiple languages been underway, this rework would have been multiplied by the total number of languages involved.
Perform Quality Assurance
The Spanish application was then checked by in-country reviewers in a test build runtime environment. Additional errors detected with improper use of variables and new line returns were corrected in the source code benefiting future localization efforts.
Execute on All other Languages
It took a couple months to complete the first language. But subsequent languages were done in a matter of weeks and with much lower effort than if all done in parallel.
Doing things in parallel is not always the shortest path! Ensuring that your software is localization ready before undertaking multi-language localization can pay lucrative dividends in time, cost and quality!
This whitepaper presents you with straight forward metrics that will help you determine the budget and schedules needed for translation and localization projects. Don’t request a bid without reading it first! Get it now for free!!