Réponse en bref
Une interface multilingue casse dès que les composants supposent un texte de taille anglaise. Une stratégie de tokens peut intégrer au système l’expansion, la hauteur des écritures, le flux RTL et la régression visuelle, au lieu d’exceptions tardives.
Le problème des tokens n’est pas la traduction, c’est la géométrie invisible
Une interface multilingue échoue généralement avant même qu’un traducteur n’y touche. L’échec est déjà inscrit dans une largeur de bouton figée, dans un titre de carte sur deux lignes sans politique de débordement, dans un élément de navigation dont le padding a été calibré autour de six lettres anglaises, ou dans une icône positionnée avec un décalage à gauche codé en dur. La traduction ne fait que révéler ces hypothèses. Un système de tokens utile décrit donc non seulement des couleurs et des valeurs d’espacement, mais aussi la géométrie qu’un composant est autorisé à négocier lorsque le contenu change.
Les recommandations d’internationalisation du W3C rendent le risque sous-jacent très concret : le texte traduit ne conserve pas la longueur de la source, et les chaînes très courtes peuvent s’allonger bien davantage que les longs paragraphes. L’allemand et le finnois peuvent aussi produire de longs mots composés qui offrent moins de points de césure naturels, tandis que des écritures comme le thaï, l’arabe, la devanagari, le chinois et le japonais peuvent exiger un espace vertical différent. Le système doit tolérer simultanément des variations de largeur, de hauteur et de retour à la ligne, au lieu de traiter « le texte plus long » comme le seul problème de localisation.
La question de conception passe alors de « Quelle est la largeur du bouton ? » à « Quelles sont la taille minimale de ce bouton, son padding en ligne, son comportement de croissance maximale et ses règles de retour à la ligne ? » Les tokens sont les plus puissants lorsqu’ils capturent ces décisions durables. Une valeur fixe en pixels peut toujours exister, mais elle doit s’inscrire dans un contrat sémantique qui explique ce qui peut s’étendre, ce qui doit rester stable et ce qui se passe lorsque le contenu dépasse la forme préférée.
Tokeniser des relations, pas des captures d’écran
Une capture d’écran n’est qu’un agencement de contenu qui a réussi. Un design token doit décrire la relation qui a rendu cet agencement possible. Pour les produits multilingues, cela implique de distinguer les exigences fixes des exigences élastiques. Les tailles minimales des cibles tactiles peuvent être fixes. Le padding en ligne peut rester stable au sein d’une même famille de composants. Les colonnes de texte peuvent avoir des mesures maximales préférées. Mais l’espace alloué à un libellé ne devrait que rarement être encodé comme une largeur rigide simplement parce que l’ensemble paraissait équilibré dans la locale source.
Une couche de tokens opérationnelle peut inclure des valeurs sémantiques telles que control-inline-padding, control-block-padding, label-gap, compact-line-height, reading-line-height, content-max-inline-size et minimum-control-block-size. Le nommage exact importe moins que la logique. Les composants consomment ensuite ces sémantiques au lieu d’inventer des nombres locaux. Lorsque la typographie change selon la locale, un alias de token peut ajuster l’interlignage ou la police de repli sans obliger les designers à réajuster individuellement chaque carte et chaque boîte de dialogue.
Le même principe s’applique à la densité. « Compact » ne doit pas signifier « ne grandit jamais ». Un composant compact peut conserver un padding réduit tout en autorisant une deuxième ligne ou une hauteur de bloc supplémentaire. C’est particulièrement important dans les interfaces d’entreprise, où cohabitent des libellés traduits, des noms saisis par les utilisateurs et des dates localisées. L’objectif est une plage contrôlée d’états valides, et non la promesse que chaque locale reproduira la capture d’écran anglaise au pixel près.
Inscrire l’expansion du texte dans les contrats de composants
Chaque composant porteur de texte a besoin d’une réponse explicite à trois questions : le texte peut-il passer à la ligne, le conteneur peut-il grandir, et que se passe-t-il lorsque ces deux marges sont épuisées ? Les boutons fonctionnent souvent mieux avec une croissance horizontale d’abord et un retour à la ligne limité, uniquement lorsque le contexte produit le permet. Les onglets peuvent nécessiter un défilement ou un autre motif de débordement. Les cartes peuvent généralement grandir verticalement. Les colonnes de tableau peuvent exiger des règles de priorité plutôt qu’une compression uniforme. Ces décisions doivent être documentées une fois dans la spécification du composant, puis éprouvées dans chaque locale.
Le critère de redistribution (reflow) du W3C constitue une discipline utile même lorsque la tâche immédiate relève de la localisation plutôt que de l’accessibilité. Il demande si l’information et les fonctionnalités restent disponibles lorsque le contenu doit se redistribuer dans un espace contraint. Un système multilingue gagne à adopter le même état d’esprit : quand la largeur disparaît, le contenu doit se réorganiser au lieu de disparaître silencieusement. Les conteneurs à hauteur fixe sont particulièrement risqués, car une traduction peut créer une deuxième ou une troisième ligne qui se retrouve rognée sans produire de signal de débordement horizontal évident.
La pseudo-localisation doit donc faire partie de la revue de design, et pas seulement de l’assurance qualité côté ingénierie. Remplacez les chaînes source par des versions exagérées contenant du texte approximativement allongé, des caractères accentués et des mots délibérément très longs. L’objectif n’est pas de simuler parfaitement une vraie langue ; il s’agit d’exposer les hypothèses de mise en page fragiles. Si un composant casse sous une contrainte synthétique, la localisation en production finira par trouver la même faiblesse à un endroit moins prévisible et plus coûteux.
La typographie fluide doit tenir compte de la hauteur des écritures autant que de la largeur
La typographie responsive est souvent pensée autour de la largeur de la fenêtre, alors que la typographie multilingue ajoute un second axe : les métriques de l’écriture et de la police de repli retenue. Deux polices réglées sur la même taille nominale peuvent présenter des hauteurs d’x, des ascendantes, des descendantes et des densités apparentes différentes. Certains systèmes d’écriture ont besoin de plus d’interlignage pour rester lisibles et pour éviter les collisions entre signes. Un token d’interlignage unique et resserré, choisi pour des capitales latines, peut devenir visiblement défaillant lorsqu’une autre écriture entre dans le même composant.
Le modèle le plus sûr sépare le rôle typographique des métriques exactes de la police utilisée pour le rendre. Un token sémantique « label-small » peut pointer vers une famille de polices, une taille, une graisse et un interlignage adaptés à la locale. Là où une écriture réclame davantage d’espace de bloc, la couche de locale peut ajuster cette correspondance sans modifier la structure du composant. C’est plus maintenable que d’enfouir du CSS d’exception dans chaque surface produit, et cela rend l’exception visible pour les équipes de design comme d’ingénierie.
Le dimensionnement fluide doit aussi comporter des planchers et des plafonds. Si la taille du texte varie continûment avec la largeur de la fenêtre alors qu’un libellé traduit occupe déjà plus de lignes, réduire le corps pour ramener de force la composition source à sa forme initiale peut nuire à la lisibilité. Traitez le retour à la ligne et la redistribution comme des résultats légitimes. Le système typographique doit préserver d’abord la qualité de lecture ; c’est au composant d’absorber la conséquence géométrique. C’est l’inverse de comprimer la langue jusqu’à ce qu’elle rentre dans une boîte prédéterminée.
La directionnalité relève des tokens et des API, pas d’un CSS de dernière minute
La prise en charge de l’écriture de droite à gauche ne s’obtient pas en retournant tout l’écran comme une image. Les interfaces en arabe et en hébreu combinent du texte RTL avec des chiffres, des noms de produits en alphabet latin, des adresses e-mail et d’autres fragments LTR. L’algorithme bidirectionnel d’Unicode (Unicode Bidirectional Algorithm) existe précisément parce que ces séquences mixtes ont besoin de règles d’ordonnancement visuel. Le code produit doit encore fournir une direction de base correcte et isoler le contenu incorporé, afin que la ponctuation, les chiffres et les chaînes adjacentes ne se réordonnent pas de manière surprenante.
Au niveau du design system, remplacez les concepts physiques comme margin-left et border-right par des concepts logiques comme inline-start, inline-end, block-start et block-end partout où le sens suit le sens de lecture. Les API de composants doivent exposer des emplacements « leading » et « trailing » plutôt que « icône à gauche » et « icône à droite ». Cela donne à la mise en page la permission de se mettre en miroir de façon appropriée tout en préservant intacte la structure sémantique du composant.
Les icônes exigent une décision distincte. Un chevron indiquant « suivant » dans une séquence directionnelle peut devoir être inversé ; un appareil photo, un microphone, un symbole d’avertissement ou une marque, généralement non. Même la ponctuation a un comportement sensible à la direction : le W3C rappelle que les caractères en miroir, comme les parenthèses, sont traités selon le contexte directionnel. La règle fiable consiste à mettre en miroir la sémantique, pas les pixels. Chaque ressource directionnelle doit être classée, testée et documentée plutôt que confiée à une transformation globale.
La troncature est une politique de contenu, pas un correctif d’espacement
Les points de suspension peuvent donner un air soigné à une mise en page cassée tout en masquant le fait que de l’information a été supprimée. Ce compromis est acceptable à certains endroits, comme un nom de fichier secondaire dans une liste contrainte, mais dangereux ailleurs. Un appel à l’action principal, un motif d’erreur, un nom de compte qui distingue un enregistrement d’un autre, ou un statut juridique peuvent être exactement le contenu dont l’utilisateur a besoin. La décision de tronquer doit donc découler de la priorité informationnelle, et non d’une gêne visuelle.
Les tokens peuvent aider en séparant le comportement de troncature de la typographie. Un composant peut exposer des modes de contenu sur une ligne, sur deux lignes et sans restriction, chacun avec une gestion du débordement définie. Les équipes produit choisissent alors délibérément. La chaîne complète doit rester accessible lorsque c’est réalisable, et l’interaction qui la révèle doit fonctionner au clavier, au toucher et avec les technologies d’assistance. Une infobulle qui n’apparaît qu’au survol de la souris n’est pas un mécanisme de récupération complet.
La localisation change aussi ce qu’il est prudent d’abréger. Le W3C avertit que les abréviations ne se transfèrent pas proprement d’une langue à l’autre ; certaines langues peuvent ne pas disposer d’un équivalent court naturel. Si une interface dépend de « Acct. » ou « Qty. » pour tenir dans l’espace, la conception transfère déjà un problème de mise en page aux traducteurs. Préférez des libellés capables d’occuper un espace variable, ou repensez l’architecture de l’information pour que le composant ne dépende pas d’une compression propre à l’anglais.
Les tests de captures d’écran doivent représenter le risque linguistique, pas chaque locale
Un produit mondial n’a pas besoin de milliers de captures pleine page pour tirer profit de la régression visuelle. Il lui faut une matrice réduite et intentionnelle qui met sous tension les principaux modes de défaillance. Incluez une locale LTR à chaînes longues, une locale RTL, une locale utilisant une écriture plus haute ou visuellement dense, et une version pseudo-localisée qui exagère l’expansion. Ajoutez les composants les plus à risque du produit : navigation, formulaires, tableaux, fenêtres modales, notifications, filtres et toute surface à contenu de hauteur fixe.
Les captures doivent s’exécuter aux mêmes points de rupture responsive que ceux utilisés pour la locale source, car localisation et comportement responsive interagissent. Un libellé qui tient sur ordinateur peut imposer un retour à la ligne en largeur tablette ; ce retour à la ligne peut augmenter la hauteur de la carte ; cette nouvelle hauteur peut pousser une action sous la ligne de flottaison ou entrer en collision avec un badge positionné en absolu. Les tests de régression sont les plus utiles quand ils attrapent cet enchaînement, plutôt que de se contenter de prouver que les glyphes se sont affichés.
La comparaison automatisée a tout de même besoin d’une relecture humaine. Une différence de pixels peut vous dire qu’une mise en page a changé, mais pas si la nouvelle césure est sémantiquement satisfaisante, si une icône a été correctement mise en miroir ou si un texte à direction mixte se lit naturellement. Associez les captures automatisées à une relecture périodique par des locuteurs natifs ou des spécialistes de la localisation pour les parcours critiques. La suite de tests protège les invariants structurels ; la relecture linguistique protège le sens. Aucune des deux ne remplace l’autre.
Une séquence d’adoption réaliste pour un design system existant
Commencez par des faits plutôt que par une réécriture des tokens. Inventoriez les bugs actuellement en production et identifiez les types de défaillance récurrents : libellés rognés, contrôles à hauteur fixe, contenu RTL mal ordonné, navigation trop tronquée, erreurs d’icônes et collisions typographiques. Reliez chaque bug à la décision de conception qui l’a rendu possible. Vous obtenez ainsi une liste courte de contraintes systémiques qui méritent d’être tokenisées, et vous évitez de créer une vaste taxonomie théorique que les composants ne consommeront jamais.
Ensuite, convertissez l’espacement physique en espacement logique dans les primitives partagées, définissez des contrats de croissance et de retour à la ligne pour les composants textuels les plus réutilisés, et introduisez des alias typographiques adaptés à la locale. Ajoutez des jeux de test de pseudo-localisation directement dans le playground de composants, pour que les designers puissent les déclencher sans assistance de l’ingénierie. Ajoutez ensuite des cas représentatifs de régression visuelle. Les premières cibles les plus rentables sont les primitives utilisées partout : boutons, champs de saisie, lignes de liste, cartes, boîtes de dialogue et éléments de navigation.
Enfin, faites de la résilience multilingue un critère de mise en production. Un composant n’est pas « terminé » parce qu’il correspond à une seule maquette Figma ; il l’est lorsque ses états de contenu valides, ses états de direction et son comportement de débordement sont spécifiés et testés. Cela ne supprime pas le travail de localisation. Cela en change l’économie. Traducteurs et spécialistes de la locale peuvent alors se concentrer sur la langue et la justesse culturelle, au lieu de découvrir sans cesse que la géométrie du produit n’a jamais été conçue pour contenir de la langue réelle.
Checklist pratique
- Remplacez les tokens d’espacement gauche/droite par des tokens logiques début/fin partout où la direction peut changer.
- Mettez sous contrainte boutons, onglets, cartes et tableaux avec des chaînes d’exemple allongées et en écritures hautes.
- Définissez les règles de retour à la ligne, de croissance et de troncature pour chaque composant porteur de texte.
- Auditez la direction sémantique des icônes avant de les mettre en miroir dans les mises en page RTL.
- Capturez des captures d’écran représentatives pour les locales LTR, RTL et à chaînes longues.
Questions et réponses
Un design system doit-il créer des tokens distincts pour chaque langue ?
En général, non. Le schéma le plus évolutif consiste à créer des tokens sémantiques pour les comportements que les langues peuvent mettre sous tension : espacement en ligne, espacement de bloc, interlignage, taille minimale des contrôles, largeur de contenu, retour à la ligne et direction. Des surcharges propres à une locale sont utiles lorsqu’une écriture ou une exigence produit le réclame réellement, mais dupliquer tout un jeu de tokens par langue crée de la dérive. Commencez par des règles sémantiques partagées, puis n’ajoutez des alias de locale étroitement délimités que lorsque les tests démontrent un besoin récurrent.
Quelle largeur supplémentaire les designers doivent-ils réserver au texte d’interface traduit ?
Il n’existe pas de pourcentage unique et sûr. Les recommandations du W3C notent que des chaînes anglaises courtes peuvent s’allonger considérablement à la traduction, tandis que les passages plus longs s’allongent généralement dans une proportion moindre. La réponse pratique n’est pas de réserver une marge fixe, mais de laisser les composants grandir, passer à la ligne ou se redistribuer selon des règles explicites. La pseudo-localisation avec des chaînes délibérément rallongées est plus fiable que de deviner un multiplicateur universel, en particulier pour les boutons, les onglets, les filtres et la navigation compacte.
Faut-il mettre en miroir toutes les icônes dans une interface de droite à gauche ?
Non. Les icônes qui expriment une direction physique ou une séquence peuvent nécessiter une mise en miroir, tandis que celles qui représentent des objets stables, des marques, des commandes multimédias ou des symboles culturellement établis peuvent ne pas en avoir besoin. La décision doit être sémantique, pas mécanique. La direction du texte affecte aussi la ponctuation et les contenus multi-écritures via l’algorithme bidirectionnel Unicode (Unicode Bidirectional Algorithm). Un système robuste traite donc la direction des icônes, la direction du texte et l’ordre de mise en page comme des questions liées mais distinctes, examinées en contexte.
La troncature est-elle une solution acceptable au débordement lié à la localisation ?
Elle peut l’être, mais seulement lorsque le contenu masqué est non essentiel ou qu’il peut être récupéré par une autre interaction : un dépliement, une infobulle ou une vue de détail. Tronquer une action principale, un prix, un message d’erreur ou une mention légale peut détruire le sens. Privilégiez d’abord le retour à la ligne, la largeur flexible ou la redistribution. Si la troncature est conservée, définissez-la comme une politique de contenu au niveau du composant et vérifiez que les lecteurs d’écran et les utilisateurs au clavier peuvent encore accéder à l’information complète.