# General Translation Knowledge Base: Alternatives à react-intl : General Translation ou react-intl
URL: https://generaltranslation.com/fr/kb/general-translation-vs-react-intl.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: General Translation permet aux équipes React de conserver la syntaxe de messages ICU tout en y ajoutant la génération de traductions, une terminologie partagée et la relecture dans le tableau de bord. react-intl fournit le formatage et l’outillage de catalogues FormatJS ; General Translation produit en plus les traductions.
Category: Internationalisation
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

react-intl est la [bibliothèque React de FormatJS](https://formatjs.github.io/docs/react-intl). Vous rédigez chaque message directement dans le code sous forme de `defaultMessage` en ICU MessageFormat, ajoutez une `description` à l’intention des traducteurs, regroupez tous les messages dans un catalogue JSON avec `formatjs extract`, puis affichez les catalogues traduits via `IntlProvider`. La bibliothèque ne traduit rien elle-même : le catalogue extrait vous revient, ou est confié à vos traducteurs ou à un système de gestion de la traduction (TMS), et les fichiers traduits vous sont renvoyés pour être compilés. Les bibliothèques de General Translation affichent elles aussi des messages ICU, mais General Translation génère en plus les traductions.

## Les points forts de react-intl

* **ICU MessageFormat de bout en bout.** [Formes plurielles avec `#` et correspondances exactes comme `=0`, `select` et `selectordinal`](https://formatjs.github.io/docs/core-concepts/icu-syntax), le tout reposant sur les API `Intl` du navigateur.
* **Texte source intégré.** FormatJS [recommande d’écrire `defaultMessage` et `description` directement dans le code](https://formatjs.github.io/docs/getting-started/message-declaration) et de laisser `babel-plugin-formatjs` ou `@swc/plugin-formatjs` générer les identifiants des messages : personne n’a donc à inventer de clés.
* **Outillage pour un workflow TMS.** [`formatjs extract`](https://formatjs.github.io/docs/tooling/cli) génère le catalogue, des formateurs intégrés produisent des fichiers pour Crowdin, Lokalise, Smartling et Transifex, `formatjs compile` pré-analyse les messages et `formatjs verify` contrôle les catalogues pour repérer les clés manquantes ou superflues.
* **TypeScript.** [La version 12 permet de typer les arguments ICU de chaque message](https://formatjs.github.io/docs/react-intl/upgrade-guide-12.x).
* **Maintenance active.** [La version 12 est sortie en septembre 2026](https://github.com/formatjs/formatjs/blob/main/packages/react-intl/CHANGELOG.md), sous licence BSD-3-Clause.

## Ce que react-intl vous laisse à gérer

Voici une petite boîte de réception réalisée avec react-intl. Le texte anglais reste dans le composant, sous forme de `defaultMessage` :

```jsx title="Inbox.jsx"
import { FormattedMessage } from 'react-intl';

export function Inbox({ count }) {
  return (
    <section>
      <h1>
        <FormattedMessage defaultMessage="Inbox" description="Heading of the inbox page" />
      </h1>
      <p>
        <FormattedMessage
          defaultMessage="You have {count, plural, one {# unread message} other {# unread messages}}."
          description="Number of unread messages in the inbox"
          values={{ count }}
        />
      </p>
    </section>
  );
}
```

`formatjs extract` transforme ces messages en un catalogue dont les clés sont des ID générés :

```json title="lang/en.json"
{
  "U5vJOY": {
    "defaultMessage": "You have {count, plural, one {# unread message} other {# unread messages}}.",
    "description": "Number of unread messages in the inbox"
  },
  "gBGgGs": {
    "defaultMessage": "Inbox",
    "description": "Heading of the inbox page"
  }
}
```

Chaque langue cible nécessite des messages traduits dont la syntaxe ICU est préservée. `IntlProvider` accepte des chaînes de messages ou des messages précompilés ; `formatjs compile` sert à préparer ces derniers. Les descripteurs extraits contiennent chaque message accompagné de sa description. Pour obtenir les ID générés de cet exemple, configurez le plugin Babel ou SWC dans votre processus de compilation. Dans l’[App Router de Next.js](https://formatjs.github.io/docs/guides/nextjs-app-router), les composants de react-intl s’exécutent dans des composants client, tandis que le code serveur formate les messages avec `createIntl`, importé de `react-intl/server`.

## Conserver les messages ICU et générer les traductions

Les bibliothèques de General Translation remplissent le même rôle que react-intl : elles affichent les messages ICU, appliquent les règles de pluriel propres à chaque paramètre régional et formatent les nombres, les devises et les dates. Vos chaînes ICU se migrent quasiment telles quelles, car [`useGT`](/docs/react/reference/hooks/use-gt) accepte la même syntaxe :

```tsx title="Inbox.tsx"
import { useGT } from 'gt-react';

export function Inbox({ count }: { count: number }) {
  const gt = useGT();
  return (
    <section>
      <h1>{gt('Inbox', { $context: 'Heading of the inbox page' })}</h1>
      <p>
        {gt('You have {count, plural, one {# unread message} other {# unread messages}}.', {
          count,
          $context: 'Number of unread messages in the inbox',
        })}
      </p>
    </section>
  );
}
```

[`npx gt translate`](/docs/cli/reference/commands/translate) extrait ces chaînes, génère les traductions en s’appuyant sur leurs notes de contexte et écrit les catalogues cibles, le tout en une seule commande. L’exemple conserve les deux descriptions FormatJS sous forme de `$context`. Les [termes du glossaire et instructions personnalisées](/docs/platform/dashboard/guides/defining-context-for-translations) partagés orientent la terminologie et le ton, et les relecteurs peuvent modifier les résultats dans le [tableau de bord](/docs/platform/dashboard/guides/reviewing-translations).

Le `#` est formaté selon chaque paramètre régional : un nombre de 12345 s’affiche ainsi « 12,345 » en anglais et « 12.345 » en espagnol. Pour du JSX contenant du balisage, [`<T>`](/docs/react/reference/components/t) traduit l’intégralité du bloc balisé, éléments compris. Avec `gt-next`, il fonctionne directement dans les Composants serveur.

Le tableau de bord, la page d’accueil et l’application iOS de Ramp sont disponibles dans plus de 11 langues grâce à General Translation. (Voir les [déploiements en production](https://generaltranslation.com/enterprise).)

## react-intl et General Translation en un coup d’œil

| Fonctionnalité         | react-intl                                                                                                               | General Translation                                                                                                              |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- |
| Rédaction des textes   | `defaultMessage` intégré en ICU, extrait dans un catalogue JSON                                                          | JSX intégré dans [`<T>`](/docs/react/reference/components/t), ou chaînes ICU dans [`useGT`](/docs/react/reference/hooks/use-gt)  |
| Traduit votre contenu  | Non                                                                                                                      | Oui, avec [`npx gt translate`](/docs/cli/reference/commands/translate)                                                           |
| Workflow du catalogue  | Extraction des messages, traduction via le workflow de votre choix, précompilation facultative ; le plugin génère les ID | [`npx gt translate`](/docs/cli/reference/commands/translate) extrait et traduit avant votre compilation                          |
| Contexte de traduction | Le message et sa description                                                                                             | Chaînes ICU avec `$context` ; structure JSX balisée avec composants intégrés ; glossaire et instructions personnalisées partagés |
| App Router de Next.js  | Composants dans les composants client ; `createIntl` côté serveur                                                        | [`<T>`](/docs/react/reference/components/t) dans les Composants Serveur et Client                                                |
| Licence                | [BSD-3-Clause](https://github.com/formatjs/formatjs/blob/main/packages/react-intl/LICENSE.md)                            | Bibliothèques JavaScript et CLI sous licence MIT                                                                                 |

Conservez react-intl si vos catalogues ICU et vos formateurs TMS fonctionnent déjà, si vous vous appuyez sur ses arguments de message typés ou sur `formatjs verify`, ou si vous utilisez FormatJS en dehors de React. Optez pour General Translation pour continuer à rédiger en ICU tout en intégrant la génération et la relecture des traductions à votre workflow de développement.

## Migrer depuis react-intl

Migrez un composant ou une route à la fois. Remplacez chaque `<FormattedMessage>` par un appel à [`useGT`](/docs/react/reference/hooks/use-gt) qui conserve sa chaîne ICU et transmet sa description via `$context`, comme indiqué ci-dessus. Pour du JSX enrichi, utilisez [`<T context="…">`](/docs/react/reference/components/t#context). Continuez à charger les catalogues react-intl existants pour les composants que vous n’avez pas encore migrés. Une fois le dernier composant migré, supprimez le plugin FormatJS ainsi que les scripts d’extraction et de compilation. (Voir [Migrer depuis d’autres bibliothèques i18n](/docs/react/guides/migrating-i18n-libraries).)

## Autres alternatives à react-intl

Les équipes qui délaissent react-intl comparent également ces bibliothèques :

* **i18next :** affiche des catalogues à clés avec gestion du pluriel et, associé à react-i18next et next-i18next, constitue un choix courant pour les applications React et Next.js. (Voir [General Translation vs. i18next](/kb/general-translation-vs-i18next).)
* **Lingui :** conserve le texte intégré au code et compile les messages en catalogues, avec un runtime léger. (Voir [General Translation vs. Lingui](/kb/general-translation-vs-lingui).)
* **next-intl :** affiche les messages de catalogue dans les applications Next.js basées sur l&#39;App Router, y compris dans les Composants serveur. (Voir [next-intl vs. gt-next](/kb/next-intl-vs-gt-next).)
* **Paraglide JS :** compile les catalogues en fonctions de message typées et tree-shakable. (Voir [General Translation vs. Paraglide JS](/kb/general-translation-vs-paraglide).)
* **Intlayer :** regroupe le contenu de chaque composant dans un fichier de déclaration typé, où toutes les langues figurent côte à côte. (Voir [General Translation vs. Intlayer](/kb/general-translation-vs-intlayer).)

## Points clés

* react-intl formate les messages ICU et fournit des outils de gestion de catalogue ; la génération des traductions passe par un workflow distinct.
* General Translation extrait et traduit en une seule commande CLI, tout en conservant le contexte fourni par les descriptions et en mettant à la disposition des relecteurs un éditeur dans le tableau de bord.
* Vos chaînes ICU migrent presque telles quelles vers [`useGT`](/docs/react/reference/hooks/use-gt), un composant à la fois.

## Related questions

- [General Translation vs i18next, react-intl et next-intl : quelle bibliothèque d’i18n choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-i18n-libraries.mdx): Les bibliothèques open source comme i18next, react-intl et next-intl ne traduisent rien. Elles affichent les traductions que vous leur fournissez dans un fichier de catalogue par langue, rédigées par vous, vos traducteurs ou un service tiers. Les bibliothèques de General Translation sont elles aussi open source et remplissent le même rôle, mais General Translation se charge en plus de la traduction, en s’appuyant sur votre code comme contexte.
- [Alternatives à i18next : General Translation ou i18next](https://generaltranslation.com/fr/kb/general-translation-vs-i18next.mdx): Choisissez General Translation pour conserver vos textes directement dans vos composants React et générer des traductions en tirant parti de leur structure JSX et du contexte de votre produit. Vous pouvez aussi conserver i18next et utiliser General Translation pour traduire vos catalogues existants. i18next assure le rendu des messages et la sélection des formes plurielles ; la génération des traductions relève d’un service distinct.
- [General Translation ou Lingui : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-lingui.mdx): Choisissez General Translation pour conserver vos textes intégrés au code comme avec Lingui, tout en générant les traductions à partir de la structure de votre JSX comme contexte. Lingui extrait les messages intégrés dans des catalogues que vos traducteurs ou un service connecté se chargent de traduire. La CLI de General Translation met à jour les traductions au fil de l’évolution de votre code, et votre équipe les relit dans le tableau de bord.
- [General Translation ou vue-i18n : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-vue-i18n.mdx): General Translation permet aux équipes Vue d’écrire le texte source directement dans les modèles et de générer les traductions avec la CLI. Son plugin gt-vue affiche ce contenu avec une gestion des formes plurielles et un formatage des nombres adaptés au paramètre régional. Optez pour cette solution si vous ne voulez plus maintenir de fichiers sources à clés ; vue-i18n reste pertinent pour les équipes qui utilisent le module i18n de Nuxt et un workflow de catalogue bien établi.
- [Comment gérer les formes plurielles dans React ?](https://generaltranslation.com/fr/kb/how-to-handle-plurals-in-react.mdx): Ne codez pas en dur la logique de pluralisation avec des tests comme n === 1. Un petit utilitaire suffit pour une application uniquement en anglais, mais une application multilingue a besoin de règles de pluriel adaptées au paramètre régional, que prend en charge pour chaque langue un composant i18n tel que `<Plural>` de gt-react ou gt-next.

## Previous and next questions

- Previous question: [Alternatives à Phrase : General Translation ou Phrase](https://generaltranslation.com/fr/kb/general-translation-vs-phrase.mdx)
- Next question: [Alternatives à Smartling : General Translation ou Smartling](https://generaltranslation.com/fr/kb/general-translation-vs-smartling.mdx)

## Sitemap

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