La traduction est relue. La page construite, souvent pas.

Une chaîne peut être correcte dans le fichier et fausse à l’écran — tronquée dans un bouton, coupée au milieu d’un mot en chinois, mal triée dans une liste déroulante, ou posée à côté d’un format de date que personne ne lit ainsi sur ce marché. Aucune de ces erreurs n’est une erreur de traduction. Toutes atteignent le client.

Le test de localisation est l’étape qui les intercepte, et il se fait sur le produit construit, en contexte, sur les appareils que le marché utilise vraiment.

Hypothèse de travail

La plupart des bugs de localisation découverts après le lancement ne sont pas des défauts de traduction. Ce sont des défauts d'intégration : un texte correct placé dans une mise en page, un format ou un chemin de code jamais vérifié dans cette locale.

Test d’internationalisation vs test de localisation

On les fusionne en une seule étape, et c’est pourquoi les mêmes bugs reviennent à chaque lancement. Ils posent des questions différentes et interviennent à des moments différents.

Le test d’internationalisation (i18n) demande si le build peut supporter n’importe quelle locale. Il se fait une fois, sur la base de code, idéalement avant que la traduction commence. L’interface accepte-t-elle des chaînes plus longues ? Le texte est-il externalisé ou codé en dur ? L’encodage survit-il aux caractères non latins ? Dates et nombres sont-ils formatés par locale ou supposés ?

Le test de localisation (L10n) demande si cette locale est juste. Il se fait par langue, sur le site construit, après traduction. La terminologie est-elle correcte pour ce marché ? La mise en page tient-elle avec le texte réel de cette langue ? Les conventions locales sont-elles respectées ?

Faire l’i18n d’abord est ce qui rend le L10n bon marché. Sautez-le, et chaque langue redécouvrira le même défaut structurel.

La checklist en un coup d’œil

• Préparation i18n — 6 points : chaînes externalisées · encodage · formatage par locale · tolérance à l’expansion · support bidirectionnel si besoin · passe de pseudo-localisation
• Langue en contexte — 5 points : terminologie contre le glossaire · ton et registre · troncatures et abréviations · placeholders et variables · formulations juridiques et de sécurité
• Mise en page et typographie — 6 points : expansion du texte · césure · police de repli · rythme vertical · images avec texte incrusté · comportement à chaque breakpoint
• Fonctionnel et formats — 6 points : dates et heures · nombres et devises · adresses et téléphones · tri et recherche · validation de formulaire · unités de mesure
• Passe avant mise en ligne — 4 points : hreflang et sélecteur de langue · métadonnées SEO par locale · pages légales et consentement · vérification sur appareil réel dans le marché

Chaque section ci-dessous détaille ce qu’il faut réellement regarder.

Préparation à l’internationalisation

À faire avant la traduction, une fois, sur la base de code.

• Les chaînes sont externalisées. Aucun texte visible codé en dur dans les templates ou le code. Une chaîne qu’on ne peut pas extraire ne peut être ni traduite ni testée.
• L’encodage est cohérent de bout en bout. UTF-8 au stockage, au transport et à l’affichage. Testez avec une chaîne mêlant CJK, latin accentué et un emoji ; tout ce qui se casse est un problème de pipeline, pas de police.
• Le formatage suit la locale. Dates, nombres, devises et pluriels résolus par locale plutôt que figés sur le marché d’origine.
• La mise en page tolère l’expansion. L’allemand et le français font couramment 20 à 35 % de plus que l’anglais ; le russe et le finnois peuvent aller au-delà. Boutons à largeur fixe et libellés sur une ligne sont les premiers à céder.
• Support bidirectionnel si un marché RTL figure à la feuille de route. Ajouter le RTL après coup coûte nettement plus cher que le prévoir maintenant.
• Passe de pseudo-localisation. Remplacez les chaînes par des équivalents accentués et rallongés mais lisibles — [Ĉöñƒïŕɱ öŕðéŕ……]. Toutes les chaînes codées en dur, tous les points de troncature et toutes les ruptures de mise en page apparaissent d’un coup, alors qu’aucun mot n’a encore été traduit.

La langue en contexte

Par langue désormais, sur le site construit.

