Discussion utilisateur:Od1n

Accueil

Favoris

Todo

Honneurs

Sous-pages

Discussion

Archives

• 2006 – 2009
• 2010
• 2011 (1er semestre)
• 2011 (2nd semestre)
• 2012
• 2013
• 2014
• 2015
• 2016
• 2017
• 2018
• 2019
• 2020
• 2021
• 2022
• 2023
• Discussions avec Micthev

3 colonnes

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)

FN

Salut Si vous voulez donner un avis, vous pouvez le donner ici et en demande de renommage. --Panam (discuter) 3 septembre 2018 à 23:35 (CEST)

Bonsoir, merci pour l'info. C'était simplement un petit avis à chaud, sans avoir étudié les discussions passées, et donc à considérer comme simple propos à ne pas forcément inclure dans la réflexion générale. od†n ↗^blah 4 septembre 2018 à 00:09 (CEST)

Modèle:Infobox Logiciel

Bonjour, apparemment le bug d'affichage du modèle que j'avais fixé puis que tu as rétabli ne survient que sur Firefox, quelles que soient les tailles d'écran (ex : Kubernetes). Sur Chromium c'est potable en revanche. JackPotte ($♠) 8 septembre 2018 à 19:41 (CEST)

Bonjour, c'est quoi le bug ? Je ne vois rien ici… od†n ↗^blah 8 septembre 2018 à 19:58 (CEST)

Je poste une image : c'est le rendu que j'ai sur mes deux PC 17 pouces, Ubuntu 18.04, Firefox 62, habillage Vector, pas de gadget ni d'erreur en console, zoom 100 %. Mais le rendu est OK sur leur Chrome ou FF Android. JackPotte ($♠) 15 septembre 2018 à 13:58 (CEST)

Je vois je vois, la ligne était tout simplement trop longue, et a priori pas possibilité de faire une césure propre. Du coup j'ai fait ceci, ça devrait résoudre ton problème, et en prime ça me donne un motif pour faire sauter ces « (s) » peut-être techniquement corrects mais ma foi fort laids. od†n ↗^blah 15 septembre 2018 à 23:41 (CEST)

C'est résolu pour les parenthèses, mais le "-s" du paramètre "environnements" chevauche toujours la première lettre de sa valeur. C'est pour cela que je vote pour une uniformisation vers un seul paramètre "environnement". D'ailleurs les autres paramètres n'existent pas au singulier ou pluriel. JackPotte ($♠) 16 septembre 2018 à 09:41 (CEST)

Ça nous emmènerait assez loin comme discussion, mais j'aurais une solution encore meilleure, qui serait de rendre ces infoboxes responsives :

• sur écran large, augmenter la largeur de l'infobox pour diminuer la quantité de retours à la ligne et augmenter son confort de lecture ;
• sur écran très étroit, carrément passer en largeur 100% (comme la version mobile), quand même mieux que d'avoir le résumé introductif sur une largeur ridicule… (edit : j'ai testé rapidement, et d'avoir à scroller pour afficher le résumé intro c'est vraiment gênant, donc il faut vraiment que l'écran soit très étroit pour que cela soit moins pire que d'afficher le résumé intro dans une gouttière excessivement étroite)

Mais bon, le changement est d'assez grande envergure et je n'ai pas vraiment le temps de m'y investir. À garder sous le coude. od†n ↗^blah 16 septembre 2018 à 10:14 (CEST)

Autre note tant que j'y pense, attention aussi à la skin Timeless, qui ne met pas le contenu en pleine largeur d'écran, et qui en prime ajoute/retire des colonnes latérales en fonction de la largeur d'écran. od†n ↗^blah 18 septembre 2018 à 03:12 (CEST)

Aide sur 2 modules

Bonjour Od1n. J'ai pas osé te déranger jusque-là, mais je suis bloqué sur un module. Zebulon84 est inactif en ce moment... Je viens de résumer la problématique à Tomtom, mais je ne sais pas s'il va répondre. J'ai posé la question au projet scribunto, mais je n'ai pas eu de réponse.

Sujet résumé ici : https://fr.wikipedia.org/wiki/Sujet:Ul7hx8sqk2iih6ly

Cordialement -- Archimëa [Toc 2 Mi] 22 septembre 2018 à 10:31 (CEST)

Salut, j'ai déjà repéré une première cause, la disparité entre Module:Date et en:Module:Date. Ce dernier implémente une fonction _Date, qui est importée par les modules jeux vidéo, mais qui n'est pas présente sur ce wiki. od†n ↗^blah 22 septembre 2018 à 11:22 (CEST)

Concernant les {{Langue|en|[[GameRankings]]}}, ils ne sont pas "obligatoires" car il s'agit de noms propres, et ne serviraient que pour la prononciation par les lecteurs d'écran. Je pense qu'il est préférable de ne pas les ajouter, afin de réduire les différences entre les modules frwiki et enwiki, car cela complique la maintenabilité du code. od†n ↗^blah 22 septembre 2018 à 13:29 (CEST)

Bonsoir Od1n. J'avais pas vu ta réponse, je m'y attendais pas si rapidement.

OK/ah bon! pour _Date. Pour traduire ce seriesQid en QidSérie ou Qid_Série, peut importe, que puis-je faire ? j'ai fait pas mal de test, sans y arriver (si tu regardes dans l'histo, tu vas bien rigoler surement).

Pour les modèles Langue. hmmm, la pratique sur les noms d'entreprise ou d’œuvres est de le mettre (de ce que je vois et de ce que l'on m'a imposé) -- enfin tu as raison sur les personnes. Mais si cela demande trop de taf, je comprend, je fais une croix dessus. Il faudrait être pointu pour aller repérer qu'il manque ici.

Pour la légende, c'est possible ? juste intégrer une case vide via un paramètre légende ? -- Archimëa [Toc 2 Mi] 22 septembre 2018 à 20:13 (CEST)

• pour le renommage du paramètre : il y avait des bugs sous-jacents, que j'ai rafistolés, le module était cassé à la base ; essaie de nouveau, ça devrait fonctionner comme tu avais fait
• pour l'ajout des {{lang}} : pas difficile dans l'absolu, mais comme j'ai expliqué, je pense qu'il est mieux de limiter les différences entre les modules enwiki et frwiki
• pour le champ supplémentaire de légende : en fait j'avais déjà regardé auparavant, mais sans aller jusqu'au bout ; a priori pas trop difficile, il faut juste encadrer la <table> actuelle avec un <div> pour pouvoir appender la légende à ce div, et peut-être 1 ou 2 règles CSS à ajuster concernant les floats, la largeur…

od†n ↗^blah 22 septembre 2018 à 20:27 (CEST)

Je viens de voir tes corrections, merci pour le travail, ca a demandé par mal d'efforts; merci !

Bon, c'est bon pour le premier modèle. PS, j'ai pas pu mettre QidSérie sinon ca bugue à cause du é, mais enfin c'est déjà mieux.

Pour le champ supplémentaire, je suis bien incapable de faire ca, j'avais essayé de tester le rajout d'une "ligne" [1]. Comme c'est du chinois, je suppose que j'avais fait n'importe quoi. -- Archimëa [Toc 2 Mi] 23 septembre 2018 à 17:51 (CEST)

Bonjour Od1n, j'ai fait quelques tests sur le modèle directement : Utilisateur:Archimëa/Brouillon 2, ne pouvant modifier le module.

Je vois qu'il y a une erreur sur le module, mais c’est peut-être pas grave puisque le modèle fonctionne.

Avec ma solution, j'ai en effet un problème de largeur et d'alignement, que je n'arrive pas à gommer... -- Archimëa [Toc 2 Mi] 8 octobre 2018 à 14:10 (CEST)

J'avais dit encadrer :

<div en float right>
    <table (sans float)></table>
    <div>légende optionnelle</div>
</div>

Pour la suite merci de refiler le bébé au projet Modèle.

od†n ↗^blah 8 octobre 2018 à 14:23 (CEST)

Merci pour ton aide et désolé pour le dérangement. -- Archimëa [Toc 2 Mi] 9 octobre 2018 à 00:27 (CEST)

 Archimëa : j'ai implémenté ce paramètre optionnel. C'est peut-être légèrement retouchable, mais le gros est fait. Je te laisse documenter etc. od†n ↗^blah 9 octobre 2018 à 03:07 (CEST)

Avant mon message j'avais bien testé d'encadrer la table... mais cela ne fonctionnait pas donc j'avais déplacé après.....

Ton exemple m'avais fait réussir : Utilisateur:Archimëa/Brouillon 2.....

Mais merci d'avoir implémenté directement dans le module, je te remercie.

J'ai mis en forme un titre (désolé je ne connais pas Lua, si j'ai fait des boulettes)

Désolé de t'avoir dérangé pour tous ca. et Merci pour l'aide. -- Archimëa [Toc 2 Mi] 9 octobre 2018 à 11:31 (CEST)

barre d'édition

bonjour ; j'ai perdu le bouton qui permettait rechercher/remplacer (entre autres) ? ; comment le retrouver ? ; cordialement ; JLM (discuter) 20 décembre 2018 à 15:46 (CET)

Bonjour, de quel bouton s'agit-il précisément ? J'ai une incertitude… Est-ce sur la barre d'outils "améliorée", ou est-ce le script venant de wikisource ? Voir aussi cette discussion très récente. od†n ↗^blah 20 décembre 2018 à 16:23 (CET)

@JLM Je veux bien aider, mais il faudrait me définir plus précisément le problème, sinon je ne sais même pas où commencer à chercher… od†n ↗^blah 21 décembre 2018 à 00:44 (CET)

comme signalé dans le bistro hier, j'ai perdu la barre d'édition habituelle, celle que j'avais en cochant : barre d'outils améliorée ; en particulier il y avait un bouton rechercher/remplacer vraiment commode ; il me semble que c'était celui avec un oeil qui maintenant donne Section Annexes ; merci ; JLM (discuter) 21 décembre 2018 à 15:43 (CET)

ah ! je viens de la retrouver, mais dans une barre vraiment bizarre où il y a juste une loupe qui fait Rechercher/Remplacer, plus un bouton Modifier la casse et deux boutons Trier ; d'où vient cette barre ? merci encore ; JLM (discuter) 21 décembre 2018 à 15:50 (CET)

Ces boutons correspondent à des scripts présents sur Utilisateur:JLM/common.js et Utilisateur:JLM/monobook.js, qui s'appliquent à la toolbar "ancienne". Je sais pourquoi à un moment cette toolbar n'était pas là, pour ensuite arriver par magie, c'est lié à des modifs récentes que j'ai faites.

Ce que je ne comprends pas, c'est que la toolbar "améliorée" semble s'être désactivée toute seule. Elle est cochée ou pas dans les préférences ?

od†n ↗^blah 21 décembre 2018 à 17:56 (CET)

Je viens de comprendre que tu as le gadget "Searchbox" d'activé. Je cherche dans cette direction. od†n ↗^blah 21 décembre 2018 à 18:03 (CET)

Le code de ce gadget est sans grande surprise un beau foutoir, c'est à peu près sûr que c'est avec lui qu'il y a un problème. Tu pourrais me dire si la barre "améliorée" est cochée, si tu as changé quelque chose récemment, et exactement tout ce que tu as de coché dans la liste des gadgets ? Merci od†n ↗^blah 21 décembre 2018 à 18:19 (CET)

Liens vers tout le merdier :

• gadget definition : MediaWiki:Gadget-lib-beau.js et MediaWiki:Gadget-searchbox.js
• trucs ensuite chargés : pl:MediaWiki:Gadget-searchbox.css, pl:MediaWiki:Gadget-sel_t.js et pl:MediaWiki:Gadget-nuxedtoolkit.js
• pas utilisé chez nous : pl:MediaWiki:Gadget-searchbox.js
• supprimé chez eux : pl:MediaWiki:Gadget-lib-beau.js

od†n ↗^blah 21 décembre 2018 à 18:38 (CET)

┌─────────────────────────────────────────────────┘
oui : Activer la barre d’outils améliorée est coché ; non je n'avais rien changé ; liste des gadgets : Archive links, Homonymiesencouleur, Searchbox, Suivisimple, Wdsearch, et j'ai tout coché hier dans Boutons de la barre d'outils après que je me sois aperçu de la disparition de ma barre habituelle (remplacée pas la barre décrite ci-dessus : une loupe, plus un bouton Modifier la casse et deux boutons Trier (et encore merci) ; JLM (discuter) 21 décembre 2018 à 18:52 (CET)

Merci pour les infos ; si la barre d'outils "améliorée" ne s'affiche pas alors qu'elle est cochée, il doit y avoir un code qui plante en amont. Tu as des erreurs dans la console javascript (touche F12) ? od†n ↗^blah 21 décembre 2018 à 19:09 (CET)

en passant en modification, j'ai :

JQMIGRATE: Migrate is installed with logging active, version 3.0.1 load.php:577:149

This page is using the deprecated ResourceLoader module "jquery.ui.position". load.php:55:291

This page is using the deprecated ResourceLoader module "jquery.ui.widget". load.php:86:936

Use of "importScriptURI" is deprecated. Use mw.loader instead. load.php:4:589

"This page is using the deprecated ResourceLoader module "schema.UniversalLanguageSelector".

See https://phabricator.wikimedia.org/T205744 for migration info." load.php:1277:370

"This page is using the deprecated ResourceLoader module "schema.QuickSurveyInitiation".

See https://phabricator.wikimedia.org/T205744 for migration info." load.php:1277:98

This page is using the deprecated ResourceLoader module "jquery.ui.core".

Please use OOUI instead. load.php:11:84

"This page is using the deprecated ResourceLoader module "schema.ReadingDepth".

See https://phabricator.wikimedia.org/T205744 for migration info." load.php:1:85

This page is using the deprecated ResourceLoader module "ext.wikiEditor.toolbar".

Please use 'ext.wikiEditor' instead. load.php:1:88

L’utilisation de « document.createAttribute() » est obsolète. Utiliser « element.setAttribute() » à la place. index.php:202:15

L’utilisation de l’attribut « nodeValue » d’un attribut est obsolète. Utiliser « value » à la place. index.php:203:4

L’utilisation de « setAttributeNode() » est obsolète. Utiliser « setAttribute() » à la place. index.php:204:4

"This page is using the deprecated ResourceLoader module "schema.EditAttemptStep".

See https://phabricator.wikimedia.org/T205744 for migration info."

JLM (discuter) 21 décembre 2018 à 21:43 (CET)

@JLM J'ai encore un peu de mal à comprendre :

• Dans la situation de départ (premiers messages), qu'est-ce qui avait disparu, exactement ? (quelle toolbar, la toolbar complète ou une partie, etc.)
• Peux-tu réexpliquer cette phrase que je n'ai pas comprise : « j'ai perdu la barre d'édition habituelle, celle que j'avais en cochant : barre d'outils améliorée ; en particulier il y avait un bouton rechercher/remplacer vraiment commode ; il me semble que c'était celui avec un oeil qui maintenant donne Section Annexes »
  • elle est comment, cette "barre d'édition habituelle" ?
  • même chose pour le "bouton rechercher/remplacer vraiment commode" ?
  • et surtout, que vient faire dans l'affaire le bouton "avec un oeil" (il appartient à la toolbar "ancienne" et sert à tout autre chose) ?
• En redécochant les cases "gadgets toolbars standards", peux-tu reproduire le problème de départ ? Et si oui, quelles sont les erreurs javascript ?
• À noter que le gadget Searchbox peut s'ajouter à divers endroits (et ça varie selon les ordres d'exécution, un joli merdier). Notamment, si tu as la toolbar "améliorée" regarde si tu n'aurais pas un menu "Gadgets" qui s'ajoute après les menus "Avancé / Caractères spéciaux / Aide".

od†n ↗^blah 22 décembre 2018 à 17:11 (CET)

d'abord excuse les termes que j'utilise, il y a des lustres que je n'avais pas touché (ni même regardé) mes Préférences

avant cet « incident », j'avais depuis très longtemps une barre qui comportait de nombreux boutons, à partir de la gauche : texte en gras, italique, souligné, barré, exposant, indice, texte en grand, texte en petit, 4 boutons Chapitre, lien interne, lien externe, etc. et vers la fin ce bouton Rechercher/Remplacer, dont je crois me souvenir qu'il était représenté par un oeil ? Soudain, cette barre a disparu, remplacée par un barre du quatre boutons : une loupe qui est en fait ce bouton Rechercher/Remplacer que je croyais avoir perdu (!), un bouton Modifier la casse représenté par un P majuscule/p minuscule, un bouton Trier alpha représenté curieusement par P/p, un bouton Trier ordre décroissant représenté tout aussi curieusement par P/p, et c'était tout. Depuis, après être intervenu dans mes préférences, j'ai quatre barres : 1 cette barre à quatre boutons décrite précédemment, 2. une barre semblable à la barre que j'avais avant (texte en gras, italique, souligné, barré…) mais pas ce fameux bouton Rechercher/Remplacer 3. une barre avec 6 boutons suivis des menus "Avancé / Caractères spéciaux / Aide" 4. une barre : Titre Format Liste à puces Liste numérotée, etc. avec tout au bout, seul, un bouton Rechercher/Remplacer, mais qui ne donne pas la même chose que celui de la première barre...

je n'ai pas de menu "Gadgets" qui s'ajoute après les menus "Avancé / Caractères spéciaux / Aide".

cases "gadgets toolbars standards" : tu veux dire les cases sous Gagjets / Boutons de la barre d'outils ?

JLM (discuter) 22 décembre 2018 à 18:41 (CET)

Je comprends un peu mieux. Le point de confusion, c'est que la barre que tu avais au départ, c'était la toolbar "ancienne" (+ les 4 boutons du gadget Searchbox), et ce alors que tu avais pourtant la barre "améliorée" cochée dans les préférences (vraiment tordu, mais passons).

Je ne garantis vraiment pas de m'occuper de ce gadget, car les histoires de toolbar étaient déjà très casse-couilles, et ce gadget à lui seul est largement pire que tout le reste additionné, pour te situer le niveau.

Par contre je peux t'indiquer comment tu devrais retrouver ce que tu avais au départ : dans "préférences > modification" décoche la "toolbar améliorée", et dans les gadgets coche "Searchbox" et "MonobookToolbarStandard".

Tu auras remarqué que le gadget peut aussi s'intégrer à la "toolbar améliorée", ça fonctionne parfois, mais l'intégration est hasardeuse et bancale…

Bref, essaie de régler les cases comme j'ai indiqué, et dis-moi si ça fonctionne. od†n ↗^blah 22 décembre 2018 à 21:23 (CET)

┌─────────────────────────────────────────────────┘
ça fonctionne ; un très grand merci de t'être occupé du pauvre ignorant que je suis en matière de « Gadjets »  ; JLM (discuter) 23 décembre 2018 à 12:22 (CET)

Documentation Javascript dans l'environnement Mediawiki

