Los mejores lanzamientos al mercado son aquellos de los que olvidas que sucedieron.
Sin prisas de traducción de última hora y sin sala de crisis… solo una nueva localización que se pone en marcha más o menos a tiempo mientras el equipo sigue con lo siguiente.
Llámelo el no-evento: una localización que se lanza sin que nadie note que lo hizo. Para los gerentes de producto que gestionan productos globales, esa es la ambición, y los equipos que la alcanzan suelen estar más cerca de lo que suponen. Es un poco como ser portero o baterista: cuando lo haces bien, nadie te nota. Pero lo que los lleva allí tiene menos que ver con el presupuesto o las herramientas que con la forma en que se configuró la localización desde el principio.
La mayoría de los equipos comienzan haciéndolo manualmente: archivos compartidos a través de Slack, traductores perseguidos a través de zonas horarias o transferencias que se sostienen gracias a la buena voluntad. Funciona hasta que el producto crece y el número de sistemas conectados aumenta, momento en el cual el enfoque manual comienza a quedarse atrás. Lo que sigue traza la brecha entre eso y el no-evento, extraído de conversaciones con cuatro personas en Phrase que trabajan en ello todos los días.
La escala es un problema de sistemas antes que un problema de idioma
Lo primero que vale la pena replantearse es la unidad de medida. Los equipos tienden a evaluar la localización por el número de idiomas: cinco parece manejable, quince algo serio, veinticinco una operación diferente. Es la medida incorrecta.
Como dice Jozsef Hodos, un gerente de producto senior en el equipo de integración de Phrase: «La escala no es cuántos idiomas soportas. Es cuántos sistemas gestionas.»
Imagina a un equipo gestionando cinco idiomas en media docena de sistemas: un CMS, un centro de ayuda, una base de código móvil, una herramienta de marketing y un sitio de documentación. Puede estar soportando más carga que un equipo que gestiona quince idiomas a través de una integración bien configurada.
Los idiomas impulsan el volumen de traducción. Los sistemas impulsan el mantenimiento, y el mantenimiento es el costo que se acumula hasta que comienza a marcar la agenda.
Así que la mejor pregunta es sobre los sistemas, no sobre los idiomas: ¿cuántos necesitan comunicarse entre sí, y quién recibe la llamada cuando uno de ellos cambia?
Construir integraciones es fácil. Mantenerlas es el costo.
Cuando la localización manual comienza a molestar, el instinto es construir algo: un conector personalizado, una integración de API punto a punto, un script que mueve archivos de un lugar a otro. Es razonable. El Team conoce su stack, el problema parece específico y construir internamente evita otra dependencia de proveedor. La primera versión funciona y el problema parece resuelto. Luego pasa el tiempo.
Las integraciones como estas no son difíciles de construir, dice Jozsef, tras haber pasado el último año trabajando exactamente en esto con clientes. El problema viene después: «son sumamente difíciles de mantener». La localización conlleva requisitos que un desarrollador quizás no prevea, como el comportamiento del diseño en escrituras de derecha a izquierda, o cómo el contenido necesita estructurarse para seguir siendo útil en una memoria de traducción. Los casos excepcionales que nunca aparecieron en las pruebas surgen en producción, y debido a que estas integraciones se construyen una a una, cada una conlleva sus propias peculiaridades y su propio mantenimiento.
Los equipos de infraestructura llaman a esto mantenimiento diferido: un costo que pasa desapercibido mientras todo funciona, pero que luego aparece de una forma peor.
La economía más amplia lo refuerza. El análisis de conectores de Nimdzi encontró que las integraciones nativas en diez de las principales plataformas SGT alcanzan menos del 13% de las aplicaciones empresariales que las empresas suelen usar, lo que deja el resto al trabajo personalizado. Y el trabajo personalizado es donde se esconde el costo. En su revisión del mercado de SGT de 2026, Nimdzi advierte que los equipos ahora tentados a construir sus propias herramientas con IA «a menudo subestiman el cronograma, la complejidad y la gestión del cambio para la creación, el lanzamiento y el mantenimiento de tales herramientas». La primera versión rara vez es la parte costosa.
Donde las integraciones nativas aún necesitan trabajo real
La alternativa es usar integraciones nativas: conectores que una plataforma mantiene para ti. Eso elimina la construcción y el mantenimiento, y plantea una pregunta diferente: configurarlos bien.
Aún más correcto sería: Toma la Creación automatizada de proyectos, que detecta nuevo contenido en una plataforma conectada a través de una integración y abre automáticamente un proyecto de traducción. Bien hecho, es lo que hace que la localización sea casi invisible: el contenido aparece, un proyecto se abre, las traducciones regresan. En la práctica, Tomáš Doischer, líder del equipo de integraciones de Phrase, dice que la mayoría de las configuraciones necesitan una segunda pasada para quedar bien. Cada entorno es lo suficientemente diferente como para que ninguna plantilla encaje perfectamente, por muy hábil que sea el equipo.
Existe una dimensión organizativa que rara vez recibe suficiente 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 por el equipo web, el CRM por ventas, y el drive donde marketing guarda sus activos. Configurar una integración requiere credenciales y acceso que un gestor de localización a menudo no puede conceder por sí solo, lo que crea dependencias entre equipos que no trabajan juntos en el día a día.
Cualquiera que haya ejecutado uno de estos proyectos conoce la situación: la persona con las credenciales no trabaja en localización, la persona que se dedica a la localización no tiene las credenciales, y el administrador que podría conectar a ambos está de vacaciones hasta el jueves. Ahí es donde reside el verdadero trabajo, y es lo más útil que se debe saber antes de empezar.
Por qué la preparación supera a la potencia técnica
Alejandro Medina, arquitecto de soluciones Enterprise en Phrase, ha ejecutado suficientes de estos proyectos para saber qué diferencia a los proyectos sin problemas de los dolorosos, y no es la potencia técnica: «El rol específico o los antecedentes técnicos de quien participa no determinan el éxito. Lo que más importa es entender el entorno del cliente y hacer las preguntas correctas.»
Él describe dos equipos con configuraciones casi idénticas. Uno estaba integrando GitHub en cuatro repositorios. Antes de configurar nada, leyeron la documentación y detectaron un problema: trabajar en ramas de pull-request cuyos nombres cambiaban en cada lanzamiento entraría en conflicto con la forma en que la integración rastreaba el contenido. Así que rediseñaron el flujo de trabajo primero, programando las importaciones a través de la integración y gestionando las exportaciones a través de GitHub Actions. El segundo equipo, con casi la misma configuración, tuvo el mismo problema semanas después de entrar en funcionamiento. La misma integración, una semana muy diferente.
La otra cara de un buen alcance es lo que hace posible. La integración de Figma de Phrase 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 cadena. Los traductores ven la fuente en su contexto visual real, un botón o una pantalla de configuración, sin que nadie lo prepare manualmente, y nadie tiene que adivinar qué significa \»btn_confirm_2\». El contexto viaja con el contenido.
Como dice Francesca Sorrentino, nuestra Directora de Localización: «Las integraciones son la capa fundamental.» Pero no resuelven todos los problemas en un caso de uso completo. Los equipos que hacen esto bien entienden para qué sirve la integración y construyen en torno a ella en consecuencia.\»
Los equipos que tienen éxito no son los más técnicos. Son los que entienden su propia configuración antes de automatizarla, y eso, más que cualquier conector, es lo que mantiene un lanzamiento tranquilo.
Cuanto antes se involucren los gerentes de producto, menor será el problema
Los gerentes de producto suelen llegar una vez que algo ha salido mal. Son útiles entonces, a menudo la única persona que puede ver cómo se conectan los sistemas y qué se supone que debe hacer realmente la función. Pero para entonces el alcance ya está definido y la mejor contribución ha pasado.
Lo que cambia cuando se involucran antes es que la información que más necesita la localización reside con ellos: qué hace la función, dónde aparece su contenido y qué mercados están incluidos. Eso rara vez llega a la localización de forma estructurada. Un ingeniero toma un ticket, crea las claves y envía el código. El gerente de localización recibe las claves, y el contexto que les permitiría informar a los traductores antes de que llegue el trabajo ha desaparecido.
Ese contexto faltante es la diferencia entre un traductor que sabe lo que significa una cadena y uno que adivina a partir del nombre de una clave.
Marty Cagan y Bob Baxley, escribiendo sobre gestión global de productos en el blog de Silicon Valley Product Group, nombran el error: la localización se trata como una entrega posterior en lugar de una preocupación de la plataforma, algo para lo cual diseñar en lugar de añadir. Aude Moras, jefa de producto en Tablecheck, lo expresa de manera más directa: «No quieres prepararte para el mercado y luego, dos semanas antes del lanzamiento, empezar a pensar en la localización.»
La versión de Tomáš Doischer (líder de equipo, Integraciones en Phrase) llega al mismo punto. Él dice que el fallo que ve con más frecuencia es que los equipos recrean su antiguo flujo de trabajo en un nuevo sistema en lugar de preguntar para qué servía: «Mapear tu antiguo proceso uno a uno a un nuevo sistema es como intentar aplicar tu receta para hacer pizza a la elaboración de hamburguesas.» Concéntrate en qué problema estaba resolviendo el proceso existente. Luego diseña para ese resultado.»
En mi opinión, esta es la contribución clave del gerente de producto:
Mucho antes de que algo se incendie, ellos traen el tiempo y el contexto del producto a la sala lo suficientemente temprano para que la localización se incorpore, en lugar de añadirla al final con una solicitud de hacerla global para el viernes.
Míralo en la práctica:
Las integraciones de Phrase muestran el ecosistema de conectores y cómo funciona la creación automatizada de proyectos en él.
