There's a new feature in the latest memoQ version I'm very happy about – until now, whenever you assigned a term base to a project, it was also used for Quality Assurance (QA). But from now on, you can choose which term bases in the project you want to use for QA.
You may wonder what the point is... but that's a bit longer story. Please bear with me.
Computer Assisted Translation (CAT) tools are a great help with translation, and from the very beginning, their main selling point was the translation memory (TM), which will insert 100% matches, show fuzzy hits, and help lookup terms or phrases with concordance. Then came the term bases (TB), quality assurance (QA) features and many, many more. The TM is still the most basic feature of any CAT tool and TMs statistics are the basis for most quotes in the translation industry. However, it can be a mixed blessing, especially if you work for LSPs, where you often deal with TM matches from many different translators writing in different styles and using different terminology. That's where TBs come in – they make it possible to manage terminology within a project or multiple projects for a given product line, even if you start with an inconsistent TM.
Personally, I find TBs to be much more valuable resources than TMs – of course, if they are properly curated. Just enter terms to your TB as you are working on a project, and next time a term appears in the source text, memoQ will do three things:
1. Tell you how the term should be translated.
2. Help you type it quickly with predictive typing.
3. Verify if the correct term was used (after you confirm the segment).
All three are great, and the QA check for TB entries is an invaluable tool for translation and review. QA is your friend, and when you see that yellow lightning icon, it means something is wrong with your translation (or with your QA settings). However, there are situations when you want all the benefits without commitment – that is, getting the translation for a term and also the predictive typing, but without QA warnings for terms. Why? Let's see.
1. You don't have time for setting matching right, and you don’t plan to use this TB for other jobs. For many languages, including Slavic languages like Polish, inflection is a serious problem when it comes to terminology recognition. Let’s take a look at this example:
| pinnace | ścigacz ścigacza ścigaczowi ścigaczu ścigaczem |
And that’s just the singular form (add three more cases for plural). Does that mean I have to enter all five forms into my TB? Fortunately not, as memoQ offers four different settings for the Matching option: 50% prefix (default), Exact, Fuzzy, and Custom.
| bridge (on a ship) |
mostek mostku mostkowi mostkiem |
As you can see, the lemma here is “most” so the default 50% match won’t work. But Custom comes to the rescue: we can manually set the lemma with a pipe character (|) and while in Translation results memoQ will display the term as entered (usually the nominative case: “mostek”), it will match only the part up to the pipe character: most|ek. This will match all inflected forms of the term. And if you want to use Custom matching for cases where the nominative form equals the lemma, you can use an asterisk: ścigacz*.
The downside of this method is that to get an error-free matching (and no false QA warnings), you need to manually edit the terms every time you add them to the TB. It’s usually worth it, and is not so much effort, but if your TB is intended as one-time help, e.g. for assuring correct spelling of names of individuals or companies, you may skip this step. You’ll get the benefits without that bit of extra effort.
2. You want a TB just for typing assistance and MatchPatch (the best two things since the invention of TBs), and your project isn’t big enough for training a Muse. This is where the option for excluding a TB from the QA is the most useful. When you ask a terminologist what a term is, you’ll get a nice, deep definition, but I really like what István Lengyel once said during a memoQfest conference: “for us, a term is whatever a user puts in a term base”. So now you can have two TBs in your project: one with proper terms and stuff you need to get right, e.g. software UI elements or client terminology, which will be verified by QA, and another “helper” TB, where you can quickly add the translation of that word you keep forgetting; names that can be used but don’t have to be inserted into the translation every time; and frequent phrases. Once you have a long phrase in your TB, you can insert it very quickly, but you can also change the wording if it fits your text better and you won’t get a QA warning. If you work on something new, and you have some references, like a TM or a bilingual corpus, you can even run a quick terminology extraction and use phrases in the non-QA TB as a tool for improving your productivity.
You might say that this was all possible before, so what’s the big deal? QA checks are your friends, but when you know you have false positives, you may overlook some real errors, and having a “lightning-free” text speaks well of the translation. In my opinion, it’s a good habit to check warnings immediately to avoid propagating real issues, and having lots of warnings you know you can ignore makes that approach useless and erodes your vigilance.
One little check box next to the TB name can go a long way to make better and more productive translations.
About the author: Marek Pawelec is an English to Polish translator specializing in Medicine, Chemistry, Biochemistry and Literary translations. You can follow Marek on his twitter alias @wasaty.
