ローカライズ可能なマニフェストの開発

もう1つの考慮事項は、その仕様で採用される言語ネゴシエーション 戦略です。マニフェストが（well-known URLにキャッシュされるのではなく） オンデマンドで生成できる場合、ローカライズはリクエストごとに適用される可能性があります。これは 簡略マニフェストのスタイルにより近いことを示します。他の場合、ある 実装はネゴシエーションできるが他の実装はできない場合には、仕様が 異なる戦略の使用を許可することが重要になることがあります。

現代の動作環境は非常に広範な利用可能ロケールの集合をサポートしており、 アプリケーション所有者は、多様な利用者を単一のローカライズされたアプリケーションまたは 文書で満たしたいと考えることが多い点に留意してください。仕様内の例は必然的に3つか4つ程度のロケールに制限されますが、 50以上の特定ロケールを持つ実際のアプリケーションは珍しくありません。

マニフェストは、ユーザーの言語優先設定を利用可能なローカライズ済みリソースに一致させる必要があります。ユーザーの ロケール優先設定には、主言語サブタグだけでなく、より多くのものが含まれる場合があります。たとえば、 zh-Hans（「簡体字漢字で書かれた中国語」を意味する）のようなタグでは用字系、または fr-CA（「カナダで使用されるフランス語」を意味する）のようなタグでは地域 —あるいはその両方—が含まれる場合があります。一部のシステムは、カレンダー、数字の形状、照合順序などの 調整を含む [BCP47] の拡張である Unicodeロケール 識別子をサポートします。詳細は、[LTLI]を参照してください。

"localized-resource": {
	"en":     {"value": "This is English"},
	"en-GB":  {"value": "This is UK English"},
	"en-US":  {"value": "This is US English"}
}

en-GB-oxendict  // no match
en-GB           // matches en-GB
en              // if en-GB were not present, matches en
(default)       // no match, use defaults

非言語フィールド（すなわち、 人間の言語ではないデータを含む文字列）については、言語または方向のメタデータをその値に関連付けるべきではありません。これには、アプリケーション内部データ 値 [INTERNATIONAL-SPECS]が含まれることに注意してください。

消費者が データに言語タグを割り当てる必要がある場合、値zxx（非言語）を使用すべきです。消費者がデータに基底 方向を割り当てる必要がある場合、値autoを使用すべきです。

単一の言語で現れるローカライズ可能な テキストフィールドについては、値を表すためにデータ構造を使用します。 推奨される表現は、3つのフィールドを持つオブジェクトです。フィールドvalueは 実際の文字列を含みます。フィールドlangは妥当な [BCP47] 言語タグを含みます。フィールド dirは文字列の基底方向（値 ltr、rtl、またはautoのいずれか）を含みます。

[STRING-META] のローカライズ可能な WebIDL辞書を参照してください。

単一言語のローカライズ可能なテキストフィールドは、ある文書に自然言語の 文字列が少ししかない場合に最も有効です。マニフェストのような文書に多くの自然言語文字列が含まれる場合、 これは非効率になります。これらの文字列を符号化する複雑さを減らすための回避策の1つは、 言語および基底方向について文書レベルの既定値を確立することです。言語は方向を意味しないため、 これらは別個の値です。それでも、上記の単一言語のローカライズ可能なテキストフィールド 表現を使用して、任意の文字列値でどちらの値も上書きできる必要があります。

[JSON-LD] の@context機構を利用できる仕様では、 @languageフィールドと@directionフィールドを使用して、文書レベルの既定値を提供します。

仕様が独自の文書レベルの既定値を定義する場合は、2つの任意フィールドを提供します:

• 文書の既定言語フィールドは languageと呼ばれるべきであり、妥当な [BCP47] 言語タグを含むように指定されるべきです。仕様は、 [BCP47] 言語タグが整形式であるかどうかだけを実装が確認すればよいと指定するべきです。
• 文書の既定の基底方向フィールドは directionと呼ばれるべきであり、値 ltr、rtl、またはautoをサポートすべきです。

