How To Write Transactional Emails for Multi-Language Audiences

What Makes Multilingual Transactional Emails Different

Multilingual transactional emails are automated messages that reach each customer in their own language. Think receipts, password resets, and shipping updates. Your app picks the language at send time from the customer’s saved locale.

Marketing emails go out as one campaign you can translate in advance. Transactional emails fire one at a time, triggered by an action. So the language decision has to happen in your code, on every single send.

Email localization goes one step further than translation. It also adapts dates, prices, names, and layout to how each region reads them.

How to Send Multilingual Emails for Transactional Messages

To send multilingual transactional emails, save each customer’s language and pick the matching template at send time. Add a fallback to your default language. Then format dates and prices by locale, and send everything as UTF-8.

Here’s the process I recommend, in the order you’ll need it. Even the first 4 steps will get most customers emails they can read.

Step 1: Get the Basics Right First

Before you translate anything, make sure your English emails are clear and actually arrive.

Write short, plain sentences with no slang or idioms. Simple source text translates faster, costs less, and leaves fewer chances for errors.

Then check email deliverability. A perfect translation does nothing in a spam folder.

Authenticate your sending domain with SPF, DKIM, and DMARC. Then protect your domain reputation with clean lists and steady sending patterns.

Finally, send through a dedicated transactional email service like SendLayer. It handles authentication, bounces, and suppression lists for every language you send in.

Step 2: Capture and Store Each Customer’s Language

Your app can’t send the right language unless it knows which one to send. So save a language on every customer record.

Use a standard language tag, like en-US, de-DE, or pt-BR. These are BCP 47 tags, the same format browsers use.

Storing the full tag keeps regional differences, like Brazilian vs. European Portuguese.

Here are 4 places to capture it:

• Signup or checkout: Add a language dropdown, pre-selected from the visitor’s browser.
• Browser default: Read the Accept-Language header when the customer signs up.
• Account settings: Let customers change their language at any time.
• The page they used: A checkout on your /fr/ pages makes French a safe default.

Step 3: Choose Per-Language Templates or Dynamic Content

There are 2 common ways to build multilingual emails. Most teams end up using a mix of both.

I lean toward one template with translation strings. You fix a layout bug once, and every language gets the fix.

Keep variables out of the translated text where you can.

Write Order {order_id} has shipped as a whole string. Don’t glue “Order” + number + “has shipped” together in code. Word order changes between languages.

Step 4: Set Up a Fallback Language

A fallback language makes sure every email still goes out, even when a translation is missing. Sooner or later, a customer will have a language you haven’t translated yet.

Build a fallback chain from most to least specific. For example: pt-BR → pt → en.

Fall back per string too, not just per email. Say one new line isn’t translated yet. Show that line in English and send the rest in Portuguese.

Never let a missing translation block the email. A password reset in the “wrong” language beats one that never arrives.

Step 5: Format Dates, Prices, and Numbers by Locale

Format dates, prices, and numbers with locale tools, not by hand. In the US, 03/11/2026 means March 11. In the UK, it means November 3.

Use your language’s locale tools: Intl in JavaScript, Babel in Python, or IntlDateFormatter and NumberFormatter in PHP. They all pull from the Unicode CLDR data set.

I ran one date and one price through JavaScript’s Intl to show the difference:

en-US   November 3, 2026      $1,234.50
en-GB   3 November 2026       £1,234.50
de-DE   3. November 2026      1.234,50 €
ja-JP   2026年11月3日          ￥1,235
ar-EG   ٣ نوفمبر ٢٠٢٦          ١٬٢٣٤٫٥٠ ج.م.‏

Notice that yen has no decimal places, so the total rounded. Egyptian Arabic uses its own digits. Hand-built formatting gets both of these wrong.

Remember time zones too. “Your delivery arrives at 3 PM” should mean 3 PM where the customer lives.

Step 6: Handle Encoding, Subject Lines, and RTL Layouts

Send every email as UTF-8, and declare it. That one setting covers accents, Cyrillic, Chinese, Arabic, and emoji.

Subject lines need extra care. Email headers only allow plain ASCII text, so your mail library encodes other characters (RFC 2047). Here’s what Python produced for a German subject line in my test:

Subject: =?utf-8?q?Best=C3=A4tigung?= Ihrer Bestellung Nr. 1042

Your mail library or email API should do this for you. Problems show up when someone builds raw headers by hand.

Set the language and direction on the HTML too:

<html lang="ar" dir="rtl">

Arabic, Hebrew, Persian, and Urdu are read right-to-left. With dir="rtl", text, tables, and button rows flip to match. Use logical alignment like text-align: start instead of hard-coding left.

Finally, leave room for longer text.

Step 7: Translate With Machines, Then Review With People

Machine translation is a fine first draft for transactional emails. The messages are short and repetitive, and they rarely change.

But don’t ship machine output unreviewed. Have a native speaker check each template once. Pay extra attention to money, security, and legal terms.

As well as the words, ask your reviewer to check:

