Sujet sur Discussion Projet:Aide et accueil/Flow

Incompatibilité de la fonctionnalité de réponse rapide avec les signatures dans des messages encadrés

10
Ideawipik (discutercontributions)

Bonjour Le problème concerne certains modèles d'avertissements préformatés inclus (rarement car déconseillé et, pour certains modèles, changement potentiel de la signature qui deviendra à chaque enregistrement de la page toujours celle du dernier éditeur) ou "substés" (Aide:Modèle#Substitution) sur les pages de discussion des utilisateurs.

Les destinataires de ce type de messages placés dans des cadres (BMA début, BMA fin) sont souvent des nouveaux. Des modèles positionnent la signature du déposant à l'intérieur du cadre. La signature n'étant pas en fin de section/message, si le destinataire clique sur le bouton [répondre] de la nouvelle fonctionnalité de « réponse rapide » (Préférences → Modification → pages de discussion) , il obtient un message lui annonçant : « Le lien « répondre » ne peut pas être utilisé pour répondre à ce commentaire. Pour répondre, veuillez utiliser l’éditeur de la page complète en cliquant sur « Modifier le code » ».

Pour remédier à ce désagrément fâcheux, ma proposition est de simplement déplacer les signatures insérées via ces modèles en fin de message en dehors du cadre, sous celui-ci. Est-ce que cela vous convient ? Pourriez-vous participer à l'élaboration de la liste des modèles concernés ? Il y a déjà les suivants, avec un paramètre signature, mais il y en a peut-être avec d'autres noms (user ?) ou des paramètres positionnels :

On peut même se demander si le paramètre est indispensable. Dans le premier modèle, le paramètre optionnel, non documenté, a été ajouté en juin 2022 (Juste Juju). Par ailleurs, l'existence du paramètre, n'incite pas le déposant à personnaliser et compléter son message en fonction du destinataire, ce qui peut aisément se faire sous le cadre en signant de manière classique. Des avis ?

Et pour rendre aux Césars ce qui leur appartient : ce sont Bwaaka et Limfjord69 qui ont remonté le problème.

Nemo Le Poisson (discutercontributions)

Salut @Ideawipik,

D'un point de vue technique je suis d'accord avec toi, c'est utile de modifier tous ces modèles pour que l'ajout des signatures via le paramètre signature se fasse en dehors du cadre du modèle, pour s'assurer que l'outil Répondre fonctionne.

D'un point de vue pratique communautaire, je préfère rajouter une phrase plus personnelle par rapport à ce qui est reproché au contributeur, suivi de ma signature en dessous du modèle, et donc ne pas utiliser ce paramètre signature qui incite au dépôt automatique, pratique qui réduit les chances d'entamer un dialogue avec un nouveau. Si on a affaire à un vandale ou un contributeur tétu, se contenter de rajouter des modèles d'avertissement automatique ne va rien améliorer je pense. Soit une conversation se déroule et il y a un changement de comportement, soit c'est que le contributeur n'est pas apte à contribuer et son compte sera de toute façon bloqué.


Donc oui, peut-être que ce paramètre n'est pas indispensable et ça mériterait une discussion avec la communauté et notamment le bulletin des patrouilleurs.

Ideawipik (discutercontributions)

@Nemo Le Poisson. Les grands esprits se rencontrent. Une section y est déjà ouverte. Tout comme une annonce sur la page de discussion d'un des modèles : Discussion modèle:Contributions rémunérées#Problème avec la signature intégrée. S'il n'y a pas d'opposition, je prendrais l'initiative de retirer les paramètres et d'adapter les documentations.

Sont concernés les quatre modèles listés ci-dessus et potentiellement des sous-pages de Modèle:Huggle (notification à FDo64, créateur de cette page), voire la configuration de l'outil. Pour ces derniers, il n'y a pas de paramètre mais parfois des signatures automatiques placées dans des cadres ou tableaux.

FDo64 (discutercontributions)

@Ideawipik. Pour information, {{Huggle}} n'est utilisé que dans la documentation des sous-modèles. Donc aucun souci avec lui.

J'ai fait une recherche de insource:/"~~<noinclude"/ dans l'espace modèle et parmi les 55 réponses, les suivantes semblent également concernées :

  1. {{Avertissement fusion}}
  2. {{Huggle/block-indef}}
  3. {{Huggle/warn-test-1}}
  4. {{Huggle/warn-test-2}}
  5. {{Huggle/warn-test-3}}
  6. {{Invitation projet Finance}}
  7. {{Invitation projet Libéralisme}}
  8. {{Invitation projet Séries télévisées}}
  9. {{LSV entête}}
  10. {{Nouveau psycho}}
  11. {{Transparence}}
Trizek (discutercontributions)

Bonjour

Au risque de répéter cette question que je pose depuis qu'on a mis des cadres autour des messages : qu’apportent ces cadres aux messages ?

Les cadres n'apportent rien, à part que les novices croient qu'il s'agit de messages automatiques. Il n'y a pas besoin d'un cadre pour rendre un message officiel, d'autres options sont possibles (un bon titre, un texte clair, une icône...).

Pour info, les DRP étaient mises en page avec des cadres et cela été changé récemment, car, au final, il n'y avait aucune plus-value. Retirer les cadres a permis d'augmenter les réponses faites au bon endroit.

