Al probar la interfaz multilingüe de Flutter, «300 BPM» apareció dividido en dos líneas

Comprobé la visualización de la aplicación que desarrollo de forma independiente, «SANGE Metronome – Práctica de ritmo sencilla», en pantallas pequeñas y con texto ampliado.

Uno de los problemas encontrados fue que las cifras de «300 BPM» en una tarjeta de favoritos se dividían en «30» y «0». El texto no se salía de la pantalla, pero el valor del tempo resultaba difícil de leer.

Era necesario comprobar tanto la ausencia de excepciones de diseño como la legibilidad de la información esencial.

Este artículo describe los problemas de visualización detectados con pruebas de widgets en 12 idiomas y revisiones de pantallas en un emulador de Android, y cómo se incorporaron a las correcciones y las pruebas.

Un diseño que cabe en japonés puede no servir para otros idiomas

La pantalla del metrónomo muestra, además de las cifras del tempo, pulsos, nombres de ritmos, volumen y nombres de favoritos. La pantalla de guardado también necesita un campo de entrada, explicaciones de errores y botones Guardar y Cancelar.

Aunque un diseño encaje en japonés, la longitud de las etiquetas cambia al traducirlas. Por ejemplo, «12拍» en japonés y «12 Schläge» en alemán necesitan botones de distinto ancho.

Al aumentar el texto, los elementos colocados uno junto a otro también dejan de caber. Por eso decidí no limitarme a cambiar el idioma, sino combinar tamaño de pantalla, escala de texto y pantalla mostrada en las comprobaciones.

Verificación automática con 12 idiomas, 6 tamaños y 3 escalas de texto

Las pruebas de widgets combinaron las siguientes condiciones. Este tipo de prueba renderiza componentes de la interfaz de Flutter en un entorno de pruebas para poder comprobarlos.

12 idiomas × 6 tamaños × 3 escalas de texto × 8 pantallas = 1.728 condiciones

Los datos de prueba incluían 300 BPM, 12 pulsos, semicorcheas, volumen al 100 % y tres favoritos con nombres largos. La pantalla de guardado también mostraba el error de nombre duplicado.

La escala de texto se especificó con TextScaler.linear. Los valores 100 %, 130 % y 200 % de estas pruebas amplían el texto linealmente; no reproducen todos los aspectos de la ampliación mediante los ajustes del sistema operativo de un dispositivo físico.

También se recogieron imágenes en un emulador de Android para siete idiomas: alemán, francés, portugués de Brasil, indonesio, tailandés, vietnamita y japonés. No se combinaron exhaustivamente todos los tamaños, escalas e idiomas. Los tamaños y las escalas se comprobaron en alemán, y los otros seis idiomas con un ajuste de 360×640 al 130 %.

Las barras del sistema reducen el área disponible para la aplicación en el emulador. Además del tamaño configurado, registré el tamaño lógico durante el renderizado y el tamaño dentro de SafeArea.

Ajustar las columnas de los botones de pulsos al texto

Los primeros problemas fueron las descripciones de tempo y las unidades de pulso que se salían por la derecha. El emulador de Android también notificó RenderFlex overflow, lo que hizo necesario revisar el diseño.

Los botones de selección de pulsos también usaban un diseño fijo de cuatro columnas. Sin embargo, unas etiquetas traducidas más largas o una escala de texto mayor dejan un ancho insuficiente para ese número de columnas.

Para ello medí las etiquetas traducidas con TextPainter y determiné el número de columnas a partir del ancho necesario, incluida la escala de texto. En condiciones estrechas, menos columnas permiten extender los botones en vertical.

También revisé el diseño estrecho de dos columnas para los nombres de ritmos largos de la pantalla de inicio, colocando los pulsos y el ritmo en vertical cuando es necesario. Para resolver las cifras partidas de los pulsos 10 a 12, permití que el conjunto de la visualización de pulsos se distribuyera en varias filas.

Dividir «300» no siempre genera una excepción

Al revisar las imágenes, detecté un problema con las tarjetas de favoritos con el ajuste de visualización 320×568 y una escala de texto del 200 %.

Las tarjetas seguían distribuidas en tres columnas, lo que provocaba un salto de línea dentro de «300». Aunque el texto permanezca en su área de visualización, dividirlo en «30» y «0» dificulta leer el valor del tempo.

Las comprobaciones de excepciones de diseño por sí solas no detectaron este problema.

La corrección ajusta el número de columnas de las tarjetas de favoritos a la escala de texto. Al 200 % en la pantalla pequeña comprobada aquí, las tarjetas usan una columna para mantener juntas las cifras del tempo.

