Discussion Projet:Scribunto

Projet

Discussions

Avenue des cafés et bistros

Le projet « Scribunto » n'est pas notifié pour le moment.

Bienvenue sur la page de discussion du Projet Scribunto !

N'hésitez pas à déposer ici suggestions, questions et requêtes à propos du projet.

Archives

• Février-mars 2013
• Mars-août 2013
• Août 2013-mars 2015
• Mars 2015-décembre 2016
• Janvier 2017-décembre 2018
• Janvier 2019-maintenant

nosave pour Coord × 1000+

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

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

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

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

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

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

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

Salut Zebulon84. OK avec l'ajout du booléen saveGeodata dans le code du module. Pour le nom du paramètre, quelques modestes propositions critiquables : léger, nombreux, sans méta (pour « pas de métadonnées ») ou conserver nosave calqué sur l'anglais mais dans ce cas plutôt noGeoData. Favorable à l'activation (de l'allègement) par défaut en dehors des articles (+ catégories ? + modèles ?), au moins sur les pages de discussion et les pages Utilisateur. — Ideawipik (discuter) 4 avril 2022 à 08:28 (CEST)

Déjà, je suis très réticent au principe d'une parser function qui sert à enregistrer des donnéees (c'est surprenant, et ça me parait sensible à l'insertion de données erronées, que cela soit volontaire ou non).

Ensuite, j'ai eu beau parcourir les pages indiquées et chercher un peu partout, je n'ai pas trouvé à quoi cela sert. J'ai souvenir qu'une fois j'étais sur une une carte, et à partir d'un emplacement je voyais autour tous les emplacements qui avaient un article ; mais je n'ai pas réussi à retrouver cela.

Donc pour l'instant, je serais d'avis à carrément supprimer la fonctionnalité, à moins que quelqu'un puisse démontrer son utilité.

od†n ↗^blah 4 avril 2022 à 18:09 (CEST)

Dans ce cas, on peut demander à Orlodrim (bonjour !) la raison de l'ajout de cet élément dans le module (modif datant de 2014). Cordialement, — Ideawipik (discuter) 4 avril 2022 à 22:47 (CEST)

Ou plutôt à Zolo (sur le bac à sable). — Ideawipik (discuter) 4 avril 2022 à 22:57 (CEST)

J'ai renommé le paramètre geodata, pour le moment activé par défaut sur les espaces principal, catégorie et portail (sur le /Bac à sable uniquement bien sur). Le module:Yesno est utilisé pour analyser la valeur booléenne.

Je ne sais pas exactement quelle est l'utilité, mais cette fonction était présente dans dans l'ancien {{coord}} et a été supprimée lors du passage en lua, ce qui à généré cette question technique. — Zebulon84 (discuter) 5 avril 2022 à 18:48 (CEST)

Si la fonctionnalité sert à géolocaliser un article ou un élément "géographique" dans un article, il me semble préférable d'intégrer par défaut cette géolocalisation aux infobox^Note. Et dans le modèle/module {{coord}}, de supprimer le "GeoData" par défaut et qu'il soit uniquement activable, dans les cas particuliers, sur demande explicite du contributeur, avec le nouveau paramètre.

Cela me fait penser aux modèles {{Date de naissance}} et de décès, qui ne seraient utiles que pour exprimer les dates de la personne à laquelle est consacré l'article et dont la fonctionnalité est d'ailleurs déjà implémentée par défaut dans un grand nombre d'infobox relatives aux personnes. Modèles inutiles (par rapport à {{Date}} ou {{Date-}}) dans une liste, un tableau ou le corps de l'article.

Note : Ce qui est déjà fait au moins partiellement. Exemple : {{Infobox Monument}} sollicite déjà (conditions à vérifier) → Module:Infobox/Fonctions/Bâtiment → Module:Infobox/Fonctions → Module:Infobox/Fonctions/Géolocalisation → Module:Coordinates dont on parle ici. — Ideawipik (discuter) 5 avril 2022 à 20:08 (CEST)

J'ai trouvé ça, dont la dernière phrase indique que ça sert à Special:Nearby et cet outil produisant une carte avec des articles. Et la question à la fin est pertinente. Maintenant, Wikidata permet de faire à peu près la même chose, de façon plus flexible, par exemple d:Wikidata:SPARQL query service/queries/examples#Places within 1km of the Empire State Building. Mais bon, pour éviter de casser ce qui existe, autant laisser un appel à partir des infobox pour définir les coordonnées "primaires". Pour les autres coordonnées présentes dans l'article, je pense qu'on peut enlever l'appel à #coordinates. Orlodrim (discuter) 5 avril 2022 à 21:23 (CEST)

