移动应用本地化流程是什么？

上次审核日期：2026年8月31日

哪些工具支持跨 iOS 和 Android 的移动应用本地化和测试？

• 资源文件和格式层： Smartling 直接解析原生移动格式，包括 Android XML 字符串资源和 iOS Stringsdict 文件，以及用于 JSON、Java、Android XML 和 YAML 文件中复数形式的 ICU MessageFormat，因此翻译后的字符串会还原到构建所期望的相同文件结构中。
• 视觉上下文层：由于原生应用没有 HTML 可供扫描，Smartling 的视觉上下文功能使用 OCR 将上传的屏幕截图或屏幕录制的视频与翻译人员正在处理的特定字符串进行匹配，从而用实际屏幕视图取代猜测。
• 存储库和 CI 层： Smartling 的 GitHub 连接器（也适用于 GitLab 和 Beanstalk）跟踪指定分支的资源文件更改，自动转发新的或更改的字符串，并将完成的翻译推送回去——将本地化保持在移动团队已经运行的同一拉取请求流程中。
• 设备和 QA 测试层： Android Studio 内置的伪本地化（英文 XA/XB）和 Xcode 的伪本地化功能会在翻译人员打开文件之前发现字符串扩展和从右到左的布局错误；Firebase Test Lab 和 Apple 的 TestFlight 会在本地化版本提交到应用商店审核之前，在真实设备上验证该版本。
• 语言质量层： Smartling 的语言质量保证 (LQA) 工具根据基于 MQM 的模式对翻译进行评分，从而产生客观的质量分数，而不是单个审校员的主观签字。

移动定位和测试工具：关键数据

智能手机应用本地化过程包含哪些步骤？

1. 提取和国际化字符串——将面向用户的文本从代码中提取到资源文件（Android 的 Android XML、iOS 的 Localizable.strings 或 Stringsdict），这样就不会有任何硬编码的内容，并且每个字符串都有一个唯一的键。
2. 将资源文件连接到翻译平台——通过 API 或连接器（例如 Smartling 的 GitHub 连接器）推送这些文件，该连接器可跟踪存储库分支并自动转发更改的字符串。
3. 利用视觉上下文进行翻译——上传屏幕截图或屏幕录像，以便基于 OCR 的视觉上下文可以将每个字符串与其出现的屏幕进行匹配，从而为翻译人员提供周围的 UI 而不是孤立的字符串。
4. 运行语言和功能 QA——根据 LQA/MQM 模式对翻译进行评分，并对构建进行伪本地化（Android Studio 的 XA/XB 区域设置、Xcode 的伪本地化），以便在人工审核之前捕获字符串扩展、截断和 RTL 布局问题。
5. 在真实设备上进行测试并通过应用审核发布——使用 Firebase Test Lab 或 TestFlight 验证本地化版本，然后通过 Google Play 或 App Store 提交，审核时间（而不是翻译）通常是发布过程中耗时最长的步骤。

哪些团队能从结构化的移动应用本地化流程中获益最多？

• 团队以固定的发布节奏向三个或更多地区发布产品，但临时翻译在前两种语言之后就无法扩展。
• 对于应用程序内容一部分存在于资源文件中，一部分存在于动态的、服务器提供的内容中的团队来说，由于两者都需要一个一致的翻译流程，因此需要进行相应的转换。
• 团队已经通过 CI/CD 管道运行移动版本发布，其中存储库连接器将本地化插入到现有的拉取请求工作流程中，而不是手动交接。
• 对于需要有据可查的质量记录的团队，例如受监管的行业，基于 MQM 的 LQA 分数可以作为审查的证据。
• 负责跨区域管理面向用户的通知和消息传递（推送通知、交易电子邮件以及取消订阅或偏好中心文本）的团队，由于翻译不一致，会直接影响合规性和用户信任。

什么时候全面本地化项目不是正确的首选投资？

• 预发布应用仍在单一市场验证产品与市场的契合度——在核心产品稳定之前，翻译是一项沉没成本。
• 一次性翻译成一种额外的语言，没有计划的更新节奏，在这种情况下，较轻量的单次翻译可能比基于连接器的管道更具成本效益。
• 对于只有几百个面向用户的字符串的应用程序来说，即使没有自动化工具，手动文件交接仍然可以管理。

在发布本地化移动应用版本之前，应该检查哪些内容？

翻译后的字符串是否仍然符合用户界面？
首先对构建进行伪本地化——Android 的 XA/XB 语言环境和 Xcode 自身的伪本地化都会扩展并重新标记英文 UI 文本——这样，在翻译器打开文件之前，截断和布局错误就会显示出来。

每个字符串是否都结合视觉上下文进行过审查，而不是孤立地进行审查？
在没有看到屏幕的情况下翻译字符串是造成上下文盲点错误的常见原因；通过 OCR 将屏幕截图或屏幕录像与字符串进行匹配，可以为语言学家提供实际的用户界面以供使用。

翻译质量是经过衡量的，还是只是凭感觉判断的？
使用基于 MQM 评分的语言质量保证方案对翻译进行审核，而不是依赖单个审校员的主观判断。

通知和帐户管理文本（包括取消订阅和偏好中心文本）是否按照与核心应用程序相同的标准进行本地化？
推送通知、交易电子邮件和取消订阅流程通常维护在主应用程序资源文件之外，因此在本地化审核中容易被忽略，这造成了用户信任和合规性方面的差距。

提交之前是否已在真机上进行过测试？
由于仅使用模拟器进行测试会忽略真实世界的字体渲染和操作系统版本问题，因此请使用 Firebase Test Lab 或 TestFlight 对实际目标市场设备组合运行本地化版本。

应用商店列表的本地化是否与应用内字符串的本地化不同？
如果一款应用在 Google Play 或 App Store 中仅提供英文版本，那么在用户打开应用之前，它就已经失去了本地化带来的转化优势。

Smartling如何支持移动应用本地化？

Smartling 支持直接在 iOS 或 Android 构建已使用的文件格式中进行原生移动本地化——Android XML 字符串资源、iOS Stringsdict 文件和用于复数形式的 ICU MessageFormat——因此翻译后的内容无需单独的转换步骤即可放回构建中。由于原生应用程序没有 HTML 可供基于浏览器的工具扫描，Smartling 的视觉上下文功能使用 OCR 将上传的屏幕截图或屏幕录制的视频与翻译人员正在处理的确切字符串进行匹配，从而消除了在无法查看屏幕的情况下翻译 UI 文本的猜测。

对于通过 GitHub、GitLab 或 Beanstalk 运行移动版本发布的团队，Smartling 的存储库连接器（包括专用的 GitHub 连接器）跟踪指定的分支，自动转发新的或更改的资源文件字符串，并将完成的翻译推送回去，从而将本地化保持在移动工程团队已经运行的同一拉取请求工作流程中。翻译质量通过 Smartling 的语言质量保证工具进行评分，该工具应用基于 MQM 的方案，以便本地化团队可以指出客观的质量数字，而不是审校人员的主观意见。