¿Qué herramientas utilizan las empresas para conectar la localización con los flujos de trabajo de producto?

Respuesta rápida

Las empresas conectan la localización con flujos de trabajo de producto mediante conectores de repositorios que conectan repositorios de código (GitHub y GitLab) a sistemas de gestión de traducción, plugins Figma que permiten a los diseñadores enviar cadenas para traducción directamente desde archivos de diseño, y APIs de sistemas de gestión de traducción que integran la localización en las canalizaciones CI/CD. El objetivo en todos los casos es la localización continua: se detectan cadenas nuevas o actualizadas y se colocan en cola para su traducción automáticamente como parte del ciclo de desarrollo del producto, de modo que las versiones localizadas se distribuyen en paralelo con las versiones en lenguaje original en lugar de semanas después. Smartling ofrece las tres vías de integración y está calificado como el sistema de gestión de traducción empresarial número uno en G2 durante 20 trimestres consecutivos.

La brecha entre el flujo de trabajo localización y producto

La mayoría de los problemas de localización en las organizaciones de producto no son problemas de calidad de traducción. Son problemas de flujo de trabajo. Se añaden cadenas al producto, se exportan manualmente a una hoja de cálculo o archivo, se envían por correo electrónico a un equipo de localización o a un proveedor, se traducen, se reformatean y se reimportan — un ciclo que dura días o semanas y requiere esfuerzo manual en cada paso. Cuando las cadenas traducidas están listas, el producto ya se ha enviado en inglés y las versiones localizadas se retrasan cada vez más.

La solución no es traducir más rápido. Es eliminar los pasos manuales que crean la brecha. Cuando la localización se conecta directamente al flujo de trabajo del producto, se detectan automáticamente nuevas cadenas, se crean trabajos de traducción sin esfuerzo manual y el contenido traducido se entrega de vuelta al repositorio o herramienta de diseño sin que nadie tenga que gestionar la transferencia. El ciclo de localización se desarrolla en paralelo al ciclo de desarrollo del producto, no después de él.

Las herramientas que hacen esto posible se dividen en tres categorías: conectores de repositorio, integraciones de herramientas de diseño e integración directa de API.

 

Los tres enfoques de integración para conectar la localización con los flujos de trabajo del producto

 
1. Conectores de repositorio (GitHub, GitLab)

Los conectores de repositorio conectan directamente tu repositorio de código y tu sistema de gestión de traducciones. Cuando los desarrolladores comprometen archivos de recursos nuevos o actualizados, el conector detecta automáticamente los cambios, sube las nuevas cadenas al TMS y activa el flujo de trabajo de traducción configurado. Cuando las traducciones están completas, el conector crea una solicitud pull con los archivos traducidos, permitiendo que la actualización de localización se integre en la base de código mediante el mismo proceso de revisión que cualquier otro cambio de código.

Este enfoque es ideal para productos de software y aplicaciones móviles donde las cadenas se almacenan en archivos de recursos en la base de código. Elimina por completo el ciclo manual de exportación e importación de archivos y permite a los equipos de ingeniería incluir el estado de localización como parte de sus comprobaciones estándar de CI/CD, bloqueando las fusiones hasta que todas las cadenas sean traducidas y aprobadas.

El Conector de Repositorio de Smartling es compatible con GitHub y GitLab, escaneando automáticamente los archivos de recursos del repositorio en busca de nuevo contenido, creando ramas de localización y entregando archivos traducidos a través del flujo de trabajo de pull request. El conector está diseñado para entornos de despliegue continuo donde la velocidad de localización es tan importante como la calidad de localización.

2. Integraciones de herramientas de diseño (Figma)

Las integraciones de herramientas de diseño conectan el flujo de trabajo de localización con la fase de diseño del ciclo de vida del producto, donde a menudo se originan las cadenas. En lugar de esperar a que las cadenas se codifiquen de forma fija antes de enviarlas para traducción, las integraciones de diseño permiten a los equipos comenzar la localización durante la fase de revisión de diseño, cuando los cambios aún son de bajo coste de realizar.

El plugin Figma de Smartling permite a los diseñadores subir archivos de diseño directamente a Smartling para su localización, facilitando que las cadenas traducidas sean revisadas en el contexto del diseño antes de que se escriba cualquier código. Esto detecta problemas de diseño, expansión de personajes y preocupaciones culturales en la fase de diseño, donde son más baratos de solucionar.

