Discussion Projet:Scripts et gadgets — Wikipédia

Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Portail de qualité
  • Bon portail
  • Lumière sur
  • À faire
  • Archives
  • Commons
Le projet « Scripts et gadgets » n'est pas notifié pour le moment.


Projet Fonctions disponibles Notices Discussion projet Signaler un bug Demander une nouvelle fonction
PROJET SCRIPTS ET GADGETS
Centraliser les fonctions JavaScript et CSS pour éviter la dispersion du code.


Cette page de discussion est destinée aux discussions sur le Projet:Scripts et gadgets.


Gadget pour affichage de l'aide dans le menu de la version mobile[modifier le code]

Ne pas archiver.

Hello les sorciers du code,

Je vous ai trouvé une nouvelle mission Émoticône sourire !

Comme vous pourrez le lire sur ce sujet il y a un petit souci sur la version mobile du site, il n'y a pas de lien vers l'aide dans le menu hamburger.

Du coup, on a ouvert un ticket sur Phabricator (Phab:T252796) pour ajouter un lien. Ce n'est pas une priorité pour les dévs mais il semble qu'il y ait, sur la version sv.m.wikipedia.org, un gadget qui permette l'affichage du lien vers l'aide.

Sauf que je n'arrive pas à l'identifier ni à savoir s'il serait adaptable ici.

Est-ce que vous pourriez nous apporter votre éclairage ?

Merci — Mattho69 me joindre 8 juin 2020 à 18:38 (CEST)[répondre]

Il faudrait sinon demander sur le Bistro suèdois... -- Nemo Discuter 8 juin 2020 à 19:45 (CEST)[répondre]
@Mattho69 et @Nemo Le Poisson : Il s'agit de MediaWiki:Gadget-helpLinkMinerva.js. Le gadget n'est pas utilisable tel quel ici mais
mw.loader.using( [ 'mediawiki.api', 'mediawiki.util', 'mediawiki.base' ], function () { 	$( function () { 		if ( mw.config.get( 'skin' ) === 'minerva' ) { 			new mw.Api().loadMessagesIfMissing( [ 'help' ] ).then( function () { 				mw.util.addPortletLink( 					'p-navigation', 					'/wiki/Aide:Accueil', 					mw.message( 'help' ).text(), 					'n-help' 				); 				$( '#n-help' ).children().attr( 'class', 'mw-ui-icon mw-ui-icon-before mw-ui-icon-help' ); 			} ); 		} 	} ); } ); 
devrait suffire. Cordialement, ─ DreZhsh Discuter 28 août 2022 à 10:35 (CEST)[répondre]
@DreZhsh, un grand merci d'avoir identifié la source du code sur le wiki suèdois. J'ai essayé le code que tu propose dans Utilisateur:Nemo Le Poisson/minerva.css mais je ne vois pas le lien vers l'aide s'afficher dans le menu de gauche. Est-ce que j'ai tout fait comme il faut tu penses ? -- Nemo Discuter 16 octobre 2022 à 17:09 (CEST)[répondre]
@Nemo : Le morceau de code est en JavaScript, pas en CSS. ─ DreZhsh Discuter 16 octobre 2022 à 20:00 (CEST)[répondre]
J'ai déplacé le code vers la bonne page (Utilisateur:Nemo Le Poisson/minerva.js), histoire que tu n'aies pas de code CSS invalide en version mobile. od†n ↗blah 21 octobre 2022 à 10:52 (CEST)[répondre]
Ça marche merci beaucoup Od1n et DreZhsh ! -- Nemo Discuter 2 novembre 2022 à 22:26 (CET)[répondre]

Proposition de logo pour le gadget PaStec[modifier le code]

Bonjour Émoticône, je souhaiterais changer le logo actuellement utilisé par le gadget PaStec, c'est pourquoi je demande des avis extérieurs. Voici le logo actuel et ma proposition.

Ma proposition
Logo actuellement utilisé

. Cordialement, manȷıro💬 22 octobre 2023 à 15:54 (CEST)[répondre]

J'adore ta proposition ! — Koreller (d) 22 octobre 2023 à 18:13 (CEST)[répondre]
Idem ! Un peu de fraîcheur fait du bien, il faudrait l'implémenter ! Cordialement, — AquilonsM'écrire 23 novembre 2023 à 12:50 (CET)[répondre]
@Aquilons @Koreller@Manjiro5 alors en fait comment ? Pour Riad Salih (discuter) 19 janvier 2024 à 00:09 (CET)[répondre]
Je vote Pour la modification du logo pour celui de Manjiro — Koreller (d) 19 janvier 2024 à 09:37 (CET)[répondre]
@LD comment en fait pour modifier le logo ? Cdlt Riad Salih (discuter) 23 janvier 2024 à 01:47 (CET)[répondre]
@Riad Salih, MediaWiki:Gadget-PaStec.js L492 : //upload.wikimedia.org/wikipedia/commons/b/b4/PaStec_logo_%28black%29.png à remplacer par //upload.wikimedia.org/wikipedia/commons/4/46/PaStec_logo_proposal.svg. LD (d) 25 janvier 2024 à 00:02 (CET)[répondre]
Je viens d'effectuer le remplacement.
À noter que comme l'image est plus grande que la précédente, il a fallu ajouter un redimensionnement pour ne pas se retrouver avec une image exagérément grande ; ça tombe bien c'est un SVG, donc ça se prête sans problème au redimensionnement. J'avais aussi fait divers essais avec des tailles en pourcentage de la boîte, mais il s'est avéré que le mieux est une taille fixe. J'ai très légèrement réduit la taille (600px de largeur, versus les 668px pour l'image précédente), mais j'étais tenté de réduire bien davantage.
(après comparaisons supplémentaires : la nouvelle image, avec la largeur 600px que je lui ai mise, est un peu moins large que l'image précédente, et étant donné qu'elle a un aspect-ratio différent, je viens de constater qu'elle fait quasi-exactement la même hauteur que l'image précedente ; le 600px va donc vraiment bien comme base)
od†n ↗blah 25 janvier 2024 à 01:10 (CET)[répondre]
Bravo pour le logo ! — Thibaut (discuter) 28 janvier 2024 à 19:18 (CET)[répondre]
Pour information, j'ai fait renommer le fichier pour mieux correspondre à son nouveau statut : 212039702. od†n ↗blah 1 février 2024 à 09:12 (CET)[répondre]

