Discussion utilisateur:Pmartin/cache.js

Puis-je proposer quelque chose ? Voilà, je proposerais de changer le lien actuel :

<sup class="cachelinks"> (<a style="color: green;" href="http://wikiwix.com/cache/?url=http://bla.b?c=d">cache</a>)</sup>

... en cela :

&nbsp;<small class="cachelinks">[<a href="http://wikiwix.com/cache/?url=http://bla.b?c=d">version en cache</a>]</small>

Avec dans un CSS :

.cachelinks, .cachelinks a { color:#AAAAFF; }

Les changements que je propose, donc :

• <small> plutôt que <sup>
• crochets [] plutôt que parenthèses
• couleur plus discrète que le vert, un bleu pâle inspiré des liens vers les versions en cache de Google : [version en cache]
• apparence dans un CSS, c'est plus propre. Et il faudra en profiter pour exclure ces liens de la page à l'impression.
• les crochets de la même couleur que le lien
• [détail] Un   en dehors du small/sup plutôt qu'un espace normal dedans (donc plus petit)
• un intitulé différent : « version en cache » plutôt que « cache » (ça me semble plus explicite)

Voilà ce que j'estimerais plus adapté pour la discrétion et la clarté du lien. J'espère que mes propositions plairont. — Delhovlyn — « ... » ^?, le 27 septembre 2008 à 17:11 (CEST)

La PDD actuellement en oeuvre permet de prendre position sur le fond, la forme sera à étudier après. Je prends note de ta proposition, mais afin de ne pas écarter le débat initial, je ne préfère pas mélanger le fond et la forme actuellement. Cordialement Pmartin (d) 29 septembre 2008 à 09:44 (CEST)

D'accord, très bien. Oui, c'est vrai, j'ai souvent tendance à privilégier la forme au fond... — Delhovlyn — « ... » ^?, le 29 septembre 2008 à 19:30 (CEST)

Accessibilité

Le script nécessite une modification permettant de produire des liens explicites (conformité WCAG, ne pas avoir plusieurs liens au libellé identique et non explicite pour des cibles différentes). Il s'agit simplement de récupérer le libellé « Lorem ipsum » du lien externe concerné et doter les liens "archive" d'un attribut title du type « archive de Lorem ipsum ». Cela résoudrait au moins un des deux aspects problématiques pour l'accessibilité (le second problème d'absence d'alternative javascript reste en effet entier, mais n'a pas de solution pertinente possible actuellement). Cordialement, --Lgd (d) 12 novembre 2008 à 11:30 (CET)

ok pas de soucis je m'en occupe aujourd'hui. Pmartin (d) 12 novembre 2008 à 11:42 (CET)

C'est fait je n'ai pas pris le title mais l'url car souvent la balise title n'est pas explicite : "A lire en ligne",... Cordialement Pmartin (d) 12 novembre 2008 à 12:37 (CET)

Non, il ne faut surtout pas que l'url soit utilisée dans l'attribut title. Je sais bien que c'est le comportement par défaut de mediawiki sur les liens externes (exemple), mais c'est justement l'un de ses défauts les plus notables en matière d'accessibilité des liens.

L'attribut title sera notamment exploité par les lecteurs d'écran, c'est à dire les outils de synthèse vocale permettant de consulter un site Web : c'est lui qui permettra, s'il est correctement rédigé, de différencier deux liens « archive » au libellé identique mais ne renseignant pas sur leurs cibles respectives. Dans ce type d'outil, l'utilisateur accède en effet le plus souvent aux liens non pas dans leur contexte (qui permet de les différencier) mais isolément de celui-ci, par exemple à travers la liste des liens extraite de la page. Tu comprendras aisément que l'url est, à cet égard, un galimatias inutilisable...

