RFC1766 日本語訳

Network Working Group                                      H. Alvestrand
Request for Comments: 1766                                       UNINETT
Category: Standards Track                                     March 1995

Alvestrandがコメントのために要求するワーキンググループH.をネットワークでつないでください: 1766年のUNINETTカテゴリ: 1995年の標準化過程行進

                Tags for the Identification of Languages

言語の識別のためのタグ

Status of this Memo

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

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This document describes a language tag for use in cases where it is
   desired to indicate the language used in an information object.

このドキュメントは情報物で使用される言語を示すのが必要である場合における使用のための言語タグについて説明します。

   It also defines a Content-language: header, for use in the case where
   one desires to indicate the language of something that has RFC-822-
   like headers, like MIME body parts or Web documents, and a new
   parameter to the Multipart/Alternative type, to aid in the usage of
   the Content-Language: header.

また、それはContent-言語を定義します: 1つがMIME身体の部分やウェブドキュメントのようなRFC-822同様のヘッダー、および新しいパラメタをMultipart/代替手段に持っている何かの言語を示すことを望んでいる場合における使用のために、ヘッダーはContent-言語の用法で援助にタイプしてください: ヘッダー。

1.  Introduction

1. 序論

   There are a number of languages spoken by human beings in this world.

人間によってこの世で話された多くの言語があります。

   A great number of these people would prefer to have information
   presented in a language that they understand.

これらの人々のかなりの数は、彼らが分かるという言語で提示された情報を持っているのを好むでしょう。

   In some contexts, it is possible to have information in more than one
   language, or it might be possible to provide tools for assisting in
   the understanding of a language (like dictionaries).

いくつかの文脈では、1つ以上の言語の情報を持っているのが可能であるか、または言語(辞書のような)の理解を助けるためのツールを提供するのは可能であるかもしれません。

   A prerequisite for any such function is a means of labelling the
   information content with an identifier for the language in which is
   is written.

どんなそのような機能のための前提条件も中に言語のための識別子がある状態で情報量をラベルする書かれた手段です。

   In the tradition of solving only problems that we think we
   understand, this document specifies an identifier mechanism, and one
   possible use for it.

私たちが、分かると思うという問題だけを解決する伝統では、このドキュメントは識別子メカニズム、およびそれの1つの活用可能性を指定します。

Alvestrand                                                      [Page 1]

RFC 1766                      Language Tag                    March 1995

1995年のAlvestrand[1ページ]RFC1766言語タグ行進

2.  The Language tag

2. Languageタグ

   The language tag is composed of 1 or more parts: A primary language
   tag and a (possibly empty) series of subtags.

言語タグは1以上の部品で構成されます: 第一の言語タグと「副-タグ」の(ことによると空)のシリーズ。

   The syntax of this tag in RFC-822 EBNF is:

RFC-822 EBNFのこのタグの構文は以下の通りです。

    Language-Tag = Primary-tag *( "-" Subtag )
    Primary-tag = 1*8ALPHA
    Subtag = 1*8ALPHA

言語タグ=第一のタグ*(「-」Subtag)第一のタグ=1*8ALPHA Subtagは1*8ALPHAと等しいです。

   Whitespace is not allowed within the tag.

空白はタグの中に許容されていません。

   All tags are to be treated as case insensitive; there exist
   conventions for capitalization of some of them, but these should not
   be taken to carry meaning.

すべてのタグが大文字と小文字を区別しないとして扱われることになっています。 いくつかのそれらの資源化のためのコンベンションは存在しますが、意味を運ぶためにこれらを取るべきではありません。

   The namespace of language tags is administered by the IANA according
   to the rules in section 5 of this document.

規則に従って、言語タグの名前空間はこのドキュメントのセクション5でIANAによって管理されます。

   The following registrations are predefined:

以下の登録証明書は事前に定義されます:

   In the primary language tag:

第一の言語で、以下にタグ付けをしてください。

    -    All 2-letter tags are interpreted according to ISO standard
         639, "Code for the representation of names of languages" [ISO
         639].

