[要約] RFC 4646は、言語を識別するためのタグに関する規格であり、言語タグの構造と使用方法を定義しています。このRFCの目的は、異なるシステムやプロトコル間で一貫した言語の識別を可能にすることです。
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).
Copyright（C）The Internet Society（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 1766を置き換えたRFC 3066を置き換えます。
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
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ブラウザでのユーザーの言語設定を使用して、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.
使用されている言語を示す1つの方法は、情報コンテンツに識別子または「タグ」でラベルを付けることです。これらのタグを使用して、情報コンテンツを選択するときのユーザー設定を指定したり、コンテンツおよび関連リソースの追加属性にラベルを付けたりすることができます。
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]と組み合わせて、[RFC1766]を置き換えた[RFC3066]を置き換えます。このドキュメントの変更点のリストについては、セクション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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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.
言語タグは、「サブタグ」と呼ばれる1つ以上の部分で構成されています。各サブタグは、一連の英数字で構成されます。サブタグは区別され、ハイフン（ "-"、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
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
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
variant = 5*8alphanum ; registered variants
/ (DIGIT 3alphanum)
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
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
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には微妙な点があります。数字で始まるバリアントは4文字の長さでもかまいませんが、文字で始まるバリアントは少なくとも5文字でなければなりません。
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.
大文字と小文字の区別は言語タグでは意味を持ちませんが、タグの一貫したフォーマットと表示はユーザーに役立ちます。レジストリ内のタグとサブタグの形式は推奨されています。この形式では、先頭以外の2文字のサブタグはすべて大文字、先頭以外の4文字のサブタグはタイトルケース、その他のすべてのサブタグは小文字です。
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.
言語タグとそのサブタグの名前空間は、このドキュメントのセクション5のルールに従って、Internet Assigned Numbers Authority（IANA）[RFC2860]によって管理されます。 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 サブタグは、「fr-Latn-CA」のサブタグ「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 1つまたは複数のコードは、外部標準で定義された値を指します（このドキュメントではサブタグとして使用されます）。たとえば、「Latn」は、言語タグで使用する「Latn」スクリプトサブタグを定義するために使用された[ISO15924]スクリプトコードです。このドキュメントのコードの例は、単一引用符（ '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.
1文字および1桁のサブタグは、現在または将来の使用のために予約されています。これらには、以下の現在の使用法が含まれます。o 1文字のサブタグ「x」は、一連の私的使用サブタグを導入するために予約されています。私的使用のサブタグの解釈は、私的な合意によってのみ定義され、このセクションのルールや、このドキュメントで定義されている標準やレジストリでは定義されていません。
o All other single-letter subtags are reserved to introduce standardized extension subtag sequences as described in Section 3.7.
o 他のすべての1文字のサブタグは、セクション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.
1文字のサブタグ「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:
1次言語サブタグは、言語タグの最初のサブタグであり（私的使用と特定の祖父タグを除く）、省略できません。以下の規則が1次言語サブタグに適用されます。
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. すべての2文字の言語サブタグは、標準のISO 639パート1、「ISO 639-1：2002、言語の名前を表すためのコード-パート1：Alpha-2コード」にある割り当てに従って、IANAレジストリで定義されました。 "[ISO639-1]、またはその後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. すべての3文字の言語サブタグは、ISO 639パート2、「ISO 639-2：1998-言語の名前を表すコード-パート2：Alpha-3コード-エディション」にある割り当てに従って、IANAレジストリで定義されました。 1インチ[ISO639-2]、またはその後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-'に続く私用サブタグを使用する代わりに）未登録の一次言語サブタグに使用できます（MAY）。プライベート使用サブタグの詳細については、セクション4.5を参照してください。
4. All four-character language subtags are reserved for possible future standardization.
4. 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 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.
5. IANAレジストリ内の5〜8文字の長さのすべての言語サブタグは、セクション3.5の登録プロセスで定義され、主要言語サブタグを形成するために使用できます。このドキュメントが作成された時点では、この種のサブタグの例はなく、このタイプの今後の登録は推奨されません。主要言語は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. 1次サブタグとしての1文字のサブタグ「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」は、「i-klingon」や「i-bnn」などの一部の祖父タグ（セクション2.2.8を参照）で使用されます。 （他の祖父のタグには、最初の位置に第一言語サブタグがあります。）
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 2文字コードとISO 639-2 3文字コードの両方がある言語の場合、ISO 639-1 2文字コードのみがIANAレジストリーで定義されます。
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の2文字コードがなく、ISO 639-2 / T（用語）コードとISO 639-2 / B（書誌）コードが異なる言語の場合、用語コードのみが定義されています。 IANAレジストリ。このドキュメントが作成された時点では、両方の種類の3文字のコードを持つすべての言語にも2文字のコードが割り当てられていました。この性質の将来の割り当てが発生することは予期されていません。
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 Registration Authority Joint Advisory Committee（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." 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の凍結時点の言語コードは、後でISO 639-1に追加されません。これは、ユーザーがインターネットアプリケーションでその言語のアルファ2コードが利用できない場合のアルファ3コード。」タグの正規形式の不安定性を回避するために、3文字のコードがすでにISO 639-2に含まれている言語の2文字のコードがISO 639-1に追加された場合、2文字のコードは登録されていません。セクション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.
たとえば、一部のコンテンツに現在2文字のコードがない「haw」（ハワイ語）のタグが付けられている場合、ISO 639-1が2文字のコードをハワイ語に割り当てても、タグは無効になりません。後日。
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登録の1つは「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. プライマリサブタグの直後に続く3文字のサブタグは、将来の標準化のために予約されており、現在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. 最大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.
拡張言語サブタグレコードは、レジストリに表示された後、拡張言語サブタグのプレフィックスとして常に表示する必要がある適切な言語サブタグまたはサブタグのシーケンスを示す「プレフィックス」フィールドを1つだけ含める必要があります。
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」が中国語を表す場合があります方言「ガン」。
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. 4文字のサブタグはすべて[ISO15924]-「スクリプトの名前を表すためのコード」に従って定義されました：アルファ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. 言語タグには最大で1つのスクリプトサブタグが存在する必要があり、タグに区別できる値が追加されない場合、またはプライマリ言語サブタグのレコードに該当するスクリプトサブタグをリストする抑制スクリプトフィールドが含まれている場合は、スクリプトサブタグを省略してください。
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. プライマリサブタグに続く2文字のサブタグはすべて、[ISO3166-1]にある割り当て（「国名とその下位区分の表現のためのコード-パート1：国コード」）に従ってIANAレジストリで定義され、 alpha-2国コードのリスト、またはその後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. 1次サブタグに続く数字（数値）文字で構成される3文字のサブタグはすべて、IANAレジストリーで、統計基準の国連標準国または地域コードにある割り当て[UN_M.49]にある割り当て、またはその後統治標準によって行われる割り当てに従って定義されました。体。国連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コードのある国または地域のUN数値コードは、レジストリに入力するときに、セクション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]で登録の対象としてリストされているが現在登録されていない国または地域の国連数値コードおよびISO 3166 alpha-2コードは、セクション3.5で説明されているプロセスを介して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. 言語タグには最大で1つの領域サブタグが存在する必要があり、領域サブタグは、タグに区別する値を追加しない場合と同様に省略できます。
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が私的使用のために予約したコードに対応しています。これらのコードは、（私的使用サブタグシーケンスを使用する代わりに）私的使用領域サブタグに使用できます（MAY）。プライベート使用サブタグの詳細については、セクション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」は、セルビアおよびモンテネグロ（「CS」）で使用されているラテン文字（「Latn」）を使用して記述されたセルビア語（「sr」）を表します。
"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）で始まるバリアントサブタグは、少なくとも5文字の長さでなければなりません。
2. Variant subtags that begin with a digit (0-9) MUST be at least four characters long.
2. 数字（0-9）で始まるバリアントサブタグは、少なくとも4文字の長さである必要があります。
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".
言語サブタグレジストリのバリアントサブタグレコードには、1つ以上の「プレフィックス」フィールドが含まれる場合があります。これは、バリアントで言語タグを形成する際に適切なプレフィックスを（必要に応じて他のサブタグと共に）作成する言語タグを示します。たとえば、サブタグ「nedis」には「sl」のプレフィックスが付いているため、「sl-nedis」や「sl-IT-nedis」などの言語タグの作成には適していますが、「」などのタグでの使用には適していません。 zh-nedis」または「it-IT-nedis」。
"sl-nedis" represents the Natisone or Nadiza dialect of Slovenian.
「sl-nedis」は、スロベニア語のナチソーネまたはナディザ方言を表します。
"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」は、異なるスペルの修正の日付を表すため、同じタグでは使用しないでください。別のバリアントと組み合わせて有意義に使用できるバリアントは、その他のバリアントをリストする 'Prefix'フィールドをレジストリレコードに含める必要があります（SHOULD）。たとえば、別のドイツ語のバリアント 'example'が作成され、 '1996'で使用するのが理にかなっている場合、 'example'には2つの接頭辞フィールド「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. 拡張サブタグは、このドキュメントで定義されている他のサブタグと1文字のサブタグ（「シングルトン」）で区切られています。シングルトンは、セクション3.7で説明されているメカニズムを介して登録機関に割り当てられたものである必要があり、プライベート使用のサブタグシーケンス用に予約されている文字「x」であってはなりません。
2. Note: Private use subtag sequences starting with the singleton subtag 'x' are described in Section 2.2.7 below.
2. 注：シングルトンサブタグ「x」で始まる私用サブタグシーケンスについては、以下のセクション2.2.7で説明します。
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. 拡張機能は、少なくとも1次言語サブタグの後に続く必要があります。つまり、言語タグを拡張子で始めることはできません。拡張機能は言語タグを拡張しますが、それらをオーバーライドしたり置き換えたりすることはありません。たとえば、「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. 各シングルトンサブタグは、（プライベート使用サブタグとしての場合を除いて）各タグに最大で1回出現する必要があります。つまり、シングルトンサブタグを繰り返すことはできません。たとえば、サブタグ「a」が2回出現するため、タグ「en-a-bbb-a-ccc」は無効です。タグ「en-a-bbb-x-a-ccc」は、シングルトン「a」の2番目の出現が私的使用シーケンスであるため有効です。
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. 各シングルトンの後には、少なくとも1つの拡張サブタグが続く必要があります。たとえば、最初のシングルトン「a」の直後に別のシングルトン「b」が続くため、タグ「tlh-a-b-foo」は無効です。
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. 1つのタグに複数の拡張機能が含まれる場合は、セクション4.4で説明されているように、タグを正規化する必要があります（SHOULD）。
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".
たとえば、プレフィックスシングルトン '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. プライベート使用のサブタグは、このドキュメントで定義されている他のサブタグと、予約済みの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 InternationalのEthnologueの出版物からのコードを言語識別に利用したいユーザーは、「az-Arab-x-AZE-derbend」などのタグを交換することに同意する場合があります。この例には、2つの私用サブタグが含まれています。 1つ目は「AZE」、2つ目は「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登録済み言語タグは、それらの有効性を維持します。これらのタグは、「祖父」または「冗長」タイプのいずれかのレコードでレジストリに保持されます。祖父のタグには、言語サブタグレジストリで定義されていない1つ以上のサブタグが含まれています（セクション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.
実装では、このドキュメントで説明されているルールと実践に関して、その機能を説明する必要がある場合があります。このドキュメントで説明する準拠実装には、「整形式」プロセッサと「検証」プロセッサの2つのクラスがあります。適合主張はこれらの定義の1つを明示的に参照する必要があります。
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 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.
oバリアントおよび拡張言語サブタグの場合、レジストリにそのサブタグの「プレフィックス」フィールドが1つ以上含まれている場合は、タグが少なくとも1つのプレフィックスと一致することを確認してください。 「プレフィックス」内のすべてのサブタグもタグに表示される場合、タグは一致します。たとえば、「es」言語サブタグと「CO」地域サブタグの両方がタグに表示されるため、接頭辞「es-CO」はタグ「es-Latn-CO-x-private」と一致します。
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).
このセクションでは、言語サブタグレジストリとそれに関連付けられたメンテナンスおよび更新手順、および言語タグの拡張機能のレジストリ（セクション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.)
言語サブタグレジストリには、言語タグで有効なすべてのサブタグの包括的なリストが含まれています。これにより、実装者は言語タグを検証するための簡単で信頼できる方法を使用できます。言語サブタグレジストリは、拡張サブタグを除いて、このドキュメントまたはその改訂版または後継版の規定に基づいて言語タグに表示されるすべてのサブタグを検証できるように維持されます。さらに、さまざまなサブタグの意味は、あいまいでなく、長期にわたって安定しています。 （もちろん、私的使用サブタグの意味は、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]で説明されているrecord-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]):
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]レパートリー外からの文字、およびフィールド本体で発生するAMPERSAND文字（ "＆"、％x26）は、スタイルの16進表記を使用した "数値文字参照"で表されます。 [XML10]で使用されます（<http://www.w3.org/TR/REC-xml/#dt-charref>を参照）。これは、シーケンス "＆＃x"（％x26.23.78）と、それに続く[ISO10646]の文字のコードポイントの16進表記と、それに続くセミコロン（％x3B）で構成されます。たとえば、ユーロ記号U + 20ACは、「＆＃x20AC;」というシーケンスで表されます。 16進表記は2桁から6桁の数値である場合があります。
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 Webサイトのレジストリが最新です。それより古い日付のバージョンは最新ではありません。
File-Date: 2004-06-28 %%
ファイル日付：2004-06-28 %%
Figure 3: Example of the File-Date Record
図3：File-Dateレコードの例
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'
後続のレコードは、レジストリのサブタグを表します。各レコードの各フィールドは、以下で特に明記されていない限り、1回だけ出現する必要があります。各レコードには、次のフィールドが含まれている必要があります。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.
* タイプのフィールド値は、「language」、「extlang」、「script」、「region」、「variant」、「grandfathered」、「redundant」のいずれかの文字列で構成する必要があり、タグまたはサブタグのタイプを示します。
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
* タグのフィールド値には完全な言語タグが含まれています。このフィールドは、「タイプ」が「祖父」または「冗長」のいずれかの値を持つレコードにのみ表示される必要があります。フィールド値は常にセクション2.1のABNFの「祖父」の生成に従います。
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のfield-valueには、レコードがレジストリに追加された日付が含まれています。
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.
「サブタグ」または「タグ」フィールドでは、2つの例外を除いて、小文字を使用してサブタグまたはタグを形成する必要があります。 「タイプ」フィールドが「スクリプト」であるサブタグ（つまり、ISO 15924で定義されているサブタグ）では、タイトルケースを使用する必要があります。 「タイプ」フィールドが「リージョン」であるサブタグ（つまり、ISO 3166で定義されているサブタグ）では、大文字を使用する必要があります。これらの例外は、基になる標準での大文字小文字の使用を反映しています。
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.
「説明」フィールドは複数回表示される場合があり、レコード内のタグまたはサブタグの説明が含まれます。 「説明」フィールドの少なくとも1つは、ラテン文字に記述または転記する必要があります。同じまたは追加のフィールドには、ラテン語以外のスクリプトの説明が含まれる場合があります。 「説明」フィールドは識別の目的で使用され、言語またはバリエーションの実際のネイティブ名を表す、または特定の言語であると解釈してはなりません。ほとんどの説明は、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.
* 接頭辞のフィールド値には、このサブタグを使用して新しい言語タグを形成できる言語タグが含まれている可能性があり、おそらく他のサブタグも同様です。このフィールドは、「Type」フィールドの値が「variant」または「extlang」であるレコードにのみ出現する必要があります。たとえば、バリアント 'nedis'の 'Prefix'は 'sl'です。これは、タグ "is-nedis"は適切ではないが、タグ "sl-nedis"と "sl-IT-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.
* Suppress-Scriptにはスクリプトサブタグが含まれていますが、これを使用して、関連付けられた一次言語サブタグを持つ言語タグを形成することはできません。このフィールドは、「Type」フィールドの値が「language」であるレコードにのみ出現する必要があります。セクション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:
「Preferred-Value」フィールドには、それが表示されるレコードと別のタグまたはサブタグとの間のマッピングが含まれています。このフィールドの値は、言語タグを選択するときにこのレコードの値を表すのに最適な選択肢として強く推奨されています。これらの値は3つのグループを形成します。
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. タグはRFC 3066から派生したものです。多くの場合、これらのタグが表す値は後で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のルールに従って、フィールドが「祖父」および「地域」タイプのレコードに追加される場合があります。それ以外の場合、フィールドはすでにレジストリにあるレコードに追加してはなりません（MUST NOT）。
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.
タイプ「バリアント」のレコードには、タイプ「プレフィックス」のフィールドが複数ある場合があります。このタイプの追加フィールドは、登録プロセスを介して「バリアント」レコードに追加される場合があります。
Records of type 'extlang' MUST have _exactly_ one 'Prefix' field.
タイプ「extlang」のレコードには、「正確に」1つの「接頭辞」フィールドが必要です。
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.
「プレフィックス」フィールドのフィールド値は、このサブタグでの使用に適切なサブタグの言語タグで構成されています。たとえば、バリアントサブタグ「1996」の「プレフィックス」フィールドは「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.
タイプ「接頭辞」のフィールドは、どのレコードからも削除してはなりません。このタイプのフィールドのフィールド値は変更してはなりません。
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".
「Suppress-Script」フィールドは、「Type」フィールド値が「language」であるレコードにのみ出現する必要があります。このフィールドは、レコード内に複数回出現してはなりません。このフィールドは、指定された言語の圧倒的多数のドキュメントを作成するために使用されるスクリプトを示します。したがって、言語タグに識別情報は追加されません。これは、このドキュメントのルールに従って生成された言語タグと、RFC 3066に基づいて言語タグおよびタグプロセッサまたはコンシューマとの間の互換性を確保するのに役立ちます。たとえば、事実上すべてのアイスランド語ドキュメントはラテン文字で記述され、サブタグ「Latn」タグ「is-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の裁量により削除または交換されます。 Language Subtag Reviewerは、ietf-languagesメーリングリストをモデレートし、登録の要求に応答し、セクション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決定と同じルールの下でIESGにアピールされる場合があります（[RFC2026]を参照）。 IESGは、Language Subtag Reviewerの決定を取り消したり、覆したり、ガイダンスを提供したり、その他の適切なアクションを実行したりできます。
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によってコードが割り当てまたは撤回されるため、Language Subtag Reviewerは各変更を評価し、既存のレジストリエントリと競合するかどうかを判断して、情報を送信する必要がありますレジストリに含めるためにIANAに。変更が行われ、Language Subtag Reviewerがこれを適時に行わない場合、関係者はセクション3.5の手順を使用して適切な更新を登録できます（MAY）。
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'のレコードは、タイプが 'redundant'に変換される場合があります。詳細については、セクション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タグは、祖父のタグのリストの一部であり、それらのコンポーネントサブタグは、登録されたバリアントとして含まれていませんでした（ただし、登録は引き続き可能です）。たとえば、タグ "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」という単語を含める必要があります。メッセージには、挿入または変更されるサブタグのレコードと新しいFile-Dateレコードの両方が含まれている必要があります。メッセージの本文に含まれる可能性があるものの例を次に示します。
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. %%
言語サブタグの変更File-Date：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.
レジストリでエントリが作成または変更されるたびに、レジストリの先頭にある「File-Date」レコードが更新され、[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. 「説明」フィールドの値は、既存のタグを無効にするような方法で変更してはなりません。それらは、範囲がいくらか拡大されるか、情報を追加するために変更されるか、または最も一般的な現代の使用法に適合される場合があります。たとえば、国によっては正式名称が変更される場合があります。これの歴史的な例は、「Upper Volta」から「Burkina Faso」への変更です。
3. Values in the field 'Prefix' MAY be added to records of type 'variant' via the registration process.
3. フィールド「プレフィックス」の値は、登録プロセスを介してタイプ「バリアント」のレコードに追加される場合があります。
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. フィールド「接頭辞」の値は、変更により接頭辞のセットが拡張される限り、変更できます。つまり、接頭辞はそれ自体の接頭辞の1つに置き換えられてもよい（MAY）。たとえば、接頭辞「en-US」は「en」に置き換えることができますが、接頭辞「en-Latn」、「fr」、または「en-US-boont」に置き換えることはできません。これらの接頭辞の1つが必要な場合は、新しい接頭辞を登録する必要があります（SHOULD）。
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. 「Suppress-Script」フィールドは、登録プロセスで追加または削除できます。
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 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.
9. ISO 639、ISO 15924、またはISO 3166によって割り当てられた、それぞれの保守または登録機関によって撤回されたコードは、言語タグで引き続き有効です。撤回の日付を含む「非推奨」フィールドがレコードに追加されます。置換値を表す同じタイプの新しいレコードが追加された場合、「優先値」フィールドも追加される場合があります。登録プロセスは、それぞれの規格によるコードの撤回に関するコメントを追加するために使用される場合があります。
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」は国「Timor-Leste」に割り当てられ、コード「TP」（ポルトガルの管理下にあったときに「East Timor」に割り当てられていました）を置き換えました。サブタグ「TP」は言語タグで引き続き有効ですが、そのレコードには「TL」の「優先値」が含まれ、そのフィールド「非推奨」には新しいコードが割り当てられた日付（「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 subtag will be at the discretion of the Language Subtag Reviewer and MUST conform to other restrictions on variant subtags in this document.
C. ISO 15924コードの場合、新しく割り当てられたコードの意味がIANAレジストリのサブタグで表されない場合、言語サブタグレビューアは、セクション3.5で説明されているように、実用的ですぐにIANAレジストリに入力するための提案を準備する必要があります。新しいコードの代替値として登録されたバリアントサブタグ。登録されたバリアントサブタグの形式は、Language Subtag Reviewerの裁量によるものであり、このドキュメントのバリアントサブタグに関する他の制限に準拠する必要があります。
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で説明されているように、言語サブタグレビューアは、 IANAレジストリのエントリとしての適切な国連M.49国コード。
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コードの場合、関連するUN数値コードがない場合、Language Subtag ReviewerはUNにそれを作成するよう申請する必要があります。リクエストが送信されてから90日以内に国連からの応答がない場合、言語サブタグレビューアは、登録されたバリアントサブタグが新しいコードの代替値として実用的になり次第、IANAレジストリに入力するための提案を作成するものとします（SHALL）。登録されたバリアントサブタグの形式は、Language Subtag Reviewerの裁量によるものであり、このドキュメントのバリアントサブタグに関する他の制限に準拠する必要があります。この状況が発生することはほとんどありません。
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. 国連M.49には、国と地域（ドイツの場合は「276」など）と地理的地域および小地域（ヨーロッパの場合は「150」など）の両方のコードがあります。既存のサブタグによる登録がブロックされているISO 3166コードの代理として使用する場合を除き、対応するISO 3166コードがないUN M.49国または地域コードは登録しないでください。そのようなコードが必要になった場合、ISO 3166の登録機関は、最初にコードを地域に割り当てるよう申請する必要があります。 ISO 3166によるコード割り当ての請願が拒否されるか、適時に実施されない場合、セクション3.5で説明されている登録プロセスを使用して、対応するUN M.49コードを登録できます。このドキュメントが作成された時点では、このようなコードは830（チャネル諸島）、831（ガーンジー）、832（ジャージー）、および833（マン島）の4つしかありませんでした。このようにして、UN M.49コードは、ISO 3166がレジストリで非推奨の値を再割り当てする場合の最後の手段の値として引き続き利用できます。
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. 安定性の規定は、この例外を除き、祖父のタグに適用されます。祖父のタグのすべてのサブタグがIANAレジストリの有効なサブタグになると、そのレコードのフィールド「タイプ」が「祖父」から「冗長」に変更されます。これらのタグは有効な生成サブタグシーケンスと一致するため、これは祖父と一致する言語タグには影響しません。たとえば、言語タグ「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.
タイプ「language」および「variant」のサブタグのみが、新しいサブタグの独立した登録で考慮されます。このドキュメントで定義されている制限内でISO 639、ISO 15924、ISO 3166、およびUN M.49とレジストリを同期させるために必要な、安定性に必要なサブタグとサブタグの処理については、セクション3.3で説明します。安定性規定はセクション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.
新しいサブタグを登録するか、既存のタグまたはサブタグの変更を要求するには、要求者が以下に再現された登録フォームに記入するところから始まります。リクエストが登録を適切に説明できるように、各レスポンスのサイズは制限されていないことに注意してください。 「Record Requested」セクションのフィールドは、セクション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>.)
IANAに提出する前に、サブタグ登録フォームを2週間の審査期間のために<ietf-languages@iana.org>に送信する必要があります。 （これはオープンリストであり、<ietf-languages-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.
バリアントサブタグは通常、特定の範囲の言語タグで使用するために登録されます。たとえば、Resianはスロベニア語の方言であるため、サブタグ「rozaj」は、1次言語サブタグ「sl」で始まる言語タグでの使用を目的としています。したがって、サブタグ「rozaj」は、「sl-Latn-rozaj」や「sl-IT-rozaj」などのタグで適切です。この情報は、レジストリの「プレフィックス」フィールドに格納されています。バリアント登録リクエストでは、登録フォームに少なくとも1つの「プレフィックス」フィールドを含める必要があります。
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.
拡張言語サブタグは、将来の標準化のために予約されています。これらのサブタグには、登録が許可されると、「プレフィックス」フィールドを1つだけ含める必要があります。
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レジストリに存在します。追加のプレフィックスは、追加の登録フォームを提出することによって追加される場合があります。その形式では、「その他の関連情報：」フィールドは、それがプレフィックスの追加であることを示さなければなりません（MUST）。
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.
「説明」フィールドには、ラテン文字に記述または転記されて登録されているタグの説明を含める必要があります。ラテン語以外のスクリプトに説明を含めることもできます（MAY）。非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.
2週間の期間が経過すると、Language Subtag Reviewerは、セクション3.3で説明されている手順に従って挿入または変更するレコードをiana@iana.orgに転送するか、リストで発生した重大な異論またはこのドキュメントの制約の問題のため（明示的に引用する必要があります）。 Language Subtag Reviewerは、さらに議論できるように、レビュー期間を2週間単位で延長してもよい（MAY）。言語サブタグレビューアは、2週間ごとに登録が承認されたか、拒否されたか、延長されたかをリストに示す必要があります。
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.
申請者は、拒否された申請を追加情報で自由に修正し、再度提出することができます。これにより、2週間のコメント期間が再開されます。
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".
承認されたすべての登録フォームは、「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.
既存のレコードの更新または変更は、新規登録と同じ手順に従います。言語サブタグレビューアは、2週間のレビュー期間の後に登録を更新するコンセンサスがあるかどうかを決定します。通常、最初の登録者による異議は、そのようなコンセンサスを形成する上で余分な重みを伴います。
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で言語を登録する必要があります。ISO639-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」サブタグ（スロベニア語のレジアン方言）です。
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.
注：4文字の主要言語サブタグは、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、AT-1120 Wien、Austria電話：+43 1 26 75 35 Ext。 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
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
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
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
Statistical Services Branch Statistics Division United Nations、Room DC2-1620 New York、NY 10017、USA
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」以外の1文字のサブタグ（「シングルトン」）によって導入されるものです。これらは、言語コンポーネントを含み、言語タグを理解するアプリケーションと互換性のある識別子の生成のために予約されています。
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, 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:
1文字のサブタグは、[RFC2434]で定義されている「IETFコンセンサス」ポリシーを使用してIANAによって割り当てられます。このポリシーでは、RFCの開発が必要です。RFCは、サブタグを維持するための名前、目的、プロセス、および手順を定義する必要があります（SHALL）。名前、連絡先電子メール、ディスカッションリスト電子メール、およびレジストリのURLの場所を含む、維持または登録機関は、RFCに明確に示されている必要があります。 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 IANAには、仕様の連絡先情報とURLの変更を通知する必要があります。
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は、割り当てられた単一文字（シングルトン）サブタグのレジストリを維持します。このレジストリは、セクション3.1のABNFで説明されているrecord-jar形式を使用する必要があります。 RFCとして拡張機能を公開すると、RFCで定義されている維持管理機関は、この登録フォームをiesg@ietf.orgに転送する必要があります。iesg@ ietf.orgは、リクエストをiana@iana.orgに転送する必要があります。拡張機能の維持管理権限は、内容が変更されるたびに、件名に「LANGUAGE TAG EXTENSION UPDATE」という件名のレコードを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：機関：Contact_Email：Mailing_List：URL：%%
Figure 6: Format of Records in the Language Tag Extensions Registry
図6：言語タグ拡張レジストリのレコードの形式
'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.
「識別子」には、拡張機能に割り当てられた1文字のサブタグ（シングルトン）が含まれています。拡張子を定義するために提出されたInternet-Draftは、使用する文字または数字を指定する必要があります（SHOULD）。ただし、IESGは、RFCを承認するときに割り当てを変更できます（MAY）。
'Description' contains the name and description of the extension.
「説明」には、拡張機能の名前と説明が含まれます。
'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.
'Added'には、RFCが発行された日付が[RFC3339]で指定されている「完全な日付」形式で含まれています。例：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.
'Authority'には、拡張の維持権限の名前が含まれています。
'Contact_Email' contains the email address used to contact the maintaining authority.
「Contact_Email」には、維持管理機関への連絡に使用されるメールアドレスが含まれます。
'Mailing_List' contains the URL or subscription email address of the mailing list used by the maintaining authority.
'Mailing_List'には、維持管理機関が使用するメーリングリストの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.
このドキュメントの採用時には、言語タグで最初に有効なさまざまなサブタグを含む言語サブタグレジストリの初期バージョンが必要です。このサブタグのコレクションは、それを作成するために使用されたプロセスの説明とともに、[RFC4645]によって説明されています。 IANAは、[RFC4645]の内容から、このドキュメントで説明されているレジストリの初期バージョンを公開するものとします（SHALL）。 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が言語サブタグレビューアーを正式に任命するまで、既存の言語タグレビューアーは言語サブタグレビューアーとして機能するものとします（SHALL）。
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で説明されている言語タグ拡張レジストリの初期バージョンも必要です。言語タグ拡張レジストリは、将来の割り当て用のプレースホルダーとして「File-Date」タイプの単一フィールドを含む単一レコードで初期化される必要があります。
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.
サブタグは、有用な識別情報を追加する場合にのみ使用してください。無関係なサブタグは、言語タグの意味、理解、および処理を妨げます。特に、ユーザーと実装は、レジストリの「Prefix」フィールドと「Suppress-Script」フィールドに従う必要があります（セクション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」というラベルの付いたコンテンツはリクエストと一致しません。したがって、スクリプトサブタグが通常使用される時期と、使用されるべきでない時期を知ることが重要です。レジストリのSuppress-Scriptフィールドは、ユーザーが特定のスクリプトサブタグを含めない場合を定義することにより、このドキュメントのルールに従って生成された言語タグと、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. スクリプトがタグに識別情報を追加しない限り、スクリプトサブタグは言語タグの形成に使用すべきではありません（SHOULD NOT）。レジストリの主要言語レコードの「Suppress-Script」フィールドは、ほとんどのアプリケーションで識別情報を追加しないスクリプトサブタグを示します。
* 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'.
* たとえば、ヘブライ語には「iw」よりも「he」を使用します。
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. HTTPのContent-Languageヘッダーの場合のように、プロトコルが複数の言語の個別のタグを許可する場合は常に、 'mul'（複数）の主要言語サブタグを使用しないでください。 'mul'サブタグはほとんど有用な情報を伝えません。複数の言語のコンテンツは、出現する言語に個別にタグを付けるか、または 'mul'サブタグよりも実際の言語を優先して示す必要があります。
6. The same variant subtag SHOULD NOT be used more than once within a language tag.
6. 同じバリアントサブタグは、言語タグ内で複数回使用してはなりません（SHOULD NOT）。
* 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 understanding of the document. Example: MIME multipart/ alternative.
o代替手段を提供することを目的とする情報オブジェクトの場合、関連する言語タグは、コンテンツが複数の言語で提供され、その言語を見つけるために代替手段のそれぞれを検査する必要があるというヒントと見なすことができます。この場合、複数のタグの存在は、ドキュメントを完全に理解するために多言語である必要があることを意味しない場合があります。例：MIMEマルチパート/代替。
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などのマークアップ言語では、マークアップ構造で識別されるドキュメントの各部分（ドキュメント全体を含む）に言語情報を追加できます。たとえば、ノルウェーのドキュメント内に<span lang = "fr"> C'est la vie。</ span>と書くことができます。ノルウェー語を話すユーザーは、フランス語とノルウェー語の辞書にアクセスして、マークされたセクションの意味を知ることができます。ユーザーが音声合成インターフェースを介してそのドキュメントを聞いている場合、このフォーメーションを使用して、不適切なノルウェーのルールを適用する代わりに、シンセサイザにそのテキストのスパンにフランス語のテキスト音声変換ルールを適切に適用するように通知できます。
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」（キリル文字を使用して書かれたアゼルバイジャン）の両方と接頭辞を共有します。テキストが同じであっても、1つのスクリプトに堪能な人は他のスクリプトを読むことができない場合があります。 「az」のタグが付けられたコンテンツは、おそらく1つのスクリプトで記述されているため、他のスクリプトに詳しい読者にはわかりにくいかもしれません。
[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は特定のサブタグのセマンティクスを定義していますが、ほとんどの言語タグは合計で最大6文字の言語と地域のサブタグで構成されていましたが、より大きな登録済みタグも可能であっただけでなく実際に登録されました。
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.
一部のアプリケーションとプロトコルは、固定バッファサイズを割り当てるか、言語タグの長さを制限する必要があります。適合実装または仕様は、指定された長さを超える言語タグの格納をサポートすることを拒否してもよい（MAY）。そのような制限は明確に文書化されるべきであり、そのような文書はより長いタグに何が起こるか（例えば、エラー値が生成されるか、言語タグが切り捨てられるか）を含むべきです（SHOULD）。タグが任意の制限で切り捨てられることを許可するプロトコルで、その制限が何であるかを示すものではありませんが、タグの意味を大幅に変更することにより害を及ぼす可能性があります。
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.
スペースに制約があるが固定の制限がないプロトコルまたは仕様の実装では、切り捨てよりも可能な限り長いタグを使用する必要があります（SHOULD）。
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文字の言語タグを許可する必要があります（SHOULD）。
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)
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).
言語タグの切り捨てはタグの意味を変更するため、回避する必要があります。ただし、バッファサイズが限られているため、言語タグの切り捨てが必要になる場合があります。そのような切り捨ては、サブタグが途中で切り落とされたり、無効なタグ（たとえば、「-」文字で終わるタグ）が形成されることを許可してはなりません（MUST NOT）。
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:
これは、タグを切り捨てるアプリケーションまたはプロトコルは、タグが指定されたバッファに対して十分に短くなるまで、言語タグの右側からサブタグとその前の「-」を徐々に削除することによってそうしなければならないことを意味します。結果のタグが1文字のサブタグで終わる場合、そのサブタグとその前の「-」も削除する必要があります。例えば：
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 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
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.
特定の言語タグが多くのプロセスで使用されることがあるので、言語タグは常に標準形式で作成または生成する必要があります（SHOULD）。
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レジストリー（セクション3.1を参照）に優先値マッピングがあるタイプ「Region」のサブタグは、マップされた値で置き換える必要があります（SHOULD）。注：まれに、マップされた値にも優先値が含まれる場合があります。
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」などの言語と言語の組み合わせにマップされる可能性があります）。
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.
言語タグの正規化を実行する場合、プロセッサは、レジストリで使用されている大文字小文字の区別に従って、サブタグの大文字と小文字を正規化することができます（つまり、このプロセスはオプションです）。これは次の大文字と小文字の規則に対応していることに注意してください。先頭以外の2文字のサブタグはすべて大文字にします。先頭以外のすべての4文字のサブタグにタイトルケースを付ける。他のすべてを小文字にします。
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」を大文字にすると、予期された「IN」の代わりにシーケンスU + 0130 U + 004Eが生成されます。
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.
注：「非推奨」フィールドが「優先値」フィールドを伴わずにレジストリレコードに表示される場合、そのタグまたはサブタグは非推奨となり、代わりのものはありません。検証プロセッサは、これらの値を含むタグを生成してはなりません（SHOULD NOT）。ただし、値は言語タグに表示されるときは標準的なものです。
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.
拡張機能は、拡張機能のさまざまなサブタグ間に存在する関係を定義する必要があります。したがって、拡張機能のサブタグの代替正規化スキームを定義できます（MAY）。拡張機能は、拡張機能のサブタグの順序がどのように解釈されるかを定義する場合があります。たとえば、拡張機能は、サブタグがASCII順に配置されている場合、サブタグが正規の順序であることを定義できます。つまり、「en-a-ccc-bbb-aaa」ではなく「en-a-aaa-bbb-ccc」です。 。別の拡張では、サブタグの順序がそれらの意味論的意味に影響を与えることを定義する場合があります（そのため、「en-b-ccc-bbb-aaa」は「en-b-aaa-bbb-ccc」とは異なる値になります）。ただし、拡張仕様は、セクション3.7で説明されている一般的なプロセスを許容できるように設計する必要があります（SHOULD）。
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].
このセクションでは、このドキュメントで定義されている[RFC2434]の要件に従って、IANAがサブタグと拡張レジストリを維持するために必要なプロセスと要件について説明します。
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.
このドキュメントで定義されている2つのレジストリの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>の[Language Tags]の下に新しいレジストリをリストし、[RFC3066]で定義されている既存の登録を置き換える必要があります。既存の登録フォームとRFC 3066登録のセットは、「Language Tags（Obsolete）」として再ラベル付けされ、維持されなければなりません（ただし、追加または変更されません）。
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.
各レコードは、囲まれたレコードが新しいレコードの挿入（件名の「INSERT」という単語で示される）であるか、既存のレコードの置換（次で示される）であるかを示す件名行とともにiana@iana.orgに送信する必要があります。件名の「MODIFY」という単語）。レコードをレジストリから削除してはいけません。 IANAは、挿入または変更されたレコードを言語サブタグレジストリの適切なセクションに配置し、「タイプ」フィールドでレコードをグループ化する必要があります。挿入されたレコードは、適切なセクションの任意の場所に配置できます。 「タイプ」でグループ化する以外に、レコードの順序は保証されません。変更されたレコードは、置き換えるレコードを上書きする必要があります。
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.
レコードを挿入または変更するリクエストには、新しいFile-Dateレコードを含める必要があります。このレコードは、レジストリの最初に配置する必要があります。レジストリに存在するFile-Dateレコードの日付が、挿入または変更されているレコードよりも遅い場合、既存のレコードを保持する必要があります。
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による言語タグ拡張レジストリに関する今後の作業は、2つのケースに限定されています。まず、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.
特定の情報項目に関連付けられた言語タグは、そのコンテンツに同形異義語が含まれる可能性があるかどうかを判断するうえで、何の影響もありません。テキストが1つの言語である、または特定のスクリプトサブタグを使用してタグ付けされているという事実は、その言語タグに関連付けられた、または指定されたスクリプト以外のスクリプトの文字が含まれていないことを保証しません。
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を参照）はインターネット経由で利用可能でなければなりませんが、サービス拒否攻撃を防ぐために、実装は常にアクセス可能であることを機械的に依存してはなりません（SHOULD NOT）。
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、HYPHEN-MINUSの文字のみを使用する必要があるため、ほとんどの文字セットに存在するため、言語タグの構成に文字セットの問題はありません。
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言語と国コードの生成的な使用と同様に、これにより、登録プロセスに頼ることなく組み合わせを生成できます。国連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.
言語タグ全体からサブタグへのレジストリのリキャストは、これの重要な部分です。 RFC 3066の重要な機能は、サブタグの生成的な使用を許可することでした。これにより、タグ全体の登録を遅らせたり、有用なすべての組み合わせを登録したりする必要なく、生成されたタグを有意義に使用できます。
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レジストリ内の有効なサブタグの完全なリストを提供する言語サブタグレジストリに置き換えます。これにより、堅牢な実装と容易なメンテナンスが可能になります。言語サブタグレジストリは、言語タグを形成するための標準的なソースになります。
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 拡張言語サブタグを定義します。ISO639-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。情報技術-Universal Multiple-Octet Coded Character Set（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：Alpha-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：Alpha-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、「RFCで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]カーペンター、B。、ベイカー、F。、およびM.ロバーツ、「Internet Assigned Numbers Authorityの技術的作業に関する了解覚書」、RFC 2860、2000年6月。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339]クライン、G、エド。 C.ニューマン、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、2002年7月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D。、エド。および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]統計局、国連、「統計使用のための標準国または地域コード」、統計使用のためのUN標準国または地域コード、リビジョン4（国連出版、販売番号98.XVII.9、1999年6月。
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC1766] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、1995年3月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーアK。、「MIME（多目的インターネットメール拡張）パート3：非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 2231、1997年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。、編、「Initial Language Subtag Registry」、RFC 4645、2006年9月。
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
[RFC4647]フィリップス、A。、エド。 M.デイビス編、「言語タグのマッチング」、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 Consortium、「The Unicode Standard、Version 5.0」、ボストン、マサチューセッツ、Addison-Wesley、2007。ISBN0-321- 48091-0。
[XML10] Bray (et al), T., "Extensible Markup Language (XML) 1.0", 02 2004.
[XML10] Bray（et al）、T。、「Extensible Markup Language（XML）1.0」、02 2004。
[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 Schema Part 2：Datatypes Second Edition"、10 2004、<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/standards/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。、「The Art of Unix Programming」、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:
以下の人々（アルファベット順）がこのドキュメントまたはRFC 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.
Glenn Adams、Harald Tveit Alvestrand、Tim Berners-Lee、Marc Blanchet、Nathaniel Borenstein、Karen Broome、Eric Brunner、Sean M. Burke、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.
RFC 1766および3066を作成したHarald Tveit Alvestrand氏には非常に特別な感謝を捧げなければなりません。 RFC 1766の発行以来ほぼ完全な期間にわたって言語タグレビュー担当者を務めてきたMichael Eversonに特別な感謝を捧げる必要があります。DougEwellが最初の完全なサブタグレジストリの作成とテストの作成に尽力してくれたことに感謝します。言語タグを検証するためのパーサー。
Appendix B. Examples of Language Tags (Informative)
付録B.言語タグの例（参考）
Simple language subtag:
単純な言語サブタグ：
de (German)
で （げｒまん）
fr (French)
fr（フランス語）
ja (Japanese)
と（日本語）
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)
sr-Latn（ラテン文字を使用して記述されたセルビア語）
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（スロベニア語のロシア語方言
sl-nedis (Nadiza dialect of Slovenian)
sl-nedis（スロベニア語のNadiza方言）
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（イタリアで使用されているラテン文字を使用して記述されたスロベニア語のNadiza方言。サブタグ「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
でーＣＨーｘーｐほねｂｋ
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
g-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)
sr-Latn-QM（セルビア語、ラテン文字、プライベートリージョン）
sr-Qaaa-CS (Serbian, private script, for Serbia and Montenegro)
sr-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 en-a-myExt-b-another
zh-CN-a-myExt-x-private en-a-myExt-b-another
Some Invalid Tags:
いくつかの無効なタグ：
de-419-DE (two region tags)
de-419-DE（2つの領域タグ）
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（プライマリ位置での1文字のサブタグの使用。有効な「i-」で始まる祖父のタグがいくつかあることに注意してください）
ar-a-aaa-b-bbb-a-ccc (two extensions with same single-letter prefix)
ar-a-aaa-b-bbb-a-ccc（1文字のプレフィックスが同じ2つの拡張子）
Authors' Addresses
著者のアドレス
Addison Phillips (Editor) Yahoo! Inc.
Addison Phillips（編集者）Yahoo!株式会社
EMail: addison@inter-locale.com
Mark Davis (Editor) Google
Mark Davis（編集者）Google
EMail: mark.davis@macchiato.com or mark.davis@google.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（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事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンライン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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許申請、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。