Discussion utilisateur:Od1n

Salut,

Bon OK, j'avais effectivement inversé les lignes et les colonnes (mal réveillé, surement ), néanmoins cela ne m'explique pas dans le fond pourquoi ce rangement, que je considère comme plus pratique, a été annulé. — Superjuju10, le 30 août 2018 à 20:11 (CEST)

Salut, je suis désolé si l'annulation t'a contrarié. J'ai rétabli cette structure, mais je ne t'empêche pas de revenir dessus, ça m'est assez égal.

De toute façon ce bandeau a des problèmes plus importants :

• markup dégueulasse (produisant par exemple ce genre de bug sournois)
• liens trop nombreux et/ou sans structuration, ils sont vraiment listés "en vrac" et ne donnent guère envie d'être utilisés (discussions : Deux liens inutiles ?, Allègement liens dans l'en-tête)

od†n ↗^blah 30 août 2018 à 21:04 (CEST)

Salut Od1n,

Je pense qu’il faudrait créer un bandeau spécifique pour Special:AbuseFilter/380 car le bandeau générique n’aide pas beaucoup pour un nouveau.

Ma modif a été détectée par le filtre et je n’ai pas trouvé ce qui clochait ? (Aucune erreur de référence affichée).

Merci !

— Thibaut (discuter) 18 mai 2023 à 15:50 (CEST)

Salut,

• Je suis d'accord qu'il y aurait effectivement nécessité d'afficher un bandeau plus explicatif.
• Pour ce qui est de ta modif, c'est un faux positif dû à la quote manquante ici : <ref name="GDT-digital>. C'est une erreur que MediaWiki tolère et laisse passer, et qui est beaucoup plus fréquente que je n'aurais imaginé.
  • J'ai dans les cartons une détection plus laxiste, qui permettrait de laisser passer diverses syntaxes clairement erronées mais qui fonctionnent malgré tout, et ainsi d'éviter ce faux positif.
  • À noter qu'il semblerait que WikiCleanerBot corrige cette syntaxe erronée ; on pourrait donc se permettre de la laisser passer, puis attendre que le bot la corrige plus tard.

Tu peux aussi consulter cette discussion : Wikipédia:Bulletin du filtrage#Filtre 380, où ces sujets du bandeau et du faux positif ont justement déjà été évoqués.

od†n ↗^blah 18 mai 2023 à 17:55 (CEST)

Bonjour Od1n.

Cela d'un côté, dans une barre d'outils, ceci d'un autre dans la boîte apparaissant sous la fenêtre d'édition. Je ne sais pas si la raison invoquée à l'époque (existence d'un outil de coloration syntaxique ne sachant pas gérer le <br> mais le <br/> et, sans doute, le <br />, valides en XHTML) était bonne, ni si elle est toujours d'actualité. Cependant, ce n'est pas très cohérent. Je m'apprêtais à mettre à jour Aide:Barre d'outils d'édition/Monobook sur plusieurs petits points et me demandais s'il fallait y indiquer <br/> ou remodifier le gadget de barre d'outils dans le sens inverse.

À propos de l'harmonisation des #REDIRECTION, merci ! Il reste un cas dans Projet:Scripts et gadgets/Refonte Common.js avec jQuery dont je ne connais pas l'utilisation et qui est présent dans ta to do list.

Quant au petit problème de hauteurs dans les titres de boîtes déroulantes, le cas vraiment farfelu a été retouché (en gagnant au passage 25 ko). Aucun appel dans les articles ne fixe de valeur inférieure à 1.6em pour le paramètre hauteur. Le modèle (protégé) peut être modifié selon la solution qui te semble meilleure.

Merci. — Ideawipik (discuter) 22 janvier 2024 à 14:27 (CET)

• Pour l'histoire du <br> : j'ai effectué 211765871. Voir sur MDN la page Void element, et en particulier la section Self-closing tags : « Self-closing tags (<tag />) do not exist in HTML. » (les ancres sont foireuses, faut remonter un peu le scroll pour voir le début de la section)
• Pour la page Projet:Scripts et gadgets/Refonte Common.js avec jQuery : c'est une page qui est de plus en plus obsolète, mais j'ai quand même effectué 211765976.
• Pour le modèle de boite déroulante, j'ai répondu dans la discussion là-bas.

od†n ↗^blah 23 janvier 2024 à 00:27 (CET)

Bonjour Od1n. Contrairement à ce que tu sembles penser, les sites sont bien considérés depuis l'origine du projet comme des publications (numériques dans ce cas), même si leur cas n'est pas traité explicitement par le Lexique, et doivent donc être obligatoirement graphiés en italique. Ils renvoient en effet très souvent vers un périodique principal (ex. The New York Times) ou sa version numérique (ex. nytimes.com). Or étant donné que dans une grande majorité des cas c'est le média principal qui est mentionné dans le champ « site », la suppression de la mise en italique automatique conduit à ne plus respecter les conventions typographiques dans la majorité des cas comme on peut le constater depuis le changement. L'expérience ayant prouvé que leur ajout au coup par coup est ingérable, il vaut mieux conserver l'automatisation précédente. Cordialement, V°o°xhominis ^[allô?] 12 février 2024 à 21:48 (CET)

Bonjour, pas de souci pour l'annulation, et merci pour les explications. C'est simplement que dans les articles portant sur les sites web, que j'ai parcourus au fil du temps, j'ai fréquemment constaté que le nom du site n'est pas en italique. J'ai retiré cet italique du modèle après avoir constaté que {{YouTube}} n'écrit pas « YouTube » en italique (et, je pense, plutôt à raison), tandis que {{Lien web}} applique l'italique automatiquement (et surtout sans pouvoir le défaire, sauf avec une bidouille que j'expose plus loin dans ce message). N'ayant rien trouvé dans les conventions typo au sujet de l'italique pour les sites web, avant de retirer l'italique, j'avais consulté divers articles sur des sites web, confirmant bien que la plupart du temps le nom du site n'y est pas écrit en italique.

De plus, je viens à nouveau de survoler quelques pages de rapports wstat.fr, et j'ai le sentiment que dans pas mal de nombreux cas, l'italique n'est vraiment pas souhaitable. Ne serait-ce que lorsque c'est un domaine brut qui est saisi (e.g. « site=www.example.org »), mais les cas de figure sont vraiment variés (et nombreux, au vu de l'immense quantité d'utilisations du modèle). Par ailleurs, il existe conjointement le paramètre "périodique", pour lequel la mise en italique automatique fait quand même davantage sens.

Tu remarqueras dans le code du module qu'il y a parfois des <i>...</i> et parfois des <span class="italique">...</span>. La différence est que le deuxième permet d'annuler les italiques… en en plaçant d'autres à l'intérieur (voir code). Mais c'est un mécanisme prévu pour les citations, là c'est un "usage détourné" qui relève de la bidouille. Tout cela pour dire qu'un paramètre du genre site en italique=non serait peut-être pertinent.

od†n ↗^blah 12 février 2024 à 22:38 (CET)

Il y du flou à ce sujet : le fameux « usage flottant » qui oblige un projet à adopter une règle par souci de cohérence générale. Le pilier des conventions typo ne l'abordant pas car ayant cessé d'être mis à jour avant l'explosion d'Internet, on a regardé à l'époque — il y a plus de 15 ans ! — ce qui se faisait dans les autres ouvrages et organismes de référence. La quasi totalité préconisant l'italique pour toutes les publications, qu'elles soient physiques ou numériques (y compris les titres de logiciels), on a logiquement choisi cette présentation puisque les champs concernés peuvent accueillir soit le titre officiel de la publication, soit son édition numérique. Il est en effet moins gênant qu'un nom de domaine soit en italique plutôt qu'un titre de périodique ne le soit pas, les CT étant pour le coup parfaitement claires à ce sujet. Ajoutons à cela que selon la documentation, le nom du site doit être indiqué sans les www. (perso, je les supprime dès que je tombe dessus) ; on peut donc de fait le considérer comme un titre à part entière. Peut-être conviendrait-il de consigner enfin ce choix dans les CT, même s'il s'est imposé jusque-là sans problème ? V°o°xhominis ^[allô?] 13 février 2024 à 12:34 (CET)

PS : Pour ce qui est de Youtube, c'est une de tes modifications qui a supprimé l'italique il y a plus de dix ans, alors qu'elle est prévue dans la plupart des autres modèles renvoyant vers des publications numériques (ex. {{ADS titre}}, {{Imdb titre}}, etc.). C'est le souci d'être un Ancien : on finit par oublier ce qu'on a fait il y a des siècles ! Personne n'a réagi (perso je n'utilise pas le modèle) donc ça a perduré. On n'a même pas retoqué la « graphie particulière » pourtant contraire aux usages… V°o°xhominis ^[allô?] 13 février 2024 à 12:34 (CET)

