Comment concevoir une interface qui supporte l’expansion du texte

L’expansion du texte devient un problème de mise en page lorsqu’une interface dépend de l’espace exact occupé par sa formulation d’origine. Un bouton anglais court tient. Une traduction plus longue est tronquée. Une rangée d’onglets bien ordonnés se comprime, ou une carte grandit tandis que son action reste fixée à l’ancienne position.

Il n’est pas nécessaire d’attendre toutes les traductions pour examiner cette rigidité. Vous pouvez mettre une version à l’épreuve avec un texte volontairement plus long, puis refaire la revue avec de vraies traductions. La première étape révèle les faiblesses structurelles ; la seconde vérifie le fonctionnement avec une langue et un sens réels.

Pourquoi un seul pourcentage d’expansion ne suffit pas

Aucun pourcentage unique ne prépare une interface à toutes les langues. Les libellés courts, phrases longues, mots composés et systèmes d’écriture différents exercent des pressions différentes. Compter les caractères ne dit pas non plus exactement quel espace le texte occupera une fois affiché.

L’explication du W3C sur la taille du texte traduit décrit pourquoi des chaînes source compactes peuvent s’allonger fortement et pourquoi largeur des caractères, structure des mots et interlignage comptent. Ses exemples sont des avertissements utiles, pas un calculateur pour votre interface. Examinez le vrai couple contenu-police avant de considérer un composant prêt.

Imaginez un tableau de bord d’événements fictif avec un bouton « Voir les détails ». Un libellé plus long peut demander un bouton plus large ou une seconde ligne. Pendant ce temps, le titre de l’événement peut passer de deux à trois lignes. Ces changements diffèrent, ainsi que leurs conséquences. Réserver partout le même pourcentage d’espace supplémentaire ne décide pas de leur comportement.

Identifiez d’abord ce que les mots doivent communiquer. Si un libellé distingue consulter une réservation de la modifier, cette distinction doit survivre. Si un avertissement explique qu’une action est irréversible, on ne peut pas en retirer le sens pour préserver la hauteur initiale de la carte. La mise en page est au service du message.

Faites un petit inventaire des composants vulnérables

Commencez par les zones où l’espace est fortement contraint. Navigation, onglets, boutons, pastilles, libellés de formulaire, en-têtes de tableau et petites cartes sont généralement plus instructifs qu’une large colonne de paragraphes. Cherchez les cas où le texte côtoie une icône, un prix, un statut ou une autre action.

Pour chaque composant, consignez quatre comportements :

1. Retour à la ligne : le libellé peut-il prendre une ligne supplémentaire ?
2. Agrandissement : le conteneur devient-il plus haut ou plus large avec lui ?
3. Voisins : l’icône et l’action adjacente se déplacent-elles sans problème ?
4. Limites : si le nombre de lignes est plafonné, où peut-on lire le texte complet ?

Une question sans réponse correspond à une décision de design encore à prendre ; le libellé anglais court l’avait peut-être simplement cachée.

Notez ensuite le coût de l’échec. Une étiquette décorative qui grandit diffère d’un montant de paiement recouvert par un libellé. Donnez la priorité aux composants qui portent décisions, exigences ou actions. Cela évite de consacrer la première heure de revue à des variations inoffensives alors qu’une commande essentielle reste illisible.

Ce que Shopify a appris avant l’arrivée des traductions

Dans le récit de l’internationalisation de son produit, Shopify décrit un problème facile à manquer dans un aperçu anglais : les chaînes extraites ressemblaient aux chaînes codées en dur. L’équipe a introduit une pseudotraduction qui remplaçait des caractères par des variantes reconnaissables et doublait les voyelles. Le texte modifié permettait de voir les chaînes passant par la traduction et d’examiner l’interface avec des mots plus longs.

La pseudotraduction détecte tôt une classe utile de défauts : textes qui n’entrent jamais dans le système de traduction, commandes dépendant de mots courts et conteneurs incapables de grandir. Elle ne dit pas si une consigne française est naturelle ni si une disposition arabe possède le bon ordre de lecture.

La capture mérite d’être examinée pour ce qui y reste reconnaissable. Un testeur comprend encore l’écran tout en voyant les caractères inhabituels. Il peut ainsi accomplir une tâche normale et remarquer les ruptures en chemin. Des chaînes aléatoires dans chaque boîte exerceraient une pression, mais empêcheraient aussi de juger si l’action et son explication gardent un sens ensemble.

Utilisez l’approche de Shopify pour séparer quatre vérifications :

