DeepL翻译术语表功能如何设置并启用？

一、术语表要解决的，是“这个词必须这样翻”的问题

在机器翻译的常规流程里，模型会依据上下文为每个词挑选它认为最贴切的译法；而 DeepL 术语表（Glossary）的作用，是在这层判断之上再加一道“硬约束”——只要原文出现你登记的条目，译文就必须使用你指定的对应表达。它面向的是品牌名、产品型号、法律主体名称、内部岗位称谓这类“译错就出事、译法不能漂移”的词汇，而不是整句风格。也正因为约束是硬的，它并不试图理解句子，只负责把某个词钉在某个译法上。

把这条边界划清楚，后面的所有设置才有意义。术语表不做翻译记忆（TM，即整句复用已有译文）的活儿，也不改写语气和文体；它只接管“词→词”的映射。因此当你发现某段译文语气不对、句子结构别扭时，加术语表条目通常无济于事——那更可能是提示设计或后编辑环节需要解决的问题。

强匹配逻辑带来的两个副作用

其一是词形变化覆盖不完整。英语的复数、德语的复合词、俄语的格变化，未必都能被同一条目命中。经验性观察：名词类条目命中率通常高于动词和形容词，带屈折变化的语言尤其明显。稳妥做法是把常见变体一并登记，例如同时录入单数与复数形式，用条目数量换命中稳定性。

其二是强制替换会破坏语法。当你把某个词硬性指定为名词译法，而原文中它实际作动词使用时，输出可能出现明显的语法错位。这不是缺陷，而是强匹配的必然代价：约束越硬，模型回旋的余地越小。取舍办法见第八节。

二、术语表在哪些环节生效：文本、文件与接口的覆盖差异

判断一个功能值不值得投入维护成本，先看它的生效半径。术语表并非只在网页版文本框里起作用：文本翻译、文件翻译（需具备相应账户权限）以及通过接口发起的翻译请求，都可以携带术语表。这意味着同一份词汇表可以在人工翻译界面与自动化流程之间复用，不必为每条链路各维护一套词库——这是它相对“每次手动改”的核心价值。

但覆盖范围并不均等。文本翻译的术语表切换最直观；文件翻译中是否出现术语表选项，取决于账户类型与文件的语言对，界面不显示时通常不是操作错误，而是该组合不受支持。接口调用侧则需要在请求中显式指定术语表标识，未指定即按默认方式翻译——这一点在排查“为什么接口译文没用我的术语”时尤其关键，因为缺省行为不会有任何报错提示。

界面文案与入口位置会随版本调整。本文描述以截至当前的最新版本为准，若与你所见界面存在差异，请以实际界面为准，并按文中给出的验证步骤自行确认功能是否可用。

三、动手之前：账户额度与语言对的两道门槛

很多人卡在第一步并非不会操作，而是没意识到术语表受两道门槛约束：账户额度与语言对支持范围。前者决定你能建多少个术语表、每个能放多少条目；后者决定你选的语言组合能不能启用术语表功能。两道门槛彼此独立，任何一道没过，表现都是“功能好像不存在”。

免费与付费账户的额度差异

经验性观察：免费账户在术语表数量与条目总量上有明显限制，通常只够支撑一个轻量词汇表；付费与团队账户的额度显著放宽，并支持在成员之间共享。具体数字不建议凭记忆判断，正确做法是进入账户的术语表页面，界面会直接显示当前占用与上限。当新建按钮变灰或提示额度不足时，先清理不再使用的旧表，再考虑升级——多数情况下，被遗忘的历史词表才是额度被占满的原因。

语言对与单语、双语术语表

术语表是绑定语言对的资产：你为“英语→简体中文”建的条目，不能直接用于“日语→简体中文”。因此在规划阶段就要按语言对分表，而不是把所有词塞进一个表里再指望通用。部分语言对还提供单语术语表选项，即只登记源语言术语并给出期望译法，适用于目标语言侧表达统一但源语言多样的场景；是否可选，以创建界面的语言对下拉列表为准，列表里没有的组合即当前不支持。

四、网页版最短路径：从创建到真正生效

