In these times of global brands and localized marketing, what exactly is translation quality? Like many other concepts where translation is involved, it depends on the context.
Quality assurance (QA) was once considered equally important to the translation itself. After every translation was completed, it was expected that at least one reviser or proofreader would go over it before publication. Quality managers simply didn’t exist. Instead, any project manager found the more glaring errors in formatting, layout, or even branding that might have slipped through. Even when they didn’t know anything about the target language.
Those times are long gone.
In the past decade, the explosion of both static and — for the most part — dynamic content left little time for QA on every piece of translation before publication. With more content being produced every year, the quality manager position evolved to better manage complex production and localization workflows.
What does this mean for translation quality itself? Painstaking industry collaborations resulted in the quality standards we know today, and the idea of “fitness for purpose” became a functional compromise for both buyers and service providers. A quality standard pinpoints the errors, but if the translation is fit-for-purpose, then maybe we don’t need to assign all the resources needed to get a near-perfect translation.
QA technology saw a parallel development — take, for instance, the process designed to match the translation to the quality standards. There are now more QA tools for translation and localization than ever before, both stand-alone and built-in CAT tools. Put together, they create a false sense of security — a sense that we have at our disposal the means to identify and fix anything and everything that might be wrong in a translation.
Another common myth is that we can do everything without a human reviser. Whether we look at stand-alone QA tools that linguists can use to validate and improve translation quality, or we consider the QA modules embedded in CAT tools, there are some obvious disadvantages that have made them rather unpopular. By extension, they made the QA process a box-ticking exercise that all too often is an afterthought.
These tools were intended to automate the process of QA in post-translation and help revisers and proofreaders find errors and apply corrections — which is exactly what you want, ideally. The problem is that language-agnostic QA tools produce far more false positives than legitimate warnings. Revisers have used these tools for years, struggling to sift through the numerous warnings and find the real errors. This experience is in a translator’s DNA, and it’s not a pleasant one. The negativity eventually seeped through to layers higher up the chain — language service providers (LSPs) and translation vendors. And that’s how Linguistic Quality Evaluation (LQE) was born, in effect as a necessity from the inadequacy of traditional Linguistic Quality Assurance (LQA).
In essence, LQE was yet another compromise. Decision-makers on the vendor side figured at some point that LQA was not efficient and cost-effective — or, at least not the way they were doing it. So instead of fixing translation errors before publication, they would use a quality score on a sample of the translated content to determine quality. If the translation received a score over the agreed threshold, it was approved — but a low score required revising before publication.
There are many issues to consider with this practice. First of all, LQE reinforced the idea of “fitness for purpose,” perpetuating the notion of “quality as an afterthought,” something no one intended. If nothing else, any quality process revolving around content production is by design holistic — it begins at the authoring stage and extends to the last steps of product delivery. It also made sampling an acceptable benchmark: With LQE being a largely manual process (with a reviser providing feedback on quality issues by manually adjusting the scoring scale), no one can afford the time and money to do LQE on every bit of translated content. Instead, if a small sample (usually around 10% of the total) receives a good LQE score, one can assume the remaining 90% is also of the same quality.
But there’s another shortcoming. In the context of more modern quality programs, LQE is done after publication, with the intent of monitoring and improving future production cycles. This means its role is rather retrospective, and it can’t help catch and fix errors, like LQA normally can.
Let’s do quality better
Whether out of necessity or choice, these practices have been in place for far too long, and it’s time to change them at the core. A quality program would ideally incorporate both LQA and LQE, as they are both important — LQA in addressing issues before publication and LQE in ensuring whatever process works today also works tomorrow (and if something doesn’t work today, we make sure it works properly tomorrow).
How can we set this up?
– Eliminate as many as possible of the manual steps in LQA and LQE;
– Use a reliable and accurate LQA system that will not produce many false positives, thus reducing the number of manual steps needed for corrections; and run your QA checks while you translate;
– Streamline LQE for everything you are translating and compare quality scores to everything you have translated before.
– Whether you build or buy your QA, it needs to work well together with your TMS, CAT and all your other business systems; ensure all the pieces of your localization process, including those for LQA and LQE, can be connected together in one technology ecosystem — both internal and external stakeholders will thank you for it;
– Reduce the effort and maintenance overheads by going online; enhanced communication between desktop systems is impractical and improbable;
– This will also encourage connectivity and interoperability amongst other players in the industry, making systems and processes quicker to react and cheaper to run at scale.
In the process of consolidating LQA and LQE in one quality program, especially in the context of continuous localization scenarios where everything is constantly updated, it is easy to conflate the two processes. One might think, if I have either one or the other, my quality program is fine. But complementary as they might be, their scope is different. So is the way you apply them in localization. For example, LQE on its own can tell you very little about the pain points in the whole corpus of your translated content. As a result, you can never be sure how many potentially critical errors have slipped through.
However, when you put the two together, and you process LQA data through the lens of LQE, you can actually get a 360o view of your translated content’s strengths and weaknesses. By connecting your LQA data with a business intelligence system, you’ll quickly learn about each language’s performance, how your translators and revisers are reacting to the LQA input, and how to make things work even better in a more targeted way. As part of this targeting, it shouldn’t surprise us that big translation buyers are currently investing even more in their quality programs. Instead of giving up on LQA and LQE altogether, they are in fact investing more time and resources to consolidate style guides in their LQA in order to ensure a clear and consistent brand voice.
Adaptation before extinction
With global brands placing more emphasis on marketing content, advertising campaigns, and customer engagement across several locales (and platforms), the challenges involved in transcreation and other more creative forms of localization are not always what they used to be for translation. However, suggesting that the established practices of LQA and LQE are already obsolete is, to say the least, premature.
For starters, even global brands still have to localize vast amounts of content that is not going to be transcreated by a marketing agency. In fact, the majority of content for any local market is not going to be used for marketing purposes. However, we can probably agree a misspelled brand name will have a more negative impact if it were to be found in a marketing brochure than in a user guide. A robust LQA process can help you catch this error before publication.
Even in the fast-paced world of transcreation, where the bonds between source and target texts are as loose as they can be, you shouldn’t have to wait for a user or a customer to report a misspelled brand name. The customer experience is already ruined by then, and it means that either your LQA process isn’t tight enough or that you don’t have one at all.
There are many constructive ways by which users can help improve a quality program, and it’s important to have open communication channels to provide their feedback to content creators. Having said that, users and customers cannot, and should not, be the only agents of quality for a localization quality program. We can’t afford to treat translation quality like a random online forum where the person asking a question about something they don’t know also gets to give 5 stars to the least correct response because “it was well-written.” Instead of ignoring quality standards and the help of advanced QA technology that is out there already, put them to use and let your customers reap the rewards.