- ISOの標準の639、「言語の名前の表現のためのコード」[ISO639]に従って、すべての2文字のタグが解釈されます。

    -    The value "i" is reserved for IANA-defined registrations

- 値「i」はIANAによって定義された登録証明書のために予約されます。

    -    The value "x" is reserved for private use. Subtags of "x"
         will not be registered by the IANA.

- 値「x」は私的使用目的で予約されます。 「x」のSubtagsはIANAによって登録されないでしょう。

    -    Other values cannot be assigned except by updating this
         standard.

- アップデート以外のこの規格を他の値に割り当てることができません。

   The reason for reserving all other tags is to be open towards new
   revisions of ISO 639; the use of "i" and "x" is the minimum we can do
   here to be able to extend the mechanism to meet our requirements.

他のすべてのタグを予約する理由はISO639の新しい改正に向かって開かれることです。 「i」と「x」の使用は私たちが私たちの要件を満たすためにメカニズムを広げることができるようにここでできる最小限であることが。

   In the first subtag:

最初のsubtagで:

    -    All 2-letter codes are interpreted as ISO 3166 alpha-2
         country codes denoting the area in which the language is
         used.

- すべての2レター・コードが言語が使用されている領域を指示するISO3166アルファ-2つの国名略号として解釈されます。

    -    Codes of 3 to 8 letters may be registered with the IANA by
         anyone who feels a need for it, according to the rules in

- 3〜8個の手紙のコードはそれの必要性を感じるだれによってもIANAに示されるかもしれません、中の規則に従って

Alvestrand                                                      [Page 2]

RFC 1766                      Language Tag                    March 1995

1995年のAlvestrand[2ページ]RFC1766言語タグ行進

         chapter 5 of this document.

このドキュメントの第5章。

   The information in the subtag may for instance be:

例えば、subtagの情報は以下の通りです。

    -    Country identification, such as en-US (this usage is
         described in ISO 639)

- アン米国などの国の識別(この用法はISO639で説明されます)

    -    Dialect or variant information, such as no-nynorsk or en-
         cockney

- 方言かいいえ-nynorskかアンロンドン子などの異形情報

    -    Languages not listed in ISO 639 that are not variants of
         any listed language, which can be registered with the i-
         prefix, such as i-cherokee

- 言語はi接頭語に登録できるどんな記載された言語の異形でないISO639にも記載しませんでした、i-cherokeeなどのように

    -    Script variations, such as az-arabic and az-cyrillic

- az-arabicやaz-cyrillicなどのスクリプト変化

   In the second and subsequent subtag, any value can be registered.

2番目の、そして、その後のsubtagでは、どんな値も示すことができます。

   NOTE: The ISO 639/ISO 3166 convention is that language names are
   written in lower case, while country codes are written in upper case.
   This convention is recommended, but not enforced; the tags are case
   insensitive.

以下に注意してください。 3166年のISO639/ISOコンベンションは言語名が小文字で書かれているということです、国名略号が大文字で書かれていますが。 このコンベンションは、推薦されますが、実施されません。 タグは大文字と小文字を区別しないです。

   NOTE: ISO 639 defines a registration authority for additions to and
   changes in the list of languages in ISO 639. This authority is:

以下に注意してください。 ISO639は言語のリストでISO639で追加のための登録局を定義して、変化します。 この権威は以下の通りです。

         International Information Centre for Terminology (Infoterm)
         P.O. Box 130
         A-1021 Wien
         Austria
         Phone: +43 1  26 75 35 Ext. 312
         Fax:   +43 1 216 32 72

用語(Infoterm)私書箱130A-1021ウィーンオーストリア電話のための国際インフォメーション・センター: +43 1 26 75 35Ext。 312 Fax: +43 1 216 32 72

   The following codes have been added in 1989 (nothing later): ug
   (Uigur), iu (Inuktitut, also called Eskimo), za (Zhuang), he (Hebrew,
   replacing iw), yi (Yiddish, replacing ji), and id (Indonesian,
   replacing in).

