tranfree issue 13 - 15th April 2000

Localisation Project Models

By Bert Esselink

This is my fourth contribution in a series of four articles about software localisation. The first article discussed the differences between translation and localisation, the second provided an overview of translation technology, and the third article covered the localisation industry developments. In this article, I will focus on localisation project models and the way the web is changing them.

Traditional Project Models

The "Guide to the Project Management Body of Knowledge" published by the Project Management Institute (www.pmi.org) defines project as "a temporary endeavour undertaken to create a unique product or service." This definition also applies to most traditional localisation or translation projects. Localisation projects usually start with a publisher sending out a localisation kit with all source material to a translation agency. The project manager sends out the relevant documents to a translator or a group of translators, schedules the time required to translate, edit, and proofread the material, and returns the translations after completion to the client. Projects have a definite beginning and a definite end.

Before the introduction of translation memory tools, translation work would usually not start until the domestic product was finalised and sometimes even published or shipped. After design, development, and testing of an English product, only limited time was scheduled to create localised versions of a product. Nevertheless, foreign users often had to wait for months before a version of the product in their language was available.

With the invention of translation memory and other computer aided translation tools in the beginning of the 1990s, this model changed dramatically. Publishers started aiming for simultaneous release (simship) of the domestic product and at least the most important target languages. This meant that translation already had to start while the source material or product was still being developed or written. The only way to effectively re-use translations of material that was still "under construction" was to use translation memory.

In most of today's localisation projects, translators start translating the a first draft of a product, and then leverage all translations already done by importing translations stored in a translation memory database. The only way in which simship of different language versions can be achieved is by combining translation memory with a thorough internationalisation of the product, i.e. separating language-dependent information from the product's layout or code information and thus limiting the amount of testing or layout work required for localised versions after translation is finished.

Tomorrow's Project Models

With the web, a new type of localisation model is evolving. Professional web sites are usually dynamic, database-driven sites, where all information and text is stored in a database, which automatically publishes information to web pages whenever new content is added or changed. Web sites are updated on a continuous basis. This means that translating a web site cannot be considered a "project" anymore; instead, it is a continuous flow of changes and updates. In the case of multilingual web sites, changes in one language should ideally be reflected in the other languages immediately.

This new localisation model, which is characterised by small "chunks" of translatable information, has called the need for more automation. Sending each small change or update to a page on a web site to a project manager, who then coordinates the translation in all required languages is just too time-consuming and inefficient. This is the reason many translation tool developers are now working on workflow systems which enable companies to automate the transfer of files between all people involved in a translation project, i.e. client, project manager, translator, editor, proofreader, client validator, etc. Examples of such tools are Lionbridge's LionTrack and SDL's SDLX WebFlow. Apart from workflow automation some  of these tools also contain online project tracking features, so clients can see any time of the day how far translation of their material has progressed.

Implementation of these systems requires a thorough analysis of the client's and vendor's processes and information flows, so the tool can be customised. Moving to this new, automated localisation project model also means that many clients are looking for long-term partnerships with localisation vendors, in order to better integrate them in their development and business processes, and to build up expertise and product knowledge in one central location.

In a few years from now, it is not unlikely that translators will be part of "virtual teams" working for one or more clients. These teams will consist of translators who, regardless of their location, have all qualified or received training to do translations for a particular client. If new information is added to the client's web site, the text is transferred to the first translator in the team, who then indicates if he or she is available to do the work. If rejected, the job is automatically passed to the next translator in the team until someone can do it. After translation, the translated material is automatically transferred to a reviewer working for the client, who approves the translation so it can be merged back into the multilingual database for publication on the web.

Workflow automation enables project managers to focus more on...

... managing, such as resource management, quality management, scheduling, and budgeting, instead of acting as a "post office" sending files back and forth between translators and clients.