[要約] RFC 4647は、言語タグのマッチングに関する仕様であり、言語タグの比較と一致の方法を定義しています。このRFCの目的は、異なる言語タグを正確に比較し、一致するかどうかを判断するための基準を提供することです。
Network Working Group A. Phillips, Ed.
Request for Comments: 4647 Yahoo! Inc.
BCP: 47 M. Davis, Ed.
Obsoletes: 3066 Google
Category: Best Current Practice September 2006
Matching of Language Tags
言語タグの一致
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 (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766.
このドキュメントでは、ユーザーの言語設定リストに項目を指定するための「言語範囲」と呼ばれる構文について説明しています。また、これらを言語タグと比較して一致させるためのさまざまなメカニズムについても説明しています。フィルタリングとルックアップの2種類のマッチングメカニズムが定義されています。フィルタリングは、（潜在的に空の）言語タグのセットを生成しますが、Lookupは単一の言語タグを生成します。可能なアプリケーションには、言語交渉またはコンテンツ選択が含まれます。このドキュメントは、RFC 4646と組み合わせて、RFC 1766に取って代わるRFC 3066を置き換えます。
Table of Contents
目次
1. Introduction ....................................................3
2. The Language Range ..............................................3
2.1. Basic Language Range .......................................4
2.2. Extended Language Range ....................................4
2.3. The Language Priority List .................................5
3. Types of Matching ...............................................6
3.1. Choosing a Matching Scheme .................................6
3.2. Implementation Considerations ..............................7
3.3. Filtering ..................................................8
3.3.1. Basic Filtering .....................................9
3.3.2. Extended Filtering .................................10
3.4. Lookup ....................................................12
3.4.1. Default Values .....................................14
4. Other Considerations ...........................................15
4.1. Choosing Language Ranges ..................................15
4.2. Meaning of Language Tags and Ranges .......................16
4.3. Considerations for Private-Use Subtags ....................17
4.4. Length Considerations for Language Ranges .................17
5. Security Considerations ........................................17
6. Character Set Considerations ...................................17
7. References .....................................................18
7.1. Normative References ......................................18
7.2. Informative References ....................................18
Appendix A. Acknowledgements ......................................19
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.
私たちの惑星の人間は、過去と現在に多くの言語を使用しています。情報を提示または要求するときに使用される言語を特定したい理由はたくさんあります。
Applications, protocols, or specifications that use language identifiers, such as the language tags defined in [RFC4646], sometimes need to match language tags to a user's language preferences.
[RFC4646]で定義された言語タグなど、言語識別子を使用するアプリケーション、プロトコル、または仕様は、言語タグをユーザーの言語設定に一致させる必要がある場合があります。
This document defines a syntax (called a language range (Section 2)) for specifying items in the user's list of language preferences (called a language priority list (Section 2.3)), as well as several schemes for selecting or filtering sets of language tags by comparing the language tags to the user's preferences. Applications, protocols, or specifications will have varying needs and requirements that affect the choice of a suitable matching scheme.
このドキュメントでは、ユーザーの言語設定のリストに項目を指定するための構文（言語範囲（セクション2））を定義します（言語優先順位リスト（セクション2.3））、および言語タグのセットを選択またはフィルタリングするためのいくつかのスキーム言語タグをユーザーの設定と比較します。アプリケーション、プロトコル、または仕様には、適切なマッチングスキームの選択に影響するさまざまなニーズと要件があります。
This document describes how to indicate a user's preferences using language ranges, three schemes for matching these ranges to a set of language tags, and the various practical considerations that apply to implementing and using these schemes.
このドキュメントでは、言語範囲を使用してユーザーの設定を示す方法、これらの範囲を一連の言語タグに一致させるための3つのスキーム、およびこれらのスキームの実装と使用に適用されるさまざまな実用的な考慮事項について説明します。
This document, in combination with [RFC4646], replaces [RFC3066], which replaced [RFC1766].
[RFC 4646]と組み合わせて、この文書は[RFC 3066]に置き換えられ、[RFC 1766]に置き換えられました。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Language tags [RFC4646] are used to help identify languages, whether spoken, written, signed, or otherwise signaled, for the purpose of communication. Applications, protocols, or specifications that use language tags are often faced with the problem of identifying sets of content that share certain language attributes. For example, HTTP/1.1 [RFC2616] describes one such mechanism in its discussion of the Accept-Language header (Section 14.4), which is used when selecting content from servers based on the language of that content.
言語タグ[RFC4646]は、コミュニケーションの目的で、話されたり、書かれたり、署名されたり、署名されたり、その他の方法で言及されているかどうかにかかわらず、言語を特定するのに役立ちます。言語タグを使用するアプリケーション、プロトコル、または仕様は、特定の言語属性を共有するコンテンツのセットを識別する問題に直面することがよくあります。たとえば、HTTP/1.1 [RFC2616]は、そのコンテンツの言語に基づいてサーバーからコンテンツを選択するときに使用される、Accept言語ヘッダー（セクション14.4）の議論でそのようなメカニズムの1つを説明します。
It is, thus, useful to have a mechanism for identifying sets of language tags that share specific attributes. This allows users to select or filter the language tags based on specific requirements. Such an identifier is called a "language range".
したがって、特定の属性を共有する言語タグのセットを識別するためのメカニズムを持つことが有用です。これにより、ユーザーは特定の要件に基づいて言語タグを選択またはフィルタリングできます。このような識別子は「言語範囲」と呼ばれます。
There are different types of language range, whose specific attributes vary according to their application. Language ranges are similar to language tags: they consist of a sequence of subtags separated by hyphens. In a language range, each subtag MUST either be a sequence of ASCII alphanumeric characters or the single character '*' (%x2A, ASTERISK). The character '*' is a "wildcard" that matches any sequence of subtags. The meaning and uses of wildcards vary according to the type of language range.
言語範囲にはさまざまな種類があり、その特定の属性はアプリケーションによって異なります。言語範囲は言語タグに似ています。それらは、ハイフンで区切られたサブタグのシーケンスで構成されています。言語範囲では、各サブタグは、ASCII英数字のシーケンスまたは単一の文字 '*'（％x2a、アスタリスク）でなければなりません。キャラクター「*」は、サブタグのシーケンスに一致する「ワイルドカード」です。ワイルドカードの意味と用途は、言語範囲のタイプによって異なります。
Language tags and thus language ranges 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. Matching of language tags to language ranges MUST be done in a case-insensitive manner.
言語のタグ、したがって言語範囲は、ケース非感受性として扱われるべきです。いくつかのサブタグの大文字化には慣習が存在しますが、これらは意味を運ぶために取られてはなりません。言語タグと言語範囲の一致は、ケースに依存しない方法で行う必要があります。
A "basic language range" has the same syntax as an [RFC3066] language tag or is the single character "*". The basic language range was originally described by HTTP/1.1 [RFC2616] and later [RFC3066]. It is defined by the following ABNF [RFC4234]:
「基本言語範囲」は、[RFC3066]言語タグと同じ構文を持っているか、単一文字「*」です。基本的な言語範囲は、もともとHTTP/1.1 [RFC2616]および後の[RFC3066]によって記述されました。これは、次のABNF [RFC4234]によって定義されています。
language-range = (1*8ALPHA *("-" 1*8alphanum)) / "*"
alphanum = ALPHA / DIGIT
A basic language range differs from the language tags defined in [RFC4646] only in that there is no requirement that it be "well-formed" or be validated against the IANA Language Subtag Registry. Such ill-formed ranges will probably not match anything. Note that the ABNF [RFC4234] in [RFC2616] is incorrect, since it disallows the use of digits anywhere in the 'language-range' (see [RFC2616errata]).
基本的な言語範囲は、[RFC4646]で定義されている言語タグとは異なります。これは、IANA言語サブタグレジストリに対して「よく形成される」、または検証されるという要件がないという点でのみです。このような不正な範囲は、おそらく何も一致しないでしょう。[RFC2616]のABNF [RFC4234]は、「言語範囲」のどこかで数字の使用を許可するため、間違っていることに注意してください（[RFC2616RERATA]を参照）。
Occasionally, users will wish to select a set of language tags based on the presence of specific subtags. An "extended language range" describes a user's language preference as an ordered sequence of subtags. For example, a user might wish to select all language tags that contain the region subtag 'CH' (Switzerland). Extended language ranges are useful for specifying a particular sequence of subtags that appear in the set of matching tags without having to specify all of the intervening subtags.
場合によっては、ユーザーは特定のサブタグの存在に基づいて言語タグのセットを選択したいと考えています。「拡張言語範囲」は、ユーザーの言語選好を、順序付けられたサブタグのシーケンスとして説明しています。たとえば、ユーザーは、地域のサブタグ「Ch」（スイス）を含むすべての言語タグを選択することをお勧めします。拡張言語範囲は、介入するすべてのサブタグを指定することなく、一致するタグのセットに表示される特定のサブタグのシーケンスを指定するのに役立ちます。
An extended language range can be represented by the following ABNF:
拡張言語範囲は、次のABNFで表すことができます。
extended-language-range = (1*8ALPHA / "*")
*("-" (1*8alphanum / "*"))
The wildcard subtag '*' can occur in any position in the extended language range, where it matches any sequence of subtags that might occur in that position in a language tag. However, wildcards outside the first position are ignored by Extended Filtering (see Section 3.2.2). The use or absence of one or more wildcards cannot be taken to imply that a certain number of subtags will appear in the matching set of language tags.
ワイルドカードサブタグ '*'は、拡張言語範囲の任意の位置で発生します。この位置では、言語タグでその位置で発生する可能性のあるサブタグのシーケンスと一致します。ただし、最初の位置の外側のワイルドカードは、拡張フィルタリングによって無視されます（セクション3.2.2を参照）。1つ以上のワイルドカードの使用または不在を使用することはできません。一定数のサブタグが一致する言語タグに表示されることを意味します。
A user's language preferences will often need to specify more than one language range, and thus users often need to specify a prioritized list of language ranges in order to best reflect their language preferences. This is especially true for speakers of minority languages. A speaker of Breton in France, for example, can specify "br" followed by "fr", meaning that if Breton is available, it is preferred, but otherwise French is the best alternative. It can get more complex: a different user might want to fall back from Skolt Sami to Northern Sami to Finnish.
ユーザーの言語設定は、多くの場合、複数の言語範囲を指定する必要があるため、ユーザーは言語の好みを最もよく反映するために、言語範囲の優先順位付けリストを指定する必要があることがよくあります。これは、少数言語のスピーカーに特に当てはまります。たとえば、フランスのブレトンのスピーカーは、「BR」に続いて「FR」を指定できます。つまり、Bretonが利用可能である場合、それが好ましいが、それ以外の場合はフランス語が最良の代替手段であることを意味します。それはより複雑になる可能性があります：別のユーザーは、Skolt SamiからSami北部からフィンランド語に戻りたいと思うかもしれません。
A "language priority list" is a prioritized or weighted list of language ranges. One well-known example of such a list is the "Accept-Language" header defined in RFC 2616 [RFC2616] (see Section 14.4) and RFC 3282 [RFC3282].
「言語優先リスト」は、言語範囲の優先順位付けまたは加重リストです。このようなリストのよく知られた例の1つは、RFC 2616 [RFC2616]（セクション14.4を参照）およびRFC 3282 [RFC3282]で定義されている「受け入れ言語」ヘッダーです。
The various matching operations described in this document include considerations for using a language priority list. This document does not define the syntax for a language priority list; defining such a syntax is the responsibility of the protocol, application, or specification that uses it. When given as examples in this document, language priority lists will be shown as a quoted sequence of ranges separated by commas, like this: "en, fr, zh-Hant" (which is read "English before French before Chinese as written in the Traditional script").
このドキュメントで説明されているさまざまなマッチング操作には、言語優先順位リストを使用するための考慮事項が含まれています。このドキュメントは、言語優先リストの構文を定義しません。このような構文を定義することは、それを使用するプロトコル、アプリケーション、または仕様の責任です。このドキュメントの例として与えられた場合、言語の優先リストは、このようなコンマで区切られた範囲の引用されたシーケンスとして表示されます。従来のスクリプト "）。
A simple list of ranges is considered to be in descending order of priority. Other language priority lists provide "quality weights" for the language ranges in order to specify the relative priority of the user's language preferences. An example of this is the use of "q" values in the syntax of the "Accept-Language" header (defined in [RFC2616], Section 14.4, and [RFC3282]).
範囲の簡単なリストは、優先順位の降順であると考えられています。他の言語優先リストは、ユーザーの言語の好みの相対的な優先度を指定するために、言語範囲の「品質重み」を提供します。この例は、「Q」ヘッダー（[RFC2616]、セクション14.4、および[RFC3282]で定義）の構文で「Q」値の使用です。
Matching language ranges to language tags can be done in many different ways. This section describes three such matching schemes, as well as the considerations for choosing between them. Protocols and specifications requiring conformance to this specification MUST clearly indicate the particular mechanism used in selecting or matching language tags.
言語の範囲を一致させる言語タグは、さまざまな方法で実行できます。このセクションでは、3つのそのような一致するスキームと、それらを選択するための考慮事項について説明します。この仕様への適合を必要とするプロトコルと仕様は、言語タグの選択または一致する際に使用される特定のメカニズムを明確に示す必要があります。
There are two types of matching scheme in this document. A matching scheme that produces zero or more matching language tags is called "filtering". A matching scheme that produces exactly one match for a given request is called "lookup".
このドキュメントには、マッチングスキームには2つのタイプがあります。ゼロ以上の一致する言語タグを生成する一致するスキームは、「フィルタリング」と呼ばれます。特定のリクエストに対して正確に1つの一致を生成するマッチングスキームは、「ルックアップ」と呼ばれます。
Applications, protocols, and specifications are faced with the decision of what type of matching to use. Sometimes, different styles of matching are suited to different kinds of processing within a particular application or protocol.
アプリケーション、プロトコル、および仕様は、どのタイプのマッチングを使用するかの決定に直面しています。特定のアプリケーションまたはプロトコル内のさまざまな種類の処理に適している場合、さまざまなスタイルのマッチングが適しています。
This document describes three matching schemes:
このドキュメントでは、3つの一致するスキームについて説明します。
1. Basic Filtering (Section 3.3.1) matches a language priority list consisting of basic language ranges (Section 2.1) to sets of language tags.
1. 基本フィルタリング（セクション3.3.1）は、基本的な言語範囲（セクション2.1）から言語タグのセットで構成される言語優先リストと一致します。
2. Extended Filtering (Section 3.3.2) matches a language priority list consisting of extended language ranges (Section 2.2) to sets of language tags.
2. 拡張フィルタリング（セクション3.3.2）は、拡張言語範囲（セクション2.2）から言語タグのセットで構成される言語優先順位リストと一致します。
3. Lookup (Section 3.4) matches a language priority list consisting of basic language ranges to sets of language tags to find the one exact language tag that best matches the range.
3. ルックアップ（セクション3.4）は、基本的な言語範囲から構成される言語の優先順位リストと一連の言語タグと一致して、範囲に最適な1つの正確な言語タグを見つけます。
Filtering can be used to produce a set of results (such as a collection of documents) by comparing the user's preferences to a set of language tags. For example, when performing a search, filtering can be used to limit the results to items tagged as being in the French language. Filtering can also be used when deciding whether to perform a language-sensitive process on some content. For example, a process might cause paragraphs whose language tag matched the language range "nl" (Dutch) to be displayed in italics within a document.
フィルタリングを使用して、ユーザーの好みを一連の言語タグと比較することにより、一連の結果（ドキュメントのコレクションなど）を作成できます。たとえば、検索を実行するときに、フィルタリングを使用して、結果をフランス語であるとタグ付けされたアイテムに制限できます。一部のコンテンツで言語に敏感なプロセスを実行するかどうかを決定する際には、フィルタリングを使用することもできます。たとえば、プロセスにより、言語タグが言語範囲「NL」（オランダ語）と一致する段落がドキュメント内のイタリック体に表示される場合があります。
Lookup produces the single result that best matches the user's preferences from the list of available tags, so it is useful in cases in which a single item is required (and for which only a single item can be returned). For example, if a process were to insert a human-readable error message into a protocol header, it might select the text based on the user's language priority list. Since the process can return only one item, it is forced to choose a single item and it has to return some item, even if none of the content's language tags match the language priority list supplied by the user.
Lookupは、利用可能なタグのリストからユーザーの設定に最適な単一の結果を生成するため、単一のアイテムが必要な場合（および単一のアイテムのみが返される可能性がある場合）に役立ちます。たとえば、プロセスが人間の読み取り可能なエラーメッセージをプロトコルヘッダーに挿入する場合、ユーザーの言語優先順位リストに基づいてテキストを選択する場合があります。プロセスは1つのアイテムのみを返すことができるため、単一のアイテムを選択することを余儀なくされ、コンテンツの言語タグがユーザーが提供する言語優先リストと一致しない場合でも、いくつかのアイテムを返す必要があります。
Language tag matching is a tool, and does not by itself specify a complete procedure for the use of language tags. Such procedures are intimately tied to the application protocol in which they occur. When specifying a protocol operation using matching, the protocol MUST specify:
言語タグマッチングはツールであり、それ自体で言語タグを使用するための完全な手順を指定していません。このような手順は、それらが発生するアプリケーションプロトコルと密接に結びついています。マッチングを使用してプロトコル操作を指定する場合、プロトコルは次のことを指定する必要があります。
o Which type(s) of language tag matching it uses
o 使用する言語タグのどのタイプ
o Whether the operation returns a single result (lookup) or a possibly empty set of results (filtering)
o 操作が単一の結果（ルックアップ）を返すかどうかの結果の結果（フィルタリング）を返すかどうか
o For lookup, what the default item is (or the sequence of operations or configuration information used to determine the default) when no matching tag is found. For instance, a protocol might define the result as failure of the operation, an empty value, returning some protocol defined or implementation defined default, or returning i-default [RFC2277].
o ルックアップの場合、デフォルトのアイテムとは何か（または、一致するタグが見つからないときに、デフォルトを決定するために使用される一連の操作または構成情報）。たとえば、プロトコルは、結果を操作の障害、空の値、いくつかのプロトコルを定義するいくつかのプロトコルまたは実装と定義されたデフォルトを返す、またはi-default [RFC2277]を返すこととして定義する場合があります。
Applications, protocols, and specifications are not required to validate or understand any of the semantics of the language tags or ranges or of the subtags in them, nor do they require access to the IANA Language Subtag Registry (see Section 3 in [RFC4646]). This simplifies implementation.
アプリケーション、プロトコル、および仕様は、言語タグまたは範囲、またはそれらのサブタグのセマンティクスを検証または理解するために必要ではなく、IANA言語サブタグレジストリにアクセスする必要もありません（[RFC4646]のセクション3を参照）。これにより、実装が簡素化されます。
However, designers of applications, protocols, or specifications are encouraged to use the information from the IANA Language Subtag Registry to support canonicalizing language tags and ranges in order to map grandfathered and obsolete tags or subtags into modern equivalents.
ただし、アプリケーション、プロトコル、または仕様の設計者は、IANA言語サブタグレジストリからの情報を使用して、言語のタグと範囲の範囲をサポートして、祖父と時代遅れのタグまたはサブタグを最新の同等物にマッピングすることをお勧めします。
Applications, protocols, or specifications that canonicalize ranges MUST either perform matching operations with both the canonical and original (unmodified) form of the range or MUST also canonicalize each tag for the purposes of comparison.
範囲が正規化するアプリケーション、プロトコル、または仕様は、比較の目的で各タグを正規および元の（変更されていない）形式の両方で一致操作を実行する必要があります。
Note that canonicalizing language ranges makes certain operations impossible. For example, an implementation that canonicalizes the language range "art-lojban" (artificial language, lojban variant) to use the more modern "jbo" (Lojban) cannot be used to select just the items with the older tag.
標準化言語範囲により、特定の操作が不可能になることに注意してください。たとえば、言語範囲「アートロイバン」（人工言語、ロジバンバリアント）を正規化する実装は、より近代的な「JBO」（ロジバン）を使用して、古いタグのあるアイテムのみを選択することはできません。
Applications, protocols, or specifications that use basic ranges might sometimes receive extended language ranges instead. An application, protocol, or specification MUST choose to a) map extended language ranges to basic ranges using the algorithm below, b) reject any extended language ranges in the language priority list that are not valid basic language ranges, or c) treat each extended language range as if it were a basic language range, which will have the same result as ignoring them, since these ranges will not match any valid language tags.
基本範囲を使用するアプリケーション、プロトコル、または仕様は、代わりに拡張言語範囲を受信する場合があります。アプリケーション、プロトコル、または仕様は、a）以下のアルゴリズムを使用して拡張言語範囲を基本範囲にマッピングする必要があります。言語の範囲は基本的な言語範囲であるかのように、これらの範囲は有効な言語タグと一致しないため、それらを無視するのと同じ結果になります。
An extended language range is mapped to a basic language range as follows: if the first subtag is a '*' then the entire range is treated as "*", otherwise each wildcard subtag is removed. For example, the extended language range "en-*-US" maps to "en-US" (English, United States).
拡張言語範囲は次のように基本的な言語範囲にマッピングされます。最初のサブタグが「*」である場合、範囲全体が「*」として扱われます。そうしないと、各ワイルドカードサブタグが削除されます。たとえば、拡張言語範囲「en - * - us」は「en-us」（英語、アメリカ）にマッピングします。
Applications, protocols, or specifications, in addressing their particular requirements, can offer pre-processing or configuration options. For example, an implementation could allow a user to associate or map a particular language range to a different value. Such a user might wish to associate the language range subtags 'nn' (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or perhaps a user would want to associate requests for the range "zh-Hans" (Chinese as written in the Simplified script) with content bearing the language tag "zh-CN" (Chinese as used in China, where the Simplified script is predominant). Documentation on how the ranges or tags are altered, prioritized, or compared in the subsequent match in such an implementation will assist users in making these types of configuration choices.
特定の要件に対処するためのアプリケーション、プロトコル、または仕様は、前処理または構成オプションを提供できます。たとえば、実装により、ユーザーは特定の言語範囲を異なる値に関連付けるか、マッピングできます。このようなユーザーは、言語範囲のサブタグ 'nn'（Nynorsk norwegian）と 'nb'（bokmal norwegian）をより一般的なサブタグ「ノー」（ノルウェー語）に関連付けることを望むかもしれません。または、おそらくユーザーは、「Zh-hans」（単純化されたスクリプトに書かれている中国）の範囲のリクエストを言語タグ「Zh-cn」（中国で使用される中国語、単純化されたスクリプトが支配的なコンテンツと関連付けたいと思うでしょう。）。このような実装での後続の一致で、範囲またはタグがどのように変更されるか、優先順位付けされ、または比較されるかについてのドキュメントは、ユーザーがこれらのタイプの構成の選択をするのに役立ちます。
Filtering is used to select the set of language tags that matches a given language priority list. It is called "filtering" because this set might contain no items at all or it might return an arbitrarily large number of matching items: as many items as match the language priority list, thus "filtering out" the non-matching items.
フィルタリングは、特定の言語の優先順位リストに一致する言語タグのセットを選択するために使用されます。このセットにはまったくアイテムが含まれていないか、任意に多数のマッチングアイテムを返す可能性があるため、「フィルタリング」と呼ばれます。言語優先順位リストと一致するように多くのアイテムが一致するため、非一致アイテムを「フィルタリング」します。
In filtering, each language range represents the least specific language tag (that is, the language tag with fewest number of subtags) that is an acceptable match. All of the language tags in the matching set of tags will have an equal or greater number of subtags than the language range. Every non-wildcard subtag in the language range will appear in every one of the matching language tags. For example, if the language priority list consists of the range "de-CH" (German as used in Switzerland), one might see tags such as "de-CH-1996" (German as used in Switzerland, orthography of 1996) but one will never see a tag such as "de" (because the 'CH' subtag is missing).
フィルタリングでは、各言語範囲は、最も特定の言語タグ（つまり、サブタグの数が最も少ない言語タグ）を表しますが、これは許容可能な一致です。一致するタグセットのすべての言語タグは、言語範囲と等しいまたはそれ以上のサブタグを持っています。言語範囲のすべての非ワイルドカードサブタグは、一致する言語のタグのすべてに表示されます。たとえば、言語優先リストが「de-ch」（スイスで使用されるドイツ語）の範囲で構成されている場合、「de-ch-1996」（1996年のスイスで使用されるドイツ語）などのタグが表示されるかもしれませんが、「de」などのタグが表示されることはありません（「ch」サブタグが欠落しているため）。
If the language priority list (see Section 2.3) contains more than one range, the content returned is typically ordered in descending level of preference, but it MAY be unordered, according to the needs of the application or protocol.
言語の優先順位リスト（セクション2.3を参照）に複数の範囲が含まれている場合、返されるコンテンツは通常、降順レベルの優先レベルで注文されますが、アプリケーションまたはプロトコルのニーズに応じて順序付けられている場合があります。
Some examples of applications where filtering might be appropriate include:
フィルタリングが適切である可能性のあるアプリケーションのいくつかの例は次のとおりです。
o Applying a style to sections of a document in a particular set of languages.
o 特定の言語セットのドキュメントのセクションにスタイルを適用します。
o Displaying the set of documents containing a particular set of keywords written in a specific set of languages.
o 特定の言語セットで記述された特定のキーワードセットを含むドキュメントのセットを表示します。
o Selecting all email items written in a specific set of languages.
o 特定の言語セットで記述されたすべての電子メールアイテムを選択します。
o Selecting audio files spoken in a particular language.
o 特定の言語で話されているオーディオファイルを選択します。
Filtering seems to imply that there is a semantic relationship between language tags that share the same prefix. While this is often the case, it is not always true: the language tags that match a specific language range do not necessarily represent mutually intelligible languages.
フィルタリングは、同じプレフィックスを共有する言語タグ間に意味関係があることを意味しているようです。多くの場合、これはそうですが、常に真実ではありません。特定の言語範囲に一致する言語タグは、必ずしも相互に理解可能な言語を表すとは限りません。
Basic filtering compares basic language ranges to language tags. Each basic language range in the language priority list is considered in turn, according to priority. A language range matches a particular language tag if, in a case-insensitive comparison, it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first character following the prefix is "-". For example, the language-range "de-de" (German as used in Germany) matches the language tag "de-DE-1996" (German as used in Germany, orthography of 1996), but not the language tags "de-Deva" (German as written in the Devanagari script) or "de-Latn-DE" (German, Latin script, as used in Germany).
基本的なフィルタリングは、基本的な言語範囲を言語タグと比較します。優先順位に応じて、言語優先順位リストの各基本言語範囲が順番に考慮されます。言語範囲は、ケースに依存しない比較で、タグに正確に等しい場合、またはタグのプレフィックスに正確に等しい場合、接頭辞に続く最初の文字が「 - 」である場合、特定の言語タグと一致します。たとえば、言語範囲の「de-de」（ドイツで使用されるドイツ語）は、言語タグ「de-de-1996」（ドイツで使用されるドイツ語、1996年の正書法）と一致しますが、言語タグは「de-ではありません。Deva "（Devanagariスクリプトで書かれているドイツ語）または「de-latn-de」（ドイツ語、ラテン語のスクリプト、ドイツで使用される）。
The special range "*" in a language priority list matches any tag. A protocol that uses language ranges MAY specify additional rules about the semantics of "*"; for instance, HTTP/1.1 [RFC2616] specifies that the range "*" matches only languages not matched by any other range within an "Accept-Language" header.
言語優先リストの特別な範囲「*」は、任意のタグと一致します。言語範囲を使用するプロトコルは、「*」のセマンティクスに関する追加のルールを指定する場合があります。たとえば、HTTP/1.1 [RFC2616]は、「*」という範囲が「受け入れ」ヘッダー内の他の範囲と一致しない言語のみを一致させることを指定します。
Basic filtering is identical to the type of matching described in [RFC3066], Section 2.5 (Language-range).
基本的なフィルタリングは、[RFC3066]、セクション2.5（言語範囲）に記載されている一致のタイプと同じです。
Extended filtering compares extended language ranges to language tags. Each extended language range in the language priority list is considered in turn, according to priority. A language range matches a particular language tag if each respective list of subtags matches. To determine a match:
拡張フィルタリングは、拡張言語の範囲を言語タグと比較します。優先度に応じて、言語優先順位リストの各拡張言語範囲が順番に考慮されます。言語範囲は、サブタグのそれぞれのリストが一致する場合、特定の言語タグと一致します。一致を決定するには：
1. Split both the extended language range and the language tag being compared into a list of subtags by dividing on the hyphen (%x2D) character. Two subtags match if either they are the same when compared case-insensitively or the language range's subtag is the wildcard '*'.
1. 拡張言語範囲と、ハイフン（％x2d）文字で分割することにより、サブタグのリストに比較される言語タグの両方を分割します。2つのサブタグが、ケースインセンシタルに比較された場合、または言語範囲のサブタグがワイルドカード「*」である場合に同じである場合に一致します。
2. Begin with the first subtag in each list. If the first subtag in the range does not match the first subtag in the tag, the overall match fails. Otherwise, move to the next subtag in both the range and the tag.
2. 各リストの最初のサブタグから始めます。範囲内の最初のサブタグがタグの最初のサブタグと一致しない場合、全体の一致は失敗します。それ以外の場合は、範囲とタグの両方で次のサブタグに移動します。
3. While there are more subtags left in the language range's list:
3. 言語範囲のリストには、より多くのサブタグが残っていますが、
A. If the subtag currently being examined in the range is the wildcard ('*'), move to the next subtag in the range and continue with the loop.
A.現在範囲で検査中のサブタグがワイルドカード（ '*'）である場合、範囲の次のサブタグに移動し、ループを続けます。
B. Else, if there are no more subtags in the language tag's list, the match fails.
B.それ以外の場合、言語タグのリストにサブタグがもうない場合、一致は失敗します。
C. Else, if the current subtag in the range's list matches the current subtag in the language tag's list, move to the next subtag in both lists and continue with the loop.
C.その他、範囲のリストの現在のサブタグが言語タグのリストの現在のサブタグと一致する場合、両方のリストの次のサブタグに移動し、ループを続行します。
D. Else, if the language tag's subtag is a "singleton" (a single letter or digit, which includes the private-use subtag 'x') the match fails.
D.その他、言語タグのサブタグが「シングルトン」（プライベート使用サブタグ 'x'を含む単一の文字または数字）である場合、試合は失敗します。
E. Else, move to the next subtag in the language tag's list and continue with the loop.
E.その他、言語タグのリストの次のサブタグに移動し、ループを続けます。
4. When the language range's list has no more subtags, the match succeeds.
4. 言語範囲のリストにサブタグがもうない場合、試合は成功します。
Subtags not specified, including those at the end of the language range, are thus treated as if assigned the wildcard value '*'. Much like basic filtering, extended filtering selects content with arbitrarily long tags that share the same initial subtags as the language range. In addition, extended filtering selects language tags that contain any intermediate subtags not specified in the language range. For example, the extended language range "de-*-DE" (or its synonym "de-DE") matches all of the following tags:
したがって、言語範囲の最後にあるものを含む、指定されていないサブタグは、ワイルドカード値「*」を割り当てられているかのように扱われます。基本的なフィルタリングと同じように、拡張フィルタリングは、言語範囲と同じ初期サブタグを共有する任意の長いタグを持つコンテンツを選択します。さらに、拡張フィルタリングは、言語範囲で指定されていない中間サブタグを含む言語タグを選択します。たとえば、拡張言語範囲「de - * - de」（またはその同義語「de-de」）は、次のすべてのタグと一致します。
de-DE (German, as used in Germany)
de-de（ドイツ語、ドイツで使用される）
de-de (German, as used in Germany)
de-de（ドイツ語、ドイツで使用される）
de-Latn-DE (Latin script)
de-latn-de（ラテンスクリプト）
de-Latf-DE (Fraktur variant of Latin script)
de-latf-de（ラテンスクリプトのfrakturバリアント）
de-DE-x-goethe (private-use subtag)
de-de-x-goethe（個人用サブタグ）
de-Latn-DE-1996 (orthography of 1996)
de-latn-de-1996（1996年の正書法）
de-Deva-DE (Devanagari script)
de-deva-de（devanagariスクリプト）
The same range does not match any of the following tags for the reasons shown:
同じ範囲が、示されている理由で次のタグのいずれも一致しません。
de (missing 'DE')
de（ 'de de'がありません）
de-x-DE (singleton 'x' occurs before 'DE')
de-x-de（singleton 'x'は「de」の前に発生します）
de-Deva ('Deva' not equal to 'DE')
de-deva（ 'de'に等しくない 'deva'）
Note: [RFC4646] defines each type of subtag (language, script, region, and so forth) according to position, size, and content. This means that subtags in a language range can only match specific types of subtags in a language tag. For example, a subtag such as 'Latn' is always a script subtag (unless it follows a singleton) while a subtag such as 'nedis' can only match the equivalent variant subtag. Two-letter subtags in the initial position have a different type (language) than two-letter subtags in later positions (region). This is the reason why a wildcard in the extended language range is significant in the first position but is ignored in all other positions.
注：[RFC4646]は、位置、サイズ、コンテンツに従って、各タイプのサブタグ（言語、スクリプト、領域など）を定義します。つまり、言語範囲のサブタグは、言語タグの特定のタイプのサブタグのみを一致させることができます。たとえば、「LATN」などのサブタグは常にスクリプトサブタグ（シングルトンに従っていない限り）ですが、「nedis」などのサブタグは同等のバリアントサブタグのみに一致します。初期位置の2文字のサブタグは、後の位置（領域）の2文字のサブタグとは異なるタイプ（言語）を持っています。これが、拡張言語範囲のワイルドカードが最初の位置で重要であるが、他のすべての位置で無視される理由です。
Lookup is used to select the single language tag that best matches the language priority list for a given request. When performing lookup, each language range in the language priority list is considered in turn, according to priority. By contrast with filtering, each language range represents the most specific tag that is an acceptable match. The first matching tag found, according to the user's priority, is considered the closest match and is the item returned. For example, if the language range is "de-ch", a lookup operation can produce content with the tags "de" or "de-CH" but never content with the tag "de-CH-1996". If no language tag matches the request, the "default" value is returned.
ルックアップは、特定のリクエストの言語優先順位リストに最適な単一言語タグを選択するために使用されます。ルックアップを実行する場合、優先度に応じて、言語優先リストの各言語範囲が順番に考慮されます。フィルタリングとは対照的に、各言語範囲は、許容可能な一致である最も具体的なタグを表します。ユーザーの優先順位に従って見つかった最初のマッチングタグは、最も近い一致と見なされ、返されたアイテムです。たとえば、言語範囲が「de-ch」の場合、ルックアップ操作は、タグ「de」または「de-ch」を使用してコンテンツを生成できますが、タグ「de-ch-1996」にはコンテンツではありません。言語タグがリクエストと一致しない場合、「デフォルト」値が返されます。
For example, if an application inserts some dynamic content into a document, returning an empty string if there is no exact match is not an option. Instead, the application "falls back" until it finds a matching language tag associated with a suitable piece of content to insert. Some applications of lookup include:
たとえば、アプリケーションがいくつかの動的なコンテンツをドキュメントに挿入する場合、正確な一致がない場合は空の文字列を返すことはオプションではありません。代わりに、アプリケーションは、挿入する適切なコンテンツに関連付けられた一致する言語タグが見つかるまで「フォールバック」します。ルックアップのいくつかのアプリケーションには以下が含まれます。
o Selection of a template containing the text for an automated email response.
o 自動化された電子メール応答のテキストを含むテンプレートの選択。
o Selection of an item containing some text for inclusion in a particular Web page.
o 特定のWebページに含めるためのテキストを含むアイテムの選択。
o Selection of a string of text for inclusion in an error log.
o エラーログに含めるための一連のテキストの選択。
o Selection of an audio file to play as a prompt in a phone system.
o 電話システムでプロンプトとして再生するオーディオファイルの選択。
In the lookup scheme, the language range is progressively truncated from the end until a matching language tag is located. Single letter or digit subtags (including both the letter 'x', which introduces private-use sequences, and the subtags that introduce extensions) are removed at the same time as their closest trailing subtag. For example, starting with the range "zh-Hant-CN-x-private1-private2" (Chinese, Traditional script, China, two private-use tags) the lookup progressively searches for content as shown below:
ルックアップスキームでは、言語範囲は、一致する言語タグが配置されるまで、端から徐々に切り捨てられます。単一の文字または数字のサブタグ（プライベート使用シーケンスを導入する文字「x '」と、拡張機能を導入するサブタグの両方を含む）は、最も近い後続のサブタグと同時に削除されます。たとえば、「Zh-Hant-CN-X-Private1-Private2」（中国、伝統的なスクリプト、中国、2つの個人用タグ）から始めると、以下に示すようにルックアップがコンテンツを徐々に検索します。
Example of a Lookup Fallback Pattern
ルックアップフォールバックパターンの例
Range to match: zh-Hant-CN-x-private1-private2 1. zh-Hant-CN-x-private1-private2 2. zh-Hant-CN-x-private1 3. zh-Hant-CN 4. zh-Hant 5. zh 6. (default) This fallback behavior allows some flexibility in finding a match. Without fallback, the default content would be returned immediately if exactly matching content is unavailable. With fallback, a result more closely matching the user request can be provided.
一致する範囲：Zh-Hant-CN-X-Private1-Private2 1. Zh-Hant-Cn-X-Private1-Private2 2. Zh-Hant-Cn-X-Private1 3. Zh-Hant-CN 4. Zh-HANT 5. ZH 6.（デフォルト）このフォールバック動作により、一致を見つける柔軟性が可能になります。フォールバックがなければ、正確に一致するコンテンツが利用できない場合、デフォルトのコンテンツはすぐに返されます。フォールバックを使用すると、ユーザーリクエストをより密接に一致させる結果を提供できます。
Extensions and unrecognized private-use subtags might be unrelated to a particular application of lookup. Since these subtags come at the end of the subtag sequence, they are removed first during the fallback process and usually pose no barrier to interoperability. However, an implementation MAY remove these from ranges prior to performing the lookup (provided the implementation also removes them from the tags being compared). Such modification is internal to the implementation and applications, protocols, or specifications SHOULD NOT remove or modify subtags in content that they return or forward, because this removes information that can be used elsewhere.
拡張機能と認識されていない個人用サブタグは、ルックアップの特定のアプリケーションとは無関係かもしれません。これらのサブタグはサブタグシーケンスの終わりに来るため、フォールバックプロセス中に最初に削除され、通常は相互運用性の障壁を引き起こしません。ただし、実装では、ルックアップを実行する前に実装が範囲から削除される場合があります（実装が比較対象のタグからもそれらを削除すると）。このような変更は、実装およびアプリケーション、プロトコル、または仕様の内部であり、他の場所で使用できる情報を削除するため、返品または転送のコンテンツのサブタグを削除または変更してはなりません。
The special language range "*" matches any language tag. In the lookup scheme, this range does not convey enough information by itself to determine which language tag is most appropriate, since it matches everything. If the language range "*" is followed by other language ranges, it is skipped. If the language range "*" is the only one in the language priority list or if no other language range follows, the default value is computed and returned.
特別な言語範囲「*」は、任意の言語タグと一致します。ルックアップスキームでは、この範囲は、すべてに一致するため、どの言語タグが最も適切であるかを決定するのに十分な情報を単独で伝えません。言語範囲「*」の後に他の言語範囲が続くと、スキップされます。言語範囲「*」が言語優先順位リストの唯一のものである場合、または他の言語範囲が続く場合は、デフォルト値が計算されて返されます。
In some cases, the language priority list can contain one or more extended language ranges (as, for example, when the same language priority list is used as input for both lookup and filtering operations). Wildcard values in an extended language range normally match any value that can occur in that position in a language tag. Since only one item can be returned for any given lookup request, wildcards in a language range have to be processed in a consistent manner or the same request will produce widely varying results. Applications, protocols, or specifications that accept extended language ranges MUST define which item is returned when more than one item matches the extended language range.
場合によっては、言語の優先順位リストには、1つ以上の拡張言語範囲を含めることができます（たとえば、同じ言語優先順位リストがルックアップ操作とフィルタリング操作の両方の入力として使用される場合）。拡張言語範囲のワイルドカード値は通常、言語タグでその位置で発生する可能性のある値と一致します。特定のルックアップリクエストに対して1つのアイテムのみを返すことができるため、言語範囲のワイルドカードを一貫した方法で処理する必要があるか、同じリクエストが大きく異なる結果を生成する必要があります。拡張言語範囲を受け入れるアプリケーション、プロトコル、または仕様は、複数のアイテムが拡張言語範囲と一致するときに返されるアイテムを定義する必要があります。
For example, an implementation could map the extended language ranges to basic ranges. Another possibility would be for an implementation to return the matching tag that is first in ASCII-order. If the language range were "*-CH" ('CH' represents Switzerland) and the set of tags included "de-CH" (German as used in Switzerland), "fr-CH" (French, Switzerland), and "it-CH" (Italian, Switzerland), then the tag "de-CH" would be returned.
たとえば、実装では、拡張言語範囲を基本範囲にマッピングできます。別の可能性は、実装がAscii-Orderで最初のマッチングタグを返すことです。言語範囲が「*-ch」（「ch」がスイスを表す）であり、「de-ch」（スイスで使用されるドイツ語）、「fr-ch」（フランス語、スイス）、および「それを含むタグのセットが含まれている場合-ch "（イタリア語、スイス）、タグ「de-ch」が返されます。
Each application, protocol, or specification that uses lookup MUST define the defaulting behavior when no tag matches the language priority list. What this action consists of strongly depends on how lookup is being applied. Some examples of defaulting behavior include:
ルックアップを使用する各アプリケーション、プロトコル、または仕様は、言語の優先度リストと一致しないタグがない場合、デフォルトの動作を定義する必要があります。このアクションが構成するものは、ルックアップがどのように適用されているかに大きく依存します。デフォルトの動作のいくつかの例は次のとおりです。
o return an item with no language tag or an item of a non-linguistic nature, such as an image or sound
o 言語タグのないアイテムや、画像や音などの非言語的性質のアイテムを返します
o return a null string as the language tag value, in cases where the protocol permits the empty value (see, for example, "xml:lang" in [XML10])
o null文字列を言語タグ値として返します。プロトコルが空の値を許可する場合（たとえば、[xml10]の「xml：lang」を参照）
o return a particular language tag designated for the operation
o 操作用に指定された特定の言語タグを返します
o return the language tag "i-default" (see [RFC2277])
o 言語タグ「i-default」を返します（[rfc2277]を参照）
o return an error condition or error message
o エラー条件またはエラーメッセージを返します
o return a list of available languages for the user to select from
o ユーザーが選択できるように利用可能な言語のリストを返してください
When performing lookup using a language priority list, the progressive search MUST process each language range in the list before seeking or calculating the default.
言語優先リストを使用してルックアップを実行する場合、プログレッシブ検索では、デフォルトを探すか計算する前に、リスト内の各言語範囲を処理する必要があります。
The default value MAY be calculated or include additional searching or matching. Applications, protocols, or specifications can specify different ways in which users can specify or override the defaults.
デフォルト値を計算するか、追加の検索またはマッチングを含めることができます。アプリケーション、プロトコル、または仕様は、ユーザーがデフォルトを指定またはオーバーライドできるさまざまな方法を指定できます。
One common way to provide for a default is to allow a specific language range to be set as the default for a specific type of request. If this approach is chosen, this language range MUST be treated as if it were appended to the end of the language priority list as a whole, rather than after each item in the language priority list. The application, protocol, or specification MUST also define the defaulting behavior if that search fails to find a matching tag or item.
デフォルトを提供する一般的な方法の1つは、特定のタイプのリクエストのデフォルトとして特定の言語範囲を設定できるようにすることです。このアプローチが選択されている場合、この言語範囲は、言語優先順位リストの各項目の後ではなく、言語優先リスト全体の最後に追加されたかのように扱わなければなりません。アプリケーション、プロトコル、または仕様は、その検索が一致するタグまたはアイテムを見つけられない場合、デフォルトの動作を定義する必要があります。
For example, if a particular user's language priority list is "fr-FR, zh-Hant" (French as used in France followed by Chinese as written in the Traditional script) and the program doing the matching had a default language range of "ja-JP" (Japanese as used in Japan), then the program searches as follows: 1. fr-FR 2. fr 3. zh-Hant // next language 4. zh 5. ja-JP // now searching for the default content 6. ja 7. (implementation defined default)
たとえば、特定のユーザーの言語の優先リストが「FR-FR、ZH-HANT」（フランスで使用されるフランスのフランスの後に、従来のスクリプトで書かれた中国語）の場合、マッチングを行うプログラムのデフォルト言語範囲は「JAのデフォルト言語範囲がありました。-jp "（日本で使用される日本）、次にプログラムは次のように検索します：1。fr-fr 2. fr 3. zh-hant //次の言語4. zh 5. ja-jp //デフォルトを検索していますコンテンツ6. JA 7.（実装が定義されたデフォルト）
When working with language ranges and matching schemes, there are some additional points that can influence the choice of either.
言語の範囲と一致するスキームを使用する場合、どちらの選択に影響を与える可能性のある追加のポイントがあります。
Users indicate their language preferences via the choice of a language range or the list of language ranges in a language priority list. The type of matching affects what the best choice is for a user.
ユーザーは、言語範囲の選択または言語の優先順位リストの範囲を選択して、言語の好みを示します。マッチングの種類は、ユーザーにとって最良の選択に影響します。
Most matching schemes make no attempt to process the semantic meaning of the subtags. The language range is compared, in a case-insensitive manner, to each language tag being matched, using basic string processing. Users SHOULD select language ranges that are well-formed, valid language tags according to [RFC4646] (substituting wildcards as appropriate in extended language ranges).
ほとんどの一致するスキームは、サブタグの意味的な意味を処理しようとはしません。言語範囲は、基本的な文字列処理を使用して、一致している各言語タグと、ケースに依存しない方法で比較されます。ユーザーは、[RFC4646]（拡張言語の範囲で適切にワイルドカードを置き換える）に従って、適切に形成された有効な言語タグの言語範囲を選択する必要があります。
Applications are encouraged to canonicalize language tags and ranges by using the Preferred-Value from the IANA Language Subtag Registry for tags or subtags that have been deprecated. If the user is working with content that might use the older form, the user might want to include both the new and old forms in a language priority list. For example, the tag "art-lojban" is deprecated. The subtag 'jbo' is supposed to be used instead, so the user might use it to form the language range. Or the user might include both in a language priority list: "jbo, art-lojban".
アプリケーションは、IANA言語サブタグレジストリからの優先値を使用して、廃止されたタグまたはサブタグを使用して、言語タグと範囲を正規化することをお勧めします。ユーザーが古いフォームを使用する可能性のあるコンテンツを使用している場合、ユーザーは、新しいフォームと古いフォームの両方を言語優先リストに含めたい場合があります。たとえば、タグ「Art-Lojban」は非推奨です。サブタグ「JBO」は代わりに使用されることになっているため、ユーザーはそれを使用して言語範囲を形成する場合があります。または、ユーザーは、言語の優先順位リストの両方に「JBO、Art-Lojban」を含めることができます。
Users SHOULD avoid subtags that add no distinguishing value to a language range. When filtering, the fewer the number of subtags that appear in the language range, the more content the range will probably match, while in lookup unnecessary subtags can cause "better", more-specific content to be skipped in favor of less specific content. For example, the range "de-Latn-DE" returns content tagged "de" instead of content tagged "de-DE", even though the latter is probably a better match.
ユーザーは、言語範囲に識別値を追加しないサブタグを避ける必要があります。フィルタリングすると、言語範囲に表示されるサブタグの数が少ないほど、コンテンツがより多く範囲が一致しますが、不要なサブタグが「より良い」、より特定のコンテンツを、特定のコンテンツを支持してスキップする可能性があります。たとえば、「de-latn-de」の範囲は、「de-de」というタグ付けされたコンテンツの代わりに「de」というタグ付けされたコンテンツを返しますが、後者はおそらくより良い一致です。
Whether a subtag adds distinguishing value can depend on the context of the request. For example, a user who reads both Simplified and Traditional Chinese, but who prefers Simplified, might use the range "zh" for filtering (matching all items that user can read) but "zh-Hans" for lookup (making sure that user gets the preferred form if it's available, but the fallback to "zh" will still work). On the other hand, content in this case ought to be labeled as "zh-Hans" (or "zh-Hant" if that applies) for filtering, while for lookup, if there is either "zh-Hans" content or "zh-Hant" content, one of them (the one considered 'default') also ought to be made available with the simple "zh". Note that the user can create a language priority list "zh-Hans, zh" that delivers the best possible results for both schemes. If the user cannot be sure which scheme is being used (or if more than one might be applied to a given request), the user SHOULD specify the most specific (largest number of subtags) range first and then supply shorter prefixes later in the list to ensure that filtering returns a complete set of tags.
サブタグが識別値を追加するかどうかは、リクエストのコンテキストに依存する可能性があります。たとえば、単純化された中国人と伝統的な中国語の両方を読み取るが、簡素化されたユーザーは、フィルタリングに「ZH」の範囲を使用する可能性があります（ユーザーが読むことができるすべてのアイテムを一致させる）が、「Zh-hans」を探して（ユーザーが取得することを確認するために」利用可能な場合は優先フォームですが、「Zh」へのフォールバックは引き続き機能します）。一方、この場合のコンテンツは、フィルタリングのために「Zh-hans」（またはそれが適用される場合は「Zh-hant」）としてラベル付けする必要がありますが、「Zh-hans」コンテンツまたは「Zhのいずれかがある場合は、検索用にラベル付けする必要があります。-hant "コンテンツ、そのうちの1つ（「デフォルト」と見なされるもの）も、単純な「Zh」で利用できるようにする必要があります。ユーザーは、両方のスキームに可能な限り最良の結果を提供する言語優先リスト「Zh-hans、Zh」を作成できることに注意してください。ユーザーがどのスキームが使用されているかを確認できない場合（または特定のリクエストに複数のスキームを適用できる場合）、ユーザーは最初に最も特定の（最大数のサブタグ）範囲を指定し、次にリストの後半で短いプレフィックスを提供する必要があります。フィルタリングがタグの完全なセットを返すようにします。
Many languages are written predominantly in a single script. This is usually recorded in the Suppress-Script field in that language subtag's registry entry. For these languages, script subtags SHOULD NOT be used to form a language range. Thus, the language range "en-Latn" is inappropriate in most cases (because the vast majority of English documents are written in the Latin script and thus the 'en' language subtag has a Suppress-Script field for 'Latn' in the registry).
多くの言語は、主に単一のスクリプトで書かれています。これは通常、その言語SubtagのレジストリエントリのSuppressScriptフィールドに記録されます。これらの言語では、スクリプトサブタグを使用して言語範囲を形成しないでください。したがって、言語範囲「en-latn」はほとんどの場合に不適切です（英語の文書の大部分がラテン語のスクリプトに記述されているため、「en」という言語サブタグには、レジストリの「latn」の抑制スクリプトフィールドがあります。）。
When working with tags and ranges, note that extensions and most private-use subtags are orthogonal to language tag matching, in that they specify additional attributes of the text not related to the goals of most matching schemes. Users SHOULD avoid using these subtags in language ranges, since they interfere with the selection of available content. When used in language tags (as opposed to ranges), these subtags normally do not interfere with filtering (Section 3), since they appear at the end of the tag and will match all prefixes. Lookup (Section 3.4) implementations are advised to ignore unrecognized private-use and extension subtags when performing language tag fallback.
タグと範囲を使用する場合、拡張機能とほとんどのプライベート使用サブタグは、ほとんどのマッチングスキームの目標に関連しないテキストの追加属性を指定するという点で、言語タグマッチングに直交することに注意してください。ユーザーは、利用可能なコンテンツの選択を妨げるため、言語範囲でこれらのサブタグを使用することを避ける必要があります。言語タグで（範囲とは対照的に）使用する場合、これらのサブタグは通常、フィルタリングを妨害しません（セクション3）。タグの最後に表示され、すべてのプレフィックスと一致します。ルックアップ（セクション3.4）の実装は、言語タグフォールバックを実行する際に、認識されていないプライベート使用および拡張サブタグを無視することをお勧めします。
Selecting language tags using language ranges requires some understanding by users of what they are selecting. The meanings of the various subtags in a language range are identical to their meanings in a language tag (see Section 4.2 in [RFC4646]), with the addition that the wildcard "*" represents any matching sequence of values.
言語範囲を使用して言語タグを選択するには、選択しているユーザーの理解が必要です。言語範囲のさまざまなサブタグの意味は、言語タグの意味と同じです（[RFC4646]のセクション4.2を参照）、ワイルドカード「*」は値の一致シーケンスを表します。
Private agreement is necessary between the parties that intend to use or exchange language tags that contain private-use subtags. Great caution SHOULD be used in employing private-use subtags 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. Matching private-use tags using language ranges or extended language ranges can result in unpredictable content being returned.
プライベート使用タグとそのような言語タグ内で使用されるサブタグの値とセマンティックな意味は定義されていません。言語範囲または拡張言語範囲を使用したプライベート使用タグを一致させると、予測不可能なコンテンツが返される可能性があります。
Language ranges are very similar to language tags in terms of content and usage. The same types of restrictions on length that can be applied to language tags can also be applied to language ranges. See [RFC4646] Section 4.3 (Length Considerations).
言語範囲は、コンテンツと使用法の観点から言語タグに非常に似ています。言語タグに適用できる長さの同じタイプの制限も、言語範囲に適用できます。[RFC4646]セクション4.3（長さの考慮事項）を参照してください。
Language ranges used in content negotiation might be used to infer the nationality of the sender, and thus identify potential targets for surveillance. In addition, unique or highly unusual language ranges or combinations of language ranges might be used to track a specific individual's activities.
コンテンツネゴシエーションで使用される言語範囲は、送信者の国籍を推測するために使用される場合があり、したがって、監視の潜在的なターゲットを特定します。さらに、特定の個人の活動を追跡するために、一意または非常に珍しい言語範囲または言語範囲の組み合わせが使用される場合があります。
This is a special case of the general problem that anything you send is visible to the receiving party. 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 or protocol.
脅威の正確な大きさと可能な対策の評価は、各アプリケーションまたはプロトコルに残されます。
Language tags permit only the characters A-Z, a-z, 0-9, and HYPHEN-MINUS (%x2D). Language ranges also use the character ASTERISK (%x2A). These characters are present in most character sets, so presentation or exchange of language tags or ranges should not be constrained by character set issues.
言語タグは、文字A-Z、A-Z、0-9、およびハイフン - マイナス（％x2d）のみを許可します。言語範囲は、文字アスタリスク（％x2a）も使用します。これらの文字はほとんどの文字セットに存在するため、言語タグまたは範囲のプレゼンテーションや交換は、文字セットの問題によって制約されるべきではありません。
[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月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[RFC4646] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[RFC4646] Phillips、A.、ed。、およびM. Davis編、「言語を識別するためのタグ」、BCP 47、RFC 4646、2006年9月。
[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC1766] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、1995年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2616errata] IETF, "HTTP/1.1 Specification Errata", October 2004, <http://purl.org/NET/http-errata>.
[rfc2616erata] ietf、 "http/1.1仕様errata"、2004年10月、<http://purl.org/net/http-errata>。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[RFC3282] Alvestrand、H。、「コンテンツ言語ヘッダー」、RFC 3282、2002年5月。
[XML10] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium Recommendation, February 2004, <http://www.w3.org/TR/REC-xml>.
[XML10] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C.、Maler、E。、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第3版）」、World Wide Web Consortiumの推奨、2004年2月、<http://www.w3.org/tr/rec-xml>。
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 [RFC1766] and [RFC3066], each of which was a precursor to this document, contributed greatly to the development of language tag matching, and, in particular, the basic language range and the basic matching scheme. This document was originally part of [RFC4646], but was split off before that document's completion. Thus, directly or indirectly, those acknowledged in [RFC4646] also had a hand in the development of this document, and work done prior to the split is acknowledged in that document.
[RFC1766]および[RFC3066]への貢献者は、それぞれがこのドキュメントの前兆であり、言語タグマッチングの開発、特に基本的な言語範囲と基本マッチングスキームの開発に大きく貢献しました。このドキュメントはもともと[RFC4646]の一部でしたが、そのドキュメントの完了の前に分割されました。したがって、直接的または間接的に、[RFC4646]で認められている人もこのドキュメントの開発に手をかけ、分割前に行われた作業はその文書で認められています。
The following people (in alphabetical order by family name) contributed to this document:
次の人々（姓によるアルファベット順の順序で）がこの文書に貢献しました。
Harald Alvestrand, Stephane Bortzmeyer, Jeremy Carroll, Peter Constable, John Cowan, Mark Crispin, Martin Duerst, Frank Ellermann, Doug Ewell, Debbie Garside, Marion Gunn, Jon Hanna, Kent Karlsson, Erkki Kolehmainen, Jukka Korpela, Ira McDonald, M. Patton, Randy Presuhn, Eric van der Poel, Markus Scherer, Misha Wolf, and many, many others.
ハラルド・アルベスランド、ステファン・ボルツマイヤー、ジェレミー・キャロル、ピーター・コンスタブル、ジョン・コーワン、マーク・クリスピン、マーティン・デュエルスト、フランク・エラーマン、ダグ・イーウェル、デビー・ガーサイド、マリオン・ガン、ジョン・ハンナ、ケント・カールソン、エルッキ・コレハネン、ジュッカ・コルペラ、イラ・マクドナルド、パットン、ランディ・プレスン、エリック・ファン・デル・プエル、マルクス・シェラー、ミーシャ・ウルフ、その他多くの多く。
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.
RFCS 1766と3066を生み出したHarald Tveit Alvestrandに非常に感謝しなければなりません。この文書は不可能でした。
Authors' Addresses
著者のアドレス
Addison Phillips (Editor) Yahoo! Inc.
Addison Phillips（編集者）Yahoo!Inc.
EMail: addison@inter-locale.com
Mark Davis (Editor) Google
マーク・デイビス（編集者）Google
EMail: mark.davis@macchiato.com or mark.davis@google.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。