i18n vs l10n : Quelle est la différence ?

Tout comme le fameux menu *secret* de In-N-Out Burger, chaque niche industrielle possède un langage secret que, une fois maîtrisé, on a l'impression de faire partie d'un groupe privilégié. Le secteur de la traduction et de la localisation ne fait pas exception. Toujours un peu complexés par rapport à nos amis mathématiciens, notre secteur a décidé d'insérer des chiffres au milieu de nos mots clés : i18n et l10n.

Ça a l'air technique et intimidant, n'est-ce pas ?

Il s'avère que c'est simplement un raccourci pour internationalisation et localisation .

L'internationalisation , ou i18n (prononcé « aï-dix-huit-en »), désigne le travail d'ingénierie qui prépare un logiciel à fonctionner dans n'importe quel langage. Il procède en extrayant les chaînes de caractères du code, en gérant l'encodage des caractères et en créant une mise en forme flexible pour les dates, les devises et les unités. L'étape i18n correspond au travail technique en coulisses effectué en préparation de la localisation (étape l10n), qui est réalisée pour chaque langue et chaque marché.

La plupart des pages explicatives que je vois deviennent un peu confuses car elles traitent les modules i18n et l10n comme deux variantes d'une même tâche, puis passent le reste de l'article à parler de bibliothèques de code. Ce ne sont pas les mêmes tâches. L'internationalisation est une tâche que votre équipe d'ingénierie effectue, idéalement une seule fois ! La localisation, en revanche, c'est ce qui arrive à votre site web chaque fois que vous ajoutez un marché ; c'est ce qui détermine si un visiteur multilingue se sent bienvenu lors de sa visite ou s'il a l'impression d'être entré dans la vallée de l'étrange, c'est-à-dire que quelque chose cloche sans qu'il puisse mettre le doigt dessus.