Il y a justement {{Italique si non précisé}} que j'ai récemment créé pour un autre chantier, et dont le module sous-jacent peut aussi être utilisé par d'autres modules. Avec {{Lien web}}, cela fait que le paramètre continuerait d'être mis en italique automatiquement, et si le rédacteur met une valeur "libre" avec seulement une partie en italique, ce formatage serait préservé (actuellement, le formatage est inversé : ce qui est saisi en italique est affiché en romain, et inversement). En revanche, il ne serait plus possible de supprimer entièrement l'italique, puisque |site=valeur (le cas habituel) continuerait de toute mettre en italique, et la bidouille |site=''valeur'' conserverait l'italique au lieu de l'inverser comme actuellement.

Après un rapide survol des résultats wstat.fr, dans la très grande majorité des cas l'ajout d'italiques semble être pour effectivement afficher en italique (donc actuellement l'affichage est erroné, vu qu'il est inversé), mais j'ai quand même repéré quelques cas où l'intention est bien la "bidouille" pour inverser l'affichage. Rien d'insurmontable à ce niveau : malgré le nombre gigantesque d'utilisations du modèle, il n'y a "que" quelques milliers d'utilisations avec des italiques saisies dans le paramètre, et de toute façon juste en mettant en place le "italique si non précisé", on corrigerait davantage d'utilisations que l'on en dégraderait, et la syntaxe serait moins surprenante pour les utilisations futures.

Le problème majeur, et pour lequel je ne vois pas vraiment de solution, serait l'impossibilité de désactiver entièrement l'italique, comme j'ai expliqué précédemment.

od†n ↗^blah 14 février 2024 à 19:59 (CET)

J'ai entretemps pensé à la création d'un modèle {{pas en italique}}, permettant d'afficher son contenu en romain même dans un champ automatiquement formaté en italique ; j'étais sur le point de le créer, mais j'ai remarqué que cela existe déjà : {{noitalic}} (edit : j'ai renommé {{noitalic}} en {{pas en italique}}, l'ancien nom restant bien entendu utilisable).

Pour résumer la situation :

L'implémentation du "italique si non précisé" permettrait d'arriver à une situation plus saine, avec l'affichage de résultats moins surprenants, et la correction de la plupart des utilisations avec des italiques saisis manuellement. Le seul inconvénient étant une régression sur les quelques utilisations reposant sur le mécanisme "inversé", et on peut s'amuser à les chercher et les corriger grâce au listing wstat (exemple de recherche).

Voilà pour la partie technique. La partie qui devrait davantage t'intéresser, et qui relève plus de ton ressort, serait effectivement la formalisation de la typographie.

od†n ↗^blah 14 février 2024 à 22:23 (CET)

Hello. Merci beaucoup pour tes propositions qui sont en effet des pistes intéressantes (la partie technique m'échappe totalement bien que j'essaie de m'y intéresser !), surtout celle qui consisterait à désactiver ponctuellement si nécessaire l'italique par défaut. Mais il faut visiblement clarifier le statut des sites internet car, à la lecture de certains avis et bien que cet usage soit en vigueur depuis quasiment l'origine du projet, la notion de « publications » est sujette à débat. A suivre donc, en espérant trouver des sources explicites incontestables pour trancher - ce qui n'est malheureusement pas le cas dans celles qui servent de fondements aux CT - ou à défaut conserver le consensus actuel, étant donné les implications à l'échelle du projet. -- V°o°xhominis ^[allô?] 17 février 2024 à 15:29 (CET)

Refs la discussion récente sur le sujet : Discussion modèle:Lien web#Paramètre site. od†n ↗^blah 17 février 2024 à 16:25 (CET)

Histoire de rester dans le sujet, je viens de tomber par hasard sur {{Allociné série}} qui, contrairement à {{Allociné titre}}, affichait les titres des séries… en romain ! Pour le coup, il n'y a pas de doute puisque le but du modèle est bien d'afficher le titre des séries et que l'italique est donc la norme. Je me suis donc basé sur ton code du second modèle pour corriger le premier, mais si tu veux jeter un coup d'œil… V°o°xhominis ^[allô?] 17 février 2024 à 20:20 (CET)

J'ai implémenté {{italique si non précisé}} dans ces modèles.

En raison du terme « précision » il pourrait y avoir une confusion entre {{italique si non précisé}} et {{titre sans précision}}, et je suis chagriné de quand même ajouter l'appel Lua lorsque c'est la valeur par défaut {{titre sans précision}} qui est utilisée, parce que dans ce cas une simple mise en italique ferait l'affaire. Mais bon, c'est ce que j'ai de mieux à proposer pour l'instant, autrement on complique le code des modèles.

Si tu veux, il y en a plein d'autres à traiter : {{Imdb titre}}, {{Imdb épisode}}, {{Imdb récompense}}, {{Ann manga}}, {{Ann anime}}…

od†n ↗^blah 17 février 2024 à 22:59 (CET)

Bonjour,

L’article « DokuWiki » fait l'objet d'un débat d'admissibilité (cf. Wikipédia:Débat d'admissibilité). Après avoir pris connaissance des critères généraux d’admissibilité des articles et des critères spécifiques, vous pourrez donner votre avis sur la page de discussion Discussion:DokuWiki/Admissibilité.

Le meilleur moyen d’obtenir un consensus sur l'admissibilité de l’article est de fournir des sources secondaires fiables et indépendantes. Si vous ne pouvez trouver de telles sources, c’est que l’article n’est probablement pas admissible.

N’oubliez pas que les principes fondateurs de Wikipédia ne garantissent aucun droit à avoir un article sur Wikipédia.

Accéder au débat

Chris a liege (discuter) 29 février 2024 à 23:05 (CET)

En ce qui concerne les annonces de DDA, je ne ne fait que suivre les procédures, c'est-à-dire avertir les intervenants sur les articles en question. Un seul oubli et on me le reproche. Je trouve donc cela malveillant de parler de spam et en plus d'être grossier. Si vous ne voulez plus être emmerdé, il suffit d'insérer en tête de votre page de discussion {{bots|deny=pastec}} (sans les nowiki). Simple non? --Chris a liege (discuter) 24 mars 2024 à 01:16 (CET)

Y compris les intervenants qui n'ont fait que corriger une faute d'orthographe quinze ans auparavant ? Du coup le mec qui a effectué des corrections mineures sur plein d'articles, ensuite il se fait pourrir de notifications les quinze ans qui suivent ? Et aussi, cette traque aux articles à supprimer, ça me gonfle. od†n ↗^blah 24 mars 2024 à 01:27 (CET)

Bonjour,

Si vous utilisez l'habillage « Vector (2022) », ce message vous concerne, sinon vous pouvez l'ignorer. Pour vérifier l'habillage utilisé, rendez-vous sur le lien suivant : Spécial:Préférences#mw-prefsection-rendering-skin, ou cliquez sur l'onglet « Préférences », puis « Apparence » et consultez la section « Habillage ».

Depuis le 18 mars 2024, les deux habillages Vector sont dissociés (Vector (2010) et Vector (2022)). Ainsi, les comptes qui utilisent Vector (2022) doivent faire renommer deux pages :

• vector.js vers vector-2022.js ;
• vector.css vers vector-2022.css.

Si tel est votre cas, cliquez sur le bouton ci-dessous pour formuler les demandes de renommage puis sur « Publier les modifications » :

Demander le renommage

Bonne journée,

Plus d'informations sur cette page.

Salut @Od1n,

Une curiosité m'attire : j'aurais souhaité trier les résultats d'une inclusion de Spécial:Index de sorte que Wikipédia:AbuseFilter/Messages d'avertissement affiche Abusefilter-warning-1 suivi de Abusefilter-warning-4. Bref, changer la manière de trier.

Nativement, ça semble compromis, j'ai donc pensé à Lua car tu avais concocté Module:AutoWikiBrowser (JSON) pour #Comptes autorisés et suivant.

J'ai créé Module:Index mais je suis perdu :

• getContent() ne récupère que le raw de la page, donc rien pour une page spécial (génial)
• avec frame:preprocess, pas mieux.

Soit je m'y prends très mal (probable, je ne parle pas Lua), soit c'est impossible, soit les deux. J'ai testé avec {{#invoke:Index|main|title=Special:Index/MediaWiki:Abusefilter-warning}} et {{#invoke:Index|main|title=User:LD}} comme témoin.

Sais-tu si on peut récupérer le contenu d'une page spéciale avec Lua ? (Sinon je me contenterai de le faire avec mon bot).

Bien à toi, LD (d) 5 avril 2024 à 02:33 (CEST)

Salut,

Je vois, tu voudrais un tri naturel. Pour récupérer le contenu de la page spéciale, je viens d'effectuer divers essais, je pense exhaustifs, avec frame:preprocess() et avec frame:expandTemplate(), sans succès : cela retourne toujours un "UNIQ". Je pense que l'opération est impossible…

od†n ↗^blah 5 avril 2024 à 07:05 (CEST)