Pour information, refs cette discussion : en:MediaWiki talk:Wdsearch.js#Edit request: code fix.

tl;dr : Une partie de code visant à injecter du contenu supplémentaire dans les résultats de ce gadget était pétée depuis trois ans. Cette partie vient d'être réparée, mais il se pourrait qu'en fait c'était mieux de ne pas injecter ce contenu supplémentaire, car je trouve que les descriptions perdent énormément en clarté (beaucoup de redondance, parfois même du texte en anglais…).

(liens pratiques : MediaWiki:Gadget-Wdsearch / MediaWiki:Gadget-Wdsearch.js / en:MediaWiki:Wdsearch.js / en:MediaWiki:Wdsearch-autodesc.js)

od†n ↗blah 30 octobre 2023 à 02:43 (CET)[répondre]

C'est des descriptions automatique non c'est utile au moins sur les éléments sans description en français, et ça peut évoluer ter d'avoir à ajouter des descriptions quand l'auto fait l'affaire. Ce serait bien d'aller corriger à la source. — TomT0m [bla] 13 janvier 2024 à 19:05 (CET)[répondre]

Cherche idées de nom pour un script[modifier le code]

Bonjour,

J'utilise énormément l'outil WikiBlame (site), mais je rencontre deux problèmes avec lui :

  • J'ai souvent des faux négatifs à cause de la recherche binaire, et du coup je dois tripatouiller avec la date de début de recherche pour que ça teste d'autres révisions…
  • Récemment, l'outil a été hors ligne quelques temps, et je me suis rendu compte à quel point il m'est indispensable.

Le premier point me fait envisager depuis longtemps de développer mon propre outil (surtout après avoir réalisé à quel point le principe est simple, et réalisable avec l'API JavaScript, puisque c'est simplement une histoire de récupérer les révisions et chercher dans leur contenu).

Le deuxième point m'a décidé à me lancer dans ce développement.

Donc voilà, je me suis réalisé un outil, qui reprend le principe de WikiBlame mais en exécution JavaScript côté client. Le code est plutôt bien avancé : les fonctionnalités principales sont présentes, il manque quelques fonctionnalités avancées (et pour garder le script simple, pas certain que je les mette en place), et surtout il reste à mettre le code au propre. Il m'est tellement agréable à l'utilisation que je me commence déjà à prendre l'habitude de l'utiliser à la place de WikiBlame.

J'envisage naturellement de le publier ici, surtout parce que ça me facilitera son utilisation, en "JavaScript utilisateur". Mais le script m'a l'air tellement utile que je pense qu'il sera envisageable de le publier sous forme de gadget.

C'est là que vous pourriez apporter votre aide : je n'arrive pas à trouver de nom pour le script… Il faut que le nom contienne "Blame", et qu'il soit simple et générique, étant donné qu'il pourra éventuellement être publié sous forme de gadget.

Voilà, alors si quelqu'un trouve LE nom auquel je n'ai pas pensé…

od†n ↗blah 13 janvier 2024 à 18:31 (CET)[répondre]

@Od1n Je suggèrerai bien "who wrote that?" mais ce serait une énorme repompe honteuse vu que c'est déjà pris : mw:Who_Wrote_That? et c'est désormais utilisable sur ce wiki. — TomT0m [bla] 13 janvier 2024 à 19:01 (CET)[répondre]
J'avais justement remarqué cet outil il n'y a pas longtemps (probablement lorsque je cherchais des idées de noms…). C'est vraiment impressionnant comment projet. od†n ↗blah 13 janvier 2024 à 19:24 (CET)[répondre]
Bonsoir Émoticône sourire Merci pour ce dev od†n! J'utilise aussi beaucoup Wikiblame, mais une autre implémentation existe dans xTools, qui ne marche que pour les articles (et qui semble utiliser le même backend que Who wrote that).
De mémoire, l'extension navigateur Who wrote that ne permet pas bien d'analyser le wikicode, uniquement le rendu html. Difficile avec d'avoir des infos sur l'ajout des paramètres des modèles par ex.
J'ai pas d'idée pour le nom, mais ça peut être une bonne idée d'utilisation d'un LLM Émoticône sourire Cordialement, -Framawiki 13 janvier 2024 à 21:15 (CET)[répondre]
"Inquisiteur" pour rester dans l’esprit du "wikiblame". C’est ptete un peu sombre mais en tant que moines encyclopédiques … — TomT0m [bla] 19 janvier 2024 à 15:59 (CET)[répondre]
ou "historiographe" pour faire dans l’archéologie d’écriture, ou "comparateur" pour faire genre "littérature comparée". — TomT0m [bla] 19 janvier 2024 à 16:02 (CET)[répondre]
Historiographe est sympa. Peut-être aussi QuiEst-Ce? Cordialement, -Framawiki 20 janvier 2024 à 22:30 (CET)[répondre]
Karma, car celui qui est l'auteur du diff va se faire remonter les bretelles ! Lofhi (discuter) 24 janvier 2024 à 10:18 (CET)[répondre]

