Discussion Wikipédia:Prise de décision/Système de cache

Le projet cache

Préambule

Ce projet part du constat simple qu'environ 5% des liens externes sont mort, la page vers laquelle ils pointent n'existe pas, ou a été déplacée. Il existe par ailleurs un Projet:Correction des liens externes, qui cherche à limiter ces liens morts.

Ces liens morts sont un problème quand ils viennent en référence pour un article. Un lien mort et il devient impossible de vérifier la source utilisée.

Pour pallier ce problème, la société Linterweb propose la mise en place d'un système de sauvegarde des pages disparues : un « cache ». Ce cache permet de consulter les pages sur un site à part, même si celles-ci ne sont plus accessibles, à la manière du système de cache bien connu de Google.

Avantages du système :

• Les liens utilisés comme source restent toujours consultables.
• Les pages altérées après avoir été liées peuvent être vérifiées.

Linterweb est la PME française qui développe et commercialise Wikipédia sur DVD en partenariat avec la Wikimedia Foundation, elle développe également un moteur de recherche spécialisé sur les projets de la Wikimedia Foundation : Wikiwix.

Solution

align

Concrêtement, le système ajoute un lien supplémentaire « cache » à tous les liens externes (voir figure ci-contre). Le lien original n'est pas altéré, le code wiki reste inchangé, le lien cache étant ajouté à la volée au moment du chargement de la page. Si le lien externe est mort, le visiteur Wikipédien a donc la possibilité de consulter la page originale en cliquant sur le lien du cache.

Il est déjà possible de tester le système en ajoutant la commande loadJs('User:Pmartin/cache.js'); à votre monobook.js. Plusieurs contributeurs le testent déjà activement.

Objections courantes

Questions les plus évidentes et leurs réponses :

• N'est-il pas illégal d'héberger un système de cache ? → Le cabinet d'avocat de Linterweb pense que non, notamment du fait que de tels systèmes sont déjà en place ailleurs (Google, Internet Archive) et qu'il existe des possibilités techniques d'interdire la mise en cache.
• N'est-il pas dangereux pour la Wikimedia Foundation d'être hébergeur ? → Seul Linterweb serait l'hébergeur, la Wikimedia Foundation ne faisant que faire des liens vers les pages en cache.
• N'est-il pas immoral de faire des liens vers un site dont on suppose qu'il pourrait violer le droit d'auteur ? → De nombreux liens de Wikipédia pointent déjà sur des sites dont certaines pages pourraient hypothétiquement violer le droit d'auteur. Aucune politique claire n'existe à ce sujet de la part de la Wikimedia Foundation, ni aucune définition non-ambigue de ce qu'est une violation du droit d'auteur acceptable ou non.
• Linterweb fera-t-elle un bénéfice sur l'exploitation du cache ? → Difficile à dire avant que le système soit lancé, mais c'est possible, de la même manière que cette société commercialise WikipediaOnDVD ou propose un moteur de recherche en espérant en retirer quelque chose. Cependant, l'esprit des projets de la Wikimedia Foundation est d'encourager ces pratiques de redistribution (voir la licence GFDL, par exemple). De plus, Linterweb s'engage à mettre à disposition les données statistiques issues du cache (sous une licence à définir, néanmoins).
• Le système peut-il pister les visiteurs des articles ? → Non, le système ne fait que rajouter un lien et ne modifie pas plus le code HTML de la page. Il peut néanmoins décompter les visiteurs des pages mises en cache.
• Les liens externes supprimés continueront-ils d'être mis en cache ? → Non, une fois supprimé de Wikipédia, le lien externe est également supprimé du cache de façon automatique.
• Internet archive propose déjà ce système et est très employé sur Wikipédia → Internet archive n'archive pas l'intégralité des liens utilisés sur Wikipédia, ni ne propose un archivage à la date d'insertion du lien. Le système proposé garantie au contraire la mise en cache pour Wikipédia.

Objet de la prise de décision

La prise de décision vise à décider de mettre à disposition le système de cache par défaut sur la Wikipédia francophone.

Plusieurs solutions sont possibles :

1. le système n'est pas activé par défaut, les utilisateurs enregistrés peuvent cocher la case dans leurs préférences pour l'activer.
2. seuls les utilisateurs enregistrés voient les liens « cache » par défaut, et peuvent les masquer via l'option idoine.
3. tous les visiteurs voient apparaître les liens « cache », avec la possibilité pour les utilisateurs enregistrés de les supprimer, via une case à cocher dans les préférences.

Étant donné que le système n'est pas techniquement intrusif, il demeure extrêmement simple de le désactiver globalement s'il n'était pas concluant.

Discussions

Question de Maloq

Bon, plusieurs remarque, dont quelque une deja formulées, mais puisque ça se passe ici maintenant .

1. Je voudrais des stats précises sur le temps d'exécution du script avant de me prononcer pour une intégration par défaut
2. Est-il possible que le cache renvoi vers la bonne page avec une réécriture d'URL si la page originale est toujours la?
3. Vous dites que 5% des pages ne sont plus accessible, pourrions nous avoir des détails ? D'où sort ce chiffre ? Je dis ça car, de mon expérience personnelle, il ne m'a pas semblé que ça soit tant que ça.
4. Vos serveurs sont-ils capable de supporter la charge ? Avez vous fait des estimation pour chaque mode de déploiement (par défaut, et en préférence) ?
5. Meme si je suis convaincu que vous n'avez aucune raison de le faire, il y a une question importante : quelle garantie avons-nous que la version produite par votre cache est exactement la mémé que celle d'origine ?
6. Sur le plan du concept, il y a un truc qui me gène. J'ai bien compris l'intérêt du cache. Mais un des reproche qui est faites à WP de la part des webmasters, c'est de vampiriser le Web. En gros ils reprochent, et je les comprend, d'utiliser de facto notre très bonne place sur Google pour mettre en avant des articles, rédigés à partir de ceux venant d'autres sites. Cette vision, un peu exagérée, je pense, est tout de même vrai dans une certaine mesure. Alors, en plus de cela, si on redirige nos liens externes vers un autre site que les sites sources, ne va-t-il pas y avoir un effet très pervers ? (je demande votre avis). Cette remarque n'est pas à prendre à la légère car ce changement, si il est fait par défaut pour la totalité des liens externes, ça va un peu modifier la navigation sur le Web. Ce n'est pas forcément à nous de statuer sur ce point, mais savoir ce que l'ont fait, et les impacts est important.

Voila, je me fait un peu l'avocat du diable, mais ce changement n'est pas anodin, et ces précisions sont importantes à mon sens. Cordialement, Maloq ^causer 27 août 2008 à 17:40 (CEST)

Pour le reste je passe mon tour. Pour le 6., je ne comprends pas trop car je ne vois pas l'intérêt de cliquer sur (cache) si le lien n'est pas mort. Or si il est mort on ne risque pas de le vampiriser, on lui rends la vie. Il y a quelque chose auquel je n'ai pas pensé? Bien amicalement, Dodoïste ^{[réveille-moi]} 27 août 2008 à 21:16 (CEST)

Yep, bien noté, mon esprit avait pris un peu d'avance en pensant que le script remplacait le lien. Si il ne fait que rajouter un lien vers le cache, la question ne se pose pas focément. Idem pour la question 2. Maloq ^causer 27 août 2008 à 22:30 (CEST)

1 nous allons te fournir celà dans la journée.

2 Dans l'absolu je dirais oui, mais d'un autre côté celà fait une redirection vers le site d'origine, lorsque la page est originale est toujours là.Mais en écartant le problème qui consiste à vérifier si la page source est là et qu'elle n'a pas été modifiée c'est que ce n'est plus à proprement parlé d'un cache à ce moment là et finalement nous risquons d'être considéré comme un trackeur tant à la fois des visiteurs que des sites sources.

3 C'est un échantillonage que nous avons testé sur 1000 liens, mais nous pourrons fournir des stats plus réaliste sur l'état des liens.

4 Je ne me fait pas trop de souci quelquesoit le mode d'intégration car nous allons investir dans des nouveaux serveurs courant Septembre, même si ce problème reste le notre.

5 Et si celà se sait, la communauté aura vite fait de retirer le cache, donc je ne pense pas que ce soit mon intérêt. Pmartin (d) 28 août 2008 à 08:28 (CEST)

Questions de Pwet-pwet

La société Linterweb pourrait-elle reproduire publiquement et en intégralité l'avis qu'a donné son cabinet d'avocat ? merci. Seconde remarque, que fait-on si la société Linterweb est attaquée en justice, perd son procès, et est contrainte de supprimer son système de cache ? (juste pour information, Google a déjà perdu un procès en Belgique au sujet du système de cache, c'est donc quelque chose de parfaitement envisageable). Comment traite-t-on les liens à nouveau morts ? Il me semble qu'il faut prévoir une issue de secours, donc ne pas automatiser le recours au cache et conserver un système optionnel comme c'est le cas actuellement, afin de ne pas avoir à se farcir l'effacement et le remplacement de milliers de liens morts le cas échéant. Pwet-pwet · (discuter) 27 août 2008 à 17:42 (CEST)

Petite précision au sujet du procès de Google en Belgique : La pratique mise en cause n'était pas le système de cache mais la récupération automatique du contenu des sites de news de la presse écrite francophone pour construire les pages Google News. --Dereckson (d) 27 août 2008 à 17:55 (CEST)

Un système de cache est la même chose qu'un système de récupération automatique (c'est en gros le système de copier-coller automatique qui est interdit), mais passons : l'important est de savoir ce qu'on fait si le cas se présente, Linterweb n'étant ni google ni webarchive. Pwet-pwet · (discuter) 27 août 2008 à 17:59 (CEST)

Le système tel qu'il est prévu ne modifie pas les pages, il consiste seulement en un javascript ajoutant des liens "à la volée". Si demain le cache, pour une raison ou une autre, ne fonctionne plus il suffira donc de désactiver ce javascript. Guillaumito (d) 27 août 2008 à 18:03 (CEST)

Ok, merci de la précision. Reste la question de lier vers un site qui reproduit un contenu sans autorisation, je suis contre car de notre côté on ne se gêne pas pour aller taper sur des sites qui reproduisent wikipédia sans autorisation (sans respecter la GFDL, sans citer les auteurs, etc.). Je pense donc qu'il faut donner une image irréprochable de Wikipédia en ne liant pas vers des contenus violant le droit d'auteur, si on veut être crédibles quand on fait valoir le nôtre. Pwet-pwet · (discuter) 27 août 2008 à 18:08 (CEST)

N'ayant aucune formation en droit, je ne m'avancerais pas sur la question du droit d'auteur et de ses possibles violations, par contre le système de cache permet aux sites d'empecher l'archivage de leur contenu (voir par exemple le cache du site le monde) de la même manière que le cache de google le fait. Guillaumito (d) 27 août 2008 à 18:15 (CEST)

Ayant une petite formation en droit d'auteur, je peux t'assurer qu'il faut demander l'autorisation préalable d'un auteur avant de copier son travail (c'est pour ça que sur google par exemple les copies de sites sont effacées sur demande : parce que normalement il faut l'autorisation de l'auteur avant de copier). Cela dit, ce système qui empêche l'archivage et permet le retrait de la copie sur demande est un bon compromis et évite de faire des vagues dans la pratique, même si en théorie un auteur est en droit de vous attaquer. Moi je voterai contre cette prise de décision pour des raisons de cohérence, mais je n'en ferai pas une maladie si le reste des contributeurs est ok pour lier vers votre site. Pwet-pwet · (discuter) 27 août 2008 à 18:19 (CEST)

Si seulement c'était si simple :). Ce n'est pas le cas, et ni toi ni moi ne sommes des avocats compétents pour donner un avis suffisemment éclairé sur la question. De toutes manières je ne suis pas sûr de comprendre ce qui te gêne. Les risques juridiques seront pris par Linterweb et aucunement par WMF. A partir de là, c'est le "probleme" de Linterweb d'avoir fait appel à un avocat pour estimer le risque juridique de l'opération. Mais j'ai sûrement mal compris ce qui te gêne :). Est-ce le fait de lier vers un site qui, peut-être, ne respecte pas le droit d'auteur? Dans ce cas, en suivant ta logique, nous devrions supprimer tous les liens externes renvoyant vers des sites ne respectant pas le droit d'auteur ?schiste 27 août 2008 à 18:36 (CEST)

Oui aux deux dernières questions. Ou plus précisemment, interdire les liens vers des contenus reproduits sans autorisation (un site peut avoir une unique page violant le droit d'auteur et le reste de son contenu non, pas de problème pour lier vers ce qui est réglo dans le site -je pense par exemple à youtube). Ce n'est pas une question de problèmes juridiques pour wikipédia, mais de cohérence avec l'image qu'on affiche -point de vue qu'on n'est pas obligé de partager. Pwet-pwet · (discuter) 27 août 2008 à 18:45 (CEST)

Cela fait plusieurs fois que j'entends cet argument, et j'avoue qu'il me gène.

Pour commencer, objectivement, il est très difficile d'être catégorique d'un point de vue légal, la jurisprudence n'est pas tout à fait cohérente avec la lettre, l'esprit et la lettre ne sont pas non plus toujours en phase, le tout est multiplié par les nombreux détails abscons qui font de la loi internationale une discipline pour professionnels. Donc, même si, moi aussi, j'ai quelques notions de droit, je préfère ne pas m'y fier, et j'ai plutôt tendance à faire confiance aux cabinets d'experts.

De plus, en pratique "Wikipédia" ne prône pas la stricte observation de la lettre de sa licence. La Wikimedia Foundation, par exemple, tolère explicitement qu'on reprenne son contenu en ne faisant qu'indiquer une url vers wikipédia comme source, en contradiction manifeste avec la GFDL. Donc, je récuse l'analyse qui voudrait que "Wikipédia" se fait la chantre de l'observance de la loi.

Si on a cette même analyse, il ne reste qu'un aspect moral que je trouve très scabreux. Après tout, Wikipédia prônant le respect du droit international, de la liberté d'expression, des droits de l'homme, de la culture libre et j'en passe, devrait-elle, pour être cohérente, ne pas lier vers des sites gouvernemntaux Russes, Chinois, Tunisiens ? Vers des sites soutenant ces politiques ? Ou même vers d'autres encyclopédies privatives ? Non, bien sûr, c'est une approche trop emprunte de jugement morale pour être honnête.

Enfin, suivre ce raisonnement, c'est prendre une décision locale en s'appuyant sur un raisonnement global, en fonction de ce que l'on voudrait que soit Wikipédia, et non pas en fonction de ce qu'elle est vraiment... nojhan→☸ 27 août 2008 à 19:25 (CEST)

Le pire c'est que le contenu n'appartient absolument pas à la fondation Wikimedia et qu'elle n'a strictement rien à dire sur les copies de Wikipédia… (à par son logo et quelques broutilles). Marc Mongenet (d) 27 août 2008 à 22:38 (CEST)

Les liens vers les pages violant une loi n'ont pas de rapport particulier avec ce « système de cache ». Ce n'est pas une question plus pertinente que de discuter du droit de faire des hyperliens. Marc Mongenet (d) 27 août 2008 à 22:41 (CEST)

Je suis ici parfaitement d'accord avec nojhan.

Vu que le procès en Belgique ne concernait pas notre propos, aurait-tu (pwet-pwet) d'autres sources impliquant google ou internet archive ? Bien amicalement, Dodoïste ^{[réveille-moi]} 27 août 2008 à 21:46 (CEST)

D'accord moi aussi, on n'est pas là pour surinterprèter une législation qu'on connait mal, alors que pour ce qui est des risques éventuels, c'est la société qui fait la proposition qui se place en première ligne, et qui parait étudier avec un minimum de sérieux la question. Pour moi avec ces conditions, la question légale est traitée. Ensuite il faut passer à l'utilité pratique du système. Astirmays (d) 27 août 2008 à 22:36 (CEST)

Histoire de charrue de la part d'un paysan ;-)

Et si nous commencions par évaluer le dysfonctionnement avant d'évaluer la solution ? Par exemple avec un sondage d'une question « Estimez-vous bloquant, majeur, mineur ou sans importance le fait qu'un lien sur vingt vers des pages web servant de référence soit un lien mort (qui ne permettent plus d'accèder à la page) ? » Cordialement. --Bruno des acacias 27 août 2008 à 18:17 (CEST)

Le problème est que les éditeurs reprèsentent une très très faible proportion des utilisateurs de Wikipédia et qu'en plus ils ne l'utilisent pas comme les lecteurs lambda. Au-delà de cet aspect, qui rend un "sondage" peu réaliste, c'est une solution technique qui assure la pérennité des liens externes sur le long terme. Cette solution ne représente aucun cout pour WMF ou pour le projet (en terme humain) puisque c'est Linterweb qui se charge de tout. schiste 27 août 2008 à 18:22 (CEST)

Pour répondre à ta question, les liens morts sont contraires à la règle Wikipédia:Vérifiabilité et pose problème à la recommandation Wikipédia:Citez vos sources. En effet un lien mort reste valide avec la date de consultation, mais

1. Peu ont ajouté cette date
2. Il serait tout de même préférable de pouvoir consulter la source... Bien amicalement, Dodoïste ^{[réveille-moi]} 27 août 2008 à 21:35 (CEST)

Pour répondre concrètement à la question, oui, c'est clairement un gros problème du point de vue de l'encyclopédie. Je ne crois pas qu'il y ait vraiment besoin d'un sondage pour ça. nojhan→☸ 28 août 2008 à 09:18 (CEST)

Oui et non. En effet, je ne suis pas certain qu'un contenu publié le jour J sur un site web, retiré du site web le jour J+n jours et qui n'a pas été repris depuis par une autre publication disponible le jour J+n soit une source de qualité. En revanche, il me paraît très probable' qu'un contenu impossible à sourcer le jour J+n alors qu'il était sourcé le jour J sur le net soit un contenu anecdotique voire douteux. Pour moi, le fait qu'un lien sur 20 soit obsolète ne met donc pas Wikipédia en péril. C'est un dysfonctionnement mineur au regard du volume de connaissances non sourcées du tout sur Wikipédia. Et si c'est un dysfonctionnement majeur, la solution n'est pas obligatoirement technique. Cordialement. --Bruno des acacias 29 août 2008 à 10:58 (CEST)

Il peut y avoir des sites dont le contenu est très bien dans leur domaine, mais dont les gestionnaire sont mauvais dans la gestion du site. Ils vont décider un jour de rénover leur site, et vont casser tout les liens dans la manœuvre, sans penser une seconde que d'autres sites ont établi des liens vers leur pages (ou peut-être en considérant que c'est un dysfonctionnement mineur, que les visiteurs n'ont rien à perdre à repasser par leur page d'accueil qui maintenant est très bien et à partir de laquelle ils retrouveront certainement rapidement l'information qu'ils recherchent !) Maintenant on a une solution technique qui s'offre, et tu dis « la solution n'est pas obligatoirement technique », ben alors je propose que tu t'occupes d'un bot qui recherche les liens cassés, puis que pour chacun d'entre eux tu explores le site ou le web pour retrouver la source, ou bien constater qu'elle était de mauvaise qualité et en trouver une autre meilleure, et puis au passage que tu corriges et améliores l'article avec les nouvelles infos que tu aura trouvé ! Astirmays (d) 29 août 2008 à 11:38 (CEST)

Épilogue

La question me semble bien là. Devons-nous accepter la publication d'un contenu qui n'a pour seule source que des pages accessibles via des « liens morts rétablis pour Wikipédia » ? Pour ma part, je pense que la décision de mettre ou ne pas mettre en place une solution de « liens morts rétablis pour Wikipédia » ne changera pas l'avis de chacun sur ce qu'est une source de qualité. Le décision à prendre ici se limite donc à celle sur la mise en place d'un outil informatique supplémentaire. Ce qui ne retiendra pas mon attention plus longtemps, car je ne suis pas sur Wikipédia pour discuter de solutions informatiques. Merci de m'avoir fait comprendre ce qu'est un lien mort. Bonne continuation à tous. Merci de votre compréhension. --Bruno des acacias 30 août 2008 à 22:39 (CEST)

Demande de précision sur un point de la FAQ

« Les liens externes supprimés continueront-ils d'être mis en cache ? → Non, une fois supprimé de Wikipédia, le lien externe est également supprimé du cache de façon automatique. »

Comment est décidée la suppression du lien ? Est-ce un passage périodique sur les pages liés au cache, ou une suppression directe si le lien disparaît dans un diff.

Dans le premier cas, est-ce que cela ne risque pas d'augmenter singulièrement l'utilisation de la bande passante et des serveurs?

Dans le deuxième cas, l'intérêt sera assez réduit pour les pages vandalisées par blanchiement.

Je serais intéressé également par des informations sur les temps de chargement des pages avec ce système.

--Hercule ^Discuter 27 août 2008 à 18:34 (CEST)

Je plussoie Hercule, question très importante. Je m'explique : wikiwix possède le cache d'un lien mort. Le lien est enlevé temporairement (vandalisme?). Lorsqu'il est remis, wikiwix copie le lien mort et affiche un 404? Bien amicalement, Dodoïste ^{[réveille-moi]} 27 août 2008 à 21:44 (CEST)

Le système que nous mettons en place ne prend aucune ressource au serveur de la Fondation puisque nous nous servons de Wikiwix pour réaliser les mises à jours sur le cache. Nous avons d'ailleurs résolu ce problème il y a quelques mois avec l'administrateur de la Fondation. Grosso modo et pour information nous suivons en temps réel les "Recent Change" et dès que ceux - ci arrivent à un quota nous récupérons les articles modifiés ( Articles désynchronisés sur Wikiwix ) ce qui permet d'avoir un laps de temps nécessaire à la communauté pour réagir à un vandalisme. Pmartin (d) 28 août 2008 à 08:42 (CEST)

Je trouve effectivement que la question du temps de latence entre la suppression et le vidage du cache est importante. Je pense notamment au cas où une page utilisée comme source disparaît pour réapparaître après la vidange... dans ce cas-ci, on perd l'avantage sur la vérifiabilité. Il faudrait sans doute réfléchir un peu à ce point de détails technique par la suite. nojhan→☸ 28 août 2008 à 09:22 (CEST)

Et tous les vandalismes ne sont pas défaits dans la journée... Qu'en est-il si la page est déplacée (fusion d'historiques, ect.) ? Amicalement, Dodoïste ^{[réveille-moi]} 28 août 2008 à 12:42 (CEST)