3. API del sistema de gestión de traducciones

La API TMS ofrece a los equipos de ingeniería acceso programático directo a todas las capacidades de la plataforma: subida de cadenas, creación de trabajos, activación de flujos de trabajo, comprobación del estado de la traducción y descarga de traducciones completadas. Este enfoque requiere esfuerzo de desarrollo para implementarse, pero ofrece la mayor flexibilidad para equipos con pipelines de contenido personalizados, sistemas propietarios de gestión de contenidos o requisitos específicos de flujo de trabajo que no corresponden a un conector preconstruido.

La integración de API también se utiliza para incrustar la localización en pipelines CI/CD: los sistemas de compilación automatizados pueden consultar la API TMS para comprobar si todas las cadenas de una versión están traducidas y aprobadas antes de permitir que un despliegue continúe.

 

Herramientas clave para conectar la localización con los flujos de trabajo de productos

Las herramientas específicas que los equipos de producto e ingeniería utilizan más comúnmente para la integración de localización se dividen en cuatro categorías.

Conectores de repositorio

Los conectores de GitHub y GitLab son los puntos de integración más comunes para los equipos de producto de software. El Conector de Repositorio de Smartling supervisa el repositorio configurado para detectar cambios en archivos de recursos, subiendo automáticamente nuevas cadenas al TMS y entregando traducciones como pull requests. El conector soporta múltiples formatos de archivo y puede configurarse para manejar diferentes tipos de contenido con distintas reglas de flujo de trabajo dentro del mismo repositorio.

Plugins de herramientas de diseño

Figma es la herramienta de diseño dominante para equipos de producto empresariales, y el plugin Figma de Smartling integra la localización directamente en el flujo de trabajo de Figma. Los diseñadores pueden subir archivos de diseño a Smartling para su traducción sin salir de Figma, y las cadenas traducidas pueden revisarse en el contexto del diseño original. Esto permite ciclos de revisión de localización más tempranos y detecta los problemas de localización a nivel de diseño antes de que se conviertan en problemas de ingeniería.

API y SDKs del sistema de gestión de traducción

La API RESTful de Smartling proporciona acceso a todo el conjunto de capacidades de la plataforma para equipos de ingeniería que construyen integraciones personalizadas o integran la localización en flujos de trabajo automatizados de construcción y despliegue. Existen kits de desarrollo de software (SDK) disponibles para reducir el esfuerzo de desarrollo necesario para integrar funciones de la API Smartling en el código existente. La API también se utiliza para la integración CI/CD, donde los sistemas de compilación comprueban el estado de finalización de la traducción antes de permitir que los despliegues continúen.

Gestión de proyectos e integraciones de colaboración

Algunos equipos de ingeniería utilizan integraciones de flujo de trabajo de localización con herramientas de gestión de proyectos para seguir el estado de la traducción junto con otras tareas de desarrollo. Smartling se integra con herramientas del ecosistema de desarrollo de producto para proporcionar visibilidad sobre el estado de la localización dentro de los flujos de trabajo que los equipos de producto e ingeniería ya utilizan para el seguimiento de proyectos.

2x

Tiempo de lanzamiento al mercado más rápido que flujos de trabajo tradicionales de traducción usando Smartling AIHT con localización continua

50%

Reducción del coste de traducción por palabra frente a traducción humana tradicional con AIHT

170+

Países alcanzados por una empresa global que utiliza Smartling, publicando contenido en días en lugar de semanas

#1

Smartling ocupó el puesto número uno en TMS empresarial en G2 durante 20 trimestres consecutivos

Cómo funciona la localización continua a través de la integración de flujo de trabajo del producto

Así es como funciona un flujo de trabajo de localización continuo cuando la localización está conectada directamente al ciclo de desarrollo del producto:

