Aller au contenu

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.

Julia Hoffmann2 min de lecture
Smartphone avec bandeau bleu, deux champs de largeurs différentes et flèches en sens opposés.

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

de-DE

1.234,50 €

12.11.2026

en-GB

€1,234.50

12/11/2026

tr-TR

€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.

Suivre ASES

À lire aussi

Tous les articles

Design & UX avec ASES

Expérience utilisateur, interfaces et image de marque