网页版是术语表功能最完整、也最适合做初始配置的入口。下面这条路径是经验性观察中被验证为最短的一条，若某个环节的按钮名称与你所见不同，按语义就近寻找即可，不要为了“找不到按钮”而怀疑功能不存在。

1. 登录 DeepL 账户，进入网页版翻译页面，确认翻译框已展开。
2. 在翻译框下方的工具栏中找到“术语表”（Glossary）入口；工具栏被折叠时先展开。
3. 打开术语表面板，选择新建，随后指定源语言与目标语言。语言对一旦确定，该表就只能服务这一组合。
4. 为术语表命名。建议把语言对与用途写进名称，例如“品牌名_英→中”，后续在切换列表中一眼可辨。
5. 逐条录入，或使用文件导入（格式见第六节）。录入时先保存少量条目，不要一次性灌入全部词汇。
6. 返回翻译页面，在术语表入口处选中刚建的表。经验性观察：选中后入口处通常会显示当前术语表名称，这是“已启用”最直观的界面信号。

为什么强调“先少量、再全量”？因为术语表的问题往往不是建不起来，而是建完之后译文变得别扭却不知是哪条引起的。先用十条以内跑通链路，确认启用状态与译文变化符合预期，再导入全量数据，可以把排查成本压到最低。反过来说，一次性导入几百条再逐条排查，等于把可控的小问题放大成全局故障。

例外情况是：部分账户在侧边的账户设置中另有一个术语表管理页，用于批量编辑与删除。两个入口操作的是同一批数据，不必担心重复创建；如果翻译页的入口因界面调整暂时不可见，从账户设置进入是合理的替代路径。

五、桌面端与移动端：路径差异与能力边界

桌面客户端与网页版共用同一账户体系，因此术语表数据是同步的——在网页端建好的表，登录桌面客户端后可以直接选用。差异在于入口位置：桌面客户端通常把术语表入口放在翻译窗口的下方工具栏或应用设置区域，具体位置随平台与版本变化，建议先在窗口底部寻找，再退到设置中查找。

移动端的情况需要格外说明。经验性观察：移动 App 的术语表能力在不同版本、不同平台之间存在差异，创建与批量编辑通常不如网页端完整；在 App 内看不到术语表入口，并不等于账户没有该功能。可复现的验证方法是：在网页端新建一个测试术语表并启用，然后在同一账户的移动 App 中翻译包含该术语的句子，观察译文是否套用了指定表达。若译文跟随网页端的设置变化，说明功能在服务端生效，仅是移动端缺少管理入口。

由此可以得出一条实际建议：把“管理”和“使用”分开。管理动作放在桌面端或网页端，移动端只承担使用。团队协作时这一点更重要，避免有人在手机上误删条目却无人察觉。

六、批量导入：文件格式与编码是失败的主要来源

当条目数量超过几十条，手工录入就不划算了。术语表支持通过文件导入，常见格式为 CSV、TSV 与 TMX。三者定位不同：CSV 与 TSV 是两列式对照表，适合自己维护；TMX 是翻译记忆的交换格式，适合从其他工具迁移已有词汇。选哪种，取决于你的词表是新写还是搬迁。

以 CSV 为例，结构上只需两列：第一列源语言术语，第二列目标语言术语，不加表头也能被识别，但保留一行表头通常更利于人工维护。真正决定成败的是编码——请务必以 UTF-8 保存，否则中文、日文、西里尔字母会在导入时变成乱码，而乱码条目往往仍能被保存，问题会推迟到翻译时才暴露。

品牌名,翻译后的品牌名
产品型号,翻译后的产品型号
部门名称,翻译后的部门名称

上例仅为结构示意，请把左侧替换为你的真实源语言术语、右侧替换为目标语言译法，并确保两列之间用英文逗号分隔；若术语本身含逗号，需要用双引号包裹该字段，或改用 TSV 以制表符分隔，避免解析错位。

导入失败的常见分支

• 提示格式不支持：先确认扩展名与实际编码一致，改后缀不等于改编码。
• 导入成功但条目数为零：多为列顺序反了，或首行被误判为表头。
• 部分条目丢失：检查是否存在空行、重复条目或超长文本，这些常在解析阶段被跳过。
• 译文出现乱码：几乎都是编码问题，用文本编辑器另存为 UTF-8 后重新导入即可复现验证。

