Discussion Projet:Scribunto/Archive 6

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Portail de qualité
  • Bon portail
  • Lumière sur
  • À faire
  • Archives
  • Commons

Une fonction nouvelle pour les compositions de divisions françaises[modifier le code]

Bonjour à tous

Le système d'information territorial développé pour les divisions françaises utilise des modules de données de population des divisions (actualisés chaque année) et deux modules de traitement ː

Ce dernier utilise des tables stockées sur Commons ː

Pour introduire certains tableaux, il nous serait utile de pouvoir créer la phrase suivante (exemple pour un département) :

 « Au {{Date-|1er|janvier|[2018]}}, le département comptait [326] communes. »

Il s'agirait

  • soit de créer un module spécifique (pour cette petite phrase) qui récupère la variable nbcom associée à la division concernée (définie par son code Insee) dans une des tables de divisions stockées sur Commons (l'année n'est par contre pas en variable, mais figure dans le texte introductif)
  • soit d'ajouter une fonction spécifique à {{Module:Composition Division de France}} (ce qui serait a priori plus court) pour faire la même tâche.

Mes connaissances en lua sont insuffisantes pour écrire un code optimisé qui fonctionne. Y aurait-il un candidat pour nous aider en la matière. Merci par avance. Cordialement.Roland45 (discuter) 7 janvier 2019 à 09:56 (CET)

Statistiques de clientèle/fréquentation[modifier le code]

Le bonjour au projet! Sur les bons conseils de VIGNERON (d · c · b) et de Trappist the monk (d · c · b), j'aimerais vous indiquer un besoin de présentation mis en forme de statistiques issues de Wikidata sur propriété clientèle/passagers (d). Pour ne pas disperser, je vous indique le lien du besoin : https://fr.wikipedia.org/wiki/Projet:Mod%C3%A8le/Demandes#Bo%C3%AEte_statistiques_issues_de_Wikidata. Merci encore ! --Bouzinac (discuter) 17 janvier 2019 à 15:40 (CET)

Bonjour

J'ai remarqué que ni {{Ouvrage}} ni {{Chapitre}} n'indiquent la langue du titre de l'ouvrage (et éventuellement du chapitre) alors que {{Article}} et {{Lien Web}} le fait.

Serait-il possible de modifier le module:Biblio dans ce sens ? Je ne peux pas le faire, les pages étant protégées.

Merci de répondre sur la PdD du module où j'ai également mis ce message pour faciliter la conversation.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 17 février 2019 à 17:34 (CET)

Module:Biblio - éditeurs multiples[modifier le code]

Serait-il possible de permettre de donner plus d’un éditeur dans les modèles utilisant Module:Biblio ? Pour l’instant seul l’argument éditeur est permis, mais éditeur1, éditeur2, etc. et lieu1, éditeur2, etc. seraient utiles. --Moyogo/ (discuter) 21 avril 2019 à 08:53 (CEST)

Communes nouvelles : Module:Données/[modifier le code]

Hello!

J'ai voulu juste modifier le code commune de Val-de-Scie sur la page de la Communauté de communes Terroir de Caux et je me suis lamentablement planté... Le module pour le code commune me semble marchait à peu près (pas le nom de la commune mais le code à la place), mais pour la population je m'avoue vaincu.. Je suis vraiment désolé, je voulais participer et patatra.. Peut-être que c'est trop récent, mais je sais pas si je peux supprimer le modèle que j'ai créé. --John.john.59 (discuter) 20 février 2019 à 23:21 (CET)

Bonjour à tous et à @John.john.59. Sur le plan du code, le module est correct. Par contre il y a des pb de fond et de contenu, qui sortent du champ du projet Scribunto.
  • Sur le fond : les populations légales millésimées 2016 entrant en vigueur le ont été calculées par l'Insee dans les limites territoriales en vigueur au . Cela signifie que les communes nouvelles créées au , ce qui est le cas de Val-de-Scie, n'ont formellement pas encore de données de population. Si des modules sont créés, ils doivent l'être par addition des populations de chacune des communes fusionnées. Mais ceci est source d'erreurs et surtout aucune source ne permet de valider la donnée affichée.
  • Sur le contenu 2 : pour la même raison que ci-dessus, on ne peut pas affirmer que le premier recensement pour cette commune nouvelle était 2015 puisqu'elle ... a été créée en 2019! Il faut attendre d'avoir le prochain calendrier (en 2020) pour savoir quelle première année est retenue par l'Insee.
Ainsi il n'y a aucun intérêt à vouloir à tout prix courir après une actualisation manuelle au jour le jour qui est impossible à réaliser vu le nombre colossal de données et de changements et est source d'erreurs. Un tableau avec une introduction du type « au 1er janvier 2018, la composition de l'intercommunalité XXX était la suivante. Depuis cette date les communes A et B ont fusionnés pour donner la commune nouvelle C » suffit largement. Un robot actualisera ensuite quand les données sont publiées. Certes le tableau comporte pendant quelques mois des communes qui ont fusionné entre le 1er janvier 2018 et le 1er janvier 2019. Mais cela ne pose aucun pb dès lors qu'on a une phrase introductrice au tableau qui explique la situation. Cordialement.Roland45 (discuter) 21 février 2019 à 09:34 (CET)
Ok merci pour ces infos. J'ai regardé sur la page de la CC Terroir de Caux et cela donne bien finalement! Pour le recensement j'ai mis 2015 juste pour mettre quelque chose, je crois que c'était comme cela sur une autre commune nouvelle. --John.john.59 (discuter) 22 février 2019 à 01:04 (CET)

Importation foireuse d'un modèle sur Wikiversité[modifier le code]

Bonjour, cette nuit, alors que j'aurais bien fait de me coucher tôt, j'ai commis l'erreur de cocher la case « inclure tous les modèles » durant l'importation d'un modèle de Wikipédia sur Wikiversité. Ben oui, ça arrive ... La plupart des modèles importés à la volée affichent ce message d’erreur : « Erreur de script : la fonction « documentation » n’existe pas. ». Je présume que c'est un message en relation à un script géré par Lua voir l'extention Scribunto, mais je ne me suis pas encore formé à ce niveau. Du coup, je viens déposer ce message dans la cour des grands pour voir si il serait possible de recevoir de l'aide. Voici pour exemple la page modèle Documentation et puis ce lien vers la page catégorie erreurs de script. Bien à vous tous, Lionel Scheepmans Contact Désolé pour ma dysorthographie, dyslexie et "dys"traction. 6 mars 2019 à 17:33 (CET)

Bonjour, ce module appelé par le Modèle:Wikidata pose plusieurs problèmes bloquants. Comme les deux développeurs de ce module ne sont plus actifs, quelqu'un pourrait-il se charger de les corriger ?

Pour rappel, la syntaxe du modèle est la suivante :

{{Wikidata| propriété | valeur à afficher }}

Il s'agit d'effectuer les modifications suivantes :

  1. <bug> à la demande de Notification Zolo au Projet:Infobox j'ai cherché à ajouter le paramètre propriété au Modèle:Infobox/Image. Le principe est le suivant : ce modèle doit pouvoir accepter soit une propriété (par exemple, P18), soit le nom d'un fichier. Dit autrement, il doit être possible d'avoir le paramètre propriété vide. C'est possible pour le nom du fichier. Par exemple, {{Wikidata|entity=Q33959| | defaut.svg}} donne « defaut.svg ». Par contre, ça ne fonctionne pas pour la récupération du libellé. {{Wikidata|entity=Q33959| | |showonlyqualifier=P2096|numval=1|lang=fr}} donne « Échec à la sérialisation des données ».
  2. <évolution> ajouter la possibilité d'avoir une valeur par défaut. Par exemple, {{Wikidata| | |défaut=defaut.svg}} donnerait « defaut.svg ».
  3. <bug> ne fonctionne pas lorsqu'on met un formatnum. Par exemple, {{formatnum:{{Wikidata|entity=Q504998| P1616 | {{{SIREN|}}} |showsource = true|linkback=true |numval=1}} }}. Il faudrait donc ajouter au module cette possibilité.

Je reste à votre disposition pour toute question. Merci. --FDo64 (discuter) 15 mars 2019 à 12:38 (CET)

Bonjour,
  1. Il manque en fait l'identifiant de la propriété à utiliser : {{Wikidata|entity=Q33959| property = P18}}-> Port Of Nice, Côte d'Azur.jpg. Il y a par contre des problèmes dans la gestion des erreurs, on devrait plutôt avoir un message : "paramètre property manquant".
  2. Il s'agit du paramètre value normalement.
  3. Dans ton exemple on essaye de formatnumer non pas un simple nombre, mais un chaîne qui contient un nomnre, un "linback" vers Wikidata et éventuellement une source. Il faudrait faire la mise en forme plus en amont, sur la valeur numérique brute avant ajout de la source et du linkback. Sur le principe, ça devrait être quelque chose comme {{Wikidata|entity=Q504998| P1616 | {{{SIREN|}}} |showsource = true|linkback=true |numval=1|displayformat=indiquer le format ici }}. Les données numériques sont formatées comme des nombres par défaut, mais la proriété Wikidata numéro SIREN (d) est de type "chaîne" et pas "nombre", donc ça ne marche pas. Il est possible de mettre transmettre au paramètre "displayformat" une fonction Lua qui définit une mise en forme. Mais ça me parait assez compliqué de faire l'équivalent depuis un modèle en Wikitexte. (je sais pas si c'est très clair :]). --Zolo (discuter) 18 avril 2019 à 22:17 (CEST)
Bonsoir Zolo Émoticône heureux de te revoir et merci de tes réponses !
  1. Ce que je cherche à faire, c'est de n'avoir qu'une seule brique d'Infobox et donc que {{Infobox/Image}} fonctionne même si aucune propriété n'est renseignée. Dit autrement, je souhaite avoir la syntaxe suivante : {{Wikidata|{{{propriété|}}}|{{{image|}}}}}, avec les paramètre 'propriété' et/ou 'image' vides. Comme je l'indiquais, le modèle {{Wikidata}} réagit bien sauf si on lui précise un showonlyqualifier pour aller chercher le libellé.
  2. Je ne crois pas que le paramètre value réponde à ma demande. Si je mets {{Wikidata|{{{propriété|}}}|{{{image|}}}|value=defaut.svg}}, je pense qu'il retournera defaut.svg dans tous les cas. C'est pour cela que je suggère un nouveau paramètre.
  3. C'est vrai que malheureusement le SIREN est de type "chaîne" et pas "nombre", et je ne pense pas qu'on puisse le changer. C'est pour cela que je souhaiterais que l'on puisse indiquer, par exemple, |displayformat=number.
