Discussion Projet:JavaScript

Une page de Wikipédia, l'encyclopédie libre.
Sauter à la navigation Sauter à la recherche
Projet Fonctions disponibles Notices Discussion projet Signaler un bug Demander une nouvelle fonction

Javascript icon.svg

PROJET JAVASCRIPT
Centraliser les fonctions JavaScript pour éviter la dispersion du code.


Cette page de discussion est destinée aux discussions sur le Projet:JavaScript.


Sommaire

sajax_init_object[modifier le code]

Bonjour, un petit message pour rappeler que le code ajax "pré-jquery", déprécié en 2012, est supprimé depuis 2015. On a quelques dizaines de pages qui utilisent encore ce code et qui sont donc cassées.

od†n ↗blah 22 mai 2017 à 07:38 (CEST)

Je vais repasser sur les pages d'aides du projet, dont beaucoup contiennent encore des mentions d'ajax pré-jquery (voir des paragraphes entiers (voir entièrement centré dessus)) et les réécrire selon les bonnes pratiques actuelles. — 0x010C ~discuter~ 1 juin 2017 à 13:23 (CEST)

Demande légitime[modifier le code]

Bonjour à tous et à toutes !
Nous souhaiterons que vous rendiez ces gadgets compatibles avec le nouveau mode de wikitexte :

  1. La compatibilité du gadget DotsSyntaxHighlighter au nouveau mode de wikitexte actuellement en bêta
  2. La compatibilité du gadget Quick Preview au nouveau mode de wikitexte actuellement en bêta

J'espère que vous pourrez rendre cela possible. — Sourire Menthe à l'eau - 7 juin 2017 à 13:23 (CEST)

Flow (et PasTec)[modifier le code]

Bonjour,

je tente actuellement de rendre MediaWiki:Gadget-PaStec.js compatible avec les utilisateurs/projets flow mais je me casse les dents avec l'API de flow dont la documentation est assez succinte. J'ai tenté de dev ici. Pour les tests, vous pouvez flooder mon faux-nez Gratis (d · c · b).

P.-S. : Dans mon code, j'ai ajouté un alert(fonctionne) à l'endroit où l'api est utilisé.

Gratus (discuter) 4 août 2017 à 17:36 (CEST)

