如何构建译者和 AI 都能真正使用的翻译术语表

要创建翻译术语表，先选出需要统一措辞的概念，定义每个概念在你的文档中的含义，为每种语言和语境批准一个目标术语，并指定一名负责人来维护这些决定。然后在真实段落中测试这些条目，再交给译者或翻译工具。

最有用的区分是记录你决策的主术语表与工具可以读取的较小导出文件。两列式导入文件可能是必要的，但它无法取代让这两列变得可信的上下文、依据和审批历史。

从空白术语表模板和术语表示例开始。两者都是 UTF-8 CSV 文件。示例使用虚构产品和示意性的英译法决策；它不是经过认证的术语列表、客户项目，也不是 BookTranslator 的现成导入预设。

让术语表比词典更小

当不一致或有歧义的选择会改变含义、造成导航混乱、削弱重要区分，或带来本可避免的审核工作时，就把该术语纳入。不要仅仅因为软件提取出了每个名词，就把它们全部收集起来。

一次有用的筛选会问：

• 这个概念是否在多个章节、文件或贡献者之间反复出现？
• 源词是否有不止一个相关含义？
• 组织、作者或主题领域是否要求特定的目标形式？
• 换一种选择是否会让警告、说明、界面或论证更难理解？
• 该术语是否是新出现的、有争议的，或已知在本项目中导致过更正？

一个罕见但影响重大的术语，可能比一个常见普通词更值得收录。一个没有现实歧义的标准术语，可能根本不需要收录。

COTSES 的《翻译术语管理入门指南》建议收录与组织相关的术语，并明确验证责任。它还提醒，仅凭条目数量并不能证明质量。这些原则在这里比其软件示例的年代更重要。

候选提取只是收件箱。当你知道一个提取出的短语是什么意思、何时适用，以及谁批准了目标措辞时，它才会成为有用的术语。

围绕一个含义建立一条记录

不要让源字符串独自拥有这条记录。英语单词“charge”可以描述电学属性，也可以描述计费金额。用一行把每次出现都映射到同一个法语词，编码的是错误，而不是一致性。

为每个概念分配一个稳定的标识符，然后添加特定语言的决策。在简单电子表格中，每个概念和源/目标语言区域对使用一行。两行可以共享同一个源拼写，但并不代表同一个概念。

模板包含以下字段：

上下文引用应能让审核者重新找到该段落：文件版本和章节、权威术语记录或其他持久来源。“来自互联网”是不够的。对于原作者定义的概念，手稿自身的定义可能就是相关证据。

将定义与源上下文分开。定义说明概念是什么；上下文展示它如何使用。诸如“Select the workspace”这样的句子说明了用法，但没有解释工作区包含什么，或它与项目有何不同。

修复五个常见的术语表条目

以下修复属于可下载的虚构示例。它们说明编辑决策，而非通用的法语术语规则。示例段落提供了周围的文本。

1. 一个多义词被强制对应一个目标译法

薄弱条目： charge → charge

修复： 创建独立的概念：

• 电学属性：源术语 charge；目标译法 charge électrique；领域“入门电子学”；上下文“The capacitor stores electric charge.”
• 计费金额：源术语 charge；目标译法 frais；领域“计费”；上下文“The delivery charge is shown before payment.”

这并不意味着任一映射应覆盖“charge”的每一次出现。条目的领域和上下文是决策的一部分。如果所选工具无法区分它们，请使用单独的项目导出、更长的无歧义短语或人工审核，而不是全局替换。

2. 缺少词性的术语

薄弱条目： seal → sceller

修复： 区分动词与组件：

• “封上信封”：一个动词，在本项目中对应的示例译文为 sceller。
• “更换橡胶密封圈”：一个指代部件的名词，对应译文为 joint。

现在，电子表格描述的是两个概念，而不是暗示某个橡胶部件是一种动作。对于真实的技术文档，请让领域审校人员验证该部件的含义和首选术语。

3. 两种可接受的译文，但项目没有偏好

薄弱条目： workspace → espace de travail / zone de travail

修正： 为这个虚构应用的命名容器批准 espace de travail。将 zone de travail 记录为针对此界面概念的拒绝变体，而不是泛指糟糕的法语。添加一条用法说明，指出允许正常的语法屈折变化。

被拒绝的变体需要理由和适用范围。否则，审校人员可能会在不同语境中“纠正”一个完全有效的短语。

4. 仅靠暗示来保护的产品名称

薄弱条目： LeafDeck → LeafDeck

修正： 设置 do_not_translate=true，将其标识为虚构产品名称，保留大小写，并引用演示项目的命名决定。说明该规则不适用于普通描述中的无关词语。

仅凭源文本和目标文本相同，并不能说明保留是有意为之，还是只是未完成的工作。请使用不翻译决策指南了解更广泛的排除清单。

5. 将草稿决定呈现为已批准

薄弱条目： sync → synchroniser / mettre à jour，没有负责人或状态。

修正： 先定义动作。对于这个同步设备库的虚构命令，批准 synchroniser 作为动词，并记录该备选译文不适用于这个特定命令。指定负责人和有日期的决策来源。

将单独提议的名词标签保留在 draft 状态，直到其审校人员解决为止。示例 CSV 特意包含了该草稿行。看起来整洁的电子表格并不能证明每一行都已批准。

使用条目质量门槛，而不是装饰性评分

在批准条目之前，先问六个是或否的问题：