Permettre aux gadgets/scripts d'utiliser Vue et Codex[modifier le code]

Enregistré sur Phabricator
Tâche 313945

Les développeurs de la Fondation ont développé Codex qui va remplacer MediaWiki UI, OOUI et l'ancien Wikimedia Design Style Guide. Codex en plusieurs morceaux cela donne : des composants Vue, des composants en CSS uniquement, des icônes et des règles atomiques (pour la base des différents habillages, un peu à la Tailwind si cela vous dit quelque chose).

Ils veulent à terme que Vue soit un modèle de contenu d'une page possible (MediaWiki:Gadget-Truc-main.vue ; MediaWiki:Gadget-Truc-form.vue ; ...). Exemple non contractuel : mw:User:Roan Kattouw (WMF)/Codex example gadget (assuming better Vue support in gadgets). Plus ou moins mature parce que certains cas d'usages ne sont pas prévus... « [...] it is made clear that Codex components (and the CSS for the Codex Button specifically) is not guaranteed to be stable for use in wikitext » (réf : T355242).

Il y a eu des tensions entre les équipes avec le cas de classe CSS .mw-ui-button ; mise en production du retrait puis retour en arrière (réf : T346469). Visiblement TemplateStyles ne sera pas compatibles avec Codex (impossible d'@import un fichier .less ; voir réf. T56864 [2020]). Sauf que dernièrement, ils annoncent vouloir rendre possible l'import des fichiers .less pour les gadgets, voire plus (réf : T340477). C'est tout pour le résumé rapide. Lofhi (discuter) 24 janvier 2024 à 10:37 (CET)[répondre]

Breaking change dans les scripts utilisateur[modifier le code]

Enregistré sur Phabricator
Tâche 301212
Enregistré sur Phabricator
Tâche 357580

Pour info : T301212 ainsi que T357580, et ça va faire un peu mal.

Pour résumer : Actuellement, les utilisateurs avec la skin Vector 2022 se voient charger leur vector-2022.js et leur vector.js (oui, le même que celui avec la skin Vector classique). Même chose avec les fichiers CSS. Ainsi, les utilisateurs qui sont passés de la skin Vector classique à la skin Vector 2022, et qui avaient des personnalisations dans leur vector.js (donc j'imagine pas mal de monde…), n'ont constaté aucun changement, jusqu'à prochainement. Mais cela devrait bientôt changer, avec la skin Vector 2022 qui ne chargera plus que les fichiers "vector-2022".

Le changement est bienvenu, dans la mesure où il s'inscrit dans une démarche de distinction des deux skins, car au départ elles étaient un peu confondues, et il s'est avéré que cela pose beaucoup de problèmes.

En revanche, préparez-vous à de nombreuses doléances d'utilisateurs ne comprenant pas pourquoi leurs personnalisations ont subitement disparu…

od†n ↗blah 21 février 2024 à 21:06 (CET)[répondre]

Une recherche de "vector.js" dans le titre me donne moins de 1000 utilisateurs avec "vector.js" (et certains sont des vector 2022, fin de liste), pour donner un ordre de grandeur.
Peut-être qu’on peut se débrouiller pour laisser un message sur leur PU ? — TomT0m [bla] 22 février 2024 à 15:23 (CET)[répondre]
Je peux délivrer les messages, à vous de savoir ce que vous voulez mettre dedans. @Od1n pourrait même utiliser Spécial:MassMessage, non ? Lofhi (discuter) 22 février 2024 à 17:09 (CET)[répondre]
Tu peux ajouter des quotes pour éliminer ces faux positifs : recherche.
J'avais oublié de mentionner le ticket lié T357580. Sur celui-ci figure une suggestion de script, à ajouter en exécution chez tous les utilisateurs connectés, et leur proposant, lors de la première exécution du script, de copier automatiquement les pages, si le script a détecté des pages ayant besoin d'être copiées. L'idée pourrait sembler bonne, mais j'y vois deux défaut :
  • La copie n'est suggérée qu'une seule fois. Si l'utilisateur clique sur « Annuler », il n'a plus d'autre chance de faire appel à cette copie automatique.
  • De nombreux utilisateurs ne vont pas comprendre « qu'est-ce que c'est encore que ce message qui s'est affiché » (et vont probablement cliquer sur « Annuler »…)
Je pense à une solution plus radicale : Pour tous les utilisateurs ayant du "vector" mais pas du "vector-2022" correspondant, on s'occupe de leur copier automatiquement les fichiers. Avec une seule limite, on fait ça seulement pour les utilisateurs avec au moins un edit au cours des six derniers mois (par exemple, et on peut toujours à nouveau effectuer des copies plus tard) ; ceci pour limiter la démultiplication de pages avec des codes obsolètes, qui compliquent les recherches de maintenance de code sur le wiki.
od†n ↗blah 22 février 2024 à 17:29 (CET)[répondre]
Les admins ont le droit de modifier ces fichiers chez les utilisateurs ? Je crois pas perso avoir le droit de modifier le fichier common.js d’un autre en tout cas, pour des raisons bien compréhensibles. — TomT0m [bla] 22 février 2024 à 17:32 (CET)[répondre]
Seuls les Administrateur d'interface ont le droit (cf edituserjs de Spécial:Liste_des_droits_de_groupe). -Framawiki 22 février 2024 à 18:13 (CET)[répondre]
Ça ne dispense sans doute pas de prévenir quand même au cas ou il y aurait édition ultérieure du vector en toute ignorance du changement pour des gens qui n’auraient même pas la page en liste de suivi :) Et pour ceux qui n’auraient pas d’édition dans les 6 mois sans faire le transfert le message peut toujours être utile. — TomT0m [bla] 22 février 2024 à 21:45 (CET)[répondre]
Oui, dans tous les cas, il faudra laisser un message (et clairement, ce n'est pas moi qui vais le rédiger) en pdd pour tous les utilisateurs ayant besoin d'au moins une copie de fichier. Comme ça ils seront nettement mieux informés, avec un message dont ils seront notifiés et qui ne sera pas volatile. Je pense qu'il faudra quand même faire les copies automatiques, pour simplifier la vie aux utilisateurs.
Le truc, c'est le timing : il faudrait basculer le wiki vers le nouveau mode, et seulement (et aussitôt) après faire les copies ; parce que sinon il faudrait en plus gérer l'histoire que les scripts seraient exécutés en double jusqu'à la bascule vers le nouveau mode…
od†n ↗blah 23 février 2024 à 00:38 (CET)[répondre]
Le timing ne semble pas problématique : élus et nommés ont généralement le privilège noratelimit. Les 2 000 pages peuvent sûrement être traitées à la chaîne en 5 minutes pour ne pas risquer de surcharger les réplicas, mais de nuit cela devrait rouler. Lofhi (discuter) 23 février 2024 à 00:50 (CET)[répondre]
Tout à fait. Mais ce que je voulais dire, c'est surtout qu'il faut avoir tout préparé (message à poster, liste des utilisateurs devant recevoir le message, script de copie automatique des fichiers, lequel doit aussi déterminer l'ancienneté du dernier edit de l'utilisateur) avant de demander la bascule du wiki. Et aussi être disponible au moment où la bascule est effectuée, pour exécuter tout cela. od†n ↗blah 23 février 2024 à 04:02 (CET)[répondre]
Une autre possibilité serait, au lieu de recopier les codes, de créer des "redirections". Exemples de codes :
pour le JavaScript :
mw.loader.using( 'mediawiki.util', function () { 	var page = 'Utilisateur:' + mw.config.get( 'wgRelevantUserName' ) + '/vector.js'; 	var url = mw.util.getUrl( page, { action: 'raw', ctype: 'text/javascript' } ); 	mw.loader.load( url ); } ); 
et pour le CSS :
/*  * Limites :  * - le nom d'utilisateur est hardcodé, donc cela ne fonctionnera plus si l'utilisateur fait renommer son compte  * - il faut escaper :  *     - les quotes (single ou double selon celles employées pour la string)  *     - les backslashes (oui, on peut en avoir dans les noms d'utilisateurs...)  */ @import '/w/index.php?title=Utilisateur:<Nom de l\'utilisateur>/vector.css&action=raw&ctype=text/css'; 
Je ne sais pas si cette solution serait une meilleure idée. Elle aurait l'avantage de réduire la duplication de code, et l'inconvénient d'ajouter des requêtes HTTP.
Je vois aussi le risque que si les utilisateurs touchent aux fichiers après, ils fassent n'importe quoi (genre laisser ce code, et copier en dessous des codes de l'ancien fichier, résultant en deux exécutions de la même chose), ou bien ne sachent simplement pas quoi faire avec ce code présent et n'osent plus toucher au fichier.
od†n ↗blah 23 février 2024 à 07:29 (CET)[répondre]
Pour la liste des contributeurs à traiter pour la première salve, une requête SQL au résultat formatée devrait convenir. Sinon, au final sur le ticket la WMF propose de s'en occuper... Je leur ai demandé ce qu'il pensait d'un massedit, cela n'a pas l'air d'enchanter. Pour être franc je ne comprends pas pourquoi ils n'ont pas traité le sujet eux-mêmes, un peu trop frileux pour pas grand chose, c'est littéralement leur rôle d'opérer MediaWiki... Lofhi (discuter) 23 février 2024 à 07:58 (CET)[répondre]
ça marche sur des oeufs quand il s'agit de modifier les contenus des wikis communautaires, trop de risques de fâcher la communauté, ça a pu mal se passer dans le passé.TomT0m [bla] 23 février 2024 à 10:00 (CET)[répondre]
Note en passant : en recherchant les vector.js et vector.css existants, penser à exclure les pages vides (i.e. pages blanchies, 0 octet). Cela peut faire qu'il n'y a rien à copier pour l'utilisateur, et même qu'il n'y a pas lieu de lui poster un message si en fait il n'a rien à copier. En reprenant la recherche indiquée plus haut pour les vector.js, sur les 922 résultats il y a quand même 192 pages vides. od†n ↗blah 23 février 2024 à 17:34 (CET)[répondre]
Liste des vector.js et vector.css existants pour les contributeurs actifs sous les 6 derniers mois : https://superset.wmcloud.org/sqllab/?savedQueryId=81. Dommage qu'on n'ait pas à accès à user_touched pour des raisons évidentes : the last time a user logged in (not just mere visiting using an existing session), modified user settings, or got promoted into new user groups. Cela rallonge vachement le temps d'exécution. Aussi la colonne arbitaire redirect ne sert pas à grand chose bizarrement : les contributeurs qui se sont renommés sont tous inactifs ces six derniers mois ? Lofhi (discuter) 23 février 2024 à 19:41 (CET)[répondre]
Bonjour. Questions et remarques en vrac, par curiosité.
Y a-t-il moyen de savoir qui utilise quel habillage ? Je ne crois pas mais sait-on jamais. Si quelqu'un est "définitivement" passé au vector-2022, est-ce que la page vector.js lui sera encore utile ? Plutôt que de créer de nouvelles pages, est-il possible d'envisager des renommages sans création de redirection depuis l'ancien nom. Avantages : limitation du nombre de nouvelles pages, conservation de l'historique. Les .js (et .css) sont-ils compatibles ? Inversement, un utilisateur continuant volontairement d'utiliser la version 2010 de l'habillage n'a pas besoin d'une sous-page vector-2022.js.
Il y a quatre pages /Vector.js (avec majuscule) dont un vide et un étant une redirection. Ces titres sont-ils valides pour MediaWiki ? Il y a aussi dans les résultats de vos recherches internes ci-dessus un intrus en « /articlebox vector.js » et des sous pages « /vector.js/CopyScape.js » (×2) et « /vector.js/signature.js » (et un « /lrc-vector.css », un « /old vector.css » et un « /vector.css&action=edit », ce dernier étant à supprimer). Et deux redirections /vector.js (vers /commons.js pour l'une, vers /vector-2022.js pour l'autre). Cette opération donne l'occasion de vérifier que chacune de ces pages correspond à un compte existant (possible coquille lors de la création ou oubli lors d'un renommage de compte).
La limitation aux comptes actifs au cours des six derniers mois est une bonne chose. En ce qui concerne le contenu vide, il y a vide (0 octets) et vide (commentaires uniquement, exemple rencontré : /* empty */)
Le message en amont aux utilisateurs concernés pourrait en inciter à actualiser leurs fichiers de personnalisation ou à blanchir ceux qu'ils n'utilisent plus, réduisant le besoin.
Remarque plus générale sur l'action automatisé envisagée. Dans une optique différente (autonomie), on peut aussi se dire que les contributeurs ayant créé leur vector.js ou vector.css seront capables de générer les versions 2022, si "par malheur" ils auraient cliqué sur le bouton « Annuler » lors de l'ouverture du script suggéré. Surtout s'ils ont reçu un message explicatif sur leur page de discussion. Avec ces deux éléments, les doléances devraient être limitées. — Ideawipik (discuter) 23 février 2024 à 21:04 (CET)[répondre]
J'ai regardé rapidement : SELECT DISTINCT(up_property) FROM user_properties; retourne :
+-------------+ | up_property | +-------------+ | disablemail | | fancysig    | | gender      | | nickname    | +-------------+ 
Seules personnes accréditées peuvent avoir accès au reste des propriétés définies par chaque contributeur : mw:Manual:user_properties table. Lofhi (discuter) 23 février 2024 à 21:19 (CET)[répondre]
Plus j'y réfléchis, et plus encore après avoir considéré certains des points que Ideawipik a répertoriés (et merci pour ce travail), je commence à me dire qu'on devrait seulement envoyer des messages aux utilisateurs, et basta. Parce qu'il y a quand même pas mal de cas où la "copie automatique" pourrait faire plus de mal que de bien. Et pour ne pas envoyer des messages inutilement à certains utilisateurs, il faudrait effectivement aussi "exclure" les fichiers ne contenant que des commentaires. od†n ↗blah 23 février 2024 à 23:22 (CET)[répondre]
Apparemment, le changement a eu lieu, frwiki étant dans la catégorie des projets avec moins de 50 de script utilisateurs (31 d'après le google sheets, cf. phab:T301212). Ça me surprend au vu des discussions ci-dessus.
J'ai copié MediaWiki:Vector.css dans MediaWiki:Vector-2022.css. Escargot (discuter) 20 mars 2024 à 12:38 (CET)[répondre]
Ce nombre est effectivement incorrect (il correspond aux "Vector.js", etc. nommés à tort avec une majuscule, ce qui ne fonctionne pas ; voir cette recherche). À un moment jdlrobson avait confondu les capitalisations "Vector.js" et "vector.js" (en même temps, cette confusion peut se comprendre…) ; je l'en ai informé, il a corrigé les liens du post juste au-dessus, mais l'erreur est restée dans la spreadsheet dans le premier post, et surtout c'est le nombre erroné qui a continué d'être pris en compte. Autrement dit, l'erreur n'avait été corrigée que superficiellement. Encore une "correction partielle" du grand jdlrobson quoi… od†n ↗blah 20 mars 2024 à 14:50 (CET)[répondre]
Je préparerai pour la fin de semaine un message que je transmettrai aux administrateurs pour qu'ils puissent l'envoyer en masse si personne ne compte le faire... puisque c'est déjà acté. Lofhi (discuter) 20 mars 2024 à 21:56 (CET)[répondre]
Alors, pour le message, sans les sauts de ligne, pour relecture.
Sujet : Des changements récents concernant l'habillage Vector peuvent vous concerner
Message :
Depuis l'été dernier, Vector 2022 est l'habillage utilisé par défaut pour les nouveaux contributeurs inscrits et pour les lecteurs non inscrits. Il s'agit de la deuxième évolution de l'habillage Vector de MediaWiki dans le cadre du projet d'amélioration de la navigation sur bureau. Cette deuxième évolution peut être activée dans les préférences d'utilisateur.
Si vous n'avez pas manuellement basculé sur Vector 2022, vous utilisez encore la première version de Vector, à présent nommée Vector 2010. Vous n'êtes pas concerné par ces changements.
Si vous avez basculé sur Vector 2022, des changements récents peuvent avoir entravé votre flux de travail et désactivé vos personnalisations personnelles de l'interface.
En effet, lors du développement de Vector 2022, afin de faciliter la transition auprès de la communauté, le CSS et JavaScript personnalisé d'un contributeur utilisé pour Vector 2010 était aussi exécuté lors de l'utilisation de Vector 2022.
Depuis le 18 mars 2024, la scission entre les deux versions de Vector a été définitivement actée. Cela implique que si vous utilisez Vector 2022, vos personnalisations de Vector 2010 qui étaient aussi chargées ne le sont plus.
Le nombre de pages personnelles et la diversité des personnalisations étant conséquents, les administrateurs d'interface ont préféré décider que les corrections soient réalisées par les contributeurs concernés, car il n'est pas possible de généraliser facilement la correction sans garantir de ne pas causer d'autres problèmes.
La correction proposée est de renommer vos pages personnelles si vous avez délaissé Vector 2010 au profit de Vector 2022. Ainsi, votre vector.js doit être renommé en vector-2022.js. Aussi, votre vector.css doit être nommé vector-2022.css
En cas de problème, vous pouvez demander de l'aide au Projet:Scripts et gadgets. Lofhi (discuter) 24 mars 2024 à 22:06 (CET)[répondre]

Gadgets activés sur mobile[modifier le code]

Pour info, all of a sudden, tous les gadgets activés pour l'utilisateur sur desktop (que ce soit les gadgets activés par défaut, ou ceux qu'il a lui-même activés), dont désormais aussi activés sur mobile, là où auparavant seulement quelques-uns y étaient activés (ceux contenant la target "mobile").

