extended language subtag

extended language subtag

[107] 言語部分タグ言語の大分類を表す時に、言語の小分類を表すものとして、 2番目の部分タグ拡張言語 (extended language) を指定することができます。

[109] 例えば、中国語に対する広東語手話に対する日本手話のようなものです。
[280] 言語タグ全体については「言語タグ」の項も参照してください。

語彙

[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 と書き換えると、拡張言語はなくなりますが、 異体 pinyinPrefix として yue は登録されていないので、 接頭辞を含める必要があるとの要件に違反してしまいます。

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

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

歴史

[119] 拡張言語は RFC 4646 で初めて構文のみ規定されましたが、その意味は規定されておらず、 将来の版で拡張するために使うとされていました。拡張言語は IANA には登録してはならない RFC 4646 2.2.2. とされていました。

[281] RFC 5646拡張言語の1つ目を使う方法が規定され、2つ目と3つ目は使わないとされました。

[282] この間3年ありますが、 ISO 639-3 の標準化作業中だったために時間差が生じたようです。

関連

[283] Unicode言語識別子Unicodeロケール識別子では拡張言語の使用が認められていません。