以下のコードは1989年(何でもない後での)に加えられます: ug(ウィグル族の)、iu(また、エスキモと呼ばれるInuktitut)、za(Zhuang)(彼(iwを取り替えるヘブライ人))は(jiを取り替えるイディッシュ)、およびイド(インドネシア語、中の取り替え)をyiします。

   NOTE: The registration agency for ISO 3166 (country codes) is:

以下に注意してください。 ISO3166(国名略号)のための登録機関は以下の通りです。

         ISO 3166 Maintenance Agency Secretariat
         c/o DIN Deutches Institut fuer Normung
         Burggrafenstrasse 6
         Postfach 1107
         D-10787 Berlin
         Germany
         Phone: +49 30 26 01 320
         Fax:   +49 30 26 01 231

ISO3166Maintenance Agency事務局気付DIN Deutches Institut fuer Normung Burggrafenstrasse6Postfach1107D-10787ベルリンドイツ電話: +49 30 26 01、320Fax: +49 30 26 01 231

Alvestrand                                                      [Page 3]

RFC 1766                      Language Tag                    March 1995

1995年のAlvestrand[3ページ]RFC1766言語タグ行進

   The country codes AA, QM-QZ, XA-XZ and ZZ are reserved by ISO 3166 as
   user-assigned codes.

国名略号のAA、QM-QZ、XA-XZ、およびZZはユーザによって割り当てられたコードとしてISO3166によって予約されます。

2.1.  Meaning of the language tag

2.1. 言語タグの意味

   The language tag always defines a language as spoken (or written) by
   human beings for communication of information to other human beings.
   Computer languages are explicitly excluded.

言語タグはいつも情報に関するコミュニケーションのために人間によって話される(または、書かれています)言語を他の人間と定義します。 コンピュータ言語は明らかに除かれます。

   There is no guaranteed relationship between languages whose tags
   start out with the same series of subtags; especially, they are NOT
   guraranteed to be mutually comprehensible, although this will
   sometimes be the case.

タグが「副-タグ」の同じシリーズと共に始める言語の間の保証された関係が全くありません。 これは時々そうになるでしょうが、特に、それらは、互いに分かりやすくなるようにguraranteedされません。

   Applications should always treat language tags as a single token; the
   division into main tag and subtags is an administrative mechanism,
   not a navigation aid.

アプリケーションはいつも単一の象徴として言語タグを扱うべきです。 メインタグと「副-タグ」への分割はナビゲーション援助ではなく、管理機構です。

   The relationship between the tag and the information it relates to is
   defined by the standard describing the context in which it appears.
   So, this section can only give possible examples of its usage.

それが関連するタグと情報との関係はそれが現れる文脈について説明する規格によって定義されます。 それで、このセクションは用法の可能な例を出すことができるだけです。

    -    For a single information object, it should be taken as the
         set of languages that is required for a complete
         comprehension of the complete object. Example: Simple text.

- 単一の情報物において、それは完全な物の完全な読解に必要である言語のセットとしてみなされるべきです。 例: 簡単なテキスト。

    -    For an aggregation of information objects, it should be taken
         as the set of languages used inside components of that
         aggregation.  Examples: Document stores and libraries.

- 情報物の集合において、言語のセットがその集合の内面のコンポーネントを使用したので、それを取るべきです。 例: 店とライブラリを記録してください。

    -    For information objects whose purpose in life is providing
         alternatives, it should be regarded as a hint that the
         material inside is provided in several languages, and that
         one has to inspect each of the alternatives in order to find
         its language or languages.  In this case, multiple languages
         need not mean that one needs to be multilingual to get
         complete understanding of the document. Example: MIME
         multipart/alternative.

- 人生における目的が代替手段を提供している情報物に関しては、それは1つが物質的な内部を多言語に提供して、その言語か言語を見つけるためにそれぞれの代替手段を点検しなければならないというヒントと見なされるべきです。 この場合、複数の言語は、人が、ドキュメントの完全な理解を得るために多数の言語で表現されている必要を意味する必要はありません。 例: MIME複合/代替手段。

    -    It would be possible to define (for instance) an SGML DTD
         that defines a <LANG xx> tag for indicating that following or
         contained text is written in this language, such that one
         could write "<LANG FR>C'est la vie</LANG>"; the Norwegian-
         speaking user could then access a French-Norwegian dictionary
         to find out what the quote meant.

