# General Translation Knowledge Base: Peut-on faire de l’i18n sans fichiers de traduction ?
URL: https://generaltranslation.com/fr/kb/i18n-without-translation-files.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 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.
Category: Internationalisation
Last updated: 2026-05-07
Authors: Jackie Chen, Ernest McCarter
Published: 2026-05-07

Quiconque a déjà internationalisé une application JavaScript connaît ce workflow. Vous installez une bibliothèque i18n, créez un fichier `en.json`, extrayez de vos composants toutes les chaînes de caractères visibles par l’utilisateur, attribuez une clé à chacune, puis faites référence à cette clé à l’endroit où se trouvait la chaîne. Vous dupliquez ensuite ce fichier JSON pour chaque langue prise en charge : `es.json`, `fr.json`, `ja.json`.

Au début, tout va bien. Trente chaînes, trois langues, 90 entrées.

Puis votre application grandit. Six mois plus tard, vous en êtes à 400 chaînes et 12 langues, soit 4 800 entrées réparties dans une douzaine de fichiers. Un développeur ajoute une fonctionnalité, écrit cinq nouvelles chaînes et oublie de mettre à jour trois des fichiers de traduction. Personne ne s’en rend compte, jusqu’au jour où un utilisateur à Tokyo voit du contenu de secours en anglais dans une interface en japonais. Quelqu’un suggère alors d’acheter un système de gestion de la traduction.

<Video src="https://assets.gtx.dev/i18n-no-translation.mp4" />

## Video

The video is narrated in English, with English captions.

[Can I do i18n without translation files?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-i18n-without-translation-files.mp4) (46 s)

General Translation lets you stop writing translation files with `gt-react` or `gt-next`. Run `npx gt init`, write the English inside a `<T>` component, then add `npx gt translate` to your build script so every build writes the translations.

## Le coût caché de la gestion des fichiers

Les fichiers de traduction imposent une charge de maintenance qui croît avec le nombre de langues prises en charge. Modifiez une chaîne de caractères, et c’est une douzaine de fichiers qu’il faut mettre à jour. Ces fichiers finissent par se désynchroniser. Pour les garder cohérents, il faut de l’outillage, de l’automatisation ou de la discipline.

La multitude de solutions de contournement en dit long : extensions VS Code qui génèrent automatiquement des clés de traduction, générateurs de types qui valident votre JSON par rapport à des interfaces TypeScript, linters qui détectent les clés inutilisées, vérifications CI qui s’assurent que tous les paramètres régionaux sont synchronisés. On ne développe pas ce genre d’outils pour un workflow qui fonctionne bien.

Votre IU dit une chose, vos fichiers de traduction en disent une autre, et une correspondance fondée sur des clés fait le lien entre les deux :

```tsx
function CheckoutSummary({ itemCount, discount }) {
  const { t } = useTranslation('checkout');

  return (
    <div>
      <h2>{t('summary.title')}</h2>
      <p>{t('summary.item_count', { count: itemCount })}</p>
      {discount && <p>{t('summary.discount_applied', { percent: discount })}</p>}
      <p>{t('summary.total_label')}</p>
      <small>{t('summary.tax_notice')}</small>
    </div>
  );
}
```

Pour comprendre ce que ce composant affiche, il faudrait ouvrir `checkout.json`, trouver l&#39;espace de noms `summary` et recouper cinq clés. Multipliée par des centaines de composants, la revue de code se transforme en un va-et-vient permanent entre fichiers.

La syntaxe de message ICU n&#39;arrange rien. Le format qu&#39;utilisent des bibliothèques comme `i18next`, `react-intl` et `next-intl` pour les formes plurielles, le genre et l&#39;interpolation est un mini-langage à part entière, intégré dans des chaînes JSON. Une accolade mal placée dans `{count, plural, one {# item} other {# items}}` ne se manifestera qu&#39;à l&#39;exécution. Il existe des linters pour cela, mais la plupart des équipes s&#39;en passent. Le code intégré, en revanche, est vérifié par votre compilateur TypeScript et votre IDE dès la saisie.

## Traduire directement le code

Et si vous n&#39;extrayiez tout simplement pas les chaînes ?