这四类现象有一个共同点：都发生在解析阶段，而不是翻译阶段。导入之后不要立刻投入生产。挑三到五条已知条目，在翻译框中输入包含它们的短句，逐条核对输出，这一步通常只需几分钟，却能拦住绝大多数“导进去了但没生效”的误判。

七、启用与切换：同一语言对通常只生效一个术语表

建好表不等于生效，这是新手最常见的落差。启用动作在翻译界面完成：选中某个术语表后，该语言对的翻译请求才会携带这些约束。经验性观察：同一语言对在同一时刻通常只能选中一个术语表，无法叠加使用两套规则。若你的需求确实横跨多个领域，可行的做法是合并成一张表并在命名上体现用途，或按项目切换。

这条限制直接影响了组织方式。与其为每个客户建一张表，不如评估这些词汇是否真的互斥：如果两个客户的品牌词从不共存于同一批文档，合并并不会产生冲突；反之，若同一份文档里会同时出现两个客户的专有名词，就必须分表并接受切换成本。判断依据不是客户数量，而是“是否会在同一次翻译任务中同时出现”。

八、例外与取舍：什么时候不该用术语表

术语表是强约束，强约束就有代价。第一类不该用的场景是“一词多义且语境决定译法”的词。把某个词锁定成单一译法，等于放弃了模型根据上下文做判断的能力；如果该词在语料中一半作名词、一半作动词，强制统一会让另一半句子的语法崩掉。

第二类是纯风格偏好。希望译文“更正式一些”“少用被动”，这属于文体诉求，术语表既表达不了也执行不了，硬塞进去只会制造出局部生硬的句子。第三类是频繁变动的营销口号，这类表达往往按活动周期更换，维护成本高于收益，条目刚录完就可能过期。

反过来，值得纳入的判据相当清晰：译错会造成实质损失（法律主体、合规称谓、药品与器械名称）、需要跨文档绝对一致（产品型号、界面按钮文案）、以及人工后编辑成本明显高于维护成本的高频专有名词。用一句话概括取舍——术语表买的是“确定性”，付的是“灵活性”，只有当确定性带来的收益更大时才划算。

九、性能与成本：开销究竟落在哪里

从响应速度看，术语表带来的额外开销在交互式翻译中通常难以感知，属于定性层面的“基本无差别”。真正的时间成本不在翻译那一刻，而在维护：条目越多，冲突与遗漏的概率越高，复核所需的人力随之上升。因此把“条目规模”当作一个需要管理的指标，比关心毫秒级差异更有意义。

可复现的测量方法如下：选取一段包含已知术语的固定原文，分别在启用与停用术语表的状态下各翻译若干次，记录两次输出的差异条目数，并人工判断差异是否符合预期。若差异条目数远少于术语表中理论上应命中的数量，问题通常出在词形变化或语言对不匹配，而不是性能。对于批量文件翻译，建议先用小批量文件跑通，再放大规模，避免一次性提交大量文件后才发现规则有误。

成本侧还有一笔隐性支出：术语表是账户级资产，成员离职、项目结项后如果无人清理，额度会被长期占用，最终表现为“新建不了”却找不到原因。把清理动作写进项目结项流程，比事后翻查高效得多。

十、团队协作：共享、命名与权限的最小化原则

团队版账户中，术语表可以在成员之间共享，具体谁可编辑、谁只能使用，取决于账户分配给该成员的角色。是否存在共享开关、开关在哪个页面，随账户类型与界面版本变化，请以账户内的术语表设置为准，不要依据他人的截图推断自己的界面。

在权限上建议遵循最小化原则：只给需要维护词表的人编辑权，其余成员仅保留使用权。原因很实际——术语表的错误是全局性的，一条错译会在所有文档中同步扩散，而发现它的人往往是译者而非维护者。让少数人掌握写权限，配合清晰的上报路径，比开放给所有人更可控。