Merci pour ces précisions. Pour les vandalismes restant longtemps, je pense personnellement que ce n'est pas dramatique. Même si certaines pages sont perdues il y a quand même du gain par rapport à la situation actuelle.

Pour les fusions et renommages, si le lien disparaît c'est quand même dommage. --Hercule ^Discuter 28 août 2008 à 14:38 (CEST)

Finalement les renommages et fusions ne poseront aucun problème, le cache est conservé, et le lein sera recréé sur l'autre page. Aucun souci. Amicalement, Dodoïste ^{[réveille-moi]} 2 septembre 2008 à 11:28 (CEST)

compatibilité

User:Xic667 m'a signalé le 21 août une incompatibilité avec le gadget réservé aux admins MediaWiki:Gadget-NavigAdmin.js. Voilà Dodoïste ^{[réveille-moi]} 27 août 2008 à 21:59 (CEST)

J'ai contacté Xic667 mais celà vient d'ailleurs car j'ai testé les deux et je n'ai pas eu de problème, mais je pressant plutôt un problème avec un autre "gadget" Pmartin (d) 28 août 2008 à 08:47 (CEST)

stats liens morts

Voilà un lien qui affiche l'état du cache avec un pourcentage sur les liens morts :

http://wikiwix.com/cache/?task=stats

Le lien ci-dessus est mort. Qui archivera l'archiveur ? ...--SGlad (d) 27 mai 2013 à 16:45 (CEST)

Effectivement je vais corriger rapidement les stats. --Pmartin (d) 27 mai 2013 à 17:06 (CEST)

C'est juste qu'elle est un peu longue à s'afficher :)--Pmartin (d) 27 mai 2013 à 18:20 (CEST)

Peut-être mettre une valeur en cache avec la date, en gardant un accès à l'outil complet pour les (très) patients ? ;-) --SGlad (d) 31 mai 2013 à 16:32 (CEST)

Excellente idée, je vais le faire dans les prochains jours, je te tiens au courant. --Pmartin (d) 3 juin 2013 à 16:03 (CEST)

Temps d'exécution

Pour tenter de donner une réponse à la question 1 de Maloq, j'ai créé une version modifiée du script de cache (disponible ici : Utilisateur:Guillaumito/cache2.js) qui affiche une moche boite de dialogue lorsque le script a fini son travail, pour indiquer le temps qu'il a passé à s'exécuter. Sur un article tel que Jacques Chirac, le temps qu'il me donne varie entre 120 et 250 millisecondes, donc au pire un quart de seconde. Maintenant, le script étant en javascript, il s'exécute sur la machine du visiteur et donc les performances dépendent de sa configuration et la charge de sa machine au moment de l'exécution, etc. Guillaumito (d) 28 août 2008 à 10:47 (CEST)

Ok. Pour etre franc, je trouve ça trop gros. Ca va se rajouter à d'autres scripts qui sont deja pas mal lourd, et ou j'ai eu bcp de mal à réduire le temps. J'essayerai de voir si je peux améliorer le script, mais une valeur de 100ms dans le pire des cas, pour une machine moyenne, est une valeur maximum, selon moi. Maloq ^causer 28 août 2008 à 22:48 (CEST)

Après une analyse plus poussée du temps d'exécution, il ressort que la majorité du temps était consommée à construire le tableau des liens : 80% du temps. Ce tableau est créé en utilisant la fonction getElementsByClassName fournit par MediaWiki. J'ai remplacé les 3 appels par un seul, ce qui a largement amélioré le temps d'exécution. De plus, en fouillant un peu et en suivant le lien indiqué comme référence de la fonction, l'auteur a fournit une nouvelle version, plus rapide, s'appuyant sur les capacités des navigateurs récents. J'ai donc adapté le code pour vérifier si le navigateur peut m'aider et dans ce cas, utiliser les fonctions qu'il fournit. Pour résumer:

• J'obtiens maintenant un temps d'exécution de 35 millisecondes pour la page Jacques Chirac avec Firefox 3
• Et un temps de 60 millisecondes pour la page Jacques Chirac avec un navigateur X

Encore une fois, ces résultats dépendent de beaucoup de paramètres (charge de la machine, age du capitaine, etc.) et sont donc a prendre avec une pincée de sel. Guillaumito (d) 10 septembre 2008 à 14:54 (CEST)

NB: il faudrait peut être mettre à jour la fonction getElementsByClassName dans MediaWiki

La getElementsByClassName est en général ze fonction chiante. Elle n'est pas native et codée à la main. La version actuelle est ultra optimisée, et je ne pense pas qu'on puisse faire mieux. En général, tout algo se basant sur elle est mauvais car trop long . Sur FF3, le pb est censé etre résolu car la fonction est native (si je me trompe pas), d'ou la grosse différence. Maloq ^causer 12 septembre 2008 à 00:37 (CEST)

Bon, j'ai retesté, et suis tombé sur des résultats équivalents. Sauf que tu n'as pas pris en compte le temps d'exécution des getElementsByClassName appelées, il me semble. Pour Jacques Chirac, j'ai 70ms en own time, en 210 en total time. 200ms, c'est clairement rédhibitoire pour une installation en standard. Maloq ^causer 16 septembre 2008 à 00:19 (CEST)

Complément un peu plu constructif:
Mon boulot dans la vraie vie touche de manière précise à ce genre de problématique, et, après m'etre fouillé le crane, je ne vois pas de solution pour optimiser le script de manière satisfaisante (on pourra toujours bidouiller l'algo actuel pour grapiller quelques ms de ci de la, mais rien de transcendant). En l'état, je m'oppose de manière assez vive à son installation en standard à cause de ce probleme, et j'en suis plutot désolé, l'idée me parait intéressante. Maloq ^causer 16 septembre 2008 à 00:25 (CEST)

Note, au passage, une petite idée de grapillage de ms pour le script, vous devriez utiliser la méthode cloneNode(), plutot que faire des createElement(), c'est plus court.

J'ai averti Maloq que la version améliorée du cache est sur Utilisateur:Guillaumito/cache.js, il me semble que maloq est en train de tester en ce moment même. Dodoïste ^{[réveille-moi]} 16 septembre 2008 à 00:50 (CEST)

oulaaaa, je testais avec la version de Pmartin. Je viens de tester avec ta version Guillaumito, et si le temps d'exécution propre est de 30ms, celui "tout compris" est de 1300ms . C'est du au fait que tu appelle document.getElementsByClassName('external') sans donner ni un type d'objet, ni un scope plus précis. Je vous conseille vivement d'utiliser firefox et firebug, et maitriser les notions de own time et total time pour vos tests. Maloq ^causer 16 septembre 2008 à 00:50 (CEST)

Il serait peut être bon que tu lises un peu de documentation : http://developer.mozilla.org/En/DOM/Document.getElementsByClassName

La fonction native de Firefox ne fonctionne pas exactement comme celle de Wikipeda : elle ne prend pas de paramètres tels que le type d'object ou le "scope". Il serait bien sur possible de partir d'un autre élément du DOM pour l'appeler, dans mes tests cela n'a pas affecté les temps, j'ai donc laissé tel quel. Dans tous les cas, l'appel 'normal' pour les navigateurs autres que FF3 utilise un scope, etc.

Pour ce qui est du calcul de temps, je parle bien sur de temps total et je n'ai jamais obtenu de valeur telle que 1300ms. J'ai du mal à voir d'ou peut venir un tel écart entre tes résultats et les miens. Guillaumito (d) 16 septembre 2008 à 12:15 (CEST)

En effet, tu as défini un scope, autant pour moi. Tu as utilisé quel navigateur, et dans quelle version pour tes tests? Maloq ^causer 16 septembre 2008 à 12:36 (CEST)

Bon, j'ai trouvé. D'autres gadgets définissent une méthode getElementsByClassName sur l'objet document, ce qui fait que ton script l'appelle, alors que celle-ci n'est pas une méthode native. Comme tu l'appelles sans scope ni filtre sur objet (normal), le temps d'exécution explose. J'ai testé sur un compte ou je n'avais rien de défini, et ca met 130ms, ce qui est mieux que les 200 de la version de Pmartin. Par contre, je trouve ça toujours trop, et le genre de bug décrit juste dessus illustre parfaitement ma réticence à voire installer par défaut une miriade de script qui commencent à faire des bugs de plus en plus compliqué à traquer. Je rajoute, au passage, qu'il serait normal que vous décantiez de manière précise vous-meme ce genre de probleme, et proposer des scripts rigoureux. Maloq ^causer 16 septembre 2008 à 12:46 (CEST)

Le test a été fait sur une grosse page car les grosses pages sont celles qui posent probleme de facto. De plus, dans la mesure ou on met en avant les pages comme les AdQ, les grosses pages ont naturellement une fréquentation accrue. Sinon, qu'on adapte les modèles ou pas, ça ne changement rien au script (au contraire, il va falloir tester si le modèle a deja inclu le lien, ce qui ralentira le tout). Et pour finir, je suis particulièrement attristé de voir que l'attitude tant que chez moi ça marche, je me tape du reste, les autre auront qu'a désactivé tout javascript est monnaie courante.

Je veux bien comprendre qu'on trouve que la plus-value de ce système justifie le prix à payer. Je veux aussi bien comprendre que ce genre de problème n'est pas accessible au commun des mortels. Mais ça commence à me gaver, ça fait 6 mois que je m'escrime à limiter l'explosion du temps de chargement des pages sur tous les plans et ça fait 6 mois que je me farci des quidams qui, tout en proférant des absurdités, emmettent des avis arrétés sur des problemes qu'ils ne maitrisent pas. Maloq ^causer 20 septembre 2008 à 13:21 (CEST)

Merci pour ta réponse et pour tes efforts d'améliorer le système. En ce qui concerne le modèle, il y a une affirmation plus haut sur cette page qui dit que le modèle n'utilise pas de script. On peut très bien ajouter un lien vers le cache sans aucune vérification. Enfin, ce n'est pas du tout l'attitude « tant que ça marche chez moi » puisque, chez moi, ça ne marchera pas (pas de javascript [sauf pour liveRC, mais ce n'est pas sur mon ordinateur personnel]). Je pense avant tout à la pertinence de la fonctionnalité pour l'encyclopédie. Voir aussi le vote de Lilyu au-dessus du mien. — Jérôme 20 septembre 2008 à 13:45 (CEST)

Oui, une modification des modèles ne nécessitera un repassage à posteriori de script. Mais si on choisit d'exécuter le script par défaut, modèle ou pas, le script s'exécutera. Et il faudra en plus le modifier pour qu'il ne rajoute pas un second lien vers le cache sur les liens externes l'ayant deja affiché via le modèle, ce qui le ralentira.

Sinon, oui j'ai bien compris l'avis de Lilyu. Et je sais que ce que ça implique au niveau performance ne parle à quasiment personne. Mais SVP, évitons de parler d'argumentation injustifiée, c'est suffisamment compliqué comme ça. Maloq ^causer 20 septembre 2008 à 16:23 (CEST)

Dans mon idée, et qui est discutée ici même dans sa formulation depuis plusieurs jours, il s'agit d'une alternative (choix d'une proposition unique parmi plusieurs) : soit on utilise le script (utilise du temps mais marche sur tous les liens), soit on utilise un modèle, exactement comme fait {{Lien mort archive}} (aucun temps d'exécution pour le lecteur mais ne marche que sur les liens marqués du modèle, d'où la nécessité de recourir à un bot). Je ne suggérais nullement de repasser avec un script « par dessus » le modèle (et suis même plutôt contre cette méthode, aussi bien pour les raisons de performance que tu cites que pour la clarté de la conception). — Jérôme 20 septembre 2008 à 17:04 (CEST)

(Afin d'éviter tout malentendu : l'idée d'utiliser des modèles n'est pas initialement de moi et je ne chercher pas à m'en récupérer le crédit ; quand j'écris « mon idée », je fais seulement référence au texte « mise en œuvre » en page de vote, dont j'espère qu'il n'a pas trahi les idées d'origine. — Jérôme 23 septembre 2008 à 09:21 (CEST))

Maloq : Le cache de Guillaumito est prévu pour ne pas s'exécuter si le nombre de liens dans la page excède 50, tandis que celui de Pmartin (l'original) est limité à 250 liens. Cela date d'avant la PDD, il a été oublié de le mentionner. J'en suis désolé. Cela restreint les problèmes liés à l'accessibilité des grosses pages, mias cel apose un souci pour la vérification (accès au cache) sur ces mêmes pages. Amicalement, Dodoïste ^{[réveille-moi]} 21 septembre 2008 à 22:33 (CEST)

Date de l'archivage

Pour moi, c'est la date d'insertion qui compte : il ne faudrait pas mettre à jour le cache après. Donc, si un lien est inséré lundi, et que la page pointée disparait vendredi, c'est la version de lundi qui est mise en cache, pas celle de jeudi.

Qu'est-ce qui est prévu en l'état ? La date d'insertion ou celle de la disparition ? nojhan→☸ 28 août 2008 à 11:43 (CEST)

La date d'insertion :) Pmartin (d) 28 août 2008 à 11:51 (CEST)

Il faut renommer « cache » en « archive »

Le système proposé n'est pas un système de cache (comme le cache de Google) mais d'archive (comme l'archive d'Internet Archive). Un système de cache sert à accélérer l'accès et cherche à être le plus synchronisé qu'il peut avec la ressource cachée. Un système d'archive sert à conserver une copie datée et figée de la ressource archivée, sans s'occuper de vitesse d'accès. Il faut renommer cette PdD pour cesser d'induire les gens en erreur. En effet, la différence importe aussi bien techniquement que légalement.

Techniquement, ce qui est proposé fonctionne comme Internet Archive : le but est de proposer pour toujours une copie figée de la ressource telle qu'elle était à un instant donné. Google cache fonctionne très différemment (comme son nom l'indique…) : le but est de proposer une copie de la dernière version connue de la ressource. Dès que le système de cache remarque que la ressource originale a changé ou disparu (ce qui prend entre quelques heures et quelques jours), alors le cache est mis à jour, et le cas échéant la ressource est virée du cache.

Légalement, il existe une exception au droit d'auteur (L122-5.6 en France) pour : La reproduction provisoire présentant un caractère transitoire ou accessoire, lorsqu'elle est une partie intégrante et essentielle d'un procédé technique et qu'elle a pour unique objet de permettre l'utilisation licite de l'oeuvre ou sa transmission entre tiers par la voie d'un réseau faisant appel à un intermédiaire ; toutefois, cette reproduction provisoire qui ne peut porter que sur des oeuvres autres que les logiciels et les bases de données ne doit pas avoir de valeur économique propre ; Cette exception vise les caches mais pas les archives, qui ne sont par définition pas « provisoires ». Marc Mongenet (d) 28 août 2008 à 16:33 (CEST)

Marc en fait c'est un peu des deux que nous proposons, c'est à dire que l'outil que nous fournissons réagit comme un cache tant que le lien source est en ligne, mais lorsque celui-ci disparaît devient donc 404 nous gardons la dernière version que nous avons récupéré. Cordialement Pmartin (d) 29 août 2008 à 10:14 (CEST)

La section plus haut, tu dis le contraire, à savoir que la page archivée est celle de la date d'insertion... De ce que je comprends, on n'archive jamais qu'une seule version, en fait, mais celle-ci disparait quand si le lien est retiré. J'ai bon ou pas ?

Le terme d'archive me parait en effet plus approprié, après la remarque de Marc. Et puis, ça ne change pas grand chose de changer de terme, surtout si c'est plus clair. nojhan→☸ 29 août 2008 à 21:06 (CEST)

En fait, contrairement au site comme archive.org, nous ne stockons qu'une version par page, et nous mettons à jours cet enregistrement à jours au fil des différentes mises à jours produites par le site.Pmartin (d) 30 août 2008 à 09:34 (CEST)

Pour moi ils serait bon de ne pas mettre à jour le cache. De même je comprends l'intérêt de supprimer les caches inutilisés depuis quelques jours, mais pour moi il y a bien trop de fluctuations en quelques jours. Supprimer après un mois reviendrait au même pour vous (niveau espace disque) et fournirait un cache bien plus fiable et utile pour nous. Dodoïste ^{[réveille-moi]} 30 août 2008 à 13:52 (CEST)

Je pense également qu'il ne faudrait pas mettre à jour le cache, ce qui est intéressant dans le cas d'une référence, par exempe, c'est d'avoir la version qui a été utilisée comme source à l'origine, pas la dernière version. Éventuellement, il faudrait un moyen de demander la mise à jour du cache, par exemple si un contributeur a constaté que la page avait subit une correction quelqu'oncque allant dans le sens de l'intérêt encyclopédique. nojhan→☸ 30 août 2008 à 21:55 (CEST)

J'y ai songé, mais il suffit qu'un vandale mette à jour alors qu'il ne faut pas, et on se retrouve avec un 404. C'est la grosse différence avec internet archive. Ou alors il faudrait qu'une discussion accepte unanimement la mise à jour et qu'une demande soit faite à wikiwix. Sinon il y aura trop d'abus àmha. Dodoïste ^{[réveille-moi]} 30 août 2008 à 22:26 (CEST)

Bien vu, cependant, vu qu'on souhaite éviter les liens morts, on ne va pas mettre à jour si la page n'existe plus :-) Cependant, on peut se poser la question quant à des mises à jours "mal intentionnées". Après plusieurs années de wikipédia, je dirais qu'il suffirait d'archiver plusieurs versions et de pouvoir revenir en arrière, mais ce ne serait plus un cache, et vraiment une archive, peut-être que ça gènerait Linterweb à ce moment là. Sinon, les cas de mal-intentions étant quand même assez pointus, ça n'est peut-être pas la peine de se prendre la tête dessus. nojhan→☸ 31 août 2008 à 22:59 (CEST)

Pour revenir au sujet initial de cette section, l'emploi de l'anglicisme cache (traduisible en français par « tampon de mémoire », « mémoire-tampon », « antémémoire ») n'est pas souhaitable : d'abord le mot anglais désigne un contenant et non un contenu (d'où l'expression to flush the cache, vider l'antémémoire), ensuite l'anglicisme n'en sera qu'encore plus en conflit avec les deux mots « cache » en français, l'un féminin, « une cache » (comme dans une cache d'armes) et l'autre masculin, « un cache » (pour occulter, = un masque). Il est question de pièces archivées, alors pourquoi ne pas adopter un terme compréhensible de tous, par ex. « un archivage » (comme on dit « un arrivage ») (je ne propose pas l'anglicisme « une archive » car ce terme en anglais signifie d'abord le contenant (le dépôt d'archives, le fonds archivistique) avant le contenu (la pièce archivée). Cela permet d'employer le verbe « archiver », sinon l'on va se retrouver avec « cacher une source » et le risque de confusion que cela va créer.--Elnon (d) 18 décembre 2008 à 15:42 (CET)

Juste une remarque en passant: pour ce qu'en voient les utilisateurs, seul le terme « archive » est employé (le lien ajouté dans les articles). Le terme « cache » ne relève que de la « cuisine interne » de cette fonctionnalité, où les éventuels dommages collatéraux sur la langue n'ont peut-être rien de bien dramatique --Lgd (d) 18 décembre 2008 à 18:16 (CET)

/Merci de ces éclaircissements qui me rassurent. --Elnon (d) 18 décembre 2008 à 18:30 (CET)

Notes

Il me semble que les liens morts dans les notes (ref) sont plus génant encore qu'en liens externes, ne devrait il pas y avoir une procedure particulière pour les identifier et les corriger. 81.252.135.249 (d) 2 septembre 2008 à 08:17 (CEST)

Si, il manque juste de la main d'oeuvre : Projet:Correction des liens externes. Tu y est le bienvenu :) Dodoïste ^{[réveille-moi]} 2 septembre 2008 à 11:26 (CEST)

(cache) indicé

Juste une objection sur la présentation. Je trouve bizarre que le lien cache soit indicé. Il n'y a amha aucune raison pour que ce mot ne soit pas sur la même ligne. --pixeltoo⇪員 4 septembre 2008 à 10:30 (CEST)

Ben en effet. Moi je trouve plus présentable et lisible. Mais bon c'est discutable... Tu préférerais comment ? Dodoïste ^{[réveille-moi]} 4 septembre 2008 à 12:15 (CEST)

Tous^surune même _{même ligne} ça me parait plus simple et moins surréaliste que ^commeça . « Les multiples ne doivent pas être utilisés sans nécessité » G. Occam --pixeltoo^⇪員 4 septembre 2008 à 13:20 (CEST)

Date de l'archivage/mise en cache (bis)

Je ne comprends plus rien. Les deux interventions suivantes me semblent contradictoires :

Le cache concerne la date d'insertion

Pour moi, c'est la date d'insertion qui compte : il ne faudrait pas mettre à jour le cache après. Donc, si un lien est inséré lundi, et que la page pointée disparait vendredi, c'est la version de lundi qui est mise en cache, pas celle de jeudi.
Qu'est-ce qui est prévu en l'état ? La date d'insertion ou celle de la disparition ? nojhan→☸ 28 août 2008 à 11:43 (CEST)
La date d'insertion :) Pmartin (d) 28 août 2008 à 11:51 (CEST)

Ah si finalement il est mis à jour après l'insertion

nous ne stockons qu'une version par page, et nous mettons à jours cet enregistrement à jours au fil des différentes mises à jours produites par le site.Pmartin (d) 30 août 2008 à 09:34 (CEST)

Je crois aussi qu'il ne faut pas mettre le cache à jour. L'intérêt d'un tel système est de permettre de retrouver une information telle qu'elle était présente le jour où le lien a été inséré, pour le cas où elle disparaitrait. Si vous mettez à jour le cache régulièrement, comment garantissez-vous que l'information que l'on source par une <ref> sera toujours présente sur la page après mise à jour par le webmaster ? — Jérôme 14 septembre 2008 à 17:46 (CEST)

De fait, le cache n'a pas eu de mise à jour.

La majorité d'entre nous sommes également d'avis que le cache ne devrait pas être mis à jour. J'ai tenté de joindre User:pmartin pour se mettre au clair là-dessus, mais il va falloir attendre Lundi. À suivre donc. Amicalement, Dodoïste ^{[réveille-moi]} 14 septembre 2008 à 18:17 (CEST)

Jerome Dodoiste, le cache est dédié pour la communauté Wikipedia, donc évidement si le mode de mise à jours vous dérange, il est tout à fait envisageable de le retirer. Pmartin (d) 15 septembre 2008 à 02:37 (CEST)

