# General Translation Knowledge Base: General Translation ou Paraglide JS : lequel choisir ?
URL: https://generaltranslation.com/fr/kb/general-translation-vs-paraglide.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Choisissez General Translation pour garder vos textes intégrés au code et générer des traductions qui tiennent compte de la structure de vos composants React, d’une terminologie partagée et d’une relecture dans le tableau de bord. Choisissez Paraglide JS pour des fonctions de messages compilées et typées, avec un tree-shaking message par message. Paraglide affiche vos catalogues ; General Translation relie vos textes source à la génération des traductions et à leurs mises à jour au fil de l’eau.
Category: Internationalisation
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16
Paraglide JS est une bibliothèque d’i18n axée sur la compilation, développée par inlang. Vous stockez vos messages dans des fichiers JSON tels que `messages/en.json`, et son compilateur transforme chaque message en une fonction typée que vous appelez sous la forme `m.greeting({ name })` : votre bundler peut ainsi éliminer les messages qu’une page n’utilise jamais. La traduction, en revanche, reste à votre charge : chaque message, dans chaque langue, doit être fourni par vous, par un traducteur ou par une commande de traduction automatique que vous exécutez sur les fichiers. Les bibliothèques de General Translation affichent elles aussi les traductions, mais General Translation se charge en plus de les générer, à partir de textes que vous écrivez une seule fois, directement dans vos composants.
## Les points forts de Paraglide JS
* **Sûreté du typage.** Les clés et les paramètres des messages sont des types générés. Depuis la version 2.29.0, une faute de frappe comme `m.greting()` et un appel à `m.greeting({})` sans son paramètre `name` déclenchent tous deux des erreurs TypeScript.
* **Taille du bundle.** Les messages sont compilés en modules ES, ce qui permet d’éliminer par tree-shaking ceux qui ne sont pas utilisés. Dans le [benchmark publié](https://paraglidejs.com/benchmark) par Paraglide, une page utilisant 100 messages sur 200 dans cinq paramètres régionaux transférait 47 Ko avec Paraglide, contre 205 Ko avec i18next.
* **Formes plurielles et variantes.** Le format de message par défaut [déclare un sélecteur de pluriel](https://paraglidejs.com/variants) et s’appuie sur les catégories CLDR telles que `one`, `few` et `many`. Des [plugins](https://paraglidejs.com/file-formats) ajoutent la prise en charge des fichiers ICU MessageFormat 1 et i18next, et des formateurs couvrent les nombres, les dates et le temps relatif via `Intl`.
* **Stratégies de détection du paramètre régional.** Une [liste `strategy`](https://paraglidejs.com/strategy) ordonnée résout le paramètre régional à partir de l’URL, d’un cookie, de `localStorage`, de la langue préférée du navigateur, d’une variable globale, de stratégies personnalisées ou de `baseLocale`. Dans la version 2.29.0, l’[ordre par défaut](https://github.com/opral/paraglide-js/blob/main/src/compiler/compiler-options.ts) est `cookie`, `globalVariable`, puis `baseLocale`. Un [middleware serveur](https://paraglidejs.com/middleware) et `localizeUrl` gèrent les routes localisées.
* **Large compatibilité avec les frameworks.** Paraglide [fonctionne avec n’importe quelle application Vite](https://paraglidejs.com/vite) et propose des guides pour React, Vue, Solid, SvelteKit, TanStack Start, React Router, Astro et Next.js. C’est l’[extension qu’installe `npx sv add paraglide`](https://paraglidejs.com/sveltekit) dans la CLI Svelte. Son [guide Next.js](https://paraglidejs.com/next-js) couvre l’App Router grâce à un plugin webpack, à exécuter avec l’option `--webpack`.
* **Outillage libre et gratuit.** La bibliothèque est [sous licence MIT](https://github.com/opral/paraglide-js/blob/main/LICENSE). La [CLI inlang](https://inlang.com/m/2qj2w8pu/app-inlang-cli) vérifie les projets en CI, [Sherlock](https://inlang.com/m/r7kp499g/app-inlang-ideExtension) affiche les traductions directement dans VS Code, et [Fink](https://fink.inlang.com/) est un éditeur gratuit, utilisable dans le navigateur, qui commite les modifications des traducteurs dans un dépôt GitHub.
## Ce que Paraglide JS vous laisse gérer
Un projet inlang est un dossier `project.inlang` dont le fichier `settings.json` répertorie vos paramètres régionaux, vos plugins et le chemin vers vos fichiers de messages. Voici une boîte de réception avec un message simple, un message avec paramètre et un pluriel :
```json title="messages/en.json"
{
"inbox_title": "Inbox",
"greeting": "Hello {name}!",
"unread_messages": [
{
"declarations": ["input count", "local countPlural = count: plural"],
"selectors": ["countPlural"],
"match": {
"countPlural=one": "You have {count} unread message.",
"countPlural=*": "You have {count} unread messages."
}
}
]
}
```
```tsx title="Inbox.tsx"
import { m } from './paraglide/messages.js';
export function Inbox({ name, count }: { name: string; count: number }) {
return (
{m.inbox_title()}
{m.greeting({ name })}
{m.unread_messages({ count })}
);
}
```
Chaque autre paramètre régional doit avoir son propre fichier, avec les mêmes clés et les variantes propres à sa langue : le polonais utilise `one`, `few`, `many` et `*`. Lorsqu'une clé est absente de `messages/pl.json`, la fonction compilée se rabat sur le paramètre régional de base sans émettre le moindre avertissement. Voici le composant affiché avec un fichier polonais dépourvu de `greeting` :
```text title="Output"
pl Skrzynka odbiorcza
Hello Ada!
Masz 2 nieprzeczytane wiadomości.
```
`npx @inlang/cli check` l’a bien détecté : il signale que `greeting` n’a pas de traduction polonaise et se termine avec le code 1, ce qui permet à la CI de bloquer cette lacune. La combler, en revanche, reste à votre charge. `inlang machine translate` traduit les messages manquants via un service communautaire gratuit par défaut, ou avec votre propre clé Google Cloud Translation ou DeepL, un message à la fois et sans le composant dans lequel il apparaît. La documentation du CLI inlang indique elle-même que des agents de codage disposant du contexte produit et du code peuvent fournir de meilleurs premiers jets qu’une traduction automatique générique.
## General Translation se charge des traductions
Les bibliothèques de General Translation assurent le même travail d'affichage. La différence tient à l'endroit où se trouvent les textes et à qui les traduit. Voici la même boîte de réception avec `gt-react` :
```tsx title="Inbox.tsx"
import { T, Plural, Num, Var } from 'gt-react';
export function Inbox({ name, count }: { name: string; count: number }) {
return (
Inbox
Hello {name}!
You have {count} unread message.}
plural={You have {count} unread messages.
}
/>
);
}
```
Aucun fichier de messages à maintenir synchronisé : le texte anglais, c’est le composant lui-même. [`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 et génère une traduction pour chaque locale cible : une nouvelle phrase est ainsi traduite avant votre compilation, au lieu de s’afficher en anglais par défaut. Une valeur placée dans [``](/docs/react/reference/components/var) n’est jamais envoyée à l’API, et [``](/docs/react/reference/components/plural) choisit une branche selon les règles de pluriel du paramètre régional du lecteur. [`npx gt validate`](/docs/cli/reference/commands/validate) vérifie le projet sans appeler l’API, et [`gt generate`](/docs/cli/reference/commands/generate) génère des fichiers modèles pour les équipes qui traduisent manuellement.
Le titre, la salutation et les branches de pluriel de ce bloc sont envoyés ensemble pour la traduction. General Translation applique également le [glossaire et les instructions personnalisées](/docs/platform/dashboard/guides/defining-context-for-translations) associés au projet, et les relecteurs peuvent modifier les résultats dans le tableau de bord. Ajoutez la CLI à votre CI, ou configurez [Locadex](/docs/platform/locadex/quickstart) pour ouvrir des pull requests de traduction à chaque modification de votre code.
Les bibliothèques JavaScript de General Translation sont sous licence MIT et fonctionnent sans compte avec vos propres traductions. En intégrant les traductions à votre application, l’affichage ne dépend plus du service hébergé ; la livraison par CDN vous permet quant à elle de publier les modifications de traduction indépendamment des livraisons de l’application. Consultez [stocker les traductions](/docs/react/guides/storing-translations) pour la configuration initiale.
Sierra publie plus de 7 paramètres régionaux sur son contenu web et marketing avec General Translation. (Voir les [déploiements en production](https://generaltranslation.com/enterprise).)
## Paraglide JS et General Translation en un coup d’œil
| Fonctionnalité | Paraglide JS | General Translation |
| ------------------------- | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Rédaction des textes | Clés dans un fichier JSON par paramètre régional, appelées via `m.key()` | 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 ; `inlang machine translate` s’appuie sur un service communautaire, Google ou DeepL | Oui, avec [`npx gt translate`](/docs/cli/reference/commands/translate) |
| Ce que voit le traducteur | Le contenu des messages transmis à l’outil de traduction choisi | Le bloc JSX balisé, les notes de développeur, ainsi que le glossaire et les instructions personnalisées attribués |
| Sûreté du typage | Types générés pour chaque clé et chaque paramètre | JSX intégré, donc aucune clé de message à mal saisir |
| Bundle | Tree-shaking par message | Traductions chargées par paramètre régional |
| Traduction manquante | Repli sur le paramètre régional de base ; signalée par `inlang check` | Générée par [`npx gt translate`](/docs/cli/reference/commands/translate) ; le contenu non traduit s’affiche dans la langue source |
| Frameworks | Applications Vite, React, Vue, Solid, SvelteKit, Astro, TanStack Start, React Router, Next.js (webpack) | React, Next.js, Vue, Node.js et [d’autres SDK](/docs/overview/get-started) |
| Coût | Gratuit et open source | Bibliothèques JavaScript gratuites ; [traduction facturée à l’usage](https://generaltranslation.com/pricing) |
Restez sur Paraglide JS si vous développez avec SvelteKit, Astro ou Solid, si le tree-shaking par message et les fonctions de message typées sont prioritaires, ou si votre équipe rédige ou achète déjà ses traductions. Optez pour General Translation si vous voulez des textes lisibles directement dans vos composants, et des traductions générées dans chaque langue à partir du contexte de votre code, à chaque compilation.
## Migrer vers General Translation composant par composant
Il est tout à fait possible de migrer composant par composant. Les messages de Paraglide sont de simples fonctions et ne nécessitent aucun fournisseur : un appel `m.*` et un bloc [``](/docs/react/reference/components/t) peuvent donc s'afficher côte à côte pendant que vous convertissez vos routes. Le guide [Migrer depuis d'autres bibliothèques i18n](/docs/react/guides/migrating-i18n-libraries) détaille les étapes, à partir du [Démarrage rapide avec React](/docs/react/react-quickstart) ou du [Démarrage rapide avec Next.js](/docs/react/nextjs-quickstart).
## Points clés
* Paraglide JS compile les catalogues en fonctions typées et compatibles avec le tree-shaking. Des outils inlang distincts peuvent générer des traductions pour ces catalogues.
* General Translation conserve le texte intégré dans [``](/docs/react/reference/components/t) et génère des traductions en s'appuyant sur le contexte de votre code, votre glossaire et vos instructions personnalisées, avec une relecture dans le tableau de bord.
* Continuez à utiliser les messages Paraglide existants pendant que vous migrez vos composants vers General Translation. Chaque composant migré embarque son texte source et son contexte de traduction directement dans le JSX.
## 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.
- [General Translation ou Intlayer : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-intlayer.mdx): Intlayer conserve le contenu de chaque composant dans un fichier de déclaration typé placé juste à côté, où toutes les langues sont écrites côte à côte, et peut compléter les langues manquantes grâce à un fournisseur d’IA que vous configurez. General Translation conserve les textes directement intégrés dans vos composants, dans une seule langue, et génère les autres langues en s’appuyant sur le contexte de votre code.
- [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.
- [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.
- [Pourquoi utiliser General Translation plutôt qu’un TMS (Smartling, Lokalise, Phrase, Crowdin ou Transifex) ?](https://generaltranslation.com/fr/kb/general-translation-vs-tms.mdx): Un système de gestion de la traduction (TMS) comme Smartling, Lokalise, Phrase, Crowdin ou Transifex coordonne les traducteurs, mais les ingénieurs doivent toujours extraire les chaînes, les envoyer, attendre les traductions, puis les réintégrer dans le produit. General Translation traduit le contenu directement dans votre code, avec son contexte, fournit toutes les langues à chaque livraison et repose sur des bibliothèques open source, sans dépendance à un fournisseur.
## Previous and next questions
- Previous question: [General Translation ou nestjs-i18n : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-nestjs-i18n.mdx)
- Next question: [General Translation ou Rails I18n : avez-vous besoin des deux ?](https://generaltranslation.com/fr/kb/general-translation-vs-rails-i18n.mdx)
## Sitemap
See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.