How to deal with questions during a translation project - Translators Family
single,single-post,postid-352965,single-format-standard,eltd-cpt-1.0,ajax_fade,page_not_loaded,, vertical_menu_with_scroll,smooth_scroll,blog_installed,wpb-js-composer js-comp-ver-,vc_responsive

How to deal with questions during a translation project


It is never easy to ask questions. As professionals, we might fear that people reading our questions think we should have known, or found, the answer ourselves. Many of us have also experienced translation project managers (TPMs) or clients ignoring the questions we asked, or at least not paying attention to all of them. It also takes time to write questions, check the answers, discuss some of the options and/or implement any subsequent changes.

Clients are sometimes swamped with work, do not have time to reply to questions, are not able to provide answers themselves or simply underestimate the value of this exchange process.

When translation projects go through translation agencies, project managers are sometimes completely inundated by the mountain of jobs they have to oversee simultaneously and could get annoyed by a high number of questions to sort out. They might overlook some or simply not invest enough time in dealing with them or even not relay them to the various project stakeholders.

In the article below, I explain what I believe are some best practices when dealing with questions, not only as a project participant (translator, reviser, DTP expert, tester, etc.), but as a project manager and client too. These are mainly based on what we do in our company and might not all apply to your own case.

Dealing with questions as a project participant

When the client or the translation agency provides you with a question template, always use it properly and follow the rules. For instance, you might be requested to include the entry date in a specific format, like DD/MM/YY, or to insert the file name next to each question.

These templates, whether online or offline (an MS Excel sheet for instance), usually contain lines or cells where you can put your questions. Make sure you only enter one question per line/cell. Grouping two questions in a single line/cell can confuse the client, who might only answer one of them.

If the query file is shared among all the project participants, examine it first before asking questions that may have been raised already. You will gain time and save the client and the project manager the trouble of having to deal with the same question twice (or more ;-)), which they might not appreciate.

On the other hand, regroup several questions under a single topic when they can be generalised. For instance, avoid creating an entry for every single product name asking if they should be translated, but instead ask: “Can you confirm that product names remain in English but we should translate ‘for’ before ‘Windows’ and ‘Mac’ in occurrences like ‘COMPANY PRODUCT for Windows’?”

If the project is multilingual, unless otherwise specified, write your questions in the main communication language. For instance, since most of our projects involve a dozen languages, people usually write their questions in English, which makes it easier to share them among the teams. Our clients are also mainly based in English-speaking countries so we can easily transfer questions to them that are already written in their language. Nonetheless, as French-speakers, we would accept questions in French for a French-only project, provided that the client speaks the language. Reversely, we would not be able to do the same for Japanese since no PM here masters it.

Questions should also be adapted to the recipient’s language level. If the end client is a non-native speaker, it might be preferable to phrase the questions with easy wording to be 100% sure that they grasp the meaning immediately and answer quickly. People might indeed get frustrated if they need to invest time trying to understand questions written in a high level of a language they do not master. Conversely, if the client is particularly sensitive to your way of writing, it might be equally important to polish your communication style.

Questions should, of course, be complete and explicit so the client can give a prompt answer. Sending only closed questions that can be answered with either “Yes” or “No” is probably the best option. Proposing your own solution gains your client time, and they will eagerly confirm immediately rather than postpone (or forget) to write down long explanations. For example, in case of doubt about the meaning of a term, do not ask “What does ‘user network’ mean?”, but make your own interpretation clear: “Can you confirm that in this specific context, ‘user network’ means ‘a network of users’?”. Avoid suggesting two options for the same question, for example “Does ‘user network’ mean ‘a network of users’ or ‘the network of a user’?”. When reading too quickly, some clients might simply answer “Yes”, which will then force you to guess what the correct option is or request clarification.

If a language reviewer is answering your questions, you can directly suggest translations for problematic terms. But if, on the contrary, someone speaking only the source language is answering them, add an explanation describing what you understand or propose in this language.