Je crois constater que tout le monde est d'accord pour dire que les pages ne devraient pas être mises à jour après l'insertion du lien. Pour les éventuels problèmes annexes, il me parait sain de voir après un peu d'utilisation du système. nojhan→☸ 15 septembre 2008 à 09:54 (CEST)

Présentation de la PDD

Bonjour,

je crois qu'il serait bon de clarifier certaines choses sur la page de vote (ça y est déjà plus ou moins) :

• Linterweb a décidé de mettre en place un système de cache (et on n'a rien à dire contre).
• le vote porte sur les conditions dans lesquelles un lien vers ce cache serait ajouté aux pages de Wikipédia (la seule chose sous notre contrôle)

Il manque, à mon avis, quelques détails techniques ou esthétiques sur ce qui pourrait être modifié à la demande de la communauté. Pas forcément pour les graver dans le marbre, mais pour éviter les objections récurrentes sans rapport avec le schmilblick (on ne sait pas sur quoi on vote ; il ne faut pas graver dans le marbre des trucs flous ; le vote est invalide, le contenu des questions a changé en cours de vote ; je vote « non » parce que je n'aime pas la police de caractères...) :

• esthétique du lien (exposant, pas exposant...) → pas de souci, ça relève de nous (via une demande d'intervention sur une page protégée)
• fonctionnement du cache, notamment la mise à jour → on a eu un débat ci-dessus, pourrait-on inclure cette question dans la PDD (préférez-vous l'un, l'autre, peu importe) ou mentionner les conditions dans lesquelles on pourrait passer d'un système à l'autre si on remarque un problème (si le système ne donne pas satisfaction, si Linterweb a un problème juridique...)
• ... (à compléter)

Par ailleurs :

• Une critique a été soulevée plus haut concernant la rapidité d'exécution du script envisagé. Je propose une sous-proposition au premier cas : le javascript (dans le cas où il est activé par défaut pour la classe X de visiteurs, p.ex. les utilisateurs non enregistrés), ne comporte par défaut, pour cette classe de visiteurs, qu'un lien qui demande, s'il est cliqué, l'exécution complète du script ajoutant les liens du cache. Cela rendrait le script par défaut très rapide d'exécution, tout en permettant l'accès à la fonctionnalité à tous les visiteurs. Et cela éviterait des votes « non » pour la raison de performance sur le poste client.
• Vu la procédure d'adoption retenue, j'imagine que le cache concerne uniquement wikipédia fr. Y Est-ce une première étape, ou la dernière ?
• Le début du vote était aujourd'hui à 0h1 CEST, ou c'est reporté ?

— Jérôme 15 septembre 2008 à 15:11 (CEST)

Alors dans l'ordre :

• 1 et 2 : je ne suis pas sûr de comprendre ce que tu veux corriger, je te propose de faire les modifications que tu propose, au pire je réverte. (Mais j'ai l'intuition que je n'en aurai pas besoin )

• 3 et 4 : Je fais cela dans un moment, hésite pas à retoucher ! Dodoïste ^{[réveille-moi]} 15 septembre 2008 à 23:42 (CEST)

• 5 : Désolé je ne m'y connais pas en programmation, je passe la main
• 6 : Nous n'en avons pas encore discuté. Si le cache est s'avère convaincant sur .fr, alors cela sera AMHA une première étape : wikipedia.en y verra probablement un intérêt.
• 7 : Le début du vote était aujourd'hui à 0h1 CEST ! Dodoïste ^{[réveille-moi]} 15 septembre 2008 à 22:07 (CEST)

1 et 2, oublie, c'est suffisamment clair, je ne devais pas être bien réveillé.

5, la faisabilité ne me semble pas poser de problème, ma question porte en réalité sur l'opportunité de le mettre effectivement en place, sans pour autant violer une prise de décision qui ne le mentionnerait pas. D'où la suggestion d'en faire une sous-proposition. Mais si le vote a commencé, je dirais que c'est trop tard (pour l'instant, on a un seul votant, éventuellement ça pourrait encore se faire). — Jérôme 16 septembre 2008 à 10:54 (CEST)

Proposition subsidiaire à la 1

Selon la proposition ci-dessus de Jérôme, j'ai l'intention d'ajouter une proposition subsidiaire à la n°1 : activer le cache via un bouton dans la boîte à outils. Qu'en pensez-vous ? Dodoïste ^{[réveille-moi]} 16 septembre 2008 à 17:18 (CEST)

Semblable à Internet Archive ou Google Cache ?

En introduction de la PdD on lit : « Cette prise de décision porte sur la mise en place d'un cache spécifique à Wikipédia, semblable à Internet archive ou google cache.» Alors finalement c'est semblable à Internet Archive ou à Google Cache ? (Prière de ne pas répondre « oui » :-) Il faudrait tout de même être un peu plus précis pour qu'on puisse décider en connaissance de cause. D'après la description qui suit dans la page de PdD, il s'agit d'un système qui archive le document pointé dès qu'un lien depuis Wikipédia est détecté. Si un même lien est détecté plus tard dans une autre page de Wikipédia, ce qui arrive n'est pas expliqué. Marc Mongenet (d) 16 septembre 2008 à 21:28 (CEST)

Le « semblable à Internet archive ou google cache » est juste là pour signaler l'existence des points de comparaison. Après ça ce cache est très différent de ses deux homologues. Je corrige de suite.

Si un même lien est archivé dans plusieurs pages, les liens renvoient vers la même page, mise en cache à la date d'insertion du premier lien. Puisque l'adresse des pages en cache est http://wikiwix.com/cache/?url= + adresse du lien en question, le même lien ne peut être archivé qu'une fois. Dodoïste ^{[réveille-moi]} 16 septembre 2008 à 21:51 (CEST)

Mode de vote

Je crois que le mode de vote choisi n'est pas bon, il faudrait en changer rapidement.

Je m'explique : il faut choisir entre trois propositions, qui sont contradictoires mais qui reflètent une échelle. Par exemple, je suis personnellement pour les trois, au sens où je ne vois pas d'objection à la 3e proposition, donc forcément j'accepterais aussi les 2 premières.

Il y a donc un biais dans le système de vote, qui va mécaniquement favoriser la 1e proposition. Je met ma main à couper que c'est celle qui aura « le plus de votes pour et le moins de votes contre », c'est inévitable.

Or, on voudrait choisir la meilleure proposition, pas décider de laquelle est la moins invasive. Il faudrait donc plutôt utiliser un système de classement, en demandant aux gens de classer les trois propositions dans l'ordre qu'ils préfèrent.

Est-ce qu'on peut suspendre le vote le temps de faire le point là-dessus, avant que trop de monde n'ait voté ? nojhan→☸ 17 septembre 2008 à 10:43 (CEST)

Je suis également favorable à la suspension du vote le temps de reprendre la formulation des questions. — Jérôme 17 septembre 2008 à 11:57 (CEST)

Proposition de formulation :

1. Devrait-on activer le javascript par défaut pour tous les visiteurs ?
   Au cas où la proposition 1 serait rejetée :
2. Devrait-on activer par défaut le javascript par défaut pour les utilisateurs enregistrés ?
   Au cas où les propositions 1 et 2 seraient rejetées :
3. Devrait-on modifier le modèle {{lien web}} pour afficher le lien cache ?

— Jérôme 17 septembre 2008 à 12:03 (CEST)

Oubliez, je n'ai pas bien compris la modification proposée de {{lien web}} proposée. Fait-elle appel à un javascript ou pas ? J'imagine que non (sinon c'est super moche). Mais si elle n'y fait pas appel, alors du point de vue performances c'est tellement mieux du point de vue performances (pas nécessairement du point de vue de l'efficacité, puisque ça limite le cache aux liens pour lesquels un modèle est présent) que ça change totalement la nature du vote pour plusieurs contributeurs. Dans ce cas le système serait de fait activé par défaut, la seule question étant celle de la CSS d'affichage (si on masque le lien ou si on l'affiche, et si oui pour qui). J'aimerais bien avoir des éclaircissements là-dessus. — Jérôme 17 septembre 2008 à 12:15 (CEST)

Si c'est bien comme je dis plus haut, ça change la nature du vote, en :

1. Devrait-on mettre en place le système par un modèle ou par un javascript ?
2. Au cas où la solution du modèle est adoptée, le lien devrait-il être affiché par défaut A) Pour tout le monde B) Seulement pour les inscrits C) Pas d'activation par défaut.
3. Au cas où la solution du javascript est adoptée, le javascript devrait-il être activé par défaut A) (idem)

— Jérôme 17 septembre 2008 à 12:23 (CEST)

Il n'y a pas besoin de faire appel à un javascript pour Lien web. Dodoïste ^{[réveille-moi]} 17 septembre 2008 à 13:42 (CEST)

En lisant les votes, je suis moi aussi favorable à la méthode Condorcet. J'y avais songé, mais je ne me souviens plus de la raison pour laquelle j'avais écarté l'idée :s

Je propose par méthode condorcet :

1. Proposition 1 actuelle
2. Proposition 2 actuelle
3. Proposition 3 actuelle
4. Laisser le cache tel qu'il est actuellement.

Au cas où la proposition 4 serait retenue, doit-on modifier les modèles {{lien web}} et autres?

Au cas où la proposition 1 serait retenue, doit-on modifier le modèle {{lien web}} et autres modèles? Amicalement, Dodoïste ^{[réveille-moi]} 17 septembre 2008 à 13:42 (CEST)

Je suis également pour limiter les propositions. Par exemple, l'inclusion ou non dans le modèle lien web me parait relever de l'anecdote technique : le modèle n'est pas universellement utilisé et il n'est pas non plus obligatoire de passer par lui. De la même manière, la proposition « laisser tel quel » est strictement équivalente à l'emploi d'un gadget décoché par défaut. Inutile, donc, à mon sens, de mutliplier les choix techniques, la vraie question est celle de l'activation par défaut et des utilisateurs enregistrés ou non. Les aspects techniques de mise en place suivront naturellement, sans qu'il y ai besoin de faire de votes de 3 mois.

Je propose donc un vote par classement (type Condorcet, si ça parle à tout le monde, pourquoi pas), sur les 3 propositions de base. Restons simple et clair. nojhan→☸ 17 septembre 2008 à 14:08 (CEST)

Pas d'autres remarques ? Sinon autant passer au vote Condorcet tout de suite... nojhan→☸ 19 septembre 2008 à 10:52 (CEST)

Condorcet c'est parfait, mais j'ai fait une remarque à Discussion Utilisateur:Dodoïste#Wikipédia:Prise de décision/Système de cache. — Jérôme 19 septembre 2008 à 11:09 (CEST)

Dépouillement des bulletins incomplets

Certains votants indiquent une seule proposition (3). La possibilité de rendre un bulletin de vote incomplet n'est pas indiquée dans la Méthode Condorcet. Doit-on considérer :