--FDo64 (discuter) 18 avril 2019 à 23:23 (CEST)
FDo64 effectivememédiaire "interface" ne devrait plus être nécessaire. Si on pouvait le supprimer ça rendrait les choses un peu plus claires. nt j'ai lu un peu vite. Je me demande s'il ne faudrait pas essayer de gérer l'intéraction données de Wikidata / données locales hors de modules dédiés à Wikidata. J'essaye de voir si j'arrive à faire quelque chose ce week end. -Zolo (discuter) 23 avril 2019 à 22:18 (CEST)
@FDo64 en y repensant une solution aux problèmes 1 et 2 serait je crois de remplacer le code de {{Wikidata}} par le suivant :
{{#if : {{{property|{{{1|}}}}}}} | {{safesubst:#invoke:Wikidata|frameFun|formatStatements|property={{{property|{{{1|}}}}}}|value={{{value|{{{2|}}}}}}}} | {{{value|{{{2|{{{default}}} }}} }}} }}
  • Inconvénients : complique un peu le modèle est augment la différence entre le comportement du modèle et un appel direct à Module:Wikidata.formatStatements.
  • Avantages : devrait régler les problèmes sans complexifier encore Module:Wikidata avec des questions qui ne concernent non pas l'utilisation des données de Wikidata, mais leur relation avec les données locales. Au passage, je remplaçerais #invoke:Interface Wikidata par #invoke:Wikidata. On devrait pouvoir se débarasser du module d'interface pour enlever une couche de complexité.
Pour le point 3, je ne sais pas trop quoi faire. S'il y a suffisamment de besoins, on peut effectivement ajouter dans le module un displayformat = number, ou peut-être |displayformat = chaînequelquongue qu'on enverrait à #mw.ustring.gsub. Sinon, on peut aussi faire des mini-modules dédiés au fil des besoins. -Zolo (discuter) 27 avril 2019 à 15:15 (CEST)
Notification Zolo : Bonsoir, j’avoue ne pas comprendre ta proposition. Sans doute à cause de ma totale ignorance du fonctionnement interne des modules. J’ai peur d’être obligé de faire ce que je cherchais à éviter : créer une nouvelle brique d’Infobox V2 rien que pour l’accès à Wikidata.
Pour ce qui est du displayformat=number, si c’est si compliqué de faire un formatnum en Lua, le numéro de SIREN va rester tel quel, sans mise en forme (Smiley: triste).
Merci d’avoir cherché. --FDo64 (discuter) 3 mai 2019 à 23:28 (CEST)
Notification FDo64 :, bonjour, en fait ma proposition était de modifier le modèle {{Wikidata}} et de ne pas toucher directement aux modules. Mais je viens de me rendre compte, qu'on pouvait tout simplement changer la ligne 1501 de Module:Wikidata de return nil en return args.default. Ca ajoute encore un argument possible à une fonction qui en a déjà beaucoup, mais ça devrait marcher. Je proposais au passage de changer légèrement le modèle {{Wikidata}} afin d'utiliser directement Module:Wikidata, et non plus Module:Interface Wikidata, dont on devrait pouvoir se débarasser.
Pour le formatnum, ça ne devrait pas être très compliqué, mais si on ajoute une option pour tout les formats potentiellement utiles, ça risque d'être un peu délicat à gérer, ou alors il faudrait un peu structurer ça. Sinon, pour faire fonctionner ponctuellement le formatnum, on peut aussi renoncer au linkback et au addcat : {{formatnum:{{#invoke:Wikidata|frameFun|formatStatements|entity=Q504998|property= P1616 |value= {{{SIREN|}}} |numval=1}} }} ->775 670 417.--Zolo (discuter) 9 mai 2019 à 10:22 (CEST)
@FDo64 j'ai ajouté le paramètre "défaut" à retourner quand on a rien d'autre [1]. -Zolo (discuter) 11 mai 2019 à 13:25 (CEST)

Edge et console de débogage Lua[modifier le code]

Bonjour, je suis actuellement sur une machine où j'ai à utiliser le navigateur Edge, et quand je teste du code dans la console de débogage qui figure en bas des pages de modification pour les Modules, je rencontre un problème franchement gênant : quand j'appuie sur Entrée pour exécuter le code, cela fonctionne, mais cela déclenche aussi la soumission du formulaire de modification… J'utilise habituellement d'autre navigateurs, et je n'avais jamais rencontré ce problème auparavant. Le problème est-il déjà connu ? Quelqu'un aurait plus d'infos à ce sujet ? od†n ↗blah 22 avril 2019 à 13:12 (CEST)

modèle:prononciation dans une infobox[modifier le code]

Atmavrittanta
Titre original
(gu) આત્મવૃત્તાંતVoir et modifier les données sur Wikidata
Langue
Auteur
Manilal Nabhubhai Dvivedi (en)Voir et modifier les données sur Wikidata
Genre
Date de parution
Pays
Éditeur
Dhirubhai Thaker (en)Voir et modifier les données sur Wikidata

Bonjour,

J'aimerais ajouter un affichage semblable à {{prononciation}} dans le champ « nom officiel » de {{Infobox Ouvrage}}, comme par exemple pour l'élément [[:d:Q54818533|Q54818533 (« Atmavrittanta »)]], dont P443 (« prononciation (fichier son) ») est renseigné.
Quelqu'un peut m'aider svp ? - Simon Villeneuve 7 mai 2019 à 20:45 (CEST)

Bonjour à tous. Le module:Composition Division de France permet de produire la composition de toute division française dès lors que les tables annexes (qui sont stockées sur Commons) sont actualisées (exemple avec la liste des communes de la Lozère).

Dans la table des départements, il y a une colonne avec le nombre de communes par département (nbcom). On a ce type d’info pour chaque division. Il pourrait être intéressant d’exploiter cette donnée en :

  • l’ajoutant dans le titre qui de « Liste des communes du département ..» deviendrait « Liste des 152 communes du département ..» (pour la Lozère)
  • créant une fonction nbcom qui permette de récupérer ce nombre à l'instar de la fonction derniere_population du module module:Population de France qui récupère la dernière population d’une division, ce qui permettrait d’actualiser automatiquement une phrase du type « le département de X comptait y communes au 1er janvier 2019 » (du coup il faut récupérer aussi automatiquement la date avec une fonction derniere_annee à créer également).

Y aurait-il des candidats pour ce petit exercice ? Merci par avance.Roland45 (discuter) 23 juin 2019 à 18:44 (CEST)

Pour info, Le point 1 (ajout du nombre de communes dans le titre) a été traité par Od1n, que je remercie. Il reste donc à créer ces fonctions nouvelles de récupération du paramètre "nbcom", si possible.Roland45 (discuter) 12 août 2019 à 17:34 (CEST)
Cette phrase, @Roland45, elle serait affichée automatiquement, optionnellement ? Dans quels cas ? Cela doit être un texte exportable ? Lofhi (me contacter) 18 août 2019 à 13:48 (CEST)
@Lofhi Voici quelques éléments de réponses :
Sur la phrase
  • le choix de "optionnel" serait à faire si la phrase ne pouvait pas s'intégrer dans un texte préexistant. A priori cette phrase se suffit à elle seule et peut être placée après tout texte descriptif. Donc elle serait à mettre en automatique.
  • Le texte de la phrase, qui est sensé couvrir les différents type de chartes et de divisions serait a priori le suivant (La ref ne comporte pas de date car le site est actualisé annuellement et donc l'url reste constante) :
Le [charte/département] [var charte/de XX] comptait [var_liste_de/nbcom] [liste_de/communes] au [date]<ref>{{Lien web |url=https://www.insee.fr/fr/information/2028028 |titre= Découpage communal - Table d’appartenance géographique des communes et tables de passage |site =le [https://www.insee.fr/ site de l'Insee] }}</ref>.
Sur les fonctions nouvelles :
Le plus important est néanmoins de produire ces fonctions qui permettraient de récupérer les deux paramètres nbcom et date car les modèles qui permettraient d’afficher ces indicateurs peuvent ensuite être mis dans n’importe quel texte ou Infobox. Comme le fait p.derniere_population dans le module:Population de France en récupérant ces infos à partir des modules de données. Dans le cas présent, on va les chercher dans la table sur les tables de Commons. Le modèle pourrait être de la sorte (par similitude avec les tableaux) :
{{Composition Division de France/dernière_pop | charte = département | département = Lozère (département) | liste de = communes}}
Merci par avance.Roland45 (discuter) 18 août 2019 à 18:51 (CEST)
Si j'ai bien compris le dernier exemple Roland45, je n'ai pas encore cerné l'histoire avec la phrase introductive. Tu souhaites l'implémenter comment ? Quel modèle doit l'afficher ? C'est à rajouter dans le modèle {{Composition Division de France}} directement ? Tu souhaites créer une arborescence de modèles comme la famille de modèles Population de France/ ? Lofhi (me contacter) 28 août 2019 à 01:35 (CEST)

@Lofhi Petit complément :

  • La phrase : elle serait à ajouter systématiquement avant le tableau généré par le module Composition Division de France.
  • Les fonctions. Par « fonction », il faut probablement entendre « sous-module » qui permette de récupérer les variables nbcom et date. Ces fonctions sont indépendantes de l’affichage du tableau (puisque ces indicateurs ont vocation à être mis dans une Infobox ou une autre phrase ou tout autre tableau, comme on le fait pour le module Population de France). Le tableau suivant résume la situation :
Modèle projeté fait appel au sous-module/fonction Résultat à l'instar de
modèle:Composition Division de France/nbcom module:Composition Division de France|nbcom Récupère la valeur du nombre de communes de la division,
càd la variable nbcom des tables par division (ex : c:Data:Table/Départements.tab)
{{Population de France/dernière_pop}}
modèle:Composition Division de France/date module:Composition Division de France|date Récupère l'année de l'indicateur (variable date de la même table) {{Population de France/dernière_année}}

On peut donc parler d'arborescence de modèles, mais bon, petite arborescence puisqu'il n'y en aurait que trois : le principal pour afficher le tableau et les deux autres pour afficher les indicateurs caractérisant la division (nbcom, date).Roland45 (discuter) 28 août 2019 à 09:17 (CEST)

&section=0[modifier le code]

Bonjour, Notification Archimëa : et moi évoquions ce problème dans les questions technique, mais nous n'avons pas eu de réponses. Ce problème concerne tous les infobox qui ne sont pas placé au début d'un article. En effet, lorsqu'on clique sur le bouton « Modifier » disponible grâce à ce modèle, l'article ne nous renvoie pas vers la section où comporte l'infobox mais dans le RI (&section=0). C'est extrêmement agaçant quand on utilise l'éditeur visuel et qu'on veut modifier une infobox. Comme disait Archiméa : « Il faudrait un espèce de code qui ouvre la section en cours comme &section=current, mais je sais pas si ce type de paramètre existe ». ». Serait-ce possible de dévelloper un paramètre pareil en Lua (ou bien, existe t-il déjà). Merci d'avance, -- Nemo Discuter 24 août 2019 à 22:53 (CEST)

Cela me semblait impossible en y pensant une fois. Étant curieux, je me suis étonné en allant lire la documentation. Elle indique que Lua peut accéder au contenu d'un article. Du coup cela pourrait être possible techniquement en éclatant l'article par section puis en cherchant le modèle, mais je ne sais pas si cela vaut vraiment le coup. Rares sont les infobox qui ne sont pas dans la section 0. Je laisse quelqu'un d'autre donne son avis... Lofhi (me contacter) 28 août 2019 à 01:57 (CEST)
C'est faux, toute les infoboxs secondaires (et il y en a bcp) se situent dans une autre section. Sinon, autant supprimer ce bouton modifier de toutes les infoboxs ? Peut être qu'il faudrait faire une demande sur Phabricatoir ? C'est un problème qui existe depuis tjrs et qui devrait être résolu une bonne fois pour toute... -- Nemo Discuter 28 août 2019 à 13:01 (CEST)
Il est effectivement possible de « lire » le wikicode d'un article depuis Lua, et donc de déterminer les sections. Il reste qu'il peut être difficile de façon générique de repérer l'infobox qui « nous » correspond. En effet s'il y a plusieurs infobox comment déterminer la notre ? Dans certains cas c'est possible (infobox différente) mais je présume que dans d'autres non.
Par ailleurs ça semble très « bourrin » de devoir faire du wiki-parsing.
Mais je doute qu'il puisse exister un section=current (dans le cadre d'un module). En effet un module peut très bien retourner… du texte contenant des sections ! Idem pour un autre module appelé avant nous…
Hexasoft (discuter) 28 août 2019 à 13:32 (CEST)
En gros, l'infobox devrait savoir par elle-même dans quelle section elle est placée. Sinon, on peut tjrs retirer ce &section=0 ce qui permet au moins de modifier toute la page et non une fausse section... Et des infoboxs qui sont pas en début de page, il y en a un paquet -- Nemo Discuter 30 août 2019 à 19:54 (CEST)

Demande d'explications mémoire Lua[modifier le code]

Bonsoir, ma question va être courte et simple : est-ce que quelqu'un sait m'expliquer ce diff ? Cela m'a coûté un polluage de l'historique du Module:Bases, pensant que les dépendances ajoutées il y a quelques semaines étaient le problème, après avoir corrigé quelques documentations des modèles Bases qui utilisent ces dépendances. Lofhi (me contacter) 30 août 2019 à 02:29 (CEST)

En cherchant "NewPP" dans la source des pages avant/après ton diff, tu verras que pour la version "sans la mémoire saturée" il y a par contre une section "Lua Profile" en plus… Ça ressemble à une stack trace… À chaud, je penserais à une "erreur cachée" qui irait interrompre l'exécution du script, ayant pour side-effect de ne pas atteindre le point de saturation mémoire. Mais je ne fais que spéculer… od†n ↗blah 30 août 2019 à 08:07 (CEST)
Je dois sûrement perdre la tête, mais je n'ai pas accès à ce « Lua Profile ». Je l'ai vu une fois hier, puis il a disparu. J'ai enregistré les rapports du préprocesseur hier, les voici :
J'ai loupé un truc ? Parce que j'ai prévisualisé plusieurs fois les changements, avant et après. Plusieurs fois, j'avais les mêmes résultats. Lofhi (me contacter) 30 août 2019 à 17:55 (CEST)
En tout cas la différence qui me semble la plus importante entre les deux c'est "Expensive parser function count" qui passe de 13 (cas saturé en mémoire) à 4 (l'autre cas).
Par contre j'ai aussi du mal à voir en quoi l'ordre pourrait influencer : s'il y en avait moins dans le 1er ça pourrait se comprendre (mémoire saturée, arrêt du traitement, certains traitements ne sont pas effectués), mais là c'est l'inverse ! Et pour autant que je sache chaque appel de module est indépendant (exception : il me semble que si des données (coûteuses par ex.) sont déjà chargées sur une page elles restent en mémoire et sont utilisable sans surcoût lors des appels ultérieurs). Hexasoft (discuter) 30 août 2019 à 18:04 (CEST)
J'ai oublié de préciser que ces deux rapports sont liés à mes changements sur le module et qui sont annulés depuis (d'où les changements pour "Expensive parser function count"). Si je n'ai pas enregistré les autres rapports, je peux assurer que j'ai fait plusieurs tests en gardant le même ordre d'appel ou en le changeant comme indiqué sur le premier diff, et à chaque fois cela se reproduit.
Si vous allez sur la version du 29 août 2019 à 23:02 et modifiée en dernier par Sukkoria de l'article, que vous prévisualisez la version, la consommation de mémoire excessive réapparaît encore dans le rapport NewPP... Lofhi (me contacter) 30 août 2019 à 18:11 (CEST)
En tout cas, la simple exécution de {{Bases géographiques}} sur la page Allemagne me montre 1,376 s de consommation CPU et 15,46 Mo de consommation mémoire… c'est beaucoup trop à mon goût… Autrement dit, pour simplement une petite série de liens tout en bas de l'article, on retarde l'affichage de la page de 1,376 sod†n ↗blah 1 septembre 2019 à 02:32 (CEST)
Je n'ai pô regardé depuis, mais il serait peut-être intéressant d'analyser les données de Wikidata pour comprendre ce qui pourrait causer ces pics. Lofhi (me contacter) 4 septembre 2019 à 20:58 (CEST)

Wikidata et les trop nombreuses données[modifier le code]

Bonsoir, je ne sais plus si j'ai signalé l'article, mais en tout cas je l'ai remarqué il y a un moment. L'article V8 (moteur JavaScript) contient plusieurs « Erreur Lua : not enough memory ». Il suffit d'aller sur l'élément lié Wikidata Q574992 (« V8 ») pour comprendre ce qui pose problème. Personnellement, je n'ai pas de solution en tête, parce que pour traiter les données de Wikidata, il faut bien les importer... Sauf que là, c'est trop de données. Si quelqu'un peut m'éclairer. Lofhi (me contacter) 9 octobre 2019 à 20:04 (CEST)

Notification Lofhi : Explication potentielle, la manière dont et codée l’infobox logiciel. Il y a pleins d’appels à des modèles lua dans son code, ce qui fait que potentiellement la totalité des données est chargées dans chacun des appels. Si la quantité de mémoire est la somme de tous ces appels, ça peut peut-être monter … Peut-être qu’en la recodant en pur lua ça réglerait le problème, ou à défaut d’utiliser les appels lua qui ne chargent pas tout l’élément à chaque appel lua comme mw.wikibase.getBestStatements dans les modèles comme {{Infobox V3/Tableau Ligne mixte Wikidata}} Je vais jeter un coup d’oeil pour voir comment ça marche en attendant. @Hercule, @Od1n, @FDo64, @Chealer et @Popolon, les éditeurs de l’infobox en 2019. — TomT0m [bla] 9 octobre 2019 à 20:44 (CEST)
Je ne connais pas trop le fonctionnement des scripts lua pour récupérer les informations wikidata pour remplir l'infobox, mais je suis un peu étonné que cela puisse saturer la mémoire. À priori, les requêtes sont faite sur l'élément associé à la page, pas à tout wikidata. Ça de doit pas faire des mégaoctets de données. Dans certains autres cas, comme dans les entités administratives géographiques, des scripts parcourent récursivement les données pour obtenir la chaîne d'entité dans laquelle elle se situe et ça ne pose pas de problèmes non plus. N'hésitez pas à me dire si je peux aider. J'ai déjà fait un peu de lua, mais pas dans ce contexte, ça doit pas être la mer à boire non plus. J'ai quand même quelque chose en tête, la liste (qui peut être très longue des versions (stable/dev). Popolon (discuter) 9 octobre 2019 à 21:22 (CEST)
Effectivement l'affichage de la page Wikidata associé à cet page pose déjà problème en raison du nombre important de numéros de versions. Je pense que si il y a un problème, c'est a cet endroit qu'il faut regarder.Popolon (discuter) 9 octobre 2019 à 21:28 (CEST)
Je pense que nous sommes tous d'accord sur la source du problème. Cependant, ma question était plutôt : connaissez-vous un moyen de l'éviter, parce que comme dit, pour traiter les données, on doit les importer... et c'est la taille des données qui pose problème ici. Je n'ai rien trouvé de très intéressant sur mw:Extension:Wikibase Client/Lua. Lofhi (me contacter) 9 octobre 2019 à 21:42 (CEST)
Bonjour à tous. Notification TomT0m : si besoin, j'ai recodé {{Infobox Logiciel}} en LUA. Il s'utilise par {{Infobox Logiciel/Bac à sable/LUA}} (liens vers le module et la page de tests. Bonne journée, --Tom (discuter) 11 octobre 2019 à 18:31 (CEST)
Après essai en prévisualisation de ce modèle de test, ça fonctionne effectivement sans erreur mémoire : cf. https://fr.wikipedia.org/w/index.php?title=V8_(moteur_JavaScript)&oldid=163474368
( Par contre si l’infobox fonctionne la sauvegarde a l’air de déconner à fond quand je sauvegarde j’ai une erreur « empty server response » … )
Du coup, soit on adopte cette version de l’infobox pour les logiciels, soit on garde l’ancienne version mais on tente d’optimiser le Module:Wikidata pour qu’il ne charge pas systématiquement tout l’élément (ce n’est plus nécessaire depuis un moment.), mais juste les déclarations dont on a besoin lors d’un appel. (c’est ce que fait Module:Wikidata/Chemin). La seconde option semble dans tous les cas une bonne idée, même si dans certains cas marginaux on risquerait peut-être d’y perdre suivant comment les données sont mises en cache. — TomT0m [bla] 12 octobre 2019 à 12:27 (CEST)
Pour mieux cerner le problème, on peut aller sur l'article concerné, cliquer sur "modifier le code" puis prévisualiser et regarder tout en bas les données de performance. On voit que :
  • l'infobox seule prend 42 Mo. La version Lua permet de descendre à 32, mais ça reste problématique.
  • l'infobox en Lua charge 4 éléments. Outre celui pour V8 (moteur JavaScript), il s'agit de ceux pour Open-source software, BlackBerry 10 et IA-32. Ces sujets n'ont pas d'article en français. La fonction wd.siteLink de Module:Wikidata charge les éléments Wikidata pour récupérer le lien en anglais. Apparemment, on peut maintenant récupérer ces liens sans charger l'élément en utilisant wikibase.getSitelink( itemId, globalSiteId ). Si quelqu'un sait ce que sont les "globalsiteids", mettre à jour la fonction ne devrait pas poser de problème. -Zolo (discuter) 12 octobre 2019 à 13:57 (CEST)
(Il semble par contre que les erreurs lua aient totalement disparues, j’en avais en prévisualisant la version https://fr.wikipedia.org/w/index.php?title=V8_(moteur_JavaScript)&oldid=162537502 et ce n’est plus le cas. peut-être ma modif d’hier dans module:Wikidata ?)
Apparemment les ids sont les mêmes que dans https://www.mediawiki.org/wiki/Extension:Wikibase_Client/Lua#mw.wikibase.entity:getSitelink . Sinon les siteids sont sur Wikidata apparemment : [2]TomT0m [bla] 12 octobre 2019 à 14:52 (CEST)
J’ai fait quelques modifs sur Module:Wikidata pour éviter des chargements d’éléments inutiles (il ne doit même virtuellement plus en rester dans le module), j’espère n’avoir rien cassé … mais a priori ça n’a pas vraiment changé la consommation mémoire. Le nombre d’entité chargé lui est par contre bien descendu à 1. — TomT0m [bla] 12 octobre 2019 à 17:09 (CEST)
@TomT0m, j'ai vu ça aussi.. (j'aurais du penser à chercher les identifiants de site directement sur Wikidata :).
En faisant quelques tests sur le module, et en y prévisualisant V8 (moteur JavaScript), je vois que :
  • si on remplace le contenu de la page par {{Wikidata|P31}} ça prend 800 ko. Il est indiqué qu'un élément Wikidata est chargé, mais l'élément n'est certainement pas chargé dans sa totalité, car ça prendrait plus de place.
  • Si on garde tout le contenu de la page sauf l'infobox, on utilise 26 Mo.
  • Avec infobox, mais Wikidata désactivé, la conso de mémoire reste à 26 Mo.
  • Avec l'infobox, on passe à 42 Mo. En réduisant le code du module d'infobox à une seule ligne utilisant Wikidata, on reste à 42 Mo.
L'impression que ça me donne c'est que charger l'élément prend environ 20 Mo, et que le charge depuis deux modèles différents, il se charge deux fois. Mais c'est un peu étonnant --Zolo (discuter) 12 octobre 2019 à 17:38 (CEST)

Bientôt des modèles et modules globaux ? (enfin)[modifier le code]

Bonjour,

J'ai été contacté par Amire80 qui se pose différentes questions de fond concernant les modèles. Cet employé de la fondation, en charge notamment de l'amélioration du support de MediaWiki pour le support des différentes langues, réfléchit notamment à mettre en place des modèles et modules globaux.

L'idée serait de mutualiser le travail en évitant de devoir refaire le développement et la maintenance sur chaque version linguistique. Il a déjà écrit des spécifications très détaillées dont le résumé est disponible ici: mw:Global_templates/Draft_spec/TLDR/fr. Il est intéressé par tout retour sur ces documents, sur cette PDD ou en le contactant directement.

Il est aussi intéressé par vos avis sur une question plus large: Comment l'infrastructure des modèles pourrait-elle être améliorée pour vous rendre plus productif ? Il présentera à la Wikimedia Technical Conference|conférence technique de Wikimedia une session sur l'amélioration de la productivité des outils présents dans les wikis, et en particulier les modèles et modules.

Je pense personnellement que c'est une chance à saisir pour remonter les idées que nous avons, contributeurs des wikis, à une personne de la fondation qui a le pouvoir direct de changer la manière dont nous éditons les articles. De plus, je trouve très bien que nos avis soient recueillis avant le moindre développement technique, ce qui n'a à ma connaissance pas toujours été le cas.

--Framawiki 2 novembre 2019 à 12:17 (CET)

Google Code-In will soon take place again! Mentor tasks to help new contributors![modifier le code]

Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributor about two or three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have any Lua, template, gadget/script or similar task that would benefit your wiki? Or maybe some of your tools need better documentation? If so, and you can imagine enjoying mentoring such a task to help a new contributor, please check out mw:Google Code-in/2019 and become a mentor. If you have any questions, feel free to ask at our talk page. Many thanks in advance! --Martin Urbanec 5 novembre 2019 à 08:28 (CET)

Erreurs de Lint via Modèle:Cycling race/listofteams[modifier le code]

Bonjour,
En me baladant parmi les erreurs de Lint, j’ai remarqué que les Balise de tableau qui devrait être supprimée, dans l’espace pricipal venaient presque toutes – quelques centaines – de Modèle:Cycling race/listofteams.
J’ai cherché à remonter à la source, mais j’ai été trop novice pour trouver l’erreur.
Sernin SC (discussion) 9 janvier 2020 à 16:34 (CET)
Effectivement, t'as vu la taille du code ?!! Comment peut-on espérer qu'un tel truc soit maintenable ?? od†n ↗blah 9 janvier 2020 à 23:33 (CET)
Oh terrible !!! Émoticône
Solution A : Wikimedia embauche un ingénieur plein temps pour maintenir le modèle.
Solution B : Suppression de l'usine à petits-drapeaux. Mot sur Projet:Vélo et requête bot pour nettoyer les articles.
-- Irønie (discuter) 10 janvier 2020 à 01:05 (CET)
Lus. Je copie cette discussion sur Discussion_Projet:CyclismeSernin SC (discussion) 11 janvier 2020 à 12:15 (CET)
La bonne nouvelle, c'est que le code sur le fr.wiki coïncide parfaitement avec la version sur wikidata. Il n'y a pas eu de fork sauvage, ouf ! Je vous invite à aller leur signaler cette histoire de balises <table>, je pense qu'ils y seront sensibles. od†n ↗blah 11 janvier 2020 à 23:17 (CET)
Ça fait des années que je réclame la solution A pour la création, le développement et la traduction des modèles réutilisant les données de Wikidata. Les moyens ne manquent absolument pas et ça permettrait un développement considérable des Wikipédias (mais à chaque fois que je réclame qqch, j'ai cette impression d'être considéré comme de la merde).
@Od1n Il n'y aura jamais de fork. Quand j'avais co-créé le projet il y a bientôt cinq ans, j'avais déterminé que la version sur Wikidata était le supermodule et que sur les autres versions linguistiques ça ne pouvait être que des copies mises à jour plusieurs fois par an (il n'est toujours pas possible d'aller chercher directement le code en un seul point, ça a pourtant été demandé), et qu'une personne apportant des traductions ou des améliorations devait absolument le faire dans le supermodule afin d'en faire bénéficier tout le monde. De cette manière, tout le monde a exactement le même affichage, on a pu se concentrer sur les meilleures traductions possibles à apporter. Autre avantage, si des personnes un peu autoritaires venaient à vouloir imposer certaines choses sur une version linguistique, ça n'avait pas d'emprise sur ce projet.
Le mieux, c'est d'expliquer précisément en français le souci à résoudre sur la page Module talk:Cycling race. Si un problème se pose sur FR Wiki, alors il doit certainement se poser pour toutes les versions linguistiques, donc tout le monde doit profiter de sa résolution. LintErrors, je ne sais pas ce que c'est, mais j'ai le souvenir qu'on m'en avait parlé sur DE Wiki et que nous avions résolu le problème. Jérémy-Günther-Heinz Jähnick (discuter) 15 janvier 2020 à 10:52 (CET)
Sur la solution A, ça m’étonnerai que ça arrive. Pas parce qu’«on» te prend pour de la merde, parce que ça brise la séparation traditionnelle WMF/communauté sur le type de contenu qui doit-être géré par la communauté et le comment, alors que la WMF se contente de fournir du logiciel complètement générique vis-à-vis du contenu. WP est un wiki dans lequel on peut traiter tous les sujets qu’on veut, et choisir de ne pas traiter, mettre des petits drapeaux si on veut, et ne pas en mettre si on veut pas … Wikidata permet à la communauté de créer toutes les propriétés qu’elle veut, et de ne pas créer celles qu’elle ne veut pas … . Il ne sert à rien de « réclamer » à mon avis si on ne tient pas compte de ça. Une solution qui ne briserait pas cette séparation serait que cette personne payée par la WMF reçoive carrément un mandat communautaire pour effectuer certaines modifs sur les modèles communautaires. Donc un consensus. Mais c’est pas simple, quand on voit les conflits que ça peut engendrer cette notion de « consensus » …
Sur le module lui même, le choix technique a été fait de mettre tout le code dans un seul module pour minimiser les dépendances, c’est un choix mais ça peut effectivement se payer en terme de duplication de code et de taille du module excessive. — TomT0m [bla] 15 janvier 2020 à 11:09 (CET)
À partir du moment ou un wikimédien ou un groupe de wikimédiens aurait besoin d'un petit programme mais qu'il ne parvient pas à le mettre en œuvre, parce que quand même c'est compliqué le codage, alors quelque chose devrait être fait, directement ou pas (je faisais aussi référence à quelques courriels ou messages restés sans réponse). Là, on a quand même la sensation de devoir se démerder par nous mêmes. Le mois passé par exemple, j'avais dû modifier le Module:Wikidata pour faire apparaître les citations dans les références parce que j'en avais marre de demander par-ci par-là depuis des mois et que rien ne bouge. Typiquement sur ça j'aurais dû recevoir un coup de main ou avoir un endroit pour adresser ma requête. Le point positif, c'est qu'au moins j'ai appris à me débrouiller par moi-même pour des choses minimales (et du coup, j'essaye de rendre service dès que possible pour par exemple ajouter une propriété), mais que de temps perdu. Si en 2015 nous avions eu une ou deux personnes pour assurer la programmation, il n'y aurait pas eu toutes ces guéguerres autour des infoboxes Wikidata, parce que le rendu aurait été bon tout de suite. Enfin là sur Wikidata et en d'autres lieux on bosse discrètement sur la future génération d'infoboxes, commune à plusieurs langues, l'idée c'est de proposer un bon produit et une bonne documentation tout de suite.
Concernant le supermodule, il génère l'affichage d'une trentaine de fonctions et peut fonctionner dans trente langues (bien que toutes n'utilisent pas toutes les fonctions). Certaines fonctions sont très très proches les unes des autres, comme les classements. Le choix a été fait d'avoir un seul et unique code. Psemdel a fait un incroyable travail de factorisation ces dernières années. Ce qu'il faut savoir, c'est que toutes les Wikipédias n'étaient pas dotées d'un module Date par exemple, donc il avait fallu inclure l'affichage des dates. C'est un exemple parmi d'autres, mais plus on travaille dans un grand nombre de langues plus c'est complexe. L'avantage pour le contributeur lambda, c'est qu'il peut se contenter de remplir Wikidata sans se soucier de la mise en forme. Et quand les données ont été remplies par un autre locuteur, alors il peut se consacrer à la rédaction de l'article ou à d'autres tâches. Jérémy-Günther-Heinz Jähnick (discuter) 15 janvier 2020 à 12:20 (CET)
Il y a surement moyen en attendant les modules globaux d’intégrer des trucs dans l’API lua de base, par exemple il y a déjà des fonctions pour formater les dates (pas forcément pour les manipuler et ça manque à mon avis). Ça pourrait être dans mes cordes mais je manque un peu de motivation en ce moment. — TomT0m [bla] 15 janvier 2020 à 13:15 (CET)
L'erreur en question est la suivante : deletable-table-tag. Remarquez qu'il ne s'agit pas de tables imbriquées, mais de tables mal imbriquées. od†n ↗blah 16 janvier 2020 à 00:14 (CET)
Pour info, l'erreur semble avoir été corrigée, voir notamment les modifs du sur le module. Le rapport lint est tout petit maintenant :) od†n ↗blah 16 janvier 2020 à 00:37 (CET)

Je viens de voir cette superbe discussion, merci pour moi! J'ai passé Noel à inserer le modèle mw.html. Listofteam délivrait exactement la même string qu'avant, sauf que comme le code était plus clair, LintErrors a pu découvrir qu'on avait un tableau dans le tableau (rien de grave en soit). Après, on peut préférer la politique de l'autruche. Je n'ai plus d'idées pour le moment, le code devrait rester stable pour un petit moment. Psemdel (discuter) 20 janvier 2020 à 21:57 (CET) Le code est surement long, mais il fait aussi plein de trucs, donc ce n'est pas vraiment scandaleux. Bien-sûr plusieurs modules seraient plus élégant, mais on aurait un problème pour faire la maintenance en bloc (gros copier/coller depuis wikidata). Pour ceux que ca intéresse, le code initial était :

	return '<table style="max-width:95%; padding:0.5em; margin-right:1em; border:1px solid rgb(200,200,200)"><tr><td>' ..
		text .. getHeader(oldCatID, count) .. '<ol>' .. list ..
		'</ol><table border="0" cellspacing="0" cellpadding="0" style="line-height:0em;width:20em;margin:0.5em 0em;border-top:2px solid #FFDF80;"><tr><th><span style="float:'..floattable..'">[[File:Wikidata-logo S.svg|12px|link=d:' ..
		raceID .. '#P1923]]</span></th></tr></table></td></tr></table>'

On voit bien l'imbrication de deux "table". J'avais converti en:

	local footerTable = mw.html.create('table')
	:attr("border","0")
	:attr("cellspacing","0")
	:attr("cellpadding","0")
	:cssText("line-height:0em;width:20em;margin:0.5em 0em;border-top:2px solid #FFDF80;")
	local tSpan = footerTable:tag('tr'):tag('th'):tag('span')
	:css("float",floattable)
	:wikitext('[[File:Wikidata-logo S.svg|12px|link=d:' ..raceID .. '#P1923]]')

	resulttable:node(footerTable)

Où footerTable est un "table" comme avant, mais on a donc était pris par la patrouille pour ce code "horrible". Maintenant footerTable est devenu footerRow. Voilà. Psemdel (discuter) 20 janvier 2020 à 22:13 (CET)

Mes excuses si je t'ai vexé. Mais il est quand même bien énorme ce code, 350 ko 😅 Je ne dis pas qu'il est sale, je pense même qu'il doit être plutôt propre, par contre avec une taille pareille faut beaucoup de temps et de courage si on veut l'assimiler 😭 od†n ↗blah 20 février 2020 à 02:02 (CET)

Occitanie[modifier le code]

J'ai remarqué que dans le module:Bandeau/Ébauche, il n'y a que le sujet « Occitanie (région culturelle) » et il n'y a pas le sujet « Occitanie (région administrative) » qui n'ont pas la même aire de répartition donc cela peut causer des confusions sur les pages concernant la région Occitanie. Cordialement, John 66000 (discuter) 17 février 2020 à 10:12 (CET)

Module:Biblio : auteur, collection, éditeur, lieu, langues et translittération[modifier le code]

Serait-il possible d’ajouter les fonctions ou arguments suivant au module:Biblio (et les modèles l’utilisant) :

  1. L’argument auteur est automatiquement divisé en prénom et nom. Peut-on formater le résultat comme si c’était ses deux arguments, en particulier avec un <span class="nom_auteur"> sur le nom de famille. Perso, j’utilise un style CSS sur la class nom_auteur, ça pourrait servir à d’autres.
  2. Peut-on ajouter plus d’argument pour les collections? Pour l’instant on a juste un argument collection mais certains ouvrages font partie de deux ou trois collection, chacune avec son propre numéro de collection. On pourrait par exemple avoir collection1, numéro dans collection1, etc.
  3. Peut-on ajouter plus d’argument pour les éditeurs ? Certains ouvrages on plus d’un éditeur. On pourrait par exemple avoir éditeur1, éditeur2, etc.
  4. Peut-on aussi ajouter plus d’argument pour les lieux ? Certaines éditeurs ont plus d’un lieu, ou encore s’il y a plus d’un éditeur, il y a parfois un lieu différent par éditeur.
  5. Pour les ouvrages multilingues ou du moins aux titres multilingues, serait-il possible d’avoir des arguments langue1, titre1, etc. L’unique argument langue=code1, code2 ne permet pas de spécifié quelle langue est laquelle dans un titre.
  6. Pour les noms d’auteurs, titres ou autre arguments en langue écrite avec un autre alphabet que l’alphabet latin, il serait utile de pouvoir noté une translittération, par exemple auteur_trans=Abc Def pour auteur=Абс Деф, ou titre_trans=Abjad pour titre=ابجد.

Qu’en pensez-vous ? Merci d’avance. --Moyogo/ (discuter) 21 février 2020 à 11:18 (CET)

Génération de SVG[modifier le code]

Bonjour,

J’essaie de produire des images vectorielles depuis un module Lua. Mon objectif réel est de réaliser un modèle qui dessinerait automatiquement un graphique en fonction des données fournies en paramètres.

Sauf erreur de ma part, un module Lua n’est destiné qu’à produire du wikicode (expansé) pour inclusion dans les pages qui l’appellent. Cependant il semble qu’on puisse mettre du HTML dans ce wikicode, j’ai donc pensé à inliner l’image SVG dans le HTML au moyen de la balise <svg/> (méthode décrite ici). Mon code de test est ici et le rendu est . C’est raté, le wiki échappe le code du SVG.

Bref, auriez‐vous d’autres suggestions ? Je mettrais ma main à couper que d’autres avant moi se sont attaqués au problème de générer des graphiques. Émoticône sourire

PS : Comme modèles produisant des graphiques, j’ai trouvé ça par exemple, mais c’est du wikicode immonde qui pond du HTML/CSS (séparation du fond et de la forme, bonjour), et de toute façon ce que je veux dessiner est bien plus complexe que quelques rectangles.

Merci ! — Maëlan, le 15 mars 2020 à 01:47 (CET)

Bonjour Maëlan Émoticône. Est-ce que tu connais le module:Graph ? Est-ce qu'il répondrait à tes besoins ? La balise HTML svg n'est pas utilisable sur MediaWiki comme tu l'as remarqué. Ce module utilise l'extension Graph qui doit, apparemment à terme, aussi remplacer EasyTimeline. Lofhi (me contacter) 15 mars 2020 à 04:47 (CET)
Bonjour Lofhi Émoticône, non je ne connaissais ni la balise <graph/> (je reste un novice) ni le module Graph, c’est exactement ce que je cherchais ! (En plus, j’envisageais à terme de produire des animations pour montrer une évolution temporelle, ce que permet aussi la balise <graph/> même si j’ignore si c’est utilisable à travers le module Graph.) Néanmoins la documentation laisse un peu à désirer et je ne sais pas ce qui est disponible sur la Wikipédia francophone. Il semble y avoir deux modèles Graph:Map et Graph:Chart qui dérivent du module Lua, mais seul le deuxième semble avoir été porté chez nous (c’est le premier qui m’intéresse actuellement). Surtout, je n’arrive pas à me servir de la fonction map avec une autre carte que le planisphère par défaut (par exemple la carte des départements français). Quelles cartes sont disponibles chez nous (il n’y a rien dans Spécial:Index/Module:Graph/) et comment les invoquer (la syntaxe présentée dans la doc anglophone à savoir basemap = //de.wikipedia.org/w/index.php?title=Modul:Graph/WorldMap-iso2.json&action=raw ne fonctionne pas) ? Comment en créer de nouvelles ? Peut‐être que je pourrais trouver mes réponses tout seul si j’ai la réponse à cette question : comment trouver des utilisations du module Lua sur la Wikipédia francophone ? — Maëlan, le 17 mars 2020 à 00:34 (CET)
Voir commons:category:Map_data_of_subdivisions_of_France. --Viruscorona2020 (discuter) 22 mars 2020 à 08:22 (CET)

Demande d'un module pour le modèle S[modifier le code]

Bonjour, j'ai lancé une proposition pour simplifier le modèle {{Siècle}}. On pourrait se passer du second paramètre pour retranscrire en français le nom du siècle (ça peut aussi se faire avec des {#IF} mais c'est peut-être mieux via un module. Je vous invite à donner votre avis ici : Discussion modèle:Siècle#On pourrait se passer du paramètre prononciation en français (2) Cordialement, -- Nemo Discuter 12 avril 2020 à 22:34 (CEST)

Refonte du modèle {{Clade}}[modifier le code]

Bonjour,

Depuis 2011, le modèle {{Clade}} contient l'avertissement « Ce modèle est catastrophique à cause des tableaux imbriqués » et en effet, la quasi-totalité soit 93 des 94 pages catégorisées dans Catégorie:Page où la profondeur d'expansion est dépassée le sont à cause de ce modèle. Une bonne âme pourrait-elle s'occuper de ré-écrire ce modèle ?

Notifications des principales personnes intervenues sur ledit modèle @SenseiAC, @Pixeltoo, @Saint amand et @Zebulon84

Cdlt, Vigneron * discut. 23 mai 2020 à 14:31 (CEST)

Est-ce qu'on peut juste mettre {{Arbre début}} / {{Arbre fin}} à la place ou est-ce que certains utilisateurs préfèrent {{clade}} pour des raisons esthétiques ? C'est la solution la plus simple à mon avis.
Sinon, on pourrait peut-être "optimiser" le modèle en sortant tous les paramètres des #if (chaque étage de l'arbre consommerait alors exactement 1 niveau d'imbrication sur les 20 autorisés, au lieu de 1 ou 2 actuellement). Mais ça rendrait le code encore pire que maintenant.
Écrire un module ne permettrait pas de résoudre le problème sans changer la manière dont le modèle est utilisé : le simple fait d'appeler un module dans le modèle ferait passer à 2 niveaux par étage de l'arbre tout le temps.
Orlodrim (discuter) 23 mai 2020 à 17:26 (CEST)
@Orlodrim je dois avouer que je n'en sais trop rien. J’ai repéré le problème et je le signale (peut-être pas au bon endroit, il ne faut pas hésitez à déplacer le message si tel est le cas). Cdlt, Vigneron * discut. 24 mai 2020 à 18:51 (CEST)
J'ai demandé là : Discussion Projet:Biologie/Le café des biologistes#Modèle:Clade. Orlodrim (discuter) 24 mai 2020 à 19:52 (CEST)

Modèle lien web[modifier le code]

Bonjour, la maintenance des principaux modèles servant à la vérifiabilité, {{lien web}}, {{article}}, {{ouvrage}}… semble désertée. J'aimerais cependant réitérer ici certaines demandes qui ne me paraissent pas problématiques et qui, de fait n'ont reçu aucune opposition, ce qui me permets d'alléguer d'un consensus par défaut relevant de l'unanimité Émoticône. Je pense notamment aux demandes d'uniformisation des paramètres des modèles (grande unification) telles que rajouter le paramètre plume et nature ouvrage au modèle lien web.

Discussion modèle:Lien web#Paramètre plume pour le modèle

Discussion modèle:Lien web#paramètre "nature article/ouvrage"

Ça ne donne pas de meilleurs résultats sur Module:Biblio.

Perso, je ne connais rien au lua et les modèles sont protégés.

Je suis allé voir les admins qui m'envoient ici...

Cordialement Ypirétis (discuter) 25 mai 2020 à 09:28 (CEST)

Notification Ypirétis :
  • Je me suis chargé d'implémenter plume dans le Module:Biblio/Lien web. Pourrais-tu mettre à jour la documentation ?
  • nature article/ouvrage est tout simple à implémenter, on peut directement reprendre le code présent dans Module:Biblio/Article et Module:Biblio/Ouvrage. Mais quel nom devrait avoir le paramètre ?
    • Pour confirmer, je suppose qu'en revanche le paramètre établissement ne serait pas vraiment utile pour ce modèle ?
od†n ↗blah 26 mai 2020 à 07:23 (CEST)
Bonjour, merci beaucoup. Pour le second paramètre je pencherais pour "nature document" avec des alias avec les deux autres. Merci encore. Ypirétis (discuter) 26 mai 2020 à 09:35 (CEST)
Je n'ai pas repéré de paramètre établissement, je ne sais pas à quoi il correspond... Je m'occupe de la doc. ✔️ Cordialement Ypirétis (discuter) 26 mai 2020 à 10:23 (CEST)
Bon, le paramètre 'établissement' n'est pas documenté. En regardant le code, vu ce que j'en comprends, il pourrait figurer dans lien web comme dans les autres, au titre de la doctrine de la grande unification. Cordialement --Ypirétis (discuter) 26 mai 2020 à 11:50 (CEST)
  • J'avais aussi pensé à nature document, donc d'accord avec ce nom. (et pourquoi pas normaliser en nature document dans les trois modèles…)
  • Aucune utilisation de établissement dans {{Article}}, et seulement deux dans {{Ouvrage}} (voir aussi cette discussion). Tout cela fait bien peu. Pas certain que le paramètre soit pertinent à conserver, et en tout cas je suis plutôt d'avis à ne pas l'ajouter dans {{Lien web}}.
od†n ↗blah 27 mai 2020 à 02:48 (CEST)
  • Ajouté nature document à {{Lien web}}. Je peux te confier la documentation de nouveau ?
  • À propos, pour {{Article}} et {{Ouvrage}}, il y a quelques noms de paramètres erronés qui traînent (e.g. nature de l'ouvrage). Il serait judicieux, à l'aide de l'outil wstat.fr, dans un premier temps de corriger les paramètres en nature ouvrage/nature article, puis dans un second temps d'ajouter un nom de paramètre nature document, qui serait le nom à utiliser de préférence.
od†n ↗blah 27 mai 2020 à 04:07 (CEST)
Bonjour, merci beaucoup. Je me charge de la doc ✔️. Pour établissement mieux vaut l'enlever partout amha (unification toujours) et traiter à la main les 2 seuls cas d'utilisation. Pour wstat.fr connais pas (je vais aller voir). Cordialement Ypirétis (discuter) 27 mai 2020 à 08:43 (CEST)
Juste pour signaler que je viens de remarquer le modèle {{Chapitre}}, dont le paramètre sera à unifier de la même façon. od†n ↗blah 1 juin 2020 à 03:26 (CEST)
Pour ajout de "plume" sur {lien web} pour homogénisation. Reste que j'ai jamais compris si le paramètre était déconseillé ou pas, s'il était préférable d'utiliser {plume}.
 OK avec "nature document" mais faut rajouter l'alias "nature du document" (sinon autant d'erreurs qu'avec l'alias inexistant "nature de l'ouvrage").
-- Irønie (discuter) 1 juin 2020 à 15:09 (CEST)

Bonjour. J'espère que je suis au bon endroit.

Sur le bistro du 29 juin j'ai fait une suggestion qui n'a pas reçu énormément de réponse, mais globalement des réponses positives. Il s'agit de modifier l'affichage des numéros de notice BNF, pour harmoniser avec tous les autres numéros (ISBN, OCLC, etc.) :

Avant Après
(BNF 34063996) (BNF 34063996)

Je sais que ça se passe sur Module:Biblio/Références mais je n'ai ni les droits d'administrateurs pour intervenir sur cette page protégée, ni les compétences suffisantes pour dire exactement comment modifier pour obtenir l'effet voulu. Enfin je pense que ça consiste grosso modo en ça, mais je ne suis pas certain :

function References.bnf( bnf )
	bnf = Outils.trim( bnf )
	if bnf then
		local texte = ''
		local category = ''
		local bnfId = bnf:upper():match( 'BNF(%d+%w)' ) or
			bnf:lower():match( 'cb(%d+%w)' ) or
			bnf:match( '^%d+%w' )
		
		if bnfId then
			-- bnf contient une suite de chiffres qui peut être un ark valide
			local base = bnfId:sub( 1, 8 )
			local arkId = References.arkId( 'cb' .. base )
			if bnfId:len() == 8 then 
				-- il manque la clé, on l'ajoute
				bnf = base .. arkId
				texte = base
			elseif bnfId:len() > 8 and bnfId:sub( 9, 9 ) == arkId then
				-- ark valide
				bnf = bnfId:sub( 1, 9 )
				texte = base
			else
				-- ark qui semble non valide
				bnf = bnfId
				texte = bnfId
				category = '[[Catégorie:Recension temporaire pour le modèle Ouvrage|bnf]]'
			end
		else
			-- le paramètre ne semble pas un ark valide
			texte = bnf
			category = '[[Catégorie:Recension temporaire pour le modèle Ouvrage|bnf]]'
		end
		
		-- dans tous les cas on renvoie l'adresse, on catégorise juste pour vérifier ce qui ne va pas
		local lien = databaseExterne(
			bnf, 
			'[[Bibliothèque nationale de France|BNF]]', 
			'catalogue.bnf.fr/ark:/12148/cb', 
			'.public', 
			texte 
		)
		
		return lien .. category
	end
end

À vrai dire je ne sais même pas comment tester... Quelqu'un ayant des droits d'admin peut-il tester et faire la modification pour moi ? Ça serait sympa. Merci Émoticône sourire.

Je notifie @Od1n et @Zebulon84 qui ont beaucoup travaillé sur ce module. — Hr. Satz 2 juillet 2020 à 22:44 (CEST)

Modèle sur les dates de naissance et de mort des personnes[modifier le code]

Il est courant d'afficher la date de naissance et la date de décès d'une personne entre parenthèse. Il peut être fastidieux de copier ces informations à la main alors qu'on peut les récupérer sur Wikidata. Du coup, j'ai créé le modèle Utilisateur:PAC2/Modèle:Personne à titre expérimental. Est ce que vous pensez que c'est utile ? Est ce qu'il y a déjà eu une tentative similaire ?--PAC2 (discuter) 7 juillet 2020 à 22:13 (CEST)

Finalement, j'ai créé {{Biographie}} qui permet d'afficher directement la date de décès et de naissance pour une personnalité (exemple Modèle:Biographie ou Modèle:Biographie). N'hésitez pas à me dire ce que vous en pensez et surtout si vous trouver ça utile ou non. --PAC2 (discuter) 9 juillet 2020 à 22:25 (CEST)

Géolocalisation des astres[modifier le code]

Bonjour
Quelqu'un saurait adapter Modèle:Infobox/Géolocalisation astronomique en Lua pour l'intégrer au modèle:Infobox Astre ? - Simon Villeneuve 12 juillet 2020 à 17:37 (CEST)

Erreurs Lua : not enough memory[modifier le code]

Bonjour tout le monde. Hier Notification JLM : a signalé ici une erreur LUA qu'il a supprimé en modifiant l'infobox de Pandémie_de_Covid-19_en_Colombie. Ayant cherché sur google, j'ai trouvé une autre page avec des erreur Lua: Projet:Communes_de_France/Taille_des_articles_(28) Que peux-t'on faire ? — Le message qui précède, non signé, a été déposé par Ender~frwiki (discuter), le 13 septembre 2020 à 10:56 (CEST) ~-- Ender~frwiki (discuter) 13 septembre 2020 à 10:57 (CEST)

Bonjour,
La page ne prend plus trop de mémoire désormais (39,7/50 Mio), JLM a supprimé la date qui posait problème, je l'ai remis mais sans formatage.
Par contre, c'est toujours le cas de Projet:Communes de France/Taille des articles (28), mais cela n'a pas de rapport, la page appel trop de modèle. — eru [Discuter] 13 septembre 2020 à 11:33 (CEST)
En faite le paramètre coordonnées semble également très gourmand en mémoire, et si je retire tous les paramètres avec =- il n'y a plus de problème de mémoire avec Depuis le {{date|6 mars 2020}} <small>({{durée|6|3|2020}})</small>.
Je ne comprends donc pas trop où est le problème de base. — eru [Discuter] 13 septembre 2020 à 12:06 (CEST)
Merci Notification eru : pour ta réponse rapide. Tu sèches aussi sur ce message d'erreur mais moins que moi qui, à part un réglage des vis platinéesÉmoticône, ne voit pas trop quoi faire. Néanmoins j'ai trouvé 5 départements utilisant une telle liste. Et celle présentant des erreurs est la plus grande. Mais bon ... cela n'explique pas non plus la page "Pandémie_de_Covid-19_en_Colombie". En tout cas, merci de t’être penché sur le problème. Ender~frwiki (discuter) 13 septembre 2020 à 13:14 (CEST)
PS: tu as une splendide collection de bouquins. mais aucun de Vernor Vinge que je te conseille. Ender~frwiki (discuter) 13 septembre 2020 à 13:15 (CEST)

Bonjour. Est-ce que l'on aurait un équivalent de ce module et modèle ? Ils permettraient de régler quelques problèmes détectés dans Spécial:LintErrors/bogus-image-options quand certains modèles construisent à la main des liens sur des images avec des paramètres optionnels. --NicoV (discuter) 28 septembre 2020 à 11:05 (CEST)

Sachant que j'ai testé rapidement ce module/modèle sur enWP, et que je trouve dommage le fait qu'il ne gère pas la présence de "File:" ou équivalent dans le nom du fichier (il l’ajoute à chaque fois). --NicoV (discuter) 28 septembre 2020 à 11:06 (CEST) EDIT: Je n'avais pas vu en:Template:Remove file prefix… --NicoV (discuter) 28 septembre 2020 à 11:08 (CEST)

Programme Viking dans la catégorie "Article à illustrer Monument"[modifier le code]

Bonjour Émoticône Tout mon problème est mais je vais en faire un résumé. Programme Viking (entre autres) est dans la catégorie Catégorie:Article à illustrer Monument.Cela arrive par le modèle {{Infobox}} => « Ce modèle s'appuie sur le Module:Infobox/Infobox universelle qui génère par défaut une infobox monument » et donc la catégorisation arrive via : Module:Infobox/Monument. Zolo ne semblant pas dispo, quelqu'un pourrait il corriger cette erreur ? En attendant je vais essayer de trouver une autre infobox pour le Programme Viking. Bien cordialement. Ender~frwiki (discuter) 1 octobre 2020 à 10:44 (CEST)

Hello Ender~frwiki,
le problème vient de l'utilisation de {{Infobox}}, qui est générique et non spécifique. J'ai changé ça en {{Infobox Engin spatial}} : ça ne semble pas changer les infos affichées (enfin, l'info), et je ne vois plus de catégorie liée aux monuments. Cordialement, Hexasoft (discuter) 1 octobre 2020 à 11:08 (CEST)
Hello Notification Hexasoft :. Merci pour cette réponse super rapide. Je verrais plutôt le bandeau {{Infobox Mission spatiale}} mais je vais m'en occuper. Le souci est plus large car il va falloir changer les bandeaux de plusieurs centaines de pages comme par exemple America West Express, ANDi, AirTags, Antique (groupe) etc ... (quelques exemples parmis la première page de {{Catégorie:Article_à_illustrer_Monument}} ). Et cela est un travail sans fin car une infobox générique est souvent la première utilisée. Cela implique que l'infobox générique soit générique et n'utilise pas un template monuments. Me trompe-je ?Émoticône Ender~frwiki (discuter) 1 octobre 2020 à 11:33 (CEST)
@Ender~frwiki,
je te laisse voir le plus indiqué en terme d'infobox.
Pour le problème de l'infobox générique oui, ça semble curieux de mettre une catégorie par défaut. À la limite il serait peut-être plus pertinent de ranger ces articles dans une catégorie du style "Article avec infobox générique" afin de les trouver et de les "spécialiser" plus facilement.
Après j'ignore si l'infobox générique dispose d'un moyen automatique pour trouver son "thème" (et que, juste, ce moyen ne fonctionnerait pas dans la situation présente).
Cordialement, Hexasoft (discuter) 1 octobre 2020 à 11:48 (CEST)
@Hexasoft,
Je vais demander au Projet:Infobox si ils peuvent adapter une infobox pour les programmes spatiaux. En attendant, je vais laisser la tienne.
Concernant l'infobox générique, si j'ai bien compris, ta méthode dois être possible mais elle demande un travail manuel conséquent (spécialiser toutes les infobox incriminées).
Je pense que Zolo n'a pas voulu recréer un template spécifique et a repris un qu'il pensait générique. Selon moi, pour que l'insertion de catégories inadaptées ne se reproduise pas dans le futur, le mieux serait de faire une copie du template Monuments, de le modifier pour qu'il n'ajoute pas la catégorie cachée et la renommer en "Template générique" puis modifier le modèle infobox générique. Comme cela l'infobox serait vraiment générique. Mais bon, comme je n'y connais rien ou pas grand chose. Je te laisse faire comme tu le sens.
Cordialement.
Ender~frwiki (discuter) 1 octobre 2020 à 12:55 (CEST)
En fait on parle du sujet Ici Ender~frwiki (discuter) 1 octobre 2020 à 13:03 (CEST)

Cf. Discussion modèle:Bibliographie#Problèmes avec ISSN marqués comme dépréciés sur Wikidata, si quelqu'un sait corriger. --NicoV (discuter) 2 octobre 2020 à 13:38 (CEST)

Taille de l'image[modifier le code]

Bonjour, comment les infobox en Lua gèrent-elles les paramètres d'image qu'on leur donne ?

En pratique, j'aimerais pouvoir jouer sur la taille des images dans {{Infobox Épidémie}} comme on peut le faire dans {{Infobox Biographie2}} et {{Infobox Localité}} avec le paramètre taille image, mis je ne vois pas où ça se passe dans Module:Infobox/Biographie ou Module:Infobox/Localité. --l'Escogriffe (✉·✎) 15 octobre 2020 à 23:41 (CEST)

Code pour avoir la carte IGN classique en référence[modifier le code]

Bonsoir, je viens m'adresser à vous sur indication de Roland45 (d · c · b) pour votre dextérité à programmer les modèles en lua. Quand vous regardez dans l'infobox du pic de la Calabasse juste après les données de géoloc, deux lignes de code permettent d'avoir dans l'article une référence qui établit un lien direct pour ouvrir la bonne carte IGN classique dans "Notes et références". Serait-il possible d'obtenir le même effet sur l'infobox "Monument" avec par exemple le Château de Belcastel (Lot) ? je pense aussi à un autre détail, nombre de chutes d'eau sont des sites naturels classés comme par exemple la Cascade d'Ars mais l'infobox "Chute d'eau" n'affiche rien du tout alors que cela est indiqué en rubrique "Classement". Cela fonctionne à titre d'exemple sur Église Saint-Jean-Baptiste de Mérigon. Cela ne marche pas également à l'infobox "Cirque naturel"... Il y a sans doute besoin de repasser sur des infobox assez marginales à caractère géographique en ce qui concerne la géoloc/carte et le classement sites classés et inscrits... En espérant être utile, bien à vous Sergio09200 (discuter) 22 octobre 2020 à 19:35 (CEST)

Modification "Module: Palmarès tennis" WTA[modifier le code]

Bonjour à tous, Suite à une discussion en cours sur la page des projets tennis, et semble t'il l’inactivité (depuis 2017 ou 2016) de vos contributeurs Notification Rpa et Zebulon84 : nous aimerions avoir votre aide quant à la mise à jour d'un module. En effet, la WTA Tour à fait renommer les catégories de tournois à partir de la saison 2021. Ainsi nous aimerions pouvoir les modifier également sur le module Palmarès tennis et plus particulièrement pour la catégorie. Ainsi nous devons créer 4 nouvelles catégories à savoir : WTA 1000, WTA 500 et WTA 250 et mettre une date de fin (2020) pour les catégories : premier mandatory, premier 5, premier et international. Savez vous qui peut nous aider, ou a défaut comment avoir la possibilité de créer de nous même ces catégories ? Un grand merci.--NikoSerbe (discuter) 21 décembre 2020 à 08:48 (CET)

Étude de faisabilité pour un module commun aux modèles « Article connexe », « Article détaillé » et compagnie[modifier le code]

Bonjour

Suite à une discussion sur le bistro (Wikipédia:Le Bistro/6 septembre 2020#Utilisation du modèle Article principal) ayant mené à une requête de bot par Jacques Ballieu (Wikipédia:Bot/Requêtes/2020/09#Modification de l'usage Modèle:Article principal), on est arrivé à la conclusion avec Ideawipik qu'il serait peut-être plus malin de fusionner une série de modèles similaires ( Modèle:Article connexe ; Modèle:Article détaillé ; Modèle:Article détaillé en ligne dont les rares insertions pourraient être aisément remplacées par le précédent et son paramètre contenu ; Modèle:Article général ; Modèle:Page annexe, pendant du Modèle:Annexe ; Modèle:Voir lexique ; Modèle:Article principal actuellement réservé aux catégories ; Modèle:Aide détaillée ; Modèle:Voir Wikipédia ; Modèle:Voir aussi Wikipédia et peut-être d'autres).

Certains de ces modèles sont utilisés dans des articles et d'autres dans des catégories ou encore sur des pages d'aide, mais tous on la même fonction : pointer vers une autre page de Wikipédia.

Le truc serait d'avoir un seul modèle capable de reconnaître où il est placé et sa cible, et changeant son apparence en conséquence (avec un paramètre supplémentaire pour les cas spéciaux).

Ça me semble plutôt compliqué avec un modèle normal (et peut être même impossible), mais je pense que c'est faisable avec un module lua, donc je suis venu demander conseil ici à propos de la faisabilité de la chose, car mes compétences en lua restent très limitées.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 13 janvier 2021 à 12:41 (CET)

Hello,
déterminer un comportement selon qu'on est appelé depuis Main:, Aide:, Discussion:, Catégorie: etc. est simple.
Par contre s'il il y d'autres critères de distinction il faudrait les expliciter, afin de voir si c'est possible. Cordialement, Hexasoft (discuter) 13 janvier 2021 à 12:56 (CET)

Ajouter l'identifiant hdl dans Module:Biblio/Références ?[modifier le code]

Bonjour. Avec mon bot, je fais actuellement un peu de ménage dans les paramètres inconnus utilisés avec les modèles {{Article}}, {{Ouvrage}}… et je vois qu'un certain nombre d'appels ont des paramètres "hdl", pour Handle System, (par exemple, sur (20000) Varuna) qui ne sont pas gérés sur frWP. Ce paramètre est géré sur enWP (il fait des liens vers http://hdl.handle.net par exemple http://hdl.handle.net/10045/70230). J'hésite entre plusieurs actions :

  1. Ajouter la gestion de ce paramètre dans Module:Biblio/Références (je peux le faire, ça n’a pas l’air trop compliqué)
  2. Considérer ce paramètre comme connu même si il ne l’est pas actuellement
  3. Mettre en commentaire les utilisations de ce paramètre
  4. Supprimer les utilisations de ce paramètre

Des préférences ou des remarques ? Je ferais bien l’option 1 Émoticône sourire. --NicoV (discuter) 19 janvier 2021 à 13:23 (CET)

Ping des contributeurs pas trop anciens du module : @Od1n, @Gratus, @Zebulon84 et @Rehtse. --NicoV (discuter) 19 janvier 2021 à 13:25 (CET)
Idem pour le paramètre "s2cid", pour Semantic Scholar, (par exemple sur Conodonta. Ce paramètre est géré sur enWP (il fait des liens vers https://api.semanticscholar.org/CorpusID:xxxxxx par exemple https://api.semanticscholar.org/CorpusID:128496416). Même question. --NicoV (discuter) 20 janvier 2021 à 08:21 (CET)

J'ai ajouté les 2 paramètres dans Module:Biblio/Références. Si vous pensez que c'est une erreur, annulez. --NicoV (discuter) 20 janvier 2021 à 08:34 (CET)

Bonjour,

Quelqu’un pourrait-il faire en sorte que si un site a (zh-Hans) et/ou (zh-Hant) listé(s) dans Wikidata, seul (zh) s’affiche dans les modèles {{Bases}} et compagnie ? Sinon c’est trop long.

Voir Lucie Guimier#Liens externes par exemple.

Merci. — Thibaut (discuter) 22 janvier 2021 à 16:06 (CET)

Bonjour Thibaut120094 Émoticône
Je pense qu'il faut éviter les cas particuliers, par contre on peut au-delà d'un certain nombre de langues (3 ? 5 ?) forcer l'affichage de (mul).
Si cela convient il faudra faire la proposition sur le Projet:Bases
eru [Discuter] 22 janvier 2021 à 17:03 (CET)
Ok à partir de minimum trois (cela permet de ne pas perdre l’information pour les sites répertoriés qui ont une version dans la langue d’origine et une version en anglais). — Thibaut (discuter) 22 janvier 2021 à 17:20 (CET)
(mul) est effectivement une base suggestion ; ceci dit, de façon générale, on peut aussi ne pas afficher l’écriture de la langue et se contenter de la langue (et n'afficher qu'une fois la langue quand elle apparaît avec plusieurs écritures). En effet, l'indication de l'écriture est rare et généralement peu utile (celui qui sait lire la langue reconnaîtra généralement l’écriture sans trop de problème et sans surprise). Cdlt, Vigneron * discut. 22 janvier 2021 à 18:49 (CET)
La langue est récupérée ici P1153#P1630 («  »), il n'a pas de distinction entre la langue et l'écriture, ou en tout cas je pense que cela serait trop compliqué pour l'utilité qu'il y en a.
Je vais lancer la discussion sur le projet. — eru [Discuter] 22 janvier 2021 à 19:04 (CET)
@Eru -Hant ou -Hant c'est bien l’écriture ;) et cela devrait facilement pouvoir être retiré, non ? Et oui, la proposition complémentaire d'avoir paramètre maxLang est excellente, j'approuve. Cdlt, Vigneron * discut. 22 janvier 2021 à 19:54 (CET)
non, on ne peut pas modifier la valeur sur wikidata, c'est le code IETF, on pourrai peut-être mettre Q7850 (« langues chinoises »), mais cela serait faux car le site est bien dans les deux systèmes d'écriture.
Il faudrait donc le faire sur wikipédia, on pourrait spliter sur le -, mais si ce n'est que pour ce cas particulier je ne pense pas que cela vaille le coup, autant mettre (mul)eru [Discuter] 22 janvier 2021 à 20:45 (CET)
@Eru oui, je pensais bien à couper après le tiret. Ceci dit, je viens de faire une requête pour voir combien de bases et de langues sont concernées : https://w.wiki/vTF Effectivement elles sont peu nombreuses (étrangement, il n'y a que le chinois que l'étiquette ISO 15924 est utilisée, les 5 autres sont des étiquettes ISO 3166), inutile de faire une usine à gaz pour si peu. Je pensais que cela pouvais faire gagner un peu de place à l'affichage et éviter le mul mais au final c'est plutôt inutile. Cdlt, Vigneron * discut. 23 janvier 2021 à 13:53 (CET)

Chargement d’un TemplateStyle dans Module:Infobox[modifier le code]

Bonsoir, afin de pouvoir supprimer tout le CSS des infobox_v3 dans MediaWiki:Common.css, un des prérequis est d’ajouter le chargement de Modèle:Infobox V3/styles.css dans Module:Infobox. À moins que ce ne soit dans Module:Infobox/Style ?

À priori c’est possible puisque le prototype Module:Palette de navigation développé par Notification Hlm Z. semble le faire. Par ailleurs, wp:en le fait également, voir les modules de en:Category:Templates using TemplateStyles (par exemple, en:Module:Infobox military conflict).

Les principaux développeurs de ce module n’étant plus présents, et ne connaissant rien au Lua, je sollicite de l’aide ici.

Qui peut m’aider ? --FDo64 (discuter) 17 février 2020 à 22:56 (CET)

J'avais entamé Catégorie:Modèle appelant des feuilles de style TemplateStyles. Lofhi (me contacter) 17 février 2020 à 23:12 (CET)
Notification Lofhi : Bonsoir. Ici, il s'agit d'un module, pas d'un modèle. --FDo64 (discuter) 18 février 2020 à 00:19 (CET)
Je sais, mon intervention ne portait que sur l'existence de la catégorie. Elle pourrait être utile à qui voudra avoir une idée des tendances d'utilisation de TemplateStyles. Lofhi (me contacter) 18 février 2020 à 00:44 (CET)
Aussi, voir cette discussion avant. Lofhi (me contacter) 18 février 2020 à 02:01 (CET)
Bonsoir, je tente de reprendre les travaux initiés par Notification Ash Crow, c’est-à-dire alléger le Mediawiki:Common.css. Dans la discussion que tu pointes, Notification Od1n semble dire que c’est une fausse bonne idée. S’il le confirme, alors je vais abandonner mes travaux. Néanmoins ça semble en contradiction avec ce que je comprends des conseils d’optimisation des chargements des pages rappelé ce matin dans le Bistro. Il y est indiqué qu’il faut mettre le maximum dans les premiers 14KB de la page, et donc alléger autant que possible le common.css.
Remarque : j’ai la même démarche pour les bandeaux et j’ai prévu le cas facile des Taxobox.
Défense Pikachu : Modèle:Liste éléments/styles.css‏‎ est utilisé sur 652 504 pages. Et il y en a d’autres (voir Pages les plus incluses).
--FDo64 (discuter) 18 février 2020 à 22:04 (CET)
La clé c'est vraiment que les CSS "externes" (Common.css, etc) sont mis en cache par le navigateur. Donc après ils ne sont plus du tout transférés et ça, c'est vraiment le top. (petit bémol quand même : Size of stylesheets, cependant les appareils et navigateurs d'aujourd'hui traitent le CSS très, très rapidement ; mieux vaut "exécuter" pour rien 2 ko de CSS gardé en cache, que de transférer 2 ko de données)
Pour les considérations comme le First Meaningful Paint, parmi les développeurs MediaWiki il y a effectivement des gars vraiment calés niveau performances d'affichage des pages (ça ne les empêche pas d'ajouter à tour de bras des scripts qui tournent comme des veaux), et globalement, Wikipedia est laaargement plus performant que la plupart des autres sites que je rencontre. Personnellement, ce qui m'intéresse (et je pense les dévs MediaWiki aussi) ce sont les performances avec le cache navigateur déjà alimenté (primed cache), car le cache vide ça ne se produit qu'une seule fois.
Un aparté au passage, pour moi tant qu'une page "sautouille" elle n'est pas exploitable (en plus que ça soit particulièrement agaçant). Donc si une page affiche un contenu rapidement c'est bien, mais si après elle "sautouille" pendant des plombes ça ne va pas du tout… (je ne dis pas ça pour Wikipédia qui s'en sort très bien à ce niveau, mais pour un paquet d'autres sites…)
Pour ta défense pikachou, là le code est tellement court, que les perfs sont négligeables et la priorité est plutôt à l'organisation.
Faut trouver le juste équilibre dans tout ça ;) od†n ↗blah 19 février 2020 à 06:23 (CET)
Une petite correction : ce sont les 14 ko du fichier HTML, donc ça n'inclut pas le Common.css, qu'il ait déjà été chargé en cache ou non. Ce qu'ils veulent dire, c'est que dans ces 14 ko, il faut faire tenir les <link rel="stylesheet"> fondamentaux et le début du contenu de l'article. od†n ↗blah 19 février 2020 à 06:33 (CET)
Merci Od1n Émoticône pour toutes ces explications. Et comme j'aime bien les réponses par oui ou par non Émoticône, je comprends que je dois arrêter mes travaux consistant à alléger le common.css des class bandeau, infobox_v2, infobox-v3 et taxobox ? C'est bien ça ? --FDo64 (discuter) 19 février 2020 à 09:57 (CET)
Même si le code CSS reste finalement dans le Common.css, j'ai le sentiment que ton boulot permet de grandement mettre au propre la codebase du wiki, c'est très bon à prendre alors te gêne pas pour continuer :) od†n ↗blah 19 février 2020 à 10:46 (CET)
Notification Od1n, FDo64 et Lofhi : Pour info : Wikipédia:Questions techniques/semaine 6 2021#Performance issue in popular infobox template. Orlodrim (discuter) 10 février 2021 à 01:19 (CET)
Ah ouais, forcément… : « Using MediaWiki:Mobile.css is highly discouraged as this can result in as unlike desktop, this file is loaded via JavaScript for performance reasons ».
J'y vois au moins deux gros inconvénients :
  • C'est à cause de cela que sur mobile on a des gros FOUC ignobles ; non pas seulement au premier affichage, mais à tous les affichages (pas de cache). À une époque j'avais du faire pas mal de modifications pour que la page d'accueil sautille moins dans tous les sens, parce que c'était vraiment cocasse…
  • Les autres codes doivent s'adapter à cette politique ; comme on a l'exemple ici, où on se retrouverait à sortir du cache desktop Common.css pour passer en inline, une blinde de CSS utilisé sur un très grand nombre de pages.
Je serais intéressé d'avoir des refs expliquant ce choix du chargement des styles via javascript, si quelqu'un arrive à retrouver cela.
od†n ↗blah 10 février 2021 à 07:33 (CET)
J'ai trouvé ça : phab:T248416phab:T190083phab:T126137#2186236. Orlodrim (discuter) 10 février 2021 à 21:41 (CET)
Bon et bien s'il faut reprendre mes travaux d'il y a un an, j'avais fait un pense-bête !
Pour les Infobox V3, il y aura une quinzaine de pages à modifier.
Et comme il n'y a pas de raisons de le faire pour les V3 et pas pour les V2, je rappelle que j'en avais recensé 425.
--FDo64 (discuter) 10 février 2021 à 23:48 (CET)

Fonctions (P39)[modifier le code]

(Je poste le même message sur le Projet:Wikidata)
Bonjour,
Je constate un problème dans l'affichage des P39 (« fonction ») de Wikidata) de l'infobox Biographie2. On dirait que la fonction ne tient compte que de P580 (« date de début ») et non de P582 (« date de fin »). Voyez, par exemple, François Abadie (affichage ci-contre), où la fonction de ministre du Tourisme devrait être située avant celle de député.
Cela semble être lié au sortclaims de module:Wikidata. Pour l'affichage des fonctions, c'est l'option 'inverted', qui est censée mettre les entrées en ordre antéchronologique.
Il faudrait que cette fonction tienne compte de P582. Dans un ordre de ce genre :
1- Prioriser les fonctions qui n'ont pas de P582,
2- Prioriser les fonctions dont le P582 (et non P580) est le plus grand,
3- En cas d'égalité de P582, mettre en premier la fonction la plus longue (le plus petit P580).
Quelqu'un pourrait faire ça? - Simon Villeneuve 19 janvier 2021 à 14:46 (CET)

Bonjour Simon Villeneuve Émoticône
Actuellement les qualificatifs prises en compte, que soit pour le tri chronologique ou l'inverse, sont : P585 (« date »), P571 (« date de fondation ou de création »), P580 (« date de début »), P582 (« date de fin »), P1319 (« date au plus tôt »), P1326 (« date au plus tard »).
Je vais voir pour créer une fonction séparée chronoSortInverted qui prendra je pense : P585 (« date »), P571 (« date de fondation ou de création »), P582 (« date de fin »), P580 (« date de début »), P1326 (« date au plus tard »), P1319 (« date au plus tôt »).
Je ne suis pas sur pour l'instant pour ceux qui ont P580 et pas P582.
eru [Discuter] 28 mars 2021 à 12:01 (CEST)
Notification Simon Villeneuve : Voilà déjà une modification simple pour prioriser P582 (et P1326) : diff, voir : Modèle:Infobox Biographie2/Test#fonction : tri.
Je suis moins sur pour la deuxième modification : diff.
Cela semble donner de bons résultats avec le sandbox, mais il faudrait vérifier avec des exemples concret.
Cela devrait mettre dans l'ordre :
  1. Pas de date
  2. Pas de date de fin, date de début la plus ancienne
  3. Date de fin la plus récente
    1. Même date de fin et date de début la plus ancienne
P585 (« date ») & P571 (« date de fondation ou de création ») reste traité en priorité.
ps : je trouve l'utilisation de '111111111111111' pas terrible, donc l'hésiter pas à donner de meilleures idées.
eru [Discuter] 28 mars 2021 à 13:18 (CEST)
Bonjour eru Émoticône,
Wow, super! J'étais sûr que mon message était passé dans le beurre.
Ça marche très bien chez moi.
J'aimerais bien commenter l'histoire du '11111111111111', mais j'y comprends rien. - Simon Villeneuve 28 mars 2021 à 20:34 (CEST)
Notification Simon Villeneuve : Oui ça c'était plutôt pour les autres dev, par contre si tu as d'autre exemple tu peux les ajouter à Modèle:Infobox Biographie2/Test#fonction : tri pour vérifier. — eru [Discuter] 28 mars 2021 à 20:38 (CEST)

Infobulle dans la balise des modèles de révision - Module:Fix[modifier le code]

Bonjour. J'ai constaté une différence de traitement entre le modèle {{Fix}} et son équivalent anglais. Si on prend le passage Bonjour[réf. nécessaire], aucune infobulle apparaît, contrairement à Bonjour[réf. nécessaire] qui indique « Ce passage nécessite une référence » au survol du texte sur le surlignage.

Le modèle anglais Citation needed indique l'infobulle lorsqu'on cliquer sur la balise, serait-ce possible de faire pareil chez-nous ? Le surlignage n'est en effet pas toujours utilisé sur ce genre de modèle.

À noter que nous utilisons un module Module:Fix, pas eux et c'est donc lui qu'il faudrait revoir. Pensez-vous cela faisable ? -- Nemo Discuter 6 février 2021 à 22:58 (CET)

Bonjour,
Amha, faisable mais à voir si ça soulève des avis négatifs, par exemple sur le bistro. --LD m'écrire 6 février 2021 à 23:15 (CET)
Pour si c'est faisable. --l'Escogriffe (✉·✎) 8 février 2021 à 23:39 (CET)
Bonjour. Notification Nemo Le Poisson, LD et GrandEscogriffe. J'avoue que je ne vois pas quel est le problème actuel. Qu'appelles-tu « la balise » ? Si c'est le texte « [réf. nécessaire] » en exposant, il y a déjà sur cet élément une infobulle indiquant la page cible du lien interne, en occurrence Aide:Référence nécessaire, utile au contributeur/lecteur pour juger si le clic lui sera profitable, en fonction de son expérience sur Wikipédia. Quand le modèle {{Référence nécessaire}} est utilisé avec un paramètre suggéré « 1=… », l'infobulle est présente, non ?
Note technique : vous remarquerez, dans son code, qu'aujourd'hui, quand le paramètre 1 du modèle Fix est vide ou inexistant, le modèle ne passe pas par le module Lua. Cependant, techniquement, ce cas pourrait, avec le code actuel du module, déjà être géré. En gros, le test if:{{{1|}}} du modèle a pour seul avantage d’éviter l'exécution inutile du module, mais on aurait le même résultat en appelant le module dans tous les cas.
Propositions d'évolution du module/modèle :
  1. Est-ce que cela irait si le rendu était conservé, dans le cas où le paramètre 1 est renseigné et si dans le cas inverse on avait quelque chose dans ce style : « Bonjour(i)[réf. nécessaire] » ? Je peux me charger rapidement de la modification si elle est acceptée.
  2. A-t-il été envisagé que le modèle Fix place lui-même les crochets du message ? Après vérification, cette opération est dispensable. Seul le modèle {{Page needed}}, peu académique sur frwiki n'insère pas de crochets autour du message. Ce modèle, avec un nom en anglais, est non documenté, non catégorisé et peu utilisé. Peut-il être fusionné/remplacé par un autre déjà existant ?
Ideawipik (discuter) 9 février 2021 à 13:09 (CET)
Bonjour Ideawipik. Merci de cette proposition (point 1.), mais je pense qu'il n'est pas souhaitable de complexifier le rendu visuel de {{refnec}} et de lui faire prendre plus de place dans le texte.
A priori je suis plutôt pour ce que demande Nemo, c'est-à-dire, comme sur en:, afficher « Ce passage nécessite une référence (demandé le date) » lorsque {{{{1|}}} n'est pas rempli et qu'on survole la balise, surtout lorsque la date est indiquée. La date est une information assez utile pour juger de la qualité du passage. En fait ça dépend si "lien interne = infobulle donnant le titre de la page liée" est un principe toujours respecté ou si on peut faire des exceptions. Si on veut garder l'information que le clic envoie vers une page d'aide, peut-être « Ce passage nécessite une référence (date) ; voir l'aide. » ?
Je n'ai pas compris le début de ton point 2, est-ce que tu proposes de transférer l'ajout des crochets du code de {{refnec}}, {{non neutre}}, {{quand}} etc. vers celui de {{Fix}} ? Pourquoi pas.
Pour le 2.2., je ne sais pas quel autre modèle joue ce rôle. --l'Escogriffe (✉·✎) 9 février 2021 à 15:36 (CET)
@Ideawipik et @GrandEscogriffe
  • Une infobulle qui dit « Aide:Référence nécessaire » n'est pour moi pas une explication convenable pour un lecteur lambda. Les modèles de révision ont chacun un paramètre de texte d'infobulle à afficher, autant en profiter pleinement ! C'est également utile de connaître la date, comme le dit GrandEscogriffe (mis automatiquement avec VE).
  • C'est une très bonne idée de mettre les crochets de via le module Fix pour ne pas devoir le répéter à chaque fois ! Et j'en ai ajouté à {{Page à préciser}} ainsi qu'une doc. -- Nemo Discuter 9 février 2021 à 22:12 (CET)
« Ce méta-modèle est destiné à afficher un avertissement lié à un morceau de texte. » --> "Modèle:Avertissement sur texte" ? --l'Escogriffe (✉·✎) 24 février 2021 à 21:38 (CET)

┌─────────────────────────────────────────────────┘
Notification Nemo Le Poisson, LD et GrandEscogriffe
Point 1. L'ajout de la date dans la "nouvelle" infobulle était évidemment prévu dès le début, si date renseignée.
« "lien interne = infobulle donnant le titre de la page liée" » : Je trouve cela assez pratique et généré automatiquement par le logiciel. mais ce n'est pas forcément une obligation. On pourrait y faire exception au moins dans le cas ou le paramètre recommandé 1 n'est pas rempli. On peut aussi ajouter un « Voir l'aide. » dans tous les cas (a.) ou même seulement dans les cas où un lien interne est présent dans le « message » (b.). Y a-t-il des cas qui justifieraient ce dernier test ? Je ne suis pas convaincu qu'il faille trop compliquer le modèle. De plus, même s'il n'y a pas de lien présent, il y a (ou devrait y avoir) souvent une explication dans l'aide générale. Voici une première proposition. Modèle:Fix/Bac à sable. Cependant, il y a un petit souci en l'état en raison de la priorité pour l'infobulle interne générée par le wikitexte présent dans le paramètre du modèle. Lire l'explication et les questions ici. Vous pouvez y répondre ici ou là-bas.
Point 2. C'était bien l'idée, afin de simplifier la syntaxe peu naturelle et disparate des appels au modèle Fix. La seule différence de rendu serait que les crochets seraient hors du lien interne comme sur {{Passage contradictoire}} (dans sa version actuelle). Mais outre les modèles particuliers « Passage contradictoire », « {{Page needed}} », {{Nonspecific}} et {{Par exemple}}, presque tous les modèles possèdent dans leur code un lien avec des crochets imposés dans le libellé d'un lien. Il n'y a pas vraiment besoin de changer quelque chose qui marche. Donc la question se résume à choisir [réf. nécessaire] ou [réf. nécessaire]. Un détail esthétique qui dépend aussi des choix à faire pour mettre en œuvre le premier point. Autre question (juste histoire de peut-être simplifier un tout petit peu le code), est-ce que le paramètre message est obligatoire ou optionnel ? — Ideawipik (discuter) 10 février 2021 à 00:40 (CET)

@Ideawipik Si j'ai bien compris, c'est difficile de mettre un message sur un lien ? De ce que je vois, le paramètre message est obligatoire et est systématiquement utilisé. Et on peut effectivement rajouter un (Voir l'aide) si tu veux. Sinon assez neutre sur la question des crochets, je remarque qu'ils ne sont pas mis dans le lien sur enwiki. -- Nemo Discuter 18 février 2021 à 15:31 (CET)
Si ! On peut techniquement mettre une infobulle différente sur le lien en perdant celle indiquant la cible mais il faut adopter une autre syntaxe (exemple : page de Nemo Le Poisson). C'est un choix à faire et une question de moindre surprise, par rapport aux infobulles par défaut sur les liens internes. Veux-tu que je modifie le brouillon du modèle dans ce sens ? Edit : C'est pour ce faire que j'avais posé ces questions, afin de savoir quelles fonctionnalités on veut avoir/conserver dans le modèle. Si on veut modifier le modèle, le plus simple : un seul lien, un seul libellé et une seule infobulle sur tout le texte en exposant. — Ideawipik (discuter) 18 février 2021 à 15:41 (CET)
Notification Ideawipik : Un seul lien, qui couvre tout le message et qui soit uniquement interne me semble la meilleure chose Émoticône sourire. Et donc ce lien contiendrait aussi l'infobulle, qui s'afficherait également si du texte est souligné. Ya t-il des points qui doivent encore être éclairé ? -- Nemo Discuter 18 février 2021 à 19:54 (CET)
Bonjour Notification Nemo Le Poisson, LD et GrandEscogriffe. Nouvelle mouture au brouillon. L'infobulle a été ajoutée sur le texte en exposant, voire même dans/sur le lien interne, sous certaines conditions. Le modèle s'utiliserait désormais avec deux paramètres : message (obligatoire) et message_lien (facultatif, utile si la cible du lien diffère du paramètre précédent ou si le lien doit être désactivé par la valeur « non »). Est-ce mieux ainsi : Modèle:Fix/Bac à sable ? On est resté au plus près de l'existant sur le plan esthétique, mais on peut facilement modifier cela (cf annotations (« Choix », « Facultatif ») dans le code du brouillon du module et l'aperçu du Bac à sable avec sa version du 3 mars). Merci d'avance pour vos réactions. — Ideawipik (discuter) 4 mars 2021 à 13:53 (CET)
Bonjour et merci Ideawipik. J'ai ajouté sur le bac à sable un exemple qui reproduit le modèle refnec, sais-tu pourquoi le message est rejeté à la ligne ? Deuxième chose, est-ce qu'on pourrait mettre le bout de texte « voir l'aide » en fin d'infobulle, seulement sur le lien vers la page d'aide, pas sur du texte non-cliquable (ni sur le texte éventuellement donné par l'argument 1 =, ni sur le message lui-même quand il est rendu non-cliquable par message_lien =) ? --l'Escogriffe (✉·✎) 5 mars 2021 à 18:55 (CET)
Bonjour GrandEscogriffe. Réponse expresse. Le retour à la ligne est certainement dû a une petite différence connue entre les modèles et les modules. Les premiers retirent automatiquement les espaces et sauts de lignes à droite et à gauche des paramètres lus, tandis que les modules les prennent en considération dans leur globalité ie tout ce qu'il y a entre deux séparateurs (symboles égal et pipe ou accolades de fermeture). Voir précision plus bas. La différence s'avère parfois avantageuse dans un sens ou dans l'autre. Pour remédier au problème que tu as soulevé, il devrait suffire de traiter les paramètres dans le module (fonction strip et variantes), comme cela a été fait à quelques endroits dans le présent Bac à sable. Bien sûr que tout est possible, On peut bien avoir deux messages différents. Cependant, peut-être qu'il faudra revoir la structure de l’algorithme, qui devient touffue et peu naturelle. Je regarderai cela d'ici peu. — Ideawipik (discuter) 5 mars 2021 à 19:21 (CET)
  • Premier point. Le modèle dans sa version existante fonctionne déjà comme cela et ne pose pas de problème si on respecte la syntaxe recommandée dans la documentation. Voir explication et comparaisons sur brouillon du modèle. Comme le présent modèle est un méta-modèle, il n'a pas vraiment vocation à être utilisé directement dans un article donc peu de risques de syntaxe erronée. C'est le modèle intermédiaire comme {{Référence nécessaire}} qui "traite" le paramètre {{{1|}}}
  • Second point. Le « Voir l'aide. » a été supprimé de l'infobulle sur le texte (1) mais conservé sur l'exposant. C'est un bon compromis car : 1. Un exposant sans lien est très rare et peu probable ; 2. Même avec un message_lien =non, on peut introduire un lien en wikicode (texte "mixte") dans le paramètre message ; 3. Dans tous les cas, même sans lien, il devrait exister une aide relative au problème pointé par le modèle.
Est-ce que cela convient ? — Ideawipik (discuter) 5 mars 2021 à 23:47 (CET)
@Ideawipik Oui, pas de problème pour moi !
1. My bad, je n'avais pas fait attention. Pas très intuitif, mais bien documenté (d'autant plus avec tes ajouts sur le bac à sable), donc rien à changer.
2. Il y en a quelques modèles qui affichent actuellement un exposant sans lien : au moins {{Page à préciser}} et {{Nonspecific}} (modèle peu utilisé) cités plus haut. D'un autre côté, dans les deux ça a l'air d'être un mauvais paramétrage (lien = au lieu de message =) facilement corrigeable. Si on trouve d'autres modèles faisant appel à Fix sans proposer de page d'aide ou de règle, on pourra toujours rédiger une courte page d'aide spécifique comme Aide:Référence non conforme. Pour le coup j'aimerais éviter d'afficher un « voir l'aide » sans orienter vers une page d'aide, ce ne serait pas très aidant Émoticône. --l'Escogriffe (✉·✎) 6 mars 2021 à 00:56 (CET)
Finalement, n'y voyant pas de contre-indication, les deux points ont été pris en considération dans le brouillon du module.
Précision de la réponse précédente. La différence concerne uniquement les paramètres positionnels non nommés, pas les paramètres nommés. À savoir, mais pourquoi pas ? Plus étrange, les appels explicites de paramètres numérotés 1=, normalement équivalents aux paramètres positionnels sont considérés dans la seconde catégorie. Donc
{{…|
*mot|
et
{{…|1=
*mot|
ne sont pas interprétés de façon identique, le second l'étant comme {{|*mot| Lectures complémentaires : mw:Extension:Scribunto/Lua_reference_manual#frame.args et mw:Module:Arguments#Trimming and removing blanks. — Ideawipik (discuter) 6 mars 2021 à 15:25 (CET)
Salut @Ideawipik, et merci pour le brouillon que tu as mis en place, j'avais un peu perdu le fil de tout ça. Penses tu qu'il soit prêt à être appliqué au dit module Émoticône sourire ? -- Nemo Discuter 16 mars 2021 à 17:26 (CET)
Bonjour, conflit d'édit : j'allais dire la même chose Émoticône sourire. --l'Escogriffe (✉·✎) 16 mars 2021 à 17:30 (CET)
@GrandEscogriffe Belle coïncidence, dix jour après le dernier message ;) -- Nemo Discuter 16 mars 2021 à 19:59 (CET)
@Nemo Le Poisson On a tous les deux été notifiés sur cette page quelque minutes avant Émoticône. --l'Escogriffe (✉·✎) 16 mars 2021 à 20:08 (CET)

Bonjour Ideawipik et Nemo Le Poisson Émoticône. Je mets cela en place, en espérant avoir bien compris où ça ce se passe : voir ce remplacement et cette demande. Cordialment, --l'Escogriffe (✉·✎) 18 avril 2021 à 00:42 (CEST)

Bonjour @GrandEscogriffe, cela me paraît très bien, on y est enfin arrivé. Cordialement, -- Nemo Discuter 19 avril 2021 à 14:42 (CEST)

Aide pour le modèle Encart ?[modifier le code]

Bonjour. Est-ce que quelqu'un pourrait aider à résoudre un problème avec {{Encart}} ? Voir ici. Merci d'avance ! -- TwøWiñgš - [Formules de politesse parfois implicites, inutile de s'offusquer] - Et si on discutait ? 2 mai 2021 à 09:26 (CEST)

Bonjour TwoWings Émoticône En examinant la différence avec {{...}} juste avant, j'ai trouvé une solution en ajoutant "overflow: hidden;" : differu [Discuter] 2 mai 2021 à 09:52 (CEST)
Notification Eru : Youpi ! Merci beaucoup ! Cela faisait plusieurs fois que je cherchais de l'aide pour résoudre ce problème, donc merci mille fois ! -- TwøWiñgš - [Formules de politesse parfois implicites, inutile de s'offusquer] - Et si on discutait ? 2 mai 2021 à 10:15 (CEST)
Bonjour Eru et TwoWings Émoticône. Merci pour cette modif. Elle introduit tout de même (comme je l'ai signalé sur le Bistro) un passage à la ligne que jusque-là le modèle ne faisait pas. Il peut donc y avoir des cas où on se retrouve avec une mise en page qui n'était pas celle souhaitée par l'utilisateur. Cela dit, en consultant les pages liées au modèle, il ne semble y avoir peu ou pas de cas réellement gênants, donc mieux vaut avoir ce "problème" que celui des gros vides signalés par TwoWings.
Je signale tout de même à Salix le changement sur sa PU : encart passé à côté de la BU et non plus en-dessous. Insérer {{clr|left}} entre les deux ramènerait la mise en page précédente. Cordialement, --l'Escogriffe (✉) 2 mai 2021 à 19:09 (CEST)
@GrandEscogriffe effectivement dans l'exemple que j'ai pris cela ajoutait automatiquement un <p>, que j'ai remplacé par un <div>, mais ce n'est pas le cas si l'encart est dans une phrase.
On pourrait ajouter un display:inline; ou display:inline-block;, cela semble résoudre les deux problèmes. — eru [Discuter] 2 mai 2021 à 20:52 (CEST)
Euh non sur Vladislava Urazova ça fait revenir le vide. --l'Escogriffe (✉) 2 mai 2021 à 22:04 (CEST)
Mince, dans mon test rapide j'avais oublié de réduire la taille de la page... — eru [Discuter] 2 mai 2021 à 22:31 (CEST)

Ajouter un paramètre durée au modèle Lien web ?[modifier le code]

On pourrait mettre un paramètre durée pour les émissions et autres documents sonores, un peu l'équivalent du nombre de pages pour les documents écrits ? Zythème Paroles dégelées 18 juillet 2021 à 11:09 (CEST)

Bonjour à vous, soit j'ai le cerveau qui commence à ramollir, soit il y a un bug avec le module. Je ne parviens pas à comprendre pourquoi je ne peux pas remplacer une apostrophe droite en courbe en utilisant {{(FULL|SUB)PAGENAME}}. Exemple : modifiez la page ' en ajoutant : {{#invoke:String|replace|{{PAGENAME}}|'|’||true}} et prévisualisez. Rien n'a changé ! Pourtant {{#invoke:String|replace|'|'|’||true}} retourne bien .

Quelqu'un y comprend quelque chose ? R [CQ, ici W9GFO] 19 août 2021 à 09:50 (CEST)

Bon, je pense avoir mis la main sur le problème : voir ici. La question c'est comment réparer ? R [CQ, ici W9GFO] 19 août 2021 à 10:51 (CEST)
Bonjour R Émoticône,
En regardant les exemples que tu a mis {{PAGENAME}} retourne surement &#39; et non '.
La seul solution doit donc probablement de mettre {{#invoke:String|replace|{{PAGENAME}}|&#39;|}}eru [Discuter] 19 août 2021 à 19:16 (CEST)
Apparemment (cf. mw:Help:Magic_words/fr#Noms_de_page) c'est un bogue bien connu et la solution la plus simple pour contourner le problème serait d'utiliser #titleparts. J'ai testé ça fonctionne. Fallait-il le savoir ! Peut-être qu'un petit avertissement dans la documentation du module éviterait à d'autres d'avoir la même surprise. Qu'en pensez-vous ? R [CQ, ici W9GFO] 19 août 2021 à 20:15 (CEST)

Bonjour, cette demande d'intervention concerne l'ajout d'un paramètre accès url pour les deux modèles précités. Toutes les modifications à apporter sont résumées à la fin de cette section du Bistro du 13 février 2021 et ont été validées par plusieurs contributeurs. J'ai d'abord fait une DIPP et on m'a conseillé de me tourner vers cette page. Merci d'avance. – Bastoche* \Discuter\ 21 février 2021 à 11:30 (CET)

Salut @Bastoche*, en gros si j'ai bien compris faut rajouter un paramètre sur le Module:Biblio. Toujours pas de page d'aide sur comment rajouter un paramètre sur du Lua donc je sais pas t'aider, mais je me permet de remettre ton résumé pour que les expert en lua s'en chargent. Amicalement, -- Nemo Discuter 16 mars 2021 à 16:48 (CET)

Résumé de la demande à convertir en code Lua[modifier le code]

Rajouter un paramètre facultatif accès url sur Module:Biblio/Lien web et Module:Biblio/Article. Celui-ci doit faire apparaître un cadenas lorsqu'il contient l'une de ces valeurs :

  • Accès libre libre [par défaut] : la lecture est libre et gratuite pour tout le monde (qui ne doit pas apparaître s'il n'a pas été apposé)
  • Inscription nécessaire inscription: une inscription gratuite au site est nécessaire
  • Accès limité limité: une inscription gratuite et/ou d'autres contraintes limitent l'accès (ex: maximum 3 articles par semaine, visionnage d'une publicité nécessaire)
  • Accès payant payant ou abonnement: la source n'est accessible qu'en payant (paywall)
>> Ces icônes doivent apparaître juste après le lien concerné. À titre d'exemple :
  • Pour Lien web : Auteur, « Lien/Titre » Accès payant, sur site.net, Date (consulté le Date).
  • Pour Article : Auteur, « Titre », périodique/site,‎ Date (lire en ligne Accès payant).
- L'alternative textuelle des icônes étant :
  • Document en libre accès : Document en libre accès
  • Inscription nécessaire pour accéder au document : Inscription nécessaire pour accéder au document
  • Accès limité au document : Accès limité au document
  • Accès payant au document : Accès payant au document
Ces alternatives doivent apparaître en infobulle, comme c'est actuellement le cas avec les modèles unitaires (que sont accès payant Accès payant, inscription nécessaire Inscription nécessaire et accès libre Accès libre).
Merci Notification Nemo Le Poisson : d'avoir relancé le sujet et copié ici le résumé du Bistro. J'en profite pour notifier des pcW ayant participé aux discussions adjacentes : Notification Eru, Ideawipik, LD et GrandEscogriffe. Merci d'avance pour ce que vous pourrez faire. Cdt. – Bastoche* \Discuter\ 16 mars 2021 à 17:09 (CET)
Pourquoi en tant que paramètre facultatif ? Les conditions d'accès à l'information me semble être une information cruciale. Lofhi (discuter) 16 mars 2021 à 19:01 (CET)
Bonjour Notification Lofhi : Il a été décidé que le paramètre devait être facultatif, dans le sens où il n'apparaît pas opportun d'apposer le cadenas Accès libre tout le temps. En effet, on considère que par défaut, n'importe quelle source est accessible, et qu'elle ne doit être suivie d'aucun cadenas (donc statu quo). Le cadenas vert n'est apposé que dans certains cas concernant des références biblo (voir actuellement les pages liées au modèle) et les autres cadenas sont apposés dans les cas correspondants.
C'est donc pourquoi le paramètre se doit d'être facultatif, puisque, s'il n'est pas complété, la source est considérée comme libre par défaut, mais sans qu'un cadenas n'apparaisse.
Espérant avoir été compréhensible Émoticône… Cdt. – Bastoche* \Discuter\ 16 mars 2021 à 19:17 (CET)
Très bon travail, merci à vous d'avoir investi de votre temps ! Émoticône sourire --LD m'écrire 16 mars 2021 à 20:27 (CET)
Voir mon brouillon @Bastoche*. Lofhi (discuter) 18 mars 2021 à 00:09 (CET)
Notification Lofhi : Ça m'a l'air parfait ! Tout du moins, je n'ai vu aucun problème Émoticône. – Bastoche* \Discuter\ 18 mars 2021 à 00:12 (CET)
Salut @Lofhi, j'avais oublié de préciser qu'il existe déjà des modèles pour les différents icônes avec leurs alternatives textuelles : {{Accès libre}}, {{Inscription nécessaire}}, {{Accès limité}} et {{Accès payant}}, je ne sais pas si c'est mieux de directement faire appel à eux. Cordialement, -- Nemo Discuter 20 mars 2021 à 11:13 (CET)
Notification Nemo Le Poisson : L'idée est de peut-être supprimer ces modèles unitaires, lorsque l'ajout dans Lien web et Article sera fait, puisqu'ils deviendront inutiles. C'est pourquoi, s'il est possible de faire sans, c'est mieux Émoticône. – Bastoche* \Discuter\ 20 mars 2021 à 20:43 (CET)
Bonsoir Notification Lofhi : Avez vous la possibilité de publier ce que vous avez proposé sur votre brouillon ? Merci d'avance. – Bastoche* \Discuter\ 26 mars 2021 à 23:57 (CET)
Bonsoir @Od1n, si tu as le temps, est-ce que tu pourrais regarder rapidement les modifications apportées sur les bacs à sable des modules concernés ? Merci. Lofhi (discuter) 27 mars 2021 à 02:37 (CET)
Bonjour Notification Lofhi et Od1n : Je relance avec un petit coup de notif Émoticône Il me semble que le bac à sable a été relu... Qu'en est-il Émoticône Merci d'avance pour votre aide. Cdt. – Bastoche* \Discuter\ 4 avril 2021 à 17:41 (CEST)
@Bastoche* : Od1n a l'air occupé, je proposerai les changements aux administrateurs quand je serai convaincu de mes modifications. Lofhi (discuter) 13 avril 2021 à 17:35 (CEST)
Bonjour Notification Lofhi : J'attendais en fait votre retour pour que vous publiez les modifications... En effet, @Od1n est intervenu plusieurs fois sur le bac à sable : une première fois lors du dépôt de votre message du 27 mars ([3] et [4]) et une deuxième fois lors de mon message du 04 avril ([5]). C'est pourquoi j'ai tendance à penser qu'il a relu et "validé" les modifs... – Bastoche* \Discuter\ 13 avril 2021 à 18:02 (CEST)
Ah oui, je suis bigleux. Je le remercie s'il passe par là (évitions les notifications agaçantes). Lofhi (discuter) 13 avril 2021 à 21:33 (CEST)
Effectivement j'étais simplement passé apporter quelques retouches, sans exprimer d'avis sur le fond, mais cette fonctionnalité me parait tout à fait appréciable et le code m'a l'air correct. od†n ↗blah 14 avril 2021 à 00:11 (CEST)
Notification Lofhi et Od1n : Merci à vous deux pour vos réponses et désolé pour la notif (Smiley oups)...
Simplement pour vous signaler que j'ai corrigé les documentations en conséquence [6] et [7] donc je vous invite déjà à relire voir si ça convient (sachant qu'au moment où j'écris, il manque juste à corriger la page WP:Accès url pour préciser les quelques exceptions).
Et par la suite donc publier le bac à sable. Merci d'avance. Cdt. – Bastoche* \Discuter\ 14 avril 2021 à 19:58 (CEST)

┌─────────────────────────────────────────────────┘
Bonjour @Bastoche*, @Lofhi et @Od1n, si j'ai bien compris il suffit maintenant de publier Module:Biblio/Lien web/Bac à sable et Module:Biblio/Article/Bac à sable... Ya t-il encore des vérifications à faire avant qu'on puisse demander à un administrateur de s'en charger ? (Où à qq qui dispose directement des droits Émoticône sourire) -- Nemo Discuter 19 avril 2021 à 14:32 (CEST)

Bonjour Notification Nemo Le Poisson : La DIPP a déjà été déposée, et, si j'ai bien compris, tout a correctement été publié... Cdt. – Bastoche* \Discuter\ 19 avril 2021 à 14:37 (CEST)
Ah bah super ! -- Nemo Discuter 19 avril 2021 à 14:41 (CEST)
Merci quand même pour votre aide ÉmoticôneBastoche* \Discuter\ 19 avril 2021 à 14:52 (CEST)

┌─────────────────────────────────────────────────┘
La documentation est à mettre à jour, les bots ne sont pas au courant de ce paramètre, cf Discussion utilisateur:NicoV#paramètre access=free sur Leopoldina Fortunati. — eru [Discuter] 4 octobre 2021 à 08:45 (CEST)

N.B. Mon bot l’est, et il a transformé les consulté le=free en accès url=libre. Il pourra éventuellement retoucher les access=free vers accès url=libre également. — LD (d) 4 octobre 2021 à 14:50 (CEST)

Anciennes version de Vega[modifier le code]

Bonjour,

Pour info, il va falloir arrêter d'utiliser la version 1.5 de Vega. Or fr: semble être un gros utilisateur de cette version. Je sais pas comment trouver cette info. Voilà le ticket correspondant https://phabricator.wikimedia.org/T260542 Pyb (discuter) 17 octobre 2021 à 10:12 (CEST)

Hello, si je comprends bien le ticket ça venait essentiellement de {{Histogramme à 4 classes pour spéléométrie départementale}} et ça aurait été réglé par ce diff. — Kvardek du (laisser un message)(pronom : iel, mode d'emploi) le 17 octobre 2021 à 12:15 (CEST)

Modèle Gallery[modifier le code]

Je ne sais pas si je suis au bon endroit pour poser une question. Je trouve dommage que dans ce modèle l'utilisation du paramètre footer force l'alignement à gauche. Ce serait bien de pouvoir utiliser footer pour une légende globale des images tout en conservant l'alignement désiré des images, notamment centré. Cordialement, — Racconish💬 25 octobre 2021 à 19:51 (CEST)

Bonjour Racconish. Pour être franc, je ne vois pas vraiment quelle est la plus-value de ce modèle {{Gallery}} (environ 2 000 inclusions) par rapport à la balise <gallery>, ni l'intérêt de ce "footer" présent dans une petite quinzaine d'articles (wstat.fr), surtout quand sa valeur est « Texte sous les images ». — Ideawipik (discuter) 25 octobre 2021 à 20:49 (CEST)
Tu ne réponds pas à ma question mais je réponds à la tienne Émoticône sourire. Le modèle gallery permet certaines choses qu'une galerie ne permet pas, par exemple un meilleur affichage d'images de largeurs différentes avec une hauteur constante. Cordialement, — Racconish💬 26 octobre 2021 à 10:27 (CEST)
Merci Racconish pour ta réponse. Il reste que la balise est bien plus accessible que le modèle et ses tableaux imbriqués. Si une image est large avec une faible hauteur, le mode="packed" peut être adéquat pour la balise. D'ailleurs, la pertinence du modèle était déjà questionnée en 2013 (discussion Plus-value de ce modèle aujourd'hui ?).
Dans le modèle, le contenu du paramètre footer est aligné à droite. En quoi est-ce problématique ? On peut bien entendu changer l'alignement dans le modèle. Mais il semble inutile d'ajouter un paramètre au modèle pour ce détail esthétique d'un élément (footer) réellement utilisé dans huit articles et encore… Parfois, la donnée serait aussi bien en titre avant les images (paramètre title du modèle ou caption de <gallery>). Dans l'attente d'autres avis. Notification Cantons-de-l'Est, Philippe rogez et Tractopelle-jaune ? — Ideawipik (discuter) 26 octobre 2021 à 14:37 (CEST)
Dans certains cas, le mode packed convient bien, dans d'autres moins bien. Plus généralement, il me semble que le consensus antérieur était pour la coexistence des deux possibilités et je trouve un peu dommage de tirer ma question, qui porte sur un autre aspect, dans le sens d'un choix que rien n'impose, rien ne t'interdisant ,ni à personne, de préférer galerie. Cordialement, — Racconish💬 26 octobre 2021 à 14:56 (CEST)
En ce qui concerne la position du footer, je pense que Racconish a raison : elle devrait pouvoir être modifiable à volonté. Si c'était le cas, peut-être que le paramètre footer serait plus utilisé. Je crois avoir utilisé quelques fois {{Gallery}}, mais j'ai cessé parce qu'il ne présentait pas d'avantages certains comparativement à <gallery>. — Cantons-de-l'Est p|d|d [‌sysop] 26 octobre 2021 à 18:18 (CEST)
Un paramètre footerposition vient d'être ajouté au modèle ; valeurs possibles : left, right, center (ou centre) ; par défaut à droite, comme avant. Racconish, tu peux tester. Cordialement. — Ideawipik (discuter) 26 octobre 2021 à 19:04 (CEST)
Merci beaucoup. Hélas, ça ne marche pas : tout comme avant la présence du footer modifie le choix d'alignement centré des images, qui deviennent ferrées à gauche. Subsidiairement, il y a un petit problème d'interligne trop petit en cas de présence de notes. Ci dessous un exemple pour me faire comprendre. En revanche, sur le conseil de ManiacParisien, j'ai essayé le modèle Images qui fait le job. Cordialement, — Racconish💬 26 octobre 2021 à 19:58 (CEST)

Bug sur la franchise dans Infobox Jeu vidéo ?[modifier le code]

Bonjour, j'espère que je suis au bon endroit pour remonter ce genre de problème Émoticône sourire

Je pense avoir trouvé un bug dans l'Infobox Jeu vidéo. En effet, si j'en crois le code du module, on devrait pouvoir récupérer les champs "franchise", "précédent" et "suivant" depuis Wikidata (respectivement P179, P155 et P156) (voir la fonction buildsuccession).

Cependant, en faisant des tests sur l'article GTA V (wikidata), il semble que l'infobox n'affiche pas ces champs s'ils ne sont pas remplis dans localement.

Est-ce que quelqu'un pourrait investiguer/réparer ce soucis ?

Merci ! Alex (discuter) 26 octobre 2021 à 11:59 (CEST)

Bonjour AlexRNL Émoticône
Apparemment ce modèle ne prend le "précédent" qu'en qualificateur de P179 (« série »), il serait mieux que les deux soient gérés car les imports de enwiki sont rarement (malheureusement) mis dans P179.
Tu peux demander l'amélioration de l'infobox sur Projet:Infobox, mais j'ai déjà mis à jour Q17452 (« Grand Theft Auto V »). — eru [Discuter] 8 novembre 2021 à 19:24 (CET)

Pour informations j'ai mis à jour les modules Module:Dictionnaire Wikidata/Codes langue & Module:Dictionnaire Wikidata/Codes langue/inversé et leur méthode de mise à jour, l'ancienne url http://wdq.wmflabs.org/api?q=CLAIM[424]%20and%20claim[31:34770]4] ne fonctionnant plus. — eru [Discuter] 8 novembre 2021 à 19:15 (CET)

Traduction du modèle anglophone "citation"[modifier le code]

Bonjour ; je me proposais (cf cette section du Bistro) de traduire le modèle En:Template:citation (uniformisant les modèles {{ouvrage}}, {{article}}, etc.), mais il s'avère qu'il est écrit en Lua, et que je ne sais même pas où chercher le code qui va bien (et ne parlons pas de le traduire). On m'a suggéré de venir ici demander de l'aide ; une âme charitable viendra-t-elle à mon secours ? Au pire, je peux me débrouiller si on me fournit un mode d'emploi complet, genre : où sont les fichiers, où est la documentation pour Lua et/ou Scribunto, etc. , mais je ne me plaindrai pas si un Bon Samaritain fait le travail à ma place Émoticône sourire.--Dfeldmann (discuter) 15 novembre 2021 à 13:59 (CET)

Salut @Dfeldmann, pour info, le module anglophone est Citation/CS1 (et son css : style.css).
L'ensemble de la documentation Lua est, me semble-t-il, disponible sur son site. Pour l'extension Scribunto, cette page me semble être la plus adéquate.
Du reste, je n'y connais pas grand chose à ce langage (je ne saurais donc t'aider davantage, désolé) et je n'ai pas d'avis sur le fond (la pertinence, intérêt) d'uniformiser les modèles. Bon courage ^^ ! LD (d) 15 novembre 2021 à 14:07 (CET)
Merci, @LD ; je vais essayer de mme débrouiller ; a priori (cf le Bistro), c'est plutôt une bonne idée, ne serait-ce que pour pouvoir traduire plus facilement les interwikis. Cordialement,--Dfeldmann (discuter) 15 novembre 2021 à 14:30 (CET)

débugagge de Module:Infobox/Établissement scolaire[modifier le code]

Bonjour, j'ai créé Module:Infobox/Établissement scolaire mais il y a un bug que je en trouve pas. Quelqu'un peut jeter un œil ? --GdGourou - Talk to °o° 18 novembre 2021 à 08:42 (CET)

Aligner des boutons[modifier le code]

Bonjour,

J'aimerais aligner les boutons "En savoir plus", par exemple en bas des cartes. Est-ce faisable ?

Si oui, je dupliquerai le modèle de la Fondation que j'utilise, on va éviter de modifier leur feuille de style Émoticône

Pyb (discuter) 22 novembre 2021 à 00:32 (CET)

Bonjour Pyb Émoticône, pour un alignement à la marge, ça doit être :
.main-button {
	text-align: bottom;
}
Bien à toi, LD (d) 22 novembre 2021 à 00:49 (CET)

Bonjour, Je ne trouve pas dans le code " localité allemande " et ce n'est pas la même chose qu'Allemagne. Sauriez vous trouver ? Merci. Manjiro91|💬 24 novembre 2021 à 15:45 (CET)

@Manjiro91, cette demande est déjà plus claire que celle en WP:DPP ! Émoticône sourire
cf. :
a["allemand"] = {
	sujet = "[[Allemagne|allemand]]",
	icone = "Nuvola German flag.svg",
Lignes 9071-9073. C'est ce fichier qui est utilisé par Abteilung par exemple. — LD (d) 24 novembre 2021 à 16:00 (CET)

@LD Ou par Bad Rippoldsau-Schapbach 😉 Manjiro91|💬 24 novembre 2021 à 16:06 (CET)

Stations de métro voisines et Wikidata[modifier le code]

Bonjour, je suis une quiche en Lua. Quelqu'un aurait du temps pour construire un petit modèle de recherche de gare voisine sur la P197 + terminus P5051 pour une ligne P81 ou un service P1192 donné? avec une petite mise en forme (flèches de directions par ex s'approchant du rendu de ce modèle enwiki https://en.wikipedia.org/wiki/Template:Adjacent_stations#Examples ) ? Bouzinac (discuter) 3 décembre 2021 à 10:00 (CET)

Bonjour Bouzinac Émoticône,
Je pense que le premier problème que tu as est qu'il faut importer sur frwiki tous les sous modules de enwiki : https://en.wikipedia.org/w/index.php?search=Adjacent+stations%2F&title=Special%3ASearch&fulltext=1&ns828=1
Pour le module voici un exemple rapide : Module:Stations voisines
{{#invoke:Stations voisines|main|Q892189|Q961290}} :
Nord/Ouest Bond StreetVoir et modifier les données sur Wikidata Sud/Est
Baker Street
vers Stanmore
ligne Jubilee Green Park
vers Stratford

eru [Discuter] 8 décembre 2021 à 19:48 (CET)

Hello Eru (d · c · b), merci pour ton intérêt! Je ne comprends pas ta remarque sur les sous-modules de enwiki, car ils ont tous l'inconvénient d'être des fichiers texte statiques reposant très peu sur Wikidata, énormément sur des lien enwiki donc peu pertinent/peu réutilisables côté frwiki ; et donc c'est pourquoi j'aurais souhaité un modèle qui recherche s'il y a du contenu Wikidata, qui est sur un format universel, (et n'affiche rien s'il y a absence de donnée WD)...
Concernant ton test, super, c'est un good start :) Il recherche ce qu'il y a comme gare voisine pour Bond Street (d) Voir avec Reasonator sur la ligne ligne Jubilee (d) Voir avec Reasonator ? Y aurait-il moyen de mettre en forme le résultat ? Comment gérer les cas particuliers (nombreux... lignes circulaires, lignes avec multiples destinations, lignes au sens service et non pas ligne de chemin de fer, Bond street est un bon exemple : https://www.wikidata.org/wiki/Q892189#P197 ) .... ? Ce serait cool d'avoir une mise en forme approchant ces wikis
C'était par rapport à l'erreur que tu as ici Modèle:Stations voisines, passé par wikidata permettra effectivement d'éviter cette liste de sous-module.
Il y a beaucoup de mise en forme à ajouter, il manquerai ici une info sur wikidata, quelle est la gare précédente et suivante, il faut mieux éviter de se baser sur l'ordre par défaut.
Pour pouvoir formater comme l'on veut, à la place de stringTable il faudrait sans doute mieux utiliser directement getClaims et boucler dessus soi-même : Spécial:Diff/188692384
{{#invoke:Stations voisines|main|Q892189}}
Nord/Ouest Bond StreetVoir et modifier les données sur Wikidata Sud/Est
Marble Arch
vers West Ruislip / Ealing Broadway
ligne Central Oxford Circus
vers Epping / Hainault / Woodford
Baker Street
vers Stanmore
ligne Jubilee Green Park
vers Stratford
Reste à construire le html autour.
J'essaierai de regarder un peu plus loin ce week-end, je peux générer un tableau wiki et utiliser les mêmes class que Modèle:Desserte LUL/débuteru [Discuter] 8 décembre 2021 à 22:03 (CET)
ps : à part les couleurs, cela limite à Londres apparemment. — eru [Discuter] 8 décembre 2021 à 22:06 (CET)
Ben non, une très grande majorité de stations de métro (côté WD) sont peuplées avec gares voisines, directions, lignes (ou service) concernés, couleurs HTML de ligne ex random https://www.wikidata.org/wiki/Q3296869#P197 pour les stations et https://www.wikidata.org/wiki/Q1044919#P465 pour les couleurs de lignes . Ce qui permet par exemple de créer des cartes cool comme celle-ci (dsl pour la longueur du lien... https://query.wikidata.org/embed.html#%23title%3A%20Carte%20du%20M%C3%A9tro...Bouzinac (discuter) 8 décembre 2021 à 22:13 (CET)
Conflit d’édition a je vois que pour la couleur on pourra aller chercher P465 (« couleur (triplet hexadécimal sRGB) ») sur la ligne. — eru [Discuter] 8 décembre 2021 à 22:14 (CET)
C'est juste que pour afficher Baker Street > Green Park ou Green Park > Baker Street il faut ce fier à l'ordre et non à un qualifier, ce n'est pas grave si c'est bien remplit.
Ca n'a d'ailleur peut être pas d'importance ? — eru [Discuter] 8 décembre 2021 à 22:21 (CET)
[dans l'hypothèse où tu es dans l'article Bond Street], l'ordre n'a pas énormément d'importance qu'on ait
station précédente London Underground station suivante
Green Park

vers Straford

  Jubilee Line   Baker Street

vers Stanmore

ou
station précédente London Underground station suivante
Baker Street

vers Stanmore

  Jubilee Line   Green Park

vers Straford

si c'était bien là le sens de ta question ? Bouzinac (discuter) 8 décembre 2021 à 22:28 (CET)
Tout à fait, merci. — eru [Discuter] 8 décembre 2021 à 22:29 (CET)
Bonjour @Bouzinac, presque bon je pense : Utilisateur:Eru/Brouillon#Autres
Reste à gérer l'image qui est présente ici Modèle:Desserte LUL/lien, mieux serait de l'avoir sur wikidata mais je ne sait pas où, sinon il faudra voir s'il est possible de prendre un svg et de changer sa couleur.
Il me faudrait également des exemples avec P1192 (« service de transport ») à la place de P81 (« ligne de transport »), les exemples que j'ai ne l'ont pas en qualifier mais directement sur l'item. — eru [Discuter] 9 décembre 2021 à 21:09 (CET)
Hello, waouh ça semble un super truc bien propre! je me suis permis de rajouter qq exemple tests sur ta page. Pour les logos, c'est relativement bien renseigné sur WD avec la propriété ex https://www.wikidata.org/wiki/Q203030#P154 Bouzinac (discuter) 9 décembre 2021 à 21:19 (CET)
Merci, je vais regardé les erreurs avec les exemples et voir pour P154 — eru [Discuter] 9 décembre 2021 à 22:11 (CET)
Voilà @Bouzinac : Utilisateur:Eru/Brouillon#Autres
On pourrait choisir d'avoir réseau ou ligne en titre en fonction du type.
Pour avoir Terminus à gauche il faut prendre l'exemple de Q601484 (« Châtelet »), no value, sinon il est forcément à droite.
L'appel à une ligne directement ne retourne forcément rien, elles n'ont pas de P197 (« gare voisine »)eru [Discuter] 9 décembre 2021 à 22:55 (CET)
C'est très cool comme rendu : mes suggestions :
  • grossir un chouia le logo de la ligne
  • "station" plutôt que "arrêt" en vocabulaire
  • est-ce utile de laisser "réseau ou ligne" en titre de colonne?
Je ne comprends pas trop ta remarque sur "L'appel à une ligne directement ne retourne forcément rien, elles n'ont pas de P197 (« gare voisine ») " Tu as un exemple de ligne de métro dans une wiki où y a un tableau automatique pour les stations de ladite ligne  ? Bouzinac (discuter) 9 décembre 2021 à 23:09 (CET)
Pour les textes et la taille j'ai tous copié sur {{Desserte LUL}}, on peut mettre ce que l'on veut.
Pour la ligne tu a ajouté en exemple {{#invoke:Stations voisines|main|Q3239098}}, c'est normal qu'il n'y ait pas de résultat.
Pour Q1284426 (« Edgware Road ») il y a trois stations sur la ligne Q210321 (« ligne Circle »), le code ne prend que la 1ere et la dernière. Je vois que tu viens de corriger wikidata :) — eru [Discuter] 9 décembre 2021 à 23:16 (CET)
absolument, c'est un peu le merdier côté WD encore...
Paris, par contre, devrait être propre
surement une erreur de copier coller pour Q3239098 (désolé pour la confusion) Bouzinac (discuter) 9 décembre 2021 à 23:18 (CET)
Conflit d’édition J'ai modifié les textes : Spécial:Diff/188727820, tu peux ajuster le module si tu veux. — eru [Discuter] 9 décembre 2021 à 23:19 (CET)
Voici la page de pré-prod : Utilisateur:Bouzinac/BrouillonLondres Bouzinac (discuter) 9 décembre 2021 à 23:36 (CET)
Il faudrait peut être trier les lignes en ordre alphabétique pour qu'elles s'assemblent à la suite, exemple de
Nord/Ouest Green ParkVoir et modifier les données sur Wikidata Sud/Est
Bond Street
vers Stanmore
ligne Jubilee Westminster
vers Stratford
Hyde Park Corner
vers Uxbridge / Heathrow terminal 5
ligne Piccadilly Piccadilly Circus
vers Cockfosters
Oxford Circus
vers Walthamstow Central
ligne Victoria Victoria
vers Brixton
Bouzinac (discuter) 9 décembre 2021 à 23:38 (CET)
Ah oui mais non y a une erreur qq part : Piccadilly devrait être une seule ligne avec Hyde Parc Corner <<< et Picaddilly circus de l'autre ? Bouzinac (discuter) 9 décembre 2021 à 23:42 (CET)
a oui, actuellement si cela ne ce suit pas sur wikidata cela pose problème, j'optimiserai cela. — eru [Discuter] 9 décembre 2021 à 23:47 (CET)
Conflit d’éditionOk, je regarderai demain.
J'ai ajouté un linkback "modifier Wikidata", c'est une mention obligatoire pour le mettre dans le corps d'articles. J'essairai de le rendre un peu plus discret. — eru [Discuter] 9 décembre 2021 à 23:44 (CET)
non, c'est super, pour être user-friendly (le wikipédien lambda étant plutôt méfiant vis à vis de wikidata) Bouzinac (discuter) 9 décembre 2021 à 23:53 (CET)
ok, j'ai juste diminué le padding top. — eru [Discuter] 10 décembre 2021 à 00:00 (CET)
j'allait oublier, pour la ligne 7 sur Q11265 j'ai mis les deux logos, si c'est préférable on peux mettre juste le 1er. — eru [Discuter] 10 décembre 2021 à 00:02 (CET)
je n'ai pas de religion sur le pb des multiples logos possible (en l'occurence c'est pour distinguer le service de jour vs service de nuit...)
Sinon brouillon dispo aussi pour Paris Utilisateur:Bouzinac/BrouillonParis Bouzinac (discuter) 10 décembre 2021 à 00:11 (CET)
tu penses pouvoir masquer la couleur côté terminus? n'avoir qu'une petite bande de couleur que s'il ya une station voisine? Bouzinac (discuter) 10 décembre 2021 à 00:13 (CET)
Oui ça ne posera pas de problème — eru [Discuter] 10 décembre 2021 à 08:24 (CET)
┌─────────────────────────────────────────────────┘
Bonjour Bouzinac Émoticône,
J'ai renommé le module Module:Stations voisines et je l'ai activé dans le modèle, je te propose de continuer à en discuter sur la pdd Discussion modèle:Stations voisines.
Je vais copier l'historique là-bas. — eru [Discuter] 10 décembre 2021 à 18:13 (CET)

éditeur de code[modifier le code]

Bonjour,

Quel éditeur utilisez-vous pour les modules ?

WikEd a pas mal de problèmes et je n'ai pas trouvé d'éditeur lourd qui permettent de tester le code facilement sur wp, voir d'avoir de l'autocomplétion. — eru [Discuter] 8 décembre 2021 à 19:08 (CET)

Oubliez, je viens de me rendre compte que l'éditeur de base avait un mode code qui faisait pas mal de choses... il manque juste la fonction de clic sur un module qu'avais WikEd. — eru [Discuter] 15 décembre 2021 à 22:21 (CET)

Nouveau module[modifier le code]

Bonjour, serait il possible de créer un nouveau module semblable à Module:Bouton cliquable 2, avec une légère différence : pouvoir ajouter une icône à gauche du texte ? Merci d'avance. Manjiro91 8 janvier 2022 à 15:25 (CET)

Problème avec le module Bases astronomie[modifier le code]

Bon samedi !
Quelqu'un sait comment corriger le {{module:Bases/astronomie}} pour que les crochets d'un identifiant Wikidata ne soient pas identifiés comme des balises wiki, comme par exemple ici, qui ne digère pas ça ? - Simon Villeneuve 30 janvier 2022 à 03:35 (CET)

✔️ Et voilà ! Le problème remontait en fait au module Wikidata : 190364755 (et hotfix : 190364830). od†n ↗blah 30 janvier 2022 à 07:01 (CET)

Merci! - Simon Villeneuve 30 janvier 2022 à 12:21 (CET)

Encoding des slash[modifier le code]

Salut, hier j'ai remarqué un bug sur l'encoding des slashes dans les urls issues de wikidata. Sur Wikidata rien n'a changé et dans le module bases sport non plus donc je pense que c'est un pb de parsing et la modif de la section suivante me semble un bon responsable.
Avant dans l'article Anthony Edwards (basket-ball) (c'est vrai pour tout ceux que j'ai vérifié), l'url (dans la section Liens externes) était

<a rel="nofollow" class="external text" href="https://www.basketball-reference.com/players/e/edwaran01.html">Basketball Reference <small>(joueurs de la NBA)</small></a> et maintenant c'est
<a rel="nofollow" class="external text" href="https://www.basketball-reference.com/players/e%2Fedwaran01.html">Basketball Reference <small>(joueurs de la NBA)</small></a>

Et l'url ne se résout pas correctement. Est-ce que qqn a saurait corriger ? Sinon je regarde mais y'a bcp de code et je sais pas comment tester proprement. Bonne journée, (:Julien:) 1 février 2022 à 12:13 (CET)

Bonjour (:Julien:). Si cela peut t'aider, on a dans le Module:Bases un val = wikidata.formatStatements qui sollicite le module:Wikidata. Ce dernier a récemment été modifié (avec l'ajout d'un encodage) par Od1n qui saura rectifier le tir, compte tenu de tes remarques. — Ideawipik (discuter) 1 février 2022 à 14:53 (CET)
✔️ Effectivement, voilà qui est corrigé. Refs un peu de lecture à propos du path component, où on voit bien que le caractère "/" a un rôle prépondérant. od†n ↗blah 2 février 2022 à 03:58 (CET)
Merci à tous les deux ! Bonne journée, (:Julien:) 3 février 2022 à 08:40 (CET)

Infobox : bug de gestion de qualificateurs multiples[modifier le code]

Monique Hanotte
une illustration sous licence libre serait bienvenue
Biographie
Naissance
Décès
Voir et modifier les données sur Wikidata (à 101 ans)
NivellesVoir et modifier les données sur Wikidata
Autres informations
Distinctions

Bonjour,

Quelqu'un est capable de résoudre ce bug ? Je le reproduis ci-contre. --l'Escogriffe (✉) 22 février 2022 à 22:35 (CET)

Je viens d'effectuer ceci. od†n ↗blah 23 février 2022 à 03:02 (CET)
Merci à Od1n d'avoir réglé le problème. l'Escogriffe (✉) 24 février 2022 à 23:37 (CET)

Bonjour, je suis tombé sur Special:Permalink/190846580#Liens externes (capture d'écran), la première ligne générée par le modèle n'a pas de puce, l'ajout d'une puce avant le modèle résout le problème et je compte passer mon bot pour ajouter les puces manquantes avant ce modèle, mais je préfère venir demander votre avis avant. — Thibaut (discuter) 24 février 2022 à 20:55 (CET)

Bonjour Thibaut. Pour la cohérence avec le modèle {{Liens}}, je partage l'avis d'Od1n, émise dans une ancienne discussion (Petite régression d'affichage : ligne à puce parasite) : « j'aime bien l'idée qu'il fonctionne aussi bien en faisant {{Bases}} ou * {{Bases}} ». Ou, par défaut, que l'on n'ait pas besoin de mettre de puce *. En sachant qu'une simple modification sur Wikidata peut ajouter à tout moment l'insertion d'un nouvel item de liste via ce modèle, existe-t-il réelement des cas où on souhaiterait sciemment l'absence du premier élément de liste ? — Ideawipik (discuter) 24 février 2022 à 22:18 (CET)
L'idéal ce serait d'utiliser {{Liens}} à la place d'{{Autorité}} ou encore {{Bases}}. Jérémy-Günther-Heinz Jähnick (discuter) 17 mars 2022 à 08:37 (CET)

Importation de Module:Listen[modifier le code]

Bonjour. Je pense qu'il serait très utile d'importer sur WP:fr https://en.wikipedia.org/wiki/Module:Listen Car les boites de lecture de son sont très frustres sur fr, et en ce moment cassées (affiche une barre grise). Mais bon, même si on le répare, c'est loin de la richesse de https://en.wikipedia.org/wiki/Template:Listen . Je le ferais bien, mais il y a des dépendances local mFileLink = require('Module:File link') local mTableTools = require('Module:TableTools') local mSideBox = require('Module:Side box') et j'ai l'impression que on va, de fil en aighuille, importer tous les module WP:en. Qu'en pensez-vous ? Est-ce que on tire trop de choses ou peut-on se raccorder à des modules fr ? Quelle stratégie pour l'importer ? Si vous le faites en brut, je peux ensuite l'adapter en français. Jean-Christophe BENOIST (discuter) 8 avril 2022 à 21:57 (CEST)

Bon. Tant pis. Ou alors je me lance, j'importe tout à la chaine, sans savoir où cela va s'arrêter. Avec un peu de chance cela ne mènera pas trop loin, quitte à laisser tomber au milieu si cela mène trop loin. On verra. Jean-Christophe BENOIST (discuter) 10 avril 2022 à 18:47 (CEST)

nosave pour Coord × 1000+[modifier le code]

Les pages de listes avec de très nombreuses coordonnées (plus de 1000) se retrouve régulièrement dans Catégorie:Page avec des erreurs de script à cause d'un temps lua dépassé, par exemple Liste des cantons québécois.

D'après mon analyse, la moitiè du temps est perdu dans

geodata = frame:callParserFunction('#coordinates', geodataparams )

ligne 1036 du Module:Coordinates. Ce code permet d'enregister les coordonnées dans je ne sais quelle base de données (cf. mw:Extension:GeoData).

La version en.wiki de Coord a un paramètre nosave qui permet de désactiver cet enregistrement, et par la même économiser le temps passé à le faire. J'ai implémenté ça dans le Module:Coordinates/Bac à sable, qui peut être testé avec {{coord/Bac à sable}}.

Qu'en pensez-vous ? Faut-il traduire le nom de ce paramètre (si oui par quoi) ? Faut-il l'activer par défaut hors de l'espace encyclopédique ?

Zebulon84 (discuter) 3 avril 2022 à 23:41 (CEST)

Salut Zebulon84. OK avec l'ajout du booléen saveGeodata dans le code du module. Pour le nom du paramètre, quelques modestes propositions critiquables : léger, nombreux, sans méta (pour « pas de métadonnées ») ou conserver nosave calqué sur l'anglais mais dans ce cas plutôt noGeoData. Favorable à l'activation (de l'allègement) par défaut en dehors des articles (+ catégories ? + modèles ?), au moins sur les pages de discussion et les pages Utilisateur. — Ideawipik (discuter) 4 avril 2022 à 08:28 (CEST)
Déjà, je suis très réticent au principe d'une parser function qui sert à enregistrer des donnéees (c'est surprenant, et ça me parait sensible à l'insertion de données erronées, que cela soit volontaire ou non).
Ensuite, j'ai eu beau parcourir les pages indiquées et chercher un peu partout, je n'ai pas trouvé à quoi cela sert. J'ai souvenir qu'une fois j'étais sur une une carte, et à partir d'un emplacement je voyais autour tous les emplacements qui avaient un article ; mais je n'ai pas réussi à retrouver cela.
Donc pour l'instant, je serais d'avis à carrément supprimer la fonctionnalité, à moins que quelqu'un puisse démontrer son utilité.
od†n ↗blah 4 avril 2022 à 18:09 (CEST)
Dans ce cas, on peut demander à Orlodrim (bonjour !) la raison de l'ajout de cet élément dans le module (modif datant de 2014). Cordialement, — Ideawipik (discuter) 4 avril 2022 à 22:47 (CEST)
Ou plutôt à Zolo (sur le bac à sable). — Ideawipik (discuter) 4 avril 2022 à 22:57 (CEST)
J'ai renommé le paramètre geodata, pour le moment activé par défaut sur les espaces principal, catégorie et portail (sur le /Bac à sable uniquement bien sur). Le module:Yesno est utilisé pour analyser la valeur booléenne.
Je ne sais pas exactement quelle est l'utilité, mais cette fonction était présente dans dans l'ancien {{coord}} et a été supprimée lors du passage en lua, ce qui à généré cette question technique. — Zebulon84 (discuter) 5 avril 2022 à 18:48 (CEST)
Si la fonctionnalité sert à géolocaliser un article ou un élément "géographique" dans un article, il me semble préférable d'intégrer par défaut cette géolocalisation aux infoboxNote. Et dans le modèle/module {{coord}}, de supprimer le "GeoData" par défaut et qu'il soit uniquement activable, dans les cas particuliers, sur demande explicite du contributeur, avec le nouveau paramètre.
Cela me fait penser aux modèles {{Date de naissance}} et de décès, qui ne seraient utiles que pour exprimer les dates de la personne à laquelle est consacré l'article et dont la fonctionnalité est d'ailleurs déjà implémentée par défaut dans un grand nombre d'infobox relatives aux personnes. Modèles inutiles (par rapport à {{Date}} ou {{Date-}}) dans une liste, un tableau ou le corps de l'article.
Note : Ce qui est déjà fait au moins partiellement. Exemple : {{Infobox Monument}} sollicite déjà (conditions à vérifier) → Module:Infobox/Fonctions/BâtimentModule:Infobox/FonctionsModule:Infobox/Fonctions/GéolocalisationModule:Coordinates dont on parle ici. — Ideawipik (discuter) 5 avril 2022 à 20:08 (CEST)
J'ai trouvé ça, dont la dernière phrase indique que ça sert à Special:Nearby et cet outil produisant une carte avec des articles. Et la question à la fin est pertinente. Maintenant, Wikidata permet de faire à peu près la même chose, de façon plus flexible, par exemple d:Wikidata:SPARQL query service/queries/examples#Places within 1km of the Empire State Building. Mais bon, pour éviter de casser ce qui existe, autant laisser un appel à partir des infobox pour définir les coordonnées "primaires". Pour les autres coordonnées présentes dans l'article, je pense qu'on peut enlever l'appel à #coordinates. Orlodrim (discuter) 5 avril 2022 à 21:23 (CEST)
J'ai modifié Module:Coordinates/Bac à sable pour que par défaut les coordonnées ne soient enregistrées que lorsqu'elles sont affichée en titre de l'article. Il est possible de changer ça avec le paramètre geodata.
J'ai aussi fait quelques petites optimisation, notamment sur le chargement de module externe (on sait maintenant que ça marche bien).
Je remercie par avance l'administrateur qui copiera ce code dans le module:Coordinates.
Zebulon84 (discuter) 8 avril 2022 à 18:55 (CEST)
✔️ @Zebulon84 et voilà, avec un diff tout propre : 192947244. od†n ↗blah 18 avril 2022 à 10:28 (CEST)
Et la documentation du paramètre "geodata" : 192970723. od†n ↗blah 19 avril 2022 à 05:02 (CEST)

Interprétation d'un modèle dans un module[modifier le code]

Bonjour, Je débute avec les modules sur wikipedia et j'aimerai savoir comment utiliser des modèles à l’intérieur des modules.

Par exemple, je cherche à retourner un classement, et pour çà je veux écrire la position avec {{2e|place}} pour voir 2e place mais lorsque j'utilise mon module, c'est le code en dur qui est affiché et non le résultat du modèle.

Comment puis-je faire pour avoir le résultat voulu ? Programmateur01 (discuter) 22 juin 2022 à 17:00 (CEST) ps: je travaille sur la page Module:Bac à sable

avec un objet « frame », passé par exemple en paramètre au lua à l’appel du module depuis un template. cf. mw:Extension:Scribunto/Lua_reference_manual/fr#frame:expandTemplate. — TomT0m [bla] 22 juin 2022 à 17:33 (CEST)
Merci ! Programmateur01 (discuter) 23 juin 2022 à 00:00 (CEST)
Ceci dit la fonction expandTemplate peut être lente donc pour des raisons de performance, si un modèle doit être appelé plusieurs fois, il est souvent préférable de refaire la fonction en lua. Par exemple pour les modèles type {{2e}}, il est possible d'utiliser la fonction ordinal du Module:nombre2texte éventuellement suivit d'un espace insécable ('\194\160') – Zebulon84 (discuter) 23 juin 2022 à 04:41 (CEST)
Je vois, merci de la précision --Programmateur01 (discuter) 23 juin 2022 à 10:46 (CEST)

Bogue d'affichage quand une valeur est vide[modifier le code]

Voir Wikipédia:Le Bistro/7 juillet 2022#Encore du Wikidata, Olympia (film, 1938)#Liens externes et Q158069#P345. — Thibaut (discuter) 7 juillet 2022 à 16:15 (CEST)

Normalement, résolu sur le Module:Bases. — TomT0m [bla] 7 juillet 2022 à 17:13 (CEST)
Merci chef. — Thibaut (discuter) 7 juillet 2022 à 17:15 (CEST)

Formatage d'une catégorie[modifier le code]

Je signale.--Patafisik (WMF) (discuter) 25 août 2022 à 11:05 (CEST)

Bonjour, Le paramètre "oclc" du modèle {{Ouvrage}} ne fonctionne plus : il faudrait mettre à jour la fonction References.ocl dans Module:Biblio/Références, comme ça a été fait récemment dans Modèle:Recherche OCLC.

Voir aussi Discussion module:Biblio/Références#Lien OCLC.

Merci ! Eric-92 (discuter) 1 septembre 2022 à 22:40 (CEST)

Savoir quels modules appellent un module donné[modifier le code]

J'ai ajouté en bas de la documentation des modules le lien vers la recherche interne qui répond à cela. l'Escogriffe (✉) 26 septembre 2022 à 21:51 (CEST)

Demande de changement de Module:Bandeau/Ébauche[modifier le code]

Bonjour,

Avec le paramètre "écrivain", ce module donne "écrivain" pour un homme, mais "femme de lettres" pour une femme. On est dans un cas flagrant de biais de genre, vu la connotation de l'expression, et même sans cela, c'est simplement inapproprié car cela ne correspond pas à la définition (voir femme de lettres). Il faudrait modifier le module pour qu'il affiche simplement "écrivaine". Je préfère poster une demande à le faire moi-même car le module est très utilisé et mes compétences techniques sont trop incertaines.

CaféBuzz (discuter) 8 octobre 2022 à 13:33 (CEST)

✔️ Fait. — Metamorforme42 (discuter) 7 novembre 2022 à 20:10 (CET)

✔️ Espace insécable entre la flèche et le nom d'utilisateur dans le Module:Notification[modifier le code]

Voir aussi la demande d'intervention sur une page protégée.

Bonjour

Je me suis rendu compte que dans le modèle:Notif et les modèles similaires, la flèche reste en bout de ligne et le nom d'utilisateur à notifier se retrouve sur la ligne suivante.

Notification Thibaut120094 : à fait remarquer que les espaces insécables &nbsp; ne fonctionnaient pas avec les images et qu'il fallait utiliser {{nowrap}}, mais qu'on ne pouvait le faire dans le modèle car cela rendait tous la ligne de pseudos insécables s'il y en avait plusieurs, et qu'il fallait intervenir au niveau du Module:Notification.

Comme je n'en suis pas capable, je viens faire la demande ici.

Je tiens à rappeler que changer les images par d'autres ou par des emojis/caractères spéciaux ASCII n'est pas envisageable (pour {{Mention}} on peut utiliser directement le paramètre prefixe=@ du module) : il y a déjà eu plusieurs discussions longues et houleuses pour décider de la taille, couleur et style de ces petites flèches, et se relancer là dedans n'est pas le but.

Merci pour votre temps, cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 14 novembre 2022 à 10:11 (CET)

Pas si simple qu'il n'y paraît… la seule solution que j'ai trouvée consisterait à injecter le </span> de fermeture :
<span class="nowrap">[[Fichier:Trucmuche.png]]&nbsp;{{#invoke:String|replace|source={{#invoke:Notification|main}}|pattern=^(%b[]%S*)|replace=%1</span>|plain=false}}
od†n ↗blah 22 novembre 2022 à 10:29 (CET)
@od†n : il me semble que ton code fait juste sauter une ligne et met le tout en début de la ligne suivante (cf. Utilisateur:SyntaxTerror/Brouillon9)
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 22 novembre 2022 à 13:29 (CET)
Forcément lol, je t'ai corrigé cela : 198882597. Notification Od1n : oups ! (Smiley oups) Şÿℵדαχ₮ɘɼɾ๏ʁ 22 novembre 2022 à 17:21 (CET)
Par ailleurs, j'ai trouvé une approche plus simple (et plus performante). Je viens d'effectuer 198883739 (+ 198883766) dans le module. Exemples d'utilisation : 198883869, 198884628.
Un léger défaut : le 1er utilisateur est entièrement insécable, tandis que les utilisateurs suivants sont sécables. Mais techniquement (vu qu'il y a un lien, donc imbrication de balises) on ne peut pas avoir l'utilisateur insécable avec l'image, tout en gardant l'utilisateur lui-même sécable. Mais éventuellement, on pourrait rendre tous les utilisateurs insécables.
od†n ↗blah 22 novembre 2022 à 14:30 (CET)
50 noms sur une seule ligne n’est pas désirable. — Thibaut (discuter) 22 novembre 2022 à 15:16 (CET)
Non non, lol. Chaque utilisateur serait insécable, mais ça serait sécable entre chacun. od†n ↗blah 22 novembre 2022 à 16:51 (CET)

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

Merci od†n, le problème semble réglé maintenant.
Pourrais-tu aussi modifier le Modèle:Notif projet s'il te plaît ? Le code est un peu compliqué avec un #if: nocat et je ne veux pas lancer là-dedans vu mes dernières prouesses en écriture de code... (Smiley oups)
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 22 novembre 2022 à 17:21 (CET)
Voilà qui est fait. od†n ↗blah 22 novembre 2022 à 18:13 (CET)
Merci Od1n Émoticône. J'en ai profité pour classer la demande d'intervention sur une page protégée. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 22 novembre 2022 à 18:37 (CET)
Super, merci Od1n et SyntaxTerror ! — Thibaut (discuter) 22 novembre 2022 à 20:27 (CET)
Comme j'avais suggéré plus haut, je viens de modifier le module afin que chaque utilisateur soit insécable. od†n ↗blah 23 novembre 2022 à 13:04 (CET)