# General Translation Knowledge Base: Alternatives à i18next : General Translation ou i18next URL: https://generaltranslation.com/fr/kb/general-translation-vs-i18next.mdx Docs index: https://generaltranslation.com/llms.txt Description: 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. Category: Internationalisation Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 i18next charge les fichiers de traduction, sélectionne le message correspondant à la langue de l’utilisateur, résout les formes du pluriel, interpole les valeurs et met en forme les nombres et les dates avec `Intl`. Disponible sur npm depuis 2012, il s’est imposé, avec `react-i18next` et `next-i18next`, comme un choix courant pour les applications React et Next.js. En revanche, i18next ne traduit pas : chaque message, dans chaque langue, doit être fourni par vous, par vos traducteurs ou par un service comme Locize, [géré par les créateurs d’i18next](https://www.i18next.com/). Les bibliothèques de General Translation assurent le même travail de rendu, mais General Translation génère en plus les traductions à partir des textes de vos composants. ## Les points forts d’i18next * **Adoption.** C’est l’un des frameworks i18n JavaScript les plus utilisés. * **Polyvalence.** [Des bindings existent pour React, Vue, Angular, Svelte et bien d’autres](https://www.i18next.com/overview/supported-frameworks), et des plugins permettent de charger des fichiers via HTTP, de détecter la langue de l’utilisateur et de passer les messages en ICU MessageFormat avec `i18next-icu`. * **Prise en charge complète des formes plurielles et du contexte.** Les clés comportent des [suffixes de pluriel CLDR](https://www.i18next.com/translation-function/plurals) tels que `_one`, `_few` et `_many`, résolus avec `Intl.PluralRules`, ainsi que des variantes de contexte telles que `friend_male`. * **Outillage.** L’outil officiel [`i18next-cli`](https://github.com/i18next/i18next-cli) extrait les clés, génère des types TypeScript et écrit les clés de pluriel de chaque paramètre régional ; sa commande `status` renvoie une erreur lorsqu’un paramètre régional contient des clés non traduites, ce qui permet à la CI de repérer les traductions manquantes. * **Composants serveur.** [`next-i18next` 16](https://github.com/i18next/next-i18next) ajoute une fonction de traduction server-side pour l’App Router de Next.js. * **Aucun service imposé.** Les catalogues sont de simples fichiers JSON qui vous appartiennent, et i18next fonctionne avec n’importe quel service de traduction, voire sans aucun. ## Ce que i18next vous laisse gérer Voici une petite boîte de réception réalisée avec react-i18next. Chaque chaîne de caractères a sa clé, et chaque forme du pluriel a également la sienne : ```json title="locales/en/translation.json" { "inbox": { "title": "Inbox", "unread_one": "You have {{count}} unread message.", "unread_other": "You have {{count}} unread messages." } } ``` ```tsx title="Inbox.tsx" import { useTranslation } from 'react-i18next'; export function Inbox({ count }: { count: number }) { const { t } = useTranslation(); return (

{t('inbox.title')}

