# Pourquoi le standard gettext existe depuis les années 1990, et ce qu’il résout

> Avant WordPress, avant même le web tel qu'on le connaît, gettext réglait déjà un problème universel des logiciels : comment traduire sans recompiler.

- Auteur : WordPress Développement
- Publié le : 2020-09-23
- Mis à jour le : 2020-09-23
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/histoire-standard-gettext/

## L’essentiel

- Créé au sein du projet GNU au début des années 1990
- Sépare le code source des chaînes traduisibles
- Repris tel quel par WordPress des années plus tard

En 1995, le projet GNU publie une bibliothèque destinée à un problème très concret que rencontrent alors les développeurs de logiciels libres distribués dans le monde entier : comment permettre à un même programme, compilé une seule fois, d'afficher ses messages dans la langue de la personne qui l'utilise, sans jamais devoir recompiler le code source pour chaque langue.

Cette bibliothèque, gettext, va devenir le standard de facto de l'internationalisation logicielle bien au-delà du monde GNU. WordPress l'adopte des années plus tard sans en changer les principes fondamentaux, ce qui explique pourquoi un développeur qui traduit un thème aujourd'hui manipule encore des fichiers `.po` et `.mo` conçus pour des programmes en C écrits vingt ans plus tôt.

## Le problème que gettext devait résoudre

Avant gettext, deux approches dominaient pour traduire un logiciel. La première consistait à maintenir une version du code source par langue, ce qui multipliait les risques de divergence et rendait toute correction de bug un cauchemar à répercuter partout. La seconde consistait à charger des tableaux de traduction codés en dur, souvent avec des identifiants numériques peu lisibles, difficiles à maintenir pour quiconque n'était pas le développeur d'origine.

La proposition de gettext change l'angle d'attaque : on laisse la chaîne en langue source, généralement l'anglais, directement dans le code, entourée d'un appel de fonction. Un outil externe extrait ensuite automatiquement toutes ces chaînes marquées pour produire un fichier modèle, que des traducteurs remplissent indépendamment du code, sans jamais y toucher.

## Une séparation stricte entre code et traduction

Cette séparation est la véritable innovation du système. Le développeur écrit son code normalement, en entourant chaque texte affiché d'un appel comme `gettext("Hello, world!")` dans un programme C classique. Un traducteur reçoit ensuite un fichier `.po` généré automatiquement, où chaque chaîne source anglaise est associée à un champ vide à remplir dans la langue cible. Il n'a besoin d'aucune compétence en programmation pour effectuer ce travail.

> L'essentiel à retenir : Créé au sein du projet GNU au début des années 1990 ; Sépare le code source des chaînes traduisibles ; Repris tel quel par WordPress des années plus tard

Une fois les traductions saisies, un compilateur transforme le fichier texte `.po` en un fichier binaire `.mo`, optimisé pour une recherche rapide au moment de l'exécution. Le programme charge alors, selon la langue configurée sur la machine de l'utilisateur, le fichier `.mo` correspondant, sans jamais avoir eu besoin de recompiler quoi que ce soit.

### Les briques du système

- `.pot` : le modèle, généré automatiquement, qui liste toutes les chaînes source à traduire.
- `.po` : une copie du modèle remplie pour une langue donnée, lisible et modifiable par un traducteur.
- `.mo` : la version compilée du `.po`, chargée réellement par le programme en production.

## Pourquoi ce modèle a traversé les décennies sans changer

Le format a survécu si longtemps parce qu'il répond à une contrainte qui n'a pas disparu avec le temps : la traduction reste un métier différent de la programmation, exercé par des personnes différentes, souvent à des moments différents du cycle de vie d'un projet. Séparer strictement les deux activités, avec un format texte simple et un outillage mature, reste aussi pertinent pour un thème WordPress en 2020 qu'il l'était pour un utilitaire GNU en ligne de commande en 1995.

> Une manière de retenir l'essentiel du système sans se perdre dans les détails : gettext ne traduit rien lui-même, il organise seulement la rencontre entre un code qui parle anglais et des traducteurs qui n'ont pas besoin de le lire.

## Ce que cela change pour un développeur WordPress

Quand WordPress introduit ses propres fonctions comme `__()` ou `_e()`, elles ne réinventent rien : elles s'appuient directement sur l'implémentation PHP de gettext, avec quelques ajustements propres au CMS, notamment la notion de domaine de texte pour distinguer les chaînes d'un thème de celles d'une extension ou du cœur. Comprendre cette filiation évite de chercher des explications complexes là où il n'y a qu'un héritage direct d'un standard vieux de plusieurs décennies.

## Pour aller plus loin

Un développeur qui bute sur un comportement inattendu des fichiers de traduction gagne souvent à se rappeler que ce système n'a pas été pensé pour WordPress en particulier. Ses règles, notamment sur les pluriels ou l'encodage des fichiers, viennent d'un standard bien plus ancien et bien plus large, conçu à une époque où le web multilingue tel qu'on le connaît n'existait tout simplement pas encore.