Internet Engineering Task Force (IETF) M. Davis
Request for Comments: 6497 Google
Category: Informational A. Phillips
ISSN: 2070-1721 Lab126
Y. Umaoka
IBM
C. Falk
Infinite Automata
February 2012
Extension T - Transformed Content
Abstract
抽象
This document specifies an Extension to BCP 47 that provides subtags for specifying the source language or script of transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source. It also provides for additional information used for identification.
この文書は、訳さ転写、または翻訳、またはソースの影響を受けて他のいくつかの方法でされているコンテンツを含む変換コンテンツのソース言語やスクリプトを指定するためのサブタグを提供BCP 47への拡張を指定します。また、識別のために使用される追加の情報を提供します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6497.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6497で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. BCP 47 Required Information .....................................4
2.1. Overview ...................................................4
2.2. Structure ..................................................6
2.3. Canonicalization ...........................................7
2.4. BCP 47 Registration Form ...................................8
2.5. Field Definitions ..........................................8
2.6. Registration of Field Subtags .............................10
2.7. Registration of Additional Fields .........................11
2.8. Committee Responses to Registration Proposals .............11
2.9. Machine-Readable Data .....................................11
3. Acknowledgements ...............................................14
4. IANA Considerations ............................................14
5. Security Considerations ........................................14
6. References .....................................................14
6.1. Normative References ......................................14
6.2. Informative References ....................................15
[BCP47] permits the definition and registration of language tag extensions "that contain a language component and are compatible with applications that understand language tags". This document defines an extension for specifying the source of content that has been transformed, including text that has been transliterated, transcribed, or translated, or in some other way influenced by the source. It may be used in queries to request content that has been transformed. The "singleton" identifier for this extension is 't'.
[BCP47]「言語の成分を含有し、言語タグを理解するアプリケーションとの互換性のある」言語タグ拡張の定義と登録が可能になります。この文書は、音訳転写、または翻訳、またはソースによって影響を受ける他の何らかの方法でされたテキストを含む、形質転換されたコンテンツのソースを指定するための拡張を定義します。変換されたコンテンツを要求するクエリで使用することができます。この拡張のための「シングルトン」識別子は、「T」です。
Language tags, as defined by [BCP47], are useful for identifying the language of content. There are mechanisms for specifying variant subtags for special purposes. However, these variants are insufficient for specifying content that has undergone transformations, including content that has been transliterated, transcribed, or translated. The correct interpretation of the content may depend upon knowledge of the conventions used for the transformation.
言語タグは、[BCP47]によって定義されるように、コンテンツの言語を同定するために有用です。特別な目的のために、変異体サブタグを指定するためのメカニズムがあります。しかしながら、これらの変異体は、音訳転写、または翻訳されたコンテンツを含む、変換を施されたコンテンツを特定するためには不十分です。コンテンツの正しい解釈は、形質転換のために使用される規則の知識に依存し得ます。
Suppose that Italian or Russian cities on a map are transcribed for Japanese users. Each name needs to be transliterated into katakana using rules appropriate for the specific source and target language. When tagging such data, it is important to be able to indicate not only the resulting content language ("ja" in this case), but also the source language.
マップ上のイタリアやロシアの都市は、日本のユーザーのために転写されていると仮定します。それぞれの名前は特定のソースおよびターゲット言語のための適切なルールを使ってカタカナに音訳する必要があります。このようなデータをタグ付けする場合は、得られたコンテンツの言語（この場合は「JA」）だけでなく、ソース言語だけでなく示すことができることが重要です。
Transforms such as transliterations may vary, depending not only on the basis of the source and target script, but also on the source and target language. Thus, the Russian <U+041F U+0443 U+0442 U+0438 U+043D> (which corresponds to the Cyrillic <PE, U, TE, I, EN>) transliterates into "Putin" in English but "Poutine" in French. The identifier could be used to indicate a desired mechanical transformation in an API, or could be used to tag data that has been converted (mechanically or by hand) according to a transliteration method.
音訳は、ソースとターゲットスクリプトに基づいてだけでなく、ソースおよびターゲット言語だけでなくによって、変えることができるように変換します。このように、ロシアの<U + 041F U + 0443 U + 0442 U + 0438 U + 043D>（キリル<PE、U、TE、I、EN>に対応）英語で "プーチン" ではなく "プーティン" にtransliteratesフランス語で。識別子は、APIに所望の機械的変換を示すために使用することができ、又は音訳法に従って（機械的にまたは手動で）変換されたデータをタグ付けするために使用することができます。
In addition, many different conventions have arisen for how to transform text, even between the same languages and scripts. For example, "Gaddafi" is commonly transliterated from Arabic to English as any of (G/Q/K/Kh)a(d/dh/dd/dhdh/th/zz)af(i/y). Some examples of standardized conventions used for transcribing or transliterating text include:
また、多くの異なる規則が同じであっても言語やスクリプトの間で、テキストを変換する方法が望まれています。例えば、 "カダフィ" 一般（G / Q / K /のKh）（D / DH / DD / dhdh /目/ ZZ）AF（I / Y）のいずれかと、アラビア語から英語への音訳されています。転写またはテキストを翻字するために使用される標準化規則のいくつかの例は次のとおりです。
a. United Nations Group of Experts on Geographical Names (UNGEGN)
A。地理学的名称に関する国連専門家グループ（UNGEGN）
b. US Library of Congress (LOC)
B。米国議会図書館（LOC）
c. US Board on Geographic Names (BGN)
C。地名の米国委員会（BGN）
d. Korean Ministry of Culture, Sports and Tourism (MCST)
D。文化体育観光部、韓国省（MCST）
e. International Organization for Standardization (ISO)
電子。国際標準化機構（ISO）
The usage of this extension is not limited to formal transformations, and may include other instances where the content is in some other way influenced by the source. For example, this extension could be used to designate a request for a speech recognizer that is tailored specifically for second-language speakers who are first-language speakers of a particular language (e.g., a recognizer for "English spoken with a Chinese accent").
この拡張機能の使用は、正式な変換に限られるものではなく、コンテンツソースによって影響を受ける他の方法である他のインスタンスを含むことができます。たとえば、この拡張機能は、特定の言語（例えば、「中国のアクセントで話される英語」のための認識装置）の最初の言語のスピーカーです第二言語話者のために特別に調整された音声認識のための要求を指定するために使用することができ。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Identification of transformed content can be done using the 't' extension defined in this document. This extension is formed by the 't' singleton followed by a sequence of subtags that would form a language tag as defined by [BCP47]. This allows the source language or script to be specified to the degree of precision required. There are restrictions on the sequence of subtags. They MUST form a regular, valid, canonical language tag, and MUST neither include extensions nor private use sequences introduced by the singleton 'x'. Where only the script is relevant (such as identifying a script-script transliteration), then 'und' is used for the primary language subtag.
形質転換されたコンテンツの識別は、この文書で定義された「T」の拡張子を使用して行うことができます。この拡張は、[BCP47]によって定義される言語タグを形成することになるサブタグのシーケンスが続く「T」シングルトンによって形成されます。これは、ソース言語またはスクリプトが要求される精度の程度を指定することを可能にします。サブタグの順序には制限があります。彼らは定期的に、有効な、正規の言語タグを形成しなければならない、と伸長もシングルトンの「x」により導入された私的使用の配列を含んではならない、どちらも。のみスクリプトが（そのようなスクリプトのスクリプト音訳を識別するように）関連している場合、次いで「ウント」が第一言語サブタグのために使用されます。
For example:
例えば：
+---------------------+---------------------------------------------+
| Language Tag | Description |
+---------------------+---------------------------------------------+
| ja-t-it | The content is Japanese, transformed from |
| | Italian. |
| ja-Kana-t-it | The content is Japanese Katakana, |
| | transformed from Italian. |
| und-Latn-t-und-cyrl | The content is in the Latin script, |
| | transformed from the Cyrillic script. |
+---------------------+---------------------------------------------+
Note that the sequence of subtags governed by 't' cannot contain a singleton (a single-character subtag), because that would start a new extension. For example, the tag "ja-t-i-ami" does not indicate that the source is in "i-ami", because "i-ami" is not a regular language tag in [BCP47]. That tag would express an empty 't' extension followed by an 'i' extension.
それは新しい拡張を開始するため、「T」に支配サブタグの順序は、シングルトン（単一文字のサブタグ）を含めることはできません。 「私は、AMI」は[BCP47]で正規言語タグがないため、例えば、タグ「JA-T-I-AMI」は、ソースが「I-AMI」であることを示すものではありません。そのタグは、「I」伸長が続く空の「T」の拡張子を発現するであろう。
The 't' extension is not intended for use in structured data that already provides separate source and target language identifiers. For example, this is the case in localization interchange formats such as XLIFF. In such cases, it would be inappropriate to use "ja-t-it" for the target language tag because the source language tag "it" would already be present in the data. Instead, one would use the language tag "ja".
「T」拡張子は、すでに別のソースとターゲット言語の識別子を提供して構造化データでの使用のために意図されていません。例えば、これは、XLIFFとして定位交換フォーマットの場合です。このような場合には、「JA-tは、それが」目標言語タグのソース言語タグが「それ」が既にデータ中に存在することになるので、使用することは不適切であろう。代わりに、一つは言語タグ「JA」を使用します。
As noted earlier, it is sometimes necessary to indicate additional information about a transformation. This additional information is optionally supplied after the source in a series of one or more fields, where each field consists of a field separator subtag followed by one or more non-separator subtags. Each field separator subtag consists of a single letter followed by a single digit.
先に述べたように、変換に関する追加情報を示すために時々必要です。この追加情報は、必要に応じて、各フィールドは、1つまたは複数の非セパレータサブタグ続くフィールドセパレータサブタグから成る1つ以上のフィールド、一連のソースの後に供給されます。各フィールドセパレータサブタグは、単一の数字に続く単一文字から成ります。
A transformation mechanism is an optional field that indicates the specification used for the transformation, such as "UNGEGN" for the United Nations Group of Experts on Geographical Names transliterations and transcriptions. It uses the 'm0' field separator followed by certain subtags.
変換機構は、このような地名音訳や編曲に関する専門家、国連グループの「UNGEGN」として、形質転換のために使用される仕様を示すオプションのフィールドです。これは、特定のサブタグが続く「M0」フィールド区切り文字を使用しています。
For example:
例えば：
+------------------------------------+------------------------------+
| Language Tag | Description |
+------------------------------------+------------------------------+
| und-Cyrl-t-und-latn-m0-ungegn-2007 | The content is in Cyrillic, |
| | transformed from Latin, |
| | according to a UNGEGN |
| | specification dated 2007. |
+------------------------------------+------------------------------+
The field separator subtags, such as 'm0', were chosen because they are short, visually distinctive, and cannot occur in a language subtag (outside of an extension and after 'x'), thus eliminating the potential for collision or confusion with the source language tag.
このような「M0」としてフィールドセパレータサブタグは、それらが短いので、視覚的に特徴的な、選択された、従って、衝突や混乱の可能性を排除し、（拡張の外側及び「X」の後）言語サブタグで発生することができませんソース言語タグ。
The field subtags are defined by Section 3 of Unicode Technical Standard #35: Unicode Locale Data Markup Language (LDML) [UTS35], the main specification for the Unicode Common Locale Data Repository (CLDR) project. That section also defines the parallel 'u' extension [RFC6067], for which the Unicode Consortium is also the maintaining authority. As required by BCP 47, subtags follow the language tag ABNF and other rules for the formation of language tags and subtags, are restricted to the ASCII letters and digits, are not case sensitive, and do not exceed eight characters in length.
ユニコードロケール・データ・マークアップ言語（LDML）UTS35]、ユニコード共通ロケールデータリポジトリ（CLDR）プロジェクトの主な仕様：フィールドサブタグは、Unicode技術標準＃35のセクション3で定義されています。その部分はまた、ユニコードコンソーシアムも維持する権限されたパラレル「U」拡張[RFC6067]を定義します。 BCP 47で要求されているように、言語タグABNFと言語タグとサブタグの形成のための他の規則に従ってサブタグ、大文字と小文字を区別しません、ASCII文字と数字に制限されており、長さが8つの文字を超えてはなりません。
The LDML specification is available over the Internet and at no cost, and is available via a royalty-free license at http://unicode.org/copyright.html. LDML is versioned, and each version of LDML is numbered, dated, and stable. Extension subtags, once defined by LDML, are never retracted or substantially changed in meaning.
LDML仕様は、インターネット上でかつ無償で利用可能で、http://unicode.org/copyright.htmlでロイヤリティフリーのライセンスを経由して提供されています。 LDMLがバージョン管理され、そしてLDMLの各バージョンは、番号付け、かつ安定です。一度LDMLによって定義された拡張サブタグは、引き込まれていない、または実質的な意味で変わっありません。
The maintaining authority for the 't' extension is the Unicode Consortium:
「T」延長のための維持の権限は、Unicodeコンソーシアムです。
+---------------+---------------------------------------------------+
| Item | Value |
+---------------+---------------------------------------------------+
| Name | Unicode Consortium |
| Contact Email | cldr-contact@unicode.org |
| Discussion | cldr-users@unicode.org |
| List Email | |
| URL Location | cldr.unicode.org |
| Specification | Unicode Technical Standard #35 Unicode Locale |
| | Data Markup Language (LDML), |
| | http://unicode.org/reports/tr35/ |
| Section | Section 3 Unicode Language and Locale Identifiers |
+---------------+---------------------------------------------------+
The subtags in the 't' extension are of the following form:
「T」の拡張子でサブタグは次の形式です。
t-ext = "t" ; Extension (("-" lang *("-" field)) ; Source + optional field(s) / 1*("-" field)) ; Field(s) only (no source)
= "T" T-EXT。拡張（（ " - " のlang *（ " - " フィールド））;ソース+オプショナルフィールド（複数可）/ 1 *（ " - " フィールド））。フィールド（複数可）のみ（ソース）
lang = language ; BCP 47, with restrictions ["-" script] ["-" region] *("-" variant)
LANG =言語。 [ " - " 地域] *（ " - " バリアント） - 制限[ "" スクリプト]とBCP 47、
field = fsep 1*("-" 3*8alphanum) ; With restrictions
フィールド= FSEP 1 *（ " - " 3 * 8alphanum）。制限付きで
fsep = ALPHA DIGIT ; Subtag separators alphanum = ALPHA / DIGIT
FSEP = ALPHAのDIGIT。サブタグセパレータalphanum = ALPHA / DIGIT
where <language>, <script>, <region>, and <variant> rules are specified in [BCP47], and <ALPHA> and <DIGIT> rules in [RFC5234].
ここで、<言語>、<SCRIPT>、<地域>、および[RFC5234]に<変形例>ルールは、[BCP47]、及び<ALPHA>で指定され、<DIGIT>規則。
Description and restrictions:
説明と制限：
a. The 't' extension MUST have at least one subtag.
A。 「T」延長は少なくとも一つのサブタグを持たなければなりません。
b. The 't' extension normally starts with a source language tag, which MUST be a regular, canonical language tag as specified by [BCP47]. Tags described by the 'irregular' production in BCP 47 MUST NOT be used to form the language tag. The source language tag MAY be omitted: some field values do not require it.
B。 「T」の拡張子は、通常[BCP47]によって指定されるように、正規、正規言語タグでなければなりませんソース言語のタグで始まります。 BCP 47の「不規則の生産によって説明タグは、言語タグを形成するために使用してはいけません。ソース言語タグを省略することができる。いくつかのフィールドの値は、それを必要としません。
c. There is optionally a sequence of fields, where each field has a separator followed by a sequence of one or more subtags. Two identical field separators MUST NOT be present in the language tag.
C。各フィールドは、1つ以上のサブタグのシーケンスが続くセパレータを有しているフィールドの順序は、任意選択です。二つの同一フィールドセパレータは、言語タグ中に存在してはなりません。
d. The order of the fields in a 't' extension is not significant. The order of subtags within a field is significant. See Section 2.3 ("Canonicalization").
D。 「T」延長のフィールドの順序は重要ではありません。フィールド内のサブタグの順序は重要です。 2.3節（ "正規化"）を参照してください。
e. The 't' subtag fields are defined by Section 3 of Unicode Technical Standard #35: Unicode Locale Data Markup Language [UTS35].
電子。 「T」サブタグフィールドは、ユニコード技術標準＃35のセクション3で定義されている：ユニコードロケール・データ・マークアップ言語は、[UTS35]。
As required by [BCP47], the use of uppercase or lowercase letters is not significant in the subtags used in this extension. The canonical form for all subtags in the extension is lowercase, with the fields ordered by the separators, alphabetically. The order of subtags within a field is significant, and MUST NOT be changed in the process of canonicalizing.
[BCP47]によって要求されるように、大文字または小文字の使用は、この拡張に使用サブタグに重要ではありません。拡張子のすべてのサブタグのための標準的な形式は、アルファベット順に、セパレータで順序体で、小文字です。フィールド内のサブタグの順序は重要である、とcanonicalizingの過程で変更しないでください。
Per RFC 5646, Section 3.7 [BCP47]:
RFC 5646あたり、3.7節[BCP47]：
%% Identifier: t Description: Specifying Transformed Content Comments: Subtags for the identification of content that has been transformed, including but not limited to: transliteration, transcription, and translation. Added: 2011-12-16 RFC: RFC 6497 Authority: Unicode Consortium Contact_Email: cldr-contact@unicode.org Mailing_List: cldr-users@unicode.org URL: http://www.unicode.org/Public/cldr/latest/core.zip %%
%%識別子：T説明：変換されたコンテンツを識別するためのサブタグ、を含むがこれらに限定されない：音訳、転写、および翻訳形質コンテンツコメントを指定します。追加：2011-12-16 RFC：RFC 6497機関：ユニコードコンソーシアムCONTACT_EMAIL：cldr-contact@unicode.org Mailing_List：cldr-users@unicode.org URL：http://www.unicode.org/Public/cldr/latest /core.zip %%
Assignment of 't' field subtags is determined by the Unicode CLDR Technical Committee, in accordance with the policies and procedures in http://www.unicode.org/consortium/tc-procedures.html, and subject to the Unicode Consortium Policies on http://www.unicode.org/policies/policies.html.
「T」フィールドサブタグの割り当てはhttp://www.unicode.org/consortium/tc-procedures.htmlにおけるポリシーや手順に従って、UnicodeのCLDR技術委員会によって決定され、上のUnicodeコンソーシアムのポリシーの対象とされますhttp://www.unicode.org/policies/policies.html。
Assignments that can be made by successive versions of LDML [UTS35] by the Unicode Consortium without requiring a new RFC include:
新しいRFCを必要とせずに、ユニコードコンソーシアムによってLDML [UTS35]の連続したバージョンによって製造することができる割り当てが含まれます。
o The allocation of new field separator subtags for use after the 't' extension.
「T」伸長後に使用するための新しいフィールドセパレータサブタグの割り当てO。
o The allocation of subtags valid after a field separator subtag.
フィールドセパレータサブタグ後の有効なサブタグの割り当てO。
o The addition of subtag aliases and descriptions.
サブタグの別名と説明のほか、O。
o The modification of subtag descriptions.
サブタグの説明の変更、O。
Changes to the syntax or meaning of the 't' extension would require a new RFC that obsoletes this document; such an RFC would break stability, and would thus be contrary to the policies of the Unicode Consortium.
「T」延長の構文や意味の変更はこの文書を廃止新しいRFCが必要となります。そのようなRFCは、安定性を破るため、ユニコードコンソーシアムの方針に反するだろう。
At the time this document was published, one field separator subtag was specified in [UTS35]: the transform mechanism. That field is summarized here:
変換メカニズム：この文書が公開された時点では、1つのフィールドセパレータサブタグは、[UTS35]で指定されました。そのフィールドはここに要約されます。
a. The transform mechanism consists of a sequence of subtags starting with the 'm0' separator followed by one or more mechanism subtags. Each mechanism subtag has a length of 3 to 8 alphanumeric characters. The sequence as a whole provides an identification of the specification for the transform, such as the mechanism subtag 'ungegn' in "und-Cyrl-t-und-latn-m0-ungegn". In many cases, only one mechanism subtag is necessary, but multiple subtags MAY be defined in [UTS35] where necessary.
A。変換機構は、一つ以上の機構サブタグ続い「M0」セパレータ始まるサブタグの配列からなります。各機構サブタグは3~8英数字文字の長さを有します。全体の配列は、「ウント・Cyrl-T-undの-LATN-M0-UNGEGN」の「UNGEGN」メカニズムサブタグとして、変換の仕様の識別を提供します。多くの場合、唯一の機構サブタグが必要であるが、複数のサブタグは、必要に応じて[UTS35]で定義されてもよいです。
b. Any purely numeric subtag is a representation of a date in the Gregorian calendar. It MAY occur in any mechanism field, but it SHOULD only be used where necessary. If it does occur:
B。任意の数字だけサブタグは、グレゴリオ暦の日付の表現です。これは、任意のメカニズムフィールドで発生する可能性があり、それが必要な場合にのみ使用されるべきです。それが発生した場合：
* it MUST occur as the final subtag in the field
*これは、フィールド内の最後のサブタグとして行われなければなりません
* it MUST NOT be the only subtag in the field
*これは、フィールド内の唯一のサブタグているはずがありません
* it MUST only consist of a sequence of digits of the form YYYY, YYYYMM, or YYYYMMDD
*だけフォームYYYY、YYYYMM、またはYYYYMMDDの数字のシーケンスで構成されなければなりません
* it SHOULD be as short as possible
*それはできるだけ短くしてください
Note: The format is related to that of [RFC3339], but is not the same. The RFC 3339 full-date won't work because it uses hyphens. The offset ("Z") is not used because the date is a publication date (aka 'floating date'). For more information, see Section 3.3 ("Floating Time") of [W3C-TimeZones].
注：フォーマットは、[RFC3339]のものに関連しているが、同じではありません。それはハイフンを使用しているため、RFC 3339のフル日付は動作しません。日付が公開日（別名「フローティング日付」）であるため、オフセット（「Z」）が使用されていません。詳細については、[W3C-時間帯]のセクション3.3（「フローティング時間」を参照）。
c. Examples:
C。例：
* 20110623 represents June 23, 2011.
* 20110623は、2011年6月23日を表します。
* There are three dated versions of the UNGEGN transliteration specification for Hebrew to Latin. They can be represented by the following language tags:
*ラテン語ヘブライ語のためのUNGEGN音訳仕様の3日付のバージョンがあります。彼らは次の言語タグで表現することができます：
+ und-Hebr-t-und-latn-m0-ungegn-1972
+そして、ヘブライ語-T-と-LATN-M0-UNGEGN-1972
+ und-Hebr-t-und-latn-m0-ungegn-1977
+そして、ヘブル-T-と-LATN-M0-UNGEGN-1977
+ und-Hebr-t-und-latn-m0-ungegn-2007
+そして、ヘブル-T-と-LATN-M0-UNGEGN-2007
* Suppose that the BGN transliteration specification for Cyrillic to Latin had three versions, dated June 11, 1999; Dec 30, 1999; and May 1, 2011. In that case, the corresponding first two DATE subtags would require the months to be distinctive (199906 and 199912), but the last subtag would only require the year (2011).
*ラテン語にキリル文字のためのBGNの音訳仕様は三つのバージョンを持っていたと仮定し、1999年6月11日の日付。 1999年12月30日;そして5月1日、2011年その場合には、対応する最初の2つの日付のサブタグが独特であることを数ヶ月を必要とする（199906と199912）が、最後のサブタグ年（2011）にのみ必要となります。
d. Some mechanisms may use a versioning system that is not distinguished by date, or not by date alone. In the latter case, the version will be of a form specified by [UTS35] for that mechanism. For example, if the mechanism xxx uses versions of the form v21a, then a tag could look like "ja-t-it-m0-xxx-v21a". If there are multiple sub-versions distinguished by date, then a tag could look like "ja-t-it-m0-xxx-v21a-2007".
D。いくつかのメカニズムだけでは日付でない日付で区別、またはされていないバージョン管理システムを使用することができます。後者の場合、バージョンは、その機構のために[UTS35]で指定された形式のものであろう。機構xxxはフォームv21aのバージョンを使用する場合、例えば、タグは、「JA-T-IT-M0-XXX-v21a」ように見える可能性があります。日付で区別複数のサブバージョンが存在する場合には、タグは、「JA-T-それ-M0-XXX-v21a-2007」のようになります。
A language tag with the 't' extension MAY be used to request a specific transform of content. In such a case, the recipient SHOULD return content that corresponds as closely as feasible to the requested transform, including the specification of the mechanism. For example, if the request is ja-t-it-m0-xxx-v21a-2007, and the recipient has content corresponding to both ja-t-it-m0-xxx-v21a and ja-t-it-m0-xxx-v21b-2009, then the v21a version would be preferred. As is the case for language matching as discussed in [BCP47], different implementations MAY have different measures of "closeness".
「T」拡張子を持つ言語タグは、特定のコンテンツの変換を要求するために使用されるかもしれません。このような場合、受信者は、機構の指定を含む、変換要求に同様に密接可能として対応するコンテンツを返すべきです。例えば、要求は、JA-T-IT-M0-XXX-v21a-2007であり、受信者は、JA-T-IT-M0-XXX-v21a及びJA-T-IT-M0-XXXの両方に対応するコンテンツを有する場合-v21b-2009、その後、v21aバージョンが好ましいであろう。 [BCP47]で説明したように、言語マッチングの場合のように、異なる実装が「近さ」の異なった尺度があるかもしれません。
Registration of transform mechanisms is requested by filing a ticket at http://cldr.unicode.org/. The proposal in the ticket MUST contain the following information:
変換メカニズムの登録はhttp://cldr.unicode.org/でチケットを提出することにより、要求されました。チケットでの提案は、以下の情報を含まなければなりません：
+-------------+-----------------------------------------------------+
| Item | Description |
+-------------+-----------------------------------------------------+
| Subtag | The proposed mechanism subtag (or subtag sequence). |
| Description | A description of the proposed mechanism; that |
| | description MUST be sufficient to distinguish it |
| | from other mechanisms in use. |
| Version | If versioning for the mechanism is not done |
| | according to date, then a description of the |
| | versioning conventions used for the mechanism. |
+-------------+-----------------------------------------------------+
Proposals for clarifications of descriptions or additional aliases may also be requested by filing a ticket.
説明や追加の別名の明確化のための提案もチケットを提出することにより要求される場合があります。
The committee MAY define a template for submissions that requests more information, if it is found that such information would be useful in evaluating proposals.
委員会は、そのような情報は、提案を評価する際に有用であろうことが判明した場合には、より多くの情報を要求提出するためのテンプレートを定義できます。
In the event that it proves necessary to add an additional field (such as 'm2'), it can be requested by filing a ticket at http://cldr.unicode.org/. The proposal in the ticket MUST contain a full description of the proposed field semantics and subtag syntax, and MUST conform to the ABNF syntax for "field" presented in Section 2.2.
それは（このような「M2」として）追加フィールドを追加する必要が証明している場合には、http://cldr.unicode.org/でチケットを提出することにより要求することができます。チケットでの提案は、提案されたフィールドのセマンティクスとサブタグ構文の完全な説明を含まなければならない、と2.2節で提示「フィールド」のためのABNF構文に従わなければなりません。
The committee MUST post each proposal publicly within 2 weeks after reception, to allow for comments. The committee must respond publicly to each proposal within 4 weeks after reception.
委員会は、コメントを可能にするために、受信した後、2週間以内に、公に各提案を掲示しなければなりません。委員会は、受信した後、4週間以内に各提案に公に応答しなければなりません。
The response MAY:
応答MAY：
o request more information or clarification
Oより多くの情報または説明を要求
o accept the proposal, optionally with modifications to the subtag or description
Oサブタグまたは説明に変更を加えて必要に応じて、提案を受け入れます
o reject the proposal, because of significant objections raised on the mailing list or due to problems with constraints in this document or in [UTS35]
Oによるこの文書に記載されているかで制約の問題にあるため、メーリングリストや調達の重要な異議の、提案を拒否[UTS35]
Accepted tickets result in a new entry in the machine-readable CLDR BCP 47 data or, in the case of a clarified description, modifications to the description attribute value for an existing entry.
受け入れられたチケットは、機械可読CLDR BCP 47のデータまたは、清澄説明の場合、既存のエントリの記述属性値の変更に新しいエントリをもたらします。
Beginning with CLDR version 1.7.2, machine-readable files are available listing the data defined for BCP 47 extensions for each successive version of [UTS35]. The data in these files is used for testing the validity of subtags for the 't' extension and for the 'u' extension [RFC6067], for which the Unicode Consortium is also the maintaining authority. These releases are listed on http://cldr.unicode.org/index/downloads. Each release has an associated data directory of the form "http://unicode.org/Public/cldr/<version>", where "<version>" is replaced by the release number. For example, for version 1.7.2, the
CLDRバージョン1.7.2以降では、機械可読ファイルは、[UTS35]の各連続バージョンのBCP 47の拡張のために定義されたデータを一覧表示できます。これらのファイル内のデータは「T」は拡張するとUnicodeコンソーシアムも維持権威であるために「U」拡張[RFC6067]のためのサブタグの有効性をテストするために使用されています。これらのリリースはhttp://cldr.unicode.org/index/downloadsに上場されています。各リリースは、フォームの関連データディレクトリが「http://unicode.org/Public/cldr/ <バージョン>」、ここで「<バージョン>」がリリース番号に置き換えられています。例えば、バージョン1.7.2のために、
"core.zip" file is located at http://unicode.org/Public/cldr/1.7.2/core.zip. The most recent version is always identified by the version "latest" and can be accessed by the URL in Section 2.4.
「core.zip」ファイルがhttp://unicode.org/Public/cldr/1.7.2/core.zipに位置しています。最新のバージョンは常にバージョン「最新」で識別され、2.4節にURLでアクセスすることができます。
Inside the "core.zip" file, the directory "common/bcp47" contains the data files listing the valid attributes, keys, and types for each successive version of [UTS35]. Each data file lists the keys and types relevant to that topic.
「core.zip」ファイル内では、ディレクトリ「共通/ BCP47は、」[UTS35]の各連続バージョンの有効な属性、キー、およびタイプをリストのデータファイルが含まれています。各データファイルは、そのトピックに関連するキーと種類を示しています。
The XML structure lists the keys, such as <key extension="t" name="m0" description="Transliteration extension mechanism">, with subelements for the types, such as <type name="ungegn" description="United Nations Group of Experts on Geographical Names"/>. The currently defined attributes for the mechanisms include:
XMLの構造は、次のようなキーを示しています。<キー拡張子=「T」名前=「M0」の説明=「翻拡張メカニズム」>そのようなタイプ名=「UNGEGN」説明=「国連<などのタイプのサブ要素と、地名に関する専門家グループ "/>。メカニズムの現在定義された属性が含まれます：
+-------------+-------------------------------+---------------------+
| Attribute | Description | Examples |
+-------------+-------------------------------+---------------------+
| name | The name of the mechanism, | UNGEGN, ALALC |
| | limited to 3-8 characters (or | |
| | sequences of them). | |
| description | A description of the name, | United Nations |
| | with all and only that | Group of Experts on |
| | information necessary to | Geographical Names; |
| | distinguish one name from | American Library |
| | others with which it might be | Association-Library |
| | confused. Descriptions are | of Congress |
| | not intended to provide | |
| | general background | |
| | information. | |
| since | Indicates the first version | 1.9, 2.0.1 |
| | of CLDR where the name | |
| | appears. (Required for new | |
| | items.) | |
| alias | Alternative name of the key | |
| | or type, not limited in | |
| | number of characters. | |
| | Aliases are intended for | |
| | backwards compatibility, not | |
| | to provide all possible | |
| | alternate names or | |
| | designations. (Optional.) | |
+-------------+-------------------------------+---------------------+
The file for the transform extension is "transform.xml". The initial version of that file contains the following information.
変換の拡張のためのファイルは、「transform.xml」です。そのファイルの最初のバージョンは、以下の情報が含まれています。
<keyword> <key extension="t" name="m0" description= "Transliteration extension mechanism"> <type name="ungegn" description= "United Nations Group of Experts on Geographical Names" since="21"/> <type name="alaloc" description= "American Library Association-Library of Congress" since="21"/> <type name="bgn" description= "US Board on Geographic Names" since="21"/> <type name="mcst" description= "Korean Ministry of Culture, Sports and Tourism" since="21"/> <type name="iso" description= "International Organization for Standardization" since="21"/> <type name="din" description= "Deutsches Institut fuer Normung" since="21"/> <type name="gost" description= "Euro-Asian Council for Standardization, Metrology and Certification" since="21"/> </key> </keyword>
<キーワード> <キー拡張子=「T」名前=「M0」の説明=「翻拡張メカニズム」> <タイプ名=「UNGEGN」説明=「地理学的名称に関する国連専門家グループ」以来=「21」/> <型名=「alaloc」説明=「議会のアメリカ図書館協会・ライブラリ」から=「21」/> <タイプ名=「BGN」説明=「地名の米国委員会」以来=「21」/> <型名=「MCST」説明=「文化体育観光部、韓国省」=「21」/> <タイプ名=「ISO」の説明=「国際標準化機構」以来=「21」/> <型名以来=」喧騒」説明= "ドイツ研究所fuer Normung" 以来= "21" /> <タイプ名= "GOST" 説明= "ユーロ・アジア・カウンシル標準化のため、計量と認定" 以来= "21" /> </ key>の< /キーワード>
To get the version information in XML when working with the data files, the XML parser must be validating. When the 'core.zip' file is unzipped, the 'dtd' directory will be at the same level as the 'bcp47' directory; this is required for correct validation. For each release after CLDR 1.8, types introduced in that release are also marked in the data files by the XML attribute "since", such as in the following example: <type name="adp" since="1.9"/>
データファイルを扱う際にXMLにバージョン情報を取得するには、XMLパーサは、検証する必要があります。 「core.zip」ファイルを解凍した場合、「DTD」ディレクトリには、「BCP47」ディレクトリと同じレベルになります。これは、正しい検証に必要とされます。 CLDR 1.8以降の各リリースでは、このリリースで導入されたタイプはまた、次の例のように、「以来の」XML属性によるデータファイルにマークされている。<タイプ名=「ADP」以来=「1.9」/>
The data is also currently maintained in a source code repository, with each release tagged, for viewing directly without unzipping. For example, see:
データはまた、現在解凍せずに直接観察するため、タグ付けされたリリースごとに、ソースコードリポジトリに維持されます。たとえば、以下を参照してください。
o http://unicode.org/repos/cldr/tags/release-1-7-2/common/bcp47/
お ｈっｔｐ：／／うにこで。おｒｇ／れぽｓ／ｃｌｄｒ／たｇｓ／れぇあせー１ー７ー２／こっもん／ｂｃｐ４７／
o http://unicode.org/repos/cldr/tags/release-1-8/common/bcp47/
お ｈっｔｐ：／／うにこで。おｒｇ／れぽｓ／ｃｌｄｒ／たｇｓ／れぇあせー１ー８／こっもん／ｂｃｐ４７／
For more information, see http://cldr.unicode.org/index/bcp47-extension.
詳細については、http://cldr.unicode.org/index/bcp47-extensionを参照してください。
Thanks to John Emmons and the rest of the Unicode CLDR Technical Committee for their work in developing the BCP 47 subtags for LDML.
LDMLのためのBCP 47サブタグを開発する上で自分の仕事のためにジョン・エモンズとUnicode CLDR技術委員会の残りに感謝します。
IANA has inserted the record of Section 2.4 into the Language Extensions Registry, according to Section 3.7 ("Extensions and the Extensions Registry") of "Tags for Identifying Languages" [BCP47]. Per Section 5.2 of [BCP47], there might be occasional (rare) requests by the Unicode Consortium (the "Authority" listed in the record) for maintenance of this record. Changes that can be submitted to IANA without the publication of a new RFC are limited to modification of the Comments, Contact_Email, Mailing_List, and URL fields. Any such requested changes MUST use the domain 'unicode.org' in any new addresses or URIs, MUST explicitly cite this document (so that IANA can reference these requirements), and MUST originate from the 'unicode.org' domain. The domain or authority can only be changed via a new RFC.
IANAは、「言語を識別するためのタグ」[BCP47]のセクション3.7（「拡張機能と拡張機能レジストリ」）によれば、言語拡張レジストリにセクション2.4のレコードを挿入しました。 5.2節[BCP47]のあたりに、このレコードのメンテナンスのためのUnicodeコンソーシアム（レコードに記載されている「当局」）によって、時折（まれ）の要求があるかもしれません。新しいRFCの公表なしでIANAに提出することができます変更はコメント、CONTACT_EMAIL、Mailing_List、およびURLフィールドの変更に制限されています。そのような任意の要求された変更は、新しいアドレスまたはURIのドメイン「unicode.org」を使用しなければならない、明示的に（IANAがこれらの要件を参照できるように）、この文書を引用しなければならない、と「unicode.org」ドメインから発信する必要があります。ドメインまたは権限が唯一の新しいRFCを介して変更することができます。
The security considerations for this extension are the same as those for [BCP47]. See RFC 5646, Section 6, Security Considerations [BCP47].
この拡張のためのセキュリティの考慮事項は、[BCP47]と同じです。 [BCP47] RFC 5646、セクション6、セキュリティについての考慮事項を参照してください。
[BCP47] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[BCP47]フィリップス、A.編、およびM.デイビス、エド。、 "言語を識別するためのタグ"、BCP 47、RFC 5646、2009年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。
[UTS35] Davis, M., "Unicode Technical Standard #35: Locale Data Markup Language (LDML)", February 2012, <http://www.unicode.org/reports/tr35/>.
[UTS35]デイビス、M.、 "Unicodeの技術標準＃35：ロケール・データマークアップ言語（LDML）"、2012年2月、<http://www.unicode.org/reports/tr35/>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339] Klyne、G.とC.ニューマン、 "インターネット上の日付と時刻：タイムスタンプ"、RFC 3339、2002年7月。
[RFC6067] Davis, M., Phillips, A., and Y. Umaoka, "BCP 47 Extension U", RFC 6067, December 2010.
[RFC6067]デイビス、M.、フィリップス、A.、およびY. Umaoka、 "BCP 47拡張U"、RFC 6067、2010年12月。
[W3C-TimeZones] Phillips, Ed., "W3C Working Group Note: Working with Time Zones", July 2011, <http://www.w3.org/TR/2011/NOTE-timezone-20110705/>.
[W3C-タイムゾーン]フィリップス、エド、 "W3Cワーキンググループ注：タイムゾーンでの作業"。、2011年7月、<http://www.w3.org/TR/2011/NOTE-timezone-20110705/>。
Authors' Addresses
著者のアドレス
Mark Davis Google
マーク・デイビスグーグル
EMail: mark@macchiato.com
メールアドレス：mark@macchiato.com
Addison Phillips Lab126
アディソン・フィリップスLab126
EMail: addison@lab126.com
メールアドレス：addison@lab126.com
Yoshito Umaoka IBM
よしと うまおか いＢＭ
EMail: yoshito_umaoka@us.ibm.com
メールアドレス：yoshito_umaoka@us.ibm.com
Courtney Falk Infinite Automata
コートニー・フォーク無限オートマトン
EMail: court@infiauto.com
メールアドレス：court@infiauto.com