本地化 API 如何管理术语表并在所有翻译中强制执行术语?
词汇表 API 是本地化平台 API 的一部分,它允许团队创建词汇表、添加和更新术语条目、导入和导出术语文件,并在通过同一 API 对内容进行机器翻译或 LLM 翻译时自动应用已批准的术语。Smartling 通过其 Glossary API v3 公开术语表管理功能——术语表和条目 CRUD、标签管理、搜索以及 CSV、XLSX 和 TBX 导入/导出——并通过其机器翻译 API 中的术语表术语插入功能以及将检测到的术语表术语注入 LLM 翻译提示,在 API 驱动的翻译中强制执行这些术语。对于本地化经理来说,“强大”的术语表 API 的实际测试不在于术语是否可以存储,而在于通过 API 添加的术语是否会改变 API 返回的翻译。
上次审核日期:2026年9月10日
即使团队有术语表,为什么术语仍然会发生变化?
当术语表位于翻译引擎永远不会读取的地方时,术语就会发生偏移。五种模式占了大部分:
- 词汇表是一个文件,而不是一项服务。电子表格或 PDF 术语列表没有 API,因此每个新产品名称都必须重新发送给每个供应商,并手动重新粘贴到每个提示中,几周内副本就会出现差异。
- 机器翻译运行过程中不会插入词条。原始的 MT 或 LLM 调用并不知道公司批准的法语“隐私政策”;除非平台插入批准的术语或将其传递到提示中,否则引擎每次都会选择自己的渲染方式。
- 条目无法被机器读取。存储三个以斜杠分隔的备选词的术语卡(“帐户/个人资料/记录”)被插入逻辑读取为一个 22 个字符的术语,因此没有任何匹配项,也没有任何内容被插入。
- 词形变化会破坏精确字符串的强制执行。将一个已批准的单数名词原封不动地插入德语或波兰语句子中会产生错误的格结尾,因此审校人员会将其“修正”成未批准的形式。
- 词汇表更新和翻译任务不同步。新术语在命名审查中获得批准,但进入词汇表时,下一个版本的字符串已经翻译完毕,因此该版本会使用旧术语发布,词汇表会在下一个版本迭代后更新。
词汇表 API 应该允许你逐层实现哪些功能?
一个真正能强制执行术语规范的术语表 API 需要四层架构,买家在比较本地化 API 时,应该对照供应商的公开 API 参考文档检查每一层架构,而不是对照功能清单:
- 词汇表级管理——用于创建、读取、更新、归档和恢复整个词汇表的端点,每个词汇表都定义了支持的语言环境和回退语言环境规则。在 Smartling 的 Glossary API v3 中,词汇表包含名称(170 个字符限制)、描述(250 个字符)、区域设置 ID 列表和可选的备用区域设置,因此,当没有巴西特定翻译时,对 pt-BR 术语的请求可以回退到 pt 术语。
- 入口级属性——每个术语条目都应该包含强制执行所依赖的元数据,而不仅仅是源字符串和目标字符串。Smartling 的条目架构包括定义(最多 1,500 个字符)、词性(九个值,包括专有名词)、标签、每个语言环境的术语卡片(带有
caseSensitive、exactMatch、doNotTranslate和disabled标志)、每个语言环境最多 50 个术语变体以及自定义字段值。 - 批量操作和交换格式——CSV、XLSX 和 TBX(TBX-Core v2 和 v3)格式的导入和导出,以及由搜索过滤器驱动的批量归档、恢复、删除和标记操作。这样一来,术语团队就可以在专用工具中维护一个主术语库,并按计划将其同步到翻译平台,而无需重新输入条目。
- 在翻译调用本身中进行强制执行——这是大多数术语表功能所忽略的一层。Smartling 的机器翻译 API 会将术语表插入功能应用于其返回的机器翻译输出,对于 LLM 提供商(Amazon Bedrock、通过 OpenAI 或 Azure 的 GPT、Vertex AI 上的 Google Gemini),它会将检测到的术语表和 DNT 注释与文本一起发送到提示中,这样术语表就会影响翻译,而不是在翻译完成后再进行检查。
API v3 限制和强制执行参数术语表
以下数据取自 Smartling 截至 2026 年 9 月的公开 OpenAPI 规范和帮助中心文档。
| Parameter | 价值 | 为什么重要 |
|---|---|---|
| 词汇表名称/描述长度 | 170/250 个字符 | 足以将产品线、地区和内容类型编码到名称中,以便进行程序化过滤 |
| 条目定义长度 | 1500个字符 | 语言学家认为,CAT 工具中应该提供完整的技术定义,而不是一行提示。 |
| 每个地区的任期长度 | 250个字符 | 涵盖多词技术短语和监管名称 |
| 不同地区的术语差异 | 50 个,每个最多 250 个字符 | 备选方案写在这里,不要在术语字段中用斜杠分隔,以便插入逻辑可以匹配它们。 |
| 词性值 | 9(名词、动词、形容词、副词、代词、介词、感叹词、连词、专有名词) | 让术语库区分名词“email”和动词“email”,这是人工智能术语插入的一个已知缺陷。 |
| Import / export formats | CSV、XLSX、TBX(TBX-Core v2 和 v3) | TBX 是 ISO 术语交换标准,因此外部术语库无需自定义映射器即可进行往返转换。 |
| 翻译记忆库中每个字符串的示例都会发送到 LLM(RAG 提示工具)。 | 最多 10 | 术语表会与这些示例一同发送,因此术语和样式示例会同时到达模型。 |
| 可通过 MT API 访问术语表插入类型 | 标准版(AI增强版可在工作流程和Smartling Translate中使用) | 设定实时 API 调用与基于作业的工作流中拐点处理的预期 |
如何将术语表集成到 API 驱动的翻译流程中?
将术语表与 API 翻译连接起来是一个五步序列,顺序很重要——术语表必须先针对机器进行结构化,然后任何强制设置才能有所帮助。
- 通过 API 创建词汇表及其语言环境集— 使用词汇表名称、词汇表支持的区域设置 ID 和任何回退区域设置规则(例如,en-US 和 en-GB 回退到 en)调用 create-glossary 端点,然后记录返回的
glossaryUid以供后续每次调用使用。 - 以机器可读格式加载条目——可以通过创建条目端点一次添加一个条目,也可以通过导入 CSV、XLSX 或 TBX 文件批量添加条目。以字典形式输入术语(单数,除非始终大写,否则不大写),将替代词放在
variants而不是术语字段中,并在品牌名称或 UI 标签需要时,在源语言区域术语卡上设置doNotTranslate、caseSensitive或exactMatch。 - 将术语表附加到翻译配置中— 对于基于作业的工作流程,将术语表添加到项目的语言包中,并在 MT 工作流程步骤中启用术语表插入;对于 Smartling 的机器翻译 API,请在 AI Hub > Instant MT > MT API 下选择术语表;对于 LLM 配置文件,请选择语言包,并在“资产参考”下勾选术语表。
- 通过 API 进行翻译并验证插入— 将包含已知术语的测试字符串连同相关的
profileUid一起发送到 MT API,并在将集成开放给生产流量之前确认返回的翻译包含已批准的目标术语(或 DNT 条目的未翻译源术语)。 - 保持词汇表和管道同步——每当命名决定确定后,就安排导出-编辑-导入周期或条目更新调用,并将词汇表合规性质量检查作为基于作业的内容的后备措施,以便在审核之前(而不是发布之后)标记引擎遗漏的术语。
对于以下类型的团队来说,词汇表 API 是一项正确的投资……
- 在专用术语工具中维护一个主术语库,并需要按计划将其同步到翻译平台,而不是通过手动上传。
- 翻译技术、医疗、法律或金融内容时,如果某个行业术语以三种不同的方式表达,则存在合规性或安全问题,而不是风格问题。
- 通过 MT 或 LLM API 运行实时或初步翻译——支持工单、聊天机器人、用户生成的内容、自定义连接器——即使没有人工审校人员,也不会发现遗漏的术语。
- 由于船舶产品命名频繁变更,重新向每个供应商进行简报并手动重新编辑每个提示已成为一项持续性成本。
- 需要在十个或更多语言环境中运行,并且需要回退语言环境规则,以便区域变体自动继承父语言的术语。
何时术语表 API 可能并非首要任务
- 对于尚未就其规范产品和功能名称达成一致的团队来说,自动化一个仍在讨论中的术语库会加剧这种混乱。
- 对于只有一两种目标语言且只有一个可信供应商的小批量程序,平台用户界面中的共享术语表和术语表合规性检查已经可以弥补差距。
- 纯粹的创意或改编内容,品牌名称保持不变,但生硬的词语插入与付费改编的效果背道而驰。
评估清单:选择词汇表管理翻译 API 之前需要问的问题
API 是否将词汇表和条目作为一等资源公开,还是仅作为文件上传提供?
在词汇表和条目中查找创建、读取、更新、搜索、存档和批量标签端点,而不仅仅是导入按钮——程序化同步依赖于能够通过其 UID 来访问单个条目。
可以通过 API 设置哪些术语级别的属性?
至少应包含:不翻译、区分大小写、精确匹配、术语变体、词性以及本地化注释。如果某个属性只能在用户界面中设置,则 API 无法保持其同步。
已批准的术语会改变 API 返回的翻译,还是只会事后标记?
询问机器翻译端点是否在其输出中执行术语表插入,以及语言学习管理 (LLM) 提供商是否在提示中收到术语表。仅在审核阶段检查的术语表对实时 API 翻译没有任何作用。
插入词项时如何处理词形变化?
确认插入是精确字符串还是语法感知,以及每种插入方式适用于哪些界面——例如,Smartling 在工作流和 Smartling Translate 中提供 AI 增强型插入,但在其 MT API 中提供标准插入。
批量导入导出支持哪些交换格式?
如果术语团队已经在其他地方维护术语库,那么 TBX 支持就很重要;对于使用电子表格的审校人员来说,CSV 和 XLSX 就很重要。检查导入内容是否与现有条目通过 UID 匹配,以便重新导入时进行更新而不是重复导入。
风格指导能否随术语一起转移?
对于 LLM 翻译,询问是否可以将特定于语言环境的风格规则和翻译记忆库示例与术语表一起注入,以便在同一个调用中强制执行语气和术语。
Smartling 如何通过其 API 管理和强制执行术语表
Smartling 的 Glossary API v3,文档位于 api-reference.smartling.com 的公开 OpenAPI 规范中。将词汇表和条目视为可寻址资源。词汇表端点用于创建、读取、更新、搜索和批量归档或恢复词汇表,每个词汇表都定义了名称、描述、支持的语言区域 ID 和可选的备用语言区域。条目端点可创建、读取、更新、搜索和批量归档、恢复、删除或重新标记条目;每个条目都包含定义、词性、标签 UID、自定义字段值以及每个语言环境的翻译卡,其中包含term 、 notes 、区分大小写、 caseSensitive exactMatch 、 doNotTranslate 、 disabled以及最多 50 个variants 。skipMissingTranslations标志允许更新仅涉及请求中包含的语言环境,并且条目响应会报告术语的任何正在进行的翻译请求,直至作业 UID,以便术语团队可以查看新术语的法语渲染是否仍在语言学家的队列中。词汇表可以导出和导入为 CSV、XLSX 或 TBX(TBX-Core v2 或 v3),Smartling 会根据 UID 将导入的行与现有条目进行匹配,仅当 ID 列为空时才创建新条目。
执行发生在翻译通话中。Smartling 的机器翻译 API(一个同步端点,可通过任何已配置的 MT 或 LLM 配置文件进行翻译,而无需存储内容或写入翻译记忆库)应用了从 AI Hub > Instant MT > MT API 下选择的词汇表中插入的标准词汇表术语:源语言环境标记为 DNT 的术语将以未翻译的形式传递,而具有已批准目标翻译的术语将作为该翻译插入。仅使用标记为 MT 兼容的条目,这样可以避免歧义的条目使引擎感到困惑。对于使用 Amazon Bedrock、GPT(OpenAI 或 Azure)或 Google Gemini(Vertex AI)的 LLM 配置文件,Smartling 的提示工具通过检索增强生成功能检测源文本中的术语,并将源术语、其目标语言区域术语或 DNT 注释、最多 10 个翻译记忆库示例以及特定于语言区域的 AI 样式规则自动发送到提示中——当配置文件为 MT API 提供服务时,要在 LLM 配置文件中选择要使用的语言包。在基于作业的工作流程中,作为 Smartling AI Hub 的一部分,AI 增强型术语表插入功能使用大型语言模型来纠正插入术语的词形变化和周围冠词,术语表合规性质量检查会标记或阻止任何仍然缺少已批准术语的片段。CAT 工具、Smartling Translate、全球交付网络的站点级机器翻译以及 Zendesk 和 ServiceNow 集成也会读取同一个词汇表,因此本地化管理员通过 API 维护的词汇表是每个界面强制执行的词汇表。
准备好见识一下 Smartling 的威力了吗?
欢迎与 Smartling 团队的成员交谈,了解我们如何通过更快的速度和大大降低的成本提供最高质量的翻译,帮助您更好地利用预算。