Re: Salvatore 2, le retour

Le 20 janv. 2020 à 16:36 +0100, Eric Lupinacci <[email protected]>, a écrit :
> Yop,
>
>
> > Le lun. 20 janv. 2020 à 15:42, Cerdic <[email protected]> a écrit :
> > > # Salvatore
> > >
> > > Salvatore a subi un GROS refactoring avec notamment les points notables suivants :
> > >
> > > 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)
> > >
> >
> > Trop cool.
> > J'ai toujours des vieux besoins sur les items de langue, je ne sais pas si ton refactoring permettrait de mieux les adresser:
> > - renommer des items sans perdre les traductions (faut bien sur une table de correspondance quelque part)

A la lecture du code, je pense que c’est une feature qui existe déjà en pratique :
Quand une nouvelle chaine apparait, salvatore regarde si il a pas déjà une autre en base avec le même contenu, et si c’est le cas il duplique les traductions pour que la nouvelle chaine récupère toutes les trads de celle existante.
Donc si tu renommes une chaine il va créer la nouvelle, dupliquer les trads, et mettre l’ancienne au grenier, ce qui in fine n’est pas si mal.

Mais je note qu’il faut tester ce cas pour être certain que ça marche bien, et si besoin corriger le peu qu’il manque

> > - couper un module de langue en deux en répartissant les items sans perdre aussi les traductions.

hmm je pense qu’on pourrait aussi le gérer : si une chaine n’est pas en base (nouveau module par exemple), on cherche si on trouve la même chaine avec le même contenu dans un autre module, et dans ce cas on duplique, et zou (et l’ancienne sera mise au grenier).

Donc je le note pour le tester aussi, mais a priori jouable

> >
> >
> > > 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
> > >
> >
> > Donc tout basculera d'un coup ?

Oui

> > Comment tu fais pour tester Salvatore sans Trad-Lang alors ?
> > Ou j'ai rien compris ?

Je teste sur une copie locale avec la base, mais sans interface d’édition fonctionnelle, ce qui pour les tests de salvatore ne gêne pas
(enfin j’ai peut-être pas tout testé du coup, mais en principe suffisament pour debug le refactoring de salvatore, sachant que les logiques et traitement sont restés identiques en principe)

> >
> > >
> > > # 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.
> >
> > La nomenklatura dit oui à archivelist qui est suffisamment connu et compréhensible.
> > Et oui pour tout dedans et oui pour l'organisation spip-contrib-outils.
> >
> >
> > >
> > > 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.
> >
> > Clairement oui.

Perfect

Cédric