Le test de l’interface multilingue Flutter a révélé « 300 BPM » sur deux lignes

J’ai vérifié l’affichage de l’application que je développe en indépendant, « SANGE Metronome – Pratique simple du rythme », sur de petits écrans et avec un texte agrandi.

L’un des problèmes découverts était la séparation des chiffres de « 300 BPM » dans un favori en « 30 » et « 0 ». Le texte ne débordait pas de l’écran, mais la valeur du tempo devenait difficile à lire.

Il fallait vérifier à la fois l’absence d’exceptions de mise en page et la lisibilité des informations essentielles.

Cet article présente les problèmes d’affichage trouvés grâce aux tests de widgets dans 12 langues et à l’examen des écrans dans un émulateur Android, ainsi que leur prise en compte dans les corrections et les tests.

Une disposition adaptée au japonais ne convient pas forcément aux autres langues

L’écran du métronome affiche, en plus des chiffres du tempo, les temps, les noms de rythmes, le volume et les noms des favoris. L’écran d’enregistrement a aussi besoin d’un champ de saisie, d’explications d’erreurs et de boutons Enregistrer et Annuler.

Même lorsqu’une disposition convient au japonais, la longueur des libellés change après traduction. Par exemple, « 12拍 » en japonais et « 12 Schläge » en allemand nécessitent des largeurs de bouton différentes.

Quand le texte grandit, les éléments disposés côte à côte ne tiennent plus non plus. J’ai donc décidé de ne pas seulement changer la langue, mais de combiner taille d’écran, échelle de texte et écran affiché dans les vérifications.

Vérification automatisée dans 12 langues, 6 tailles et 3 échelles de texte

Les tests de widgets ont combiné les conditions suivantes. Un test de widget affiche les composants d’interface Flutter dans un environnement de test pour permettre leur vérification.

12 langues × 6 tailles × 3 échelles de texte × 8 écrans = 1 728 conditions

Les données de test utilisaient 300 BPM, 12 temps, des doubles croches, un volume à 100 % et trois favoris aux noms longs. L’écran d’enregistrement affichait également l’erreur de nom en double.

L’échelle de texte a été définie avec TextScaler.linear. Les valeurs 100 %, 130 % et 200 % utilisées ici agrandissent le texte de façon linéaire et ne reproduisent pas tous les aspects de l’agrandissement par les réglages du système sur un appareil réel.

Des images ont également été collectées dans un émulateur Android pour sept langues : allemand, français, portugais brésilien, indonésien, thaï, vietnamien et japonais. Toutes les tailles, échelles et langues n’ont pas été combinées de manière exhaustive. Les tailles et échelles ont été vérifiées en allemand, et les six autres langues avec un réglage de 360×640 à 130 %.

Les barres du système réduisent la surface disponible pour l’application dans l’émulateur. Outre la taille configurée, j’ai enregistré la taille logique lors du rendu et celle à l’intérieur de SafeArea.

Adapter le nombre de colonnes des boutons de temps au texte

Les premiers problèmes trouvés concernaient des descriptions du tempo et des unités de temps qui débordaient à droite. L’émulateur Android a également signalé RenderFlex overflow, ce qui a nécessité de revoir la mise en page.

Les boutons de sélection des temps utilisaient aussi une disposition fixe sur quatre colonnes. Avec des libellés traduits plus longs ou une échelle de texte supérieure, la largeur n’est toutefois plus suffisante pour ce nombre de colonnes.

J’ai donc mesuré les libellés traduits avec TextPainter et déterminé le nombre de colonnes d’après la largeur nécessaire, en tenant compte de l’échelle de texte. Lorsque l’espace est réduit, moins de colonnes permettent d’étendre les boutons verticalement.

Sur l’accueil, j’ai aussi revu la disposition étroite sur deux colonnes des longs noms de rythmes pour placer les temps et le rythme verticalement si nécessaire. Pour éviter de couper les chiffres des temps 10 à 12, l’ensemble de l’affichage des temps peut maintenant passer sur plusieurs rangées.

Couper « 300 » ne déclenche pas toujours d’exception

En examinant les images, j’ai repéré un problème avec les favoris au réglage d’affichage 320×568 et à l’échelle de texte 200 %.

Les cartes restaient disposées sur trois colonnes, ce qui provoquait un retour à la ligne au milieu de « 300 ». Même si le texte reste dans sa zone, séparer les chiffres en « 30 » et « 0 » rend le tempo difficile à lire.

Les seules vérifications d’exceptions de mise en page n’ont pas permis de détecter ce problème.

La correction adapte le nombre de colonnes des favoris à l’échelle de texte. À 200 % sur le petit écran testé ici, les cartes utilisent une colonne afin que les chiffres du tempo restent groupés.

En parallèle de la correction, j’ai ajouté une assertion automatique vérifiant qu’une valeur BPM à trois chiffres tient sur une ligne. En voici un extrait.

