言語タグ

言語タグ

[71] 言語タグ (language tag) は、自然言語を識別するための短い文字列です。 ISO の定める言語符号などの組み合わせにより様々な言語言語地域用字系などの組み合わせによるバリエーションを表現することができます。 言語タグIETF により BCP 47 として標準化されており、様々な IETFプロトコルの他 HTMLCSS などの Web標準でも広く使われています。

仕様書

[191] IETF として初めて言語タグを規定した最初の正式な仕様は RFC 1766 でしたが、 RFC 3066RFC 4646 を経て RFC 5646 が現行仕様となっています。 RFC 3066RFC 4646 の間に大規模な非互換変更が行われています。 (詳しくは歴史の項を参照してください。)

BCP 47

[84] IETF BCP 47 は、現在 RFC 5646RFC 4647 により構成されています >>72 1.

IANA 登録簿

[188] 言語タグで使うことができる部分タグ祖父化言語タグIANA の登録簿があります (>>74>>76)。

[189] RFC 1766RFC 3066 の時代は ISO の仕様から導出できない追加の言語タグを登録してもよいという形でしたが、 RFC 4646 以降は原則としてすべて登録簿にある部分タグを組み合わせて使う形に改められています。

[190] RFC 3066 までの時代の登録簿は機械処理には適さない文書でしたが、 RFC 4646 以降は機械処理可能な形式になっています。 その書式は RFC 4646 3. で規定されていましたが、 (非互換に) 変更されて現在は RFC 5646 3. で規定されています。

[53] ただし IANA が公開しているファイルはこの書式に必ずしも適合していません。 機械処理して利用する場合は、適合していなくてもある程度扱えるような配慮が必要です。 改行は CRLF ではなく、省略可能な CR と必須の LF の列として処理する必要があります。 また区切りの %% の後に空白が来ても、無視する必要があります。

[93] IETF の身内であるところの IANA すら仕様を正しく運用できないのは驚くべきことかもしれませんが、 IETF の仕様の品質としては一般的な部類です。

[143] データファイル (>>144) も参照。

呼称

[125] 正式には「言語タグ (language tag) 」と呼ばれます。

[126] WikipediaIETF 仕様であることから「IETF言語タグ」 と呼んでいます。

[127]言語コード」と呼ばれることもありますが、 言語タグ仕様上は言語タグに含まれる最初の部分タグ (として用いられる ISO言語コード) のことを指すので、 全体として言語コードと呼ぶのは不正確です。

[128] 値が言語タグとなる属性の名前などでは「lang」 と略されることがよくあります。プログラミング言語変数などの名前としては 「tag」や「langtag」などと略されることもあります。

構文

[55] 言語タグ (language tag) は、 1つ以上の部分タグ (subtag) HYPHEN-MINUS (-) で連結した文字列です。

例えば、

ja-Latn-US
... は、3つの部分タグから構成される言語タグです。狭義の言語日本語 (ja) であって、ラテン文字という用字系 (Latn) によって表記され、アメリカ合衆国という地域 (US) で用いられている言語を表しています。


[230] RFC言語タグABNF 構文で規定しています。

[254] IETF では一般的に ABNF で規定された構文を US-ASCII、 たまに UTF-8 で符号化される文字列たるバイト列と解釈しています。

[255] しかしながら、 言語タグはいろいろな場面で使われており、 あくまで ABNF で規定された文字列と解されています。 従って HTMLJSON で使われるときは、 その記述に使われる文字コードの普通の文字列として扱われます。

[261] Unicode言語タグは、 Unicode に含まれる通常の ASCII文字のかわりに、 タグ文字に含まれるASCII文字相当を使った文字列としています。

部分タグ

[56] 部分タグ (subtag) は、 (狭義の) 言語地域などを表す文字列です。 部分タグを複数組み合わせて細かく指定できます。 部分タグの長さや位置は、それが何を表すかによって決まっています。 RFC 4646 2.1.

[313] 部分タグの種類

[281] 言語タグの変種であるUnicode言語識別子Unicodeロケール識別子部分タグのことを 「符号 (code) 」とも呼んでいます。

[283] 実際に部分タグとして使われているのは ISO の仕様によって定められた言語符号国符号だったりするので、 「符号」と呼びたくなるのも理解できます。

大文字と小文字

