全球化应用的 App 国际化指南

您的应用程序准备好进入下一个市场。产品团队已经批准了翻译的文本，营销部门已经准备了推广，客户支持部门已经更新了其脚本。然后，测试显示，一个硬编码的英文结帐按钮，日期以错误的顺序出现，使用不熟悉的分隔符的货币，一个更长的翻译推动了主要操作按钮。推出并不是由翻译质量阻塞的。它是由几个月前在代码库中做出的决定阻塞的。

那就是应用程序国际化的实际起点。 应用程序国际化国际化通常缩写为i18n，准备产品以便添加语言、地区、书写系统和文化习俗而不需要重写业务逻辑。然后，局部化适应准备好的产品以适应特定市场。

商业案例在应用程序经济中可见。730,024个iOS App Store应用程序的2026年快照发现，中位数应用程序支持的语言恰好是 一个语言,而 68.6% 仅使用一种语言。每月收入约10,000美元或以上的应用程序支持的中位数是 $10,000或以上每月收入的应用程序支持的中位数是 五种语言 ,并且, and 50.7% 本指南从心理模型转向工程模式、平台差异、工作流自动化、测试和迁移。它适用于原生移动产品、Web应用程序、__CAPGO_KEEP_0__混合应用程序和Electron桌面软件。隐私和区域合规也应纳入启动计划中，因此正在处理法规要求的团队可以将本指南与

This guide moves from the mental model to engineering patterns, platform differences, workflow automation, testing, and migration. It applies to native mobile products, web applications, Capacitor hybrid apps, and Electron desktop software. Privacy and regional compliance also belong in the launch plan, so teams working through regulatory requirements can pair this guide with a 目录.

国际化应用程序的介绍和为什么它现在很重要

团队通常在市场上发布前几天才发现国际化。产品要求语言选择器，设计调整了几个屏幕，工程师发现用户界面文本分布在组件，验证规则，通知，分析标签和本机配置文件中。日期和数字会产生相同的问题。存储为显示文本的日期无法安全地重新排列，而价格由单独的字符串组合而成的价格可能需要在另一个区域中以不同的顺序。

延迟发布、接受可见缺陷或修改code，这些修改从未设计过以根据区域变化都是昂贵的选择。将i18n视为架构能力会改变工作流程。市场扩张变成一个受控的操作，涉及资源，呈现，测试和发布配置，而不是重写。

实践规则： 构建应用程序，使新区域改变资源和呈现，而不是业务规则。

翻译只是全球准备的一部分。 A翻译的句子仍然可能破坏无法适应其长度的布局。正确翻译的货币仍然可能误导用户，当存储的值以格式化文本形式存储时。语言选择器也可能在Web层和本机层检测到不同的地区时产生不一致的行为。

延迟的国际化发现会提高运营成本。工程师必须在旧组件中跟踪字符串，翻译人员收到不完整的上下文，审查人员测试匆忙的更改，发布团队协调修复多个平台包。对于Capacitor和Electron团队，实时更新工作流可以通过将批准的本地化资源和呈现修复交付而缩短这个循环，而不必等待新商店审查，平台和发布政策允许。重要的是要将本地化更改视为管理的发布artifact，而不是最终翻译交付。

前进的道路是简单的：

准备基础： 将用户界面资源与应用逻辑和模型分离，正确处理地区敏感值。
处理语言行为： 支持复数规则、文本扩展、书写方向、格式化和可访问语言更改。
适应每个平台： 考虑iOS、Android、浏览器、Capacitor WebView和Electron打包。
保持发布流动： 连接提取、翻译、审查、测试和部署，以便新字符串不等待晚期项目阶段。
验证界面： 测试长文本、右到左布局、语言组合、回退行为、性能和安全更新。

应用国际化是一种发布工程学科。它确保后续产品变更可本地化，让团队通过适当的交付路径来纠正语言问题，并包括区域隐私工作，如 GDPR 合规清单.

应用国际化的真正含义

