Wikipédia

Discussion Projet:Modèle/Archive 2022

< Discussion Projet:Modèle
Dernier commentaire : il y a 2 ans par FDo64 dans le sujet Palette Dates
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Portail de qualité
  • Bon portail
  • Lumière sur
  • À faire
  • Archives
  • Commons

Cette page de discussion est une archive.

Cette page contient les discussions passées en lien avec le projet Modèle .
Pour intervenir sur les discussions actuelles ou pour en lancer une nouvelle, allez sur la page de discussion actuelle.

✔️ Très réservé par l'esthétisme du Modèle:Onglets portail/Religions et croyances

modifier
Dernier commentaire : il y a 2 ans4 commentaires3 participants à la discussion

Bonjour, comme dit dans le titre, je suis très réservé par l'impression visuel que laisse ces onglets de haut de page : {{Modèle:Onglets portail/Religions et croyances}}

Pourquoi avoir mis cinq onglets sur une ligne et un autre sur une deuxième ligne ? Pourquoi les titres sont-ils alignés à gauche ? Ne peut-on pas condenser les six onglets sur une seule ligne ? Ou alors deux lignes de trois onglets ??

Merci pour votre réponse. Bien cordialement.

--Sergio1006 (observateur de l'encyclopédie, responsable, libre et indépendant) 4 janvier 2022 à 00:37 (CET)

Bonjour,
Cela dépend de la largeur de votre écran, sur mon pc les 6 sont sur la même ligne.
Je pense qu'il faudrait diminuer flex-basis: 15em;, cela suffirait avec flex-basis: 11em;. — eru [Discuter] 4 janvier 2022 à 08:14 (CET)
Même réponse. --FDo64 (discuter) 4 janvier 2022 à 08:19 (CET)
@Eru et @FDo64 : oui, c'est impeccable comme cela, merci ! --Sergio1006 (observateur de l'encyclopédie, responsable, libre et indépendant) 4 janvier 2022 à 23:39 (CET)

Doublon de modèles de notification

modifier
Dernier commentaire : il y a 2 ans3 commentaires2 participants à la discussion

Bonjour et bonne année. Je vous invite à lire Wikipédia:Le Bistro/28 décembre 2021#Insistance peu productive pour une simple icône, relative à la multiplication de modèles ayant exactement la même fonction et en rapport avec le sondage Wikipédia:Sondage/Modernisation des icônes du modèle notif. Imaginons que je n'aime aucune des deux icônes mais que je veuille absolument une image (malgré le fait que l'intérêt de l'image soit très limité comme plusieurs contributeurs l'ont relevé au cours du sondage). Vais-je créer un autre modèle, et mon voisin qui a d'autres goûts créera un énième modèle ? On ne s'en sortira pas. Ces pratiques individualistes dans l'espace de discussion ne donnent pas une bonne idées des règles d'harmonisation et de consensus à appliquer dans l'espace encyclopédique (articles). J'apprécierais l'avis du projet modèle sur l'utilité du nouveau modèle, alors qu'on a à disposition, pour personnaliser cet affichage, d'autres moyens dont un CSS donné sur le bistro.
Notification, pour avis ou conseils, à quelques modélistes expérimentés (liste non-exhaustive) : Orlodrim, Od1n, FDo64, JackPotte, Tractopelle-jaune, Cantons-de-l'Est. Merci d'avance. — Ideawipik (discuter) 2 janvier 2022 à 19:52 (CET)

Bonne nouvelle année @Ideawipik ! Avoir quelques modèles de notifications différents me paraît bénéfique (un avec une flèche, l'autre avec une arobase...), mais il faut quand même garder une limite. Et effectivement une simple variation de couleur ça me semble assez léger. Néanmoins, étant des modèles grand public et l'avis différera d'une personne à l'autre. Je pense que le meilleur moyen d'en décider le sort (si on décide de les conserver ou pas), c'est de proposer ces différents modèles en PàS. -- Nemo Discuter 2 janvier 2022 à 21:09 (CET)
Pour information et invitation à vous exprimer : deux pages de discussion (PàS) sur le maintien ou la suppression de modèles :
— Ideawipik (discuter) 11 janvier 2022 à 23:06 (CET)

Bus IDFM/correspondance

modifier
Dernier commentaire : il y a 2 ans1 commentaire1 participant à la discussion

Bonjour,

Un cas très complexe pour moi, celui de {{Bus IDFM/correspondance}} concernant la gestion des wikilien avec certaines lignes de bus franciliennes. Par défaut, le wikilien généré est de type "Réseau de bus <x>#Ligne <y>" or pour les lignes Citalien et Ligne 1 du T Zen, qui sont particulières, j'aimerais que le modèle renvoie directement sur l'article dédié plutôt que vers Réseau de bus Sénart#Ligne Citalien ou Réseau de bus Sénart#Ligne Tzen 1. Comment faire ? J'ai essayé de m'inspirer de {{Bus RATP/article}}, mais le modèle IDFM gère plusieurs réseaux... Cdlt, Lyon-St-Clair [Hon hon hon] 15 janvier 2022 à 13:42 (CET)

Dispersion des modèles liés au temps

modifier
Dernier commentaire : il y a 2 ans88 commentaires4 participants à la discussion

Bonjour,
Dans cette discussion (il y a déjà quelques temps), plusieurs d'entre nous avaient identifié des problèmes de dispersion des modèles liés au temps : modèles de date, âge et durée. Je notifie les participants à cette discussion et ceux qui ont participé au traitement par bot :   Ideawipik, FDo64, Cuagga et LD.
Certains problèmes ont entre temps été traités par mes soins (modèles peu utilisés transformés en redirection), d'autres remplacés par des bots (merci aux dresseurs). L'objectif de cette section est de faire un petit point un an plus tard sur le sujet, afin de voir où on en est à présent.
Tout d'abord, une petite liste des modèles concernés :

Dans cette liste, j'ai identifié en italique les modèles qui me semblent potentiellement problématiques et sur lesquels il pourrait y avoir une action. Voici mes réflexions concernant ces modèles :

  •   {{Date de naissance2}} : ce modèle utilise des paramètres au format anglo-saxon (année-mois-jour). Il est exclusivement lié au sport (suffixage automatique "en sport"). Il me semble qu'il faudrait le renommer vers un nom plus explicite et corriger le problème de l'ordre des paramètres.
  •   {{Nbjours}} : Doublon de {{Durée en jours}} utilisé exclusivement par des articles sur le catch, avec un format de paramètres anglo-saxon. Remplacement en cours de traitement par un bot (rien de plus à faire).
  •   {{Âge}} et {{Âge en années}} : doublons au texte près. Il faudrait à mon avis fusionner les deux modèles en dotant le modèle fusionné d'un paramètre pour afficher le texte "an(s)". Par ailleurs, ces deux modèles n'acceptent pour leurs paramètres que l'ordre année-mois-jour.
  •   {{Âge en années et jours}} : N'accepte que l'ordre année-mois-jour pour ses paramètres.
  •   {{Année de décès et âge}}, {{Année de naissance et âge}} et {{Naissance décès âge}} ces modèles sont un peu différents des autres modèles d'âge, car ils présentent un age approximatif. Je ne pense pas que l'on puisse les harmoniser avec les autres, mais il me semble qu'il faudrait peut-être les renommer pour avoir des noms plus explicites. Peut-être aussi est-il possible de les fusionner car leur objectif est proche ? Notamment, les deux premiers me semblent extrêmement similaires.
  •   {{Naissance&décès âge}} : cas un peu particulier, ce modèle présente également des informations supplémentaires comme le lieu de naissance ou de décès. Son nom me semble peu explicite vis à vis de son propos.

Par ailleurs, sur les modèles qui ne me semblent pas problématiques, quelques remarques concernant leur code :

Voilà pour l'état des lieux. Mes remarques ne sont bien entendu que des pistes de réflexion, dites moi ce que vous en pensez.
Wikipédiennement, Epok__ (✉), le 16 octobre 2021 à 11:05 (CEST)

Bonjour,
Je suis d'accord, il faut réduire le nombre de modèle si possible, et les harmoniser sinon, je regarderais les détails plus tard.
J'ai mis à jour {{Date de décès-}} qui était clairement un oublie. — eru [Discuter] 16 octobre 2021 à 12:06 (CEST)
Merci beaucoup   Eru pour cette modification. Epok__ (✉), le 16 octobre 2021 à 13:19 (CEST)
« année-mois-jour au format anglo-saxon [sic] »
Juste une précision : le format année-mois-jour est le format ISO, je ne pense pas qu’une « action » soit nécessaire, surtout que le Module:Date prend en charge ce format et restitue à l’écran la date au format jour-mois-année.
Il n’y a pas de format « anglo-saxon », mois-jour-année est le format américain et jour-mois-année le format utilisé dans les autres pays dont le Royaume-Uni. — Thibaut (discuter) 16 octobre 2021 à 15:14 (CEST)
  Thibaut120094 merci pour cette précision. Toutefois, de mon point de vue, ce format, adopté par une minorité de modèles et très peu courant (pour ne pas dire inexistant) dans la vie de tous les jours des francophones reste un problème à corriger. Ne serait-ce que pour l'harmonisation entre les modèles, évitant ainsi la complexité engendrée par le fait de devoir comprendre les spécificités de ces quelques modèles. Le plus gros problème à mes yeux étant celui rencontré par les contributeurs débutants, peu au fait des particularités des modèles, qui peuvent être décontenancés par ce format en éditant une page. L'objectif étant de rester accessible au plus grand nombre, et de cacher ces spécificités techniques : ce n'est pas parce que c'est possible techniquement que l'on doit nécessairement le faire.
Wikipédiennement, Epok__ (✉), le 16 octobre 2021 à 15:44 (CEST)
Le format ISO est très utilisé en informatique et dans le traitement des données pour éviter les confusions.
Mais bon, tant qu’on ne touche pas aux modèles {{date}} et {{lien web}} ainsi qu’aux modules associés qui acceptent plusieurs formats (excepté l’horrible format américain), je ne vais pas insister. — Thibaut (discuter) 16 octobre 2021 à 18:08 (CEST)
Bonjour,
Le fait qu'il accepte année-mois-jour n'est pas un problème, le fait qu'il n'accepte que ce format peut en être un.
C'est d'ailleurs faux, le format supporté est année|mois|jour, année-mois-jour fonctionne dans {{Date de naissance}} mais pas dans {{Date de naissance2}}.
Autres problèmes de {{Date de naissance2}} :
  • L'affichage de la date avec bday en display:none devant est redondant.
  • Le nom du modèle ne vas pas puisqu'il n'est destiné qu'au sport
Le module Date gère les différents calcules demandés, convertir le modèle pour utiliser directement le module ne devrait pas poser de problème, et cela devrait permettre de supporter les deux formats année|mois|jour & jour|mois|année
Par contre, faut-il rendre le modèle générique en déplaçant en sport dans les 424 inclusions, ou le renommé en conséquence (en conservant une redirection) ?
Par exemple :
— eru [Discuter] 16 octobre 2021 à 19:29 (CEST)

{{Date de naissance et âge}}

modifier
Bonjour Epok et Thibaut120094  
J'ai fait un premier jet dans le bac à sable, le module a également eu besoin d'un ajustement : diff
Les deux formats de date sont désormais supportés : Modèle:Date de naissance2/Test.
Il ne reste que l'appel à {{Oui non}} que j'ai préféré laissé dans le modèle. — eru [Discuter] 16 octobre 2021 à 20:58 (CEST)
Bonsoir Epok et Eru  . Pour rappel/information, j'avais posté une demande de bot en 2019 pour pouvoir supprimer {{date sport}} présent sur 91 654 pages. C'est   Supertoff qui s'en était chargé. Peut-être faudrait-il faire de même pour {{Date de naissance2}} qui n'est présent que sur 394 pages ? --FDo64 (discuter) 18 octobre 2021 à 22:19 (CEST)
Ce modèle peut avoir un intérêt en dehors du sport, si on le supprime complètement il faudrait le remplacer par deux modèles, {{Date de naissance}} et {{Âge en années}}.
Je pense qu'il faudrait demander à un bot d'ajouter en sport dans les pages une fois le modèle renommé.
Après pour 394 usages actuellement c'est à voir. — eru [Discuter] 18 octobre 2021 à 22:29 (CEST)
Hello,
De ce que je vois de ce modèle : il permet d'afficher l'âge d'une personne à un instant donné. Il s'agit grosso-modo d'un modèle {{Âge}} avec du texte après la valeur. Le même rendu peut être obtenu avec une combinaison de {{Date de naissance}}, {{Âge}} et de texte brut (c'est d'ailleurs ce que fait le code du modèle). Il peut donc potentiellement être intéressant, mais c'est vrai que le réserver au sport (ce dont, au passage, ne fait nullement mention la doc du modèle) le restreint dans son usage potentiel. Mais y a-t-il d'autres endroits où il peut être utile que dans la présentation d'une équipe sportive, où l'on fait la liste des joueurs, indique leur date de naissance et leur âge à l'instant t ? À voir. Si c'est le cas, il faut effectivement le rendre générique dans la thématique comme les autres modèles, à l'aide d'un paramètre.
Pour le renommage, je serai partisan de la version {{Date de naissance et âge}}, je n'aime pas trop le "&" qui me semble artificiel pour dire "et" (ce n'est plus une phrase, mais une concaténation de termes).
Wikipédiennement, Epok__ (✉), le 19 octobre 2021 à 08:23 (CEST)
Bonjour,
J'ai ajouté dans mon message initial un nouveau problème que je n'avais pas identifié lorsque je l'ai rédigé : le modèle âge lui aussi ne respecte pas l'ordre jour-mois-année commun aux autre modèles temporels.
  Eru désolé, je me rends compte que je n'ai même pas répondu à ta proposition pour le code sur Modèle:Date de naissance2/Bac à sable. Celui-ci me semble très bien : il résout la problématique en permettant les deux ordres pour les paramètres. Y a-t-il des cas particuliers à vérifier pour s'assurer de son bon fonctionnement ? Sinon, il me semble OK pour une mise en production.
Wikipédiennement, Epok__ (✉), le 2 novembre 2021 à 09:16 (CET)
Bonjour Epok  
Pas de soucie, il faut :
  1.   Fait. Rendre le paramètre qualificatif paramétrable avec "en sport" par défaut
  2.   Fait. Appliquer le nouveau code
  3.   Fait. Mise à jour de la documentation
  4.   Fait. Renommer le modèle a priori vers {{Date de naissance et âge}}
  5.   Fait. Demander à un bot de remplacer les occurrences en mettant "en sport" dans le code de la page
  6.   Fait. Enlever la valeur par défaut "en sport"
— eru [Discuter] 2 novembre 2021 à 18:27 (CET)
  Eru : tout me semble OK, tu peux appliquer le point 2 (et 3 ?) pour garder la paternité des modifs dans l'historique et je peux me charger des points subséquents si tu le souhaites. Je ferai aussi un petit lifting de la doc pour intégrer le nouveau comportement.
Sauf si quelqu'un s'oppose à cette modif, bien sûr. Par ailleurs, le nom n'est pas tranché, même si c'est bien celui-ci qui recueille mes faveurs.
Wikipédiennement, Epok__ (✉), le 2 novembre 2021 à 21:30 (CET)
@Epok Voilà déjà pour l'application du nouveau code — eru [Discuter] 2 novembre 2021 à 22:36 (CET)
Oups, j'ai oublié les modifications du module date, cela utilise pour l'instant le bac à sable.
@Od1n : tu pourrais appliquer ces modifications : diff ? — eru [Discuter] 2 novembre 2021 à 22:49 (CET)
ps : cela a provoqué 4 pages avec des Catégorie:Page utilisant le modèle date avec une syntaxe erronée dû à des espaces en trop.
Je les ai corrigés plutôt que de rajouter un trim. — eru [Discuter] 3 novembre 2021 à 07:40 (CET)

┌──────────────────────────────────┘
   Eru je n'avais pas vu que ta modif impliquait également une modification du module Date. Je peux l'appliquer, mais en reviewant le code j'ai une petite question : pourquoi ce if args['dateNaissanceÉvénement'] and args['dateNaissanceÉvénement'] ~= '' ? Je trouve la redondance ici étonnante, mais peut-être y a-t-il une raison technique qui m'échappe ? Epok__ (✉), le 3 novembre 2021 à 09:16 (CET)
Ah non, my bad, il me manquait les parenthèses mentales if A and (A ~= '') ! Je transfère ta modif dans le module. Epok__ (✉), le 3 novembre 2021 à 09:18 (CET)

Voilà, l'intégration du module et du modèle sont faites, et la doc est à jour (il faudra peut-être mettre un TemplateData quand même). J'attends tout de même quelques temps pour le renommage, afin de vérifier que rien n'a été cassé (notamment par la modification du module Date) et de voir si il y a des propositions alternatives pour le nouveau nom du modèle. Je procèderai au renommage et à la demande de bot d'ici demain si pas d'objection ni de problème rencontré. Epok__ (✉), le 3 novembre 2021 à 09:58 (CET)
Merci, j'avais oublié que tu était admin :)
J'avais vérifié la page Modèle:Date/Test, elle est toujours ok.
Je suis d'accord que dans l'idéal il faudra un TemplateData. — eru [Discuter] 3 novembre 2021 à 18:28 (CET)
c'est fait pour le TemplateData. — eru [Discuter] 3 novembre 2021 à 19:04 (CET)
Renommage + demande de bot effectués. Epok__ (✉), le 5 novembre 2021 à 10:12 (CET)
Bonjour, je ne connaissait pas la redirection {{Birth date and age2}}, du coup je penser qu'il faudrait fusionner Q26024732 (« Modèle:Date de naissance et âge ») avec Q6438902 (« Modèle:Date de naissance et âge ») — eru [Discuter] 5 novembre 2021 à 16:43 (CET)

{{Durée}}

modifier

Bonjour,

J'ai commencé à préparer la suite avec {{Durée en jours/Bac à sable}} & {{Durée en mois/Bac à sable}} et le module durée.

Voici les pages de tests : Modèle:Durée en jours/Test & Modèle:Durée en mois/Test

Cela soulève quelques questions :

  • J'ai l'impression que l'ancien modèle {{Durée en jours}} faisait des erreurs si certaines données n'étaient pas remplies, la documention est imprécise car les 3 premiers paramètres sont obligatoires mais ont une valeur par défaut. Donc est-ce que c'est utile de le gérer ? Si oui quelle est la valeur souhaitée pour les testes 2010 4 & 5, maintenant 2 & 3 ?
  • Est qu'il faut gérer les résultats négatifs (jours & mois)) ?

— eru [Discuter] 6 novembre 2021 à 12:35 (CET)

ps : les différences doivent principalement venir du fait que le module met le jour courant si jours=0 et de même pour mois, alors que l'ancien modèle fait les calcules avec 0 — eru [Discuter] 6 novembre 2021 à 12:55 (CET)
  Eru effectivement, mais ce problème me semble un "non-problème", car d'après les utilisations actuelles de ces modèles (et la doc), les 3 premiers paramètres doivent être remplis, et le sont effectivement. Par ailleurs, la valeur "0" pour une date n'a pas de sens. Les valeurs par défaut sur "durée en jours" me semblent correspondre à la volonté de pouvoir indiquer une durée entre aujourd'hui et une date future, mais comme ce n'est pas documenté ni utilisé, je ne pense pas qu'il faille s'en préoccuper.
Pour les résultats négatifs, dans le propos de ces modèles, cela n'a pas de sens : une durée est toujours positive, donc je dirai qu'il ne faut également pas s'en préoccuper. En fait, pour ces deux modèles, je m'en tiendrai à un fonctionnement équivalent au modèle "de référence" {{Durée}} et à ce qu'il permet de faire, sans aller au-delà. L'objectif reste d'harmoniser les modèles entre eux, c'est pour cela que je proposais de faire le changement vers l'utilisation du module Durée.
Je vois que ça a l'air de fonctionner pour les durées en mois seuls ou en jours seuls, mais il me semble que l'on pourrait également proposer une durée en années seules, cela sera utile si on souhaite également passer les modèles d'âge en utilisations de ce module, ce qui me semble également pertinent. Toutefois, cette idée mais va se heurter au problème de l'ordre des paramètres, car contrairement au module Date, un seul ordre est accepté pour les paramètres du module.
Merci pour ton travail,
Wikipédiennement, Epok__ (✉), le 7 novembre 2021 à 10:25 (CET)
Merci Epok  , je suis d'accord, si cela n'est pas utilisé il suffira de clarifier la documentation.
J'ai ajouté une vérification de l'ordre des paramètres : diff
On peut ajouter un calcule en années, mais pour l'âge il existe déjà une fonction modeleAge dans Module:Date, autant l'utiliser. — eru [Discuter] 7 novembre 2021 à 12:16 (CET)
ps : en faite pour le modèle {{Durée}} les paramètres sont obligatoires, donc ce code semble inutile et pas très fonctionnel :
::::if not jour1 then
::::	precision = 'mois'
::::	jour1 = maintenant.day
::::end

::::if not mois1 then 
::::		if precision == 'mois' then
::::			precision = 'an'
::::			mois1 = maintenant.month
::::		else
::::			return erreur( 'mois invalide (' .. ( args[2] or '' ) .. ')' )
::::		end
::::end

::::if not annee1 then
::::		if precision == 'an' then
::::			return
::::		else
::::			annee1 = maintenant.year
::::		end
::::end
Il pourrait être supprimé — eru [Discuter] 7 novembre 2021 à 12:24 (CET)
  Eru Effectivement, le calcul de l'âge en années existe déjà dans l'autre module, bien vu ! Il suffira de l'utiliser.
En ce qui concerne les paramètres non renseignés, pour le modèle {{Durée en jours}}, il me semble qu'il est absolument nécessaire de tout renseigner (jour/mois/année), sinon le modèle n'est pas capable de faire son job. Pour le modèle {{Durée en mois}}, en théorie, le jour pourrait éventuellement être omis. Deux possibilités : soit on prend en charge cette possibilité, soit on considère, comme c'est le cas actuellement (doc ET usages) qu'il faut une syntaxe complète, et on simplifie le code. Je serais en faveur de la seconde possibilité : ne pas essayer d'introduire une fonctionnalité si personne n'en fait usage. Il sera toujours temps de se poser la question de l'introduction de cette possibilité si quelqu’un en fait la demande. Epok__ (✉), le 7 novembre 2021 à 12:29 (CET)
Omettre un 1 paramètre donne des résultats bizarres car il met la date du jour, et ne fonctionnait pas du tout avant : Modèle:Durée en mois/Test#1 mois
Je vais tester en commentant ce code. — eru [Discuter] 7 novembre 2021 à 12:40 (CET)
EDIT : je vois que le code dont tu parles n'est pas nouveau, mais existe déjà, my bad. À voir les utilisations du modèle {{Date}}, il semblerait que la différence d'utilisation des paramètres 1/2/3 (resp. 28120/28117/28112) et 4/5/6 (resp. 23738/23725/23721) est infime, mais existe. On pourrait essayer de retrouver les cas non complets pour voir si il s'agit d'erreurs ou d'une vraie info manquante. Dans tous les cas, le code donc tu parles me semble effectivement bancal : pourquoi utiliser la date actuelle (qui change tous les jours) comme référence pour une info manquante ? On peut se poser la question...
Epok__ (✉), le 7 novembre 2021 à 12:34 (CET)
J'ai mis 1 par défaut, cela semble plus cohérent, reste à vérifier les tests et les cas particuliers. — eru [Discuter] 7 novembre 2021 à 12:45 (CET)
J'ai refait les pages de tests pour que cela soit plus claire et complété celle du modèle durée : Modèle:Durée en jours/Test, Modèle:Durée en mois/Test & Modèle:Durée/Test
D'après wstat il n'y a pas d'usage avec des paramètres vides ni ^[0]$, il y a juste une inclusion de {{Durée en jours}} avec le paramètre 1 et c'est tout.
Il faudra aussi traiter les redirections {{Âge en mois}}, {{Age en jours}}, {{Age in days}} & {{Âge en jours}}, ce dernier étant utilisé dans 12 pages de l'espace principale. — eru [Discuter] 7 novembre 2021 à 18:11 (CET)
Encore une fois Eru, merci pour ton travail !
En ce qui concerne {{Durée en mois}}, vu le faible nombre d'utilisations, j'ai vérifié les utilisations une par une, et j'ai trouvé que l'article Liste des empereurs romains mélangeait les deux ordres de paramètres jj/mm/aaa et aaa/mm/jj... Ce qui fait que l'on avait des jours qui étaient interprétées comme des années, et cela donnait des valeurs incorrectes : ta modif va corriger ce problème. J'inclurai ta modif sur ce modèle, qui est protégé. D'ailleurs, je ne sais pas si la protection est toujours d'actualité, car il n'y a pas "un grand nombre" de pages qui l'utilisent. Pour {{Durée en jours}}, il n'est pas protégé, donc je te laisse faire la modif pour conserver la paternité des modifications. Je pense que lui, de son côté, pourrait être protégé, car on a quand même un petit millier d'utilisations, et avec le remplacement de {{nbjours}}, on en aura environ 2000. Qu'en penses-tu ?
Concernant les redirections, j'ai traité à la main tous les appels de {{Âge en jours}} dans l'espace principal.
Wikipédiennement, Epok__ (✉), le 11 novembre 2021 à 10:26 (CET)
EDIT : j'ai diminué la protection de {{Durée en mois}}, car elle me semblait disproportionnée, d'autant plus que le module lui-même est moins protégé. Tu peux donc intégrer les modifications toi-même et en garder la paternité. Epok__ (✉), le 11 novembre 2021 à 11:10 (CET)
Merci Epok  , j'ai appliqué les modifications (et vérifié Liste des empereurs romains)
Je pense qu'une semi-protection étendue est généralement suffisante tant qu'il n'y a pas de vandalism, même pour 5310 inclusions. Je n'en trouve que 124 pour nbjours.
Je vais regarder les documentations maintenant. — eru [Discuter] 12 novembre 2021 à 17:30 (CET)
  Eru super, c'est parfait, merci ! En ce qui concerne {{nbjours}}, comme l'autre fois, je fais référence au nombre d'utilisations totales au dernier dump, on a tous nos petites habitudes  . Par ailleurs, le modèle étant en cours de remplacement par un bot, il est possible que le nombre d'utilisations ait changé depuis le dernier dump. Templatecount est-il basé sur un dump, ou bien fait-il une requête SQL en temps réel ?
Epok__ (✉), le 12 novembre 2021 à 18:44 (CET)
Je ne sais pas trop, la doc dit qu'il y a une mise en cache, mais ce n'est pas dit que cela soit celui du dump. — eru [Discuter] 12 novembre 2021 à 18:47 (CET)
J'ai constaté que les versions "en jours", "en mois" et "en années" de {{Durée}} n'avaient pas le même comportement par défaut que le modèle de base. En effet, ces versions nécessitent un paramètre supplémentaire pour afficher le texte, alors que le modèle de base a bien du texte par défaut. J'ai donc proposé un changement en bac à sable du module pour inverser le comportement. J'ai testé les modèles suivants :
Par contre, cela a nécessité une petite rustine sur le code de {{Durée en jours/Bac à sable}} et {{Âge/Bac à sable}} pour conserver le comportement actuel. J'ai volontairement modifié le comportement par défaut de {{Durée en mois}}, car ce modèle n'a qu'un petit nombre d'utilisations et la totalité de celles-ci ajoutent le texte "mois" après le modèle => il sera aussi simple de modifier les utilisations.
  Eru : Questions : que penses-tu de ce changement ? Est-il souhaitable ? Par ailleurs, le code que je propose pour le module te semble-t-il correct ? En effet, ce code n'accepte que la valeur "oui" pour le paramètre "masquer texte", mais je ne savais pas comment faire autrement sans passer par un "if" n'ayant de contenu que dans son "else"...
Epok__ (✉), le 17 décembre 2021 à 09:52 (CET)
Merci Epok   J'avais effectivement vu la différence, mais j'avais conservé le comportement d'origine, c'est mieux comme cela. La documentation de {{Durée}} sera plus simple à comprendre.
J'ai vérifié, tout à l'air bon.
Il serait sans doute utile de changer l'affichage par défaut d'{{Âge}} & {{Durée en jours}} aussi, mais le nombre d'usage n'est pas le même. — eru [Discuter] 17 décembre 2021 à 17:52 (CET)
  Eru : ok, vu, je déploie donc ces modifs. Pour {{Âge}} et {{Durée en jours}}, je suis bien d'accord avec toi, mais effectivement il y a plus de boulot. Je pense que l'on pourra traiter {{Durée en jours}} par bot assez facilement, par contre pour {{Âge}}, il faudra réfléchir un peu plus avant : notamment, vu le changement de comportement, la différence avec {{Âge en années}} n'aura plus lieu d'être, donc il faudra songer à une fusion.
Epok__ (✉), le 18 décembre 2021 à 08:58 (CET)
C'est pas faux.
Je viens de voir un problème dans les tests 49 & 50 Modèle:Âge/Test, je regarde. nop c'est bon. — eru [Discuter] 18 décembre 2021 à 09:10 (CET)

{{Âge}} et {{Âge en années}}

modifier

Voila : Module:Durée/Bac à sable, Modèle:Âge/Test & Modèle:Âge en années/Test

— eru [Discuter] 12 novembre 2021 à 18:55 (CET)

@Epok Galère mais j'ai réussi à faire les calcules pour {{Âge en années et jours}}, il faut calculer le nombre de jours dans chaque mois : Module:Durée/Bac à sable & Modèle:Âge en années et jours/Test — eru [Discuter] 12 novembre 2021 à 21:42 (CET)
Il y avait en fait bien plus simple avec os.difftime, en plus le test 38 que j'ai ajouté ensuite était faux : diff — eru [Discuter] 12 novembre 2021 à 23:11 (CET)
Hello Eru  ,
Désolé pour le temps de réponse, en ce moment je suis extrêmement pris niveau boulot, et j'avoue que j'ai moins de temps à consacrer à WP...
Très beau boulot, un fois de plus, tout me semble OK. En ce qui concerne ces deux modèles, la seule différence se situant au niveau du texte, je serai partisan d'une fusion, en ajoutant un paramètre au modèle qui permettrait d'afficher ou non la mention "ans". Toutefois, ceci nécessiterait un passage de bot pour remplacer les appels au modèle {{Âge en années}}, donc à voir si le jeu en vaut la chandelle vu que de toutes façons, avec ta version, le code sera mutualisé...
Epok__ (✉), le 20 novembre 2021 à 09:33 (CET)
Pas de souci, je suis moi-même bien occupé, je viens d'ailleurs de faire une autre modification qui permettrait d'avoir un modèle pour afficher une date et l'âge ce moment, soit le contraire de
{{Date de naissance et âge}} : Discussion modèle:Infobox Biographie2#date de disparition
Pour {{Âge en années}} le paramètre existe maintenant a=oui, ainsi que en années et jours=1, donc au besoin les occurrences pourront être remplacées. L'on pourra mettre un alias pour que cela soit plus claire. Une petite modification est nécessaire : Special:Diff/188156143
Tests :
  • {{Âge/Bac à sable|1984|8|29|2010|8|1}}, {{Âge/Bac à sable|1984|8|29|2010|8|1|a=1}} & {{Âge/Bac à sable|1984|8|29|2010|8|1|en années et jours=1}}
  • 25 ans, 25 ans & 25 ans, 337 jours — eru [Discuter] 20 novembre 2021 à 10:33 (CET)
