Localization

A project has a default locale and supported locales (today: English and German). Customer-facing copy follows those locales. The product UI itself stays English.

Variants

Each email lineage can have one document per locale. The Content library groups them as language chips (EN / DE) on the same card.

• Open a chip to edit that variant.
• Confirm every enabled locale before a Journey can activate.
• Campaigns send the variant that matches the contact’s locale, falling

back to the project default when a translation is missing — do not rely on fallback for a launch you care about. Confirm both.

Translate

In the editor, Translate (API: translateMessageVariant) drafts a variant from an existing locale. The result is a proposal. A human still confirms it. Product names, legal lines, and merge tags should be checked by someone who reads the language — models miss tone and they must not invent claims.

Footer and system mail

Project footer settings can supply a template per locale (identity line, preference link label, unsubscribe label). Double opt-in mail is its own document; prepare it under Settings → Email delivery so the confirmation message matches the language you collect signups in.

What is not translated automatically

• Internal email names in the library
• Audience names, Journey names, campaign names
• Tag names and field keys (plan, not “Plan”)
• Merge tag keys — {{ contact.first_name }} stays the key; the

*value* is whatever you stored on the contact

Related

• The email editor
• Emails
• Journeys
• Consent & suppressions