[58] 言語タグの (ASCII の) 大文字小文字は、区別されませんRFC 4646 2.1., RFC 5646 2.2.1.

[59] 区別はされませんが、 IANA 登録簿の書式が推奨されています。 RFC 4646 2.1., RFC 5646 2.2.1.

[60] これは、 ISO 639-1言語符号がすべて小文字ISO 3166-1国名符号がすべて大文字ISO 15924用字系符号が先頭だけ大文字が推奨されていることに由来します。

[164] 拡張部分タグについては、すべて小文字正規化されることが期待されています。 RFC 5646 2.2.6.

[296] 拡張t」は拡張の一部として言語タグを含めることができますが、 その場合の正規形は、地域用字系も含めてすべて小文字とされています。

[121] しかしこの正規形への機械的な変換は、言語タグの構文を踏まえた若干複雑な処理が必要になります。 分野や実装によっては、 BCP 47 の推奨を無視してすべて小文字に変換することもあります。

[193] Unicode言語タグでは小文字が推奨されています。

長さ

[231] 言語タグには長さ制限はありません。一般的には6文字程度に収まりますが、 それより長い言語タグもあります。 RFC 4646 4.3., RFC 5646 4.4.

[232] プロトコル等で長さを制限する場合であっても、最低35文字は認めなければなりませんRFC 5646 4.4.

[233] RFC 4646 4.3. では最低42文字とされていましたが、拡張言語の仕様が確定したため緩和されました。

[234] 実装や仕様は長い言語タグを扱えなくても構いませんが、 何文字まで扱えるのか、長すぎる時にどうなるのかを文書化するべきです。 また実装は長すぎる時に警告するべきですRFC 4646 4.3., RFC 5646 4.4.

[235] 実装は長い言語タグを切り落としていく時に、部分タグの途中でぶった切ってはなりませんRFC 4646 4.3., RFC 5646 4.4.

歴史

[268] RFC 1766 では、構文は制限が緩い単純なもので、

... という制限しかありませんでした RFC 1766 2.

[260] RFC 3066 では、数字が認められて、

... という制限になりました RFC 3066 2.1

拡張部分タグ

[155] 拡張 (extension) は、 言語言語タグと併用される、言語以外の情報を表すために使える言語タグの拡張機構です。 RFC 4646 2.2.6., RFC 5646 2.2.6.

[297] 数値の表現、照合順序といったようなロケール情報は、 広い意味では言語を構成する要素ではありますが、言語タグ本体仕様には含まれておらず、 拡張として記述する必要があります。

[161] 拡張は、 singleton と呼ばれる1文字の部分タグと、 それに続く1個以上の2-8文字の英数字部分タグにより構成されます。 singleton拡張の種類を表すものであり、 IANA に登録しなけてばなりません。 続きの部分タグは、その拡張の仕様に従わなければなりませんRFC 4646 2.2.6., RFC 5646 2.2.6. 拡張は続きの部分タグを構文の制約の元で自由に使うことができます。 拡張妥当 (valid) であるかどうかは、その仕様によって定められます RFC 5646 2.2.9.

[162] xi拡張を表す singleton ではありません。

文脈