- (例えば)次の含まれたテキストがこの言語で書かれているのを示すための<ラングxx>タグを定義するSGML DTDを定義するのは可能でしょう、人が書くことができるように「<LANG FR>C'est laが競う、</ラング>、」、。 そして、ノルウェー語話しユーザは、引用文が何を意味したかを見つけるためにフランス語ノルウェーの辞書にアクセスできました。

Alvestrand                                                      [Page 4]

RFC 1766                      Language Tag                    March 1995

1995年のAlvestrand[4ページ]RFC1766言語タグ行進

3.  The Content-language header

3. Content-言語ヘッダー

   The 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, like MIME body parts or Web documents.

Languageヘッダーは1つがRFC-822のようなヘッダーがある何かの言語を示すことを望んでいる場合における使用のために意図します、MIME身体の部分やウェブドキュメントのように。

   The RFC-822 EBNF of the Language header is:

LanguageヘッダーのRFC-822 EBNFは以下の通りです。

    Language-Header = "Content-Language" ":" 1#Language-tag

「言語ヘッダーは「満足している言語」と等しい」:、」 1#言語タグ

   Note that the Language-Header is allowed to list several languages in
   a comma-separated list.

Language-ヘッダーがコンマで切り離されたリストの多言語を記載できることに注意してください。

   Whitespace is allowed, which means also that one can place
   parenthesized comments anywhere in the language sequence.

空白(また、1つが言語系列でどこでもparenthesizedコメントを置くことができることを意味する)は許容されています。

3.1.  Examples of Content-language values

3.1. Content-言語値に関する例

   NOTE: NONE of the subtags shown in this document have actually been
   assigned; they are used for illustration purposes only.

以下に注意してください。 見せられた「副-タグ」のNONEは実際に本書では割り当てられました。 それらはイラスト目的だけに使用されます。

   Norwegian official document, with parallel text in both official
   versions of Norwegian. (Both versions are readable by all
   Norwegians).

平行なテキストがノルウェー語の両方の公式のバージョンにあるノルウェーの公文書。 (両方のバージョンはすべてのノルウェー人で読み込み可能です。)

      Content-Type: multipart/alternative;
             differences=content-language
      Content-Language: no-nynorsk, no-bokmaal

コンテントタイプ: 複合/代替手段。 違いは満足している言語のContent-言語と等しいです: nynorskがない、bokmaalがありません。

   Voice recording from the London docks

ロンドンドックからの声の録音

      Content-type: audio/basic
      Content-Language: en-cockney

文書内容: オーディオ的、または、基本的なContent-言語: アンロンドン子です。

   Document in Sami, which does not have an ISO 639 code, and is spoken
   in several countries, but with about half the speakers in Norway,
   with six different, mutually incomprehensible dialects:

サミにもかかわらず、ノルウェーのスピーカーのおよそ半分、6が異なっている互いに不可解な方言で以下を記録してください。(サミは、ISO639コードを持たないで、数カ国で話されます)。

      Content-type: text/plain; charset=iso-8859-10
      Content-Language: i-sami-no (North Sami)

文書内容: テキスト/平野。 charset=iso-8859-10 Content-言語: i-sami-いいえ(北のサミ)

   An English-French dictionary

英語フランス語の辞書

      Content-type: application/dictionary
      Content-Language: en, fr (This is a dictionary)

文書内容: アプリケーション/辞書Content-言語: アン、fr(これは辞書です)

   An official EC document (in a few of its official languages)

公式のECドキュメント(公用語のいくつかにおける)

Alvestrand                                                      [Page 5]

RFC 1766                      Language Tag                    March 1995

1995年のAlvestrand[5ページ]RFC1766言語タグ行進

      Content-type: multipart/alternative
      Content-Language: en, fr, de, da, el, it

文書内容: 複合の、または、代替のContent-言語: アン、fr、de、da、高架鉄道、それ

   An excerpt from Star Trek

