10 Common i18n Mistakes Developers Make | Fix Guide 2025

L’internationalisation (i18n) semble simple — jusqu’à ce que vous découvriez que vos utilisateurs allemands voient des boutons tronqués, vos utilisateurs japonais obtiennent des fragments de phrases tronqués et vos utilisateurs arabophones se retrouvent avec des mises en page complètement cassées. Ce ne sont pas des cas isolés. Ce sont les conséquences prévisibles d’erreurs fréquentes que la plupart des équipes de développement commettent en abordant la localisation pour la première fois. Dans ce guide, nous parcourons les 10 erreurs i18n les plus courantes, expliquons exactement pourquoi elles se produisent et vous montrons étape par étape comment corriger chacune. Que vous construisiez une nouvelle application ou que vous mettiez à jour une application existante, éviter ces pièges vous fera gagner des semaines de débogage et offrira une expérience soignée aux utilisateurs du monde entier.

Erreur n°1 : chaînes codées en dur

Les chaînes codées en dur (hardcode) sont l’erreur i18n la plus fondamentale. Cela se produit lorsque les développeurs se concentrent d’abord sur le fait que les fonctionnalités fonctionnent et prévoient de tout nettoyer plus tard. Mais plus tard ne vient jamais, et tout à coup vous avez des milliers de chaînes réparties sur des centaines de fichiers.

['Mettez en place votre cadre i18n avant même d’écrire la première ligne de code UI', 'Utilisez un plugin de lint pour détecter les chaînes codées en dur dans les templates et les composants', 'Conservez les clés de traduction descriptives et organisées par fonctionnalité ou page']

Configurez votre framework i18n avant d'écrire la première ligne de code UI.

Utilisez un plugin de linter pour repérer les chaînes codées en dur dans les templates et les composants

Conservez des clés de traduction descriptives et organisées par fonctionnalité ou page.

Un scénario type

Un développeur écrit directement l’étiquette d’un bouton dans JSX : <button>Submit Order</button>.

L’application est livrée en anglais et fonctionne parfaitement. Six mois plus tard, l’entreprise s’étend en Allemagne.

L’équipe de localisation découvre plus de 2 000 chaînes codées en dur. La mise à jour prend 3 semaines et entraîne 47 bugs.

Pourquoi c’est un problème

Dans une base de code mature, les chaînes codées en dur peuvent atteindre des milliers. Les extraire ultérieurement nécessite de toucher chaque fichier, de retester chaque composant et de risquer des régressions partout.

Les chaînes codées en dur sont directement intégrées dans le code source, les modèles ou les composants. Elles ne peuvent pas être extraites, traduites ou échangées à l’exécution sans modifier le code lui-même.

Les utilisateurs qui ne parlent pas anglais voient des éléments d’interface non traduits mélangés à du contenu traduit — une impression chaotique et peu professionnelle.

Comment le corriger

Externalisez toutes les chaînes visibles par l’utilisateur dès le départ dans des fichiers de ressources.

Mettez en place un framework de traduction (par exemple next-intl, react-i18next, vue-i18n) avant d’écrire votre première composante.

Crée une structure de fichiers ressources (par exemple messages/de.json) et référence tous les textes via des clés de traduction telles que t('checkout.submitButton').

Ajoute une règle de lint ou un hook de pré-commit qui marque les littéraux de chaîne bruts dans les composants UI.

Erreur n°10 : Tout traduire mot à mot.

Tout le contenu ne doit pas être traduit. Les noms de marque, les noms des personnes morales, les termes techniques et certains noms de produits doivent rester dans leur langue d'origine. Une traduction excessive peut provoquer des problèmes juridiques, des incohérences de marque et de la confusion chez l'utilisateur.

