Discussion Projet:Scripts et gadgets/2018

Script MaintenanceCategorie

(copié depuis Discussion utilisateur:Mats01#Script MaintenanceCategorie)

Bonjour, je viens de voir passer tes modifs en rapport avec le script de maintenance catégories (la version commune, ta version). Le souci est que tu es basé sur une version plus ancienne du script, qui affiche moins de colonnes, et du coup cela entre en disparité avec les autres utilisateurs du script (exemple). Il faudrait vraiment que tu utilises la version commune, si tu as constaté un problème avec celle-ci je t'invite à le signaler au Discussion Projet:JavaScript. od†n ↗^blah 1 janvier 2018 à 14:25 (CET)

Bonjour, oui en effet c'était mon intention (en mettant à jour brievement ce matin ma sous page common.js pour ajouter "obtenir('MaintenanceCategorie');") mais je me suis rappelé que pour les portails comprenant beaucoup de pages, de mémoire environ 2500, le script sature (saturait?) en mémoire et la mise à jour ne se fait pas. Faute de mieux, j'avais dupliqué le script d'origine et supprimé les lignes interprojet et interwification que je jugeais moins intéressantes. Si la limite de mémoire n'est plus d'actualité, aucun souci pour utiliser la version commune, bien au contraire. Mats01 (discuter) 1 janvier 2018 à 14:50 (CET)

Il y a peut-être une erreur de conception quelque part dans le script, qui ferait que beaucoup plus de mémoire que nécessaire est utilisée. J'ai demandé à Mats01 s'il peut venir préciser le navigateur qu'il utilisait. od†n ↗^blah 1 janvier 2018 à 15:28 (CET)

Je découvre seulement cette page que je viens d'ajouter à mon suivi ! Pour préciser ma remarque précédente, j'ai constaté la limite en mémoire en voulant mettre à jour les pages Projet:Boxe anglaise/Suivi/Catégories et Projet:Athlétisme/Suivi/Catégories qui recensent plusieurs milliers d'articles. J'utilise depuis très longtemps firefox et non internet explorer que je sais peu performant. En regardant dans l'historique de ma sous page MaintenanceCategorie.js, le problème est apparu en mars 2013. Peut être que cela a été corrigé depuis. Si l'un d'entre vous peut mettre à jour la première des deux pages mentionnées avec la version commune du script, cela clôturerait le débat. Mats01 (discuter) 1 janvier 2018 à 15:51 (CET)

En migrant le format des réponses ajax de ce script, du format XML vers le format JSON, on pourrait déjà avoir un gain très substantiel… od†n ↗^blah 1 janvier 2018 à 17:00 (CET)

Est-ce que fait déjà la version commune ? Si ce n'est pas le cas, la migration nécessite t-elle un gros travail? Mats01 (discuter) 1 janvier 2018 à 17:56 (CET)

Pendant que je me suis plongé dans ce code pour étudier la modernisation des requêtes ajax, je me suis rendu compte qu'en fait ce script télécharge toutes les pages. Ce n'est donc pas surprenant qu'il mette du temps, et les optimisations auxquelles je pensais devraient en fait avoir un apport assez marginal. Le code HTML des pages parsées est téléchargé, mais les assets (images) sont aussi téléchargés, ce qui évidemment allonge énormément le temps, et ne devrait pas être nécessaire. J'ai cherché quelle partie du code provoque le téléchargement des assets mais je n'ai pas encore trouvé. od†n ↗^blah 1 janvier 2018 à 20:52 (CET)

Le chargement des assets est déclenché dès que le contenu HTML de la page (une string retournée par la requête ajax) est injecté via innerHTML dans un élément DOM pour analyse, même si cet élément n'est pas dans le DOM visible. J'ai essayé en fabriquant l'élément avec jQuery ($('code html').find(...)), pareil… od†n ↗^blah 1 janvier 2018 à 21:25 (CET)

C'est une problématique connue, alors déjà il y a la solution bourrinium (es veritas) qui consiste à trafiquer la source html avec regexes bien grasses, ou alors il y a cette solution qu'il faudra que je regarde : How to parse HTML response without loading any images. od†n ↗^blah 1 janvier 2018 à 21:33 (CET)

 Mats01 : J'ai un peu bricolé le script, il devrait maintenant être 4 fois plus performant. Si tu veux l'essayer de nouveau… od†n ↗^blah 1 janvier 2018 à 23:57 (CET)

Ah ah, j'ai testé sur Portail:Colombie/Suivi/Catégories avancement/ébauche (4852 pages) et voilà sur quoi je tombe : « Erreur : Le texte que vous avez soumis fait 3 455,308 Kio, ce qui dépasse la limite fixée à 2 048 Kio. Il ne peut pas être sauvegardé. ». Effectivement, là on est un peu coincé… od†n ↗^blah 2 janvier 2018 à 01:11 (CET)

J'ai effectué plusieurs modifications pour réduire la taille du code de la table générée, maintenant le script encaisse bien davantage. J'ai réessayé sur Portail:Colombie/Suivi/Catégories avancement/ébauche et maintenant ça passe. De justesse mais ça passe. od†n ↗^blah 5 janvier 2018 à 21:43 (CET)

Délistage gadget OldSearchBox

Bonjour, dans la veine de Projet:JavaScript/Maintenance 2017 des gadgets, je viens de délister le gadget OldSearchBox (code) des préférences, pour alléger un peu celles-ci. De mémoire, Spécial:GadgetUsage indiquait 20 utilisations parmi les utilisateurs actifs, ce qui est très peu.

Personnellement, j'ai toujours trouvé ça con déroutant, les boîtes de recherche avec deux boutons (style "google j'ai de la chance"), alors pour une fois qu'il y a quelque chose de correct dans l'interface de MediaWiki, ça serait dommage de le défaire. Mais pour ceux qui voudraient quand même, il est possible d'utiliser obtenir('OldSearchBox');

Enfin, j'ai mis à jour les documentations : Aide:Interface#Personnaliser l'interface, Aide:Apparence Vector#FAQ et accessoirement Projet:JavaScript/Liste des fonctions disponibles#Autres.

od†n ↗^blah 27 janvier 2018 à 01:33 (CET)

RevertDiff

Bonjour aux membres du projet. {{Test 0}} a été enlevé du gadget RevertDiff , serait-il possible de le remettre ? SammyDay (discuter) 30 janvier 2018 à 15:31 (CET)

Je viens de voir Projet:Aide et accueil/Bandeaux/2018. Laissez tomber. SammyDay (discuter) 30 janvier 2018 à 15:39 (CET)

Proposition délistage gadget RecentChangesBox

Bonjour, je propose de délister le gadget RecentChangesBox (code) des préférences, toujours pour alléger celles-ci. Le gadget resterait de toute façon utilisable via obtenir('RecentChangesBox').

De manière générale, je pense qu'il faudrait kicker ce genre de scripts "Game Boy", qui franchement n'apportent rien en fonctionnalités ou en ergonomie. Donc, si vous en avez d'autres à suggérer pour élimination… Vu que pour les utilisateurs qui voudraient, les scripts restent utilisables via obtenir('Guirlande'), je pense qu'on peut épurer sans trop de remords.

od†n ↗^blah 1 février 2018 à 14:19 (CET)

@Od1n Entièrement OK pour moi ! — 0x010C ^~discuter~ 2 février 2018 à 15:26 (CET)

Délisté des préférences, en ayant à cette occasion effectué un peu de maintenance sur le code. od†n ↗^blah 3 février 2018 à 14:00 (CET)

Où sont créees les bulles de prévisualisation des liens ?

Bonjour, je suis en train d'investiguer (discussion ici) un problème qui peut causer la dissimulation de texte important avec la prévisualisation des appels aux modèles dans la prévisualisation des liens, mais je ne sais absolument pas où ça se passe. C'est ici ? -- Camion (discuter) 2 février 2018 à 15:22 (CET)

Importer le gadget en:MediaWiki:Gadget-removeAccessKeys.js sur WP:FR

Bonjour,

Ce serait vraiment une bonne idée d'importer ce gadget sur WP:FR, et de le rendre disponible dans l'onglet gadgets des préférences pour tous les utilisateurs.

Ce gadget permet de désactiver les raccourcis claviers (AccessKeys) ajoutés par MediaWiki.

Sur les navigateurs comme Firefox, c'est la combinaison Alt + Maj + ... qui permet d'accéder aux raccourcis clavier ajoutés par les pages web.

Hors, la combinaison Alt+Maj est justement fréquemment utilisée par des modules complémentaires du navigateur, ou par des applications extérieures au navigateur, du fait quelle est très peu encombrée (pour ne pas dire polluée...) en raccourcis prédéfinis, tant par le navigateur que les applications extérieures et bien entendu tous ceux du système d'exploitation, (au contraire des plages Ctrl + Alt + ... et Ctrl + Maj + ..., et je ne parle même pas des plages Ctrl + ... et Alt + ..., qui sont archi-saturées).

Il n'existe aucun moyen simple de désactiver les raccourcis claviers ajoutés par MediaWiki. Hors ces raccourcis claviers sont d'une utilité assez limitée.

J'ai notamment le problème avec le module complémentaire Clippings, qui utilisent la combinaison Alt + Maj + Y, et que le module ne permet pas de modifier.

Ce module permet de préconfigurer des bouts de textes à ajouter, et permet l'utilisation de variables de manière assez poussée ([1]). Ce module m'est très pratique pour ajouter des messages sur des PdD, des caractères spéciaux, bref, des bouts de code en tout genres, en utilisant les variables (par exemple, pour ajouter une source, j'ai configurer un bout de code, et il demande les différents paramètres possibles, que l'on peut remplir ou pas, certains avec des choix proposées par défaut, etc.).

Hors MediaWiki utilise le raccourci clavier « Y » (donc Alt + Maj + Y sur Firefox, ainsi que sur pas mal d'autres navigateurs) pour afficher ma liste de contributions.

Après pas mal de temps passer à rechercher une solution sur la doc de Mozilla, j'ai découvert qu'en mettant l'option ui.key.contentAccess à 0 dans about:config, cela désactive tous les raccourcis claviers ajoutés par les pages web. Cela a donc permis de libérer mon raccourci clavier.

Mais cette méthode reste très peu pratique, et de plus il faut vraiment chercher pour la trouver, et avoir un minimum un esprit "bidouilleur".

Et voilà que cet après-midi, j'ai découvert le gadget en:MediaWiki:Gadget-removeAccessKeys.js disponible sur WP:EN, dont j'ignorais complètement l'existence jusqu'à aujourd'hui.

Comme je ne doit pas être le seul dans ce cas, serai t'il possible de l'importer sur WP:FR, et de l'ajouter à la liste des gadgets possibles ? car je suppose que je ne doit de loin pas être le seul à avoir ce genre de soucis de conflits de raccourcis clavier (et malheureusement, ceux des pages web l'emportent en cas de conflit).

Merci d'avance.

--Tractopelle-jaune (discuter) 24 février 2018 à 17:52 (CET)

Ajouter les gadgets contribs-relecture.js et hist-relecture.js d'Orlodrim dans les préférences ?

Bonjour,

Par la même occasion, serai t'il envisageable d'ajouter les deux gadgets contribs-relecture.js et hist-relecture.js de  Orlodrim dans les préférences ?

C'est toujours un truc qui m'a manqué de ne pas avoir l'information relu/pas relu dans les listes de contributions ainsi que sur l'historique des pages. Je n'ai jamais compris pourquoi cela n'était pas géré par MediaWiki.

Et aujourd’hui, je découvre ces deux gadgets sur Projet:JavaScript/Liste des fonctions disponibles. Immédiatement ajoutées à mon common.js, elles fonctionnent impeccablement.

Je trouve vraiment dommage de ne pas mettre ces deux gadgets en avant, ils comblent vraiment un manque majeur de l'interface MediaWiki.

Mentionner leur existence juste sur Projet:JavaScript/Liste des fonctions disponibles est vraiment dommage, car il est peu probable qu'un utilisateur qui n'est pas un minimum à l'aise avec ces bidouillages arrive jusqu'à cette page. Hors autant il est justifié de ne pas rendre disponible tous les gadgets dans les préférences, certains étants vraiment spécifiques, d'autres d'une utilité limitée.

Mais là, c'est deux gadgets s'adressent possiblement à plusieurs centaines de contributeurs réguliers autopatrolled.

Je pense justifié de les ajouter sur la liste des gadgets dans les préférences.

Qu'en pensez-vous ?

--Tractopelle-jaune (discuter) 24 février 2018 à 17:52 (CET)

Il y a encore quelques bugs, des ! s’affichent parfois sur des modifs relues. — Thibaut (discuter) 24 février 2018 à 19:44 (CET)

 Orlodrim et Thibaut120094 : Depuis la dernière mise à jour du gadget hist-relecture effectuée par Orlodrim, suite aux nouvelles possibilités de l'API, il me semble que le souci des ! s'affichant à tort sur les modifications révoquées par l'outil Rollback n'est plus d'actualité.

Ce problème provenait sûrement de la manière différente dont MediaWiki enregistre les modifications marquées relues manuellement ou par statut (autopatrolled), de celles révoquées via rollback, mais le nouvelle API n'est à priori pas concernée par ces soucis (qui sont gérés côté serveur).

C'était le souci principal du gadget hist-relecture (contribs-relecture n'est pas sujet à ce problème)

