Layout internacional: dirección, elasticidad y pseudoidiomas

Hay una asimetría curiosa en cómo se distribuye el esfuerzo de internacionalizar. La traducción, que es la parte visible, cuesta dinero pero es un proceso conocido y acotado; el layout, que nadie presupuesta, es donde aparecen los defectos que obligan a rehacer pantallas. La razón es que el diseño original codifica sin querer un conjunto de supuestos sobre el texto que lo va a habitar: que se lee hacia la derecha, que una etiqueta de botón cabe en ochenta puntos, que un icono de flecha apunta hacia delante, que dos líneas bastan. Ninguno de esos supuestos es una propiedad del diseño; todos son propiedades del inglés. Una interfaz internacional no es una interfaz traducida: es una interfaz que dejó de suponer, y esa renuncia se hace en el momento de escribirla o no se hace nunca a coste razonable.

Dirección: no hay izquierda ni derecha

El árabe, el hebreo, el persa y el urdu se leen de derecha a izquierda, y eso no afecta solo al texto: invierte el eje de progresión de toda la interfaz. La barra de navegación coloca el botón de retroceso a la derecha, las filas alinean su contenido al otro lado, el indicador de detalle apunta al lado contrario, los gestos de deslizamiento cambian de sentido y hasta el orden de lectura de un formulario se refleja. El sistema hace la mayor parte de ese trabajo por su cuenta, pero solo si el código no le ha impedido hacerlo.

La regla operativa es que en una interfaz internacional no existen los conceptos de izquierda y derecha: existen inicio y final, que el sistema resuelve según la dirección activa. SwiftUI está construido sobre esa idea, de modo que las alineaciones leading y trailing, los rellenos por borde y las pilas horizontales ya se comportan correctamente. Los problemas aparecen justo donde alguien decidió ser explícito.

// Mal: fija la geometría a una dirección concreta
.padding(.left, 16)
.frame(maxWidth: .infinity, alignment: .init(horizontal: .leading, vertical: .center))
.offset(x: 12)

// Bien: relativo a la dirección de lectura
.padding(.leading, 16)
.frame(maxWidth: .infinity, alignment: .leading)

Los desplazamientos por coordenada son el caso que más se escapa, porque no tienen versión relativa: un valor positivo en el eje horizontal siempre va hacia la derecha física, también en árabe. Lo mismo ocurre con las transformaciones, los gradientes con puntos de inicio y fin y cualquier dibujo hecho en un Canvas. En todos esos sitios hay que leer la dirección del entorno y decidir el signo.

@Environment(\.layoutDirection) private var direccion

var body: some View {
    Insignia()
        .offset(x: direccion == .rightToLeft ? -12 : 12)
}

Queda la pregunta que más discusiones genera: qué se refleja y qué no. La respuesta no es estética sino semántica, y se resume en un criterio: se refleja lo que representa progresión o dirección de lectura, y no se refleja lo que representa una realidad física o un sentido temporal universal.

Los símbolos del sistema ya llevan esa distinción codificada y se reflejan solos cuando corresponde. Para un recurso propio, el catálogo de imágenes permite declarar la dirección del reflejo, y desde código existe el modificador que fuerza el volteo de una vista concreta. Conviene usarlo con parsimonia: el reflejo indiscriminado de una pantalla completa produce logotipos invertidos y texto ilegible.

Texto que crece

La segunda fuente de roturas es la elasticidad. Las estimaciones habituales del sector, recogidas en las guías de internacionalización de las grandes plataformas, sitúan la expansión respecto del inglés en torno al treinta por ciento para textos medios, y muy por encima para textos cortos: una palabra de cinco caracteres puede triplicarse. El alemán es el caso arquetípico por sus compuestos, pero el finés, el ruso y el francés canadiense compiten de cerca. En la dirección contraria, el chino y el coreano contraen mucho, y una etiqueta pensada para dos líneas puede quedar ridículamente corta.

De ahí se sigue una regla de diseño que conviene tratar como no negociable: ningún contenedor de texto lleva ancho fijo. Un frame con ancho constante alrededor de una etiqueta es una afirmación sobre la longitud de una frase que no ha sido traducida todavía. La alternativa es dejar que el texto negocie su tamaño y controlar solo lo que de verdad importa, que es el número de líneas y el comportamiento al desbordar.

Text(titulo)
    .lineLimit(2)
    .minimumScaleFactor(0.8)      // último recurso, no política general
    .fixedSize(horizontal: false, vertical: true)

El orden de preferencia entre las salidas al desbordamiento importa más de lo que parece. Permitir más líneas es casi siempre mejor que truncar, y truncar es mejor que encoger, porque el texto encogido rompe la jerarquía tipográfica y a partir de cierto punto deja de ser legible para quien tiene baja visión. La reducción de escala debería reservarse a números y a etiquetas donde la pérdida de una palabra impide entender el control.

