blog 18ways

i18n est cassé : arrêtez d’écrire des clés de traduction

Une façon native IA de faire de l’i18n dans Next.js, sans nuire au SEO.

L’internationalisation (souvent abrégée en i18n), la localisation (l10n) et la prise en charge multilingue décrivent toutes la même idée : adapter votre produit pour que les gens puissent l’utiliser dans leur propre langue.

i18n est toujours conçu comme en 2005

Chaque entreprise finit par se rendre compte qu’elle doit prendre en charge plusieurs langues. À ce moment-là, l’équipe produit se penche en arrière comme un mécanicien, aspire de l’air entre ses dents et dit : « De combien de pages parle-t-on ? C’est au moins quatre sprints. »

Une réaction de mécano au coût et à l’effort du travail i18n traditionnel

La manière fondamentale dont nous implémentons l’i18n n’a pas changé depuis 20 ans. La plupart des « bonnes pratiques » de l’i18n ont vu le jour bien avant les architectures web modernes, et tout ce qui a suivi n’a fait que se greffer dessus.

L’i18n est la seule partie du développement web moderne qui implique encore d’exporter des fichiers et de les envoyer à quelqu’un. On considère qu’une configuration est moderne si, au lieu de les envoyer par e-mail, vous les téléversez via une API.

Dans un monde de pipelines CI et de déploiements mesurés en minutes plutôt qu’en jours, on devrait probablement se considérer chanceux de ne pas avoir à faxer quoi que ce soit.

Pourquoi l’i18n semble cassée

Le développement web moderne a avancé à une vitesse incroyable.

Nous avons :

Et pourtant, les workflows d’internationalisation donnent encore l’impression de venir d’une autre époque.

Même des applications relativement petites se retrouvent vite à jongler avec :

Les développeurs ne se lancent pas dans la création de systèmes comme celui-ci. Ils y tombent par inadvertance, à mesure que les obstacles courants de l’i18n piègent des développeurs peu familiers avec la manière complètement différente dont les langues structurent les phrases… et qu’ils acceptent, à contrecœur, le statu quo établi il y a 20 ans.

Avec le temps, l’internationalisation devient l’une des parties les plus complexes de la stack.

L’UI moderne ne rentre pas dans des chaînes de traduction

Prenons une interface simple :

jsx
<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

C’est facile à comprendre. C’est simple.

À un moment donné, nous décidons de l’internationaliser. Nous extrayons donc le texte dans un fichier de traduction :

json
{
  "mainPage": {
    "greeting": "Hello world",
    "cta": "<0>Click here</0> to view your <1>{{description}}</1>"
  }
}

Et nous faisons référence à cela dans notre code :

jsx
<h1>{t('mainPage.greeting')}</h1>
<p>
  <Trans key="mainPage.cta">
    <a href="#/">Click here</a> to view your <b>{{ description: serverResponse.productDescription }}</b>
  </Trans>
</p>

Mais, attendez, nous avons maintenant du texte anglais à la fois dans notre code et dans notre fichier de traduction ? Oui. Différentes bibliothèques d’i18n y mettent des accents différents, mais essayer de traduire un texte partiellement formaté en l’extrayant dans un fichier JSON lisible par l’humain est une bataille perdue d’avance.

L’interface utilisateur moderne est structurée, mais les systèmes de traduction sont bâtis sur des chaînes de caractères plates.

Dès qu’il y a du balisage, des variables et du contenu dynamique, l’abstraction commence à fuir.

Le contenu dynamique et généré par les utilisateurs bouscule l’i18n traditionnelle

Les choses se compliquent encore davantage lorsque le contenu n’est pas statique.

Reprenons cet exemple :

jsx
<b>{serverResponse.productDescription}</b>

Cette chaîne provient d’une API. Comment la transformer en clé de traduction ?

Spoiler : non. Maintenant, votre backend doit lui aussi prendre en charge l’internationalisation.

Votre backend doit désormais gérer :

Les traducteurs doivent soudainement aussi accéder aux systèmes backend.

Et le problème ne fait que s’aggraver lorsque du contenu généré par les utilisateurs entre en jeu.

Avis. Commentaires. Annonces sur les marketplaces. Forums.

Les pipelines d’i18n traditionnels partent du principe que les développeurs contrôlent tout le texte. De plus en plus, ce n’est tout simplement pas vrai.

Le fait que des entreprises comme Amazon aient commencé à expérimenter avec des avis utilisateurs traduits en 2026 en dit long sur la lenteur avec laquelle l’écosystème de l’i18n a évolué.

La détection de locale est toujours un vrai bazar

Déterminer même quelle langue un utilisateur souhaite utiliser est étonnamment complexe.

Les navigateurs transmettent les préférences linguistiques via l’en-tête Accept-Language :

