[71] 言語タグは、自然言語を識別するための短い文字列です。 ISO の定める言語符号などの組み合わせにより様々な言語や言語と地域や用字系などの組み合わせによるバリエーションを表現することができます。 言語タグは IETF により BCP 47 として標準化されており、様々な IETF のプロトコルの他 HTML や CSS などの Web標準でも広く使われています。
[191] IETF として初めて言語タグを規定した最初の正式な仕様は RFC 1766 でしたが、 RFC 3066、RFC 4646 を経て RFC 5646 が現行仕様となっています。 RFC 3066 と RFC 4646 の間に大規模な非互換変更が行われています。 (詳しくは歴史の項を参照してください。)
[84] IETF BCP 47 は、現在 RFC 5646 と RFC 4647 により構成されています >>72 1.。
[188] 言語タグで使うことができる部分タグや祖父化言語タグは IANA の登録簿があります (>>74、>>76)。
[189] RFC 1766 や RFC 3066 の時代は ISO の仕様から導出できない追加の言語タグを登録してもよいという形でしたが、 RFC 4646 以降は原則としてすべて登録簿にある部分タグを組み合わせて使う形に改められています。
[190] RFC 3066 までの時代の登録簿は機械処理には適さない文書でしたが、 RFC 4646 以降は機械処理可能な形式になっています。 その書式は RFC 4646 3. で規定されていましたが、 (非互換に) 変更されて現在は RFC 5646 3. で規定されています。
[53] ただし IANA が公開しているファイルはこの書式に必ずしも適合していません。
機械処理して利用する場合は、適合していなくてもある程度扱えるような配慮が必要です。
改行は CRLF ではなく、省略可能な CR と必須の LF の列として処理する必要があります。
また区切りの %% の後に空白が来ても、無視する必要があります。
[125] 正式には「言語タグ」と呼ばれます。
[126] Wikipedia は IETF 仕様であることから「IETF言語タグ」 と呼んでいます。
[127] 「言語コード」と呼ばれることもありますが、 言語タグ仕様上は言語タグに含まれる最初の部分タグ (として用いられる ISO の言語コード) のことを指すので、 全体として言語コードと呼ぶのは不正確です。
[128] 値が言語タグとなる属性の名前などでは「lang」
と略されることがよくあります。プログラミング言語の変数などの名前としては
「tag」や「langtag」などと略されることもあります。
[55]
言語タグは、
1つ以上の部分タグを
HYPHEN-MINUS (-)
で連結した文字列です。
例えば、
ja-Latn-US... は、3つの部分タグから構成される言語タグです。狭義の言語が日本語 (
ja) であって、ラテン文字という用字系
(Latn) によって表記され、アメリカ合衆国という地域
(US) で用いられている言語を表しています。[230] RFC は言語タグを ABNF 構文で規定しています。
[254] IETF では一般的に ABNF で規定された構文を US-ASCII、 たまに UTF-8 で符号化される文字列たるバイト列と解釈しています。
[255] しかしながら、 言語タグはいろいろな場面で使われており、 あくまで ABNF で規定された文字列と解されています。 従って HTML や JSON で使われるときは、 その記述に使われる文字コードの普通の文字列として扱われます。
[261] Unicode言語タグは、 Unicode に含まれる通常の ASCII文字のかわりに、 タグ文字に含まれるASCII文字相当を使った文字列としています。
[56] 部分タグは、 (狭義の) 言語や地域などを表す文字列です。 部分タグを複数組み合わせて細かく指定できます。 部分タグの長さや位置は、それが何を表すかによって決まっています。 RFC 4646 2.1.
[281] 言語タグの変種であるUnicode言語識別子、Unicodeロケール識別子は部分タグのことを 「符号」とも呼んでいます。
[58] 言語タグの (ASCII の) 大文字と小文字は、区別されません。 RFC 4646 2.1., RFC 5646 2.2.1.
[59] 区別はされませんが、 IANA 登録簿の書式が推奨されています。
RFC 4646 2.1., RFC 5646 2.2.1.
[164] 拡張の部分タグについては、すべて小文字に正規化されることが期待されています。 RFC 5646 2.2.6.
[121] しかしこの正規形への機械的な変換は、言語タグの構文を踏まえた若干複雑な処理が必要になります。 分野や実装によっては、 BCP 47 の推奨を無視してすべて小文字に変換することもあります。
[231] 言語タグには長さ制限はありません。一般的には6文字程度に収まりますが、 それより長い言語タグもあります。 RFC 4646 4.3., RFC 5646 4.4.
[232] プロトコル等で長さを制限する場合であっても、最低35文字は認めなければなりません。 RFC 5646 4.4.
[234] 実装や仕様は長い言語タグを扱えなくても構いませんが、 何文字まで扱えるのか、長すぎる時にどうなるのかを文書化するべきです。 また実装は長すぎる時に警告するべきです。 RFC 4646 4.3., RFC 5646 4.4.
[235] 実装は長い言語タグを切り落としていく時に、部分タグの途中でぶった切ってはなりません。 RFC 4646 4.3., RFC 5646 4.4.
[268] RFC 1766 では、構文は制限が緩い単純なもので、
... という制限しかありませんでした RFC 1766 2.。
... という制限になりました RFC 3066 2.1。
[155] 拡張は、 言語や言語タグと併用される、言語以外の情報を表すために使える言語タグの拡張機構です。 RFC 4646 2.2.6., RFC 5646 2.2.6.
[161] 拡張は、 singleton と呼ばれる1文字の部分タグと、 それに続く1個以上の2-8文字の英数字の部分タグにより構成されます。 singleton は拡張の種類を表すものであり、 IANA に登録しなけてばなりません。 続きの部分タグは、その拡張の仕様に従わなければなりません。 RFC 4646 2.2.6., RFC 5646 2.2.6. 拡張は続きの部分タグを構文の制約の元で自由に使うことができます。 拡張が妥当であるかどうかは、その仕様によって定められます RFC 5646 2.2.9.。
[158]
IETF言語タグの拡張部分タグは、
言語、拡張言語、用字系、地域、異体の後で、
私用の前になければなりません。
言語タグ全体が私用であって x- から始まる場合には拡張を使うことはできません。
RFC 4646 2.2.6., RFC 5646 2.2.6.
[317]
ScriptLangTag
では、
用字系部分タグ、
地域部分タグ、
異体部分タグのいずれよりも後で私用部分タグより前に、
0個以上書けます。
>>117
[159] 拡張は複数個含めることができますが、同じ種類 (singleton) の拡張を複数個同時に含めてはなりません。 RFC 4646 2.2.6., RFC 5646 2.2.6.
[163] 拡張の順序は大文字・小文字不区別のASCII順に正準化するべきです。 RFC 4646 2.2.6., 4.4., RFC 5646 2.2.6., 4.5. 順序に意味は無いようです。
[318]
ScriptLangTag を規定する OpenType の仕様書は、
拡張Uや拡張Tより後にも更新されているにも関わらず、
仕様書執筆時点で
ScriptLangTag 用に定義された拡張はなく、
何か指定されても無視される、
としています。
>>117
[319]
不明瞭ですが、特に ScriptLangTag 用だと規定がない限りは、
ScriptLangTag では使えないということでしょうか。
[165] 私用部分タグは、 特定の文脈で私的な合意の元に意味のある言語の区別を示すものです、 RFC 4646 2.2.7., RFC 5646 2.2.7. 私用の部分タグは登録なしに自由に使うことができますが、 合意の範囲外では意味を共有することができませんし、 異なる当事者間の同意により同じ文字列が異なる意味で理解されることもあり得ます。
[166] x だけの1文字の部分タグの後に1つ以上の私用の部分タグを使うことができます。
私用の部分タグは1文字以上8文字以下の任意の英数字の列です。
RFC 4646 2.2.7., RFC 5646 2.2.7.
en-US と en-X-US は同じ言語を表すとは限りません。[169] 他に候補がある場合や一般的な情報交換に供する場合には私用の部分タグを使うべきではありません。 RFC 4646 2.2.7., 4.5., RFC 5646 2.2.7., 4.6.
[170] 言語部分タグや地域部分タグなどにもそれぞれ私用に割り当てられた部分タグがありますが、 それらはここでいう私用の部分タグとは別のものです。 私用に割り当てられた部分タグは言語タグ仕様上、それぞれ言語、地域などの意味を保持していますが、 ここでいう私用の部分タグは言語タグ仕様上不透明なものです。 従って私用部分タグよりは私用に割り当てられた各種の部分タグを使うべきである RFC 4646 4.5., RFC 5646 4.6. とされています。
[183] 利用者は、私用部分タグを除き、 IANA に登録されていない部分タグを使ってはなりません。 RFC 5646 2.2.9.
[299] 私用部分タグとは別に、 拡張部分タグによってはその一部を私用としていることがあります。
[21]
ScriptLangTag では、私用部分タグは無視しても良いとされます。
>>117
[168] IETF言語タグの私用部分タグは他の部分タグより後になければなりません。 言語部分タグなしで私用部分タグだけを使うこともできます。 RFC 4646 2.2.7., RFC 5646 2.2.7.
[2]
ScriptLangTag
では、
他の部分タグの後に1組私用部分タグを置けます。
>>117
[25] 体系的な利用例がいくつかあります。
[41] CLCR の long code がこれらしきものを使っています。
[309] LIISコードが x-liis* を使っています。
[222] Semantic Web の世界では x-d-* が提案されています。
[312] Class Utilities | Apps Script | Google Developers, , https://developers.google.com/apps-script/reference/utilities/utilities
<html
lang="en"
dir="ltr"><html
lang="id-x-mtfrom-en"
dir="ltr"><html
lang="zh-TW-x-mtfrom-en"
dir="ltr"><html
lang="ar-x-mtfrom-en"
dir="rtl"><html
lang="th-x-mtfrom-en"
dir="ltr">English 原文と各言語の翻訳があり、
内容折衝により、または利用者の選択により切り替えられる。
言語タグは選択言語により切り替わり、
English 以外では私用部分タグ x-mtfrom-en が付く。
[322]
Vimeo
は私用部分タグ
-x-autogen
を使っています。
>>320, >>321
[323]
公開されているドキュメントに記載されているのは
en-x-autogen
だけで >>320, >>321、
しかも「at the present time」に於いてEnglishのみであると明言されています
>>320
し、ここに指定されるのが IETF言語タグであるかも定かではありません。
[324]
しかし実サイトで DOM TextTrack の language
が
ja-x-autogen、
label
が
日本語 (自動生成)
となるものが利用されていることが確認できます。
language の値は BCP 47言語タグと定められています。
[325]
おそらく English 以外にも日本語を含むいくつかの言語に現在は拡大されているのでしょう。
x-autogen は人間により作成されたデータではなく、
機械的に音声から文字データに変換されたものであることを意味すると思われます。
To enable automatically generated closed captions instead, provide the value
en-x-autogen. Please note that, at the present time, automatic captions are always in English.
埋め込みコードのように自動生成されたキャプションを追加するには、"texttrack=en-x-autogen"を追加する必要があります。
[171] RFC 1766 と RFC 3066 では、1つ目の部分タグ
(当時の用語でいう一次タグ) を
x とすることで私用を表していました。
2つ目の部分タグ (当時の用語でいう最初の部分タグ)
について、 RFC 1766 では何も規定がなく、 RFC 3066
では1文字のものは将来の拡張のために予約するとされていました。
3つ目以降の部分タグについては特に制約なく、 x
を使ったり登録したりすることも認められていました (特に私用という意味は割り当てられていませんでした)。
[57] RFC 1766 や RFC 3066 の時代に登録された言語タグの中には、 RFC 4646 以後の部分タグの定義に従っていないものがありますが、 それも互換性のため引き続き RFC 4646 以後の仕様でも使うことが認められています RFC 4646 2.2.8., RFC 5646 2.2.8.。
grandfathered = 1*3ALPHA 1*2("-" 2*8(ALPHA / DIGIT))... という構文を認めていました RFC 4646 2.1.。
[86] ところがこれでは RFC 4646 以後のより制限が厳しい構文で認めていないものがこちらの構文では認められることになってしまい、 構文の定義として意味をなしていない状態でした。
[87] RFC 5646 では RFC 3066 までに登録されたものを構文定義に列挙する形となっており、 この問題は解消しています。
[89] RFC 5646 では、新しい構文に一致しないものの例外的に認めているもの (irregular) と、 新しい構文に一致するものの新しい構文から導かれる意味と違う意味で解釈されるべきもの (regular) の2種類に分類されています。 RFC 5646 2.1., 2.2.8.
[90] "en-GB-oed" / "i-ami" / "i-bnn" / "i-default" / "i-enochian" / "i-hak" / "i-klingon"
/ "i-lux" / "i-mingo" / "i-navajo" / "i-pwn" / "i-tao" / "i-tay" / "i-tsu" / "sgn-BE-FR"
/ "sgn-BE-NL" / "sgn-CH-DE"irregular に分類されている言語タグ
[91] "art-lojban" / "cel-gaulish" / "no-bok" / "no-nyn" / "zh-guoyu"
/ "zh-hakka" / "zh-min" / "zh-min-nan" / "zh-xiang"regular に分類されている言語タグ
[174] en-GB-oed は英語の一種ですが、それ以外は単独の言語を表しています。
その多くは単独の一次言語部分タグが新たに割り当てられており、
IANA 登録簿の Preferred-Value に示されています
RFC 4646 2.2.8., RFC 5646 2.2.8.。
[175] なお、 RFC 4646 で祖父化に分類されていた言語タグのうちの幾つかは、 RFC 5646 のもとでは言語と拡張言語の組み合わせと解されるため、 冗長に再分類されています。
[300] t 拡張は言語タグをその一部として含めることができますが、
irregular の使用は禁止されています。
[23]
ScriptLangTag は祖父化言語タグ構文を認めていません。
i-default[228] i-default は、既定の言語を示すことが要求されている場合を除き、
使うべきではありません。
RFC 5646 4.1.
[213] 大原則として、言語タグを構成する時は、可能な限りで粗すぎず、細かすぎない、 必要十分な粒度で言語を特定できるように部分タグを選択するべきです。 RFC 4646 4.1., RFC 5646 4.1.
[214] 例えば、殆どの場合 de-CH-1996 (1996年正書法) は細かすぎで、
de-CH で十分です。
[194] IANA 登録簿には Deprecated (非推奨) 欄があります。 (値は非推奨になった日付です。) RFC 4646 3.1., RFC 5646 3.1.2.。
[202] 妥当性を検証する実装は非推奨な部分タグやタグを使うべきではありません RFC 4646 3.1., 4.4., RFC 5646 3.1.6., 4.5.。
[203] 非推奨な部分タグや言語タグには好ましい値が指定されていることもあれば、 指定されていない (代替がない) こともあります。
[195] IANA 登録簿には Preferred-Value (好ましい値) 欄があります。 RFC 4646 3.1., RFC 5646 3.1.2.。
[204] 非推奨かつ好ましい値が指定されている場合にあっては、 好ましい値が最善の選択として利用されるべきです。 拡張言語以外で好ましい値が指定されているなら、必ず非推奨でもあります。 RFC 4646 3.1., RFC 5646 3.1.7.
[205] なお、好ましい値は必ずしも意味的に等価ではありません。例えば地域の部分タグは国の独立などがあって変化した時に新しい国の符号が好ましいとされますが、 必ずしも以前の国と同じ範囲ではありません。
i-* 形式の言語タグの多くは、
現在では ISO の言語符号が割り当てられていて、そちらを使うのが好ましいとされています。
RFC 3066 の当時も、 ISO の言語符号が割り当てられたらそちらを使わなければならない
RFC 3066 2.3 とされていました。[287]
これは一見IANA登録簿を読んで機械処理できそうなのですが、
実際はそうとは限りません。
[199] IANA 登録簿には Prefix (接頭辞) 欄があります。 その値は、当該部分タグを使う時に接頭辞となっているべき言語タグです。 (接頭辞となっているか否かは、拡張濾過算法に拠ります。) 接頭辞は拡張言語と異体の登録にのみ含まれます。 RFC 4646 3.1., RFC 5646 3.1.2., 3.1.8.。
[277] Prefix に一致するかどうかは拡張濾過算法により判断されるので、
必ずしも文字列として接頭辞になっていなくても構いません。例えば
es-Latn-CO-x-private に es-CO は接頭辞として含まれています。
[237] 言語タグは正準形であるべきです。 RFC 4646 4.4., RFC 5646 4.5.
[238] 整形式言語タグは次の手順で正準化できます
RFC 5646 4.5.。
[247] en-b-ccc-bbb-a-aaa-X-xyz は正準形ではありませんが、
en-a-aaa-b-ccc-bbb-x-xyz は正準形です。
[242] 整形式言語タグは次の手順で拡張言語形に変形できます。
RFC 5646 4.5.
[248] 正準形では必ず拡張言語が含まれない形になるので、言語と拡張言語の両方を含めた形の方が便利なときには拡張言語形が良いとされています。
[176] 言語タグの適合性については、整形式と妥当の2つの基準が設けられています。
[177] 言語タグは ABNF 構文に一致する時、整形式です。 RFC 5646 2.2.9.
[32] 整形式とは、構文として正しい言語タグであるということを意味しています。 構文として正しいとしても、意味のある言語タグを構成しているかどうかはわかりません。
[33] 妥当性は、整形式性、つまり構文的に正しいかどうかに加えて、 IANA登録簿に登録されて意味が明確になっていることを表しています。
[36] 妥当な言語タグは仕様上「適切」な言語タグであるといえますが、 妥当でないからといって言語タグとして不適切ということでもありません。 例えば私用の部分タグは定義上非妥当になります。
[173]
RFC 1766 や RFC 3066 に基づく手続きにより IANA に登録された言語タグの中には、
RFC 4646 以後の仕組みに基づかず祖父化扱いされているものの他、
zh-Hant のように RFC 4646
以後の部分タグの組み合わせで表現できるものがいくつもあります。
このような言語タグもまた RFC 4646 以後の IANA
登録簿に含まれており、「冗長」と分類されています
RFC 4646 2.2.8., RFC 5646 2.2.8.。
[184] RFC 5646 は言語タグの適合性を定義していますが、 RFC 4646 はそれを処理する実装の適合性を定義していました。実装は >>185 と >>186 のいずれかを明示的に引用して適合性を主張するべきだとされていました RFC 4646 2.2.9.。
[185] RFC 4646 における整形式性を検証する実装は、 >>177 に加えて、 >>181 もチェックしなければなりませんでした。 RFC 4646 2.2.9.
[186] RFC 4646 における妥当性を検証する実装は、 >>178 に加えて、 対応している拡張について妥当性をチェックすることが求められていました。 異体と拡張言語について、登録簿上の Prefix の要件を満たしているかチェックすることも求められていました。 更に、対応している登録簿や拡張の版・日付について指定することが求められていました。 RFC 4646 2.2.9.
[187] RFC 4646 についても RFC 5646 についても、妥当であるからといって RFC 上のすべての要件を満たしていることにはなりません。
[114] 構文レベルで不適切な言語タグもしばしば使われています。
<html xmlns="http://www.w3.org/1999/xhtml" lang="ja-JP.UTF-8" xml:lang="ja-JP.UTF-8">
[278] 拡大イメージ表示, https://screenstore.jp/shop/image_view.html?image=000000004236
<meta http-equiv='CHARSET' content='EUC-JP'> <meta http-equiv='CONTENT-LANGUAGE' content='Japanese'> <meta http-equiv='Content-Type' content='text/html; charset=EUC-JP'>
<html lang="en_US">
<html lang="de_DE">
<html lang="en_us" prefix="og: http://ogp.me/ns#">
<html lang="en_us" prefix="og: http://ogp.me/ns#">
<!doctype html>
<html lang="ja,zh">
The locale is set in RFC-3066 format using the lang parameter:
lang=language-region
language - Two-letter language code. Specified in ISO 639-1 format. Sets the language for objects on the map (toponyms and controls).
region - Two-letter country code. Specified in ISO 3166-1 format. Determines regional settings such as measurement units (for indicating distances between objects or driving speeds on a route).
Note. For the regions RU, UA and TR, distance is shown in kilometers; for US, it is shown in miles.
The following locales are currently supported:
lang=tr-TR
lang=en-US (distance in miles)
lang=en_RU
lang=ru-RU
lang=ru_UA
lang=uk_UA
Note. In early versions of the API, the locale was specified after a dash. For example, en-US. This notation is supported for backward compatibility, but is not recommended.
A code that indicates the language of the article. Use the IANA.org language subtag registry to find the appropriate code; e.g., en for English, or the more specific en_GB for English (U.K.) or en_US for English (U.S.).
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US.UTF-8" xml:lang="en-US.UTF-8">
<html lang="zh_tw">
[288]
CKAN という世界中の政府機関等で使われている CMS が
fa_IR や zh_Hans_CN 式の不正な言語タグを使っているために、
今も世界中のサーバーでおかしな言語タグが量産されています...
[308]
Chrome は - と _ を同一視しているみたいです。
その上で、既知の言語タグと一致するか、 - か _
が続くなら、その言語タグとみなすようです。
(少なくてもフォントの選択についてそのようにみえます。)
Firefox も似たような挙動ですが、 - でも _
でもない文字が続く場合の動作がもう少し複雑なようです。
[276] 言語タグとワイルドカードによって言語タグの集合を表現する「言語範囲」
や言語範囲を複数列挙した「言語優先度リスト」が
HTTP の Accept-Language: などで用いられています。
[8] 言語はロケールを構成する一要素であり、言語とロケールは別の概念ではありますが、言語はロケールの最重要要素でもありますから、同一視されることもよくあります。
[9] 言語タグは Unix 系システムのロケールの識別子と (区切り文字が違うことを除けば) 非常によく似ていて、歴史的にも深く関わっています。
[40] この区切り文字の違いが曲者で、
言語タグで間違って _
を使ったり、
ロケールの記述で間違って -
を使ったりする誤用例が散見され、それによる不具合もまま見かけます。
ややこしいことにロケール識別子の仕様もいろいろあって、
中には - を使うものもあります。
[10] UTS #35 は元は Unix ロケール識別子由来の独自の構文を規定していましたが、
現在は言語タグの u 拡張や t 拡張という形で両者の要素を混在させたスタイルになっています。
[12] 言語タグ本体と u 拡張、 t 拡張を合わせればロケールのかなりの側面が一つの識別子により記述できますが、
それでもまだカバーされてない範囲もあります。
[94] MIME では、 RFC 2231 で拡張された引数の値の構文で RFC 1766 により登録された言語タグの値を指定できるとされています。
[95] また encoded-word でも RFC 2231 の拡張により、RFC 1766
により登録された言語タグの値を指定できるとされています。
[208]
MIME や HTTP の Content-Language:
ヘッダーの値や HTTP の Accept-Language:
ヘッダーの値の一部として言語タグが使われています。
[211]
HTML の lang 属性や hreflang
属性の値として言語タグが使われています。
[212]
XML の xml:lang 属性の値として言語タグが使われています。
[262] RFC 3367 - Common Name Resolution Protocol (CNRP), , https://tools.ietf.org/html/rfc3367#page-10
The language associated with a resource. The default type of this property is 'RFC1766' and the vocabulary is drawn from the list of languages in RFC 1766 [4]. If RFC 1766 is updated, then the values listed in the updated version are also valid for this type.
[263] 改訂は想定しながら、非互換変更までは想定できず梯子を外された事例。
[27] 言語サポート | Cloud Speech-to-Text ドキュメント | Google Cloud, , https://cloud.google.com/speech-to-text/docs/languages?hl=ja
[106] Language Metadata Table (LMT) はIETF言語タグのプロファイルです。 >>102
[107] 映像系の企業の標準化団体で、映像や音声の言語の識別に使うための言語タグの一覧を管理しています。 >>102
[110] EIDR language code は LMT を採用しつつ、中文言語タグは例外的な規定を設けています。 >>109 つまり少しだけ違うプロファイルです。
[47] GREEの国際化, その4 - 言語コード | GREE Engineering, https://labs.gree.jp/blog/2012/11/6439/
[144] 言語タグについて構文的に正しいかどうか以上の処理を行いたい場合、 データファイルを用意する必要があります。
[145] 理論上はプラットフォームのロケールシステムの一部として提供されている可能性もありますが、 実際にはそのようなプラットフォームは一般的ではありません。 (プラットフォーム独自のロケールシステムに関するデータは提供していても、 言語タグ一般のデータは提供されません。)
[148] >>146 に、 JSON 形式のデータファイルがあります。 IANA登録簿や Unicode の登録簿に登録された部分タグの情報が含まれています。
[149] 言語タグの情報は、言語というそう頻繁に変わらなそうなものを扱ってはいますが、 数ヶ月に一度程度という意外な高頻度で改訂されています。漏れている言語が追加されるなど、 細かな変更がちょくちょく行われているようです。
[150] 従って、言語タグの情報を扱うシステムは、その情報を定期的に更新する機構を組み込んでおく必要があります。
[37] 非常に古い HTTP では、 RFC 1766 の "-" を使う方法ではなく POSIX の locale 名のように "_" で区切っていました。
[38] >>37 現在でも間違ってこちらが使われる可能性がありますから、実装は両方に対応しているといいかもしれません。
[39] HTML 3.0 では lang 属性の値に "-" の代わりに "." を使っていました。 (The Body Element and Related Elements http://www.w3.org/MarkUp/html3/docbody.html#Body)
[4] RFC 1766 は、言語タグを規定する最初の RFC でした。 RFC 3066 により廃止されました。
[267] IETF で初めて言語タグを規定した正式な仕様書が RFC 1766 です。 RFC 1766 は標準化過程 RFC で、提案標準でした。
[290] IETF における国際化について議論している RFC 2130 と RFC 2277 では、言語タグを IETF での標準的な言語識別方法としています。
The term 'language tag' should be reserved for the short identifier of RFC 1766 [RFC-1766] that only serves to identify the language. While there may be other text attributes intimately associated with the language of the document, such as desired font or text direction, these should be specified with other identifiers rather than overloading the language tag.
[257] HTTP/1.1 (RFC 2068, RFC 2616) は、RFC 1766 を引用しつつも独自に言語タグの構文を規定しています。
A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and Content-Language fields.
言語札識別子は、人間が他の人間と情報の通信をするために話したり書いたりその他伝達する自然言語を識別します。
計算機言語は陽に除外します。 HTTP
は Accept-Language 欄と Content-Language
欄の中で言語札を使います。
The syntax and registry of HTTP language tags is the same as that defined by RFC 1766 [1]. In summary, a language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags:
HTTP 言語札の構文と登録簿は RFC1766 で定義されているものと同じです。 要約すると、言語札は一つ以上の部分の組合せ、すなわち 主言語札と空かもしれない部分札の系列です。
- language-tag = primary-tag *( "-" subtag )
- primary-tag = 1*8ALPHA
{2068,2616} subtag = 1*8ALPHA- {Errata} subtag = 1*8(ALPHA / DIGIT)
White space is not allowed within the tag and all tags are case-insensitive. The name space of language tags is administered by the IANA. Example tags include:
空白は札の中では認められず、すべての札は大文字・小文字を区別しません。 言語札の名前空間は IANA で管理します。札の例:
en, en-US, en-cockney, i-cherokee, x-pig-latin
where any two-letter primary-tag is an ISO-639 language abbreviation and any two-letter initial subtag is an ISO-3166 country code. (The last three tags above are not registered tags; all but the last are examples of tags which could be registered in future.)
ここで、2文字の主札は ISO639 の言語の略語で、 2文字の最初の部分札は ISO3166 国名符号です。 (上の最後の3つの札は登録されていない札です。最後のもの以外は将来登録されるかもしれない例です。)
[258] 元々の定義は RFC 1766 に基づく、数字が認められていないものでした。 正誤表により RFC 3066 に基づく数字が使える定義に改められています。
[1] 言語札は RFC 1766 が定義していましたが、 RFC 3066 に改訂されました。
[78] RFC 1766 は標準化過程 RFC (提案標準) でしたが、 RFC 3066 以後は BCP (BCP 47) となっています。
[275] RFC 3066 は全面改訂により RFC 4646 に変わっています。 RFC 4646 は構文についても登録の仕方についても根本的に改めており、 完全には互換性がない新しい仕様となっています。
[256] RFC 4645 は、 RFC 4646 の標準化に際して改めて作成された新しい IANA 登録簿の初期状態の内容 (ILSR) を用意した方法について説明しています。
[79] RFC 5646 への改訂では、仕様の全体的な構成と内容は変わっていませんが、 細かな編集上の変更が数多く加わっています。また、前の版で未定義だった拡張言語が正式に定義されています。
[80] その他、前の版でブラックホールになっていた祖父の ABNF 定義が改められ、何でも一致する定義から、 RFC 3066 時代までに登録されて現在の基準には沿わない言語タグをすべて列挙する形に改められています。
[81] IANA登録簿の書式が US-ASCII から UTF-8 に変更されています。
[65] RFC 4646 が出てからまだ3年しか経ってないのに改訂とか超うけるwwwwwwwwwwwwwwww
[66] 調べてみたら RFC 1766 → RFC 3066 で5年、 RFC 3066 → RFC 4646 で5年なのねwwwwwwwww
[70] >>65 逆に、 IETF でたった3年で改訂版を出せるのが奇跡かもwww
[69] Diff: rfc4646.txt - rfc5646.txt ( 版) http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc4646.txt&url2=http://www.ietf.org/rfc/rfc5646.txt
だいぶ変わってるな・・・。
[253] RFC 5645 は、 RFC 5646 への改訂に際して行われた大規模な IANA 登録簿の追加と改訂の内容について説明しています。
[280] WebHACC 付属のツール https://suika.suikawiki.org/gate/2007/html/langtag/?tag=en で言語タグの構文解析結果や適合性エラーを見ることができます。
[192] HTML の lang 属性や XML
の xml:lang 属性は IETF の言語タグを値に採用しています。
これらの属性は言語情報の不在を示すために空文字列も値として認めています。
[311] Android の設定修飾子は IETF言語タグを構文的に変形したものです。
[314]
OpenType
の
ScriptLangTag
は
IETF言語タグと非常によく似ていますが、
用字系を中心としたものです。
[63] OpenDocument 1.0 の
dc:language 要素の内容は RFC 3066
言語札に似たものです。
[316]
POSIX のロケール識別子は - ではなく _ を区切りにしていますが、
IETF言語タグと非常によく混同されています。
%LanguageCode; 型 (HTML 4)[151] HTML
の DTD
で使われている %LanguageCode 型は、
言語札を表します。
[153] HTML 4 本文 (規定), DTD 注釈 (参考) は RFC 1766 を参照しています。 XHTML 1.0 SE DTD 注釈 (規定), XHTML m12n 抽象モジュール定義 (規定) XHTML m12n 4.3 は RFC 3066 を参照しています。
%LanguageCode (HTML 4, XHTML 1.0)LanguageCode (XHTML m12n)language-code(HTML 4)
NAME (HTML 4)NMTOKEN (XHTML 1.0)[156] HTML 4 は、 RFC 1766 で定義された言語札を参照しています。
大文字・小文字は区別されません。
SGML
的には NAME です
(つまり、 HTML 4 SGML宣言の元では大文字に正規化されます)。
[160] RFC 1766 はすでに改訂されていて、 ISO 639 の3文字符号に対応するとか構文上の重要な変更があります。
では HTML 4 で新しい構文の言語札を使っても良いのか、 微妙なところです。
引用規格は最新版を適用するかどうかの規定はないのですけど、 IW:HTML4:"references.html#ref-RFC1766" は I-D に言及しています。少なくても HTML 4 の著者は改訂があることに気づいているし、読者にもそれなりには注意を促しているのですから、 新しい構文の言語札を使っても、ばちは当たらないでしょう。 (無茶苦茶な論理だ。)
[200] この型が使われているのは、 lang 属性や hreflang 属性ですな。
[201] lang 属性は XML
本体仕様に取り込まれ、 xml:lang
属性になりました。こちらは後に空文字列を認めるように修正されています。
[326] Language Codes, InetSDK, , https://web.archive.org/web/20001115020300/http://msdn.microsoft.com/workshop/Author/dhtml/reference/language_codes.asp
[22] RFC 3066 によれば、第2小札以降は文法規則 (特に、字数制限: 3〜8文字に注意) に従う限り自由に使っていいことになっています。このため言語札の一意性は保障されないでしょう。 もっとも言語はそう簡単に増えたり減ったりするものではないですから、滅多なことでは衝突しないでしょうが・・・。
[50] Published subjects for languages in ISO 639 http://psi.oasis-open.org/iso/639/
言語符号の URI参照。 ISO 639 の3文字符号が使われてます。
IETF はこれを見習ってとっとと言語札の URI 参照表現を定義してください:) (名無しさん 2005-01-10 00:06:08 +00:00)
[51] ちょっとしたメモ - 地理コードのURI http://www.kanzaki.com/memo/2005/01/09-1 (名無しさん)
[52]
1月11日付で、No linguistic content
を表すzxxが追加されました。
Used to declare the absence of linguistic information
。
(名無しさん 2006-02-07 03:54:43 +00:00)
[54] I'm not a Klingon : Change in .Net Framework Culture Names for Windows Vista http://blogs.msdn.com/shawnste/archive/2006/06/02/615674.aspx (名無しさん 2006-11-08 13:18:26 +00:00)
[61]
Language Tags and Locale Identifiers for the World Wide Web (2006-12-19 13:39:55 +09:00 版) http://www.w3.org/International/core/langtags/
[209] RFC 4646/RFC 5646、同じ要件が何度も微妙に違う表現で繰り返されたりしていて、 とても読みにくくて悪い仕様書だなあ。
[210] IANA 登録簿や ISO の仕様に依存しているせいで仕様書本体の規定に抽象的なものが多くて理解しづらいし。
[227] あとは同じものについての話題があちこちの章にばらばらに出てくるからでしょうなー。 今の章構成もそれなりに意味があるのだろうけど、もっとテーマごとにまとめてコンパクトにできるような。
[293] W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes ( ( 版)) http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#language
[294] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) ( ( 版)) http://w3c.github.com/packed-webapps/packaging/#rule-for-deriving-the-user-agent-locales
[295] Re: Language ranges with more than two sub-tag ( (Norbert Lindenberg 著, 版)) http://lists.w3.org/Archives/Public/www-international/2013JanMar/0327.html
[301] mattcg/language-tags ( ( 版)) https://github.com/mattcg/language-tags
[302] mattcg/language-subtag-registry ( ( 版)) https://github.com/mattcg/language-subtag-registry
[303] Metadata API for Media Resources 1.0 ( ( 版)) http://www.w3.org/TR/mediaont-api-1.0/#widl-MediaAnnotation-language
[304] Notifications API Standard ( ( 版)) http://notifications.spec.whatwg.org/#language-0
[305] Internationalization Tag Set (ITS) Version 2.0 ( ( 版)) http://www.w3.org/TR/its20/#LocaleFilter
[306] Internationalization Tag Set (ITS) Version 2.0 ( ( 版)) http://www.w3.org/TR/its20/#LocaleFilter
[307] RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content ( ( 版)) https://tools.ietf.org/html/rfc7231#section-3.1.3.1
[97] OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 1: OpenDocument Schema ( 版) http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#a18_3_16language
[98] OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 1: OpenDocument Schema ( 版) http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#a19_236fo_language
[99] OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 1: OpenDocument Schema ( 版) http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#a19_512style_rfc-language-tag
Human-readable Claim Values and Claim Values that reference human-readable values MAY be represented in multiple languages and scripts. To specify the languages and scripts, BCP47 [RFC5646] language tags are added to member names, delimited by a # character. For example, family_name#ja-Kana-JP expresses the Family Name in Katakana in Japanese, which is commonly used to index and represent the phonetics of the Kanji representation of the same represented as family_name#ja-Hani-JP. As another example, both website and website#de Claim Values might be returned, referencing a Web site in an unspecified language and a Web site in German.
To specify the languages and scripts, BCP47 [RFC5646] language tags are added to Client Metadata member names, delimited by a # character.
When language is specified, the language tag MUST use the RFC 3066
[LANGCODES] syntax.
カタロニア語(バレンシア) [ca-ES-valencia] を文書の内容として利用できるようになりました。 tdf#68714 (Eike Rathke)
カタロニア語(バレンシア) のUI翻訳として当座しのぎで [ca-XV] を使っていたのを、正しく [ca-ES-valencia] タグを用いるようになりました。 (Eike Rathke)
当座しのぎで [sh-*] という文書言語としていたものを、正しく [sr-Latn-*] とするように、古い [sh-*] も扱えるようにしました。 (Eike Rathke)
言語リストに [en-GB-oed] ルール外(grandfathered)タグを "English, Oxford English Dictionary spelling" 用として追加しました。 (Eike Rathke)
ラテン綴りで書かれたクルド語 [ku-*] の汚いマクロ言語のコードを綺麗にし、それぞれの国ごとに区別したスクリプトで処理するようにしました。 tdf#63460 (Eike Rathke)
ku → kmr-Latn (北部クルド語、ラテン綴り)
ku-TR → kmr-Latn-TR (トルコでの北部クルド語、ラテン綴り)
ku-SY → kmr-Latn-SY (シリアでの北部クルド語、ラテン綴り)
ku-IQ → ckb-IQ (イラクでの中部クルド語、アラビア綴り)
ku-IR → ckb-IR (イランでの中部クルド語、アラビア綴り)
追加: sdh-IQ (イラクでの南部クルド語、アラビア綴り)
[105] mediawiki/Names.php at master · wikimedia/mediawiki ( 版) https://github.com/wikimedia/mediawiki/blob/master/languages/Names.php
<englishName>Sorani Kurdish</englishName>
<codes>
<code>
<standard>
<name>FB</name>
<representation>cb_IQ</representation>
</standard>
</code>
</codes>
<englishName>Cherokee</englishName>
<codes>
<code>
<standard>
<name>FB</name>
<representation>ck_US</representation>
</standard>
</code>
</codes>
[119] Remove requirements on language tags. Encourage developers to do the … · whatwg/notifications@743cd90 ( 版) https://github.com/whatwg/notifications/commit/743cd90906c5fa522d31ef0082b2a6e573385b6b
[120] Indicate language is a language tag. Fixes #46 again. · whatwg/notifications@90e2964 ( 版) https://github.com/whatwg/notifications/commit/90e29647469fb26b1f707cf93d8c787b92d2bbdc
To specify the languages and scripts, BCP 47 [RFC5646] language tags
are added to client metadata member names, delimited by a "#"
character. Since JSON [RFC7159] member names are case sensitive, it
is RECOMMENDED that language tag values used in Claim Names be
spelled using the character case with which they are registered in
the "IANA Language Subtag" registry [IANA.Language]. In particular,
normally language names are spelled with lowercase characters, region
names are spelled with uppercase characters, and languages are
spelled with mixed-case characters. However, since BCP 47 language
tag values are case-insensitive, implementations SHOULD interpret the
language tag values supplied in a case insensitive manner. Per the
recommendations in BCP 47, language tag values used in metadata
member names should only be as specific as necessary. For instance,
using "fr" might be sufficient in many contexts, rather than "fr-CA"
or "fr-FR".
An implementation MUST treat language identifiers that [BCP 47] defines as equivalent as identifying the same language. For example "mn" and "MN" are equivalent, as language tags are case insensitive, and "de" and "deu" are equivalent, as they are different codes for the same language. However, it is implementation-defined whether an implementation treats a particular language identifier with script, region, or variant portions as equivalent to the language identifier without them. For example, an implementation may treat "en-UK" as equivalent "en" and "en-US" but "sr-Latn" as different from "sr" and "sr-Cyrl".
[124] ( 版) http://unicode.org/repos/cldr/trunk/tools/java/org/unicode/cldr/util/data/langtagTest.txt
[131] nototools/lang_data.py at master · googlei18n/nototools ( 版) https://github.com/googlei18n/nototools/blob/master/nototools/lang_data.py
locales引数は、すべてのUnicode拡張を除去した後、アプリケーションからの優先順位付き要求として解釈されます。ランタイムは、利用可能なローケルと比較し、利用可能なもののうち一番よいローケルを選びます。マッチングアルゴリズムは"lookup" matcherと"best fit" matcherの二つです。"lookup" matcher は、BCP 47で指定されたLookupアルゴリズムに従います。"best fit" matcher では、少なくとも "lookup" matcher と同程度の、しかし可能ならより要求に適したロケールを選択します。
[133] (Language tag) - SuikaWiki Data ( 版) https://data.suikawiki.org/lang
[135] language_detection_util.cc - Code Search ( ()) https://code.google.com/p/chromium/codesearch/#chromium/src/components/translate/core/language_detection/language_detection_util.cc
The value of the property should be a language code following the [bcp47] specification.
[207] draft-ietf-slim-negotiating-human-language-08 - Negotiating Human Language in Real-Time Communications () https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-08
[216] GPHemsley/BCP47: Code for parsing the IANA Language Subtag Registry and implementing BCP 47 support in Firefox. () https://github.com/GPHemsley/BCP47
Language: The "language" item (CAtype 0) optionally identifies the
language used for presenting the address information, drawing from
the tags for identifying languages in [4], as discussed in [13].
If omitted, the default value for this tag is "i-default" [3].
Language: The "language" item (CAtype 0) optionally identifies the
language used for presenting the address information, drawing from
the tags for identifying languages in [4], as discussed in [13].
If omitted, the default value for this tag is "i-default" [3].
[224] VRML97, ISO/IEC 14772-1:1997 -- 6 Node Reference () https://www.web3d.org/documents/specifications/14772/V2.0/part1/nodesRef.html#FontStyle
[226] JSON Feed - JSON Feed Version 1.1 (, ) https://jsonfeed.org/version/1.1#top-level
[271] rfc3659 () https://datatracker.ietf.org/doc/html/rfc3659#section-7.5
In older versions you might see these language entries instead:
* {art-Cyrl-x-interslv}
* {art-Latn-x-interslv}
[140] Multilingual names - OpenStreetMap Wiki, https://wiki.openstreetmap.org/wiki/Multilingual_names#France
In Britanny and Normandy, there are also the "Gallo" and "Norman" languages but they still have no specific ISO 639 code assigned (they may be represented in conforming BCP 47 tags as "fr-gallo" or "fr-x-norman" using a private extension only to collect the data, that won't be used interoperably before there's a documented agreement on which subtags to use; for Norman the assigned code "nrf" refers ambiguously to modern Jersiais, Guernésiais or Continental Norman and don't seem to discriminate their own local dialects, so it would still safely replace the "fr-x-norman" private use extension of French, or we could use "nrf-FR" font continental Norman, "nrf-JE" for Jersiais, and "nrf-GG" for Guernésiais if a distinction is really needed at the same place).