• 3 > 1 = 2 (conséquence de l'application de la Méthode Schulze)
• 3 > aucune des propositions ci-dessus (suggéré par Wikipédia:Prise de décision/Choix dans les votes#B - Proposition n°7 : Méthode Condorcet)
• 3 > aucune des propositions ci-dessus > 1 = 2 (puisque de toute façon on applique la méthode Schulze, cela se ramène à ça)

Il faudrait aussi prévenir les votants de l'interprétation qui sera donnée de leur vote, avant la clôture de celui-ci. — Jérôme 20 septembre 2008 à 16:13 (CEST)

Il me semble que c'est indiqué dans Wikipédia:Prise de décision/Système de cache#Vote : « Si les 3 choix ne sont pas listés, les choix non exprimés sont tous classés à égalité et derniers. » Ce qui signifie que :

• 3

sera interprété comme :

• 3>2=1

D'autres méthodes sont en effet envisageables. Par contre je vois mal comment comptabiliser aucune des propositions ci-dessus. Cela est généralement utilisé dans le cas où l'on refuse toutes les propositions. Dans le cas où l'on en accepte certains, mais refusent d'autres, à mon avis on sort de la méthode Condorcet. Amicalement, Dodoïste ^{[réveille-moi]} 20 septembre 2008 à 17:05 (CEST)

Ah pardon je n'avais pas vu que tu l'avais écrit. Tout va bien. — Jérôme 20 septembre 2008 à 17:59 (CEST)

maj du tableau du contributeur svp

Bonjour. Tout est dans le titre. Cordialement. --Bruno des acacias 20 septembre 2008 à 16:28 (CEST)

Euh... Je sais pas si c'est moi, mais àmha quelques détails seraient bienvenus je pense. J'ai vraiment pas compris. Amicalement, Dodoïste ^{[réveille-moi]} 20 septembre 2008 à 17:39 (CEST)

Bruno, faisais-tu référence à Wikipédia:Accueil/Tableau, dit « tableau de bord du contributeur » ? La page de vote y est bien mentionnée, quel est le problème ? — Jérôme 23 septembre 2008 à 09:24 (CEST)

Vote préliminaire

Pourquoi n'y a t'il pas un vote préliminaire pour savoir si la communauté est d'accord d'adopter ce système de cache ? Même si l'issue aurait probablement été sans grande surprise, je penses que ce vote aurait eu le mérite d'exister. Noritaka666 (d) 21 septembre 2008 à 14:57 (CEST)

Parce que Linterweb n'a pas besoin de notre autorisation pour mettre en place un cache à ses frais sur ses serveurs. La seule chose qui est dans notre pouvoir, c'est de lui donner un accès facile (ou pas) depuis Wikipédia. — Jérôme 21 septembre 2008 à 16:15 (CEST)

J'ajouterais que si la proposition retenue est « désactivé par défaut pour tous », c'est très exactement équivalent à un « non » à ta question... inutile de multiplier les votes inutilement. nojhan→☸ 21 septembre 2008 à 21:35 (CEST)

En effet c'est pas faux, merci pour les précisions Noritaka666 (d) 22 septembre 2008 à 00:44 (CEST)

Question subsidiaire

Je crains déjà depuis un moment que la moitié de la proposition 1 n'aie pas été bien comprise : un bouton dans la boîte à outils pour activer le cache à volonté. Et ce, sans les limites du cache (ne traite pas les pages de plus de 50 liens externes, moins envahissant). C'est une proposition qui n'a pas été longuement discutée, quel est votre avis ? Amicalement, Dodoïste ^{[réveille-moi]} 22 septembre 2008 à 21:37 (CEST)

Bonjour, penses-tu qu'il faudrait clarifier la formulation ?

Mais il me semble que les votants se soient focalisés sur la désactivation par défaut, sans trop considérer l'existence ou pas de ce lien dans la boite à outils. Ce qui signifie, si la proposition 1 est rejetée, que les votants ne sont pas réellement opposés à l'existence de ce lien. On pourrait par exemple le faire afficher par le script (si une solution 2 ou 3 est retenue) sur les pages où le script refuse de fonctionner. Possibilités (en vrac) :

• spécifier la limite maximale dans une préférence utilisateur.

Au cas où la page contient trop de liens :

• traiter quand même les 50 (ou 250) premiers liens. Dans ce cas, on conserve une fonctionnalité minimale. Il se peut que le lecteur se demande si l'absence de traitement après X liens est un bug.
• ajouter le lien de la boite à outil qui demande le traitement des liens externes indépendamment de leur nombre ('utilisateur sait que ça peut prendre du temps).
• afficher un message en haut ou en bas de page, qui renvoie à la page d'aide, à la boite à outil, aux préférences utilisateur...

— Jérôme 23 septembre 2008 à 09:16 (CEST)

Régler tant de préférences utilisateurs, alors qu'on ne désire pas utiliser le cache, mais juste ne pas voir le chargement des ses pages ralentir (surtout si on a une connexion faible débit), ne me plaît guère. Il faudrait alors modifier à nouveau ses préférences si on désire avoir le cache sur un AdQ... Bref peu pratique

Je suis plutôt pour cette proposition ci : « Ajouter le lien de la boite à outil qui demande le traitement des liens externes indépendamment de leur nombre (l'utilisateur sait que ça peut prendre du temps). » Cette proposition permet de charger le script uniquement quand on en a besoin. Dodoïste ^{[réveille-moi]} 24 septembre 2008 à 14:33 (CEST)

De l'interprétation du résultat

Depuis peu, une option supplémentaire devient envisageable (en cumulant la gestion par bot, l'accès au cache via modèles, la boîte à outils et le gadget [détails en cours de rédaction]), qui a de très nombreux avantages sur la proposition n°3, et qui devrait àmha mettre tout le monde d'accord, au vu des arguments données.

De plus, les utilisateurs on décidés de motiver leur choix dans ce vote Condorcet. Certains émettent des propositions, d'autres demandent des précisions et d'autres encore demandent des changements sur certains points (détails ou éléments cruciaux confondus). Sans oublier ceux qui s'opposent avec des arguments pertinents, ni ceux qui approuvent avec des conditions.

• Je propose de prendre en compte ce premier vote comme le choix d'une utilisation soit restreinte soit large du cache. (À voir les résultats actuels, ce sera plutôt large.)

• Je propose donc qu'à la fin de ce vote, une seconde phase de discussion s'ouvre; dans laquelle nous discuteront des différentes options, des détails, des choix envisagés. Et de préparer une seconde partie dans cette prise de décision, cette fois décidant de la manière générale de gérer la correction des liens externes. Amicalement, Dodoïste ^{[réveille-moi]} 24 septembre 2008 à 14:33 (CEST)

De toute façon, il est certains que les aspects techniques et mise en place sont à discuter. La prise de décision vise à... décider effectivement la portée. Après, je ne pense pas qu'il soit nécessaire de relancer une autre prise de décision pour le détail, une discussion devrait suffire, sauf à rencontrer des oppositions fortes qui empêche le consensus... nojhan→☸ 24 septembre 2008 à 17:07 (CEST)

Je suis moi aussi pour un consensus autant que possible. Amicalement, Dodoïste ^{[réveille-moi]} 24 septembre 2008 à 21:59 (CEST)

Pour les détails de la proposition à discuter à la fin de la PDD, j'ai fait un brouillon ici : Utilisateur:Dodoïste/bac à sable perso. Tous commentaires bienvenus Amicalement, Dodoïste ^{[réveille-moi]} 24 septembre 2008 à 22:52 (CEST)

Hébergement et responsabilité

4 uniquement. Je définis 4 comme "pas de cache du tout". Raison : Le cabinet d'avocat de Linterweb défend les intérets de l'hébergeur du cache, qui peut se retrancher derrière la LCEN et la responsabilité limitée de l'hébergeur, donc il n'est pas a priori surprenant que ce cabinet ne voit pas de risque pour son client. Mais c'est le Wikipédien individuel qui introduit le lien externe qui risque fort d'être le lampiste qu'on punit en cas de problème de délit de presse ou de droit d'auteur. Voir sur Projet:Sources/Chez Manon/archive 7#Sourçage et site web qui ferme - demande de conseil un cas concrêt de site qui avait fermé et qu'il me paraissait imprudent de ressusciter. Teofilo ◯ 29 septembre 2008 à 13:12 (CEST)

L'éditeur incluant un lien ne peut pas être poursuivi pour violation du droit d'auteur (il n'a rien rediffusé), ni diffamation (il n'a rien affirmé). D'ailleurs, le lien que tu cites ne prouve pas que le site a fermé pour cause de diffamation, c'est juste une hypothèse que tu lances au hasard d'une discussion. Dans tous les cas, si problème il y a, ça retombera sur Linterweb, charge à eux de se défendre, que ce soit en invoquant un statut d'hébergeur ou autre. Il y a peut-être un risque que la Wikimedia Fundation doivent imposer un retrait de l'extension si jamais Linterweb est condamné, mais je ne vois pas en quoi on pourrait craindre qu'un wikipédien incluant un lien soit inquiété. Pour moi, ce genre d'élucubrations, c'est du FUD, jusqu'à preuve du contraire. nojhan→☸ 29 septembre 2008 à 14:30 (CEST)

Tu mélanges beaucoup de choses et ce serait compliqué de te répondre point par point, mais nous sommes d'accord sur ceci : « Linterweb, charge à eux de se défendre, que ce soit en invoquant un statut d'hébergeur ou autre » et c'est déjà beaucoup. Je souligne "statut d'hébergeur". Une fois qu'il est établit que Linterweb n'est pas responsable, vers qui le plaignant va-t-il se tourner pour faire porter la responsabilité ? Teofilo ◯ 29 septembre 2008 à 15:12 (CEST)

Les trois messages ci-dessus sont recopié (pour le premier) et déplacés (pour les suivants) depuis la page principale Teofilo ◯ 29 septembre 2008 à 15:29 (CEST)

Société Linterflora, selon Dodoïste

De quel droit accuserait-il le Wikipedien ? Et de quoi exactement ? Diffusion de fausse nouvelle ou diffamation ne peuvent s'appliquer que si le Wikipedien semble reprendre a son compte les declarations problematiques, pas seulement si leur existence est signalee et attribuee. Le travail des journalistes est encore autorise, tout autant que celui d'encyclopediste. Le wikipedien m'a pas non plus republie le texte problematique, seulement signale l'endroit ou il se trouvait, avant d'avoir ete interdit (ex : « mon boulanger en affiche une copie dans sa vitrine, allez-y voir »). A charge a ceux qui le recopient (linterweb, mon boulanger...) de reagir promptement comme le leur prescrit la loi, et de retirer les textes publies integralement, des leur interdiction. — Jérôme 29 septembre 2008 à 15:49 (CEST)

Si un lien est problématique, il suffira de l'enlever et il est prévu que si le lien n'est pas restauré par la suite la page en cache sera supprimée. Ca fonctionnerais un peu pareil qu'une page copyvio mais du coté de linterweb. J'ai bon?--M.A.D.company ^{[keskisspass?]} 29 septembre 2008 à 15:59 (CEST)

Imagine que tu es commerçant également, par exemple fleuriste. Tu vois une affiche chez le boulanger, tu la prends en photo ou tu la photocopies et tu la mets sur la vitrine de ta propre boutique en te disant "comme ça, si le boulanger la retire, les gens pourront toujours venir chez moi pour la lire". Après ce scénario, si l'agent de police qui passe par là trouve que l'affiche enfreint la loi, je doute que l'explication "ce n'est pas moi qui ai commencé, c'est le boulanger" soit suffisante pour se disculper, surtout si entre temps le boulanger s'est ravisé et a retiré l'affiche chez lui. Teofilo ◯ 29 septembre 2008 à 17:25 (CEST)

Oui, mais je ne suis pas le fleuriste, je suis le rédacteur du Journal du Village, et j'écris : « monsieur Untel a publié un article intitulé : « Le juge du village est un imbécile corrompu » <reff>Article publié sur le panneau du boulanger tel qu'il était visible le 27 septembre (ou, au cas où le panneau aurait changé entre-temps, chez le fleuriste qui a pris une photo du panneau du boulanger le 29 septembre).</reff>. »

Ce que tu me décris c'est le système qui a existé jusqu'à maintenant et qui fonctionne à peu près bien. Mais la société Linterflora te propose un local gratuit avec une grande vitrine pour un commerce de fleuriste et une photocopieuse pour photocopier tout ce que le boulanger raconte de passionnant chez lui. Que réponds-tu à la proposition ? Moi je réponds "merci, mais non merci". Teofilo ◯ 29 septembre 2008 à 19:15 (CEST)

Voici la situation. Un tiers créé un site web archivant des pages webs. Il se trouve que ces archives sont utiles à Wikipédia. Ces archives étant utiles, les wikipédiens décident de généraliser les liens vers ce site. Aucune reproduction de contenus, juste création de liens. Où est le risque pour le wikipédien? :) schiste 29 septembre 2008 à 21:48 (CEST)

+1 Si tu n'est pas convaincu tu peux toujours demander sur Wikipedia:Legifer, ils sauront te répondre. Amicalement, Dodoïste ^{[réveille-moi]} 29 septembre 2008 à 22:20 (CEST)

(conflit d'édition, c'est vrai que la discussion a plus la place sur Legifer, mais j'ai déjà passé un bon moment à écrire ce qui suit...)

Le cas problématique qu'évoque Teofilo est (je pense) celui où le cache copierait une page au contenu illégal (et que Wikipédia contribue donc à propager). La seule affaire proche et dont on ait parlé ici est l'affaire Fuzz. Le débat avait porté sur qui avait la qualité d'éditeur, et la conclusion a été que c'était le gestionnaire du site (bien que des utilisateurs aient entré le lien). Je ne généralise pas au cas Wikipédia, où l'agencement des liens repose bien plus sur la volonté de contributeurs identifiés que sur la mécanique logicielle de fuzz dont le seul responsable (légal) est le webmaster.

Mais dans tous les cas, si procès il y a lieu contre lampiste, c'est qu'en tout premier lieu le lampiste avait ajouté un lien vers un site au contenu illégal, ce qu'il aurait dû vérifier dès le début (WP:LE#Choisir un « bon » site externe demande d'éviter les sites à contenu illégal) et pour lequel il est légalement responsable indépendamment de la présence d'un système de cache.

Il est vrai que la présence du cache ne peut qu'énerver un peu plus d'éventuels plaignants, constatant que l'information est présente en deux lieux distincts, particulièrement s'ils ne découvrent cela qu'a posteriori. Mais on voit bien dans l'affaire fuzz que l'accessibilité effective du lien n'est pas en question. Le blog responsable de la nouvelle avait probablement été fermé rapidement, et le site fuzz lui-même avait fermé avant l'audience. La présence du lien un certain jour à une certaine heure a été suffisante à caractériser le délit. En ce sens, qui que soit le responsable légal du contenu sur Wikipédia (la Fondation, le lampiste, l'ensemble des auteurs de l'article postérieurs à la première publication du lien, les admins ayant rejeté une purge, etc.), cette personne est responsable dès l'ajout du lien problématique, qu'il y ait ou non un cache. Et, pour me répéter, si cette personne est condamnée, c'est de toute façon que le lien n'aurait jamais dû être ajouté (et que les mécanismes communautaires de relecture des articles et des liens n'a pas fonctionné correctement). — Jérôme 29 septembre 2008 à 23:11 (CEST)

J'imagine le cas suivant : un site américain diffuse une page internet qui contient deux informations sur la même page : l'information A utile pour Wikipédia et parfaitement légale, et l'information B légale aux Etats-Unis et illégale en France (la justice française est beaucoup plus pointilleuse que la justice américaine sur la vie privée des stars, par exemple). Un Wikipédien introduit l'info A dans l'article de Wikipédia et source avec cette page américaine. Ensuite il peut se faire condamner pour avoir publié une cache avec l'info B illégale en France. Vous vous souvenez de la vieille rengaine « les serveurs sont en Floride », pas toujours employée très à propos. Eh bien cette fois-ci les serveurs seront... où ? En France j'imagine puisque Linterweb est une société française. Teofilo ◯ 30 septembre 2008 à 15:08 (CEST)

Teofilo tu es un avocat de pacotille qui comprends que dalle au droit et nous les brise sévères avec tes interprétations à 20centimes sur les risques légaux. Donc pour que tu comprennes, puisque tu as beaucoup de mal, je vais tout te récapituler mon petit.

Allons-y:

• Wikimedia Foundation, l'hébergeur de Wikipédia, n'est en rien lié à Linterweb et au projet de Linterweb. Il est donc strictement impossible d'attaquer en justice l'hébergeur d'un site pour les problèmes causés par un autre site.
• Les Wikipédiens sourcent, en leur ame et conscience, les infos qu'ils ajoutent. C'est donc leur responsabilité à eux qui est en jeux sur les ajouts qu'ils font. Comme toujours depuis 6ans.
• On parle ici, d'ajout de liens, et non pas de contenus. Tu ne vois pas la différence? "Coucou" c'est du contenu, "http://cerveauaacheter.fr" c'est un lien. L'un on ajoute une information, et donc on a une responsabilité sur cet ajout, l'autre on dit "cette url existe", on a pas de responsabilité sur le contenus de cette adresse.
• Pour finir, puisque tu aimes les exemples, ce que tu dis revient à dire que Google a une responsabilité légale dès qu'elle ajoute un lien vers un site pédophile dans son moteur de recherche. Ou pas.

Voilà, j'espere que tu auras un peu compris. Sinon, je ne peux rien faire de plus pour toi. Avant de répondre utilise un peu le mou de veau qu'il y a entre tes oreilles, ca serait pas mal pour une fois. schiste 30 septembre 2008 à 21:09 (CEST)

Si le projet dont on parle se réalise, Wikipédia sera hébergée chez deux hébergeurs au lieu d'un seul, avec un partage des rôles : les contenus encyclopédiques seront hébergés comme jusqu'à présent chez la fondation Wikimedia et les caches dont on parle seront hébergées chez Linterweb.

C'est donc leur responsabilité à eux qui est en jeux sur les ajouts qu'ils font. Comme toujours depuis 6ans. On est parfaitement d'accord. Il convient de souligner que si le projet dont on cause voit le jour, ils auront également sous leur responsabilité cette mise en cache de différentes pages. Teofilo ◯ 1 octobre 2008 à 12:48 (CEST)

Salut,

Avec tout mon respect, schiste, j'aurais tendance à dire WP:PAP.

Teofilo, peux-tu énumérer tous les cas particuliers qui seraient problématiques à ton avis ? Je vais essayer. (je numérote tout pour que tu puisses répondre point à point si tu veux).

1. De façon générale, les wikipédiens sont tous dans la mer**. Vandalismes, biographies de personnes vivantes... en modifiant une virgule on peut devenir l'un des principaux auteurs d'un contenu illégal (celui dont le nom est marqué en haut de la page quand on clique sur « lien permanent »). En pratique, les plaignants ne sont pas idiots, les juges non plus, et on n'a pas encore eu de problème à ce niveau là.
2. De façon générale, la Fondation est dans la mer**. Des contenus inappropriés sont redistribués auprès de 200 personnes (admins, stewards, etc.) dans plusieurs pays. Un site dont la vocation serait de redistribuer des textes (diffamatoires, etc.) auprès de ses 200 inscrits aurait rapidement des problèmes. On a du bol, ça ne se sait pas trop pour Wikipédia (et on peut invoquer la bonne foi, l'objectif du site n'étant pas la redistribution de contenus inappropriés). L'argument « les serveurs sont en Floride » est régulièrement invoqué, et n'est d'ailleurs pas totalement vrai, puisque la Fondation dispose aussi de serveurs aux Pays-Bas. En pratique, à nouveau, les potentiels plaignants ne sont pas idiots (et la mise sous oversight d'une page, lors du référé de l'année dernière a apparemment satisfait le tribunal). Mis à part ces cas généraux qui en pratique ne se présentent pas, les cas particuliers sont :
3. Publication d'un lien vers un site au contenu tellement inapproprié qu'il est rapidement supprimé (cas justdroit.com dont tu parles dans la discussion « chez Manon »), et dont nous faciliterions la propagation à travers un lien vers une cache. J'en ai déjà parlé plus haut, avec le cas fuzz, on voit que la justice française peut condamner des webmasters pour des liens, lorsqu'elle estime qu'une des personnes a eu le rôle d'éditeur de l'information. Mais ici, qui en serait responsable ?
   1. La Fondation ? L'hypothèse habituelle dit que non (serveurs centraux en Floride, simple hébergeur technique sans rôle éditorial).
   2. Le wikipédien ? S'il a inséré une information diffamatoire, il aura des problèmes, indépendamment de la présence d'un lien ou de la présence de la page en cache. S'il a inséré une information non problématique, il pourra toujours invoquer la bonne foi, arguant qu'il n'a pas remarqué que la page contenait également une information problématique. Que le tribunal retienne ou pas son excuse de bonne foi, de toute façon, la faute qu'il a commise est d'avoir inséré le lien initialement, il ne va pas être tenu responsable de la présence ou de l'absence du lien dans le cache. De toute façon, si on en arrive à ce genre de procès, Linterweb aura vraisemblablement reçu un courrier et retiré la page de son cache.
   3. Linterweb ? C'est leur problème, et ils pensent qu'ils s'en sortiront. Exactement comme sur Wikipédia : n'importe qui peut publier des bêtises, mais les administrateurs agissent de bonne foi et retirent de la vue du public les contenus illégaux. On leur fait confiance, Linterweb fera le nécessaire si un document problématique leur est signalé.
   4. Mais alors qui va porter le chapeau ? Ben, j'en sais rien. Mais il n'est ici question que de la responsabilité supplémentaire qui viendrait de la présence du cache. Et je ne vois pas ce que cette présence en cache ferait commettre comme nouveau délit à un wikipédien ou à la Fondation (Linterweb c'est son affaire, comme google cache).
4. Le seul cas possible que je trouve où la présence du lien en cache serait est un problème supplémentaire, par rapport à la situation SNAFU normale, serait le cas où : quelqu'un s'étant plaint, un site est fermé ; Linterweb n'est pas prévenu des raisons de l'erreur 404 ; la victime dans sa grande mansuétude décide de ne pas attaquer les personnes ayant inséré un lien vers le site ; mais, a posteriori, la victime découvre que le site existe toujours en cache chez Linterweb avec un lien sur Wikipédia (accessible à tous, ou bien seulement aux inscrits, ou bien seulement aux admins). Et, du coup, décide de se plaindre. Dans cet unique cas, de toute façon, elle a raison de se plaindre (le site problématique doit être retiré). Voir le point précédent pour le problème de la responsabilité (qui conclut à ce qu'au pire des cas, les problèmes seraient pour Linterweb, mais on suppose que Linterweb connait la LCEN et suivra ses recommandations).
5. Cas cité par Teofilo : la page mise en lien contient deux informations, dont l'une est interdite en France (où est situé le siège de Linterweb et ses serveurs). Dans le cas fuzz, le fait que l'information problématique (élément de vie privée) figurait dans le titre du lien, le fait que cette information était en bonne place en haut du site et le fait qu'il y ait volonté manisfeste de diffuser l'information ont fait partie des données ayant guidé le juge (« volonté de mettre en contact le public avec l'information », dit [je cite de mémoire] le jugement cité par Eolas). Dans le cas que donne Teofilo, le Wikipédien ne cherche nullement à mettre le public en contact avec l'information problématique, qui ne se trouve pas rediffusée par Wikipédia et seulement accessible dans le lien par coïncidence. Et de toute façon, la culpabilité éventuelle du wikipédien serait liée à l'insertion par lui du lien, indépemment de l'existence d'un cache. Et pour Linterweb, cf. plus haut.
6. La limitation de la redistribution aux admins. De toute façon, s'il y a un délit, que l'information ou le lien soit redistribué aux admins seulement ou à tout visiteur, ça reste un délit. Certes moins grave si le nombre de personnes est faible, mais je pense qu'on ne cherche pas ici à minimiser les délits, mais plutôt à s'assurer qu'on n'en commet pas du tout. La situation actuelle, où des contenus calomnieux, révisionnistes et autre sont accessibles à 200 admins est déjà un problème. En pratique, personne ne se plaint, mais dans l'absolu des gens pourraient se plaindre. S'ils le font, la Fondation se retranchera derrière le droit américain sur la libre expression, et Linterweb derrière la LCEN (réaction prompte à tout signalement de contenu illicite).

— Jérôme 1 octobre 2008 à 15:56 (CEST)

Moi ce qui me rends perplexe c'est que tu t'oppose à un gadget, à un ajout dans le monobook. Or je ne comprends pas cette position. N'est-tu pas plutôt en faveur de la proposition n°1 Teofilo ? Amicalement, Dodoïste ^{[réveille-moi]} 1 octobre 2008 à 00:59 (CEST)

La seule différence est que le public ciblé par la republication sous forme de cache est plus restreint dans le cas 1 que dans le cas 3, mais cela n'exonère pas totalement des responsabilités. Si un texte illégal est distribué à 100 personnes c'est moins grave que de le distribuer à 1000 ou 10000, mais cela reste répréhensible.

Quelles que soient les solutions qu'on pourraient envisager pour protéger le public des contenus sensibles générateurs de délits de presse (je pensais à une cache qui serait consultable uniquement par les bureaucrates et les admins), on est bloqué par le code de la propriété intellectuelle : je lis à l'article L. 122-5 que les copies privées que la loi autorise doivent être strictement réservées à l'usage privé du copiste et non destinées à une utilisation collective. On peut donc se créer son propre système de cache chez soi, sur son ordinateur, mais il est interdit de le partager avec d'autres en le mettant en ligne, dans le cadre d'une structure collective comme Wikipédia.

Enfin, à l'avenir, il faudra suivre comment évolue le projet de système de mise en cache de la bibliothèque nationale de France, qui est pour l'instant en attente d'un décret d'application, mais dont on peut penser que le cadre légal sera irréprochable. Teofilo ◯ 1 octobre 2008 à 14:16 (CEST)

Juste pour resituer un petit peu, dans l'affaire Fuzz, dont on parle abusivement plus haut, la condamnation était liée au fait de porter sciemment une information, disons, illégale, sur un site web. L'équivalent pour wikipédia serait celui d'un éditeur qui ajouterait un lien titrant « madame truc va se marier avec monsieur machin », et pointant vers une page web détaillant l'information.

Dans son argumentation, Teofilo confond allègrement violation de droit d'auteur et délit de presse, ainsi que responsabilité d'éditeur et d'hébergeur.

Pour dire les choses simplement, un wikipédien ajoutant un lien vers un site violant le droit d'auteur ne saurait être poursuivi sur cette seule base. Par contre, un wikipédien ajoutant un lien titrant une diffamation le pourrait. De même, si le système de cache/archive reprenait des liens titrant un contenu illégal (et non pas « pointant vers »), il pourrait y avoir poursuites. Or, le système présenté ne fait pas ça, puisqu'il ne titre pas les liens, ni ne retranscris de contenu. Autrement dit, un lien [1] est différent d'un lien madame truc aime les parties fines, de même qu'un lien téléchargez ce livre et violez le droit d'auteur est différent d'un lien citation page 4.

Il en ressort que le système de cache/archive a deux points d'entrés légaux qui nous intéressent : 1) le statut hypothétique d'hébergeur de Linterweb, 2) la responsabilité du wikipédien qui ajoute le lien. Le 1) ne concerne pas la Wikimedia Foundation, il ne sert donc à rien d'en discuter ici, sauf à croire être plus compétent que des avocats ou à vouloir prédire l'issue d'un procès. Le 2) est de toute façon déjà à l'oeuvre partout dans le projet, sauf à vouloir reprendre tout Wikipédia depuis le début, je ne vois pas non plus en quoi ça intéresse la présente prise de décision.

Je ne peux que conclure que ce troll est bien un FUD, par définition : peur, incertitude et doute. nojhan→☸ 3 octobre 2008 à 10:31 (CEST)

Salut, merci pour ces précisions. Ton message me suggère une question : le bot de Zouavman ajoute automatiquement les titres des pages. Dans un cas limite, voilà ce que cela pourrait donner : « Madame Truc, alors ministre de l'industrie italienne, acheta elle-même acheté une Fiat Panda pour donner l'exemple à ses concitoyens<ref>[http://blog.com/titre.html madame truc aime les parties fines dans sa Fiat Panda (>-- titre généré automatiquement --<)]</ref>

Certes, ce cas sera très rare et on aurait probablement de meilleures sources pour la Fiat Panda d'une ministre. Mais dans l'intervalle, madame Truc est diffamée. — Jérôme 3 octobre 2008 à 10:55 (CEST)

Nojhan : « Pour dire les choses simplement, un wikipédien ajoutant un lien vers un site violant le droit d'auteur ne saurait être poursuivi sur cette seule base. » --> C'est inexact et c'est le contraire qui est vrai : « le Tribunal Correctionnel d'Epinal, dans un jugement du 24 octobre 2000, a retenu la responsabilité pénale et civile d'un individu qui avait permis, par le biais de liens hypertextes, d'accéder à des œuvres musicales sous format MP3 sans l'autorisation leurs auteurs. » Source Jérôme Perlemuter, avocat, « Liens hypertextes : risques et responsabilités », Le Journal du net, Mardi 16 juillet 2002 http://www.journaldunet.com/juridique/juridique020716.shtml. Teofilo ◯ 9 octobre 2008 à 13:25 (CEST)

Il n'est pas inutile de noter ici que dans l'ordonnance faite à la Wikimedia Foundation par le tribunal de grande instance de Paris en date du 2 octobre 2008, l'un des motifs de plainte porte sur la présence sur Wikipédia de « liens hypertextes vers des sites internet dont la diffusion de l'un, en raison de son contenu préjudiciable, a été suspendue par ordonnance du Président du tribunal de commerce de Paris » (page 3). On peut très bien imaginer dans le futur, si le système de cache est mis en place, une plainte de ce type agravée par le fait que le système de cache pourrait permettre de contourner une interdiction de diffusion. Teofilo ◯ 9 octobre 2008 à 13:01 (CEST)

Dans les deux cas (Hington et Épinal), ce qui motive la plainte est le fait que le contenu du lien est illégal (pour l'un, de la musique, pour l'autre de la diffamation). Ces liens ne correspondent à des sources de qualité, et sont même explicitement déconseillés par WP:LE. Dans ce cas si le wikipédien a légalement fauté, ça me parait normal qu'il subisse les conséquences, éventuellement aggravées (ou pas) par la présence du cache. Le cas qui intéresse Wikipédia est plutôt celui où un contributeur source une information à partir d'un lien internet légal, p.ex. un article de journal gratuit. L'article devient par la suite payant, et le cache crée un préjudice au journal en permettant un accès gratuit. Contre qui le journal va-t-il porter plainte ? — Jérôme 9 octobre 2008 à 14:50 (CEST)

Essai de résumé sur la légalité

Je veux des réponses courtes, simples et claires des proposants:

1. Est-ce que le coté légal a été vérifié et revérifié par à la fois Wikimédia et Linterweb?
2. Qui est responsable en cas d'ajout de lien vers un site frauduleux actuellement?
3. Qui sera responsable en cas d'ajout de lien vers un site frauduleux après la mise en place des caches?

Si c'est trois questions ont une réponse et que les deux dernières ont la même réponse, en toute logique, il n'y a aucun problème (pas plus qu'actuellement en tout cas) et donc cette PDD doit se concentrer sur une seule question: Est-ce que ce serait bien que l'on ajoute cet outil?--M.A.D.company ^{[keskisspass?]} 1 octobre 2008 à 13:08 (CEST)

Réponse :

1. Linterweb est seul a avoir vérifié le côté légal. Pas de risque *à priori* pour Wikimédia, le délit n'étant pas clairement avéré. Il y a un flou juridique à ce sujet. Le jour où l'archivage web sera interdit, nous pourrons facilement retirer tous ces liens cache... Pour l'instant c'est pas comme si Internet archive fermait ses portes hein

2 et 3 : Tu peux poser la question sur Wikipédia:Legifer. Moi, je dirais que le fait d'avoir un cache n'augmente pas les risques actuels. En gros, ta situation n°2 est égale à ta n°3 : le cache est supprimé si le lien est enlevé. Donc cela ne change rien à ce niveau. Amicalement, Dodoïste ^{[réveille-moi]} 1 octobre 2008 à 13:58 (CEST)

Voilà donc je vois pas pourquoi on épilogue, la situation actuelle est déjà floue (même si ca me parait bizarre que Wikimédia n'ai rien vérifié) et pour les réponses aux question 2 et 3 j'espérais une meilleure réponse de ta part (j'ai supposé que vous aviez fait des recherches a ce sujet).--M.A.D.company ^{[keskisspass?]} 1 octobre 2008 à 14:23 (CEST)

Bah pour 2 et 3 on pense pas qu'il y ait un risque. Mais comme dit précédemment je t'encourage à poser la question à Légifer Amicalement, Dodoïste ^{[réveille-moi]} 1 octobre 2008 à 14:31 (CEST)

Voir aussi ma réponse pas courte et pas claire plus haut cette réponse. — Jérôme 1 octobre 2008 à 15:58 (CEST)

Effectivement c'est pas court et pas clair, une conclusion à ce pavé pour résumer? (ne crois pas que j'ai pas lu au contraire mais j'ai fait cette section pour résumer)--M.A.D.company ^{[keskisspass?]} 1 octobre 2008 à 16:15 (CEST)

Je ne m'aventurerai surtout pas à résumer (pas juriste, j'y connais rien, tout ça) mais une grande partie de ce que j'ai dit vient des conséquences de l'l'affaire Fuzz, dont je te conseille la lecture. — Jérôme 1 octobre 2008 à 17:33 (CEST)

1. Linterweb affirme que oui (après, chacun décide de faire confiance ou non), la Wikimeda Foundation n'a rien vérifiée pour l'instant, mais il est impossible (et je sais de quoi je parle) de demander un avis légal à la WMF sans montrer concrêtement de quoi on parle.
2. Ça dépend du lien, tous les liens pointant vers un site « frauduleux » ne sont pas illégaux. Pour les liens qui pourraient être concernés, le wikipédien qui a inclu le lien serait responsable (c'est la ligne de défense de la WMF, en tous cas).
3. Même réponse que précédemment : le wikipédien. Linterweb pourraient être poursuivi conjointement, mais pour d'autres motifs que celui de l'insertion du lien à proprement parlé.

nojhan→☸ 3 octobre 2008 à 10:53 (CEST)

Merci des réponses c'est clair net précis, c'est bien ce que je pensais le wikipédien était responsable avant et continuera a l'être après donc ca change rien pour nous. (Après que linterweb fasse partie des dégâts collatéraux c'est pas notre problème et ils assument les risques) Donc plus qu'à voter pour décider si c'est bien ou pas.--M.A.D.company ^{[keskisspass?]} 3 octobre 2008 à 11:09 (CEST)

« le wikipédien était responsable avant et continuera a l'être après donc ca change rien pour nous » : si ça change. Car la nature de ce qu'il fait change. Dans un cas il fait un lien. Dans le second il fait un lien en sachant que cela déclenche la création d'une copie dans un serveur. Un automobiliste qui passe d'un véhicule de tourisme à un poids lourd était responsable avant et continue d'être responsable après. Mais conduire un poids lourd est plus délicat que conduire un véhicule de tourisme. Teofilo ◯ 3 octobre 2008 à 12:43 (CEST)

il est impossible (et je sais de quoi je parle) de demander un avis légal à la WMF sans montrer concrêtement de quoi on parle. → qu'est-ce qu'il te manque pour leur demander ? (Ils peuvent s'inscrire sur fr: et activer le gadget, non ?) Sur la base du vote actuel, si la proposition 3 est adoptée, leur demanderas-tu ? — Jérôme 3 octobre 2008 à 16:52 (CEST)

Les wikis par zone.

Le problème de la WMF c'est qu'ils ont peu de personnel, qui ne parle généralement pas ou mal le français, et que, plus prosaïquement, ils n'en ont rien à foutre de ce genre de petits tracas hypothétiques sur des wikis de seconde zone. Éventuellement, si le système est mis en place ils décideront de le virer ou de le garder, mais je doute très fortement qu'on ait un retour en le leur demandant avant. Maintenant, tu peux essayer de leur demander, moi, je n'ai aucune légitimité spécifique pour ce faire (je ne travaille pas pour Linterweb, même si je défend le système de cache/archive, il ne faut pas confondre), j'émets juste un avis. nojhan→☸ 8 octobre 2008 à 10:00 (CEST)

Wiki de seconde zone! i'm schocked!--M.A.D.company ^{[keskisspass?]} 8 octobre 2008 à 10:17 (CEST)

Autres aspects juridiques : droit moral ; extraction substantielle de données

On a beaucoup parlé des délits de presse (diffamation, vie privée) et du droit de reproduction (copyright), mais peu d'autres aspects juridiques qui ne sont pas forcément moins importants.

Pwet-pwet a parlé du droit moral plus haut sur cette page : « normalement il faut l'autorisation de l'auteur avant de copier » ( 27 août 2008 à 18:19 #Questions de Pwet-pwet ), mais le droit moral comporte aussi les choses suivantes :

• le droit à la paternité de l'oeuvre : parfois le nom de l'auteur n'est pas écrit sur la page liée mais sur une autre page du type "qui-sommes-nous.html", ou "à-propos-de-l'auteur.html". Si le système de cache proposé ne recopie que la page liée, sans recopier le site en entier, la possibilité que des textes se retrouvent anonymisés de cette façon est à craindre.

• le droit de retrait : il y a des auteurs qui sont peut-être bien contents que leurs textes disparaissent, et ils n'ont pas forcément envie de pouvoir être lus au-delà de la durée de vie du site auquel ils avaient confié leur écrit.

• le droit de choisir le contexte dans lequel leur oeuvre est diffusée. Un auteur peut se sentir valorisé lorsque son texte fait partie d'un site internet complet qui a une cohérence, et ne pas souhaiter que son texte apparaisse isolément lorsque le reste du site a disparu.

J'oubliais aussi : le droit à l'intégrité de l'oeuvre. Même si son nom est bien cité, l'auteur peut considérer que c'est tout son site qui constitue une oeuvre et que publier uniquement une ou deux pages est une mutilation de l'oeuvre. Teofilo ◯ 3 octobre 2008 à 16:16 (CEST)

Enfin il y a le droit des bases de données. Toute collection de données donne lieu à une protection du producteur qui a produit la collecte. Seules les extractions de données ponctuelles sont autorisées. Les extractions massives nécessitent de passer contrat avec le producteur. Article L342-1 du code de la propriété intellectuelle :

Le producteur de bases de données a le droit d'interdire : 1° L'extraction, par transfert permanent ou temporaire de la totalité ou d'une partie qualitativement ou quantitativement substantielle du contenu d'une base de données sur un autre support, par tout moyen et sous toute forme que ce soit ; 2° La réutilisation, par la mise à la disposition du public de la totalité ou d'une partie qualitativement ou quantitativement substantielle du contenu de la base, quelle qu'en soit la forme. Ces droits peuvent être transmis ou cédés ou faire l'objet d'une licence. Le prêt public n'est pas un acte d'extraction ou de réutilisation.

Je ne vous donne pas le lien legifrance.fr (il faut que je m'habitue à ne plus utiliser de liens sur Wikipédia) Teofilo ◯ 3 octobre 2008 à 08:52 (CEST)

Tout à fait. Articles qui pourraient tous se retourner vers Linterweb. Cependant, la Wikimedia Foundation n'ayant aucun rôle dans le système, il n'y aucune raison logique de penser qu'elle pourrait être véritablement inquiétée, sauf à remettre en cause son statut d'hébergeur, mais c'est sa position officielle, sur laquelle tout repose, on sort donc largement du cadre qui nous intéresse.

Pour compléter, les points incertains sont : 1) on ne sait pas si les systèmes d'archive/cache sont illégaux par nature ou si le cas par cas (type opt-out) pourrait suffire à leur gestion, 2) on ne sait pas si une page web est une « partie qualitativement ou quantitativement substantielle » d'un site, et il est moins que certains qu'un site web soit toujours une base de donnée (ça dépend de quelle partie de la page web on parle, pour être exact). — Le message qui précède, non signé, a été déposé par Nojhan (discuter), le 3 octobre 2008 à 10h45 CEST

Question

Où on vote contre la mise en place du système de cache (peu importe la manière dont il est mis en place) ? Personnellement, je suis contre insérer des liens vers ce site, pourquoi ne pas laisser s'exprimer cette opinion ? La prise de décision s'intitule pourtant "Autoriser la mise en place d'un système de mise en cache des pages liées externes", et non "modalités de mise en place d'un système de mise en cache des pages liées externes". Pwet-pwet · (discuter) 4 octobre 2008 à 15:40 (CEST)

Bon, j'ai indiqué mon avis, mais il me semble que la façon dont a été mis en place ce vote est du gros n'importe quoi, l'issue ne m'en semblera pas du tout légitime. Mais tant pis. Pwet-pwet · (discuter) 4 octobre 2008 à 15:47 (CEST)

Tu parles là de blacklister un lien externe. Rien n'interdit de faire des liens vers ce site. La Prise de Décision est donc sur l'apparence que sera donné à ses liens assez particuliers. :) schiste 4 octobre 2008 à 15:49 (CEST)

Si je suis ta logique, tous les liens vers des sites qui n'auront pas reçu un consensus durant une PdD sont illégitimes. Intéressant :) schiste 4 octobre 2008 à 15:51 (CEST)

Non, je suis pour blacklister ce site. Pwet-pwet · (discuter) 4 octobre 2008 à 16:10 (CEST)

Salut Pwet Pwet,

Cette option n'a pas été mentionnée parce qu'on ne pourrait rien en faire. C'est une société privée indépendante de nous qui met en place un cache. À moins d'avoir une bonne raison et de te plaindre à la police, je ne vois pas ce que tu peux faire contre le cache lui-même.

La situation actuelle, qui correspond à la proposition 1, est que seuls les utilisateurs inscrits et volontaires peuvent ajouter un script à leur monobook.js pour afficher des liens dans leur navigateur. Cela ne pourrait-il pas convenir à ton avis ? On n'avait effectivement pas pensé que des contributeurs puissent voter pour l'interdiction totale d'un script utilisateur.

Tu peux, pour manifester ton mécontentement, voter comme Teofilo. Sinon, la méthode Condorcet utilisée sur Wikipédia prévoit explicitement la possibilité de classer dans ses choix la proposition « aucun des choix ci-dessus » ici qui conduit, si elle est adoptée, à l'annulation du vote (aucune décision n'est prise, retour à la case discussion). — Jérôme 4 octobre 2008 à 16:11 (CEST)

J'ai bien compris la première partie. Je suis simplement contre placer un lien vers un site dont le but est de reproduire du contenu sur lequel il ne possède aucun droit (pour moi, ça serait comme placer un lien pour télécharger un film ou un documentaire en ligne, mis à disposition illégalement par un tiers -pas un souci légal mais plutôt éthique). Il me semble important de mentionner cette possibilité de vote, là j'ai l'impression qu'on essaie de forcer la main. Mais bon manifestement que ce soit sous forme de texte gêne manifestement moins que s'il s'agissait de "mettre en cache" des vidéos. Pwet-pwet · (discuter) 4 octobre 2008 à 16:15 (CEST)

En l'état actuel des choses, aucun lien n'est réellement présent dans Wikipédia, ils sont ajoutés par un script activé par les gens qui le veulent. Ta proposition est-elle d'interdire la programmation d'un tel script ? — Jérôme 4 octobre 2008 à 16:26 (CEST)

Pour le problème éthique, tout le monde sait qu'il y a déjà des systèmes de cache et d'archivage automatique comme google cache ou web.archive.org. Aussi, les créateurs de sites que ces systèmes embêtent ont déjà mis dans leur fichier d'exclusion des robots qu'ils ne souhaitent être archivés par personne, et leur souhait est respecté. Cela devrait aussi être le cas pour Linterweb. (À vérifier auprès d'eux, quand même, mais c'est le plus logique.) — Jérôme 4 octobre 2008 à 17:03 (CEST)

Oui oui c'est respecté. Sur n'importe quel lien mort de l'Express.fr datant d'après la mise en place du cache, wikiwix renvoie une page de ce type. Voilà Amicalement, Dodoïste ^{[réveille-moi]} 4 octobre 2008 à 20:57 (CEST)

Pour répondre à l'argument moral de Pwet-Pwet, je me permet de recoller un commentaire que j'avais déjà fait plus haut :

« Cela fait plusieurs fois que j'entends cet argument, et j'avoue qu'il me gène.

Pour commencer, objectivement, il est très difficile d'être catégorique d'un point de vue légal, la jurisprudence n'est pas tout à fait cohérente avec la lettre, l'esprit et la lettre ne sont pas non plus toujours en phase, le tout est multiplié par les nombreux détails abscons qui font de la loi internationale une discipline pour professionnels. Donc, même si, moi aussi, j'ai quelques notions de droit, je préfère ne pas m'y fier, et j'ai plutôt tendance à faire confiance aux cabinets d'experts.

De plus, en pratique "Wikipédia" ne prône pas la stricte observation de la lettre de sa licence. La Wikimedia Foundation, par exemple, tolère explicitement qu'on reprenne son contenu en ne faisant qu'indiquer une url vers wikipédia comme source, en contradiction manifeste avec la GFDL. Donc, je récuse l'analyse qui voudrait que "Wikipédia" se fait la chantre de l'observance de la loi.

Si on a cette même analyse, il ne reste qu'un aspect moral que je trouve très scabreux. Après tout, Wikipédia prônant le respect du droit international, de la liberté d'expression, des droits de l'homme, de la culture libre et j'en passe, devrait-elle, pour être cohérente, ne pas lier vers des sites gouvernemntaux Russes, Chinois, Tunisiens ? Vers des sites soutenant ces politiques ? Ou même vers d'autres encyclopédies privatives ? Non, bien sûr, c'est une approche trop emprunte de jugement morale pour être honnête.

Enfin, suivre ce raisonnement, c'est prendre une décision locale en s'appuyant sur un raisonnement global, en fonction de ce que l'on voudrait que soit Wikipédia, et non pas en fonction de ce qu'elle est vraiment... nojhan→☸ 27 août 2008 à 19:25 (CEST) »

Pourquoi pas un site miroir ?

Pourquoi les initiateurs de cette idée de cache ne créent-ils pas un site mirroir totalement indépendant de Wikipédia, comme il en existe tant (voir Wikipédia:Site miroir et en:Wikipedia:Mirrors and forks) ? De cette façon les exemptions de responsabilité (anglais disclaimers) de la page Wikipédia:Avertissements généraux en:Wikipedia:General disclaimer viennent se placer entre le Wikipédien et le miroitier et le protègent. Et comme c'est indépendant, on n'a plus besoin de passer par une prise de décision.

Teofilo ◯ 8 octobre 2008 à 07:34 (CEST)

Salut. Je ne comprends pas bien. Tu proposes un miroir de Wikipédia ou des sites comme Libération ou Le Monde ? En quoi ta proposition (que je n'ai pas comprise) répond-elle au problème des liens 404 ? (J'ai noté plus haut ta proposition d'archive non publique.) Cordialement. — Jérôme 8 octobre 2008 à 09:14 (CEST)

Je propose un miroir de Wikipédia. Le lecteur qui est mécontent de trouver des liens 404 sur fr.wikipedia.org se dirait : je vais aller consulter fr.lemiroird'uneencyclopedietrèsconnue.com car j'ai entendu dire que ce miroir avait un système de cache. Teofilo ◯ 9 octobre 2008 à 11:55 (CEST)

Alors qu'est-ce que tu attends tu le fais ?

/me ne rentre même pas dans la discussion sur le sujet : « comment le lecteur saura que untel miroir possède le cache ? Problème niveau accès ? » Dodoïste ^{[réveille-moi]} 9 octobre 2008 à 12:06 (CEST)

Quand je dis "je propose", c'est pour reprendre la phrase de Jérôme. Plus précisément, je propose aux partisans d'un tel système de renoncer à le mettre en oeuvre sur fr.wikipedia.org. S'ils le mettent en oeuvre sur un autre site possédant un autre nom de domaine, je ne m'y opposerai pas, tant qu'ils respectent la licence GFDL, mais je n'ai pas l'intention d'y participer. Teofilo ◯ 9 octobre 2008 à 12:17 (CEST)

Résultat

La communauté se prononce pour une large utilisation du cache. Les détails de sa mise en application sont à discuter. Il me semble important de noter que beaucoup sont contre l'utilisation d'un script par défaut pour des raisons d'accessibilité. Certains sont également favorables à une utilisation via un modèle. Cela n'ayant pas encore été discuté, voici une proposition. Dodoïste ^{[réveille-moi]} 27 octobre 2008 à 18:09 (CET)

Proposition avec {{Lien web}}

Il est possible de modifier le modèle Lien web selon Utilisateur:Dodoïste/Modèle:Bac à sable, qui fonctionne exactement comme lien web, avec des améliorations inspirées de en. Cette nouvelle version permet de corriger les liens morts, et est conçue pour être ajouté par un bot.

Test des modifs du modèle {{Lien web}} avec ceci

J'ai donc copié le modèle lien web et lui ai ajouté 3 paramètre, dont un par défaut et deux remplaçant le premier si activé. Par défaut, un lien vers wikiwix est ajouté. Il est possible de le remplacer par une archive spécifique ( wikiwix, internet archive, google cache, archive-it, ...), jugée la plus pertinente, via le paramètre |archiveurl, et la date de l'archive via |archivedate.

Exemples

Rendu par défaut :

• Ziba Mir-Hosseini, Azadeh Kian-Thiébaut, « Islam, Women and Civil Rights: the Religious debate in the Iran of the 1990s » sur Abstracta Iranica, 2002, Richmond, Curzon Press et Royal Asiatic Society, (ISBN 1234567890123^{[à vérifier : ISBN invalide]}), p. 169-188. Mis en ligne le 15 mars 2006, consulté le 2 octobre 2006

Rendu avec les paramètres archiveurl et archivedate remplis :

• Ziba Mir-Hosseini, Azadeh Kian-Thiébaut, « Islam, Women and Civil Rights: the Religious debate in the Iran of the 1990s » sur Abstracta Iranica, 2002, Richmond, Curzon Press et Royal Asiatic Society, (ISBN 1234567890123^{[à vérifier : ISBN invalide]}), p. 169-188. Mis en ligne le 15 mars 2006, consulté le 2 octobre 2006

Bot

Actuellement DeepBlue (d · c · b), un bot qui ajoute {{Lien web}} à tous les liens externes, demande son bot flag et est en attente de l'issue de cette PDD. Il peut en effet répandre la nouvelle version de lien web sur tout les liens externes, et corriger les liens morts. Les gros avantages sont que cela inscrit le lien en dur (pas de script, pas de temps de chargement), que cela fait un lien vers le cache wikwix.

Accessibilité

Bonjour, La forme actuelle, qui ne fait pas appel à un javascript mais à un traitement côté serveur, règle au moins ce problème. Il reste cependant (rapidement, car je n'ai pas le temps de creuser...) deux points à améliorer :

1. dans le cas où plusieurs appels vers le modèle sont faits sur une même page, il faudrait que les intitulés des liens vers Wikiwix soient différents
2. il ne faut pas que l'attribut title du lien reprenne l'URL !!!!

Un moyen simple de régler les deux problèmes simultanément consiste à laisser l'intitulé « Wikiwix », et à renseigner l'attribut title sous la forme [titre de la page liée] (archivé sur Wikiwix). GillesC →m'écrire 28 octobre 2008 à 11:27 (CET)

J'ai modifié le modèle ( voir les exemples au-dessus ). Cela te convient ? Le gros inconvénient est que cela rallonge considérablement la présentation, mais en dehors de cela je suis aussi favorable à l'idée : c'est plus explicite. Amicalement, Dodoïste ^{[réveille-moi]} 28 octobre 2008 à 12:22 (CET)

Pour ce qui est de l'attribut title, c'est une petite particularité de mediawiki : seule l'application a la main dessus, et elle génère systématiquement ces title contenant l'url pour les liens externes. Pas valide ATAG, ça. Cordialement, --Lgd (d) 28 octobre 2008 à 12:28 (CET)

Lgd, j'ai pas compris. Veux-tu dire qu'il y a un problème ? Si tu veux améliorer quoique ce soit, n'hésite pas. Amicalement, Dodoïste ^{[réveille-moi]} 28 octobre 2008 à 22:15 (CET)

Il y a effectivement un problème (l'attribut title du lien ne doit pas reprendre l'URL, comme le signalait GillesC, car cela rendra le lien incompréhensible pour certains utilisateurs). Mais sa solution ne relève pas d'une correction du modèle et des contributeurs. Elle relève d'une modification du logiciel mediawiki lui-même. La question a déjà été signalée aux développeurs. Cordialement, --Lgd (d) 29 octobre 2008 à 03:25 (CET)

Il fallait cependant aussi faire en sorte que l'intitulé du lien fût univoque, ce qui est maintenant le cas. Pour l'attribut title sur les liens externes, je l'ignorais (ou alors, je l'ai à ce point oublié que je ne me souviens plus l'avoir jamais su...). Donc en l'état actuel des choses, je ne vois plus rien de problématique qui soit à portée de ce qui est faisable avec la version actuelle du logiciel. GillesC →m'écrire 29 octobre 2008 à 10:37 (CET)

C'est le bug #2147. Il a été bizarrement marqué comme doublon (l'autre signalement concerne pourtant les liens internes), et n'a pas l'air de convaincre.

GillesC, Lgd : Ce serait correct de garder l'intitulé « Archivé sur Wikiwix » mais de remettre le nom complet de la page de destination (suivi de « Archivé sur Wikiwix ») dans l'attribut title du lien d'un span enveloppant le lien, par exemple ? — Delhovlyn — « ... » ^?, le 29 octobre 2008 à 15:39 (CET)

Non, l'attribut title sur un span ou un autre élément de texte n'aura pas d'effet sur la restitution des liens pour les utilisateurs concernés (lecteurs d'écran, en particulier). Comme le dit GillesC, on ne peut pas faire mieux que la version avec l'intitulé du lien explicite. --Lgd (d) 4 novembre 2008 à 06:16 (CET)

Bonjour, de toute façon un changement de modèle ne passera pas amha , car primo bien trop de modèle lien externe existant http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Mod%C3%A8le_cr%C3%A9ant_un_lien_externe et deuxio celà fait au moins une modification par page Pmartin (d) 7 novembre 2008 à 06:43 (CET)

Très franchement, ce système de cache (hélas adopté par cette PDD) devrait au moins être déployé via une extension mediawiki, et non via un javascript ou des modèles. Ce serait un minimum pour gérer cela de manière réaliste, robuste et accessible. Faute de cela, et si tant est que ce effectivement déployé, ce sera non accessible et lourd à mettre en place via les modèles, ou bien non accessible et lourd pour le traitement côté client via javascript... --Lgd (d) 7 novembre 2008 à 07:20 (CET)

J'attends avec impatience cette extension, mais actuellement deux solutions sont possibles une qui modifie un seul fichier et l'autre tous les modèles. Donc en attendant l'extension il est préférable d'utiliser la solution javascript qui permettera très facilement de basculer vers l'extension. Pmartin (d) 9 novembre 2008 à 19:53 (CET)

Le script ne prépare en rien la mise en place d'une extension, au contraire, mais peu importe : je m'étonne simplement que les intervenants dans ce projet ne ne se soient pas donnés les moyens de traiter cela sur le fond, en développant l'extension nécessaire avant de proposer le tout. Bien-sûr, j'ignore peut-être certains aspects des choses, et je ne demande qu'à être éclairé là-dessus.

Bref, dans l'immédiat, il va bien falloir en passer par l'une ou l'autres des deux mauvaises solutions. A la réflexion, contrairement à Gilles, j'estimerais que la solution javascript sera encore la moins dommageable, à condition toutefois de procéder à la correction expliquée dans la page de discussion du script. Cordialement, --Lgd (d) 12 novembre 2008 à 11:39 (CET)

Je suis moi aussi favorable à une extension. Faut-il en faire la demande à Bugzilla ? N'étant pas très compétent en informatique je crains d'être peu précis et de mal me faire comprendre... Si l'un de vous pouvait s'en charger. Amicalement, Dodoïste ^{[réveille-moi]} 12 novembre 2008 à 13:36 (CET)

A noter: une très récente implémentation de liens sur images dans mediawiki permet à présent de passer par les modèles tout en obtenant un lien accessible : il suffit qu'une icône soit utilisée à la place du libellé textuelle « archive ». L'implémentation permet alors de faire un lien externe sur cette icône, avec une alternative textuelle explicite (reprenant le libellé du lien original et le complétant par la mention « archive de ».

Les liens sur image ne générant pas de title problématique pour les liens externes, les problèmes évoqués ci-dessus ne se posent plus. Cordialement, --Lgd (d) 13 novembre 2008 à 00:11 (CET)

Exemple simple (icône choisie tout à fait arbitrairement):

• John Doe, Ma vie, mes oeuvres ().

Autre exemple (autre image, plus petite, pas de parenthèses) :

• John Doe, Ma vie, mes oeuvres

(zut, l'attribut title ne marche pas)

Cette image-ci est dans le domaine public, c'est plus mieux pour le lien sur image.

— Delhovlyn — « ... » ^?, le 13 novembre 2008 à 22:35 (CET)

Je vois tout de même un souci "assez intéressant" avec le principe de l'extension : certaines pages web sont modifiées après avoir été citées. Avec une extension, à moins de préciser une date d'archivage d'une manière ou d'une autre, je doute qu'il soit possible de fixer une archive précise : je pense par exemple à l'archivage sur WebArchive de fr.wikipedia.org/wiki/Accueil : [2] ... Certes, Wikiwix permettrait de ne mettre qu'une seule page, mais qu'arrive-t-il alors si on a besoin de la même page à deux dates différentes dans deux articles différents - ou le même article, d'ailleurs - ?

Je sais, on pourrait préciser ladite date d'archivage à utiliser dans une table sql (beurk, que ce serait laid du point de vue programmation ! et sans doute pas adapté, peu fonctionnel, ne marchant pas pour une même page web à deux dates différentes sur un même article, j'en passe et des pires...).

Ou par un modèle (ou un autre élément à même le code source de la page, par exemple un span sans css avec une date en paramètre, allez savoir) - mais alors, puisqu'il faudrait de toutes façons utiliser une modification du code source des articles, pourquoi développer une extension plutôt qu'utiliser un modèle ? Comment se marcher sur la tête en une leçon...

Avec un modèle, je pense par exemple au modèle {{lien web}}, on a je vous rappelle une chose bien pratique, qui est le paramètre "date" (entre autres paramètres de date, d'ailleurs).

Je vois un autre problème :

• pour les liens étant de base des liens d'archive (et ils sont bizarrement assez nombreux dans les articles concernant l'astronomie, (107) Camilla en est un exemple parmi beaucoup d'autres, notez le lien vers Web Archive dans la box "Caractéristiques physiques", à "Dimensions"),
• les liens avec un robots.txt empêchant l'archivage (il y en a aussi quelques uns),
• beaucoup de liens ftp, gopher, etc...,

il n'y a pas d'archives.

On met quand-même un lien vers ceux-ci, ou pas ? Ou on précise que c'est uniquement fonctionnel pour les liens http:// (voire https:// même si je ne suis pas sûr que tous les services d'archivage les prennent en compte...), mais on oublie ceux qui sont quand-même archivés ? On se mord la queue... décidément, entre "se marcher sur la tête" et "se mordre la queue", je fais dans l'anatomique aujourd'hui...

Même chose si on veut préciser une adresse d'archivage alternative, qui ne soit ni WebArchive, ni Wikiwix, on fait comment pour le dire à l'extension ? Là encore, un modèle permettant l'ajout d'adresses d'archivage alternatives serait un plus - même si Wikiwix pourrait là encore les reprendre à terme, je doute que les archivages "privés" soient tous connus de Linterweb (ce n'est pas une critique, hein, personne ne peut tous les connaître et je trouve déjà le travail fourni formidable - non, j'ai pas d'actions chez eux, je ne suis pas un employé Linterweb, et je ne suis pas de la famille non plus)...

Bref, je suis (et pas seulement parce que j'ai développé un bot pour ça, j'ai aussi réfléchi un peu aux différents cas possibles) contre l'utilisation d'une extension.

Alphos ^{[me pourrir la vie]} 15 novembre 2008 à 04:10 (CET)

PS : je sais, il y a "beaucoup de modèles de liens externes" (289 à ce jour en comptant les sous-catégories, les sous-pages de paramètres comme {{Coord/dec2dms/dms1}} qui ne sont pas vraiment des modèles avec des liens externes à proprement parler, les modèles vers des pages web non archivées, comme les divers modèles boursiers, etc...), mais je doute que les modifier soit si long ou dangereux... Et encore une fois, si l'on a besoin d'une date d'archivage précise, si c'est possible, une extension ne le permettra pas sans une précision dans le code - auquel cas autant se passer d'une extension et passer directement par un modèle, cf supra)

PS2 : Y'a aussi des liens mal classés dans la catégorie en question, je pense par exemple à {{sigle 1 lettre}}...

PS3 : quand j'aurai des sous, peut-être

PSP : pareil

PS4 : Wikiwix ajoute à son archive les pages web au moment de l'ajout de leur lien, pour les liens ajoutés désormais ; pour les liens antérieurs, je n'en sais rien, à voir avec les intéressés. Mais là encore, que se passe-t-il pour une page web dont le lien est ajouté à 3 mois d'écart après une modification ? Je ne crois pas, sans en être sûr, que Wikiwix propose une archive distincte pour chaque date d'ajout. On fait comment alors, avec l'extension, pour des liens vers des archives à deux dates différentes ? C'est de fait sans doute la seule critique que j'ai au sujet de ce système d'archivage, critique qui est moindre pour WebArchive, qui propose pour chaque page un nombre important de dates d'archivages.

PS5 : pour ce qui est d'ajouter au "title" html sur lien le titre véritable de la page cible plutôt qu'autre chose, là encore un modèle serait sans doute plus efficace qu'une extension ou un javascript (à condition que mediawiki finisse par donner la main sur les title - tout au moins, les liens sur images pour les archives le permettraient) ; là aussi, un paramètre de modèle pour ce "title" serait pratique, et là aussi un bot comme DeepBlue permettrait de le préciser (puisqu'il "visite" la page web, justement, il est logique qu'il voie le titre de la page dans le <head> qu'il reçoit)...

PS6 : de même, pour une page qui interdit l'archivage, un bot peut sans difficulté ajouter un paramètre précisant que pour ce lien aucune archive légale n'est disponible, empêchant ainsi l'affichage des liens vers archives associés au lien de la page en question : pour chaque lien, il peut sans difficulté vérifier à la volée le contenu du robots.txt correspondant, c'est pas bien compliqué et c'est pas la mer à boire...

PS7 : désolé du nombre important de PS...

PS8 : désolé aussi du pavé, hein...

Le système mis en place par Linterweb ne gère pas d'archives datées. Le rôle de l'extension étant d'étendre le parseur mediawiki afin de générer un lien externe d'un type spécifique (le lien vers la source suivi du lien archive correctement formaté), il ne se pose pas plus de question de date que dans la solution côté client (javascript) ou dans la solution modèles.

Pour ce qui est du title (attribut), il ne s'agit pas de reprendre le titre de la page cible, mais le libellé du lien source : de nombreuses pages Web n'ont pas un titre pertinent (élément title).

Cordialement, --Lgd (d) 15 novembre 2008 à 06:32 (CET)

Je me répète, mais... "Et pour les pages qui évoluent au cours du temps, parfois en supprimant des informations pourtant légitimes comme références/sources, on fait quoi ?"

Je croyais que le but des liens était la vérifiabilité ; si on veut juste un annuaire de lien, il y a del.icio.us ... si en revanche on veut pouvoir vérifier la validité d'une information basée sur une page web à une date précise, il est utile de préciser une date précise quant à l'archive à utiliser en regard d'un lien (rôle d'un paramètre "date" dans un modèle, ce qu'une extension "sensée" est incapable de faire, et un javascript sans modification du code source des articles est incapable de faire aussi) ; et puisque (nous sommes d'accord) Wikiwix ne propose pas d'archive datée, on perd de l'information en utilisant ce seul système d'archivage, lorsqu'une même page est utilisée comme source à deux dates différentes, avec deux informations qui disparaissent l'une après l'autre. Puisqu'aussi une page web disparue, mais archivée sur un archiveur alternatif (voire même le détenteur du site web en question), peut ne pas être connue de WebArchive ou Wikiwix, il me semble utile - au moins jusqu'à ce que Wikiwix récupère l'archive à son tour, si le robots.txt de l'archiveur peu connu le permet - de pouvoir indiquer une adresse d'archivage alternatif. Et là encore, une extension n'est pas capable sans modification du code d'indiquer ce genre d'informations.

Soit on veut promouvoir Linterweb et Wikiwix, soit on veut promouvoir Wikipédia. Il me semblait que c'était pour la qualité de cette dernière qu'on implémentait un système de cache associé, et pas pour une promotion des deux premiers...

Et si on veut une qualité suffisante, on se doit, par exemple pour les liens que j'avais exposés dans le domaine de l'astronomie, d'utiliser un système d'archives datées (si distinctes, bien entendu), chose qu'une extension ou un javascript - encore une fois... - sont incapables de réaliser.

les passages soulignés marquent que je me répète encore, sans obtenir de réponse autre que "on va demander une extension". les passages de couleur turquoise marquent les questions et informations répétées et restées sans réponse ou contre-argument.

pas que ça m'agace, mais...

Alphos ^{[me pourrir la vie]} 15 novembre 2008 à 17:53 (CET)

J'ai failli oublier le cas toujours en suspens des pages refusant net l'archivage : on en fait quoi, on laisse un lien vers archive quand-même ? Alors même que cette archive sera vierge ? Ou on considère qu'un paramètre de modèle permettrait de ne pas afficher les liens d'archivage ? Je doute qu'une extension MW soit une bonne chose de ce point de vue si elle doit par exemple vérifier les robots.txt des 140 et quelque liens externes de Paris... Imaginez le temps d'exécution, du côté serveur, sans parler de la bande passante supplémentaire - qui restera certes assez faible, mais multipliez un fichier de quelques dizaines d'octets par quelques milliers/millions/milliards de vérifications, et pleurez... Alphos ^{[me pourrir la vie]} 15 novembre 2008 à 18:09 (CET)

Maintenant que Wikiwix a récupéré le contenu d'internet archive, lier vers internet archive me paraît secondaire. La version d'archive essentielle pour Wikipédia est la date d'insertion sur les articles. À partir de là, on peut AMHA ajouter d'autres versions selon le cas, mais cela ne sera pas toujours pertinent, au contraire. Donc je suis contre l'application par défaut de internet archive, qui dans la majorité des cas ne fera qu'alourdir les articles. Par contre je compte bien promouvoir internet archive via le modèle Lien web, avec les paramètres "archive" et "archivedate", qui seront utiles quoiqu'il en soit.

Je propose qu'avant toute décision, comme de demander une extension ou pas, nous observions un peu la suite des événements. L'archive à été acceptée et appliquée sur tout WP, le projet suscite de nouveaux intérêts, beaucoup sont en train de découvrir cet outil petit à petit. Ne pas précipiter les choses, et prendre calmement le temps d'observer la suite des événements avant de songer à une nouvelle modification d'envergure.

On a plein de petites modifications à faire : WP:LE doit être mis à jour, par exemple. Il faut aussi prendre le temps : de nombreuses améliorations du script se font en ce moment, et de nombreuses discussions s'ouvrent à peine. Avant de demander une extension, je pense qu'il est nécessaire que le projet mûrisse un peu. Alors l'extension c'est pas pour aujourd'hui. Bien à toi, Dodoïste ^{[réveille-moi]} 15 novembre 2008 à 19:01 (CET)

1. Au fond je ne sais quoi dire de plus. Je ne suis pas opposé à l'ajout d'internet archive mais je doute que la communauté l'accepte. D'autre part, bien que j'apprécie sa variété de versions, je n'y vois pas une utilité décisive pour le moment. Pour la plupart, les changements apportés entre chaque versions sont mineurs. Et je ne vois pas ce qu'on en ferait, d'une manière purement pragmatique.
2. Pour les articles d'astronomie, j'avoue ne pas avoir bien compris ou se situe le problème.
3. Pour ce qui est d'indiquer une adresse d'archive alternative, cela ne change pas depuis notre situation initiale. L'usage d'un javascript ou d'une extension n'empêche pas d'apposer des modèles ou des liens lorsque c'est nécessaire. Raison pour laquelle je t'ai proposé d'utiliser ton bot à cet effet. Si tu détectes les liens qui ne sont pas corrigées à l'aide de wikiwix, tu peux leur ajouter un modèle capable de les corriger. Notre bon vieux {{Lien brisé}} peut être revu à cet effet. Bien à toi, Dodoïste ^{[réveille-moi]} 4 décembre 2008 à 23:49 (CET) Ps. Désolé de m'être fait attendre.

Le système mis en place par Linterweb peut être à tout moment modifié , c'est ce que j'ai spécifié à Olive028 http://fr.wikipedia.org/wiki/Discussion_Utilisateur:Pmartin/Cache#Javascript_et_comp.C3.A9tences , si vous souhaitez un système de date, ou bien un doublon de page mise en cache car la source est linké deux fois , aucun souci. On peut passer le titre de l'article au js, pour résoudre le problème de doublon sur deux articles différents. L'outil cache ou archive que nous proposons ne doit pas être vu comme une contrainte mais dites nous ce dont vous avez besoin et nous vous le ferons. J'avais même évoqué la création d'un projet afin de coordonner le projet. Cordialement Pmartin (d) 5 décembre 2008 à 00:59 (CET)

Je pense que, si c'est bien ce dont tu parles, un système de datage des version comme le fait internet archive s'avérerait bien utile. Cela permettrait également de résoudre le problème des mises à jour.

Je n'ai pas bien compris ce que tu entends par un doublon de la mise en page du cache.

Si nous voulons un projet, alors autant qu'il soit à Projet:Correction des liens externes/Archive.

Maintenant que l'archive est utilisée ici depuis bientôt un mois, je pense qu'on peut commencer à songer à en parler sur en:. Fais-moi signe lorsque tu te sens prêt. ^_^ Bien à toi, Dodoïste ^{[réveille-moi]} 5 décembre 2008 à 01:32 (CET) Ps. J'ai beaucoup aimé Kiwix 0.5. félicitations pour ce bijou.

Je pense qu'il faut séparer le traitement du cache lié à "source" et lié aux "liens externes", amha pour le premier il faut conserver la page tel qu'elle a servi comme source pour la communauté sinon qu'elle version affiché à l'internaute qui arrive. Une source doit resté source et ne pas avoir la possibilité de la mise à jours ( sauf dans le cas où elle sert à un autre article mais j'y reviendrai plus tard) , là le travail d'archivage des sources est efficace. Pour la partie concernant les liens externes , il me paraît judicieux de garder la dernière version mais qui n'est pas un site parking, car lorsqu'on tombe sur un site qui n'existe plus ou bien un site de parking Wikipedia perd en qualité.

Dans le cas où une page sert de sources à plusieurs articles, on peut tout à fait garder les différentes versions et affiché un arbre de type de internet archive. Ainsi cela permet à la communauté de contrôler si une page n'a pas tendance à se modifier au fil de la mode ( blog, forum, ...).

Dans le cas où une page sert de sources et de liens externes , nous pouvons effectuer deux traitements séparés. Le javascript permet de récupérer le titre de l'article soit en le passant au moment de la requète GET soit au en récupérant le referer afin de faire la distinction entre les deux.

Après il reste un cas qui est celui de la source qui est linké deux fois dans le même articles, ce qui me parait être réellement anecdotique en terme d'information au sein de Wikipedia. Car si un article contient deux fois le même lien je vois pas trop l'intérêt.

Par contre celà pourrait se faire que si une definition de type "lien externe" et "source" est clair pour la communauté, car à l'heure actuelle pas mal de confusion règne en la matière. A voir si un robot pourrait pas basculer les faux liens externes sur les sources en partant du principe qu'une source est rarement une page d'accueil voire avec un niveau de répertoire.

Donc voilà, il n'y a pas à constituer une internet archive géante, je pense que quelque chose qui s'approche à se que je décris plus haut peu parfaitement convenir, vous en pensez quoi ? Je pense qu'on pourrait mettre aussi Olive028* dans la boucle, car il était très intéressé par une mise à jours des liens externes.

Concernant la propagation du cache pour en , tu vois loin Dodoïste , c'est encore un peu trop prématuré tu vois on n'en discute encore , tout comme Kiwix 0.7 d'ailleurs. Cordialement Pmartin (d) 5 décembre 2008 à 06:58 (CET)

• Olive028 ==> Faux nez

[archive]

Vu la laideur et l'encombrement de cette chose inutile, y a-t-il un moyen pour que ces [archive] n'apparaissent que sur demande exprès, en cochant quelque chose dans préférences, sous gadgets par exemple ? Giovanni-P (d) 13 novembre 2008 à 12:38 (CET)

Le résultat de la PDD est une application par défaut. Il est possible de masquer les liens en ajoutant no_external_cache = true; à ton monobook. Si tu as des remarques précises à faire sur l'apparence ou l'utilité de l'archive, elles sont bienvenues. Amicalement, Dodoïste ^{[réveille-moi]} 13 novembre 2008 à 12:49 (CET)

L'inutilité est patente sur cet exemple: [archive] , si la page en question n'autorise pas le cache comme il est indiqué : « This page uses a tag to prevent archiving of its content, thus we're not archiving it. », alors on ne met pas le [archive] disgracieux.

Merci pour l'astuce Monobook, je tente la modif. immédiatement. Giovanni-P (d) 13 novembre 2008 à 13:03 (CET)

Cela signifie que l'auteur de la page ne désire pas que la page soit archivée. Il est donc nécessaire, pour des raisons de droits d'auteurs, que nous respectons cette interdiction. Il me semble toutefois que cette intierdiction est peu fréquente, et que de chercher un cache pour google est peu pertinent : google possède son propre cache, et n'a pas pour habitude d'être en erreur 404 = ce lien est valide. Amicalement, Dodoïste ^{[réveille-moi]} 13 novembre 2008 à 13:11 (CET)

La plupart des liens que j'ajoute dans un article sont des liens vers « Google Books » qui interdit l'archivage. Je pense donc que l'affreux [archive] ne devrait pas venir polluer les articles quand il n'a aucune raison d'être. Par défaut d'ailleurs ce [archive] ne devrait pas apparaître, il est inutile sauf dans le cas ou quelqu'un désire vérifier la véracité d'une source Web disparue. Pour le faire apparaître, il faudrait cocher une case dans les gadgets, ce serait plus malin et consommerait moins de bande passante que ces 20 ou 30 [archive] qui apparaissent dans la bibliographie des articles. Giovanni-P (d) 13 novembre 2008 à 13:21 (CET)

La possibilité de désactivé cette option est possible , il suffit de mettre no_external_cache = true; dans votre monobook.js. Après la solution de il est "inutile sauf" revienderai à un système intrusif car des requêtes par le fait du "sauf" tout en ne garantissant pas la fonctionnalité qui est que le système mis en place protège des évolutions de contenu des sites. C'est un javascript donc la quantité de bande passante est dérisoire. Cordialement Pmartin (d) 13 novembre 2008 à 17:43 (CET)

Une telle option ne devrait pas être activée d'office. Elle n'apporte rien à l'encyclopédie, elle-même. Elle n'est utile que s'il y a doute sur une source fournie. Par contre les [archive] enlaidissent considérablement les articles. À quoi bon s'efforcer de faire une mise en page correcte en vue d'obtenir un label BA ou AdQ pour que l'on vienne ensuite nous balancer des choses non désirées dans les articles. Giovanni-P (d) 13 novembre 2008 à 18:02 (CET)

• Pour le point 1, à savoir ne pas afficher le lien si le site refuse l'archivage, c'est possible en théorie, mais pas souhaitable en pratique. L'archive est mise en place via un Javascript dans Mediawiki:Common.js, ce qui fait qu'il s'exécute côté client. Pour faire ce que tu demandes, il faudrait que le script repère les fichiers « robots.txt » dans les pages web. Cela va donc alourdir le script, et rallonger le chargement des pages à un point propre à dégouter tout lecteur.
• La prise de décision a pour but de choisir si il faut le rendre accessible uniquement à qui veut via un gadget (proposition 1), aux utilisateurs enregistrés (P. 2), ou à tout le monde ( P. 3). La communauté a choisit la n°3 il y a bientôt un mois. Je t'invite à vérifier les calculs, et à regarder les avis de chacun. Maintenant, seules 52 personnes ont participé, car le sujet n'ayant que le méconnu Projet:Correction des liens externes comme prédécesseur, peu de gens étaient sensibilisés au sujet : c'est maintenant qu'ils se manifestent. Bonne continuation !
• Concernant le « ça ne sert à rien », il semble que certaines personnes y voient un intérêt... Dodoïste ^{[réveille-moi]} 13 novembre 2008 à 18:09 (CET)

Ça n'a intéressé que 52 personnes sur combien d'utilisateurs inscrits, c'est la question qu'il conviendrait de se poser. On peut imaginer que, pour une modification touchant à l'aspect de pratiquement toutes les pages, il faille un quorum, au moins 33% des utilisateurs inscrits participent au vote. Dans le cas présent c'est une décision arbitraire prise par une minorité. Giovanni-P (d) 13 novembre 2008 à 18:18 (CET)

Oui, tu as tout à fait raison. Dorénavant, pour que toutes prises de décision communautaire soit validée (et ça concerne les PàS et RfA) elle ait réunis un minimum de 162961 votants ( ou 5463 selon le nombre prix comme base).schiste 13 novembre 2008 à 18:27 (CET)

Une Prise de décision réunit parfois 100 votants, 200 au maximum. Amicalement, Dodoïste ^{[réveille-moi]} 13 novembre 2008 à 18:45 (CET)

Bien, vu le ton de la discussion, j'ai l'impression que la messe est dite. Conservons cette horreur puisque 50 contributeurs l'ont ainsi décidé. Giovanni-P (d) 13 novembre 2008 à 21:13 (CET)

À l'heure où j'écris, {{NUMBEROFUSERS}} : 489 037 (actualisé : 4 904 361), divisé par 3, cela donnerait un quorum de 163 012 contributeurs nécessaires pour valider une prise de décision portant « modification touchant à l'aspect de pratiquement toutes les pages ». Lorsqu'on sait que, s'agissant de l'élection des administrateurs, le record de participation (toutes opinions exprimées) n'a jamais dépassé les 220 contributeurs (le maximum ordinaire étant d'ailleurs d'environ 160), on se dit qu'il y a de la marge ... Hégésippe | ±Θ± 13 novembre 2008 à 21:55 (CET) – P.S. : désolé si ça fait doublon avec les réponses ci-dessus, ma réponse était restée « coincée » dans un onglet en conflit de modification, et comme j'ai toujours, incorrigible que je suis, au moins une quinzaine d'onglets ouverts en permanence dans Firefox, je n'avais pas vu que celui-là était resté « en rade ». Je me contente de réactualiser les nombres que j'avais plus tôt dans la soirée... Montrons au moins que plusieurs bons connaisseurs de Wikipédia peuvent avoir à peu près la même idée de réponse à peu près au même moment. Hégésippe | ±Θ± 13 novembre 2008 à 22:03 (CET)

@Dodoïste : « Pour le point 1, à savoir ne pas afficher le lien si le site refuse l'archivage, c'est possible en théorie, mais pas souhaitable en pratique. » → Si tu parles de faire une requête AJAX aux sites web concernés, alors ce n'est pas possible (si je me trompe pas) : les requêtes AJAX de JavaScript sont limitées au site sur lequel on est (au nom de domaine). Mais pour éviter le cas de Google Books, on peut prévoir ce cas spécifique dans le script : ne pas mettre le lien d'archive pour les liens commençant par http://books.google.com. — Delhovlyn — « ... » ^?, le 13 novembre 2008 à 22:27 (CET)

Alors autant pour moi :p

Certes il est possible d'ajouter un site aux deux déjà non archivés (internet archive et wikiwix lui-même). Maintenant je vois mal faire cela pour chaque site web un tant soit peu conséquent qui interdit l'archivage. Il existe 3007 liens vers Google books dans WP : je ne saurais dire si cela est beaucoup ou pas énorme. Pour comparaison http://www.legifrance.gouv.fr/ en a plus de 25000. Amicalement, Dodoïste ^{[réveille-moi]} 13 novembre 2008 à 23:36 (CET)

En fait c'est plutôt bien fait (après avoir vu plusieurs pages) et je suis plutôt pour garder une trace pages citées par des liens ext.
X-Javier ✉ ^{me parler} 13 novembre 2008 à 22:50 (CET)

Je suis entièrement d'accord avec Giovanni : les petits [archive] qui commencent à fleurir sur les pages rendent celles-ci de plus en plus indigestes et abiment certaines mises en page. Ces [archive] diminuent beaucoup l'ergonomie de wikipedia et à mon sens causent beaucoup plus de gêne au lecteur que cela n'apporte d'intérêt. Il y avait déjà un symbole avec une flèche pour indiquer un lien externe (en plus de la couleur bleue sur le lien), maintenant on se retrouve avec de surcroit un petit [archive] derrière, ce qui fait particulièrement moche dans des listes de ce genre:

Accès aux volumes en ligne : t.1, t.2, t.3, t.4, t.5, t.6, t.7, t.8, t.9, t.10, t.11, t.12, t.13, tables

Par exemple la page Encyclopédie méthodique sera complètement défigurée dès lors que ses liens seront "cachés" et que pleins de [archive] apparaitront sur la page!! Alors je propose deux choses:

1. Serait-il possible d'utiliser tout simplement la petite icône de lien, qui existe déjà, comme zone de clic pour accéder à la version "cache"? On n'aurait plus besoin de l'affreux [archive] qui pourrait dès lors être supprimé.
2. Serait-il possible, pour les auteurs des pages, de mettre sur les pages Wikipedia qu'ils écrivent des indicateurs désactivant l'affichage des [archive] pour tout ou partie des liens externes de la page? Frac (d) 27 novembre 2008 à 12:33 (CET)

Concernant Encyclopédie méthodique, les liens présents dans le tableau ne seront pas pris en compte (seuls les liens présents dans des listes sont affectés).

Pour l'icône à la place du texte, en effet, ce serait une possibilité. Mais l'icône signalant les liens externes ne peut pas être utilisée à cet effet.

La désactivation du cache au cas par cas n'est sans doute pas souhaitable. En revanche, elle peut être gérée pour des modèles de liens spécifiques, lorsque la mise en cache n'est pas jugée pertinente. --Lgd (d) 29 novembre 2008 à 21:28 (CET)

Liens externes

D'après ce que j'ai compris sur le bistrot, la question de savoir si les archives doivent apparaitre pour tous les liens externes n'est pas close. Si c'est bien le cas, il me semblerait judicieux de les réserver à ceux qui sont indiqués en notes, à l'exlusion de ceux qui sont indiqués en lien externe.
En effet, c'est dans les notes, qui contiennent les sources des articles qu'il peut être important (et qu'il est selon moi intéressant) de bénéficier de ce système. En revanche, les liens externes, d'une part n'ont pas nécessairement pour vocation à renvoyer vers une page en particulier, mais renvoient assez souvent vers des sites (donc vers leur page d'accueil.) Si l'archivage ne concerne que la page vers laquelle renvoie le lien, il gardera en cache une page d'accueil qui ne renvoie vers rien.
Par ailleurs, les liens externes de cette rubrique, s'ils ont été utilisés pour sourcer les articles, sont censés être mentionnés dans les notes. Auquel cas, l'archivage risque d'être redondant (et s'ils ne l'ont pas été, ils ne sont au mieux qu'un "plus" pour l'article, dont celui-ci se passera si le lien est cassé.) S'il est possible de faire en sorte que les caches ne soient activés qu'entre les balises (ref)(/ref), cela limiterait cette redondance (et permettrait à ceux qui le souhaitent de ne pas mettre de lien externe vers google-books qui refuse les caches dans ces notes, et de le réserver pour la bibliographie.) Non signé par User:Loudon dodd, diff

J'ai parfois vu de jolis documents pdf, n'attendant que d'être utilisés comme source, dans la rubrique liens externes (allez savoir pourquoi, je tenais à le dire :-) ).

Ce que tu propose me semble techniquement faisable. Maintenant je sais pas si cela risque d'alourdir beaucoup le Javascript utilisé (Lgd s'il te plait ? ). C'est en tout cas certainement faisable lorsque l'archive sera mise en place par une extension mediawiki. Maintenant faut savoir si il y a des oppositions à cette idée. Amicalement, Dodoïste ^{[réveille-moi]} 13 novembre 2008 à 18:56 (CET)

Pour ettayer cette thèse, il est vrai qu'il y a des liens externes qui sont des PDF http://fr.wikipedia.org/wiki/Sable_bitumineux#Liens_externes Pmartin (d) 15 novembre 2008 à 11:00 (CET)

Sur 3 Pdfs, deux sont en 404 et irrécupérables, dont un parce qu'il a interdit l'archivage par un robots.txt . Ces webmasters n'ont pas l'air de comprendre qu'un site web n'est pas éternel. Dodoïste ^{[réveille-moi]} 15 novembre 2008 à 11:23 (CET)

C'est très simple, normalement, au niveau du script. Il suffit de rechercher les liens dans document.getElementsByClassName("references") plutôt que dans document.getElementById("bodyContent"). D'ailleurs, l'idée me semble très intéressante. Et une option dans le monobook pourrait permettre d'étendre les liens « archive » à tous les liens externes, éventuellement ; mais que par défaut, ce soit réservé aux références. — Delhovlyn — « ... » ^?, le 13 novembre 2008 à 21:11 (CET)

C'est en effet possible. Trois remarques:

• il est préférable de ne pas multiplier les appels à getElementsByClassName dont les performances sont passablement médiocres sur une partie des navigateurs. Mieux vaudrait ajouter un identifiant via le modèle {{Références}}.
• le script, là encore pour des raisons de performances, est limité aux pages comportant moins de 50 liens externes (section lien externe et références confondues). Restreindre sa portée aux seuls liens des références permettrait d'étendre légèrement le nombre d'articles qui en bénéficient, et améliorerait en effet la pertinence globale de ce système (la mise en cache de diverses pages d'accueil est plus ridicule qu'autre-chose).
• les liens externes vers des sites bloquant la mise en cache pourraient être dotés d'une classe permettant au script (sans impact majeur sur les performances, cette fois) de ne pas proposer de lien archive inutile (Un bot peut se charger de la modification nécessaire).

Cordialement, --Lgd (d) 14 novembre 2008 à 06:18 (CET)

Sur de nombreux articles à l'état d'ébauche, les références sont présentées dans la section liens externes, et ces liens constituent parfois le seul moyen de vérifier l'article. Sur dix articles piochés au hasard, j'ai trouvé Picea sitchensis, François Pluchart, Mount Isa. Donc, tout bien pesé, je suis contre cette proposition. Amicalement, Dodoïste ^{[réveille-moi]} 14 novembre 2008 à 19:35 (CET)

A mon sens, un article qui ne comprend pas de notes n'est pas un article sourcé (ce qui n'est pas le cas du premier cité - aucune note ne renvoie aux site donnés en lien externes, d'ailleurs.) Procéder ainsi serait pousser les rédacteurs à utiliser les balises de références pour sourcer leurs articles, s'ils souhaitent que leur travail accède à une certaine pérennité.--Loudon dodd (d) 14 novembre 2008 à 19:41 (CET)

Humm je ne suis pas totalement convaincu concernant la non utilisation de la section "Liens Externes" pour la mise en cache, en effet les pages mises dans cette section ne sont pas systématiquement des pages d'accueil http://fr.wikipedia.org/wiki/Sable_bitumineux et d'autre part un site institutionnel n'est pas non plus garant de page 404 http://fr.wikipedia.org/wiki/C%C3%A9zac_(Gironde) le lien vers l'IGN n'est plus valide et le site de la mairie contient un parking. PS il m'a fallu que 10 minutes ce matin pour trouver ces 3 exemples. Donc je pense qu'on ne peut vraiment pas généraliser sur cette section et que cette section a également besoin de l'outil cache. Cordialement Pmartin (d) 17 novembre 2008 à 08:50 (CET)

L'outil, sous sa forme actuelle, ne traite qu'un maximum de 50 liens, autant étendre le traitement en retirant du champ d'application le bloc de liens les moins souvent pertinents pour une mise en cache. --Lgd (d) 17 novembre 2008 à 12:26 (CET)

« ajouter un identifiant via le modèle {{Références}}. » → Sauf que ce modèle n'est pas présent sur tous les articles, loin de là. Si on limite l'action du script aux pages portant le modèle {{Références}}, de très très nombreuses pages n'en bénéficieront pas, ça me semble « injuste ». =) — Delhovlyn • [discuter] – 17 novembre 2008 à 19:00 (CET)

Oui, il y a une solution plus complète sans l'identifiant, voir Discussion Utilisateur:Pmartin/cache.js. --Lgd (d) 17 novembre 2008 à 19:10 (CET)

MàJ : tous les articles, section référence

C'est fabuleux. Le script a été modifié presque en douce ce week-end par mes soins pour affecter désormais tous les articles (et pas seulement ceux comportant moins de 50 lienx externes) mais uniquement pour les liens de la section références, et personne ne râle .

Bon, si vous rencontrez un souci ou un type de liens en référence qu'il ne serait pas pertinent d'archiver, ou un type de liens en dehors de cette section qu'il serait au contraire pertinent d'archiver, dites-le. --Lgd (d) 3 février 2009 à 16:49 (CET) --Lgd (d) 3 février 2009 à 16:49 (CET)

^_^ Ce qu'il y a de bien avec cette modification du .js, c'est que l'archivage se fait toujours, et qu'on peut changer d'avis sans soucis. Amicalement, Dodoïste ^{[réveille-moi]} 3 février 2009 à 17:27 (CET)

pfff, si tu râles pas, c'est pas du jeu.

en revanche, plus sérieusement, quand tu parles de changer d'avis : s'il y a un mode d'emploi à mettre quelque-part, ce serait où ? Je pense à la désactivation totale du cache, par exemple.--Lgd (d) 3 février 2009 à 17:37 (CET)

/me profite de l'occasion pour râler : « Tonnerre de Brest et mille sabords ! Il faudra me passer sur le corpsle pseudo avant de désactiver cette archive, crénom. J'ajoute qu'il est politiquement correct de parler d'archive et non de cache. »

Pour ainsi dire, c'est une bonne idée, mais je n'ai pas trop d'idées non plus où le mettre. Pmartin avait soulevé l'idée de créer un projet pour coordonner les réflexions et actions sur cette archive, mais en fait je me demande si il y aurait ne serais-ce que trois inscrits... Alors en attendant ton choix sera le mien. Bien à toi, Dodoïste ^{[réveille-moi]} 3 février 2009 à 18:32 (CET)

Dans une page genre « Aide:Archivage des liens externes » qui serait accessible depuis une section dans Aide:Liens externes, non ?

ça me semble relever plutôt d'un atelier/projet/machin de gestion globale de l'interface et de ses évolutions que j'ai en tête. Cette fonctionnalité n'est à ce titre qu'une parmi quelques autres. Mais bon, peut-être est-ce trop tôt ? Cela dit, +1 pour l'intégration d'une page à l'Aide, bien que le projet de celle-ci soit assez confus et foisonnant actuellement--Lgd (d) 3 février 2009 à 19:59 (CET)

Ce qui est amusant aussi est que PMartin ne ne manifeste pas d'un poil. Mais ce n'est pas un souci. « Qui ne dit rien ne se fera pas taper dessus » est de bonne politique pour un prestataire de Wikipédia (sans compter qu'on peut aussi ne pas avoir eu le temps ou ne rien avoir à dire, ce que je suppose a priori). --Lgd (d) 3 février 2009 à 20:05 (CET)

Ce n'est pas parce que je ne participe pas au débat que je ne les suit pas :) T'inquiètes pas Lgd je suis toujours là, et je trouve que cela va dans le bon sens comme je mettais exprimer ici http://fr.wikipedia.org/w/index.php?title=Discussion_Wikip%C3%A9dia:Prise_de_d%C3%A9cision/Syst%C3%A8me_de_cache&diff=35862192&oldid=35858804 donc voilà. D'un autre côté, comme nous sauvegardons toutes les liens externes , on a de la marge sur les éventuels prises de décision de la communauté. Pmartin (d) 3 février 2009 à 23:49 (CET)

La restriction des archives aux références me pose un petit problème : il m'est arrivé de regrouper les liens vers les sources dans une section spécifique "Sources", avec renvoi à partir des références, pour en clarifier la présentation (par exemple dans l'article Société tibétaine) ; j'aimerais pouvoir forcer le mode archive pour certains liens de cette section (pages web), mais pas pour tous (comme les livres en ligne, où l'archivage ne porte que sur une seule page) ; est-ce possible, ou au moins envisageable ? Croquant (discuter) 4 février 2009 à 11:06 (CET)

Ça me fait penser qu'on a une possibilité de forcer la désactivation du mode archive au cas par cas (classe noarchive, ou qqch du genre), mais qu'on a pas prévu l'inverse, c'est-à-dire forcer le mode archive (pour des liens hors des références, comme dans le cas ci-dessus). Ça pourrait être bienvenu. — Delhovlyn • [discuter] – 4 février 2009 à 15:42 (CET)

Si ça peut porter sur un identifiant unique, c'est à dire ne forcer le mode archive que pour une section spécifique et unique, mais libre, ça peut très facilement se faire. Je vous proposerai quelque-chose dès que possible, cette semaine. --Lgd (d) 4 février 2009 à 19:19 (CET)

désolé, je pensais avoir répondu depuis.

En fait, c'est très loin d'être trivial. Et surtout, compte-tenu de la rareté de cette situation, il serait préférable de voir d'abord quelle autre organisation des sources et des notes/références permettait d'éviter ce souci (voir par exemple la gestion de deux types de sources dans l'article Accessibilité du Web). --Lgd (d) 23 février 2009 à 09:22 (CET)

Ça me rappelle un peu la phrase de Coluche (si ma mémoire ne me trahit pas) : « Dites moi ce dont vous avez besoin, je vous dirai comment vous en passer. » --Croquant (discuter) 23 février 2009 à 09:40 (CET)

Violation droit d'auteur

Ce projet de cache est une pure violation des droits d'auteurs et ne respecte pas la directive européenne sur le "caching" et les modalités prérequises. C'est du plagiat qui se couvre d'archivage, et non pas du caching. E

Nous refusons de voir les liens vers nos sites mis vers des plagiats sur wikimix.

Nous allons donc attaquer en justice la société qui édite le site wikimix, c'est à dire :

Linterweb

 Martin Pascal
 135 rue Grande
 Val de Reuil, 27100
 FR
 

1 _ ce système plagie et vole les oeuvres intiales en en retirant les applications javascript 2 _ le caching se fait en allant indexer les pages d'internet, et non pas en archivant les liens présents sur wikipedia. Les pages en cache doivent disparaitre lorsque la page disparait sur un système normal de caching, ce qui n'est pas le cas sur wikimix puisque ce système d'archivage a été mis en place en vue de sauvegarde les sources vers lesquelles pointait wikipedia. Si une source disparait, son auteur a le droit d'en retirer la publication en ligne sans qu'un système d'archivage ne lui republie son travail !

C'est cela le droit d'auteur : un auteur a parfaitement le droit de faire publier son travail quand il le souhaite, cela lui donne aussi le droit d'en retirer la publication quand il le souhaite.

Et un vrai système de caching, cela indexe les pages qui existent, car les caches qui concernent les pages qui ont disparues disparaissent, ce qui respecte le droit d'auteur.

Or, ici, le but de ce projet est d'archiver les pages des sites sources qui ont disparue. Et bien amenez moi le service juridique ou le cabinet d'avocat de wikimix, et on va voir lequel des deux juriste a réellement raison ! Si un site source retire de sa publication une oeuvre, personne n'a le droit de l'archiver pour la republier ailleurs.

Alors : 1 _ vous retirer toutes les pages archivées, car ces archives sont des violations du droit d'auteur 2 _ vous informez les sites source de ce message et vous leur expliquer comment elles ont été plagiées sur wikimix grace à la collaboration des contributeurs. 3 _ Cela vous embête quand un lien disparait ? et bien c'est votre boulot de mettre à jour wikipedia sans violer le droit d'auteur !

Bonjour. Il y a malentendu sur le sujet. Wikiwix est en fait une archive web, et non pas un cache, comme le signale les intitulés des liens dans les articles. Wikiwix est donc semblable à Internet archive.

Sachez que le but de cette archive est de permettre aux sites web de perdurer dans le temps, et est donc là pour faciliter la vie aux auteurs de sites web comme vous. Le but est de relayer l'information et de faire en sorte qu'elle reste accessible, même si le site d'origine a dû être fermé, ou si les serveurs hôtes sont indisponibles, si vous modifiez l'achitecture du site, et de nombreuses autres raisons. Voyez plutôt les listes d'erreurs 4XX (client) et 5XX (serveur).

Si vous ne désirez pas que votre site web soit archivé, rien de plus simple. Il vous faut ajouter un ficher robots.txt à votre site web, dont le contenu est le suivant :

User-agent: *
Disallow: /

Ce fichier interdit l'archivage à tous les archiveurs web. Sachez donc que votre site est également archivé par Internet archive. Par exemple, si vous désirez n'interdire que internet archive, le code est le suivant :

User-agent: ia_archiver
Disallow: /

Pour en savoir plus, voyez l'explication d'internet archive. Vous trouverez également pléthore d'informations sur le net. Cordialement, Dodoïste ^{[ dring-dring ]} 23 février 2009 à 22:10 (CET)

Merci Dodoïste pour ta réponse rapide et à Salebot d'avoir fait du good job. En effet, chez Monsieur Linterweb est la société dont je suis le gérant. Économisez votre énergie de telle sorte à ce que dans vos méta données vous positionnez cette balise <META NAME="ROBOTS" CONTENT="NOARCHIVE"> ou bien <META NAME="WIKIWIXBOT" CONTENT="NOARCHIVE"> le premier interdisant tout archivage de votre site , le second interdisant uniquement notre robot. Je me tiens à votre disposition sur ma page personnelle, pour accélérer le processus de mise à jours de vos meta ou bien du fichier robot. Cordialement Pmartin (d) 24 février 2009 à 00:42 (CET)

Bonjour cher gérant de l'interweb.

Déjà, d'une part, le droit d'auteur, et qui plus est le droit francophone relatif au droit d'auteur s'appliquant à ton serveur localisé en France, ne dispose en aucun manière l'obligation de mettre les codes, aussi sous forme de balise dans le header des pages, comme dans le .htaccess de n'importe quel dossier.

Donc, il n'est pas question qu'on aille mettre les codes pour tous les bots, surtout qu'un bot ne correspond pas forcément à la fonction d'archivage d'un site, un bot est un programme et il peut avoir des usages divers très différents les uns des autres ; d'autre part, on va pas rajouter du code pour tous les administrateurs de site d'archivage, vu qu'un développeur n'a pas à aller devoir se soucier des activités des autres développeur. Donc, d'un côté, comme de l'autre, ton histoire de code ne correspond en rien à l'activité d'un développeur, de même, c'est juridiquement illégal.

Comme je viens de te l'écrire par e-mail, tu as l'obligation de retirer tout plagiat issu de notre rédaction, obligation juridique, à moins que tu ne préfères une bonne décision de justice, qui par la suite, relayée, sera suffisante pour informer toute la communauté sur wikipedia. Le seul moyen de lutter contre les lines morts, c'est tout simplement de les retirer, et si ce retrait revient à mettre fin au droit de citation, il faut aussi réciproquement retirer le contenu issu de la citation reprenant les termes de l'oeuvre originale.

Ah, je précisais : tes explications concernant ton avocat en NTIC sont très vagues, mais bon, je suis juriste, et tout juriste sait pertinemment que l'explication qui t'a été donnée ne vient pas d'un avocat, ou du moins tu n'en a cité qu'une partie, ou tu as fait appel au servive d'un étudiant, ou d'un juriste qui ne connaît pas ce domaine. Et bien, tu as de la chance de tomber sur moi, car tu as un juriste spécialisé en NTIC et en droit d'auteur.

Alors, déjà, d'une part, tout archivage, que cela soit sur Internet Archive, ou sur wikiwix, est strictement interdit, et suscite les accords préalables de chaque propriétaire de site.

Pour Internet Archive, encore un article francophone sur wikipedia qui montre à quel point wikipedia n'est que participatif et loin d'être académique : Internet Archive a été soumis à de très nombreux procès, et jusqu'à présent, il n'y a pas un procès où les propriétaires privés de sites n'aient perdu. En conclusion : tout webmaster peut faire retirer tout archive le concernant de IA, et ce sans avoir à mettre de code. Et nous allons revenir un peu plus bas sur l'illégalité de l'archivage, je vais vous prouver par quelques bons cas bien concrets vous vous engagez à des poursuites pénales bien plus importantes que celles de la violation du droit d'auteur.

En autre, IA se dit humanitaire, il indexe tout site sans devoir passer par wikipedia, et il archive 100% d'une page, et son rôle ne consiste qu'à archiver. Il y a une certaine souplesse avec IA car ce site ne cherche pas à entrer directement en concurrence avec les oeuvres sources. Un des problèmes avec wikiwix, c'est que vous êtes une société commerciale, et vous archiver des oeuvres qui ont été publiées parfois même la veille. De toute façon, c'est bien d'avoir évoqué IA, car justement les gens connaissent mal cette fonction : mais ils ignorent aussi bien quels risques font encourir IA et wikiwix en matière de droit d'auteur, et en matière de protections des personnes ( en quelque sorte, on peut lyncher une personne en publique, et elle sera archivée grâce aux soins de IA et de wikiwix )

Déjà, sur l'argumentation dite d'aide, je vous arrête. Vous avez réalisées les archives de notre site en en retirant les régies publicitaires qui font vivre notre site. Et oui, que vous le vouliez ou non, pour avoir des infos, il faut des journalistes, les rémunérer, que personne ne travaille, je dis bien travaille, gagna sa vie, gratuitement. Si vous pouvez lire gratuitement des infos apportées par des professionnels, c'est parce que le taux de fréquentation sur les pages des journaux est subordonnée aux valeurs des régies publicitaires. C'est pour cerla que si un article sur wikipedi, s'enrichit et se complête grace à des sources externes, qu'il les cite en en faisant une liste en bas, l'utilisateur qui a créé cet article n'a pas le droit d'apposer à côté du lien source un autre lien vers votre site, wikiwix, qui fait du plagiat, et qui n'a pas d'autres buts que de se faire de la publicité à compter des articles de presse cités dans wikipedia.

C'est vrai que l'intervenant gagne un point ici : il n'y a aucune raison pour que l'archive Wikiwix vide la page en cache de ses régies publicitaires et de ses scripts. La bonne solution est de délivrer uen copie conforme du contenu, en ajoutant seulement un <base href="URL d'origine"> dans l'entête HTML afin que tous les scripts (et images liées et liens locaux sur la page) puissent fonctionner normalement (et tant pis si le site est hors ligne et ne peut délivrer ces scripts). Au moins ça permet au propriétaire du site de mettre en place, quand le site en en ligne, un script qui rechargera la page hors du frame de Wikiwix.

Wikiwix doit en faire le moins possible. Ce qui importe pour nous est de retrouver seulement un texte du site lié (et tant pis aussi si la site a été mis à jour et le contenu visualisé ne correspond plus à la date d'insertion du lien externe, ce serra à la communauté Wikipédia de supprimer les liens qui pointent vers un contenu qui ne correspond plus à la description. Le seul rôle de wikiwix devrait être d'afficher une page telle qu'elle était lors du dernier archivage, quand elle était encore en ligne.

Bref on ne doit voir le contenu du cache Wikiwix QUE si le lien est mort (erreur HTTP 300 et supérieur), et accepter aussi que le site lié voit son contenu changer au cours du temps (à nous alors de retirer le lien des pages si le contenu ne nous plait plus et ne correspond pas à nos attentes en terme de référence externe).

Aussi, lorsqu'on accède à une page Wikiwix, la première chose que Wikiwix doit faire c'est de vérifier si son cache a été mis à jour récemment (disons 24 heures maxi depuis la dernière vérification), et récupérer et cacher le contenu sans le modifier (pour mettre à jour son cache). Pendant ce temps, il renverra immédiatement le visiteur au site original dès qu'il aura vu que celui-ci a répondu par un statut inférieur à 300 (exception faite des statuts transitoires 100 qui veulent dire : page en cours de fabrication, veuillez patienter, le contenu arrive... pour lesquels on doit encore attendre un statut de fin réelle de transaction HTTP). Si le site répond 300 et plus, alors le contenu du cache pourra être affiché (mais là encore le base href doit être présent car il peut y avoir des contenus liés à l'intérieur de la page en cache qui fonctionnent encore).

Ceci signifie que par défaut le comportement de wikiwix doit être celui d'un transporteur (exactement comme les fournisseurs d'accès Internet qui ont aussi leurs caches) et non d'un hébergeur de contenu (même si ce contenu a changé sur le site, car justement le site a pu vouloir ajouter des liens publicitaires, ou en changer, ou les supprimer, ou ajouter de nouvelles conditions d'accès, ou retirer un contenu pour lui-même respecter le droit de la personne). Verdy p (d) 1 novembre 2009 à 05:34 (CET)

Donc, si nos serveurs sont inopérationnels, question d'infogérance, c'est notre problème, mais en aucun cas une tierce personne n'a le droit de procéder à un archivage de nos oeuvres, et c'est pour cela que vous serez pénalement condamnés. Dans le cadre d'un moteur, c'est différend : _ le caching va permettre de consulter l'oeuvre originale en son entier ( avec nos régies publicitaires, topus les élements, et non pas des oeuvres filtrées ) _ le caching sera temporaire, car à la prochaine visite du bot, la cahce va disparaitre automatiquement, alors qu'ici vous attendez que les utilisateurs de wikipedia supprime le lien. Donc, ce n'est plus de caching, c'est de l'archivage, et c'est illégal

Autre chose : en tant qu'archiveur, wikiwix est ipso facto responsable en tant qu'éditeur de son site internet au sens de la LCEN, vous ne bénéficiez pas du statut d'hébergeur, de prestataire technique, car en enregistrant, sans l'accord des auteurs des sites pointés par wikipedia, les oeuvres sources et en en republiant le contenu, vous agissez pleinement comme tout éditeur.

Voici un exemple de risque : _ Un éditeur fait un très bon article qui va intéresser les membres de la communauté wikipedia. Des membres de la communauté wikipedia vont pointer vers l'article en question. Il sera archivé par vos soins. _ Dans le site du même éditeur, l'éditeur se fâche de vois quelqu'un lui voler ses oeuvres, comme par exemple sur wikiwix. L'éditeur va donc publier un article comportant les nom et prénom de la personne qui édite le site qui plagie, et elle va accompagner son article avec des insultes. Comme l'éditeur est un infatiguable insatisfait, il multiplie les attaques personnelles, il publie plusieurs articles où il va diffamer plusieurs personnes. _ Bien évidemment, un membre de la communauté wiki ne va pas pointer sur un tel article, mais il y a un mais de quelque chose bien plus vicieuse : dans le contenu _ et oui, remontions au premier bon article, l'utilisateur de wikipedia pointe vers celui-ci. La page de l'article peut comporter un cadre qui génère aléatoirement une série d'article. Le bot de wikiwix arrive sur cette page concernant le très bon article, mais il se trouve qu'à ce moment là, dans le cadre en question, apparait un des articles diffamatoires avec les noms et prénoms de la personne. Donc, wikiwix aura archivé la diffamation, ainsi que les coordonbnées privées de la personne.

Là, on arrive à la partie la plus intéressante :

La ou les personnes qui se sont faites lynchées par l'éditeur portent plainte contre ce dernier. L'éditeur sera condamnée pour diffamation, insultes.

Oui, mais entre temps l'information aura tournée, et aura été enregistrée sur d'autres sites. ces personnes peuvent elles attaquer l'éditeur.

Réponse 1 : oui, sur les seuls sites où l'éditeur peut intervenir, commle par exemple la xonsole pour webmaster sur google news, les flux rss qui auront été simplement agrégés.

Réponse 2 : non, vis à vis des sites qui agrègent et édite des flux RSS ( rappelle toi petit on en a parlé sur webrankinfo, salon juridique ) mais aussi vis à vis des sites d'archives.

Donc, si wikiwix archive sans l'accord préalable des auteurs de site internet, c'est wikiwix qui encaisse. Et wikiwix ne pourra pas prétendre à la responsabilité des hébergeurs, ici vous êtes éditeur et devrez surveiller chacun des archives.

Oui, mais vous allez répondre que ceux sont les utilisateurs de wikipedia qui choisisent les liens, à cela je vous répondrais : oui, mais c'est vous qui avez choisi d'archiver sans le consentement des auteurs des articles, donc vous êtes directement responsables.

Encore autre chose : l'archivage est internet, et tout éditeur n'a pas à aller devoir placé les balises en question. Mais merci pour vos codes, comme si on était des newsbies, comme si on les connaissait pas, vous nous prenons pour des idiots. Tout éditeur connait ces balises, mais tout éditeur sait que son trtavail n'a pas à être archivé sans son accord Préalable.

Là aussi, il y a un autre cas bien plus concret : prenons le cas d'un journal qui a décidé d'archiver ses oeuvres et de soumettre la consultation de ces dernières à un abonnement payant, ce dont il est en droit de faire pendant toute sa vie et ses ayants droits pendant 70 années après le décès de ce dernier, comment pouvez vous justifier la protection du fond de commerce d'un journal si vous êtes venus l'archiver le piller par l'intermédiaire de wikipedia.

Je vois, vous avez besoin d'une décision juridique, et bien soit, cela sera fait !

Texte de loi et balise No - archive

1. Sur le caching et l'archivage :

Déjà, le caching est autorisé par la directive européenne prévue à cette fais en terme de droit de reproduction et de non divulgation au public. Donc, balise ou non, elle constitue une exception au droit d'auteur.

Mais pas le service de mise en archive. L'archivage doit être soumis au droit d'auteur.

2. L'exercice du droit de reproduction.

La loi dispose que tout accord de l'auteur doit être explicite, et non implicite. Cela signifie que tout droit de reproduction doit faire l'objet d'un contrat.

Art. L. 122-4. Toute représentation ou reproduction intégrale ou partielle faite sans le consentement de l'auteur ou de ses ayants droit ou ayants cause est illicite. Il en est de même pour la traduction, l'adaptation ou la transformation, l'arrangement ou la reproduction par un art ou un procédé quelconque.

Je vous renvoie aux notes de JP : http://www.celog.fr/cpi/lv1_tt2.htm#c2

Par ailleurs, en aucun cas l'absence de la balise "no-archive" ne constitue un accord de volonté susceptible de vous autoriser à reprendre le contenu. L'archivage étant interdit et non prévu aux exceptions du droit d'auteur, aucun éditeur n'est tenu d'insérer de balise ou de code s'opposant à l'archivage sur internet. Par conséquent, l'absence de ce genre de code ne vaut pas l'expression explicite de l'accord de l'auteur à pouvoir faire sujet à de l'archivage.

Plus concrètement : déjà que les sites insèrent une mention copyright, qui n'est pas obligatoire, ce n'est pas parce qu'un site n'insère pas de copyright qu'on a le droit d'en reprendre le contenu, de la même manière, ce n'est pas parce qu'un site n'interdit pas l'archivage qu'on a le droit de l'archiver.

Pour le problème des liens externes : il existe des scrip php qui permettent de vérifier la validité des liens, et il est tout à fait possible d'informer un article sur les mises à jour à faire, sans devoir passer par de l'archivage ou en archivant les oeuvres des auteurs.

Dans le cas contraire : _ tout éditeur archivé pourra poursuivre wikiwix _ tout éditeur archivé pourra poursuivre la fondation française wikipedia pour non respectd es droits d'auteur car l'usage des droits de citation est vicié, en se basant à la fois sur le cpp et sur la lcen car wikipedia n'est pas prestataires de service mais éditeur au sens de la LCEN _ poursuivre wikipedia sur le fondement de la DMCA, ce qui autorise ipso facto à demander à tous les éditeurs de sites plagiés de procéder à une dmca auprès de tous moteurs de recherche dont les serveurs sont aux USA ( en expliquant que la mise en cache constitue un non respect formel aux règle de fair use )

Remarque : attention à différencier la Wikimedia Foundation et l'association Wikimédia France. Vos propos concernent la première, pas la seconde. Je vous suggère également (si je puis me le permettre) de créer un compte utilisateur, ce qui facilitera les discussions ici avec vous, et vous donnera une image un peu plus positive auprès des contributeurs de Wikipédia (Je ne prononce aucun avis sur le fond de vos interventions, je le précise bien. Ce n'est qu'un conseil sur la forme). --Lgd (d) 24 février 2009 à 11:16 (CET)

Je vous remercie Lgd, je vais tenir compte de votre remarque, et créer le compte utilisateur. Mais voilà, je vais faire part à la communauté de wikipédia de quelques informations capitales, que vous pourrez aller vous même vérifier auprès de l'éditeur de wikiwix :

1 : Les plagiats que j'avais cités, effectués sous forme d'archive, ont été retirés, et ce sans avoir besoin de poser de balise noarchive. Le retrait des plagiats est une bonne chose, cela va éviter toute poursuite pénale. Mais quand on découvre des plagiats, on demande deux choses : retrait du matériel litigieux, et indemnisation. Donc wikiwix sera tenu de rembourser sous peine de poursuites civiles. Donc, l'affaire juridique n'est pas finie.

2 : Suite à l'entretien téléphonique que j'ai eu avec le responsable, il m'a affirmé que le service juridique auquel il avait fait appel lui avait confirmé la possibilité juridique d'effectuer de telles archives. Pour l'instant, il n' y a ni contact avec le service juridique, ni aucune preuve juridique et encore aucun texte de loi, ou directive communautaire, qui puisse légaliser la création de ces archives et de les publier. La seule exception concernent des établissements publics, et ce dans des conditions strictement bien réglementées, et les bibliothèques nationales par l'intermédiaire du dépôt légal.

3 : La pose des balises no archives : c'est l'expression du refus de l'auteur de se faire archiver, mais ce n'est pas l'expression de l'autorisation. Pour la loi, et cela même dans tous les autres pays, le consentement doit être expresse, c'est à dire que chaque auteur doit donner l'autorisation, et l'absence de balise ne signifie pas autorisation.

C'est bien gentil tout cela, mais au niveau NTIC, cet archivage reste illégal, et il n'y a aucun cabinet d'avocat ou de juriste qui ne saura dire le contraire, jusqu'à preuve du contraire. Mes interventions n'ont pas pour rôle de défendre mes seuls intérêts personnels, généralement elles ont aussi pour but de faire cesser toute activité illicite, même si ce n'est pas pour mon compte.

Limite des archives à la section référence : problème

Salut,

À l'article Pyramide de Bosnie, des liens externes [3] est en erreur 404. Il se trouve que bien heureusement cet article est présent dans le cache [4]. cependant, le lien [archive] n'est pas présent.

Informations :

• La page comporte 30 liens externes et c'est le 29^e.
• Ce lien n'apparait pas dans une référence mais dans la section ==Liens externes==

Sachant que le lien est de fait présent dans le cache, sais-tu comment rétablir ou forcer l'affichage du lien ?

Merci de tes conseils. — Jérôme 24 février 2009 à 18:56 (CET)

L'explication se trouve dans cette section : MàJ : tous les articles, section référence. Il y avait eu une idée, quelques mois plus tôt, de limiter l'affichage des archives à la section référence. Je m'y étais opposé, puis vu que j'étais le seul, j'ai décidé de laisser Lgd tester l'idée.

La raison : certains estiment que les liens hors balises référence ne sont pas des sources d'informations (page principale d'un site, et non pas la page intéressante qui sert de source d'infos).

Mon opposition : comme tu as pu le constater, il existe de nombreuses sources d'informations qui sont présentées en liens externes sans figurer dans les références. De plus, le problème est abordé du mauvais angle : si le lien présenté en lien externe renvoie vers une page d'accueil sans info encyclopédique, il faut modifier le lien de sorte qu'il présente la partie intéressante.

Donc, l'affichage du script a été modifié dans le common.js, mais Wikiwix archive toujours les liens.

En somme, j'aimerais qu'on reconsidère la restriction du cache à la section référence. Amicalement, Dodoïste ^{[ dring-dring ]} 24 février 2009 à 19:33 (CET)

Si je peux me permettre, deux remarques :

• Si un article est sourcé par des liens situés dans la section « Liens externes », il y a un problème, car les sources sont supposées être liées aux informations qu'elles sourcent (par le biais de notes de bas de page), sinon l'article n'est pas correctement sourcé. Cf. {{sources à lier}} et l'explication correspondante, ou encore Relier la source et les informations.
• Si un lien externe situé dans la section « Liens externes » contient des informations qui ne sont pas encore dans l'article, il faut ajouter ces informations, et placer le lien en note.
• Quand tu dis « le problème est abordé du mauvais angle : si le lien présenté en lien externe renvoie vers une page d'accueil sans info encyclopédique, il faut modifier le lien de sorte qu'il présente la partie intéressante », ce n'est pas pertinent dans la plupart des cas. En effet, dans l'absolu, les seuls liens externes acceptés dans la section « Liens externes » devraient être les sites officiels (les autres liens servant de notes). Dans ce cas-là, il n'y a pas de « partie intéressante » : l'information, c'est que le site officiel de telle entité est nomdedomaine.com, pas le contenu de ce site. La page à lier est donc bien dans ce cas la page d'accueil.

Hr. Satz 24 février 2009 à 19:57 (CET)

Hello.

1) et 2) : je parlais de sources d'informations qui n'ont pas encore été utilisées pour la rédaction de l'article, et qui tombent en erreur 404.

• Dans le cas d'un site "officiel", certes tu as raison. Il y a d'autres cas, qui, s'ils ne sont pas censés perdurer (il faut les utiliser pour rédiger l'article et hop dans une référence), restent de fait dans cette situation d'attente pendant un certain temps. Et pendant ce temps, ils peuvent passer en 404. Voilà. Amicalement, Dodoïste ^{[ dring-dring ]} 24 février 2009 à 20:37 (CET)

