ワールド・ワイド・ウェブのための言語タグおよびロケール識別子

1. はじめに

言語タグとロケールは、Web の 国際化 （i18n）を構成する基本要素の一部である。本文書には、 国際化のこの側面に関連する基本用語の多くについて、その定義が記載されている。

本文書はまた、文書形式またはプロトコル内の 自然言語値を識別するために仕様作成者が必要とし、 国際化（I18N）作業グループが推奨する用語およびベストプラクティスを提供する。これらをはじめとする多数の ベストプラクティスは、関連資料へのリンクとともに、仕様開発者向け国際化 ベストプラクティス［INTERNATIONAL-SPECS］にも記載されている。ここに記載する ベストプラクティスに加えて、Web 上の言語メタデータに関するその他のベストプラクティスは、 ［STRING-META］に記載されている。

2. 言語と言語タグ

コンテンツの 自然言語またはユーザーの 国際化設定を識別するためのタグは、 Web を構成する基本要素の一つである。Web およびインターネットの形式 とプロトコルで使用される 言語タグは、［BCP47］によって定義される。言語タグを一貫して使用すると、 アプリケーションは言語固有の書式設定または処理を実行できる。たとえば、ユーザーエージェントは、 テキストを表示する適切なフォントを選択するために言語を使用でき、Web ページの設計者は、 ある言語のテキストを別の言語とは異なるスタイルで表示できる。

Web の中核標準の多くは 言語タグをサポートしている。これには、 ［XML10］の xml:lang 属性、 ［HTML］の lang および hreflang 属性、［XSL10］の language プロパティ、 CSS［CSS3-SELECTORS］の :lang 疑似クラスのほか、SVG、TTML、SSML など多数が含まれる。

自然言語（本文書では単に 言語ともいう）。人間が 使用する、音声、文字、または手話によるコミュニケーション。

言語を識別する方法は多数あり、ソフトウェアが Web 上のコンテンツの言語を識別する必要がある 理由も多数ある。Web 上の文書形式およびプロトコルでは、通常、インターネットの他の大部分で使用される識別子、 すなわち［BCP47］で定義される言語タグを使用する。「BCP」という名称は、 「現行のベストプラクティス」を構成する、現在の一連の IETF RFC を指す。

言語 タグ。言語の識別子として使用される文字列。本文書において、言語 タグという用語は常に、明示的に［BCP47］言語タグを指す。これらの 言語タグは、一つ以上のサブタグで構成される。

​言語識別を必要とする Web の仕様は、必ず［BCP47］を参照しなければならない。

​仕様は、原則として［BCP47］を構成する特定の RFC を参照するべきではない。

［BCP47］は、本文書の公開時点では、 二つの個別の RFC で構成される複数部から成る文書である。言語を識別するための タグ［RFC5646］と呼ばれる第1部は、言語タグの文法、形式、および 用語を定義する。言語タグのマッチング［RFC4647］と呼ばれる第2部は、言語タグを使用して コンテンツをマッチング、比較、および選択するための複数の方式について説明し、言語設定と タグ付けされたコンテンツとの比較に関する有用な用語も含む。

​「RFC 5646 またはその後継文書」のような表現は、 特定の文書バージョンが必要な場合に限り、使用してもよい。

この参照形式はかつて一般的であったが、BCP への参照を使用する方が正確である。言語タグの文法は ［RFC4646］以降固定されているため、BCP を参照しても、 ほとんどの実装で追加の適合性リスクが生じることはない。

​仕様は、［BCP47］の廃止されたバージョン、たとえば［RFC1766］または［RFC3066］を決して参照してはならない。

​［BCP47］の廃止されたバージョンとの互換性を維持する必要がある仕様は、必ず ［BCP47］の生成規則 obs-language-tagを参照しなければならない。

［RFC4646］以降、［BCP47］は、 言語タグについて、より複雑で機械可読な構文を定義している。この構文は安定しており、予見可能な 将来に変更されることは想定されていない。一部の仕様では、以前のバージョンの BCP47 に存在する 古い言語タグ文法（特に［RFC1766］および［RFC3066］）との互換性が望まれるか、必要になる場合がある。この文法は、より 制約が緩く、［BCP47］では ABNF 生成規則 obs-language-tagとして記述されている。言語タグの現在の文法を導入した［RFC4646］は、現在の［RFC5646］の一部として、［BCP47］に置き換えられた。

