如何通过查询日志管理翻译疑问

翻译查询日志（Translator Query Log）是一份共享的决策记录，用于记录无法通过原始翻译包安全解决的问题。每一行都标明了准确的原文位置，解释了歧义及其后果，在可能的情况下提出处理建议，指派负责人和截止日期，并记录最终答案以及所有受影响的位置。

它的目的不是为了收集消息，而是为了防止四种代价高昂的失败：凭空猜测、重复提问、在邮件中遗失答案，以及只修复了一处却在其他地方留下了同样的问题。

美国翻译协会（ATA）关于翻译项目中的提问指南建议使用共享的查询文件，检查问题是否已被提出，并在交付前解决所有未决问题。XLIFF 标准在结构化翻译工作流中提供了相同的基础数据模型：源单元和目标单元可以携带上下文信息和注释，包括指令和翻译人员的评论。请参阅XLIFF 1.2 规范.

仅在答案会改变翻译结果时提问

当一名合格的翻译人员无法从核准的来源中解决疑问，且该疑问的答案会改变含义、术语、范围、排版或验收标准时，该疑问就应记录在日志中。

触发查询的典型情况包括：

• 具有两种合理解释的指代关系的句子；
• 明显的原文错误，且修正后会改变含义；
• 未定义的缩写或项目特定术语；
• 两个原文位置中的名称或数字冲突；
• 缺失插图、表格、注释或引用的附件；
• 代码、产品名称、引文或引语的可翻译性不明确；
• 导致无法按要求生成目标语言内容的排版限制；以及
• 必须应用于所有重复出现位置的决策。

不要将日志用于翻译人员可以通过常规调研、提供的术语表、风格指南、上下文或既定的目标语言规范解决的问题。如果日志中充斥着“请确认”之类的请求，会将正常的翻译工作推回给客户，并掩盖掉真正重要的问题。

使用最小完备的架构

关键的区别在于 已答复, 已实施、以及 已验证。客户的回复并不代表所有受影响的段落都已修改，而一次编辑也不代表最终导出的文件中已包含该修改。

编写一个可以一次性回答的问题

使用以下结构：

位置： 第 4 章，第 18 段，第 2 句

原文： “Mara 告诉 Elena 她将率领代表团。”

问题： 这里的 she 指的是 Mara 还是 Elena？目标语言要求指代对象必须明确。

已核实证据： 前面两段提到了这两位女性，但并未指明谁担任代表团职务。

建议操作： 除非作者确认是 Elena，否则使用 Mara。

影响： 第 6 章和第 9 章也提到了同一位代表团负责人。 截止日期： 第 4 章批准前。

这比“她指的是谁？”要好，因为它向负责人提供了来源、后果、已做的研究、建议的默认方案以及后续影响。

每一行应只请求一个决策。如果一个段落包含一个歧义代词、一个错误日期和一个未定义的缩写，请创建独立的查询，以便每个查询都有不同的负责人和状态。

按后果而非好奇心进行分类

使用三个实用的级别。

阻碍性 (Blocker)

受影响的翻译无法安全进行，或者继续翻译会导致昂贵的返工。示例包括：源内容缺失、未解决的安全用语、矛盾的数量或章节核心的未知实体。

重大 (Major)

工作可以在记录临时假设的情况下继续，但必须在交付前得到答复。示例包括：重复出现的术语、人物关系或适用于整个出版物的格式规则。

轻微 (Minor)

决策仅影响局部偏好或影响较小的段落，可以批量处理。示例包括：在两种选项都易于理解的情况下，某个一次性标签的大写问题。

严重程度不等于紧急程度。一个三小时内需要的重大术语决策，其处理优先级可能高于下周才翻译的附录中的阻碍性问题。请同时记录影响和截止日期。

将决策分配给正确的负责人

不要把所有问题都发给作者。领域专家可以解决概念问题，目标语言编辑可以负责措辞，而制作负责人可以决定是否可以更换图片。

保持单一事实来源

