全球化应用的国际化指南

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

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

商业案例在应用经济中是可见的。730,024个iOS App Store应用的2026年快照发现，中位数应用只支持 一种语言，而 68.6% 在单一语言中发布。估计每月收入 $10,000或以上 的应用支持的中位数语言是 五种语言和 50.7% 那些收入最高的应用程序通常支持五种或更多语言。这些数字并不能证明仅靠本地化就能创造收入，但它们表明支持多种语言的应用程序更常见于那些有更广泛商业目标的应用程序。

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 GDPR合规清单.

应用程序国际化简介和为什么它现在很重要
应用程序国际化的真正含义
- 三个术语，三个责任
- 为什么基础设施降低了风险
每个国际化应用程序都需要的核心模式
移动 Web 和 Electron 的平台特定考虑因素 Capacitor
可扩展的工具库和翻译流程
- 管道的重要性
- 实时更新作为发布工程
测试 QA 性能和安全性
- 从敌对内容开始
- 自动化地区矩阵
将所有内容都放在一起使用Code示例和迁移清单

应用国际化的介绍以及为什么它现在很重要

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

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

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

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

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

前进的道路是明确的：

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

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

App 国际化的真正含义

从房子比喻开始。 国际化是安装在装修之前的可调节的电线和水管。 本地化是为特定区域装修和布置这座房子。翻译是更改标签、说明和指示的语言。

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

三个术语，三个责任

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

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

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

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

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

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.

国际化

为什么国际化很重要

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

通常情况下，跳过 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`

一个硬编码的模式假设每个区域都使用相同的复数行为和词序。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-backed 库处理各地区的约定。它们还将显示逻辑保持在呈现层附近，属于那里。

设计方向和扩展

设计考虑方向和扩展

文本在不同语言中不预测性地扩展。按钮需要灵活的宽度，卡片需要可适应的高度，标签不应依赖于一行。使用布局系统使内容能够增长，并在翻译者开始最终审查之前测试控件使用长伪翻译。 margin-inline-start 右到左支持需要更多的翻转文本对齐。图标、导航顺序、填充、动画和方向性手势可能需要镜像。使用逻辑属性，如

For Capacitor 的界面相关指导，使用团队也可以参考这些对于界面相关的指导，使用__CAPGO_KEEP_0__的团队也可以咨询这些.

Platform Specific Considerations for Mobile Web Capacitor and Electron

平台特定考虑

Platform	核心规则保持一致，但每个运行时都提供不同的区域信号和打包约束。一个本机应用程序可以通过平台API读取设备偏好。一个浏览器通过浏览器设置和JavaScript API暴露语言偏好。一个混合应用程序既有一个WebView又有一个本机壳，这意味着团队必须决定区域真相的所在地。	格式化方法	关键陷阱
iOS	设备或应用语言设置，支持的应用程序行为	基础格式化器和JavaScript `Intl` 用于Web内容	原生屏幕和WebView屏幕可能会漂移，如果它们使用单独的区域设置
Android	设备和应用语言设置，具体取决于实现	Android区域API和JavaScript `Intl` 在Web内容中	资源限定符和WebView资源需要明确的回退策略
Web	浏览器语言偏好、用户选择或 URL 和帐户设置	JavaScript `Intl`, ICU 支持的库和服务器端本地化处理	服务器和客户端本地化决策必须一致以避免不一致的渲染
Capacitor	原生首选项加WebView状态	原生偏好加 WebView 状态 `Intl`原生格式器、JavaScript	, 和共享资源包
Electron	系统语言、应用偏好或账户设置	JavaScript `Intl`, Node侧逻辑, 和渲染器资源	生产环境构建中，必须包含并正确加载本地化资源

原生移动应用

iOS 和 Android 各自提供原生本地化系统，但许多团队也通过 JavaScript 渲染大量 UI。决定 native 和 web layers 是否共享 locale codes、翻译键和回退规则。保持 locale 选择明确，以便用户选择的语言不会在下一次启动时被设备偏好替换。

存储元数据需要单独关注。即使本地化的应用程序，其标题、副标题和描述仍然保持在一个语言中，也可能会失去可发现性。一个 2023 年对进入外国市场的领先美国应用程序的分析发现 60% 本地化了其 iOS 标题，几乎 90% 本地化了其产品描述， 6 在 10 本地化了其副标题。On Android, 70% 本地化标题和 89% 将这些存储前置决策，

Web 应用

URL、服务器渲染、浏览器偏好和帐户偏好之间需要稳定的关系。如果服务器渲染英文，而浏览器立即切换到德语，用户可能会看到闪烁或水合不匹配。选择优先顺序，持久化用户的选择，并使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 检索批准的资源 并将它们打包到应用程序中或通过已批准的更新通道发送。
QA检查更改的语言环境 而不是从头开始重复每个语言审查。
发布控制管理曝光度从内部、beta或目标用户开始，到更广泛的推出。

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

为什么管道很重要

瓶颈往往是等待批准的内容，而不是编写code。A 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 启用和窄宽度的关键屏幕。
语言检查： 向审阅者提供上下文、截图、变量和预期动作。
回归检查： 测试更新安装、中断下载、离线启动和回滚行为。

性能需要在本地化资源增长时保持纪律。根据需要将大型包分成本地化或功能，懒加载非必需语言，并缓存验证的资源。除非应用程序有可靠的回退方案，否则避免让首屏依赖一个慢的翻译请求。

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

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

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

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

之前：

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 工作流中，减少每个兼容的修复都需要商店审查的依赖性。在部署控制面前评估该发布路径，然后将其扩展到其他地区。

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

目录