How Multilingual Marketing Teams Work in SFMC

‍

Running one campaign in one language is a content problem. Running the same campaign in seven languages is a data problem.

Most teams discover this the hard way. The copy gets translated on time, and the send still goes out with a French audience receiving the German version.

The gap is almost never the translation. It is the audience layer underneath it.

‍

Salesforce Marketing Cloud gives you the pieces you need: locale settings, culture codes, international send encoding, shared data extensions across business units. What it does not give you is a single place where language lives.

Language ends up spread across subscriber attributes, business unit boundaries, dynamic content rules, and SQL filters written months apart by different people.

‍

This post walks through how multilingual teams actually operate inside SFMC, where the structure holds, and where it quietly breaks.

‍

What multilingual really means inside SFMC

‍

Language is a data attribute before it is content

In SFMC, a subscriber's language is not a system-level property. It is whatever field you decided to store it in.

That might be Language on a sendable data extension, Country used as a proxy, or a locale value inherited from a synchronized data source.

‍

Whichever you pick becomes the spine of every multilingual campaign you run afterwards. Change it later and you rewrite every query that touched it.

Teams that treat language as a content decision instead of a data decision tend to accumulate three or four competing versions of the same field.

‍

Where the language decision actually gets made

There are three common places: the send audience, the email content, and the landing page.

Each can resolve language differently, and they do not have to agree with each other.

‍

An email can be built with dynamic content blocks that branch on a subscriber attribute. The landing page behind it may resolve language from the browser preference instead.

Salesforce documents this explicitly for translated supporting pages, which are available in 21 languages and display based on the subscriber's browser language preference, even when that differs from the email language.

‍

Locale, culture code, and what they control

‍

Culture code sits at the account and user level

The culture code in Marketing Cloud Engagement sets language and formatting defaults for the account and for individual users.

It governs how dates and numbers render in the interface, and it now influences generated content. Einstein generative AI produces subject lines and body copy in French, German, Italian, Japanese, Portuguese, and Spanish when the user's culture code matches a supported language.

‍

This is useful, but it is worth being precise about scope. Culture code describes the user or account, not the subscriber receiving the message.

Teams sometimes assume that changing a user's culture code will change what a contact receives. It will not.

‍

Locales describe the subscriber

The locale object in Marketing Cloud Engagement represents a specific locale and indicates the location of a subscriber.

Salesforce maintains a list of valid locales for data extension sends, which matters once you send from a data extension rather than a list.

‍

If your locale values drift from that supported set, sends do not always fail loudly. They fall back, and the fallback is easy to miss in a QA pass.

‍

Content localization in Email Studio

‍

International sends and encoding

The International Sends feature in Email Studio lets you select the language encoding for an email and serves translated supporting pages to subscribers.

Salesforce recommends Unicode UTF-8 for most international audiences, while noting that a specific local encoding can be more appropriate for all or part of a list.

‍

Encoding is not cosmetic. Salesforce frames it as affecting both deliverability and whether the subscriber's client renders characters correctly.

Accented characters, German umlauts, and non-Latin scripts are where mismatched encoding shows up first.

‍

Dynamic content versus separate assets

Two patterns dominate, and both are defensible.

• One email with dynamic content blocks branching on a language attribute
• Separate email assets per language, each with its own send definition
• A hybrid: shared template, localized content blocks per market

‍

Dynamic content keeps the send count low and the reporting unified. Separate assets give local teams real editorial control.

The choice usually comes down to whether your regional teams need to change layout, not just words.

‍

Business units and shared data

‍

Shared data extensions in Enterprise 2.0

Most multilingual programs are also multi-business-unit programs. Enterprise 2.0 accounts let you share data extensions by storing them in shared data extension folders.

Segmentation across business units generally follows a set path. A query or filter activity pulls from a synchronized data source and populates a shared data extension, which is then made available to the relevant units.

‍

That shared layer is where the multilingual audience logic tends to live in practice.

‍

Permissions and sharing windows

Data Extension Permissions controls what each business unit can do with a shared data extension in Email Studio.

You can allow or deny specific actions per unit, and optionally set a Start Sharing and End Sharing date.

‍

This is useful for governance. It is also a common source of confusion when a regional team reports that an audience disappeared and the real cause is a sharing window that ended.

‍

Where multilingual segmentation breaks

‍

SQL does not know about language

A Query Activity has no concept of a language dimension. It only knows the column you tell it about.

So a query that joins _Open and _Sent to find engaged contacts will happily return a mixed-language result set unless someone remembered to add the filter.

‍

Multiply that by the number of markets and the number of queries in your account, and the failure mode becomes statistical rather than occasional.

It is rarely one broken query. It is fifty queries where three forgot the language clause.

‍

Language filters drift

Language values are notoriously inconsistent across sources. fr, FR, fr-FR, French, and Francais can all coexist in the same org.

A query written against one convention silently excludes contacts stored under another.

‍

The contacts are not missing. They are just invisible to that particular WHERE clause.

‍

Patterns that hold up over time

‍

Standardize the language attribute once

Pick one canonical field and one canonical format, then normalize everything into it at the point of ingestion rather than at query time.

Aligning that format with the locale values Salesforce supports for data extension sends saves a conversion step later.

‍

Normalization at ingestion is more work up front. It removes an entire class of segmentation bug afterwards.

‍

Build one audience, branch at the end

Rather than maintaining seven near-identical queries, build one audience query that carries the business logic and treat language as a final segmentation step.

When the engagement definition changes, you update one query instead of seven.

‍

This also makes review possible. A single query with clear language branching is something a regional marketer can read and challenge, even without SQL fluency.

‍

See QAiry in action

‍

Multilingual teams rarely lose time on translation. They lose it on the round trip between a marketer who knows the market and a technical resource who owns the query.

Every language variant adds another lap of that round trip, and the lap is the cost, not the SQL.

‍

QAiry lets you describe an audience in plain language and returns production-ready SFMC SQL, in English or in French, against your own data extensions and data views.

If your team runs campaigns across several markets, it is worth seeing how much that shortens the loop: qairy.com/product-demos, or start with qairy.com/try-it-free.