Salut,

Merci de ta réponse et de tes essais. Sait-on jamais : j'ai créé phab:T361916, sans t'y ajouter (pour éviter les emails non désirés). Evidemment, j'avais créé Module:Index (et non Spécial:Index ).

J'ignore si une tâche sur une méthode Lua auraît une chance d'aboutir, donc je me suis abstenu. LD (d) 5 avril 2024 à 11:05 (CEST)

Re, je passe tevi (arrêter de pourrir la page des QTs), juste pour un merci supplémentaire (oui, quand je juge que c'est mérité, je ne mégote pas sur les merci ! , car je me rends compte que c'est toute ta PU qui est une vraie mine d'or ; et va me permettre d'accéder bien plus rapidement que je ne l'espérais à tout un tas de WP-geekeries que j'avais un peu de mal à trouver au sein des « regular » docs, aides, toussa...
Et quand je pose des questions : soit j'en pose trop (oui, /me questions <==> merci, et on ne répond qu'à une partie, soit on répond à côté, soit... on ne répond pas .
Bon wikibreak, s'il n'est pas terminé !
— jeep (j33p) ॐ 4 mai 2024 à 13:49 (CEST)

Salut. Est-ce qu'on peut contrer ce genre de modif qui n'est pas détectée actuellement par le filtre 145 ? (pas le temps de m'en charger) 'toff ^[discut.] 1 juin 2024 à 19:19 (CEST)

Salut, à première vue je dirais que ça serait délicat à faire… D'un point de vue "programmatique", c'est simplement un ajout de terme, donc comment faire la différence entre un ajout approprié et un "ajout" tel qu'effectué ici ?

La seule solution qui me semble viable serait de rechercher très spécifiquement un tel remplacement de destination de lien, mais cela en vaudrait-il le coup ? J'imagine qu'une telle modification ne doit vraiment pas être fréquente. Le ratio "quantité de code à ajouter / nombre de détections" ne me parait pas très favorable…

od†n ↗^blah 1 juin 2024 à 19:31 (CEST)

Bonjour, en regardant la page Olympiakós (basket-ball) je vois un message d'erreur :

Unité « ftin » inconnue du modèle {{Conversion}}

J'ai essayé de comprendre le modèle {{player3}} qui utilise {{conversion}}. Je sais pas si l'erreur provient de l'appel à conversion, ou de modification de ce dernier modèle ({{player3}} ne semble pas avoir été modifié depuis longtemps). Avez vous une idée pour corriger ce problème. Merci d'avance. 2A01:E0A:9F5:C260:6B96:3F70:2DC0:3EDB (discuter) 28 juin 2024 à 17:45 (CEST)

Bonjour, le modèle {{Conversion}} ne propose effectivement pas d'unité « ftin », donc cela ne risque pas de fonctionner. La petite chose que je ne comprends pas, c'est qu'apparemment ça a toujours été le cas, mais je ne vois pas comment le modèle {{Player3}} aurait pu être publié initialement en ne fonctionnant pas de la sorte, et comment cela aurait pu rester comme ça depuis 2016.

D'autre part, j'ai constaté de nombreux défauts dans le modèle {{Conversion}}, j'ai posté un message à ce propos sur Discussion Projet:Modèle#Modèle:Conversion, où il sera plus approprié de poursuivre la conversation.

od†n ↗^blah 29 juin 2024 à 13:51 (CEST)

Bonjour ‎Od1n . Ta récente modification de la page « Sélénium (homonymie) » mérite discussion. Dans ta version (ici) l'encadré des autres projets apparaît dans la partie texte, alors que dans la précédente (ici) il est ancré dans le bloc de tête, qui sert aux aiguillages et à la description standard de la page — ce qui est plus logique —, et le fait qu'il prolonge la ligne de séparation me paraît au contraire une bonne chose. Quant aux ajustements de mise en page dont tu parle dans ton commentaire de diff (ici) je ne sais pas (je n'ai pas le temps maintenant d'aller voir en détail), en tout cas je n'ai jamais rencontré de mise en page posant un problème particulier avec cette disposition. Amitiés, Ariel (discuter) 11 août 2024 à 08:44 (CEST)

Bonjour, je comprends parfaitement ton point de vue "d'intégrer" la boîte dans le bandeau de navigation. Cependant, c'est une mise en page un peu "personnelle" et qui ne correspond pas à ce qui se fait ailleurs sur le wiki.

L'ordonnancement recommandé dans les articles étant celui-ci (consensus) :

1. bandeaux d'homonymie
2. éventuels bandeaux d'avertissement, ébauche, etc.
3. infoboxes, images en thumb right…

Pour les pages d'homonymie, pour ma part je pense qu'il est préférable de correspondre de même à cette structure. Je considère que les bandeaux d'homonymie ne doivent être coupés en aucun cas.

Concernant les histoires de CSS que j'ai indiquées, on parle d'ajustements de 0.5em, donc tout le monde ne remarque pas forcément les différences (même si moi je les remarque immédiatement et que ça me fait bondir), par contre cela permet de comprendre que les bandeaux d'homonymie ont vraiment vocation à être placés en tout premier dans le contenu.

od†n ↗^blah 11 août 2024 à 09:39 (CEST)

Bonjour Od1n , merci pour ta création Catégorie:Modèle Lien avec un paramètre inconnu. Penses-tu qu'il serait possible de séparer les pages en deux nouvelles sous-catégories : une cat pour les pages de l'espace encyclopédique, l'autre pour tout le reste (pages d'utilisateurs, discussions, etc.). Histoire d'y voir plus clair. Merci. — V_VL_LA_AC_C 24 août 2024 à 12:42 (CEST)

Je viens de réaliser cela. Et effectivement, l'immense majorité des utilisations erronées sont dans des pages utilisateur… (je viens de remarquer que j'avais lu ton message trop vite : j'ai catégorisé à part les namespaces « Utilisateur » et « Discussion utilisateur », de ton côté tu avais proposé de catégoriser à part tous les namespaces hors 0. Bon, finalement comme j'ai fait ça va plutôt bien.)

• Le problème semble très majoritairement venir des traductions d'articles, avec des paramètres "2" et "3" inexistants, provenant du modèle en:Template:Ill de chez enwiki.
• Il y a aussi le coup du paramètre "en=" inexistant, que tu sembles déjà connaître. C'est une problématique qui a déjà été discutée. Chercher « en= » dans la pdd du modèle, c'est évoqué dans plusieurs discussions, notamment celle-ci. La mise en œuvre de paramètres dynamiques ("en=", "de=", etc.) serait une mauvaise idée, justement parce qu'il s'agit de noms de paramètres dynamiques.

Dans l'éventualité où un jour il y aurait moins d'utilisations erronées, et de façon durable dans le temps, la suppression de cette sous-catégorie dédiée serait à envisager.

od†n ↗^blah 24 août 2024 à 21:31 (CEST)

Merci !
Oui, l'essentiel pour moi est d'avoir une catégorie moins polluée pour mieux s'y retrouver, donc les nouvelles catégories me conviennent.
Concernant le contenu de la catégorie, c'est un énième exemple de pourquoi l'outil de traduction de wikifr fait probablement plus de mal que de bien (de ma petite expérience sur Wiki en tout cas) : d'après moi, quelqu'un qui utilise l'outil aura vite tendance à faire de la trad auto sans vérifier les modèles (et donc au final au moins un autre contributeur devra repasser derrière), alors que quelqu'un qui souhaite traduire correctement un article (texte ET forme/formatage) n'en a pas vraiment besoin. Mais bon, je ne m'en sers pas et je ne suis pas actif depuis énormément de temps, donc peut-être que je loupe quelque chose. Bref, merci encore pour la (nouvelle) catégorie! — V_VL_LA_AC_C 24 août 2024 à 21:59 (CEST)

Salut. Tu crois qu'on pourrait améliorer le filtre 145 pour qu'il détecte ça ou ça ? Je vois pas comment pour le premier (trop de possibilités ?) mais il y a peut-être moyen pour le deuxième ? 'toff ^[discut.] 31 août 2024 à 06:58 (CEST)

Le temps que je t'écrives, j'ai trouvé une solution et modifié le filtre pour le premier cas. Tu peux jeter un œil pour corriger/améliorer. 'toff ^[discut.] 31 août 2024 à 07:07 (CEST)

