Discussion utilisateur:Od1n — Wikipédia

3 colonnes[modifier le code]

Salut,

Bon OK, j'avais effectivement inversé les lignes et les colonnes (mal réveillé, surement Émoticône), 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)[répondre]

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 :
od†n ↗blah 30 août 2018 à 21:04 (CEST)[répondre]

Modèle:Infobox Société [modifier le code]

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

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 « Drapeau ????? » 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)[répondre]
Merci pour l'explication, bon ça fait du nettoyage à faire :)--Remy34 (discuter) 10 février 2023 à 23:29 (CET)[répondre]
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)[répondre]
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)[répondre]
Bonjour @Od1n. Je vois passer tes modifs [1] 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)[répondre]
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)[répondre]
@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)[répondre]
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)[répondre]
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)[répondre]

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)[répondre]

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)[répondre]

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)[répondre]

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)[répondre]

L'élargissement de la résolution du paramètre ean est proposé à la discussion[modifier le code]

Bonjour Émoticône

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.

LeFit (discuter) 19 juin 2023 à 21:08 (CEST)[répondre]

Need your input on a policy impacting gadgets and UserJS[modifier le code]

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)[répondre]

A propos du modèle >> Modèle:Date de naissance[modifier le code]

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)[répondre]

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)[répondre]
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)[répondre]
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)[répondre]
Alors, que faire ?! Dans les deux cas, la page 1925 est-elle accessible ? Mike d 6 septembre 2023 à 09:18 (CEST)[répondre]
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)[répondre]
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)[répondre]
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)[répondre]

Salut & merci de m'avoir notifié pour <p><br></p> et d'avoir lancé ton bot. J'essayerai d'y penser la prochaine fois.

Bonnes fêtes, LD (d) 28 décembre 2023 à 16:17 (CET)[répondre]

Pas de souci, normalement toutes les retouches ont été effectuées.
À propos, je ne suis pas très fan du CSS des galeries, car elles sont très proches du contenu au-dessus, et en revanche il y a 3 kilomètres d'espacement avec le contenu en dessous… Quelque chose d'un peu mieux réparti aurait été préférable. Mais bon, c'est au niveau du logiciel MediaWiki, donc faudra faire avec.
od†n ↗blah 29 décembre 2023 à 01:20 (CET)[répondre]
Joyeuse et fructueuse année 2024, Od1n !
Que cette année nouvelle réponde à tes espoirs, sans omettre d'ajouter quelques heureuses surprises !

--Fanfwah (discuter) 3 janvier 2024 à 04:50 (CET)[répondre]

