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)。



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
1. Introduction
1. はじめに

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.


In addition, knowledge about the particular language used by some piece of information content might be useful or even required by some types of processing; for example, spell-checking, computer-synthesized speech, Braille transcription, or high-quality print renderings.


One means of indicating the language used is by labeling the information content with an identifier or "tag". These tags can be used to specify user preferences when selecting information content, or for labeling additional attributes of content and associated resources.


Tags can also be used to indicate additional language attributes of content. For example, indicating specific information about the dialect, writing system, or orthography used in a document or resource may enable the user to obtain information in a form that they can understand, or it can be important in processing or rendering the given content into an appropriate form or style.


This document specifies a particular identifier mechanism (the language tag) and a registration function for values to be used to form tags. It also defines a mechanism for private use values and future extension.


This document, in combination with [RFC4647], replaces [RFC3066], which replaced [RFC1766]. For a list of changes in this document, see Section 8.


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]で説明されているように解釈されます。

2. The Language Tag
2. 言語タグ

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.


2.1. Syntax
2.1. 構文

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


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.


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.


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.


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.2. Language Subtag Sources and Interpretation
2.2. 言語サブタグのソースと解釈

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.


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.


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.


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.


2.2.1. Primary Language Subtag
2.2.1. 第一言語サブタグ

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. 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」などのタグが有効になります。

2.2.2. Extended Language Subtags
2.2.2. 拡張言語サブタグ

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.


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」が中国語を表す場合があります方言「ガン」。

2.2.3. Script Subtag
2.2.3. スクリプトサブタグ

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.


2.2.4. Region Subtag
2.2.4. 地域サブタグ

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.


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').


"sr-Latn-CS" represents Serbian ('sr') written using Latin script ('Latn') as used in Serbia and Montenegro ('CS').


"es-419" represents Spanish ('es') appropriate to the UN-defined Latin America and Caribbean region ('419').


2.2.5. Variant Subtags
2.2.5. バリアントサブタグ

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.


"de-CH-1996" represents German as used in Switzerland and as written using the spelling reform beginning in the year 1996 C.E.


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」を含める必要があります。

2.2.6. Extension Subtags
2.2.6. 拡張サブタグ

Extensions provide a mechanism for extending language tags for use in various applications. See Section 3.7. The following rules apply to extensions:


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"。

2.2.7. Private Use Subtags
2.2.7. 私的使用のサブタグ

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」です。

2.2.8. Preexisting RFC 3066 Registrations
2.2.8. 既存のRFC 3066登録

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に基づいて登録されている可能性があることに注意することが重要です。

2.2.9. Classes of Conformance
2.2.9. 適合クラス

Implementations sometimes need to describe their capabilities with regard to the rules and practices described in this document. There are two classes of conforming implementations described by this document: "well-formed" processors and "validating" processors. Claims of conformance SHOULD explicitly reference one of these definitions.


An implementation that claims to check for well-formed language tags MUST:


o Check that the tag and all of its subtags, including extension and private use subtags, conform to the ABNF or that the tag is on the list of grandfathered tags.

o タグとそのすべてのサブタグ(拡張サブタグや私用サブタグを含む)がABNFに準拠していること、またはタグが祖父のタグのリストにあることを確認してください。

o Check that singleton subtags that identify extensions do not repeat. For example, the tag "en-a-xx-b-yy-a-zz" is not well-formed.

o 拡張機能を識別するシングルトンサブタグが繰り返されていないことを確認してください。たとえば、タグ "en-a-xx-b-yy-a-zz"は整形式ではありません。

Well-formed processors are strongly encouraged to implement the canonicalization rules contained in Section 4.4.


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」と一致します。

3. Registry Format and Maintenance
3. レジストリの形式とメンテナンス

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).


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レジストリでは定義されていません。)

3.1. Format of the IANA Language Subtag Registry
3.1. 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].


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


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 <>). 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 "&#x20AC;". Note that the hexadecimal notation MAY have between two and six digits.

US-ASCII [ISO646]レパートリー外からの文字、およびフィールド本体で発生するAMPERSAND文字( "&"、%x26)は、スタイルの16進表記を使用した "数値文字参照"で表されます。 [XML10]で使用されます(<>を参照)。これは、シーケンス "&#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.


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


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'


* 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:


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.


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.


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」で冗長です。

3.2. Language Subtag Reviewer
3.2. 言語サブタグレビューア

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の決定を取り消したり、覆したり、ガイダンスを提供したり、その他の適切なアクションを実行したりできます。

3.3. Maintenance of the Registry
3.3. レジストリのメンテナンス

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.


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.


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:


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


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.


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.


3.4. Stability of IANA Registry Entries
3.4. IANAレジストリエントリの安定性

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」は引き続き有効です)。

3.5. Registration Procedure for Subtags
3.5. サブタグの登録手順

The procedure given here MUST be used by anyone who wants to use a subtag not currently in the IANA Language Subtag Registry.


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:


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


The subtag registration form MUST be sent to <> 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 <>.)