Est-ce que l'on pourrait envisager de passer ces deux gadgets dans le menu préférences/gadgets, car il comble vraiment un véritable manque de MediaWiki, et depuis que je les ais, je ne peux plus m'en passer. Ces deux gadgets sont tout simplement in-di-spen-sa-bles. Et je trouve extrêmement dommage qu'il ne soit pas plus facile à connaitre et activer, car le gain de temps apporté par leur utilisation est énorme. Que ce soit depuis une liste de contribs avec plusieurs dizaines de modifs à contrôler/révoquer, cela permet de voir tout de suite où on en est, d'éviter de laisser passer des vandalismes, tout en gagnant du temps.

Est-ce que il y a encore quelque chose qui s'oppose à basculer ces gadgets dans le menu préférences, en ne les affichant que pour les utilisateurs autopatrolled (peut-être avec un |rights=patrol dans MediaWiki:Gadgets-definition) ?

--Tractopelle-jaune (discuter) 3 juin 2018 à 10:23 (CEST)

Je veux bien que mes scripts soient déplacés, mais m'occuper de JavaScript m'intéresse de moins en moins, donc je laisserai quelqu'un d'autre gérer ça. Orlodrim (discuter) 3 juin 2018 à 16:32 (CEST)

Script refErrors

Bonjour,
mes connaissances en informatique sont nulles alors JavaSript est de l’Hébreu !
Néanmoins, depuis peu j’utilise Script refErrors (qui me semble un outil très malin). Je ne suis pas le seul (par exemple @Harrieta171, @Racconish et @Cantons-de-l'Est…)
Cependant, d’une discussion partie de Arcyon37 et à la suite de laquelle les compétences de 0x010C ont été sollicitées, celui-ci indique : « Je n'ai pas regardé plus avant sur la pertinence des résultats renvoyés par ce script, mais il semble qu'il y ai des trucs bizarres (après, je suis pas sûr de comprendre tout ce qu'il essaye de faire) » et, la conclusion est « Le script aurait un réel besoin de relifting, sous peine de tomber en rade un jour ou l'autre » sachant qu’il a été élaboré par Lgd, qui a cessé toute participation depuis 2012.
Pourriez-vous redonner ce « lifting » ?
--Cordialement. 6PO (discuter) 26 février 2018 à 20:23 (CET)

Bonjour @6PO. Petite remarque vu que j'avais toujours cette page en suivi, mais on ne peut pas considérer que Lgd a « cessé toute participation depuis 2012. » puisque ce compte a été bloqué indef, et l'utilisateur banni par la suite. Pour le reste, je laisse les développeurs répondre. — Superjuju10 ^{(à votre disposition)}, le 26 février 2018 à 21:37 (CET)

Notification depuis le résumé de modification

Bonjour,

Depuis aujourd’hui il est possible de notifier un utilisateur depuis le résumé de modification, pour les gadgets et scripts personnalisés qui placent automatiquement des noms d’utilisateur dans les résumés de modification, il faut maintenant penser à ajouter un deux-points pour éviter la notification, comme ceci : [[:User:Example]]. Cela semble aussi concerner les messages systèmes comme MediaWiki:Revertpage (j’ai reçu une notification pour cette révocation)

J'ai déjà mis à jour MediaWiki:Gadget-LiveRCSiteConfig.js, je me demande s’il faut aussi mettre à jour ces pages ?

Cordialement. — Thibaut (discuter) 15 mars 2018 à 22:59 (CET)

Bonjour Thibaut120094 ,

je suis très très très intéressé par cette nouvelle possibilité de notification.

Faut-il effectuer une manœuvre particulière préalable (charger une page JavaSript — laquelle et comment — ou autre) ?

Ceci n'est-il pas à diffuser à la communauté (par exemple sur Aide:Notifications) ?

Merci beaucoup de votre réponse et Cordialement. 6PO (discuter) 16 mars 2018 à 15:39 (CET)

Oui, dans ces cas il ne parait pas approprié de notifier l'auteur de la dernière bonne version. Le vandale gêne assez comme ça, on ne va pas en plus faire perdre du temps à un contributeur qui n'a rien demandé.

D'accord aussi pour mettre à jour les pages indiquées au-dessus. Les forks doivent rester à jour au moins pour ce genre de changements non ambigus et qui sont impliqués dans l'écosystème.

Par ailleurs, pour la maintenabilité il serait fort appréciable de réduire cette quantité de forks. À garder en tête, un démarchage des auteurs pour en supprimer une partie.

od†n ↗^blah 16 mars 2018 à 15:59 (CET)

J'ai posté un message sur translatewiki.net (à propos qui semble mal en point en ce moment, avec du javascript à moitié pété de partout…) od†n ↗^blah 16 mars 2018 à 16:41 (CET)

@Od1n : Je trouve en effet bizarre que personne n’ait prévenu translatewiki.net, merci d’avoir déposé un message.

@6PO : Il suffit de mentionner le lien interne de la page de l’utilisateur dans le résumé de modification, comme ceci : [[Utilisateur:6PO|6PO]] (ou plus court : [[User:6PO|6PO]]).

Les modèles comme {{notif}} ne fonctionnent pas. — Thibaut (discuter) 16 mars 2018 à 17:12 (CET)

Attention  Thibaut120094, [[User:6PO|6PO]] ne fonctionne que sur la WP anglaise. --Cordialement. 6PO (discuter) 17 mars 2018 à 03:30 (CET)

Non, les espaces de noms en anglais fonctionnent partout.

Dans ce diff, vous avez mis [[User|Harrieta171]] au lieu de [[User:Harrieta171|Harrieta171]]. — Thibaut (discuter) 17 mars 2018 à 03:33 (CET)

┌─────────────────────────────────────────────────┘
Il ne devrait pas être nécessaire de modifier le message de révocation pour qu'elles ne provoquent pas de notification. C'est un bug (phab:T189819 / phab:T32750#3997501). Orlodrim (discuter) 16 mars 2018 à 17:30 (CET)

Pré-hackathon au printemps à Montpellier

Bonjour,

Comme dit dans la section « Discussion tech à la WikiConvention et maintenance du projet JavaScript » plus haut, nous avions à la Wikiconvention évoqué l'idée d'un pré-hackathon centré sur la mise à jour des gadgets. J'ai initié la page de l'événement ici : mw:Wikimedia_Hackathon_2018/Prehackathon_Montpellier. N'hésitez pas à vous lister si vous êtes intéressés, afin que l'on puisse avoir une idée du nombre de participants. Vous pouvez aussi rejoindre la liste de discussions dédiée si vous voulez filer un coup de mains pour l'organisation. -Sylvain WMFr (discuter) 10 janvier 2018 à 19:29 (CET)

Hello, Les inscriptions sont ouvertes ! -Sylvain WMFr (discuter) 16 mars 2018 à 14:50 (CET)

Suis inscrit, merci Sylvain ! — 0x010C ^~discuter~ 16 mars 2018 à 22:47 (CET)

RenommageCatégorie

Bonjour bonsoir le projet,

Après une semaine de travail, je viens de finir une première version d'une réécriture complète du script de renommage de catégorie, en vue de le passer en gadget.

Celui-ci a été au cœur de la controverse autours de Polmars, plusieurs avis (@Sammyday par exemple de mémoire) ont indiqués qu'il manquait sans doutes d'une limite formelle à ces éditions automatiques. En plus d'une refonte complète de l'UI et des technos utilisés (utilisation de mw.Api au lieu des requêtes AJAX à la main par exemple), j'ai donc revu tout le système de limitation :

• Conservation du mécanisme de temporisation ;
• Ajout d'une limite à N éditions par 24h ;
• traitement un onglet à la fois des renommages ;
• dépôt automatique d'une requête aux bots une fois cette limite dépassé.

Notez aussi que:

• les personnes utilisant un comptes bot ne sont affectés par aucune de ces limitations ;
• pour ne pas encombrer les RBOT, je vais relancer d'ici ce soir ou demain un bot que j'avais pour traiter de manière automatique ces requêtes avec un rythme de passage élevé (traitement des requêtes toute les quelques minutes par exemple).

Je pense qu'avec cela, les deux partis de la-dite controverse seront satisfait : aucune habitude à changer d'une part (le dépôt d'une RBOT se faisant de manière transparente, pas besoin obligatoirement d'un compte séparé, rapidité d’exécution), les listes de suivi et autres modifications récentes plus spammés d'autre part (car passage par des RBOT au dessus d'une limite).

Le nouveau script est testable via le code mw.loader.load( '//fr.wikipedia.org/w/index.php?title=Utilisateur:0x010C/script/CatRename.js&action=raw&ctype=text/javascript' ); à ajouter dans son common.js.

J'aimerais beaucoup avoir votre avis et vos retours là dessus, ainsi que d'éventuelles suggestions et rapports de bugs si vous en trouvez.

Cordialement — 0x010C ^~discuter~ 17 mars 2018 à 17:02 (CET)

Hello,

Très bonne démarche, qui devrait permettre de résoudre les problèmes que tu évoques en douceur.

Petite question : N vaudra combien ? Il faudrait une valeur pas trop élevée, mais pas trop basse non plus, pour que les personnes qui font très occasionnellement des renommages de catégories puissent garder la main dessus sans passer par le bot. N = 200 ou N = 250 me semblerait pas mal.

Je n'ai pas testé ton gadget, tu l'as peut-être déjà mis en place, mais avant de lancer la requête aux bots, peut-être faudrait-il en demander la confirmation au contributeur (qui peut vouloir utiliser son propre compte bot s'il en a un, par ex.) ?

Merci, en tout cas ! — Jules ^Discuter 17 mars 2018 à 17:13 (CET)

La valeur de N reste à déterminer, je n'ai pas d'avis tranché sur la question. Elle est défini dans la constante DAILY_LIMIT présente dans les premières lignes du code.

C'est déjà le cas, le renommage manuel ou via requête se font via deux boutons différents (il est ainsi possible de passer par une requête même si la limite n'est pas dépassé ).

— 0x010C ^~discuter~ 17 mars 2018 à 20:05 (CET)

Bonsoir 0x010C, tu as eu une très bonne idée en voulant actualiser le code du gadget. Il semble bien fonctionner, avec une jolie interface :)

L'idée de proposer une manière simple d'appeler un bot me semble utile, et si on peut l'appliquer sans surcharger WP:Bot/Requêtes, c'est encore mieux ! Comme me le souligne Orlodrim (d · c · b), j'ai fait l'année dernière un script permettant de répondre à ces demandes de renommages. Mais il mangue d’améliorations nécessaires, en particularité la rapidité de déclenchement. Peut être devrait-on repartir de zéro pour cette partie. --Framawiki ^✉ 19 mars 2018 à 22:07 (CET)

Impressionnant ! Une petite remarque : pour le nouveau titre, il faudrait gérer avec et sans préfixe (actuellement il est obligatoire de saisir sans préfixe). Parce que sinon, tu peux être certain que l'erreur sera faite à foison par les utilisateurs !

Je viens de regarder rapidement le module mw.Title, et considérant qu'il faut conserver les autres namespaces (e.g. "Catégorie:Wikipédia:Trucmuche"), je pense que le mieux serait en fait de le faire à la main : value.trim().replace(/^([Cc]atégorie|[Cc]ategory):/, '');, et cela dans une fonction helper de sorte à ne pas répéter le code.

od†n ↗^blah 19 mars 2018 à 22:37 (CET)

Autres petits points : je t'encourage à utiliser le wrapper "mediawiki.storage" (exemple), j'avais regardé et effectivement, il est justifié de l'utiliser. J'attire aussi ton attention sur le commentaire de ce diff. od†n ↗^blah 19 mars 2018 à 23:14 (CET)

Merci beaucoup @Od1n pour ces retours et tes modifications !

Je regarderais plus en avant ce soir les modifications que tu suggère, mais cela me semble tout à fait pertinent à première vue. Concernant le window.catRename, il me sert en fait à débugger, pour analyser facilement l'état des différents attributs, il n'a en effet plus de sens dans un environement de production. — 0x010C ^~discuter~ 20 mars 2018 à 11:17 (CET)

@Od1n Le script gère à présent les cas avec et sans prefix proprement et j'ai switché pour mw.storage. J'ai fini d'ajouter les autres petites améliorations que j'avais en tête (gestion plus avancées des boutons d'action, utilisation de mw.Message pour les textes,...), je pense que le script est pleinement prod-able maintenant.

@tous Que pensez-vous de passer ce script dans les gadgets d'ici une semaine et, après annonce à ses utilisateurs actuels, rediriger l'ancien script vers ce nouveau ?

— 0x010C ^~discuter~ 23 mars 2018 à 23:39 (CET)

Chez moi le tooltip d'aide, pour le nouveau nom, fait apparaître plein de scrollbars horizontales. Ce tooltip n'ayant plus vraiment d'utilité maintenant, je propose de simplement le supprimer. od†n ↗^blah 24 mars 2018 à 00:15 (CET)

Ce serait pratique que le champ pour le nouveau nom soit prérempli avec le nom actuel, comme pour un renommage normal (en empêchant le renommage d'une catégorie vers elle-même... même si c'est actuellement impossible en raison d'une autre restriction, l'impossibilité d'utiliser le gadget lorsque la page cible existe).

Ce serait pratique que le champ pour le motif soit prérempli avec « Tais-toi et fais ce que je dis », pour éviter d'avoir à en donner un. Bon, on verra à l'usage

Pour le traitement automatique des requêtes, tu as quelques chose d'utilisable ? Je peux m'en occuper, sinon. Je tiens à ce que ça se fasse, pour que les contraintes de la nouvelle version ne ralentissent pas les utilisateurs.

Orlodrim (discuter) 24 mars 2018 à 11:04 (CET)

@Od1n  Fait.

@Orlodrim  Fait. le champ de nouveau titre est pré-rempli, avec un message d'erreur dédié si identique à l'ancien. Concernant ton second point, je suis tout à fait d'accord que la réactivité du bot est un point primordiale. J'ai déjà un script près à tourner à un rythme très régulier, je vais lui créer un projet dédié sur toolforge ce week-end.

— 0x010C ^~discuter~ 24 mars 2018 à 13:13 (CET)

Dans les messages d'erreur, j'ai essayé de supprimer le bouton « Rééessayer », mais sans succès (refs 146763621, 146763699). Si tu es intéressé pour trouver la solution… Documentation : Processes and errors, API OO.ui.Error, ProcessDialog.js. od†n ↗^blah 24 mars 2018 à 21:34 (CET)

@Od1n oui, je sais pas non plus pourquoi ça ne fonctionne pas, d'autant que j'avais déjà utilisé cette fonctionnalité (avec succès) dans un autre script... Je m'y pencherais mais pas de suite.

@Od1n, @Orlodrim, @Framawiki, @Jules78120 et @Habertix Le bot est en route et le script est dans la liste des gadgets. Je vais laisser un message sur le bistro de demain (car 1er avril aujourd'hui...). Je pense notifier les utilisateurs actuels du script, et change le script actuel pour une redirection dans quelques jours.

— 0x010C ^~discuter~ 1 avril 2018 à 18:03 (CEST)

 0x010C : Merci pour cette nouvelle version. En plus, il semble que tu as activé NeoBot (d · c) sur Wikipédia:Bot/Requêtes/Catégories . Y a-t-il des restrictions pour éviter les abus ? Sinon, il serait peut-être utile de mettre au moins une semi-protection. Autre question, si quelqu'un souhaite annuler sa requête (ou celle de quelqu'un d'autre) pendant qu'elle est en cours de traitement, est-ce possible ? Orlodrim (discuter) 1 avril 2018 à 18:09 (CEST)

@Orlodrim Je voulais mettre une semi-protection, j'ai oublié, merci de me l'avoir rappelé (note que le gadget n'est activable que pour ceux ayant le droit move, c'est à dire les utilisateurs auto-confirmé, ça va dans le même sens). Pour annuler une requête, si le bot n'est pas encore passé il suffit de retirer la ligne en question, pendant son passage en l'état actuel il faut bloquer le bot .

Au final, je voulais régler ça tout de suite donc j'ai quand même mis un message sur le bistro d'aujourd'hui.

— 0x010C ^~discuter~ 1 avril 2018 à 19:23 (CEST)

Hello 0x010C, super avancement. Serait-il possible de créer un compte dédié pour les renommages ? Tel que Bot de renommage de catégories (d · c · b), donc la fonction est clairement explicite, plutôt que les modifs apparaissent avec un compte plus original ? Bonne soirée --Framawiki ^✉ 1 avril 2018 à 22:32 (CEST)

Proposition d'amélioration

Bonjour,

Comme un clic sur l'icône "poubelle" du bandeau {{SI}} utilise le champ raison= du modèle pour remplir le motif de suppression (très pratique pour les admins paresseux ), est-ce qu'il est possible d'ajouter le nouveau nom de la catégorie ? Pour le moment le gadget génère "Catégorie récemment renommée (raison)". Est-ce qu'on peut mettre "Catégorie renommée en [[:Catégorie:Nouveau_nom]] (raison)" en gardant le lien cliquable dans le journal des suppressions ? -- Habertix (discuter) 14 mai 2018 à 23:38 (CEST).

PS  0x010C et Od1n : qui sont les principaux contributeurs sur le .js du gadget.

@Habertix céfé — 0x010C ^~discuter~ 14 mai 2018 à 23:44 (CEST)

J'ai annulé car si c'est bon dans le journal la catégorie à supprimer est catégorisée à tort dans la nouvelle. -- Habertix (discuter) 15 mai 2018 à 00:39 (CEST).

cf diff, j'ai voulu aller trop vite et j'ai oublié le : initial qui transforme la catégorisation en lien normal ; c'est mieux maintenant . — 0x010C ^~discuter~ 15 mai 2018 à 01:22 (CEST)

Tout bon ! Merci. -- Habertix (discuter) 15 mai 2018 à 23:53 (CEST).

Alerte notification chez envoyeur

Enregistré sur Phabricator
Tâche 187264

Bonjour Thibaut,
la notification à partir du résumé de modification fonctionne mais :

1. Sur WP France seule fonctionne la syntaxe [[utilisateur:xxxx]]
2. Beaucoup plus gênant, il est certain que la marque rouge qui devrait apparaitre sur la cloche n'est jamais présente chez celui qui envoie.

Est-il possible de remédier à cette dernière donnée ?
--Cordialement. 6PO (discuter) 20 mars 2018 à 19:53 (CET)

Je ne connais pas WP France, c’est un nouveau wiki ?

Pour l’absence de notif à l’envoyeur c’est effectivement un bug, il faudrait le signaler sur Phabricator. — Thibaut (discuter) 20 mars 2018 à 19:55 (CET)

Je ne comprends pas le problème rapporté. Trizek (WMF) (discuter) 21 mars 2018 à 09:27 (CET)

Après avoir testé manuellement dans la section ci-dessous, je confirme que [[user:xxxx]] fonctionne. J'ai eu un popup temporaire pour me confirmer l'envoie, et j'ai bien recu la notification (cloche rouge) sur l'autre compte. Maintenant j'ai fait ça à la main, pas avec de JavaScript. — Zebulon84 (discuter) 21 mars 2018 à 16:59 (CET)

Dénomination de Wikipédia

Bonjour Thibaut,
je ne sais pas comment nommer correctement Wikipédia, en clair la version francophone de Wikipédia — ainsi dénommé (« Wikpédia France ) elle est facilement comprise par les nouveaux contributeurs mais il ne faudrait pas les emmener sur une fausse piste. Quelle est la bonne réponse ?

Qui se charge de mentionner le bug sur « Pabricator » ? Mes compétences Wikimedia, JavaScript, tout ce qui concerne les modèles ou l'informatique sont nulles et archinulles. Je serais incapable d'exposer clairement le problème (la preuve avec Trizeck) et encore moins de soutenir une discussion !

--Cordialement. 6PO (discuter) 21 mars 2018 à 13:40 (CET)

 6PO : fr.wikipedia ou Wikipédia en français, et non Wikipédia France. Comme en.wikipedia n'est ni Wikipedia Angleterre, ni Wikipedia État-unis mais Wikipedia en anglais. — Zebulon84 (discuter) 21 mars 2018 à 16:53 (CET)

Merci Zebulon84, c'est clair pour tous.--Cordialement. 6PO (discuter) 21 mars 2018 à 17:00 (CET)

Envoyeur non prévenu de l'envoi de notification

Bonjour Trizek (WMF),
je me permets de reprendre car je pense pas savoir d'autre formulation à proposer : « la marque rouge qui devrait apparaitre sur la cloche n'est jamais présente chez celui qui envoie. »
Il existe une façon simple de procéder : configurer vos préférences avec :

• « Échec de la mention d’un utilisateur » ;
• « Succès de la mention d’un utilisateur ».

Dans l'un et l'autre cas il devrait apparaitre une marque rouge sur la cloche. Or il n'en est rien comme l'indique Thibaut : « Pour l’absence de notif à l’envoyeur c’est effectivement un bug ».

Qui se charge de mentionner ce bug sur « Pabricator » ? Mes compétences Wikimedia, JavaScript, tout ce qui concerne les modèles ou l'informatique sont nulles et archinulles. Je serais incapable d'exposer clairement le problème (la preuve avec Trizeck) et encore moins de soutenir une discussion !

--Cordialement. 6PO (discuter) 21 mars 2018 à 13:40 (CET)

6PO, il faudrait regarder si le bug n'est pas effectivement lié à un script ou un gadget. Trizek (WMF) (discuter) 21 mars 2018 à 16:37 (CET)

Merci Trizek (WMF) de cette réponse a proprie mais j'ai du mal à l'appliquer car en anglais ! --Cordialement. 6PO (discuter) 21 mars 2018 à 17:03 (CET)

Une traduction est fournie, 6PO : voir en haut de la page sous le titre : mw:Help:Locating_broken_scripts/fr. :) Trizek (WMF) (discuter) 21 mars 2018 à 17:38 (CET)

 Trizek (WMF), 6PO et Thibaut120094 : Ce problème semble être celui reporté sur phab:T187264. — NoFWDaddress ^(d) 2 avril 2018 à 00:35 (CEST)

Poisson d'avril 2018

Bonsoir !

Dans le cadre du Wikipédia:Sondage/Poisson d'avril 2018 autres propositions‎, Lrq3000 (d · c · b) a créé une proposition de JS/CSS permettant de modifier la page d'accueil dans le cadre du premier avril prochain. Le sondage est en bonne voie, Lrq a donc publié son code sur Github. https://github.com/lrq3000/wikipedia-fr-aprils-fools (Sujet:U9lup1eflw2btxyi).

Serait-il possible pour des connaisseurs de javascript de relire/compléter/corriger/ajouter des fonctionnalités à ce code ? Il sera exécute sur des centaines de milliers d'ordinateurs, donc mieux vaut qu'il soit relu et consensuel :)

Par ailleurs, ce serait je pense souhaitable de réfléchir à la manière de déployer ce code pour la journée en question. Peut être qu'un gadget serait plus praticable qu'une modification des Common.js et css, puisque étant clairement séparé, chargé par le ressource loader, activable et désactivable rapidement, et serait testable par tous en activant une coche dans les préférences.

Ping Utilisateur:Od1n, Utilisateur:0x010C, Utilisateur:Prométhée et Utilisateur:Arkanosis : vous serez sûrement intéresses par regarder le script.

Merci ! --Framawiki ^✉ 22 mars 2018 à 21:54 (CET)

Hello Framawiki, Lrq3000 et les autres

Pour ma part, je serais rassuré s'il n'y avait pas d'utilisation de innerHTML avec des variables : pas que ça introduise nécessairement de faille de sécurité, mais ça rend d'autant plus difficile de s'assurer de leur absence.

Par ailleurs, le lien pour désactiver le poisson d'avril n'est « visible » qu'à la fin de l'animation — et à vrai dire pas vraiment visible car caché dans le reste du texte ; il vaudrait mieux qu'il s'affiche dès le début et à des endroits très visible (première ligne et dernière ligne de la page, par exemple).

Amicalement — Arkanosis ^✉ 22 mars 2018 à 23:57 (CET)

<sarcasme> Chouette ! Si on a autant de main d'œuvre pour développer un truc aussi dispensable, ça veut dire qu'en fait on a plein de main d'œuvre pour faire la maintenance du javascript sur le wiki ! od†n ↗^blah 23 mars 2018 à 00:56 (CET)

Merci beaucoup Framawiki d'avoir posté ici, je ne connaissais pas ce projet, et merci à tous pour vos feedbacks :-) Je vais essayer de corriger tout cela point par point dans les prochains jours. J'ai une autre question: je suis en train de préparer un easter egg (un truc interactif, je préfère ne pas en dire trop pour garder la surprise ;-) ), et j'ai maintenant une première maquette fonctionnelle :-) Je comptais initialement le proposer en bonus au style (en un lien caché qui n’apparaît que de temps en temps), mais ça risque de faire un peu trop. Par contre pour le bistro ça peut être bien je pense. Est-ce qu'il existe un moyen technique de faire exécuter du javascript seulement sur le bistro, sans modifier le common.js? Merci par avance :-) --Lrq3000 (discuter) 23 mars 2018 à 03:10 (CET)