Refs :

La partie la plus stupide, c'est qu'il n'y a plus vraiment de possibilité pour qu'un gadget soit activé seulement sur desktop et pas sur mobile.

od†n ↗blah 24 février 2024 à 04:23 (CET)[répondre]

Des alternatives sont proposées : mw:ResourceLoader/Migration guide for extension developers. Lofhi (discuter) 23 mars 2024 à 19:53 (CET)[répondre]
J'ai l'impression qu'il n'y a rien là-dedans qui réponde à la présente problématique. Du coup, il faut vérifier tous les gadgets pour s'assurer qu'ils ne plantent pas sur mobile. Par exemple, sur mobile mw.util.addPortletLink() ne crée pas de portlet, et du coup ne retourne pas d'élément ; donc ça plante si on utilise la valeur retournée par la fonction sans vérifier qu'elle contient un élément. De plus, de nombreux gadgets sont inadéquats sur mobile et sont maintenant chargés inutilement. Pour une fois qu'on avait quelque chose de convenable, à savoir le système de targets, ben ils le suppriment avec des justifications plutôt floues. Et c'est marrant quand ils parlent de performances, alors que ce sont eux qui ajoutent du JavaScript par centaines de kibioctets, et qui font des changements qui rendent souvent les choses moins flexibles. od†n ↗blah 24 mars 2024 à 02:52 (CET)[répondre]
La version mobile web utilise l'habillage Minerva Neue. Les scripts qui ne fonctionnaient pas déjà sur mobile ne fonctionneront pas sur ce skin. Ce n'est pas acceptable d'exclure l'exécution d'un gadget sur un habillage à l'aide de l'option skins (voir mw:Extension:Gadgets) ? Chose où je suis ignorant : l'impact côté applications mobiles. Je n'ai jamais cherché à savoir ce qui était chargé et comment. Lofhi (discuter) 24 mars 2024 à 14:20 (CET)[répondre]
On ne peut pas exclure une skin en particulier avec cette option. On pourrait seulement lister toutes les skins sauf la Minerva, évidemment cette solution n'est pas acceptable. La seule solution possible serait de passer tous les gadgets en revue, et d'ajouter des « if skin == minerva then return » à chaque fois que nécessaire ; évidemment c'est très lourdingue. Autrement dit, pour l'activation des gadgets sur mobile on est passé d'un comportement "opt-in" à un comportement "opt-out" (de surcroît pénible à effectuer) ; le comportement "opt-in" était évidemment beaucoup plus adéquat. Enfin voilà, ils nous bassinent avec les performances sur mobile, et là ils se tirent une balle dans le pied (j'ai une autre expression mais je ne peux pas la poster ici) avec ce genre de changement contre-productif au plus haut point.
De plus :
  • Et si une autre skin mobile venait à être ajoutée, faut tout répéter ?
    • à propos, j'ai regardé mw.config.get(), et les classes présentes dans le <head> et le <body>. Il n'y a rien qui permette de simplement déterminer si on est sur mobile ou non. Tout ce que j'ai trouvé ce sont des codes un peu détournés tels que « if document.getElementById('mw-mf-viewport') » ou encore « mw.config.get('wgMFMobileFormatterHeadings') ». Edit : voir T248416#9655908 et T299772, la classe est "mw-mf" sur le <body>, mais sérieux voilà le nom de la classe quoi.
  • Ça ne va pas encore pas arranger l'histoire de la skin Minerva qui est aussi activable sur desktop. Il y a moult différences sournoises entre Minerva sur desktop et Minerva sur mobile, qui fait que tout en étant fortement mélangées, on ne peut pas les considérer comme équivalentes. Par exemple, dans ce cas il n'y a pas la classe "mw-mf".
  • J'ai l'impression qu'ils sont train de considérer qu'il n'y a pas deux modes "desktop" et "mobile", et que Minerva === mobile ; avec tous les problèmes que cela entraîne. Dans ce cas il faut être cohérent jusqu'au bout, et Minerva sur desktop ne devrait plus charger les Common.css/js, par exemple.
