# General Translation Knowledge Base: Faut-il développer votre propre i18n ou utiliser General Translation ? URL: https://generaltranslation.com/fr/kb/general-translation-vs-in-house-i18n.mdx Docs index: https://generaltranslation.com/llms.txt Description: Une i18n faite maison (un dictionnaire par langue et un petit utilitaire t()) suffit pour une ou deux langues et un peu de texte. À mesure que l’application grandit, vous finissez par réécrire les règles de pluriel, les solutions de repli et la synchronisation des fichiers, et il vous reste à produire les traductions. Les bibliothèques open source de General Translation gèrent l’affichage, et General Translation génère et met à jour les traductions à partir de votre code. Category: Internationalisation Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 Vous pouvez développer vous-même l’internationalisation (i18n) : un objet de messages par langue, un utilitaire `t()` qui recherche une clé et insère les variables, un sélecteur de paramètre régional, et les API `Intl` intégrées pour les nombres et les dates. Pour une ou deux langues et quelques dizaines de chaînes, cela suffit souvent, et c’est généralement ce qu’un agent de codage produira si vous lui demandez d’ajouter une langue. Ce qui s’alourdit avec l’application, c’est tout ce qui gravite autour de l’utilitaire : les règles de pluriel, les clés manquantes, la synchronisation de chaque fichier de langue avec le code et, avant tout, la production de chaque traduction. Les bibliothèques open source de General Translation prennent en charge la partie exécution de ce travail, et General Translation génère et met à jour les traductions à partir de votre code. ## Quand une i18n faite maison suffit * **Aucune dépendance tierce.** Le dictionnaire et l’utilitaire vous appartiennent, et vous maîtrisez chaque ligne. * **La plateforme se charge du formatage.** `Intl.NumberFormat`, `Intl.DateTimeFormat`, `Intl.PluralRules` et `Intl.Locale` sont [intégrés aux navigateurs modernes et à Node.js](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl) et formatent les devises, les dates et les catégories de pluriel selon le paramètre régional. * **Des textes courts et stables.** Pour un prototype, un outil interne ou un site proposant une seule langue supplémentaire rédigée par un collègue, inutile d’aller plus loin. * **Des langues dont le pluriel fonctionne comme en anglais.** L’anglais et l’allemand n’utilisent que [`one` et `other`](https://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html). ## Ce qui ne tient plus quand le projet grandit Voici une première version typique, à laquelle on a ajouté un dictionnaire polonais : ```js title="i18n.mjs" const messages = { en: { greeting: 'Hello, {name}!', files: { one: '{count} file', other: '{count} files' }, checkout: 'Checkout', }, pl: { greeting: 'Cześć, {name}!', files: { one: '{count} plik', other: '{count} pliki' }, // « checkout » n'est pas encore traduit }, }; export function t(locale, key, vars = {}) { let message = messages[locale][key]; if (typeof message === 'object') { message = vars.count === 1 ? message.one : message.other; } return message.replace(/\{(\w+)\}/g, (_, name) => vars[name]); } console.log(t('pl', 'greeting', { name: 'Ania' })); console.log([1, 2, 5].map((count) => t('pl', 'files', { count })).join(', ')); console.log(t('pl', 'checkout')); ``` En l'exécutant avec Node.js 24 : ```text title="Output" Cześć, Ania! 1 plik, 2 pliki, 5 pliki TypeError: Cannot read properties of undefined (reading 'replace') ``` Deux bugs surviennent simultanément. "5 pliki" est incorrect (en polonais, on dit "5 plików"), et la clé `checkout` non traduite fait planter l'affichage. La plateforme fournit tout ce qu'il faut pour corriger ces deux problèmes : ```js title="intl.mjs" // Catégories de pluriel par langue for (const locale of ['en', 'ja', 'pl', 'ar']) { console.log(locale, new Intl.PluralRules(locale).resolvedOptions().pluralCategories.join(' ')); } const pl = new Intl.PluralRules('pl'); console.log([1, 2, 5, 22].map((n) => `${n} → ${pl.select(n)}`).join(', ')); // Devises et dates const date = new Date(Date.UTC(2026, 9, 16)); for (const locale of ['en-US', 'de-DE', 'ja-JP']) { const price = new Intl.NumberFormat(locale, { style: 'currency', currency: 'EUR' }).format(1234.5); const day = new Intl.DateTimeFormat(locale, { dateStyle: 'long', timeZone: 'UTC' }).format(date); console.log(locale, price, day); } // Sens du texte console.log(new Intl.Locale('ar').getTextInfo().direction); ``` ```text title="Output" en one other ja other pl one few many other ar zero one two few many other 1 → one, 2 → few, 5 → many, 22 → few en-US €1,234.50 October 16, 2026 de-DE 1.234,50 € 16. Oktober 2026 ja-JP €1,234.50 2026年10月16日 rtl ``` Chaque correctif est minime, mais, mis bout à bout, ils pèsent lourd : * **Formes plurielles.** `n === 1` ne fonctionne pas pour le polonais (quatre catégories) ni pour l’arabe (six). L’utilitaire doit donc s’appuyer sur [`Intl.PluralRules`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/PluralRules), et chaque dictionnaire doit contenir une chaîne de caractères par catégorie. (Voir [Comment gérer les formes plurielles dans React ?](/kb/how-to-handle-plurals-in-react)) * **Ordre des mots.** Les espaces réservés tels que `{name}` permettent à chaque langue de placer la valeur où elle le souhaite. Ce n’est pas le cas de la concaténation : `t('by') + ' ' + author` place le nom à la fin, alors que le japonais écrit « Ana 著 ». * **Formatage.** `{count}` insère le nombre brut ; l’utilitaire doit donc aussi recourir à [`Intl.NumberFormat`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat) pour afficher 12,500 sous la forme « 12 500 » en polonais. * **Clés manquantes.** L’utilitaire a besoin d’une chaîne de solutions de repli (langue cible, puis source, puis la clé), faute de quoi les utilisateurs voient `undefined` ou l’application plante. * **Synchronisation des fichiers.** Rien ne vous signale que `pl` ne contient pas `checkout` ou conserve la formulation du mois dernier, jusqu’à ce qu’un utilisateur s’en aperçoive. * **Langues s’écrivant de droite à gauche.** L’arabe et l’hébreu nécessitent `lang` et `dir="rtl"` sur la page, ainsi qu’une mise en page en miroir. * **Moteurs de recherche.** Un sélecteur qui conserve le choix dans l’état ou dans un cookie laisse toutes les langues sur une seule URL, alors que Google recommande une URL par langue ([Gérer les sites multilingues](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)). (Voir [Comment configurer le SEO d’une application Next.js multilingue ?](/kb/multilingual-nextjs-seo)) * **Les traductions.** Aucun utilitaire ne supprime ce coût : quelqu’un doit écrire « plików » et toutes les autres chaînes de caractères dans chaque langue, puis recommencer à chaque modification du texte anglais. Une fois que l’utilitaire gère les catégories de pluriel, les solutions de repli et le formatage des nombres, vous avez écrit le cœur d’une bibliothèque d’i18n, et il vous manque encore les traductions. ## Ce que General Translation propose à la place General Translation conserve ce qui fonctionne dans l'approche artisanale (un texte lisible et le formatage natif de la plateforme) et prend en charge les parties qui prennent de l'ampleur. Avec `gt-react` (ou `gt-next` pour Next.js), le texte reste dans le composant, à l'intérieur de [``](/docs/react/reference/components/t), si bien qu'il n'y a ni dictionnaire ni utilitaire à maintenir : ```tsx title="Inbox.tsx" import { T, Plural, Num, Var } from 'gt-react'; export function Inbox({ name, count }: { name: string; count: number }) { return (

