本地化

  • 项目

本指南介绍国际化和本地化背后的概念，并链接到有关如何使用这些概念生成 Xamarin 移动应用程序的说明。

如果要直接跳到本地化 Xamarin 应用的技术详细信息，请从以下特定于平台的操作方法文章之一开始：

i18n 和 L10n

国际化是使代码能够显示不同的语言并调整其显示以适应不同区域设置（如数字和日期格式）的过程。 这也称为全球化。

本地化是接下来的步骤 - 为每个语言创建资源（如字符串和图像），并将它们与国际化应用程序捆绑在一起。

国际化通常缩写为 i18n - 这是 "i" 和 "n" 之间 18 个字母的缩略词。 本地化同样缩短为 L10n – "L" 和 "n" 之间的 10 个字母。

概述

本文介绍了与国际化和本地化相关的概念，以及这些概念如何普遍应用于移动应用开发。 设计和生成应用程序时，之前可能已进行硬编码但必须参数化才能本地化的事情包括：

  • 屏幕布局和文本，
  • 图标、图形和颜色，
  • 视频和声音文件，
  • 动态文本和文本格式（如数字、货币和日期），
  • 从右到左 (RTL) 语言的布局更改，以及
  • 数据排序。

无论应用面向哪些移动平台，这些提示都会帮助你构建高质量的本地化应用。

设计注意事项

构建应用程序以便能够对其内容进行本地化的过程称为国际化。 正确实现国际化不仅仅是允许在运行时 – 加载不同的语言字符串，一个设计良好的应用应该允许根据语言和区域设置（包括图像、声音和视频）更改所有资源，并且可以调整格式和布局，以应对不同大小的字符串。

本部分讨论构建国际化应用程序时要考虑的一些设计注意事项。

布局和字符串长度

中文和日文的字符串可能非常短 - 有时一两个字符就足以作为输入字段的标签。

德文字符串（举例来说）可能非常长；有时英文中的一个相对较短的单词在其他语言中会变得很长 - 要么被裁剪，要么导致布局意外重新流动。

比较 iOS 主屏幕上以英文、德文和日文表示的几个项的字符串长度：

German vs Japanese string length

请注意，英文设置（8 个字符）需要 13 个字符才能进行德文翻译，但日文中只需要 2 个字符。

当标签长度差异很大时，显示标签和输入字段并排的布局很难处理。 通常，标签显示在字段上方的布局更易于本地化，因为屏幕的全宽可用于标签和输入。

一般情况下，如果要构建固定布局（尤其是并排元素），则允许至少比标签和文本所需的英文字符串多 50% 的宽度。 这不会解决每个问题，但会提供在许多情况下可以工作的缓冲区。

输入验证

在编写验证规则时，请注意假设。 可能需要文本字段输入以“需要”至少三个字符（英文）似乎有效，因为一个字母很少具有任何意义。 在中文和日文中，单个字符可能是有效的输入，并且验证消息“至少需要 3 个字符”对于这些语言没有意义。

其他看似简单的任务，如验证电子邮件地址或网站 URL 变得更加复杂，字符并不局限于 ASCII 子集。

考虑到国际化编写验证规则 – 选择限制最少的规则，或编写逻辑，使其对每种语言的工作方式不同。

图像和颜色

并非每个图像都需要根据用户的语言选择进行更改。 许多图标或照片将适合所有用户，不管他们说什么语言。 不过，某些资源可以本地化，例如：

  • 描述人员或特定位置的图像 - 如果应用显示本地人员/位置，则应用可能会感觉与用户更相关。
  • 图标 – 某些图标是文化特定的，可以通过本地化图像来反映本地理解，使应用更易于使用。
  • 颜色 - 一些文化对颜色的理解有所不同 - 红色在一个地区可能意味着警告，而在另一个地区可能意味着好运。 在设计应用时，请与讲母语者核对，以确定是否应该构建一种机制来本地化颜色。

视频和声音

在本地化应用程序时，视频和声音会带来特殊的挑战，因为虽然翻译字符串相对容易，但录制多条配音轨道或视频片段既昂贵又困难。

视频和声音文件的多个副本也可能显著增加应用程序的大小（尤其是在本地化为大量语言或拥有大量媒体文件时）。 你可能会考虑在用户安装应用后仅下载所需的语言资产，但这也可能导致网络速度缓慢而导致用户体验不佳。

通常有多种方法可以解决本地化问题 - 最重要的是事先考虑这些问题，并确保应用程序设计为能够解决这些问题。

