设计

本地化

更新时间: 2025年1月13日

应用本地化不仅通过翻译文本和语音内容来帮助吸引全球受众，还更新设计元素，确保用户以期望的方式享受应用。这个过程确实需要投入时间和资源，但它是值得推荐的，因为它能大大提高为应用找到全球新买家的可能性。

如何为本地化规划和设计应用

为了在本地化过程中节省时间和资源，设计和开发时就应考虑到应用翻译，以及与更广泛受众分享的问题。请参阅下文，了解在构建 Alpha 之前的计划和开发过程中的一系列最佳实践。

准备字符串文件

本地化需要一个双语文件导向的过程，这就是字符串文件对该过程的成功和效率如此重要的原因。该字符串文件应包含构成本地化内容的所有应用内内容字符串。在规划和构建时，请牢记以下几点，以实现最大效率。

在团队中指定一个联系人，负责本地化的规划和执行。

利用一个主文件管理所有应用内内容。

将字符串外部化，以便为翻译做好准备。不要硬编码任何文本。

确保字符串文件与本地化工具兼容。XLS、PO、JSON、XML、CSV 广泛接受为行业标准。

为每个字符串分配唯一的字符串 ID/键，即使相同的源文本在应用程序的不同区域使用也要如此。这将简化将单个词翻译成多种语言的过程，并在需要不同文本布局时增加灵活性。

确保字符串 ID 是静态的，在导出过程中不会更改。新字符串 ID 会被本地化工具标记和审核，这导致了不必要的工作和额外的翻译成本。

避免在字符串中提及任何特定平台。如有必要，为所有平台特定文本添加变体字符串，并记得相应地修改/删除这些内容。

添加针对本地化过程的开发者备注，以确保语言学家准确翻译每个部分。提供文本/字符串用途的上下文，澄清词性（动词、名词等），澄清特定场景中的讲话者，特别关注复杂的措辞或双关语的使用等。

请参阅下面的示例 XLS 文件，该文件格式已为本地化进行过调整。

string_ID	中文	开发者备注
mainmenu_start_button	开始	开始游戏的用户界面按钮
mainmenu_credits_button	点数	查看游戏点数的主要菜单
scene_1_cutscene_char1_1	嘿，醒醒！	对话，字符上限：15
scene_2_objective_name_record	记录	动词目标名称：使用录音机记录对话

构建本地化准备好的用户界面

设计和开发灵活、易于调整大小的用户界面将大大节省本地化时间。与英语相比，许多其他语言的句子和单词在视觉长度上通常要长 2 到 3 倍，而某些语言需要更高的布局来容纳额外的重音符号和笔画字符。更多确保用户界面做好本地化准备的方法，请参阅下文：

启用响应式布局，以适应可能因不同语言字符类型而发生的变化。这包括文本框、按钮和文本的自动调整大小。

支持水平滚动的字幕带框，作为解决文字换行挑战的一种方案。

在翻译文件中集成富文本标签，用于换行符和不换行标签（例如 <br>，<nbsp>）。这将简化换行的本地化过程，特别是在那些单词之间使用最小间距的语言中。

记录所有包含文本嵌入布局中的视觉资产，以更有效地规划本地化过程。

如果布局只为特定数量的字符留有足够的空间，请务必在开发者备注中记录该应用部分的最大字符数。

在启动本地化过程之前，务必对字符串进行全面审核。删除不需要翻译的过时字符串，并修正任何拼写、语法和标点错误，以进一步优化本地化过程。

避免使用国旗来代表语言，因为一种语言可以在全球多个地区使用。

在应用中管理语言支持

虽然 Quest 应用支持 25 种语言⁠，但仍然可以针对特定语言进行调整。如果用户设备语言与应用程序的语言环境匹配，应用内语言应根据用户设备语言来提供。在运行时使用 Meta Quest 平台 SDK 或原生 Android 方法检测语言环境对象，然后使用该对象来确定向特定用户发送哪个本地化版本的应用程序。有关如何获取用户语言环境的更多信息，请参阅以下文档页面。

强烈建议在应用中设置自定义语言选择器，以便用户可以选择偏好语言。如果没有计划支持用户的设备语言，则应用必须默认以英语加载。有关其他需要注意的要求，请查看 Quest 虚拟现实检查 (VRC) 指南。

在管理本地化文件时，请务必考虑使用语言包，因为这可以减少应用的安装大小。

国际语言支持的字体

默认情况下，许多游戏引擎和框架无法正确渲染非拉丁字符，而是将其显示为块（通常被称为“豆腐块”）。要渲染非拉丁语言，必须包含这些语言的字体。

使用 Unity 默认字体 Liberation Sans 显示的韩文文本。由于在 Liberation Sans 字体中未找到韩文字形，因此它显示为方块。

使用支持韩文符号的 Noto-Sans 字体正确显示的韩文文本。

为了确保本地化内容与应用的既定外观和感觉一致，请研究并实施符合原始风格的字体。有许多可用的免费字体，以及可用于商业用途的授权字体。

Unity：将字体文件导入 Unity，然后创建一个 Text Mesh Pro 资产。默认情况下，Atlas 填充模式设置为动态。不要担心巨大的纹理规格，因为每个符号的纹理将在运行时生成。例如，如果使用静态纹理图像处理具有复杂笔画和变化的亚洲语言，如中文和日文，可能会超过数百兆字节。然而，通过动态纹理，纹理规格可以减少到仅为 10KB。

如果使用静态纹理，对于具有数千个字符的多字节语言，将每个可能的字符都包含在图像中是不可行的。因此，最常见的做法是扫描文本以生成一个包含在字符串文件中的字符库，并生成仅包含这些字符的图像。

