"We’re changing our corporate language. Starting next year, we’ll only be producing documentation in English."
Such a decision is currently being made by many companies whose locations are not exclusively in Germany. The administrative advantages of a common corporate language are obvious: All employees have access to the same documents, which aids immensely in avoiding misunderstandings. There’s no additional time and effort involved in translating internal documentation into the respective national (i.e. “local”) languages, and the cost associated with this translation loop are also eliminated.
Wait a minute — the costs associated with this translation loop are eliminated? At this point, we have to realise that a major factor is being ignored in the calculation: In the future, the translation would have to be from English instead of German. So the Translation Memories are still empty and must therefore be completely rebuilt — a potentially expensive project.
Why is this so?
Anyone who has ever held a quote for a technical translation in their hands knows that billing in accordance with so-called match rates has become common practice: texts that have already been translated once and are already contained in the bilingual database, the Translation Memory (or "TM" for short), are subject to a higher discount than texts that have only been translated in a similar form previously. These in turn, are more heavily discounted than texts that have never been translated before. So now it becomes clear why unexpected costs are incurred here: none of the new English texts have been previously translated.
We consider still another factor: by using regular translators (who have been able to orient themselves on existing translations), a characteristic language has developed over time, that is used across many documents. This is partially due to the consistent use of specialist terminology, but also to the personal writing style of the translators. If the collection is now being rebuilt with a different pool of translators, it’s highly likely that this style will change.
So how can we now use the collections we already have? Many companies have well-filled TMs from German into the respective target language. It would be a real shame not to be able to use them in some form or another!
Step 1: Combining existing translation memories through a “relay language”
We stepped-up to this challenge and quickly found out that the magic word is "relay language". In principle, it’s not an unusual procedure. For rarer target languages, the number of people translating from English is much higher than the number of people translating from German. As it happens, companies have their documentation translated first into English and then into Korean – English is then referred to as the "relay language".
This is the path we’re now also taking. Let’s imagine that the "KS5000 Operating Manual” document is to be translated from English into French. In the past, the company's documentation was translated from German into many different target languages, including French and English. Translation Memories are therefore available in the language pairs German – English and German – French (or, to illustrate the train of thought, in the language pairs English – German and German – French, because TMs can usually be used bi-directionally). Thus, we first translate the operating manual from English into German, and then translate it from German into French. Due to our well-populated TMs, we benefit from high match rates, in both directions, and we can also use the existing translations, in combination with the specialist terminology in the target text.
Problem solved, then? No, not quite yet.
Although this workflow would be possible, it would by no means be a sustainable solution – because on the one hand, the processing time is now considerably increased by using two translators, and on the other hand, we still don’t produce a TM with the language pair English – French this way. Additionally, the cost savings of running two translations per process would hardly be noticeable. On the contrary, it could even become more expensive. So there’s a need here for optimisation.
Step 2: Optimisation through automation
Do two different translators really have to be used? Wouldn’t it be possible to automate the relay step?
We asked ourselves this question and came to the conclusion: sure, it’s quite possible. The approach to run the translation in two steps remains the same – but instead of changing the process, we modify the TMs. We know that many of the German texts are contained in both TMs, and we take advantage of this: now, all we have to do is find these spots automatically and match the English and French translations. The newly-assigned pairs are then populated in a new TM – and voilà! With this TM it’s possible to translate directly from English into French.
If this procedure reminds you of the popular “telephone game”, you’re not wrong. The risk of information being “lost in (the) translation” of texts is naturally higher, the more often these texts have been passed on. It’s therefore essential to introduce an additional control measure here. In this way, all sentence pairs created by our automation are tagged with very specific metadata and automatically subjected to closer scrutiny by the translator during the translation process. Only when a sentence pair has passed this check is it marked as a reliable database entry.
Have we reached our goal?
Yes – and then some. In addition to the obvious benefit that existing TMs can be reused for translation processes with a different source language, we’ve developed a model for checking TM entries as a by-product through the use of metadata in TMs. This quality check is performed easily during the translation process, and it can be used whenever existing entries need to be revised.
Costs kept in check
In the end, we all breathe a sigh of relief: we don't have to start from scratch, as originally feared, but can instead build upon existing processes. Building up TMs over the past few years has paid off, and in addition to the quality of the translations, it’s also reflected in the bottom-line (i.e. on the invoice): although we’ve introduced an additional quality loop, the cost of translation jobs is far lower than what would have been calculated for an entirely new translation.
