让你的应用全球化的指南和清单（使用 C#/VB/C++ 和 XAML 的 Windows 应用商店应用）

使用正确的数字、日期、时间、地址和电话号码格式。

数字、日期、时间和其他形式数据采用的格式因文化、地区、语言和市场的不同而不同。如果要显示数字、日期、时间或其他数据，请使用全球化 API 获取用户首选格式。

有关详细信息，请参阅快速入门：使用全球通用的格式。

支持国际度量单位和货币单位。

尽管最流行的度量单位为公制和英制，但不同的国家/地区会采用不同的度量单位和尺度。如果你需要处理度量问题，例如长度、温度或面积，则请使用 Globalization 命名空间校正系统度量。如果应用支持显示货币，请确保使用了正确的格式。也可以通过使用 CurrenciesInUse 属性，获取用户所在地理位置的货币。

使用 Unicode 进行字符编码。

默认情况下，最新版本的 Microsoft Visual Studio 针对所有文档使用 Unicode 字符编码。如果使用的是不同的编辑器，则请确保在适当的 Unicode 字符编码中保存源文件。所有 Windows 运行时 API 均返回 UTF-16 编码字符串。

请勿通过语言假定用户的位置，并且请勿通过位置假定用户的语言。

在 Windows 中，用户的语言和位置是单独的概念。用户可以使用某种语言的特定区域变体，例如在大不列颠使用的 en-gb 形式的英语，而用户却可以位于完全不同的国家或地区。请考虑应用是否需要有关用户语言的知识，例如针对 UI 文本、或位置，例如用于许可问题。

有关详细信息，请参阅如何管理语言和区域。

请勿使用技术行话、缩写或缩略语。

技术语言很有可能不会被来自其他文化或区域的非技术用户或人员所理解，并且也很难翻译。人们在日常对话中不会采用这样的说法。技术语言常常显示在错误消息中，用于标识硬件和软件问题。有时，这是必要的，但应将字符串重写为非技术性的。

在地图中或在涉及地理区域时避免政治冒犯。

地图可能包含有争议的地理区域或国界，并且这是引起政治冒犯的常见原因。 请务必小心用于选择国家/地区的任何 UI，应将其称为“国家/地区”。将有争议的领土置于标记为“国家/地区”的列表中（例如地址表单中）可能会导致纠纷。

请勿假定始终按字母顺序进行排序。

对于不使用拉丁语脚本的语言，排序基于诸如发音、笔划数和其他因素的因素。即使使用拉丁语脚本的语言也不是始终使用字母顺序排序。例如，在某些文化中，电话簿可能不是按照字母顺序排序。系统可以为你处理排序问题，但如果你创建自己的排序算法，请确保要将你的目标市场使用的排序方法考虑在内。

将资源（例如 UI 字符串和图像）与代码分开。

对应用进行设计，以便将资源（例如，字符串和图像）与代码分开。这样，你就可以分别对这些资源进行维护、本地化，并针对不同的比例因子、辅助功能选项以及大量其他用户和计算机上下文进行自定义。

将字符串与应用的代码分离，以创建独立于语言的单独的代码库。始终将字符串与代码和标记分离。并将这些资源置于资源文件中，例如 ResW 或 ResJSON 文件。

在 Windows 中使用资源基础结构来处理选择最适合的资源以匹配用户的运行时环境。有关详细信息，请参阅应用资源指南和清单。

设置默认语言，并标记所有资源，甚至包括默认语言中的资源。

始终为应用适当地设置默认语言。默认语言确定当用户不使用应用的所有支持语言时要使用的语言。使用语言标记默认语言资源，例如 en-us/Logo.png，以便系统可以通知语言哪些资源使用该语言以及在特定情况下如何使用该语言。

在代码和标记中使用资源标识符来引用资源。

在标记中不针对图像使用字符串文字或特定的文件名称，而应使用对资源的引用。对于 XAML，请参考 [链接]，对于 HTML，则参考链接。请确保对每个资源使用唯一的标识符。

支持镜像。

文本对齐和读取顺序可以采用从左到右的方式（按照英语采用的方式）或者从右到左的方式 (RTL)，通常在阿拉伯语或希伯来语中会采用后面一种方式。如果要将你的产品本地化为使用与你本身语言不同读取顺序的语言，请确保你的 UI 元素的布局支持镜像。甚至诸如后退按钮、UI 过渡效果以及图像之类的项都可能需要镜像。

有关详细信息，请参阅如何针对 RTL 语言调整布局和本地化字体。

使用短字符串。

较短的字符串更易于翻译，并使翻译结果可循环使用。由于无需将相同的字符串再次发送给本地化人员，因此翻译结果的循环使用节约了成本。

某些本地化工具可能不支持长于 8192 个字符的字符串，因此请保持字符串长度为 4000 或更少。

注释字符串。

请确保字符串正确注释，并且只为本地化人员提供需要翻译的字符串。过度本地化是问题的常见根源。