Quels outils les entreprises utilisent-elles pour relier la localisation aux flux de travail des produits?

L’écart entre le flux de travail localisation et produit

La plupart des problèmes de localisation dans les organisations de produits ne sont pas des problèmes de qualité de traduction. Ce sont des problèmes de flux de travail. Des chaînes de caractères sont ajoutées au produit, exportées manuellement dans un tableau ou un fichier, envoyées par courriel à une équipe de localisation ou un fournisseur, traduites, reformatées et réimportées — un cycle qui prend des jours voire des semaines et qui demande un effort manuel à chaque étape. Au moment où les chaînes traduites sont prêtes, le produit a déjà été expédié en anglais, et les versions localisées prennent de plus en plus de retard.

La solution n’est pas de traduire plus vite. C’est pour supprimer les étapes manuelles qui créent l’espace. Lorsque la localisation est directement connectée au flux de travail du produit, de nouvelles chaînes sont détectées automatiquement, les tâches de traduction sont créées sans effort manuel, et le contenu traduit est renvoyé au dépôt ou à l’outil de conception sans que personne n’ait besoin de gérer le transfert. Le cycle de localisation se déroule en parallèle avec le cycle de développement du produit, pas après.

Les outils qui rendent cela possible se divisent en trois catégories : connecteurs de dépôt, intégrations d’outils de conception et intégration directe d’API.

Les trois approches d’intégration pour connecter la localisation aux flux de travail produits

1. Connecteurs de dépôt (GitHub, GitLab)

Les connecteurs de dépôt font le pont direct entre votre dépôt de code et votre système de gestion de traduction. Lorsque les développeurs valident de nouveaux fichiers de ressources ou des fichiers de ressources mis à jour, le connecteur détecte automatiquement les changements, téléverse les nouvelles chaînes dans le TMS et déclenche le flux de traduction configuré. Lorsque les traductions sont terminées, le connecteur crée une pull request avec les fichiers traduits, permettant à la mise à jour de localisation de fusionner dans la base de code par le même processus de révision que tout autre changement de code.

Cette approche est idéale pour les produits logiciels et les applications mobiles où les chaînes sont stockées dans des fichiers ressources de la base de code. Cela élimine complètement le cycle manuel d’exportation et d’importation de fichiers et permet aux équipes d’ingénierie d’inclure le statut de localisation dans leurs vérifications CI/CD standard, bloquant les fusions jusqu’à ce que toutes les chaînes soient traduites et approuvées.

Le connecteur de dépôt de Smartling supporte GitHub et GitLab, scannant automatiquement les fichiers ressources du dépôt à la recherche de nouveau contenu, créant des branches de localisation et livrant des fichiers traduits via le flux de travail pull request. Le connecteur est conçu pour des environnements de déploiement continu où la vitesse de localisation est aussi importante que la qualité de la localisation.

2. Intégrations d’outils de conception (Figma)

Les intégrations d’outils de conception relient le flux de travail de localisation à la phase de conception du cycle de vie du produit, où les chaînes proviennent souvent. Plutôt que d’attendre que les chaînes soient codées en dur avant de les envoyer pour traduction, les intégrations de conception permettent aux équipes de commencer la localisation lors de la phase de revue de conception, lorsque les changements sont encore peu coûteux.

Le plugin Figma de Smartling permet aux concepteurs de téléverser directement les fichiers de conception dans Smartling pour la localisation, permettant ainsi de revoir les chaînes traduites dans le contexte de la conception avant que tout code ne soit écrit. Cela détecte les problèmes de mise en page, d’expansion des personnages et de préoccupations culturelles au stade de conception, où c’est le moins coûteux à corriger.

3. API du système de gestion de traduction

L’API TMS donne aux équipes d’ingénierie un accès programmatique direct à toutes les capacités de la plateforme : téléchargement de chaînes de caractères, création de jobs, déclenchement de flux de travail, vérification de l’état des traductions et téléchargement des traductions terminées. Cette approche nécessite un effort de développement pour être mise en œuvre, mais offre la plus grande flexibilité aux équipes disposant de pipelines de contenu personnalisés, de systèmes de gestion de contenu propriétaires ou d’exigences de flux de travail spécifiques qui ne correspondent pas à un connecteur préconstruit.

