Polylang for WooCommerce, By WP SYNTEX

Polylang for WooCommerce by WP SYNTEX adds multilingual support to WooCommerce — translating products, categories, emails, and other store content into multiple languages. When you create a backend order using Phone Orders for WooCommerce, the order confirmation and notification emails should go out in the customer’s own language rather than the store’s default language. Without any intervention, Polylang’s email language handler doesn’t fire correctly in the Phone Orders context, so all emails default to the store language regardless of the customer’s locale setting.

This article provides a two-part fix that routes order emails through the customer’s saved language preference when Phone Orders creates or resends an order.

---

Part 1 — Edit the Polylang for WooCommerce Plugin File

Before applying the PHP snippet, you need to disable two action hooks inside Polylang for WooCommerce’s own code. These hooks interfere with Phone Orders’ email dispatch sequence and prevent the language switcher from firing at the right moment.

1. Open the file /wp-content/plugins/polylang-wc/include/emails.php on your server using your preferred file editor (SFTP, cPanel File Manager, or a code editor plugin).
2. Find lines 45 and 46 and comment them out by adding // at the start of each line:

3. Save the file.

⚠️ This change edits a third-party plugin file directly. Polylang for WooCommerce updates will overwrite it and you’ll need to reapply the comment-out after each update. Consider using a file monitoring tool or setting a reminder to recheck this file after Polylang updates.

---

Part 2 — Add the Compatibility Snippet

Once you’ve edited the Polylang file, add the following snippet to your child theme’s functions.php or the Code Snippets plugin:

---

Code Explained (for Developers)

Element	Description
woocommerce_before_resend_order_emails	A WooCommerce action that fires before the system dispatches order-related emails. Phone Orders hooks into this point to trigger its email dispatch — making it the correct place to set the customer’s language before the email sends.
Priority 1	Runs the callback as early as possible on this hook — before Polylang’s own before_order_email callback, which would otherwise set the wrong language first.
function_exists( 'PLLWC' ) and function_exists( 'PLL' )	Safety checks that confirm both Polylang and Polylang for WooCommerce are active before attempting to call any of their functions. The snippet exits cleanly with no errors if either plugin is absent.
$order normalisation block	The hook may receive $order as a numeric ID, an array with an order_id key, or a WC_Order object depending on the context. The three-branch normalisation block handles all three cases and ensures $order_id is always a valid integer before calling wc_get_order().
$order->get_customer_id()	Retrieves the registered WordPress user ID attached to the order. The language-switching logic only runs for registered customers — guest orders have no user ID and no stored locale, so the snippet skips them gracefully.
remove_action( 'woocommerce_before_resend_order_emails', ... 'before_order_email' )	Detaches Polylang’s own email language setter from the hook. Without this removal it would run after this snippet and overwrite the customer-specific language with the store default.
remove_filter( 'get_user_metadata', ... 'filter_user_locale' )	Temporarily removes Polylang’s user locale filter so the next get_user_meta() call reads the raw stored value rather than a Polylang-filtered one.
get_user_meta( $order->get_customer_id(), 'locale', true )	Reads the customer’s stored language locale from their WordPress user meta. This is the locale value the customer set in their account preferences.
$lang = empty( $lang ) ? get_locale() : $lang	Falls back to the site’s current locale if the customer has no stored language preference, ensuring the email always sends in some valid language.
add_filter( 'get_user_metadata', ... 'filter_user_locale' )	Re-registers Polylang’s user locale filter immediately after reading the raw locale, restoring normal Polylang behaviour for everything that follows.
PLL()->model->get_language( $lang )	Converts the locale string (e.g. fr_FR) into a Polylang language object that set_email_language() can use.
remove_filter( 'load_textdomain_mofile', ... ) / add_filter(...)	Temporarily removes and then restores Polylang’s translation file loader around the set_email_language() call. This prevents Polylang from re-routing the translation file lookup to the wrong language during the switch.
PLLWC()->emails->set_email_language( $language )	The core call — tells Polylang for WooCommerce to switch all subsequent email content, subject lines, and template strings to the customer’s language before the email sends.

---

How to Apply This Fix

1. Connect to your server via SFTP or open cPanel → File Manager.
2. Navigate to /wp-content/plugins/polylang-wc/include/emails.php.
3. Comment out lines 45 and 46 as shown in Part 1 above. Save the file.
4. Open Appearance → Theme File Editor in your WordPress admin, or open the Code Snippets plugin.
5. Paste the snippet from Part 2 into your child theme’s functions.php or create a new dedicated snippet.
6. Save the file or snippet.
7. Create a test order via Phone Orders for a registered customer whose account language differs from the store default.
8. Verify the order confirmation email arrives in the customer’s language rather than the store’s default language.

⚠️ Always use a child theme or Code Snippets for the PHP snippet — parent theme files get overwritten on theme updates. However, the edit to emails.php in the Polylang plugin folder must be reapplied manually after every Polylang for WooCommerce update.

---

When Should You Use This Fix?

This fix applies when you run a multilingual WooCommerce store with Polylang for WooCommerce and Phone Orders PRO, and order emails sent through Phone Orders always arrive in the store’s default language regardless of the customer’s language preference. It covers both new order emails created through Phone Orders and resent order emails triggered manually from the backend.