Soporte RTL: software que funciona en árabe y hebreo

El soporte RTL (right-to-left, de derecha a izquierda) significa que una interfaz se lee correctamente en idiomas como el árabe y el hebreo, donde el texto fluye de derecha a izquierda en lugar de izquierda a derecha. El error que comete casi cada equipo es tratarlo como un ajuste de alineación del texto. No lo es. El RTL invierte toda la maquetación: la navegación, los iconos, los campos de formulario y la dirección en que el ojo del usuario recorre la pantalla. Fállalo y el software no parece extranjero. Parece roto, y los usuarios de idiomas RTL lo notan en los primeros segundos.

Lo señalamos como una de las dos familias de escrituras que destapan más rápido una internacionalización (i18n) frágil, junto con las escrituras CJK, en el desarrollo de software multilingüe. Aquí tienes lo que el RTL exige de verdad: el reflejo de la maquetación, el mecanismo CSS que lo hace mantenible, el tratamiento del texto bidireccional y un enfoque de pruebas que caza los fallos antes de que lo haga un usuario real.

Por qué esto le toca a una empresa española

El RTL suena a mercado lejano hasta que miras el mapa. Marruecos está a unos catorce kilómetros de la costa andaluza, Ceuta y Melilla tienen frontera terrestre con él, y buena parte del comercio español con el Magreb pasa por ahí. A eso se suman los exportadores que venden en Argelia, Egipto o los países del Golfo, y las empresas con plantilla o clientes arabófonos dentro de España.

Conviene ser honestos con el alcance. En Marruecos y Argelia el francés sigue siendo lengua habitual de negocios, así que una interfaz en árabe rara vez es la única que necesitas: suele convivir con el francés y con el español. Eso no rebaja el problema técnico, lo agrava. Una aplicación que sirve francés y árabe tiene que voltear la pantalla entera según el idioma activo, en la misma versión y con la misma base de código.

Qué invierte de verdad el RTL

Poner dir="rtl" en una página voltea más cosas de las que la mayoría de los equipos imagina, y cada una tiene que estar bien, no solo el texto de los párrafos:

• Navegación y menús. Una navegación a la izquierda pasa a estar a la derecha. Migas de pan, pestañas y flechas de menús desplegables se invierten todas.
• Iconos que implican dirección. Las flechas de "atrás" y "siguiente", los galones y los indicadores de progreso apuntan al lado contrario, porque "avanzar" en una interfaz RTL apunta visualmente a la izquierda.
• Maquetación de formularios. Las etiquetas, la alineación de los campos y el orden de tabulación de un formulario de varios campos se reflejan todos, o el formulario se lee bien por separado pero tabula por los campos en el orden equivocado.
• Indicadores de progreso y de pasos. Un alta en cinco pasos que se rellena de izquierda a derecha en español tiene que rellenarse de derecha a izquierda en árabe, o la metáfora visual deja de tener sentido.

Sáltate uno solo de estos y obtienes una interfaz híbrida: texto árabe metido dentro de una maquetación dibujada para el español. Se lee como inacabada, porque lo está.

Las propiedades CSS lógicas: el mecanismo que hace mantenible el RTL

El viejo enfoque del RTL era una hoja de estilos aparte con cada left cambiado por right, mantenida a mano, siempre a la deriva respecto a la maquetación principal. El CSS moderno lo resuelve bien con las propiedades lógicas, que describen la posición respecto a la dirección del texto en lugar de respecto a un lado físico.

margin-inline-start y margin-inline-end sustituyen a margin-left y margin-right. padding-inline-start sustituye a un padding-left escrito en el código. Escrito así, el navegador voltea la maquetación de forma automática según el atributo dir de la página, y una sola hoja de estilos sirve bien las dos direcciones. Escrito a la antigua, con valores físicos de izquierda y derecha, nada se voltea, y el texto árabe acaba alineado a la izquierda en una interfaz alineada a la derecha, con el relleno en el lado equivocado.

Es la decisión que más pesa en el soporte RTL. Una base de código construida desde el principio sobre propiedades lógicas admite el RTL como una simple configuración. Una base de código construida sobre valores de izquierda y derecha escritos en el código exige una auditoría manual de cada componente antes de llegar ahí.

Cuando el texto árabe se cruza con un NIF español

El contenido real rara vez se queda en una sola dirección. Una frase en árabe que contiene un número de factura, un teléfono +34 961 234 567 o el NIF del emisor tiene que mostrar el texto RTL de derecha a izquierda mientras los caracteres latinos y las cifras incrustados siguen leyéndose de izquierda a derecha, en su sitio, sin revolver la frase que los rodea.

