orderAction.actionType はチェックアウトのリダイレクトとアクションタイプで扱っています。
チェックアウトの表示言語を制御するフィールドはどれですか？
注文作成時に渡すpaymentInfo.cashierLanguage です。
チェックアウトの言語を固定する Merchant Portal の設定はありません。言語を固定したい場合は、すべての注文で
cashierLanguage を渡してください。
cashierLanguage はどのような形式でなければなりませんか？
language[-script][-region] のみで、それ以外は受け付けません。
通る例：
拒否される値：
- アンダースコア区切り —
en_USは BCP 47 タグではありません。 - バリアントサブタグ —
de-DE-1996。 - 拡張サブタグ —
en-US-x-foo。 - 24 文字を超えるもの。
en-us は受け付けられ、en-US として保存されます。
値が間違っている場合、どのエラーが返りますか？
2 つの異なる結果があり、それぞれ意味が異なります。
どちらも注文作成時に HTTP 400 として返されるため、不正な値がチェックアウトページに届くことはありません。
A0047 が返った場合は文字列の形を修正してください。A0026 が返った場合は形は正しいものの、その言語が Waffo の描画対象ではないということです。下の一覧を確認してください。
同じフィールドはサブスクリプションでも使えますか？
はい。paymentInfo.cashierLanguage はサブスクリプション作成時にも同じ名前で存在し、同じ 24 文字制限、同じ BCP 47 ルール、同じ 2 つのエラーが適用されます。サブスクリプション作成フローの同じ場所で検証されます。
cashierLanguage はチェックアウトページ以外にも影響しますか？
サブスクリプションでは、はい。エンドユーザー向けのサブスクリプション通知は同じ判断を再利用します。Waffo が貴社の顧客にサブスクリプション通知を送る際、言語は cashierLanguage を指定していればその値、指定していなければ顧客の支払通貨から推定されます。
チェックアウトページとの違いに注意してください。通知はブラウザセッションではないため、読み取れる Accept-Language ヘッダーも国タブもありません。通知のフォールバックは通貨ベース、チェックアウトページのフォールバックは国ベースです（次の質問を参照）。
チェックアウトは表示言語をどのように決めますか？優先順位はありますか？
はい。5 つの層があり、上から順に評価されます。最初に値を返した層が採用されます。
設計上考慮すべき 2 つの帰結：
- 層 0、1、2 は言語を固定します。 いずれかがヒットすると、言語はもう国に追従しません。顧客が国タブを切り替えても文言はそのままです。
- 層 3 だけが国タブに追従します。 つまり、
cashierLanguageがなく、使用可能なAccept-Languageもない顧客は国を切り替えると文言が変わり、どちらかがある顧客は変わりません。
層 3 は実際にどの国を使いますか？
注文がライフサイクルのどこにあるかによります。「表示国」と「顧客の国」は同じものではないため、この区別は重要です。
選択ページでは、顧客自身の国が注文の候補一覧に含まれていない場合、表示国は候補一覧のいずれかの国で埋め戻されることがあります。この埋め戻された値は顧客の所在地を表さないため、言語の判断では意図的に使用しません。
Global タブの選択は所在地ではないため、所在地としては扱われません。IP から推定された国にフォールスルーします。
固定された表示言語とは何ですか？層 0 が存在する理由は？
顧客が決済手段選択ページで選択を送信すると、チェックアウトはその時点で見ていた言語を注文に保存します。それ以降、この値が他のすべてに優先します。 これは決済の途中で言語がぶれるのを防ぐために存在します。グローバルに利用可能な決済手段は、注文の表示国をGlobalに移動させます。これは実在する国ではなくセンチネル値です。スナップショットがなければ、現地語で表示されていた注文は、顧客がグローバルな決済手段を選んだ瞬間に英語のフォールバックへ切り替わり、顧客は選択から支払いの間にページの言語が変わるのを目にすることになります。スナップショットはすでに見ていた言語を固定します。 この値は設定も読み取りもできません。送信時にチェックアウトが書き込みます。貴社の連携への実務上の影響はこれだけです：顧客が選択ページで送信した後は、何をしても言語は変わりません。チェックアウトは Accept-Language から正確には何を読み取りますか？
層 2 は多くの人が想像するより狭いものです。
- ヘッダーの最も重みの高いエントリのみが考慮されます。それがサポート対象の言語にマッピングされない場合、チェックアウトは次のエントリを試しません。層 3 へ降ります。
- 主要言語サブタグのみが使用されます。ヘッダーの
zh-Hant-TWはzhに畳み込まれ、ヘッダー内のスクリプトと地域は破棄されます。 - 受け付ける主要サブタグは
en、es、id、ja、ko、ms、pl、pt、th、tr、vi、zhです。それ以外（fr、ruなど）は何も返さず、層 3 へフォールスルーします。 - 不正な形式のヘッダー（一部の古いアプリ内ブラウザは品質値を重複して出力します）は、生の文字列内の最初の言語タグを読み取る動作に退化し、同じマッピングが適用されます。
zh は繁体字中国語で描画されます。下記のスクリプトのフォールバックを参照してください。
チェックアウトはどの言語をサポートしていますか？
cashierLanguage が完全なタグとして受け付ける値は次のとおりです。
これらの文字列そのものに限定されるわけではありません。検証はサブタグ単位で行われるため、サポート対象の言語、任意のサポート対象スクリプト、有効な ISO 地域の任意の組み合わせが受け付けられます。たとえば
en-SG などです。地域が何を変えるかは次で説明します。
en-HK を渡しましたが、ページは en と同じに見えます。地域サブタグは無視されるのですか？
ページの文言については、実質的にそのとおりです。チェックアウトの文言は 13 の言語バケットで管理されており、タグは言語とスクリプトのみでバケットに対応付けられます。地域サブタグが別の文言セットを選ぶことはありません。
したがって
es-PE と es-CL は同じスペイン語の文言を描画し、en-KE と en-NG は同じ英語の文言を描画します。地域サブタグは引き続き注文に保持され、ロケールに応じた書式設定には使用されますが、文言を分岐させることはありません。
人を驚かせる 2 つの具体的なルール：
- 素の
zhは繁体字中国語で描画されます。 スクリプトサブタグがないと両者を区別するものがないため、チェックアウトはzhをzh-Hantに解決します。簡体字にしたい場合は、zh-Hansまたはzh-Hans-HKのようにHansスクリプトを明示的に渡してください。 - バケットのない言語は英語で描画されます。
ru-RUは検証を通りますが、ロシア語は 13 の文言バケットに含まれないため、ページは英語で描画されます。
何も渡しませんでした。顧客にはどの言語が表示されますか？
層 2 から 4 が、この順序で決定します。- 顧客のブラウザが送るヘッダーの最上位エントリが、受け付ける 12 の主要サブタグのいずれかであれば、その言語が使用され、国タブを切り替えても変わりません。
- そうでなければ言語は国から推定され（送信前は実際の所在地、送信後は表示国）、タブを切り替えると変わります。
- どちらからも得られない場合、ページは英語になります。
cashierLanguage を渡してください。
領収書をダウンロードする際、顧客はどの言語を選べますか？
同じ 13 のバケットが、それぞれの言語名で提示されます：English、Português、Español、繁體中文、简体中文、Tiếng Việt、ไทย、Bahasa Indonesia、日本語、한국어、Bahasa Melayu、Polski、Türkçe。 領収書の言語はダウンロード時に顧客自身が選択します。cashierLanguage によって決まるものではなく、選択してもチェックアウトページの言語は変わりません。
顧客自身にチェックアウトの言語を選ばせることはできますか？
チェックアウトページに言語セレクターはありません。言語は 5 層の連鎖が解決した結果になります。 顧客が変更できるのは、決済手段選択ページ上の国です。それが言語を変えるのは、連鎖が層 3 に到達した場合のみ、つまり貴社がcashierLanguage を渡さず、かつブラウザのヘッダーが一致しなかった場合のみです。国セレクターがそもそも表示される条件については、チェックアウトのリダイレクトとアクションタイプを参照してください。