The power of QA in a translation project

The Power of QA in a Translation Project

As a translation project manager, you are answerable to the customer in all instances. The project manager is the one who delivers – they can never sit back and assume that the file they receive for finalisation is without errors. Even if the translators verify the translated documents before delivering, issues can slip through the cracks, and it’s the duty of the project manager to ensure the final quality meets the customer’s requirements. 
 
However, when the deadline is NOW and people are desperate to cut corners to save time, it can be tempting to simply perform a sanity-check, instead of an extensive verification, just to deliver on schedule. Sometimes we can even get away with that, if we’re lucky. It’s risky but delivering late might be worse. However, in some cases this risk is just too big to take – one good example of this is the relay translation project.

Relay Translation

Here, each project has two translation cycles; the translation of the first phase becomes the source of the second translation phase. It might seem a rather overcomplicated road to take but often it is the only solution for a tight budget. Think about this for example: even if you manage to find somebody who can translate from Croatian into Finnish, they will surely be expensive. But you can decide to first have the Croatian source translated into English, and then the English into Finnish, and the cost of the two together might even come out lower.

And this is where project managers cannot skip any quality assurance (QA) steps: here the risk is multiplied by the number of target languages. If there are issues left in the first translation – usually into English – it will most probably be carried over to all secondary target languages. Imagine correcting mistranslations in 26 languages, not to mention fixing tag errors in languages you cannot even read! Therefore it is in everyone’s best interest to translate a file in the second round which has been through proper QA.

The Power Couple of QA: Proofreading and Verification

Even if the file is long and full of errors, there is a way to tackle the issues. Proofreading is best suited to fixing incorrect translations, but is not enough in itself to pick up tag errors. On the other hand, verification can identify missing or misplaced tags and spacing issues, but is not effective in checking for mistranslations. Hence the safest approach is incorporating both into the QA process.

In SDL Trados Studio, we can further fine-tune the QA by enabling the Terminology Verifier next to the default QA Checker feature and the Tag Verifier. In addition, we can also parameterize the checks and set the appropriate notification levels, and then nothing will slip past our thorough review and extensive verification. Below I’ve listed some features of the Studio Verifier that are important in this process, but are not mentioned enough.

Appreciating The Gravity of The Situation: The Difference Between Errors, Notes and Warning

Whether the issue comes up as Note, Warning or Error, once the verification report is complete, it usually gives us a good idea about the gravity, but not always. Luckily, not only can you define what Studio should be checking the translation for, but you can also set different levels of severity to the errors picked up (Project Settings > Verification > Tag Verifier > Common). Let’s look at a few examples where you might find some fine-tuning useful to differentiate between serious errors and potential issues in the files you work with.

  • Ghost tags: When either the opening or the closing part of the tag pair is missing, the missing tag will appear as a ghost tag, half-transparent. In the default verification profile ghost tags only come up as Notes, but since they can lead to structural issues in the target file, they must be corrected – and one way to make sure that you notice them is to set the level to Error.
  • Tag order: As languages construct sentences differently, tags might be placed in a different order in the translation compared to the source. By default these changes appears as Warnings, even if the modified order is justified. With this in mind it might sound reasonable to lower the severity level to Note, but doing so can also lead to overlooking genuine issues. So please be cautious.
  • Spacing: Studio also checks for changes in the spacing around the tags and reports them even if they are justified or have no effect at all on the structure of the final translation. Imagine a space change after or before a bold tag – it does not really matter. The default level is Note, and in most cases should be kept this way. 
  • Formatting tags: Here the change is not about the level, but about whether Studio should check them in the first place. By default they are not picked up during verification, but I would argue in favor of checking for them, if you would like to make sure that the formatting of the target document indeed matches that of the source file.

Why Not Compare Apples to Apples? Verification Settings Defined Per Language

In multi-language projects you might receive quite a few false positive errors if Studio verifies all languages according to the same parameters. It really is like comparing apples to oranges – a green orange should raise suspicion, while a green apple is in its most perfect form (hardly anyone would argue). Now, in Studio 2019 you can set different verification settings per target languages, so you will only be warned if there is a blue apple in the mix, green ones would not register. This can be neatly defined in the project template for example, and this way the verification profile can be consistent for the given target languages across similar projects.

Invite to Verify When Working With Project Packages

In the case of sending out translation jobs via project packages, you can ensure that linguists run a verification before returning the translation. It’s important to remember, however, that activating this option in the Package Return Settings will only make it required to start a verification – it does not necessarily mean that all errors will be indeed corrected. So in all cases a thorough final check is still essential, but this option can help you involve the translators more in the QA process.

Verify, Fix, Repeat

Finally, let’s say a few words about the verification process itself. It is not quite enough to run the verification, correct the errors and then close the file for good. There could always be some errors you missed, and moreover, fixing an error might create two new ones if you are not careful enough – ask any software developer, they would testify to that. Therefore the ideal process would be verification, correction, verification (and correction and so on…) until there are no errors left to fix. This does not always mean that the Messages window is empty; there still might be a handful of warnings or notes listed but now those are acknowledged and left there intentionally (change in tag order for example, as already discussed).  

In summary, each step is crucial: verification after the translation, a thorough review, followed by another verification by the project manager, who is in charge of the final checks and therefore has the last chance to pick up those errors which have gone unnoticed during the previous steps. Of course, this is a tricky task, because you may speak many languages, but there will always be some you don’t understand in the projects you manage. But you don’t necessarily have to understand them – the biggest task is to notice when something is wrong, fixing only comes second, and Studio offers a helping hand in both.

Looking for more Project Manager related content? Visit our Project Management Hub.