Todo esto lo rige el algoritmo bidireccional de Unicode (UAX #9), que determina el orden visual de un texto de direcciones mixtas a partir de las propiedades de los caracteres subyacentes. La mayoría de las veces funciona solo. Se rompe en dos puntos previsibles: los números y la puntuación en el borde de un tramo de texto, donde el algoritmo tiene que adivinar qué dirección "posee" un carácter compartido como un guion o una barra, y el contenido insertado de forma dinámica, como un nombre de producto sacado de una base de datos e interpolado en una frase traducida, donde el marcado que lo rodea no declara su dirección. El arreglo es explícito en ambos casos: los caracteres de aislamiento de Unicode (U+2066 a U+2069) o los elementos HTML dir y bdi marcan dónde el texto de una dirección va incrustado dentro de la otra, en lugar de dejar que el algoritmo adivine.

Sáltate este paso y obtienes el equivalente RTL del mojibake: un número de teléfono mostrado al revés, o un código de producto que aparece al lado equivocado de las palabras que lo rodean. En una factura destinada a una aduana, eso deja de ser un detalle estético. El paralelismo no es solo una imagen: los dos fallos vienen de la misma capa, y la cara en bytes del problema está en Unicode y codificación de caracteres.

Qué iconos se reflejan y cuáles no

No todos los iconos se voltean, y equivocarse en cualquiera de los dos sentidos se lee como un fallo.

Refleja estos: las flechas de atrás y adelante, los galones, los botones de "siguiente" y "anterior", las barras de progreso y cualquier icono que codifique una secuencia de izquierda a derecha o un sentido de avance.

No reflejes estos: los relojes, el botón de reproducción de un reproductor multimedia, una marca de verificación, las cifras, los logos y las fotografías de personas u objetos. Un reloj con la esfera invertida o un triángulo de reproducción al revés parece un fallo de representación, no una decisión de localización, porque estos iconos representan un objeto del mundo real, no una metáfora direccional.

La distinción suena simple planteada así. En la práctica exige una pasada deliberada por cada icono de la interfaz, clasificando cada uno, porque una transformación global de "voltearlo todo" se equivoca en los dos sentidos.

Probar el RTL antes de que los usuarios reales encuentren los fallos

Los fallos de RTL se esconden de una pasada de QA hecha solo en español, porque nada en la maquetación visible parece inacabado hasta que contenido RTL real la rellena. Tres comprobaciones cazan lo que un vistazo distraído pasa por alto:

1. Prueba con contenido árabe o hebreo real, no con lorem ipsum ni cajas de relleno. El texto de relleno es uniforme en longitud y dirección, así que nunca expone los casos límite bidireccionales ni el problema de expansión del texto: las etiquetas de interfaz cortas pueden estirarse hasta un 300 % en la traducción, y hasta las palabras corrientes son a menudo más largas que su original en inglés (W3C, Text size in translation). Nuestro propio idioma ya lo demuestra: un botón dimensionado para "Save" no sobrevive a "Guardar cambios", y menos aún a su equivalente en árabe.
2. Lanza una pasada de pseudolocalización con el modo RTL forzado. La mayoría de los frameworks modernos saben voltear la dirección de una página sin traducción en marcha, lo que hace aflorar rápido las roturas de maquetación (iconos apuntando al lado equivocado, formularios desalineados, desbordamientos) antes de que el contenido traducido esté listo para probar.
3. Incluye al menos un caso de prueba de direcciones mixtas. Un campo de formulario, un resultado de búsqueda o una notificación que combine texto RTL con un código de producto, una dirección de correo o un importe de tu soporte multidivisa en caracteres latinos. Ahí es justo donde el algoritmo bidireccional necesita ayuda y donde se esconden los fallos de unión. Un precio en dírhams marroquíes mostrado al revés en una frase árabe sigue siendo un precio equivocado.

Metemos la pseudolocalización y al menos una locale RTL y una CJK en cada proyecto multilingüe, precisamente por esto: los fallos de RTL cuestan poco de corregir durante el desarrollo y mucho de corregir después de que un cliente avise de que la aplicación "se ve rota" en árabe.

Preguntas frecuentes sobre el soporte RTL

¿Qué significa RTL en software?

RTL significa right-to-left, de derecha a izquierda, en referencia a idiomas como el árabe y el hebreo que se leen en ese sentido. El soporte RTL significa que toda la interfaz, no solo el texto, se refleja correctamente: navegación, iconos, formularios y dirección de la maquetación se invierten juntos.

¿Qué idiomas necesitan soporte RTL?

El árabe y el hebreo son las dos grandes escrituras RTL del software comercial; el persa (farsi) y el urdu también usan la escritura árabe y se leen de derecha a izquierda. Todos los demás grandes idiomas del mundo, incluidos el chino, el japonés y el coreano, se leen de izquierda a derecha pese a otras particularidades de maquetación.

¿Puedo simplemente voltear mi CSS cambiando izquierda por derecha?

Puedes, pero eso crea una segunda hoja de estilos que se desincroniza con cada actualización de la maquetación principal. Las propiedades CSS lógicas (margin-inline-start en vez de margin-left) dejan que una sola hoja de estilos sirva las dos direcciones de forma automática, según la dirección declarada de la página.

¿Por qué un texto árabe muestra a veces números o palabras en inglés en el orden equivocado?

Es un fallo de texto bidireccional: el contenido de direcciones mixtas (texto árabe que contiene un código de producto latino, un número de teléfono o un nombre de marca) necesita marcadores de dirección explícitos para que el algoritmo bidireccional de Unicode lo muestre bien. Sin ellos, el algoritmo tiene que adivinar, y a veces adivina mal en la frontera entre escrituras.

¿Cómo se prueba bien el soporte RTL?

Con contenido árabe o hebreo real en lugar de texto de relleno, una pasada de pseudolocalización en RTL forzado para cazar pronto las roturas de maquetación, y al menos un caso de prueba que mezcle texto RTL con números o códigos de producto latinos. Integramos estas pruebas en cada proyecto multilingüe; pide un presupuesto cerrado y el soporte RTL entra en el alcance desde el principio.

Constrúyelo bien a la primera

Cuéntanos qué escrituras y qué direcciones tiene que admitir tu software. Metemos el RTL en el alcance desde el primer commit, no como un parche, y respondemos con un precio cerrado y una fecha de entrega.

Pide un presupuesto cerrado →