Mail
Pocket
Translation review is a regular practice at Palex. Every I receive dozens of feedbacks from clients. This is normal and can be very useful. It helps us understand what our clients are looking for and customize translation workflows to fit those needs. We strive to have nothing that the client can complain about. Not even the smallest thing.
This seems to be a simple formula: the client doesn’t like something — we fix it and learn from our mistakes — the client is happy and never corrects any of our work again. But sometimes the feedback handling can turn into a nightmare with translators and client’s reviewers not being able to find the common ground, constantly doing the same work without getting anywhere. Formally, there’s cooperation, but this cooperation doesn’t bear fruit: the translation doesn’t improve, the client doesn’t get what they want, and both sides spend a lot of time and energy on pointless actions, as a result, being disappointed in one another. The worst-case scenario of this is losing a client.
I’m the linguistic lead in our company. I’ve analyzed hundreds of clients’ complaints and spent hours explaining why we can’t change the translation of one or another term. And after these hours, I still received requests to change it to what the client wanted. A normal reaction to this would be to give up and do what the client asks, but it’s important to understand that it’s not about an incompetent reviewer or freelancer, rather about the lack of communication between the freelancer and the client due to the endless number of intermediaries involved. It’s easy to imagine the client’s reviewer think: “How long could this last? I’ve been correcting the same thing over and over for a year! Isn’t it time to understand how this should be translated?” Well, it’s in your power to change this situation.
This is where everything should begin. When a PM receives the client’s corrections, their first reaction is to apologize and ask the translator on the project to fix everything quickly. But if you don’t stop and analyze such corrections, you will never know what the client is looking for. Additionally, the client may actually introduce errors into the translation, since reviewers aren’t always native speakers of the language in question, neither are they usually linguists. If you blindly accept all the changes suggested by the client, you can actually make the translation worse. It’s important to talk about incorrect suggestions and clarify anything that may be ambiguous.
The client is asking to correct a term across the entire document. Our linguist explains that such correction will create a lot of work that won’t actually improve the text. In fact, the term used by us works better in this specific context.
A simple analysis and commenting on errors may not be enough. Make sure to record repeated corrections—if they are justified, then the fault is on you, because you didn’t do anything to make sure the client-preferred terminology and wording are being used in future projects. On the other hand, if the corrections are wrong and you’ve explained your choice several times before, you should wonder if the reviewer is reading your comments at all. In this case, it’s time to take measures and contact someone who can help clarify the issue on the client’s side.
| This is bad: you won’t get anywhere and may insult the client | This is good: you’re most likely to receive a clear reply from the client |
|---|---|
| The dictionary is pretty clear that this option is wrong. | The dictionary suggests that we use a different option. Here’s a link to the relevant page. |
| This is gibberish. No one talks like this. | This looks strange to a native speaker. Could you explain what the issue is and we’ll provide another alternative? |
| You yourself asked us to translate this term this way and now you are correcting us! | The project glossary uses another translation for this term. Please see file Glossary.xls. Could you confirm that we definitely need to change this? |
Our report for the reviewer. The errors are sorted into blocks. There are arguments and links to the necessary files or other sources. It’s easy to quickly find the necessary fragment in the files or read credible sources that prove your choice.
There are at least two facilitators between the linguist and the reviewer—the PMs on the side of the LSP and the client. If at least one of them thinks that your comments are not important, all of your work on providing the arguments was in vain.
Start with the PM on your side, the one you work with on the project. I’ve seen it a hundred times when a PM chooses not to overload the client with my “unnecessary” comments and doesn’t pass them to the client or summarizes them in their own words at most. Your PMs willingness to accommodate with the client’s expectations in the most quick and unobtrusive manner is understandable. But your goal is to make sure that everyone understands how important it is for the reviewer to go through the linguist’s comments.
Help your PM understand that if they don’t send the detailed report to the client, this will not save them time. Actually, this will create even more work in the future possibly making the client even more upset. Work with your PM closely. If both of you act as one team this will ensure that all crucial information reaches the client’s reviewer, making it possible to boost the quality of the projects involved.
Such motivation will drive your PM to convince the PM on the client’s side that it’s important to discuss all questionable corrections with the reviewer. If necessary, I help write an email that supports this argument, making it clear to the client’s PM that we aren’t arguing with the reviewer just because, but in order to avoid unnecessary iterations in future projects, saving everyone time.
Written communication with the reviewer via PMs isn’t always as effective as you may wish: it takes time from everyone’s schedule and the information might not get through as you intended. Sometimes, you may not get the reply in time to make the correct decision. For example, the PM of one of our clients is located in UK, while the reviewer is in Tokyo. Obviously, we’ve had situations when we sent questions for the reviewer to the PM and before he could get to them, the workday in Japan was over, so the reviewer didn’t get them on the same day. So we had to wait for answers to simple questions for two days.
If you clearly see that communicating through intermediaries isn’t doing you and the client any good, it’s time to connect with the reviewer directly. Yes, not every client will share their reviewer’s contact information, but don’t be afraid to ask. It’s possible that their PM will happily arrange your communication with the reviewer, ridding them of the hassle and waste of time that are involved in managing your collaboration.
We were successful many times in convincing the client’s PM to connect us directly with the person that reviewed our work. As a result, we saved our and the client’s time and gave the linguist a real opportunity to go through the nuances that caused the argument in the first place. After such discussions, we clearly understood how to translate the text the next time around, so the reviewer would be happy. They, on the other hand, were able to accept our arguments in some cases not to correct certain terms or sentence structures, introducing mistakes instead of making the text better.
Make sure to discuss with the reviewer how you will communicate in the future. Any means will do. We use messengers, emails or phone calls, for example. Sometimes, we organize a conference call, inviting all the linguists that work on the project for the specific client. This way, recommendations and instructions from the reviewer are sure to get to everyone, and everyone is sure to have a chance to ask direct questions. If there are many participants, or you’re expecting a heated discussion, it’s best to set a moderator—the project PM would do perfectly, for example.
We accepted the reviewer’s preferential correction, but later found out that our version is used in other texts about the product. I immediately wrote about this to the reviewer and he confirmed that we needed to return to the previous translation.
When you get the chance to communicate directly with the reviewer, don’t just discuss specific corrections on the project, but talk about an algorithm of working on their objections in general.
For example, one client gave us the go ahead to leave everything that concerns the style and grammar as we see fit, since the reviewer wasn’t native and could easily introduce errors. On the other hand, any doubts about terminology needed to be discussed with the reviewer, who had the last word on what terms to use.
If you can agree on at least three main directions, you will save each other a lot of time in the future.
Now that you’ve agreed on the course of action with the reviewer and heard all of their concerns, it’s important to follow through on your agreement in the future projects. It would be strange if you spent a bunch of time discussing a term and then translated it in a way other than agreed upon. In our company, all of the issues resolved turn into updated glossaries, style guides and instructions, and all of the freelancers on the project always know what was agreed upon with the reviewer.
For one of our clients, we have a dedicated glossary to store and add all reviewer’s preferences. For each term, the project number is indicated, which helps us find previous client comments quickly when the reviewer changes the translation
