Automatiser la gestion de lingui sur les PR ?
publié le , mis à jourAvec l'i18n, à chaque fois qu'on fait une PR qui modifie le texte affiché à l'écran, on doit faire un bun lingui:extract, puis quelqu'un d'autre modifie le texte affiché à l'écran (avec une PR fusionnée avant ou en modifiant directement la branche principale), et ça fait tout un tas de conflits qu'il faut régler avec un rebase et en refaisant bun lingui:extract. En théorie c'est le genre de truc qui s'automatise : on clone le dépot git sur une machine, on rebase, on fait le bun lingui:extract, on fusionne la PR, puis on push sur Codeberg. À voir si c'est faisable en pratique...
etienneJr
perso la routine que j'utilise pour remettre à jour une PR quand elle est désynchronisée de master est :
git checkout master git pull git checkout ma-branche git rebase master # ça sort tous les conflits dans les messages.po git rebase --skip # pour sauter le commit lingui-extract précédent bun run lingui:extract --clean git commit -a git push --force@severo ça va comme ça ? ou bien il y a un truc que j'ai raté ?
laem
Intéressant @etienneJr ce skip ! À noter que quand une PR a plusieurs commits et des conflits, mieux vaut faire un merge en pratique. C'est moins beau, moins pur, et ça nécessite un "git push origin mabranche --force-with-lease" ensuite, mais ça fait gagner du temps :)
Je suis d'accord que c'est pas optimal de truc, mais j'ai pas trop d'idée de comment fluidifier tout ça. Vous comprenez mieux pourquoi j'ai attendu longtemps avant de faire l'i18n haha, ça complique tout.
severo
je suis d'accord que c'est pénible à gérer, mais je ne sais pas à quel point c'est automatisable. 1. on n'a pas de CI sur ce repo, 2. est-ce souhaitable qu'un PR modifie le code toute seule ? (je pense que non).
On peut tester, mais espérons que ça ne génère pas plus de soucis que ça n'en résout.
Mes deux propositions alternatives :
- ajouter un test dans la CI qui lance lingui:extract et retourne une erreur s'il y a des modifications -> indique à l'auteur/rice de la PR qu'il faut lancer lingui:extract en local
- installer https://pre-commit.com/ ou un truc similaire en local pour que lingui:extract se lance automatiquement avant de faire un commit
Attention tout de même à l'automatisation : est-ce qu'on veut
lingui:extractoulingui:extract --clean(mieux, mais efface des traductions existantes, donc du travail des contributeurs/trices, parfois pour une modification minime de la string - auquel cas il est mieux d'essayer d'adapter les strings traduites dans le commit)etienneJr
@severo wrote in https://codeberg.org/cartes/web/issues/2712#issuecomment-21326939:
est-ce qu'on veut
lingui:extractoulingui:extract --clean(mieux, mais efface des traductions existantes,Tu peux me donner plus de détails sur la différence entre les 2 ? (en faisant comme si je n'avais jamais ouvert weblate ou un fichier messages.po, ce qui n'est pas loin d'être le cas)
severo
quand une string n'existe plus dans le code,
lingui:extractmet tout le bloc en commentaires, genre :##: components/itinerary/cycling/LightsWarning.tsx:76 #msgid " et " #msgstr " and "donc on conserve les valeurs existantes, mais elles sont ignorées.
Au contraire,
lingui:extract --cleanefface ces blocs obsolètes. C'est plus propre, on ne traîne pas de vieilles strings, mais on peut perdre des traductions.etienneJr
OK merci
@severo wrote in https://codeberg.org/cartes/web/issues/2712#issuecomment-21336827:
on peut perdre des traductions.
Il n y a pas de sauvegarde sur l'interface weblate ?
severo
non. Mais c'est pas très grave. Si on automatise, à mon avis il faut utiliser
lingui:extract, et fairelingui:extract --cleande manière régulière à la main à des fins de maintenance.esmenard
@severo wrote in https://codeberg.org/cartes/web/issues/2712#issuecomment-21326939:
Mes deux propositions alternatives :
1. ajouter un test dans la CI qui lance lingui:extract et retourne une erreur s'il y a des modifications -> indique à l'auteur/rice de la PR qu'il faut lancer lingui:extract en local 2. installer https://pre-commit.com/ ou un truc similaire en local pour que lingui:extract se lance automatiquement avant de faire un commitCes deux propositions alternatives ne règlent pas le principal problème, qui sont les conflits si une autre modification des textes traduisibles a été effectuée entre la création et le merge de la PR.
severo
Exactement. À mon avis ce n'est pas facilement automatisable.
n4n5
Question bête mais on peut pas avoir, dans les fichiers
.poles translation sans la line numberj'ai l'impression que c'est ce qui pose le plus de conflits: un changement d'une ligne est ça change tout les
.poa cause de la line numbersevero
Bonne idée, c'est pas méga utile, c'est facile de retrouver une string dans le code si besoin.
severo
Ça doit être
lineNumbers: falsefans la configuratiln de lingui: https://lingui.dev/ref/catalog-formats#po-usageSi qqun veut tester
n4n5
@severo wrote in https://codeberg.org/cartes/web/issues/2712#issuecomment-21344678:
Ça doit être
lineNumbers: falsefans la configuratiln de lingui: https://lingui.dev/ref/catalog-formats#po-usageSi qqun veut tester
En effet, ça les vire
severo
Tu peux faire la PR? J'ai pas d'ordi aujourd'hui
severo
Ah OK, ça vire que les numéros, pas le fichier en tant que tel. C'est déjà ça, c'est ce qui chzbge le plus.
esmenard
Oui, sans les numéros il devrait pas y avoir de conflits.
n4n5
@severo wrote in https://codeberg.org/cartes/web/issues/2712#issuecomment-21344819:
Tu peux faire la PR? J'ai pas d'ordi aujourd'hui
laem
Mais attendez, ces numéros de lignes, ils les ont pas mis pour rien, si ?
Ça va pas casser une migration automatique des traductions en cas de déplacement d'un texte dans un fichier ?
laem
La doc dit "Include line numbers in the origin comments. This makes it easier to locate messages in the source code", mais j'espère que ça ne rend pas plus bêtes certaines logiques de
lingui extract. Si c'est juste pour l'oeil humain, ça me va, et ça pousse à faire des composants petits pour bien contextualiser les traductions.severo
C'est pour aider les développeurs, donc optionnel, si j'en crois la doc : https://lingui.dev/ref/catalog-formats
laem
Je viens de tester, quand on change un bloc Trans d'un fichier au même, avec l'option lineNumbers: false, ça change pas les .po, c'est cool, fausse alerte :)