虚幻引擎和其他第三方引擎：对于大多数游戏引擎，文本打印方法通常是完全自定义的过程。请尽量保持灵活性，并提供多种支持的字体。

要测试新字体，请部署一个包含随机翻译文本的编译版本。请注意，许多字体与亚洲语言或西里尔字母语言不兼容，因此如果这些语言在应用的目标市场中较为常见，请务必在这些语言环境下测试应用。请记住，未支持的字符（字形）在部署测试编译版本时将不会显示，或者仅以方块的形式出现。

执行本地化处理

为确保本地化过程顺利高效，请在推进应用本地化时遵循以下最佳实践和注意事项。

将本地化纳入发布流程，并进行相应规划。翻译和测试应用可能需要数周或数月时间，具体取决于字数、测试和漏洞的复杂性。但是，如果在开始工作前就锁定内容，将有助于本地化团队提供准确的时间表和成本预估，从而确保该过程相对简单、无忧。无论是先以英语发布应用、随后再发布本地化版本，还是同时以多种语言发布应用（即同时发布），情况都是如此。

以下是本地化过程的步骤快照：

锁定字符串文件

翻译应用内和商店内容

审查和测试翻译内容

修复本地化问题和错误

提交以供商店审核

版本控制和更改管理

不可避免要进行应用更新、漏洞修复等操作，但在启动本地化之前请锁定内容（即字符串锁定），并避免在本地化完成之前进行更改。如果在本地化过程中需要进行设计/编译版本更改，应依赖版本控制，因为在本地化过程中不断添加更新时，沟通和构建管理可能变得特别具有挑战性。

应用内内容翻译：字符串锁的重要性

为了启动本地化工作，需要将所有待翻译的字符串收集到一个字符串文件中。在将此文件发送给翻译团队（无论是内部团队还是外部团队）时，请确保这些文件在初步本地化工作完成之前是锁定的。如果在本地化工作开始后对字符串进行了任何更改，则需要发送更新后的字符串文件，并要求翻译团队进行这些额外的更改，这将导致额外的工作量和成本。如果没有告知质量保证团队这些更改，或者他们测试的是过时版本，这还可能给测试过程带来混淆。因此，强烈建议遵守字符串锁定的规定。

翻译并上传 Meta Horizon 商店内容

Meta Horizon 开发者面板支持 TSV 文件的导入和导出，以便于批量本地化。填写英文商店元数据，然后点击批量本地化，获取本地化商店内容的推荐步骤。然后，通过点击弹出模态窗口中的下载 TSV 导出 TSV 文件，将其发送给翻译团队。

Bulk localization overlay within Developer Dashboard

所需 Meta Horizon Store 元数据参阅下文：

应用名称：最多 40 个字符

应用简短描述：最多 500 个字符

应用详细描述：最多 1,000 个字符

搜索关键词：每个关键词最多 50 个字符，最多 5 个关键词（可选但推荐）。关键词中不允许有空格。

如何构建关键词，请查阅应用名称和资产最佳实践，以及商店提交成功指南

注意：应用名称本地化及其推荐原因

本地化应用名称有助于使国际用户感到亲切和贴近。西方国家/地区的用户通常英语水平较高，而东方国家/地区的用户往往会误解某些标题的意图，有些用户甚至可能会在可读性上遇到困难。通过本地化的应用名称，应用将吸引更大的受众。

大家应该注意到，大多数电影制片厂会翻译或音译他们的电影标题。音译是指将一个字母表的字母转换为听起来类似的另一个字母表的字母。例如，希伯来语单词 חנוכה 可以音译为英语中的 Hanukkah 或 Chanukah。对于原本以英文开发的应用，我们通常会看到在面向东方语言市场时，更倾向于使用音译的应用标题，而面向西方语言市场时，由于英语普及率较高，则往往推荐使用原始的英文标题。在决定如何在这些本地地区推广新 IP 之前，请向本地化团队征求建议。对于亚洲语言中的非本地化标题，请在应用管理工具中为应用添加音译标题作为搜索关键词，以便在搜索结果中显示该应用。

审核并测试本地化内容

翻译团队依赖英文源文本和开发者备注来确保翻译的准确性，但这有其局限性，因为语言学家通常无法查看完整的应用体验（用户界面设计、叙事上下文等）。他们可能很难理解字符串文件中每个字符串之间的联系，并且在此过程中可能会出现错误，例如翻译没有按预期显示、缺乏对特殊字符的支持，以及翻译文本与用户界面重叠。这正是需要针对本地化进行专门质量保证测试的地方。这一过程通常被称为本地化质量保证 (LQA)，传统上包括专业的双语质量保证测试人员来审查本地化版本，从而使这些更新得以改进，并且以更高的效率解决本地化特定问题。

以下为 LQA 测试中发现的常见用户界面错误：

为了准备 LQA 测试，将翻译后的字符串文件与 LQA 团队共享，并附上所有与翻译团队共享的其他材料。部署包含最新翻译的新编译版本，并将 LQA 团队添加到编译版本渠道。确保 LQA 测试计划包括了测试应用本地化元素的最有效路径。例如，引导他们跳过不受本地化过程影响的特定区域，并确保所有包含翻译重点更新的区域都被触发。同时，请务必提供一个调试工具，以便他们能够跳过应用中没有本地化设计更改或翻译文本的部分。

在结束本地化质量保证阶段之前，部署一个已解决本地化错误的新版本，并让 LQA 团队验证这些更新。重复这一过程，直到 LQA 团队批准新本地化编译版本的整体质量，无任何重大未解决的问题，才能提交应用获得商店批准。