Saltar al contenido

Planificar una interfaz multilingüe con una tarea concreta

Un ejemplo de portal permite planificar textos largos, formatos locales, traducciones ausentes y cambios de idioma durante una tarea.

Julia Hoffmann2 min de lectura
Teléfono con cabecera azul, dos campos de distinto ancho y flechas en sentidos opuestos.

Partir de un registro que no cambia

Planifique una interfaz multilingüe con una tarea completa: abrir, revisar y aprobar una solicitud. Los textos deben seguir siendo comprensibles y los datos de negocio conservar su significado. Una lista de botones traducidos todavía no muestra estas relaciones.

Un portal ficticio de proyectos admitirá diez idiomas. La solicitud R-18 contiene el importe numérico 1234.5, la moneda EUR y la fecha de calendario 2026-11-12. En esta tarea, el idioma de la interfaz no cambia moneda, importe, fecha ni estado de aprobación. Una interfaz inglesa no convierte el importe en dólares.

Definir expresamente los formatos

El equipo elige estas tres configuraciones regionales, que indican idioma y región, para compararlas. El importe aparece como moneda con dos decimales; la fecha, con día y mes de dos cifras y año completo. La comparación de fechas utiliza expresamente la zona horaria UTC.

Configuración regional

Importe mostrado

Fecha mostrada

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 e Intl.DateTimeFormat permiten estas presentaciones según el idioma. La configuración regional y las opciones se eligen expresamente; el ajuste predeterminado del equipo no debe cambiar la comparación inadvertidamente. Una fecha que representa solo un día de calendario no debe desplazarse a otro al cambiar el idioma. Si se introducen importes, hacen falta además reglas adecuadas de entrada y validación: una salida formateada no define por sí sola un analizador seguro de entradas.

Prever textos largos y estados ausentes

Compruebe las etiquetas reales en vistas estrechas y amplias. En el ejemplo, el botón «Aprobar la solicitud del proyecto tras revisarla» debe conservar su significado aunque una traducción necesite más espacio. Un salto de línea previsto u otra disposición resulta más útil que una abreviatura incomprensible. Un porcentaje fijo de ampliación no garantiza que todos los textos quepan.

La cobertura lingüística también incluye listas vacías, estados de carga y errores. Si falta la traducción de approval.confirm, el portal del ejemplo bloquea la aprobación y muestra una explicación comprensible en el idioma elegido. Para este paso crítico no se acepta silenciosamente un idioma de reserva mezclado con la interfaz. Es una regla de producto elegida, no una propiedad automática de una biblioteca de traducción.

Comprobar el cambio de idioma durante la tarea

Abra la misma solicitud en cada idioma previsto y cambie de idioma mientras la edita. En el ejemplo deben conservarse los datos introducidos; el cambio no debe activar la aprobación. Compruebe después que se mantienen importe, día de calendario y estado todavía abierto.

Los textos de prueba alargados artificialmente pueden revelar pronto problemas de diseño. Aun así, debe leer las traducciones finales en contexto y comprobar la tarea completa. Registre por idioma si la aprobación es comprensible y posible sin perder datos, o qué estado concreto sigue faltando.

Fuentes

Escrito por

  • Julia HoffmannRedactora de diseño y UXJulia Hoffmann es responsable en ASES de los contenidos editoriales sobre diseño y experiencia de usuario. Sus artículos tratan el uso de sitios web y aplicaciones, el diseño de interfaces de usuario y la accesibilidad digital.

Seguir a ASES

Seguir leyendo

Todos los artículos

Diseño y UX con ASES

Experiencia de usuario, interfaces e imagen de marca