Learn how XML standards help facilitate translation processes that involve many participants in different locations. This article focuses on the most common XML formats used in the localisation industry to show you how important XML is becoming in multilingual document exchange.
Any company that seeks
Learn how XML standards help facilitate translation processes that involve many participants in different locations. This article focuses on the most common XML formats used in the localisation industry to show you how important XML is becoming in multilingual document exchange.
Any company that seeks to operate in foreign markets knows that language technology is crucial to success. Contracts, product manuals, brochures, advertising campaigns, and everything else related to corporate communications must be fashioned and adapted to suit each different culture where commercial operations are to be carried out.
This article is an introduction to the use of XML in localisation. Its objective is to provide the basis for future articles that will explain the technical aspects of the relevant XML standards.
A localisation project comprises several steps and involves many participants.
Figure 1 illustrates a traditional process in five stages. (Blue boxes in the graphic represent processes that take place in house; yellow boxes show tasks done by the translation agency.)
Figure 1. Traditional localisation process
The first stage is the creation of the documents that will need translation. For example, a typical software product might contain:
Other types of products, such as electrical appliances or automobiles, may not have RC files, but may instead require additional translation of things like complex Web sites, slide shows, or scripts for advertisements.
Once documentation is ready, it is sent to a translation agency or several independent translators. This stage is identified in Figure 1 as "Translation provider".
Usually, you need to translate more than one document format. This can be problematic for two reasons:
If you want to reduce costs, your first priority is to reduce the number of document formats.
Here's an alternative course of action:
By using this alternative method, a company can retain greater control over the process and its component parts. Additionally, the use of good computer aided translation (CAT) tools for text extraction can help reduce the need for post-translation DTP.
Figure 2 summarizes the steps described above.
Figure 2. Alternative localisation workflow
The second stage ("Translation preparation") consists of converting strings into a special XML vocabulary and reusing existing translations if they are available. This is done using CAT tools or custom-made text filters.
Once the translation agency returns a translated XML document, all strings are reinserted in the original document. This process is known as reverse conversion and is performed using the same tools used in Step 1.
The procedures described above are not new. Many software companies experience problems that result from multiple document formats, and they are searching for an XML-based solution.
In 2001, several IT companies -- including Novell, Oracle, Sun, and IBM -- formed a technical committee to write the specification for XML Localisation Interchange File Format (XLIFF), which was formally published by the Organization for the Advancement of Structured Information Standards (OASIS) in 2002.
One of the advantages of XLIFF is its relative simplicity. An XLIFF file can be described as a collection of translation units. Each translation unit contains a sentence or paragraph that's extracted from the original document in an element called
<source>, and the translator has to fill a
<target> element with the appropriate translation.
Legacy translations from previous projects can be added to a new translation unit using
<alt-trans> elements. Translators can use these translations as a guideline. Sometimes the translation in an
<alt-trans> element is perfect, and all the translator has to do is accept the suggested text.
Figure 3 shows the relationship between the different components of a translation unit.
Figure 3. Components of a translation unit
Listing 1 is an actual translation unit:
<trans-unit approved="no" id="1" resname="res1" xml:space="preserve"> <source xml:lang="en">Corporate Headquarters</source> <target xml:lang="es">Casa Central de la Compañía</target> <alt-trans match-quality="100" origin="web" tool="TM Search"> <source xml:lang="en">Corporate Headquarters</source> <target xml:lang="es">Casa Central de la Compañía</target> </alt-trans> <alt-trans match-quality="92" origin="web" tool="TM Search"> <source xml:lang="en">"Corporate Headquarters"</source> <target xml:lang="es">"Casa Central de la Compañía"</target> </alt-trans> </trans-unit>
Listing 1. Translation unit
Figure 4 shows a real implementation of an XLIFF editor with source text, target text, and proposed translations.
For more detailed information about this format, see the link to the XLIFF specification in Resources.
Possible translations contained in the
<alt-trans> elements of an XLIFF file are extracted from a translation memory (TM) database. Translation memory is a language technology that enables the translation of segments (sentences, paragraphs, or phrases) of documents by searching for similar segments in a database and suggesting matches that are found in the database. For example, a TM can be built storing translated
<target> pairs from an XLIFF file in a relational database or a specially designed TM server.
Technical manuals, legal contracts, and corporate Web sites usually contain text that is repeated in every published version. Therefore, it's a good idea to keep a TM database and reuse its content as much as possible. A good TM system can help achieve significant cost reductions in a localisation project.
The Open Standards for Container/Content Allowing Re-use (OSCAR) group defined TMX as a common standard 