[要約] RFC 3282は、コンテンツ言語ヘッダーに関するガイドラインを提供するものであり、主な目的は、ウェブコンテンツの言語を正確に識別し、ユーザーエクスペリエンスを向上させることです。
Network Working Group H. Alvestrand
Request for Comments: 3282 Cisco Systems
Obsoletes: 1766 May 2002
Category: Standards Track
Content Language Headers
コンテンツ言語ヘッダー
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language.
このドキュメントでは、「コンテンツ言語：」ヘッダー、マイムボディパートやWebドキュメントなどのRFC 822のようなヘッダーを備えたものの言語を示すことを望んでいる場合に使用するために、「accept-language：」ヘッダーを定義します。言語に関して自分の好みを示したい場合に使用するために。
There are a number of languages presently or previously used by human beings in this world.
現在、この世界には人間が以前に使用していた多くの言語があります。
A great number of these people would prefer to have information presented in a language which they understand.
これらの人々の多くは、彼らが理解している言語で提示された情報を持っていることを好むでしょう。
In some contexts, it is possible to have information available in more than one language, or it might be possible to provide tools (such as dictionaries) to assist in the understanding of a language.
一部のコンテキストでは、複数の言語で情報を利用できるようにすることができます。または、言語の理解を支援するためにツール（辞書など）を提供することが可能です。
In other cases, it may be desirable to use a computer program to convert information from one format (such as plaintext) into another (such as computer-synthesized speech, or Braille, or high-quality print renderings).
他のケースでは、コンピュータープログラムを使用して、ある形式（プレーンテキストなど）から情報を別の形式（コンピューターシンセイドスピーチ、点字、高品質の印刷レンダリングなど）に変換することが望ましい場合があります。
A prerequisite for any such function is a means of labelling the information content with an identifier for the language that is used in this information content, such as is defined by [TAGS]. This document specifies a protocol element for use with protocols that use RFC 822-like headers for carrying language tags as defined in [TAGS].
そのような関数の前提条件は、[タグ]で定義されているような、この情報コンテンツで使用される言語の識別子に情報コンテンツをラベル付けする手段です。このドキュメントは、[タグ]で定義されているように言語タグを運ぶためにRFC 822のようなヘッダーを使用するプロトコルで使用するプロトコル要素を指定します。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" not "、" becommented "、" "、" optional "は、[RFC 2119]で説明されているように解釈されます。
The "Content-Language" header is intended for use in the case where one desires to indicate the language(s) of something that has RFC 822-like headers, such as MIME body parts or Web documents.
「Content-Language」ヘッダーは、Mimeの身体部分やWebドキュメントなど、RFC 822のようなヘッダーを持つものの言語を示すことを望んでいる場合に使用することを目的としています。
The RFC 822 EBNF of the Content-Language header is:
コンテンツ言語ヘッダーのRFC 822 EBNFは次のとおりです。
Content-Language = "Content-Language" ":" 1#Language-tag
In the more strict RFC 2234 ABNF:
より厳格なRFC 2234 ABNF：
Content-Language = "Content-Language" ":" [CFWS] Language-List
Language-List = Language-Tag [CFWS]
*("," [CFWS] Language-Tag [CFWS])
The Content-Language header may list several languages in a comma-separated list.
コンテンツ言語ヘッダーは、コンマ分離リストにいくつかの言語をリストする場合があります。
The CFWS construct is intended to function like the whitespace convention in RFC 822, which means also that one can place parenthesized comments anywhere in the language sequence, or use continuation lines. A formal definition is given in RFC 2822 [RFC2822].
CFWSコンストラクトは、RFC 822のWhitespace Conventionのように機能することを目的としています。つまり、言語シーケンスのどこにでも括弧付きのコメントを配置したり、継続ラインを使用したりすることもできます。RFC 2822 [RFC2822]に正式な定義が示されています。
In keeping with the tradition of RFC 2822, a more liberal "obsolete" grammar is also given:
RFC 2822の伝統に沿って、よりリベラルな「時代遅れの」文法も与えられています。
obs-content-language = "Content-Language" *WSP ":" [CFWS] Language-List
obsontent-language = "content-language" *wsp "：" [cfws]言語リスト
Like RFC 2822, this specification says that conforming implementations MUST accept the obs-content-language syntax, but MUST NOT generate it; all generated headers MUST conform to the Content-Language syntax.
RFC 2822と同様に、この仕様によると、適合実装はobsontent-content-languageの構文を受け入れる必要がありますが、生成してはなりません。生成されたすべてのヘッダーは、コンテンツ言語の構文に準拠する必要があります。
Voice recording from Liverpool downtown
ダウンタウンのリバプールからの音声録音
Content-type: audio/basic Content-Language: en-scouse
コンテンツタイプ：オーディオ/基本的なコンテンツ言語：en-scouse
Document in Mingo, an American Indian language which does not have an ISO 639 code:
ISO 639コードを持っていないアメリカインディアンの言語であるミンゴのドキュメント：
Content-type: text/plain Content-Language: i-mingo
コンテンツタイプ：テキスト/プレーンコンテンツ言語：i-mingo
A English-French dictionary
英語とフランスの辞書
Content-type: application/dictionary Content-Language: en, fr (This is a dictionary)
コンテンツタイプ：アプリケーション/辞書コンテンツランガージ：en、fr（これは辞書です）
An official European Commission document (in a few of its official languages):
公式欧州委員会の文書（その公用語のいくつか）：
Content-type: multipart/alternative Content-Language: da, de, el, en, fr, it
コンテンツタイプ：MultiPart/代替コンテンツ言語：DA、DE、EL、EN、FR、IT
An excerpt from Star Trek
スタートレックからの抜粋
Content-type: video/mpeg Content-Language: i-klingon
コンテンツタイプ：ビデオ/MPEGコンテンツランガージ：i-Klingon
The "Accept-Language" header is intended for use in cases where a user or a process desires to identify the preferred language(s) when RFC 822-like headers, such as MIME body parts or Web documents, are used.
「Accept-Language」ヘッダーは、ユーザーまたはプロセスが、Mime Body PartsやWebドキュメントなどのRFC 822のようなヘッダーが使用される場合に優先言語を識別したい場合に使用することを目的としています。
The RFC 822 EBNF of the Accept-Language header is:
Accept-LanguageヘッダーのRFC 822 EBNFは次のとおりです。
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
A slightly more restrictive RFC 2234 ABNF definition is:
わずかに制限的なRFC 2234 ABNF定義は次のとおりです。
Accept-Language = "Accept-Language:" [CFWS] language-q
*( "," [CFWS] language-q )
language-q = language-range [";" [CFWS] "q=" qvalue ] [CFWS]
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
A more liberal RFC 2234 ABNF definition is:
よりリベラルなRFC 2234 ABNF定義は次のとおりです。
Obs-accept-language = "Accept-Language" *WSP ":" [CFWS]
obs-language-q *( "," [CFWS] obs-language-q ) [CFWS]
obs-language-q = language-range
[ [CFWS] ";" [CFWS] "q" [CFWS] "=" qvalue ]
Like RFC 2822, this specification says that conforming implementations MUST accept the obs-accept-language syntax, but MUST NOT generate it; all generated messages MUST conform to the Accept-Language syntax.
RFC 2822と同様に、この仕様によると、適合実装はobs-Accept-Languageの構文を受け入れる必要がありますが、生成してはなりません。生成されたすべてのメッセージは、承認言語構文に適合する必要があります。
The syntax and semantics of language-range is defined in [TAGS]. The Accept-Language header may list several language-ranges in a comma-separated list, and each may include a quality value Q. If no Q values are given, the language-ranges are given in priority order, with the leftmost language-range being the most preferred language; this is an extension to the HTTP/1.1 rules, but matches current practice.
言語範囲の構文とセマンティクスは、[タグ]で定義されています。Accept-Languageヘッダーは、コンマ分離リストにいくつかの言語範囲をリストする場合があり、それぞれに品質値Qが含まれる場合があります。Q値が与えられない場合、言語範囲は優先順位で与えられ、左端の言語範囲で与えられます最も好ましい言語であること。これは、HTTP/1.1ルールの拡張機能ですが、現在の実践と一致しています。
If Q values are given, refer to HTTP/1.1 [RFC 2616] for the details on how to evaluate it.
Q値が指定されている場合は、評価方法の詳細については、HTTP/1.1 [RFC 2616]を参照してください。
The only security issue that has been raised with language tags since the publication of RFC 1766, which stated that "Security issues are believed to be irrelevant to this memo", is a concern with language ranges used in content negotiation - that they may be used to infer the nationality of the sender, and thus identify potential targets for surveillance.
「セキュリティの問題はこのメモとは無関係であると考えられている」と述べたRFC 1766の公開以来、言語タグで提起された唯一のセキュリティの問題は、コンテンツネゴシエーションで使用される言語範囲の懸念である - それらは使用される可能性があるということです。送信者の国籍を推測し、したがって、監視の潜在的な目標を特定する。
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 exact magnitude of the threat, and any possible countermeasures, is left to each application protocol.
脅威の正確な大きさ、および可能な対策は、各アプリケーションプロトコルに残されます。
This document adds no new considerations beyond what is mentioned in [TAGS].
このドキュメントは、[タグ]で言及されているもの以外に新しい考慮事項を追加しません。
This document has benefited from many rounds of review and comments in various fora of the IETF and the Internet working groups.
このドキュメントは、IETFおよびインターネットワーキンググループのさまざまなフォーラでの多くのラウンドとコメントの恩恵を受けています。
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.
貢献者のリストは不完全であると拘束されます。以下は、この文書を今日のものにするために貢献した人々のグループからの選択のみと考えてください。
In alphabetical order:
アルファベット順：
Tim Berners-Lee, Nathaniel Borenstein, Sean M. Burke, John Clews, Jim Conklin, John Cowan, Dave Crocker, Martin Duerst, Michael Everson, Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, Paul Hoffman, Olle Jarnefors, John Klensin, Bruce Lilly, Keith Moore, Chris Newman, Masataka Ohta, Keld Jorn Simonsen, Rhys Weatherley, Misha Wolf, Francois Yergeau and many, many others.
ティム・バーナーズ・リー、ナサニエル・ボレンシュタイン、ショーン・M・バーク、ジョン・クレウズ、ジム・コンクリン、ジョン・コーワン、デイブ・クロッカー、マーティン・ドゥースト、マイケル・エバーソン、ネッド・フリード、ティム・グッドウィン、ダーク・ウィレム・ヴァン・グリク、マリオン・ガン、ポール・ホフマン、オレJarnefors、John Klensin、Bruce Lilly、Keith Moore、Chris Newman、Masataka Ohta、Keld Jorn Simonsen、Rhys Weatherley、Misha Wolf、Francois Yergeauなど。
Special thanks must go to Michael Everson, who has served as language tag reviewer for almost the entire period, since the publication of RFC 1766, and has provided a great deal of input to this revision. Bruce Lilly did a special job of reading and commenting on my ABNF definitions.
RFC 1766の出版以来、ほぼ全体で言語タグレビューアを務めてきたマイケルエバーソンに特別に感謝しなければならず、この改訂に多大な情報を提供してきました。ブルース・リリーは、私のABNFの定義について読んでコメントするという特別な仕事をしました。
[TAGS] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066
[タグ] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066
[ISO 639] ISO 639:1988 (E/F) - Code for the representation of names of languages - The International Organization for Standardization, 1st edition, 1988-04-01 Prepared by ISO/TC 37 - Terminology (principles and coordination). Note that a new version (ISO 639-1:2000) is in preparation at the time of this writing.
[ISO 639] ISO 639：1988（E/F） - 言語名の表現のためのコード - 国際標準化機関、第1版、1988-04-01 ISO/TC 37-用語（原則と調整）。この執筆時点で、新しいバージョン（ISO 639-1：2000）が準備中であることに注意してください。
[ISO 639-2] ISO 639-2:1998 - Codes for the representation of names of
languages -- Part 2: Alpha-3 code - edition 1, 1998-11-
01, 66 pages, prepared by ISO/TC 37/SC 2
[ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of names of countries - The International Organization for Standardization, 3rd edition, 1988-08-15.
[ISO 3166] ISO 3166：1988（E/F） - 国の名前の表現のためのコード - 国際標準化機関、第3版、1988-08-15。
[ISO 15924] ISO/DIS 15924 - Codes for the representation of names of scripts (under development by ISO TC46/SC2)
[ISO 15924] ISO/DIS 15924-スクリプトの名前の表現のためのコード（ISO TC46/SC2による開発中）
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC 2045] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC 2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC 2046] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC 2047]ムーア、K。、「MIME（多目的インターネットメール拡張）パート3：ASSASCII以外のテキスト用のメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
[RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[RFC 2048] Freed、N.、Klensin、J。およびJ. Postel、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、RFC 2048、1996年11月。
[RFC 2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC 2049] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC 2234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[RFC 2616] 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.
[RFC 2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「Hypertext Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC 2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC 2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
Appendix A: Changes from RFC 1766
付録A：RFC 1766からの変更
The definition of the language tags has been split, and is now RFC 3066. The differences parameter to multipart/alternative is no longer part of this standard, because no implementations of the function were ever found. Consult RFC 1766 if you need the information.
言語タグの定義は分割されており、現在はRFC 3066です。マルチパート/代替の差異パラメーターは、関数の実装が見つからなかったため、この標準の一部ではなくなりました。情報が必要な場合は、RFC 1766に相談してください。
The ABNF for content-language has been updated to use the RFC 2234 ABNF.
コンテンツ言語のABNFは、RFC 2234 ABNFを使用するように更新されました。
Author's Address
著者の連絡先
Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 7043 Trondheim NORWAY
Harald Tveit Alvestrand Cisco Systems Weidemanns Vei 27 7043 Trondheim Norway
EMail: Harald@Alvestrand.no
Phone: +47 73 50 33 52
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。