Discussion modèle:Lien brisé

A propos

de ça. Je dégage la possibilité d'utiliser "auteurs", coauteurs et toute la panoplie. Pourquoi ? Parce que ce modèle a visiblement été fait un peu trop rapidement : quand l'un de ces paramètres est fourni, la syntaxe utilisée est celle de {{Lien web}}, sans afficher le rouge ni les liens en cache.

En gros avant la modif', {{Lien brisé|url=http://example.com|titre=exemple|auteur=Dalaï lama}} affichait {{Lien web|url=http://example.com|titre=exemple|auteur=Dalaï lama}}, maintenant il affiche {{Lien brisé|url=http://example.com|titre=exemple}}.

Moi je pense que ne pas supporter tous les paramètres de lien web n'est pas grave tant que ça ne lève pas d'erreur: quand un éditeur voit un "Lien web" qui ne marche pas, il transforme "lien web" en "lien brisé" en gardant les paramétres. Le fait qu'il y ait des paramètres provenant de {{lien web}} et non utilisés par {{lien brisé}} ne pose pas de problèmes. Maintenant si un autre arrive plus tard, et corrige le lien vers disons, la nouvelle adresse, il corrige le paramètre url, et "Lien brisé" en "lien web", tous les autres paramètres sont gardés, on retombe sur nos pieds.

Après si quelqu'un considère que ce modèle doit être aussi complexe que {{lien web}}, qu'il s'attèle à la tâche . Moi, je me fiche des fonctionnalité complexes, tant que le simple {{lien brisé|url=pouet}} est supporté.

NicDumZ ~ 20 octobre 2008 à 12:53 (CEST)

date illisible

