Polylang compatibility (v9.0.56) – emails and order-received in wrong language

Hello Jignesh,

Thank you so much for the incredibly fast turnaround — a fix in less than 24 hours for a free plugin is truly exceptional. We really appreciate it.

After testing version 9.0.57.1, here are the results:

✅ Order-received page now redirects to the correct language
✅ Order confirmation email is now sent in the correct language

One small remaining issue:
The order date in the confirmation email still appears in the site default language (French) instead of the customer’s language. For example, an English customer receives: [Order #26598] (février, 27 2026) — the month name is in French.

Separate issue — validation error messages:
When a customer clicks the PayPal button without filling in the required billing fields, the validation error messages appear in the wrong language (French instead of English). This happens because the PayPal button triggers a /wc-api/ request where Polylang does not apply its language detection.

We were able to work around this with the following code, which may be useful for your Polylang compatibility implementation:

add_filter( 'determine_locale', function( $locale ) {
if ( is_admin() ) {
return $locale;
}
$uri = $_SERVER['REQUEST_URI'] ?? '';
$is_wc_ajax = ! empty( $_REQUEST['wc-ajax'] );
$is_wc_api = ( strpos( $uri, '/wc-api/' ) !== false );
if ( ! $is_wc_ajax && ! $is_wc_api ) {
return $locale;
}
$pll_slug = isset( $_COOKIE['pll_language'] )
? sanitize_key( $_COOKIE['pll_language'] )
: '';
if ( $pll_slug === 'en' ) return 'en_US';
if ( $pll_slug === 'fr' ) return 'fr_CA';
return $locale;
}, 0 );

Note: the locale mapping (en → en_US, fr → fr_CA) is specific to our site. A more generic implementation could read the locale directly from Polylang’s language model.

Thank you again for your responsiveness and dedication to this plugin.

Best regards

Thank you for the suggestion.

In our testing, pll_current_language() returns an empty value in the /wc-api/ context, which is essentially the root of the issue. At that point Polylang has not fully bootstrapped the language, so the Polylang API is not reliable there and can’t be used as a sole source of truth for locale switching.

Regarding cookies being disabled: Polylang’s front-end language selection relies on its language cookie. If that cookie is absent, the bilingual site behavior becomes inconsistent anyway (e.g., language context can’t be persisted across requests). In practice, the cookie is therefore a safe and reliable signal specifically for these technical endpoint requests.

That said, I agree that the most compatible approach would be:

• Try pll_current_language('slug') first when it returns a valid value,
• and fall back to the Polylang cookie (and/or a language parameter in the return URL) when it does not.

We have not yet tested whether the direct credit card flow behaves differently for the order-received redirect and notification emails. If you have tested that flow, I’d be very interested to know whether it reproduces the same behavior in your setup.

Hello Jignesh,

Thank you very much for the quick turnaround and for providing the patched version.

I have tested a new order in English, and I can confirm that the month in the confirmation email is now correctly displayed in English. The localization issue appears to be resolved on our side.

The next step for us will be to test the direct credit card payment flow. I will clone the site and run tests in sandbox mode to verify that the order-received redirect and email localization also behave correctly in that scenario.

We really appreciate your responsiveness and the effort you put into addressing this.

Best regards,