/[pub]/suikawiki/sw4data/ids/2/552.txt
Suika

Contents of /suikawiki/sw4data/ids/2/552.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.3 - (hide annotations) (download)
Sun Sep 4 10:46:59 2011 UTC (13 years, 3 months ago) by wakaba
Branch: MAIN
CVS Tags: HEAD
Changes since 1.2: +1 -1 lines
File MIME type: text/plain
updated by (anon)

1 wakaba 1.1
2 wakaba 1.3 ;;
3 wakaba 1.2 [21] [[RFC 3066]] は [[RFC 4646]] により[[廃止]]されています。
4 wakaba 1.1
5    
6     '''Tags for the Identification of Languages [INS[言語同定用__&&tag&&__]]'''
7     -Network Working Group
8     -Request for Comments: 3066
9     -BCP: 47
10     -Obsoletes: 1766
11     -Category: Best Current Practice
12     -H. Alvestrand (Cisco Systems)
13     -January 2001
14     __&&BCPStatus&&__
15     *Copyright Notice
16     >Copyright (C) The Internet Society (2001). All Rights Reserved.
17     *Abstract
18     >This document describes a language tag for use in cases where it is
19     desired to indicate the language used in an information object, how
20     to register values for use in this language tag, and a construct for
21     matching such language tags.
22    
23     この文書は、情報物体で使われている言語を示すことが望ましい場面で使用する言語__&&tag&&__,
24     この言語__&&tag&&__で使う値の登録方法, 及び言語__&&tag&&__の一致の構成を説明します。
25    
26     [INS[
27     訳注: ''一致の構成''って何だよ? とか思うけど適切な訳語が思いつかない。
28     [[#comment]]
29     ]INS]
30     *1. Introduction [INS[はじめに]]
31     >Human beings on our planet have, past and present, used a number of
32     languages. There are many reasons why one would want to identify the
33     language used when presenting information.
34    
35     この[RUBY[地球] [ほし]]の人間は、過去及び現在において、幾多の言語を使用してきました。
36     情報を表現するときに使われている言語を同定したい理由は沢山あります。
37    
38     >In some contexts, it is possible to have information available in
39     more than one language, or it might be possible to provide tools
40     (such as dictionaries) to assist in the understanding of a language.
41    
42     幾つかの場面において、複数の言語で情報が利用可能であるかもしれませんし。言語の理解の補助のための道具
43     (例えば辞書) を提供することが出来るかもしれません。
44    
45     >Also, many types of information processing require knowledge of the
46     language in which information is expressed in order for that process
47     to be performed on the information; for example spell-checking,
48     computer-synthesized speech, Braille, or high-quality print
49     renderings.
50    
51     また、多くの情報処理の型において、情報に施される処理のためにどの言語で情報が表現されているのかの知識が必要になります。
52     例えば、綴り検査, 計算機合成発話, 点字, 又は高品質印刷__&&rendering&&__が挙げられます。
53    
54     >One means of indicating the language used is by labeling the
55     information content with an identifier for the language that is used
56     in this information content.
57    
58     使用されている言語を同定する一つの方法は、当該情報内容に使用されている言語の識別子で情報内容を札付けするというものです。
59    
60     >This document specifies an identifier mechanism, a registration
61     function for values to be used with that identifier mechanism, and a
62     construct for matching against those values.
63    
64     この文書は識別子の仕組み, 識別子の仕組みで使用される値の登録機能,
65     及びこの値の一致の構築について規定します。
66    
67     >The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
68     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
69     document are to be interpreted as described in [RFC 2119].
70    
71     __&&JA:RFCKeywordsAre...&&__
72     *2. The Language tag [INS[言語__&&tag&&__]]
73     **2.1 Language tag syntax [INS[言語__&&tag&&__構文]]
74     >The language tag is composed of one or more parts: A primary language
75     subtag and a (possibly empty) series of subsequent subtags.
76    
77     言語__&&tag&&__は1つ以上の部分で構成します。第1言語__&&subtag&&__及びそれに続く
78     (空かもしれない) __&&subtag&&__群です。
79    
80     >The syntax of this tag in ABNF [RFC 2234] is:
81    
82     この__&&tag&&__の構文を [[ABNF]] で表すとこうなります。
83    
84     -[1] Language-Tag = Primary-subtag *( "-" Subtag )
85     -[2] Primary-subtag = 1*8ALPHA
86     -[3] Subtag = 1*8(ALPHA / DIGIT)
87    
88     >The productions ALPHA and DIGIT are imported from RFC 2234; they
89     denote respectively the characters A to Z in upper or lower case and
90     the digits from 0 to 9. The character "-" is HYPHEN-MINUS (ABNF:
91     %x2D).
92    
93     構成要素 [CODE(ABNF)[ALPHA]] 及び [CODE(ABNF)[DIGIT]]
94     は [[RFC2234]] にあります。それぞれ文字 [CODE[A]]〜[CODE[Z]]
95     の大文字・小文字及び数字 [CODE[0]]〜[CODE[9]] を示します。
96     文字 [CODE(ABNF)["-"]] は [CODE(CHARNAME)[HYPHEN-MINUS]]
97     (ABNF: [CODE(ABNF)[%x2D]]) です。
98    
99     >All tags are to be treated as case insensitive; there exist
100     conventions for capitalization of some of them, but these should not
101     be taken to carry meaning. For instance, [ISO 3166] recommends that
102     country codes are capitalized (MN Mongolia), while [ISO 639]
103     recommends that language codes are written in lower case (mn
104     Mongolian).
105    
106     全ての__&&tag&&__は大文字・小文字を区別しないものとして扱います。
107     幾つかのものを大文字化する慣習がありますが、これはなんら意味を持つものでもありません。
108     例えば、 [[ISO3166]] は国名符号を大文字化する ([CODE(LANG)[MN]] モンゴル)
109     ことを推奨し、 [[ISO639]] は言語符号を小文字で書く ([CODE(LANG)[mn]] モンゴル語)
110     ことを推奨しています。
111    
112     **2.2 Language tag sources [INS[言語__&&tag&&__典拠]]
113     >The namespace of language tags is administered by the Internet
114     Assigned Numbers Authority (IANA) [RFC 2860] according to the rules
115     in section 3 of this document.
116    
117     言語__&&tag&&__の名前空間はこの文書の第3章の規則に従って__&&IANAFullName&&__が管理します。
118    
119     >The following rules apply to the primary subtag:
120    
121     第1__&&subtag&&__には次の規則を適用します。
122    
123     - All 2-letter subtags are interpreted according to assignments found
124     in ISO standard 639, "Code for the representation of names of
125     languages" [ISO 639], or assignments subsequently made by the ISO
126     639 part 1 maintenance agency or governing standardization bodies.
127     (Note: A revision is underway, and is expected to be released as
128     ISO 639-1:2000)
129    
130     - All 3-letter subtags are interpreted according to assignments found
131     in ISO 639 part 2, "Codes for the representation of names of
132     languages -- Part 2: Alpha-3 code [ISO 639-2]", or assignments
133     subsequently made by the ISO 639 part 2 maintenance agency or
134     governing standardization bodies.
135    
136     - The value "i" is reserved for IANA-defined registrations
137    
138     - The value "x" is reserved for private use. Subtags of "x" shall
139     not be registered by the IANA.
140    
141     - Other values shall not be assigned except by revision of this
142     standard.
143    
144     -全ての2文字__&&subtag&&__は ISO 規格 639 『言語符号』にある割当て若しくは
145     ISO 639 第1部維持機関又は管理標準化団体により後に行われた割当てに従って解釈する。
146     (注意: 改定が作業中であり、 ISO 639-1:2000 として制定されると思われる。)
147     -全ての3文字__&&subtag&&__は ISO 639 第2部『言語符号——第2部: α‐3符号』
148     にある割当て若しくは
149     ISO 639 第1部維持機関又は管理標準化団体により後に行われた割当てに従って解釈する。
150     -値 [CODE(ABNF)["i"]] は IANA が定義した登録用に予約する。
151     -値 [CODE(ABNF)["x"]] は 私用に予約する。__&&subtag&&__ [CODE(ABNF)["x"]]
152     は IANA で登録しない。
153     -他の値はこの規格の改訂を除いては使用しない。
154    
155     >The reason for reserving all other tags is to be open towards new
156     revisions of ISO 639; the use of "i" and "x" is the minimum we can do
157     here to be able to extend the mechanism to meet our immediate
158     requirements.
159    
160     他の全ての__&&tag&&__を保留する理由は、 ISO 639 の新しい版に追随するためです。
161     [CODE(ABNF)["i"]] や [CODE(ABNF)["x"]] の使用は、我々の迫った要求に見合うように仕組みを拡張することが出来るようにここで出来る最小限のことです。
162    
163     >The following rules apply to the second subtag:
164    
165     次の規則を第2__&&subtag&&__に適用します。
166    
167     - All 2-letter subtags are interpreted as ISO 3166 alpha-2 country
168     codes from [ISO 3166], or subsequently assigned by the ISO 3166
169     maintenance agency or governing standardization bodies, denoting
170     the area to which this language variant relates.
171    
172     - Tags with second subtags of 3 to 8 letters may be registered with
173     IANA, according to the rules in chapter 5 of this document.
174    
175     - Tags with 1-letter second subtags may not be assigned except after
176     revision of this standard.
177    
178     -全ての2文字__&&subtag&&__は ISO 3166 からの、若しくは ISO 3166
179     維持機関又は管理標準化団体が割り当てた ISO 3166 α‐2
180     国名符号とし、当該言語異形が関係する地域を示す。
181     -3〜8文字の第2__&&subtag&&__を持つ__&&tag&&__は IANA によりこの文書の第5章の規則に従い登録しても良い。
182     -1文字の第2__&&subtag&&__を持つ__&&tag&&__はこの規格の改訂された後まで割当ててはいけない。
183    
184     >There are no rules apart from the syntactic ones for the third and
185     subsequent subtags.
186    
187     第3及びそれ以降の__&&subtag&&__には構文的規則以外の規則はありません。
188    
189     >Tags constructed wholly from the codes that are assigned
190     interpretations by this chapter do not need to be registered with
191     IANA before use.
192    
193     この節でその解釈が割当てられた符号のみから構成される__&&tag&&__は使用の前に
194     IANA に登録する必要はありません。
195    
196     >The information in a subtag may for instance be:
197    
198     __&&subtag&&__中の情報は例えば次のようなものです。
199    
200     - Country identification, such as en-US (this usage is described in
201     ISO 639)
202    
203     - Dialect or variant information, such as en-scouse
204    
205     - Languages not listed in ISO 639 that are not variants of any listed
206     language, which can be registered with the i-prefix, such as i-tsolyani
207    
208     - Region identification, such as sgn-US-MA (Martha's Vineyard Sign
209     Language, which is found in the state of Massachusetts, US)
210    
211     -国家同定, 例えば [CODE(LANG)[en-US]] (この用法は ISO 639 で説明されています)
212     -方言や異形の情報、例えば [CODE(LANG)[en-scouse]] [INS[(英語の Liverpool (西 England の港町) 方言)]]
213     -[20] ISO 639 に載っていない言語で他のどの言語の変形でもないもので、 [CODE(LANG)[i-tsolyani]]
214     のように [CODE(LANG)[i-]]接頭辞を付けて登録できる
215     -[19] 地域同定, 例えは [CODE(LANG)[sgn-US-MA]]
216     (合衆国マサチューセッツ州マーサズ[RUBY[葡萄園] [ヴィンヤード]]島の手話)
217     [INS[
218     訳注: Martha's Vineyard == (台湾名) 馬薩葡萄園島。
219     『みんなが手話で話した島』(佐野正信訳, 築地書館, <urn:ISBN:4-8067-2220-0>)
220     という本に詳しいらしい。
221     ]INS]
222    
223     >This document leaves the decision on what tags are appropriate or not
224     to the registration process described in section 3.
225    
226     この文書はどのような__&&tag&&__が第3節で説明する登録過程に適当か否かの決定には触れません。
227    
228     >ISO 639 defines a maintenance agency for additions to and changes in
229     the list of languages in ISO 639. This agency is:
230    
231     ISO 639 は ISO 639 の言語一覧への追加と変更の管理機関を定義しています。
232     管理機関は、
233    
234     International Information Centre for Terminology (Infoterm)
235     P.O. Box 130 [INS[専門用語国際情報センター]]
236     A-1021 Wien
237     Austria
238    
239     Phone: +43 1 26 75 35 Ext. 312
240     Fax: +43 1 216 32 72
241    
242     です。 [INS[訳注: Infoterm の日本語名は見つかりませんでした。]]
243    
244     >ISO 639-2 defines a maintenance agency for additions to and changes
245     in the list of languages in ISO 639-2. This agency is:
246    
247     ISO 639-2 は ISO 639-2 の言語一覧への追加と変更の管理機関を定義しています。
248     管理機関は、
249    
250     Library of Congress [INS[合衆国議会図書館ネットワーク開発及び MARS 標準局]]
251     Network Development and MARC Standards Office
252     Washington, D.C. 20540
253     USA
254    
255     Phone: +1 202 707 6237
256     Fax: +1 202 707 0115
257     URL: http://www.loc.gov/standards/iso639
258    
259     です。
260    
261     >The maintenance agency for ISO 3166 (country codes) is:
262    
263     ISO 3166 (国名符号) の維持機関は
264    
265     ISO 3166 Maintenance Agency Secretariat [INS[ISO 3166 維持機関事務局]]
266     c/o DIN Deutsches Institut fuer Normung
267     Burggrafenstrasse 6
268     Postfach 1107
269     D-10787 Berlin
270     Germany
271    
272     Phone: +49 30 26 01 320
273     Fax: +49 30 26 01 231
274     URL: http://www.din.de/gremien/nas/nabd/iso3166ma/
275    
276     です。
277    
278     >ISO 3166 reserves the country codes AA, QM-QZ, XA-XZ and ZZ as
279     user-assigned codes. These MUST NOT be used to form language tags.
280    
281     ISO 3166 は国名符号 [CODE[AA]], [CODE[QM]]〜[CODE[QZ]], [CODE[XA]]〜[CODE[XZ]]
282     及び [CODE[ZZ]] を利用者割当符号として予約しています。
283     これらは言語__&&tag&&__の形成に使用しては__&&MUST&&__。
284    
285     [INS[
286     訳注: ISO 639-2 は [CODE(LANG)[qaa]]〜[CODE(LANG)[qtz]]
287     を私用言語符号として予約していますが、これも使用しないのが良いでしょう。
288     ]INS]
289    
290     **2.3 Choice of language tag [INS[言語__&&tag&&__の選択]]
291     >One may occasionally be faced with several possible tags for the same
292     body of text.
293    
294     時折、__&&text&&__の同一本体に対して複数の__&&tag&&__が考えられる場面があります。
295    
296     >Interoperability is best served if all users send the same tag, and
297     use the same tag for the same language for all documents. If an
298     application has requirements that make the rules here inapplicable,
299     the application protocol specification MUST specify how the procedure
300     varies from the one given here.
301    
302     全ての利用者が同じ__&&tag&&__を送信し、全ての文書で同じ言語に同じ__&&tag&&__を使えば最も相互通信性ががります。
303     応用がその要件によりここでの規則を適用できない場合、応用__&&protocol&&__は手続きがここに示すものからどう変化するのかを規定しなければ__&&MUST&&__。
304    
305     >The text below is based on the set of tags known to the tagging entity.
306    
307     下記の__&&text&&__は__&&tag&&__付けする実体に対して分かっている__&&tag&&__の集合を基にします。
308    
309     1. Use the most precise tagging known to the sender that can be
310     ascertained and is useful within the application context.
311    
312     2. When a language has both an ISO 639-1 2-character code and an ISO
313     639-2 3-character code, you MUST use the tag derived from the ISO
314     639-1 2-character code.
315    
316     3. When a language has no ISO 639-1 2-character code, and the ISO
317     639-2/T (Terminology) code and the ISO 639-2/B (Bibliographic)
318     code differ, you MUST use the Terminology code. NOTE: At present,
319     all languages for which there is a difference have 2-character
320     codes, and the displeasure of developers about the existence of 2
321     code sets has been adequately communicated to ISO. So this
322     situation will hopefully not arise.
323    
324     4. When a language has both an IANA-registered tag (i-something) and
325     a tag derived from an ISO registered code, you MUST use the ISO
326     tag. NOTE: When such a situation is discovered, the IANA-registered
327     tag SHOULD be deprecated as soon as possible.
328    
329     5. You SHOULD NOT use the UND (Undetermined) code unless the protocol
330     in use forces you to give a value for the language tag, even if
331     the language is unknown. Omitting the tag is preferred.
332    
333     6. You SHOULD NOT use the MUL (Multiple) tag if the protocol allows
334     you to use multiple languages, as is the case for the Content-Language: header.
335    
336     =確認出来ていて応用の文脈中で有用である、送信者の知る最も正確な__&&tag&&__付けを使う。
337     =言語が ISO 639-1 2文字符号及び ISO 639-2 3文字符号の両者を持つ場合は、 ISO 639-1
338     2文字符号に由来する__&&tag&&__を使わなければ__&&MUST&&__。
339     =言語が ISO 639-1 2文字符号を持っておらず、 ISO 639-2/T (用語) 符号及び
340     ISO 639-2/B (書誌) 符号が異なる場合、用語符号を使わなければ__&&MUST&&__。
341     注意: 現在、差異のある全ての言語は2文字符号を持っており、また2つの符号集合が存在することに関する開発者の不満は
342     ISO に十分に伝えられています。ですから、この状況はうまくいけば起こらないでしょう。
343     =言語が IANA 登録__&&tag&&__ ([CODE(LANG)[i-なんたら]])
344     と ISO 登録符号に由来する__&&tag&&__を持っている場合、 ISO __&&tag&&__
345     を使わなければ__&&MUST&&__。注意: そのような状況が判明した場合、 IANA
346     登録__&&tag&&__は可能な限りすぐに非推奨する__&&SHOULD&&__。
347     =[CODE[UND]] (未決定) 符号は使用するプロトコルが言語__&&tag&&__の値を与えることを強制していない限り使用し__&&SHOULD NOT&&__。
348     __&&tag&&__を省略する方が好ましいです。
349     =[CODE[MUL]] (複数) __&&tag&&__は、 [CODE[Content-Language:]]
350     __&&header&&__のようにプロトコルが複数の言語の使用を認めている場合には使用し__&&SHOULD NOT&&__。
351    
352     >NOTE: In order to avoid versioning difficulties in applications such
353     as that of RFC 1766, the ISO 639 Registration Authority Joint
354     Advisory Committee (RA-JAC) has agreed on the following policy
355     statement:
356    
357     注意: RFC 1766 の場合のように応用中での版決定が困難になるのを避けるため、
358     ISO 630 登録事務局合同諮問委員会 (RA-JAC) は次の方針声明に合意しました。
359    
360     >>"After the publication of ISO/DIS 639-1 as an International
361     Standard, no new 2-letter code shall be added to ISO 639-1 unless a
362     3-letter code is also added at the same time to ISO 639-2. In
363     addition, no language with a 3-letter code available at the time of
364     publication of ISO 639-1 which at that time had no 2-letter code
365     shall be subsequently given a 2-letter code."
366    
367     「ISO/DIS 639-1 が国際標準として発行された後、3文字符号が同時に ISO 639-2
368     に追加されない限り新しい2文字符号は ISO 639-1 には追加しない。
369     加えて、 ISO 639-1 の発行の時点で3文字言語符号を持つが2文字符号は持たない言語には今後2文字符号を与えない。」
370    
371     >This will ensure that, for example, a user who implements "hwi"
372     (Hawaiian), which currently has no 2-letter code, will not find his
373     or her data invalidated by eventual addition of a 2-letter code for
374     that language."
375    
376     これにより例えば、現在2文字符号を持たない [CODE(LANG)["hwi"]]
377     (ハワイ語) を実装した利用者は、結果として起こるこの言語への2文字符号の追加によりそのデータが無効になることはありません。
378    
379     [INS[
380     訳注: 上記段落原文には末尾に <"> がついているが、字下げや内容を考えると RA-JAC
381     声明の一部ではなく RFC の一部ではないかと思われる。
382     ]INS]
383    
384     **2.4 Meaning of the language tag [INS[言語__&&tag&&__の意味]]
385     >The language tag always defines a language as spoken (or written,
386     signed or otherwise signaled) by human beings for communication of
387     information to other human beings. Computer languages such as
388     programming languages are explicitly excluded. There is no
389     guaranteed relationship between languages whose tags begin with the
390     same series of subtags; specifically, they are NOT guaranteed to be
391     mutually intelligible, although it will sometimes be the case that
392     they are.
393    
394     言語__&&tag&&__は常に、人間により他の人間への情報の伝達のために話される
395     (又は書かれる, 示される, その他信号される) 言語を定義します。
396     プログラム言語のような計算機言語は明白に除外します。
397     同じ__&&subtag&&__群で始まる__&&tag&&__の言語間の関係についての保障はありません。
398     具体的には、相互に理解可能であるという保障は、可能であるという場合もあるでしょうが、保障し'''ません'''。
399    
400     >The relationship between the tag and the information it relates to is
401     defined by the standard describing the context in which it appears.
402     Accordingly, this section can only give possible examples of its usage.
403    
404     __&&tag&&__及びその関連する情報の関係は、その出現する文脈を説明した規格の定義によります。
405     従って、この節はその可能な用法の例のみを示します。
406    
407     - For a single information object, it could be taken as the set of
408     languages that is required for a complete comprehension of the
409     complete object.
410     Example: Plain text documents.
411    
412     - For an aggregation of information objects, it should be taken as
413     the set of languages used inside components of that aggregation.
414     Examples: Document stores and libraries.
415    
416     - For information objects whose purpose is to provide alternatives,
417     the set of tags associated with it should be regarded as a hint
418     that the content is provided in several languages, and that one has
419     to inspect each of the alternatives in order to find its language
420     or languages. In this case, a tag with multiple languages does not
421     mean that one needs to be multi-lingual to get complete
422     understanding of the document.
423     Example: MIME multipart/alternative.
424    
425     - In markup languages, such as HTML and XML, language information can
426     be added to each part of the document identified by the markup
427     structure (including the whole document itself). For example, one
428     could write <span lang="FR">C'est la vie.</span> inside a Norwegian
429     document; the Norwegian-speaking user could then access a
430     French-Norwegian dictionary to find out what the marked section meant. If
431     the user were listening to that document through a speech synthesis
432     interface, this formation could be used to signal the synthesizer
433     to appropriately apply French text-to-speech pronunciation rules to
434     that span of text, instead of misapplying the Norwegian rules.
435    
436     -単一情報物体で、完全な物体の完全な理解のために必要とされる言語の集合として取ることが出来る。
437     例: __&&plain text&&__文書
438     -情報物体の集合で、集合の内部構成要素に使われている言語の集合として取るのが良い。
439     例: 文書蓄積及び書庫
440     -代替物を提供するのが目的の情報物体で、これに関連付けられている__&&tag&&__の集合は内容が複数の言語で提供されていて各代替物をその言語を調べるために調査しないといけないものの補助情報としてみなすのが良い。
441     この場合、複数言語の__&&tag&&__は文書を完全に理解するのに多言語に通じている必要があることを意味しない。
442     例: MIME [CODE[multipart/alternative]]
443     -マーク付け言語, [[HTML]] や [[XML]] などで、マーク付け構造で識別される文書の各部
444     (文書自体全体を含む。) に加えることが出来る。
445     例えば、[RUBY[諾威] [ノルウェイ]]語文書の中で
446     [CODE(HTML)[<span lang="FR">C'est la vie.</span>]] と書くことが出来ます。
447     諾威語話者はマークされた節の意味を理解するために仏[ABBR[諾] [諾威]]辞典を引くことが出来ます。
448     利用者が文書を発話合成界面を通じて聞いているなら、__&&text&&__の当該部分を仏蘭西語の会話発音規則を
449     (誤って諾威語の規則を適用せずに正しく)
450     適用するよう合成器に知らせるのに使えます。
451    
452     **2.5 Language-range [INS[言語範囲]]
453     >Since the publication of RFC 1766, it has become apparent that there
454     is a need to define a term for a set of languages whose tags all
455     begin with the same sequence of subtags.
456    
457     RFC 1766 の発行以後、同じ__&&subtag&&__群で始まる__&&tag&&__の言語の集合を表す語彙を定義する必要があることが明らかになってきました。
458    
459     >The following definition of language-range is derived from HTTP/1.1 [RFC 2616].
460    
461     次の [CODE(ABNF)[language-range]] の定義は [[HTTP/1.1]] に由来します。
462     -[13] language-range = language-tag / "*"
463    
464     >That is, a language-range has the same syntax as a language-tag, or
465     is the single character "*".
466    
467     つまり、 [CODE(ABNF)[language-range]] は [CODE(ABNF)[language-tag]]
468     と同じ構文を持つか、単一文字 [CODE(ABNF)["*"]] です。
469    
470     >A language-range matches a language-tag if it exactly equals the tag,
471     or if it exactly equals a prefix of the tag such that the first
472     character following the prefix is "-".
473    
474     [CODE(ABNF)[language-range]] は__&&tag&&__と完全に等しいか、__&&tag&&__の接頭辞が完全に等しくて、接頭辞の次の文字が
475     [CODE(ABNF)["-"]] である場合に [CODE(ABNF)[language-tag]] に一致します。
476    
477     >The special range "*" matches any tag. A protocol which uses
478     language ranges may specify additional rules about the semantics of
479     "*"; for instance, HTTP/1.1 specifies that the range "*" matches only
480     languages not matched by any other range within an "Accept-Language:" header.
481    
482     特殊範囲 [CODE(ABNF)["*"]] はどの__&&tag&&__にも一致します。
483     言語範囲を使用する__&&protocol&&__は [CODE(ABNF)["*"]]
484     の意味についての追加の規則を規定しても構いません。例えば、 [[HTTP/1.1]]
485     は [CODE[Accept-Language:]] __&&header&&__中のどの他の範囲にも一致しない言語に一致します。
486    
487     >NOTE: This use of a prefix matching rule does not imply that language
488     tags are assigned to languages in such a way that it is always true
489     that if a user understands a language with a certain tag, then this
490     user will also understand all languages with tags for which this tag
491     is a prefix. The prefix rule simply allows the use of prefix tags if
492     this is the case.
493    
494     注意: 接頭辞一致規則のこの用法は、ある利用者がある__&&tag&&__の言語を理解するならば、この利用者はこの__&&tag&&__が接頭辞である__&&tag&&__の全ての言語をも理解するという条件が常に真であるように言語__&&tag&&__が割当てられることを必要とするものではありません。
495    
496     *3. IANA registration procedure for language tags [INS[言語__&&tag&&__ IANA 登録手続き]]
497     >The procedure given here MUST be used by anyone who wants to use a
498     language tag not given an interpretation in chapter 2.2 of this
499     document or previously registered with IANA.
500    
501     ここに示す手続きはこの文書の2.2節の解釈又は以前の IANA
502     の登録にない言語__&&tag&&__を使用することを望む人は誰でも使うことが出来なければ__&&MUST&&__。
503    
504     >This procedure MAY also be used to register information with the IANA
505     about a tag defined by this document, for instance if one wishes to
506     make publicly available a reference to the definition for a language
507     such as sgn-US (American Sign Language).
508    
509     手続きはこの文書で定義される__&&tag&&__について、
510     例えば [CODE(ABNF)[sgn-US]] (アメリカ手話)
511     のような言語の定義の参照先を広く利用可能にしたい場合に
512     IANA に情報を登録するのに使っても__&&MAY&&__。
513    
514     >Tags with a first subtag of "x" need not, and cannot, be registered.
515    
516     最初の__&&subtag&&__が [CODE(ABNF)["x"]]
517     である__&&tag&&__は登録する必要はありませんし、登録出来ません。
518    
519     >The process starts by filling out the registration form reproduced below.
520    
521     過程は下記を複製した登録用紙を埋めることで始まります。
522    
523     [PRE[
524     LANGUAGE TAG REGISTRATION FORM [INS[言語__&&tag&&__登録用紙]]
525     Name of requester : [INS[要求者名]]
526     E-mail address of requester: [INS[要求者の電子メイル・アドレス]]
527     Tag to be registered : [INS[登録する__&&tag&&__]]
528     English name of language : [INS[言語の英語名]]
529     Native name of language (transcribed into ASCII): [INS[言語名 (ASCII に翻字)]]
530     Reference to published description of the language (book or article): [INS[言語についての出版された記述への参照 (書籍又は記事)]]
531     Any other relevant information: [INS[その他関連情報]]
532     ]PRE]
533    
534     >The language form must be sent to <ietf-languages@iana.org> for a
535     2-week review period before it can be submitted to IANA. (This is an
536     open list. Requests to be added should be sent to
537     <ietf-languages-request@iana.org>.)
538    
539     言語用紙はこれが IANA に提出可能となる前に、 <MAIL:ietf-languages@iana.org>
540     に送信して2週間の評価期間を経なければ__&&MUST&&__。
541     (これは公開リストです。追加の要求は <MAIL:ietf-languages-request@iana.org>
542     に送って下さい。)
543    
544     [INS[
545     訳注: [[ML]] に参加するには後者のメイル・アドレスに送るべし、ということです。
546     <http://www.alvestrand.no/mailman/listinfo/ietf-languages> 参照。
547     ]INS]
548    
549     >When the two week period has passed, the language tag reviewer, who
550     is appointed by the IETF Applications Area Director, either forwards
551     the request to IANA@IANA.ORG, or rejects it because of significant
552     objections raised on the list. Note that the reviewer can raise
553     objections on the list himself, if he so desires. The important
554     thing is that the objection must be made publicly.
555    
556     2週間の期間が経過したら、 IETF 応用__&&IETFArea&&__理事により任命された言語__&&tag&&____&&reviewer&&__は要求を
557     <MAIL:IANA@IANA.ORG> に転送するか又はリストでの重大な異議により却下するかします。
558     なお、評価者自身がリストで異議を提出したければそうできます。
559     重要なことは、異議が公的に行われなければならないことです。
560    
561     >The applicant is free to modify a rejected application with
562     additional information and submit it again; this restarts the 2-week
563     comment period.
564    
565     志願者が却下された申し立てを修正して追加情報を加えて、再び提出するのは自由です。
566     この場合2週間のコメント期間が再び開始されます。
567    
568     >Decisions made by the reviewer may be appealed to the IESG [RFC 2028]
569     under the same rules as other IETF decisions [RFC 2026]. All
570     registered forms are available online in the directory
571     http://www.iana.org/numbers.html under "languages".
572    
573     __&&reviewer&&__の決定は他の IETF 判断と同様の規則の元で IESG
574     に訴えられるかもしれません。全ての登録用紙はディレクトリ
575     <http://www.iana.org/numbers.html> の「language」のところから online
576     で入手出来ます。
577    
578     [INS[
579     訳注: <http://www.iana.org/numbers.html#L>
580     ]INS]
581    
582     >Updates of registrations follow the same procedure as registrations.
583     The language tag reviewer decides whether to allow a new registrant
584     to update a registration made by someone else; in the normal case,
585     objections by the original registrant would carry extra weight in
586     such a decision.
587    
588     登録内容の更新は登録と同じ手続きに従います。
589     言語__&&tag&&____&&reviewer&&__は新しい登録者が他の誰かによる登録を更新するのを認めるかどうか決定します。
590     通常の場合、元の登録者の異議はその決定により重みを持ちます。
591    
592     >There is no deletion of registrations; when some registered tag
593     should not be used any more, for instance because a corresponding ISO
594     639 code has been registered, the registration should be amended by
595     adding a remark like "DEPRECATED: use <new code> instead" to the
596     "other relevant information" section.
597    
598     登録の削除はありません。登録された__&&tag&&__がそれ以上使用するべきではなくなった時、例えば対応する
599     ISO 639 符号が登録された時には、登録は「その他の関連情報」の節に「非推奨:
600     [VAR[<新しい符号>]]を代わりに使うべし」と注記を加えるよう改訂するのが良いです。
601    
602     >Note: The purpose of the "published description" is intended as an
603     aid to people trying to verify whether a language is registered, or
604     what language a particular tag refers to. In most cases, reference
605     to an authoritative grammar or dictionary of the language will be
606     useful; in cases where no such work exists, other well known works
607     describing that language or in that language may be appropriate. The
608     language tag reviewer decides what constitutes a "good enough"
609     reference material.
610    
611     注意: 「出版された記述」の目的は、言語が登録されているかどうかやどの言語が特定の__&&rag&&__により参照されているのかを確認しようとする人を助けることを意図しています。
612     多くの場合、その言語の権威的な文法書又は辞書への参照が有用でしょう。
613     そうした成果物が存在しない場合、その言語を説明した又はその言語で書かれたよく知られた成果物が適切かもしれません。
614     言語__&&tag&&____&&reviewer&&__が何を持って「'''十分良い'''」参考文献とするかを決定します。
615    
616     *4. Security Considerations [INS[安全性に関して]]
617     >The only security issue that has been raised with language tags since
618     the publication of RFC 1766, which stated that "Security issues are
619     believed to be irrelevant to this memo", is a concern with language
620     ranges used in content negotiation - that they may be used to infer
621     the nationality of the sender, and thus identify potential targets
622     for surveillance.
623    
624     「このメモと安全性の問題は無関係と信じています」と述べた RFC 1766
625     の発行後に起こった言語__&&tag&&__に係る唯一の安全性の問題は、内容折衝で使われる言語範囲に関するものです。
626     これは送信者の民族の推測して監視の対象となり得る相手を同定するのに使われるかもしれません。
627    
628     >This is a special case of the general problem that anything you send
629     is visible to the receiving party; it is useful to be aware that such
630     concerns can exist in some cases.
631    
632     これは、送信したものは全て受信者側には見えてしまうという一般的問題の特殊な場合です。
633     場合によってはそうした心配が存在し得ることに注意するのは良いことでしょう。
634    
635     >The evaluation of the exact magnitude of the threat, and any possible
636     countermeasures, is left to each application protocol.
637    
638     実際の脅威の大きさと可能な対応策の評価は各応用__&&protocol&&__の仕事です。
639    
640     *5. Character set considerations [INS[文字集合に関して]]
641     >Language tags may always be presented using the characters A-Z, a-z,
642     0-9 and HYPHEN-MINUS, which are present in most character sets, so
643     presentation of language tags should not have any character set issues.
644    
645     言語__&&tag&&__は常に文字 [CODE[A]]〜[CODE[Z]], [CODE[a]]〜[CODE[z]],
646     [CODE[0]]〜[CODE[9]] 及び [CODE(CHARNAME)[HYPHEN-MINUS]]
647     という殆どの文字集合に含まれるもので表現されますから、言語__&&tag&&__の表現は文字集合問題を持たないはずです。
648    
649     >The issue of deciding upon the rendering of a character set based on
650     the language tag is not addressed in this memo; however, it is
651     thought impossible to make such a decision correctly for all cases
652     unless means of switching language in the middle of a text are
653     defined (for example, a rendering engine that decides font based on
654     Japanese or Chinese language may produce suboptimal output when a
655     mixed Japanese-Chinese text is encountered)
656    
657     言語__&&tag&&__に基づく文字集合の__&&rendering&&__の決定についてはこのメモでは触れません。
658     しかし、__&&text&&__中での言語の切り替えの手段が定義されていない限り全ての場合に正しくそうした決定をを行うのは不可能と思われます
659     (例えば、日本語か中文かにより__&&font&&__を決定する__&&rendering&&__機関は日中混合文に遭遇した場合には次善出力しか生成出来ないかもしれません)。
660    
661     *6. Acknowledgements [INS[謝辞]]
662     >This document has benefited from many rounds of review and comments
663     in various fora of the IETF and the Internet working groups.
664    
665     この文書は IETF 及び Internet
666     作業部会の種々の討論場における多段階に亘る評価と注釈によりここまで来ました。
667    
668     >Any list of contributors is bound to be incomplete; please regard the
669     following as only a selection from the group of people who have
670     contributed to make this document what it is today.
671    
672     貢献者を全員挙げることは出来ません。
673     次に示すのはこの文書の今の姿を形作るのに貢献した人々のほんの選り抜きくらいに考えて下さい。
674    
675     >In alphabetical order: [INS[アルファベット順で:]]
676    
677     Glenn Adams, Tim Berners-Lee, Marc Blanchet, Nathaniel Borenstein,
678     Eric Brunner, Sean M. Burke, John Clews, Jim Conklin, Peter
679     Constable, John Cowan, Mark Crispin, Dave Crocker, Mark Davis, Martin
680     Duerst, Michael Everson, Ned Freed, Tim Goodwin, Dirk-Willem van
681     Gulik, Marion Gunn, Paul Hoffman, Olle Jarnefors, Kent Karlsson, John
682     Klensin, Alain LaBonte, Chris Newman, Keith Moore, Masataka Ohta [INS[太田昌孝]],
683     Keld Jorn Simonsen, Otto Stolz, Rhys Weatherley, Misha Wolf, Francois
684     Yergeau and many, many others. [INS[そして沢山の沢山の皆さん。]]
685    
686     >Special thanks must go to Michael Everson, who has served as language
687     tag reviewer for almost the complete period since the publication of
688     RFC 1766, and has provided a great deal of input to this revision.
689    
690     RFC 1766 の発行以後殆ど全期間言語__&&tag&&____&&reviewer&&__を務めてきて、この改訂にも大変協力していただいた
691     Michael Everson には特に感謝します。
692    
693     [INS[
694     訳注: そんな Everson 君について知りたいあなたは
695     <http://www.egt.ie/> 及び <http://www.evertype.com/> を参照。
696     ]INS]
697    
698     *7. Author's Address [INS[著者の連絡先]]
699    
700     '''Harald Tveit Alvestrand'''
701     Cisco Systems
702     Weidemanns vei 27
703     7043 Trondheim
704     NORWAY
705    
706     Phone: +47 73 50 33 52
707     EMail: Harald@Alvestrand.no
708    
709     [INS[
710     訳注: Harald 君がどんなにカッコいいか知りたい君は
711     <http://www.opengroup.org/public/member/q102/alvestrand.htm> を見よう!
712     ]INS]
713     *8. References [INS[参考文献]]
714    
715     [ISO 639] ISO 639:1988 (E/F) - Code for the representation of names
716     of languages - The International Organization for
717     Standardization, 1st edition, 1988-04-01 Prepared by
718     ISO/TC 37 - Terminology (principles and coordination).
719     Note that a new version (ISO 639-1:2000) is in
720     preparation at the time of this writing.
721     [INS[執筆の時点で新版が準備中。]]
722     [INS[そして実際発行されました。]]
723    
724     [ISO 639-2] ISO 639-2:1998 - Codes for the representation of names of
725     languages -- Part 2: Alpha-3 code - edition 1, 1998-11-
726     01, 66 pages, prepared by a Joint Working Group of ISO
727     TC46/SC4 and ISO TC37/SC2.
728    
729     [ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of
730     names of countries - The International Organization for
731     Standardization, 3rd edition, 1988-08-15.
732    
733     [INS[
734     [JIS X 0304] JIS X 0304:1999, 『国名コード』, [[JISC]], 1999-11-20。
735     ISO 3166 に対応。 <http://www.jisc.go.jp/> より入手可能。
736     ]INS]
737    
738     [RFC 1327] Kille, S., "Mapping between X.400 (1988) / ISO 10021 and
739     RFC 822", RFC 1327, May 1992.
740    
741     [RFC 1521] Borenstein, N., and N. Freed, "MIME Part One: Mechanisms
742     for Specifying and Describing the Format of Internet
743     Message Bodies", RFC 1521, September 1993.
744    
745     [INS[
746     [RFC 2045] 『MIME 第1部: Internet メッセージ本体の書式』, [[RFC2045]]。
747     RFC 1521 を廃止。
748     ]INS]
749    
750     [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
751     3", BCP 9, RFC 2026, October 1996.
752    
753     [RFC 2028] Hovey, R. and S. Bradner, "The Organizations Involved in
754     the IETF Standards Process", BCP 11, RFC 2028, October
755     1996.
756    
757     [RFC 2119] Bradner, S."Key words for use in RFCs to Indicate
758     Requirement Levels", BCP 14, RFC 2119, March 1997.
759    
760     [RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
761     Specifications: ABNF", [[RFC2234]], November 1997.
762    
763     [RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
764     Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
765     Transfer Protocol -- HTTP/1.1", [[RFC2616]], June 1999.
766    
767     [RFC 2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of
768     Understanding Concerning the Technical Work of the
769     Internet Assigned Numbers Authority", RFC 2860, June
770     2000.
771    
772     *Appendix A: Language Tag Reference Material [INS[言語__&&tag&&__参考物件]]
773     >The Library of Congress, maintainers of ISO 639-2, has made the list
774     of languages registered available on the Internet.
775    
776     ISO 639-2 の維持者である米国議会図書館は登録された言語の一覧を Internet
777     で利用可能にしています。
778    
779     >At the time of this writing, it can be found at
780     http://www.loc.gov/standards/iso639-2/langhome.html
781    
782     執筆の時点ではこれは <http://www.loc.gov/standards/iso639-2/langhome.html>
783     にあります。
784    
785     >The IANA registration forms for registered language codes can be
786     found at http://www.iana.org/numbers.html under "languages".
787    
788     登録された言語符号の IANA 登録用紙は <http://www.iana.org/numbers.html>
789     の「language」の欄にあります。
790    
791     >The ISO 3166 Maintenance Agency has published Web pages at
792    
793     ISO 3166 維持機関は Web 頁を出版しています。
794    
795     <http://www.din.de/gremien/nas/nabd/iso3166ma/>
796    
797     *Appendix B: Changes from RFC 1766 [INS[RFC 1766 からの変更点]]
798     - Email list address changed from ietf-types@uninett.no to ietf-languages@iana.org
799     - Updated author's address
800     - Added language-range construct from HTTP/1.1
801     - Added use of ISO 639-2 language codes
802     - Added reference to Library of Congress lists of language codes
803     - Changed examples to use registered tags
804     - Added "Any other information" to registration form
805     - Added description of procedure for updating registrations
806     - Changed target category for document from standards track to BCP
807     - Moved the content-language header definition into another document
808     - Added numbers to the permitted characters in language tags
809    
810     -電子メイル・アドレスを <MAIL:ietf-types@uninett.no> から <MAIL:ietf-languages@iana.org> に変更
811     - 著者の連絡先を更新
812     - [[HTTP/1.1]] の [CODE(ABNF)[language-range] を追加
813     - ISO 639-2 言語符号の使用を追加
814     - 米国議会図書館の言語符号の一覧への参照を追加
815     - 登録済み__&&tag&&__を使うように例を変更
816     - 登録用紙に「その他の情報」を追加
817     - 登録更新手続きの記述の追加
818     - 文書の分類を標準化過程から BCP に変更
819     - [CODE[content-language]] __&&header&&__の定義を他の文書に分離
820     --訳注: [[RFC3282]] にあります。
821     - 言語__&&tag&&__で認められる文字に番号を追加
822     *Full Copyright Statement
823     >Copyright (C) The Internet Society (2001). All Rights Reserved.
824     __&&RFCFullCopyright&&__
825     __&&RFCAcknowledgement&&__
826     *メモ
827     -[14] ''ISO 639 Joint Advisory Committee'' <http://lcweb.loc.gov/standards/iso639-2/iso639jac.html>
828     -[15] ''ISO 639-1 Registration Authority'' <http://linux.infoterm.org/infoterm-e/raiso639-1_start.htm>
829     -[16] ''ISO 639-2 Registration Authority - Library of Congress'' <http://www.loc.gov/standards/iso639-2/iso639-2ra.html>
830     -[17] ''LANGUAGE TAGS'' <http://www.iana.org/assignments/language-tags>
831     -[18] ''Directory of language tag applications'' <http://www.iana.org/assignments/lang-tag-apps.htm>

admin@suikawiki.org
ViewVC Help
Powered by ViewVC 1.1.24