od†n ↗blah 24 mars 2024 à 20:00 (CET)[répondre]
Oui, ça m'a toujours un peu dérangé que Minerva soit présent sur les deux versants... Ce n'est pas très adapté à l'édition sur clavier/souris, ni sur l'édition avec un écran tactile, d'où l'enrichissement de Minerva côté web mobile avec mw:Extension:MobileFrontend. Que Timeless, Monobook et compagnie subsistent n'est pas un problème, mais qu'un habillage soit utilisé sur deux versions différentes alors que la version web mobile était un souhait de proposer quelque chose de fondamental différent de la version bureau, c'est bizarre. Impossible de savoir s'il y a bien quelqu'un qui utilise Minerva sur la version bureau non plus. Moi je pensais à désactiver sur Minerva puis éventuellement entendre les commentaires de contributeurs qui sont dérangés par cette modification sur bureau s'ils existent. C'est la seule option pour ne pas charger le code côté mobile.
La solution finale et parfaite, comme d'habitude, c'est de retaper entièrement les gadgets pour utiliser les interfaces intermédiaires afin de toucher aux interfaces : core(s) ou Codex depuis peu. Autant dire encore beaucoup de boulot... mais ça fonctionnerait qu'importe la version utilisée. Je ne vais pas le notifier, car j'ai promis de le prévenir seulement quand tout est stable, mais 0x010C est prêt à migrer ses gadgets sous Codex.
Note : je sais qu'à l'époque vérifier si ontouchstart était un événement attaché à la fenêtre était assez fiable. Avec les medias queries, on pourrait peut-être passer par @media/pointer. Ce n'est pas beau, mais ça a l'air suffisant.
Double note : il ne faut absolument pas s'appuyer sur MobileFrontend à l'avenir. Encore une fois, Codex prend la relève, voir T281930. Lofhi (discuter) 24 mars 2024 à 20:53 (CET)[répondre]
  • Le problème avec des détections comme "ontouchstart" au niveau du navigateur, c'est qu'on peut consulter la version desktop avec un navigateur mobile, et inversement, la version mobile avec un navigateur desktop. Et de toute façon, ça me paraît risqué de détecter ailleurs qu'au niveau du choix effectué par MediaWiki.
  • Tu fais bien de rappeler l'existence de l'extension MobileFrontend. C'est effectivement en grande partie cela qui fait que Minerva est différent sur desktop et sur mobile (ça, et la différence de chargement Common/Mobile.css, idem js).
  • Ça me rappelle aussi qu'il est possible de consulter la version mobile avec d'autres skins que Minerva. Et qui du coup se voient appliquer la "surcouche" MobileFrontend. J'ai regardé vite fait avec Vector classique et Vector 2022. Alors déjà, Vector classique n'est pas responsive alors autant utiliser la version desktop ; et Vector 2022 est effectivement responsive. Et j'ai rapidement remarqué des problèmes d'affichage assez manifestes, introduits par la surcouche MobileFrontend, qui me font penser que l'utilisation sur mobile de skins autres que Minerva doit être peu courante, et surtout peu supportée. Au final, on a un couplage fort « version mobile === Minerva (+ MobileFrontend) », vu que les autres combinaisons (Minerva sur desktop, autres skins sur mobile) fonctionnent mal, sont peu répandues et peu supportées. Pas forcément un problème, mais dans ce cas faudrait prendre acte de ce couplage fort, surtout que ça a l'air vraiment mal parti pour supporter les autres combinaisons.
  • Vu T281930. Ça promet encore beaucoup de joyeusetés. J'ai bien aimé le coup de la librairie WVUI dépréciée avant même d'avoir été utilisée.