text
Accept-Language: en-GB,en;q=0.9,fr;q=0.8

Cela indique au serveur :

  1. Privilégier l’anglais britannique
  2. Puis toute forme d’anglais
  3. Puis n’importe quelle forme de français

En pratique, la mise en œuvre correcte de tout cela implique :

Beaucoup de frameworks laissent la majeure partie de cette logique aux développeurs.

Même la détection de locale la plus basique finit souvent par devenir du code applicatif personnalisé.

Le changement de langue est relégué au second plan

L’infrastructure de traduction n’est que la moitié du problème.

Les utilisateurs ont encore besoin d’un moyen de changer de langue.

La plupart des bibliothèques d’i18n fournissent la couche de traduction mais laissent le reste du problème au développeur :

Ces détails semblent mineurs, mais ils finissent vite par représenter une quantité importante de plomberie applicative, surtout si vous ne connaissez pas toutes les subtilités de l’i18n. La plupart des entreprises et des développeurs ne les connaissent pas.

Le raccourci : la traduction automatique de site web

Compte tenu de toute cette complexité, certaines équipes se tournent vers des outils de traduction automatique de sites web. Ces plateformes promettent de traduire votre site automatiquement avec un minimum d’effort.

Plusieurs entreprises construisent des versions de plus en plus sophistiquées de cette idée. Malheureusement, elles introduisent un autre ensemble de problèmes :

Le résultat est souvent un site qui prend techniquement en charge plusieurs langues mais offre une expérience nettement moins bonne, et constitue une boîte noire avec laquelle les développeurs doivent composer.

Comment nous en sommes arrivés là

Nous avons commencé avec quelque chose de merveilleusement simple :

jsx
<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

Et on s’est retrouvé avec des clés de traduction, des dictionnaires JSON, des pipelines fragmentés, des couches de localisation backend et frontend séparées, et des outils de traduction externes.

Les applications web modernes sont des systèmes incroyablement sophistiqués. Pourtant, les outils i18n attendent des workflows conçus pour une autre époque, comme une Ferrari qu’il faudrait démarrer à la manivelle.

Repenser le modèle

Et si l’internationalisation ressemblait plutôt à ça ?

jsx
<h1><T>Hello world!</T></h1>
<p>
  <T>
    <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
  </T>
</p>

Pas de clés de traduction.

Aucun dictionnaire JSON.

Aucun pipeline manuel.

Juste du texte.

Une approche différente

Cette idée est au fondement même de 18ways.

18ways traite la traduction comme une préoccupation d’exécution optimisée. Extraire les clés de traduction et gérer les fichiers de traduction est un problème pour les machines, pas pour les humains.

Les développeurs se contentent de marquer le texte qu’ils veulent faire traduire.

Dans les coulisses, 18ways :

Tout reste compatible avec le SSR et sûr pour le SEO.

Traductions sensibles au contexte

Les systèmes d’i18n traditionnels perdent le contexte.

Un traducteur pourrait voir quelque chose comme :

text
home

Mais qu’est-ce que cela signifie ?

En allemand, ces sens exigent des mots complètement différents :

Si vous deviez traduire « home » en allemand, qu’aimeriez-vous voir en priorité ? Une chaîne isolée, ou la page où elle apparaît réellement ?

Comparaison entre la traduction d’une chaîne JSON isolée et la traduction dans le contexte complet du site web

Les systèmes de traduction qui ne voient que des chaînes isolées peinent à gérer ces distinctions.

18ways analyse les traductions dans le contexte de l’UI réelle.

Nos agents backend examinent les traductions telles qu’elles apparaissent sur de vraies pages et optimisent pour :

Pour celles et ceux qui connaissent les noms composés allemands, pas d’inquiétude, la détection de dépassement est incluse elle aussi.

Donner les moyens aux traducteurs humains

Tout ce qui aide l’IA à produire de meilleures traductions aide aussi les traducteurs humains.

18ways offre aux traducteurs le même environnement tenant compte du contexte que celui utilisé par nos agents IA.

Au lieu de modifier des fichiers JSON, les traducteurs relisent le texte directement dans l’UI où il apparaît.

Cela améliore considérablement la précision des traductions et l’efficacité du workflow.

À quoi ressemble une meilleure i18n

L’internationalisation n’a pas besoin d’une couche supplémentaire de clés de traduction, de fichiers de chaînes et de glue pour le pipeline.

Les applications modernes disposent déjà de la structure, du contexte et des informations d’exécution dont nous avons besoin pour faire mieux.

La prochaine génération d’i18n devrait être conçue pour les applications rendues côté serveur, le contenu dynamique, les workflows natifs de l’IA et les traducteurs humains travaillant côte à côte.

C’est dans cette direction que va 18ways.

Changement de langue