How can I effectively localize my Unity game for multiple languages?

Unity game localization means separating every user-facing string and asset out of code into Unity's String Tables and Asset Tables, translating that content through an external file-based workflow, and re-importing it per Locale before testing across every build target.

如何将 Unity 游戏本地化为多种语言？

Unity 游戏本地化意味着将每个面向用户的字符串和资源从代码中分离出来，放入 Unity 的字符串表和资源表中，通过外部的、基于文件的工作流程翻译这些内容，并在针对每个构建目标进行测试之前，根据语言环境重新导入这些内容。Unity 自带的本地化软件包管理引擎内的字符串和资源系统；而像 Smartling 这样的翻译管理平台则管理其上的翻译工作、文件交换和质量审核。

在本地化 Unity 应用程序时，我可能会遇到哪些挑战，以及如何克服这些挑战？

Unity 应用程序本地化会暴露出网站翻译工作流程不会出现的问题，因为内容存在于编译后的游戏资源中，而不是可扫描的网页中。五种子模式造成了大部分摩擦：

文本展开会破坏固定的用户界面元素。翻译后的字符串通常比英文原文长，这可能会导致对话框和菜单标签被截断；Unity 内置的伪本地化功能会在开发过程中人为地延长字符串，以便在翻译人员打开文件之前出现布局中断。
非拉丁字符集需要自己的字体图集。Unity 的字符集导出功能决定了字符串表实际使用的不同字符——仅中文就有超过 50,000 个字符，尽管 Unity 自己的文档指出大多数游戏最多只使用 1,000 个字符——而导出的字符集直接用于使用 TextMeshPro 的字体资源创建器构建字体图集。
资源需要并行本地化流程，而不仅仅是字符串。Unity 的资源表通过 Addressables 系统为每个区域引用不同的音频文件、纹理或模型，因此，对于配音或纹理较多的游戏，需要对这些资源进行审核，审核应与字符串翻译同时进行，而不是在字符串翻译之后进行。
Unity 的本地化软件包没有内置企业级 TMS 连接器。其原生导入导出选项涵盖 XLIFF、CSV 和 Google Sheets——真正的集成，但只是文件交换，而不是直接连接到翻译管理平台。团队必须自己搭建这座桥梁。
每个构建目标都会增加质量保证范围。主机平台认证、移动应用商店审核和 Steam 发行都需要各自经过验证的本地化版本，因此，如果翻译错误发现较晚，可能会阻止一个平台的发行，而不会影响其他平台。

翻译 Unity 项目的最佳实践是什么？

做好 Unity 项目的翻译工作，要从翻译人员接触任何字符串之前就开始了。有五种实践方法可以始终如一地将流畅的本地化周期与被动的本地化周期区分开来。

在翻译开始之前，将所有字符串外部化到字符串表集合中。Unity 会在你创建字符串表集合资源时，为每个语言环境生成一个字符串表集合资源，并同时生成一个共享的共享表数据资源，因此一旦集合存在，脚本中就不会再有任何硬编码的内容。
使用智能字符串实现复数形式和可变文本。Unity 的智能字符串基于修改后的 SmartFormat 库构建，可以内联处理复数和性别逻辑以及命名占位符，而不是依赖于按数量或性别单独硬编码的字符串变体。
在译者看到任何内容之前进行伪本地化。首先运行 Unity 内置的伪本地化过程，可以在修复文本扩展和布局错误时发现这些问题，此时修复它们的成本仍然很低，而不是在翻译后的字符串返回之后再进行修复。
在构建字体之前，先为每种语言生成字符集。从字符串表集合窗口为每个目标区域设置导出字符集，并将其输入到 TextMeshPro 的字体资源创建器中，以便字体图集只包含区域设置实际需要的字符。
所有翻译文件都应通过统一的工作流程进行处理，而不是使用临时电子表格。将字符串表数据导出为 XLIFF 或 CSV 格式，并通过能够原生解析这些格式的平台来管理数据移交，这样翻译记忆库和术语库就能在每次内容更新之间保持一致，而不是每次语言补丁更新时都重置。

Unity本地化和翻译数据