Junto con la corrección añadí una comprobación automática de que un valor de BPM de tres cifras cabe en una sola línea. A continuación se muestra un extracto de esa comprobación.

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 comprobación confirma que el intervalo de caracteres correspondiente a «300» tiene una sola caja de renderizado. En las pruebas reales se comprobó el BPM de cada uno de los tres favoritos y los números de pulso del 1 al 12 de la pantalla de inicio.

Este método se aplica a los dígitos dibujados con la misma tipografía en estas pruebas. No es un método general para detectar saltos de línea en textos que mezclan idiomas o tipografías diferentes.

Concretar las comprobaciones según la información que debe transmitir la interfaz. Un resultado útil fue convertir un problema detectado en las imágenes en una prueba automática capaz de detectarlo después de futuros cambios.

¿Se puede acceder al error completo y al botón Guardar?

También revisé el límite de líneas de los errores en la pantalla de guardado.

El mensaje de error estaba limitado originalmente a tres líneas, por lo que una traducción larga podía no caber con texto ampliado en una pantalla estrecha. Eliminé el límite de líneas para que la explicación completa quedara accesible al desplazarse.

Los botones Guardar y Cancelar ahora se colocan en vertical en pantallas estrechas o con texto grande. También se reorganizaron los títulos y botones de cierre de los diálogos, así como los nombres de ajustes y sus valores seleccionados, para dejar suficiente ancho al texto.

También añadí comprobaciones durante la introducción de texto. Las pruebas de widgets reservaron un margen inferior de 280 píxeles lógicos para simular el teclado y verificaron que, al desplazarse, el botón Guardar aparecía por encima de esa zona. También comprobaron que los mensajes de error no se truncaban por un límite de líneas.

En el emulador de Android enfoqué realmente el campo de entrada y comprobé el diseño con el teclado abierto. Sin embargo, los PNG recogidos solo capturan la superficie de Flutter y no incluyen el propio teclado del sistema operativo. Las vistas normales y las de introducción de texto se registraron por separado.

Resultados tras las correcciones y alcance de la verificación

Estos son los resultados de la verificación realizada el 30 de octubre de 2026.

1.728 es el número de combinaciones de condiciones de visualización y 121 es el total de pruebas de Flutter ejecutadas. Son cifras distintas porque cada prueba comprueba repetidamente varias condiciones de visualización.

478 es el número de PNG recogidos. No se asignó un resultado visual individual de aprobado o suspenso a cada imagen; se seleccionaron pantallas principales para comprobar caracteres ausentes o superpuestos, cifras partidas y la vista tras el desplazamiento. En las pantallas principales inspeccionadas en tailandés y vietnamita tampoco aparecieron cuadros de glifos ausentes ni textos superpuestos.

Además de seis tamaños sintéticos, el emulador utilizó seis perfiles de visualización: Galaxy A16 5G, A06 4G, S24+, S23, Redmi 14C 4G y Pixel 9. Preparé 30 perfiles de dispositivos, pero en esta verificación ejecuté seis de ellos.

Estos ajustes aplicaron resoluciones y densidades aproximadas de prueba al mismo emulador de Android 14. No se reprodujeron los sistemas operativos personalizados, las fuentes o los orificios de cámara de los fabricantes, ni se probaron 30 modelos de dispositivos físicos. Las pruebas de Flutter se ejecutaron en Windows; tampoco se realizaron esta vez comparaciones golden con coincidencia exacta de píxeles para Linux.

Este registro trata de la verificación de la visualización. Renderizar pantallas, enfocar campos de entrada y comprobar el desplazamiento no demuestra que la reproducción de audio o el guardado de datos hayan tenido éxito.

Qué comprobar en el próximo cambio de la interfaz

Esta verificación concretó los aspectos que conviene conservar en las pruebas de visualización.

• No dividir números como los valores de tempo y los números de pulso.
• Permitir leer la explicación completa del error.
• Mantener accesibles los botones de acción necesarios con texto ampliado y durante la introducción de texto.

Ajustar el número de columnas al tamaño del texto y a las traducciones, y utilizar disposiciones verticales y desplazamiento, permitió reservar espacio para la información y los controles necesarios.

Comprobar las condiciones repetidamente con pruebas automáticas y añadir comprobaciones para los problemas detectados en las imágenes realmente renderizadas. Conservar este proceso permite comprobar, tras el próximo cambio de la interfaz, que los problemas encontrados aquí no han reaparecido.