XML in Localisation: What can it really do for us?

Have you ever wondered how xml could possibly be relevant to our needs? Localising xml files is pretty much straight forward. But what of using XML to localise?

As localisation professionals we’ve all known about XML for quite some time now. We understand that as a Markup Language, it is closely related to HTML. We also know that it is Extensible, meaning that the tags and structure are user-specific. This gives us the picture of a very powerful and flexible language.

But I’m sure we also all have come across an xml-based document (a “.xml file”), which we have launched in our favorite browser, only to be treated to a pretty unattractive page of…XML code!

So what can that powerful and yet somewhat undefinable animal really do for us?

This article shows a practical example of xml technology applied to a specific localisation process. In doing so, it also illustrates some of the advantages of having a dedicated Localisation Team or Department, rather than allowing various departments in an organisation to manage their own localisation. In this case, a simple handover of responsibilities from a Marketing team to a Localisation team generated a major leap forward in process, efficiency and quality control. Here is how:

Original setup

In this organisation, the process for creating and localising marketing and web content was the following:

• 1 master document – the product sheet – was created for each new product released.
• The product sheet was localised into 13 languages.
• Relevant  sections were pasted individually into the website for each language.
• Relevant sections were also pasted individually into a printable version which was converted to PDF again for each language.
• The localised doc files were also circulated.

There were 2 major issues with this:

1. Copying and pasting made the process extremely time consuming and error prone.
2. No translation memory system was used, making leveraging impossible and quality control of the localised content solely reliant on proof readers.

Solution implemented

The Localisation team was handed over the responsibility of localising this content mainly to free-up Marketing resources. Rather than simply taking over, they identified opportunities for improvement and initiated an R&D effort in xml Single Source Publishing. The goal now was to automate as much of the process as possible, and free-up time within the agreed standard turnaround for systematic quality control.

The new process ended up as follows:

• Product sheet created in xml by the authors, using the free WYSIWYG XML authoring tool Altova Authentic®.
• The xml schema was designed to be compatible with the web content management system used to create localised product pages.
• A Trados ini file was created to parse out all non-localisable content in the xml code.
• XSL Transformation and Apache FOP were used to automatically generate all localised XML, HTML, RTF and PDF copies after post-translation processing in Trados.
• A VB Developer created a tool to manage all Altova StyleVision®-based automation from one single UI.

Result

• Upload of complete xml product sheets to the website for each language rather than copying and pasting independent fields (unfortunately batch upload was not permitted by the web content management system).
• Internet team saved 75% on the time required for localised product webpages to go live.
• Other content types were all published simultaneously.
• Use of Translation Memories and pro-active Terminology Management cut cost and increased consistency.
• Thorough Quality Checks were also processed in batch using QA Distiller™ which helped catch multiple terminology and value errors before publication.

The key to the success of this new setup, apart from choosing to use XML, was the ability to revise the process from beginning to end. Because the Localisation team were allowed to have a say in the authoring process, efficiencies were generated on the whole span of the Marketing and Web content creation and XML Single Source Publishing was successfully implemented.

Advertisement

SDL Trados 2007: License Server Setup

Using Technical Support Advisors (TSAs) to produce Knowledge Base content is a logical choice: they are in-house native speakers with unbeatable product knowledge, who can produce source and localised articles at minimal additional cost if they can work around their other duties.

What can be overlooked in such a seemingly efficient setup is Translation Memories (TMs). This case shows an example of such a setup being integrated with Trados TM technology.

Original setup

• English articles were produced at a sustained pace by a team of dedicated technical writers.
• TSAs were involved with their review and the creation of some English articles.
• Translation would be undertaken by native speakers in TSA, when time allowed.
• Percentage of translated articles was low and loosing ground.
• Lack of version tracking meant English articles may be updated several times before translation work started.
• Reusing existing translations and updating existing articles was tedious, and sometimes led to the re-translation of entire sections or documents.
• There was no terminology control and references to UI terms (e.g. OS or software strings, firmware messages etc.) were entirely ad hoc.

Solution implemented

• The corporation setup a Trados Network License Server as part of the Trados 2007 update.
• Thanks to the different time zones involved, a sufficient number of Trados licenses was available to equip the Technical Support translators.
• Initial training and a reference manual was provided.
• A Termbase was loaded into Workbench to provide integrated reference across content types.
• Some Winalign work was also done to start populating the Knowledge Base Master TMs before Trados-based translations even started.
• An engineer was assigned to run TagEditor Verifiers and QA Distiller checks on the new translated content to help increase overall quality.

Result

• The gap between the English and localised Knowledge Base narrowed, especially for the most viewed cases.
• The quality and consistency of the articles increased.
• The pace of translation increased.
• The setup was used beyond its original scope, supporting updates to the parent corporation website.
• Substantial cost was saved and projects delivered which would not have received cost approval necessary for outsourcing.

One of the things which made this project a big success was its negligible cost. The investment was null since the whole setup was based on better utilising existing resources. In such a scenario, the cost of a full-blown Global CMS system would have been impossible to justify..

SDL Trados 2007: Translation Memory Strategies

What is the best way to organise and maintain Translation Memories?

I currently maintain TMs using 2 features of Trados (the Attributes and Master/Project TM dichotomy) and Alchemy’s Trados component.

Master TMs

• single and exhaustive repository for each field and language pair (e.g. EN-FR Medical).
• used to analyse all new projects and generate Project TMs.
• content of Project TMs are only added to it when full project cycle has ended (including review, QA etc.).
• because of their exhaustive nature, Master TMs tend to grow rapidely and would not be practical for inclusion into a translation kits.
• even when outsourcing all or most of the localisation process, these should always be held by the client as they are a valuable asset which they own, regardless of whether they are outsourcing TM Management.

Project TMs

• specific to a project or project stage (i.e. successive handoffs of a same project often have their own Project TMs).
• used to pre-translate the handoff (i.e. generate the TTX files to send to the vendor).
• passed on to translation vendors for analysis and use during interactive translation.
• used during post-translation engineering (bugs are fixed in Workbench + TagEditor + MultiTerm interactive translation environment by the localisation engineer).

Software TMs

• single and exhaustive repository for each field and language pair, generated bi-yearly from Catalyst TTKs.
• added to Master TM of their field and/or used as Concordance reference during translation of help, documentation, knowledge base articles etc.
• also used as leverage source for software through Catalyst.

Use of attributes

• every time a new project is analysed, custom attributes are added and set (e.g. Vendor=AAA, Project=XXX, Field=FFF).
• can be used to filter searches and analyses.
• also useful to track back on errors or arbitrate between duplications.