i18n : Le guide essentiel de l'internationalisation des logiciels

Résumez ce post avec : 9 min de lecture

ChatGPT Perplexité Grok Google IA

L'internationalisation (i18n) est le travail que vous effectuez en code afin qu'un produit puisse être adapté à n'importe quelle langue ou région sans être repensé. Le W3C le définit comme “la conception et le développement d'un produit, d'une application ou d'un contenu de document qui permet une localisation facile pour des publics cibles qui varient en culture, en région ou en langue” (W3C). En pratique, cela signifie Unicode partout, pas de chaînes codées en dur destinées à l'utilisateur, un formatage des dates, des nombres et des pluriels tenant compte des paramètres régionaux, et des mises en page qui survivent à un texte plus long et à des scripts de droite à gauche.

Principaux points à retenir

• i18n est une ingénierie ; la localisation (l10n) est l'adaptation à un marché que i18n rend possible. Les “18” et “10” comptent les lettres entre la première et la dernière lettre de chaque mot.
• Les cinq habitudes qui empêchent la plupart des bugs i18n : UTF-8 de bout en bout, chaînes externalisées, gestion plurielle et variable de style ICU, API de formatage des paramètres régionaux de la plateforme et mises en page flexibles.
• Ne construisez jamais de phrases en concaténant des fragments. L’ordre des mots et les règles plurielles diffèrent trop selon les langues.
• Testez avec une pseudo-localisation avant qu'un traducteur ne voie les chaînes.
• Un site Web déjà en ligne et qui n'a pas été conçu pour i18n peut toujours être rendu multilingue au niveau de la couche de rendu, sans refactoriser la base de code.

i18n, l10n et g11n : la différence

Le W3C énumère ce que l'internationalisation inclut généralement : la suppression des barrières à la localisation (Unicode et codage de caractères), la prise en charge de fonctionnalités telles que le texte bidirectionnel, la prise en charge des conventions locales pour les dates, les calendriers, les nombres et les noms, et “la séparation des éléments localisables du code source” afin que la bonne version se charge pour chaque utilisateur (W3C).

Voici un test simple pour savoir si le travail i18n est terminé : l'ajout d'un nouveau langage devrait nécessiter des traducteurs et une certaine configuration. S'il a besoin d'un développeur, quelque chose a été manqué.

1. Utilisez Unicode (UTF-8) de bout en bout

UTF-8 est la valeur par défaut pour le Web, utilisée par 99,1 % des sites Web dont le codage des caractères est connu (W3Techs, 28 septembre 2026). De nos jours, les erreurs sont rarement dans le HTML. Ils se produisent dans les couches qui l'entourent :

• Colonnes et connexions de base de données qui ne sont pas définies sur UTF-8 complet. Dans MySQL, utf8 est un sous-ensemble de 3 octets ; utiliser utf8mb4 ou des emoji et certains personnages CJK seront perdus.
• Fonctions de chaîne qui comptent les octets au lieu des caractères, ce qui tronque « Zürich » ou « 東京 » au milieu d'un caractère.
• Exportations CSV ouvertes dans un logiciel de feuille de calcul avec un codage incorrect.
• Tri avec ordre des octets au lieu de collation des paramètres régionaux, ce qui place “Äpfel” après “Zebra”.

Déclarez l'encodage une fois (<meta charset="utf-8">), définissez-le sur chaque connexion et utilisez une comparaison tenant compte des paramètres régionaux, telle que Intl.Collator dans JavaScript.

2. Externaliser chaque chaîne destinée à l'utilisateur

Les chaînes que les utilisateurs voient appartiennent à des fichiers de ressources, indexés par un identifiant. Gardez-les hors des modèles et du code :

{
  "cart.title": "Your cart",
  "cart.empty": "Your cart is empty",
  "cart.checkout": "Go to checkout"
}

Chaque locale obtient son propre fichier et le code le demande cart.title. Les frameworks suivent le même modèle : dans Vue, la bibliothèque vue-i18n expose $t pour “traduction locale du message” et $i18n pour l'instance globale qui gère les paramètres régionaux et les messages (Documentation vue-i18n). Réagir (react-intl, i18next), Angular (@angular/localize), Django, Rails et Laravel livrent tous un équivalent.

Quelques règles qui épargnent la douleur plus tard :

