A CTOs View to Localization

We assume that you are the CTO or chief software architect of a software company. In the past you have successfully developed a software product or service. Your company is now considering to sell a software product or service to other markets, for example to Europe. Your software has been designed for the American market so far.

In this situation, you basically have two choices:

1. Full service Localization:
   Take your Windows .EXE/.DLL binary code and contact a localization agency to create a version of your code that is fully adapted to the new target market(s) without your intervention.
2. Multilingual Architecture:
   You can work on your software architecture to factor out all localizable items into external resource files.
   

Apparently there are advantages and disadvantages with both approaches:

Full Service Localization

Specialized localization agencies possess tools that allow to strip most localizable items such as strings and icons from Windows binary files. These items are then send to translators and the translated strings are merged with the code to form a localized executable. There are some issues with this process, but it works well in general.

Advantages:

• Low dedication:
  The client software company only needs to deal with those GUI elements that cannot be handled by localization tools such as date and time formats.
• Time to market:
  You can get a localized product in a very short time, limited only by the number of translators involved.

Disadvantages:

• Cost:
  The localization process involves a lot of specialized manual work and is thus quite expensive.
• Development Cycle Time:
  The extraction and merge process has to be done manually for each new software release. This can become a problem if you are releasing updates frequently.

Multilingual Architecture

Another option is to change the architecture of your software application to separate the program logic from all language specific items ("Multilingual Architecture"). The language specific items are factored out and maintained in external "resource files" or in a database.

Advantages:

• Cost and Development Cycle Time:
  The localization effort is reduced to the translation of the resource files. Typically, software architects design the resource files in such a way that they can be easily converted into MS-Word format. MS-Word is the preferred word processor for translators because most Computer Assisted Translation (CAT) tools such as translation memories and terminology maintenance are available for it.
• Single Binary:
  A multilingual architecture allows you to release a single binary to all users. Your users can change their language preference at runtime. Or you can serve several users with different language in the case of a server application.

Disadvantages:

• Development Effort:
  The implementation of a multilingual architecture is time consuming because most static strings have to be replaced with calls to the localization subsystem. Also, the localization subsystem requires an understanding of the way that translators work to minimize manual work.

Localization Subsystem

The term "localization subsystem" typically refers to all elements of application related to the management of language and cultural preferences. A localization subsystem usually consists of the elements:

• Resource File Interface:
  A simple API that returns a localized string from a resource file or a database table.
• Localized GUI Components:
  Frequently used GUI components makes it easier to program complex GUI screens.
  • "OK" or "Cancel" button that automatically appears in the right language
  • Date and Time Components:
    The date and time formats may vary between countries: "10/31/2001, 3:24pm" is not acceptable for a German user. He expects to see "31.10.2001, 15:24".
  • Sorting and Collators:
    Sort order is language dependent, so all list presenting GUI components need to take a locale as a parameter.
• Translation Interface:
  Translators are highly paid specialist, so it is advisable to optimize the input for them. This may include a MS-Word or MS-Excel export function for the resource files and the management of resource file differences using "diff".
  

Additional complexity is introduced if you have to deal with double byte character languages such as Chinese, Japanese or Korean or in the case of right-to-left languages such as Arab and Hebrew.

Conclusion

• Take multilingual software architecture into account next time you develop software from scratch.
• If you are stuck with monolingual system and you are in a hurry, start with full service localization. This gives you the time and the financial resources (from the oversee sales) to upgrade you software with the next release.
• Try to switch to a multilingual architecture as soon as possible to save localization costs.

Please contact Frank Bergmann if you have any questions concerning the multilingual software architecture. He will be happy to answer your questions.