With the Summer '26 release, Marketing Cloud Next handles multilingual content natively through Content Variations. The days of cloning an email, a flow and a reporting set for every language are over: you now maintain a single asset with as many language variations as you need, and the send engine picks the right one based on the recipient's language. If you run campaigns across several markets, the payoff is immediate — fewer assets to maintain, one approval cycle, and translations you can actually trace. Here is how to roll it out end to end, from CMS workspace setup through the XLF import cycle, including the traps we see most often on client projects.
What Summer '26 actually changes
Before this release, a five-language campaign in Marketing Cloud Next meant five emails, five flows and five reporting sets. One legal wording tweak turned into five tickets. Summer '26 introduces Content Variations on the Growth and Advanced editions: emails, images, headers, footers and promotional blocks can now carry language variations managed inside a single resource.
This did not land in isolation. The same release brought AMPscript support to Marketing Cloud Next, plain text sends, custom fonts, and form improvements that cut the dependency on CloudPages. Together, these remove most of the reasons teams had for staying on Marketing Cloud Engagement.
The "one resource, many variations" model
The mechanic is straightforward. You designate a source language — the one your designers write in — then add translation languages from those enabled in your Salesforce org. Each content block then carries its variations. At send time, the variation served depends on the recipient's language; when there is no match, the source language is used as the fallback.
Step 1 — Declare your languages in the CMS workspace
Start at the org level: only languages enabled in your Salesforce organisation settings will show up as translation languages later. This is the number-one blocker we hit in scoping workshops — the marketing team goes hunting for Italian in the CMS when it was never switched on at the platform level.
From there, open your CMS workspace, go to Manage, then Translations. Add each target language and confirm the workspace default. One piece of practical advice: start with two or three languages, not eight. The translation cycle is an operational process, not a checkbox, and every extra language adds a synchronisation point to your campaign calendar.
Step 2 — Get the language attribute right
Variation selection is only as good as your data. Before you translate anything, audit the coverage and normalisation of your language field. A quick SQL query against your Data Extensions tells you how much work is ahead:
SELECT
UPPER(LEFT(ISNULL(NULLIF(PreferredLanguage, ''), 'XX'), 2)) AS LanguageCode,
COUNT(*) AS Contacts
FROM [Contact_Master]
GROUP BY UPPER(LEFT(ISNULL(NULLIF(PreferredLanguage, ''), 'XX'), 2))
ORDER BY 2 DESCThree governance rules worth locking down before the first send:
- normalise to two-character ISO 639-1 codes in uppercase, with no regional variant unless the business genuinely needs one
- define an explicit fallback language and document it with your local teams
- reject nulls at ingestion, deriving language from country if you have to
Step 3 — The XLF cycle: export, translate, reimport
Marketing Cloud Next uses XLIFF, the standard format professional translation tooling expects. The cycle has four beats: export the XLF files from Manage > Translations, hand them to your agency or TMS, collect the translated files, then zip them before reimporting through the Import option.
An XLF fragment looks like this:
<trans-unit id="hero.headline">
<source>Your loyalty programme is changing</source>
<target>Ihr Treueprogramm ändert sich</target>
</trans-unit>
<trans-unit id="cta.primary">
<source>See your new benefits</source>
<target>Neue Vorteile entdecken</target>
</trans-unit>Three things to watch here. First, the id on each trans-unit must stay stable: if a designer rebuilds a block instead of editing it, the identifier changes and existing translations no longer attach. Second, the import expects a ZIP archive, even for a single file. Third, brief your translators never to touch personalisation tokens inside a segment — a {{recipient.firstName}} rendered as "recipient first name" will break the send.
Step 4 — What translation does not solve
Translating copy is not the same as localising a campaign. Date formats, thousand separators, currencies and forms of address belong to template logic, not to the XLF file. This is where Handlebars helpers earn their keep:
{{#if (eq recipient.language "de")}}
Lieferung am {{formatDate order.deliveryDate "dd.MM.yyyy"}}
{{else}}
Delivery scheduled for {{formatDate order.deliveryDate "MMMM d, yyyy"}}
{{/if}}Since Summer '26, AMPscript is available in Marketing Cloud Next too, which means proven logic from Engagement can move across without a rewrite:
%%[
VAR @lang, @greeting
SET @lang = Uppercase(Substring(AttributeValue("PreferredLanguage"), 1, 2))
IF @lang == "DE" THEN
SET @greeting = Concat("Guten Tag ", AttributeValue("FirstName"))
ELSEIF @lang == "ES" THEN
SET @greeting = Concat("Hola ", AttributeValue("FirstName"))
ELSE
SET @greeting = Concat("Hi ", AttributeValue("FirstName"))
ENDIF
]%%
%%=v(@greeting)=%%Here is how we split responsibilities at the start of a project:
| Element | Content Variations | Template logic |
|---|---|---|
| Email body copy | Yes | No |
| Subject line and preheader | Yes | No |
| Images with baked-in text | Yes | No |
| Date and currency formats | No | Yes |
| Country-specific legal notices | Partly | Yes |
The hard part of a multilingual campaign is never the translation — it is governing the language attribute. A contact with a missing or badly normalised language will get the wrong variation no matter how good your translations are.
Step 5 — Preview, test, measure
The preview screen was rebuilt in Summer '26 and now supports multilingual content, so you can switch languages without leaving the editor. Use it on every build, and pay particular attention to the subject line and preheader — they are the elements most often left untranslated.
Back it up with a test send per language to control addresses, and check mobile rendering. German runs 20 to 30 percent longer than English and will wrap your CTA buttons onto two lines. On measurement, break your reports out by language from the very first send: it is the only way to spot a variation whose translation is dragging performance down, rather than blaming the creative.
Key takeaways
One resource, many variations. Summer '26 removes per-language email duplication in Marketing Cloud Next and centralises translations in a single CMS resource.
Enable languages at the org level first. A language missing from your Salesforce settings can never be added as a translation language in the CMS workspace.
Language data comes before translation. Normalise to ISO 639-1, define a fallback language and reject nulls at ingestion.
XLF does not cover localisation. Dates, currencies and country-specific notices belong to Handlebars helpers or AMPscript, now available in Next.
Test per language, measure per language. Subject line, preheader and mobile rendering are the three checks that slip most often.
Planning a move to Marketing Cloud Next, or a multilingual rollout across several markets? Our SFMC consultants help with scoping, language data governance and industrialising the translation cycle. Let's talk about your project.
