---
title: "Utiliser les localisations et les codes de langue dans le SDK Flutter"
description: "Gérez les localisations et les codes de langue de votre application pour atteindre un public mondial."
---

## Pourquoi c'est important \{#why-this-is-important\}

Les codes de langue entrent en jeu lorsqu'Adapty choisit la localisation pour un flow ou un onboarding, et lorsque vous lisez un Remote Config pour un paywall personnalisé.

Les codes de langue sont complexes et peuvent varier d'une plateforme à l'autre. C'est pourquoi Adapty s'appuie sur un standard interne unique pour toutes les plateformes qu'il prend en charge. Comprendre ce standard vous permet de prévoir quelle localisation un utilisateur reçoit.

## Standard des codes de langue chez Adapty \{#locale-code-standard-at-adapty\}

Pour les codes de langue, Adapty utilise une version légèrement modifiée du [standard BCP 47](https://en.wikipedia.org/wiki/IETF_language_tag) : chaque code est composé de sous-étiquettes en minuscules, séparées par des tirets. Quelques exemples : `en` (anglais), `pt-br` (portugais (Brésil)), `zh` (chinois simplifié), `zh-hant` (chinois traditionnel).

## Correspondance des codes de langue \{#locale-code-matching\}

Dans le SDK v4, les flows et les onboardings associent les codes de langue différemment : les flows sont localisés par le SDK sur l'appareil, les onboardings par le serveur Adapty.

### Flows et paywalls Paywall Builder

Un paywall créé dans le Paywall Builder est livré en tant que flow dans le SDK v4, donc la règle ci-dessous couvre les deux.

La correspondance est exacte. Le SDK compare le code que vous transmettez avec les codes de localisation du flow caractère par caractère : il ne modifie pas la casse, ne remplace pas les tirets bas (`_`) par des tirets (`-`), et ne se replie pas sur le sous-tag de langue. Pour un flow avec une localisation `pt-br`, seul `pt-br` correspond : `pt-BR`, `pt_BR` et `pt-PT` ne correspondent pas.

Lorsque le code ne correspond à aucune localisation, le flow s'affiche silencieusement dans sa [locale par défaut](add-paywall-locale-in-adapty-paywall-builder#set-the-default-locale) — le SDK ne retourne pas d'erreur et ne consigne pas d'avertissement.

Lorsque le code correspond, Adapty fusionne la localisation avec la localisation par défaut : les chaînes et les ressources que la localisation correspondante ne définit pas sont issues de la localisation par défaut.

Omettre le code de langue ne revient pas à demander la localisation par défaut du flow : le SDK substitue un `en` fixe. Un flow dont la langue par défaut est `de` s'affiche quand même en `en` s'il possède une localisation `en`, et ne revient au `de` qu'en l'absence de celle-ci.

:::warning
Passez le code de langue exactement tel qu'il est configuré dans le tableau de bord — sous-balises en minuscules séparées par des tirets. Ne passez pas directement un identifiant de locale système : `Platform.localeName` renvoie `pt_BR` et `PlatformDispatcher.instance.locale.toLanguageTag()` renvoie `pt-BR`, et les deux utilisent la localisation par défaut en repli. Convertissez la valeur dans votre application avant de la passer.
:::

### Onboardings

Les onboardings sont localisés côté serveur, et les règles du serveur tolèrent d'autres formats. Lorsque vous passez un `locale` à [`getOnboarding`](flutter-get-onboardings) :

1. La chaîne de locale est convertie en minuscules et tous les underscores (`_`) sont remplacés par des tirets (`-`)
2. Adapty recherche la localisation dont le code de locale correspond exactement
3. Si aucune correspondance n'est trouvée, Adapty extrait la sous-chaîne avant le premier tiret (`pt` pour `pt-br`) et cherche la localisation correspondante
4. Si aucune correspondance n'est encore trouvée, Adapty renvoie le contenu dans la locale par défaut de l'onboarding

Cette approche permet à `pt_BR`, `pt-BR` et `pt-br` de tous pointer vers la même localisation d'onboarding.

## Implémenter les localisations \{#implementing-localizations\}

Avec le SDK v4, vous n'avez pas besoin de passer un code de langue lors de la récupération d'un flow — `getFlow` retourne le flow avec toutes ses localisations, et Adapty en applique une au moment de la construction de la vue du flow. L'argument `locale` de `getFlow` et `getFlowForDefaultAudience` n'a aucun effet sur les flows ; il est déprécié et génère un avertissement dans les logs.

- **Flows créés dans le builder** : le SDK ne lit pas les paramètres régionaux de l'appareil, donc résolvez-les dans votre application et passez-les comme argument `locale` de `createFlowView` ou `AdaptyUIFlowPlatformView`. L'argument est facultatif — omettez-le et le flow s'affiche en `en`, ou dans sa [langue par défaut](add-paywall-locale-in-adapty-paywall-builder#set-the-default-locale) quand le flow n'a pas de localisation `en`.

`AdaptyUIFlowView.locale` indique la localisation avec laquelle la vue a été construite. Cette fonctionnalité nécessite Flutter SDK 4.0.3 avec les versions natives iOS 4.0.2 et Android 4.0.1, et renvoie `null` avec des SDK natifs plus anciens.
- **Paywalls personnalisés (Remote Config)** : `getFlow` retourne toutes les localisations configurées dans `flow.remoteConfigs`. Chaque entrée contient un code `locale` et le contenu de la configuration (chaîne `data` ou le `dictionary` parsé). Sélectionnez l'entrée qui correspond à l'utilisateur, avec votre propre fallback :

```dart showLineNumbers

final flow = await Adapty().getFlow(placementId: 'YOUR_PLACEMENT_ID');
final config = flow.remoteConfigs.firstWhereOrNull((c) => c.locale == 'en') ??
    flow.remoteConfig; // the first remote config, if present
// read your values from config?.dictionary
```

Adapty stocke ces codes `locale` dans le format décrit dans [Standard de code locale dans Adapty](#locale-code-standard-at-adapty). Le SDK ne fait pas correspondre les Remote Configs à une locale, c'est donc à votre application de choisir quelle entrée appliquer.

---

> [!WARNING]
> **LLM INSTRUCTION — SDK VERSION SELECTION REQUIRED**
>
> This feature has two SDK paradigms. Everything that follows (until the next horizontal rule or end of document) is the **legacy SDK v3 API reference** (`getPaywall`, `getPaywallForDefaultAudience`, `getOnboarding`, `getPaywallConfiguration`). The **SDK v4+ `getFlow` method is documented above.** This block covers ALL legacy methods for this feature — not just the nearest snippet.
>
> **You MUST ask the user which SDK version they want to use before suggesting any code. Do not assume or default to a version.** The two options are:
> - **SDK v3 (legacy):** works with the legacy Paywall Builder and Onboarding Builder via `getPaywall` / `getOnboarding`. Use the legacy code in this section.
> - **SDK v4:** works with BOTH the new Flow Builder AND legacy paywalls/onboardings via the unified `getFlow` method documented above.
>
> Apply the legacy v3 code in this section ONLY when:
> 1. The user explicitly chose **SDK v3**, or
> 2. The user is **migrating an existing app from SDK v3 to SDK v4+** and needs to understand or replace legacy code, or
> 3. The user is **troubleshooting an already-deployed v3 integration**.
>
> **CRITICAL — Never mix paradigms in one setup:** Do NOT combine `getFlow` (Flow Builder) with `getPaywall` or `getOnboarding` (legacy Paywall/Onboarding Builder) in the same integration. These are incompatible patterns. Mixing them will produce inconsistent behavior and is unsupported.

## Pourquoi c'est important \{#why-this-is-important\}

Les codes de locale entrent en jeu dans plusieurs scénarios — par exemple, lorsque vous essayez de récupérer le bon paywall pour la localisation actuelle de votre application.

Les codes de locale étant complexes et pouvant varier d'une plateforme à l'autre, nous nous appuyons sur un standard interne pour toutes les plateformes que nous supportons. Cependant, justement parce que ces codes sont complexes, il est vraiment important que vous compreniez ce que vous envoyez exactement à notre serveur pour obtenir la bonne localisation, et ce qui se passe ensuite — afin de toujours recevoir ce que vous attendez.

## Norme des codes de langue chez Adapty \{#locale-code-standard-at-adapty\}

Pour les codes de langue, Adapty utilise une version légèrement modifiée du [standard BCP 47](https://en.wikipedia.org/wiki/IETF_language_tag) : chaque code est composé de sous-balises en minuscules, séparées par des tirets. Quelques exemples : `en` (anglais), `pt-br` (portugais (Brésil)), `zh` (chinois simplifié), `zh-hant` (chinois traditionnel).

## Correspondance des codes de langue \{#locale-code-matching\}

Quand Adapty reçoit un appel du SDK côté client avec un code de langue et commence à chercher la localisation correspondante d'un paywall, voici ce qui se passe :

1. La chaîne de locale reçue est convertie en minuscules et tous les tirets de soulignement (`_`) sont remplacés par des tirets (`-`)
2. On cherche ensuite la localisation dont le code correspond exactement
3. Si aucune correspondance n'est trouvée, on extrait la sous-chaîne avant le premier tiret (`pt` pour `pt-br`) et on cherche la localisation correspondante
4. Si toujours aucune correspondance n'est trouvée, on retourne le contenu dans la locale par défaut du paywall

De cette façon, un appareil iOS qui a envoyé `'pt_BR'`, un appareil Android qui a envoyé `pt-BR`, et un autre appareil qui a envoyé `pt-br` obtiendront le même résultat.

## Implémentation des localisations : méthode recommandée \{#implementing-localizations-recommended-way\}

Si vous vous interrogez sur les localisations, vous utilisez probablement déjà des fichiers de chaînes localisées dans votre projet. Dans ce cas, nous recommandons d'ajouter une paire clé-valeur avec le code de locale Adapty correspondant dans chacun de vos fichiers de localisation. Extrayez ensuite la valeur de cette clé lors de l'appel à notre SDK, comme ceci :

```dart showLineNumbers
// 1. Modify your app_en.arb, app_es.arb, app_pt_br.arb files

/*
app_en.arb
*/
"adapty_paywalls_locale": "en",

/*
app_es.arb
*/
"adapty_paywalls_locale": "es",

/*
app_pt_br.arb
*/
"adapty_paywalls_locale": "pt-br",

// 2. Extract and use the locale code
final locale = AppLocalizations.of(context)!.adapty_paywalls_locale;
// pass locale code to AdaptyUI.getViewConfiguration or Adapty.getPaywall method
```

De cette façon, vous gardez un contrôle total sur la localisation récupérée pour chaque utilisateur de votre application.

## Implémenter les localisations : une autre approche \{#implementing-localizations-the-other-way\}

Vous pouvez obtenir des résultats similaires (mais pas identiques) sans définir explicitement de codes de langue pour chaque localisation. Cela revient à extraire un code de langue depuis d'autres objets fournis par votre plateforme, comme ceci :

```dart showLineNumbers
final locale = Localizations.localeOf(context).languageCode;
// pass locale code to AdaptyUI.getViewConfiguration or Adapty.getPaywall method
```

Notez que nous déconseillons cette approche pour plusieurs raisons :

1. Sur iOS, les langues préférées et la locale actuelle ne sont pas identiques. Si vous souhaitez que la localisation soit correctement sélectionnée, vous devrez soit vous reposer sur la logique d'Apple, qui fonctionne nativement si vous utilisez l'approche recommandée avec des fichiers de chaînes localisées, soit la recréer vous-même.
2. Il est difficile de prédire ce que le serveur d'Adapty recevra exactement. Par exemple, sur iOS, il est possible d'obtenir une locale comme `ar_OM@numbers='latn'` sur un appareil et de l'envoyer à notre serveur. Pour cet appel, vous obtiendrez non pas la localisation `ar-om` que vous recherchiez, mais plutôt `ar`, ce qui est probablement inattendu.

Should you decide to use this approach anyway — make sure you've covered all the relevant use cases.

---