Bonsoir Od1n ! Je suis en train de regarder par-ci et par-là les différentes documentation fournies sur Mediawiki au sujet de Javascript. Pour autant, il ne me semble pas avoir trouvé une page résumant les bonnes pratiques à suivre pour que tout le monde s'y retrouve. Par exemple, il semblerait que jQuery puisse être utilisé, alors que ce n'est pas le truc le plus léger, sauf qu'on ne sait pas quand il est déconseillé de l'utiliser. Je trouve moins d'informations au sujet de Javascript que de Lua pour les modules... Merci d'avance pour tes remarques, Lofhi [me contacter] 29 décembre 2018 à 02:32 (CET)

Salut, en général je pars de cette page ; elle aurait encore un peu besoin d'être nettoyée/complétée, mais globalement ça va, c'est encore le meilleur point de départ. Cette page te renverra pas mal vers la documentation de l'API, qui elle-même permet d'aller consulter les codes sources (les liens apparaissent en survolant les noms de fichier à droite).

Pour ce qui est de jQuery tu as raison, c'est maintenant plutôt à utiliser en dernière intention, et il vaut mieux préférer les codes mw.* (par exemple pour les requêtes API, les cookies...) ou du JavaScript natif (par exemple pour la manipulation DOM). Maintenant que le JavaScript n'est plus du tout exécuté sur les IE <= 10, on dispose d'un JavaScript natif plutôt moderne.

od†n ↗^blah 29 décembre 2018 à 02:54 (CET)

bonne année + help stp !

coucou od1n ! je viens de manière très très intéressée te souhaiter une bonne année 2019 et te demander ton aide sur un modèle ! j'ai vu que tu étais intervenu sur le modèle {{orphelin}} qui catégorise les pages sur lesquelles il est apposé ! je voudrais faire la même chose pour le modèle {{une pomme est un fruit}} mais c'est trop compliqué pour moi j'ai un peu peur de faire exploser wp en ce début d'année ce serait dommage ! alors voilà : il faudrait pouvoir lorsqu'on appose le modèle sur une page indiquer en même temps le paramètre des deux catégories : l'année de création de l'article et l'année de présentation au bistro ! ces deux paramètres sont bien en catégorie cachée mais j'aimerais qu'ils le soient réellement c'est-à-dire qu'ils n'ajoutent pas du code sur la page ! deux exemples : Concours pentétérique et Episkyros  ! autre question : de quelle manière puis-je repérer les pages sur lesquelles le modèle est apposé sans être proposé au bistro ? ex. : Pommeau (selle) ! jusqu'à 500 je peux faire travailler ma mémoire de manière empirique sur la liste des pages liées mais au-delà ça va devenir compliqué ! dernière question : le modèle est déployé sur près de 500 pages pour le seul dernier trimestre 2018 et va l'être de manière exponentielle en 2019 → passage de 3 à 6 pommes dans la rubrique « pommes à croquer » du bistro : il faudra p-ê le protéger ? valà valà ! une très bonne année riche de jolis petits codes et de plein d'autres gourmandises ! mandariine ^(d) 1 janvier 2019 à 10:01 (CET)

J'ai réalisé une partie du boulot histoire de "démarrer la machine", pour la suite (fignolages, documentation modèle) je t'invite à plutôt demander sur Discussion projet:Modèle. Il te faudrait aussi poster une demande WP:RBOT pour faire effectuer les quelques centaines de modifs semblables à celle-ci. od†n ↗^blah 1 janvier 2019 à 10:56 (CET)

chouette merci ! quelle célérité ! je m'en vais de ce pas voir les petits robots et j'irai ensuite faire modeler tout ça par les modeleurs ! vu la nouvelle Catégorie:Wikipédia:Pomme non présentée sur le bistro : quelle idée géniale ! pour le moment elle contient toutes les pommes : elle ne contiendra plus que les pommes non présentées au bistro une fois le bot passé c'est bien ça ? en tout cas encore merci pour ton aide ! mandariine ^(d) 1 janvier 2019 à 11:15 (CET)

C'est bien cela, le modèle ne peut pas deviner comment catégoriser, tant que les pages n'ont pas été mises à jour par un bot comme j'ai montré. od†n ↗^blah 1 janvier 2019 à 11:21 (CET)

Recommandations pour les articles sur les wikis Wikimédia pour les utilisateurs mobiles

Bonsoir Od1n, je ne sais pas si tu as vu la page recommendations for mobile friendly articles on Wikimedia wikis, mais il me semble que le module:Bandeau doit être modifié sur plusieurs points pour tenter de répondre à ces recommandations. Il y aussi des choses recommandées qui ne verront jamais le jour à mon avis : respect d'un ordre défini des bandeaux, etc.

Enfin bref, c'était pour te tenir au courant, puisque Zebulon semble être plus ou moins en wikibreak et que tu es le deuxième pseudo qui s'affiche majoritairement dans l'historique. Encore un nouveau standard ! Lofhi (me contacter) 5 février 2019 à 21:36 (CET)

Merci pour l'info, je crois bien avoir déjà croisé cette page. Tu penses à quels points en particulier ? od†n ↗^blah 5 février 2019 à 21:55 (CET)

Pour ce qui concerne le module, voici la liste des recommandations :

• utiliser des class sémantiques ;
• utiliser des class signalétiques pour les modèles du type {{Neutralité}}, {{Source douteuse}}, etc. ;
• utiliser la class .hide-when-compact qui devrait s'appliquer, à mon avis, au texte renseigné pour le paramètre textedes modèles méta ;
• étudier les class .mbox-text-div et .mbox-text-span (pas trop compris leur réelle utilité).

Ce qui veut dire que les construteurs des divs devraient un peu évoluer, mais cela ne semble pas être quelque chose de très significatif. Quelques paramètres... Les autres recommandations semblent pertinentes, mais là, c'est à la communauté de se prononcer et il semblerait que le modules ne soient pas concernés. Je ne sais pas ce que tu en penses. Lofhi (me contacter) 7 février 2019 à 20:50 (CET)

Note : je n'ai pas creusé le sujet en profondeur, mais je crois que nous ne sommes pas obligés d'utiliser les noms anglais proposés. Voir phab:T206177. Après, peut-être que cela pourrait être utile un jour... Il faut se renseigner, tout ne semble pas si limpide. Lofhi (me contacter) 7 février 2019 à 20:59 (CET)

Merci pour ce boulot de recherche concernant les classes.

Il y a pas mal de choses intéressantes dans la page que tu as indiquée, mais tout n'irait pas forcément faire consensus. Pour prendre un exemple, j'ai regardé le système qui déplace le 1^er paragraphe au dessus de l'infobox, et ça ne me branche pas du tout : la taille du paragraphe est variable donc pas très harmonieux, mais surtout, cela coupe le résumé introductif en deux et ça je trouve que c'est horrible ; tandis qu'avec l'infobox en premier, il "suffit" de scroller l'infobox (qui a son intérêt, notamment la photo en haut) et après on a un beau résumé introductif d'un bloc.

Pour en revenir aux classes, c'est intéressant et certainement à travailler sur le long terme. Personnellement ce n'est pas dans mes premières priorités, mais je me soucie de plus en plus du rendu sur mobile, donc à garder sous le coude. C'est surtout que je devine aisément un chantier d'envergure gigantesque, avec le risque d'ajouter encore plus de bazar dans les markups, classes, css, etc. si c'est réalisé trop précipitamment :)

od†n ↗^blah 7 février 2019 à 23:16 (CET)

MediaWiki:Gadget-ConfirmRollback.js

Bonsoir Od1n, je pense que ce gadget pourra bientôt être désactivé au profit de la demande de confirmation native qui va bientôt être ajoutée, voir phab:T199534. Visiblement, on peut aussi demander une activation par défaut, à voir si cela intéresse la communauté. Lofhi (me contacter) 17 mars 2019 à 19:09 (CET)

Merci pour l'info ; vu que ça traîne déjà depuis des années, on criera victoire le jour où cela sera effectivement implémenté ! od†n ↗^blah 17 mars 2019 à 21:55 (CET)

Humour?

Bonjour. Ce sont de surprenants commentaires d'édition et modifs, venant d'un admin... --Lewisiscrazy (discuter)

Bonjour, yep il se pourrait que j'aie un peu trollé. Je n'ai qu'une vie et elle est déjà bien entamée, alors des fois quand l'occasion se présente il m'arrive de me lâcher. od†n ↗^blah 20 mars 2019 à 03:09 (CET)

Dernière modification

