Multilingual Software Architecture
Multilingual software architecture addresses the issues of running
a single software application in several markets or environments
at the same time. Such environments can be characterized by:
- Language
- Country specific dialects or language variants
- Time, date and currency formats
- Character sets
- Address formats (ZIP code formats, telephone number digits,
...)
- Hot key assignments (Ctrl-O opens a file in an English application,
Ctrl-A in a Spanish)
- Legal differences (privacy regulations in Europe, VAT calculations,
accounting rules, ...)
Most software applications are designed to be monolingual and face
the challenge to operate in an international context later. In such
cases a first approximation can be achieved using localization
which usually refers to the translation of text strings included
in the application binaries. But localization is expensive and does
not address address the other factors in the list above. Also, localization
creates a distinct set of binaries for each language, resulting
in added difficulties during the release process.
As an alternative, any multilingual architecture separates language
specific text strings from the program code. These language specific
strings are typically moved into a resource file or into a database.
Multilingual Architecture Issues
The separation between program and strings is a first step towards
a multilingual architecture. But it doesn't stop there. The following
issues occur during any internationalization of software:
- Translation Workflow:
Imagine that a developer has just added a new field to a screen
of your program and that you have to deliver the modified application
to your clients ASAP. But before you can do so, the new field
has to be translated by N (the number of your target languages)
translators, your translation manager has to check for N Email
replies and has to be manually integrate them into your resource
files. Finally you should have made N final tests.
So what you need is a workflow application that takes care of
the organizational aspects and that helps you to reduce errors.
Such workflow applications notify translators if a change has
occurred in the English resource files and that tells you when
the last translator has returned his or her results.
- Localization Fallback Handling:
But errors are going to occur even if you are using an automated
translation workflow. Typical cases include missing translations
or missing localizable GIFs ( images that include text). In these
cases you have to provide the user with a reasonable default value
(such as English text) and you want to inform your Translation
Workflow about the error.
- Translation Cost:
You can be sure that your CFO is going to ask you why the translation
costs are so high. This is because translation is a manual process
and good translators charge daily rates comparable to software
developers. So you will have to add cost saving features to your
translation workflow such as computing the "diff"-erences
between the current resource file version and the last version.
- Translation Context:
Another persistent issue is that your translators are going to
complain about missing "context" in their resource files.
Missing context leads to wrong translations and can have very
funny results. So you have to include this consideration into
the design of your translation workflow.
- Terminology Consistency:
Finally you have to make sure that your translators use the same
words in all translations. This issues becomes even more important
if you are working with several translators at the same project
of if you are changing translators during a project. You have
to make sure that your translators use a Translation Memory and
a Terminology Maintenance Application at home. Unfortunately these
tools only work together with Microsoft Word which is not the
file format of your resource files. Or your translators don't
have the same tools installed at home.
Two MLA Examples
In this section I want to present two representative examples of
multilingual architectures: A Car Configurator
application represents a typical object oriented Java architecture.
A B2B Marketplace represents
a database oriented approach without object oriented architecture.
|
|
|
System Architecture |
Java Servlets and Business Objects with local state |
Stateless Tcl architecture with central Oracle database |
Resource File Format |
Flat File |
Database + design templates |
Translation Lookup |
Centralized "localization subsystem" with memory
cache |
Database lookup + multilingual design templates on file system |
Translation Workflow |
EMail exchange of MS-Word resource files |
Online translation workflow + content management for static
HTML and templates |
Fallback strategy |
Explicit fallback rules + logging of fallback events for the
translation workflow |
Return of English text + error emails to the translation workflow |
Templating |
No templates |
Design templates with separate components for all localizable
items |
Performance |
Translation strings cached in RAM because of slow Java-DB
access speed |
Database access for all localization strings because of fast
DB connection |
Both multilingual architectures have proved to work well in practice.
However, the way of maintaining the systems is very different:
- The Car Configurator maintains all
translatable items in Microsoft Word resource files structured
as tables. This makes the work very easy for the translators who
can use the Trados translation memory and MultiTerm terminology
maintenance component. Also, this makes email communication easy
with translators who are not very technology savvy. The organizational
overhead is limited because there is only a single resource file
per language.
- The B2B Marketplace includes
its own online translation workflow that allows translators to
work directly with the system. Consistency and error control is
automatic. However, translators were complaining about missing
context and expensive online time. Translation is now done by
in-house translators in local sales offices, so that these issues
have become less important.
Conclusion
Both multilingual architectures present viable options. However,
I recommend to define clearly the linguistic and organizational
aspects before the implementation of a MLA.
Please contact us if you have doubts,
questions or comments.
|