​言語 情報を URI の一部として提供するアプリケーション（たとえば RDF の領域）は、原則として［BCP47］を使用するべきである。

現在、言語情報を表す URI は、ISO 639 の一部に由来する値を使用することが多い。そのため、 たとえばドイツ語について、ISO 639-1 の de と ISO 639-2 の ger のどちらが 適切な値であるか曖昧になる状況が生じる。BCP 47 とその言語サブタグ レジストリを使用すれば、このような曖昧さを回避できる。たとえばドイツ語について、レジストリには de のみが含まれる。

サブタグ。ハイフンマイナス文字によって他のサブタグから区切られ、 ASCII 文字または数字から成る文字列であり、言語タグ全体における特定の 意味要素を識別する。言語タグ。［BCP47］では、サブタグを ASCII の大文字または小文字（大文字と小文字に意味上の違いはない）あるいは ASCII 数字で構成できる。サブタグの長さは 8文字以下に制限される（ただし、サブタグの具体的な用途に応じて、さらに長さが 制限される）。

言語タグに基づいてコンテンツまたは動作を選択するには、 ［BCP47］（［RFC4647］）で定義される追加の概念がいくつか必要になる。 本文書では、［BCP47］から直接採用した次の用語を使用する。

IANA 言語サブタグレジストリ。言語タグで有効なすべてのサブタグの包括的な一覧を 含み、IANA を通じて入手できる機械可読テキストファイル。（リンク： レジストリ）

​仕様は、原則として［BCP47］の IANA 言語サブタグレジストリに寄与する基礎標準、 たとえば ISO639、ISO15924、ISO3066、または UN M.49 を参照するべきではない。

標準によっては、［BCP47］に寄与する標準の一つを直接使用する場合があり、 その場合、参照は完全に適切である。しかし、ほとんどの場合、参照の目的は、 有効なコードとその意味の一覧を指定することにある。［BCP47］の サブタグレジストリは安定しており、多くの有用な方法で 曖昧さを解消するため、この種の参照において優先される情報源にするべきである。

［BCP47］は、二つの異なる 適合性レベルを定義している。詳細については、［BCP47］の 適合性クラスを参照されたい。言語タグの場合、 適合性レベルは、実装が言語タグ値に適用する検査の種類に対応する。

整形式の言語タグ。［BCP47］で定義される文法に従う言語タグ。すなわち、構造的に正しく、 規定された長さの ASCII 文字および数字から成る サブタグをハイフンで区切って構成したもの。

妥当な言語タグ。整形式であり、 ［BCP47］の追加の 適合性 要件にも従う言語タグ。特に、各サブタグが IANA 言語サブタグ レジストリに存在する必要がある。

​仕様は、 言語タグが 整形式であることを原則として要求するべきである。

​仕様は、 言語タグが 妥当であることを要求してもよい。

​仕様は、コンテンツ作成者が 妥当な言語 タグを使用することを原則として要求するべきである。

これは、実装に対して推奨される要件よりも厳格であることに注意されたい。

​コンテンツ検証器は、 可能な場合、コンテンツが 妥当な言語タグを使用しているかを原則として検査するべきである。

タグが 妥当であるかを検査するには、レジストリへのアクセスまたはそのコピーに加え、実行時の追加ロジックが必要になる。 コンテンツ作成者には妥当な値のみを選択、生成、および交換することが推奨されるが、言語タグのマッチングや その他の一般的な言語タグ操作は、妥当性検査を必要としないよう設計されている。サブタグの 具体的な意味内容を理解する必要がある機能または関数は、仕様がプロトコルまたは文書形式の一部として 妥当なタグを規範的に要求する主な理由となる。

言語タグ拡張または 拡張。IANA に登録された単一の文字または数字のサブタグによって導入され、 ［BCP47］に追加されるサブタグの仕組みであり、 追加の種類の言語 識別を可能にする。