世界は単一言語ではありません。単一の言語のみを含む文書を持つことは、マニフェストをローカライズするために、 各言語ごとに文書の反復を多数提供することを意味します。これには、マニフェストを要求する際に 言語ネゴシエーションが必要になる場合もあります。

これに対処する1つの方法は、マニフェスト文書内の各ローカライズ可能なテキストフィールドに対して 多言語値を許可することです。

言語選択は、言語タグの文字列値をユーザーの優先 ロケールに単に完全一致させることではありません。通常のオブジェクト表現のローカライズ可能な テキストフィールドでは、値に関連付けられた言語タグを見つけるために、オブジェクトをデシリアライズする必要があります。これは、あるマニフェストファイル内に多くの値がある場合に非効率になることがあります。 このような場合のベストプラクティスは、言語マップを使用してローカライズ可能なテキスト値を整理することです。このような マップは選択の目的で言語タグを公開しますが、それでもマップの値側ではオブジェクト表現を使用します。これは、特定の 文字列値について言語と方向の両方を上書きする必要がある場合があるためです。

単一マニフェストのアプローチは、言語値の配列を使用してローカライズ可能なフィールドを定義することで、 ローカライズを可能にします。

単一マニフェストの利点には、次のものがあります:

1. マニフェストが単一ファイルであり、ダウンロードが容易になります。
2. 各言語で正しいバージョンのリソースが使用されていることを保証しやすくなります。
3. 言語の既定化を管理しやすい場合があります。

このアプローチには、次のような欠点もあります:

1. マニフェストが多くの言語にレンダリングされる場合、ファイルサイズが不釣り合いに大きくなる可能性があります。
2. ローカライズ工程は通常、元のファイルのコピーを作成し、言語を含む素材だけを置き換えるように最適化されています。 高度に多言語化されたファイル内でローカライズを作成、管理、同期することは、 言語ごとに個別ファイルを使用するより複雑になる可能性があります。スクリプトまたはツールによって マニフェストを生成することは、この複雑さを管理するための1つのアプローチです。

単一マニフェストは、ローカライズ可能なコンテンツフィールドの数が限られている、かつ/または言語数が限られている 小さなソースファイルで最も有効です。ほとんどの単一マニフェストは、実際の選択を行うために、 何らかの種類の「言語索引付け」方式（[JSON-LD] に見られるものなど）を定義します。

ロケール固有のマニフェストでは、サポートされる各言語またはロケールごとに個別のファイルを作成します。通常、 仕様はマニフェストファイルを割り当てて見つけるために、pathまたはfilenameの どちらかに基づく構成方式を選択します。

ロケール固有のマニフェストの利点には、次のものがあります:

1. ロケールの作成または追加の管理は、一般により簡単です。ローカライズ工程は通常、 指定されたソースファイルの「ローカライズ済みコピーを作成する」ために最適化されています。

欠点には、次のものがあります:

1. 単純なロケールフォールバックチェーンであっても、クライアントが複数のファイルを検索または取得する必要が生じる場合があります。
2. ファイルが個別であるため、コンテンツのバージョン管理を厳密に制御する必要があります。
3. 適切な動作を保証するために、より多くのバリエーションをテストする必要がある場合があります。

一般的な折衷案は、ローカライズできないコンテンツの大部分またはすべてを含む中央マニフェストファイルを用意し、 ローカライズ可能なコンテンツを含む個別ファイルと組み合わせることです。場合によっては、中央 マニフェストファイルがローカライズ可能なコンテンツの既定値を含みます。中央マニフェストには、 利用可能なロケールのディレクトリまたは一覧（あるいは言語固有マニフェストのURL）を含めることもでき、 それによりクライアントは実際に利用可能なローカライズ済みファイルだけを取得しようとすれば済みます。