一份能用的术语库不是事先写好的，而是在项目推进中从真正制造麻烦的术语里长出来的。这里讲它为什么难、在哪里出问题，以及委托方该向供应商要什么。
- 术语库不是一份事先写好的术语表
- 最容易被丢掉的那部分
- 难的那些需要一个负责人，而不是投票
- 冻结点：一个容易错过、且错过就有代价的时刻
- 委托方该要求什么
术语库不是一份事先写好的术语表
团队往往把术语工作想象成翻译开始前要完成的一项任务：坐下来、列出术语、商定对应词、交出去。在二十年的项目实践里，一份能用的术语库不是这样建成的。你在还没看过源文时写下的清单，是一次猜测。
真正的术语库是在工作推进过程中长出来的——从那些真正制造麻烦的术语里。事先能做的部分很小：明显的产品名、已经批准过的受监管术语、客户有强烈意见的内容。那是一颗种子，不是术语库。
最容易被丢掉的那部分
术语库的内容有几个来源，其中两个大家都想得到：客户已批准的材料（过往申报、既有标签、已出货的手册），以及源文本身在通读时暴露出的行话与歧义词。
真正被忽略的是第三个：项目过程中的疑问记录。译员提问，客户或领域审校回答——那个回答就是一项术语决定，不管有没有人把它当成术语决定写下来。
这些答案是你花钱做出的判断。把它们收进术语库，是这项工作的大部分；把它们留在邮件和聊天记录里，则是术语漂移的大部分。一个项目结束、人员轮换之后，没人记得当初为什么这么定，于是下一个项目重新争论一遍。
| 来源 | 具体是什么 | 实际状况 |
|---|---|---|
| 客户已批准的材料 | 过往申报、既有标签、已出货的手册 | 大家都想得到 |
| 源文本身 | 通读时暴露出来的行话与歧义词 | 大家都想得到 |
| 项目过程中的 疑问记录 | 译员提问，客户或领域审校回答——那个回答就是一项术语决定，不管有没有人把它当成术语决定写下来 | 真正被忽略的一个。这些答案是你花钱做出的判断；留在邮件和聊天记录里，就是术语漂移的大部分 |
条目只写「用 X」，半年后的下一次改版会有人重新掀开讨论——通常是一位当时不在场的新审校。写清依据，他们就会继续往下走。所以理由比决定本身更重要。
难的那些需要一个负责人，而不是投票
任何有规模的项目里，总有少数术语没有干净的答案。两个目标词都站得住。一个源术语被客户在各部门之间用得很松。一个受监管的表述上，标准和市场团队意见相左。这些不靠共识解决。
它们之所以解决，是因为有权拍板的人做了决定，并把决定连同理由记录下来。而理由比决定本身更重要——半年后的下一次改版，会有人质疑这个选择，通常是一位当时不在场的新审校。条目只写「用 X」，他们会重新掀开讨论；写清依据，他们就会继续往下走。
冻结点：一个容易错过、且错过就有代价的时刻
术语库应当在第一轮翻译和审校期间保持开放，因为真正的术语正是在那时浮现的。但总有一个点，它必须停止移动。
错过这个点的代价是具体的：如果一个术语在整套文档翻译过半之后才改，你并没有改善一致性——你制造了两个版本的事实，外加一张返工账单。改得越晚，账单越大。
这个点具体在哪里，取决于交付物的数量、审校进度和文档之间的引用关系。判断它是术语管理里最需要经验的一步，也是自动化工具帮不上忙的地方。
委托方该要求什么
如果你是委托方，不要只把「一份术语表」列为交付物，然后就以为够了。要问三件事。术语库是基于贵司已批准的材料建立的，而不是被发明出来的。贵司项目中的疑问答案被收进了术语库，使你花钱做出的那些决定不会流失。以及，项目结束时你能拿回这份术语库，并且是你能复用的格式。
一家把术语当作自家工具的供应商，会把它留在自己那一侧，每次合作都悄悄重建一遍——而且每次都向你收重建的钱。一家把它当作你的资产的供应商会交出来。三年下来，这个差别比任何每字单价都值钱。