Sujet sur Discussion utilisateur:Golmote/Structured Discussions Archive 1

Bonjour Golmote, après les {unité} injustifiés hier, je comptais m'attaquer dans cet article aux dates aujourd'hui, mais je vois que c'est fait ! À ce propos, j'aimerais être fixé sur la politique « officielle » en la matière : quand je suis à m'occuper de (petites) choses et d'autres sur une page, si je m'aperçois que celle-ci est pleine de {date| et de LI d'années, je m'en colle une copie dans LibreOffice et je nettoie tout ça vite fait : outre le remplacement instantané des {date| en {date-| on peut utiliser des expressions régulières, et un rechercher-remplacer de la forme \[\[(\d{4})\]\] → $1 enlève tous les crochets des années (ici à quatre chiffres) en un clic, plus qu'à recoller la nouvelle version à la place de l'autre (en vérifiant avant que personne n'y a touché entre-temps !) ; c'est plus efficace que wikEd. Je ne garde dans ces cas que les dates du RI (naissance etc.) : est-ce que c'est casher comme pratique, ou bien y a-t-il des articles où il est inapproprié de virer ces liens date & année ? Je ne parviens pas à trouver de doc qui soit très affirmative pour ces deux cas...
Bien cordialement, -- jilucorg → ✉ 28 janvier 2022 à 09:19 (CET)

Bonjour Jilucorg. Tu tombes bien, je comptais justement t'écrire par rapport à ta modification. J'en reparle plus bas.

A ma connaissance, il n'existe effectivement pas de règle claire et nette indiquant quels liens de date doivent être conservés ou retirés. C'est un débat qui a eu lieu à de nombreuses reprises et de ce que j'en comprends, on en revient toujours à la même recommandation : il faut juger de la pertinence du lien. Voir également Liens et contribution à la cohérence d'ensemble de l'encyclopédie.