スタートレックからの抜粋

      Content-type: video/mpeg
      Content-Language: x-klingon

文書内容: mpeg Contentビデオ/言語: x-klingon

4.  Use of Content-Language with Multipart/Alternative

4. 複合か代替との満足している言語の使用

   When using the Multipart/Alternative body part of MIME, it is
   possible to have the body parts giving the same information content
   in different languages. In this case, one should put a Content-
   Language header on each of the body parts, and a summary Content-
   Language header onto the Multipart/Alternative itself.

MIMEのMultipart/代替手段身体の部分を使用するとき、身体の部分に異なった言語の同じ情報量を与えさせるのは、可能です。 この場合、それぞれの身体の部分、および概要のContent言語ヘッダーのためにMultipart/代替手段自体にContent言語ヘッダーを置くべきです。

4.1.  The differences parameter to multipart/alternative

4.1. 複合か代替への違いのパラメタ

   As defined in RFC 1541, Multipart/Alternative only has one parameter:
   boundary.

RFC1541で定義されるように、Multipart/代替手段には、1つのパラメタしかありません: 境界。

   The common usage of Multipart/Alternative is to have more than one
   format of the same message (f.ex. PostScript and ASCII).

Multipart/代替手段の一般的な用法は同じメッセージの1つ以上の形式を持つことです。(f. 例えば ポストスクリプトとASCII).

   The use of language tags to differentiate between different
   alternatives will certainly not lead all MIME UAs to present the most
   sensible body part as default.

確かに、異なった代替手段の間で微分する言語タグの使用は、すべてのMIME UAsがデフォルトとして最も分別がある身体の部分を提示するように導かないでしょう。

   Therefore, a new parameter is defined, to allow the configuration of
   MIME readers to handle language differences in a sensible manner.

したがって、新しいパラメタは、MIME読者の構成が賢明な方法の言語差を扱うのを許容するために定義されます。

    Name: Differences
    Value: One or more of
         Content-Type
         Content-Language

以下を命名してください。 違いの値: 1か一層のコンテントタイプContent-言語

   Further values can be registered with IANA; it must be the name of a
   header for which a definition exists in a published RFC.  If not
   present, Differences=Content-Type is assumed.

さらなる値をIANAに示すことができます。 それは定義が発行されたRFCに存在するヘッダーの名前であるに違いありません。 そうでなければ、現在のDifferences=コンテントタイプは想定されます。

   The intent is that the MIME reader can look at these headers of the
   message component to do an intelligent choice of what to present to
   the user, based on knowledge about the user preferences and
   capabilities.

意図はMIME読者がユーザー選択と能力に関する知識に基づいてユーザに提示するべきことの利口な選択をするためにメッセージコンポーネントのこれらのヘッダーを見ることができるということです。

   (The intent of having registration with IANA of the fields used in
   this context is to maintain a list of usages that a mail UA may
   expect to see, not to reject usages.)

(分野のIANAがこのような関係においては使用されている登録を持つ意図はメールUAが用法を拒絶するのではなく、見ると予想するかもしれない用法のリストを維持することです。)

Alvestrand                                                      [Page 6]

RFC 1766                      Language Tag                    March 1995

1995年のAlvestrand[6ページ]RFC1766言語タグ行進

   (NOTE: The MIME specification [RFC 1521], section 7.2, states that
   headers not beginning with "Content-" are generally to be ignored in
   body parts. People defining a header for use with "differences="
   should take note of this.)

(以下に注意してください。 MIME仕様[RFC1521](セクション7.2)は、一般に、「内容」で始まらないヘッダーが身体の部分で無視されることになっていると述べます。 使用のために「違い=」でヘッダーを定義する人々はこれに注目するべきです。)

   The mechanism for deciding which body part to present is outside the
   scope of this document.

このドキュメントの範囲の外にどの身体の部分を提示したらよいかを決めるためのメカニズムがあります。

    MIME EXAMPLE:

例をまねてください:

    Content-Type: multipart/alternative; differences=Content-Language;
              boundary="limit"
    Content-Language: en, fr, de