​仕様は、必要に応じて ［BCP47］の登録済み拡張を参照してもよい。

特に、［RFC6067］は、「Unicode ロケール」としても 知られる BCP 47 拡張Uを定義する。［BCP47］に対するこの拡張は、特定の ロケール変種を選択するための追加のサブタグ列を提供する。

​仕様は、 言語タグの長さを制限したり、拡張の削除を許可または推奨したりするべきではない。

言語範囲。言語タグに似た構造を持ち、 「特定の属性を共有する言語タグの集合を識別する」ために使用される文字列。

言語 優先順位リスト。マッチングで使用するユーザーの 言語設定を識別する、一つ以上の 言語範囲の集合。その名前が示すように、このようなリストには通常、 ユーザーの設定に従って順序または重みが付けられる。HTTP［RFC2616］の Accept-Language［RFC3282］ヘッダーは、言語 優先順位リストの一種の例である。

基本言語範囲。ハイフンで区切られた サブタグ列で構成される 言語範囲。すなわち、外観は言語タグと同一である。

拡張言語範囲。ハイフンで区切られた サブタグ列で構成される 言語範囲。拡張言語範囲では、サブタグに妥当なサブタグまたは 任意の値に一致するワイルドカードサブタグ *を使用できる。

前述の Accept-Language［RFC3282］ヘッダーなど、一部の 言語優先順位リストでは、 リストに現れる値に「重み」が与えられる。このような重み付けは、リストの 順序付け以外の用途では信頼できない。

​言語タグのマッチングまたは 言語ネゴシエーションを定義する仕様は、 使用する言語範囲が 基本言語 範囲または 拡張言語範囲のどちらであるかを必ず指定しなければならない。

​言語タグのマッチングを定義する仕様は、 マッチング操作の結果が単一の結果（［RFC4647］で定義される ルックアップ）を含むのか、または空の場合もある（0個以上の）結果の集合 （［RFC4647］で定義される フィルタリング）を含むのかを必ず指定しなければならない。

​言語タグのマッチングを定義する仕様は、 使用可能なマッチングアルゴリズムおよび選択機構を必ず指定しなければならない。

たとえば、JavaScript 国際化［ECMA-402］ および［CLDR］は、実装者が調整できる 「最適一致」アルゴリズムを提供する。

3. ロケールと国際化

この節では、国際化およびローカライズに関する基本用語を定義する。

異なる言語を話す、または異なる文化的背景を持つユーザーは通常、自身の母語、書記体系、 計量体系、暦、およびその他の言語規則や文化的慣習を使用して情報を正しく処理できるように適応された ソフトウェアおよびサービスを必要とする。

言語 タグは、特定のコンテンツまたはユーザーに関連付けられた 国際化設定を識別するためにも使用できる。 これは、これらの設定がエンドユーザーの自然言語、地域との関連、または文化に結び付いているためである。このような設定は、 数値、日付、または時刻の表示、リストの言語的な並べ替え、暦の表示または 一般的な計量単位などの既定値の提供、12時間制と24時間制の 時刻表示の選択、およびユーザーが個別に設定するには煩雑すぎると感じる可能性のあるその他多くの詳細に 適用される。これらの設定をまとめて表す識別子は、通常 ロケールと呼ばれる。［BCP47］の拡張である Unicode ロケール［CLDR］は、Web 上の 国際化 API の基礎となる。特に JavaScript 言語［ECMASCRIPT］は、Unicode ロケールを ［ECMA-402］に含まれる API の基礎として使用する。

国際化設定。ユーザー固有の 言語および書式設定と、それに関連する文化的慣習の集合。ソフトウェアは、これらの設定を使用して、 そのユーザーと交換する情報を正しく処理または提示できる。

コンテンツまたはサービスが世界中のユーザーにとって利用可能で 受け入れられるものとなるように、Web 上ではさまざまな 国際化設定を提供できる。 これらの設定には、 次のものが含まれる場合がある。

