Traducción de aplicaciones y SaaS: cómo localizar al ritmo de los lanzamientos continuos
La traducción de aplicaciones funciona con lanzamientos semanales cuando forma parte de la cadena de entrega: las cadenas nuevas y modificadas pasan a los traductores en cuanto están estables, vuelven por el mismo repositorio, se prueban en contexto y se publican junto con el idioma original. Una única memoria de traducción y un glosario mantienen la coherencia. DEMA Solutions localiza apps, ayuda y notas de versión para equipos de software europeos.
A quién va dirigida esta guía
Esta guía está pensada para quienes se ocupan de los idiomas en una empresa de software que nunca deja de publicar: responsables de producto que prometen funciones en varios mercados a la vez, responsables de ingeniería a cargo de la compilación y de los archivos de cadenas, y responsables de localización que hacen de puente entre ambos y el proveedor de traducción. Da por sabidos los fundamentos que explicamos en nuestro artículo sobre el proceso de traducción y localización de software, como las cadenas externalizadas y los archivos de recursos, y se centra en lo que cambia cuando el producto sale cada semana o cada sprint.
Las preguntas son operativas: congelar o fluir, cómo viajan los archivos, cómo probar lo que usted no puede leer y cuánto debería costar cada versión. Si su producto es software de máquina, como un panel de operador o una interfaz de control que se entrega con el equipo, las reglas son otras, y las tratamos en la guía sobre traducción de software para HMI y máquinas.
Qué significa la localización de SaaS cuando se publica cada semana
En un proyecto tradicional, la localización empieza cuando el contenido está terminado. Un producto SaaS nunca está terminado: la interfaz cambia en pequeños incrementos, las funciones se activan primero para algunos clientes, los flujos de bienvenida se prueban en variantes y el centro de ayuda crece con cada versión.
Por eso la localización de SaaS tiene otra unidad de trabajo. No es un documento, sino un paquete de cambios: las cadenas añadidas o modificadas desde la última entrega, más los artículos de ayuda, notificaciones y notas de versión que las describen. De ahí se derivan tres consecuencias. La rapidez nace del flujo, no del esfuerzo heroico: las cadenas estables enviadas en cada sprint vuelven dentro del mismo sprint, mientras que un lote trimestral siempre llega tarde. La coherencia depende de recursos compartidos, porque quien traduce hoy quizá no tradujo el mes pasado. Y el coste por versión se convierte en la cifra clave, porque el presupuesto se gasta de forma continua.
Congelación de cadenas o flujo continuo: elegir el modelo de lanzamiento
Hay dos maneras básicas de encajar la traducción en un ciclo de lanzamientos, y la mayoría de los equipos con experiencia acaba combinándolas.
La congelación de cadenas (string freeze) fija una fecha antes de cada versión a partir de la cual ningún texto visible puede cambiar. Todo lo congelado se traduce, vuelve, se prueba y se publica. Es un modelo sencillo, previsible y fácil de presupuestar. Encaja con productos de lanzamientos mensuales o trimestrales, con contenidos cuya redacción requiere aprobación y con equipos que localizan por primera vez. Su punto débil es el hueco que crea: si la congelación es tres días antes del lanzamiento y la traducción, la revisión y las pruebas necesitan cinco, o los idiomas salen tarde o la congelación se adelanta y el desarrollo pierde margen.
La localización continua elimina la congelación como evento único. Las cadenas pasan a traducción en cuanto se marcan como listas, normalmente cuando se fusiona una rama de funcionalidad o se aprueba un pull request, y las traducciones vuelven al mismo ritmo. El día del lanzamiento, casi todo el texto ya está traducido y revisado, y solo quedan los cambios de última hora. Eso es, en la práctica, la localización ágil: la traducción avanza en paralelo al desarrollo, no detrás de él.
El flujo continuo exige más disciplina que la congelación, no menos. Las cadenas deben estar realmente estables antes de salir del repositorio; de lo contrario, la misma frase se traduce tres veces mientras se asienta la redacción. Una marca de «lista para traducir» o un breve periodo de espera tras la fusión resuelve la mayoría de los casos.
La elección depende de la frecuencia de lanzamiento, de cuánto texto cambia, de la rapidez con la que alguien de su equipo responde a las consultas y del riesgo que supone una traducción ausente. Un buen compromiso es el flujo continuo para los textos de interfaz y la ayuda, con una congelación breve para las notas de versión y los textos de la tienda de aplicaciones, que se escriben los últimos y se leen los primeros.
Conectar el repositorio con el flujo de traducción
El cuello de botella más habitual en la localización continua no es la velocidad de traducción, sino el manejo de archivos. Si un desarrollador exporta las cadenas a mano, las envía por correo, espera y copia el archivo devuelto en la carpeta correcta, cada versión pierde un día y corre el riesgo de sobrescribir algo. Lo que vale para cualquier gestión del flujo de traducción sin correos ni hojas de cálculo vale aquí todavía más: las cadenas deben viajar entre el repositorio de código y el entorno de traducción sin pasos manuales.
En el esquema más sencillo, una tarea programada exporta las cadenas nuevas y modificadas de la rama principal a una ubicación compartida, y los archivos traducidos vuelven allí para que la compilación los recoja. En una configuración más integrada, el entorno de traducción está conectado directamente al repositorio: detecta cambios en los archivos del idioma original, crea las tareas de traducción y, cuando un idioma está completo, abre un pull request que sus desarrolladores revisan y fusionan como cualquier otro cambio.
Sea cual sea el esquema, tres reglas lo hacen seguro. Los archivos de destino solo debe escribirlos el flujo de traducción, para que las ediciones manuales no desaparezcan en la siguiente sincronización. Las claves deben ser estables, porque una clave renombrada parece una cadena eliminada más otra nueva, y la traducción existente se pierde. Y la estrategia de ramas debe acordarse de antemano: traducir cada rama de funcionalidad malgasta esfuerzo en funciones que nunca salen, mientras que traducir solo la rama de lanzamiento deja muy poco tiempo, así que muchos equipos traducen desde la rama principal tras la fusión.
Pregunte a su proveedor exactamente cómo le llegan los archivos y cómo vuelven. Un tratamiento nativo de JSON, XML y archivos de cadenas de cada plataforma, devueltos sin claves rotas ni cambios de codificación, elimina toda una categoría de errores de compilación.
Memoria de traducción y glosario a lo largo de las versiones
Un producto con cincuenta versiones al año genera cincuenta pequeñas entregas de traducción. Sin una única memoria de traducción detrás, el producto va acumulando tres traducciones de «workspace», dos formas de dirigirse al usuario y verbos distintos en los botones.
La memoria de traducción es lo que hace que la localización continua sea rentable y coherente. Cada traducción aprobada se guarda con su texto original; cuando una cadena reaparece, igual o ligeramente modificada, se reutiliza la redacción aprobada y solo se traduce la diferencia. La memoria debe ser suya, no del proveedor, y poder exportarse en cualquier momento en un formato portátil. Por eso el valor estratégico de la memoria de traducción pesa más en un producto SaaS que en casi cualquier otro contenido.
El glosario hace lo mismo con los términos. Un producto SaaS tiene un vocabulario reducido y muy usado: nombres de funciones, nombres de planes, tipos de objeto, acciones. Cada término necesita una traducción aprobada por idioma y una decisión sobre qué nombres se quedan en inglés. Marketing de producto suele renombrar funciones, de modo que el glosario necesita un responsable que lo actualice antes de que salgan las nuevas cadenas. Nuestro artículo sobre la gestión terminológica centralizada entre traductores y proveedores explica cómo crear y mantener ese glosario.
Las decisiones de estilo van justo al lado. ¿Trata usted a sus usuarios de tú o de usted? ¿Los botones son verbos o sustantivos? ¿Cómo se redactan los mensajes de error? En español, además, conviene decidir si la interfaz se dirige a España, a Latinoamérica o a ambos mercados con una variante neutra. Una breve guía de estilo para la traducción por idioma responde a estas preguntas una sola vez para todos los traductores y revisores.
Contexto, revisión en contexto y pruebas de localización
Los textos de interfaz son cortos y ambiguos. «Archive» puede ser verbo o sustantivo, y «Free» puede referirse al precio o a la disponibilidad. En la localización continua el riesgo aumenta, porque el traductor ve un puñado de cadenas por paquete y no el producto entero. Con cada paquete de cambios debería viajar el contexto: un comentario en cada clave ambigua, una nota sobre qué contiene cada marcador de posición, la longitud máxima donde el espacio es fijo y, si es posible, una captura de pantalla o un enlace al entorno de pruebas.
Las pruebas de localización convierten traducciones correctas en un producto correcto. Tienen dos partes. Las comprobaciones funcionales confirman que la compilación localizada funciona: nada de texto en inglés codificado de forma fija, etiquetas cortadas, marcadores de posición rotos, formatos de fecha, número o moneda incorrectos ni caracteres que no se muestran. Muchas de ellas pueden automatizarse y ejecutarse en cada compilación. La prueba lingüística, o revisión en contexto, la hace una persona que lee el idioma: recorre los principales itinerarios del usuario en el entorno de pruebas y comprueba que cada traducción encaja en su contexto, que la terminología es la misma de una pantalla a otra y que nada suena a fragmento.
No hace falta una prueba lingüística completa de cada idioma cada semana. Un ritmo práctico combina comprobaciones automáticas en cada compilación, revisión en contexto de las funciones nuevas y un recorrido completo en las versiones importantes o al lanzar un idioma nuevo. Cada corrección debe volver a la memoria de traducción, no solo a la compilación, o el error reaparecerá en la siguiente sincronización. Nuestra guía sobre el control de calidad de la traducción explica cómo plantear una revisión que genere observaciones útiles y no preferencias personales.
Interfaces móviles: longitud, plurales, género y escritura de derecha a izquierda
La localización de aplicaciones móviles añade limitaciones que una interfaz web suele absorber: poco espacio en pantalla, etiquetas en la barra de navegación y tamaños de texto dinámicos.
Longitud. El texto traducido suele ser más largo que el inglés, y las cadenas cortas son las que más crecen en proporción: un botón de dos palabras puede duplicar su longitud en español o en alemán. Fije límites de caracteres para las cadenas en espacios fijos, pruebe pronto con el idioma más largo y permita que el traductor proponga una redacción más breve en lugar de imponer una abreviatura que nadie entiende.
Plurales. El inglés necesita dos formas («1 file», «2 files»). Muchos idiomas necesitan más: el polaco distingue entre uno, pocos y muchos, y el árabe usa hasta seis categorías. Las dos grandes plataformas móviles y los formatos de mensaje habituales admiten categorías de plural, pero solo si el desarrollo las utiliza en lugar de concatenar un número y una palabra.
Género y concordancia. En español, como en las demás lenguas romances, en las eslavas y en alemán, adjetivos, participios y a veces verbos concuerdan con el género del sustantivo o de la persona. Una cadena como «{name} has been invited» necesita «invitado» o «invitada» según quién sea. Donde el producto conoce el género o el tipo de objeto, las cadenas separadas o los formatos de selección permiten frases correctas; donde no lo conoce, el traductor debe saberlo para buscar una formulación neutra.
Escritura de derecha a izquierda. El árabe y el hebreo invierten la interfaz: la navegación, los iconos con dirección y los indicadores de progreso se reflejan, mientras que los números y el texto latino incrustado siguen yendo de izquierda a derecha. El soporte de derecha a izquierda es una tarea de ingeniería que debe probarse en dispositivos reales antes de poder juzgar la traducción. Si además de la aplicación hay que traducir el sitio web, los factores que determinan el coste de traducción de una web son en gran parte los mismos.
Fichas de la tienda, notas de versión y centro de ayuda
La interfaz es solo una parte de lo que leen los usuarios. En una app móvil, la ficha de la tienda es el primer texto localizado que ve el cliente: título, subtítulo, descripciones corta y larga, palabras clave y textos de las capturas. Cada tienda fija sus propios límites de caracteres, y la ficha es texto comercial, no de interfaz. En la traducción de apps conviene confiarla a un traductor que escriba de forma persuasiva dentro de esos límites y compruebe cómo buscan los usuarios de cada mercado aplicaciones como la suya. Los textos de las capturas se olvidan con facilidad, porque están en archivos de imagen y no en archivos de cadenas.
Las notas de versión se escriben a última hora y las leen sus usuarios más activos. Deles una ventana de traducción breve y fija y reutilice la terminología de la interfaz, para que la función que mencionan las notas sea la misma que el usuario encuentra en la app.
El centro de ayuda suele crecer más deprisa que la interfaz. Sus artículos son largos, repetitivos y se actualizan a menudo, lo que los convierte en buenos candidatos para la traducción automática con posedición a cargo de un lingüista cualificado, siempre que el motor trabaje con su glosario y su memoria aprobados. En nuestra página de traducción automática con posedición explicamos cómo decidimos según el tipo de contenido. Los textos de interfaz son otro caso: cortos, ambiguos y visibles en cada pantalla, por lo que en general necesitan un traductor humano desde el principio. Su sitio web corporativo sigue a su vez una lógica distinta, con sus propios criterios de coste y de posicionamiento.
Medir la reutilización y el coste por versión
En la localización continua, la tarifa por palabra explica menos del presupuesto que la composición de cada versión. Cada paquete de cambios contiene texto realmente nuevo, texto parecido a algo ya traducido y texto idéntico a una traducción aprobada, por ejemplo una cadena que se ha trasladado a otra pantalla. La proporción de texto reutilizado se llama aprovechamiento (leverage) y es la cifra más útil para entender el coste.
Un ejemplo ilustrativo: un sprint modifica 1500 palabras de interfaz y ayuda. De ellas, 700 son nuevas, 500 son coincidencias parciales con traducciones existentes y 300 son repeticiones exactas. En seis idiomas son 4200 palabras nuevas que traducir, 3000 que adaptar y 1800 que verificar, en lugar de 9000 palabras traducidas desde cero. Si el proveedor detalla este reparto en cada entrega, usted ve por qué un sprint costó más que otro y detecta problemas a tiempo: una caída brusca del aprovechamiento suele indicar que se renombraron claves o se reestructuraron archivos, y que la memoria ya no reconoce texto que contiene.
Otros tres factores mueven el coste por versión. El tamaño del paquete: cada entrega conlleva un esfuerzo fijo de gestión de archivos y comprobaciones, así que enviar cadenas sueltas sale caro. La rotación: el texto que se reescribe después de traducirlo se paga dos veces. El alcance de las pruebas: la revisión en contexto debe planificarse en cada versión, no descubrirse tras una queja. Al cabo de unos meses, los informes por versión dan a producto una base fiable para presupuestar nuevos idiomas y funciones.
El proceso de localización de apps en un sprint, paso a paso
Así suele desarrollarse la localización de apps en un sprint de dos semanas, una vez que la base está montada.
Al inicio del sprint, producto y diseño acuerdan qué funciones salen y en qué mercados. Los términos nuevos, como el nombre de una función, se añaden al glosario con sus traducciones antes de escribir ninguna cadena.
Durante el desarrollo, los desarrolladores crean las claves con comentarios y límites de caracteres. Cuando se fusiona una rama de funcionalidad, las cadenas nuevas y modificadas se recogen automáticamente y empieza la traducción. Las consultas de los traductores llegan a una persona concreta de su equipo, que responde en el día.
A mitad del sprint, las traducciones vuelven por el repositorio, como pull request o como archivos en la ubicación acordada. Se ejecutan comprobaciones automáticas sobre la compilación: marcadores de posición, longitud, codificación y traducciones ausentes.
Antes del lanzamiento, un revisor recorre las funciones nuevas en cada idioma en el entorno de pruebas. Las notas de versión, los textos de la tienda y los artículos de ayuda se traducen en una ventana breve y fija. Las correcciones se hacen en el entorno de traducción para que queden en la memoria.
Después del lanzamiento, el proveedor informa del aprovechamiento por idioma, y los problemas recurrentes, como la falta de contexto, se corrigen para el siguiente sprint.
Errores habituales en la localización continua
Editar los archivos de destino a mano. Un desarrollador corrige una errata directamente en el archivo en español; la siguiente sincronización la sobrescribe, o la corrección nunca llega a la memoria y el error vuelve en la siguiente versión.
Renombrar claves al refactorizar. Para un sistema de traducción, una clave renombrada es una cadena nueva. El aprovechamiento cae, se rehacen traducciones y la redacción aprobada cambia sin que nadie lo haya decidido.
Dejar que cada equipo o proveedor tenga su propia memoria. Si la app, el centro de ayuda y la web se traducen por separado, la terminología se dispersa, y cambiar de proveedor más adelante supone perder años de traducciones aprobadas. Si sus traducciones anteriores solo existen como archivos sueltos, la alineación de memorias de traducción permite recuperarlas y reutilizarlas desde la primera entrega.
Cómo elegir un proveedor para la traducción de aplicaciones
El proveedor adecuado para un ciclo de lanzamientos continuo es aquel cuya forma de trabajar encaja con su cadena de entrega, no simplemente el más barato por palabra. Estas preguntas revelan casi todo lo que necesita saber:
- ¿Cómo le llegan los archivos y cómo vuelven, y puede tratar nuestros formatos de recursos de forma nativa sin romper claves ni marcadores de posición?
- ¿Qué plazo puede comprometer para un paquete típico de sprint, y cómo gestiona las cadenas urgentes?
- ¿Qué comprobaciones automáticas se ejecutan antes de la entrega, y revisa cada traducción un segundo lingüista cualificado?
- ¿Pueden nuestros desarrolladores o responsables de producto revisar las traducciones en contexto, y sus correcciones actualizan la memoria?
- ¿A quién pertenecen la memoria de traducción y el glosario, y podemos exportarlos en cualquier momento en un formato estándar?
- ¿Informa por versión e idioma del texto nuevo, las coincidencias parciales y el texto reutilizado?
Las respuestas pesan más que cualquier certificado en una web, aunque un proceso certificado según la ISO 17100 indica que la revisión por un segundo lingüista es la norma y no un extra opcional.
Cómo apoya DEMA Solutions a los equipos de SaaS y apps
Nuestras soluciones lingüísticas para el sector tecnológico están pensadas para equipos de producto que publican de forma continua. Las cadenas nuevas y modificadas se recogen y traducen en cada versión, al ritmo de sus sprints, en lugar de agruparse en grandes proyectos ocasionales. Los archivos JSON, XML y otros archivos de recursos se procesan y se devuelven con su estructura original, sin extracción manual y sin claves rotas. Las comprobaciones automáticas detectan variables rotas, cadenas de interfaz cortadas y errores de formato antes de que lleguen a una compilación de lanzamiento.
Nuestros traductores son lingüistas técnicos nativos que trabajan con terminología de software y de desarrollo. Sus ingenieros y responsables de producto pueden revisar directamente en el entorno de traducción, sin hojas de cálculo exportadas, de modo que las correcciones terminológicas llegan a la memoria de inmediato. El proceso está certificado según la ISO 17100, con un segundo lingüista cualificado que revisa cada traducción, como se describe en nuestra página de calidad de traducción.
La memoria de traducción, los glosarios y las bases terminológicas se construyen con la terminología de su producto y siguen siendo suyos, exportables a petición en cualquier momento en formatos portátiles como TMX y TBX. Los informes de aprovechamiento muestran cuánto de cada versión se ha reutilizado. Más allá de la interfaz, nuestros equipos en Italia, Serbia y España traducen centros de ayuda y bases de conocimiento, documentación de API y para desarrolladores, notas de versión y registros de cambios, para que el producto y todo lo que lo rodea compartan una misma terminología.
Dónde encaja TUBE
TUBE es nuestra solución para productos con lanzamientos continuos, en los que cada sprint supone un nuevo ciclo de localización. Su glosario y su memoria de traducción controlan la traducción automática, cada traducción aprobada se incorpora a una memoria que es suya y que puede exportar, y los informes de aprovechamiento muestran qué parte de cada actualización procede de texto que usted ya ha aprobado.
Preguntas frecuentes
Es la adaptación de una aplicación móvil o web a usuarios de otros idiomas y mercados: interfaz, bienvenida, notificaciones, centro de ayuda, notas de versión y ficha de la tienda. Además de la traducción, incluye formatos, plurales, longitud del texto y pruebas en contexto, por lo que suele hablarse también de localización de apps.
Consiste en enviar a traducción las cadenas nuevas y modificadas en cuanto están estables, en lugar de acumularlas hasta una congelación de cadenas antes de cada versión. Las traducciones vuelven al mismo ritmo, de modo que cada idioma puede publicarse junto con el original.
No necesariamente para todo el producto. Muchos equipos dejan fluir de forma continua la interfaz y la ayuda y mantienen una congelación breve para los textos más visibles o de última hora, como las notas de versión, las páginas de precios y las fichas de la tienda.
Las comprobaciones funcionales confirman que la compilación localizada funciona: sin texto codificado de forma fija, cortes, marcadores de posición rotos ni formatos erróneos. La prueba lingüística comprueba en pantallas reales que cada traducción encaja en su contexto y que la terminología es coherente.
Con una sola memoria de traducción y un solo glosario para todo el contenido del producto, un glosario que se actualiza antes de que aparezcan términos nuevos, correcciones hechas en el entorno de traducción y no en los archivos de destino, y claves de cadena estables.
Mejor por versión que por año, a partir del volumen de texto nuevo, coincidencias parciales y texto reutilizado en cada idioma. Los informes de aprovechamiento de versiones anteriores son la base más fiable para estimar el coste de nuevas funciones e idiomas.
Suele funcionar bien para los artículos de ayuda y la documentación, si trabaja con su glosario y su memoria aprobados y un lingüista cualificado posedita el resultado. Las cadenas cortas de interfaz y las fichas de la tienda suelen necesitar un traductor humano desde el principio.
Una localización que siga el ritmo de sus versiones
Si sus idiomas salen más tarde que el original, o cada versión trae una nueva ronda de incoherencias, cuéntenos cómo es su producto, su ritmo de lanzamientos y sus idiomas de destino. Revisaremos sus archivos de recursos y le propondremos un flujo de localización que encaje en sus sprints.
¿Cómo podemos ayudarle?
Cuéntenos qué necesita y le responderemos con las soluciones adecuadas.