J'ai pensé à une alternative qui ne requiert pas d'insertion JS donc plus besoin de ma question précédente :-)  Arkanosis : Merci pour les suggestions, j'ai rajouté un lien pendant l'animation (sinon il y a aussi deux liens après l'animation: un sous le titre et un tout en bas dans les footers), et pour le innerHTML j'ai réduit son usage au maximum, mais je l'ai gardé pour l'animation de la bannière car sinon cela complexifie beaucoup le code et le rend inflexible (car il y a des balises html à des endroits spécifiques, comme pour le blink et pour le formattage correct de la bannière en ASCII Art). Dans tous les cas j'ai vérifié niveau sécurité, tout ce qui rentre dans innerHTML sont des constantes définies dans le code, il n'y a pas de user input. Merci! :-D --Lrq3000 (discuter) 26 mars 2018 à 00:33 (CEST)

Lrq3000: Félicitations pour les changements !

J'ai encore deux problèmes à signaler (qui ont été introduits récemment) :

• le curseur cesse bien de clignoter lorsqu'on presse echap, mais le poisson qui est désormais animé continue de bouger (cf. WCAG 2.0, 2.2.2);
• l'easter egg ouvre un site tiers (ok, ça nécessite une intervention de l'utilisateur, passons), mais surtout, il donne le contrôle de la fenêtre courante au site tiers via l'objet window.opener. Il faut remplacer window.open(url, '_blank'); par window.open(url, '_blank', 'noopener'); (cf. « the most underestimated vulnerability ever »).

