How to Reuse Your Translation Glossaries Efficiently


October 19th, 2013, Roman Mironov

OmegaT glossary viewIsn’t it frustrating for a translator to use a translation of a term in a given project that is worse than the translation used previously for another client? Not only it is worse, but the translator may also waste time researching this translation all over again! Could there be a better way than reinventing the wheel each time?

Glossary situation

Until recently, we have been maintaining glossaries on a per-client basis only. Whenever we launch a project for a new client, we create a client glossary. Translators and editors add terms to this glossary during each project for this client, so the glossary is reused in each project. This is fine, but it limits each glossary to that specific client. Terms added to per-client glossaries are seldom reused elsewhere. What we need to do is merge all client glossaries into one big collection of the best translations per subject matter area: medical, legal, business administration, and what have you. And then reuse this big collection—let’s call it a general glossary—in each project in that subject area, together with the client glossary for that particular project.

Advantages

Having a general glossary means that instead of researching terms already translated in other projects, a translator sees those terms within a CAT tool and conveniently inserts them into the translation. Those terms are often better translations than a translator can find on their own, since the glossary entries are usually honed to perfection.

This glossary provides a great opportunity for improving quality, too. Checking translations against this huge collection of terms can reduce the risk of mistranslations (a QA program shows that a translation is different from the one in a glossary) and omissions (a QA program shows that a specific translation was expected, but was not found). Yes, it takes time, but this time is well spent. Not that I am implying that manual editing is unnecessary; I simply suggest that checking against such a glossary can be another powerful QA step.

Downsides

  1. It is not clear yet how to handle terms already available in a general glossary, but not in a specific client glossary. Because translators will see those terms in the glossary window within a CAT tool, they are less likely to add them to the client glossary. But it is important to do that, since they will use the client glossary later to check terminology in a QA program. So translators either have to add terms to the client glossary or use both glossaries for checking terminology. This uncertainty may increase the risk of inconsistency.
  2. General glossaries require maintenance. It is important to update existing translations, just as it is important to add new ones. Otherwise, glossaries will soon become outdated, and the translation team that works with them will be less interested in using them.
  3. Adding a general glossary to each project takes time and effort.

Technical side

Approaches to using general glossaries depend on the translation environment. The easiest and least efficient way is accessing a glossary directly by opening a glossary file and searching for terms. Another way is uploading a glossary into a web-based database that allows searching terms through a browser. Better yet, a glossary can be made available within a CAT tool. For example, the translation program OmegaT, since version 3.0.5, provides a convenient way to work with general glossaries. You add a general glossary together with a client glossary to a project’s glossary subfolder. OmegaT shows results from both and highlights those from the client’s glossary, so that you know that they have priority. A general glossary can be conveniently added to an OmegaT project by creating a symbolic link to it, while the actual glossary rests in a central location. This allows using one glossary file simultaneously in all open projects, instead of creating multiple copies of that file.

If you have anything to add, feel free to comment! If you liked this post, please tell us so by subscribing to our RSS feed or “liking” us on Facebook.

Tags: ,

Комментарии:

  1. Great truth. For years I have structured my glossaries on subject areas, not clients – this allows reuse of terminology across customers. I do not use OmegaT, but you can also obtain the same results with Multiterm. If really special customer-specific terms are used, I simply create a second glossary that is specific for that customer, and use both glossaries at once. However, when I add new terms (since they are not specific to that customer), I add them to the general subject glossary.

    • Hello Ramon,
      Thanks for sharing your experience.
      I need to sell my team on starting to rely on subject area glossaries mainly, and your example will help me make my case.
      Best,
      Roman

  2. Glossaries are very important in our job. I’ve never heard about such approach though!

  3. Customers come and go, but the subject areas remain the same, and very often you can reuse terms across customers. Try it out, the moment you merge the glossaries from many customers into a subject-specific glossary, you will be amazed how many terms you have suddenly!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

  • RSS

    Subscribe by E-mail

  • © 2005-2014 Velior

    Contact Us

    Phone

    +7 (962) 155-89-07
    +7 (4932) 23-87-23

    info@velior.ru
    velior@list.ru