Copyright © 2020 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
本書は、Web上のドキュメントフォーマット、仕様書、および実装において、コンテンツの自然言語を識別するための定義とベストプラクティスを提供します。言語タグがユーザーのロケールの好みを示すために利用され、それにより情報の処理・書式化・表示がユーザー向けに行われる方法について説明します。
このセクションは公開時点での 本文書のステータスを示します。今後、他の文書がこの文書に取って代わる場合もあります。最新の W3C 公開文書一覧と 技術レポートの最新版は、 W3C 技術レポート一覧 https://www.w3.org/TR/ にて参照できます。
これは「World Wide Webにおける言語タグとロケール識別子」の最新の公開作業草案です。ワーキンググループはこれをワーキンググループノートにする予定です。
本書に関するコメントを送る場合は GitHub
issue を作成してください。また、
メーリングリスト www-international@w3.org
(購読,
過去ログ)
へも下記の通り送信可能です。メールの件名の頭に[ltli]
を記載してください。コメントを追跡しやすくするため、コメント毎に別々のissueまたはメールを送るようお願いします。どんなコメントも歓迎です。
本書はInternationalization Working Groupによって 作業草案として公開されました。
この仕様に関する議論には GitHub Issues の利用を推奨します。
作業草案として公開されたことは W3C会員による承認を意味するものではありません。
本書はドラフト文書であり、将来更新・置換・廃止される可能性があります。進行中の作業以外として引用するのは不適切です。
本書は 2017年8月1日 W3C特許ポリシー のもとで運営されるグループにより作成されました。 グループは本書がW3C勧告になることは想定していません。 W3Cは 作業成果に関連する特許の公開リスト を管理しています; そのページには特許公開の手続きも記載されています。特許の実内容で必須項目(Essential Claim)を含むと信じる場合は、 W3C特許ポリシー第6節 に従い、情報公開が必要です。
本書には 2020年9月15日 W3Cプロセス文書 が適用されます。
言語タグとロケールは、Webの国際化
（i18n
）の基礎的な構成要素の一つです。本書では、この国際化に関連する基本用語の多くについて定義を示します。
本書はまた、ドキュメント形式やプロトコルにおける自然言語の値を識別するために仕様作成者が必要とする用語とベストプラクティスを示しており、Internationalization (I18N) Working Group によって推奨されています。これら（およびその他多数の）ベストプラクティスや関連資料へのリンクは、Internationalization Best Practices for Spec Developers [INTERNATIONAL-SPECS]にも掲載されています。ここで示すベストプラクティスに加え、Web上の言語メタデータに関する追加のベストプラクティスは [STRING-META] にあります。
コンテンツの自然言語やユーザーの国際的な優先設定を識別するためのタグは、Webの基本的な構成要素の一つです。Webやインターネットのフォーマットやプロトコルで用いられる言語タグは [BCP47] によって定義されています。言語タグを一貫して使用することで、アプリケーションは言語に依存した書式設定や処理を行うことができます。例えば、ユーザーエージェントは表示用の適切なフォントを選択したり、Webページのデザイナーが言語ごとに異なるスタイルを適用したりすることがあります。
多くのコアなWeb標準は言語タグをサポートしています。これには [XML10] の
xml:lang 属性、[HTML] の lang および hreflang 属性、[XSL10] の language
プロパティ、CSS の :lang 擬似クラス（[CSS3-SELECTORS]）などが含まれます。SVG、TTML、SSML 等もこれに含まれます。
自然言語（本書では単に 言語）。人間が用いる音声、文章、または手話によるコミュニケーション。
言語の識別方法は多数あり、ソフトウェアがWeb上のコンテンツの言語を識別する必要が生じる理由も様々です。Web上のドキュメント形式やプロトコルは一般にインターネットの他の多くの部分で使われている識別子、すなわち [BCP47] で定義された言語タグを使用します。"BCP" という表記は「best current practice」を構成する一連の IETF RFC を指します。
言語タグ。言語を識別するために用いられる文字列。本書においては、言語タグは常に [BCP47] の言語タグを明示的に指します。これらの言語タグは1つ以上のサブタグから構成されます。
言語識別を要求する仕様は、BCP47への参照を行うことが必要です（MUST）。
仕様は、BCP47 の構成要素である特定の RFC を直接参照すべきではありません（SHOULD NOT）。
[BCP47] は複数部から成る文書であり、本書公開時点では二つの別個の RFC で構成されています。第一部は Tags for Identifying Languages（[RFC5646]）で、言語タグの文法、形式、および用語を定義します。第二部は Matching of Language Tags（[RFC4647]）で、言語タグを用いたマッチング、比較、選択のためのスキームや、優先設定とタグ付けされたコンテンツとの比較に関する有用な用語を説明します。
"RFC 5646 またはその後継" のような表現は、特定の文書バージョンが必要な場合に限り使用してもよい（MAY）とされています。
この参照スタイルはかつて一般的でしたが、BCP を参照する方がより正確です。言語タグの文法は [RFC4646] 以降で安定しているため、BCP を参照しても多くの実装に追加のコンプライアンスリスクは生じません。
仕様は、BCP47 の廃止されたバージョン（例: [RFC1766] や [RFC3066]）を参照してはなりません（MUST NOT）。
古い
BCP47 互換性を保持する必要がある仕様は、BCP47 の obs-language-tag 生成規則を参照すべきです（MUST）。
RFC4646 以降、BCP47 はより複雑で機械可読な言語タグの構文を定義してきました。この構文は安定しており、近い将来に変更されることは想定されていません。いくつかの仕様は古い文法（RFC1766 や
RFC3066 に見られる）との互換性を要求するかもしれませんが、古い文法はより許容的であり、BCP47 ではこれを obs-language-tag として扱っています。RFC4646
は現在の言語タグ文法を導入し、後に RFC5646 に置き換えられ、これらは現在の BCP47 の一部となっています。
URI の一部として言語情報を提供するアプリケーション（例: RDF の領域）では、BCP47 を使用することが推奨されます（SHOULD）。
現在、言語情報を表す URI はしばしば ISO 639 の一部の値を使うことがあり、例えばドイツ語で de（ISO 639-1）か ger（ISO
639-2）かの曖昧さが生じます。BCP47 とそのサブタグ登録に従うことで、このような曖昧さは回避できます。例えばドイツ語については登録上 de のみが用意されています。
サブタグ。ハイフン（ハイフンマイナス）で区切られた ASCII の英字または数字の列で、言語タグ全体の中で特定の意味要素を識別します。BCP47 ではサブタグは大文字でも小文字でも構いません（大文字小文字に意味はない）かつ通常は最大 8 文字とされます（ただし用途によって追加の長さ制限が適用される場合があります）。
言語タグに基づいてコンテンツや振る舞いを選択するには、BCP47（RFC4647）で定義されたいくつかの追加概念が必要です。本書では BCP47 から直接取り入れた次の用語を採用します：
IANA 言語サブタグ登録。IANA が提供する機械可読のテキストファイルで、言語タグ内で有効な全てのサブタグの包括的な一覧を含みます。（リンク: Registry）
仕様は、IANA Language Subtag Registry に寄与する下位標準（ISO639、ISO15924、ISO3066、UN M.49 など）を参照すべきではありません（SHOULD NOT）。
一部の標準は BCP47 の寄与標準の一つを直接利用することがありますが、その場合は当該標準への参照は適切です。多くの場合、参照の目的は有効なコード一覧とその意味を指定することにあり、BCP47 のサブタグ登録は安定していて曖昧さを解消するため、この種の参照には推奨されます。
BCP47 は2つの異なる適合レベルを定義します。詳細は BCP47 の classes of conformance を参照してください。言語タグについては、適合レベルは実装が言語タグ値に対して行うチェックの種類に対応します。
well-formed（構文的に正しい）言語タグ。BCP47 で定義された文法に従う言語タグ。すなわち、所定の長さの ASCII 英字および数字からなるサブタグがハイフンで区切られている構造を満たすものです。
有効な言語タグ。well-formed であり、さらに BCP47 の適合要件（たとえば各サブタグが IANA サブタグ登録に現れること）を満たすタグを指します。
仕様は言語タグが well-formed であることを要求すべきです（SHOULD）。
仕様は言語タグが valid であることを要求してもよい（MAY）。
仕様はコンテンツ作成者が valid な言語タグ を使用することを推奨すべきです（SHOULD）。
これは実装向けの推奨よりも厳格である点に注意してください。
コンテンツ検証ツールは、可能であればコンテンツが valid な言語タグ を使っているかチェックすべきです（SHOULD）。
タグがvalidかどうかを判定するには、登録へのアクセスまたはコピーと追加のランタイムロジックが必要です。コンテンツ作成者は有効な値のみを選択・生成・交換することが推奨されますが、言語タグのマッチングや他の一般的操作は有効性チェックを必須としないよう設計されています。サブタグの具体的な意味内容を理解する必要がある機能がある場合、その仕様はプロトコルやドキュメント形式の一部として valid なタグを規範的に要求する正当な理由になります。
言語タグ拡張（extension）。単一の英数字サブタグとして IANA に登録され、追加の種類の言語識別を許す BCP47 の補助サブタグの仕組み。
仕様は必要に応じて BCP47 の登録拡張を参照してもよい（MAY）。
特に、RFC6067（BCP 47 Extension U）は "Unicode Locales" として知られる拡張を定義しており、これは BCP47 に対して特定のロケール変種を選択するための追加的なサブタグ列を提供します。
仕様は言語タグの長さを制限したり拡張の除去を許容・奨励すべきではありません（SHOULD NOT）。
言語レンジ（Language range）。言語タグに似た構造を持つ文字列で、特定の属性を共有する言語タグの集合を識別するために使われます。
言語優先リスト。ユーザーの言語優先を識別する一つ以上の 言語レンジ
の集合で、通常はユーザーの好みに応じて順序付けまたは重み付けされています。HTTP の Accept-Language ヘッダーはこの種の言語優先リストの例です。
基本言語レンジ。ハイフンで区切られたサブタグの列からなる 言語レンジ。すなわち見た目は言語タグと同一です。
拡張言語レンジ。ハイフンで区切られたサブタグの列からなる 言語レンジ。拡張言語レンジでは、サブタグは有効なサブタグまたはワイルドカードサブタグ
のいずれかであり、任意の値にマッチします。*
一部の 言語優先リスト、例えば先述の Accept-Language
ヘッダーはリスト内の値に対して「重み（weights）」を提供しますが、重み付けはリストの順序の決定以外には依存すべきではありません。
言語タグのマッチングや 言語ネゴシエーション を定義する仕様は、使用する言語レンジが 基本言語レンジ か 拡張言語レンジ のどちらであるかを明示しなければなりません（MUST）。
言語タグマッチングを定義する仕様は、マッチング操作の結果が単一の結果（RFC4647 で定義される lookup）であるのか、あるいは（0個以上の）集合を返す可能性があるのか（RFC4647 の filtering）を明示しなければなりません（MUST）。
言語タグマッチングを定義する仕様は、利用可能なマッチングアルゴリズムと選択機構を明示しなければなりません（MUST）。
例えば JavaScript の国際化（ECMA-402）や CLDR は、実装者が調整可能な「ベストフィット」アルゴリズムを提供しています。
このセクションでは国際化とローカリゼーションに関する基本用語を定義します。
異なる言語を話す、あるいは異なる文化的背景を持つユーザーは、母語・文字体系・計量単位・カレンダー・その他の言語規則や文化的慣習に適合するように情報処理されたソフトウェアやサービスを必要とします。
言語タグは、コンテンツやユーザーに紐付いた国際的な選好を識別するためにも利用でき、これらの選好は利用者の自然言語・地域的なつながり・文化に関連しています。これらの選好は、数値・日付・時刻の表示、リストの言語的なソート、カレンダー表示や単位などのデフォルト値の提供、12/24時間制の選択など、個別に設定するには面倒な様々な処理に使われます。これら選好の識別子はまとめてロケールと呼ばれます。[BCP47]の拡張で定義されるUnicodeロケール [CLDR]は、ウェブ上の国際化APIの基盤であり、特にJavaScript [ECMASCRIPT]は[ECMA-402] APIの基礎にUnicodeロケールを利用しています。
国際的な選好。ユーザー独自の言語やフォーマット、およびそれに付随する文化的慣習の集合。ソフトウェアはこれらの選好を用いてそのユーザーとの情報のやり取りを正しく処理・提示できます。
ウェブ上では、世界中のユーザーに対してコンテンツやサービスが使いやすく受け入れられるように様々な国際的な選好を提供する必要があります。例として：
国際化。 文化・地域・言語が異なるターゲット層に対応可能な製品を設計・開発すること。国際化はしばしばi18nと略されます（英語"internationalization"のIとNの間に18文字あるため）。
ローカリゼーション。特定の市場や個人集団の文化的な期待に合わせてシステムを調整すること。ローカリゼーションはユーザー向けテキストやメッセージの翻訳だけに留まりません。l10n（LとNの間に10文字）と略されることもあります。特定のコンテンツと国際的な選好が表現され、それが運用可能な場合、そのシステムはローカライズ済みとされます。
ロケール。言語タグ等で表現される特定の国際的な選好の集合の識別子。通常はユーザーの優先言語や地域情報（例：国）を含みます。ロケールはAPIや実行環境で設定・受け渡され、システム内で文化的に影響を受ける振る舞いを得るために使われます。
ロケール対応（Locale-aware）（またはEnabled）。ロケールの変更に応じて文化や言語ごとに適切な挙動やコンテンツを提供できるシステム。一般に国際化対応システムは、多様なロケールへの対応によって様々な国際的な選好に応えます。
言語タグは言語・文字体系・地域・登録済みのバリアントなどの情報をサブタグで示すことができますが、時にこれと直接関連しない国際的な選好もあります。例えば文化によっては内容アイテムの並び順が複数あり、言語タグだけから適切な並び順が推測できない場合もあります。例えばドイツ語ユーザーは辞書式順や電話帳式順から用途に応じて選択できるべきです。
歴史的にはロケールはユーザーのプログラミング言語やOS環境に結びついていました。これらアプリケーション固有の識別子はしばしば言語タグに変換されたり、推定の根拠となり得ます。例として
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）（[CLDR]）。CLDRはUnicodeコンソーシアムのプロジェクトで、システムやOS環境にロケールを実装するためのデータを定義・収集・管理します。CLDRデータとそのロケールモデルは、特にブラウザで広く採用されています。
Unicodeロケール識別子（Unicodeロケール）。UTR#35 [LDML]に定められた追加のサブタグ選択ルールに従う言語タグ。任意の有効なUnicodeロケール識別子は[BCP47]の言語タグとしても有効ですが、一部の有効な言語タグはUnicodeロケール識別子としては扱えません。
標準Unicodeロケール識別子。Unicodeロケール識別子[LDML]の正規化ルール（第3節）によって変換された構文的に正しい言語タグ。この処理は任意の有効なBCP47言語タグを正規化済みUnicodeロケール識別子にします。例えば廃止済みサブタグや特殊な祖父タグはIANAサブタグ登録の推奨値に置き換えられます。
[CLDR]はUnicodeロケール識別子に関する2つの言語タグ拡張（[RFC6067]と[RFC6497]）を定義・管理しています。これら拡張により言語タグは言語・地域の違いを超えた国際的表現や、ロケール内で複数の選択肢・ユーザー選好に応じたフォーマットやコンテンツの選択も可能になります。Unicodeロケール識別子は必ずしもこれらの拡張を含む必要はなく、実際に拡張が必要な場合だけ使われます。[CLDR]はロケール識別子として特定サブタグの解釈も規定しています。詳細はLDML第3.2節を参照。
Unicodeロケール言語タグ拡張（[RFC6067]）は-u-サブタグを使い、様々なロケールベースのフォーマットや動作選択用サブタグを提供します。詳細はLDML第3.6節を参照。
変換コンテンツ言語タグ拡張（[RFC6497）は-t-サブタグを使い、スクリプト間の文字変換などのテキスト変換用サブタグを提供します。詳細はLDML第3.7節。
Unicodeロケールはますますウェブの国際化の基盤となっており、特にJavaScriptのIntlロケールフレームワーク（[ECMA-402]）で重要です。
コンテンツの作成者は、標準Unicodeロケール識別子となる言語タグを選択すべきです（SHOULD）。
LDML第3節で示される追加の内容規制や正規化処理により、直接BCP47を使う場合よりも相互運用性と一貫性が向上します。
実装は、標準Unicodeロケール識別子となる言語タグのみを出力し、入力する言語タグは正規化ルールで正規化すべきです（SHOULD）。
上記同様、LDML第3節の規制と正規化処理によって直接BCP47を使う場合よりも相互運用性、一貫性が得られます。このベストプラクティスは、実装がCLDR拡張の処理・生成・理解をすべてサポートする必要があることを意味するものではありません。
コンテンツ作成者は、特別なカスタマイズが必要な場合を除き言語タグ拡張を言語タグに含めるべきではありません（SHOULD NOT）。
すべてのUnicodeロケール識別子は同時に構文的に正しい（well-formed）[BCP47]言語タグですが、Unicodeロケール識別子はCLDR拡張のいずれも必須ではありません。
国際的選好や文化的選好の一部は個人に属し、コンテンツ作成者・サービスプロバイダー・OS・ユーザーエージェントがユーザーのために定義・管理します。
非言語フィールド。自然言語テキストデータの保存や交換を意図していないデータ構造の要素。ブール値・数字・日付などの非文字列型、プログラムやプロトコル内部識別子などの文字列も含む。本書ではフィールドという語で簡略に表現。
ドキュメントフォーマットやプロトコルの仕様は、様々なデータ値や構造の交換・処理・表示を定義します。Webは主にテキストファイルによってデータをシリアライズ・交換しており、生のバイトでも通常string型（base64等）で転送されます。従ってWebにおける非言語フィールドも一般的には文字列型になります。ここで重要なのは、非言語フィールドは一般にアプリケーション側で解釈されるもので、利用者自身が直接扱うものではないという違いです。
ロケール非依存。特定言語・ロケール・文化向けでない形式で保存・交換され、どのロケールにも曖昧なく提示できる非言語フィールドはロケール非依存とされます。
多くの仕様は、[XMLSCHEMA11-2]や[JSON-LD]等のシリアライズ方式を利用して、ドキュメントフォーマットやプロトコル内の非言語フィールドのロケール非依存エンコーディングを提供します。
ロケール非依存な表現自身が特定文化的選好に紐づけられることはあり得ますが、こうした結びつきは最小限にすべきです。例えばISO8601の日付/時刻値シリアライズはグレゴリオ暦に紐づけられますが、フォーマットや項目順・セパレータ・表示形態は特定ロケール向けではありません（機械可読性重視）。上記例のように、任意のカレンダー・ロケール表示に容易に変換できます。
言語ネゴシエーション。ユーザーの国際的選好を利用可能なロケール・ローカライズリソース・コンテンツ・処理にマッチさせるプロセス。
ロケールフォールバック。特定化された翻訳・ロケールデータ・リソースがない場合、より一般的なものに順次フォールバックして探す手続き。
ユーザーの選好は通常ロケールまたは優先ロケールリストとして表現されます。言語ネゴシエーションではアルゴリズムで最適なコンテンツや機能を提供します。多くの場合言語ネゴシエーションアルゴリズムはロケールフォールバックを用います。
ドキュメントフォーマットでフィールドを提示する仕様は、データを周囲コンテンツの言語に沿って書式化することを要求すべきです（SHOULD）。
ドキュメントやアプリケーションの一部として非言語フィールドを提示する場合、その文書・アプリケーションが「コンテキスト」となります。コンテンツ作者や開発者はフィールドを体験の一部に見せたり表示を制御したりできる必要があります。これには、そのコンテキストの言語タグが重要です。通常、対応システムはタグをロケールとして扱いそれを達成します。ユーザーエージェントの実行時ロケールが非言語フィールドの提示ロケールになるのは最終手段とすべきです。
フォームや非言語フィールド入力を提示する仕様は、値が周辺コンテンツ言語のフォーマットでユーザーにローカライズ提示されるよう要求すべきです（SHOULD）。
ドキュメントフォーマットやアプリで非言語フィールドを提示・交換・入力受付する仕様は、保存・交換時にロケール非依存形式を使うことを必須（MUST）とします。
実装は、ドキュメントフォーマットやアプリで非言語フィールドを提示する際に、周囲の言語に一貫したフォーマットを用い、入力・編集にも同じロケールにローカライズされたコントロールを提供すべきです（SHOULD）。
ユーザーは、フォーム項目や他のデータ入力が、値が出現するドキュメントやアプリの文脈に沿った表示であることを期待します。また入力検証やプロンプト・コントロールも内容と一貫しているべきです。これによりコンテンツ作成者は完全なローカライズ体験をユーザーに提供でき、顧客の期待にも合致します。
国際化ワーキンググループ（Internationalization WG）は、言語タグ選択に関する記事など、追加のベストプラクティスや参考文献を提供しています。これらには以下が含まれます：
2015年4月23日付けの作業草案以降の変更は、githubコミットログで参照できます。本書はその版以降大幅に構成変更されました。特に：
2006年6月20日の改訂以降に行われた追加の変更：
2006年4月19日付公開 版以降の変更記録：
序文セクションを全面的に書き直し、文書の適用範囲、応用シナリオ、ロケールと自然言語の区分説明などを含めました。
[BCP47]に依存する用語は定義せず、該当文献への参照のみに変更。加えて各用語に例を追加。
言語値・ロケール値の要件は順守セクションから本文へ移動しました。
改訂履歴セクションを新設しました。
国際化ワーキンググループは本仕様への貢献者へ感謝を表明します：