Bonjour Epok  , j'ai appliqué les modifications pour {{Âge en années}} & {{Âge en années et jours}}, {{Âge}} étant protégé je te laisse t'en occuper.
Au passage si tu peux appliquer cette modification : Module:Date/Bac à sable
— eru [Discuter] 21 novembre 2021 à 18:42 (CET)
Houlà, il semblerait que ce matin, j'ai quasiment cassé Wikipédia en appliquant ces deux modifs ! Heureusement, certains veillaient au grain et la plus grave (celle touchant le module Date) a été rapidement annulée (merci à   Ariel Provost). J'ai annulé ce soir la seconde, sur le modèle {{Âge}}, car apparemment, certains usages de ce modèle consistent à utiliser le résultat fourni par le modèle pour réaliser des calculs, et la mise en forme (balises div) appliquée par le module casse ce fonctionnement. Il faudra donc faire une nouvelle passe un peu plus approfondie avant de l'appliquer à nouveau.
wikipédiennement, Epok__ (✉), le 22 novembre 2021 à 16:46 (CET)
D'accord merci, je n'avais pas vu pour le modèle âge, je suis à l'hôtel donc je regarderai tout cela ce weekend, à commencer par des test avec {{addition}} — eru [Discuter] 22 novembre 2021 à 18:05 (CET)
Bonjour Epok  
J'ai donc enlevé le formatage s'il n'y a pas d'unité et ajouté un paramètre format si l'on veut forcer la mise en forme (probablement utilise uniquement si l'âge est supérieur à 999) : Module:Durée
Il y a 4 tests correspondants en bas de Modèle:Âge/Test
Nous pourrions faire de même pour {{Durée en mois}}, mais aucun problème n'a été signalé et il est plus probable d'avoir des valeurs supérieures à 999
Si tu penses que tout est bon tu peux appliquer la modification du modèle Âge (mais pas lundi matin   )
Par contre, je ne sais pas si cela est réellement utile, est-ce utilisé dans l'espace principal ? Je ne trouve qu'une page, mais il y a peut-être d'autres cas : Spécial:Recherche/hastemplate:addition hastemplate:âge
Il serait peut-être plus opportun d'ajout un paramètre raw et de le mettre sur les pages concernées ?
— eru [Discuter] 27 novembre 2021 à 12:22 (CET)
  Eru : J'ai commencé à regarder les utilisations du modèle, mais je n'ai jusqu'à présent effectivement trouvé aucune utilisation de ce type dans l'espace principal (mais je faisais "à la main", ta méthode est plus efficace). Il me semble qu'effectivement, un formatage par défaut serait le plus souhaitable, ce type d'utilisation restant dans tous les cas très minoritaire. Ta solution avec le paramètre raw me semble très bien, car on aura ainsi une vraie harmonisation dans le fonctionnement des modèles temporels, avec juste la possibilité de revenir à un format brut pour les cas ayant besoin d'éventuels calculs.
Epok__ (✉), le 27 novembre 2021 à 12:26 (CET)
Voila la solution avec le paramètre raw/brut dans le bac à sable Spécial:Diff/188349272 (test 46) — eru [Discuter] 27 novembre 2021 à 12:35 (CET)
ps : la recherche dans tous les domaines donne 5 pages potentiel (seul les deux pages utilisateurs sont réellement concernées), mais il peut y avoir d'autres calcules que {{addition}} je suppose. — eru [Discuter] 27 novembre 2021 à 12:46 (CET)
  Eru : yep, c'est parfait. Par contre, je me rends compte suite au remplacement d'un modèle par {{Durée en jours}} (Merci LD   pour ton bot !) que le même problème se pose sur un certains nombre d'appels de ce modèle. Ceux-ci utilisent la syntaxe {{#expr}} pour faire des calculs. J'ai temporairement annulé la modification sur la petite 20aine d'articles concernés, mais clairement, ce modèle pourrait également bénéficier du paramètre raw (liste des pages concernées ici). Est-ce que tu penses que ce que tu as fait pour les années est généralisable ? Epok__ (✉), le 27 novembre 2021 à 15:48 (CET)
@Epok aucun soucie, c'est fait : Spécial:Diff/188354563
Je m'occupe de la doc. — eru [Discuter] 27 novembre 2021 à 16:03 (CET)
  Eru : super, c'est parfait. Je confirme que tout est OK avec cette version, je viens de corriger tous les problèmes d'utilisation introduits par le remplacement du modèle {{Nbjours}} par {{Durée en jours}} (à l'exception de quelques brouillons à l'abandon). En ce qui concerne {{Âge}} par contre, je ne vais pas pouvoir m'en occuper ce week-end, car je voudrai vérifier les potentielles utilisation dans la parserfunction {{#expr}} avant, et je ne vais pas avoir suffisamment de temps car j'ai du boulot. Mais bon, on touche au but !
Bonne fin de week-end, Epok__ (✉), le 27 novembre 2021 à 17:42 (CET)
Parfait, je commencerai peut être à regarder les modèles restant. — eru [Discuter] 27 novembre 2021 à 18:06 (CET)

┌────────────────────────────────┘
 Bon, pour #expr j'ai fait une recherche avec ceci, j'espère que c'est correct (j'ai du mal avec les regex), et je trouve quelques pages utilisant la syntaxe, mais uniquement des faux positifs sur des modèles dont le nom commence par Âge. Ça m'a permis de corriger quelques erreurs qui restaient sur {{Âge en jours}} (redirection de {{Durée en jours}}), mais à priori je ne trouve rien de plus que sur addition. On pourra donc procéder à la mise à jour de {{Âge}} dès que j'aurai un peu de temps d'affilée pour rester vérifier derrière que je n'ai rien cassé après  . Epok__ (✉), le 1 décembre 2021 à 08:58 (CET)

Parfait, je te propose de le faire en début de week-end si possible, ainsi je pourrais vérifier en même temps. — eru [Discuter] 1 décembre 2021 à 18:38 (CET)
  Eru désolé, je n'étais pas chez moi et je n'ai pas trop eu de temps libre ce w-e, je vais appliquer la modif maintenant. Ne pas hésiter à me notifier en cas de problème. Notif à   LD et Ariel Provost au passage. Epok__ (✉), le 5 décembre 2021 à 14:10 (CET)
pas de souci, en début de week-end n'impliquait pas forcément ce week-end, juste pas le dimanche soir :) — eru [Discuter] 5 décembre 2021 à 14:49 (CET)
LD je viens de voir dans le diff que l'ancien modèle avait trois paramètres année, mois & jour, je regarde ce que je peux faire dans le module. — eru [Discuter] 5 décembre 2021 à 14:56 (CET)
Voilà, cela devrait résoudre le problème partout : Spécial:Diff/188578400 — eru [Discuter] 5 décembre 2021 à 15:02 (CET)
La documentation n'est pas claire sur cet usage, elle parle également de Année1 & Année2 qui n'existe pas, donc :
ps : l'usage d'uniquement année empêche l'usage des paramètres 4, 5 & 6
— eru [Discuter] 5 décembre 2021 à 15:21 (CET)
  Eru : Je viens d'aller faire un tour sur les utilisations de ces paramètres, et de ce que je vois, ils étaients utilisés pour restaurer l'ordre normal jour|mois|année, étant donné que le modèle ne supportait que année|mois|jour. Je pense que maintenant que le modèle supporte les 2 ordres, il suffirait de faire passer un bot pour enlever ces paramètres nommés, inutile de maintenir de la complexité si elle n'apporte plus rien par rapport au fonctionnement normal. La doc ne mentionne pas vraiment année1 et compagnie, mais <année1> (et compagnie), c-à-d des paramètres non nommés qui représentent l'année 1. Mais ce n'est effectivement pas forcément clair. Je passerai un coup dessus pour mettre tout ça à jour plus tard. Epok__ (✉), le 5 décembre 2021 à 15:38 (CET)
Parfait, j'ai déjà remplit le template data, il restera à clarifier le reste, la section #Paramètres peut porter à confusion. — eru [Discuter] 5 décembre 2021 à 15:42 (CET)
  Eru : concernant les paramètres année, mois et jour, je remarque qu'ils sont quasiment exclusivement utilisés par des articles concernant le volley, pour indiquer l'âge d'un joueur après sa date de naissance. Étant donné le contexte, j'ai commencé à remplacer ces appels par des appels au modèle {{Date de naissance}} munis du paramètre âge. Je préfère donc le faire à la main plutôt que par un bot, car les syntaxes varient fortement d'une page à l'autre (liens direct sans modèle date, modèle date avec un seul paramètre, modèle date avec 3 paramètres, modèle âge avec ou sans précision textuelle "ans", etc.) Ce sera donc un peu plus long que prévu, mais ça me permet d'adapter la modification au contexte. J'ai pour l'instant terminé le remplacement jusqu'à la lettre B, j'espère avoir fini ceci courant janvier, et je te préviendrai quand on pourra supprimer le support de ces paramètres dans le module. Epok__ (✉), le 12 décembre 2021 à 10:03 (CET)
Ok, pas de souci, ils ne sont pas bien génant, le templatedata n'en parle pas.
J'ai modifié Modèle:Âge/Documentation#Paramètres pour que cela soit plus claire. — eru [Discuter] 12 décembre 2021 à 10:21 (CET)

Année & Âge

modifier

— eru [Discuter] 3 décembre 2021 à 19:59 (CET)

En fin de compte j'ai commencé à regarder dans mon bac à sable : Module:Utilisateur:Eru/Date & Utilisateur:Eru/Brouillon/Modèle:Date de naissance.
Il faudra voir si l'on garde la logique précédente (pas d'âge si la date de décès est précisée, date imprécise alors que l'on connais le mois et que ce n'est pas celui en cours) ou si comme dans l'exemple on affiche effectivement toujours l'âge.
— eru [Discuter] 3 décembre 2021 à 23:16 (CET)
Du coup j'ai appliqué les modifications que j'avais préparé dans le bac à sable Spécial:Diff/188583192, cela permet de gérer les trois 1er modèles :
Reste à voir pour le dernier modèle. — eru [Discuter] 5 décembre 2021 à 18:07 (CET)
Voilà pour {{Naissance&décès âge/Bac à sable}} (test), en faisant deux appel au module date et avec quelques modifications de celui-ci : diff
Il faudra voir ce que l'on fait pour l'affichage de â avant l'âge, ce n'est pas très uniforme.
Je revérifierai tout et j'ajouterai des tests plus tard.
— eru [Discuter] 5 décembre 2021 à 19:20 (CET)
Autres points :
J'ai ajouté des équivalences dans les pages de tests, cela provoque pour l'instant des erreurs lorsqu'il n'y a que l'année, je regarderai pour les gérer au mieux. — eru [Discuter] 6 décembre 2021 à 19:31 (CET)
Voilà pour les cas précédemment en erreur : Spécial:Diff/188624129 et Spécial:Diff/188624174 (pour gérer |année|année et |||année|||année)
Attention cela peut impacter les autres modèles, il faudra tous vérifier. — eru [Discuter] 6 décembre 2021 à 19:59 (CET)
Bonjour Eru  ,
Si il est possible de remplacer ces modèles peu utilisés par les modèles "standard" munis d'un paramètre, je serai plutôt pour. Mais je vois dans les commentaires introduits par modif du module Date « les années sont dans le premier et le second paramètres ». Cela signifie-t-il que l'on accepte la syntaxe |année|année ? Si oui, ça me semble un problème potentiel, par exemple pour les année très proches de l'an 0 (avant l'an 31) qui pourraient être prises par erreur pour une syntaxe de mois. Il me semble que dans ce cas, il vaudrait mieux faire l'adaptation du paramètre par le modèle, en le mettant à la bonne place attendue par le module, et dans ce cas on ne peut pas fusionner car les modèles devront être différents.
Epok__ (✉), le 12 décembre 2021 à 09:01 (CET)
Oui, si je ne me trompe pas cela ne supporte que les années supérieures à 31.
Un remplacement par bot serait préférable je pense, il poura choisir la syntaxe la plus adéquate.
Je ne vois pas comment la fusion de modèle serait possible pour Modèle:Naissance décès âge de toute façon, pour les deux autres aussi l'ordre des paramètres risquerai de poser problème en cas de fusion.
Dans la page de test Modèle:Année de décès et âge/Test j'ai mis deux propositions de remplacement, |année|année ou |||année|||année — eru [Discuter] 12 décembre 2021 à 09:14 (CET)
ps : cela améliore le support de {{Date de décès|24 février 1993|23 juin 1920}} indiqué dans la documentation, qui faisait une erreur s'il n'y a que l'année.
  • Mois invalide (23 juin 1920)
  • Mois invalide (23 juin 1920)
Mais je vois qu'il reste une erreur avec 1993|23 juin 1920, je vais regarder cela. — eru [Discuter] 12 décembre 2021 à 09:24 (CET)
Voilà : diff — eru [Discuter] 12 décembre 2021 à 09:40 (CET)
  Eru je viens de me pencher sur {{Naissance décès âge}}, et je remarque que de (très) nombreux appels de ce modèle précisent tous les paramètres. Je pense que l'on peut commencer par remplacer ces appels par des appels à {{Date de naissance}}/{{Date de décès}} dans un premier temps, et ensuite voir ce qu'il reste. À mon avis, il n'en restera pas des masses, on pourra donc voir en détail ce qu'il convient de faire. Je vais voir s'il est possible de faire appel à un bot pour ça, ou si c'est aussi simple de faire à la main. De manière générale, pour tous les modèles cités dans cette section, il y a à mon avis pas mal de remplacements possibles par un modèle "standard", donc je ne sais pas si il est vraiment nécessaire d'alourdir le module pour si peu d'utilisations. Epok__ (✉), le 12 décembre 2021 à 13:30 (CET)
Oui, je pense que seul {{Naissance&décès âge}} est intéressant à conserver (après renommage).
Pour les autres modèles l'ajout de âge=Toujours permet d'avoir l'affichage équivalent
Je serai une bonne idée de créer une palette regroupant les modèles liées au temps, cela permettrai d'être plus complète que la section voir aussi. — eru [Discuter] 12 décembre 2021 à 14:10 (CET)
  Eru : Requête bot faite pour le modèle {{Naissance décès âge}}. En fait, il semblerait que j'avais déjà identifié l'algo à réaliser l'année dernière, mais que je ne m'en souvenais plus  ...
Pour la palette, c'est bien noté, je m'en occuperai.
Epok__ (✉), le 12 décembre 2021 à 17:58 (CET)
  Eru : voici une première proposition pour les modèles liés au temps : {{Palette Modèles liés au temps}}. Je n'ai mis que les modèles qui me semblaient "principaux" (donc notamment pas les modèles sur lesquels on travaille encore), n'hésites pas à l'enrichir si j'ai oublié des modèles majeurs. Epok__ (✉), le 12 décembre 2021 à 19:02 (CET)
Merci, il y en a que je ne connaissais pas.
On pourra ajouter {{Naissance&décès âge}}, mais mieux vaut attendre qu'il soit renommé. — eru [Discuter] 12 décembre 2021 à 19:33 (CET)
J'ai vérifié les autres modèles cités dans les documentations, ils semblent effectivement mineurs :
Je ne sait pas s'il mérite une place en bas de la palette, mais sans ils resterons oubliés. — eru [Discuter] 17 décembre 2021 à 18:26 (CET)

┌────────────────────────────────┘
 Hello Eru,
Petit update sur la situation après de nombreuses mises à jour d'appels de modèles pour y voir plus clair. Après passage du bot et de moi-même sur {{Naissance décès âge}}, il ne devrait plus rester beaucoup d'utilisation. On verra ce qu'il en est au prochain dump. Pour résumer, on aura :

Du coup, ces modèles se trouvent globalement très peu utilisés, et je te rejoindrai sur le fait de plutôt ne pas les conserver. Une question donc : est-il possible, à ton avis, de modifier le Module:Date de manière à ce qu'il soit capable d'afficher automatiquement un âge imprécis (type 41-42 ans) dans le cas où l'un des mois (de naissance ou de décès) n'est pas précisé ? En ce qui concerne l'omission du jour uniquement, les modèles actuels affichent quand même un âge précis, ce qui se comprend car potentiellement, il n'y a que quelques jours par an où l'âge sera incorrect. Bien évidemment, il faudrait que cette modification soit sans effets de bord pour les dates complètes. Ainsi, cela supprimerait la nécessité d'ajouter un paramètre du type "âge=toujours", et on aurait des modèles {{Date de naissance}} et {{Date de décès}} vraiment universels.
En ce qui concerne {{Naissance&décès âge}}, je pense que le nouveau nom du modèle devrait comporter les informations "naissance", "décès", "date" et "lieu", car ce sont ces éléments qui sont systématiquement utilisés dans quasiment tous les appels du modèle. La partie "âge" n'est affichée que par un paramètre optionnel qui n'est présent que dans une minorité d'appels. Un truc du style {{Date et lieu de naissance et de décès}} me semblerait bien, mais c'est un peu long... {{Date et lieu naissance et décès}}, peut-être ?
Epok__ (✉), le 15 janvier 2022 à 09:44 (CET)

Je me rends compte que j'ai également oublié de te répondre concernant les modèles que tu cites dans ton dernier message. J'ai étudié un peu ces modèles suite à ton message, et mes réflexions sont les suivantes :
  • {{Existe depuis}} : Ce modèle me semble adapté pour les institutions : dans de nombreux cas, les articles sur celles-ci utilisent le modèle {{Âge}} pour indiquer la durée d'existence. Même si ce n'est pas vraiment incorrect, il me semble qu'un tel modèle pourrait avantageusement le remplacer, en réservant le modèle {{Âge}} aux humains (et éventuellement aux animaux, enfin à ce qui est vivant). À voir donc, mais si on va dans ce sens, on pourrait moderniser ce modèle en lui faisant utiliser le module. À mon avis, un code proche de celui de {{Durée}}, avec une petite adaptation pour ne garder que la plus grande unité pourrait faire l'affaire.
  • {{Time ago}} : clairement à renommer en français si on le conserve. Mais je doute de son intérêt formel par rapport à {{Existe depuis}} (même si techniquement actuellement, le second dépend du premier).
  • {{Décompte}} : pas convaincu qu'il faille s'y attarder, il est clairement très peu utilisé... mais pas forcément à supprimer, il va vers le futur là où les autres vont vers le passé. Mais il est plutôt rare de faire un décompte dans une encyclopédie, donc à voir...
Auxquels je rajouterai :
  • {{Date-n}} : quasiment totalement inutilisé, à voir si on conserve.
  • {{Date grégorienne}} : même combat, inutilisé, il servait à priori dans des modèles qui maintenant utilisent le module.
  • {{Date ISO}} : un peu différent car il fait un affichage ISO, mais inutilisé.
  • et enfin les 12 modèles {{1er janvier}} à {{1er décembre}} : je n'y vois aucun intérêt par rapport à {{Date}} avec l'année mentionnée avec le suffixe « - » (y'a un petit tooltip en plus, mais pas convaincu de son utilité) => à remplacer ? (difficile par un bot, faut déterminer l'année)
  • {{Year}} : à remplacer par {{Date}} ? => bot ?
