Benefits and Issues of Binary Localization

Moving towards a more efficient strategy to localize Windows applications

Overview

The process of localizing C/C++ Windows applications has changed significantly over its history. Because of fierce global competition, the localization industry has progressed from rather painful methods of localizing large and inconvenient source files to using specialized tools that allow for a quicker and considerably more efficient process of binary files localization. Usage of these localization tools and switching to a binary localization has provided many benefits that streamline and shorten the process of localization.

The old approach to localization involved translating hundreds of resource (RC) files and resizing dialogs using tools such as Microsoft Developer Studio or text editors. As newer builds of the same products started being released more frequently and translators' work became more repetitive, translators started to use various translation database tools to save translation time.

While database tools with RC filters improved part of the translation process and allowed translators to begin their work sooner, it was still time consuming, and error prone to resize graphical user interface elements separately for each build. Localizers therefore started to use tools focused primarily on software localization that combine aspects of translation database technology with visual editing.

Currently, the localization industry is taking its next evolutionary step; leaving behind a tiresome and time consuming RC-based process for the quicker and cleaner process of directly localizing precompiled binary modules. Tools, such as Lingobit Localizer, promise to provide integrated localization solutions that allow translators and engineers to work directly with binaries saving enormous amounts of time and effort.

Traditional RC-based Approach

The traditional process of localizing Windows RC files is a complex process with many steps.
First, required files of the project have to be identified and prepared by developers and localization engineers before being sent to translators. After translation, they must be sent back to the engineers to be compiled and built for quality assurance testing. For each user interface bug or change found during the QA process, the corresponding RC file must be found, fixed, and included in a new compile. This process then has to be repeated until the final localized build is produced.

With a binary localization process, all activities are focused on the compiled modules of the application rather than the source files that go into the compilation process. This is possible since the tools used to accomplish the task are aware of the constructs of a C/C++ application executable files and able to make all of the text-based strings and other data of the application available for localization. This means there are far fewer files involved in the process and preparation time is dramatically reduced. After translation, an extra compile is not necessary since the translation and visual editing occurs directly on the working binary and translated files can go immediately into the QA process.

Switching to a binary localization process can seem fairly beneficial at first glance. An even closer examination of binary localization reveals how extensive its advantages really are in terms of the greatly reduced number of files, the convenience of building the final product, the ease of user interface bug fixing and quality assurance, and the additional time-saving utilities that are available on many binary tools. Taken collectively, these advantages can add up to lower cost and dramatically reduced project timeframes.

Reduction of Files

Probably the most obvious advantage when localizing binaries is the greatly reduced number of files that localization engineers have to manage. When dealing with a large number of files, the preparation can get extremely complicated. The chances of losing a crucial header file or a library file are quite high and that loss can lead to severe complications in the final build of the localized application. Engineers have to take meticulous care that the directory structure of these files is preserved and that no files are lost in the process. If certain files are misplaced and excluded from the translator's package, valuable time is spent tracking the file down and sending files back and forth between the engineer and the translator to get it resolved.

With average binary projects, the engineer will have only a few files to organize in the exchange package and the chance of losing essential files is greatly reduced. And to make certain that all files are included in the package, a simple check can be performed by merely running the application and making sure it works.

Streamlined Build Process

When localizing RC files, the build process can get extremely complicated and time-consuming. Because source files are being translated, 5 to 10 working days can be spent simply assembling files and compiling the application for each build in each target language.

RC localization also requires a strict adherence to the directory structure of the files. If a file is misplaced or corrupted during translation, countless hours can be spent trying to pinpoint the exact source of the problem and correcting it.  When there are thousands of files in question, this can prove to be a very painful process. Additional time is also spent finding translators who would be comfortable with the technicalities of the directory structure and educating them in the nuances of the application. This need for a technically proficient translator can in turn force a company to compromise the quality of the translation when forced to opt for a technician over a more experienced linguist.

Equally important, if translators are working in source files, they can inadvertently introduce syntax errors or, worse, introduce functional problems by modifying or deleting nontranslatable portions of these files. This can substantially increase the QA effort. With very large projects, binary localization is the only feasible option.

All of these problems are eliminated when switching to binary localization. Instead of sending thousands of files in a strict and complicated directory structure to the translator, less than a tenth of the number of binaries need to be sent and translators do not have to be concerned with the exact structure of the files. The extra time spent recompiling the application for each new build is no longer necessary. One only has to place the translated exe's or dll's into an existing installed build to be able to see the new translations.

Furthermore, if a company takes advantage of the various tools available for binary localization, resource objects and strings can be locked and any information that might be trouble some for the translator can be filtered out. The only elements of the application that the translator has to be concerned with are the ones that need to be translated. This filtering of information not only makes the translator's job simpler, it also prevents accidental translation of untranslatable text and corruption of the application.

Fixing User Interface Bugs