1. 含义： 其他人能否将此概念与相近概念区分开？
2. 证据： 他们能否找到支持性来源或作者决定？
3. 语言： 目标形式是否适用于指定的区域设置、语法和领域？
4. 范围： 他们是否知道该规则适用于哪里、不适用于哪里？
5. 责任： 是否有负责人负责解决变更？
6. 使用： 该条目是否已在代表性句子中检查过？

如果有答案未解决，该条目就保持草稿状态。这是一套编辑验收标准，而不是经过验证的翻译质量数值指标。

按专业分工。作者或主题专家确认概念；目标语言审校者确认用法；术语负责人记录决定并分发已批准的版本。在小型项目中，一个人可以身兼数职，但这些问题仍然需要得到解答。

如果审校者对某条目提出异议，请记录相互竞争的选择以及暴露冲突的段落。遵循译者提问工作流，而不是让私信成为无记录的例外。

仅在批准后导出以供接收工具使用

你的主术语表和引擎的词典有着不同的用途。主术语表向人们解释决策。导入文件必须遵循特定工具的架构和匹配行为。

对于支持术语表导入的工具：

1. 选择所需的源语言/目标语言对和项目领域。
2. 排除 draft 和 deprecated 条目。
3. 解决接收工具无法消歧的重复源字符串。
4. 仅将受支持的字段映射到工具的当前导入格式中。
5. 确认它如何处理大小写、词形变化、多词术语和受保护文本。
6. 测试一小段有代表性的输入，并检查返回的译文。

例如，Google Cloud Translation 有文档记载的单向 CSV 格式使用不带表头的源/目标对，而其等效术语集 CSV 则使用语言表头。其术语表匹配默认区分大小写，并且某些停用词条目会被忽略。这些是 Google Cloud 的规则，而不是通用 CSV 规则或 BookTranslator 的功能。在为该服务准备导出文件之前，请查看当前的 Google Cloud 术语表文档。

不要将本文中带有丰富注释的 CSV 上传到随便一个导入对话框中。它是一个工作主表。反过来，也不要仅仅因为某个工具只接受两列，就丢弃它的定义和批准历史。

在使用带有受支持指令字段的 AI 系统时，请提供相关的、已批准的术语子集，以及区分含义所需的上下文。指令可以要求使用术语；但它并不能证明输出遵循了该要求。请检查结果。如果系统不提供受支持的术语表输入，请将主表保留为审校者参考，而不是发明一种导入它的方法。

对于拥有一线多语言团队的组织而言，翻译后的术语一致性同样重要。培训材料、政策和运营沟通可能需要以员工偏好的语言传达给他们，同时保留已批准的措辞。iTacit 解释了多语言沟通如何支持跨语言、国家和文化的工作场所信息。

添加语言而不抹除本地决策

在添加另一个目标语言环境时复用概念 ID，但为该语言环境提供自己的目标、状态、负责人和证据。法语中的批准并不等于批准了德语对应项。空白目标意味着“未解决”，而不是“自动使用源文”。

同样的纪律也适用于同一语言内部。当特定语言环境的决策存在实质性差异时，请将其拆分。不要仅仅为了添加没有任何实际影响的地区标签而创建重复行。

让这些状态保持简单：

• 草稿： 候选或有争议的决策；不属于已批准的导出内容。
• 已批准： 在所述范围和版本内被接受。
• 已弃用： 为历史和检测而保留，但不推荐用于新工作。

对于实质性变更，请记录旧形式、新形式、原因、生效版本、负责人以及受影响的源文位置。重建相关导出内容，并告知译者哪些段落需要重新考虑。不要在项目中途悄悄替换某个术语，并指望已经翻译的章节会自动更新。

当产品、源稿件、标准或公认用法发生变化时，请审查条目。日历提醒可能有帮助，但定义发生变化是更强的触发因素。

在扩大规模之前，先在段落中验证术语表

术语表可以内部整齐，但在句子中仍然可能失效。使用一小组刻意包含以下情况的段落：

• 一个歧义源词具有两种含义；
• 一个术语既作为标题又出现在正文中；
• 单数、复数或其他语法变体；
• 一个受保护的名称紧邻普通语言；以及
• 一个术语出现在表格、图注、说明或其他重要文档结构中。

可下载的示例将“delivery charge”与“electric charge”配对，并包含“seal”作为名词和动词的用法。这些案例揭示了为什么无范围限定的替换是错误的验收测试。

对于每个段落，记录源文、术语表版本、目标输出、审校决定以及必要的更正。如果你实际测试了翻译服务，请添加服务/模型、日期、设置和原始输出。本文中的示例不声称进行了此类服务测试。

完整文档翻译完成后，进入术语一致性审校。术语表构建确立政策；输出审校决定交付文本是否遵循该政策而不失自然。

移交决策记录，而不仅仅是词汇表

最终移交应包含源文版本、已批准的主术语表、适用时的接收工具导出文件、未解决查询日志以及代表性示例。进行翻译的人员应知道哪个文件具有权威性，以及就冲突向谁咨询。

对于受支持的整本书或长文档，BookTranslator 的文件翻译工作流可以提供草稿供后续审校。将你批准的术语表与该草稿放在一起。此处的 worksheet 是外部编辑参考，并不声称 BookTranslator 导入用户管理的 CSV 术语表或强制执行每个条目。

从几个重要概念开始，使决策可检查，并从真正的歧义或审校发现中扩展。目标是下一个文档中未解决的决策更少——而不是术语表最大。