我把多语言文案交给AI后翻车了三次，才明白批量翻译插件UI的正确姿势

一、先说翻车经历：那些看起来很聪明的做法

失败做法一：把整个语言文件一股脑丢给AI

我最开始的操作是这样的：打开 zh_CN.json,全选、复制、粘贴到对话框，附一句「帮我翻译成英语、日语、德语、西班牙语」。

结果拿到的东西乍看正常，细看全是坑：

• 「设置」被翻译成 "Settings",但「设为默认」里的「设」被单独翻译成了 "Set up";
• 语言文件里还混着正则说明和占位符 {count},AI 把 {count} 翻译成了 {数量},运行时占位符替换直接报错；
• 三十多个语言包翻下来，同一个词「同步」在不同文件里出现了 "Sync"、"Synchronize"、"Synchronization" 三种译法。

失败做法二：一个语言一个对话，各翻各的

第二次我学聪明了点，每个语言单独开对话。结果更糟：每个对话里的AI都在「自由发挥」，术语一致性彻底崩了。英文版叫 "Bookmark Manager",德文版直译成了 "Lesezeichen-Verwalter"(母语用户看了会皱眉的那种)，日文版干脆用了片假名外来语堆砌。

失败做法三：不告诉AI这是浏览器插件

AI 不知道上下文时，会按「通用软件」来翻译。比如「扩展」在通用语境下被译成 "Extension of file"(文件扩展名)，而浏览器插件场景应该是 "Browser Extension"。菜单项「后退」被译成 "Retreat"——那是军事用语。

三次翻车让我明白：批量生成多语言界面文案，问题不在翻译能力，而在约束不够。

二、正确路径：把AI当成一个「带术语表的本地化工程师」

第一步：整理「翻译原料包」

不要丢原始JSON,先做三件事：

1. 提取纯文案：把 key 和值分离，只让AI处理值；
2. 标注上下文：每条文案标记它出现的位置(菜单/按钮/提示/错误信息)；
3. 建立术语表：插件核心概念(如「书签」「同步」「标签组」)先自己定好各语言的标准译法，或者先让AI生成术语表、人工确认后再用。

第二步：用结构化提示词分批投喂

一次只处理一个目标语言，文案量大时分批(每批50条以内)，并且始终携带同一份术语表。这是保证一致性的关键。

第三步：用JSON Schema式输出 + 程序校验

要求AI输出严格的JSON,拿到结果后跑一个简单脚本：检查key是否齐全、占位符 {xxx} 是否保留、是否有多余翻译。程序做机器检查，人只抽查语义。

三、可直接复用的提示词模板

你是一名专业的软件本地化工程师,正在为Chrome浏览器插件翻译界面文案。

## 背景
- 产品类型:书签管理类浏览器插件
- 目标语言:{目标语言,如:日语}
- 文案风格:简洁、正式,符合该语言母语用户的软件界面习惯

## 术语表(必须严格遵守,不得改写)
- Sync -> {对应译法}
- Bookmark -> {对应译法}
- Group -> {对应译法}

## 翻译规则
1. 严格保留占位符,如 {count}、{name},不得翻译或改动
2. 保留HTML标签如 <b>、<br>
3. 按钮文案控制在2个词以内,提示文案不超过原文字符数的1.5倍
4. "Extension"指浏览器扩展,不是文件后缀
5. 不要逐字直译,优先采用该语言软件界面的惯用表达

## 输出格式
仅输出JSON,不要任何解释:
{"key1":"译文1","key2":"译文2"}

## 待翻译文案(含上下文标注)
{这里粘贴 key + 原文 + 位置标注}

把这个模板存下来，每次只替换目标语言、术语表和文案批次，循环跑完所有语言即可。配合脚本校验占位符和key完整性，基本可以做到零返工。

四、用AI前后对比

最有价值的其实不是「快」，而是流程可复用：插件每次更新新增文案，我只要把新条目塞进同一个模板，十分钟就能补齐8种语言。

五、几点经验提醒

1. 不要跳过术语表。前期花20分钟和AI一起敲定术语，能省掉后期几小时的返工；
2. 小语种务必抽查。英日德这类主流语言质量稳定，但小众语言建议找母语者或用另一个模型交叉验证；
3. 用API而非网页对话。批量场景下走API才能脚本化，还能指定低温度参数减少「发挥」。

如果你也想把这套流程脚本化，需要一个稳定、支持多模型切换的AI API通道，可以试试 https://api.thistoken.ai/register ,注册即用，多语言批量任务跑起来很顺畅。

---

不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。