Always add context with your questions, even if it is not planned in the template. Do not hesitate to insert the full paragraph or even more (like a screen capture) when you feel this will help your client grasp the point immediately. Clients usually have no time to open the source files to look for context. It is handier for them to visualise it next to your question or translation proposal. Note, by the way, that when you copy context directly from tagged files, internal tags or code displaying within the query file might confuse the client. In this case, remove those and format the copied content correctly. For example, do not leave the context like this:

Assuming that the word “<strong>Quotation</strong>” is inserted in cell <strong>A1</strong>, the result appearing in cell&nbsp;<strong>E27</strong>, in the <strong>Price/task</strong> column, corresponds to the formula “<strong>=B27*D27</strong>”.

but clean it up as follows:

Assuming that the word “Quotation” is inserted in cell A1, the result appearing in cell E27, in the Price/task column, corresponds to the formula “=B27*D27“.

You can join comments as well, for instance to explain why you chose one option or another; or where you found specific information. Obviously, verify that your comments are crystal clear and make sense to the reader.

Before sending your questions, review them, imagining that you are the one receiving them, potentially not having any translation background and/or not mastering the source language and the subject 100%. Ask yourself if you could answer them easily and quickly, and if so, send them on! 😉

Dealing with questions as a translation project manager

Most of the advice covered in the previous section applies to translation project managers. As the middlemen, they should follow a few more principles. Indeed, one of the TPM’s roles is to ease communication. Sorting questions, informing translators about the end client’s profile and efficiently managing both the project team and the client’s inputs will certainly increase their chances of achieving a successful project.

If your end client does not provide you with a question template, use your translation agency’s or create a brand new one yourself. You should tell your subcontractors the kind of information to provide with their questions and the presentation to follow. If not, you might end up spending hours extracting data presented in various formats. Typical fields would be “Date”, “File name”, “Source term”, “Target term”, “Context”, “Comments”, “Client’s answer” but, depending on your projects, you could of course add some more.

When teams send you questions, read each one carefully before sending them to your client. Make sure all questions are 100% clear and understandable. If you do not understand some wording, the client might be puzzled too. In these cases, do not hesitate to rewrite problematic questions yourself or ask the team/freelancer to do it. On some occasions, you might even have to soften the tone used for questions. Some people are very straightforward and use imperative forms such as “Confirm this term”. Make this a bit politer by saying: “Can you please confirm this term is correct?”

Additionally, double-check that all the appropriate fields/cells are correctly filled in and fix or complete the missing data yourself, for instance include context or correct the referenced filenames.

While going through the questions, try to answer some yourself instead of sending them all directly to the client. Project managers gain experience from one job to the other and after managing several projects in the same sector or for the same client, you might already know a lot about the subject and be able to assist your team. Alternatively, you can turn to your colleagues or company staff (linguists or members of the technical team) in case they can provide you with more information. On multilingual projects, it could make sense to first send the question file to all the teams, asking if anyone can share explanations that could be helpful to others.

Providing the schedule allows, avoid sending questions every day, or worse multiple times a day. Instead, gather them together and send them in batches, once or twice a week or even once or twice a month for very long projects.

Of course, delete any duplicates before sending the question file to your client. Similarly, make certain that some of those “new” questions have not already been clarified in previous batches or even during an earlier project. Remember, the fewer questions the client receives, the more chances you’ll have of obtaining answers… So why not create a reference folder for each client containing all the questions that have previously been solved?

Depending on the client’s profile, it might be worthwhile separating questions related to content from questions related to language. For instance, the job coordinator at the client’s might decide to transfer queries on product features to engineers able to supply detailed technical explanations and send the proposed translated terms in Korean to their local manager in Seoul and the Dutch ones to the sales team in Amsterdam. Receiving three different files will definitely make this contact person’s work easier.