1.
Un desarrollador compromete archivos de recursos nuevos o actualizados en el repositorio de GitHub o GitLab. El conector del repositorio detecta los cambios automáticamente y sube nuevas cadenas al sistema de gestión de traducción sin intervención manual.
2.
El TMS aplica reglas de flujo de trabajo configuradas, enrutando cadenas al flujo de traducción adecuado según el tipo de contenido: Traducción Humana Impulsada por IA (AIHT) para cadenas de producto orientadas al usuario, traducción totalmente automatizada por IA para contenido interno o de baja visibilidad.
3.
AI Adaptive Translation Memory optimiza las coincidencias disponibles de la memoria de traducción, y el glosario y la guía de estilo configurados se aplican antes de que comience la traducción, asegurando que la terminología del producto sea coherente con las traducciones previamente aprobadas.
4.
La traducción avanza a través del flujo de trabajo configurado. Para el AIHT, la IA genera una traducción de primera y un lingüista profesional la revisa y aprueba. Para flujos de trabajo totalmente automatizados, los controles de calidad automatizados gestionan la validación.
5.
Las traducciones completadas se devuelven al repositorio como una solicitud pull o directamente a la herramienta de diseño para su revisión en contexto. El equipo de ingeniería fusiona la PR de localización mediante el proceso estándar de revisión de código.
6.
Para flujos de trabajo CI/CD, el sistema de compilación consulta la API TMS para confirmar que todas las cadenas de una versión están traducidas y aprobadas antes de permitir que el despliegue continúe. Esto garantiza que las compilaciones localizadas se distribuyan en paralelo con la versión en idioma original.

Cuando conectar la localización con los flujos de trabajo del producto es la prioridad correcta

Los equipos de producto de software lanzan lanzamientos frecuentes donde las versiones localizadas van consistentemente rezagadas respecto a las versiones en lenguaje original, creando una experiencia de usuario fragmentada entre los mercados.
Organizaciones de ingeniería donde la sobrecarga manual de exportaciones e importaciones de archivos de localización añade fricción al ciclo de desarrollo y requiere soporte de ingeniería dedicado para cada sprint de localización.
Equipos de producto que desean incluir el estado de localización en las comprobaciones CI/CD, asegurando que los despliegues se bloqueen hasta que todas las cadenas para una publicación sean traducidas y aprobadas.
Las organizaciones de producto orientadas al diseño, donde las cadenas se originan en Figma y revisiones de localización anteriores, reducirían el coste de los cambios de diseño en comparación con detectar problemas tras la transferencia de ingeniería.
Empresas que se expanden a nuevos mercados donde lanzar versiones localizadas simultáneamente con la versión en idioma original es un requisito empresarial más que algo agradable de tener.
Equipos empresariales con grandes volúmenes de traducción en muchos pares de idiomas, donde la localización continua automatizada reduce el número de empleados operativos necesarios para gestionar la localización junto con el desarrollo activo de productos.

Cuando la integración de flujo de trabajo del producto puede no ser la prioridad inmediata

⚠️

Los equipos con lanzamientos de productos poco frecuentes o contenido estable que cambia rara vez pueden no ver suficiente beneficio de eficiencia gracias a la integración continua de localización como para justificar la inversión en configuración frente a un flujo de trabajo por lotes más sencillo.

⚠️

Las organizaciones de ingeniería que no tienen la capacidad de implementar y mantener un conector de repositorio o una integración de API pueden encontrar que un conector CMS o una integración basada en proxy es un punto de partida más accesible.

⚠️

Los equipos de producto en los primeros años de su proceso de internacionalización, cuando las cadenas aún no se externalizan de la base de código a archivos de recursos, pueden necesitar completar ese trabajo de ingeniería antes de que sea práctica una integración de conectores de repositorio.

⚠️

Las organizaciones que planean cambios significativos en la plataforma o en las herramientas, como el traslado a un nuevo repositorio de código o herramienta de diseño, pueden encontrar más eficiente completar esa migración antes de invertir en integraciones de localización para la pila actual.

Lista de verificación empresarial para evaluar la integración de la localización de flujos de trabajo del producto

Utiliza estas preguntas para evaluar si una plataforma de gestión de traducción puede integrarse eficazmente con tu flujo de trabajo de desarrollo de producto.

 
Conector de repositorio
  • ¿La plataforma ofrece un conector de repositorio certificado para tu plataforma de repositorio de código, específicamente GitHub o GitLab?
  • ¿El conector monitoriza automáticamente el repositorio para detectar cambios en archivos de recursos, o requiere activaciones manuales para iniciar la subida de contenido?
  • ¿El conector entrega las traducciones de vuelta al repositorio como pull requests, permitiendo que las fusiones de traducción pasen por el proceso estándar de revisión de código?
  • ¿Se puede configurar la integración CI/CD para que las compilaciones comprueben el estado de finalización de la traducción antes de permitir que los despliegues continúen?
 