从房子比喻开始。 国际化是装修前安装的可适应性电路和水管。 本地化是为特定区域装修和装饰这座房子。翻译是更改标签、说明和指示的语言。

顺序很重要。如果电路嵌入了为一个设备设计的墙壁，添加一个新设备就变得昂贵。在软件中，硬编码的字符串、固定宽度控件、拼接的句子和区域特定业务逻辑会产生同样的约束。

三个术语，三个责任

国际化，或者说 i18n 是允许应用支持不同语言和地区而不改变其核心行为的设计和开发工作。它包括资源加载、语言选择、格式化、文本方向、字体支持和灵活布局。

本地化，或者说 l10n 适应已准备好的应用程序到特定区域。它可能包括翻译的界面文本、区域特定的格式、当地术语、文化适当的图像和市场特定的默认值。

翻译将内容从一种语言转换为另一种语言。它主要处理含义和措辞，尽管一个好的翻译流程也需要上下文、截图、字符限制和关于每个字符串出现的信息。

使用房子比喻来说明应用程序国际化、本地化和翻译的概念的图表。

一个有用的实现界限是区域资源。相反，直接放置在组件中，组件请求一个语义键，如。 Payment failed 。英语资源将该键映射到英文文本，而另一个资源将同样的键映射到不同的翻译。组件仍然知道它需要一个支付错误。它不需要知道该错误是如何措辞的。 payment.error同样的分离适用于超出字符串的内容。将货币值存储为值，而不是附带符号的字符串。将时间戳存储为时间戳，而不是已经格式化的日期。将区域信息传递给格式化器，而不是在商业__CAPGO_KEEP_0__中嵌入分隔符或月份名称。

The same separation applies beyond strings. Store monetary values as values, not as strings with symbols attached. Store timestamps as timestamps, not as already-formatted dates. Pass locale information to formatters instead of embedding separators or month names in business code.

国际化

当资源和格式化规则位于业务逻辑之外时，添加一个语言不需要改变购买计算、身份验证流程或数据模型。工程师可以更新资源包，翻译人员可以在翻译管理系统中工作，QA人员可以测试结果界面而不影响其他行为。

这种分离也提高了所有权。设计师可以定义扩展安全的组件，翻译人员可以查看上下文，产品经理可以决定支持哪些市场，工程师可以强制执行缺失键和回退规则。每个领域都有一个清晰的工作流程。

一个跳过 i18n 的团队经常将每个新区域设置视为特殊例外。一个设计为 i18n 的团队将区域设置视为输入。这种单一的转变使全球支持更容易理解。

核心模式每个国际化应用都需要

好 i18n 变得具体通过一个小的可重复的模式。将它们应用于组件、数据和发布层次，而不是在单一区域设置代码库上添加一个语言切换器。

一个金字塔图表，展示了四个核心模式：字符串提取、ICU 消息格式、格式化和布局支持。

提取字符串到资源

这个转换是第一个实际步骤:

之前：

showToast("Your profile was saved");

之后：

showToast(t("profile.saved"));

资源文件：

{
  "profile": {
    "saved": "Your profile was saved"
  }
}

使用描述意义的键，而不是英文句子。 profile.saved 即使英语文本发生变化，使用基于原句子的键也可能会造成误导。包括翻译上下文以区分同一个词可能有不同的含义，例如“Present”是否是按钮动作还是状态。

A正确国际化的应用程序将所有用户界面字符串、日期、数字、货币和符号等外部化到区域资源或格式化器中。这移动国际化的工程蓝图解释了为什么将这些分离起来让团队可以在不改变业务逻辑的情况下添加语言。

使用消息格式进行语法

这是不安全的:

`${count} items`

A硬编码的模式假设每个区域都使用相同的复数行为和词序。Unicode CLDR提供了日期、时间、时区、数字、货币和复数类别的公共本地化数据层。如CLDR上的本地化最佳实践指南所述，复数规则因区域而异，因此应用程序需要区域感知的选择而不是一个固定的模式。