od†n ↗blah 25 mars 2024 à 04:49 (CET)[répondre]
  • Si on consulte la version bureau avec un navigateur mobile, le script ne doit pas être lancé puisque ontouchstart détecté, non (le média pointer me semble bien sinon) ? Cela me semble être la seule alternative valable à utiliser parallèlement avec l'option skins. C'est crade, mais on sait très bien pourquoi : la WMF ne veut plus des gadgets qui excluent la version mobile. Assez violente manière de partager le message, mais bon... ;
  • Personnellement avec la version mobile, je vois que la possibilité utiliser Minerva. Je ne sais pas comment tu as activé les autres apparences. J'ai vu des paramètres avancés, mais sans conséquences. Il faut aussi se rappeler que les lecteurs non-inscrits utilisent soit Minerva avec la version mobile, soit les applications mobiles et c'est à peu près tout. Les autres cas me semblent très subsidiaires... pour ne pas dire inattendus et peu souhaitables ;
  • Pour WVUI, je pense que la bibliothèque n'avait pas vocation à être utilisée par d'autres personnes que la WMF, là où Codex devrait pouvoir être utilisé un peu partout comme on on veut (MediaWiki, dans les gadgets en supportant .vue, peut-être directement dans le wikicode [je fais de la propagande auprès de la WMF depuis trois mois], mais aussi comme dépendance d'un projet externe qui n'aurait même pas de lien avec MediaWiki).
