翻译术语表怎么做？从术语提取、禁用译法到版本管理的完整指南

同一个功能在首页叫“工作区”，帮助中心叫“工作空间”，客服又称为“项目区”，用户很难知道它们是否指向同一件事。翻译术语表要解决的不是把词汇翻译得更华丽，而是让产品、文档与沟通使用同一套可解释的名称。

一份有用的术语表应回答三个问题：这个词代表什么概念，在哪些语境使用，谁有权决定它的译法。下面以虚构的软件产品为例，介绍从术语提取到版本发布的完整流程。示例字段是团队内部的数据设计，不代表某家翻译 API 的请求参数。

一、先确定范围，不要把整本词典放进来

第一版可以聚焦一个用户旅程，例如注册、创建工作区、邀请成员和查看账单。收集界面文案、帮助文章、客服回复及产品说明，优先处理出现频繁、容易混淆、直接影响操作的名称。

普通连接词、完整宣传段落和一次性的客户地址通常不适合作为术语。前者不需要额外管理，中间一类更适合进入已审校句段库，后者还可能带来不必要的数据暴露。术语表越大，审查冲突和维护过期规则的成本也越高。

可以先建立候选区，不急于决定译法。记录“这个词为什么值得管理”，比一次提取几千个高频词更容易形成可用成果。若团队尚未统一源语言名称，应先解决源文案本身的不一致。

二、以概念为单位，而不是以拼写为单位

英文 charge 在账单中可能指费用，在电池说明中可能表示充电。只建立一行“charge = 费用”，会把一个场景的正确答案扩散到另一个场景。应把概念标识和领域作为主键的一部分，并保留真实上下文。

同样，中文“账户”可能指登录身份，也可能指财务科目；“订阅”可能指付费计划，也可能指关注消息。词形相同不代表概念相同，词形不同也可能属于同一概念。先写定义，再讨论目标语言词汇，能够减少围绕个人偏好的争论。

对于品牌、功能名和技术标识，要区分展示名称与程序标识。界面上的名称可以本地化，API 字段、路径、文件名和配置键不应因为术语统一而自动改变。两类内容应有不同的保护规则。

三、设计一条足够解释问题的术语记录

还可以补充词性、截图编号、大小写规则、复数形式和示例句。不要把这些列全部塞进不支持它们的供应商导入文件；维护主表与导出视图，才不会因为某个接口只接收两列而丢失上下文。

四、用例句验证译法，而不只看孤立词对

假设已批准 workspace 译为“工作区”。评审至少应检查“创建工作区”“离开工作区”“工作区所有者”三个不同位置，确认词义和语法均自然。只有在词表中看起来漂亮，但放进按钮就不通顺的译法，仍需要修改。

再加入负面样本：把同一拼写放入不属于该概念的句子，检查规则是否错误触发。对于短缩写、连字符和大小写变体，这一步尤其重要。不要使用简单的全局字符串替换，替换掉另一单词内部的字符或代码标识。

中英文规则也不一定对称。一个英文词可能对应多个中文概念；反向翻译时，仅靠把两列交换过来，无法恢复已经消失的语义区分。每个语言方向都应独立确认适用范围。

五、把供应商规则放在适配层

不同服务的术语匹配并不相同。例如 Google Cloud 的术语表文档说明其默认匹配区分大小写，并提供忽略大小写的选项。这个行为不能直接推断到其他供应商或自建服务。

接入前建立一组小测试：原形、大小写变化、复数、带标点、相似词和不适用领域各一例。分别记录输入、实际输出和期望结果。若引擎不支持某种约束，应在审校环节提示，而不是宣称约束已经生效。

使用 TranslateHub 时，公开能力和请求字段以开发者文档为准。本文的术语主表、版本号和禁用词检查可以由应用侧管理；不能仅凭流程设计就假定接口接受自定义 glossary 参数。

六、让审批和更新形成明确状态

建议至少区分候选、待评审、已批准和已废弃。译者可以提交建议，产品负责人确认概念，目标语言审校者确认表达，发布负责人决定何时启用。小团队可以一人兼任，但每次变更仍需留下理由。

不要把所有“看起来更好”的措辞修改都当作强制更新。先区分事实错误、产品正式改名与风格偏好，再判断是否必须重翻历史内容。否则，一个轻微词汇偏好就可能触发整个站点的无效修改。

废弃词不要立即删除。保留它的替代项和停用原因，才能解释历史译文，并在扫描旧内容时发现需要迁移的位置。删除记录只能让冲突暂时看不见，不能帮助团队理解它。

七、更新术语时同步检查旧资产

发布新版本前，先扫描受影响的页面、帮助文章、邮件模板和翻译记忆库，生成候选清单。列表应包含内容版本、命中位置、当前译法和负责人，避免拿一份过时导出文件修改已经更新的页面。

批量替换后仍要检查句法、指代和链接文本。一个名称变长，可能使按钮溢出；一个产品名发生改变，周边的所有格或数量表达也可能需要调整。术语迁移不是简单的查找替换任务。

保留上一版主表、导出文件以及相关发布记录。回滚时先判断是恢复术语规则、恢复译文，还是两者都恢复。只回滚词表但继续使用旧缓存，会让页面呈现混合版本。

八、衡量真实覆盖，而不是追求漂亮百分比

术语符合率的分母应是“确实适用某条规则的位置”，不是文章中的全部单词。一个页面没有相关术语，不能证明术语应用成功；一个目标语言允许变形，也不应因为未逐字匹配而被错误判为失败。

建议同时记录未覆盖概念、误触发、人工豁免和重复争议。若错误主要来自缺少语境，继续添加同义词可能没有帮助；若错误来自旧版本未迁移，就应改进发布和失效流程，而不是更换翻译引擎。

每次评审可以抽取少量近期问题，追溯到源文案、词表规则和最终页面。这样能区分“规则不清楚”“工具未执行”和“译者判断不同”，避免把所有问题都归为翻译质量差。

九、交付前检查清单

确认每条已批准记录都有定义、语言方向、适用场景和责任人；确认导出文件来自指定版本；确认技术标识未被改写；确认存在正例和反例测试；确认禁用词检查支持必要的例外；确认回滚文件能够找到。

对于跨团队协作，还应指定争议入口和处理期限。临时发现新词时，可以先保留源词并注明待确认，而不是由不同人员各自创造一个“正式译名”。稳定的协作方式比追求一次性完美词库更重要。

十、常见问题

术语表越大越好吗？

不是。优先管理影响用户理解和业务一致性的概念。低价值条目会增加冲突和维护负担，应定期清理未使用或定义不清的候选项。

术语表和翻译记忆库是一回事吗？

不是。术语表约束概念的名称，记忆库复用已翻译句段。两者可以协作，但不能互相替代，详见翻译资产对比指南。

引擎没有术语表功能怎么办？

可以先提供已批准语境，再在结果中执行术语检查并人工复核。不要用未经检查的后处理替换，强行制造看似一致、实际不通顺的译文。

品牌词是否应该永远保留原文？

应按品牌规范和目标市场决定。有些名称保留原文，有些使用认可的本地译名；需要明确规则，而不是对所有大写词一律禁止翻译。

术语表建立后，可以结合机器翻译译后编辑流程完成意义、术语和版式的联合验收。