别把本地化留到最后：用 AI + String Catalogs 先整理 iOS 文案

今天这招适合一个很常见的首版场景：你已经让 AI 写出几个 SwiftUI 页面，按钮、空状态、错误提示都能跑，但所有文案都散在代码里。等到想做英文版、日文版，或者只是想检查长文案会不会把界面撑爆时，你会发现自己没有一张「全 App 文案表」。

String Catalogs 可以把这件事提前做掉。Apple 的文档把它定义为在 Xcode 中管理可本地化字符串、添加语言、翻译文本、处理复数和按设备变化文案的方式。1 对 PM 来说，重点不是马上出海，而是先把首版里所有会给用户看的文字收进一个地方，后面验收、改文案、试多语言都不再靠肉眼翻代码。

这个技巧解决什么问题

没有设计和研发帮忙时，iOS 首版最容易漏掉三类文案问题：

界面里还有临时文案，比如「TODO」「测试按钮」「Error」。
中文看着刚好，换成英文、德文这类更长的语言后，按钮和卡片被撑开。
数量、设备、状态不一样时，同一句话需要不同写法，比如 1 个任务和 3 个任务不能永远用同一段提示。

如果只让 AI 继续改 SwiftUI 页面，它可能会把文案改得更顺，但你仍然不知道全 App 到底有多少句用户可见文本。String Catalog 的价值是把文案从「藏在代码里」变成「能检查的清单」。WWDC23 的 String Catalogs 介绍里，Apple 明确说 Xcode 15 可以把项目里的可本地化字符串集中到 String Catalog，并在构建时从 SwiftUI、Swift 代码、Interface Builder 和 Info.plist 等位置发现字符串。2

String Catalog 把一段界面文字变成不同语言版本 — Apple 官方文档用「Hello」到「Hej」示意 String Catalog 管理不同语言文案；对首版 PM 来说，它更像一张可验收的全 App 文案表。1

原理：AI 负责找问题，Xcode 负责当账本

这招不要让 AI 直接接管本地化。更稳的分工是：

环节	让谁做	产出
找出用户会看到的文字	Xcode 构建后自动提取，AI 辅助查漏	String Catalog 里的字符串列表
判断文案是否像产品话	PM + AI	更清楚的中文源文案、翻译备注
生成第一版外语草稿	AI	可人工复核的翻译候选
验收界面会不会坏	Xcode Preview 或运行时切语言	截图、问题清单

这张自制流程图对应本期最小工作流：AI 先帮 PM 理清文案意图，Xcode String Catalog 再负责同步、状态和切语言验收。

Apple 在 WWDC23 里提到，String Catalog 会跟踪 New、Needs Review、Stale 等状态；源字符串变更后，已有翻译会被标成需要复核，代码里已经找不到的字符串会变成 Stale。2 这对 PM 很有用，因为你不需要记住「上周改过哪句按钮文案」。让 Xcode 标出来，再让 AI 帮你逐条判断语气和长度，风险小很多。

怎么用：今天做一个 30 分钟版本

1. 先让 AI 帮你列出文案意图

把当前页面的 SwiftUI 文件或页面截图交给 AI，要求它只做一件事：列出用户可见文案，不改代码。可以这样问：

请帮我从这个 iOS 页面里列出所有用户可见文案。输出表格：页面位置、原文、用户看到它时的场景、这句话想让用户做什么、是否需要给翻译者备注。不要改代码。

这一步的产出不是最终翻译，而是一张 PM 看得懂的文案意图表。你会很快发现哪些句子太工程化，比如「Request failed」，哪些句子没有给用户下一步，比如「加载失败」。

2. 在 Xcode 里建立 String Catalog 并构建一次

如果项目还没有 String Catalog，在 Xcode 里新建一个 Localizable.xcstrings。然后执行一次 Product > Build。Apple 的 String Catalogs 介绍中说明，Xcode 会在构建时发现当前 scheme 和平台里的可本地化字符串；新发现的字符串会被加入 Catalog，准备翻译。2

你不需要一开始就把所有语言都做完。今天的最小目标只有两个：

Catalog 里能看到主要页面的按钮、标题、空状态和错误提示。
每句关键文案旁边有一句备注，说明它出现在哪里、用户当时要做什么。

备注很重要。Apple 在视频里建议给字符串添加 comments，帮助翻译者理解文案在界面里的使用场景。2 没有翻译者时，这些备注就是你和 AI 协作的上下文。

3. 让 AI 先做「长度压力测试」，不是只做翻译

把 Catalog 里的关键中文、备注和目标语言交给 AI，让它输出两版：

正常版：适合真实产品上线的翻译。
加长版：故意偏长，用来测试按钮、卡片、导航栏会不会被撑爆。

然后把正常版填回 Catalog，把加长版临时放到一门测试语言里。这里不要追求一次翻译完美，先看界面是否还能站得住。Apple 的本地化界面准备文档强调，要找出 App 中需要翻译的文字，并验证界面能适应翻译后的文本。3

4. 处理两个最容易被 PM 忽略的变化

第一是数量变化。比如「1 个草稿」和「3 个草稿」在英文里写法不同，其他语言可能更复杂。WWDC23 里演示了 String Catalog Editor 的复数变化能力，它可以为插值数字设置 plural variation，不必手写复杂的 .stringsdict。2

第二是设备变化。iPhone 上写「轻点」，Mac 上可能要写「点击」。String Catalog 支持按设备变化文本，Apple 在演示里用 iOS 的「tap」和 Mac 的「click」说明了这种差异。2 如果你的 App 未来可能上 iPad 或 Mac，这一步能提前少踩坑。

怎么验收：别只看 Catalog，要切语言跑一遍

在 Xcode 里切换运行语言是 PM 很容易上手的验收动作。Apple 的本地化准备文档配图显示，可以在 Scheme Editor 的 Run > Options 里设置 App Language 和 App Region。3

Xcode Scheme Editor 里的 App Language 和 App Region 设置 — 切到目标语言后跑一遍核心路径，重点看导航栏、按钮、空状态和错误提示有没有被长文案撑坏；图中设置来自 Apple 官方文档。3

你可以按这个顺序验收：

首页：标题、主按钮、空状态能不能完整显示。
表单页：输入框 placeholder、错误提示、保存按钮有没有挤压。
列表页：数量相关文案是否能正确变化。
弹窗和权限提示：是否还像真人说话，不像系统报错。
失败状态：用户是否知道下一步该重试、返回，还是联系支持。

今天只要跑通一条核心路径就够了。把发现的问题丢给 AI，让它按「更短、更像产品话、保留用户下一步」三条规则改写，再回到 Catalog 里更新。

今天的最小行动清单

新建或打开 Localizable.xcstrings，执行一次 Product > Build。
让 AI 从一个核心页面里列出用户可见文案和使用场景。
给 10 条最关键文案补上备注，不急着全量翻译。
让 AI 生成一版目标语言翻译和一版加长测试文案。
在 Scheme 的 Run > Options 里切换 App Language，跑一遍核心路径。

这件事做完，你不一定已经有一套完美翻译，但你会得到一张可维护的 App 文案账本。下次再让 AI 改界面时，先看 Catalog 里哪些文案变成 New、Needs Review 或 Stale，比到处翻 SwiftUI 文件靠谱得多。