Language and locale property normalization

Outcome. A contact's preferred language always reads as one of a small, standard set of values, instead of a mix of raw locale codes, free-text guesses, and inconsistent casing that no email personalization rule or list segmentation can reliably filter on.

Workflow map Enrollment, branches and actions at a glance data-quality-040

flowchart TD
    A[Raw locale code known or changed] --> B{Starts with which prefix?}
    B -->|en| C[Preferred language: English]
    B -->|fr| D[Preferred language: French]
    B -->|nl| E[Preferred language: Dutch]
    B -->|de| F[Preferred language: German]
    B -->|es| G[Preferred language: Spanish]
    B -->|none match| H[Leave unset]

When to use it, when not to

• UseUse it when a raw locale code, from a browser's language header captured by an integration, a form field, or an import, needs to become a clean, standard picklist value used for segmentation and email personalization.
• UseUse it when the set of locales you actually operate in is small enough to map explicitly, a handful of languages, not the full space of every possible browser locale variant.
• SkipDo not use it to infer language from country alone. A contact's country and preferred language are related but not the same thing, a French-speaking contact in Belgium, an English-speaking expat in Germany. Keep them as separate properties.
• SkipDo not use it if the raw source already writes a clean, standard value directly. Check the actual raw values you receive before building a mapping for variants that do not occur in practice.