Aller au contenu

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 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.


Template gadgets

[modifier le code]
Enregistré sur Phabricator
Tâche 204201
Enregistré sur Phabricator
Tâche 63007
Ne pas archiver.

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]
Le passage de ns-subject à ns-talk n'est pas suffisant pour faire fonctionner les outils de discussion (activés par défaut sur mobile et en beta sur bureau). Il faut obligatoirement que le mot magique __NEWSECTIONLINK__ soit présent, éventuellement en combinaison avec __NONEWSECTIONLINK__ si on veut désactiver le bouton « Ajouter un sujet ».
En considérant que ce mot magique sera forcément présent sur les pages qu'on veut changer en page de discussion (et qu'il sera absent sinon), il y a peut-être moyen de le détecter et d'utiliser ça pour déterminer que ns-subject doit être remplacé par ns-talk (même si je n'ai pas trouvé comment). Escargot (discuter) 7 juin 2024 à 21:40 (CEST)[répondre]
J'ai fait le changement en question pour MediaWiki:Gadget-Diaporama.js qui charge maintenant avec la catégorie Catégorie:Page utilisant le modèle Animation.
Le modèle fonctionne correctement en prévisualisation, y compris pour une section, mais pas avec l'aperçu rapide, même avec la page complète, ni avec l'éditeur visuel.
Je ne reviens pas en arrière sur mon changement qui permet quand même de faire fonctionner le modèle sur mobile. Escargot (discuter) 9 juin 2024 à 13:12 (CEST)[répondre]

Adaptation de Pastec à un nouveau modèle

[modifier le code]

Bonjour,

Un nouveau modèle d'en-tête pour les DdA a été proposé dans le but de rendre les informations plus lisibles sur ces pages. Ce modèle a la particularité de changer d'apparence selon les différentes étapes de la procédure et prend en charge la conclusion des DdA. Voir les exemples d'utilisation.

Pour prendre en compte ces modifications, Pastec devra modifier les paramètres de l'en-tête lors des clôtures, plutôt qu'ajouter un bandeau de clôture. À noter qu'une période de transition est à prévoir, pendant laquelle les nouvelles procédures utiliseront le nouveau modèle, tandis que les DdA déjà existantes continueront à utiliser l'ancien.

Est-ce faisable ?

Amicalement. SleaY [contacter] 21 juin 2024 à 17:10 (CEST)[répondre]

Bonjour
La documentation détaillée du modèle est à présent à jour.
Merci pour votre aide, Trizek bla 26 juin 2024 à 20:23 (CEST)[répondre]

Paramètres des gadgets

[modifier le code]

Bonjour,

Je voudrais simplifier l'utilisation des paramètres des gadgets PaStec, Evaluation, ResumeDeluxe et peut-être HotCatsMulti. Actuellement, ces gadgets sont paramétrés depuis le common.js, ce qui n'a rien d'évident pour un certain nombre d'utilisateurs, et implique en plus de lire avec attention la notice pour les trouver dans le cas de PaStec.

Les paramètres de gadgets peuvent être enregistrés depuis les préférences utilisateur. @0x010C a créé en 2019 MediaWiki:Gadget-GadgetsPreferences.js pour permettre de le faire simplement (discussions associées : 1 et 2), dont la seule utilisation actuelle est dans Utilisateur:Arkanosis/xdone.js. GadgetsPreferences utilise la page MediaWiki:Préférences des Gadgets, sur laquelle sont réglés les paramètres, et on y accède depuis le menu déroulant en haut à droite.

Je connais deux autres manières utilisées pour le réglage de préférences de gadgets : le gadget CustomSidebar paramétré en cliquant sur un petit engrenage et qui ouvre un widget ; le gadget Adiutor dont le lien vers les options est inclus dans la liste déroulante des actions ajoutées par le gadget et dont les options sont aussi sous la forme d'un widget surgissant.

Ma question porte sur l'emplacement le plus approprié pour le paramétrage des gadgets que j'ai cités. Le plus agréable à utiliser côté utilisateur est à mon avis un widget surgissant, plutôt qu'une page à part comme MediaWiki:Préférences des Gadgets (qui a en plus l'inconvénient de ne pas être dans les espaces de nom pour lesquels ces gadgets sont activés). Mais un widget surgissant en cliquant sur le menu déroulant utilisateur me perturbe.

Escargot (discuter) 31 octobre 2024 à 20:57 (CET)[répondre]

