Préparer une interface multilingue avec une tâche concrète
Un exemple de portail montre comment prévoir textes longs, formats locaux, traductions manquantes et changement de langue pendant une tâche.

Partir d’un enregistrement inchangé
Préparez une interface multilingue autour d’une tâche complète : ouvrir, examiner et approuver une demande. Les textes doivent rester compréhensibles et les données métier conserver leur sens. Une liste de boutons traduits ne montre pas encore ces relations.
Un portail fictif de projets doit proposer dix langues. La demande R-18 contient le montant numérique 1234.5, la devise EUR et la date calendaire 2026-11-12. Pour cette tâche, la langue de l’interface ne change ni devise, ni montant, ni date, ni statut d’approbation. Une interface anglaise ne transforme pas le montant en dollars.
Définir les formats d’affichage
L’équipe choisit ces trois paramètres régionaux, qui précisent langue et région, pour la comparaison. Le montant est affiché en devise avec deux décimales ; la date avec jour et mois sur deux chiffres et année complète. La comparaison des dates utilise explicitement le fuseau UTC.
Paramètre régional | Montant affiché | Date affichée |
|---|---|---|
| 1.234,50 € | 12.11.2026 |
| €1,234.50 | 12/11/2026 |
| €1.234,50 | 12.11.2026 |
Intl.NumberFormat et Intl.DateTimeFormat permettent ces affichages adaptés à la langue. Les paramètres régionaux et les options sont choisis explicitement ; le réglage par défaut de l’ordinateur ne doit pas modifier la comparaison à l’insu de l’équipe. Une date désignant uniquement un jour calendaire ne doit pas changer de jour avec la langue. La saisie d’un montant exige en plus des règles adaptées de saisie et de validation : un texte formaté en sortie ne définit pas à lui seul un analyseur de saisie sûr.
Prévoir textes longs et états manquants
Vérifiez les libellés réels dans des vues étroites et larges. Dans l’exemple, le bouton « Approuver la demande de projet après examen » doit conserver son sens même si une traduction prend davantage de place. Un retour à la ligne prévu ou une autre disposition vaut mieux qu’une abréviation obscure. Un pourcentage fixe d’agrandissement ne garantit pas que chaque texte tiendra.
La couverture linguistique comprend aussi listes vides, chargements et erreurs. Si la traduction de approval.confirm manque dans l’exemple, le portail bloque l’approbation et affiche une explication compréhensible dans la langue choisie. Une langue de secours mêlée à l’interface n’est pas acceptée tacitement pour cette étape critique. C’est une règle produit choisie, pas une propriété automatique d’une bibliothèque de traduction.
Vérifier le changement de langue pendant la tâche
Ouvrez la même demande dans chaque langue prévue et changez de langue pendant la modification. Dans l’exemple, les saisies doivent être conservées ; le changement de langue ne doit déclencher aucune approbation. Vérifiez ensuite que montant, jour calendaire et statut toujours ouvert sont préservés.
Des textes de test artificiellement allongés peuvent révéler tôt des problèmes de disposition. Il faut néanmoins lire les traductions finales dans leur contexte et les vérifier sur la tâche complète. Consignez pour chaque langue si l’approbation est compréhensible et possible sans perte de données, ou quel état précis manque encore.
Sources
Écrit par
- Julia HoffmannRédactrice design et UXJulia Hoffmann est responsable chez ASES des contenus éditoriaux consacrés au design et à l’expérience utilisateur. Ses articles portent sur l’utilisation des sites web et des applications, la conception d’interfaces utilisateur et l’accessibilité numérique.
À lire aussi
Tous les articles







Design & UX avec ASES
Expérience utilisateur, interfaces et image de marque

