New requirements for user signatures/fr

De nombreux wikis ont des règles encadrant les signatures personnalisées des utilisateurs. L'Editing team souhaite obtenir votre avis sur une proposition visant à codifier certains de ces besoins dans le logiciel de Wikipedia. Il sera ainsi plus simple de répondre aux messages spécifiques sur les pages de discussion et d'utiliser d'autres outils.

Vous trouverez ci-dessous plus de détails sur ce qui est proposé et pourquoi :


 * Sur quoi l'équipe souhaite obtenir un avis : Contribution : votre avis
 * Pourquoi ces changements sont proposés : Contexte : pourquoi ces changements ?
 * Quels changements sont proposés : Proposition : conditions de validation d'une signature
 * Comment ces changements pourraient vous affecter : Incidence : effets du changement

Si aucun obstacle important n'est identifié, ce changement pourrait intervenir en avril 2020. Si l'équipe doit apporter des changements importants suite à vos avis, cela prendra plus de temps.

Partagez votre expérience
L'équipe souhaite connaître votre avis sur cette proposition.

Veuillez partager vos remarques concernant ces questions sur la page de discussion :


 * 1) Ces conditions de validation d'une signature créeraient-elles des problèmes sur votre wiki ?
 * 2) De quoi l'équipe devrait-elle être consciente avant de procéder à ce changement ?
 * 3) Que faire des signatures existantes qui ne respectent pas les nouvelles conditions ? Par exemple, doivent-elles être rejetées ?

Ne vous sentez pas limité par les questions ci-dessus. L'équipe souhaite lire toutes les remarques que vous avez à partager.

Contexte : pourquoi ces changements ?
En 2019, les bénévoles des 20 projets Wikimedia et des groupes d'utilisateurs, ainsi que des employés de la Wikimedia Foundation, ont participé à la consultation sur la communication. Il s'agissait de déterminer de meilleurs outils pour discuter.

Cette consultation a notamment débouché sur la demande d'un moyen plus facile pour répondre à des messages spécifiques sur les pages de discussion.

Pour que cette fonctionnalité fonctionne correctement, le logiciel doit disposer de signatures lisibles par le logiciel, afin de pouvoir détecter de manière fiable les messages des utilisateurs et permettre d'y répondre.

Le problème est que, bien que de nombreux wikis aient déjà mis en place des règles pour les signatures, ces exigences ne sont pas vérifiées par le logiciel lui-même. Cela accroît les possibilités qu'une personne appose une signature qui enfreint les règles du wiki et pourrait rendre plus difficile la participation aux discussions.

Cette cohérence supplémentaire dans le format des signatures améliorerait les fonctionnalités existantes, comme les notifications, qui ne sont envoyées que si votre signature peut être détectée dans votre message.

Proposition : critères de validité d'une signature
Les trois vérifications proposées sont décrites dans cette section. Elles seraient appliquées aux signatures des utilisateurs dans les préférences lorsqu'un utilisateur enregistre une signature modifiée. Selon la proposition de l'équipe Editing les signatures existantes ne seront *PAS* affectées.

Interdire certains usages invalides en HTML et ceux identifiés par les erreurs Linter
Plus important encore, ce changement interdirait les balises de formatage non fermées, comme ou la balise wikitext correspondante, , sans balise de fermeture correspondante (dans ce cas,  ou  , respectivement). Les signatures contenant des balises non valides peuvent affecter l'ensemble d'une page de discussion, lorsque le formatage se poursuit dans les commentaires suivants.

