Localización continua: qué es y cómo funciona

La localización continua es la práctica de traducir y revisar contenido a la par que se desarrolla, en lugar de tratarlo como una fase aparte después de que el código se haya publicado. Se vincula la traducción directamente a los flujos de trabajo Agile y de CI/CD, y así las nuevas funciones llegan a todos los mercados y a todos los idiomas al mismo tiempo, sin tener que pedir una entrega aparte a un equipo de traducción.

El desarrollo Agile se basa en una iteración rápida y continua. Pero la mayoría de procesos de traducción siguen planteándose en forma de cascada: termina el desarrollo, se empaqueta un lote de strings y se envía a traducción. La localización continua se deshace de estos desajustes.

Esta guía detalla qué es realmente la localización continua, por qué los flujos de trabajo de traducción tradicionales palidecen ante el desarrollo Agile, cómo funciona la localización continua en la práctica y cómo implementarla.

¿Por qué la traducción tradicional no funciona con el desarrollo Agile?

En un modelo en cascada, cada etapa de un proyecto tiene que terminar antes de que comience la siguiente. La traducción suele ser una de esas etapas que, además, va al final.

Eso crea dos problemas. Primero, cualquier retraso en la traducción retrasa todo el lanzamiento, ya que nada se puede publicar hasta que estén listos todos los idiomas. Segundo, solucionar un problema que se haya encontrado tarde, ya sea una mala traducción, una string que no encaje en la interfaz de usuario o un fallo por falta de contexto, implica tener que reabrir una etapa ya «terminada», lo cual siempre es lento y disruptivo por diseño.

Algunos proveedores de traducción se definen como «agile» también, pero no cambian sus flujos de trabajo de siempre: las strings siguen empaquetándose en kits al final de cada fase y se mandan a un equipo aparte. El resultado provoca esa misma desconexión, por mucho que hayan cambiado el nombre al proceso. Los gestores de localización acaban siendo el punto de negociación entre los desarrolladores y traductores que trabajan en diferentes partes del producto en momentos distintos, lo que añade una carga extra de coordinación para cada lanzamiento.

¿Cómo ha cambiado el desarrollo Agile la localización?

El desarrollo Agile funciona en ciclos pequeños e iterativos en lugar de en una compilación secuencial larga. Si aplicamos esto a la localización, eso significa que la traducción se hace en el mismo ciclo que el desarrollo, no después.

En lugar de una gran entrega de traducción al final de un proyecto, el contenido va llegando a los traductores de forma continua, en los mismos lotes pequeños que los desarrolladores van entregando. El equipo de localización está integrado en estos ciclos en lugar de tener que esperar una transferencia.

Este cambio permite a los equipos obtener unos resultados más rápidos y permite detectar y solucionar los problemas desde el principio. Sin embargo, esto significa que el proceso de localización en sí, las herramientas, los flujos de trabajo y la estructura del equipo deberán reconstruirse para poder adaptarse a un flujo continuo en lugar de a los lotes periódicos.

Cómo funciona la localización continua

Las entregas continuas suponen mantener un producto listo para su lanzamiento en cualquier momento, y es el modelo en el que se inspira la localización continua. Los desarrolladores no quieren tener que esperar varios días a que los de QA, localización y testeo acaben antes de poder lanzar su producto; quieren publicarlo en cuanto se haya hecho un cambio.

Para los equipos de localización, eso significa gestionar un flujo continuo de contenido en lugar de grandes lotes periódicos. En la práctica, esto suele ejecutarse con unos activadores automatizados: cuando un desarrollador agrega o cambia una string de un repositorio de código fuente, se detecta automáticamente y se envía para su traducción, sin que nadie tenga que solicitar que se «congelen las strings» para que a los traductores les dé tiempo a trabajar.

En este punto, las herramientas son clave. Una función de gestión de traducción, que se conecta directamente a la base de código, y una función de control, con la que activar los flujos de trabajo de traducción automáticamente desde un webhook o evento de API, son lo que hacen que lo «continuo» sea realmente continuo y no «frecuente». Phrase Strings está diseñado específicamente para esto: se sincroniza con tus repositorios de código fuente a través de una API o CLI, así los cambios de las strings van fluyendo a la traducción a medida que van surgiendo y las cadenas traducidas fluyen de regreso a tu repositorio de esa misma manera. Consulta la documentación sobre las API y los desarrolladores para saber cómo funciona la integración.