Mais pour être honnête, c'est un sujet que j'évite au maximum. Personnellement, quand je wikifie les dates, j'utilise {{date}} si au moins une partie de la date était un lien et {{date-}} sinon. C'est imparfait (car ça ajoute des liens sur les jour et mois, même quand la date originelle ne liait que l'année par exemple) mais c'est le juste milieu que j'ai trouvé. (Si tu veux plus de finesse dans la gestion des liens générés par {{date}}, j'ai lancé l'idée sur la PDD du modèle, mais elle est passée assez inaperçue pour l'instant, semble-t-il. Il faudrait sans doute que je relance l'idée dans le Projet Modèle.)

Bref, je crois que la réponse est « ça dépend du contexte ». Retirer sans réfléchir tous les liens de date n'est sans doute pas recommandable.

Sinon, pour revenir à ta modification d'hier, je me suis interrogé sur sa pertinence en passant sur l'article. Autant je te rejoins sur l'inutilité de {{unité}} dans un cas comme {{unité|300|millions}}, autant lorsque le substantif est effectivement une unité abrégée, le modèle ajoute une infobulle qui justifie selon moi son utilisation. Un cas comme {{unité|12 ch}} apporte une information en indiquant à l'utilisateur que l'on parle de cheval-vapeur.

Par ailleurs, malgré le paragraphe sur {{nobr}} de WP:CCN#INSÉCABLES et la documentation de {{unité}}, certains^[Qui ?] disent qu'il est inutile de chercher à « optimiser » les appels de modèle ainsi (je ne retrouve pas de source, désolé, je me souviens juste avoir vu passer ce genre de propos par le passé ; j'éditerai si je retrouve).

Enfin, dans ta modification d'hier, tu as aussi remplacé certains {{nobr}} par {{unité}} (on pourrait penser que tu as remplacé les uns par les autres et les autres par les uns ?). Je pense qu'il s'agit d'un accident. ^^

Merci pour ton message. Bonne continuation !

Merci Golmote pour cette réponse détaillée, et pour tes remarques ! Je viens de regarder la PDD où tu es intervenu, j'avoue ne pas comprendre certains modèles qui multiplient les liens jour-mois-année en automobile, au cinéma etc., ni d'ailleurs tout simplement tous ces liens de date : les gens regardent vraiment les cibles de ces liens quand ils lisent un article tout bleu ? Par exemple dans l'article sur Spirou on peut lire : « Le 28 mars 1957, Spirou sort son n^o 1000 » Donc je clique sur '28' : chouette, je sais qu'en -58 le peuple helvète commence sa migration pendant la guerre des Gaules ; clic sur 'mars', bingo : en mars 1957 Rejet de la Constitution Lyttleton par les Noirs au Kenya ; clic sur '1957' (en bande dessinée) : Début de la série des Aventures de Tonton Eusèbe par J. Lebert... Moi qui m'intéressais à l'histoire de Spirou, que m'apportent ces trois liens pour une seule date ?
Dans le passage que tu mentionnes (que j'avais déjà lu plusieurs fois attentivement, il y a : « Les liens internes (vers d'autres articles de Wikipédia) sont à choisir avec parcimonie. » et « le consensus est qu'il n'existe que des cas très limités où la liaison des dates est souhaitable » : alors quoi ? Je t'avoue que j'ai bien de la difficulté à faire la différence entre ce qui est Bien et ce qui est Mal pour la communauté WP dans ces domaines, et je finis par me sentir totalement illégitime à faire du nettoyage d'articles « bleus », avec la menace immanente de me faire reprocher ce nettoyage – qui à moi simple utilisateur paraît pourtant de l'hygiène minimale et du respect pour le lecteur. Mon épouse avec qui j'en parlais récemment me disait qu'elle renonce bien souvent à lire des articles remplis de bleu, comme moi elle trouve ça illisible.
Je vais cesser de m'occuper de ces liens pour l'instant, tant qu'il n'y a pas un minimum de consensus clair, la restauration des liens rouges à laquelle je me suis attelé en parallèle me convient bien car peu susceptible de débat voire de réprimandes... J'avais entrepris de corriger la syntaxe des anciens articles labellisés, et j'ai pu constater que beaucoup sont tout bleuis de dates et d'années : ils l'étaient déjà au moment de leur labellisation, alors OK...
Pour l'affaire des {unité} comme km – et de pourquoi inversement j'ai quelquefois transformé certains {nobr} en {unité} – je vois que tu as déjà lu mon point de vue chez @Vega : ce n'est que le mien, petit novice qui marche sur la pointe des pieds, mais je sens que ça aussi c'est un domaine aux usages trop mystérieux et trop imprécis pour moi, que je vais donc abandonner en attendant un consensus clair. [Sauf que ça me fera un tout petit peu mal au ventre, because j'ai tout récemment pris vraiment conscience que ne pas chercher à optimiser les appels de modèles inutiles c'est vraiment incohérent avec toute prétention écologique, quand on sait ce que ça produit d'envoyer des requêtes à des serveurs et de les faire travailler – inutilement dans ce cas – à chaque ouverture de page, à coup de millions de requêtes qui traversent l'Atlantique dans les deux sens comme pour WP : il ne s'agit pas de faire faire des économies à la Fondation, mais d'œuvrer modestement pour un tout petit peu de sobriété numérique quand on peut, IMHO...]
Pardon d'avoir été trop long. -- jilucorg → ✉ 28 janvier 2022 à 15:37 (CET)

Oui, les liens de date sont tout un autre débat, mais tout aussi enflammé que les espaces insécables des nombres. J'espère qu'à terme, on trouvera une solution élégante pour avoir un réel contrôle sur les liens des dates sans pour autant devoir renoncer à leurs typographie et sémantique.

Également, j'ai retrouvé plus ou moins la source de mon propos sur la performance : WP:PERF, tout simplement.

Techniquement, les modèles ne sont de toute façon pas exécutés à chaque affichage d'article. Wikipédia dispose de mécanismes de mise en cache qui permettent de ne pas constamment faire appel aux modèles sans raison. Le nombre de visites par mois n'est donc pas selon moi un argument ultra pertinent.

En tout cas, il ne faut pas que l'absence de consensus ou de règle limpide te freine dans tes envies de ménage. N'hésite pas ! Le pire qui puisse arriver est un revert.

J'étais tombé, à force de chercher des réponses à mes interrogations, sur cette page WP:PERF, mais ça n'est pas la préoccupation mentionnée, je ne suis pas inquiet pour la capacité des serveurs de Wikimedia Foundation, Inc. à supporter la charge, ils sont visiblement bien dimensionnés. Cependant si effectivement il y a des gros gros caches bien configurés pour les appels de modèles alors c'est une autre musique.
Mais je n'ai pas (plus) envie de faire à mon idée ici, pour les dates ni le reste. Déjà, aussi, pour avoir tenté de rectifier des balises de commentaire mises n'importe comment – ce qui m'avait semblé sans danger – j'ai eu un revert très sec, et je ne sais toujours pas comment ça s'explique malgré ma demande aimable [aimable au point que je n'ai pas voulu demander par la même occasion pourquoi il avait aussi posé un {{formatnum:962}}...] : si même un truc qui pourrait sembler techniquement pur ça peut clasher, alors... (c'est là et là ). Je pense que le projet Lien rouge + l'orthographe et la ponctuation des articles qui m'intéressent, en mettant des {nobr} quand c'est béton de chez béton, ça fera bien mon affaire. -- jilucorg → ✉ 29 janvier 2022 à 00:17 (CET)

J'avais vu passer cet article dans la liste de l'erreur 5. On est clairement dans le cas d'un faux-positif en fait. WPCleaner estime que -- > est une fermeture de commentaire invalide (à raison !) mais elle est ici tout à fait intentionnelle : sans cette espace le commentaire qui masque tout le tableau ne fonctionnerait pas correctement (car les commentaires ne peuvent pas être imbriqués).

Erf... la façon de faire est un peu sèche en effet, mais ne prends pas le revert ou l'absence de réponse personnellement. Chacun a sa façon de contribuer et de communiquer.

Ah OK, merci Golmote ! Ça me confirme dans mes intentions : je ne toucherai plus à ce genre de machins si une faute de code aussi basique doit être faite pour que la page fonctionne.
-- jilucorg → ✉ 29 janvier 2022 à 09:38 (CET)

Hello, je réponds à l'invitation pour parler ici de dates (mais je garde les nombres sur ma PdD pour ne pas croiser les discussions).

Donc je partage entièrement l'argumentaire de jilucorg (et de son épouse, et de ses poules) sur les dates en bleu. Wikipédia:PLI dit bien « Concernant les dates, il n’est pas indispensable de créer un lien pour une année sauf si cela apporte un élément pertinent à l’article. » Alors perso, j'élague sans trop de scrupule et on ne me l'a jamais reproché, si ce n'est que « {{date-|01/01/1901|en astronomie}} n'aurait aucun intérêt par rapport à {{date-}} », seul cas que je laisse donc en place, dans le doute.

Golmote, la reco dont tu parlais est sans doute Wikipédia:Ne vous préoccupez pas de performance. Elle met la priorité sur la contribution, ce qui est compréhensible, mais n'interdit pas l'optimisation aux contributeurs consciencieux. Un admin s'est d'ailleurs livré à des tests de charge de serveur sur les modèles de nombres, dans une conversation (que je ne retrouve plus).

PS : nos messages se sont croisés, c'était donc bien WP:PERF. J'ignorais l'existence du cache de WP, qui limiterait effectivement la casse.

Oui, je pense que le remplacement de {{date}} en {{date-}} est globalement une opération consensuelle. On croisera toujours des pcW qui estiment que tel ou tel lien est effectivement pertinent, et alors il suffirait de faire une exception pour celui-ci.

(Jamais trop trop compris l'intérêt des domaines (en astronomie, etc.) en dehors évidemment d'un éventuel article historique sur le sujet. M'enfin !)

Côté perf, tu fais sans doute référence aux tests de Ideawipik (qui n'est pas admin je crois, mais ça ne change rien) ici ?

Dans tous les cas, soyons clairs : je vous rejoins sur le principe même. Oui, la performance c'est important. Je dis juste qu'il y a de nombreuses façons de remédier aux problèmes de perf et que les développeurs de MediaWiki ont tout un attirail de possibilités d'actions de leur côté aussi. (Je n'ai pas de connaissances avancées du fonctionnement du cache de WP, je sais juste qu'il existe puisqu'il peut être purgé manuellement sur un article. Et sans ça, je pense que WP aurait explosé depuis longtemps haha !)

C'est donc très bien que les pcW aient une sensibilité à ce sujet. Pour autant, il est sans doute vain de dépenser trop d'énergie (humaine) pour lutter contre des {{unité}} « mal » utilisés. Si vous en croisez lors d'une autre opération, corrigez-les, mais je pense qu'il n'est pas raisonnable de chercher à les éradiquer. ^^