This site is protected by reCAPTCHA. Pressing REGISTER/SUBMIT button you agree with our Privacy Policy and Terms of Service.
Submit
Provide links
Get a quote
Rapid and reliable localization services for your goals into 80+ languages
Translation correction by client: why it is good and what to do the feedback
June 20, 2019
Linguistic Lead
Olga Simonova
Reading time is 7 minutes
We will send you the material to:
By clicking the Subscribe button you agree to our Privacy Policy terms
Why it is good and what to do with the feedback
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.
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.
share
Value your client's feedback
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.
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.
Deal with the corrections right away
and ask questions
and ask questions
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.
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.
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.
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.
Make sure that the reviewer's corrections are never repeated
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:
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.
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.
When I analyze the client's feedback I separate it into three groups:
- We knew about this requirement and still made a mistake.
- We've never seen this requirement before—it's a new direction from the client.
- The client made small stylistic and preferential corrections.
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.
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.
Monitor how much of your work the client checks and how happy they are with the result
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.
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.
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.
Memo: How to benefit from client reviews
- Don't look at client feedback and comments as something negative. This is a great way to figure out exactly what your client is looking for, and win their trust and loyalty by considering even the most minute of their wishes.
- Analyze feedback right away, ask questions and decline erroneous corrections. Keep an open dialogue with the reviewer and carefully listen to their explanations of the changes made.
- Do everything you can to avoid repeating mistakes that were already pointed out by the client. Create glossaries and style guides, and set up automatic QA tools.
- Follow how satisfied the client is on a constant basis. Regularly analyze the full picture of your work review.
Stay Tuned
By clicking the Subscribe button you agree to our Privacy Policy terms
Related articles
Linguistic Lead
Kamil Mustafin
Reading time is 7 minutes
June 13, 2019
Translation review: how to avoid miscommunication between translators and reviewers
Reading time is 7 minutes
May 30, 2019
Group Leader
Alexander Barabash
Linguistic Assistant Group Lead
Milena Miyayeva
Reading time is 7 minutes
June 7, 2019
Interesting?
Then let's get in touch
Then let's get in touch
Interesting?
get in touch
get in touch
Industries
Industries
Company
Company
Life sciences
TMS
TMS
MT
MT
Partnership
© All rights reserved
Social media
Call us
Write to us
sales@palexgroup.com
Call us
Write to us
sales@palexgroup.com
© All rights reserved
Social media