Hello,
A la suite de la migration d’une partie de la zone vers git ce week-end,
un petit point d’étape concernant Salvatore et Trad-lang
# Salvatore
Salvatore a subi un GROS refactoring avec notamment les points notables suivants :
- intégration au plugin trad-lang, dont il était interdépendant, ensapsulé maintenant dans un spip-cli https://git.spip.net/spip-contrib-extensions/trad-lang/src/branch/master/spip-cli
- séparation de la notion de répertoire module et répertoire dépot :
- chaque dépot est checkout une et une seule fois par url+branche dans un sous-dossier unique salvatore/depots/nom-de-dossier-unique
- on sait checkout en svn ou en git
- chaque module est relié à son dépot via un lien symbolique (plusieurs modules peuvent être linkés vers un même dépot) salvatode/modules/id_de_module_unique
- le lien symbolique est un nom unique qui prend en compte l’url du depot, le nom du module, la branche et le sous-dossier, ce qui permet de traduire potentiellement le même module qui serait éclaté en plusieurs plugins (ex newsletters pour ne pas le nommé, mais potentiellement d’autres)
- l’id unique d’un module est désormais ajouté au fichier xml généré par salvatore comme ici https://git.spip.net/spip-contrib-extensions/scssphp/src/branch/master/lang/paquet-scssphp.xml (ceci est un test de validation, le nouveau salvatore n’est pas encore en prod)
- si on change l’url d’un repo dans le fichiers de traduction (passage de svn à git), salvatore s’y retrouve grace l’id présent dans le fichier et garde l’historique
- salvatore sait aussi commit et pousser en git et en svn (en gérant la problématique des auteurs en git)
- le format du fichier de traductions évolue (l’ancien format reste supporté pour la migration) https://git.spip.net/spip-contrib-extensions/trad-lang/src/branch/master/inc/salvatore.php#L151 pour pouvoir spécifier la méthode (git ou svn), la branche et le sous-dossier dans lequel est le module de langue
La structure de la base de donnée au aussi évolué, pour intégrer un dir_module unique sur chaque module de langue, et l’unicité du champ module n’étant plus assurée les index ont évolués et les fonctions qui traitent les modules de langue doivent être appelées un utilisant la clé primaire et non plus le champ module pour désigner le module concerné.
Une procédure de migration est intégrée, utilisable en spip-cli, pour migrer toute la base avec les modules existants et le fichier de traductions de la zone et permettre de tout recheckout suivant le nouveau format sans perdre d’historique
Chez-moi-ça-marche (tm) : En l’état le nouveau salvatore marche en test et est donc prêt pour une mise en fonction sous surveillance (et debug finaux)
MAIS
# Trad-lang
Comme expliqué plus haut, le fait qu’un module ne soit plus unique impacte la structure de la base et les signatures de fonction.
Il faut donc maintenant revoir aussi trad-lang pour qu’il s’adapte à cette nouvelle logique et gérer la possibilité de plusieurs modules.
Du coup cela veut dire refonte technique, mais aussi passage en 3.2 a minima, et donc un peu de boulot sur la partie squelette, sans laquelle on ne peut pas encore mettre le nouveau salvatore en route.
C’est donc un travail pour les prochaines semaines, stay tuned
# le fichier traductions.txt
Actuellement le fichier est hébergé à la racine de la zone, comme les fichiers de l’empaqueteur.
Dans le cadre de la migration vers git, il me semble qu’il faudrait faire un nouveau projet « archivelist » (ou autre, nomenklatura à l’aide!) dans https://git.spip.net/spip-contrib-outils qui regroupera ce fichier traductions.txt mais aussi les fichiers archivelist.
On peut amha se dispenser d’une synchro avec la zone sur ces fichiers et décider que le projet git fait référence.