Localización de software grande y ágil: caso práctico de Kaspersky

Dirigir los esfuerzos de localización de una gran empresa de software es un reto en sí mismo. ¿Qué ocurre cuando esta empresa cambia a prácticas ágiles? Pues bien, los retos se vuelven aún más difíciles y hay que implementar cambios drásticos con rapidez. En este caso práctico, Ekaterina Galitskaya y Darya Egorushkina del equipo de documentación y localización de Kaspersky se sumergen en su viaje para mejorar la capacidad y la eficiencia de sus procesos con Smartcat.

Texto adicional de Ekaterina y Darya

Nuestro equipo se encarga de redactar y localizar tanto los textos de la interfaz de usuario como los artículos del centro de ayuda para las aplicaciones de seguridad móvil de la empresa. A continuación, le explicaremos cómo empezamos a localizar las aplicaciones de seguridad móvil de una forma más fiable, ágil y automatizada. Comenzaremos por las dificultades que nos llevaron a la necesidad de cambiar algo y le guiaremos a través de los retos a los que nos enfrentamos y las soluciones que encontramos. Esperamos que este artículo resulte interesante para cualquier empresa de software de mediana o gran envergadura que se enfrente al reto de implementar Agile no solo en su desarrollo, sino también en todos los aspectos relacionados.

Al igual que muchas otras empresas, Kaspersky había adoptado en algún momento las prácticas de desarrollo ágil. Esto condujo naturalmente a ciclos de lanzamiento mucho más cortos. Si antes lanzábamos nuevas versiones de la aplicación cada pocos meses, ahora lo hacíamos cada dos semanas. Es cierto que ahora había menos cadenas en cada nueva versión, pero eso no ayudaba mucho: seguíamos teniendo que someter esas pocas cadenas a todo nuestro proceso de localización y pruebas lingüísticas, al tiempo que nos enfrentábamos a plazos mucho más ajustados.

También existe la idea errónea de que las aplicaciones móviles solo contienen una pequeña cantidad de texto. ¡Ojalá fuera así! En nuestro caso, por ejemplo, teníamos una media de 25 000 palabras por aplicación solo en los textos de la interfaz de usuario, multiplicadas por unas 10 aplicaciones y por unos 20 idiomas de destino para cada aplicación. Todo ello con nuevos textos de interfaz de usuario y documentación que llegaban cada semana.

Como resultado, la localización se convirtió esencialmente en el cuello de botella de todo el proceso de lanzamiento. Y si antes los gestores de producto ni siquiera conocían los nombres de los miembros del equipo de localización —¿por qué iban a hacerlo, si todas las traducciones aparecían «por arte de magia»?—, ahora eran conscientes de todos los problemas que ello conllevaba a un nivel mucho más profundo de lo que hubieran deseado.

En Kaspersky, el proceso de localización suele constar de dos fases: traducción y pruebas lingüísticas.

El problema general en la fase de traducción era que había demasiado trabajo manual, debido tanto al proceso utilizado como a las limitaciones de la herramienta CAT. En concreto:

• Como no se admitían canalizaciones multirramas, tuvimos que crear manualmente los deltas para la traducción y luego volver a introducirlos en las ramas.

• Era imposible garantizar la coherencia entre las aplicaciones y los idiomas.

• No podíamos realizar traducciones adicionales solicitadas en paralelo, por ejemplo, si los textos originales se modificaban durante el proceso. En su lugar, teníamos que esperar a que el paquete de traducción básico estuviera listo y solo entonces proceder con las traducciones adicionales.

• Los errores en los «no traducibles», los apóstrofos sin escapar y otros errores humanos provocaban cada vez más fallos en la compilación.

El objetivo principal de las pruebas lingüísticas es comprobar la traducción completa dentro de su contexto. Contamos con un sólido equipo de traductores que conocen bien nuestra terminología. Sin embargo, cuando se traduce un texto sin ver lo que lo rodea, o incluso sin saber si se trata de un botón o un encabezado, las cosas pueden torcerse rápidamente.

Por lo tanto, las pruebas lingüísticas implican comprobar manualmente todas las pantallas resultantes de la aplicación, normalmente mediante capturas de pantalla. Esto ayuda a identificar problemas como

• El texto es demasiado largo para el tamaño del elemento de la pantalla. En ocasiones, esto puede tener implicaciones legales, si el texto omitido incluye exenciones de responsabilidad o información financiera.

• Texto sin traducir, ya sea por un error del traductor o porque estaba codificado en lugar de externalizado como una string,

• Texto traducido en un contexto incorrecto, por ejemplo, cuando el texto de un botón (por ejemplo, «Descargar») es gramaticalmente un imperativo en lugar de un infinitivo.

Solo la parte de capturar pantallas requería una cantidad exorbitante de tiempo. Por ejemplo, si una nueva función implicaba 40 pantallas de interfaz de usuario y había 20 idiomas de destino, podía llevar hasta 70 horas de trabajo manual y mecánico tedioso.

En definitiva, era algo con lo que se podía vivir cuando había un nuevo lanzamiento cada tres meses. Pero con lanzamientos quincenales, esto empezó a pasar factura al equipo de localización. Había que solucionarlo, y hacerlo rápido.