IANAに提出する前に、サブタグ登録フォームを2週間の審査期間のために<>に送信する必要があります。 (これはオープンリストであり、<>にリクエストを送信することで参加できます。)

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.


Extended language subtags are reserved for future standardization. These subtags will be REQUIRED to include exactly one 'Prefix' field once they are allowed for registration.


The 'Prefix' field for a given registered subtag exists in the IANA registry as a guide to usage. Additional prefixes MAY be added by filing an additional registration form. In that form, the "Any other relevant information:" field MUST indicate that it is the addition of a prefix.


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" 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.


When the two-week period has passed, the Language Subtag Reviewer either forwards the record to be inserted or modified to 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.


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 under "languages".


Updates or changes to existing records follow the same procedure as new registrations. The Language Subtag Reviewer decides whether there is consensus to update the registration following the two-week review period; normally, objections by the original registrant will carry extra weight in forming such a consensus.


Registrations are permanent and stable. Once registered, subtags will not be removed from the registry and will remain a valid way in which to specify a specific language or variant.


Note: The purpose of the "Description" in the registration form is to aid people trying to verify whether a language is registered or what language or language variation a particular subtag refers to. In most cases, reference to an authoritative grammar or dictionary of that language will be useful; in cases where no such work exists, other well-known works describing that language or in that language MAY be appropriate. The Language Subtag Reviewer decides what constitutes "good enough" reference material. This requirement is not intended to exclude particular languages or dialects due to the size of the speaker population or lack of a standardized orthography. Minority languages will be considered equally on their own merits.


3.6. Possibilities for Registration
3.6. 登録の可能性

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.


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

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

The registration authority for ISO 15924 (script codes) is:

ISO 15924(スクリプトコード)の登録機関は次のとおりです。

   Unicode Consortium Box 391476
   Mountain View, CA 94039-1476, USA

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
3.7. Extensions and Extensions Registry
3.7. 拡張および拡張レジストリ

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.


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, who MUST forward the request to The maintaining authority of the extension MUST maintain the accuracy of the record by sending an updated full copy of the record to 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: %%


Figure 6: Format of Records in the Language Tag Extensions Registry


'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.


'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.


'RFC' contains the RFC number assigned to the extension.


'Authority' contains the name of the maintaining authority for the extension.


'Contact_Email' contains the email address used to contact the maintaining authority.


'Mailing_List' contains the URL or subscription email address of the mailing list used by the maintaining authority.


'URL' contains the URL of the registry for this extension.


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.


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.


3.8. Initialization of the Registries
3.8. レジストリの初期化

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.


4. Formation and Processing of Language Tags
4. 言語タグの形成と処理

This section addresses how to use the information in the registry with the tag syntax to choose, form, and process language tags.


4.1. Choice of Language Tag
4.1. 言語タグの選択

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.


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.


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.


4.2. Meaning of the Language Tag
4.2. 言語タグの意味

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 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".


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つのスクリプトで記述されているため、他のスクリプトに詳しい読者にはわかりにくいかもしれません。

4.3. Length Considerations
4.3. 長さに関する考慮事項

[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.


4.3.1. Working with Limited Buffer Sizes
4.3.1. 制限されたバッファサイズでの作業

Some applications and protocols are forced to allocate fixed buffer sizes or otherwise limit the length of a language tag. A conformant implementation or specification MAY refuse to support the storage of language tags that exceed a specified length. Any such limitation SHOULD be clearly documented, and such documentation SHOULD include what happens to longer tags (for example, whether an error value is generated or the language tag is truncated). A protocol that allows tags to be truncated at an arbitrary limit, without giving any indication of what that limit is, has the potential for causing harm by changing the meaning of tags in substantial ways.


In practice, most language tags do not require more than a few subtags and will not approach reasonably sized buffer limitations; see Section 4.1.


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.


The considerations for assigning a buffer limit are:


Implementations SHOULD NOT truncate language tags unless the meaning of the tag is purposefully being changed, or unless the tag does not fit into a limited buffer size specified by a protocol for storage or transmission.


Implementations SHOULD warn the user when a tag is truncated since truncation changes the semantic meaning of the tag.


Implementations of protocols or specifications that are space constrained but do not have a fixed limit SHOULD use the longest possible tag in preference to truncation.


Protocols or specifications that specify limited buffer sizes for language tags MUST allow for language tags of up to 33 characters.


Protocols or specifications that specify limited buffer sizes for language tags SHOULD allow for language tags of at least 42 characters.


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):


   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


4.3.2. Truncation of Language Tags
4.3.2. 言語タグの切り捨て

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:


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


4.4. Canonicalization of Language Tags
4.4. 言語タグの正規化

Since a particular language tag is sometimes used by many processes, language tags SHOULD always be created or generated in a canonical form.


A language tag is in canonical form when:


1. The tag is well-formed according the rules in Section 2.1 and Section 2.2.

1. タグは、セクション2.1およびセクション2.2のルールに従って整形式です。

2. Subtags of type 'Region' that have a Preferred-Value mapping in the IANA registry (see Section 3.1) SHOULD be replaced with their mapped value. Note: In rare cases, the mapped value will also have a Preferred-Value.