Il est donc essentiel que cet attribut reprenne le libellé du lien externe original, qui est le seul à désigner explicitement sa cible (voir cette bonne pratique et pour plus d'explication cette fiche de méthode d'application d'accessibilité). Ce sera ensuite aux contributeurs de wikipédia à appliquer les recommandations d'accessibilité et à rédiger eux-même un libellé pertinent pour chaque lien externe concerné.

Pour te donner un exemple de ce qu'il faut implémenter, si le lien externe archivé est:

<a rel="nofollow" title="http://www.w3.org/WAI/" class="external text" href="http://www.w3.org/WAI/">Directives d'Accessibilité des contenus Web</a>

Le lien archive devra être du type:

<a href="..." title="archive de 'Directives d'Accessibilité des contenus Web'">Archive</a>

Si le lien externe est rédigé sans libellé explicite ([1]), il est alors évident que le script ne pourra que reprendre (hélas) le numéro automatiquement généré par mediawiki. Mais le problème se corrigera dès que le lien externe lui-même sera corrigé.

Cordialement, --Lgd (d) 12 novembre 2008 à 18:30 (CET)

(conflit de modif)

Avec une espace après le deux-points, ce serait bien. Sinon, j'ai l'impression que le libellé du lien serait en général mieux que l'URL, non ? C'est vrai que certains modèles donnent des liens du type « Lire en ligne », mais c'est le genre de choses qu'il faut changer dans ces modèles, puisque mauvais pour l'accessibilité. La plupart du temps, on essaie de mettre un libellé explicite. On peut aussi prévoir que le script choisisse, dans le cas d'un libellé non explicite comme « À lire en ligne » ou « [1] », de mettre l'url au lieu de ce libellé. — Delhovlyn — « ... » ^?, le 12 novembre 2008 à 18:43 (CET)

c'est fait Pmartin (d) 13 novembre 2008 à 00:55 (CET)

Lgd, par contre, dans « archive de 'Directives d'Accessibilité des contenus Web' », mettre des beaux guillemets français plutôt que ces moches single quotes, là. — Delhovlyn — « ... » ^?, le 12 novembre 2008 à 18:52 (CET)

La méthode utilisée pour récupérer le contenu textuel du libellé de lien externe a été corrigée dans MediaWiki:Common.js: external_links[i].firstChild.data; ne peut pas restituer comme attendu le contenu textuel des liens externes comportant des noeuds enfants, ce qui est le cas des liens externes avec mention d'un changement de langue, du type WCAG1.0, Guideline 10. Use interim solutions. Cordialement, --Lgd (d) 13 novembre 2008 à 07:13 (CET)

merci d'avoir corrigé dans le Commons.js Pmartin (d) 13 novembre 2008 à 07:30 (CET)

Cas de listes imbriquées dans les liens externes

Le script a été corrigé pour éviter que le lien archive ne soit généré après la sous-liste dans le cas de liens externes dans des listes imbriquée (exemple, liens externes de Faux-texte).

Sinon, une question: pourrait-on utiliser une valeur de gris beaucoup plus contrastée ? Le #AAAAFF actuel est très en dessous du ratio de contraste/luminosité requis. --Lgd (d) 15 novembre 2008 à 08:17 (CET)

Pour la forme j'avais suivi les conseils de Delhovlyn Pmartin (d) 15 novembre 2008 à 10:55 (CET)

Je constate un problème apparemment présent sur tous les liens, qui peut être lié à cette modification du script : le lien « [archive] » apparaît en double, identiquement, pour un seul lien. Voir Faux-texte#Notes : le lien de la note 3 a un lien archive juste après lui, avant le point, et un autre juste après le point. Pour les autres, les deux liens archive sont côte-à-côte à la fin de la ligne. — Delhovlyn — « ... » ^?, le 15 novembre 2008 à 16:41 (CET)

Et pour la couleur, en effet, j'aimais bien celle-ci, mais c'est en effet peu contrasté. On peut utiliser le #3366BB des liens externes, mais un peu plus clair serait mieux à mon avis, pour différencier. Je te laisse voir, Lgd, jusqu'où on peut descendre. — Delhovlyn — « ... » ^?, le 15 novembre 2008 à 16:50 (CET)

Est-il vraiment pertinent de les différencier des autres liens ? --Lgd (d) 16 novembre 2008 à 09:10 (CET)

Peut-être pas. — Delhovlyn • [discuter] – 19 novembre 2008 à 17:46 (CET)

Mais à part ça, personne ne remarque le bug dont je parle ci-dessus ? Je viens de purger mon cache, ça persiste. — Delhovlyn • [discuter] – 19 novembre 2008 à 18:02 (CET)

Non. importScript("User:Pmartin/cache.js"); figure encore dans ton monobook.js, je ne sais pas si cela a une influence. Bien à toi, Dodoïste ^{[réveille-moi]} 19 novembre 2008 à 18:22 (CET)

A supprimer en effet. --Lgd (d) 20 novembre 2008 à 02:56 (CET)

Oui, je venais de me rendre compte que le script était maintenant activé pour tout le monde, je ne savais pas... >.< Delhovlyn (d · c · b) (90.41.219.73 (d)) 20 novembre 2008 à 12:51 (CET)

Réduire aux liens de la section Références ?

Il sans doute un peu tôt pour faire cette modification, mais il faut envisager de restreindre l'application du script aux seuls liens de la section « Références » des articles. En effet:

• l'ajout des liens d'archive sur la section « Liens externes » est le plus souvent peu pertinente (mise en cache de pages d'accueil, de pages de sites institutionnels type IGN,etc). Ce point est encore en discussion dans la page de discussion de la PDD.
• en traitant par défaut tous les liens ayant la classe external situés dans une liste ul, le script va ajouter un lien archive sur des liens comme celui de Commons dans {{Autres projets}} si ce modèle évolue, comme c'est actuellement discuté, vers une syntaxe de liste plus appropriée que l'actuel tableau.

Réduire l'application du script à la seule section références peut se faire aisément en testant le ol class="references" (le modèle {{Références}} permettrait d'ajouter un identifiant qui optimiserait considérablement le script, mais son emploi n'est pas systématique). --Lgd (d) 17 novembre 2008 à 06:32 (CET)

Humm je ne suis pas totalement d'accord avec toi concernant ton analyse la section "Liens Externes", 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)

Bon, après quelques tests, le script est en fait plus lourd en traitement côté client en limitant à la section référence (obligation de traiter le cas de plusieurs OL class="references", notamment). Oublions ça. --Lgd (d) 18 novembre 2008 à 14:38 (CET)

FaQ

Il me semble temps de créer une FaQ, et une page où reporter les bugs. Je veux bien me charger de rédiger tout cela. Je propose d'afficher sur le iframe (c'est bien cela non ?) :

• « Vous pouvez obtenir plus d'informations sur la Foire aux Questions. Pour reporter un bug ou nous donner votre avis c'est par ici. »

Ou quelque chose dans le genre. Les adresses coisies te conviennent-elles ? Ont peut choisir un emplacement du projet correction des liens, ou de la PDD cache, ou ici-même.

User:Loudon dodd vient de me signaler que cette archive est en erreur 404 alors que l'original fonctionne. Peut-être qu'il était en 404 lors du crawl ? Je note aussi que lorsque l'archive est en 404, il n'y a pas de lien où reporter un bug, alors que c'est principalement dans ce genre de cas qu'il est nécessaire. Bien à toi, Dodoïste ^{[réveille-moi]} 13 novembre 2008 à 18:35 (CET)

C'est corrigé celà venait du "%20" dans l'url Pmartin (d) 18 novembre 2008 à 10:13 (CET)

Mise à jour de Utilisateur:Pmartin/cache.js et suivi des corrections

Suite à [2], j'ai mis à jour Utilisateur:Pmartin/cache.js avec la version actuelle de la fonction de MediaWiki:Common.js. Si cela convient, je mettrais à jour régulièrement en cas de nouvelles corrections, en les signalant ici.

Attention: la fonction fait appel à une autre fonction générique getTextContent présente également dans common.js. Faut-il l'ajouter également pour faciliter l'implémentation sur d'autres wiki ?

Sinon, désolé : j'avais oublié de signaler ici une correction, la dernière en date, sur le $(last).insertAfter(external_links[i]);, pour gérer correctement les cas où le lien n'est pas descendant direct de l'élément de liste li

Enfin, une question: le test if ((last.tagName == "SUP") && (last.getAttribute("class") == "cachelinks")) est-il encore utile ? Il me semble correspondre à la première mouture où le lien était généré dans un sup ? me gourge-je ? Cordialement, --Lgd (d) 18 novembre 2008 à 14:47 (CET)

oui je pense que getTextContent n'est pas présente sur les petits wikipedia et comme leur ressource en compétence javascript sont proportionnels aux nombres d'utilisateurs celà me paraît pas mal de l'ajouter. Oui j'avais vu j'ai mis Commons.js en suivi. Oui ca doit venir de la première implémentation. Cordialement Pmartin (d) 18 novembre 2008 à 15:26 (CET)

Mise à jour 2008-11-24

J'ai mis à jour Utilisateur:Pmartin/cache.js pour refléter les corrections de MediaWiki:Common.js suite aux discussions ci dessus:

• couleur plus contrastée du lien (accessibilité)
• suppression du code correspondant à une ancienne version des liens du cache

Cordialement, --Lgd (d) 24 novembre 2008 à 05:10 (CET)

Je reporte également un correctif que j'ai fait hier qui évite l'affichage en cas de lien interwiki. Pmartin (d) 24 novembre 2008 à 09:02 (CET)

cache

Bonjour,

L'archivage des liens est très utile mais pour le modèle {{GESTIS}} [3] ou la {{chimiebox}} [4], il n'apporte pas grande chose. Y-a-t'il une astuce pour les enlever dans ces cas-là?
Merci Epop (d) 29 novembre 2008 à 18:47 (CET)

Pour {{Chimiebox}}, les possibilités immédiates sont:

• modifier {{Chimiebox}} pour ne pas mettre les liens dans une liste à puces
• ou ajouter l'url du tollserver aux exceptions gérées par le script en fait non, voir ci-dessous

Pour {{GESTIS}}, à part encore l'ajout d'encore une url au script, on pourrait peut-être envisager une classe "noarchive" dans le modèle, si cela ne pénalise pas trop les performances du script. Je suppose que ce n'est pas le premier cas qui va se présenter. A voir. --Lgd (d) 29 novembre 2008 à 19:20 (CET)

fait pour la classe "noarchive", voir common.js et {{GESTIS}} (attention, il faut actualiser le cache du navigateur pour voir les effets).

Du coup, c'est fait aussi pour {{Chimiebox}} avec la même utilisation de cette classe dans {{CAS}}. Pour ce dernier, j'ai peu alourdi le modèle en ajoutant un nouveau <span class="noarchive"> plutôt que la classe sur les span existants, mais cela permet d'éviter de recourir à hasClass dans le script, ce qui est préférable côté performances.

Qu'en pensez-vous ? Cordialement, --Lgd (d) 29 novembre 2008 à 20:10 (CET)

Je pense que concerant {{GESTIS}}, on pourrait demander à Pmartin pourquoi les archives des liens générés par ce modèle sont en erreur 404.

Par exemple sur Tétrachlorure de carbone, comme sur d'autres inclusions du modèle Gestis, les archives de Wikiwix sont en erreur 404 alors que le site est valide. Je n'arrive pas à reproduire ici les urls car l'affichage pose problème à cause d'un [ dans l'url.

Par exemple si j'essaie d'afficher l'url : http://wikiwix.com/cache/?url=http://biade.itrust.de/biade/lpext.dll?q=[F+casnr%3A56-23-5]%26f=hitlist%26t=main-hit-h.htm%26tf=doc%26tt=document-frame.htm%26x=Advanced%26c=redirect%26s=Contents%26h1=Title[%2C100]

Je pense que c'est parce qu'elles sont en 404 que Epop trouve ces archives inutiles. Je suis certain que Pmartin peut corriger cela. Bien à vous, Dodoïste ^{[réveille-moi]} 29 novembre 2008 à 20:38 (CET)

Sinon je ne comprends pas pourquoi l'archive n'apporte pas grand-chose dans la chimiebox. Le Toolserver peut être momentanément ne 404 comme tout le monde. Et le modèle ATC ne crée pas de liens vers le Toolserver. Amicalement, Dodoïste ^{[réveille-moi]} 29 novembre 2008 à 20:49 (CET)

humm oui c'est bizarre on regardera ca lundi. Cordialement Pmartin (d) 30 novembre 2008 à 13:45 (CET)

c'est ok Pmartin (d) 1 décembre 2008 à 12:20 (CET)

Non en fait. C'est dur de corriger un bug alors que LgD a enlevé le cache du modèle GESTIS...

• Deux exemples de liens générés par le modèle : 1 et 2
• Les versions Wikiwix : 1 et 2

Problème : il manque une partie de l'adresse url : &fn=main-hit-h.htm&2.0.

Donc les pages mises en cache sont 1 et 2.

Bien à toi, Dodoïste ^{[réveille-moi]} 1 décembre 2008 à 17:36 (CET)

Affichage double

Bonsoir,

Je remarque ce soir que l'affichage de archive est doublé sur les pages. Voir par exemple Actions_en_justice_des_Présidents_de_la_République_française#Notes_et_r.C3.A9f.C3.A9rences.

Je ne fais généralement pas très attention aux liens, je ne sais donc pas si ce bug est récent.

Cordialement,

--Hercule ^Discuter 2 décembre 2008 à 22:15 (CET)

C'est parce que loadJs('User:Pmartin/cache.js'); figure encore dans ton Utilisateur:Hercule/monobook.js. Maintenant que le script est dans le commons.js, cela fait en effet doublon. Bien à toi, Dodoïste ^{[réveille-moi]} 2 décembre 2008 à 22:53 (CET)

Merci --Hercule ^Discuter 2 décembre 2008 à 23:02 (CET)