---
title: "Utiliser les localisations et les codes de langue dans le SDK React Native"
description: "Découvrez comment localiser les paywalls dans votre application React Native avec le SDK Adapty."
---

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

Les codes de langue entrent en jeu quand Adapty choisit la localisation d'un flow, et quand 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 aide à anticiper 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-balises en minuscules, séparées par des traits d'union. Quelques exemples : `en` (anglais), `pt-br` (portugais (Brésil)), `zh` (chinois simplifié), `zh-hant` (chinois traditionnel).

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

Quand Adapty recherche la localisation correspondant à la locale d'un utilisateur, voici ce qui se passe :

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 recherche la localisation correspondante
4. Si aucune correspondance n'est trouvée non plus, Adapty renvoie le contenu dans la locale par défaut du flow

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

## Implémentation des localisations \{#implementing-localizations\}

Dans le SDK v4, vous ne passez pas de 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 lors de la construction de la vue du flow.

- **Flows créés dans le builder** : le SDK ne lit pas les paramètres régionaux de l'appareil, vous devez donc les résoudre dans votre application et les passer via le paramètre `locale` de `createFlowView`, ou dans la prop `params` du composant intégré `AdaptyFlowView`. Ce paramètre est facultatif — si vous l'omettez, le flow s'affiche en `en`, ou dans sa [locale par défaut](add-paywall-locale-in-adapty-paywall-builder#set-the-default-locale) si le flow ne dispose pas de localisation `en`. Si vous demandez une localisation que le flow ne possède pas, la vue revient silencieusement à la locale par défaut, et les chaînes manquantes dans la localisation choisie sont tirées de cette locale par défaut.

  ```typescript showLineNumbers
  import { createFlowView } from 'react-native-adapty';

  const view = await createFlowView(flow, { locale: 'es' });
  ```

`view.locale` indique la localisation avec laquelle la vue a été réellement construite — la locale que vous avez demandée si cette localisation existe, ou la locale par défaut du flow sinon. Le paramètre `locale` et `view.locale` nécessitent le SDK React Native 4.0.2 ou version ultérieure, et `view.locale` est `undefined` sur les versions antérieures.
- **Paywalls personnalisés (Remote Config)** : `getFlow` renvoie chaque localisation configurée dans `flow.remoteConfigs`. Chaque entrée contient un code `lang` et un objet `data`. Sélectionnez l'entrée correspondant à l'utilisateur, avec votre propre mécanisme de fallback :

```typescript showLineNumbers

const flow = await adapty.getFlow('placement_id');
const config = flow.remoteConfigs?.find((c) => c.lang === 'en') ?? flow.remoteConfigs?.[0];
// read your values from config?.data
```

Les règles de correspondance des codes de locale décrites ci-dessus expliquent comment Adapty normalise les codes `lang` stockés dans chaque Remote Config.

---

> [!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 langue entrent en jeu dans plusieurs situations — par exemple, lorsque vous souhaitez récupérer le bon paywall pour la localisation actuelle de votre application.

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

## 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-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\}

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

1. La chaîne de langue reçue est convertie en minuscules et tous les underscores (`_`) sont remplacés par des tirets (`-`)
2. On recherche ensuite la localisation dont le code de langue 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 aucune correspondance n'est encore trouvée, on renvoie le contenu dans la langue 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.

## Mise en œuvre des localisations : méthode recommandée \{#implementing-localizations-recommended-way\}

Si vous vous interrogez sur les localisations, il y a de bonnes chances que vous gériez 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 :

```javascript showLineNumbers
// 1. Modify your localization files (e.g., using react-i18next)

/*
en.json
*/
{
  "adapty_paywalls_locale": "en"
}

/*
es.json
*/
{
  "adapty_paywalls_locale": "es"
}

/*
pt-BR.json
*/
{
  "adapty_paywalls_locale": "pt-br"
}

// 2. Extract and use the locale code

const MyComponent = () => {
  const { t } = useTranslation();
  
  const fetchPaywall = async () => {
    const locale = t('adapty_paywalls_locale');
    // pass locale code to adapty.getPaywall or adapty.getPaywallForDefaultAudience method
    const paywall = await adapty.getPaywallForDefaultAudience('placement_id', locale);
  };
};
```

C'est ainsi que vous vous assurez d'avoir un contrôle total sur la localisation qui sera récupérée pour chaque utilisateur de votre application.

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

Vous pouvez obtenir des résultats similaires (mais pas identiques) sans définir explicitement les codes de langue pour chaque localisation. Cela implique d'extraire un code de langue depuis l'appareil, par exemple via [`react-native-localize`](https://github.com/zoontek/react-native-localize) :

```javascript showLineNumbers

const fetchPaywall = async () => {
  // getLocales() returns the user's preferred locales in BCP-47 format (e.g., 'en-US', 'pt-BR')
  const locale = RNLocalize.getLocales()[0].languageTag;
  // pass locale code to adapty.getPaywall or adapty.getPaywallForDefaultAudience method
  const paywall = await adapty.getPaywallForDefaultAudience('placement_id', locale);
};
```

Notez que nous ne recommandons pas cette approche pour plusieurs raisons :

1. Sur iOS, les langues préférées et la locale régionale actuelle ne sont pas identiques. Pour que la localisation soit correctement sélectionnée, vous devrez soit vous appuyer sur la logique de résolution d'Apple — qui fonctionne nativement avec l'approche recommandée utilisant des fichiers de chaînes localisées — soit la recréer vous-même.
2. La locale de l'appareil peut ne correspondre à aucune localisation configurée dans Adapty. Dans ce cas, le SDK utilise en priorité une correspondance sur le premier sous-tag ou, en dernier recours, `en` — ce qui n'est peut-être pas la langue par défaut souhaitée pour cet utilisateur.

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

---