PDF illisible

Comment puis-je faire pour obtenir une version utilisable de ceci ?

  ...page d'archive d'un PDF...

J'aurais aimé avoir un lien vers la version originale non décorée... un PDF affiché comme texte, c'est frustrant. (D'autant plus frustrant qu'aucun des URLs contenuies dans cette page ne semble donner le PDF brut... ni même quoi que ce soit du PDF.)

Merci FvdP (discuter) 24 mars 2019 à 21:47 (CET)

C'est corrigé :) Pmartin (discuter) 27 mars 2019 à 01:07 (CET)

Beaucoup mieux en effet.

Merci :-) FvdP (discuter) 4 avril 2019 à 21:14 (CEST)

Pour l'article Anne-Marie Simond

Bonjour. Il y a quelques jours, j'ai entrepris un rangement nécessaire dans l'article AMS, au niveau des Notes et références, Annexes Bibliographie, Sources, Liens externes ; pour la section "Scénographie, décor et costume de théâtre", au sujet de la Quadriennale de Prague 1971, j'ai inséré l'adresse de la Quadriennale de Prague 1971 > archives > les noms des participants pour la Suisse, P. Simond et A.-M. Simond, le lien me fait certes aboutir à la bonne page du site, mais séparée en haut de page par ce texte :

Vous êtes en train de consulter une version archivée le 05/06/2019 16:41:14 de cette URL. Elle apparaît ci-dessous telle qu'elle était lorsqu'elle a été insérée comme lien externe dans Wikipedia., Vous trouverez des informations et pouvez donner votre opinion sur le cache sur cette page. | Si vous souhaitez interdire la mise en cache de ce site, merci d'utiliser le formulaire deblocage de site.