• Couverture : la pseudotraduction visiblement marquée révèle les chaînes jamais transformées.
• Capacité : les formulations allongées testent l’agrandissement des commandes et des conteneurs.
• Rendu : le système d’écriture voulu et la police de remplacement révèlent les glyphes manquants ou les boîtes de ligne tronquées.
• Langue : les traductions validées permettent à une personne maîtrisant la langue de juger sens et formulation.

Un jeu pratique de tests de résistance pour une interface

Prenez une page avec un titre, des onglets, une pastille de statut, deux actions et une erreur. Préservez les valeurs et les destinations en ne changeant que le texte examiné.

Rattachez chaque défaut à la chaîne et à l’état qui l’ont produit. « L’action secondaire française recouvre l’action principale à 390px après validation » donne un point de départ au développeur. « Le français demande plus de place » ne distingue pas un bouton à largeur fixe d’une rangée d’actions rigide ou d’une erreur mal placée.

Après une correction, retestez aussi le texte court. Un bouton pleine largeur peut résoudre le plus long libellé mais sembler détaché sur grand écran. Une carte à grande hauteur fixe peut accueillir une traduction tout en compliquant le parcours des fiches ordinaires. Préférez un agrandissement lié au contenu et un empilement défini ; réservez les capacités fixes aux contraintes réelles, comme une surface hôte intégrée.

Avant la revue linguistique, donnez au traducteur la destination de l’action et la phrase environnante. « Open » peut désigner un état ou un impératif. Un bouton plus large ne résoudra pas cette ambiguïté. Les vérifications visuelles et linguistiques doivent s’éclairer sans demander à chaque personne de certifier un travail qu’elle ne peut pas évaluer.

Gardez le test de résistance contrôlé

Utilisez un titre d’événement, un nom de lieu et un libellé d’action plus longs. Gardez les dates et les nombres de participants fixes lors de la première comparaison pour isoler la longueur du texte. Une fois la disposition correcte, ajoutez les formats de date localisés dans un passage distinct.

Utilisez un anglais allongé pour révéler la pression sur la mise en page, puis de vraies traductions pour examiner naturel de la formulation, sens et rendu propre au système d’écriture.

Choisissez une réponse pour chaque composant

La même chaîne plus longue ne doit pas déclencher la même réparation partout. Un bouton peut grandir ; la navigation peut changer de disposition ; une carte peut prendre une ligne supplémentaire. Partez de la relation à préserver.

Boutons : agrandir, passer à la ligne ou empiler

Les boutons ont besoin d’une règle pour les libellés plus longs. Une largeur fixe peut servir un groupe volontairement aligné, mais devient fragile lorsque cette largeur compte davantage que le libellé. Examinez l’action dans son environnement avant de décider si le bouton doit grandir, passer à la ligne ou se déplacer.

Pour deux actions sous un formulaire, les empiler sur écran étroit peut être plus clair que les comprimer sur une ligne. Si l’une est principale, préservez sa mise en avant après empilement. Le visiteur ne doit pas déduire l’importance d’une disposition de bureau qui n’existe plus.

Un libellé sur plusieurs lignes n’est pas automatiquement incorrect. Il peut fonctionner avec une hauteur suffisante, des marges internes équilibrées et un lien clair avec le contenu concerné. En revanche, une collection de petits boutons sur deux lignes peut devenir difficile à parcourir. Si plusieurs actions nécessitent de longues explications, reconsidérez leur présence dans un même groupe compact.

Ne remplacez pas les libellés significatifs par des icônes inexpliquées pour gagner de la largeur. Une icône peut convenir à une action familière dans un contexte adapté, mais ce changement crée un nouveau problème de reconnaissance. Évaluez ce compromis délibérément, plutôt que d’en faire une manière neutre de faire disparaître la traduction.

Pour une vérification concrète, j’ai mesuré trois libellés anglais en Albert Sans à 32px avec 20px de marge interne horizontale de chaque côté. « View details » demande 212px au total ; « Review booking details », 368px ; « Review your booking details », 440px. Un bouton fixe de 220px ne laisse que 180px au libellé : le premier tient, les autres exigent une réponse de mise en page. Ces libellés anglais de test isolent la pression sur la largeur ; ce ne sont pas des traductions. La partie sombre de chaque barre représente le texte mesuré, la partie claire les marges internes. Sur une page étroite, comparez cette largeur à l’espace du groupe d’actions avant de choisir agrandissement, retour à la ligne ou empilement.

Navigation : changez avant la collision

La navigation révèle souvent tôt l’expansion, car plusieurs libellés se disputent une seule rangée. Un en-tête qui accueille tout juste la langue source dispose de peu de marge pour des formulations plus longues. Il faudra peut-être changer de présentation plus tôt dans une autre langue ou utiliser une disposition adaptée à l’espace disponible.