1. Contratar a trabajadores con poca experiencia y reducir la cantidad de trabajo de localización, lo que naturalmente conduce a una disminución de la calidad, O
2. Automatizar.

Optamos por lo segundo.

A la hora de elegir la solución CAT/TMS, nuestras principales prioridades fueron:

1. Menos aprobaciones internas: aprobación de presupuestos, generación de claves de serie y todo lo demás. — para poder empezar a utilizarlo de inmediato sin tener que esperar a que se desarrollaran más funciones.

2. Requisitos de servidor ligeros — de nuevo, para evitar aprobaciones largas.

3. Accesible, preferiblemente gratuito, acceso al servicio.

4. Soporte adecuado por parte del servicio para no tener que contratar a un desarrollador interno.

5. Requisitos de seguridad: nosotros nos conectamos a él, y no al revés.

6. Soporte multirrama — para traducir varias funciones en paralelo.

7. Traducciones adicionales posibles en paralelo con el lote original.

Cuando recopilamos una lista de opciones, solo nos quedaron dos nombres: Smartcat y Zing, un servidor de localización continua de los creadores de Evernote.

Nos gustó Zing por su personalización, su paquete de instalación gratuito y su acceso privado, ya que podíamos alojarlo dentro de nuestra propia organización. Por el contrario, el proceso de instalación no fue nada fácil, por lo que incorporar a todos nuestros traductores y personal supondría un coste de tiempo demasiado elevado para el funcionamiento del servicio.

Así que nos decidimos por Smartcat. Como no se nos permite conectar herramientas CAT directamente a nuestro VCS interno, optamos por utilizar un paquete Smartcat–Serge. (Serge es un software de código abierto que sincroniza cadenas entre los sistemas de control de versiones y de gestión de traducciones. Identifica cadenas en archivos de diversos formatos y las convierte al formato PO estándar del sector, que luego envía a Smartcat. Podemos instalarlo directamente en nuestros servidores, por lo que ninguna de nuestra información clasificada sale al exterior).

Esto es lo que más nos gustó de la solución resultante:

• Cumple con todos nuestros requisitos: canalizaciones multirramas, traducciones adicionales, seguridad, etc.

• Recibimos actualizaciones al instante, sin necesidad de descargar ni instalar nada.

• Podemos crear nuestros propios esquemas de análisis sintáctico para cadenas gracias al paquete Smartcat–Serge.

• Podemos hablar con los traductores que trabajan en nuestros documentos sin salir de la plataforma.

• Podemos encontrar autónomos directamente en el mercado de la plataforma, si alguna vez necesitamos aumentar la producción.

• Podemos pagar todos los idiomas y proyectos con una sola factura.

• Nos encanta el apoyo que recibimos : el equipo de Smartcat nos ayudó a poner en marcha nuestro flujo de trabajo y dio prioridad a algunas de las funciones que eran fundamentales para nosotros. — al final optamos por una suscripción debido a la función de búsqueda de texto en todo el proyecto, pero esta decisión fue opcional.

Algunos de los retos a los que nos enfrentamos fueron:

• Al principio, no podíamos buscar texto dentro de todos los documentos de un proyecto, pero esto ya no es un problema, ya que Smartcat ha implementado esa función desde entonces.

• El gestor del proyecto tiene que enviar manualmente las invitaciones a los traductores, pero hemos oído que este paso se automatizará pronto.

Teniendo en cuenta nuestra experiencia con Smartcat hasta ahora, esperamos que su equipo ya esté trabajando para resolver estos problemas.

Para poner las cosas en perspectiva, aquí hay una comparación entre lo que teníamos y lo que tenemos ahora, tanto en términos de procesos como de cifras.

Antes

Antes de los cambios, teníamos que seguir cerca de 30 pasos a lo largo de las etapas de traducción y pruebas lingüísticas:

Traducción:

1. Recopilar textos de diferentes ramas en el repositorio, manualmente.

2. Crear un delta para la traducción, manualmente.

3. Crear paquetes para la traducción.

4. Subirlos a un servidor FTP,

5. Escribir un montón de correos electrónicos a agencias, autónomos u oficinas locales,

6. Recoger la traducción del servidor FTP una vez lista,

7. Cargarla en la herramienta CAT y asegurarse de que todo está bien,

8. Subir las cadenas traducidas al repositorio intentando no mezclar las ramas, de forma manual,

9. Ejecutar una compilación, corregir errores, completar la compilación,

10. Solicitar traducciones adicionales, básicamente repitiendo el mismo proceso otra vez.

Pruebas lingüísticas:

1. Iniciar la compilación y esperar a que finalice.

2. Reiniciar la compilación si ha fallado debido a errores de localización.

3. Configurar un entorno de pruebas especial si no hay menú de depuración.

4. Realizar todas las capturas de pantalla pertinentes para más de 20 idiomas.

5. Averiguar, junto con el equipo de control de calidad, cómo obtener las capturas de pantalla que aún faltan.

6. Crear y nombrar paquetes de capturas de pantalla.

