Vertiges

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,

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

Hi,

Thanks for your response. After thorough testing, it appears that the issue is specifically tied to the credit card payment method using Hosted Fields (payment_method_wpg_paypal_checkout_cc) in your plugin.

When submitting the checkout form with required fields missing (e.g., first name), instead of triggering WooCommerce’s native validation, the submission is interrupted and an “Unknown error occurred” message is displayed.

This issue does not occur with the standard PayPal payment button, which correctly allows WooCommerce validation to run before proceeding.

In your script ppcp-paypal-checkout-for-woocommerce-public.js, the following line appears to override the default behavior:

$('form.checkout').on('checkout_place_order_wpg_paypal_checkout_cc', (event) => {
event.preventDefault();
return this.handleCheckoutSubmit(event);
});

This effectively bypasses WooCommerce’s validation logic. Since handleCheckoutSubmit doesn’t replicate that logic on its own, users can click “Place Order” with missing or invalid data and get a generic error instead of proper field-level messages.

It would be great to adjust this logic to allow WooCommerce’s native validation to complete before handleCheckoutSubmit() is triggered — or, alternatively, explicitly perform equivalent validation within your handler.

Let me know if you’d like help testing a fix.

Best regards