20 projets, 20 langues, date limite hier. 3e partie

Dernier article sur l' intégration de Serge + Smartcat . Dans cet article, je vais vous expliquer comment nous adaptons Serge à l'ensemble de l'entreprise, considérons 4 intégrations non standard et, en bonus, parlerons de 2 fonctionnalités qui peuvent vous simplifier la vie.

Articles précédents:

20 projets, 20 langues, date limite hier
20 projets, 20 langues, date limite hier. 2e partie

Évolutivité

Dans un article précédent, j'ai expliqué comment configurer Serge pour un référentiel unique. Dans notre entreprise, nous avons plusieurs dizaines de référentiels qui ont besoin de traductions, donc un serveur distinct pour la localisation a été alloué. La structure et l'environnement du fichier sont complètement identiques à ce qui est décrit dans l'article précédent. Chaque référentiel utilise sa propre instance de Serge. Afin de ne pas exécuter les commandes manuellement, chaque instance a une couronne, qui exécute successivement les commandes Serge: recevoir de nouvelles lignes du référentiel, recevoir de nouvelles traductions, analyser, envoyer de nouvelles lignes à Smartcat et envoyer de nouvelles traductions à Gitlab.

Options d'intégration

Deux ensembles de langues dans un référentiel

Commençons par le cas le plus simple. Imaginez que votre référentiel possède plusieurs ensembles de fichiers de ressources. Par exemple, les chaînes client et les API d'application sont stockées dans le même référentiel, mais dans des répertoires différents. Le client est traduit en 20 langues, l'API en 6.

Objectif : organiser une fourniture indépendante de traductions dans chacun des répertoires.
Solution :

1. Mettre en place 2 projets dans Smartcat: en 6 langues et en 20.
2. Configurez 2 projets sur le serveur de localisation.
3. Dans le premier projet du fichier project1.cfg , ajoutez la ligne our $ unmerged_branch_mask = '^ (translateAPI-)'; # traite les branches non fusionnées correspondant à ce masque , où « translateAPI- » est le préfixe du nom de la branche. Le préfixe indiquera à Serge que cette branche a besoin de traductions dans le répertoire API.
4. Dans le fichier project1.serge.tmpl , spécifiez le chemin d'accès aux fichiers de ressources dans le répertoire API dans le paramètre source_dir .
5. De même, pour le deuxième projet du fichier project2.cfg , ajoutez la ligne our $ unmerged_branch_mask = '^ (translateCLIENT-)'; # traite les branches non fusionnées correspondant à ce masque , où « translateCLIENT » est le préfixe des branches de ce projet. Le préfixe indiquera à Serge que cette branche a besoin de traductions dans le répertoire Client.
6. Dans le fichier project2.serge.tmpl , spécifiez le chemin d'accès aux fichiers de ressources dans le répertoire CLIENT dans le paramètre source_dir .

Veuillez noter que les préfixes doivent être uniques parmi tous les projets configurés pour un référentiel.

Au total, nous avons 2 projets dans Smartcat et 2 projets correspondants sur le serveur de localisation. Les deux projets regardent le même référentiel dans Gitlab, mais dans des répertoires différents. Serge, en utilisant le préfixe de branche, comprend quelles lignes il doit envoyer pour traduction. Pour calculer le diff, la même branche base-translate est utilisée.

Localisation Swagger

Dans notre entreprise, tous les produits, y compris la documentation, sont localisés. Nous introduisons maintenant la génération automatique de documentation à partir de swagger, et nous sommes confrontés à la nécessité de la localiser.
Tâche : localiser le swagger avec un minimum d'effort.

Solution : dans le fichier myproject.tmpl.serge , ajoutez l'objet de données à l'objet analyseur et répertoriez-y les champs dont la valeur doit être extraite et envoyée pour traduction:

parser { plugin parse_json data { path_matches \/(summary|description)$ } } 

Une tâche similaire : il est nécessaire de traduire des textes à partir d'un fichier, mais pas tous, mais uniquement des textes légaux. Les autres textes sont fournis par une équipe marketing. Afin de ne pas compliquer la structure et de ne pas créer de fichier supplémentaire pour les textes juridiques, les clés de toutes les lignes légales ont reçu le préfixe «légal»:

 parser { plugin parse_json data { path_matches ^\/legal\..* } } 

Subtilités de traductions juridiques

