Utilisateur:Od1n/TODO

• 2026-06-19 - page d'accueil actuellement dégradée ; cf. T68637#12036688
  • update : Common.css : 237216380 et 237216538 – Mobile.css : 237216755 – aperçu actualités : 237216784
  • aucune occurrence de "accueil_2017_bloc-titre" contenant des "wikitext headings" sur le wiki : insource:"accueil_2017_bloc-titre" insource:/\=\=/
  • mais ce n'est pas la même avec "accueil_2017_cadre"… : insource:"accueil_2017_cadre" insource:/\=\=/
  • et encore autre chose : 212145793, 212145922 → les exemples là sur "Heading HTML"changes" sont tartés ?
• du code sandbox actuellement présent dans Utilisateur:Od1n/common.js (pour l'histoire avec MutationObserver dans Spécial:Block, pour MediaWiki:Group-sysop.js)
  • voir notes plus bas, dans la section #Boîtes de pandore ouvertes
• IMPORTANT : Discussion MediaWiki:Gadget-DeluxeHistory.js#Tout est marron
  • le truc le plus chiant, ce sont les listings groupés (here)
  • il faut tout remettre à plat, et le plus "simple" c'est de repartir de zéro
  • j'utilise le mode "non-JavaScript", avec le mode JavaScript ça semble à peu près pareil, mais « à peu près » ça ne me suffit pas, faut vraiment vérifier aussi
  • effet de multiplication : history/watchlist/RC/linkedRC/newpages/log/transcluded × modes groupé/non groupé × modes JS/non-JS… ça fait des dizaines à markup à vérifier
  • signaler le message raciste (« tout est marron », « marron dégueu »…)

• faire un listing de toutes les merdes à décocher dans les préférences, parce que c'est de pire en pire
  • dernier exemple en date, un questionnaire bien débile injecté dans un article : « Au cours des 30 derniers jours, vous êtes-vous senti en danger ou mal à l’aise en contribuant à Wikipédia (fr.wikipedia.org) ? Oui / Non / Pas sûr(e) »
    • coupables : meta:Community Safety, foundation:Legal:Community Safety Survey Privacy Statement
    • la merde à désactiver se trouve ici : Spécial:Préférences#mw-prefsection-personal-quicksurveyext
    • début 2026 here ; vous ne rêvez pas, cette "étude" traîne, est biieeen étalée depuis fin 2021… ben oui, une fois qu'on a le prétexte pour la rémunération, faut pas le lâcher.
    • exemple de résultats vaaaaaachement utiles : meta:Community Safety/Reports#French Wikipedia ; admirer le magnifique tableau dans la section « Reasons felt unsafe », voilà… tout ça, pour ça.
    • et comme toujours avec ces études sociologiques à la mords-moi-le-nœud, ça tire une conclusion « ouin ouin les contribut·eur·rices sont harcelé·e·s », alors que dans les 10 % de oui, 90 % c'est parce qu'i·l·e·lle·s ont publié de la zob et se sont fait reverter… donc ton étude elle sert à rien, ta conclusion elle est fausse et même mensongère comme toujours, tout ça c'est à foutre à la benne, et la PhD sociologie machin là au Minnesota va donc faire caissière chez Auchan tu seras plus utile à la société
• hop, encore une nouvelle merde à cacher dans l'interface (faute de pouvoir désactiver davantage) : « étiquettes » pour la liste de suivi
  • lien « Gérer les étiquettes » dans la barre de liens "subtitle"
    • attention : l'interface vient d'être modifiée : les liens "subtitle" ont été remplacés par des onglets regular (comme les habituels onglets « Article » et « Discussion »)
      • un changement pas forcément délirant, à part que ça a très vite fait d'overflow horizontal…
      • du coup, a plus de classe pour sélectionner le truc que je veux masquer…
      • pas question de faire #ca-special-specialAssociatedNavigationLinks-link-2 : pas fiable (i.e. future-proof) du tout
      • faudrait faire un truc du genre li:has(> a[href="/wiki/Sp%C3%A9cial:WatchlistLabels"]), avec en plus quelque chose de sorte à analyser le moins de <li> possible
        • vérifier que le CSS fonctionne sur toutes les skins, sinon mettre en "spécifique Vector classic"
      • autre élément à réémigrer : l'onglet « Effacer la liste de suivi » ; je ne veux surtout pas faire ça !!
        • et franchement c'est quoi l'intérêt d'alourdir ainsi l'interface : même pour des gens qui purgent leur liste, il suffit de tout sélectionner et supprimer…
  • boutons « Attribuer des étiquettes » et « Supprimer les étiquettes » (et aller, pas de moyen de sélectionner ça directement…)
    • après divers essais, sélecteur le plus performant trouvé : button.mw-editwatchlist-remove-selected + span[data-v-app]
      • est "suffisamment" précis/robuste/descriptif ; pas idéal, mais ça devrait convenir quand même ; c'est faute de pouvoir faire mieux quoi…
      • performances équivalentes en retirant button et/ou span, et je préfère les laisser
      • l'attribut [data-v-app] a son utilité pour les performances, je présume parce que ça fait "remonter" beaucoup moins d'éléments <span>
    • toutefois, la suppression de ces boutons fait que le bouton « Ne plus suivre » se retrouve juste en dessous des liens pour parcourir la pagination…
      • et bien entendu, le retrait des éléments de la liste de suivi est exécuté sans dialogue de confirmation !! (p*tain quoi)
        • edit : un dialogue de confirmation a été ajouté
      • admirer aussi que ces boutons « Attribuer des étiquettes » et « Supprimer les étiquettes » ne sont pas présents au début du chargement de la page, et apparaissent en "flashouillage", de surcroît en décalant le bouton déjà présent…
        • et des éléments de merde rajoutés de la sorte avec des espèces de frameworks JS de merde, qui font sautouiller la page au chargement, il y en a de plus en plus…
      • et aller, encore autre chose : en quelque sorte, une absence de PRG : si après avoir exécuté un retrait de la liste, je refresh la page avec le bandeau « Un titre a été enlevé de votre liste de suivi », ça retire de nouveau la page même si entretemps (autre onglet) je l'ai restaurée dans la liste de suivi…
        • et le bandeau continue bien entendu d'apparaître ; je sens que certains, les principes de PRG et de bandeau flash, ça a l'air très très loin de leur parler…
  • néanmoins, ce n'est pas la pire fonctionnalité (moi-même, je trouve souvent utile d'ajouter des annotations à mes bookmarks, par exemple)
    • mais à la différence de la suggestion initiale (voir image ici), ce ne sont pas des annotations, mais des tags : perso, je trouve que des tags c'est trop chiant à gérer
    • et en tout cas, pour wikipédia, pour ma part je n'en ressens vraiment pas l'utilité
  • ces nouvelles fonctionnalités développées avec ce cancer de "Codex" et apparemment le turbo-cancer Vue, qu'est-ce que c'est à ch—, ça suinte l'accumulation de couches, ça flashouille dans tous les sens…
  • et à côté de ça, l'interface de gestion qui n'affiche plus tous les liens et est passée à une pagination de 500 éléments max…
    • on peut passer la pagination jusqu'à 5000, sur le même principe de ce que je fais pour les pages d'historiques et de contributions, mais cette fois-ci c'est avec un dropdown
      • mais attention : si je charge par exemple Spécial:Éditer Liste de suivi?limit=1000, un élément correspondant « 1 000 items » est déjà ajouté par MediaWiki au dropdown
    • bon, apparemment pour des raisons de perfs, ça je peux admettre
    • et qui est aussi passé À UN PUTAIN d'affichage hyper volumineux AVEC DES PUTAINS DE LIGNES qui sont PUTAINS DE HAUTES COMME PAS POSSIBLE
      • rustinable en faisant un truc du genre #watchlist-edit-form td { padding: 4px 12px } pour overrider le padding: 12px délirant d'origine (et au passage, admirer le code CSS présent en double…)
      • pour rappel, chercher à maximiser la performance du sélecteur CSS dans ce genre de situation ; pour la page concernée (nombreux éléments), mais aussi de sorte à réduire l'overhead dans les autres pages
    • bref, maintenant obligé d'utiliser le "mode brut" faute de mieux, alors que c'était très bien avant… BRAVO les "améliorations", hein.