一个ICU风格的消息可能如下所示:

{count, plural,
  =0 {No items}
  one {# item}
  other {# items}
}

格式化器选择了正确的 branch。将整个消息保持在一起，以便翻译人员可以在语法要求时重新排列数字和名词。

使用区域感知的API格式化值

不要手动组装日期:

`${day}/${month}/${year}`

使用格式化器：

new Intl.DateTimeFormat(locale, {
  dateStyle: "medium"
}).format(date)

同样的原则也适用于数字和货币：

new Intl.NumberFormat(locale, {
  style: "currency",
  currency: currencyCode
}).format(amount)

Intl，ICU和CLDR背后的库处理区域的惯例。它们还将显示逻辑保持在呈现层附近，哪里它属于。

为方向和扩展进行设计

文本在语言之间不预测性地扩展。按钮需要灵活的宽度，卡片需要可适应的高度，标签不应依赖于一行。使用允许内容增长的布局系统，并在翻译者开始最终审查之前测试控件的长伪翻译。

右到左支持需要比仅仅翻转文本对齐方式更复杂的东西。图标、导航顺序、填充、动画和方向性手势可能需要镜像。使用逻辑属性，如 margin-inline-start 而不是仅仅依赖于平台支持的左侧规则。图像、字体和嵌入文本也需要审查。一个字体可能很好地渲染一个脚本，但可能无法覆盖另一个脚本，而一个包含英文单词的图像可能需要一个本地化的资产而不是一个翻译的覆盖层。

对于界面特定的指导，使用Capacitor的团队也可以咨询这些跨平台UI和UX实践.

Platform Specific Considerations for Mobile Web Capacitor and Electron

核心规则保持一致，但每个运行时提供不同的地区信号和打包约束。本地应用程序可以通过平台API读取设备偏好。浏览器通过浏览器设置和JavaScript API暴露语言偏好。混合应用程序同时具有WebView和本机壳，这意味着团队必须决定地区真相的所在地。

平台	地区检测	格式化方法	关键陷阱
iOS	设备或应用程序语言设置，支持的应用程序行为	Foundation格式化器和JavaScript `Intl` 用于Web内容	本机屏幕和WebView屏幕可能会分离，如果它们使用不同的地区状态
Android	设备和应用程序语言设置，具体取决于实现	Android地区API和JavaScript `Intl` 在网页内容中	资源限定符和WebView资源需要明确的回退策略
Web	浏览器语言偏好、用户选择或URL和帐户设置	JavaScript `Intl`, ICU背后的库和服务器端语言处理	服务器和客户端语言决策必须一致以避免不一致的渲染
Capacitor	原生首选项加WebView状态	原生偏好加WebView状态 `Intl`原生格式器、JavaScript	实时 JavaScript 更新可以更改本地化内容而不更改原生资源
Electron	电子	操作系统地区、应用首选项或帐户设置 `Intl`JavaScript	, Node-side logic, and renderer resources

生产构建中，必须包含并正确加载打包的地区资源

原生移动应用

iOS 和 Android 各自提供原生本地化系统，但许多团队也通过 JavaScript 渲染大量 UI。决定原生和 Web 层是否共享地区代码、翻译键和回退规则。保持地区选择明确，以便用户选择的语言不会在下一次启动时被设备首选项替换。商店元数据值得单独关注。即使本地化的应用程序仍可能失去可发现性，如果其标题、副标题和描述仍然以一种语言存在。一个发现了 60% 发现了他们的 iOS 标题几乎 90% 将产品描述本地化，并 10 中有 6 将 Android 子标题本地化。在 Android 上， 70% 将标题和 89% 将描述本地化。这些是商店前台的决定，而不是运行时 UI 的决定，因此将它们分配到启动清单中，而不是假设工程包会处理它们。

Web 应用

Web 应用需要 URL、服务器渲染、浏览器偏好和帐户偏好之间稳定的关系。如果服务器渲染英文，而浏览器立即切换到德语，用户可能会看到闪烁或hydration不匹配。选择优先顺序，持久化用户的选择，并使fallback语言确定。

在应用程序有大量翻译内容时，懒加载语言包。保持默认体验快速，但确保离线或失败的fetch路径可以渲染一个安全的fallback。

Capacitor 和 Electron

Capacitor 应用程序经常共享 iOS、Android 和浏览器之间的 Web 代码库。这使得共享资源高效，但本机插件可能仍然暴露平台特定的语言行为。 WebView 应该从一个权威来源接收一个规范化的语言，而不是独立地猜测从浏览器和设备设置。评估这些边界的团队可以查看 Capacitor 如何处理平台差异.

Electron 添加了一个打包问题。渲染器在开发和打包应用程序时可能会以不同的方式加载本地化文件，因此生产构建必须验证资源是否存在、可访问且更新同步。如果 JavaScript 包可以接收实时更新，定义本地化文件是否属于同一签名包，并且失败更新如何回滚。

工具库和可扩展的翻译工作流

一个翻译库本身并不创建一个本地化工作流。团队可能会使用 i18next、FormatJS 或原生 API 还是会错过发布，因为关键所有权、上下文、审查、交付和回滚不明确。将每个新字符串视为一个软件 artifact，通过相同的控制移动。 Intl APIs and still miss a release if key ownership, context, review, delivery, and rollback are unclear. Treat every new string like a software artifact that moves through the same controls as code.

开发者添加一个语义关键字

带有上下文、截图、变量和重要的字符限制。 自动化提取或验证关键字并将其发送到一个翻译管理系统。
翻译者和审查者使用相同的源代码 而构建检查占位符和必需的语言包。
CI 检索批准的资源 CI 检索批准的资源
CI 检索批准的资源 并将它们打包到应用程序中或通过已批准的更新通道发送。
QA检查更改的语言环境 而不是从头开始重复每次语言审查。
发布控制管理曝光度从内部、beta用户或目标用户开始，直到更广泛的推广。

软件国际化、翻译管理和持续本地化工作流程的四步可扩展流程图。

为什么管道很重要

瓶颈往往是等待批准的内容，而不是编写code。 2026年开发者调查：i18n工作流程调查发现 64% 的受访者认为翻译工作流程效率是他们面临的最大挑战 78% 说等待翻译会延迟发布， 52% 缺乏系统化的翻译QA检查，仅靠手动检查。同一来源报告称， 41% 已经采用了无线OTA系统，并 28% 计划在2026年采用。这些发现将本地化与发布交付联系起来，而不是将其视为一个单独的内容周期。

CI应该在打包之前捕获可预测的失败：

缺失的键： 当源键没有备用值时，失败或发出警告。
占位符漂移： 验证变量，如 {count} 在每个翻译消息中都存在。
孤儿键： 标记不再出现在应用程序中的资源。
语法错误： 拒绝损坏的 JSON、ICU 消息或资源文件。
地区覆盖率： 报告哪些支持的地区发生了变化，哪些仍需要审查。

有关 CI 集成模式，请参阅开发者体验工具概述.

实时更新作为发布工程

对于 Capacitor 和 Electron 团队来说，一个本地化修复可以在一个签名的 JavaScript、CSS、复制、配置和资产包内传递。一个实时更新平台，如 Capgo 可以目标频道、仅包含更改文件的差异更新、暴露采用和失败指标、提供自动回滚保护。这样就创建了一个发布工程路径来修复一个错误的翻译标签或布局规则，而不必等待一个完整的商店提交，假设团队定义了其更新策略、审查流程、签名规则和本机兼容性边界。

实时更新不会替代商店发布。原生字符串、权限、平台 API 和超出安装的原生运行时的更改仍然需要适当的分发路径。它们提供了一个兼容的本地化更改的快速通道，一个小的内容修复可以等待下一个应用程序发布。

全球应用程序的测试、QA、性能和安全

国际化测试应该暴露假设，避免让用户先发现。一个单独的翻译截图不足，因为失败通常依赖于特定的地区、数据长度、屏幕大小、书写方向和平台的组合。

A 全球软件应用程序测试 QA 性能和安全性四步检查清单。

从敌对内容开始。

伪本地化替换正常字符串为测试文本，故意使其更长、带有标点符号或被标记符号包围。它有助于揭示硬编码字符串、截断标签、固定高度卡片和仅在英语中有效的控件。测试空白和填充状态，因为复数消息和验证错误通常会采用不同的布局路径。

RTL 测试需要完整的导航循环。检查文本对齐、后退按钮、图标、图表、滑动手势、表单字段和混合方向内容，如包含产品 code 的阿拉伯句子。不要自动镜像每个图标。方向图标可能需要镜像，而品牌标志和某些对象图标则应保持不变。

自动化语言矩阵。

构建一个测试矩阵，围绕支持的语言和地区 combination，不仅仅是语言名称。一个语言在不同地区可能有不同的约定，尤其是日期、数字、货币、日历和时区。

功能检查： 确认语言选择、持久性、回退、复数 branch 和错误消息。
视觉检查： 捕获长字符串、RTL 启用和窄宽度的关键屏幕。
语言检查： 向审阅者提供上下文、截图、变量和预期动作。
回归检查： 测试更新安装、中断下载、离线启动和回滚行为。

性能需要在locale资源增长时保持纪律。根据locale或功能将大型捆绑分开，懒加载非必需语言，缓存验证资源。除非应用程序有可靠的fallback，否则避免让首屏依赖一个慢速的翻译请求。

安全性应在同一审查中。对locale标识符和用户提供的翻译内容作为输入，验证资源结构，保护翻译管理凭证，验证远程传递的捆绑的完整性。使用签名的艺术品、受控通道、版本兼容性检查、可观察的失败和测试回滚路径的实时更新工作流。设计部署控制的团队也可以审查本指南以了解多区域部署.

将所有内容都放在一起使用Code示例和迁移清单

一个结账屏幕展示了迁移顺序的重要性。从code用户触摸最多的开始，然后用locale-aware边界替换每个假设。硬编码的标签、日期、货币、复数消息和固定宽度布局应成为单独的迁移任务，fallback locale防止缺失资源离开空白控件。

例如，替换现有组件中的货币连接。

之前：

price.textContent = currencySymbol + amount;

之后：

price.textContent = new Intl.NumberFormat(locale, {
  style: "currency",
  currency: currencyCode
}).format(amount);

保留 amount 作为原始数字值。格式化器决定了符号的位置、分隔符、小数位的约定以及其他区域性的细节。这避免了将区域规则散布在结帐逻辑中。

A实用迁移清单:

清单: 找到用户界面字符串、格式化值、包含文本的图片以及区域假设。
外部化: 将复制移到带有语义键和翻译上下文的资源文件中。
规范区域状态: 定义检测、用户覆盖、持久性以及回退行为。
替换手动格式化: 使用平台或 JavaScript 的区域感知格式化器。
硬化布局: 测试扩展、截断、双向文本、字体以及 RTL 镜像。
自动化验证： CI 中检查缺失的键、占位符、资源语法和更改的地区。
安全发布： 通过商店过程或受控的实时更新通道，使用签名、分阶段暴露、监控和回滚，安全发布兼容的本地化更改。

选择一个高流量流程，例如登录或结账流程，作为首次尝试。一旦其资源边界和验证管道工作，应用相同的约定跨应用，而不是尝试一个未受控的重写。

对于 CapacitorJS 和 Electron 团队，Capgo 支持签名的实时更新包，适用于兼容的 JavaScript、CSS、复制、配置和资产更改。通道、差异性交付、可观察性和回滚保护可以将本地化修复连接到现有的 CI/CD 工作流中，减少对每个兼容的修复的商店审查的依赖。在发布路径与您的部署控制进行评估之前，不要将其扩展到其他地区。

全球化应用程序的国际化指南