El objetivo del equipo de desarrollo es percibir la menor fricción posible: ellos seguirán publicando y la localización irá manteniendo el ritmo en segundo plano, haciendo llegar únicamente los comentarios que realmente necesiten de la atención de un desarrollador.

Beneficios de la localización continua

Incorporar la localización dentro del ciclo de desarrollo, y no después de este, cambia la forma en que los traductores y desarrolladores trabajan juntos. Los traductores dejan de ser receptores pasivos de kits de localización y comienzan a trabajar junto a las personas que crean el producto.

Ciclos de lanzamiento más cortos

La localización ya no es un paso crítico que está en una etapa aparte, así que se reduce el tiempo en que los productos llegan al mercado. Pega redujo los tiempos de entrega de sus traducciones en hasta un 75 %, logrando que el contenido de marketing que solía retrasar los lanzamientos en inglés hasta cuatro semanas tardase en estar listo solo una semana, y todo sin aumentar la plantilla. Una empresa global de SaaS fue más allá: después de automatizar la traducción de su contenido web, los ciclos de lanzamiento pasaron de tardar semanas a estar listos ese mismo día en varios idiomas, reduciendo a cero los costes de los proveedores externos.

Mejor calidad

Los traductores que trabajan con el contexto real del producto, y no con una lista de strings inconexas, producen menos errores y tienen menos dudas. Los problemas surgen cuando el desarrollador aún sigue trabajando con la base de código, no semanas más tarde.

Lanzamientos globales simultáneos

Eliminar los retrasos entre el desarrollo y la localización implica que una función puede llegar a todos los mercados a la vez, en lugar de tener que ir lanzándose de manera escalonada durante las semanas o meses siguientes.

¿Cómo se implementa la localización continua?

El paso a la localización continua supone un cambio de proceso y no solo un cambio de herramientas. Hay algunas prácticas que hacen que la transición resulte más fluida:

1. Prepara a tu equipo para trabajar de forma diferente.

Prepara a tu equipo para que reciba el cambio con los brazos abiertos y no trate de evitarlo. Cuanto más se resiste alguien a la inevitabilidad del cambio, más le afectará cuando llegue.

2. Ten bien identificado tu flujo de trabajo actual antes de cambiarlo.

Considera la localización un flujo de contenido y ubica aquellos puntos en los que se estanque actualmente. Si el proceso parece demasiado grande para abordarlo de golpe, comienza por ese paso que produzca una menor fricción y ve avanzando desde ahí.

3. Automatiza las entregas

Agrupar strings en lotes manualmente, enviar archivos por correo electrónico y volver a integrar el contenido traducido en la base de código es justo lo que la localización continua pretende ahorrarte. Vincula tu sistema de gestión de traducciones directamente al rastreador de problemas que tengas (por ejemplo, mediante API a una herramienta como Jira) para que el contenido y las consultas puedan avanzar sin necesidad de intervención manual.

4. Ten un equipo de traducción estable y dedicado.

Los traductores que trabajan con un mismo producto durante mucho tiempo acaban desarrollando un conocimiento del producto y una coherencia que un grupo que va rotando jamás podrá obtener. Además, los desarrolladores también empiezan a confiar en los comentarios de aquellos traductores que consideren que conocen bien el producto y que no son otro nombre más en un ticket.

5. Da contexto a los traductores, no solo strings

Una captura de pantalla, un vídeo corto o un ticket vinculado hará que una string ambigua se traduzca de forma rápida y precisa. La falta de contexto es una de las fuentes más comunes de errores de traducción que requieran de cambios.

6. Considéralo algo continuo, no una migración única

Espera tener que iterar con este flujo de trabajo después del lanzamiento inicial. La metodología Agile es un prerrequisito para que la localización continua funcione: si el desarrollo en sí no es iterativo, los beneficios de hacer que la localización sí lo sea serán limitados.

¿La localización continua es ideal para todos los equipos?

Si tu producto va a llegar a un público mundial a buen ritmo, sí: un flujo de trabajo de traducción que todavía funciona con una cascada de suposiciones seguirá dándote problemas siempre, lanzamiento tras lanzamiento. La localización continua unifica el ritmo de la traducción y el desarrollo, por lo que tu proyecto dejará de estar fragmentado y este proceso formará parte de la propia entrega del producto.

Preguntas frecuentes sobre la localización continua