La vérification identifierait également les misnested tags, comme $exemple (les deux balises, ou les deux balises  , devraient être à l'extérieur), et stripped tags, qui sont des balises de fermeture sans balise d'ouverture correspondante (le contraire de la « balise de formatage non fermée » mentionnée ci-dessus).

Les signatures qui contiennent des problèmes moins critiques seraient également refusées, par exemple les balises HTML obsolètes comme  et . Bien que ces balises ne causent pas de problèmes immédiats, cela préviendrait de la propagation de code obsolète aux nouvelles pages du wiki, ce qui est gênant pour les éditeurs qui doivent nettoyer les erreurs Linter.

Une liste complète des fonctionnalités syntaxiques qui ne seraient pas autorisées, ainsi que des liens vers des pages qui expliquent comment mettre à jour ou corriger du code avec des erreurs de Linter, est disponible à cette adresse.

Les balises de formatage non fermées étaient déjà censées être empêchées par le logiciel, mais en raison des limitations de l'analyseur de wikitext actuel, cela n'a fonctionné que dans certains cas. Une solution plus robuste est devenue possible grâce à Parsoid.

Exiger un lien vers la page de l'utilisateur, la page de discussion ou les contributions
Divers outils ne fonctionnent pas correctement lorsqu'une signature ne contient pas au moins un des liens suivants : un lien vers la page de l'utilisateur, la page de discussion de l'utilisateur ou la page des contributions. Par exemple, les notifications de type « mention » ne sont pas envoyées, et les prochains Outils de discussion ne permettront pas de répondre aux commentaires avec ces signatures non valides. Les gadgets et autres outils qui interagissent avec les signatures peuvent également ne pas fonctionner comme prévu.

Cette exigence est présente depuis longtemps dans les politiques de nombreux wikis de Wikimedia, mais elle n'a pas été appliquée par le logiciel MediaWiki.

Interdire la substitution « imbriquée » dans une signature
Certaines utilisations de la balise subst: et des tildes seraient également interdites dans les signatures. Auparavant, il était possible d'utiliser ces fonctionnalités pour définir une signature qui ferait apparaître le nom d'un éditeur ultérieur sur vos commentaires. Toutes les formes de falsification de signature ont longtemps été interdites par la politique des grands wikis, et ce type de falsification sera désormais empêché dans les logiciels. L'utilisation unique de subst: est toujours autorisée.

Qu'adviendrait-il des signatures existantes ?
Toute signature existante qui deviendrait invalide en vertu des nouvelles règles est toujours autorisée (clause d'antériorité). En consultant vos préférences, vous verrez un message d'avertissement et si vous essayez de changer la signature, la nouvelle signature doit être valide. Mais si vous ne la modifiez pas, l'ancienne signature invalide continuera d'être utilisée lors de la signature de votre message, et vous pourrez modifier vos autres préférences sans que cela n'ait d'incidence.

Nous aimerions savoir si vous souhaitez que les signatures invalides existantes soient interdites. Si une signature invalide est interdite, une signature par défaut serait insérée lorsque l'utilisateur signe ses messages, jusqu'à ce qu'il corrige sa signature personnalisée.

Quand ces changements pourraient-ils avoir lieu ?
Veuillez envoyer vos commentaires avant le 31 mars 2020. L'équipe d'Edition prendra ses décisions concernant ce projet début avril. Les résultats seront affichés sur la page de discussion.

Si aucun problème important n'est identifié, ce changement n'interviendrait pas avant avril 2020. Cette date pourrait être repoussée si l'équipe doit implémenter des modifications importantes suite à la réception de votre avis.

Comment saurons-nous quels sont les changements en cours ?
Nous publierons un autre message dans le Tech/News lorsque ce changement sera sur le point d'être mis en œuvre.

À quoi peuvent ressembler les erreurs lors de la validation de la signature ?
Les erreurs HTML/Lint comprennent des liens vers la documentation existante, telle que Help:Extension:Linter/missing-end-tag, et un bouton pour mettre en évidence la partie problématique de la signature.

L'erreur pour le lien requis dans la signature propose des exemples de syntaxe à utiliser.

Résultats
La proposition a été largement acceptée. En réponse aux commentaires des contributeurs, quelques petites modifications ont été apportées et quelques points ont été clarifiés.


 * 1) Interdire certaines parties en HTML non valides ainsi que d'autres erreurs  Linter
 * L'objectif de ces modifications sera réduit. Les balises mal imbriquées et balises vides seront rejetées.  Certaines erreurs de faible priorité seront tout de même acceptées. Plus précisément, les balises HTML obsolètes comme   et   ne seront pas interdites pour le moment.  Cette décision ne préjuge pas de toute décision future en faveur ou en défaveur de la suppression de ces balises HTML obsolètes.
 * 1) Nécessite un lien vers la page utilisateur, la page de discussion ou les contributions
 * Ceci sera implémenté comme prévu initialement.
 * Par souci de clarté, il doit y avoir au moins un lien local direct (et non une redirection, par exemple à partir d'un ancien nom d'utilisateur) vers l'une de ces pages. Ainsi, une signature comme  serait acceptable (un lien direct local, un lien vers un autre projet frère), mais une signature qui inclut seulement des liens vers un autre wiki, ou seulement des redirections à partir d'un ancien nom d'utilisateur sera invalide.  Ceci, pour des raisons techniques.
 * 1) Interdire la substitution « imbriquée » dans la signature
 * Ceci sera implémenté comme prévu initialement.

Le processus pour implémenter cette modification est :


 * ✅ Une annonce générale sera faite dans une édition du Tech News lorsque les nouvelles exigences entreront en vigueur.
 * ✅ Une fois le changement de logiciel effectué sur les serveurs, les contributeurs ne pourront plus enregistrer de signatures personnalisées non valides. Toutefois, les signatures existantes seront conservées.
 * Les contributeurs actifs dont les signatures ne sont pas valides seront encouragés à modifier leur signature. Ce processus prendra probablement quelques mois.
 * À terme, toutes les signatures devront être conformes. Si les contributeurs ne corrigent pas leurs signatures personnalisées, celles-ci cesseront de fonctionner et la signature par défaut apparaîtra à la place.

Les wikis tiers pourront activer ce changement manuellement.