Un autre cas intéressant. Nous avons un document juridique dont les conditions varient d'un pays à l'autre. Mais, néanmoins, il s'agit d'une seule application et les fichiers de ressources se trouvent dans le même répertoire.

Objectif : dans le cadre d'un projet de traduction de plusieurs documents, chaque document doit être traduit dans une langue spécifique.

Ce qui a été fait :

1. Un répertoire approprié a été créé pour chaque pays, à l'intérieur duquel se trouve un fichier source en anglais correspondant à ce pays.
2. Le chemin de la variable source_dir est spécifié dans le répertoire partagé avec les fichiers de ressources.
3. Nous activons la recherche de fichiers de ressources dans tous les sous - répertoires : source_process_subdirs YES
4. Nous ajoutons un nouveau plugin à la liste des plugins appelés, qui vous permet d'envoyer chaque fichier de ressource spécifique dans la langue souhaitée. À titre indicatif, utilisez le nom du répertoire où il se trouve:

 callback_plugins { :feature_branch { plugin feature_branch data { master_job job.base-translate } } :limit_languages { plugin limit_languages data { # all rules are processed top to bottom; each rule can add or remove languages # so the most priority rules are placed at the bottom if { # by default, don't localize file_matches . then { exclude_all_languages YES } } if { file_matches de-au\/ then { include_languages de-AT } } if { file_matches li-LI\/ then { include_languages li } } if { file_matches pt\/ then { include_languages pt-BR } } if { file_matches zh-Hans\/ then { include_languages zh-Hans } } # and so on.. } } 

Localisation lors du stockage de lignes dans la base de données

Notre système a une partie du code qui stocke les traductions dans la base de données, et pour un certain nombre de raisons, il ne peut pas se déplacer vers des fichiers de ressources dans le référentiel. Cependant, nous devons être en mesure de livrer des traductions rapidement et automatiquement.

Tâche : organiser un processus de localisation continue si les lignes ne sont pas stockées dans le référentiel, mais dans la base de données.

Solution :

1. Créez un référentiel, collectez et regroupez toutes les lignes de la base de données selon le principe qui nous convient (par le nombre de langues de traduction ou par produits).
2. Créez un projet dans Smartcat.
3. Commencez le cycle standard de localisation continue.
4. Fusionnez les branches de traduction dans la branche base-translate.
5. Par couronne, vérifiez la valeur de hachage du dernier commit dans base-translate. Si le hachage a changé, c'est-à-dire que de nouvelles traductions ont été générées, analysez la différence entre l'ancien et le hachage actuel et envoyez des lignes nouvelles / modifiées à la base de données.

Fonctionnalités bonus

Alertes

Les alertes de base Smartcat ne nous convenaient pas, car chaque équipe souhaite recevoir des notifications uniquement sur ses succursales et uniquement sur la disponibilité complète des traductions dans tous les fichiers de ressources du produit.

Il a été décidé de s'appuyer sur la disponibilité de toutes les traductions dans le référentiel et, si elles sont complètement prêtes, d'envoyer des notifications au messager d'entreprise, dans notre cas, Google Chat.

Tâche : organiser les alertes dans le référentiel, où 8 équipes peuvent s'engager, dupliquer toutes les alertes dans le canal du service de documentation technique.

Solution :

1. Convenez avec chaque équipe que le nom des branches doit contenir le nom de l'équipe. Utilisez toujours le préfixe translate- pour indiquer les branches qui ont besoin de traduction.
2. Créez un pipeline qui s'exécute uniquement pour les branches préfixées par translate-.
3. Dans le pipeline, déterminez à quelle commande appartient la branche, vérifiez la présence de lignes avec une valeur vide et, s'il n'y en a pas, envoyez des notifications de disponibilité au canal approprié. Comme le code est assez volumineux, je l'ai mis dans un script.

Ci

 check-translations: stage: check-translations image: node:8.14.0 tags: - devops script: - chmod +x ./notification.sh - ./notification.sh only: - base-translate - /^translate.*$/ when: always 

Script d'alerte

 #!/bin/bash hangouts(){ curl -X POST --max-time 180 -H "Content-Type: application/json; charset=UTF-8" --data "{ \"cards\": [{\"header\": {\"title\": \"LOCALIZATION IS READY\",\"subtitle\": \"REPOSITORY NAME\",\"imageUrl\": \"https://avatanplus.com/files/resources/mid/5775880ee27f8155a31b7a50.png\"},\"sections\": [{\"widgets\": [{\"keyValue\": {\"topLabel\": \"Translation is finished in the branch\",\"content\": \"$1\"}}]},{\"widgets\": [{\"buttons\": [{\"textButton\": {\"text\": \"SEE COMMIT\",\"onClick\": {\"openLink\": {\"url\": \"https://gitlab.loc/common/publisher-client/commit/$2\"}}}}]}]}]}]}" "$3" || true } cd app/translations if echo "$CI_COMMIT_REF_NAME" | grep "commandname1"; then grep -rl '\:\s\"\"' *.json >> result.file if [ -s network.file ]; then echo "Translations are not ready"; cat result.file else hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_COMMAND_NAME_1 hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_DOC fi fi if echo "$CI_COMMIT_REF_NAME" | grep "commandname2"; then grep -rl '\:\s\"\"' *.json >> result.file if [ -s result.file ]; then echo "Translations are not ready"; cat result.file else hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_COMMAND_NAME_2 hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_DOC fi fi ... if echo "$CI_COMMIT_REF_NAME" | grep "commandname8"; then grep -rl '\:\s\"\"' *.json >> result.file if [ -s result.file ]; then echo "Translations are not ready"; cat result.file else hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_COMMAND_NAME_8 hangouts $CI_COMMIT_REF_NAME $CI_COMMIT_SHA $HANGOUTS_NOTIFICATIONS_DOC fi fi 

Affectations de traducteur via l'API Smartcat

Voici à quoi ressemble notre gestionnaire de localisation quand vient le temps d'affecter toutes les branches à la traduction.

En moyenne, nous avons plus de 10 succursales dans notre travail chaque jour. Dans Smartcat, chaque paire de langues est un document distinct et des traducteurs doivent être affectés à chacun de ces documents. Manuellement. Imaginez: 40 à 60 rendez-vous chaque jour. Pour simplifier ce processus, nous avons pris rendez-vous via l'API et l'avons également mis dans le pipeline. Ce travail est lancé par le bouton. Une question raisonnable: pourquoi ne pas rendre les affectations automatiques lors de l'envoi de transferts, et ne pas placer d'appel de méthode dans le plugin Smartcat, et non dans le pipeline?

Plusieurs raisons expliquent cette décision:

1. Le facteur humain. Malgré le fait que nous construisons des processus et essayons de les respecter, des lignes non lues ou des lignes sans contexte entrent régulièrement dans Smartcat. L'affectation automatique dans ce cas entraînerait des dépenses supplémentaires pour nous, car certaines lignes seraient envoyées pour traduction deux fois: avant et après l'édition.
2. Répartition des rôles. Les projets sont configurés et gérés au niveau du serveur de localisation par l'ingénieur de localisation ou le rédacteur technique du projet. Les rendez-vous et la communication avec les traducteurs sont assurés par le responsable de la localisation. Ainsi, les affectations doivent être gérables, transparentes et accessibles via l'interface graphique.

Solution: lorsque le responsable de la localisation considère que les lignes de cette branche sont prêtes à être traduites, il appuie sur un bouton dans Gitlab. Toute l'équipe de traducteurs est affectée à cette branche. La tâche est assumée par le traducteur qui a répondu le premier.

Ci

 assignee: stage: assignee image: node:8.14.0 tags: - devops script: - chmod +x ./assignee.sh - ./assignee.sh only: - base-translate - /^translate.*$/ - assignee when: manual 

Script d'affectation

 #!/bin/bash if echo "$CI_COMMIT_REF_NAME" | grep "translate-"; then node -pe "JSON.parse(process.argv[1]).documents.forEach(function(elem){ if(elem.name.indexOf(\"$CI_COMMIT_REF_NAME\") !== -1) { console.log(elem.id) } });" "$(curl -XGET -H "Authorization: Basic $SMARTCAT_API_KEY" -H "Content-type: application/json" "https://smartcat.ai/api/integration/v1/project/$SMARTCAT_PROJECT_ID")" >> documents fi sed '$d' documents > documents.list while read LINE; do bash -c "curl -XPOST -H 'Authorization: Basic $SMARTCAT_API_KEY' -H "Content-type:application/json" -d '{"documentIds":[\""$LINE"\"],"stageNumber": 1}' 'https://smartcat.ai/api/integration/v1/document/assignFromMyTeam'";done < documents.list 

Ceci conclut ma série d'articles sur l'intégration et la configuration de localisations continues. Je me ferai un plaisir de répondre à toutes vos questions.