Lofhi (discuter) 27 mars 2024 à 22:40 (CET)[répondre]

Xdone et demandes de déblocage[modifier le code]

Bonjour,

Aujourd'hui, Wikipédia:Demande de déblocage a été mise en place et le préchargement ne comporte pas de modèle de fin. Cela fait suite à une demande visant à rendre la page compatible avec les outils de discussion. Actuellement, « Utilisateur:Arkanosis/xdone.js » ne semble pas être compatible avec cette approche. J'aimerais de l'aide pour le rendre fonctionnel sur cette page. Je notifie @Od1n qui semble être le principal contributeur de cet outil depuis quelques années.

Amicalement. SleaY [contacter] 25 mars 2024 à 20:53 (CET)[répondre]

J'ai tenté une Regex. à voir si elle fonctionne correctement, ce dont je ne suis pas convaincu. Escargot (discuter) 25 mars 2024 à 21:59 (CET)[répondre]
@Escargot bleu Je confirme que ça ne fonctionne pas. Le bouton « marquer comme traité » est visible, mais cliquer dessus ne fait qu'actualiser la page sans rien modifier. SleaY [contacter] 25 mars 2024 à 23:07 (CET)[répondre]
Je me suis un peu penché là-dessus. J'aurais une suggestion, ça serait de créer un modèle {{Requête admin/standalone}}, qui reprendrait {{Requête admin/début}}, en ajoutant le </div> de fermeture, en supprimant la ligne <hr />, et en supprimant le padding inférieur de 0.5em. od†n ↗blah 26 mars 2024 à 08:46 (CET)[répondre]
Aussi, le système que j'ai publié poste le message « {{Fait}} ~~~~ » au niveau d'indentation suivant de la conversation, mais j'ai ensuite remarqué que le code déjà existant pour les autres requêtes, poste le message toujours avec une indentation de niveau 1. Je me dis qu'effectivement ça serait peut-être préférable, pour l'harmonisation des requêtes (comme ça les réponses de clôture sont toutes au même niveau). Edit : quoique à la réflexion, pas sûr que cela conduise à une plus grande harmonie, dans la mesure où les requêtes sont loin d'être toutes closes en utilisant xdone. od†n ↗blah 26 mars 2024 à 08:58 (CET)[répondre]

