Define Contact-Language Sources Before Localizing Email
Generating twenty language versions is the easy part. The risky decision is which source assigns one version to one person.
- Written by
- Marketing Wiki Research Automation
- Review status
- Not independently reviewed
- Published
- Updated
- Evidence checked
- Sources
- 4
Set precedence, normalization, confidence, fallback, change handling, and review rules for the language field that selects each recipient's email variant.
Define the source and fallback for a contact's language before generating localized email. Prefer an explicit current preference, normalize it to an approved language set, and treat inferred locale as lower confidence than a recipient's direct choice.
Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Sources were refreshed on September 6, 2026.
Migma's multi-language guide and localized-send tutorial describe generating language variants and routing them from contact language. That makes the profile field a production decision, not decorative CRM metadata.
Set source precedence#
| Priority | Source | Confidence | Expiry or review rule |
|---|---|---|---|
| 1 | Recipient-selected communication language | High | Until changed by the recipient |
| 2 | Contract or account language explicitly chosen by customer | High for service mail; verify marketing use | Recheck on account change |
| 3 | Support-confirmed preference with timestamp | Medium-high | Reconfirm after material account or region change |
| 4 | CRM owner-entered language | Medium | Require provenance and review date |
| 5 | Recent content or product-language behavior | Inferred | Short expiry; never overwrite explicit preference silently |
| 6 | Browser, IP, country, or name inference | Low | Use only to ask or choose a safe default |
| 7 | Brand default | Fallback | Always available and fully reviewed |
The exact order is a governance choice. Publish it and make ties deterministic.
Normalize without inventing precision#
Use BCP 47 language tags for the stored contract, then map only to variants the campaign actually supports.
raw_value: "pt_BR"
normalized_tag: "pt-BR"
campaign_variants: ["en", "es", "pt"]
selected_variant: "pt"
fallback_reason: "regional variant unavailable"
source: "recipient preference center"
source_recorded_at: "2026-09-06T07:30:00Z"
confidence: "explicit"
owner: "localization operations"
Do not convert an unknown value into a specific regional dialect. If the campaign supports pt but not pt-BR, record the fallback rather than pretending the two artifacts are identical.
Keep language and consent separate#
Migma's event documentation says a customer event can update profile metadata including language but cannot opt someone in or make a non-sendable contact sendable. Preserve that boundary. A person using a French product interface is evidence about language, not consent to receive marketing email.
Test the routing table#
Create synthetic contacts for:
- exact supported tag;
- supported base language with unsupported region;
- malformed tag;
- explicit preference conflicting with inferred behavior;
- missing language;
- language changed after campaign approval;
- right-to-left language requiring separate layout review;
- unsubscribed contact with a valid language.
For each fixture, verify selected variant, fallback reason, consent invariance, subject and preview text, personalization variables, links, directionality, received rendering, and event-time versus import-time behavior.
The localized version-control guide governs approval of each translated artifact. This matrix binds the approved artifact to the right recipient.
Handle changes after scheduling#
Record whether the send platform resolves language at audience snapshot, schedule time, queue time, or delivery time. If the product does not document the moment, test it. Define whether a late preference change cancels, re-routes, or waits for the next campaign. Consent changes should fail closed regardless of localization timing.
Stop conditions#
Stop when an inferred language overrides an explicit preference, an unsupported value silently selects a random variant, the default version is unreviewed, right-to-left layout has not been tested, language changes can race with scheduled delivery, or contact language is used as evidence of consent, nationality, ethnicity, or legal jurisdiction.
Evidence limits#
Marketing Wiki did not test Migma's accepted tag set, resolution time, fallback, or right-to-left behavior. Documentation supports contact-language routing and profile updates; the precedence and test matrix are an independent operating method.
Sources behind this page
Claims remain tied to dated source review. Method and corrections stay public.