插件翻译翻车之后,我才明白多语言文案不该让AI“一次性吐完”
先说一次典型的失败
给浏览器插件做多语言支持,听起来是AI最擅长的事:把 manifest.json 和 _locales 目录里的文案丢给模型,让它翻译成十几种语言,几分钟就能拿到结果。
我第一次就是这么干的。把一份包含两百多条 key-value 的中文语言包直接贴进对话框,附一句“翻译成英文、日语、韩语、西班牙语等12种语言,保持JSON格式”。模型确实返回了12份格式完整的JSON,看起来皆大欢喜。
直到用户反馈进来:
- 土耳其语版本里,"清除缓存”被译成了一个在当地方言里有俚语含义的词;
- 日语里同一个“设置”按钮,两处 key 被分别译成了「設定」和「セッティング」,界面风格割裂;
- 俄语译文比英文长出40%,按钮文字直接溢出;
- 还有几个 key 的占位符
{count}被翻译成了「{カウント}」,运行时直接报错。
问题不在模型能力,在于我把它当成了一台“翻译自动售货机”:一次性投喂,一次性输出,中间没有任何质量控制环节。
失败做法的三个共性
复盘下来,这类翻车通常踩了同样的坑:
坑一:没有术语表,模型只能猜。 插件界面里的词不是孤立句子。"Tab""剪藏”“沉浸模式”这些词在产品里有一致性要求,但你不说,模型每次都会给出自己的最优解——而它的最优解之间可能互相矛盾。
坑二:没有长度约束。 界面文案不是文档,按钮放不下长句。中文四个字的“重新检测”,直译成德语可能是一整个从句。
坑三:一次生成全部语言,错误成倍复制。 一份提示词的缺陷会原样复制到12种语言里,返工时你要修12遍。
正确路径:把一次翻译拆成三个阶段
后来我把流程改成了“术语先行 → 分批翻译 → 回译校验”,AI在其中扮演三个不同角色。
第一步:让AI先当“术语顾问”
不急着翻译。先把源文案和产品背景给模型,让它产出一份多语言术语对照表:
你是一个软件本地化专家。我正在为一个浏览器插件做多语言支持。
请先阅读以下源文案(中文),完成术语整理任务:
1. 从文案中提取所有产品核心术语(功能名、按钮名、专有名词);
2. 为每个术语确定英文标准译法,注意这是浏览器插件语境,
参考Chrome官方界面用语习惯;
3. 标注哪些术语需要保持英文不译(如产品名);
4. 对每个术语给出简短的理由说明。
源文案如下:
{粘贴你的locales JSON或文案列表}这一步人工过目一次,十分钟。它决定了后面所有语言的一致性底座。
第二步:带约束地分批翻译
术语表确认后,再开始翻译,而且按语言分批、按批次分块,每次处理一种语言。提示词模板如下,可直接复制使用:
你是一个专业的软件界面本地化译者。
## 任务
将下面的浏览器插件界面文案从{源语言}翻译为{目标语言}。
## 必须遵守的术语表
{粘贴第一步产出的该语言术语对照表,格式:原文=译文}
## 硬性规则
1. 保持JSON结构完全不变,只翻译value,不改动key;
2. 保留所有占位符原样输出,如 {count}、{name}、%s 不得翻译;
3. 每条译文长度尽量不超过原文的1.3倍,这是界面按钮文案,
过长会被截断;如无法缩短,请在末尾加 [LONG] 标记;
4. 按钮文案使用祈使句,不用敬语除非该语言界面惯例要求
(如日语需使用です・ます体);
5. 不确定的俚语敏感词,不要自行发挥,加 [CHECK] 标记;
6. 只输出JSON,不要任何解释。
## 待翻译文案
{粘贴本次批次的JSON,建议每次不超过50条}两个细节值得强调:[LONG] 和 [CHECK] 标记让模型把“没把握”显式暴露出来,而不是硬着头皮编。这比追求“零干预全自动”可靠得多——AI最擅长把可疑的地方标出来,人只看标记处,审查成本骤降。
第三步:回译校验
最后再来一轮,让模型把译文回译成中文,与原文对比语义是否偏移。这一步能抓住大部分“翻译得很流畅但意思不对”的问题,尤其是土耳其语那次翻车,回译立刻就能暴露。
前后对比
| 维度 | 失败做法(一把梭) | 三阶段流程 |
|---|---|---|
| 首轮可用率 | 约六成,需大量返工 | 绝大部分标记项修完即可上线 |
| 一致性 | 同词不同译,随机 | 术语表锁定,全语言统一 |
| 返工成本 | 12种语言逐个排查 | 只看 [CHECK]/[LONG] 标记 |
| 占位符损坏 | 手工全局搜索修复 | 规则前置,基本不出现 |
| 人工耗时 | 感觉快,返工拖一周 | 流程半天,当周上线 |
真实体感:改流程后,新增一种语言从“祈祷式发布”变成了“跑一遍模板、扫一遍标记”的例行操作。后续插件迭代新增文案,只需要复用同一套术语表和模板增量翻译,边际成本极低。
一点延伸
如果你的插件文案量大、语言多,这个过程还可以更进一步:用API把三阶段串成脚本,术语表存进数据库,翻译任务排队跑,标记项汇总成一份审核清单。模型调用通过一个统一的OpenAI兼容网关接入,中文、日文这类文案工作换便宜模型跑,回译校验换强模型跑,成本结构立刻健康很多。具体模型价格以官网价格页为准,通常按token计费,批量文案这种短文本任务花不了多少。
想动手试试这套流程的话,可以先注册一个API账号,把上面第二阶段的提示词模板直接作为system prompt跑起来:https://api.thistoken.ai/register
多语言不是一次翻译任务,而是一条带质检的生产线——把AI放进合适的位置,它比你想象的稳得多。
---
不想折腾多家供应商的接入差异?在 https://api.thistoken.ai/register 注册,用一个 base_url 调用所有模型。