Testando l'interfaccia multilingue di Flutter, abbiamo trovato “300 BPM” diviso su due righe

Abbiamo verificato la visualizzazione su schermi piccoli e con testo ingrandito in “SANGE Metronome – Esercizi di ritmo semplici”, l'app che sviluppiamo in modo indipendente.

Uno dei problemi scoperti era la divisione delle cifre di “300 BPM” nei preferiti in “30” e “0”. Il testo non fuoriusciva dallo schermo. Ciononostante, il valore del tempo era diventato difficile da leggere.

Era necessario verificare separatamente l'assenza di eccezioni di layout e la leggibilità delle informazioni necessarie.

In questo articolo descriviamo i problemi di visualizzazione scoperti con i test dei widget in 12 lingue e i controlli delle schermate nell'emulatore Android, e come li abbiamo incorporati nelle correzioni e nei test.

Un layout che funziona in giapponese potrebbe non funzionare allo stesso modo in altre lingue

La schermata del metronomo mostra non soltanto il tempo, ma anche battiti, nomi dei ritmi, volume e nomi dei preferiti. La schermata di salvataggio richiede inoltre campi di input, spiegazioni degli errori e pulsanti Salva e Annulla.

Anche se un layout è adatto al giapponese, la lunghezza delle etichette cambia con la traduzione. Per esempio, “12拍” in giapponese e “12 Schläge” in tedesco richiedono larghezze diverse per il pulsante.

Ingrandendo ulteriormente il testo, gli elementi affiancati non trovano più spazio. Per questo abbiamo deciso di non limitarci a cambiare lingua, ma di combinare dimensioni dello schermo, scala del testo e schermata visualizzata nelle verifiche.

Verifica automatizzata con 12 lingue, 6 dimensioni e 3 scale del testo

Nei test dei widget abbiamo combinato le condizioni seguenti. Questi test renderizzano i componenti dell'interfaccia Flutter in un ambiente di prova per verificarli.

12 lingue × 6 dimensioni × 3 scale del testo × 8 schermate = 1,728 condizioni

I dati di prova comprendevano 300 BPM, 12 battiti, semicrome, volume al 100% e tre preferiti con nomi lunghi. Nella schermata di salvataggio abbiamo visualizzato anche l'errore per un nome duplicato.

Abbiamo impostato la scala del testo con TextScaler.linear. I valori 100%, 130% e 200% di questa verifica sono condizioni di ingrandimento lineare e non riproducono integralmente tutti gli ingrandimenti del testo offerti dalle impostazioni del sistema sui dispositivi reali.

Abbiamo raccolto immagini anche nell'emulatore Android in sette lingue: tedesco, francese, portoghese brasiliano, indonesiano, thailandese, vietnamita e giapponese. Non abbiamo provato tutte le combinazioni di dimensioni, scale e lingue. Abbiamo verificato le dimensioni e le scale in tedesco, mentre le altre sei lingue sono state controllate con configurazione 360×640 e scala del 130%.

Nell'emulatore, le barre del sistema riducono l'area disponibile per l'app. Oltre alle dimensioni impostate, abbiamo registrato le dimensioni logiche durante il rendering e quelle all'interno della SafeArea.

Adattare le colonne dei pulsanti dei battiti al testo

Il primo problema rilevato era la fuoriuscita a destra del testo esplicativo del tempo e dell'unità dei battiti. L'emulatore Android ha rilevato anche un RenderFlex overflow, rendendo necessaria una revisione del layout.

Anche i pulsanti di selezione dei battiti usavano quattro colonne fisse. Tuttavia, con etichette tradotte più lunghe o una scala del testo maggiore, quel numero di colonne non offriva larghezza sufficiente.

Abbiamo quindi misurato le etichette tradotte con TextPainter e determinato il numero di colonne in base alla larghezza necessaria, considerando anche la scala del testo. Negli spazi stretti riduciamo le colonne e disponiamo i pulsanti verticalmente.

Anche nella schermata iniziale abbiamo rivisto il layout che comprimeva nomi di ritmi lunghi in due colonne strette, disponendo battiti e ritmo verticalmente quando necessario. Per risolvere la divisione delle cifre dei battiti da 10 a 12, abbiamo consentito all'intero gruppo di indicatori dei battiti di distribuirsi su più righe.

La divisione di “300” non genera necessariamente un'eccezione

Esaminando le immagini, abbiamo individuato il problema nelle schede dei preferiti con configurazione 320×568 e scala del testo al 200%.

Poiché le schede rimanevano disposte su tre colonne, “300” andava a capo nel mezzo. Anche se il testo resta nell'area di visualizzazione, dividerlo in “30” e “0” rende difficile leggere il tempo.

Il solo controllo delle eccezioni di layout non ha consentito di rilevare questo problema.

La correzione ha adeguato il numero di colonne delle schede dei preferiti alla scala del testo. Sullo schermo piccolo al 200% di questa verifica, siamo passati a una colonna per evitare che le cifre del tempo si dividessero.

