Imagínese: tiene 7 equipos de desarrollo con un total de más de 100 personas. Al mismo tiempo vieron 13 aplicaciones. El trabajo se lleva a cabo en 20 repositorios.
Todas las aplicaciones necesitan ser traducidas. Algunos en 6 idiomas, algunos en 20. Y algunos en 13, pero este es un conjunto de idiomas completamente diferente, no está incluido en los 20 anteriores.
Todos tienen una pila diferente, como resultado de diferentes formatos de línea: js, json, ts, yaml o yml. Y algunos aún conservan sus textos en la base de datos.
Trabajas en Agile: entrega de valor diario, sprints de dos semanas. DoR incluye todas las traducciones necesarias. Bueno, por supuesto, ayer se necesitaban traducciones para tener tiempo de probar.
Hay un departamento de escritores técnicos. ¿Quién es un escritor técnico? Esta es una persona que escribe documentación externa, a veces interna. Escribe todo tipo de textos que los usuarios o socios pueden ver: textos frontales, textos de mensajes, respuestas API, errores. Acompaña el proceso de desarrollo para sumergirse en la tecnología y la lógica empresarial. Y proporciona la entrega oportuna de traducciones a la aplicación.
También existe el cargo de redactor-traductor y gerente de localización. Esta es una persona que crea todos los textos en inglés y también supervisa la coherencia de las traducciones, nombra traductores y resuelve todos los problemas relacionados.
Atención, la pregunta es: ¿cuántas especificaciones técnicas, redactores y gerentes de localización son necesarios para no obstaculizar el desarrollo y no dañar a todo el departamento técnico?
En nuestro caso, gestionamos 4 servicios técnicos y 1 gerente de localización de redactores. La entrega de transferencias en promedio se ajusta dentro de un día hábil y nunca excede los tres días hábiles. Espero que lo encuentres interesante.
¿Cómo llegamos a esto?
Hace 6 años trabajamos en hojas de Google y un DB. Es decir, si durante el proceso de desarrollo aparecieron líneas para la traducción, las copiamos en una tableta y luego las enviamos por correo a la traducción. Cuando la traducción estuvo lista, se vertió manualmente en la base de datos. La única ventaja de esta solución es que no necesita volver a colocar la aplicación para ver nuevas líneas. Pero si hay un error en las traducciones, no funcionará retroceder. Sin memoria de traducción, sin glosarios. La consistencia de las traducciones se logra mediante el método de la mirada.
Primer intento
La primera versión para automatizar este proceso se veía así: cuando un desarrollador tenía líneas, las agregaba a una nueva sucursal en un repositorio especial para traducciones. Luego, en la misma rama, se lanzó una tubería que, mediante API, envió todas las líneas de diferencias para la traducción. Es cierto que se suponía que las traducciones ya debían volver a la base de datos, pero no pudo cargar las líneas del recurso externo a la base de datos interna a través de la API.
¿Qué dio tal integración? Se eliminó un paso donde el escritor técnico necesita reunir todo en una tabla, enviarlo manualmente y luego dividir las traducciones recibidas por aplicación y por la cantidad de idiomas. En este caso, las líneas se enviaron inmediatamente para su traducción como parte de un proyecto del mismo nombre con la aplicación para la que estaban destinadas. Como resultado, el escritor técnico recibió un conjunto de archivos para cada una de las aplicaciones para las que se realizó el trabajo. Esto redujo significativamente la participación del trabajo manual. Además, la memoria de traducción se implementó en el lado del proveedor. Pero esta solución también retuvo una serie de inconvenientes: almacenar filas en la base de datos no permitía una gestión completa de las filas de nuestro lado y, como antes, implicaba una gran parte del trabajo manual.
Dolor y localización continua.
La siguiente integración trajo mucho sufrimiento a los desarrolladores. Me parece que aquellos que lo atraparon todavía tienen los ojos crispados por la palabra "localización". Esta fue la primera integración con Serge y Smartcat.
Aquí es importante decir qué son Serge y Smartcat.
Serge es una utilidad que admite git. Ella sabe cómo obtener las líneas necesarias de la rama, enviarlas para su traducción y luego devolver la traducción de las mismas líneas solo a la misma rama. También necesitamos un complemento que llame a la API del sistema CAT en el que traducimos. El complemento debería recibir nuevas líneas de Serge y devolver traducciones listas para Serge.
Smartcat es un sistema CAT con soporte para glosario, memoria de traducción, marcadores de posición. Además, Smartcat agrega y simplifica el proceso de liquidación con trabajadores independientes, admite la conexión de proveedores de traducción.
En este paso, transferimos las filas de la base de datos al repositorio del proyecto. Ahora las cadenas tenían que enviarse directamente desde el repositorio de la aplicación y devolverse allí.
Se suponía que esto funcionaría así: el desarrollador sabe de qué rama creó su rama característica, y la diferencia en los archivos de recursos entre estas dos ramas es exactamente lo que necesita ser traducido. Cuando un desarrollador tiene un conjunto de líneas para la traducción, comienza un trabajo en su rama con la configuración Serge. Serge calcula diff, extrae nuevas líneas, llama al complemento y envía las líneas para su traducción. Cuando las traducciones están listas, el desarrollador llama al siguiente trabajo: implementa la instancia de Serge creada en el paso anterior, recibe las traducciones terminadas y las confirma en la rama de origen.
La solución resultó ser inestable: Serge no estaba destinado a implementarse desde cero cada vez que se lanzaba la tubería, los desarrolladores no querían pensar en diferencias entre las ramas, y el complemento Smartcat necesitaba urgentemente una actualización y mejora. El proceso de entrega de nuevas líneas podría llevar horas. Y, por desgracia, no siempre fue exitoso.
Teóricamente, todas las etapas del proceso fueron automatizadas, de hecho, el mantenimiento, el cálculo de la diferencia antes del inicio de la tubería y la resolución de problemas tomó más tiempo que hacer la misma tarea de forma completamente manual.
Luz al final del túnel.
Para agosto de 2018, hemos lanzado la versión actual de integración. Tenemos un servidor de localización. En el servidor para cada repositorio hay una instancia separada de Serge. Serge escanea todas las ramas en el repositorio, envía nuevas líneas para la traducción y confirma las traducciones terminadas a las ramas originales. En la integración actual, todo es rápido y estable. Después de crear una rama para las traducciones, las líneas aparecen en Smartcat en 5-6 minutos. Después de confirmar las transferencias, la confirmación se produce de manera similar, dentro de los mismos 5-6 minutos. El tiempo de entrega de las traducciones está limitado solo por el factor humano: la carga de trabajo de los traductores, la diferencia en las zonas horarias, etc.
En los siguientes artículos, le diré cómo configurar la integración Serge-Smartcat-Gitlab desde cero, y cómo resolvimos varias tareas no estándar.
Continuación:
20 proyectos, 20 idiomas, fecha límite ayer. Parte 220 proyectos, 20 idiomas, fecha límite ayer. Parte 3