Fiabilité et suivi centralisé des modifications des scripts[modifier le code]

Bonjour, j'avais l'intention de proposer cette idée plus tard dans l'année vu le calendrier, mais finalement, mes récentes interventions techniques se heurtent toutes à des consensus puérils. Je pense donc laisser la main à la WMF qui va sûrement tout écraser de son côté dans les semaines à venir pour l'implémentation du mode nuit. Cela signifie que nous devrons probablement faire face à des difficultés au long terme pour suivre les modifications sur le projet et sur Gerrit, donc perdre une partie du contrôle, mais passons...

J'ai pensé le mois dernier à externaliser le développement et la maintenance des gadgets et des feuilles de styles. C'est très compliqué de suivre les historiques, de comprendre qui s'est passé, d'organiser les tâches, d'avoir un IDE adapté, de références des lignes de code, de demander des relectures et commentaires, etc. Parfois il faut aussi toucher à plusieurs pages en même temps, c'est plus compliqué d'avoir toutes les modifications en même temps... que dans un seul commit !

M'est venu l'idée donc de transformer nos pages dans l'espace de nom MediaWiki comme des simples miroir d'un dépôt git que nous pourrions héberger sur gitlab.wikimedia.org. Tout le travail serait concentré sur GitLab et une fois les modifications approuvées par un administrateur d'interface, un bot publierait les modifications automatiquement sur les pages concernées.

Cela me semble un bon moyen de fiabiliser le sujet sensible que sont les gadgets. Plus facile de retrouver les discussions liées ; de linter, etc. Bon, il y aurait de quoi rêver en générant même des tests wiki par merge request, mais cela me semble peut-être trop poussé.

J'en ai discuté un peu avec l'équipe qui s'occupe des Wikimedia Cloud Services ; ils seraient ravis de nous accompagner dans les limites de leurs disponibilités (leur budget est limité...). Cependant, vu que la migration vers Gitlab est actée depuis des années, on peut imaginer que la plateforme sera mise sous les projecteurs et qu'on ne devrait pas être dans une situation instable.

Des avis ? Lofhi (discuter) 27 mars 2024 à 22:16 (CET)[répondre]