---
title: "Utiliser les localisations et codes de locale dans le SDK Android"
description: "Gérez les localisations et codes de locale de votre application pour toucher une audience mondiale (Android)."
---

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

Les codes de langue entrent en jeu quand Adapty choisit la localisation pour 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. Adapty s'appuie donc sur un standard interne unique pour toutes les plateformes qu'il prend en charge. Comprendre ce standard vous permet de prédire quelle localisation un utilisateur recevra.

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

Lorsqu'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 tirets bas (`_`) 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 à nouveau, Adapty renvoie le contenu dans la langue par défaut du flow

Cette façon de procéder 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 transmettez pas de code de langue lors de la récupération d'un flow — `getFlow` retourne le flow avec toutes ses localisations.

- **Flows créés dans le builder** : le SDK ne lit pas la locale de l'appareil, vous devez donc la résoudre dans votre application et la passer comme argument `locale` de `AdaptyUI.getFlowConfiguration`. L'argument est optionnel — omettez-le et 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 n'a pas de localisation `en`. Si vous demandez une localisation que le flow ne possède pas, la vue revient à la valeur par défaut du flow sans erreur, et les chaînes manquantes dans la localisation choisie sont reprises de la locale par défaut.

Le rendu en `en` par défaut nécessite le SDK Android 4.0.1. Dans la version 4.0.0, l'omission de `locale` affiche la localisation par défaut du flow.
- **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 (`jsonString`, ou le `dataMap` parsé). Sélectionnez l'entrée correspondant à l'utilisateur, avec votre propre logique de repli :

```kotlin showLineNumbers
Adapty.getFlow("YOUR_PLACEMENT_ID") { result ->
    when (result) {
        is AdaptyResult.Success -> {
            val flow = result.value
            val config = flow.remoteConfigs.firstOrNull { it.locale == "en" }
                ?: flow.remoteConfigs.firstOrNull()
            // read your values from config?.dataMap
        }
        is AdaptyResult.Error -> {
            // handle the error
        }
    }
}
```

Les règles de correspondance des codes de paramètres régionaux décrites ci-dessus expliquent comment Adapty normalise les codes `locale` 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\}

Il existe plusieurs situations où les codes de langue entrent en jeu — par exemple, lorsque vous essayez de récupérer le bon paywall pour la localisation actuelle de votre application.

Les codes de langue étant complexes et pouvant varier d'une plateforme à l'autre, nous nous appuyons sur un standard interne pour toutes les plateformes que nous prenons en charge. Cependant, en raison de cette complexité, 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 que vous receviez toujours ce que vous attendez.

## Standard de code 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-tags en minuscules, séparés 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 underscores (`_`) sont remplacés par des tirets (`-`)
2. On cherche ensuite la localisation dont le code de locale 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 trouvée non plus, on renvoie le contenu dans la locale par défaut du paywall

Ainsi, 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, vous travaillez probablement déjà avec des fichiers de chaînes localisées dans votre projet. Dans ce cas, nous vous recommandons d'ajouter une paire clé-valeur avec le code de locale Adapty correspondant dans chacun de vos fichiers de localisation. Ensuite, récupérez la valeur de cette clé lors de l'appel à notre SDK, comme ceci :

```kotlin showLineNumbers
// 1. Modify your strings.xml files

/*
strings.xml - Spanish
*/
<string name="adapty_paywalls_locale">es</string>

/*
strings.xml - Portuguese (Brazil)
*/
<string name="adapty_paywalls_locale">pt-br</string>

// 2. Extract and use the locale code

val localeCode = context.getString(R.string.adapty_paywalls_locale)
// pass locale code to AdaptyUI.getViewConfiguration or Adapty.getPaywall method
```

Vous contrôlez ainsi entièrement la localisation qui sera récupérée pour chaque utilisateur de votre application.

## Implémenter les localisations : l'autre méthode \{#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. Il s'agirait d'extraire un code de langue depuis d'autres objets fournis par votre plateforme, comme ceci :

```kotlin showLineNumbers
val locale = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N)
    context.resources.configuration.locales[0]
else
    context.resources.configuration.locale

val localeCode = locale.toLanguageTag()
// pass locale code to AdaptyUI.getViewConfiguration or Adapty.getPaywall method
```

Notez que nous ne recommandons pas cette approche car il est difficile de prévoir exactement ce que le serveur d'Adapty recevra.

Si vous décidez tout de même d'utiliser cette approche, assurez-vous d'avoir couvert tous les cas d'utilisation pertinents.

---