Network Working Group A. Phillips, Ed.
Request for Comments: 4646 Yahoo! Inc.
BCP: 47 M. Davis, Ed.
Obsoletes: 3066 Google
Category: Best Current Practice September 2006
Network Working Group A. Phillips, Ed.
Request for Comments: 4646 Yahoo! Inc.
BCP: 47 M. Davis, Ed.
Obsoletes: 3066 Google
Category: Best Current Practice September 2006
Tags for Identifying Languages
用于识别语言的标记
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766.
本文档描述了语言标记的结构、内容、构造和语义，以便在需要指示信息对象中使用的语言的情况下使用。它还描述了如何注册用于语言标记的值，以及如何为专用交换创建用户定义的扩展。本文件与RFC 4647一起取代了RFC 3066，后者取代了RFC 1766。
Table of Contents
目录
1. Introduction ....................................................3
2. The Language Tag ................................................4
2.1. Syntax .....................................................4
2.2. Language Subtag Sources and Interpretation .................7
2.2.1. Primary Language Subtag .............................8
2.2.2. Extended Language Subtags ..........................10
2.2.3. Script Subtag ......................................11
2.2.4. Region Subtag ......................................11
2.2.5. Variant Subtags ....................................13
2.2.6. Extension Subtags ..................................14
2.2.7. Private Use Subtags ................................16
2.2.8. Preexisting RFC 3066 Registrations .................16
2.2.9. Classes of Conformance .............................17
3. Registry Format and Maintenance ................................18
3.1. Format of the IANA Language Subtag Registry ...............18
3.2. Language Subtag Reviewer ..................................24
3.3. Maintenance of the Registry ...............................24
3.4. Stability of IANA Registry Entries ........................25
3.5. Registration Procedure for Subtags ........................29
3.6. Possibilities for Registration ............................32
3.7. Extensions and Extensions Registry ........................34
3.8. Initialization of the Registries ..........................37
4. Formation and Processing of Language Tags ......................38
4.1. Choice of Language Tag ....................................38
4.2. Meaning of the Language Tag ...............................40
4.3. Length Considerations .....................................41
4.3.1. Working with Limited Buffer Sizes ..................42
4.3.2. Truncation of Language Tags ........................43
4.4. Canonicalization of Language Tags .........................44
4.5. Considerations for Private Use Subtags ....................45
5. IANA Considerations ............................................46
5.1. Language Subtag Registry ..................................46
5.2. Extensions Registry .......................................47
6. Security Considerations ........................................48
7. Character Set Considerations ...................................48
8. Changes from RFC 3066 ..........................................49
9. References .....................................................52
9.1. Normative References ......................................52
9.2. Informative References ....................................53
Appendix A. Acknowledgements ......................................55
Appendix B. Examples of Language Tags (Informative) ...............56
1. Introduction ....................................................3
2. The Language Tag ................................................4
2.1. Syntax .....................................................4
2.2. Language Subtag Sources and Interpretation .................7
2.2.1. Primary Language Subtag .............................8
2.2.2. Extended Language Subtags ..........................10
2.2.3. Script Subtag ......................................11
2.2.4. Region Subtag ......................................11
2.2.5. Variant Subtags ....................................13
2.2.6. Extension Subtags ..................................14
2.2.7. Private Use Subtags ................................16
2.2.8. Preexisting RFC 3066 Registrations .................16
2.2.9. Classes of Conformance .............................17
3. Registry Format and Maintenance ................................18
3.1. Format of the IANA Language Subtag Registry ...............18
3.2. Language Subtag Reviewer ..................................24
3.3. Maintenance of the Registry ...............................24
3.4. Stability of IANA Registry Entries ........................25
3.5. Registration Procedure for Subtags ........................29
3.6. Possibilities for Registration ............................32
3.7. Extensions and Extensions Registry ........................34
3.8. Initialization of the Registries ..........................37
4. Formation and Processing of Language Tags ......................38
4.1. Choice of Language Tag ....................................38
4.2. Meaning of the Language Tag ...............................40
4.3. Length Considerations .....................................41
4.3.1. Working with Limited Buffer Sizes ..................42
4.3.2. Truncation of Language Tags ........................43
4.4. Canonicalization of Language Tags .........................44
4.5. Considerations for Private Use Subtags ....................45
5. IANA Considerations ............................................46
5.1. Language Subtag Registry ..................................46
5.2. Extensions Registry .......................................47
6. Security Considerations ........................................48
7. Character Set Considerations ...................................48
8. Changes from RFC 3066 ..........................................49
9. References .....................................................52
9.1. Normative References ......................................52
9.2. Informative References ....................................53
Appendix A. Acknowledgements ......................................55
Appendix B. Examples of Language Tags (Informative) ...............56
Human beings on our planet have, past and present, used a number of languages. There are many reasons why one would want to identify the language used when presenting or requesting information.
我们星球上的人类过去和现在都使用过多种语言。有许多原因可以解释为什么人们希望识别在呈现或请求信息时使用的语言。
A user's language preferences often need to be identified so that appropriate processing can be applied. For example, the user's language preferences in a Web browser can be used to select Web pages appropriately. Language preferences can also be used to select among tools (such as dictionaries) to assist in the processing or understanding of content in different languages.
通常需要确定用户的语言偏好，以便应用适当的处理。例如，用户在Web浏览器中的语言首选项可用于适当地选择网页。语言首选项还可用于在工具（如词典）中进行选择，以帮助处理或理解不同语言的内容。
In addition, knowledge about the particular language used by some piece of information content might be useful or even required by some types of processing; for example, spell-checking, computer-synthesized speech, Braille transcription, or high-quality print renderings.
此外，某些信息内容使用的特定语言的知识可能对某些类型的处理有用，甚至是必需的；例如，拼写检查、计算机合成语音、盲文转录或高质量打印渲染。
One means of indicating the language used is by labeling the information content with an identifier or "tag". These tags can be used to specify user preferences when selecting information content, or for labeling additional attributes of content and associated resources.
指示所用语言的一种方法是用标识符或“标签”标记信息内容。这些标记可用于在选择信息内容时指定用户首选项，或用于标记内容和关联资源的其他属性。
Tags can also be used to indicate additional language attributes of content. For example, indicating specific information about the dialect, writing system, or orthography used in a document or resource may enable the user to obtain information in a form that they can understand, or it can be important in processing or rendering the given content into an appropriate form or style.
标记还可用于指示内容的其他语言属性。例如，指示关于文档或资源中使用的方言、书写系统或正字法的特定信息可能使用户能够以他们能够理解的形式获得信息，或者在将给定内容处理或呈现为适当的形式或样式时可能很重要。
This document specifies a particular identifier mechanism (the language tag) and a registration function for values to be used to form tags. It also defines a mechanism for private use values and future extension.
本文档为用于形成标记的值指定了特定的标识符机制（语言标记）和注册函数。它还定义了私有使用值和未来扩展的机制。
This document, in combination with [RFC4647], replaces [RFC3066], which replaced [RFC1766]. For a list of changes in this document, see Section 8.
本文件与[RFC4647]一起取代了[RFC3066]，后者取代了[RFC1766]。有关本文件中的变更列表，请参见第8节。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Language tags are used to help identify languages, whether spoken, written, signed, or otherwise signaled, for the purpose of communication. This includes constructed and artificial languages, but excludes languages not intended primarily for human communication, such as programming languages.
语言标签用于帮助识别语言，无论是口语、书面语、有符号语言还是其他信号语言，以便于交流。这包括构造语言和人工语言，但不包括非主要用于人类交流的语言，如编程语言。
The language tag is composed of one or more parts, known as "subtags". Each subtag consists of a sequence of alphanumeric characters. Subtags are distinguished and separated from one another by a hyphen ("-", ABNF [RFC4234] %x2D). A language tag consists of a "primary language" subtag and a (possibly empty) series of subsequent subtags, each of which refines or narrows the range of languages identified by the overall tag.
语言标记由一个或多个部分组成，称为“子标记”。每个子标签由一系列字母数字字符组成。子标签通过连字符（“-”，ABNF[RFC4234]%x2D）相互区分和分隔。语言标记由一个“主语言”子标记和一系列（可能为空）后续子标记组成，每个子标记细化或缩小由整个标记标识的语言范围。
Usually, each type of subtag is distinguished by length, position in the tag, and content: subtags can be recognized solely by these features. The only exception to this is a fixed list of grandfathered tags registered under RFC 3066 [RFC3066]. This makes it possible to construct a parser that can extract and assign some semantic information to the subtags, even if the specific subtag values are not recognized. Thus, a parser need not have an up-to-date copy (or any copy at all) of the subtag registry to perform most searching and matching operations.
通常，每种类型的子标签都通过长度、在标签中的位置和内容来区分：子标签只能通过这些特征来识别。唯一的例外是在RFC 3066[RFC3066]下注册的固定祖父标记列表。这使得构造一个解析器成为可能，该解析器可以提取一些语义信息并将其分配给子标记，即使无法识别特定的子标记值。因此，解析器无需拥有子标记注册表的最新副本（或任何副本），即可执行大多数搜索和匹配操作。
The syntax of the language tag in ABNF [RFC4234] is:
ABNF[RFC4234]中语言标记的语法为：
Language-Tag = langtag
/ privateuse ; private use tag
/ grandfathered ; grandfathered registrations
Language-Tag = langtag
/ privateuse ; private use tag
/ grandfathered ; grandfathered registrations
langtag = (language
["-" script]
["-" region]
*("-" variant)
*("-" extension)
["-" privateuse])
langtag = (language
["-" script]
["-" region]
*("-" variant)
*("-" extension)
["-" privateuse])
language = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code
/ 4ALPHA ; reserved for future use
/ 5*8ALPHA ; registered language subtag
language = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code
/ 4ALPHA ; reserved for future use
/ 5*8ALPHA ; registered language subtag
extlang = *3("-" 3ALPHA) ; reserved for future use
extlang = *3("-" 3ALPHA) ; reserved for future use
script = 4ALPHA ; ISO 15924 code
脚本=4ALPHA；ISO 15924代码
region = 2ALPHA ; ISO 3166 code
/ 3DIGIT ; UN M.49 code
region = 2ALPHA ; ISO 3166 code
/ 3DIGIT ; UN M.49 code
variant = 5*8alphanum ; registered variants
/ (DIGIT 3alphanum)
variant = 5*8alphanum ; registered variants
/ (DIGIT 3alphanum)
extension = singleton 1*("-" (2*8alphanum))
extension = singleton 1*("-" (2*8alphanum))
singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT
; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9"
; Single letters: x/X is reserved for private use
singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT
; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9"
; Single letters: x/X is reserved for private use
privateuse = ("x"/"X") 1*("-" (1*8alphanum))
privateuse = ("x"/"X") 1*("-" (1*8alphanum))
grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum))
; grandfathered registration
; Note: i is the only singleton
; that starts a grandfathered tag
grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum))
; grandfathered registration
; Note: i is the only singleton
; that starts a grandfathered tag
alphanum = (ALPHA / DIGIT) ; letters and numbers
alphanum = (ALPHA / DIGIT) ; letters and numbers
Figure 1: Language Tag ABNF
图1：语言标记ABNF
Note: There is a subtlety in the ABNF for 'variant': variants starting with a digit MAY be four characters long, while those starting with a letter MUST be at least five characters long.
注意：ABNF中的“变体”有一个微妙之处：以数字开头的变体可能有四个字符长，而以字母开头的变体必须至少有五个字符长。
All subtags have a maximum length of eight characters and whitespace is not permitted in a language tag. For examples of language tags, see Appendix B.
所有子标记的最大长度为8个字符，语言标记中不允许使用空格。有关语言标记的示例，请参见附录B。
Note that although [RFC4234] refers to octets, the language tags described in this document are sequences of characters from the US-ASCII [ISO646] repertoire. Language tags MAY be used in documents and applications that use other encodings, so long as these encompass the US-ASCII repertoire. An example of this would be an XML document that uses the UTF-16LE [RFC2781] encoding of [Unicode].
请注意，尽管[RFC4234]指的是八位字节，但本文档中描述的语言标记是US-ASCII[ISO646]指令表中的字符序列。语言标记可用于使用其他编码的文档和应用程序中，只要这些编码包含US-ASCII指令集。一个例子是使用[Unicode]的UTF-16LE[RFC2781]编码的XML文档。
The tags and their subtags, including private use and extensions, are to be treated as case insensitive: there exist conventions for the capitalization of some of the subtags, but these MUST NOT be taken to carry meaning.
标记及其子标记（包括私有使用和扩展）应视为不区分大小写：有些子标记的大小写存在约定，但这些约定不得被视为具有意义。
For example:
例如：
o [ISO639-1] recommends that language codes be written in lowercase ('mn' Mongolian).
o [ISO639-1]建议语言代码应使用小写（“mn”蒙古语）。
o [ISO3166-1] recommends that country codes be capitalized ('MN' Mongolia).
o [ISO3166-1]建议国家代码大写（“MN”蒙古）。
o [ISO15924] recommends that script codes use lowercase with the initial letter capitalized ('Cyrl' Cyrillic).
o [ISO15924]建议脚本代码使用小写字母，首字母大写（“Cyrl”西里尔字母）。
However, in the tags defined by this document, the uppercase US-ASCII letters in the range 'A' through 'Z' are considered equivalent and mapped directly to their US-ASCII lowercase equivalents in the range 'a' through 'z'. Thus, the tag "mn-Cyrl-MN" is not distinct from "MN-cYRL-mn" or "mN-cYrL-Mn" (or any other combination), and each of these variations conveys the same meaning: Mongolian written in the Cyrillic script as used in Mongolia.
但是，在本文档定义的标记中，“A”到“Z”范围内的大写US-ASCII字母被认为是等效的，并直接映射到“A”到“Z”范围内的US-ASCII小写等效字母。因此，标记“mn Cyrl mn”与“mn Cyrl mn”或“mn Cyrl mn”（或任何其他组合）没有区别，并且这些变体中的每一个都传达了相同的含义：蒙古语以西里尔文字书写，与蒙古语中使用的一样。
Although case distinctions do not carry meaning in language tags, consistent formatting and presentation of the tags will aid users. The format of the tags and subtags in the registry is RECOMMENDED. In this format, all non-initial two-letter subtags are uppercase, all non-initial four-letter subtags are titlecase, and all other subtags are lowercase.
尽管大小写区分在语言标记中并没有意义，但标记的一致格式和表示方式将有助于用户。建议使用注册表中标记和子标记的格式。在这种格式中，所有非首字母两个字母的子标签都是大写的，所有非首字母四个字母的子标签都是titlecase，所有其他子标签都是小写的。
The namespace of language tags and their subtags is administered by the Internet Assigned Numbers Authority (IANA) [RFC2860] according to the rules in Section 5 of this document. The Language Subtag Registry maintained by IANA is the source for valid subtags: other standards referenced in this section provide the source material for that registry.
语言标记及其子标记的名称空间由互联网分配号码管理局（IANA）[RFC2860]根据本文件第5节中的规则进行管理。IANA维护的语言子标签注册表是有效子标签的来源：本节中引用的其他标准提供了该注册表的源材料。
Terminology in this section:
本节中的术语：
o Tag or tags refers to a complete language tag, such as "fr-Latn-CA". Examples of tags in this document are enclosed in double-quotes ("en-US").
o 标记是指完整的语言标记，如“fr Latn CA”。本文件中的标签示例附在双引号（“en US”）中。
o Subtag refers to a specific section of a tag, delimited by hyphen, such as the subtag 'Latn' in "fr-Latn-CA". Examples of subtags in this document are enclosed in single quotes ('Latn').
o Subtag是指标记的特定部分，由连字符分隔，例如“fr Latn CA”中的Subtag“Latn”。本文件中的子标签示例附在单引号（“Latn”）中。
o Code or codes refers to values defined in external standards (and that are used as subtags in this document). For example, 'Latn' is an [ISO15924] script code that was used to define the 'Latn' script subtag for use in a language tag. Examples of codes in this document are enclosed in single quotes ('en', 'Latn').
o 代码是指外部标准中定义的值（在本文件中用作子标签）。例如，“Latn”是一个[ISO15924]脚本代码，用于定义语言标记中使用的“Latn”脚本子标记。本文件中的代码示例附在单引号中（“en”、“Latn”）。
The definitions in this section apply to the various subtags within the language tags defined by this document, excepting those "grandfathered" tags defined in Section 2.2.8.
本节中的定义适用于本文件定义的语言标记中的各种子标记，第2.2.8节中定义的“祖父”标记除外。
Language tags are designed so that each subtag type has unique length and content restrictions. These make identification of the subtag's type possible, even if the content of the subtag itself is unrecognized. This allows tags to be parsed and processed without reference to the latest version of the underlying standards or the IANA registry and makes the associated exception handling when parsing tags simpler.
语言标记的设计使每个子标记类型都有唯一的长度和内容限制。这样就可以识别子标签的类型，即使子标签本身的内容无法识别。这允许在不参考最新版本的基础标准或IANA注册表的情况下解析和处理标记，并使解析标记时的相关异常处理更简单。
Subtags in the IANA registry that do not come from an underlying standard can only appear in specific positions in a tag. Specifically, they can only occur as primary language subtags or as variant subtags.
IANA注册表中不来自基础标准的子标签只能出现在标签中的特定位置。具体来说，它们只能作为主要语言子标记或变体子标记出现。
Note that sequences of private use and extension subtags MUST occur at the end of the sequence of subtags and MUST NOT be interspersed with subtags defined elsewhere in this document.
请注意，专用子标签和扩展子标签的序列必须出现在子标签序列的末尾，并且不得与本文档其他地方定义的子标签交错。
Single-letter and single-digit subtags are reserved for current or future use. These include the following current uses:
单字母和单数字子标签保留供当前或将来使用。其中包括以下当前用途：
o The single-letter subtag 'x' is reserved to introduce a sequence of private use subtags. The interpretation of any private use subtags is defined solely by private agreement and is not defined by the rules in this section or in any standard or registry defined in this document.
o 保留单字母子标签“x”，以引入一系列专用子标签。任何私人使用子标签的解释仅由私人协议定义，不受本节规则或本文件中定义的任何标准或注册的定义。
o All other single-letter subtags are reserved to introduce standardized extension subtag sequences as described in Section 3.7.
o 保留所有其他单字母子标签，以引入第3.7节所述的标准化扩展子标签序列。
The single-letter subtag 'i' is used by some grandfathered tags, such as "i-enochian", where it always appears in the first position and cannot be confused with an extension.
单字母子标记“i”被一些祖辈标记使用，例如“i-enochian”，它总是出现在第一个位置，不能与扩展混淆。
The primary language subtag is the first subtag in a language tag (with the exception of private use and certain grandfathered tags) and cannot be omitted. The following rules apply to the primary language subtag:
primary language子标记是语言标记中的第一个子标记（私有使用和某些祖父标记除外），不能省略。以下规则适用于主语言子标记：
1. All two-character language subtags were defined in the IANA registry according to the assignments found in the standard ISO 639 Part 1, "ISO 639-1:2002, Codes for the representation of names of languages -- Part 1: Alpha-2 code" [ISO639-1], or using assignments subsequently made by the ISO 639 Part 1 maintenance agency or governing standardization bodies.
1. 根据标准ISO 639第1部分“ISO 639-1:2002，语言名称表示代码第1部分：Alpha-2代码”[ISO639-1]中的分配，IANA注册表中定义了所有两个字符的语言子标签，或使用ISO 639第1部分维护机构或管理标准化机构随后制定的任务。
2. All three-character language subtags were defined in the IANA registry according to the assignments found in ISO 639 Part 2, "ISO 639-2:1998 - Codes for the representation of names of languages -- Part 2: Alpha-3 code - edition 1" [ISO639-2], or assignments subsequently made by the ISO 639 Part 2 maintenance agency or governing standardization bodies.
2. 根据ISO 639第2部分“ISO 639-2:1998-语言名称表示代码-第2部分：Alpha-3代码-第1版”[ISO639-2]中的分配，IANA注册表中定义了所有三个字符的语言子标签，或ISO 639第2部分维护机构或管理标准化机构随后做出的任务。
3. The subtags in the range 'qaa' through 'qtz' are reserved for private use in language tags. These subtags correspond to codes reserved by ISO 639-2 for private use. These codes MAY be used for non-registered primary language subtags (instead of using private use subtags following 'x-'). Please refer to Section 4.5 for more information on private use subtags.
3. “qaa”到“qtz”范围内的子标签在语言标签中保留供私人使用。这些子标签对应于ISO 639-2保留供私人使用的代码。这些代码可用于未注册的主语言子标记（而不是使用“x-”后面的专用子标记）。有关专用子标签的更多信息，请参阅第4.5节。
4. All four-character language subtags are reserved for possible future standardization.
4. 所有四个字符的语言子标签都保留用于将来可能的标准化。
5. All language subtags of 5 to 8 characters in length in the IANA registry were defined via the registration process in Section 3.5 and MAY be used to form the primary language subtag. At the time
5. IANA注册表中长度为5至8个字符的所有语言子标签都是通过第3.5节中的注册过程定义的，可用于构成主语言子标签。当时
this document was created, there were no examples of this kind of subtag and future registrations of this type will be discouraged: primary languages are strongly RECOMMENDED for registration with ISO 639, and proposals rejected by ISO 639/RA will be closely scrutinized before they are registered with IANA.
本文件是创建的，没有此类子标签的示例，今后不鼓励此类子标签的注册：强烈建议在ISO 639中注册主要语言，被ISO 639/RA拒绝的提案将在IANA中注册之前进行仔细审查。
6. The single-character subtag 'x' as the primary subtag indicates that the language tag consists solely of subtags whose meaning is defined by private agreement. For example, in the tag "x-fr-CH", the subtags 'fr' and 'CH' SHOULD NOT be taken to represent the French language or the country of Switzerland (or any other value in the IANA registry) unless there is a private agreement in place to do so. See Section 4.5.
6. 作为主要子标记的单字符子标记“x”表示语言标记仅由子标记组成，其含义由私人协议定义。例如，在标签“x-fr-CH”中，子标签“fr”和“CH”不应被视为代表法语或瑞士国家（或IANA注册中的任何其他值），除非有这样做的私人协议。见第4.5节。
7. The single-character subtag 'i' is used by some grandfathered tags (see Section 2.2.8) such as "i-klingon" and "i-bnn". (Other grandfathered tags have a primary language subtag in their first position.)
7. 单字符子标签“i”由一些祖父标记（见第2.2.8节）使用，如“i-klingon”和“i-bnn”。（其他grandfathered标记的第一个位置有一个primary language子标记。）
8. Other values MUST NOT be assigned to the primary subtag except by revision or update of this document.
8. 除非通过修订或更新本文件，否则不得将其他值分配给主子标签。
Note: For languages that have both an ISO 639-1 two-character code and an ISO 639-2 three-character code, only the ISO 639-1 two-character code is defined in the IANA registry.
注：对于同时具有ISO 639-1两字符代码和ISO 639-2三字符代码的语言，IANA注册表中仅定义了ISO 639-1两字符代码。
Note: For languages that have no ISO 639-1 two-character code and for which the ISO 639-2/T (Terminology) code and the ISO 639-2/B (Bibliographic) codes differ, only the Terminology code is defined in the IANA registry. At the time this document was created, all languages that had both kinds of three-character code were also assigned a two-character code; it is not expected that future assignments of this nature will occur.
注：对于没有ISO 639-1双字符代码且ISO 639-2/T（术语）代码和ISO 639-2/B（书目）代码不同的语言，只有术语代码在IANA注册表中定义。在创建此文档时，所有同时具有两种三字符代码的语言也被分配了一个两字符代码；预计未来不会发生这种性质的任务。
Note: To avoid problems with versioning and subtag choice as experienced during the transition between RFC 1766 and RFC 3066, as well as the canonical nature of subtags defined by this document, the ISO 639 Registration Authority Joint Advisory Committee (ISO 639/ RA-JAC) has included the following statement in [iso639.prin]:
注：为了避免在RFC 1766和RFC 3066之间的转换过程中遇到的版本控制和子标签选择问题，以及本文件定义的子标签的规范性质，ISO 639注册机构联合咨询委员会（ISO 639/RA-JAC）在[iso639.prin]中包含以下声明：
"A language code already in ISO 639-2 at the point of freezing ISO 639-1 shall not later be added to ISO 639-1. This is to ensure consistency in usage over time, since users are directed in Internet applications to employ the alpha-3 code when an alpha-2 code for that language is not available."
“在ISO 639-1冻结时，ISO 639-2中已经存在的语言代码以后不得添加到ISO 639-1中。这是为了确保随着时间的推移使用的一致性，因为在互联网应用程序中，当该语言的alpha-2代码不可用时，用户被指示使用alpha-3代码。”
In order to avoid instability in the canonical form of tags, if a two-character code is added to ISO 639-1 for a language for which a three-character code was already included in ISO 639-2, the two-character code MUST NOT be registered. See Section 3.4.
为了避免标签规范形式的不稳定性，如果在ISO 639-2中已包含三字符代码的语言的ISO 639-1中添加了两字符代码，则不得注册两字符代码。见第3.4节。
For example, if some content were tagged with 'haw' (Hawaiian), which currently has no two-character code, the tag would not be invalidated if ISO 639-1 were to assign a two-character code to the Hawaiian language at a later date.
例如，如果某些内容被标记为“haw”（夏威夷语），目前没有两个字符的代码，那么如果ISO 639-1稍后将两个字符的代码分配给夏威夷语，则标记不会失效。
For example, one of the grandfathered IANA registrations is "i-enochian". The subtag 'enochian' could be registered in the IANA registry as a primary language subtag (assuming that ISO 639 does not register this language first), making tags such as "enochian-AQ" and "enochian-Latn" valid.
例如，IANA的祖父注册之一是“i-enochian”。子标签“enochian”可以在IANA注册中心注册为主要语言子标签（假设ISO 639没有首先注册该语言），使“enochian AQ”和“enochian Latn”等标签有效。
The following rules apply to the extended language subtags:
以下规则适用于扩展语言子标签：
1. Three-letter subtags immediately following the primary subtag are reserved for future standardization, anticipating work that is currently under way on ISO 639.
1. 紧跟在主要子标签之后的三个字母子标签保留用于未来的标准化，预计ISO 639目前正在进行的工作。
2. Extended language subtags MUST follow the primary subtag and precede any other subtags.
2. 扩展语言子标签必须位于主子标签之后，并位于任何其他子标签之前。
3. There MAY be up to three extended language subtags.
3. 最多可以有三个扩展语言子标签。
4. Extended language subtags MUST NOT be registered or used to form language tags. Their syntax is described here so that implementations can be compatible with any future revision of this document that does provide for their registration.
4. 扩展语言子标签不得注册或用于形成语言标签。这里描述了它们的语法，以便实现能够与本文档的任何未来版本兼容，该版本确实提供了它们的注册。
Extended language subtag records, once they appear in the registry, MUST include exactly one 'Prefix' field indicating an appropriate language subtag or sequence of subtags that MUST always appear as a prefix to the extended language subtag.
它们必须作为扩展AGS或SUBSTAG的前缀在注册表中显示一次，表明SUBSTAG记录必须始终作为SUBSTAG的一种语言前缀出现。
Example: In a future revision or update of this document, the tag "zh-gan" (registered under RFC 3066) might become a valid non-grandfathered (that is, redundant) tag in which the subtag 'gan' might represent the Chinese dialect 'Gan'.
示例：在本文档的未来修订或更新中，标记“zh-gan”（根据RFC 3066注册）可能会成为有效的非祖父（即冗余）标记，其中子标记“gan”可能代表汉语方言“gan”。
Script subtags are used to indicate the script or writing system variations that distinguish the written forms of a language or its dialects. The following rules apply to the script subtags:
脚本子标签用于表示区分语言或方言书面形式的脚本或书写系统变体。以下规则适用于脚本子标签：
1. All four-character subtags were defined according to [ISO15924]--"Codes for the representation of names of scripts": alpha-4 script codes, or subsequently assigned by the ISO 15924 maintenance agency or governing standardization bodies, denoting the script or writing system used in conjunction with this language.
1. 所有四个字符的子标签均根据[ISO15924]-“脚本名称表示代码”：alpha-4脚本代码定义，或随后由ISO 15924维护机构或管理标准化机构指定，表示与该语言结合使用的脚本或书写系统。
2. Script subtags MUST immediately follow the primary language subtag and all extended language subtags and MUST occur before any other type of subtag described below.
2. 脚本子标记必须紧跟在主语言子标记和所有扩展语言子标记之后，并且必须出现在下面描述的任何其他类型的子标记之前。
3. The script subtags 'Qaaa' through 'Qabx' are reserved for private use in language tags. These subtags correspond to codes reserved by ISO 15924 for private use. These codes MAY be used for non-registered script values. Please refer to Section 4.5 for more information on private use subtags.
3. 脚本子标记“Qaaa”到“Qabx”在语言标记中保留供私人使用。这些子标签对应于ISO 15924保留供私人使用的代码。这些代码可用于未注册的脚本值。有关专用子标签的更多信息，请参阅第4.5节。
4. Script subtags MUST NOT be registered using the process in Section 3.5 of this document. Variant subtags MAY be considered for registration for that purpose.
4. 不得使用本文件第3.5节中的流程注册脚本子标签。为此，可考虑注册变体子标签。
5. There MUST be at most one script subtag in a language tag, and the script subtag SHOULD be omitted when it adds no distinguishing value to the tag or when the primary language subtag's record includes a Suppress-Script field listing the applicable script subtag.
5. 一个语言标记中最多必须有一个脚本子标记，如果脚本子标记未向标记添加区分值，或者主语言子标记的记录包含列出适用脚本子标记的抑制脚本字段，则应忽略该脚本子标记。
Example: "sr-Latn" represents Serbian written using the Latin script.
示例：“sr Latn”表示使用拉丁语书写的塞尔维亚语。
Region subtags are used to indicate linguistic variations associated with or appropriate to a specific country, territory, or region. Typically, a region subtag is used to indicate regional dialects or usage, or region-specific spelling conventions. A region subtag can also be used to indicate that content is expressed in a way that is appropriate for use throughout a region, for instance, Spanish content tailored to be useful throughout Latin America.
区域子标签用于表示与特定国家、地区或地区相关或适用的语言变体。通常，区域子标记用于表示区域方言或用法，或特定于区域的拼写约定。区域子标签也可用于表示内容以适合整个区域使用的方式表达，例如，西班牙语内容适合整个拉丁美洲使用。
The following rules apply to the region subtags:
以下规则适用于区域子标记：
1. Region subtags MUST follow any language, extended language, or script subtags and MUST precede all other subtags.
1. 区域子标记必须位于任何语言、扩展语言或脚本子标记之后，并且必须位于所有其他子标记之前。
2. All two-character subtags following the primary subtag were defined in the IANA registry according to the assignments found in [ISO3166-1] ("Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes") using the list of alpha-2 country codes, or using assignments subsequently made by the ISO 3166 maintenance agency or governing standardization bodies.
2. 根据[ISO3166-1]（“国家及其子区名称表示代码——第1部分：国家代码”）中的分配，使用alpha-2国家代码列表，在IANA注册中心定义了主子标记后面的所有两个字符的子标记，或使用ISO 3166维护机构或管理标准化机构随后制定的任务。
3. All three-character subtags consisting of digit (numeric) characters following the primary subtag were defined in the IANA registry according to the assignments found in UN Standard Country or Area Codes for Statistical Use [UN_M.49] or assignments subsequently made by the governing standards body. Note that not all of the UN M.49 codes are defined in the IANA registry. The following rules define which codes are entered into the registry as valid subtags:
3. 根据联合国统计使用标准国家或地区代码[UN_M.49]中的分配或管理标准机构随后进行的分配，在IANA注册中心定义了所有三个字符的子标签，包括主子标签后面的数字（数字）字符。请注意，并非所有UN M.49代码都在IANA注册表中定义。以下规则定义哪些代码作为有效子标记输入注册表：
A. UN numeric codes assigned to 'macro-geographical (continental)' or sub-regions MUST be registered in the registry. These codes are not associated with an assigned ISO 3166 alpha-2 code and represent supra-national areas, usually covering more than one nation, state, province, or territory.
A.分配给“宏观地理（大陆）”或子区域的非数字代码必须在注册表中注册。这些代码与指定的ISO 3166 alpha-2代码无关，代表超国家区域，通常覆盖多个国家、州、省或地区。
B. UN numeric codes for 'economic groupings' or 'other groupings' MUST NOT be registered in the IANA registry and MUST NOT be used to form language tags.
B.“经济分组”或“其他分组”的联合国数字代码不得在IANA注册表中注册，也不得用于形成语言标签。
C. UN numeric codes for countries or areas with ambiguous ISO 3166 alpha-2 codes, when entered into the registry, MUST be defined according to the rules in Section 3.4 and MUST be used to form language tags that represent the country or region for which they are defined.
C.对于ISO 3166 alpha-2代码不明确的国家或地区，当输入注册时，必须根据第3.4节中的规则定义联合国数字代码，并且必须用于形成代表其定义国家或地区的语言标签。
D. UN numeric codes for countries or areas for which there is an associated ISO 3166 alpha-2 code in the registry MUST NOT be entered into the registry and MUST NOT be used to form language tags. Note that the ISO 3166-based subtag in the registry MUST actually be associated with the UN M.49 code in question.
D.注册表中存在相关ISO 3166 alpha-2代码的国家或地区的联合国数字代码不得输入注册表，也不得用于形成语言标签。请注意，注册表中基于ISO 3166的子标记实际上必须与所讨论的UN M.49代码相关联。
E. UN numeric codes and ISO 3166 alpha-2 codes for countries or areas listed as eligible for registration in [RFC4645] but not presently registered MAY be entered into the IANA registry via the process described in Section 3.5. Once registered, these codes MAY be used to form language tags.
E.对于[RFC4645]中列出的有资格注册但目前尚未注册的国家或地区，可通过第3.5节所述的流程将联合国数字代码和ISO 3166字母-2代码输入IANA注册中心。一旦注册，这些代码可用于形成语言标签。
F. All other UN numeric codes for countries or areas that do not have an associated ISO 3166 alpha-2 code MUST NOT be entered into the registry and MUST NOT be used to form language tags. For more information about these codes, see Section 3.4.
F.不具有相关ISO 3166 alpha-2代码的国家或地区的所有其他联合国数字代码不得输入注册表，也不得用于形成语言标签。有关这些代码的更多信息，请参见第3.4节。
4. Note: The alphanumeric codes in Appendix X of the UN document MUST NOT be entered into the registry and MUST NOT be used to form language tags. (At the time this document was created, these values matched the ISO 3166 alpha-2 codes.)
4. 注：联合国文件附录X中的字母数字代码不得输入登记册，也不得用于形成语言标签。（创建本文档时，这些值与ISO 3166 alpha-2代码匹配。）
5. There MUST be at most one region subtag in a language tag and the region subtag MAY be omitted, as when it adds no distinguishing value to the tag.
5. 语言标记中最多必须有一个region子标记，并且region子标记可以省略，因为它不会向标记添加任何区分值。
6. The region subtags 'AA', 'QM'-'QZ', 'XA'-'XZ', and 'ZZ' are reserved for private use in language tags. These subtags correspond to codes reserved by ISO 3166 for private use. These codes MAY be used for private use region subtags (instead of using a private use subtag sequence). Please refer to Section 4.5 for more information on private use subtags.
6. 区域子标签'AA'、'QM'-'QZ'、'XA'-'XZ'和'ZZ'在语言标签中保留供私人使用。这些子标签对应于ISO 3166保留供私人使用的代码。这些代码可用于专用区域子标记（而不是使用专用子标记序列）。有关专用子标签的更多信息，请参阅第4.5节。
"de-CH" represents German ('de') as used in Switzerland ('CH').
“de CH”代表瑞士（“CH”）使用的德语（“de”）。
"sr-Latn-CS" represents Serbian ('sr') written using Latin script ('Latn') as used in Serbia and Montenegro ('CS').
“sr Latn CS”代表塞尔维亚语（“sr”），使用塞尔维亚和黑山语（“CS”）中使用的拉丁语书写（“Latn”）。
"es-419" represents Spanish ('es') appropriate to the UN-defined Latin America and Caribbean region ('419').
“es-419”代表适用于联合国定义的拉丁美洲和加勒比地区（“419”）的西班牙语（“es”）。
Variant subtags are used to indicate additional, well-recognized variations that define a language or its dialects that are not covered by other available subtags. The following rules apply to the variant subtags:
变体子标签用于表示其他公认的变体，这些变体定义了其他可用子标签未涵盖的语言或方言。以下规则适用于变量子标签：
1. Variant subtags are not associated with any external standard. Variant subtags and their meanings are defined by the registration process defined in Section 3.5.
1. 变量子标签不与任何外部标准关联。变体子标签及其含义由第3.5节中定义的注册过程定义。
2. Variant subtags MUST follow all of the other defined subtags, but precede any extension or private use subtag sequences.
2. 变体子标记必须跟在所有其他定义的子标记之后，但必须在任何扩展或专用子标记序列之前。
3. More than one variant MAY be used to form the language tag.
3. 可以使用多个变体来形成语言标记。
4. Variant subtags MUST be registered with IANA according to the rules in Section 3.5 of this document before being used to form language tags. In order to distinguish variants from other types of subtags, registrations MUST meet the following length and content restrictions:
4. 变体子标签必须根据本文件第3.5节中的规则在IANA注册，然后才能用于形成语言标签。为了将变体与其他类型的子标签区分开来，注册必须满足以下长度和内容限制：
1. Variant subtags that begin with a letter (a-z, A-Z) MUST be at least five characters long.
1. 以字母（a-z，a-z）开头的变体子标签长度必须至少为五个字符。
2. Variant subtags that begin with a digit (0-9) MUST be at least four characters long.
2. 以数字（0-9）开头的变体子标签长度必须至少为四个字符。
Variant subtag records in the language subtag registry MAY include one or more 'Prefix' fields, which indicate the language tag or tags that would make a suitable prefix (with other subtags, as appropriate) in forming a language tag with the variant. For example, the subtag 'nedis' has a Prefix of "sl", making it suitable to form language tags such as "sl-nedis" and "sl-IT-nedis", but not suitable for use in a tag such as "zh-nedis" or "it-IT-nedis".
语言子标记注册表中的变体子标记记录可能包括一个或多个“前缀”字段，这些字段指示在使用变体形成语言标记时将产生合适前缀（与其他子标记一起，视情况而定）的一个或多个语言标记。例如，子标记“nedis”具有前缀“sl”，使得其适合形成诸如“sl nedis”和“sl it nedis”之类的语言标记，但不适合在诸如“zh nedis”或“it nedis”之类的标记中使用。
"sl-nedis" represents the Natisone or Nadiza dialect of Slovenian.
“sl nedis”代表斯洛文尼亚的Natisone或Nadiza方言。
"de-CH-1996" represents German as used in Switzerland and as written using the spelling reform beginning in the year 1996 C.E.
“de-CH-1996”代表瑞士使用的德语，以及1996年开始采用拼写改革的德语。
Most variants that share a prefix are mutually exclusive. For example, the German orthographic variations '1996' and '1901' SHOULD NOT be used in the same tag, as they represent the dates of different spelling reforms. A variant that can meaningfully be used in combination with another variant SHOULD include a 'Prefix' field in its registry record that lists that other variant. For example, if another German variant 'example' were created that made sense to use with '1996', then 'example' should include two Prefix fields: "de" and "de-1996".
大多数共享前缀的变体是互斥的。例如，德语拼写变体“1996”和“1901”不应在同一个标记中使用，因为它们代表不同拼写改革的日期。可以有意义地与其他变体结合使用的变体应在其注册表记录中包含一个“前缀”字段，该字段列出了其他变体。例如，如果创建的另一个德语变体“example”与“1996”配合使用，则“example”应包含两个前缀字段：“de”和“de-1996”。
Extensions provide a mechanism for extending language tags for use in various applications. See Section 3.7. The following rules apply to extensions:
扩展提供了一种机制来扩展语言标记，以在各种应用程序中使用。见第3.7节。以下规则适用于扩展：
1. Extension subtags are separated from the other subtags defined in this document by a single-character subtag ("singleton"). The singleton MUST be one allocated to a registration authority via the mechanism described in Section 3.7 and MUST NOT be the letter 'x', which is reserved for private use subtag sequences.
1. 扩展子标签与本文档中定义的其他子标签通过单个字符子标签（“singleton”）进行分隔。单件必须是通过第3.7节所述机制分配给注册机构的单件，不得为字母“x”，该字母保留给私人使用的子标签序列。
2. Note: Private use subtag sequences starting with the singleton subtag 'x' are described in Section 2.2.7 below.
2. 注：以下第2.2.7节描述了以单例子标记“x”开头的专用子标记序列。
3. An extension MUST follow at least a primary language subtag. That is, a language tag cannot begin with an extension. Extensions extend language tags, they do not override or replace them. For example, "a-value" is not a well-formed language tag, while "de-a-value" is.
3. 扩展必须至少跟在主语言子标记后面。也就是说，语言标记不能以扩展名开头。扩展扩展扩展了语言标记，它们不会覆盖或替换它们。例如，“a-value”不是格式良好的语言标记，而“de-a-value”是。
4. Each singleton subtag MUST appear at most one time in each tag (other than as a private use subtag). That is, singleton subtags MUST NOT be repeated. For example, the tag "en-a-bbb-a-ccc" is invalid because the subtag 'a' appears twice. Note that the tag "en-a-bbb-x-a-ccc" is valid because the second appearance of the singleton 'a' is in a private use sequence.
4. 每个单例子标记必须在每个标记中最多出现一次（专用子标记除外）。也就是说，单例子标记不能重复。例如，标记“en-a-bbb-a-ccc”无效，因为子标记“a”出现两次。请注意，标记“en-a-bbb-x-a-ccc”是有效的，因为单例“a”的第二次出现是在一个私人使用序列中。
5. Extension subtags MUST meet all of the requirements for the content and format of subtags defined in this document.
5. 扩展子标签必须满足本文件中定义的子标签内容和格式的所有要求。
6. Extension subtags MUST meet whatever requirements are set by the document that defines their singleton prefix and whatever requirements are provided by the maintaining authority.
6. 扩展子标签必须满足定义其单例前缀的文档设置的任何要求以及维护机构提供的任何要求。
7. Each extension subtag MUST be from two to eight characters long and consist solely of letters or digits, with each subtag separated by a single '-'.
7. 每个扩展子标记的长度必须为2到8个字符，并且仅由字母或数字组成，每个子标记之间用单个“-”分隔。
8. Each singleton MUST be followed by at least one extension subtag. For example, the tag "tlh-a-b-foo" is invalid because the first singleton 'a' is followed immediately by another singleton 'b'.
8. 每个单例后必须至少有一个扩展子标记。例如，标记“tlh-a-b-foo”无效，因为第一个单例“a”后面紧跟着另一个单例“b”。
9. Extension subtags MUST follow all language, extended language, script, region, and variant subtags in a tag.
9. 扩展子标签必须跟随标签中的所有语言、扩展语言、脚本、区域和变体子标签。
10. All subtags following the singleton and before another singleton are part of the extension. Example: In the tag "fr-a-Latn", the subtag 'Latn' does not represent the script subtag 'Latn' defined in the IANA Language Subtag Registry. Its meaning is defined by the extension 'a'.
10. 单例之后和另一单例之前的所有子标记都是扩展的一部分。示例：在标记“fr-a-Latn”中，子标记“Latn”不表示IANA语言子标记注册表中定义的脚本子标记“Latn”。其含义由扩展名“a”定义。
11. In the event that more than one extension appears in a single tag, the tag SHOULD be canonicalized as described in Section 4.4.
11. 如果单个标记中出现多个扩展，则应按照第4.4节所述规范化标记。
For example, if the prefix singleton 'r' and the shown subtags were defined, then the following tag would be a valid example: "en-Latn-GB-boont-r-extended-sequence-x-private".
例如，如果定义了前缀singleton'r'和显示的子标记，那么下面的标记将是一个有效的示例：“en-Latn-GB-boont-r-extended-sequence-x-private”。
Private use subtags are used to indicate distinctions in language important in a given context by private agreement. The following rules apply to private use subtags:
私用子标签是指在特定语境下，通过私用协议在语言上的重要区别。以下规则适用于专用子标签：
1. Private use subtags are separated from the other subtags defined in this document by the reserved single-character subtag 'x'.
1. 专用子标签通过保留的单字符子标签“x”与本文档中定义的其他子标签分开。
2. Private use subtags MUST conform to the format and content constraints defined in the ABNF for all subtags.
2. 专用子标签必须符合ABNF中为所有子标签定义的格式和内容约束。
3. Private use subtags MUST follow all language, extended language, script, region, variant, and extension subtags in the tag. Another way of saying this is that all subtags following the singleton 'x' MUST be considered private use. Example: The subtag 'US' in the tag "en-x-US" is a private use subtag.
3. 专用子标签必须位于标签中的所有语言、扩展语言、脚本、区域、变体和扩展子标签之后。另一种说法是，单例“x”后面的所有子标记都必须被视为专用。示例：标记“en-x-US”中的子标记“US”是一个专用子标记。
4. A tag MAY consist entirely of private use subtags.
4. 标记可以完全由专用子标记组成。
5. No source is defined for private use subtags. Use of private use subtags is by private agreement only.
5. 没有为专用子标记定义源。仅通过私人协议使用私人使用子标签。
6. Private use subtags are NOT RECOMMENDED where alternatives exist or for general interchange. See Section 4.5 for more information on private use subtag choice.
6. 如果存在替代方案或用于一般交换，则不建议使用专用子标签。有关专用子标签选择的更多信息，请参见第4.5节。
For example: Users who wished to utilize codes from the Ethnologue publication of SIL International for language identification might agree to exchange tags such as "az-Arab-x-AZE-derbend". This example contains two private use subtags. The first is 'AZE' and the second is 'derbend'.
例如：希望使用SIL国际民族志出版物中的代码进行语言识别的用户可能同意交换标签，如“az-Arab-x-AZE-derbend”。此示例包含两个专用子标签。第一个是“AZE”，第二个是“derbend”。
Existing IANA-registered language tags from RFC 1766 and/or RFC 3066 maintain their validity. These tags will be maintained in the registry in records of either the "grandfathered" or "redundant" type. Grandfathered tags contain one or more subtags that are not defined in the Language Subtag Registry (see Section 3). Redundant tags consist entirely of subtags defined above and whose independent registration is superseded by this document. For more information, see Section 3.8.
来自RFC 1766和/或RFC 3066的现有IANA注册语言标记保持其有效性。这些标记将保存在注册表中的“grandfathered”或“redundant”类型的记录中。Grandfathered标记包含一个或多个子标记，这些子标记未在语言子标记注册表中定义（请参见第3节）。冗余标记完全由上面定义的子标记组成，其独立注册被本文档取代。有关更多信息，请参见第3.8节。
It is important to note that all language tags formed under the guidelines in this document were either legal, well-formed tags or could have been registered under RFC 3066.
需要注意的是，根据本文件指南形成的所有语言标签都是合法的、格式良好的标签，或者可以根据RFC 3066注册。
Implementations sometimes need to describe their capabilities with regard to the rules and practices described in this document. There are two classes of conforming implementations described by this document: "well-formed" processors and "validating" processors. Claims of conformance SHOULD explicitly reference one of these definitions.
实现有时需要根据本文档中描述的规则和实践来描述它们的功能。本文档描述了两类一致性实现：“格式良好”处理器和“验证”处理器。一致性声明应明确引用其中一个定义。
An implementation that claims to check for well-formed language tags MUST:
声称检查格式良好的语言标记的实现必须：
o Check that the tag and all of its subtags, including extension and private use subtags, conform to the ABNF or that the tag is on the list of grandfathered tags.
o 检查标签及其所有子标签（包括扩展子标签和专用子标签）是否符合ABNF或标签是否在父辈标签列表中。
o Check that singleton subtags that identify extensions do not repeat. For example, the tag "en-a-xx-b-yy-a-zz" is not well-formed.
o 检查标识扩展的单例子标记是否不重复。例如，标签“en-a-xx-b-yy-a-zz”的格式不正确。
Well-formed processors are strongly encouraged to implement the canonicalization rules contained in Section 4.4.
强烈鼓励格式良好的处理器执行第4.4节中包含的规范化规则。
An implementation that claims to be validating MUST:
声称正在验证的实现必须：
o Check that the tag is well-formed.
o 检查标签的格式是否正确。
o Specify the particular registry date for which the implementation performs validation of subtags.
o 指定实现执行子标记验证的特定注册表日期。
o Check that either the tag is a grandfathered tag, or that all language, script, region, and variant subtags consist of valid codes for use in language tags according to the IANA registry as of the particular date specified by the implementation.
o 检查标记是否为祖父标记，或者所有语言、脚本、区域和变体子标记是否包含有效代码，以便在实现指定的特定日期根据IANA注册表在语言标记中使用。
o Specify which, if any, extension RFCs as defined in Section 3.7 are supported, including version, revision, and date.
o 指定支持第3.7节中定义的扩展RFC（如有），包括版本、修订和日期。
o For any such extensions supported, check that all subtags used in that extension are valid.
o 对于支持的任何此类扩展，请检查该扩展中使用的所有子标记是否有效。
o For variant and extended language subtags, if the registry contains one or more 'Prefix' fields for that subtag, check that the tag matches at least one prefix. The tag matches if all the
o 对于变体和扩展语言子标记，如果注册表包含该子标记的一个或多个“前缀”字段，请检查标记是否与至少一个前缀匹配。如果所有
subtags in the 'Prefix' also appear in the tag. For example, the prefix "es-CO" matches the tag "es-Latn-CO-x-private" because both the 'es' language subtag and 'CO' region subtag appear in the tag.
“前缀”中的子标记也出现在标记中。例如，前缀“es CO”与标记“es-Latn-CO-x-private”匹配，因为“es”语言子标记和“CO”区域子标记都出现在标记中。
This section defines the Language Subtag Registry and the maintenance and update procedures associated with it, as well as a registry for extensions to language tags (Section 3.7).
本节定义了Language Subtag注册表及其相关的维护和更新过程，以及Language标签扩展注册表（第3.7节）。
The Language Subtag Registry contains a comprehensive list of all of the subtags valid in language tags. This allows implementers a straightforward and reliable way to validate language tags. The Language Subtag Registry will be maintained so that, except for extension subtags, it is possible to validate all of the subtags that appear in a language tag under the provisions of this document or its revisions or successors. In addition, the meaning of the various subtags will be unambiguous and stable over time. (The meaning of private use subtags, of course, is not defined by the IANA registry.)
Language Subtag注册表包含语言标记中有效的所有子标记的综合列表。这使实现人员能够以一种简单可靠的方式验证语言标记。将维护语言子标签注册，以便除扩展子标签外，可以根据本文件或其修订版或后续版本的规定验证语言标签中出现的所有子标签。此外，随着时间的推移，各子标签的含义将是明确和稳定的。（当然，IANA注册中心没有定义私人使用子标签的含义。）
The IANA Language Subtag Registry ("the registry") consists of a text file that is machine readable in the format described in this section, plus copies of the registration forms approved in accordance with the process described in Section 3.5. The existing registration forms for grandfathered and redundant tags taken from RFC 3066 will be maintained as part of the obsolete RFC 3066 registry. The remaining set of initial subtags will not have registration forms created for them.
IANA语言子标签注册中心（“注册中心”）由一个文本文件组成，该文本文件以本节所述的格式进行机器可读，加上根据第3.5节所述流程批准的注册表格副本。从RFC 3066获取的祖父和冗余标签的现有登记表将作为过时RFC 3066注册表的一部分进行维护。剩余的初始子标签集将不会为其创建注册表。
The registry is in the text format described below. This format was based on the record-jar format described in [record-jar].
注册表的文本格式如下所述。此格式基于[record jar]中描述的记录jar格式。
Each line of text is limited to 72 characters, including all whitespace. Records are separated by lines containing only the sequence "%%" (%x25.25).
每行文本限制为72个字符，包括所有空格。记录由仅包含序列“%%”（%x25.25）的行分隔。
Each field can be viewed as a single, logical line of ASCII characters, comprising a field-name and a field-body separated by a COLON character (%x3A). For convenience, the field-body portion of this conceptual entity can be split into a multiple-line representation; this is called "folding". The format of the registry is described by the following ABNF (per [RFC4234]):
可以将每个字段视为ASCII字符的单个逻辑行，包括字段名和字段正文，字段正文由冒号字符（%x3A）分隔。为方便起见，该概念实体的字段主体部分可拆分为多行表示；这就是所谓的“折叠”。注册表的格式由以下ABNF描述（根据[RFC4234]）：
registry = record *("%%" CRLF record)
record = 1*( field-name *SP ":" *SP field-body CRLF )
field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
field-body = *(ASCCHAR/LWSP)
ASCCHAR = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26
UNICHAR = "&#x" 2*6HEXDIG ";"
registry = record *("%%" CRLF record)
record = 1*( field-name *SP ":" *SP field-body CRLF )
field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)]
field-body = *(ASCCHAR/LWSP)
ASCCHAR = %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26
UNICHAR = "&#x" 2*6HEXDIG ";"
Figure 2: Registry Format ABNF
图2：注册表格式ABNF
The sequence '..' (%x2E.2E) in a field-body denotes a range of values. Such a range represents all subtags of the same length that are in alphabetic or numeric order within that range, including the values explicitly mentioned. For example 'a..c' denotes the values 'a', 'b', and 'c' and '11..13' denotes the values '11', '12', and '13'.
字段正文中的序列“..”（%x2E.2E）表示一个值范围。该范围表示该范围内以字母或数字顺序排列的相同长度的所有子标签，包括明确提到的值。例如，“a..c”表示值“a”、“b”和“c”，而“11..13”表示值“11”、“12”和“13”。
Characters from outside the US-ASCII [ISO646] repertoire, as well as the AMPERSAND character ("&", %x26) when it occurs in a field-body, are represented by a "Numeric Character Reference" using hexadecimal notation in the style used by [XML10] (see <http://www.w3.org/TR/REC-xml/#dt-charref>). This consists of the sequence "&#x" (%x26.23.78) followed by a hexadecimal representation of the character's code point in [ISO10646] followed by a closing semicolon (%x3B). For example, the EURO SIGN, U+20AC, would be represented by the sequence "€". Note that the hexadecimal notation MAY have between two and six digits.
US-ASCII[ISO646]指令表之外的字符，以及出现在字段体中的符号和字符（&），%x26），由使用十六进制表示法的“数字字符引用”表示，采用[XML10]使用的样式（参见<http://www.w3.org/TR/REC-xml/#dt-charref>）。这包括序列“&#x”（%x26.23.78），后面是[ISO10646]中字符代码点的十六进制表示形式，后面是结束分号（%x3B）。例如，欧元符号U+20AC将由序列“€；”表示。请注意，十六进制表示法可能有两到六位数字。
All fields whose field-body contains a date value use the "full-date" format specified in [RFC3339]. For example: "2004-06-28" represents June 28, 2004, in the Gregorian calendar.
字段正文包含日期值的所有字段均使用[RFC3339]中指定的“完整日期”格式。例如：“2004-06-28”代表公历中的2004年6月28日。
The first record in the file contains the single field whose field-name is "File-Date" (see Figure 3). The field-body of this record contains the last modification date of this copy of the registry, making it possible to compare different versions of the registry. The registry on the IANA website is the most current. Versions with an older date than that one are not up-to-date.
文件中的第一条记录包含一个字段，其字段名为“file Date”（见图3）。此记录的字段正文包含此注册表副本的上次修改日期，从而可以比较注册表的不同版本。IANA网站上的注册是最新的。日期早于该日期的版本不是最新版本。
File-Date: 2004-06-28 %%
提交日期：2004-06-28%
Figure 3: Example of the File-Date Record
图3：文件日期记录的示例
Subsequent records represent subtags in the registry. Each of the fields in each record MUST occur no more than once, unless otherwise noted below. Each record MUST contain the following fields:
后续记录表示注册表中的子标记。除非下文另有说明，否则每条记录中的每个字段不得出现一次。每个记录必须包含以下字段：
o 'Type'
o “类型”
* Type's field-value MUST consist of one of the following strings: "language", "extlang", "script", "region", "variant", "grandfathered", and "redundant" and denotes the type of tag or subtag.
* 类型的字段值必须由以下字符串之一组成：“语言”、“extlang”、“脚本”、“区域”、“变体”、“祖父”和“冗余”，并表示标记或子标记的类型。
o Either 'Subtag' or 'Tag'
o “子标签”或“标签”
* Subtag's field-value contains the subtag being defined. This field MUST only appear in records of whose 'Type' has one of these values: "language", "extlang", "script", "region", or "variant".
* 子标记的字段值包含正在定义的子标记。此字段只能出现在“类型”具有以下值之一的记录中：“语言”、“extlang”、“脚本”、“区域”或“变体”。
* Tag's field-value contains a complete language tag. This field MUST only appear in records whose 'Type' has one of these values: "grandfathered" or "redundant". Note that the field-value will always follow the 'grandfathered' production in the ABNF in Section 2.1
* 标记的字段值包含完整的语言标记。此字段只能出现在“Type”具有以下值之一的记录中：“grandfathered”或“redundant”。请注意，字段值将始终遵循第2.1节ABNF中的“grandfathered”生成
o Description
o 描述
* Description's field-value contains a non-normative description of the subtag or tag.
* 描述的字段值包含子标记或标记的非规范性描述。
o Added
o 补充
* Added's field-value contains the date the record was added to the registry.
* Added的字段值包含记录添加到注册表的日期。
The 'Subtag' or 'Tag' field MUST use lowercase letters to form the subtag or tag, with two exceptions. Subtags whose 'Type' field is 'script' (in other words, subtags defined by ISO 15924) MUST use titlecase. Subtags whose 'Type' field is 'region' (in other words, subtags defined by ISO 3166) MUST use uppercase. These exceptions mirror the use of case in the underlying standards.
“Subtag”或“Tag”字段必须使用小写字母构成Subtag或Tag，但有两个例外。“Type”字段为“script”的子标签（换句话说，ISO 15924定义的子标签）必须使用titlecase。“Type”字段为“region”的子标记（换句话说，ISO 3166定义的子标记）必须使用大写。这些例外情况反映了基本标准中case的用法。
The field 'Description' MAY appear more than one time and contains a description of the tag or subtag in the record. At least one of the 'Description' fields MUST be written or transcribed into the Latin script; the same or additional fields MAY also include a description in a non-Latin script. The 'Description' field is used for identification purposes and SHOULD NOT be taken to represent the actual native name of the language or variation or to be in any particular language. Most descriptions are taken directly from source standards such as ISO 639 or ISO 3166.
字段“Description”可能出现多次，并包含记录中标记或子标记的描述。必须将至少一个“描述”字段写入或转录成拉丁文字；相同或附加字段还可以包括非拉丁语脚本中的描述。“描述”字段用于识别目的，不应被视为代表语言或变体的实际本地名称，也不应被视为使用任何特定语言。大多数描述直接取自ISO 639或ISO 3166等源标准。
Note: Descriptions in registry entries that correspond to ISO 639, ISO 15924, ISO 3166, or UN M.49 codes are intended only to indicate the meaning of that identifier as defined in the source standard at the time it was added to the registry. The description does not replace the content of the source standard itself. The descriptions are not intended to be the English localized names for the subtags. Localization or translation of language tag and subtag descriptions is out of scope of this document.
注：对应于ISO 639、ISO 15924、ISO 3166或UN M.49代码的注册表项中的描述仅用于指示源标准中添加到注册表时定义的标识符的含义。该说明不替换源标准本身的内容。这些描述不是子标签的英文本地化名称。语言标记和子标记描述的本地化或翻译不在本文档范围内。
Each record MAY also contain the following fields:
每个记录还可以包含以下字段：
o Preferred-Value
o 优先值
* For fields of type 'language', 'extlang', 'script', 'region', and 'variant', 'Preferred-Value' contains the subtag of the same 'Type' that is preferred for forming the language tag.
* 对于“language”、“extlang”、“script”、“region”和“variant”类型的字段，“Preferred Value”包含构成语言标记首选的相同“type”的子标记。
* For fields of type 'grandfathered' and 'redundant', a canonical mapping to a complete language tag.
* 对于“grandfathered”和“redundant”类型的字段，是到完整语言标记的规范映射。
o Deprecated
o 不赞成
* Deprecated's field-value contains the date the record was deprecated.
* 弃用的字段值包含记录弃用的日期。
o Prefix
o 前缀
* Prefix's field-value contains a language tag with which this subtag MAY be used to form a new language tag, perhaps with other subtags as well. This field MUST only appear in records whose 'Type' field-value is 'variant' or 'extlang'. For example, the 'Prefix' for the variant 'nedis' is 'sl', meaning that the tags "sl-nedis" and "sl-IT-nedis" might be appropriate while the tag "is-nedis" is not.
* Prefix的字段值包含一个语言标记，该子标记可用于形成一个新的语言标记，也可用于其他子标记。此字段只能出现在“Type”字段值为“variant”或“extlang”的记录中。例如，变体“nedis”的“前缀”为“sl”，这意味着标记“sl nedis”和“sl IT nedis”可能合适，而标记“is nedis”则不合适。
o Comments
o 评论
* Comments contains additional information about the subtag, as deemed appropriate for understanding the registry and implementing language tags using the subtag or tag.
* 注释包含关于子标记的附加信息，这对于理解注册表和使用子标记或标记实现语言标记是合适的。
o Suppress-Script
o 抑制脚本
* Suppress-Script contains a script subtag that SHOULD NOT be used to form language tags with the associated primary language subtag. This field MUST only appear in records whose 'Type' field-value is 'language'. See Section 4.1.
* 抑制脚本包含的脚本子标记不应用于与关联的主语言子标记形成语言标记。此字段只能出现在“类型”字段值为“语言”的记录中。见第4.1节。
The field 'Deprecated' MAY be added to any record via the maintenance process described in Section 3.3 or via the registration process described in Section 3.5. Usually, the addition of a 'Deprecated' field is due to the action of one of the standards bodies, such as ISO 3166, withdrawing a code. In some historical cases, it might not have been possible to reconstruct the original deprecation date. For these cases, an approximate date appears in the registry. Although valid in language tags, subtags and tags with a 'Deprecated' field are deprecated and validating processors SHOULD NOT generate these subtags. Note that a record that contains a 'Deprecated' field and no corresponding 'Preferred-Value' field has no replacement mapping.
“已弃用”字段可通过第3.3节所述的维护过程或第3.5节所述的注册过程添加到任何记录中。通常，添加“弃用”字段是由于某个标准机构（如ISO 3166）撤消代码的行为。在某些历史案例中，可能无法重建原始折旧日期。对于这些情况，注册表中会显示一个大致日期。虽然在语言标记中有效，但子标记和带有“已弃用”字段的标记已弃用，验证处理器不应生成这些子标记。请注意，包含“已弃用”字段且没有相应“首选值”字段的记录没有替换映射。
The field 'Preferred-Value' contains a mapping between the record in which it appears and another tag or subtag. The value in this field is STRONGLY RECOMMENDED as the best choice to represent the value of this record when selecting a language tag. These values form three groups:
“首选值”字段包含它出现的记录与另一个标记或子标记之间的映射。强烈建议在选择语言标记时，将此字段中的值作为表示此记录值的最佳选择。这些值分为三组：
1. ISO 639 language codes that were later withdrawn in favor of other codes. These values are mostly a historical curiosity.
1. ISO 639语言代码，后来被撤销，取而代之的是其他代码。这些价值观大多是一种历史好奇心。
2. ISO 3166 region codes that have been withdrawn in favor of a new code. This sometimes happens when a country changes its name or administration in such a way that warrants a new region code.
2. ISO 3166地区代码已被撤销以支持新代码。有时，当一个国家改变其名称或行政管理方式，从而需要一个新的地区代码时，就会发生这种情况。
3. Tags grandfathered from RFC 3066. In many cases, these tags have become obsolete because the values they represent were later encoded by ISO 639.
3. 标签来源于RFC3066。在许多情况下，这些标签已经过时，因为它们所代表的值后来被ISO 639编码。
Records that contain a 'Preferred-Value' field MUST also have a 'Deprecated' field. This field contains a date of deprecation. Thus, a language tag processor can use the registry to construct the valid, non-deprecated set of subtags for a given date. In addition, for any given tag, a processor can construct the set of valid language tags that correspond to that tag for all dates up to the date of the registry. The ability to do these mappings MAY be beneficial to applications that are matching, selecting, for filtering content based on its language tags.
包含“首选值”字段的记录还必须包含“已弃用”字段。此字段包含弃用日期。因此，语言标记处理器可以使用注册表为给定日期构造有效的、未弃用的子标记集。此外，对于任何给定的标记，处理器可以构造一组有效的语言标记，这些标记对应于注册表日期之前的所有日期。执行这些映射的能力可能有助于根据语言标记匹配、选择和过滤内容的应用程序。
Note that 'Preferred-Value' mappings in records of type 'region' sometimes do not represent exactly the same meaning as the original value. There are many reasons for a country code to be changed, and the effect this has on the formation of language tags will depend on the nature of the change in question.
请注意，“区域”类型记录中的“首选值”映射有时表示的含义与原始值不完全相同。更改国家代码有很多原因，而这对语言标记形成的影响将取决于相关更改的性质。
In particular, the 'Preferred-Value' field does not imply retagging content that uses the affected subtag.
特别是，“首选值”字段并不意味着重新标记使用受影响子标签的内容。
The field 'Preferred-Value' MUST NOT be modified once created in the registry. The field MAY be added to records of type "grandfathered" and "region" according to the rules in Section 3.3. Otherwise the field MUST NOT be added to any record already in the registry.
“首选值”字段在注册表中创建后不得修改。根据第3.3节的规则，可将该字段添加到“grandfathered”和“region”类型的记录中。否则，该字段不得添加到注册表中已有的任何记录中。
The 'Preferred-Value' field in records of type "grandfathered" and "redundant" contains whole language tags that are strongly RECOMMENDED for use in place of the record's value. In many cases, the mappings were created by deprecation of the tags during the period before this document was adopted. For example, the tag "no-nyn" was deprecated in favor of the ISO 639-1-defined language code 'nn'.
“grandfathered”和“redundant”类型记录中的“Preferred Value”字段包含全语言标记，强烈建议使用这些标记来代替记录的值。在许多情况下，映射是在采用本文档之前的一段时间内通过弃用标记创建的。例如，标签“no-nyn”被弃用，取而代之的是ISO 639-1定义的语言代码“nn”。
Records of type 'variant' MAY have more than one field of type 'Prefix'. Additional fields of this type MAY be added to a 'variant' record via the registration process.
“variant”类型的记录可能有多个“Prefix”类型的字段。这种类型的其他字段可以通过注册过程添加到“变体”记录中。
Records of type 'extlang' MUST have _exactly_ one 'Prefix' field.
“extlang”类型的记录必须有一个“Prefix”字段。
The field-value of the 'Prefix' field consists of a language tag whose subtags are appropriate to use with this subtag. For example, the variant subtag '1996' has a 'Prefix' field of "de". This means that tags starting with the sequence "de-" are appropriate with this subtag, so "de-Latg-1996" and "de-CH-1996" are both acceptable, while the tag "fr-1996" is an inappropriate choice.
“Prefix”字段的字段值由一个语言标记组成，该标记的子标记适合与该子标记一起使用。例如，变体子标签'1996'有一个'Prefix'字段“de”。这意味着以序列“de-”开头的标签适用于该子标签，因此“de-Latg-1996”和“de-CH-1996”都是可接受的，而标签“fr-1996”是不合适的选择。
The field of type 'Prefix' MUST NOT be removed from any record. The field-value for this type of field MUST NOT be modified.
不能从任何记录中删除“Prefix”类型的字段。不得修改此类型字段的字段值。
The field 'Comments' MAY appear more than once per record. This field MAY be inserted or changed via the registration process and no guarantee of stability is provided. The content of this field is not restricted, except by the need to register the information, the suitability of the request, and by reasonable practical size limitations.
“注释”字段可能会在每条记录中出现多次。该字段可通过注册过程插入或更改，且不保证稳定性。此字段的内容不受限制，但需要注册信息、请求的适用性以及合理的实际大小限制除外。
The field 'Suppress-Script' MUST only appear in records whose 'Type' field-value is 'language'. This field MUST NOT appear more than one time in a record. This field indicates a script used to write the overwhelming majority of documents for the given language and that therefore adds no distinguishing information to a language tag. It helps ensure greater compatibility between the language tags generated according to the rules in this document and language tags and tag processors or consumers based on RFC 3066. For example, virtually all Icelandic documents are written in the Latin script, making the subtag 'Latn' redundant in the tag "is-Latn".
字段“抑制脚本”只能出现在“类型”字段值为“语言”的记录中。此字段在记录中不得出现多次。此字段表示用于为给定语言编写绝大多数文档的脚本，因此不会向语言标记添加区分信息。它有助于确保根据本文档中的规则生成的语言标记与基于RFC 3066的语言标记和标记处理器或使用者之间更大的兼容性。例如，几乎所有冰岛文档都是用拉丁语书写的，这使得标记“is Latn”中的子标记“Latn”是多余的。
The Language Subtag Reviewer is appointed by the IESG for an indefinite term, subject to removal or replacement at the IESG's discretion. The Language Subtag Reviewer moderates the ietf-languages mailing list, responds to requests for registration, and performs the other registry maintenance duties described in Section 3.3. Only the Language Subtag Reviewer is permitted to request IANA to change, update, or add records to the Language Subtag Registry.
语言子标签审查员由IESG无限期任命，IESG可自行决定是否撤换。语言子标签评审员主持ietf语言邮件列表，响应注册请求，并履行第3.3节所述的其他注册维护职责。仅允许语言子标记审阅者请求IANA更改、更新或向语言子标记注册表添加记录。
The performance or decisions of the Language Subtag Reviewer MAY be appealed to the IESG under the same rules as other IETF decisions (see [RFC2026]). The IESG can reverse or overturn the decision of the Language Subtag Reviewer, provide guidance, or take other appropriate actions.
可根据与其他IETF决定相同的规则（见[RFC2026]）向IESG申诉语言子标签评审员的绩效或决定。IESG可以推翻或推翻语言子标签评审员的决定，提供指导，或采取其他适当的行动。
Maintenance of the registry requires that as codes are assigned or withdrawn by ISO 639, ISO 15924, ISO 3166, and UN M.49, the Language Subtag Reviewer MUST evaluate each change, determine whether it conflicts with existing registry entries, and submit the information to IANA for inclusion in the registry. If a change takes place and the Language Subtag Reviewer does not do this in a timely manner, then any interested party MAY use the procedure in Section 3.5 to register the appropriate update.
注册表的维护要求，由于代码由ISO 639、ISO 15924、ISO 3166和UN M.49分配或撤销，语言子标签评审员必须评估每项变更，确定其是否与现有注册表条目冲突，并将信息提交给IANA以纳入注册表。如果发生变更，且语言子标签评审员未及时进行变更，则任何相关方可使用第3.5节中的程序注册适当的更新。
Note: The redundant and grandfathered entries together are the complete list of tags registered under [RFC3066]. The redundant tags are those that can now be formed using the subtags defined in the registry together with the rules of Section 2.2. The grandfathered entries include those that can never be legal under those same provisions.
注：冗余项和冗余项一起是在[RFC3066]下注册的标签的完整列表。冗余标签是现在可以使用注册表中定义的子标签以及第2.2节的规则形成的标签。祖传条目包括那些根据同样的条款永远不可能合法的条目。
The set of redundant and grandfathered tags is permanent and stable: new entries in this section MUST NOT be added and existing entries MUST NOT be removed. Records of type 'grandfathered' MAY have their type converted to 'redundant'; see item 12 in Section 3.6 for more information. The decision-making process about which tags were initially grandfathered and which were made redundant is described in [RFC4645].
这组冗余标记和grandfathered标记是永久和稳定的：不得添加此部分中的新条目，也不得删除现有条目。“grandfathered”类型的记录可能会将其类型转换为“冗余”；详见第3.6节第12项。[RFC4645]中描述了关于哪些标签最初被赋予祖父权，哪些标签被赋予冗余权的决策过程。
RFC 3066 tags that were deprecated prior to the adoption of this document are part of the list of grandfathered tags, and their component subtags were not included as registered variants (although they remain eligible for registration). For example, the tag "art-lojban" was deprecated in favor of the language subtag 'jbo'.
在采用本文件之前被弃用的RFC 3066标签是grandfathered标签列表的一部分，其组件子标签未作为注册变体包括在内（尽管它们仍然有资格注册）。例如，标签“art lojban”被弃用，取而代之的是语言子标签“jbo”。
The Language Subtag Reviewer MUST ensure that new subtags meet the requirements in Section 4.1 or submit an appropriate alternate subtag as described in that section. When either a change or addition to the registry is needed, the Language Subtag Reviewer MUST prepare the complete record, including all fields, and forward it to IANA for insertion into the registry. Each record being modified or inserted MUST be forwarded in a separate message.
语言子标签审查员必须确保新子标签符合第4.1节的要求，或提交该节所述的适当替代子标签。当需要对注册表进行更改或添加时，语言子标签审查员必须准备完整的记录，包括所有字段，并将其转发给IANA以插入注册表。每个被修改或插入的记录必须在单独的消息中转发。
If a record represents a new subtag that does not currently exist in the registry, then the message's subject line MUST include the word "INSERT". If the record represents a change to an existing subtag, then the subject line of the message MUST include the word "MODIFY". The message MUST contain both the record for the subtag being inserted or modified and the new File-Date record. Here is an example of what the body of the message might contain:
如果记录表示注册表中当前不存在的新子标记，则消息的主题行必须包含单词“INSERT”。如果记录表示对现有子标记的更改，则消息的主题行必须包含单词“MODIFY”。消息必须同时包含插入或修改的子标记的记录和新文件日期记录。下面是消息正文可能包含的内容的示例：
LANGUAGE SUBTAG MODIFICATION File-Date: 2005-01-02 %% Type: variant Subtag: nedis Description: Natisone dialect Description: Nadiza dialect Added: 2003-10-09 Prefix: sl Comments: This is a comment shown as an example. %%
语言子标签修改文件日期：2005-01-02%%类型：变体子标签：nedis描述：Natisone方言描述：Nadiza方言添加：2003-10-09前缀：sl注释：这是作为示例显示的注释。%%
Figure 4: Example of a Language Subtag Modification Form
图4：语言子标签修改表单的示例
Whenever an entry is created or modified in the registry, the 'File-Date' record at the start of the registry is updated to reflect the most recent modification date in the [RFC3339] "full-date" format.
每当在注册表中创建或修改条目时，注册表开始处的“文件日期”记录都会更新，以反映[RFC3339]“完整日期”格式的最新修改日期。
Before forwarding a new registration to IANA, the Language Subtag Reviewer MUST ensure that values in the 'Subtag' field match case according to the description in Section 3.1.
在将新注册转发给IANA之前，语言子标签审查员必须确保“子标签”字段中的值符合第3.1节中的描述。
The stability of entries and their meaning in the registry is critical to the long-term stability of language tags. The rules in this section guarantee that a specific language tag's meaning is stable over time and will not change.
注册表中条目及其含义的稳定性对于语言标记的长期稳定性至关重要。本节中的规则保证特定语言标记的含义随着时间的推移是稳定的，不会改变。
These rules specifically deal with how changes to codes (including withdrawal and deprecation of codes) maintained by ISO 639, ISO 15924, ISO 3166, and UN M.49 are reflected in the IANA Language Subtag Registry. Assignments to the IANA Language Subtag Registry MUST follow the following stability rules:
这些规则专门处理ISO 639、ISO 15924、ISO 3166和UN M.49维护的代码更改（包括代码的撤销和弃用）如何反映在IANA语言子标记注册表中。IANA语言子标记注册表的分配必须遵循以下稳定性规则：
1. Values in the fields 'Type', 'Subtag', 'Tag', 'Added', 'Deprecated' and 'Preferred-Value' MUST NOT be changed and are guaranteed to be stable over time.
1. “Type”、“Subtag”、“Tag”、“Added”、“Deprecated”和“Preferred Value”字段中的值不得更改，并保证随着时间的推移保持稳定。
2. Values in the 'Description' field MUST NOT be changed in a way that would invalidate previously-existing tags. They MAY be broadened somewhat in scope, changed to add information, or adapted to the most common modern usage. For example, countries occasionally change their official names; a historical example of this would be "Upper Volta" changing to "Burkina Faso".
2. “Description”字段中的值不得以使以前存在的标记无效的方式进行更改。它们的范围可能会有所扩大，也可能会进行更改以添加信息，或者适应最常见的现代用法。例如，国家偶尔会更改官方名称；历史上的一个例子是“上沃尔特”改为“布基纳法索”。
3. Values in the field 'Prefix' MAY be added to records of type 'variant' via the registration process.
3. “Prefix”字段中的值可以通过注册过程添加到“variant”类型的记录中。
4. Values in the field 'Prefix' MAY be modified, so long as the modifications broaden the set of prefixes. That is, a prefix MAY be replaced by one of its own prefixes. For example, the prefix "en-US" could be replaced by "en", but not by the prefixes "en-Latn", "fr", or "en-US-boont". If one of those prefixes were needed, a new Prefix SHOULD be registered.
4. “前缀”字段中的值可以修改，只要修改扩展了前缀集。也就是说，一个前缀可以被它自己的一个前缀替换。例如，前缀“en US”可以替换为“en”，但不能替换为前缀“en Latn”、“fr”或“en US boont”。如果需要其中一个前缀，则应注册一个新前缀。
5. Values in the field 'Prefix' MUST NOT be removed.
5. “前缀”字段中的值不能删除。
6. The field 'Comments' MAY be added, changed, modified, or removed via the registration process or any of the processes or considerations described in this section.
6. 可通过注册流程或本节所述的任何流程或注意事项添加、更改、修改或删除“注释”字段。
7. The field 'Suppress-Script' MAY be added or removed via the registration process.
7. “抑制脚本”字段可以通过注册过程添加或删除。
8. Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do not conflict with existing subtags of the associated type and whose meaning is not the same as an existing subtag of the same type are entered into the IANA registry as new records.
8. 由ISO 639、ISO 15924和ISO 3166分配的代码与关联类型的现有子标记不冲突，且其含义与相同类型的现有子标记不同，将作为新记录输入IANA注册表。
9. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are withdrawn by their respective maintenance or registration authority remain valid in language tags. A 'Deprecated' field containing the date of withdrawal is added to the record. If a new record of the same type is added that represents a
9. 由ISO 639、ISO 15924或ISO 3166分配的代码（由各自的维护或注册机构撤销）在语言标签中仍然有效。记录中添加了一个包含提取日期的“弃用”字段。如果添加了相同类型的新记录，则表示
replacement value, then a 'Preferred-Value' field MAY also be added. The registration process MAY be used to add comments about the withdrawal of the code by the respective standard.
替换值，然后还可以添加“首选值”字段。注册过程可用于添加关于各标准撤销代码的注释。
Example The region code 'TL' was assigned to the country 'Timor-Leste', replacing the code 'TP' (which was assigned to 'East Timor' when it was under administration by Portugal). The subtag 'TP' remains valid in language tags, but its record contains the a 'Preferred-Value' of 'TL' and its field 'Deprecated' contains the date the new code was assigned ('2004-07-06').
例如，区域代码“TL”分配给国家“东帝汶”，取代了代码“TP”（葡萄牙管理期间分配给“东帝汶”）。子标记“TP”在语言标记中仍然有效，但其记录包含“TL”的a“首选值”，其字段“弃用”包含分配新代码的日期（“2004-07-06”）。
10. Codes assigned by ISO 639, ISO 15924, or ISO 3166 that conflict with existing subtags of the associated type, including subtags that are deprecated, MUST NOT be entered into the registry. The following additional considerations apply to subtag values that are reassigned:
10. 由ISO 639、ISO 15924或ISO 3166分配的与关联类型的现有子标记（包括不推荐使用的子标记）冲突的代码不得输入注册表。以下附加注意事项适用于重新分配的子标记值：
A. For ISO 639 codes, if the newly assigned code's meaning is not represented by a subtag in the IANA registry, the Language Subtag Reviewer, as described in Section 3.5, SHALL prepare a proposal for entering in the IANA registry as soon as practical a registered language subtag as an alternate value for the new code. The form of the registered language subtag will be at the discretion of the Language Subtag Reviewer and MUST conform to other restrictions on language subtags in this document.
A.对于ISO 639代码，如果IANA注册中心中的子标签未表示新分配代码的含义，则第3.5节所述的语言子标签审查员应编制一份提案，以尽快将注册语言子标签作为新代码的替代值输入IANA注册中心。注册语言子标签的格式将由语言子标签审查员自行决定，并且必须符合本文件中对语言子标签的其他限制。
B. For all subtags whose meaning is derived from an external standard (i.e., ISO 639, ISO 15924, ISO 3166, or UN M.49), if a new meaning is assigned to an existing code and the new meaning broadens the meaning of that code, then the meaning for the associated subtag MAY be changed to match. The meaning of a subtag MUST NOT be narrowed, however, as this can result in an unknown proportion of the existing uses of a subtag becoming invalid. Note: ISO 639 maintenance agency/registration authority (MA/RA) has adopted a similar stability policy.
B.对于含义源自外部标准（即ISO 639、ISO 15924、ISO 3166或UN M.49）的所有子标签，如果对现有代码赋予了新含义，且新含义拓宽了该代码的含义，则相关子标签的含义可能会更改为匹配。但是，子标签的含义不能缩小，因为这可能导致子标签现有使用中未知比例的无效。注：ISO 639维护机构/注册机构（MA/RA）采用了类似的稳定性政策。
C. For ISO 15924 codes, if the newly assigned code's meaning is not represented by a subtag in the IANA registry, the Language Subtag Reviewer, as described in Section 3.5, SHALL prepare a proposal for entering in the IANA registry as soon as practical a registered variant subtag as an alternate value for the new code. The form of the registered variant
C.对于ISO 15924代码，如果IANA注册中心中的子标签未表示新分配代码的含义，则语言子标签审查员（如第3.5节所述）应编制一份提案，以尽快将注册的变体子标签作为新代码的替代值输入IANA注册中心。注册变体的形式
subtag will be at the discretion of the Language Subtag Reviewer and MUST conform to other restrictions on variant subtags in this document.
子标签将由语言子标签审查员决定，并且必须符合本文件中关于变体子标签的其他限制。
D. For ISO 3166 codes, if the newly assigned code's meaning is associated with the same UN M.49 code as another 'region' subtag, then the existing region subtag remains as the preferred value for that region and no new entry is created. A comment MAY be added to the existing region subtag indicating the relationship to the new ISO 3166 code.
D.对于ISO 3166代码，如果新分配的代码的含义与另一个“区域”子标记相同的UN M.49代码相关联，则现有区域子标记保留为该区域的首选值，并且不会创建新条目。可在现有区域子标记中添加注释，指示与新ISO 3166代码的关系。
E. For ISO 3166 codes, if the newly assigned code's meaning is associated with a UN M.49 code that is not represented by an existing region subtag, then the Language Subtag Reviewer, as described in Section 3.5, SHALL prepare a proposal for entering the appropriate UN M.49 country code as an entry in the IANA registry.
E.对于ISO 3166代码，如果新分配代码的含义与UN M.49代码相关，而该代码未由现有的区域子标签表示，则语言子标签审查员（如第3.5节所述）应编制一份建议书，将适当的UN M.49国家代码作为条目输入IANA登记册。
F. For ISO 3166 codes, if there is no associated UN numeric code, then the Language Subtag Reviewer SHALL petition the UN to create one. If there is no response from the UN within ninety days of the request being sent, the Language Subtag Reviewer SHALL prepare a proposal for entering in the IANA registry as soon as practical a registered variant subtag as an alternate value for the new code. The form of the registered variant subtag will be at the discretion of the Language Subtag Reviewer and MUST conform to other restrictions on variant subtags in this document. This situation is very unlikely to ever occur.
F.对于ISO 3166代码，如果没有相关的联合国数字代码，则语言子标签评审员应请求联合国创建一个。如果在发送请求后90天内未收到联合国的回复，则语言子标签审查员应编制一份提案，以便尽快将注册的变体子标签作为新代码的替代值输入IANA注册中心。注册变体子标签的格式将由语言子标签审查员决定，并且必须符合本文件中关于变体子标签的其他限制。这种情况不太可能发生。
11. UN M.49 has codes for both countries and areas (such as '276' for Germany) and geographical regions and sub-regions (such as '150' for Europe). UN M.49 country or area codes for which there is no corresponding ISO 3166 code SHOULD NOT be registered, except as a surrogate for an ISO 3166 code that is blocked from registration by an existing subtag. If such a code becomes necessary, then the registration authority for ISO 3166 SHOULD first be petitioned to assign a code to the region. If the petition for a code assignment by ISO 3166 is refused or not acted on in a timely manner, the registration process described in Section 3.5 MAY then be used to register the corresponding UN M.49 code. At the time this document was written, there were only four such codes: 830 (Channel Islands), 831 (Guernsey), 832 (Jersey), and 833 (Isle of Man). This way, UN M.49 codes remain available as the value of last resort in cases where ISO 3166 reassigns a deprecated value in the registry.
11. UN M.49对国家和地区（如德国的“276”）以及地理区域和次区域（如欧洲的“150”）都有代码。UN M.49没有相应ISO 3166代码的国家或地区代码不应注册，除非作为ISO 3166代码的替代物，该代码被现有子标记阻止注册。如果需要此类代码，则应首先请求ISO 3166注册机构为该地区指定代码。如果ISO 3166的代码分配申请被拒绝或未及时采取行动，则可使用第3.5节所述的注册程序注册相应的UN M.49代码。在编写本文件时，只有四个这样的代码：830（海峡群岛）、831（根西岛）、832（泽西岛）和833（马恩岛）。这样，当ISO 3166在注册表中重新分配不推荐的值时，UN M.49代码作为最后手段的值仍然可用。
12. Stability provisions apply to grandfathered tags with this exception: should all of the subtags in a grandfathered tag become valid subtags in the IANA registry, then the field 'Type' in that record is changed from 'grandfathered' to 'redundant'. Note that this will not affect language tags that match the grandfathered tag, since these tags will now match valid generative subtag sequences. For example, if the subtag 'gan' in the language tag "zh-gan" were to be registered as an extended language subtag, then the grandfathered tag "zh-gan" would be deprecated (but existing content or implementations that use "zh-gan" would remain valid).
12. 稳定性规定适用于grandfathered标记，但有以下例外：如果grandfathered标记中的所有子标记在IANA注册表中成为有效子标记，则该记录中的字段“Type”将从“grandfathered”更改为“冗余”。请注意，这不会影响匹配grandfathered标记的语言标记，因为这些标记现在将匹配有效的生成子标记序列。例如，如果要将语言标记“zh-gan”中的子标记“gan”注册为扩展语言子标记，那么将不推荐使用祖父标记“zh-gan”（但使用“zh-gan”的现有内容或实现仍然有效）。
The procedure given here MUST be used by anyone who wants to use a subtag not currently in the IANA Language Subtag Registry.
任何想要使用IANA语言子标记注册表中当前未包含的子标记的人都必须使用此处给出的过程。
Only subtags of type 'language' and 'variant' will be considered for independent registration of new subtags. Handling of subtags needed for stability and subtags necessary to keep the registry synchronized with ISO 639, ISO 15924, ISO 3166, and UN M.49 within the limits defined by this document are described in Section 3.3. Stability provisions are described in Section 3.4.
只有“语言”和“变体”类型的子标签才会考虑独立注册新子标签。第3.3节描述了稳定性所需子标签的处理，以及在本文件规定的范围内保持注册中心与ISO 639、ISO 15924、ISO 3166和UN M.49同步所需的子标签的处理。稳定性规定见第3.4节。
This procedure MAY also be used to register or alter the information for the 'Description', 'Comments', 'Deprecated', or 'Prefix' fields in a subtag's record as described in Section 3.4. Changes to all other fields in the IANA registry are NOT permitted.
本程序也可用于注册或更改第3.4节所述子标签记录中“说明”、“注释”、“弃用”或“前缀”字段的信息。不允许更改IANA注册表中的所有其他字段。
Registering a new subtag or requesting modifications to an existing tag or subtag starts with the requester filling out the registration form reproduced below. Note that each response is not limited in size so that the request can adequately describe the registration. The fields in the "Record Requested" section SHOULD follow the requirements in Section 3.1.
注册新的子标签或请求对现有标签或子标签进行修改，首先由请求者填写下面复制的注册表。请注意，每个响应的大小不受限制，因此请求可以充分描述注册。“要求记录”部分中的字段应符合第3.1节的要求。
LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: 2. E-mail address of requester: 3. Record Requested:
语言分组登记表1。申请人姓名：2。请求者的电子邮件地址：3。要求的记录：
Type: Subtag: Description: Prefix: Preferred-Value: Deprecated: Suppress-Script: Comments:
类型：子标记：说明：前缀：首选值：不推荐：抑制脚本：注释：
4. Intended meaning of the subtag: 5. Reference to published description of the language (book or article): 6. Any other relevant information:
4. 子标签的预期含义：5。参考已出版的语言描述（书或文章）：6。任何其他相关信息：
Figure 5: The Language Subtag Registration Form
图5：语言子标签注册表
The subtag registration form MUST be sent to <ietf-languages@iana.org> for a two-week review period before it can be submitted to IANA. (This is an open list and can be joined by sending a request to <ietf-languages-request@iana.org>.)
子标签登记表必须发送至<ietf-languages@iana.org>在提交给IANA之前，进行为期两周的审查。（这是一个开放列表，可以通过向<ietf语言发送请求来加入-request@iana.org>.)
Variant subtags are usually registered for use with a particular range of language tags. For example, the subtag 'rozaj' is intended for use with language tags that start with the primary language subtag "sl", since Resian is a dialect of Slovenian. Thus, the subtag 'rozaj' would be appropriate in tags such as "sl-Latn-rozaj" or "sl-IT-rozaj". This information is stored in the 'Prefix' field in the registry. Variant registration requests SHOULD include at least one 'Prefix' field in the registration form.
变体子标签通常注册用于特定范围的语言标签。例如，子标记“rozaj”用于以主语言子标记“sl”开头的语言标记，因为Resian是斯洛文尼亚方言。因此，子标签“rozaj”适用于“sl Latn rozaj”或“sl IT rozaj”等标签。此信息存储在注册表的“前缀”字段中。变体注册请求应在注册表格中至少包含一个“前缀”字段。
Extended language subtags are reserved for future standardization. These subtags will be REQUIRED to include exactly one 'Prefix' field once they are allowed for registration.
扩展语言子标签保留用于将来的标准化。一旦允许注册，这些子标签将被要求只包含一个“前缀”字段。
The 'Prefix' field for a given registered subtag exists in the IANA registry as a guide to usage. Additional prefixes MAY be added by filing an additional registration form. In that form, the "Any other relevant information:" field MUST indicate that it is the addition of a prefix.
IANA注册表中存在给定注册子标记的“前缀”字段，作为使用指南。可通过提交额外的登记表来添加额外的前缀。在这种形式下，“任何其他相关信息：”字段必须表明它是前缀的添加。
Requests to add a prefix to a variant subtag that imply a different semantic meaning will probably be rejected. For example, a request to add the prefix "de" to the subtag 'nedis' so that the tag
向变体子标记添加前缀的请求可能会被拒绝，该前缀暗示不同的语义。例如，请求将前缀“de”添加到子标记“nedis”，以便标记
"de-nedis" represented some German dialect would be rejected. The 'nedis' subtag represents a particular Slovenian dialect and the additional registration would change the semantic meaning assigned to the subtag. A separate subtag SHOULD be proposed instead.
代表某种德语方言的“de nedis”将被拒绝。“nedis”子标记代表一种特定的斯洛文尼亚方言，额外的注册将改变分配给子标记的语义。应提出一个单独的子标签。
The 'Description' field MUST contain a description of the tag being registered written or transcribed into the Latin script; it MAY also include a description in a non-Latin script. Non-ASCII characters MUST be escaped using the syntax described in Section 3.1. The 'Description' field is used for identification purposes and doesn't necessarily represent the actual native name of the language or variation or to be in any particular language.
“Description”（描述）字段必须包含正在注册的标签的描述，并将其写入或转录成拉丁文字；它还可以包括非拉丁文字的描述。非ASCII字符必须使用第3.1节中描述的语法进行转义。“描述”字段用于识别目的，不一定代表语言或变体的实际本地名称，也不一定是任何特定语言。
While the 'Description' field itself is not guaranteed to be stable and errata corrections MAY be undertaken from time to time, attempts to provide translations or transcriptions of entries in the registry itself will probably be frowned upon by the community or rejected outright, as changes of this nature have an impact on the provisions in Section 3.4.
虽然“描述”字段本身不保证稳定，并且可能会不时进行勘误更正，但社区可能会反对在注册中心本身提供条目翻译或抄本的尝试，或干脆拒绝，因为这种性质的变更会对第3.4节的规定产生影响。
When the two-week period has passed, the Language Subtag Reviewer either forwards the record to be inserted or modified to iana@iana.org according to the procedure described in Section 3.3, or rejects the request because of significant objections raised on the list or due to problems with constraints in this document (which MUST be explicitly cited). The Language Subtag Reviewer MAY also extend the review period in two-week increments to permit further discussion. The Language Subtag Reviewer MUST indicate on the list whether the registration has been accepted, rejected, or extended following each two-week period.
两周后，语言子标签审阅者将要插入或修改的记录转发给iana@iana.org根据第3.3节所述的程序，或因清单上提出的重大异议或本文件中的约束问题而拒绝请求（必须明确引用）。语言分组审核人还可以延长审核期两周，以允许进一步讨论。语言分组审核人必须在列表上说明是否在每两周后接受、拒绝或延长注册。
Note that the Language Subtag Reviewer MAY raise objections on the list if he or she so desires. The important thing is that the objection MUST be made publicly.
请注意，如果语言子标签评审员愿意，他或她可能会在列表上提出异议。重要的是，反对意见必须公开提出。
The applicant is free to modify a rejected application with additional information and submit it again; this restarts the two-week comment period.
申请人可自由修改被拒绝的申请，并提供额外信息，然后再次提交；这将重新开始为期两周的评论期。
Decisions made by the Language Subtag Reviewer MAY be appealed to the IESG [RFC2028] under the same rules as other IETF decisions [RFC2026].
根据与其他IETF决定[RFC2026]相同的规则，可向IESG[RFC2028]上诉语言分包评审员作出的决定。
All approved registration forms are available online in the directory http://www.iana.org/numbers.html under "languages".
所有经核准的登记表格均可在网上查阅http://www.iana.org/numbers.html 在“语言”下。
Updates or changes to existing records follow the same procedure as new registrations. The Language Subtag Reviewer decides whether there is consensus to update the registration following the two-week review period; normally, objections by the original registrant will carry extra weight in forming such a consensus.
对现有记录的更新或更改遵循与新注册相同的过程。语言分组审核人决定在两周审核期后是否达成更新注册的共识；通常情况下，原始注册人的反对意见将在形成此类共识方面发挥额外的作用。
Registrations are permanent and stable. Once registered, subtags will not be removed from the registry and will remain a valid way in which to specify a specific language or variant.
注册是永久和稳定的。一旦注册，子标记将不会从注册表中删除，并且将仍然是指定特定语言或变体的有效方式。
Note: The purpose of the "Description" in the registration form is to aid people trying to verify whether a language is registered or what language or language variation a particular subtag refers to. In most cases, reference to an authoritative grammar or dictionary of that language will be useful; in cases where no such work exists, other well-known works describing that language or in that language MAY be appropriate. The Language Subtag Reviewer decides what constitutes "good enough" reference material. This requirement is not intended to exclude particular languages or dialects due to the size of the speaker population or lack of a standardized orthography. Minority languages will be considered equally on their own merits.
注：登记表中“说明”的目的是帮助人们核实某一语言是否已登记或某一特定子标签所指的语言或语言变体。在大多数情况下，参考该语言的权威语法或词典是有用的；在不存在此类作品的情况下，描述该语言或该语言的其他知名作品可能是合适的。语言子标签评审员决定“足够好”参考材料的构成。由于说话人的数量或缺乏标准化的正字法，本要求并不排除特定的语言或方言。少数民族语言将根据其本身的优点得到平等考虑。
Possibilities for registration of subtags or information about subtags include:
登记子标签或子标签信息的可能性包括：
o Primary language subtags for languages not listed in ISO 639 that are not variants of any listed or registered language MAY be registered. At the time this document was created, there were no examples of this form of subtag. Before attempting to register a language subtag, there MUST be an attempt to register the language with ISO 639. Subtags MUST NOT be registered for codes that exist in ISO 639-1 or ISO 639-2, that are under consideration by the ISO 639 maintenance or registration authorities, or that have never been attempted for registration with those authorities. If ISO 639 has previously rejected a language for registration, it is reasonable to assume that there must be additional, very compelling evidence of need before it will be registered in the IANA registry (to the extent that it is very unlikely that any subtags will be registered of this type).
o 可以注册ISO 639中未列出的语言的主语言子标签，这些语言不是任何列出或注册语言的变体。在创建此文档时，没有这种形式的子标签的示例。在尝试注册语言子标签之前，必须尝试向ISO 639注册该语言。对于ISO 639-1或ISO 639-2中存在的代码、ISO 639维护或注册机构正在考虑的代码或从未尝试向这些机构注册的代码，不得注册子标签。如果ISO 639之前拒绝了一种语言的注册，那么可以合理地假设，在将其注册到IANA注册中心之前，必须有额外的、非常令人信服的需要证据（在一定程度上，任何子标签都不太可能被注册为这种类型）。
o Dialect or other divisions or variations within a language, its orthography, writing system, regional or historical usage, transliteration or other transformation, or distinguishing variation MAY be registered as variant subtags. An example is the 'rozaj' subtag (the Resian dialect of Slovenian).
o 方言或一种语言中的其他分支或变体、其正字法、书写系统、区域或历史用法、音译或其他转换，或区别变体，可登记为变体子标签。例如，“rozaj”子标签（斯洛文尼亚的Resian方言）。
o The addition or maintenance of fields (generally of an informational nature) in Tag or Subtag records as described in Section 3.1 and subject to the stability provisions in Section 3.4. This includes descriptions, comments, deprecation and preferred values for obsolete or withdrawn codes, or the addition of script or extlang information to primary language subtags.
o 如第3.1节所述，根据第3.4节的稳定性规定，在标签或子标签记录中添加或维护字段（通常为信息性字段）。这包括对过时或已撤销代码的描述、注释、弃用和首选值，或将脚本或extlang信息添加到主语言子标签中。
o The addition of records and related field value changes necessary to reflect assignments made by ISO 639, ISO 15924, ISO 3166, and UN M.49 as described in Section 3.4.
o 如第3.4节所述，添加记录和相关字段值更改以反映ISO 639、ISO 15924、ISO 3166和UN M.49所做的分配。
Subtags proposed for registration that would cause all or part of a grandfathered tag to become redundant but whose meaning conflicts with or alters the meaning of the grandfathered tag MUST be rejected.
建议注册的子标签将导致所有或部分祖父标记变得多余，但其含义与祖父标记的含义冲突或改变祖父标记的含义的子标签必须被拒绝。
This document leaves the decision on what subtags or changes to subtags are appropriate (or not) to the registration process described in Section 3.5.
本文件对第3.5节所述的注册过程中哪些子标签或子标签的更改是合适的（或不合适的）做出了决定。
Note: four-character primary language subtags are reserved to allow for the possibility of alpha4 codes in some future addition to the ISO 639 family of standards.
注：保留了四个字符的主语言子标签，以允许将来在ISO 639标准系列中添加alpha4代码。
ISO 639 defines a maintenance agency for additions to and changes in the list of languages in ISO 639. This agency is:
ISO 639定义了一个维护机构，用于添加和更改ISO 639中的语言列表。该机构是：
International Information Centre for Terminology (Infoterm) Aichholzgasse 6/12, AT-1120 Wien, Austria Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72
国际术语信息中心（Infoterm）Aichholzgasse 6/12，地址：奥地利维恩1120电话：+43 1 26 75 35分机312传真：+43 1 216 32 72
ISO 639-2 defines a maintenance agency for additions to and changes in the list of languages in ISO 639-2. This agency is:
ISO 639-2为ISO 639-2中语言列表的添加和更改定义了维护机构。该机构是：
Library of Congress
Network Development and MARC Standards Office
Washington, D.C. 20540 USA
Phone: +1 202 707 6237 Fax: +1 202 707 0115
URL: http://www.loc.gov/standards/iso639-2
Library of Congress
Network Development and MARC Standards Office
Washington, D.C. 20540 USA
Phone: +1 202 707 6237 Fax: +1 202 707 0115
URL: http://www.loc.gov/standards/iso639-2
The maintenance agency for ISO 3166 (country codes) is:
ISO 3166（国家代码）的维护机构为：
ISO 3166 Maintenance Agency
c/o International Organization for Standardization
Case postale 56
CH-1211 Geneva 20 Switzerland
Phone: +41 22 749 72 33 Fax: +41 22 749 73 49
URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html
ISO 3166 Maintenance Agency
c/o International Organization for Standardization
Case postale 56
CH-1211 Geneva 20 Switzerland
Phone: +41 22 749 72 33 Fax: +41 22 749 73 49
URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html
The registration authority for ISO 15924 (script codes) is:
ISO 15924（脚本代码）的注册机构为：
Unicode Consortium Box 391476
Mountain View, CA 94039-1476, USA
URL: http://www.unicode.org/iso15924
Unicode Consortium Box 391476
Mountain View, CA 94039-1476, USA
URL: http://www.unicode.org/iso15924
The Statistics Division of the United Nations Secretariat maintains the Standard Country or Area Codes for Statistical Use and can be reached at:
联合国秘书处统计司保留用于统计用途的标准国家或地区代码，可通过以下网址联系：
Statistical Services Branch Statistics Division United Nations, Room DC2-1620 New York, NY 10017, USA
统计事务处联合国统计司，美国纽约州纽约市DC2-1620室，邮编：10017
Fax: +1-212-963-0623
E-mail: statistics@un.org
URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm
Fax: +1-212-963-0623
E-mail: statistics@un.org
URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm
Extension subtags are those introduced by single-character subtags ("singletons") other than 'x'. They are reserved for the generation of identifiers that contain a language component and are compatible with applications that understand language tags.
扩展子标签是由除“x”之外的单字符子标签（“单例”）引入的子标签。它们保留用于生成包含语言组件的标识符，并且与理解语言标记的应用程序兼容。
The structure and form of extensions are defined by this document so that implementations can be created that are forward compatible with applications that might be created using singletons in the future. In addition, defining a mechanism for maintaining singletons will lend stability to this document by reducing the likely need for future revisions or updates.
本文档定义了扩展的结构和形式，因此可以创建与将来可能使用单例创建的应用程序前向兼容的实现。此外，定义维护单例的机制将通过减少未来修订或更新的可能需要，使本文档更加稳定。
Single-character subtags are assigned by IANA using the "IETF Consensus" policy defined by [RFC2434]. This policy requires the development of an RFC, which SHALL define the name, purpose, processes, and procedures for maintaining the subtags. The maintaining or registering authority, including name, contact email,
IANA使用[RFC2434]定义的“IETF共识”策略分配单字符子标签。本政策要求制定RFC，RFC应定义维护子标签的名称、目的、流程和程序。维护或注册机构，包括姓名、联系方式、电子邮件、，
discussion list email, and URL location of the registry, MUST be indicated clearly in the RFC. The RFC MUST specify or include each of the following:
必须在RFC中明确指出讨论列表电子邮件和注册中心的URL位置。RFC必须指定或包括以下各项：
o The specification MUST reference the specific version or revision of this document that governs its creation and MUST reference this section of this document.
o 本规范必须参考本文件的特定版本或修订版，该版本或修订版管理本规范的创建，并且必须参考本文件的本节。
o The specification and all subtags defined by the specification MUST follow the ABNF and other rules for the formation of tags and subtags as defined in this document. In particular, it MUST specify that case is not significant and that subtags MUST NOT exceed eight characters in length.
o 规范和规范定义的所有子标签必须遵循ABNF和本文件中定义的标签和子标签形成的其他规则。特别是，它必须指定大小写不重要，子标记的长度不得超过8个字符。
o The specification MUST specify a canonical representation.
o 规范必须指定规范表示。
o The specification of valid subtags MUST be available over the Internet and at no cost.
o 有效子标签的规范必须在互联网上免费提供。
o The specification MUST be in the public domain or available via a royalty-free license acceptable to the IETF and specified in the RFC.
o 该规范必须在公共领域内，或通过IETF可接受且RFC中规定的免版税许可证提供。
o The specification MUST be versioned, and each version of the specification MUST be numbered, dated, and stable.
o 规范必须进行版本控制，规范的每个版本都必须编号、注明日期并保持稳定。
o The specification MUST be stable. That is, extension subtags, once defined by a specification, MUST NOT be retracted or change in meaning in any substantial way.
o 规格必须稳定。也就是说，一旦规范定义了扩展子标签，就不能以任何实质性的方式收回或更改其含义。
o The specification MUST include in a separate section the registration form reproduced in this section (below) to be used in registering the extension upon publication as an RFC.
o 本规范必须在单独一节中包含本节（下文）中复制的登记表，以便在作为RFC发布时用于登记扩展。
o IANA MUST be informed of changes to the contact information and URL for the specification.
o 必须将规范的联系信息和URL的更改通知IANA。
IANA will maintain a registry of allocated single-character (singleton) subtags. This registry MUST use the record-jar format described by the ABNF in Section 3.1. Upon publication of an extension as an RFC, the maintaining authority defined in the RFC MUST forward this registration form to iesg@ietf.org, who MUST forward the request to iana@iana.org. The maintaining authority of the extension MUST maintain the accuracy of the record by sending an updated full copy of the record to iana@iana.org with the subject line "LANGUAGE TAG EXTENSION UPDATE" whenever content changes. Only the 'Comments', 'Contact_Email', 'Mailing_List', and 'URL' fields MAY be modified in these updates.
IANA将维护已分配单字符（单例）子标签的注册表。此注册表必须使用ABNF在第3.1节中描述的记录jar格式。在将扩展发布为RFC后，RFC中定义的维护机构必须将此注册表转发给iesg@ietf.org，必须将请求转发给iana@iana.org. 扩展的维护机构必须通过将更新的完整记录副本发送给iana@iana.org每当内容更改时，使用主题行“语言标记扩展更新”。在这些更新中，只能修改“评论”、“联系电子邮件”、“邮件列表”和“URL”字段。
Failure to maintain this record, maintain the corresponding registry, or meet other conditions imposed by this section of this document MAY be appealed to the IESG [RFC2028] under the same rules as other IETF decisions (see [RFC2026]) and MAY result in the authority to maintain the extension being withdrawn or reassigned by the IESG.
如果未能保存该记录、保存相应的登记册或满足本文件本节规定的其他条件，可根据与其他IETF决定相同的规则（见[RFC2026]）向IESG[RFC2028]提出上诉，并可能导致IESG撤销或重新分配维持延期的权限。
%% Identifier: Description: Comments: Added: RFC: Authority: Contact_Email: Mailing_List: URL: %%
%%标识符：描述：注释：添加：RFC:权限：联系人\u电子邮件：邮件\u列表：URL:%%
Figure 6: Format of Records in the Language Tag Extensions Registry
图6:Language Tag Extensions注册表中记录的格式
'Identifier' contains the single-character subtag (singleton) assigned to the extension. The Internet-Draft submitted to define the extension SHOULD specify which letter or digit to use, although the IESG MAY change the assignment when approving the RFC.
“标识符”包含分配给扩展名的单字符子标记（单例）。为定义扩展而提交的互联网草案应指定使用哪个字母或数字，尽管IESG在批准RFC时可能会更改分配。
'Description' contains the name and description of the extension.
“Description”包含扩展名的名称和说明。
'Comments' is an OPTIONAL field and MAY contain a broader description of the extension.
“注释”是可选字段，可能包含扩展的更广泛描述。
'Added' contains the date the RFC was published in the "full-date" format specified in [RFC3339]. For example: 2004-06-28 represents June 28, 2004, in the Gregorian calendar.
“已添加”包含以[RFC3339]中指定的“完整日期”格式发布RFC的日期。例如：2004-06-28代表公历中的2004年6月28日。
'RFC' contains the RFC number assigned to the extension.
“RFC”包含分配给分机的RFC编号。
'Authority' contains the name of the maintaining authority for the extension.
“权限”包含扩展的维护权限的名称。
'Contact_Email' contains the email address used to contact the maintaining authority.
“联系人电子邮件”包含用于联系维护机构的电子邮件地址。
'Mailing_List' contains the URL or subscription email address of the mailing list used by the maintaining authority.
“邮件列表”包含维护机构使用的邮件列表的URL或订阅电子邮件地址。
'URL' contains the URL of the registry for this extension.
“URL”包含此扩展的注册表URL。
The determination of whether an Internet-Draft meets the above conditions and the decision to grant or withhold such authority rests solely with the IESG and is subject to the normal review and appeals process associated with the RFC process.
互联网草案是否符合上述条件以及授予或拒绝此类授权的决定完全由IESG决定，并受与RFC程序相关的正常审查和上诉程序的制约。
Extension authors are strongly cautioned that many (including most well-formed) processors will be unaware of any special relationships or meaning inherent in the order of extension subtags. Extension authors SHOULD avoid subtag relationships or canonicalization mechanisms that interfere with matching or with length restrictions that sometimes exist in common protocols where the extension is used. In particular, applications MAY truncate the subtags in doing matching or in fitting into limited lengths, so it is RECOMMENDED that the most significant information be in the most significant (left-most) subtags and that the specification gracefully handle truncated subtags.
扩展作者被强烈警告，许多（包括大多数格式良好的）处理者将不知道扩展子标签顺序中固有的任何特殊关系或含义。扩展作者应该避免子标记关系或规范化机制，这些关系或规范化机制会干扰匹配或长度限制，这些限制有时存在于使用扩展的公共协议中。特别是，应用程序在进行匹配或拟合到有限长度时可能会截断子标记，因此建议最重要的信息位于最重要（最左边）的子标记中，并且规范会优雅地处理截断的子标记。
When a language tag is to be used in a specific, known, protocol, it is RECOMMENDED that the language tag not contain extensions not supported by that protocol. In addition, note that some protocols MAY impose upper limits on the length of the strings used to store or transport the language tag.
在特定的已知协议中使用语言标记时，建议该语言标记不包含该协议不支持的扩展。此外，请注意，某些协议可能会对用于存储或传输语言标记的字符串长度施加上限。
Upon adoption of this document, an initial version of the Language Subtag Registry containing the various subtags initially valid in a language tag is necessary. This collection of subtags, along with a description of the process used to create it, is described by [RFC4645]. IANA SHALL publish the initial version of the registry described by this document from the content of [RFC4645]. Once published by IANA, the maintenance procedures, rules, and registration processes described in this document will be available for new registrations or updates.
采用本文档后，需要初始版本的Language Subtag Registry，其中包含最初在语言标记中有效的各种子标记。[RFC4645]描述了此子标签集合以及用于创建它的过程的描述。IANA应根据[RFC4645]的内容发布本文件所述登记册的初始版本。一旦IANA发布，本文件中描述的维护程序、规则和注册流程将可用于新的注册或更新。
Registrations that are in process under the rules defined in [RFC3066] when this document is adopted MAY be completed under the former rules, at the discretion of the Language Tag Reviewer (as described in [RFC3066]). Until the IESG officially appoints a Language Subtag Reviewer, the existing Language Tag Reviewer SHALL serve as the Language Subtag Reviewer.
采用本文件时，根据[RFC3066]中定义的规则正在进行的注册可根据之前的规则完成，由语言标签审查员自行决定（如[RFC3066]中所述）。在IESG正式任命语言子标签审查员之前，现有语言标签审查员应担任语言子标签审查员。
Any new registrations submitted using the RFC 3066 forms or format after the adoption of this document and publication of the registry by IANA MUST be rejected.
采用本文件并由IANA发布注册后，使用RFC 3066表格或格式提交的任何新注册必须被拒绝。
An initial version of the Language Tag Extensions Registry described in Section 3.7 is also needed. The Language Tag Extensions Registry SHALL be initialized with a single record containing a single field of type "File-Date" as a placeholder for future assignments.
还需要第3.7节中描述的语言标记扩展注册表的初始版本。语言标记扩展注册表应使用一条记录进行初始化，该记录包含一个“文件日期”类型的字段，作为将来分配的占位符。
This section addresses how to use the information in the registry with the tag syntax to choose, form, and process language tags.
本节介绍如何使用注册表中的信息和标记语法来选择、形成和处理语言标记。
One is sometimes faced with the choice between several possible tags for the same body of text.
对于同一文本体，有时需要在几个可能的标记之间进行选择。
Interoperability is best served when all users use the same language tag in order to represent the same language. If an application has requirements that make the rules here inapplicable, then that application risks damaging interoperability. It is strongly RECOMMENDED that users not define their own rules for language tag choice.
当所有用户使用相同的语言标记来表示相同的语言时，互操作性得到了最好的服务。如果应用程序的需求使得此处的规则不适用，那么该应用程序就有可能破坏互操作性。强烈建议用户不要定义自己的语言标记选择规则。
Subtags SHOULD only be used where they add useful distinguishing information; extraneous subtags interfere with the meaning, understanding, and processing of language tags. In particular, users and implementations SHOULD follow the 'Prefix' and 'Suppress-Script' fields in the registry (defined in Section 3.1): these fields provide guidance on when specific additional subtags SHOULD (and SHOULD NOT) be used in a language tag.
子标签只能用于添加有用的区分信息的地方；外来子标签干扰语言标签的含义、理解和处理。特别是，用户和实现应遵循注册表中的“前缀”和“抑制脚本”字段（在第3.1节中定义）：这些字段提供关于何时应（不应）在语言标记中使用特定附加子标记的指导。
Of particular note, many applications can benefit from the use of script subtags in language tags, as long as the use is consistent for a given context. Script subtags were not formally defined in RFC 3066 and their use can affect matching and subtag identification by implementations of RFC 3066, as these subtags appear between the primary language and region subtags. For example, if a user requests content in an implementation of Section 2.5 of [RFC3066] using the language range "en-US", content labeled "en-Latn-US" will not match the request. Therefore, it is important to know when script subtags will customarily be used and when they ought not be used. In the registry, the Suppress-Script field helps ensure greater compatibility between the language tags generated according to the rules in this document and language tags and tag processors or consumers based on RFC 3066 by defining when users SHOULD NOT include a script subtag with a particular primary language subtag.
特别值得注意的是，许多应用程序可以从语言标记中使用脚本子标记中获益，只要在给定的上下文中使用是一致的。RFC 3066中未正式定义脚本子标记，它们的使用可能会影响RFC 3066实现的匹配和子标记识别，因为这些子标记出现在主语言和区域子标记之间。例如，如果用户在[RFC3066]第2.5节的实现中使用“en-US”语言范围请求内容，则标记为“en-Latn-US”的内容将与请求不匹配。因此，了解脚本子标记通常何时使用以及何时不应使用是很重要的。在注册表中，“抑制脚本”字段通过定义用户何时不应将脚本子标记包含在特定的主语言子标记中，有助于确保根据本文档中的规则生成的语言标记与基于RFC 3066的语言标记、标记处理者或消费者之间更大的兼容性。
Extended language subtags (type 'extlang' in the registry; see Section 3.1) also appear between the primary language and region subtags and are reserved for future standardization. Applications might benefit from their judicious use in forming language tags in the future. Similar recommendations are expected to apply to their use as apply to script subtags.
扩展语言子标签（在注册表中键入“extlang”；参见第3.1节）也出现在主语言子标签和区域子标签之间，并保留用于将来的标准化。应用程序将来可能会受益于它们在形成语言标记时的明智使用。类似的建议预计将适用于它们的使用，就像适用于脚本子标签一样。
Standards, protocols, and applications that reference this document normatively but apply different rules to the ones given in this section MUST specify how the procedure varies from the one given here.
规范性引用本文件但对本节给出的标准、协议和应用程序应用不同规则的标准、协议和应用程序必须说明程序与此处给出的程序之间的差异。
The choice of subtags used to form a language tag SHOULD be guided by the following rules:
用于形成语言标记的子标记的选择应遵循以下规则：
1. Use as precise a tag as possible, but no more specific than is justified. Avoid using subtags that are not important for distinguishing content in an application.
1. 使用尽可能精确的标记，但不要超出合理的范围。避免使用对区分应用程序中的内容不重要的子标签。
* For example, 'de' might suffice for tagging an email written in German, while "de-CH-1996" is probably unnecessarily precise for such a task.
* 例如，“de”可能足以标记用德语编写的电子邮件，而“de-CH-1996”对于此类任务可能不必要地精确。
2. The script subtag SHOULD NOT be used to form language tags unless the script adds some distinguishing information to the tag. The field 'Suppress-Script' in the primary language record in the registry indicates which script subtags do not add distinguishing information for most applications.
2. 脚本子标记不应用于形成语言标记，除非脚本向标记添加了一些区别信息。注册表中主语言记录中的字段“抑制脚本”指示哪些脚本子标记不为大多数应用程序添加区分信息。
* For example, the subtag 'Latn' should not be used with the primary language 'en' because nearly all English documents are written in the Latin script and it adds no distinguishing information. However, if a document were written in English mixing Latin script with another script such as Braille ('Brai'), then it might be appropriate to choose to indicate both scripts to aid in content selection, such as the application of a style sheet.
* 例如，子标签“Latn”不应与主要语言“en”一起使用，因为几乎所有英语文档都是用拉丁语编写的，并且没有添加任何区别信息。但是，如果一个文档是用英语编写的，将拉丁语脚本与另一个脚本（如盲文（“Brai”）混合在一起，则可以选择指示这两个脚本以帮助内容选择，例如应用样式表。
3. If a tag or subtag has a 'Preferred-Value' field in its registry entry, then the value of that field SHOULD be used to form the language tag in preference to the tag or subtag in which the preferred value appears.
3. 如果标记或子标记在其注册表项中有“首选值”字段，则该字段的值应用于形成语言标记，优先于首选值出现的标记或子标记。
* For example, use 'he' for Hebrew in preference to 'iw'.
* 例如，在希伯来语中使用“he”而不是“iw”。
4. The 'und' (Undetermined) primary language subtag SHOULD NOT be used to label content, even if the language is unknown. Omitting the language tag altogether is preferred to using a tag with a primary language subtag of 'und'. The 'und' subtag MAY be useful for protocols that require a language tag to be provided. The 'und' subtag MAY also be useful when matching language tags in certain situations.
4. “und”（待定）主语言子标签不应用于标记内容，即使语言未知。与使用主语言子标记为“und”的标记相比，最好完全省略语言标记。“und”子标记对于需要提供语言标记的协议可能很有用。在某些情况下，当匹配语言标记时，“und”子标记可能也很有用。
5. The 'mul' (Multiple) primary language subtag SHOULD NOT be used whenever the protocol allows the separate tags for multiple languages, as is the case for the Content-Language header in HTTP. The 'mul' subtag conveys little useful information: content in multiple languages SHOULD individually tag the languages where they appear or otherwise indicate the actual language in preference to the 'mul' subtag.
5. 当协议允许对多种语言使用单独的标记时，不应使用“mul”（多）主语言子标记，HTTP中的内容语言头就是这样。“mul”子标签传递的有用信息很少：多种语言的内容应该单独标记它们出现的语言，或者以其他方式指示实际语言，而不是“mul”子标签。
6. The same variant subtag SHOULD NOT be used more than once within a language tag.
6. 同一变体子标记在语言标记中不应使用多次。
* For example, do not use "de-DE-1901-1901".
* 例如，不要使用“de-de-1901-1901”。
To ensure consistent backward compatibility, this document contains several provisions to account for potential instability in the standards used to define the subtags that make up language tags. These provisions mean that no language tag created under the rules in this document will become obsolete.
为了确保一致的向后兼容性，本文档包含了一些条款，以解释用于定义构成语言标记的子标记的标准中可能存在的不稳定性。这些规定意味着根据本文件中的规则创建的任何语言标签都不会过时。
The relationship between the tag and the information it relates to is defined by the context in which the tag appears. Accordingly, this section gives only possible examples of its usage.
标记与其相关信息之间的关系由标记出现的上下文定义。因此，本节仅给出其用法的可能示例。
o For a single information object, the associated language tags might be interpreted as the set of languages that is necessary for a complete comprehension of the complete object. Example: Plain text documents.
o 对于单个信息对象，关联的语言标记可能被解释为完整理解完整对象所必需的一组语言。示例：纯文本文档。
o For an aggregation of information objects, the associated language tags could be taken as the set of languages used inside components of that aggregation. Examples: Document stores and libraries.
o 对于信息对象的聚合，关联的语言标记可以作为该聚合组件内部使用的语言集。示例：文档存储和库。
o For information objects whose purpose is to provide alternatives, the associated language tags could be regarded as a hint that the content is provided in several languages and that one has to inspect each of the alternatives in order to find its language or languages. In this case, the presence of multiple tags might not mean that one needs to be multi-lingual to get complete
o 对于其目的是提供备选方案的信息对象，相关的语言标记可以被视为一种提示，表明内容是以几种语言提供的，并且必须检查每种备选方案才能找到其语言。在这种情况下，多个标记的存在可能并不意味着需要多语言才能完成
understanding of the document. Example: MIME multipart/ alternative.
对文件的理解。示例：MIME多部分/alternative。
o In markup languages, such as HTML and XML, language information can be added to each part of the document identified by the markup structure (including the whole document itself). For example, one could write <span lang="fr">C'est la vie.</span> inside a Norwegian document; the Norwegian-speaking user could then access a French-Norwegian dictionary to find out what the marked section meant. If the user were listening to that document through a speech synthesis interface, this formation could be used to signal the synthesizer to appropriately apply French text-to-speech pronunciation rules to that span of text, instead of applying the inappropriate Norwegian rules.
o 在HTML和XML等标记语言中，可以将语言信息添加到由标记结构标识的文档的每个部分（包括整个文档本身）。例如，一个人可以在挪威文档中写下“生活就是这样”；说挪威语的用户可以访问法语-挪威语词典，以了解标记部分的含义。如果用户正在通过语音合成界面收听该文档，则可以使用该格式向合成器发出信号，以将法语文本到语音发音规则适当应用于该文本范围，而不是应用不适当的挪威规则。
Language tags are related when they contain a similar sequence of subtags. For example, if a language tag B contains language tag A as a prefix, then B is typically "narrower" or "more specific" than A. Thus, "zh-Hant-TW" is more specific than "zh-Hant".
当语言标记包含相似的子标记序列时，它们是相关的。例如，如果语言标记B包含语言标记a作为前缀，则B通常比a“更窄”或“更具体”。因此，“zh Hant TW”比“zh Hant”更具体。
This relationship is not guaranteed in all cases: specifically, languages that begin with the same sequence of subtags are NOT guaranteed to be mutually intelligible, although they might be. For example, the tag "az" shares a prefix with both "az-Latn" (Azerbaijani written using the Latin script) and "az-Cyrl" (Azerbaijani written using the Cyrillic script). A person fluent in one script might not be able to read the other, even though the text might be identical. Content tagged as "az" most probably is written in just one script and thus might not be intelligible to a reader familiar with the other script.
并非所有情况下都能保证这种关系：特别是，以相同子标签序列开头的语言不能保证相互理解，尽管它们可能相互理解。例如，标记“az”与“az-Latn”（使用拉丁语书写的阿塞拜疆语）和“az-Cyrl”（使用西里尔语书写的阿塞拜疆语）共享前缀。精通一种脚本的人可能无法阅读另一种脚本，即使文本可能完全相同。标记为“az”的内容很可能仅用一个脚本编写，因此熟悉另一个脚本的读者可能无法理解。
[RFC3066] did not provide an upper limit on the size of language tags. While RFC 3066 did define the semantics of particular subtags in such a way that most language tags consisted of language and region subtags with a combined total length of up to six characters, larger registered tags were not only possible but were actually registered.
[RFC3066]未提供语言标记大小的上限。虽然RFC 3066确实定义了特定子标签的语义，大多数语言标签由语言和区域子标签组成，组合总长度高达六个字符，但更大的注册标签不仅可能，而且实际上已经注册。
Neither the language tag syntax nor other requirements in this document impose a fixed upper limit on the number of subtags in a language tag (and thus an upper bound on the size of a tag). The language tag syntax suggests that, depending on the specific language, more subtags (and thus a longer tag) are sometimes necessary to completely identify the language for certain applications; thus, it is possible to envision long or complex subtag sequences.
本文档中的语言标记语法和其他要求都没有对语言标记中的子标记数量施加固定的上限（从而对标记的大小施加上限）。语言标记语法表明，根据特定的语言，有时需要更多的子标记（因此标记更长）来完全识别特定应用程序的语言；因此，可以设想长或复杂的子标签序列。
Some applications and protocols are forced to allocate fixed buffer sizes or otherwise limit the length of a language tag. A conformant implementation or specification MAY refuse to support the storage of language tags that exceed a specified length. Any such limitation SHOULD be clearly documented, and such documentation SHOULD include what happens to longer tags (for example, whether an error value is generated or the language tag is truncated). A protocol that allows tags to be truncated at an arbitrary limit, without giving any indication of what that limit is, has the potential for causing harm by changing the meaning of tags in substantial ways.
一些应用程序和协议被迫分配固定的缓冲区大小或以其他方式限制语言标记的长度。一致性实现或规范可能拒绝支持存储超过指定长度的语言标记。任何此类限制都应该清楚地记录下来，并且此类记录应该包括较长标记的情况（例如，是否生成错误值或语言标记是否被截断）。协议允许在任意限制下截断标签，而不给出该限制的任何指示，通过实质性地改变标签的含义，有可能造成损害。
In practice, most language tags do not require more than a few subtags and will not approach reasonably sized buffer limitations; see Section 4.1.
在实践中，大多数语言标签不需要超过几个子标签，也不会接近合理大小的缓冲区限制；见第4.1节。
Some specifications or protocols have limits on tag length but do not have a fixed length limitation. For example, [RFC2231] has no explicit length limitation: the length available for the language tag is constrained by the length of other header components (such as the charset's name) coupled with the 76-character limit in [RFC2047]. Thus, the "limit" might be 50 or more characters, but it could potentially be quite small.
一些规范或协议对标记长度有限制，但没有固定的长度限制。例如，[RFC2231]没有明确的长度限制：语言标记的可用长度受其他头组件（例如字符集的名称）的长度以及[RFC2047]中76个字符的限制的约束。因此，“限制”可能是50个或更多字符，但可能非常小。
The considerations for assigning a buffer limit are:
分配缓冲区限制的注意事项包括：
Implementations SHOULD NOT truncate language tags unless the meaning of the tag is purposefully being changed, or unless the tag does not fit into a limited buffer size specified by a protocol for storage or transmission.
实现不应该截断语言标记，除非有目的地更改标记的含义，或者除非标记不适合存储或传输协议指定的有限缓冲区大小。
Implementations SHOULD warn the user when a tag is truncated since truncation changes the semantic meaning of the tag.
当标记被截断时，实现应该向用户发出警告，因为截断会更改标记的语义。
Implementations of protocols or specifications that are space constrained but do not have a fixed limit SHOULD use the longest possible tag in preference to truncation.
空间受限但没有固定限制的协议或规范的实现应该使用尽可能长的标记，而不是截断。
Protocols or specifications that specify limited buffer sizes for language tags MUST allow for language tags of up to 33 characters.
为语言标记指定有限缓冲区大小的协议或规范必须允许最多33个字符的语言标记。
Protocols or specifications that specify limited buffer sizes for language tags SHOULD allow for language tags of at least 42 characters.
为语言标记指定有限缓冲区大小的协议或规范应允许至少42个字符的语言标记。
The following illustration shows how the 42-character recommendation was derived. The combination of language and extended language subtags was chosen for future compatibility. At up to 15 characters, this combination is longer than the longest possible primary language subtag (8 characters):
下图显示了42个字符的建议是如何导出的。为了将来的兼容性，选择了语言和扩展语言子标签的组合。最多15个字符，此组合比可能最长的主语言子标记（8个字符）长：
language = 3 (ISO 639-2; ISO 639-1 requires 2)
extlang1 = 4 (each subsequent subtag includes '-')
extlang2 = 4 (unlikely: needs prefix="language-extlang1")
extlang3 = 4 (extremely unlikely)
script = 5 (if not suppressed: see Section 4.1)
region = 4 (UN M.49; ISO 3166 requires 3)
variant1 = 9 (MUST have language as a prefix)
variant2 = 9 (MUST have language-variant1 as a prefix)
language = 3 (ISO 639-2; ISO 639-1 requires 2)
extlang1 = 4 (each subsequent subtag includes '-')
extlang2 = 4 (unlikely: needs prefix="language-extlang1")
extlang3 = 4 (extremely unlikely)
script = 5 (if not suppressed: see Section 4.1)
region = 4 (UN M.49; ISO 3166 requires 3)
variant1 = 9 (MUST have language as a prefix)
variant2 = 9 (MUST have language-variant1 as a prefix)
total = 42 characters
total = 42 characters
Figure 7: Derivation of the Limit on Tag Length
图7：标签长度限制的推导
Truncation of a language tag alters the meaning of the tag, and thus SHOULD be avoided. However, truncation of language tags is sometimes necessary due to limited buffer sizes. Such truncation MUST NOT permit a subtag to be chopped off in the middle or the formation of invalid tags (for example, one ending with the "-" character).
语言标记的截断会改变标记的含义，因此应该避免。但是，由于缓冲区大小有限，有时需要截断语言标记。这样的截断不能允许子标记在中间被截断或无效标签的形成（例如，一个结束与“--”字符）。
This means that applications or protocols that truncate tags MUST do so by progressively removing subtags along with their preceding "-" from the right side of the language tag until the tag is short enough for the given buffer. If the resulting tag ends with a single-character subtag, that subtag and its preceding "-" MUST also be removed. For example:
这意味着截断标记的应用程序或协议必须通过从语言标记的右侧逐渐删除子标记及其前面的“-”，直到标记对于给定的缓冲区足够短为止。如果生成的标记以单个字符子标记结尾，则该子标记及其前面的“-”也必须删除。例如：
Tag to truncate: zh-Latn-CN-variant1-a-extend1-x-wadegile-private1 1. zh-Latn-CN-variant1-a-extend1-x-wadegile 2. zh-Latn-CN-variant1-a-extend1 3. zh-Latn-CN-variant1 4. zh-Latn-CN 5. zh-Latn 6. zh
要截断的标记：zh-Latn-CN-variant1-a-extend1-x-wadegile-private1。zh-Latn-CN-variant1-a-extend1-x-wadegile 2。zh-Latn-CN-variant1-a-EXTEND13。zh-Latn-CN-variant1 4。zh Latn CN 5。zh Latn 6。zh
Figure 8: Example of Tag Truncation
图8：标记截断的示例
Since a particular language tag is sometimes used by many processes, language tags SHOULD always be created or generated in a canonical form.
由于特定的语言标记有时被许多进程使用，因此语言标记应该始终以规范的形式创建或生成。
A language tag is in canonical form when:
在以下情况下，语言标记为规范形式：
1. The tag is well-formed according the rules in Section 2.1 and Section 2.2.
1. 根据第2.1节和第2.2节中的规则，标签的形状良好。
2. Subtags of type 'Region' that have a Preferred-Value mapping in the IANA registry (see Section 3.1) SHOULD be replaced with their mapped value. Note: In rare cases, the mapped value will also have a Preferred-Value.
2. IANA注册表中具有首选值映射的“Region”类型子标记（见第3.1节）应替换为其映射值。注意：在极少数情况下，映射值也将具有首选值。
3. Redundant or grandfathered tags that have a Preferred-Value mapping in the IANA registry (see Section 3.1) MUST be replaced with their mapped value. These items either are deprecated mappings created before the adoption of this document (such as the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh") or are the result of later registrations or additions to this document (for example, "zh-guoyu" might be mapped to a language-extlang combination such as "zh-cmn" by some future update of this document).
3. 必须将IANA注册表中具有首选值映射（见第3.1节）的冗余或祖父标记替换为其映射值。这些项目要么是在采用本文档之前创建的不推荐的映射（如“no-nyn”到“nn”或“i-klingon”到“tlh”的映射），要么是后来注册或添加到本文档的结果（例如，“zh-guoyu”可能映射到诸如“zh-cmn”之类的语言extlang组合通过本文件的某些未来更新）。
4. Other subtags that have a Preferred-Value mapping in the IANA registry (see Section 3.1) MUST be replaced with their mapped value. These items consist entirely of clerical corrections to ISO 639-1 in which the deprecated subtags have been maintained for compatibility purposes.
4. IANA注册表中具有首选值映射的其他子标签（见第3.1节）必须替换为其映射值。这些项目完全由ISO 639-1的文书更正组成，其中出于兼容性目的保留了不推荐使用的子标签。
5. If more than one extension subtag sequence exists, the extension sequences are ordered into case-insensitive ASCII order by singleton subtag.
5. 如果存在多个扩展子标记序列，则扩展序列将按单例子标记按不区分大小写的ASCII顺序排序。
Example: The language tag "en-A-aaa-B-ccc-bbb-x-xyz" is in canonical form, while "en-B-ccc-bbb-A-aaa-X-xyz" is well-formed but not in canonical form.
示例：语言标记“en-A-aaa-B-ccc-bbb-x-xyz”是标准格式，而“en-B-ccc-bbb-A-aaa-x-xyz”格式良好，但不是标准格式。
Example: The language tag "en-BU" (English as used in Burma) is not canonical because the 'BU' subtag has a canonical mapping to 'MM' (Myanmar), although the tag "en-BU" maintains its validity.
示例：语言标记“en-BU”（缅甸使用的英语）不规范，因为“BU”子标记具有到“MM”（缅甸）的规范映射，尽管标记“en-BU”保持其有效性。
Canonicalization of language tags does not imply anything about the use of upper or lowercase letters when processing or comparing subtags (and as described in Section 2.1). All comparisons MUST be performed in a case-insensitive manner.
语言标记的规范化并不意味着在处理或比较子标记时使用大写或小写字母（如第2.1节所述）。所有比较必须以不区分大小写的方式进行。
When performing canonicalization of language tags, processors MAY regularize the case of the subtags (that is, this process is OPTIONAL), following the case used in the registry. Note that this corresponds to the following casing rules: uppercase all non-initial two-letter subtags; titlecase all non-initial four-letter subtags; lowercase everything else.
在执行语言标记的规范化时，处理器可以按照注册表中使用的大小写规范化子标记的大小写（即，此过程是可选的）。请注意，这对应于以下大小写规则：大写所有非首字母的两个字母子标签；titlecase所有非首字母四个字母的子标签；其他的都小写。
Note: Case folding of ASCII letters in certain locales, unless carefully handled, sometimes produces non-ASCII character values. The Unicode Character Database file "SpecialCasing.txt" defines the specific cases that are known to cause problems with this. In particular, the letter 'i' (U+0069) in Turkish and Azerbaijani is uppercased to U+0130 (LATIN CAPITAL LETTER I WITH DOT ABOVE). Implementers SHOULD specify a locale-neutral casing operation to ensure that case folding of subtags does not produce this value, which is illegal in language tags. For example, if one were to uppercase the region subtag 'in' using Turkish locale rules, the sequence U+0130 U+004E would result instead of the expected 'IN'.
注意：某些地区的ASCII字母的大小写折叠，除非小心处理，有时会产生非ASCII字符值。Unicode字符数据库文件“SpecialCasing.txt”定义了已知会导致此问题的特定情况。特别是，土耳其语和阿塞拜疆语中的字母“i”（U+0069）大写为U+0130（拉丁文大写字母i，上面带点）。实现者应该指定与语言环境无关的大小写操作，以确保子标记的大小写折叠不会产生此值，这在语言标记中是非法的。例如，如果使用土耳其语言环境规则将区域子标记“in”大写，则结果将是序列U+0130 U+004E，而不是预期的“in”。
Note: if the field 'Deprecated' appears in a registry record without an accompanying 'Preferred-Value' field, then that tag or subtag is deprecated without a replacement. Validating processors SHOULD NOT generate tags that include these values, although the values are canonical when they appear in a language tag.
注意：如果字段“已弃用”出现在注册表记录中，但没有附带“首选值”字段，则该标记或子标记将弃用而不替换。验证处理器不应生成包含这些值的标记，尽管这些值出现在语言标记中时是规范的。
An extension MUST define any relationships that exist between the various subtags in the extension and thus MAY define an alternate canonicalization scheme for the extension's subtags. Extensions MAY define how the order of the extension's subtags are interpreted. For example, an extension could define that its subtags are in canonical order when the subtags are placed into ASCII order: that is, "en-a-aaa-bbb-ccc" instead of "en-a-ccc-bbb-aaa". Another extension might define that the order of the subtags influences their semantic meaning (so that "en-b-ccc-bbb-aaa" has a different value from "en-b-aaa-bbb-ccc"). However, extension specifications SHOULD be designed so that they are tolerant of the typical processes described in Section 3.7.
扩展必须定义扩展中各个子标记之间存在的任何关系，因此可以为扩展的子标记定义备用规范化方案。扩展可以定义如何解释扩展子标记的顺序。例如，一个扩展可以定义当子标签被放置到ASCII顺序时，它的子标签是规范顺序的：即“en-a-aaa-bbb-ccc”而不是“en-a-ccc-bbb-aaa”。另一个扩展可能定义子标签的顺序影响其语义（因此“en-b-ccc-bbb-aaa”的值与“en-b-aaa-bbb-ccc”的值不同）。然而，扩展规范的设计应使其能够容忍第3.7节中描述的典型过程。
Private use subtags, like all other subtags, MUST conform to the format and content constraints in the ABNF. Private use subtags have no meaning outside the private agreement between the parties that intend to use or exchange language tags that employ them. The same subtags MAY be used with a different meaning under a separate private agreement. They SHOULD NOT be used where alternatives exist and SHOULD NOT be used in content or protocols intended for general use.
与所有其他子标签一样，专用子标签必须符合ABNF中的格式和内容约束。私用子标签在打算使用或交换使用它们的语言标签的各方之间的私用协议之外没有任何意义。在单独的私人协议下，相同的子标签可能具有不同的含义。不应在存在替代品的情况下使用，也不应在用于一般用途的内容或协议中使用。
Private use subtags are simply useless for information exchange without prior arrangement. The value and semantic meaning of private use tags and of the subtags used within such a language tag are not defined by this document.
未经事先安排，私用子标签对于信息交换毫无用处。本文档未定义私用标记和此类语言标记中使用的子标记的值和语义。
Subtags defined in the IANA registry as having a specific private use meaning convey more information that a purely private use tag prefixed by the singleton subtag 'x'. For applications, this additional information MAY be useful.
IANA注册表中定义的具有特定专用含义的子标记传递的信息比以单例子标记“x”为前缀的纯专用标记更多。对于应用程序，此附加信息可能有用。
For example, the region subtags 'AA', 'ZZ', and in the ranges 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) MAY be used to form a language tag. A tag such as "zh-Hans-XQ" conveys a great deal of public, interchangeable information about the language material (that it is Chinese in the simplified Chinese script and is suitable for some geographic region 'XQ'). While the precise geographic region is not known outside of private agreement, the tag conveys far more information than an opaque tag such as "x-someLang", which contains no information about the language subtag or script subtag outside of the private agreement.
例如，区域子标签'AA'、'ZZ'以及范围'QM'-'QZ'和'XA'-'XZ'（源自ISO 3166专用代码）可用于形成语言标签。像“zh Hans XQ”这样的标签传达了大量关于语言材料的公开、可互换的信息（即它是简体中文，适合某些地理区域的“XQ”）。虽然在私人协议之外不知道确切的地理区域，但标记所传递的信息远远多于不透明的标记，如“x-someLang”，它不包含私人协议之外的语言子标记或脚本子标记的信息。
However, in some cases content tagged with private use subtags MAY interact with other systems in a different and possibly unsuitable manner compared to tags that use opaque, privately defined subtags, so the choice of the best approach sometimes depends on the particular domain in question.
但是，在某些情况下，与使用不透明的、私密定义的子标签的标签相比，使用私用子标签标记的内容可能以不同且可能不合适的方式与其他系统交互，因此，最佳方法的选择有时取决于所讨论的特定领域。
This section deals with the processes and requirements necessary for IANA to undertake to maintain the subtag and extension registries as defined by this document and in accordance with the requirements of [RFC2434].
本节涉及IANA根据[RFC2434]的要求维护本文件定义的子标签和扩展登记册所需的流程和要求。
The impact on the IANA maintainers of the two registries defined by this document will be a small increase in the frequency of new entries or updates.
本文件定义的两个注册中心对IANA维护者的影响将是新条目或更新频率的小幅增加。
Upon adoption of this document, the registry will be initialized by a companion document: [RFC4645]. The criteria and process for selecting the initial set of records are described in that document. The initial set of records represents no impact on IANA, since the work to create it will be performed externally.
通过本文件后，注册表将由一个附带文件[RFC4645]初始化。该文件描述了选择初始记录集的标准和过程。初始记录集对IANA没有影响，因为创建记录的工作将在外部执行。
The new registry MUST be listed under "Language Tags" at <http://www.iana.org/numbers.html>, replacing the existing registrations defined by [RFC3066]. The existing set of registration forms and RFC 3066 registrations MUST be relabeled as "Language Tags (Obsolete)" and maintained (but not added to or modified).
新注册表必须列在<http://www.iana.org/numbers.html>，替换[RFC3066]定义的现有注册。现有的注册表格和RFC 3066注册必须重新标记为“语言标签（过时）”并予以维护（但不得添加或修改）。
Future work on the Language Subtag Registry SHALL be limited to inserting or replacing whole records preformatted for IANA by the Language Subtag Reviewer as described in Section 3.3 of this document and archiving the forwarded registration form.
语言子标签注册的未来工作应限于插入或替换语言子标签审查员按照本文件第3.3节所述为IANA预先格式化的全部记录，并存档转发的注册表格。
Each record MUST be sent to iana@iana.org with a subject line indicating whether the enclosed record is an insertion of a new record (indicated by the word "INSERT" in the subject line) or a replacement of an existing record (indicated by the word "MODIFY" in the subject line). Records MUST NOT be deleted from the registry. IANA MUST place any inserted or modified records into the appropriate section of the language subtag registry, grouping the records by their 'Type' field. Inserted records MAY be placed anywhere in the appropriate section; there is no guarantee of the order of the records beyond grouping them together by 'Type'. Modified records MUST overwrite the record they replace.
每个记录必须发送到iana@iana.org主题行指示所附记录是插入新记录（在主题行中用“插入”一词表示）还是替换现有记录（在主题行中用“修改”一词表示）。不得从注册表中删除记录。IANA必须将任何插入或修改的记录放入language subtag注册表的相应部分，并按“类型”字段对记录进行分组。插入的记录可以放在适当部分的任何地方；除了按“类型”将记录分组在一起外，无法保证记录的顺序。修改后的记录必须覆盖其替换的记录。
Included in any request to insert or modify records MUST be a new File-Date record. This record MUST be placed first in the registry. In the event that the File-Date record present in the registry has a later date than the record being inserted or modified, the existing record MUST be preserved.
任何插入或修改记录的请求中必须包含新的文件日期记录。此记录必须放在注册表的第一位。如果注册表中的文件日期记录的日期晚于插入或修改的记录的日期，则必须保留现有记录。
The Language Tag Extensions Registry will also be generated and sent to IANA as described in Section 3.7. This registry can contain at most 35 records, and thus changes to this registry are expected to be very infrequent.
如第3.7节所述，还将生成语言标记扩展注册表并发送给IANA。此注册表最多可包含35条记录，因此对该注册表的更改预计非常少。
Future work by IANA on the Language Tag Extensions Registry is limited to two cases. First, the IESG MAY request that new records be inserted into this registry from time to time. These requests MUST include the record to insert in the exact format described in Section 3.7. In addition, there MAY be occasional requests from the maintaining authority for a specific extension to update the contact information or URLs in the record. These requests MUST include the complete, updated record. IANA is not responsible for validating the information provided, only that it is properly formatted. It should reasonably be seen to come from the maintaining authority named in the record present in the registry.
IANA在语言标记扩展注册中心的未来工作仅限于两种情况。首先，IESG可能会不时要求将新记录插入该注册表。这些请求必须包括以第3.7节所述格式插入的记录。此外，维护机构可能会偶尔请求特定扩展以更新记录中的联系信息或URL。这些请求必须包括完整、更新的记录。IANA不负责验证所提供的信息，只负责其格式正确。应合理地将其视为来自登记处记录中指定的维护机构。
Language tags used in content negotiation, like any other information exchanged on the Internet, might be a source of concern because they might be used to infer the nationality of the sender, and thus identify potential targets for surveillance.
与互联网上交换的任何其他信息一样，内容协商中使用的语言标签可能会引起关注，因为它们可能被用来推断发送者的国籍，从而确定潜在的监视目标。
This is a special case of the general problem that anything sent is visible to the receiving party and possibly to third parties as well. It is useful to be aware that such concerns can exist in some cases.
这是一般问题的一个特例，即发送的任何内容都对接收方可见，也可能对第三方可见。意识到这种担忧在某些情况下可能存在是有益的。
The evaluation of the exact magnitude of the threat, and any possible countermeasures, is left to each application protocol (see BCP 72 [RFC3552] for best current practice guidance on security threats and defenses).
威胁的确切程度和任何可能的对策的评估由每个应用程序协议决定（有关安全威胁和防御的最佳当前实践指南，请参阅BCP 72[RFC3552]）。
The language tag associated with a particular information item is of no consequence whatsoever in determining whether that content might contain possible homographs. The fact that a text is tagged as being in one language or using a particular script subtag provides no assurance whatsoever that it does not contain characters from scripts other than the one(s) associated with or specified by that language tag.
与特定信息项关联的语言标记在确定该内容是否可能包含同形词方面没有任何意义。文本被标记为使用一种语言或使用特定脚本子标记的事实不能保证它不包含与该语言标记关联或指定的脚本以外的脚本中的字符。
Since there is no limit to the number of variant, private use, and extension subtags, and consequently no limit on the possible length of a tag, implementations need to guard against buffer overflow attacks. See Section 4.3 for details on language tag truncation, which can occur as a consequence of defenses against buffer overflow.
由于变量、专用和扩展子标签的数量没有限制，因此标签的可能长度也没有限制，因此实现需要防止缓冲区溢出攻击。有关语言标记截断的详细信息，请参见第4.3节，这可能是防止缓冲区溢出的结果。
Although the specification of valid subtags for an extension (see Section 3.7) MUST be available over the Internet, implementations SHOULD NOT mechanically depend on it being always accessible, to prevent denial-of-service attacks.
尽管扩展的有效子标签规范（见第3.7节）必须在互联网上提供，但实现不应机械地依赖于它始终可访问，以防止拒绝服务攻击。
The syntax in this document requires that language tags use only the characters A-Z, a-z, 0-9, and HYPHEN-MINUS, which are present in most character sets, so the composition of language tags should not have any character set issues.
本文档中的语法要求语言标记仅使用大多数字符集中存在的字符A-Z、A-Z、0-9和连字符减号，因此语言标记的组合不应存在任何字符集问题。
Rendering of characters based on the content of a language tag is not addressed in this memo. Historically, some languages have relied on the use of specific character sets or other information in order to infer how a specific character should be rendered (notably this applies to language- and culture-specific variations of Han ideographs as used in Japanese, Chinese, and Korean). When language
基于语言标记内容的字符呈现不在本备忘录中讨论。历史上，一些语言依赖于特定字符集或其他信息的使用来推断特定字符的呈现方式（尤其适用于日语、汉语和韩语中使用的特定于语言和文化的汉表意文字变体）。当语言
tags are applied to spans of text, rendering engines sometimes use that information in deciding which font to use in the absence of other information, particularly where languages with distinct writing traditions use the same characters.
标记应用于文本的范围，呈现引擎有时在没有其他信息的情况下使用这些信息来决定使用哪种字体，特别是在具有不同书写传统的语言使用相同字符的情况下。
The main goals for this revision of language tags were the following:
此次语言标签修订的主要目标如下：
*Compatibility.* All RFC 3066 language tags (including those in the IANA registry) remain valid in this specification. The changes in this document represent additional constraints on language tags. That is, in no case is the syntax more permissive and processors based on the ABNF and other provisions of RFC 3066 (such as those described in [XMLSchema]) will be able to process the tags described by this document. In addition, this document defines language tags in such as way as to ensure future compatibility.
*兼容性。*所有RFC 3066语言标记（包括IANA注册表中的标记）在本规范中保持有效。本文档中的更改表示对语言标记的附加约束。也就是说，在任何情况下，语法都是不允许的，基于ABNF和RFC 3066的其他规定（如[XMLSchema]中所述）的处理器将能够处理本文档所述的标记。此外，本文档还定义了语言标记，以确保将来的兼容性。
*Stability.* Because of changes in the past in the underlying ISO standards, a valid RFC 3066 language tag could become invalid or have its meaning change. This has the potential of invalidating content that may have an extensive shelf-life. In this specification, once a language tag is valid, it remains valid forever.
*稳定性。*由于过去基础ISO标准的变化，有效的RFC 3066语言标签可能会失效或其含义发生变化。这有可能使可能具有较长保质期的内容无效。在本规范中，一旦语言标记有效，它将永远有效。
*Validity.* The structure of language tags defined by this document makes it possible to determine if a particular tag is well-formed without regard for the actual content or "meaning" of the tag as a whole. This is important because the registry grows and underlying standards change over time. In addition, it must be possible to determine if a tag is valid (or not) for a given point in time in order to provide reproducible, testable results. This process must not be error-prone; otherwise implementations might give different results. By having an authoritative registry with specific versioning information, the validity of language tags at any point in time can be precisely determined (instead of interpolating values from many separate sources).
*有效性。*本文件定义的语言标记的结构使我们能够在不考虑标记作为一个整体的实际内容或“含义”的情况下确定特定标记的格式是否正确。这一点很重要，因为注册表会随着时间的推移而增长，而基础标准也会随之变化。此外，必须能够确定标签在给定时间点是否有效，以提供可复制、可测试的结果。这个过程不能容易出错；否则，实现可能会给出不同的结果。通过拥有具有特定版本控制信息的权威注册中心，可以精确地确定语言标记在任何时间点的有效性（而不是从许多单独的源插入值）。
*Utility.* It is sometimes important to be able to differentiate between written forms of a language -- for many implementations this is more important than distinguishing between the spoken variants of a language. Languages are written in a wide variety of different scripts, so this document provides for the generative use of ISO 15924 script codes. Like the generative use of ISO language and country codes in RFC 3066, this allows combinations to be produced without resorting to the registration process. The addition of UN M.49 codes provides for the generation of language tags with regional scope, which is also required by some applications.
*实用工具。*有时能够区分一种语言的书面形式很重要——对于许多实现来说，这比区分一种语言的口语变体更重要。语言是用各种不同的脚本编写的，因此本文档提供了ISO 15924脚本代码的生成性使用。与RFC 3066中ISO语言和国家代码的生成性使用一样，这允许在不诉诸注册过程的情况下生成组合。添加UN M.49代码可生成具有区域范围的语言标记，这也是某些应用程序所需的。
The recast of the registry from containing whole language tags to subtags is a key part of this. An important feature of RFC 3066 was that it allowed generative use of subtags. This allows people to meaningfully use generated tags, without the delays in registering whole tags or the need to register all of the combinations that might be useful.
注册表从包含全语言标记到子标记的重铸是其中的一个关键部分。RFC3066的一个重要特征是它允许子标签的生成性使用。这允许人们有意义地使用生成的标记，而不需要延迟注册整个标记，也不需要注册可能有用的所有组合。
The choice of placing the extended language and script subtags between the primary language and region subtags was widely debated. This design was chosen because the prevalent matching and content negotiation schemes rely on the subtags being arranged in order of increasing specificity. That is, the subtags that mark a greater barrier to mutual intelligibility appear left-most in a tag. For example, when selecting content written in Azerbaijani, the script (Arabic, Cyrillic, or Latin) represents a greater barrier to understanding than any regional variations (those associated with Azerbaijan or Iran, for example). Individuals who prefer documents in a particular script, but can deal with the minor regional differences, can therefore select appropriate content. Applications that do not deal with written content will continue to omit these subtags.
将扩展语言和脚本子标签置于主语言和区域子标签之间的选择引起了广泛的争论。之所以选择这种设计，是因为流行的匹配和内容协商方案依赖于按增加特异性的顺序排列的子标签。也就是说，标记相互可理解性更大障碍的子标记出现在标记的最左侧。例如，在选择以阿塞拜疆语编写的内容时，该脚本（阿拉伯语、西里尔语或拉丁语）比任何地区变体（例如与阿塞拜疆或伊朗相关的变体）更难理解。个人喜欢特定脚本中的文档，但可以处理较小的区域差异，因此可以选择适当的内容。不处理书面内容的应用程序将继续忽略这些子标签。
*Extensibility.* Because of the widespread use of language tags, it is disruptive to have periodic revisions of the core specification, even in the face of demonstrated need. The extension mechanism provides for a way for independent RFCs to define extensions to language tags. These extensions have a very constrained, well-defined structure that prevents extensions from interfering with implementations of language tags defined in this document.
*可扩展性。*由于语言标记的广泛使用，即使面对已证明的需求，也会对核心规范进行定期修订。扩展机制为独立的RFC提供了一种定义语言标记扩展的方法。这些扩展有一个非常受约束、定义良好的结构，可以防止扩展干扰本文档中定义的语言标记的实现。
The document also anticipates features of ISO 639-3 with the addition of the extended language subtags, as well as the possibility of other ISO 639 parts becoming useful for the formation of language tags in the future.
本文件还预测了ISO 639-3的特点，以及扩展语言子标签的添加，以及其他ISO 639部分将来对语言标签的形成有用的可能性。
The use and definition of private use tags have also been modified, to allow people to use private use subtags to extend or modify defined tags and to move as much information as possible out of private use and into the regular structure.
私用标签的使用和定义也进行了修改，以允许人们使用私用子标签扩展或修改定义的标签，并将尽可能多的信息移出私用并转移到常规结构中。
The goal for each of these modifications is to reduce or eliminate the need for future revisions of this document.
这些修改的目的是减少或消除本文件未来修订的需要。
The specific changes in this document to meet these goals are:
为实现这些目标，本文件中的具体变更如下：
o Defines the ABNF and rules for subtags so that the category of all subtags can be determined without reference to the registry.
o 定义子标签的ABNF和规则，以便在不参考注册表的情况下确定所有子标签的类别。
o Adds the concept of well-formed vs. validating processors, defining the rules by which an implementation can claim to be one or the other.
o 添加了格式良好与验证处理器的概念，定义了实现可以声明为一个或另一个的规则。
o Replaces the IANA language tag registry with a language subtag registry that provides a complete list of valid subtags in the IANA registry. This allows for robust implementation and ease of maintenance. The language subtag registry becomes the canonical source for forming language tags.
o 将IANA语言标记注册表替换为语言子标记注册表，该注册表提供IANA注册表中有效子标记的完整列表。这允许稳健的实施和易于维护。language subtag注册表成为形成语言标记的规范源。
o Provides a process that guarantees stability of language tags, by handling reuse of values by ISO 639, ISO 15924, and ISO 3166 in the event that they register a previously used value for a new purpose.
o 提供了一个确保语言标记稳定性的过程，在ISO 639、ISO 15924和ISO 3166为新目的注册以前使用的值时，通过处理值的重用来保证语言标记的稳定性。
o Allows ISO 15924 script code subtags and allows them to be used generatively. Defines a method for indicating in the registry when script subtags are necessary for a given language tag.
o 允许ISO 15924脚本代码子标记，并允许生成性地使用它们。定义一种方法，用于在注册表中指示给定语言标记何时需要脚本子标记。
o Adds the concept of a variant subtag and allows variants to be used generatively.
o 添加变体子标签的概念，并允许生成性地使用变体。
o Adds the ability to use a class of UN M.49 tags for supra-national regions and to resolve conflicts in the assignment of ISO 3166 codes.
o 增加了为超国家地区使用一类UN M.49标记以及解决ISO 3166代码分配冲突的能力。
o Defines the private use tags in ISO 639, ISO 15924, and ISO 3166 as the mechanism for creating private use language, script, and region subtags, respectively.
o 分别将ISO 639、ISO 15924和ISO 3166中的专用标记定义为创建专用语言、脚本和区域子标记的机制。
o Adds a well-defined extension mechanism.
o 添加定义良好的扩展机制。
o Defines an extended language subtag, possibly for use with certain anticipated features of ISO 639-3.
o 定义扩展语言子标签，可能用于ISO 639-3的某些预期功能。
[ISO10646] International Organization for Standardization, "ISO/IEC 10646:2003. Information technology -- Universal Multiple-Octet Coded Character Set (UCS)", 2003.
[ISO10646]国际标准化组织，“ISO/IEC 10646:2003.信息技术——通用多八位编码字符集（UCS）”，2003年。
[ISO15924] International Organization for Standardization, "ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts", January 2004.
[ISO15924]国际标准化组织，“ISO 15924:2004.信息和文件——脚本名称表示代码”，2004年1月。
[ISO3166-1] International Organization for Standardization, "ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", 1997.
[ISO3166-1]国际标准化组织，“ISO 3166-1:1997.国家及其分支机构名称表示代码——第1部分：国家代码”，1997年。
[ISO639-1] International Organization for Standardization, "ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code", 2002.
[ISO639-1]国际标准化组织，“ISO 639-1:2002.语言名称表示代码——第1部分：阿尔法-2代码”，2002年。
[ISO639-2] International Organization for Standardization, "ISO 639-2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code, first edition", 1998.
[ISO639-2]国际标准化组织，“ISO 639-2:1998.语言名称表示代码——第2部分：阿尔法-3代码，第一版”，1998年。
[ISO646] International Organization for Standardization, "ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.", 1991.
[ISO646]国际标准化组织，“ISO/IEC 646:1991，信息技术——信息交换用ISO 7位编码字符集”，1991年。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[RFC2028]Hovey，R.和S.Bradner，“参与IETF标准过程的组织”，BCP 11，RFC 2028，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC2860]Carpenter，B.，Baker，F.和M.Roberts，“关于互联网分配号码管理局技术工作的谅解备忘录”，RFC 28602000年6月。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339]Klyne，G.，Ed.和C.Newman，“互联网上的日期和时间：时间戳”，RFC33392002年7月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[UN_M.49] Statistics Division, United Nations, "Standard Country or Area Codes for Statistical Use", UN Standard Country or Area Codes for Statistical Use, Revision 4 (United Nations publication, Sales No. 98.XVII.9, June 1999.
[UN_M.49]联合国统计司，“统计用途标准国家或地区代码”，联合国统计用途标准国家或地区代码，第4版（联合国出版物，出售品编号：98.XVII.9，1999年6月）。
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC1766]Alvestrand，H.，“语言识别标签”，RFC1766，1995年3月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781]Hoffman，P.和F.Yergeau，“UTF-16，ISO 10646编码”，RFC 2781，2000年2月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC4645] Ewell, D., Ed., "Initial Language Subtag Registry", RFC 4645, September 2006.
[RFC4645]Ewell，D.，编辑，“初始语言子标签注册”，RFC 46452006年9月。
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
[RFC4647]Phillips，A.，Ed.和M.Davis，Ed.，“语言标记的匹配”，BCP 47，RFC 4647，2006年9月。
[Unicode] Unicode Consortium, "The Unicode Standard, Version 5.0", Boston, MA, Addison-Wesley, 2007. ISBN 0-321- 48091-0.
[Unicode]Unicode联盟，“Unicode标准，5.0版”，马萨诸塞州波士顿，Addison-Wesley，2007年。ISBN 0-321-48091-0。
[XML10] Bray (et al), T., "Extensible Markup Language (XML) 1.0", 02 2004.
[XML10]Bray（等人），T，“可扩展标记语言（XML）1.0”，2004年2月。
[XMLSchema] Biron, P., Ed. and A. Malhotra, Ed., "XML Schema Part 2: Datatypes Second Edition", 10 2004, < http://www.w3.org/TR/xmlschema-2/>.
[XMLSchema]Biron，P.，Ed.和A.Malhotra，Ed.，“XML模式第2部分：数据类型第二版”，2004年10月，<http://www.w3.org/TR/xmlschema-2/>.
[iso639.prin] ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory Committee: Working principles for ISO 639 maintenance", March 2000, <http://www.loc.gov/ standards/iso639-2/iso639jac_n3r.html>.
[iso639.prin]ISO 639联合咨询委员会，“ISO 639联合咨询委员会：ISO 639维护工作原则”，2000年3月<http://www.loc.gov/ 标准/iso639-2/iso639jac_n3r.html>。
[record-jar] Raymond, E., "The Art of Unix Programming", 2003, <urn:isbn:0-13-142901-9>.
[record jar]Raymond，E.，“Unix编程的艺术”，2003年，<urn:isbn:0-13-142901-9>。
Any list of contributors is bound to be incomplete; please regard the following as only a selection from the group of people who have contributed to make this document what it is today.
任何贡献者的名单都是不完整的；请将以下内容视为仅从为本文件的编制做出贡献的人员中选出的一部分。
The contributors to RFC 3066 and RFC 1766, the precursors of this document, made enormous contributions directly or indirectly to this document and are generally responsible for the success of language tags.
本文档的前身RFC 3066和RFC 1766的贡献者直接或间接地为本文档做出了巨大贡献，并且通常对语言标记的成功负有责任。
The following people (in alphabetical order) contributed to this document or to RFCs 1766 and 3066:
以下人员（按字母顺序）对本文件或RFCs 1766和3066作出了贡献：
Glenn Adams, Harald Tveit Alvestrand, Tim Berners-Lee, Marc Blanchet, Nathaniel Borenstein, Karen Broome, Eric Brunner, Sean M. Burke, M.T. Carrasco Benitez, Jeremy Carroll, John Clews, Jim Conklin, Peter Constable, John Cowan, Mark Crispin, Dave Crocker, Elwyn Davies, Martin Duerst, Frank Ellerman, Michael Everson, Doug Ewell, Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, Joel Halpren, Elliotte Rusty Harold, Paul Hoffman, Scott Hollenbeck, Richard Ishida, Olle Jarnefors, Kent Karlsson, John Klensin, Erkki Kolehmainen, Alain LaBonte, Eric Mader, Ira McDonald, Keith Moore, Chris Newman, Masataka Ohta, Dylan Pierce, Randy Presuhn, George Rhoten, Felix Sasaki, Markus Scherer, Keld Jorn Simonsen, Thierry Sourbier, Otto Stolz, Tex Texin, Andrea Vine, Rhys Weatherley, Misha Wolf, Francois Yergeau and many, many others.
格伦·亚当斯、哈拉尔德·特维特·阿尔维斯特兰德、蒂姆·伯纳斯·李、马克·布兰切特、纳撒尼尔·博伦斯坦、凯伦·布鲁姆、埃里克·布伦纳、肖恩·M·伯克、M.T·卡拉斯科·贝尼特斯、杰里米·卡罗尔、约翰·克莱斯、吉姆·康克林、彼得·康斯特布尔、约翰·考恩、马克·克里斯宾、戴夫·克罗克、埃尔文·戴维斯、马丁·杜尔斯、弗兰克·埃勒曼、迈克尔·埃弗森、道格·埃威尔、内德、，蒂姆·古德温、德克·威廉·范·古利克、马里恩·冈恩、乔尔·哈普伦、埃利奥特·拉斯蒂·哈罗德、保罗·霍夫曼、斯科特·霍伦贝克、理查德·石田、奥利·贾内福斯、肯特·卡尔森、约翰·克莱辛、埃尔基·科勒梅宁、阿兰·拉邦特、埃里克·马德、爱尔兰共和军麦克唐纳、基思·摩尔、克里斯·纽曼、大塔、迪伦·皮尔斯、兰迪·普雷森、乔治·罗腾、菲利克斯·萨奇、，马库斯·谢勒、凯尔德·乔恩·西蒙森、蒂埃里·苏尔比尔、奥托·斯托尔茨、特克斯·特辛、安德里亚·维恩、里斯·韦瑟利、米莎·沃尔夫、弗朗索瓦·耶尔乔和许多其他人。
Very special thanks must go to Harald Tveit Alvestrand, who originated RFCs 1766 and 3066, and without whom this document would not have been possible. Special thanks must go to Michael Everson, who has served as Language Tag Reviewer for almost the complete period since the publication of RFC 1766. Special thanks to Doug Ewell, for his production of the first complete subtag registry, and his work in producing a test parser for verifying language tags.
必须特别感谢Harald Tveit Alvestrand，他是RFC 1766和3066的发起人，没有他，本文件就不可能完成。特别要感谢Michael Everson，自RFC1766出版以来，他担任语言标签审稿人几乎整整一段时间。特别感谢Doug Ewell，他制作了第一个完整的subtag注册表，并制作了一个用于验证语言标记的测试解析器。
Appendix B. Examples of Language Tags (Informative)
附录B.语言标签示例（资料性）
Simple language subtag:
简单语言子标签：
de (German)
德文
fr (French)
法文主任（法文）
ja (Japanese)
ja（日语）
i-enochian (example of a grandfathered tag)
i-enochian（祖父标记的示例）
Language subtag plus Script subtag:
语言子标签和脚本子标签：
zh-Hant (Chinese written using the Traditional Chinese script)
zh Hant（繁体中文书写）
zh-Hans (Chinese written using the Simplified Chinese script)
zh Hans（简体中文书写）
sr-Cyrl (Serbian written using the Cyrillic script)
sr Cyrl（塞尔维亚语，使用西里尔文书写）
sr-Latn (Serbian written using the Latin script)
高级拉丁语（塞尔维亚语，用拉丁语书写）
Language-Script-Region:
语言脚本区域：
zh-Hans-CN (Chinese written using the Simplified script as used in mainland China)
zh Hans CN（中国大陆使用的简体中文书写）
sr-Latn-CS (Serbian written using the Latin script as used in Serbia and Montenegro)
sr Latn CS（塞尔维亚语，使用塞尔维亚和黑山语中使用的拉丁语书写）
Language-Variant:
语言变体：
sl-rozaj (Resian dialect of Slovenian
sl rozaj（斯洛文尼亚的Resian方言）
sl-nedis (Nadiza dialect of Slovenian)
sl nedis（斯洛文尼亚的纳迪扎方言）
Language-Region-Variant:
语言区域变体：
de-CH-1901 (German as used in Switzerland using the 1901 variant [orthography])
de-CH-1901（瑞士使用的德语，使用1901变体[正字法]）
sl-IT-nedis (Slovenian as used in Italy, Nadiza dialect)
sl IT nedis（意大利使用的斯洛文尼亚语，纳迪扎方言）
Language-Script-Region-Variant:
语言脚本区域变量：
sl-Latn-IT-nedis (Nadiza dialect of Slovenian written using the Latin script as used in Italy. Note that this tag is NOT RECOMMENDED because subtag 'sl' has a Suppress-Script value of 'Latn')
sl Latn IT nedis（斯洛文尼亚纳迪扎方言，使用意大利使用的拉丁语书写。请注意，不建议使用此标记，因为子标记“sl”的抑制脚本值为“Latn”）
Language-Region:
语言区：
de-DE (German for Germany)
德德（德语代表德国）
en-US (English as used in the United States)
en US（美国使用的英语）
es-419 (Spanish appropriate for the Latin America and Caribbean region using the UN region code)
es-419（适用于拉丁美洲和加勒比区域的西班牙语，使用联合国区域代码）
Private use subtags:
专用子标签：
de-CH-x-phonebk
de-CH-x-phonebk
az-Arab-x-AZE-derbend
az-Arab-x-AZE-derbend
Extended language subtags (examples ONLY: extended languages MUST be defined by revision or update to this document):
扩展语言子标签（仅示例：必须通过修订或更新本文档来定义扩展语言）：
zh-min
中民
zh-min-nan-Hant-CN
中民南韩中国
Private use registry values:
专用注册表值：
x-whatever (private use using the singleton 'x')
x-whatever（使用单例“x”的私人用途）
qaa-Qaaa-QM-x-southern (all private tags)
qaa-Qaaa-QM-x-southern（所有私人标签）
de-Qaaa (German, with a private script)
de Qaaa（德语，带私人脚本）
sr-Latn-QM (Serbian, Latin-script, private region)
高级拉丁语QM（塞尔维亚语、拉丁语、私人区域）
sr-Qaaa-CS (Serbian, private script, for Serbia and Montenegro)
高级Qaaa CS（塞尔维亚语，私人脚本，用于塞尔维亚和黑山）
Tags that use extensions (examples ONLY: extensions MUST be defined by revision or update to this document or by RFC):
使用扩展名的标记（仅示例：扩展名必须通过本文档的修订或更新或RFC定义）：
en-US-u-islamCal
en-US-u-islamCal
zh-CN-a-myExt-x-private
zh-CN-a-myExt-x-private
en-a-myExt-b-another
en-a-myExt-b-other
Some Invalid Tags:
一些无效标记：
de-419-DE (two region tags)
de-419-de（两个区域标签）
a-DE (use of a single-character subtag in primary position; note that there are a few grandfathered tags that start with "i-" that are valid)
a-DE（在主位置使用单个字符的子标记；注意，有几个以“i-”开头的祖父标记是有效的）
ar-a-aaa-b-bbb-a-ccc (two extensions with same single-letter prefix)
ar-a-aaa-b-bbb-a-ccc（具有相同单字母前缀的两个分机）
Authors' Addresses
作者地址
Addison Phillips (Editor) Yahoo! Inc.
艾迪生·菲利普斯（编辑）雅虎！股份有限公司。
EMail: addison@inter-locale.com
EMail: addison@inter-locale.com
Mark Davis (Editor) Google
马克·戴维斯（编辑）谷歌
EMail: mark.davis@macchiato.com or mark.davis@google.com
EMail: mark.davis@macchiato.com or mark.davis@google.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。