Copyright © 2020 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
本文档提供了与在 Web 上的文档格式、规范和实现中判别内容自然语言相关的定义和最佳实践。文档描述了语言标签如何用于指示用户的地区偏好，这些偏好又被用于处理、格式化和向用户展示信息。
本节描述了本文档在发布时的状态。后续可能有其他文档取代本文件。当前 W3C 出版物列表及本技术报告的最新修订可在 W3C 技术报告索引 https://www.w3.org/TR/ 查找。
这是“万维网的语言标签和地区标识符”的更新公开工作草案。工作组预计本文件将成为工作组说明。
如果您希望对本文档提出意见，请 在 github 提
issue。您也可以发送电子邮件到 www-international@w3.org
(订阅,
邮件存档)
如下方所述。请在邮件主题开头加上[ltli]
，以方便跟踪意见。请针对每条意见分别建立 issue 或发单独邮件。欢迎任何意见。
本文档由 国际化工作组 发布为工作草案。
GitHub Issues 是讨论本规范的推荐方式。
作为工作草案发布不代表 W3C 会员的认可。
本文件为草案，随时可能更新、替换或废弃。作为进行中的工作，引用本文件可能不合适。
本文件由一组成员 在 2017年8月1日 W3C 专利政策 下运营。 该组不希望本文件成为 W3C 推荐标准。 W3C 保持一份 公开的专利披露列表， 涉及工作组产出的相关专利。该页面也包含专利披露相关指引。如果个人明确知晓某专利，且认为其包含 必要声明， 应按 W3C 专利政策第6节披露相关信息。
本文档受 2020年9月15日 W3C流程文档 管理。
语言标签和地区（locales）是 Web 国际化（internationalization
，即 i18n
）的一些基础构件。本文档提供了与 Web 国际化相关的许多基本术语定义，
涵盖了与该方面相关的大部分基本术语。
本文档还为规范作者提供了在文档格式或协议中识别自然语言值所需的术语和最佳实践，这些建议由国际化（I18N）工作组推荐。本文中的这些（以及许多其他）最佳实践及其支持材料的链接，也可以在《Internationalization Best Practices for Spec Developers》（国际化规范开发者最佳实践）[INTERNATIONAL-SPECS] 中找到。除了此处列出的最佳实践外，关于 Web 上语言元数据的更多最佳实践可查阅 [STRING-META]。
用于标识内容的自然语言或指示用户的国际化偏好的标签，是 Web 的基础构件之一。Web 与 Internet 格式和协议中使用的语言标签由 [BCP47] 定义。语言标签的一致使用使应用能够执行与语言相关的特定格式化或处理。例如，用户代理可能会根据语言选择适当的字体来显示文本；网页设计者也可能根据语言为文本应用不同的样式。
许多 Web 的核心标准都支持语言标签；例如在 [XML10] 中的
xml:lang 属性，
在 [HTML]
中的 lang 和 hreflang 属性，
在 [XSL10] 中的 language
属性，
以及 CSS [CSS3-SELECTORS] 中的 :lang 伪类，等等，另外还有 SVG、TTML、SSML
等。
自然语言（在本文档中亦简称为 language）。人类用于口语、书写或手语的交流方式。
有多种方式可以标识语言，也有多种原因使软件需要识别 Web 上内容的语言。Web 上的文档格式和协议通常采用 Internet 其他部分使用的标识，即由 [BCP47] 定义的语言标签。“BCP” 命名法指的是构成“最佳当前实践”的 IETF RFC 集合。
语言标签。用于标识语言的字符串。在本文档中，术语 language tag 明确指代 [BCP47] 中的语言标签。这些语言标签由一个或多个子标签组成。
需要进行语言标识的 Web 规范必须参照 [BCP47]。
规范不应引用 [BCP47] 中的具体组成 RFC，除非确有必要。
[BCP47] 是一个多部分文档，截至本文件发布时由两份独立的 RFC 组成。第一部分称为 Tags for Identifying Languages [RFC5646]，定义了语言标签的语法、格式与术语。第二部分称为 Matching of Language Tags [RFC4647]，描述了若干用于匹配、比较和选择使用语言标签的内容的方案，并包含与比较语言偏好与标记内容相关的有用术语。
诸如 “RFC 5646 或其后续版本” 的表述 可以 使用，但仅在需要指明具体文档版本的情况下才应如此。
尽管这种引用方式曾经普遍，但使用 BCP 引用更加准确。由于从 [RFC4646] 起语言标签的语法已被固定，对于大多数实现而言，引用 BCP 不会带来额外的合规风险。
规范不得引用 BCP47 的过时版本，例如 [RFC1766] 或 [RFC3066]。
需要与
BCP47 的旧版本保持兼容的规范，在必要时必须在 BCP47 中引用名为 obs-language-tag 的产出。
自 [RFC4646] 起，[BCP47]
定义了更复杂的、可机器读取的语言标签语法。该语法已稳定，短期内不太可能更改。有些规范可能希望或要求与 BCP47 以前版本中使用的旧语法兼容（特别是 [RFC1766] 和 [RFC3066]）。这种较宽松的语法在 BCP47 中被称为 ABNF 产生式
obs-language-tag。引入当前语言标签语法的 [RFC4646] 已被 [RFC5646] 取代，作为当前 [BCP47]
的一部分。
那些在 URI 中（例如在 RDF 领域）提供语言信息的应用应当使用 [BCP47]。
目前，用于表示语言信息的 URI 常常使用来自 ISO 639 的值，这会导致模糊性，例如德语可以用 ISO 639-1 的 de 或 ISO 639-2 的 ger
表示。通过使用 BCP47 及其语言子标签注册表，可避免此类歧义。例如，对于德语，注册表只包含 de。
子标签（Subtag）。由 ASCII 字母或数字组成的一段序列，子标签之间以连字符（hyphen-minus）分隔，用以标识语言标签中某一具体含义元素。在 [BCP47] 中，子标签可以是大小写字母（大小写不区分）或 ASCII 数字。子标签长度上限为八个字符（具体使用场景可能对长度有额外限制）。
基于语言标签选择内容或行为需要 BCP47（参见 [RFC4647]）中定义的一些附加概念。本文档直接采用了来自 [BCP47] 的下列术语：
IANA 语言子标签注册表（IANA Language Subtag Registry）。一个可由机器读取的文本文件，可通过 IANA 获取，其中包含语言标签中所有有效子标签的完整列表。（链接：Registry）
规范不应引用构成 IANA 语言子标签注册表来源的底层标准（如 ISO639、ISO15924、ISO3166 或 UN M.49）来替代对 [BCP47] 的引用。
某些标准可能直接使用 BCP47 的某个贡献性标准，在这种情况下引用该标准是合适的。然而，对于指定代码和含义的目的，大多数情况下应优先使用 [BCP47] 的 子标签注册表，因为该注册表已稳定并能以若干有用方式消除歧义。
[BCP47] 定义了两种不同级别的合规性。详情见 [classes of conformance]。对于语言标签，合规性级别对应于实现对语言标签值所进行的检查类型。
良构语言标签（Well-formed language tag）。遵循 [BCP47] 中定义语法的语言标签。即其结构正确，由规定长度的 ASCII 字母和数字的 子标签组成，并以连字符分隔。
有效语言标签（Valid language tag）。既是 良构，又满足 [BCP47] 中的附加合规性要求（参见 conformance requirements），尤其要求每个子标签都出现在 IANA 语言子标签注册表中。
请注意，这对实现而言比建议更为严格。
检查标签是否 有效 需要访问或保留 注册表 的副本并实现额外的运行时逻辑。尽管建议内容作者选择、生成并交换仅为有效的值，语言标签匹配和其他常见语言标签操作的设计通常不需要进行有效性检查。那些需要理解子标签具体语义内容的功能或特性，才是规范在协议或文档格式中正式要求有效标签的主要原因。
语言标签扩展（Language tag extension）或称 extension。由单字母或数字子标签在 IANA 注册引入的一组额外 [BCP47] 子标签，允许表示更多类型的语言识别信息。
特别地，[RFC6067] 定义了 BCP 47 Extension U，也称“Unicode Locales”。该扩展为 BCP47 提供了额外的子标签序列，用以选择具体的地区变体。
规范不应限制语言标签的长度，也不应允许或鼓励移除扩展。
语言范围（Language range）。结构类似于语言标签的字符串，用于“标识具有特定属性的一组语言标签”。
语言优先列表（Language priority list）。由一个或多个 语言范围 组成的集合，用于识别用户的语言偏好并用于匹配。顾名思义，此类列表通常按用户偏好排序或加权。HTTP 的 [RFC2616] 中的 Accept-Language
[RFC3282] 头便是语言优先列表的一种示例。
基本语言范围（Basic language range）。由一系列以连字符分隔的子标签组成的 语言范围；即其外观与语言标签一致。
扩展语言范围（Extended language range）。一种由连字符分隔子标签组成的
语言范围，其中子标签既可以是有效子标签，也可以是通配子标签
，表示匹配任意值。
*
某些 语言优先列表（如之前提到的 Accept-Language [RFC3282]）为列表中的值提供“权重”。此类加权仅可用于对列表进行排序，且不应依赖于其他用途。
定义语言标签匹配或语言协商 的规范必须指明所使用的语言范围是基本语言范围 还是 扩展语言范围。
定义语言标签匹配的规范必须指明匹配操作的结果是单一结果（在 [RFC4647] 所定义的 lookup 情形）还是可能为空的多个结果集合（在 RFC4647 中称为 filtering）。
定义语言标签匹配的规范必须指明可用的匹配算法以及选择机制。
例如，JavaScript 国际化（[ECMA-402]）和 [CLDR] 提供了可由实现者调整的“最佳匹配（best fit）”算法。
本节定义了与国际化和本地化相关的基本术语。
说不同语言或具有不同文化背景的用户，通常需要能够正确使用他们母语、书写系统、度量单位、日历以及其他语言规则和文化习惯处理信息的软件与服务。
语言标签也可用于识别与某段内容或用户相关的国际偏好，因为这些偏好与最终用户的自然语言、地区关联或文化有关。这类偏好会应用于诸如数字、日期、时间的展示；按照语言习惯对列表排序；为如日历展示、常用计量单位等项目提供默认值；选择12小时制还是24小时制展示时间；以及许多用户不便逐项设置的细节。对此类偏好的标识通常称作地区（locale）。定义Unicode地区的 [BCP47] 扩展 [CLDR] 为 Web 的国际化API，尤其是JavaScript语言 [ECMASCRIPT] 和 [ECMA-402] 提供了基础。
国际偏好。特指用户的语言和格式化偏好及关联的文化惯例。软件可根据这些偏好正确处理或展示与用户交换的信息。
为了使内容或服务能被全球用户接受和使用，Web上可能需提供多种国际偏好，包括但不限于：
国际化
针对因文化、地区或语言差异而变化的目标用户，进行产品的设计和开发。国际化有时缩写为 i18n，意为单词“I”与“N”之间有18个字母。
本地化。将系统针对某一特定市场或群体的文化预期进行定制。本地化不仅包括用户可见文本和消息的翻译，还涵盖更多内容。本地化缩写为l10n，因单词“L”与“N”之间有10个字母。当针对某组国际偏好的一组内容和设置可以实际使用时，系统被认为是已本地化的。
地区（Locale）。用于标识一组国际偏好的标识符 （如语言标签）。通常该标识符指示用户的首选语言，并可能包括其他信息，如地理区域（如国家）。可以通过API传递或在操作环境中设置地区，以在系统或流程中获得受文化影响的行为。
感知地区（Locale-aware）（或 开启）。系统能够根据地区变化，展示语言和文化相关的内容或行为。通常，已国际化的系统可支持广泛的地区，以满足不同用户的国际偏好。
语言标签可用子标签表达语言、文字脚本、地区和各种特别注册的变体。但某些国际偏好可能无法直接与上述属性对应。例如，许多文化里存在多种排序方式，不能只靠语言标签来推断出合适的排序。例如德语用户，字典与电话簿的排序方式就不一样。
以往，地区往往与用户所用编程语言或操作环境相关。这些应用专用的标识符往往可以从语言标签推断或转换而来。地区模型例子如Java的 java.util.Locale、POSIX（如
de_CH@utf8）、Oracle数据库（AMERICAN_AMERICA.AL32UTF8）、微软的 LCID（如
0x0409）。这些模型与 ISO639、ISO3166 等底层标准及早期语言标签（如 [RFC1766]）的关系是有意设计的。实现常会把已有协议（如 HTTP
Accept-Language头）里的语言标签映射到自有或平台的地区模型。
自当前 [BCP47] 标识符语法被采用以来，众多地区模型直接采纳了 BCP47，或为自有模型与语言标签之间提供了适配或映射。特别是开源地区数据仓库 [CLDR] 的发展与普及，使得将语言标签作为地区标识符被广泛采用。
公共地区数据仓库（Common Locale Data Repository） （[CLDR]）。 公共地区数据仓库是 Unicode 联盟的项目，旨在定义、收集和管理系统或操作环境中所需的地区数据。 CLDR 数据及其地区模型已被广泛采用，特别是在浏览器中。
Unicode地区标识符或 Unicode地区。遵循 UTR#35 [LDML] 中对子标签选择的额外规定的语言标签。有效的 Unicode 地区标识符也是有效的BCP47 语言标签，但部分有效语言标签并不能作为有效的 Unicode 地区标识符。
规范化的 Unicode 地区标识符。指对Unicode 地区标识符应用 [LDML] 中的规范化规则后的良构语言标签（详见第3节）。 该过程会将所有有效的 BCP47 语言标签转换为有效的Unicode地区标识符。例如会将已废弃的子标签或不规则的祖传标签替换为 IANA 语言子标签注册表中的首选值。
[CLDR] 定义并维护了两类与Unicode地区标识符相关的语言标签扩展（[RFC6067] 和 [RFC6497]）。这些扩展允许语言标签表示超越语言或地区变体的某些国际偏好，或在同一地区下有多种选项时指定格式化方式或内容。当地区标识符需要这些扩展实现额外定制时可用，但不是必须。CLDR还对作为地区标识符时的一些子标签做了特殊解释，详情见 [LDML] 3.2节。
Unicode 地区语言标签扩展 [RFC6067] 用
-u- 子标签，提供选择不同格式和行为的子标签。详情见 [LDML] 3.6节。
转化内容语言标签扩展
[RFC6497] 使用 -t-
子标签，提供脚本之间音译等文本转换用的子标签。详见 [LDML] 3.7节。
Unicode地区日益成为Web国际化的基础，尤其在JavaScript [ECMA-402] 的 Intl
地区框架中。[ECMASCRIPT]。
内容作者应当选择规范化的Unicode地区标识符作为语言标签。
[LDML] 第3节中规定的额外内容限制和规范化步骤，比直接使用 [BCP47] 更有利于互操作性和一致性。
实现应当只输出规范化的Unicode地区标识符的语言标签，并应当采用生成规范标签的规范化规则来规范其消费的语言标签。
如上，[LDML] 第3节规定的内容限制和规范化步骤，比直接用 [BCP47] 更能保证互操作性和一致性。此项最佳实践并不意味着实现必须支持、生成、处理或理解任何 CLDR 的扩展。
内容作者不应在语言标签中包含语言标签扩展，除非具体应用需要额外定制。
请牢记每个Unicode 地区标识符本身也是一个良构的 [BCP47] 语言标签。Unicode 地区标识符本身并不要求采用 CLDR 的任何语言标签扩展。
某些国际和文化偏好是个性化的，需由内容作者、服务提供方、操作环境或用户代理代表用户定义和管理。
非语言字段。指不用于存储或交换自然语言文本数据的数据结构元素，包括非字符串类型（如布尔值、数字、日期等），也包括如程序或协议内部标识符等字符串。本文档将“字段”作为该概念的简称。
文档格式或协议的规范通常定义了各种数据值或数据结构的交换、处理或展示。Web主要依靠文本文件进行数据序列化与交换，即使原始字节也常用字符串序列化（如 base64）传输。因此，Web上的非语言字段通常也表现为字符串。重要区别在于，非语言字段一般由底层应用解释或消费，而不是由用户直接阅读。
地区中立。若非语言字段被存储或交换为无特定语言、地区或文化适用格式，并可被明确解释为针对任一地区的展示，则称其为地区中立。
许多规范采用如 [XMLSCHEMA11-2] 或 [JSON-LD] 提供的序列化方案，对文档格式或协议中的非语言字段进行地区中立编码。
地区中立表示本身可能与某种文化偏好相关，但这种关联应尽量减少。比如许多 ISO8601 日期/时间值序列化形式与格里高利历相关，但格式、字段排序、分隔符及外观都不是某地区专属（是面向机器可读的），并且如上例，值可被转换为任何日历或地区展示模式。
语言协商。将用户的国际偏好与可用地区、本地化资源、内容或处理过程进行匹配的过程。
地区回退。通过从更具体资源“回退”到更一般资源并遵循确定性模式搜索翻译内容、地区数据或其他资源的过程。
用户偏好通常表现为一个地区或优先排列表。协商语言时系统采用某种算法以从可用资源中获得最佳匹配内容或功能。许多情况下语言协商算法会用地区回退。
在文档格式中展现字段的规范，应当要求数据按周边内容语言来格式化。
当非语言字段作为文档或应用的一部分呈现给用户时，该文档或应用即为数据的“上下文”。内容作者或开发者需有办法让字段融合进用户体验并可控地展示。这可由字段出现上下文的语言标签指示：通常已开启地区识别的实现会把标签视为地区来实现。直接用用户代理运行环境的地区设置来展示非语言字段只应作为最后手段。
规范如在文档或应用中展现表单或接收非语言字段输入，应当要求值展现给用户时按其内容或标签周边语言格式本地化。
对于展现、交换或接收非语言字段输入的规范，必须用于存储与交换采用地区中立格式。
实现应当在文档或应用中用与周边内容语言一致的格式展现非语言字段，且鼓励对于输入或编辑时提供本地化到同一地区的控件。
用户希望表单字段与其他数据输入的展示能与所处文档或应用保持一致。通常希望输入与文档上下文语言相符而非与用户代理或操作环境一致，输入验证、提示或控件也应和内容一致。这样作者可以创造完全本地化的体验，符合用户的预期。
国际化工作组还有其它最佳实践与参考资料，例如语言标签选择的相关文章。包括：
本文件自 2015-04-23 工作草案 发布之后的变更可在 github 提交日志查询。本次更新自该版本后文件结构变动较大，主要包括：
自 2006-06-20 版本后还做了如下调整：
自 2006年4月发布版本以来的变动记录如下：
对引言部分彻底重写，包括文档范围、应用场景及地区与自然语言的区别描述。
依赖 [BCP47] 的术语现不再定义，仅引用该规范，并补充了示例。
对语言与地区值的要求已从合规章节移至正文。
创建了修订记录。
国际化工作组对本规范以下贡献者表示感谢：