```tsx
import { T } from 'gt-react';

function CheckoutSummary({ itemCount, discount }) {
  return (
    <T>
      <div>
        <h2>Order Summary</h2>
        <p>You have {itemCount} items in your cart.</p>
        {discount && <p>{discount}% discount applied!</p>}
        <p>Total (before tax):</p>
        <small>Tax calculated at checkout.</small>
      </div>
    </T>
  );
}
```

Le composant [`<T>`](/docs/react/reference/components/t) de [`gt-react`](/docs/react/react-quickstart) marque un bloc de JSX à traduire. Le texte anglais reste dans votre composant. Lorsqu&#39;un utilisateur consulte la page en espagnol, le contenu de [`<T>`](/docs/react/reference/components/t) est remplacé par son équivalent espagnol. La structure et le formatage sont conservés.

Fini les `t('checkout.summary.title')`, le fichier `en.json` et les fichiers JSON par paramètre régional à maintenir synchronisés.

## Les traductions comme artefacts de compilation

Elles sont générées au moment du déploiement. La [CLI GT](/docs/cli/reference/commands/translate) analyse votre base de code pour repérer tout ce qui se trouve dans les composants [`<T>`](/docs/react/reference/components/t), puis génère les traductions pour chaque langue cible. Le résultat est placé dans un répertoire ignoré par Git, au même titre que le CSS compilé ou le JavaScript empaqueté.

```json title="gt.config.json"
{
  "defaultLocale": "en",
  "locales": ["es", "fr", "ja", "de", "ko", "zh"],
  "files": {
    "gt": {
      "output": "public/_gt/[locale].json"
    }
  }
}
```

```txt title=".gitignore"
public/_gt/
```

En développement, les traductions se font à la demande : modifiez une chaîne de caractères, actualisez la page, et elle s&#39;affiche aussitôt en japonais. En production, tout est prégénéré et servi depuis un CDN. Les fichiers de traduction existent toujours sur le disque, mais ce sont des artefacts de build, et non des fichiers que vous rédigez ou maintenez vous-même.

## Ce qui change en pratique

La différence se ressent bien plus dans le travail quotidien que sur les schémas d&#39;architecture.

Une PR qui ajoute une nouvelle section à une page se lit comme une PR qui ajoute une nouvelle section à une page. Le relecteur voit le texte réel, et non `checkout.summary.discount_applied_notice`. La revue de code n&#39;oblige plus à garder un fichier JSON ouvert à côté.

Le refactoring devient moins pénible. Renommez un composant, déplacez-le, découpez-le en plusieurs morceaux : les traductions suivent le contenu, puisqu&#39;il n&#39;y a aucune clé à remapper. Ajouter une langue se résume à modifier une seule ligne de configuration. Supprimer un composant signifie simplement que ses traductions cessent discrètement d&#39;être générées, au lieu de laisser derrière lui des clés orphelines éparpillées dans 15 fichiers, que personne n&#39;a envie de nettoyer.

## L&#39;avenir des bibliothèques i18n

Dans l&#39;ensemble de l&#39;écosystème, la tendance est aux chaînes intégrées. Les premières bibliothèques i18n comme `i18next` et `react-intl` ont été conçues à une époque où la traduction automatique n&#39;était pas viable et où chaque chaîne de caractères devait être confiée à un traducteur humain. Les dictionnaires se justifiaient alors comme format d&#39;échange. Cette contrainte a disparu, et le coût en expérience développeur qu&#39;implique la maintenance de fichiers de chaînes parallèles est de plus en plus difficile à justifier.

