# General Translation Knowledge Base: Que sont les codes de paramètres régionaux, comme en-US et en-GB ?
URL: https://generaltranslation.com/fr/kb/locale-codes.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Un code de paramètre régional identifie une langue et, si nécessaire, son système d’écriture et sa région, par exemple en-US pour l’anglais des États-Unis ou zh-Hant-TW pour le chinois traditionnel de Taïwan. La plupart des logiciels utilisent des étiquettes BCP 47 construites à partir de codes ISO. General Translation utilise des codes BCP 47 pour les paramètres régionaux source et cibles dans gt.config.json.
Category: Formatage selon les paramètres régionaux
Last updated: 2026-10-28
Authors: General Translation Team
Published: 2026-10-28

Un code de paramètre régional désigne une langue et, si nécessaire, son système d’écriture et la région où elle est parlée. `en-US` correspond à l’anglais des États-Unis, `en-GB` à l’anglais du Royaume-Uni, et `zh-Hant-TW` au chinois en caractères traditionnels tel qu’il est utilisé à Taïwan. Les navigateurs, HTTP, HTML et les API `Intl` de JavaScript s’appuient tous sur la même norme pour ces codes, BCP 47 : le code que vous choisissez détermine donc la traduction, le format de date et les règles de pluriel proposés à l’utilisateur.

## Structure d&#39;une balise BCP 47