选择一个权威日志。即时通讯和电子邮件可以用来通知相关人员，但他们的回答必须连同来源和日期一起复制到权威日志的对应行中。

对于每一个新查询：

1. 在日志中搜索该术语、实体、原文摘录和类别。
2. 链接相关问题，而不是默默创建重复项。
3. 使用稳定的源文件位置和版本。
4. 指定一名决策负责人。
5. 完整记录答案。
6. 找出目标语言中所有受影响的出现位置。
7. 仅在完成这些修改后，才将该行标记为已执行。
8. 验证最终交付成果并关闭该行。

XLIFF 的 <note> 元素可以携带指令或译者注释，其上下文结构可以将信息附加到翻译单元。无论您的项目使用 XLIFF、电子表格还是问题跟踪器，请务必保留这种单元级的可追溯性。

将答案转化为可重复使用的项目控制措施

当决策具有可重复使用性时，一个答案应当更新多个行。

• 将核准的名称或术语添加到术语登记表.
• 将关于作者语气的决策添加到风格指南中。
• 在源包中添加“不翻译”规则。
• 将已知的源文件错误添加到变更日志中。
• 将被否决的变体添加到 QA 搜索列表中。
• 为下一批翻译任务添加缺失的上下文指导。

这就是信息增益循环：每一个解决的问题都会让后续的翻译和审校更加可靠。如果一个查询系统只关闭工单而不更新工作资源，那么必然会导致重复提问。

处理源文件错误，而非默不作声地重写

当源文件看起来有误时，请区分观察结果与决策。

错误的记录行：

将日期从 2019 年修正为 2020 年。

更好的记录行：

源文件此处显示为 2019 年，但在时间线和引用的报告中显示为 2020 年。哪个年份具有权威性？建议操作：在源文件所有者核准更正前保留 2019 年。影响范围：正文段落、时间线、图注和索引条目。

译者可以识别证据并建议更正，但不应在不告知的情况下默默修改事实源文。如果所有者批准了更改，请记录是否会更正源文本身以及哪些目标版本会继承该更改。

刻意使用临时假设

当工作必须在答复到达之前继续时：

• 标记该选择provisional;
• 记录为什么它是风险最低的选项；
• 添加确切的搜索词元或片段列表；
• 确定更改它的最后安全日期；
• 在阻碍依然存在时阻止发布；以及
• 用最终答复替换临时说明，而不是将两者都留作相互竞争的指令。

切勿将沉默视为批准。只有在项目简介中提前给出了该规则的情况下，截止日期才能触发升级或声明默认情况。

将查询日志视为项目数据

在里程碑结束时，计算流程信号而不是虚荣指标：

• 未解决的阻碍和重大问题；
• 未答复查询的时长；
• 缺少所有者或截止日期的提问；
• 重复的提问；
• 已答复但尚未实施的行；
• 已实施但尚未验证的行；
• 重复出现的类别和源位置；以及
• 根据答复创建的源文、术语表或简介改进。

大量的查询并不自动意味着翻译质量差。它可能表明源文很困难，或者译者拒绝进行猜测。有用的问题是查询是否具体、重要、得到了一次性解决并得到了正确的传播。

查询日志发布检查清单

在交付之前，请确认：

• 每一行都标识了确切的源版本和位置；
• 阻塞性问题和重大疑问拥有权威解答；
• 临时假设要么得到批准，要么予以移除；
• 最终答案需明确具体的决策内容，而不仅仅是“是”或“已批准”；
• 重复出现的术语和实体已在所有受影响的位置进行更新；
• 可复用的决策已同步至术语表、风格指南和 QA 规则中；
• 已解答、已实施和已验证是三个不同的状态；
• 最终导出的文件在实施后经过了检查；以及
• 已撤回或未解决的行均保留了解释说明。

启动项目时使用书籍源文件预检工作流，以便在问题增多之前理清源版本、术语表、资产和验收标准。BookTranslator 可以从支持的书籍和文档文件中生成完整的翻译初稿；通过查询日志记录源上下文和自动化无法安全解决的决策，然后在人工审校期间一致地应用这些答案。