命名规范同样是协作成本的一部分。建议采用“用途_语言对_维护人”的结构，例如“法务_英→中_张三”。当团队里有十几张表时，规范的命名能省掉大量“这张表是干什么的”的沟通。若账户支持备注或说明字段，把适用范围写进去，效果更好——名称负责被看见，备注负责被理解。

十一、验证与回退：三步确认它真的生效了

第一步，确认启用状态。回到翻译界面，查看术语表入口处显示的名称是否为你期望的那张表；名称为空或显示其他表，说明没选上。

第二步，做最小对照实验。准备一句只包含一个术语的短句，分别在启用与停用状态下翻译，比较两次输出。差异应当精确地出现在该术语处，其余部分基本不变。若整句都变了，多半是两次翻译的原文或语言对不一致，而非术语表在起作用。

第三步，检查边界条件。确认语言对一致、条目拼写与原文完全一致（含空格与大小写）。经验性观察：不少“不生效”的报障最终都归结为条目里多了一个空格，或在全角与半角字符之间混用。

回退方案同样要提前想好：术语表随时可以取消选中，取消后翻译立即回到默认行为，不会污染历史记录；若怀疑某条条目引发问题，删除单条比删除整表更精准。建议在批量导入前先导出一份当前词表作为备份——即便界面没有一键导出，保留原始 CSV 源文件也等价于备份。

十二、故障排查：按现象定位，而不是凭猜测

排查时请坚持“一次只改一个变量”。同时更换术语表、语言对和原文，即便问题解决了也无法知道原因，下次还会重演。若条件允许，用一段完全不含术语的原文做对照，可以快速排除“其实是别的地方变了”的误判。

十三、适用与不适用场景清单

把前文的判断标准收敛成一张准入清单，遇到新项目时可以直接对照，而不必每次重新推演。

• 建议启用：品牌与公司名称、法律主体与合规称谓、产品型号与规格、界面按钮等需绝对一致的短语、跨国团队共用的岗位与流程术语。
• 谨慎启用：一词多义且语境决定译法的词、带复杂屈折变化的动词、在多份文档中含义不一致的缩写。
• 不建议启用：纯风格与语气偏好、活动期间高频更换的口号、仅供一次性使用的临时表达。

三档之间的界线并不总是清晰，遇到拿不准的词，可以用前文的判据反问一句：译错会带来多大损失，人工后编辑的成本又有多高。规模上也有边界。经验性观察：单张术语表的条目数从数十条增长到数百条时，维护成本上升明显快于收益，此时更应考虑拆表，按业务域隔离，而不是继续堆在一张表里。

十四、最佳实践检查表

以下检查表按“建设—使用—维护”三段排列，可在每次新建或交接术语表时逐项过一遍，通常两三分钟即可完成。

1. 语言对是否与实际翻译任务一致，是否存在混用多个语向的情况。
2. 命名是否包含用途与语言对，其他人能否在不询问的情况下判断适用范围。
3. 是否先用少量条目跑通链路，再执行全量导入。
4. 源文件是否以 UTF-8 保存，并保留了一份可回溯的备份。
5. 导入后是否用三到五条已知条目做了命中验证。
6. 是否明确“同一语言对只启用一张表”的取舍，并写清了切换规则。
7. 团队内是否约定编辑权限最小化，以及错误上报路径。
8. 项目结项时是否安排了额度清理与词表归档。

十五、常见问题（FAQ）

写在最后：先把链路跑通，再谈规模

回到最初的问题——DeepL 术语表并不难设置，难点在于它同时受账户额度、语言对支持与启用状态三重约束，任何一环没对上，表现都是“看起来没生效”。因此最省时的路径是：先用十条以内的条目在网页端跑通一次完整链路，确认启用信号与译文变化可观测，再谈批量导入与团队共享。

下一步建议你立刻做一件事：挑出当前项目里最容易译错的两个专有名词，在网页端新建一张以语言对命名的小表，启用后用一句包含它们的原文做前后对照。这个动作通常几分钟内完成，却能一次性验证账户额度、语言对支持、启用状态与命中效果四件事。等到规模扩大，第七节的取舍规则与第十四节的检查表就可以直接接管；而由于界面与入口会随版本调整，把上述验证步骤固化成团队习惯，比记住某个按钮的位置更耐用。