7. Subirlos al servidor FTP.

8. Asignar tareas a las agencias de traducción para que comprueben las traducciones.

9. Responder a las preguntas de las agencias.

10. Aceptar las tareas y realizar los cambios.

11. Realizar la compilación, lo que a veces lleva mucho tiempo.

12. Volver a realizar la compilación si hay errores.

13. Realizar capturas de pantalla para pruebas regresivas.

14. Volver a subir las capturas de pantalla y asignar tareas a las agencias de traducción.

15. Volver a discutir todo con las agencias.

16. Volver a realizar otra ronda de pruebas regresivas si se han producido cambios en la traducción.

Después

Ahora solo tenemos nueve pasos en todas las etapas:

1. El redactor envía las nuevas cadenas a Git. Serge las introduce automáticamente en Smartcat.

2. El gestor de proyectos de localización asigna traductores.

3. Los traductores traducen en contexto, con capturas de pantalla y comentarios al alcance de la mano.

4. El gestor de proyectos de localización revisa y confirma la traducción, que luego vuelve automáticamente a Git.

5. El equipo de localización ejecuta el bot de captura de pantalla de funciones para los textos localizados.

6. El equipo de localización coloca las capturas de pantalla localizadas en el servidor FTP y las envía a los lingüistas.

7. Los lingüistas comprueban y corrigen las traducciones si es necesario mientras miran las capturas de pantalla localizadas.

8. Los cambios se envían automáticamente a Git.

9. El equipo de localización cierra la solicitud de extracción.

Eso es todo: con esta reducción de la complejidad en tres partes, realmente notamos la diferencia en comparación con lo que teníamos antes.

Todas las cifras corresponden a una versión (cada dos semanas) y a una aplicación.

Entre las ventajas adicionales, algunas de las cuales no habíamos previsto, se incluyen:

• Compilaciones más fiables: gracias a marcadores de posición, ya no tenemos que preocuparnos de que se traduzcan textos no traducibles o de que no se escapen los apóstrofos, etc.

• Smartcat identificó algunos errores antiguos gracias a su configuración de errores críticos.

• No malgastamos el tiempo y los recursos de otras personas: no necesitamos tomar dispositivos de prueba del equipo de control de calidad ni utilizar el tiempo del equipo de desarrollo para tomar capturas de pantalla.

• Las capturas de pantalla disponibles para los traductores, que pueden abrir y ver fácilmente desde el editor, mejoraron enormemente la calidad de las traducciones.

Podríamos seguir, y estamos seguros de que con el tiempo encontraremos otras formas de mejorar tanto la eficiencia como la calidad de nuestros procesos de localización. Lo más importante es que la localización ya no es un cuello de botella en el ciclo de lanzamiento. Creemos que obtener estos resultados en tan poco tiempo ha sido todo un logro tanto para nuestro equipo como para la plataforma Smartcat.

A continuación, presentamos algunas medidas concretas que hemos tomado tras implementar Smartcat. Las incluimos aquí como «guía rápida» para otras empresas y equipos que deseen seguir nuestros pasos. No todas son fáciles de llevar a cabo, pero la mayoría contribuirán a que el proceso de localización sea más fluido y menos propenso a errores.

Integración:

• Prueba la integración Git–Serge–Smartcat para asegurarte de que todas las cadenas llegan a los proyectos de Smartcat y viceversa. No querrás encontrarte con sorpresas en la fase de producción.

• Acuerda con los ingenieros de software el nombre de las ramas. De esta manera, podrás configurar un bot que busque las ramas específicas que deben localizarse, lo que te ahorrará a ti y a los desarrolladores horas de comunicación.

• Personalice los analizadores sintácticos predeterminados de Serge si es necesario. Por ejemplo, hicimos que los identificadores de cadenas, los comentarios y los enlaces a capturas de pantalla de referencia fueran visibles para los traductores.

• Cree una tarea cron para encontrar ramas de localización según la máscara de nombre acordada anteriormente.

• Considere la posibilidad de realizar pruebas de la interfaz de usuario y capturas de pantalla de las funciones utilizando el marco Kaspresso. Por ejemplo, nuestros desarrolladores incluyen un enlace a una captura de pantalla para cada cadena que utilizan. Cuando el archivo llega a Smartcat, el enlace de la captura de pantalla se incluye automáticamente en la pestaña Comentarios. Puede obtener más información sobre Kaspresso y por qué le puede interesar utilizarlo en aquí.

Localización y pruebas lingüísticas:

• Si dispone de glosarios, cárguelos en Smartcat para garantizar la coherencia en todas sus localizaciones.

• Añada a sus lingüistas internos para que puedan explorar la plataforma y aprender a manejarla antes de que les asigne trabajos reales.

• Busque y seleccione autónomos e incorpórelos a los procesos de su empresa, asegurándose de que saben cómo utilizar capturas de pantalla, comentarios, glosarios, etc.

• Cuando sea necesario, busque agencias de traducción para necesidades adicionales de localización o pruebas.

Esperamos que te hayan sido útiles. ¡Si tienes alguno propio, háznoslo saber!