• Donnez un contexte aux traducteurs. “Ouvrir” peut être un verbe (ouvrir le fichier) ou un adjectif (le magasin est ouvert). Ajoutez une description à chaque clé.
• Ne réutilisez pas une clé simplement parce que le texte anglais correspond. “Enregistrer” sur un bouton et “Enregistrer 20 %” dans une bannière sont des messages différents dans la plupart des langues.
• Gardez le balisage hors des chaînes lorsque vous le pouvez, ou utilisez des espaces réservés pour cela, afin que les traducteurs ne puissent pas casser votre HTML.

3. Ne concaténez jamais de phrases ; utilisez des espaces réservés et des règles plurielles

Cela semble inoffensif :

'You have ' + count + ' new messages';

Il se brise de deux manières. L'ordre des mots change entre les langues, et les règles plurielles ne sont pas “1 contre tout le reste”. Les règles plurielles Unicode CLDR donnent à l'anglais deux catégories cardinales (une, autre), au japonais une, au russe et au polonais quatre (une, peu, beaucoup, autre) et à l'arabe six (zéro, une, deux, peu, beaucoup, autre) (CLDR Unicode).

Utilisez un format de message qui connaît ces règles, tel que ICU MessageFormat :

{count, plural,
  =0 {You have no new messages}
  one {You have # new message}
  other {You have # new messages}}

Un traducteur russe peut alors ajouter le few et many formulaires sans aucune modification de votre code. Il en va de même pour le genre, les nombres ordinaux (“1er, 2e”) et les listes (“A, B et C”).

4. Laissez la plateforme formater les dates, les chiffres et la devise

03/04/2026 c'est le 4 mars aux États-Unis et le 3 avril dans la majeure partie de l'Europe. 1,234.5 en anglais est écrit 1.234,5 en allemand et 1 234,5 en français. N'écrivez pas votre propre formatage. Chaque plate-forme moderne dispose de données locales intégrées, et dans JavaScript, c'est le Intl API (MDN):

new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }).format(1234.5);
// "1.234,50 €"

new Intl.DateTimeFormat('fr-FR', { dateStyle: 'long' }).format(new Date('2026-09-27'));
// "27 septembre 2026"

Certaines décisions connexes méritent d’être prises tôt :

• Stockez l'heure en UTC et convertissez-la dans le fuseau horaire de l'utilisateur pour l'afficher.
• Gardez la monnaie séparée des paramètres régionaux. Un visiteur francophone au Canada paie en CAD et non en EUR. Formater un nombre en monnaie est i18n ; décider du prix est une décision commerciale.
• Ne présumez pas comment les noms et les adresses sont façonnés. Beaucoup de gens n'ont pas de “prénom” et “nom de famille” au sens occidental du terme, et les codes postaux ne sont pas toujours numériques.

5. Concevez des mises en page qui s'étirent et se retournent

Le texte traduit est souvent plus long que l’anglais et les chaînes courtes sont celles qui poussent le plus. Le W3C résume les chiffres indicatifs d'IBM : les chaînes jusqu'à 10 caractères peuvent augmenter de 200 à 300 % dans les langues européennes, tandis que le texte de plus de 70 caractères augmente jusqu'à environ 130 % (W3C, Taille du texte en traduction). Leur exemple est l'italien qui transforme “vues” en “visualizzazioni”.

Pour le travail de l'interface utilisateur, cela signifie :

• Pas de boutons ou d'onglets à largeur fixe dimensionnés pour les étiquettes anglaises.
• Aucun texte intégré dans les images. Il ne peut pas être traduit sans redessiner l'image.
• Prend en charge les écritures de droite à gauche (arabe, hébreu, persan, ourdou) avec dir="rtl" sur le <html> élément et propriétés logiques CSS (margin-inline-start au lieu de margin-left), donc la mise en page se reflète d'elle-même.
• Choisissez des polices qui couvrent les scripts que vous prévoyez de prendre en charge ou définissez des solutions de secours.

6. Gérez délibérément la détection des paramètres régionaux et les URL

Décidez comment les paramètres régionaux d'un utilisateur sont choisis et comment ils sont mémorisés :

1. Un choix explicite (un changement de langue) gagne toujours.
2. Sinon, utilisez le navigateur Accept-Language en-tête comme suggestion, pas comme redirection forcée.
3. Mettez les paramètres régionaux dans l'URL (/de/, de.example.com) pour n'importe quelle page publique, afin que chaque version linguistique puisse être partagée, mise en cache et indexée par les moteurs de recherche. Les cookies à eux seuls rendent les pages traduites invisibles pour Google.

Si le produit comporte des pages publiques, ces URL linguistiques nécessitent également des annotations hreflang ; voir le guide de hreflang.

7. Test avec pseudo-localisation

La pseudo-localisation remplace vos chaînes sources par une version modifiée avant qu'une véritable traduction n'existe, par exemple [Ýöûŕ çåŕţ îš éɱþţý !!!!]. Les accents détectent les problèmes d'encodage, le remplissage détecte les mises en page qui se cassent sous un texte plus long et les crochets révèlent la troncature et toute chaîne codée en dur qui n'a pas changé. De nombreuses bibliothèques i18n et outils de construction peuvent générer une pseudo-locale ; exécutez votre suite de tests d'interface utilisateur dessus à chaque version.

Ajoutez-les également à votre liste de contrôle :

• Passez à un paramètre régional RTL et vérifiez la navigation, les icônes avec direction (flèches, barres de progression) et l'alignement du formulaire.
• Tester le tri et la recherche avec des caractères accentués.
• Vérifiez les e-mails, les PDF, les messages d’erreur et les notifications push, qui sont souvent oubliés.

Une liste de contrôle i18n pour les nouveaux projets

• UTF-8 (utf8mb4 dans MySQL) dans les fichiers, la base de données, les connexions et les API
• Toutes les chaînes destinées à l'utilisateur dans les fichiers de ressources, avec contexte pour les traducteurs
• Format de message ICU (ou équivalent) pour les pluriels, le sexe et les variables
• Intl ou les API locales de la plateforme pour les dates, les nombres, la devise, les listes et le tri
• Stockage UTC et affichage du fuseau horaire par utilisateur
• Dispositions flexibles, propriétés logiques CSS, dir prise en charge des attributs
• Locale dans l'URL pour les pages publiques, hreflang pour les moteurs de recherche
• Pseudo-localisation dans CI

Lorsque le site Web existe déjà

Tout ce qui précède s’applique à une application que vous créez. Pour un site marketing, un magasin ou un CMS déjà en ligne, cela signifie une refactorisation importante, et l'équipe propriétaire du contenu n'est généralement pas l'équipe propriétaire du code.

Dans ce cas, la traduction peut avoir lieu au niveau de la couche de rendu. ConveyThis lit le texte que votre site génère déjà, le traduit dans l'une des 210 langues et sert chaque langue sur sa propre URL (sous-dossier ou sous-domaine du Business plan et supérieur, ou un ?lang paramètre) avec hreflang ajouté automatiquement. Les langues de droite à gauche font changer la direction du texte, les images peuvent être remplacées par langue et un glossaire et mémoire de traduction gardez les noms et les termes des produits cohérents. Il s'installe comme un Plugin WordPress, une application Shopify ou un seul script sur n'importe quelle autre pile, afin que le travail i18n dans votre base de code puisse continuer selon son propre calendrier. Pour le côté commercial de l'adaptation du contenu à chaque marché, lisez notre guide sur en quoi consiste la localisation de contenu.

Questions fréquemment posées

Pourquoi l’internationalisation est-elle abrégée en i18n ? Il y a 18 lettres entre le premier “i” et le dernier “n” dans “internationalisation”. La localisation (l10n) suit le même modèle.

Est-ce que i18n est la même chose que la traduction ? Non. La traduction est une partie de la localisation. i18n est l'ingénierie qui permet à la traduction, et à toutes les autres adaptations locales, de se produire sans modification de code.

Quand un projet doit-il démarrer i18n ? Au début. L'externalisation des chaînes et l'utilisation d'API locales coûtent peu le premier jour et beaucoup lorsqu'elles sont intégrées à une base de code mature.

Qu'est-ce que $i18n dans Vue ? Dans vue-i18n, $i18n est l'instance globale qui gère les lieux et les messages, et $t est la fonction qui renvoie un message traduit pour une clé (vue-i18n).

Étape suivante

Si vous avez besoin d'un site Web en direct en plusieurs langues avant que la base de code ne soit entièrement internationalisée, créer un compte ConveyThis et publiez votre première langue, puis comparez plans quand vous en ajoutez plus.