Compte tenu de la nécessité d'indiquer la preuve de ce que j'écris dans un article, comment puis-je insérer ce lien <normalement> — depuis plusieurs années, je ne fais plus, dans les articles de Wikipédia, que de la correction orthographe, grammaire, syntaxe, et je manque de d'exercice dans le langage wiki. Merci de m'aider, cordialement, Buster Keaton (discuter) 5 juin 2019 à 17:57 (CEST)

Remarques

- Je ne comprends pas bien pourquoi les "liens morts" impliquent un "archivage". Rien n'oblige à ce que les sources soient accessibles en ligne. Quand on cite un bouquin, la plupart du temps, il n'est pas accessible en ligne, et si le lecteur est intéressé, il doit acheter la version papier. Ne suffit-il pas de supprimer les liens morts en gardant les références vers la publication ?

Pour ce point je vous renvoie vers ces pages, https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Citez_vos_sources https://fr.wikipedia.org/wiki/Aide:Pr%C3%A9sentez_vos_sources/avanc%C3%A9e, je ne connais pas l'intégralité des choix de la communauté liée à ces choix.Pmartin (discuter) 31 août 2022 à 23:12 (CEST)

Ce sont des sujets différents. On peut citer des sources sans poster de lien. Cordialement. IP_MACHIN 92.184.100.142 (discuter) 4 septembre 2022 à 02:16 (CEST)

