Imaginez: vous avez 7 équipes de développement totalisant plus de 100 personnes. Ils ont vu simultanément 13 demandes. Le travail est effectué dans 20 référentiels.
Toutes les applications doivent être traduites. Certains en 6 langues, certains en 20. Et certains en 13, mais il s'agit d'un ensemble de langues complètement différent, il n'est pas inclus dans les 20 précédents.
Chacun a une pile différente, en raison de différents formats de ligne: js, json, ts, yaml ou yml. Et certains conservent toujours leurs textes dans la base de données.
Vous travaillez sur Agile: livraison de valeur quotidienne, sprints de deux semaines. DoR comprend toutes les traductions nécessaires. Eh bien, bien sûr, des traductions étaient nécessaires hier pour avoir le temps de tester.
Il existe un département de rédacteurs techniques. Qui est rédacteur technique? Il s'agit d'une personne qui écrit de la documentation externe, parfois interne. Écrit toutes sortes de textes que les utilisateurs ou les partenaires peuvent voir: textes frontaux, textes de message, réponses API, erreurs. Accompagne le processus de développement pour s'immerger dans la technologie et la logique métier. Et assure la livraison en temps opportun des traductions de l'application.
Il y a aussi le poste de rédacteur-traducteur et de gestionnaire de localisation. Il s'agit d'une personne qui crée tous les textes en anglais et surveille également la cohérence des traductions, nomme les traducteurs et résout tous les problèmes connexes.
Attention, la question est: combien de spécifications techniques, rédacteurs et responsables de localisation sont nécessaires pour ne pas gêner le développement et ne pas nuire à l'ensemble du service technique?
Dans notre cas, nous avons géré 4 services techniques et 1 gestionnaire de localisation de rédacteurs. La livraison des virements tient en moyenne dans un jour ouvrable et ne dépasse jamais trois jours ouvrables. J'espère que vous le trouverez intéressant.
Comment en sommes-nous arrivés là?
Il y a 6 ans, nous travaillions dans des feuilles Google et une base de données. Autrement dit, si au cours du processus de développement, des lignes sont apparues pour la traduction, nous les avons copiées sur une tablette, puis nous les avons envoyées par courrier à la traduction. Lorsque la traduction était prête, elle a été versée manuellement dans la base de données. Le seul avantage de cette solution est que vous n'avez pas besoin de recaler l'application pour voir de nouvelles lignes. Mais s'il y a une erreur dans les traductions, cela ne fonctionnera pas pour revenir en arrière. Pas de mémoire de traduction, pas de glossaires. La cohérence des traductions est obtenue par la méthode du regard.
Première tentative
La première version à automatiser ce processus ressemblait à ceci: lorsqu'un développeur avait des lignes, il les ajoutait à une nouvelle branche dans un référentiel spécial pour les traductions. Puis, dans la même branche, un pipeline a été lancé, qui, par API, a envoyé toutes les lignes de diff pour traduction. Certes, les traductions devaient déjà revenir à la base de données, mais il n'a pas réussi à charger les lignes de la ressource externe vers la base de données interne via l'API.
Qu'est-ce que cette intégration a apporté? Une étape a été supprimée où le rédacteur technique doit tout rassembler dans une table, envoyer manuellement, puis diviser les traductions reçues par application et par nombre de langues. Dans ce cas, les lignes ont été immédiatement envoyées pour traduction dans le cadre d'un projet du même nom avec l'application à laquelle elles étaient destinées. En conséquence, le rédacteur technique a reçu un ensemble d'archives pour chacune des applications pour lesquelles des travaux ont été effectués. Cela a considérablement réduit la part du travail manuel. De plus, la mémoire de traduction a été implémentée côté fournisseur. Mais cette solution a également conservé un certain nombre d'inconvénients: le stockage des lignes dans la base de données ne permettait pas de gérer les lignes à part entière de notre côté et impliquait toujours une grande partie du travail manuel.
Douleur et localisation continue
L'intégration suivante a apporté beaucoup de souffrance aux développeurs. Il me semble que ceux qui l'ont attrapé ont encore les yeux tremblants au mot «localisation». Ce fut la première intégration avec Serge et Smartcat.
Ici, il est important de dire ce que sont Serge et Smartcat.
Serge est un utilitaire qui prend en charge git. Elle sait comment obtenir les lignes nécessaires de la branche, les envoyer pour traduction, puis renvoyer la traduction des mêmes lignes à la même branche uniquement. Nous avons également besoin d'un plugin qui appellera l'API du système CAT dans lequel nous traduisons. Le plugin devrait recevoir de nouvelles lignes de Serge et retourner les traductions prêtes à Serge.
Smartcat est un système CAT
prenant en charge le glossaire, la mémoire de traduction et les espaces réservés. En outre, Smartcat agrège et simplifie le processus de règlement avec les pigistes, prend en charge la connexion des fournisseurs de traduction.
À cette étape, nous avons transféré les lignes de la base de données vers le référentiel du projet. Maintenant, les chaînes devaient être envoyées directement à partir du référentiel d'applications et y être retournées.
Il était supposé que cela fonctionnerait comme ceci: le développeur sait à partir de quelle branche il a créé sa branche de fonctionnalité, et la différence dans les fichiers de ressources entre ces deux branches est exactement ce qui doit être traduit. Lorsqu'un développeur dispose d'un ensemble de lignes de traduction, il commence un travail dans sa branche avec la configuration Serge. Serge calcule le diff, extrait de nouvelles lignes, appelle le plugin et envoie les lignes pour traduction. Lorsque les traductions sont prêtes, le développeur appelle le travail suivant: il déploie l'instance Serge créée à l'étape précédente, reçoit les traductions terminées et les valide dans la branche source.
La solution s'est avérée instable: Serge n'était pas destiné à être déployé à partir de zéro à chaque lancement du pipeline, les développeurs ne voulaient pas penser aux différences entre les branches, et le plugin Smartcat avait un besoin urgent de mise à jour et d'amélioration. Le processus de livraison de nouvelles lignes pourrait prendre des heures. Et, hélas, cela n'a pas toujours réussi.
Théoriquement, toutes les étapes du processus ont été automatisées, en fait, la maintenance, le calcul du différentiel avant le début du pipeline et le dépannage ont pris plus de temps que de faire la même tâche complètement manuellement.
La lumière au bout du tunnel
D'ici août 2018, nous avons lancé la version actuelle de l'intégration. Nous avons un serveur de localisation. Sur le serveur de chaque référentiel, il existe une instance distincte de Serge. Serge scanne toutes les branches du référentiel, envoie de nouvelles lignes pour la traduction et valide les traductions terminées dans les branches d'origine. Dans l'intégration actuelle, tout est rapide et stable. Après avoir créé une branche pour les traductions, les lignes apparaissent dans Smartcat dans les 5-6 minutes. Après avoir confirmé les transferts, la validation se produit de la même manière, dans les mêmes 5-6 minutes. Le délai de livraison des traductions n'est limité que par le facteur humain: la charge de travail des traducteurs, la différence de fuseaux horaires, etc.
Dans les articles suivants, je vais vous expliquer comment configurer à partir de zéro l'intégration Serge-Smartcat-Gitlab et comment nous avons résolu diverses tâches non standard.
Suite:
20 projets, 20 langues, date limite hier. 2e partie20 projets, 20 langues, date limite hier. 3e partie