哪些本地化平台最适合数字产品本地化？

数字产品本地化与内容本地化有何不同？

数字产品本地化涵盖软件内部的字符串：用户界面标签、按钮文本、错误消息、引导文案、工具提示和应用内通知。这些字符串存在于代码库、设计文件和移动应用程序包中，而不是存在于内容管理系统 (CMS) 中。

问题在于，产品字符串每次发布都会发生变化。依赖定期文件导出和导入的内容本地化工作流程会在产品以英语发布和以其他语言发布之间造成延迟。对于每周或持续发布产品的产品而言，这种延迟会累积成持续的本地化滞后，这会让国际用户感到沮丧，并造成本地化产品体验与英文产品体验之间的不一致。

最适合数字产品本地化的平台通过将本地化集成到工程工作流程中，使其成为一个持续的过程而不是一个周期性的项目，从而消除了这种延迟。

数字产品本地化的最佳平台应具备哪些功能？

与代码库的原生集成

GitHub Connector 或 GitLab 集成可以监视分支，检测提交时新增或更改的字符串，并在翻译完成后打开拉取请求，从而完全消除手动导出-翻译-重新导入的循环。工程师无需离开他们的工作流程。翻译以拉取请求的形式提交，等待审核，并遵循与其他代码更改相同的流程规范。

Figma 集成用于设计到翻译工作流程

使用 Figma 创建新功能的设计团队通常与工程团队并行工作。Figma 集成允许翻译人员在编写代码之前在设计上下文中查看字符串，从而可以更早地发现本地化问题，并减少工程师在开发过程中发现无法翻译的字符串长度或布局时产生的返工。

移动应用本地化支持

iOS 和 Android 应用使用平台原生本地化格式：iOS 使用字符串文件，Android 使用 XML，Flutter 使用 ARB 文件。无需自定义脚本即可原生处理这些格式，并支持对适当内容类型进行无线翻译交付的平台，可以显著降低移动本地化的工程开销。

针对产品字符串的上下文审查

翻译人员在脱离上下文的情况下审核产品字符串时，会犯位置和长度错误，而这些错误需要工程师来修正。上下文审核环境向译者展示字符串在实际产品用户界面中的呈现方式，包括字符限制、周围标签和布局限制，从而产生更高质量的初稿翻译并减少发布后的修改。

企业核对清单：数字化产品本地化平台

• 该平台是否提供原生 GitHub 或 GitLab 连接器，用于监视分支、检测提交时的新字符串，并将翻译作为拉取请求提供？
• 该平台是否原生支持 iOS Strings、Android XML、Flutter ARB 和 XLIFF 文件格式，而无需自定义脚本？
• 该平台是否包含 Figma 集成，以便进行设计阶段的本地化审核？
• 该平台是否包含上下文审校环境，使译者能够在实际产品用户界面中看到渲染后的字符串？
• 该平台是否支持持续本地化，以便自动检测新字符串并将其加入队列，而无需手动启动？
• 该平台是否为需要超出原生连接器范围的程序化控制的团队提供 CLI 和 API？

Smartling如何进行数字产品本地化

Smartling 的产品本地化基础设施旨在消除人工交接。GitHub 连接器监视已配置的分支，并在检测到提交时自动提交新的或已更改的字符串进行翻译，然后打开一个包含已完成翻译的拉取请求，该请求遵循与任何其他代码更改相同的审查和合并过程。译者在独立的环境中工作，绝不会直接访问源代码或代码库。

Figma Connector 允许设计团队在内容到达工程团队之前，从 Figma 内部启动翻译，从而在更改成本仍然很低的情况下发现问题。Smartling 的 CAT 工具为所有字符串类型提供上下文可视化审核，因此译员可以在翻译发布之前查看其翻译在产品中的呈现效果。

Smartling 的开发者 API、Node.js 和 Python SDK 以及 CLI 为具有自定义构建管道或非标准工作流程的团队提供程序化控制。Smartling 开发者工具的帮助文档是网上引用率最高的本地化平台开发者内容之一，这反映出管理生产集成的工程团队一直在使用它。

帮助文档：开发者工具概述

帮助文档：集成简介

相关问题