L'internationalisation (souvent abrégée en i18n), la localisation (l10n) et le soutien multilingue décrivent tous la même idée : adapter votre produit afin que les gens puissent l'utiliser dans leur propre langue.

i18n est toujours construit comme si c'était 2005

Chaque entreprise finit par réaliser 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 par les dents et dit : « Combien de pages parlons-nous ? Cela fait au moins quatre sprints. »

La manière dont nous mettons en œuvre l'i18n n'a pas changé depuis 20 ans. La plupart des "meilleures pratiques" en matière d'i18n ont été établies bien avant les architectures web modernes, et tout ce qui a suivi a simplement été superposé à celles-ci.

L'I18n est la seule partie du développement web moderne qui implique encore l'exportation de fichiers et leur envoi à quelqu'un. On considère qu'il s'agit d'une configuration moderne si, au lieu de les envoyer par e-mail, vous les téléchargez via une API.

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

Pourquoi l'i18n semble cassé

Le développement web moderne a évolué incroyablement rapidement.

Nous avons :

• composants rendus par le serveur
• interface de streaming
• exécutions en périphérie
• déploiement continu
• Outils natifs de l'IA

Pourtant, les flux de travail d'internationalisation semblent toujours appartenir à une époque différente.

Même les applications relativement petites finissent rapidement par jongler avec :

• clés de traduction
• Fichiers de traduction JSON
• pipelines de traduction manuelle
• logique de localisation isolée pour le frontend et le backend
• outils de gestion de la traduction

Les développeurs ne cherchent pas à construire des systèmes comme celui-ci. Ils y entrent par inadvertance, alors que des obstacles courants en i18n font trébucher des développeurs peu familiers avec la manière dont les différentes langues structurent les phrases de manière complètement différente… et acceptent à contrecœur le statu quo établi il y a 20 ans.

Au fil du temps, l'internationalisation devient l'une des parties les plus complexes de la pile.

L'interface utilisateur moderne ne s'intègre pas dans les chaînes de traduction.

Considérez une interface utilisateur simple :

<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. Donc, nous extrayons le texte dans un fichier de traduction :