Dans tous les cas, il faut que l'espace de nom courant n'affecte pas la possibilité d'accéder aux préférences des gadgets. Donc les paramètres de gadgets doivent à mon avis être contrôlés par un gadget autre, éventuellement GadgetsPreferences.js. Escargot (discuter) 1 novembre 2024 à 07:48 (CET)[répondre]
@Escargot bleu : Pour PaStec, c'est assez facile, sauf pour window.PaStec_WLH_BLDefaultNamespaces et window.PaStec_WLH_IUDefaultNamespaces mais ces options ne sont pas utilisées (cf. [1] et [2]) et on peut probablement s'en débarrasser.
Pour HotCats, ResumeDeluxe et Evaluation, c'est plus délicat :
  • Pour Evaluation, le plus approprié serait OO.ui.TagMultiselectWidget, mais GadgetsPreferences.js ne le supporte pas encore ;
  • Pour HotCatsMulti, j'ai trouvé 4 utilisateurs encore actifs utilisant les options (cf. cette recherche) ;
  • Pour ResumeDeluxe, OO.ui.MenuTagMultiselectWidget me semble être le plus pratique : on pourrait fusionner window.ResumeDeluxe_affiches et window.ResumeDeluxe_liens. Toutefois, les structures du type ['homonymie', 'création homonymie'] nécessiteraient certaines adaptations.
DreZhsh Discuter 1 novembre 2024 à 15:36 (CET)[répondre]
Merci pour l'avis et pour avoir pris le temps de fouiller.
J'essayerai d'ajouter le support de OO.ui.TagMultiselectWidget à GadgetsPreferences.js puisque ça semble effectivement pertinent.
Pour la faible utilisation des personnalisations de HotCatsMulti, je me demande si c'est parce qu'elles sont réellement peu utiles en pratique ou simplement parce que les gens ne savent pas qu'elles existent. Contrairement à ResumeDeluxe qui n'a pas d'intérêt sans personnalisation dans le common.js et Evaluation pour lequel ça a longtemps été plus ou moins la même chose, HotCatsMulti fonctionne très bien sans personnalisation. Escargot (discuter) 1 novembre 2024 à 18:51 (CET)[répondre]
Un élément à prendre en compte avec OO.ui.TagMultiselectWidget, c'est que sa méthode .getValue() retourne un tableau si plusieurs éléments son indiqués. Avec mw.Api().saveOption(), il faut utiliser JSON.stringify() sur le tableau à enregistrer, et lorsque l'on récupère les options, utiliser JSON.parse(). Dans le cas contraire, il va être transformé en chaîne avec String() (cf. [3]), ce qui pourrait causer des problèmes si l'une des chaînes du tableau contient une virgule. ─ DreZhsh Discuter 2 novembre 2024 à 09:22 (CET)[répondre]

Boutons d'avertissement ne fonctionnant pas avec les Outils de discussion

[modifier le code]

Bonjour, est-il possible d'actualiser les boutons d'avertissements — boutons « Faut sourcer » ou « Test 1 » à droite des liens (Annuler / Message) (Révoquer / Message) sur une page de différence de diff d'un article —, qui ne fonctionnent pas avec les Outils de discussion (Préférences > Fonctionnalités bêta) ?

Merci de votre aide et bien à vous. @Jules* et @Arcyon37 pour information. Harrieta171 (discussion) 7 novembre 2024 à 18:55 (CET)[répondre]

Pour préciser la demande d'Harrieta171, ce sont les boutons fournis par le gadget MediaWiki:Gadget-RevertDiff.js. — Jules* discuter 7 novembre 2024 à 18:59 (CET)[répondre]
Ping @Od1n et @Arkanosis, pour info. — Jules* discuter 7 novembre 2024 à 19:16 (CET)[répondre]
Il doit s'agir de la problématique déjà signalée sur Wikipédia:Bulletin des administrateurs/2023/Semaine 23#Problème technique ainsi que Projet:Modèle/Demandes#Faut sourcer - Test 1 - Test 2, Bienvenue, etc. od†n ↗blah 7 novembre 2024 à 21:27 (CET)[répondre]
J'ai modifié pour que le gadget utilise forcément le formulaire éditeur de wikicode. Les boutons fonctionnent, mais on voit le formulaire flasher. Le mieux serait d'utiliser l'API pour faire l'édition, comme dit par Od1n dans la discussion qu'il vient de citer. Ca permettrait que l'édition se fasse directement, sans passer par un formulaire rempli automatiquement. Escargot (discuter) 7 novembre 2024 à 21:35 (CET)[répondre]
Bonjour, ça fonctionne, merci beaucoup. Je n'ai pas compris le commentaire portant sur l'API. Bien à vous. Harrieta171 (discussion) 8 novembre 2024 à 09:11 (CET)[répondre]

Demande d'ajout de code pour le gadget BandeauxEbauches

[modifier le code]

Bonsoir,

Le gadget BandeauxEbauches est évidemment protégé. Il est très complet, mais il y a un bémol : supprimer un bandeau d'ébauche est (à la longue) fastidieux, bien plus par rapport aux autres tâches d'évaluation.

J'ai donc ajouté créé un fork et y ait ajouté un bouton « Tout supprimer », effaçant en un clic toutes les thématiques associées.