Merci encore. Amicalement — Arkanosis ^✉ 29 mars 2018 à 12:52 (CEST)

Merci BEAUCOUP Arkanosis, je vais implémenter tout ça un peu plus tard et je reposterai un message! :-D --Lrq3000 (discuter) 29 mars 2018 à 15:53 (CEST)

 Arkanosis :Merci beaucoup pour les suggestions et les références! Je les ai toutes implémentées avec l'aide de GratusFR :-) Pour le easter egg, oui on m'a proposé l'idée et j'ai trouvé que c'était bien de cette façon car il faut vraiment le vouloir pour l'activer, c'est quasi impossible par hasard. Pour l'ouverture dans une autre page, c'est pour éviter tout risque d'attaque XSS sur les credentials WP de l'utilisateur, et avec les corrections suggérées c'est encore mieux :-D Merci encore et n'hésites pas si tu as d'autres suggestions! --Lrq3000 (discuter) 29 mars 2018 à 21:15 (CEST)

Chargement dynamique de gadgets à partir d'un paramètre de l'URL

Vous pouvez donner un avis sur cette DIMS : Wikipédia:Demande d'intervention sur un message système#MediaWiki:Common.js – prise en charge des paramètres withJS & withCSS. Orlodrim (discuter) 2 avril 2018 à 12:34 (CEST)

Pages de configuration JSON de l’espace utilisateur protégées, comme pour les JS/CSS