Et enfin, ceux sur lesquels je suis actuellement en train de travailler :
  • {{Date triable}} : inutile maintenant que {{Date}} est triable. J'ai fait quelques modifs sur les appels spécifiques, j'attends le prochain dump (et une petite question sur l'utilité de sa fonction "amj" = format ISO, à voir si on conserve ses usages) pour voir où on en est mais pour moi => à remplacer par bot.
  • {{Date rapide}} : clairement dit dans la doc du modèle qu'il n'est utile pour les pages avec plusieurs centaines d'appels, et actuellement il est principalement utilisé par des pages avec seulement quelques inclusions : il faudrait trancher sur son utilité réelle, et éventuellement le remplacer par bot.
Wikipédiennement, Epok__ (✉), le 20 janvier 2022 à 21:44 (CET)

Proposition de refonte des modèles millénaire

modifier
Dernier commentaire : il y a 2 ans3 commentaires2 participants à la discussion

Bonsoir,

J'ai plongé aujourd'hui dans la foultitude de modèles permettant d'afficher des millénaires. L'état d'incohérence d'un modèle à l'autre étant assez terrible, j'aimerais proposer une refonte globale, inspirée des modèles de siècles (qui semblent globalement cohérents et connus de la communauté).

La proposition en question : Utilisateur:Golmote/Proposition de refonte des modèles millénaire. J'aimerais beaucoup avoir vos avis sur le sujet. --Golmote (discuter) 16 janvier 2022 à 21:10 (CET)

  Golmote : Je soutiens ta proposition et le principe de reprendre tout ça. Je n'ai pas regardé en détail ta proposition ce soir (je ferais ça la semaine prochaine), mais elle me semble assez cohérente.
Par contre je serais hautement favorable à préempter {{mi}}, qui n'est utilisé que 24 fois.
C'est une langue tellement anecdotique (cf. usage du modèle), que de toute façon personne ne doit connaître ce modèle.
Histoire de faire un truc propre et cohérent avec les siècles, et de ne pas toucher le nom des modèles de millénaires déjà existants et compatibles avec le nouveau shéma, et bien plus utilisés que ce code de langue.
--Tractopelle-jaune (discuter) 16 janvier 2022 à 21:31 (CET)
@Tractopelle-jaune Pourquoi pas, effectivement. Je ne voulais pas interférer avec les modèles d'indication de langue, mais j'imagine qu'un modèle {{lang:mi}} serait raccord avec les quelques autres exceptions que je vois ({{lang:non}}, {{lang:nb}}, {{lang:ve}}). --Golmote (discuter) 16 janvier 2022 à 21:59 (CET)

Meilleur contrôle sur les liens de {{date}}

modifier
Dernier commentaire : il y a 2 ans1 commentaire1 participant à la discussion

Bonjour, j'avais lancé l'idée il y a quelque temps d'ajouter au modèle {{date}} une fonctionnalité pour désactiver les liens sur les différents fragments de façon plus unitaire que {{date-}}, à la manière de ce que propose {{date républicaine}}. J'ai finalement sauté le pas et fait un test d'implémentation. Je suis preneur de vos avis sur la PDD du modèle {{date}}. Merci d'avance ! --Golmote (discuter) 29 janvier 2022 à 12:49 (CET)

Modèle Abréviation et balise abbr

modifier
Dernier commentaire : il y a 2 ans8 commentaires4 participants à la discussion

{{Abréviation}} utilise <abbr> qui est plus ou moins de facto obsolète, cf. cet article en anglai. Je pense qu’il serait pertinent de recoder le modèle en utilisant une approche comme celle de {{abbr wikitexte}} et un peu de CSS avec templatestyles et des « media queries » pour gérer les cas comme les lecteurs vocaux de la meilleure manière possible. Des idées / suggestions ? — TomT0m [bla] 29 janvier 2022 à 14:49 (CET)

@TomT0m Attention aux raccourcis dans la formulation : la balise <abbr> n'est pas obsolète ; l'attribut title non plus d'ailleurs. Par contre, l'utilisation de title pour expliciter une abréviation est effectivement critiquée pour son manque d'utilité et d'accessibilité dans certaines situations. --Golmote (discuter) 29 janvier 2022 à 15:02 (CET)
Bonsoir, je lis en effet le contraire dans cet article : « The title on the <abbr> element is well supported by screen reader software, but its use is still problematic, as other user groups cannot access the expansion. It is recommended that the expanded form of an abbreviation is provided in plain text when it is first used in a document, and/or a glossary of terms that provides the expanded form is provided. This is not to suggest that that the expansion cannot be provided using the title attribute, only that due to its limitations, an expansion in plain text also be provided. »
Donc title est utile pour les lecteurs d'écran. Il est juste recommandé d'avoir en plus un glossaire.
--FDo64 (discuter) 29 janvier 2022 à 22:39 (CET)
En fait c’est plus compliqué, dans la note qui accompagne ( https://www.tpgi.com/short-note-the-abbreviation-appreciation-society/ ) on peut lire « The title attribute content is only practically available to mouse users.
The title attribute display for mouse users with low vision is problematic, to say the least.
The title attribute content is available to users of JAWS and NVDA screen reader users if they enable it, by default it’s ignored.
VoiceOver simply does not announce the title attribute content on <abbr>
No amount of clever tricks with ARIA, CSS and JavaScript will make it not suck.
 » — TomT0m [bla] 29 janvier 2022 à 23:03 (CET)
Une chose intéressante que l'on peut faire avec l'attribut title, c'est avec du simple CSS ajouter sa valeur entre parenthèses après l'abréviation, pour ceux qui le souhaiteraient :
abbr::after {
    content: ' (' attr(title) ')';
}
Pour tester, rentrer dans la console JavaScript :
mw.loader.addStyleTag(`
    abbr::after {
        content: ' (' attr(title) ')';
    }
`);
Concernant le modèle {{abbr wikitexte}}, je pense que c'est une très mauvaise solution, justement j'ai récemment détaillé sur sa pdd.
od†n ↗blah 30 janvier 2022 à 04:31 (CET)
  Od1n : C’est toujours sympa de pouvoir personnaliser un max ses trucs avec des techniques standards et propre, le problème c’est que si par défaut ça fonctionne pas pour bien des utilisateurs de lecteur vocal, dans le sens ou si par défaut ils lisent pas la version longue, on passe à côté du problème je pense. Une solution qui pourrait marcher c’est d’utiliser les media queries pour afficher la version longue de l’abbréviation systématiquement dans le cas de lecture vocale, vu que par exemple « resp. » ça donne rien à l’oral en comparaison de « respectivement ». Si les lecteurs vocaux respectent les règles bien entendu et c’est pas forcément gagné.
@TomT0m, @FDo64 et @Od1n Il y a normalement seulement une poignée de cas dans lesquels on voudrait utiliser une infobulle :
  • Pour définir un sigle : Si l'article utilise beaucoup ce sigle, il conviendrait normalement de l'écrire une première fois entièrement, en précisant le sigle entre parenthèses. Les occurrences suivantes peuvent alors se contenter d'utiliser le sigle (comme expliqué dans la page déjà citée précédemment [1]). Une infobulle sur ces occurrences peut apporter un petit plus aux utilisateurs mais son bon fonctionnement n'est pas critique à la compréhension. Et dans un cas comme SNCF, et si l'article ou le sigle est utilisé n'est pas l'article détaillé sur la SNCF, alors je pense qu'un lien vers l'article détaillé est suffisant. Le lien fournit l'explication du sigle aux utilisateurs qui en auraient besoin.
  • Pour définir une abréviation : Je pense que c'est le cas le plus subtil. Les abréviations sont normalement utilisées quand on manque de place, donc écrire entièrement le mot n'est pas sans doute pas une solution envisageable. Pour satisfaire les lecteurs d'écran, il serait possible de faire des trucs du style <span class="visually-hidden">respectivement</span><abbr aria-hidden="true" title="respectivement">resp.</abbr> (visually-hidden) mais ça ne change rien pour les utilisateurs mobile ou les utilisateurs qui naviguent entièrement au clavier...
  • Pour apporter des informations complémentaires : Formules chimiques, notes et ce genre de choses devraient passer par des <ref>.
--Golmote (discuter) 30 janvier 2022 à 11:05 (CET)
Si c’est pour un tableau style le tableau périodique des éléments ou des isotopes je te racontes pas la tailles des notes de bas de pages. cf modèle:Table des isotopes par exemple ou on a dans les tuyaux un module pour afficher différentes infos sur les isotopes.
Sinon il y a peut-être des trucs pour détecter les appareils qui vont fonctionner, genre les mobiles on peut les détecter par exemple si la largeur d’affichage est assez peu large, ou avec les propriétés de media query plus moderne celle sur la possibilité de survor ou sur la précision du pointeur (souris / gros doigts j’imagine) sont à expérimenter.
@TomT0m Malheureusement détecter la largeur de l'écran n'est pas une solution fiable : on peut avoir une fenêtre étroite sans être sur mobile, on peut utiliser un curseur de souris sur un mobile, etc. J'ai testé @media(hover), mais malheureusement certains navigateurs mobiles (comme Google Chrome sur mon Android) indiquent supporter le survol (ce qui est techniquement vrai) mais pour autant ils ne sont pas capable d'afficher les infobulles title. Et pareil pour @media(pointer:coarse), ça ne donne pas d'information réelle sur la capacité ou non à afficher l'infobulle. Ces media queries ne permettent pas un balayage exhaustif : on peut tout à fait avoir une souris mais préférer (ou être seulement en capacité de) naviguer au clavier, par exemple. C'est un sujet compliqué.
Pour ton exemple de tableau périodique, les informations additionnelles sur les isotopes mériteraient probablement d'avoir leur propre section dans l'article non ? Et ainsi, ces infos pourraient être rédigées. Et avec pourquoi pas un système d'ancres depuis le tableau en lui-même. --Golmote (discuter) 30 janvier 2022 à 15:16 (CET)
@Golmote C'est pas nécessairement un problème d'essayer d'avoir une approche conservative. Par exemple si l'écran est petit expliciter systématiquement ou juste la première fois n'est pas gênant même si on est sur un bureau. Pour la navigation au clavier peut-être qu'une balise <a> et la pseudo classe focus ferait l'affaire.
Renvoyer vers une section dans l'exemple de la table des isotopes serait pas spécialement pratique pour la navigation à la souris par exemple, et ça ferait vraiment une page à rallonge, comme pour mettre ça en note de bas de page non ? Et quitte à nécessiter un clic autant aller dans l'article de l'élément. — TomT0m [bla] 30 janvier 2022 à 15:42 (CET)

Documentation d'infobox, Italie

modifier
Dernier commentaire : il y a 2 ans8 commentaires4 participants à la discussion

Bonsoir. Ayant un accord sur la PDD du projet italie, nous avons essayé de rajouter la ligne "langue" dans l'infobox. Cependant, nous n'arrivons pas à la rendre fonctionnelle : on ne la voit pas. Sauriez-vous quoi faire ? --Æpherys (discuter) 29 janvier 2022 à 21:58 (CET)

Bonjour Æpherys et Adri08. Gemini1980 a bien fait d'annuler les tâtonnements effectués dans le modèle. La documentation du méta-modèle {{Infobox Subdivision administrative}} et en particuler les paramètres divers et nom divers permettent d'accéder simplement à votre demande, dans une "rubrique" « Divers ». Voir l'exemple de Sicile qui contenait déjà ce paramètre langues bien qu'inexistant alors. Les nouveaux paramètres sont langues et type langues, comme ce que vous aviez tenté d'insérer. Est-ce que cela convient ? Sinon, il y a la possibilité d'intégrer l'affichage de cette donnée à la rubrique « Démographie ». À vous de voir. Pense-bête : il ne faudra pas oublier de mettre à jour la documentation du modèle une fois les choses fixées. — Ideawipik (discuter) 1 février 2022 à 07:35 (CET)
Pour moi « langues » c'est très bien et cela fonctionne  . Modifié dans Ombrie. Merci beaucoup -- Adri08 (discuter) 1 février 2022 à 13:38 (CET)
Ah ! Merci beaucoup   Ideawipik. Je ne savais pas non plus. Par contre, il me semble que c'est mieux que cela soit placé dans "Démographie", comme c'est fait pour tous les autres pays. Après ce n'est qu'un détail, mais ça fait mieux rangé, disons… Si c'était possible de le faire, afin de faire comme avec les autres pays, je trouverais ça mieux… Je ne sais pas si vous maintenez votre avis   Adri08 pour calquer sur l'usage généralement des autres pays, où c'est généralement placé à la fin de la section "Démographie"… --Æpherys (discuter) 1 février 2022 à 18:36 (CET)
Oui, Autant calquer l'usage général. -- Adri08 (discuter) 1 février 2022 à 18:58 (CET)
@Æpherys et Adri08. C'est fait dans le modèle. Maintenant, je me demande s'il est vraiment pertinent éditorialement d'employer ce paramètre si c'est pour ne mettre que … « italien », surtout avec le libellé par défaut « Langues officielles » au pluriel, élement personnalisable avec le paramètre type langues dont je doute de la réelle utilité et de l'intérêt de la conservation. — Ideawipik (discuter) 1 février 2022 à 19:21 (CET)
  Æpherys : quelle est la logique derrière le fait que ce soit mis dans « Démographie » dans la mesure où ce n'est pas à proprement parler une donnée démographique ? J'ai bien compris qu'ici la remarque n'était que par rapport à l'usage dans d'autres modèles analogues, mais cet usage me laisse perplexe. SenseiAC (discuter) 3 février 2022 à 00:16 (CET)

┌─────────────────────────────────────────────────┘

  • Si c'est à remettre en cause, il faut le faire généralement. Si je regarde pas mal d'article WP, comme celui des États-Unis ou de l'Espagne, la section langue se trouve dans la section "Démographie". Ce n'est donc en rien aberrant que ce le soit aussi dans l'infobox. Pour d'autres pays comme la France ou le RU, démographie et langues sont des sections à part en revanche dans l'article, mais sont regroupés dans une section "Population". S'il n'y a pas d'unanimité pour aucun des camps dans les articles, c'est au contraire le cas dans l'infobox où les langues sont quasi-systématiquement placé dans la section démographie.
  • Démographie, c'est composé du grec dêmos, « peuple », et de ‑graphie, du grec graphein, « écrire ». Or, la section "langue" apparaît systématiquement dans la section "population" ou "démographie", qui est littéralement la même chose. Je ne vois donc en rien de problème.
  • Et oui, c'est bien une donnée démographie, il s'agit là de parler d'étudier un peuple. Un peuple a un langage. Le TLFI définit ainsi Démographie : « Science dont l'objet est l'étude statistique des collectivités humaines dans leurs structures fondamentales, sociales, intellectuelles, etc. ». Le social inclut les langues. --Æpherys (discuter) 3 février 2022 à 16:15 (CET)

D'étranges méprises au niveau de bandeaux de catégories

modifier
Dernier commentaire : il y a 2 ans4 commentaires3 participants à la discussion

Bonjour à tous,

Je suis surpris de constater qu'il a été fait de gros raccourcis dans l'élaboration des bandeaux de catégories {{Catégorie XIe siècle}} jusqu'à {{Catégorie XVIe siècle}}. En effet, on est complètement dans l'eurocentrisme, par analogie avec le francocentrisme, puisque ces modèles renvoient des bandeaux propres au Moyen Âge et à la Renaissance, ce qui ne veut rien dire pour d'autres civilisations que l'européenne !

Je sollicite le projet:Modèle pour revenir à des intitulés plus modestes, plus logiques, du même effet que {{Catégorie XVIIe siècle}} qui renvoit

  Arborescence du XVIIe siècle

, car je maîtrise mal la programmation technique.

Merci d'avance, bien cordialement. --Sergio1006 (observateur de l'encyclopédie, responsable, libre et indépendant) 19 février 2022 à 00:46 (CET)

Oui, ça semble une très bonne idée. • Chaoborus 19 février 2022 à 17:58 (CET)
Bonjour Sergio1006 et Chaoborus. Mis à part une sous-page résiduelle (Portail:XVe siècle/Index thématique) qui n'est incluse nulle part ni lié à aucune page, il n'existe aucun portail pour les siècles antérieurs au Portail:XVIIe siècle donc pas de raison d'avoir de bandeau de portail pour cela. On notera que les modèles problématiques cités plus haut ne sont que des redirections. En revanche pour limiter l'"eurocentrisme", on pourrait inviter les contributeurs à utiliser directement les modèles dédiés, voire supprimer les redirections sauf si des portails par siècle sont envisagés.
P.S. – Il faut en discuter avec le Projet:Chronologie. — Ideawipik (discuter) 20 février 2022 à 21:31 (CET)
Merci pour votre réponse Ideawipik, mais je pense que vous n'avez pas compris le problème soulevé.
Le fait qu'un portail lié à ces bandeaux de catégorie existe ou pas importe peu, il s'agit de ne plus voir apparaître ces bandeaux de catégorie redirigés avec des intitulés absurdes. Par exemple, la catégorie:Édifice religieux du XIVe siècle au Japon indique en haut de page qu'on se situe historiquement au Moyen Âge, ce qui ne veut rien dire pour la civilisation japonaise.
J'irai exposer la situation auprès du projet:Chronologie.
Cordialement. --Sergio1006 (observateur de l'encyclopédie, responsable, libre et indépendant) 21 février 2022 à 00:35 (CET)

Prise de décision : PàS et débat d'admissibilité

modifier
Dernier commentaire : il y a 2 ans8 commentaires4 participants à la discussion
 
Page connexe : Lien vers la PdD.

Bonjour,

Avec la clôture de la PdD, plusieurs modèles (voire modules et gadgets) sont à adapter. Voici ceux auxquels j'ai pensé :

Votre aide est la bienvenue. LD (d) 18 février 2022 à 22:29 (CET)

Je me suis chargé de {{Instructions_PàS2}} et Module:Talkpageheader avant même de voir tes demandes  . Pour {{L}}, je crois que ça va être compliqué de faire quelque chose de correct sans le migrer dans un module Lua. El pitareio (discuter) 18 février 2022 à 23:34 (CET)
J’ai tenté quelque chose dans {{L/Bac à sable}}. L’idée est d’utiliser « ifexist » pour tester si la page « /Suppression » existe et l’utiliser le cas échéant, sinon d’utiliser /Admissibilité . Ça complique un peu le code mais c’est déjà le bordel.
J’ai juste peur que ça tienne pas sur des pages qui peuvent être très chargées comme WP:PàS parce que la fonction est « expensive ». Je sais pas, c’est quoi la limite de nos jours, 500 appels expensive ? — TomT0m [bla] 19 février 2022 à 16:58 (CET)
Pour l'instant, je bricole : je fais une redirection de Discussion:Article/Suppression vers Discussion:Article/Admissibilité. C'est moyen, mais efficace. Ο Κολυμβητής (You know my name) 19 février 2022 à 17:00 (CET)
Ça passe avec ma version en bac à sable avec 3/4 fois le volume des PàS actuels (j’ai fait des copier/collers) donc il ne devrait pas y avoir de soucis. — TomT0m [bla] 19 février 2022 à 17:04 (CET)
Autre modèle à actualiser : Modèle:Page conservée. BàV, LD (d) 19 février 2022 à 21:07 (CET)
Plus généralement, tout ce qui est dans les résultats de cette recherche devrait être modifié.
On se rapproche de la fin des renommages des anciennes pages en /Suppression. El pitareio (discuter) 22 février 2022 à 23:09 (CET)
J'ai renommé pages protégées que nos bots ne pouvaient pas toucher. LD (d) 22 février 2022 à 23:37 (CET)

✔️ Modèle:Jour de fonctionnement pour les pays où le premier jour de la semaine n'est pas le lundi.

modifier
Dernier commentaire : il y a 2 ans5 commentaires2 participants à la discussion

Bonjour.

Je suis en train de travailler sur les articles relatifs aux transports en commun en Algérie, notamment sur les lignes de bus d'Alger (Lignes de bus ETUSA).

Je viens de m'apercevoir que les indications sur les jours de fonctionnement des lignes de bus (jours spécifiés avec Modèle:Jour de fonctionnement) n'étaient pas convenablement affichés dans les tableaux des lignes de bus (avec le Modèle:Ligne de transport en commun) par rapport aux choix qu'ont fait les rédacteurs précédents de ces articles qui ont indiqué les jours dans l'ordre : "D", "L", "Ma", "Me", "J" et, éventuellement "V" et "S" car, en Algérie, le premier jour de la semaine est le dimanche (vendredi et samedi étant des jours de "repos" comme pour d'autres pays, voir : Repos hebdomadaire le vendredi).

Aussi, pour indiquer qu'une ligne de bus ne fonctionne qu'en semaine en Algérie (du dimanche au jeudi), les rédacteurs précédents ont écrit : {{jour de fonctionnement|d|l|ma|me|j|}} , mais au final, seule la lettre "D" est affichée car le modèle "Jour de fonctionnement" a été écrit de sorte que le premier jour est le lundi et le dernier est le dimanche

Je me demande s'il ne faudrait pas créer un autre modèle pour permettre d'indiquer les jours de fonctionnement dans l'ordre que l'on veut. Qu'en pensez-vous ? --Poudou! (discuter) 30 mars 2022 à 18:02 (CEST)

Bonjour Poudou!. Il y a une solution toute bête dans le code du modèle existant, en mettant toutes les possibilités pour chaque paramètre positionnel, i.e. dupliquer sept fois le même "switch". Une solution plus propre serait de solliciter un sous-modèle qui servirait de fonction ou de réécrire le modèle en Lua (module). J'ai une préférence pour le sous-modèle, mais souhaiterais l'avis d'autres modélistes. En attendant, la première solution, somme toute, assez simple, a été appliquée en simplifiant le code en place (regroupement des cas). Le nouveau fonctionnement répond-il à tes attentes ? — Ideawipik (discuter) 30 mars 2022 à 18:42 (CEST)
Bonjour @Ideawipik. Super ta modification  , c'est exactement cela que je souhaitais voir comme rendu. Merci. --Poudou! (discuter) 30 mars 2022 à 18:49 (CEST)
On pourrait ajouter directement dans le code du modèle une détection des valeurs invalides (voire vides) passées en paramètre à ce modèle. Vérification externe wstat : dans le paramètre 2 (concerne en particulier Lignes d'autobus du TEC Hainaut et Réseau interurbain de la Corrèze), dans le paramètre 7, paramètre inexistant 8. @Poudou!, je te laisse corriger, si tu veux. — Ideawipik (discuter) 30 mars 2022 à 19:24 (CEST)
@Ideawipik : je viens de corriger les appels au modèle avec les valeurs erronées citées par wstat. --Poudou! (discuter) 31 mars 2022 à 02:11 (CEST)

Localisation sur carte qui produit un scroll horizontal

modifier
Dernier commentaire : il y a 2 ans14 commentaires2 participants à la discussion

Bonjour, sur l'article Chaumont (Haute-Marne) (avec la skin Vector classique), et déjà quelques autres fois auparavant, j'ai constaté une barre de défilement horizontale sur la fenêtre du navigateur. La cause se trouve dans la carte de l'infobox : le libellé du point de localisation a un CSS width:12em qui fait que ça dépasse parfois l'article en largeur. Pour information, sur cet article j'ai pu faire disparaitre le scroll horizontal en ajoutant un display:inline (ou inline-block) (et on peut supprimer le width:12em qui devient inutile). Mais au vu de la quantité d'utilisations de ces modèles, et de leur complexité, je n'ai pas trop envie de faire de modification à la va-vite. Donc si une personne familière avec les modèles de cartes et géolocalisation est intéressée pour se pencher sur la question, ça serait le bienvenu. od†n ↗blah 10 mars 2022 à 02:41 (CET)

Ce width:12em vient de {{Point/Ville sans lien}} (depuis sa première version) mais est sans doute aussi présent dans d'autres modèle de point, mais pas dans ceux utilisant {{Pictogramme avec toponyme}}. Mettre un display:inline ajoute des retours ligne pour les noms composés (essaye sur Saint-Germain-la-Blanche-Herbe par exemple).
J'ai visiblement déjà regardé ça (Diff #153656533) mais je ne m'en souviens plus trop. Peut-être devrait-on utiliser {{Pictogramme avec toponyme}} dans {{Point/Ville sans lien}}, mais comme ce modèle utiliser sur 200 000+ pages il faudrait tester un peu avant. Pas le courage de d'essayer ça tout de suite. — Zebulon84 (discuter) 10 mars 2022 à 09:31 (CET)
Avec display:inline-block cela n'ajoute pas de retour ligne sur Saint-Germain-la-Blanche-Herbe 🙂 À noter que contrairement au display:inline, il devient impératif de supprimer le width:12em, autrement le scroll horizontal reste présent sur Chaumont (Haute-Marne). od†n ↗blah 10 mars 2022 à 11:06 (CET)
Mais avec display:inline-block et en supprimant le width:12em, sur Saint-André-de-Cubzac cela ajoute des retours ligne… od†n ↗blah 10 mars 2022 à 11:12 (CET)
Une autre piste serait que dans le cas de Chaumont (Haute-Marne) le libellé devrait être placé à gauche du point, comme c'est par exemple le cas avec les villes à l'Est de la France telles que Lingolsheim. Il y aurait donc peut-être une valeur à ajuster quelque part. od†n ↗blah 10 mars 2022 à 11:28 (CET)
Oui, dans l'absolu on peut modifier le positionnement du texte, mais Reims ou Chaumont ne paraissaient pas proche du bord, donc le modèle doit correctement gérer ces cas.
Je me suis inspirer du code de {{Pictogramme avec toponyme}}, ça devrait résoudre la majorité des problèmes. Il peut toujours y avoir des débordement pour les noms long sans coupure, ou en position N ou S proche du bord (il reste un width:120px dans ce cas), mais ça doit être rare. Ceci-dit je n'ai pas testé sur tout les navigateurs (notamment mobile), sur tout les habillage, donc il y a peut-être un problème que je n'ai pas vu. — Zebulon84 (discuter) 10 mars 2022 à 22:34 (CET)
J'ai effectué divers tests et ça avait l'air tout bon, mais mauvaise nouvelle j'ai repéré un bug : sur l'article Strasbourg en version mobile, avec une fenêtre de largeur inférieure à 700px de sorte que l'infobox bascule en affichage pleine largeur, le point se trouve en dehors de la carte.
À noter que j'ai testé d'autres villes de la même manière et elles n'ont pas le bug. Détail intéressant, avec l'article Strasbourg la carte est au milieu de l'infobox, alors qu'avec les autres villes la carte est à gauche.
od†n ↗blah 11 mars 2022 à 02:38 (CET)

┌─────────────────────────────────────────────────┘
 Si je compare Starsbourg et Mulhouse, sur Strasbourg il y a en plus le CSS (edit : de la table contenant les cartes de géolocalisation) 

  @media (max-width: 720px)
body.skin-minerva .mw-parser-output [class*="infobox"] table {
  display: table;
}

qui écrase le display:block; du CSS 

  @media (max-width: 720px)
.content table {
  display: block;
  width: 100% !important;
  box-sizing: border-box;
}

présent sur les deux pages. Je ne sais pas (encore) d'où vient cette différence. — Zebulon84 (discuter) 11 mars 2022 à 11:27 (CET)

Cette différence persiste en prévisualisation d'une modification ou je laisse le seul code {{Infobox Commune de France}} — Zebulon84 (discuter) 11 mars 2022 à 11:37 (CET)
Trouvé : Ça vient du Modèle:Infobox/styles.css introduit par l'Infobox Ancienne entité territoriale, Infobox_V3 présente sur la page de Strasbourg (section Strasbourg, ville impériale libre). En modification sur minerva le code actuel de la page est présent mais caché, d'où l'interférence même lorsqu'on supprime tout le code.
As-t-on un moyen d'éviter cette collision ? — Zebulon84 (discuter) 11 mars 2022 à 12:26 (CET)
Tu peux consulter cette discussion : Discussion utilisateur:Great Brightstar#Modèle:Infobox/styles.css. En résumé, sur la skin Minerva avec les fenêtres de faible largeur, MediaWiki passe les tables en display:block, etc. pour qu'elles prennent toute la largeur. Mais c'est quelque chose que nous ne voulons pas dans les infoboxes. Le workaround de Great Brightstar est donc pertinent, mais devrait être déployé plus proprement, avec une mise en œuvre globale, au lieu d'ajouter le TemplateStyles (+ ajout d'un CSS inline width:100%) sur quelques infoboxes ici et là. od†n ↗blah 12 mars 2022 à 05:33 (CET)
La largeur de la table étant cruciale pour les cartes de géolocalisation je propose de rajouter un !important sur le width:auto de la table du modèle {{Début de carte}}. Mais n'étant plus admin je ne peux pas faire cette modif moi-même.
Je centrerai bien la carte d'office avec margin: 0 auto !important;, mais cela peut aussi modifier la position des cartes qui ne sont pas dans une infobox (ex. Université de technologie (France)). Sinon cela pourrait-être dans le MediaWiki:Common.css sous une nouvelle entrée .infobox_v2 .DebutCarte mais cette dernière classe ne respecte pas la typographie du Common.css. Je ne sais pas si elle est utilisée quelque part. — Zebulon84 (discuter) 12 mars 2022 à 17:49 (CET)
Le margin: 0 auto !important; pourrait être passé à {{Début de carte}} par le paramètre style table dans le modèle {{Infobox/Géolocalisation multiple/Carte}}, comme ça ça n'affecterait que les infobox_V2. Mais ce modèle est évidemment aussi protégé, hors de ma portée. — Zebulon84 (discuter) 13 mars 2022 à 05:36 (CET)
Pour information, je viens de supprimer les utilisations de la classe « infobox », et de déployer un modèle {{Classes début infobox}} ; voir cette discussion. od†n ↗blah 30 juin 2022 à 06:23 (CEST)

✔️ BBKL

modifier
Dernier commentaire : il y a 2 ans8 commentaires3 participants à la discussion

Bonjour,

Quand on utilise le modèle {{BBKL}}, la mention "[Archive]" s'affiche en italique. Je trouve cela particulièrement disgracieux. Cdlt, — Jacques   (me laisser un message) 23 avril 2022 à 14:02 (CEST)

Bonjour Jacques. Le modèle BBKL se contentant d’appeler le modèle {{Ouvrage}} et la classe "metadata", utilisée (à quoi sert-elle ?) dans une balise span, ne mettant pas en italique, je ne crois pas que le modèle soit à incriminer. As-tu un exemple d'affichage insatisfaisant ? Merci. — Ideawipik (discuter) 23 avril 2022 à 16:38 (CEST)
@Jacques Ballieu@Ideawipik cf. Wikipédia:Archivage des liens externes c’est le cas pour tous les liens externes dans l’espace encyclopédique. Si ça te gène la page donne un moyen de désactiver ça pour toi. Je sais pas si il y a un moyen de désactiver cette fonctionnalité de manière sélective dans un modèle. Peut-être via une CSS. — TomT0m [bla] 23 avril 2022 à 16:47 (CEST)
Il doit y avoir moyen, si on veut via un une CSS de modèle de désactiver la classe <small class="cachelinks"> pour certains modèles. — TomT0m [bla] 23 avril 2022 à 16:50 (CEST)
Bonjour Ideawipik  , j'ai remarqué cela dans Ennode_de_Pavie#Liens_externes, référence Friedrich Wilhelm Bautz. Bien sûr, ce n'est pas essentiel, j'ignore même si il y a une quelconque recommandation à ce sujet. Cdlt, — Jacques   (me laisser un message) 23 avril 2022 à 17:02 (CEST)
Les liens au dessus qui n’affichent eux pas le lien d’archive ont une particularité, ils sont englobés par <span class="nowrap uid noarchive">. Il faudrait faire pareil avec ce modèle pour les supprimer j’imagine. — TomT0m [bla] 23 avril 2022 à 17:07 (CEST)
Merci Jacques et TomT0m. J'avais lu trop vite le code du modèle. L'italique est bien issu de celui-ci. En réalité une bonne partie du texte est introduite via le paramètre titre du modèle {{Ouvrage}}, donnée qui est mise en italique (<cite class="italique">) et l'auteur du modèle a utilisé une astuce pour retirer l'italique là où il n'était pas souhaité (sur le mot « dans ») mais cela laisse tout le lien externe en italique y compris l'archive. Ce paramètre titre n'est normalement pas destiné à recevoir un lien externe. On peut envisager une réécriture de {{BBKL}} de sorte qu'il sollicite un {{Lien web}} ou conserver l'Ouvrage mais laisser son affichage habituel, sans lien sur le titre mais avec un « [lire en ligne] ». Le modèle {{Chapitre}} semblerait encore davantage adapté.
Sinon, il est peut-être possible de modifier le CSS. Suffirait-il de changer la définition pour « cachelinks » dans le Commons.css avec le code suivant ? 
small.cachelinks > a {
	color: #36b;
	font-style: normal;
}
Je n'ai pas testé dans un common.css personnel. Mais la première solution me semble beaucoup plus propre. — Ideawipik (discuter) 23 avril 2022 à 18:12 (CEST)
Bonjour Jacques. La solution avec le modèle Chapitre a été appliquée.
Un bout de code fort peu compréhensible, sauf à vouloir voir le modèle afficher « col. 0–-0 » (ajout de 2016) a été retiré.
Puisqu'ils affichaient la même chose sur frwiki, spalte et spalten sont devenus alias (j'ai vérifié qu'il n'y avait actuellement aucun appel avec simultanément les deux paramètres).
La partie concernant l'Internet Archive a été conservée telle quelle, étant donné que les utilisations du paramètre archiveurl, à ce jour, pour ce modèle concernent toujours le site d'Internet Archive (web.archive.org) ; mais ce n'est pas forcément cohérent avec les autres modèles bibliographiques dont le paramètre du même nom accepte tous types d'archives. On pourrait utiliser directement ce paramètre "natif" des modèles bibliographiques, dont « Chapitre » fait partie, conjointement à leur paramètre archivedate.
Notes pour la suite.
  1. On pourrait intégrer un langue=de directement dans le modèle BBKL, mais il faudrait retirer les {{de}} devant les appels de celui-ci dans les articles.
  2. Je n'ai pas vérifié, ni modifié, les adresses internet mais il me semble que les liens externes ne dirigent pas (ou pas toujours ?) sur les pages souhaitées.
  3. Pour respecter les recommandations du projet:Modèle, il serait vraisemblablement bien de traduire en français les noms des paramètres, tout en gardant les alias en allemand.
S'il y a un souci, Merci de le signaler. — Ideawipik (discuter) 24 avril 2022 à 00:52 (CEST)

✔️ TempleWizard défectueux pour modèle très utilisé

modifier
Dernier commentaire : il y a 2 ans2 commentaires2 participants à la discussion

Bonjour, j'ai soulevé un problème concernant la boîte de dialogue TempleWizard (et donc la syntaxe) d'un modèle protégé et très utilisé, ici : Discussion modèle:Article conservé si certains d'entre vous veulent y jeter un oeil. Bonne journée et merci par avance. Champeillant (discuter) 25 avril 2022 à 05:56 (CEST)

 . Valeur automatique corrigée dans le TemplateData. — Ideawipik (discuter) 25 avril 2022 à 14:54 (CEST)

Demande de modifs du modèle Infobox Critique presse

modifier
Dernier commentaire : il y a 2 ans7 commentaires3 participants à la discussion

Salut,

est-ce qu'il serait possible de modifier le modèle {{Infobox Critique presse}} de façon :

  • qu'il puisse utiliser un paramètre du type | langue du titre = ;
  • qu'il mette automatiquement le titre en italique puisqu'il s'agit du titre d'une œuvre ;
  • qu'il ait une largeur automatiquement identique à une éventuelle infobox qui la précède ou alors qu'il y ait un paramètre width = quelque part pour l'ajuster ?

Je demande beaucoup, je sais... :)

Kropotkine 113 (discuter) 11 mars 2022 à 10:21 (CET)

  Kropotkine 113 : J'ai ajouté les paramètres langue du titre et width.
Il n'est pas possible de savoir si il y déjà une infobox dans la page, encore moins quelle est sa largeur. Ceci-dit, si la majorité des infobox déjà présentes ont une largeur commune différente la largeur actuelle de {{Infobox Critique presse}}, on peut ajouter une valeur par défaut à ce width.
Concernant l'italique, la grande majorité de ces infobox l'ajoute déjà manuellement dans le paramètre titre d'après ce que je vois sur wstat.fr. Si le modèle met en italique automatiquement, ces infobox se retrouveront sans italique, car double italique = droit (pour pouvoir retirer l'italique justement). Je n'ai donc pas changer le comportement pour l'instant. Si tu es près à modifier les ~4000 pages concernées (ou faire la demande de bot pour les modifier), c'est simple à changer.
Je te laisse modifier la documentation du modèle.
— Zebulon84 (discuter) 12 mars 2022 à 18:26 (CET)
Il serait possible d'utiliser des balises <i>. od†n ↗blah 13 mars 2022 à 05:01 (CET)
Certes, mais ça rendrait presque impossible de désactiver cet italique (sauf bidouille connue uniquement des développeurs), par exemple pour les quelques pages don le paramètre titre contient « Critiques presse » comme Achtung Baby ou Astronaut. — Zebulon84 (discuter) 13 mars 2022 à 05:26 (CET)
Mais quitte à passer sur une infobox pour la corriger, plutôt que de trafiquer pour défaire l'italique sur « Critiques presse », autant en profiter pour remplacer par la valeur attendue, à savoir le titre de l'œuvre.
De plus, l'italique automatique permet de faire comprendre que c'est un titre d'œuvre qui est attendu.
Il y a un peu plus d'une centaine d'infoboxes avec la valeur « Critiques presse ». On pourrait ajouter grâce à Lua un test du genre « si match /critique/i alors pas d'italique », mais ça serait un peu tiré par les cheveux, il serait plus simple de directement corriger ces infoboxes.
od†n ↗blah 14 mars 2022 à 00:57 (CET)
Des discussions similaires avaient eu lieu il y a deux ans : Discussion utilisateur:Père Igor/Archives 16#Ma modification que tu as annulée et Wikipédia:Bot/Requêtes/Archives/2020/03#Retrait de l'italique manuel dans les pages liées au Modèle:Infobox Critique presse, précédée d'une autre RBOT : Wikipédia:Bot/Requêtes/Archives/2020/02#Mise en forme du titre dans {{Infobox Critique presse}}. Finalement cela n'avait pas abouti, avec retour à la situation initiale, ce qui est dommage dans la mesure où on a là quelque chose d'assez simple techniquement. od†n ↗blah 14 mars 2022 à 01:10 (CET)
La valeur par défaut lorsqu'il n'y a pas de paramètre titre est « Notation des critiques » et non « {{PAGENAME}} », donc j'ai considéré qu'on ne pouvait pas affirmer que la valeur attendue était le titre de l'œuvre. Ceci dit je ne suis pas client de cette infobox, je me rangerait à l'avis de ceux qui l'utilisent. — Zebulon84 (discuter) 14 mars 2022 à 06:36 (CET)

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

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

Bonjour,

L’article « Modèle:Empire mongol (page supprimée) » fait l'objet d'un débat d'admissibilité (cf. Wikipédia:Débat d'admissibilité). Il débouchera sur la conservation, la suppression ou la fusion de l'article. 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:Empire mongol/Admissibilité.

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.

Noms de modèle à inverser ?

modifier
Dernier commentaire : il y a 2 ans4 commentaires4 participants à la discussion

Bonjour, Les modèles {{tweet}} et {{citation tweet}} me semble avoir des noms contre-intuitifs, qui à mon sens seraient plus intuitifs en les inversant au vu de ce qu'ils produisent. En effet, le modèle {{tweet}} produit un pseudo-tweet sous une forme un peu comparable aux citations formatées avec {{citation bloc}}, tandis que {{citation tweet}} insère lui une référence tout à fait analogue à {{article}}, {{lien web}} ou {{ouvrage}} (qui ne sont pas nommés {{citation article}} etc.). Même si ces modèles semblent être d'un usage relativement limité (4 utilisations dans des articles pour {{tweet}} et 489 pour {{citation tweet}}), je pense que ce serait bien que les noms soient inversés par cohérence avec les analogues. Qu'en pensez-vous ? SenseiAC (discuter) 3 février 2022 à 00:11 (CET)

  SenseiAC : Je suis favorable à cette proposition, elle ne peut qu'améliorer la clarté quant au nom de ces modèles, et de ce qu'ils produisent.
--Tractopelle-jaune (discuter) 19 février 2022 à 00:11 (CET)
  Pour fort Manjiro5 [💬] 23 mars 2022 à 19:02 (CET)
