ロケール解決

用語集項目、ブランドボイス、指示、モデル設定は、いずれもロケールごとに保存されます。エンジンが翻訳リクエストを処理する際は、そのリクエストのロケールにどの保存済みエントリが適用されるかを解決します。これには、完全一致するコードの照合、地域バリアントをまたいだ継承、そして完全一致がない場合のフォールバックが含まれます。同じ解決ルールが、この 4 つすべての設定対象に適用されます。

仕組み#

ロケールは入力時に正規化され、その正規形で保存・返却されます。大文字・小文字や区切り文字は補正されますが、サブタグは保持されます。

照合はサブタグ境界をまたいで双方向に行われます。保存されたロケールは、一方が他方と完全一致する場合、または一方が他方の上位にあたる場合に、リクエストへ適用されます。また、同じロケールの表記ゆれでも、一方が他方の上位ではないものの、地域によって文字体系が決まる場合は一致とみなされます。つまり、地域のみを指定した形式と文字体系を明示した形式は同等です（zh-CN ≡ zh-Hans-CN、zh-TW ≡ zh-Hant-TW）。

複数一致する場合の解決#

適用可能な保存済みエントリが複数ある場合、エンジンはそれらを順位付けし、最適なものを使います。

• 完全一致または言語デフォルトを最優先。 de へのリクエストでは、de-DE（ドイツ語の CLDR デフォルトリージョン）が優先され、その次に単独の de が続きます。
• 次に、より具体的なものを優先 し、タイブレークに使います。
• それ以外の一致するリージョンもフォールバックとして残ります。たとえば唯一のエントリが de-CH しかない顧客でも、de リクエストに対してそれより良い一致がなければそのエントリが使われるため、設定が宙に浮くことはありません。

スクリプトの安全性#

追加ルールが1つあり、これはテキストが特定の正書法に結び付いている用語集のcustom_translation項目にのみ適用されます。文字体系が曖昧な基本言語、たとえば sr（キリル文字またはラテン文字）や zh（簡体字または繁体字）は、書き込み時にどの文字体系かを確定させる必要があります。方法は、文字体系を明示する（zh-Hans、sr-Cyrl）か、それを決定する地域を指定する（zh-CN → 簡体字、sr-RS → キリル文字、CLDR に準拠）かのいずれかです。拒否されるのは、文字体系も地域も付かない完全に裸のコードだけです。読み取り時には、こうした確定済みの形式は同等に扱われます。つまり、zh-Hans-CN として保存された用語集は zh-CN のリクエストに適用され、その逆も同様です。一方で、文字体系が不明な裸の zh リクエストは、文字体系が確定した行にはマッチしないため、安定した結果を得るには文字体系または地域を明示して送信してください。de のように文字体系が1つしかない言語では、文字体系の指定は不要で、de は通常どおり de-DE に解決されます。non_translatable 項目は、文字体系に関係なくそのまま通過します。

例#

地域コード（en-US から fr-FR、de-DE、nb-NO）で設定されたエンジンが、ベースコードのリクエスト（fr、de、no）を受け取る場合:

• fr ターゲットでは、fr-FR の用語集、ブランドボイス、指示が適用されます。これは fr に対するデフォルトとして順位付けされるため、最後の手段ではありません。fr-FR はフランス語の CLDR デフォルトリージョンだからです。
• en のソースは en-US のエントリに一致します。照合は双方向です。
• no ターゲットが nb-NO を拾うことはありません。no と nb はリージョンの組み合わせではなく、異なる言語サブタグです。ターゲットには nb を使ってください。

API でロケール解決を使う#

localize endpoint を呼び出すと、解決は自動で行われます。エンジンは、リクエストの sourceLocale と targetLocale を、保存済みの用語集、ブランドボイス、指示、モデル設定に照合します。追加のパラメータは必要ありません。

次のステップ#