Projet:Modèle/Demandes

Demandes/améliorations de modèles

Cette page regroupe les requêtes des modèles à construire ou améliorer. Si votre demande concerne une « Infobox », une « Palette » ou une « Boîte Utilisateur », veuillez consulter les projets respectifs.

Avant de faire une demande :

OOjs UI icon next-ltr-progressive.svg Ajouter une demande pour un modèle

OOjs UI icon next-ltr-progressive.svg Demander une infobox

OOjs UI icon next-ltr-progressive.svg Demander une palette

OOjs UI icon next-ltr-progressive.svg Demander une boîte utilisateur

Cette page est automatiquement archivée. Les sections répondues n'ayant aucune activité depuis 7 jours sont automatiquement déplacées.

Problème des titres de section de la page Wikipédia:Demande de suppression immédiateModifier

Travail demandé par Ariel (discuter) 2 novembre 2020 à 17:51 (CET)[répondre]

  • Avancement :
    0 %
    Le modèle créé sous le nom {{noredirect'}} devrait répondre aux attentes. 24 mars 2021 à 11:30 (CET)
  • Détails de la demande : Ce n'est pas exactement un problème de modèle, mais c'est un problème de la compétence des modélistes : quand la page à supprimer est une redirection, quand on clique dessus on arrive sur la page de destination alors que la demande de suppression immédiate porte sur la page de redirection elle-même. Du coup, quand un administrateur voit plein de pages à supprimer et qu'il fait ça un peu vite, il risque de supprimer la page de destination au lieu de la page de redirection. Il faudrait qu'en cliquant sur le titre de la section on arrive sur la page à supprimer elle-même, que ce soit ou non une redirection. Il faudrait donc ajouter un &redirect=no quelque part dans le code des sous-pages, mais je ne sais pas bien où. Pouvez-vous y jeter un coup d'œil, si vous avez compris ma demande ? — Ariel (discuter) 2 novembre 2020 à 17:51 (CET)[répondre]
  • Article(s) pour le modèle : (hors-sujet)
  • Discussions :
    Si j'ai bien compris il faudrait modifier le modèle {{a'}}, mais celui-ci est protégé et est surement utilisé par ailleurs. Il faudra peut-être faire un autre modèle dérivé. — eru [Discuter] 2 novembre 2020 à 18:45 (CET)[répondre]
    Bonjour Ariel. C'est bien le modèle {{a'}} qui est utilisé. Pour les redirections, il existe déjà {{noredirect}} ou {{noredirect-}}. Mais, le premier fait appel à une fonction d'analyse coûteuse à éviter sur ce type de page où le modèle est répété ; le second n'est pas adapté ici, étant donné que le lien reste bleu que la page existe ou ait été supprimée. Il existe aussi {{A-redir-simple}} plus léger. Voici une autre proposition de modèle, par exemple, nommé « Modèle:A'redir » qui afficherait les deux liens et pourrait être utilisé, uniquement pour les redirections. Néanmoins, il faudrait revoir la page Wikipédia:Demande de suppression immédiate, pour différencier la création de section selon que l'on demande la suppression d'un article (a') ou d'une redirection (a'redir), avec deux boutons distincts.
    Le code du modèle pourrait-être quelque chose comme :
    <includeonly><span class="plainlinks" id="<nowiki>{{</nowiki>a'redir{{!}}{{anchorencode:{{{1|}}}}}<nowiki>}}</nowiki>">[{{fullurl:{{{1|}}}|redirect=no}} <span title="Redirection">↳Redir. : </span>] [[:{{{1|Titre manquant}}}]]<!--
    --> · {{Abréviation discrète|1=[{{fullurl:{{{1|}}}|action=history}} h]|2=Historique}}<!--
    --> · {{Abréviation discrète|1=[{{fullurl:Spécial:Journal|page={{urlencode:{{{1|}}}}}}} j]|2=Journaux}}</span><!--
    --> · [[Spécial:Pages liées/{{{1|}}}|<span title="Pages liées">↵</span>]]<!--
    --></includeonly>
    
    Ideawipik (discuter) 5 novembre 2020 à 23:28 (CET)[répondre]
    Merci Ideawipik  , je vais tester cette proposition en sous-page de ma page utilisateur. — Ariel (discuter) 6 novembre 2020 à 07:25 (CET)[répondre]
    Bonjour Ariel. Un modèle de ce type pourrait également s'intituler « Noredirect' » puisqu'il serait applicable pour plusieurs espaces par exemple pour une redirection de modèle ou une redirection de catégorie. Comme l'est d'ailleurs « A' » qui accepte la syntaxe {{a'|Catégorie:…}}. Il s'agirait d'une version allégée du modèle Noredirect (qui lui appelle une fonction coûteuse lors du test d'existence de la page). Si un simple test if n'est pas trop lourd, on peut gérer le cas de l'argument vide dès le début.
    Pour la mise en œuvre sur la page des suppressions immédiates, il suffirait d'ajouter, dans l'en-tête, un bouton comme [{{fullurl:Wikipédia:Demande de suppression immédiate|action=edit&section=new&preload=Wikipédia:Demande_de_suppression_immédiate/preload&editintro=Wikipédia:Demande_de_suppression_immédiate/editintro&preloadtitle=%7B%7Ba%27redir%7C1%3DTitre+de+la+page%7D%7D}} {{bouton cliquable|Lien direct, cas d'une redirection}}] (← exemple pour a'redir à adapter au nom choisi). Idem dans Wikipédia:Demande_de_suppression_immédiate/Utilisation.
    Enfin, il serait bien d'actualiser l'aide Wikipédia:Demande de suppression immédiate/editintro, en fonction du choix retenu, pour gagner en cohérence.
    Je te laisse voir ce qu'il en est et faire la proposition, sur la page de discussion de la page concernée, d'une évolution qui réduirait les confusions sur l'objet de la demande de suppression. Je me tiens disponible pour les questions techniques. — Ideawipik (discuter) 11 novembre 2020 à 20:32 (CET)[répondre]
    En fait, et je regrette de ne pas l'avoir fait remarquer plus tôt (je n'y pensais alors plus), ce que je souhaite est exactement ce qui se passe avec le modèle « Demande de renommage/Titre » (appelé dans la page WP:DR) : quand l'une ou l'autre des deux pages mentionnées (voire les deux) est une redirection, en cliquant dessus on n'arrive que sur la page, pas sur la destination finale. — Ariel (discuter) 4 janvier 2021 à 18:44 (CET)[répondre]
    Bonjour Ariel. Le modèle que tu cites fait appel à la même technique que la proposition ci-dessus (lien "externe" sans suivre la redirection). Le petit problème est qu'un tel lien vers une page supprimée n’apparaîtra pas en rouge. C'est pour cette raison qu'il est préférable de mettre deux liens : un "normal" (entre doubles crochets qui initialement suit la redirection et qui deviendra rouge à la suppression de la page) et un lien « redirect=no » conduisant à la page à supprimer et qui après suppression mènera à la même page (confirmant sa suppression) mais restera bleu. C'est ce qui avait été proposé en novembre. L'affichage de rouge dans le titre de section permet aux opérateurs de voir que la tâche est déjà accomplie. Bonne année à toi. — Ideawipik (discuter) 4 janvier 2021 à 23:29 (CET)[répondre]
    Bonjour Ariel. Comme j'ai aussi eu besoin d'un modèle de ce type, pour une liste, j'ai finalement créé {{noredirect'}}, après avoir hésité sur le nom « Noredirect' » ou « A'redir ».
    En ce qui concerne la page, Wikipédia:Demande de suppression immédiate (h). J'ai remarqué un autre défaut, à propos des ancres sollicitées dans les commentaires de modification de la page. Les sections sont initiées dans « Faire une demande ». Le lien vers la section, généré par défaut pour le résumé de modification, correspond à la syntaxe choisie pour le code mais le titre réel de la section sera « Titre (d · h · j · ↵) » dans le cas du modèle A'. Pour pallier cette différence, le modèle A' génère une ancre tentant d'imiter le code et valant {{a'|Titre}} (accessible par un lien interne [[#&#123;&#123;A'&#124;Titre&#125;}]]). Donc si le champ est rempli avec exactement la syntaxe précédente, le lien sera fonctionnel vers l'ancre du modèle. En revanche, si le contributeur choisit {{a'|1=Titre}} ou même {{A'|Titre}}, le lien ne marchera pas et mènera en haut de la page. Techniquement, on doit pouvoir améliorer cela soit en examinant la présence du paramètre "nommé" « 1= », soit en générant plusieurs ancres au même endroit. Dans les deux cas, ce serait soit lourd pour le code du modèle et son exécution, soit très lourd pour le code HTML de la page générée … et encore, il ne sera pas évident de bien prendre en compte les distinctions « 1=Titre » et « 1= Titre » ni les variantes (majuscules initiale ou alias) dans les noms de modèles. Je ne pense pas que le jeu en vaille la chandelle, mais si quelqu'un a une idée lumineuse… Une alternative pourrait-être de préconiser la syntaxe {{a'|Titre}} et d'inviter le contributeur à remplacer manuellement les éventuels (très rare) signes « = » du titre par « {{=}} ». Cordialement. — Ideawipik (discuter) 24 mars 2021 à 11:30 (CET)[répondre]
    Merci Ideawipik  . Je n'imaginais pas que ma demande poserait autant de difficultés. Ton modèle {{noredirect'}} est intelligent, mais j'ai peur qu'il n'aide pas beaucoup à éviter la suppression intempestive de la page de destination (dans le cas d'une redirection à supprimer), car il propose les deux liens (vers la redirection et vers la destination) : comme pour les non-redirections ça donne la même chose et que le 2e lien est plus visible que le premier, la confusion reste probable.
    Sinon, j'avoue ne pas avoir compris le problème d'ancrage posé par la syntaxe 1=. — Ariel (discuter) 24 mars 2021 à 14:02 (CET)[répondre]
    @Ariel. Pas facile de concilier tous les avantages… Il est tout à fait possible de revoir la présentation du modèle proposé. En gardant les deux liens mais inversant les libellés ? Donc, voici un résumé.
    • 1a. Soit on considère que le nombre de suppressions de redirections sur une même page de WP:SI (y compris les archives) est potentiellement élevé et alors, pour ne pas prendre le risque d'un problème d'affichage (Catégorie:Page avec trop d'appels dispendieux de fonctions parseurs, cela altérerait l'affichage de WP:SI mais aussi l'apparition de la page WP:SI dans les pages liées à la page de redirection), il est impératif de privilégier un modèle sans ces fonctions comme {{noredirect-}} (avec l'inconvénient que le lien "externe" restera bleu même quand la page sera supprimée), ou en compromis, un modèle affichant les deux liens comme {{A-redir-simple}} ou le récent {{noredirect'}}.
    • 1b. Soit on considère que le nombre de demandes de suppression de redirections est faible, et alors le modèle {{noredirect}} est approprié, car il génère un lien vers la page de redirection si elle existe puis un lien rouge lorsque cette dernière n'existe plus.
    Dans tous les cas, l'usage d'un de ces modèles est préférable à celui de {{A'}} qui, avec un seul lien vers la page cible via la redirection, présente un risque de suppression de la mauvaise page. Cela dit, le reste est une question de praticité et de prise d'habitudes pour les usagers (demandeurs et opérateurs).
    • 1c. Si le problème est intermédiaire et ne concerne que les archives, il serait envisageable que le bot archiveur, lors des transferts quotidiens, remplace les appels au modèle {{noredirect|…}} par des liens rouges simples [[…]], uniquement si la page « … » a été supprimée. Ou bien qu'il fasse une substitution de modèle ou, encore plus simple, remplace le nom du modèle par celui d'un modèle plus sobre. Mais pour voir la possibilité de cela, il faut demander au dresseur   Orlodrim, ce qu'il en pense.
    2. La question des ancres est indépendante. Va sur historique de la page « Wikipédia:Demande de suppression immédiate », cherche le texte {{a'| et essaye de cliquer sur les liens. Par exemple, aujourd'hui, on a {{a'|Commune de Mugongomanga}} qui mène à l'ancre existante (générée par le modèle) et {{a'|1=Ovide nombre livre}} qui ne mène pas à l'ancre {{a'|Ovide nombre livre}} générée par le modèle. Est-ce plus clair ?
    3. Mise en œuvre. Une fois fixés sur le choix pour le point 1, il sera possible d'adapter en-têtes/formulaires comme indiqué dans le message du .
    Ideawipik (discuter) 24 mars 2021 à 16:12 (CET)[répondre]

modèle « Autres projets » : problème de mise en page pour les mobilesModifier

Travail demandé par Ariel (discuter) 13 novembre 2020 à 14:42 (CET)[répondre]

  • Avancement :
    0 %
  • Détails de la demande : Je vous transmets cette diff, où une IP explique que le positionnement standard du modèle « Autres projets » (c.-à-d. juste après le titre de section « Voir aussi ») pose des problèmes d'affichage sur les mobiles. Pour ma part je n'en sais rien, je ne consulte quasiment jamais Wiki sur mon mobile.
  • Article(s) pour le modèle : quasiment tous
  • Discussions :

Effectivement, j'avais déjà remarqué que la boîte {{Autres projets}} a un mauvais rendu sur mobile. Le modèle utilise les classes .boite-a-droite et .boite-grise (et il y a par ailleurs .boite-sans-fond), qui sont définies dans le MediaWiki:Common.css mais pas dans le MediaWiki:Mobile.css.

En revanche il ne faut pas se contenter de recopier le CSS, pour la version mobile il faudrait que la boîte prenne toute la largeur de page. Il faudrait aussi vérifier le rendu des autres modèles qui utilisent ces classes.

Vu l'omniprésence de ce modèle, je pense qu'il serait assez important de traiter la chose. Avis aux intéressés ;-)

od†n ↗blah 14 novembre 2020 à 03:37 (CET)[répondre]

Merci od†n  . À propos du même modèle, et si tu as un moment (?), pourrais-tu m'expliquer pourquoi on m'a refusé d'ajouter un paramètre nommé facultatif pour permettre de mettre la boîte à gauche, ce qui serait très utile quand l'infobox est plus haute que le texte (voire énormément plus haute, ça se produit dans un grand nombre d'articles scientifiques sur des composés chimiques ou des minéraux où il n'y a pas grand chose à dire à part la foultitude de données dans l'infobox) ? Je me rappelle qu'on m'avait dit que ça avait déjà été refusé antérieurement, mais sans me donner d'autre explication). Merci d'avance. — Ariel (discuter) 14 novembre 2020 à 07:32 (CET)[répondre]
@Ariel Provost et @Od1n : il faudrait surtout que la version mobile donne accès aux autres projets en colonne de gauche, comme pour les liens interwikis. Cela permettrait de supprimer la boîte autres projets. TED 19 janvier 2021 à 05:14 (CET)[répondre]

Outil pour sourcer pour l’éditeur normalModifier

Travail demandé par TED 19 janvier 2021 à 05:17 (CET)[répondre]

  • Avancement :
    0 %
  • Détails de la demande : Bonjour ! Il existe en mode « éditeur visuel » un outil pour créer des sources à partir d’un lien http, un ISBN, un DOI ou autre… mais cet outil n’est pas disponible avec l’éditeur normal. Serait-il possible de l’ajouter ? TED 19 janvier 2021 à 05:17 (CET)[répondre]
(NB : ne sachant pas exactement où poser cette question, je l’ai posée aussi là : Discussion Projet:Scripts et gadgets/Demande de fonction#Outil pour sourcer pour l’éditeur normal) TED 20 janvier 2021 à 20:24 (CET)[répondre]
  • Article(s) pour le modèle : potentiellement tous.
  • Discussions :
@Thomasbr33, vu que tu sembles pouvoir créer des gadgets similaires, je me permets de te notifier sur cette demande. LD m'écrire 29 juin 2021 à 16:10 (CEST)[répondre]
  LD : Yep merci je vais voir ce que je peux faire, mais je ne garantis rien   --Thomasbr33 (discuter) 29 juin 2021 à 17:20 (CEST)[répondre]

Conventions typographiques et modèle/module LangueModifier

Travail demandé par LD m'écrire 12 février 2021 à 21:20 (CET)[répondre]

  • Article(s) pour le modèle : beaucoup trop  
  • Discussions :

Ajouter un paramètre au modèle « Test 0 »Modifier

Travail demandé par Bru [M'écrire] 27 avril 2021 à 01:54 (CEST)[répondre]

  • Avancement :
    65 %
  • Détails de la demande : Bonjour  ,

Il faudrait, si possible, rajouter un paramètre style dans le modèle {{test 0}}, qui, si le champ contient oui, ajoute le texte « Elle n'est pas rédigée dans un style encyclopédique. Sur Wikipédia, soignez l'orthographe, la compréhensibilité, la clarté, la neutralité, la sobriété et la précision du texte ('''[[Aide:Style encyclopédique|aide]]'''). » dans le message posté, de la même manière que pour les autres paramètres du modèle.

Par ailleurs, il faudrait modifier le lien interne apparaissant à la fin de la phrase présente si le paramètre pov est ajouté, afin qu'il ne dirige pas vers Wikipédia:Style encyclopédique mais vers Wikipédia:Neutralité de point de vue.

Enfin, la phrase du modèle : « Cependant, j'ai dû la retirer car : » devrait être remplacée par : « Cependant, j'ai dû la retirer pour les raisons suivantes. » afin d'être typographiquement correcte.

Merci beaucoup de votre aide par avance, et n'hésitez pas s'il y a besoin de davantage de précisions.  

Cordialement.

  • Article(s) pour le modèle : Pages de discussion des débutants, probablement plusieurs milliers.
  • Discussions : Juste ici.

Bonjour Bru. Je n'ai pas les droits pour modifier la page mais voici une proposition de wikicode à enregistrer dans la page du modèle. J'ai ajouté :

  • quelques simplifications du code final après substitution sur la page de discussion de l'utilisateur ;
  • un paramètre « 3 » ou « oldid » permettant de citer une modification ayant eu lieu sur plusieurs éditions (à l'image du modèle {{non signé}}) et un alias (« diff ») pour « 2 ».

La mise à jour de la documentation suivra. Elle en a d'ailleurs besoin car il y a dans le Templatedata une erreur de confusion entre « Valeur automatique » et « Exemple ». Je pourrai m'en charger une fois la modification effectuée. Je rajouterai aussi la catégorie Catégorie:Modèle à subster.

Remarque annexe. L'idéal pour ce modèle serait que, dans le cas où le paramètre autre n'est pas défini et aucun des paramètres (sources, POV, style, wikif, LE) ne vaut « oui », l'enregistrement ne soit pas effectué et qu'apparaisse un message d'erreur. Mais je ne sais pas faire cela. Si quelqu'un le sait, merci. En revanche, il ne doit pas être trop difficile de catégoriser, lors de l'enregistrement, les pages sur lesquelles l'insertion ne respecterait pas la règle, afin de signaler la mauvaise utilisation aux poseurs. Faut-il faire cela ?

En espérant ne pas avoir fait de boulette. Une fois le code fixé, on pourra solliciter un opérateur sur Wikipédia:Demande d'intervention sur une page protégée avec un simple lien interne ancré vers la présente section. Alternative : demander à Ariel qui s'était intéressé au modèle {{Test 1}}, il y a quelque temps. En attendant vos réactions, salut. — Ideawipik (discuter) 27 avril 2021 à 11:53 (CEST)
PS: Ces stats laissent à penser qu'il serait préférable de faire de raison un alias de autre. Certainement une question de moindre surprise avec les paramètres d'autres modèles semblables. — Ideawipik (discuter) 27 avril 2021 à 12:03 (CEST)[répondre]

Merci Bru pour la demande et Ideawipik pour la réponse. Tant qu'à faire, serait-il possible de mentionner plusieurs articles, à l'image de ce que Modèle:Test 1 permet ?
Pour le cas où aucune raison n'est indiquée, on peut aussi afficher le modèle sans liste, en supposant que le poseur détaillera dessous les raisons (exemple), éventuellement après un message d'avertissement (du type "Vous n'avez pas indiqué de motif. Confirmez ?"). — Vega (discuter) 27 avril 2021 à 19:45 (CEST)[répondre]
PS : avec mon message, je ne sais s'il faut passer à 45,43 % d'avancement ou reculer à 45,08 % =)
  Vega et Ideawipik : bonsoir !
Un grand merci, Ideawipik, pour le travail effectué et les bonnes idées d'amélioration que tu as apporté. Merci également de prendre en charge l'actualisation de la documentation.
Dans le cas où aucun motif n'est fourni, pour moi, sauf si on adapte le modèle pour qu'il soit malgré tout cohérent, je suis d'accord qu'il faudrait qu'apparaisse un message d'erreur au lieu du message peu sensé actuel, et catégoriser les mauvais usages me paraît également utile. Dans ton exemple, Vega, tu as tout de même signalé un motif, ce qui ne pose alors pas de problème.
Deux remarques supplémentaires :
  • je crois que C-helper a du mal avec ce modèle, car il indique que fournir un motif à l'annulation est facultatif (ce qui n'est pas le cas), et recopie tout le code du modèle (voir ce diff).
  • serait il possible de faire en sorte que, si un seul motif est fourni, la phrase ne soit pas Cependant, j'ai dû la retirer pour les raisons suivantes. mais Cependant, j'ai dû la retirer pour la raison suivante. ?
Merci encore !  
Cordialement, — Bru [M'écrire] 27 avril 2021 à 20:38 (CEST)[répondre]
  Vega et Bru Water : Quelques réponses, en vrac. Pour ceux qui veulent aller à l'essentiel : passer directement ici.
Il y a différents types de messages d'erreur, en général.
  1. Message d'erreur, généré dans le modèle, affiché en rouge dans le texte. Pas très adapté ici car le poseur ne prévisualisera pas forcément la page et ne relira pas forcément la page après enregistrement. Il ne serait pas très sérieux qu'un nouveau trouve sur sa page un message d'avertissement avec une erreur.
  2. Un pop-up apparaissant au moment de la validation. Peut-être faisable dans un gadget. Je ne connais pas C-helper, mais si les « patrouilleurs », qui apposent régulièrement des messages préformatés en pddU, l'utilisent et vu la structure du formulaire, j'imagine qu'il ne devrait pas être trop compliqué de rajouter une étape ou un contrôle dans le cas du modèle « Test 0 ». Si quelqu'un sait où sont les sources de cet outil, je pourrai y jeter un coup d'œil, sans garantie de résultats.
  3. Un avertissement dans l'esprit de ce qui se passe en cas de conflit d'édition, lors de l'enregistrement
Je ne maîtrise pas techniquement les deux derniers cas. Mais fait remarquer que si quelque chose est mis en place pour cela, le système ne doit considérer que les ajouts sur la page éditée (diff) et non le préexistant dans la page. Sinon, des contributeurs venant juste déposer une message sans aucun rapport pourraient avoir des surprises si la page contient un {{Test 0}}. Il y a aussi une particularité à prendre en compte. Puisque le modèle subit une substitution le wikicode qui sera enregistré sur la page diffère de celui entré par l'utilisateur. À quel moment un contrôle est possible ?
Pour le reste (fait dans le bac à sable) :
  •   Le "code" dans le résultat final (visible dans le diff) n'est pas lié à C-Helper ou un quelconque éditeur mais au modèle lui-même. Le premier point de la première réponse et l'ajout de plusieurs "safesubst" déjà effectué dans la proposition initiale résoudra le défaut actuel qui entraîne du texte inutile, des octets "consommés" pour rien (taille, stockage) et un code pas simple du tout pour un nouveau qui éditerait le message.
  •   Gestion du singulier/pluriel. J'ai bien une petite idée et ferai des tests. Si aucun motif n'est donné, le message pourrait être « Pseudo du poseur vous en expliquera les raisons. » Comme le texte est rédigé à la première personne, plutôt « Je devrais vous fournir des explications. » Dans le même temps, on catégoriserait la page dans « Catégorie:Modèle de message « Test 0 » utilisé sans motif/explication/raison » Alternative possible : utiliser une catégorie commune avec d'autres modèles de message qui seraient dans le même cas de figure et utiliser des clés de tri (lettres) pour distinguer les différents modèles.. Les patrouilleurs surveilleraient régulièrement la catégorie et "gronderaient" leurs acolytes dont l'action au rabais l'alimenterait. Et on aurait moins besoin du message d'avertissement/erreur dont on a parlé précédemment.
    Techniquement, dans tous les cas, le modèle sera un peu plus lourd, il sera donc encore plus important de s'assurer que le modèle est bien substitué sur les pages et non pas simplement inclus. Il y aurait une évolution qui réduirait légèrement la complexité du code du modèle. Pour les paramètres optionnels (sources, POV, style, wikif, LE), au lieu d'avoir une activation [« oui » → ON ; tout le reste → OFF], serait-il acceptable de passer au fonctionnement suivant : [Paramètre non vide (même "non") → ON ; paramètre inexistant ou vide → OFF] ? L'utilisation serait la même qu'aujourd'hui, sauf pour les usagers, s'il y en a qui ont pris l'habitude de renseigner tous les paramètres [oui/non]. Sur les 12 000 modèles non substitués seulement sept portent des paramètres valant « non ». Ces derniers et un wikif=Hors sujet mis à part, on n'a jamais autre chose que vide ou « oui » exemple pour LE Un avantage, mineur, serait que |LE=x suffirait à activer le paramètre. Ne sachant comment fonctionne le C-Helper, je ne me risquerais pas à faire cette modification pour l'instant. Et puis finalement, ce n'est pas plus mal d'avoir un paramètre uniformisé, imposé, On pourrait aussi en tirer avantage.
  •   Possibilité de mettre plusieurs articles et plusieurs liens vers des modifications. Envisageable mais cela voudrait dire de passer à des paramètres nommés, ce qui ne serait pas plus mal, quand on voit les confusions comme le montre cette recherche. En effet, il faudrait des articleN, diffN et oldidN.
Après avoir écrit tout cela, j'ai trouvé Modèle:Test 0/Bac à sable et me suis amusé, avec une proposition assez complète. N'hésitez pas à tester dans des pages de discussion utilisateur ou brouillons. Vous n'êtes pas obligés d'enregistrer.
  •   Pas fait. Si on veux exploiter les options du modèle amélioré, à partir de C-Helper, ce dernier aura peut-être besoin d'une mise à jour, pour y implémenter les nouvelles possibilités. C'est par où ?
Ideawipik (discuter) 28 avril 2021 à 20:49 (CEST)[répondre]
  Ideawipik et Bru Water : pfiou, j'avais sous-estimé le chantier que ça demanderait. Merci pour ces investigations ! Et pour les LI qui m'ont permis de comprendre enfin l'intérêt de substituer ou pas. Quelques éléments de réponses :
  • Message d'erreur : l'avertissement "type 3" est ce à quoi je pensais, mais si c'est compliqué on pourra sûrement s'en passer. Je ne sais pas modifier ta recherche pour vérifier s'il y a des cas où tous les paramètres >1 sont vides (et encore, seulement pour ceux non substés)... À vrai dire, m'est avis que l'utilisation étendue de ce genre de messages avant publication (détection d'erreurs de modèles, de vandalismes, de LE dans le texte, etc.) économiserait beaucoup de ressources humaines et machines prises par les corrections, mais des facteurs m'échappent peut-être. Ils ne sont pas déjà davantage utilisés sur en.wiki ?
  • Paramètres nommés : personnellement, je trouve plus rapide de ne pas avoir à nommer les paramètres, en tout cas le premier.
Salutations — Vega (discuter) 29 avril 2021 à 00:03 (CEST)[répondre]
Bonjour,
Quel travail ! Merci infiniment.  
Je suis d'accord avec Vega pour le type d'avertissement, mais je n'ai aucune idée de comment configurer ça sur le plan technique. L'idée que le modèle indique que les raisons seront détaillées en dessous si aucun paramètre n'est renseigné me semble par ailleurs bonne.
Pour afficher la phrase par simple inclusion du paramètre et pas seulement si oui est présent, je trouve ça également plus simple, donc j'y suis favorable si ça ne cause pas de problème ! J'ai mal compris le rapport entre cette modification et C-helper, par ailleurs, mais tu peux trouver le code du gadget sur cette page — le script est géré par 0x010C, mais celui-ci est absent jusqu'en février 2022.
Enfin, merci pour le brouillon, je vais aller tester tout ça !
Cordialement, — Bru [M'écrire] 29 avril 2021 à 09:24 (CEST)[répondre]
  Vega et Bru Water
Messages. De ce que j'ai vu comme messages lors de l'édition et sur lesquels on pourrait jouer :
  • les messages d'avertissement préventifs qui apparaissent en haut de page lorsque l'on clique sur « Modifier le code » d'une page particulière. Il rappelle les instructions spécifiques pour ladite page (on peut le voir pour certaines pages de requêtes). Pas adapté ici.
  • les messages qui à la prévisualisation avertissent d'une possible erreur. Par exemple, il arrive de voir « Avertissement : <Nom de la page éditée> appelle Modèle:<Untel> avec plus d'une valeur pour le paramètre « 1 ». Seule la dernière valeur fournie sera utilisée. ». Ce serait un bon début mais encore faut-il que le patrouilleur prévisualise.
  • l'avertissement de "type 3", après validation et prévenant l'enregistrement jusqu'à correction. Piste à creuser. Il demandent un développement plus en amont. Si vous avez des exemples observés, histoire de s'inspirer de l'existant… Mais n'attendons pas qu'une solution sur ce point soit établie pour modifier le modèle.
Paramètres
  • Bien sûr, les paramètres positionnels 1 et 2 restent et resteront des alias des nouveaux article1 et diff1. Mais pour la suite, il est impossible de mettre des paramètres non nommés ayant des fonctions différentes et dont le nombre est variable, sauf à soit analyser le contenu (et encore ... comment savoir si en écrivant 123, le contributeur veut dire article 123, diff=123 oldid=123), soit se trimballer des « ||||| » pour les paramètres vides (Bonjour les yeux, confusions assurées. Et qu'adviendra-t-il si on augmentait un jour le nombre de paramètres acceptés ?)
  • La question du changement de critère ON/OFF n'est pas indispensable. Le gain en performance serait faible, vu que pour chaque message déposé, la fonction (le modèle) est sollicité une seule fois, au moment de sa substitution. Il est préférable de laisser ainsi une chose qui roule et à laquelle sont habitués les utilisateurs.
Vega, il convient de garder en mémoire que les inclusions reportées sur wstats.fr sont des utilisations, parfois anciennes, pour lesquelles, il aurait été préférable de voir le modèle substitué. Mais elles permettent de repérer des tendances ou utilisations incorrectes (ou obsolètes) des paramètres. Cela veut aussi dire que potentiellement, il y a plein d'autres pages où le modèle a pu être substitué avec un texte ne correspondant pas aux attentes.
Merci pour le lien vers le code de C-helper. Dans, MediaWiki:Gadget-C_helper_message.js, on trouve {category:1, display:'Test 0', template:'Test 0|$(page)|raison=$(extra)|user=$(user)', extra:'Type de maladresse (facultatif) :', help:''},. Si je comprends bien, il en est resté à une ancienne version du modèle « Test 0 » pour laquelle le paramètre « raison » était valide, comme le paramètre « user » (aujourd'hui inutile, remplacé par une détection automatique du poseur lors de la substitution). Du coup, je ne comprends pas immédiatement comment il permet l'entrée du motif (activation d'options préformatées), ni s'il permet d'entrer un lien vers la modification annulée. Je devrais tester ce gadget.
Voici un bon exemple de ce qu'il ne faut pas faire avec les modèles à "subster". Le but est que le concerné par le message ait un message en dur dans sa page, sans qu'il ait besoin de chercher d'où vient le message ni de comprendre l'usage des modèles sur Wikipédia. En plus, cela induit un autre problème. Si l'utilisateur Toto va sur la page donnée en exemple clique sur « Modifier le code », pour y faire une modification quelconque et enregistre la page, le lien « me contacter » ne sera plus un lien vers la page de discussion utilisateur du poseur initial mais vers celle de Toto. Cela est confirmé par cet exemple Discussion utilisateur:LE REAL BRO où le modèle a été posé par   Dfeldmann mais le lien dirige vers la pdd du dernier intervenant sur la page. D'où l'importance du subst: dans {{subst:Test0|…}} quand on pose le message en wikicode. Dans la doc de C-helper, il y a une image montrant une case à cocher. Pour information   Harrieta171 et JLM.
Bonjour Ideawipik  , merci pour ce travail. Je n’ai pas compris ce qu’il faut faire pour cocher la case mentionnée ci-dessus. Désolé d’être aussi crasse. Bien à vous.--Harrieta171 (discussion) 3 mai 2021 à 11:52 (CEST)[répondre]
Encourager la substitution. Je me demande s'il ne serait pas préférable que le texte du message soit automatiquement "substé", par défaut (dans tous les cas), même si le poseur oublie le « subst: ». (Note pense-bête, l'opération inverse consistant à empêcher la substitution – ou plutôt à se servir de la substitution pour convertir un appel {{subst:Modèle|…}} en texte {{Modèle|…}}) – est possible ; voir notamment du côté de Module:Unsubst.) Je n'ai pas trouvé de solution immédiate. En revanche, on peut mettre un message d'erreur lorsque le modèle est inclus au lieu de subir une substitution. Voir la proposition actualisée (Modèle:Test 0/Bac à sable).
Il reste juste une broutille à régler dans {{BMA début}} (passage à la ligne superflu lors de la substitution, on y remédie facilement mais il y a un choix à faire entre plusieurs techniques) Edit :   Fait.
Dans l'attente de vos réactions. — Ideawipik (discuter) 2 mai 2021 à 23:52 (CEST)[répondre]
Bonjour Ideawipik  , merci beaucoup du travail accompli, encore une fois. Je crains qu'une bonne partie de ton message ne dépasse mes compétences techniques, je n'ai donc pas grand chose à rajouter sur ce que tu expliques vis-à-vis des avertissements ou de C-helper.
Pour les paramètres, c'est un peu pareil : si tu indiques que c'est mieux de laisser ainsi, je te fais confiance.
Pour ce diff, je ne comprenais pas l'intérêt de substituer un message au moment où j'ai effectué la modif, ni les problèmes que ne pas le faire peut engendrer. Je tâcherai de faire attention, mais, du coup, je suis favorable — si c'est faisable techniquement — à ce que le modèle substitue le texte par défaut puisque ça permettrait d'éviter les problèmes que tu mentionnes : c'est plus pratique qu'un gros message d'erreur en rouge, et ça faciliterait probablement la vie aux patrouilleurs peu habitués.  
Deux autres remarques qui me viennent à l'esprit :
  • il faudrait, idéalement, que lorsque les modifications annulées sont plurielles, toute la phrase le prenne en compte. Dans cet exemple, la phrase n'est pas accordée correctement (« je vous remercie de vos modifications » mais « voir la modification » ; « j'ai dû les retirer » mais « elle contient », etc.) ;
  • j'ai l'impression que lorsqu'aucun champ de motif n'est rentré, le message censé indiquer que les raisons seront détaillées plus bas ne s'affiche pas (voir ici, à priori je n'ai pas fait d'erreur dans l'insertion du modèle). Par ailleurs, c'est un détail, mais tant que j'y suis, je pense que la phrase qui apparaît devrait plutôt être formulée ainsi : Cependant, j'ai dû la retirer et vais vous fournir des explications ci-dessous. vu qu'il est impératif que le patrouilleur fournisse des explications.
Merci encore ! Cordialement, — Bru [M'écrire] 3 mai 2021 à 09:05 (CEST)[répondre]
Bonjour
  Harrieta171. N'ayant pas testé C-Helper, je ne suis pas sûr mais imagine que la case est cochée par défaut ? On lit dans son code : « Substituer les modèles / Cette case doit rester cochée dans la plupart des cas. » Quelqu'un pourrait confirmer ? En wikicode, l'appel de ce modèle, comme celui de certains autres messages similaires, doit se faire en le substituant, selon la syntaxe donnée ci-dessous.
  Vega et Bru Water. « Que le modèle substitue le texte par défaut », ce serait l'idéal. Je n'ai pas trouvé la solution pour ce faire. Donc la syntaxe à adopter restera {{subst:Test 0|…}}. Il faudrait le mettre davantage en avant dans la documentation du modèle (fait avec le modèle {{modèle à subster}}) et sur l'aide aux patrouilleurs. Le message en rouge est conservé en cas de non-substitution mais le texte du modèle est également présent.
  • Menues corrections du texte. En ce qui concerne, les remarques sur le code, les phrases ont été légèrement revues pour éviter le passage entre le singulier et le pluriel. Est-ce que cela convient ? Le dernier problème était lié à un simple commentaire dans le code qui était invisible lors d'une inclusion (transclusion) mais affectait le test lors d'une substitution. Il est corrigé sur le Bac à sable. J'attends vos dernières remarques sur le contenu du texte avant de demander l'intervention d'un administrateur pour mettre à jour le code du modèle. Cela peut être réalisé indépendamment des retouches qui seraient utiles dans C-Helper. Les substitutions seront plus propres qu'actuellement.
  • Il y aussi la question des catégories, Je pense qu'on peut créer la « Catégorie:Page contenant un message d'avertissement qui devrait être substitué », elle sera alimentée par le modèle s'il est inclus sans substitution et ne se retrouvera jamais en dur dans le code des pdd utilisateur. En revanche,la « Catégorie:Page contenant un message « Test 0 » utilisé sans explication », envisagée un temps, aurait été écrite en dur sur la page où le modèle aurait été substitué si aucun des paramètres optionnels d'explication n'avait été activé au moment de la pose. Si le texte introductif de la "non-liste" est modifié en « Cependant, j'ai dû la retirer et vais vous fournir des explications ci-dessous. » et si les utilisateurs expliquent effectivement leur action, il me semble préférable d'abandonner l'idée de cette catégorie qui demanderait une édition supplémentaire de la page pour la retirer si le message est effectivement motivé sous le modèle. — Ideawipik (discuter) 6 mai 2021 à 17:46 (CEST)[répondre]
Bonsoir  ,
Pour C-helper, Harrieta171, la case est effectivement cochée par défaut lorsque le gadget est utilisé pour laisser un message sur une PDDU. Le champ, nommé « Substituer les modèles », se situe juste au dessus de la liste des messages apposables, et juste en dessous du champ permettant d'indiquer l'article où les modifications ont été révoquées.
  Ideawipik : pas de soucis pour la substitution, ça me convient. Pour les catégories, je te rejoins également : une qui répertorie les modèles non-substitués est utile, mais pas une qui répertorie les messages sans paramètre prédéfini tant que les patrouilleurs expliquent les raisons en dessous du message automatique — il est, par conséquent, important de bien expliquer dans la documentation du modèle que détailler les motifs du revert est capital.
Sur les phrases, c'est mieux ainsi, merci ! Un dernier cas qui me chiffonne est celui-ci, puisque le modèle parle d'une modification au singulier alors qu'il y en a plusieurs, mais si c'est trop compliqué à corriger, ce n'est pas très grave. Je me suis par ailleurs permis de modifier la phrase qui apparaît dans le cas où aucun paramètre prédéfini n'est rempli, j'espère ne pas avoir fait de bêtise  .
Hormis ça, tout me paraît bon, merci encore une fois de tout ton travail ! En l'absence de contre-indication future, tu peux introduire une DIPP quand tu le souhaites  .
Bonne soirée, — Bru [M'écrire] 7 mai 2021 à 02:23 (CEST)[répondre]
Bonjour Bru. Tu as bien fait de modifier le texte ; le brouillon ne m'appartient pas. Dans l'occurrence qui te chiffonne, La formulation est normale, selon moi. Cet appel est fait avec le paramètre pluriel=non qui force le singulier. Inversement pluriel=oui force le pluriel. Si tu fais le même appel sans ce paramètre optionnel, le pluriel sera mis automatiquement, en raison de la présence de article2 ou de diff2. Il est vrai que l'exemple n'est pas forcément idéal ni nécessaire dans la documentation. Dans le cas où un utilisateur fait exactement la même modification dans une série d'articles, cette formulation ne serait pas fausse, celle au pluriel non plus. Bref, c'est un détail et ce paramètre sera rarement utilisé mais a le mérite d'exister pour des exceptions.
OK pour la demande d'intervention. J'actualiserai dans la documentation, juste après. Ensuite, rien ne t'empêchera d'y faire les retouches nécessaires.
J'ai juste un peu de scrupules à alimenter une « Catégorie:Page contenant un message d'avertissement qui devrait être substitué » avec 12 000 pages (liste rien que pour Test 0).   FDo64, NicoV et Thibaut120094, qu'en pensez-vous ? Un bot devrait-il chercher les poseurs et substituer les modèles de ce type ? Inutile de lire toute la discussion, le problème réel est expliqué, un peu plus haut, ici et permet de comprendre pourquoi parfois des réactions sont adressées au mauvais destinataire. Et vous pouvez jeter un coup d’œil au brouillon de proposition récente à transférer (la partie initiale, avant la Documentation, seulement) dans le code du modèle {{Test 0}}. Merci. — Ideawipik (discuter) 7 mai 2021 à 14:56 (CEST)[répondre]
Re, Ideawipik,
Ça roule, pas de soucis pour la formulation, et, oui, je relirai la documentation avec plaisir. Pour la catégorie à alimenter ou pas, la question me dépasse sur le plan technique donc je laisse ma place aux utilisateurs compétents notifiés.
Cordialement, — Bru [M'écrire] 7 mai 2021 à 15:47 (CEST)[répondre]

Modèle:lang-ruModifier

Travail demandé par LD m'écrire 29 juin 2021 à 15:52 (CEST)[répondre]

Modules pour les populations des communes de FranceModifier

Travail demandé par LD m'écrire 29 juin 2021 à 16:08 (CEST)[répondre]

  • Avancement :
    0 %
  • Détails de la demande : Création d'un sous-module contenant la racine des adresses url les plus communes pour le projet : www.insee.fr/fr/information/ ; www.insee.fr/fr/statistiques ; cassini.ehess.fr/fr/html/ ; etc.
  • Pour tous les modules : notamment, catégorie:Module de données démographiques
  • Discussions :

L'idée serait d'appeler le sous-module en tête (comment  ) et ensuite de réaliser une inclusion, par ex. dans Module:Données/Boigny-sur-Bionne/évolution population, passer de http://cassini.ehess.fr/fr/html/fiche.php?select_resultat=2397 à 'sous-module' + '2397' Je ne connais pas Lua, j'aurais besoin de quelques précisions pour pouvoir ensuite passer sur tous mes modules concernés (pour les modifier avec mon bot), notamment : comment inclure un sous-module et l'inclure ; un exemple suffirait, je me chargerais ensuite du reste  , merci -LD m'écrire

Bonjour LD. Il y a déjà pas mal de choses dans Module:Population de France. En résumé, tu veux juste que les racines des sites soient stockées dans des "variables" à un seul endroit et ne conserver dans la base de données des communes que les identifiants numériques de celles-ci. Bonne idée ! Même s'il est possible de le faire, je doute qu'il soit nécessaire/productif d'appeler ce module (ces variables) dans tous les modules du type « Données/commune/évolution population ». Il serait peut-être plus pertinent de l'appeler uniquement dans les fonctions ("sur-modules") qui affichent les données, en l’occurrence les liens externes, dans les articles. Est-ce que les données seront stockées dans des champs « ID_Cassini », « ID_INSEE_info », « ID_INSEE_stats », etc. ? Est-ce que ces données pourront se substituer aux « source1 », « source2 », « source3 » ? Fonctionnement global à vérifier.   Roland45 ? PS: En réponse à la question technique, pour une utilisation locale, avec un nom : …=require("Module:…") (exemple et doc genérale).Ideawipik (discuter) 1 juillet 2021 à 19:53 (CEST)[répondre]
Bonjour Ideawipik  
Pour mémoire, tu avais préconisé cette solution lors de la RBOT associée ;
L'idéal serait de centraliser la racine, quelque part, et que ce soit modifiable en une correction pour tous les modules parce que le site continue de déplacer ses pages. Stricto sensu, seul Cassini-Ehess m'intéresse vraiment mais quite à créer un module-racine, autant ouvrir le champ des possibles aux autres formes de liens racines.
Pour le stockage des variables, je ne sais pas trop à vrai dire ; vu que je ne sais pas vraiment lire Lua, je peine à comprendre ce qui a déjà été fait (surtout que le dossier est relativement lourd et complexe pour un néophyte lua). Mais dans l'esprit, ce serait : ["source1"] = ["Module.RACINE-CASSINI"] + "2397", (bon le code doit pas s'écrire comme ça, mais en python ça donnerait source 1 = function(racine + "2397")) ;
Une autre possibilité envisageable serait que je contacte Cassini-Ehess pour essayer d'avoir une BDD SQL pour les associations, si ça peut aider à simplifier les modules...
Dans cet esprit de centralisation, j'ai mis à jour {{Cassini-Ehess}}, ainsi la plupart des liens sont déjà encodés et pour les notices communales, cela fonctionne par racine + id.
J'espère que cela t'éclaire un peu,
Question connexe : peut-on détecter les références par inclusions de modules (comparer les sources provenant du wikicode à celles des modules) ? Parce que la correction des liens brisés entraîne des doublons de références pas fameuses dans les cas où les modules sont appelés... LD m'écrire 1 juillet 2021 à 20:28 (CEST)[répondre]
Merci LD. Oui j'ai bien compris. Reformulation de ma première question.
  • Est-ce que vous voulez continuer à utiliser les "source1", "source2", "source3" ? S'ils sont tous de la même forme, autant passer à des paramètres précis et générer l'url un peu plus haut dans le module et pas dans la base de donnée pour laquelle le stockage de l'"identifiant" (2397 dans ton exemple) suffirait. Dans le cas contraire, il peut-être préférable de garder le mode de fonctionnement actuel. Je n'ai pas de vue d'ensemble.
  • Est-ce que quand un module « Module:Données/Commune/évolution population » est sollicité, le modèle associé à cette opération affiche toujours une référence (source1 et/ou 2 et/ou 3) ? C'est juste qu'il serait inutile de charger le sous-module, si son contenu (la/les racine(s) de l'url) n'est pas utilisé
Pour la question connexe. Je ne vois pas trop le rapport direct avec les liens brisés. Dis-moi si je comprends correctement. Veux-tu parler de ceci ? Un modèle M qui introduirait une référence <ref>BlaBla_CASSINI</ref> et cette référence serait aussi appelée, en dur dans le code de l'article <ref>BlaBla_CASSINIbis</ref> avec la même URL cible, éventuellement sous une forme légèrement différente, pour sourcer un autre point.
Je n'ai pas de réponse technique pour la vérification des url en doublon. Il faudrait travailler sur le code HTML final de l'article ou la liste des liens externes.   Orlodrim, qui génère une liste de liens externes sur les pages d'homonymie, aura peut-être une idée. Mais j'irais du côté des références nommées avec une nomenclature bien définie, propre au projet. Par exemple dans le cas de Cassini, le module/modèle pourrait générer une référence <ref name="CassiniEhess_2397">{{Cassini-Ehess|id=2397|…}}</ref>. Il conviendrait alors que les rédacteurs suivent la même forme/convention pour citer la source dans l'article. Le pseudo-doublon dans le wikicode ne serait à priori pas problématique puisque les deux références contiendraient le même contenu et le même identifiant. Dans ce cas, le logiciel groupe les références. C'est sur ce principe que fonctionne le modèle {{sfn}}. Et même si le modèle M était un jour retiré de l'article, la référence serait encore présente, en dur. Pour faciliter la chose, tu peux créer un modèle RefCassini-Ehess qui générerait la référence nommée. La seule petite difficulté peut survenir si les notes/références sont dans un "group" précis. Donc il conviendrait d'ajouter un paramètre "groupe" à RefCassini-Ehess, par rapport à ceux de Cassini-Ehess.
Là où les deux points se rejoignent : manipuler des « ID_Cassini », « ID_INSEE_info », « ID_INSEE_stats », plutôt que des "sourceN" permettrait de mettre cela en place plus facilement (sans avoir besoin d'ajouter des "sourceN_name" dans la base). Autre avantage : permettre d'avoir des références davantage conformes à la présentation des liens externes comme celles des modèles « Cassini-Ehess » ou « Lien web ». — Ideawipik (discuter) 1 juillet 2021 à 22:44 (CEST)[répondre]
Amha, on peut passer à des paramètres précis plutôt que conserver une BDD de variables, à confirmer par @Roland45 cela dit ;
Pour la question connexe, les sous-modules créent <ref name=Cassini>{{Cassini-Ehess|id=2397|…}}</ref> et depuis le wikicode via AWB, quand je transforme un lien brisé vers un modèle Cassini <ref>{{Cassini-Ehess|id=X|…}}</ref>; il m’est impossible de vérifier que l'id du lien brisé (transformé en modèle) correspond (ou non) à l'id de la réf. du modèle inclu ; sinon je réutiliserais <ref name=Cassini/> ; autrement dit, je crée (parfois) des doublons de références si je passe dans les pages contenant des liens brisés ET un modèle de ce groupe de modules ; en plus, j'ai vérifié, ces doublements de réfs. sont indétectables par WPCleaner, ce qui rend la gestion ultérieure entièrement manuelle ; donc pour j'évite de passer là où les modèles/modules sont inclus, mais tôt ou tard, je devrais privilégier la requête initiale (la réparation) plutôt que le rendu lui-même, sauf si je trouve une solution; car aussi, a contrario, il n'est pas concevable de mettre <ref name=Cassini/> à chaque fois puisque parfois, les liens brisés renvoient vers une source différente, cela détournerait la source d'adopter ce système. LD m'écrire 1 juillet 2021 à 23:16 (CEST)[répondre]
@LD. L'id utilisé par le module correspond bien à quelque chose : soit à (ou via) un paramètre du modèle M (celui qui sollicite le module) soit à une donnée liée à la page (titre, nom de commune, élément Wikidata). Question préliminaire : peut-il y avoir deux modèles M dans la même page (avec des id différents) ?
Remplacer une référence Cassini brisée par <ref name=Cassini/> ne me semble pas être une bonne idée, d'une part en raison de ta remarque sur la vérification nécessaire de X=2397 (Bien que ce soit faisable en utilisant la correspondance de la question du paragraphe précédent et si besoin allant lire le sous-module de donnée correspondant) et d'autre part dans l'éventualité d'un retrait du modèle M de la page ou l'arrêt de l'introduction du lien via ce modèle. C'est pourquoi, ma proposition de remplacer les liens erronés<ref>Texte actuel de la référence Cassini pour l'id X</ref> dans les articles par {{RefCassini-Ehess|id=X|…|groupe=…}} me semble préférable. 1) L'utilisateur n'aurait pas à se préoccuper des "name=" intégrés automatiquement au nouveau modèle. 2) On n'aurait pas les problèmes de doublon qu'engendreraient des références non nommées <ref>{{Cassini-Ehess|id=X|…}}</ref> ou pas assez précises (name="Cassini"). Important, en revanche, il faut s'assurer que le modèle M utilise la même mise en forme pour cette référence que le futur modèle {{RefCassini-Ehess}} (idéalement il devrait le solliciter dans son module) si on ne veut pas avoir d'erreurs « Références nommées définies plusieurs fois avec des contenus différents ».
Implémentation des modèles. J'ajoute tout de suite une question. Dans le lien actuel (référence) vers Cassini dans les pages de communes n’apparaît pas le nom de la commune, mais seulement le numéro (id). Si on garde cette particularité, cela nous arrange pour la suite. Dans le cas contraire, l'idéal serait soit a) de trouver un moyen d'obtenir ce nom à partir de l'id ce qui permettrait de s'affranchir du paramètre "titre" du modèle Cassini-Ehess, soit b) de définir un identifiant unique à partir des paramètres "id" et "titre" (cette deuxième option nécessitera de bonnes explications pour l'usager (dans le choix du "titre") et est moins bien pour la maintenance, en cas de changement du nom de la commune ayant un identifiant donné.
Ensuite, les seuls point délicats lors des remplacements sont :
  • la gestion des éventuels <ref name="Toto">Texte actuel de la référence Cassini pour l'id X</ref> associés à des rappels <ref name="Toto"/> (et variantes typo)
  • celle des <ref name=Cassini/> déjà présents, (si non définis en dur dans l'article)
  • le respect des groupes (ce point n'est pas très gênant puisque techniquement deux références dans deux groupes différents peuvent avoir le même "name").
  • la présence antérieure éventuelle dans l'article d'une référence nommée de la même façon que le nom retenu pour les modèles RefCassini-Ehess et M.
Maintenance : il y aura des doublons pendant la phase de transition.
Remarques finales :
  1. On est parti sur les id des url, ce qui est vraisemblablement le plus simple mais un autre identifiant unique relatif à la commune serait envisageable mais peut-être plus lourd.
  2. Simple curiosité. Y a-t-il une raison de ne pas se servir de la donnée Wikidata P8422 (« identifiant Ldh/EHESS/Cassini ») ?
PS : Venant de découvrir{{Cassini-Ehess/ancre}}, je te suggères d'introduire les identifiants des ancres (div id=…) directement dans le modèle Cassini-Ehess, avec par défaut un identifiant basé sur l'id Cassini, comme dans ma suggestion pour RefCassini-Ehess dont le code pourrait ressembler, avec l'éventualité b), à {{#tag:ref|{{Cassini-Ehess|id={{{id}}}|titre={{titre}}}}}|name={{#if:{{{name|}}}|{{{name}}}|Cassini-Ehess_{{#if:{{{id|}}}|{{{id}}}}}{{#if:{{{titre|}}}|{{{titre}}}}}|group={{{groupe|}}}}}, en faisant en sorte de ne pas avoir de nom défini plusieurs fois avec des contenus différents.
Ideawipik (discuter) 2 juillet 2021 à 14:43 (CEST)[répondre]
Salut Ideawipik  
Je vais tenter de répondre point par point  , n'hésite pas à me soliciter sur un point que je n'aurais pas suffisament détaillé :
  1. Dans une même page il peut y avoir deux modèles M, c'est parfois le cas dans les anciennes communes ou les communes avec plusieurs ID Cass selon son histoire ;
  2. Créer {{RefCassini-Ehess}} me paraît une bonne idée mais ne pourra pas non plus être utilisée dans 100% des cas, certaines références contiennent par exemple un commentaire du style « Contrairement à l'Insee, Cassini-Ehess ne dit rien sur le statut de la ville en 1870, la population (...) voir (la réf. Cassini) ». A moins de rajouter un paramètre commentaire et une position av./ap. pour déterminer son emplacement. Mais par conséquent, ça ne matcherait pas avec le module   donc {{Cassini-Ehess}} pourrait toujours être utile pour intégrer un commentaire. Du coup on partirait sur au moins deux modèles pour Cassini : l'un pour une référence basique : {{RefCassini-Ehess}} ; l'autre {{NoteCassini-Ehess}} (l'actuel {{Cassini-Ehess}}) et l'ancre : {{Cassini-Ehess/ancre}} ; sauf si tu vois une meilleure solution pour gérer les noms et leurs problèmes.
  3. Sur l'implentation, gardons ID Cassini, créer un ID est inutilement lourd, je partage ton avis : communes fusionnent régulièrement, il faudra une maintenance... tandis que les ID Cassini, ben ils s'en chargent eux-mêmes  
  4. Pour ta curiosité, P8422 (« identifiant Ldh/EHESS/Cassini ») est l'ID de la commune définie selon son statut "moderne" mais chaque page de commune peut regrouper plusieurs ID Cassini : les anciennes communes ou les communes qui ont fusionné sont de bons exemples, mais il y a également les pages de cantons regroupant un tas de communes où P8422 (« identifiant Ldh/EHESS/Cassini ») n'est pas envisageable. Et enfin, Cassini a des IDs différents pour les grandes villes selon leurs époques (le coeur historique, tel ou tel identité qui s'est fusionné, etc.). Donc, il faudra renseigner l'ID, cela laisse le choix à l'éditeur directement sur WP de renvoyer vers la bonne notice à chaque fois qu'il emploie une référence Cass.   pour le principe de vérifiabilité.
  5. Pour l'ancre, je suivrais ce conseil.
Bon ... quelle est la prochaine étape ?  
Merci de ta réponse LD m'écrire 7 juillet 2021 à 02:46 (CEST)[répondre]

Bonjour @LD et @Ideawipik . Je n'ai pas bien compris la conclusion de la proposition : il s'agirait de transférer l'id Cassini, actuellement dans le module de données, directement dans le corps de l'article, en tant que paramètre associé au modèle {{Cassini-Ehess}} ? Mais comment gère-t-on alors les doublons de ref avec le module:Population de France, que la racine de l'url soit à l'intérieur du code du module de traitement ou dans le module de données ?
La meilleure solution me parait être de modifier la fonction p.source_cassini dans Module:Population de France/Sources en mettant en dur la racine de l'url et ne garder dans le module de données en source1 que l'id Cassini, puis en cas de réutilisation de la ref dans le corps de l'article, on écrit <ref name=Cassini/>. Pour quelqu'un qui maîtrise le lua, cela me parait pas trop compliqué. On n'a pas besoin d'un quelconque sur-module.
Au fait, petite précision : « ... tandis que les ID Cassini, ben ils s'en chargent eux-mêmes ». Cela ne me parait pas exact. La base Cassini est une base historique et est figée dans le temps ... en 2006. Les communes nouvelles n'y sont pas. Et il n'y a eu aucune modif depuis cette date.
Maintenant on peut aussi faire passer un bot pour modifier l'url Cassini dans tous les modules de données. C'est encore plus simple. Ce n'est pas tous les jours qu'il y a un changement de racine d'url. De toutes façons en tout état de cause si on veut faire passer la racine de l'url dans le module de traitement, il faudra modifier tous les modules de données. Cordialement.Roland45 (discuter) 7 juillet 2021 à 10:09 (CEST) ┌─────────────────────────────────────────────────┘
[répondre]

@Roland45
Pour rappel, tu avais demandé en février de faire ceci.
Mais plutôt que de conserver une URL, j'ai proposé que de conserver l’ID dans les modules d'évolution de population et centraliser la racine quelque part. Et l'idéal serait même de nommer la référence des modules Cassini<numéroID> pour être certain que ça colle avec les modèles.
Il n'y a pas eu de mise à jour depuis 2006, mais il est probable qu'ils en refassent une. En tout cas, il est préférable qu'ils gèrent leurs IDs plutôt qu'on y travaille, à mon avis. LD m'écrire 7 juillet 2021 à 16:45 (CEST)[répondre]
@LD Oui. Je me rappelle bien de ma demande qui portait sur une modif de l'url dans tous les modules. Ce que je dis, c'est que si tu veux ne conserver que l'id dans le module de données, il faut simplement modifier la fonction p.source_cassini dans Module:Population de France/Sources en mettant en dur la racine de l'url. Mais dans tous les cas on doit faire un passage sur les 25000 modules de données, ainsi d'ailleurs que sur les modèles de données qui n'ont pas été transférés en modules.
Pour ce qui est de renommer le nom de la référence en Cassini<numéroId>, il faudrait aussi changer le module de traitement, mais par contre on ne sait pas si cette ref Cassini simplement, qui correspond à l'id de la commune, n'est pas utilisée par ailleurs. Je ne le préconise donc pas. Cordialement.Roland45 (discuter) 7 juillet 2021 à 19:04 (CEST)[répondre]
Oui, et quite à passer sur les modules, autant les retravailler en même temps. Mais mes compétences en Lua s'arrêtent à la réflexion globale, je vous laisse choisir l'optimum et j'appliquerais bêtement les modifications avec mon bot  
D'expérience sur plus de 2000 articles, il y a bien plus souvent un conflit entre deux références appelées "Cassini". L'association et la réflexion sur une mise en forme identique du texte des références (module / modèles) me semble une solution plus adéquate pour éviter les erreurs comme soulignées par Ideawipik.
--LD m'écrire 7 juillet 2021 à 19:12 (CEST)[répondre]
Bonjour   LD et Roland45
Présentation des articles. Avis personnel sur un point connexe : je ne vois pas trop l'intérêt de mettre la référence à Cassini dans une section dédiée comme illustré dans la documentation du nouveau modèle {{Cassini-Ehess/ancre}}.
  • … ou alors, il faudrait vérifier que le bas de page associé à la ref (ou note) soit sur toutes les pages qui contiennent le modèle {{Population de France/introduction}} (et peut-être les autres {{Population de France/…}}). Une sorte de fonctionnement par paire.
  • Cette présentation complexe n'est pas forcément à adaptée pour de simples ref/notes qui, à mon avis, n'ont pas à être mises en avant plus que cela.
C'est pourquoi, conserver de simples références (éventuellement dans un groupe "Notes"), comme c'est le cas actuellement, me semble préférable. Le seul problème qui puisse arriver est l'absence d'un {{Références|groupe=Note}} en fin de page, pour laquelle un message explicite apparaît dans l'article (recherche), avec une résolution relativement aisée.
Avez-vous un exemple de page qui porterait deux modèles {{Population de France/introduction}} (ou deux autres modèles du même acabit), en utilisant son paramètre nom (non documenté mais valide) ? C'était la question préliminaire de ma précédente intervention. Parce que sur ce genre de pages, un nom de référence unique name="Cassini" ne convient pas. Cela est illustré dans les notes avec messages d'erreur visibles sur Projet:Communes de France/Module démographique/Comparatifs. Wstat.fr donne très peu de cas d'utilisations du paramètre nom et aucun appel en double. Il faudrait vérifier la même chose pour les modèles …/tableau, …/graphique, etc. J'ai juste trouvé une balise "ref" nommée définie plusieurs fois avec des contenus différents pour le nom « Cassini » dans Mauzac-et-Grand-Castang, avec une définition locale dans l'article. Attention particulière pour les articles avec définition en dur, si on devait y ajouter un modèle « Population de France ».
Inversement, il ne semble pas y avoir de problème de référence non définie pour Cassini du type rappel <ref name="Cassini"/> sans définition, bien que le nombre de insource:/name\=\"?Cassini/ soit élevé.
Le règlement de la question des doublons dans les références passe par la nécessité d'avoir une cohérence (un rendu et un nom de référence identiques) dans le modèle « Population de France » et dans le modèle {{RefCassini-Ehess}} suggéré plus haut. Les name="Cassini_<numéroID (ou quelque chose d'autre de distinctif)>" sont requis pour faire un lien vers la page web Cassini d'une commune A dans l'article d'une commune B, ou plusieurs appels de {{RefCassini-Ehess}} dans une même page.
En partant du principe hypothétique que l'on n'a jamais deux appels du "modèle" « Population de France » sur une même page, il serait possible de conserver un simple name="Cassini" :
  • pour un appel sans paramètre de « Population de France ». L'idCassini étant alors celui défini dans le module de données associé (correspondance du titre) à l'article courant.
  • pour un appel de {{RefCassini-Ehess}}
    • soit sans paramètre.
    • soit avec un id (ou titre article, lire la suite) correspondant à celui de l'article courant (si ce dernier est associé à un module, avec id défini.
Explications. Vu que le(s) modèle(s) « Population de France » (et la base de sous-modules) fonctionnent à partir des titres des pages, il pourrait être intéressant de rendre possible l'utilisation de {{RefCassini-Ehess}} sans paramètre et {{RefCassini-Ehess|titre article=…}} au lieu de (ou comme alternative à) {{RefCassini-Ehess|id=…}}, le modèle sollicitant le sous-module existant. Idem éventuellement pour {{Cassini-Ehess}}. On garderait quand même le paramètre id valide pour les éventuelles localités sans article/module. Inconvénients de ce fonctionnement : 1. Code des modèles plus lourds avec passage en Lua, 2. Lors du renommage d'un article A et de son module, maintenance à faire dans les appels du modèle avec un paramètre titre article=A. Cependant, plus généralement, l'invalidité du paramètre titre article pourrait figurer dans une catégorie de maintenance, tout comme l'invalidité d'un appel sans module de données associé. Avantage : possibilité de mettre facilement dans le texte de la référence à la fois le nom de la commune et le bon lien externe, sans générer de problème d'unicité sur les "name" des ref.
Si j'ai bien lu les modules, l'adresse internet dans "source1" devrait toujours être une adresse vers le site Cassini, sauf en cas d'appel de module avec "division" = « commune en COM1 » (recherche, ce qui correspond à 35 cas – intitle:Données – dont 33 "source1=http://www.isee.nc" et deux autres liens web pour Miquelon et St Pierre). Si les autres adresses sont toutes sous la même forme (même racine), on peut effectivement, dans les modules de données remplacer le contenu des sources1 par les ID_Cassini (numéros dans les url) mais ne serait-il pas plus clair d'y définir une nouvelle entrée, avec, pour ce nombre, un nom explicite ? (N.B. pour la vérification il suffirait de se contenter des modules de données sans "division" ou avec une valeur différente de celles traitées à part dans la fonction p.sources des modules Module:Population de France/Sources et Module:Population/France.) La racine de l'url pourrait être définie en dur dans ces deux modules. @Zolo. À quoi sert le second ?
Notes au passage :
  • Pour une éventuelle utilisation des titres, il y a la particularité des modules Données/<numéroINSEE>/évolution population mais ceux-ci ne sont pas utilisés dans l'encyclopédie par le module qui affiche le lien "source1", sauf un exemple dans une documentation. Ils sont sollicité par « Population de France/dernière pop », …/dernière année, …/tableau, …/graphique.
  • Le lien externe sur "Calendrier départemental des recensements" établi dans le module:Population de France/Introductions est un lien mort. Faut-il le remplacer par https://www.insee.fr/fr/statistiques/fichier/2383265/Fichier_historique_2015_2021.xlsx ou autre chose ?
  • retrait contenu de la référence "Struct", à corriger peut-être ailleurs.
  • Exemple avec plusieurs références en double, c'est à dire avec des intitulés légèrement différents mais des url identiques : Démographie de Bordeaux-en-Gâtinais
  • @Roland,
    • Que contiennent les "source2" et "source3" des modules de données ? quels modèles les utilisent ?
    • Pourrais-tu préciser le « ainsi d'ailleurs que sur les modèles de données qui n'ont pas été transférés en modules » de ton dernier message. Est-ce que ce sont des insertions dans les articles pour lesquelles le contenu de la référence est définie en dur dans un paramètre de modèle ? ou bien des tableaux en dur, sans modèle ?
  • @LD. À la première lecture, je n'ai pas bien compris ce que serait {{NoteCassini-Ehess}}, la même chose qu'un {{RefCassini-Ehess|groupe=Note}}. Ou autre chose ? S'il s'agissait juste de renommer {{Cassini-Ehess}}, je n'en vois pas l'utilité, le « Note », n'étant pas très clair. Difficile choix du nom des modèles.
Ideawipik (discuter) 8 juillet 2021 à 21:50 (CEST)[répondre]

Modèle « Article » : paramètre accès urlModifier

Travail demandé par Ariel (discuter) 6 juillet 2021 à 08:19 (CEST)[répondre]

  • Avancement :
    91,54 %
  • Détails de la demande : Le modèle « Article » comporte depuis peu le paramètre accès url (valeurs autorisées : libre, inscription, limité et payant). Il faudrait que ce paramètre induise un affichage, non seulement quand le paramètre lire en ligne est renseigné, mais aussi quand c'est le cas du paramètre doi. Le doi est en effet définitif alors que l'url peut changer (réorganisation du site web du périodique, à la suite d'une fusion, d'une scission, d'un rachat ou même d'un simple problème technique) : quand le doi existe il est déconseillé de mettre aussi l'url (qui au mieux fait doublon, au pire devient fausse).
  • Article(s) pour le modèle : Tous articles de sciences (inhumaines aussi bien que molles)
  • Discussions :
Bonjour Ariel. Ce point (WP:Accès url) concerne tant le modèle article « Article » que « Ouvrage », « Chapitre », « Lien web » (j'en oublie peut-être) qui passent tous par le module:Biblio.
Voici d'autres questions :
  1. Faut-il décliner le paramètre "accès url", en fonction des catalogues ou bibliothèques, afin que le cadenas informatif soit placé à côté du lien concerné ? Lire aussi Discussion modèle:Ouvrage#Accès URL. On est d'accord que le DOI est un élément un peu à part. Il faudra éviter les guirlandes de cadenas.
  2. Faut-il ajouter une gestion des "accès url" dans le modèle {{Lire en ligne}} ? dans le modèle {{Bibliographie}} ?
Ideawipik (discuter) 6 juillet 2021 à 09:57 (CEST)[répondre]
Tu as raison, j'oubliais que les ouvrages et même les liens web pouvaient aussi avoir un doi. Je pense que le cadenas doit être affiché dès que l'un au moins des paramètres lire en ligne et doi est renseigné. Le cadenas peut être différent pour le doi et pour le lien direct (qui peut être sur le site d'une université, par exemple) donc il faudrait un cadenas pour chacun des deux paramètres (et donc des tests indépendants). La redondance devrait être évitée parce qu'on ne devrait jamais renseigner le paramètre lire en ligne quand il renvoie à la même adresse que le doi (et peut devenir obsolète), il faudrait à mon sens rajouter cette recommandation aux docs.
Quant au modèle Lire en ligne, dont j'ignorais l'existence, oui, il faudrait lui ajouter le paramètre accès url. — Ariel (discuter) 6 juillet 2021 à 10:38 (CEST)[répondre]
Bonjour Ariel. Pour information, aux lecteurs de cette section, des paramètres « accès doi » et « accès hdl », associés respectivement aux « doi » et « hdl », ont été ajoutés aux modèles bibliographiques comme Article, Ouvrage, Chapitre ou Lien web. Les documentations sont encore incomplètes.
Le second point reste à faire. C'est peut-être l'occasion de passer {{Lire en ligne}} en Lua. Il existe déjà des fonctions Biblio.enLigne dans Module:Biblio/Références et References.enLigne dans Module:Biblio/Références qui pourraient servir. — Ideawipik (discuter) 31 mars 2022 à 23:47 (CEST)[répondre]
Bonjour Ariel Provost et Ideawipik, j'ai complété les documentations (voir Utilisateur:Vega/Brouillon2), avec quelques réserves :
  • j'ai ajouté la ligne <code id="doi accès">accès doi</code> et la suivante à {{Lien web}}, à vérifier svp ;
  • si tout est correct, je compléterai le template data et la doc sur {{Lire en ligne}} et sur {{Chapitre}} (où il manque « hdl »).
J'ai aussi ajouté une mention à {{Lien web}} et {{Article}} à propos de la redondance URL/DOI ; si elle vous convient, je compléterai de même Chapitre et Ouvrage.
En passant, ce ne serait pas l'occasion d'uniformiser "résumé" et "présentation en ligne" entre Article et Chapitre/Ouvrage respectivement, qui y sont inversement des alias ? — Vega (discuter) 23 juin 2022 à 19:50 (CEST)[répondre]

Réf Bible : auteur=RabbinatModifier

Travail demandé par — Valp 1 octobre 2021 à 15:14 (CEST)[répondre]

Bonjour Valp. Le modèle pourrait utiliser le modèle {{Ouvrage}} ou {{Lien web}}.
Veux-tu un modèle avec des paramètres {{Réf Bible Rabbinat|livre=|paracha=|chapitre=|verset=}}. « paracha » serait facultatif, utilisé seulement pour le libellé du lien/titre, pas pour l'adresse internet.
Faut-il prendre en compte aussi la « collection » (Pentateuque, Prophètes, Hagiographes) ? Pour le passage donné en exemple, en plus des deux adresses valides données ci-dessus, on a aussi la suivante : « https://www.sefarim.fr/Pentateuque_Genèse_10_8.aspx ». Quel est le format le plus universel ?
Note technique, il faudra dans le modèle penser à remplacer les espaces éventuels par des %20 (utile par exemple pour « Rois 2 », module String).Ideawipik (discuter) 1 octobre 2021 à 19:37 (CEST)[répondre]
Bonjour Ideawipik   et merci de votre réponse.
Je crois que le mieux serait un modèle comme les autres (ici) : {{Réf Bible|livre|chapitre|verset|auteur=Rabbinat}}.
Renvoyant à www.sefarim.fr OU à Wikisource Bible du Rabbinat.
Cordialement — Valp 2 octobre 2021 à 16:24 (CEST)[répondre]
Rebonjour Ideawipik
STOP ce modèle existe ! Mais il n'est pas documenté là où il faut ! Voyez par exemple {{Réf Bible|Josué|10|35|auteur=Rabbinat}}=Js 10,35
Valp 2 octobre 2021 à 18:01 (CEST)[répondre]
Bonjour Valp. Oups, ma faute. J'aurais dû lire tous les liens. Merci pour les précisions et l'ajout à la documentation. {{Réf Bible|Genèse|10|8|auteur=Rabbinat}} (Gn 10,8) correspond à ton exemple initial. Cela convient-il ? S'il manque des livres, dans le modèle, il est possible de les paramétrer dans {{Livre de la Bible sur Wikisource}}. On abandonne l'idée d'utiliser www.sefarim.fr ? Est-ce que Wikisource est suffisant et exhaustif ? Cordialement. — Ideawipik (discuter) 2 octobre 2021 à 18:33 (CEST)[répondre]
Bonsoir Ideawipik,
Wikisource paraît complet et correct pour ce que j'en ai vu. Par contre le paramètre extra-long de |display= du modèle {{Réf Bible |auteur=Rabbinat}} ne fonctionne pas.
Quant à Sepharim, c'est une très belle édition électronique, bilingue, et {{Réf Bible |auteur=Sepharim}} ferait un beau modèle, à mon avis.
Par curiosité, pourriez-vous me montrer comme un modèle comme {{Réf Bible}} est codé ?
Cordialement — Valp 2 octobre 2021 à 21:06 (CEST)[répondre]
Bonsoir Valp. Réponse apportée sur votre page de discussion. Faites juste savoir si un modèle dédié, hors de {{Réf Bible}}, par exemple {{Réf Sepharim}} ou {{Réf Bible Sepharim}} serait utile pour des liens externes vers le site.
Dans {{Réf Bible}}, avec le paramètre display à la valeur « extra-long », l'url était bonne mais le libellé affiché était toujours identique à celui généré pour auteur=Segond, quel que soit l'auteur. Le plus simple, à court terme, est d'ajouter un paramètre « auteur » au modèle {{Livre de la Bible}} et de rendre Rabbinat mais aussi Darby et Crampon valides dans {{Livre de la Bible sur Wikisource}} ce qui est déjà le cas pour beaucoup de livres (tous ?) ex. : {{Livre de la Bible sur Wikisource|Gn|auteur=Rabbinat}} (Bible du Rabbinat 1899/La Genèse) fonctionne déjà. La modification effectuée requiert une exhaustivité des livres pour chaque auteur dans ce dernier ou le passage à un autre fonctionnement*. Cependant, si la modification faisait apparaître un problème d'affichage quelque part, cela correspondrait à un appel pour lequel le lien généré était déjà invalide.
Exemple d'application, après la modification : {{Réf Bible|Genèse|10|8|auteur=Rabbinat|display=extra-long}} (Bible du Rabbinat 1899/La Genèse 10,8). N'hésitez pas à tester.
Note *. Je n'y ai pas touché mais le titre "extra-long" pour le modèle {{Livre de la Bible}} doit-il être par exemple « Bible Segond 1910/Évangile selon Jean » (rendu actuel) ou simplement « Évangile selon Jean ». En faisant sortir l'auteur du titre "extra-long", on pourrait ajouter son nom directement dans le libelle du lien depuis le modèle principal et ainsi simplifier légèrement le modèle {{Livre de la Bible}}. Mais cela reste un détail.
On peut aussi s'étonner des disparités sur wikisource, dans la formation des titres utilisés pour la version "extra-longue", auteur parfois au début, parfois à la fin, séparateur tantôt « / », tantôt « - ».Ideawipik (discuter) 3 octobre 2021 à 20:34 (CEST)[répondre]
Bonsoir Ideawipik.
Merci pour le display=extra-long "Bible du Rabbinat 1899/La Genèse 2,3". Je l'ai documenté dans Réf Bible. J'aurais préféré "Bible du Rabbinat 1899, Genèse 2,3", avec virgule plutôt que barre, et sans l'article défini devant le nom du livre, article superfétatoire et non standard, mais c'est quand même bien. J'ai répondu sur l'autre page de discussion. Cordialement — Valp 3 octobre 2021 à 22:03 (CEST)[répondre]

Langue d'une devise dans Module:Infobox/LocalitéModifier

Travail demandé par J. N. Squire (discuter) 16 février 2022 à 01:06 (CET)[répondre]

  • Avancement :
    0 %
  • Détails de la demande : Bonjour, Je viens de me rendre compte que, dans les cas où la devise de la localité n'est pas en français, l'{{Infobox Localité}} n'affiche pas le code de langue, ni ne met le texte en italique, ni ne propose d'afficher une traduction issue de l'élément Wikidata (parenthèses ?). Voici à quoi cela ressemble en formatage pour les États-Unis ({{Infobox Pays}}). Quelqu'un pourrait-il corriger cela dans le module Lua s'il-vous-plait ? Merci d'avance.
  • Article(s) pour le modèle : Coutts (Alberta) (par exemple)
  • Discussions : Personne ? J. N. Squire (discuter) 24 février 2022 à 20:23 (CET)[répondre]

Bug dans le modèle {{Stations voisines}}Modifier

Travail demandé par Bouzinac (discuter) 10 mars 2022 à 13:12 (CET)[répondre]

  • Avancement :
    0 %
  • Détails de la demande : Cf Modèle:Stations_voisines/Documentation#Bugs_connus_à_résoudre : il se peut parfois qu'une station de métro ne soit desservie que dans un seul sens. Exemple de Gulleråsen, cf cette carte. Je ne sais trop comment prendre le problème, s'il faut affiner côté Wikidata ou ajouter une règle de gestion dans le lua du module associé au modèle (ou probablement un peu des deux). Actuellement le modèle part de deux postulats : soit la station est un terminus, soit elle est entre deux stations. Merci pour vos idées !
  • Article(s) pour le modèle : Gulleråsen (métro d'Oslo)
  • Discussions :

Plaques d’immatriculation européennesModifier

Travail demandé par Louloumra59 (discuter) 3 avril 2022 à 00:33 (CEST)[répondre]

  • Avancement :
    0 %
  • Détails de la demande : Créer un modèle avec la partie gauche des plaques d’immatriculation européennes (ex : drapeau européen 🇪🇺 + F) pour remplacer actuellement la simple lettre présente dans les infobox et rendre cette section plus parlante
  • Article(s) pour le modèle : ...; ...; ...
  • Discussions :

Modification du modèle « Température »Modifier

Travail demandé par Ariel (discuter) 3 mai 2022 à 09:47 (CEST)[répondre]

  • Avancement :
    0 %
  • Détails de la demande : Actuellement le modèle « Température » (1) accepte différents symboles d'unité, (2) affiche la température en °C, et (3) montre par survol de la souris sur le ou les nombre(s) la valeur correspondante en °F et K. Je formule deux demandes distinctes mais cohérentes consistant à modifier le point no 2 optionnellement et le point no 3 systématiquement.
    • Affichage de la température (point no 2) : il faudrait ajouter au modèle un paramètre optionnel permettant de garder à l'affichage le symbole d'unité utilisé dans l'appel au modèle (et donc de ne pas effectuer la conversion en °C). Ce serait utile pour les kelvins dans un contexte thermodynamique (notamment lors de l'usage de nombres ronds ou de très basses températures comme 300 K et 2,3 K (le modèle « Unité » n'offrant pas la conversion — souvent utile — par survol de la souris) et pour les autres unités dans un contexte géographique (°F) ou historique (°Réetc.).
    • Survol de la souris (point no 3) : en cohérence avec la demande précédente, il faudrait afficher systématiquement la température dans les unités actuellement en usage dans la francophonie (°C, °F et K) s'il est bien vrai que les Canadiens francophones utilisent parfois les degrés Fahrenheit (seulement °C et K dans le cas contraire). On peut trouver bizarre d'éventuellement inclure la valeur qui s'affiche mais ce n'est pas très grave, et ce serait trop compliqué de demander au modèle de modifier l'effet du survol en fonction de ce qui est demandé pour l'affichage.
  • Article(s) pour le modèle : (innombrables)
  • Discussions :

Modèle:OuvrageModifier

Travail demandé par J. N. Squire (discuter) 12 juin 2022 à 15:37 (CEST)[répondre]

Bonjour,

Actuellement, seul le titre peut être traduit en français. Serait-il possible d'ajouter au modèle les paramètres manquants ("traduction sous-titre", "traduction titre volume", "traduction titre collection", "traduction titre série", "traduction titre chapitre") s'il-vous-plait ?

Merci d'avance.

❌ Idées 💡 politiques suiviesModifier

Travail demandé par Glush (Dev)

  • Avancement : requête sans objet puisqu'un modèle existe déjà.
  • Détails de la demande : Encadré (pour le profil) avec le logo RN et un texte comme quoi je soutiens leurs idées
  • Article(s) pour le modèle : Rassemblement National; ...; ...
  • Discussions :
    Bonjour Glush (Dev). Tu peux, par exemple, coller sur ta page le code suivant :
    {{BUdébut}}
    {{Utilisateur Rassemblement National}}
    {{BUfin}}
    
    Pour plus de détails, Aide:Boîte Utilisateur. Mais n'oublions pas que Wikipédia n'est pas un lieu fait pour exprimer ses propres idées politiques ou d'autres natures, ni un réseau social, mais un espace lié à la connaissance : une encyclopédie collaborative. Il n'est donc pas forcément pertinent d'y étaler ce type d'opinions personnelles. — Ideawipik (discuter) 21 juin 2022 à 05:16 (CEST)[répondre]