`next-intl` a ajouté des [messages intégrés expérimentaux avec extraction automatique](https://next-intl.dev/docs/usage/extraction) en complément de son mode dictionnaire. [Le compilateur de Lingui](https://lingui.dev/ref/swc-plugin) extrait les messages lors du build à partir de gabarits étiquetés intégrés. [Paraglide](https://inlang.com/m/gerre34r/library-inlang-paraglideJs) emprunte une autre voie : il compile des fichiers de messages en fonctions propres à chaque paramètre régional et compatibles avec le tree-shaking. Les approches diffèrent, mais toutes rapprochent le contenu du composant. GT pousse cette logique jusqu&#39;au bout : votre JSX est la source de vérité, et la traduction devient une étape de compilation.

## Le compromis

Lorsque vous écrivez du contenu intégré, vous écrivez dans votre langue maternelle. La structure de vos composants, la construction de vos phrases, le parcours de votre IU : tout reflète votre façon de penser en anglais (ou dans votre langue source, quelle qu&#39;elle soit). Une approche fondée sur un dictionnaire, comme `next-intl`, est par nature plus indépendante de la langue, car le composant ne contient jamais de véritable phrase, dans quelque langue que ce soit : seulement une clé qui renvoie ailleurs.

Mais la plupart des développeurs pensent déjà dans une langue donnée lorsqu&#39;ils construisent une IU. La mise en page, les textes, les libellés des boutons : tout est d&#39;abord pensé en anglais. Ce biais est inscrit dans la conception elle-même, que les chaînes soient intégrées ou stockées dans un fichier JSON. Selon nous, c&#39;est au framework i18n de s&#39;adapter à votre façon réelle de travailler. Construisez l&#39;application naturellement et laissez le framework se charger de la traduction, plutôt que d&#39;abstraire le contenu en clés au nom de la neutralité linguistique.

## Prise en main

```bash
npx gt@latest init
```

L&#39;assistant de configuration initiale paramètre votre projet, installe les dépendances et met en place le rechargement à chaud des traductions en développement. Retrouvez le guide complet dans le [Démarrage rapide de la CLI](/docs/cli/quickstart).

Une fois cette étape terminée, encapsulez le contenu dans [`<T>`](/docs/react/reference/components/t), lancez votre serveur de développement et utilisez le composant [`<LocaleSelector>`](/docs/react/reference/components/locale-selector) pour passer d&#39;une langue à l&#39;autre :

```tsx
import { LocaleSelector } from 'gt-react';

function Header() {
  return (
    <header>
      <nav>{/* ... */}</nav>
      <LocaleSelector />
    </header>
  );
}
```

En développement, les traductions sont générées à la demande, ce qui vous permet de voir immédiatement votre application dans n&#39;importe quelle langue. En production, les traductions sont prégénérées. Ajoutez l&#39;étape `translate` à votre processus de compilation, puis définissez `GT_PROJECT_ID` et `GT_API_KEY` chez votre hébergeur :

```json title="package.json"
{
  "scripts": {
    "build": "npx gt translate && next build"
  }
}
```

La commande [`translate`](/docs/cli/reference/commands/translate) parcourt votre base de code pour repérer toutes les utilisations de [`<T>`](/docs/react/reference/components/t) et génère les traductions, afin que chaque paramètre régional soit prêt dès la compilation de votre application.

`gt-react` est open source. Pour l&#39;App Router de Next.js, utilisez [`gt-next`](/docs/react/nextjs-quickstart). Pour React Native, utilisez [`gt-react-native`](/docs/react/react-native-quickstart).

## Related questions

- [Comment traduire du texte conditionnel en JSX ?](https://generaltranslation.com/fr/kb/translate-conditional-jsx.mdx): Plutôt que de traduire séparément chaque branche d’un ternaire, encapsulez la phrase entière dans un composant `<T>` et exprimez la condition avec `<Branch>` : le traducteur dispose ainsi du contexte complet et peut réorganiser la phrase selon chaque langue.
- [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.
- [Quel est le meilleur logiciel de localisation pour les développeurs ?](https://generaltranslation.com/fr/kb/best-localization-software.mdx): Privilégiez un système unique qui couvre l’ensemble du pipeline, de la bibliothèque i18n dans votre code jusqu’à la traduction et la livraison, plutôt que d’assembler tant bien que mal une bibliothèque, un système de gestion de la traduction et un prestataire de traduction distincts.

## Previous and next questions

- Previous question: [Quel est le meilleur logiciel de localisation pour les développeurs ?](https://generaltranslation.com/fr/kb/best-localization-software.mdx)
- Next question: [Alternatives à Crowdin : General Translation ou Crowdin](https://generaltranslation.com/fr/kb/general-translation-vs-crowdin.mdx)

## Sitemap

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