Les sous-pages utilisateur dont le nom se termine par .json vont être protégées de la modification par d’autres personnes, comme c’est déjà le cas pour les pages .js et .css. Si vous possédez un outil qui stocke de la configuration statique, vous pouvez maintenant utiliser une sous-page comme User:Example/mygadget.json pour le faire. [2]

Copié depuis les Technews. C'est une bonne nouvelle, qui servira sûrement pour la configuration propre de gadgets. --Framawiki ^✉ 3 avril 2018 à 19:03 (CEST)

Note au passage : Pour rebondir sur ce que dit @Framawiki, pour la configuration propre de gadgets, il est possible (et c'est encore plus propre àmha) de stocker ça dans ses préférences, via Special:ApiHelp/options avec le préfixe userjs-. — 0x010C ^~discuter~ 8 avril 2018 à 23:15 (CEST)

Pour rebondir sur cette note, pour ma part a priori pas fan du tout de l'enregistrement dans les préférences. Parce que trop difficile d'accès (aucun accès direct, faut passer par du javascript) si on veut les lire, en faire le point, etc. od†n ↗^blah 29 avril 2018 à 00:34 (CEST)

Proposition de délistage du gadget BugStatusUpdate

Bonjour, en regardant un peu le gadget BugStatusUpdate (qui s'applique au modèle {{phab}}), j'ai remarqué qu'en raison de différents bugs, apparemment il n'a en fait jamais fonctionné sur ce wiki… Et ce sans que personne ne le signale depuis des années.

En prime, le tool wmflabs qu'il utilise (appel API) ne semble plus fonctionner à ce jour…

Au vu de tout cela, j'ai bien envie de délister ce gadget des préférences, histoire d'alléger un peu celles-ci. Qu'en pensez-vous ?

od†n ↗^blah 29 avril 2018 à 00:30 (CEST)

Plutôt pour : mieux vaut l'absence de gadget qu'un gadget non fonctionnel. Il n'est "utilisé" que par 40 contributeurs actifs de toute façon. — Zebulon84 (discuter) 29 avril 2018 à 00:59 (CEST)

Je suis aussi de cet avis, il ne sert à rien de conserver un script non fonctionnel dans un endroit aussi visité que les préférences.— Gratus (discuter) 29 avril 2018 à 17:19 (CEST)

Merci pour vos confirmations, je vais donc délister le gadget (edit : fait). À noter aussi que je viens de passer quelques heures à retravailler le script, comme ça il est prêt si jamais l'API réapparait plus tard, et que des utilisateurs veulent utiliser le script via import manuel dans leur javascript perso. od†n ↗^blah 29 avril 2018 à 22:29 (CEST)

Proposition de suppression du code de compte à rebours

Bonjour,

Toujours en vue d'alléger le javascript, je pense à supprimer la fonction Rebours du Common.js, utilisée par le modèle {{Compte à rebours}}. Le but est d'avoir un Common.js plus agréable à maintenir, et d'économiser quelques centaines d'octets sur le javascript minifié envoyé à tout le monde.

Liste des utilisations grâce à wstat. Vous constaterez qu'il n'y a presque pas de compteurs à jour, et de ce que j'ai survolé, il n'y a pas vraiment d'utilisation très utile…

Vos avis ? od†n ↗^blah 8 mai 2018 à 08:21 (CEST)

+1 complètement pour, d'autant qu'avec les modules de nos jours, on peut en faire une version statique assez simplement (ou pas en fait, et laisser ce modèle hanter les historiques de WP). — 0x010C ^~discuter~ 13 mai 2018 à 16:49 (CEST)

Je n'ai vu que deux utilisations

• une BU (pour indiquer le temps d'ici la fin de l'année) utilisée sur la page d'un seul utilisateur actif, et encore dans une boite déroulante au milieu de dizaines d'autre BU,
• Pour indiquer le temps d'ici la fermeture des bureaux de vote de la prochaine élection municipale de Grenoble.

→ cela ne me semble effectivement pas indispensable, un affichage statique étant largement suffisant dans ces deux cas. — Zebulon84 (discuter) 13 mai 2018 à 17:38 (CEST)

Merci pour vos confirmations, « y'a plus qu'à » réaliser la suppression de tout cela.

• 0x010C : on aurait pu effectivement transformer en module (comme j'ai fait pour CadreOnglets dans le Common.js), mais je suis franchement d'avis à carrément supprimer le truc pour gagner en simplicité
• Zebulon84 : j'ai été enculer de rire avec le 2^e point de ta liste

od†n ↗^blah 14 mai 2018 à 15:54 (CEST)

Je viens d'effectuer la suppression (allègement Common.js, obsolescence modèle). Finalement assez simple puisque je n'ai pas touché aux pages utilisateur ; je laisse ceux qui le veulent mettre à jour leurs pages, de la façon qu'ils souhaitent. od†n ↗^blah 1 septembre 2018 à 14:46 (CEST)

Tant qu'on y est

Ola!

En cherchant dans le Common.js de quoi parlait @Od1n dans la section précédente, j'ai dérapé et suis tombé sur la fonction LastModCopy. Elle sert à indiquer la date de dernière modification d'un article, dans des bandeaux comme {{Événement en cours}}. Sauf que c'est possible de faire ça directement avec des parser functions (ce que j'ai fait là et là), fait que ce reliquat de 2009 me semble assez inutile de nos jours.

On vire cette fonction ?

— 0x010C ^~discuter~ 14 mai 2018 à 10:11 (CEST)

Le problème est qu'avec cette génération côté serveur, les données peuvent ne pas être mises à jour, pendant plusieurs jours. Cela se voit notamment avec les liens de type "bistro du jour" qui peuvent envoyer sur un bistro datant d'il y a plusieurs jours… od†n ↗^blah 14 mai 2018 à 16:05 (CEST)

Si je ne me trompe pas tous les liens de ce type sont mis à jour lorsque la page est enregistrée. Le problème se pose lorsque la page elle-même n'est pas modifiée alors que la donnée change (nombre de pages dans un catégorie, date ou heure courante...). Mais il me semble que cela ne devrait pas posé problème pour la dernière édition de la page sur laquelle est le bandeau, puisque par définition la page a été enregistrée à ce moment là. — Zebulon84 (discuter) 14 mai 2018 à 16:55 (CEST)

Conflit d’édition — @Od1n Hum, arrête moi si je me trompe, mais sur WP:LB, le problème est la mise en cache de la page qui ne reflète pas/plus ce que devrait être la page, je ne crois pas qu'il n'y ai ce problème ici. Je m'explique : une page a le bandeau en question. J'arrive, je la modifie, j'enregistre. À ce moment là, le fait d'enregistrer une nouvelle version force la réinterprétation de tout le wikicode (y compris la transclusion du bandeau, dont {{REVISIONTIMESTAMP}}) et le rafraîchissement immédiat de tous les caches (afin que les visiteurs puissent lire les modifications). Ça fait que la date et l'heure seront forcément à jour, non ? — 0x010C ^~discuter~ 14 mai 2018 à 17:02 (CEST)

Effectivement, je n'avais pas pensé à cela, comme la page contenant le modèle est aussi celle qui est modifiée, ça devrait a priori être forcément à jour. Du coup, je me demande pourquoi cela a été fait en javascript au départ ? od†n ↗^blah 14 mai 2018 à 18:13 (CEST)

Je suppose que c'était par simple méconnaissance de cette solution, ou alors la solution javascript avait été considérée (à tort) comme plus simple. La seule différence est que le texte est toujours en français, et non dans la langue de l'interface choisie par l'utilisateur, mais cela convient très bien étant donné que le reste du contenu est en français. J'ajoute mon feu vert pour ce nettoyage. Chercher « insource:lastmodcopy », il n'y a pas grand chose. Peut-être factoriser la nouvelle ligne dans un modèle ? od†n ↗^blah 15 mai 2018 à 06:10 (CEST)

sauf les pages de discussion et les archives, j'ai viré toutes les balises qui se servaient de cette fonction, remplacé par {{Dernière modification}} fraichement créé. Et j'ai viré dans la foulée la-dite fonction du Common.js et du Mobile.js. — 0x010C ^~discuter~ 16 mai 2018 à 01:19 (CEST)

Te gêne pas pour modifier les archives et pdds, ce sont des modifs techniques et non éditoriales. Toujours mieux que de se les traîner indéfiniment dans les jambes, à compliquer de plus en plus les maintenances en pourrissant les résultats de recherches… od†n ↗^blah 16 mai 2018 à 03:54 (CEST)

Pour info, j'ai mis à jour ces quelques inclusions restantes. Ça devrait être tout bon maintenant. od†n ↗^blah 17 mai 2018 à 13:23 (CEST)

Update Gadget-ExternalSearch.js

Le Gadget ExternalSearch.js est updated: Utilisateur:Mah3110/Gadget-ExternalSearch.js

Actions: Jqueryfication + Ajout du moteur Qwant + ouverture dans un nouvel onglet pour les searchs.

0x010C, tu peux vérifier et pousser en prod si ok.

N'hésitez pas à me faire vos retours Merci --Mah3110 (discuter) 16 mai 2018 à 12:51 (CEST)

Je vous ai préparé le terrain, notamment pour faciliter les comparaisons, et ça m'a l'air d'avoir déjà bonne allure. Cela aura aussi été l'occasion de repérer quelques erreurs dans le code actuellement en prod. od†n ↗^blah 19 mai 2018 à 23:34 (CEST)

Salut @Mah3110, il reste un bug qui traîne: je commence je fais une recherche avec google, ok, mais je veux faire la même recherche avec un autre moteur, par exemple Qwant, ça m'ouvre alors et Qwant et Google, pareil pour une 3ème ou 4ème requête. Je te laisse chercher d'où ça peut bien venir — 0x010C ^~discuter~ 27 mai 2018 à 20:11 (CEST)

Je viens justement de passer le code en prod… J'allais faire une relance pour avoir des relectures, le gadget étant quand même activé par défaut chez tout le monde.

@0x010C tu es arrivé à point nommé, je viens de corriger ce bug, sans ton signalement il serait probablement resté un certain temps… Merci !!

On devrait probablement pouvoir faire plus propre, en attachant un seul listener une bonne fois pour toutes sur le form.

od†n ↗^blah 27 mai 2018 à 20:30 (CEST)

Top! Merci od†n

je regarde pour le listener si tu veux!

--Mah3110 (discuter) 27 mai 2018 à 20:43 (CEST)

Je viens de traiter cela : 149010554. od†n ↗^blah 29 mai 2018 à 15:51 (CEST)

Rock your sidebox, présentation et appel à l'aide

Je développe le script Utilisateur:PAC2/rockyoursidebox.js qui permet d'ajouter des liens et des informations "utiles" (ie selon moi) directement dans les barres latérales de l'interface Timeless. En gros, j'ajoute une boîte article (Utilisateur:PAC2/articlebox.js) et une boîte contributeur (Utilisateur:PAC2/userbox.js).

Dans la boîte article, je mets un lien vers Reasonator, un lien vers Xtools, un lien vers Pageviews, des recherches préfaites vers Commons, Google, Wikipedia, Scholar, Qwant, etc, et des informations sur l'article (nombre de mots, nombre de références, etc) issues de l'API xtools.

J'aimerais bien ajouter aussi dans cette interface le nombre de pages liées à partir de l'API wikipedia. Je n'arrive pas à appeler l'API wikipédia :

Le code ci-dessous ne fonctionne pas :

var whatlinkshere = new XMLHttpRequest();
whatlinkshere.open("GET", "https://fr.wikipedia.org/w/api.php?action=query&prop=linkshere&titles=Notebook&format=json", false) ;
whatlinkshere.send();

Quelqu'un a t il une solution ?

Par ailleurs, si vous êtes intéressés par le projet Rock your sidebox, n'hésitez pas à me faire signe. Je serai heureux de collaborer, voir comment on peut en faire un gadget, améliorer le code, le rendre compatible avec Vector, etc.

--PAC2 (discuter) 23 mai 2018 à 08:11 (CEST)

Salut @PAC2,

Quelques premières remarques en vrac en parcourant le code rapidement :

• tu as un « http://commons.wikimedia.org/ » qui traîne ligne 70 de articlebox.js ;
• tes requêtes AJAX sont faites de manière synchrone (le troisième paramètre de open mis à false), c'est absolument à proscrire car tu vas bloquer l’exécution de tous les autres scripts qui suivent en attendant la réponse (et vu que tu n'as pas de timeout, il suffit que Xtools soit en panne pour que ton script ce bloque complètement) ; de manière générale, pour tes requêtes AJAX, préfère :
  • $.get(...) pour les requêtes vers des sites externes;
  • mw.Api() pour les requêtes vers Wikipédia (ou mw.ForeignApi pour les requêtes vers les autres wikis);

Par exemple, ta requête si-dessus s'écrit :

var api = new mw.Api();
api.get( {
    action: 'query',
    prop: 'linkshere',
    titles: 'Notebook',
    format: 'json',
    formatversion: 2
} ).then( function( data ) {
    var nbLinks = data.query.pages[ 0 ].linkshere.length;
    // ...
} );

Cordialement — 0x010C ^~discuter~ 27 mai 2018 à 21:26 (CEST)

Merci beaucoup  0x010C :. C'est plus clair pour moi et ça marche !!

Du coup, j'essaie d'utiliser 'mw.ForeignApi()' mais je comprends pas trop comment former ma requête pour l'API xtools.

var prose_api = new mw.ForeignApi( 'https://xtools.wmflabs.org/api/page/prose/fr.wikipedia.org/' +  + mw.config.get( 'wgPageName' ) );
prose_api.get( {
    action: 'query',
    } ).done( function ( data ) {
    var uniquereferences = data.unique_references ;
    console.log(uniquereferences) ;
    mw.util.addPortletLink( 
       portletID = 'p-articlebox', 
       href = "https://xtools.wmflabs.org/api/page/prose/", 
      text = uniquereferences + ' références uniques' , 
      id = 'p-unique-references' );
    } );

--PAC2 (discuter) 30 mai 2018 à 08:38 (CEST)

@PAC2 cf mon message ci-dessus. mw.ForeignApi permet de faire des requêtes sur un autre wiki (n'importe quel site utilisant MediaWiki pour être précis), ce que Xtools n'est pas. Pour cela, utilise $.get(...).

Cordialement — 0x010C ^~discuter~ 4 juin 2018 à 15:27 (CEST)

Gadget-Evaluation.js

Bonjour, depuis quelques semaines je n'arrive plus à évaluer les articles via le gadget d'évaluation. Dois-je mettre à jour un script sur une de mes sous pages ? Le gadget est bien activé dans mes préférences ; le menu déroulant "plus" --> "évaluer" est accessible et je peux cocher les cases que je souhaite mais c'est au moment de valider via le bouton "exporter cette évaluation vers la page de discussion" que rien ne se passe. D'avance merci. Mats01 (discuter) 15 juillet 2018 à 08:00 (CEST)

Ça devrait être réparé. Un grand merci pour ce signalement. od†n ↗^blah 15 juillet 2018 à 08:53 (CEST)

En effet, cela refonctionne. Merci à toi. Mats01 (discuter) 15 juillet 2018 à 13:07 (CEST)

Evolution de MediaWiki:Gadget-DotsSyntaxHighlighter.js

Bonjour, malgré plusieurs demandes à l’auteur de ce gadget, il refuse de le modifier pour gérer proprement la nouvelle syntaxe autorisée pour les balises <br>, <hr>… par la norme HTML5. J'ai fait ma propre version de ce gadget ici avec des modifications simples. Elle n'est pas minifiée comme l'original, mais si certains d'entre vous veulent la tester, je ne serais pas contre quelques retours. Quelle serait la procédure à suivre si je voulais demander que le gadget que l'on utilise sur frwiki dans les préférences soit remplacé par cette version ? --NicoV (discuter) 27 juillet 2018 à 13:02 (CEST)

Bonjour NicoV

Il n'y a pas vraiment de procédure établie. Le diff que tu mets en avant ne m'inquiète pas outre mesure ; si tu es confiant de la stabilité de ta version du script, je t'invite à écraser MediaWiki:Gadget-DotsSyntaxHighlighter.js avec (ce qu'on perd du fait de la non-minification, on le gagne largement en évitant la requête HTTP associée au chargement du script distant).

PS : si tes droits d'admin ne suffisent plus pour effectuer cette modification, tu peux demander les droits d'administrateur technique sur le WP:BB ou transmettre ta demande à l'un des administrateurs techniques actuels.

Amicalement — Arkanosis ^✉ 21 août 2018 à 14:16 (CEST)

Mise en page personnelles

Bonjour à tous, je suis hélas en conflit sur Wikiversité avec Jean-Louis Tripon (d · c · b) qui cherche à obtenir ceci comme rendu dans les textes qui réalise sur Wikiversité ;

     Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed non risus. Suspendisse lectus tortor, dignissim sit amet, adipiscing nec, ultricies sed, dolor. Cras elementum ultrices diam. Maecenas ligula massa, varius a, semper congue, euismod non, mi. Proin porttitor, orci nec nonummy molestie, enim est eleifend mi, non fermentum diam nisl sit amet erat. Duis semper. Duis arcu massa, scelerisque vitae, consequat in, pretium a, enim. Pellentesque congue. Ut in risus volutpat libero pharetra tempor. Cras vestibulum bibendum augue. Praesent egestas leo in pede. Praesent blandit odio eu enim. Pellentesque sed dui ut augue blandit sodales. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Aliquam nibh. Mauris ac mauris sed pede pellentesque fermentum. Maecenas adipiscing ante non diam sodales hendrerit.
    Ut velit mauris, egestas sed, gravida nec, ornare ut, mi. Aenean ut orci vel massa suscipit pulvinar. Nulla sollicitudin. Fusce varius, ligula non tempus aliquam, nunc turpis ullamcorper nibh, in tempus sapien eros vitae ligula. Pellentesque rhoncus nunc et augue. Integer id felis. Curabitur aliquet pellentesque diam. Integer quis metus vitae elit lobortis egestas. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi vel erat non mauris convallis vehicula. Nulla et sapien. Integer tortor tellus, aliquam faucibus, convallis id, congue eu, quam. Mauris ullamcorper felis vitae erat. Proin feugiat, augue non elementum posuere, metus purus iaculis lectus, et tristique ligula justo vitae magna.

plutôt que la mise en page normal ;

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed non risus. Suspendisse lectus tortor, dignissim sit amet, adipiscing nec, ultricies sed, dolor. Cras elementum ultrices diam. Maecenas ligula massa, varius a, semper congue, euismod non, mi. Proin porttitor, orci nec nonummy molestie, enim est eleifend mi, non fermentum diam nisl sit amet erat. Duis semper. Duis arcu massa, scelerisque vitae, consequat in, pretium a, enim. Pellentesque congue. Ut in risus volutpat libero pharetra tempor. Cras vestibulum bibendum augue. Praesent egestas leo in pede. Praesent blandit odio eu enim. Pellentesque sed dui ut augue blandit sodales. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Aliquam nibh. Mauris ac mauris sed pede pellentesque fermentum. Maecenas adipiscing ante non diam sodales hendrerit.

Ut velit mauris, egestas sed, gravida nec, ornare ut, mi. Aenean ut orci vel massa suscipit pulvinar. Nulla sollicitudin. Fusce varius, ligula non tempus aliquam, nunc turpis ullamcorper nibh, in tempus sapien eros vitae ligula. Pellentesque rhoncus nunc et augue. Integer id felis. Curabitur aliquet pellentesque diam. Integer quis metus vitae elit lobortis egestas. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi vel erat non mauris convallis vehicula. Nulla et sapien. Integer tortor tellus, aliquam faucibus, convallis id, congue eu, quam. Mauris ullamcorper felis vitae erat. Proin feugiat, augue non elementum posuere, metus purus iaculis lectus, et tristique ligula justo vitae magna.

Et donc, quel serait le code qui faudrait mettre dans ces gadgets personnelles pour avoir le résultat qu'il veut. Merci beaucoup pour votre aide, amicalement. FrankyLeRoutier % Appelez-moi sur mon CB 8 août 2018 à 05:27 (CEST)

La présentation de mes textes permise par Wikiversité, meilleure car plus lisible que celle que tu désires imposer, est destinée à tous et non seulement à toi-même, donc je n'accepterai jamais un gadget qui imposerait aux autres ta présentation laide et absurde, tout en m'évitant de la voir. Cesse de vandaliser mes textes, et demande plutôt de l'aide pour voir la présentation des autres telle que tu la désires sans saccager leurs textes, mets des lunettes.--Jean-Louis Tripon (discuter) 8 août 2018 à 06:41 (CEST)

Je ne pense pas que remplacer les balises "<p>" par "<pre>\t" en JS (ou de surcharger ce style en CSS), ou vice-versa, soit la solution miracle de ce conflit. En effet, il ne s'agit pas de le faire pour une personne dans un des articles Wikipédia, mais dans tous les cours Wikiversité d'un seul auteur pour tout le monde. JackPotte ($♠) 8 août 2018 à 07:39 (CEST)

DeluxeHistory et nouvelle liste de suivi

Lorsque la nouvelle liste de suivi est rafraichie après avoir cliqué sur un bouton (marquer tout comme vu, changement de durée...) les couleurs disparaissent.

J'ai essayé de remplacer $(function ($) par mw.hook().add, mais quel que soit l'event que je choisis parmi ceux qui me semblent potentiellement applicable sur la doc (wikipage.content, structuredChangeFilters.ui.initialized, wikipage.collapsibleContent), pas d'amélioration.

• Savez-vous voir quel évènement mw.hook est activé pour une action particulière ?
• Savez-vous lequel utilisé ici ?
• Avez-vous une autre solution ?
• Si non, faut-il demander sur phabricator l'ajout de l'un de ces évènements ?

— Zebulon84 (discuter) 31 août 2018 à 13:00 (CEST)

En cherchant "watchlist" sur mw:Manual:Hooks, je suis arrivé sur BeforeWatchlist (supprimé), puis sur SpecialWatchlistFilters (déprécié), SpecialWatchlistQuery (déprécié), et enfin, les bons… ChangesListSpecialPageStructuredFilters et/ou ChangesListSpecialPageQuery. Bon courage ! od†n ↗^blah 1 septembre 2018 à 03:48 (CEST)

Et oui, ce sont les hooks PHP, mais ça peut éventuellement servir de piste pour trouver les hooks JavaScript. od†n ↗^blah 1 septembre 2018 à 03:50 (CEST)

Et en général pour ce genre d'investigation, je fais des recherches sur le miroir GitHub de MediaWiki. Exemple en l'occurrence. Et si la recherche GitHub est trop floue, recherches sur une copie locale du repository MediaWiki. od†n ↗^blah 1 septembre 2018 à 03:58 (CEST)

Mmmmm, dans le code pour les RC "améliorées" ils rajoutent un "hook('wikipage.content').fire()" (là ou encore là), et le code pour la watchlist "améliorée" (ce qui à propos est très discutable) est basé sur le code pour les RC. Mon intuition me dit qu'ils ont oublié de rajouter ce hook (qu'en plus tu as déjà essayé de "listener") pour la watchlist. À confirmer, mais ça me semble assez probable. od†n ↗^blah 1 septembre 2018 à 04:28 (CEST)

 Od1n : Merci de t'être penché sur le sujet. Avec tes hook php, je n'ai pas de couleur du tout, donc il ne sont pas actif en JS, ou alors pas exactement sous ce nom...

