How to Manage Translator Questions with a Query Log

A translator query log is a shared decision record for questions that cannot be resolved safely from the source package. Each row identifies the exact source location, explains the ambiguity and its consequence, proposes an action where possible, names an owner and deadline, and records the final answer and every affected location.

Its purpose is not to collect messages. It prevents four expensive failures: guessing, asking the same question repeatedly, losing an answer in email, and fixing one occurrence while leaving the same issue elsewhere.

The American Translators Association's guidance on questions during a translation project recommends a shared query file, checking whether a question has already been asked, and resolving outstanding questions before delivery. The XLIFF standard provides the same underlying data model in structured translation workflows: source and target units can carry contextual information and notes, including instructions and translator comments. See the XLIFF 1.2 specification.

Ask only when the answer can change the translation

A query belongs in the log when a reasonable translator cannot resolve it from the approved sources and the answer changes meaning, terminology, scope, layout, or acceptance.

Good query triggers include:

• a sentence with two plausible referents;
• an apparent source error whose correction would change meaning;
• an undefined acronym or project-specific term;
• conflicting names or numbers in two source locations;
• a missing figure, table, note, or referenced attachment;
• unclear translatability of code, product names, citations, or quotations;
• a layout constraint that makes the requested target impossible; and
• a decision that must apply to repeated occurrences.

Do not use the log for questions the translator should answer through ordinary research, the supplied glossary, style guide, nearby context, or established target-language convention. A log full of “please confirm” requests transfers normal translation work back to the client and hides the consequential questions.

Use a minimum complete schema

The crucial separation is between answered, implemented, and verified. A client response does not prove every affected passage changed, and an edit does not prove the final export contains it.

Write a query that can be answered in one pass

Use this structure:

Location: Chapter 4, paragraph 18, sentence 2

Source: “Mara told Elena that she would lead the delegation.”

Question: Does she refer to Mara or Elena? The target language requires the referent to be explicit.

Evidence checked: The preceding two paragraphs identify both women but do not assign the delegation role.

Proposed action: Use Mara unless the author confirms Elena.

Impact: The same delegation leader is referenced in chapters 6 and 9. Needed by: Before chapter 4 approval.

This is better than “Who does she refer to?” because it gives the owner the source, the consequence, the research already done, the proposed default, and the downstream impact.

One row should ask one decision. If a paragraph contains an ambiguous pronoun, a wrong date, and an undefined acronym, create separate queries so each can have a different owner and status.

Triage by consequence, not curiosity

Use three practical levels.

Blocker

The affected translation cannot proceed safely, or continuing would create expensive rework. Examples include missing source content, unresolved safety language, contradictory quantities, or an unidentified entity central to a chapter.

Major

Work can continue with a documented provisional assumption, but the answer is required before delivery. Examples include recurring terminology, a character relationship, or a publication-wide formatting rule.

Minor

The decision affects a local preference or low-impact passage and can be batched. Examples include capitalization of a one-off label when both options remain understandable.

Severity is not the same as urgency. A major terminology decision needed in three hours can deserve action before a blocker in an appendix that will not be translated until next week. Record both impact and needed-by date.

Assign the decision to the right owner

Do not send every question to the author. A subject expert may resolve the concept, a target editor may own the wording, and a production owner may own whether an image can be replaced.

Keep one source of truth

Choose one canonical log. Chat and email can notify people, but their answers must be copied into the canonical row with source and date.

For each new query:

1. Search the log for the term, entity, source excerpt, and category.
2. Link related questions rather than creating silent duplicates.
3. Use a stable source location and version.
4. Assign one decision owner.
5. Record the answer in full.
6. Find every affected target occurrence.
7. Mark the row implemented only after those edits are made.
8. Verify the final deliverable and close the row.

XLIFF's <note> element can carry instructions or translator comments and its context structures can attach information to translation units. Whether your project uses XLIFF, a spreadsheet, or an issue tracker, retain that unit-level traceability.

Turn answers into reusable project controls

An answer should update more than one row when the decision is reusable.

• Add an approved name or term to the terminology register.
• Add an authorial voice decision to the style guide.
• Add a do-not-translate rule to the source package.
• Add a known source error to the change log.
• Add rejected variants to the QA search list.
• Add missing-context guidance to the next translation batch.

This is the information-gain loop: each resolved question makes later translation and review more reliable. A query system that closes tickets without updating the working resources guarantees repeat questions.

Handle source errors without silently rewriting them

When the source appears wrong, distinguish observation from decision.

Bad row:

Fixed the date from 2019 to 2020.

Better row:

Source says 2019 here and 2020 in the timeline and cited report. Which year is authoritative? Proposed action: retain 2019 until the source owner approves a correction. Impact: body paragraph, timeline, caption, and index entry.

The translator can identify evidence and recommend a correction, but should not silently alter a factual source. If the owner approves a change, record whether the source itself will be corrected and which target editions inherit it.

Use provisional assumptions deliberately

When work must continue before an answer arrives:

• label the choice provisional;
• record why it is the lowest-risk option;
• add an exact search token or segment list;
• identify the last safe date to change it;
• prevent release while a blocker remains open; and
• replace the provisional note with the final answer rather than leaving both as competing instructions.

Never present silence as approval. A deadline can trigger escalation or a declared default only if the project brief gave that rule in advance.

Review the query log as project data

At the end of a milestone, calculate process signals rather than vanity counts:

• open blockers and majors;
• age of unanswered queries;
• questions missing an owner or needed-by date;
• duplicate questions;
• answered rows not yet implemented;
• implemented rows not yet verified;
• recurring categories and source locations; and
• source, glossary, or brief improvements created from answers.

A large query count does not automatically mean poor translation. It can indicate a difficult source or a translator who is refusing to guess. The useful question is whether queries are specific, consequential, resolved once, and propagated correctly.

Query-log release checklist

Before delivery, confirm that:

• every row identifies the exact source version and location;
• blocker and major queries have authoritative answers;
• provisional assumptions are either approved or removed;
• final answers name the decision, not only “yes” or “approved”;
• repeated terms and entities were updated across all affected locations;
• reusable decisions reached the glossary, style guide, and QA rules;
• answered, implemented, and verified are distinct states;
• the final exported file was checked after implementation; and
• withdrawn or unresolved rows retain an explanation.

Start the project with the book source-preflight workflow so the source version, glossary, assets, and acceptance criteria are clear before questions multiply. BookTranslator can generate a complete translated draft from supported book and document files; use the query log to capture decisions that source context and automation cannot resolve safely, then apply those answers consistently during human review.