[要約] RFC 6497は、BCP 47拡張Tで定義されるTransformed Contentに関する要約です。このRFCの目的は、言語タグの拡張機能を提供し、変換されたコンテンツの言語情報を正確に表現することです。
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
BCP 47 Extension T - Transformed Content
BCP 47拡張T-変換されたコンテンツ
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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>に対応しています）は、英語の「プーチン」であるがフランス語の「プーチン」に音訳されます。識別子を使用して、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:
さらに、同じ言語とスクリプトの間でさえ、テキストを変換する方法については、多くの異なる規則が生じています。たとえば、「gaddafi」は、一般にアラビア語から英語まで、（g/q/k/kh）a（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)
e. 国際標準化機関（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").
具体的には、特定の言語の第1言語スピーカーである第2言語スピーカー向け（たとえば、「中国のアクセントと話された英語」の認識者）。
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」拡張機能を使用して実行できます。この拡張機能は、「T」シングルトンによって形成され、その後に[BCP47]で定義された言語タグを形成する一連のサブタグが続きます。これにより、ソース言語またはスクリプトを必要な精度の程度まで指定できます。サブタグのシーケンスには制限があります。それらは、定期的な有効な標準的な言語タグを形成する必要があり、シングルトン「X」によって導入された拡張機能もプライベート使用シーケンスも含める必要があります。スクリプトのみが関連する場合（スクリプトスクリプトの音訳の識別など）、「UND」が主要な言語サブタグに使用されます。
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」によって支配されたサブタグのシーケンスには、新しい拡張機能が開始されるため、シングルトン（シングルキャラクターサブタグ）を含めることはできないことに注意してください。たとえば、「Ja-t-i-ami」というタグは、「i-ami」は[BCP47]の正規の言語タグではないため、ソースが「i-ami」にあることを示していません。そのタグは、空の 't'拡張子を表現し、その後に「i」拡張子が続きます。
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などのローカリゼーションインターチェンジ形式の場合です。そのような場合、ソース言語タグ「IT」がすでにデータに存在するため、ターゲット言語タグに「JA-T-IT」を使用することは不適切です。代わりに、言語タグ「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つ以上の非セパレーターサブタグが続きます。各フィールドセパレーターサブタグは、単一の文字と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.
フィールドサブタグは、Unicode Technical Standard＃35のセクション3で定義されています。UnicodeCommonLocale Data Repository（CLDR）プロジェクトの主な仕様であるUnicode Locale Data Markup Language（LDML）[UTS35]。そのセクションでは、Unicodeコンソーシアムも維持権である並列「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)
lang = language ; BCP 47, with restrictions ["-" script] ["-" region] *("-" variant)
Lang = Language;BCP 47、制限付き[" - "スクリプト] [" - " region] *（ " - "バリアント）
field = fsep 1*("-" 3*8alphanum) ; With restrictions
fsep = ALPHA DIGIT ; Subtag separators
alphanum = ALPHA / DIGIT
where <language>, <script>, <region>, and <variant> rules are specified in [BCP47], and <ALPHA> and <DIGIT> rules in [RFC5234].
ここで、[rfc5234]の[bcp47]、および<alpha>および<digit>ルールで<言語>、<cript>、<region>、および<variant>ルールが指定されています。
Description and restrictions:
説明と制限：
a. The 't' extension MUST have at least one subtag.
a. 「T」拡張子には、少なくとも1つのサブタグが必要です。
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つ以上のサブタグのシーケンスが続きます。言語タグに2つの同一のフィールドセパレーターが存在しないでください。
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（ "Canonicalization"）を参照してください。
e. The 't' subtag fields are defined by Section 3 of Unicode Technical Standard #35: Unicode Locale Data Markup Language [UTS35].
e. 「T」サブタグフィールドは、Unicode Technical Standard＃35：Unicode Locale Data Markup Language [UTS35]のセクション3で定義されています。
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]で要求されているように、この拡張機能で使用されているサブタグでは、大文字または小文字の使用は重要ではありません。拡張機能内のすべてのサブタグの標準形式は小文字であり、分離器によって順序付けられたフィールドがアルファベット順に並べられています。フィールド内のサブタグの順序は重要であり、標準化の過程で変更してはなりません。
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
%%
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 Consortiumポリシーの対象となります。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を必要とせずにUnicodeコンソーシアムがLDML [UTS35]の連続バージョンで作成できる割り当ては次のとおりです。
o The allocation of new field separator subtags for use after the 't' extension.
o 「T」拡張後に使用するための新しいフィールドセパレーターサブタグの割り当て。
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は安定性を破るため、Unicodeコンソーシアムのポリシーに反します。
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」セパレーターから始まるサブタグのシーケンスで構成され、その後に1つ以上のメカニズムサブタグが続きます。各メカニズムサブタグの長さは3〜8個の英数字です。シーケンス全体として、「und-cyrl-t-und-latn-m0-ungegn」のメカニズムサブタグ「ungegn」など、変換の仕様の識別を提供します。多くの場合、1つのメカニズムサブタグのみが必要ですが、必要に応じて[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-TimeZones]のセクション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
+ und-hebr-t-und-latn-m0-ungegn-1972
+ und-Hebr-t-und-latn-m0-ungegn-1977
+ und-hebr-t-und-latn-m0-ungegn-1977
+ und-Hebr-t-und-latn-m0-ungegn-2007
+ und-hebr-t-und-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日付の3つのバージョンがあると仮定します。1999年12月30日;2011年5月1日。その場合、対応する最初の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-IT-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:
応答は次のとおりです。
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
"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" name = "m0" description = "lranteration endixメカニズム"などのキーがリストされています。地理的名に関する専門家のグループ "/>。メカニズムの現在定義されている属性には、以下が含まれます。
+-------------+-------------------------------+---------------------+
| 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>
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属性「afth」によるデータファイルにもマークされています。
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
o http://unicode.org/repos/cldr/tags/release-1-8/common/bcp47/
o
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.
John Emmonsと、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は、「言語を識別するためのタグ」のセクション3.7（「拡張機能と拡張レジストリ」）[BCP47]のセクション3.7（「エクステンションと拡張レジストリ」）に従って、セクション2.4のレコードを言語拡張レジストリに挿入しました。[BCP47]のセクション5.2に従って、このレコードのメンテナンスのために、Unicodeコンソーシアム（記録に記載されている「権限」）による時折（まれな）要求があるかもしれません。新しいRFCの公開なしでIANAに提出できる変更は、コメント、contact_email、maeling_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]のセキュリティと同じです。RFC 5646、セクション6、セキュリティに関する考慮事項[BCP47]を参照してください。
[BCP47] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[BCP47] Phillips、A.、ed。、およびM. Davis編、「言語を識別するためのタグ」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、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] Davis、M。、「Unicode Technical Standard＃35：Locale Data Markup Language（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. Newman、「インターネット上の日時：タイムスタンプ」、RFC 3339、2002年7月。
[RFC6067] Davis, M., Phillips, A., and Y. Umaoka, "BCP 47 Extension U", RFC 6067, December 2010.
[RFC6067] Davis、M.、Phillips、A。、およびY. Umaoka、「BCP 47 Extension 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-TimeZones] Phillips、ed。、「W3Cワーキンググループ注：タイムゾーンの作業」、2011年7月、<http://www.w3.org/tr/2011/note-time-zone-20110705/>。
Authors' Addresses
著者のアドレス
Mark Davis Google
マーク・デイビス・グーグル
EMail: mark@macchiato.com
Addison Phillips Lab126
Addison Phillips Lab126
EMail: addison@lab126.com
Yoshito Umaoka IBM
ヨシートウマオカイブ
EMail: yoshito_umaoka@us.ibm.com
Courtney Falk Infinite Automata
コートニーフォークインフィニットオートマトン
EMail: court@infiauto.com