Copyright © 2017-2024 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
この文書は、Web で使用される文字列について、言語および方向を識別するためのベストプラクティスを説明します。
この節は、公開時点におけるこの 文書の状態を説明します。現行の W3C 公開文書の一覧と、この技術報告書の最新改訂版は、 https://www.w3.org/TR/ にある W3C 技術 報告書インデックスで参照できます。
この文書へのコメントを歓迎しますが、追跡しやすくするため、各コメントについて個別の課題を作成し、 URL を使用してコメント対象の節を指してください。
この文書は、国際化 ワーキンググループにより、 ノートトラックを使用して グループノートとして公開されました。
このグループノートは 国際化ワーキンググループによって承認されていますが、 W3C 自体またはその メンバーによって承認されているわけではありません。
これは草案文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。 この文書を作業中のもの以外として引用することは適切ではありません。
W3C 特許 ポリシーは、 この文書に対してライセンス要件またはコミットメントを課しません。
この文書は、 2023年11月03日版 W3C プロセス文書に準拠します。
この文書は、JSON、WebIDL、およびその他の非マークアップデータ言語に基づく形式に関連する一連の仕様レビューを通じて、 国際化ワーキンググループが行った観察の結果として作成されました。XML などのマークアップ形式とは異なり、 これらのデータ言語は一般に拡張可能な属性を提供せず、組み込みの言語メタデータや方向メタデータを備えるものとして 構想されていませんでした。
この文書の概念は、Web 上で文字列が使用されるあらゆる場合に適用できます。これは、文字列が 形式化されたデータ構造の一部である場合だけでなく、単に JavaScript スクリプトや保存された文字列リストに由来する場合にも 当てはまります。
Web 上の自然言語 情報は、言語メタデータと方向メタデータの存在に依存し、またその恩恵を受けます。Unicode のサポートとともに、 テキスト範囲のブロック方向および 自然言語を含め、 指定するための仕組みは、Web 向けの新しい形式や技術を開発する際の重要な国際化上の考慮事項の 1 つです。
HTML や XML などのマークアップ形式、および CSS や XSL などの関連するスタイル言語は、 かなり成熟しており、組み込み機能によって世界の言語の交換と表示をサポートしています。文字列および 文字列ベースのデータ形式にも、世界の言語と文化を完全かつ一貫してサポートするために、同様の仕組みが必要です。
この文書では、[RFC2119] の大文字イタリックのキーワードは 通常の意味を持ちます。また、次のようなスタイル上の規約を使用します。
定義は、このように異なる背景色と 装飾で表示されます。
ベストプラクティスは、このように異なる背景色と 装飾で表示されます。
この節では、この文書の内容を理解するために必要な主要な用語の短い定義を示します。 ここで示される用語の多くは、[I18N-GLOSSARY] から取られたものです。便宜のために ここに再掲しています。
双方向テキストまたは右から左のテキストに詳しくない場合は、基本的な 導入がここにあります。これは、 Unicode 双方向 アルゴリズムがどのように機能するか、またそれとブロック方向との相互作用についての 基本的な理解を与え、この文書を読むための十分な助けとなります。追加の資料は、 国際化ワーキンググループの 仕様 開発者向けベストプラクティスにあります。
メタデータとは、データ についてのデータです。つまり、追加の文脈、意味、または表示を提供するために データ構造に含められる情報です。この文書では、メタデータの機能は、方向および 言語に関する情報を表現することです。[I18N-GLOSSARY]
生成者とは、自然 言語文字列データが、後で保存、処理、または交換されるために作成される任意のプロセスです。[I18N-GLOSSARY]
消費者とは、 表示または処理のために自然言語文字列を受け取る任意のプロセスです。[I18N-GLOSSARY]
直列化に関する合意とは、文字列メタデータの直列化について、 生成者と消費者の間で共有される理解です。つまり、それをどのように理解し、 直列化し、読み取り、送信し、削除するか、などに関するものです。[I18N-GLOSSARY]
Unicode 双方向アルゴリズム [UAX9] は、 UBA とも呼ばれ、段落方向という概念を定義します。これは 「段落」の初期基底方向であり、左から右または 右から左のいずれかに解決されます。「段落」という用語は、UBA 内部で特定の意味を持ちます。 この文書の文脈では、この用語は誤解を招きます。一般に、Web 上の文字列やその他のデータは、 何らかの文書形式における「テキストの段落」ではないためです。この文書では、通常、次の 2 つの より具体的な用語を使用します。
ブロック方向。テキストブロックの初期基底方向であり、 左から右または右から左のいずれかに解決されます。ブロックとは、 文書内の段落やデータファイル内の文字列など、全体としてのテキスト単位を指します。 「ブロック」という名前は、インライン方向との対比として選ばれています。Unicode では、この値を 段落方向と呼びます。 [I18N-GLOSSARY]
文字列方向。特定の文字列の全体的な方向であり、 文字列内部の方向性を持つランの表示順序を示します。さまざまなデータ構造内で送信される文字列は、 しばしばブロック（段落など）に挿入されます。そのような場合、文字列方向は文字列の bidi 分離の一部として 必要になります。
この文書では、文字列全体の文字列方向を識別すること、 およびさまざまな文脈で文字列を表示する際に文字列方向をどのように送信し適用するかを扱います。 文字列内のテキストランの方向または表示をどのように決定するかについては扱いません。
bidi アルゴリズムは、主として文字プロパティに基づいて隣接する文字を配置することに焦点を当てています。 ブロック方向は、(a) 強い型を持つ LTR および RTL 文字のランが表示される視覚的な順序と方向、 および (b) 句読点などの弱い方向性を持つ文字または中立文字がある場合に、それらの項目を他の内容に対して どこに配置するかを決定します。
文字列メタデータの扱いについて、真空中で代替案を検討することはできません。文字列処理とデータ形式について 議論するための枠組みを確立する必要があります。
文字列は、コンテンツ作者がプレーンテキストエディター、テキストメッセージ、または編集ツールに文字列を入力する場合、 スクリプトが Web ページからテキストをスクレイピングする場合、または別のアプリケーションやリポジトリから既存の 文字列集合を取得する場合など、さまざまな方法で作成されます。この文書で検討しているデータ形式では、 多くの文字列がバックエンドのデータリポジトリや各種データベースに由来します。文字列のソースは、 データの文字列方向および言語に関する情報を含むインターフェイス、 API、またはメタデータを提供することがあります。また、方向または言語が提供または指定されていない場合に適した デフォルトを提供するものもあります。この文書では、文字列の生成者とは、 人間であれ仕組みであれ、保存または送信のために文字列を作成または提供するソースを指します。
文字列が作成されるときには、(a) その文字列に関連付けられる適切な言語と文字列方向を検出または取得し、 (b) 必要に応じて、言語および文字列方向を保存し伝達するように文字列を設定する手順を 取る必要があります。
たとえば、HTML フォームから抽出された文字列の場合、文字列方向は、フォームフィールドの算出値から検出できます。
そのような値は、html 要素などの以前の要素から継承されることもあれば、
input 要素自体のマークアップやスタイルを使用して設定されることもあります。
ユーザーは、キーボード
ショートカットキーを使用することで、フォームフィールドのテキスト方向を変更することもできます。
dirname 属性は、フォーム送信時にその値を自動的に伝達する方法を提供します。
同様に、HTML フォーム内の言語情報は、通常、html タグ上の lang 属性、またはツリー内の祖先要素の lang
属性から継承されます。
文字列の生成者が、別の生成者によって保存され、かつ文字列方向と言語がすでに 確立されている場所からその文字列を受け取る場合、生成者は、言語と文字列方向がすでに 設定されていることを理解し、その情報を消費者向けにどのように変換または符号化するかを理解する必要があります。
消費者とは、処理のために文字列を受け取り、場合によってはそれをユーザーに 露出する文脈に配置するアプリケーションまたはプロセスです。表示目的では、 その文脈で文字列のブロック方向と言語が正しく適用されることを保証しなければなりません。 処理目的では、少なくとも言語と方向を保持しなければならず、言語固有の操作を行うために 言語および方向データを使用する必要がある場合があります。
文字列を適切に表示するには、追加のマークアップの適用、制御コードの追加、または表示プロパティの設定によって、 文字列 方向と言語をレンダリング文書またはプロセスに与える必要があります。これは、表示コンテキストで 文字列が正しく見えるようにするため、その文字列に適用すべき文字列方向または言語をレンダリングソフトウェアに示します。 言語と方向の両方について、言語が適用されるテキスト範囲の境界を明確にしなければなりません。 テキスト方向については、bidi アルゴリズム [UAX9] の波及効果を避けるため、 埋め込まれた文字列を周囲のテキストから分離しなければなりません。
ある文書形式の消費者が、別の文書形式の生成者になることがある点に注意してください。
任意の生成者 と消費者の間には、 文書形式が何を含み、各フィールドまたは属性内のデータが何を意味するかについての 合意が必要です。文字列の生成者が、その文字列の 文字列方向または言語に関する情報を収集し 伝達するために特別な手順を取る場合は常に、文字列の消費者が生成者によるこの情報の符号化方法を 理解するという期待のもとで行わなければなりません。
生成者が何の処置も取らない場合でも、消費者は、たとえ何らかのデフォルト値を提供するだけであっても、 適切な文字列方向および言語を決定するために どの規則に従うかを判断しなければなりません。
一部のシステムまたは文書形式では、文字列の生成者と消費者に必要な挙動が完全に指定されています。 他のものでは、そのような合意は利用できません。必要な言語または方向情報をどのように符号化し、 送信し、後で復号するかについての合意を提供するのはユーザー次第です。JSON などの低レベル仕様は、 デフォルトでは文字列メタデータ構造を提供しないため、それらに基づく文書形式は自ら「合意」を 提供する必要があります。
Web は、ほとんどのデータを符号化するために文字列と文字列シーケンスを使用します。異なるデータ型
（数値、時刻値、または base64 などのバイナリデータ直列化など）を別にしても、
文字列データ型を使用するものとして定義されているが、自然
言語データ値として使用されることを意図していない値が存在します。たとえば、CSS の予約キーワードや
WebIDL 文書内のさまざまな定義の名前など、仕様によって定義される構文上の内容は、それぞれの
文書形式またはプロトコルにおけるローカライズ可能なテキストの一部ではありません。
多くの仕様では、ユーザーが所定の名前空間または文書形式の中でユーザー提供値を指定することも許可されています。 たとえば、Wifi ネットワークの SSID はユーザー定義です。CSS スタイルシート内のクラス名も同様です。 ほとんどの仕様では、これらの名前に幅広い Unicode 文字を許可しています（また、許可することが推奨されています）。 多くのユーザーは、値を扱いやすくするために、何らかの自然言語の単語として認識できる値を選びます。 しかし、これらの文字列が自然言語の単語で構成されているとしても、この種の文字列はローカライズ可能な テキストとは見なされず、言語または文字列方向に関連する追加のメタデータを負わせる必要はありません。 通常、それらはコンピューターが値を照合できるようにする単なる識別子です。
ときに有用なテストとして、識別子を
tK0001.37B のような任意の文字列に置き換えても、なお許可され、機能し、
「普通」であるなら、それはローカライズ可能な
テキストではありません。
たとえば、下の基本例では、JSON 文書内のすべてのキー
（id、title、authors、language、
publisher など）は構文上の内容です。ISBN、言語タグ、公開日などのデータ値も
構文上の内容です。実際の書名、著者名、および出版社名だけが自然言語データ値であり、したがって
ローカライズ可能なテキストです。
この節は、Web 上のデータ形式における言語および文字列方向を識別するための、国際化（I18N）ワーキンググループによる ベストプラクティス一式で構成されます。場合によっては、既存の標準にギャップがあり、I18N WG の勧告が追加の 標準化を必要としたり、完全な採用への障壁が存在したりすることがあります。
主な課題は、データ値の生成者と消費者の間で共通の直列化に関する合意をどのように確立するかです。これにより、各データフィールドの 言語および文字列方向を どのように符号化し、見つけ、解釈するかをそれぞれが把握できます。自然言語文字列フィールドの言語および 文字列方向の両方を 提供するためにメタデータを使用することで、必要な情報が存在し、最小限の処理で提供および抽出でき、 生成者または消費者がデータを走査したり変更したりする必要がなくなります。
国際化ワーキンググループがあらゆる仕様に対して求める最も基本的なベストプラクティスは、次のとおりです。
自然言語テキストを含む任意の文字列フィールドについて、その特定の文字列の言語および 文字列方向を 判断できなければなりません（MUST）。そのような判断は、文字列レベルまたは文書レベルの メタデータを使用するべきであり（SHOULD）、ヒューリスティックに依存するべきではありません （SHOULD NOT）。
この節では、文字列値の直列化に対する 4 つのアプローチについて説明します。仕様は、文書形式および プロトコルにおける言語メタデータと方向メタデータの管理について完全な解決策を形成するために、 これらを併用することが意図されています。
非言語フィールド （すなわち、人間の言語ではないデータを含む文字列）に対して、言語メタデータまたは方向メタデータを割り当てたり要求したりすることは 避けてください。これには、アプリケーション内部のデータ 値 [INTERNATIONAL-SPECS] が含まれることに注意してください。
構文上の内容項目または ユーザー提供 値の値は、（たとえばデバッグの補助として）人間に意味を伝える単語風のトークンを使用することがよくありますが、 その値をユーザーに提示するためには、一貫してローカライズ可能な表示文字列で包む必要があります。
消費者が何らかの非言語データに
言語タグを割り当てる必要がある場合は、言語タグ zxx（非言語）を使用するべきです
（SHOULD）。消費者がそのようなデータに
文字列方向を割り当てる必要がある場合は、値
auto を使用するべきです（SHOULD）。
仕様は、構文上の 内容（ユーザー提供 値を含む）と、ローカライズ可能なテキストを 注意深く区別するべきです（SHOULD）。
個々のローカライズ可能なテキスト 値について、言語および 文字列方向を示すために、フィールドベースのメタデータまたは文字列データ型を 使用してください。
単一の言語で現れるローカライズ可能な
テキストフィールドについては、その値を表すためにデータ構造を使用してください。
推奨される表現は 3 つのフィールドを持つオブジェクトです。フィールド value は
実際の文字列を含みます。フィールド lang は、妥当な [BCP47]
言語タグを含みます。フィールド
dir は、その文字列の文字列方向（値
ltr、rtl、auto のいずれか）を含みます。
言語または文字列方向を判定するために ヒューリスティックを使用すると、特定の場合には必ず失敗するため、それらの文字列について正しい結果を提供する方法が必要です。 メタデータの割り当て（リソース全体のデフォルトとして、または文字列固有のラベルとして）は、 ヒューリスティックを適用して結果を推測する必要をなくす意図的な行為です。
ブロック方向を 示すためにメタデータを使用することが望ましいのは、first strong のような方法で消費者が方向を補間することや、データ自体の変更を必要とする方法（RLM/LRM マーカーの挿入や 双方向制御など）の使用を要求せずに済むためです。
[WebIDL] で定義されるデータ構造については、各
ローカライズ可能な
テキスト（自然言語テキスト）フィールドを
として
定義してください。
Localizable
これは言語メタデータと方向メタデータの両方を組み合わせるもので、一貫して採用されれば、異なる形式間の交換を 容易にします。異なる仕様や文書形式の間の一貫性により、文字列データを容易に交換できます。 フィールド属性に同じ名前を付け、同じ意味論を採用することで、異なる仕様は、他のデータソースからリソースへ 値を抽出したり追加したりしやすくなります。
リソースが多数の自然言語文字列を含む場合（特にそれらの文字列がすべて同じ言語である場合）、上で説明した ローカライズされた文字列表現を使用すると非効率になることがあります。これらの文字列の符号化の複雑さを減らすため、 仕様は、言語および文字列 方向について、リソースレベルのデフォルトを確立できます。言語は方向を含意しないため、これらは別個の値です。 それでもなお、上記の表現を使用して、任意の文字列値について 言語または方向のいずれかを上書きできる必要があります。
リソース全体のデフォルトとは、 リソースまたは文書レベルで指定され、そのリソースに含まれる任意のラベルなし値に適用できる値です。
仕様は、与えられたリソース内のすべての文字列について、デフォルト言語およびデフォルトの 文字列 方向を提供する仕組みを定義してもよいです（MAY）。ただし、仕様は、リソース全体のデフォルトで十分であると仮定してはなりません （MUST NOT）。リソース全体の設定が利用可能であっても、文字列固有のメタデータを使用して そのデフォルトを上書きできなければなりません。
仕様が独自の文書レベルのデフォルトを定義する場合は、2 つの任意フィールドを提供してください。
リソース全体のデフォルト言語フィールドは language と呼ばれるべきであり
（SHOULD）、妥当な [BCP47]
言語タグを含むように指定されるべきです。
仕様は、実装が [BCP47] 言語タグが
整形式であるかどうかだけを
検査すればよいことを指定するべきです（SHOULD）。
デフォルトに対する例外は常にあり得るため、ユーザーが文字列ごとにデフォルトを上書きできる必要があります。
メタデータを使用して方向が外部から設定されている場合、first-strong ヒューリスティックは文字列に適用されません。
U+200F RIGHT-TO-LEFT MARK などの強い方向性を持つ文字が文字列の先頭に
付加されていたとしても、リソース全体のデフォルトメタデータは、波及
効果を生じさせる形で、その文字列の表示を上書きすることがあります。したがって、内容は、
文字列方向がリソース全体のデフォルトと一致しない文字列について、
そのデフォルトを上書きする文字列レベルのメタデータを提供できる必要があります。
[JSON-LD] の @context 仕組みを
利用できる仕様については、文書レベルのデフォルトを提供するために @language および
@direction フィールドを使用してください。
文書内で単一フィールドの複数言語バージョンを保存するには、言語マップを使用してください。
[WebIDL] で定義されるデータ構造については、そのフィールドを定義するために LanguageMap を使用してください。
世界は単一言語ではありません。単一の言語だけを含む文書を持つということは、内容をローカライズするために、 言語ごとに文書の多数の反復を提供することを意味します。これは、内容を要求するときに言語ネゴシエーションも 必要とする可能性があります。
これに対処する 1 つの方法は、文書内の各ローカライズ可能なテキストフィールドについて、 多言語値を許可することです。
言語選択は、言語タグ文字列値をユーザーの優先ロケールと正確に照合するだけではありません。 オブジェクト表現による通常のローカライズ可能な テキストフィールドでは、その値に関連付けられた言語タグを発見するために、オブジェクトを逆直列化する必要があります。 与えられたファイルに多数の値がある場合、これは非効率になることがあります。このような場合のベストプラクティスは、 言語マップを使用してローカライズ可能なテキスト値を 組織化することです。そのようなマップは、選択の目的で言語タグを公開しますが、与えられた文字列値について 言語と方向の両方を上書きする必要がある可能性があるため、マップの値側では引き続きオブジェクト表現を使用します。
他の情報がない場合、デフォルト方向およびデフォルト言語は不明であると指定してください。
明示的なメタデータが利用可能であれば、ヒューリスティックを適用する必要性に優先します。これは論理的です。 ヒューリスティックな方法は、必要な方向をそれ自体で確実に推定できず、メタデータが明示的に提供されている場合には、 それが権威あるものとして意図されているという示唆があるためです。
消費者がデータにフォールバック戦略を適用すべき時を知るためには、言語と方向が未知の量であることを 消費者が知っていることが不可欠です（これには、言語検出、または方向についての first-strong ヒューリスティックが含まれ得ます）。 特に、デフォルト方向を LTR に設定するべきではありません。そうすると、RTL 用字で書かれた文字列により適した first-strong 検出の必要性が上書きされてしまうためです。
メタデータが利用できない場合、文字列の消費者は、文字列の基底方向を検出するために、Unicode 標準の first-strong 検出アルゴリズムに基づくことが望ましいヒューリスティックを使用するべきです。
first-strong アルゴリズムは、文字列内で最初の強い方向性を持つ文字を探し （特定の予備的な部分文字列はスキップします）、それが文字列全体の 文字列方向を表すと仮定します。しかし、最初の強い方向性を持つ文字は、 文字列全体の実際の、または望ましい文字列方向と常に一致するわけではないため、必要に応じてこの問題に対処するための メタデータを提供できるべきです。
first-strong ヒューリスティックに依存する場合、特定の基底方向を強制する必要がある箇所では コンテンツ開発者が文字列の先頭に RLM/LRM を使用できるようにしてください。ただし、既存の文字列にこれらの文字の いずれかを先頭付加してはなりません。
ほとんどの場合、RLM/LRM 書式文字が利用可能であることに依存しないでください。
文字列データが Web フォームまたはその他の単純な環境でユーザーやコンテンツ開発者によって提供されている場合、 ユーザーはこれらの書式文字を入力できない可能性があります。実際には、ほとんどのユーザーは、そのような文字が存在することや その使い方を知らないでしょう。Web フォームは、入力のブロック方向を設定する（そうすべきです）ことで、即時の確認においてそれらの使用を 不要にできます。
仕様は、方向メタデータが利用できず、他の方法でも提供できない場合を除き、 文字列方向を利用可能な言語メタデータから補間することを許可するべきではありません （SHOULD NOT）。
すべてのリソースが利用可能なメタデータの仕組みを使用するわけではありません。言語タグの用字系サブタグ （または [BCP47] および [LDML] に基づく 「可能性の高い」用字系サブタグ）は、他のデータが利用できない場合に、 ブロック方向または 文字列方向を推論するために使用できることがあります。 言語情報を使用することは「最後の手段」であり、仕様はそれを ブロック方向を示す主要な方法として使用するべきではありません （SHOULD NOT）。メタデータを提供する努力をしてください。
自然言語テキスト値を含む文書形式またはプロトコルの仕様は、各自然言語内容値について ブロック方向を保存するための データフィールドまたは属性を定義する必要があります。これらの定義は、相互運用性を確保するために Web 全体で 一貫している必要があります。なぜなら、ある文書形式の消費者は、受け取った値について ブロック方向を、自らが生成するフィールドにマッピングする必要があるか、 内容を表示するときに各文字列の文字列方向を制御する必要があるためです。 この節では、使用する具体的な内容とともに、そのような定義を提供する方法について説明します。
内容方向を定義するための一般的なユースケースは 2 つあります。(i) データ構造内のフィールドとして 文字列方向を保存および送信するための 方向メタデータフィールドを定義すること、または (ii) 与えられた自然言語内容の一部にブロック方向を関連付けるための 方向属性を定義することです。
方向メタデータフィールド。方向メタデータフィールド（または短く 方向フィールド）とは、与えられた自然言語文字列フィールドまたはデータ値に 文字列方向を関連付けるために使用される、データ構造内のフィールドです。
方向属性。方向属性とは、関連付けられた自然言語文字列内容の 文字列方向を提供する、通常はマークアップ言語における属性として表される フィールドまたは値です。
データ構造またはプロトコル内で方向メタデータフィールドを定義するときは、
フィールド名 direction を使用してください。
データ値には、名前 direction が望ましいです。名前 dir は許容される代替です。
マークアップ言語などにおける属性には、名前 dir が望ましいです。
属性に direction を使用することは、このユースケースでは長く、比較的一般的でないため、
推奨されません。なお、[HTML] と [XML10]
の両方には、
組み込みの dir 属性があります。dir
属性は文書内でスコープを持つべきであり、bidi 分離を提供するように定義されるべきです。
方向メタデータフィールドまたは
方向属性の値は、
ltr、rtl、および
auto の値を含み、かつそれらに限定されるように定義してください。
値 ltr は、CSS 書字
モード [CSS-WRITING-MODES-4] によって示されるのとまったく同じ方法で、
左から右の方向を示します。
値 rtl は、CSS 書字
モード [CSS-WRITING-MODES-4] によって示されるのとまったく同じ方法で、
右から左の方向を示します。
値 auto は、ユーザーエージェントが [HTML] によって定義された
auto のアルゴリズムを使用して、
ブロック方向（「段落
方向」）を決定することを示します。このヒューリスティックは、双方向アルゴリズム [UAX9] における段落レベルの決定に類似した方法で、
強い方向性を持つ最初の文字を探します。
auto が複数のフィールドまたは文書全体に適用される場合、それは
方向が各フィールドについて個別に導出されるべきであることを意味します（自動的に判定できない場合には、
文字列固有のメタデータが上書きを提供します）。これは、ほとんどの文字列の
文字列方向を
first-strong ヒューリスティックで確実に判定できる、混在方向の文字列グループにラベル付けする場合に有用です。
可能な限り、個々の文字列の実際の文字列方向（ltr または rtl）を、
auto の代わりに保存または交換するべきです。
値が真に不明である場合は、方向フィールドを省略することが望ましいです。
文書形式またはプロトコルの仕様には、通常、例が含まれます。例には必然的に自然言語テキストフィールドが含まれます。
仕様で例を作成するときは、自然 言語テキストを含むフィールドについて、この文書に示される直列化とベストプラクティスを常に使用してください。 その形式またはプロトコルがリソース全体のデフォルトをサポートしている場合は、例の中で デフォルトを設定することを示してください。その形式またはプロトコルが文書レベルのデフォルトをサポートしていない場合、 またはデフォルトを示すことが不便な場合は、例の中で単一言語のローカライズ可能なテキスト フィールドまたは言語マップを使用してください。
この文書で説明するさまざまな言語メタデータおよび方向メタデータの仕組みを提供する仕様の実装者を含む、コンテンツ 生成者は、ここに示すベストプラクティスを どのように実装するかについて、一定の裁量を持ちます。たとえば、文書形式がリソース全体のデフォルトと 単一言語のローカライズ可能なテキストフィールドの両方を提供する場合、ユーザーはどちらを選ぶべきでしょうか。
文書形式またはプロトコルによって言語についてのリソース全体のデフォルトが提供される場合、 それは常に文書の内容に最も適した言語に設定されるべきです（SHOULD）。 多くの場合、これは生成ユーザーのロケールです。
文書形式またはプロトコルによって方向についてのリソース全体のデフォルトが提供される場合、 それは常に文書の内容と最も関連する方向に設定されるべきです（SHOULD）。 通常、この方向は、提供されている場合、文書レベルの言語デフォルトと一致します。
たとえば、文書のリソース全体の言語が en-US
（英語、米国）である場合、その言語に関連付けられた方向が左から右であるため、文書のリソース全体の方向はおそらく
LTR
であるべきです。
生成者は、 リソース全体のデフォルトが提供されており、文字列固有の値が そのデフォルトと一致する場合、文字列固有の言語メタデータまたは方向メタデータを含めるべきではありません （SHOULD NOT）。
生成者は、与えられた文字列の値が リソース全体のデフォルトよりも具体的であるか、 まったく異なる場合、文字列固有の言語メタデータを含めるべきです（SHOULD）。
たとえば、リソース全体のデフォルト値が
fr（フランス語）であり、文字列に関連付けられた言語が
fr-FR（フランス語、フランス）である場合、
生成者は、より具体的な
fr-FR タグを持つ文字列固有のメタデータを生成するべきです。
同様に、言語が de（ドイツ語）のようにまったく異なる場合にも、
生成者は
文字列固有のメタデータを生成するべきです。
言語タグは、より多くのサブタグを含む場合、 より具体的です。
生成者は、内容の 文字列方向が、提供された リソース全体のデフォルトの方向と反対である任意の内容について、 たとえ文字列自体が曖昧でない場合でも、文字列固有の方向メタデータを含めるべきです （SHOULD）。
多くの文字列は、全体的な文字列方向と一致する強い方向性を持つ文字だけで構成されます。 この方向がリソース全体のデフォルト（デフォルトが存在する場合）と一致しない場合、 文字列方向を含める必要があります。これにより、 消費者が方向を判断するために文字列を内省する必要がなくなり、 また、フィルタリングや選択などのプロセスが内容の方向を誤解しなくなります。
言語メタデータおよび文字列 方向メタデータを収集し、直列化し、送信する目的は、消費者がそれを使用して文字列データを正しく表示および 処理できるようにすることです。
消費者は、関連付けられた文字列値を処理または表示するとき、文書形式またはプロトコルによって提供される 任意の言語メタデータを使用するべきです（SHOULD）。
文字列が文書内で表示される、または文書に挿入される場合、消費者は周囲のテキストから方向的に それを分離するべきです（SHOULD）。
消費者は、文字列が文書に挿入されるとき、方向メタデータを文字列に適用するべきです （SHOULD）。この文字列 方向が文字列に関連付けられたメタデータによって提供されている場合、消費者はそれを使用するべきです （SHOULD）。そのようなメタデータが利用できない場合は、方向を割り当てるために first-strong ヒューリスティックを使用するべきです（SHOULD）。
挿入された文字列値を双方向分離で包むことは問題を引き起こさず、そうすることで 波及効果を防ぎ、最良の結果を生みます。
消費者は、文字列が文書に挿入されるとき、言語メタデータを文字列に適用するべきです （SHOULD）。利用可能な任意の言語メタデータを文字列に適用するために、 関連する文書属性または API を使用してください。
表示（フォント選択など）またはテキスト処理（ハイフネーションなど）で最良の結果を得るには、
挿入されたテキストの言語を、文書内またはテキストを扱う API 内で設定するべきです。
[HTML]
では、これは lang 属性を設定することで行います。
[XML] では、
これは xml:lang 属性を設定することで行います。
消費者は、相互運用性を確保するために、言語タグを正規化してもよいです （MAY）。
たとえば、多くの実装は、[CLDR] の 言語タグ 変換に見られる正規化を使用します。この正規化は、特に、廃止されたサブタグを置換し、変種をアルファベット順に並べます。
生成者でもある消費者は、言語メタデータおよび方向メタデータを下流の消費者へ渡すよう注意するべきです （SHOULD）。
それを使用する文書形式については、[JSON-LD] は、（リソース全体を含む）文字列のコレクションに
言語メタデータ（ただし段落方向ではない）を割り当てるのに役立つデータ構造をいくつか含んでいます。特に、
これはコンテキストスコープの @language 値という形で
「文字列の国際化」と呼ぶものを定義しており、JSON のブロックまたは個々のオブジェクト内に関連付けることができます。
基底方向の定義はないため、@context 仕組みは現在のところ、
この文書で提起されるすべての懸念に対応しているわけではありません。
i18n 名前空間が利用できない場合、または
使用することが不適切な場合、仕様は、自然言語値について [JSON-LD] のプレーン文字列リテラルが文字列固有の言語情報を
提供するよう要求するべきです（SHOULD）。
[RDF-PLAIN-LITERAL] など、言語メタデータを文字列値の一部として直列化できるデータ型がすでに存在します。
ローカライズ可能なテキストではない
文字列値および文字列フィールドについて、仕様は、そのフィールドが本質的に非言語的であることを指定し、
言語タグ zxx（「言語内容なし」）を各文字列値に関連付けることを
推奨するべきです（SHOULD）。
ローカライズ可能なテキストを
含むことが知られているが、基礎となる形式から言語メタデータを得る可能性がない文字列値および文字列フィールドについて、
仕様は、内容の言語が不明であることを指定し、言語タグ und
（「未確定」）を各文字列に関連付けることを推奨するべきです（SHOULD）。仕様は、適切であり最後の手段として、ヒューリスティックの使用または
他のフィールド値からの言語の推論を許可してもよいです（MAY）。
多くのプロトコルまたは形式は、自然言語テキストとして意図されていない一方で、人間が判読できることを 意図した値を使用します。これにより、人々はデバッグに使用するなど、その値を利用できます。 これには、人間が値を表示し操作することを期待する一般的なプロトコル要素が含まれ得ます。
これらの一般的な例には、ドメイン名やメールアドレスが含まれます。この種の値空間で Unicode が より広く利用可能になると、これらの値の表示はシステムや環境によって異なる可能性があります。たとえば、 言語によって異なり得るフォント選択は、既定のロケールが異なるシステムでは異なる場合があります。
一部の仕様は、既存のプロトコルまたは形式によって定義された文字列値と相互作用します。多くの場合、これらの文字列は 言語メタデータまたは方向メタデータと関連付けられていないか、それらを提供しません。たとえば、多くの HTTP ヘッダーは、 その内容が自然言語テキストであることを期待されている場合でも、その内容をローカライズ可能なテキストではないかのように 定義します。これらの文字列値の消費者または生成者として動作する仕様には、 言語メタデータまたは方向メタデータが何であるかを発見する方法がなく、そのようなメタデータを添付する仕組みもありません。
仕様は、言語識別のために Unicode の「言語タグ」文字（コードポイント
U+E0000 から U+E007F）を使用するべきではありません
（SHOULD NOT）。
[Unicode] は、... 言語タグを伝達するためのタグ文字の使用は
強く推奨されない
と述べ、文字 U+E0001 LANGUAGE TAG の使用は強く推奨されないと述べています。
仕様は、対になる bidi 制御の生成または使用を要求してはなりません （MUST NOT）。
別の言い方をすると、実装に対して、通過するデータを変更することを要求してはならない ということです。Unicode bidi 制御文字は、特定の文字列内容の中に見つかることがあります。そこでは、 生成者またはデータソースが、テキストを適切に表示させるためにそれらを使用していた可能性があります。つまり、 それらはすでにデータの一部である可能性があります。実装は見つけた制御を乱すべきではありませんが、 自ら追加の制御を生成することを要求されるべきではありません。
仕様は、同じ値について複数の言語で
Localizable
文字列を提供できる場合、言語インデックス付けの使用を推奨するべきです
（SHOULD）。
生成者は、同じ内容項目または データレコードについて、複数の言語値を提供する必要があることがあります（ローカライゼーションに関する考慮事項を参照）。 これの用途の 1 つは、消費者による 言語ネゴシエーションです。
Web における bidi および言語メタデータのユースケースの記事を読んでください。そこには、 波及やロケールベースの レンダリングなどの問題を明確に示した、詳細なユースケースが含まれています。この節では、その文書の主要な点と、 言語メタデータおよび方向メタデータの必要性に関係する点を要約します。
内容の言語に関する情報は、さまざまな理由から、ローカライズ可能なテキストを 処理および提示する際に重要です。言語情報が存在しない場合、外観や機能の劣化によって、 ユーザーが苛立ったり、内容が理解不能になったり、重要な機能が無効になったりする可能性があります。 影響を受ける処理には、次のようなものがあります。
同様に、方向メタデータは Web にとって重要です。文字列が右から左（RTL）に進む用字のテキストを含む場合、 その文字列が最終ユーザーに届いたときに正しく表示できる必要があります。そのためには、文字列全体に適用する必要がある 文字列方向が 何であるかを確立する必要があります。適切な文字列 方向は、単に文字列を見るだけでは常に推定できるとは限りません。可能な場合であっても、 文字列の生成者と消費者は、方向を解釈するために同じヒューリスティックを使用する必要があります。
Web ページの本文や電子書籍の内容などの静的な内容には、多くの場合、文書形式によって、または 内容メタデータの一部として、言語または方向の情報が提供されます。Web 上に見られるデータ形式は、 一般にこのメタデータを提供しません。Microformats、WebIDL、JSON などの基本仕様は、 追加のメタデータなしで、自然言語テキストを文字列オブジェクトに保存する傾向がありました。
これは、アプリケーション作者およびデータ形式設計者に、自らの主導でメタデータを提供する負担を課します。 標準化された形式が結果として生じる問題に対処しない場合、データ自体は完全な状態で届いても、 その処理または提示を完全には回復できないという結果になり得ます。
分散した Web では、任意の消費者が、他の処理またはシステムに対する 生成者にもなり得ます。 したがって、ある消費者は、1 つの文書形式（および 1 つの直列化に関する合意）から、異なる文書形式を使用する別の消費者へ、 言語メタデータおよび方向メタデータを渡す必要があるかもしれません。直列化に関する合意において言語メタデータおよび 方向メタデータの表現に一貫性がないことは、相互運用性への脅威であり、一貫した実装への障壁となります。
顧客の電子書籍ライブラリを表示する Web ページを構築しているとします。電子書籍はデータのカタログ内に存在し、 通常のデータ値で構成されています。単一の項目に対する JSON ファイルは、次のように見えるかもしれません。
{
"id": "978-111887164-5",
"title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
"authors": [ "Jon Duckett" ],
"language": "ar",
"pubDate": "2008-01-01",
"publisher": "مكتبة",
"coverImage": "https://example.com/images/html_and_css_cover.jpg",
// など。
},上記の各項目は、どこかのデータベース内のデータフィールドです。本がどの言語で書かれているかについての情報 （"language": "ar"）さえあります。
十分に国際化されたカタログであれば、上に示したものに加えて追加のメタデータを含むでしょう。すなわち、 title や authors フィールドなど、ローカライズ可能なテキストを含む 各フィールドについて、言語および文字列方向の情報がメタデータとして保存されるべきです。 （東アジア言語情報のソートのための発音メタデータなど、他の値もあり得ます。） これらのメタデータ値は、データの消費者によって、処理に影響を与え、さまざまな方法で項目の表示を可能にするために 使用されます。JSON データ構造にはこれらの値を保存または交換する場所がないため、国際化されたアプリケーションを 構築することがより困難になります。
1 つの回避策は、HTML と Unicode bidi 制御を混ぜて値を符号化し、データ値が次のいずれかのように見えるように することかもしれません。
// 次の例は推奨されません
// HTML マークアップを含む
"title": "<span lang='ar' dir='rtl'>HTML و CSS: تصميم و إنشاء مواقع الويب</span>",
// 最初の文字として LRM を含む
"authors": [ "\u200eJon Duckett" ],しかし、JSON はデータ交換形式です。内容は、title フィールドが HTML コンテキストで表示される形で終わるとは 限りません。上記の JSON は、たとえば、ネイティブコントロールを使用してタイトルを表示するローカルデータストアを 埋めるために使用される可能性が十分にあり、その場合、これらのコントロールは HTML を文字列内容として扱います。 データの生成者および消費者は、追加データを提供または削除したり、それをメタデータとして公開したりするために、 データを内省することを期待していないかもしれません。ほとんどの JSON ライブラリは、直列化している内容の構造について 何も知りません。生成者は、データベースなどのローカルデータストアから JSON ファイルを直接生成したいと考えます。 消費者は、各文字列の内容について追加の考慮をせずに、値を保存または取得して使用したいと考えます。さらに、 生成者または消費者のいずれかには、追加の制御やマークアップの挿入によって影響を受けるフィールド長制限など、 他の考慮事項がある場合があります。これらの各考慮事項は、必要なメタデータを直列化、逆直列化、管理、および 交換するための任意の手段を実装者が作成することに特別な負担を課し、その過程で相互運用性が犠牲になります。
（余談ですが、上の例に示したマークアップは、タイトルと挿入されたマークアップの両方をブラウザーで正しく表示させるために 実際に必要であることに注意してください。）
[Unicode] とその文字符号化（UTF-8 など）は、 Web とその形式の重要な要素です。それらは、インターネット全体で一貫して任意の言語のテキストを符号化し交換する能力を 提供します。しかし、Unicode 自体は完全な交換を保証するものの、自然言語テキストの 完全な提示と処理を保証するものではありません。
Unicode のいくつかの機能は、言語メタデータおよび方向メタデータを提供するための解決策の一部として
提案されることがあります。具体的には、方向メタデータの扱いに Unicode bidi 制御が提案されます。
さらに、Unicode の U+E0000 ブロックには、もともと言語タグとしての
使用を意図した「タグ」文字があります（ただし、この使用は現在では非推奨です）。
交換形式のデータに文字を追加することが良い考えではない理由は、さまざまにあります。これには次が含まれます。
この最後の考慮事項は、特に取り上げることが重要です。文書形式は、多くの場合、複数のコード層を使って構築され、 直列化されます。汎用 JSON ライブラリなどのライブラリは、渡されたデータを忠実に保存し取得することを期待されています。 より高レベルの実装も、通常、渡された値の忠実な直列化および逆直列化を重視します。データ自体を変更する任意の処理は、 望ましくない変動性を導入します。たとえば、文書から返された文字列が、その文書を生成するために使用された データカタログ内の文字列と同一かどうかを確認するアプリケーションの単体テストを考えてください。bidi 制御、 HTML マークアップ、または Unicode 言語タグが挿入、削除、または変更されている場合、本来同じであることが 期待されていても、文字列は等しいものとして比較されない可能性があります。
双方向テキストのユースケースを考えると、消費者は、追加の作業や準備なしに単に文字列を 目的の位置に挿入することはできないことが明らかです。まず挿入される文字列に適した 文字列方向を確立し、次にその文字列の周囲に bidi 分離を 適用する必要があります。
これには、文字列の周囲にマークアップまたは Unicode 書式制御が存在することが必要です。文字列の実際の方向が、 それが挿入される内容の方向と反対である場合、マークアップまたは制御コードはその文字列を密に包む必要があります。 互いに隣接して挿入される文字列はすべて、前の節で見た波及の問題を避けるために、個別に包む必要があります。
[HTML]
は、
dir 属性が使用される場合、または bdi
要素が使用される場合、任意のインライン要素に対して基底方向制御と分離を提供します。文字列をプレーンテキスト環境に
挿入する場合は、分離用の Unicode 書式文字を使用する必要があります。（残念ながら、Unicode 標準が
プレーンテキスト／非マークアップアプリケーションのデフォルトとして推奨している分離文字のサポートは、まだ普遍的ではありません。）
要点は、マークアップまたは制御文字によって提供される方向情報が、その文字列の 文字列方向を反映するようにすることです。
双方向テキスト値に関する根本的な問題は、文字列の消費者が、その文字列が最終的に ユーザーに表示されるときに、その文字列にどの文字列方向を使用すべきかを、どのように知るかです。 方向を識別または推定するためのこれらのアプローチの一部は、特定のアプリケーションでは有用であり、 [HTML] などの さまざまな仕様で使用されていることに注意してください。ここでの問題は、どれが一般的に採用するのに適しており、 文書形式におけるベストプラクティスとして使用を指定するのに適しているかです。
このアプローチを単独で使用することは推奨されませんが、他のアプローチと組み合わせたフォールバックとしては 推奨されます。
生成者は何もする必要がありません。
文字列はそのまま保存されます。
消費者は、文字列内で強い Unicode 方向プロパティを持つ最初の文字を探し、 文字列方向をそれに合わせて設定しなければなりません。 その後、文字列が必要なとおりに表示されるよう、適切な処置を取ります。これは見かけほど単純ではありません。 理由は次のとおりです。
First-strong 検出が必要なのは、必要な文字列 方向がまだ分かっていない場合だけです。文字列固有またはリソース全体の宣言によるメタデータで、 ある文字列の方向が示されている場合、first-strong ヒューリスティックを呼び出すべきではありません。 たとえば、first-strong ヒューリスティックは、 "HTML و CSS: تصميم و إنشاء مواقع الويب" のような文字列に対して 誤った結果を生成します。これはメタデータを使用することで修正できます。メタデータの使用は、十分に理解した上での 意図を表すものであり、その後に結果を誤らせるヒューリスティックを適用する必要も望みもありません。
しかし、メタデータを適用する仕組みがない場合、またはそのような仕組みはあるがコンテンツ開発者が
それを使用しなかった場合には、first-strong ヒューリスティックは、多くの場合（ただしすべての場合ではありません）、
基底
方向を確立するのに役立ちます。強い方向性を持つ書式文字の適用は、先ほど引用した例のような
プレーンテキスト文字列について正しい結果を生む助けになりますが、それらを常に適用できるわけではありません
（4.3 RLM/LRM
マーカーを挿入することによる first-strong
の補強を参照）。
信頼できる場合には、文字列に変更を加えることなく、またアウトオブバンドのメタデータをサポートするために 必要となる合意や構造なしに、方向に関する情報を取得できます。
このアプローチの主な問題は、次の場合に誤った結果を生成することです。
span などのマークアップで始まる文字列。最初の強い文字は常に LTR になるためです。文字列全体が RLI/LRI/FSI...PDI 書式文字で開始および終了する場合、Unicode 双方向アルゴリズムに従って 最初の強い文字を検出することはできません。これは、そのアルゴリズムが bidi 分離されたテキストを検出から 除外することを要求するためです。
文字列内に強い方向性を持つ文字が見つからない場合、方向はおそらく LTR と仮定されるべきであり、 消費者はそれに基づいて行動するべきです。ただし、これはまだ十分にテストされていません。
文字列に、消費者によってマークアップとして解析されるマークアップが含まれている場合、追加の問題があります。 文字列の先頭にあるそのようなマークアップも、最初の強い方向性を持つ文字を探す際にスキップしなければなりません。
文字列内の解析可能なマークアップが、文字列の意図された方向についての情報
（たとえば、HTML における値 rtl
を持つ dir 属性）を含む場合、
first-strong ヒューリスティックに依存するのではなく、その情報を使用するべきです。これはいくつかの点で問題があります。
(a) 文字列の消費者がマークアップの意味論を理解していると仮定します。すべての当事者の間で、たとえば
HTML マークアップだけを使用するという合意があるなら問題ないかもしれませんが、たとえばランダムな XML 語彙を
扱う場合には問題になります。(b) 消費者は、文字列の初期部分だけがマークアップを持つ状況、
すなわちマークアップが文字列全体ではなくインラインのテキスト範囲に適用される状況を認識して処理できなければなりません。
次の段落にある壊れたリンクの例がどこにあるのか、または以前どこにあったのかは明確ではありません。
しかし、山括弧の内容が実際のマークアップではなく、マークアップの例として意図されている場合、 そのマークアップをスキップしてはなりません。RTL コンテキストでマークアップのソースコードを表示しようとすると、 非常に混乱した結果になります。ただし、文字列の消費者が、例と解析可能な文字列の違いを常にどのように知るのかは 明確ではありません。
first-strong 検出は Unicode 双方向アルゴリズム（UBA）[UAX9] で概説されていますが、 文字列方向を推定するために言及されている唯一の高水準プロトコルではありません。たとえば、X（旧 Twitter）と Facebook は現在、テキストの基底方向を推測するために異なるデフォルトヒューリスティックを使用しています。 どちらも単純な first-strong 検出だけを使用しておらず、一方はまったく異なる方法を使用しています。
このアプローチは推奨されます。
ここで「メタデータ」とは、データ形式内の特定の文字列または文字列集合に関連付けられたフィールドベースの情報、 または文字列データ型に組み込まれた情報を意味します（4.7 新しい bidi データ型を作成するも参照）。
例は次のようになります。
{
"title": "HTML و CSS: تصميم و إنشاء مواقع الويب",
"direction": "rtl",
"language": "ar",
},リソース内のすべての文字列についてデフォルト方向を示すメタデータも、適切なフィールドを使用して設定できます。
生成者は文字列の文字列方向を確認し、 その文字列が保存または送信される際に、それに付随するメタデータフィールドへそれを追加します。
メタデータを使用するには、いくつかのアプローチがあります。
auto が使用されます。文字列集合をまとめて保存または送信する場合、リソース全体についてグローバルなデフォルトの 文字列方向を設定するフィールドがあると 役立ちます。そのリソース内のすべての文字列はそれを継承できます。グローバルフィールドに加えて、 ある文字列の文字列方向がデフォルト値と同じでない場合には、 文字列固有のメタデータフィールドを付加できる可能性が依然として必要であることに注意してください。 個々の文字列に設定された文字列方向は、常にデフォルトを上書きしなければなりません。
消費者は、文字列とともに送られたメタデータの読み取り方を理解する必要があり、メタデータがない場合には first-strong ヒューリスティックを適用する必要があります。
JSON ベースの文書形式における個々の値には、Localizable 辞書構造の使用が推奨されます。これは言語メタデータと方向メタデータの両方を 組み合わせるものであり、一貫して採用されれば、異なる形式間の交換を容易にします。
メタデータを文字列とは別個のデータ値として渡すことは、文字列の実際の内容に影響を与えることなく、 意図された文字列 方向を伝達する、単純で効果的かつ効率的な方法を提供します。
すべての文字列に方向のラベルが付けられている場合、またはすべての文字列の方向をグローバル設定と 任意の文字列固有の逸脱を適用して確認できる場合、各個別の文字列の文字列 方向を決定するために検査やヒューリスティックの実行を行う必要がなくなります。
アウトオブバンド情報は文字列に関連付けられ、文字列とともに保持される必要があります。これは、定義された枠組みの一部ではない 一部の文字列データ集合にとって問題となる可能性があります。
特に、JSON-LD は、言語の場合と同じ方法で方向を個々の文字列に関連付けることを許可していません。
このアプローチは、すべての状況で実行可能なわけではありません。
生成者は文字列の文字列方向を確認し、 文字列の先頭にマーカー文字（U+200F RIGHT-TO-LEFT MARK（RLM）または U+200E LEFT-TO-RIGHT MARK（LRM）のいずれか）を追加します。 このマーカーは機能的なものではありません。すなわち、消費者が使用できる基底方向を文字列に自動的に適用するわけではなく、 単なるマーカーです。
いくつかの可能なアプローチがあります。
消費者は first-strong ヒューリスティックを適用して、文字列の文字列 方向を検出します。RLM および LRM 文字は方向的に強い型を持つため、適切な基底方向の検出につながるはずです。
4.1 First-strong プロパティ検出で説明したように、 方向情報がメタデータによって提供されている場合、このアプローチは関係ありません。
生成者がマーカーを確実に適用できる限り、基底方向を示す信頼できる方法を提供します。
理論上は、正しい RLM/LRM が文字列の先頭に付加されている限り、マークアップで始まる文字列で 最初の強い文字を見つけやすくなるはずです。
生成者が人間である場合、方向性を示すために、理論上は文字列作成時にこれらの文字の 1 つを 適用できます。
特にモバイルデバイスでは、RLM/LRM 文字の入力が可能かどうか、または入力が不便であることが、 これに関する重大な問題です。モバイルデバイスのキーボードは通常、RLM/LRM 文字用のキーを提供していません。 さらに重要なのは、文字が不可視であり、Unicode bidi が複雑であるため、ユーザーがその文字を効果的に 使う方法を知ることが難しい場合があることです。実際、多くのユーザーは、これらの文字が何であるか、 何をするものかを実際には知りません。
さらに、たとえば RTL ページの HTML フォームにユーザーが情報を入力したり、ショートカットキーを使用して
フォームフィールドの方向を設定したりする場合、RLM/LRM を追加しなくても文字列は正しく見えます。しかし、
そのコンテキストの外で使用されると、必要なブロック
方向に関する情報と関連付けられていない限り、その文字列は正しく見えません。同様に、
html 要素に dir=rtl
が設定された Web ページからスクレイピングされた文字列は、HTML 内では通常、
文字列の先頭に RLM/LRM 文字を持たないか、必要としません。
生成者が使用する手順に、文字列の元のコンテキストを方向情報について調べること （たとえば、HTML フォームフィールドの算出方向をテストすること）と、その後必要に応じて 文字列の先頭に RLM/LRM マークを自動挿入することを含めることは可能かもしれません。このアプローチの課題は、 文字列の値と同一性を変更することです。これは、特に一部の生成者がマーカーを追加し、他の生成者が追加しない場合、 文字列長やポインター位置を扱う際にも問題を生じさせる可能性があります。
方向情報が、消費者によってそのように解析されるマークアップ内に含まれている場合（たとえば HTML の
dir=rtl）、文字列の生成者は、そのマークアップを理解し、
適切に RLM/LRM 文字を設定するか設定しないかを判断する必要があります。生成者がそのような文字列の先頭に
常に RLM/LRM を追加する場合、消費者はそのことを知っていることが期待されます。生成者が代わりに
マークアップが理解されることに依存する場合、消費者はそのマークアップを理解していることが期待されます。
文字列の生成者は、文字列の先頭に RLM または LRM を自動的に適用するべきではなく、それが必要かどうかを テストするべきです。たとえば、テキスト内にすでに RLM がある場合、もう 1 つ追加する必要はありません。 コンテキストが first-strong ヒューリスティックによって正しく伝達される場合にも、追加の文字を加える必要はありません。 ただし、この種の補足的な方向情報が必要かどうかをテストできるのは、生成者が文字列の元のコンテキストに アクセスでき、かつアクセスできることを知っている場合だけであることに注意してください。多くの文書形式は、 元のコンテキストから離れて保存されたデータから生成されます。たとえば、上の元の例における本のカタログは、双方向テキストを入力したユーザーから切り離されています。
このアプローチは推奨されません。
生成者は文字列の文字列方向を確認し、 方向書式文字（U+2066 LEFT-TO-RIGHT ISOLATE（LRI）、U+2067 RIGHT-TO-LEFT ISOLATE（RLI）、 U+2068 FIRST STRONG ISOLATE（FSI）、 U+202A LEFT-TO-RIGHT EMBEDDING（LRE）、または U+202B RIGHT-TO-LEFT EMBEDDING（RLE）のいずれか）を文字列の先頭に追加し、U+2069 POP DIRECTIONAL ISOLATE（PDI）または U+202C POP DIRECTIONAL FORMATTING（PDF）を末尾に追加します。
いくつかの可能なアプローチがあります。
消費者は理論上、表示される位置に文字列を挿入するだけで、方向性の管理をそれらの書式コードに依存できます。 しかし、物事はそれほど単純ではありません（下記参照）。
対になる書式文字には 2 種類があります。元の制御セットは、Unicode 双方向アルゴリズムに追加の双方向 「埋め込み」レベルを加える能力を提供します。より最近、Unicode は補完的な「分離」制御セットを追加しました。 分離制御は文字列を囲むために使用されます。文字列の内部は独自の双方向シーケンスとして扱われ、 文字列は周囲のテキストに関連する波及効果から保護されます。囲んでいる文字列は、囲まれた文字列全体を、 bidi 並べ替えでは無視される単一単位として扱います。この問題はここで説明されています。
| コードポイント | 略称 | 説明 | コードポイント | 略称 | 説明 |
| U+200A | LRE | 左から右への埋め込み | U+2066 | LRI | 左から右への分離 |
| U+200B | RLE | 右から左への埋め込み | U+2067 | RLI | 右から左への分離 |
| U+2068 | FSI | First Strong 分離 | |||
| U+200C | 方向書式のポップ（埋め込みの終了） | U+2069 | PDI | 方向分離のポップ（分離の終了） |
対になる書式文字を使用する場合、それらは分離用であるべきです。すなわち、RLE や LRE ではなく、 RLI、LRI、FSI で始めるべきです。
このアプローチを使用することに実質的な利点はありません。
このアプローチは、文字列の値を変更することが許容される場合にのみ適切です。文字列長やポインター位置が 変わる可能性といった問題に加えて、このアプローチには、処理エラーやテキストの切り詰めなどにより、 対になる文字の一方が失われるという現実的で重大なリスクがあります。
文字列の生成者と消費者は、文字列が対になる書式文字で始まるが、それで終わらない状況を認識して 処理する必要があります。これは、その書式文字が文字列の一部だけを記述しているためです。
Unicode は、有効な埋め込み数に制限を指定しており、埋め込みが時間とともに積み重なって その制限を超える可能性があります。
消費アプリケーションは、分離書式文字を認識し、適切に処理する必要があります。現時点では、 RLI/LRI/FSI に対するそのようなサポートは、広く普及しているとは言えません。
このアプローチは、認識していない消費者によって使用された場合、 その文字列を UBA の first-strong ヒューリスティックに適したものではなくします。Unicode bidi アルゴリズムは、 RLI/LRI/FSI で始まり PDI で終わる文字列について基底方向を確認できないためです。これは、 アルゴリズムが分離シーケンスをスキップし、それらを中立文字として扱うためです。文字列の消費者は、そのような場合、 最初の強い文字を見つけるために特別な手順を取らなければなりません。
このアプローチは、メタデータの使用を妨げる状況に対する回避策としてのみ推奨されます。
生成者は、文字列に 言語メタデータを提供し、必要に応じて使用中の用字系を指定します。
いくつかの可能なアプローチがあります。
消費者は、 各文字列に関連付けられた言語タグから用字系サブタグを抽出し、必要に応じて文字列の文字列方向を計算します。RTL 用字系に関連付けられた用字系サブタグは、 その関連付けられた文字列に RTL の方向を割り当てるために使用されます。
言語情報は [BCP47] 言語タグを使用しなければなりません
（MUST）。情報を担う言語タグの部分は、主要言語サブタグではなく用字系サブタグです。
たとえば、アゼルバイジャン語は LTR（ラテン文字またはキリル文字）でも RTL（アラビア文字）でも書かれ得ます。
したがって、サブタグ az は、意図された
ブロック方向を明確にするには不十分です。しかし、
az-Arab（アラビア文字で書かれたアゼルバイジャン語）のような言語タグは、一般に
ブロック方向が RTL であるべきことを
示すものとして信頼できます。
文字列自体を検査または変更する必要はありません。
このアプローチは、最初の強い文字が文字列に必要な文字列 方向を示していない場合に first-strong 検出に関連して生じる課題を回避し、マークアップの解釈に関する課題も 回避します。
文字列テキスト内容の言語を設定するマークアップ（例：
<cite lang="zh-Hans">）で始まる文字列は、ここでは問題にならないことに
注意してください。その言語宣言は、文字列方向の設定に関与することが期待されないためです。
上で概説したメタデータの使用は、利用可能であれば、はるかに優れたアプローチです。この用字系関連のアプローチは、 レガシー上の理由により、そのアプローチが利用できない場合にのみ使用するものです。
言語固有ではないものの、正しく消費されるためには特定のブロック方向と関連付けることが
絶対に必要な文字列は数多くあります。たとえば、RTL コンテキストに挿入される MAC アドレスは、全体として LTR の
基底方向で表示され、周囲のテキストからも分離される必要があります。これらの場合を他の場合から
（方向メタデータを使用するときに実現可能な方法で）どのように区別するかは明確ではありません。
zxx（非言語）などの特別な言語タグは、この種の内容を識別するために存在しますが、
通常、この種のデータフィールドは言語情報をまったく省略します。適用できないためです。
用字系サブタグの一覧は将来追加される可能性があります。その場合、デフォルトの RTL 方向を示すサブタグは、 文字列の消費者が使用する一覧に追加される必要があります。
適切な段落 方向を用字系サブタグから識別できないまれな状況がありますが、実際には古風なテキスト使用に限られます。 たとえば、第二次世界大戦以前の日本語および中国語のテキストは、LTR ではなく RTL で書かれることがよくありました。 エジプト象形文字やティフィナグ・ベルベル文字を使用して書かれる言語などは、以前は LTR と RTL のどちらでも 書かれ得ましたが、学術研究でのデフォルトは LTR に傾く傾向があります。
ここで概説したアプローチは、文字列に関連付けられる全体的な 文字列方向に関する情報を宣言する場合にのみ適切です。 文字列内のテキスト方向を示すために言語データを使用することは推奨しません。 使用パターンが互換的ではないためです。
このアプローチは、HTML または XML マークアップデータだけを排他的に交換することを期待する 直列化に関する合意の下を除き、 推奨されません。
生成者は、すべての文字列が、その文字列に適した基底方向を示すマークアップで開始および終了することを保証します。
これには、生成者が文字列を調べる必要があります。文字列が方向情報を持つマークアップで囲まれていない場合、
生成者は、dir または its:direction [ITS20]
属性を持つ要素、または特定の XML アプリケーションに適したその他のマークアップで文字列を包む必要があります。
文字列がマークアップで囲まれているが、それが HTML の h1
要素などである場合、生成者は単に span で文字列を囲むのではなく、
既存のマークアップに方向情報を導入する必要があります。
この例では HTML マークアップを使用しています。（単に例を読みやすくするため、文字が保存されている順序ではなく、 表示されるべき順序で文字列のテキスト内容を示しています。）
消費者は、文字列が表示される際に、そのテキスト内容の周囲で基底方向を設定することをマークアップに依存します。 （追加のメタデータが提供されていない限り、消費者は対象位置に文字列を統合する前にマークアップを削除できないことに 注意してください。どのマークアップが生成者によって追加されたもので、どれがすでに存在していたものかを判別できないためです。 ただし一般に、そのように追加されたマークアップは無害です。）
すでにマークアップを使用している内容にとっての利点は明白です。内容は、テキストの表示および処理に必要な完全な マークアップをすでに提供しているか、ソースページのコンテキストから抽出できます。HTML および XML プロセッサーは すでにこのマークアップの扱い方を知っており、すぐに検証できます。
HTML では、dir 属性が内容を周囲のテキストから双方向的に分離し、
波及の衝突を取り除きます。これにより、消費者の作業が減ります。
マークアップは、文字列内部の方向情報にも使用できます。これは、文字列方向だけでは解決できないことです。
実質的には、実装スタックのすべてのレベルが、マークアップを理解することに参加しなければなりません （または害を及ぼさないことを保証しなければなりません）。
システムがエンドツーエンドで HTML を使用している場合、適切なマークアップが利用可能であり、その意味論も理解されています
（すなわち、dir 属性、ならびに bdi および
bdo 要素）。
しかし XML アプリケーションでは、bidi サポートのための標準マークアップはありません。そのようなマークアップは、
まず定義され、その後、生成者と消費者の両方によって理解される必要があります。
このアプローチの主な欠点は、多くのデータ値が単なる文字列であることです。Unicode タグや Unicode bidi 制御を 追加する場合と同様に、文字列にマークアップを追加すると元の文字列内容が変わります。内容の長さを変更することは、 任意の制限を強制する処理や、山括弧などの HTML/XML 非安全文字をエスケープして内容を「サニタイズ」する処理に 問題を引き起こす可能性があります。
もう 1 つの課題は、文字列を調べ、必要に応じてマークアップを追加するために生成者に求められる作業と高度さです。
Unicode 双方向アルゴリズムによって許可される埋め込み数には制限があります。消費者は、文字列をより広い コンテキストに埋め込む際に、この制限を超えないことを保証する必要があります。
マークアップの追加は、XSS 攻撃など、マークアップ挿入に伴う通常の問題から守ることも消費者に要求します。
このアプローチは [JSON-LD] 1.1 に追加されました。
これは、前に説明した文字列とともにメタデータを送信するという考えに似ていますが、メタデータは
（4.2
メタデータのように）完全に別個のフィールドに保存されるのでも、
（4.3 RLM/LRM マーカーを挿入することによる
first-strong
の補強のように）文字列自体に挿入されるのでもなく、
文字列の直列化形式の一部として文字列に関連付けられます。
[RDF-PLAIN-LITERAL] など、言語メタデータを文字列値の一部として直列化できるデータ型はすでに存在します。 しかし、これらは方向に関する考慮を含んでいません。これは、文書形式が言語メタデータと方向メタデータの両方を 含む自然言語文字列を直列化するために使用できる新しいデータ型を定義する（または既存のものを拡張する）ことで 対処できるかもしれません。
[JSON-LD] 1.1 は、JSON 文書が言語メタデータおよび
方向メタデータを文字列値とともに直接直列化できるようにするため、i18n
名前空間を追加しました。これは、それを必要とする仕様に対して RDF への
逆直列化を提供します。
最後の文字列は内部データ値であるため言語情報を含みませんが、この種の文字列は LTR 順で提示されなければならない ため、方向情報は含むことに注意してください。
生成者は、必要に応じて 各文字列に文字列方向を付加する必要があります。
各消費者は、 このアプローチを使用しない、または文字列方向を含まない文字列について、 first-strong ヒューリスティックを使用するべきです。その場合、 生成者は、first-strong アプローチでは 誤った結果が生じる場合にだけ文字列方向情報を追加することになります。これは、メタデータを必要とする 文字列の数が比較的少ないため、文字列の管理と送信するデータ量を単純化するかもしれません。
消費者は、 文字列に関連付けられたメタデータがあるかどうかを確認し、ある場合は示された文字列方向を設定します。そうでない場合は、first-strong ヒューリスティックを使用してその文字列の文字列方向を決定します。
自然言語文字列をサポートするための新しいデータ型が JSON に追加されたなら、仕様はその型を文書形式で使用するように 容易に指定できます。形式が標準化されているため、生成者と消費者は、 それが符号化されているときに方向または言語情報について推測する必要がありません。
これが現在機能しないという事実は別として、データ型を追加することの欠点は、JSON が多くのアドホック実装を含め、 広く実装された形式であることです。新しい直列化形式は、これらの既存実装を破壊したり、相互運用性の問題を 引き起こしたりする可能性が高いです。JSON は「バージョン付き」の形式として設計されていません。 使用される任意の直列化形式は、既存の JSON プロセッサーに対して透過的である必要があり、したがって既存の文字列や 形式に望ましくないデータまたはデータ破損を導入する可能性があります。
この節では、文字列値の言語を判定または伝達するためのさまざまな手段を扱います。
このアプローチは推奨されます。
生成者は 文字列の言語を確認し（通常は上流から提供されたメタデータから）、文字列が保存または送信されるときに それに付随するメタデータフィールドにこの情報を含めます。
文字列集合をまとめて保存または送信する場合、リソース全体について、そのリソース内のすべての文字列が 継承できる言語を設定するフィールドがあると役立ちます。グローバルフィールドに加えて、文字列の言語が デフォルトのものではない場合に、文字列固有のメタデータフィールドを付加できる可能性が依然として必要であることに 注意してください。個々の文字列に設定された言語は、任意のリソースレベルの値を上書きしなければなりません。
消費者は、 文字列に関連付けられたメタデータを読み取り、それを生成する表示、処理、またはデータ構造に 適用する方法を理解する必要があります。これには、個別の値を直列化または交換するときに、 リソースレベルのデフォルト言語を適用する必要が含まれる可能性があることに注意してください。
一貫性があり明確に定義されたデータ構造を使用することで、異なる標準が合成可能であり、 シームレスに連携する可能性が高くなります。
メタデータは、内容自体に影響を与えることなく提供できます。
メタデータが利用できない場合は、省略できます。
消費者と生成者は、通常の処理の外でデータを内省する必要がありません。
辞書とそのデータ値を利用する直列化ファイルには追加のフィールドが含まれ、その結果として 読みにくくなる可能性があります。
既存の文書形式については、交換される値への変更を表します。
このアプローチは推奨されません。ただし、交換される内容が、特定のマークアップ言語における リテラル値から成ることが期待され、かつそれに制限されている特別な場合を除きます。
文書が HTML または XML 断片から成ることが期待され、厳密にマークアップコンテキストで処理および表示される場合、
生成者は、
lang または xml:lang
属性を持つ
要素で文字列を包むことにより、マークアップを使用して内容の言語を伝達できます。
このアプローチ、したがってその利点は、実質的にこの 節と同じです。
上記を参照してください。
このアプローチは推奨されません。
生成者は、 文字列に言語をタグ付けするために、Unicode タグ文字をデータに挿入します。
消費者は、 Unicode タグ文字を処理し、それらを使用して言語を割り当てます。
Unicode は、言語タグとして使用できる特殊文字を定義しています。これらの文字は「デフォルトで無視可能」であり、 視覚的な外観を持たないはずです。Unicode タグは次のように機能することが想定されています。
各タグは文字シーケンスです。シーケンスはタグ識別文字で始まります。現在定義されている唯一のものは
U+E0001 で、これは [BCP47] 言語タグを識別します。私的な合意により、
他の種類のタグも可能です。タグを形成するための Unicode ブロックの残りは、表示可能な ASCII 文字を
ミラーします。すなわち、U+E0020 はスペース（U+0020 をミラー）であり、
U+E0041 は大文字 A（U+0041 をミラー）であり、以下同様です。
タグ識別文字に続いて、生成者は各タグ文字を使用し、大文字／小文字、数字、およびハイフン文字を使って
[BCP47] 言語タグを綴ります。
ASCII 文字、数字、ハイフンから構成される所与の元言語タグは、各文字のコードポイントに
0xE0000 を加えることでタグへ変換できます。言語優先順位リスト（[RFC4647] を参照）などの追加構造は、
コンマやセミコロンなどの他の文字を使用して構築できるかもしれませんが、Unicode はこれを定義しておらず、
必ずしも許可しているわけでもありません。
タグのスコープの終わりは、文字列の終わりによって示されるか、キャンセルタグ文字 U+E007F を使用して
明示的に示すことができます。これは単独で（すべてのタグをキャンセルするために）使用するか、
言語タグ識別文字 U+E0001 の前に置いて（すなわち、言語タグだけを終了するための
シーケンス <U+E0001,U+E007F> として）使用します。
したがって、タグは最低 3 文字を持ち、容易に 12 文字以上になる可能性があります。さらに、これらの文字は
補助文字です。すなわち、UTF-8 では 1 文字あたり 4 バイトを使用して符号化され、UTF-16 ではサロゲートペア
（2 つの 16 ビットコード単位）として符号化されます。Java や JavaScript など、内部で UTF-16 を使用する
言語の文字列型でこれらの文字を符号化するには、サロゲートペアが必要です。サロゲートの使用により、
文字列はいくぶん不透明になります。たとえば、U+E0020 は UTF-16 では
0xDB40.DC20 として、UTF-8 ではバイトシーケンス
0xF3.A0.80.A0 として符号化されます。
これらの言語タグ文字は、文書形式の構造を変更することなく、通常の Unicode テキストの一部として使用できます。
言語識別のために Unicode タグ文字を使用することは、Unicode Consortium によって強く推奨されていません （したがって非推奨です）。これらのタグ文字は、プレーンテキストコンテキスト内での言語タグ付けに使用することを 意図しており、インバンドの非マークアップ言語タグ付けを提供する代替手段としてしばしば提案されます。 私たちは、これらを言語タグとして使用する実装を認識していません。
これらの文字を未知の Unicode 文字として扱うアプリケーションは、それらを豆腐（中空の箱の置換文字）として表示し、 長さ制限などに数える可能性があります。そのため、それらを完全に認識し、適切に削除または無視できる アプリケーションまたは交換機構でのみ有用です。これらの文字は表示されず、テキスト処理に影響を与えないことが 想定されていますが、実際には、切り詰め、改行、ハイフネーション、スペルチェックなどの通常のテキスト処理に 干渉する可能性があります。
設計上、[BCP47] 言語タグは ASCII の大文字小文字を 区別しないことが意図されています。Unicode タグ文字を扱うアプリケーションは、言語を正しく識別するために 同様の大文字小文字非依存性を適用しなければなりません。（Unicode データはこれらの文字について大文字小文字変換の 対応を指定していません。これは、タグ文字を使用して符号化された言語タグ値の処理および照合を複雑にします。）
さらに、言語タグは [BCP47] に準拠するために、 妥当なサブタグから形成される必要があります。妥当なサブタグは IANA レジストリで管理され、新しいサブタグは 定期的に追加されるため、この種のタグ付けを扱うアプリケーションは、常に各サブタグをレジストリの最新バージョンと 照合する必要があります。
言語タグ文字は、言語タグの入れ子を許可しません。たとえば、文字列が英語文の中にフランス語の引用を含むなど、 2 つの言語を含む場合、Unicode タグ文字は 1 つの言語がどこで始まるかしか示せません。入れ子の言語を示すには、 タグを先頭に付加するだけでなく、テキスト内に埋め込む必要があります。
実装されたことはありませんが、他の種類のタグも Unicode タグ文字を使用して文字列または文書に 埋め込むことができます。これらのタグが、言語タグでタグ付けされたテキスト部分と重なり合う可能性があります。
最後に、Unicode は最近、スコットランドの旗（🏴）などのサブリージョン旗を形成するために、 これらの文字を「再利用」しました。これは次のシーケンスで構成されます。
上記は、2017 年 6 月に Unicode 10.0（UTR#51 のバージョン 5.0）で追加された emoji の新機能です。 適切な表示は、このバージョンがシステムに採用されているかどうかに依存します。
このアプローチは推奨されません。
生成者は何もしません。
消費者は、 テキストの言語を判定するために言語検出アルゴリズムを実行します。これらは通常、ある言語における n-gram 頻度を使用するなどの統計ベースのヒューリスティックであり、場合によっては他のデータと組み合わせられます。
このアプローチには根本的な利点はありません。
ヒューリスティックは、走査されるテキストが長く、より代表的であるほど正確になります。短い文字列はうまく 検出できない場合があります。
言語検出は、検出器を持つ言語に限定されます。
別の言語または用字で書かれた個人名やブランド名などの混入は、検出を狂わせる可能性があります。
言語検出は遅くなりがちで、メモリを多く消費する場合があります。単純な消費者は、言語を判定するために必要な 複雑さを負担できない可能性があります。
ときには、生成者が、 生成者と 消費者の間で何らかの 言語 ネゴシエーションを行うことで、所与の内容項目またはデータレコードについてローカライズされた値を 提供できる場合があります。その場合、ローカライゼーションは、交渉された言語を使用して返す内容を選択する 生成者内で行われます。 このようなアプローチは、ファイルサイズを節約でき、これはレイテンシーと複雑さに影響します。なぜなら、 消費者が必要とする言語だけを返せばよいからです。
しかし、これは常に可能とは限らないため、仕様は、所与のフィールドについて複数の異なる言語値を返すことを 許可する場合があります。これは実行時ローカライゼーションをサポートするため、または 生成者が複数の 異なる言語値を持ち、それらを適切に事前選択できないためである可能性があります。
これらの場合、内容項目のローカライゼーションは、生成者がその項目について複数の言語表現を返し、 消費者に表示する値を選択させることで行われます。 このようなアプローチは、生成者が言語をネゴシエーションできない場合 （たとえば、結果のファイルが複数のユーザー向けにキャッシュされる場合）や、言語数が比較的少ない場合に有用です。 大規模な言語集合は、扱いにくい過度に大きな文書を生じさせる可能性があります。
言語
インデックス付けとは、言語タグを使用して、
所与のフィールドの異なる言語バージョンを整理し、消費者が最も適切な値を選択できるようにする
戦略です。仕様は、LanguageMap などのデータ構造を使用して、
所与のフィールドについて複数の言語バージョンを提供できます。所与のフィールドの値はマップとして定義されます。
マップ内のキーは言語タグです。各言語タグに関連付けられた値は
文字列、または理想的には LanguageEntry オブジェクトです。
マップ内の値へのキーとして言語タグを使用すると、
所与の要求に対して正しい値を迅速に選択できます。言語タグに関連付けられた値が
LanguageEntry である場合、言語が値の中で
繰り返される（または上書きされる）可能性があることに注意してください。値内の
LanguageTag は任意であるため、
これは必須ではありません。（価値を追加しない限り、含めないでください。）
たとえば、要求された言語が米国英語（en-US）であった場合、
この形式により、最も適合する title オブジェクト {"value": "Learning Web Design"}
を照合して抽出しやすくなります。
追加の潜在的な利点として、インデックス付けされた言語タグは、値の対象読者を実際のデータ値の言語タグとは別に
示すことができます。この例として、言語範囲
[RFC4647] の使用が考えられます。次の例のように、
より具体的な言語値が、より具体的でない言語タグで包まれる場合です。この例では、内容には具体的な言語タグ
（de-DE）が付けられていますが、de-CH や
de-AT など、
ドイツ語の他の変種を話すユーザーにも利用可能で適用可能です。
より一般的でない例として、実際の翻訳値が欠けているためなどに、インデックス付け言語タグとは異なる （「間違った」）言語の具体的な値をシステムが提供する場合があります。
このアプローチの主な課題は、インデックスを生成するために、内容からインデックス付け言語タグを抽出する必要があることです。
生成者は、インデックス付け言語タグが
何らかの形で正規化されるかどうかについて、消費者との
直列化に関する合意を持つ必要があるかもしれません。たとえば、言語タグ
cel-gaulish は、[BCP47] の祖父化された言語タグの 1 つです。
[CLDR] の規則に従う実装など、一部の実装は、
言語ネゴシエーションの目的で、このタグを現代的な等価物（この場合は
xtg-x-cel-gaulish）に置き換えることを望むでしょう。
[JSON-LD]
は、@context 構造の使用に依存する、言語インデックス付けの
特定の実装を定義しています。
この構造は LanguageEntry 値の使用を
サポートしていない（文字列または文字列配列だけがサポートされる）ため、[JSON-LD] 文書で上記の機能の一部を可能にするには変更が必要です。
この節は、上記の本文書で説明したさまざまな構造についての WebIDL 定義を含みます。
効果を上げるために、仕様の作者は同じ形式とデータ構造を一貫して使用するべきです。そうすることで、 大部分のデータ形式が相互運用可能になります（言い換えれば、多くの形式間で追加処理を適用することなくデータを コピーできるようになります）。単一言語のローカライズ可能なテキストフィールドには Localizable を、言語マップには LanguageMap を 採用することを推奨します。
WebIDL 辞書形式で言語と方向を定義することで、仕様は所与の String 値について言語メタデータおよび 方向メタデータを簡潔に組み込むことができます。実装は辞書実装をそのまま再利用できます。
WebIDLtypedef DOMString LanguageTag;
LanguageTag typedefDOMString。
WebIDLdictionary Localizable {
DOMString value;
LanguageTag lang;
TextDirection dir = "auto";
};
value メンバーlang メンバー
dir メンバーWebIDLtypedef record<DOMString,LanguageEntry> LanguageMap;
LanguageMap recordLanguageTag であり、値がそのキーに関連付けられた
ローカライズ済み文字列値と任意の上書きメタデータを含む LanguageEntry であるマップ。WebIDLdictionary LanguageEntry {
DOMString value;
LanguageTag? lang; // Optional property for language tag
TextDirection? dir; // Optional property for text direction
};
value メンバーlang メンバーLanguageMap の
LanguageEntry 内の
lang メンバーを上書きまたは補正する
LanguageTag。
このフィールドはまれに使用されます。
dir
メンバーTextDirection。WebIDLenum TextDirection {
"auto",
"ltr",
"rtl"
};
テキスト方向値は次のとおりであり、人間可読メンバーの値がデフォルトで次のようであることを意味します。
autoltrrtl国際化（I18N）ワーキンググループは、 この文書への次の貢献者に感謝します。 Mati Allouche, David Baron, Ivan Herman, Tobie Langel, Emil Lundberg, Sangwhan Moon, Felix Sasaki, Najib Tounsi, および多くの方々。
次のページが、この文書の最初の基礎となりました。
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: