直接结论
一份面向全球发布的本地化清单，必须覆盖三个经常被混为一谈的层：翻译（文字变成了目标语言）、本地化（策略在目标市场成立）、运营（每个 locale 完整上线且持续更新）。大多数全球发布的翻车是运营性的，不是语言性的——某个市场带着英文截图上线了几个月、某个关键词字段从没用母语调研过、某个 locale 从上上个版本起就没同步更新。下面的清单按发布顺序展开：先做市场和 locale 划定，再做按语言的调研与生产，然后是拦截「半成品 locale」的一致性检查，最后是长期规则——任何版本发布前，所有在线 locale 要么已更新、要么有负责人签字的明确延期。
三个层
| 层 | 问题 | 典型失败 |
|---|---|---|
| 翻译 | 所有字段都是目标语言了吗？ | 本地化 listing 里躺着英文关键词字段 |
| 本地化 | 策略在这个市场成立吗？ | 翻译出来的关键词根本没人搜 |
| 运营 | 每个 locale 都完整且现行吗？ | 一半市场的截图落后两个版本 |
清单
阶段一——翻译之前先划定范围
- 明确列出目标商店，每个商店标注文字和 locale 代码（zh-Hans 与 zh-Hant、pt-BR 与 pt-PT、es-MX 与 es-ES）。
- 每个市场做出决定：完整本地化、仅元数据本地化、还是直接用英文 listing——并记录理由。
- 在承诺发布日期之前，识别有合规或内容要求的市场。
- 指定一名负责人对整个版本的 locale 完整性负责。
阶段二——按 locale 调研与生产
- 每个完整本地化的 locale 用母语跑关键词调研：商店搜索联想、本地竞品、本地措辞——不是翻译英文聚类。
- 围绕调研出的本地关键词重建标题副标题；不同文字下字符限制的计算方式不同。
- 从同一份 recipe 按 locale 产出截图文字图层，排印和信息密度按文字调整。
- 关键词字段按市场本地化，不按语言：locale 与国家商店的喂给关系值得逐一确认。
- 每个 locale 由母语读者对照源策略做语义一致性评审，而不是语法校对。
阶段三——上线前一致性检查
- 核查每个 locale 所有字段都已填写——副标题、推广文本、关键词字段里没有英文兜底。
- 核查每个 locale 的截图集覆盖所有必需设备类别。
- 按 locale 检查链接：支持、隐私和营销 URL 应落在该市场读得懂的页面上。
- 确认价格展示、优惠文案、日期和数字格式符合当地惯例。
阶段四——长期规则
- 任何版本发布前，所有在线 locale 必须已更新——或有明确、带日期、有主人的延期记录。
- 维护一张 locale 状态表（locale × 素材 × 最后更新版本），每次发布节点过一遍。
- 每个主要市场的母语关键词调研至少一年重跑两次；本地搜索行为的变化和你的路线图无关。
常见失败模式
隐形的半个 locale
某市场元数据是本地语言，截图却挂了几个月英文。用户把这种不一致读成怠慢——事实也确实是怠慢。
一个西语、一个葡语、一个中文
把 es、pt、zh 各当成一个 locale，忽略了 es-MX 与 es-ES、pt-BR 与 pt-PT、zh-Hans 与 zh-Hant 在词汇、预期和竞争上的差异。按商店划定范围，不按语系。
上线后的 locale 漂移
上线时所有 locale 齐整，之后每个版本只更新主语言。三个版本之内，次要市场描述的就是一个旧产品。阶段四的规则就是为这个存在的。
执行原则
一个 locale 要么完整且现行，要么是一条有记录、有日期、有主人的例外。没有第三种状态——第三种状态叫无声腐烂。
为什么这件事适合放进 App Store Helper
App Store Helper 把语言变体并排放在同一个项目里，每种语言有自己的评审状态，「哪个 locale 落后了」有一个可见的答案。一致性检查和「locale 不齐不发版」的规则变成可核查的工作流状态，而不是一张总有人忘记更新的表格。