Overview
Reelevant treats locale as a first-class dimension for multi-country personalisation. A locale identifies both a language and a country, written in the canonicallang_COUNTRY format (for example fr_FR, fr_CH, en_US, pt_PT).
Locale flows through four layers:
- DataHub — you map a locale field on your Datasource, and values are normalised to
lang_COUNTRYon ingestion. - Workflow runtime — the Personalisation Engine resolves a single locale per execution and uses it to filter product Datasources automatically.
- Content — components such as Countdown can adapt to the resolved locale, for instance to end a timer at the same local time in every country.
- Integration — when a Workflow is certain to use locale in a multi-country way, the integration panel makes locale selection mandatory before it reveals the links.
The locale format
A locale is a language identifier and a country identifier joined by an underscore, in the formlang_COUNTRY.
On ingestion, DataHub normalises raw values to the
lang_COUNTRY format. A country code (FR), an alpha-3 code (FRA), or a country name (France) is converted to the matching locale where possible. A value already in lang_COUNTRY form is kept as-is.Layer 1 — Mapping locale in DataHub
Locale is a field type you assign during field mapping. Two Datasource categories carry locale:- Product Datasource — the locale field describes which country a product row belongs to. This powers automatic filtering (see Layer 2).
- CRM Datasource — the locale field describes the recipient’s country. This lets a Workflow know each user’s locale without a URL parameter.
Localised product catalogs
A Localised product Datasource is a catalog where the same product exists in several countries, one row per locale. For this subtype, mapping a locale field is required — you cannot finish configuration without it. When you configure a Localised product Datasource, a dedicated step asks you to assign the locale value for each source. This guarantees every row resolves to a validlang_COUNTRY value.
Worked example
A retailer imports a shoe catalog covering three countries. After mapping, the locale field holds:
The same product (
SKU-100) appears three times, once per locale, each with its own price. Locale is what lets the Personalisation Engine return only the row for the recipient’s country.
Layer 2 — Automatic filtering at runtime
When a Workflow runs, the Personalisation Engine resolves one locale for the execution, then applies it automatically.How locale is resolved
The Personalisation Engine checks these sources in order and uses the first that yields a value:The Context node itself reads the CRM locale field when present, so sources 1 and 2 usually agree. The distinction matters only when the Context node is not on the executed Branch — the Personalisation Engine then falls back to reading the CRM node directly.
How product Datasources use it
A Product Datasource node adds a locale filter to its query automatically — you do not configure it. The node keeps only the rows whose locale field equals the resolved locale. Using the catalog above, if the resolved locale ispt_PT, the node returns only the Portuguese rows:
The rlvt-l parameter
rlvt-l is the reserved URL parameter that carries the visitor’s locale into the Workflow. Its value must always be a full ISO locale in lang_COUNTRY form (rlvt-l=pt_PT). A partial value such as a bare country code is not a valid locale and should not be used.
Layer 3 — Locale-driven content
Some Content components adapt to the resolved locale. The clearest example is the Countdown timezone behaviour.Countdown timezone
The Countdown component has a Use user’s local timezone option. When enabled, the countdown ends at the same local time in every country, instead of the same absolute instant. Behind the scenes, enabling this option binds the countdown tocontext.user.locale. The Personalisation Engine derives the viewer’s country from the resolved locale and adjusts the end time to that country’s timezone. For example, a sale set to end at 18:00 local time expires at 18:00 in France (fr_FR) and at 18:00 in Portugal (pt_PT), even though those are different absolute moments.
Because the Countdown reads
context.user.locale, a Workflow using this option is treated as a multi-country Workflow — locale selection becomes mandatory at integration (see Layer 4). Email client caching can still freeze a countdown image; see Email client caching and proxies.Layer 4 — Mandatory locale selection at integration
The integration panel generates the links you paste into your channel. For multi-country Workflows it enforces locale selection so links are never shipped without a country.When locale selection is required
The panel inspects the Workflow and marks locale as required in either of these cases:
A single locale value on a Datasource does not trigger the requirement — with only one country, there is nothing to choose.
What the user sees
While locale selection is required and no locale is chosen, the panel hides the integration links and shows a message asking the user to pick a locale. Once a locale is selected, the links appear withrlvt-l appended automatically.
This gating exists so every integrated link is attributable to a country in your statistics. Without it, a multi-country Workflow could be integrated with no locale, and its opens would not be tagged by country.
Worked example
Take the Localised catalog above, used by a Portugal campaign. The product Datasource exposes three locales (fr_FR, fr_CH, pt_PT), so the panel treats locale as required. The user selects pt_PT, and every generated link ends with &rlvt-l=pt_PT. At runtime the Personalisation Engine reads rlvt-l, filters the catalog to the Portuguese rows, and tags the open as pt_PT in analytics.