コンテントタイプ: 複合/代替手段。 違いは満足している言語と等しいです。 境界は「限界」Content-言語と等しいです: アン、fr、de

    --limit
    Content-Language: fr

--Content-言語を制限してください: fr

    Le renard brun et agile saute par dessus le chien paresseux
    --limit
    Content-Language: de
    Content-Type: text/plain; charset=iso-8859-1
    Content-Transfer-encoding: quoted-printable

Le renard brun etのアジャイルソテー平価ドシュle chien paresseux--Content-言語を制限してください: deコンテントタイプ: テキスト/平野。 charset=iso-8859-1 Contentはコード化を移します: 引用されて印刷可能です。

    Der schnelle braune Fuchs h=FCpft =FCber den faulen Hund
    --limit
    Content-Language: en

Der schnelle brauneフックスh=FCpft =FCberはfaulenフントを穴に追い込みます--Content-言語を制限してください: アン

    The quick brown fox jumps over the lazy dog
    --limit--

怠惰な犬の上の迅速な茶色のキツネジャンプ--限界--

   When composing a message, the choice of sequence may be somewhat
   arbitrary. However, non-MIME mail readers will show the first body
   part first, meaning that this should most likely be the language
   understood by most of the recipients.

メッセージを作成するとき、系列の選択はいくらか任意であるかもしれません。 しかしながら、非MIMEメール読者は最初に最初の身体の部分を見せるでしょう、これがたぶん受取人の大部分に解釈された言語であるべきであることを意味して。

5.  IANA registration procedure for language tags

5. 言語タグのためのIANA登録手順

   Any language tag must start with an existing tag, and extend it.

どんな言語タグも、既存のタグから始まって、それを広げなければなりません。

   This registration form should be used by anyone who wants to use a
   language tag not defined by ISO or IANA.

この登録用紙はISOかIANAによって定義されなかった言語タグを使用したがっているだれによっても使用されるべきです。

Alvestrand                                                      [Page 7]

RFC 1766                      Language Tag                    March 1995

1995年のAlvestrand[7ページ]RFC1766言語タグ行進

----------------------------------------------------------------------
LANGUAGE TAG REGISTRATION FORM

---------------------------------------------------------------------- 言語タグ登録用紙

Name of requester          :
E-mail address of requester:
Tag to be registered       :

リクエスタの名前: リクエスタのEメールアドレス: 登録されるべきタグ:

English name of language   :

言語のイギリスの名前:

Native name of language (transcribed into ASCII):

言語(ASCIIに転写される)の固有の名前:

Reference to published description of the language (book or article):
----------------------------------------------------------------------

言語(本か記事)の発行された記述の参照: ----------------------------------------------------------------------

   The language form must be sent to <ietf-types@uninett.no> for a 2-
   week review period before submitting it to IANA.  (This is an open
   list. Requests to be added should be sent to <ietf-types-
   request@uninett.no>.)

to <ietf-types@uninett.no を言語形式に送らなければならない、gt;、2IANAにそれを提出する前のレビューの期間の週に。 (これはオープン・リストです。 <ietfタイプ- request@uninett.no に加えられるという要求を送るべきである、gt。)

   When the two week period has passed, the language tag reviewer, who
   is appointed by the IETF Applications Area Director, either forwards
   the request to IANA@ISI.EDU, or rejects it because of significant
   objections raised on the list.

2週間の期間が経過したとき、リストで上げられた重要な反論のために、言語タグ評論家(IETF Applications Areaディレクターによって任命される)は、要求を IANA@ISI.EDU に転送するか、またはそれを拒絶します。

   Decisions made by the reviewer may be appealed to the IESG.

評論家によってされた決定はIESGに上告されるかもしれません。

   All registered forms are available online in the directory
   ftp://ftp.isi.edu/in-notes/iana/assignments/languages/

すべての記名式がディレクトリ ftp://ftp.isi.edu/in-notes/iana/assignments/languages/ でオンラインで利用可能です。

6.  Security Considerations

6. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

7.  Character set considerations