J'ai modifié Module:Coordinates/Bac à sable pour que par défaut les coordonnées ne soient enregistrées que lorsqu'elles sont affichée en titre de l'article. Il est possible de changer ça avec le paramètre geodata.

J'ai aussi fait quelques petites optimisation, notamment sur le chargement de module externe (on sait maintenant que ça marche bien).

Je remercie par avance l'administrateur qui copiera ce code dans le module:Coordinates.

— Zebulon84 (discuter) 8 avril 2022 à 18:55 (CEST)

@Zebulon84 et voilà, avec un diff tout propre : 192947244. od†n ↗^blah 18 avril 2022 à 10:28 (CEST)

Et la documentation du paramètre "geodata" : 192970723. od†n ↗^blah 19 avril 2022 à 05:02 (CEST)

Interprétation d'un modèle dans un module

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

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

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

avec un objet « frame », passé par exemple en paramètre au lua à l’appel du module depuis un template. cf. mw:Extension:Scribunto/Lua_reference_manual/fr#frame:expandTemplate. — TomT0m ^[bla] 22 juin 2022 à 17:33 (CEST)

Merci ! Programmateur01 (discuter) 23 juin 2022 à 00:00 (CEST)

Ceci dit la fonction expandTemplate peut être lente donc pour des raisons de performance, si un modèle doit être appelé plusieurs fois, il est souvent préférable de refaire la fonction en lua. Par exemple pour les modèles type {{2e}}, il est possible d'utiliser la fonction ordinal du Module:nombre2texte éventuellement suivit d'un espace insécable ('\194\160') – Zebulon84 (discuter) 23 juin 2022 à 04:41 (CEST)

Je vois, merci de la précision --Programmateur01 (discuter) 23 juin 2022 à 10:46 (CEST)

Bogue d'affichage quand une valeur est vide

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

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

Merci chef. — Thibaut (discuter) 7 juillet 2022 à 17:15 (CEST)

Formatage d'une catégorie

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

OCLC dans Module:Biblio/Références

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

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

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

Savoir quels modules appellent un module donné

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

Demande de changement de Module:Bandeau/Ébauche

Bonjour,

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

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

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

Espace insécable entre la flèche et le nom d'utilisateur dans le Module:Notification

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

Bonjour

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

 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.

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

Pas si simple qu'il n'y paraît… la seule solution que j'ai trouvée consisterait à injecter le </span> de fermeture :

