OpenL logo

如何对移动应用进行本地化

OpenL Team 2026/3/14

目录

如果你正在搜索如何对移动应用进行本地化，你通常需要的不是”翻译技巧”，而是一套可安全发布的工作流程，涵盖应用字符串、布局、复数规则、从右到左支持、截图和应用商店元数据，同时不会破坏产品本身。

这就是关键区别：移动应用本地化不仅仅是翻译文本，而是为每个目标市场调整应用、产品页面和质量保证流程。Apple 表示 App Store 已覆盖 175 个地区和 40 种语言，而 Android 13 引入了系统级的应用语言偏好设置。换句话说，两大主要平台现在都将语言选择视为核心产品体验，而非事后补充。

本指南将逐步介绍 iOS 和 Android 团队的实际操作步骤。

概览：

  • 将应用内本地化与 App Store 和 Google Play 本地化分开处理。
  • 在翻译之前先将字符串外部化。
  • 尽早处理复数、变量、日期、货币和 RTL。
  • 在发布真正的翻译之前，先用伪语言进行测试。
  • 不仅要本地化描述文字，还要本地化截图和商店资源。

移动应用本地化实际包含哪些内容

本地化工作通常分为两条主线。

1. 应用内本地化

这是产品本身：

  • UI 字符串
  • 错误消息和引导文案
  • 日期、时间、数字、货币和单位
  • 复数和性别敏感字符串
  • 布局扩展和从右到左行为
  • 包含文本或方向含义的图片或图标

Apple 明确建议使用 Xcode、Foundation API、Auto Layout、Unicode 支持、本地化资源目录和方向感知符号来为全球市场准备应用。Android 同样建议使用区域感知资源、应用语言支持和 RTL 感知布局，而非硬编码文本和定位。

2. 应用商店列表本地化

这是用户发现你应用的方式：

  • 应用名称
  • 副标题或简短描述
  • 完整描述
  • 关键词
  • 截图
  • 应用预览或宣传视频

将此视为一个独立的交付物。一个本地化良好的应用如果产品页面是通用的、未翻译的或与目标市场视觉不匹配，仍然可能表现不佳。

从国际化开始，而非翻译

翻译是一个以结构为起点的流程中的最后一步。

将字符串外部化并保持完整的备用语言

在 Android 上，Google 警告说你的默认 res/values/strings.xml 必须定义应用所需的每个字符串。如果默认文件不完整且设备运行在不支持的区域设置下，应用可能无法加载并显示带有”强制关闭”按钮的错误。这就是为什么本地化从资源管理开始，而非语言选择。

对于 iOS，Apple 建议将用户可见的文本和图像与可执行代码分离，以便作为资源文件进行本地化。在现代 Apple 工作流程中，字符串目录是 Xcode 15 及更高版本中处理包含复数的字符串的推荐方式。

实用规则：

  • 永远不要在视图或控制器中硬编码 UI 文本
  • 保持一个规范的源语言
  • 确保每个面向用户的字符串都有稳定的键、上下文和备用值
  • 为含义模糊的字符串添加翻译者注释

一个小示例可以让这更容易理解。

Android 通常从一个默认的 strings.xml 文件开始：

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

然后你的 UI 读取资源而非硬编码英文：

Text(text = stringResource(R.string.checkout_cta))

在 Apple 平台上，Xcode 15+ 通常在字符串目录中管理相同的概念。简化的 Localizable.xcstrings 片段如下所示：

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

你不需要记住文件格式。操作层面的要点更简单：每个面向用户的字符串都需要一个唯一的事实来源、足够的翻译者上下文，以及在某个语言不完整时的安全备用方案。

如果你的应用还发布结构化语言文件，我们的 2026 年最佳 JSON 翻译工具 指南可以帮助你思考自动化和格式保持问题。

如果你需要一个直接处理应用资源文件的工具，OpenL JSON Translator 值得一看。它专为翻译 .json 文件而设计，不会破坏键名或结构，这正是当应用字符串存储在机器可读的本地化文件中时你所需要的。工作流程很简单：上传从应用、CMS 或本地化管道导出的 JSON 文件，选择目标语言，然后下载一个结构相同的翻译后 JSON 文件。根据产品页面介绍，它支持 100 多种语言和最大 50 MB 的文件，是处理结构化内容的应用本地化团队实用的初稿工具。