日期、时间、数字和货币

如果使用 .NET 格式设置函数，请记得指定区域性，以便正确分析小数分隔符（并避免引发转换异常）。 例如，1.99 和 1,99 都是有效的十进制表示形式，具体取决于区域设置。

当数据来自已知源（即来自你自己的代码或你控制的 Web 服务）时，可以硬编码与格式匹配的区域性标识符，例如将适用于标准英语格式的 InvariantCulture。

double.Parse("1,999.99", CultureInfo.InvariantCulture);

如果数据由应用用户输入，请使用反映其区域设置的 CultureInfo 实例对其进行分析：

double.Parse("1 999,99", CultureInfo.CreateSpecificCulture("fr-FR"));

有关其他信息，请参阅 MSDN 文章分析数值字符串和分析日期和时间字符串。

从右到左 (RTL) 语言

某些语言（例如阿拉伯文、希伯来文和乌尔都文）从右到左读取。 支持这些语言的应用程序应使用适合从右到左阅读器的屏幕设计，例如：

  • 文本应右对齐。
  • 标签应显示在输入字段右侧。
  • 默认按钮放置通常相反。
  • 还应反转使用上下文方向的分层导航轻扫和动画（以及其他导航隐喻和动画）。

iOS 和 Android 都支持从右到左的布局和字体呈现，具有有助于进行上述调整的内置功能。 Xamarin.Forms 当前不会自动支持 RTL 呈现。

排序

不同的语言以不同的方式定义其字母的排序顺序，即使它们使用相同的字符集也是如此。

有关语言 (CultureInfo) 影响排序顺序的示例，请参阅 .NET Framework 中使用字符串的最佳做法中的字符串比较详细信息。

移动平台上的内置数据库功能不太可能支持特定于语言的排序顺序，因此可能需要在业务逻辑中实现其他代码。

文本搜索

请确保使用多种语言编写和测试搜索算法。 需要考虑的事项包括：

  • 自动完成 – 如果已生成自动完成函数，请确保它提供与用户语言相关的建议。
  • 匹配查询与数据 - 是否仅针对以该语言编写的内容或应用中的所有内容执行以特定语言输入的搜索查询？
  • 词干分析 - 如果你的搜索是为搜索类似字词、词根和其他搜索优化而生成的，这些优化是否为你支持的所有语言而构建？
  • 排序 – 确保结果已正确排序（请参阅上图）。

来自外部源的数据

许多应用程序从外部源、Twitter 和 RSS 源下载到天气、新闻或股票价格的数据。 向用户显示此信息时，需要考虑显示与其无关或不可读信息的屏幕的可能性。

可以使用以下策略尝试并确保应用显示与用户相关的数据：

  • 不同的数据源 – 应用程序可能会根据用户的语言或区域设置从其他数据源下载数据。 区域设置新闻、天气和股价可能比从北美源下载的数据更有意义。
  • 本地化的显示 – 如果你显示 Twitter 或照片源，则应以自己的语言显示元数据（如所用时间），即使内容本身仍以原始语言显示。
  • 翻译 – 可以在应用中生成翻译选项，以执行传入数据的机器翻译。 这可以是自动的，也可以由用户自行决定 - 只需确保在发生这种情况时通知用户，因为机器翻译永远不会完美！

这也可能影响指向音频轨道或视频的外部链接 - 在设计应用程序时，请务必提前计划好获取翻译内容的方式，或者确保用户界面能够充分告知用户，某些内容将不会以他们的语言呈现。

不要过度翻译

应用中的某些字符串可能不需要翻译，或者至少需要翻译人员特别注意。 示例包括：

  • URL – 如果列出 URL，可能需要根据语言进行调整，也可能不需要。 例如，facebook.com 不需要翻译，它会自动检测主站点的语言。 其他网站具有特定于区域设置的内容，你可能想要提供不同的 URL，例如 yahoo.com 与 yahoo.fr 或 yahoo.it。
  • 电话号码 - 尤其是那些具有不同国家代码或特定语言呼叫者的电话号码。
  • 联系人详细信息 - 地址和其他信息可能因语言或区域设置而异。
  • 商标和产品名称 - 某些字符串不需要翻译，因为它们总是用同一语言编写。

最后，如果某些字符串需要特殊处理，请务必包含翻译的详细说明。

带格式文本

移动应用通常没有问题，因为字符串通常格式不丰富。 但是，如果应用需要富文本（如粗体或斜体格式），请确保翻译人员知道如何输入格式，字符串文件存储正确，并在显示给用户之前正确格式化（即，不要意外地将格式代码本身呈现给用户）。

