Discussion Projet:Scribunto/Archive 7

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)

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)