Je ne trouve d'ailleurs pas le terme « hook » sur watchlist.js (mais ce code me parait bien court, je ne sais pas si c'est celui de la nouvelle watchlist).

Je vais sans doute faire une demande sur phab demain, mais je doute que ce sois traité rapidement. — Zebulon84 (discuter) 1 septembre 2018 à 05:06 (CEST)

Tu es sûr que le hook wikipage.content ne fonctionne pas ? J'ai essayé ceci : mw.hook('wikipage.content').add(function () { console.log('TEST ' + Date.now()); }); et les messages s'affichent bien. En fait même, ça affiche non pas un message, mais deux… Qu'est-ce que c'est encore que ça. od†n ↗^blah 1 septembre 2018 à 13:00 (CEST)

Effectivement. Bon il faut que je me plonge un peu plus dans le code du gadget pour comprendre pourquoi il ne s'exécute qu'une fois, je n'avais pas pensé à ça. — Zebulon84 (discuter) 1 septembre 2018 à 14:26 (CEST)

Trouvé, ça marche. — Zebulon84 (discuter) 1 septembre 2018 à 14:33 (CEST)

 Od1n : puisque tu maitrise bien mieux que moi l'ordre de lancement des script, et que tu as largement contribué à ce gadget, j'ai quelques questions :