支持应用级语言选择

用户越来越期望能够独立于设备语言单独选择应用语言。

在 Apple 平台上，用户可以为应用单独选择偏好语言，独立于设备语言。在 Android 上，Android 13 添加了集中式的应用语言设置，Google 建议启用自动逐应用语言支持或将你的选择器接入官方 API。

这对实际产品很重要。双语和多语用户可能保持手机使用英语，但更喜欢用另一种语言使用购物、银行或外卖应用。如果你的应用强制使用单一语言模型，那么在翻译质量成为问题之前，你就已经在制造摩擦了。

使用平台本地化技术栈

除非你确实需要，否则不要试图发明一套平行的本地化系统。

对于大多数团队来说，默认的平台技术栈就足够了：

  • iOS: string catalogs、Localizable.strings、.stringsdict、Foundation formatters、Auto Layout
  • Android: res/values/、特定区域资源文件夹、LocaleConfig、setApplicationLocales()、supportsRtl

自定义本地化基础设施在非常大的规模下才有意义，但它会增加运维开销。先从原生系统开始，只在真正感到痛点时才扩展。

本地化大多数团队容易遗漏的部分

团队经常翻译了可见的句子，却遗漏了围绕它们的产品机制。

复数、变量和语法

复数规则并非通用的。Unicode CLDR 复数规则定义了 zero、one、two、few、many 和 other 等类别，不同语言使用不同的子集。Apple 指出，在较早的 .stringsdict 工作流程中，other 是唯一必需的类别，但跳过特定语言的类别仍然可能产生语法错误的输出。Android 和 iOS 都依赖区域感知的复数处理是有原因的。

这就是简单机器翻译失效的地方：

  • 1 file 和 2 files 在英语中很简单
  • 斯拉夫语系通常需要两种以上的复数形式
  • 一些语言会同时改变名词、动词或周围的词

永远不要通过拼接片段来构建复数化的 UI，比如 "You have " + count + " messages"。请改用平台的复数资源。

以下是每个平台上最基本的实现形式。

Android:

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>
Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

iOS 旧版 .stringsdict 示例：

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

在 Xcode 15 及更高版本中，Apple 建议改在字符串目录中处理复数，但原则不变：给平台一个消息模式，让它选择正确的语言形式。

关于占位符和结构化字符串的更深层工作流程保障，请参阅如何在不破坏代码的情况下翻译技术文档。

日期、数字、货币和单位

Apple 明确建议使用 Foundation API 跨区域格式化日期、长度、重量、价格和货币符号。同样的原则适用于 Android：使用区域感知的 API 格式化数据，而非硬编码标点符号、小数点标记或单位顺序。

典型的失败情况包括：

  • 03/04/2026 在不同地区意味着不同的含义
  • 为非美元市场硬编码美元符号
  • 1,234.56 在使用逗号作为小数分隔符的区域设置中显示不正确
  • 度量单位使用了错误的计量系统

如果你的应用包含日程安排、计费、配送时间窗口或分析功能，这是本地化的一部分，而非锦上添花。

布局扩展和从右到左支持

英语通常比较紧凑。德语会更长。阿拉伯语和希伯来语会反转阅读方向。在英语中看起来正常的布局在其他区域设置中可能严重损坏。

Apple 建议在导入真实翻译之前，先使用伪语言进行测试，包括从右到左伪语言和双倍长度伪语言。Android 建议使用 start 和 end 替代 left 和 right，启用 android:supportsRtl="true"，并在设备上使用 Force RTL 测试 RTL 布局。

你的检查清单很简单：

  • 允许按钮和标签增长
  • 避免对重要 UI 使用固定宽度的文本容器
  • 在适当的地方镜像方向性 UI
  • 在 RTL 模式下验证图标、箭头、进度流程和轮播
  • 测试混合方向文本，如包含拉丁产品名称或优惠码的阿拉伯语 UI

图片、图标、截图和视频