J'attends avec impatience la fonctionnalité forçant la surveillance d'une section. Pour les DRP, elle permettrait aux novices de ne pas louper une réponse ; pour les bandeaux déposer par une personne qui patrouille, elle permettrait de ne pas louper une demande d'explications.

Ideawipik (discutercontributions)

Bonjour @FDo64, merci pour les compléments. J'en avais vu certains autres mais ils n'étaient pas vraiment destinés à obtenir une réponse comme Modèle:Récompense pour un élève/Fourmi et équivalents. Le modèle:LSV entête n'attend pas de réponse.

Merci @Trizek de partager ton interrogation. J'adhère à l'idée de "sortir du cadre". J'irais même plus loin. Se contenter des sections et retirer les modèles de type {{DRP fin}}. Cela éviterait

  1. de devoir mettre dans le wikicode des tonnes de commentaires tels que <!-- répondre en dessous de cette ligne (pour que ça arrive au même endroit via l'éditeur ou via le lien répondre --> [sic], vu dans la page actuelle entre deux messages, ou le courant <!-- Ne pas modifier les lignes suivantes ni écrire en dessous, merci. -->
  2. d'obliger les opérateurs à contrôler régulièrement la présence de messages sous le modèle de fin. C'est encore moins facilement repérable sans le cadre.

Cela simplifierait la réponse pour tous, en particulier les moins expérimentés. La seule chose qui demanderait éventuellement une évolution aurait pu être la méthode d'archivage par bot. Mais, dans le code du bot sur github, bien que soit défini le nom du modèle de fermeture, ce dernier n'est pas utilisé. Le bot archive déjà la section (de niveau « == ») toute entière. Donc à priori pas de souci de ce côté là.

Le seul intérêt actuel de ces modèles de fin est l'insertion d'une balise d'affichage des références, au cas où. Mais le rapport inconvénient bénéfice est assez faible. Ainsi, parmi les 70 sections de la page des DRP actuelle, une seule section contenait une référence, et encore… juste après un message d'erreur de balise </ref> manquante (correction). Les requérants ont l'habitude de mettre les liens directement dans le texte ce qui est logique, les sources étant à la base de la discussion en DRP. L'usage ponctuel d'un {{Références discussion}} conviendrait. Dans les autres pages de requêtes (DIMS, DIPP, DPH, DPP, DR, RA, RCU), on a également rarement besoin de solliciter des références en notes. Pour avis, @Od1n (Spécial:Diff/153014320). La question concerne la pratique future. Elle devrait être soumise plus largement aux patrouilleurs et admins ou à tous via un petit sondage. Pour la lisibilité des archives, on pourrait très bien conserver le modèle mais ne plus l'utiliser en "production".

Bonjour @El pitareio. Question connexe à propos du bot d'archivage : quid de la gestion des titres de sections en double dans une page ?
Bien à vous

Trizek (discutercontributions)

Techniquement, plus que la position de la signature, ce qui pose problème avec le cadre, c'est qu'il est souvent lié à un modèle. C'est le cas pour les modèles de patrouille. Or le système de réponse ne peut pas (encore ?) détecter qu'un morceau de wikitexte dans un cadre ou encadré par des <div> est la pleine partie d'un message. Sortir la signature aide à faire comprendre au système qu'il y a bien eu message, mais sans donner l'opportunité à Mediawiki d'apporter la structuration progressivement mise en place pour identifier ce qui fait partie d'un seul et même message.

Concernant {{DRP fin}}, il a effectivement été conservé pour insérer un moyen de collecter les notes de bas de page. Et c'est tout : il n'insère pas le cadre que l'on avait avant. Tant qu'on n'aura pas un vrai formulaire avec des champs séparés pour chaque élément demandé, on ne pourra pas empêcher les gens qui ne lisent pas les consignes de nous balancer leur article. Et pour gérer les DRP de temps à autre, toute maintenance qu'on peut s'éviter est bienvenue ! :)

Side note : DRP était un test avant de mettre en place une généralisation à DIMS, DIPP, DPH, DPP, DR, RA, RCU et co (ce qui, à mon avis, ne nécessite pas de consultation, car c'est de la maintenance de bon sens).

El pitareio (discutercontributions)

Pour les titres de section en double, je dirais que le bot ne traite que la première. Sur DRP, elles sont en général assez vite renommées. Le cas doit quand même se produire de temps à autre et je n'ai pas souvenir que ça ait posé problème.

Pour le modèle {{DRP fin}}, s'il apporte plus de problème qu'il n'en résout, autant s'en débarrasser effectivement.

Habertix (discutercontributions)

Pour les DRP, je regrette la disparition du cadre qui permettait de colorer l'ensemble de la demande ; c'était plus pratique pour connaître rapidement son état d'avancement. Puisque je n'y interviens quasiment jamais, pas besoin de revenir en arrière Émoticône.

Par contre, j'aimerai garder la coloration de l'ensemble d'une RA et les autres pages accueillant des demandes à rallonge.

@El pitareio est-ce vous pouvez donner la longueur moyenne des requêtes archivées par NaggoBot (par type RA/DRP/DIPP/DPH/....)  ? Merci.

Trizek (discutercontributions)
Répondre à « Incompatibilité de la fonctionnalité de réponse rapide avec les signatures dans des messages encadrés »