Encore moi (j'abuse) : à mon avis, il faudrait aussi par anticipation prévoir le même remplacement pour les gentilés. 'toff ^[discut.] 31 août 2024 à 07:19 (CEST)

(Promis j'arrête) bon, j'ai amélioré le truc après réflexion (pas d'intérêt le removed_lines) ce qui m'a permis d'ajouter facilement les gentilés. Je te laisse (vraiment) voir s'il y a matière à amélioration et si tu as une idée pour le cas 1. 'toff ^[discut.] 31 août 2024 à 07:31 (CEST)

Pour le 1^er cas que tu as mentionné, il me semble délicat à détecter (autrement qu'en provoquant moult FP) ; en revanche pour le 2^e cas c'est très facile, et tu viens de t'en occuper.

J'ai effectué ces modifs (le diff est tarté, c'est pénible de ne pas pouvoir le prévisualiser…). (suivi de cette modif, pour ne pas matcher inopinément [[Israël]] | Palestine, même si peu probable)

Points principaux :

• J'ai ajouté la détection inverse, qui je suppose aurait aussi son intérêt.
• J'ai élargi/simplifié la détection, tout en n'ajoutant pas de risque de FP, en se basant simplement sur la racine des termes. En prime, c'est en harmonie avec le test au-dessus (qui est également basé sur la racine des termes).

od†n ↗^blah 31 août 2024 à 08:58 (CEST)

Merci 'toff ^[discut.] 31 août 2024 à 09:35 (CEST)

Bien vu pour tes modifs et la détection inverse : 'toff ^[discut.] 1 septembre 2024 à 07:14 (CEST)

Bonjour,

Je m'étais retenu de le dire lors de votre diff sur la page Daniel Conversano, mais je suis assez interpellé par le ton des commentaires de diff qui me semblent être opposés à WP:RSV et WP:COL. Je ne comptais pas relever, supposant que c'est passager, mais les réponses , son commentaire de modification et m'interpellent davantage. Et malheureusement, afin de les retrouver, je tombe sur d'autres commentaires dans les contributions récentes qui me paraissent évitables : , et ... Et un vandalisme :s

Cela peut se lire, il y a de l'exaspération. Malheureusement je ne pense vraiment pas que ce genre de commentaire aient leurs place ici. Bien que ces commentaires ne me soient aucunement adressés, cela me peine de les lire, d'autant plus venant d'un administrateur.

Quelles que soient les raisons, restons serein autant que possible. :)

Bonne journée, Nanoyo (discuter) 1 septembre 2024 à 06:30 (CEST)

Merci pour le message, ne t'en fais pas je suis serein là-dessus (c'est insignifiant au regard des choses qui me préoccupent réellement), ça m'aura simplement apporté une confirmation des biais non assumés qui règnent ici. Et c'est plutôt une bonne chose, parce que maintenant clairement, le site je n'en ai plus rien à cirer. Il y a quelques chantiers techniques, dont certains assez compliqués, que je tiens vraiment à résoudre à long terme, mais mon implication s'arrête là. od†n ↗^blah 1 septembre 2024 à 08:42 (CEST)

Je viens de voir les derniers messages dans ma boîte de notifications, et franchement c'est édifiant, le "deux poids deux mesures" là il est apparu bien comme il faut. Je pense que le wikibreak il va devenir bien long. Ces deux-là on va les encadrer 218247325 et 218250391, voilà voilà. od†n ↗^blah 1 septembre 2024 à 14:24 (CEST)

Salut. Comme tu as l'air de t'y connaître plus que moi j'aimerais savoir s'il y a une préférence à avoir entre plusieurs possibilités de détection équivalentes. Par exemple si tu veux juste contrôler un mot sans tenir compte de la casse uniquement sur l'initiale, il est préférable d'employer quoi ? J'ai pensé à 3 possibilités mais il y en a peut-être d'autres :

• [Ee]xemple
• (E|e)xemple
• irlike "Exemple"

Pour moi, c'est plutôt le premier qu'il faudrait utiliser car il vérifie juste 2 caractères. Le deuxième les vérifie mais le garde en mémoire, le troisième vérifie la casse sur tout le mot. Mais je peux me tromper ? 'toff ^[discut.] 6 septembre 2024 à 07:15 (CEST)

C'est tout à fait ça. od†n ↗^blah 6 septembre 2024 à 07:32 (CEST)

Bonsoir, Quand je clique sur un bouton « Répondre » sur ma PDDu qui contient une catégorie cachée et pas de catégorie non cachée, puis que je commence à écrire dans la boîte de dialogue pour répondre, un [+] est ajouté à chaque caractère que je tape. Escargot (discuter) 22 septembre 2024 à 21:54 (CEST)

Après quelques péripéties (où j'ai notamment causé 3 millions d'erreurs), c'est bon ce problème est corrigé, voir dans le Common.js. Merci pour le signalement, d'autant plus qu'il aura permis à la situation dans T349298 d'avancer un peu. Considérant la multitude d'outils qui déclenchent le hook "wikipage.content", il y aurait encore des choses à mettre au clair dans le Common.js, en particulier concernant les fonctions qui modifient des choses en dehors de l'élément $content. Je me serais bien passé de ces complications, mais bon, elles sont là… od†n ↗^blah 26 septembre 2024 à 03:19 (CEST)

Bonjour Od1n,

j'ai vu que vous aviez de nombreuses fois modifié MediaWiki:Edittools.

Je voulais savoir, existe-il un moyen de personnaliser MediaWiki:Edittools ?

J'aimerais beaucoup pouvoir y insérer :

<ref>{{Lien web|auteur=|url=|titre=|site=|date=}}</ref>

Ça m'éviterait d'aller à chaque fois sur ma PU pour chercher le "code" ci-dessus, lorsque je source une information quand j'édite une page.

Cordialement. — JK^rs's (discuter) le 15 octobre 2024 à 13:49 (CEST)

Bonjour, alors c'est une question très intéressante, parce c'est un besoin qui doit être assez répandu (j'en aurais moi-même justement besoin aussi), et les solutions actuelles ne sont pas des modèles de simplicité…

• La seule solution simple (et encore…) est d'ajouter une entrée dans le petit menu déroulant, avec addSpecialCharset() (voire addSpecialCharsetHTML() pour aussi ajouter autre chose que des liens). Exemples :

addSpecialCharset( 'Personnel', '<ref>{{Lien\\ web|auteur=|url=|titre=|site=|date=}}</ref> <ref\\ name="">{{Lien\\ web|auteur=|url=|titre=|site=|date=}}</ref>' );

addSpecialCharset( 'Personnel', [
	'<ref>{{Lien\\ web|auteur=|url=|titre=|site=|date=}}</ref>',
	'<ref\\ name="">{{Lien\\ web|auteur=|url=|titre=|site=|date=}}</ref>',
].join( ' ' ) );

addSpecialCharsetHTML( 'Personnel', 'Ref&nbsp;: <span>&lt;ref&gt;{{Lien\\ web|auteur=|url=|titre=|site=|date=}}&lt;/ref&gt;</span>&nbsp;• Ref name&nbsp;: <span>&lt;ref\\ name=""&gt;{{Lien\\ web|auteur=|url=|titre=|site=|date=}}&lt;/ref&gt;</span>' );

Notes :

• Pour mettre plusieurs liens, les séparer avec une espace.
• Si le lien comporte une espace, il faut l'escaper en faisant « \\  ».
• Dans le cas du addSpecialCharsetHTML(), il faut aussi escaper les éventuelles balises, avec des entités HTML (voir avec les balises <ref> dans l'exemple au-dessus).
• Le texte du lien correspond à ce qui est inséré. Donc si le lien sert à insérer quelque chose de long, le lien sera hyper long aussi.
• Un avantage avec cette solution est que l'utilisateur n'a aucune condition de chargement ou dépendance à gérer, on s'occupe de tout pour lui (ça se trouve dans le Common.js). Il n'y a rien d'autre à faire que d'ajouter l'appel de fonction dans le Spécial:Ma page/common.js.

• Si l'on utilise la barre d'outils « améliorée » ou la barre d'outils « MonobookToolbarStandard » (voir les captures d'écran ici pour les identifier), on peut ajouter des boutons à l'aide des codes qui se trouvent ici.

Notes :

• Il y a un peu de conditions de chargement et dépendances à ajouter, qui sont heureusement présentes dans les codes indiqués en lien.
• Et il y a aussi à trouver une image pour le bouton…
• En revanche, il n'y a pas la problématique des espaces à escaper avec « \\  ».
• Bien entendu, l'élément est ajouté ailleurs : dans la barre d'outils. Donc la solution convient ou pas, selon les préférences (par exemple, pour ma part j'ai désactivé toutes ces barres d'outils).

• Autrement, il faut se fabriquer un code maison qui ira faire usage de MonobookToolbar.insertTags(). Quelque chose dans ce genre :

if ( [ 'edit', 'submit' ].includes( mw.config.get( 'wgAction' ) ) ) {
	$.when( mw.loader.using( 'ext.gadget.MonobookToolbar' ), $.ready ).then( function () {

		const label = '<ref>{{Lien web|...}}</ref>';
		const contenu = '<ref>{{Lien web|auteur=|url=|titre=|site=|date=}}</ref>';

		const elm = document.createElement( 'a' ); // ou bien aussi 'button'
		elm.textContent = label;
		elm.title = contenu;
		elm.addEventListener( function ( event ) {
			event.preventDefault();
			MonobookToolbar.insertTags( null, contenu );
		} );

		// reste à ajouter l'élément quelque part dans l'interface
	} );
}

Note : dans le MonobookToolbar.insertTags( null, contenu ) j'ai mis le contenu en 2^e paramètre (en skippant le 1^er paramètre avec une valeur falsy). Ainsi, si du texte est sélectionné, la <ref> est ajoutée après (et non avant).

Pour ma part, je me contente finalement des copier-collers, que j'arrive à effectuer relativement vite (par exemple avec tous les snippets dans une autre fenêtre). Si tu es sous Windows, je mentionne à toutes fins utiles le Win + V (voir cet article ou encore celui-ci), qui permet de copier plusieurs choses d'affilée avant de les utiliser, plutôt que de devoir copier une seule chose à la fois.

od†n ↗^blah 15 octobre 2024 à 20:37 (CEST)

Bonjour Od1n,

merci beaucoup pour cette réponse très détaillée.

J'ai mis les deux "codes" dans mon common.js, et effectivement, j'ai désormais

<ref>{{Lien web|auteur=|url=|titre=|site=|date=}}</ref>

dans la barre Monobook, ainsi qu'une nouvelle entrée « Personnel » dans le petit menu déroulant, et ça fonctionne très bien !

Encore merci, bien cordialement . — JK^rs's (discuter) le 16 octobre 2024 à 12:04 (CEST)

Ces codes étaient seulement des suggestions…

• Dans la première section (les "addSpecialCharset"), les trois codes font la même chose, tu as donc des entrées redondantes dans le menu déroulant.
• Dans la seconde section (avec le "MonobookToolbar.insertTags"), il y a le code pour fabriquer l'élément, mais il n'y a pas le code pour ajouter celui-ci dans la page. La section est donc ineffective.
• Enfin, il n'y a aucun code pour ajouter de bouton à une barre d'outils, je ne vois donc pas comment cela aurait pu se produire. Edit : je constate qu'auparavant tu chargeais déjà le script BoutonSourceEnLigne.js, donc je suppose qu'en fait, tu avais déjà le bouton que tu as mentionné.

od†n ↗^blah 16 octobre 2024 à 13:14 (CEST)

Salut. Je suppose que tu t'y connais en programmation Lua des modules ?

Je vois régulièrement (pour ne pas dire quasiment tout le temps) le modèle {{lien web}} inséré avec les paramètres de date date et consulté le inscrits sous la forme "Année-mois-jour" plutôt que "jour-mois-année" (par exemple). Je suppose que ça vient du modèle {{Lien web}} lui-même et donc de son module (qui serait à priori Module:Biblio/Lien web ? ) mais autant je me débrouille dans les modèles, autant le Lua m'est étranger. Il n'y a pas moyen de forcer la date sous la forme jour-mois-année qui est utilisée en français ? 'toff ^[discut.] 22 mars 2025 à 11:47 (CET)

Salut, de ce que je vois, le TemplateData préremplit avec le format textuel « 1 janvier 2015 », donc je suppose que ce sont vraiment les rédacteurs qui choisissent le format ISO. Et justement, je déconseille très fortement l'infect format 12/01/04, source d'un nombre pas croyable de confusions (il m'est même déjà arrivé de ne vraiment pas pouvoir déterminer ce qui est le jour et ce qui est le mois, même après moult recherches). Alors que nous avons le format ISO qui est absolument génial : aucune confusion possible, parfaitement triable même en cas de dates partielles. Et pour ceux qui ne seraient pas encore trop à leur aise avec ce format, le format textuel est aussi une solution très convenable. Mais par pitié, pas l'infect 12/01/04. Voir aussi : xkcd 1179. od†n ↗^blah 23 mars 2025 à 07:51 (CET)

Marrant ton "voir aussi" avec l'année avant le mois Je me demandais si le format n'était pas lié aux préférences utilisateur mais j'ai testé et ça n'est pas ça. Bon bah tant pis, ça continuera à "m'agacer" (moi aussi j'ai parfois du mal à trouver le jour dans tout ça) 'toff ^[discut.] 23 mars 2025 à 10:14 (CET)

Je t'encourage vivement à te mettre à ce format, une fois l'habitude prise, tu ne voudras plus revenir en arrière. Pour ma part je l'utilise du matin au soir dans moult situations, et il ne me viendrait pas à l'esprit d'utiliser autre chose. Dans le cas des modèles de références, une autre très bonne solution est la forme textuelle, qui elle aussi ne présente pas de problème de confusion. od†n ↗^blah 23 mars 2025 à 10:23 (CET)

Bonjour Od1n

En 2012, tu avais modifié la doc du modèle:Code pour ajouter à la description du premier paramètre « Le wikicode n’est pas interprété, en revanche l’expansion des modèles est effectuée. Pour ne pas effectuer l’expansion des modèles, les encadrer avec des balises <nowiki> … </nowiki> » .

Que veux-tu dire par « Le wikicode n’est pas interprété » ?

Parce qu'il me semble que le wikicode fonctionne, c'est juste la police qui change pour une à chasse fixe :

• {{code|[[Truc|machin]]}} donne : [[Truc|machin]]

Aussi, il me semble qu'il y a plus simple que d'utiliser des balises <nowiki>, mettre wikitext dans le paramètre « langage » fait la même chose à ce que je peux voir :

• {{code|<nowiki>[[Truc|machin]]}}</nowiki> donne : '"`UNIQ--nowiki-00000050-QINU`"'
• {{code|[[Truc|machin]]|wikitext}} donne : [[Truc|machin]]

Şÿℵדαχ₮ɘɼɾ๏ʁ 3 avril 2025 à 18:43 (CEST)

Bonjour, en fait le comportement du modèle a été modifié depuis lors : 212001382. Maintenant, lorsque le modèle est utilisé sans paramètre "lang / 2", il produit un <code> au lieu d'un <syntaxhighlight>, et du coup le wikicode (exemple : ''italique'') est interprété, alors qu'il ne l'était pas auparavant. Et dans tous les cas, le remplacement des modèles est effectué.

• {{code|''{{trim|test}}''|wiki}} donne actuellement ''test''
• {{code|''{{trim|test}}''}} donne actuellement test

od†n ↗^blah 3 avril 2025 à 22:37 (CEST)

À noter que la valeur de langue "wiki" n'est pas reconnue (donc pas de coloration syntaxique, et catégorisation en erreur de la page), la valeur correcte est "wikitext" (ou "mediawiki"). J'ai modifié ton message pour que la présente page ne soit plus catégorisée en erreur. Refs mw:Extension:SyntaxHighlight#Supported languages et Pygments - Languages.

Si l'on souhaite ne pas avoir de coloration syntaxique, la valeur à utiliser est "text" (à propos, ce point devrait peut-être être documenté davantage). Refs mw:Extension:SyntaxHighlight#Syntax highlighting error category.

od†n ↗^blah 3 avril 2025 à 22:58 (CEST)

 SyntaxTerror : très bonne nouvelle, j'ai trouvé une solution pour avoir le beurre et l'argent du beurre (contenu du paramètre transmis mais non interprété, et sans utilisation du syntaxhighlight coûteux) : 224590535. od†n ↗^blah 6 avril 2025 à 19:49 (CEST)

Notes complémentaires :

• Je trouve qu'il est un peu surprenant / déroutant qu'avec un code tel que {{code|[[Truc|machin]]}} le wikicode soit retourné littéralement au lieu d'être interprété. Généralement, dans pratiquement tous les modèles, le wikicode serait interprété. Mais bon, c'était déjà comme ça auparavant, et on peut considérer qu'il s'agit ici d'un cas particulier.
• J'ai suggéré le système sur enwiki : en:Template talk:Code#Edit request 6 April 2025 - Performance improvement. Quelqu'un d'autre avait déjà eu l'idée : 1211956864.
• Il demeure une différence de comportement, avec les entités HTML, voir le 3^e tableau dans la discussion précédente. En attente de voir si des commentaires sont apportés sur ce point.

od†n ↗^blah 7 avril 2025 à 03:35 (CEST)

Bonjour Od1n.
Je n'ai pas pour habitude d'intervenir dans ce type de discussion mais j'avoue avoir été surpris (euphémisme) par ce commentaire de diff dont le ton et le contenu surprennent, surtout à coté du texte de la diff qui lui reste très factuel. Tu sais qu'il t'a déjà été reproché des dérapages qui, à force d'être répétés, peuvent être lourds de conséquences pour toi : dans certains cas, il serait bon que tu tournes sept fois tes doigts au-dessus du clavier avant d'appuyer sur les touches.
Qu'en penses-tu ? Cordialement, — Arcyon ^{[Causons z'en]} 28 juillet 2025 à 08:44 (CEST)

Bonjour. J'avoue me questionner également sur ces propos, alors que j'ai encore en tête cette sortie de juin 2025 (dernière en date dont j'ai connaissance)... Il me semble également important de veiller à un ton plus posé et constructif, surtout dans les espaces publics du projet. Od1n, pourrais-tu nous expliquer ce qu'il s'est passé ? Cdlt, — Antimuonium ^discuter 31 juillet 2025 à 20:28 (CEST)

Merci pour vos messages.

Je vais faire simple : cela fait un bon moment que je ne suis plus en phase avec Wikipédia, ni sur le plan éditorial, ni sur l'évolution technique du logiciel. Et cet écart, déjà beaucoup trop grand, se creuse encore avec le temps.

Si j'ai continué à contribuer, c'est parce que je m'en sentais obligé : trop de boîtes de Pandore ouvertes, trop d'engagement qui s'est renforcé au fil des années. Mais ce n'était plus par conviction, seulement par inertie.

Je réalise désormais que c'est peine perdue. Le courant opposé est trop fort, et je n'ai ni l'envie ni l'énergie de continuer à ramer dans le vide. J'ai pris mes distances. Il m'arrive encore de contribuer, épisodiquement, mais sans illusions.

od†n ↗^blah 12 septembre 2025 à 04:27 (CEST)

Salut Od1n,

Pour ma part je continue de trouver que tes contributions sont de grande qualité quand bien même elles ne viennent plus « par conviction ». Je te souhaite de trouver ton équilibre et de ne pas mettre bêtement en danger ton statut (de contributeur respecté ou d'admin) à cause de gros mots sortis dans un moment de relâchement.

Je ne sais pas exactement ce que tu comptes parmi le courant opposé mais à la fois je comprends le sentiment, et en même temps je pense qu'en prenant du recul tu peux réaliser que quand même, il y a beaucoup de choses réussies sur ce projet et continuer à s'y investir est faire œuvre utile. Amicalement, l'Escogriffe (✉) 23 septembre 2025 à 17:59 (CEST)

Parce que j'ai vu tes commentaires dans ton todo : phab:T265566.

Néanmoins, il y a bien un problème avec l'utilisation de Minerva comme habillage sur bureau. Escargot (discuter) 1 décembre 2025 à 15:52 (CET)

Merci pour l'info. Là franchement, voilà le point où ça en est arrivé…

Concernant Minerva sur desktop, tu peux oublier complètement. Je suis justement retombé récemment sur un commit Gerrit du dév que je ne peux plus blairer, où il a bien écrit noir sur blanc que Minerva sur desktop n'est plus un cas supporté.

Mais malheureusement, même en oubliant Minerva sur desktop, la situation est devenue complètement ingérable.

Ça aurait quand même pas été compliqué putain :

• Common.css/js : comme le nom l'indique, toujours chargé (mais comme pour des raisons historiques il n'était chargé que sur desktop, peut-être utiliser un autre nom)
• + Desktop/Mobile.css/js : à limiter le plus possible, code spécifique/ajustements/hacks, selon que ce cancer de MobileFrontend est chargé ou non
• + Vector/Minerva.css/js : comme le nom l'indique, skin utilisée == fichier correspondant chargé

Et les CSS chargés en synchrone (le chargement asynchrone du mobile.css n'ayant été justifié par rien d'autre qu'un message avec un motif bancal, une histoire d'africains sur des smartphones en 2G, faisant ainsi passer un asset de genre 10 ko (et mis en cache navigateur…) vers un chargement via JavaScript et infliger trois secondes de FOUC à tout le monde).

od†n ↗^blah 1 décembre 2025 à 16:49 (CET)

De ce que j'en comprends, l'actuel chargement de Common.css/js dans le mode "useformat=mobile" serait en fait par erreur. Krinkle dit que c'était déjà le cas avec l'ancien domaine mobile, pour ma part je n'ai pas souvenir d'avoir rencontré le problème auparavant. J'ai une hypothèse rapide, c'est qu'en raison des domaines différents, les caches étaient distincts ; ce qui serait appuyé par le fait que j'ai besoin de faire "Shift + F5" (purge cache client) pour complètement effectuer les bascules mode desktop/mobile.

En tout cas ça me parait vraiment tordu. Pour moi, "useformat=mobile" ça doit faire comme sur mobile, point. Pour le index.php comme pour les assets ResourceLoader. Donc d'une manière consistante, activation du cancer de MobileFrontend et utilisation de la "seule / par défaut" skin mobile, Minerva (sauf si aussi ajout d'un paramètre "useskin=...").

od†n ↗^blah 1 décembre 2025 à 18:40 (CET)

Ça fait plus de deux semaines que j'ai posté un message avec la description du problème, et effectivement ils s'en battent les couilles. Tant que ce n'est pas résolu, hors de question de faire le moindre développement/test pour la version mobile. Faudrait sans cesse cliquer sur le lien de bascule en bas de page, qui impacte tous les onglets ouverts, et sans oublier de faire des "shift + F5" pour charger les bons assets. Donc extrêmement laborieux et beaucoup trop de confusions possibles. od†n ↗^blah 16 décembre 2025 à 10:09 (CET)

Bonjour Od1n,

Merci pour vos commentaires que j'avais commencé à lire hier soir.

Mais j'avoue que je suis surpris de leurs disparitions aujourd'hui. Est-il possible de comprendre pourquoi vous les avez supprimés ?

--Dom (discuter) 1 avril 2026 à 07:20 (CEST)

Bonjour, j’ai supprimé mes messages parce que je me suis rendu compte que je m’étais lancé dans un monologue qui m'avait déjà fait perdre beaucoup de temps et d'énergie. Je dois rester concentré sur ce qui compte pour moi. od†n ↗^blah 1 avril 2026 à 07:55 (CEST)

Je viens de restaurer mes messages : 236897374. Comme j'ai indiqué dans le résumé de modif, c'est principalement pour couper court à l'ajout de cette classification à la con. Et pourquoi on n'irait pas ajouter un de ces put– de « compteur d'émissions CO₂ » à la con (avec des chiffres tout droit sortis du trou du c–) tant que nous y sommes ? od†n ↗^blah 9 juin 2026 à 01:54 (CEST)

Note pour éviter toute méprise, parce que ça arrive vite sur internet : il n'y a absolument rien contre vous dans ce message, c'est un coup de gueule général. Ça fait des années que je vois le web partir en vrille, et ça fait du bien d'extérioriser de temps en temps. od†n ↗^blah 9 juin 2026 à 05:56 (CEST)

J'avais remplacé un certain nombre d'utilisations de window.location par location en accord avec mw:Manual:Coding conventions/JavaScript#Exporting. J'ai vu que tu faisais la transformation inverse. J'avoue ne pas maîtriser le sujet, quel est ton avis sur les conventions MediaWiki ? Escargot (discuter) 8 juin 2026 à 22:47 (CEST)

Merci pour le lien. J'en pense que leur recommandation est de la mer—, pardon, un antipattern, du moins dans le cas précis de location. C'est d'ailleurs une question sur laquelle j'avais déjà longuement réfléchi avant de faire cette modification (que j'ai déjà effectuée ailleurs auparavant) : comme je l'ai indiqué dans mon résumé de modif, location doit vraiment être considéré comme une propriété de window, et non comme un global autonome — les réponses que j'avais trouvées sur Stack Overflow à ce sujet allaient d'ailleurs dans le même sens.

J'indique aussi ces éléments de réponse IA : « La recommandation est raisonnable pour la plupart des globaux — personne n'écrit const document = …, donc utiliser document seul est sans ambiguïté. Mais location est un nom de variable courant, susceptible d'être redéfini localement (paramètre de fonction, variable de module…). Dans ce cas, window.location lève l'ambiguïté de façon explicite, là où location seul peut désigner n'importe quelle variable du scope. L'analyse statique, censée bénéficier de la convention, y perd au change. »

J'essaierai de ne plus toucher à ça à l'avenir — je n'ai vraiment pas envie de passer encore du temps là-dessus.

od†n ↗^blah 8 juin 2026 à 23:16 (CEST)

J'ai corrigé ce point précis et apporté des améliorations à la documentation, voir notamment 8422803 et 8422908. J'espère que cela sera maintenu. od†n ↗^blah 9 juin 2026 à 01:11 (CEST)

Et comme je l'avais mentionné, voir ces réponses sur Stack Overflow : window.location versus just location, qui vont clairement dans le sens de window.location. od†n ↗^blah 9 juin 2026 à 01:26 (CEST)

J'ai effectué plusieurs relectures de mon texte révisé sur mediawiki.org, et ça me semble vraiment bon en l'état. Certains éléments sont un peu à cheval sur les deux mondes (propriété de window, globale ?) et il faut parfois trancher de manière empirique, mais il y a quand même moyen de parvenir à une classification robuste :

1. On utilise le global nu pour les classes/constructeurs (URL, IntersectionObserver), les fonctions d'action (fetch, setTimeout) et les objets pivots du DOM/Engine (document, navigator, console, mw, $).
2. On utilise le préfixe window. pour toutes les propriétés qui décrivent l'état, l'environnement, les dimensions ou l'identité de la fenêtre courante (location, history, name, status, innerWidth), car leurs noms sont fréquemment en conflit avec des variables locales.

Mon approche de la situation est plutôt conceptuelle, là où les IA mettent vraiment l'accent sur les problèmes de name masking ; elles considèrent beaucoup le cas de location utilisé en nom de variable locale, et il y a aussi le cas fameux de window.name qui cause un name dans l'espace global… (et juste pour rappel : tous les id d'éléments (et aussi les name d'éléments de formulaires) se retrouvent dans l'espace global. C'est horrible.)

Il ne te reste plus qu'à refaire tes remplacements window.location ⇄ location dans l'autre sens. 😂😭

od†n ↗^blah 10 juin 2026 à 00:59 (CEST)

Je viens d'effectuer tous les remplacements, y compris pour les utilisations de location seule dont je n'étais pas responsable. Je n'ai pas touché aux document.location. Escargot (discuter) 10 juin 2026 à 09:00 (CEST)

Concernant document.location : à terme il serait cohérent de les remplacer aussi par window.location. document.location est un alias historique maintenu uniquement pour la compatibilité ascendante — il était en lecture seule dans certaines anciennes spécifications, ce qui avait créé de la confusion, et le HTML living standard considère window.location comme la référence canonique. Conceptuellement, l'URL de la page est une propriété de la fenêtre, pas du document (document.location est en ce sens une leaky abstraction). Cela dit, ce n'est pas vraiment prioritaire — à traiter tranquillement au fil des passages dans les fichiers concernés. od†n ↗^blah 10 juin 2026 à 09:41 (CEST)

Bonjour od†n !

Si tu as le temps et l'envie, aurais-tu la possibilité de relire rapidement un petit script Utilisateur:Framawiki/js/BibliothèqueWikipedia.js permettant d'ajouter un lien [bib] à côté des références prises en charge par la Bibliothèque Wikipédia? Je l'ai basé sur le modèle de MediaWiki:Gadget-ArchiveLinks.js.

J'aimerais donc le proposer comme gadget prochainement, puis dans un second temps proposer à ce qu'il soit activé par défaut pour les utilisateurs connectés, au vu de la forte demande (Wikipédia:Le Jardin#Valorisation de la bibliothèque Wikipédia). C'est donc pour cela que je serais ravi d'obtenir ton avis sur l'architecture du script Merci d'avance et bonne journée, -Framawiki ^✉ 15 juin 2026 à 09:03 (CEST)

Je viens de me pencher sur le code : j'ai fini par corriger pas mal de choses. Deux points :

• À l'avenir, merci de ne pas m'adresser ce genre de demande directe.
  • Le problème est que je ne peux pas m'empêcher de traiter l'affaire (soit je la traite, soit elle reste en tâche de fond dans ma tête), ce qui me consomme énormément de temps et d'énergie.
  • Il y a pourtant un avertissement en haut de ma page de discussion ; si ce genre de situation se reproduit, je risque d'avoir à rejeter ce type de demande de façon radicale, avant que cela me rentre dans l'esprit, et j'aimerais ne pas avoir à en arriver là.
  • Il y a une page prévue exprès pour ce genre de demande : Discussion Projet:Scripts et gadgets (et on peut même éventuellement m'y pinguer) ; c'est gagnant-gagnant : davantage de visibilité pour la demande, et ça m'enlève un poids considérable.
• De toute façon, je suis franchement très réticent à l'ajout de ce script JavaScript, surtout activé pour tous les utilisateurs, car le coût d'exécution est loin d'être négligeable. Une gestion côté serveur, au niveau des modules Lua, serait largement préférable.

od†n ↗^blah 16 juin 2026 à 06:45 (CEST)

• Je trouve le alert() assez gênant, il serait avantageusement remplacé par un wikilien ordinaire, vers une page d'explications.
  • Une telle page permettrait de fournir davantage d'informations, des liens cliquables…
  • Aussi, cela aiderait pour l'approche server-side Lua (qui ne permettrait pas d'ajouter des onclick).
• Je continue de pencher nettement pour une approche server-side Lua.
  • En raison de contraintes techniques, les liens seraient toujours générés, càd même pour les contributeurs avec moins de 500 edits.
    • Pas idéal que de tels liens masqués soient présents, mais c'est la moins pire solution que je vois. Le markup de ces liens serait réduit au minimum, càd juste le lien et une classe HTML, aucun style inline.
  • Les liens seraient masqués au départ, via CSS, et il y aurait seulement un JavaScript léger, qui ajouterait une classe au <body> pour les les contributeurs avec plus de 500 edits. Toujours via CSS, la présence de cette classe irait rendre les liens visibles.
    • Mieux de faire le "FOUC" dans ce sens (liens masqués au départ, puis qui apparaissent si plus de 500 edits) que dans l'autre sens (liens affichés au départ, puis qui disparaissent si moins de 500 edits).
  • En Lua, il y aurait moyen de faire la détection "URL appartient à un domaine de la liste" de façon ultra-performante, sans utiliser la librairie URI.
  • La seule contrainte que je vois, c'est qu'il faudrait copier meta:The Wikipedia Library/partners.json vers un module de données Lua local (mw.loadData), et surtout le maintenir à jour.
    • Pour rappel, mw.loadJsonData est significativement plus coûteux (il incrémente même le "expensive parser function count").
    • On pourrait même développer un petit code JavaScript, permettant à qui le veut de mettre à jour les infos du module de données Lua sans attendre le prochain passage du bot.

od†n ↗^blah 16 juin 2026 à 18:13 (CEST)

Je m'excuse de ne pas avoir lu le message d'entête, c'est une erreur de ma part qui a effectivement du te prendre une partie importante de ta journée. Cela aurait pu t'être évité si j'aurais pris quelques secondes de plus pour lire la page avant de poster. J'ai bien noté de passer par les pages des projets pour mes demandes futures.

Un grand merci pour cette relecture très détaillée et pour les améliorations de stabilité que tu as apporté! Le script semble bien plus robuste et lisible pour tenir dans le temps, grâce à toi!

Effectivement, l'approche Lua+CSS était l'idée initiale.

J'ai finalement préféré implémenter cette première version côté client, ce qui permet surtout de prendre en charge les liens quelque-soit leur position. Un nombre non négligeable de refs ne sont pas mises en forme dans un modèle. Les liens peuvent également être dans une infinité de modèles variés: je viens de découvrir à l'instant sur l'article Hyperbraille que {{Admissibilité à vérifier}} contient par défaut un lien vers le site Cairn.info, pour lequel le script permet en un clic de s'y authentifier via la bibliothèque, et de trouver des références. J'ai également découvert que {{Bases}} contient plusieurs liens pris en charge par la bib (ex Léonard_de_Vinci#Liens_externes). Ainsi, il faudrait modifier un grand nombre de modèles pour bénéficier pleinement de la bibliothèque, et ça ne fonctionnerait jamais pas sur les liens bruts hors modèles. De même, la vérification du contenu des refs via les liens de la bib est très utile pour les patrouilleurs, qui relisent souvent des articles non mis en forme.

L'approche server-side aurait par contre l'avantage de pouvoir montrer les liens à tout le monde, sans prendre des perfs aux clients, ce qui a été demandé par plusieurs contributeurs: "ça pourrait même favoriser le recrutement de gens découvrant un intérêt matériel à une contribution régulière". Peut-être pour une prochaine version?

Pour éviter d'injecter le script aux contributeurs n'y ayant pas accès, je pensais l'activer uniquement pour les autopatrolled (500+ modifs, même critère que permettant d'accéder à la bibliothèque) en profitant au maximum des options de Extension:Gadgets :
BibliothèqueWikipédia [ResourceLoader|dependencies=mediawiki.ForeignApi,mediawiki.storage|actions=view|namespaces=0,2|rights=autopatrol|default] | BibliothèqueWikipédia.js

Concernant le alert(), j'ai initialement commencé par relire la doc OOUI, qui indique être dépréciée et redirige vers Codex, et ce dernier m'a vite donné envie de fermer la page Mais je finirais par regarder l'amélioration de cette boite de dialogue, pour prendre en compte les quelques cas particuliers supplémentaires d'accès permis par la bibliothèque qui ne sont pas encore gérés par le script.

Est-ce que le problème de performance te semble finalement acceptable pour une activation par défaut client-side, en restreignant les utilisateurs pour lequel le script est chargé? J'imagine qu'il n'y a que ~2000 contributeurs automatrolled actifs actuellement.

La prochaine étape pourrait être de demander à la communauté pour une éventuelle activation par défaut pour ces utilisateurs, en demandant si les avantages apportés contrebalancent le risque de nécessiter davantage de ressources. -Framawiki ^✉ 17 juin 2026 à 01:16 (CEST)

Bonjour @Framawiki,

On peut être autopatrolled sans avoir accès à la bibliothèque Wikipédia et inversement.

Les critères pour l'accès à la bibliothèque sont (cf https://wikipedialibrary.wmflabs.org/about/):

• compte ancien d'au moins 6 mois (pour autopatrolled, c'est 3 mois sur le wiki courant)
• au moins 500 contributions sur les projets Wikimédia (pour autopatrolled, c'est le même nombre mais sur le wiki courant)
• au moins 10 modifications aux projets Wikimédia au cours du dernier mois (pas de telle restriction pour les autopatrolled, et concerne en réalité un certain nombre d'entre eux)
• ne pas être bloqué en écriture sur un projet de Wikimédia

Des contributeurs peuvent avoir gagné l'accès à la bibliothèque grâce à leur contributions sur d'autres projets sans être autopatrolled ici, auquel cas le gadget devrait quand même leur être accessible. A l'inverse, les utilisateurs contribuant uniquement ici sont souvent autopatrolled trois mois avant de gagner l'accès à la bibliothèque et auraient, si le gadget est activé par défaut, des liens qui ne deviendraient utilisables que trois mois plus tard. L'optimisation du ResourceLoader ne permettrait pas de cibler exactement les personnes concernées.

Le bot a supprimé 30k octets de la liste. Est-ce normal ? Escargot (discuter) 17 juin 2026 à 01:38 (CEST)

Bonjour @Escargot, ce sont effectivement des points intéressants.

Effectivement, j'ai déjà eu d'autres demandes de ne pas restreindre à 500 modifs sur frwiki, notamment de @Malik2Mars. On peut imaginer activer par défaut le script pour les autopatrolled sur frwiki (via la configuration de MediaWiki:Gadgets-definition), et j'imagine que les utilisateurs ayant atteint ce seuil de contribs sur les autres wikis pourront activer manuellement ce gadget dans leur préférences si ils le souhaitent? J'ai retiré la limite qui était jusqu'à présent dans le code, en ce sens .

Il reste le cas des utilisateurs ayant entre 3 et 6 mois de contributions, mais ayant déjà 500 modifs, ainsi que les utilisateurs satisfaisant tous les critères mais n'ayant pas contribué à 10 modifs dans le mois. Si on effectue une demande à la communauté avant d'activer le gadget par défaut, ce serra un point à souligner.

Concernant le bot, j'ai modifié à posteriori son script pour retirer les sous-domaines lorsqu'un domaine parent est déjà présent, pour diminuer la taille de la liste et in-fine le stockage en cache sur les navigateurs des contributeurs. -Framawiki ^✉ 17 juin 2026 à 11:08 (CEST)

J'ai posté un message sur Wikipédia:Le Jardin#Valorisation de la bibliothèque Wikipédia. En résumé : l'approche JavaScript centralisée est effectivement préférable à des rajouts éparpillés dans les modules Lua ; en revanche, je suis très fortement opposé à une activation par défaut, l'utilité étant faible et le coût d'exécution très important — ratio extrêmement défavorable. J'ai également évoqué une autre piste, qui serait à mon sens bien plus efficace : publier régulièrement des messages au Bistro, avec des exemples concrets illustrant l'utilité de la Bibliothèque. od†n ↗^blah 24 juin 2026 à 12:27 (CEST)

Concernant les diverses conditions pour l'accès (indiquées sur https://wikipedialibrary.wmflabs.org/about/ et rappelées par Escargot plus haut), et pour faire suite à 237117989. On ne peut récupérer qu'une partie de ces infos : par exemple pour le global edit count, essayer déjà mw.config.get('wgUserEditCount'), et si le nombre local est insuffisant, faire une requête API query pour "globaluserinfo > editcount". Mais apparemment, on ne peut pas obtenir pour l'ensemble des wikis les 10 edits les plus récents, ni les blocages. Je crains que l'implémentation exhaustive des diverses conditions soit très complexe. Alors que si le gadget est opt-in, on peut simplement omettre ces vérifications. od†n ↗^blah 26 juin 2026 à 18:33 (CEST)

Effectivement, c'est une piste intéressante.

Dans le cas où on activerai éventuellement le gadget par défaut, l'activer uniquement pour les autopatrolled (500+ modifs) via la config MediaWiki:Gadgets-definition me semble suffisant, car les cas supplémentaires ne me semble pas poser problème:

• les utilisateurs autopatrolled mais avec moins de 6 mois d'ancienneté: ils peuvent découvrir la bibliothèque via la mis en valeur des références compatibles, au travers des pages qu'ils consultent pendant les semaines où ils n'ont pas encore l'ancienneté nécessaire. Le message sur https://wikipedialibrary.wmflabs.org leur indique clairement qu'ils doivent attendre quelque temps pour y avoir accès.
• les utilisateurs bloqués: il ne semble pas nécessaire de passer de l'énergie à traiter ces cas.
• les utilisateurs ayant moins de 10 modifs sur le mois en cours: si ils veulent consulter la bibliothèque, ils peuvent effectuer quelques améliorations en une demie-heure, et récupérer leur accès.
• les utilisateurs ayant effectué 500 modifs sur d’autres wikis et qui ne sont pas encore autopatrolled sur frwiki: ils peuvent forcer l'activation dans les préférences. Effectuer un call api globaluserinfo pour tous les utilisateurs non autopatrolled me semble poser un coup de performance trop important, même avec mise en cache.

Merci pour les améliorations du script que tu as effectué!

-Framawiki ^✉ 27 juin 2026 à 14:29 (CEST)

Une considération technique que je vais quand même mentionner :

• L'ordre de chargement/exécution avec ArchiveLinks.js n'est pas déterministe ; autrement dit, les deux gadgets effectuent chacun leur passe d'ajout de liens simplement dans l'ordre où ils ont été chargés. Je présume qu'en pratique, sur une période donnée, les deux gadgets sont chargés dans le même ordre, mais rien ne le garantit ; et les liens pourraient se retrouver un beau jour ajoutés dans l'autre ordre. Rien de catastrophique, mais c'est le genre de détail qu'il pourrait être bon de gérer. Cela pourrait se résoudre avec des add/fire de hooks, des promises…
  • Rappel / note to self : attention à la compatibilité avec l'aperçu rapide (en particulier, attention à ne pas "multiplier les hooks entre eux").

Autre point ; mais à la réflexion, piste qui complique surtout les choses, pour en fait peu d'intérêt, voire contre-productif :

• On pourrait aussi imaginer un "helper" qui serait utilisé par les deux gadgets, pour récupérer les liens externes (juste pour info, refs HeadingsTweaker.js pour les titres de sections ; noter que celui-ci traite directement les éléments avec un callback, au lieu de retourner une liste qui serait à itérer à nouveau). On pourrait aller plus loin et imaginer faire que le helper garde en mémoire les liens externes, afin de ne pas les récupérer plusieurs fois ; mais avec le risque d'effectuer de l'optimisation complexe qui en fait n'apporte quasiment rien, voire contre-productive si mal réalisée (e.g. si davantage d'itérations).
  • À propos, pendant que j'effectuais quelques tests avec Chrome, j'ai découvert par hasard, en faisant plusieurs récupérations des élements ".external" d'affilée, que les récupérations après la première étaient souvent (mais pas toujours) plus rapides. Ça indique que Chrome utilise une sorte de cache en interne, mais j'en ignore la durée (apparemment très courte), les conditions, etc. bref, on ne peut pas vraiment compter dessus.
  • À la réflexion, comme j'ai écrit au début, cette idée de factorisation n'est peut-être pas une bonne piste.

od†n ↗^blah 9 juillet 2026 à 07:10 (CEST)

Rappel to self : penser aussi à éventuellement court-circuiter leur putain de connerie d'exécution du hook à chaque putain d'aperçu de message (càd à chaque input clavier) dans le DiscussionTools ; refs Common.js. Oui, l'exécution de hook fait sens dans la mesure où c'est du "contenu parsé" ; par contre non, ça n'a pas à être considéré au même niveau, il faudrait disposer d'un hook "large" (l'actuel, qui capture vraiment tout, y compris les petites prévisualisations ultrafréquentes) et d'un autre plus restreint (qui capture seulement les "résultats finaux").

Noter quand même que ces déclenchements de hooks ne sont pas extrêmement impactants (les messages ne sont généralement pas immensément longs, et merci le code de sélection des liens externes bien optimisé), et de toute façon ces prévisualisations "en direct" effectuent des requêtes réseau pour obtenir le contenu parsé, ce qui est évidemment considérablement plus coûteux ; la désactivation dans le Common.js sert davantage a éviter divers bugs / effets de bord. Il y a quand même le "mw.storage.getObject" exécuté à chaque fois qui me gêne un peu, mais en fait lui aussi est très performant (et bien entendu, c'est de la lecture seule).

od†n ↗^blah 10 juillet 2026 à 08:07 (CEST)