• Discussion Projet:Scripts et gadgets/Rapport de bug#URLs fautives avec AncreTitres : normalement traité de chez traité, mais je le garde un peu sous le coude, au cas où
  • edit : ben voilà, et aller, encore repéré un cas tordu : trailing « ) »'s… si et seulement si il n'y a aucun « ( » avant (peu importe que cela soit balanced ou non)
    • et attention : comme il faut traiter tous les trailing characters en une seule passe, il faut tester au préalable si présence d'un « ( », puis inclure ou non « ) » dans la passe d'encodage ; autrement dit, il ne faut pas effectuer les remplacements de « ) » avec une autre passe
    • j'avais déterminé cela, et qu'est-ce que je trouve plus tard, j'avais encore vu juste (nouvel exploit, faisant suite à celui-ci), ça correspond exactement à ce que fait MediaWiki : recherche « getAutoUrlTerminatingChars »
    • lien de secours, codesearch.wmcloud.org étant encore claqué au sol : recherche sur GitHub (attention : même avec des quotes, loupe un résultat dans src/Wt2Html/TracingGrammar.php…)
      • attention, des fichiers sont indiqués autogenerated ; et du coup, faudrait aller chercher la source de la génération…
      • à propos, pour information je viens de remarquer ce commit : Improve performance of getAutoUrlTerminatingChars
    • mais évidemment, ce n'est pas fini… :
      • les « ( » sont aussi pris en compte s'ils sont dans le reste de l'URL, c'est-à-dire dans le titre (e.g. « /wiki/Truc_(film) »)
      • et cette détection de MediaWiki est très naïve, ce qui conduit aisément à des résultats erronés : « bla bla (https://fr.wikipedia.org/wiki/Irlande_(pays)) bla bla »
      • mais pour ce qui est du gadget, c'est heureusement plus simple : il suffit de tester la présence de « ( » dans toute l'URL, au lieu de seulement dans l'ancre ; et le cas échéant on encode comme prévu ; le reste ne nous concerne pas, puisqu'on ne gère pas de contexte
        • ou alors justement, on encode toujours les trailing « ) », comme ça les URL du gadget, à la différence de MediaWiki, ne produisent pas le problème si on les utilise entre parenthèses dans du wikitexte
          • mais pour cela il faut aussi encoder les « ( » sinon ça bugue encore, et aussi pour équilibrer ; et peut-être aussi dans le titre de page
            • notons aussi RFC3986
            • mais les parenthèses encodées c'est moche dans le wikicode ; et pire, dans le navigateur ça reste en %28 / %29, pire encore dans le titre aussi (et en prime ce n'est plus l'URL canonique)
            • jpp ; bon, faut faire quoi pour gérer simplement, en gérant les cas vraiment probables, et en n'introduisant pas de régression ?
  • résolution :
    • la recherche de « ( » par MediaWiki ce n'est pas pour le lien en lui-même, c'est vraiment autre chose : c'est pour déterminer "par négation" si un « ( » se trouve probablement avant le lien
    • mais le problème avec cette détection Éco+, c'est qu'elle introduit le problème en quelque sorte inverse, comme montré plus haut ; il faudrait quelque chose de plus robuste, du genre parenthèses balanced
    • en tout cas, il n'y a absolument pas à encoder les parenthèses dans un lien en lui-même ; ça ne fait aucun sens de chercher à corriger dans le gadget ; c'est vraiment un problème de MediaWiki ; preuve en est, s'ils corrigeaient le problème, ça corrigerait tous les liens, y compris ceux du gadget
    • ça serait tentant de suggérer sur Phabricator de faire un truc plus robuste, mais soit 1) ils vont encore s'en battre les couilles, soit 2) ça va encore être un "can of worms" pas croyable
    • en plus, ça échoue aussi simplement en cas d'URL se terminant par « ! » : https://fr.wikipedia.org/wiki/La_V%C3%A9rit%C3%A9_si_je_mens_! (mais impossible de deviner si le « ! » fait partie de l'URL ou du contexte)
    • à toutes fins utiles, exemple de code obtenu vite fait :

      // 1. Retirer la ponctuation classique
      $url = rtrim( $url, Consts::$strippedUrlCharacters );
      
      // 2. Gérer les parenthèses
      $openCount  = substr_count( $url, '(' );
      $closeCount = substr_count( $url, ')' );
      
      // Si trop de ')', on en retire jusqu'à équilibre
      while ( $closeCount > $openCount && str_ends_with( $url, ')' ) ) {
          $url = substr( $url, 0, -1 );
          --$closeCount;
      }
      

    • cela effectue, right to left, une passe pour les parenthèses fermantes puis une passe pour les autres séparateurs ; ce n'est déjà pas trop mal, mais on pourrait faire mieux, en supprimant les parenthèses qui seraient aussi à l'intérieur de séparateurs
      • exemples : « bla bla (https://example.org/foo_(bar)); bla bla » voire « bla bla (https://example.org/foo_(bar)!); bla bla »
    • approche plus élaborée :

      // $n = $closeCount - $openCount;
      
      function removeRightmostParentheses( $str, $n ) {
          // Loop N times
          for ( $i = 0; $i < $n; ++$i ) {
              // Find the last occurrence of ")"
              $pos = strrpos( $str, ')' );
              if ( $pos === false ) {
                  // No more ")" found, break early
                  break;
              }
              // Remove it by slicing around it
              $str = substr( $str, 0, $pos ) . substr( $str, $pos + 1 );
              // autre méthode, semble un peu plus performante (d'environ 20-30 % ; testé sur PHP 8.5) :
              //$str = substr_replace( $str, '', $pos, 1 );
      
              // notes parce que là je fais du rangement et je supprime mon benchmark local :
              // both methods are very, very fast, and the substr_replace() method is about 20–30% faster than the substr() method
              // (my guess is that the functions themselves, C‑implemented, are very fast, and the gain comes from 1 function call instead of 2)
          }
          return $str;
      }
      

    • et une regex-based approach (one-liner, simple à comprendre, et le paramètre $limit est vraiment adéquat ; mais cela serait à benchmarker) :

      function removeRightmostParentheses( $str, $n ) {
          return preg_replace( '/\)(?=[^)]*$)/', '', $str, $n );
      }
      

      • IMPORTANT XXX : ça ne fonctionne pas, ça supprime une seule parenthèse

• TODO : m'ajouter un CSS pour dégager le nouvel élément « Ajouter le modèle aux favoris » (sur les pages de modèles, à côté de l'étoile de liste de suivi)
  • c'est l'élément #ca-favorite, et c'est à mettre dans le CSS global (tous les wikis)
  • note : l'élément est ajouté en JavaScript et du coup ça "sautouille" au chargement de la page. alors que évidemment c'est à ajouter "server side". encore une fois, vraiment BRAVO hein.

• rafistolé le système anti publication accidentelle : https://meta.wikimedia.org/w/index.php?title=User:Od1n/global.js&diff=prev&oldid=27113423
  • envoyé un message : phab:T369995
  • refs w3c/input-events#156
    • ça avance au rythme de trois lignes tapées sur IRC tous les six mois, et qui sont à côté de la plaque ; on n'est pas arrivé…
    • voilà le web, malgré des avalanches de documents, drafts, specs, au bout du compte les décisions sont entérinées avec trois lignes sur IRC
  • splitté dans w3c/input-events#160 (manifestement tout le monde s'en fiche)
  • mozilla : https://bugzilla.mozilla.org/show_bug.cgi?id=1909539 (stalled)
  • chromium : https://issues.chromium.org/issues/355482873 (stalled tant que #156 n'est pas traité)
  • il y a aussi cette autre problématique : w3c/input-events#161 (pas bloquant, il suffit que preventDefault continue de tout interrompre par défaut)
  • entretemps Firefox j'en suis revenu :
    • les marketeux ont trop mis leur sales pattes grasses dedans, ce n'est plus supportable
    • j'ai encore en travers de la gorge des problèmes tels que Mitchell Baker#Controverses (malheureusement, c'est loin d'être un cas isolé)
    • je me suis développé une extension perso concernant la gestion des bookmarks dans Chrome, avec le problème d'UX complètement débile au point que c'était un blocker pour moi

• mon .vector-body { font-size: 0.813em; } (de mon vector.css) n'est plus effectif sur certains bandeaux système MediaWiki
  • et j'imagine que bien entendu c'est aussi pété dans le MediaWiki:Gadget-VectorClassic.css…
  • exemples :
    • bandeau « Attention, vous êtes en prévisualisation ! »
    • bandeau de blocage : Spécial:Contributions/NTMVA
  • culprit :

    .cdx-message__content, .cdx-message__content > * {
        font-size: var(--font-size-medium, 1rem);
        line-height: var(--line-height-small, 1.375rem);
    }
    

  • ça a été introduit là : Gerrit blame (et effectivement, le gerrit:1123503 ce n'est pas un petit changement…)
    • même en fenêtre incognito et ?useskin=vector, le texte des bandeaux (16px) me semble anormalement plus gros que le reste (14px)
    • nous sommes le 2025-05-15, et ça a été déployé récemment, déjà attendre de voir si cela change, autrement ça sera à signaler
  • aparté 1 : jpp de ces polices de caractères hyper grosses. Malgré un écran 4K, il y a des fois, j'ai même moins de texte que deux décennies en arrière sur un écran 1024x768…
  • aparté 2 : jpp de ce "Codex" là ; le truc qui me fait même regretter l'ignominie précédente OOUI machin là, c'est dire…
• (skin vector classique) constaté ce 2023-12-15 la dégradation de la page d'accueil, au niveau des borders et des margins des titres de sections, et le texte Wikipédia du bandeau d'en-tête
  • recherche rapide en partant de « mw-heading2 » :
    • https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+log/60c804aba3166877d478f76f5f919b60f1aa4315/resources/src/mediawiki.skinning/elements.less
    • https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/Vector/+log/c7b000ada4002029edba2f50575d40e5eb99fd9c/resources/skins.vector.styles.legacy/typography.less
    • https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/Vector/+log/c7b000ada4002029edba2f50575d40e5eb99fd9c/resources/skins.vector.styles/typography.less
  • et aussi le retour, mon override n'étant plus effectif à ce niveau, de la typographie débile avec les titres de section en font serif…
  • il y aura aussi besoin de mettre à jour le gadget AncresTitres, notamment ses liens qui ne sont plus en font sans-serif, mais en serif…
  • refs mw:Heading HTML changes (attention, actuellement c'est un mélange entre l'ancien et le nouveau markup…), T13555 et T314714
  • a été signalé ici : Discussion Wikipédia:Accueil principal/Archive 20#Vide avant les titres des blocs sur Vector
• encore et encore, au sujet du nouveau markup des titres de sections (T13555 et mw:Heading HTML changes), et aller, repéré encore deux autres gadgets à réparer :
  • MediaWiki:Gadget-FlecheHaut.js
  • MediaWiki:Gadget-verifAncres.js (chercher « mw-headline »)
  • à propos : T337286 (Gadget API for adding buttons to section titles), qui a été mentionné ici et à nouveau ici
• Discussion Projet:Scripts et gadgets#Template gadgets : il faut que je poste des éléments de réponse (pour rappel, voir les clarifications dans T204201 ; j'avais aussi posté un message ici, envoyant vers cette autre discussion)
• Spécial:Filtre antiabus/380 (discussion)
• Spécial:Filtre antiabus/321, le spambot de m*rde :
  • Wikipédia:AbuseFilter/Faux positifs#Spécial:AbuseFilter/321 2023-11-04 15:52
  • Wikipédia:AbuseFilter/Faux positifs#Spécial:AbuseFilter/321 2023-11-17 06:15
• paramètre "petit" dans Modèle:Titre section (wstat)
• le contenu de {{En-tête de page de discussion}} ne prend pas toute la largeur du cadre
  • même problème avec {{Anecdote publiée}}
• Catégorie:Wikipédia:ébauche Tarbes blindé d'erreurs et qui se retrouve en sous-catégorie de Catégorie:Page avec des erreurs de script
  • correctif appliqué : 207231964
  • aussi créé le thème d'ébauche : 207232103
  • TODO : chose sale à arranger : 207232354
  • pour faire au moins pire, j'ai annulé 207231964 et 207231964 pour revenir à l'erreur Lua…
• il reste des mw.loader.using('mediawiki.action.edit') à supprimer dans des JS utilisateur
  • et on peut même remplacer par simplement addCustomButton() (attention quand même, ça utilise MonobookToolbar au lieu de mw.toolbar)
  • voir ces edits : 154709825, 154909772, et un peu plus tard 157110994
• {{Méta palette de navigation}}, {{Méta palette de navigation sous-groupe}}, et peut-être d'autres :
  • on est avec le "border-collapse:separate" d'origine, avec les tables de sous-groupes en "margin:-3px"
    • problèmes : risque d'inconsistance selon les navigateurs, et si on applique un background à la table de sous-groupe ça dépasse
    • sur enwiki ils ont remplacé par un système en "border-collapse:collapse", cf. en:Module:Navbox/styles.css
    • voir aussi sur Stack Overflow : https://stackoverflow.com/questions/8806161/css-table-border-spacing-inside-only/30401167#30401167
  • sur enwiki ils gèrent l'alternance de lignes même avec des sous-groupes
    • cela devrait se situer dans en:Module:Navbox, mais le code de ce module semble très complexe, pas sûr que cela soit judicieux…
• {{Liste éléments}} : le templatestyles pourrait être manquant sur mobile, cf. T303378
• Discussion modèle:Infobox V3/Séparateur#Modèle cassé
• classes .toccolours / .cadre-gris-clair (dans le Common.css, archive DIMS) : on pourrait faire passer un bot pour renommer une grande partie des classes
• rapport de bug Gadgets AncreTitres et FlecheHaut : le vivre ensemble avec le nouveau markup des titres de sections, on y est de moins en moins : aux problématiques qui étaient déjà présentes, se rajoutent ces histoires avec les DiscussionTools…
• je viens de remarquer que sur les pages de catégories, le contenu "wikitexte" est dans un ".mw-parser-output", et pas le listing des pages de la catégorie ; c'est tout à fait cohérent, par contre ça pourrait prendre en défaut le code "$content.find('.mw-parser-output')"
• il faudrait regrouper les contenus de MediaWiki:Minerva.css et MediaWiki:Gadget-Mobile.css, qui sont chargés de façon tout à fait redondante (les deux avec Minerva sur desktop comme sur mobile)
  • comme ça on pourrait dégager cette c*nnerie monumentale qu'a été ce MediaWiki:Gadget-Mobile.css ; en prime on économise un chargement de fichier, comme ça tout le monde est content
  • desktop charge Common + Minerva, mobile ne charge que Minerva ; donc couplage très fort mobile/Minerva ; ainsi on ne peut décemment pas supporter Minerva sur desktop (trop de conflits), et on a fermé la porte au support d'autres skins que Minerva sur mobile ; oui, tout cela est claqué au sol
  • le problème principal, ça serait de préserver / restaurer les historiques, maintenant répartis entre trois fichiers… (et merci au prix nobel qui nous a flingué l'historique en créant MediaWiki:Gadget-Mobile.css par copier-coller de MediaWiki:Mobile.css au lieu de le renommer)
  • EDIT : ça fait sens d'avoir deux fichiers, Mobile.css (en attendant, à long terme, la fusion de desktop et mobile) et Minerva.css (dédié aux moult rustines spécifiques pour cette skin). Voir T248416#10605265. Donc NE PAS fusionner ces fichiers (de plus, de toute façon les historiques sont complètement différents et donc non fusionnables).
• "rustineFoucMobile" dans le Module:Bandeau et icônes à masquer (ou pas) sur mobile :
  • Discussion MediaWiki:Common.css/Archive 1#Disparition inexpliquées
  • https://fr.wikipedia.org/w/index.php?title=Module:Bandeau&diff=prev&oldid=223684200
  • https://fr.wikipedia.org/w/index.php?title=MediaWiki:Gadget-Mobile.css&diff=prev&oldid=223683963
• avec par exemple Black tools icon.svg, on peut remplacer fill="#000000" par fill="currentColor", ce qui permet de changer la couleur de l'icône directement en CSS via la propriété color
  • ça pourrait avoir un intérêt pour le mode sombre : utilisation d'une même icône pour les modes clair et sombre : plus simple et CSS plus léger
  • peut-être indiquer cela à l'Escargot, même s'il connait probablement déjà
  • edit : technique pas utilisable directement, il faut bricoler ; propositions IA, non testées :

.mon-icone {
    width: 24px;
    height: 24px;
    background-color: #123456;
  
    /* On applique le masque */
    -webkit-mask-image: url('icone.svg');
    mask-image: url('icone.svg');
    mask-size: contain;
    mask-repeat: no-repeat;
}

• classes tleft et tright : meta:Tech/News/2026/22 et phab:T426452
  • un cas classique (et malheureusement devenu habituel) de "on fait le changement, démerdez-vous"
  • where money ? ça sera sans moi
  • une fois de plus, petite démonstration (on a déjà eu largement pire) que le "principal software engineer" là ne fait que réfléchir en surface
  • concepts du jour :
    • Net Negative Producing Programmer (NNPP) ; dans Peopleware
    • –10x Engineer (bien remarquer le « – »)
    • le classique principe de Peter, tout à fait adéquat ici
      • à ne pas confondre avec le principe de Dilbert, qui n'est malheureusement pas appliqué ici
  • concepts connexes :
    • Broken windows theory : effet systémique, complémentaire et amplificateur du NNPP
    • effet "bad apple" (article 2006), mais c'est plus large et concerne surtout l'aspect relationnel

• T321532 (« Console error - 'Error: View mediainfoview does not exist' on Commons File pages ») – et aller, toujours le même :

À cette analyse « gestion du personnel » (2d6) de l'IA, j'ajoute que la suppression du système targets me semble être une idée désastreuse : la version mobile est radicalement différente, et la grande majorité des gadgets n'y ont aucunement leur place. Accessoirement et inversement, des gadgets pertinents seulement sur version mobile, ça me semble aussi possible. La suppression du système targets enlève toute possibilité de configuration du chargement, ce qui en gros obligerait à passer sur chaque gadget et à ajouter un early return lorsque mobile… Donc, même problématique (déterminer pour chaque gadget s'il est adéquat sur desktop et/ou mobile), mais à devoir gérer de façon beaucoup plus merdique. Et aussi, bien entendu, tous les assets sont chargés, le payload en prend un sacré coup (alors après faut pas venir me parler d'optimisation, quand on pond des idées de merde pareilles). od†n ↗^blah 10 juin 2026 à 04:25 (CEST)

• mw:Talk:Growth/Revise Tone#Surface-level tone fixes may mask deeper content problems

• mw:Manual:Coding conventions/JavaScript#Exporting :
  • 8425176
  • 8323577 / 8425176
  • il a fait sauter les placeholders $2 et $3 ; du coup ils sont affichés tels quels dans les traductions périmées, et ce trou dans la numérotation, gniiiiiiiii juste non c'est pas possible
  • il a aussi regroupé (mais attention, pas effectué dans tous les paragraphes) les énumérations comma-separated dans des <tvar> "globaux" ; toutes les langues ne séparent pas avec des virgules, mais OK pour le principe, comme ça c'est plus simple (et moins la m**** si le nombre d'exemples est encore modifié plus tard)
  • idéalement, il faudrait refaire les "gabarits" bien proprement à la base, en mettant à jour conjointement toutes les traductions, qui sont peu nombreuses : mw:Special:PrefixIndex/Manual:Coding conventions/JavaScript
  • mais attention, huge warning : le putain de système de traduction, qui repose sur des espèces de mises à jour par bot, ça a toujours été une source d'emmerdemments comme pas possible
• Wikipédia:Forum des nouveaux#fonctionnement de l'option "langue" pour le modèle "ouvrage", qui concerne maintenant le Module:Langue
  • j'ai déplacé la discussion vers Discussion module:Langue#fonctionnement de l'option "langue" pour le modèle "ouvrage"
• MediaWiki:Group-sysop.js : script fortement compromis à cause du passage à Codex / Vue
  • la proposition de donner le droit ipblock-exempt aux membres du groupe bot, c'est judicieux ? ça règle entièrement le problème ?
  • je viens de passer encore trop de temps à expérimenter avec le hook 'SpecialBlock.form'
    • cf. 234892334 et mw:Help:Manage blocks/Developers
    • encore une fois, prise de tête malgré les apparences (penser à tous les "flux" possibles) ; notamment :
      • lorsque changement vers un autre utilisateur : généralement, deux hooks reçus, avec formVisible false puis avec formVisible true
      • pas de formVisible true lorsque utilisateur ayant déjà un blocage (ce hook se produit ensuite, ssi on clique sur « Ajouter un blocage »)
      • au démarrage, un hook avec formVisible true lorsque utilisateur prérempli et n'ayant pas de blocage ; autrement, il n'y a pas ce hook
        • c'est embêtant parce que sans hook au départ, ça oblige à garder // et également faire la vérification avec la valeur initiale checkBlockBotWithIP();…
    • néanmoins, c'était bien parti, mais… blocker :
      • malgré le hook reçu avec formVisible true, la checkbox input[value="wpAutoBlock"] n'existe pas encore à ce moment-là, elle n'apparait que plus tard…
      • c'est parce qu'elle se trouve ailleurs (recherche), dans un composant "AdditionalDetailsField.vue"
      • faudrait signaler et demander à ce que le hook soit fired seulement une fois tout le form bien construit, mais franchement ce Vue de merde là j'en peux plus
      • edit : checkbox trouvable au moment du premier hook, celui avec formVisible false…
    • 234963615 ne va pas : le message est bien ajouté, mais Vue de mes couilles doit pas encore avoir fini tout son merdier d'initialisation, et l'élément de message est supprimé
  • et alors, d'autre part, le truc qui me fait encore plus péter un câble : les « Vérifier votre identité » SANS CESSE pour modif la page, avec le putain de code 2FA à aller chercher à chaque fois, et pire encore, cette vérif 2FA déconne à longueur de temps…
    • refs phab:T197137, où l'IA m'a confirmé la parfaite incompétence technique d'un personnel WMF, pourtant à une position de responsabilité, et n'ayant fait que communiquer pour noyer le poisson mais sans action concrète
• Discussion modèle:YouTube#Paramètres "début passage" et "fin passage"
  • j'ai une sandbox locale, pour ajouter support de :
    • « min » en plus de « m »
    • espaces optionnelles
    • omission du « s » ssi précédé de minutes (car ambiguïté dans le cas « 1 h 30 », et à deviner, on dirait des minutes plutôt que des secondes…)
      • justement, aussi ce remplacement inopiné à prendre soin d'éviter : 20:30 → 20:30s
  • exemples de nouvelles syntaxes : « 1 h 20 min », « 20 min 30 »
  • la question prise de tête : support ou non de « min. » (erroné mais fréquent) ?
    • pour être consistant, faudrait aussi supporter « h. » et « s. »…
    • je dirais plutôt, ne pas supporter :
      • déjà assez prise de tête comme ça
      • « garbage in, garbage out »
      • l'affichage "silencieusement corrigé" serait divergent, donc confusion
      • en prime permettrait inclusion du cas si catégorisation futures des syntaxes erronées
      • au lieu de chercher à gérer des trucs erronés, corriger à la base : catégoriser/corriger, wstat.fr, faire passer des bots, éduquer les rédacteurs…
  • pour rappel, j'ai une autre approche, en normalisant au départ avec des remplacements du genre :gsub( '%d+ *min%f[^a-z]', 'm' )
    • patterns volontairement stricts quitte à en faire trop ; ça ne mange pas de pain
    • évite des remplacements du genre « minute → mute » (serait rejeté ensuite, mais autant ne pas reposer dessus…)
    • concernant l'omission du « s » final (pour rappel, ssi précédé de minutes), variantes :
      • :gsub( '%d+ *m *%d+$', '%0s' ) (mais à exécuter après la normalisation « min → m »), ou
      • :gsub( '%d+ *m *%d+$', '%0s' ):gsub( '%d+ *min *%d+$', '%0s' ) (mais beurk… vraiment dommage que l'on ne puisse pas faire m(?:in)?…)
    • dilemne des patterns de remplacement "isolés / indépendants" versus "mieux, mais il y a un ordre à respecter"
  • il y a aussi les leading zeroes (comment les nettoyer proprement/simplement), néanmoins ils ne posent pas problème pour le parsage int Lua
• Discussion modèle:Date#Date incomplète compacte -> erreur lua
  • la cause de la cause, c'est dans validationJourMoisAnnee le « if bmois:match( '^%u' ) then mois = ucfirst( mois ) end », qui fait qu'ensuite au lieu de toujours propager le nom de mois canonique, ça peut aussi le propager avec une majuscule
    • cette majuscule est bien entendu souhaitée dans le résultat, à propos j'ai aussi vu cette discussion : Discussion module:Date#Typographie erronée pour les mois, qui confirme cela
    • la grande question : comment arranger cela, afin que cela soit à la fois plus simple et plus robuste ?
  • source de divers autres bugs, par exemple la normalisation « aout → août » (pour les cibles de liens seulement, i.e. l'orthographe choisie par le rédacteur est préservée) qui est skippée dans ce cas :
    • {{date|Aout 2010|liens=oui}} → Aout 2010 (actual [[Aout 2010|Aout]] ; expected [[Août 2010|Aout]], comme c'est le cas avec les autres utilisations)
  • concernant aussi le « aout », mais ne venant en fait pas de l'histoire avec la majuscule, c'est encore autre chose… une discrepency « 17 aout 2010 (30 août dans le calendrier grégorien) » :
    • {{date|17 aout 2010|julien=oui}}
    • {{date|17 aout 2010|julien=oui|compact=oui}}
    • {{date|17 Aout 2010|julien=oui}}
    • {{date|17 Aout 2010|julien=oui|compact=oui}}
• Module:Liste simple, à la suite de la fusion de {{Liste simple}}, {{Liste sans puce}}, {{Unbulleted list}} :
  • discussion : Discussion modèle:Liste simple#Fusion des modèles Modèle:Liste sans puce et Modèle:Liste simple et Modèle:Unbulleted list
  • dans le code actuel, le if #numargs > 1 pose problème :
    • si un seul item de liste (pas précédé d'un "*", càd un simple texte), il sera retourné au mauvais endroit (par le return "paramètre déjà une liste")
    • plutôt numargs[1]:sub(1, 1) == '*'
      • attention, il faut s'assurer que c'est testé sur une valeur trimmée
  • c'est dommage de boucler deux fois
    • on peut éviter ça même avec le système "skip empty params", avec des flags, des early returns, etc.
      • pour rappel, en Lua il existe "break" mais pas "continue" ; en revanche on peut mettre des "return" partout, du moment que c'est la dernière instruction de bloc (en on peut même faire un bloc exprès : do return ... end)
  • système "skip empty params" vraiment nécessaire ? on pourrait ajouter une catégorie de détection ("if #args ~= #numargs")
  • classe "liste_sans_puce" du module et Modèle:Liste simple/style.css semblent unused
    • remarquer la confusion "ul.liste_sans_puce" du module et ".liste_sans_puce ul" de ce templatestyles
    • redondant avec le ".liste-simple ul" des CSS Common et Mobile, et qui est de meilleure qualité
    • recherche "liste_sans_puce"
  • Daïras de la wilaya de Djelfa
    • attention, la wikisyntaxe de liste (i.e. "*") n'est pas reconnue dans les légendes d'images
    • justement, je crois bien qu'il existe un modèle pour répondre à cette problématique
      • retrouvé : {{Liste pour légende}}, mais le résultat affiché est avec des bullets
    • traité : 231363225
    • le fait que ça supporte la syntaxe HTML mais pas la wikicode, c'est assez clairement un défaut, qui devrait être corrigé ; mais je sais très bien d'avance à quel point soit 1) ça serait un merdier pas croyable, soit 2) ils vont s'en battre les couilles
  • encore autre chose : il y a eu une espèce de fusion mais sans préserver l'historique, du coup on a l'historique de {{Liste sans puce}} mais tout l'historique de {{Liste simple}} (here) a disparu…
    • bien entendu, modèles différents donc historiques unrelated, donc à ne pas fusionner sinon ça devient un merdier incohérent
    • mais il est teeeeeeeeellement évident qu'il suffisait de remplacer le contenu de {{Liste sans puce}} par un redirect, et ne pas toucher aux historiques
  • à propos, je viens de remarquer cette discussion : Wikipédia:Le Bistro/6 novembre 2021#Liste pour tableau
  • update : à part l'histoire de l'historique tarté, normalement le reste c'est traité
  • à propos, je viens de re-tester (très vite fait) Module:Code de liste décalable, il est encore un peu pénalisant, mais pas autant qu'auparavant
    • néanmoins, l'ajout de cela serait-il pour autant justifié, si pertinent/utile que cela ?
    • explication, car entretemps il y a eu des optimisations dans le "bootstrap" Lua (todo retrouver les tickets phabricator)
      • mais il faudrait faire encore mieux, notamment le lazy load auquel j'avais pensé (sous réserve que cela soit tout simplement possible), au lieu de cloner tout l'environnement à chaque fois…
• Discussion Projet:Scripts et gadgets#Proposition de délistage du gadget UTCLiveClock
  • et à propos mw:MediaWiki_talk:Gadget-UTCLiveClock.js#Optimizing timer updates when seconds are hidden
• wikt:Discussion MediaWiki:Gadget-StyleArticles.css#Le markup des titres de sections a changé
  • envisager de solliciter les droits admin d'interface (ça arrangera tout le monde) sur le modèle de cette candidature, annoncée ici, ici et ici
  • update : candidature lancée le 19 juin 2024 : wikt:Wiktionnaire:Administrateurs/Od1n (administrateur d'interface)
• Wikipédia:Demande d'intervention sur un message système/Archives2#MediaWiki:Common.css – ".aa-faux-h2" ; entre autres :
  • transformer les id en class (peut y avoir plusieurs éléments par page) fait
  • créer une classe aa-bloc-seul pour remplacer les aa-bloc-gauche utilisés sans aa-bloc-tete
    • bien entendu, une fois la classe appliquée aux pages, il y a du CSS que l'on pourra nettoyer dans le Common.css
  • remplacer les <strong> par des <div>
    • il faudra bien entendu ajouter des margins verticales, là ça repose sur les créations automatiques de <p>
    • <p> aurait été sémantiquement préférable à <div>, mais :
      • bazar CSS avec les règles que MediaWiki applique d'origine (par exemple problème de priorité sur le line-height)
      • plus inhabituel pour les rédacteurs (un coup à ce qu'ils oublient que c'est cette balise et pas une autre qu'il faut utiliser)
      • pour résumer : « avec div, pas de surprise »
  • lorsque cela ne sera plus plus nécessaire (plus de "vrais titres"), retirer les CSS "border bottom none" des aa-titre-bleu etc.
  • recherche insource:"aa-bloc-tete" insource:/\<h2/ pour le "#aa-bloc-tete h2 margin-top 4pt;" dans le Common.css
    • penser aux titres syntaxe "==", mais je crois qu'il n'y en a pas
  • pour rappel, penser à l'affichage dans les popups de l'éditeur visuel (refs 153085043 et 149879322)
• sur les pages d'articles inexistants, le texte « L'article « … » n'existe pas encore. Comment faire pour le créer ? » est en bleu (classe aa-titre-bleu), et on peut avoir l'impression que c'est un lien
• Discussion modèle:Brouillon#Section déroulante
• Discussion Projet:Jeu vidéo#Modèle:Infobox Notes de jeu vidéo : titre en italique ?
• 153112689 : poursuite nettoyage paramètres {{Infobox/Début}}
• {{Confusion}} : ajout paramètre "position section", cf. ce diff ? (aussi pour Saint-Affrique#L'histoire et Château de Kincardine (Fettercairn)#Sheriffdom de Kincardine)
• Codes des bandeaux (Module:Bandeau, méta-modèles, fichiers CSS…) :
  • <lister ici les discussions et rapports de bugs>
  • pour vérification rapide des multiples bandeaux : Aide:Liste des modèles de maintenance
  • une autre page avec des tests : Modèle:Méta bandeau/Test
  • un modèle que je viens de repérer, où le contenu ne prend pas toute la largeur : {{En-tête de page de discussion}}
  • et pour rappel, sur mobile il y a l'histoire des icônes ridiculement petites
• classes "toccolours" / "cadre-gris-clair" : voir cette DIMS, notamment les diverses observations que j'ai ajoutées à la fin
  • ça serait tentant d'utiliser le bot là-dessus, mais vu le nombre de pages, forcément des problèmes inattendus vont émerger…
• Catégorie:Italique à vérifier dans un paramètre de modèle : purée il y en a plein en fait, suite à la mise en œuvre de cette détection (« [[Foo]], [[bar]] »)
  • résumés de diff :
    • [[Modèle:Infobox Personnage (fiction)|{{Infobox Personnage (fiction)}}]]&nbsp;: correction d'une "écriture détournée" qui n'est plus appropriée suite à la mise en place du modèle [[Modèle:Italique si non précisé|{{Italique si non précisé}}]]
    • [[Modèle:Infobox Personnage (fiction)|{{Infobox Personnage (fiction)}}]]&nbsp;: mise en italique plus précise (on peut faire cela depuis la mise en œuvre de [[Modèle:Italique si non précisé|{{Italique si non précisé}}]] dans l'infobox)
    • [[Modèle:Infobox Personnage (fiction)|{{Infobox Personnage (fiction)}}]]&nbsp;: désactivation d'une mise en italique automatique, grâce au modèle [[Modèle:Pas en italique|{{pas en italique}}]]
• Discussion Projet:Modèle#Présence anormale d'un article dans les pages liées
  • en plus là j'y pense, le "follow redirects" est effectué dans tous les appels de wd.siteLink(), pas seulement les infoboxes…
  • idée : table remplie manuellement avec les redirs et leurs destinations
    • quand même bien mitigé : ça fait un truc en plus à gérer et à maintenir
      • et pas possible d'ajouter une catégorie de maintenance, car la fonction retourne un titre de page et non un lien ; encore une problématique que T137584 résoudrait
      • workaround : fonction dédiée qui teste toutes les redirs de la table, que l'on invoque quelque part dans une page wiki, et qui affiche le résultat de l'analyse (ou seulement en cas d'erreur)
    • éventuellement : suivre la destination actuelle de la redir, au lieu de hardcoder aussi la destination ; impact perf, mais seulement sur les pages contenant une redir
  • code rapide pour lister une grande partie des redirections ; exécuter sur Spécial:Modèles les plus liés "5000" :

    (() => {
    	const links = document.querySelectorAll('ol.special > li > bdi > a');
    	const result = [];
    	for (const link of links) {
    		if (
    			!/^(Modèle|Module):/.test(link.textContent) &&
    			link.classList.contains('mw-redirect')
    		) {
    			result.push('* [[' + link.textContent + ']]');
    		}
    	}
    	console.log(result.join('\n'));
    })();
    

  • attention : seulement parmi les 5000 pages les plus liées, donc il n'y a pas les redirs moins utilisées
    • donc, il resterait quelques redirs présentes dans les infoboxes, mais quand même peu
  • actuellement, parmi les 5000 pages les plus liées : 20 résultats (+ 3 FP que l'on peut aisément éliminer)
  • idée : option pour activer le mode "follow redirects" seulement à la demande
    • par exemple, rien qu'en activant cela pour les « Activités » et les « Distinctions », cela couvrirait une grande partie des cas détectés
    • toutefois, cela fait quand même une "opération coûteuse" pour chaque activité ou distinction listée, et néanmoins une certaine "gestion manuelle" à faire (choisir où activer le mode), et un résultat imparfait (les redirs ne sont pas évitées, partout où le mode n'est pas activé)
• Discussion MediaWiki:Gadget-CatRename.js#& nbsp; → en:MediaWiki talk:Gadget-popups.js#Edit summaries in history/contribs previews double-escape HTML entities
• Wikiquote :
  • Problème visuel Parsoid saut de ligne
  • Modèle:Voir autre projet : les icônes devraient être sur la même ligne que le texte ; il manque tout un tas de CSS (les .bandeau-cell, .bandeau-icone, etc.)

(pour ne pas en oublier en cours de route)

• en:Template talk:Infobox software#Layout of the "initial release" field : le layout actuel est bien tarté, et ça a l'air simple à corriger (sous toutes réserves, remarquer que l'infobox contient déjà un "hack" par Codename Lisa) ; surprenant que ça soit encore en l'état
• en:Module talk:Yesno#Edit request 25 September 2025 : éventuellement ajouter un message pour confirmer que la suggestion serait en fait contre-productive, notamment en raison de "l'overhead Lua", qui n'a pas été pris en compte par le benchmark
  • à propos, il y a une footer note, qui est défecteuse en raison d'un caractère « = » dans le contenu ; je ne corrige pas pour l'instant, pour ne pas "réactiver" la discussion avant que j'ajoute un message
• gerrit:1161572 a été mergé hamdoullah
  • une fois déployé (1.45.0-wmf.7, 26 juin 2025), on pourra supprimer les rustines height: auto dans MediaWiki:Gadget-MonobookToolbar.js et MediaWiki:Gadget-mediawiki.toolbar.js
  • edit : et non : commentaire sur gerrit ; va falloir se taper une création de ticket et cinq patches pour les skins…
  • notons aussi Skin:BlueSpiceDiscovery (en:BlueSpice) qui a eu la grande intelligence d'utiliser le même id #toolbar pour une toolbar à eux (recherche)… soupir
  • à propos, il reste dans mediawiki/core un CSS pour la classe "mw-toolbar-editbutton" (ici), et cette classe est encore un peu utilisée dans les wikis ; peut-être faudrait-il ne plus reposer sur cette classe, qui pourrait disparaître de MediaWiki
  • on a un prix nobel qui a supprimé la classe sans prévenir sans rien : gerrit:1161826. C'est dans MediaWiki DEPUIS 18 ANS, avec des utilisations qui se sont éparpillées un peu partout. Donc une fois de plus, des décennies de codes qui se sont construits autour, mais "on supprime sans prévenir. Une semaine. Démerdez-vous. Adaptez les wikis à nos changements." (et les adaptations sont tellement laborieuses à réaliser que ça reste en l'état, c'est-à-dire devenu pété…)
• du Phabricator plus ou moins en cours :
  • T308504 : redirects qui ne sont pas mis en évidence sur Spécial:Modèles les plus liés (en attendant, j'ai ajouté des styles dans Utilisateur:Od1n/ProtectionsModeles.js)
  • T307361 : texte en input qui n'est pas conservé quand on sélectionne un autre projet avec l'outil MediaWiki code search
    • corrigé dans une nouvelle version beta de l'outil
      • ça utilise un module WebAssembly (Wasm)
        • ne fonctionne pas sous Pale Moon ; mais de toute façon, Pale Moon de moins en moins de sites fonctionnent dessus (et quand ça fonctionne, souvent c'est excessivement lent…)
        • à propos, le WebAssembly ça me semble overkill parce que le frontend c'est juste une page de recherche, et ça doit bien compliquer la maintenabilité (mais bon, c'est eux qui voient)
      • un point à corriger dans l'interface : faudrait un "cursor pointer" quand on survole les liens de projets, parce que là actuellement ça fait un "cursor text"…
• diffs qui sont passés en font monospace : cet ajustement local sera peut-être à retoucher ou supprimer à l'avenir ; surveiller phab:T250393
• Utilisateur:Od1n/Arbre modèles siècles
• Détermination « er/e » si non spécifié, dans les quelques modèles de siècles
  • pour {{s}}, {{s mini}}, etc. simplifier code liens avec {{Lien siècle}}, et inliner {{Suffixe siècle}} dedans
  • documenter et catégoriser ces « sous-modèles techniques » : {{Lien siècle}}, {{Lien siècle av JC}}, {{Exposant siècle}}, {{Suffixe siècle}}, {{Vérification siècle}} et sous-pages…
  • le cas échéant, supprimer ceux qui ne sont finalement pas utilisés ({{Exposant siècle}} ?)
  • proposal : {{XXe siècle-}}, équivalent {{s-|XX}} mais plus lisible ? (idem que {{XXe siècle}} / {{s|XX}})
  • à terme (notamment une fois les inclusions vérifiées), simplement ignorer les anciens paramètres d'exposants, de sorte à alléger les codes
  • nouvelle syntaxe implémentée dans {{s2}}, faire de même avec les variantes (vérifier au préalable les inclusions)
    • Utilisateur:Od1n/Rapport s2-
    • faire ensuite de même avec {{sp}} et variantes
    • enfin documenter le tout
    • {{s2}} et variantes pourront éventuellement appeler {{sp}} avec la nouvelle syntaxe de ce dernier ?
  • attention : {{s}} a encore un paramètre 3, utilisé par exemple par {{sp}}
    • apparemment le paramètre 6 dans {{sp}} c'est que du « s » ou du vide. devrait y avoir moyen de faire du ménage.
      • edit : attention, presque. trouvé deux articles qui l'utilisent en suffixe av/ap J-C
  • {{sp}} (etc.) : le lien va aussi sur « siècle » en mode singulier, mais pas en mode pluriel ; idéalement, serait à rendre consistant
  • {{-sp}} et {{spa}} seraient à fusionner ?
    • les résultats sont légèrement différents, faudra faire le point là-dessus
    • refs 140991346, concernant la palette
  • modèle {{Romain vers texte ordinal}}, mieux en texte pour les lecteurs d'écrans ; vérifier s'il n'y a pas déjà de tels modèles
  • proposal : syntaxe alternative avec les exposants, e.g. {{s|VIIe}}, {{s2|VIIe|VIIIe}} ?
  • les siècles saisis en chiffres arabes, on les gère ou pas ?
  • éventuellement trimer les valeurs
    • si c'est possible simplement en modifiant au niveau des modèles fondamentaux
    • et avec « 1= » et non {{trim}} (performances)
  • éventuellement catégorisation des syntaxes erronées, mais il faut que le code soit simple et performant
  • faire le point sur les protections des modèles
• il y a aussi les modèles de millénaires…
• arrangeage des inclusions de {{Allmusic}}, simplifications du modèle, et bien sûr liens externes
• grgniiii – indicatif requiert, subjonctif requière, nondediou
• une coquille fréquente : « desription » (l'histoire a commencé dans ce modèle)
• MediaWiki passé en HTML5 (youhouuu !) ; Murphy oblige, y'a des codes qui ont coincé :
  • {{Boîte déroulante/début}} apparemment y'a un truc qui va pas
  • voir Wikipédia:Le Bistro/18 septembre 2012#Migration vers le doctype HTML5
  • voir Discussion Projet:Modèle/2012#Attributs de mise en forme HTML v. styles inline
• Discussion Projet:Modèle#Indicateurs de langue dans les modèles
• Histoire de catégorisation redondante sur Discussion Projet:Scribunto#Catégorie des modules
  • pour retrouver les inclusions automatiques : MediaWiki:Scribunto-doc-*
• en:Wikipedia:Village pump (proposals)/Archive 142#Re-hiding the siteSub "from Wikipedia blah blah"
• mw:Manual talk:Custom edit buttons#Getting a bit complicated, doesn't it?
• Discussion Projet:Scripts et gadgets/2017#Retrait de vieux gadgets (notamment à propos du newCollapsible, "fr-collapsible")
• Discussion modèle:Wikiprojet#Supprimer le lien "masquer/afficher"
• mw:Extension talk:CentralNotice#Scroll position messed up after the banner is added
• p**tain de positionnement de scroll de la page décalé à cause des modèles déroulants qui se referment au chargement
  • chercher scrollIntoView dans le MediaWiki:Common.js, bout de code déjà traficatouillé plusieurs fois, sans grand succès
  • un truc bien lourdingue, c'est que selon l'ancre ça fonctionne ou pas, sans explication :
    • PHP#Présentation : décalé
    • PHP#Fonctionnement : pas décalé
  • on peut aussi avoir des palettes au milieu des articles :
    • exemple Formule 1#Circuits, qui décale donc les liens ancrés à partir de Formule 1#Qualification
    • mais à la rigueur, ce cas n'étant pas fréquent, on n'a pas trop à s'en soucier
  • pour rappel, on a trois systèmes différents dans les pattes :
    • "NavFrame" : boîtes déroulantes
    • "collapsible" : palettes, et utilisations de la classe ailleurs…
    • "mw-collapse" : natif MediaWiki
  • bien entendu, ce qu'il faudrait c'est repositionner après que chaque script ait fait son boulot initial
    • mais attention, le hook "wikipage.content" ne convient pas ? on ne veut scroller qu'au chargement, pas à chaque refresh ajax
  • le diaporama/animation est maintenant lazy-loadé, et le chargement est maintenant asynchrone, donc il faudrait qu'il repositionne le scroll après son exécution ?
    • attention, aussi exécuté par le LiveRC RunCommonJS, où cela pourrait y poser problème ?
  • pour mw-collapsible :
    • /resources/src/mediawiki.page.ready/ready.js (GitHub)
    • /resources/src/jquery/jquery.makeCollapsible.js (GitHub)
    • idée à chaud : hook sur "wikipage.collapsibleContent", mais avec un flag global de sorte à ne repositionner que la première fois
• d:User talk:Seb35/sortValues.js#Code review
  • nope, algo de tri pas encore bon…
  • liens Stack Overflow :
    • How can I compare arbitrary version numbers?
    • Sort version-dotted number strings in Javascript?
• phab:T186702 – Request to manually rename a gadget in fr.wiki database
• Discussion modèle:Unité#Propositions changements redirections/aliases
• Très bonne nouvelle : la fonctionnalité TemplateStyles est maintenant disponible (bistro)
• dégueulis de noms de paramètres avec des coquilles avec le modèle {{Ouvrage}}
  • Sans surprise, même constat avec Article et avec Lien web…
• Une discussion que j'ai ouverte : Discussion modèle:Bibliographie#Nom du modèle
• {{Pistes}}, leading zeroes dans les indexes des pistes : Discussion modèle:Pistes#Bug du modèle Pistes sur Wikipédia francophone

• Cuisine niçoise (cf. « guerre des alt ») (voir aussi cette discussion) à noter que les <gallery> supportent maintenant les alt
  • toujours dans les <gallery> : le préfixe "Fichier:" est désormais optionnel
• Corriger les ajouts par Juna polino (d · c) (une partie déjà faite)
  • un autre à nettoyer : 92.145.218.188 (d · c) (lien qui servira peut-être  : en:San Fernando Mission Cemetery)
• Il manque les évaluations wikiprojets sur plein d'articles que j'ai créés → hop, liste (lent à charger)

pour essayer de ne pas oublier…

• avec la titine :
  • nettoyage subst Avertissement fusion
  • nettoyage subst Quote (pour retrouver le contexte)

• Daniel Conversano :
  • un exemple, parmi tant d'autres, de « il FaUt deS SoURces secOndAiREs » (à géométrie très variable, selon la gueule du client)
  • et à côté de ça, Charte du Mouvement (juin 2024) : « nique les principes fondateurs, maintenant on assume que l'on fait du militantisme »

• Utilisateur:Od1n/ProtectionsModeles.js (pour Spécial:Modèles les plus liés) : les images ne fonctionnent plus, en raison de la restriction à la con des dimensions possibles pour les thumbs
  • la restriction qui gêne à peine ceux qui font du hotlink, mais qui emmerde bien comme il faut les utilisations légitimes sur le wiki (modèles, CSS, etc.)
• le système pour rapprocher les "hat notes "un peu vers le haut (voir ici) n'est plus fonctionnel en l'état avec le nouveau parseur Parsoid en développement
  • car inclus dans un élément <section data-mw-section-id="0" ...>
  • à propos, Parsoid semble rajouter beaucoup, mais alors vraiment, beaucoup de markup… ça va faire mal.
  • Wikipédia:Le Bistro/24 juin 2026#Migration vers Parsoid (découvert via cette rustine) : « 2026-06-25 ». doomsday. ça va faire mal.
  • et aller : 237333793
    • faire le point sur attribut vs propriété
    • remarquer aussi mon commentaire code, qui a peut-être besoin d'une mise à jour
    • et surtout : pourquoi en est-on encore à avoir besoin d'un JavaScript de la sorte ??? pourquoi il n'y a toujours pas moyen de faire ça directement server-side ???
• snippet Google actuel pour Financement participatif : « Le financement participatif ^{, ,}, ou sociofinancement, (…) » : des virgules présentes indésirablement
  • modèle {{,}}, classe cite_virgule dans le Common.css
  • solution suggérée : afficher la virgule en CSS avec ::after et content
  • autre possiblité, mais moins bonne : aria-hidden="true" ; edit : elle est redevenue envisageable, cf. un peu plus bas dans ces notes
  • éventuellement (à confirmer si vraiment adéquat), mettre aussi l'espace dans le content CSS, et comme ça on peut retirer les paddings actuels
  • refs : 44100288
  • attention, ça serait aussi à mettre dans le mobile CSS
    • auquel (une fois de plus…) il manque actuellement le CSS pour cite_virgule, et donc les virgules sont collées
  • problème, et de taille (blocker) : avec les copier-collers de texte, on passe de [1],[2] à [1][2], or c'est fortement préconisé avec des virgules
    • edit : j'ai posé de nouveau la question à l'IA, et cette fois elle m'a répondu que c'est fortement préconisé sans virgules ; nan mais wesh quoi
  • du coup, la piste avec aria-hidden="true" devient envisageable
    • au pire, ça ne fonctionnera pas pour enlever les virgules dans le snippet Google
    • il y a aussi la question de ce qui est – éventuellement – lu par les lecteurs d'écran (apparemment ça dépend des outils) :
      • les virgules (sauf à coup sûr si aria-hidden="true")
      • et même les crochets
  • en fait la vraie solution, ça serait que ça soit traité dans MediaWiki, qui ajouterait/afficherait automatiquement des virgules entre les références successives
    • plutôt que d'ajouter (en mode désespoir) encore et encore des putains de "fonctionnalités" qui cassent sérieusement les cou*lles
• (re)mettre sur la table la question de l'utilité des bandeaux ébauche :
  • évidence visuelle : un article court se voit immédiatement, le bandeau n'apporte pas d'information nouvelle
  • bruit ajouté : surcharge de bandeaux en tête d'article, lisibilité réduite
  • dilution des avertissements importants : les bandeaux critiques (sources, neutralité…) perdent en impact
  • effet Pierre et le loup : trop de bandeaux → les lecteurs finissent par ignorer tout le bloc
• une source IA à réémigrer : Discussion:Mot de passe (jeu vidéo)#Source douteuse
• ça me gonfle les '''Titre''' (<b>, font-weight "bolder") dans les captions de tables (déjà en font-weight "bold"), qui du coup se retrouvent avec du "gras supplémentaire"
  • plutôt que de les corriger encore et encore, comme si on s'essuyait avec du papier comme au moyen-âge, et qu'il en reste encore et encore,
  • envisager l'ajout d'un CSS du genre "caption b/strong { font-weight: bold }", et ainsi overrider le "bolder" d'origine du navigateur
  • le "caption bold" n'est pas d'origine navigateur : avec la skin Vector classique, MediaWiki applique un .wikitable > caption { font-weight: bold; }
    • faudrait regarder pour les autres skins
  • avec ce nouveau CSS, visuellement on ne détecterait plus les syntaxes "erronées", mais :
    • le "caption bold" n'étant pas d'origine navigateur, ces syntaxes ne sont en fait pas si erronées que cela
    • la correction silencieuse me semble préférable plutôt que d'enforcer une syntaxe alors que ce n'est pas vraiment justifié et que ça serait évitable
  • faudrait un truc du genre :

    /* <b> pas forcément direct child de <caption> : genre il y a un <span> intercalé pour une raison X ou Y (penser à certains modèles) */
    /* en revanche garder le direct child ".wikitable > caption" : c'est en raison des tables imbriquées */
    /* EDIT : et aussi faudrait faire b:only-child, pour traiter ssi tout est en gras ;
       pour préserver le cas où, volontairement, seulement une partie est mise en gras.
       mais ça semble amener des problèmes de conflits avec le ruleset suivant (gras imbriqués) ? */
    .wikitable > caption b {
        font-weight: inherit;
    }
    /* éventuellement restauration des <b> imbriqués */
    /* mais cela nécessite que le rédacteur utilise la wikisyntaxe <b> (ou <strong>…), car « ''' » n'est pas imbriquable */
    /* franchement, je me demande si c'est utilisé ne serait-ce qu'à un seul endroit sur le wiki… */
    .wikitable > caption b b {
        font-weight: bolder;
    }
    

  • un exemple (parce que sinon ça serait laborieux de faire un bac à sable, etc.) : Université Paris-Panthéon-Assas#Présidents
    • trouver et noter d'autres exemples, en "backup"
  • toutes les skins ont un .wikitable > caption { font-weight: bold; }
  • Minerva a en plus de cela un .content caption { font-weight: bold; text-align: left; }
    • il applique un bold à tous les captions, pas seulement ceux des ".wikitable"
    • il override son propre font-weight (celui des ".wikitable"), mais ce n'est pas très grave
    • à propos, il aligne les captions à gauche, on ne sait pas vraiment pourquoi mais avec eux on n'est plus à une connerie près
  • simplement pour info : sur la skin Cologneblue, le "bolder" est bien présent mais chez moi n'a pas d'effet visuel (i.e. pas de gras supplémentaire malgré le weight 900)
• page d'accueil sur mobile :
  • en mode "deux colonnes" (tout à fait possible, penser aux tablettes voire phablettes), il n'y a pas d'espacement entre les colonnes gauche et droite
  • il y a deux "lignes bleues" en dessous des titres de section
    • refs rapides : Common.css, Mobile.css ; diff 212145328 et suivants
  • et pour confirmer : oui, c'est avec le MobileFrontend activé (d'ailleurs, les problèmes sont aussi présents sans le MobileFrontend)
  • pour rappel, le Common.css est désormais aussi chargé sur mobile
  • donc : ne pas faire comme j'aurais été tenté de faire (mettre sur Mobile.css le code de Common.css, avec éventuels ajustements) : il faudrait enlever le code du Common.css, et mettre dans Mobile.css seulement les ajustements/annulations (donc, sous forme de surcouche dégueulasse)
  • ATTENTION : ?useformat=mobile ne fonctionne pas correctement : le rendu varie aussi selon "état bascule desktop/mobile" + Shift+F5 entre les bascules !
    • refs Discussion utilisateur:Od1n#useformat=mobile charge MediaWiki:Common.css et phab:T265566
    • basculé desktop (sans oublier le Shift+F5) : rendu sur deux colonnes, et avec les bugs mentionnés au-dessus ; basculé mobile (sans oublier le Shift+F5) : rendu sur une colonne
      • (et encore à propos : pourquoi pas permettre deux colonnes même en mode mobile ? normalement c'est ça, le responsive…)
• pages d'homonymie URI  et Uri 
• Accueil 2017 (Wikipédia:Accueil principal, MediaWiki:Common.css, MediaWiki:Mobile.css) : le markup et le CSS ont encore besoin de proprage
• page d'accueil avec la skin Vector 2022 :
  • important : tester en étant connecté et déconnecté (fenêtre navigation privée), les rendus sont très différents ; tester aussi avec Firefox et Chrome, vu qu'ils affichent le texte un peu différemment
  • les « six liens » (« Accueil de la communauté », etc.) rendent mal :
    • lorsque déconnecté : les liens « Accueil de la communauté » et « Comment contribuer » s'affichent au-dessus du globe
    • lorsque connecté : césure d'emblée dans le lien « Accueil de la communauté »
  • tout en bas de page, lorsque déconnecté, le lien « Wikispecies » et sa description s'affichent en dessous de l'icône
• les liens « révoquer » qui s'exécutent sans confirmation (page intermédiaire ou popup), c'est une blague ?
  • si c'est bien un problème au niveau de mediawiki, faut leur signaler (edit, déjà fait : phab:T126798)
  • en attendant, faire le point sur les solutions possibles ici
  • en:Wikipedia:Rollback#Accidental use of rollback • en:Wikipedia:Rollback#Additional tools • en:Wikipedia:Customizing watchlists#Remove or modify the .5Brollback.5D link
  • Wikipédia:Rollback • MediaWiki:Gadget-ConfirmRollback.js
• on trouve des articles pétés en cherchant wikitable
• Wikipédia:Modèles à haut risque : directement importé depuis le wiki anglais, beaucoup de choses à arranger (apparemment une bonne partie du cravail effectuée entretemps, cf. cette discussion)
• Arme à feu : à sourcer. début de pêche aux infos :
  • ajout de stats dans l'article (404 sur l'URL de la réf à la fin)
  • récupération document (voir les PDF, pas les forums en tête de résultat)
  • autre source de stats
• commons:Accueil : oh le centrage vertical foireux des titres de sections
• commons:Template talk:Idw#Issue with post-expand size ; sera plutôt à signaler sur commons:Commons:Village pump/Technical
• MediaWiki:Spam-blacklist à épurer (cette extension a un impact sur les perfs lors de l'enregistrement, donc… gniiiii quoi)
  • mais pour que cela soit humainement faisable, faudrait au moins tester programmatiquement les domaines…
• commons:Commons:Téléverser : le bandeau d'avertissement est en anglois, traduction à ajouter
• {{Animation}} utilise des classes "diaporama"… les noms seraient à uniformiser sur l'un ou l'autre
• la classe headergris du Common.css est très ancienne et peu utilisée, il y aurait peut-être moyen de l'éliminer
• rechercher « insource:"aa-titre-bleu" » : des textes bleus que l'on confond avec des hyperliens, forcément…

• surveiller T68637#12015627, dont la résolution comme indiqué nécessiterait d'effectuer des mises à jour dans le Common.css (cf. 237000147 et 236986430)
• avec mw.util.getUrl(), il faudrait escaper les « % » dans les ids/ancres
  • refs phab:T238385#11417365 et gerrit:572403
  • pour rappel : dans MediaWiki:Gadget-AncreTitres.js
• "diffs" des filtres anti-abus : ça affiche toutes les lignes (au lieu de seulement les lignes de contexte), ce qui est pénible notamment en raison des notes qui sont parfois très longues (vu que c'est surtout utilisé comme changelog…)
  • pour rappel, ça affiche les notes et/ou les conditions, i.e. pas forcément les deux, seulement s'il y a eu une modification dans le composant
  • si cet affichage de seulement les lignes de contexte est effectué, il faudrait une solution pour pouvoir afficher toutes les lignes (toggle), sinon carrément pas possible d'accéder à l'ancien contenu
  • j'avais commencé à développer en local un script pour disposer de cette limitation des lignes, avec un toggle, mais ça ne m'avait que moyennement plu (on sentait que c'était un truc rajouté "au moins pire" sur l'interface d'origine)
  • faudrait poster une demande sur Phabricator, mais vu comment le développement de AbuseFilter est délaissé (j'ai moult PR qui attendent…), pas trop motivé pour perdre du temps avec une demande ayant très peu de chances d'aboutir
• l'insertion fallback d'un <references /> si manquant n'est peut-être pas une si bonne idée, car du coup les problèmes passent inaperçus au lieu d'être corrigés…
  • implémenté dans 798b4537712e
  • à propos, mentionné dans cette DIMS
  • exemple de problème (for the record, diff concerné)
• ParserFunctions : Suggestion: new functions #ifnot, #ifand
• ne pas générer des <ul> distincts lorsque lignes « * » séparées avec des lignes vides
• phab:T47070 : dans le Tablesorter "forké", concernant les collations, le code tarté est toujours présent
  • le genre de truc que je voudrais corriger avant de me barrer en claquant la porte de ce projet de m—
  • dans le gerrit:517266 associé, il y a aussi un nitpick code comment (à corriger par la même occasion, en "scouting")
• phab:T200206 (« Omit `<link rel="mw-deduplicated-inline-style">` from page view HTML ») : problème toujours présent et dont la résolution est tombée aux oubliettes
• phab:T387778#10827432 : des variables CSS manquantes avec Vector classic
  • c'est le problème qui me fait que les "messages système" (e.g. lorsque modification d'une ancienne version de page) ont un texte devenu dégueulasse
  • signalé depuis mai 2025, quand même…
  • « we're looking into a fix now » 🤡
• phab:T340797#12074376 : un déluge affligeant de "star selectors" CSS, avec de surcroît des styles présents en double…
• sur mobile, le lien « More > Expand all / Tout développer » n'a pas d'icône (mask-image), à la différence des autres liens (il y a aussi le lien "Report visual bug", mais il n'est pas censé demeurer à long terme)
  • pour constater, une page contenant des éléments "mw-collapsible", ce qui active la création du lien : en:Help:Collapsing tables and more
  • refs la task de l'ajout de ce satané lien : phab:T347299
  • MediaWiki code search "t-collapsible-toggle-all", où on voit qu'il n'y a vraiment rien d'autre
  • update concernant l'aparté "icône aussi manquante sur le lien « Report visual bug »" :
    • sur enwiki (« Report visual bug »), il n'y a pas d'icône…
    • mais sur frwiki (« Signaler un bogue visuel »), il y a une icône !?
    • pourtant les markups sont les mêmes, et on n'a rien d'ajouté en local sur frwiki
    • recherche codebase MediaWiki très rapide, le plus proche que j'ai trouvé : init.less history, gerrit 1318275 ; mais cela concerne l'icône de la version desktop, c'est vraiment autre chose
  • à propos, gag : lorsque non connecté, il n'y a pas du tout ce menu « More »… donc tout simplement pas d'accès à plein de liens pertinents
  • si une icône est ajoutée upstream, on aura besoin d'implémenter aussi dans notre Common.js, lorsque l'on crée le portlet nous-mêmes parce que pas présent initialement
    • parce que le CSS n'est pas appliqué directement sur le lien, mais sur un <span> qui est prépendé

• MediaWiki:Common.js : de l'harmonisation à faire entre les codes "Palette" et "BoiteDeroulante"
  • voir notamment 238463253
  • onclick / addEventListener / jQuery .click( … )
  • event handlers définis en "single instance outer scope" vs "inline"
  • à l'initialisation, approches "textContent correct dès le départ" (le ternary dans le code "Palette") vs "toujours "enrouler", puis éventuellement corrigé par le toggle initial"
  • et justement : dans un cas la function "toggle" est inconditionnelle, dans l'autre cas ça prend en compte le texte ; et appel initial inconditionnel ou pas ; bref, faudrait converger vers des mécanismes identiques
  • edit : quoique ; les objectifs sont différents : les "palettes" sont soit enroulées soit déroulées au départ, alors que les "boîtes déroulantes" sont toujours enroulées au départ
  • nom de variable toggle / toggler pour les liens de toggle
  • à propos, il reste aussi des noms de variables en PascalCase (NavFrame, NavToggle…), ça serait à "moderniser"
• MediaWiki:Gadget-LeftPaneSwitch.js :
  • je dois reconnaître que je n'utilise quasiment pas ce bouton, et c'est bien dommage…
  • attention : ce n'est plus un script perso, mais un gadget global (relativement peu utilisé, mais utilisé quand même ; voir Spécial:GadgetUsage), donc ne pas le modifier directement, mais overrider avec du CSS perso
  • augmenter le padding de largeur ; passer à un bouton d'aspect ratio horizontal
    • mais pas trop, pour ne pas avoir d'effet gniiiiii ce n'est pas tout à fait aligné verticalement avec le premier onglet de page (dont la largeur varie selon le namespace…)
  • ne pas augmenter le padding de hauteur : avoir un léger espacement avec les onglets de page est appréciable
  • autre avantage, et considérable : avec une plus grande surface, le bouton est beaucoup plus facile/agréable à cliquer
  • mettre un gris un peu plus clair, pour compenser, pour ne pas que le bouton soit trop proéminent
  • l'époque a bien changé depuis la création de ce gadget en 2012… c'est maintenant le retour du split screen… différemment :
    • 2012 : gadget créé à une période personnelle bien critique ; workflow de travail : un PC claqué au sol et un écran minuscule, split screen tout juste concevable
    • 2026 : workflow de travail : un mini PC master race et un écran 4K de seigneur ; split screen 5 colonnes, et des esclaves IA
• Wikipédia:Le Bistro/11 mai 2026#Re-using references with different details – introducing sub-referencing
  • une fonctionnalité a priori bienvenue, et un message très bien rédigé : ça fait plaisir
  • en plus, des gadgets on en a deux : MediaWiki:Gadget-ReferenceTooltips.js (celui mentionné dans le message) et MediaWiki:Gadget-tooltipRef.js (celui que j'utilise encore)
• MediaWiki:Gadget-ArchiveLinks.js : j'avais commencé à faire ça :

  		/*
  		 * Le code pour itérer les "a.external" est particulièrement verbeux,
  		 * mais c'est parce qu'il est important de maximiser les performances.
  		 *
  		 * notamment :
  		 * - ne pas utiliser querySelectorAll()
  		 * - itérer les NodeList (live comme static) avec une boucle numérique et non avec un "for...of"
  		 * - mettre en cache la propriété "length" lorsque itération d'une NodeList live
  		 */
  
  		const parserOutput = $content[ 0 ].getElementsByClassName( 'mw-parser-output' )[ 0 ];
  		if ( !parserOutput ) {
  			return;
  		}
  
  		const links = parserOutput.getElementsByClassName( 'external' );
  		for ( let i = 0, l = links.length; i < l; ++i ) {
  			const link = links[ i ];
  
  			// normalement tous les éléments ".external" sont des <a>, mais il faut s'en assurer
  			// (rien n'empêche l'ajout de ce nom de classe à n'importe quel autre élément)
  			if ( link.tagName !== 'A' ) {
  				continue;
  			}
  

  • avec ce résumé de diff : « optimisation de l'itération des "a.external" (important car assez lent et exécuté chez tout le monde) ; sur un gros article, pour 1000 itérations on passe de 40 ms à 15 ms (avec une machine puissante) ; la méthode avec jQuery incluait toutes ces optimisations, donc en gros là on économise l'overhead de jQuery »
  • mais finalement le gain de perfs, somme toute assez minime, ne justifie pas un code aussi verbeux
  • la méthode actuelle avec jQuery est en fait déjà bien optimisée en interne, et c'est presque une one-liner ; c'est le sweet spot
  • garder le code actuel, et éventuellement ajouter des commentaires en s'inspirant de ceux ci-dessus
  • update : effectué 231233131
• wikt:MediaWiki:Gadget-CommonWikt.js : réémigrer la fonction obsolète "CommonWikt_ajax"
  • je l'ai déjà éliminée des gadgets du namespace MediaWiki: (voir 37397210)
  • mais elle est encore utilisée dans des forks utilisateur
    • après vérification, oui ce sont des forks qui sont utilisés, via chargement par common/vector/etc.js utilisateur
    • malgré le var CommonWikt_ajax (et non window.CommonWikt_ajax), c'est quand même dans l'espace global (et donc encore fonctionnel à ce jour) lorsque présence d'un chargement mw.loader.load("//fr.wiktionary.org/wiki/MediaWiki:Gadget-CommonWikt.js?action=raw&ctype=text/javascript");
      • du coup, possibilité que Gadget-CommonWikt.js ait été chargé plusieurs fois ? en fichier de gadget (dans le scope de chaque gadget) et via mw.loader.load (dans l'espace global)
      • après chaque nettoyage de "CommonWikt_ajax" dans un fork utilisateur, vérifier si d'autres fonctions de "Gadget-CommonWikt.js" y sont encore utilisées ; si négatif, supprimer le chargement qui serait éventuellement présent
• LiveRC :
  • dégager les animations des menus basées sur du CSS "opacity"
    • bien que j'aie l'impression d'être la seule personne au monde à ne pas supporter les effets de transition à ce point et à devoir les désactiver immédiatement (Windows, Android…)
    • ces animations sont présentes un peu partout dans la codebase, loin d'être seulement sur les menus
    • code compliqué, avec une sorte de time interval qui change en boucle le CSS opacity… de nos jours il existe le CSS "transition"
    • idéalement, garder des animations mais en opt-out avec détection de la configuration dans l'OS : window.matchMedia('(prefers-reduced-motion: reduce)').matches
      • mais à la condition que le code des animations soit simple et court, sinon mieux vaudrait privilégier la simplification de la codebase
  • plus pertinent, ajouter un système pour que les menus ne s'ouvrent pas immédiatement dès que la souris passe au-dessus
    • pareil, plein de sites ont ce problème et c'est horripilant, et ce n'est quasiment jamais traité…
• Utilisateur:Arkanosis/xdone.js : je viens de retrouver une ancienne sandbox locale (avril 2024), du coup c'est à réexaminer…

  l'intention était de remplacer :

  [ new RegExp( '\n*\\{\\{' + _templates + ' fin\\}\\}', 'g' ), '\n:' + _option[ 'done_message' ] + '\n{{$1 fin}}' ],
  [ new RegExp( '(\n:[^:\n][^\n]*\n)(:[^\n]*\n\\{\\{' + _templates + ' fin\\}\\})', 'g' ), '$1\n$2' ],
  

  par :

  [ new RegExp( '(\n(:*).+)?\n*\\{\\{' + _templates + ' fin\\}\\}', 'g' ), function ( match, p1, p2, p3 ) {
  	// p1: last non-empty line before the closing template - may be undefined
  	// p2: number of leading colons in this line - defined iff p1 has been found
  	// p3: from the parentheses of the "_templates" group
  
  	// note: the possible newlines before the closing template are stripped,
  	// then we will add back exactly one newline in the output
  
  	if ( p1 ) {
  		const replyIndentLevel = p2.length;
  		const reply = ':'.repeat( replyIndentLevel ) + _option[ 'done_message' ];
  		return p1 + '\n' + reply + '\n' + '{{' + p3 + ' fin}}';
  	} else {
  		const reply = ':' + _option[ 'done_message' ];
  		return '\n' + reply + '\n' + '{{' + p3 + ' fin}}';
  	}
  } ],
  

  → voir mes modifs connexes en mars 2024, notamment la dernière, 213685191

• (edit : done 2025-02-27) wikt:MediaWiki:Gadget-CommonWikt.js : réémigrer la fonction String.prototype.format(), très mauvaise chose de modifier le prototype
  • ce CommonWikt.js est une dépendance pour d'autres gadgets, cf. wikt:MediaWiki:Gadgets-definition
  • recherche « contentmodel:javascript insource:/\.format\(/ » dans tous les namespaces
  • il y a largement ce qu'il faut nativement : avec de simples concaténations, ou les template strings maintenant disponibles (pour rappel, on peut tout à faire mettre des fonctions dans les expressions)
  • certains scripts semblent ne rien utiliser d'autre du CommonWikt.js : recherche « contentmodel:javascript insource:/\.format\(/ -insource:/wikt\./ »
  • résumé de diff : remplacement de la fonction String.prototype.format() du module [[MediaWiki:Gadget-CommonWikt.js|CommonWikt.js]] par des template strings ES6 natives
  • regexes à l'arrache pour automatiser une partie des remplacements :
    • "([^"]*)\{0\}([^"]*)"\.format\(([\w\.]+)\) → `$1\$\{$3\}$2`
    • "([^"]*)\{0\}([^"]*)\{1\}([^"]*)"\.format\(([\w\.]+), *([\w\.]+)\) → `$1\$\{$4\}$2\$\{$5\}$3`
    • attention, gère mal le cas où le placeholder est utilisé plusieurs fois (e.g. « foo {0} bar {0} baz »)
  • il ne reste plus que CreerNouveauMot.js (et deux versions dev/sandbox)
    • et là pour le coup, c'est vraiment utilisé par un système de "templating"
    • soit transformer String.prototype.format() en wikt.text.format()
    • soit déplacer vers une fonction locale dans CreerNouveauMot.js
    • dans les deux cas, attention changement de signature : renseignement du texte en 1^er paramètre, donc décalage des paramètres variadiques
• MediaWiki:Gadget-MagnusEditBox.js (voir l'historique) : on peut maintenant utiliser const et let sans problème
• Discussion Projet:Scripts et gadgets#Boutons d'avertissement ne fonctionnant pas avec les Outils de discussion
  • voir notamment les EXPLICATIONS que j'ai postées sur Wikipédia:Bulletin des administrateurs/2023/Semaine 23#Problème technique
  • j'ai un bac à sable local où j'ai résolu toutes les problématiques (y compris l'histoire avec les titres de sections, où j'ai même élaboré deux méthodes différentes lol) ; tout le code y est, et j'y ai aussi noté beaucoup d'EXPLICATIONS
  • en revanche tout un travail de mise au propre à faire ; EXPLICATIONS, c'est la raison pour laquelle ce n'est pas encore publié…
• HideLastEditedPages.js : une fois le correctif pour T378132 passé en prod, faire usage de la classe .mw-contributions-current (T130824)
  • classe découverte grâce à cette discussion
  • script créé en 2015, classe apparue en 2016…
  • j'ai vérifié : plus performant que les elm.querySelector() (par exemple, sur une page de 5000 lignes, gain d'environ 2,3 ms)
  • .matches('.classe') vs .classList.contains('classe') :
    • Chrome : matches() très légèrement plus performant, mais c'est vraiment le même ordre de grandeur
    • Firefox (console JavaSript ouverte) : matches() aussi légèrement plus performant mais c'est vraiment infime, et les deux pas mal plus lents qu'avec Chrome
    • Firefox (console JavaSript fermée) : les deux deviennent beaucoup plus performants, et classList.contains() environ 2.3x plus rapide que matches(), ce qui le fait même passer devant Chrome
    • pour trancher :
      • matches() est très peu utilisé dans les repositories MediaWiki : code search (par contre, il y a énormément de faux positifs : code search)
      • classList.contains() est en revanche énormément utilisé : code search
  • fait : 220062930
• pour nettoyer des options ajoutées par des gadgets foireux qui ont été chargés pour être testés
  • pour tout lister : mw.user.options.get();
  • pour réémigrer un item : new mw.Api().postWithToken( 'csrf', { action: 'options', change: 'userjs-adiutor-...' } );
  • important : exécuter aussi en ajoutant global: 'update'
  • refs mw:API:Options, et à propos phab:T207448 (c'est bon, c'est corrigé)
  • refs api.saveOption() et api.saveOptions()
    • c'est surtout pour aller voir leurs codes
    • voir plutôt l'ancienne interface, parce que la nouvelle interface est complètement merdique (en particulier la visualisation de code qui est étroite comme pas possible)
    • je ne les utilise pas, à la place j'utilise postWithToken() pour pouvoir ajouter le global: 'update'
• créer un script pour obtenir le wikicode du résumé d'un diff déjà existant, pour réutiliser ce résumé
  • je sais que c'est faisable avec l'API
  • parce que ça me servirait souvent (quand le navigateur n'a pas mémorisé, et que je me retrouve à aller copier puis coller et refaire tous les nbsp, liens modèles…)
  • ça ne devrait pas être compliqué à faire, la seule question c'est où je mets ça
  • à propos, dans Chrome (chrome://settings/addresses), le toggle « Save and fill addresses » est aussi pour toutes les autocomplétions classiques d'inputs… ils ont vraiment très, très mal nommé ce réglage (ou alors, c'est qu'ils considèrent que le web ne sert plus à rien d'autre que 1) réseaux sociaux 2) boutiques…)
• rappel : cf. 219337527 et 219337526, des navigateurs de clochards à supporter… mais ça sera vraiment pour les codes exécutés d'origine, pas les gadgets optionnels (recherche code)
• wikt:Spécial:Recherche : les labels collés aux radios, ça m'horripile toujours autant
  • code : wikt:MediaWiki:Gadget-searchEngines.js (chargé ici)
  • j'ai testé vite fait, et le résultat final rendait super bien :
    • d'abord en ajoutant ces espaces,
    • puis en mettant deux espaces entre chaque radio, pour continuer de bien voir les associations radio-label
    • puis en appliquant un "font-size:95%" pour que le tout ne dépasse pas en largeur
• wikt:Spécial:Index/Utilisateur:Od1n/ : quelques anciens bacs à sable qui traînent, les faire supprimer s'il n'y a plus rien à récupérer dedans, pour alléger la maintenance sur le wiki
• le JavaScript (du Common.js) pour les boîtes déroulantes (modèles {{Boîte déroulante}} et {{Boîte déroulante/début}}) n'est pas présent dans le Mobile.js, du coup celles-ci sont toujours déroulées
  • souhaitable ou non ? penser que c'est en navigation touchscreen
  • il manque aussi un style : chercher "div.NavEnd" dans le MediaWiki:Common.css
  • edit : les Common.css/js sont maintenant chargés sur mobile (changement effectué sans prévenir sans rien), du coup changement de problématique : faut traiter les codes inadaptés, redondants… Ça doit être un tel m*rdier que je ne veux même pas regarder ça.
• autre chose, si ces boîtes sont juste après un titre de section h3 ~ h6, sur Vector et Minerva elles sont collées à la bordure en pointillés, car le titre est en "margin-bottom 0" ; voir exemple
• Discussion MediaWiki:Gadget-LiveRC.js#LiveRC et le nouveau message d'annulation :
  • faut workarounder en remplaçant manuellement dans LiveRC les PLURAL et les GENDER (dans MediaWiki:Gadget-LiveRC.js chercher « revertpage », remarquer aux lignes suivantes qu'il y a déjà remplacement de $1 et $2)
  • attention aux éventuelles branches vides ou absentes
  • il peut y avoir des espaces partout dans l'appel magicword (seule expection : « PLURAL: » doit être attaché), et le résultat est trimmé
  • pour le PLURAL, faut utiliser la valeur singulier, pluriel, ou… c'est variable ?
  • pour le GENDER, utiliser la 3^e valeur si elle existe, sinon la 1^re valeur ; je suppose que ça serait très compliqué pour déterminer le genre dans LiveRC
• C-helper : à tout un tas d'endroits, ajouter une espace entre les inputs (checkboxes, etc.) et les textes, pour aérer la présentation
  • mettre l'espace dans le <label>, de sorte que si on clique sur l'espace entre l'input et le texte ça active aussi
  • espace déjà présente à quelques endroits (minoritaires), mais : espace pas à l'intérieur du <label>, et ça utilise  , qui peut être superflu voire contre-productif
• nouvelle possibilité de charger des gadgets uniquement en cas de présence d'une catégorie : Discussion Projet:Scripts et gadgets#Template gadgets
• rendre MediaWiki:Gadget-Accessibility.js compatible avec l'aperçu rapide ; refs discussion
• MediaWiki:Gadget-DeluxeHistory.js : suivi du code de migration du format localStorage :
  • la première partie est à garder bien longtemps, car il faut vraiment que ça migre tout le monde : si on a une entrée mais sans l'entrée "expiry" de mw.storage associée (et bien celle-ci, pas l'entrée "lastUpdate" du format précédent), l'entrée sera considérée comme permanente, donc pas mise à jour, donc reste permanente…
  • la seconde partie a son intérêt, c'est un "catch all" qui est même capable de gérer le point précédent (il supprime l'entrée si elle est permanente, par contre il ne nettoie pas l'entrée "lastUpdate"), et son fonctionnement est assez sûr ; mais c'est sale d'utiliser le format interne de mw.storage (notamment, ça peut changer à l'avenir), donc essayer de ne pas la garder trop longtemps
  • liens rapides concernant mw.storage : documentation, code, code sur GitHub
• faire un script pour pouvoir visualiser une page sur les différentes skins, ainsi que sur la version mobile
  • UX : ajout d'un portlet, qui affiche un popup (lazy-load OOUI), avec tous les liens qu'il ne restera plus qu'à middle-cliquer
• faire un script pour enlever les liens sur les dates, vu que c'est une demande assez récurrente
  • deux parties : un CSS color:inherit pour masquer visuellement au plus tôt, puis un JavaScript date.textContent = date.textContent pour faire sauter les liens
  • voir les options "type" et "peers" sur mw:Extension:Gadgets#Options
  • refs Discussion module:Date#Evolution modèleDate et Discussion modèle:Date#Évolution modèle Date
• Utilisateur:Arkanosis/xdone.js : si jamais l'utilisateur a gardé la page ouverte longtemps, et qu'entretemps des sections ont été supprimées/déplacées (genre bot d'archivage), quand il va cliquer sur le lien xdone de la section, vu que ça fonctionne avec « rvsection=<numéro de section> », ça va exécuter l'API sur une autre section que celle voulue (!), ou bien aussi le numéro de section peut être devenu invalide.
  • j'y ai réfléchi, mais là, je ne vois pas comment on pourrait résoudre le problème…
• Utilisateur:Od1n/WhatlinkshereDeluxe.js : permettre de configurer la limite avant interruption des requêtes (le « 100000+ »)
• cartes géoloc multiples : augmenter espacement entre carte et liens toggle, pour éviter clics accidentels sur la carte au lieu du lien (a fortiori en version mobile)
• remplacer le gadget ext.gadget.getStrDateToday par du javascript natif Date.prototype.toLocaleDateString()
  • exemple : 160725646
  • update : plutôt Date.prototype.toLocaleString() (exemple : 173975317)
  • rappel : attention, parfois c'est avec des underscores (e.g. "j_m_a"), notamment pour des urls ; il faut donc aussi implémenter mw.util.getUrl()
  • problème, sur le wiki il y a des fonctions locales (chercher "getStrDateToday" ainsi que "getStrDateCeJour") qui traitent aussi les numéros de semaines
    • refs en:ISO week date
    • pour le code qui va bien, ça se trouve ici.
    • le code est compliqué et il va bien falloir le mettre quelque part…
      • mw.libs.frwiki.getISOWeekNumber(), mw.libs.frwiki.calculateISOWeek() ?
      • cependant, répéter les codes avec toLocaleString() dans toutes les pages c'est vraiment pas l'idéal…
      • mw.libs.frwiki.nomdusupermoduleici/.moisAnnee()/.jourMoisAnnee()/.calculateISOWeek() ? (mélange français / anglais là…)
    • on peut utiliser une IIFE, pour ajouter un function scope, permettant de garder des variables, au lieu de tout calculer à chaque appel de la fonction
      • pas forcément une bonne idée : penser au cas d'une page restant ouverte longtemps, avec un script qui s'y exécute en ultérieurité
  • Escargot a supprimé le gadget : 228681108 ; merci à lui
    • mais du coup, pour la problématique des numéros de semaines ?
  • de plus, la librairie Moment a été dépréciée (refs meta:Tech/News/2025/19), et elle est actuellement utilisée dans quelques scripts utilisateur
    • le mediawiki.DateFormatter qui est mentionné dans la tech news : documentation, code
      • n'exporte pas de globales, utilisable seulement via require() donc à l'intérieur du ResourceLoader : hyper pénible pour développer avec
      • ne propose rien pour les numéros de semaines ISO (et c'est la seule partie qui demande un peu de longueur de code, les autres parties c'est genre 2 ou 3 lignes)
      • ratio utilité / emm*rdement extrêmement défavorable : ce mediawiki.DateFormatter n'est pas intéressant pour le cas présent
• créer un script pour disposer de liens « modification précédente / suivante » toujours positionnés au même endroit, pour pouvoir naviguer plus facilement entre les diffs (là les liens se décalent verticalement, selon la longueur des résumés de diff)
  • j'ai repéré par hasard qu'il existe d'origine un élément .mw-diff-revision-history-links avec ces liens, qui est en "display:none". à étudier.
• trouvé pourquoi ça ajoute un <div id="toolbar"> vide au dessus de la zone de modification, c'est parce que le module CommonEdit a une dépendance sur le module MonobookToolbar, et donc ben ça l'exécute
• FOUC dégueulasse le retour, cf. 153050677 et 153050900
  • voir par exemple sur Aide:Accueil, rien que ça
  • penser aux modèles enroulés au départ, et déroulés au départ
  • recherche : insource:"titre-section-deroulante"
• Utilisateur:Arkanosis/xdone.js : ajouter une "user option" pour ajouter une demande de confirmation au lieu d'exécuter sans prévenir
• MediaWiki:Gadget-ExternalSearch.js :
  • lorsque input vide :
    • les liens devraient envoyer vers les vraies homepages des moteurs de recherches, sans paramètres
    • les liens ne sont actuellement pas left-cliquables
  • lorsque input rempli, les hrefs de ces liens devraient contenir la recherche en cours :
    • recherche middle-cliquable
    • plus joli / moins surprenant dans la status bar
    • mais attention aux perfs : c'est à faire en input onchange... notamment, mettre en cache les éléments DOM ; un debounce pourrait aussi être bénéfique
  • c'est con de mettre des radios pénibles à cliquer, alors que ça fait pareil (mais en beaucoup moins chiant) si on clique directement sur les liens
    • remplacer tous ces radios par une simple série de liens : « Recherche externe : Google • Bing • etc. »
  • à propos, origine préhistorique : 9447902, 31573257
    • le moteur de recherche interne a considérablement évolué depuis lors (CirrusSearch)
    • donc, est-il encore bien utile ? mettre sur la table le sujet de l'arrêt de son activation par défaut. edit, posté : Discussion Projet:Scripts et gadgets/2018#Désactivation par défaut de ExternalSearch
• MediaWiki:Gadget-CatRename.js :
  • Je peste à chaque fois à cause du bouton "Renommer" placé à un endroit complètement tordu
  • … et qu'à chaque fois je clique par erreur sur le bouton "… ou faire faire la tâche par un bot", avec edit inopiné à la clé
  • évidemment j'avais déjà regardé, et le problème est au niveau de l'OOJS-UI mes couilles, qui n'est pas flexible même pour simplement positionner un putain de bouton
• scripts de toolbars : du point et de la mise au propre à faire, en particulier concernant les race conditions
  • liens vers les codes des gadgets toolbars, parce que ça me pète les couilles pour les avoir à chaque fois :
    • MediaWiki:Gadget-mediawiki.toolbar.js
    • MediaWiki:Gadget-ForceMonobookToolbar.js
    • MediaWiki:Gadget-MonobookToolbar.js
    • MediaWiki:Gadget-MonobookToolbarStandard.js
    • MediaWiki:Gadget-MonobookToolbarSources.js
    • MediaWiki:Gadget-MonobookToolbarPatrouille.js
    • MediaWiki:Gadget-MonobookToolbarNotif.js
    • MediaWiki:Gadget-MonobookToolbarSmiliesAlien.js
    • MediaWiki:Gadget-MonobookToolbarChangeCase.js
    • MediaWiki:Gadget-MonobookToolbarDiacritiques.js
    • MediaWiki:Gadget-MonobookToolbarLang.js
  • rappel : ça commence avec la dépendance "user.options" qui manque dans MediaWiki:Gadget-MonobookToolbar.js
    • mais elle n'est pas straightforward à ajouter, car cela rend le code asynchrone, et cela devient à gérer dans les scripts enfants
  • voir aussi :
    • mw:Manual talk:Custom edit buttons#Getting a bit complicated, doesn't it?
    • fonction addCustomButton() dans le MediaWiki:Common.js
  • codes utilisateurs :
    • Utilisateur:Salsero35/monobook.js (qui dans les préférences a décoché les toolbars natives, et coché le gadget ForceMonobookToolbar et quelques toolbars)
    • discussion : Wikipédia:Questions techniques/semaine 20 2018#Fonctions javascript
    • évidemment plein d'autres "DeluxeBar", petite recherche
  • pour info, l'ancienne toolbar va être complètement supprimée : mw:Contributors/Projects/Removal of the 2006 wikitext editor
    • donc en quelque sorte, il faudra toujours forcer notre truc local qui imite les boutons style ancienne toolbar
    • à surveiller, j'imagine qu'ils vont encore nous traficatouiller les options, dépendances, etc.
  • updates en vrac :
    • comme prévu, le bouton "toggle syntax coloring" a disparu, par contre ça me crée encore une #toolbar vide de 22px de haut… ça gaspille de la place et surtout, ça sautouille
    • à mettre à jour (quand la situation sera un peu stabilisée) : effet de bordure au survol bouton
      • à première vue, l'idée me paraît bonne, plutôt pour garder un tel système
      • faut mettre à jour les sélecteurs (img n'est plus en child node)
      • ces bordures posent des petits soucis rapport à la place qu'elle prennent, pourquoi pas tester avec un effet de réduction opacity ?
  • encore notes :
    • pdd d'Arkanosis, notamment Discussion utilisateur:Arkanosis#Page
    • n'est plus à jour : mw:Manual:Custom edit buttons#Classic edit toolbar
  • MediaWiki:Gadget-MonobookToolbar.js, important :
    • résolution de bugs/régressions lorsque paramètres undefined
    • utilisation du module jquery.textSelection (code) pour simplicité/robustesse (comme ancienne toolbar upstream)
    • refs gerrit 317079, notamment l'ancien toolbar.js
    • à terme on pourra transformer Utilisateur:Stef48/signature.js en un simple one-liner :) (utilisé par Utilisateur:Mandariine/common.js, mentionné sur Wikipédia:Le Bistro/6 novembre 2018#Fin des barres d'éditions custom ?)
  • encore notes en vrac :
    • voir MediaWiki:Gadget-mediawiki.toolbar.js, copie locale, avec déjà quelques modifications effectuées (exemple), ajouté en dépendance ext.gadget.mediawiki.toolbar sur des pages utilisateur
    • pour rappel, MediaWiki:Gadget-MonobookToolbar.js et MediaWiki:Gadget-mediawiki.toolbar.js font doublons, seraient à terme à uniformiser et fusionner
      • remarquons aussi l'existence de MediaWiki:Gadget-lib-beau.js, qui hamdoullah est inutilisé
        • c'était utilisé par MediaWiki:Gadget-searchbox.js, mais il utilise maintenant pl:MediaWiki:Gadget-nuxedtoolkit.js
        • concernant pl:MediaWiki:Gadget-searchbox.js, ça semble être passé de pl:MediaWiki:Gadget-lib-beau.js à pl:MediaWiki:Gadget-nuxedtoolkit.js puis à pl:MediaWiki:Gadget-lib-toolbar.js…
    • Aide:Barre d'outils d'édition aura peut-être besoin de mises à jour à l'avenir
• MediaWiki:Gadget-verifEbauche.js : requêtes API largement optimisables
  • fait, voir modifs d'octobre 2022, et en particulier 197899466
  • documentation API templates
  • avec &tltemplates=Modèle:Ébauche, hop on ne chope que ce qui nous intéresse
  • on pourrait aussi interroger pour toutes les pages (au lieu d'une requête par page), mais attention :
    • nombre de pages en un coup à limiter à 50 (déjà eu cette problématique, voir Utilisateur:Od1n/ProtectionsModeles.js)
    • nombre de templates limité (tllimit) (à paginer ?), et la limite est globale pour toutes les pages interrogées
    • mais avec le &tltemplates=Modèle:Ébauche, ça change la donne…
    • d'autre part, les liens ne seraient plus coloriés progressivement, mais par gros chunks (pas un problème en fait)
  • on pourrait aussi faire en sorte de ne pas interroger plusieurs fois pour la même page
  • empêcher plusieurs exécutions simultanées ?
  • pour inspiration, gadget similaire, au code très propre : MediaWiki:Gadget-verifHomon.js
• MediaWiki:Gadget-Evaluation.js :
  • permettre de saisir les projets à ajouter, au lieu d'avoir à configurer une liste figée dans le javascript utilisateur…
  • idéalement, avec autocomplete et/ou vérification existence du wikiprojet
• Liens de changement de carte de géolocalisation (par exemple dans les infoboxes de villes) :
  • garder en "placeholder" le lien de la carte actuellement affichée, parce que là c'est laborieux pour s'y retrouver quand on switche (obligé de lire les libellés, au lieu de "repérer spatialement")
• MediaWiki:Common.js :
  • proposer le kickage de la fonction Rebours() (modèle {{Compte à rebours}})
  • message posté : Discussion Projet:Scripts et gadgets/2018#Proposition de suppression du code de compte à rebours
  • pour faire le point sur les utilisations : wstat
• Projet:Scripts et gadgets/Refonte Common.js avec jQuery :
  • "charogner" cette page s'il y a des trucs à éventuellement récupérer dessus
  • puis kicker cette page qui n'est plus à jour et me complique régulièrement la maintenance
  • et retirer sa mention dans l'en-tête de MediaWiki:Common.js
• mw:ResourceLoader/Core modules : un bon paquet de proprage à faire sur cette page…
• Wikidata, d:User:Od1n/sortValues.js (fork de d:User:Seb35/sortValues.js) :
  • si chacune des deux lignes a une date, comparer les lignes selon la date
  • sinon, en fallback comparer les versions, comme déjà actuellement
    • liens stack overflow : 47823116, 47917031
    • a priori, c'est la version "fluent avec padding" qui est la moins pire des deux
  • la difficulté c'est de récupérer simplement la putain de date, et idéalement directement au format ISO
  • éventuellement poster un message pour demander si quelqu'un a la technique qui va bien pour obtenir la p— de date
• rendre les tables avec "mw-collapsible" togglables avec clic sur tout le caption, comme j'ai déjà fait pour d'autres systèmes déroulants (palettes, etc.) dans le Common.js
• dans MediaWiki:Common.js, remanier le code "Diaporama" (pour {{Animation}}) :
  • pour être compatible avec la prévisualisation rapide
  • aussi pour gratter tous les "Diaporama" dans la minification du javascript
  • signalé sur Discussion Projet:Scripts et gadgets/2017#JavaScript associé au Modèle:Animation et Discussion modèle:Animation#Besoin de réécriture du JavaScript
• BoutonsHelpers.js : jQuery UI déprécié… ces boutons étant indispensables, agir proactivement sans attendre que le module disparaisse
  • MediaWiki UI lui aussi déjà déprécié (la bonne blague)
  • OOjs UI une PITA à utiliser, comme toujours la programmation d'UI avancée avec des widgets est loin d'être des plus agréables…
  • du coup, réfléchir à une nouvelle interface sans tout ce bazar, sans dialogs, plus simple mais en restant agréable d'utilisation
• Dans les historiques, rendre le bouton « Comparer les versions sélectionnées » middle-cliquable
  • Pour simple rappel, il y a ce javascript exécuté à la soumission du form : mediawiki.action.history.js
  • Comme je me fais avoir à chaque fois : il y a deux boutons (celui dont j'ai l'habitude en haut, et aussi un autre en bas de la page)
  • Et voilà, script créé : Utilisateur:Od1n/CompareVersionsButtonsToLinks.js (refs aussi ajout dans mon common.js)
• DeluxeHistory/HistoryDeluxe : j'utilise actuellement mon fork perso (refs Utilisateur:Od1n/common.js, Utilisateur:Od1n/DeluxeHistory.js, Utilisateur:Od1n/DeluxeHistory.css)
  • l'expérience montre que les codes des forks ont tendance à moisir rapidement, et que ce sont des plaies niveau rajout de maintenance
  • donc, migrer vers le gadget upstream (MediaWiki:Gadget-DeluxeHistory.js)
  • chargement (continuer à charger via le common.js ? ou alors cocher le gadget dans les préférences ?)
    • comme d'habitude, faire en sorte de n'exécuter que lorsque nécessaire
    • dans le common.js, on pourrait faire mw.loader.load('ext.gadget.DeluxeHistory'), probablement plus performant (cache Resource Loader) que importScript()
      • mais dans ce cas, mw.user.options.get('gadget-DeluxeHistory') est false, et le CSS est chargé deux fois (une fois par le ResourceLoader, puis une fois par le JavaScript)
    • pour rappel, en.wiki a un système avec des sous-gadgets hidden "machin-core"
  • configuration (affichage sur liste de suivi ?)
  • attention : les entrées localStorage n'ont pas le même nom, penser à nettoyer une fois le switch accompli
• newCollapsible (js, css) :
  • fork pas maintenu, n'est plus à jour par rapport à la version upstream (notamment, risque de problèmes divers de compatibilité)
  • activé par défaut pour tout le monde…
  • cause des warnings dans la console javascript…
  • l'idéal serait de supprimer le gadget, mais à défaut, on pourrait assez facilement supprimer les warnings avec cette nouvelle feature : Gadget peers
  • pour prévention étourderie : utilise des classes différentes (e.g. fr-collapsible vs. mw-collapsible)
  • exemples d'utilisation : {{Wikiprojet}} - PHP#Historique des versions
  • version upstream : historique 1 - historique 2
  • l'un des soucis principaux, la gestion des table captions, a été corrigé en upstream : ba8f2a605c8d
  • petit souci de mise en forme, à éventuellement corriger en local en attendant fix upstream : There should be a space between span.mw-collapsible-toggle and its preceding content
    • patch en attente : gerrit:338045 (février 2017, si jamais ça traîne des mois : relancer un coup, mettre du CSS local en attendant…)
• encore des réparations à faire : wikt:Wiktionnaire:Questions techniques/février 2017#Mise à jour de MediaWiki:Gadget-searchEngines.js
• pouvoir personnaliser le nombre de palettes avant autocollapse (default 1)
  • plus clair : nombre de palettes déclenchant l'autocollapse (default 2)
  • race condition ordre exécution Common.js / JS perso : qui peut le plus peut le moins, supporter les deux cas de figure
  • à première vue il faudra une légère refactorisation dans le Common.js, de sorte à avoir une fonction dédiée à l'initialisation des états toggle et pouvant être re-appelée en cas de changement valeur autocollapse
• tooltipRef (code, css, documentation) :
  • les liens externes dans les tooltips n'ont pas l'icône à droite
  • utilise le module jquery.ui.position qui est signalé comme déprécié
    • cf. phab:T142418 et gerrit:302732
    • voir du côté de mw:OOjs UI/Widgets/Popups (edit : ou pas.)
    • un premier correctif appliqué, cf. Discussion Projet:Scripts et gadgets/2017#Gadget tooltipRef : module déprécié jquery.ui.position
      • il faudrait corriger le problème de la position du tooltip après window resize (event handler ; exécuter le moins possible lorsque pas de tooltip, et debounce)
    • les deux autres warnings (jquery.ui.widget et jquery.ui.core) viennent d'ailleurs, à localiser aussi
      • c'est le gadget osm.js (activé par défaut !), cf. Discussion Projet:Scripts et gadgets/2017#Gadget OpenStreetMap : modules jquery.ui dépréciés
  • fonctionnalités dans le mode par défaut "clic pour ouvrir" (doivent être configurables) :
    • pouvoir garder plusieurs références ouvertes
    • pouvoir fermer la référence en cliquant en dehors
  • fonctionnalités dans le mode "ouverture au survol" :
    • ne pas fermer si ensuite survol du contenu de la référence (parce que là on ne peut pas cliquer sur les liens)
    • performances au chargement page (redondance sélecteurs jquery)
    • si on quitte-revient rapidement sur la réf avant fin timeout, le tooltip est quand même supprimé puis réaffiché vu qu'il y a un close dans la function open
• C'est toujours la m*** pour s'y retrouver dans les onglets navigateur
  • virer le suffixe « — Wikipédia », toujours ça de pris pour alléger
  • changer la favicon, par exemple :
    • première lettre titre page (sans namespace) (mais pourrait-on aussi caser le namespace ?)
    • + couleur différente (en background ?) pour actions (modification en cours, historique, diff…)
    • et sans oublier les pages spéciales (liste de suivi, contributions…)
• LiveRC :
  • notes : Utilisateur:Od1n/Développement LiveRC • script perso : Utilisateur:Od1n/LiveRC.js • utilisation : ajouter fork à la query string
  • Discussion MediaWiki:Gadget-LiveRC.js#Erreurs JavaScript dues à un nouveau rc type non implémenté
  • performances désastreuses, il y a d'énormes goulots aisément corrigeables
  • watchCategories : Catégorie:Utilisateur projet pédagogique renommé en Catégorie:Utilisateur Projet/Pédagogique (aussi, vérifier que le slash ne pose pas problème)
• Économie de la requête de MediaWiki:Common.js/edit.js, en le transformant en gadget hidden ?
• TagFilterDeluxe :
  • Lien pratique : listing API des tags
  • Il y a des tags en doublon, différenciés uniquement par la casse, exemple : « Suppression de références » et « suppression de références ». Dans cet exemple, seule la version lowercase est fonctionnelle, il faudrait vérifier si la situation est la même avec chaque doublon. Bien entendu, trouver l'origine de ces doublons et la corriger.
• Utilisateur:Od1n/WhatlinkshereDeluxe.js : en checkant pour un modèle inexistant (lien rouge), il semblerait que les pages incluant ce modèle soient comptées en double : une fois en inclusion et une fois en lien
  • En fait, toute page contenant un lien et une inclusion est comptée deux fois
• Les pages chargées avec des liens #ancrés se positionnent pas correctement sur l'ancre. Peut-être un JS qui interfère. (pensée de l'instant : purée, c'est vraiment casse-couilles ce truc)
  • un workaround a été implémenté : Common.js, DIMS 1, DIMS 2
  • le $(document).ready est redondant vu qu'il y a le $(window).load
  • idéalement il faudrait exécuter plus tôt que le $(window).load, mais je doute que cela soit possible
• MediaWiki:Common.js/edit.js :
  • fonction addCharSubsetMenu : envisager le rajout d'un event à la keyup pour mettre à jour l'UI lorsque défilement au clavier
  • nombreuses choses améliorables dans ce fichier
  • conversion en "gadget hidden" ou un truc dans le genre, de sorte à ne pas ajouter une requête http
  • j'avais fait quelques jqueryfications de code, mais pas satisfait à cause de l'impact sur les perfs
  • déluge de race conditions avec les codes utilisateur et gadgets rajoutant des charsets, actuellement c'est tout pété
  • restauration position du <select> : pour limiter les "local storage set" (et donc surtout, les écritures disques, ssd parano), mettre un throttle/debounce (de sorte à ce que ça enregistre quand même bien la valeur dans les différents scénarios d'utilisation ; explication visuelle)
• Gadget à voir : ContribColors (ainsi que le fork se trouvant en pdd)
• Gadget pour ajouter un <select> de namespace devant la zone de recherche en haut à droite fait
  • ajouter un système de cache
  • highlight aussi si saisie "cross-namespace", d'alias namespace ou de namespace canonical
  • à corriger : « saisie sans namespace puis validation avec Entrée » envoie sur la page de recherche…
  • rappel : les cookies d'HistoryDeluxe ajoutent plus de 4 ko d'overhead à chaque requête
• Popup pour visualiser rapidement les références
  • cf. Discussion Wikipédia:Atelier accessibilité/Archives accessibilité 2011 - second semestre#Une solution intelligente pour consulter les <ref> ?
• Demande de modularisation des modèles déroulants par D^r Brains sur WP:DIMS
  • Par contre on a encore le bug des autocollapse des palettes qui compte aussi les boîtes déroulantes
    • Le problème est que les « {| class="collapsible[ collapsed]" » (donc sans rapport avec {{Boîte déroulante}}) sont gérés par le script des palettes…
  • Depuis lors, les boites déroulantes sont gérées par un script séparé, mais il y a d'autres modèles ; cf. Discussion Projet:Modèle/2016#Modèles succession masqués par défaut
• Ne pas scanner tout le document mais seulement depuis l'id du contenu de l'article... Lien très utile : Projet:JavaScript/Développeurs
• Projet:JavaScript/Aide API : mise à jour 1.17
• Gadget DeluxeHistory (notice • code JS • code CSS) :
  • (2017-11-16) le gadget est exécuté sur toutes les pages, il faudrait exécuter moins de choses lorsqu'il n'est pas utilisé, en particulier la récupération des données du localStorage
  • Voir aussi la version de D^r Brains : Utilisateur:Dr Brains/HistoryDeluxe.js
    • C'est étrange, avec ce script D^r Brains apparaît en bleu (exemple), pourtant il ne semble pas y avoir de traitement spécifique ah ah... et moi j'apparaît en jaune ! simple inversion (volontaire ou pas ?) dans le CSS
    • comportement bizarre lors de la sélection de versions à comparer (input radio), y'a une ligne qui perd sa couleur
      • apparemment conflit avec scripts généraux du wiki (la classe ajoutée au <li> est overwritée), a priori il faudrait donc faire comme l'ancienne version du script : créer un <div> à l'intérieur du <li>
      • s'est corrigé tout seul MediaWiki 1.18 ?
  • répercuter les modifs du 22 août 2011 (et éventuellement ultérieures, au moment de la lecture du présent message) de Utilisateur:Dr Brains/HistoryDeluxe.js (d · h · j · ↵)
    • compatibilité avec les « modifications récentes améliorées » (enhancedchanges.js) – activable dans « Préférences → Modifications améliorées »
    • voir aussi bistro du 22 août 2011
  • charger le script seulement lorsque nécessaire (pages Spécial: ?)
    • I mean, actuellement la lecture du cookie est effectuée sur toutes les pages
    • voir pour cette histoire de multiple submit POST après le login
  • corriger bug lorsque présence d'une révision masquée (discussion • exemple) (et penser aussi : si pas de lien sur "actu / diff")
  • ne marche pas si une seule ligne et celle-ci faite par IP (exemple)
  • les icônes marchent pas ?
  • documentation pas à jour : Wikipédia:Historiques en couleur (la partie avec l'installation manuelle dans le monobook.js)
  • à voir – les admins ont des pitites cases en plus ?
• Gadget BandeauxPortails (notice • code JS • échange sur ma pdd • encore échange) :
  • navigation clavier "up/down" ?
  • performances autocomplétion
  • charset avec IE
  • une requête ajax à chaque affichage d'article (fonction BandeauxPortails_Update), voir s'il serait possible de faire sans (ajouté ici)
• SommaireCompactCategorieDeluxe aurait besoin d'un peu de "modernisation" du code
  • refs au passage cette discussion
• Spécial:Préférences#mw-prefsection-gadgets section « Caractères spéciaux » :
  • la blinde de race conditions à corriger, c'est bon à tout redévelopper en asynchrone
  • sans oublier que c'est aussi utilisé (enfin… c'est actuellement pété) dans des javascripts utilisateur

• {{Lien vidéo}} / Module:Biblio/Lien vidéo : c'est infect le paramètre « medium » affiché en font monospaced, etc.
  • c'est la même mise en forme que les indications de langue / format, mais c'est adéquat seulement pour des textes courts
  • or là, il y a souvent des textes longs, cf. wstat.fr
• classe cachelinks : clarifier la situation
  • cf. dans le Common.css et dans le Mobile.css
  • problématique : dans les modèles biblio, ce sont des liens externes générés par MediaWiki, qui ont donc déjà une classe external pour styliser ; notre définition de couleur y est donc redondante
  • il existe une couleur "de base" (i.e. default/fallback), puis certaines skins modifient légèrement la couleur
  • couleurs que j'avais listées : cologneblue : #36b / modern : #36b / monobook : #36b / vector : #36b / minerva : #36c / vector 2022 : #36c / timeless : #37a
    • j'ai vérifié vector 2022 et minerva en dark mode, ce sont les mêmes couleurs
  • il manque les :hover, :active, :visited, et même des combinaisons
  • quelques refs :
    • mediawiki.skin.defaults.less (styles de base)
      • chercher @color-link-external, @color-link-external--visited et @color-link-external--active
      • ce sont les couleurs par défaut (pour fallback)
    • screen-common.less#371 (skin Timeless)
      • remarquer qu'il y a :hover, :visited et même la combinaison :visited:hover
    • faut encore se taper toutes les autres skins
  • j'aimerais bien une classe external-like, pour les gadgets JS qui générent des <a>
    • et cette classe serait à mettre directement sur l'élément <a> (càd pas sur un élément parent/conteneur)
    • edit : ça appliquerait la couleur bleu ciel, mais à la différence des liens externes normaux, ça n'ajouterait pas l'icône CSS, donc plutôt nommer la classe external-color-like ; j'ai parlé de cela vers la fin de cette discussion
  • utilisé par MediaWiki:Gadget-ArchiveLinks.js
  • il existe par ailleurs MediaWiki:Gadget-WikipediaLibrary.js
  • MediaWiki:Print.css cache les containers cachelinks (refs 37489456)
  • pour rappel : 60041953, 182753878 et 182754007
    • à la base, cette classe avait été ajoutée spécifiquement pour le gadget JS Wikiwix
    • et l'ajout aux modèles de biblio est ultérieur (voir avec les liens du résumé de modif de 237881848)
  • aussi présent dans l'horrible ramassis de règles de filtrage de MediaWiki:Gadget-verifAncres.js
• Module:Linguistique.inparentheses() :
  • c'est vraiment à lui de prépender l'espace ; parce que si à l'avenir on y implémente les langues asiatiques, ils utilisent des caractères "parenthèses fullwidth" et ne mettent pas d'espace
  • les problèmes, c'est surtout dans les codes appelants, qui souvent rajoutent aussi une espace, à tort
  • aussi, il serait arguably préférable de retouner chaîne vide lorsque input nil (ou false…), si on considère que le rôle de la fonction est de permettre de "string concaténer sans se poser de question"
    • mais attention, important : c'est parfois utilisé dans des "linguistic.conj" (table.concat sous-jacent), et là ça s'attend à ce que ça soit nil (pour que la valeur soit ignorée)
      • voir Module:Infobox/Usine et Module:Infobox/Centrale ; mais de toute façon, ces "linguistic.conj" sont inadéquats, et à remplacer par un "string concaténée si existe"
    • idéalement, supporter les deux cas (return nil ou tel quel) dans les appelants, par précaution
      • pour rappels : attention à ne pas "string concaténer" nil (erreur Lua) ; et si table.concat (éventuellement en sous-jacent), une chaîne vide y serait indésirable
  • refs commons:Module:Linguistic et wikidata:Module:Linguistic
    • oui, ils divergent : "return nil" vs "return tel quel", et "pas prepend espace" vs "prepend espace"
  • autre problématique : les appelants qui encadrent avec un <small>
    • le <small> contient l'espace de séparation, alors qu'elle devrait être en dehors
    • on perd aussi l'intérêt "early return lorsque absent", visant à permettre de "string concaténer sans se poser de question"
    • c'est en fait une problématique "d'imbrications dont les ordres sont en conflit", faisant qu'il n'y a pas de résolution simple/directe du problème
    • meilleure solution trouvée : ajouter une fonction "inparenthesesSmall"
  • autre détail : probablement inutile de recourir à une entité HTML  
• {{Accueil actualité}} et surtout {{Accueil actualité/Affichage}} :
  • je n'aime vraiment pas la séparation des deux listes « évenements en cours » avec un saut de ligne : à la fois, ça casse l'harmonie et la distinction n'est guère visible
  • l'affichage était pas mal auparavant : la séparation était « __'''–'''__ », depuis la première version (avec un remaniement dans 186747564)
  • la séparation avec un saut de ligne provient de 205949378
  • pas d'objection sur le principe, la difficulté c'est surtout de réaliser cela, et proprement
• {{date de naissance}} et {{date de décès}} : je viens de retirer le paramètre agePrefix d'un article et de quatre brouillons / bacs à sable (exemple)
  • ces utilisations devaient probablement venir en grande partie de l'éditeur visuel (TemplateData)
  • il reste peu d'occurrences : insource:agePrefix
  • envisager de supprimer ce paramètre de {{date de naissance}} et {{date de décès}} (plus précisément, de leurs documentations)
    • un paramètre en moins dans l'éditeur visuel, c'est toujours bon à prendre
  • le paramètre serait en fait encore utilisable, car les paramètres Module:Date prend tous les paramètres, en "pass through" (i.e. frame + frame parente)
    • idéalement ça serait à arranger, mais implémenter une distinction des frames serait-il vraiment possible / souhaitable ?
    • remarquer qu'il existe un mode nogetparent ; voir dans {{date de naissance et âge}} : 228742989
  • le paramètre agePrefix est vraiment utilisé par {{date de naissance et âge}} (et uniquement par lui)
• {{petit}} (alias {{small}}) : un grand bravo à celui qui a eu la merveilleuse idée de mettre deux <small>…
  • aujourd'hui, nous en sommes à 93 567 inclusions de ce modèle tarté
  • proposition, à réfléchir :
    • y aller à la bourrin et passer le modèle à un seul niveau de small
    • surtout que depuis lors, le web est devenu "mobile first" (et c'est un désastre), et aussi que maintenant les textes sont PUTAIN DE ÉNORMES partout
    • argument complémentaire : principe de moindre surprise
    • éventuellement créer en remplacement un modèle {{très petit}} (ou {{toupetit}}, lol)
      • mais ça me semble foireux : il me semble judicieux de ne pas envisager plus loin qu'un seul niveau de "smaller"
      • néanmoins, il y aurait peut-être le cas de texte très gros à la base (genre titre d'infobox), où une réduction plus prononcée serait souhaitée
• mise en italique des liens dans {{Article détaillé}}, etc., problématique encore présente à ce jour : 127416820
  • technique encore d'actualité : {{Article détaillé|Souvenirs entomologiques{{!}}''Souvenirs entomologiques''}}
  • joli mais trop magique : {{Article détaillé|''Souvenirs entomologiques''}}
  • moins joli mais plus clair : {{Article détaillé|''[[Souvenirs entomologiques]]''}}
    • et plus simple à implémenter : il suffit de chercher s'il y a des square brackets
  • la problématique n'aurait pas déjà été abordée quelque part ?
  • il faudrait que cela soit factorisé, de sorte que tous les modèles de la série aient la fonctionnalité sans avoir à la réécrire pour chacun
• au hasard d'une recherche au sujet des strip markers, remarqué que la détection est erronée dans Module:InfoboxImage#L-173
  • cela matche l'ancien format, qui a quand même disparu depuis 2015…
  • avant de corriger : pas fonctionnel depuis la première version du module, qui date de 2016, sans que cela ne semble déranger ?
  • remarquer que la détection est correcte dans Module:Infobox/Image double##L-174, créé en 2024 (et correct depuis le départ, cela n'a pas été corrigé après coup)
• {{RFC}} : permettre d'obtenir un lien externe plutôt que obligatoirement une référence ?
  • exemple : UTF-8#Liens externes (remarquer les références qui se retrouvent en toute fin de page)
• dark mode : rencontré des backgrounds gris dans l'entête infobox au lieu que ça soit entièrement noir :
  • Belgique > {{Infobox Pays}} (contient effectivement des <p> manuels) > {{Infobox V3/Début}}
  • j'étais sur le point de faire des .infobox p:not(.entete p):not(.notheme) dans le MediaWiki:Vector-2022.css, mais ça aurait été trop ignoble
  • c'est déjà une telle accumulation de rustines que je n'ai vraiment pas envie d'en rajouter, surtout que là ça casserait la consistance du code
  • faudrait évaluer la situation : de tels <p> dans des entêtes infobox, ça se rencontre ailleurs/beaucoup, ou pas ?
• {{Coord}} / Module:Coordinates : éventuellement permettre de spécifier "geoshape" :
  • exemple : Prison de la Santé#/maplink/0 versus Nicolas Sarkozy#/maplink/0
  • actuellement ça utilise l'ID wikidata de la page actuelle (code), et c'est "hardcodé" vu que {{Coord}} ne transmet pas "extraparams"
  • pourquoi pas aussi pouvoir désactiver geoshape et économiser une requête
• les palettes de navigation sont maintenant affichées sur mobile (faudrait retrouver les tickets Phabricator, etc.), mais y'a rien qui va :
  • il n'y a pas les styles, notamment pour le background des cases, parce que là… les palettes ont un background transparent !
  • le lien "afficher / masquer" ne fonctionne pas
• boîte {{Autres projets}} sur mobile, y'a rien qui va :
  • il n'y pas les styles "boite-grise"
  • une partie des styles nécessaires (border-width, border-style, margins…) se trouve en fait dans la classe "boite-a-droite"
    • c'est-à-dire que "boite-grise" ne peut présentement pas être utilisé séparément de "boite-a-droite" ; peut-être que c'est bien comme ça, ou pas
  • lorsque la boîte ne flotte pas à droite (parce qu'il manque le CSS float, ou parce que la fenêtre est étroite), la boîte se trouve au-dessus de la section "Articles connexes", or c'est cette dernière qui devrait être prioritaire (navigation dans le même projet)
    • mais je ne vois pas vraiment de solution "moins pire"
  • il manque aussi les icônes (e.g. classe "commons" pour Commons)
  • et autre problème, cette fois sur desktop avec fenêtre étroite : il y a un CSS "media query" pour enlever le float, mais il reste un margin left et la boîte ne prend pas toute la largeur
• {{Catégorisation homonymie pour XTools}} effectue une inclusion de {{Wikiprojet/todo}}
  • bien entendu la margin-top qui m'a fait bondir — fait : 229505403 et 229505507
  • inclusion inattendue, risque de casser le 1^er si le 2^e venait à, par exemple, passer du modèle au module — fait, documenté : 229505244
• doublon entre Module:Correction syntaxique et Module:Check for unknown parameters
  • signalé dans 150425473
  • notre Module:Check for unknown parameters est outdaté, par exemple il manque 688672621 (support des nom de paramètres vides : | = value)
• passage en SVG des flèches dans les "navigateurs" des infoboxes V3
  • première tentative, échec : 223686929
  • c'est parce qu'il faut ajouter viewBox et/ou width/height (encore à tester/clarifier)
  • refs Stack Overflow : Why don’t SVG images scale using the CSS “width” property?
  • en profiter pour optimiser les fichiers, avec la commande Inkscape + Scour
  • refs can of worms : Wikipédia:Demande d'intervention sur un message système/Archives3#MediaWiki:Common.css#L-959 – Icône de barre d'outils
  • liens vers les fichiers : ArrowLeftNavbox.svg et ArrowRightNavbox.svg
  • et aussi, pour traiter toute la série : ArrowUpNavbox.svg et ArrowDownNavbox.svg
  • rappel : aussi dans le MediaWiki:Gadget-Mobile.css
• récapitulatif (non exhaustif) des modules / modèles de biblio :
  • Module:Biblio/Article : {{Article}} et {{Chapitre}}
  • Module:Biblio/Ouvrage : {{Ouvrage}}
  • Module:Biblio/Lien web : {{Lien web}} et {{Lien brisé}}
  • Module:Biblio/Lien vidéo : {{Lien vidéo}}
  • Module:Cite archive : {{Cite archive}}
  • Module:Biblio/Article encyclopédique : inutilisé ? (mais j'ai trouvé {{Article encyclopédique}}, qui utilise Biblio.Chapitre)
  • et les modules communs : Module:Biblio, Module:Biblio/Commun et Module:Biblio/Références
  • peut-être à l'avenir : {{Lien archive}}, vu qu'il serait à convertir en Lua (cf. cette discussion)
• dans les briques d'infoboxes V2, la fameuse stupidité sans nom d'avoir mis les <tr> (ou équivalent wikicode |-) d'ouverture à la fin du modèle, donc qui ouvre la ligne de la brique suivante…
  • à cause de cela, exemple de bricolage ignoble qui a été nécessaire : 114894559 (pouvant causer des <tr> vides dans le résultat)
    • j'avais aussi noté 142150712 (je ne sais plus trop en quoi c'était pertinent, là je suis simplement en train de faire le ménage dans des vieux bookmarks)
    • à toutes fins utiles, c'est sur l'article YouTube que j'avais remarqué un <tr> vide, fin décembre 2023 (ce <tr> vide ne semble plus présent actuellement)
  • dans des recherches pour préparer le chantier, j'avais repéré (non exhaustif) deux infoboxes avec des trailing <tr>'s : {{Infobox Cours d'eau}} et {{Infobox Voie de Paris}}
  • et je déplace ici tout un dossier de bookmarks en vrac, lors de recherches précédentes (juin 2023) pour la même problématique :
    • [d] « Modèle:Infobox Site web » : différence entre les versions
    • Résultats de recherche pour « intitle:Infobox intitle:/Infobox\// insource:/\|\-/ »
    • Résultats de recherche pour « intitle:infobox insource:/\|\-/ -intitle:Documentation »
    • [M] Modèle:Infobox Élection
    • Résultats de recherche pour « intitle:infobox insource:/\{\{!\}\}-/ -intitle:Documentation »
    • [M] Modèle:Infobox Bibliographie
    • [M] Modèle:Infobox Joueur de baseball2
    • [M] Modèle:Infobox Aéroport
    • [M] Modèle:Infobox Voie de Paris
    • [M] Modèle:Infobox Boxeur
    • [M] Modèle:Infobox Protéine
    • [M] Modèle:Infobox Tunnel
    • [M] Modèle:Infobox Train de voyageurs baptisé
• MediaWiki:Common.css : reconsidérer plus tard T366389#10055910 (code plus robuste pour les listes horizontales, en raison de ces p—tains d'éléments .mw-empty-elm)
  • pour l'instant c'est quand même vraiment tôt, cf. https://caniuse.com/css-has
  • comme indiqué sur Phabricator, attention à ne pas utiliser + comme il y a dans les diffs, mais bien ~
    • et comme aussi indiqué, à effectuer aussi pour les .fieldsetlike (à propos, qu'est-ce que ça vient f—tre dans une classe "fieldsetlike" ?)
  • aussi à effectuer dans le MediaWiki:Mobile.css, vu qu'il n'y a pas de moyen de définir du CSS vraiment commun (i.e. desktop et mobile)… un manque vraiment très, très, très stupide dans MediaWiki
    • enfin… là ce n'est plus MediaWiki:Mobile.css mais MediaWiki:Gadget-Mobile.css (énième stupidité de vous savez qui, pourquoi corriger un problème évident à la base, quand on peut à la place faire un truc bien tordu)
    • et il y a aussi la stupidité sans nom du support du navigateur stock des Android préhistoriques (mw:Compatibility#Browser support matrix)
      • mais ça on s'en fout, tout ce que l'on veut c'est éviter les 0.001 % d'erreurs JavaScript dans les logs qui iraient faire débarquer vous savez qui
  • le navigateur de cirque, on n'y pense même pas
• {{Incise}} : remplacer les tirets cadratins affreusement longs (justifiés seulement par quelques psychorigides, se basant sur des recommandations typographiques davantage adaptées aux grimoires qu'aux écrans)
  • voir la discussion sur la pdd, et aussi la discussion sur l'Oracle
• pour rappel : string.gsub() est plus performant que mw.ustring.gsub(), mais ce qui pulvérise tout, c'est le "préfiltrage plaintext" : if haystack:find('foobar', nil, true)
  • bench rapide, 500 000 itérations : un mw.ustring.gsub() 2159 ms ; deux string.gsub() 1430 ms ; préfiltrage plaintext (bien entendu, rejeté) 53 ms
  • on pourrait se dire que c'est suffisamment rapide, mais en évitant un mw.ustring.gsub() avec un préfiltrage plaintext, pour 1000 itérations ça fait quand même un gain de 4,2 ms
  • aussi pour rappel, lorsque le paramètre "plain" n'est pas renseigné dans l'appel à string.find(), Lua analyse en interne le pattern et s'il n'y a aucun caractère spécial, la recherche se fait automatiquement en plaintext
    • voir implémentation de "str_find_aux" dans lstrlib.c
    • cette détection des caractères spéciaux a théoriquement un coût, mais l'exécution est extrêmement rapide
    • mais de toute façon, je préfère indiquer explicitement le mode plaintext :
      • ça évite les mauvaises surprises, si le pattern contient (ou se voit ajouter ultérieurement) un caractère spécial
      • on montre que l'intention est vraiment de faire une recherche plaintext, ultra-performante, sinon elle n'a pas lieu d'être
• Discussion modèle:Catégorisation badges#Récupération des badges sur Wikidata
• modèles "smiley" : éventuellement mettre en place un méta-modèle pour factoriser le code
  • pas encore étudié si l'idée est bonne ni même si c'est faisable
  • parce que là, pour implémenter {{Taille px pour image}} je viens de me taper la modification de 115 modèles (ça s'est fini avec un script de remplacement automatisé, quand je me suis rendu compte de la quantité)
  • pour rappel, il existe aussi ces méta-modèles : {{Alien}}, {{Smirc}} et {{Cabale}}
  • repéré quelques modèles n'ayant pas le "<span class="smiley">"
  • autre "méta-modèle" existant : {{Émoticône}}
  • et ça, purée : {{Emoji}}, avec un paramètre "taille" qui est appliqué à deux endroits : pour une taille d'image, et pour un CSS font-size…
    • bon au moins, actuellement dans toutes les inclusions les paramètres "taille" présents sont corrects (nombres entiers) (edit : en fait j'ai détecté deux utilisations avec un suffixe "px" : ici et ici)
    • j'ai modifié le modèle {{Emoji}} : 219508220
  • les appels de modèle sans arguments étant mis en cache, ça fait une invocation Lua maximum par modèle différent
    • donc éventuellement simplifier en réémigrant les {{{{{|safesubst}}}#if:...}} et en implémentant à la place un 2^e paramètre dans {{Taille px pour image}}
    • à la manière de {{Dièse couleur web}}, mais pour rappel pour celui-ci c'est justifié en raison des sauts de lignes avant les "#"
• en:Template talk:Replace#Edit request 19 August 2024 : si à terme le module en:Module:String est corrigé, les mêmes corrections pourront être faites sur frwiki (Module:String et ce qui en fait usage)
  • pour rappel, une ancienne modif déjà faite sur frwiki : 198891366
  • il reste principalement à traiter en:Template:In string, actuellement en "unexcepted default false", mais on pourrait peut-être directement le passer en "default true"
  • ensuite (bien entendu après avoir bien fait le tour), on pourra corriger le "default lorsque chaîne vide" dans le module, puis repasser dans les modèles pour les simplifier
    • néanmoins, un intérêt d'avoir la valeur par défaut indiquée dans le modèle, est que l'on a pas à aller chercher dans le module pour la trouver
  • à propos : Lua n'a pas de mode "plain" (sauf avec string.find()) du coup c'est obtenu en ajoutant des traitements d'escaping ; c'est dommage d'utiliser le "plain mode" quand il n'est pas nécessaire (pas de caractères spéciaux dans le "needle"), mais ça reste la moins pire solution (parce qu'elle évite les surprises)
  • quémandage de modification : en:Module talk:String#Protected edit request on 3 September 2024 (et je viens de l'effectuer dans le module frwiki)
• {{Brouillon}} : de nombreuses utilisations avec un paramètre "1", et c'est même documenté ici, alors qu'apparemment ce paramètre n'a jamais existé ? (j'ai bien dû louper quelque chose…)
• Module:Lien interwiki : les noms des catégories de maintenance seraient à harmoniser :
  • d'une part : Catégorie:Page contenant un modèle Lien avec un paramètre inconnu (et Catégorie:Page utilisateur contenant un modèle Lien avec un paramètre inconnu)
  • d'autre part : Catégorie:Page utilisant Lien pour un article existant (et Catégorie:Page de discussion utilisant Lien pour un article existant)
• MediaWiki:Newarticletext (remarqué lors de cette DIMS) :
  • lorsque dans le popup de l'éditeur visuel (exemple), il reste un <p><br></p> de trop ; refs 149879284 et 149879322 (suivi de 153085043)
    • cette classe "boutons-action" n'est actuellement utilisée nulle part ailleurs
    • il faudrait mettre le <br> dans le div "boutons-action" (et s'assurer qu'il n'y a pas de création inopinée de <p>), mais ça me gêne un peu de mettre autre chose qu'un bouton dans un conteneur avec une classe nommée ainsi
  • toujours en popup d'éditeur visuel, quand c'est pour une création de page utilisateur (exemple), il y a ce contenu en trop : bouton « Créer votre page » - lien « Créer votre page avec l'éditeur wikicode »
    • ça serait à masquer de la même façon
    • cette classe "boutons-action" serait peut-être à renommer pour un nom de "classe utilitaire" servant à masquer du contenu dans le popup de l'éditeur visuel… à réfléchir
      • du coup, ça ferait une inversion de responsabilité : avant c'est le Common.css qui spécifie ce qu'il faut masquer dans le popup, après c'est le message système qui spécifie cela
• voir cette modif faisant usage d'une variable CSS
  • j'étais sur le point de faire color:{{#if:{{{4|}}}|{{Dièse couleur web|{{{4}}}}}|var(--color-emphasized, #000)}};
    • pour rappel, le famoso T14974 (qui là n'est pas déclenché vu que ça commence par « var… ») : The newline added to a template, magic word, variable, or parser function that returns line-start wikicode formatting (*#:; {|) causes unexpected parsing
  • avec ce résumé de modif : [[Modèle:Dièse couleur web|{{Dièse couleur web}}]] n'a pas été prévu pour ce genre de valeur, par précaution je préfère éviter de lui passer cela ; refs [[Spécial:Diff/216690908|216690908]] ; unique cas de figure détecté, il y en avait un autre mais qui a déjà disparu : [[Spécial:Diff/217373689|217373689]]
  • il suffit de chercher « var » avec wstat.fr
  • mais en fait, il n'y a pas vraiment de raison que {{Dièse couleur web}} ne fonctionne pas avec cela
  • peut-être plutôt ajouter un exemple dans Modèle:Dièse couleur web#Exemples
• dans {{Barre colorée}} (et les autres de la série…), j'étais prêt à mettre un {{taille px}}, mais ça aurait posé problème avec les "x24" dans cette page
  • voir ces discussions : Discussion modèle:Taille px#Autres formats de taille d'image et Wikipédia:Bot/Requêtes/Archives/2023/01#Correction d'erreurs de Lint
  • heureusement, ces modèles sont encore peu utilisés, donc c'est gérable pour faire le point sur leur utilisation : recherche pour {{taille px}} et recherche pour {{taille em}}
  • le truc, c'est qu'il y a deux cas de figures assez distincts :
    • valeurs CSS : 10em, 10.5em, .5em
    • valeurs de taille d'image (balise d'image MediaWiki) : 42px, 42x42px, x42px
  • l'idée pour l'instant, c'est qu'il faudrait créer un nouveau modèle {{taille image px}} ou {{taille px image}} (pas évident de déterminer le nom à utiliser…)
    • possible résolution du problème : {{taille px pour image}}
  • rappel : attention à faire "find number only" et pas "find suffix" : il ne faut pas ajouter le suffixe dans le cas où une autre unité serait déjà présente (enfin, pour les valeurs CSS… pour les tailles d'images, il n'y a pas d'autre unité que px)
  • on pourrait être tenté d'ajouter cela dans {{Drapeau}}, {{Drapeau/callback}}, {{Drapeau2}}… mais surtout pas, car j'imagine que cela causerait de gros problèmes de performances (ajout overhead Lua à des modèles pouvant être appelés de très nombreuses fois)
  • j'ai découvert qu'il est possible de mettre des espaces (une ou plusieurs, et même aussi des tabs, mais pas des newlines) avant le px (et pas ailleurs), e.g. « 42 px » ou « 42x42 px » ; vu que l'on en est à utiliser un module, supporter aussi cela
    • cela est documenté : « A space character between the width value and "px" is permitted. »
  • MediaWiki tolère la saisie de deux fois (pas plus) le suffixe « px » (exemples : "42pxpx", "42 pxpx", "42px px", "42 px px")
    • ça fait que ce cas de figure typique fonctionne en fait : 1 = 42px → {{{1}}}px → 42pxpx
    • mais franchement, pas terrible de reposer là-dessus
    • faudrait chercher dans le code source de MediaWiki et sur Phabricator si je trouve quelque chose à ce sujet ; edit : T15500 (où justement il est stipulé que cette syntaxe n'est pas souhaitable, et pourrait donc disparaître à l'avenir), ainsi que T53628
      • voir Catégorie:Pages avec des tailles d'image contenant des px supplémentaires (message MediaWiki:Double-px-category)
    • problème : en:Template:Flagicon requiert de mettre le "px", tandis que {{Drapeau}} requiert de ne pas le mettre
      • or chez nous, c'est une redirection de modèle, donc les paramètres sont les mêmes
      • il faudrait transformer cela en une couche de compatibilité, un truc du genre {{Drapeau|taille={{remplace|{{{size|{{{taille|20x18}}}}}}|^(%d+) *px$|%1|plain=false}}|<et transmettre les autres paramètres>}} (attention à la problématique "paramètre présent mais vide", voir dans {{Drapeau}})
      • attention aussi, il faudrait également supporter les valeurs "x43px" et "42x43px" ; et comme indiqué un peu plus haut, il peut aussi y avoir des espaces
    • pour rappel, implémenter {{Taille px pour image}} dans {{Drapeau}} risquerait de trop impacter les performances
    • finalement, c'est comme cela que j'ai résolu le problème ; voir 219514896, 219515044 et 219515224
    • il n'y avait pas tant d'utilisations erronées que cela, éventuellement défaire cet ajout de {{Taille px pour image}}, pour performances en raison de l'appel Lua
      • recherches rapides : dans "taille" et dans "size"
      • rien à changer dans le modèle parent ("passthrough direct"), et dans le modèle "/callback" remplacer par {{#if:{{{size|}}}||{{{size}}}px|20x18px}}
      • pour consistance, serait à faire également dans {{Pays}} et dans {{Drapeau2}}
      • mais du coup, ça serait le retour du problème de compatibilité avec les utilisations venant de en:Template:Flag, en:Template:Flag icon, etc. qui eux demandent de mettre le suffixe
      • j'avais mon idée de créer des "modèles de compatibilité" (à l'époque {{Cite web}}, et là {{Flagicon}}, {{Wide image}}…), faisant une couche intermédiaire convertissant les paramètres (au lieu d'une redirection de modèle, où les paramètres ne peuvent pas être changés), mais pas sûr que l'idée soit vraiment bonne (notamment, il faut ajouter tous les paramètres pour les transmettre) ; et je crois bien que l'idée pour {{Cite web}} remonte à avant même que Lua ait été disponible
  • éventuellement mettre en œuvre quelques {{taille px}}
    • ça serait en fait pour que le modèle ne devienne pas inutilisé, après avoir remplacé les rares (deux…) utilisations actuelles par le {{taille image px}} plus adéquat
    • exemple de recherche : insource:px insource:/\}\}\}px *[^ \|\]]/
  • une fois le modèle {{taille px pour image}} mis en place, éventuellement renommer les autres modèles en {{taille px pour CSS}} et {{taille em pour CSS}}
  • {{Image panoramique}} :
    • suite à mes modifs pour permettre avec/sans suffixe "px", le modèle effectue deux ou même trois invocations Lua
    • et à cela on ajoute l'histoire des paramètres 4/5 qui sont différents sur enwiki, etc.
    • encore autre chose, le markup des images a depuis lors changé (voir mw:Parsoid/Parser Unification/Media structure/FAQ#Overview), des ajustements seraient peut-être donc nécessaires (mais ça a l'air de fonctionner encore)
    • et il existe aussi {{Double image}}, {{Triple image}}, {{Double image multiple}}, {{Double image verticale}} avec les mêmes problématiques… et là, le support avec/sans suffixe rendrait le code vraiment infect
    • du coup, j'ai eu envie de retirer le support avec/sans px dans {{Image panoramique}}… mais on en a besoin pour les utilisations venant de en:Template:Wide image, etc.
    • noter que en:Template:Multiple image (qui regroupe les fonctionnalités de {{Double image}}, {{Triple image}} et {{Double image verticale}}) requiert les largeurs sans le suffixe "px"
      • ainsi, c'est moins gênant que nos modèles "images multiples" ne supportent pas non plus avec suffixe
      • et on s'en tient à la compatibilité "avec/sans px" seulement pour le modèle {{Image panoramique}}, où là c'est justifié en raison des modèles en:Template:Wide image, etc. qui eux fonctionnement avec le suffixe
      • toutefois, vu que en:Template:Multiple image fonctionne avec un module, ils pourraient tout à fait ajouter ultérieurement le support "avec suffixe px"
• diverses modifications apportées à {{Barre colorée}} n'ont pas été effectuées sur {{Barre colorée/centre}}, mettre celui-ci à jour
  • attention : je viens de remarquer qu'il existe aussi {{Barre colorée/Lien externe}}…
• encore avec {{Barre colorée}} (et les autres) : quand il y a un lien, éventuellement ajouter celui-ci aussi sur l'image
  • ça fait deux markups de liens, dont un lien sur une image ayant un alt vide ; mais peut-être un gain de praticité pour certains utilisateurs, et c'est quand même ça le plus important
  • sachant que le lien sur l'image est actuellement supprimé (link=) (donc licence de toute façon déjà pas accessible actuellement)
  • l'immense majorité des images utilisées semble venir de commons:Category:Elegant Themes Circle Icons, qui est déjà référencé sur Wikipédia:Crédits graphiques
• Discussion:Covariant et contravariant#Suppression (bis) :
  • éventuellement (je dis bien, éventuellement), permettre des "valeurs libres" pour les paramètres de liens dans {{Autre4}}, {{Autre}}, etc.
  • un peu sur le principe de ce que j'avais fait avec {{Italique si non précisé}}
  • exemple de recherche (il faudrait en faire beaucoup d'autres), on voit qu'il y aurait des cas particuliers à traiter, notamment ici le coup du « Echospace [detroit] »
  • voir aussi cette discussion, ainsi que cette fonction Lua (actuellement inutilisée, et sans modèle associé) :
    • à utiliser en remplacement des {{lien préfixé avec un deux-points}}, cela supporterait en plus les liens en input, et cela permettrait de factoriser les modèles
    • mais pour que le changement soit pertinent (car cela ajoute quand même l'appel à Lua, sur de très nombreuses pages), il faudrait réaliser la factorisation des modèles dès la mise en place
• JPEG XL (permalien) → {{Infobox Format de données}} → Module:Infobox/Format de données → Module:Infobox/Fonctions::website() → Module:Weblink::makelink() :
  • ça buggue si j'essaie d'utiliser un {{Liste simple}} dans le paramètre "site web" de l'infobox, car le Module:Weblink::makelink() en bout de chaîne ne supporte pas cela
• code qui serait peut-être simplifiable/améliorable dans {{p.}} : 210438433
  • cf. Wikipédia:Demande d'intervention sur une page protégée/Archives/24#Modèle:p. (d · h · j · ↵)
  • voir méthodes formatePassage et formatePagesTotales dans Module:Biblio/Commun
  • à propos, dans ces méthodes des wikifications supplémentaires pourraient être souhaitables dans certains cas précis :
    • ajout d'un "formatnum" aux suites d'au moins quatre chiffres, e.g. « 1234 »
    • ajout d'un "nowrap" aux intervalles, e.g. « 42-43 »
    • bien faire attention aux situations où le paramètre aurait déjà été wikifié (chercher si présence de balises, d'espaces insécables…)
    • au vu de la multitude de cas auxquels il faut penser, et de la quantité énorme d'appels à ces méthodes sur le wiki, créer des tests unitaires
• Palettes :
  • idem que cette modif : recherche regex link=[|\]] dans les paramètres "image"
  • recherche "hlist" dans les paramètres "styleliste" (résumé modif que j'avais préparé : « les paramètres « styletrucmuche » ne peuvent contenir que du code CSS, pas des classes HTML »)
  • recherche paramètres "nom", c'est un paramètre qui n'existe pas
  • paramètre "bordure" : il ne sert pas à contenir un code couleur, mais c'est une sorte de paramètre "interne" (d'ailleurs non documenté) (refs 39735498 et 39735903)… du coup si on nettoie ces quelques utilisations erronées, le paramètre n'est plus du tout utilisé ensuite ?
    • voir aussi paramètre 1, encore une fois, de nombreuses utilisations qui ont l'air erronées
• les briques d'infoboxes V2 avaient été codées n'importe comment, avec les <tr> d'ouverture placés… dans la brique précédente (et le </tr> dans la brique suivante). Au lieu de… ben simplement mettre le <tr> dans la brique quoi…
  • bien entendu, délicat à corriger parce qu'il y a tout un écosytème de modèles à adapter conjointement à la correction des briques (j'avais déjà fait quelques séries de recherches, c'est en bookmarks)
  • exemple de problématique engendrée : [//fr.wikipedia.org/w/index.php?title=Mod%C3%A8le:Infobox/Image&diff=prev&oldid=114894559 114894559]. Ça cause un espacement supplémentaire, il faudrait mettre le "display:none" sur le <tr>, et là justement on peut pas…
• après passage en production de T180911 (dans MediaWiki 1.42.0-wmf.15), on pourra utiliser talkNsText dans Module:Talkpageheader (refs 142747801)
  • en revenant là-dessus, j'ai constaté un problème avec nsText : T369784 – tant que ce n'est pas corrigé, le code actuel du module est préférable, plutôt que d'utiliser talkNsText et par conséquent aussi nsText (en "else")
• il s'avère que Module:TableBuilder est généralement détourné de son rôle initial pour en faire un "string builder"
  • le rôle initial, c'est une interface "fluent" pour table, vu que sinon il faut faire table.lafonction(lavariable, ...), la syntaxe lavariable:lafonction(...) n'étant pas possible avec les tables
  • création d'un module StringBuilder, avec vraiment le minimum en méthodes exposées :
    • méthodes de bases : push/add/append/minsert() variadique, et concat/join/tostring/result() à la fin
    • besoins spécifiques :
      • unshift() (i.e. prepend) (apparemment plus besoin : 219062026) (edit : si, il y a aussi des table.insert(1, ...), directement la fonction table native, dans Module:Biblio/Lien web)
      • intermediateConcat() (deux fois dans Module:Biblio/Lien web, mais c'est horrible, faudrait vraiment trouver moyen de les dégager…)
        • il y a exactement la même chose en code natif dans Module:Biblio/Ouvrage, Module:Biblio/Article, Module:Biblio/Lien vidéo, Module:Biblio/Article encyclopédique… chercher wiki.concat()
        • edit : Module:Biblio/Lien vidéo a été réécrit en 2025, et contient maintenant aussi cet ignoble intermediateConcat()
      • alternativement, exposer la variable table ; cela dépend :
        • tant qu'il y a encore besoin de faire des intermediateConcat(), exposer la table et mettre l'implémentation des traitements dans les consumers
        • si le intermediateConcat() est réémigré et qu'il ne reste plus que prepend() : ne pas exposer la table, et proposer prepend() en plus de append()
    • dans Module:Biblio/Lien web, concernant le intermediateConcat() qui sert à éventuellement ajouter un marqueur ‎ :
      • un problème constaté actuellement : s'il y a des textes en rtl adjacents, par exemple « <texte 1 en rtl>, <texte 2 en rtl> », ils sont affichés dans l'autre sens : « <texte 2 en rtl>, <texte 1 en rtl> »
      • une meilleure solution serait d'encapsuler chacun des textes susceptibles d'être en rtl avec une balise <bdi>, ou <baliseexistante dir="auto">
      • référence : Inline markup and bidirectional text in HTML
      • le souci, c'est de déterminer quelles valeurs sont susceptibles de contenir du texte en rtl (surtout qu'il est difficile d'analyser les paramètres) ; j'ai eu peur mais en fait c'est jouable : moins de 10 valeurs devraient être concernées
      • aussi, il serait plus exact de chercher uniquement les caractères rtl, au lieu de tous les caractères non latins, mais ce n'est pas grave : ça ratisse simplement plus large, donc ça peut ajouter du markup inutilement, mais ce n'est pas grave du tout (avec des inputs dynamiques, en général le markup est toujours ajouté, et nous on a déjà une passe pour économiser le markup dans une grande partie des cas)
    • concernant l'indicateur "plume" avec l'éventuel ajout d'un point avant :
      • le plan actuel serait de concat() avant pour avoir le résultat affiché final, puis de patcher ce résultat en ajoutant ces éléments
      • il faut vraiment limiter le nombre de concaténations de strings, et Lua optimise les multiples concaténations dans une même instruction ; il faut faire : resultat = resultat .. ( not ponctuation and '.' or '' ) .. plume
      • avec un autre stringbuilder pour les catégories ensuite, et on retourne la concaténation de "résultat affiché" et "catégories"
      • pas de stringbuilder pour concat() le résultat affiché et les catégories : pour deux strings, une simple concaténation de strings est évidemment plus performante
      • il faut limiter le nombre de concaténations de strings ; toutefois, il en faut un paquet avant que table.concat() devienne plus performant
      • pour générer les catégories, mieux en simples concaténations de strings qu'avec un stringbuilder
      • en résumé : stringbuilder pour fabriquer le contenu affiché, ensuite on le concat(), et pour tout ce qui suit (la plume et les catégories) : en simples concaténations de strings, mais en en faisant le moins possible
  • à utiliser dans Module:Biblio/Lien web, parce que 171986603 ne me plait pas (obligé de concaténer, au lieu des arguments en variadique)
  • renommer le module TableBuilder en FluentTable (à propos, les modules peuvent maintenant être renommés, cf. T120794)
• deux modèles qui semblent faire doublon avec {{Liste simple}} : {{Liste sans puce}} et {{Unbulleted list}}
• créer une catégorie pour les modèles dont le rôle est d'avoir une page "fonctionnelle" lorsqu'elle a été copiée depuis un autre wiki, en ayant laissé les modèles étrangers tels quels
  • exemples : le {{Unbulleted list}}, et chercher « Cite book » plus bas dans cette page
• Discussion module:Outils#Fonction extractArgs()
  • référence externe : https://help.fandom.com/wiki/Extension:Scribunto#Supporting_both
  • attention à 197673793 : comme rappelé dans la référence ci-dessus, les arguments définis mais vides sont tout autant pris en compte, donc peut-être garder l'ordre actuel (frame "#invoke" prioritaire sur la frame du modèle) pour éviter les mauvaises surprises
  • ensuite, si T137584 (« Allow Scribunto code to add a category without changing output ») est résolu, il serait possible de catégoriser les pages où le changement d'ordre change le résultat
• lorsque le modèle {{Documentation}} ajoute automatiquement un bandeau pour indiquer que le modèle est protégé en écriture, s'il y a des bandeaux "hatnote" au début de la documentation ça serait bien de ne pas ajouter le bandeau au tout début, mais en dessous de ceux-ci
• {{Infobox Site web}} : implémenter un paramètre couleur nom, pour remplacer les utilisations assez nombreuses de {{blanc}}, etc. dans le paramètre nom (cf. wstat.fr)
• {{Encart}} : ça ne produit pas un <p> mais un <div>, du coup le texte peut se retrouver tout collé aux éléments avant et après
  • exemples : Aide:Homonymie, Souris (homonymie)
  • forcément, j'imagine qu'il y a des cas inverses, où le rétablissement de ces margins serait indésirable…
  • pour rappel, « avec div, pas de surprise », mais là pour le coup un <p> me paraît tout indiqué
  • entretemps j'ai effectué 210018567, sans avoir pensé à ces notes TODO ; la situation est donc déjà meilleure, mais on pourrait peut-être encore un peu améliorer
• harmonisation {{Site officiel}}, {{Bases}}, {{Dictionnaires}} et {{Autorité}} (utilisés par {{Liens}}), ainsi que {{Blog officiel}} (présent en plus dans {{Liens de biographie}}) :
  • si le paramètre « wikidata / id / entity [ / 1 ] » n'est pas un qid valide, certains modules discardent la valeur, d'autres la laissent passer (et donc erreur plus tard)
    • rappel : bien entendu, il y a la valeur spéciale « - »
  • si le paramètre « wikidata / etc. » est utilisé avec le qid de la page en cours, certains modules ajoutent le suffixe "entityInfo" « (pour [[même article]]) » (donc "selflink", lien remplacé par texte en gras), d'autres ne l'ajoutent pas
    • rappel : le paramètre pourrait éventuellement valoir « q42 » (lowercase) ; une telle valeur fonctionne, mais faux négatif quand on compare avec mw.wikibase.getEntityIdForCurrentPage() (résultat « Q42 », uppercase)
  • nom de variable « entityId » au lieu de « entity »
• renommer le modèle {{L}} en autre chose, pour libérer le nom, puis utiliser ce nom de modèle pour afficher le nombre 50 en chiffres romains
  • cf. message de Néfermaât sur Discussion modèle:L#Remarques (ça commence à bien dater, 2009 !) : il y aurait aussi d'autres modèles à renommer, par exemple {{LC}}
• {{Palette}} : tout devrait se faire dans le module, parce que là quand on passe une palette complète en argument, args[1] vaut « {{Palette \n {| code de la palette »… (parentArgs[1] étant utilisé à la place quand il s'agit d'une palette complète, ce args[1] n'est pas utilisé, il n'en demeure pas moins complètement foireux, et long)
  • sauf que, si on utilise des frame:expandTemplate() dans le module, toutes les palettes incluses vont se retrouver en temps d'exécution Lua…
• on pourrait peut-être gagner à convertir {{Méta palette de navigation}} en Lua (modèle apparemment un peu lent, inclus peu de fois)
  • une indication que cela pourrait être intéressant de convertir en Lua : Discussion modèle:Méta palette de navigation#Augmentation de la limite des groupes de 30 à 40 dans la méta palette de navigation
    • sous réserve que les performances soient validées (équivalentes ou meilleures)
  • pour rappel, il y a aussi tout le système "hacky" de communication entre {{Palette}} et {{Méta palette de navigation}} :
    • lorsque {{Palette}} reçoit en argument les noms de palettes (utilisation classique), les palettes sont expandées puis transmises au module
    • {{Palette}} peut recevoir en argument des palettes déjà expandées : {{Palette\n | {{Palette Truc}}\n | {{Palette Muche}}\n}}
    • il y a aussi l'utilisation "directe" : {{Palette Truc}} (sans le pipe)
    • et tout cela se fait avec le paramètre parent=bandeau, des préfixes "plaintext" détectés puis nettoyés par le module, et important (traître) : des args[N] vs parentArgs[N]…
• {{Méta infobox navigation}} : des espacements verticaux foireux, par exemple {{Palette Projet articles audio}}, {{Projet:Photographie/menu}}…
• {{Méta bandeau d'avertissement}} : le contenu du paramètre optionnel supplément est trop collé au contenu précédent
  • exemples : Paramètre « supplément » sur wstat.fr
  • attention, il y a vraiment de tout : ça peut être un texte simple, ou commencer par un <hr>, par un <br>, être une liste, un div, un div collapsible…
• {{YouTube}} : pouvoir ajouter un timecode
  • exemple pour utilisation : 172998491 (hacky pour l'instant)
  • support et conversion bidirectionnelle formats : 3:49 ⇄ 229s (j'imagine qu'il va falloir du Lua…)
  • rappel : le <small> ne s'affiche pas plus petit dans les <references /> (mais ça ne fait pas de mal de le mettre, car ça ajoute quand même une information sémantique, et le modèle peut être utilisé ailleurs)
  • en cas d'échec parsage du paramètre de position, comme actuellement l'afficher en libellé tel que saisi, mais par contre ne pas le mettre en timecode dans l'URL
  • éventuellement, ajouter le support des intervalles (exemple d'utilisation erronée pour l'instant)
    • avec la première valeur de l'intervalle en timecode dans l'URL, et un libellé « de <libellé 1> à <libellé 2> »
• comme déjà remarqué, {{Lien web}} pose des problèmes de performances (notamment quand il est utilisé de nombreuses fois)
  • une piste pourrait être dans Module:Biblio/Lien web de remplacer l'utilisation de Module:TableBuilder par du code natif
    • rappel : on peut aussi faire un truc du genre local insert = table.insert, améliore légèrement performances et surtout lisibilité code
  • (car multiplication du nombre d'appels de wiki.minsert() (avec toute la machinerie sous-jacente) par le nombre d'utilisations de {{Lien web}}, ça devient vraiment élevé)
• {{Lien archive}} serait à convertir en Lua, actuellement ses performances sont encore largement pires que celles de {{Lien web}} (cf. cette discussion)
• réémigrer la fonction String.simpletitle vers un module dédié, afin d'alléger le Module:String
  • de plus, la fonction String.titledisambig associée, juste en dessous, semble inutilisée ?
  • simplement pour information, je viens de remarquer l'existence de Module:Formatage du titre, peut-être serait-ce un bon endroit pour y déplacer le code
• {{nbsp}} : rôle actuel alambiqué (rappel : les branches de #if non atteintes ne sont pas exécutées…), et bien entendu les inclusions sont erronées, s'attendant à un simple paramètre "N espaces"
  • et justement, ça serait bien de pouvoir faire {{nbsp}} dans le wikicode, plus friendly que  
  • apparemment la seule utilisation où le paramètre "nom de modèle" est volontaire : {{Modèle:Bus autres/correspondances avec intitulé}}
  • edit : attention, les branches de #if non atteintes ne sont pas exécutées (refs en:Help:Template limits#Expansion), mais il se pourrait qu'elles soient comptées dans le Post-expand include size, voir notamment #Nested transclusions. Et justement, le modèle a été créé en mai 2008, quelques mois après la mise en place du NewPP, en février 2008 ; c'est peut-être donc en rapport.
  • refs discussions qui ont eu lieu ultérieurement : Discussion utilisateur:Pic-Sou#syntaxe absurdément complexe et Discussion utilisateur:Pic-Sou#Nbsp puis modèle
  • depuis lors, j'ai effectué de la remise à plat, et le paramètre sert maintenant bien à spécifier un nombre de répétitions
  • attention, parce que j'ai failli me faire avoir :
    • il n'y a plus d'utilisation de {{nbsp}} avec un paramètre (sous réserve que cela ne réapparaisse pas)
    • mais il existe aussi {{space}}, qui est actuellement identique à {{nbsp}}, mais par contre il a beaucoup d'utilisations avec un paramètre…
    • les documentations des deux modèles indiquent qu'ils sont identiques, et qu'une transformation en redirection serait envisageable, mais ce n'est plus le cas si je supprime le paramètre de {{nbsp}}
• Catégorie:Palette Métropole : des palettes à proprer (autocollapse, gras double, css…)
• fusionner {{non vide}} et {{premier non vide}}
  • impact perfs négligeables pour le {{non vide}}, ça rajoute juste un #if
  • sur enwiki (cf. en:Template:If empty) ils utilisent carrément un module Lua… mais ça franchement, NON. overkill.
    • d'autant plus qu'actuellement, il n'y a aucune utilisation de notre modèle avec plus de 3 arguments, voir wstat.fr
• {{Page de discussion}} (et JavaScript associé) : transformer l'id transformeEnPageDeDiscussion par une classe du même nom
  • permettrait de ne pas craindre d'avoir un HTML incorrect parce que la page contient plusieurs fois le modèle (notamment, inclusions de sous-pages en cascade)
  • bien plus envisageable qu'à l'époque, vu que maintenant on a tout ce qu'il faut en JavaScript pour choper les éléments par class
  • refs 155412647, barre de semaines incluse dans l'en-tête et les pages de semaines (exemple)
• {{Palette Modèles de vote}} :
  • modèles de discussion : du proprage de catégories à faire, notamment avec des ajouts de Catégorie:Modèle affichant une icône
  • faudrait aussi que tous les modèles (genre Oui, Fait, etc.) soient bien répertoriés, de sorte à ne pas en oublier lors de modifications
• {{Lien archive}} :
  • des paramètres à ajouter, voir discussion : Mieux coller aux paramètres de lien web
• {{Colonnes}} :
  • uniformisation paramètres {{Colonnes}} et {{Début de colonnes}}
  • ne supporte actuellement que "taille=30" (unité "em" implicite), pour syntaxe moins pénible supporter aussi avec les unités : "taille=30em", "taille=30rem"…
  • catégoriser les valeurs incorrectes, on retrouve notamment "taille=em" (on s'en serait douté…)
  • en addition au paramètre non nommé pour le contenu, paramètre "contenu", ça serait moins laid que les "|nombre=2|1="…
  • histoire de la "correction de marge supérieure" qui ne gère pas tous les cas
    • voir cette discussion : Discussion modèle:Début de colonnes#Difficultés CSS, toujours et encore !
    • exemples de cas problématiques : avec une "liste simple", avec un <poem> intercalé
• le header de la page d'accueil est complètement à refaire, en particulier ces histoires de layout colonnes, là…
  • la partie de plaisir, c'est qu'il faut que ça rende bien sous toutes les largeurs
  • bien tester avec tous les navigateurs (pour rappel on avait eu un bug spécifique à Chrome…)
  • discussions à propos :
    • Affichage de liens dans Chromium
    • Deux liens inutiles ?
    • Allègement liens dans l'en-tête
    • une relance ici : Discussion modèle:Accueil/Titre#Mise à jour
  • prérequis : corriger au moins sur la page d'accueil les dégradations dues au nouveau markup des titres de sections qui est en chantier, cf. section #Foutoir de cette page
  • refs : #Trucs à arranger (sur la présente page), section sur ma pdd (qui y traîne depuis 2018…), 230023373 (tout récent, 2025)
  • autre chose, le globe utilisé en background a un poids non négligeable (162ko, 54ko transfert compressé) par rapport au total de la page
• Modèle:Accueil actualité : réfléchir à le rendre plus aisé à modifier pour les contributeurs
  • voir cette discussion à propos : Discussion utilisateur:FDo64/Archive08#Modèle:Accueil actualité
  • fait, grâce à mon beau Modèle:Accueil actualité/Affichage :-)
• {{Indication de langue}} :
  • il faudrait inverser les paramètres 1 et 2, ça serait plus logique
  • attention, il y a aussi des appels direct du module ! (chercher « insource:indicationDeLangue »)
  • ça serait bien de ne pas invoquer Lua quand il n'est pas utile, lorsque code et nom renseignés, exemple {{en}}, etc.
    • quoique, ça ne semble pas faire bottleneck (il n'y a que l'invocation Lua), par contre ça serait dommage de dupliquer le code (une fois Lua, une fois template)
• classe bandeau-section utilisée pour deux choses différentes :
  • e.g. {{Article détaillé}}
  • e.g. {{Section à recycler}}, et là le contenu est tout collé à gauche c'est moche
  • regardé que très succintement, à approfondir
  • évidemment, on remarque déjà que c'est le bazar dans les modèles et que l'uniformité c'est pas vraiment ça
• {{Infobox Série de jeux vidéo}} : remplacer "|jeu phare N=Foo (bar) |jeu phare N affiché=Foo" par "|jeu phare N=[[Foo (bar)|Foo]]"
  • sans oublier idem avec "premier jeu" et "dernier jeu en date"
  • attention il y a des "|jeu phare N=Foo |jeu phare N affiché=<identique>", bien transformer en [[Foo]] et non [[Foo|Foo]]
  • a priori traité depuis lors : 149591247 et 149596892
• sous-catégories de Catégorie:Page utilisant un modèle avec une syntaxe erronée : faire sauter ce bazar de catégorisation de la sous-catégorie qui diffère selon que ladite sous-catégorie est vide ou pas
• performances modèles : en cherchant "NewPP" dans la source des pages, maintenant on a même un classement des modèles les plus coûteux en temps CPU
• {{lang}} et {{lien web}} : mauvaises performances en raison des utilisations habituellement nombreuses et du coût invocation Lua
  • voir Discussion Projet:Modèle#Poids du modèle Refm (Références multiples)
  • déjà pour {{lang}}, réfléchir à court-circuiter le Lua pour les syntaxes et codes courants
  • après essais rapides, pas moyen de faire jouer le système qui cache les templates avec des arguments identiques, la présence de Lua semble invalider le cache même si non appelé
  • pour mémoire : {{Code langue}} et {{Code langue 2}}
  • des cas de paramètre 2 vide par erreur (pipe en trop), pour recherche rapide : regex \|\s*\| sur wstat.fr
    • rapport au 2017-01-26 : Utilisateur:Od1n/Modèles Langue à corriger
• bottleneck suivant rapport aux invocations Lua : {{Lien web}}
• réduire légèrement l'indentation des messages dans les pages de discussion
  • pour tous les utilisateurs, e.g. passer de margin-left:1em à 0.8em, visuellement ça ne surprend pas et on gagne un agréable 20 %
  • éventuellement faire davantage dans mon CSS perso, par ex. 0.5em (mais du tout je m'éloigne encore plus du rendu des pages que les autres utilisateurs ont)
  • étudier toutes les skins
• {{str len}} :
  • documentation erronée : la longueur est celle du paramètre "trimmé" (vraisemblablement depuis la conversion en Lua)
  • étonnamment, modèle très peu utilisé, du coup ça devrait être gérable pour vérifier les utilisations
  • à voir : plus performant si on s'inspire de {{Hex2dec/1}} pour traiter les chaînes courtes sans charger le Lua ?
    • observé un gain ssi on matche dans le switch, par contre si "parcours de tout le switch + fallback Lua" c'est très mauvais
    • en plus testé avec un switch court, et le gain diminue logiquement à mesure que le switch augmente…
    • alors à moins de créer un modèle « {{str len (pour chaîne pas très longue)}} »… (hint : no way.)
  • attention au multibyte UTF-8, à garder en tête
• Module:String et Catégorie:Modèle de manipulation de chaîne
  • beaucoup de proprage à faire
  • nouveaux modèles/modules startsWith et endsWith (noms à définir)
    • quelques références : String Recipes – Why does “abcd”.StartsWith(“”) return true? – Standardize Str::startsWith() and endsWith() with empty needle
  • modèles/modules {{str left}}, {{str rightc}}, {{str sub long}}… trucs à rendre plus consistants :
    • les noms, évidemment
    • support indexes négatifs là où ça serait utile
    • à bien réfléchir et à couvrir avec des tests pour éviter BC break : comptage à partir de 0 ou 1, comportement lorsque dépassement de la chaîne
    • garder en tête qu'on est sur de l'encodage multibyte
• {{Liste simple}} :
  • à étudier, mais ne serait-ce pas mieux sans le margin-bottom:0 ? (étudier aussi le line-height:inherit)
  • Discussion MediaWiki:Common.css#Rendre {{liste simple}} compatible avec les liste ordonnées
• idée : système pour avoir des listes à puces moins décalées à droite dans les infoboxes
• MediaWiki:Semiprotectedpagewarning : utilisé pour les semi-protections classiques mais aussi les étendues, à mettre à jour pour tester et afficher un message correct pour ces dernières
  • MediaWiki:Protectedpagewarning : la semi-protection étendue y a été implémentée (modifs d'avril 2016), mais est-ce utilisé avec ce message ?
  • MediaWiki:Protectedpagetext : code illisible…
• Documenter et catégoriser sous-modèles techniques {{Suffixe siècle}} et {{Exposant siècle}}, puis réflexion approfondie pour prévoir tout caveat, et enfin mise en prod une fois établi que tout est ok
  • ben déjà il y a à gérer les textes pour les liens, pi y'a aussi des tooltips
• {{ExpInd}} serait améliorable, cf. cette discussion
• Module Lua qui serait à ajouter aux modèles les plus impactés, et qui servirait à détecter la présence de paramètres non implémentés (comme on voit sur wstat.fr) et à catégoriser les pages fautives
  • existe déjà : Module:Correction syntaxique, syntaxe peut-être améliorable (paramètres sous forme d'une liste CSV ?)
• {{Infobox Conflit militaire}} :
  • de façon générale, du proprage à faire : virer les commentaires « fin de #if », mettre au clair les briques optionnelles (lignes vides, <nowiki />, toutça)
  • souci si notes contient une liste, la suite se retrouve dans le dernier item de liste (exemple : Bataille de Gavinana)
    • on avait réglé cela sur Conflit israélo-palestinien avec un <div> encadrant
  • éventuellement ajouter un paramètre pour modifier le titre « Notes » (mais à réfléchir dans la globalité avant de faire des ajouts épars)
• {{Références}} : 101316296 corrige les colonnes pas alignées en haut (bug CSS3 ?), mais du coup elles sont toutes collées en haut.
  • ajouter .references-small {padding-top:0.3em} (padding et non margin, car overlap margins avec monobook)
  • ils ont fait quelque chose de similaire sur le wiki angl.
  • fait, et bien avec margin
• même problème avec {{Colonnes}} ?
  • voir diff Common.css et discussion sur DIMS
  • de plus, ce sélecteur CSS ne serait-il pas une plaie niveau perfs ? (évaluation right to left)
  • uniformisation sélecteurs concernant .references-small et .colonnes (cf. mes edits sur le Common.css et ce message à Ltrlg)
• perfs CSS : reste dans le Common.css un joli star selector : .img_toggle, \n .img_toggle *, en espérant qu'il soit éliminable.
  • refs déjà 30384599, mais le contenu a changé par la suite, faut chercher les diffs en question
  • on dirait que c'est traité : 128249644, ainsi que les suivants : 128249715, 128249757 et 128249945
• {{Liste horizontale}} :
  • ajouter un mode sécable ?
  • voir : Discussion utilisateur:Od1n/Archives 2016#liste-horizontale
  • il est aussi question de la simplification code avec li:after {content:"\a0• "}, le seul inconvénient étant que IE 8 ne supporte pas :last-child et donc garde une boulette en fin de liste
  • justement à propos : Discussion modèle:Liste horizontale#Bug d'affichage
• {{Palette Portails sur l'alimentation et la gastronomie}} :
  • pas mal de chose à revoir
  • doublon avec {{Palette Portails Alimentation et Gastronomie}} ?
• {{Saison de série télévisée/Épisode}} : Wikipédia:Le Bistro/14 mai 2016#Division en deux paragraphes
  • pas satisfaisant en l'état, notamment le modèle doit rester compact en hauteur
  • uniformité espacements verticaux aussi lorsque colonnes
  • pour rappel : {{#if:...|<nowiki />\n
  • risque d'y avoir à rajouter du css, et faudrait voir à ne pas trop compliquer le code
• les codes de {{Autre4}} et {{Autre5}} seraient "fusionnables"
  • mais la vraie problématique c'est les noms pas très clairs de ces modèles (petite liste ici), réfléchir si cela serait améliorable
• {{Accueil/Cadre}} et {{Accueil/Cadre2}} : background CSS au lieu d'images simples (afficher la page sans CSS pour constater le problème)
• Catégorie:Boîte utilisateur habite ville française : faire un modèle pour factoriser le code de tout cela ?
• MediaWiki:Common.css : on est vraiment obligé de mettre toutes les images d'en-tête d'infobox à cet endroit ?
  • ça nous plombe bien le fichier : 14 % du nombre de lignes, 22 % du poids
  • sans compter toutes les WP:DIMS à chaque fois que quelqu'un veut rajouter une image
  • refs : 26030633, 26031099, 28508360, pour commencer
  • ça ne fonctionne pas en wikitexte, c'est remplacé par style="/* insecure input */"…
  • aussi essayé en base64 mais ça ne fonctionne pas non plus, c'est supprimé.
• créer modèle "rééd.", en se basant sur {{p.}} etc.
• icône pour toutes les palettes (pas que pour les palettes "multiples") et arranger hauteur / alignement vertical
  • cf. bas de ma page utilisateur et Discussion modèle:Méta palette de navigation#v · d · m
• {{DAYINYEARreverse}}, {{DAYINYEAR365reverse}}, {{DAYINYEAR366reverse}} :
  • formatage 1^er inadéquat car c'était pour générer des liens (Wikipédia:Le Bistro/25 août 2006#modification du bistro)
  • de toute façon, ce n'est plus utilisé ?
• résoudre confusion {{Suppression immédiate}} / {{Suppression Immédiate}}
• Les modèles de "compatibilité en:" ({{Cite book}}, etc.) devraient avoir une catégorisation dédiée (ils sont actuellement dans Catégorie:Modèle obsolète à garder)
• {{Cite video}} à franciser (conserver la compatibilité avec les copier-coller depuis le wiki EN)
  • voir plus grand, avec la mise à plat de systèmes de compatibilité des copier-coller contenant des {{cite book}} etc.
  • un autre exemple : {{WAM}}, copié-collé du wiki en:, utilisait {{border-radius}} et {{box-shadow}} qui ont été supprimés du wiki fr: (en prime les erreurs avec ces deux modèles ne sont pas visibles vu qu'ils sont utilisés dans des balises)
• redirs {{Mr}}, {{Ms}}, etc. : il faudra revenir sur l'annulation de mon changement (discussion avec Voxhominis)
• préparation {{date}} Lua :
  • faut jarter ce truc, là • RBOT postée • merci Orlodrim
  • il y a déjà des choses ici
  • amélioration du modèle demandée sur WP:DIPP • reminder : faudra mettre la doc à jour (paramètre facultatif, dernier exemple à corriger)
• un autre modèle pour la syntaxe duquel Lua va être très appréciable : {{lien}}
• {{puce}} transformé en redir vers {{·}} par Hlm Z. le 8 mars 2013, à voir (peu utilisé donc c'est pépère) (c'est surtout que ça a touché ma PU )
• {{Infobox Biographie}} : vérifier s'il reste beaucoup de paramètres âge au décès dans les articles
  • see 123987796
  • mais l'âge au décès n'est pas indiqué, see Abaï Kounanbaïouly
• Projet:Infobox/Ménage V1
• {{Infobox Musique (œuvre)}} :
  • paramètres classement et critique non documentés
  • critiques en pleine largeur ? (refs Discussion Projet:Musique/Archive 12#Modèle:Infobox Musique (œuvre))
  • nouveau paramètre "de qui" (refs Discussion Projet:Musique/Archive 10#Besoin d'avis pour le remaniement de l'Infobox Musique (œuvre))
  • histoire des auteurs/compositeurs (refs Discussion Projet:Musique/Archive 10#Autre modification de l'.7B.7BInfobox Musique (oeuvre).7D.7D)
• {{Essai}}, {{Principe fondateur}}, {{Règle officielle}}, etc. :
  • voir les pdd de ces modèles pour suggestions de Herr Satz (d · c) et liste complète des modèles concernés
  • factorisation code
  • marges verticales
  • kicker le align="center"
• lister avec Bottine (d · c) les pages de documentation de modèles supprimés (i.e. Modèle:Modèle supprimé/Documentation)
• {{Wikiprojet}} :
  • gestion plus évoluée des erreurs de syntaxe, pour informer l'utilisateur plutôt que d'afficher un résultat cassé
  • exemple : {{Wikiprojet|Informatique}} et {{Wikiprojet|informatique}} ne rendent pas la même icône, {{Wikiprojet/image}} essayant déjà de récupérer l'image du modèle d'ébauche ; voir pour harmoniser cela – edit : à première vue ça c'est bon maintenant (fallback ébauche à la fin, auparavant c'était utilisé en premier)
    • Modèle:Wikiprojet, Module:Wikiprojet, Modèle:Wikiprojet/image : faire moins hacky pour l'ajout de la catégorie "image déduite" (là c'est bidouillé pour se retrouver dans la balise d'image, et ça fonctionne mais jusqu'à quand) ; déplacer le "fallback ébauche" et la catégorisation vers le code du module, qui donc regarderait si Modèle:Wikiprojet/image a retourné vide
  • gestion plus élégante des sous-pages /À faire existantes mais vides
  • suite à mes modifs sur {{{projet}}}, plutôt traiter les redirections dans les inclusions, au lieu d'accumuler les alias. exemple Togo, etc. vers Afrique
• Les modèles de diptyques se reproduisent entre eux et au fil des générations développent des tares diverses :
  • {{Succession musicale}} : flèches moches (see {{Images}}) et non cliquables
  • {{Infobox/Succession}} : on l'a toujours dans le côlon, impossible de faire [[Foo (bar)|Foo]]
• Migrer tous les liens externes Allmusic (avec ou sans modèle) vers le nouveau format d'URL
  • demande : Projet:Modèle/Demandes#Mise à jour du modèle:Allmusic
  • procédure : en:Template talk:Allmusic#URL syntax has changed
• {{Lien web}} : mettre un terme à cette confusion entre les paramètres date et consulté le (ce dernier correspond à accessdate du modèle anglais, c'est un tout autre usage ; c'est pour les archives, système qui en plus n'est pas présent dans notre modèle)

  de façon générale, il y a des choses à revoir dans ce modèle

• Améliorer {{Semi-protection}} et {{Semi-protection longue}} en reprenant les améliorations apportées à {{Protection}} (catégorisation, texte sur mesure, etc.)
  • et aussi {{Nom protégé}}
  • Pour le jour où – on l'espère ! – j'aurai les droits : nettoyer le dernier {{Semi-protection|nocat}} (inutile depuis que ce modèle n'affiche plus de bandeau), qui se trouve sur Wikipédia:Demande d'intervention sur une page protégée/Archives/2#Tir groupé (au passage, ajouter un {{Protection}} sur cette page ; quoique, à voir aussi : pourquoi cette page d'archive DIPP serait protégée et elle seule ? c'pas cohérent)
• {{Infobox/Triptyque}} (utilisé par exemple dans {{Infobox Console de jeux vidéo}}) : problème du « ante=[[foo]], post=[[bar|baz]] // [[Image:...|link=foo]] »

résultat : images non cliquables pour la navigation

solution : implémenter images cliquables (doc MediaWiki) ; permet de ne pas ajouter de paramètres

• Il y a aussi bien sûr {{Infobox/Diptyque}}. Pour informations utilisation voir ceci. Et en voila un beau {{Infobox Heure}}. Enjoy.
• À essayer : avoir une marge supérieure avec la syntaxe {{Palette Truc}} (comme avec {{Palette|Truc}})
  • CSS du style : table.navbox {margin-top: 1em} (en fait déjà présent dans le Common.css mais écrasé par du CSS inline dans {{Méta palette de navigation}})  /  div.navbox-container table.navbox {margin: 0}  /  div.navbox-container {margin-top: 1em}
  • cas des palettes empilées à l'ancienne ({{Palette Foo}} \n {{Palette Bar}})
  • encore plus problématique : cas des palettes non nommées suivant la convention « Palette ... »
  • il faut aussi gérer correctement {{Méta palette de navigation sous-liste}}
• Problèmes de performances liés aux modèles, goulots d'étranglement causés par la pléthore de #ifexist :
  • {{Date}} : attention, implique nécessairement une réduction de fonctionnalité, consultation de la communauté nécessaire
  • modèles de pitidrapeaux : éventuellement solliciter l'aide avisée de Xfigpower (d · c) si je n'arrive pas à m'y retrouver dans tout ce foutoir
• {{BNF}}, {{ERIC}}, {{ISSN}}+{{Recherche ISSN}}, {{LCCN}}+{{Recherche LCCN}}, {{CODEN}}(WTF lien rouge)+{{Recherche CODEN}}, {{OCLC}}+{{Recherche OCLC}} (j'en oublie peut-être) :
  • corriger les noarchive
  • voir si y'a pas de la réorganisation à faire, au sujet des modèles "directs" {{Recherche (...)}} (à confronter avec l'approche que j'avais prévue pour les BNF) c'est très bien comme ça
  • les sections "Voir aussi" dans les documentations seraient à arranger / unifier
• {{OCLC|nu=}}... ("nu" devant être obligatoirement vide ! toutefois je connais une bonne âstuce pour le corriger : {{#ifeq: {{{v|}}} | {{{v|-}}} | v was specified (and may be empty) | v was not specified }} )
  • ... mais plutôt remplacer par {{OCLC brut}}, moins tordu n'est-il pas ?
  • attention, point à voir au passage : le <small>... faudra vérifier l'usage actuel du modèle en mode sans parenthèses
• factorisation des modèles d'abréviation de civilité (cf. pdd du modèle {{Mlle}})
• Catégorie:Article orphelin et Catégorie:Wikipédia:Tentative d'adoption : arranger un peu cela, et bien sûr traiter des articles
• créer un modèle {{Taille fichier}} pour ne plus faire ça :

  <small>({{unité|4.2|{{abréviation discrète|Mo|Mégaoctets}}}})</small>

  • pourra être ajouté dans ces articles : Appel du 18 Juin • Les Fleurs du mal • Théorie du chaos
  • exemple de rendu : (4,2 Mo)
  • penser à la gestion du pluriel (« toto(s) » n'est pas français)
  • ne pas oublier le cas particulier de kilooctet, sans majuscule à « ko » (voir Octet)
  • dans le code de ce modèle, on pourrait se passer de {{unité}} et rendre insécable "à la main" (juste un &nbsp; à mettre, et ça sera mieux que de passer par un CSS white-space:nowrap ; par contre ne pas oublier le {{formatnum:}} !)
  • ne pas inclure le <small> dans le modèle ? pour pouvoir utiliser dans des références
• faudra refaire une passe avec Bottine pour voir/finaliser l'état des {{Abréviation}}
  • pour accès rapide ; le rapport est enregistré ici : Utilisateur:Od1n/Statut Abréviation
  • j'avais noté quelques cas particuliers ici : Discussion utilisateur:Lgd/archives14#Migration du Modèle:Abréviation
• {{Infobox Logiciel}}, {{Dernière version stable/xxxx}} et {{Dernière version avancée/xxxx}} : trouver un moyen, simple et rapide si possible, pour ne plus afficher la version avancée lorsque celle-ci est caduque
  • à harmoniser : date en taille normale en mode « sans sous-modèle », date encadrée de <small> en mode « avec sous-modèle »
• palettes de navigation :
  • réduction font-size ? (constater la différence entre 90 % et 88 % sous Firefox) et line-height en accordance ; s'inspirer de ce qui est fait sur le wiki EN ; a priori, à la fois plus compact et plus lisible, bien sûr comparer sur moulte plates-formes
  • pouvoir enrouler/dérouler en cliquant sur toute l'en-tête ; évidemment faut gérer les liens qui y sont superposés (ahhh les joies du bubbling)
    • fait dans le js perso ; serait à intégrer directement dans le MediaWiki:Common.js pour que tout le monde en profite
    • il faudrait appliquer le même système aux boites déroulantes fait, mais il reste encore de rares cas non gérés (le fameux fr-collapsible qui serait de toute façon à dégager)
  • en vrac, quelques trucs à ne pas oublier en cas de chantier sur le code des palettes :
    • diffs de certains codes assez alambiqués : 128635849, 134413811
    • {{Méta palette de navigation sous-liste}} (oui, c'en est un autre que l'habitel modèle "sous-groupe", et celui-là je l'oublie toujours)
• aligner horizontalement les {{Référence à confirmer}} avec les <ref> ? (cf. classes reference et exposant dans le Common.css)

attention, chantier peut-être délicat (par exemple, homogénéité avec le niveau des {{référence nécessaire}}, étudier les 2 classes ci-dessus, faire très attention à l'interlignage, etc.)

• {{Infobox/Ligne mixte optionnelle}}, {{Infobox/Ligne mixte}}, et peut-être d'autres : finir la simplification doc (voir échange sur ma pdd)
• faire sauter les {{Infobox/Ligne mixte site web}} et {{Infobox/Ligne mixte site web optionnel}} qui compliquent la vie plus qu'ils ne la facilitent
  • pour rappel, même si on ajoute un paramètre à ces modèles pour pouvoir modifier le texte du lien, il faudrait aussi ajouter un paramètre dans les infoboxes...
  • Ou alors mieux, les conserver mais en modifiant la syntaxe du paramètre 2 pour un conventionnel [http://foo/ foo] (car ce modèle a quand même un avantage : il fournit un libellé par défaut « Site Web »)
• {{Lien}} et {{MultiLien}} : implémenter support de plusieurs langues (noter qu'il y a déjà eu des essais de produits)
• {{Maladie génétique}} : diverses opérations de maintenance à réaliser, pour faire suite à la transformation en infobox V2
• Catégorie:Comité de lecture et Catégorie:Wikipédia:Atelier de lecture : un peu d'organisation à faire (legacy de l'ex Comité de Lecture ?)
• Catégorie:Palette Félins : les listes d'éléments auraient besoin d'être uniformisées (alignement, séparateurs...)
• Catégorie:Bandeau renvoyant vers des homonymes : petit toilettage des modèles (nohr, documentation, etc.) (échange sur ma pdd)
• {{Début des onglets}}, {{Début des onglets 3D}}, etc. : il y en a encore à arranger
• Utiliser Bottine pour mettre à jour les noms de paramètres "legacy" (exemple "foo_bar" → "foo bar") sur les pages utilisant les modèles que nous avons modifié. Une fois fait, enlever le support du nom de paramètre legacy.
• {{Palette Sexologie}}, {{Palette Régime alimentaire}}, {{Palette Castlevania}}, {{Palette Jeux de rôle}}, {{Palette Legacy of Kain}} : utiliser {{Liste éléments}}
• {{Liste éléments}} : documenter l'utilisation de {{=}} ?
• {{YouTube}} : les paramètres sont pour l'instant exclusivement non-nommés, et ça porte fichtrement à erreur (je comprenais pas le problème, j'ai dû regarder le code...)
• {{Imdb titre}} (etc.), {{Allociné titre}} (etc.), {{MySpace}}, {{Afdb nom}}, {{Iafd nom}} :
  • À propos des modèles IMDb, une discussion est en cours ici : Discussion Projet:Modèle/Demandes#Uniformisation des modèles IMDb
  • Sondage : casse des noms de modèles, ie. « IMDb / AlloCiné » ou « Imdb / Allociné » ? Évidemment il y aura aussi des redirections. Attention : « Afdb » « Iafd » semblent être des abréviations officieuses et non reconnues.
  • Sondage : préférer les paramètres nommés ou non nommés ? (sachant que plusieurs modèles en sont déjà à 3 paramètres)
  • Arranger (simplifier) les pages de documentation
  • fusion {{Afdb}} et {{Afdb nom}}
  • {{Iafd nom}} : résoudre le problème des URL
  • créer modèles AFDB et IAFD pour films
• Projet:SVA/Modèle Cadre : un exemple, parmi tant d'autres, de "cadres de projet" dont tous les codes seraient à factoriser
• Modèles de siècle {{s}}, {{s-}}, etc. :
  • pourquoi faut-il s'embêter à saisir l'exposant... (déjà signalé en 2007)
  • faudrait expliciter le nombre romain avec un abbr title...
  • voir modèle {{siècle}} de Lgd, plus récent et considérant ces points
• Bourdel de modèles en chaîne
• Une autre cascade de modèles en chaîne, voir si c'est améliorable :
  • {{Calendrier annuel}}, {{MoisCalendrier}}, {{MoisCalendrier/2}}, {{MoisCalendrier/3}}
  • voir Discussion Projet:Modèle/2010#Calendrier annuel