Discussion Projet:Scripts et gadgets

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
(Redirigé depuis Discussion Projet:JavaScript)
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.


Aide Aide • Exemples
Aide Fonctions avancées
Aide Apparence Vector
Aide Apparence Timeless
Projet Projet:Scripts et gadgets
Wikimedia (en) User styles
CSS
page perso. common.css personnel
espace MediaWiki Common.css commun
espace MediaWiki Monobook.css commun
espace MediaWiki Vector.css commun
(en) Catalogue of classes
Index des propriétés CSS2
JavaScript
page perso. common.js personnel
MediaWiki Common.js commun
Catégories Fonctions JavaScript
Cliquez ici pour purger le cache

modifier Consultez la documentation du modèle

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]

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]

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)[répondre]

Mise à jour des outils pour l'arrivée des comptes temporaires[modifier le code]

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)[répondre]

Liste des outils à mettre à jour[modifier le code]

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)[répondre]

Zotero[modifier le code]

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)[répondre]

Bonjour LD. Ce serait très utile Émoticône. 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)[répondre]
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)[répondre]
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)[répondre]

API pour les gadgets afin d'ajouter des boutons aux titres de section[modifier le code]

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)[répondre]

Demande du statut d’administrateur d’interface[modifier le code]

Bonjour, je l’ai annoncé ailleurs, parce qu’il était de bon ton de le faire, mais il me semble bien de le faire ici aussi. Donc j’annonce que j’ai demandé le statut d’administrateur d’interface pour pouvoir participer au développement et à la maintenance des gadgets. Bonne journée, Lepticed7 (Viens tcharer ! :D) 17 mai 2024 à 11:46 (CEST)[répondre]

Template gadgets[modifier le code]

Bonjour,

Depuis phab:T204201#9559072 il est possible de restreindre l'activation de gadgets aux pages dans une certaine catégorie, ce qui permet de faire des mw:Template gadgets : du code javascript qui ne s'active que lorsqu'un certain modèle est présent dans la page (le modèle doit juste ajouter une catégorie). Cela fonctionne car les gadgets activés par défaut sont aussi activés pour les IPs.

Beaucoup de code dans MediaWiki:Common.js a précisément pour rôle de ne s'activer que lorsqu'un modèle précis est présent : Modèle:Titre incorrect, Modèle:Sous-titre, Modèle:Méta palette de navigation, Modèle:Boîte déroulante, Modèle:Animation, Modèle:Aide contextuelle et indirectement Modèle:Édition et Modèle:Page de discussion. On pourrait déplacer ce code dans des gadgets dédiés pour alléger la taille du fichier js livré par défaut à tous les visiteurs.

Liens utiles :

Escargot (discuter) 4 juin 2024 à 18:14 (CEST)[répondre]

C'est effectivement intéressant. Une petite mise en garde au sujet de Modèle:Page de discussion (la classe "transformeEnPageDeDiscussion"), vu que tu l'as mentionné : dans le MediaWiki:Common.js il y a tout un code lourdingue où l'on teste sur le nom de la page pour déterminer si la page est à "transformer", plutôt que de se baser sur la présence du modèle. Ceci permet d'appliquer la transformation aussi lorsque l'on modifie une section (et non la page entière), car dans ce cas le modèle ne peut pas être détecté. C'est un code que je n'aime franchement pas, en raison de cette grosse liste de pages qui se trouve dans le code, mais je ne vois vraiment pas d'autre solution. od†n ↗blah 4 juin 2024 à 20:36 (CEST)[répondre]
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Discussion_Projet:Scripts_et_gadgets&oldid=215686146 ».