应用商店本地化：先做哪些语言

直接结论

「应该先本地化哪些语言」有一个大多数团队手里已经握着数据的答案：按「未本地化状态下已经从该市场获得的收入或安装量」排序，乘上「本地化在该市场通常能撬动多大变化」，再对照「把这个 locale 做好的真实成本」。已有的未本地化增长是手头最强的信号——一个通过英文 listing 还在持续送来安装量的市场，是在宣告本地化会放大的需求。第二梯队信号：该语言里你所在品类的商店搜索量、竞品的本地化空档（竞品全是英文的市场赢起来便宜）、该语言的客服和评价活跃度。错误的排序方式是按人口、按 GDP、或者按「大家都翻这五种语言」——那些排的是世界，不是你的机会。

排序输入

推荐流程

1. 先拉地区数据，再听观点

一份报表——最近两个季度分商店的安装、收入和 listing 转化率——能在大多数排序争论开始之前结束它们。有增长但转化低于平均的市场，就是你的候选名单。

2. 按市场估算增益，不笼统估算

本地化对指标的撬动因市场而异：有的商店换成本地语言转化率大幅上升，有的市场对英文 listing 容忍度很高。本地语言竞品的存在感是个不错的代理指标——它们统治的地方，语言就重要。

3. 诚实地核算每个 locale 的成本

一个 locale 的成本包括调研、重建元数据、截图文字生产、母语评审，以及所有人都会忘的那部分——未来每个版本的永久维护。一个你养不起的 locale，是一个带发布日期的负债。

4. 按波次推进，不按批量

每波上一到三个 locale，读一个周期的结果，再决定下一波。第一波教会你真实的单 locale 成本和单市场增益；一次性上十个语言的批量发布，等你学到教训时已经来不及调整。

5. 定义退出标准，和进入标准一样重要

先决定什么结果才配得上下一波——以及什么结果应该让整个计划暂停。一个素材完整、两个发布周期后仍无增益的 locale，是值得尊重的证据，不是「本地化得再狠一点」的理由。

常见失败模式

按语言规模排序

按使用人口选语言，任何产品都会选出同样五种语言，与品类、竞争和既有增长无关。你的数据比人口统计更有发言权。

半承诺的 locale

元数据本地化了、截图没有、关键词字段是翻译的不是调研的。半成品 locale 花掉了预算，产出的结果读起来像「本地化在这里没用」，毒化下一轮排序。

成本里不算维护

每个在线 locale 都会加重未来每一次发布。一个季度里翻八种语言的团队，往往下个季度就停更其中五种——比从没上线更糟，因为过期读起来像怠慢。

locale 排序清单

1. 拉好地区报表：分商店的安装、收入、转化。
2. 候选名单按「既有增长 × 语言敏感度估算」排序。
3. 每个 locale 的完整成本算清，含每版本维护。
4. 波次已定义：一到三个 locale、读数周期、再下一波。
5. 第一波上线前写好进入和退出标准。
6. 每个上线的 locale 都是完整的——不做只有元数据的发布。

执行原则

在你已经有增长但服务不足的地方本地化，以一个你能永远维持的节奏。一个将来会被弃养的 locale，从一开始就不该上线。

为什么这件事适合放进 App Store Helper

App Store Helper 让每一波的运营成本变低：新 locale 继承项目的定位、关键词结构和 screenshot recipe，按语言的评审状态在上线前就显示什么已完成。增加一个 locale 变成一项生产任务，而不是一次策略的重新推导。