>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3614193. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !21 >>> <p>The hosted checkout page is always rendered in one site-wide language. <code class="language-php">kessai_worldline.settings:checkout.locale</code> holds a single value, shipped as <code class="language-php">fr_FR</code>, and the gateway sends it for every payer. On a multilingual site somebody browsing in English is handed a French payment page, at the one moment in the flow where being confused is most expensive.</p> <h3>The information is already on the payment</h3> <p>The <code class="language-php">kessai_payment</code> entity declares <code class="language-php">langcode</code> as an entity key, so every payment already records the language it was created in. Nothing in the module reads it. So the engine is storing the answer and the gateway is ignoring it in favor of a constant.</p> <p>That makes this narrower than it first looks. No new field, no new engine concept: the payment carries the language, the gateway turns that language into whatever shape its provider wants.</p> <h3>The part that needs deciding</h3> <p>Drupal language codes and provider locales are not the same alphabet. Drupal has <code class="language-php">fr</code>; Worldline wants <code class="language-php">fr_FR</code>. Doubling the code covers the common cases and quietly gets <code class="language-php">en</code> wrong, since a site may mean <code class="language-php">en_GB</code> or <code class="language-php">en_US</code> and the difference is visible to the payer.</p> <p>Options, roughly in order of how much they ask of a site:</p> <ul> <li>Derive the locale by doubling the language code, and keep the existing setting as the fallback for anything unmatched. Cheapest, and wrong for English.</li> <li>Add a small per-language map beside the existing locale setting, so a site says once that <code class="language-php">en</code> means <code class="language-php">en_GB</code>. Honest about the ambiguity, one more thing to configure.</li> <li>Read it from the language's own configuration where Drupal already knows a region, and fall back to the map or the doubling.</li> </ul> <p>The middle one looks right: the ambiguity is real, it is per-site, and it is small.</p> <p>The existing locale setting is not replaced by the map, it becomes the floor under it: whatever the payment's language, a language the map does not name falls back to that one value, which is also what a payment with no usable language gets. So a site that adds no mapping at all behaves exactly as it does today, one field is added rather than one swapped, and there is no arrangement of settings that leaves the gateway without a locale to send.</p> <h3>Which language, exactly</h3> <p>A second thing to settle: whether the payment's <code class="language-php">langcode</code> is the payer's language in every flow that matters. It defaults to the content language at creation, which is right for a payer buying something on the site, and may not be for a payment created by a back-office action or a queue worker on somebody's behalf. A caller that knows better should be able to say so, and the gateway should fall back to the configured locale rather than guess when the language is unknown.</p> <h3>Boundary</h3> <p>The locale stays inside the submodule. The engine's part is only that the payment carries a language, which it already does; turning a language into a provider locale is provider-shaped and belongs with the provider, in the same way the session timeout and the attempt count do.</p> <h3>Notes</h3> <p>Found while reviewing the settings form in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614082" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614082</a></span>. Not part of the <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/kessai/-/work_items/3614067" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/kessai/-/work_items/3614067</a></span> series, which is about expiry and handoff, so it is filed separately rather than folded in. Documentation and the French translations come with the change, and no update hook: the module is pre-1.0, so reinstall is the upgrade path.</p>