Software Localization Guide

Software Localization with Lingobit Localizer

Software Localization is the process of adapting a software application for a specific international market, which includes translating user interface, resizing dialog boxes, customizing features (if necessary), and testing results to ensure that the program works as expected. In modern world, as more and more users who do not speak English begin using computers, localization becomes critical for increasing sales and profits. Due to globalization, companies and products now are found in multiple countries worldwide, giving rise to increasing localization requirements.

The software localization process usually consists of 3 main phases: preparation of your software, translation and quality assurance. On the fist stage the application must be prepared for localization. Localizable resources must be separated from the code. Then it is necessary to verify whether the application runs steadily after some of the resources have been translated. The readiness for localization called Localizability, and the process of testing the application for localization called Localizability Testing.

When all mistakes are fixed, it is time for the next phase – translation. Today it is a usual practice to outsource translation. Most of the work is done remotely, so the more convenient the translation software, the better the translation.

In the final stage, after all resources are translated, it is essential to check for errors that might have appeared during the translation process. These errors may be simple orthographic or critical like buffer overflow due to the broken format string in translation. During this phase, continuous testing for each of the supported languages across all resources is needed.

Modern localization software significantly simplifies the task and automates localization process cutting project costs. In the this article, we explain the localization process basics by example using one of the leading solutions for software localization – Lingobit Localizer.

Lingobit Localizer

Lingobit Localizer supports the most popular technologies: Microsoft .NET Framework, Visual C++, Borland Delphi, C++Builder, Java. In current article, we explain software localization process basics for an MFC-based application. All steps are nearly identical for the rest of the platforms.

Let’s start localizing a small test application containing the most common resources: dialogs, menus, toolbars, strings, format strings and images.

Avoid localizing in your source code as this breaks encapsulation and lets a translator edit critical data.

Create a new project and add executables from the application. We will choose “English – United States” as the original language and “Russian” as target. After a new project has benn created, you can see the hierarchy of resources available on the left and a table where you can enter your translation on the right.  

Let’s translate a couple of menus and dialogs and then check results running our application. While editing dialogs we might need to scale elements to fit new text. This can be done with a convenient visual editor that pops up when you choose dialog in navigation panel. When we made some changes we only need to click “Run Localized” to see how our test app looks.

Lingobit Localizer assists on each stage of localization with intuitive UI and a set of build-in tools. Lets start from localizability testing.

Stage 1: Preparing for software localization

The preparation phase of localization is of extreme importance because the results here influence the efficiency of the successive stages. Errors missed during this phase might very well cause significant problems during the next stage. The preparation stage consists of initially preparing for project and localizability testing. In this stage, we need to accomplish the following steps:

• Check what UI elements are not within resources therefore not available for localization.
• Check whether changing the length of strings causes errors
• Research how target language locale\codepage effects the application UI.

What really might bring some relief to a localization manager is that there is one tool that manages these tasks quite well. In Lingobit Localizer you can utilize Pseudo Translate function that inserts a language-specific character (like î â é ô) in all strings across the application. Modified text is still readable and one can identify whether an element is within the resources or not. Therefore, you won’t accidently miss an element while translating. Let’s run Pseudo-Translate and then launch the application 

As we see Pseudo-Translate replaced English characters with language-specific. Let’s launch the application and click “Register” button. Application crashes, while it was working fine earlier. It’s obvious that the error was triggered by one of the translations, thus now we need to determine which of translations caused the error.

We could examine the code in debugger, but in that case we would need the source code and the help of developer. It is clear that calling for developer to fix a problem is the last resort during translation. One way we to fix this would be to turn off each translation and check if the application still crashes. For large-scale projects, that would take a huge amount of time. Fortunately, there is a tool called Crash Finder that automates the task by performing a search for translations that cause the application to crash. For a project that contains several thousand elements, you need to run Crash Finder only about 10 times instead of running the application thousands of times. So let’s use this convenient tool to find invalid translations.

After several steps, Crash Finder identified elements that caused the bug. It is evident now, that during the translation we broke the format string - hence application crashing. Let’s correct this element’s translation and try once again. Now the application is running as it supposed to.

Stage 2: Translating resources

We reviewed the simplicity of translation editing and element scaling processes. With Lingobit Localizer translation of resources becomes solely the task of the translator - the developer’s assistance and basic knowledge of programming is not necessary.

Collaboration with translators

Everyone should apply skills and knowledge in the area he is proficient in: a developer should program, a translator should translate, especially, when we are talking about some exotic languages like Chinese. For this to happen, it is essential to set communication and data exchange between everyone involved in the process of software localization. Within Lingobit Localizer this quite a complicated task and can be accomplished with the assistance of the Exchange Wizard. This tool allows sending work tasks for translators in the form of a project file or integrated distributive that contains free Localizer Translator edition and a project file. As the project file incorporates all the information the translator needs, it is not necessary to send source texts or your binaries. After a translator finishes his part, it can be integrated into the main project.

While translating an application into several languages, it is convenient for localization manager to keep a master version and send tasks to translators in the form of project files. This enables you to translate to several languages, integrating localizations as they come.

Re-use of translations