Welcome back, {name}

You have {count} unread message.

} plural={

You have {count} unread messages.

} /> ); } ``` [``](/docs/react/reference/components/plural) choisit une branche selon les règles de pluriel CLDR de chaque paramètre régional, les mêmes que celles qu'utilise `Intl.PluralRules` : plus de `n === 1` sur lequel se tromper. [``](/docs/react/reference/components/num) formate le nombre selon le paramètre régional du lecteur, et la valeur contenue dans [``](/docs/react/reference/components/var) n'est jamais envoyée à l'API de General Translation. Voici le composant affiché côté serveur avec `gt-react` 11.4.12, avec une traduction espagnole saisie à la main dans le modèle [`gt generate`](/docs/cli/reference/commands/generate) à titre d'illustration (sans les séparateurs de texte de React) : ```html title="Output"

Welcome back, Ana

You have 12,500 unread messages.

Hola de nuevo, Ana

Tienes 12.500 mensajes sin leer.

``` Lorsqu’un paramètre régional n’a pas de traduction pour un bloc, [``](/docs/react/reference/components/t) affiche le contenu source, et non `undefined` ou une erreur. Mais le vrai changement, c’est que General Translation produit lui-même les traductions : * **Générées avec leur contexte.** [`npx gt translate`](/docs/cli/reference/commands/translate) envoie chaque bloc [``](/docs/react/reference/components/t) avec ses éléments, ses variables, ses branches de pluriel et l’éventuelle note [`context`](/docs/react/reference/components/t#context), puis écrit un fichier par paramètre régional. Un glossaire fixe la terminologie et des instructions personnalisées définissent le ton pour tous les projets qui partagent un même groupe de contexte. (Voir [Définir le contexte des traductions](/docs/platform/dashboard/guides/defining-context-for-translations).) * **Toujours synchronisées.** Chaque exécution traduit le contenu nouveau ou modifié et réutilise les traductions existantes pour le reste. Lancez-la dans votre CI, ou laissez [Locadex](/docs/platform/locadex/quickstart), l’agent IA de General Translation, ouvrir des pull requests selon les déclencheurs de votre choix. Pour les applications Next.js et React, Locadex peut aussi encapsuler les textes existants dans [``](/docs/react/reference/components/t). * **Relues par des humains.** Votre équipe modifie les traductions dans le tableau de bord. (Voir [Relire et modifier les traductions](/docs/platform/dashboard/guides/reviewing-translations).) * **Sens d’écriture et routage.** [`useLocaleDirection`](/docs/react/reference/hooks/use-locale-direction) renvoie `'rtl'` pour l’arabe, et `gt-next` peut servir chaque paramètre régional sur sa propre URL grâce à son [middleware](/docs/react/nextjs/app-router-middleware). Les bibliothèques JavaScript sont sous licence MIT et fonctionnent sans compte General Translation 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. Pour générer les traductions, utilisez le service hébergé, avec une [tarification à l’usage](https://generaltranslation.com/pricing). À l’autre bout de l’échelle, Profound publie sa plateforme et sa documentation dans plus de 47 paramètres régionaux grâce à General Translation. (Voir [déploiements en production](https://generaltranslation.com/enterprise).) ## Solution maison, bibliothèque ou General Translation en un coup d’œil | | Dictionnaire et utilitaire maison | Bibliothèque open source, comme i18next | General Translation | | --------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Dépendances | Aucune | La bibliothèque et ses liaisons pour le framework, comme `react-i18next` | `gt-react` ou `gt-next`, ainsi que la CLI `gt` | | Formes plurielles | Votre propre code de sélection, et chaque forme dans chaque fichier | Sélection CLDR ; des traducteurs ou un service de traduction connecté fournissent les formes | [``](/docs/react/reference/components/plural) sélectionne selon les règles CLDR ; la traduction génère les formes de chaque langue cible à partir des branches que vous écrivez | | Nombres, dates, devises | Les API `Intl` que vous appelez vous-même | Formateurs intégrés reposant sur `Intl` | [``](/docs/react/reference/components/num), [``](/docs/react/reference/components/currency) et [``](/docs/react/reference/components/datetime) | | Traductions manquantes | Selon le comportement de votre utilitaire | [Se rabat sur une langue configurée, puis affiche la clé](https://www.i18next.com/principles/fallback) | Affiche le contenu source | | Synchronisation des langues | À la main ou avec votre propre script | Outils d’extraction et service de traduction que vous connectez | Chaque exécution de [`npx gt translate`](/docs/cli/reference/commands/translate) traduit le contenu nouveau ou modifié | | Qui traduit | Des traducteurs ou un service que vous intégrez | Des traducteurs ou un service de traduction connecté | L’IA, à l’aide du contexte JSX balisé, du glossaire et des instructions personnalisées ; votre équipe relit dans le tableau de bord | | Coût | Votre temps et les services que vous intégrez | Bibliothèque gratuite ; la traduction est facturée à part | Bibliothèques JavaScript gratuites ; [traduction facturée à l’usage](https://generaltranslation.com/pricing) | ## Quand le développer vous-même Développez-le vous-même si vous proposez une ou deux langues, que vos textes sont peu nombreux et stables, que vos langues forment le pluriel comme l'anglais et qu'un membre de l'équipe rédige les traductions, ou s'il s'agit d'un prototype. Optez pour une bibliothèque open source comme i18next si vous avez besoin de règles de pluriel et de solutions de repli, et que vous disposez déjà de traducteurs ou d'un système de gestion de la traduction. Utilisez General Translation si vous ajoutez plusieurs langues, si vos textes changent à chaque livraison ou si personne dans l'équipe ne devrait avoir à rédiger des formes du pluriel en polonais : General Translation génère les traductions en tenant compte du contexte de votre code et maintient chaque langue à jour à chaque compilation. (Voir [General Translation vs. i18next, react-intl et next-intl](/kb/general-translation-vs-i18n-libraries).) ## Conservez votre dictionnaire et laissez la CLI le traduire Inutile de réécrire votre utilitaire pour ne plus traduire à la main. Placez les messages de chaque langue dans un fichier JSON (`locales/en.json`, `locales/es.json`), conservez votre `t()` et faites pointer `gt.config.json` vers ces fichiers à l'aide de l'espace réservé `[locale]` : ```json title="gt.config.json" { "defaultLocale": "en", "locales": [ "es" ], "files": { "json": { "include": [ "locales/[locale].json" ] } } } ``` [`npx gt translate --dry-run`](/docs/cli/reference/commands/translate) indique `locales/en.json` comme source, et une exécution complète génère `locales/es.json`. Cet exemple utilise des messages en anglais et en espagnol dont les structures de clés correspondent, avec de simples espaces réservés comme `{name}`. Un fichier associé `locales/en.metadata.json` permet d’ajouter du contexte ou des limites de caractères pour chaque clé. Consultez [JSON](/docs/cli/reference/formats/json-files) et [Métadonnées associées aux clés](/docs/cli/reference/keyed-metadata). La recherche des clés et la sélection des formes plurielles restent à la charge de votre utilitaire ; vérifiez-les toutes deux dans le rendu en espagnol. Pour vous passer de l’utilitaire, encapsulez un composant à la fois dans [``](/docs/react/reference/components/t), ou conservez les clés avec [`useTranslations`](/docs/react/guides/translating-with-dictionaries). Si vous confiez le travail à un agent de codage, fournissez-lui les [instructions pour agents](/docs/overview/for-coding-agents) de General Translation plutôt que de lui demander un utilitaire `t()`. Commencez par le [Démarrage rapide Next.js](/docs/react/nextjs-quickstart) ou le [Démarrage rapide pour une SPA React](/docs/react/react-spa-quickstart). ## Points clés * Un dictionnaire, un utilitaire `t()` et les API `Intl` intégrées suffisent pour une ou deux langues, un peu de texte et des formes plurielles qui fonctionnent comme en anglais. * À mesure que l'application grandit, c'est à vous de maintenir la sélection des formes plurielles, les solutions de repli, le formatage, la synchronisation des fichiers, la prise en charge du right-to-left, les URL par paramètre régional et le processus de production des traductions. * Les bibliothèques de General Translation se chargent du travail à l'exécution, General Translation génère les traductions en s'appuyant sur votre code comme contexte, et la CLI peut traduire un dictionnaire JSON fait maison si vous choisissez de le conserver. ## 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. - [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. - [Comment configurer le SEO d’une application Next.js multilingue ?](https://generaltranslation.com/fr/kb/multilingual-nextjs-seo.mdx): Attribuez à chaque langue sa propre URL, définissez l’attribut lang de la balise html, faites pointer l’URL canonique de chaque page vers elle-même, ajoutez des variantes localisées hreflang pour chaque langue, traduisez les titres et les descriptions, et listez toutes les versions linguistiques dans votre sitemap. - [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 ``, 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. - [Alternatives à Google Translate : General Translation vs Google Translate](https://generaltranslation.com/fr/kb/general-translation-vs-google-translate.mdx): Google Translate permet de traduire rapidement un texte ponctuel, mais pour livrer un produit dans une autre langue, il faut aussi traduire chaque chaîne de caractères dans son contexte, garantir la cohérence des termes, gérer correctement les variables et les formes plurielles, prévoir une relecture et mettre en place un processus de livraison. General Translation comprend le contexte de chaque chaîne de caractères dans votre code et automatise l’ensemble du workflow de localisation, du code à la relecture, jusqu’à chaque livraison. ## Previous and next questions - Previous question: [Alternatives à Transifex : General Translation ou Transifex](https://generaltranslation.com/fr/kb/general-translation-vs-transifex.mdx) - Next question: [General Translation ou Babel et Flask-Babel : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-flask-babel.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.