- J'ai pu constater sur quelques articles portant sur des sujets d'actualité que la plupart des liens pointent vers des articles de journaux. La plupart de ces articles ne sont plus entièrement consultables en ligne. Il n'y a plus qu'un court extrait et une invitation à payer pour accéder au reste. Ces liens ne sont donc pas "morts". Pourtant, ils sont quand même "archivés" par wikiwix. Je n'ai pas la moindre expertise personnelle sur la légalité de la chose, mais il me semble que mettre en ligne tout l'article alors que le propriétaire a fait le choix inverse de les faire payer ne peut que porter atteinte à son exploitation. Pourquoi ne pas considérer, comme pour les livres, que le lecteur, s'il est intéressé par les archives de journaux, peut aller normalement s'abonner au journal ?

Pour ce point, je réponds en tant qu'éditeur wikiwix actuellement aucune plainte ne m'est parvenu de la part des médias. Ils sont bien entendu au courant du système d'archivage qui n'est pas le seul sur le marché Wayback_Machine.Pmartin (discuter) 31 août 2022 à 23:12 (CEST)

Il y a malheureusement un univers entre le préjudice et la procédure. Mais le problème éventuel d'une action illégale (de wikimedia, pas de linterweb) est d'inclure une grande quantité de contenu fragile. En cas de dépôt de plainte, il faudra en toute logique retirer toute l'information associée aux liens qui disparaitront. Ce qui est dommage puisqu'il est si simple d'utiliser à la place de courtes citations légales. Cordialement IP_MACHIN 92.184.100.142 (discuter) 4 septembre 2022 à 02:20 (CEST)

Cordialement IP_MACHIN 92.184.102.117 (discuter) 26 août 2022 à 21:09 (CEST)