A CTOs View to Localization
This article has been updated and moved
to a new location.
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 foreign markets, for example
to Europe. Your software has been designed for the American market
In this situation, you basically have two choices:
- Full service Localization:
If your system is based on Windows, you can take your .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.
- Multilingual Architecture:
You can work on your software architecture to factor out all localizable
items into external resource
Apparently there are advantages and disadvantages with both approaches:
|Time to Market
|Development Cycle Time
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.
- 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.
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
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.
- 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.
- Development Effort:
The implementation of a multilingual architecture is time consuming
because most static strings have to be replaced with calls to
subsystem. Also, the localization subsystem requires an understanding
of the way that translators work to minimize manual work.
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
- "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.
- Multilingual software architecture needs to be build into system
from the beginning.
- If you are stuck with a monolingual Windows system and you are
in a hurry, start with full service localization. This buys you
time, and you may develop a multilingual architecture for the
next release of your software.
Please contact contact me
if you have any questions concerning the multilingual software architecture.
I will be happy to answer your questions.