Apple 的本地化指南提出了许多团队忽视的一个重要观点：图片也可以本地化。这包括图像集、符号集和自定义符号的方向性。如果你的截图包含英文 UI、横幅中的英文文本或从左到右的箭头，那么截图本身就没有本地化。

这对引导页面、教程卡片和 App Store 资源尤其重要。用户不会在心理上将”营销视觉”与”产品语言”分开。他们会一次性评判整个体验。

单独本地化你的 App Store 和 Google Play 页面

这是许多团队在完成应用内工作后仍然流失安装量的地方。

需要规划的 App Store 要求

Apple 建议在 App Store Connect 中本地化元数据，包括应用描述、关键词、应用预览和截图。Apple 还表示你可以在产品页面上展示最多 10 张截图，以及每种支持的设备尺寸和语言最多 3 个应用预览。应用预览最长可达 30 秒，当没有预览时截图更加重要，因为前一到三张截图可能会出现在搜索结果中。

这有两个含义：

  1. 你的前几张截图是可发现性资源，而不仅仅是文档。
  2. 你应该为优先市场本地化截图和预览，而不是到处复用英文资源。

需要规划的 Google Play 要求

Google Play 也将应用商店列表本地化视为独立的工作流程。Play Console 允许你添加本地化文本、目标语言截图和本地化图形资源。如果你添加了文本翻译但没有本地化图形资源，Google 表示仍会显示默认语言的视觉素材。

Google 还指出，如果你没有添加自己的应用商店列表翻译，用户可能会看到自动翻译的内容，并附有自动生成的提示。这作为备用方案很有用，但不是强有力的市场进入策略。

一个特别相关的当前功能：Play Console 表示可以使用 Gemini 模型免费持续翻译应用字符串。更具体地说，Google 表示这适用于上传到草稿发布的应用包中 strings.xml 里的应用字符串，你可以在发布前使用内置模拟器预览生成的翻译。这是加快初稿覆盖率的好方法，但对于关键流程仍应进行人工审查。

构建发布和质量保证工作流程

良好的本地化流程更多的是减少发布意外，而非加快翻译速度。

步骤 1. 慎重选择目标区域

不要一开始就”把所有内容翻译成 20 种语言”。

从以下方面入手：

  • 你当前的下载分布
  • 你积极支持的国家
  • 计费、法律和客户支持覆盖范围
  • 你是否能同时本地化应用和应用商店列表

端到端地做好一个市场通常胜过半途而废地做五个市场。

步骤 2. 创建本地化就绪的资源

在翻译开始之前，冻结并准备：

  • 附带上下文的源字符串
  • 按区域划分的截图列表
  • 术语表和产品名称规则
  • 占位符规则
  • 应用商店文案的字符数限制指南
  • 区域特定的审查负责人

如果应用使用单独的代码仓库或多种文件格式，请尽早标准化命名和提取。

步骤 3. 首先使用伪本地化进行测试

在 Apple 平台上，使用双倍长度和从右到左伪语言。在 Android 上，测试不支持的区域设置、Force RTL 和应用语言设置。这可以捕获：

  • 截断的按钮
  • 被裁剪的标题
  • 隐藏的文本
  • 错误的对齐
  • 未本地化的字符串
  • 硬编码的左/右假设

这是你能进行的成本最低的质量保证检查之一。

步骤 4. 在真实设备上进行语言质量保证

翻译完成后：

  • 在每种目标语言中测试关键流程
  • 比较系统语言和应用语言行为
  • 验证复数行为和占位符
  • 检查支付、日期和地址
  • 审查市场中的截图和应用商店列表

如果某个错误影响了引导流程、结账、身份验证或通知，将其视为发布阻断问题。

首次本地化冲刺检查清单

如果这是你第一次认真推进本地化，请将冲刺范围缩小到可以干净利落完成的程度：

  • 选择 1 个目标区域，而不是 10 个。
  • 冻结一个发布分支的源字符串。
  • 导出所有引导、结账、账户和通知字符串，并附带上下文注释。
  • 捕获你想为 App Store 和 Google Play 本地化的截图。
  • 在将真实文本发送给翻译人员之前，进行一次伪本地化检查。
  • 在同一个冲刺中翻译应用字符串和应用商店列表文案。
  • 重新导入翻译并在 iOS 和 Android 上测试应用语言切换。
  • 在真实设备上对前 5 个用户旅程进行质量保证。
  • 为同一区域更新截图、应用预览和应用商店元数据。
  • 先发布到 TestFlight 或内部测试渠道，然后关注客服工单和崩溃报告。

