El proceso: exportar, traducir e importar en cada versión

El fallo más común de la localización no es lingüístico ni técnico: es de planificación. Un equipo internacionaliza bien, contrata traducciones, publica una versión impecable en once idiomas y, tres meses después, la mitad de las pantallas nuevas están en inglés porque nadie previó que traducir tiene un plazo de entrega y que ese plazo no cabe dentro de la última semana antes de publicar. El resultado es una app medio traducida, que comunica algo peor que una app en inglés: comunica abandono. Entender la localización como una cadena de suministro con latencia, y no como una tarea que se hace cuando toca, es lo que separa a los productos que sostienen doce idiomas durante años de los que acumulan idiomas fósiles con el porcentaje bajando en cada versión.

El intercambio: paquetes y XLIFF

Xcode exporta las localizaciones como paquetes, uno por idioma de destino, y dentro de cada uno viaja un documento XLIFF, que es el estándar de la industria para el intercambio de traducciones. Ese detalle es más importante de lo que parece porque significa que no dependes de un proveedor concreto: cualquier sistema de gestión de traducciones, cualquier agencia y cualquier herramienta de traducción asistida lee ese formato. El paquete lleva además una carpeta para capturas de pantalla y las notas asociadas a cada cadena.

El documento XLIFF empareja cada unidad de origen con su destino y arrastra las notas, que son los comentarios que escribiste en el catálogo. Lo que no viaja es el contexto que no escribiste: la jerarquía de la pantalla, el ancho disponible, el papel gramatical de la palabra. Por eso el rendimiento de este intercambio depende casi por completo del trabajo hecho antes, en el propio código.

flowchart LR
a[String Catalog en el repositorio] --> b[Exportar localizaciones]
b --> c[Paquete por idioma con XLIFF y capturas]
c --> d[Agencia o sistema de gestion de traducciones]
d --> e[Traduccion y revision por hablante nativo]
e --> f[Importar localizaciones]
f --> g[Revision de la solicitud de cambios]
g --> h[Comprobacion en dispositivo antes de publicar]

La importación fusiona por clave y respeta lo que ya existe, de modo que el ciclo es incremental por naturaleza: se exporta el conjunto completo, se traduce solo lo pendiente y se importa el resultado. La fricción aparece cuando alguien edita traducciones a mano en el catálogo mientras hay una exportación en curso, porque entonces conviven dos fuentes de verdad. La disciplina que evita el problema es tratar el catálogo como se trata un archivo generado a medias: los idiomas de destino los escribe la importación, y las correcciones puntuales entran también por ahí.

Trabajar con quien traduce

Una persona que traduce interfaces recibe una lista de frases sin aplicación, sin flujo y a menudo sin capturas, y tiene que decidir por cada una qué clase de elemento es y cuánto espacio tiene. Cualquier inversión en reducir esa incertidumbre se paga varias veces, porque un malentendido no cuesta una frase: cuesta una ronda de correcciones multiplicada por el número de idiomas.

A esos tres elementos conviene añadir una guía de estilo corta que fije las decisiones transversales: si se trata de usted o de tú, si los títulos van en mayúscula inicial o en estilo de oración, cómo se escriben los números, y qué tono tiene el producto. Son decisiones que se toman una vez y que, si no se toman, cada persona resuelve de forma distinta y el resultado es una app que cambia de voz al cambiar de pestaña.

Hay un papel que casi siempre falta y que rinde más que ningún otro: la revisión en contexto por un hablante nativo que use la app compilada, no la hoja de cálculo. Los defectos que solo aparecen ahí son de otra naturaleza —una etiqueta que no cabe, una frase correcta pero antinatural, un término que en esa región significa otra cosa— y ninguna revisión sobre el XLIFF los detecta. Media jornada por idioma y por versión mayor es un coste modesto para la clase de defecto que evita.

El calendario de una versión

Aquí es donde la mayoría de los procesos se rompen, y el motivo es aritmético. El desarrollo de una versión produce cadenas nuevas hasta el último día; la traducción tarda entre varios días y dos semanas según el volumen y el número de idiomas; y la fecha de publicación no se mueve. Si las tres cosas son ciertas a la vez, algo tiene que ceder, y lo que cede sin que nadie lo decida es la traducción.