2. IANAレジストリー(セクション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.


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.


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.


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.


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)。

4.5. Considerations for Private Use Subtags
4.5. 私的使用のサブタグに関する考慮事項

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.


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.


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.


5. IANA Considerations
5. IANAに関する考慮事項

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].


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.


5.1. Language Subtag Registry
5.1. 言語サブタグレジストリ

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.


The new registry MUST be listed under "Language Tags" at <>, 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).

[>の[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.


Each record MUST be sent to 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.


5.2. Extensions Registry
5.2. 拡張レジストリ

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.


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は、提供された情報を検証する責任を負いません。適切にフォーマットされていることのみを保証します。レジストリに存在するレコードで指定された維持管理機関からのものであることが合理的にわかるはずです。

6. Security Considerations
6. セキュリティに関する考慮事項

Language tags used in content negotiation, like any other information exchanged on the Internet, might be a source of concern because they might be used to infer the nationality of the sender, and thus identify potential targets for surveillance.


This is a special case of the general problem that anything sent is visible to the receiving party and possibly to third parties as well. It is useful to be aware that such concerns can exist in some cases.


The evaluation of the exact magnitude of the threat, and any possible countermeasures, is left to each application protocol (see BCP 72 [RFC3552] for best current practice guidance on security threats and defenses).

脅威の正確な大きさの評価と可能な対策は、各アプリケーションプロトコルに任されています(セキュリティの脅威と防御に関する現在のベストプラクティスガイダンスについては、BCP 72 [RFC3552]を参照してください)。

The language tag associated with a particular information item is of no consequence whatsoever in determining whether that content might contain possible homographs. The fact that a text is tagged as being in one language or using a particular script subtag provides no assurance whatsoever that it does not contain characters from scripts other than the one(s) associated with or specified by that language tag.


Since there is no limit to the number of variant, private use, and extension subtags, and consequently no limit on the possible length of a tag, implementations need to guard against buffer overflow attacks. See Section 4.3 for details on language tag truncation, which can occur as a consequence of defenses against buffer overflow.


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)。

7. Character Set Considerations
7. 文字セットに関する考慮事項

The syntax in this document requires that language tags use only the characters A-Z, a-z, 0-9, and HYPHEN-MINUS, which are present in most character sets, so the composition of language tags should not have any character set issues.


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.


8. Changes from RFC 3066
8. RFC 3066からの変更点

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.


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の予想される特定の機能で使用する可能性があります。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[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.


9.2. Informative References
9.2. 参考引用

[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, <>.

[XMLSchema] Biron、P.、Ed。そしてA. Malhotra、Ed。、 "XML Schema Part 2:Datatypes Second Edition"、10 2004、<>。

[iso639.prin] ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory Committee: Working principles for ISO 639 maintenance", March 2000, < standards/iso639-2/iso639jac_n3r.html>.

[iso639.prin] ISO 639合同諮問委員会、「ISO 639合同諮問委員会:ISO 639維持のための作業原則」、2000年3月、<> 。

[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>。

Appendix A. Acknowledgements

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)


Simple language subtag:


de (German)

で (げrまん)

fr (French)


ja (Japanese)


i-enochian (example of a grandfathered tag)


Language subtag plus Script subtag:


zh-Hant (Chinese written using the Traditional Chinese script)


zh-Hans (Chinese written using the Simplified Chinese script)


sr-Cyrl (Serbian written using the Cyrillic script)


sr-Latn (Serbian written using the Latin script)




zh-Hans-CN (Chinese written using the Simplified script as used in mainland China)


sr-Latn-CS (Serbian written using the Latin script as used in Serbia and Montenegro)




sl-rozaj (Resian dialect of Slovenian


sl-nedis (Nadiza dialect of Slovenian)




de-CH-1901 (German as used in Switzerland using the 1901 variant [orthography])


sl-IT-nedis (Slovenian as used in Italy, Nadiza dialect)




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')




de-DE (German for Germany)

でーで (げrまん ふぉr げrまny)

en-US (English as used in the United States)


es-419 (Spanish appropriate for the Latin America and Caribbean region using the UN region code)


Private use subtags:






Extended language subtags (examples ONLY: extended languages MUST be defined by revision or update to this document):






Private use registry values:


x-whatever (private use using the singleton 'x')


qaa-Qaaa-QM-x-southern (all private tags)


de-Qaaa (German, with a private script)


sr-Latn-QM (Serbian, Latin-script, private region)


sr-Qaaa-CS (Serbian, private script, for Serbia and Montenegro)


Tags that use extensions (examples ONLY: extensions MUST be defined by revision or update to this document or by RFC):




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)


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)


ar-a-aaa-b-bbb-a-ccc (two extensions with same single-letter prefix)


Authors' Addresses


Addison Phillips (Editor) Yahoo! Inc.

Addison Phillips(編集者)Yahoo!株式会社


Mark Davis (Editor) Google

Mark Davis(編集者)Google

   EMail: or

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に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。



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


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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許申請、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。



Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).