You’ve outgrown English-only. Customers write reviews in Spanish, support tickets arrive in German and French, your Shopify Markets storefronts are live, and your social team just went viral in Portuguese. Meanwhile, your email program speaks one language and hopes context will carry the rest. That’s not a strategy; it’s a bottleneck.

In Klaviyo, “multilingual” can be elegant—or a maintenance nightmare—depending on the architecture you pick. This guide is the operator-level blueprint for doing it right: the real tradeoffs between single-account vs. multi-account, one-template-with-dynamic-language vs. duplicated flows, where to put your translations (and where not to), how to handle right-to-left layouts, how to keep deliverability clean across regions, and how to ship a program your translators can maintain without filing a JIRA for every comma.

We’ll also give you copy+code starters, a 90-day roadmap, a QA checklist that saves teams from slow-motion disasters, and a decision tree. If you want vibes, there are plenty of decks. If you want a system that pays rent in every language you sell in, you’re in the right place.

Why Multilingual Email Isn’t “Nice to Have” Anymore

• Conversion follows comprehension. “It’s fine in English” is a tax on conversion. People buy faster in the language their brain rests in.
• Deliverability cares about behavior, not intentions. If half your list can’t comfortably parse your copy, they don’t engage. Engagement falls → inbox placement erodes → revenue decays.
• Consent has a language. GDPR/PECR/Quebec Law 25 expect consent and policy notices your audience can read. So should you.
• Support tickets are expensive. A quickstart in the customer’s language cuts “how do I…?” tickets and returns. Retention begins with understanding.

The Decision Tree: Three Viable Architectures (Pick Once, Maintain Forever)

There are only three approaches that scale. Everything else is cosplay.

Option A — Single Account, Single Set of Flows, Dynamic Language (our default recommendation)

• What it is: One Klaviyo account. One set of flows. One template per message with language decided at render time using person.lang.
• When to use: 2–6 languages, ~70% shared content, one Shopify store (or Markets), one global brand/strategy.
• Pros: Minimal duplication; translators touch keys, not flows; testing applies globally; metrics live in one place; easier deliverability control.
• Cons: Template logic gets complex if content diverges heavily; you’ll need governance for translation keys.

Option B — Single Account, Separate Flows per Language (use when content diverges >30%)

• What it is: One Klaviyo account. Duplicated flows per language (e.g., “Welcome — ES” and “Welcome — EN”). Triggers segment by lang.
• When to use: Legal/compliance blocks differ by region; creative, merchandising, or cadence differ materially.
• Pros: Simpler templates; translators see their own flow; regional teams can move independently.
• Cons: Maintenance overhead; testing fragmentation; analytics are harder to roll up; mistakes multiply across copies.

Option C — Multi-Account (Per Region/Store) (use when data or ops is truly separate)

• What it is: One account per store/region (e.g., EU store, US store). Each account has its own flows and language set(s).
• When to use: Separate Shopify stores; materially different tax/shipping/compliance; distinct brand calendars; regional deliverability/IP strategy; data residency needs.
• Pros: Clean separation; localized “From” domains for deliverability; autonomy for regional teams.
• Cons: Highest cost/overhead; analytics comparisons require external BI; duplication risk high without tight ops.

Short answer: If you’re one store with a handful of languages, choose Option A and never look back. If your content, legal copy, or calendars truly differ, move to Option B with discipline. If you already operate multiple stores/teams, embrace Option C—but budget for translation ops and a BI layer to stitch truth back together.

Capturing Language (and Keeping It Accurate)

Language is not a guess. Store it the moment a human tells you—or when your storefront does.

1. Profile property: Create lang (ISO 639-1, e.g., en, es, fr, de, ar).
2. Set it from real signals:
   • Shopify Markets storefront or URL param (?lang=es / subdomain). On sign-up, pass lang to Klaviyo.
   • Signup forms: radio or dropdown (English, Español…); submit to lang.
   • Footer toggle / preferences page: write the choice to lang.
   • Browse behavior heuristic: last three sessions in same locale → propose a change (“Prefer Español?”). Do not auto-switch without consent.
3. Default and remember: Fallback to en if unknown; append ?lang={{ person.lang|default:'en' }} to links; update lang across channels (email, SMS, support).

Template Architecture: One Template, Many Languages (Without Tears)

With Option A, you’ll keep one template per message and load a language dictionary inside it. Translators edit the dictionary; marketers edit layout once.

Inline dictionary (fastest to ship)

{% set lang = person.lang|default:'en' %}
{% set T = {
  'en': {
    'subject': 'Your order is on the way',
    'headline': 'Track your order',
    'body': 'We’ll email when it’s delivered.',
    'cta': 'Track now'
  },
  'es': {
    'subject': 'Tu pedido está en camino',
    'headline': 'Rastrea tu pedido',
    'body': 'Te avisaremos cuando se entregue.',
    'cta': 'Rastrear ahora'
  },
  'fr': { ... },
  'de': { ... }
} %}
{% set L = T[lang] if lang in T else T['en'] %}

{{ L['headline'] }}

{{ L['body'] }}

{{ L['cta'] }}
    

