· 本地化 · 6 分钟阅读

应用商店信息应该本地化成哪些语言?

应用商店信息应该本地化成哪些语言?
TL;DR.真正的问题不是“要做多少种语言”,而是“先做哪些市场”。从应用信息页做起,而不是应用界面本身:你可以只翻译元数据和截图,完全不用碰一行应用代码。之后再用两份清单交叉排序——几个高消费市场(德语、日语、韩语)和几个高下载量市场(巴西葡萄牙语、印地语、印尼语)——对照你的应用实际适合哪里。下面的分级框架会告诉你先做什么、接下来做什么、最后再做什么。

关于这个问题的大多数建议,其实回答的是另一个问题。你问“该为哪些语言本地化”,得到的却是一堆全球应用经济的统计数字。当作冷知识挺有意思,但帮不了你做决定。这篇文章就是要给你一个决定。

如今 App Store 大约有 50 种元数据语言(Apple 在 2026 年 3 月把语言数从 39 种增加到 50 种,新增了主要是印度语系的十一种),Google Play 的应用信息语言区域数量更多。你不可能全做,也不该全做。目标是列出一份短小、有优先级、这周就能行动的清单。

先把应用信息和应用本身分开来看

这是两个成本天差地别的项目,把它们混为一谈是最常见的错误。

  • 应用信息页——标题、副标题、描述、关键词和截图。翻译这些内容改变的是用户安装前看到的东西。不涉及应用代码,在 App Store Connect 和 Play Console 里改完立刻生效。
  • 应用界面——应用运行时的每一句文案。翻译这部分是实打实的工程工作:要提取字符串、接入本地化系统、重新测试每个界面,还要在每次发版时持续维护。

省钱又理智的顺序是:先本地化应用信息页,等数据证明值得再翻译应用本身。ASO 从业者把这叫作“最小可行本地化”:先给某个市场投放翻译好的商店页面,观察安装量和(更关键的)留存率是否站得住,然后再决定是否花钱翻译应用本身。一个本地化的信息页配上英文应用,是完全合理的测试;而为一个从未转化过的市场全盘翻译应用,则是打了水漂的钱。

所以下面的框架讨论的是应用信息页。应用界面的翻译要作为一个独立、之后再做的决定,按市场逐一评估,依据是留存数据。

两股方向相反的力量

市场沿着“消费轴”和“规模轴”排列,二者很少重合。这里更看重方向而非精确数字——把这些当作指引,而不是价目表,因为具体数字会因类别和年份而变化。

  • 人均收入高。少数成熟市场的消费能力远超其人口占比。日本尤其突出——其头部产品历来的人均收入大约是美国的两倍——德国和韩国也属于同一高消费梯队。下载量较少,但每个用户的价值更高。
  • 下载量大。印度的全球安装量遥遥领先,巴西和印尼紧随其后。触达规模巨大,但人均收入低得多,变现更多依赖广告和低价位,而非付费安装或订阅。

两个方向都不是绝对赢家。走高端订阅路线的应用应更看重第一份清单;靠规模吃饭、依赖广告变现的应用应更看重第二份清单。大多数应用会从两边各选几个,具体取决于自己的定价模式。

决策框架

分三个层级,按顺序做。做到你维护精力的极限就可以停下来——光是把应用信息本地化到第一层,就已经覆盖了全球大部分的应用消费。

第一层——从这里开始。几乎每款应用都该把应用信息本地化成的语言,因为它们兼具庞大受众和已验证的付费意愿:

  • 西班牙语葡萄牙语(巴西)——覆盖美洲和西班牙的庞大受众。
  • 德语法语日语——成熟的高消费市场,本地语言的信息页能实测提升转化率。
  • 简体中文——单一最大的应用商店,如果你的应用在当地可行的话。

第二层——接下来加上这些。等第一层上线并看到数据变化后,值得触达的市场:

  • 韩语意大利语——市场较小但意向高,转化不错。
  • 俄语土耳其语——受众规模大,变现效果因类别而异。
  • 如果你的产品偏欧洲市场,还可以加上葡萄牙语(葡萄牙)荷兰语

第三层——锦上添花。拼规模和长尾触达。当新增一种语言的边际成本接近于零时(下面会讲到),或者你的分析数据显示某个特定市场冒头了,就值得做:

  • 印地语印尼语越南语泰语——安装量巨大,人均收入较低,多以广告变现。
  • 波兰语阿拉伯语,以及其他符合你特定受众的区域语言。

快速参考:

根据自己的应用做调整。一款在美国和德国留存表现良好的冥想应用,应更看重第一层里的欧洲语言;一款追求规模的社交应用则会更早跳到第三层的规模市场。你自己的安装和留存数据比任何通用清单都可靠——这些层级只是起点,不是终点。

一份信息页可以覆盖多个商店区域

有个不太起眼但很有用的效率点:在 App Store 上,单一语言的本地化会通过回退机制服务相关地区。如果你有法语(法国)的信息页,但还没单独设置法语(加拿大),法语(法国)的元数据会一直服务讲法语的加拿大用户,直到你添加专属版本。西班牙语(西班牙)和西班牙语(墨西哥)也是同理,其他语言变体也是如此。

实际上,这意味着一份写得好的法语信息页已经能覆盖好几个商店区域的法语用户,一份西班牙语信息页在拉美和西班牙也是同样的效果。等某个市场规模大到值得针对性打磨措辞和关键词时,再添加国家专属版本。先做好基础语言,等量起来了再按地区精细化。

为什么“做多少种”不再是难题

上面每一层都假设翻译每种语言都要花钱——这也是为什么代理机构会建议你精挑细选。而 Mokbi 恰恰改变了这道算术题。因为它一次性把整份应用信息——商店文案和截图文案——翻译成 50 种语言,第二十种语言的边际成本几乎和第二种一样低。

当新增一种语言几乎不花钱时,约束条件就翻转了。你不再是在配给翻译额度以保护预算,而是在决定哪些市场值得投入注意力、打磨关键词,最终再翻译应用本身。这是一个优先级问题,而分级框架正好能回答它。先广泛做好信息页,再在数据指向的地方深耕。

截图只是这个流程中的一环——截图、功能图、商店文案、翻译、发布——所以文案会和描述在同一轮里一起翻译,两者按语言区域始终保持同步。你不用在一个工具里翻译文字,再在另一个工具里翻译图片。

一套简单的执行顺序

  1. 把信息页本地化到第一层。元数据加截图,底层应用仍是英文。这是你的测试,不是承诺。
  2. 按市场观察转化率和留存率。安装量告诉你信息页是否奏效;留存率告诉你这个市场是不是真的。
  3. 加上第二层,再加第三层。趁边际成本低时扩展,让你自己的分析数据把特定语言往前推。
  4. 最后才翻译应用界面——只针对那两三个用真实留存数据证明了价值的市场。

这样的顺序让昂贵的工作(应用翻译)要靠证据才能解锁,而让便宜的工作(翻译好的商店页面)尽可能广泛地铺开。

接下来可以读读

把你的应用信息翻译成 50 种语言 →