Re: Salvatore 2, le retour

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)
- couper un module de langue en deux en répartissant les items sans perdre
aussi les traductions.



> 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 ?
Comment tu fais pour tester Salvatore sans Trad-Lang alors ?
Ou j'ai rien compris ?


>
> # 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.

++
Eric