Les arguments pour et contre l’i18n basée sur un compilateur

Si vous développez des applications web depuis plus d’une décennie, vous savez que l’internationalisation (i18n) a toujours été un point de friction. C’est souvent la tâche que personne ne veut faire : extraire les chaînes, gérer les fichiers JSON, et se soucier des règles de pluriel.

Récemment, une nouvelle vague d’outils i18n « basés sur un compilateur » a émergé, promettant de faire disparaître cette douleur. L’argument est séduisant : Il suffit d’écrire le texte dans vos composants, et laissez l’outil de build gérer le reste. Pas de clés, pas d’importations, juste de la magie.

Mais comme pour toutes les abstractions en ingénierie logicielle, la magie a un prix.

Dans cet article de blog, nous allons explorer le passage des bibliothèques déclaratives aux approches basées sur un compilateur, les dettes architecturales cachées qu’elles introduisent, et pourquoi la méthode « ennuyeuse » pourrait encore être la meilleure pour les applications professionnelles.

Une brève histoire de la traduction

Pour comprendre où nous en sommes, il faut revenir à nos débuts.

Vers 2011–2012, le paysage JavaScript était très différent. Les bundlers tels que nous les connaissons (Webpack, Vite) n’existaient pas ou étaient à leurs débuts. Nous collions les scripts ensemble dans le navigateur. C’est à cette époque que des bibliothèques comme i18next sont nées.

Elles ont résolu le problème de la seule manière possible à l’époque : les Dictionnaires à l’exécution. Vous chargiez un énorme objet JSON en mémoire, et une fonction recherchait les clés à la volée. C’était fiable, explicite, et fonctionnait partout.

Avançons jusqu’à aujourd’hui. Nous disposons de compilateurs puissants (SWC, bundlers basés sur Rust) capables d’analyser des arbres de syntaxe abstraite (AST) en quelques millisecondes. Cette puissance a donné naissance à une nouvelle idée : Pourquoi gérer manuellement les clés ? Pourquoi le compilateur ne pourrait-il pas simplement voir le texte "Hello World" et le remplacer pour nous ?

Ainsi est née l’i18n basée sur un compilateur.

L’Attrait du Compilateur (L’Approche "Magique")

Il y a une raison pour laquelle cette nouvelle approche est tendance. Pour un développeur, l’expérience est incroyable.

1. Vitesse et "Flow"

Quand vous êtes dans votre zone, vous arrêter pour réfléchir à un nom de variable (home_hero_title_v2) casse votre flow. Avec une approche compilateur, vous tapez <p>Welcome back</p> et continuez. La friction est nulle.

2. La Mission de Sauvetage du Legacy

Imaginez hériter d’une énorme base de code avec 5 000 composants et aucune traduction. Adapter cela avec un système manuel basé sur des clés est un cauchemar qui dure des mois. Un outil basé sur un compilateur agit comme une stratégie de sauvetage, extrayant instantanément des milliers de chaînes sans que vous ayez besoin de toucher un seul fichier manuellement.

3. L’Ère de l’IA

C’est un avantage moderne qu’il ne faut pas négliger. Les assistants de codage IA (comme Copilot ou ChatGPT) génèrent naturellement du JSX/HTML standard. Ils ne connaissent pas votre schéma spécifique de clés de traduction.

• Déclaratif : Vous devez réécrire la sortie de l’IA pour remplacer le texte par des clés.
• Compilateur : Vous copiez-collez le code de l’IA, et ça fonctionne tout simplement.

La Réalité : Pourquoi la "Magie" est Dangereuse

Bien que la "magie" soit séduisante, l’abstraction fuit. Compter sur un outil de build pour comprendre l’intention humaine introduit une fragilité architecturale.

1. Fragilité Heuristique (Le Jeu de Deviner)

Le compilateur doit deviner ce qui est contenu et ce qui est code.

• Est-ce que className="active" est traduit ? C’est une chaîne de caractères.
• Est-ce que status="pending" est traduit ?
• Est-ce que <MyComponent errorMessage="An error occurred" /> est traduit ?
• Est-ce qu’un identifiant produit comme "AX-99" est traduit ?

