要約

  • RFC 1766 は言語タグを見た目上の区切りで表した一方、アプリケーションには全体を一つのトークンとして扱うよう指示した。サブタグは管理の仕組みであり、メニューではない。
  • ISO のコード、IANA 登録値、私用領域は文法の異なる位置を占める。タグと情報オブジェクトの関係は、そのタグを使う文脈の仕様が定義する。
  • 後年の仕様は明示的な照合操作を追加した。1995 年の文法に含まれる各ハイフンが、汎用的な案内経路になったわけではない。

ハイフンはパンくずリストに見える

1995 年 3 月、RFC 1766 は情報オブジェクトがどの言語を使っているかを示す、短いラベルの形式を提示した。主タグの後ろに任意の部分がハイフンでつながる見た目は、階層を連想させる。en-US はなじみ深く、az-arabic と az-cyrillic には同じ先頭部分がある。しかし RFC はその読み方に明確な制限を置いた。アプリケーションは言語タグ全体を一つのトークンとして扱うべきであり、主タグとサブタグへの分割は管理上の仕組みであって、ナビゲーション用ではない。

この指示が重要なのは、読める文字列がそのまま操作の階層になるわけではないからだ。主タグは一〜八文字、各サブタグも一〜八文字だった。タグの途中に空白は置けない。大文字と小文字は区別されず、国コードを大文字、言語コードを小文字で書く慣例にも、それ自体の意味はないとされた。

名前空間には境界があった。二文字の主タグは ISO 639 に従う。i は IANA が定義する登録値に予約され、x は私的利用を示し、その後のサブタグは IANA に登録されない。その他の主タグを割り当てるには標準の改訂が必要だった。最初のサブタグでは二文字コードが ISO 3166 alpha-2 に従い、三〜八文字の値は IANA に登録できた。後続のサブタグも登録対象になった。

この構造には混同しやすい二つの役割があった。文字列を分けて読めることと、名前空間を行政的に管理できることだ。タグの各部分をディレクトリーのように順にたどれとは書かれていない。また、すべてのアプリケーションが同じ部分に同じ意味を与えるとも定めていない。タグと情報オブジェクトの関係は、利用する文脈を定義する仕様に委ねられた。

登録は値を公開記録にする

RFC 1766 の例には、地域を示す en-US、方言や変種の no-nynorsk と en-cockney、IANA 登録言語の i-cherokee、文字体系の違いを示す az-arabic と az-cyrillic があった。重要な但し書きもある。文書に挙がったサブタグは、実際には一つも割り当てられていなかった。例は文法を示すもので、利用可能な値の一覧ではなかった。

事前に定められた ISO 値以外を提案する場合、申請者は言語名、原語名、公開された記述への参照などを登録フォームに記入した。フォームは公開メーリングリストで二週間のレビューにかけられる。IETF の Applications Area Director が任命したレビュー担当者は、IANA に転送するか、重大な反対意見を受けて却下できた。判断には IESG への異議申立てが可能だった。共有の綴りが他者に確認できるようになるのは、ハイフンの後ろに誰かが文字列を足した時点ではなく、公開記録に載った時点だった。

この仕組みの対象は限定されていた。登録したのは識別子とその参照情報であり、汎用のユーザーインターフェースではない。タグだけで、各プロトコルにどの表現を選ぶか、どの図書群を絞るか、どの経路を開くか、どの言語メニューを出すかを決めることはできない。その動作はタグが使われる文脈に属する。

ヘッダーに言語を並べても選択機構は決まらない

RFC 1766 は Content-Language も定め、そこに複数の完全なタグを列挙できるようにした。MIME の multipart/alternative には Differences パラメーターを加え、内容言語が異なる代替部分を示せるようにした。読者がその情報を使う理由は説明しているが、実際にどの部分を表示するかを選ぶ方法は文書の範囲外とされた。

ここでは三つの問いが分かれている。どの文字列がオブジェクトの言語を識別するのか、どのプロトコル要素がそれを運ぶのか、受信側のアプリケーションがそれをどう使うのか。タグをコンテンツヘッダーに置き、コンテナーが代替言語の存在を示しても、読者側には別途選択動作が必要だった。RFC が用意したのは共通ラベルと配置場所であり、全員に共通するナビゲーション画面ではない。

後続文書はその違いをより明確にする。2001 年の RFC 3066 はサブタグに数字を認め、language-range の照合を導入した。範囲はタグ全体、またはハイフンの直前で終わる接頭辞に一致する。この一致規則は明示された操作である。RFC 3282 はその後 Content-Language と Accept-Language のヘッダーを定義し、希望する言語範囲と任意の品質値を扱った。こうした追加でタグの周囲に明示的なプロトコル動作が生まれたが、元のハイフンが汎用的な経路になったわけではない。

2006 年の RFC 4646 と 2009 年の RFC 5646 は BCP 47 の改訂を続けた。文法や登録規則が変化したことは分かるが、すべてのクライアントがあらゆる値を正しく処理したことや、タグがページ、翻訳、表示形式を自動選択したことは示さない。RFC 1766 の歴史的な示唆はもっと限定的だ。内部構造を持つ識別子でも、アプリケーションには不可分の値として扱わせ、その部分を管理慣例に使うことができる。

出典と証拠の限界

基礎となる文書は RFC 1766。改訂の流れは RFC 3066、RFC 3282、RFC 4646、RFC 5646 に記録されている。これらは文法、登録、後続プロトコルの変更を示すが、全体的な実装や普及を証明するものではない。