Branchlate· Article 1 sur 2

Des traductions qui suivent les branches Git

Le développeur synchronise sa branche, le métier corrige dans l'app, la CI vérifie. Personne n'attend personne, et personne n'écrase le travail des autres.

8 septembre 20264 min de lectureRead in English

Une application traduite ne contient pas ses textes en dur. Elle utilise des clés, et un fichier par langue associe chaque clé à son texte. Le code dit « affiche telle clé », le fichier français répond « Commander », le fichier anglais « Place order ».

Le code

<Button>
  {t("checkout.submit")}
</Button>

Les fichiers de langue

en.json"checkout.submit": "Place order"fr.json"checkout.submit": "Commander"

L'écran

enPlace orderfrCommander

Le code ne contient que des clés ; chaque langue a son fichier. Changer un texte, c'est changer une ligne d'un fichier, pas le code.

Dans la plupart des équipes, ces fichiers vivent mal. Les développeurs les modifient dans le code ; le métier corrige dans un tableur ou un outil à part ; quelqu'un recopie à la main, et les deux finissent par diverger. Chaque fonctionnalité se termine par la même question : « les textes sont prêts ? ».

Pourquoi suivre les branches Git

Le code vit dans des branches : chaque fonctionnalité a la sienne, relue puis fusionnée. Les textes devraient suivre le même chemin, puisqu'ils changent avec le code qui les affiche. Branchlate part de cette idée simple : une branche Git, une branche de traductions.

Le métier travaille sur la branche de la fonctionnalité, avant qu'elle soit fusionnée, sans attendre une mise en production. Et les traductions arrivent dans le produit avec le code qui les utilise, dans la même revue.

mainfeature/checkoutBranchlate à revoir validé

DevUne branche, une nouvelle cléUne clé ajoutée en anglais, puis branchlate sync. Branchlate crée la même branche à partir des fichiers ; le français manque : pastille rouge.
MétierTraduit et valide, sans toucher au codeDans l'app web, ou directement sur le produit via l'extension Chrome. Le texte validé passe au vert.
DevRapatrie les textes validésUn second sync ramène le texte dans les fichiers. Le développeur le commite, comme n'importe quel changement.
CIVérifie avant le mergebranchlate status échoue si une langue est incomplète, ou si les fichiers ne sont plus synchronisés.
DevMerge, puis on rangeLes traductions arrivent dans main par Git, avec le code. La branche de traductions peut disparaître.

Une fonctionnalité, du premier commit au merge. En pointillé, la copie de la branche dans Branchlate : elle naît au premier sync et disparaît après le merge. Chacun travaille dans son outil, et Git reste la seule route vers main.

Le défi. Les traductions vivent à deux endroits à la fois : dans les fichiers du dépôt, que les développeurs modifient, et dans Branchlate, où le métier les corrige. Les deux changent en même temps, et le travail de l'un ne doit jamais effacer celui de l'autre.

Qui gagne ?

Git ne voit pas la base de Branchlate, et la base ne voit pas l'historique Git : impossible de faire une vraie fusion à trois branches, comme Git le fait pour le code. La règle tient donc dans l'état de chaque texte : est-ce qu'un humain l'a touché, et est-ce qu'il l'a validé ?

Le fichier et Branchlate ont tous deux changé : qui gagne ?

Pas de pastilleen.jsonBranchlatele code gagne
Personne ne l'a touchée dans Branchlate : elle appartient au code.
—
À revoiren.jsonBranchlateBranchlate gagne, le fichier est réécrit
Elle est dans le circuit de relecture : on ne l'écrase pas en silence.
Une option explicite laisse le code gagner, et remet le texte à revoir.
Validéeen.jsonBranchlateBranchlate gagne, le fichier est réécrit
Un humain l'a validée : elle est protégée.
Seul un forçage, confirmé clé par clé, passe outre.

Git ne voit pas la base, la base ne voit pas l'historique Git : pas de merge à trois branches possible. La règle tient donc dans l'état de chaque valeur. La liste des clés, elle, vient toujours du fichier de la langue de référence.

Ce que voit le développeur

Une seule commande, dans le terminal ou dans la CI. Elle détecte la branche, envoie les fichiers, et réécrit ceux qui ont changé. Une seconde sert de garde-fou avant la fusion.

~/app · feature/checkout

$ branchlate sync🌿 Branch createdfr  ⬇ Local key addedcheckout.submit  null✅ Project synced successfully. $ branchlate statusen 100% validatedfr 99% validated- checkout.submit$ echo $?1

La CLI, sortie simplifiée. Elle envoie les fichiers tels quels ; c'est le serveur qui les lit et renvoie la nouvelle version de chacun. Un seul analyseur par format, donc des diffs stables.

Ce que j'en retiens

Git reste la route vers la production : les traductions voyagent avec le code, dans la même revue.
Chaque texte sait à qui il appartient : au code, ou à la personne qui l'a validé.
La CI dit non avant qu'un texte manquant parte en production.