Après refonte technique de Salvatore et du site trad.spip.net, la nouvelle version a été mise en route ce début de semaine.
J’ai passé un peu de temps cette semaine à faire travailler Salvatore sous surveillance pour le debug et pour convertir/mettre a jour les fichiers de langue et les XML dont le format a un peu changé
Par ailleurs, je viens de mettre à jour le fichier des traductions, et maintenant presque tous les modules de langue sont gérés via GIT, ce qui a l’avantage de permettre à nouveau de créditer les traducteurs en les mettant comme auteur du commit : https://git.spip.net/spip/spip/commit/9baf4a90f488f12156a1600710dd476fba2ab3cd
(salvatore restant le commiteur, dans son rôle ingrat de moine copiste, puisque git permet de distinguer l’auteur du recopieur)
Egalement, trad.spip.net permet maintenant de traduire les modules répartis entre plusieurs plugins, comme le module newsletter (défini dans les plugins mailshot/mailsubscribers/newsletters)
Par ailleurs, un mécanisme de rafraichissement « rapide » a été intégré : quand un fichier de langue maitre est modifié, il sera *en principe* mis à jour dans trad.spip.net après le passage l’empaqueteur, vers 10’ de chaque heure (toutes les H:10’)
A défaut il sera mis à jour la nuit suivante comme avant
Et j’ajoute une dernière chose, il y a maintenant un bouton « Bon à envoyer » qui permet d’indiquer qu’on a fini une traduction d’un module et qu’on veut que Salvatore mette à jour le dépôt avec, ce qu’il fera dans les 5mn suivantes (sous réserve qu’il y ait bien des nouvelles trads à envoyer !)
Même si je ne suis pas traducteur moi même, gros boulot que tu as fait là, y compris pour le coup de peinture sur le site.
Je trouve juste le vert un peu... très vert
En tirant un poil plus sur le jaune, avec #3d930c par exemple, c'est un peu plus doux et ça passe un peu mieux les tests de contraste, en plus.
Todobien, petite digression, ça me fait remarquer que les mails de notification des commits en git indiquent uniquement le chemin du plugin dans leur sujet (ex : in _plugins_/newsletters/trunk), ce qui ne permet pas de repérer les commits qui ne concernent que des langues (alors qu'en svn le sujet comportait in _plugins_/newsletters/trunk/lang).
Camille, penses-tu qu'on puisse faire quelque chose à ce sujet ?
Egalement, trad.spip.net permet maintenant de traduire les modules répartis entre plusieurs plugins, comme le module newsletter (défini dans les plugins mailshot/mailsubscribers/newsletters)
Après refonte technique de Salvatore et du site trad.spip.net, la nouvelle version a été mise en route ce début de semaine.
Merci, beau chantier !
Ah oui c’est clair !
Sauf un truc, j’aime pas le vert comme couleur
Egalement, trad.spip.net permet maintenant de traduire les modules répartis entre plusieurs plugins, comme le module newsletter (défini dans les plugins mailshot/mailsubscribers/newsletters)
Super !
Ah oui ça c’est top.
Y a un exemple qu’on peut voir sur trad.spip.net aujourd’hui ?
J’ai vu aussi qu’il y avait une recherche avancée pour filtrer la liste des items du module newsletter.
Donc j’ai filtré par langue, par ex, fr impec.
Maintenant si je veux voir juste les items newsletter mais du plugin mailshot je pense qu’il faut utiliser le filtre “Dans le module”.
Si c’est bien ça y a juste un souci c’est que la liste contient tous les modules et pas uniquement ceux concernés par newsletter ce qui serait plus pratique.
D’ailleurs même c’est pas “dans le module” mais “issu du plugin” puisque on est en train de regarder les items du module newsletter non ?
Todobien, petite digression, ça me fait remarquer que les mails de notification des commits en git indiquent uniquement le chemin du plugin dans leur sujet (ex : in _plugins_/newsletters/trunk), ce qui ne permet pas de repérer les commits qui ne concernent que des langues (alors qu'en svn le sujet comportait in _plugins_/newsletters/trunk/lang).
Camille, penses-tu qu'on puisse faire quelque chose à ce sujet ?
+1, et comme déjà soulevé par Rasta, avant on avait carrément l'expéditeur du mail qui était l'auteur du commit :
> Hello, je ne sais pas si c'est possible, mais j'avais l'impression qu'on avait toutes les infos sous la main : à l'intérieur de tous les emails de commits, il y a bien "Author: un nom" (enfin bizarre des fois c'est un nom des fois un email, mais ça identifie vraiment quand même). Est-ce que le hook post-commit qui envoie les emails peut utiliser cette info qu'il a bien déjà pour formater l'expéditeur de l'email avec le format standard "Nom du author <email@truc>" afin de voir le nom dans les clients emails ?
> C'est d'ailleurs bien le cas pour la liste de commits du noyau (dont l'intérieur du contenu a pile le même format).
Là ça devient très très difficile de suivre les commits...
- il me semble que là ce sont bien les notifications de SVN qui continuent à arriver sur spip-zone-commit et pas celles de git (sinon on aurait pas des chemins tels que _plugins_/saisies/trunk/), donc rien à voir avec git
- je pense qu’il faudrait qu’on passe à des notifications via git ou gitea en effet, plutôt que celles via svn, mais quid alors de ce qui se passera sur la zone sur les projets non migrés ? Je pense qu’on ne peut basculer les notifications qu’une fois la zone fermée en écriture, non ?
- concernant l’expéditeur des mails, cela fait déjà longtemps que l’expéditeur de l’email est unique, et c’est lié de manière plus générale à la problématique d’envoi des emails : quand on envoie un email au nom de quelqu’un d’autre ça pose plein de problèmes techniques vis a vis des antispams (l’IP du serveur n’ayant aucune correspondance avec le domaine de l’email concerné) et légaux (j’en connais qui se sont retrouvé convoqué en audition au commissariat pour cette raison, c’est potentiellement une usurpation d’identité)
Peut-être une solution serait de dédier un sous domaine pour ces notifications genre @contrib.spip.net, de forger des adresses mails d'expediteur à partir de l’auteur de commit, comme par exemple :
nicod_ <nicod_+lerebouteux.fr@contrib.spip.net>
ce qui permet de mettre en place un envoi à peu près sécurisé (avec meme un DKIM/SPF si besoin), et un reply to vers la liste et la bonne adresse mail du commiteur
Mais il faudra que la liste accepte ces emails d’expéditeur en entrée (ce qui est un autre problème, qui semble toutefois soluble), et idéalement que les emails sur @contrib.spip.net soient automatiquement redirigés si quelqu’un réponds à cette adresse (parce qu’il copie colle l’email, ou que son client ne respecte par le Reply-to).
Rien d’impossible, mais rien de trivial non plus...
Ma remarque de départ était plus simple, la norme email c'est pas juste mettre une adresse dans l'entête "From:", on peut y mettre le format standard "From: Nom quelconque <email@truc>".
"Salvatore <spip-zone-commit@spip.net>"
"Cédric <spip-zone-commit@spip.net>"
"Charles <spip-zone-commit@spip.net>"
etc
Et donc avoir le nom dans les clients email (et pouvoir filtrer, etc).
Ya aucune manip compliquée, de génération de faux emails reconstruits, etc, juste changer le nom du From, ce serait parfait, sachant que le nom on l'a bien sous la main au moment d'envoyer (c'est le contenu du "Author: …" au tout début du texte de chaque email).
Cela dit, pourquoi pour la liste du core, là on a bien des From différenciés ?
les clients email un peu smart retiennent que Charles a pour adresse email spip-zone-commit@spip.net et la fois suivantes que tu veux écrire à « Charles » pouf il te recolle l’adresse email en spip-zone-commit@spip.net (et tu le vois même pas car c’est en format réduit).
Ou au contraire, tu veux écrire à spip-zone-commit@spip.net et il s’obstine à te mettre « Charles » comme adresse de destinataire.
1) Tu peux avoir plusieurs amis qui s'appellent "Charles", si ton client email quand tu commences à mettre "Char…" comme destinataire il te présente pas dans une liste TOUS tes amis s'appelant Charles avec un moyen clair de les distinguer (= leur email au moins), c'est qu'il est vraiment pas smart.
Et donc on peut pas se baser sur un (gros) défaut d'ergonomie d'un client mail pour s'empêcher de distinguer facilement sans effort nos emails.
2) C'est pourtant bien ce que font tous les gros services en ligne comportant des commentaires. TOUS les emails de Github ont en From uniquement l'email "notifications@github.com" avec le nom qui change ("b_b <notifications@github.com>"). Pareil pour Gitlab, y compris le votre ("Cédric <gitlab@nursit.net>"). Ce n'est donc pas considéré comme une mauvaise pratique du tout par des services qui envoient des millions d'emails par jour, ni divers logiciels libres.
3) Si vraiment on veut distinguer, on peut très bien rajouter un préfixe au nom : "SPIP-Zone - Charles", "SPIP-Zone - Salvatore", avec toujours le même email, ça reste alors parfaitement clair que c'est bien SPIP-Zone qui envoie, mais avec des variantes.
En effet, my bad!
Du coup je suis retourné dans mon client mail tester et ce qui gêne c’est donc ensuite quand tu veux écrire à cette adresses mail, il te ressort un des noms utilisés à la réception.
Il faut donc juste utiliser une adresse mail qui n’est pas celle de la liste concernée, mais donc une adresse en notifications@rezo.net par exemple (ou n’importe quel domaine qui marche bien sur ce serveur mail)
Désolé j'ai pas tout compris. Donc possible que je réponde à coté de la plaque.
Pour le moment c'est bien svn qui notifie des commits.
Dès qu'un commit se fait sur git il est envoyé à svn et c'est alors
que la notification est envoyé. Il est possible de modifier le format
du mail mais je n'ai pas bien compris ce qu'il faudrait modifier.
Il est possible de laisser chaque forge gérer les notifications d'un
coté gitea et de l'autre svn mais je n'en suis pas très fan car cela
demanderait une double maintenance. J'opterai bien d'attendre qu'on
est transformé le svn en lecture seule pour basculer les notifications
depuis gitea.
Pour forge le mail expéditeur, on prend le mail du commit. Sur la zone
l'identifiant est le mail tandis que sur git ce sont 2 choses
distinctes.
Si l'expéditeur git est associé à un compte svn, alors c'est le mail
svn qui est utilisé comme expéditeur
Si l'expéditeur git n'est pas associé à un compte svn (par exemple
les traducteurs ou les comptes gitea en direct) c'est alors un peu
magique. Svn "invente" le mail expéditeur et forme un mail (selon une
régle que ne n'ai plus en tête)
Yo Camille,
en fait dans cette conversation, ainsi que dans le fil dédié que j'avais créé à la base pour ça (Expéditeur…), on ne parle pas de l'email avant tout, mais *du nom*.
Là tous les emails on le même nom d'expéditeur, alors qu'il est normalement facile de le changer pour mettre le vrai nom de la personne qui a commité (puisque ce nom est juste en tout premier dans le contenu du texte, c'est bien qu'on l'a sous la main).
Oui je viens d'expliquer comment cela fonctionne actuellement avec le
système de notification avec svn. On n'a conscience que d'un login
(c'est à dire un email dans notre cas).
N'est pas distingué nom d'expéditeur et mail d'expéditeur.
Si le mapping fonctionne (c'est à dire pour les comptes existants sur
la zone et qu'on trouve une correspondance entre git et svn) on arrive
à utiliser le mail présent sur la zone. Pour les traducteurs on n'a
pas de mapping donc on prend un mail par défaut (et par conséquent un
nom identique).
Le hook svn ne forge par les enêtes de mail et son contenu de la même façon.
Ah c'est un truc pré-codé sur lequel on n'a pas la main tu veux dire ?
Parce que dans le contenu, qui est bien généré au même moment, il y a bien le *nom* de la personne, donc c'est un peu bizarre de pas pouvoir utiliser cette info qu'on connait bien à ce moment, pour remplir le nom de l'envoyeur…
