Mail
Pocket
I’m the linguistic lead on a team that specializes in IT and tech projects. My main responsibility is linguistic quality control—I make sure that the translations performed by our company fall in line with what our clients are expecting. If something goes wrong and the client isn’t happy, the project manager and I work on figuring out what happened and fixing the issue.
We have several clients that send us similar requests on a weekly basis. Naturally, a team of two-three translators that regularly work on such requests is formed. These translators work in the schedule we need, have the rates we can afford and translate the texts in such a way that makes the client happy. We’ve been working with them for quite some time and are sure that the translation will be of good quality and done on time.
This seems to be an ideal picture—what is there to do for a PM but send out a couple of emails? But sooner or later I receive a message from one of our managers that reads something like: “Maria is on vacation as of today, John is out for a couple of days for his daughter’s wedding, and I have a job that’s due in five hours! And it has detailed instructions that will take an hour to read through. What do I do?!”
Such a message means that our team overlooked preparing backup linguists for this specific project type, and no one deals with this client except for the two people mentioned. In this case, we have to start looking for a translator based on resumes and general test results in our database, which means that we have no idea what the end result of the job will be. So we send out the texts to be translated to the new person and hope for the best. Most likely, we will either not deliver on time, the freelancer will be confused by the instructions and will make a bunch of mistakes, or the client won’t like the new style of writing. The best we can hope for is that we don’t have to provide a discount for a job done poorly.
I try to curate the managers in our team and tell them how to not get fixated on “comfortable” people and constantly operate with new freelancers as not to risk failure on a job.
Even if you are sure that only one translator-editor team can do a good job on your project, most likely, there is a dozen of potentially appropriate linguists in your database.
It’s quite understandable when you don’t want to work with new people, having tested and successfully worked with old ones—no one wants to do extra work contacting and testing new freelancers. But you will have to do this sooner or later, because people go on vacations, get sick, have children, etc. And it’s best to prepare for such events when you are not panicking because you need to translate something in a couple of hours and you don’t have anyone to do it. You’ll have to spend a week writing an RCA afterwards, on top of that.
What you need to have is an expanded resource database, where you clearly understand who can work on the project with their eyes closed and whom you know of only from their resume. In our company, we use the following statuses for freelancers: main, backup, candidate.
Of course, a candidate is not just any random freelancer. This person has already completed and passed a test, and currently works in the subject area of the project and with the necessary CAT tool. This information is clearly understood at the time we begin to cooperate with the contractor. After our cooperation begins, if something doesn’t fall in line with reality, or there are additional recommendations, we add an appropriate comment to the database.
| Project type | Vendor | Main | Backup | Candidate | Comment | |
|---|---|---|---|---|---|---|
| Consumer electronics: mobile apps | John Jensen | Translating | Check a translation quality by Kevin | |||
| Kevin Williams | Editing, LQA | |||||
| Robert Brown | Translating | |||||
| Maria Johnson | Translating | Cheaper than Robert. Test if can be our main translator | ||||
| Elizabeth Hill | Editing | Never worked with. Be sure to perform an LQA before delivery |
If you already have backup linguists, try to work with them on a regular basis, even if your main translators are available. This way you’ll have current information on their schedules, prices and quality of work delivered.
How often you’ll work with them depends on the project type. It’s not necessary to work with a backup linguist often if that person is busy on other company projects of a similar type—you’ll always have current information in your system. On the contrary, if the projects you’d like to work with the freelancer on are very specific and have a ton of requirements, be sure to engage the linguist on a constant basis, so they don’t forget instructions.
If there are no backups available at this time, the managers need to test new linguists on every appropriate project.
If a freelancer is a potential fit for the job, it doesn’t guarantee that they’ll be a fit in reality. Anything can go wrong: they may do a bad job translating, will not deliver on time, or won’t reply to your emails.
I have experience when a freelancer delivered the job several hours after the deadline without notifying the PM ahead of time. The files delivered had several untranslated segments, and the translator didn’t follow the glossary. As a result, we had to give the job to another linguist, paying them a higher rate for the urgent request; we delivered past the deadline; and the client was unhappy.
You should do everything to avoid such situations. No matter what issues may arise with your candidates, you should always deliver a good quality job to the client on time. So it’s very important to know how to choose the first project for a new freelancer.
I suggest you start with smaller jobs of under 1000 words. With a small job, if the quality is very poor, you’ll have time to redo the work completely or give an editor enough to correct all the mistakes. If the translator doesn’t deliver the project on time, it’ll be easier to find someone else to complete an urgent job on a smaller project than on a larger one. But don’t start with very small jobs of up to 100 words—you won’t be able to judge the quality of work on such a translation and may get a false sense of the freelancers work ethics, thinking that they do good work on time.
If some projects always come with several thousand words to translate, divide them between your main contractor and the candidate, giving the latter the optimal volume of under 1000 words.
If you are starting to work with a new person, their work will need to be edited and evaluated. To do so, you will need the help of the linguist who has worked on the project extensively: they will be familiar with the specific requirements, know the client’s preferences and understand the product. They also must be ready to get the translation up to the acceptable quality, no matter what kind of a translation they received from the candidate.
The perfect option is to complete the LQA step using a special form that calculates the translation quality rate. Such an evaluation definitely requires a budget, but it’s worth it, because it’s objective and more reliable.
If you don’t have the budget, ask for the opinion of the editor who worked post-translation. Just because the editor didn’t have any complaints doesn’t mean that everything was perfect. Some people are too shy to complaint, others are just too lazy. You need to clearly ask for their opinion.
Possibly, everything will go well and you will only need to spend some time on the evaluation of the candidate’s work. But you need to be prepared for the worst-case scenario, which is when you either don’t get the translation at all, or get one of poor quality, having to redo everything. Those projects on which you are testing new people need to have at least double the time allowance when compared to the projects on which you work with tested and reliable freelancers.
It’s possible, if not likely, that something went wrong—the translator didn’t check their work in a QA tool, used the wrong segment statuses, and worked in a style that is pretty bad, according to the editor. All you want to do is forget this horrible experience with constant edits and redos, the unhappy editor, and waste of time and money.
For all of this not to be in vain, you should give the candidate a chance to get better. Tell them the mistakes they made and what you are expecting on the following jobs. Not everyone does their best job the first time around. Remember, if you have regular projects that are similar, it’s very possible to train a decent freelancer.
Linguists that you have no information about are usually the most problematic. For example, you may have work with a linguist who disappeared or didn’t turn in their work at all. You got angry and swore never to work with them again, but didn’t tell anyone about this. Another PM may encounter the same problem and you don’t know how grave the consequences may be.
On the other hand, if you recorded the issues you had with the linguist, such as misspellings, grammar mistakes, or punctuation errors, your colleagues will set aside enough time for a good editor to work post-translation, if they see fit.
This is why our company has a rule: when you get new information about the freelancer, share it and make sure that your colleagues have easy access to it, clearly understanding what to expect, and not wasting time for re-testing a new candidate.
For example, after working with a freelancer on several projects, a PM may change their status in the resource database. You can see how the roles have changed in the list below:
| Project type | Vendor | Main | Backup | Candidate | Reject | Comments |
|---|---|---|---|---|---|---|
| Consumer electronics: mobile apps | John Jensen | Translating | Problems with formal quality. Make sure to QA | |||
| Kevin Williams | Editing, LQA | |||||
| Robert Brown | Translating | |||||
| Maria Johnson | Translating | Almost no complaints. Moved to the main translator role | ||||
| Elizabeth Hill | Translation, editing | Translates word-for-word. Do not use |