["Maintenez un glossaire 'à ne pas traduire' et partagez-le avec tous les traducteurs", 'Utilisez des segments verrouillés ou des espaces de noms séparés pour les termes de marque et les termes juridiques', 'Fournissez toujours des notes de contexte pour les chaînes ambiguës afin d'éviter les mauvaises traductions']

Conservez un glossaire 'à ne pas traduire' et partagez-le avec tous les traducteurs

Utilisez des segments verrouillés ou des espaces de noms séparés pour les termes de marque et juridiques

Fournissez toujours des notes de contexte pour les chaînes ambiguës afin d’éviter les erreurs de traduction

Un scénario typique

Un fichier de traduction contient le nom de l’entreprise 'CloudForge Inc.' et le terme technique 'OAuth 2.0 Token' en tant que chaînes à traduire habituelles.

Le traducteur espagnol traduit 'CloudForge' par 'ForjaNube' et 'OAuth 2.0 Token' par 'token OAuth 2.0'.

Résultat : les utilisateurs ne trouvent pas l'entreprise sous son nom réel, et les développeurs qui lisent la documentation en espagnol sont déroutés par des termes techniques traduits inconnus.

Pourquoi cela pose-t-il problème

Un seul nom de marque mal traduit dans un document juridique peut rendre les contrats nuls. Corriger des sur-traductions nécessite de vérifier chaque chaîne dans chaque langue — plusieurs semaines de travail.

Si toutes les chaînes sont envoyées à la traduction sans contexte, les traducteurs peuvent traduire des noms de marque ('Apple' → 'Apfel'), des termes juridiques ('GmbH' → 'LLC') ou des dénominations techniques qui doivent rester en anglais.

Les utilisateurs ne trouvent pas les produits sous leur nom de marque connu, les documents juridiques font référence à la société incorrecte, et la documentation technique devient incompréhensible lorsque des termes tels que 'API Endpoint' sont traduits.

Comment le résoudre

Signalez clairement le contenu non traduit et fournissez des notes de contexte pour les traducteurs.

Créez un glossaire 'à ne pas traduire' qui répertorie tous les noms de marque, noms de produit, personnes morales et termes techniques qui doivent rester inchangés.

Utilisez un espace de noms séparé ou des clés spécifiques pour les contenus non traduits. De nombreux outils i18n prennent en charge des segments 'verrouillés' que les traducteurs ne peuvent pas modifier.

Ajoutez des commentaires/descriptions pour les traducteurs dans vos fichiers de traduction afin d'expliquer le contexte : 'Il s'agit d'un nom de marque — ne pas traduire' ou 'Terme technique — laisser en anglais'.

Erreur n°2 : Concaténation de chaînes

Assembler des phrases à partir de fragments peut sembler logique en anglais, mais cela ne fonctionne pas dans les autres langues. L’ordre des mots, la grammaire et la structure des phrases varient considérablement entre les langues, ce qui rend les chaînes concatenées intraduisibles.

['Ne jamais concaténer des phrases en assemblant des fragments traduits', 'Utiliser des espaces réservés nommés ('{name}') plutôt que positionnels ({0}) pour plus de clarté', 'Fournir des commentaires de contexte pour les traducteurs expliquant ce que contient chaque espace réservé']

Ne construisez jamais des phrases en concaténant des fragments traduits.

Utiliser des espaces réservés nommés ('{name}') plutôt que positionnels ({0}) pour plus de clarté

Fournissez des commentaires de contexte pour les traducteurs expliquant ce que contient chaque espace réservé

Un scénario typique

Le développeur écrit : 'You have ' + count + ' items in your ' + cartType + ' cart' — fonctionne parfaitement en anglais.

Le traducteur allemand reçoit trois fragments séparés et ne peut pas former une phrase grammaticalement correcte, car l'ordre des mots doit changer.

Résultat : les utilisateurs allemands voient 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — maladroit et peu professionnel.

Pourquoi c’est un problème

Chaque chaîne concaténée est une bombe à retardement. Avec 20 langues et 50 chaînes concaténées, vous avez 1 000 fautes de grammaire potentielles à corriger manuellement.

La concaténation de chaînes comme 'Willkommen ' + userName + ', vous avez ' + count + ' nouveaux messages' impose un ordre des mots spécifique. Les traducteurs reçoivent des fragments déconnectés qu’ils ne peuvent pas réorganiser.

Les utilisateurs voient des phrases grammaticalement incorrectes. En allemand, le verbe se place souvent à la fin. En arabe, toute la structure est inversée. Le résultat se lit comme un non-sens.

Voici comment le corriger

Utilisez des messages paramétrés avec des espaces réservés nommés, afin que les traducteurs puissent réorganiser la phrase entière.

Remplacez la concaténation par une clé de message unique avec des espaces réservés : 'cart.summary' : 'Vous avez {count} articles dans votre panier '{cartType}''.

Transmettez les variables en tant que paramètres à votre fonction de traduction: t('cart.summary', { count: 5, cartType: 'Premium' }).

Les traducteurs peuvent maintenant réarranger librement : 'Dans votre panier '{cartType}', il y a {count} articles' — allemand grammaticalement correct.

Erreur n°3 : Ignorer les règles de pluriel

L'anglais a deux formes du pluriel : singulier et pluriel. Les développeurs supposent souvent que toutes les langues fonctionnent de la même façon. Ce n'est pas le cas. Le polonais en a 4, l'arabe en a 6, et même des langues comme le français traitent zéro différemment de l'anglais.

['Utilisez toujours ICU MessageFormat ou une bibliothèque équivalente pour les contenus qui dépendent du nombre', 'N’écrivez jamais votre propre logique de pluriel — faites confiance aux règles CLDR', 'Testez les pluriels avec des valeurs comme 0, 1, 2, 5, 21 et 100 pour couvrir toutes les catégories']

Utilisez toujours ICU MessageFormat ou une bibliothèque équivalente pour les contenus comportant des pluriels

N’écrivez jamais votre propre logique de pluriel — faites confiance aux règles CLDR

Testez les pluriels avec des valeurs telles que 0, 1, 2, 5, 21 et 100 pour couvrir toutes les catégories

Un scénario typique

Le développeur écrit : count + (count === 1 ? ' Datei' : ' Dateien') — gère correctement l'allemand.

Le traducteur polonais a besoin de 4 formes : 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. L'opérateur ternaire simple ne peut pas l'exprimer.

Résultat : les utilisateurs polonais voient '5 pliki' (mauvaise forme) au lieu de '5 plików' (forme correcte), et l'application semble cassée.

Pourquoi c'est un problème

Chaque nom comptable dans votre application a besoin d'un traitement du pluriel. Avec 50 chaînes de ce type et 20 langues, cela fait 1 000 règles de pluriel — impossible à gérer manuellement.

Des vérifications simples if/else (count === 1 ? 'Datei' : 'Dateien') ne gèrent que l'allemand et l'anglais. Le CLDR définit jusqu'à 6 catégories de pluriel : zero, one, two, few, many et other. Chaque langue utilise un sous-ensemble différent.

Les utilisateurs voient des textes grammaticalement incorrects, comme '1 Nachrichten' ou des formes plurielles entièrement incorrectes. Dans des contextes formels, cela détruit la crédibilité.

Comment le corriger

Utilisez ICU MessageFormat, qui prend en charge toutes les règles de pluriel CLDR nativement.

Définissez des messages avec la syntaxe ICU : 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.

Les traducteurs fournissent toutes les formes de pluriel nécessaires pour leur langue. Polonais: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.

Votre bibliothèque i18n choisit automatiquement à l'exécution la forme correcte selon les règles CLDR de la locale active.

Erreur n°4 : Largeurs d’éléments UI fixes

Les designers créent des mises en page pixellisées en anglais, et les développeurs les implémentent avec des largeurs fixes. Mais le texte traduit peut être nettement plus long ou plus court. Le texte allemand est environ 30 % plus long que l'anglais, tandis que le chinois peut être environ 50 % plus court.

['N’utilisez jamais de largeurs fixes en pixels pour les éléments contenant du texte traduisible', 'Préparez une expansion de texte de 40 % comme référence — certaines langues s’étendent encore davantage', 'Utilisez CSS Flexbox ou Grid pour des mises en page qui s’adaptent à des longueurs de contenu variables']

N’utilisez jamais de largeurs fixes en pixels pour les éléments contenant du texte à traduire

Planifiez une expansion du texte de 40 % comme base — certaines langues s’étendent encore davantage

Utilisez le CSS Flexbox ou Grid pour des mises en page qui s’adaptent à des longueurs de contenu variables

Un scénario typique

Le concepteur crée une barre de navigation avec 5 boutons, chacun exactement large de 100 px — cela rend bien en anglais.

Traduction en allemand : 'Settings' devient 'Einstellungen' (13 contre 8 caractères), 'Submit' devient 'Absenden' (8 contre 6). La barre de navigation déborde.

Résultat : sur les appareils mobiles, les boutons s'empilent les uns sur les autres ou le texte est tronqué, rendant la navigation inutilisable pour les utilisateurs allemands.

Pourquoi cela pose-t-il un problème ?

Chaque élément à largeur fixe est un point de rupture potentiel. Une application typique compte des centaines de boutons, étiquettes et cartes, qui doivent tous supporter l’agrandissement du texte.

Un conteneur à largeur fixe (width: 120px) et des boutons de taille fixe coupent le contenu ou débordent lorsque le texte s'allonge. overflow: hidden masque le contenu discrètement, tandis que overflow: visible détruit la mise en page.

Les utilisateurs voient des étiquettes tronquées comme 'Param...' au lieu de 'Paramètres', ou des boutons qui chevauchent des éléments voisins. Les actions critiques deviennent illisibles ou non cliquables.

Comment y remédier

Conçois et mets en œuvre des mises en page flexibles qui s'adaptent à la longueur du contenu dans toutes les locales.

Remplacez les largeurs fixes par min-width, max-width et des mises en page flexibles. Utilisez CSS Grid ou Flexbox pour répartir l'espace dynamiquement.

Configurez le conteneur de texte pour les retours à la ligne : utilisez overflow-wrap: break-word et évitez white-space: nowrap pour le contenu traduisible.

Testez votre interface avec une pseudo-localisation qui allonge toutes les chaînes de 40 % afin de simuler le pire cas — avant même d'envoyer les chaînes aux traducteurs.

Erreur n°5 : formatage des dates et des nombres

Les données et les chiffres semblent universels. Mais 01/02/2025 correspond au 2 janvier aux États-Unis et au 1er février en Europe. Les virgules et les points changent de signification: 1,000.50 (USA) vs 1.000,50 (Allemagne). Les faire mal entraîne confusion, erreurs de données et perte de confiance.

['Dès le premier jour, utilisez exclusivement des propriétés CSS logiques (inline-start/end, block-start/end)', 'Testez votre application avec dir='rtl' sur l’élément HTML à chaque revue de sprint', 'Créez une liste de contrôle de test RTL pour la navigation, les icônes, les formulaires et les indicateurs de progression']

Ne formatez jamais les données ou les nombres manuellement avec des gabarits de chaînes — utilisez toujours les API Intl

Stockez toutes les données en ISO 8601 et les devises dans la plus petite unité (cent) en interne

Testez avec des locales utilisant des séparateurs décimaux différents, des ordres de date et des systèmes calendaire différents

Un scénario typique

Le développeur formate une date au format MM/DD/YYYY et un prix en $1,234.50 — correct pour les utilisateurs américains.

Un utilisateur allemand voit la date 03/04/2025 et la lit comme le 3 avril (notation DD/MM/YYYY). Le prix $1,234.50 semble être 1.234,50.

['Résultat : l’utilisateur réserve un vol à la mauvaise date et remet en question le format des prix. Les tickets de support augmentent de 15 % sur le marché allemand.']

Pourquoi cela pose-t-il un problème ?

La mise en forme des dates et des chiffres concerne chaque affichage de données dans votre application : tableaux, graphiques, formulaires, factures, rapports. Une solution globale couvrirait des centaines d’instances.

Les chaînes de formatage codées telles que toLocaleDateString('en-US') ou le formatage manuel avec des littéraux ignorent la locale réelle de l’utilisateur. Même avec la bonne locale mais le calendrier incorrect (Grégorien vs Hijri) peut causer des problèmes.

Les utilisateurs lisent les données de manière incorrecte et saisissent des données dans le mauvais format. Un utilisateur européen qui voit 03/04/2025 pourrait l’interpréter comme le 3 avril au lieu du 4 mars — des rendez-vous manqués ou des réservations incorrectes.

['Comment le corriger']

['Utilisez l’API Intl intégrée ou une bibliothèque de formatage locale pour toutes les dates, heures, nombres et monnaies.']

['Remplacez le formatage manuel par Intl.DateTimeFormat(locale) pour les dates et Intl.NumberFormat(locale, { style: 'currency', currency }) pour les prix.']

['Stockez les données en interne au format ISO 8601 (YYYY-MM-DD) et ne les formatez que pour l’affichage avec la locale de l’utilisateur.']

['Testez avec au moins 5 locales différents: en-US, de-DE, ja-JP, ar-SA et zh-CN, afin de couvrir les variantes de formatage les plus importantes.']

Erreur n°6 : oublier les langues RTL

Les langues RTL telles que l’arabe, l’hébreu et le persan sont utilisées par plus de 500 millions de personnes. Pourtant, la plupart des applications sont conçues uniquement en mise en page de gauche à droite (LTR). Le support RTL ne signifie pas seulement inverser le texte — toute l’interface doit être reflétée.

['Dès le premier jour, utilisez exclusivement des propriétés CSS logiques (inline-start/end, block-start/end)', 'Testez votre application avec dir=\'rtl\' sur l’élément HTML à chaque revue de sprint', 'Créez une liste de contrôle de test RTL pour la navigation, les icônes, les formulaires et les indicateurs de progression']

Utilisez dès le premier jour uniquement des propriétés CSS logiques (inline-start/end, block-start/end)

Testez votre application avec dir='rtl' sur l’élément HTML à chaque revue de sprint

Créez une liste de contrôle RTL pour la navigation, les icônes, les formulaires et les indicateurs de progression

['Un scénario type']

['Le développeur utilise margin-left: 16px et text-align: left dans toute l’application — pratique LTR par défaut.']

['L’application démarre en Arabie Saoudite. Les flèches de retour pointent vers l’avant, les barres latérales apparaissent du mauvais côté et les données numériques sont mal alignées.']

['Résultat : les utilisateurs arabes quittent l’application au bout de 30 secondes. L’équipe a besoin de 4 semaines de refactoring CSS d’urgence pour résoudre le problème.']

['Pourquoi c’est un problème']

['Le support RTL concerne chaque composant de votre application. L’introduire ultérieurement oblige généralement à réécrire 30 à 50% des règles CSS et à vérifier chaque icône et chaque mise en page.']

['Les propriétés CSS telles que margin-left, padding-right, text-align: left et float: left codent durement la direction. Les icônes indiquant une direction (flèches, indicateurs de progression) pointent dans la mauvaise direction. Même les valeurs de border-radius doivent être reflétées.']

['Les utilisateurs arabes voient la navigation dans le coin incorrect, les barres de progression avancent à l’envers et le texte chevauche les éléments de l’interface. L’application donne une impression étrangère et inutilisable.']

['Voici comment le corriger']

['Utilisez des propriétés CSS logiques et testez le layout RTL dès le départ.']

['Remplacez toutes les propriétés CSS physiques par leurs équivalents logiques : margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.']

['Définissez l’attribut dir sur l’élément racine HTML en fonction de la locale active. Utilisez la pseudoclasse CSS :dir(rtl) pour les overrides RTL spécifiques.']

['Vérifiez toutes les icônes pour leur orientation. Remplacez les icônes orientées par des versions miroir ou utilisez CSS transform: scaleX(-1) pour les contextes RTL.']

Erreur n°7 : Images avec du texte

['Mettre du texte dans des images — que ce soit dans des bannières héros, des boutons, des infographies ou des captures d’écran — est un cauchemar de localisation. Chaque image comportant du texte doit être créée pour chaque langue, ce qui augmente les coûts de conception et retarde les versions.']

['N'insérez jamais du texte traduisible directement dans des images raster (PNG, JPG)', 'Utilisez des superpositions de texte CSS sur les images de fond pour les bannières héros et les CTA', 'Automatisez la génération de captures d'écran pour les fiches App Store et les pages marketing']

N’insérez jamais de texte traduisible directement dans des images raster (PNG, JPG)

Utilisez des superpositions de texte CSS sur des images d’arrière-plan pour les bannières et les CTA

Automatisez la génération de captures d’écran pour les fiches App Store et les pages marketing

Un scénario typique

Un concepteur crée une bannière promo avec le texte 'Start Your Free Trial' directement intégré à l'image.

L'équipe de localisation traduit toutes les chaînes de l'UI, mais la bannière affiche toujours du texte anglais sur la page allemande.

Résultat : la page d'accueil allemande affiche une bannière en anglais qui dérange. Créer des bannières localisées pour 15 langues prend 3 jours de travail de design et retarde le lancement.

['Pourquoi c’est un problème']

Une page marketing typique comporte 5 à 10 images avec du texte. À 15 langues, cela représente 75 à 150 variantes d'images qui doivent être créées, entretenues et mises à jour à chaque changement de design.

['Le texte intégré dans les images (PNG, JPG, SVG avec texte intégré) ne peut pas être extrait par les outils de traduction. Chaque version localisée nécessite qu’un designer modifie manuellement le fichier source, l’exporte et le télécharge.']

Les utilisateurs voient des images avec du texte dans une langue étrangère, ou pire, un mélange d'une interface utilisateur traduite et d'images non traduites. Cela paraît incohérent et nuit à la confiance envers la marque.

Comment le résoudre.

Sépare le texte des images en utilisant des superpositions CSS, des SVG avec des éléments de texte traduisibles ou une génération dynamique d'images.

Utilisez le CSS pour placer le texte traduisible au-dessus des images d'arrière-plan : positionnez le calque de texte en positionnement absolu au-dessus du conteneur d'image.

Pour les infographies ou les diagrammes, utilisez des SVG avec des éléments <text> qui réfèrent à des clés de traduction, au lieu d'intégrer des chaînes brutes.

Pour les captures d'écran d'applications dans les supports marketing, automatisez la génération de captures d'écran avec des outils tels que Fastlane (Mobile) ou Playwright (Web), qui prennent des captures dans chaque locale.

Erreur n°8 : Les traductions manquantes ne sont pas gérées.

Les traductions pendant le développement sont toujours incomplètes. Les nouvelles fonctionnalités ajoutent des chaînes plus rapidement que les traducteurs ne peuvent les traduire. Sans une gestion correcte des fallback, les traductions manquantes provoquent des plantages, des éléments d'UI vides ou des clés de traduction brutes visibles par les utilisateurs.

['Configurez toujours au moins une langue de secours dans votre configuration i18n', 'Enregistrez les clés de traduction manquantes dans votre système de surveillance pour le suivi', 'Définissez un seuil minimal de couverture des traductions avant la mise en production d’une locale']

Configurez au moins une langue de secours dans votre configuration i18n

Enregistrez les clés de traduction manquantes dans votre système de surveillance pour le suivi

Définissez un taux de couverture de traduction minimum avant qu'une locale puisse être publiée

Un scénario typique

Le développeur ajoute une nouvelle section 'Premium Features' avec 15 nouvelles clés de traduction. La version anglaise est livrée immédiatement.

Les traductions françaises ne sont pas encore terminées. La page française affiche des clés brutes : 'premium.feature1.title', 'premium.feature1.description'.

Résultat : les utilisateurs français voient une page cassée remplie de noms de clés côté développeur. L'équipe de support reçoit des dizaines de rapports de bogues.

Pourquoi c'est un problème

Plus votre application grandit, plus l'écart entre les chaînes en anglais et les traductions dans les autres langues s'accroît. Une application avec 100 langues et 2000 chaînes pourrait à tout moment avoir plus de 10 000 traductions manquantes.

Sans une logique de fallback, une clé manquante renvoie undefined, null ou la chaîne brute de la clé (par exemple 'checkout.confirmButton'). Les moteurs de templates peuvent générer des erreurs, faire planter la page ou ne rien rendre.

Les utilisateurs voient une interface utilisateur défectueuse : boutons vides, libellés manquants ou des chaînes cryptiques comme 'nav.settings.title' au lieu d'un vrai texte. C'est déroutant et peu professionnel.

Comment le résoudre

Configurez une chaîne de secours robuste et surveillez la couverture des traductions pour toutes les locales.

Configurez une chaîne de fallback dans votre configuration i18n : les clés manquantes en français (fr) reviennent automatiquement en anglais (en).

Ajoute un gestionnaire de clé manquante qui enregistre les clés non traduites dans votre système de surveillance (par exemple Sentry, Datadog), sans casser l'expérience utilisateur.

Créez un tableau de bord de couverture de traduction qui suit le taux d’achèvement par locale et bloque les versions lorsque la couverture chute en dessous d’un seuil (par ex. 95%).

Erreur n°9 : Problèmes d'encodage des caractères

Les problèmes de codage des caractères sont le tueur silencieux de la localisation. Tout semble correct en anglais et dans les langues européennes, mais dès que vous ajoutez le chinois, le japonais, le coréen, l'arabe ou des émojis, des caractères tronqués (Mojibake) apparaissent. Ces bugs sont notoirement difficiles à repérer.

['Utilisez l’UTF-8 partout — fichiers sources, base de données, réponses API et balises meta HTML', 'Utilisez utf8mb4 dans MySQL (pas utf8), pour prendre en charge l’ensemble de l’Unicode y compris les emoji', 'Testez avec du contenu réel en CJK, arabe et emoji pour repérer les problèmes de codage tôt']

Utilisez l’encodage UTF-8 partout — fichiers sources, base de données, réponses API et balises meta HTML

Utilisez utf8mb4 dans MySQL (au lieu de utf8) pour prendre en charge l’ensemble Unicode y compris les émojis

Testez avec du contenu réel en CJK, en arabe et en émojis pour dépister les problèmes d’encodage tôt

Un scénario typique

Les développeurs configurent une base de données MySQL avec collation latin1 (l’ancien standard). Le code source de l’application utilise UTF-8.

Les utilisateurs japonais s’inscrivent avec leur vrai nom. La base de données stocke '田中太郎' sous forme d’octets endommagés.

Résultat : le profil utilisateur affiche du texte tronqué. Pire encore : la recherche et le tri échouent pour tous les noms CJK, touchant des milliers d’utilisateurs.

Pourquoi c’est un problème

Les problèmes de codage se propagent dans l’ensemble de la pile. Une collation de base de données mal configurée peut endommager des millions d’enregistrements — la réparation nécessite des migrations de données coûteuses.

Une incohérence de codage à travers la pile — UTF-8 dans les fichiers source, Latin-1 dans la base de données et Windows-1252 dans les réponses API — détruit les caractères multibytes. Une seule couche mal configurée transforme '日本語' en '????' ou 'æ—¥æœ¬èª'.

Les utilisateurs voient des textes tronqués, des points d'interrogation ou des cases vides là où leur langue devrait apparaître. Dans le pire des cas, les entrées de formulaire sont endommagées de façon permanente dans la base de données.

Comment le corriger

Assurez l’encodage UTF-8 de manière cohérente à chaque couche de votre pile d’application.

Réglez tous les fichiers sources en UTF-8 (configuez votre éditeur et .editorconfig). Ajoutez <meta charset='UTF-8'> dans votre HTML et 'Content-Type: application/json; charset=utf-8' dans les réponses API.

Configurez votre base de données sur utf8mb4 (pas seulement utf8, qui est un sous-ensemble de 3 octets dans MySQL). Définissez la collation de connexion sur utf8mb4_unicode_ci.

Choisissez des polices couvrant vos systèmes d'écriture cibles : latin, cyrillique, CJK, arabe, devanagari. Utilisez des piles de polices système ou Google Fonts avec des sous-ensembles linguistiques pour un chargement optimal.

Testez votre implémentation i18n

Test d’allongement de la longueur

Élargissez toutes les chaînes traduites de 30 à 40 % pour simuler l’expansion du texte qui se produit dans des langues plus riches en texte comme l’allemand, le finnois ou le grec. Cela couvre les conteneurs à largeur fixe, les étiquettes tronquées et les boutons qui débordent, même avant de commencer à traduire. De nombreux outils de pseudo-localisation offrent cela en tant que fonctionnalité intégrée.

"Envoyer" → "Ṡéééñðéñ_éxpáñðéð" (40% plus long)

Pseudo-localisation

La pseudo-localisation remplace chaque caractère par son équivalent accentué (par exemple, 'a' → 'á') et encadre les chaînes avec des marqueurs tels que [!! et !!]. Cela permet de voir immédiatement quelles chaînes sont codées en dur et lesquelles proviennent du système de traduction. Exécutez la pseudo-localisation dans le cadre de votre pipeline CI afin d'attraper automatiquement les régressions.

Tout texte affiché à l'écran qui n'est pas entouré par les marqueurs [!! !!] est codé en dur et doit être externalisé. Ce test capte 95 % des chaînes ignorées en moins d'une minute.

"Envoyer le message" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"

Test de mise en page RTL

Même sans des traductions en arabe ou en hébreu, vous pouvez tester la mise en page RTL en ajoutant dir='rtl' à l'élément racine de votre HTML. Cela permet de repérer immédiatement les bugs CSS directionnels: icônes mal alignées, marges du bon ou du mauvais côté, navigation cassée et éléments Flex mal triés. Faites-en un contrôle standard à chaque revue de sprint — il ne faut que 10 secondes pour basculer et cela permet de repérer des problèmes qui, autrement, prendraient des semaines à corriger en production.

La checklist i18n

['Toutes les chaînes visibles par l’utilisateur sont externalisées dans des fichiers de ressources', 'Aucune concaténation de chaînes pour former des phrases n’est utilisée', 'Les règles de pluriel sont implémentées avec ICU MessageFormat ou équivalent', 'Le formatage des dates, heures et nombres utilise des API adaptées à la locale', 'Le rendu RTL a été testé avec du contenu arabe ou hébreu', 'Une interface utilisateur flexible sans largeurs fixes pour les éléments contenant du texte', 'La langue de repli (fallback) est configurée et testée en cas de clés manquantes', 'Le codage UTF-8 est cohérent sur tous les fichiers et bases de données', 'Les métadonnées de l’App Store et du Play Store localisées pour chaque marché', 'Captures d’écran et actifs marketing pour chaque langue mis à jour']