Pour la suppression d'un bandeau de 3 thématiques (le plus courant en moyenne), cela revient à un clic « Modifier » + un clic « Tout supprimer » + un clic « Valider » + un clic « Confirmer » = 4 clics

Auparavant, il fallait compter « Modifier », « Valider », et « Confirmer », mais également un double-clic + un appui sur la touche effacer, ce qui donne 3 + 3×3 = 12 clics.

En moyenne, 8 clics d'économisés. Je crois que ça en vaut la peine pour ce genre d'éditions.

Amicalement, Athozus Discussion 7 novembre 2024 à 22:25 (CET)[répondre]

Quelques remarques concernant l'UX :
  • Chez les utilisateurs du gadget, cela produirait un effet d'incitation à supprimer ces bandeaux. Plutôt une bonne chose, à mon avis.
  • Ce nouveau bouton ne devrait pas être à côté des deux boutons existants, mais plutôt à côté des inputs avec les noms. La raison est que ce bouton n'est pas une "action finale", comme sont les deux autres boutons, mais une "action intermédiaire", qui doit encore ensuite être publiée ou annulée.
    • Et hors de question que le bouton publie si l'on clique dessus (publication accidentelle). Et en ajoutant un avertissement intermédiaire, la manipulation demanderait deux clics… donc autant rester sur le workflow actuel, plus clair et deux clics aussi.
    • Aussi, si possible, il faudrait que le bouton soit plus petit. Pour réduire sa prévalence, pour qu'il s'intègre mieux avec les inputs, et pour qu'il se différencie des boutons Valider et Annuler.
  • Un détail en passant, il faudrait qu'il y un espacement entre les boutons (et peut-être aussi un léger espacement entre les inputs).
od†n ↗blah 7 novembre 2024 à 23:20 (CET)[répondre]
Merci @Od1n pour les retours !
Je vais suivre point par point selon les tiens :
  • J'avoue ne pas avoir pensé à cet effet-là, mais tant mieux s'il existe.
  • Je vais essayer de le replacer à un meilleur endroit. Les inputs ont l'air vieux, ce qui n'est pas optimal. Je vais voir demain pour une retouche cosmétique
    • Peut-être que ce ne sera pas clair, mais le « Tout supprimer » se fait bel et bien avec les étapes de confirmation nécessaires. Envisager un autre libellé, tel que « Vider » ?
    • J'ai mis un fond rouge pour éviter de faire deux boutons similaires, mais l'action n'étant pas immédiatement destructive, je devrais remettre comme « Annuler ». Les boutons ne seront d'ailleurs plus côte-à-côte, qui plus est.
  • Ah et bien c'est dit :p
Merci encore, Athozus Discussion 8 novembre 2024 à 11:05 (CET)[répondre]
  • Mmmmm, pas d'accord avec « Réinitialiser » : il y a un côté "retour à la situation initiale", i.e. retour aux ébauches de la version actuellement publiée. Alors que ce n'est pas ce que fait le bouton.
  • Comme Escargot vient de m'y faire penser, il y a une ambiguïté : on pourrait croire qu'après avoir vidé les champs puis publié, cela irait publier un bandeau vide, alors que non, c'est un cas spécial dans lequel le bandeau est supprimé à la publication.
    • À la réflexion, il me semble que cela soit en fait assez naturel / instinctif que le bandeau soit supprimé en le publiant sans valeurs.
  • Autre idée : un bouton intitulé "Supprimer le bandeau" qui, après un prompt de confirmation, irait directement supprimer le bandeau.
    • En fait c'est le workflow que je ne voulais pas dans mon message plus haut, mais avec cet autre intitulé pour le bouton, cela explicite son fonctionnement.
    • Aussi, je ne vois pas trop de situations on l'on voudrait supprimer toutes les ébauches existantes et en remettre de nouvelles.
  • Néanmoins, ma préférence reste encore plutôt pour un bouton discret "Vider tous les champs" à côté des inputs.
    • Mais il y a le risque que l'utilisateur clique par erreur sur le bouton, s'il va trop vite et ne remarque pas que ce n'est pas le bouton pour publier. Ce qui irait vider les champs que l'utilisateur vient de s'embêter à remplir, et faire hurler le-dit utilisateur.
od†n ↗blah 8 novembre 2024 à 17:56 (CET)[répondre]
  • Ok, « Tout effacer » convient, ou il faut considérer un autre libellé ?
  • Pour le coup, c'est en me penchant sur le code que j'ai compris qu'il y avait cette option. La prévisualisation mettait toujours un bandeau, certes non thématisé, mais toujours présent ;
  • Il faudrait toujours une fenêtre de confirmation, mais c'est faisable ;
  • À commencer par moi :D
Amicalement, Athozus Discussion 8 novembre 2024 à 22:33 (CET)[répondre]