Go here to registerGo here if you're already registered
Contact us

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.


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.