Apparemment, depuis récemment, le modèle affiche la date à laquelle le lien a été constaté comme brisé sous la forme 20130319. Ce n'est pas très convivial pour dire le moins. En plus, ça me paraît générer de la confusion : lorsqu'on utilise date à l'intérieur de lien web, il s'agit de la date à laquelle la page web a été publiée. Comme ceci : {{lien web |url=http://exemple.com |titre=titre |site=exemple.com |auteur=Gérard Manvussat |date= 27 mai 2012}} rendu ainsi : Gérard Manvussat, « titre », sur exemple.com, 27 mai 2012

Ici, date devient la date à laquelle le bot a détecté le lien brisé si je comprends bien. Par ailleurs, une autre discussion, ici Discussion_utilisateur:JackPotte#Format_de_date_pas_.22human_readable.22_pour_lien_bris.C3.A9, montre qu'en fait c'est le paramètre consulté le qui est modifié (à la place ou en plus de date). --Vincent.vaquin (d) 19 mars 2013 à 12:44 (CET)

Voilà comment je l'utilisais avant que tu soulèves de manque de précision : quand j'ajoute {{lien brisé}} (manuellement ou par bot), je ne garde aucun paramètre sauf l'URL et le titre. Peut-être que nous pourrions en conserver plus (éditeur, page) mais consulté le n'a plus de sens dans un nouveau modèle. Si on ajoute un truc du genre constaté brisé le je ne vois pas ce que cela apporterait.

De plus concernant le format de ces dates, il est difficile de l'uniformiser avec les autres modèles quand les docs de {{Lien mort archive}} et {{Lien web}} prônent des formats différents. Je dirais que tout dépend si elles servent à catégoriser. Un format tel que celui de {{Lien mort archive}} permettrait de classer les pages Catégorie:Article contenant un lien mort chronologiquement. JackPotte ($♠) 24 mars 2013 à 13:21 (CET)

1. Quant à moi, lorsque j'appose {{lien brisé}} manuellement, je conserve TOUS les paramètres...
2. Consulté le est une date à laquelle le lien a été consulté par un humain. Le paramètre constaté brisé le apporterait ce que tu souhaites toi-même apporter lorsque tu modifies consulté le par bot ; à toi de dire à quoi ça sert. En tout état de cause ce n’est pas consensuel.
3. Dans lien mort archive, la date bizarroïde n'est pas affichée. On voit au contraire des règles typo respectées : « version du 7 janvier 2005 »

--Vincent.vaquin (d) 24 mars 2013 à 13:40 (CET)

Le fait de conserver tous les paramètres des différents modèles de liens pose non seulement le problème de leur absence ici, mais en plus certains sont contradictoires (work=périodique dans {{article}}, et série dans {{lien web}}). A moins d'avoir un vote plus clair je ne te rejoindrai pas sur ce point. Et à propos de la date de consultation que j'ajoute à {{lien brisé}}, je ne modifie jamais celles de {{lien web}}, {{article}} ou autres puisqu'ils n'ont plus de raison d'être en l'état, et que certains modèles de liens n'ont peut-être pas ce paramètre. JackPotte ($♠) 24 mars 2013 à 14:23 (CET)

Enfin, la fonction de format de date de {{Lien mort archive}} pourrait être utilisée ici aussi, si cela ne brouille pas les formats existants dans nos articles. Cela permettrait d'afficher les mois en toutes lettres au lieu de jongler avec des "aout, août et August". JackPotte ($♠) 24 mars 2013 à 14:35 (CET)

En ajoutant #time:j F Y les dates apparaissent en clair, il y a quelques erreurs facilement corrigeables. Ensuite nous pourront aisément classer les liens en fonction de ces dates lisibles et uniformisées. JackPotte ($♠) 24 mars 2013 à 14:53 (CET)

Je ne comprends strictement rien à tout cela. Que vient faire l’argument concernant work dans périodique et série dans lien web ? Ici, fait en sorte que ton bot remplace lien web par lien brisé et qu'il ne touche pas au reste. C'est quoi le problème ?

Par ailleurs, c'est toi qui veux créer une catégorie du style "brisé depuis le". Et bien fait-le mais :

1. sans modifier le paramètre consulté le car ce n'est pas consensuel
2. c'est contraire à ce que dit la documentation (il faudra la corriger en tout état de cause)
3. la date affichée est illisible ; donc ne touche pas à consulté le ça t'éviteras d'avoir à jongler avec des trucs et des machins.

En bref, remplace lien web par lien brisé, ne touche pas aux paramètres remplis par les humains, et crée un paramètre, invisible tant qu'à faire, te permettant d'alimenter ta catégorie et qui pourra être aussi moche que tu veux dans la mesure où tu ne l'affiches pas.

--Vincent.vaquin (d) 24 mars 2013 à 15:08 (CET)

Le présent modèle {{Lien brisé}} sert à toutes URL ne répondant plus ou une erreur, cela s'applique aussi bien pour celles de {{article}} que celles entre crochets. Cette information est dans la documentation, et le cahier des charges du travail à faire depuis plusieurs mois : Wikipédia:Bot/Requêtes/2012/11. JackPotte ($♠) 24 mars 2013 à 15:17 (CET)

Et ? qu'est-ce qui empêche de remplacer lien web (et les autres) par lien brisé et de ne pas toucher au reste ? --Vincent.vaquin (d) 24 mars 2013 à 15:31 (CET)

J'ai déjà répondu à cette question ci-dessus. JackPotte ($♠) 24 mars 2013 à 16:13 (CET)

Non, désolé. Je ne vois aucune justification de ta part au fait de modifier consulté le que ce soit pour lien web ou pour tout autre modèle. --Vincent.vaquin (d) 24 mars 2013 à 23:43 (CET)

Plus précisément, voici comment je te l'ai répété différemment sur ma PDD : mon bot ajoute (ne modifie pas) "consulté le" tout comme je le fais manuellement (donc consensus de la doc) aux liens brisés qu'il identifie, que ce soit dans des URL entre crochets ou dans des modèles (peu importe qu'il s'agisse de "lien web" jusqu'à preuve du contraire), ces modèles étant remplacés leurs paramètres n'ont plus de raison d'être : laisser une date de consultation d'un site qui marche dans {{lien brisé}} induirait en erreur, car généralement il s'agit de celle depuis quand on a constaté qu'il ne fonctionnait pas, comme quand on le fait pour les URL hors modèles. JackPotte ($♠) 25 mars 2013 à 00:52 (CET)

Note de 2023 : brisé le indique la date de détection du lien comme mort.

La conservation du paramètre consulté le (date où l'URL était OK quand {lien web}) permet de retrouver une archive web à une date voisine : c'est important avec l'horodatage Internet Archive, les cas de cybersquattage, etc. — Irønie (d) 28 novembre 2023 à 20:05 (CET)

Erreur pas corrigée et modifications non consensuelles et non concertées

Bonsoir, sur l'article Allosaurus[1], le JackBot a, aujourd'hui, transformé ceci :

{{lien web|langue=en |url=http://www.dinosauria.com/dml/names/dinoa.htm |titre=''{{lang|en|Dinosauria Translation and Pronunciation Guide A}}'' |auteur=Ben Creisler |date=7 juillet 2003 |éditeur=Dinosauria On-Line}}

en ceci :

{{lien brisé|consulté le=2013-03-25|url=http://www.dinosauria.com/dml/names/dinoa.htm|titre=''{{lang}}

répétant le problème que tu disais pourtant résolu de |titre={{lang}}, syntaxiquement incorrect qui catégorise la page dans la Catégorie:Page avec code de langue invalide.

J'ajoute que le bot ajoute consulté le alors que ce n'est pas consensuel, certains préférant que ce paramètre ne puisse être rempli que par un humain (ce qui est différent de le faire humainement à la main). J'ajoute qu'on perd des informations, en la circonstance l'auteur et la date, qui seraient pourtant utiles pour retrouver la référence et restaurer ou remplacer le lien. Je me permets d'insister pour que les interventions du bot conservent les paramètres entrés par les humains et que consulté le soit remplacé par testé par bot ou équivalent.

Le modèle a été modifié sans annonce préalable sur cette page de discussion ce qui est contraire aux usages. Vincent.vaquin (d) 25 mars 2013 à 21:21 (CET)

Il s'agit d'un bug légèrement différent du précédent, je travaille actuellement à localiser s'il en existe d'autres sur le site. Le reste de ce paragraphe est la répétition du précédent. JackPotte ($♠) 25 mars 2013 à 21:45 (CET)

Et oui, répétition dont tu ne veux pas tenir compte, c'est bien cela ? --Vincent.vaquin (d) 26 mars 2013 à 00:12 (CET)

Je croyais sincèrement y avoir bien répondu. Je repatcherai mon bot s'il s'avère qu'un consensus modifie la documentation pour conserver les paramètres les plus pertinents quand {{lien brisé}} remplace un autre modèle de lien (mais tous les paramètres me semble techniquement impossible en l'état). JackPotte ($♠) 26 mars 2013 à 00:18 (CET)

problème avec le modèle

Bonjour, j'ai vraiment des soucis avec le modèle... Pourquoi cela, dans cet article Ólafur Jóhannesson (entraîneur) :

{{lien brisé | titre = Ólafur Jóhannesson | url = http://www.fhingar.net/fullStory.php?id=862&p=leikmenn | site = http://www.fhingar.net |jour = 11 |mois=6 |année=2005 | consulté le = 27 mars 2013}}

m'annonce en rouge : Erreur : durée invalide. ?

NB : ça fait pareil avec |date=11 juin 2005

Promis, je serai aimable mais franchement ça me gonfle c'est déconcertant... Avant, ce genre de modif, ça marchait. On mettait lien brisé et on mettait à jour (ou pas) le paramètre consulté le et youpi. Vincent.vaquin (d) 27 mars 2013 à 20:44 (CET)

Je pense qu'une meilleure approche consisterait à ajouter un paramètre |brisé= dans les modèles {{lien web}}, {{article}} et {{ouvrage}} qui reprendrait la présentation de {{lien brisé}} sans pour autant foutre le bordel dans la référence elle-même. J'en parlais il y a une minute dans la PdD de JackPotte (d · c). — Bouchecl (dring) 28 mars 2013 à 19:26 (CET)

@Vincent : j'ai réglé le cas ci-dessus, qui était dû à la modification que j'avais faite quand tu voulais voir des dates en clair alors que j'écrivais des chiffres. C'est juste la méthode de {{lien mort archive}}, si nous la changeons ici nous devrions aussi le faire là-bas (ou bien je pourrais lancer un module Lua qui marcherait à tous les coups). JackPotte ($♠) 28 mars 2013 à 19:37 (CET)

@Bouchecl Pour --Vincent.vaquin (d) 29 mars 2013 à 15:48 (CET)

Je pense que l’idée de Bouchecl — d’ajouter un param au lieu de changer de modèle — est excellente. -- Nnemo (discuter) 8 février 2014 à 19:29 (CET)

Pertinence du modèle

Pour faire suite un commentaire de Bouchecl (d · c · b), je me demande quelle est la pertinence de ce modèle? J'ai l'impression que sur Wikipédia, dès qu'une référence bibliographique n'est pas accessible en ligne, c'est suspect. Je comprends pour le {{lien web}}, mais pour {{article}} et {{ouvrage}}, c'est un élément secondaire de savoir si l'ouvrage est accessible en ligne ou non.
Bref, ne pourrait-on pas arrêter de mettre en rouge des liens. Ça beurre inutilement les articles. Un message semi-automatique sur la page de discussion ou un catégorisation cachée me semblerait plus appropriée que de rougir tout. — Riba ^(discuter) 29 mars 2013 à 14:29 (CET)

D'accord, mais d'un autre côté retirer le rouge renverra les lecteurs vers des sites inexistants sans qu'ils puissent avoir été bien informés de leur présence potentielle sur archive.org ou wikiwix. Cette mise en évidence permet à ceux qui "chassent" ces liens de les repérer tout de suite. JackPotte ($♠) 29 mars 2013 à 14:41 (CET)

J'aime bien l'idée donnée ci-dessus par Bouchecl de rajouter un paramètre brisé le dans les modèles déjà existants ; ça paraît une solution vraiment élégante puisque ça préserve le reste du modèle sachant que, pour ouvrage, c'est en effet mineur à la différence de lien web. --Vincent.vaquin (d) 29 mars 2013 à 15:49 (CET)

@Riba : On pourrait envisager plusieurs approches. Par exemple, dans le cas du modèle {{lien web}}, le rendu d'un lien brisé pourrait mettre le titre de la page en rouge (si |brisé le= est renseigné) avec wikiwix et archive.org rendus de façon semblable au modèle {{lien brisé}} actuel. Dans le cas d'{{article}} et {{ouvrage}}, l'URL pourrait disparaître complètement si |brisé le= est renseigné, pour être remplacé par la mention [lien brisé] en exposant. L'article pourrait aussi être classé dans une catégorie cachée appropriée. Le contributeur pourrait alors enlever l'URL ou la remplacer sans que ce soit trop criard. Dans ma proposition, le modèle {{lien brisé}} lui-même ne serait plus utilisé directement et servirait de contenant qui serait transclus dans le code de {{lien web}}, {{article}}, {{ouvrage}}, {{loi}}, {{jugement}}, etc. — Bouchecl (dring) 29 mars 2013 à 18:27 (CET)

Je voudrais aussi signaler que enwiki a ajouté des paramètres pour les archives |archivedate= et |archiveurl= dans Template:Cite book, Template:Cite news et Template:Cite web. — Bouchecl (dring) 29 mars 2013 à 18:35 (CET)

Oui, et ils ajoutent en:Template:dead link après leurs modèles de lien, ce qui est moins pratique d'un point de vue CSS, JavaScript. JackPotte ($♠) 29 mars 2013 à 19:07 (CET)

Leur approche n'est pas nécessairement à émuler . On peut certainement faire mieux. — Bouchecl (dring) 29 mars 2013 à 19:28 (CET)

En tout cas s'il vous faut des exemples pour travailler le rendu, l'article Rupture du ligament croisé contient {{article}} suivi de la mention "lien mort". JackPotte ($♠) 1 avril 2013 à 18:29 (CEST)

Préservation du format de date lors de la transformation d'un lien en "lien brisé"

Bonjour, il m'arrive d'avoir à corriger des liens dans les articles. Mais "lien brisé" ne fonctionne pas à l'instar des autres modèles tels que article ou ouvrage et le formatage des dates est perdu lors de la transformation. Ainsi, par exemple, ce lien cassé :

« Législatives au Gabon : peu d'affluence pour un scrutin acquis au pouvoir », Libération,‎ 17 décembre 2011 (lire en ligne)

devient ceci avec le modèle lien brisé

« Législatives au Gabon : peu d'affluence pour un scrutin acquis au pouvoir »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)}, Libération, 17 décembre 2011

Serait-il possible de faire en sorte qu'on puisse se contenter de remplacer le paramètre "article" par "lien brisé" et que ce dernier préserve le formatage des dates ?

Cordialement --Barada-nikto (discuter) 23 juillet 2014 à 14:04 (CEST)

Je souscris à cette demande que j'ai moi-même failli faire par le passé. -- XoLm56 (discuter) 23 juillet 2014 à 14:27 (CEST).

Recensement toujours croissant des liens brisés

J'ai commencé sur Bistrot une discussion parce que je ne vois pas comment suivre un point de la documentation du Projet:Correction des liens externes :

- un lien web devient un lien brisé grâce au bot ;

- s'il existe une archive du lien, le contributeur remplace l'url du lien brisé par le lien de l'archive et le Modèle:lien brisé devient Modèle:lien web (ou Modèle:lien mort archive si l'archive provient de Internet Archive mais du coup on perd des informations du type auteur, etc. parce ce que ce modèle est minimaliste, peut-on lui ajouter les paramètres de lien web ? ) ;

- s'il n'existe pas d'archive du lien et qu'on a trouvé une autre source prouvant la même chose, la documentation dit de garder l'url du lien brisé mais comment le faire ? Si on garde la garde avec le modèle du lien brisé, ça veut dire que la page liens brisés ne va quasiment jamais diminuer (sauf pour les liens brisés ayant une archive). De plus, il va être difficile de trouver parmi la liste des liens brisés ceux n'ayant pas encore bénéficié de l'ajout d'une nouvelle référence pour justifier le passage : un contributeur souhaitant en corriger quelques-uns pourrait se retrouver à parcourir une centaine d'articles de la page avant de tomber sur un lien brisé n'ayant pas encore été traité par un autre contributeur.

Ne faudrait-il pas créer un modèle « lien mort justifié/remplacé » pour pouvoir différencier les « liens brisés trouvés par le bot » des « liens brisé trouvés par le bot pour lesquels un contributeur a ajouté une nouvelle référence justifiant le passage de l'article » ? --Positronique (discuter) 4 juin 2015 à 14:18 (CEST)

Nous avons trop de Catégorie:Modèle créant un lien externe, je propose d'ajouter plutôt un paramètre. JackPotte ($♠) 5 juin 2015 à 17:16 (CEST)

Rapprochement vers le modèle:Lien web

Je propose de baser le code de ce modèle sur le même code que {{Lien web}} pour avoir les même paramètres et le même comportement, sauf bien sur le lien en rouge, les liens archives et le paramètre brisé le spécifique à ce modèle.

Il est possible d'essayer cette nouvelle version via {{Lien brisé/Bac à sable}}. Comparaison possible avec le modèle actuel sur Modèle:Lien brisé/Test.

Qu'en pensez-vous ?

— Zebulon84 (discuter) 24 avril 2017 à 21:53 (CEST)

Que du bien... cordialement Barada-nikto (discuter) 24 avril 2017 à 22:01 (CEST)

Modifier

Bonjour, savez-vous comment modifier cet article? Bien Cordialement — Les Yeux Noirs (discuter) 5 juillet 2018 à 23:13 (CEST)

Cette page n'est pas un article, mais un modèle. Sa modification est semi-protégée. --Chealer (discuter) 7 juillet 2023 à 20:00 (CEST)

Obligation du paramètre url

Non résolu.

Veillez rendre le paramètre url facultatif. Il est très difficile d'indiquer les références brisées en attendant, sans équivalent au modèle anglophone. --Chealer (discuter) 1 avril 2020 à 15:16 (CEST)

Je ne comprends pas l'intérêt d'un {lien brisé} sans URL. Si y'a pas d'URL, y'a pas de lien. -- Irønie (discuter) 4 juin 2020 à 16:18 (CEST)

Vu que ça date du 1er avril, c'est, qui sait, du second degré... --Ypirétis (discuter) 4 juin 2020 à 16:25 (CEST)

Ah ok. Ça me fait pas rire ! -- Irønie (discuter) 4 juin 2020 à 16:35 (CEST)

Irønie : Il y a bien sûr un URL... il figure simplement avant (par convention), et non pas dans le gabarit Dead link.--Chealer (discuter) 20 mai 2023 à 05:27 (CEST)

Paramètre 'titre' facultatif

Résolu. Chealer (discuter) 7 juillet 2023 à 20:00 (CEST)

D'après la doc, le paramètre titre est obligatoire. Je propose de changer en "facultatif" :

1. car superflu : dans le cas d'une URL 404 transformée en {lien brisé}, y'a pas la possibilité de connaitre l'ancien titre de la page ou du document.
2. Le code {lien brisé} autorisé déjà l'ommission de ce paramètre. Il utilise alors la valeur de url à la place.

Exemple : {{lien brisé| url=https://www.persee.fr/bla}} donne « https://www.persee.fr/bla »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)}

-- Irønie (discuter) 4 juin 2020 à 16:18 (CEST)

Ben pourquoi ? ça serait encourager à ne pas le mettre, même s'il sait s'en débrouiller quand il n'y en a pas. --Ypirétis (discuter) 4 juin 2020 à 16:41 (CEST)

Parce que c'est pas obligatoire, en vrai. -- Irønie (discuter) 4 juin 2020 à 18:00 (CEST)

Hé ouais, mais faut pas que ça se sache. Ypirétis (discuter) 4 juin 2020 à 18:05 (CEST)

Idée d'amélioration

Bonjour,

Ne serait-il pas possible avec ce modèle de lui inclure également la possibilité de corriger les liens brisés en choisissant l'archiveur qui possède une archive de la page et l'horodatage qui va avec comme peut le faire le modèle {{Lien archive}} mais seulement avec les pages de l'Internet Archive ?

Cordialement --Rayquachu (discuter) 24 août 2022 à 16:01 (CEST)

J'ai ce problème avec mon bot, qui pourrait remplacer automatiquement le lien brisé par un lien d'archive wikiwix (quand l'archive est disponible) ; j'ai l'impression qu'il n'existe pas de telle possibilité avec les modèles actuels. Pourtant ce serait une plus value très appréciable pour le lecteur qui bénéficierait ainsi d'un lien OK bleu cliquable plutôt que des trucs rouges qui font peur de {lien brisé}.

A suivre... — Irønie (d) 15 avril 2023 à 10:16 (CEST)

D'ailleurs je découvre une ergonomie (UX) complètement con, proposant au lecteur un lien bleu très visible, menant à une 404 (quel intérêt pour le lecteur de l'envoyer sur une page cassée ?!!). Exemple (créé par bot en 2020) :

• {{lien web|url=http://www.auburntigers.com/sports/m-baskbl/mtt/chuck_person_894768.html|titre=Chuck Person|éditeur=auburntigers.com|consulté le=31 juillet 2015|archive-url=https://web.archive.org/web/20160425034141/http://www.auburntigers.com/sports/m-baskbl/mtt/chuck_person_894768.html|archive-date=25 avril 2016|brisé le=29 mai 2020}}
• « Chuck Person » [archive du 25 avril 2016], auburntigers.com (consulté le 31 juillet 2015)

Rolala y'a tellement à faire côté pour recycler et améliorer tous les trucs côté Liens externes. _ Irønie (d) 15 avril 2023 à 10:24 (CEST)

Bonsoir Irønie , je viens de constater l'existence d'une discussion sur le sujet des liens brisés sur la PdD du modèle Lien web qui, après avoir répondu à la question initiale qui a lancé la discussion, rejoint le constat de l'inutilité de mettre en avant un lien qui ne fonctionne plus au détriment de l'archive. Bon weekend. --Rayquachu (discuter) 22 juillet 2023 à 23:50 (CEST)

Obligation de sites d'archivage

Non résolu.

Veillez rendre les liens d'archivage facultatifs, de façon à ce qu'on puisse les désactiver quand ceux-ci sont impertinents, comme dans le cas de sites dynamiques à des fins utilitaires. Chealer (discuter) 20 mai 2023 à 05:19 (CEST)

Bonjour Chealer Pouvez-vous donner un exemple de ce que vous demandez ? Qu'appelez-vous un « site dynamique » ? Bien à vous — Pharma ^💬 24 octobre 2023 à 21:00 (CEST)

Une page web dynamique a un contenu variable calculé au moment de sa consultation. Wikipédia est un site dynamique basé sur PHP. Un exemple de page tellement dynamique qu'elle n'aurait pas d'intérêt sans est ce générateur, qui est ici brisé puisque l'archivage n'a capturé qu'un rendu, pas la recette pour y arriver. Les liens qu'on retrouvait sur Modèle:Article/Documentation étaient donc trompeurs. Chealer (discuter) 25 octobre 2023 à 04:48 (CEST)

Intérêt du paramètre date

Bonjour,

Quelqu'un connaîtrait-il une application pratique qui utilise le paramètre date de ce modèle ? De même dans {{Lien web}}, quel est l'intérêt d'indiquer la date à laquelle on constate la mort du lien plutôt que simplement |brisé=oui ? Je pensais qu'il existerait des catégories telles qu'« Article avec un lien mort signalé en 20XX » mais, sauf erreur, ce n'est pas le cas.

Pharma ^💬 24 octobre 2023 à 20:58 (CEST)

Bonjour Pharma,

Aucun site n'est invulnérable. Lorsqu'il brise, un site peut être réparé, de sorte qu'un lien brisé n'est pas nécessairement brisé de façon permanente. Indiquer la date donne un indice sur l'ampleur du bris, ce qui aidera à décider comment gérer le problème. Chealer (discuter) 25 octobre 2023 à 04:32 (CEST)

• ne pas confondre les dates de brisé le et de date !
• date correspond exactement au date de {lien web} : date de publication du document web.
  • permet notamment la recherche d'archive web pour cette date précise (mieux que consulté le ajouté par bot)
  • facilite la conversion éventuelle {lien brisé} => {lien web}.
• brisé le c'est le constat du lien mort. Permet à un bot d'exclure des liens qui ont été déclaré "brisé" trop récemment (-1 mois), dans l'hypothèse d'un site temporairement indisponible. Comme l'indique @Chealer

- Irønie (d) 5 décembre 2023 à 00:11 (CET)

Dysfonctionnement surprenant

Bonjour. Je viens de constater un comportement pour le moins étrange : la présence de guillemets français (chevrons) autour du titre donne au modèle {{Lien brisé}} un comportement équivalent à celui du modèle {{Lien web}}. Ce n'est heureusement pas une syntaxe habituelle, mais ça reste dérangeant. Quelqu'un en connaît-il la cause et ce problème concerne-t-il d'autres caractères ? Un fin connaisseur des modules associés, tel Od1n, peut-être ?
Syntaxe minimale pour reproduire le problème : {{Lien brisé|titre=« Titre »|url=…}} à comparer à {{Lien brisé|titre=Titre|url=…}}. Notons que |titre=«Titre» pose aussi problème mais pas |titre="Titre" ni |titre=A« Titre » ni |titre=« Titre »A. — Ideawipik (discuter) 23 novembre 2023 à 15:52 (CET)

Par-là :

Biblio.lienBrise => Biblio/Lien web.lienBrise( args ) => Biblio/Lien web.titre :

-- on teste d'abord si titre contient déjà des guillemets
		if titre:match( '^«.+»$' ) then
			insert( titre )
        else

- Irønie (d) 23 novembre 2023 à 16:21 (CET)

Bien vu ! Merci Irønie. Cela veut dire que si on est dans cette situation l'éventuel sous-titre n'est pas affiché.

Ne peut-on pas remplacer par un traitement en amont et retirer le else (et les indentations correspondantes) ? La variable titre n'est pas réutilisée ultérieurement, donc on peut l'altérer. La création de contenu (insert) aura lieu ensuite. Cela donnerait :

		if titre:match( '^«.+»$' ) then
			titre=titre:gsub( "^«%s*(.+)%f[%s»]%s*»$", "%1" )
		end

— Ideawipik (discuter) 23 novembre 2023 à 18:11 (CET)

J'avais vu ce signalement et j'avais commencé à étudier une solution pour supprimer les « [espaces] et les [espaces] », mais il s'est avéré beaucoup plus simple de ne pas faire de tels remplacements (pour de toute façon remettre des guillemets ensuite…), et plutôt ne pas ajouter de guillemets si on en a détectés à la base. J'ai donc réalisé cela : 209945990.

od†n ↗^blah 24 novembre 2023 à 01:43 (CET)

Pour info, le code que j'avais en bac à sable pour le retrait des leading/trailing guillemets :

if titre:match( '^«.+»$' ) then
    titre = titre:gsub( '^«' ):gsub( '»$' )
    local beforeRepl = titre
    repeat
        titre = titre
            :gsub( '^ +' ):gsub( '^\194\160', '' ):gsub( '^ ', '' ):gsub( '^ ', '' ):gsub( '^ ', '' )
            :gsub( ' +$' ):gsub( '\194\160$', '' ):gsub( ' $', '' ):gsub( ' $', '' ):gsub( ' $', '' )
    until titre == beforeRepl
end

On voit bien que plutôt que de bidouiller le paramètre "titre" ainsi (alors qu'en plus des guillemets on en remettra après…), mieux vaut garder la valeur saisie par l'utilisateur et ne pas ajouter de guillemets. Aussi, un paramètre "titre" de format ^«.+»$ est anormal, il est censé contenir simplement le titre, et ne pas être encadré de guillemets. Refs à propos 102412502.

od†n ↗^blah 24 novembre 2023 à 02:27 (CET)

Quelle que soit la méthode appliquée, l'important lors de la suppression des « [espaces] initiaux et les [espaces] » finaux est de ne pas le faire de façon indépendante (ou alors, en se limitant aux cas correspondant à la capture des codes ci-dessus ('^«.+»$') et en n'enlevant qu'une seule occurrence des motifs). En effet, on peut avoir, dans un titre légitime, une citation en début ou fin de phrase. Il ne faudrait pas déséquilibrer les guillemets imbriqués. Toutes les propositions données respectent ce cadre. Les dernières sont plus exhaustives quant aux types d'espaces (notamment les entités HTML pour l'insécable). Une autre différence marginale, par rapport à la première proposition serait visible en cas de |titre=« » ou |titre=«». La solution appliquée est satisfaisante et, tout compte fait, moins gourmande en ressources. Merci. — Ideawipik (discuter) 24 novembre 2023 à 10:27 (CET)

L'autre solution, c'est de ne pas exiger du modèle qu'il corrige la donnée : passer un bot partout pour retirer les « » superflus. Puis inclure la règle aux scripts/bots de correction typo (AWB, WPCleaner de  NicoV :, CodexBot…). Ça évite de surcharger le code et les responsabilités du modèle, pour une erreur typo rare sur l'ensemble des citations. Est-ce que les modèles enwiki le font ?

Je trouve 28000 occurences de titre ?\= ?\« [2] - soit estimé 0,8% des citations, c'est plus fréquent que j'imaginais, mais probablement lié à des pratiques anciennes (car en 2023 les {lien web} surtout ajoutés par gadgets ou bots, j'imagine)

Tout me va. -- Irønie (d) 24 novembre 2023 à 10:54 (CET)

Le modèle {{Lien web}} est utilisé sur plus d'un million de pages, alors forcément dans le lot faut s'attendre à en trouver des dingueries ! Avec une recherche de ^«.+»$ dans le paramètre "titre", j'ai environ 16 000 résultats. On pourrait envisager une requête aux bots pour les nettoyer (en faisant la même chose que dans le code que j'ai posté au-dessus), néanmoins j'imagine que cela reviendrait.

Ou alors justement, après avoir tout nettoyé, on enlève la détection ^«.+»$ du module, comme ça si un rédacteur les met, il se retrouvera avec "« « titre » »" dans le résultat et il devrait comprendre… ou pas.

od†n ↗^blah 24 novembre 2023 à 13:25 (CET)

Y'a pas un bug d'algo avec titre=« A » et « b » => titre=A » et « b ? Je ne connais pas LUA/gsub (sans 2ème/3eme param) . Et avec "titre=« A » selon B" ? ( Od1n : - Irønie (d) 24 novembre 2023 à 15:48 (CET)

Bien vu, je n'avais pas pensé au cas "« A » et « B »". L'avantage de la solution "ne pas ajouter de guillemets" au lieu de "supprimer les guillemets", est que même avec un faux positif comme ici, ben en fait ça fonctionne bien quand même ! Dans ce cas précis, il est même préférable de ne pas ajouter de guillemets, et je pense qu'on pourrait même considérer que ce n'est en fait pas un faux positif.

Par contre, pour une requête aux bots, la regex serait plutôt ^«[^«»]+»$, pour une détection plus restreinte.

Concernant les cas du genre "« A » selon B", j'y avais bien pensé et il n'y a pas de faux positif de détection sur ceux-ci. À moins que tu aies voulu dire que justement, il faudrait les détecter aussi, pour ne pas leur ajouter de guillemets. Dans ce cas, une détection plus large, et peut-être plus appropriée, serait titre:match( '^«' ) or titre:match( '»$' ). Remarque que cela rejoint aussi le cas "« A » et « B »" mentionné précédemment.

od†n ↗^blah 24 novembre 2023 à 16:41 (CET)

En ce qui concerne « A » et « B », les changements récents ne modifient pas la présence de guillemets par rapport à avant. Ils apportent juste un affichage cohérent (color:red;). Le retrait aurait eu lieu uniquement en début et fin de chaîne et été limité à un retrait de chaque côté. Même |texte=« Selon A « B » » aurait été traité correctement, quelle que soit la solution adoptée. Les guillemets auraient été retirés puis remis : pas naturel mais affichage correct. En revanche, il est vrai que, si on avait eu «A» et «B» sans espaces, le modèle en aurait établi ainsi « A» et «B ». Donc la solution adoptée est plus sage.

Occurrences de « A » et « B » dans les articles. La majorité des appels pour lesquels on a plusieurs guillemets de même sens (par exemple : pour Lien brisé, une vingtaine dont trois déséquilibrés) correspondent à des cas pour lesquels il ne faut pas en ajouter une couche ; seule une poignée est du type "« A » et « B »" (4 pour Lien brisé). Pour le modèle Lien web, le constat est inverse ; on est plutôt à 600 pour 800. Comme quoi, il n'y a pas tant d'appels avec des guillemets en trop techniquement. Bilan : il est peut-être préférable de réduire les exceptions d'ajout de guillemets dans le module à ^«[^«»]+»$ plutôt qu'à l'actuel ^«.+»$. S'il y a trop de guillemets imbriqués affichés, un lecteur ou un bot corrigera le paramètre dans l'appel du modèle, selon la syntaxe recommandée. En ce qui concerne les guillemets en trop éditorialement, par exemple |titre=« Titre » : « Sous-titre », difficile de corriger cela de façon automatique.

Attention ! Si on fait passer un bot, considérer l'éventualité « A « B » C » ou « A « B » C « D » E » (guillemets externes à retirer) différente de « A » B « C » (guillemets à conserver). Pour couronner le tout, on a des paramètres contenant déjà des guillemets imbriqués. Par exemple : titre=«φόρτου-εργασίας»-είναι-άνεργος « Ο βουλευτής της Χρυσής Αυγής που παραιτήθηκε λόγω «φόρτου εργασίας» είναι... άνεργος » dans Liste des députés de la XVe législature du Parlement grec et XVe législature du Parlement grec, syntaxe qui coche aussi la case « A » et « B ».

À propos de la modification suivante, je ne suis pas persuadé de l'intérêt du test ajouté puisque dans ce cas, on a déjà un message d'erreur « paramètre « url » manquant » en rouge pour un problème d'absence de paramètre obligatoire bien plus important qu'une présence de crochets superflus. Mais si le coût est faible… — Ideawipik (discuter) 24 novembre 2023 à 19:55 (CET)

• Nous sommes d'accord que pour une éventuelle requête aux bots, le pattern serait ^«[^«»]+»$. C'est vraiment le seul avec lequel il n'y a pas de risque de faux positif, et ce n'est pas grave si le bot ne détecte pas absolument tout, c'est mieux que d'introduire des erreurs ; et l'objectif ne serait que de dégrossir, pas d'être exhaustif.
• Concernant le module, nous avons établi que le pattern ^«.+»$ n'est pas l'idéal. Je garde en considération ma proposition plus haut, de ne pas ajouter les guillemets si titre:match( '^«' ) or titre:match( '»$' ) (j'avais même un moment pensé à titre:find( '«', nil, true ) or titre:find( '»', nil, true ) (attention, caractère multibyte donc ne pas faire :match( '[«»]' ), et utilisation de :find() en mode plaintext pour micro-optimisation), mais pas une bonne idée, car on veut ajouter les guillemets dans le cas "Jean-Claude a dit « truc muche » à Josiane"). Il faudrait comparer les propositions ^«[^«»]+»$ et ^« or »$, mais je pense que chacune des deux serait déjà préférable à l'actuelle.
• Concernant le cas où le paramètre obligatoire url viendrait quand même à être manquant : effectivement, dans cette situation on peut quand même avoir un affichage propre, avec simplement un texte au lieu d'un lien, ça serait dommage de s'en priver. Je pense que le wikicode du résultat doit être valide en toutes circonstances, même si l'utilisateur n'a pas renseigné un paramètre obligatoire.

od†n ↗^blah 25 novembre 2023 à 15:07 (CET)

• Pour RBOT avec ^«[^«»]+»$. 99% des cas, c'est parfait ! Mieux, avec ensuite un trim des éventuels espaces insécables devant/derrière. Traiter aussi les guillemets simples ? ^"[^"]+"$ ?
• Pour l'amélioration du code modèle, j'ai pas d'avis : fais comme tu veux ! :) -

Irønie (d) 28 novembre 2023 à 14:33 (CET)

Le rouge a disparu

Résolu. Chealer (discuter) 7 janvier 2024 à 18:56 (CET)

Depuis aujourd'hui, la couleur bleu appliquée aux balises <a> dans Vector 2022 cache la couleur rouge des liens brisés. Escargot (discuter) 24 novembre 2023 à 15:27 (CET)

Bien vu, je viens de corriger cela. Merci pour le signalement. od†n ↗^blah 24 novembre 2023 à 16:54 (CET)

Merci @Od1n ! Escargot (discuter) 24 novembre 2023 à 18:02 (CET)

Nettoyage de paramètres non supportés

Bonjour

Dans Wstat, j'ai analysé les statistiques d'usage des paramètres du modèle {{lien brisé}} (lire ces stats en ligne.)

Avant de prendre le relais manuellement, j'aimerais qu'un bot fasse un premier grand nettoyage.

Si un dresseur de bot peut m'aider :

Accéder à la requête

Merci LeFit (discuter) 23 mars 2024 à 07:55 (CET)