L’intégration API est également utilisée pour intégrer la localisation dans les pipelines CI/CD : les systèmes de compilation automatisés peuvent interroger l’API TMS pour vérifier si toutes les chaînes de caractères d’une version sont traduites et approuvées avant d’autoriser un déploiement.

Outils clés pour connecter la localisation aux flux de travail produits

Les outils spécifiques que les équipes produit et d’ingénierie utilisent le plus couramment pour l’intégration de la localisation se divisent en quatre catégories.

Connecteurs de dépôt

Les connecteurs GitHub et GitLab sont les points d’intégration les plus courants pour les équipes de produits logiciels. Le connecteur de dépôt de Smartling surveille le dépôt configuré pour détecter les modifications des fichiers de ressources, téléversant automatiquement de nouvelles chaînes dans le TMS et livrant les traductions sous forme de pull requests. Le connecteur prend en charge plusieurs formats de fichiers et peut être configuré pour gérer différents types de contenu avec différentes règles de flux de travail au sein du même référentiel.

Plugins d’outils de conception

Figma est l’outil de conception dominant pour les équipes produit d’entreprise, et le plugin Figma de Smartling intègre la localisation directement dans le flux de travail Figma. Les concepteurs peuvent télécharger des fichiers de conception vers Smartling pour traduction sans quitter Figma, et les chaînes de caractères traduites peuvent être consultées dans le contexte de la mise en page originale. Cela permet des cycles de révision de localisation plus précoces et détecte les problèmes de localisation au niveau de la conception avant qu’ils ne deviennent des problèmes d’ingénierie.

API et SDK du système de gestion de traduction

L’API RESTful de Smartling donne accès à l’ensemble complet des capacités de la plateforme pour les équipes d’ingénierie qui développent des intégrations personnalisées ou intègrent la localisation dans des flux de travail automatisés de construction et de déploiement. Des kits de développement logiciel (SDK) sont disponibles pour réduire l’effort de développement nécessaire à l’intégration des fonctions de l’API Smartling dans le code existant. L’API est également utilisée pour l’intégration CI/CD, où les systèmes de compilation vérifient l’état de la traduction avant de permettre la poursuite des déploiements.

Gestion de projet et intégrations de collaboration

Certaines équipes d’ingénierie utilisent des intégrations de flux de travail de localisation avec des outils de gestion de projet pour suivre l’état de la traduction en parallèle d’autres tâches de développement. Smartling s’intègre aux outils de l’écosystème de développement produit pour offrir une visibilité sur l’état de la localisation dans les flux de travail que les équipes produit et ingénierie utilisent déjà pour le suivi des projets.

Comment fonctionne la localisation continue grâce à l’intégration des flux de travail produits

Voici comment fonctionne un flux de travail de localisation continu lorsque la localisation est directement liée au cycle de développement du produit :

Lorsque l’intégration des flux de travail produit n’est pas toujours la priorité immédiate

Liste de vérification d’entreprise pour évaluer l’intégration de la localisation des flux de travail produits

Utilisez ces questions pour évaluer si une plateforme de gestion de traduction peut s’intégrer efficacement à votre flux de travail de développement de produits.

Connecteur de dépôt

• La plateforme offre-t-elle un connecteur de dépôt certifié pour votre plateforme de dépôt de code, plus précisément GitHub ou GitLab?
• Le connecteur surveille-t-il automatiquement le dépôt pour détecter des modifications dans les fichiers de ressources, ou nécessite-t-il des déclencheurs manuels pour initier le téléchargement du contenu?
• Le connecteur renvoie-t-il les traductions au dépôt sous forme de pull requests, permettant ainsi aux fusions de traductions de passer par le processus standard de revue de code?
• L’intégration CI/CD peut-elle être configurée pour que les builds vérifient l’état de la traduction avant d’autoriser les déploiements?

Intégrations d’outils de design

