Los mejores lanzamientos al mercado son aquellos de los que te olvidas.
Ni ha habido líos de última hora con la traducción ni ninguna crisis… Lo único que ha habido es una nueva localización que llega a tiempo mientras el equipo ya está con otra historia.
Podríamos decir que se trata de un no evento: una localización que se lanza sin que nadie se dé cuenta. Ese es el sueño de cualquier gestor que trabaje con productos globales, y es posible que los equipos capaces de cumplirlo estén más cerca de lo que se pueda creer. Esto es como ser el portero de tu equipo o el batería del grupo: si haces bien tu trabajo, nadie se da cuenta de que estás ahí. Lo que lleva al equipo a ese punto no tiene tanto que ver con los presupuestos o las herramientas, sino con cómo se configuró la localización desde el primer momento.
La mayoría de equipos empiezan haciéndolo todo a mano: los archivos se comparten por Slack, se va persiguiendo a los traductores de las distintas zonas horarias y las entregas van saliendo porque Dios quiere. Todo funciona hasta que el producto empieza a crecer y va aumentando el número de sistemas conectados. En ese momento, este enfoque manual empieza a quedarse corto. Los siguientes pasos son lo que marca la diferencia entre este caso y el mencionado no evento, según hemos podido saber gracias a las conversaciones con cuatro personas de Phrase que trabajan con la plataforma cada día.
La escala supone un problema para los sistemas antes de suponer un problema lingüístico
Lo primero que va a haber que valorar es la unidad de medida. Los equipos tienden a aumentar la localización según el número de idiomas: cinco lenguas se pueden controlar, con quince la cosa se pone seria y, si tenemos veinticinco, todo cambia. Pero esto no ha de medirse de esta manera.
Jozsef Hodos, gestor de producto sénior del equipo de integraciones de Phrase, comenta: «Tu escala no depende de cuántos idiomas estés hablando, sino de cuántos sistemas estás gestionando».
Imagina un equipo que gestiona cinco idiomas usando media docena de sistemas: un CMS, un centro de ayuda, una base de código móvil, una herramienta de marketing y una página de documentación. Podría tener una carga superior que un equipo que lleva quince idiomas con una única integración bien configurada.
El número de idiomas trae más volumen de traducción. Los sistemas suponen un mejor mantenimiento, y el mantenimiento es lo que necesitas para ir creciendo hasta que se empiecen a establecer los objetivos.
Entonces, lo mejor es pensar en los sistemas y no en los idiomas. ¿Y cuántas personas tendrán que ponerse de acuerdo y quién recibirá la llamada si uno de estos cambia?
Construir integraciones es fácil. Mantenerlas es lo que supone un coste.
Cuando la localización manual empieza a dar problemas, el instinto te dicta que lo normal sería crear algo: un conector personalizado, una integración API de punto a punto, un script que lleve los archivos de un lugar a otro… Eso es lo razonable. Tu equipo conoce su stack, parece que estemos ante un problema específico y crear las herramientas internamente evita depender de otro proveedor más. La primera versión funciona y parece que el problema ya está resuelto. Pero el tiempo va pasando.
No es tan difícil construir este tipo de integraciones, nos explica Joszef tras haber pasado el último año encargándose de ayudar con esto a los clientes. El problema llega después: «Son sumamente difíciles de mantener». La localización conlleva ciertos requisitos que un desarrollador quizás no haya previsto, como el comportamiento del diseño en casos de escritura de derecha a izquierda, o la estructura que necesitará el contenido para seguir siendo útil dentro de una memoria de traducción. Estos casos excepcionales que quizá nunca se vieron en las pruebas acaban surgiendo durante la producción, y debido a que estas integraciones se construyen una a una, cada una de ellas tendrá sus propias peculiaridades y un mantenimiento concreto.
Los equipos de infraestructura llaman a esto mantenimiento diferido: un coste que pasa desapercibido mientras todo va bien, pero que luego aparece de la nada de la peor manera posible.
Y una visión económica más amplia refuerza esta idea también. El análisis de conectores de Nimdzi descubrió que las integraciones nativas de diez de los sistemas de gestión de traducciones más importantes tan solo llegan a menos del 13 % de las aplicaciones que suelen usar las empresas, por lo que todo lo demás es trabajo personalizado. Y en el trabajo personalizado es donde encontramos los costes ocultos. En su revisión del mercado de los SGT de 2026, Nimdzi advierte que los equipos que se están animando a crear sus propias herramientas con IA «suelen subestimar el tiempo, la complejidad y la gestión de cambios que hacen falta para crear, lanzar y mantener esas herramientas». Lo caro no suele ser la primera versión.
Dónde hay que centrarse en las integraciones nativas
La alternativa es usar integraciones nativas: conectores que una plataforma estará manteniendo por ti. Ahí te deshaces de la creación y el mantenimiento, y surge una nueva cuestión, la necesidad de configurarlas como es debido.
Y lo más correcto sería hablar de: la creación de proyectos automatizada, que detecta nuevo contenido en una plataforma conectada a través de una integración y abre automáticamente un proyecto de traducción. Si esto se hace bien, la localización se vuelve prácticamente invisible: aparece el contenido, se abre un proyecto y se obtienen las traducciones. En la práctica, Tomáš Doischer, líder del equipo de integraciones de Phrase, comenta que la mayoría de las configuraciones necesitan de un segundo vistazo para asegurarse de que todo quede bien. Hay las suficientes distinciones entre cada entorno para que ninguna plantilla consiga encajar a la perfección, por muy hábil que sea el equipo.
Existe una parte de organización a la que rara vez se presta atención. Los gestores de localización son expertos en localización, pero los sistemas a los que se conectan suelen ser propiedad de otras personas: el CMS corresponderá al equipo web, el CRM a ventas y marketing tendrá una unidad en la que guarda sus recursos. Configurar una integración requiere de unas credenciales y un acceso que rara vez podrá ofrecer un gestor de localización por sí solo, lo que acaba creando dependencias entre equipos que no trabajan juntos en su día a día.
Cualquiera que haya gestionado uno de estos proyectos sabe cómo son: quien tiene las credenciales no trabaja en localización, el que se encarga de la localización no tiene dichas credenciales y resulta que el administrador encargado de conectarlos a ambos se ha ido de vacaciones hasta el jueves. Es en eso en lo que hay que trabajar y no hay nada más útil que puedas saber antes de comenzar.
Por qué la preparación supera a la potencia técnica
Alejandro Medina, arquitecto de soluciones empresariales de Phrase, ha liderado tantos proyectos que ya sabe distinguir qué hace que vayan sobre ruedas o que sean un dolor de cabeza, y no es la potencia técnica: «El rol específico o la experiencia técnica de quien participa no son lo que determina el éxito. Lo más importante es entender el entorno del cliente y hacer las preguntas correctas».
Nos describe dos equipos con configuraciones casi idénticas. Uno de ellos integra GitHub en cuatro repositorios. Antes de configurar nada, leyeron la documentación y detectaron un problema: trabajar en ramas de pull-request cuyos nombres fueron cambiando con cada lanzamiento supondría un conflicto con la forma en que la integración rastreaba el contenido. Así que rediseñaron el flujo de trabajo primero, programando las importaciones en toda la integración y gestionando las exportaciones desde GitHub Actions. El segundo equipo, con una configuración casi idéntica, se topó con el mismo problema semanas después de su lanzamiento. Tenían la misma integración, pero su semana fue muy distinta.
Lo bueno de evaluarlo todo bien es que brinda muchas posibilidades. La integración de Figma con Phrase Strings es un buen ejemplo: cuando los diseñadores crean claves de traducción en Figma, la integración extrae capturas de pantalla y resalta automáticamente la posición de cada string. Los traductores ven la fuente en su contexto visual real, en un botón o una pantalla de configuración, sin que nadie tenga que prepararlo manualmente, y así nadie tiene que andar imaginándose qué significará \»btn_confirm_2\». El contexto viaja con el contenido.
Como dice Francesca Sorrentino, nuestra directora de localización: «Las integraciones están en la base de todo. Pero no pueden resolver todo lo que surge en un caso de uso. Los equipos que saben lo que hacen entienden para qué sirven las integraciones y van construyendo a partir de ellas».
Los equipos que mejor funcionan no son los más técnicos. Son aquellos que entienden bien su configuración antes de automatizarla, y eso garantiza un lanzamiento sin inconvenientes mucho mejor que cualquier conector.
Cuanto antes se involucren los gestores del producto, menor será el problema
Los gestores de producto suelen meterse cuando algo ya ha salido mal. Sí, en ese momento son útiles, pues seguramente sean las únicas personas capaces de ver cómo se conectan los sistemas y qué debería hacer tal o cual función. Pero para entonces ya se habrá establecido un objetivo y no se podrá aportar lo máximo posible.
Lo que cambia cuando los gestores participan desde el inicio es que ellos son los que conocen de verdad la información que mejor le viene a la localización: son ellos quienes saben qué hace la función, dónde aparece su contenido y hacía qué mercados se dirige. Esto es algo que rara vez llega a la localización de manera estructurada. Le llega un ticket a un ingeniero que creará las claves e introducirá el código. Al gestor de localización le llegarán las claves, pero se perderá el contexto con el que podía haber explicado la situación a los traductores.
Ese contexto perdido marca la diferencia entre un traductor que entiende una string y otro que intenta averiguar el contexto a partir de una clave.
Cuando Marty Cagan y Bob Baxley escribieron sobre la gestión de productos globales en el blog de Silicon Valley Product Group, comentaron este error: a menudo se habla de la localización como una entrega secundaria y no como un problema a nivel de plataforma; como algo para lo que hay que diseñar y no algo que hay que meter luego a la fuerza. Aude Moras, jefa de producto de Tablecheck, lo expresa de manera más directa: «No es buena idea prepararte para salir al mercado y luego, tan solo dos semanas antes del lanzamiento, ponerse a pensar en la localización».
La versión de Tomáš Doischer (jefe del equipo de integraciones de Phrase) llega a la misma conclusión. Explica que el fallo más común es que los equipos intenten recrear su antiguo flujo de trabajo en un sistema nuevo en lugar de preguntar para qué servía desde un inicio: «Mapear tu antiguo proceso tal cual en un nuevo sistema es como intentar usar la receta de una pizza para preparar unas hamburguesas. Hay que centrarse en el problema que resolvía el proceso que había antes. A partir de ahí, habrá que diseñar lo que haga falta para lograr ese mismo resultado».
Tal y como yo lo veo, la contribución clave de un gestor de producto es la siguiente:
Mucho antes de que surja algún problema, se debe establecer un plazo y un contexto con la suficiente antelación para que la localización esté integrada en el proceso y no para que se meta con calzador al final, pidiendo que el producto pueda llegar al mundo entero el viernes que viene.
Mira cómo funciona:
Las integraciones de Phrase muestran cómo es el ecosistema de conectores y cómo funciona con él la creación de proyectos automatizada.
