avec le passage d’un dépôt svn unique vers de multiples dépôts git se pose la question du fichiers traductions.txt qui alimente trad.spip.net et salvatore.
Au départ je pensais faire un dépôt archivelist qui contiendrait le fichier traductions.txt actuel, mais à la reflexion je me demande si il ne serait pas mieux et plus lisible que chaque dépôt puisse déclarer ses besoins de traduction.
Cela pourrait se faire
- dans le fichier paquet.xml mais dans ce cas il faut introduire de nouvelles balises xml qui casseront sur les anciennes versions de SPIP
- dans un fichier package.json (ou composer.json dans l’avenir), avec une syntaxe json compatible pour les package composer sur le modèle suivant :
{
"extra": {
"translate": [{
"branch": "master",
"files": [
"lang/medias_fr.php",
"lang/paquet-medias_fr.php"
]
}]
}
}
La déclaration des fichiers à traduire suffisant à définir le module et la langue mère.
Potentiellement on peut vouloir traduire plusieurs branches, si un module n’existe que dans une branche ou si la branche master n’est pas la branche de référence,
(mais je ne suis pas sur qu’il faille autoriser de traduire le même fichier depuis plusieurs branches car cela entrainerait du doublon et de la confusion côté traduction, ou alors de façon exceptionnelle uniquement)
Il est ensuite assez facile de récupérer tous les fichiers package.json des projets de git.spip.net et de traduire les projets qui le demandent.
Se pose également la question de la traduction des projets hébergés ailleurs, sur github par exemple.
Si techniquement il va être possible de brancher salvatore dessus, il y aura toujours une question de droits d’écriture (il faut que salvatore soit autorisé en écriture directement sur le projet) qui fait que ça devrait être géré manuellement au cas par cas.
Peut-être le mieux est de décider qu’un projet *doit* être sur git.spip.net pour bénéficier de la traduction par la communauté ?
Est-ce que dans ce cas on peut prévoir que salvatore ait un droit en écriture sur tous les projets hébergés sur git.spip.net quel que soit le propriétaire ?
avec le passage d’un dépôt svn unique vers de multiples dépôts git se pose la question du fichiers traductions.txt qui alimente trad.spip.net et salvatore.
Au départ je pensais faire un dépôt archivelist qui contiendrait le fichier traductions.txt actuel, mais à la reflexion je me demande si il ne serait pas mieux et plus lisible que chaque dépôt puisse déclarer ses besoins de traduction.
Cela pourrait se faire
dans le fichier paquet.xml mais dans ce cas il faut introduire de nouvelles balises xml qui casseront sur les anciennes versions de SPIP
dans un fichier package.json (ou composer.json dans l’avenir), avec une syntaxe json compatible pour les package composer sur le modèle suivant :
La balise traduction existe déjà pour le paquet.xml.
Il faut vérifier par contre qu’elle te donne les informations requises mais en tout cas je l’avais créé il y a longtemps car je voulais par smart-paquets m’affranchir du fichier traductions.txt en le recréant à la volée à partir des balises traduction.
Donc oui, pour moi c’est la bonne approche.
La déclaration des fichiers à traduire suffisant à définir le module et la langue mère.
Potentiellement on peut vouloir traduire plusieurs branches, si un module n’existe que dans une branche ou si la branche master n’est pas la branche de référence,
(mais je ne suis pas sur qu’il faille autoriser de traduire le même fichier depuis plusieurs branches car cela entrainerait du doublon et de la confusion côté traduction, ou alors de façon exceptionnelle uniquement)
Ouais là je trouve que c’est casse gueule. Est ce vraiment utile de demander cet effort aux traducteurs ?
Si techniquement il va être possible de brancher salvatore dessus, il y aura toujours une question de droits d’écriture (il faut que salvatore soit autorisé en écriture directement sur le projet) qui fait que ça devrait être géré manuellement au cas par cas.
Peut-être le mieux est de décider qu’un projet doit être sur git.spip.net pour bénéficier de la traduction par la communauté ?
Est-ce que dans ce cas on peut prévoir que salvatore ait un droit en écriture sur tous les projets hébergés sur git.spip.net quel que soit le propriétaire ?
C’est le cas déjà non ? Il me semble que les bots comme salvatore et amemo ont toujours des droits d’écriture dans les repos.
Exemple concret : si je ramène bank sur git.spip.net, pour autant je veux garder la main sur les commits et que les contributions soient en mode PR uniquement, donc pas le mettre dans spip-contrib-extensions.
Autre plan, tu peux laisser bank où il est et demander à salvatore de commiter sur github, c'est ce qu'on fait déjà pour geodiv et seenthis cf :
Salvatore a un compte sur github, il suffit de l'ajouter à la liste des commiters du repo ou de l'organisation.
Dans ce cas est-ce qu’il faudra autoriser salvatore au cas par cas, ou est-ce qu'il est possible de lui donner un droit universel sur *tous* les repos ?
Amha oui ça semble logique (espérons que ça soit possible), si le code est sur la zone salvatore doit pouvoir commiter dessus.
Ah oui mais alors dans ce cas il faut qu’on garde un fichier archivelist manuel quelque part pour déclarer les projets en dehors de git.spip.net
Donc on ferait un mix :
- pour les projets de git.spip.net il suffit de le déclarer dans le repo selon format à préciser
- pour les autres projets on a un archivelist
Donc on revient quand même à faire un projet archivelist sur git.spip.net, on y migre le fichier actuel, et quand la feature par repo sera fonctionnelle on pourra le cleaner.
Ça semble le plus robuste
Oui dans la période de transition, ça permet que le fichier soit toujours pris en compte tel qu'il est déjà.
Mais je suis plutôt pour ta première idée qu'à terme ça soit uniquement déclaratif en interne et que si on veut profiter des automatismes on doit être sur la forge communautaire.
Après pour les cas non-automatiques, ça pourrait être ajouté manuellement dans l'interface de trad.spip ? Tout ce qui est sur la forge communautaire est scanné et reconnu automatiquement par XML ou JSON plus tard. Et ce qui est externe c'est ajouté à la main (librement je sais pas, sinon par les admins en demandant).
Pour les processus de traduction aucun avis de mon coté, je ne
maîtrise ni le tenants ni les aboutissants.
Pour le moment les projets hébergés sont des "contrib" du coup si on
déclare le compte salvatore (si ce n'est déjà fait) il aura les
droits de commiter en direct.
Pour les projets "non-contrib" (externe ou dist ou autre), le bot peut
ne pas avoir de droit d'écriture direct et avoir des droits de PR.
Mais dans ce cas c'est au bot d'ouvrir la PR probablement via l'api.
Certes.
Mais quid du cas où une chaine de langue est différente entre plusieurs branches ?
S'il y a une nouvelle traduction elle remplacerait celle des branches antérieures, ça peut poser des problèmes de sens, non ?
Ou peut aussi assumer ce principe...