Mail
Pocket
A localization manager’s workday consists of many tasks. Often, these tasks are quite complex—a PM has to coordinate the work of hundreds of freelancers on a multilingual project and not mix anything up, find linguists for rare language pairs, translate thousands of words and perform desktop publishing for hundreds of pages per day.
Without a doubt, in such cases you spend a lot of time and energy, but here, much depends on you and your ability to make your own life easier: you can create templates, automate repetitive and routine tasks, keep control of yourself and your team by paying attention to details and planning ahead.
For me, the real problems begin when I get a new request from a client, where they send three emails, five documents with a hundred comments, a couple of screenshots and an Excel file. You surely can’t just pass on such “instructions” to the vendor, because you’ll receive a bunch of questions, answering which will take a long time, and you’ll still most likely receive the job done incorrectly.
So it’s in my interests to “translate from the client’s language”. This may take a lot of time, but it will save me from a situation when a day before the deadline I’ll understand that the instructions contradict each other and that the client didn’t actually send all the files necessary.
With such a request you won’t be able to go the usual way and send out briefs to vendors, quickly moving on to other projects. Plan your workday in such a way that you have enough time to decipher the “instructions”, and be morally prepared that this will take long. You shouldn’t rush—it’s better to spend time on a thorough analysis and rewriting the instructions, then later reply to a dozen questions like “what did you mean when you said that on page 73?” And getting questions in this case will be the best thing that could happen! Many vendors will just do things the way they understand, and you won’t even know that there was something contradictory or down right wrong in the client’s instructions. Clear instructions on such projects are half the success!
In the best case scenario, it might take you 20−30 minutes to rewrite a not too complicated instruction. If you’re lucky. But I remember the project when it took me three and a half weeks to analyse the request. We spent almost a month to clear instructions with the client, wait for the correct source files, and discuss requirements for images in the document. Only after that we could launch the project and complete it seamlessly.
I have a golden rule: I never forward the instructions from a client to linguists and engineers without taking a careful look at them first. When I open a PDF file and see ten comments on each page, I know right away that there’s much work to be done before anyone else can start doing anything. In this case, I create a separate file and break up the instructions received into blocks: I rewrite one block and rest. This way, I get some satisfaction after tackling each block.
A hundred scattered comments from the client turn into a logical chain of instructions if you rewrite them with the vendor in mind. I try to put myself in the place of the linguist or engineer and ask questions like: “Would I be comfortable working with such references? What questions would I have?” My main goal is to create instructions after reading which the vendor doesn’t feel as desperate as I did when I read the client’s initial email. The list of my major fixes is roughly the same on each project.
Rewrite instructions in a language understandable to the vendor. Usually, the clients write all the comments they have in English. However, this can present a problem in itself. PMs on the client’s end don’t always speak English well, and I have to rephrase a lot for the vendors to understand what the client is trying to say. For example, when you work every day with the client, you get used to their writting “style”, even if it’s not perfect. But someone new will surely get lost. I also work with people, for whom I need to translate the instructions into Russian.
Simplify the wording. If you don’t clearly understand what needs to be done after reading a phrase or sentence once, the instructions are faulty. Everything should be clear and unambiguous, and not raise any questions. Sometimes I get PDF files with not just a single comment, but an entire dialogue of the client’s managers. In such cases, I have to dive into the “conversation” and figure out what exactly was the end-result and to what everyone agreed.
Remove excess. It often happens that a document or email says the same thing in three different places, three different ways. In this case, I process duplicate information into one simple instruction. Additionally, I try to minimize the number of comments in general.
| Original client’s instruction | Instruction with my fixes |
|---|---|
| Kindly refer to ENG screenshot and change other length to 70 x 41. | Please change “65 mm x 32 mm” to “70 mm x 41 mm” in all target languages. Please refer to the English screenshot. |
| Add this. | Please add “approximately”. Refer to the translation in the next line. |
| The following text which is included in the manual was previously translated into European languages for the other project. So you will not have to translate the text this time. | Please insert this sentence from project 2347, page 39. |
| Count up from the previous version. | Change “Version 1” to “Version 2”. |
If based on the instructions you receive you need to replace screenshots, add images, insert tables, or check something in accordance with some special checklist, you need to make sure that all of these files were actually sent to you. Sometimes I have to work very hard to find all of the documents in question, because the client sends one in an archive, the other is included into the main document, and the 68-page table “isn’t ready yet”, being available to download via a file sharing service on the third Friday after Christmas.
In this case, the approach is simple: if any additional files are mentioned in the instructions, the client needs to send them to you or give you a link where you can download them. Additionally, the contents of these files have to correspond to what the instructions say. If you are being asked to insert a table from a document that doesn’t have a table, you need to clarify what happened: is it a wrong file or a misleading instruction.
Another important point: you can always simplify the work with such references so the vendors can do their job faster. For example, you can copy the text from the Excel file directly into the PDF comments, or download a screenshot from the client’s portal and attach it to the main document.
“Want something done right, do it yourself,” is a great statement, but it can’t be always applied to reality. Not on every project can I fully sift through the client’s instructions by myself, and if there’s a person on my team who can definitely do something faster and better than me, I delegate a part of the job to them. For example, a linguist can help me with terminology, a DTP specialist — with fonts, a localization engineer — with any special requirements for a video voice-over.
If neither you nor your colleagues were able to figure out what the client wants you to do, you should prepare a list of concise questions.
I usually start such a list from the first minutes of my analysis of the client’s instructions. I split my workstation into two screens, opening a document with the comments on one, and a query sheet on the other. I look through each comment and when I have a question, I add it to the query sheet right away, so that I don’t forget about it. It happens that by the time I’m done going through the instructions, I find the answers to some of my questions. But it only takes a few seconds to delete a question that I no longer need answered. It’s much more difficult and lengthy to remember all of the questions I had when reading the instructions.
«elow, I jotted down a few examples of such questions. They may seem silly at first, but my experience tells me that it’s better to ask a silly question before you launch a project, then to redo something that you thought was right, but in fact, misunderstood.
My message to the client with questions. This request contained many files. With most of them there were no issues and I sent them to the engineers. But I noticed problems with some documents and instructions and had to ask the client to clarify what we should do.
I try not to start the project before receiving the answers to my questions from the client. This helps me to avoid confusing the project team and/or redoing something that was already done based on a false assumption.
As soon as I receive the answers, I simplify them much like the rest of the instructions and make them clear for everyone who will be working on the project. Finally, I can brief the project team and be sure that they will understand everything correctly.
