> ## Documentation Index > Fetch the complete documentation index at: https://docs.reelevant.com/llms.txt > Use this file to discover all available pages before exploring further. # Gestion de la locale et du multi-pays > Comment la locale circule de DataHub au Personalisation Engine, pilote le filtrage automatique des produits et le fuseau horaire des countdowns, et devient obligatoire à l'intégration ## Vue d'ensemble Reelevant traite la **locale** comme une dimension de premier plan pour la personnalisation multi-pays. Une locale identifie à la fois une langue et un pays, au format canonique `lang_COUNTRY` (par exemple `fr_FR`, `fr_CH`, `en_US`, `pt_PT`). La locale circule à travers quatre couches : 1. **DataHub** — vous mappez un field locale sur votre Datasource, et les valeurs sont normalisées au format `lang_COUNTRY` à l'ingestion. 2. **Exécution du Workflow** — le Personalisation Engine résout une seule locale par exécution et l'utilise pour filtrer automatiquement les Datasources produit. 3. **Content** — des composants comme Countdown peuvent s'adapter à la locale résolue, par exemple pour faire expirer un compte à rebours à la même heure locale dans chaque pays. 4. **Intégration** — lorsqu'un Workflow utilise la locale de façon multi-pays certaine, le panneau d'intégration rend la sélection de locale obligatoire avant d'afficher les liens. Cette page décrit chaque couche et la façon dont elles s'articulent. ## Le format de la locale Une locale est un **identifiant de langue** et un **identifiant de pays** joints par un underscore, sous la forme `lang_COUNTRY`. | Propriété | Détail | | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **Partie langue** | Code [ISO 639-1](https://fr.wikipedia.org/wiki/Liste_des_codes_ISO_639-1) à deux lettres minuscules (par ex. `fr`, `en`, `pt`). | | **Partie pays** | Code [ISO 3166-1 alpha-2](https://fr.wikipedia.org/wiki/ISO_3166-1_alpha-2) à deux lettres majuscules (par ex. `FR`, `CH`, `US`). | | **Séparateur** | Un underscore (`_`) entre les deux, selon la convention d'identifiant de locale Unicode/CLDR. | | **Exemples** | `fr_FR`, `fr_CH`, `fr_BE`, `en_US`, `en_GB`, `pt_PT`, `de_DE`. | | **Pourquoi le pays compte** | Une même langue peut cibler plusieurs pays (`fr_FR` vs `fr_CH`). La locale les distingue pour le filtrage et l'analyse. | À l'ingestion, DataHub normalise les valeurs brutes au format `lang_COUNTRY`. Un code pays (`FR`), un code alpha-3 (`FRA`) ou un nom de pays (`France`) est converti vers la locale correspondante lorsque c'est possible. Une valeur déjà au format `lang_COUNTRY` est conservée telle quelle. ## Couche 1 — Mapper la locale dans DataHub La locale est un type de field que vous assignez lors du [field mapping](/fr/advanced-guide/datahub/field-mapping). Deux catégories de Datasource portent la locale : * **Datasource produit** — le field locale indique à quel pays appartient une ligne produit. C'est ce qui alimente le filtrage automatique (voir Couche 2). * **Datasource CRM** — le field locale indique le pays du destinataire. Le Workflow connaît ainsi la locale de chaque utilisateur sans paramètre d'URL. ### Catalogues produit localisés Un Datasource produit **localisé** est un catalogue où un même produit existe dans plusieurs pays, une ligne par locale. Pour ce sous-type, mapper un **field locale est obligatoire** — vous ne pouvez pas terminer la configuration sans lui. Lors de la configuration d'un Datasource produit localisé, une étape dédiée vous demande d'assigner la valeur de locale pour chaque source. Cela garantit que chaque ligne résout vers une valeur `lang_COUNTRY` valide. Un Datasource produit localisé sans field locale mappé ne peut pas être enregistré. Si votre catalogue mélange plusieurs pays dans un seul flux, mappez la colonne qui identifie le pays ; si vous chargez un flux par pays, assignez la locale de chaque flux dans l'étape de configuration. ### Exemple concret Un distributeur importe un catalogue de chaussures couvrant trois pays. Après le mapping, le field locale contient : | product\_id | name | price | locale | | ----------- | ------------ | ------ | ------- | | SKU-100 | Running Shoe | 89.90 | `fr_FR` | | SKU-100 | Running Shoe | 95.00 | `fr_CH` | | SKU-100 | Running Shoe | 79.90 | `pt_PT` | | SKU-200 | Trail Shoe | 120.00 | `fr_FR` | | SKU-200 | Trail Shoe | 110.00 | `pt_PT` | Le même produit (`SKU-100`) apparaît trois fois, une par locale, chacune avec son propre prix. C'est la locale qui permet au Personalisation Engine de ne renvoyer que la ligne correspondant au pays du destinataire. ## Couche 2 — Filtrage automatique à l'exécution Lorsqu'un Workflow s'exécute, le Personalisation Engine résout **une** locale pour l'exécution, puis l'applique automatiquement. ### Comment la locale est résolue Le Personalisation Engine examine ces sources dans l'ordre et utilise la première qui fournit une valeur : | Priorité | Source | Description | | -------- | ---------------------- | ------------------------------------------------------------------------------------ | | 1 | **Node Context** | Si un node Context est sur la Branch exécutée, sa sortie `user.locale` est utilisée. | | 2 | **Datasource CRM** | Le field locale mappé sur un node Datasource CRM fournit la locale du destinataire. | | 3 | **Paramètre `rlvt-l`** | La locale passée sur le lien d'intégration (voir Couche 4). | | 4 | **Aucune** | Si rien ne résout, la locale reste vide. | Le node Context lit lui-même le field locale du CRM lorsqu'il est présent, si bien que les sources 1 et 2 concordent généralement. La distinction ne compte que lorsque le node Context n'est pas sur la Branch exécutée — le Personalisation Engine lit alors directement le node CRM. ### Comment les Datasources produit l'utilisent Un node Datasource produit ajoute automatiquement un filtre de locale à sa query — vous ne le configurez pas. Le node ne conserve que les lignes dont le field locale est égal à la locale résolue. Avec le catalogue ci-dessus, si la locale résolue est `pt_PT`, le node ne renvoie que les lignes portugaises : | product\_id | name | price | locale | | ----------- | ------------ | ------ | ------- | | SKU-100 | Running Shoe | 79.90 | `pt_PT` | | SKU-200 | Trail Shoe | 110.00 | `pt_PT` | Si aucune locale ne résout, un node Datasource produit se rabat sur le filtre `fr_FR`. Un catalogue localisé sans ligne `fr_FR` ne renverrait alors rien. Assurez-vous toujours que la locale est fournie — via un Datasource CRM, un node Context ou le paramètre `rlvt-l` — pour tout Workflow qui lit un catalogue localisé. ### Le paramètre `rlvt-l` `rlvt-l` est le paramètre d'URL réservé qui transporte la locale du visiteur dans le Workflow. Sa valeur doit toujours être une locale ISO complète au format `lang_COUNTRY` (`rlvt-l=pt_PT`). Une valeur partielle comme un simple code pays n'est pas une locale valide et ne doit pas être utilisée. ## Couche 3 — Content piloté par la locale Certains composants de Content s'adaptent à la locale résolue. L'exemple le plus clair est le fuseau horaire du **Countdown**. ### Fuseau horaire du Countdown Le [composant Countdown](/fr/product-guide/contents/components/countdown) dispose d'une option **Use user's local timezone**. Lorsqu'elle est activée, le compte à rebours se termine à la même heure locale dans chaque pays, au lieu du même instant absolu. En coulisses, activer cette option lie le countdown à `context.user.locale`. Le Personalisation Engine déduit le pays du visiteur de la locale résolue et ajuste l'heure de fin au fuseau horaire de ce pays. Par exemple, une promotion censée se terminer à 18h00 heure locale expire à 18h00 en France (`fr_FR`) et à 18h00 au Portugal (`pt_PT`), même s'il s'agit d'instants absolus différents. Comme le Countdown lit `context.user.locale`, un Workflow utilisant cette option est considéré comme multi-pays — la sélection de locale devient obligatoire à l'intégration (voir Couche 4). Le cache des clients email peut tout de même figer une image de countdown ; voir [Cache et proxies des clients email](/fr/advanced-guide/email-rendering/caching-and-proxies). ## Couche 4 — Sélection de locale obligatoire à l'intégration Le [panneau d'intégration](/fr/product-guide/workflows/integration) génère les liens que vous collez dans votre canal. Pour les Workflows multi-pays, il impose la sélection de la locale afin que les liens ne soient jamais livrés sans pays. ### Quand la sélection de locale est requise Le panneau inspecte le Workflow et marque la locale comme **obligatoire** dans l'un ou l'autre de ces cas : | Cas | Condition | Sélecteur de locale affiché | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | **Locale de Datasource** | Un Datasource produit ou CRM expose un field locale avec **plus d'une** valeur distincte. | Une liste des valeurs de locale réellement présentes dans les données (par ex. `fr_FR`, `pt_PT`). | | **Dépendance au Context** | Un Node ou un composant de Content du Workflow lit `context.user.locale` — par exemple un Countdown avec **Use user's local timezone** activé. | Un sélecteur de pays complet, car les pays possibles sont ouverts. | Une valeur de locale unique sur un Datasource ne déclenche **pas** l'obligation — avec un seul pays, il n'y a rien à choisir. ### Ce que voit l'utilisateur Tant que la sélection de locale est requise et qu'aucune locale n'est choisie, le panneau masque les liens d'intégration et affiche un message invitant l'utilisateur à choisir une locale. Une fois la locale sélectionnée, les liens apparaissent avec `rlvt-l` ajouté automatiquement. Ce verrouillage existe pour que chaque lien intégré soit attribuable à un pays dans vos statistiques. Sans lui, un Workflow multi-pays pourrait être intégré sans locale, et ses ouvertures ne seraient pas taguées par pays. ### Exemple concret Reprenez le catalogue localisé ci-dessus, utilisé par une campagne Portugal. Le Datasource produit expose trois locales (`fr_FR`, `fr_CH`, `pt_PT`), donc le panneau considère la locale comme obligatoire. L'utilisateur sélectionne `pt_PT`, et chaque lien généré se termine par `&rlvt-l=pt_PT`. À l'exécution, le Personalisation Engine lit `rlvt-l`, filtre le catalogue sur les lignes portugaises et tague l'ouverture comme `pt_PT` dans l'analyse. ## Résumé de bout en bout | Étape | Ce qui se passe | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Import** | Field locale mappé dans DataHub ; valeurs normalisées en `lang_COUNTRY`. Obligatoire pour les catalogues produit localisés. | | **Intégration** | Le panneau détecte l'usage multi-pays, impose la sélection de locale et ajoute `rlvt-l` aux liens. | | **Exécution** | Le Personalisation Engine résout la locale (node Context → Datasource CRM → `rlvt-l`), filtre les lignes produit et adapte le Content piloté par la locale. | | **Analyse** | La locale résolue est attachée à l'ouverture, de sorte que les statistiques sont ventilées par pays. | ## Pages associées * [Field Mapping](/fr/advanced-guide/datahub/field-mapping) * [Nodes Datasource](/fr/advanced-guide/workflows/data-nodes/datasources) * [URL Parameter](/fr/advanced-guide/workflows/data-nodes/url-parameter) * [Composant Countdown](/fr/product-guide/contents/components/countdown) * [Intégration du Workflow](/fr/product-guide/workflows/integration) * [Cache et proxies des clients email](/fr/advanced-guide/email-rendering/caching-and-proxies)