Software Localization Demystified
You’re ready.
You’ve settled on entering new global markets. You’ve internationalized your software. You’ve found a localization company that specializes in adapting software products to users whose language, habits and expectations may vastly differ from your own.
So what happens now? What goes on behind the scenes at your vendor as they localize your software? Here are the six main steps in the software localization process:
Step 1: Preparation and Analysis
To kick off the process, you give your localization agency the set of files that you want translated. These «resources» externalize text from the source code, usually in formats such as java properties files,.net resx files, traditional windows resources, xml or even just text or table formats. (Though text-based, they still contain enough software code to indicate where text gets used, variable parameters, formatting and other items.) Agency engineers then prepare the files for localization. They load the resource files into the selected Translation Memory tool, which parses the text from the remaining code. Then they lock down all the remaining parts of the file that are not translatable, so translators can’t make any accidental changes that might cause problems later on. In addition, they make sure that any variables that need to be included in the string for translation are protected, but can also be moved or re-ordered within a sentence when needed (i.e. a name inserted by the software at runtime). They also check that the source English «flows» well for translation (i.e removing unnecessary line breaks that could disrupt translation).
Step 2: Glossary and Style Guide Creation and Approval
During this step, your localization vendor creates a glossary and style guide for your approval. These «language assets» establish the key terminology and language conventions that form the basis of your product in each market. Doing this early in the localization process enables the entire team to work off the same set of assumptions, which are aligned with your local market expectations and brand.
Step 3: Translation
Translation now begins. Software localization is hard work for linguists as they are faced with short text strings that are largely out of context. Remember that they’re working in a translation memory environment instead of within the running interface. This limited context during translation sets software work apart from other types of localization projects, such as user manuals or websites, where the context is provided through coherent blocks of sequential sentences and paragraphs.
Training the translators on your product and providing a copy of the English UI for reference help to mitigate this. Developer comments in the file can help as well, but the translator still has to make certain assumptions about how text is being used – and the shorter a text string, the more open it is to interpretation. From this perspective, a single word on a button or menu can pose a bigger challenge than a sentence or paragraph.
Even in the best of circumstances there will be many context-related questions that will require research, collaboration with other team members and escalation to the product experts. Make sure your vendor has a good mechanism for communication and timely resolution of issues across the language team in order to achieve the best linguistic quality.
Step 4: Post-Processing
At this point, the localization engineers take over again to prepare the file for delivery back to you: removing the content from the translation environment and placing it back into its original format; re-encoding files according to your specifications, and checking the tags within the files to make sure the translation team hasn’t introduced any technical errors. If the resource files are in a format such as RC, the engineer will also check dialogs, buttons, and menus for issues such as text fitting and duplicate hotkeys. The engineer will resize and fix as needed.
Next it’s time to make a build of the software. The localization company provides you with a translated version of the resources you gave them; you place these translated files into your build system, and create a localized product in the target language.
Step 5: Localization and Linguistic Testing
Is your software ready to go? Not just yet. Testing will identify engineering, formatting and language issues that were created during translation but are not necessarily translation errors. This step involves testers walking through the user interface within the target language environments (e.g., French application in French browser on French OS), usually via a set of test cases prepared in advance, to view all the translated text and log any issues that turn up.
First, the localization QA team carries out tests to make sure all the text has been translated and is appearing properly on screen. Such tests can turn up many problems that were not apparent before translation, such as strings that were never externalized, corrupted characters, truncated text, etc.
Truncated text is fairly common as text tends to grow longer from English to most other languages (with the exception of Asian languages, which typically contract from the length of the English sentence). Some text may no longer fit into the allotted space, cutting off lines or distorting the rest of the content. All such bugs are logged in a database and fixed before the next stage of testing begins.
During linguistic testing, linguists go back over the translated text to root out any errors in the language – this time in the context of the actual software, so they have a better sense of meaning and nuances.
The localization team fixes any linguistic issues they find during this testing and your software developers tackle any functional or other non-linguistic issues. You will receive an updated set of translated files in order to rebuild the software; with this updated build, the translation company can work with you to verify that all fixes have been made.
Step 6: Client Review and Approval
This is the important step where you have your internal reviewers approve the translated software. Ideally they have provided feedback on core vocabulary, style, and linguistic conventions during step two, so they shouldn’t have many changes at this stage. Edits from the reviewer should be weighed carefully, as implementing changes at this point in the process is more involved than earlier in the process. Nevertheless, it’s a good time for the reviewer to see the software in context so that they’re comfortable with how it will look when released.
Your software is now fully localized and ready for release. Marketing and updating your product will raise a new set of challenges. But for now, congratulations – a new world of customers awaits.
Read our top 10 tips on software localization to help you prepare and navigate through this localization process. Or, contact us with any of your software localization needs.