語彙

[111] 拡張言語は、3文字のラテン文字であって、 ISO 639-3 で割り当てられている言語符号のいくつかを IANA に登録したものです。 RFC 5646 2.2.2.

[112]

ISO 639-5 で定義されているような言語の集成やグループは含まれていません。 RFC 5646 2.2.2.

[118] 例えば、マクロ言語である中国語 (zh) には、贛語 (gan)、広東語 (yue)、官话 (cmn) などの方言が含まれています。これらは単独の言語として gan のように表しても構いませんし、拡張言語を使って zh-gan のように表しても構いません。ただし前者の表記が望ましいとされています。しかし従来 zh を使っていたなら、互換性のために zh-gan とした方がよいことも多いでしょう。もっとも、単に中国語一般を表したい時は単に zh と表記して構いません。 RFC 5646 2.2.2., 4.1.2.

[229] 元々言語の区分は客観的なものというよりは恣意的なものなので、中国語の各方言の差異は異なる言語と言って良いほどで、逆に欧州の一部の言語の差異は単なる方言と言える程度のものだったりします。 ISO 639 は中国語のような大きなくくりは「マクロ言語」として扱い、広東語などの細かな括りも独立した言語符号を割り振っています。そうすると、これまで単に zh と表してきた中国語ですが、個別の各言語として表現することもできるようになったわけですが、慣習的にはやはり zh にまとめた方が便利で受け入れやすいわけで、拡張言語はそのへんの妥協の産物なのでしょう。しかし zh-gan のような現在の慣習と親和性の高い表記法よりも gan のような一般的でない表記をより好ましいとする辺り、有用性よりも理論的一貫性を重視する方針は今回の改訂でも継続中のようです。

[254] マクロ言語のすべてが言語と拡張言語の組み合わせで使えるわけではなく、 LTRU Working Group が選んだ ar (Arabic), kok (Konkani), ms (Malay), sw (Swahili), uz (Uzbek), zh (Chinese) についてのみ拡張言語が登録されています RFC 5645 2.2.。

[255] また、手話はマクロ言語ではなく言語の種類ですが、これまで sgn-US のような言語タグで表してきた経緯から、拡張言語が登録されています RFC 5645 2.2.。

言語部分タグと拡張言語部分タグ

[110] 拡張言語はいずれも一次言語部分タグとして単独で使うこともできます。言語タグでは拡張言語部分タグよりも一次言語部分タグを使うべきです RFC 5646 2.2.2.。

[114] 拡張言語は IANA 登録簿で Preferred-Value 欄が定義されていなければならず、その値は Subtag 欄と同じでなければなりません。 RFC 5646 2.2.2. 従って >>110 の通り、拡張言語としてではなく言語として使うことが好ましいということになります。

[113] 拡張言語は IANA 登録簿で Prefix 欄が1つだけ定義されていなければなりません RFC 4646 2.2.2., RFC 5646 2.2.2.。すなわち、拡張言語部分タグを使う時は、必ずそれに対応する一次言語部分タグが1つだけ決まっていて、それを使わなければなりません。

[278] これらの規則から拡張言語 (とその前の言語) は特定の言語に無条件に書き換えられるように思えますが、実際にはそれによって非妥当になってしまう言語タグもあります。

[279] 例えば zh-yue-Latn-pinyin は妥当な言語タグではありますが、拡張言語を使うべきではないという要件に違反しています。そこで yue-Latn-pinyin と書き換えると、拡張言語はなくなりますが、異体 pinyin の Prefix として yue は登録されていないので、接頭辞を含める必要があるとの要件に違反してしまいます。

[115] ABNF 構文上は更に2つ (つまり合計3つ) 部分タグを連ねることができる RFC 4646 2.2.2., RFC 5646 2.2.2. とされていますが、これは使ってはならず、永続的に予約されていて非妥当であり続ける、とされています RFC 5646 2.2.2. 。

[116] これでは何のために構文をわざわざ定義して予約しているのか意味不明ですね・・・。

語彙

言語部分タグと拡張言語部分タグ

歴史

関連