Dernier commentaire : il y a 6 ans3 commentaires2 participants à la discussion
Bonsoir,
Je viens de remarquer que cette fonctionnalité de l'api ne semblait pas marcher avec le MediaWiki:Gadget-ListAllPortals.js sur la page Wikipédia:Liste des portails. En effet, il semblerait que certaines redirections (pas toutes) étaient quand même remontées (cf ce diff qui en supprime quelques-unes après un ménage de ce type de page).
Je suis allé voir l'une d'entre-elle, Portail:Bio, qui contenait avant sa suppression :
#REDIRECT[[portail:biologie]]
Est-ce que quelqu'un a une idée de ce qui peut faire remonter ce type de redirection malgré la présence du "apfilterredir=nonredirects" dans la requête ? Merci, Prométhée (discuter) 17 janvier 2019 à 22:20 (CET)
Le contenu que tu indiques a été celui présent pendant plusieurs années, mais entre le et la suppression de la page le , le contenu avait été remplacé par {{Suppression Immédiate|Redirection non utile}}, sans laisser le code de redirection. Ça a dû être causé par ça ? od†n ↗blah18 janvier 2019 à 05:52 (CET)
Par exemple, j'ai commencé à écrire un petit script sur Utilisateur:PAC2/minerva.js qui permet d'ajouter en bas de chaque article :
un lien vers la page Wikidata
un lien vers la page reasonator
un lien vers la liste des pages liées
un lien de recherche automatique du titre dans Wikipedia (utile pour relier un nouvel article et faire en sorte qu'il ne soit pas orphelin)
un lien vers le pageviews
un lien vers Articleinfos sur xtools.
C'est un début mais je trouve ça déjà super utile. Faites moi signe si ça vous intéresse de développer ou utiliser ça.
-PAC2 (discuter) 19 janvier 2019 à 15:52 (CET)
Script d'annulation des modifications depuis mobile
Dernier commentaire : il y a 6 ans3 commentaires2 participants à la discussion
Dans le but d'améliorer l'interface mobile, j'essaie de développer un script permettant d'annuler une modification directement depuis l'interface. Cette fonctionnalité existe dans la version ordinateur et n'a pas de raison de ne pas exister sur mobile.
L'idée est simple. Il suffit de créer un bouton qui renvoie vers l'url d'annulation.
Concernant le wgRevisionId je pense que c'est un bug, preuve en est il est bien renseigné sur les pages de diff classiques, et avec un rapide coup de google je suis arrivé sur des bugs connexes : phab:T92296 (pour les pages Flow), phab:T53594 (ajout aux diffs classiques). Je pense que cela serait à signaler/demander sur phabricator. En attendant tu pourrais essayer de parser le DOM. od†n ↗blah21 janvier 2019 à 10:15 (CET)
Wikipedia sur Ipad mini (IOS12.1.2) en "version mobile désactivée", pb de copie des Liens et URL dans le presse papier
Dernier commentaire : il y a 6 ans9 commentaires3 participants à la discussion
Bonjour, lorsque je clique sur [Lien] ou [URL] au niveau des titres à droite de la flèche, j’obtiens un popup indiquant que le lien a été copié dans le presse-papier. Mais il n’y a rien dans le presse papier et l’option "coller" reste vide. Comment faire remonter ce bug?
Je repose cette question ici suite à la réponse donnée par Orlodrim ci-après (cf Wikipédia:Questions techniques/semaine 4 2019) : "Ces liens ne sont pas visibles par défaut. Ils sont produits par gadget AncreTitres. Il est possible que le gadget ne fonctionne pas avec le navigateur de l'iPad, mais je n'ai pas les moyens de tester. Il faudrait demander sur Discussion Projet:JavaScript".
Nb: j’utilise l’Ipad mini en désactivant la version wikipedia mobile car il y a plus d’options.
Est-ce vous utilisez Safari ? Si oui, est-il à jour ? Il y a eu quelques problèmes il y a deux ou trois ans, car la méthode utilisait n'était pas supportée par le navigateur. Lofhi (me contacter) 25 janvier 2019 à 09:24 (CET)
Rebonsoir Thepat. Quelle plaie Safari, on dirait l'Internet Explorer moderne. Cela veut au moins dire que vous n'avez pas l'Ipad Mini original, car iOS 12 ne prend en charge que l'iPad mini 4, iPad mini 3, iPad mini 2.
Émettons l'hypothèse que vous avez bien Safari 12 alors, ce qui implique que la méthode utilisée devrait fonctionner. Aussi, elle est considérée comme non-standard et dépréciée, il faudrait peut-être mettre à jour le gadget pour éviter qu'il casse sans qu'on y fasse attention. Bien entendu, le nouveau standard pour gérer le presse papiers est trop récent et on ne sait même pas si Safari le supporte ou non...
Tu peux essayer d'ajouter mw.loader.load("/w/index.php?title=Utilisateur:Lofhi/JavascriptTest.js&action=raw&ctype=text/javascript"); sur ton /common.js ? Il s'agit d'une version modifiée du gadget qui s'appuie de bidouillages partagés sur internet pour réussir à faire fonctionner quelque chose de potable... Il faut que tu désactives le gadget pour éviter des conflits. Lofhi (me contacter) 26 janvier 2019 à 01:15 (CET)
Merci d'avoir testé. C'est assez ce que je craignais, même si j'espérais un petit miracle… Je pense que la seule solution décente serait d'utiliser une librairie telle que clipboard-polyfill, mais c'est un beau bébé de 23,50 ko, ça pique… Quand même à titre d'information, pourrais-tu aussi tester le code de Lofhi ? od†n ↗blah27 janvier 2019 à 14:03 (CET)
Avant de voir si on ajoute un gadget, est-ce que tu pourrais commencer par expliquer plus précisément ce que tu comptes faire en pratique s'il te plaît ? Est-ce que tu as une version fonctionnelle de ce gadget dans ton espace utilisateur avec une page permettant de tester (par exemple ce que tu voudrais faire sur WP:Vandalisme en cours) ?
Dernier commentaire : il y a 6 ans7 commentaires3 participants à la discussion
Bonjour,
Pour une nouvelle présentation du Wikimag, je souhaiterais créer des sections qui peuvent s'ouvrir et se refermer. Seulement voilà, j'ai suivi ce site : [1]. Il m'écrit un code, que j'ai recopié et adapté pour le modèle. Mais cela ne marche toujours.
Je me suis donc dirigé vers ce projet car il me semble qu'on fait cela en JavaScript.
Pour ma part, j'ai utilisé la fonction collapse qui est sensé s'utiliser avec data-toggle et data-target ainsi que id pour retrouver ce qu'il nous faut.
Gratus : « RemexHtml aims to be compliant with W3C recommendation HTML 5.1, except for minor backported bugfixes. We chose to implement the W3C standard rather than the latest WHATWG draft because our application needs stability more than feature completeness. » Cela sera pour plus tard... Lofhi (me contacter) 31 mars 2019 à 17:40 (CEST)
Edit : pourquoi vouloir des sections pliables et surtout une nouvelle présentation ? Tout a été modifié l'an dernier en demandant des avis aux lecteurs. Ces éditions sont supposées être aussi envoyées par email et être lisibles corectement dans un flux RSS, impossible de mettre du Javascript. Lofhi (me contacter) 31 mars 2019 à 17:42 (CEST)
Athozus : pas de soucis, il fallait le savoir. Reste sur une page simple et verticale pour t'éviter des peines, c'est clairement suffisant pour la majorité des cas et cela plait à tout le monde. Lofhi (me contacter) 31 mars 2019 à 18:09 (CEST)
Le mot magique REVISIONID nous quitte
Dernier commentaire : il y a 6 ans1 commentaire1 participant à la discussion
Plus d'informations sur phab:T137900. Je ne fais que survoler, mais voici les pages en JavaScript qui pourraient casser ou ne devraient plus afficher le mot magique, car déprécié :
Code CSS pour rendre toutes les palettes collapsed
Dernier commentaire : il y a 5 ans2 commentaires2 participants à la discussion
Bonjour
J'aimerais savoir s'il est possible replier toutes les palettes (pour moi uniquement) en modifiant ma page CSS ? Si oui, quel serait le code à y ajouter ?
C'est le paramètre « étatboîte = collapsed » (qui n'est pas présent sur toutes les palettes).
J'avais déjà pensé à ce genre de fonctionnalité (configuration du nombre de palettes déclenchant le "autocollapse", nombre actuellement fixé à 2… j'aurais bien voulu augmenter d'un cran).
Le problème est qu'on aurait besoin d'ajouter une dépendance à user afin de pouvoir lire la valeur personnalisée éventuellement définie par l'utilisateur ; autrement dit lire et exécuter les common.js etc. avant le code mettant en œuvre les palettes (i.e. ajout des boutons "toggle" et éventuels repliages de départ).
Et du fait de cet ordre d'exécution, cela retarderait la mise en œuvre des palettes pour l'ensemble des utilisateurs (i.e. augmentation FOUC, notamment du fait des repliages de départ qui seraient retardés), ce qui ne me paraît vraiment, vraiment pas souhaitable.
Par conséquent, sans suite pour cette requête, à contrecœur mais pour des raisons techniques insolvables. À moins que quelqu'un trouve une solution, mais j'en doute fort.
Ajout message contributions rémunérées dans C-helper
Dernier commentaire : il y a 5 ans1 commentaire1 participant à la discussion
Bonjour à vous,
Serait-il possible d'ajouter le message Modèle:Contributions rémunérées dans la boîte de C-helper. Sauf si je me trompe, le message n'y est pas (ni sur un autre outil ?). Je pense qu'il suffit d'ajouter quelque chose comme :
Week-end de travail du groupe « tech » de Wikimédia France
Dernier commentaire : il y a 5 ans1 commentaire1 participant à la discussion
Bonjour,
Je me permets de faire suivre ce message ici, puis qu'il vous concerne et que vous pouvez avoir envie d'y participer :
Dans l'optique de relancer le groupe « tech » de Wikimédia France, j'aimerais organiser une réunion sur un week-end de toutes les personnes intéressées par cette thématique. Les axes sur lesquels j'aimerais travailler durant le week-end sont les suivants :
Quelles ressources pour aiguiller quelqu'un avec des compétences en développement informatique qui veut s'impliquer dans l'association ou sur les projets Wikimedia ?
Comment identifier et contacter les personnes intéressées quand l'association a un projet impliquant des besoins tech (par exemple, un import massif de données ou de photos) ?
Comment aider les personnes déjà impliquées dans la création de modèles, modules, gadgets ou outils sur les projets Wikimedia à monter en compétence ou aller plus loin ?
Comment permettre à de nouvelles personnes de se former à ces aspects et s'y impliquer ?
Tout le monde est bienvenu, y compris les novices ! Les repas seront pris en charge pour tout le groupe, et le transport et l'hébergement pour celles et ceux qui en ont besoin.
Recommandations pour l'avenir de Wikimédia - Produit et technologie
Dernier commentaire : il y a 5 ans3 commentaires2 participants à la discussion
Bonjour :)
La Wikimedia Foundation soutient en ce moment un processus stratégique qui réfléchit à comment améliorer le fonctionnement structurel du mouvement Wikimédia (voir ici pour un résumé du contexte). Dans ce cadre, des groupes de travail bénévoles ont élaboré une première ébauche de "recommandations" destinées à être discutées avec le reste de la communauté.
Ces recommandations portent notamment sur le thème "Produit et technologie", qui pourrait vous intéresser en tant que contributeurs au Projet:JavaScript. Le groupe de travail dédié à cette thématique s'est par exemple demandé : comment impliquer davantage de développeurs ou développeuses sur nos projets ? comment co-construire les évolutions techniques en collaboration avec la communauté (pour éviter le fossé "Fondation VS contributeurs") ? etc.
Un résumé (très succinct) de ces recommandations est disponible ici :
Si besoin, je peux traduire des passages qui vous intéresseraient particulièrement.
Ces recommandations vont-elles dans la bonne direction ? Quelles précautions faudrait-il prendre pour les mettre en œuvre ? Répondent-elles aux besoins concrets de la communauté ? Avez-vous d'autres propositions ?
Vous pouvez partager vos retours ici-même ou sur les pages de discussion jusqu'au 15 septembre. Dans tous les cas, le mieux est de me notifier ("ping" ou autre) car c'est moi qui suis chargée de collecter les retours en français pour les traduire et les transmettre.
Bonjour @Jérémy-Günther-Heinz Jähnick Effectivement c'est une bonne remarque. Cela dit, le processus stratégique ne vise pas à émettre des requêtes précises, mais à réfléchir globalement aux structures du mouvement. En l'occurrence dans votre cas : une remarque pertinente est ignorée depuis des années. Pourquoi ? Que pourrait-on changer dans le fonctionnement global pour que ce genre de remarques ne soient pas perdues dans un coin ? De quels canaux de communication manque-t-on ? Parmi les recommandations en lien ci-dessus (ici), les propositions 2 et 3 pourraient être à même d'améliorer les choses à l'avenir. N'hésitez pas à en consulter les versions longues et à dire ici ce que vous en pensez. --DRanville (WMF) (discuter) 11 septembre 2019 à 14:58 (CEST)
Redirection de catégorie
Dernier commentaire : il y a 5 ans3 commentaires2 participants à la discussion
Sur Wikimedia Commons, en utilisant la "Balise : HotCat", si on met une catégorie qui n'est qu'une redirection, automatiquement la bonne catégorie se met en place. La requête serait d'offrir cette même possibilité sur Wikipédia. --Io Herodotus (discuter) 10 mai 2019 à 11:10 (CEST)
@Io Herodotus : il n’existe pas de catégories redirigées sur Wikipédia, contrairement à Commons. Il peut y en avoir transitoirement après un renommage fait avec les outils adéquats, mais ces catégories redirigées sont catégorisées dans Catégorie:Catégorie redirigée et sa sous-catégorie Catégorie:Catégorie redirigée non vide si nécessaire. Un bot vide chaque jour les catégories non vides, et les catégories vides sont supprimées.
Donc, en cas de catégorisation dans une des rares catégories redirigées existant transitoirement, le bot recatégorisa l’article dans les 24 à 48h, et la catégorie sera supprimée. Du coup, quelle utilité pour l’outil que tu demandes ? TED14 septembre 2019 à 20:45 (CEST)
Dernier commentaire : il y a 5 ans15 commentaires6 participants à la discussion
Bonjour,
Après une discussion dont le lien est Discussion Projet:Charte graphique#Nouveaux bandeaux, et dont je notifie les participants @TiboF, @Jules78120, @FructidorAn3, @Trizek et @Menthe 555, il semblerait qu’on sondage auprès des lecteurs soit la meilleure des solutions. Ainsi, l’utilisateur n’aurait qu’à écrire ce qu’il comprend du bandeau dans une petite boîte affichée automatiquement, un bouton Envoyer et un petit message de remerciement ; tout en respectant bien évidemment la charte graphique. Il a aussi été convenu de commencer par l’ébauche. Pour aider, je pense que l’outil de 2013 Wikipédia:Outil de retour des lecteurs soit un bon point de départ.
Si cela pour être fait avant la fin du mois, ce serait cool ; mais l’important est de l’avoir .
L'outil de retour des lecteurs, c'est pas le truc qui a fait un bide complet parce que le flux de messages reçus était un gigantesque dépotoir ? od†n ↗blah14 septembre 2019 à 19:53 (CEST)
Od1n : Salut. Ça je sais pas trop, j’avais 7 ans à l’époque et je n’étais pas inscrit sur WP (heureusement). Donc voilà, si tu ne pense pas que ce soit une bonne idée, eh ben il faudra une autre. Mais à l’époque, est-ce que Salebot triait les messages constructifs et les vandales qui se disaient “Chouette, on nous a simplifié la tâche !” ? AthozusDiscussion, le 14 septembre 2019 à 20:00 (CEST).
Le problème c'est surtout que 95 % des messages portaient sur le dernier truc passé à la télé, un quelconque groupe de rap-variété ou le dernier match de football. Et je te laisse imaginer le niveau intellectuel, l'orthographe et la mise en forme des messages. En fait, c'était même pire que ce que je m'étais imaginé… c'est dire à quel point ça raclait le fond de la fosse sceptique. od†n ↗blah14 septembre 2019 à 21:02 (CEST)
@Od1n : septique, pas sceptique, la fosse… À moins que tu ne parles d’une fausse sceptique, autre nom d’une vraie croyante ? TED14 septembre 2019 à 21:10 (CEST)
Le wikipédien qui avait fait son pointilleux sur l'orthographe a été retrouvé dans une fosse sceptique. EXPLICATIONS. od†n ↗blah14 septembre 2019 à 22:42 (CEST)
Faire une requête pour dire qu’on va en jeter plus de 99,99 %, il me semble que c’est la définition même d’une requête à ne pas faire. L’outil de retour des lecteurs a été un précédent qui montre que cela ne peut pas fonctionner.
Par ailleurs, dans la discussion que tu cites en début de section, je ne vois pas de consensus pour demander un tel outil, et il me semble que tu es le seul à vouloir faire cela, et j’avoue que je n’ai pas très bien compris le but de tout cela : savoir si les lecteurs de WP savent lire ? TED15 septembre 2019 à 10:45 (CEST)
TED : Le but est de savoir ce que les lecteurs comprennent, et pas trop les contributeurs comme l’a dit @Trizek puisqu’on sait déjà ce que ça veut dire. Mais alors là, je ne vois pas d’autres solutions, quoi. Si on veut l’avis, qu’est-ce qu’on peut faire ? AthozusDiscussion, le 15 septembre 2019 à 11:21 (CEST).
Le but est de savoir quel modèle de bandeau est le mieux compris par les lecteurs entre deux choix. Si on demande aux contributeurs aguerris de choisir entre deux modèles donnés, le choix serait biaisé car 1/ les personnes expérimentées comprennent le contenu des bandeaux et 2/ ces personnes ne sont pas concernées en premier lieu par les bandeaux. D'où la nécessité d'avoir un outil permettant de donner aléatoirement et comparer deux options. Trizekbla16 septembre 2019 à 09:50 (CEST)
Trizek : Bonjour, donc en plus d'intégrer l'outil de réponse, il faut implémenter un test A/B sur les bandeaux ? Et sinon, y a t-il un moyen d'obtenir le même résultat en proposant un QCM au lieu d'une zone de texte, afin de ne pas reproduire le fiasco de l'ORL ? Cordialement, — Gratus (discuter)16 septembre 2019 à 16:16 (CEST)
Je pense que ce que Gratus veut dire, c'est qu'un QCM du type « est-ce que ce message est clair ? [ ] oui [ ] non » sera plus efficace et simple à traiter qu'un champ où les gens commentent (et écrivent n'importe quoi). Trizekbla18 septembre 2019 à 14:33 (CEST)
Je rejoins l'avis de Gratus. C'est vrai que l'efficacité des bandeaux reste à démontrer mais certains doivent rester (les plus graves), les autres ne sont peut être pas tjrs nécessaire sur un article mais un message en pdd est + efficace. Des bonnes pratique devraient être vulgarisée à l'ensemble de la communauté, sur son apposition ; pas plus de deux bandeaux sinon problème multiples, pas de bandeaux redondants, parfois un message en pdd suffit et tenter de régler le problème soit même est souvent la meilleure solution. En tous cas certains bandeaux sont à gerber niveau look et je trouve le brouillon d'@Athozus un bon début d'idée de refonte. (après, une autre couleur que le blanc permet de distinguer l'article des bandeaux) Sur le même sujet, j'ai justement créé une page Aide:Bandeau (avec Jules et Pères Igor) pour informer sur l’utilité des bandeaux ainsi que de bonnes pratiques avant d'en apposer/retirer un. -- NemoDiscuter2 octobre 2019 à 21:28 (CEST)
CustomSidebar
Dernier commentaire : il y a 5 ans3 commentaires3 participants à la discussion
Bonjour,
Faisant suite à une discussion avec @Arkanosis, je viens de mettre en place un nouveau gadget, CustomSidebar. Celui-ci permet d'ajouter des liens personnalisés dans la barre latérale, avec une petite UI userfriendly.
L'objectif est, à terme, est triple :
Virer tout un ensemble de scripts hétérogène qui était copié-collé de génération en génération sur les common.js des contributeurs ;
Permettre aux contributeurs non-technique qui ne connaissent rien au JS de personnaliser leur menu latéral ;
Et par conséquent, réduire la quantité globale de JS à maintenir dans les espaces perso des utilisateurs.
Question : est-il normal que les mots magiques ne fonctionnent pas. J'ai essayé de me créer un lien https://www.google.com/search?q={{PAGENAME}}, mais ça marche pô.
Dernier commentaire : il y a 5 ans6 commentaires4 participants à la discussion
Salut,
depuis ce matin, j'ai l'erreur "Vous n'êtes plus connecté" qui apparaît en utilisant xpatrol. En regardant le code, je vois qu'il s'agit d'une histoire de token mais je ne saisis pas l'origine de l'erreur (notion débutant en js). Où ne suis-je plus connecté exactement ? Sur Mediawiki (j'ai été sur le site et en effet, je n'étais plus connecté mais maintenant c'est le cas) ? Merci d'avance.--ɄΓDO‾CЬWTH?11 octobre 2019 à 12:53 (CEST)
Dernier commentaire : il y a 5 ans9 commentaires3 participants à la discussion
Bonjour, je me suis rendu compte que ce gadget ne fonctionne plus. Je pense que la structure de la page des messages système a changé. Dans la fonction createPanel, le gadget va chercher le formulaire par son id "mw-allmessages-form". Sauf que visiblement, le formulaire n'a plus d'id du tout maintenant. Comment sélectionner le bon form pour corriger le problème ? -- Shawn (discuter) 19 octobre 2019 à 18:30 (CEST)
C'était plus compliqué qu'une simple à jour de sélecteur, mais je viens de réparer la chose. Je n'ai pas peaufiné, mais ça devrait être, au moins, aussi bien qu'avant. od†n ↗blah21 octobre 2019 à 05:18 (CEST)
Merci Od1n, c'est vrai que le passage à OOUI fait des ravages un peu partout. Je trouve que le visuel est vraiment pas terrible (trop d'espace entre les éléments, widgets beaucoup trop gros, padding énorme un peu partout, ...) et cela ne facilite vraiment pas l'utilisation sur un PC... Par contre, j'ai un souci de mon côté, le champ de recherche n’apparaît pas et j'ai le message suivant dans la console : "JavaScript parse error: Parse error: Missing ; before statement in file 'MediaWiki:Gadget-AllmessagesDeluxe.js' on line 32". Pourtant je n'ai rien vu d'erroné dans le script... --Shawn (discuter) 21 octobre 2019 à 11:41 (CEST)
Bonsoir Od1n, oui, cela fonctionne maintenant. J'utilise Vivaldi 2.8. Étrange que cela ne fonctionne pas, il est pourtant basé sur Chromium 77.0.3865.121... Cela dit, j'ai testé sur mon ordi du boulot tout à l'heure et là ça fonctionne chez moi. Mais normalement c'est le même navigateur... Peut-être une histoire de cache ? --Shawn (discuter) 21 octobre 2019 à 21:31 (CEST)
Shawn. Effectivement c'est bizarre. J'ai installé Vivaldi et j'ai testé le script avec succès. J'ai remis le "let", tu pourras réessayer de ton côté si ça fonctionne toujours ? J'aimerais bien être fixé sur cette histoire… od†n ↗blah22 octobre 2019 à 01:29 (CEST)
Les gadgets et scripts utilisateur peuvent accéder à des variables concernant la page actuelle en JavaScript. En 2015, ces informations avaient été déplacés des variables globales wg* vers mw.config. Ces anciennes variables globales seront supprimées cette année. Vous pouvez en savoir plus sur cela et indiquer aux développeurs si vous voulez que votre wiki soit le premier à tester cela.
Dernier commentaire : il y a 5 ans35 commentaires16 participants à la discussion
Bonjour à tous
Dans le cadre d'un (gros) rafraîchissement de la documentation autour des scripts utilisateur et des gadgets (avec @0x010C, @Ash Crow, @Envlh, @JackPotte, @Jitrixis, @Ltrlg, @Sukkoria et @Trizek), nous nous proposions de renommer le Projet:JavaScript (inutile de cliquer, vous êtes dessus !) en… autre chose. L'idée serait de ne pas se focaliser sur le langage utilisé, mais sur la finalité. En effet, le projet ne vise à pas à fournir une assistance sur JavaScript en général (par exemple pour écrire un bot sur Node.js) et ne se limite pas non plus à JavaScript (on fait du CSS, de la traduction ; on joue avec mw:Extension:Gadgets, mw:ResourceLoader…).
Voici une liste de une proposition (!) qui n'a pas choqué les personnes sus-mentionnées ; n'hésitez pas à l'enrichir
Complètement d'accord avec le renommage. Je vote pour Projet:Scripts et gadgets car je pense que c'est le nom qui décrit le mieux ce qu'on y fait (gadget n'étant pour moi pas assez précis car on pense uniquement aux gadgets de WP). --Niridya (discuter) 6 octobre 2019 à 13:41 (CEST)
Hello, regrouper l'ensemble du domaine "technique" ici me semble trop général, et distant de l'idée que je me fais de ce projet. Et vu que je ne vois pas la différence entre un gadget et un script, en mentionner qu'un me semble suffisant. Projet:Gadgets me semble correspondre. --Framawiki✉6 octobre 2019 à 18:51 (CEST)
« Technique » me semble trop vaste et imprécis, « Tech » encore pire avec cette économie de caractères, « Gadgets » me semble au contraire trop restrictif, et « Scripts et gadgets » ne me semble pas trop mal. Apparemment je rejoins les avis déjà exprimés. Même si « JavaScript » ne me déplait pas particulièrement (question d'habitude ?). Petite réserve quand même, car on se retrouve avec un nom plus long et plus difficile à mémoriser. od†n ↗blah6 octobre 2019 à 19:10 (CEST)
Aparté : je "vote" à l'avance, pour le remplacement de l'abscons « Scribunto », non pas par « Modules » (modules de qui de quoi ?), mais par « Modules Lua ». od†n ↗blah6 octobre 2019 à 19:16 (CEST)
Un « script », cela reste tout de même de l'argot informatique. Projet:Gadgets me semble plus compréhensible ? En plus, c'est le mot utilisé dans les préférences utilisateurs. Pour les modules, même si on répète le mot Lua assez souvent, je pense qu'il faudrait créer Projet:Modules à l'instar de Projet:Modèles. Lofhi (me contacter) 8 octobre 2019 à 19:31 (CEST)
Projet:Scripts et gadgets semble se détacher assez nettement ci-dessous (également au-dessus, mais la proposition de Projet:Gadgets ayant été faite après, je ne suis pas certain qu'on puisse vraiment en tirer la moindre conclusion).
Je propose d'attendre une deuxième semaine puisque le sujet n'est vraiment pas urgent et hop, on acte. Merci à tous pour vos avis
Pour mais si la majorité préfère l'autre nom, ça ne me dérangera pas plus que ça. Par contre, va aussi falloir qu'on reface l'interface du projet ducoup. -- NemoDiscuter28 octobre 2019 à 09:53 (CET)
@Trizek Un bandeau archive apparaît depuis que tu as effectué le renommage sur la présente page. Je viens aussi de constater (mais c'était peut être déjà comme ça avant?) que les pages 2018 et 2019 n'apparaissent pas dans la boîte des archives. En tous cas, merci d'avoir effectué le renommage ! -- NemoDiscuter7 novembre 2019 à 20:15 (CET)
MediaWiki:Gadget-teahouse
Dernier commentaire : il y a 5 ans2 commentaires2 participants à la discussion
Bonjour
Ce gadget est inutilisé. Je l'avais « importé » comme un bourrin il y a quelques années, et il ne sert à rien.
Si un administrateur d'interface pouvait vérifier s'il est possible de le supprimer et donc le supprimer, ainsi que les sous-pages (Spécial:Index/MediaWiki:Gadget-teahouse) ce serait bien. C'est mieux que d'avoir de vieux codes qui traînent.
Google Code-In will soon take place again! Mentor tasks to help new contributors!
Dernier commentaire : il y a 5 ans2 commentaires2 participants à la discussion
Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributor about two or three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have any Lua, template, gadget/script or similar task that would benefit your wiki? Or maybe some of your tools need better documentation? If so, and you can imagine enjoying mentoring such a task to help a new contributor, please check out mw:Google Code-in/2019 and become a mentor. If you have any questions, feel free to ask at our talk page. Many thanks in advance! --Martin Urbanec5 novembre 2019 à 08:28 (CET)
L'idée est de créer des taches impliquant le developpement/correction de bugs/docs de modèles/modules/scripts/bots/apps... en rapport avec wikipédia, qui seront faites par de jeunes developpeurs. J'ai participé les années précédentes en tant que mentor, avec notamment la création d'un script permettant d'éditer plus facilement les tweets à publier sur le compte @Wikipedia_fr: Utilisateur:Efly/Script/AddTweet.js. Je peux aider/renseigner si d'autres parmis vous veulent se lancer :) --Framawiki✉8 novembre 2019 à 21:35 (CET)
Boite déroulante en navigation mobile
Dernier commentaire : il y a 5 ans6 commentaires4 participants à la discussion
@FDo64 et @Od1n (à la suite de notre conversation précédente) Comme je l'ai signalé il y a un moi et demi, les boites déroulantes, ne fonctionnent pas sur mobile le contenu étant simplement affiché. C’est très embêtant pour les longues liste qui figurent parfois sur les articles et les pages d’aide et ça rend la lecture de ces pages très compliquée. Cela est dû à Mediawiki:Mobile.css qui ne contient pas le même code que le commons.css sur nos pc. Cela est d’autant plus embêtant que les appareils mobiles (navigateur ou application Wikipédia) constituent une grosse partie de notre lectorat et que ces modèles sont très utilisé ({{Boite déroulante}} et {{Section déroulante début}}). D'après Od1n une solution serait d'ajouter dans le Mobile.js le code idoine, que l'on trouve dans le Common.js. Il y a aussi un peu de CSS, même chose avec Mobile.css et Common.css. Qu'en pensez vous ? -- NemoDiscuter8 novembre 2019 à 17:46 (CET)
Je ne suis pas compétant, mais je pense que si on a besoin d'une boîte déroulante, c'est qu'on a un problème de structuration do contenu. Trizekbla25 novembre 2019 à 18:06 (CET)
Je n'ai pas spécialement d'avis, mais je suis presque convaincu qu'il y a des explications perdues et enfouies expliquant cette observation dans les tréfonds des pages de discussion. Ou alors je raconte n'importe quoi. Sûrement une question d'accessibilité... Lofhi (me contacter) 25 novembre 2019 à 20:14 (CET)
Effectivement, c'est « déconseillé » sur les pages principales mais sur les pages d'aide, c'est très souvent utilisé (voir {{Section déroulante début}}) tu dois savoir ça, Trizek J'ai déjà rencontré plusieurs pages presque illisible à cause de ce flux d'info non divulgué sur mobile. -- NemoDiscuter27 novembre 2019 à 13:49 (CET)
Dernier commentaire : il y a 5 ans1 commentaire1 participant à la discussion
J'ai testé ce gadget hier et il est très utile ! Par contre, il est responsable de l'accumulation de bandeaux sur de nombreux articles de notre encyclopédie. Vu le nombre de wikipédien qui utilisent ce gadget pour la maintenance, on voit apparaître parfois 4 ou 5 bandeaux sur de misérables ébauches. J'ai notamment fait un test sur le bac à sable. La solution serait que si on sélectionne + de deux bandeaux, il utilise {{problèmes multiples}} et met donc en paramètre les bandeaux sélectionné.