• Si j'écrit

  $(function ($) {
      // code divers ...
      function run() { 
          // code
      }
      mw.hook( 'wikipage.content' ).add(run);
   }
  

  Cela marche pour moi, mais est-ce que je suis sur que run sera exécuté lorsque la page sera chargé, ou est-ce que le hook wikipage.content initial peut-être déjà échu lorsque l'exécution du script arrive là dans certainnes configuration, puisque la fonction n'est ajouté au hook qu'après que la page soit chargée ?
• Le code

  if (!mw.user.options.get('gadget-DeluxeHistory')) {
      mw.loader.load('/w/index.php?title=MediaWiki:Gadget-DeluxeHistory.css&action=raw&ctype=text/css', 'text/css');
  }
  

  s'exécute lorsque je lance le script depuis mon common.js et écrase mon CSS perso, mais ne semble pas s'exécuter lorque j'active le gadget dans mes préférences, et c'est mon common.css qui est utilisé (chargé après le DeluxeHistory.css déclaré dans Gadgets-definition). Pourquoi et à quel moment est définit cette user.option 'gadget-DeluxeHistory' ?

— Zebulon84 (discuter) 1 septembre 2018 à 17:15 (CEST)

• Comme pour les promises, un hook est bien déclenché une fois même s'il a été enregistré après. Cf. docblock mw.hook : « This means if an event is fired, and a handler added afterwards, the added function will be fired right away with the last given event data. »
• Tu as dû mal comprendre la raison d'être de ces lignes (effectivement pas des plus évidentes), ce n'est pas pour de la personnalisation, mais seulement pour le chargement du CSS de base. Il y a deux modes de chargement de ce gadget :
  • en cochant le gadget dans les préférences, auquel cas le CSS est chargé via la définition ; le gadget étant coché, la user option est true, et le test fait que le CSS n'est pas chargé une deuxième fois par le JavaScript
  • via un obtenir(), auquel cas la user option est false, et c'est le JavaScript qui s'occupe de charger le CSS

od†n ↗^blah 1 septembre 2018 à 17:45 (CEST)

Merci, c'est très clair. J'ai bien compris l'utilité des lignes, mais n'avais pas compris que 'gadget-DeluxeHistory' est simplement d'indication que le gadget est activé (ou plutôt j'ai oublié, car maintenant je suis sur d'avoir déjà vu ça, et m'être déjà posé la question d'où ça vient). — Zebulon84 (discuter) 1 septembre 2018 à 18:07 (CEST)

Désactivation par défaut de ExternalSearch

Bonjour, le gadget ExternalSearch est actuellement activé par défaut pour tous les utilisateurs. Pour rappel, il s'agit des liens "Bing", "Google", etc. en dessous de la zone d'entrée sur Spécial:Recherche. Remarque importante : les liens ne servent pas à chercher sur ces autres sites, mais à chercher sur Wikipédia en utilisant les moteurs de recherche de ces sites.

Je propose de retirer cette activation par défaut. Effectivement, c'est un code qui remonte à plus de dix ans (9447902, 31573257), et depuis lors, la recherche interne sur Wikipédia s'est vue très grandement améliorée, notamment avec l'extension CirrusSearch.

Certains pourraient être tentés de dire « on pourrait modifier ces liens pour qu'ils servent à faire des recherches "classiques" sur Bing, Google, etc. », sauf que non. D'abord, Wikipédia n'a aucunement le rôle de "portail servant à faire des recherches sur des sites tiers", et d'autre part ça serait vraiment alambiquité : quand un internaute veut chercher un truc sur Google, il va sur Google, sur Wikipédia, il va sur Wikipédia, etc. Aller sur Google et y faire une recherche uniquement sur Wikipédia, c'est un truc de geek ça !

od†n ↗^blah 2 septembre 2018 à 15:25 (CEST)

Je suis pour le retrait de ce truc (cela fait déjà longtemps que je l'ai désactivé ce gagdet, je m'en servais jamais).

CirrusSearch a révolutionné la recherche interne (même si ce ne serait jamais parfait), avec sa tolérance bien plus grande aux erreurs (tolère 2 fautes, réglage par défaut, modifiable dans les préférences), et son insensibilité aux diacritiques (très pratique aussi) font que l'usage d'un moteur externe pour une recherche interne ne se justifie plus pour moi.

--Tractopelle-jaune (discuter) 2 septembre 2018 à 21:16 (CEST)

Merci pour ton avis, et il me faudrait quelques approbations supplémentaires pour pouvoir effectuer la désactivation sereinement. od†n ↗^blah 3 septembre 2018 à 20:03 (CEST)

Bonjour

Entièrement de ton avis, od†n : l'époque où le moteur de recherche interne était inutilisable fait partie du passé (je n'en reste pas moins convaincu qu'utiliser NOINDEX sur certaines pages comme les PU est une erreur, mais c'est un tout autre sujet). Et en 2018, le moteur de recherche préféré de l'internaute est de toutes façon accessible dans son navigateur, où il a tout loisir de choisir quelles alternatives s'offrent à lui.

Amicalement — Arkanosis ^✉ 4 septembre 2018 à 12:06 (CEST)

Je suis d'accord avec ces arguments. Orlodrim (discuter) 5 septembre 2018 à 19:01 (CEST)

Je viens de retirer cette activation par défaut. od†n ↗^blah 7 septembre 2018 à 23:37 (CEST)

Délistage ContribsRange

Bonjour, petite relance pour avoir vos avis sur le délistage de ContribsRange (code) afin d'alléger les préférences. Voir la discussion précédente. od†n ↗^blah 3 septembre 2018 à 19:59 (CEST)

 Od1n : Bof, autant je suis pour virer des trucs obsolètes, qui ne servent plus à rien. Autant je ne suis pas convaincu que de vouloir épurer la liste des gadgets de tout ce qui n'est pas massivement utilisé soit vraiment le mieux.

Je m'explique : La liste des gadgets (dans les préférences) est là pour justement indiquer différents gadgets qui pourraient êtres utiles selon son type de contributions, et ses habitudes.

Je t'avoue que, à part alléger la liste des gadgets des préférences, j'ai de la peine à saisir l’intérêt de vouloir la cantonner aux seuls gadgets les plus utilisés.

Après-tout, si une telle liste existe, c'est bien pour répondre à différentes attentes et besoins des contributeurs, et aussi leur suggérer des fonctionnalités qui pourraient leur êtres utiles.

