Solution

A trend towards binary localization in past years

A significant trend over the past number of years is the rapid decline in the translating of source files. As products are better designed for localization and avail of the Microsoft Foundation Class API's and toolkits, the need to send source files to translators has diminished.

Instead, development companies are now sending out the compiled resource files for translation and using advanced translation environments like Alchemy CATALYST to speed up and reduce the complexity and cost of localization.

How localizing executables surpasses source files

All the information held within a resource file (.RC, .Resx, .Hpp etc.) is maintained and stored in the Microsoft binary equivalent. This enables one compiled resource file to be sent out for translation rather than the numerous constituent resource files.

This dramatically reduces the overhead of file management, speeding up the translation process and enabling more languages to be handled in a parallel fashion.

One user of Alchemy CATALYST technology regularly sent out over 750 resource files for each language version of its product! Changing over to a binary translation method reduced this number down to 2 files.

While this significantly reduced the complexity of their localization process, the real benefit of this improvement was that they now had the bandwidth to do more product localizations in parallel with the same number of Engineers. Additionally they now had the ability to simultaneously release multiple language products.

Reduced Complexity

1. Since the number of files dispatched for translation is significantly reduced, the overhead of file management is reduced in terms of complexity, engineering time and overall project cost.

2. No need to support complex and large build environments as the binary file contains all the necessary information to translate, engineer and test the translated application.

3. No need for extra development and compiler licenses as they're simply not needed anymore.

4. No compiling required. Since the binary is being edited directly, the need to recompile your translation disappears.

5. Translators can translate in a visual environment without any danger of accidentally damaging critical code sections of your resource files.

More efficient use of limited resources

1. Reducing the complexity of the localization process increases team bandwidth enabling more languages to be handled in parallel, reducing lead-time on product releases and thus reducing overall cost.

2. Since there is no compilation process required, the downtime between releases of builds to your testing team is reduced substantially.

3. Your engineers can achieve faster debug-fix cycles, since translation bugs can be fixed immediately without recourse to re-compile and re-build.

4. Product revisions can be updated quickly, automatically and in a predetermined and structured way. This reduces the impact on testing and engineering, shortening development cycles and creating greater velocity in your organizations ability to release language products.

More secure method

1. Sensitive source files such as .CPP, .C, .H, .RC, .LIBs, .Resx do not need to be dispatched to translation agencies, ensuring that you protect your IP and investment in your code. All you need is a compiled resource file. (i.e. DLL, EXE ).

2. The potential for damage to your source files due to the translation process is eradicated. This reduces your engineering and testing requirements.

Reduced Lead-time and higher quality products to market

By creating additional team bandwidth and capacity, more products can be localized simultaneously, less time needs to be spent on engineering and more time can be spent on structured testing.

 

Related topics

 

Products or Versions Affected

  • Alchemy CATALYST 5.0  and greater