<span class="nowrap">[[Fichier:Trucmuche.png]]&nbsp;{{#invoke:String|replace|source={{#invoke:Notification|main}}|pattern=^(%b[]%S*)|replace=%1</span>|plain=false}}

od†n ↗^blah 22 novembre 2022 à 10:29 (CET)

@od†n : il me semble que ton code fait juste sauter une ligne et met le tout en début de la ligne suivante (cf. Utilisateur:SyntaxTerror/Brouillon9)

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 22 novembre 2022 à 13:29 (CET)

Forcément lol, je t'ai corrigé cela : 198882597.  Od1n : oups ! Şÿℵדαχ₮ɘɼɾ๏ʁ 22 novembre 2022 à 17:21 (CET)

Par ailleurs, j'ai trouvé une approche plus simple (et plus performante). Je viens d'effectuer 198883739 (+ 198883766) dans le module. Exemples d'utilisation : 198883869, 198884628.

Un léger défaut : le 1er utilisateur est entièrement insécable, tandis que les utilisateurs suivants sont sécables. Mais techniquement (vu qu'il y a un lien, donc imbrication de balises) on ne peut pas avoir l'utilisateur insécable avec l'image, tout en gardant l'utilisateur lui-même sécable. Mais éventuellement, on pourrait rendre tous les utilisateurs insécables.

od†n ↗^blah 22 novembre 2022 à 14:30 (CET)

50 noms sur une seule ligne n’est pas désirable. — Thibaut (discuter) 22 novembre 2022 à 15:16 (CET)

Non non, lol. Chaque utilisateur serait insécable, mais ça serait sécable entre chacun. od†n ↗^blah 22 novembre 2022 à 16:51 (CET)

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

Merci od†n, le problème semble réglé maintenant.

Pourrais-tu aussi modifier le Modèle:Notif projet s'il te plaît ? Le code est un peu compliqué avec un #if: nocat et je ne veux pas lancer là-dedans vu mes dernières prouesses en écriture de code...

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 22 novembre 2022 à 17:21 (CET)

Voilà qui est fait. od†n ↗^blah 22 novembre 2022 à 18:13 (CET)

Merci Od1n . J'en ai profité pour classer la demande d'intervention sur une page protégée. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 22 novembre 2022 à 18:37 (CET)

Super, merci Od1n et SyntaxTerror ! — Thibaut (discuter) 22 novembre 2022 à 20:27 (CET)

Comme j'avais suggéré plus haut, je viens de modifier le module afin que chaque utilisateur soit insécable. od†n ↗^blah 23 novembre 2022 à 13:04 (CET)

Utilisation de MySQL dans des modules ?

Bonjour, est-ce que quelqu'un pourrait m'indiquer s'il est possible d'utiliser des bases de données MySQL et donc des librairies MySQL dans des modules sur Wikipédia ? J'ai tenté une recherche avancée mais je n'ai rien trouvé, et vu que j'apprends tout juste à utiliser MySQL je ne me rends pas vraiment compte des implications. Merci bien. Salutations, Espandero (discuter) 17 novembre 2022 à 18:38 (CET)

Bonjour Espandero : à ma connaissance non. Et j'ai envie de dire : quelle base de données ? Wikipédia/wikimedia a bien une base de données derrière, mais elle est accédée à travers diverses API, jamais directement.

Et on voit mal le contenu de wikipédia dépendre directement (au sens accès) d'une base de données qui lui soit externe (à la limite wikidata est une base de données externe, mais encore une fois elle est accédée via une API, certainement pas via une interface *SQL. Et c'est un projet frère).

Par contre il existe des modules Lua (pas Scribunto) pour interfacer des bases de données. Mais ça sort un peu du scope de ce projet je pense (voir ça par exemple, mais il y en a plein d'autres). Cordialement, Hexasoft (discuter) 22 novembre 2022 à 21:17 (CET)

Bonjour Hexasoft et merci de la réponse. L'idée serait d'avoir une base de donnée pour plusieurs statistiques de communes suisses (population, chiffres pour pyramide des âges, proportion secteur primaire, secondaire, tertiaire, etc.) afin de faciliter la mise à jour de ces informations (en rajoutant ou mettant à jour une ligne on pourrait mettre à jour les ~2000 articles en même temps). La base de donnée pourrait par exemple être stockée sur Commons, mais cela dépend bien sûr de la faisabilité d'une telle chose. Je n'en suis qu'aux prémices de ce projet donc je cherche des manières de mettre ceci en place. Salutations, Espandero (discuter) 22 novembre 2022 à 21:28 (CET)

Bonjour,

Vu le projet, il y a quelques pistes (mw:Manual:Managing data in MediaWiki) :

1. Stocker l'ensemble des données dans un module, comme le fait par exemple Module:Données Rang1975 pour alimenter Modèle:Données Rang1975, Module:Population de France/Données ou plein de modules Données.
   • J'ignore si cette méthode utilise Cargo and Semantic MediaWiki mais Cargo et Semantic MediaWiki sont des pistes ; Cargo a une fonction de requête SQL sur la base de données créée par un modèle (j'ignore comment tout cela fonctionne).
2. Stocker les données dans Wikidata, appeler les propriétés.

Le plus simple resterait de créer un ensemble de modules, je crois. LD (d) 22 novembre 2022 à 21:44 (CET)

Une autre piste : exporter une base de données MySQL en JSON par exemple avec lib mysqludf json. Vu que le format JSON est supporté par des pages, ex. Wikipédia:AutoWikiBrowser/CheckPageJSON est une mini base de données en soi, et que @Od1n m'a récemment souligné qu'on pouvait décoder du JSON en wikitexte grâce à Lua, il doit être possible de remplacer les requêtes SQL par des résultats pré-définis de requêtes qui seront exploitables. LD (d) 22 novembre 2022 à 21:59 (CET)

Conflit d’édition — LD a mieux résumé que moi (j'ai tendance à être verbeux ).

Pour wikidata il y a théoriquement la structure existante. Toutefois 1. le formalisme peut dérouter l'informaticien pur ainsi que le wikipédien pur 2. l'ajout de propriétés/sources n'est pas « si » libre que ça, ce qui peut être compliqué quand on souhaite avoir des distinctions fines et spécifiques (« population, chiffres pour pyramide des âges, proportion secteur primaire, secondaire, tertiaire, etc. ») 3. ça rend complexe les modules car il faut prendre en compte l'absence de certaines sources pour certaines données (sur quoi on peut retomber, qu'est-ce qui est possible / souhaitable / non voulu) 4. comme pour toute externalisation de l'info ça rend complexe le suivi, d'autant plus que le module est complexe.

Pour le JSON et autre il faut penser au poids des données : il y a des restrictions en temps mais aussi en mémoire, ça peut être à prendre en considération. Cordialement, Hexasoft (discuter) 22 novembre 2022 à 22:20 (CET)

Effectivement, hors opendata.swiss, il est problématique de copier-coller une base de données suisse (l'Office fédéral de la statistique copyright presque tout).

Pour le JSON, je serais en effet plutôt réticent à exploiter cela sans avoir un retour sur la performance pour les raisons citées par Hexasoft, et parce qu'il faut être admin pour créer le format (pas si fréquent...) et modifier la page sous le format... Après, la conversion JSON vers Lua n'est pas complexe, donc cela peut revenir à la première piste in fine. LD (d) 22 novembre 2022 à 22:36 (CET)

Le format module semble effectivement être le plus simple, mais la façon de faire de Module:Population de France/Données m'embête un peu car la mise à jour me semble un peu fastidieuse (au final au lieu de mettre à jour ~2000 articles on doit mettre à jour ~2000 modèles ; j'aimerais rendre ça le plus accessible possible, donc pas besoin de bot ou de statut spécial). Pour les questions de copyright, il me semble que les données de population ([1] et [2]) et les nouvelles statistiques publiées par l'OFS tendent à être rendues libres d'usage (et donc publiées sur opendata.swiss). - Espandero (discuter) 22 novembre 2022 à 22:46 (CET)

Une base importable dans wikidata ferait l'affaire, non? Avec des graphiques requêtant dans Wikidata (sparql/et modules graph) non? Ou alors j'ai pas compris le besoin... Bouzinac (discuter) 22 novembre 2022 à 22:58 (CET)

Conflit d’édition — Une note en passant : le principe de séparer les modules de données est lié… à la taille des données.

Charger un module (ou un modèle) contenant toutes les données de toutes les communes pour afficher les infos (éventuellement partielles) d'une seule commune est un non sens informatique : le logiciel ne peut savoir de quoi on va avoir besoin, vu que ça dépend de tout un tas de paramètres et du code lui-même. C'est un gouffre en mémoire (et en temps d'accès : même avec de bons index plus une base est grosse plus il faut de temps pour trouver une donnée spécifique).

Ça complexifie la mise à jour. Mais ça a son intérêt quand tout n'est pas mis à jour d'un seul coup (très fréquent dans les recensements), et ça a son intérêt en terme d'impact (on n'invalide pas les caches de X milliers de communes parce qu'on a corrigé ou mis à jour les données d'une seule).

Et au final ça regarde les contributeurs de se taper le sale boulot, le but c'est la fluidité pour les lecteurs et donc pour WP dans son ensemble Hexasoft (discuter) 22 novembre 2022 à 23:00 (CET)

Oui l'idée n'était pas de mettre tout dans une seule base de donnée (d'où la question avec MySQL) mais plutôt de procéder par canton (26x). Peut-être que du coup le plus simple c'est de faire cela par canton et par décennie et de laisser un module pour le dernier recensement (qui viendrait donc remplacer les modèles qui font déjà cela). Pour Wikidata, je me vois très mal renseigner les populations d'une quinzaine de décennies là-bas, surtout que la surveillance serait beaucoup plus compliquée de cette façon (il faudrait avoir des yeux ici et là-bas). Je suis un peu fainéant mais mon but est de rendre ça le plus simple possible en même temps que de trouver une solution durable sur le long terme. - Espandero (discuter) 22 novembre 2022 à 23:31 (CET)

Accord en genre des libellés de ligne d'infobox

Une nouvelle fonctionnalité est décrite ici. l'Escogriffe (✉) 19 février 2023 à 00:43 (CET)

Pays et région entre parenthèses

Bonjour,

En ce moment, les infoboîtes WD n’affichent pas le pays et l’État/région/département entre parenthèses pour les lieux de naissance et de décès, une personne sous IP utilise une bidouille pour les faire apparaître ([3][4][5][6][7][8], etc.), mais je ne suis pas sûr que ce soit la façon la plus pertinente de faire sur Wikidata (le qualificatif « pays : Japon » me semble inutile sur « lieu de décès : Tokyo »), il vaut mieux que le module aille chercher par lui-même le pays dans l’élément de la ville et l'affiche tout simplement.

Quels sont vos avis ? — Thibaut (discuter) 20 février 2023 à 19:03 (CET)

Je suis d'accord, ça devrait être fait automatiquement si ce n'est pas encore le cas. On ne devrait pas ajouter en qualificatif d'une déclaration des informations déjà contenues dans les propriétés de l'élément, ça crée des redondances injustifiées sur la base de données.

Pour pouvoir gérer le cas des villes qui ont changé de pays au cours de l'histoire, ça implique que l'infobox regarde le pays auquel appartient la ville à la date de naissance indiquée pour la personne. Escargot (discuter) 12 avril 2023 à 23:49 (CEST)

Hmm, en effet c'est pas si facile, un exemple, il faudrait que l'élément sur la ville soit renseigné correctement, soit en créer plusieurs selon les périodes ? — Thibaut (discuter) 25 mai 2023 à 14:51 (CEST)

@Thibaut120094 et @Escargot bleu effectivement pour éviter les anachronismes, l'infobox devrait regarder la période dans l'idéal. Ceci dit, dans un grand nombre de cas (la majorité ?), le pays est unique et trivial, ne pourrait-on pas déjà traiter ces cas ?

Et non, sauf exception, il n'y a aucune raison de scinder un élément si le pays change (Paris reste Paris, que ce soit à l'époque du royaume de France ou de la France moderne - ou la 4e ou la 5e République si on va encore plus loin dans les détails), Lutèce étant un contre-exemple), cela va causer d'autres problème (Paris au moyen âge n'ayant pas d'article Wikipédia, il faudrait en plus que l’infobox retrouve l’article correspondant et là cela devient vite compliqué).

Cdlt, Vigneron * ^discut. 25 mai 2023 à 15:38 (CEST)

Je suis un des contributeurs qui modifie très souvent Wikidata pour avoir la bonne forme [Ville] ([Pays]) sur les infobox lié à Wikidata. Ou encore [Ville] ([État], [Pays]) pour les USA par exemple.

Donc je suis totalement d'accord qu'il faudrait que l'infobox regarde directement les informations déjà présentes dans la page de ville en question pour éviter de faire ce travail ensuite sur Wikidata.

Par contre, il faudra bien garder la logique [Ville] ([Pays]) pour les pays non fédéraux. Peut-être des exceptions pour les territoires d'outre-mer comme la Guyane ou la Polynésie Française. Pour les pays fédéraux, prendre [ville] ([État], [Pays]) car un état dans un pays est totalement différent d'une région administrative. Storberg (discuter) 26 mai 2023 à 15:22 (CEST)

Inaccessibilité des graphes

Bonjour,

Je viens de me rendre compte que {{Graph:Chart}} utilise canvas. Or cet élément HTML pose de gros problèmes pour l'accessibilité, notamment pour les personnes utilisant des lecteurs d'écran. Il faudrait y ajouter une surcouche d'ARIA, passant par l'ajout d'un paramètre supplémentaire permettant de donner une alternative textuelle. Cet article est très clair pour expliquer ce qu'il faut faire. Eussé-je eu plus de temps que je me serais lancé, mais je n'ai jamais touché à Lua et en ce moment je suis sous l'eau au travail. Serait-il possible de faire quelque chose, ou au moins de remonter le problème? Merci! Litlok (m'écrire) 10 mars 2023 à 08:15 (CET)

Bonjour @Litlok. Le plus simple selon moi reste de ne pas se limiter à une seule présentation des données sous forme de graphe. Si le texte à proximité du graphe explique ce que montre le graphe et/ou si les données sont également présentées sous forme tabulaire, alors l'information est plutôt accessible (l'article mis en lien en montre un exemple dans la section « Good example: Canvas element with text alternative via data table »). --Golmote (discuter) 10 mars 2023 à 18:55 (CET)

Création d'une base erreur LUA

Bonjour,

Avec le Ateliers bases, la propriété P2071 (« identifiant Mémoire des hommes ») a été acceptée. Il n'existait pas de bases dédiés aux militaires et vu que P11152 (« identifiant web Léonore ») a aussi été acceptée, je me suis dit que j'allais donc la créer. J'ai tâtonné pas mal et je pensais avoir tout fait sauf que j'ai une erreur LUA sur Modèle:Bases militaire et je comprends pas pourquoi. Serait-il possible d'avoir de l'aide et désolé si j'ai mal fait les choses.

Cordialement. Gabon100 (discuter) 14 mai 2023 à 23:26 (CEST)

Apparemment c'est réglé : dans Module:Bases/militaire il fallait mettre la propriété entre "". - Eric-92 (discuter) 15 mai 2023 à 20:19 (CEST)