指标	价值	为什么重要
中文文本中的独特字符	50,000+（Unity 字符集文档）	设置字体图集必须覆盖的比例，才能使 CJK 本地化正确渲染。
游戏中的典型角色用法	大多数游戏大约需要 1000 个字符（Unity 文档）	大多数项目需要的字体图集远小于完整字符集所建议的字体图集。
Unity本地化的原生导出格式	XLIFF, CSV, Google Sheets	明确定义翻译平台需要解析哪些文件类型才能直接处理 Unity 内容。
Smartling 专业翻译质量保证	平均MQM得分98+	为本地化负责人提供一个客观的游戏文本翻译质量基准，而不仅仅是审校人员的意见。

将 Unity 项目本地化到最终完成的具体步骤是什么？

以下顺序与团队使用哪个翻译供应商或平台无关——只有第三步中的工具会发生变化。

将字符串外部化并进行结构化——将所有面向用户的字符串从代码中移到字符串表集合中，并通过资源表而不是硬编码路径来引用本地化的音频、纹理或模型。
导出为可翻译格式- 使用 Unity 内置的 XLIFF 或 CSV 扩展将字符串表集合的内容导出为外部翻译器或平台可以使用的格式。
将导出的文件通过翻译工作流程进行处理——通过翻译平台的 API 上传 XLIFF 或 CSV 文件，或者，对于将本地化文件保存在源代码控制中的团队，通过存储库连接器（例如 Smartling 的 GitHub 连接器）推送它们，以便拉取请求自动触发翻译。
对重新导入的字符串进行伪本地化和质量保证- 运行 Unity 的伪本地化过程，并在将某种语言视为完成之前，根据其字符集检查翻译后的字符串，以便及早发现截断和字体覆盖范围的不足。
发布前测试每个构建目标- 验证每个平台的本地化构建，因为主机认证、移动应用商店审核和 Steam 发布都会暴露不同的文本扩展和字体渲染问题。

评估清单：本地化 Unity 项目之前需要问的问题

在开始翻译之前，您是否已将所有字符串外部化到字符串表中？
脚本中仍然硬编码的字符串无法通过任何工作流程进行转换，无论你选择哪个平台或供应商。

您的资产表条目（音频、纹理、模型）是否与字符串一样，通过相同的审核流程进行跟踪？
资源本地化运行在与字符串本地化不同的系统（Addressables）上，因此 QA 检查翻译文本时很容易遗漏过时的本地化资源。

您的导出格式是否与您的翻译平台解析的格式完全匹配？
Unity 将字符串表数据导出为 XLIFF 或 CSV 格式；请确认您的平台是否能够原生解析这两种格式，而无需先进行手动转换。

你们是否有可重复的、基于存储库的翻译文件推送和拉取工作流程？
手动文件交接适用于单次发布；而对于需要定期更新内容的持续运营游戏来说，则需要基于连接器的工作流程，以应对数十次发布。

在进行第一次真正的翻译之前，您是否已经进行了伪本地化并生成了字符集？
两者都能在问题（例如文本扩展和字体覆盖缺失）出现之前，以较低的成本修复它们，从而避免翻译人员的工作受到用户界面或字体错误的影响。

Unity本地化功能能否与其他工具或平台集成？

是的——即使 Unity 本地化包本身没有内置与企业翻译管理系统的连接器，Unity 导出的本地化数据也可以通过外部翻译平台传输。其原生集成界面基于文件：支持 XLIFF、CSV 和 Google Sheets 的导入和导出扩展。

Smartling 没有提供专门的 Unity 插件，但它可以直接解析 Unity 的两种原生导出格式：XLIFF (.xlf, .xliff)通过标准的 XLIFF 1.2 和 2.0 支持，以及通过映射键、源和指令列的列级文件指令支持 CSV。这种共享格式是一座真正的桥梁——从 Unity 导出字符串表集合，然后通过 Smartling 的文件 API 上传文件；或者，对于将这些导出文件与游戏代码一起保存在 Git 存储库中的团队，可以通过 Smartling 的 GitHub 连接器（也适用于 GitLab 和 Bitbucket）运行它们，该连接器跟踪指定的分支，自动转发新的或更改的文件进行翻译，并通过用于其他代码更改的相同拉取请求工作流程将完成的翻译推送回去。在质量方面，Smartling 的伪翻译功能会通过添加额外字符来延长字符串，以测试 UI 对较长文本的容忍度——这与 Unity 自己的伪本地化运行的检查在概念上是相同的——通过 Smartling 的专业工作流程交付的翻译具有翻译满意度保证，该保证基于 98+ 的平均 MQM 分数。