• 解析、スペルチェック、および 文法チェックなどのテキスト処理に使用する自然言語。
• 画像、色、音声、形式、ナビゲーション要素、および 表示されるテキスト文字列などを含む場合がある ユーザーインターフェイス言語。
• 日付、時刻、数値、リスト、 およびその他の値の提示（人間向けの書式設定）。
• コンテンツの照合、並べ替え、および編成（ 電話帳や辞書など）。
• 祝日、就業規則、平日と週末の区別、月の数と 構成、年の番号付けなどを含む場合がある、 代替の時刻管理方式および暦。
• 税制または規制制度。
• 通貨

国際化。 文化、地域、または言語が異なる対象利用者に対応できる製品の設計および開発。国際化は、 英単語の「I」と「N」の間に18文字あるため、i18nと略されることがある。

ローカライズ。特定の対象市場または個人集団の個々の文化的 期待に合わせてシステムを調整すること。ローカライズには、ユーザー向けテキストおよびメッセージの 翻訳が含まれるが、それだけに限定されない。ローカライズは、英単語の「L」と「N」の間に 10文字あるため、l10nと略されることがある。特定の国際化設定の集合に対応する 特定のコンテンツおよび設定の集合が運用上利用可能な場合、そのシステムは ローカライズ済みであるという。

ロケール。言語タグなど、国際化 設定の集合を表す識別子。通常、この識別子はユーザーの優先言語を示し、 地理的地域（国など）といったその他の情報を含む場合もある。ロケールは、システムまたはプロセス内で 文化の影響を受ける動作を得るために API に渡されるか、動作環境で設定される。

ロケール対応（または 対応済み）。ロケールの変化に応じて、 文化および言語に固有の動作またはコンテンツを提供できるシステム。一般に、国際化されたシステムは、 多様なユーザーの 国際化 設定を満たすため、広範な ロケールをサポートできる。

言語 タグは、サブタグを使用して、言語、用字、地域、および特別に登録されたさまざまな 変種に関する情報を提供できる。しかし、これらのいずれとも直接対応しない国際化設定が 存在する場合がある。たとえば、多くの文化にはコンテンツ項目を並べ替える方法が複数あり、 適切な並べ替え順序を言語タグだけから常に推測できるとは限らない。そのため、ドイツ語の ユーザーは、辞書で使用される並べ替え順序と電話帳で使用される並べ替え順序のいずれかを選択したい場合がある。

歴史的に、ロケールはユーザーのプログラミング言語または動作環境に関連付けられ、それらに固有であった。 これらのアプリケーション固有の識別子は、多くの場合、言語タグから推測するか、言語タグに変換できた。 ロケールモデルの例には、Java の java.util.Locale、POSIX（ de_CH@utf8などの識別子）、Oracle データベース（AMERICAN_AMERICA.AL32UTF8）、または Microsoft の LCID（0x0409などの数値コードを使用）がある。これらの モデル、ISO639 や ISO3166 などの基礎標準、および初期の言語タグ（［RFC1766］など）の関係は、完全に意図されたものであった。 実装は多くの場合、HTTP の Accept-Language ヘッダーなど、既存のプロトコルの言語タグを 独自またはプラットフォーム固有のロケールモデルに対応付けており、現在も対応付けている。

現在の［BCP47］識別子構文が採用されて以降、多くのロケール モデルが BCP47 を直接採用するか、独自モデルと 言語タグの間の変換または対応付けを提供している。特に、 ［CLDR］として知られるオープンソースのロケールデータリポジトリの開発と採用により、 言語タグが ロケール識別子として広く一般に採用されるようになった。

共通ロケールデータリポジトリ（または ［CLDR］）。共通ロケールデータリポジトリは、 システムまたは動作環境で ロケールを有効にするために必要なデータ集合を定義、収集、および管理する Unicode Consortium のプロジェクトである。CLDR のデータおよびロケールモデルは、特にブラウザーで広く採用されている。

Unicode ロケール識別子または Unicode ロケール。言語タグであり、 UTR#35［LDML］で定義されるサブタグ選択に関する追加の規則および制限に従うもの。妥当な Unicode ロケール識別子はすべて、妥当な［BCP47］言語タグでもあるが、一部の 妥当な言語 タグは、妥当な Unicode ロケール識別子ではない。

