Pour intervenir sur les discussions actuelles ou pour en lancer une nouvelle, allez sur la page de discussion actuelle.
Une fonction nouvelle pour les compositions de divisions françaises
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 ː
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)
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)
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/
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é
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✉ ContactDé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 :
<bug> à la demande de 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 ».
<évolution> ajouter la possibilité d'avoir une valeur par défaut. Par exemple, {{Wikidata| | |défaut=defaut.svg}} donnerait « defaut.svg ».
<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é.
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".
Il s'agit du paramètre value normalement.
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 heureux de te revoir et merci de tes réponses !
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é.
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.
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 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 :
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)
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 .
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)
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 ↗blah22 avril 2019 à 13:12 (CEST)
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).
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)
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}}
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)
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)
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)
§ion=0
Bonjour, 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 (§ion=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 §ion=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, -- NemoDiscuter24 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... -- NemoDiscuter28 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…
En gros, l'infobox devrait savoir par elle-même dans quelle section elle est placée. Sinon, on peut tjrs retirer ce §ion=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 -- NemoDiscuter30 août 2019 à 19:54 (CEST)
Demande d'explications mémoire Lua
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 ↗blah30 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 :
Avant
NewPP limit report
Parsed by mw1258
Cached time: 20190829201454
Cache expiry: 2592000
Dynamic content: false
Complications: []
CPU time usage: 4.316 seconds
Real time usage: 6.591 seconds
Preprocessor visited node count: 20224/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 528402/2097152 bytes
Template argument size: 114854/2097152 bytes
Highest expansion depth: 24/40
Expensive parser function count: 13/500
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 118471/5000000 bytes
Number of Wikibase entities loaded: 20/400
Lua time usage: 2.350/10.000 seconds
Lua memory usage: 50 MB/50 MB
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 s… od†n ↗blah1 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
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)
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)
( 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)
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)
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.
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.
Google Code-In will soon take place again! Mentor tasks to help new contributors!
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 Urbanec5 novembre 2019 à 08:28 (CET)
Erreurs de Lint via Modèle:Cycling race/listofteams
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 ↗blah11 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)
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 :
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 ↗blah20 février 2020 à 02:02 (CET)
Module:Biblio : auteur, collection, éditeur, lieu, langues et translittération
Serait-il possible d’ajouter les fonctions ou arguments suivant au module:Biblio (et les modèles l’utilisant) :
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.
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.
Peut-on ajouter plus d’argument pour les éditeurs ? Certains ouvrages on plus d’un éditeur. On pourrait par exemple avoir éditeur1, éditeur2, etc.
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.
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.
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=ابجد.
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 là. 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.
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.
Bonjour Maëlan. 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, 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)
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 ?
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 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)
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é . 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.
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 ?
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…)
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.
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)
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").
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.) :
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 :
functionReferences.bnf(bnf)bnf=Outils.trim(bnf)ifbnfthenlocaltexte=''localcategory=''localbnfId=bnf:upper():match('BNF(%d+%w)')orbnf:lower():match('cb(%d+%w)')orbnf:match('^%d+%w')ifbnfIdthen-- bnf contient une suite de chiffres qui peut être un ark validelocalbase=bnfId:sub(1,8)localarkId=References.arkId('cb'..base)ifbnfId:len()==8then-- il manque la clé, on l'ajoutebnf=base..arkIdtexte=baseelseifbnfId:len()>8andbnfId:sub(9,9)==arkIdthen-- ark validebnf=bnfId:sub(1,9)texte=baseelse-- ark qui semble non validebnf=bnfIdtexte=bnfIdcategory='[[Catégorie:Recension temporaire pour le modèle Ouvrage|bnf]]'endelse-- le paramètre ne semble pas un ark validetexte=bnfcategory='[[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 paslocallien=databaseExterne(bnf,'[[Bibliothèque nationale de France|BNF]]','catalogue.bnf.fr/ark:/12148/cb','.public',texte)returnlien..categoryendend
À 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 .
Modèle sur les dates de naissance et de mort des personnes
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)
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>.
Merci 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, 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)
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"
Hello 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 ?Ender~frwiki (discuter) 1 octobre 2020 à 11:33 (CEST)
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).
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.
Code pour avoir la carte IGN classique en référence
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
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 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
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.
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 :
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é)
Considérer ce paramètre comme connu même si il ne l’est pas actuellement
Mettre en commentaire les utilisations de ce paramètre
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.
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.
@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 (« chinois »), 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)
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)
Bonsoir, je tente de reprendre les travaux initiés par Ash Crow, c’est-à-dire alléger le Mediawiki:Common.css. Dans la discussion que tu pointes, 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.
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.
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 ↗blah19 février 2020 à 06:33 (CET)
Merci Od1n pour toutes ces explications. Et comme j'aime bien les réponses par oui ou par non , 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 ↗blah19 février 2020 à 10:46 (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.
(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 Villeneuve19 janvier 2021 à 14:46 (CET)
Bonjour eru, 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 Villeneuve28 mars 2021 à 20:34 (CEST)
Infobulle dans la balise des modèles de révision - Module:Fix
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.
Bonjour. 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 :
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.
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 ?
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.
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).
┌─────────────────────────────────────────────────┘ 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. -- NemoDiscuter18 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)
Ideawipik : Un seul lien, qui couvre tout le message et qui soit uniquement interne me semble la meilleure chose . 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é ? -- NemoDiscuter18 février 2021 à 19:54 (CET)
Bonjour 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.
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. --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
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 ? -- NemoDiscuter16 mars 2021 à 17:26 (CET)
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. 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)
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 ’.
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, -- NemoDiscuter16 mars 2021 à 16:48 (CET)
Résumé de la demande à convertir en code Lua
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 :
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: une inscription gratuite au site est nécessaire
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)
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 », sur site.net, Date (consulté le Date).
Pour Article : Auteur, « Titre », périodique/site, Date (lire en ligne).
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 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 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.
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 . – Bastoche*\Discuter\20 mars 2021 à 20:43 (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 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)
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 ↗blah14 avril 2021 à 00:11 (CEST)
Lofhi et Od1n : Merci à vous deux pour vos réponses et désolé pour la notif ...
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).
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)
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)
Tu ne réponds pas à ma question mais je réponds à la tienne . 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. 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'Estp|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)
Sur le plan graphique, divers emplois de la forme de la poire attestent de son usage dans la caricature au début du XIXe siècle, notamment chez Jean-Baptiste Isabey[1] et George Cruikshank, qui a pu inspirer la Poire[2],[3].
Sur le plan graphique, divers emplois de la forme de la poire attestent de son usage dans la caricature au début du XIXe siècle, notamment chez George Cruikshank, qui a pu inspirer la Poire[4],[5], et Jean-Baptiste Isabey[6].
↑Jürgent Döring, « Caricature anglaise et caricature française aux alentours de 1830 », dans Philippe Régnier, Raimund Rütten, Ruth Jung et Gerhard Schneider, La Caricature entre République et censure : L’imagerie satirique en France de 1830 à 1880 : un discours de résistance ?, Lyon, Presses universitaires de Lyon, (DOI10.4000/books.pul.7859).
↑Jürgent Döring, « Caricature anglaise et caricature française aux alentours de 1830 », dans Philippe Régnier, Raimund Rütten, Ruth Jung et Gerhard Schneider, La Caricature entre République et censure : L’imagerie satirique en France de 1830 à 1880 : un discours de résistance ?, Lyon, Presses universitaires de Lyon, (DOI10.4000/books.pul.7859).
↑Werner Hofmann, La caricature de Vinci à Picasso, Gründ, , p. 99.
Bug sur la franchise dans Infobox Jeu vidéo ?
Bonjour, j'espère que je suis au bon endroit pour remonter ce genre de problème
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 ?
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.
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 .--Dfeldmann (discuter) 15 novembre 2021 à 13:59 (CET)
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
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 !
cf. :
a["allemand"]={sujet="[[Allemagne|allemand]]",icone="Nuvola German flag.svg",
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) sur la ligne ligne Jubilee(d) ? 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
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.
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.
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.
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)
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)
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...)
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)
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 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)
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)
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 ?
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é.
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.
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.
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.
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.
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)
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.
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.
Thibaut120094 : à fait remarquer que les espaces insécables 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.
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.
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...