这个检查清单故意很窄。一个具有干净应用体验和同步商店资源的区域，能教会你的东西远比仓促发布多个市场要多得多。

真实案例

以上核心理念并非理论空谈。

DoorDash 将翻译视为平台问题

2022 年，DoorDash 表示已经跨四种语言翻译了超过一百万个字符串，并将新语言上线从数小时的开发工作缩减到一分钟内的一条命令。有趣的启示不仅仅是规模，而是结构：DoorDash 将静态和动态字符串分离，添加了术语表和风格指南支持，并构建了防止未翻译字符串漏出的保障机制。

在 2026 年 2 月 2 日的一篇博客文章中，DoorDash 表示其重建的入职平台现在为所有 DoorDash 市场的注册提供支持，并支持通过无缝本地化快速进行国际扩展。这正是成熟本地化的样子：可复用的工作流程、区域灵活性和更少的一次性临时方案。

Meta 将本地化视为语言问题和应用体积问题

Meta 表示大约 57% 的 Facebook Android 用户和 49% 的 Facebook iOS 用户使用非英语语言。在同一篇文章中，Meta 表示移除捆绑的翻译文件在 iOS 应用中节省了多达 16.6 MB，并允许 Android 在不增加应用体积的情况下额外添加近十几种语言。

即使对于较小的团队，这一启示也很有用：本地化具有工程层面的影响。它影响二进制文件大小、运行时加载、翻译交付和发布机制，而不仅仅是文案撰写。

发布前的最终检查清单

将此作为最后一道检查：

  • 所有面向用户的字符串都已外部化。
  • 默认备用资源是完整的。
  • 复数和占位符使用平台原生的本地化支持。
  • 日期、时间、数字、货币和单位是区域感知的。
  • RTL 布局和混合方向文本已经过测试。
  • 应用商店列表文本已针对目标市场本地化。
  • 截图和预览已针对优先语言本地化。
  • 应用内语言选择在 iOS 和 Android 上按预期工作。
  • 语言质量保证已覆盖最重要的用户旅程。

结语

理解移动应用本地化最简单的方式是：翻译产品，本地化体验，测试发布。

如果你是第一次做这件事，不要在第一天就追求完美的全球覆盖。选择一到两个战略性区域，同时本地化应用和商店页面，进行认真的质量保证检查，并从真实使用中学习。如果你已经在管理资源文件和面向开发者的内容，可以将此工作流程与如何在不破坏代码的情况下翻译技术文档和 2026 年最佳 JSON 翻译工具结合使用。

如果本周你只能做一件事，那就是：选择 1 个区域，运行 1 次伪本地化检查，并本地化 1 个对应的 App Store 或 Google Play 列表。这个三步测试会比同时翻译二十个区域告诉你更多关于你准备程度的信息。

如果你需要快速初稿来处理应用文案、截图或结构化语言文件，可以使用自动化工具加速草稿，然后在发布前保留人工质量保证环节。这才是保护用户信任、防止”已翻译但未真正本地化”的发布的关键。

参考资料

Tags

i18n how to
分享这篇文章：
在 X 上分享这篇文章 在 Facebook 上分享这篇文章 通过 WhatsApp 分享这篇文章

Related Posts

如何翻译出生证明

如何翻译出生证明

一份关于出生证明翻译的分步指南，适用于移民、签证申请和法律用途，包括各国认证翻译要求以及常见被拒原因。

2026/3/6
如何翻译文凭

如何翻译文凭

需要用于移民、大学或海外工作认证的毕业证书翻译吗？以下是关于认证、公证和加签（Apostille）的操作方式，以及各国的具体规定和避免被拒的实用建议。

2026/1/25
如何翻译CSV文件

如何翻译CSV文件

学习如何在线翻译CSV文件，同时确保不破坏列、编码、ID或特殊字符。内容包括分步工作流程、质量检查清单以及故障排除方法。

2026/1/9