# General Translation Knowledge Base: General Translation ou Lingui : lequel choisir ?
URL: https://generaltranslation.com/fr/kb/general-translation-vs-lingui.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 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.
Category: Internationalisation
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

Côté rédaction, l’approche de Lingui est proche de celle de General Translation. Vous écrivez `<Trans>Inbox</Trans>` dans un composant, les macros de Lingui le compilent en un message ICU doté d’un ID généré, `lingui extract` produit des catalogues PO, et `lingui compile` transforme les catalogues traduits en modules JavaScript légers. L’étape que Lingui laisse de côté, c’est la traduction elle-même : sa documentation propose de [modifier les catalogues à la main ou de les synchroniser avec Crowdin ou Translation.io](https://lingui.dev/tools/introduction). General Translation conserve lui aussi les textes intégrés au code, mais se charge en plus de générer les traductions.

## Les points forts de Lingui

* **Source intégrée grâce aux macros.** La macro `<Trans>` et [les macros de Lingui](https://lingui.dev/ref/macro) dédiées aux formes plurielles et aux simples chaînes de caractères gardent le texte anglais dans le composant et se compilent en ICU MessageFormat : personne n&#39;a donc à écrire de clés.
* **Une exécution légère.** Les messages sont compilés à l&#39;avance, et Lingui évalue son exécution à [environ 2 ko](https://lingui.dev/introduction) selon ses propres mesures.
* **Des catalogues compatibles avec Gettext.** [PO est le format par défaut](https://lingui.dev/ref/catalog-formats), `lingui extract` fusionne les nouveaux messages dans chaque paramètre régional et marque les messages supprimés comme obsolètes, tandis que les champs `context` et `comment` sont transmis aux traducteurs.
* **Composants serveur.** [Depuis la version 4.10](https://lingui.dev/tutorials/react-rsc), `<Trans>` et `useLingui` fonctionnent côté serveur dès lors que chaque page ou layout appelle `setI18n`.
* **Développement actif.** [La version 6 est sortie en avril 2026](https://lingui.dev/blog/2026/04/22/announcing-lingui-6.0) (ESM uniquement, Node.js 22.19 ou version ultérieure), sous licence MIT.

## Ce que Lingui vous laisse gérer

Voici une petite boîte de réception écrite avec les macros React de Lingui :

```jsx title="Inbox.jsx"
import { Trans, Plural } from '@lingui/react/macro';

export function Inbox({ count }) {
  return (
    <section>
      <h1>
        <Trans>Inbox</Trans>
      </h1>
      <p>
        <Trans>
          You have <Plural value={count} one="# unread message" other="# unread messages" />.
        </Trans>
      </p>
    </section>
  );
}
```

`lingui extract` ajoute les nouveaux messages de la langue cible aux catalogues PO, avec des traductions vides. Vos traducteurs ou un service connecté complètent ensuite ces entrées en conservant la syntaxe ICU. Voici le catalogue espagnol une fois cette étape terminée :

```text title="locales/es/messages.po"
#: src/Inbox.jsx:7
msgid "Inbox"
msgstr "Bandeja de entrada"

#: src/Inbox.jsx:10
msgid "You have {count, plural, one {# unread message} other {# unread messages}}."
msgstr "Tienes {count, plural, one {# mensaje sin leer} other {# mensajes sin leer}}."
```

Ensuite, [`lingui compile`](https://lingui.dev/ref/cli) transforme le catalogue en un module chargé par l&#39;application. Ce cycle d&#39;extraction, de traduction et de compilation se répète à chaque modification, les macros nécessitent une [transformation à la compilation](https://lingui.dev/installation) (le plugin Babel de Lingui, son plugin Vite ou un plugin SWC expérimental), et la personne chargée de la traduction travaille à partir de l&#39;entrée PO et de ses commentaires, et non à partir du composant.

## Conservez le texte intégré et laissez General Translation produire les catalogues

Les bibliothèques de General Translation reprennent le même principe de rédaction directement dans le code : le texte reste dans [`<T>`](/docs/react/reference/components/t), les formes du pluriel se placent dans [`<Plural>`](/docs/react/reference/components/plural), et [`<Num>`](/docs/react/reference/components/num) formate les valeurs selon chaque paramètre régional. General Translation fait ensuite ce que Lingui ne fait pas : il génère les traductions. Voici la même boîte de réception avec `gt-react` :

```tsx title="Inbox.tsx"
import { T, Plural, Num } from 'gt-react';

export function Inbox({ count }: { count: number }) {
  return (
    <T>
      <section>
        <h1>Inbox</h1>
        <Plural
          n={count}
          singular={<p>You have <Num>{count}</Num> unread message.</p>}
          plural={<p>You have <Num>{count}</Num> unread messages.</p>}
        />
      </section>
    </T>
  );
}
```

[`npx gt translate`](/docs/cli/reference/commands/translate) envoie chaque bloc [`<T>`](/docs/react/reference/components/t) avec sa structure d’éléments et génère les catalogues cibles avant votre compilation. Les branches source `singular` et `plural` fournissent la formulation nécessaire aux formes requises par chaque langue cible. [`<Plural>`](/docs/react/reference/components/plural) sélectionne la branche traduite à l’exécution. Les chaînes situées hors JSX passent par [`useGT`](/docs/react/reference/hooks/use-gt), l’équivalent de la macro de chaînes de Lingui.

Dans cet exemple, le titre de la boîte de réception et les branches du message sont envoyés ensemble en traduction. Vous pouvez également ajouter une [note de `context`](/docs/react/reference/components/t#context) pour préciser une signification propre au produit. Les relecteurs modifient le texte généré dans l’[Éditeur de Traduction du tableau de bord](/docs/platform/dashboard/guides/reviewing-translations) ; la prochaine exécution de la CLI réutilise les traductions inchangées et génère les nouveaux textes, sans commande distincte de compilation des catalogues.

La plateforme et la documentation de Profound sont disponibles dans plus de 47 paramètres régionaux grâce à General Translation. (Voir les [déploiements en production](https://generaltranslation.com/enterprise).)

## Lingui et General Translation en un coup d’œil

| Fonctionnalité               | Lingui                                                                                                                | General Translation                                                                                                           |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| Rédaction des textes         | Macros intégrées comme `<Trans>`                                                                                      | JSX intégré dans [`<T>`](/docs/react/reference/components/t), et chaînes dans [`useGT`](/docs/react/reference/hooks/use-gt)   |
| Traduction de votre contenu  | Non                                                                                                                   | Oui, avec [`npx gt translate`](/docs/cli/reference/commands/translate)                                                        |
| Étapes à chaque modification | Extraction, traduction de chaque catalogue PO, compilation, avec une transformation des macros lors de la compilation | [`npx gt translate`](/docs/cli/reference/commands/translate) avant la compilation                                             |
| Catalogues                   | Fichiers PO par paramètre régional, compilés en modules JavaScript                                                    | Générés par paramètre régional, stockés dans votre dépôt ou sur le CDN de General Translation                                 |
| Ce que voit le traducteur    | Le message, ainsi que les champs `context` et `comment`                                                               | La structure des blocs JSX balisés, les notes de contexte, ainsi que le glossaire et les instructions personnalisées partagés |

Conservez Lingui si vos traducteurs travaillent avec des catalogues PO gettext, si son exécution compilée et minimale est importante pour la taille de votre bundle, ou si votre processus de traduction fonctionne déjà. Optez pour General Translation si vous souhaitez conserver la rédaction directement dans le code sans le cycle extraction-traduction-compilation, et obtenir des traductions générées en tenant compte du contexte de votre code.

## Migrer depuis Lingui

Migrez un composant ou une route à la fois. Le `<Trans>` de Lingui correspond à [`<T>`](/docs/react/reference/components/t). Son `<Plural value={count} one="…" other="…" />` correspond à [`<Plural>`](/docs/react/reference/components/plural) avec `n={count}` et les branches `singular` et `plural`, ainsi qu’à [`<Num>`](/docs/react/reference/components/num) pour le nombre. Sa macro pour les chaînes de caractères correspond à [`useGT`](/docs/react/reference/hooks/use-gt). Continuez à charger les traductions Lingui existantes pour les composants que vous n’avez pas encore migrés. Une fois le dernier composant migré, supprimez la transformation de macro ainsi que les scripts d’extraction et de compilation. (Voir [Migrer depuis d’autres bibliothèques i18n](/docs/react/guides/migrating-i18n-libraries).)

## Points clés

* Lingui conserve les textes intégrés au code et compile une exécution légère ; ce sont des traducteurs ou un service connecté qui fournissent chaque catalogue cible.
* Les bibliothèques de General Translation reposent sur la même rédaction directement dans le code, mais General Translation se charge aussi de la traduction, en tenant compte du contexte de votre code et sans cycle de catalogue.
* Les macros de Lingui correspondent étroitement à [`<T>`](/docs/react/reference/components/t), [`<Plural>`](/docs/react/reference/components/plural) et [`useGT`](/docs/react/reference/hooks/use-gt) : vous pouvez donc migrer composant par composant.

## 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.
- [Alternatives à react-intl : General Translation ou react-intl](https://generaltranslation.com/fr/kb/general-translation-vs-react-intl.mdx): 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.
- [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.
- [Peut-on faire de l’i18n sans fichiers de traduction ?](https://generaltranslation.com/fr/kb/i18n-without-translation-files.mdx): Oui. Avec gt-react ou gt-next, le contenu reste intégré dans vos composants, à l’intérieur d’un composant `<T>`, et les traductions sont générées lors du build. Il n’y a donc ni clés ni fichiers JSON par paramètre régional à écrire et à garder synchronisés.

## Previous and next questions

- Previous question: [General Translation ou le framework de traduction de Django : avez-vous besoin des deux ?](https://generaltranslation.com/fr/kb/general-translation-vs-django-i18n.mdx)
- Next question: [General Translation ou Locize : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-locize.mdx)

## Sitemap

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