[107] 言語部分タグが言語の大分類を表す時に、言語の小分類を表すものとして、 2番目の部分タグに拡張言語を指定することができます。
[111] 拡張言語は、3文字のラテン文字であって、 ISO 639-3 で割り当てられている言語符号のいくつかを IANA に登録したものです。 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.
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. 。
[119] 拡張言語は RFC 4646 で初めて構文のみ規定されましたが、その意味は規定されておらず、 将来の版で拡張するために使うとされていました。拡張言語は IANA には登録してはならない RFC 4646 2.2.2. とされていました。
[283] Unicode言語識別子・Unicodeロケール識別子では拡張言語の使用が認められていません。