Isn’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?
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.
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.
- 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.
- 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.
- Adding a general glossary to each project takes time and effort.
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.