Translating on Good Terms

By Jost Zetzsche,
an English-to-German translator,
a localization and translation consultant

jzetzsche at internationalwriters com

Become a member of TranslationDirectory.com at just $12 per month (paid per year)

At a recent conference in Montreal I felt vindicated to hear that I am not alone in my notion of the ideal use of terminology tools among translators. Lynne Bowkers, who teaches translation technology at the University of Ottawa, gave a talk on the discrepancy between the terminology components that many translation environment tools (aka CAT tools) offer and their actual and/or ideal use by translators.

But let me start from the beginning. Although most of us already own tools that support terminological work and maintenance, we typically don't use this important part of the translation process and fail to harvest its many benefits. While we may use translation environment tools (TE tools) like Trados, SDLX, DéjàVu, or one of the many others out there, we are quick to use the translation memory component but we ignore the terminology database component. There are several reasons for this:

• The often-used term "translation memory program" seems to suggest that the emphasis is on the translation memory.
• There is a more immediate gain through perfect and fuzzy matches on a sentence-by-sentence translation memory basis than there is with terminology databases.
• Translation memories can be built up relatively quickly by aligning existing translated file pairs and/or automatically as you translate new texts.
• The construction of terminology databases is a comparatively tedious process: terms have to be individually highlighted in the translation or even entered into the terminology management application, and additional information has to be entered.

These would all be really good arguments if terminology databases were not so terribly useful! No matter how immediate the gain through translation memories, and no matter how tedious it may be to enter terms into the terminology database, it pays out. I promise!

I think of terminology databases as proactive, living dictionaries that are completely geared toward your (or your client's) preferred terminology. The idea of terminology databases is that you can view any corresponding data to any source segment when you are ready to translate it. You can then enter the displayed terms with the help of keyboard shortcuts or, as in the case of some tools including Déjà Vu, Similis, Multitrans, or MemoQ, even automatically "assemble" target segments with the relevant terms.

Since this semi- or fully-automated use of terms is part of the normal and desired workflow for the translator, the typical concepts that many terminologists believe in do not necessarily apply. Wikipedia (http://en.wikipedia.org/wiki/Terminology) describes the difference between the terminology work of traditional terminologists and translators as that of systematic terminology ("which deals with all the terms in a specific subject field or domain of activity") and ad hoc terminology ("which deals with a single term or a limited number of terms"):

[A]d hoc terminology is prevalent in the translation profession, where a translation for a specific term (or group of terms) is required quickly to solve a particular translation problem.

Exactly! Not only is it unreasonable to cover all the terms in a specific subject field, but realistically speaking it is also unreasonable to enter all the descriptive data that a "true" terminologist would enter to describe the term, including all the relations that it has with its synonyms, antonyms, etc. This is what I want to have in my terminology database for a term ("term" always includes "phrases" as well): one (!) source term, one (!) target term, the subject area, the client, and possibly a definition. In very rare cases I may add some grammatical information (e.g., whether the gender for the German translation of "URL" is feminine or neutral), and I would expect information like date of entry or name of user to be entered automatically. You may have noted that I exclamation-marked (how's that for a cool new verb?) the requirement that there should be only one source and target term. This is hugely important if you a) want to search terms automatically ("URL, Uniform Resource Locator" would neither be an automatic match for "URL" nor for "Uniform Resource Locator") and b) want to use that (semi-) automated method of entering target terms into your translation (and don't want to manually delete the first or second part of "URL, Uniform Resource Locator"). The same is true for grammatical information. An entry like "URL (noun)" would be unhelpful as either source or target. If you need grammatical information, enter it into a separate field.

Why the extra trouble of entering subject and client information? Well, if your project is well set up, your tool should do this automatically. And it is important information about the origin of the term which allows your tool to prefer a certain term over another with an identical source but a different target. Not all tools offer that feature, but you'll love it in those that do.

And here is another important difference between classical/systematic terminology and the translator-preferred "ad hoc terminology." Most tools offer a fuzzy terminology search, so that "Uniform Resource Locators" would be a match for "Uniform Resource Locator." But what about matches between the singular and plural of "mouse"? Only tools with extensive pre-configured knowledge about the source language would recognize "mice" as a match for "mouse." As a result, you are well advised to enter as many grammatical forms into your database as make sense for your particular term and source language. And even phrases like "click on the button," "click OK," or "the dialog opens" may be helpful entries in a translator's terminology database (but not a terminologist's repository).

So, let's look at the terminology component of many of the more common TE tools. There's a really interesting difference between the more traditional ones such as Trados and Star Transit and newer ones like MemoQ, Similis, or Lingotek. While Trados and Star Transit offer the complete range of functionality that terminologists require, the terminology components of many of the newer tools are simpler and more straightforward. Some companies, especially larger corporate translation buyers, use the terminology component of tools like Trados and Star Transit to their full extent, but the tools' apparent complexity tends to frighten off the freelance translator. What is not known to many translators is that in general the terminology component is only complex when used in a complex way. The ad hoc way described above is really quite simple, and has actually become even simpler in the latest releases of most tools.

And if all this wasn't persuasive enough, many tools now also offer a quality control feature: once you're done with your translation, it automatically checks whether all the terms in your project match those in your terminology database(s). Tools that offer this include Star Transit, across, DéjàVu, Trados (TagEditor), SDLX, MemoQ, and various others.

And last but not least, if for some reason you do not use a TE tool, there are also stand-alone tools such as Lingo that offer only terminology management. While a tool like this is not integrated as well into the overall workflow, it at least offers quick access to the data that guarantees the success of your project.

However, I'll still repeat my plea and hope that the chorus grows louder as more voices join in: Translation workers of the world, unite! Use your terminology tools within your TE tools!

This article was originally published at Translation Journal (http://accurapid.com/journal).

Submit your article!

Read more articles - free!

Read sense of life articles!

E-mail this article to your colleague!

Need more translation jobs? Click here!

Translation agencies are welcome to register here - Free!

Freelance translators are welcome to register here - Free!