Pour apporter la contradiction, avec cette inversion de noms on perdrait la correspondance avec les noms du wiki anglais (qui sont logiques chez eux). En particulier, on perdrait le fait que le nom simple {{tweet}} affiche simplement… un tweet (enfin… une imitation de tweet). Je pense que le problème vient en fait de la traduction maladroite de « cite » en « citation », et qui a pour effet chez nous d'entraîner la confusion de {{citation tweet}} avec les citations (modèles {{citation}}, {{citation bloc}}, etc., et auxquels pour le coup le modèle {{tweet}} est plus proche, puisque celui-ci affiche le contenu du tweet, c'est-à-dire qu'il en fait la citation).
Je pourrais suggérer de renommer {{citation tweet}} en {{référence tweet}}, qui est une meilleure traduction, et au nom plus descriptif que seulement {{tweet}} (de cette proposition d'inversion de noms). Ça laisserait le champ libre au {{tweet}} actuel, que l'on pourrait laisser nommé tel quel ou renommer en {{citation tweet}}.
od†n ↗blah 23 mars 2022 à 19:34 (CET)

Raccourci supplémentaire

modifier
Dernier commentaire : il y a 2 ans1 commentaire1 participant à la discussion

Bonsoir, je souhaiterais rajouter le raccourci « W:{{}} », qu'en pensez-vous ? Bien à vous Manjiro5 [💬] 23 mars 2022 à 18:52 (CET)

Caractères spéciaux et Modèle:Article supprimé

modifier
Dernier commentaire : il y a 2 ans9 commentaires3 participants à la discussion

Bonjour,

Les caractères spéciaux sont mal gérés par {{Article supprimé}}, la petite corbeille (nuke icon) renvoie vers un lien illisible dans quelques cas. Par exemple, pour Maison & Objet (débat), on obtient ce lien.

Peut-on appliquer une transformation des caractères spéciaux vers des caractères gérés par HTML au sein de {{urlencode:{{#if:{{ARTICLESPACE}}|{{ARTICLESPACE}}:}}{{BASEPAGENAME}}}} ?

  Pour info @SleaY

Bien à vous, LD (d) 29 mars 2022 à 22:06 (CEST)

La solution est probablement de remplacer par ça par {{#if:{{ARTICLESPACE}}|{{ARTICLESPACEE}}:}}{{PAGENAMEE}}}}, sans le urlencode:. Cf. mw:Help:Magic words#URL encoded page names. — Zebulon84 (discuter) 30 mars 2022 à 10:10 (CEST)
Merci @Od1n pour ton intervention, cela ne résoud pas encore le problème mais on avance   (boutade à part, c'est pour te mettre dans la boucle). LD (d) 31 mars 2022 à 05:07 (CEST)
En gérant aussi la situation pour le motif de suppression, pour l'instant ma moins pire solution est :
?title={{#if:{{ARTICLESPACEE}}|{{ARTICLESPACEE}}:}}{{BASEPAGENAMEE}}
&action=delete
&wpReason=%5B%5B{{TALKSPACEE}}:{{BASEPAGENAMEE}}{{urlencode:/Admissibilité{{!}}Décision communautaire}}%5D%5D
  • J'ai remarqué que ça bug quand on fait précisément {{urlencode:[[}} (c'est le genre de bug sur des edge cases que l'on rencontre quelquefois dans le parseur de MediaWiki, difficile à corriger), d'où le recours au %5B%5B.
  • Par rapport au code actuel, avec ce code ça ajoute des underscores dans le motif de suppression (exemple : [[Discussion:Maison_&_Objet/Admissibilité|Décision communautaire]]), mais le résultat après publication reste le même, et ça reste moins moche (et je trouve plus sûr) que [[Discussion:Maison &#38; Objet/Admissibilité|Décision communautaire]].
od†n ↗blah 31 mars 2022 à 05:16 (CEST)
Merci Od1n  , en effet l'URL encoding me semble préférable à mon idée de transformation qui serait très probablement lourde et coûteuse. En soi un peu plus de lisibilité avec des underscore auxquels la communauté (moi compris) est, il me semble, plus habituée ne fait pas de mal.
Ceci dit, je suis incapable de dire si la proposition de Zebulon84 fonctionnerait tout autant vu la liste des tâches Phabricator sur le même sujet : il semblerait qu'il faut faire un choix par défaut, merci pour ta réponse également.
Sauf si une solution est mise en place et fonctionne, je testerais les deux. LD (d) 31 mars 2022 à 06:09 (CEST)
En fait j'ai justement mis en œuvre la solution de Zebulon84, qui corrige effectivement le problème, tout en continuant d'utiliser urlencode pour le reste. od†n ↗blah 31 mars 2022 à 06:13 (CEST)
N'étant plus admin, je ne pouvais pas tester la deuxième partie de l'URL, et je me suis dit que d'une part c'était moins important, d'autre part la solution devrait être facile à trouvé par l'admin qui ferait la modif. Merci od†n. — Zebulon84 (discuter) 31 mars 2022 à 06:20 (CEST)
La fatigue ou la précipitation, j'ai cru que urlencode était encore dans le titre. @Zebulon84, on peut te créditer cette trouvaille voyons ! LD (d) 31 mars 2022 à 06:21 (CEST)
Si tu veux tester la deuxième partie, en faisant à la place un lien de renommage (la page doit être existante) :
|link=https://fr.wiki.x.io/wiki/Sp%C3%A9cial:Renommer_une_page/{{#if:{{ARTICLESPACEE}}|{{ARTICLESPACEE}}:}}{{BASEPAGENAMEE}}
?wpReason=%5B%5B{{TALKSPACEE}}:{{BASEPAGENAMEE}}{{urlencode:/Admissibilité{{!}}Décision communautaire}}%5D%5D
od†n ↗blah 31 mars 2022 à 06:58 (CEST)

Demande de modification pour Modèle:Infobox Commune de Suisse

modifier
Dernier commentaire : il y a 2 ans3 commentaires2 participants à la discussion

Bonjour, j'ai modifié il y a quelques mois l'infobox pour qu'elle affiche la carte du district en français si elle existe (cela faisait partie d'une idée que j'ai lancé sur le projet Suisse qui consistait à traduire ces cartes). Cela se fait avec la partie du code suivante :

<!-- test si carte française existe ; si carte française n'existe pas, carte allemande --> {{#ifexist: Media:{{{carte|Carte commune {{{nomcarte|{{{nom}}}}}} {{{annéecarte|2007}}}.png}}}|{{{carte|Carte commune {{{nomcarte|{{{nom}}}}}} {{{annéecarte|2007}}}.png}}} |<!-- -->{{#ifexist: Media:{{{carte|Karte Gemeinde {{{nomcarte|{{{nom}}}}}} {{{annéecarte|2007}}}.png}}}|{{{carte|Karte Gemeinde {{{nomcarte|{{{nom}}}}}} {{{annéecarte|2007}}}.png}}} |<!-- -->}}}}

Au final je n'ai fait que rajouter un ifexist avec le nom de la traduction française des images. Je me rends cependant compte maintenant que, sur le long terme, cette façon de faire n'est pas viable. En effet, ces cartes sont créées et tenues à jour par un contributeur allemand, et les fusions de communes font qu'au fil du temps les cartes en français ne seront plus à jour. C'est déjà le cas pour un certain nombre de communes, qui sont regroupées dans la catégorie Maintenance Infobox Commune Suisse/carte inconnue.

Ma demande est ainsi la suivante : j'aurais besoin de trouver un moyen de créer une condition qui fait que, si une carte plus récente existe en allemand, elle soit préférée à la carte francophone. J'aurais bien essayé moi-même, mais j'avoue ne pas comprendre comment le paramètre annéecarte fonctionne (l'infobox n'a pas ce paramètre, et malgré que l'année indiquée soit 2007 le modèle va tout de même chercher des cartes de 2022).

Pour info, toutes les cartes se trouvent dans la catégorie Commons Maps of municipalities of Switzerland by canton. Merci d'avance, salutations, Espandero (discuter) 2 avril 2022 à 10:13 (CEST)

Bonsoir Espandero  . L'infobox Commune de Suisse possède bien le paramètre annéecarte même si il n'est pas assez documenté. Un exemple d'utilisation est sur Fribourg (ville suisse), où annéecarte = 2021 déclenche l'affichage de File:Karte Gemeinde Fribourg 2021.png. Via ce paramètre il est donc possible d'afficher la carte en allemand que l'on souhaite, au cas par cas, en indiquant sa date.

Si on veut que l'infobox cherche automatiquement la carte la plus récente, cela veut dire ignorer le paramètre annéecarte. On afficherait la carte en français de 2022 si elle existe, sinon la carte en allemand de 2022 si elle existe, sinon la carte en français de 2021 si elle existe, etc. Techniquement cela pourrait se faire par un sous-modèle appelant une grande suite de #ifexist emboîtés (un peu lourd mais je ne vois pas comment faire autrement en wikicode). Une solution plus propre serait un module en Lua faisant une boucle for descendante, mais je maîtrise un peu moins le Lua. Une autre solution propre serait que le contributeur qui crée régulièrement ces cartes mises à jour les indique aussi à chaque fois sur Wikidata en tant que P242 (« carte de localisation »), mais force est de constater que ce n'est pas fait : en terme de fréquence des mises à jour on semble avoir Wikidata < Wikipédia en français < Wikipédia en allemand. Salutations, --l'Escogriffe (✉) 3 avril 2022 à 02:45 (CEST)
Merci beaucoup pour la réponse. Je pense qu'en comprenant mieux le paramètre annéecarte je devrais pouvoir faire quelque chose. Peut-être que je vais simplement créer un nouveau modèle juste pour choisir la carte, ça permettra de faire un code plus complet sans polluer le code de l'infobox. Salutations, Espandero (discuter) 4 avril 2022 à 20:19 (CEST)

Déploiement de liens vers wstat

modifier
Dernier commentaire : il y a 2 ans12 commentaires8 participants à la discussion

Bonjour,

L'outil wstat créé par Orlodrim est fort utile à la maintenance des modèles (je dois l'habitude de son utilisation à Ideawipik). J'ai créé le modèle {{wstat}} qui lie vers les statistiques d'un modèle de façon très simple :

  1. {{wstat}} : Veuillez indiquer le nom d'un modèle. (car on n'est pas sur l'espace de nom modèle)
  2. {{wstat|Infobox Biographie2}} : Voir les statistiques d'utilisation du modèle sur wstat.
  3. {{wstat}} apposé sur Modèle:Infobox Biographie2/Documentation : même résultat qu'en 2., voir en bas de la sous-page.

J'aimerais le déployer massivement en pied de page des documentations de modèle, dans une section Statistiques. Qu'en pensez-vous ? --l'Escogriffe (✉) 19 avril 2022 à 22:21 (CEST)

Bonsoir GrandEscogriffe  . Plutôt qu'un déploiement massif, il avait été proposé (je ne retrouve pas où) de l'ajouter au modèle {{Documentation}}. Comme ça tous les modèles en profiteraient. Puisque cet outil externe lui appartient, l'autorisation avait été demandée à Orlodrim et il n'avait pas répondu. J'y suis bien évidement favorable, ainsi que pour les modules. --FDo64 (discuter) 19 avril 2022 à 23:01 (CEST)
Très belle initiative. Totalement favorable ! Si il était possible d'afficher directement sur chaque page de modèle le nombre d'erreurs, le nombre d'utilisation, etc, ça serait encore mieux. Exemple :
== Statistiques ==
  • Inclusions directes : 309 958
  • Pages distinctes : 309 882
  • Pages utilisant la redirection {{Infobox Biographie 2}} : 1293
  • Pages utilisant la redirection {{Infobox biographie2}} : 25345
  • Erreur recensées : 203
Plus d'informations sur l'utilisation de ce modèle.
- Thomas #Talk 19 avril 2022 à 23:03 (CEST)
Conflit d’édition —Bonjour GrandEscogriffe, un lien vers Wstat est déjà présent sur toutes les pages de discussion / d'historique « Pages liées » des modèles. Pour ma part, j'ai activé un "gadget personnel" permettant d'ajouter un lien dans la colonne latérale (en l'occurrence "section" « Outils ») depuis les pages de modèle et leurs sous-pages de documentation. Voici le code correspondant à une possibilité parmi d'autres. Il est à ajouter dans sa sous-page .js de personnalisation.
if (mw.config.get('wgCanonicalNamespace') == "Template") {
    $(function () {
      mw.loader.using( 'mediawiki.util', function () {
        var wstemplateurl = 'https://wstat.fr/template/info/' + mw.config.get('wgTitle').split('/Documentation')[0].replace(" ", "_"); /* On aurait aussi pu utiliser replace(/\/Documentation.“étoile”/, '') */
        mw.util.addPortletLink('p-tb', wstemplateurl, 'Wstat', 'r-ws', 'Wstat');
      });
    });
}
Preneur de remarques et suggestions d'amélioration. Le lien serait peut-être à rendre plus imposant. Techniquement, il serait possible de le déplacer dans une nouvelle "section" du panneau latéral. À voir avec le projet:Scripts et gadgets.
Je pense que ce type de personnalisation, voire l'intégration aux gadgets si la demande existe, est préférable à l'ajout d'un modèle sur un nombre conséquent de pages de documentation. Mais attendons l'avis d'autres modélistes et relecteurs. Cordialement, — Ideawipik (discuter) 19 avril 2022 à 23:04 (CEST)
PS : L'alternative systématique au sein de {{Documentation}} est également intéressante. Le texte « statistiques d'utilisation du modèle » que tu as choisi dans le modèle est préférable à « Plus d'informations sur l'utilisation » qui pourrait faire croire à un lien vers l'aide ou la documentation du modèle.   Thomasbr33, il vaut mieux rester simple/sobre, notamment afin de ne pas surcharger les pages d'information dispensable et parce que l'outil est partiellement soumis à l'actualisation des TemplateData (notamment pour les modèles "Lua") et possède une réactivité propre (mise à jour bimensuelle). Donc le nombre d'utilisations erronées ne veut pas dire grand-chose : l'important est la vérification des appels "problématiques" relevés par rapport au fonctionnement présent du modèle. Ces éléments à connaître pour bien utiliser l'outil seraient sans doute à mettre en évidence ou rappeler si son exposition était augmentée. — Ideawipik (discuter) 20 avril 2022 à 00:11 (CEST)
Bonjour.
Favorable à l'idée de généraliser wstats dans la documentation, ou les différents espaces.
@Thomasbr33, théoriquement, tu as « infos diverses » dans les pages liées d'un modèle.
Pour info, il existe CustomSidebar qui permet de créer une boîte de menu personnalisable, sinon voir le manuel Manual:Interface/Sidebar pour un outil plus personnel, voire cette documentation sur l'ajout de lien.
Tout comme MediaWiki:Gadget-NavigAdmin.js, il est possible de créer un gadget pour les liens les plus utilisés par les modèlistes, ils restent néanmoins à définir. LD (d) 19 avril 2022 à 23:40 (CEST)
Conflit d’édition —   GrandEscogriffe, FDo64, Thomasbr33, Ideawipik et LD : Je suis favorable à l'ajout de wstat.fr (que j'utilise tous les jours), mais à faire via {{Documentation}}. Histoire que ce soit déployé partout de manière systématique, sans perte de temps, et sans dépendre de la mise en page de chaque doc (doc qui n'existe parfois même pas).
L'ajout d'un lien systématique vers wstat.fr par {{Documentation}} fait d'ailleurs partie des choses qui me sont déjà venues à l'esprit ces dernières années (comme 50 millions d'autres), mais manque de temps toujours...
Déployer massivement manuellement un tel modèle sur toutes les documentations de modèles n'a pas de sens. Cet outil peut s'utiliser avec tous les modèles, donc c'est typiquement un truc à gérer automatiquement. On ne doit pas à avoir perdre de temps à apposer un tel modèle manuellement.
On pourrait envisager que ce lien soit automatiquement ajouté en fin de documentation, juste au-dessus du « La documentation de ce modèle est générée par le modèle ... ». On pourrait le faire suivre d'une seconde ligne horizontale (hr), afin de séparer clairement ce qu'il y a au-dessus (il n'y a pas toujours un modèle {{Projet}}), et ce qu'il y a dessous (les divers liens et explications relatifs au système de documentation/bac à sable/test du modèle).
L'importance de cet outil dans le cadre de la maintenance fait qu'il devrait être accessible (et que les contributeurs puissent ainsi découvrir son existence !) sans passer par les pages liées ou un gadget/common.js.
--Tractopelle-jaune (discuter) 19 avril 2022 à 23:46 (CEST)
Bonjour Tractopelle-jaune. Je suis d'accord avec toi, l'outil est actuellement à deux clics mais il faut d'abord le découvrir avant de l'adopter. La solution envisagée le ramènerait sur la page du modèle avec une plus grande visibilité. Deux remarques.
  • Il faudra absolument décrire les limites factuelles de cet outil, liées aux défauts humains de documentation des modèles et à sa fréquence de mise à jour, à partir des dépôts. Ceci pour éviter des "corrections" qui n'en sont pas, avec retrait de données valides.
  • Coté serveur, on peut supposer que la fréquentation du site d'Orlodrim augmentera. Y-a-t-il des limites techniques de ce coté ? Sait-on jamais… — Ideawipik (discuter) 20 avril 2022 à 00:11 (CEST)
Conflit d’édition —Vous avez raison, une inclusion dans {{Documentation}}, c'est-à-dire si j'ai bien compris dans le code du module:Documentation, est sans doute le mieux (j'avais pensé à mettre le lien dans le bandeau {{Sous-page de documentation}} ce qui n'est pas top mais {{Documentation}} m'avait échappé). Favorable à la proposition de Tractopelle-jaune.
Si on fait cela je pense réorienter {{wstat}} vers un simple raccourci pour les discussions. {{wstat|Oui}} rendrait Oui. --l'Escogriffe (✉) 20 avril 2022 à 00:21 (CEST)
Je connaissais l'outil wstat (trop bien, dommage qu'il n'existasse pas sur les autres langwikis) et j'avais mis un lien côté Doc dans un de mes modèles donc totalement +1 pour une inclusion en Documentation ;) Bouzinac (discuter) 20 avril 2022 à 09:04 (CEST)
Bonjour, vous pouvez mettre un lien où vous voulez. Je ne pense pas être très bien placé pour dire si c'est une bonne idée ou pas. S'il y a un lien quelque part, ce serait bien d'indiquer que c'est un outil externe (comme c'est déjà le cas dans Spécial:Pages liées). Orlodrim (discuter) 23 avril 2022 à 10:40 (CEST)

  Orlodrim, Bouzinac, Ideawipik, Tractopelle-jaune, FDo64, Thomasbr33 et LD : c'est fait sur Module:Documentation. J'en profite pour créer une ébauche d'aide sur cet outil, à compléter. --l'Escogriffe (✉) 25 avril 2022 à 03:30 (CEST)

DOI dans le module:Biblio

modifier
Dernier commentaire : il y a 2 ans1 commentaire1 participant à la discussion

Bonjour 

Je recopie ici mon message laissé sur la PdD du module:Biblio, car elle semble peu visitée...

Merci de répondre là-bas : Discussion module:Biblio#DOI

Parfois les contributeurs ne savent pas quelle partie du lien du DOI choisir et cela rend le lien inutile, amenant sur une page d'erreur.

Par exemple, https://dx.doi.org/10.1515/9783110431070-018/html (le /html est en trop) sur Wikipédia:Trollage (voir [2]).

Il faudrait que les liens soient vérifiés et qu'un message d'erreur soit affiché si le DOI n'est pas correct.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 22 avril 2022 à 18:55 (CEST)

Modèles relatifs aux millénaires

modifier
Dernier commentaire : il y a 2 ans6 commentaires5 participants à la discussion

Bonjour. Voici quelques explications, notamment pour Golmote. Il me semble inutile de générer des paramètres obsolètes dès la création d'un modèle. C'est pourquoi j'ai simplifié les documentations et le code des modèles récemment créés (en janvier 2022) parmi ceux de Catégorie:Modèle de millénaire. En ce qui concerne les modèles qui existaient déjà, le constat sur les utilisations est le suivant :

J'ai l'impression que les modèles Mi2(-) n'ont jamais été utilisés. Mais vérifier dans l'historique complet de Wikipédia serait un peu long, même pour un programme informatique. L'ancienne syntaxe doit être conservée dans les codes de ces modèles afin que les anciennes versions des articles restent lisibles, mais peut-être qu'un jour il y aura prescription et seules les syntaxes courtes seront de mise dans les articles ainsi que dans le code des modèles. Il y a bien des modèles qui ont été renommés, supprimés ou réutilisés pour un usage totalement différent qui altèrent l'affichage des vielles versions de certaines pages. En attendant, je pense qu'on peut simplifier les documentations et TemplateData des modèles pour lesquels l'ancienne syntaxe n'est pas ou plus usitée.   Tractopelle-jaune, ayant réagi à la proposition en début d'année, ou FDo64, avez-vous un avis à ce sujet ?

Remarque typographique. Les ordinaux romains pour les siècles sont en petites capitales (c'est la convention adoptée et trouvée dans le Lexique…). Est-il cohérent que les millénaires soient indiqués, via ces modèles, en grandes capitales ? – Ideawipik (discuter) 12 mai 2022 à 22:17 (CEST)

Bonsoir, puisqu'on me demande mon avis : je suis très favorable à la simplification de ces modèles sur l'exemple des modèles de siècles. Et si peu d'articles sont touchés (j'en suis surpris), alors leur appliquer la nouvelle syntaxe et simplifier la documentation. --FDo64 (discuter) 12 mai 2022 à 22:41 (CEST)
Merci @FDo64. Les deux syntaxes sont déjà valides. Je n'ai listé ici que des modèles affichant deux millénaires et dont le passage dans leur code à la seule syntaxe simplifié altérerait le rendu des anciens appels. Pour les modèles affichant un seul millénaire, la simplification déjà effectuée ne pose pas problème. Cela laisse juste, dans les appels, des paramètres inutilisés résiduels qui sont et seront peu à peu retirés au gré des éditions humaines ou par bots, comme pour les siècles.
Une liste complète de modèles est disponible sur Utilisateur:Golmote/Proposition de refonte des modèles millénaire.
– Ideawipik (discuter) 12 mai 2022 à 23:01 (CEST)
  Ideawipik : J'approuve la simplification du code des modèles concernés. Ça évite aussi de risquer de voir (ré-)apparaître ces paramètres dans les données TemplateDta (en cliquant sur ajouter les paramètres absents).
Concernant le maintien de la lisibilité des anciennes versions des pages (donc appelant d'anciens modèles supprimés ou d'anciennes syntaxes de modèles), la meilleure solution reste Internet Archive pour consulter correctement ces pages. Car les modèles ont de manière générale tellement évolué depuis 20 ans ; ils ont changés de noms, de paramètres, de syntaxe, que ça ne vaut pas la peine de vouloir maintenir cette rétro-compatibilité pour des modèles « mineurs ». Il ne s'agit que de simples modèles formatant l'affichage de millénaires, relativement peu utilisés (comparés aux modèles des siècles)...
Je suis d'accord pour maintenir une certaine rétro-compatibilité pendant un certains temps pour les modèles importants (infobox, génération de tableaux, listes, etc) ET que les contraintes en résultant ne sont pas disproportionnées sur le code du modèle. Et bien entendu que cela n'entrave aucunement l'évolution ou la simplification de l'utilisation d'un modèle.
Mais pas pour des modèles secondaires, peu utilisés, ou assurant un simple formatage, où l'absence de rétro-compatibilité ne fait que provoquer de légers problèmes d'affichage/mise en forme ou la perte d'informations mineures et isolées.
On doit viser une optique de simplification de l'utilisation des modèles et de réduction de la maintenance du code et de la documentation des modèles.
Pour les modèles en questions (qui sont des modèles de formatage, d'importance mineure), mon avis personnel :
  1. À partir du moment où (plus) aucune page n'utilise la syntaxe obsolète (directement ou via un autre modèle), on peut les supprimer à la fois du code du modèle et de la documentation.
  2. Si elle est encore utilisée dans certaines pages, soit on peut décider de l'éliminer de manière anticipée (genre s'il n'y a que 5-10 pages), puis cas #1 ; sinon on conserve en l'état le code, et on marque le paramètre comme déprécié (obsolète) dans TemplateData, éventuellement en indiquant ce qu'il y a lieu de faire.
--Tractopelle-jaune (discuter) 13 mai 2022 à 13:05 (CEST)
La question de la visualisation de l'historique est un serpent de mer de la modification de modèle. Je rejoins l'avis de Tractopelle-jaune sur ce point : tenter à tout prix de maintenir la lisibilité du rendu de l'historique est à mon sens une tâche impossible et pas forcément nécessaire. Les modèles changent de nom, le nouveau nom est utilisé par un autre modèle, les paramètres évoluent et font qu'une rétro-compatibilité est impossible à maintenir sans surcharger le code du modèle, etc. Vu le nombre de modèles en circulation, leur diversité et leur complexité générale, à mon sens, maintenir cette compatibilité relève de l'utopie, et ne concerne très probablement qu'une minorité d'utilisateurs : on a tendance à l'oublier lorsque l'on est au fait des rouages techniques de MediaWiki, mais une majorité d'utilisateur ne font que consulter la version actuelle de la page... C'est donc beaucoup d'efforts pour peu d'effet. Je suis donc partisan de ne pas se préoccuper outre mesure de cette rétro-compatibilité, sauf bien entendu si il est possible de le faire simplement et sans effort surnuméraire. Mais supporter explicitement des paramètres obsolètes est à mon avis contre-productif en raison du risque de voir des utilisateurs les utiliser sur de nouveaux appels, n'étant pas au fait de leur obsolescence.
Wikipédiennement, Epok__ (✉), le 14 mai 2022 à 08:48 (CEST)
@Ideawipik Bonjour ! Effectivement, gérer les anciennes syntaxes des modèles de siècle n'était certainement pas nécessaire pour les millénaires. Cela rendait juste l'opération plus simple pour moi de reprendre précisément le comportement des modèles de siècle. Je suis totalement pour la simplification également.
Concernant ta remarque typographique, les modèles n'étaient pas tous cohérents entre eux avant la refonte. J'ai uniformisé en utilisant les grandes capitales, en suivant les recommandations du Lexique (« On emploie les chiffres romains grandes capitales pour numéroter les millénaires », chapitre « Millénaires » page 118). --Golmote (discuter) 14 mai 2022 à 09:26 (CEST)

Modèle:Déco ajout date

modifier
Dernier commentaire : il y a 2 ans3 commentaires2 participants à la discussion

Bonjour, serait-il possible pour les modèles Déco série Déco Chevalier ou suivants de l'Ordre des Saints-Maurice-et-Lazare ou Déco Chevalier ou suivants de la Légion d'honneur, d'ajouter un emplacement Date

Par exemple : Mathias_Arminjon#Décoration, ici pour l'année et parfois pour les références, les informations renvoyées à la ligne.

Merci, B-noa (discuter) 18 mai 2022 à 12:25 (CEST)

Bonjour B-noa. Plutôt que de se voir ajouter un paramètre, les modèles ont reçu la même forme que les modèles équivalents, offrant plus de souplesse. La note présente était paradoxale. Outre la page Mathias Arminjon, les articles Auguste Lumière, Constant Despine, Joseph-Louis-Thomas Girod et Prosper de Fleury ont maintenant besoin d'un ajout d'espace juste après l'appel du ou des modèles. Cordialement. — Ideawipik (discuter) 18 mai 2022 à 14:00 (CEST)
  Ideawipik :, c'est tout à fait ça, merci ! --B-noa (discuter) 18 mai 2022 à 16:41 (CEST)

Problème de modèle dans les apps

modifier
Dernier commentaire : il y a 2 ans4 commentaires3 participants à la discussion

Bonjour à tous et à toutes, my apologies for writing in English.

There is a French Wikipedia template problem which is especially obvious in the Android app, where we end up with a rather ugly result because the template ends up on the same level as the header. We've tried to describe it in this task: phab:T306281 (especially in phab:T306281#7945720).

We don't want to interfere with your work, but we hope you'd be interested in fixing this. Please let me know if you have any questions. Johan (WMF) (discuter) 24 mai 2022 à 10:19 (CEST)

Il y a 30 000 pages d'homonymie avec le modèle Autre projet (petscan), souvent en haut, donc pas mal de pages concernées.
La solution est peut-être d'ajouter dans /styles.css une règle @media(max-width:xxx) du style .autres-projets + h2 { clear:right; }. Ou .autres-projets { float:none; } ou encore .autres-projets { display:none }.
Ceci peut aussi être plus général pour .boite-a-droite (mais ou pour être pris en compte par l'app mobile ?)
Qu'en pensez-vous ?
— Zebulon84 (discuter) 24 mai 2022 à 11:39 (CEST)
Bonjour. Remarque connexe. L'exemple (capture d'écran) relevé dans Phabricator montre un mot écrit à la verticale. Sur une version bureau, si on a un des premiers mots du titre assez long et un écran étroit, l'habillage Vector peut conduire à un titre masqué partiellement ou totalement par le cadre latéral de droite. La dernière version de Vector (2022) semble avoir résolu ce problème. (exemple1 vector2010, exemple1 vector2022, exemple2 vector2010, exemple2 vector2022). En version mobile (exemple1 fr.m.wiki.x.io), le modèle affiche un « Sur les autres projets Wikimedia : » centré et le ou les éléments à gauche, sans "float" particulier. Quelles sont les applications concernées ? Aide:Mobile ?
Une des deux premières solutions semble bien. Juste une question pour la première : quid des niveaux de titre h3, h4… (voir exemple2) ? — Ideawipik (discuter) 25 mai 2022 à 01:47 (CEST)
  Fait pour autre projet.
Mais il y a d'autres modèles qui utilisent la class boite-a-droite qui peuvent avoir le même problème, sans parler de tout ceux qui ont un float:right; directement dans le code.
Faut-il créer systématiquement un TemplateStyle pour gérer ça, ou est-il préférable d'ajouter du code (et peut-être une class générique) dans MediaWiki:Common.css ?  — Zebulon84 (discuter) 27 mai 2022 à 00:21 (CEST)

Modèle affichant la liste des contributions d'un utilisateur

modifier
Dernier commentaire : il y a 2 ans6 commentaires2 participants à la discussion

Hello,

Est-ce que quelqu'un sait s'il existe un modèle permettant d'afficher la liste des contributions d'un utilisateur selon certains critères ? Par exemple : la liste des articles traduits ?

Merci d'avance !

PS : Voir ma page utilisateur que j'aimerai automatiser. Thomas #Talk 29 mai 2022 à 20:46 (CEST)

Salut   Thomasbr33,
Tu peux transclure directement ta liste de contribs via un {{Spécial:Contributions|target=Thomasbr33|namespace=0|tagfilter=contenttranslation}}
Aperçu
Le compte d’utilisateur « Thomasbr33 » n’est pas enregistré.

Aucune modification correspondant à ces critères n’a été trouvée.

 

--Tractopelle-jaune (discuter) 29 mai 2022 à 22:40 (CEST)

@Tractopelle-jaune Ah super ! J'y avait pas pensé du tout ! Merci beaucoup ! Thomas #Talk 29 mai 2022 à 23:06 (CEST)
@Tractopelle-jaune Par hasard, tu ne saurais pas comment afficher juste le titre des pages ? Thomas #Talk 29 mai 2022 à 23:10 (CEST)

┌─────────────────────────────────────────────────┘
   Thomasbr33 : tiens mon petit, un modèle tout juste sorti du four (attention il est peut-être encore un peu chaud) : {{Liste des contributions}}.

S'il n'est pas possible d'agir sur le code HTML issu d'une transclusion de page spéciale, il est possible d'agir sur la mise en page grâce à l'extension TemplateStyles.

J'ai donc créé un modèle, qui transclus la page spéciale, puis la met en forme via la feuille de style Modèle:Liste des contributions/styles.css selon la présence ou non de certaines classes. Et pour l'accompagnement, j'ai fait la petite documentation qui va bien pour comprendre comment ce servir de tout ça (y inclus le TemplateData, cela va de soit).

Et donc en primeur, voici un modèle paramétré selon tes désirs :

Titre uniquement
{{Liste des contributions|utilisateur=Thomasbr33|espace=0|balise=contenttranslation|nombre=500|masquer date=oui|masquer liens=oui|masquer octets=oui|masquer symboles=oui|masquer résumé=oui|masquer balises=oui}}
Le compte d’utilisateur « Thomasbr33 » n’est pas enregistré.

Aucune modification correspondant à ces critères n’a été trouvée.

 

Ou par exemple avec la date et l'heure en plus

Date/heure et titre
{{Liste des contributions|utilisateur=Thomasbr33|espace=0|balise=contenttranslation|nombre=500|masquer liens=oui|masquer octets=oui|masquer symboles=oui|masquer résumé=oui|masquer balises=oui}}
Le compte d’utilisateur « Thomasbr33 » n’est pas enregistré.

Aucune modification correspondant à ces critères n’a été trouvée.

 

Alors satisfait cette fois ?  

N'hésite pas en cas de question ou pour implémenter d'autres paramètres ou options de mise en page.

Bonne journée (et désolé pour le retard, mais je n'ai pas eu le temps de m'en occuper avant).

--Tractopelle-jaune (discuter) 1 juin 2022 à 10:20 (CEST)

On t'a déjà dit que tu étais quelqu'un de génial ?
Plus sérieusement, je regarde ça tout à l'heure !
Encore merci ! Thomas #Talk 1 juin 2022 à 13:22 (CEST)

Multiplicité de modèles affichant une syntaxe de modèle

modifier
Dernier commentaire : il y a 2 ans10 commentaires4 participants à la discussion

Pour citer du wikicode, dans le cas des paragraphes ou citations de plusieurs lignes, on peut utiliser les balises <pre> ou <syntaxhighlight lang="moin">.

Pour de courts extraits, outre <syntaxhighlight lang="moin" inline>, il est possible d'écrire le code entre balises <code> et <nowiki>, cette dernière afin que le code ne soit pas interprété. Il existe aussi de nombreuses possibilités via des modèles. Pas forcément plus simples et pas toujours bien utilisés (y compris par des bots,   Linedwell) comme le montrent les statistiques pour {{M}}.

Voici une comparaison de quelques modèles identifiés.

Comparaison des modèles
Modèle Lien interne Insécable Balise Accepte argument vide Gère le = sans avoir besoin de recourir à {{=}} Nombre max de param. positionnels Notes (en gras les défauts, inconvénients, limitations)
Statistiques approximatives d'utilisation.
{{m}} oui non – non non 9 Stats : 89 961 pages distinctes.
{{m-}} non non – non non 9 Une infobulle mais plutôt gadget
Stats : 36 pages distinctes.
{{mdl}} non non <kbd> non non 9 Attention ! Ce modèle introduit un caractère {{!}} qui peut interférer avec la syntaxe des tableaux et altérer l'affichage ; Il serait préférable qu'il utilise dans son code le caractère &#124;
Stats : 13 141 pages distinctes.
{{mpl}} oui non – oui mais limité à un non 1 Paramètre "2" obligatoire, celui permettant d'indiquer un paramètre. Pas d'autres paramètres : besoin de solliciter {{!}} ou &#124; pour en afficher plusieurs
Stats : 2 pages distinctes dont un brouillon utilisateur.
{{Lien vers modèle avec paramètres}} / {{tlx}} oui non – non non 10, puis affiche « … » Stats : 3 868 pages distinctes.
{{tlc}} non oui <code> oui non 8 Stats : 205 pages distinctes.
{{tld}} non oui par défaut (cf paramètre dédié) <code> oui non 10, puis affiche « … » Possède un paramètre subst de substitution et un paramètre allowlinebreak pour autoriser le passage à la ligne.
Repose sur un méta-modèle {{tlg}} qu'uniquement lui sollicite.
Stats : 9 pages distinctes ; un seul appel du paramètre allowlinebreak.
{{mpn}} oui non – non oui sans limite, mais les affiche à la fin, après les paramètres non nommés et dans un ordre douteux. Incompatible avec la substitution. 9 Possède un paramètre namespace présentant peu d’intérêt, sauf pour cibler un "modèle" hébergé dans un espace autre que « Modèle: »

L'ordonnancement des paramètres nommés est assez étrange et ne respecte pas l'ordre préconisé. Exemple : {{mpn|nom modèle|p1=|p2=|p3=|p4=|p5=}} affiche chez moi « {{nom modèle|p5=|p4=|p2=|p3=|p1=}} ».
Si le modèle est substitué, les paramètres nommés ne s'affichent plus.
En outre, l'autorisation d'une infinité de paramètres nommés pose un problème de renseignement du TemplateData.
Stats : une seule page concernée. Paramètre namespace inutilisé.

Exemples
Modèle Rendu (figé au 24 mai 2022) {{Modèle|nom modèle|nommé1=valeurnom1|num1|num2||num4|nommé2=|num5|num6|num7|num8|num9|num10|num11|num12}}
m {{nom modèle|num1|num2|num4|num5|num6|num7|num8|num9}}
m- {{nom modèle|num1|num2|num4|num5|num6|num7|num8|num9}}
mdl {{nom modèle|num1|num2|num4|num5|num6|num7|num8|num9}}
mpl {{nom modèle|num1}}
lmp / tlx {{nom modèle|num1|num2|num4|num5|num6|num7|num8|num9|num10|...}}
tlc {{nom modèle|num1|num2||num4|num5|num6|num7|num8}}
tld {{nom modèle|num1|num2||num4|num5|num6|num7|num8|num9|num10|…}}
mpn {{nom modèle|num1|num2|num4|num5|num6|num7|num8|num9|nommé1=valeurnom1|nommé2=}}

Remarque générale : actuellement, aucun de ces modèles n'est écrit pour accepter une substitution propre (sauf le plus simple « mpl »).

Observations

Des fusions sont possibles afin de simplifier les choses pour le néo-contributeur. Des avis ? Notification à quelques créateurs des modèles   Pixeltoo, GLec, TomT0m et GrandEscogriffe. Merci par avance. — Ideawipik (discuter) 25 mai 2022 à 01:47 (CEST)

Bonjour Ideawipik, merci de m'avoir cité pour m'informer d'un usage incorrect du modèle {{m}} par LinedBot. Au vu de la page de statistiques (et des logs du bot) les appels avec des paramètres inexistants par le bot sont du fait que les utilisateurs ayant apposés les bandeaux d'origine sur les pages (que ça soit {{En travaux}}, {{En cours}} ou leurs nombreuses déclinaisons) l'ont fait avec ces mêmes paramètres (en effet, lors de la suppression du modèle, le bot récupère la liste de tous les paramètres pour la spécifier dans son Log). Conscient que cela semble désormais poser un problème, quelle serait la préconisation que tu proposerais ? Est-ce que remplacer l'utilisation du modèle {{m}} par {{m-}} (aussi bien dans les futures action du bot, que rétroactivement en corrigeant ses logs passés) serait une solution qui te conviendrait ? Cordialement, Linedwell [discuter] 25 mai 2022 à 08:43 (CEST)
Bonjour,
J'ai créé {{m-}} en septembre dernier pour aligner {{m}} sur l'usage, existant sur d'autres modèles, que l'ajout du tiret au nom du modèle retire le lien interne en gardant le même rendu. C'est le cas de {{date-}} et de {{s-}}. Plus généralement, sur des modèles comme {{a-}}, {{u-}}, ou {{notif-}}, la version avec tiret donne un rendu plus sobre que la version sans tiret (mais en gardant quand même un lien interne).
De plus {{m-}} est le seul des modèles listés plus haut a avoir un rendu sobre, sans lien interne ni code. Par contre il ne prend pas plus en compte que les autres les paramètres nommés, donc le mettre à la place de {{m}} ne changera rien sur ce point.
Favorable à faire des redirections parmi les autres modèles pour garder les plus performants. De la synthèse d'Ideawipik, je retiens qu'il y a quatre rendus possibles : texte simple ( {{m-}} ), mise en balise de code ( {{mdl}}, {{tlc}} et {{tld}} ), lien interne seulement sur le nom du modèle ({{mpl}} et {{lmp}}), ou lien interne couvrant tout le texte ( {{m}} et {{mpn}} ). On peut garder un seul modèle pour chaque rendu. l'Escogriffe (✉) 25 mai 2022 à 16:15 (CEST)
C’est quoi les cas d’utilisation d’une substitution ? — TomT0m [bla] 25 mai 2022 à 16:45 (CEST)

En ce qui concerne {{mpn}} : il suit une approche qui permet d’afficher les paramètres nommés grâce à un module en lua. Il n’y a pas moyen de récupérer l’ordre des paramètres nommés par ce biais, et les paramètres positionnels seront sans doute forcément dans l’ordre. Il y a moyen d’améliorer la gestion des paramètres numérotés vides par contre, et de faire sauter la limite du nombre de paramètres. Je vais m’y atteler si ça offre des trucs que les autres ne peuvent pas trop faire. — TomT0m [bla] 25 mai 2022 à 16:42 (CEST)

Bonjour Linedwell. Cas particulier pour ton bot. Remplacer m par m- ne résoudrait rien car le second ne gère pas davantage les paramètres nommés que le premier. Si on considère que le lien interne vers la page du modèle n'est pas indispensable, le plus simple serait d'utiliser directement la syntaxe <code><nowiki>{{…}}</nowiki></code> reproduisant tout le code du modèle. Sinon, on verra quel est le modèle le mieux adapté en fonction de la suite de la présente discussion. Peut-être {{tlx|Nom du modèle|<nowiki>liste des paramètres sans la barre verticale initiale</nowiki>}} ? Une autre possibilité est de conserver le lien et de limiter l'affichage au nom du modèle : {{m|Nom du modèle retiré/ajouté}} et éventuellement de l'accompagner d'un second lien vers la modification ([[Special:Diff/oldid|modif/retrait/ajout]]) (libellé à choisir).
Cas général pour l'affichage de paramètres nommés (donc avec présence d'un signe égal)
  • Soit on conserve le fonctionnement actuel qui impose à l'utilisateur de remplacer les « = » par {{=}} ou par &equals; ou de les entourer de balises <nowiki> ou de recourir au numéros explicites |n=param=valeur pour le nième paramètre du modèle appelé, i.e. le (n-1)ième "paramètre" du modèle cité (décalage lié au fait que le premier est le nom du modèle cité).
  • Soit on trouve une solution (à priori en Lua) permettant de reproduire tous les paramètres dans leur ordre d'entrée et en gérant les arguments vides qui ont un sens dans certains modèles à paramètres positionnels.
    • Dans ce cas, aucun paramètre optionnel de configuration ne serait disponible dans le nouveau modèle (ou alors avec un nom réservé à ce seul modèle et sans possibilité de se citer lui-même).
    • Je ne sais pas s'il est possible de faire comprendre à un modèle (TemplateData) que tous les noms de paramètres sont valides.   Tractopelle-jaune ?
    • Il n'est pas évident d'analyser le contenu des "paramètres" pour savoir comment interpréter les signes égal. Nombreux cas : déjà en nowiki, pour un attribut dans une balise à l'intérieur, dans un modèle imbriqué, dans un nom de modèle (typiquement {{=}}), en paramètre numéroté explicite (exemple : 2=blabla) mais cela se réfère-t-il au modèle de citation ou au modèle cité ?, etc.
L'avantage du fonctionnement actuel du modèle {{Lien vers modèle avec paramètres}} est de pouvoir mettre des liens vers plusieurs modèles lors d'appels imbriqués. Exemple : {{m|{{=}}}} affiché grâce au code {{tlx|m|{{tlx|1==}}}}.
Salut TomT0m. Pas vraiment d'intérêt de substituer ce modèle, c'était juste une observation. Pour les signes égal, s'il n'y a pas moyen de récupérer l'ordre des paramètres, je ne suis pas convaincu de la pertinence d'un affichage différent de celui souhaité par le rédacteur. — Ideawipik (discuter) 25 mai 2022 à 17:04 (CEST)
@Ideawipik parfois on s’en fiche un peu de l’ordre, il n’est pas significatif. L’avantage principal c’est qu’on peut facilement transformer un vrai appel pour faire une citation.
Par exemple dans une autre discussion sur un bug je viens de taper rapidement {{Wikidata|entity={{Qid|Antonie Ruset}}|P1559}}. Comment montrer l’appel sans trop de soucis à rajouter des balises ? juste rajouter « mpn| » devant suffit {{Wikidata|P1559|entity=Q541714}} à montrer l’idée. — TomT0m [bla] 2 juin 2022 à 19:56 (CEST)
Salut GrandEscogriffe, le modèle m-, avec son infobulle, n'est pas le plus sobre. À ce détail près, on obtient la même chose avec {{Tlg|nolink=oui|…}} qui intègre les arguments vides. Utilisable pour mutualiser, reste à voir les performances. — Ideawipik (discuter) 25 mai 2022 à 17:30 (CEST)
J'ai mis le bot à jour pour l'utilisation des balises code + nowiki pour les prochains runs. Si l'affichage n'est pas bugué, je ferai les remplacements dans les logs (et leurs archives) dans la journée de demain. Cordialement, Linedwell [discuter] 25 mai 2022 à 18:20 (CEST)
Si c'est utile, OK recoder m- avec {{tlg|nolink=oui}}. Pour moi l'important est qu'on puisse continuer à utiliser {{m-|...}} qui est de loin la syntaxe la plus intuitive une fois qu'on connaît {{m}} et les modèles à tiret. --l'Escogriffe (✉) 25 mai 2022 à 20:37 (CEST)

taille du logo pour modèle:Infobox Jeu de données

modifier
Dernier commentaire : il y a 2 ans3 commentaires2 participants à la discussion

Bonjour.

Je m'aperçois que le logo dans l'{{Infobox Jeu de données}} de Base Léonore est un peu petit. À mon avis, il devrait être de 280px de large pour remplir la largeur de l'infobox.

Ça doit être géré au niveau du Module:Infobox (ou peut être Module:Infobox/Jeu de données), mais je ne sais pas quoi modifier.

Merci de regarder ça de plus près, cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 10 juin 2022 à 11:34 (CEST)

Bonjour SyntaxTerror. Suite à modification sur le module Infobox/Jeu de données, c'est désormais réglé par le paramètre upright logo (mettre un coefficient de l'ordre 1, pas une taille en pixels). Le paramètre existait déjà mais non documenté et appelé de façon trompeuse « upright blason ». l'Escogriffe (✉) 10 juin 2022 à 14:26 (CEST)
Merci GrandEscogriffe. Il semble que upright logo = 1.5 soit le maximum, des valeurs plus grandes n'agrandissent pas l'image ou l'infobox (ce qui est souhaitable).
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 10 juin 2022 à 19:10 (CEST)

✔️ Problème Liste des chapitres de Kingdom

modifier
Dernier commentaire : il y a 2 ans11 commentaires4 participants à la discussion

Bonjour au projet

Existe-t-il un moyen de régler le problème d'un trop grand nombre de modèles sur une page ? L'article Liste des chapitres de Kingdom ne peut pas afficher l'intégralité de la page : « Attention : cette page contient trop d’inclusions de modèles. Certaines inclusions ne seront pas effectuées. »

Merci pour votre aide VKaeru crôa ? 23 juillet 2022 à 13:11 (CEST)

Apparemment ce n'est pas la nombre d'inclusions de modèles qui pose problème, c'est la « Taille d’inclusion après expansion » qui a atteint sa limite (2 097 152 octets). La meilleure solution semble donc de scinder la page. Alserv (discuter) 23 juillet 2022 à 15:38 (CEST)
Une solution à plus long terme serait sans doute de recoder le Modèle:Japonais en Lua. Le modèle n'est pas gros mais contient de multiples expansions de ses arguments, d'où sans doute le problème. Le modèle contient aussi beaucoup de #if, le Lua aiderait. Il contient aussi beaucoup d'appels au Modèle:Langue qui est déjà écrit en Lua et qui pourrait être appelé directement à partir d'un code Lua.
Mais les choses ne sont pas toujours aussi simples qu'il y paraît au premier abord, la question nécessiterait d'être analysée plus en détail.
-- Alserv (discuter) 23 juillet 2022 à 15:55 (CEST)
Le problème est la taille de la page finale. Recoder le modèle en Lua ne changerait rien au problème. (edit : en fait si, la taille calculée est actuellement démultipliée, voir messages suivants)
La première piste serait de réduire la quantité de markup généré. Par exemple, chaque petite icône d'aide avec son CSS inline, pèse 491 octets. Cependant, je n'ai pas étudié si réduire cela serait suffisant, ou s'il y a d'autres éléments de la page qui pèsent encore plus lourd.
Donc avant d'essayer d'alléger le markup, il faudrait déjà faire une estimation pour voir si cette approche serait suffisante pour permettre d'afficher la page, et sinon, il faudrait directement procéder au scindage de la page.
od†n ↗blah 24 juillet 2022 à 05:28 (CEST)
Pendant que je rédigeais mon message, Ideawipik a justement traité le problème : 195551465. od†n ↗blah 24 juillet 2022 à 05:35 (CEST)
Et effectivement, les #if imbriqués multiplient la taille calculée : en:Wikipedia:Post-expand include size. od†n ↗blah 24 juillet 2022 à 05:38 (CEST)
Et si on en croit 159343299, ce n'est pas la première fois qu'il y a des problèmes de poids avec ce modèle (bien entendu s'il est utilisé un grand nombre de fois sur la page). Aussi, il pourrait effectivement être judicieux de l'écrire en Lua, car il serait préférable d'avoir un seul require 'Module:Langue' suivi de plusieurs Langue.langue(), plutôt que actuellement plusieurs {{Langue}} qui iront exécuter plusieurs {{#invoke:Langue|langue}} (c'est-à-dire plusieurs chargements du module Langue). od†n ↗blah 24 juillet 2022 à 17:21 (CEST)
Bonjour od†n. Effectivement, entre les #if et les appels en cascade actuels, ce serait avantageux sans aucun inconvénient. Dans cette situation, on pourrait penser qu'il est préférable de traiter de la même façon les modèles équivalents parmi la catégorie:Modèle pour les langues en définissant une fonction commune, avec un paramètre de langue. Mais, en réalité, on a des paramétrages si différents et des rendus si disparates qu'il est difficile de l'envisager sans une remise à plat généralisée sur l'usage de ces modèles dont le nombre reste assez faible. Curiosité personnelle : si cela avait été le cas et afin de ne pas (trop) impacter d'autres modèles sollicitant le module — question de chargement —, où aurait-il été opportun de définir la fonction "principale" mutualisée : dans Module:Langue ? dans une sous-page du module Langue ? dans un autre module, séparé ?
En l'occurrence, souhaites-tu créer un Module:Japonais ? — Ideawipik (discuter) 24 juillet 2022 à 18:17 (CEST)
Je ne sais pas quel aurait été le meilleur endroit pour ajouter une telle fonction, c'est à voir au cas par cas, selon comment la situation se dessine ; et à la rigueur c'est toujours relativement simple à déplacer ultérieurement (sous réserve que le code ne se soit pas retrouvé à être utilisé un peu partout dans tous les sens au fil du temps).
Pour ce qui est de créer le module, c'est tentant mais je n'en ai guère le temps… Mais si on s'en tient à un module réimplémentant seulement le modèle {{Japonais}}, cela devrait être relativement simple.
od†n ↗blah 25 juillet 2022 à 00:52 (CEST)
Réponse pour assouvir la curiosité du demandeur. Si trop long, aller directement au PS.
Bonjour VKaeru. La raison est que l'intégralité du contenu de cet article (sauf les trois phrases introductives) est inséré via un modèle. Donc la taille d'expansion des modèles est énorme. Pour faire une analogie, comparons 
{{Colonnes|…|1=}}
* A
* B
…
}}
et 
{{Début de colonnes|…}}
* A
* B
…
{{Fin de colonnes}}
Ces deux syntaxes ont exactement le même rendu. Avec la première syntaxe tout le contenu de la liste en colonnes est compté comme insérée par un modèle. Avec la seconde, seulement le début de la section et la fin (balises de mis en colonnes) sont insérés par modèle. Ce qui peut aboutir à une grande différence sur la « Taille d’inclusion après expansion ». C'est le type d'économies faciles à faire. Et en plus on réduit le risque d'avoir un signe égal dans le modèle interprété comme la définition d'un paramètre, si le 1= initial a été omis.
Revenons à l'article soulevé ici, en commençant par des détails peu importants et de fausses bonnes idées
  • Dans la version signalée du code de l'article figure un petit problème de syntaxe HTML : des balises non symétriques dans les paramètres chapitre des modèles sollicités sur la fin du document avec des doubles fermetures de div au lieu d'une ouverture et d'une fermeture. La correction, simple, ne coûte rien et permettra de gagner une miette sur la taille totale ; il ne faut pas s'attendre à un gain significatif.
  • Idée d'économie de bouts de chandelle non recommandé car le gain est nul : remplacer {{Références}} par <references/> et les appels avec groupe et références définies dans le modèle par <references group="…"><ref name="…">…</ref> … </references>. Dans ton cas, vu que le texte de chacune des références est très court, je proposerais d'entourer la balise <references> d'un div
    <div class="references-small" style="column-width:15em;">…</div> (avec éventuellement un column-count dans l'attribut de style pour fixer un nombre maximum de colonnes mais cela me semble superflu étant donné le grand nombre de références). Mais, je le répète, le gain sur la taille sera quasiment nul, donc ce n'est pas une solution à recommander. La seule différence est que les références individuelles — et encore uniquement si elles ne sont pas introduites via un modèle —, seront lisibles.
Pour une réponse plus satisfaisante, voici des pistes à explorer.
  1. Élaguer l'article. Est-ce que certains détails peuvent-être considérés comme superflus ou sans intérêt encyclopédique ? La page n'est autre qu'un catalogue d'ISBN et de titres de chapitres ; les "références", des liens vers le site de l'éditeur, sources primaires et commerciales… En outre chacun de ces liens ne présente pas de liste de chapitre mais seulement un titre de volume, ce dernier n'étant d'ailleurs pas repris sur Wikipédia. D'où sortent donc les noms des chapitres ? Une compilation personnelle ? Pas sûr qu'on rentre dans le cadre de Wikipédia:Wikipédia est une encyclopédie#Listes.
  2. Remplacer l'appel des modèles TomeBD par des syntaxes classiques de tableau ou réorganiser partiellement la page. Remarque connexe : le tableau généré par le modèle {{TomeBD}}, avec une structure aux cases fusionnées, n'est pas vraiment accessible.
  3. Si ces nombreux modèles sont dans la page depuis longtemps, on peut imaginer qu'à un moment il n'y avait pas de problème d'affichage ni dépassement des limites techniques. On peut regarder, dans le code de {{TomeBD}}, s'il y a eu des évolutions expliquant une augmentation de la taille d'inclusion et tenter de remédier à ce poids.
    • En réalité, Le problème est consécutif à un ajout massif de contenu volumineux (voir point 4) faisant passer la taille d'inclusion après expansion pour l'article de 808 394 à environ 2 350 000 octets.
  4. Au niveau du modèle {{japonais}} mêmes considérations.
    • On notera que le modèle japonais insère des infobulles (visibles au passage de la souris sur les éléments : « Japonais », « Transcription Hepburn », « Information complémentaire ». On pourrait envisager un paramètre permettant de désactiver ces infobulles (redondantes dans ce type de liste), afin d'avoir une version allégée.
    • Les balises introduites sont munies d'attributs : <span class="lang-ja" lang="ja"> ou <span class="lang-ja-latn-alalc97" lang="ja-latn-alalc97">. Je ne sais pas quelle est l'utilité de la classe dans ce cas, mais, si elle a une utilité, il est peut-être possible de la surcharger afin d’intégrer la langue dans la classe.
  5. Déjà envisagé par Alserv, scinder l'article. Mais selon quel critère ?
Et il y aura sûrement d'autres idées de modélistes.
PS : une petite comparaison des rendus et de la « Post‐expand include size » si on retire infobulles, liens vers Aide:Japonais et éléments HTML invisibles superflus dans la présente situation :
  • {{japonais|Le souffle de Bananji|馬南慈の気概|Bananji no kigai}} → 1576 octets
  • Le souffle de Bananji ({{Langue|ja|馬南慈の気概}}, ''{{Langue|ja-Latn-alalc97|Bananji no kigai}}'') → 276 octets
  • Le souffle de Bananji ({{Langue|ja|馬南慈の気概}}, ''Bananji no kigai'') → 114 octets
J'ai appliqué la deuxième solution dans l'article ; cela laisse un peu de marge avec un retour à 747790/2097152 bytes, tout en restant accessible. Cette syntaxe correspond à ce qui était envisagé au point 4 pour le modèle Japonais. Rien n'empêche de réintroduire des modèles plus lourds/complets sur la première ligne des tableaux dans l'article. — Ideawipik (discuter) 24 juillet 2022 à 06:15 (CEST)
Apparemment j'ai posé la question au bon endroit, merci au projet, vous assurez ;)
Concernant vos solutions, la scission de l'article reste envisageable, sur le modèle de Liste des chapitres de One Piece qui se divise en 4 sous-articles, mais ça ne fait qu'étendre un article limite du point de l'admissibilité, comme souvent les articles de liste. J'ai créé cet article en premier lieu pour décharger la page générale et se concentrer sur les informations sourçables et non WP:BASE, ce genre d'article semblant néanmoins répondre à un grande demande (l'article sur les chapitres recevant tout de même un grand nombre de consultation par rapport à l'article général, et on peut imaginer que de nombreuses lectures du général se font pour parvenir au deuxième). La solution appliquée plus haut par @Ideawipik me semble répondre efficacement au problème, aussi je pense qu'il n'est pas vraiment nécessaire d'aller chercher plus loin.
Merci à tous les membres du projet pour leurs explications et leur aide, bonne continuation
--VKaeru crôa ? 24 juillet 2022 à 09:49 (CEST)

✔️ Problème avec {{Site officiel}} (?)

modifier
Dernier commentaire : il y a 2 ans4 commentaires2 participants à la discussion

Voir aussi : Projet:Langues/Café des linguistes#ALS

Bonjour

Je pense qu'il y a un problème avec le module:site officiel car lorsqu'on met « suisse allemand » sur wikidata, le code affiché sur wp.fr est (als) au lieu de (gsw) (ou mieux, « gsw-CH »), « als » est aussi le code de wikipédia en suisse alémanique, mais supprimer la propriété « code de langue Wikimedia (P424) » de l'élément WD « suisse allemand » ne change rien (à moins qu'il y ait un lag dans l'affichage des données WD ?).

Il est un peu tard et je suis confus, je laisse la main à quelqu'un de plus compétent... (genre   Zebulon84 ?)

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 10 août 2022 à 02:19 (CEST)

Salut @SyntaxTerror,
Dans Module:Langue/Data#L-450, aucun problème ; dans d:Q387066 tu as modifié.
Dans Module:Dictionnaire Wikidata/Codes langue#L-475, 387066 devrait renvoyer à "gsw", 131339 renvoie à alémanique (d:Q131339). Idem Module:Dictionnaire Wikidata/Codes langue/inversé#L-475. Ces dictionnaires ne sont pas actualisés en temps réel mais sont utilisés par Module:Wikidata, qui lui-même est utilisé par Module:Site officiel.
Après, je n'y connais pas grand chose en Lua donc dire si c'est la source du problème avec certitude dépasse mes compétences mais si les dictionnaires ne sont pas à jour et sont utilisés pour faire les correspondances en local, ça ne risque pas de fonctionner : principe d'identité. LD (d) 10 août 2022 à 02:38 (CEST)
Merci LD. J'essayerai de revenir à suisse allemand demain pour voir si ça affiche bien gsw-CH qui est le code IETF correct (enfin il me semble... c'est toujours compliqué avec ces indicatifs de région). Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 10 août 2022 à 02:44 (CEST)
En fait le problème venait de Module:Dictionnaire Wikidata/Codes langue#L-475 qui avait pour valeur « als » au lieu de « gsw » (et pas « gsw-CH », l'IANA est claire là dessus : pas de code de région pour « suisse allemand »).
Merci LD de m'avoir fait découvrir ce sous-module, à mon avis il doit y avoir d'autres erreurs dans ce genre, mais comme c'est des numéros d'élément WD, je vois mal comment vérifier les fautes... Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 10 août 2022 à 08:17 (CEST)

Appel du modèle Géolocalisation par le modèle Méta palette Équipe nationale

modifier
Dernier commentaire : il y a 2 ans7 commentaires4 participants à la discussion

Bonjour, Les modèles {{Méta palette Équipe nationale}} et {{Méta palette Équipe nationale sans numéro}} appellent un modèle {{Géolocalisation/Pays qui va bien}} => Pourquoi ?

Vu avec le modèle {{Palette Équipe de Grande-Bretagne féminine de hockey sur gazon aux Jeux olympiques 2016}} qui appelle le modèle {{Géolocalisation/Grande-Bretagne}} qui n'existe pas mais cela n'a pas l'air d'être utile à la palette. Cordialement - Drongou (discuter) 30 juin 2022 à 23:22 (CEST)

  Drongou : Bonsoir, c'est le modèle:Du? qui s'en sert pour construire le titre de la palette.
Quand le modèle de géolocalisation n'existe pas il met par défaut « de la zone » (comme on peut le voir dans l'exemple que tu donnes).
--FDo64 (discuter) 30 juin 2022 à 23:35 (CEST)
  FDo64 : Un grand merci, je n'aurai jamais trouvé => je cherchais une carte ... Cordialement - Drongou (discuter) 30 juin 2022 à 23:49 (CEST)
Hello FDo64,
Merci pour cette réponse, j'avais aussi de mon côté cherché sans succès, en raison de la forte présence de {{Géolocalisation/Grande-Bretagne}} dans les modèles demandés. Dans ce cas, ne faudrait-il pas protéger le modèle {{Du?}} contre un appel de modèle inexistant, en vérifiant que le modèle existe avant de l’appeler ?
Wikipédiennement, Epok__ (✉), le 1 juillet 2022 à 10:35 (CEST)
Bonjour, j'ai créé le modèle de géoloc (la géoloc n'est ici qu'un prétexte) pour donner l'affichage souhaité.
Je ne suis pas contre vérifier que le modèle existe avant de l'appeler mais dans ce cas il faudrait mettre un place un autre mécanisme de détection des échecs de {{Du?}}. Ici on voit que ça a permis de résoudre un problème. l'Escogriffe (✉) 1 juillet 2022 à 19:22 (CEST)
GrandEscogriffe : entourer le code actuel tel quel d'un simple #ifexist, en renseignant "de la zone" dans le cas négatif résoudrait le problème. Mais cette parser function étant couteuse, ce n'est peut-être pas une solution acceptable... Epok__ (✉), le 2 juillet 2022 à 11:13 (CEST)
Ajout : je viens de tomber là dessus depuis la doc de la parser function : à priori, cela n'allègerait pas la page spéciale car les pages testées par ifexist se retrouvent tout de même dans une autre liste... J'annule donc ma remarque. Epok__ (✉), le 2 juillet 2022 à 11:15 (CEST)

Modèles de langues

modifier
Dernier commentaire : il y a 2 ans4 commentaires2 participants à la discussion

Le modèle:en russe fonctionne bien. Mais les modèles modèle:en biélorusse et modèle:en ukrainien ne fonctionnent pas correctement. Le paramètre "translittération" ne fonctionne pas et le texte apparaît en italique, ce qui est inutile et indésirable pour le texte cyrillique. Les transcriptions latines sont présentes, mais ne sont pas visibles. Donc

Quelqu'un peut-il aider? GPinkerton (discuter) 5 juillet 2022 à 15:15 (CEST)

  GPinkerton : le truc c'est que le modèle:en russe utilise un modèle spécial ({{lang-ru}}) pour indiquer la langue, tandis que les deux autres utilisent le Modèle:En langue, prévu à la base pour les langues écrites avec l'alphabet latin (le seul qui devrait être mis en italique).
Je ne comprends pas vraiment pourquoi ces modèles simples utilisent des sous-modèles et des sous-sous-modèles, et ce qui me gêne un peu c'est que certains de ces modèles de ces « modèles de langue avec nom » ont des parenthèses et d'autres pas, et certains on « en » avant le nom de la langue, d'autres pas.
Il faudrait vérifier tous les modèles de la catégorie, enlever toutes les parenthèses pour permettre leur utilisation dans un plus grand nombre de situations et passer avec un bot pour ajouter toutes les parenthèses qui auront disparu...
En bref un sacré boulot en perspective (mais ça fait un moment que j'ai envie de me lancer dedans).
Il y a un autre problème : pour les deux modèles problématiques, il n'y a qu'un seul argument, où l'on doit mettre le texte en cyrillique ET sa transcription éventuelle, alors que le modèle « en russe » à deux arguments, pour le cyrillique et le romain (ce qui est la bonne chose à faire).
  • {{en russe|Николай|Nikolaï}} → en russe : Николай, Nikolaï
  • {{en biélorusse|Гвардыя, Hvardyya}} → en biélorusse : Гвардыя, Hvardyya
Enlever l'italique pour le cyrillique veut dire l'enlever aussi pour la transcription, donc on se retrouve avec un autre problème...
Je préfère ne rien toucher en attendant d'autres avis. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 5 juillet 2022 à 16:11 (CEST)
À y réfléchir, il y a un autre problème : certaines langues peuvent s'écrire en romain ET avec un ou plusieurs autre systèmes d'écriture (comme certaines langues yougoslaves, selon la date du texte, par ex. le serbe qui est redevenu en cyrillique après la dissolution de la Yougoslavie il me semble). C'est donc un problème bien plus vaste que ces deux modèles fautifs.
Idéalement, il ne faudrait pas ajouter la mise en italique dans ce genre de modèle, et le faire en dur dans les articles, comme pour le modèle {{langue}}, mais ça veut dire retoucher des dizaines (centaines ?) de milliers de pages si on enlève l'italique des modèles.
Le mieux serait peut-être de créer un module, et d'utiliser le modèle {{en langue}} (synonyme {{en lang}}) pour toutes les indications de langue dans les articles, au lieu de l'utiliser comme méta-modèle.
On pourrait se servir de Module:Langue/Data comme base de données, et ensuite {{en langue|ru|...}} marcherait, de même que {{en langue|russe|...}}, ou n'importe quel synonyme de nom de langue indiqué dans Module:Langue/Data.
Comme les modèles {{en trucmuche}} utilisent en majorité {{Langue avec nom}} comme méta-modèle, on pourrait les modifier un à un sans chambouler les articles trop longtemps. [EDIT] ça marche pas, j'ai le cerveau en bouillie...
L'avantage serait qu'il n'y aurait plus jamais besoin de créer de nouveaux « modèles de langue avec nom », il suffirait d'ajouter la langue à Module:Langue/Data pour avoir un modèle fonctionnel.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 5 juillet 2022 à 16:26 (CEST)
  Zebulon84 qui a créé le module:langue. Şÿℵדαχ₮ɘɼɾ๏ʁ 5 juillet 2022 à 16:57 (CEST)

Modèles dynastiques

modifier
Dernier commentaire : il y a 2 ans11 commentaires3 participants à la discussion

Bonjour,

Les noms dynastiques (ceux avec un numéro en chiffres romains) sont supportés par une série de modèles comme Monarque, Souverain, Souverain-, Souverain2, Souverain3 qui donnent une migraine à essayer de comprendre leur utilisation, quand utiliser l'un ou l'autre, et quelles sont les différences et les incompatibilités, et comment modifier un appel pour ajouter ou supprimer le lien.

Question : y aurait-il un intérêt à créer un seul modèle qui en fasse une synthèse ? Vous trouverez une proposition de ce genre, sans préjuger de rien, sur Utilisateur:Alserv/Documentation. J'en ai parlé un peu avec Golmote qui y semble favorable.

Deuxième question : je ne connais pas bien les usages, est-ce « Crée le d'abord, qu'on voie à quoi ça ressemble », ou bien est-ce « Pas de passage en force, touche à rien tant qu'on n'a pas donné notre avis » ? Alserv (discuter) 6 juillet 2022 à 12:53 (CEST)

Bonjour Alserv j'ai juste survolé, mais ça me semble bien.
Le vrai problème ça va être le boulot pour tout mettre en phase avec le nouveau modèle, surtout que les paramètres sont différents, et qu'il y en a en plus que dans ton modèle « noble » (entre crochets, le nombre de transclusions) :
  • [2871] {{monarque|prénom|nombre romain|(optionnel : nom du pays)|pays=}}
  • [145] {{Souverain|prénom de règne|ordre|article wikipédia|complément du nom}}
  • [9929] {{Souverain-|prénom de règne|ordre|complément de nom}}
  • [15892] {{Souverain2|prénom de règne|ordre|complément de lien|complément du nom}}
  • [6979] {{Souverain3|prénom de règne|ordre|complément de lien}}
En plus, selon la doc de certains modèles « pour des raisons historiques (compatibilité des anciennes versions), il est toujours possible d'écrire les paramètres en les séparant par des « | », sans changement de rendu »
Ça fait que c'est un sacré boxon, surtout qu'avec un total de 35 816 pages à éditer, ça prendra au mieux une dizaines d'heures si on compte 2 secondes par édition, mais c'est sans compter les autres manips et les problèmes éventuels.
Sinon, quant au truc de passer en force, tu ne peux pas, car les paramètres sont différents, il te faut l'aide d'un bot pour faire le boulot, et il va falloir discuter avant, parce que ce genre de modification de grande ampleur ça amène toujours des pénibles (c'est pour ça que mon bot à 180 000 édits au compteur, une bonne moitié ont été défaites puis refaites, parfois deux fois...).
En 10 ans ici, je suis devenu un peu pessimiste, mais c'est bien d'avoir des nouvelles idées  . Attendons de voir ce qu'en disent les autres, avec lua on fait parfois des miracles.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 6 juillet 2022 à 13:34 (CEST)
Merci. L'idée n'était pas de supporter tous les paramètres des anciens modèles mais bien d'avoir un modèle aussi simplifié et facile à utiliser que possible pour les nouvelles utilisations, donc sans s'imposer de contrainte de compatibilité. Ce qui signifie qu'un bot ne pourrait pas modifier toutes les pages existantes, sauf dans certains cas bien particuliers très limités ; les anciens modèles peuvent rester, ils ne gênent pas. Donc pas de bots. Et cela permet d'avoir un code Lua plus compact et plus performant: le code Lua pour implémenter le modèle proposé fait tout juste 256 lignes, commentaires compris.
Quand je parlais de passer en force, je me suis mal exprimé. Je voulais dire, créer le modèle puis discuter après - au risque de polluer l'espace des modèles avec des essais ratés. Alserv (discuter) 6 juillet 2022 à 14:09 (CEST)
Bonjour Alserv. Je pense que tu peux créer module et modèle sans problème. Pour les modèles, il est possible de créer un brouillon dans une sous page utilisateur (« Utilisateur:Alserv/… ») qui se sollicite ainsi : « {{Utilisateur:Alserv/…|paramètres}} ». Cela permet d'éviter la proposition d'insertion du modèle par l'outil de l'éditeur visuel. Pour les modules, aucune idée. Au pire, si la proposition était abandonnée, la page pourrait être supprimée. Dans un premier temps, il convient d'indiquer clairement que les modules/modèles sont en phase de développement et donc pas à utiliser dans les articles pour le moment.
La simplification de l'utilisation des modèles va dans le bon sens à mon avis. Il faudra établir comment convertir les syntaxes des anciens modèles, en fonction des cas (titre d'article avec parenthèse, titre d'article avec du texte après le numéral, etc.). Le modèle {{Souverain}} étant relativement peu employé (moins de 140 articles), il serait possible, à moyen terme, de réutiliser ce nom (préférable à « noble ») pour le futur modèle Lua, en faisant rapidement passer un robot dans les articles concernés puis en surveillant ces derniers quelque temps (en cas de retour à une version antérieure). Pour {{Souverain-}} (7600 pages distinctes), c'est un peu plus délicat. Voir si on peut temporairement avoir un modèle qui accepte les deux syntaxes (en fonction des valeurs des arguments). Ensuite, les modèles pourrait être déployés petit à petit, au fil de l'eau en remplacement des autres modèles listés. Il n'y aurait pas d'urgence à convertir les modèles Monarque, Souverain2 et Souverain3.
N.B. – Les nombres donnés par SyntaxTerror correspondent aux nombres de pages qui incluent une transclusion du modèle mais le nombre de pages dont le code source contient le modèle peut être inférieur (exemple du modèle présent dans une palette portée par de nombreuses pages). — Ideawipik (discuter) 6 juillet 2022 à 17:36 (CEST)
Merci. Je ne suis pas très chaud pour réutiliser le nom d'un module existant. Pour coller à la bonne pratique de beaucoup de modèles où le modèle X génère un lien et le modèle X- (avec un tiret) fait exactement la même chose sans générer de lien, il faudrait redéfinir {{Souverain}} et {{Souverain-}} en même temps, et là on tombe sur un bec de gaz : d'abord il y a beaucoup d'articles qui utilisent {{Souverain-}}, et je vois vraiment pas un bot capable de reconnaître et de convertir « {{Souverain-|Louis II}} d'Italie ». Ensuite, je sais par amère expérience (en-dehors de Wikipédia) que cela apporte des tonnes de bugs de compatibilité et coûte très cher en maintenance, sans compter que cela surcharge souvent très fort le nouveau code.
Merci aussi pour le conseil pour les brouillons. J'utilise ma page de brouillon comme vous m'avez suggéré pour faire des tests, avec deux pages de brouillon supplémentaires pour contenir les deux modèles. Pour les modules, on ne peut pas en faire dans son espace perso, il faut utiliser Module:Bac à sable qui est commun à tout le monde. Heureusement on peut l'éditer, copier du code, le tester puis annuler sans jamais le publier et donc sans gêner les autres utilisateurs. Alserv (discuter) 6 juillet 2022 à 18:28 (CEST)
Je ne suis pas non plus très chaud pour la réutilisation d'un nom de modèle en général, sauf s'il est désuet depuis très longtemps. Mais il faut quand même que le modèle soit bien nommé (titre précis, sans surprise). Donc dans certains cas, pourquoi pas ? Avec une grosse dose de pédagogie pour les rédacteurs habitués aux deux modèles, une bonne préparation de la transition et une adaptation des documentations associées à ces modèles (y compris en pages de discussion, aides aux contributeurs, pas seulement la sous-page de documentation du modèle). Comme l'indiquait Tractopelle-jaune au cours d'une autre discussion sur la présente page en mai 2022, le besoin de rétro-compatibilité est relatif.
En l’occurrence pour {{Souverain-|Louis II}}, il n'y aurait rien à changer dans l'article puisque ce modèle ne doit pas introduire de lien interne. Le seul intérêt du modèle est l'insécabilité entre le nom et le numéro, soit un rendu équivalent à {{nobr|Louis {{II}}}}. On n'est pas obligé de faire entrer le complément « d'Italie » dans le modèle.
Remarque connexe sur l'avantage de la syntaxe proposée pour le nouveau modèle par rapport aux syntaxes initiales rappelées ci-dessus par SyntaxTerror. En cas de renommage d'un article de souverain, afin de transformer ce dernier article consacré à un homonyme éclipsant l'initial ou de le transformer en page d'homonymie, serait rendu plus facile le repérage des pages ayant besoin d'un changement. En effet, le titre complet de l'article serait entier dans un seul paramètre et pas dispatché sur plusieurs paramètres (prénom de règne, ordre, complément de lien). D'ailleurs, la possibilité de mise en forme (italique) dans le paramètre du modèle Souverain3 ne doit pas faciliter la maintenance par bot, dans de telles situations.
Une question à se poser par exemple pour {{Modèle|Louis II d'Italie}}, quel serait le libellé du lien par défaut : « Louis II » comme avec Souverain2 ou « Louis II d'Italie » comme avec Souverain3. Le premier semble plus simple (se distinguant de {{Modèle|Louis II d'Italie|d'Italie}}) mais n'est pas forcément le plus logique pour l'utilisateur final. Il pourrait être intéressant d'autoriser une syntaxe particulière {{Modèle|nom de l'article|libellé=libellé complet}} le modèle mettrait en forme (insécabilité devant les numéros, infobulle) tout le libellé (exemple : |Philippe V le Long|libellé=Philippe V dit « le Long » ou Philippe II de Navarre}}). D'un autre coté, pour ces cas particuliers, on peut aussi préconiser la syntaxe classique entre doubles crochets et l'usage du {{nobr}}. — Ideawipik (discuter) 6 juillet 2022 à 20:36 (CEST)
+1 pour le renommage d'un article, je n'y avais pas pensé.
Pour la conception du modèle, j'ai essayé de faciliter autant que possible la conversion d'un nom d'article en un appel de modèle, ce qui se rapproche le plus de Souverain3, en supprimant le texte entre parenthèses dans l'affichage, mais sans les modifications du nom d'article faites par Souverain3, comme vous le faites si bien remarquer : le premier argument est strictement le nom de l'article. Puis seulement après j'ai repris les idées de Souverain2 pour le deuxième argument. Donc pour {{Modèle|Louis II d'Italie}} la mise en forme serait « Louis II d'Italie », ce qui me semblait en effet le plus logique, je suis d'accord avec vous. On peut ajouter un second argument avec un seul tiret {{Modèle|Louis II d'Italie|-}} pour obtenir « Louis II », le second argument indiquant toujours que le texte affiché s'écarte du nom de l'article.
Quant à une syntaxe particulière, pas besoin : si le deuxième argument contient un numéro en chiffres romains, seul le deuxième argument est utilisé pour l'affichage, le premier argument ne servant qu'à générer le lien. Donc on peut écrire |Philippe V le Long|Philippe V dit « le Long » ou Philippe II de Navarre}} sans syntaxe particulière. Par contre, j'adore votre exemple, je n'avais pas pensé qu'il pouvait y avoir PLUSIEURS nombres en chiffres romains dans le deuxième argument. Je vais essayer de réviser le code pour les traiter tous. En plus je crois bien que cela simplifierait le code, merci pour la remarque. Et si le libellé ne contient pas de chiffres romains, à quoi bon s'embarrasser d'un modèle ?
Un grand merci pour cette discussion très fructueuse et pour toutes vos idées. Alserv (discuter) 6 juillet 2022 à 21:20 (CEST)
  Ideawipik et Alserv : pour tester les modules, j'avais créé Module:Utilisateur:SyntaxTerror, Module:Utilisateur:SyntaxTerror/2, etc. ça n'a jamais gêné personne et ça fait des années qu'ils sont là. Şÿℵדαχ₮ɘɼɾ๏ʁ 6 juillet 2022 à 21:59 (CEST)
@Alserv. Astucieux le paramètre 2 à la valeur « - ». On pourrait même accepter une valeur « + » pour afficher aussi l'éventuelle parenthèse d'homonymie.
Si j'ai compris ta proposition, |Louis XV|le Bien-Aimé}} est censé afficher en libellé « Louis XV le Bien-Aimé », |Louis II de Germanie|de Bavière}} « Louis II de Bavière » et |Charles II (roi d'Espagne)|l'Ensorcelé}} « Charles II l'Ensorcelé ». Mais un utilisateur pourrait s'attendre à voir cette syntaxe donner simplement « l'Ensorcelé » (dans ce cas précis, il vaut mieux qu'il utilise [[Charles II (roi d'Espagne)|l'Ensorcelé]], mais on trouvera inévitablement de telles utilisations superflues du modèle au fil du temps, par mimétisme). C'était le sens de la question relative au paramètre sur le libellé complet. Sur quelle base le modèle changera-t-il son comportement entre ajout/remplacement d'un complément et affichage du second paramètre uniquement ?
Autres cas envisageables :
  • numéro uniquement dans le libellé |Mélèce Métaxakis|Mélèce IV}} ou |Jeanne d'Albret|Jeanne III de Navarre}} (avec éventuellement une parenthèse d'homonymie). Cela correspond aux cas « Avec un autre numéro » du brouillon ;
  • avec un prénom différent. Concrètement, je n'ai pas d'exemple d'article mais on pourrait avoir un |George VII (roi d'Angleterre)|Charles III}} ou |Karol Wojtyla|Jean-Paul II}}. En pratique, par l'intermédiaire de redirections on devrait pouvoir s'éviter ce genre de gymnastique, mais sait-on jamais… Ai trouvé un exemple simple : |Charlemagne|Charles Ier}}. — Ideawipik (discuter) 6 juillet 2022 à 22:46 (CEST)
