开发可本地化的清单

另一个考虑因素是规范采用的语言协商 策略。如果清单可以按需生成（而不是缓存在一个众所周知的 URL 上），那么 本地化可以按请求应用。这更倾向于一种简写清单风格。在其他情况下，如果某些 实现可能能够协商，而另一些则不能，那么规范允许使用不同策略 可能很重要。

请记住，现代操作环境支持非常广泛的可用区域设置集， 而应用程序所有者通常希望通过单个本地化的应用程序或 文档来满足多样化受众。虽然规范中的示例必然限制在大约三到四个区域设置， 但实际应用程序具有 50 个或更多特定区域设置并不罕见。

清单需要将用户的语言偏好与可用的本地化资源相匹配。用户的 区域设置偏好可以包含的不仅仅是主要语言子标签。它可能包含文字（在 zh-Hans 这样的标签中，表示“以简体汉字书写的中文”）或地区 （在 fr-CA 这样的标签中，表示“加拿大使用的法语”）——或两者兼有。一些系统支持 Unicode 区域设置 标识符，它是 [BCP47] 的一个扩展，包含 日历、数字成形、排序规则等定制。有关更多信息，请参见 [LTLI]。

"localized-resource": {
	"en":     {"value": "This is English"},
	"en-GB":  {"value": "This is UK English"},
	"en-US":  {"value": "This is US English"}
}

en-GB-oxendict  // no match
en-GB           // matches en-GB
en              // if en-GB were not present, matches en
(default)       // no match, use defaults

对于非语言字段（即 包含非人类语言数据的字符串），不应将语言或方向元数据与该值关联。请注意，这包括 应用程序内部数据 值 [INTERNATIONAL-SPECS]。

如果使用者需要 为数据分配语言标签，则应使用值 zxx（非语言）。如果使用者需要为数据分配基 本方向，则应使用值 auto。

对于以单一语言出现的可本地化 文本字段，使用一种数据结构来表示该值。推荐的 表示是一个包含三个字段的对象。字段 value 包含 实际字符串。字段 lang 包含一个有效的 [BCP47] 语言标签。字段 dir 包含字符串的基本方向（值为 ltr、rtl 或 auto 之一）。

参见 [STRING-META] 中的 可本地化 WebIDL 字典。

如果给定文档中只有少量自然语言 字符串，单语言可本地化文本字段最为适用。当诸如清单之类的文档包含许多自然语言字符串时， 这种方式会变得低效。为了降低编码这些字符串的复杂性，一种变通方法是 为语言和基本方向建立文档级默认值。它们是独立的值，因为 语言并不暗含方向。仍应能够通过使用可本地化文本字段的单语言 表示法来覆盖任何给定字符串值上的任一值，该表示法见上文。

对于可以使用 [JSON-LD] @context 机制的规范，请使用 @language 和 @direction 字段来提供文档级默认值。

如果你的规范定义了自己的文档级默认值，请提供两个可选字段：

• 文档的默认语言字段应命名为 language，并且应规定其包含一个有效的 [BCP47] 语言标签。规范应规定，实现只需要检查 [BCP47] 语言标签是否形式良好。
• 文档的默认基本方向字段应命名为 direction，并支持值 ltr、rtl 或 auto。

世界并非单语。让文档只包含单一语言将意味着需要提供 该文档的许多迭代版本，每种语言一个版本，以便本地化清单。这还 可能需要在请求清单时进行语言协商。

解决此问题的一种方式是允许清单文档内的每个可本地化文本字段具有 多语言值。

语言选择并不仅仅是将语言标签字符串值与用户首选的 区域设置进行精确匹配。对象表示法通常用于表示可本地化 文本字段，它要求先反序列化对象，才能发现与该值关联的语言标签。 当给定清单文件中有许多值时，这可能效率低下。 在这些情况下，最佳实践是使用语言映射来组织可本地化文本值。这样的 映射会暴露语言标签以供选择，但在映射的值一侧仍使用对象表示法， 因为对于给定的字符串值，可能需要覆盖语言和方向。

单一清单方法通过使用语言值数组定义可本地化字段，来提供 本地化能力。

单一清单的优势包括：

1. 清单是单个文件，便于下载。
2. 更容易确保正在使用每种语言的正确资源版本。
3. 语言默认处理可能更容易管理。

这种方法也有缺点：

1. 如果清单被呈现为许多语言，文件大小可能会不成比例地增长。
2. 本地化流程通常经过优化，用于创建原始文件的副本，只是 替换其中承载语言的材料。在一个高度多语言的文件中创建、管理和同步本地化 可能比为每种语言使用单独文件更复杂。通过脚本或工具生成 清单是管理这种复杂性的一种方法。

单一清单最适合源文件较小、可本地化内容字段数量有限 和/或语言数量有限的情况。大多数单一清单都会定义某种“语言索引” 方案（例如 [JSON-LD] 中的方案）来执行实际选择。

特定于区域设置的清单会为每种受支持的语言或区域设置创建单独文件。通常， 规范会选择基于 path 或 filename 的组织方案来分配和查找清单文件。

特定于区域设置的清单的优势包括：

1. 管理区域设置的创建或添加通常更容易。本地化流程 通常针对“创建给定源文件的本地化副本”进行了优化。

缺点包括：

1. 即使是简单的区域设置回退链，也可能要求客户端搜索或获取多个文件。
2. 由于文件是分开的，必须严格控制内容的版本管理。
3. 可能需要测试更多变体，以确保正常运行。

一种常见的折中方案是设置一个中央清单文件，其中包含大部分或全部不可本地化 内容，并配合包含可本地化内容的单独文件。在某些情况下，中央 清单文件包含可本地化内容的默认值。中央清单还可能包含 可用区域设置的目录或列表（或特定于语言的清单的 URL），以便客户端只 需要尝试获取实际可用的本地化文件。