Vérifiez l’en-tête complet, y compris marque, sélecteur de langue, action du compte et éventuel lien promotionnel. Examiner seulement les libellés de navigation peut masquer la vraie collision. Un libellé de compte légèrement plus long peut suffire à comprimer inconfortablement tout le reste.

Ne raccourcissez pas les libellés indépendamment pour conserver des largeurs égales. Un traducteur peut choisir d’autres mots pour préserver le sens, sans produire de symétrie visuelle. Un élément de navigation peut raisonnablement prendre plus de place si le groupe reste compréhensible et utilisable.

Pour les onglets, demandez-vous si le retour à la ligne crée de l’ambiguïté. Deux rangées peuvent rendre moins clair le contenu associé à l’élément sélectionné. Une autre commande ou un défilement délibéré peuvent mieux convenir selon la tâche. Examinez ensemble l’état sélectionné et le contenu de destination, pas seulement la visibilité de tous les mots.

Cartes : préservez identité et action

Les cartes répétées poussent à conserver exactement la même hauteur partout. Cela peut faciliter le parcours, mais la méthode compte. Couper un texte significatif pour préserver la grille peut faciliter l’alignement et compliquer le choix.

Dans le tableau de bord d’événements, supposons qu’un nom occupe trois lignes et un autre une seule. L’action peut encore garder une position prévisible si l’espace est réparti avec soin. La zone de titre doit pouvoir grandir et la relation entre titre, date et action doit rester claire.

Décidez quels textes peuvent être abrégés et comment atteindre leur version complète. Un aperçu de longue description diffère d’un titre qui identifie l’événement. Si deux événements deviennent impossibles à distinguer après troncature, le composant a perdu une information nécessaire à la sélection. Des points de suspension n’expliquent pas la différence manquante.

Vérifiez séparément les pastilles et statuts. Un statut plus long ne doit pas recouvrir le nom de l’événement ni chasser la date hors de la carte. Le déplacer sur sa propre ligne peut être préférable à réduire sa police. Examinez ensuite une carte à libellé court pour que la réparation ne crée pas un vide excessif partout ailleurs.

Formulaires : testez ensemble libellés, indications et erreurs

Les formulaires sont particulièrement sensibles à la longueur, car plusieurs contenus entourent la même commande. Le libellé identifie le champ, l’indication explique la saisie attendue et l’erreur décrit une correction. Tous peuvent s’allonger dans une autre langue.

Examinez chaque état en présence des autres. Un champ correct avec son seul libellé peut devenir confus lorsqu’une indication et une erreur traduites apparaissent dessous. Le lecteur doit encore identifier quelle information appartient à quel champ et où poursuivre après la correction.

Les libellés placés à côté des champs devront peut-être s’empiler lorsqu’ils deviennent longs. C’est un choix structurel, pas un signe de mauvaise traduction. Si vous gardez une disposition horizontale, laissez assez de place au libellé et à la commande pour remplir leur rôle. Un libellé généreux près d’un champ inutilisablement étroit n’est pas une amélioration.

Préservez les distinctions des messages d’erreur. « Obligatoire », « Trop long » et « Enregistrement impossible » décrivent des problèmes différents. La revue de localisation ne doit pas tous les comprimer en une formule générique courte parce que la zone d’erreur a une hauteur fixe. Laissez-la communiquer le problème précis et grandir avec le message.

Gardez nombres, unités et noms dans leur contexte

L’expansion ne concerne pas que les phrases. Dates, devises, noms et unités peuvent changer l’espace et l’ordre nécessaires à un composant. Traitez-les comme des exemples à examiner pour la langue concernée, pas comme des valeurs à improviser de mémoire.

Une ligne de prix peut associer un montant monétaire, une période et une précision. Si cette dernière passe à la ligne, vérifiez qu’elle reste clairement liée au prix. Dans l’exemple d’événement, une période peut demander davantage de place qu’une date unique. Garder le libellé et sa valeur ensemble peut compter davantage que gagner une ligne sur toute la carte.

Utilisez des noms représentatifs fournis par des utilisateurs, plutôt que supposer un nombre fixe de mots courts. Une disposition qui ne fonctionne que pour « Alex Lee » ne prouve pas que les noms plus longs seront lisibles. Déterminez où le nom complet doit rester visible et où une forme compacte convient à la tâche.

Ne concaténez pas des fragments dans la spécification visuelle comme si l’ordre source était universel. Une phrase assemblée à partir d’un nombre, d’un nom et d’un court suffixe peut exiger une autre construction dans la traduction. Transmettez le sens voulu et le contexte pour obtenir un message cohérent plutôt que demander de réarranger sans guide des morceaux déconnectés.