翻译提示

翻译应用程序使用的字符串被视为本地化过程的一部分。 通常，此任务将外包给翻译服务，并由可能不知道应用程序或业务的多语种员工执行。

以下提示将帮助你生成更易于准确翻译的字符串，从而提高本地化应用的质量。

本地化完整的字符串，而不是单词

有时，开发人员采用尝试指定单个字词或句子“代码片段”的方法，以便他们可以在整个应用程序中重复使用它们。 例如，对于文本“你有 5 条消息”，他们可能指定以下字符串进行翻译，

错误：

"You have"
"no"
"message"
"messages"

然后尝试使用字符串串联在代码中实时创建正确的短语：

错误：

"You have" + " " + numMsgs + " " + "messages"
"You have" + " no " + "messages"

不建议这样做，因为它不一定适用于所有语言，并且翻译器很难理解每个短段的上下文。 它还会导致重复使用已翻译的字符串，如果它们在不同的上下文中使用（然后更新），可能会导致以后出现问题。

允许参数重新排序

某些编程语言需要额外的语法来指定字符串中的参数顺序，但 .NET 已经支持编号占位符的概念，因此

规范：

"a {0} b {1} cde {3}"

可以翻译以下内容（其中占位符的位置和顺序已更改），

"{2} {3} f g h {0}"

并且令牌将按翻译人员的预期顺序排序。 请务必在将字符串发送到翻译器时包含每个占位符的说明。

对多重性使用多个字符串

避免 "You have {0} message/s." 这样的字符串 对每种状态使用特定字符串，以提供更好的用户体验：

规范：

"You have no messages."
"You have 1 message."
"You have 2 messages."
"You have {0} messages."

必须在应用中编写代码，以评估显示的数字并选择相应的字符串。 某些平台（包括 iOS 和 Android）具有内置功能，可根据当前语言/区域设置的首选项自动选择最佳复数字符串。

允许性别

基于拉丁语的语言有时根据主题的性别使用不同的单词。 如果你的应用知道性别，则应允许翻译后的字符串反映这一点。

即使在英语中，也有更明显的情况，其中字符串是指应用的特定人员或用户。 例如，某些网站显示诸如 "Bob commented on his post" 之类的消息，因此您需要为男性、女性和非二元或未知性别准备字符串：

规范：

"{0} commented on his post"
"{0} commented on her post"
"{0} commented on their post"

不要重复使用字符串

或者更准确地说，不要重复使用字符串，只是因为它们在字符串本身具有不同的用途或含义时相似。

例如：假设应用中有打开/关闭开关，开关控件需要本地化 ‘on’ 和 ‘off’ 的文本。 还可以在文本标签的应用中显示该设置的值。 应对开关显示使用不同的字符串，而不是开关的状态（即使它们与默认语言中的字符串相同），例如：

  • "On" - 显示在开关本身上
  • "Off" - 显示在开关本身上
  • "On" - 显示在标签中
  • "Off" – 显示在标签中

这为翻译人员提供了最大的灵活性：

  • 出于设计原因，开关本身使用小写的 "on" 和 "off"，但显示标签使用大写的 "On" 和 "Off"。
  • 某些语言可能需要缩写开关值才能适应用户界面控件，而完整的（已翻译）单词可以出现在标签中。
  • 或者，对于某些语言，可能出于文化熟悉度的考虑使用 "I" 和 "O" 来呈现开关，但你可能仍希望标签显示为 "On" 或 "Off"。

翻译设置

机器翻译

若要在应用中内建翻译功能，请考虑 Azure 文本翻译 API。

出于测试目的，可以使用许多联机翻译工具之一在开发过程中在应用中包括一些本地化文本：

还有其他许多可用项。 未经专业翻译人员或母语者的审查和测试，机器翻译的质量通常被认为不足以直接发布应用程序。

专业翻译

还有一些专业的翻译服务，他们会采用你的字符串，并分发给自己的翻译人员，向你提供收费的翻译服务。

最著名的服务公司之一是 LionBridge。 大多数专业服务都支持所有常见的文件类型，包括字符串、XML、RESX 和 POT/PO。

总结

本文介绍了在将应用国际化和本地化资源之前应熟悉的一些概念，还介绍了如何更改每个平台的语言首选项。

这些概念可以应用于 Xamarin 可能的各种特定于平台的跨平台国际化技术。

继续阅读你感兴趣的平台的技术详细信息：