Salut. Nous utilisons le modèle {{Série télévisée en production}} qui utilise le modèle {{Méta bandeau d'événement récent}}, qui utilise le modèle {{Dernière modification}}, et affiche le texte suivant : « La dernière modification de cette page a été faite le (date) à (heure) », ajusté au fuseau horaire de la France. Étant donné que wiki francophone est fréquenté par les québécois, et la France Outre-Mer, il serait pratique de préciser "(CET)" dans le modèle, n'est-ce pas ? Ou encore, pour les utilisateurs enregistrés, utiliser le fuseau sélectionné dans "Préférences"/"Apparence" ? Je préférais vous en aviser plutôt que de modifier le modèle moi-même. InMontreal (discuter) 23 mars 2019 à 17:24 (CET)

D'accord sur le principe. Mais j'ai l'impression que l'heure affichée est en UTC.

Comme tu l'as peut-être déjà remarqué dans l'historique de {{Méta bandeau d'événement récent}}, le modèle utilisait auparavant du JavaScript et affichait effectivement l'heure locale (mais aussi sans indication du fuseau). Pas question de remettre du JavaScript, d'autant plus que l'affichage en UTC me semble être plutôt une bonne solution.

Il te reste donc simplement à ajouter l'indication « (UTC) » si tu le souhaites.

(ah, et il y a un pitit bandeau en haut de ma pdd…)

od†n ↗^blah 23 mars 2019 à 18:14 (CET)

Edit : pas certain que cela soit en UTC… Sur Modèle:Dernière modification j'ai une heure de moins que le pied de page, mais sur Modèle:Méta bandeau d'événement récent j'ai la même heure que le pied de page. Ça me gonflera toujours autant ces histoires de fuseaux horaires. od†n ↗^blah 25 mars 2019 à 05:53 (CET)

Avertissement suppression « Brenton Tarrant »

Bonjour,

L’article « Brenton Tarrant » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). En tant que participant à l'article ou projet associé, vous êtes invité à donner votre avis à l’aune de l’existence de sources secondaires fiables et indépendantes et des critères généraux et spécifiques d'admissibilité.

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

Hercule (discuter) 15 mai 2019 à 15:37 (CEST)

Vu, je suis allé poster, merci. od†n ↗^blah 15 mai 2019 à 17:42 (CEST)

Outils pour les conventions JavaScript

Salut Od1n, je ne sais pas si tu connais ce site, mais je viens de le découvrir, alors je partage. Lofhi (me contacter) 16 mai 2019 à 19:28 (CEST)

Salut, je ne connaissais pas, merci pour l'info. Cela pourrait effectivement s'avérer bien appréciable. Reste à me souvenir de l'existence de cet outil pour quand il y en aura besoin ! od†n ↗^blah 20 mai 2019 à 04:30 (CEST)

Module Composition Division de France

Bonjour Od1n, Je vois que tu as résolu le pb du modèle Tableau Liste commune de France 2 qui buggait au-delà d’un certain nombre de communes en créant le Module:Tableau Liste commune de France 2.

Le Module:Composition Division de France a été créé par @Zebulon84 en mai 2018, suite au même constat, mais surtout pour s’affranchir de cette liste de communes qui est dressée à la main, alors qu’elle peut être automatisée à partir d’une base de données. Celle-ci est stockée sous forme de table sur Commons (comme celle des départements, voir explications sur le projet ici et modalités d’actualisation de la table ici). Mais ce module peut encore être amélioré, en particulier avec la récupération du nombre de communes (paramètre nbcom dans la table des départements) pour être utilisé :

• soit dans le titre du tableau ;
• soit en tant que valeur dans un texte d’introduction du tableau.

S’agissant de lua pur, j’ai pensé que tu pourrais être intéressé par le sujet (vu que pour ma part, je suis plutôt néophyte en la matière).
1-Ajout dans le titre du tableau pour avoir un texte comme « liste des 772 communes du département de X ». J’ai pensé ajouter dans le code tout simplement nbCom comme ceci

titre = titre
		.. nbCom
		.. ' '
		.. args['liste de']
		.. ' '
		.. config( 'titreTableau' )
		.. ' '
		.. nomDivision
		.. ' au '
		.. require 'Module:Date'.modeleDate{ completeList.description.date, nolinks=true }

(voir ici), Mais c’était trop simple pour être correct !
2-Récupération du paramètre nbcom pour l’insérer dans une phrase.
Il s’agirait ici de créer une fonction du type p.nbcom(prm) pour récupérer ledit-paramètre, de la même manière que function p.derniere_population_m(prm) de Module:Composition Division de France récupère la dernière population et peut ensuite être utilisée dans le Modèle:Dernière population commune de France.

3-Récupération du paramètre date de la table pour l'insérer dans une phrase.
Le tableau doit pouvoir être daté dans son titre, mais aussi dans la phrase introductrice. Il faudrait donc disposer d'une fonction qui récupère cette valeur, permettant de rédiger une phrase comme La Somme comprend [nbcom/772] communes au [date/1er janvier 2019].
J’avais déjà posé la question sur le projet Scribunto ici, mais sans succès ! Pourrais-tu regarder ce qu'il en est ? Merci par avance. Roland45 (discuter) 6 août 2019 à 10:51 (CEST)

Bonjour, merci pour l'info, je n'avais même pas vu passer Module:Composition Division de France au cours de mes interventions. J'ai développé mon module pour résoudre les problèmes de performances (donc de pages qui plantent), mais oui, il y a certainement d'autres axes d'améliorations possibles, par exemple les données comme tu as décrit. Mais bon, j'ai déjà passé beaucoup plus de temps que raisonnable sur le module, maintenant que le gros du problème de perfs est réglé, je dois passer le relai et passer à autre chose.

Pour les 3 points que tu as énumérés, en fait tu ne demandes pas de gros chantier mais simplement quelques modifs, pas si grosses que ça, à première vue. J'ai juste regardé très vite fait le 1er point, bizarre on dirait que c'est déjà implémenté ?

S'il n'y a personne sur le Projet:Scribunto pour s'occuper de cela, on a effectivement un gros problème de main d'œuvre :\

od†n ↗^blah 6 août 2019 à 11:14 (CEST)

Premier point traité, à noter que c'est effectif seulement en cas d'utilisation des données externes, pas si commune 1 etc sont renseignés dans le modèle. od†n ↗^blah 6 août 2019 à 16:05 (CEST)

C'est parfait pour le point 1. Pour le cas où les communes sont listées explicitement, on peut difficilement donner un nombre puisqu'on ne sait pas à quelle date est arrêtée la liste ni si elle est exhaustive. Merci bien.Roland45 (discuter) 6 août 2019 à 18:43 (CEST)

 Roland45 et Od1n : C'est presque parfait pour le point 1 ^^. En effet, le département en question possède des homonymes, les parenthèses se mettent...

Par exemple, pour le département de la Drôme, l'article principal est Drôme (département), et la liste des communes affiche les parenthèses "Liste des 364 communes du département Drôme () au 1er janvier 2019". Une idée de correction ?

Jessy ^Oui ? 7 août 2019 à 17:10 (CEST)

 JessydeVilly : Pour l'absence du genre (« département Drôme » au lieu de « département de la Drôme »), je pense que c'est dû au fait qu'il n'existe pas (a priori) de module de carte géolocalisée de type Module:Carte/données/drôme comme par exemple Module:Carte/données/deux-sèvres, (voir Catégorie:Module de paramétrage de carte de département français). Le module ne peut donc pas récupérer le genre du département (paramètre genre dans le module de carte). Il faudrait donc le créer.Roland45 (discuter) 7 août 2019 à 21:04 (CEST)

J'ai corrigé le problème de parenthèses, et Roland45 a déjà répondu concernant l'absence de conjonction que j'avais aussi remarquée, techniquement on ne peut pas vraiment faire mieux… od†n ↗^blah 7 août 2019 à 22:05 (CEST)

Concernant le point 2 : dans un tel nouveau modèle/module, on serait obligé de renseigner de nouveau les deux paramètres "| charte = <nom de la charte>" et " | <nom de la charte> = <valeur de la charte>", et aussi, il y aurait toute une consultation supplémentaire des données externes. Je pense que la moins pire solution serait d'intégrer la phrase voulue directement dans le présent module, un peu comme ce qui se fait avec Module:Population de France et Module:Population de France/Introductions. Nous fournir un gabarit de la phrase voulue pourrait aider à l'implémentation de celle-ci. Par contre pour la suite, j'aimerais bien que cette discussion soit coupé/collée vers une nouvelle section dans Discussion Projet:Scribunto. od†n ↗^blah 8 août 2019 à 00:55 (CEST)

Merci pour ton investissement en la matière et pour ton efficacité. Désolé de t'avoir sollicité directement mais comme tu le vois toi-même, la question avait été posée sur le projet mais sans résultats. Le nombre de développeurs en lua est en fait très restreint. Mais je reposerai plus tard la question sur le projet, peut-être effectivement en intégrant une phrase idoine.Roland45 (discuter) 8 août 2019 à 08:57 (CEST)

Infobox Cinéma

Salut, j'ai vu que tu avais retiré le lien dans les dates, pas de problème mais cette fonction est également activé sur d'autres infoboxs (par ex Modèle:Infobox Jeu vidéo, et il y en a d'autre). Il faudrait donc à mon avis entamer une discussion pour harmoniser tout ça... Déjà, il y en a sans le bandeau gris en fond (est-il utile ?) comme ici, bref. Perso, j'ai pas d'avis sur l'utilité de la date, ça peut parfois être une indication utile mais bon... Le lien vers l'année permettait au moins de rendre utile toute ces liste 2019 en littérature, 2019 en jeu vidéo, 2019 au cinéma... Peut être qu'il faudrait dans ce cas les inclure dans les articles connexe, pour qu'ils soient quand même visible. -- Nemo ^Discuter 29 août 2019 à 15:36 (CEST)

Comme j'ai indiqué dans le résumé de diff, ces liens sont à mon avis assez pénibles car il faut faire bien attention à ne pas cliquer dessus… Pour ce qui est de la visibilité des éphémérides, le lien présent sur l'année de sortie du film de l'infobox me paraît bien suffisant ; mais là encore, ce n'est que mon avis personnel. od†n ↗^blah 31 août 2019 à 22:48 (CEST)

Question de forme, alignement par défaut des en-têtes de tableaux (lignes)

Bonjour, Ce n'est pas très important mais je ne sais pas si ce diff est très consensuel. Si je ne me trompe pas, la modification touche beaucoup de tableaux (accessibles) dans l'encyclopédie : au moins ces plus de 19450 articles, sans compter les inclusions via modèles. Certains rédacteurs appréciaient l'alignement à gauche et prenaient en compte de cet alignement par défaut. Pour s'en convaincre, on rencontre parfois la syntaxe  ! scope="row" style="text-align:center;" |… pour les cas où l'alignement ne convenait pas. Syntaxe de style devenue superflue avec la modif puisque tous les "headers" sont désormais centrés. Est-ce une initiative personnelle? --Ideawipik (discuter) 2 septembre 2019 à 13:15 (CEST)

Bonjour, c'est une initiative tout à fait personnelle. Certains préféreront à gauche, d'autres au centre (pour ma part ça me paraît préférable au centre, pour la consistance des en-têtes), donc pour trancher, j'opte pour la solution sans rustine sur le CSS et uniforme à travers les wikis. od†n ↗^blah 2 septembre 2019 à 14:06 (CEST)

PAP

Hello,

Je peux comprendre ton avis sur le fond et je le respecte totalement. En revanche, qualifier autrui de « parasite », ce n'est pas dans l'esprit des lieux. Tu devrais le savoir.

— Jules ^Discuter 3 septembre 2019 à 22:14 (CEST)

Tout à fait. C'est simplement que quand je vois les community/machintruc managers qui débarquent avec leurs grands principes qu'ils sont les seuls à lire (et purée, voilà les pavés qu'ils pondent…), je réagis au huitième de tour. od†n ↗^blah 3 septembre 2019 à 22:41 (CEST)

Reference Tooltips

Salut Od1n, les problèmes de flèche semblent définitivement être réglé pour Reference Tooltips Il ne faut plus que créer sa page de description et l'inclure dans les gadgets MediaWiki:Gadgets-definition. Penses-tu qu'on peut dès à présent l'activer pour tous le monde ? Si oui, as tu le temps pour t'en charger ou tu préfère que je demande à un autre admin ? -- Nemo ^Discuter 9 septembre 2019 à 17:05 (CEST)

J'ai corrigé quelques bugs, mon rôle s'arrête là ; je ne souhaite effectivement pas me charger de cette activation… od†n ↗^blah 9 septembre 2019 à 22:32 (CEST)

help

bonjour et merci de ton message ; désolé de n'avoir pas répondu plus tôt, mais j'ai dû m'absenter ces deux derniers jours ; et ce matin, tout est rentré dans l'ordre !! j'avais essayé d'autres navigateurs, sans succès, purgé, sans plus de succès, mais pas pensé à la console JavaScript, ce qui aurait en effet sans doute été utile ; encore merci ; cordialement ; JLM (discuter) 13 septembre 2019 à 10:55 (CEST)

Des news

Bonsoir/bonjour as-tu des news pour Discussion modèle:Article#Bibcode? Je t'ai aussi 'appelé à l' aide' ici. Je me tourne vers toi car tu me semble etre le plus actif sur la maintenance de ces 'bidules' (et tu es toujours là (mais j'ai bien lu le message en tete de ta PdD )). Merci bien, Un Fou (discuter) 26 septembre 2019 à 01:53 (CEST)

Bistro du 15

Bonjour  Od1n, je viens de lire vos messages et j'aimerais pouvoir vous aider mais n'ai aucune idée. J'espère que d'autres contributeurs le pourront ou des amis dans la vraie vie. Tenez bon. Cordialement, --2A01:E35:8B77:6CF0:A401:BB6D:19E4:6CC (discuter) 15 novembre 2019 à 08:30 (CET)

Bonjour, on se connait pas (ou en tout cas, je ne m'en souvient pas !) cependant, la section engagé sur le bistro est inquiétante. J'ai pris sur moi d'envoyer un mail a a la fondation conformement a ce qui est ecrit sur cette page. J’espère que ta situation va s'arranger. Aratal (Diskussion) 15 novembre 2019 à 08:55 (CET)

Hello - Même message que celui de l'anonyme ci-dessus. Rien de particulier à proposer, dommage mais tout le soutien moral possible. TigH (discuter) 15 novembre 2019 à 11:31 (CET)

Salut Od1n. Je ne connais pas d'avocat, désolé, mais je tiens à t'encourager et à te rappeler à quel point tu es un contributeur génial — pas seulement compétent ou rigoureux ou agréable, mais tout cela à la fois et même plus. Rien à voir avec la choucroute et pas forcément d'une grande aide, mais comme c'est vrai, je n'ai pas besoin de me forcer et si le moral est au plus bas…

Par ailleurs… Je ne suis pas certain de comprendre ta recherche de poste à la fondation… Tu cherches spécifiquement à t'expatrier, ou tu cherches « juste » un job ? Parce que si je peux te rédiger une recommandation, ou faire suivre ton CV dans quelques boîtes où j'ai des contacts (logiciel et services, essentiellement), ce sera sans feinter.

Amicalement — Arkanosis ^✉ 15 novembre 2019 à 12:45 (CET)

je ne savais pas quoi faire cette nuit, j'ai du commencer à modifier une dizaine de fois la section du bistro mais je me suis ravisé à chaque fois. Bref, comme ci dessus, j'espère que tout ira pour le mieux pour toi. PEACE. Un Fou (discuter) 15 novembre 2019 à 23:49 (CET)

Coucou. Un peu pareil qu'au-dessus. Je n'ai pas de contacts ni de connaissances dans le monde de l'informatique/du développement (puisque je crois que tu as en particulier des compétences dans ce domaine) ni à Reims, donc je ne sais pas trop comment t'aider, mais je t'envoie du courage et un sincère soutien. J'imagine que tu connais déjà, mais au cas où, je le dis quand même : il existe un droit à l'aide juridictionnelle (cf. aussi [2]). Si tu cherches un avocat au barreau de Reims, as-tu essayé d'appeler le barreau et d'exposer ton cas pour qu'ils t'aiguillent vers un avocat compétent dans le domaine concerné ? — Jules ^Discuter 16 novembre 2019 à 11:38 (CET)

Bon courage. Lofhi (me contacter) 23 novembre 2019 à 18:52 (CET)

MediaWiki:Gadget-DeluxeHistory.js - Cross-wiki collaboration

Bonjour Od1n,

Je t'imagine très occupé, mais je tente toujours : sur le Wiktionnaire nous avons aussi le gadget DeluxeHistory, cela dit il semble que depuis un moment plus aucune différence n'est faite entre utilisateurs excepté entre inscrits et non-inscrits, et ayant remarqué ton expertise sur ce script sur Wikipédia et tes dernières modifications, peut-être dues à un changement dans MediaWiki qu'on pourrait répercuter sur wikt:MediaWiki:Gadget-DeluxeHistory.js, j'aimerais demander… — est-ce que, en un coup d'œil, tu aurais une chance de trouver ce qui ne va plus dans le script du Wiktionnaire ?

Toute piste serait fort appréciée, si possible.

Bien cldt, — Automatik (discuter) 3 décembre 2019 à 00:05 (CET)

@Automatik Salut, suite à des changements dans le markup produit par MediaWiki (depuis déjà plusieurs années…), il te faut remplacer un domUserlink.innerHTML; par domUserlink.textContent;. Refs notamment 129424989, 137522125.

De façon plus générale, il s'agit d'un fork d'une version datant de plusieurs années, donc forcément la survenue de ce genre de problème n'est pas très surprenante. J'ai survolé rapidement, si je n'ai rien raté les seules différences sont l'ajout du "oldBotMembers" et du "patrollerMembers" ? Dans ce cas, il serait très facile de refaire un nouveau fork tout neuf (prendre la version actuelle et y ajouter les fonctionnalités wiktionnaire).

od†n ↗^blah 6 décembre 2019 à 20:37 (CET)

Merci à vous deux.--Braaark (discuter) 9 décembre 2019 à 11:07 (CET)

Merci, le remplacement domUserlink.innerHTML; → domUserlink.textContent; a résolu le problème, et la mise à jour du code est aussi validée avec succès… Un grand merci pour les conseils avisés ! — Automatik (discuter) 10 décembre 2019 à 01:50 (CET)

Modèles Discogs

Bonjour Od1n. Juste pour info vu que tu es le dernier à être intervenu sur ces modèles (même si c'était il y deux ans !) : je les ai conformés aux conventions typos de WP sur les titres d’œuvres, à savoir qu'ils doivent - quelle que soit leur nature, singles ou albums - toujours être graphiés en italique et jamais entre guillemets (qui plus est droits). J'ai en revanche conservé le paramètre single pour éviter de devoir boter l'ensemble des inclusions. Et puis, ça servira peut-être dans l'avenir pour une autre fonction, qui sait ? Cordialement, --V°o°xhominis ^[allô?] 6 décembre 2019 à 20:03 (CET)

Vu, tout à fait d'accord avec tes corrections typographiques. Tu auras remarqué que les modèles MusicBrainz ont les mêmes problèmes ;)

Aussi, j'ai constaté que tous ces modèles de discographie auraient besoin de maintenance/mise au propre, au niveau des paramètres, de la documentation… mais c'est clair que la tâche est ingrate et rébarbative :p

od†n ↗^blah 7 décembre 2019 à 02:43 (CET)

Nan j'avais pas vu. C'est corrigé... du moins typographiquement ! Pour le reste, on devrait bien trouver quelques pédagogues désœuvrés sur le projet Musique. --V°o°xhominis ^[allô?] 9 décembre 2019 à 02:21 (CET)

romanichel

Salut. Je fais suite à cette RA : certains termes ou expressions ou attitudes sont stigmatisantes ou dénigrantes pour ceux qui les reçoivent ou qui en sont la cible même quand c'est quasi de l'expression populaire. Malheureusement ou pas, nous ne sommes pas dans le fond d'un bar à 3h du matin alors autant éviter de ressortir les bonnes vannes racistes, clichées ou vulgaires que ce soit dans les discussions ou dans les commentaires de diff. Revoir WP:RSV. -- Pªɖaw@ne 14 décembre 2019 à 12:15 (CET)

Page d'accueil en bas saxon

Bonjour! J'ai vu que vous travailliez souvent sur la page d'accueil. J'ai utilisé le design de la page d'accueil en français pour le Wikipédia en bas saxon (peu de designs compatibles avec les mobiles ont été publiés), mais la version mobile ne s'affiche pas correctement. La version mobile sur Wikipédia en bas saxon diffère quelque peu de celle sur Wikipédia en français, je n'ai pas trouvé la cause, avez-vous une idée? Merci d'avance. Servien (discuter) 29 décembre 2019 à 13:18 (CET)

Bonjour, ça ne serait pas le qui cause le problème ? od†n ↗^blah 29 décembre 2019 à 13:26 (CET)

2020

Bonne et heureuse année ! Mike the song remains the same 1 janvier 2020 à 21:20 (CET)

Ah… merci. De même ! od†n ↗^blah 2 janvier 2020 à 00:31 (CET)

Bonne année aussi et pour info une mini-modif dans ce modèle dont tu es le principal contributeur et que tu suis donc de près j'imagine : l'italique n'avait aucune justification pour la mention « (version du ...) » purement informative, comme le sont « (consulté le ...) » sur d'autres. Je l'ai donc remise en romain dans un souci d'homogénéité et de sobriété. Et un peu de sobriété en début d'année, c'est toujours bienvenu ! Cordialement, -- V°o°xhominis ^[allô?] 15 janvier 2020 à 22:52 (CET)

Bandeaux d’homonymie

Bonsoir, comme déjà discuté par ailleurs, j’ai terminé de réécrire tous les modèles de bandeaux de début d’article ou de section qui n’utilisaient pas de méta-modèle.

Il reste une centaine de modèles pour les homonymies. J’ai donc réécrit {{Bandeau homonymie}} (à renommer en Modèle:Méta bandeau d'homonymie) qui devrait pouvoir servir à la fois pour les modèles contenus dans Catégorie:Modèle de bandeau pour page d'homonymie et Catégorie:Modèle de bandeau renvoyant vers des homonymes. En effet, et sauf erreur de ma part, la seule différence est qu’il faut indiquer id=homonymie dans les pages d’homonymie.

La nouvelle version se trouve là : Modèle:Bandeau homonymie/Bac à sable. Et sa page de test est Modèle:Bandeau homonymie/Test. Saurais-tu me confirmer que c’est correct au niveau CSS ? En effet, j’ajoute un class=homonymie et je ne suis pas sûr qu’il n’y ait pas d’interférences avec les class gérées par Module:Bandeau/Class.

Et comme tu n’aimes pas trop les bidouilles (moi non plus d’ailleurs), est-ce que cette solution n’en est pas une ?

Autre point : je ne me suis occupé que des articles et des modèles (sauf {{Wikiprojet}}, {{En-tête de page de discussion}}, {{FilmDisneystandard}} et {{Anecdote publiée}} que je n’ai pas su convertir). Pour les autres espaces de noms, il en reste plus de 300 (Aide : 1, Discussions : 40, Module : 1, Projet : 5, Utilisateur : 92, Wikipédia : 181). On les trouve en faisant la recherche suivante : insource:/bandeau-(article|discussion|simple|système|section)/. J’imagine qu’avant de pouvoir alléger le common.css il faut s’en charger également ?

--FDo64 (discuter) 21 janvier 2020 à 23:00 (CET)

Salut, alors tout d'abord, un immense merci pour ce genre de boulot. C'est clairement ce dont nous avons besoin pour que le wiki reste gérable sur le long terme. De manière générale, j'ai le fort sentiment que les personnes qui cherchent à dégrossir les bazars, face à ceux qui en rajoutent encore plus, sont malheureusement extrêmement minoritaires. Donc quand j'en aperçois une, crois bien qu'elle a toute ma bénédiction.

En revanche, perso c'est de plus en plus la m*rde IRL (oui, ça peut encore descendre). Je n'ai absolument pas le temps de me lancer dans de telles explorations de codes, d'autant plus que c'est un chantier dont j'ai déjà une certaine idée de l'envergure.

Sans faire de délation, j'ai l'impression qu'au niveau des bandeaux nous subissons là les problèmes de maintenabilité liés aux modifs amenées vers 2012 par un contributeur apparemment plus actif aujourd'hui, qui était très sympathique, mais qui nous a pondu des systèmes super tordus, que ce soit pour la gestion de sa pdd, ou pour des classes CSS sur le wiki, notamment boîtes et bandeaux. Pour le dire clairement, c'est ni fait ni à refaire, et tout est à remettre à plat.

Juste une remarque à chaud : le nom de classe homonymie ne me semble pas assez précis (risque de collision). Quelque chose comme bandeau-homonymie serait possible ? De la même manière, peut-être remplacer id="homonymie" par id="bandeau-page-homonymie" (le remplacement sur le wiki serait relativement facile, et ça semble servir notamment à MediaWiki:Gadget-BandeauxPortails.js ou encore MediaWiki:Gadget-PaletteDeluxe.js).

Pour ce qui est du remplacement des classes hardcodées, je pense que la priorité est avant tout, avant l'allégement du Common.css, d'avoir un système de classes bien propre et à plat, sans surprises, sans collision. Je veux dire : telle classe produit un bandeau de section, telle classe produit un fond d'avertissement orange, telle classe produit une boîte flottant à droite, etc. Et le tout combinable sans surprise. Si tu as creusé le code comme j'ai déjà fait, tu auras constaté que nous en sommes un peu éloigné, avec des classes qui doivent être utilisées ensemble, des classes qui ne fonctionnement pas ensemble, ce genre de chose.

Amicalement et encore merci, od†n ↗^blah 22 janvier 2020 à 07:03 (CET)

Merci pour les scripts

Bonjour,

Je ne vous croise plus depuis quelques mois, ce qui est normal si j'ai bien compris ce que j'ai lu dans la section précédente. Néanmoins, je suis content de tout le travail que vous avez fait pour améliorer les scripts ou en produire d'autres.

En espérant vous croiser plus souvent dans nos pages à l'avenir, pour les bonnes raisons , je vous souhaite du succès dans L'IRL.

— Cantons-de-l'Est ^p|d|d [‌sysop] 3 février 2020 à 01:32 (CET)

Merci pour le message de soutien, ça fait toujours très plaisir. Pour ma part je continue de m'accrocher ! od†n ↗^blah 3 février 2020 à 02:53 (CET)

Traducteur automatique d’articles

Salut Od1n

Il y a un gros problème actuellement sur le traducteur automatique d’articles interwikis, qui ne fonctionne plus du tout en publication finale. Plusieurs personnes le signalent dans différentes langues sur la page https://www.mediawiki.org/wiki/Talk:Content_translation, mais personne ne répond.

Pourrais-tu regarder ça ou contacter des spécialistes ?

Merci Tubamirum (discuter) 14 mars 2020 à 00:17 (CET)

Désolé, mais c'est un code extrêmement complexe, qui ne peut pas être pris en main comme ça… De plus, on voit sur la pdd que ce genre de problèmes sont déjà signalés et connus, je ne peux rien y faire de plus…

(coup de gueule au passage : je ne donnerai pas de nom, mais j'en vois un qui s'attribue un peu trop de mérites à mon goût… « we », « our tool », qui a un joli PhD, qui fait des jolis schémas, qui donne des jolies conférences… et à côté, ben il y a ceux qui ont écrit le code.)

od†n ↗^blah 14 mars 2020 à 02:20 (CET)

Discussion Projet:Infobox/V3#Ajout de la classe infobox en début de class="

Salut Od1n,

Est-ce que tu as bien reçu la notification à propos de Discussion Projet:Infobox/V3#Ajout de la classe infobox en début de class=" ? The RedBurn (ϕ) 9 avril 2020 à 11:24 (CEST)

Yep bien reçu, je n'étais pas trop motivé, mais je viens de publier un message là-bas. od†n ↗^blah 10 avril 2020 à 02:14 (CEST)

Typographie

Salut, comme je viens de voir passer cette retouche, je n'avais effectivement pas mis de point à la fin, en application de WP:TYPO#LISTES SANS : : « Une liste, composée de groupes nominaux ou verbaux, non introduite par un deux-points a une majuscule en début d’item et pas de ponctuation finale. ». Enfin bon, ces histoires de typographie, on n'en finit jamais… Cordialement, od†n ↗^blah 6 mai 2020 à 03:00 (CEST)

Salut,
Est-ce que cela s’applique vu qu’il est indiqué « non introduite par un deux-points », mais la liste est bel et bien précédée par deux-points : « peut désigner : »
Cordialement, 2A02:2788:22A:100D:4169:D178:FCCC:5DDD (discuter) 6 mai 2020 à 03:12 (CEST)

Déplacement de Mediawiki vers Module:

Bonjour,

j'ai vu ce diff et je me demande s'il n'y a pas un souci à déplacer des codes d'un espace de nom dont l'édition est restreinte à la possession d'un droit particulier (editinterface) à un espace de nom pour lequel ce n'est (a priori) pas le cas ? Est-ce que ce type de transfert ne devrait pas être systématiquement accompagnée d'une protection de la page du module ? Est-ce que je dis une bêtise ?

Kropotkine 113 (discuter) 7 juin 2020 à 10:42 (CEST)

Bien vu, il devait certainement s'agir d'un oubli. Je me sers habituellement de Spécial:Modèles les plus liés pour repérer les protections manquantes, mais ça ne liste que les transclusions, pour ce qui est des messages système ce n'est pas listé… il faut donc au plus tôt penser à protéger, car après ça peut effectivement passer inaperçu pendant des années… Je viens donc d'ajouter la protection, merci pour le signalement. od†n ↗^blah 8 juin 2020 à 05:45 (CEST)

Ok, de rien. Et merci à toi. Kropotkine 113 (discuter) 9 juin 2020 à 13:58 (CEST)

Modèle cassé

Bonjour,
J'ai vu que tu es intervenu sur Module:Biblio/Lien web mais maintenant {{Lien web}} est cassé, voir par exemple Croissant-Rouge tunisien. Moumou82 ^[message]

Normalement réparé. Un grand merci pour ce signalement rapide ! od†n ↗^blah 14 juin 2020 à 09:55 (CEST)

Module:Bases

Bonjour,

J'ai fait un correctif dans le bac à sable, il fonctionne mais je ne suis pas sûr d'avoir utilisé la meilleure méthode, pourrais-tu vérifier : diff & Modèle:Bases littérature/Test ?

— eru ^[Discuter] 28 juin 2020 à 09:51 (CEST)

Quick note about a spam article added in this project

Hello! Hope you are having a great weekend. Sorry to bother you, but this is about this spam article Calvin Lo which was recently created in this project.
A user which has been blocked on EN has been creating a recently deleted article on EN. This user (blocked on EN) has recreated the article across many wiki projects see Wikidata for full details. It was also created in: now deleted: ID, AR,FR, JA, KO, MS, TH, and many others. The same account has been proven to be a sockpuppet of Timlaieditor (see the group that was blocked on June 18). Thought you may want to know as JA, MS, TH, AR, UR, and ID projects have already deleted the articles in their respective projects for cross-wiki spam/promotions. Hope you can help look into it. Thanks! — Infogapp1 (discuter) 19 juillet 2020 à 15:49 (CEST)

WikEd

Bonjour,

As-tu un avis sur le fait d'avoir un fork local du gadget WikEd ?

J'ai créé la copie et je l'ai tenue à jour de façon automatisée jusqu'en 2016 sur MediaWiki:Gadget-WikEd.js/local, en appliquant à chaque fois le patch pour ne pas remplacer les espaces insécables par "&nbsp;" (comme expliqué ici). Depuis, le code a été mis dans MediaWiki:Gadget-WikEd/local.js et ça a un peu divergé, de sorte que les mises à jour automatiques ne sont plus possibles, et je voudrais arrêter de suivre ça.

J'ai re-re-demandé il y a quelques jours à ce qu'une option soit ajoutée à la version d'origine pour qu'on puisse l'utiliser directement. Ça prend un certain temps. J'insiste ou tu préfères de toute façon qu'on garde notre version ?

Orlodrim (discuter) 10 octobre 2020 à 09:49 (CEST)

Oula, j'avais déjà vu passer… c'est vieux ça ! C'est une histoire où l'auteur du script s'entêtait à ne pas vouloir ajouter le réglage, ou revenir à l'ancien fonctionnement, alors que tout le monde lui faisait la demande ? J'espère que la situation va se débloquer cette fois-ci. Et je te comprends, c'est vraiment dommage, et laborieux, d'avoir à maintenir un fork uniquement à cause de cela.

Par ailleurs, je viens de créer phab:T265203, rapport au bouton « » qui ajoute inopinément des espaces insécables. Car c'est un problème qu'il serait vraiment bon d'éradiquer, même si cela nécessite de recourir à un workaround.

od†n ↗^blah 11 octobre 2020 à 05:19 (CEST)

Merci. Après deux personnes qui me disent "les forks c'est bien", c'est rassurant de savoir que tu ne viendras pas me dire la même chose si finalement ça marche.

Ce serait encore mieux si les espaces insécables n'étaient plus ajoutées, mais je crois qu'on n'est pas près de se débarrasser de toutes celles qui sont déjà là.

Orlodrim (discuter) 11 octobre 2020 à 09:30 (CEST)

J'ai l'impression que la discussion que tu as lancée sur le en.wiki a bien dévié en hors-sujet… Concernant la réponse de Cacycle sur sa page de discussion, on voit qu'il a répondu vraiment rapidement. Laissons-lui le temps ; si besoin, peut-être le relancer d'ici quelques semaines. Tout ce qu'il a à faire, c'est donner son feu vert, en espérant qu'il accepte maintenant ;) od†n ↗^blah 11 octobre 2020 à 10:16 (CEST)

Pour information, j'ai été récemment pingé sur meta:User:Jdlrobson/User scripts with client errors#3rd November (voir le tableau juste au dessus, avec les erreurs WikEd). Ça serait vraiment bien de ne plus avoir à se traîner le fork…

Edit rapide : je viens de voir qu'il y a eu de l'activité sur ta discussion avec Cacycle. Espérons.

od†n ↗^blah 6 novembre 2020 à 14:37 (CET)

L'article Modèle:Article en sursis est proposé à la suppression

Bonjour, L’article « Modèle:Article en sursis » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). 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 modèle:Article en sursis/Suppression. Le meilleur moyen d’obtenir un consensus pour la conservation 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

Epigraphiste (discuter) 13 décembre 2020 à 12:38 (CET)

L'article Mint Énergie est proposé à la suppression

Bonjour, L’article « Mint Énergie » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). 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:Mint Énergie/Suppression. Le meilleur moyen d’obtenir un consensus pour la conservation 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

Arroser (râler ou discuter ?) 13 mars 2021 à 16:23 (CET)

Avertissement suppression « Out from the Dark »

Page proposée à la suppression

Bonjour,

L’article « Out from the Dark ^{(page supprimée)} » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). En tant que participant à l'article ou projet associé, vous êtes invité à donner votre avis à l’aune de l’existence de sources secondaires fiables et indépendantes et des critères généraux et spécifiques d'admissibilité.

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) 15 mars 2021 à 23:34 (CET)

Concernant l'ajout d'un Gadget dans Préférences

Bonjour,

J'ai développé un Gadget qui génère un lien vers les résultats d'une requête SPARQL. Cette requête donne une description structurée d'une catégorie donnée en se basant sur les déclarations Wikidata les plus utilisées pour définir les membres directs de cette catégorie. La description de l'outil est disponible sur https://www.wikidata.org/wiki/Wikidata:Structured_Categories et le code source JavaScript est accessible sur https://www.wikidata.org/wiki/User:Csisc/StructuredCategories.js. Le code est fonctionnel. Je vous demande comment ajouter l'outil aux Préférences pour Wikipédia en français.

Mes salutations,

--Csisc (discuter) 16 avril 2021 à 14:19 (CEST)

Besoin de conseil, substitution et dièses

Bonjour Od1n. En regardant des messages substitués sur des pages utilisateur avec des codes inutilement long, et surtout contenant des éléments de programmation des modèles sans intérêt (voir Modèle:Actualités du Wiktionnaire), j'ai proposé une version allégée au brouillon (noté ici Test1).
Me rendant compte qu'il y avait, lors des substitutions, des retours à la ligne superflus au sein des propriétés des <div>, en raison de ceux ajoutés par MediaWiki pour les paramètres (ou les sorties de fonctions parser) commençant par un « * » ou un « # » (comme les codes couleurs), j'ai écrit, au brouillon, un modèle (noté ici Test2) qui permet de pallier le problème en faisant précéder le "dièse" d'un préfixe. Il accepte codes « #… » et noms de couleur. Il fonctionne dans la proposition ci-dessus. J'allais le mettre dans l'espace des modèles pour qu'il soit utilisé tant dans {{Actualités du Wiktionnaire}} que dans {{BMA début}} concerné par le même souci, quand j'ai découvert {{Dièse couleur web}} que tu as crée. Ce dernier pourrait être plus intéressant que ma proposition Test2.

Mais j'ai des questions, à partir de Modèle:BMA début/Bac à sable dont l'inclusion est correcte mais pas encore la substitution. Dans, {{Dièse couleur web}}, il y aurait besoin de "subster" le #invoke du module. Je vois deux possibilités de changement pour le code de ce dernier :

1. l'ajout d'un {{{|safesubst:}}} : {{{{{|safesubst:}}}#invoke:Dièse couleur web|main|{{{1}}}}}
2. l'ajout d'un paramètre « subst » : {{{{{subst|}}}#invoke:Dièse couleur web|main|{{{1}}}}} et on appellerait depuis l'autre modèle {{{{{|safesubst:}}}:Dièse couleur web|…|subst=safesubst:}}

Si la seconde option ne me semble pas dangereuse, j'ai un doute sur la première, quant aux autres utilisations du modèle. Cela dit, pour revenir à la question initiale et ne sachant comment sera géré le « &#35; », je crains que MediaWiki ne réintroduise un passage à la ligne, quel que soit le choix.

Pourrais-tu me conseiller sur cette question et sur l'utilité éventuelle d'un modèle de type "Test2" ? En espérant que tu auras quelques minutes à consacrer à cette question. Bonjour  Orlodrim, on ne sait, jamais, si tu passes dans le coin et veux aussi partager ta science . Bonne fin de journée. — Ideawipik (discuter) 2 mai 2021 à 20:52 (CEST)

 Ideawipik : Je ne vois pas de problème que la solution 1 pourrait introduire (et je trouve la solution 2 pas très élégante), du coup j'ai pris les devants et je l'ai déjà implémentée. Si jamais tu découvres quand même un problème n'hésite pas le signaler.

Pour ce qui est de ce genre d'insertions de sauts de lignes (refs phab:T14974), on fait ce qu'on peut pour les éviter, mais il ne faut pas que cela se fasse au détriment de la simplicité du code des modèles. Par exemple, si dans un attribut CSS inline on se retrouve avec des sauts de lignes, cela fonctionne quand même sans problème, et je pense qu'il est préférable de ne pas complexifier un code de modèle seulement pour éviter le saut de ligne.

od†n ↗^blah 4 mai 2021 à 10:40 (CEST)

Merci beaucoup pour la réponse et la modification. La substitution a lieu correctement. Pour le reste, tu n'as pas tort, c'est aussi en partie pour cela que j'ai souhaité voir s’il était possible d'utiliser un modèle existant plutôt que d'en créer un autre plus complexe avec deux paramètres (couleur et préfixe). Si on veut faire plus simple, dans {{BMA début}}, vu que les couleurs sont codées en dur, le mieux serait de n'utiliser que des codes couleur (#XXXXXX) et pas de noms. Il suffirait alors de sortir le # de la fonction switch (ou du if), comme je l'ai fait dans le bac à sable pour la première occurrence. Si on peut, sans problème, remplacer le « red » par #FF0000, je ne suis pas certain de la valeur à adopter pour le « grey » : #808080 (■) ou #BEBEBE (■) ? Je penche pour le premier. — Ideawipik (discuter) 5 mai 2021 à 22:32 (CEST)

Erreurs de dates dans modèles bibliographiques

Bonjour, un certain nombre d'articles affichent une erreur due à une date invalide dans des modèles bibliographiques (Catégorie:Page utilisant le modèle date avec une syntaxe erronée). J'ai le sentiment (sans en avoir la certitude) que ces articles sont apparus en erreur récemment et je vois que vous avez fait une modification sur inscriptionDate aujourd'hui. Est-ce que ça pourrait être lié ? Cordialement --Golmote (discuter) 11 juillet 2021 à 20:59 (CEST)

Notez que je ne suis pas forcément contre un affichage de ces erreurs. Ça permettrait au moins de les corriger. Mais je voulais m'assurer qu'il s'agissait d'une modification intentionnelle de votre part. --Golmote (discuter) 11 juillet 2021 à 21:00 (CEST)

Bonjour, il s'agit bien d'un changement volontaire, en fait au niveau de {{Lien archive}} où j'ai implémenté la wikification automatique des dates (refs 176641086 et 184551190). La catégorie contient actuellement moins de 100 pages, et il s'agit effectivement de dates invalides et assez simples à corriger (sauf exception…)

Concernant cette wikification automatique, on a trois solutions :

• Faire comme avant et ne pas wikifier automatiquement, laissant le paramètre tel que fourni. C'est-à-dire que soit la date n'est pas wikifiée (notamment : avec des retours à la ligne, sans vérification de la validité, conservant des formats à éviter tel que jj/mm/aaaa), soit on oblige à mettre {{date-|…}} dans le paramètre, ce qui est laborieux pour le rédacteur et complexifie le code de l'article.
• Essayer de wikifier automatiquement, et en cas d'échec, ne pas wikifier et afficher le paramètre tel qu'il était fourni. Le problème est qu'en cas de paramètre invalide, il n'y a ni message d'erreur, ni catégorisation.
• Wikifier automatiquement, et en cas d'échec, afficher un message d'erreur et catégoriser. Le problème étant que le paramètre devient strict, on ne peut plus mettre autre chose qu'une date.

od†n ↗^blah 11 juillet 2021 à 23:51 (CEST)

Je viens de repasser de la solution 3 à la solution 2, qui me semble être le meilleur compromis. Refs 184568701. Le seul inconvénient est que l'on perd la détection des dates vraiment invalides, mais on a d'autres solutions techniques pour les repérer, et on récupère la possibilité de mettre des valeurs libres. od†n ↗^blah 12 juillet 2021 à 00:08 (CEST)

Je vois, merci pour vos réponses ! Je pense que pour les exceptions, il restait envisageable de contourner le problème (dans votre exemple, en sortant le « modifié le » du modèle). Mais la solution 2 est certainement celle qui se met en place le plus facilement. Merci pour le lien wstat, je ne connaissais pas cet outil ! --Golmote (discuter) 12 juillet 2021 à 00:18 (CEST)

Le nocat de {{Sigle}}

Bonjour Od1n. Ta Bottine fait des bêtises, et je soupçonne que c'est toi le responsable (et coupable !). Le paramètre nocat du modèle Sigle est nécessaire dans toutes les pages d'homonymie titrées « Xxx » ou « Xxx (homonymie) » quand la page « XXX » (= le sigle) existe et est dûment catégorisée (que ce soit ou non une redirection). Il faudrait réverter tout ça. Amitiés, Ariel (discuter) 4 août 2021 à 09:30 (CEST)

Je vois je vois, la structure que tu exposes là fait sens, et il faudra que je regarde pour rectifier cela. Néanmoins je crains que cette structure ne soit un peu compliquée pour les rédacteurs, puisqu'il faut aller chercher si une redirection existe, en plus ça peut changer au cours du temps… od†n ↗^blah 4 août 2021 à 19:20 (CEST)

 Ariel Provost : j'ai traité les pages en question. Il reste uniquement Ches (homonymie) (CHES) que je ne sais pas tout à fait comment il faut traiter, donc je te laisse t'en charger, si tu le veux bien.

Par ailleurs, j'attire ton attention sur les pages listées dans Code Q#Extraits du code Q, un certain nombre d'entre elles ont la boîte Sigle, mais je ne sais pas si elle est vraiment adéquate, puisqu'il s'agit de codes et non de sigles à proprement parler.

od†n ↗^blah 5 août 2021 à 05:32 (CEST)

C'était bon pour la page « Ches (homonymie) » parce que la page « CHES » ne concernait qu'un des items. Mais comme ce CHESS-là n'était pas de façon évidente prépondérant sur l'autre, j'ai fait un sérieux ménage. J'ai notamment renommé « Ches (homonymie) » en « Ches », renommé l'ancienne page « CHES » avec le nom complet de l'acide, mis à jour les liens et transformé la page « CHES » en redirection vers « Ches ». Du coup, j'ai catégorisé la page du sigle et décatégorisé « Ches ». — Ariel (discuter) 5 août 2021 à 11:30 (CEST)

Ordonnancement des bandeaux et des boîtes (pages d'homonymie)

Bonjour Od1n . À propos de ta dernière modif de la page « Ches » (ici) : dans les pages d'homonymie, mettre dans le code le modèle « Autres projets » avant les modèles de bandeau (« Confusion », « Autre4 », etc., puis « Homonymie ») a pour effet que la boîte s'inscrit à droite des bandeaux (mais pas avant leur début) au lieu de s'inscrire dans le texte, il me semble que c'est bien plus logique (comparer par exemple la page « Ches » avant et après ta modif). Je le fais systématiquement, mais bien sûr seulement quand j'ai à faire des modifs plus substantielles sur la même page. Il me semble que ça relève du choix personnel et qu'on ne devrait pas changer cet ordre uniquement pour imposer le sien. Amitiés, Ariel (discuter) 6 août 2021 à 07:07 (CEST)

Rebonjour :) Ce qui me gêne le plus, c'est que quelque chose coupe la ligne de séparation du bandeau d'homonymie. Je pars du principe que ces bandeaux d'homonymie ne concernent pas spécifiquement le sujet de l'article, qu'ils sont un système de navigation pour se diriger vers d'autres articles. Autrement dit, l'article à proprement parler ne commence qu'en dessous de ces bandeaux. C'est comme avec les bandeaux de maintenance et les infoboxes, appliqué aux cas d'autres boîtes (sigle, autres projets…). J'en profite au passage pour mentionner cette discussion passée.

J'entends bien ta remarque pour ce qui est d'effectuer une modification avec "seulement" ceci comme changement. Mais à ma décharge, ces pages d'homonymies sont modifiées beaucoup moins fréquemment que les articles, donc les historiques sont courts et rapides à parcourir, et ces pages sont de petite taille, donc pas d'inquiétude au niveau du volume de données ajouté en base de données.

od†n ↗^blah 12 août 2021 à 06:16 (CEST)

Catégorie:Page utilisant le modèle date avec une syntaxe erronée & Module:Biblio/Références

Bonjour,

Pour information je pense que cette modification vient de faire apparaitre 642 pages dans la catégorie Catégorie:Page utilisant le modèle date avec une syntaxe erronée, ce qui est bien vu quelles sont effectivement erronées.

Reste à les nettoyer, mais cela va me prendre du temps.

— eru ^[Discuter] 3 septembre 2021 à 18:55 (CEST)

(en faite je viens de lire le commentaire de diff, cela était prévu:) ) — eru ^[Discuter] 3 septembre 2021 à 18:56 (CEST)

Bonjour, cette catégorisation est effectivement volontaire, et la majorité des erreurs sont évidentes à corriger (à voir à terme, ce qui reste en erreurs "pas évidentes à corriger"). Toutefois, j'ai un peu sous-estimé le nombre d'articles qui s'y retrouve… La catégorie se remplit encore, et là on en est presque à mille… od†n ↗^blah 3 septembre 2021 à 19:50 (CEST)

 Eru : Ça en est maintenant à 5 000 pages… considérant que la Catégorie:Page utilisant le modèle date avec une syntaxe erronée était auparavant entièrement vide, je me dis que le déplacement de cette nouvelle histoire vers une catégorie distincte pourrait être judicieux, ce qui permettrait de la vider sans "urgence". Penses-tu que l'idée est bonne, et si oui, que dirais-tu de Catégorie:Page contenant un paramètre "consulté le" avec une date invalide ?

Par ailleurs, j'ai remarqué qu'il y a de nombreuses communes françaises qui sont catégorisées, une histoire de climat pour la période 1981-2010, avec en référence un PDF et un paramètre "consulté le" qui contient tout autre chose : le nom de la station météo du PDF (celle qui est la plus proche de la commune). Vu la quantité de pages à traiter, c'est vraisemblablement quelque chose qu'il faudra faire traiter par un bot.

od†n ↗^blah 4 septembre 2021 à 05:03 (CEST)

Effectivement, je pensais déjà hier soir demander à un bot de s'occuper des cas les plus courants, mais en attendant utiliser une sous-catégorie serait une bonne idée.

Pour le nom ça me va, on pourra toujours la refusionner une fois vidée. — eru ^[Discuter] 4 septembre 2021 à 07:43 (CEST)

Voici quelque cas classique à donner aux bots :

• 14 décembre 2013=
• /11/2019
• 2018-12-05t09:19:54z
• 2021-05-30]
• {{date[27|10|2020}}
• 2017-23-02
• 1 au 10 mai 2014
• 16-05- 2007
• 2008-04-04 (4 avril 2008)
• 1re déc. 2007
• 16 avril 2016 2016
• 10.1o.2020
• 3 décembre 2005)

Pour ceux contenant du texte ou des fautes sur les mois cela sera sans doute plus compliqué, mais le reste je pense que @Bot de pluie et @LD AWBot (@Jules* et @LD) pourrait gérer cela. — eru ^[Discuter] 4 septembre 2021 à 08:12 (CEST)

Il y a effectivement ce genre de cas, mais mon idée de faire appel à un bot était pour le cas spécifique avec les communes françaises ;) La majorité des erreurs semblent être ce cas. od†n ↗^blah 4 septembre 2021 à 08:51 (CEST)

Oui j'en ai vu pas mal en effet, cela ferait déjà un bon nettoyage.

En regardant plusieurs exemples je vois que c'est @Roland45 qui ajoute cela généralement : Pourrais-tu regarder si tu as une erreur dans les scripts qui te permettent de créer les sections Climat — eru ^[Discuter] 4 septembre 2021 à 09:10 (CEST)

Bonjour à tous. Oui. J'avais identifié et corrigé ce problème (mais un peu tardivement, d'où ce grand nombre de communes impactées). Au lieu de prendre la date du jour pour le paramètre « consulté le » du modèle Lien web, mon bot allait cherche le nom de la station météorologique la plus proche. Par contre je ne savais pas comment retrouver tous les articles erronés. Avec cette catégorie, j'ai la solution. Pour la correction, je pourrais développer un petit script, mais j'ai l'impression que vous avez des outils plus puissants et dédiés au balayage de catégorie. Pour corriger mon erreur, il suffit de remplacer cette partie textuelle par une date vers le mois de juillet, le 21 juillet 2021 par exemple. Sinon, je m'en occuperai. Cordialement.Roland45 (discuter) 4 septembre 2021 à 10:35 (CEST)

Finalement, je prends en charge la correction des articles de communes. Cordialement.Roland45 (discuter) 4 septembre 2021 à 14:15 (CEST)

Bonjour et merci pour la notification ;

J'avais également repéré le cas des consulté le, à la fois sur wstats et en passant parmi les communes.

Je lance une première tentative de correction des erreurs les plus fréquentes pour diminuer cette catégorie. Parmi les formats identifiés, certains ne me semblent déjà pas traitables par un bot (ex. 16 avril 2016 2017 ; quelle année choisir ?)

Pour les dates, on a également le format américain et britannique à prendre en compte. Peut-être voir du côté des bots qui traduisent {{cite web}} et assimilés.

Remarque est-ce que l'éditeur visuel, via le référencement automatique, ajoute le bon format ?

BàV, LD ^{• m'écrire •} 4 septembre 2021 à 15:37 (CEST)

Re @Od1n, @Eru et @Roland45 ;

Je peux corriger la plupart des erreurs, mais seulement avec ces formats :

• 05/06/2020 ; en supposant que c'est jour mois année
• 2015-04-20 ; en supposant que c'est année mois jour
• 02-02-2020 ; en supposant que c'est jour mois année
• 06 18 2009 ; contrainte pour vérifier que le second >12
• 2020-11-10 ; contrainte pour vérifier que le second paramètre <12
• "01-05-2010" ; en supposant que c'est jour mois année
• tous les formats du type : 01 01 2020 ; très probablement jour mois année sont corrigés vers 01 janvier 2020
• tous les formats du type : année mois (string) jour vers journée mois (string) année
• tous les formats du type : 01 de enero de 2020 ; traduction du mois -> 01 janvier 2020
• Correction des doublons du type "consulté le=([Cc]onsulté le(=|))"

En testant sur 67 pages, a priori, les formats sans contrainte fonctionnent bien mais considérant qu'il y a le format américain/britannique, cela pourrait entraîner des erreurs. Je rajouterais des contraintes pour vérifier le paramètre "mois".

Je regarderais ça demain pour dégrossir la catégorie.

Plusieurs remarques :

• Je ne crois pas avoir la possibilité d'éviter de corriger une page si toutes les erreurs ne sont pas corrigées car la diversité des erreurs est trop grande ;
  • Je peux remplacer tout le contenu par la date du jour si l'erreur n'a pas été corrigé. Mais par conséquent, on ne saura pas si le lien fonctionne / le contenu a changé, etc. Parfois, il suffirait de traduire les mois depuis une autre langue, mais hormis pour les langues les plus parlées (c.à.d les 12 langues définies sur ce projet), je pense que je serais vraiment trop flemmard pour toutes les considérer. Donc, à voir si cette possibilité reste imaginée. Bon, s'il faut aller jusqu'à 20 langues x 12 mois, ok pour écrire 240 regexes; au-delà, non merci  : je laisserais la main à quelqu'un qui peut scripter ça plus facilement.
• Quid des paramètres vides ?
  • Je peux considérer de retirer les paramètres vides ou d'ajouter la date du jour.
• Comme sus-rappelé, certains formats ne pourront pas être corrigés, mais j'aimerais améliorer certains formats : par exemple 01 FÉVRIER 2020 ou 01 Février 2020, c'est juste une question de typo. Idem avec "12 février, 2020" ou variantes.
• Pour le moment, je peux éviter les "consulté le" comportant un point, une virgule, une balise (ex.consulté le=) ou un modèle.

Des remarques ou considérations ? ^^

BàV, LD ^{• m'écrire •} 4 septembre 2021 à 17:56 (CEST)

Je suggèrerais de faire au plus rapide et simplement traiter les cas les plus évidents (non ambigus). Avec ça et l'histoire des communes françaises, cela devrait déjà bien dégrossir la catégorie. Par contre, ne surtout pas remplacer le paramètre par la date du jour, car ça serait une information manifestement fausse… od†n ↗^blah 4 septembre 2021 à 18:06 (CEST)

Pour info, j'ai traité les communes figurant parmi les 3400 premiers articles de la catégorie. Je ne traite que les problématiques liées à la section climat. Je me suis aperçu qu'il pouvait y avoir quelques cas d'erreurs sur d'autres sections, mais c'est vraiment à la marge. Je les ferai ultérieurement.Roland45 (discuter) 4 septembre 2021 à 18:27 (CEST)

Je viens de mettre en œuvre une catégorie distincte : Catégorie:Page contenant un paramètre "consulté le" avec une date invalide. (pour info, j'avais dans un premier temps pensé à implémenter un nouveau paramètre catonerror dans le Module:Date, mais finalement c'est moins alambiqué d'implémenter la catégorie dans Module:Biblio/Références comme je viens de faire). od†n ↗^blah 4 septembre 2021 à 18:54 (CEST)

Merci à tous, le but est de traiter ceux qui peuvent l'être automatique, je vois que les catégories sont en trains de diminuer, le restant on pourra le faire à la main.

S'il y a une incertitude il vaut mieux ne rien faire, donc :

• Les 12 langues suffirons largement
• Ne pas mettre la date du jour, il faut mieux laisser vide / tel quel.
• Pour FÉVRIER c'est comme tu veux
• Je pense qu'il faut supprimer le caractère de début et de fin s'il s'agit de : [ ] ( ) , / " -
• Pour les modèles imbriqués c'est plus délicat, donc il faut mieux laisser un traitement manuel

— eru ^[Discuter] 4 septembre 2021 à 21:49 (CEST)

Bonsoir,

Mon bot a fini de tourner ; il s'est limité à une poignée d'articles et donc d'erreurs. Désormais, il peut éventuellement passer pour corriger certains formats/erreurs, mais pas toutes, ce serait plus histoire d'uniformiser le paramètre et diminuer le travail manuel qu'une véritable maintenance ^^ LD ^{• m'écrire •} 4 septembre 2021 à 23:56 (CEST)

Fais une passe pour corriger les « en septembre 2020 → septembre 2020 », j'ai l'impression que tu vas en trouver un petit paquet ;-) Il y aurait aussi les dates en espagnol qui devraient être relativement nombreuses et simples à traiter, e.g. « 1 de julio de 2017 → 1er juillet 2017 ». Et juste pour confirmer, as-tu bien vu que les pages sont maintenant listées dans une nouvelle catégorie, et que le déplacement est actuellement en cours ? od†n ↗^blah 5 septembre 2021 à 10:59 (CEST)

Un autre cas à traiter serait « consulté le=date de dernière consultation à indiquer après contrôle du lien → consulté le=<!--date de dernière consultation à indiquer après contrôle du lien--> ». od†n ↗^blah 5 septembre 2021 à 11:03 (CEST)

Et encore un autre : « (\d{4}-\d{2}-\d{2})[Tt]\d{2}:\d{2}:\d{2}[Zz] → $1 » (e.g. « 2018-12-04t17:02:49z → 2018-12-04 »). od†n ↗^blah 5 septembre 2021 à 11:09 (CEST)

Hello,

J'ai bien vu la transition de catégorie ; mais je cherche à partir du dump via wstat.fr ;

La catégorie est instable, et c'est comme si je vidais l'océan à la cuillère : elle continue de se remplir . Bon, ça s'explique aussi parce que AWB doit purger les articles en passant dedans même si je ne les corrige pas.

J'ai créé Utilisateur:LD/Date consulté le pour mieux suivre les changements ; ce sera plus simple pour le travail auto et manuel.

Pour les suggestions, je les ai intégrées, sauf "date de dernière ... après contrôle" (cf. modèle Lien web sur wstat, peu de cas, gérable manuellement).

J'ai rajouté d'autres types comme jour mois année année (si identique) => jour mois année.

L'espagnol est traité dans 99% des cas, le portugais et l'italien en revanche ne sont pas encore très bien corrigés.

Je fonctionne avec la méthode d'apprentissage supervisé, histoire d'aboutir à un script que je pourrais lancer deux à trois fois par an pour uniformiser à l'instar des dates. Par conséquent, il y a parfois plusieurs retouches d'un même article.

Je vais également me pencher du côté du paramètre "date" qui a des contenus dans d'autres langues. Par ex, le paramètre "añoacceso" (lien web sur wstat.fr).

Bref, un travail de longue haleine LD ^{• m'écrire •} 5 septembre 2021 à 18:18 (CEST)

Je suppose que Mediawiki piétine car je constate que la catégorie ne cesse encore d'augmenter ; parfois à juste titre car j'ai commis quelques impairs (mais que j'ai corrigés ensuite : ouf !). Quand je corrige, la catégorie stagne entre 2200 et 2250 ; quand j'arrête, elle dépasse 2350. Ce qui me rassure et me motive, c'est que ce ne sont pas les mêmes articles qui apparaissent...

Mais sinon, je me demande quand même si la détection avec {{article}} fonctionne comme les autres, par ex. dans cette modification j'ai corrigé le format qui n'était pas détecté, alors que pour {{Lien web}} par ex. avant cette correction, le format était détecté.

Dans le même ordre d'idée, le paramètre "date" mériterait souvent le même type de correction, et je ne suis pas certain que Module:Biblio lui impose un format "francophone".

Je ne comprends pas grand chose au Lua, mais à voir si Module:Biblio/Références tient bien compte de {{article}} et si le paramètre date pourraît être traité également. On risque cependant d'avoir encore 3000 articles ou plus à mettre dans Catégorie:Page contenant un paramètre "date" avec une date invalide ; mais quite à corriger les principaux modèles de référence, autant corriger le plus de paramètres  !

Malheureusement, je ne pourrais pas traiter le paramètre "date" entier tout de suite ; mais j'ai commencé au moins à corriger des bricoles comme "01 de janvier de 2016".

N.B. : limiter la détection au ns 1 voire ns 10 et 14 me paraît également une bonne idée ; surtout les brouillons, j'en ai retouchés mais autant dire que certains auteurs abandonnent leurs brouillons donc je ne suis pas certain que ce soit très utile...

BàV, LD ^{• m'écrire •} 6 septembre 2021 à 01:10 (CEST)

Réponse rapide concernant le "consulté le" erroné qui n'était pas détecté dans le {{Article}} que tu as donné en exemple : c'est parce qu'il ne contient pas de paramètre "lire en ligne" ou "url", et du coup le paramètre "consulté le" n'est en fait pas utilisé. od†n ↗^blah 6 septembre 2021 à 04:14 (CEST)

Bonjour Od1n et LD

Les catégories ont enfin fini d'êtres mise à jour, il reste donc pages 3 930 à traiter.

Est-ce qu'il reste des dates qui peuvent être traitées par le bot ?

En ignorant les fauts de frappe je trouve :

• 2011-jul-02
• 31 avril 2014
• 4 de janvier de 2014
• 25 septembre, 2019
• 7 octobre 2012 2012
• des retours chariot : Cancer du poumon

Il reste également des communes liés à donneespubliques.meteofrance.fr dans des sections climat Castelnau_Montratier-Sainte_Alauzie#cite_ref-11 @Roland45

— eru ^[Discuter] 10 septembre 2021 à 08:48 (CEST)

Bonjour à tous. Concernant la section climat des communes, ne reste en fait que les communes nouvelles à traiter. Je vais m'en occuper.Roland45 (discuter) 10 septembre 2021 à 09:00 (CEST)

bonjour @Eru :

Il reste des traductions depuis d'autres langues ; je n'ai pas fini mon travail en ce sens, je le mettrais sur Utilisateur:LD/Date consulté le quand ce sera le cas ^^ !

Sinon, les formats mentionnés peuvent encore être traités par un bot. Idem avec les fautes d'orthographe si on connait les orthographes problématiques. Par exemple, les coquilles "aveil", "avtil" et "avfil" (faute de frappe du r sur azerty) => quelques erreurs (ou écrit comme ceci : \d{1,2}(er|) av[^r]il \d{4}). Je n'ai pas la possibilité d'écrire un algorithme type bayésien qui permettrait de définir la probabilité a priori d'une faute de frappe avec un "dictionnaire" de substitutions, mais théoriquement, je peux quand même dresser des règles de substitutions pour les fautes de frappe les plus courrantes : cela demanderait donc la vérification d'un opérateur. Si jamais tu veux te lancer dans une liste exhaustive d'exemples différents, je pourrais les inclure .

Après avoir traité la plupart des erreurs, avec le nouveau dump, j'aurais aimé dresser la liste des formats excluants les mois francophones pour avoir les cas étranges, avec \d{1,2} (?!janvier|février|mars|avril|mai|juin|juillet|août|septembre|octobre|décembre) \d{4} sur wstat, mais cette regex ne semble pas compatible en pearl. Je vais poser la question à Orlodrim sur sa pdd.

En fonction de sa réponse, peut-être pas besoin de faire la liste des erreurs. LD (d) 10 septembre 2021 à 11:12 (CEST)

Merci tous les deux, j'ai ajouté quelques cas traitables, et une section pour les cas que je ne pense pas traitable.

Le \n et \r ne semble pas passer sur wstat (je ne connaissais pas cette fonction bien pratique).

Je repasserai dessus de temps en temps. — eru ^[Discuter] 10 septembre 2021 à 17:33 (CEST)

 eru, LD et Roland45 : Je viens de remarquer que la Catégorie:Page contenant un paramètre « consulté le » avec une date invalide est entièrement vide. J'ai cru à une erreur de code (refs 186440728, 186440975), mais non, le code fonctionne correctement et je ne rêve pas, la catégorisée a bien été entièrement vidée. Franchement, bravo à vous. od†n ↗^blah 3 octobre 2021 à 10:01 (CEST)

Merci, à par LD AWBot un bon nombre des correction ont été faites par Tylwyth Eldar.

Il reste 2 pages de test, le mieux serait je pense de gérer le paramètre nocat. — eru ^[Discuter] 3 octobre 2021 à 10:12 (CEST)

Je viens d'implémenter la non-catégorisation automatique de ces pages : 186826599. od†n ↗^blah 3 octobre 2021 à 10:26 (CEST)

┌─────────────────────────────────────────────────┘
Merci à tous les participants et participantes.
@Od1n, au cas où, « and not currentTitle.prefixedText:match( '^Modèle:.+/Bac à sable$' ) » pourrait être rajouté à la liste blanche.
Aussi, serait-il possible de réaliser la même maintenance que pour « consulté le » mais avec ces paramètres et sur tous les modèles (Lien web, Ouvrage, Article, Lien brisé, Chapitre, Article encyclopédique, etc.) :

• Accès url (paramètres définis valides : libre, inscription, limité ou payant ; à la limite on peut travailler depuis wstats mais la catégorisation ne serait pas de trop)
  • Access
  • Accesso
• Consulté
  • accessdate
• Date
• Data
• Date d’accès
• Archive-date
• Archivedate
• Brisé le (un peu particulier car cela peut être une date, un booléen ou une heure)
  • Datali (souvent obsolète, doit être remplacé par "brisé le" le plus souvent)
  • Urlmorta (idem)
  • Urlmorto (idem)

Il s'agirait surtout d'avoir les dates invalides depuis date et data voire date d'accès en priorité. Les autres paramètres sont particuliers voire déconseillés (les archives par ex.). Je mets les paramètres importés depuis d'autres wikis en italique, car ils sont probablement (et idéalement) à convertir en français pour uniformiser.
Si jamais une catégorie était créée pour recenser toutes les pages avec des paramètres étrangers ou non existants pour ces modèles, ce serait vraiment génial pour que je passe avec mon bot. Cela m'éviterait d'attendre le dump. Bien à toi, — LD (d) 4 octobre 2021 à 17:17 (CEST)

En fait à la base, après avoir déjà implémenté la wikification automatique (sans erreur en cas de date non reconnue) dans divers modèles, j'avais activé la détection d'erreur (message d'erreur + catégorisation) pour le paramètre "date" du modèle {{Lien archive}} (et aussi {{Interview}}, beaucoup moins utilisé). Mais il s'est avéré que beaucoup plus d'erreurs que prévu étaient présentes, et je suis revenu au statu quo en désactivant la détection d'erreur pour {{Lien archive}} ; cf. cette discussion plus haut, 184551691 et 184568701.

Plus tard, on en arrive à notre paramètre "consulté le" du Module:Biblio/Références. Naïvement, je me suis dit « bon, ce paramètre-là, pour y mettre autre chose qu'une date, faut vraiment y aller… », donc je lui ai activé la détection d'erreur et… boum, on s'est retrouvé avec la détection de milliers d'erreurs et tous les messages et traitements constituant ce fil de discussion.

J'avais là aussi envisagé de revenir au statu quo en désactivant la détection d'erreur, mais plusieurs contributeurs ont effectué un boulot monstre pour traiter les erreurs, donc j'ai laissé la détection, et au final la catégorie a été entièrement vidée !

Par la suite, j'ai amélioré le code de détection d'erreur, en implémentant la possibilité de gérer finement l'affichage ou non d'erreur et la catégorisation, cf. 186440728. Au vu des boîtes de Pandore que cela ouvre, pour ma part je ne vais pas de nouveau activer des détections d'erreur, mais pour ceux qui veulent faire la maintenance, vous avez l'outil pour configurer la détection/catégorisation d'erreur au cas par cas.

Pour finir, last but not least, il pourrait quand même être pertinent de laisser la possiblité de mettre autre chose que seulement une date, sans considérer qu'il s'agisse d'erreurs. C'est aussi pour cela que j'étais retourné au statu quo pour le paramètre "date", pour permettre de mettre autre chose qu'une date seule. Là je vous laisse voir. Vous pourriez par exemple ne pas afficher de message d'erreur mais catégoriser (plus ou moins temporairement).

od†n ↗^blah 4 octobre 2021 à 19:15 (CEST)

@Od1n Salut et désolé du retard. En réalité, il n'est pas nécessaire d'avoir un message d'erreur. Ma demande concerne avant tout la catégorisation afin d'uniformiser au mieux, voire déceller des erreurs de formatage. (En plus de rajouter une exception pour les bacs à sable.)

Le module est protégé (admin only), et je ne connais pas assez Lua pour suggérer des modifications sur WP:DIPP et/ou en pdd de toute façon. Préfères-tu que je soumette ma demande au projet Lua ?

BàT, LD (d) 15 octobre 2021 à 19:57 (CEST)

Module Liens

Merci pour toutes tes optimisations, j'essaierai d'en prendre compte pour mes prochains modules.

Pour le table.insert vs finalResult[ #finalResult + 1 ] cela change quoi en pratique ? — eru ^[Discuter] 9 décembre 2021 à 19:09 (CET)

C'est fonctionnellement identique, simplement plus performant (on évite un appel de fonction, etc.). C'est un pattern bien connu en Lua, et cette réponse sur Stack Overflow explique vraiment bien. Dans le cas présent, la différence n'est guère significative vu que le code n'est pas exécuté de nombreuses fois (modèle présent une seule fois dans la page), mais cela reste toujours bon à prendre.

Par ailleurs, il y a ce document [PDF] a priori très connu, qui expose pas mal d'autres points (variables locales, table rehashes, string interning (en)…).

od†n ↗^blah 10 décembre 2021 à 18:10 (CET)

Module:Unité : Module:Composition Division de France

Bonsoir,

Il semblerait que les modifications que vous avez effectué ces derniers jours sur le Module:Unité entraînent un problème d'affichage dans les tableaux générés par le Module:Composition Division de France.

Visiblement, le Module:Unité permet un formatage du résultat du calcul de la densité à deux décimales. Or si l'on regarde par exemple Liste des communes de l'Ain, la densité comporte désormais dix décimales contre deux auparavant.

Pouvez-vous corriger Module:Composition Division de France en conséquence ?

Cordialement, Jessy ^Oui ? 29 décembre 2021 à 22:11 (CET)

C'est corrigé. En fait je n'avais pas introduit de bug, mais mes modifications ont fait émerger un bug qui était enfoui de longue date, et qui n'était pas visible auparavant. Un grand merci pour ce signalement, qui aura conduit à la correction de ce problème. od†n ↗^blah 30 décembre 2021 à 04:26 (CET)

Merci pour votre réactivité. Cordialement, Jessy ^Oui ? 30 décembre 2021 à 08:58 (CET)

{{Titre sans précision}}

Salut et bonne année. Je viens de voir cette modif et ton commentaire de diff associé. Je ne connaissais pas ce modèle mais vu que j'étais un peu à l'origine de l'initiation des infobox v3 et des usages que je connais sur les infobox, il y a très peu de cas ou l'insertion dans l'infobox v3 cassera le titre de l'infobox. Donc, je suis plutôt pour son insertion dans l'infobox directement (après il faudra faire le ménage sur les infobox où tu l'as inséré ). 'toff ^[discut.] 1 janvier 2022 à 18:29 (CET)

Salut 'toff et bonne année aussi. L'implémentation du {{Titre sans précision}} directement dans la brique {{Infobox V3/Début}} (et pourquoi pas aussi dans les infoboxes V2) pourra effectivement permettre de généraliser ce traitement, et de simplifier tous les modèles d'infoboxes, qui n'auront plus besoin d'y faire appel explicitement. Pour ce qui est de nettoyer les utilisations déjà présentes dans les infoboxes, cela devrait pouvoir se réaliser programmatiquement sans trop de difficultés. Si jamais tu penses à des cas où ce {{Titre sans précision}} pourrait produire des résultats erronées, n'hésite pas à en faire part, ça serait grandement utile. od†n ↗^blah 3 janvier 2022 à 18:46 (CET)

Bonjour ! Bonne idée, attention toutes fois aux effets de bord des Infobox qui ont un nom construit avec d'autres informations entre parenthèses (autre nom, date...). Par exemple en V2, Modèle:Infobox Cours d'eau, Modèle:Infobox Personnalité militaire et Modèle:Infobox Système d'écriture. Et d'autres trouvées en cherchant dans les statistiques. En V3, il y a par exemple, Modèle:Infobox Pays. --FDo64 (discuter) 3 janvier 2022 à 20:26 (CET)

FDo64, j'ai un peu survolé les infoboxes que tu as données en exemple, mais j'ai l'impression qu'il n'y a pas de cas où il ne serait pas souhaitable de supprimer la partie entre parenthèses ? od†n ↗^blah 10 janvier 2022 à 06:38 (CET)

Bonsoir, j'ai effectué différents tests et en effet, mes craintes ne se sont pas vérifiées. Sans doute parce que les parenthèses sont toujours précédées d'un saut de ligne ? --FDo64 (discuter) 10 janvier 2022 à 23:56 (CET)

Tu parles du saut de ligne dans l'en-tête de l'infobox ? Dans ce cas tu as peut-être confondu : si on prend par exemple Meuse (fleuve), le « Maas, Maes, Moûse, Mosa » n'a rien à voir avec le titre de la page, c'est le paramètre autres noms de l'infobox. Et je précise aussi, le modèle {{Titre sans précision}} supprime tout suffixe entre parenthèses, peu importe son contenu, que cela soit « (film, 1956) », « (fleuve) » ou « (f̵̳̉ͭ̉̐ͬͣ︣͒͑l̵̲̇̉e̷̢̝ͭ̈͗̚u̶̞̻᷊̯̮̎︡ͭv̴̱̖̭̦̤̮̘̖̘͖͌᷾ͫ̉︠͡e̶͇͕͔︢̈̌) ». od†n ↗^blah 11 janvier 2022 à 03:57 (CET)

Salut !

Comme ci-dessus je ne voyais pas la solution que tu envisageais, j'avais imaginé dans {{Infobox V3/Début}} quelque chose de très simple mais qui au final est plus risqué :

|{{Titre sans précision|{{{text|}}}}}

Maintenant j'imagine que tu as prévu la syntaxe suivante :

|{{#if:{{{text|}}}|{{{text|}}}|{{Titre sans précision}}}}

Donc tout va bien !

--FDo64 (discuter) 11 janvier 2022 à 23:51 (CET)

How we will see unregistered users

Bonjour !

Vous recevez ce message parce que vous êtes un administrateur ou une administratrice sur un wiki Wikimedia.

Aujourd'hui, lorsqu'une personne modifie un wiki Wikimedia sans être connectée, nous affichons son adresse IP. Comme vous le savez peut-être déjà, nous ne serons plus en mesure de le faire à l'avenir. Il s'agit d'une décision du service juridique de la Fondation Wikimedia, car les normes et réglementations en matière de confidentialité en ligne ont changé.

Au lieu de l'IP, nous allons montrer une identité masquée. Du fait de votre statut d'admin, vous pourrez toujours accéder à l'adresse IP. Il y aura également un nouveau droit d'utilisateur pour celles et ceux qui ne sont pas admin mais qui ont besoin de voir les IP complètes, afin de lutter contre le vandalisme, le harcèlement et le spam. Les patrouilleurs et patrouilleuses verront également une partie de l'IP même sans ce droit d'utilisateur. Nous travaillons également sur de meilleurs outils pour faciliter la maintenance des wikis.

Si vous ne l'avez pas encore fait, vous pouvez en savoir plus sur Meta. Si vous voulez être sûr de ne pas manquer les changements techniques sur les wikis Wikimedia, vous pouvez vous inscrire à aux actualités techniques hebdomadaires (Tech News).

Nous avons deux propositions concernant le possible fonctionnement de cette identité. Nous apprécierions vos commentaires sur la façon dont vous pensez que cela fonctionnerait le mieux pour vous et votre wiki, maintenant et à l'avenir. Vous pouvez nous laisser un message sur la page de discussion. Vous pouvez écrire dans votre langue. Les suggestions ont été publiées en octobre et nous déciderons après le 17 janvier.

Merci. /Johan (WMF)

4 janvier 2022 à 19:15 (CET)

Vector et MediaWiki:Common.css 

Bonjour, par rapport à cette modification, s'il te plaît ne supprime pas la modification de @Jon (WMF): l'équipe Web est en train de fixer un problème avec le nouvel entête figé, demais cela sera résolu, mais ils ont besoin de cette modification pour progresser. Jon vient de m'écrire que selon lui ce serait préferable de ne pas avoir l'entête sur la page d'accueil de Monobook jusqu'à jeudi plutôt que de casser l'entête figé de tous les utilisateurs connectés qui utilisent Vector". C'est vraiment temporaire. Merci pour ton attention.--Patafisik (WMF) (discuter) 12 janvier 2022 à 19:21 (CET)

Hello, now that the issues have been pinpointed and that they are being worked on, I won't touch the upcoming edits. You can redo the changes in the Common.css and in the messages, as you see fit. Regards, od†n ↗^blah 12 janvier 2022 à 20:03 (CET)

By the way, refs this topic you posted too. od†n ↗^blah 12 janvier 2022 à 20:08 (CET)

@Jon (WMF)--Patafisik (WMF) (discuter) 12 janvier 2022 à 20:08 (CET)

J'ai rétabli comme souhaité : Common.css, messages Mainpage-title et Mainpage-title-loggedin .

À propos de ce que tu as écrit, « ne pas avoir l'entête sur la page d'accueil de Monobook jusqu'à jeudi », ça ne serait pas plutôt le contraire ? À savoir l'en-tête qui s'affiche temporairement jusqu'à jeudi, au lieu d'être masquée.

od†n ↗^blah 12 janvier 2022 à 20:51 (CET)

Utilisateur:Od1n Tomorrow PM all issues raised should have been addressed. If not, I'll make sure to provide the necessary backports ASAP.

Regarding Monobook, the following change will hide the header on the MonoBook homepage for now, but it can be removed (reverted) safely when this week's deploy is complete:

https://fr.wikipedia.org/w/index.php?title=MediaWiki%3AMonobook.css&type=revision&diff=189832648&oldid=189745818 Jon (WMF) (discuter) 12 janvier 2022 à 23:27 (CET)

Siècles en majuscules

Bonsoir Od1n, merci pour la modification sur Divyavadana. Il faut donc systématiquement utiliser les majuscules pour les différents modèles "siècle"?
Je suis retourné sur la page et je vois en effet que tous les modèles sont notés avec le nombre en majuscules. Mais p-ê serait-il bien de spécifier clairement au début de la page qu'il faut utiliser les maj.? Pour moi, le système fonctionnant avec les minuscules, je ne suis pas allé voir plus loin...; d'autant que c'est plus rapide, puisqu'on n'a pas besoin d'activer la touche maj. Et comme l'être humain est naturellement paresseux... Cordialement, Dawamne (discuter) 20 janvier 2022 à 21:25 (CET)

Bonjour,

Je pars du principe que la saisie en majuscules dans le code est beaucoup moins déroutante : 1) le code ressemble davantage à ce qui est affiché, 2) ça fait vraiment bizarre de voir un siècle écrit en minuscules, et 3) une immense majorité des contributeurs écrivent comme cela, donc c'est plus uniforme et moins surprenant.

Cela étant, à ce jour ça fonctionne aussi si on saisit en minuscules (car un CSS "normalise" l'affichage), et cela ne devrait pas changer dans l'immédiat. Disons que je passe sur les articles pour corriger/uniformiser les codes, c'est toujours bon à prendre et cela prépare le terrain en cas de changements ultérieurs au niveau des modèles.

En tout cas, ne te tracasse pas avec cela, mon objectif est de simplifier les codes pour les contributeurs ;) Si je remplace les siècles saisis en minuscules, pour l'instant c'est seulement pour limiter leur propagation, voir s'ils ont tendance à revenir…

Mais sinon, tu as essayé de saisir les siècles en majuscules non pas avec le caps lock, mais avec la touche shift ? Parce que j'en conviens qu'avec le caps lock ça doit être la plaie, mais avec le shift ça passe crème.

od†n ↗^blah 21 janvier 2022 à 02:22 (CET)

Merci pour ta réponse. Oui, j'utilise aussi le shift, mais cela reste malgré tout plus "pesant". Cela dit, c'est un détail et j'utiliserai désormais les majuscules. Bonne suite, Dawamne (discuter) 21 janvier 2022 à 09:01 (CET)

Je suis content

Bonjour,

En parcourant l'historique d'un modèle sur lequel j'ai travaillé, j'ai vu votre pseudo. En parcourant votre historique de contributions, j'observe que vous êtes toujours actif ici. Je suis content de vous savoir parmi nous.

— Cantons-de-l'Est ^p|d|d [‌sysop] 6 mars 2022 à 13:37 (CET)

Et oui, toujours là ! Il faut faire des choix et j'essaie de limiter l'investissement en temps dans Wikipédia, mais je garde toujours un pied ici. Merci pour le message, ça fait plaisir. J'espère que les choses vont bien aussi de votre côté. od†n ↗^blah 7 mars 2022 à 03:14 (CET)

Merci aussi pour avoir maintenu les modules que j'ai créé ou développé il y a quelques années. Désolé pour le manque de commentaire pertinents, les nombreuses faute d'orthographe dans ceux que j'avais écris, et un code parfois (souvent ?) obscur. — Zebulon84 (discuter) 7 mars 2022 à 14:06 (CET)

Zebulon84 après une longue absence je t'avais effectivement vu revenir, c'était assez inespéré et ça a été vraiment une bonne surprise. Aucun problème avec ton approche productive, je vois d'autres personnes qui fonctionnent comme ça, en y réfléchissant je me rends compte que ça a le mérite de faire avancer les choses, et c'est préférable à mon approche perfectionniste (ce qui en réalité est plus un défaut qu'une qualité), où à vouloir faire le mieux dès le départ finalement rien n'est fait. J'en profite donc pour te souhaiter un bon retour, d'autant plus qu'on est plutôt en manque de main-d'œuvre technique. od†n ↗^blah 10 mars 2022 à 01:59 (CET)

Demande d'import d'un modèle très utile

Bonjour. J'ai demandé il y a une semaine sur le Bistro s'il était possible d'importer en:Template:Reflist-talk. Puisque personne ne l'a fait et que je sais que tu es capable de te débrouiller en codage, je te demande directement : pourrais-tu importer ce modèle, sous le nom de "Reflist-discussion", avec "Reflist-talk" comme autre nom possible ? Veverve (discuter) 27 mars 2022 à 20:02 (CEST)

Bonjour, c'est un modèle qui semble effectivement être assez utilisé. En revanche je n'ai vraiment plus le temps de me lancer dans des chantiers supplémentaires. Si tu as demandé seulement sur le bistro, ce n'est pas surprenant que la demande n'ait pas encore trouvé du monde pour s'en charger. Le mieux serait que tu postes une demande sur Projet:Modèle/Demandes. od†n ↗^blah 28 mars 2022 à 02:56 (CEST)

Pour information, Zebulon84 a traité la demande ici : Projet:Modèle/Demandes/2022#Demande d'import d'un modèle très utile, Template:Reflist-talk. od†n ↗^blah 19 avril 2022 à 07:56 (CEST)

Extrait/Excerpt

Bonsoir,

Je suis tombé dessus par hasard, mais 100% des articles de mon échantillonnage incluant le {{extrait}} et avec des ref dans cet extrait, posent un problème. Bon, soyons honnête, 100% ça fait 2 articles :

• Konso (woreda)#Préhistoire
• Bardonnex#Conseil municipal

Les ref ne passent pas et nous gratifient d'un beau Erreur de référence : Balise <ref> incorrecte : les références sans nom doivent avoir un contenu. Bon en fait dans le cas de Bardonnex ce n'est pas si net puisque seule la première des trois référence rate, d'où ma tentative de correction sur la loi Suisse, un bel échec. Par contre pour Konso c'est une ref tout à fait standard.

Bref vu que tu as l'air de maîtriser le module excerpt (et en être le seul auteur francophone), peut-être que tu as une idée.

Bonne soirée, Gaillac (discuter) 14 juin 2022 à 22:24 (CEST)

Bon je rajoute ReCAPTCHA#Collecte de données et Notaire#Suisse, avec des petites variations sur certaines ref qui posent problème. Mon échantillonnage prend de l'ampleur, quatre sur quatre ;-) Gaillac (discuter) 14 juin 2022 à 22:31 (CEST)

Bonjour, c'est un module sur lequel je n'ai jamais travaillé (excepté une correction mineure), et dont à propos l'utilisation me semble assez risquée (par exemple, si dans l'article inclus des paragraphes sont ajoutés/supprimés, leurs numéros sont décalés). En tout cas, le problème que tu as signalé semble avoir été corrigé dans cette mise à jour récente (et qui inclut ma correction mineure, que l'auteur a dû remarquer). Voir aussi cette discussion sur le sujet. od†n ↗^blah 15 juin 2022 à 14:47 (CEST)

Espaces insécables inopinées

Bonjour Od1n, je régis à cette modif : d'où sortent ces insécables ? Elles n'ont pas été posées volontairement il me semble, alors est-ce que ça viendrait d'un outil utilisé pour éditer les pages (je pense à un traitement de texte) qui ferait ça tout seul à l'insu de la pcW ? Et comment les repérez-vous ? En cherchant les   dans le html de de la page ? Bien à vous, -- 🐜 jilucorg ✉ 20 juin 2022 à 09:17 (CEST)

Il s'agit de recherches que j'ai effectuées avec l'outil wstat.fr : sur le paramètre "pages totales" et sur le paramètre "pages" (la zone de saisie contient une espace insécable, Alt+0160).

Je me rends ensuite sur la page en question, puis sur "Modifier le code", ensuite je sélectionne tout, je copie puis colle, ce qui fait sauter les espaces insécables (elles sont remplacées par des espaces simples), et enfin je fais "Voir les modifications" pour voir les changements que cela a effectué.

Pour ce qui est de l'origine de telles espaces insécables, je ne sais pas trop, je sais juste que quand on fait de la maintenance sur le wiki, on tombe souvent sur des trucs vraiment improbables ! L'hypothèse la plus probable serait l'utilisation d'un éditeur de texte externe genre Word, en effet.

od†n ↗^blah 20 juin 2022 à 15:36 (CEST)

Merci pour cette explication détaillée ! -- 🐜 jilucorg ✉ 20 juin 2022 à 16:13 (CEST)

Code IETF du moldave déprécié

Bonjour Od1n

Je suis passé sur Module:Langue/Data et j'ai vu ta modif du 1er juin 2022 [3]

Pour info, le problème avec le code mo ne date pas d'hier (cf. [4])

En bref, le code du moldave est déprécié depuis 2008, il faut utiliser celui du roumain.

Il est vraiment improbable que ce code soit utilisé de nouveau et je ne suis pas du tout sûr qu'utiliser ro-MD soit la chose à faire (l'IETF préconise d'utiliser seulement ro, voir sur https://r12a.github.io/app-subtags/ (Find > "moldovan"). )

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 1 juillet 2022 à 18:25 (CEST)

Bonjour, je m'étais penché sur la question, avant de constater qu'en fait, il est tout simplement impossible d'avoir dans ce module de données deux langues avec un même code. C'est une contrainte purement technique, pour laquelle on ne peut pas faire grand chose.

Prenant acte de la contrainte technique, qui d'une certaine façon coupe court au débat, j'ai ensuite trouvé le code ro-MD, que l'on peut malgré tout estimer convenable pour notre utilisation (même s'il est remis en question, au moins on comprend ce qu'il désigne), et je suis donc parvenu à cette solution "la moins pire".

od†n ↗^blah 2 juillet 2022 à 00:49 (CEST)

En fait, j'avais fini par trouver qu'il avait été proposé d'utiliser ro-Cyrl-MD[5] mais ça a été abandonné (d'ailleurs le « moldave » s'écrit aussi avec l'alphabet romain, c'est celui-ci qui est utilisé par l'administration, sur les billets,les panneaux routiers, etc.).

D'ailleurs, [6] à fermé en 2006 et est maintenant redirigé sur ro.wp.

Sinon, je ne pense pas qu'il faille créer nous même des usages pour les codes de langue quand l'IETF dit explicitement le contraire. S'il y a un problème, c'est à la source, sur l'IETF qu'il faut le régler, pas sur Wikipédia.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 2 juillet 2022 à 16:35 (CEST)

La seule autre solution, techniquement possible, serait que « moldave » soit un alias pour le « roumain / ro ». Cela signifierait que les deux langues seraient techniquement équivalentes (correspondant à la même table dans les données). Ainsi :

• {{code langue|roumain}} et {{code langue|moldave}} donneraient tous deux « ro »
• {{nom langue|ro}} donnerait « roumain », en revanche :
  • il ne serait plus possible d'obtenir le nom « moldave » à partir d'un code de langue
  • {{nom langue|mo}} serait bien reconnu comme invalide, mais enverrait vers « roumain / ro ».

Mais si tu trouves que c'est une moins pire solution, pourquoi pas. od†n ↗^blah 12 juillet 2022 à 01:02 (CEST)

Je croyais que c'était déjà le cas mais en fait non, je viens de rectifier [7]. J'avais déjà corrigé {{mo}} et l'article Moldave (qui est d'ailleurs une grosse synthèse inédite). Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 12 juillet 2022 à 12:05 (CEST)

En fait ce à quoi j'avais pensé, c'était carrément de mettre "moldave" en nom supplémentaire dans la ligne "ro/roumain", c'est-à-dire complètement un alias.

Mais j'ai testé les résultats avec la manière dont tu as renseigné les données, et apparemment c'est correct. J'ai aussi confirmé en étudiant la construction pas-à-pas des données finales, et ça semble bien fonctionner.

Si on creuse un peu, les lignes "mo" et "ro-MD" ne rentrent pas en conflit car elles ont à la fois le même nom et redirigent vers le même code. C'est-à-dire qu'il n'y en a pas une qui va écraser les données de la précédente avec des données différentes. Néanmoins, vu que le "ro-MD" c'est un truc que j'avais ajouté, peut-être pourrait-on supprimer cette ligne.

od†n ↗^blah 25 juillet 2022 à 23:27 (CEST)

Le truc c'est que si on met « moldave » en alias de « roumain », ça ne sert que si on met moldave en valeur de paramètre (cas très rare à mon avis, les alias ne servent vraiment que pour les langues très utilisées, par une très petite partie des contributeurs, genre english à la place de en ou anglais), les valeurs mo restantes ou futures ne seront pas reconnues et feront une erreur.

Avec mo = { "moldave", invalide = "ro" }, on n'a pas ce problème, on affiche au survol que c'est en moldave (en affichant à l'écran le code ro), et on garde dans la liste que le code mo est bien invalide.

C'est la même chose avec ro-MD, il n'y a pas de problème de garder ce code dans la liste, il est techniquement valide (après on peut discuter de s'il vaut mieux afficher « moldave », « roumain » ou « roumain de Moldavie », mais c'est beaucoup d'histoire pour pas grand chose, et même l'IETF n'est pas très clair au sujet de l'usage des codes de région).

Ce n'est pas moi mais Zebulon84 qui a codé le truc, et je ne connais pas toutes les subtilités, mais ça ne me semble pas une bonne idée d'avoir des codes IETF en alias (j'ai d'ailleurs récemment enlevé un code ma qui était en alias pour l'arabe marocain : voir lignes 72 & 732, c'est le même problème de code invalide).

Je viens de corriger pas mal d'erreurs, mais il doit en rester d'autres, difficiles à repérer si on ne connait pas les codes corrects et les articles liés. Heureusement cette page n'est pas trop modifiée par le commun des contributeurs... Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 26 juillet 2022 à 01:30 (CEST)

Module Noble

Merci d'avoir attiré mon attention sur un morceau de code un peu trop cryptique. J'ai viré le string.find() et je l'ai remplacé par du code un peu plus long mais j'espère plus clair, avec quelques exemples.

Amicalement, Alserv (discuter) 11 juillet 2022 à 13:42 (CEST)

Le Module:Noble a effectivement bonne allure. De plus, les exemples que tu as ajoutés en commentaires sont vraiment utiles pour répertorier les cas de figures à supporter. od†n ↗^blah 12 juillet 2022 à 01:07 (CEST)

Modèle:A : ancres, performances, affichage incomplets.

Bonjour Od1n. Comme on pouvait s'y attendre, l'ajout d'une ancre pour les appels avec une majuscule au nom du modèle (diff) fait grossir la taille des pages, après expansion du modèle. Ainsi, la quasi-totalité des pages d'archive de WP:Demande de suppression immédiate depuis 2020 et beaucoup depuis 2016 (Archive56) sont entrées dans la catégorie:Page contenant trop d'inclusions de modèles. Il est peut-être préférable de faire machine arrière. L'intérêt des liens ancrés sur les pages d'archive est très faible. Les liens depuis l'historique de ces pages sont inexistants. Si la majorité des appels actuels se font avec les minuscules, autant laisser cela, comme avant (paramètre modèle depuis 2014). À mon avis, il vaut mieux avoir un affichage complet (avec des sections intelligibles et des liens internes, utiles notamment pour la recherche parmi les pages liées), au détriment d'ancres que personne n'utilise puisqu'elle n'étaient pas fonctionnelles avant ta modification du 6 septembre. Par ailleurs, les statistiques de début septembre ne montrent, parmi les 12 158 portant le modèle A, que 1479 pages avec des appels "en majuscule" pour plus de 10 000 avec une minuscule. De même, pour le modèle {{A'}}, on a 72 pages avec « A' » contre 387 avec « a' » et pour ce même modèle, 23 pages avec une redirection en « A- » contre 753 avec « a- ». Le bénéfice/coût semble assez bas. Et on gagnerait en temps de chargement des pages. À moins qu'on puisse faire des économies ailleurs dans le modèle {{A}}. Une autre "solution" pourrait-être de copier le code de A directement dans A' (et autres A-court, A-dpp), en retirant ce qui est inutile. Ainsi, on s'affranchirait du comptage en double dû à l'imbrication des modèles, mais on perdrait la factorisation du code. — Ideawipik (discuter) 14 septembre 2022 à 09:07 (CEST)

Bonjour Ideawipik. Merci pour ce signalement, encore une fois fort bien détaillé. Je ne pense pas que cette modification soit allée ajouter un poids vraiment important, le problème est plutôt que nous étions déjà vraiiiiiment à la limite (et le modèle étant utilisé un grand nombre de fois, le moindre alourdissement est démultiplié). Du coup, j'ai annulé 196751924 (mais j'ai laissé pour l'instant 196751710, dont l'impact devrait être quand même faible).

• Pour ce qui est de recopier le code de {{a}} dans {{a'}} (ainsi que {{a-court}} et {{a-dpp}}), on perdrait effectivement grandement en factorisation de code. Mais je pense que cela peut être envisagé, à titre exceptionnel, étant donné qu'il y a un problème manifeste de taille post-expand avec ces modèles qui sont utilisés un très grand nombre de fois sur certaines pages, et si j'ai bien compris, cette modification permettrait en gros de diviser le post-expand size par deux. Un point qui nous arrange, c'est que ces modèles sont modifiés assez peu souvent. Aussi, il est important de mentionner les modèles entre eux, afin qu'en cas de modifications sur l'un, on pense bien à mettre à jour les autres (c'est d'ailleurs pour cela que je suis intervenu sur les documentations de {{a'}}, {{a-court}} et {{a-dpp}}), après avoir transformé ces deux derniers en recopies de code du premier).
• Une piste complémentaire à envisager serait d'inliner le code de {{abréviation discrète}}. Cela permettrait de gratter quand même significativement en performances, et ça serait acceptable dans la mesure où le modèle {{abréviation discrète}} est stable (i.e. change peu), et que la classe "abbr" est déjà beaucoup utilisée séparément (i.e. sans passer par le modèle) sur le wiki. Enfin, une recherche (<abbr class="abbr[ ]"> reste techniquement réalisable afin de détecter toutes (ou presque) les utilisations manuelles de la classe. D'ailleurs, dans le « NewPP » de par exemple la page Wikipédia:Demande de suppression immédiate/Archives automatiques138 qui continue de poser des problèmes de performances, on voit tout de suite que les {{abréviation discrète}} ont un temps d'exécution significatif (ce qui n'est pas dû au modèle en lui-même, mais à son nombre d'inclusions) :

Transclusion expansion time report (%,ms,calls,template)
100.00% 1248.552      1 -total
 82.81% 1033.915   1268 Modèle:A'
 74.88%  934.900   1268 Modèle:A
 32.30%  403.323   2536 Modèle:Abréviation_discrète
  1.59%   19.889    149 Utilisateur:Gratus/PaStec/motif_SI
  1.52%   18.996      6 Modèle:Ping
  0.53%    6.569      2 Modèle:User
  0.43%    5.371      1 Modèle:Citation
  0.36%    4.488      3 Modèle:Notif
  0.35%    4.421      2 Modèle:Merci

Est-ce que tu valides pour effectuer ces deux modifications ?

od†n ↗^blah 19 septembre 2022 à 15:47 (CEST)

Bonjour Od1n. Bien vu le coup (et coût) de l'appel du modèle d’abréviation discrète dans {{A}}. Tu peux peut-être commencer par là. Et, si cela ne suffit pas, appliquer la "défactorisation généralisée" envisagée dans le premier point. Merci !

Ce qui explique aussi le problème pour la page donnée en exemple est la présence de plusieurs demandes groupées. Donc un ratio nombre de modèles par kilo-octet de wikicode plus élevé que s'il n'y avait qu'un seul modèle par section. J'avoue que je trouve généralement plus logiques les demandes groupées circonstanciées que la multiplication des sections et éditions de la page de requêtes pour des demandes similaires. On peut envisager de réduire légèrement la taille maximale par page d'archive (actuellement maxarchivesize = 400k) pour les demandes de suppression immédiate ou, beaucoup mieux en théorie, demander à Orlodrim (dresseur du bot d'archivage) s'il serait possible d'ajouter une contrainte sur le nombre de modèles de "type A" dans la page. — Ideawipik (discuter) 19 septembre 2022 à 18:30 (CEST)

Les deux modifications agissent sur des points différents et sont donc complémentaires. La défactorisation de {{a}} va principalement réduire le post-expand size (par deux quand même !), tandis que l'inlinage de {{abréviation discrète}} va principalement réduire le temps d'exécution (comme montré plus haut). Chacun agissant aussi sur l'autre point, mais marginalement.

La réduction du post-expand size est un impératif (sinon erreurs sur la page), et la réduction du temps d'exécution est très bonne à prendre vu comment ces pages sont lourdes à charger.

Je viens d'effectuer l'inlinage de {{abréviation discrète}}, mais comme en pouvait s'en douter il ne réduit pas suffisamment le post-expand size. La "défactorisation généralisée" sera donc aussi à effectuer.

od†n ↗^blah 20 septembre 2022 à 16:17 (CEST)

Je viens d'effectuer la "dé-factorisation" dans {{a'}}, {{a-court}} et {{a-dpp}}, et j'ai aussi ajouté un commentaire de code dans {{a}}. Comme on pouvait s'y attendre, le gain est vraiment conséquent. od†n ↗^blah 23 septembre 2022 à 06:08 (CEST)

{{Lien préfixé avec un deux-points}}

Bonjour Od1n.

J'ai vu que tu avais créé le modèle {{Lien préfixé avec un deux-points}}. Mais je l'ai vu un peu trop tard, car j'avais déjà créé {{Lien sûr}} qui fait la même chose (mais pas de la même manière). J'explique le contexte ici.

Néanmoins j'ai testé :

• ici avec le modèle que j'ai créé (ce diff est le résultat de {{subst:Test 1| Asticot| Asticothérapie| Astico-Brenta}} suivi de {{subst:User:Herr Sats/BàS modèle| Asticot| Asticothérapie| Astico-Brenta}}, où {{User:Herr Satz/BàS modèle}} est une copie de {{test 1}} en remplaçant les liens internes par {{safesubst:Lien sûr|{{{1}}}}}) et ça fonctionne.
• ici avec ton modèle (même chose qu'au point précédent, mais cette fois les liens internes étaient remplacés par {{safesubst:Lien préfixé avec un deux-points|{{{1}}}}}) et ça fonctionne aussi mais j'ai un problème avec le subst. Idéalement j'aimerais qu'il ne reste plus aucun autre code que les liens après la substitution, comme dans le test du point précédent.

Mes questions sont donc les suivantes :

• Je ne comprends pas trop le trim dont tu parlais ici quand tu as transféré le code dans {{Modèle:Lien préfixé avec un deux-points/main}}.
• Y a-t-il moyen de faire un safesubst de {{Lien préfixé avec un deux-points}} sans qu'il reste de code à la fin ? On peut mettre safesubst dans son code sans que ça n'ait d'autre conséquence ? Et le problème de la sous-page... J'avoue que je ne comprends pas grand chose aux substitutions.
• Question subsidiaire : est-ce toujours d'actualité, depuis 2021, que l'utilisation du Module:String comme je l'ai fait dans mon modèle, est plus gourmand en ressources que les if ?

En somme, que me conseilles-tu pour modifier avantageusement les modèles de messages utilisateur en adressant le problème des deux-points comme tu l'as fait avec ton modèle ? Je me demande si je ne pourrais pas simplement mettre l'appel du Module:String directement dans les modèles de message (sachant que je vais demander la suppression de mon {{Lien sûr}}, il n'est pas souhaitable qu'il subsiste deux modèles qui font la même chose).

Merci. Cordialement. — Hr. Satz 11 octobre 2022 à 21:29 (CEST)

Bonjour, je vais essayer d'apporter quelques éléments de réponse :

• Pour se prémunir de bugs en cas de présence d'espaces autour des paramètres, e.g. un modèle contenant {{Lien préfixé avec un deux-points| {{{page|}}} }} (démonstration d'espace qui se retrouverait dans le résultat : @[[PHP ]]@ donne @PHP @), j'ai voulu ajouter des {{trim}}. Problème, quand le résultat d'un modèle (en l'occurrence les {{trim}} que je souhaitais ajouter) commence par « : », MediaWiki rajoute un retour ligne au début du résultat, ce qui avait pour effet de casser les liens… Après réflexions, la meilleure solution que j'ai trouvée a été d'utiliser un sous-modèle, comme ça on peut mettre des « 1= » et « 2= » dans le modèle parent, qui ont pour effet de trimmer les paramètres transmis au sous-modèle.
• Vu comment ça complique le code, j'essaie d'implémenter les "safesubst" le moins possible. Mais si tu en as l'utilité, je viens de regarder et oui, ça peut se faire.
• C'est un modèle potentiellement utilisé un grand nombre de fois sur certaines pages, donc s'il existe une méthode n'utilisant pas Lua mais des modèles légers, et qui reste néanmoins fiable et simple, je pense que c'est à privilégier. Évidemment, si le modèle est substé et donc exécuté seulement lors de sa publication, cette question des performances ne se pose pas ; mais c'est un modèle qui est prévu à la base pour des utilisations où il n'est pas substé.

En somme, je pense qu'il suffit de rendre {{Lien préfixé avec un deux-points}} substable, et ça devrait le faire.

od†n ↗^blah 11 octobre 2022 à 23:12 (CEST)

Je viens de rendre ce modèle substable, voir mes modifs sur Modèle:Lien préfixé avec un deux-points et Modèle:Lien préfixé avec un deux-points/main. od†n ↗^blah 11 octobre 2022 à 23:27 (CEST)

Eh bien merci beaucoup d'avoir pris le temps de me lire, d'étudier la question, de me répondre très clairement, et d'avoir modifié le modèle en conséquence. Si l'ajout des safesubst ne crée pas d'effet de bord, c'est parfait.

Par conséquent {{Lien sûr}} peut être supprimé (le titre était pourri mais j'étais content de ma petite expression régulière 🤓 — mais j'ai bien compris le problème lié à l'inclusion massive de ce modèle en non substé).

Sinon question bête, il y aurait moyen de renommer {{Lien préfixé avec un deux-points}} en quelque chose d'un peu plus concis ? Genre {{Lien avec :}} ; je pense que le caractère « : » passe dans un titre de modèle, mais sinon {{Lien avec deux-points}} ? Sinon ce n'est pas grave.

Cordialement. — Hr. Satz 12 octobre 2022 à 00:39 (CEST)

Je serais d'avis de conserver le nom actuel. Tu te doutes bien qu'à l'époque j'avais longuement réfléchi au nom du modèle 😉

Il s'agit d'un modèle "technique" n'étant pas destiné à être utilisé par les rédacteurs, mais à être employé dans d'autres modèles, donc la longueur du nom n'est pas trop importante (bien entendu en restant dans le raisonnable) ; en revanche, au vu de la grande spécificité de sa fonction, il m'a paru important que son nom le décrive précisément.

J'ai donc cherché un nom décrivant la fonction du modèle sans ambiguïté, tout en restant de longueur acceptable. Je trouve que toute suppression dans le nom actuel rend celui-ci moins descriptif ou plus ambigu.

od†n ↗^blah 12 octobre 2022 à 08:13 (CEST)

Bonjour. Oui tu as raison, je n'avais pas vu les choses sous cet angle (modèle technique pas destiné aux rédacteurs) qui permet d'avoir un nom vraiment descriptif, même si un peu long. Je vais l'utiliser sous ce nom alors. Merci ! — Hr. Satz 12 octobre 2022 à 14:11 (CEST)

Doublon

Merci d'avoir viré ce doublon sur le bistro. C'est pas la première fois que ça m'arrive, c'est un bug lié à l'éditeur rapide : tu saurais où signaler ça ? Bonne soirée ! levieuxtoby ^{✍ · w (il/lui)} – le 20 octobre 2022 à 22:21 (CEST)

Pas de souci. Pour ce qui est de ces outils, et à plus forte raison sur mobile, j'imagine qu'ils ne sont peut-être pas encore totalement stables. od†n ↗^blah 20 octobre 2022 à 22:27 (CEST)

commons.js

Merci d'avoir optimisé les scripts que j'utilise ! Je t'avoue que c'est du charabia pour moi alors je te fais entièrement confiance . Bonne journée — Pharma ^💬 27 novembre 2022 à 13:00 (CET)

Gadget javascript

C’est évidemment tout à fait envisageable, il y a même d’autres infos intéressantes à ajouter comme la date de naissance pour les biographies (j’ai tendance à préférer faire ça en sparql pour ce genre de truc, mais dans bien des cas c’est kifkif)

Le souci c’est que les gadgets javascript c’est souvent confidentiel et que les catégories offrent assez de de flexibilité pour naviguer. Par exemple avec un affichage comme celui de mon modèle on peut facilement trier sur la colonne année de naissance si on la rajoute, on fait d’une pierre plusieurs coup, alors que naviguer dans une catégorie ça se fait page par page. C’est plus rapide à afficher, certes, après pas forcément plus rapide à utiliser dans tous les cas. — TomT0m ^[bla] 17 décembre 2022 à 09:57 (CET)

Pour info j’ai entamé un travail pour avoir des informations sur les catégories de métier sur Wikipédia et les genre (travail en cours) dont les résultats actuels sont consultables ici (en principe, me dire si le lien ne fonctionne pas).

J’ai essayé de trouver les catégories de métiers sur Wikipédia grâce à Wikidata. Il y en a un certain nombre, dont quelques une très peuplées et beaucoup de catégories pas peuplées. Je dis "peuplé" dans le sens soit la catégorie a plein de personne qui exercent ce métier sur Wikidata, potentiellement la catégorie elle même est vide mais ses sous-catégories le sont pas.

Je sais que la requête fonctionne dans tous les cas, de mémoire, pour le métier "avocat", il n’y a qu’une dizaine de catégorie de métier plus "peuplé" que avocat, donc c’est possible de faire une liste manuelle de cas particuliers sans problèmes. — TomT0m ^[bla] 17 décembre 2022 à 10:43 (CET)

Modèle:Infobox Société 

Bonjour Od1n, ta modification a entraîné une inflation de drapeaux non reconnus dans Catégorie:Page du modèle Drapeau comportant une erreur, Remy34 (discuter) 10 février 2023 à 14:12 (CET)

Bonjour, cela vient en fait de cette modification. Quand un wikilien (au lieu d'un nom de pays seul) est transmis à {{Drapeau2}}, cela n'était déjà pas reconnu auparavant, mais la catégorisation ne fonctionnait pas (au lieu de cela, ça affichait du texte inopiné « [[Catégorie:Page du modèle Drapeau comportant une erreur|France]] » sur la page).

Ainsi, les pages utilisant l'{{Infobox Société}} avec un wikilien dans le paramètre siège (pays) se retrouvaient déjà auparavant avec un «  ????? » dans l'infobox, mais elles n'étaient pas catégorisées (au lieu de cela, elles avaient en plus le texte inopiné mentionné précédemment).

Et forcément, la présence de paramètres siège (pays) avec un wikilien au lieu d'un texte seul n'a rien de surprenant, vu que le paramètre siège (ville) juste au-dessus reçoit quant à lui un wikilien…

od†n ↗^blah 10 février 2023 à 22:39 (CET)

Merci pour l'explication, bon ça fait du nettoyage à faire :)--Remy34 (discuter) 10 février 2023 à 23:29 (CET)

J'envisage de permettre la saisie d'un lien, ce qui serait appréciable pour les rédacteurs. od†n ↗^blah 10 février 2023 à 23:33 (CET)

Bonsoir. Je viens de nettoyer la catégorie. Je signale qu'il n'y avait pas que des liens. Aussi des modèles de drapeau ou à la fois la ville et le pays. --FDo64 (discuter) 11 février 2023 à 00:37 (CET)

Bonjour @Od1n. Je vois passer tes modifs [8] sur {{Infobox Société}}. Puisqu'une seule regex est un enfer, pourquoi ne pas découper l'opération en deux regex ?

Du genre {{remplace|{{remplace|{{{siège (pays)|}}}|^%[%[.-{{!}}(.-)%]%]$|[[%1]]|plain=false}}|^%[%[(.-)%]%]$|%1|plain=false}} ? --Golmote (discuter) 11 février 2023 à 12:42 (CET)

Bonjour, j'avais aussi pensé à cette solution, mais ça me gênait d'avoir un code aussi long et de faire deux appels à Lua, pour quelque chose que je pensais simple au départ. D'ailleurs, dans le code que tu as posté, l'ordre d'exécution des remplacements est à respecter (il faut remplacer « foobar (pays)|foobar » avant « foobar »), c'est le genre de "fragilité" qui me gêne un peu.

Et effectivement, dans un cas comme par exemple « [[Maurice (pays)|Maurice]] », ce que nous voulons prendre c'est le deuxième « Maurice ». Même si un tel cas de figure de lien n'était présent qu'une seule fois et que FDo64 l'a traité. Mais ça me gênerait de supporter les liens « [[foobar]] » mais pas les liens « [[foobar (pays)|foobar]] »…

Du coup, ça m'a fait revoir ma position sur cette idée, et je me dis qu'elle n'est pas si bonne, elle est peut-être un peu trop "magique". Quelque chose d'un peu moins magique, serait en cas de saisie d'un lien, d'afficher ce lien tel qu'il a été saisi, mais en plus d'essayer de détecter le nom du pays dans ce lien et de préfixer le drapeau avec {{Drapeau}}, si la détection réussit.

od†n ↗^blah 11 février 2023 à 15:34 (CET)

@Od1n c'est sûr qu'à maintenir, c'est pas fou. Ta dernière proposition est intéressante, mais sans passer par un Module Lua dédié ça semble être un enfer aussi non ? D'autant qu'il n'est pas possible, je crois, de détecter si l'appel à {{Drapeau}} a effectivement trouvé un drapeau ou pas.

Bon après, j'admets ne pas bien connaître l'écosystème des drapeaux sur Wikipédia, ça a l'air d'être un peu le bazar entre {{Drapeau}}, {{Drapeau2}}, Système Country... Ça donne à la fois envie de WP:TNT le tout et absolument pas envie d'y toucher. --Golmote (discuter) 11 février 2023 à 16:02 (CET)

Après être tombé sur cette discussion, il existe déjà des codes pour faire ce que je cherchais : Module:Biblio/Commun.nettoyageTexte() et Module:Delink (modèle {{Delink}}). od†n ↗^blah 20 février 2023 à 03:33 (CET)

Comme du coup il y a simplement un modèle à ajouter, je viens de le faire : 201564199. À propos, ce modèle {{Delink}} aurait besoin d'être documenté, et le Module:Delink aurait peut-être besoin d'être mis à jour depuis la version anglophone (mais la tâche semble difficile, car depuis le fork initial, chacun des modules a évolué de son côté). od†n ↗^blah 20 février 2023 à 03:41 (CET)

Paramètre de Modèle:Accueil actualité/Affichage

Bonjour,

J'ai ajouté le paramètre pour que mon bot puisse faire l'expansion des modèles lorsqu'il copie le contenu vers {{Accueil actualité/Copie protégée}} (présentation de l'idée).

En théorie, je pourrais faire l'expansion des modèles en simulant n'importe quel titre pour la page actuelle. "Wikipédia:Accueil principal" serait le choix évident. Cependant, je voudrais utiliser le titre du modèle lui-même ("Modèle:Accueil actualité") pour qu'il soit plus difficile de commettre un vandalisme affectant uniquement l'expansion par bot en étant invisible sur la page d'origine.

Le problème est que cette méthode est incompatible avec un test basé sur le nom de la page courante dans {{Accueil actualité/Affichage}}.

Orlodrim (discuter) 24 février 2023 à 20:14 (CET)

Je vois, merci pour les explications claires. Du coup j'ai annulé les deux modifs. od†n ↗^blah 24 février 2023 à 22:50 (CET)

Special:AbuseFilter/380

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)

L'élargissement de la résolution du paramètre ean est proposé à la discussion

Bonjour

Dans les modèles qui dépendent du module:Biblio/Références, le paramètre ean génère un lien vers la page spéciale Ouvrages de référence, dont l'intérêt est réduit aux livres alors que le code-barres EAN concerne tout type de bien de consommation (ou presque).

Le remplacement, dans le code du module:Biblio/Références, du lien généré vers la page spéciale Ouvrages de référence par la résolution de la valeur sur le site ean-search.org est proposé à la discussion.

N'hésitez ni à y participer ni à déposer l'invitation sur d'autres pages de discussion.

Accéder au débat

LeFit (discuter) 19 juin 2023 à 21:08 (CEST)

Need your input on a policy impacting gadgets and UserJS

Dear interface administrator,

This is Samuel from the Security team and I hope my message finds you well.

There is an ongoing discussion on a proposed policy governing the use of external resources in gadgets and UserJS. The proposed Third-party resources policy aims at making the UserJS and Gadgets landscape a bit safer by encouraging best practices around external resources. After an initial non-public conversation with a small number of interface admins and staff, we've launched a much larger, public consultation to get a wider pool of feedback for improving the policy proposal. Based on the ideas received so far, the proposed policy now includes some of the risks related to user scripts and gadgets loading third-party resources, best practices for gadgets and UserJS developers, and exemptions requirements such as code transparency and inspectability.

As an interface administrator, your feedback and suggestions are warmly welcome until July 17, 2023 on the policy talk page.

Have a great day!

Samuel (WMF), on behalf of the Foundation's Security team 8 juillet 2023 à 01:02 (CEST)

A propos du modèle >> Modèle:Date de naissance

Bonjour Odin, Est-ce qu'il y a un emploi de ce modèle pour les non-voyants ? Est-ce qu'il faut privilégier celui de {{date-| ? Et enfin, question que j'ai posé à l'Atelier d'accessibilité (sans réponse) pourra-t-on avoir un jour le lien interne sur les dates pour voyants et non-voyants ? Bonne journée et cordialement, Mike d 6 septembre 2023 à 06:35 (CEST)

Bonjour,

Avec la suppression récente des liens, tous les avantages à continuer d'utiliser les modèles ont déjà été listés dans une discussion, mais là je ne saurais la retrouver…

Au l'aune de l'ère des machines (IA) qui consultent aussi les contenus, je te conseille de continuer d'utiliser {{date}}, qui balise clairement les dates, et plus encore {{date de naissance}} lorsque c'est applicable, qui permet aussi d'indiquer qu'il s'agit de dates de naissance. Personnellement j'utilisais {{date-}}, et du coup je dois maintenant passer à {{date}}.

Pour ce qui est d'avoir quand même les liens chez certaines personnes, ce n'est malheureusement pas possible techniquement (et c'est bien là le problème, sinon on n'aurait pas toutes ces histoires) : on est obligé de servir le même contenu à tout le monde ; tout ce qu'on peut faire c'est modifier l'affichage avec du CSS, ou bidouiller avec du JavaScript (MediaWiki:Gadget-AffMasLiens, code), mais cela ne permet pas traiter le problème fondamental qui est de servir les dates sous forme de liens ou non.

od†n ↗^blah 6 septembre 2023 à 07:29 (CEST)

Merci. Est-ce que le modèle {{date}} est consultable par les non- et malvoyants ? Les machines à IA c'est un grand danger : En Amérique, il y a un bonze qui donne des conférences (sur les potentiels dangers des IA) et les gens de la Silicon Valley vont le voir. Je propose qu'on inscrive les instances dirigeantes de Wikipédia. Mike d 6 septembre 2023 à 07:43 (CEST)

Je ne sais pas s'il y a un avantage pour les malvoyants, mais je ne pense pas : avec ou sans le balisage <time> supplémentaire, ça devrait lire le texte de la même façon (en revanche peut-être que le retrait des liens les a aidés, en désencombrant de ces liens moins pertinents que les autres). Mais qui peut le plus peut le moins, il y a d'autres utilisations, et à l'avenir ça devrait servir de plus en plus.

Par exemple, si on raisonne à la marge, et pour en revenir aux IA, ça pourrait leur permettre de comprendre dans les structures de textes ce qui est une date (et aussi par exclusion ce qui ne l'est pas), leur apprenant ainsi à mieux détecter les dates dans les textes d'autres sites où il n'y a aucun balisage.

od†n ↗^blah 6 septembre 2023 à 09:07 (CEST)

Alors, que faire ?! Dans les deux cas, la page 1925 est-elle accessible ? Mike d 6 septembre 2023 à 09:18 (CEST)

Si ces liens ont été supprimés, ce n'est pas pour des raisons d'accessibilité, mais parce que ces liens ont été jugés peu pertinents (et donc "polluent" les liens pertinents). C'est discutable, mais Wikipédia:Sondage/Liens internes sur le modèle Date a révélé un consensus clair.

Là où l'accessibilité rentre en compte, c'est quand on parle de continuer à mettre des modèles alors qu'ils ne font plus grand chose en apparence.

Donc oui, il est maintenant plus difficile de se rendre sur les pages d'éphémérides, puisqu'il faut y aller "manuellement". Et oui, il y a des déçus, notamment ceux qui travaillent sur ces pages. Mais encore une fois, il y a eu un consensus assez clair pour supprimer ces liens…

od†n ↗^blah 6 septembre 2023 à 23:09 (CEST)

Encore une fois, je vois que l'on a oublié les mal-voyants dans ce sondage. Alors dis-moi, quels modèles doit-on utiliser maintenant sur Wikipédia ? Quelle est la recommandation ? Mike d 7 septembre 2023 à 03:13 (CEST)

J'ignorais tout de ce sondage. Le modèle date+ est annoncé mais n'a pas été créé. Mike d 7 septembre 2023 à 03:14 (CEST)

{{Modèle:Infobox Ville de Croatie}}

Salut, je cherche à améliorer un peu cette infobox en faisant appel aux données de wikidata. Je rencontre un probléme avec l'appel des données non numérique de supercifie qui revoit une information en rouge km²km². Aurais-tu une solution ? Cordialement Pªɖaw@ne 8 septembre 2023 à 14:26 (CEST)

Bonjour, je ne sais pas trop, peut-être plutôt demander sur Discussion Projet:Modèle et/ou sur Discussion Projet:Scribunto ?

(à propos j'ai remarqué un piège : j'ai testé vite fait sur la première page liée, Dubrovnik, et ça a retourné deux valeurs : « 142,6 km2 et 12,1 km2 »… c'est un cas de figure auquel il faudra aussi penser)

od†n ↗^blah 11 septembre 2023 à 08:46 (CEST)

Bonsoir Padawane , je me permets d'intervenir.

La syntaxe habituellement utilisée dans les infobox utilisant le meta-modèle {{Infobox Subdivision administrative}} est la suivante :

{{Wikidata|P2046|{{{superficie|}}}|displayformat=raw|numval=1}}

Voir, par exemple, {{Infobox Ville de Lituanie}}.

Si ça peut aider... --FDo64 (discuter) 11 septembre 2023 à 21:39 (CEST)

L'admissibilité de l'article « Modèle:Liste éléments » est débattue

Page proposée au débat d'admissibilité

Bonjour,

L’article « Modèle:Liste éléments ^{(page supprimée)} » 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 modèle:Liste éléments/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

LD (d) 2 octobre 2023 à 06:20 (CEST)

L'admissibilité de l'article « Modèle:· » est débattue

Page proposée au débat d'admissibilité

Bonjour,

L’article « Modèle:· ^{(page supprimée)} » 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 modèle:·/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

LD (d) 2 octobre 2023 à 06:20 (CEST)

Modif sur Module:Biblio/Lien web casse les modèles utilisant {{Méta base Culture}}

Bonjour Od1n.

Juste pour te signaler que l'une des tes modifications d'aujourd'hui sur Module:Biblio/Lien web a cassé les modèles utilisant {{Méta base Culture}} (tels que {{Base Mérimée}}, {{Base Palissy}}, etc.) quand le titre de la notice n'est pas saisi. Exemple :

• Notice n^o PA00086780, base Mérimée, ministère français de la Culture
• « Cimetière de l'Est », notice n^o PA00086780, base Mérimée, ministère français de la Culture

Je n'ai pas investigué plus avant.

Cordialement. — Hr. Satz 24 novembre 2023 à 19:27 (CET)

Petite précision : le problème survient en fait partout où {{lien web}} est utilisé en renseignant description= mais pas titre= :

• Page d'accueil de Google
• « Google », page d'accueil

— Hr. Satz 24 novembre 2023 à 22:03 (CET)

Effectivement… j'étais resté sur le principe que le paramètre "titre" est obligatoire (comme stipulé dans la documentation de {{Lien web}}), et à force de m'être penché sur cette partie du code, j'en avais complètement oublié la suite.

Il s'avère que le paramètre "titre" peut être omis lorsqu'un paramètre "description" est présent (refs 116130104) ; et à première vue cela me semble pertinent, car on peut trouver des cas (comme tes exemples) où le lien n'a pas vraiment de titre (dans le sens d'un titre d'article de presse par exemple), mais plutôt une description. Et dans ce cas on n'encadre pas de guillemets, ce qui convient parfaitement.

J'ai réparé cela dans le module, merci pour le signalement.

od†n ↗^blah 24 novembre 2023 à 22:54 (CET)

Merci beaucoup pour ta réactivité, c'est top ! Oui tu as parfaitement résumé la situation pour la description sans titre, ça arrive même si ce n'est pas courant. Et merci d'avoir sorti les guillemets du lien, ça fait un moment que je voulais le proposer en me disant que personne n'allait être d'accord de toute façon. Avantages : si le titre commence ou termine par des guillemets, c'est plus clair, et si l'auteur contient un lien interne, on fait mieux la distinction entre ce lien interne et le lien externe. Que du bon dans ta modif ! — Hr. Satz 25 novembre 2023 à 10:05 (CET)

Problème Modèle:Infobox V3/Tableau Ligne données

Bonjour @Od1n,

Je viens de voir qu'on a un problème avec le modèle Modèle:Infobox Notes de jeu vidéo depuis quelques jours. Il semblerait que cela coïncide avec les modifs que tu as faites sur le Modèle:Infobox V3/Tableau Ligne données. N'y comprenant pas grand chose je ne sais pas trop comment régler le problème, pourrais-tu m'aider ? Goombiis •~Δ~• 1 décembre 2023 à 23:54 (CET)

Bonjour Goombiis, vu que j'ai effectué récemment cette correction le problème est-il encore présent ? od†n ↗^blah 2 décembre 2023 à 00:30 (CET)

Je viens de vérifier, c'était effectivement le même problème que celui signalé dans cette discussion. C'est maintenant corrigé. od†n ↗^blah 2 décembre 2023 à 00:37 (CET)

@Od1n Effectivement c'est corrigé. Merci pour ta réactivité :D Goombiis •~Δ~• 2 décembre 2023 à 00:50 (CET)