Cette distinction ne se résume pas à une simple question de pédanterie de ma part (c'en est une, certes, mais dans ce cas précis, elle est importante pour les équipes qui effectuent la localisation !). Un site peut être parfaitement internationalisé et pourtant être perçu comme « incohérent » dans la langue cible. Votre équipe a veillé à concevoir des boutons extensibles pour s'adapter à l'affichage du texte allemand, des étiquettes de prix avec le symbole monétaire approprié et des dates estampillées dans un format familier au lecteur. That’s i18n! Mais qu'en est-il de la phrase à côté du bouton ? Est-ce que ça sonne comme si c'était écrit par quelqu'un qui connaît le marché, ou comme si c'était passé par une application de traduction automatique et publié tel quel sur la page ? C’est le rôle de la localisation, et c’est le facteur déterminant qui choisit si le visiteur clique ou s’il quitte le site.

Que signifie réellement i18n ?

Je l'ai déjà dit, mais il est important de le préciser (jeu de mots voulu) : l'internationalisation est un numéronyme. Prenez la première lettre (i), la dernière lettre (n), comptez les 18 lettres entre elles, et voilà , vous obtenez i18n. C'est une abréviation qui s'est imposée car les développeurs cherchaient un moyen de taper le mot sans avoir à l'épeler cinquante fois lors d'une revue de code. Par conséquent, l10n pour la localisation et a11y pour l'accessibilité, etc.

Mais l'abréviation, c'est la partie ennuyeuse. Ce qui compte, c'est ce que fait réellement le cours i18n .

Il s'agit du processus de structuration d'un code source afin qu'il puisse prendre en charge n'importe quel langage ou paramètre régional sans réécriture :

• Les chaînes de caractères sont extraites du code et placées dans des fichiers externes, au lieu d'être codées en dur.
• Encodage UTF-8, permettant un rendu correct des caractères accentués et des alphabets non latins.
• Mise en page qui ne suppose pas que le texte se lit toujours de gauche à droite
• Les formats de date, de nombre et de devise sont traités comme des variables, et non comme des hypothèses fixes.

Bien menée, la matière i18n est comme l'eau pour un poisson rouge : invisible et imperceptible (dans le meilleur sens du terme).

l10n : la partie qui ne se termine jamais

Si i18n représente la voiture, alors l10n représente le carburant. Lorsque vous décidez d'ajouter le français, vous effectuez une localisation. Lorsque vous ajoutez du japonais, vous effectuez une nouvelle localisation. Il ne s'agit pas d'une phase ponctuelle, mais d'un processus continu, c'est pourquoi la localisation nécessite son propre flux de travail, son responsable et ses outils, distincts de ceux de l'ingénierie.

Une équipe peut commercialiser un produit véritablement internationalisé et pourtant échouer en matière de localisation, car la localisation ne se limite pas à remplacer des mots. Cela peut également inclure des expressions idiomatiques et du niveau de formalité, ainsi que des échanges d'images et même de subtils changements de couleur !

Où la différence apparaît sur une page en direct

Les problèmes de format sont le moyen le plus simple de voir que i18n et l10n fonctionnent séparément.

Prenons les nombres, par exemple. Aux États-Unis, mille dollars et cinquante cents s'écrivent 1,000.50. Dans une grande partie de l'Europe, on écrit la même valeur sous la forme 1.000,50, en inversant la virgule et le point. Un champ monétaire affiche 99.00 $ aux États-Unis et 99,00 € en Allemagne, les symboles étant placés de part et d'autre. Les dates sont encore plus divisées. 03/04/2026 Cela signifie mars 4th aux États-Unis et avril 3rd presque partout ailleurs, ce qui explique l'existence de la norme ISO 8601 (AAAA-MM-JJ), pour contourner l'ambiguïté plutôt que de la débattre pays par pays. Les codes de langue suivent également une norme : la norme ISO 639-1 attribue des codes à deux lettres comme de, ja et pt, ce qui permet à un système de localisation de disposer d’un identifiant stable au lieu de deviner à partir du nom du pays.

L'expansion du texte est l'aspect que les équipes d'ingénierie sous-estiment le plus. Documentation i18n de Phrase Il utilise la pointure de chaussure comme illustration simple : une pointure britannique 10 correspond à une pointure européenne 38, et une pointure américaine 38 correspond à une pointure européenne 6, complètement différente. Maintenant, traduisez une étiquette d'interface utilisateur de la même manière et vous obtiendrez le même type d'inadéquation de longueur de mot. L'allemand et le finnois sont généralement 20 à 35 % plus longs que le texte source anglais, c'est pourquoi un bouton intitulé « Soumettre » s'affiche correctement et « Zur Kasse gehen » non, sauf si la mise en page a été construite avec des conteneurs flexibles. L'arabe et l'hébreu, étant des langues RTL (de droite à gauche), ajoutent un problème totalement différent : toute la mise en page est symétrique, et pas seulement le sens du texte.

Aucun de ces problèmes n'est résolu de manière satisfaisante au moment de la traduction. Cela devrait être résolu dans le code, d'où mon insistance à bien faire le module i18n avant de commencer le module l10n .

Le processus : bâtir sa maison sur des fondations solides

Dans une configuration saine, l'internationalisation a lieu une seule fois et la localisation se répète indéfiniment par-dessus. Vous extrayez vos chaînes de caractères, définissez votre encodage et créez des mises en page flexibles en une seule fois. Ensuite, vous localisez en français. Ensuite, vous effectuerez la localisation en japonais. Plus tard encore, l'arabe, sans pour autant toucher à l'architecture sous-jacente, car celle-ci avait été conçue dès le départ pour s'adapter à n'importe quel contexte local.

Ce qui fait trébucher les équipes, c'est de sauter la première étape et d'essayer de la rattraper lors de la seconde. C'est là que vous vous retrouvez avec des chaînes de caractères codées en dur, enfouies à trois niveaux de composants, et des sélecteurs de date qui ne comprennent que le format MM/JJ/AAAA. Finalement, le projet de traduction se transforme en une refonte que personne n'avait prévue.

Devons-nous reconstruire notre infrastructure ?

J'ai assisté à suffisamment de réunions commerciales pour savoir ce qui inquiète la plupart des équipes : « Faut-il reconstruire toute notre infrastructure pour bien faire les choses ? » L'hypothèse sous-jacente est que si leur site n'a pas été internationalisé dès le départ, une localisation correcte implique une refonte complète. La plupart du temps, la réponse est NON.

Si la couche de localisation s'exécute par-dessus le site existant au lieu d'être intégrée à son code source, aucune reconstruction n'est nécessaire. Je dévoile un peu mon jeu, mais c'est précisément comme ça que fonctionne Bablic . La plupart du temps, un extrait de code JavaScript léger s'exécute dans le navigateur du visiteur et remplace le texte traduit par le texte correspondant à la langue appropriée au moment de la requête, sans avoir à explorer ni à reconstruire le site d'origine (le serveur original où se trouve réellement la page).

Le problème de performance qui en découle généralement est qu'une approche côté navigateur implique le chargement d'un corpus de traduction complet à chaque affichage de page. Si cela vous préoccupe réellement, choisissez un outil qui propose la mise en cache avant traduction, qui stocke le texte précédemment traduit afin que le navigateur n'ait pas à interroger une API de traduction à chaque requête.

Vous vous dites sûrement : « Mais mon produit est une application native avec une logique conditionnelle profondément imbriquée et aucune séparation entre les chaînes de caractères et le code… » blablabla. Eh bien, voilà un problème d'ingénierie qu'une couche côté navigateur ne résoudra pas ! Dans ce cas, recherchez une solution avec un SDK. Mais pour les sites marketing et les boutiques en ligne, les pages initialement conçues dans une seule langue et qui doivent désormais desservir cinq marchés, l'hypothèse de réarchitecture est généralement erronée.

Ne traduisez pas sans contexte

Une page peut réussir tous les i18n contrôles (la devise est correcte, le format de date est correct) et pourtant paraître manifestement étrangère à la personne à qui elle est censée s'adresser. Les clients peuvent se rendre compte qu'un message est raté ou même légèrement erroné, et ceux qui le remarquent ne convertissent pas. C'est cette fameuse vallée de l'étrange dont je parlais plus tôt, et c'est un véritable frein à la conversion.

Comprendre et faire respecter le contexte permet de résoudre ce problème. Tout d'abord, en contrôlant des termes spécifiques, comme le nom de votre marque et les noms propres de votre produit, vous vous assurez que les expressions clés soient toujours traduites de la même manière, indépendamment des valeurs par défaut d'un moteur de traduction automatique. Un glossaire permettant de valider ces choix est ce qui garantit qu'une page traduite reflète votre marque, au lieu d'une version générique adressée à personne en particulier.

La seconde est la possibilité de consulter la page traduite et de corriger directement les erreurs, sans avoir besoin de maîtriser la langue cible pour repérer une expression maladroite. Un éditeur contextuel affiche la page traduite en direct et vous permet de la modifier directement, ce qui signifie qu'un collègue hispanophone peut vérifier le résultat en quelques minutes au lieu qu'un traducteur refasse tout à partir d'une feuille de calcul.

Pour la plupart des pages, la traduction automatique (TA) est un point de départ raisonnable. Les moteurs par défaut de Bablic sont Google Translate et DeepL, qui traitent la première ébauche à une vitesse qu'aucune équipe humaine ne peut égaler. Pour la plupart des entreprises avec lesquelles nous discutons, ces moteurs, associés à un glossaire et à une vérification ponctuelle avec un éditeur contextuel, suffisent à donner l'impression que votre site est véritablement localisé.

FAQ