Insieme alla correzione abbiamo aggiunto ai test automatizzati il controllo che un BPM di tre cifre rimanga su una sola riga. Di seguito è riportato un estratto di questo controllo.

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',
  );
}

Verifichiamo che l'intervallo di caratteri corrispondente a “300” occupi una sola casella di rendering. Nei test completi abbiamo controllato il BPM di ciascuno dei tre preferiti e i numeri dei battiti da 1 a 12 nella schermata iniziale.

Questo metodo riguarda le cifre renderizzate con lo stesso carattere tipografico in questa verifica. Non è un metodo generale per individuare le interruzioni di riga nei testi che mescolano lingue o caratteri diversi.

Definire controlli concreti in base alle informazioni da visualizzare. Un risultato utile di questa verifica è stato riportare i problemi scoperti nelle immagini nei test automatizzati, per rilevarli anche nelle modifiche future.

È possibile leggere la spiegazione dell'errore e raggiungere il pulsante Salva?

Nella schermata di salvataggio abbiamo rivisto anche il limite di righe dei messaggi di errore.

In precedenza il testo era limitato a tre righe, ma su uno schermo stretto con testo ingrandito le traduzioni lunghe potevano non entrare. Abbiamo rimosso il limite di righe per consentire la lettura dell'intera spiegazione tramite scorrimento.

Abbiamo disposto i pulsanti Salva e Annulla verticalmente sugli schermi stretti o con testo grande. Abbiamo modificato anche il titolo e il pulsante di chiusura del modale, nonché i nomi delle impostazioni e i valori selezionati, per riservare più larghezza al testo.

Abbiamo aggiunto controlli anche durante la digitazione. Nei test dei widget abbiamo riservato un margine inferiore di 280 pixel logici equivalente alla tastiera e verificato che, dopo lo scorrimento, il pulsante Salva fosse visualizzato sopra quell'area. Abbiamo inoltre controllato che il limite di righe non troncasse i messaggi di errore.

Nell'emulatore Android abbiamo effettivamente attivato il campo di input e verificato il layout con la tastiera aperta. Tuttavia, i PNG raccolti in quel momento catturano solo la schermata Flutter e non mostrano la tastiera del sistema. Abbiamo registrato separatamente le immagini della visualizzazione normale e della digitazione.

Risultati dopo le correzioni e ambito della verifica

Questi sono i risultati della verifica del 30 ottobre 2026.

1,728 è il numero di combinazioni delle condizioni di visualizzazione, mentre 121 è il numero totale di test Flutter eseguiti. Poiché i test verificano ripetutamente più condizioni di visualizzazione, i due numeri hanno significati diversi.

478 è il numero di PNG raccolti. Non abbiamo assegnato un esito visivo individuale a ogni immagine: abbiamo selezionato le schermate principali per controllare caratteri tagliati o sovrapposti, numeri divisi e visualizzazione dopo lo scorrimento. Nelle schermate principali verificate in thailandese e vietnamita non abbiamo osservato quadrati per caratteri mancanti né sovrapposizioni del testo.

Oltre a sei dimensioni sintetiche, abbiamo usato sei configurazioni di visualizzazione nell'emulatore: Galaxy A16 5G, A06 4G, S24+, S23, Redmi 14C 4G e Pixel 9. Abbiamo preparato 30 configurazioni specifiche per modello, ma ne abbiamo eseguite sei in questa verifica.

Abbiamo applicato risoluzioni e densità approssimative di prova allo stesso emulatore Android 14. Non abbiamo riprodotto sistemi personalizzati dei produttori, caratteri o fori per la fotocamera, né verificato 30 modelli su dispositivi reali. I test Flutter sono stati eseguiti su Windows; questa volta non abbiamo eseguito neppure il confronto golden pixel per pixel per Linux.

Questo resoconto riguarda la verifica della visualizzazione. I risultati relativi a rendering, attivazione del campo di input e scorrimento non dimostrano il successo della riproduzione audio o della procedura di salvataggio.

Cosa continuare a verificare nelle prossime modifiche dell'interfaccia

Questa verifica ha reso concreti gli aspetti che vogliamo mantenere nei test di visualizzazione.

• Non dividere nel mezzo valori numerici come il tempo e i numeri dei battiti.
• Consentire la lettura integrale delle spiegazioni degli errori.
• Mantenere raggiungibili i pulsanti necessari con testo ingrandito e durante la digitazione.

Adattando il numero di colonne alle dimensioni del testo e alle traduzioni, e usando disposizione verticale e scorrimento, abbiamo riservato spazio per le informazioni e le operazioni necessarie.

Ripetere le condizioni nei test automatizzati e aggiungere ai controlli i problemi notati nelle immagini renderizzate. Mantenendo questo flusso, nelle prossime modifiche dell'interfaccia potremo verificare che i problemi trovati in questa occasione non si ripresentino.