Après recherche plus poussé, j'obtiens TypeError: mw.messagePoster is undefined dans la console. Je suppose donc qu'il faut importer [1] mais je ne sais pas comment faire. — Gratus (discuter) 4 août 2017 à 22:46 (CEST)
J'ai réussi à faire fonctionner l'API. Cependant le système de commentaires de diff/vérification/balisage est cassé sur les fonctions utilisant flow (problèmes moins grave comparé aux messages d'erreurs que l'on recevait auparavant lorsqu'on voulait avertir un utilisateur/projet utilisant flow). — Gratus (discuter) 5 août 2017 à 13:25 (CEST)

JavaScript associé au Modèle:Animation[modifier le code]

Bonjour, simplement pour attirer votre attention sur le message que j'ai posté concernant le JavaScript de ce modèle : Discussion modèle:Animation#Besoin de réécriture du JavaScript. od†n ↗blah 27 août 2017 à 20:13 (CEST)

Fait Fait, pour plus de détails se rendre sur la pdd du modèle : Discussion modèle:Animation#Besoin de réécriture du JavaScript. od†n ↗blah 10 avril 2018 à 04:23 (CEST)

Demande d'aide - Caractères spéciaux associé à addSpecialCharset[modifier le code]

Bonjour,

Le jeux de caractères (appelé Ludo) n'apparait pas dans la boite déroulante.

Un utilisateur peut-il éclairer ma lanterne, car je n'arrive pas à utiliser le script addSpecialCharset suite à la page Caractères spéciaux#Personnalisation avancée. Aucun caractères spéciaux n'apparait ni la possibilité de choisir dans la boite déroulante le jeux de caractères (appelé Ludo).

Ma page de script est ici et le code rajouté (qui semble scrupuleusement respecter le code de la page mentionné plus haut) est le suivant :

addOnloadHook(function() {
  addSpecialCharset("Ludo", "æ Æ à À â  ä Ä á Á · ç Ç · € é É è È ê Ê ë Ë · î Î ï Ï í Í · œ Œ ô Ô ö Ö ó Ó · ù Ù û Û ü Ü ú Ú · ÿ Ÿ · «  » {{subst:}} {{}} {{|}} [[]] [[|]] [] “” · — – → • ’ | … ~ ± # @ ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ⁰ ½ ");
});

L'origine du problème et la question que j'avais posée sur le forum des nouveaux vient du fait que je n'ai plus acces aux caractères Spéciaux de Wikipedia (sous Chrome v61 x64 - Windows 8.1) donc j'ai décidé de créer un jeu de caractères. Ceci est un problème récent car depuis des années j'ai toujours utilisé ces caractères.

Ai-je fait une faute dans mon script ? Merci de m'aider ou m'aiguiller ou demander de l'aide sur Wikipédia pour résoudre ce souci de script.
— Ludopedia [Discu.] 18 octobre 2017 à 13:09 (CEST)

@Ludopedia: Cette documentation n’est plus à jour (comme une bonne partie de la doc JavaScript). La correction est mineure ici : remplacer addOnloadHook par jQuery :
jQuery(function() {
    addSpecialCharset("Ludo", "æ Æ à À â  ä Ä á Á · ç Ç · € é É è È ê Ê ë Ë · î Î ï Ï í Í · œ Œ ô Ô ö Ö ó Ó · ù Ù û Û ü Ü ú Ú · ÿ Ÿ · «  » {{subst:}} {{}} {{|}} [[]] [[|]] [] “” · — – → • ’ | … ~ ± # @ ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ⁰ ½ ");
});
J’ai testé sur mon common.js perso, ça fonctionne avec ce changement (sur Firefox en l’occurence). Je met à jour cette partie de doc. ~ Seb35 [^_^] 26 octobre 2017 à 16:56 (CEST)
C'est un peu la rustine de réparation du pauvre, en l'occurrence il s'agit d'une race condition qui n'est pas vraiment résolue et qui pourrait se reproduire à l'avenir. La clé est que la fonction addSpecialCharset est définie dans MediaWiki:Common.js/edit.js et donc qu'il ne faut pas l'appeler avant que ce fichier ait été chargé. En fait ce fichier complet aurait peut-être besoin d'être "ResourceLoader-ifié". À étudier. od†n ↗blah 27 octobre 2017 à 08:49 (CEST)
Notification Od1n : et Notification Seb35 :, merci à tous les deux, votre aide est vraiment appréciée. Après la modification que vous avez suggérée tout fonctionne sur Firefox v56.0.1 (par contre pas sur Chrome v62.0.32) donc grande consolation de pouvoir utiliser Firefox. Merci pour votre temps et votre aide avec ceci Espiègle. — Ludopedia [Discu.] 5 novembre 2017 à 23:56 (CET)

Discussion tech à la WikiConvention et maintenance du projet JavaScript[modifier le code]

Lors de la WikiConvention d’octobre 2017 à Strasbourg, nous étions plus d'une dizaine à discuter de la maintenance technique de Wikipédia en français, notamment le JavaScript vieillissant, mais aussi en partie les modules Lua et les bots. La page de la présentation est sur Meta (en français) et il y a eu un pad de prise de notes.

En résumé, à propos du JavaScript, nous trouvions qu’il faudrait :

  • mettre à jour la documentation technique de ce projet JavaScript, elle est assez abondante mais elle utilise des techniques désormais obsolètes,
  • mettre à jour les gadgets (Projet:JavaScript/Maintenance 2017 des gadgets), vérifier qu’ils fonctionnent, qu’ils n’ont pas de problèmes de sécurité, et lorsque nécessaire les mettre à jour avec les techniques plus actuelles,
  • mettre à jour/compléter les documentations des gadgets,
  • dans la mesure du possible, rendre les gadgets plus génériques avec les autres wikis, dans une optique à terme de les centraliser,

Dans l’immédiat (évoqué lors de la discussion, mais discuté un peu plus en détails après entre 0x010C, Arkanosis et moi), il a été proposé de demander un dépôt Git à la Fondation pour les gadgets francophones avec un bot qui copierait depuis ce dépôt Git vers les projets francophones (ou pas d’ailleurs) qui ont le gadget, cela serait une première étape pour centraliser les gadgets. Dans l’idée, les droits de push vers ce dépôt Git seraient largement distribués, au moins aux locuteurs réguliers en JavaScript.

@0x010C @Arkanosis @Trizek (WMF) @BamLifa @Framawiki @Lionel Scheepmans @Mathis B @Gzen92 @Nicolas NALLET @Ltrlg @Ash Crow : Le résumé vous semble correct ? N’hésitez pas à compléter et/ou commenter. ~ Seb35 [^_^] 26 octobre 2017 à 17:53 (CEST)

Seb35: Très bon résumé, merci SourireArkanosis 26 octobre 2017 à 18:16 (CEST)
A noter aussi qu'a été évoquée l'idée de créer un hackaton francophone, par exemple en marge de celui de la Fondation. La prochaine édition aura lieu en mai, peut être que la WMFr l'organisera pour cette période. N'hésitez pas à vous manifester et commenter. --Framawiki 26 octobre 2017 à 20:53 (CEST)
Pour le repo Git, c'est pas très complexe à créer. Je veux bien m'occuper dès maintenant de faire et de suivre les démanches de création si tout le monde est d'accord. --Framawiki 26 octobre 2017 à 20:53 (CEST)
On avait aussi proposé d'utiliser Gerrit. --Mathis B discuter, le 26 octobre 2017 à 22:21 (CEST)
Avec Gerrit, ce serait top, oui Sourire Je suis d'accord si tu veux bien t'en charger, Framawiki. Merci SourireArkanosis 27 octobre 2017 à 00:14 (CEST)
Heureux de voir que ce projet ne reste pas à ses bonnes intentions strasbourgeoises. Sourire
Centraliser les gadgets, surtout en ayant en vue leur possible mutualisation sur les wikis, est un projet que Amire80 tentons de mettre en place quand nous avons un peu de temps. Avoir une communauté qui se lance sur ce projet est une excellente nouvelle ! Vous pouvez compter sur notre soutien dans la mesure de nos capacités.
Un point abordé durant la réunion a été d'avoir une meilleure connaissance des bots existants par les autres dresseurs afin d'éviter de regrettables et impromptues pannes. Je pense que cela peut se dérouler en parallèle, mais c'est moins l'endroit où en parler.
Trizek (WMF) (discuter) 27 octobre 2017 à 06:25 (CEST)
@Seb35 Très bon résumé. @Framawiki go for it si tu es motivé !
Je ping aussi @Od1n pour avoir son avis, vu qu'il est un des pilliers de ce projet. — 0x010C ~discuter~ 27 octobre 2017 à 10:31 (CEST)
Je suis pourtant à l'aise avec Git, mais je ne suis pas emballé par l'idée du dépôt Git. Ça sent la contrainte supplémentaire qui va rebuter les participants arrivants. Par rapport à la simple centralisation sur fr.wiki, on gagne quoi concrètement ? Cela ne va pas faire pousser magiquement de la main d'œuvre.
Par ailleurs, forte opposition à Gerrit. C'est une plaie pas croyable ce truc…
od†n ↗blah 27 octobre 2017 à 11:33 (CEST)
Ton avis est intéressant od†n, mais lorsque tu dis « Ça sent la contrainte supplémentaire qui va rebuter les participants arrivants. », je ne vois pas comment faire pire que maintenant... Seuls les admins peuvent modifier les gadgets, et on a une énorme quantité de développeurs péons améliorant les scripts dans leur sous-pages utilisateur. Et ces modifications ne seront jamais centralisées via WP:DIMS (qui n'est pas une page dédiée aux Gadgets). Or, Git (ou équivalent) permet à tout un chacun, développeur, admin ou péon, de proposer des changements dans le code, et voir les retours des autres.
Je suis par contre pleinement d'accord que Gerrit n'est ni ergonomique ni attractif : il demande un très important temps d'adaptation. Cependant, il est très puissant, et plus qu'utilisable avec l'habitude. Si pas Gerrit, d'autres idées, libres si possible ? --Framawiki 28 octobre 2017 à 18:42 (CEST)
J'avais oublié cette évidence, les pages protégées, avec les laborieux quémandages de modif sur DIMS qui font perdre un temps considérable à tout le monde. Et mécaniquement cela réduit le nombre d'améliorations apportées.
En alternative à Gerrit, je suggère GitHub sans hésiter un instant. En ergonomie et en plaisir d'utilisation, c'est le jour et la nuit. C'est tellement bien fichu qu'on peut même préparer des PR directement sur le site, sans même faire de clone local du fork. Par contre Gerrit, sur les PR même les discussions (le truc de base quoi) c'est la misère…
Je vois bien Git comme un simple complément pouvant être utilisé à la place de DIMS. En revanche, le point qui me préoccupe c'est pour la centralisation et la synchronisation. Comme je le vois, la synchronisation devrait se faire dans les deux sens, ce qui peut laisser dubitatif, et il reste la question de quel emplacement serait le master.
od†n ↗blah 29 octobre 2017 à 00:44 (CEST)

┌──────────────────┘
Pour ma part, je peux m’investir pour rénover les gadgets, mais je ne me vois pas trop demander sur DIMS à chaque fois. Sur le système de relecture de code, certaines équipes de la Fondation utilisent Phabricator Differential (exemple) et j’avais entendu que ça pourrait remplacer Gerrit à terme (je sais pas si c’est toujours d’actualité), sinon GitHub me va très bien, et de toutes façons une fois qu’un a un dépôt Git on peut migrer facilement si besoin (pas forcément les commentaires de review mais c’est secondaire).
Sur la question du master, il faudrait effectivement éviter de se désynchroniser : peut-être que le bot qui copiera de Git vers les wikis peut ne pas faire le transfert si un autre contributeur que le bot lui-même a édité plus récemment et émettre un rapport d’erreur pour ces cas, et en parallèle mettre un avertissement en haut des gadgets en demandant à faire la modif de façon centralisée. Je sais pas si c’est suffisamment acceptable pour les admins locaux de "perdre une partie de leur champ d’action", mais ça viendrait avec le bénéfice d’avoir des gadgets mieux entretenus globalement. Peut-être en complément dire que "en cas d’urgence" (genre LiveRC qui casse à cause d’une mise à jour de MediaWiki) les admins ont toute latitude de corriger en urgence (et que ça serait mieux de rapporter ensuite de façon centralisée).
~ Seb35 [^_^] 30 octobre 2017 à 09:17 (CET)

Pour info, je viens de voir passer cette tache phab:T179550 qui peut être intéressante. Je vous ai ajouté en tant que subscribers, vous pouvez vous désinscrire si besoin. --Framawiki 3 novembre 2017 à 14:31 (CET)
On part donc sur un répo Github ? Le seul point négatif est que c'est un outil externe, fermé, et qui n'appartient pas au mouvement Wikimédia, mais faute de mieux... --Framawiki 3 novembre 2017 à 14:31 (CET)

En anglais[modifier le code]

Pour info, j’ai fait un résumé en anglais de cette discussion à Samwilson (développeur à la Fondation) sur Meta : meta:User talk:Seb35#Gadgets in Git?. ~ Seb35 [^_^] 31 octobre 2017 à 10:46 (CET)

Création de balise et ajout aux préférences[modifier le code]

Bonsoir,

Hier j'ai déplacé un script de mon espace perso vers MediaWiki (Gadget-PaletteDeluxe.js). J'envisage de créer une balise ("PaletteDeluxe"), y a t'il des règles particulières qui encadrent leur création ? Même question pour l'ajout à l'onglet "gadget" des Préférences ? Merci, Prométhée (discuter) 26 octobre 2017 à 21:15 (CEST)

@Prométhée En soi, il n'y a pas de règles écrites à ce sujet, que des règles tacites. Si ton script est opérationnel pour toutes les configurations, tu peux l'ajouter à la liste des gadgets. Idem pour la création d'une balise, si tu en as besoin, créé en une (c'est même plutôt une bonne idée pour suivre les modifs faites avec le gadget).
Cependant, je vais nuancer mes propos généraux à la vue de ton code : Dans la section juste au dessus, tu pourras constater que nous essayons de lancer un grand nettoyages des codes, et d'établir des bonnes pratiques de programmation. Je sais que cela n'a rien d'obligatoire et que l'on a pas fait encore la doc qui va bien, mais voici quelques petites améliorations que tu pourrais apporter avant de le passer en gadget :
  • Utiliser mw.Api à la place des requêtes Ajax en dure ;
  • Travailler plus avec JQuery pour les manipulations du DOM ;
  • Commenter un peu plus tes fonctions
Amicalement — 0x010C ~discuter~ 27 octobre 2017 à 10:06 (CEST)
D'accord merci pour tes retours, je vais travailler à la mise en place de la balises et aux évolutions avant de mettre en place le script dans les préférences. Prométhée (discuter) 27 octobre 2017 à 18:01 (CEST)

ContribsRange[modifier le code]

Bonjour,

Vu que Special:Contributions affiche maintenant les contributions d’une plage IP (voir 92.136.0.0/16 (u · d · b) par exemple) de manière native, il faudrait mettre à jour le gadget ContribsRange pour qu’il s'affiche uniquement lorsqu’on recherche une plage avec un joker.

Cordialement. — Thibaut (discuter) 27 octobre 2017 à 14:06 (CEST)

Du coup, ce script n'est plus tellement utile ? [123.123.123.*] peut s'écrire [123.123.123.0/24], et les recherches [Pseudo*] ne doivent pas servir bien souvent… La seule chose qui reste donc est la simplicité d'utilisation de saisir [123.123.123.*] au lieu de [123.123.123.0/24].
Ce qu'on pourrait faire, c'est ajouter un javascript (pour tout le monde, pas en gadget, comme ça un gadget en moins) qui, lorsque le champ contient [123.123.123.*], redirige automatiquement vers [123.123.123.0/24]. Comme ça, script plus simple, et les résultats sont ceux natifs de mediawiki et pas ceux obtenus avec de l'ajax maison.
od†n ↗blah 29 octobre 2017 à 01:04 (CEST)
@Od1n et @Thibaut120094 ça : Utilisateur:0x010C/neoContribsRange.js ? — 0x010C ~discuter~ 29 octobre 2017 à 11:48 (CET)
C'est l'idée, oui. Par contre je suis dubitatif concernant le remplacement du texte pendant qu'il est saisi, c'est le genre de truc qui habituellement m'horripile. On pourrait plutôt faire la manip lors de la soumission du formulaire.
(à propos, l'event input est préférable à keyup, il gère davantage de situations, par exemple les copier-collers à la souris ; refs oninput event)
od†n ↗blah 29 octobre 2017 à 12:00 (CET)
@Od1n Et hop ! Sourire Je pense que ça serait quand même bien de le mettre à la place du gadget actuel, au moins le temps d'avoir d'éventuels retours, avant de le mettre dans le common.js, non ? — 0x010C ~discuter~ 30 octobre 2017 à 18:22 (CET)
Quitte à le mettre pour tout le monde, ce serait encore mieux dans MediaWiki, côté serveur — c'est-à-dire sans réécriture et sans JavaScript (et donc sans overhead ni risque d'interférer avec la saisie de l'utilisateur), non ? Amicalement — Arkanosis 30 octobre 2017 à 19:13 (CET)
@Arkanosis J'y ai pensé, mais ça ne sera pas possible car « 78.226.* » par exemple est un nom d'utilisateur valide pour MediaWiki. Ici, on part du postulat que ce genre de pseudos n'arrivera pas (et sur frwiki, il faut être admin pour pouvoir ignorer la vérification de similitude pour avoir accès à ce genre de pseudos), mais ce n'est pas un postulat généraliseable Mouais. — 0x010C ~discuter~ 30 octobre 2017 à 20:46 (CET)
L'autre alternative serait sinon d'éduquer les contributeurs via page d'aides ou court message dans le formulaire de Spécial:Contributions (faire attention à pas surcharger visuellement ce formulaire déjà chargé...) — 0x010C ~discuter~ 30 octobre 2017 à 20:52 (CET)
Je suggère de continuer à le proposer sous forme de gadget, pour ne pas encore alourdir le javascript des utilisateurs qui n'ont rien demandé, mais en revanche, on pourrait le délister des définitions de gadgets, vu qu'il est relativement marginal. od†n ↗blah 30 octobre 2017 à 23:16 (CET)

Supprimer les gadgets WikiOpenStreetMap et WikiMiniAtlas[modifier le code]

Sauf erreur, le gadget WikiOpenStreetMap (je n'ai pas trouvé le code source, où est-il ?) ne fait plus rien depuis que Kartographer est activée. Soit dit en passant, il utilise des fonctions jquery qui seront bientôt abandonnées (voir console d'erreur qui mène à [2]). Même chose pour WikiMiniAtlas (idem pour le code source) qui n'a plus l'air de fonctionner non plus. Ces gadgets (qui devraient d'ailleurs être dans Cartographie) ne pourraient-ils pas être supprimés ? The RedBurn (ϕ) 1 novembre 2017 à 15:45 (CET)

Voir aussi Wikipédia:Le_Bistro/30_octobre_2017#.2F.21.5C_Maintenance_des_gadgets_.2F.21.5C The RedBurn (ϕ) 1 novembre 2017 à 17:25 (CET)
@The RedBurn Comme tu l'as vu sur le bistro, c'est dans les cartons. Afin d'éviter 50 000 octets de réclamations sur le bistro, j'ai pris les devants en laissant le temps aux éventuelles mécontents de réagir. Je viens de republier le message sur le bistro d'aujourd'hui, donc si d'ici quelques jours y'a pas de retours, on pourra passer à l'étape suivante Sourire.
(btw, n'hésite pas à me ping quand il est question de Kartographer)
— 0x010C ~discuter~ 14 novembre 2017 à 21:37 (CET)

Retrait de vieux gadgets[modifier le code]

Ola!

Voilà qui est fait, comme planifié sur la page Projet:JavaScript/Maintenance 2017 des gadgets et après avoir averti par deux fois le bistro, je viens de retirer de la liste des gadgets les 9 suivants :

  • interProjets
  • verifHomon
  • TriInterWiki
  • WikiMiniAtlas
  • WikiOpenStreetMap
  • Quick Preview
  • newCollapsible
  • MiseEnPageEspaceAide
  • DeleteBot

Ils restent cependant activable via un obtenir( 'NomDuGadget' ); placé dans son common.js.

Cordialement — 0x010C ~discuter~ 20 novembre 2017 à 21:04 (CET)

Ola!
Question à deux balles 0x010C : est-ce que newCollapsible n'était pas (par hasard) le système permettant de fermer les blocs de texte présents dans Aide:Sommaire (et à divers autres endroits) ? Mort de rire
Je demande, parce que là, c’est un peu cassé. Tire la langue Trizek bla 26 novembre 2017 à 10:44 (CET)
@Trizek « chez moi ça marche » © Sifflote. Sinon, voici le message qu'Od1n a indiqué lorsqu'il a rajouté ce gadget à la liste : Alternative obsolète au "collapsible" natif de MediaWiki. (j'en profite pour le pinger, vu qu'il connait bien mieux ce gadget que moi) — 0x010C ~discuter~ 26 novembre 2017 à 10:53 (CET)
Si ça marche chez l'un mais pas chez l'autre, c’est qu'il y a un problème™.
Si j'ai les infos que le "collapsible" natif, je prends pour faire les réparations. Trizek bla 26 novembre 2017 à 10:54 (CET)
En effet, la suppression du gadget newCollapsible ne pouvait pas se faire aussi simplement qu'en retirant le gadget. Celui-ci ne venait pas remplacer le code MediaWiki natif appliqué aux classes "mw-collapsible", mais s'appliquait à un jeu de classes différentes, "fr-collapsible". J'ai hésité à le remettre en place, puis je me suis dit que ce n'était pas plus mal comme ça, pour "forcer le mouvement" et inciter à mettre à jour les pages.
(à ce propos, j'en profite pour signaler phab:T155347 que j'aurais voulu voir résolu au préalable.)
od†n ↗blah 26 novembre 2017 à 19:48 (CET)
(et encore à propos, j'avais aussi ouvert phab:T179612 parce que, qu'est-ce qu'il me gonfle cet effet de "fading" quand on toggle des tables…) od†n ↗blah 26 novembre 2017 à 19:53 (CET)
Encore un défaut dans le code de mediawiki, ce sont les captions qui peuvent être ridiculement étroites sur les tables repliées (exemple) (update : problème connu sur en.wiki). Je continue néanmoins de penser qu'il faut essayer de centraliser le bazar, parce que là nous avons les palettes ("table.collapsible" dans le Common.js), les boîtes déroulantes (".NavFrame" dans le Common.js), le système natif (".mw-collapsible"), le fork local (".fr-collapsible")… od†n ↗blah 26 novembre 2017 à 20:52 (CET)
En problème avec "mw-collapsible", on peut encore ajouter Firefox qui centre le caption n'importe comment avec les tables centrées, lorsqu'elles sont repliées (exemple, le "tableau synthétique" en bas). od†n ↗blah 26 novembre 2017 à 21:45 (CET)

J'ai traité une partie des pages. Il reste encore des trucs cassés notamment sur les pages d'aide (exemple). Notification Trizek, si jamais tu as les moyens d'apporter de l'aide… Et bien entendu, mw-collapsible aurait besoin de rustines en local, en attendant espérant un jour mieux upstream (délicat de corriger de sorte à n'introduire de problème nulle part). od†n ↗blah 27 novembre 2017 à 04:03 (CET)

od†n, maintenant que j'ai un exemple, je vais tenter d'aider. :) Trizek bla 27 novembre 2017 à 08:54 (CET)
  • Pour réactiver rapidement le gadget : importStylesheet('MediaWiki:Gadget-newCollapsible.css'); obtenir('newCollapsible');
  • Il y a aussi des "fr-collapsible-group", "fr-collapsible-group-toogle" (exemple). A priori pas très utiles, peut-être pourraient-il simplement sauter ?
  • De manière plus générale, essayer de limiter l'usage des scripts "d'enroulage", qui peuvent même faire plus de mal que de bien. (exemple, le bouton bleu pour… une ligne, soupir)
od†n ↗blah 27 novembre 2017 à 09:04 (CET)
Après avoir pas mal cogité les différents scénarios possibles, j'ai ajouté des règles qui devraient bien améliorer la situation. Si jamais vous trouvez des tables qui rendent mal avec ces règles, vos signalements sont les bienvenus. od†n ↗blah 28 novembre 2017 à 02:46 (CET)

Beautifier et formatter le code[modifier le code]

Question, est ce qu'il y a eu un jour une décision sur la manière de formater proprement le code des gadgets ? Question lisibilité cela pourrait être pas mal de se mettre d'accord. Prométhée (discuter) 2 décembre 2017 à 19:15 (CET)

Comme base il y a mw:Manual:Coding conventions/JavaScript, qui semble avoir été adoptée ici, par exemple par 0x010C. C'est plutôt propre comme convention, à un détail près, mais de taille : ces p** d'espaces à l'intérieur des parenthèses… Il y en a partout, c'est la plaie à lire et c'est encore plus pénible à écrire… od†n ↗blah 3 décembre 2017 à 15:24 (CET)
C'est très bizarre sur les tableaux aussi d'avoir ces espaces, exemple :foo = [ bar, baz ];. C'est à rebours de ce que j'ai l'habitude de pratiquer ailleurs... Prométhée (discuter) 3 décembre 2017 à 21:10 (CET)

Supprimer le système "collapsible group" ?[modifier le code]

Bonjour,

Comme déjà évoqué dans la section un peu au dessus, la suppression du gadget newCollapsible (qui était activé par défaut pour tout le monde) a incité à migrer les pages qui faisaient usage de ce système, vers le système natif "mw-collapsible" (docs : en:Help:Collapsing, mw:Manual:Collapsible elements).

Une bonne partie a déjà traitée, par contre le gadget implémentait un système "collapsible group", qui n'est pas présent nativement. Cela sert à ajouter un lien "Tout ouvrir / tout fermer". Comme vous pouvez constater, le système est assez peu utilisé : Aide:Sommaire, Wikipédia:Parrainage des nouveaux, Projet:Art+Féminisme/30 septembre 2017, Projet:Colombie.

J'ai rajouté ce système dans le Common.js mais honnêtement cela me gêne d'alourdir ainsi le javascript local, alors que ma démarche est justement de réduire la quantité de bazar ajouté en addition du javascript de mediawiki (par contre celui-là ne se gêne pas pour grossir encore et encore).

On en arrive à l'objet du message : j'ai bien envie de tout simplement supprimer ce système "collapsible group". Qu'en pensez-vous ?

od†n ↗blah 10 décembre 2017 à 22:18 (CET)

@Od1n Si effectivement cela se résume à quelques pages hors de l'espace principale, je soutiens totalement — 0x010C ~discuter~ 11 décembre 2017 à 15:29 (CET)
Je viens de supprimer cela, effectivement il n'y a à peine que sur les quelques pages citées plus haut que c'était réellement utilisé. Et là encore, de toute façon ça mettait la pagaille pour s'y retrouver, en déroulant tout d'un coup. od†n ↗blah 18 décembre 2017 à 06:04 (CET)
Je trouvais ça pratique mais OK pour moi ; je notifie Jules78120 qui l'utilisait je crois. — Kvardek du (laisser un message) le 19 décembre 2017 à 21:19 (CET)
Hmmm, tu dois confondre avec quelqu'un d'autre Kvardek du ; en tout cas ça ne me dit rien, comme ça. Amicalement, — Jules Discuter 19 décembre 2017 à 22:09 (CET)
Tu trouvais le système pratique sur une page en particulier ? Personnellement, j'ai trouvé à l'usage que ce système était une fausse bonne idée, n'apportant en fait pas de gain en ergonomie : en déroulant tout d'un coup on ne s'y retrouve plus, et si c'est pour faire cela, autant ne pas mettre de zone déroulante du tout…
Aussi, tu devais probablement penser à Trizek, (c'est que je commence à les connaître les pages qui utilis·ai·ent les classes "fr-collapsible" 😁)
od†n ↗blah 20 décembre 2017 à 00:44 (CET)
Je ne suis pas certain de tout comprendre... Vous voulez remplacer fr-collapsible par mw-collapsible ou vous voulez carrément retirer les boîtes déroulantes ? Trizek bla 20 décembre 2017 à 09:57 (CET)
Seulement remplacer fr-collapsible par le mw-collapsible natif, afin de ne pas rajouter un tas de javascript pour quelque chose qui existe déjà nativement. od†n ↗blah 21 décembre 2017 à 06:42 (CET)
OK, ouf. :) Désolé de t’avoir fait répéter od†n, mais je n'avais pas tout compris. Trizek bla 21 décembre 2017 à 19:31 (CET)

Demande Nouvelle Fonctionnalité[modifier le code]

Bonjour,

Serait-il possible de rendre compatible la fonctionnalité LeftPaneSwitch avec Timeless ? Mais en l'améliorant afin de permettre l'ajout d'un bouton permettant d'afficher/masquer le menu latéral de gauche et le menu latéral de droite. Sourire Menthe à l'Eau - 26 décembre 2017 à 13:04 (CET)

Script MaintenanceCategorie[modifier le code]

(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)
Notification 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[modifier le code]

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[modifier le code]

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[modifier le code]

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)
Fait 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 ?[modifier le code]

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[modifier le code]

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 ([3]). 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 ?[modifier le code]

Bonjour,

Par la même occasion, serai t'il envisageable d'ajouter les deux gadgets contribs-relecture.js et hist-relecture.js de Notification 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)
Notification 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[modifier le code]

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[modifier le code]

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 Bonjour,
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 Notification 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[modifier le code]

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[modifier le code]

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é Sourire).
— 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 Clin d'œil
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)
Notification 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 Sourire. 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é Sourire (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 Sifflote.
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[modifier le code]

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 Clin d'œil), 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 Notification 0x010C et Od1n : qui sont les principaux contributeurs sur le .js du gadget.

@Habertix Fait céfé Clin d'œil — 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 Sourire. — 0x010C ~discuter~ 15 mai 2018 à 01:22 (CEST)
Tout bon ! Merci. -- Habertix (discuter) 15 mai 2018 à 23:53 (CEST).

Alerte notification chez envoyeur[modifier le code]

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[modifier le code]

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)

Notification 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[modifier le code]

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)

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

Poisson d'avril 2018[modifier le code]

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 Sourire
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 :-) Notification 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 ! Sourire
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)
Notification 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[modifier le code]

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[modifier le code]

Sujet technique 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. [4]

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[modifier le code]

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[modifier le code]

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 2e point de ta liste Mort de rire
od†n ↗blah 14 mai 2018 à 15:54 (CEST)
Fait 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[modifier le code]

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 et ), 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)

Fait 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[modifier le code]

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 Clin d'œil — 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[modifier le code]

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 Notification 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[modifier le code]

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)

Fait Ç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[modifier le code]

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 Sourire
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[modifier le code]

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[modifier le code]

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()" ( ou encore ), 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)
Notification 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)
Notification 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[modifier le code]

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 Sourire
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)
Fait Je viens de retirer cette activation par défaut. od†n ↗blah 7 septembre 2018 à 23:37 (CEST)

Délistage ContribsRange[modifier le code]

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)

Notification 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 Clin d'œil
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)
Notification Od1n : Bon alors je me range à ton avis, va pour moi pour le délistage Clin d'œil.
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 :
ou
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[modifier le code]

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[modifier le code]

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)
Fait Notification 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)