# General Translation Knowledge Base: General Translation ou GNU gettext : avez-vous besoin des deux ? URL: https://generaltranslation.com/fr/kb/general-translation-vs-gettext.mdx Docs index: https://generaltranslation.com/llms.txt Description: Conservez GNU gettext pour l’extraction et l’affichage, et ajoutez General Translation pour générer et maintenir les fichiers PO. General Translation tient compte des notes aux traducteurs et du contexte des messages lors de la génération, applique une terminologie partagée et met à la disposition des relecteurs un éditeur dans le tableau de bord. Vos appels gettext existants et vos catalogues compilés restent en place. Category: Internationalisation Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 GNU gettext reste la chaîne d’outils sur laquelle repose encore l’essentiel de la traduction logicielle. Vous encapsulez les chaînes visibles par l’utilisateur dans `_()` ou `gettext()`, `xgettext` les extrait dans un modèle POT, `msginit` crée un fichier PO pour chaque langue, `msgmerge` met ces fichiers à jour lorsque la source change, et `msgfmt` les compile en fichiers `.mo` que votre programme charge à l’exécution. Les programmes C, l’extension gettext de PHP, le module `gettext` de Python, WordPress, Django et Babel utilisent tous ce format. En revanche, gettext vous laisse l’essentiel de la traduction : depuis la version 1.0, il peut rédiger une première version des entrées avec un LLM local, mais chaque `msgstr` de chaque fichier PO doit être finalisé par vous, vos traducteurs ou un prestataire. General Translation ne remplace aucun maillon de la chaîne d’outils : sa CLI génère ces fichiers PO à partir de votre modèle, et le reste de votre configuration gettext reste inchangé. ## Les points forts de gettext * **Le texte source sert de clé.** Le code contient `_("Inbox")`, et non un nom de clé, et une chaîne de caractères sans traduction [se rabat sur le texte source](https://www.gnu.org/software/gettext/manual/html_node/Interface-to-gettext.html) au lieu de provoquer une erreur. * **Des règles de pluriel propres à chaque langue.** Chaque fichier PO contient un [en-tête `Plural-Forms` indiquant la règle de la langue](https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html), et `msginit` le remplit pour vous. Le polonais se voit attribuer une règle à trois formes et trois emplacements `msgstr[n]` pour chaque entrée au pluriel. * **Le contexte accompagne la chaîne.** `msgctxt` (issu de `pgettext`) [distingue « Archive » le verbe de « Archive » le nom](https://www.gnu.org/software/gettext/manual/html_node/Contexts.html), les commentaires `#.` transmettent des notes aux traducteurs (`xgettext --add-comments`), les lignes `#:` renvoient à la source, et des options telles que `python-format` permettent à `msgfmt --check` de rejeter une traduction qui casse un espace réservé. * **Des mises à jour sans risque.** `msgmerge` [conserve les traductions existantes lorsque le modèle change](https://www.gnu.org/software/gettext/manual/html_node/msgmerge-Invocation.html) et marque comme fuzzy les entrées dont la source a changé, tout en conservant l'ancienne source pour comparaison (`--previous`). * **Des premières versions générées par un LLM local.** Depuis la version 1.0, [`msgpre` et `spit` prétraduisent les fichiers PO](https://www.gnu.org/software/gettext/manual/html_node/Pretranslating.html) à l'aide d'un LLM installé localement via ollama, ce qui fournit une base de travail à faire relire par un traducteur. * **Une prise en charge universelle.** PO est le format que lisent et écrivent les éditeurs PO comme Poedit et la plupart des systèmes de gestion de la traduction (TMS), et les outils sont des [logiciels libres](https://www.gnu.org/software/gettext/manual/html_node/Licenses.html) (sous GPL, la bibliothèque d'exécution étant sous LGPL). ## Ce que gettext vous laisse à gérer Voici un petit script Python qui utilise le module `gettext` de la bibliothèque standard : ```python title="inbox.py" import gettext, sys lang = sys.argv[1] count = int(sys.argv[2]) t = gettext.translation("inbox", localedir="locale", languages=[lang], fallback=True) _ = t.gettext # TRANSLATORS: titre de la page de la boîte de réception print(_("Inbox")) print(t.ngettext("You have %d unread message.", "You have %d unread messages.", count) % count) print(t.pgettext("email verb", "Archive")) ``` Le workflow gettext, avec [GNU gettext 1.0](https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00007.html) : ```bash xgettext --language=Python --keyword=pgettext:1c,2 --add-comments=TRANSLATORS -o po/inbox.pot inbox.py msginit --no-translator --locale=pl_PL.UTF-8 -i po/inbox.pot -o po/pl.po # quelqu'un renseigne chaque msgstr de po/pl.po msgfmt --check -o locale/pl/LC_MESSAGES/inbox.mo po/pl.po ``` Une fois le fichier polonais complété, `python3 inbox.py pl 5` affiche « Masz 5 nieprzeczytanych wiadomości. » Puis quelqu'un remplace « unread message » par « new message » dans le code. `xgettext` et `msgmerge --update --previous` reprennent l'ancienne traduction polonaise et la marquent comme fuzzy, puisqu'elle traduit désormais un texte différent : ```text title="po/pl.po" #: inbox.py:10 #, fuzzy, python-format #| msgid "You have %d unread message." #| msgid_plural "You have %d unread messages." msgid "You have %d new message." msgid_plural "You have %d new messages." msgstr[0] "Masz %d nieprzeczytaną wiadomość." msgstr[1] "Masz %d nieprzeczytane wiadomości." msgstr[2] "Masz %d nieprzeczytanych wiadomości." ``` `msgfmt` [ignore les entrées fuzzy](https://www.gnu.org/software/gettext/manual/html_node/msgfmt-Invocation.html) (il indique "2 translated messages, 1 fuzzy translation") : la même commande affiche donc désormais "You have 5 new messages." en anglais, au beau milieu d'un écran en polonais. L'ancienne traduction polonaise parle toujours de messages « non lus » ("unread") et doit donc être mise à jour. General Translation peut générer cette mise à jour à partir du nouveau modèle lors de votre compilation. ## Traduire des catalogues gettext avec General Translation La CLI de General Translation lit votre modèle POT, traduit chaque entrée et génère un fichier PO pour chaque langue cible. Faites pointer `gt.config.json` vers le modèle et indiquez où placer le fichier de chaque langue. Cette configuration a été testée avec `gt` 2.26.5 : ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["de", "pl", "pt_BR"], "customMapping": { "pt_BR": { "code": "pt-BR" } }, "files": { "pot": { "include": ["po/inbox.pot"], "transform": { "match": "^po/inbox\\.pot$", "replace": "po/{locale}.po" }, "transformationFormat": "PO" } } } ``` * **`pot` lit les fichiers PO et POT**, et `"transformationFormat": "PO"` génère des fichiers `.po` traduits. (Consultez la [référence du format PO / POT](/docs/cli/reference/formats/po-pot-files).) * **`transform` définit le nom des fichiers de sortie.** `{locale}` correspond au paramètre régional exactement tel qu'il est écrit dans `locales`, ce qui donne `po/pl.po` et `po/pt_BR.po`. (Consultez [`transform`](/docs/cli/reference/config#files).) * **Conservez les noms de paramètres régionaux de gettext.** [`customMapping`](/docs/cli/reference/config#custom-mapping) associe `pt_BR` au code de langue standard `pt-BR`. La même approche convient à d'autres arborescences, comme les fichiers `languages/my-plugin.pot` et `languages/my-plugin-de_DE.po` d'un plugin WordPress. Une fois la CLI configurée (consultez le [Démarrage rapide de la CLI](/docs/cli/quickstart)), le workflow se résume à : ```bash xgettext --language=Python --keyword=pgettext:1c,2 --add-comments=TRANSLATORS -o po/inbox.pot inbox.py msgconv --to-code=UTF-8 -o po/inbox.pot po/inbox.pot npx gt translate msgfmt --check -o locale/pl/LC_MESSAGES/inbox.mo po/pl.po ``` `xgettext` laisse `charset=CHARSET` comme espace réservé dans l'en-tête du modèle, et `msgconv` le définit sur UTF-8, comme le ferait `msginit` pour un fichier de langue. [`npx gt translate`](/docs/cli/reference/commands/translate) envoie chaque entrée accompagnée, en guise de contexte, de tout ce que le fichier PO sait à son sujet : le `msgctxt`, les commentaires pour les traducteurs `#.`, les références `#:` et les options de format. Pour une entrée au pluriel, General Translation écrit l'en-tête `Plural-Forms` de la langue cible et remplit chaque emplacement `msgstr[n]` requis par cet en-tête (trois pour le polonais, six pour l'arabe), puis vérifie que les espaces réservés comme `%d` sont restés intacts. Lorsqu'un `msgid` change, General Translation génère une traduction du nouveau texte lors de l'exécution suivante ; les entrées inchangées réutilisent leurs traductions existantes. Importez vos traductions PO existantes avec [`npx gt upload`](/docs/cli/reference/commands/upload) avant votre première génération. Si vous modifiez ensuite des traductions dans un éditeur PO local, [`npx gt save-local`](/docs/cli/reference/commands/save-local) les renvoie vers la plateforme avant que vous ne relanciez la génération. Au-delà du remplissage des `msgstr`, General Translation apporte tout le reste de la stack. Un glossaire et des instructions personnalisées dans un [groupe de contexte](/docs/platform/dashboard/guides/defining-context-for-translations) garantissent la cohérence de la terminologie et du ton dans vos fichiers PO comme dans toutes les autres interfaces que vous traduisez ; les relecteurs peuvent [vérifier et modifier](/docs/platform/dashboard/guides/reviewing-translations) chaque entrée PO, avec les formes du pluriel de la langue cible, dans le tableau de bord ; enfin, la CLI s'exécute dans votre CI pour que chaque livraison embarque des catalogues à jour. Exécutez la CLI Node.js pendant votre compilation, puis compilez la sortie PO obtenue avec `msgfmt`. Votre application continue de charger les traductions compilées en local. ## GNU gettext et General Translation en un coup d'œil | Fonctionnalité | GNU gettext | General Translation | | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | Extraction des chaînes du code | Oui, avec `xgettext` | Lit votre modèle POT existant | | Création d'un fichier par langue | Oui, avec `msginit` | Oui, à partir du modèle, pour chaque paramètre régional configuré | | Rédaction des traductions | Brouillons générés par un LLM local depuis la version 1.0, à finaliser par un traducteur | Oui, avec [`npx gt translate`](/docs/cli/reference/commands/translate) | | Après modification d'une chaîne source | `msgmerge` la marque comme fuzzy jusqu'à sa relecture | Retraduite lors de la prochaine exécution ; les entrées inchangées sont réutilisées | | Formes du pluriel | `msginit` écrit l'en-tête ; à vous de remplir chaque emplacement | Écrit l'en-tête et remplit tous les emplacements | | Contexte de traduction | `msgctxt`, commentaires du traducteur, références, options | Les mêmes, plus le glossaire et les instructions personnalisées | | Compilation et recherche des traductions à l'exécution | Oui, avec `msgfmt` et l'environnement d'exécution gettext | Conserve votre compilateur et votre environnement d'exécution gettext | | Coût | Logiciel libre | [Traduction facturée à l'usage](https://generaltranslation.com/pricing) | ## Quand utiliser l'un ou l'autre Utilisez gettext seul si des traducteurs ou un TMS alimentent déjà vos fichiers PO, si chaque traduction doit être rédigée par une personne avant sa mise en production, ou si votre processus de compilation ne peut pas exécuter Node.js. Ajoutez General Translation si vous souhaitez que chaque fichier PO soit traduit dans toutes les langues dès que le modèle change, avec des formes plurielles complètes et une terminologie cohérente partout, sans attendre un cycle de traduction. Il n'y a rien à migrer : General Translation conserve vos appels `_()`, votre modèle, vos fichiers PO et votre environnement d'exécution. Il remplace l'étape manuelle entre `msgmerge` et `msgfmt`. (Pour les configurations propres à un framework, consultez [General Translation vs. le framework de traduction de Django](/kb/general-translation-vs-django-i18n) et [General Translation vs. Babel et Flask-Babel](/kb/general-translation-vs-flask-babel).) ## Points clés * GNU gettext extrait, fusionne, compile et recherche les traductions, et depuis la version 1.0, il peut en rédiger des ébauches avec un LLM local, mais sans les finaliser. Les chaînes nouvelles ou modifiées s'affichent dans la langue source tant que personne ne les a traduites ou relues. * La CLI de General Translation traduit un modèle POT en un fichier PO par langue, grâce à la clé `pot`, à `"transformationFormat": "PO"`, à un `transform` pour le chemin de sortie et à `customMapping` pour des noms comme `pt_BR`. * Pour chaque entrée au pluriel, General Translation écrit l'en-tête `Plural-Forms` de la langue cible ainsi que chaque emplacement `msgstr[n]`, en s'appuyant sur `msgctxt` et les commentaires destinés aux traducteurs comme contexte. `msgfmt` et votre environnement d'exécution gettext restent en place. ## Related questions - [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): Utilisez conjointement le framework de traduction de Django et General Translation. Django gère l’extraction des messages, la sélection de la langue et l’affichage. General Translation remplit ses fichiers PO, formes du pluriel comprises, avec la terminologie de votre produit et une relecture dans le tableau de bord. Vos modèles et vos motifs d’URL restent inchangés, tandis que les traductions évoluent au rythme de votre code. - [General Translation ou Babel et Flask-Babel : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-flask-babel.mdx): Babel formate les dates, les nombres et les devises pour n’importe quel paramètre régional et gère les catalogues gettext, tandis que Flask-Babel l’intègre à Flask, mais aucun des deux ne traduit vos chaînes. La CLI de General Translation remplit les fichiers PO de Babel pour chaque langue, formes du pluriel comprises : vous pouvez ainsi conserver Flask-Babel et ne plus traduire vos catalogues à la main. - [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. - [General Translation ou Weblate : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-weblate.mdx): Weblate est une plateforme de localisation auto-hébergeable basée sur Git, conçue pour traduire les fichiers d’un dépôt avec une communauté ou une équipe. General Translation intègre la génération des traductions au développement et aux livraisons, en s’appuyant sur du JSX balisé et un contexte produit partagé. Conservez vos fichiers gettext, ou adoptez la rédaction directement dans le code pour vous affranchir aussi de la maintenance du catalogue source. - [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: [General Translation ou Babel et Flask-Babel : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-flask-babel.mdx) - Next question: [General Translation ou i18n-tasks : lequel choisir ?](https://generaltranslation.com/fr/kb/general-translation-vs-i18n-tasks.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/fr/kb/sitemap.md) for every article.