7. 文字の組問題

   Codes may always be expressed using the US-ASCII character repertoire
   (a-z), which is present in most character sets.

コードは、米国-ASCII文字レパートリー(a-z)(ほとんどの文字の組で存在している)を使用することでいつも表されるかもしれません。

   The issue of deciding upon the rendering of a character set based on
   the language tag is not addressed in this memo; however, it is
   thought impossible to make such a decision correctly for all cases
   unless means of switching language in the middle of a text are
   defined (for example, a rendering engine that decides font based on
   Japanese or Chinese language will fail to work when a mixed
   Japanese-Chinese text is encountered)

言語タグに基づく文字の組の表現について決める問題はこのメモに記述されません。 しかしながら、テキストの中央で言語を切り換える手段が定義されない場合、それはすべてのケースのために正しくそのような決定をするのが不可能であると考えられます。(例えば、複雑な日中のテキストが遭遇するとき、日本の、または、中国の言語に基づく字体が働かないと決める表現エンジン)

Alvestrand                                                      [Page 8]

RFC 1766                      Language Tag                    March 1995

1995年のAlvestrand[8ページ]RFC1766言語タグ行進

8.  Acknowledgements

8. 承認

   This document has benefited from innumberable rounds of review and
   comments in various fora of the IETF and the Internet working groups.
   As so, 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.

このドキュメントはIETFとインターネットワーキンググループの様々なフォーラムでレビューとコメントの「不-数-可能」ラウンドの利益を得ました。 したがって、貢献者のどんなリストも不完全であることが制限されているので。 このドキュメントを今日現在の姿にするように貢献した人々のグループから以下を選択だけと見なしてください。

   In alphabetical order:

アルファベット順に:

   Tim Berners-Lee, Nathaniel Borenstein, Jim Conklin, Dave Crocker,
   Ned Freed, Tim Goodwin, Olle Jarnefors, John Klensin, Keith Moore,
   Masataka Ohta, Keld Jorn Simonsen, Rhys Weatherley, and many, many
   others.

ティム・バーナーズ・リー、ナザニエルBorenstein、ジム・コンクリン、デーヴ・クロッカー、ネッド・フリード、ティム・グッドウィン、オッレJarnefors、ジョンKlensin、キース・ムーア、Masataka太田、Keldイェルン・シモンセン、リスWeatherley、および多くの他のもの。

9.  Author's Address

9. 作者のアドレス

   Harald Tveit Alvestrand
   UNINETT
   Pb. 6883 Elgeseter
   N-7002 TRONDHEIM
   NORWAY

ハラルドTveit Alvestrand UNINETT Pb。 6883 Elgeseter N-7002トロンヘイムノルウェー

   EMail: Harald.T.Alvestrand@uninett.no
   Phone: +47 73 59 70 94

メール: Harald.T.Alvestrand@uninett.no 電話: +47 73 59 70 94

10.  References

10. 参照

    [ISO 639]
         ISO 639:1988 (E/F) - Code for the representation of names of
         languages - The International Organization for
         Standardization, 1st edition, 1988 17 pages Prepared by
         ISO/TC 37 - Terminology (principles and coordination).

[ISO639]ISO、639:1988 (E/F)--言語の名前の表現のためのコード--国際標準化機構、最初の版、1988 17はISO/TC37でPreparedを呼び出します--用語(原則とコーディネート)。

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

[ISO3166]ISO、3166:1988 (E/F)--国の名前の表現のためのコード--国際標準化機構、3番目の版、1988年8月15日。

    [RFC 1521]
         Borenstein, N., and N. Freed, "MIME Part One: Mechanisms for
         Specifying and Describing the Format of Internet Message
         Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

[RFC1521] Borenstein、N.、およびN.フリード、「パート1をまねてください」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。

    [RFC 1327]
         Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC
         822", RFC 1327, University College London, May 1992.

Kille、[RFC1327]S.、「X.400(1988)/ISO10021とRFC822インチ、RFC1327、ユニバーシティ・カレッジロンドンの間で5月1992日を写像すること。

Alvestrand                                                      [Page 9]

Alvestrand[9ページ]