Respondo se construyó en Dubái, y ese hecho moldeó el producto más que cualquier decisión de hoja de ruta que tomáramos. Una sola cola de soporte aquí puede contener a un cliente que escribe en árabe, otro en inglés, un tercero en hindi y un cuarto en urdu, a menudo dentro de la misma hora. Nunca hubo una versión de este producto que tratara un idioma como el predeterminado y el resto como traducciones. Más de treinta idiomas, incluidos los de derecha a izquierda, tenían que ser el cimiento, no una capa que añadiéramos después.

Esa restricción resultó ser esclarecedora. Cuando lo multilingüe no es opcional, muchos atajos que parecen razonables en un producto pensado primero para el inglés se revelan como callejones sin salida. Esto es lo que aprendimos al construir para esa realidad, tanto en la IA como en la interfaz.

Traducir no es comprender

La arquitectura tentadora es un pipeline: tomar el mensaje entrante, pasarlo por una API de traducción al inglés, procesarlo con sus modelos en inglés, generar una respuesta en inglés y volver a traducirla. Es barata, se construye rápido y falla justo en las situaciones de las que está hecha la atención al cliente.

Las conversaciones con clientes están cargadas de un contexto que la traducción genérica aplana. La jerga, los modismos, los registros de cortesía y la terminología específica de un dominio quedan todos limados en el viaje de ida y vuelta. El ejemplo clásico es una sola palabra con una bifurcación de significado: un cliente que pregunta por un «return» en un contexto de comercio minorista quiere saber sobre devolver un producto; la misma palabra en un contexto financiero se refiere al rendimiento de una inversión. Traducir-procesar-traducir pierde el hilo, porque, para cuando el modelo en inglés lo ve, el contexto que desambigua ya ha quedado destrozado.

Respondo, en cambio, usa modelos específicos para cada idioma. Un mensaje en árabe se comprende y se responde en árabe, de forma nativa, sin pasar nunca por el inglés como representación intermedia. Las distinciones que importan —el tono, el registro, el sentido correcto de una palabra ambigua— se captan en el idioma en el que realmente viven. Esa es la diferencia entre una respuesta que es técnicamente correcta y una que un hablante nativo reconoce como fluida.

Cuando la interfaz se invierte

Manejar los idiomas en el modelo es la mitad del problema. La otra mitad es la interfaz, y los idiomas de derecha a izquierda son donde la mayoría de los sistemas de diseño se desmoronan en silencio.

Dar soporte al árabe y al hebreo no es cuestión de traducir cadenas de texto. Toda la maquetación se invierte. El texto se alinea a la derecha. El orden de lectura va de derecha a izquierda, lo que significa que el flujo visual de una conversación, la posición de un botón de retroceso, la dirección hacia la que debe apuntar una flecha: todo se refleja como en un espejo. Un diseño construido con supuestos de izquierda a derecha incrustados en posiciones fijas no se traduce al RTL; se rompe.

La parte sutil es que no todo se invierte. Esta es la trampa en la que caen los equipos cuando descubren la propiedad direction de CSS y creen que el trabajo está hecho.

  • La maquetación, la alineación del texto y el orden de lectura se reflejan. Una barra lateral que en inglés está a la izquierda, en árabe corresponde a la derecha.
  • Los iconos con dirección heredan la inversión. Una flecha de «responder» o un chevrón de «siguiente» tiene que apuntar hacia el otro lado, porque su significado es direccional.
  • El contenido que es intrínsecamente LTR no se invierte. Los números de teléfono, los nombres de marca en alfabeto latino, los fragmentos de código y las URL se leen de izquierda a derecha con independencia del idioma que los rodea. Refléjelos y habrá creado un sinsentido.

Hacer esto bien a mano, componente por componente, a lo largo de todo un producto es exactamente el tipo de tarea que resulta imposible de mantener coherente a medida que el producto crece. Así que no lo hicimos a mano.

Basado en restricciones, no en posiciones

La decisión que hizo sostenible el RTL fue dejar de describir nuestros componentes en términos de posiciones absolutas y empezar a describirlos en términos de relaciones.

Un componente basado en posiciones dice «esta etiqueta se sitúa a 16 píxeles del borde izquierdo». Esa instrucción es errónea en el momento en que la maquetación se invierte. Un componente basado en restricciones dice «esta etiqueta se sitúa al inicio de la fila, con 16 píxeles de espacio antes de que empiece el contenido». Ahora «inicio» se resuelve automáticamente como la izquierda en inglés y la derecha en árabe, y la misma definición de componente se renderiza correctamente en ambas direcciones sin un solo condicional.

Nos apoyamos en las propias propiedades lógicas del navegador para expresar esto: el CSS moderno que piensa en *start* y *end* en lugar de *left* y *right*, y en *inline* y *block* en lugar de horizontal y vertical. Un componente escrito de esta forma no sabe ni le importa en qué dirección se está renderizando. La dirección se fija una sola vez, en la raíz, y cada componente por debajo se adapta.

El beneficio se acumula. Añadir el siguiente idioma RTL no cuesta casi nada, porque la lógica de maquetación nunca estuvo atada a una dirección concreta en primer lugar. Un componente nuevo construido sobre las primitivas compartidas es correcto en ambas direcciones por defecto: un ingeniero tendría que esforzarse expresamente para romperlo.

Espacio para que el texto respire

La última lección es la menos glamurosa y la que más a menudo se ignora: la longitud del texto varía enormemente de un idioma a otro, y una maquetación que solo ha visto inglés se resquebrajará ante los que no encajan.

La misma frase puede ser un 30 % más larga en alemán, llegar en un conjunto de caracteres completamente distinto en chino, donde unos pocos glifos cargan con lo que en inglés necesita una oración, o requerir más espacio vertical para los diacríticos que se sitúan encima y debajo de la escritura árabe. Un botón dimensionado para la palabra inglesa «Send» recorta o desborda su contenido en cuanto le cae dentro una traducción más larga.

Nuestros componentes asumen desde el principio que no saben cuán largo será su texto. Crecen con su contenido, se ajustan con elegancia y nunca dependen de que una cadena tenga una longitud concreta. Es una pequeña disciplina que ahorra mil arreglos puntuales de maquetación más adelante y que, como el manejo de la dirección, es de esas cosas que salen casi gratis si las incorpora desde el primer día y resultan enormemente caras de aplicar a posteriori.

El hilo conductor

Cada una de estas decisiones rima con la misma idea: lo multilingüe no puede ser una función que se añade, porque los supuestos de un producto de un solo idioma se cuelan en el modelo, en la maquetación y en cada componente individual. Construya primero para el inglés y pasará el resto de la vida del producto parcheando los lugares por donde se filtran esos supuestos. Construya para treinta idiomas desde el principio y el trigésimo primero sale casi gratis. Tener nuestra sede allí donde nuestros clientes hablan una docena de idiomas al día no lo hizo más difícil: lo hizo imposible de estropear en silencio, que es el mejor tipo de restricción bajo la que diseñar.