用 AI 做多语言有多爽 —— DualCam 一个人做出 12 种语言

DualCam 上架的时候，支持 12 种语言：英语、简体中文、繁体中文、日语、德语、法语、阿拉伯语（从右往左排版）、巴西葡语、西班牙语、泰语、印尼语、俄语。

不是只翻了个界面 —— 是从用户点开 App 到掏钱付费、再到读隐私协议这一整条链路，全本地化了。

放在以前，“支持 12 种语言”是一句要算成本的话：你得找译员或买翻译服务、搭一套术语表和翻译管理流程（TMS）、每加一种语言还要做一轮 QA。小团队大多的选择是 —— 先只做中英，等以后再说。

这次我想说的是：这道成本题，被 AI 抹平了。 我一个人，把多语言从”以后再说”做成了”默认就带上”。

我到底把哪些东西做了多语言

很多人以为”做多语言”就是翻译一下界面按钮。其实一个真正全球化的 App，要本地化的面比这多得多。DualCam 这次覆盖了七块：

App 界面文案 —— 近百条 UI 字符串：布局名（画中画/上下/左右/人入景）、美颜档位、面具、背景、震惊模式、设置、相册的多选删除、照片模式、各种 toast 和报错……全部走系统的 String Catalog（.xcstrings）。
系统权限弹窗 —— 相机 / 麦克风 / 相册那三条”为什么要这个权限”的说明（InfoPlist.xcstrings）。这是用户第一次看到的文案，也是审核必看的，全 12 语言。
App 内语言切换 —— 设置里能手动切语言，不跟着系统走也行。切完整个界面立即刷新成新语言。
付费页 —— 标题、套餐名、说明、CTA 全本地化；价格从 App Store 后台实时拉（按用户所在区自动显示 ¥ / $ / €，不写死）。
内购商品 —— “永久买断 / 周会员”两个商品的显示名 + 描述，12 语言，填进 App Store Connect。
App Store 商店页 —— 名称、副标题、关键词、宣传文本、描述，12 语言（关键词还得按每种语言单独优化，这是 ASO 的核心）。
隐私协议 + 用户条款 —— 连官网的法务页面都做成了 12 语言（同一个网址内置语言切换，自动跟随浏览器语言，阿拉伯语自动右对齐）。

一个人，七条战线，12 种语言。 这放在两年前是不可想象的工作量。

用 AI 做多语言的工作流

爽的地方不在于”AI 会翻译”——翻译软件早就有了。爽在于 AI 能在我整个工程的上下文里，把翻译这件事工程化地做完、并自己验证对不对。

具体是这么跑的：

第一步：在上下文里直接产出翻译。 我不需要把文案导出成表格、丢进翻译工具、再导回来。AI 直接读我代码里所有 NSLocalizedString 的 key，理解每一句在什么场景下出现（是按钮？是报错？是营销文案？），然后给出 12 种语言贴合语境的翻译 —— 营销文案翻得有感染力，报错翻得简洁，按钮翻得短。

第二步：脚本把翻译灌进字符串表。 String Catalog 本质是个 JSON。AI 直接写一个 Python 脚本，把几百条翻译按”只补缺、不覆盖已有”的规则写进 .xcstrings，一次性灌完。不是手动一格一格填。

第三步：程序化校验覆盖率。 这步是关键。AI 写脚本扫一遍：代码里在用的每一个 key，是不是 12 种语言都齐了？ 一跑就报出”这 26 个 key 缺了 9 种语言、那 8 个 key 整个没建”，然后批量补齐。最后一句话总结：60 个在用的 key × 12 种语言，零缺口。

人工做多语言最容易出的错就是”漏了几条没翻”或”加了新功能忘了补翻译”。这种覆盖率审计交给脚本，比人靠谱得多。

几个真机/真实上架才会遇到的坑

多语言不是”翻译完就完了”，魔鬼在细节里：

String Catalog 是被逼的最优解。 我这个工程用的是 Xcode 新的”文件夹同步”分组，它不认传统的 .lproj 语言文件夹。绕不过去，只能上 String Catalog —— 结果反而更好维护。
App 内切语言要”骗”过系统。 iOS 默认跟着系统语言走。要做到 App 内手动切，得在运行时把 Bundle.main 换成一个会读指定语言包的子类（swizzle）。切完重建根界面，整个 App 立刻变语言。
价格千万别写死。 早期我在付费页写了 ¥40，这是错的 —— 苹果会按用户所在区自动换算并本地化货币符号。正确做法是只填一个”价格档”，代码用 StoreKit 的 displayPrice 实时拉，美国显示 US$5.99、中国显示 ¥40，一行汇率代码都不用写。
阿拉伯语是从右往左的。 不只是翻译，整个排版要 RTL：文字右对齐、列表项左右边距对调。AI 处理这个时顺手就把 dir="rtl" 和对应 CSS 写好了。
每个字段都有字数上限。 比如内购商品的”显示名 ≤30 字符、描述 ≤45 字符”。AI 是卡着上限写的；个别语言超了（阿拉伯语的”永久”一版太长），换了个更短的词压回限制内。这种细碎约束，AI 记得比我牢。

多语言到底有什么用 —— 为什么值得做

如果它很贵，“要不要做”还要权衡。但当成本趋近于零，剩下的全是好处：

1. 触达 —— 你的用户大概率不说中文。 App Store 是个全球市场，下载量的大头来自非英语区。一个只有中英的 App，等于主动把日本、德国、巴西、中东的用户挡在门外。本地化不是锦上添花，是把店开到别人家门口。

2. ASO —— 关键词要按语言分别打。 App Store 的搜索是分语言的。你在日区用日语关键词、在西语区用西语关键词，才能在各自的市场被搜到。这是多语言直接换来的自然流量，单靠英文关键词覆盖不到。

3. 转化 —— 母语让人更敢付费。 付费页、商品名、价格都用用户的母语 + 本地货币显示，决策成本和心理门槛都更低。一个看不懂的付费页，转化率注定差。

4. 信任与合规 —— 尤其是相机类 App。 权限弹窗和隐私协议用母语写清楚”我们不收集你的数据”，用户更敢授权；审核也更顺。DualCam 是个会检测人脸、抠人像的相机 App，把隐私这块用每种语言讲明白，是过审和建立信任的基础。

5. 一致性 —— AI 让术语全局统一。 界面叫”震惊模式”，商店描述、隐私页也得是同一个说法。一个人用 AI 统一产出，比多个译员分头翻更容易保持术语一致。

小结

过去，“支持多语言”是一道成本与收益的权衡题 —— 大多数独立开发者算下来都选择缓一缓。

AI 把这道题的成本项几乎清零了：翻译在上下文里直接生成、脚本批量灌入、覆盖率程序化校验、连 RTL 和字数限制这种细节都顺手处理。

于是”要不要做多语言”不再是个需要纠结的决定 —— 它变成了默认选项。 一个人 + AI，就能让一个 App 从第一天起就讲全世界的语言。

这大概就是这一轮 AI 工具最朴素、也最实在的一种”爽”：它没有让我变成翻译，而是让”做不做多语言”这件事，不再需要被讨论。

DualCam 已上架：App Store 下载。它怎么从一个念头做到上架，见 DualCam 项目记录。