Quand je vois que pour des gadgets aussi utiles et sans équivalence que Utilisateur:Orlodrim/contribs-relecture.js et Utilisateur:Orlodrim/hist-relecture.js (tous deux d'Orlodrim) ne sont utilisés que par respectivement 33 et 16 contributeurs (y compris les utilisateurs inactifs). J'ai de gros doutes sur le fait que de se dire que Projet:JavaScript/Liste des fonctions disponibles soit suffisant pour les utilisateurs expérimentés, et que la liste des gadgets des préfs ne devraient contenir que les gadgets les plus utilisés.

Il me semble d'ailleurs que comparé à la liste des gadgets d'enwiki, la longueur de la liste chez nous n'est pas particulièrement problématique.

Après, il est clair que je comprend aussi la position d'Od1n, qui fait partie des 2-3 seuls admins maintenant le javascript (autre que celui de leurs propres scripts) de toute la Wikipédia en français (et c'est le plus actif).

Donc, bien que je comprenne ta motivation Od1n, qui est de limiter le javascript à maintenir d'une part, et d'autre part ta volonté d'alléger les préfs en transférant tout ce qui est un peu technique et un peu moins utilisé vers Projet:JavaScript/Liste des fonctions disponibles, mais je ne suis pas convaincu que cette solution soit la meilleure, au vu de la grande confidentialité de cette liste (moi-même, j'ai longtemps ignoré son existence).

Pour moi, la liste des gadgets des préfs sert justement à lister des gadgets, il ne s'agit pas de tout lister (une minorité d'entre-eux seulement), mais au moins les fonctionnalités sans équivalence par un autre gadget listé, et apportant une véritable utilité.

D'après Spécial:GadgetUsage, le gadget ContribsRange est quand même utilisé par 781 contributeurs, dont 83 actifs dernièrement (et ce alors que son utilité parait effectivement moindre par rapport à des gadgets comme contribs-relecture.js et hist-relecture.js).

Il faut noter aussi que presque toutes les grandes wikipédias ont un gadget similaire à ContribsRange disponible dans les préfs. Tout le monde (moi le premier) n'est pas à l'aise dans le calcul des plages CIDR (c'est pas intuitif comme calcul pour un non-habitué), et pouvoir utiliser l'astérisque à la place est très pratique.

Après si d'autres contributeurs sont aussi d'avis qu'il vaut mieux délister ce gagdet, je ne m'y opposerai pas, et me rangerai à cet avis.

--Tractopelle-jaune (discuter) 4 septembre 2018 à 10:10 (CEST)

Je comprends ton avis, ceci étant, je ne le partage pas

Quelques points en vrac :

• Mes préoccupations ne portent pas sur la quantité de scripts à maintenir (pour moi ils sont à maintenir, qu'ils soient listés ou non), mais simplement sur la clarté de la page de préférences.
• Les chiffres d'utilisations sont impressionnants, et dépendent très grandement de l'ancienneté du gadget dans les préférences. J'en suppose que les utilisateurs ont tendance à cocher des trucs pour tester, mais à ne pas décocher derrière en cas de non utilisation.
• Ne pas se baser sur le wiki anglophone, ils ne font pas forcément les choses mieux.

od†n ↗^blah 5 septembre 2018 à 01:21 (CEST)

 Od1n : Bon alors je me range à ton avis, va pour moi pour le délistage .

Par contre, je trouve quand même dommage la confidentialité de la liste Projet:JavaScript/Liste des fonctions disponibles.

Est-ce que l'on pourrait pas alors envisager d'ajouter dans le message système MediaWiki:Gadgets-prefstext (affiché au début de la liste des gadgets dans les préfs) une ligne du genre :

• « D'autres gadgets et outils sont disponibles sur la page Projet:JavaScript/Liste des fonctions disponibles. »

ou

• « D'autres gadgets et outils sont disponibles sur la liste des fonctions disponibles du projet JavaScript. »

Comme ça, cela indiquerait aussi l'existence de cette liste depuis les préférences, cela pourrait être pas mal, qu'en pense tu ?

En tout cas merci pour tout ce que tu fait, j'essaie aussi de faire de la maintenance, même si pour moi c'est plus sur les palette de navigation et certains modèles, et quelques corrections syntaxiques.

--Tractopelle-jaune (discuter) 5 septembre 2018 à 05:49 (CEST)

Oui, la page Projet:JavaScript/Liste des fonctions disponibles semble manquer de visibilité. On pourrait ajouter un lien comme tu le suggères, et remanier un peu Aide:Personnaliser l'interface (actuellement la moitié de la page ce sont des exemples, cette page gagnerait à être plus synthétique, utile à la navigation vers des pages plus ciblées). od†n ↗^blah 5 septembre 2018 à 14:58 (CEST)

Ça me semble raisonnable de ne pas garder le gadget si c'est géré nativement, même si ce n'est pas exactement équivalent. Mais vu la différence de notation, ce serait bien de donner des explications sur WP:BA et WP:BULPAT. Orlodrim (discuter) 5 septembre 2018 à 19:07 (CEST)

Pour information, le code pour JavaScript utilisateur, permettant de charger le gadget s'il venait à être délisté des préférences :

if (mw.config.get('wgCanonicalSpecialPageName') === 'Contributions') {
    obtenir('contribsrange');
}

od†n ↗^blah 8 septembre 2018 à 02:50 (CEST)

À la réflexion, ce gadget n'étant peut-être pas le plus inutile de tous, va pour le laisser dans la liste pour l'instant. od†n ↗^blah 9 septembre 2018 à 05:22 (CEST)

BandeauxEbauches: lien d'activation n'ayant aucun effet

Bonsoir, Bastenbas (d · c · b) et moi rencontrons un problème avec l gadget BandeauxEbauches. Tout fonctionne normalement lorsqu'un bandeau d'ébauche est déjà présente dans la page. Lors-qu’aucun n'est trouvée, il ajoute un lien dans le portlet (le menu en haut à droite berceau de l'option Renommer). Un appui sur ce lien ne déclenche aucune action. Je n'arrive pas à isoler le problème dans MediaWiki:Gadget-BandeauxEbauches.js, qui doit se trouver dans le second bloc conditionnel de initEditLink(), où il a pour but d'appeler startEdit(). Quelqu'un peut-il regarder ? Merci ! --Framawiki ^✉ 8 septembre 2018 à 20:59 (CEST)

Chez moi ça fonctionne, testé à l'instant sous Firefox, Chrome et IE. Des erreurs dans la console javascript ? od†n ↗^blah 8 septembre 2018 à 21:15 (CEST)

Gadget-FlecheHaut.js

Ne serait-il pas une bonne idée de rendre plus smooth le scroll top en y ajoutant une animation? Actuellement, lorsque l'on clique sur les flèches, le scroll vers le haut est trop brusque. Je proposerais quelque chose du genre:

jQuery( function ( $ ) {
    var lien = $( '<a class="noprint" href="#" title="Haut de page">↑</a>' ).click( function ( e ) {
        e.preventDefault();
        
        $( 'html, body' ).animate( {
            scrollTop: 0
            }, 1000 );
    } );
    $( '#mw-content-text' ).find( 'h2, h3, h4, h5, h6' ).append( ' ', lien );
} );

— Le message qui précède, non signé, a été déposé par Mah3110 (discuter), le 25 septembre 2018 à 02:10 (CEST)

Personnellement contre ce genre d'animation, mais pourquoi pas sous forme d'option (variable à ajouter dans le JavaScript utilisateur), bien entendu désactivé par défaut.

J'ai vérifié et c'est bien $( 'html, body' ) (les deux éléments, pas de .first()) ; refs Stack Overflow.

od†n ↗^blah 25 septembre 2018 à 10:51 (CEST)

 Mah3110 : Fait ! T'as plus qu'à activer dans ton common.js. od†n ↗^blah 25 septembre 2018 à 11:39 (CEST)

Top! Merci Od1n

Mah3110 (discuter)

Améliorer BandeauxPortails

Bonjour ! J’espèce que je suis au bon endroit… Une demande sans aucune urgence, mais qui serait bien pratique à mes yeux (et probablement pour d’autres contributeurs aussi) : améliorer BandeauxPortails pour qu’il puisse auto-compléter les noms de portails dès qu’on commence à entrer le nom (comme le fait HotCats), voire qu’on puisse ajouter plusieurs portails à la fois comme HotCats (je viens de découvrir en lisant Projet:JavaScript/Notices/BandeauxPortails qu’on peut le faire à l’aide d’un simple | entre deux noms, mais est-ce que cela fonctionnera avec une option où les noms complets sont proposés ?). TED 4 novembre 2018 à 19:50 (CET)

Fonction prochainement dépréciée

Je cite la dernière publication de Tech News :

La fonction mw.util.jsMessage() a été dépréciée en 2012. Elle sera supprimée la semaine prochaine. (en) Recherchez l’avertissement Use of "mw.util.jsMessage" is deprecated (L’utilisation de « mw.util.jsMessage » est dépréciée) dans la console JavaScript pour savoir si vous utilisez un script ou gadget affecté. Si vous êtes responsable de la maintenance d’un gadget, vous devriez vérifier si votre code JavaScript contient mw.util.jsMessage. Un guide de migration existe. Il explique comment utiliser mw.notify à la place. [3]

Trizek ^bla 27 novembre 2018 à 15:24 (CET)

Techniquement c'est bon, la fonction n'était encore présente que dans quelques scripts de Utilisateur:Lgd, et avait déjà été remplacée dans certains d'entre eux (afin d'avoir une zone de résultats décente).

Comme il pourrait y avoir encore un peu de maintenance à faire dessus, je mets ici une liste exhaustive des scripts en question, sachant que certains d'entre eux sont obsolètes :

• MediaWiki:Gadget-interProjets.js (+ MediaWiki:Gadget-interProjets.css)
• Utilisateur:Lgd/checkLinks.js
• Utilisateur:Lgd/fatMan.js
• Utilisateur:Lgd/Interprojets.js (+ Utilisateur:Lgd/Interprojets.css)
• Utilisateur:Lgd/Palettes/palettes V2.js (+ Utilisateur:Lgd/Palettes/palettes V2.css)
• Utilisateur:Lgd/refErrors/refErrors.js (+ Utilisateur:Lgd/refErrors/refErrors.css)
• Utilisateur:Lgd/refErrors/refErrorsDev.js

od†n ↗^blah 4 décembre 2018 à 00:43 (CET)