• La terminologie correspond au glossaire. Non pas « est-ce une traduction raisonnable » mais « est-ce le terme approuvé pour ce marché » — contre la liste que tout l’ensemble de contenus utilise.
• Ton et registre collent à la surface. Un microtexte, un paragraphe juridique et un titre marketing ne doivent pas sonner comme traduits d’une seule et même manière.
• Troncatures et abréviations sont délibérées. Là où le texte a été raccourci pour tenir, vérifiez que la forme courte reste correcte et idiomatique — et non les N premiers caractères.
• Placeholders et variables s’assemblent correctement. L’ordre des mots change d’une langue à l’autre ; une phrase assemblée dans l’ordre anglais peut être absurde ailleurs. Vérifiez chaque chaîne interpolée avec de vraies données.
• Les formulations juridiques et de sécurité sont conformes au marché. Garantie, confidentialité et sécurité doivent satisfaire aux exigences locales, pas seulement être exactes. Cela demande une relecture locale, pas une relecture de traduction.

Mise en page et typographie

• L’expansion tient. Testez la chaîne réelle la plus longue de chaque composant, pas la moyenne.
• La césure respecte le système d’écriture. Chinois, japonais et thaï ne se coupent pas aux espaces ; une césure naïve scinde les mots et, en japonais, peut isoler la ponctuation en début de ligne.
• La police de repli est choisie, pas héritée. Si la police de marque ne couvre pas le CJK, c’est le repli que les clients voient réellement.
• Le rythme vertical survit. Les glyphes CJK se positionnent différemment par rapport à la ligne de base latine ; une interligne réglée pour l’anglais paraît souvent serrée en chinois.
• Les images avec texte incrusté sont localisées ou remplacées. Un texte cuit dans une image est invisible pour le pipeline de traduction comme pour les moteurs.
• Chaque breakpoint est vérifié. Une expansion qui passe sur desktop casse souvent la mise en page mobile, où se trouve l’essentiel du trafic.

Fonctionnel et formats de données

• Dates et heures. Ordre, séparateurs, 12 ou 24 heures, affichage du fuseau. 03/04 désigne deux jours différents selon le lecteur.
• Nombres et devises. Séparateurs décimaux et de milliers s’inversent d’un marché à l’autre ; la place et l’espacement du symbole monétaire changent.
• Adresses et numéros de téléphone. Ordre des champs, format de code postal, et le formulaire accepte-t-il seulement la forme locale.
• Tri et recherche. L’ordre alphabétique dépend de la langue, et le tri CJK connaît plusieurs schémas valides. La recherche doit correspondre à la façon dont les gens tapent, y compris sans diacritiques.
• Validation de formulaire. Champs de nom exigeant l’alphabet latin, motifs de code postal supposant un seul pays, validateurs de téléphone rejetant des numéros locaux valides : parmi les premiers tueurs de conversion.
• Unités de mesure. Converties quand le marché l’attend, pas seulement traduites.

La passe avant mise en ligne

À retenir

Faites le test d'internationalisation une fois sur le build avant traduction, puis le test de localisation par langue sur le site construit. Une passe de pseudo-localisation avant toute traduction repère la majorité des défauts structurels d'un seul coup — et c'est le test le moins cher de cette liste.

• hreflang et sélecteur de langue. Balises correctes et réciproques pour chaque locale ; sélecteur visible et menant à la page équivalente plutôt qu’à l’accueil.
• Métadonnées SEO par locale. Titres, descriptions et données structurées localisés — ni laissés en langue source, ni remplis automatiquement.
• Pages légales et consentement. Confidentialité, conditions, bandeau cookies et texte de consentement présents en langue locale et conformes aux exigences locales.
• Vérification sur appareil réel dans le marché. Idéalement par quelqu’un sur place, avec un appareil et un réseau typiques. Rendu, disponibilité des polices et comportement au chargement diffèrent de la machine d’un développeur.

Où cela s’inscrit

Cette checklist couvre la vérification de ce qui a été construit. Les décisions qui déterminent la quantité à vérifier — périmètre, workflow de mise à jour, responsabilité de relecture, terminologie — se prennent plus tôt et figurent dans la checklist de localisation de site web.

Si vous préparez un lancement multilingue et voulez que la couche de test soit menée correctement plutôt que compressée dans le dernier sprint, notre service de contenus web et produit multilingues l’inclut dans le workflow. Pour un état des lieux, commencez ici.