(Photo : Jeanne Champ, reine de Paris en 1924 ; peut-être admissible d'ici un autre siècle, qui sait ?)

Bonne Année et bonne santé[modifier le code]

Mike d 3 janvier 2024 à 08:23 (CET)[répondre]

Harmonisations[modifier le code]

Bonjour Od1n.

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

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

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

Merci. — Ideawipik (discuter) 22 janvier 2024 à 14:27 (CET)[répondre]

od†n ↗blah 23 janvier 2024 à 00:27 (CET)[répondre]

Bug du modèle Liens[modifier le code]

Salut, il y a depuis peu la ligne Échec lors de la sérialisation des données qui apparaît en liens externes. Sais-tu de quoi cela peut venir ? Bien à toi. Enrevseluj (discuter) 27 janvier 2024 à 16:41 (CET)[répondre]

Salut, je n'ai pas retrouvé cette erreur dans les pages sur lesquelles tu es dernièrement intervenu, et je n'ai pas trouvé de modification problématique dans les modules en rapport avec {{Liens}}. Plutôt signaler cela au Discussion Projet:Scribunto, ou à la rigueur sur Discussion Projet:Modèle qui est davantage actif, si tu es en mesure de montrer comment reproduire l'erreur ? od†n ↗blah 27 janvier 2024 à 20:51 (CET)[répondre]

Conventions typo[modifier le code]

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

Bonjour, pas de souci pour l'annulation, et merci pour les explications. C'est simplement que dans les articles portant sur les sites web, que j'ai parcourus au fil du temps, j'ai fréquemment constaté que le nom du site n'est pas en italique. J'ai retiré cet italique du modèle après avoir constaté que {{YouTube}} n'écrit pas « YouTube » en italique (et, je pense, plutôt à raison), tandis que {{Lien web}} applique l'italique automatiquement (et surtout sans pouvoir le défaire, sauf avec une bidouille que j'expose plus loin dans ce message). N'ayant rien trouvé dans les conventions typo au sujet de l'italique pour les sites web, avant de retirer l'italique, j'avais consulté divers articles sur des sites web, confirmant bien que la plupart du temps le nom du site n'y est pas écrit en italique.
De plus, je viens à nouveau de survoler quelques pages de rapports wstat.fr, et j'ai le sentiment que dans pas mal de nombreux cas, l'italique n'est vraiment pas souhaitable. Ne serait-ce que lorsque c'est un domaine brut qui est saisi (e.g. « site=www.example.org »), mais les cas de figure sont vraiment variés (et nombreux, au vu de l'immense quantité d'utilisations du modèle). Par ailleurs, il existe conjointement le paramètre "périodique", pour lequel la mise en italique automatique fait quand même davantage sens.
Tu remarqueras dans le code du module qu'il y a parfois des <i>...</i> et parfois des <span class="italique">...</span>. La différence est que le deuxième permet d'annuler les italiques… en en plaçant d'autres à l'intérieur (voir code). Mais c'est un mécanisme prévu pour les citations, là c'est un "usage détourné" qui relève de la bidouille. Tout cela pour dire qu'un paramètre du genre site en italique=non serait peut-être pertinent.
od†n ↗blah 12 février 2024 à 22:38 (CET)[répondre]
Il y du flou à ce sujet : le fameux « usage flottant » qui oblige un projet à adopter une règle par souci de cohérence générale. Le pilier des conventions typo ne l'abordant pas car ayant cessé d'être mis à jour avant l'explosion d'Internet, on a regardé à l'époque — il y a plus de 15 ans ! — ce qui se faisait dans les autres ouvrages et organismes de référence. La quasi totalité préconisant l'italique pour toutes les publications, qu'elles soient physiques ou numériques (y compris les titres de logiciels), on a logiquement choisi cette présentation puisque les champs concernés peuvent accueillir soit le titre officiel de la publication, soit son édition numérique. Il est en effet moins gênant qu'un nom de domaine soit en italique plutôt qu'un titre de périodique ne le soit pas, les CT étant pour le coup parfaitement claires à ce sujet. Ajoutons à cela que selon la documentation, le nom du site doit être indiqué sans les www. (perso, je les supprime dès que je tombe dessus) ; on peut donc de fait le considérer comme un titre à part entière. Peut-être conviendrait-il de consigner enfin ce choix dans les CT, même s'il s'est imposé jusque-là sans problème ? V°o°xhominis [allô?] 13 février 2024 à 12:34 (CET)[répondre]
PS : Pour ce qui est de Youtube, c'est une de tes modifications qui a supprimé l'italique il y a plus de dix ans, alors qu'elle est prévue dans la plupart des autres modèles renvoyant vers des publications numériques (ex. {{ADS titre}}, {{Imdb titre}}etc.). C'est le souci d'être un Ancien : on finit par oublier ce qu'on a fait il y a des siècles ! Personne n'a réagi (perso je n'utilise pas le modèle) donc ça a perduré. On n'a même pas retoqué la « graphie particulière » pourtant contraire aux usages… Songeur V°o°xhominis [allô?] 13 février 2024 à 12:34 (CET)[répondre]
Il y a justement {{Italique si non précisé}} que j'ai récemment créé pour un autre chantier, et dont le module sous-jacent peut aussi être utilisé par d'autres modules. Avec {{Lien web}}, cela fait que le paramètre continuerait d'être mis en italique automatiquement, et si le rédacteur met une valeur "libre" avec seulement une partie en italique, ce formatage serait préservé (actuellement, le formatage est inversé : ce qui est saisi en italique est affiché en romain, et inversement). En revanche, il ne serait plus possible de supprimer entièrement l'italique, puisque |site=valeur (le cas habituel) continuerait de toute mettre en italique, et la bidouille |site=''valeur'' conserverait l'italique au lieu de l'inverser comme actuellement.
Après un rapide survol des résultats wstat.fr, dans la très grande majorité des cas l'ajout d'italiques semble être pour effectivement afficher en italique (donc actuellement l'affichage est erroné, vu qu'il est inversé), mais j'ai quand même repéré quelques cas où l'intention est bien la "bidouille" pour inverser l'affichage. Rien d'insurmontable à ce niveau : malgré le nombre gigantesque d'utilisations du modèle, il n'y a "que" quelques milliers d'utilisations avec des italiques saisies dans le paramètre, et de toute façon juste en mettant en place le "italique si non précisé", on corrigerait davantage d'utilisations que l'on en dégraderait, et la syntaxe serait moins surprenante pour les utilisations futures.
Le problème majeur, et pour lequel je ne vois pas vraiment de solution, serait l'impossibilité de désactiver entièrement l'italique, comme j'ai expliqué précédemment.
od†n ↗blah 14 février 2024 à 19:59 (CET)[répondre]
J'ai entretemps pensé à la création d'un modèle {{pas en italique}}, permettant d'afficher son contenu en romain même dans un champ automatiquement formaté en italique ; j'étais sur le point de le créer, mais j'ai remarqué que cela existe déjà : {{noitalic}} (edit : j'ai renommé {{noitalic}} en {{pas en italique}}, l'ancien nom restant bien entendu utilisable).
Pour résumer la situation :
Code Résultat actuel En implémentant le module "italique si non précisé"
site = truc muche truc muche truc muche
site = ''truc muche'' truc muche (beurk, c'est inversé) truc muche
site = ''truc'' muche truc muche (beurk, c'est inversé) truc muche
site = truc {{pas en italique|muche}} truc muche truc muche
L'implémentation du "italique si non précisé" permettrait d'arriver à une situation plus saine, avec l'affichage de résultats moins surprenants, et la correction de la plupart des utilisations avec des italiques saisis manuellement. Le seul inconvénient étant une régression sur les quelques utilisations reposant sur le mécanisme "inversé", et on peut s'amuser à les chercher et les corriger grâce au listing wstat (exemple de recherche).
Voilà pour la partie technique. La partie qui devrait davantage t'intéresser, et qui relève plus de ton ressort, serait effectivement la formalisation de la typographie.
od†n ↗blah 14 février 2024 à 22:23 (CET)[répondre]
Hello. Merci beaucoup pour tes propositions qui sont en effet des pistes intéressantes (la partie technique m'échappe totalement bien que j'essaie de m'y intéresser !), surtout celle qui consisterait à désactiver ponctuellement si nécessaire l'italique par défaut. Mais il faut visiblement clarifier le statut des sites internet car, à la lecture de certains avis et bien que cet usage soit en vigueur depuis quasiment l'origine du projet, la notion de « publications » est sujette à débat. A suivre donc, en espérant trouver des sources explicites incontestables pour trancher - ce qui n'est malheureusement pas le cas dans celles qui servent de fondements aux CT - ou à défaut conserver le consensus actuel, étant donné les implications à l'échelle du projet. Émoticône -- V°o°xhominis [allô?] 17 février 2024 à 15:29 (CET)[répondre]
Refs la discussion récente sur le sujet : Discussion modèle:Lien web#Paramètre site. od†n ↗blah 17 février 2024 à 16:25 (CET)[répondre]
Histoire de rester dans le sujet, je viens de tomber par hasard sur {{Allociné série}} qui, contrairement à {{Allociné titre}}, affichait les titres des séries… en romain ! Pour le coup, il n'y a pas de doute puisque le but du modèle est bien d'afficher le titre des séries et que l'italique est donc la norme. Je me suis donc basé sur ton code du second modèle pour corriger le premier, mais si tu veux jeter un coup d'œil… Émoticône V°o°xhominis [allô?] 17 février 2024 à 20:20 (CET)[répondre]
J'ai implémenté {{italique si non précisé}} dans ces modèles.
En raison du terme « précision » il pourrait y avoir une confusion entre {{italique si non précisé}} et {{titre sans précision}}, et je suis chagriné de quand même ajouter l'appel Lua lorsque c'est la valeur par défaut {{titre sans précision}} qui est utilisée, parce que dans ce cas une simple mise en italique ferait l'affaire. Mais bon, c'est ce que j'ai de mieux à proposer pour l'instant, autrement on complique le code des modèles.
Si tu veux, il y en a plein d'autres à traiter : {{Imdb titre}}, {{Imdb épisode}}, {{Imdb récompense}}, {{Ann manga}}, {{Ann anime}}
od†n ↗blah 17 février 2024 à 22:59 (CET)[répondre]

L'admissibilité de l'article « DokuWiki » est débattue[modifier le code]

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

Bonjour,

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

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

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

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

Wikibreak[modifier le code]

Salut @Od1n, je te souhaite un bon wikibreak.

J'espère te revoir bientôt ; ne te démotive pas face à la montagne de choses à faire, tes modifs sont utiles et formatrices. Bon weekend, LD (d) 8 mars 2024 à 11:05 (CET)[répondre]

Bonsoir @Od1n, je me permets aussi d'en profiter pour te remercier dans ton travail acharné. Grâce à toi notre petit site reste jusqu'à présent assez présentable, merci beaucoup! Tes contributions ne sont pas forcément les plus visibles dans les modifications récentes ou le compteur d'édition, mais la complexité des fichiers que tu manipules rappelle l'importance de ce que tu as accompli. À bientôt j'éspère :) -Framawiki 8 mars 2024 à 19:36 (CET)[répondre]
Hello @Od1n, même si nous avons été souvent en désaccord par principe, je te souhaite également un bon wikibreak. Je reconnais en toi des valeurs techniques indéniables qui ont permis des belles optimisations et reposes toi bien. Je te laisse, je retourne surveiller les attaques sur wikiwix https://www.abuseipdb.com/user/142739, qui est devenu une base d'entrainements pour les robots qui pensent que les backoffice des pages archivées sont accessibles.Pmartin (discuter) 9 mars 2024 à 06:35 (CET)[répondre]
Bon repos. Il faudrait revenir avant le 1er avril par contre, sinon personne ne va me retenir de demander à réactiver le mode kikoulol... Lofhi (discuter) 12 mars 2024 à 19:54 (CET)[répondre]

Soi-disant spams[modifier le code]

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

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