Les conseils rapides d’internationalisation du W3C traitent de ces fondations : déclaration de langue, séparation du contenu et de la présentation, précautions avec les chaînes assemblées.

Prévoyez de la place en hauteur comme en largeur

Une réparation courante consiste à augmenter la largeur tout en gardant toutes les hauteurs fixes. Cela aide un libellé, mais en coupe un autre dès que son nombre de lignes change. Examinez le flux vertical de la section entière : un titre plus long peut repousser un sous-titre, un groupe d’actions et la section suivante.

Laissez la page absorber cette croissance lorsque la tâche le permet. Une carte plus haute est souvent moins nuisible qu’une phrase essentielle disparue. Si la hauteur doit rester contrainte, définissez explicitement l’alternative, par exemple déplacer les détails secondaires vers une vue séparée tout en gardant l’identité visible.

Examinez le haut et le bas des caractères réellement affichés. Une boîte peut sembler assez grande pour les mots tout en coupant un accent ou une partie de glyphe. Changer de police, de système d’écriture ou de graisse peut révéler ce problème. Une capture faite avec la police source ne suffit pas pour un autre système d’écriture.

Ne forcez pas chaque langue à imiter le nombre exact de lignes de la source. Le design doit préserver hiérarchie, relations et utilisabilité. Des variations de hauteur de section et de retours à la ligne sont une conséquence raisonnable de l’expression d’un même sens par des textes différents.

Combinez tests de localisation et revue des largeurs

Une traduction qui fonctionne sur ordinateur peut encore échouer sur téléphone. Testez les composants vulnérables dans des vues étroite, intermédiaire et large, puis examinez les largeurs où la disposition change. Gardez la même langue pendant une tâche complète pour remarquer les relations qu’une série de captures isolées manquerait.

Séparez les problèmes de langue des problèmes de disposition. Une formulation peu naturelle demande une revue linguistique. Un libellé correct qui heurte une commande voisine demande un travail de mise en page. Les deux peuvent coexister, mais les classer évite que designer et traducteur se renvoient sans cesse le problème.

Pour juger définitivement la formulation et le sens, faites intervenir une personne qui comprend la langue. Une personne qui ne la parle pas peut détecter troncatures, chevauchements et caractères manquants ; elle ne peut pas confirmer de manière fiable qu’un libellé raccourci communique toujours la bonne action. Notez cette limite dans le compte rendu plutôt que de confondre le fait de tenir à l’écran avec une validation de traduction.

Les dispositions de droite à gauche demandent aussi une revue distincte de directionnalité. Allonger seulement du texte de gauche à droite ne prouve pas le bon fonctionnement de l’ordre, des contenus bidirectionnels ou des commandes directionnelles. Gardez ce travail visible plutôt que de le dissoudre dans une affirmation vague selon laquelle toutes les langues ont réussi.

Utilisez OpenDesign pour examiner et modifier la mise en page

OpenDesign peut accompagner ce travail avec son aperçu HTML, ses vues ordinateur, tablette et mobile et des modifications ciblées du design. Fournissez le texte validé comme contexte, examinez le résultat et décrivez une collision par commentaire ou dans le chat. Les modifications manuelles de texte et de style prises en charge permettent d’essayer un ajustement local.

Par exemple, précisez que le titre d’événement peut prendre des lignes supplémentaires, que la date doit rester entièrement visible et que l’action principale doit rester rattachée à sa carte. Gardez le texte inchangé pendant le test de réparation. Le résultat devient plus facile à juger qu’en demandant une refonte générale chaque fois qu’une chaîne longue apparaît.

Fournissez les traductions validées pour juger la disposition finale, afin qu’un changement de formulation ne masque pas une collision encore à réparer.

Après une réparation locale, comparez de nouveau contenu d’origine et contenu allongé. Une règle qui résout l’exemple le plus long peut rendre les libellés courts inutilement maladroits. Une bonne souplesse sert toute une plage : le texte ordinaire reste équilibré, le texte long reste utilisable et la raison d’un traitement exceptionnel est claire.

Définissez ce que signifie « prêt pour la traduction »

Une transmission utile consigne le comportement des composants vulnérables, les cas de résistance essayés et les vraies langues examinées. Incluez les restrictions non résolues, comme un widget externe à largeur de libellé fixe ou une image contenant du texte qui attend encore une version localisée.

Donnez du contexte aux traducteurs pour les chaînes ambiguës. La destination d’un bouton, les explications environnantes disponibles et la distinction entre actions proches peuvent compter. Si une limite de caractères est réellement inévitable, indiquez-la avec sa raison et identifiez qui peut décider de la changer. Ne transformez pas discrètement chaque largeur de conteneur actuelle en contrainte linguistique.