Once the client has dealt with the questions and sent the answers back, check meticulously that they are all clear and none are missing. Clarify any issue with the client first instead of sending the file to several teams who will then face the same problems. In the event of an emergency or time differences, you could decide to ask your teams to confirm that everything has been properly addressed first, as they might be better experts in the field than you are. To avoid involving several teams in what might turn out to be a waste of time, you could instead ask for one team’s opinion.

As the hub of the project team, the TPM should judge if the answers have to be communicated only to the askers or if they might be useful for everyone working on the project. For instance, getting confirmation that the client’s Italian validator prefers “firma” instead of “signature” for the English term “signature” will only be useful to the Italian team. Whereas if the German team wanted to know whether proper names appearing in examples needed to be localised (for instance replacing “John Smith” with “Max Meier” in the target text), the client’s answer will be valuable to all the project’s teams. Unless otherwise instructed, all the linguistic teams working on the translation project should definitely be notified of these decisions.

Supposing that a participant disagrees with some of the client’s answers, verify that their comments are written in a nice and respectful way. Whenever needed, rewrite them yourself so as not to offend the client. Obviously, check that the justification for the rejection is correct and well-argued and will result in the client either confirming the initial choice or validating your team’s comment.

To be on the safe side, before delivering the final files to the client, you could perhaps double-check that all teams have properly implemented the answers the client has provided across the whole project.

Finally, let’s point out that for some projects, when time allows, it could be extremely beneficial if the TPM took some time to browse the source text to spot any potential issues and already solve those with the client. This would allow them to either complete the instructions or communicate already solved issues when launching the project into production.

Dealing with questions as a client

Depending on the reason why they order translation jobs, end clients might perfectly master both the content and the requested target language, or be an expert in the field while speaking only the source language, or be fluent in the target language and not have a clue about the translated subject or simply have to request a translation in a language they cannot read for a domain they have never dealt with before. Whatever the case, clients have to be conscious that translation teams sometimes need extra information or validation of their choices to deliver quality work. It is, therefore, of the utmost importance to spend time handling questions properly.

Clients should read all the questions attentively to make sure they fully understand the requestor’s needs. Do not hesitate to point out any ambiguity in the questions to the project manager or to the translator/reviser since trying to guess the meaning of a question might lead to foolish answers that could lower the quality of the final target text. You might also be surprised to see that questions occasionally reveal errors or inconsistencies in the source files, and consequently help you to improve them.

If you cannot solve some specific points, pass them on to people who have the required skills and ensure a proper follow-up if they take a long time to respond. Whenever possible, instead of simply transferring the answers to the translation agency or translator, carefully inspect each one to ensure they are all meaningful and none was left out.

If you consider that the number of questions is too high or that some are not really justified, do not hesitate to point this out to the translation team or TPM. The latter should indeed realise that searching for information is certainly part of their job. If reference materials exist and are easily available to everyone, they should refrain from sending the client every single question that might cross their mind.

On the other hand, when appropriate, provide additional data when answering certain questions. For instance, if someone wonders whether people’s titles in your company should be translated or not and your answer is positive, try to find the list of the local job titles in use and distribute it to the translation team. It is far too dangerous to let people make assumptions. Translators are professionals, possibly specialised in some sectors, but by no mean wizards able to guess some internal terminology or undisclosed data.

Dealing with questions is time-consuming. It can be frustrating. And at times, you might even consider that it is not worth the extra effort. Nevertheless, asking the right questions, transferring them to a qualified person, answering willingly, and making sure all people involved get the relevant answers can sometimes be crucial for a good end result.

As with everything, professionalism and moderation always prove to be a good recipe every step of the way, so that everyone gets the right information, without wasting too much time and can meet the expected quality level.

Follow Us On

Facebook twitter Google Plus Linkedin Pinterest RSS feed
1 Comment
  • Very insightful article from the different perspectives. I couldn’t agree more about sending questions in batches. I really like the tip about phrasing questions as closed-ended to save time. Thank you for the insights!

    December 14, 2016

Leave a Comment

Your email address will not be published.