Translators involved in software localization normally work with texts that are highly repetitive. Therefore there is a certain need for a tool that automates the translation of duplicates. A Translation Memory, or TM, is a type of database that is used in software programs designed to aid human translators. It consists of text segments in a source language and their translations into one or more target languages. In case you already have a translation for a number of terms you can use it while translating new project.

In Lingobit Localizer Translation Memory has an option to import and export data in plenty of formats. In particular, all kinds of text files and TMX files are supported. TMX (Translation Memory Exchange) is a recently approved standard for translations exchange between automated translation software. For instance, you could use one set of translations for several projects or import Microsoft dictionaries used for Windows and Office localization.

Microsoft dictionaries, used for translation of numerous applications can be obtained from http://www.microsoft.com/resources/glossary/.

In addition to Translation Memory in Lingobit Localizer, you can also use helpful little tool called “Translate Duplicates”. It translates duplicate strings like a “Cancel” button across the application.

Translating binary data

With the exception of string translations and scaling dialog elements, you might need to change some additional data. While changing images and icons is a bad practice, sometimes it has to be done. For binary data translation (images, etc) you can use the ability to work with external files. Choose an element in the translations table, through context menu choose «Save Original Data» or «Load Translated Data». After that, you can edit data in external applications and load it back, but this time as translation. Sometimes it is essential to change Version Info parameters, where the application language is indicated.

Avoid using images to store language-specific or country-specific data. This can significantly increase localization costs

Stage 3: Quality Assurance

When we are finished with translation, it is time to check if the translation is correct. Of cause, we could engage a tester, who would review the whole application, but the majority of mistakes could be identified without even launching the application. For instance, it is easy to forget to place a space at the beginning or the end of a string if it was there originally, or to set duplicate shortcuts within a menu, or even leave strings that exceed dialog’s element space. To find these kind of mistakes, Lingobit Localizer uses a tool called Validation. It is an extensive checklist for the majority of mistakes a translator could make. So, let’s check our project.

Many of the mistakes here are difficult to find during translation, but they are easily identified with the help of Validation.

Additionally, the project file can be sent for proofreading. This can be done through Exchange Wizard. The procedure here is similar to translation exchange.

In the final stage of verification, the support of a tester is necessary. You have to launch the application to check all UI elements. It can be achieved without recompilation. In the case of minor errors or unexpected behavior, you can always use Crash Finder, instead of calling for a developer’s help.

Multilingual application maintenance

For better or for worth, applications never stay unchanged for more then a year. If you want to support multiple languages with each update, the whole application must be localized once again to the languages it supported in the previous release.

Without Lingobit Localizer, you would have to translate the entire application or manually merge resource changes into existing translations. This would be a very difficult and error-prone task. In Lingobit Localizer, there is a function called Scan for Changes that automates the task. Scan for Changes compares two versions of resources (translated and the new one) and detects new, changed, removed and equal elements. It copies translations for equal and changed resources, removes translations of missing elements. So you should only translate new elements and check translations of changed elements. These elements can be easily found by status: when only an approximate comparison can be accomplished, elements are set to “Updated” status while new elements from the most recent release get “New” status. 
 
The mechanism of updating is built upon comparing various parameters including resource identifiers. Try to avoid changing this parameter to raise Scan for changes efficiency.

Lets check how Scan for Changes works. Let us change a few elements within our application, add some new elements and run the function. As we see on pic. 6. the majority of translations remained unchanged. In the second column from the left we see how Scan for Changes updated statuses of elements. 

After checking “updated” elements and translating “new” elements, you can release translations for the next version. I’m sure those who tried to support translations consistency between versions manually would understand how simple it is with Lingobit Localizer.

Other aspects of software localization

Localization project management

As with any other IT project, during software localization it is crucial to practice project management and monitoring. First, you should estimate the amount of work and make a plan. During a project it is necessary to monitor the project’s progress and to estimate the possibility of translation re-use.

Taking into account that the quantity of elements in mid-scale application maybe in the thousands, you most likely need some additional productivity tools, particularly, if you are translating into several languages.

The status management system is one of these tools. After an element is translated, you get an “in progress” status, after sending to your co-worker, an element gets a “for review” status, after a translation is completed the status of en element will be “complete”, etc. Status filtering and statistics then keeps you informed of a project’s progress.

Lingobit Localizer has a build-in version control system that saves versions and compares elements. It has basic functionality, which is adequate for tracking changes between different versions.

Switching from different localization approach

During migration to the new localization tools, the big problem is how transfer your translations from the old tools. Some localize directly within resource files, some use text files for translations. Lingobit Localizer deals with all the issues using translation import and translation memory. 

Build-system integration

Command-line interface is essential if you are using scripts. Command line interface grants access to almost full functionality including Scan for Changes, switching between languages and creation of translated files.

Conclusion

Currently, the localization industry is taking its next evolutionary step as modern localization software makes supporting multilingual applications simple and efficient. Localization project managers and translators now don’t’ have to stay in touch with developers constantly. Translators now work in a very user-friendly environment and are not obliged to understand the basics of programming. Today it is quite easy to engage external translators or even to outsource the entire localization process without disclosing your source-code. This leads to time savings and cuts overall localization costs thus so that even smaller companies can afford to produce software aimed for international markets.