• Natural phrasing: What sounds natural in their culture.
• Tone: Whether it fits, like formal “Sie” or casual “du” in German.
• Idioms: Phrases that don’t translate.
• Names: Names, addresses, and honorifics in the right order.

Your templates rarely change, so this review is mostly a one-time cost. Re-check only the strings you edit.

Localize the Pages Your Emails Link To

A translated email that links to an English-only page breaks the experience. The customer clicks “Track your order” in Spanish. Then they land on a page they can’t read.

Every transactional email points somewhere. Usually that’s an order-tracking page, a checkout, an account page, or a password-reset form. Those pages need to match the email’s language.

On WordPress, Universally handles this side of the job. It’s an AI website translation plugin that covers 110+ languages.

Here’s what it does that matters for transactional email:

• WooCommerce pages: It translates product pages, the cart, checkout, and my-account pages.
• Forms: It translates form labels, placeholders, and error messages. That includes WPForms, Gravity Forms, and Contact Form 7.
• Language URLs: Each language gets its own prefix, like /fr/ or /es/. That makes it easy to tell which language a customer used.
• New content: It translates pages you publish later automatically.

That /fr/ prefix connects back to Step 2. If a customer checks out on your French pages, save fr as their email language. Then use the same language in the links inside your emails.

Setup takes a few minutes. You’ll need to install the plugin and enter your API key.

Then you pick your languages in the Universally dashboard. You can test it for free with 1 language.

Design for the Devices Your Customers Use

In many markets, customers read most email on a phone. Design for a small screen first, everywhere.

• Layout: Use a single-column, responsive layout.
• Text size: Keep body text at 16px or larger.
• Buttons: Make them big enough to tap, with space between links.
• Spacing: Leave extra room for longer translated text (see Step 6).

Check dark mode too. Test that your colors, logo, and images still read well when the background flips.

Testing Your Multi-Language Emails

Test every language before customers see it. A quick checklist covers most problems:

• Characters: Accents, Cyrillic, and Asian scripts display correctly in the subject and body.
• Length: Buttons and headings still fit in your longest language. German and Finnish are good stress tests.
• Direction: RTL emails flip correctly, including tables and button rows.
• Fallbacks: An untranslated locale still sends in your default language.
• Links: Every link opens the matching language version of the page.
• Clients: The email looks right in Gmail, Outlook, and Apple Mail. Check regional providers too, like Mail.ru or Naver Mail.

Ask a native speaker to open the test emails on their own phone. They’ll spot an awkward phrase faster than any tool.

Email Compliance Across Borders

Transactional emails get different treatment from marketing emails in most privacy laws. But that only holds while the email stays transactional.

In the US, CAN-SPAM uses a “primary purpose” test.

Would a reasonable reader see it as a receipt, account notice, or delivery update? Then it’s transactional.

Those messages don’t need an unsubscribe link. They must still have accurate routing information, as the FTC’s CAN-SPAM guide explains.

Add a promotion to that receipt and it may count as a commercial email. Then the opt-out rules apply, in every language you send.

In the EU and UK, GDPR covers the personal data you collect and store. That includes the language preference you saved in Step 2. Follow our email data privacy guide for the basics.

Some countries also require your business address or registration number in the footer. Check the rules for each market you sell into. Then translate the footer with everything else.

Measuring Performance by Language

Once your emails are live, compare results for each language. A drop in one language usually points to a translation or layout problem.

SendLayer doesn’t break down reports by language on its own. So use the locale you already store.

Tag each send with it in your own app. Then match SendLayer’s webhook events, like delivered, bounced, and clicked, back to that locale.

You can also check individual messages in the SendLayer email log. It’s searchable by recipient, domain, status, and date.

Be careful with open rates.

Apple Mail Privacy Protection loads images automatically. That makes open rates look higher than they are. Clicks and delivery rates are more reliable.

If one language underperforms, start with the subject line and the main button. Small fixes there often help the most.

Troubleshooting Multilingual Emails

Accented Characters Show Up as Garbled Text

Text like “Bestätigung” shows up when an email client reads UTF-8 text as another charset, like Latin-1. That happens when the email doesn’t declare UTF-8.

Set the charset to UTF-8 in your template and your mail library. Then save your translation files as UTF-8 too.

The Customer Got the Email in the Wrong Language

Check which language your app stored for that customer.

A common cause is reading the browser language on every send. Load the saved locale from the customer record instead. Use browser data only as the first default.

The Arabic or Hebrew Layout Looks Backwards

Add dir="rtl" and the correct lang value to the <html> tag. Replace hard-coded left and right alignment with start and end. Then test in Gmail and Outlook, since they handle RTL differently.

Translated Button Text Overflows

Fixed-width buttons break when a translation runs longer than the English. Let buttons grow with their text, and allow headings to wrap. If space is really tight, ask your translator for a shorter phrase.

Frequently Asked Questions

Here are answers to common questions about multilingual emails.

Rachel Adnyana

Rachel has been writing about WordPress for a decade and building websites for much longer. Alongside web development, she's fascinated with the art and science of SEO and digital marketing.

See Full Bio