Discussion Projet:Scripts et gadgets

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.

Archives

2006-2007, 2008-2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022

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

• Si vous souhaitez signaler un bug, utiliser la page de rapport de bug.
• Si vous souhaitez demander une fonction qui ne se trouve pas dans la liste des fonctions disponibles, utilisez la page de demande de fonction.
• Pour tout autre demande, vous êtes au bon endroit.

Personnaliser l'interface

Données clés

Aide • Exemples

Fonctions avancées

Apparence Vector

Apparence Timeless

Projet:Scripts et gadgets

(en) User styles

CSS

common.css personnel

Common.css commun

Monobook.css commun

Vector.css commun

(en) Catalogue of classes

Index des propriétés CSS2

JavaScript

common.js personnel

Common.js commun

Fonctions JavaScript

Cliquez ici pour purger le cache

Breaking change dans les scripts utilisateur

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)

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)

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)

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)

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)

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)

Ç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)

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)

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)

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)

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)

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)

ç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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

Gadgets activés sur mobile

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 :

• 212745974 dans MediaWiki:Gadgets-definition
• 6383230 dans les options des gadgets
• T340802
• T328610

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)

Des alternatives sont proposées : mw:ResourceLoader/Migration guide for extension developers. Lofhi (discuter) 23 mars 2024 à 19:53 (CET)

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)

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)

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)

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)

• 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)

• 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)

Xdone et demandes de déblocage

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)

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)

@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)

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)

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)

Fiabilité et suivi centralisé des modifications des scripts

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)

Bof… De tout ce que j'ai vu en "codes centralisés" sur les wikis, ça a toujours eu très vite fait de se retrouver à "forker" localement. Un exemple récent est Adiutor, et c'est aussi le cas avec divers gadgets, modules, etc. centralisés sur Meta.

L'idée de départ est bonne (par exemple la possibilité de regrouper plusieurs fichiers dans un commmit serait intéressante), mais en pratique, pour modifier une version locale il y a juste à faire deux clics, alors que pour modifier une version centralisée, il peut y avoir de nouvelles plates-formes à prendre en main, ou alors devoir quémander les modifications (rédiger trois paragraphes de justification, puis attendre six mois, puis se retaper une navette d'une demi-douzaine de messages à en fait réexpliquer la même chose, tout ça pour modifier deux lignes… et le pire c'est que je n'exagère même pas).

od†n ↗^blah 1 avril 2024 à 00:41 (CEST)

Mise à jour des outils pour l'arrivée des comptes temporaires

Hello,

Je vous partage cette annonce récente de la WMF : mediawikiwiki:Trust and Safety Product/Temporary Accounts/For developers/2024-04 CTA. Elle concerne le futur (pas encore de date) déploiement des comptes temporaires (cf. page projet sur notre wiki), en remplacement de l'identification par IP.

Un mode d'emploi pour la mise à jour du code des outils est disponible ici.

Il faudrait commencer à recenser les outils qui seront affectés sur notre wiki (aide). Je suis loin d'être un expert, mais je commence une liste ci-dessous et compte sur vous pour la compléter. Il y aura aussi des outils/gadgets pour lesquels une mise à jour des modèles d'avertissement sera nécessaire : cf. là. — Jules* ^discuter 5 avril 2024 à 22:31 (CEST)

Liste des outils à mettre à jour

• LiveRC (pas le moins important des outils)
• Salebot
• WP:Adiutor
• MediaWiki:Gadget-DeluxeHistory.js
• MediaWiki:Gadget-0xBlockMessage.js (?)
• MediaWiki:Gadget-PaStec.js (avertissement envoyé à l'ouverture d'un débat)

Je n'ai pas l'impression qu'il y ait énormément de choses à changer. Au lieu de se demander si un utilisateur est enregistré, il faudra se demander s'il est anonyme. Et ensuite, il faudra juste changer le texte affiché pour être cohérent. Escargot (discuter) 5 avril 2024 à 23:13 (CEST)

Zotero

Bonjour,

Suite à cette discussion (#Automatisation ...), je suggère cette idée : adapter le template Zotero aux modèles francophones (Article, Livre, Chapitre, ...).

Concrètement, il existe ce script qui permet de convertir les métadonnées d'une source à un format wikicode, sauf que c'est le style de WP en anglais...

Avec cette documentation, il serait possible d'établir des règles adaptées à Article, Livre, Chapitre, ...

Certes, c'est un script externe mais ça reste très pratique pour enrichir les articles. LD (d) 11 avril 2024 à 23:56 (CEST)

Bonjour LD. Ce serait très utile . J'ai adopté Zotéro récemment et ai été déçu de ne pas pouvoir exporter automatiquement les sources sur WP avec les modèles qui vont bien. — Jules* ^discuter 12 avril 2024 à 00:04 (CEST)

Ou sinon d'utiliser la procédure qui permet de créer des éléments Wikidata pour les références. Le modèle approprié est choisi par {{Bibliographie}} automatiquement. — TomT0m ^[bla] 12 avril 2024 à 10:11 (CEST)

J'avais discuté sur Discord pour créer un site web communautaire qui pour une adresse URL générerait un format de sortie (mediawiki, mediawiki-basefields, zotero, bibtex, ou wikibase) ; voir l'API. Il me semble en lisant cette section, les modifications qui seraient apportées bénéficieront peut-être directement à Citoïd, le service qui formatte automatiquement les sources avec l'éditeur visuel. C'est à prendre avec des pincettes, je n'ai pas creusé, mais on peut lire : « mediawiki: format designed for MediaWiki to be used with templateData. Uses Zotero field names. ». Lofhi (discuter) 15 avril 2024 à 00:49 (CEST)

API pour les gadgets afin d'ajouter des boutons aux titres de section

Voir T337286. « [...] we think it would mitigate various problems we'll see in MobileFrontend and will soften the blow of gadgets breaking (which often web team is blamed for). MobileFrontend will likely change the HTML format further to support section collapsing for example so having a stable API seems like a good thing for both our teams on the long run. ». Lofhi (discuter) 22 avril 2024 à 18:57 (CEST)