The objective of the QA team is to find errors, graphically or linguistically, in the User Interface by taking the application through its paces looking for problems. With an RC-based process, this may be the first time some of the dialogues and messages are actually seen in the dynamic context of the application and invariably problems will be found. When this occurs, the engineer and/or translator must return to the source file, fix the bug, send the file to the engineer who rebuilds the application and sends the compiled module back to QA for further testing. In fact, in a complex product, just tracing the defect observed by running the product back to the correct source file can be time consuming and error prone.

The localization of binary files can make user interface bug fixing considerably easier and less convoluted. When a user interface bug is found during QA, the localization tool itself can be used to fix the problem and extract a new working version of the module. This makes the fix immediately available for further testing by simply updating the relevant module in the installed build. The extra compile steps are eliminated from the process, saving a considerable amount of time in the long run.

Overall, the amount of time spent fixing user interface bugs is greatly reduced when localizing binary files.

Verifying Internationalization

Some of the more advanced localization tools currently available now have utilities that allow you verify that an application has been properly internationalized before you begin the localization process. This is accomplished through a utility that allows you to 'pseudo-translate' modules before actual translation work is begun. Pseudo-translation allows the engineer to simulate the effects of accented or extended characters and increased string lengths on the application to verify that it will continue to work correctly in the target language. With a binary process, this can be readily done without recompiling by pseudo-translating the module, dropping it back into an existing installed build, and checking to see that the application continues to function properly. This process helps identify code bugs that may arise from the translation of resources before localization begins rather than at the tail-end of the process when the translated version is built for QA testing. By catching the problem up front, the developer has a better chance of maintaining a single code base rather than having to create a special build for a particular language. And depending on the tool used, the process of locating the source of the problem can be much easier than chasing it down with RC files. Additionally, going through the pseudo-translation exercise can also help find resources that need to be locked in order to prevent their translation.

Better Translation Quality

Another great advantage these tools bring to the localization process is that they give the translator an idea of the context of strings that is not available in RC files. Many tools include a visual representation of dialogs and menus to let the translator know exactly how a string will appear in the final application. With applications that conform to Microsoft Foundation Classes (MFC), some tools align menu items with their associated Tool Tips and Long Prompts in order to provide context for the translator.

Addressing the Concerns

While the benefits of binary localization are easily recounted, many localizers are still apprehensive about switching from their current RC based approach. Reasons most often cited include concerns about ability of tools to handle custom resources, loss of comments in RC files providing context for translators, the availability of translators who have the tool needed, code bug-fixing processes and general concerns about the stability of the tools.

When moving to binary localization, localizers are usually apprehensive about their ability to correct code bugs created during localization. The translation of sensitive strings can sometimes uncover code bugs that must be adjusted in the application's source files. When RC files are localized, comments and IDD resource names in the RC files can help point out where a functionality bug may lie. When localizing binaries, this task can become more complicated since engineers no longer have the utility of comments and IDD resource names when tracking down bugs.

While the extra effort in tracking down code bugs is definitely a burden, the issue helps point out broader problems in the localization procedure. As Peck points out, early detection of code bugs allows the maintenance of a single code base for all languages the application is to be localized into. If RC files are localized, code bugs will only be revealed once the application has been translated and compiled. The bugs will therefore have to be corrected in the localized version of the application, hence creating differences between the original and localized code. As differences between the original and localized codes grow, versioning information and updating of source files becomes more complicated than it would be if the application maintained a single code base for every localized language. When switching to binary localization and using utilities such as pseudo translation, code bugs can be found and adjusted before any translation is done. Therefore, a single code base can be maintained for all language versions of the application.

Another fear cited by product managers considering the switch to binary is that they are uncertain as to whether or not a tool is sophisticated enough to handle their application and localization procedures. While this is a valid concern, the developers of localization tools have been working hard to address these issues and some products are now in their third release version. While no tool is perfect, these tools have progressed steadily in terms of stability and robustness with most users reporting benefits that far outweigh any shortcomings. Additionally, many tools either currently, or will soon, allow you to export glossaries and translation memories in Translation Memory Exchange (TMX) format as sanctioned by the Localization Industry Standards Association (LISA) thereby giving the user portability to change tools or processes at a later date.

All of the above arguments make it clear that when localizing standard Windows/MFC applications, the localization of binary files is significantly faster and easier than the localization of RC files. Binary files provide an almost error free process that reduces the number of files, helps simplify the build process, and improve the bug fixing process. Overall, this process saves a phenomenal amount of time and money, helps improve the accuracy of localization, and makes the entire process faster and less painful for engineers and translators alike.  While binary localization may not be an option for every company and every product, and a large amount of effort needs to go in to changing the process from RCs to binaries, it is certainly an option that should be considered by product managers and localization engineers looking to simplify and expedite their processes. When considering the transition, project managers should be sure to consider the analysis and investment that may be required to internationalize the product before localizing binaries. Internationalization strategy often has to be changed, as do several localization procedures. Localization tools should be chosen carefully with emphasis on their handling of the languages that the application has to be localized into, and training on the new tools may be required for translators and engineers.

While all these issues require some time and effort, considering them and moving to a binary localization process can result in notable savings and convenience to your localization process.

Lingobit Localizer Overview

Software Localization using Lingobit Localizer