La solución conocida es una fecha de congelación de textos anterior a la de congelación de código. A partir de ese momento las cadenas de la versión no cambian, se exporta, y el desarrollo continúa sobre lo que no afecta a los textos. Cualquier texto nuevo que aparezca después entra sabiendo que se publicará en inglés y con una tarea abierta para la siguiente versión. Lo importante de este mecanismo no es que evite textos sin traducir, que no lo hace: es que convierte una sorpresa en una decisión consciente y registrada.

// Un texto que llega tarde puede aislarse tras una bandera
if Funcionalidad.resumenSemanal.activa {
    Text("Resumen semanal")
}

Esa bandera cumple una función que se suele pasar por alto: permite publicar la versión con la funcionalidad desactivada en los mercados donde el texto todavía no existe, en lugar de mostrarla en inglés. Es la misma técnica que se usa para desplegar por fases, aplicada al eje del idioma en lugar de al del porcentaje de usuarios.

Conviene además entender la cadena de respaldo, porque determina qué ve exactamente alguien cuando falta una traducción. El sistema recorre los idiomas preferidos de la persona en orden, y si ninguno está disponible en tu paquete recae en la localización de desarrollo. Eso significa que un usuario con catalán y luego español en su lista verá tu app en español si no ofreces catalán, lo que casi siempre es el comportamiento deseable, y que un usuario con un solo idioma no cubierto la verá en el de desarrollo.

// Qué idioma está sirviendo realmente el paquete, útil en diagnósticos
let servido = Bundle.main.preferredLocalizations.first ?? "desconocido"
let disponibles = Bundle.main.localizations

Cuántos idiomas y hasta cuándo

La decisión de qué idiomas soportar se toma casi siempre con intuición y debería tomarse con dos datos. El primero es dónde están ya tus usuarios, que las herramientas de la tienda desglosan por territorio y por idioma del dispositivo. El segundo es dónde hay mercado sin barrera de entrada, que rara vez coincide con lo anterior. Añadir un idioma donde ya tienes tracción convierte usuarios existentes en usuarios que se quedan; añadir uno nuevo es una apuesta con coste de adquisición aparte.

Lo que casi nadie contabiliza es que un idioma no es un gasto único sino una suscripción. Cada versión futura tendrá cadenas nuevas que habrá que traducir a todos los idiomas activos, con su coste, su plazo y su coordinación. Doce idiomas no son doce traducciones: son doce traducciones por versión durante toda la vida del producto, y ese es el número que hay que poner sobre la mesa antes de decir que sí.

// Una prueba barata que impide que la deuda crezca en silencio
func testTodasLasClavesTienenTraduccion() throws {
    for idioma in Bundle.main.localizations where idioma != "Base" {
        let paquete = try XCTUnwrap(Bundle(path: Bundle.main.path(
            forResource: idioma, ofType: "lproj") ?? ""))
        for clave in clavesCriticas {
            let valor = paquete.localizedString(forKey: clave, value: nil, table: nil)
            XCTAssertNotEqual(valor, clave, "Falta \(clave) en \(idioma)")
        }
    }
}

Esa prueba explota una propiedad del mecanismo de búsqueda que resulta muy útil: cuando no hay traducción, el sistema devuelve la clave. Comparar el resultado con la clave detecta ausencias sin necesidad de analizar el catálogo, y ejecutarla en integración continua sobre el conjunto de cadenas críticas convierte un porcentaje que nadie mira en una condición que bloquea.

Queda la decisión más incómoda, que es retirar un idioma. Un idioma con el veinte por ciento de las cadenas traducidas no está soportado: está estropeado, y produce pantallas mezcladas que resultan peores que el inglés íntegro. Cuando la deuda supera cierto umbral, las opciones honestas son dos, invertir para recuperarlo o retirarlo, y la peor de todas es dejarlo como está. Retirar tiene además un coste que conviene anticipar: quienes lo usaban pasarán al respaldo, y eso merece un aviso en las notas de la versión.