Mail
Pocket
I’m the linguistic lead on one of Palex’s teams. My work consists of helping the PMs to constantly deliver work that the client will be satisfied with. One of the priorities in this is to analyze the client’s feedback and know what to do with it.
My team daily works on large orders from the same client. These orders usually deal with translating into 27 languages, with a reviewer looking over our work on the client’s side for each language. I’ve heard a dozen times when our PMs were looking over the client’s email, saying something like: “Corrections. Again… Didn’t we look over everything and work as per their instruction?! Now I gotta waste time because they can’t figure out what they need.”
In the couple of years that I’ve been working at Palex, I’ve changed my perception of client feedback and now see it as a benefit—it’s only natural and very useful to see the reviewer’s comments to your work. I actually worry if a client says: “We looked everything over and have no comments.” Feedback is the only true path to a high quality translation.
When we talk about translation quality, we generally look at international standards and industry accepted dictionaries and rules. Maybe, you can’t really think about getting a good text without these guiding you, but you always have to remember that standards and rules are nothing more than a guide—it’s the minimum that you need, not everything. It’s the foundation upon which you build a quality translation from the pieces of information you receive from the client—their insight, their expertise and their wishes. Quality doesn’t mean following the norm. Quality is making your client happy.
You can learn the client’s preferences through analyzing their corrections of your work, and create a translation that suits their specific needs, not just follows industry standards.
On my team, we usually follow the rule that the most important thing about any translation is what the client thinks about it. It’s a big mistake not to pay attention to feedback or comments that you get after delivering the work.
I’m not talking about the linguistic quality of your texts. Of course you already delivered the near-perfect translation: the style, absence of typos, following the glossary and client’s guidelines—everything was thought through. But if the client still made corrections, it only means that they know their product better than you and your linguists, and that there are nuances which you couldn’t have foreseen. Paying attention to the client’s feedback is your job!
For example, in the work with the abovementioned client, our texts are checked by in-market product managers. They know best under which names their gadgets and parts that are related to them are sold. I’ve seen product managers change product name translations to something that my team didn’t think was best. But the client has already used these names on their website and in stores for several years, and it wouldn’t be best to confuse the end users, no matter what our linguist thinks of the name used by the reviewer.
A client that regularly checks your work is a great client. I don’t envy those of my colleagues who constantly get replies that read: “Got the files. Thanks!” and nothing more. Such replies rob you of the opportunity to clearly understand if the client is happy with your work or if they are looking for a replacement.
It’s really bad when the client doesn’t check your work and send you corrections. Sooner or later they are bound to review what you’ve sent them (worst-case scenario is if users complain about an app interface, for example), and you will be faced with a mountain of corrections that you could have approached gradually, had they been sent to you on a per-job basis. There could be so much work to do and so much misunderstanding, that the client may actually refuse to work with you in the future.
It’s not enough to understand the value of feedback—you need to know how to work with it. It’s normal for the PM to want to fix everything and send the work back to the client, bothering them as little as possible. But in reality, a no-questions-asked approach creates more problems for you and the client in the future.
In our team, we carefully go through every correction with the linguist that translated the text. The linguist always has the right to accept the client’s corrections or decline them. In the first case, the linguist will give a short explanation to why they made a mistake; in the second—supply arguments to why the client’s correction is wrong and what option may be more suitable. After this, we send all the comments to the reviewer and wait for their final decision.
The reviewer corrected the term from the glossary. We asked to confirm the change for this and future projects. The client asked us to use the new term and update the glossary.
All this is done with only one goal in mind—to improve the translation and not introduce any new errors. Such an approach reflects your professionalism and how you look at quality control. In an open discussion with the reviewer, you may find out that you weren’t supplied a new version of the glossary, the QA tool you work with to run automatic checks wasn’t set up properly, or your missed an email with the client’s recommendations for the translator. In any of these cases, you find out that it’s not that the client is too picky, but that you have specific issues to pay attention to in the future and which can be solved rather easily.
This communication is very valuable. It’s unlikely that any client will send you a detailed list of their requirements and preferences. The most you can count on is a glossary and a style guide, which will probably miss half of what the client is looking to see in the end. It is through feedback that we understand the client’s preferences, even if it takes several rounds of reviews. Such an approach shows that we care—we don’t want to bug the client when we ask for more information and detailed instructions, we just want to make sure we never waste their time on correcting our work again.
Communication between the reviewer and the translator is a dialogue of two equally competent people. The linguist can easily point out a mistake of the reviewer, or give their recommendation, but remember—the client always has the final word. You can point your finger at industry standards all you want, but the reviewer has their own problems and tasks, and they just want you to help solve them.
We had a job on which the translator argued with the client about the translation of the word “scanner”. The argument lasted for days, and the translator gave many reasons for her choice of terminology, referencing dictionaries and her own experience. But in the end, the main argument was the client stating that in their business, the end user always calls scanners this way, and it doesn’t matter what the dictionaries say—the client has a business and in their business scanners are called scanners, nothing else. All else is unimportant.
Receiving the same correction from the reviewer that you’ve already received on another job is one of the worse things that can happen. There’s nothing more annoying for the reviewer than repeated errors from one job to another on a similar project. This means that you don’t pay attention to the recommendations and the reviewer must waste their time correcting your work again.
When I analyze the client’s feedback I separate it into three groups:
We knew but still made a mistake. The least pleasant of the bunch is when the client had already voiced their requirements about specific term usage or style, but we continue to make mistakes in the translation. In such cases I try to go through the chain of events and figure out what happened. I check what references were sent to the translator, what instructions the linguist received, and if the QA tool was set up properly to check the work. There was obviously a glitch somewhere and it needs to be found and fixed.
Mу message to the internal QA specialist asking to figure out the reasons why we missed the error. (I’ve translated it from Russian to English).
I had a funny, but very unpleasant case once. There was a project on which the reviewer corrected our translation and requested that we always write an abbreviation using lower-case letters. We added this condition to our QA tool and the program was supposed to always alert us when the abbreviation was written with any upper-case letters. Several months have passed, and I received an email from the reviewer with nothing more than this abbreviation in the list of other corrections. I spent several hours on trying to figure out what happened, and it turned out that when I added the abbreviation to the QA tool, I used the wrong keyboard language and typed the Russian letter “с” instead of English. So the abbreviation looked correct but the tool was reading it as something completely different.
Something new. Almost every project we work on brings forth some new preferences from the client. This can be terminology preference changes, requirements regarding dates and numbers, usage of articles or capitalization.
These may affect not just one request, but all of the same client’s requests, so we have to update the glossary, set up checks in the QA tools, and make necessary corrections in the checklist.
If during the back and forth with the client we find out that something can’t be included into automatic checks, we send out a mass email to all linguists involved, letting them know that there are new requirements from the client.
Our letter to the translators team with new guidelines as a result of long discussion with the client.
Style corrections by the client. There are times when the client makes minor changes to the style of the translation, rephrasing a sentence here, changing the preposition or article there, or adding a word. These changes don’t improve the text or worsen it, so we just accept them and update the TM, so the CAT tool uses the client’s preferred translation of any specific phrase in the future.
But if there are too many stylistic changes, it should signal that the reviewer isn’t happy with the work of your linguist. If this is the case, you are unlikely to solve the issue with updating glossaries and sending recommendations to the translator—you will probably need to get another translator on the project.
We had a similar situation with our client: a translator-editor pair was chosen to work on the client’s projects, but we constantly received many corrections and the reviewer sent us negative comments on a regular basis. Our linguists argued with him, and no compromise was ever reached. We ended up forming new translator-editor pairs and sending the client several test translations, asking them to choose the style they liked. After changing the team, we stopped getting as many corrections and negative feedback—the reviewer was happy to see the translation they liked.
My daily routine includes analyzing client correction and feedback, discussing such feedback with our linguists and updating reference materials. I also prepare a report for my team once a quarter, which includes two indicators—Fail Rate and Coverage. Fail Rate demonstrates the percentage of positive reviews received from the client related to the entire volume of the translations checked by them. Coverage indicates the portion of the total volume that was checked and evaluated by the client.
The slide from my quarter presentation for the team. These 3 months were not so good with the 15% Fail Rate. But we found out the reasons for each fail job and passed the next quarter without fails at these language pairs.
Fail Rate is easy to understand—where it’s lower than a set threshold, there’s the need for us to figure out why the client is unhappy and take measures, ensuring that similar mistakes are avoided on future projects. We started to calculate Coverage because we wanted to see the translation of what language pairs the client barely checks and sends us feedback. Where this number is lower than the set threshold, we increase our interior checks and overviews, consulting with the reviewer in case we aren’t sure about some specific terminology.