{t('inbox.unread', { count })}

); } ``` Toutes les autres langues ont besoin des mêmes clés de message, avec les formes du pluriel qui leur sont propres : le polonais requiert `unread_one`, `unread_few`, `unread_many` et `unread_other`. Si un fichier polonais ne contient que les formes `_one` et `_other` calquées sur l'anglais et que votre [langue de secours](https://www.i18next.com/principles/fallback) est l'anglais, des valeurs comme 2 ou 5 s'afficheront en anglais : ```text title="Output" pl, count 1: Masz 1 nieprzeczytaną wiadomość. pl, count 2: You have 2 unread messages. pl, count 5: You have 5 unread messages. pl, count 22: You have 22 unread messages. ``` Exécuter `i18next-cli status` dans la CI permet de repérer les formes manquantes. Les services de traduction peuvent générer le contenu des catalogues ; votre application, elle, continue de faire référence à des clés comme `inbox.unread`, et c'est le workflow de traduction et d'extraction qui maintient ces catalogues à jour. ## General Translation garde le texte intégré au code et génère les traductions Les bibliothèques de General Translation remplissent le même rôle qu'i18next. Elles sélectionnent les messages de chaque paramètre régional, appliquent ses règles de pluriel, interpolent les variables et formatent les nombres, les devises et les dates avec [``](/docs/react/reference/components/num), [``](/docs/react/reference/components/currency) et [``](/docs/react/reference/components/datetime). Les équipes qui préfèrent les clés peuvent conserver des dictionnaires avec [`useTranslations`](/docs/react/reference/hooks/use-translations). Mais General Translation va plus loin qu'i18next : 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 (

Inbox

You have {count} unread message.

} plural={

You have {count} unread messages.

} />
); } ``` [`npx gt translate`](/docs/cli/reference/commands/translate) envoie chaque bloc [``](/docs/react/reference/components/t), avec sa structure d’éléments, à l’API de General Translation avant votre compilation, puis génère une traduction pour chaque paramètre régional cible. Les branches source génériques `singular` et `plural` fournissent la formulation nécessaire aux formes requises par chaque langue cible. [``](/docs/react/reference/components/plural) sélectionne ensuite une branche traduite selon les règles propres à ce paramètre régional. Une valeur encapsulée dans [``](/docs/react/reference/components/var) n’est jamais envoyée à l’API. Lorsque vous modifiez une phrase dans [``](/docs/react/reference/components/t), la prochaine exécution de traduction la met à jour dans chaque langue et réutilise les traductions existantes pour le contenu inchangé. Les relecteurs travaillent dans l’[Éditeur de Traduction du tableau de bord](/docs/platform/dashboard/guides/reviewing-translations) : il n’est donc pas nécessaire de modifier les composants pour corriger les traductions. Les bibliothèques JavaScript sont sous licence MIT et fonctionnent sans compte si vous fournissez vous-même les traductions. Une application configurée pour charger toutes ses traductions depuis son bundle n’effectue aucun appel à General Translation à l’exécution. `gt-react` et `gt-next` ne reposent sur aucune autre bibliothèque d’i18n. Cursor déploie plus de 14 paramètres régionaux sur son site web et sa documentation grâce à General Translation. (Voir les [déploiements en production](https://generaltranslation.com/enterprise).) ## i18next et General Translation en un coup d’œil | Fonctionnalité | i18next | General Translation | | -------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Rédaction des textes | Clés dans des fichiers JSON par langue et par espace de noms | JSX dans [``](/docs/react/reference/components/t), chaînes via [`useGT`](/docs/react/reference/hooks/use-gt), ou dictionnaires à clés | | Traduit votre contenu | Non | Oui, avec [`npx gt translate`](/docs/cli/reference/commands/translate) | | Provenance des traductions | Vous, des traducteurs ou un service tel que Locize | Générées à partir du contexte de votre code, ou rédigées par votre équipe | | Formes du pluriel | Une clé par forme CLDR, à rédiger pour chaque langue | Branches [``](/docs/react/reference/components/plural), traduites avec le reste du bloc | | Contexte de traduction | Messages source et contexte fournis par votre workflow de traduction | La structure des blocs JSX balisés, les notes de contexte, ainsi que le glossaire et les instructions personnalisées partagés | | Frameworks | React, Next.js et des bindings pour Vue, Angular, Svelte, etc. | React, Next.js, Vue, Node.js et [d’autres SDK](/docs/overview/get-started) | | Compte requis | Non | Pas pour les bibliothèques ; la traduction passe par un projet General Translation | Conservez i18next si vos catalogues et votre processus de traduction fonctionnent déjà, si vous développez avec un framework que les bibliothèques de General Translation ne prennent pas en charge, ou si vous souhaitez des clés qui restent stables lorsque les textes évoluent. Optez pour General Translation si vous voulez des textes intégrés directement dans vos composants, des traductions générées à partir du contexte de votre code et toutes vos langues à jour à chaque compilation. ## Conservez i18next et laissez General Translation s'occuper de la traduction Inutile de changer de bibliothèque. La CLI `gt` détecte `i18next` dans votre `package.json` et préserve sa syntaxe d'interpolation. Voici une configuration permettant de traduire en allemand le catalogue de la boîte de réception ci-dessus : ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["de"], "files": { "json": { "include": ["locales/[locale]/translation.json"] } } } ``` L'anglais et l'allemand utilisent la même structure de clés de pluriel `_one` et `_other`. Cette configuration génère `locales/de/translation.json` à partir de `locales/en/translation.json`. Pour ajouter du contexte propre à chaque clé, par exemple l'endroit où une chaîne de caractères apparaît, utilisez les [métadonnées associées aux clés](/docs/cli/reference/keyed-metadata). Exécutez [`npx gt upload`](/docs/cli/reference/commands/upload) pour importer vos sources et vos traductions existantes, puis [`npx gt translate`](/docs/cli/reference/commands/translate) pour traduire les nouveaux textes. Pour passer plutôt à [``](/docs/react/reference/components/t), suivez le guide [Migrer depuis des bibliothèques i18n](/docs/react/guides/migrating-i18n-libraries). Il explique comment remplacer les recherches par clé par du texte intégré, conserver vos dictionnaires avec [`useTranslations`](/docs/react/reference/hooks/use-translations) et faire cohabiter les deux bibliothèques le temps de migrer une route après l'autre. (Consultez [General Translation vs. i18next, react-intl et next-intl](/kb/general-translation-vs-i18n-libraries) pour comparer i18next aux autres solutions.) ## Comment gérer le polonais et les autres langues riches en formes plurielles dans i18next ? Chaque langue nécessite une clé pour chaque forme du pluriel CLDR qu'elle utilise, par exemple `_one`, `_few`, `_many` et `_other` pour le polonais. Exécutez `i18next-cli status` dans votre CI pour repérer les formes manquantes. Avec la rédaction directement dans le code proposée par General Translation, il vous suffit d'écrire les branches `singular` et `plural` présentées ci-dessus : le service de traduction génère les formes cibles. [``](/docs/react/reference/components/plural) sélectionne ensuite la forme appropriée à l'exécution. ## Autres alternatives à i18next Les équipes qui quittent i18next comparent également ces bibliothèques : * **react-intl :** met en forme les messages ICU et fournit l'outillage de catalogues FormatJS. (Voir [General Translation vs. react-intl](/kb/general-translation-vs-react-intl).) * **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 des catalogues dans les applications Next.js utilisant l'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 messages 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é, avec toutes les langues côte à côte. (Voir [General Translation vs. Intlayer](/kb/general-translation-vs-intlayer).) ## Points clés * i18next effectue le rendu de catalogues indexés par clés et gère la sélection des formes plurielles ; les traductions sont produites par des personnes ou par un service connecté. * Les bibliothèques de General Translation affichent les traductions de la même manière, mais General Translation se charge en plus de la traduction, à partir du texte rédigé directement (intégré) dans [``](/docs/react/reference/components/t). * Vous pouvez conserver i18next et laisser la CLI `gt` traduire ses fichiers JSON, ou migrer progressivement vers [``](/docs/react/reference/components/t), une route à 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 à 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 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 `` de gt-react ou gt-next. ## Previous and next questions - Previous question: [Alternatives à Google Translate : General Translation vs Google Translate](https://generaltranslation.com/fr/kb/general-translation-vs-google-translate.mdx) - Next question: [Alternatives à Lokalise : General Translation ou Lokalise](https://generaltranslation.com/fr/kb/general-translation-vs-lokalise.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.