{
  "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 :

<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, avons-nous maintenant du texte en anglais à la fois dans notre code et dans notre fichier de traduction ? Oui. Différentes bibliothèques i18n appliquent des styles différents, mais essayer de traduire un texte qui est partiellement formaté en le sortant dans un fichier JSON lisible par un humain est une bataille perdue.

L'interface utilisateur moderne est structurée, mais les systèmes de traduction sont construits sur la base de chaînes de caractères plates.

Une fois que le balisage, les variables et le contenu dynamique entrent en jeu, l'abstraction commence à fuir.

Le contenu dynamique et généré par les utilisateurs brise l'i18n traditionnel

Les choses deviennent encore plus difficiles lorsque le contenu n'est pas statique.

Prenez cet exemple à nouveau :

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

Cette chaîne provient d'une API. Comment pouvons-nous la transformer en une clé de traduction ?

Spoiler : vous ne le faites pas. Maintenant, votre backend doit également prendre en charge l'internationalisation.

Votre backend doit maintenant gérer :

• les données sémantiques originales
• variantes traduites
• logique de secours
• détection de la locale

Les traducteurs ont soudainement besoin d'accéder aux systèmes backend également.

Et le problème ne fait que croître lorsque le contenu généré par les utilisateurs entre en jeu.

Avis. Commentaires. Annonces sur le marché. Forums.

Les pipelines i18n traditionnels supposent 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 lente évolution de l'écosystème i18n.

La détection de la locale est toujours un désastre

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

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

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

Cela indique au serveur :

1. Préférez l'anglais britannique
2. Alors toute forme d'anglais
3. Alors toute forme de français

En pratique, mettre cela en œuvre correctement implique :

• analyse des poids de qualité
• normalisation des locales (en, en-GB, en-US)
• langues prises en charge correspondantes
• gestion de la logique de secours
• respect des remplacements explicites de l'utilisateur

De nombreux frameworks laissent la plupart de cette logique aux développeurs.

Même la détection de locale de base devient souvent du code d'application personnalisé.

Le changement de langue est une réflexion après coup

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

Les utilisateurs ont toujours besoin d'un moyen de changer de langue.

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

• commutateurs de langue
• routage local
• persistance des cookies
• Canonicalisation d'URL
• hreflang tags pour le SEO

Ces détails peuvent sembler insignifiants, mais ils deviennent rapidement une quantité significative de plomberie d'application, surtout si vous n'êtes pas familier avec toutes les subtilités de l'i18n. La plupart des entreprises et des développeurs ne le sont pas.

Le Raccourci : Traduction Automatique de Site Web

Étant donné 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 développent des versions de plus en plus sophistiquées de cette idée. Malheureusement, elles introduisent un ensemble différent de problèmes :

• les traductions se font souvent côté client
• Pannes SEO
• le contenu chargé dynamiquement ne peut pas être traduit sans un scintillement de langue incorrecte
• le contrôle du développeur disparaît

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

Comment nous avons fini ici

Nous avons commencé avec quelque chose de magnifiquement simple :

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

Et cela a abouti à 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 d'i18n s'attendent à des flux de travail conçus pour une époque différente, comme une Ferrari avec un démarreur à manivelle.

Repenser le modèle

Et si l'internationalisation ressemblait davantage à cela ?

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

Aucune clé de traduction.

Pas de dictionnaires JSON.

Pas de pipelines manuels.

Juste du texte.

Une approche différente

Cette idée est la base derrière 18ways.

18ways considère la traduction comme une préoccupation d'exécution optimisée. L'extraction des clés de traduction et la gestion des fichiers de traduction sont des problèmes pour les machines, pas pour les humains.

Les développeurs marquent simplement le texte qu'ils souhaitent traduire.

Dans les coulisses, 18ways:

• extrait les chaînes
• génère des traductions en utilisant l'IA
• met en cache les résultats
• sert du HTML traduit directement depuis le serveur

Tout reste compatible avec SSR et sécurisé pour le SEO.

Traductions Contextuelles

Les systèmes i18n traditionnels perdent le contexte.

Un traducteur pourrait voir quelque chose comme :

home

Mais qu'est-ce que cela signifie ?

En allemand, ces significations nécessitent des mots complètement différents :

• Maison - une maison
• Page d'accueil - la page d'accueil
• Commencer - une étiquette de navigation
• au début - retourner au début

Si vous deviez traduire « maison » en allemand, que préféreriez-vous voir ? Une chaîne isolée, ou la page où elle apparaît réellement ?

Les systèmes de traduction qui ne voient que des chaînes isolées ont du mal avec ces distinctions.

18ways analyse les traductions dans le contexte de l'interface utilisateur réelle.

Nos agents backend examinent les traductions telles qu'elles apparaissent sur des pages réelles et optimisent pour :

• contexte
• cohérence
• contraintes de mise en page
• qualité de traduction

Pour quiconque est familier avec les noms composés allemands, ne vous inquiétez pas, la détection de débordement est également incluse.

Autonomiser les traducteurs humains

Tout ce qui aide l'IA à produire de meilleures traductions aide également les traducteurs humains.

18ways fournit aux traducteurs le même environnement sensible au contexte que celui utilisé par nos agents IA.

Au lieu de modifier des fichiers JSON, les traducteurs examinent le texte directement dans l'interface utilisateur où il apparaît.

Cela améliore considérablement la précision de la traduction et l'efficacité du flux de travail.

À quoi ressemble une meilleure internationalisation

L'internationalisation n'a pas besoin d'une autre couche de clés de traduction, de fichiers de chaînes et de colle de pipeline.

Les applications modernes ont déjà la structure, le contexte et les informations d'exécution dont nous avons besoin pour faire cela mieux.

La prochaine génération de l'i18n devrait être conçue pour des applications rendues sur serveur, du contenu dynamique, des flux de travail natifs à l'IA et des traducteurs humains travaillant côte à côte.

C'est la direction que prend 18ways.