for (var card = 0; card < 3; card++) {
  final paragraph = tester.renderObject<RenderParagraph>(
    find.text('300  BPM').at(card),
  );
  expect(
    paragraph.getBoxesForSelection(
      const TextSelection(baseOffset: 0, extentOffset: 3),
    ),
    hasLength(1),
    reason:
        '$locale/$size/$scale favorite BPM must stay on one line',
  );
}

La vérification confirme que la plage de caractères correspondant à « 300 » ne forme qu’une seule boîte de rendu. Les tests réels vérifiaient les BPM de chacun des trois favoris, ainsi que les numéros de temps de 1 à 12 sur l’accueil.

Cette méthode concerne les chiffres rendus avec une même police dans ces tests. Ce n’est pas une méthode générale de détection des retours à la ligne dans des textes mêlant différentes langues ou polices.

Définir des assertions adaptées aux informations que l’interface doit transmettre. L’un des apports de cette vérification a été de transformer un problème repéré sur les images en test automatique capable de le détecter après de futures modifications.

Peut-on atteindre tout le message d’erreur et le bouton Enregistrer ?

J’ai également revu la limite de lignes des erreurs sur l’écran d’enregistrement.

Le message d’erreur était initialement limité à trois lignes. Une traduction longue risquait donc d’être tronquée avec un texte agrandi sur un écran étroit. J’ai supprimé cette limite pour que toute l’explication reste accessible par défilement.

Les boutons Enregistrer et Annuler sont désormais disposés verticalement sur les écrans étroits ou avec un texte agrandi. Le titre et le bouton de fermeture des fenêtres modales, ainsi que les noms de réglages et leurs valeurs, ont aussi été réorganisés pour laisser assez de largeur au texte.

J’ai également ajouté des vérifications pendant la saisie. Dans les tests de widgets, une marge inférieure de 280 pixels logiques simule le clavier ; le test vérifie qu’après défilement le bouton Enregistrer apparaît au-dessus de cette zone. Il vérifie aussi que les messages d’erreur ne sont pas tronqués par une limite de lignes.

Dans l’émulateur Android, j’ai réellement placé le focus dans le champ de saisie et vérifié la disposition avec le clavier ouvert. Toutefois, les PNG collectés ne capturent que la surface Flutter, sans le clavier du système lui-même. Les états normaux et en cours de saisie ont été consignés séparément.

Résultats après correction et périmètre vérifié

Voici les résultats de la vérification du 30 octobre 2026.

1 728 correspond au nombre de combinaisons de conditions d’affichage, et 121 au nombre total de tests Flutter exécutés. Ce sont deux chiffres distincts, car plusieurs conditions d’affichage sont vérifiées de manière répétée dans un même test.

478 est le nombre de PNG collectés. Je n’ai pas attribué un verdict visuel individuel à chaque image : j’ai sélectionné les écrans principaux pour vérifier les caractères manquants ou superposés, les chiffres coupés et l’affichage après défilement. Les écrans principaux inspectés en thaï et en vietnamien ne présentaient pas non plus de carrés signalant des glyphes manquants ni de textes superposés.

En plus des six tailles synthétiques, l’émulateur a utilisé six profils d’affichage : Galaxy A16 5G, A06 4G, S24+, S23, Redmi 14C 4G et Pixel 9. Trente profils d’appareils ont été préparés, mais six ont été exécutés dans cette vérification.

Ces réglages ont appliqué des résolutions et des densités approximatives de test au même émulateur Android 14. Les vérifications n’ont pas reproduit les systèmes personnalisés, les polices ou les découpes de caméra des fabricants, et n’ont pas été réalisées sur 30 modèles d’appareils physiques. Les tests Flutter ont été exécutés sous Windows ; les comparaisons golden à correspondance exacte des pixels sous Linux n’ont pas été exécutées non plus cette fois-ci.

Ce compte rendu porte sur l’affichage. L’affichage des écrans, le focus dans les champs et les vérifications du défilement ne permettent pas de conclure que la lecture audio ou l’enregistrement des données ont réussi.

Points à vérifier lors de la prochaine modification de l’interface

Cette vérification a précisé les assertions à conserver dans les tests d’affichage.

• Ne pas séparer les chiffres des valeurs de tempo et des numéros de temps.
• Permettre la lecture intégrale de l’explication de l’erreur.
• Garder les boutons d’action nécessaires accessibles avec un texte agrandi et pendant la saisie.

En adaptant le nombre de colonnes à la taille du texte et aux traductions, puis en utilisant une disposition verticale et le défilement, j’ai réservé l’espace nécessaire aux informations et aux commandes.

Vérifier les conditions à répétition avec des tests automatiques, puis ajouter des assertions pour les problèmes remarqués dans les images réellement affichées. En conservant ce processus, il devient possible de vérifier que les problèmes trouvés ici ne réapparaissent pas lors de la prochaine modification de l’interface.