Integraciones de herramientas de diseño
  • ¿La plataforma ofrece un plugin Figma o una integración equivalente para la herramienta de diseño del entorno principal de diseño de tu equipo?
  • ¿La integración con la herramienta de diseño soporta sincronización bidireccional: subir cadenas desde archivos de diseño y devolver cadenas traducidas para revisión en contexto?
  • ¿Se pueden revisar las cadenas traducidas en el contexto del diseño original dentro de la herramienta de diseño, permitiendo detectar problemas de diseño y expansión de caracteres antes de la transferencia de ingeniería?
 
API y SDK
  • ¿Ofrece la plataforma una API RESTful con acceso completo a las capacidades de la plataforma, incluyendo creación de empleos, activación de flujo de trabajo, comprobación de estado y descarga de traducciones?
  • ¿Están disponibles kits de desarrollo de software (SDK) para los lenguajes principales de desarrollo de tu equipo para reducir el esfuerzo de integración de la API?
  • ¿Está la API diseñada para su uso en sistemas de compilación automatizados, con límites de tasa, autenticación y diseño de endpoints de estado apropiados para casos de uso CI/CD?
 
Configuración y automatización de flujos de trabajo
  • ¿Se pueden enrutar automáticamente diferentes tipos de cadenas en el mismo repositorio a diferentes flujos de trabajo de traducción, según el tipo de archivo, la ruta o los metadatos?
  • ¿La plataforma soporta reglas de automatización de trabajos que agrupan cadenas y crean trabajos de traducción automáticamente sin intervención manual?
  • ¿Cómo se aplican la memoria de traducción y el glosario para las cadenas de producto: desde la salida de la IA en la primera pasada, o solo durante la revisión humana?

Cómo Smartling conecta la localización con los flujos de trabajo de producto

Smartling ofrece tres vías de integración para conectar la localización con los flujos de trabajo de desarrollo de productos, cada uno diseñado para un punto diferente del ciclo de vida del producto.

El Conector de Repositorio conecta directamente los repositorios de GitHub y GitLab a Smartling. Cuando los desarrolladores comprometen archivos de recursos nuevos o actualizados, el conector detecta automáticamente los cambios, sube cadenas a Smartling y activa el flujo de trabajo de traducción configurado. Las traducciones completadas se devuelven como pull requests, permitiendo que la fusión de localización pase por el proceso estándar de revisión de código. El conector está diseñado para entornos de despliegue continuo, con soporte para comprobaciones CI/CD que verifican el estado de finalización de la traducción antes de que continúen los despliegues.

El plugin Smartling Figma permite a los diseñadores cargar archivos de diseño directamente desde Figma a Smartling, facilitando que las cadenas traducidas se revisen en el contexto del diseño original antes de la transferencia de ingeniería. Esto mueve la revisión de localización más temprano en el ciclo del producto, cuando los cambios de diseño aún son de bajo coste de realizar.

La API RESTful de Smartling proporciona acceso programático completo a las capacidades de la plataforma para equipos que construyen integraciones personalizadas o integran localización en sistemas automatizados de construcción y despliegue. Los SDK están disponibles para reducir el esfuerzo de desarrollo. La API soporta patrones de integración CI/CD, incluyendo la comprobación del estado de traducción como una puerta de compilación.

En todas las vías de integración, la Memoria de Traducción Adaptativa con IA, la aplicación de glosarios y el flujo de trabajo AIHT de Smartling garantizan que las cadenas de producto se traduzcan con los mismos estándares de calidad que otros tipos de contenido. Las reglas de automatización de trabajos agrupan y enrutan cadenas automáticamente, y las traducciones aprobadas se escriben de nuevo en la memoria de traducción para mejorar continuamente la producción futura de IA para contenido similar de productos.

Smartling está calificado como el sistema de gestión de traducción empresarial número uno en G2 durante 20 trimestres consecutivos, y posee las certificaciones ISO 27001, SOC 2, HIPAA, HITRUST e1, PCI Nivel 1 e ISO/IEC 42001:2023.

 

Descubre cómo Smartling se conecta con el flujo de trabajo de tu producto

El conector de repositorio de Smartling, el plugin Figma y la API están diseñados para equipos de producto e ingeniería que necesitan localización, ejecutándose como un proceso automatizado y continuo junto con el desarrollo de producto. Mira cómo funciona para tu repositorio, herramientas de diseño y ritmo de lanzamiento.