La elasticidad tiene además una consecuencia estructural que va más allá del ajuste de una etiqueta: cambia qué disposición es la correcta. Una fila con título a la izquierda y valor a la derecha es legible en inglés y se convierte en dos columnas estranguladas en alemán, donde la solución no es reducir el cuerpo de letra sino apilar los elementos. ViewThatFits expresa exactamente esa decisión, ofreciendo una alternativa vertical cuando la horizontal no cabe, y lo hace midiendo el texto real en lugar de comparar identificadores de idioma.

ViewThatFits(in: .horizontal) {
    HStack { Text(titulo); Spacer(); Text(valor) }
    VStack(alignment: .leading) { Text(titulo); Text(valor) }
}

El peor escenario no es el alemán por sí solo, sino el alemán combinado con el tamaño de texto máximo del sistema. Ese cruce multiplica los dos factores y es donde aparecen los recortes, los solapamientos y los botones cuyo rótulo desaparece. Diseñar pensando en él tiene además un efecto lateral valioso: una fila que sobrevive a esa combinación es una fila que se adapta a cualquier cosa, lo que incluye tamaños de ventana pequeños en iPad y en Mac.

Pseudoidiomas: probar sin traducciones

La objeción habitual a todo lo anterior es que no se puede comprobar hasta tener traducciones, y es falsa. Xcode incluye pseudoidiomas, que son transformaciones sintéticas del texto de origen que se activan como idioma del esquema de ejecución sin que exista ni una sola cadena traducida.

flowchart TB
a[Texto en el idioma de desarrollo] --> b[Pseudoidioma en el esquema]
b --> c[Doble longitud: revela recortes y solapamientos]
b --> d[Derecha a izquierda: revela lados fijos]
b --> e[Acentuado: revela texto no localizado]
b --> f[Delimitado: revela truncamiento silencioso]
c --> g[Defectos de layout antes de gastar en traducir]
d --> g
e --> g
f --> g

Cada uno de esos modos responde una pregunta distinta y conviene usarlos con intención en lugar de a la vez. El de doble longitud simula el peor caso de expansión y encuentra los anchos fijos. El de derecha a izquierda invierte la interfaz y localiza todo lo que quedó anclado a un lado físico. El acentuado sustituye las letras por variantes con diacríticos, de modo que cualquier texto que siga apareciendo en inglés limpio es texto que no está pasando por el catálogo, y esa es la forma más rápida que existe de encontrar cadenas sin extraer. Y el delimitado rodea cada cadena con marcas, lo que hace visible el truncamiento incluso cuando el resultado parece una frase razonable.

Las previsualizaciones cubren el resto del ciclo, porque permiten ver varias combinaciones a la vez sin recompilar. Fijar el Locale y la dirección en el entorno de una previsualización es barato y convierte la comprobación en algo que ocurre mientras se escribe la vista, no en una fase posterior.

#Preview("Árabe, texto grande") {
    FilaTarea(tarea: .ejemplo)
        .environment(\.locale, Locale(identifier: "ar"))
        .environment(\.layoutDirection, .rightToLeft)
        .environment(\.dynamicTypeSize, .accessibility3)
}

Lo que no se ve en una captura

Quedan tres familias de detalles que sobreviven a todas las comprobaciones anteriores porque no producen un layout roto sino un resultado sutilmente pobre. La primera es tipográfica: las escrituras árabe, tailandesa, devanagari y similares tienen ascendentes y descendentes mayores que el alfabeto latino, de modo que una altura de línea ajustada al milímetro recorta los signos diacríticos. Un espaciado de línea fijado a mano en puntos, que en inglés se ve elegante, en árabe amputa la parte superior de las letras.

La segunda es la ordenación. El orden alfabético no es una propiedad universal de las cadenas: en sueco ciertas letras acentuadas van al final del alfabeto, en alemán la diéresis se ordena de dos maneras distintas según el contexto, y en varios idiomas hay dígrafos que cuentan como una sola letra. Ordenar comparando cadenas byte a byte produce listas que a un hablante nativo le parecen desordenadas. La comparación sensible a la configuración regional existe justo para eso.

La tercera es la entrada de datos. Un campo que valida un nombre con letras del alfabeto latino rechaza nombres perfectamente válidos; uno que espera un código postal numérico rechaza los del Reino Unido; uno que impone un número fijo de dígitos para un teléfono rechaza medio mundo. Cada validación estricta de formato es una decisión cultural disfrazada de comprobación técnica, y casi todas conviene relajarlas.