正規 Unicode ロケール識別子。整形式の言語タグであり、 Unicode ロケール識別子の正規化規則を適用した結果得られるもので、この規則は ［LDML］に記載されている（第3節を参照）。この処理は、 任意の 妥当な［BCP47］言語タグを妥当な Unicode ロケール識別子に変換する。たとえば、非推奨のサブタグまたは 不規則な祖父条項付きタグは、IANA 言語サブタグレジストリに記載された優先値に置き換えられる。

［CLDR］は、Unicode ロケール識別子に関連する二つの 言語タグ拡張（［RFC6067］および ［RFC6497］）を定義し、管理している。これらの拡張により、 言語タグは、言語的または地域的な違いを超える 国際化 設定の変種を表したり、特定のロケール内に複数の選択肢またはユーザー設定がある場合に 書式設定の動作またはコンテンツを選択したりできる。Unicode ロケール識別子にこれらの拡張を含めることは必須ではない。 これらは、識別対象のロケールがいずれかの拡張による追加調整を必要とする場合にのみ使用される。 ［CLDR］は、ロケール識別子として使用される 特定のサブタグにも固有の解釈を適用する。詳細については、［LDML］の 第3.2節を参照されたい。

Unicode ロケール言語タグ拡張［RFC6067］は -u- サブタグを使用し、 ロケールに基づくさまざまな形式および動作を選択するためのサブタグを提供する。詳細については、 ［LDML］の 第3.6節を参照されたい。

変換済みコンテンツ言語タグ拡張 ［RFC6497］は、 -t- サブタグを使用し、用字間の翻字など、テキスト変換用のサブタグを提供する。 詳細については、［LDML］の 第3.7節を参照されたい。

Unicode ロケールは、Web 上の 国際化、特に JavaScript［ECMASCRIPT］の Intl ロケールフレームワーク［ECMA-402］の基礎として、ますます広く使用されている。

​コンテンツ作成者は、 正規 Unicode ロケール識別子である言語 タグを原則として選択するべきである。

［LDML］の 第3節に記載される追加のコンテンツ制限および正規化手順は、 ［BCP47］を直接使用する場合よりも 優れた相互運用性および一貫性をもたらす。

​実装は、 正規 Unicode ロケール識別子である言語 タグのみを原則として出力し、使用する言語タグを 正規タグ生成規則によって原則として正規化するべきである。

前述のとおり、［LDML］の 第3節に記載される追加のコンテンツ制限および正規化手順は、 ［BCP47］を直接使用する場合よりも 優れた相互運用性および一貫性をもたらす。このベストプラクティスは、実装が ［CLDR］のいずれかの拡張をサポート、生成、処理、または理解する必要があるという意味に 解釈するべきではない。

​コンテンツ作成者は、特定のアプリケーションが追加の調整を必要としない限り、 言語タグに 言語タグ拡張を含めるべきではない。

すべての Unicode ロケール識別子は、整形式の［BCP47］言語タグでもあることを 忘れないことが重要である。Unicode ロケール識別子では、 ［CLDR］の 言語タグ 拡張のいずれかを使用する必要はない。

非言語フィールド。自然言語のテキストデータを保存または 交換することを目的としない、データ構造の任意の要素。これには、ブール値、数値、日付などの 文字列以外のデータ型が含まれる。また、プログラムまたはプロトコルの内部 識別子などの文字列も含まれる。本文書では、この概念の略称として フィールドという用語を使用する。

文書形式またはプロトコルの仕様は通常、 さまざまなデータ値またはデータ構造の交換、処理、または表示を定義する。Web は主に、 データの直列化および交換にテキストファイルを使用する。生のバイトでさえ、通常は base64 などの文字列直列化を使用して送信される。そのため、 Web 上の 非言語フィールドも通常は 文字列で構成される。ここで重要な違いは、非言語フィールドは一般に、 ユーザーではなく、基礎となるアプリケーションによって解釈または使用されることを意図している点である。

ロケール中立。非言語フィールドが、 特定の言語、ロケール、または文化に特に適したものではなく、 ロケール対応の方法で提示するために明確に解釈できる形式で保存または交換される場合、そのフィールドは ロケール中立であるという。