Malin le « + », j'adopte. Si le nom de l'article se présente comme « nom numéro complément (homonymie) », le comportement standard avec un seul argument affichera « nom numéro complément ». Un « - » comme second argument retranchera le complément pour afficher « nom numéro » alors qu'un « + » comme second argument ajoutera l'homonymie pour afficher « nom numéro complément (homonymie) ». On fait des maths, plus ou moins.
Les exemples sont exactement comme tu l'indiques. Le comportement change selon qu'on détecte ou non des chiffres romains dans le second argument. Si pas de chiffres romains, ajout du second argument au nom et numéro tirés du premier argument. Si chiffres romains, affichage du second argument uniquement.
Pour les autres cas envisagés, il affichera donc toujours uniquement le second argument puisqu'il contient des chiffres romains. Et il ne se plaindra pas s'il n'y en a pas dans le premier. Alserv (discuter) 7 juillet 2022 à 08:20 (CEST)
Merci à tous pour cette discussion fructueuse et vos interventions de qualité. Je vais essayer de résumer :
  • L'accent est mis sur une utilisation aussi simple et intuitive que possible. Une compatibilité avec les anciens modèles n'est pas garantie, et il n'y a pas de demande à un bot de convertir les appels aux anciens modèles en appels au nouveau ;
  • Le premier argument est strictement le nom de l'article (s'il existe) pour faciliter le travail des bots ;
  • Un « + » comme second argument affiche aussi l'homonymie ;
  • Il peut y avoir plusieurs nombres en chiffres romains, qui doivent être mis en forme individuellement.
