What exactly is translation memory? McElroy clients have always demanded the high quality that results from customized translations performed by experienced individuals with technical backgrounds, with the additional quality assurance processes of technical editing and proofing. (In other words, a human approach!) For some types of work, the productivity and the consistency of these highly qualified translators is optimized using translation memory tools. This is NOT machine translation. Translation memory tools draw strictly upon the translation that has already been performed by the translator, so that effort is not repeated and translation throughout a body of work or across multiple projects is consistent.

McElroy Chief Editor Dr. Mark Ritter teaches a course for the Austin Community College Localization Certification program on Translation Memory and Machine Translation. An excerpt from his course introduction follows. It serves as an excellent overview of Translation Memory and illustrates the value that using this technology can offer to some of McElroy’s clients.

Theoretical Background and Structure of TM Systems

Translation memory can be considered a special case of example-based machine translation, albeit with one very important difference. In EBMT, the aim is to use an existing corpus of translations to produce translations of new material. The idea is that, instead of writing a very complicated set of transfer rules in advance, an MT designer can harness the much more sophisticated transfer rules that exist in the minds of the human translators who have already produced a huge body of translations.

This of course begs the question of just how good these examples really are. Quite apart from that fundamental question, however, there is another catch with EBMT: while EBMT may eliminate the need to construct an elaborate transfer rules engine, a designer still faces the problem of deciding how to divide up the source text into units that are to be compared to the target text. The technical term for this is segmentation. If the segments are too large, there will not be enough matches to be useful; if they are too small, meaning might not be conveyed properly. There are also problems with storing the example sentences and searching through them in a practical amount of time, but these latter can be solved or at least ameliorated with better and faster hardware.

Two other important, somewhat interrelated obstacles faced by EBMT are less amenable to solution: insertion of matches into the text and what to do with partial matches. If the segment is a whole sentence, then it is easy enough to replace the entire source-langugage sentence with the match found in the EBMT database. But what if the segmentation unit is shorter than a sentence? Well, the proper placement is dependent to some extent on the structure of the target language. Thus, solving this problem automatically would in effect require the EBMT designer to create a set of transfer rules to tell the system where to put the partial match in the target language. But wasn’t this precisely what EBMT was supposed to avoid?

Apparently the best approach is to accept only partial matches of complete sentences. Unfortunately, real world texts, even of very repetitive subject matter, often do not yield enough perfect matches to produce useful documents in the target language. The output of the EBMT system could not really be called a “translation.” It would at best be a "pretranslation". A human translator or another MT system would still be needed to fill in the untranslated parts and produce a complete translation.

Translation Memory — Human-Assisted EBMT?

Translation memory systems are usually classified as CAT (Computer Assisted Translation) tools. That term is certainly more flattering to our human egos than a name suggesting that proud translators are mere servants of machines, but I would argue that logically there is not much difference. Many, if not all, TM systems even offer some sort of pretranslation function, which yields exactly the same result as an EBMT system that accepts only 100% matches.

The very first translation memory systems were proprietary. Translation Manager by IBM emerged in the mid 1990s as the first commercially available translation memory product. It was discontinued a few years ago. To my knowledge, Transit from Star AG of Germany was the next system, and is still in use. In general, software development in the TM field has been and still is largely a European affair (not so surprising in view of our country’s general neglect of foreign languages).

In 1998, I worked for the first time with Transit to leverage pre-existing translations of software manuals. [“Leveraging” is a term used—mainly by vendors of TM systems—to highlight the economic advantages of TM, and simply means “recycling” or “reuse.”]

The TM workflow is shown in the following diagram from Star AG.

The diagram illustrates the fundamental parts of all translation memory systems:

• filtering—to separate translatable text from formatting
• segmentation of the text into translation units [TU]
• comparison of each unit against a translation memory
• editing of the translation (method varies from system to system) to make sure each TU is translated
• reassembling the target language text; and
• updating the TM by incorporating new or modified material

The final TM update step of the process is called cleanup. The results are: (1) a complete file in the target language that is automatically formatted identically to the source and (2) a stored TM that now contains all the new items added in the project.