Discussion Projet:Scribunto/Archive 6

Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Suppression
  • Neutralité
  • Droit d'auteur
  • Portail de qualité
  • Bon portail
  • Lumière sur
  • À faire
  • Archives

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

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

Module:Biblio[modifier le code]

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

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

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

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

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

Problèmes avec Module:Interface Wikidata[modifier le code]

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}} }} donne « 775 670 417link=https://www.wikidata.org/wiki/Q504 998?uselang=fr#P1 616 ». Il faudrait donc ajouter au module cette possibilité.

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

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

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

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 Q54818533 (« Atmavrittanta »), dont P443 (« prononciation (fichier son) ») est renseigné.
Quelqu'un peut m'aider svp ? - Simon Villeneuve 7 mai 2019 à 20:45 (CEST)[répondre]

Nouvelles fonctions pour le module:Composition Division de France[modifier le code]

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

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

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

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

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

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

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

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

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

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

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

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)[répondre]
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)[répondre]
Oh terrible !!! Mort de rire
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)[répondre]
Lus. Je copie cette discussion sur Discussion_Projet:CyclismeSernin SC (discussion) 11 janvier 2020 à 12:15 (CET)[répondre]
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)[répondre]
Ç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)[répondre]
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)[répondre]
À 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)[répondre]
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)[répondre]
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)[répondre]
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)[répondre]

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

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

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

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

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

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

Bonjour Maëlan Bonjour. 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)[répondre]
Bonjour Lofhi Bonjour, 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)[répondre]
Voir commons:category:Map_data_of_subdivisions_of_France. --Viruscorona2020 (discuter) 22 mars 2020 à 08:22 (CET)[répondre]

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

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

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)[répondre]
@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)[répondre]
J'ai demandé là : Discussion Projet:Biologie/Le café des biologistes#Modèle:Clade. Orlodrim (discuter) 24 mai 2020 à 19:52 (CEST)[répondre]

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é Clin d'œil. 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)[répondre]

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

Module:Biblio/Références[modifier le code]

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
(notice BnF no FRBNF34063996) (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 Sourire.

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

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

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

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

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

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)[répondre]
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)[répondre]
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éesClin d'œil, 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)[répondre]
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)[répondre]

Equivalent de en:Module:File link et en:Template:File link[modifier le code]

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

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

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

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

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)[répondre]
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 ?Clin d'œil Ender~frwiki (discuter) 1 octobre 2020 à 11:33 (CEST)[répondre]
@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)[répondre]
@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)[répondre]
En fait on parle du sujet Ici Ender~frwiki (discuter) 1 octobre 2020 à 13:03 (CEST)[répondre]

ISSN dépréciés mal gérés par {{Bibliographie}} et Module:Wikidata/Références[modifier le code]

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

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

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