Vous finissez inévitablement par « lutter » contre le compilateur, en ajoutant des commentaires spécifiques (comme // ignore-translation) pour l’empêcher de casser la logique de votre application.

2. La limite stricte des données dynamiques

L’extraction par le compilateur repose sur une analyse statique. Il doit voir la chaîne littérale dans votre code pour générer un ID stable. Si votre API renvoie une chaîne de code d’erreur comme server_error, vous ne pouvez pas la traduire avec un compilateur car celui-ci ne connaît pas cette chaîne au moment de la compilation. Vous êtes obligé de construire un système secondaire « runtime-only » uniquement pour les données dynamiques.

3. « Explosion des chunks » et cascades réseau

Pour permettre le tree-shaking, les outils de compilation divisent souvent les traductions par composant.

• La conséquence : Une seule vue de page avec 50 petits composants peut déclencher 50 requêtes HTTP distinctes pour de petits fragments de traduction. Même avec HTTP/2, cela crée un effet de cascade réseau qui rend votre application lente comparée au chargement d’un seul bundle de langue optimisé.

4. Surcharge des performances à l’exécution

Pour rendre les traductions réactives (afin qu’elles se mettent à jour instantanément lorsque vous changez de langue), le compilateur injecte souvent des hooks de gestion d’état dans chaque composant.

• Le Coût : Si vous affichez une liste de 5 000 éléments, vous initialisez 5 000 hooks useState et useEffect uniquement pour le texte. Cela consomme de la mémoire et des cycles CPU que les bibliothèques déclaratives (qui utilisent généralement un seul fournisseur Context) économisent.

Le Piège : Le Verrouillage Fournisseur

C'est sans doute l'aspect le plus dangereux de l'i18n basée sur un compilateur.

Dans une bibliothèque déclarative, votre code source contient une intention explicite. Vous possédez les clés. Si vous changez de bibliothèque, vous changez simplement l'import.

Dans une approche basée sur un compilateur, votre code source n'est que du texte en anglais. La "logique de traduction" n'existe que dans la configuration du plugin de build. Si cette bibliothèque cesse d’être maintenue, ou si vous la dépassez, vous êtes bloqué. Vous ne pouvez pas facilement « éjecter » car vous n’avez aucune clé de traduction dans votre code source. Vous devriez réécrire manuellement toute votre application pour migrer.

L’autre côté : risques de l’approche déclarative

Pour être juste, la méthode déclarative traditionnelle n’est pas parfaite non plus. Elle a ses propres « pièges ».

1. L’enfer des namespaces : Vous devez souvent gérer manuellement quels fichiers JSON charger (common.json, dashboard.json, footer.json). Si vous en oubliez un, l’utilisateur voit les clés brutes.
2. Surcharge de requêtes : Sans une configuration soigneuse, il est très facile de charger accidentellement toutes vos clés de traduction pour toutes les pages dès le chargement initial, ce qui alourdit la taille de votre bundle.
3. Dérive de synchronisation : Il est courant que des clés restent dans le fichier JSON bien après que le composant qui les utilise ait été supprimé. Vos fichiers de traduction grossissent indéfiniment, remplis de « clés zombies ».

Le juste milieu avec Intlayer

C’est là que des outils comme Intlayer cherchent à innover. Intlayer comprend que, bien que les compilateurs soient puissants, la magie implicite est dangereuse.

Intlayer propose une commande unique transform. Au lieu de faire simplement de la magie dans une étape de build cachée, elle peut en réalité réécrire votre code de composant. Elle analyse votre texte et le remplace par des déclarations de contenu explicites dans votre base de code.

Cela vous offre le meilleur des deux mondes :

1. Granularité : Vous gardez vos traductions proches de vos composants (améliorant la modularité et le tree-shaking).
2. Sécurité : La traduction devient un code explicite, et non une magie cachée au moment de la compilation.
3. Pas de verrouillage : Puisque le code est transformé en une structure déclarative standard dans votre dépôt, vous ne cachez pas la logique dans un plugin webpack.

Conclusion

Alors, que devriez-vous choisir ?

Si vous êtes un développeur junior, un fondateur solo, ou que vous construisez un MVP : L'approche basée sur le compilateur est un choix valide. Elle vous permet d'avancer extrêmement vite. Vous n'avez pas besoin de vous soucier des structures de fichiers ou des clés. Vous construisez simplement. La dette technique est un problème pour le "Vous du futur".

Si vous construisez une application professionnelle de niveau entreprise : La magie est généralement une mauvaise idée. Vous avez besoin de contrôle.

• Vous devez gérer des données dynamiques provenant des backends.
• Vous devez garantir la performance sur des appareils peu puissants (en évitant les explosions de hooks).
• Vous devez vous assurer de ne pas être enfermé à jamais dans un outil de build spécifique.

Pour les applications professionnelles, la Gestion de Contenu Déclarative (comme Intlayer ou des bibliothèques établies) reste la référence. Elle sépare vos préoccupations, maintient votre architecture propre, et garantit que la capacité de votre application à parler plusieurs langues ne dépend pas d'un compilateur "boîte noire" devinant vos intentions.