[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. 順序に意味は無いようです。

[298] 拡張によっては更に正規化する方法が規定されています。

一覧

[26] その他提案されているもの: 拡張D


[318] ScriptLangTag を規定する OpenType の仕様書は、 拡張U拡張Tより後にも更新されているにも関わらず、 仕様書執筆時点で ScriptLangTag 用に定義された拡張はなく、 何か指定されても無視される、 としています。 >>117

[319] 不明瞭ですが、特に ScriptLangTag 用だと規定がない限りは、 ScriptLangTag では使えないということでしょうか。

歴史

[157] 拡張RFC 4646 で導入されました。それ以前は同様の仕組みはありませんでした。

[289] t は2011年12月16日付でIANAに登録されています。

私用部分タグ

[165] 私用 (private use) 部分タグは、 特定の文脈で私的な合意の元に意味のある言語の区別を示すものです、 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.

[167] 私用部分タグは、たとえ言語地域部分タグと同じように見えたとしても、 (当事者間でそのように合意していない限り) その言語地域を意味しません。 en-USen-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

[7] 用字系部分タグが必須なので、 ScriptLangTag 全体を私用部分タグにはできません。

実例

[24] 個別の事例は言語タグの一覧参照。


[25] 体系的な利用例がいくつかあります。

[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 が付く。

歴史

[171] RFC 1766RFC 3066 では、1つ目の部分タグ (当時の用語でいう一次タグ (primary tag) )x とすることで私用を表していました。 2つ目の部分タグ (当時の用語でいう最初の部分タグ (subtag) ) について、 RFC 1766 では何も規定がなく、 RFC 3066 では1文字のものは将来の拡張のために予約するとされていました。 3つ目以降の部分タグについては特に制約なく、 x を使ったり登録したりすることも認められていました (特に私用という意味は割り当てられていませんでした)。

[172] RFC 4646 以後、私用を表す部分タグの最初に使うという意味になっています。

祖父化言語タグ

[57] RFC 1766RFC 3066 の時代に登録された言語タグの中には、 RFC 4646 以後の部分タグの定義に従っていないものがありますが、 それも互換性のため引き続き RFC 4646 以後の仕様でも使うことが認められています RFC 4646 2.2.8., RFC 5646 2.2.8.

[85] RFC 4646 は特別に

grandfathered = 1*3ALPHA 1*2("-" 2*8(ALPHA / DIGIT))
... という構文を認めていました RFC 4646 2.1.

[86] ところがこれでは RFC 4646 以後のより制限が厳しい構文で認めていないものがこちらの構文では認められることになってしまい、 構文の定義として意味をなしていない状態でした。

[87] RFC 5646 では RFC 3066 までに登録されたものを構文定義に列挙する形となっており、 この問題は解消しています。

[88] これによって RFC 3066 時代までに未登録で利用され、 RFC 4646 以後定義に沿わないことにされてしまった言語タグRFC 5646 の構文に適合しなくなってしまいました。 とはいえ、 RFC 4646 の時に既に RFC 本文の定義に合致しない状態だったのですが。

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

冗長言語タグ

[173] RFC 1766RFC 3066 に基づく手続きにより IANA に登録された言語タグの中には、 RFC 4646 以後の仕組みに基づかず祖父化 (grandfathered) 扱いされているものの他、 zh-Hant のように RFC 4646 以後の部分タグの組み合わせで表現できるものがいくつもあります。 このような言語タグもまた RFC 4646 以後の IANA 登録簿に含まれており、「冗長 (redundant) 」と分類されています RFC 4646 2.2.8., RFC 5646 2.2.8.

部分タグの選択

[213] 大原則として、言語タグを構成する時は、可能な限りで粗すぎず、細かすぎない、 必要十分な粒度で言語を特定できるように部分タグを選択するべきです。 RFC 4646 4.1., RFC 5646 4.1.

[214] 例えば、殆どの場合 de-CH-1996 (1996年正書法) は細かすぎで、 de-CH で十分です。

[215] 普通は gem (ゲルマン語族) は粗過ぎで、 それが (例えば) ドイツ語とわかっているなら de を使うべきです。

非推奨

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

[198] RFC 4646 3.1. では、拡張言語>>196 に分類されていました。また >>197拡張言語範囲ではなく、「完全な言語タグ」とされていました。

[204] 非推奨かつ好ましい値が指定されている場合にあっては、 好ましい値が最善の選択として利用されるべきです拡張言語以外で好ましい値が指定されているなら、必ず非推奨でもあります。 RFC 4646 3.1., RFC 5646 3.1.7.

[205] なお、好ましい値は必ずしも意味的に等価ではありません。例えば地域部分タグの独立などがあって変化した時に新しいの符号が好ましいとされますが、 必ずしも以前のと同じ範囲ではありません。

[265] RFC 3066 以前に登録された i-* 形式の言語タグの多くは、 現在では ISO言語符号が割り当てられていて、そちらを使うのが好ましいとされています。 RFC 3066 の当時も、 ISO言語符号が割り当てられたらそちらを使わなければならない RFC 3066 2.3 とされていました。

接頭辞

[199] IANA 登録簿には Prefix (接頭辞) 欄があります。 その値は、当該部分タグを使う時に接頭辞となっているべき言語タグです。 (接頭辞となっているか否かは、拡張濾過算法に拠ります。) 接頭辞は拡張言語異体の登録にのみ含まれます。 RFC 4646 3.1., RFC 5646 3.1.2., 3.1.8.

[206] 例えば cmn (官話) 拡張言語部分タグ接頭辞zh (中文) となっているので、 zh-cmn とするべきであり、 ja-cmn は不適当です。

[277] Prefix に一致するかどうかは拡張濾過算法により判断されるので、 必ずしも文字列として接頭辞になっていなくても構いません。例えば es-Latn-CO-x-privatees-CO は接頭辞として含まれています。

正規化と比較

正準形

[237] 言語タグ正準形 (canonical form) であるべきですRFC 4646 4.4., RFC 5646 4.5.

[238] 整形式言語タグは次の手順で正準化できます RFC 5646 4.5.

  1. [239] 拡張は、 singleton の大文字・小文字を区別しない ASCII 順にします。
  2. [240] 祖父化または冗長として登録されている言語タグであって、 Preferred-Value が示されていれば、その言語タグに置き換えます。
  3. [241]部分タグが登録されていて Preferred-Value が示されていれば、 その部分タグに置き換えます。

[243] これは RFC 4646 4.4. に示されていた正準化の方法とは少し違っています。 両者は実質的に等価だと思いますが、検証していません。

[246] en-BU (英語、ビルマ) の正準形en-MM (英語、ミャンマー) です。

[249] ここでいう正準化には大文字・小文字の正規化 (>>58) は含まれていません。 また用字形抑制や異体の順序など、言語タグの仕様上推奨されている要件であっても、 正準化によって満たされないものがあります。
[250] 拡張は、それぞれの正準形をそれぞれにおいて規定できるとされています。

拡張言語形

[242] 整形式言語タグは次の手順で拡張言語形 (extlang form) に変形できます。 RFC 5646 4.5.

  1. [244] 正準形にします。
  2. [245] 拡張言語でもある言語ではじまるなら、その拡張言語Prefix を先頭に挿入します。

[248] 正準形では必ず拡張言語が含まれない形になるので、言語拡張言語の両方を含めた形の方が便利なときには拡張言語形が良いとされています。

その他

[288] 言語タグは冗長性や廃止された値が多くあるので、それらの扱いについて個別に規定している仕様もあります。

[287] ヘブライ語を表すいろいろな言語タグiwiw-ILhe-ILhe を等価として扱わなければならないとする仕様もあります。 (he の項を参照。)

言語タグの適合性

[176] 言語タグ適合性については、整形式妥当の2つの基準が設けられています。

整形式言語タグ

[177] 言語タグABNF 構文に一致する時、整形式 (せいけいしき) (well-formed) です。 RFC 5646 2.2.9.

妥当な言語タグ

[178] 言語タグは、

... 妥当 (valid) です。 RFC 5646 2.2.9.

歴史

[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 上のすべての要件を満たしていることにはなりません。

不正な言語タグ

[7] GNU Wget - バグ: bug #26786, TLS SNI support [Savannah] (Copyright (C) 2000, 2001, 2002, 2003 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved 著, 版) http://savannah.gnu.org/bugs/?26786
<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'>
[134] ( 版) http://doc.qt.io/qt-4.8/qcolor.html#setNamedColor

<html lang="en_US">

[141] [CITE@de_DE[Another RDF Encoding Form (aREF)]] (Jakob Voß (voss@gbv.de)著, ) https://gbv.github.io/aREF/aREF.html

<html lang="de_DE">

[217] [CITE@en_us[Building the Future of the Twitter API Platform]] () https://blog.twitter.com/developer/en_us/topics/tools/2017/building-the-future-of-the-twitter-api-platform.html

<html lang="en_us" prefix="og: http://ogp.me/ns#">

[218] [CITE@en_us[Giving you more characters to express yourself]] () https://blog.twitter.com/official/en_us/topics/product/2017/Giving-you-more-characters-to-express-yourself.html

<html lang="en_us" prefix="og: http://ogp.me/ns#">

[221] [CITE@ja,zh[電脳戦機バーチャロン×とある魔術の禁書目録 とある魔術の電脳戦機(バーチャロン) 公式サイト]] () http://vo-index.sega.jp/outline/istg/index01.html

<!doctype html>

<html lang="ja,zh">

[225] Static Maps API — Map localization — Yandex Technologies () https://tech.yandex.com/maps/staticapi/doc/1.x/dg/concepts/localization-docpage/

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.

[136] Apple News Format Reference: Properties () https://developer.apple.com/library/ios/documentation/General/Conceptual/Apple_News_Format_Ref/Properties.html#//apple_ref/doc/uid/TP40015408-CH2-SW1

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

[137] [CITE@en-US.UTF-8[Welcome [Savannah]]] (Copyright 2016 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.著, ) http://savannah.nongnu.org/

<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US.UTF-8" xml:lang="en-US.UTF-8">

言語タグの集合

[276] 言語タグワイルドカードによって言語タグ集合を表現する「言語範囲」 や言語範囲を複数列挙した「言語優先度リスト」が HTTPAccept-Language: などで用いられています。

ロケールと言語タグ

[8] 言語ロケールを構成する一要素であり、言語ロケールは別の概念ではありますが、言語ロケールの最重要要素でもありますから、同一視されることもよくあります。

[9] 言語タグUnix 系システムのロケールの識別子と (区切り文字が違うことを除けば) 非常によく似ていて、歴史的にも深く関わっています。

[10] UTS #35 は元は Unix ロケール識別子由来の独自の構文を規定していましたが、 現在は言語タグu 拡張や t 拡張という形で両者の要素を混在させたスタイルになっています。 Unicodeロケール識別子

[12] 言語タグ本体と u 拡張、 t 拡張を合わせればロケールのかなりの側面が一つの識別子により記述できますが、 それでもまだカバーされてない範囲もあります。

[11] 言語タグで (まだ) 記述できないもの
[130] 枠組みとしてカバーされていても、値が存在しないものもあります。 例えばですます調だである調の違いや候文、 戦前公用文型の片仮名文、2chスラング混じり文、 といったバリエーションは言語の異体として区別可能かもしれませんが、 使える値は登録されていません。 書き言葉話し言葉の別、語尾に「アル」、「にゃん」、 「ごわす」のような特徴的なものを使うかどうかといった違いも表現できる値がありません。 句読点に「、。」を使うか 「,.」を使うかの違いも何らかの方法で理論上記述可能かもしれませんが、 そのような値は現時点でありません。 方言の違いも、値がありません。

文脈

[94] MIME では、 RFC 2231 で拡張された引数の値の構文で RFC 1766 により登録された言語タグの値を指定できるとされています。

[95] また encoded-word でも RFC 2231 の拡張により、RFC 1766 により登録された言語タグの値を指定できるとされています。

[208] MIMEHTTPContent-Language: ヘッダーの値や HTTPAccept-Language: ヘッダーの値の一部として言語タグが使われています。

[211] HTMLlang 属性hreflang 属性の値として言語タグが使われています。

[212] XMLxml:lang 属性の値として言語タグが使われています。

[269] LDAP lang-

[270] CPIM ;lang=

[96] Unicode の特別な文字コードを使って RFC 1766 言語タグを埋め込む方法がかつて提案されていましたが (RFC 2482)、現在では使われていません。 Unicode言語タグ

[264] MLSFUTF-8 を拡張して特殊なバイト列として言語タグを埋め込む方法でした。

[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] 改訂は想定しながら、非互換変更までは想定できず梯子を外された事例。

データファイル

[144] 言語タグについて構文的に正しいかどうか以上の処理を行いたい場合、 データファイルを用意する必要があります。

[145] 理論上はプラットフォームロケールシステムの一部として提供されている可能性もありますが、 実際にはそのようなプラットフォームは一般的ではありません。 (プラットフォーム独自のロケールシステムに関するデータは提供していても、 言語タグ一般のデータは提供されません。)

[148] >>146 に、 JSON 形式のデータファイルがあります。 IANA登録簿Unicode の登録簿に登録された部分タグの情報が含まれています。

[149] 言語タグの情報は、言語というそう頻繁に変わらなそうなものを扱ってはいますが、 数ヶ月に一度程度という意外な高頻度で改訂されています。漏れている言語が追加されるなど、 細かな変更がちょくちょく行われているようです。

[150] 従って、言語タグの情報を扱うシステムは、その情報を定期的に更新する機構を組み込んでおく必要があります。

ロケールも参照。

歴史

[37] 非常に古い HTTP では、 RFC 1766 の "-" を使う方法ではなく POSIXlocale 名のように "_" で区切っていました。

[38] >>37 現在でも間違ってこちらが使われる可能性がありますから、実装は両方に対応しているといいかもしれません。

[39] HTML 3.0 では lang 属性の値に "-" の代わりに "." を使っていました。 (The Body Element and Related Elements http://www.w3.org/MarkUp/html3/docbody.html#Body)

RFC 1766

[4] RFC 1766 は、言語タグを規定する最初の RFC でした。 RFC 3066 により廃止されました。

[267] IETF で初めて言語タグを規定した正式な仕様書が RFC 1766 です。 RFC 1766標準化過程 RFC で、提案標準でした。

[290] IETF における国際化について議論している RFC 2130RFC 2277 では、言語タグIETF での標準的な言語識別方法としています。

[286]

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.

[285] RFC 2130 - The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 ( 版) http://tools.ietf.org/html/rfc2130#page-8

HTTP/1.1

[257] HTTP/1.1 (RFC 2068, RFC 2616) は、RFC 1766 を引用しつつも独自に言語タグの構文を規定しています。

[92] RFC 2068・2616 (HTTP/1.1) 3.10 Language Tags

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 に基づく数字が使える定義に改められています。

RFC 3066

[1] 言語札は RFC 1766 が定義していましたが、 RFC 3066 に改訂されました。

[5] RFC 3066 の項も参照してください。

[78] RFC 1766標準化過程 RFC (提案標準) でしたが、 RFC 3066 以後は BCP (BCP 47) となっています。

RFC 4646

[77] RFC 4646 の項も参照してください。

[275] RFC 3066 は全面改訂により RFC 4646 に変わっています。 RFC 4646 は構文についても登録の仕方についても根本的に改めており、 完全には互換性がない新しい仕様となっています。

[256] RFC 4645 は、 RFC 4646 の標準化に際して改めて作成された新しい IANA 登録簿の初期状態の内容 (ILSR) を用意した方法について説明しています。

[273] RFC 3066 のうち言語範囲と一致演算については RFC 4647 に分離されています。

RFC 5646

[79] RFC 5646 への改訂では、仕様の全体的な構成と内容は変わっていませんが、 細かな編集上の変更が数多く加わっています。また、前の版で未定義だった拡張言語が正式に定義されています。

[80] その他、前の版でブラックホールになっていた祖父 (grandfathered) ABNF 定義が改められ、何でも一致する定義から、 RFC 3066 時代までに登録されて現在の基準には沿わない言語タグをすべて列挙する形に改められています。

[81] IANA登録簿の書式が US-ASCII から UTF-8 に変更されています。

[82] また非互換変更かよ・・・。

[65] RFC 4646 が出てからまだ3年しか経ってないのに改訂とか超うけるwwwwwwwwwwwwwwww

[66] 調べてみたら RFC 1766RFC 3066 で5年、 RFC 3066RFC 4646 で5年なのねwwwwwwwww

[70] >>65 逆に、 IETF でたった3年で改訂版を出せるのが奇跡かもwww

[252] というか前回で完成しなかったところを引き続きやってたからか。

[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言語タグの構文解析結果や適合性エラーを見ることができます。

テスト・ケース

[62]

応用

[192] HTMLlang 属性XMLxml:lang 属性IETF言語タグを値に採用しています。 これらの属性言語情報の不在を示すために空文字列も値として認めています。

[229] 言語タグ応用

関連

[311] Android設定修飾子IETF言語タグを構文的に変形したものです。

[314] OpenTypeScriptLangTagIETF言語タグと非常によく似ていますが、 用字系を中心としたものです。

[63] OpenDocument 1.0 の dc:language 要素内容RFC 3066 言語札似たものです。

[316] POSIXロケール識別子は - ではなく _ を区切りにしていますが、 IETF言語タグと非常によく混同されています。

[315] その他各種言語符号IETF言語タグによく似たものも多いです。 言語符号

言語タグの一覧

言語タグの一覧, 日本語言語タグ

歴史

%LanguageCode; 型 (HTML 4)

[151] HTMLDTD で使われている %LanguageCodeは、 言語札を表します。

[153] HTML 4 本文 (規定), DTD 注釈 (参考) は RFC 1766 を参照しています。 XHTML 1.0 SE DTD 注釈 (規定), XHTML m12n 抽象モジュール定義 (規定) XHTML m12n 4.3RFC 3066 を参照しています。

[154]

引数実体名
%LanguageCode (HTML 4, XHTML 1.0)
抽象属性型名
LanguageCode (XHTML m12n)
属性型名
language-code (HTML 4)
SGML 属性型
NAME (HTML 4)
XML 属性型
NMTOKEN (XHTML 1.0)
大文字・小文字
大文字正規化 (HTML 4), 区別無し (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 属性になりました。こちらは後に空文字列を認めるように修正されています。

[22] RFC 3066 によれば、第2小札以降は文法規則 (特に、字数制限: 3〜8文字に注意) に従う限り自由に使っていいことになっています。このため言語札の一意性は保障されないでしょう。 もっとも言語はそう簡単に増えたり減ったりするものではないですから、滅多なことでは衝突しないでしょうが・・・。

  • [44] しかし衝突はしなくても、同じ言語/方言を表す名前が複数存在してしまうことになりかねません。
  • [45] 言語札のレベルでは解決できない問題として、言語/方言の区分の方法による非一意性もあります。 日本語言語タグ大阪弁/関西弁問題や、台湾の外省人の言語が北京語と同じなのか (違うかな。) とか。
  • [46] >>45 でも中国で北京語といったら北京方言のことで、官話方言のことじゃないそうですね。日本語共通語と山手方言とか江戸っ子言葉の関係みたいなもん?

[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 の仕様に依存しているせいで仕様書本体の規定に抽象的なものが多くて理解しづらいし。

[223] 例示なのに助動詞が使われていたりおかしいし。

[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

[100] Final: OpenID Connect Core 1.0 incorporating errata set 1 ( 版) http://openid.net/specs/openid-connect-core-1_0.html#ClaimsLanguagesAndScripts

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.

[101] Final: OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1 ( 版) http://openid.net/specs/openid-connect-registration-1_0.html#LanguagesAndScripts

To specify the languages and scripts, BCP47 [RFC5646] language tags are added to Client Metadata member names, delimited by a # character.

[103] RFC 3709 - Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates ( 版) https://tools.ietf.org/html/rfc3709#page-10

When language is specified, the language tag MUST use the RFC 3066

[LANGCODES] syntax.

[104] LibreOffice 4.2 リリースノート - The Document Foundation Wiki ( 版) https://wiki.documentfoundation.org/ReleaseNotes/4.2/ja#.E8.A8.80.E8.AA.9E.E3.82.BF.E3.82.B0.E3.82.B5.E3.83.9D.E3.83.BC.E3.83.88

カタロニア語(バレンシア) [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

[116] ( 版) https://www.facebook.com/translations/FacebookLocales.xml

<englishName>Sorani Kurdish</englishName>

<codes>

<code>

<standard>

<name>FB</name>

<representation>cb_IQ</representation>

</standard>

</code>

</codes>

[118] ( 版) https://www.facebook.com/translations/FacebookLocales.xml

<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

[122] RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol ( 版) https://tools.ietf.org/html/rfc7591#section-2.2

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

[123] XQuery and XPath Full Text 3.0 ( 版) http://www.w3.org/TR/2015/REC-xpath-full-text-30-20151124/#ftlanguageoption

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

[132] Intl - JavaScript | MDN ( 版) https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Intl

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

[140] Androidで特定の言語コードがISO639-1のコードと違う問題に対する対処方法 - Qiita ( ()) https://qiita.com/konifar/items/b3ceaa1dcd0e132de3fd

case "he": // ヘブライ語

return "iw";

case "yi": // イディッシュ語

return "ji";

case "id": // インドネシア語

return "in";

[142] Web Annotation Data Model () https://w3c.github.io/web-annotation/model/wd2/#h-external-web-resources

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

[219] RFC 4676 - Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information () https://tools.ietf.org/html/rfc4676#section-3.4

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

[220] RFC 4776 - Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information () https://tools.ietf.org/html/rfc4776#page-11

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

[279] Interslavic Spellchecker » Extensions () https://extensions.libreoffice.org/en/extensions/show/15995

In older versions you might see these language entries instead:

* {art-Cyrl-x-interslv}

* {art-Latn-x-interslv}