Tip: keep keys consistent across templates (subject, headline, body, cta). Store legal or footer strings in a shared partial so one change propagates.

Shared partials (scale safely)

Create a “Language Pack” partial you include across templates. Translators update once; all emails reflect the change.

{# partial: lang_pack.html #}
{% set T = {
  'en': { 'review_cta': 'Tell us how we did', 'privacy': 'Privacy Policy' },
  'es': { 'review_cta': 'Cuéntanos cómo nos fue', 'privacy': 'Política de privacidad' }
} %}
{% set L = T[person.lang|default:'en'] if person.lang|default('en') in T else T['en'] %}
    

{% include 'lang_pack.html' %}
{{ L['review_cta'] }}
{{ L['privacy'] }}
    

Dictionaries from a CMS (enterprise-friendly)

If your translation team lives in a TMS (Phrase, Lokalise, Transifex, Crowdin) or CMS (Contentful, Sanity), sync a JSON dictionary into Klaviyo via API nightly. The template reads the dictionary as a variable (via data feed or liquid-like substitution using a custom integration). Governance wins; marketers stop being copy-paste couriers.

Beyond Copy: Currency, Dates, Images, and Links

• Currency & price: If Shopify Markets serves local currency on PDP(s), link with ?currency={{ person.currency|default:'USD' }} when applicable. Don’t hardcode “$”. Write “{{ price }} {{ currency_symbol }}”.
• Date/time: Use template filters to format dates per locale, or store a region property (e.g., region: 'de-DE') and render accordingly. When in doubt: ISO (YYYY-MM-DD) inside legal copy.
• Images: Avoid text in images. If you must, host localized variants and switch by lang.
• Legal/policy links: Point to localized routes (/es/politica), not a single English page.
• RTF quirks: Emojis and diacritics survive most clients; still, prefer live text over embedded text in graphics.

Right-to-Left (RTL) Languages Without Breaking Your Layout

Arabic and Hebrew need more than translation; they need a flipped canvas.

• Container-level direction: Wrap the body with <div dir="{{ 'rtl' if person.lang in ['ar', 'he'] else 'ltr' }}">. Many clients honor dir.
• Template CSS: Add a .rtl body class when lang is RTL to swap padding/margins and arrow directions. Keep CTAs centered to dodge edge cases.
• Fonts: Use web-safe fallbacks with proper glyph coverage (e.g., Noto family). Don’t rely on brand typefaces with incomplete RTL support.
• Numerals: Decide whether to use Arabic-Indic digits based on audience expectation; consistency beats novelty.
• QA: Hand-test in Outlook, Gmail web/app, iOS Mail, and Android. Mirror image direction in all icons (arrows, steps) for RTL.

Multilingual Forms & Preference Centers

Don’t capture consent in English and market in Spanish. The legal team (and your unsubscribe rate) will notice.

• Signup forms: Duplicate or dynamically translate copy; pass lang with the submission.
• Preference center: Show language toggles. Save the click to lang. Surface content themes (“Deals only”, “New drops”, “Order updates”).
• Compliance copy: Translate opt-in disclosures (TCPA/CTIA, GDPR/PECR). Use the local word for “unsubscribe.”
• Pop-ups per locale: Geo-target or route by URL path/subdomain; don’t show English opt-ins on /es/.

Turning Your 10 Core Flows Multilingual (Without Duplicating Yourself into a Corner)

Here’s how we translate the backbone with Option A (“dynamic language in one template”).

1. Welcome: 3–4 messages. Language dictionary for subject/CTA; one UGC block per language; a single offer keyed by country if needed.
2. Abandoned checkout: plain-text variant for all languages; dynamic proof block tied to product (images need no translation).
3. Post-purchase: quickstart modules per product type; the ZPD ask is language-agnostic but copy must be localized; legal links route to localized policy.
4. Second-purchase accelerator: recs filtered by goal; progress header (loyalty) localized; bandit test “proof-first vs. perk-first” in each language cohort.
5. Replenishment: minimal copy + numbers; quantitative language travels well; add localized “snooze” line.
6. Winback: “what you loved” + preference refresh (“Deals only | New drops | Updates”) in the customer’s language.
7. Subscription nurture/save: control words (“skip/swap/pause”) must be exact; never rely on icons alone.
8. Loyalty status: progress header + “redeem now” localized; avoid idioms that break.
9. Browse abandonment: show the product; keep language minimal and factual.
10. Birthday/anniversary: simple copy; regionalized date format.

If divergence grows (e.g., separate offers or legal copy), move those flows to Option B (duplicated per language) with a clear naming convention ([LANG] Flow — Name) and a “do not edit EN” policy to stop accidental cross-edits.

Deliverability Across Regions (The Quiet Multiplier)

• Dedicated domain & DMARC for the brand. If Option C (multi-account) per region, use region-specific subdomains mail.eu.brand.com for localized reputation.
• Warm-up/Down by engagement band. New language cohorts mean new engagement profiles; don’t slam them with full volume on day one.
• Unsubscribe in the local language. List-unsubscribe header still present; the visible word should be familiar (“Darse de baja”, “Se désabonner”).
• Complaint handling: Watch per-domain complaint rates; Spanish Gmail cohorts will behave differently from German Outlook cohorts. Adjust cadence accordingly.

Translation Ops: How to Keep This Maintainable When You Add a Sixth Language

• Glossary & tone guide. Maintain a lexicon per language (product names that never translate; banned phrases; preferred verbs). Translators love constraints; customers love consistency.
• Keys, not sentences. Organize copy as keys (subject, headline, cta_primary) instead of walls of prose. Changes don’t cascade accidentally.
• Review loop: Translators → in-platform preview → regional approver. No more PDF screenshots.
• Versioning: Keep translation dictionaries in Git (or TMS history). Copy paste is where bugs breed.
• Fallbacks: Always render English if a key is missing rather than a blank. Broken copy is cheaper than broken HTML.

Testing in Multiple Languages (Without Superstition)

• Structure vs. framing: Test structure (module order) globally if content is equivalent; test framing (proof vs. perk) per language cohort.
• Bandits for speed: Multi-armed bandits pick winners faster when traffic is split across languages.
• Document the “why.” “French cohort prefers proof first because…” becomes institutional memory, not guesswork.

Dashboards That Make Finance Nod (Per Language)

Weekly. Two minutes to read. Five dials plus notes:

• RPR by flow and campaign, split by lang.
• 30-day second-purchase rate per language.
• Reorder interval P1→P2 per language.
• Save rate at subscription cancel (if relevant) per language.
• Discount reliance per language.

Then PM notes: what changed, what we learned, what we’ll test next. You’ll spot early that “ES prefers proof-first” or “DE hates emojis in subject lines.”

90-Day Roadmap: From “We Should Add Spanish” to “We Operate in Five Languages”

Phase 1 (Weeks 1–3): Foundations

• Create lang profile property; default to en.
• Expose language capture (footer toggle + preference center + forms).
• Convert two flows (Welcome, Post-Purchase) to Option A (dynamic language). Ship English + Spanish first.
• Baseline metrics by language: RPR, second-purchase, discount reliance.

Phase 2 (Weeks 4–6): Expand & Orchestrate

• Translate Abandoned Checkout and Replenishment. Add progress header for loyalty languages.
• Wire SMS choreography and quiet hours by profile; confirm STOP/HELP in local language where required.
• Add in-template dictionaries to partials; remove hardcoded English from templates.

Phase 3 (Weeks 7–9): Optimize & Test

• Bandit test proof-first vs. perk-first per language in second-purchase.
• A/B test module order in Welcome for non-English cohorts.
• Introduce a third language (FR/DE) using the same partials.

Phase 4 (Weeks 10–12): Prove & Scale

• Publish a multilingual dashboard; present holdout deltas per language.
• Kill losing variants; keep exploration on; add one more flow (Winback or Subscription Save) to the multilingual set.
• Document the process (“Language Pack Handbook”) so the 6th language doesn’t require heroics.

Troubleshooting: Symptoms → Causes → Fixes

“Spanish CTR is high, conversion low.”

Causes: links route to English PDP; price shown only in USD; CTA idiom mistranslated.

Fix: append ?lang=es and local currency to URLs; use “Ver” vs. “Comprar” appropriately; QA with native speakers.

“Arabic layout breaks on Outlook.”

Causes: forgetting dir="rtl"; left-aligned arrows and padding.

Fix: wrap containers with dir; center CTAs; swap arrow icons; ensure fonts cover RTL glyphs.

“Translators keep changing EN keys.”

Causes: unclear key ownership; inline dictionaries scattered across templates.

Fix: move language packs into partials; add a glossary; gate EN changes through one owner.

“Deliverability dipped after adding FR/DE.”

Causes: volume spike without warm-up; unengaged legacy profiles included.

Fix: warm down to 0–30/31–60 bands; send helpful lifecycle only for 48–72 hours; check list hygiene.

FAQ: Multilingual Klaviyo Questions You’ll Be Asked (and Good Answers)

Do we need a new Klaviyo account per language?

No, not if you run one store and content is ~70% shared. Use Option A (dynamic language in one account). Multi-account is for separate stores/teams/compliance.

Can translators work without touching code?

Yes. Keep all strings in a shared partial or a TMS-synced dictionary. Translators edit keys; marketers touch layout.

How do we personalize without being creepy?

Use signals customers expect you to have (product bought, variant, shipping state) plus one explicit zero-party answer (primary_goal). Swap modules by goal, not identity.

Does multilingual email hurt deliverability?

It helps, when done right. Readability improves engagement → better placement. Just warm volume and use proper HTML/unsubscribe headers in every language.

Final Take: Multilingual Is Not a Project. It’s an Operating Principle.

You don’t “launch Spanish.” You earn Spanish. Then you keep earning it every week—with a system that respects the person on the other side of the screen and the language their brain rests in. If you want a partner who builds the system, not just the send—who measures with a spine and treats deliverability like a license—start here:

• Explore our email & SMS strategy
• Read case studies (numbers + context, not lore)
• Request a free audit (we’ll show you where the lift hides in every language you sell in)