'What does ACU mean on page 4?'
A product manual is going into fifteen languages. On the first day, the Italian translator emails the PM to ask what an abbreviation on page 4 means. An hour later the Dutch translator asks the same thing, and the Korean translator asks something slightly different about the same sentence. The PM forwards them to the client. The client's engineer answers the first email, ignores the second as a duplicate and answers the third differently.
By the end of the week, the PM has a folder of query emails, some answered, some not, and no way of knowing which translators have seen which answer.
Why queries multiply
- Each translator works alone and cannot see what others have asked.
- Queries arrive by email, often without the segment they refer to.
- The PM forwards queries one at a time, and the client answers them one at a time.
- Answers only go back to the translator who asked.
- Nothing records the answers for future jobs from the same client.
What it costs
PM time spent relaying messages. Client patience worn thin by duplicate questions, which reflects badly on your agency. Translators who never get an answer and make their own choice, producing inconsistency across languages. Delays while translators wait. And the same questions asked again on the next job, because the answers were never stored.
| Aspect | Shared query log | |
|---|---|---|
| Asking | Email to the PM | Posted against the source segment |
| Duplicates | Each forwarded | Merged or linked before reaching the client |
| Client answers | By email, per question | Once, in the portal |
| Who sees the answer | The asker | Every translator on the project |
| Future jobs | Lost | Answers kept and searchable, terms proposed |
How we build the query log
- Each project has a query log. Translators post queries from a link or, where the CAT tool supports it, directly from the segment, so the query carries the source text and context.
- New queries are compared with existing ones, and likely duplicates are shown to the translator and PM, who can link them instead of creating a new one.
- The PM reviews queries, answers what they can and sends the rest to the client in a batch through the client portal, with context attached.
- The client answers each query once. The answer is visible to every translator on the project, and they are notified.
- Answers that settle terminology are proposed for the client's termbase, and all answers are kept for future projects from that client.
- The PM sees open, answered and overdue queries, so nothing waits unnoticed and the deadline impact is visible.
Some TMS and CAT platforms already include a query feature. Where yours does, we look at configuring or extending it first.
What changes
We also give the PM a way to answer from what the agency already knows. If a previous project for the same client settled what an abbreviation means, that answer is shown alongside the new query, and the PM can reuse it with one click instead of troubling the client again. Only genuinely new questions reach the client.
The client answers each question once, which they appreciate. Translators get answers faster and see answers to questions they had not thought to ask. PMs manage a list rather than a folder of emails. Languages stay consistent because they are all working from the same answers. And the next project for the same client starts with the previous answers already available.
Clients' source authors often find the log useful too. Seeing the questions translators ask shows them where their source text is unclear, which improves the next version.
Is this your multilingual project?
- Translators email queries to the PM separately.
- Clients get the same question from several languages.
- Answers only reach the translator who asked.
- Different languages treat the same unclear sentence differently.
- Answers from previous projects cannot be found.