多くの仕様は、［XMLSCHEMA11-2］または ［JSON-LD］が提供するような直列化方式を使用し、文書形式またはプロトコル内の 非言語フィールドに ロケール中立の符号化を提供する。

ロケール中立の表現自体が特定の 文化的設定に関連付けられる場合もあるが、そのような関連付けは最小限にするべきである。たとえば、ISO8601 の日時値の 直列化の多くはグレゴリオ暦に関連付けられているが、その形式、フィールドの順序、区切り文字、および視覚的 外観は特定のロケールに特に適したものではない（機械可読であることを意図している）。また、 上記の 例に示したように、値を任意の暦またはロケールで表示するよう変換できる。

言語ネゴシエーション。ユーザーの 国際化設定を、利用可能なロケール、ローカライズ済み リソース、コンテンツ、または処理とマッチングする処理。

ロケール フォールバック。決定論的なパターンに従って、より具体的なリソースからより一般的なリソースへ 「フォールバック」しながら、翻訳済みコンテンツ、ロケールデータ、またはその他のリソースを検索する処理。

ユーザーの設定は通常、ロケールまたは優先順位が付けられたロケールのリストとして表現される。言語をネゴシエーションする際、 システムは何らかのアルゴリズムに従い、利用可能な リソースから最も適合するコンテンツまたは機能を取得する。多くの場合、言語ネゴシエーションアルゴリズムは ロケールフォールバックを使用する。

​文書形式で フィールドを提示する仕様は、 周囲のコンテンツの言語に従ってデータを書式設定することを原則として要求するべきである。

非言語フィールドが文書またはアプリケーションの一部としてユーザーに提示される場合、 文書またはアプリケーションは、データが閲覧される「コンテキスト」を形成する。 コンテンツ作成者またはアプリケーション開発者には、フィールドを 利用体験の自然な一部に見せ、表示を制御する方法が必要になる。これは、コンテンツが現れるコンテキストの 言語タグによって示される。通常、 対応済みの実装は、この目的を達成するためにタグを ロケールとして解釈する。 非言語フィールドの提示にユーザーエージェントの実行時ロケールまたはローカライズを使用することは、 最後の手段に限るべきである。

​フォームを提示する、または文書形式もしくはアプリケーションで 非言語フィールドの入力を受け取る仕様は、 値の直近を囲むコンテンツまたはマークアップの言語の形式で 原則として値をユーザー向けに ローカライズして提示することを要求するべきである。

​非言語フィールドを提示、交換、または入力可能にする仕様は、 保存および交換に ロケール中立の形式を必ず使用しなければならない。

​実装は、文書形式またはアプリケーション内の 非言語フィールドを、 周囲のコンテンツの言語と一致する形式を使用して原則として提示するべきであり、 入力または編集のために同じ ロケールへ ローカライズされたコントロールを提供することが推奨される。

ユーザーは、フォームフィールドおよびその他のデータ入力において、非言語 フィールドの提示が、値の現れる文書またはアプリケーションと一致することを期待する。ユーザーは通常、 自身の入力がユーザーエージェントまたは動作環境ではなく文書のコンテキストに一致することを期待し、 入力検証、プロンプト、またはコントロールも同様にコンテンツと一致することを期待する。これにより、コンテンツ 作成者は完全にローカライズされた顧客体験を作成でき、一般的に 顧客の期待にも沿う。

4. 関連資料

国際化作業グループは、言語 タグの選択に関する記事など、追加のベストプラクティスおよびその他の参考資料を提供している。これには次のものが含まれる。

• Web 上の文字列：言語および書字方向のメタデータ ［STRING-META］
• 言語 タグの選択
• HTML および XML の言語タグ
• 言語を持たないテキストへのタグ付け
• ローカライズと国際化の比較

B. 謝辞

国際化作業グループは、この仕様に貢献した 次の人々に謝意を表する。

• 本文書を編集し、2006年の WD を公開した Felix Sasaki
• BCP47 拡張に貢献した Mark Davis、Y.Umaoka、および その他の人々
• WS-I18N の貢献者：本文書は、［WS-I18N-REQ］の 要件 R005 を満たすために作成された。