• La plateforme offre-t-elle un plugin Figma ou une intégration équivalente à l’outil de conception pour l’environnement principal de conception de votre équipe?
• L’intégration de l’outil de conception supporte-t-elle la synchronisation bidirectionnelle : téléverser des chaînes à partir de fichiers de conception et renvoyer les chaînes traduites pour une révision contextuelle?
• Les chaînes traduites peuvent-elles être examinées dans le contexte de la mise en page originale dans l’outil de conception, permettant ainsi de détecter les problèmes de mise en page et d’expansion des caractères avant le transfert d’ingénierie?

API et SDK

• La plateforme offre-t-elle une API RESTful avec un accès complet aux capacités de la plateforme, incluant la création d’emplois, le déclenchement de flux de travail, la vérification de statut et le téléchargement de traduction?
• Des kits de développement logiciel (SDK) sont-ils disponibles pour les principaux langages de développement de votre équipe afin de réduire l’effort d’intégration de l’API?
• L’API est-elle conçue pour être utilisée dans des systèmes de compilation automatisés, avec des limites de débit, une authentification appropriée et la conception de terminaux d’état pour les cas d’utilisation CI/CD?

Configuration et automatisation des flux de travail

• Est-ce que différents types de chaînes dans le même dépôt peuvent être automatiquement acheminés vers différents flux de traduction, selon le type de fichier, le chemin ou les métadonnées?
• La plateforme supporte-t-elle des règles d’automatisation des emplois qui créent automatiquement des chaînes de chaînes et des tâches de traduction sans intervention manuelle?
• Comment la mémoire de traduction et le glossaire sont-ils appliqués aux chaînes de produits : à partir de la sortie IA au premier passage, ou seulement lors de la revue humaine?

Comment Smartling relie la localisation aux flux de travail produits

Smartling offre trois voies d’intégration pour connecter la localisation aux flux de travail de développement produit, chacun conçu pour un moment différent du cycle de vie du produit.

Le connecteur de dépôt relie directement les dépôts GitHub et GitLab à Smartling. Lorsque les développeurs valident de nouveaux fichiers de ressources ou des fichiers de ressources mis à jour, le connecteur détecte automatiquement les changements, téléverse les chaînes de caractères dans Smartling et déclenche le flux de traduction configuré. Les traductions terminées sont renvoyées sous forme de pull requests, permettant à la fusion de localisation de passer par le processus standard de revue de code. Le connecteur est conçu pour des environnements de déploiement continu, avec le support des vérifications CI/CD qui vérifient l’état de la traduction avant la poursuite des déploiements.

Le plugin Smartling Figma permet aux concepteurs de téléverser directement des fichiers de conception vers Smartling depuis Figma, permettant ainsi de revoir les chaînes traduites dans le contexte de la mise en page originale avant le transfert d’ingénierie. Cela déplace la revue de localisation plus tôt dans le cycle produit, lorsque les modifications de conception sont encore peu coûteuses à réaliser.

L’API RESTful de Smartling offre un accès programmatique complet aux capacités de la plateforme pour les équipes qui développent des intégrations personnalisées ou intègrent la localisation dans des systèmes automatisés de construction et de déploiement. Les SDK sont disponibles pour réduire l’effort de développement. L’API prend en charge les patrons d’intégration CI/CD, y compris la vérification du statut de traduction comme porte de compilation.

Dans tous les parcours d’intégration, la mémoire de traduction adaptative IA de Smartling, l’application des glossaires et le flux de travail AIHT garantissent que les chaînes de produits sont traduites selon les mêmes normes de qualité que les autres types de contenu. Les règles d’automatisation des tâches se regroupent et routent automatiquement des chaînes de chaînes, et les traductions approuvées sont réécrites dans la mémoire de traduction afin d’améliorer continuellement la sortie future de l’IA pour le contenu produit similaire.

Smartling est classé premier système de gestion de traduction d’entreprise sur G2 pendant 20 trimestres consécutifs, et détient les certifications ISO 27001, SOC 2, HIPAA, HITRUST e1, PCI Niveau 1 et ISO/IEC 42001:2023.

Questions connexes