[BCP 47](https://www.rfc-editor.org/info/bcp47) est la norme de l&#39;IETF pour les balises de langue. Elle réunit la [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646.html), qui en définit la syntaxe, et la [RFC 4647](https://www.rfc-editor.org/rfc/rfc4647.html), qui définit la mise en correspondance des balises. Une balise est une suite de sous-balises séparées par des tirets, toujours dans cet ordre :

| Sous-balise          | Forme                                                 | Origine                                | Exemples                                         |
| -------------------- | ----------------------------------------------------- | -------------------------------------- | ------------------------------------------------ |
| Langue (obligatoire) | 2 ou 3 lettres                                        | ISO 639, code le plus court disponible | `en`, `zh`, `gsw`                                |
| Système d’écriture   | 4 lettres                                             | ISO 15924                              | `Hant`, `Hans`, `Latn`, `Cyrl`                   |
| Région               | 2 lettres ou 3 chiffres                               | ISO 3166-1 alpha-2 ou UN M.49          | `GB`, `BR`, `419`                                |
| Variante             | 5 à 8 caractères, ou un chiffre suivi de 3 caractères | Enregistrée auprès de l&#39;IANA       | `de-1901` (orthographe allemande traditionnelle) |
| Extension            | Une seule lettre, suivie de ses sous-balises          | `u` est définie par Unicode            | `ar-EG-u-nu-latn`                                |
| Usage privé          | `x`, suivi de vos propres sous-balises                | Vous                                   | `en-CA-x-ca`                                     |

Toutes les sous-balises valides figurent dans l&#39;[IANA Language Subtag Registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry), la référence unique pour rechercher un code. Son édition de septembre 2026 recense 8 276 sous-balises de langue et 305 sous-balises de région, et indique pour chaque code retiré le code qui le remplace.

En combinant ces éléments, vous exprimez exactement ce que vous voulez dire. `sr-Latn-RS` désigne le serbe écrit en alphabet latin, tel qu&#39;il est utilisé en Serbie. `es-419` désigne l&#39;espagnol d&#39;Amérique latine et des Caraïbes, `419` étant un code UN M.49 qui désigne une région regroupant plusieurs pays. La RFC 5646 donne un exemple plus subtil : `de-CH` désigne l&#39;allemand tel qu&#39;il est pratiqué en Suisse (allemand standard suisse), tandis que le suisse allemand (Schweizerdeutsch) est une langue distincte, dotée de son propre code : `gsw-CH`.

### Les extensions modifient le formatage, pas la langue

L&#39;extension `-u-`, définie dans la [RFC 6067](https://www.rfc-editor.org/rfc/rfc6067.html) et dont les clés sont répertoriées dans la [spécification LDML d&#39;Unicode](https://unicode.org/reports/tr35/), véhicule des préférences de formatage. `-u-nu-` sélectionne le système de numération, `-u-hc-` le cycle horaire, `-u-ca-` le calendrier et `-u-co-` l&#39;ordre de tri. `en-US-u-hc-h23` reste de l&#39;anglais américain ; seul l&#39;affichage change : `14:05` au lieu de `2:05 PM`. L&#39;exemple plus bas illustre les deux cas.

## Casse, traits d’union et tirets bas

Les tags ne sont pas sensibles à la casse : `EN-gb` et `en-GB` désignent donc la même chose. La RFC 5646 [recommande néanmoins une convention](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1.1) : la langue en minuscules, le système d’écriture avec une majuscule initiale et la région en majuscules, comme dans `zh-Hant-TW`. Normalisez le code sous cette forme avant de l’utiliser dans un nom de fichier ou une URL, afin que `/en-gb/` et `/en-GB/` ne deviennent pas deux chemins distincts.

BCP 47 sépare les sous-balises par des traits d’union. Plusieurs plateformes utilisent leurs propres formats ; effectuez donc la conversion au point d’interface avec chacune d’elles :

| Système                                                                                            | Format                                                                                   | Exemple                            |
| -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ---------------------------------- |
| Web (HTML `lang`, `hreflang`, `Accept-Language`, `Intl`)                                           | BCP 47 avec traits d’union                                                               | `en-US`, `zh-Hant-TW`              |
| [POSIX](https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html) (`LANG`, `LC_*`) | `language[_territory][.codeset][@modifier]`                                              | `en_US.UTF-8`                      |
| [Unicode CLDR](https://unicode.org/reports/tr35/) et identifiants de paramètres régionaux ICU      | Tirets bas ; traits d’union également acceptés                                           | `en_US`                            |
| [Java](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Locale.html)         | `toString()` renvoie des tirets bas, `toLanguageTag()` renvoie du BCP 47                 | `en_US`, `en-US`                   |
| [Ressources Android](https://developer.android.com/guide/topics/resources/providing-resources)     | `r` devant la région, ou `b+` pour les tags BCP 47 (Android 7.0 et versions ultérieures) | `values-en-rUS`, `values-b+es+419` |

JavaScript rejette la forme avec tiret bas : `Intl.getCanonicalLocales('en_US')` lève une exception `RangeError`.

## Erreurs courantes

* **`en-UK` au lieu de `en-GB`.** Le code de région ISO du Royaume-Uni est `GB`, et `UK` ne figure pas dans le registre de l’IANA. Unicode CLDR traite `UK` comme un alias, si bien que JavaScript convertit silencieusement `en-UK` en `en-GB`, mais [Google ignore](https://developers.google.com/search/docs/specialty/international/localized-versions) `UK` dans hreflang. Écrivez `en-GB`.
* **Un code de pays à la place du code de langue.** `jp`, `cn`, `gr`, `dk` et `cz` ne sont pas des codes de langue : le japonais est `ja`, le chinois `zh`, le grec `el`, le danois `da` et le tchèque `cs`. Certains codes de pays désignent même de tout autres langues : `se` correspond au same du Nord (le suédois est `sv`), `kr` au kanouri (le coréen est `ko`), `uk` à l’ukrainien et `be` au biélorusse. Les vérifications syntaxiques acceptent `jp` parce qu’il compte deux lettres ; vérifiez donc les codes dans le registre au lieu de vous contenter du fait qu’ils sont analysables.
* **`zh-CN` alors que vous visez le chinois simplifié.** En chinois, c’est le système d’écriture qui change le texte écrit, et la région ne fait qu’en suggérer un : `zh-TW` se développe en `zh-Hant-TW` et `zh-SG` en `zh-Hans-SG`. Lorsqu’une même traduction en chinois simplifié couvre la Chine continentale et Singapour, étiquetez-la `zh-Hans` ; utilisez `zh-Hant` pour le chinois traditionnel, et ajoutez une région, par exemple `zh-Hant-HK`, lorsque la formulation diffère.
* **Codes retirés.** `iw` (hébreu), `in` (indonésien) et `ji` (yiddish) ont été dépréciés en 1989 au profit de `he`, `id` et `yi`. Les versions de Java antérieures à la 17 produisaient encore les anciennes formes, si bien qu’on les retrouve dans des données anciennes. La canonicalisation les remplace.
* **Des étiquettes trop détaillées.** `en-Latn-US` précise un système d’écriture que l’anglais utilise presque toujours. La RFC 5646 [recommande](https://www.rfc-editor.org/rfc/rfc5646.html#section-4.1) d’omettre les sous-balises qui n’apportent aucune information distinctive, et précise qu’avec le filtrage de base, une requête pour `en-US` ne correspondra pas à un contenu étiqueté `en-Latn-US`.
* **Des codes valides qu’un outil ne prend pas en charge.** `es-419` est un code BCP 47 valide, mais le hreflang de Google n’accepte que les régions ISO 3166-1 ; annotez donc ces pages avec `es` ou avec des pays précis. (Voir [Qu’est-ce que hreflang ?](/kb/what-is-hreflang).)

## Générique ou régional : quel code utiliser ?

Dans ses conseils sur le [choix des balises de langue](https://www.w3.org/International/questions/qa-choosing-language-tags), le W3C recommande de garder les balises aussi courtes que possible et de n’ajouter une région que lorsqu’elle apporte une information utile. Déclinez ce principe en règle pour chaque paramètre régional :

* **Utilisez la langue seule** (`fr`, `de`, `ja`) lorsqu’une même traduction convient à toutes les régions où elle est parlée.
* **Ajoutez une région** lorsque l’orthographe, le vocabulaire ou les textes juridiques diffèrent et que vous comptez maintenir des traductions distinctes : `en-US` et `en-GB`, `pt-BR` et `pt-PT`, `es-MX` et `es-ES`, `fr-CA`.
* **Choisissez d’abord le système d’écriture pour le chinois, le serbe et les autres langues qui en utilisent plusieurs** : `zh-Hans` et `zh-Hant`, `sr-Cyrl` et `sr-Latn`.
* **Utilisez un code régional pour le formatage, même lorsque la traduction est partagée.** Un texte traduit une seule fois en `en` peut tout de même formater les dates selon le paramètre `en-GB` du visiteur, qui écrit 28/10/2026 là où `en-US` écrit 10/28/2026.

Pour un logiciel, un code sans région n’est pas pour autant dépourvu de région. Les données de sous-balises probables (likely subtags) du CLDR ajoutent le système d’écriture et la région les plus probables : `pt` devient ainsi `pt-Latn-BR`, et `zh` devient `zh-Hans-CN`. Si votre traduction `pt` est en portugais européen, étiquetez-la `pt-PT`.

Lorsque le paramètre régional d’un utilisateur ne fait pas partie de ceux que vous prenez en charge, le logiciel applique un mécanisme de repli. La [recherche](https://www.rfc-editor.org/rfc/rfc4647.html#section-3.4) définie par la RFC 4647 retire les sous-balises une à une en partant de la fin jusqu’à trouver une correspondance (`zh-Hant-HK`, puis `zh-Hant`, puis `zh`), tandis que d’autres algorithmes de correspondance testent aussi les régions voisines. La lecture des préférences du navigateur et le choix entre ces algorithmes sont traités dans [comment détecter la langue du navigateur d’un utilisateur](/kb/detect-user-language).

## Normaliser les codes en JavaScript

[`Intl.getCanonicalLocales`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/getCanonicalLocales) corrige la casse et remplace les sous-balises obsolètes ou définies comme alias, tandis que [`Intl.Locale`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale) permet de compléter le système d’écriture et la région les plus probables :

```js title="locale-codes.mjs"
const names = new Intl.DisplayNames(['en'], { type: 'language' });

for (const tag of ['EN-gb', 'zh-tw', 'iw-IL', 'en-UK', 'jp', 'es-419', 'en_US']) {
  try {
    // Canonicaliser : corriger la casse et remplacer les sous-balises obsolètes ou définies comme alias
    const [canonical] = Intl.getCanonicalLocales(tag);
    // Ajouter le système d’écriture et la région probables
    const maximized = new Intl.Locale(canonical).maximize().toString();
    console.log(`${tag} -> ${canonical} (${maximized}): ${names.of(canonical)}`);
  } catch (error) {
    console.log(`${tag} -> ${error.name}: ${error.message}`);
  }
}

// Une extension -u- modifie le formatage, pas la langue
const time = new Date(Date.UTC(2026, 9, 28, 14, 5));
for (const tag of ['en-US', 'en-US-u-hc-h23', 'ar-EG', 'ar-EG-u-nu-latn']) {
  const formatted = new Intl.DateTimeFormat(tag, {
    hour: 'numeric',
    minute: '2-digit',
    timeZone: 'UTC',
  }).format(time);
  console.log(`${tag}: ${formatted}`);
}
```

Sortie de `node locale-codes.mjs` sous Node.js 24.19.0 :

```text title="Output"
EN-gb -> en-GB (en-Latn-GB): British English
zh-tw -> zh-TW (zh-Hant-TW): Chinese (Taiwan)
iw-IL -> he-IL (he-Hebr-IL): Hebrew (Israel)
en-UK -> en-GB (en-Latn-GB): British English
jp -> jp (jp): jp
es-419 -> es-419 (es-Latn-419): Latin American Spanish
en_US -> RangeError: Incorrect locale information provided
en-US: 2:05 PM
en-US-u-hc-h23: 14:05
ar-EG: ٢:٠٥ م
ar-EG-u-nu-latn: 2:05 م
```

Deux lignes méritent qu’on s’y attarde. `jp` passe la canonicalisation et ressort sans nom d’affichage, car la vérification porte sur la syntaxe, et non sur l’existence de la langue. Quant à `ar-EG-u-nu-latn`, il conserve l’écriture arabe tout en passant aux chiffres occidentaux.

## Comment General Translation utilise les codes de paramètres régionaux

General Translation utilise systématiquement les codes BCP 47. Dans `gt.config.json`, [`defaultLocale`](/docs/cli/reference/config#default-locale) désigne le paramètre régional dans lequel votre contenu source est rédigé (`en` par défaut), et [`locales`](/docs/cli/reference/config#locales) répertorie les paramètres régionaux cibles :

```json title="gt.config.json"
{
  "defaultLocale": "en-US",
  "locales": ["en-GB", "fr-CA", "pt-BR", "zh-Hant"]
}
```

La CLI vérifie ces codes avant toute traduction. Elle s&#39;arrête sur un code non valide, ainsi que lorsque `defaultLocale` est plus large qu&#39;une cible : une traduction de `en` vers `en-GB` échoue. C&#39;est pourquoi un projet qui ajoute l&#39;anglais britannique définit sa source sur `en-US`, comme ci-dessus.

La plateforme traduit vers les paramètres régionaux figurant dans sa liste des [paramètres régionaux pris en charge](/docs/platform/dashboard/reference/supported-locales). General Translation traite généralement les codes équivalents comme un seul et même paramètre régional : `fr`, `fr-FR` et `fr-Latn-FR` recevraient la même traduction, et `ja` et `ja-JP` mettent à jour la même traduction stockée. (Voir [Comprendre les codes de paramètres régionaux](/docs/platform/core/guides/locale-codes).)

Pour utiliser un code qui ne correspond pas à une langue enregistrée, comme `cn` dans vos URL, le paramètre [`customMapping`](/docs/cli/reference/config#custom-mapping) de General Translation en fait un alias d&#39;un code standard (`cn` vers `zh`) et permet de remplacer son nom d’affichage. Pour hreflang, le [guide SEO sur les alias de paramètres régionaux](/docs/react/nextjs/locale-alias-seo) fait de nouveau correspondre l&#39;alias à `zh`.

La bibliothèque Core `generaltranslation` exporte des utilitaires de paramètres régionaux sous forme de fonctions autonomes, qui ne nécessitent aucune clé API. Les valeurs de retour ci-dessous proviennent de `generaltranslation` 9.5.8 :

```js title="check-locales.mjs"
import {
  standardizeLocale,
  isValidLocale,
  getLocaleName,
  determineLocale,
} from 'generaltranslation';

standardizeLocale('EN-gb'); // 'en-GB'
isValidLocale('en_US'); // false
isValidLocale('jp'); // false
getLocaleName('pt-BR', 'en'); // 'Brazilian Portuguese'
determineLocale(['fr-CA', 'en-US'], ['en', 'fr', 'zh-Hant']); // 'fr'
```

[`standardizeLocale`](/docs/platform/core/reference/utility-functions/locales/standardize-locale) corrige la casse, [`isValidLocale`](/docs/platform/core/reference/utility-functions/locales/is-valid-locale) rejette les formes avec trait de soulignement ainsi que les codes comme `jp` que `Intl` accepte, [`getLocaleName`](/docs/platform/core/reference/utility-functions/locales/get-locale-name) renvoie un nom d’affichage destiné à un sélecteur de langue, et [`determineLocale`](/docs/platform/core/reference/utility-functions/locales/determine-locale) sélectionne la meilleure correspondance prise en charge en fonction des préférences de l&#39;utilisateur — ici, en proposant votre traduction `fr` à un utilisateur francophone du Canada.

## Questions fréquentes

### Quelle est la différence entre un code de langue et un code de paramètre régional ?

Un code de langue se compose d’une seule sous-balise, comme `en` ou `pt`. Un code de paramètre régional peut y ajouter un système d’écriture et une région, comme `pt-BR` ; il détermine donc également le formatage des dates, des nombres et des devises.

### Faut-il écrire en-GB ou en-UK ?

`en-GB`. `GB` est le code ISO 3166-1 du Royaume-Uni ; `UK` n&#39;est pas une sous-balise de région enregistrée, et Google l&#39;ignore dans les attributs hreflang.

### Dois-je utiliser zh-CN ou zh-Hans ?

Utilisez `zh-Hans` pour un texte en chinois simplifié destiné à plusieurs régions, et réservez `zh-CN` aux contenus propres à la Chine continentale. Dans les deux cas, le système d’écriture résolu est le chinois simplifié.

### Les codes de paramètres régionaux sont-ils sensibles à la casse ?

Non. `en-us` et `en-US` désignent la même balise, mais privilégiez `en-US` pour que les noms de fichiers, les URL et les clés restent cohérents.

## Points clés à retenir

* Un code de langue BCP 47 se compose d’une sous-balise de langue suivie, facultativement, de sous-balises de système d’écriture, de région, de variante et d’extension, dans cet ordre, séparées par des traits d’union : `zh-Hant-TW`, `es-419`, `en-US-u-hc-h23`.
* Vérifiez les codes dans le registre de l’IANA : `en-GB` et non `en-UK` ; `ja` et non `jp` ; `he` et non `iw`.
* Privilégiez des balises courtes, n’ajoutez une région que si le contenu varie selon la région, et pour le chinois, choisissez d’abord le système d’écriture.
* Effectuez la conversion aux frontières du système : POSIX, ICU et la méthode `toString()` de Java utilisent des traits de soulignement, tandis qu’Android utilise `values-b+es+419`.
* General Translation lit les codes BCP 47 dans les champs `defaultLocale` et `locales` de `gt.config.json`, rejette tout paramètre régional source plus large qu’un paramètre régional cible et prend en charge les alias via `customMapping`.

## Related questions

- [Comment détecter la langue du navigateur d’un utilisateur ?](https://generaltranslation.com/fr/kb/detect-user-language.mdx): Lisez la liste ordonnée des langues du navigateur (navigator.languages en JavaScript ou l’en-tête Accept-Language côté serveur), triée par valeur q, puis mettez-la en correspondance avec vos paramètres régionaux pris en charge, en prévoyant une solution de secours. Safari et la navigation privée de Chrome n’indiquent qu’une seule langue, et la géolocalisation par IP révèle l’emplacement, pas la langue.
- [Qu’est-ce que hreflang et comment le configurer ?](https://generaltranslation.com/fr/kb/what-is-hreflang.mdx): Hreflang indique à Google quelles URL correspondent aux versions linguistiques ou régionales d’une même page, afin qu’il affiche la bonne dans les résultats de recherche. Ajoutez-le à l’aide de balises link HTML, d’en-têtes HTTP Link ou d’un plan de site, veillez à ce que chaque lien soit réciproque et utilisez des codes valides comme en-GB, et non en-UK.
- [Internationalisation et localisation (i18n et l10n)](https://generaltranslation.com/fr/kb/internationalization-vs-localization.mdx): L’internationalisation (i18n) désigne le travail de code et de conception qui permet à un même produit de prendre en charge de nombreux paramètres régionaux, par exemple le formatage des dates avec Intl ou la prise en charge du texte right-to-left. La localisation (l10n) l’adapte à un paramètre régional donné, ce qui englobe la traduction, mais aussi la devise, les formats de date, les unités, le ton et les aspects juridiques.
- [Comment formater les nombres, les dates et les devises pour chaque paramètre régional ?](https://generaltranslation.com/fr/kb/format-numbers-dates-currencies.mdx): Formatez chaque valeur au moment de l’affichage de la page, avec le paramètre régional du lecteur et l’API Intl de JavaScript, et laissez-la en dehors de la phrase traduite. Les composants `<Num>`, `<Currency>`, `<DateTime>` et `<RelativeTime>` de General Translation font les deux à l’intérieur d’un `<T>` : une seule traduction suffit ainsi pour toutes les valeurs.
- [Sous-répertoire, sous-domaine ou ccTLD pour le SEO multilingue](https://generaltranslation.com/fr/kb/multilingual-url-structure.mdx): Utilisez des sous-répertoires comme example.com/de/ lorsqu’un même produit partage un site et un processus de livraison. Seul un ccTLD signale un pays, les sous-domaines permettent un hébergement distinct, Google déconseille les paramètres ?lang= et considère les domaines « de complaisance » comme .io et .ai comme génériques.

## Previous and next questions

- Previous question: [Qu’est-ce qu’une mémoire de traduction, et en avez-vous encore besoin avec l’IA ?](https://generaltranslation.com/fr/kb/what-is-translation-memory.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.
