Transactional emails are part of the customer experience in a multilingual WooCommerce store. An order confirmation, processing notice, refund message, invoice, or account email should use language that matches the customer’s order context. If these messages remain partly untranslated, customers may see inconsistent subjects, headings, body text, footers, or additional content even when the storefront itself is multilingual.
This guide explains the documented WPML workflow for WooCommerce email translation. It covers the email types explicitly supported in WPML’s WooCommerce documentation, translation through String Translation, registration of missing strings, and the way WooCommerce order language affects customer-facing messages. Customized templates, third-party extensions, and manually resent emails require additional verification because their behavior depends on the specific site configuration.
What WPML Can Translate in WooCommerce Emails
WPML documents a WooCommerce workflow for translating several important order-related emails. The explicitly covered group includes new order, processing, completed, cancelled, refunded, customer invoice, and customer-account creation messages. WPML states that the email subject, body, and footer are registered as translatable strings, so these parts can be handled through WPML String Translation rather than the ordinary translation workflow for posts, pages, or taxonomies.
WooCommerce itself provides a broader set of built-in notifications. Depending on the installed configuration, these can include failed-order, on-hold, order-details, customer-note, reset-password, confirm-email, and new-account messages, in addition to other order notifications. This list provides useful context, but it should not be treated as a guarantee that every message follows exactly the same WPML workflow.
The available email set depends on the WooCommerce configuration, enabled features, order statuses, active theme, and installed extensions. A message generated by an extension or an email customization tool may use strings that are not part of the standard WooCommerce group. Therefore, identify the source of each message before assuming that its subject, heading, body, or footer will appear automatically in String Translation.
Before You Start
First, confirm that the multilingual WooCommerce setup and target languages are already configured. The translation process described here is intended for text handled as strings: plugin labels, settings text, button text, error messages, and similar content that is not stored as an ordinary post, page, or taxonomy term. WooCommerce email text commonly belongs to this category.
Next, review the email settings in WooCommerce. WooCommerce exposes editable fields such as the subject, email heading, additional content, and email type. These fields can contain placeholders and may have been customized for the store. Record which messages are standard WooCommerce emails and which depend on a theme, email customization plugin, or another extension.
Use a staging environment or a backup-based workflow before changing production translations or email templates. Customer communications are operational content: an incorrect translation, missing placeholder, or incomplete message can affect what recipients see. Prepare representative test orders in each supported language so that the result can be checked before publishing changes.
Translating Subjects, Headings, Bodies, and Footers
The main administrator workflow begins in WPML > Translations > Strings. Search for the relevant WooCommerce email text and translate the registered strings for the required languages. According to the documented WPML workflow, email subjects, bodies, and footers are registered in String Translation together with other WooCommerce strings.
Translate the text in context rather than treating every matching phrase as interchangeable. A subject should remain suitable for an email subject line, while a body or footer may contain longer customer-facing content. Check the translated version for the correct order status, customer action, and message purpose. A completed-order email should not be confused with a processing, cancelled, or refunded message simply because some wording is similar.
WooCommerce’s email settings add another verification point. The subject, email heading, and additional-content fields may be editable independently. If a store has customized these fields, locate and check each corresponding string rather than assuming that translating the standard body will translate every visible part of the email.
Pay close attention to placeholders and dynamic order information. Translating the surrounding sentence must not remove, alter, or corrupt the placeholders used to insert order data. After saving translations, send test messages and inspect the rendered email, not only the translation screen. Check the subject, heading, body, footer, additional content, and dynamic information in each relevant language.
Reviewing WooCommerce Email Fields
A practical review should compare the fields configured in WooCommerce with the strings available in WPML. Check the subject, email heading, and additional-content fields for every message being tested. Treat customized fields as part of the verification process, because a field configured by a theme or extension may not appear through exactly the same route as a standard WooCommerce string.
If a translated email still contains text in the source language, identify whether that text comes from the standard WooCommerce message, a customized template, the active theme, or an extension. This distinction determines where the missing text should be registered and translated.
Registering Missing Email Strings
A common problem occurs when an email subject, heading, body fragment, footer, or custom message is not visible in String Translation. In that case, use the Not seeing strings you are looking for? utility and open Admin Texts Translation. This is the documented route for finding text that has not been registered automatically.
Scan the source that supplies the missing text. Depending on the message, that source may be WooCommerce, the relevant WooCommerce extension, an email customization plugin, or the active theme. Do not scan only WooCommerce when the untranslated content was added by another component. After discovering the required strings, select them and add them to String Translation. They can then be translated through the normal string workflow.
This procedure is especially relevant for customized email templates and third-party email tools. Such components may introduce additional strings, and their compatibility may not have been formally tested. Registration makes the text available for translation, but it does not by itself establish that every custom email behavior will match the standard WooCommerce flow.
WPML also documents an additional workflow for JavaScript-generated strings. When the missing text is generated through JavaScript, the relevant JavaScript string detection option and frontend scanning process may be required. This is more relevant to dynamic or block-based interfaces than to ordinary email fields, so first establish whether the text actually comes from JavaScript before using that procedure.
After registration, translate the string and send a new test message. Verify that the discovered text appears in the intended location and that registering it did not leave another part of the email untranslated.
How WPML Chooses the Customer’s Email Language
For the documented WooCommerce order-email flow, the key language is the language recorded for the order at checkout. WPML states that WooCommerce records the order language at checkout and uses that recorded language to select the matching customer-facing email translation when the order status changes.
This means that the checkout language is central to standard order emails. If an order was placed in one language, later status-based messages use the translation associated with that order language, provided the relevant strings have been registered and translated. The rule is therefore different from simply assuming that every message will use a current site preference or a universally preferred language.
Do not generalize this behavior to every message sent by every extension. Customized, third-party, manually triggered, or manually resent emails may not behave identically to the documented automated order flow. Test these messages on the actual site configuration, especially when an extension supplies its own email type or template.
Testing, Troubleshooting, and Workflow Limits
Testing should cover both translation quality and message behavior. Place representative orders in each supported language and review the applicable new-order, processing, completed, cancelled, refunded, invoice, and account-related messages. The precise set depends on the notifications enabled on the store.
If a message is incorrect, work through the source of the text instead of immediately editing unrelated strings. Check whether the problem is an untranslated subject, heading, body, footer, or additional-content field. Then determine whether the text belongs to WooCommerce, the active theme, a customized template, an email customization plugin, or another extension.
Also check the order language recorded at checkout. A correct translation can appear to be missing when the test order was created in a different language from the one expected. Review placeholders and dynamic order data as well. A message can be translated linguistically but still be defective if required order information is missing or malformed.
Compatibility is configuration-specific. The research confirms the documented WPML workflow, but it does not establish universal compatibility for every third-party WooCommerce extension or email customization plugin. The exact email list also varies with installed WooCommerce features, enabled settings, custom statuses, themes, and extensions. Manually resent messages should be tested separately rather than assumed to follow the original automated send.
A Practical Verification Checklist
Before publishing translated customer communications, complete the following checks:
- Place representative test orders in every supported language.
- Confirm that the order language at checkout produces the expected customer-facing language.
- Review subjects, headings, bodies, footers, and additional content.
- Check that placeholders and dynamic order information remain intact.
- Register missing strings through Admin Texts Translation when they are not visible in String Translation.
- Scan the relevant extension, customization plugin, or theme when it supplies the text.
- Test payment, refund, invoice, account-related, and other customer-facing messages used by the store.
- Record which messages are standard WooCommerce emails and which depend on customization or extensions.
Keep the verification environment separate from production whenever possible. Apply corrective changes only after confirming the source of the string and reviewing the resulting email. This reduces the risk of changing a customer communication without understanding which message or language context it affects.
In summary, the documented WPML process is based on identifying supported WooCommerce email strings, translating them in WPML String Translation, and registering missing text through Admin Texts Translation. WPML’s WooCommerce workflow covers new order, processing, completed, cancelled, refunded, customer invoice, and customer-account creation messages, including registered subjects, bodies, and footers. WooCommerce records the order language at checkout and uses it for matching customer-facing order emails when status changes. Customized templates and extension-generated messages require separate checks. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.