-- Alserv (discuter) 8 juillet 2022 à 11:24 (CEST)

Recherche pour les nouveaux

modifier
Dernier commentaire : il y a 2 ans8 commentaires5 participants à la discussion

Un modèle, lorsqu'on l'utilise, doit être précédé de "{{" et suivi de "}}".

Quelqu'un de nouveau sur Wikipédia ne sait pas cela.

Ne pourrait-on pas faire que ce soit possible de faire une recherche avec ces accolades.

Exemple : quelqu'un fait une recherche sur "{{article}}" il ne trouvera rien, ce n'est qu'en cherchant, qu'il arrivera à trouver qu'il faut taper modèle à la place des accolades et donc taper "modèle:article". Io Herodotus (discuter) 8 juillet 2022 à 08:11 (CEST)

Bonjour  . En effet, ce n'est pas intuitif sans avoir lu un minimum d'aides…
Je pense que la bonne réponse à ta demande est de poster une demande sur Phabricator.
Là tu risque d'avoir la réponse que l'outil de recherche te permet déjà de trouver le bon résultat à condition de sélectionner l'espace de nom "modèle", après avoir fait plusieurs clics… Encore faut-il le savoir.
J'ai bien peur qu'à notre niveau nous ne puissions rien faire.
--FDo64 (discuter) 8 juillet 2022 à 09:03 (CEST)
Il est possible de rechercher un modèle spécifique, par exemple hastemplate:"tonmodèle" dans la barre de recherche. Bouzinac (discuter) 8 juillet 2022 à 12:43 (CEST)
Bonjour Io Herodotus. Il y a deux cas : la recherche d'un modèle et la recherche des pages portant un modèle donné.
Pour la recherche d'un modèle.
  • Si le nom exact du modèle est connu : une recherche Modèle:lemodèle (l'auto-complétion facilite la recherche).
  • Si le titre exact du modèle n'est pas connu, une recherche de mot dans la page :
    • soit Modèle: "expression cherchée".
    • soit "expression cherchée" en restreignant la recherche à l'espace des modèles (case à cocher).
  • Variantes en connaissant une partie du titre avec intitle:/expression cherchée/i ou une partie du code source de la page avec insource:/expression cherchée/i ; le i final est facultatif selon que la casse soit exacte ou que la recherche doive être souple.
Pour la recherche d'articles utilisant un modèle donné, il existe plusieurs méthodes :
  • La méthode proposée plus haut dans l'outil de recherche hastemplate:"lemodèle" que l'on peut combiner à d'autres critères de recherche ;
  • Alternative qui sera peut-être moins complète (pour des mises en forme particulières) mais permet de rechercher des motifs parmi les paramètres insource:/\{\{\s*[Ll]emodèle\s*\|/ ;
  • Spécial:Pages liées en affichant uniquement les inclusions (pas les liens et les redirections) ;
  • wstat.fr qui permet aussi des recherches de motifs (expressions régulières) pour le modèle complet et pour chaque paramètre. Site externe développé par le contributeur Orlodrim avec une mise à jour bimensuelle à partir de dépots.
Comme FDo64, je pense que l'important est la documentation et l'aide pour les nouveaux. Un néo-contributeur est en général assez rapidement amené à côtoyer des modèles. Une suggestion : créer la page « Aide:{{ » en tant que redirection vers Aide:Modèle. La seule suggestion que je vois pour Phabricator serait l'ajout d'un raccourci « {{ » à la place du mot « Modèle » dans l'outil de recherche. — Ideawipik (discuter) 8 juillet 2022 à 16:04 (CEST)
Je me mettais à la place d'un nouveau, ne sachant pas ce qu'est un modèle.
Créer la page « Aide:{{ » pourrait probablement aider.
Mon idée était que si un nouveau, voyait «{{article}}» sur une page, ne sachant pas ce que c'est, faisait une recherche sur «{{article}}» ; celle-ci aboutisse directement à « modèle:article ». Io Herodotus (discuter) 8 juillet 2022 à 16:35 (CEST)
Bonjour Io Herodotus. C'est au niveau du logiciel MediaWiki qu'il faut demander ça, on ne peut rien faire depuis Wikipédia.
 
« On finit par s'y habituer, et en fait, je vois même plus le wikicode : tout ce que je vois, ce sont des bandeaux, des palettes, des modèles biblio... »
Sinon, sans même demander, il ne me semble pas que ça soit faisable, car certains caractères ne sont tout simplement pas reconnus par la barre de recherche (dont { et [ par exemple).
Certains signes de ponctuations sont des redirections, par exemple ( vers Parenthèse, mais pas [[{]], qu'il n'est d'ailleurs pas possible de créer (et que le logiciel de rendu ne peut même pas afficher comme un lien, même rouge), ni [[Aide:{{]] d'ailleurs.
On ne peut malheureusement pas tout simplifier, il faut un minimum de connaissances pour contribuer de manière un peu avancée... D'ailleurs maintenant avec l'éditer visuel ce genre de problème avec le wikicode ne devrait plus arriver (y'a plus que les vieux coûtons de Wikipédia comme moi qui ont l'audace d'encore éditer en mode source  ).
Sinon, le moyen le plus facile de trouver un lien vers la page du modèle est d'aller voir en fin de page en mode édition : il y a une liste des « Modèles utilisés par cette page » (d'où on devrait d'ailleurs retirer les modules pour les mettre dans une liste a part, car pas grand monde sait comment les éditer ou même s'en servir). Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 8 juillet 2022 à 17:34 (CEST)
Effectivement, l'accolade fait partie des caractères interdits dans les titres de page, tout comme les crochets, barre verticale ou dièses qui ont un rôle propre (d'ailleurs un script de maintenance que j'ai écrit pour contrôler les paramètres du modèle Lien détecte la présence de ces caractères problématiques). Néanmoins, on peut observer que la recherche simpliste de { dans le moteur de recherche mène à l'article Symboles typographiques japonais qui contient les caractères « ｛ » et « ｝ », des accolades unicode U+FF5B et U+FF5D (avec une espace large précédant ou suivant nos accolades classiques U+007B et U+007D). Donc si on introduit « ｛｛ » et « ｝｝» quelque part (si besoin de façon "cachée") dans l'aide:Modèle, une recherche dans l'aide générale de {{ ou }} devrait conduire à la page d'aide souhaitée. Attention toutefois à ne pas utiliser ces caractères pour appeler des modèles car cela ne fonctionnerait pas.
La découverte des modèles est assez rapide pour un débutant. Une page comme Aide:Syntaxe évoque les modèles et possède de nombreux liens vers certains d'entre eux.
Contrairement à ce qu'il semble croire, SyntaxTerror n'est pas le seul à ne pas se servir de l'éditeur visuel, si tant est qu'un éditeur de code source ne soit pas "visuel". La plupart des pages de discussion sont éditable uniquement en « mode source ». Ou alors, il y a beaucoup de « vieux croûtons ».   — Ideawipik (discuter) 8 juillet 2022 à 18:41 (CEST)
Merci.
C'est l'explication que j'attendais.
PS Je suis aussi un vieux croûtons. Io Herodotus (discuter) 9 juillet 2022 à 13:48 (CEST)

✔️ (274301) Wikipedia dans les articles liés?

Dernier commentaire : il y a 2 ans10 commentaires4 participants à la discussion
Article connexe : (274301) Wikipedia.

En regardans dans la catégorie des articles liee du portail je trouve cet article qu’il n’a aucun rapport avec les langues et n’a pas le portail langue…Bug? TYURZ🗣Parler de Wiki?🗣 14 juillet 2022 à 13:52 (CEST)

Le pire c’est qu’on ne peut pas modifié la catégorie TYURZ🗣Parler de Wiki?🗣 14 juillet 2022 à 13:53 (CEST)
1Lib1Ref;3/24; aussi je pense qu’il n’y a encore beaucoup TYURZ🗣Parler de Wiki?🗣 14 juillet 2022 à 13:56 (CEST)
J’ai fouillé et ne comprend pas.
3/24 est lié au portail:Langue catalane. Mais pour les autres exemples, je ne peux mettre en cause ni portail, ni palette.
— Sernin SC (discussion) 14 juillet 2022 à 15:07 (CEST)
Moi aussi je n’y comprends rien TYURZ🗣Parler de Wiki?🗣 14 juillet 2022 à 15:21 (CEST)
Les 404 pages de la catégorie:Portail:Wikimédia/Articles liés sont incluses dans la catégorie:Portail:Langues/Articles liés.
Mais je ne comprends pas encore pourquoi.
— Sernin SC (discussion) 14 juillet 2022 à 15:29 (CEST)

┌─────────────────────────────────────────────────┘

J'ai recopié la conversation depuis le café des linguistes, car je pense que c'est sans doute une histoire d'infobox ou de palette, mais je n'ai pas réussi à trouver quoi.
En tous cas, les gens ici seront plus à même de trouver d'où vient le problème. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 14 juillet 2022 à 23:23 (CEST)
Bonjour TYURZ, Sernin SC et SyntaxTerror. Une recherche Spécial:Recherche/incategory:"Portail:Wikimédia/Articles liés" -hastemplate:"Portail Wikimédia" semble montrer que toutes les pages concernées portent le bandeau du portail:Wikimédia, indépendamment de tout autre portail. Une recherche Petscan:22459908 le confirme. Donc la catégorisation paraît logique ou tout du moins techniquement cohérente. En effet, le Modèle:Portail Wikimédia catégorise à la fois dans Catégorie:Portail:Wikimédia/Articles liés et dans Catégorie:Portail:Langues/Articles liés et également dans les articles liés au Portail:Internet et au Portail:Associations. Si ce n'est pas pertinent, c'est ce modèle qu'il faut modifier. Ensuite des modifications nulles seront peut-être nécessaires afin de purger la catégorie. — Ideawipik (discuter) 15 juillet 2022 à 00:28 (CEST)
Merci d'avoir trouvé la source du problème Ideawipik. Je viens de retirer la Catégorie:Portail:Langues/Articles liés de ce modèle, car ce n'est effectivement pas pertinent d'ajouter en masse comme ça des articles liés. Si certains articles doivent vraiment être ajoutés, ça doit être fait « à la régulière ».
J'ai fait un null edit dans la catégorie au cas où. merci de ton aide, cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 15 juillet 2022 à 00:58 (CEST)
Merci pour l’information. Je n’avais pas pensé à regarder le modèle portail !? — Sernin SC (discussion) 16 juillet 2022 à 18:22 (CEST)

✔️ Titre mis en forme et avec une minuscule initiale

Dernier commentaire : il y a 2 ans3 commentaires2 participants à la discussion

Bonjour, existe-t-il une solution pour mettre en forme un titre d'article et lui imposer la minuscule (par exemple pour iPod touch (5e génération)) ? {{minuscule}} ne semble pas permettre d'autres modifs que la langue et {{titre mis en forme}} ne gère pas la minuscule. --Golmote (discuter) 7 août 2022 à 22:14 (CEST)

{{DISPLAYTITLE:iPod touch 5<sup>e</sup> génération}} en semble pas marcher : il y a un message d'erreur « Avertissement : le titre d’affichage « iPod touch 5e génération » a été ignoré car il n’est pas équivalent au titre effectif de la page. »
Je ne vois pas trop comment faire... Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 8 août 2022 à 00:05 (CEST)
Merci @SyntaxTerror, en fait grâce à toi j'ai trouvé haha ! {{titre mis en forme}} permet totalement de le faire, et j'avais simplement (comme toi) oublié les parenthèses dans le titre. {{Titre mis en forme|iPod touch ({{5e|génération}})}} fait le taf. --Golmote (discuter) 8 août 2022 à 00:12 (CEST)

✔️ L'admissibilité de l'article « Modèle:Avertissement Vidéo » est débattue

Dernier commentaire : il y a 2 ans1 commentaire1 participant à la discussion
 
Page proposée au débat d'admissibilité

Bonjour,

L’article « Modèle:Avertissement Vidéo (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:Avertissement Vidéo/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.

Champeillant (discuter) 19 août 2022 à 17:02 (CEST)

Erreur de Lint div-span-flip

Dernier commentaire : il y a 2 ans2 commentaires2 participants à la discussion

Bonjour. Les pages qui sollicitent le modèle:Location map~ avec des balises <div> dans le paramètre label (sur wstat) du modèle déclenchent une erreur de Lint « div-span-flip » (Spécial:LintErrors/misc-tidy-replacement-issues) en raison de l'imbrication <span>…<div>…</div></span> Une solution pourrait être de remplacer dans le code du modèle les « span » par des « div » mais cela risque de modifier les positions actuelles de ces annotations sur les cartes sollicitant le modèle {{Location map~}} dans les articles. Quelle est la meilleure correction à votre avis ?

PS : On remarquera aussi que l'affichage n'est pas forcément idéal/homogène si plusieurs éléments sont présents dans le paramètre (le modèle génère des <p> au milieu mais pas au début de l'ensemble affiché).
— Ideawipik (discuter) 21 juillet 2022 à 00:23 (CEST)

Salut @Ideawipik, si ton but est principalement de te débarrasser de l'erreur de lint, je suppose qu'un <div style="display:inline;"> à la place du <span> serait suffisant. La position des annotations devrait rester inchangée. --Golmote (discuter) 6 août 2022 à 11:16 (CEST)

span avec IndexCE

Dernier commentaire : il y a 2 ans9 commentaires3 participants à la discussion

Bonjour, 5 articles de chimie (liste via la recherche "Numéro index <span title" -- ex : Rouge congo, Trioxyde de chrome -- ) ont des span apparent qui arrivent via l'utilisation de {{IndexCE}}
Exemple : {{indexCE|028-003-00-2}} => 028-003-00-2
J'ai l'impression que c'est lié à l'utilisation d'un modèle sur la ligne par exemple : 028-003-00-2
Cordialement Drongou (discuter) 24 juillet 2022 à 15:38 (CEST)

Désolé pour le dérangement, ce modèle fait un lien externe vers un site qui à l'air mort depuis très longtemps (10 ans, j'ai l'impression)
Exemple avec un rendu correct mais un lien HS : {{indexCE|601-003-00-5}} => 601-003-00-5
Je vais voir avec le projet Chimie (après mes vacances). Cordialement - Drongou (discuter) 24 juillet 2022 à 16:03 (CEST)
Pas vraiment une solution, mais cela pourrait vous tirer d'affaire provisoirement: dans le Modèle:IndexCE, remplacer les chiffres romains entre double accolades genre {{II}} par les mêmes chiffres sans doubles accolades, genre II.
Pour une explication un peu plus technique: apparemment il y a un problème quelque part dans la génération du texte. Premier exemple qui ne marche pas: [http://fr.wiki.x.io <span title="numéro {{II}}">texte</span>] génère <span title="numéro II">texte avec un texte erroné, alors que [http://fr.wiki.x.io <span title="numéro II">texte</span>] sans les doubles accolades génère texte qui s'affiche très bien. Pour ma part, je n'en connais pas suffisamment pour trouver la vraie cause du problème. Probalement en problème d'interaction entre le code généré par les chiffres romains et les guillements du title= .
Mais peut-être vaut-il mieux attendre des informations de quelqu'un de plus compétent que moi.
Cordialement, Alserv (discuter) 24 juillet 2022 à 17:44 (CEST)
Les double accolades ont été introduites par cette modification.
Le texte devant déjà apparaître dans une infobulle, les chiffres romains devraient alors apparaître dans une infobulle dans l'infobulle ? J'avoue que je ne comprends pas très bien.
Cordialement, Alserv (discuter) 24 juillet 2022 à 18:22 (CEST)
Bonjour Drongou. Alserv a bien identifié le problème, lié à cette modification dans l'ensemble superflue, voire cassant l'affichage avec l'introduction inappropriée des modèles de mise en forme des nombres romains. Ces modèles n'ont pas lieu d'être dans des attributs de balises HTML. Il sont à réserver au texte affiché dans les articles. Les rares choses que l'on peut considérer utiles dans cette modification sont les corrections typographiques comme tout en bas d’ argent → d’argent et l'ajout d'un {{I}} dans du texte affiché uniquement dans la page du modèle (tout en haut) — même si c'est un gadget et qu'idéalement, cela nécessiterait aussi une espace insécable —. Le remplacement des entités HTML dans les attributs, ne change pas le comportement du modèle, comme on pourrait le constater en comparant <span title="cyanure d&#39;hydrogène">Voir l'infobulle</span> et <span title="cyanure d'hydrogène">Voir l'infobulle</span>. En revanche, <span title="élément {{V}} bis">Texte</span> est équivalent à, accrochez-vous, <span title="élément <abbr class="abbr" title="5"><span class="romain" style="text-transform:uppercase">V</span></abbr> bis">Texte</span>. On comprend la raison du dysfonctionnement, l'attribut title devant recevoir du texte "brut" sans certains caractères. Ainsi, un "simple" <span title="A>B">…</span> serait déjà problématique. Dans le modèle cela sert de libellé à un lien externe.. La correction consiste en la proposition initiale d'Alserv. Point positif, le problème ancien a permis de relever un autre problème : l’obsolescence du site externe. — Ideawipik (discuter) 24 juillet 2022 à 19:33 (CEST)
Difficile de se convaincre que c'est comme ça depuis 9 ans mais je pense que c'est la seule conclusion possible. En fait, je pensais avoir déjà cherché du span bizarre mais visiblement jamais cette configuration.
Et donc un autre modèle vainqueur {{DHS}} sur Pully (ma recherche) -- Pour lequel la réponse ci-dessus est aussi valable --

{{DHS|2412|Pully - Du Moyen Age au {{s-|XX}}|auteur=André Schmutz}}
=>
André Schmutz, « <span title="Pully - Du Moyen Age au XXe siècle en français">Pully - Du Moyen Age au XXe siècle » dans le Dictionnaire historique de la Suisse en ligne.

mais pour celui-ci ce n'est pas intrinsèque au modèle mais comme plus habituellement dû à une hyper wikification.
Merci à tous les deux :   Alserv et Ideawipik Cordialement - Drongou (discuter) 25 juillet 2022 à 00:33 (CEST)
  Corrigé.
Les appels à des modèles dans les infobulles ont été supprimés. Il y avait non seulement des chiffres romains (facile à corriger), et des appels au modèle {{lang|en}} (j'ai conservé uniquement le texte anglais), mais aussi - nettement plus ennuyeux - des appels au modèle {{fchim}}. Pour ce dernier cas, j'ai fait ce que j'ai pu. Je vous suggère cependant de regarder de plus près l'infobulle générée par 016-019-00-2 et 051-003-00-9, les deux cas où le modèle {{fchim}} était utilisé.
Amicalement, Alserv (discuter) 28 juillet 2022 à 17:23 (CEST)
PS @Drongou: pour {{DHS}}, rien à faire. Il faudrait modifier le modèle pour ajouter un argument texte= avec le titre wikifié comme déjà fait par exemple dans le modèle {{Lien}}, mais j'avoue être un peu rebuté par la complexité du modèle {{DHS}}.
Amicalement, Alserv (discuter) 28 juillet 2022 à 17:46 (CEST)
Bonjour. Pour le cas général des infobulles, la conversion du wikicode en HTML dans un cas simple title="A>B" devrait être logiquement gérée (compatibilité) mais ce n'est pas le cas dans MediaWiki. Cf. Phabricator:T211816. Et cela ne semble pas être une priorité. Donc, la solution simple que tu (Alserv) as appliquée, est correcte. Éventuellement, on pourrait remplacer les chiffres par des caractères HTML équivalents : comme &#8322; ; &#8323; ; etc. permettant d'afficher : SO₃ ou Sb₂O₄ Mais d'une part, le rendu ne semble pas correspondre à ce qui est généralement fait pour les formules (SO3) ; d'autre part, la petite taille rendrait le texte vraiment illisible.
Remarque – Un modèle peut tout à fait être utilisé dans un texte d'infobulle, sous réserve que cela soit pertinent et n'introduise pas un élément incompatible. Par exemple, les modèles de caractères, comme ceux de la catégorie:Modèle empêchant l'évaluation par MediaWiki sont acceptés.
En ce qui concerne {{DHS}}, on peut s'interroger sur la pertinence de mettre une infobulle qui affiche un élément superflu (texte déjà présent sur la page dans le cas du romanche et mention inutile du « français » — qui est la langue attendue en priorité depuis frwiki — dans l'autre cas). Mieux vaudrait simplifier le rendu et retirer cette "lourdeur", à mon avis. Si un consensus en ce sens est obtenu dans la page de discussion du modèle, je peux me charger de l'aspect technique. — Ideawipik (discuter) 28 juillet 2022 à 23:16 (CEST)

Question JSON vers wikitexte

Dernier commentaire : il y a 2 ans1 commentaire1 participant à la discussion

Bonjour,

Existe-t-il un modèle qui puisse convertir une page incluse (Wikipédia:AutoWikiBrowser/CheckPageJSON en l'occurence) de JSON à Wikitext ?

Je connais effectivement Module:String (replace) mais je voulais savoir si quelque chose de dédié avait été fait.

Bien à vous, LD (d) 26 août 2022 à 00:57 (CEST)

J'ai trouvé mw:Extension:Scribunto/Lua_reference_manual/fr#mw.text.jsonDecode mais je n'ai pas compris si on pouvait ensuite faire en sorte que le tableau Lua soit un tableau wikitexte, une liste à puces ou des sections (pour enabledusers par exemple) avec des puces  .
L'idée serait d'avoir quelque chose comme :
<syntaxhighlight lang="html">

Utilisateurs

Vers une suppression de {{Modèle:Armorial commune}} ?

Dernier commentaire : il y a 2 ans5 commentaires3 participants à la discussion

Bonjour, après avoir passé pas mal de temps à comprendre l'origine d'une erreur de lint dans l'article Combles, je suis arrivé à trouver que le problème venait de {{Modèle:Armorial commune}} avec {{Modèle:Armorial commune titre}} et {{Modèle:Armorial commune fin}} qui ajoute un tableau sans cellule, mais cela uniquement dans le cas où on parle du blason de la ville dans son propre article. Dans un cas comme ça d'autres articles n'utilisent que {{Modèle:Armorial commune}} (ce qui n'est pas documenté) mais cela provoque d'autres erreurs de lint à la modification de l'article. En regardant le code je pense qu'on peut corriger facilement le problème et harmoniser l'utilisation de {{Modèle:Armorial commune}} mais en vrai est-ce-que ça serait pas mieux de supprimer ce modèle ?

{{Modèle:Armorial commune}} a 282 inclusions dans 41 pages ; {{Modèle:Blason commune}} qui a la même fonction a 29 606 inclusions dans 8 290 pages.

A-t-on de bonnes raisons de conserver {{Modèle:Armorial commune}} ? Ou, est-ce qu'il faut juste faire la migration vers {{Modèle:Blason commune}} pour partir vers une suppression ? mat.duf (discuter) 26 août 2022 à 06:29 (CEST)

Bonjour, j'ai abaissé la protection, ça aidera déjà probablement à maintenir ce modèle qui n'a pas retouché depuis 2012... LD (d) 26 août 2022 à 06:59 (CEST)
Merci, ça sera plus pratique dans tous les cas.
J'ai posté le sujet principalement pour voir si quelqu'un avait une bonne raison de vouloir conserver {{Armorial commune}}. Je suis plutôt partisan de simplifier les choses quand c'est possible et ne garder qu'un modèle parmi les deux serait une simplification (si bien sûr {{Blason commune}} permet comme je le pense de gérer ce que fait {{Armorial commune}}). mat.duf (discuter) 27 août 2022 à 14:10 (CEST)
  Mat.duf : Si les deux modèles font la même chose dans leur usage, je suis également partisan de n'en conserver qu'un seul. Donc, replacer les utilisations de {{Modèle:Armorial commune}} par {{Modèle:Blason commune}} (le moins utilisé par le plus utilisé), et à moins de rencontrer un cas où il est impossible de faire le remplacement sans perdre une info cruciale, supprimer le premier.
Note : voir au passage la discussion à propos d'{{Modèle:Armorial commune}} ayant conduit à la création de {{Modèle:Blason commune}} pour le remplacer.
Wikipédiennement, Epok__ (✉), le 29 août 2022 à 08:06 (CEST)
{{Blason commune}} a tous les paramètres de {{Armorial commune}} donc à ce niveau là pas de perte d'infos je pense. Je vais avancer la conversion et si je vois un cas qui pose problème on étudiera les solutions à ce moment là.
Merci pour les avis. mat.duf (discuter) 30 août 2022 à 20:39 (CEST)

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

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

Bonjour,

L’article « Modèle:Message galerie (page supprimée) » fait l'objet d'un débat d'admissibilité (cf. Wikipédia:Débat d'admissibilité). Il débouchera sur la conservation, la suppression ou la fusion de l'article. 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:Message galerie/Admissibilité.

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.

Le modèle Smn est-il encore utile ?

Dernier commentaire : il y a 2 ans4 commentaires4 participants à la discussion

Bonjour. Dans un article contenant près de 2 900 sollicitations du modèle {{Smn}} pour des entiers, à tel point que la page entrait allégrement dans la Catégorie:Page contenant trop d'inclusions de modèles, un retrait généralisé de ces appels dans les tableaux a été appliqué, en remplaçant le cas échéant (entiers à quatre chiffres ou plus) par des {{formatnum:…}}. Il s'avère que le tri numérique se fait tout aussi bien, en tout cas chez moi. Mes questions sont les suivantes :

  1. Y a-t-il des environnements ou navigateurs qui nécessitent le formatage particulier de ce modèle ?
  2. Dans quels cas particuliers (nombres relatifs, nombres négatifs ?), le modèle est-il indispensable ?

Notification à quelques rédacteurs de la page Aide:Insérer un tableau (wikicode, expert), notamment des sections en rapport avec le tri :   Tractopelle-jaune, Vatadoshu, Zebulon84, Seudo, Salix, Lucio fr, BTH, Lostinthiswhirlpool et HB. — Ideawipik (discuter) 20 septembre 2022 à 21:32 (CEST)

Il est vrai que {{smn}} insère une quantité invraisemblable de code HTML, probablement inutile dans la plupart des cas... Toutefois il a des fonctionnalités supplémentaires à FORMATNUM, notamment de mise en forme (voire d'arrondi), comme le montre l'exemple donné dans la documentation du modèle (colonne "Montant").
En conséquence il vaut mieux sans doute le conserver, mais déconseiller son utilisation pour des gros tableaux, voire ne plus conseiller son utilisation dans Aide:Insérer un tableau (wikicode, expert) (au besoin, on peut mettre un data-sort-type dans l’en-tête de colonne). Et sa suppression est en effet l'une des premières choses à essayer lorsqu'un article dépasse les limites d'expansion de modèle. Seudo (discuter) 20 septembre 2022 à 23:53 (CEST)
Ce n'est plus tant un problème sur le tri, puisque "formatnum", "unité" ou même, comme le dit Seudo "data-sort-type=number" en tête de colonne permet de faire un tri numérique. C'est plutôt un problème de mise en forme : il y a un autre avantage à smn que n'a pas formatnum, c'est l'alignement des nombres sur les unités. Cette fonctionnalité est mathématiquement utile dans des nombres en colonne et n'est offerte ni par "formatnum", ni par "unité". Maintenant, si tous les nombres ont le même nombre de chiffres après la virgule, un alignement à droite pourrait suffire mais comme cette mise en forme ne peut pas s'effectuer sur toute une colonne, il faudra le répéter dans chaque cellule (c'est lourd...). Je préconise donc de conserver le modèle mais de conseiller de limiter son utilisation aux cas vraiment nécessaires. En attendant, chercher des alternatives à ce problème d'alignement. HB (discuter) 21 septembre 2022 à 11:44 (CEST)
Quelle est la différence avec {{sfn}} ?
Je viens d'ailleurs d'éditer Liste de villes du Guyana ou je l'avais utilisé après avoir introduit un tableau triable, mais où en fait il n'est nécessaire que pour les nombres de 3 chiffres (il n'y a pas de nombres de 6 chiffres ou plus dans ce tableau).
Ça me fait d'ailleurs penser qu'il faudrait peut-être mettre plus en avant qu'unité ne doit pas être utilisé avec des nombres de moins de 4 chiffres (auquel cas il faut lui préférer {{nobr}}), ou s'ils ne sont pas suivis d'une unité ou d'un nom (auquel cas il faut lui préférer {{formatnum:}}).
Par contre, je me demande le gain réel de remplacer les cas fautifs par bot de façon systématique (surtout que c'est une modif cosmétique), et s'il est possible de créer une regex qui pourrait corriger ces cas pour être ajoutée au listes de typos d'AWB et WPC.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 21 septembre 2022 à 14:54 (CEST)

Exclusion d'un namespace d'un modèle : magic word ou non ?

Dernier commentaire : il y a 2 ans13 commentaires7 participants à la discussion

Salut

Je me pose une question : est-ce qu'il vaut mieux écrire {{#ifeq:{{NAMESPACENUMBER}}|0|vrai|faux}} (comme là) ou {{#ifeq:{{NAMESPACENUMBER}}|{{ns:0}}|vrai|faux}} ?

In fine, j'ai l'impression que cela ne change rien mais j'ignore si une pratique est meilleure qu'une autre. Je suis curieux d'en savoir plus.

Bien à vous, LD (d) 26 septembre 2022 à 22:07 (CEST)

Salut. La deuxième possibilité telle que tu l'as écrite ne fonctionnerait pas, c'est plutôt {{#ifeq:{{NAMESPACE}}|{{ns:0}}|vrai|faux}} ou directement (solution 3) {{#ifeq:{{NAMESPACE}}||vrai|faux}}.
Pour autant que je sache ça ne change rien ; si je devais exprimer une légère préférence ce serait pour la 3 suivie de la 1 pour des raisons de simplicité du code. --l'Escogriffe (✉) 26 septembre 2022 à 22:21 (CEST)
Aide:Mot magique dit que NAMESPACENUMBER donne le numéro du namespace, NAMESPACE donne le nom du namespace. Donc il faut comparer soit deux numéros, soit deux noms. Mieux vaut comparer deux numéros, on aura moins de problèmes avec des chaînes vides. Donc à mon avis la première possibilité est préférable.
Et {{ns:xx}} permet d'obtenie le nom d'un namespace quand on connaît son numéro.
-- Alserv (discuter) 26 septembre 2022 à 22:34 (CEST)
Salut à tous ! Pour la simplicité du code : {{#if:{{NAMESPACE}}|faux|vrai}}  .— Ideawipik (discuter) 27 septembre 2022 à 00:28 (CEST)
Merci @GrandEscogriffe, @Alserv et @Ideawipik pour vos réponses.
Je pensais que NS pouvait renvoyer les deux  .
Je suis moins friand des propositions n°3 et n°4 (la dernière avec IF) dans la mesure où la vérification est moins compréhensible à tout à chacun et que cela repose sur le fait que NAMESPACE ne renvoie rien pour l'espace encyclopédique.
{{#ifeq:{{NAMESPACENUMBER}}|0|vrai|faux}} me semble aussi la solution la plus opportune car quite à faire reposer une préférence sur la notion de design et d'accessibilité du code, autant ne pas multipler les mots magiques et prétendre que chacun d'entre eux pourrait changer aisément (hypothétiquement peu probable).
J'ignore si j'irais jusqu'à retoucher les modèles comme Modèle:Infobox Biographie, Modèle:Infobox Cinéma (personnalité) ou Modèle:Infobox Gare pour ce détail, mais pour les modèles et infobox qui catégorisent encore des PU et des brouillons dans les catégories, cela valait la peine de se renseigner en amont. LD (d) 27 septembre 2022 à 01:50 (CEST)
La question de la manière la plus propre de faire fonctionner nocat et cette vérification, par exemple pour Modèle:Sigle, reste intéressante. LD (d) 27 septembre 2022 à 01:58 (CEST)
@LD. À l'heure où nous écrivons, il y a, dans l'ensemble des modèles, 4 572 modèles contenant un {{NAMESPACE}} contre 105 ayant un {{NAMESPACENUMBER}}. Donc je ne comprends pas ce que tu entends par « autant ne pas multipler[sic] les mots magiques ». Choisis ce que tu veux dans le cas sur lequel tu travailles, mais il n'y a pas de raison de changer le code de modèles qui marchent. Quiconque découvre les mots magiques et fonctions natives trouve facilement à quoi correspondent chacun. Tractopelle-jaune a très bien compilé cela dans Aide:Mot magique. Il manque peut-être seulement quelques redirections. Et on a aussi Aide:Modèles spéciaux.
Par ailleurs, le NAMESPACE correspondant au préfixe des noms de page, il n'est pas étonnant qu'il soit vide pour les articles. Il n'est pas plus évident de savoir que l'espace principal (articles) correspond au code numéro zéro. Toutes les solutions se valent.
N.B. – Vu que toutes les pages de Wikipédia sont dans un espace de nom, il n'y a aucune raison qu'une quelconque « chaîne vide » pose problème. Et s'il y a un changement de comportement (très peu probable), nous en serions informés en amont par les développeurs du logiciel MediaWiki.
PS : à propos du modèle {{Sigle}} (version de ce jour), rien de bien extraordinaire ; l'astuce est de se servir de ce que renvoie l'évaluation #ifexpr pour tomber dans le cas par défaut du switch et alimenter la catégorie de maintenance. Cela a lieu pour quelques éventualités : un nombre (réel) négatif ou nul ou un réel de [0,9] non entier, passé dans le test et ressorti à l'identique ; une valeur invalide pour #expr (par exemple contenant une lettre, bref autre chose qu'un nombre) qui déclenche un message d'erreur du test. La catégorie:Modèle sigle utilisé incorrectement est vide et ne doit pas être bien fréquentée. On notera que {{Sigle|15,568}} serait valide envoyant 9 et plus. Mais les contributeurs sont sages et ont respecté la documentation ; aucun intrus avec des points ou des virgules. En revanche le second paramètre contient une valeur sans effet (différente de « nocat ») dans plus de 50 % des fois où il est renseigné non vide. Pour ce modèle, on pourrait envisager deux autres options diamétralement opposées. Option 1. Une méthode automatisée : s'affranchir de ce paramètre 1 et récupérer la longueur du titre de la page privé de son éventuelle parenthèse d'homonymie. Pour les cas particuliers où on voudrait mettre ce modèle pour un sigle qui ne correspond pas au titre de la page on utiliserait un paramètre dédié. L'inconvénient technique est le coût du traitement de la chaîne de caractères. Option 2. On conserve le paramètre en lui imposant dans les articles une valeur comprise entre 1 et 9 inclus, en adaptant documentation et TemplateData et on supprime la limitation à 9 opérée par le #ifexpr. En pratique il n'y a qu'une seule page concernée d'après wstat.fr recherche [0-9]{2} : Abracadabra (homonymie) à 11 caractères. Ce serait une solution moins coûteuse. Enfin, vu les statistiques d'utilisation du paramètre (seulement un article marginal sur les 12 050 utilisant le modèle), se contenter d'un #switch:{{{1}}} principal plus léger et gérer le cas particulier dans le #default quitte à ce que ça soit alors un peu plus coûteux, ne serait pas un mauvais calcul du point de vue des performances générales. En ce qui concerne la première partie un passage en Lua éviterait la répétition des switch identiques. Et même en restant en wikicode, ne serait-il pas préférable, puisqu'il n'y a que deux possibilités, de faire un seul switch et deux tableaux, selon le type de réponse ?   Od1n en tant que principal contributeur récent. Cordialement, — Ideawipik (discuter) 27 septembre 2022 à 09:38 (CEST)
@Ideawipik, merci.
L'utilisation équivoque de {{NAMESPACE}} et {{NAMESPACENUMBER}} n'est pas problématique. Mon propos « autant ne pas multipler les mots magiques » vise les propositions comme {{#ifeq:{{NAMESPACE}}|{{ns:0}}|vrai|faux}} : recourir à deux mots magiques ne sert visiblement pas à améliorer le raisonnement du code, autant s'en soustraire pour les motifs évoqués. Le fait qu'un code fonctionne n'est pas un motif suffisant pour empêcher un changement : {{#ifeq:{{NAMESPACE}}|{{SUBJECTSPACE:}}|vrai|faux}} fonctionnerait pour exclure les articles du main, c'est une logique abérante et un design pauvre. Avec une logique purement mathématique, on peut tout faire dire à un modèle, ce qui ne veut pas dire que cela a une raison d'être ou qu'il y ait un sens, y compris pour les personnes les plus valeureuses qui ont déjà consulté voire appris nos pages d'aide avec zèle. Toutes ces propositions ne se valent pas, mais tous leurs résultats pratiques se valent*.

Nota : je conseille cette lecture de Wiggenstein (~1h) qui illustre parfaitement ce lien entre logique, (vide de) sens, véracité et absurdité ; la situation pourrait se résumer par sa « tout ce qui peut être être dit doit l'être clairement, si on ne peut pas le dire, il faut le taire ».
* => exemple de Wiggenstein/Frege : 1+1+1+1 = (1 + 1) + (1 + 1), ce sont deux propositions qui ont « la même signification mais pas le même sens », elles ne se valent donc pas [3] [4].

Pour les sigles, je vise particulièrement ce genre de catégorisations qui n'ont pas lieu d'être : [5] et 4. Être « bien utilisé » (e.g. non présent dans la catégorie dédiée aux erreurs) — car logique — ne suffit pas, il faut que la logique ne soit ni incomplète, ni illusoire. Utiliser un nocat pour décatégoriser les pages non encylopédiques n'est pas une solution satisfaisante et rajouter sauvagement {{#ifeq:{{NAMESPACE}}|{{ns:0}}|vrai|faux}} ne me semble pas être propre vu la construction actuelle. LD (d) 27 septembre 2022 à 11:35 (CEST)
TL;DR. Utilisez plutôt {{#ifeq:{{NAMESPACENUMBER}}|2}}. Parce qu'avec {{#ifeq:{{NAMESPACE}}|{{ns:2}}}} vous faites la même chose mais en rajoutant une étape inutile : vous cherchez aussi si c'est le namespace 2 (en fournissant le numéro et non le nom, pour que le code soit plus international, portable, future-proof, etc.), mais vous convertissez le deuxième paramètre sous forme de nom local puis vous comparez ces noms, alors qu'il aurait suffi de comparer le numéro de départ.
Autre point, le namespace 2 a pour nom « Utilisateur: » mais pour les utilisatrices cela affiche « Utilisatrice: » ; le code {{#ifeq:{{NAMESPACE}}|{{ns:2}}}} repose sur le fait que {{NAMESPACE}} donne quand même dans cette situation « Utilisateur: » (le nom canonique local). Cela montre qu'il est plus rassurant de comparer directement les numéros.
Enfin, les deux codes sont fonctionnels, n'allez donc pas faire une obsession d'aller les remplacer (même si je l'ai déjà fait à quelques occasions).
od†n ↗blah 27 septembre 2022 à 17:28 (CEST)
Remarque historique : {{NAMESPACENUMBER}} a été ajouté en 2012, alors que {{NAMESPACE}} existait bien avant. Cela explique sans doute pourquoi la forme avec {{NAMESPACE}} est assez répandue, même si elle est plus compliquée. Orlodrim (discuter) 27 septembre 2022 à 20:33 (CEST)
Comme les autres intervenants, j'avais écarté d'office l'appel à la fonction supplémentaire {{ns:}} dispensable ici. Quand je parlais d'équivalence c'était sur les propositions 1, 3 et 4 qui se lisent respectivement
  • Si le numéro d'espace est nul alors vrai sinon faux.
  • Si le nom (préfixe) d'espace est [la chaîne] vide alors vrai sinon faux.
  • Si le nom (préfixe) d'espace n'est pas [une chaîne] vide alors faux sinon vrai. (i.e. la contraposée de la précédente).
PS – Une proposition a été faite en page de discussion du modèle Sigle. — Ideawipik (discuter) 27 septembre 2022 à 22:45 (CEST)
Merci Od1n pour ces informations ! Je cherchais depuis quelques jours pourquoi certaines catégories utilisateur étaient vides malgré l'utilisation des modèles associés, et le point commun était qu'ils n'étaient utilisés que par des utilisatrices ! Du coup, j'ai fait une passe sur les modèles pour éliminer la syntaxe {{#ifeq:{{NAMESPACE}}|Utilisateur|...}} et les remplacer par un test du numéro de l'espace de nom, et elles se peuplent à nouveau. Epok__ (✉), le 17 octobre 2022 à 08:26 (CEST)
J'avais entretemps vu dans un code encore une autre méthode, {{#ifeq:{{NAMESPACE}}|{{ns:User}}|...}}, qui a l'intérêt de fonctionner avec le nom en anglais plutôt qu'avec le numéro (même moi parfois j'ai du mal à m'y retrouver avec les numéros, et il m'arrive quelquefois d'avoir à consulter la documentation). Mais ton exemple a montré que seul le fonctionnement avec les numéros est vraiment fiable. Et bon, je trouve que c'est moche de faire {{#ifeq:{{NAMESPACE}}|{{ns:}}|...}} pour l'espace de nom principal… od†n ↗blah 17 octobre 2022 à 10:58 (CEST)

Robots

Dernier commentaire : il y a 2 ans8 commentaires2 participants à la discussion

</syntaxhighlight >

Vu que je maîtrise mal les patterns Lua, la fonction replace me semble difficile à mettre en place mais cela m'apparaît pas une solution impossible (si tant est qu'on maîtrise  ). LD (d) 26 août 2022 à 06:47 (CEST)
Avec la fonction récente mw.loadJsonData() (refs T217500), c'est effectivement très simple à réaliser :
local function formatCheckPage()
    local success, data = pcall( mw.loadJsonData, 'Wikipédia:AutoWikiBrowser/CheckPageJSON' )
    if not success then
        return 'Erreur Lua : ' .. data
    end

    local liUsers = {}
    for i, user in ipairs( data.enabledusers ) do
        liUsers[ i ] = '* {{u|' .. user .. '}}'
    end

    local liBots = {}
    for i, bot in ipairs( data.enabledbots ) do
        liBots[ i ] = '* {{u|' .. bot .. '}}'
    end

    return '== Utilisateurs ==\n'
        .. table.concat( liUsers, '\n' )
        .. '\n\n'
        .. '== Robots ==\n'
        .. table.concat( liBots, '\n' )
end
od†n ↗blah 20 octobre 2022 à 17:21 (CEST)
notif LD, vu que c'est une section qui a déjà presque deux mois. od†n ↗blah 20 octobre 2022 à 22:30 (CEST)
Merci @Od1n ; il y aurait un "then" manquant près de "do" ligne 3 et, un "end" attendu pour clore la fonction, j'en ai mis un à la fin : le code a pu être publié dans Module:AutoWikiBrowser.
En essayant d'invoquer le module via {{#invoke:AutoWikiBrowser|formatCheckPage}}, j'obtiens « Erreur de script : le module a renvoyé une valeur de type nil. Il est supposé renvoyer un tableau d’exportations. »
Lua et moi ça fait deux*   LD (d) 22 octobre 2022 à 19:59 (CEST)
  • pour l'histoire du do au lieu d'un then : j'avais pourtant testé le code durant le développement, mais pas forcément la toute dernière version ; j'ai probablement dû rajouter le pcall() à l'arrache avant de publier le code… Voilà qui est corrigé.
  • pour l'histoire de la structure du module : j'avais fourni le code sous forme d'une simple fonction locale, à adapter ensuite selon les besoin. Je m'en suis occupé aussi.
od†n ↗blah 23 octobre 2022 à 00:08 (CEST)
Merci pour tout @Od1n, Lua et moi ça fait plutôt 4*. Peut-être un jour ça fera 2 ou 1  . LD (d) 23 octobre 2022 à 00:37 (CEST)
Après avoir visualisé le résultat, je trouvais que c'était dommage de ne pas avoir de mise en colonnes…
  • Ma première approche a été naturellement de tenter {{Colonnes|taille=18em|{{#invoke:AutoWikiBrowser|formatCheckPage}}}}, mais le résultat n'était pas terrible ; notamment, les deux sections, et même leurs titres, se retrouvaient à la chaîne dans les colonnes.
  • Du coup… j'ai développé vite fait cette autre approche, qui peut s'utiliser ainsi :
== Utilisateurs ==
{{Colonnes|taille=18em|{{#invoke:AutoWikiBrowser|getList|group=enabledusers}}}}

== Robots ==
{{Colonnes|taille=18em|{{#invoke:AutoWikiBrowser|getList|group=enabledbots}}}}
od†n ↗blah 23 octobre 2022 à 00:55 (CEST)
Merci, j'aime bien ; j'ai mis à jour. LD (d) 23 octobre 2022 à 01:39 (CEST)

Modèle:GeoGroup

Dernier commentaire : il y a 2 ans6 commentaires2 participants à la discussion

Bonjour. Je fais appel aux jeunes nouveaux pour que le modèle:GeoGroup fonctionne bien à nouveau, avec les noms, qui manquent actuellement dans OSM et Google Earth (depuis plusieurs années). Exemple : Liste des châteaux de la Charente. J'ai eu beau mettre "name=Castrum d'Andone" au modèle:Coord de la 3ème ligne, il apparaît toujours "#3" dans OSM. Merci d'avance pour vos efforts, Jack ma ►discuter 23 octobre 2022 à 08:36 (CEST)

Bonjour @Jack ma.
De ce que je comprends, la carte OSM utilise les données renvoyées par kmlexport. On peut voir dans l'export KML de Liste des châteaux de la Charente que les noms des éléments sont effectivement numérotés #1, #2, etc.
D'après le code source de kmlexport, il semble que le programme lise le HTML de l'article cible pour en extraire les liens créés par {{coord}} (Module:Coordinates), qui ont la classe mw-kartographer-maplink (ligne 327-330 du code source). A partir de ces liens, les coordonnées sont déterminées grâce aux attributs data-lat et data-lon mais le nom est explicitement vide (ligne 435 du code source).
($latitude, $longitude, $name) = ( $item->attr('data-lat'), $item->attr('data-lon'), '' );
Le nom vide est ensuite remplacé par un numéro ou par le nom de l'article s'il n'y a qu'un point à afficher (lignes 449-451 du code source).
Je présume qu'il n'est donc pas possible de corriger le problème sans une intervention sur le code source de kmlexport (à moins de changer totalement le comportement de {{coord}} pour ne plus passer par des liens mw-kartographer-maplink...).
Suggestion : faire une WP:DIPP pour ajouter un attribut data-name sur les liens générés par {{coord}} et faire un ticket sur Phabricator pour demander à ce que kmlexport en tienne compte lors de la lecture des liens mw-kartographer-maplink ?
--Golmote (discuter) 23 octobre 2022 à 11:39 (CEST)
Entièrement d'accord avec cette analyse. Si quelqu'un parmi vous peut s'en charger ? (je ne me sens ni suffisamment compétent ni disponible pour faire cela). Merci énormément d'avance, car le modèle:GeoGroup est très utile et utilisé, Jack ma ►discuter 24 octobre 2022 à 07:41 (CEST)
Après une deuxième lecture, j'ai l'impression que Module:Coordinates ne crée pas le lien manuellement en fait... il fait appel au tag <maplink> qui n'accepte pas de paramètre pour indiquer un nom, donc je ne vois finalement pas ce qu'on pourrait modifier nous-mêmes dans le module... Je pense que la résolution de ce problème ne peut se faire que du côté des devs. --Golmote (discuter) 24 octobre 2022 à 18:33 (CEST)

┌───────┘

Enregistré sur Phabricator
Tâche 321507

Bon j'ai créé un ticket sur Phabricator. On verra bien ce qu'ils en disent. --Golmote (discuter) 24 octobre 2022 à 19:16 (CEST)

Alternativement, s'il n'est pas possible de modifier le rendu du tag <maplink>, peut-être serait-il possible d'ajouter le paramètre geodata=oui/non au modèle {{coord}} (le module est déjà apte à recevoir cette info), ce qui permettrait de forcer les coordonnées à être associées à l'article et elles pourraient ainsi être retrouvées via l'API GeoData (comme c'est déjà le cas pour les coordonnées qui utilisent display=title : exemple pour la page Charente (département)). Mais ça demanderait considérablement plus de modifications à apporter à kmlexport je suppose... --Golmote (discuter) 26 octobre 2022 à 07:39 (CEST)

{{!!}} vs {{!}}{{!}}

Dernier commentaire : il y a 2 ans4 commentaires2 participants à la discussion

Bonjour,

En travaillant sur la Catégorie:Page contenant trop d'inclusions de modèles j'ai découvert un modèle qui, au lieu d'utiliser le modèle {{!!}} avait {{!}}{{!}}.

Je me suis donc dit que pour diminuer le nombre de modèles il fallait remplacer tous les {{!}}{{!}} par un seul {{!!}}.

En prévisualisant le modèle modifié j'ai constaté que le modèle {{!!}} apparaissait dans la liste "Modèles utilisés par cette page", ce qui est normal.

En comparant avec la prévisualisation de l'ancienne version j'ai constaté que le modèle {{!}} n'apparaissait pas dans la liste "Modèles utilisés par cette page". Je me suis donc rappelé que {{!}} n'est pas un modèle mais un mot magique.

Donc j'en viens à inverser complètement le raisonnement que j'avais au départ.

Ne faudrait-il pas mieux remplacer, au moins dans les modèles très utilisés, {{!!}} par {{!}}{{!}} ?

Avant de me lancer dans ce travail, je veux bien quelques avis/conseils au cas où j'aurais loupé quelque chose.

Merci. FDo64 (discuter) 23 octobre 2022 à 19:04 (CEST)

Bonjour FDo64. Contrairement à ce que peut faire croire l'intitulé de la catégorie, ce qui compte ici n'est pas le nombre de modèles mais la taille (du "wiki"code) après expansion de l'ensemble des modèles de la page (Post‐expand include size). Elle est limitée à 2 Mo. Si {{!}} avait été un modèle, remplacer {{!}}{{!}} par {{!!}} (et vice-versa) n'aurait eu aucun effet sur cette taille puisque l'ensemble correspond, dans les deux cas, à simplement deux barres verticales. En considérant que le mot magique {{!}} n'est pas comptabilisé parmi les modèles, le gain à l'utiliser plutôt que le modèle {{!!}} serait de deux petits octets. Cela est bien maigre. Il y a certainement des économies bien plus conséquentes à réaliser sur des modèles plus lourds.
Remarque 1. Les modèles "imbriqués" (comprendre appel d'un modèle dans le wikicode d'un autre modèle, par exemple sollicitation de méta-modèles) sont une source importante d'augmentation de la taille, puisque les tailles de chaque expansion sont cumulées. Quelques éléments de compréhension dans en:Help:Template limits, en anglais.
Remarque 2. La contrainte sur la taille des arguments de modèles (Template argument size) est rarement le facteur limitant, mais le remplacement proposé pourrait dans certaines situations augmenter cette valeur. Edit. : erreur de ma part, voir plus bas. — Ideawipik (discuter) 23 octobre 2022 à 22:52 (CEST)
Merci Ideawipik  . Donc pour ce modèle cela semble une mauvaise idée.
Je ne comprends pas ta deuxième remarque, même en lisant l'aide de wp:en. Comment en supprimant un modèle peut-on augmenter la taille des arguments de modèles ?
Pour information, je travaille actuellement sur l'optimisation du modèle {{Différence}}. En supprimant deux modèles dans sa version Bac à sable, j'arrive à diviser par 7 la taille des arguments de modèles et à gagner 1 seconde de chargement d'une page qui en met 5.
--FDo64 (discuter) 23 octobre 2022 à 23:44 (CEST)
@FDo64. Oups, désolé, erreur de ma part. Je songeais à un hypothétique cas {{modèle|{{!}}{{!}}}} à comparer à {{modèle|{{!!}}}}. Mais, comme la valeur passée en argument est développée avant le modèle externe, la taille des arguments de modèle sera la même (en l'occurrence 2 octets dans cet exemple), quelle que soit la syntaxe.
Toute optimisation technique sans inconvénient pour le lectorat et pour les rédacteurs est bonne à prendre, en considérant tout de même le gain et le nombre de pages à éditer pour appliquer l'amélioration. — Ideawipik (discuter) 24 octobre 2022 à 00:16 (CEST)

Modèle:syntaxhighlight

Dernier commentaire : il y a 2 ans16 commentaires4 participants à la discussion

Bonjour

J'ai crée le modèle:shl, semblable au en:template:syntaxhighlight, mais j'aimerais qu'il puisse mettre du texte « inline » aussi (dans le corps du texte, pas dans une boîte).

Pour pouvoir mettre <syntaxhighlight> dans un modèle, il faut utiliser {{#tag:}} apparemment, mais je n'ai pas réussi à trouver de la documentation dessus, et si un second paramètre semble marcher (pour lang="", un troisième ne marche pas (pour ajouter inline par ex.).

Est-ce que quelqu'un pourrait me donner un lien vers la doc de {{#tag:}}, ou bien même faire fonctionner le truc comme espéré ?

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 15 septembre 2022 à 23:06 (CEST)

Merci de t'y être mis LD  
Je viens de trouver mw:Template:Tag, c'est pas #tag:, mais c'est peut-être similaire ?
Je vais tester quelques trucs... Şÿℵדαχ₮ɘɼɾ๏ʁ 15 septembre 2022 à 23:48 (CEST)
Salut @SyntaxTerror
Les manuels sont mw:Manual:Tag extensions, mw:Manual:Parser functions et mw:Extension:SyntaxHighlight.
A première vue, si la syntaxe semble être <syntaxhighlight lang="html" line>...</syntaxhighlight> avec la balise, ce n'est pas le cas avec le tag, on devrait avoir quelque chose comme : {{#tag:syntaxhighlight|blabla|lang="html"|inline=1}}
Je ne suis pas certain que mon ajout aille dans la bonne direction ^^' LD (d) 15 septembre 2022 à 23:52 (CEST)
  LD : merci pour la doc.
Pour voir si ça marche, il n'y a qu'a tester avec la page de documentation du modèle (là, ça a pas l'air d'être ça encore). Şÿℵדαχ₮ɘɼɾ๏ʁ 15 septembre 2022 à 23:55 (CEST)
On dirait que c'est ça (tout en bas de la page) :
{{#tag:tagname
|content
|attribute1=value1
|attribute2=value2
}}
pourtant j'ai déjà essayé et ça marche pas... Şÿℵדαχ₮ɘɼɾ๏ʁ 16 septembre 2022 à 00:00 (CEST)
  LD : ils disent « <tagname attribute1="value1" attribute2="value2">Your content goes here‎</tagname> can be rewritten like this: {{#tag:tagname|Your content goes here|attribute1=value1|attribute2=value2}}
Mais le problème c'est que inline est pas un paramètre nommé, c'est pas inline=...
Et aussi c'est foutu pour les paramètres supplémentaires, parce qu'il faut les nommer explicitement dans {{#tag:}}.
Şÿℵדαχ₮ɘɼɾ๏ʁ 16 septembre 2022 à 00:07 (CEST)
J'y vois davantage un problème de CSS que de Tag car mw:Extension:SyntaxHighlight les mentionne comme attributs. Mais je ne vois pas vraiment de solutions à ma portée. LD (d) 16 septembre 2022 à 00:26 (CEST)

┌─────────────────────────────────────────────────┘

  LD : j'arrive à faire un inline avec {{#tag:syntaxhighlight|{{{1|}}}|lang={{{2|html}}}|inline=1}} :
  • machin, {{#tag:syntaxhighlight|<div>truc</div>|lang=html|inline=1}}, chose affiche :
    • machin, <div>truc</div>, chose
C'est déjà ça...
Par contre, dès que j'y mets des #if ou des #ifeq pour savoir si le paramètre 3 existe ou pas, ça marche plus...
Je laisse en plan pour ce soir, bonne nuit. Şÿℵדαχ₮ɘɼɾ๏ʁ 16 septembre 2022 à 00:36 (CEST)
En effet, ça me paraissait douteux que cela ne marche pas ; dans le wikitext de mw:Magic words on a la syntaxe : {{#tag:syntaxhighlight|{{^(}}translate{{)^}}{{^(}}!--T:2--{{)^}} Untranslated unit. Language: {{^(}}tvar name=lang>{{((}}TRANSLATIONLANGUAGE{{))}}{{^(}}/tvar{{)^}}.{{^(}}/translate{{)^}}|lang="html"|inline=1|style="backgrond-color:transparent; border:0; padding:0"}}
inline et style semblent pouvoir s'utiliser, en plus de start et de highlight.
En revanche, je ne sais pas trop comment gérer les autres parseurs ; une solution est peut-être d'évaluer en amont, en dehors du tag et de "switch" deux propositions de tag (avec et sans inline). Je vais tenter, bonne nuit   LD (d) 16 septembre 2022 à 00:38 (CEST)
Le problème semble être que la balise {{#tag:}} ne reconnait les paramètres que s'ils sont "en dur", i.e. pas présents dans un {{#if:}}, etc.
Ceci n'applique pas le style :
{{#tag:syntaxhighlight|le code|{{#if:true|style="border:3px dashed blue"}}}}
En revanche, ceci applique le style :
{{#tag:syntaxhighlight|le code|style={{#if:true|"border:3px dashed blue"}}}}
De même, ceci n'applique pas le inline :
{{#tag:syntaxhighlight|le code|{{#if:true|inline=1}}}}
En revanche, ceci applique le inline :
{{#tag:syntaxhighlight|le code|inline={{#if:true|1}}}}
Sauf que comme le inline est activé du moment que l'attribut est présent même sans valeur, il n'y a pas moyen de le désactiver…
Je n'ai pas trouvé de solution à ce problème en utilisant la balise {{#tag:}}.
En revanche, cela serait possible en Lua, en utilisant extensionTag() :
frame:extensionTag( 'syntaxhighlight', 'le code', { inline = '1' } )
od†n ↗blah 16 septembre 2022 à 00:47 (CEST)
@od†n : ouais, mais lua c'est tricher !  
L'idée de LD (d · c · b) avec des switch est pas mal, je tente un autre truc de mon côté (je dormirai l'an prochain lol). Şÿℵדαχ₮ɘɼɾ๏ʁ 16 septembre 2022 à 00:53 (CEST)
@SyntaxTerror J'imagine que cet essai (Modèle:Shl/Test -> Modèle:Shl/Bac à sable) se rapproche du rendu souhaité, mais il semble falloir bidouiller les attributs selon les langages.
En testant "inline=0", le résultat n'est pas le même avec un switch @Od1n, cela contournerait le problème.
Après, j'ignore s'il faut mieux définir un style, appeler la classe nowrap de MediaWiki:Common.css#L-99  + ou en définir une nouvelle. LD (d) 16 septembre 2022 à 01:00 (CEST)
@Od1n Est-ce qu'il y a vraiment un intérêt de définir 2 alternatives supplémentaires pour le style (cas n°2, forme étendue du cas n°1, voire étendre le n°0 ; cf. Modèle:Shl/Test), ou bien on peut les mutualiser, i.e, avoir que les alternatives "inline" et "non inline" avec |style={{#if:true|"border:3px dashed blue"}} selon ton exemple n°2 ?
En effet, j'ignore si le design du modèle est ainsi satisfaisant, et s'il sera plus simple de maintenir 2 alternatives plutôt que 4 (ou l'inverse), si jamais l'extension change radicalement. LD (d) 16 septembre 2022 à 01:14 (CEST)

┌─────────────────────────────────────────────────┘

  LD et Od1n : je crois que la première chose à faire c'est de voir si {{#tag:}} peut faire ce qu'on lui demande, et ça semble pas être le cas :
Regardez mon brouillon : la section D marche et pas la E, pourtant le résultat est censé être le même...
Si c'est comme ça pour tous les autres paramètres, il vaut mieux abandonner là et se dire que {{#tag:}} n'est juste pas le bon truc pour ce modèle.
Fini pour ce soir pour moi, bonne nuit. Şÿℵדαχ₮ɘɼɾ๏ʁ 16 septembre 2022 à 01:33 (CEST)
Bonjour SyntaxTerror, LD et Od1n. Ma réponse a été rédigée en parallèle de vos réflexions, donc désolé si cela doublonne.
Si on cherche un peu, on arrive toujours à quelque chose de fonctionnel. Mais, avec l'astuce appliquée, je ne garantis pas la propreté, ni l'absence de déclenchement d'erreur de Lint. Exemple :
{{#tag:syntaxhighlight|{{{1|}}}|lang={{#if:{{{2|}}}|{{{2}}}|html}}|start={{{start|}}}|highlight={{{highlight|}}}|{{{3|}}}=}}
Notes : 1. Par rapport à la proposition initiale, j'ai ajouté un test sur le deuxième paramètre car la syntaxe {{shl|code||p3}} aurait conduit à une absence de langage spécifié, ce qui est d'ailleurs catégorisé par MediaWiki (Catégorie:Page avec des erreurs de coloration syntaxique). 2. Le paramètre 3 peut prendre les valeurs valides « line » et « inline ». Et on pourrait contrôler la conformité de la valeur en ajoutant un test. Voire modifier la valeur par défaut. 3. On peut aussi ajouter des paramètres class/classe et style, afin d'inclure l'ensemble des options de la fonctionnalité.
Néanmoins comparons les syntaxes <syntaxhighlight lang=… inline>…</syntaxhighlight> et {{shl|1=…|2=…|3=inline}} ou <syntaxhighlight lang=… start=… highlight=… line>…</syntaxhighlight> et {{shl|1=…|2=…|3=line|start=…|highlight=…}}. Le gain est quasiment nul. Si on ajoute un nom de modèle peu évident/naturel, un risque de confusion de l'ordre des paramètres — D'autres modèles, comme {{langue}}, ont en premier paramètre le code langue, avant le texte. —, une solution pas très propre (sauf à trouver mieux ou passer en Lua), un coût (taille du contenu inséré via modèle, tests lors de l'exécution), on réduit encore la pertinence de ce modèle. On remarquera aussi que peu d'articles encyclopédiques ont besoin de cette spécificité d'affichage de code qui est principalement utile sur des pages d'aide et pour les contributeurs expérimentés, lors de discussions relatives à des questions techniques. Donc l'utilisation directe de la fonction "intégrée" au logiciel (mw:Extension:SyntaxHighlight), avec les balises, s'entend.
J'inviterais plutôt les utilisateurs potentiels, si ce n'est pas déjà fait, à ajouter un bouton d'insertion du code <syntaxhighlight lang="moin" inline> (ou approchant) dans leur interface d'édition personnalisée. — Ideawipik (discuter) 16 septembre 2022 à 01:35 (CEST)
Aparté : LD qui écrit {{#if:{{{3|inline}}}|…}}, test qui sera toujours vrai sauf à spécifier sciemment un paramètre 3 vide (cas non envisagé dans les essais ou la documentation dans laquelle on lit 3=line) ; avec une valeur du paramètre 3 jamais utilisée dans le code par la suite. SyntaxTerror qui se demande pourquoi son cas E ({{#tag:syntaxhighlight|…|lang=python|line start=3}}) ne fonctionne pas, alors que la fonction syntaxhighlight ne dispose pas d'attribut « line start » mais d'un attribut « start » et d'un "pseudo-attribut" (attribut sans valeur, présent ou absent) « line ». La nuit de sommeil n'aura pas pu faire de mal.   Chaleureuses salutations. — Ideawipik (discuter)

┌─────────────────────────────────────────────────┘

  LD, Od1n et Ideawipik : j'ai finalement simplifié le truc en utilisant {{#tag:syntaxhighlight|{{{1|}}}|lang={{{2|html}}}|inline=1}}.
C'est surtout un modèle destiné à être utilisé dans les discussions pour formater du code simplement, avec un inline forcé. Pour les articles, il vaut mieux utiliser des balises <syntaxhighlight> en dur. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 29 octobre 2022 à 20:56 (CEST)

Nom du modèle « Noble »

modifier
Dernier commentaire : il y a 2 ans3 commentaires3 participants à la discussion

Bonjour,

Une discussion a eu lieu sur le nom des modèles {{noble}} et {{noble-}}. Le nom actuel est en effet peu approprié puisque ces modèles peuvent s'appliquer à des personnes qui n'ont rien de noble comme Cassini Ier (≠ Cassini I), Cassini II, Cassini III, Cassini IV, qui ne sont ni nobles, ni papes, ni souverains, ni monarques, juste une célèbre « dynastie » d'astronomes, des entités numérotées comme gouvernement Charles de Gaulle III (merci à SenseiAC pour les exemples), ou des objets comme Mark IV ou Saturn V .

Quelqu"un aurait-il une suggestion pour un meilleur nom ? Il me semble qu'un nom purement technique sans référence à des personnes serait probablement plus approprié. Comme après tout ces modèles concernent des noms avec des chiffres romains, ma meilleure idée serait « Nom rom », et « Nom rom- » pour le modèle sans lien interne.

Qu'en pensez-vous ?

Amicalement, Alserv (discuter) 27 octobre 2022 à 16:17 (CEST)

Bonjour Alserv. Ce n'est pas le nom qui est romain mais le chiffre du numéro, on aurait {{n° rom}} ou {{numéro romain}} (mais ça ne veut pas dire grand chose non plus).
On ne peut même pas utiliser ordinal ou cardinal, car si « Louis Ier » est ordinal, « Louis II » est cardinal.
Je sais pas trop, mais l'important pour un nom de modèle est de décrire ce qu'il fait le plus souvent, on ne peut pas toujours trouver de nom qui colle à toutes les utilisations de tous les modèles.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 27 octobre 2022 à 17:09 (CEST)
On peut utiliser une cuillère à soupe pour manger de la purée, ou prendre un sirop pour la toux. On peut utiliser le modèle noble pour formater le nom d'un astronome, d'un gouvernement ou d'un char d'assaut. Ebroïn (le gnome) 27 octobre 2022 à 23:45 (CEST)

Lien interne de {CH4} à contre-sens

modifier
Dernier commentaire : il y a 2 ans10 commentaires4 participants à la discussion

Copie de mon message sur Discussion modèle:CH4#Lien interne à contre-sens.

Bonjour,

Je suis surpris que le sujet n'ait pas déjà été traité : m'est avis que lorsqu'on utilise {{CH4}}, le lien interne (vers méthane) ne devrait pas apparaître par défaut, car il oblige à traiter ce modèle différemment de ses équivalents : H2, CO2, O2, H2O (← utilisés ici sous la forme {espèce chimique}). Voyez par exemple ici : le code [[méthane]] ({{CH4}}) crée un LI doublon, contrairement aux autres molécules mentionnées.

Je propose donc de modifier le modèle ainsi :

  • {{CH4}} affiche CH4 ;
  • {{CH4|lien=méthane}} ou mieux, simplement {{CH4|lien}} affiche CH4.

Il faudra reprendre de nombreuses pages pour ajuster l'affichage, mais ça devrait en fin de compte être positif. Salutations — Vega (discuter) 31 octobre 2022 à 12:43 (CET)

Bonjour,
Vous avez déjà le modèle {{Formule chimique}}, {{fchim}} pour les intimes, qui accepte un paramètre lien=. Par souci de cohérence, il serait en effet positif d'accepter le même paramètre, comme tu as proposé.
Ma suggestion serait la suivante :
  1. Tu révises les 92 appels dans les 44 pages qui incluent ce modèle, pour remplacer {{CH4}} par {{CH4|lien=méthane}} si le lien doit être conservé après la modification du modèle. Comme l'argument lien= n'existe pas encore, il sera ignoré et l'affichage restera identique (compatibilité).
  2. Tu modifies le code du modèle {{CH4}} pour supporter le nouveau paramètre lien=. Inutile de réinventer la roue, autant appeler {{Formule chimique}} : {{Formule chimique|lien={{{lien|}}}|CH|4}} fera parfaitement l'affaire. J'ai placé le lien en premier, ainsi il est facile de copier-coller le début du modèle lors d'une adaptation identique d'un autre modèle. Maintenant le modèle sans paramètre ne génèrera plus de lien, et pour les pages révisées le paramètre lien= sera pris en compte, générant donc le même affichage (compatibilité). La page Utilisateur:Alserv/Brouillon2 contient provisoirement une proposition de modèle révisé, en anticipant quelque peu sur le point suivant.
  3. Pour bien faire, tu révises la documentation du modèle {{CH4}} : {{Documentation lien interne}} n'est maintenant plus approprié, vu qu'il y a un nouveau paramètre. Donc tu crées la page Modèle:CH4/Documentation. La page Utilisateur:Alserv/Brouillon3 contient provisoirement un exemple qui pourrait être utilisé comme point de départ très rudimentaire.
  4. Si le coeur t'en dit, tu peux aussi réviser les autres modèles qui sont dans le même cas, il y en a déjà quelques-uns de mentionnés dans la Catégorie:Modèle de formatage pour la chimie.
Amicalement, -- Alserv (discuter) 1 novembre 2022 à 16:14 (CET)
Super, merci pour ce mode d'emploi Alserv. Quelques questions avant de m'y mettre :
1. On ne peut pas demander à un bot de s'occuper de cela, ou au moins utiliser un outil de patrouillage pour semi-automatiser la tâche ? Ca fait longtemps que je dois m'y mettre.
4. Je n'avais pas connaissance des autres modèles. Apparemment toutes les molécules plus complexes présentent un lien comme CH4 actuellement, ça relativise l'argument que j'avançais. Je peux poser la question au Projet:Chimie sur ce qu'il faudrait faire.
Salutations — Vega (discuter) 1 novembre 2022 à 16:34 (CET)
Pour les modifications de {{CH4}} en {{CH4|lien=méthane}}, probablement qu'un bot pourrait régler cela assez rapidement. Je notifie @SyntaxTerror pour avoir son avis, il s'y connaît très bien en bots, et moi pas du tout.
Pour les autres molécules, ce serait en effet une bonne idée d'en parler avec le Projet:Chimie. Peut-être qu'il serait souhaitable d'adapter les autres modèles aussi. Dans ce cas, ce serait peut-être une bonne idée aussi de faire un modèle de documentation spécial, adapté simplement de {{Documentation lien interne}} mais mentionnant le paramètre lien=, ainsi il ne faudrait pas retaper toute la documentation à chaque fois.
Cordialement, -- Alserv (discuter) 1 novembre 2022 à 16:47 (CET)
@Alserv : houla ! Je m'y connais pas trop en bots, j'ai juste AWB, mais n'ai pas beaucoup d'expérience, ni de connaissances en langages de programmation.
De toute façon, pour les requêtes de bots, il faut mieux faire ça sur la page dédiée, ça permet à tous les dresseurs du moment de donner leur avis et de voir des problèmes qu'on aura peut-être oubliés.
Ici, je me demande l'intérêt de modifier le modèle {{CH4}} et d'ensuite remplacer {{CH4}} en {{CH4|lien=méthane}}, car en fait rien ne sera changé dans les articles, et si l'on veut changer le modèle ici, c'est justement pour éviter les doublons de liens internes.
Ici, on a 51 inclusions du modèle sur 44 pages [6], donc le passage d'un bot peut éventuellement être justifié, mais il vaudrait mieux à mon avis faire cette quarantaine d'articles un par un à la main et faire les modifs qui vont bien.
Par exemple, dans Acétylène#Combustion partielle du méthane, le lien n'est peut-être pas nécessaire, car il n'y a pas de liens pour toutes les autres molécules dans les autres équations.
À mon avis, il vaudrait mieux retirer le lien partout, et l'ajouter au cas par cas quand c'est nécessaire.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 1 novembre 2022 à 18:46 (CET)
Merci. Je pense que l'idée était que le lien était indésirable sur certaines pages, et puis pour uniformisation avec d'autres modèles de molécules.
Probable que c'est mieux de faire ça à la main. Cela me rappelle les pages qui mentionnaient « option citée » au lieu de {{Op.cit.}}, j'ai bien ri. Comme il n'y avait que 179 pages, j'ai fait ça à la main, c'était plus rapide au bout du compte. Alserv (discuter) 1 novembre 2022 à 18:56 (CET)
Bonjour. Je me demande pourquoi utiliser un modèle intermédiaire « CH4 » qui appelle dans son code {{fchim}} alors qu'on peut appeler directement dans les articles ce dernier modèle commun qui fonctionne pour toutes les formules chimiques. Au passage, il existe aussi {{fchim li}} qui génère un lien interne (si la page ou la redirection existe), bien que le lien ne soit pas toujours approprié. Exemple dans la documentation avec H2O qui est une page d'homonymie. — Ideawipik (discuter) 1 novembre 2022 à 20:09 (CET)
Je peux comprendre qu'un chimiste pas forcément informaticien préfère écrire CH4 plutôt que CH|4 en faisant attention à toutes les barres verticales et aux arguments pairs ou impairs de {{fchim}}. Maintenant c'est vrai que le résultat final est le même. -- Alserv (discuter) 1 novembre 2022 à 21:06 (CET)
Merci pour vos suggestions. Je risque de ne pas avoir le temps avant décembre, mais ce mini-projet me plaît. Ecrire {{CH4}} est tout simplement plus rapide et plus lisible que {{fchim|CH|4}}, tout comme les autres molécules simples citées. Je parie aussi que dans la majorité des cas, le lien est un doublon, puisque pour le WP:STYLE le nom de la molécule aura déjà été explicité et lié (ou alors je l'expliciterai). Bien à vous — Vega (discuter) 2 novembre 2022 à 14:52 (CET)
Pas de souci.
Le mieux serait de demander l'avis au Projet:Chimie pour choisir une solution cohérente, avec ou sans lien. Je ne suis pas sûr que le paramètre lien= soit vraiment utile, avec le modèle {{fchim}} il n'est utilisé que 63 fois sur les 42620 appels du modèle. Apparemment la plupart des articles préfèrent écrire [[lien|{{fchim|etc}}]].
Et les chimistes pourraient également jeter un oeil sur la page de statistiques qui répertorie un certain nombre d'articles avec des erreurs, qui ont probablement oublié d'utiliser {{=}} pour indiquer un lien chimique double =. Je ne suis pas chimiste, je n'ai aucune idée de ce que ça signifie, et je ne risquerais pas à faire une correction moi-même.
Cordialement, -- Alserv (discuter) 2 novembre 2022 à 16:26 (CET)

Modèles utilisant la légende d'une image comme texte alternatif

modifier
Dernier commentaire : il y a 2 ans5 commentaires3 participants à la discussion

Bonjour,
travaillant sur la correction des erreurs de Lint, il y en a certaines que je ne suis pas en mesure de corriger directement sur la page concernée. Il s'agit d'appels de modèles (en l’occurrence des infoboxes) qui répliquent la légende d'une image en tant que texte alternatif (option de fichier alt= d'une image). Or, dans certains cas, cette légende contient des éléments qui ne sont pas compatibles avec un texte (une légende avec des carrés de couleurs par exemple).
Outre le fait que dans cet exemple précis c'est totalement inutile, je m'interrogeais sur l'intérêt général de cette pratique : en effet, en l'absence de texte alternatif mais en présence d'un légende, les lecteurs d'écran (pour qui cette option de fichier est la plus importante) ne vont-il pas de toutes façons lire la légende de l'image, située juste en dessous ?
Les exemples de pages concernées sont les deux erreurs concernant alt= sur cette page, les modèles concernés ne proposant pas de paramètre alt= mais se contentant de répliquer leur paramètre légende= en tant que texte alternatif. Une correction évidente serait de rajouter un paramètre alt= sur ces modèles, mais cette question me semble tout de même intéressante car j'ai également rencontré des pages sur lesquelles la légende est simplement dupliquée dans l'option de fichier alt= d'une image, et je m'interrogeais sur l'intérêt de ceci si le texte alternatif ne décrit pas plus précisément l'image.
Wikipédiennement, Epok__ (✉), le 2 novembre 2022 à 21:15 (CET)

Bonjour,
D'une manière générale, les images sont illustratives d'un contenu textuel déjà présent dans l'article, de fait elles sont plutôt décoratives et n'apportent pas de plus-value à la compréhension de l'article (s'il est lu entièrement) ; mais on ne peut pas vraiment partir du principe que l'alternative ne sera jamais utile ; on peut cependant partir du principe que par défaut alt= doit être vide intentionnellement (w3). Qu'elle n'est à renseigner que lorsque son absence fait perdre un sens (comme lorsque les symboliques de diminution et augmentation sont utilisées par des fichiers plutôt que des symboles qui seraient lus : ▼ ▲).
En termes d'accessibilité, il est abérant d'avoir une légende et une alternative identiques : l'utilisateur aura vocalement le lecture de l'alternative et de la légende. A l'inverse, sans synthèse, seule la légende sera immédiatement accessible (l'alternative sera visible au survol de l'image).
Dans le cas des images informatives, la légende peut être très longue (comme un texte de paragraphe), l'alternative reste utile (w3) pour transmettre le sens, en peu de mots.
Plus généralement, l'alternative doit être utilisée pour aider les personnes à comprendre pourquoi une image était utile, ce qu'une description ne doit pas faire, et ce à défaut de pouvoir l'afficher ou le percevoir visuellement.
Le bon compromis est bien de dissocier les deux et d'utiliser les deux avec bon sens. LD (d) 2 novembre 2022 à 22:10 (CET)
Merci LD, ceci me conforte donc dans ce que je pensais : copier directement la légende en tant qu'option de fichier alt n'est pas utile.
Dans le cas des exemples ci-dessus, je vois donc procéder à la modification des modèles incriminés pour introduire un paramètre alt= (et sans mettre l'option alt= à la valeur du paramètre légende= en cas d'absence de paramètre alt=).
Wikipédiennement, Epok__ (✉), le 3 novembre 2022 à 08:30 (CET)
Bonjour Epok  , j'avais regardé le problème et j'en avais discuté dans la page du modèle et   SyntaxTerror m'avait convaincu que c'était pas forcément la meilleure méthode. En regardant plus loin je pense que le mieux serait probablement d'ajouter quelques lignes à la fonction nettoyageAlt de Module:Image pour qu'elle nettoie aussi les balises de <ref> qui pourraient être dans le alt (mais un manque de sûreté de ma part en Lua et la flemmeTM ont fait que j'ai pas continué là dessus). Mais oui, je ne vois pas dans quel cas il serait légitime d'avoir un <ref> dans un alt et donc à moins que la fonction soit mal utilisée le changement devrait être positif. Mais par contre c'est des regex ce qui est un problème à part entière surtout pour du HTML qui n'est pas régulier. Après il est toujours possible de faire un fonction qui manipule le string directement. mat.duf (discuter) 8 novembre 2022 à 01:34 (CET)
Merci Mat.duf pour cette réponse.
Néanmoins, entre deux, je me suis rendu compte que le modèle {{Infobox/Image}} gère correctement l'absence de texte alternatif, générant celui-ci à partir de la légende après nettoyage. Il suffisait donc simplement de supprimer la recopie de la légende sur le paramètre 4 de celui-ci.
Wikipédiennement, Epok__ (✉), le 8 novembre 2022 à 07:08 (CET)

Palette Dates

modifier
Dernier commentaire : il y a 2 ans2 commentaires2 participants à la discussion

Bonjour,

Suite à cette demande et après discussion avec @Bédévore, j'ai fabriqué une {{Palette Dates}} librement inspirée de la {{Palette Années}} mais avec les liens complètement configurables, ce qui permet d'utiliser cette palette par exemple dans les pages de catégories.

Comme c'est la première fois que je manipule des palettes, tous les avis sont les bienvenus.

Cordialement, -- Alserv (discuter) 8 novembre 2022 à 15:37 (CET)

Discussion déplacées dans Discussion modèle:Palette Années#Palette Années. --FDo64 (discuter) 19 novembre 2022 à 19:18 (CET)

Discussion sur Modèle:Centrer

modifier
Dernier commentaire : il y a 2 ans1 commentaire1 participant à la discussion

Bonjour, je fais suivre ici, une discussion que j'ai ouverte pour parler d'une évolution de {{Centrer}}. Je pense avoir un meilleure visibilité ici pour recueillir des avis. Merci. mat.duf (discuter) 16 novembre 2022 à 20:39 (CET)

Ce document provient de « https://fr.wiki.x.io/w/index.php?title=Discussion_Projet:Modèle/Archive_2022&oldid=208196001 ».
Revenir à la page « Modèle/Archive 2022 ».