Pour débuger plus facilement mes modules j'ai installer eclipse LDT. Pour pouvoir utiliser les fonctions de mw j'ai téléchargé les fichiers de scribunto.
Le problème c'est qu'il me manque l'environnement « mw_interface » pour que ça marche correctement.
J'ai commencer par virer la majorité du code de mw.lua (qui ne me sert pas trop), et défini manuellement une ou deux variables d'environnement type mw.title.getCurrentTitle=function()return{namespace=0}end, ce qui m'a permis de travailler quelque temps. Mais je désire utiliser un objet mw.language et je me retrouve encore bloqué. Je peux de nouveau bricoler le code de language.lua, mais ce serai plus simple si j'avais une méthode pour récupérer / définir cette variable d'environnement.
Je crois comprendre que tu veux générer une table avec sous-tables qui "simule" mw.language, mais seulement les valeurs. J'ai des fonctions pour lister une table récursivement et générer le texte d'un modèle. Dans ControlArgs les fonctions doctable_args/doctable_recursive et generDoc/generDoc1 (voir les résultats "{{Auteur | ..." et dérouler les boites). Elles sont trop compliquées pour ton cas mais tu peux t'en inspirer et les combiner. Ensuite il suffit de copier le texte généré comme une partie de ton code Lua, et tu peux recommencer aussi souvent que tu veux et pour n'importe quelle table. --Rical (discuter) 28 août 2013 à 22:57 (CEST)
Que j'utilise tes fonctions ou pas, je vois le principe. Cela ne permet pas d'avoir un pseudo-environnement complet, mais ça va déjà m'aider.
Pour le pseudo-environnement complet, je crois qu'il n'y a pas de demi-mesure, il faut monter un serveur local personnel comme je l'ai fait à un moment pour un gadget, mais c'est lourd et pas sur/stable/fidèle. Il faut un serveur MASM + mediawiki et ses bonnes variables + importer tous les modèles, modules, extensions et gadgets annexes à ton but + toutes les pages d'exemples + des logins admin ou non + des mises à jour de tout ça en permanence ! Il faut que ça en vaille vraiment la peine ! --Rical (discuter) 29 août 2013 à 10:32 (CEST)
Non, c'est trop lourd pour mes petits développements actuels. Je vais continuer de bricoler avec les bibliothèques de scribunto sur eclipse. Et j'utiliserai peut-être moins certaine fonction que j'ai du mal a simuler, mais le code n'en sera pas forcément moins efficace.
Dans un but de tester lua comme moyen d'extraction de données de Wikidata, j'ai copier-collé le code du module:InfoboxBuilder/Cultivar pour créer le module:InfoboxBuilder/Composé chimique. Un exemple d'utilisation de ce module est disponible dans l'article Undéc-1-ène. Mon problème vient de ma tentative d'utiliser la fonction Infobox:addMixedRow du module:Infobox pour créer un code permettant de récupérer les données de wikidata si aucune donnée n'est fournie dans le modèle. Quelqu'un pourrait-il me dire comment utiliser la fonction Infobox:addMixedRow pour effectuer l'extraction de wikidata ? Merci Snipre (discuter) 29 août 2013 à 14:56 (CEST)
syntaxhighlight lang="lua"
Bonjour,
Pour les explications du Lua, ne serait-il pas mieux d'utiliser : <syntaxhighlight lang="lua"> </syntaxhighlight> plutôt que <pre></pre> ?
Pendant qu'on y est, quelqu'un sait s'il y a une différence entre <syntaxhighlight lang="lua"> et <source lang="lua">, ou si c'est juste un alias ? Zebulon84 (discuter) 9 septembre 2013 à 22:26 (CEST)
Je suis tombé sur <source> dans le code d'une page et j'ai trouvé le nom bien plus simple à retenir que <syntaxhightlight>. Avec lua il n'y a pas de risque de conflit donc <source> va tout aussi bien. Et dans le cas ou je veux juste écrire un bout de code dans une phrase j'utilise {{code|lang=lua|code= ... }}.
Sur WP:MH, on a un gros problème avec l’utilisation du modèle {{Ligne de tableau MH}}. Le modèle en lui-même fonctionne très bien mais dès que l’on l’appelle « trop », il tombe en rade pour cause de « trop d'inclusions de modèles » (les liste de MH squattent quasiment en permanence Catégorie:Page contenant trop d'inclusions de modèles). Le problème est que cette limite se situe en dessous du nombre de MHs de la plupart des départements (NB: 1 MH = 1 appel de ce modèle).
Lua pourrait-il venir à bout de ce problème ? Et notamment, ce modèle contient presque une vingtaine de #if (pas forcément tout bien codé d’ailleurs) et surtout il appelle les modèles {{Coord/dec2dms}}, {{Coord/dec2dms/dms}} et {{Coord/link}} qui contiennent eux aussi tout un tas de #if et de codes dispendieux. Sachant que par contre, le modèle {{coord}} a été converti au Lua, serait-il possible de ré-utiliser le module:Coordinates ? (malheureusement, je manque de temps et de connaissance en modèle/module).
la question est aussi de savoir d'où vient ce "trop-plein" d'appels de modèles. Si je regarde par exemple Liste des monuments historiques de la Vendée je compte pas moins de 321 appels au modèle {{Ligne de tableau MH}}, et ceci sans compter sur cette même page les quelques autres modèles utilisés, moins nombreux (modèles de portail, palette, autres projets, ébauche…). Je ne sais pas exactement ce que comptabilise mediawiki, mais ces appels resteront quoi qu'il en soit.
Sauf si quelqu'un autre se sent intéressé par ça je veux bien jeter un œil, et tenter de créer un module de remplacement (au moins basique) pour tester la « surcharge ».
Densité de monuments historiques par département en unité par centaine de kilomètres carré.
Bonne question, je venais justement ici pour quérir la réponse. Sur WP:MH, on sait qu'il y a un seuil mais on ne connaît qu’empiriquement son mode de déclenchement (et en général, on le voit que quand il est déjà trop tard ).
Pour information, les départements comptent de 49 à 1803 MHs et donc autant de ligne de tableau. Le cas extrême de Paris étant désespéré (le lecteur saturera bien avant Mediawiki ), le second maximum est la Gironde avec 941 et on tombe ensuite rapidement en dessous des 700 (est-ce raisonnable/envisageable techniquement ?). Ce qui est gênant c’est surtout sont les listes de 300/500 éléments (la majorité des départements).
Il me semble que Mediawiki sature à cause de l’appel des sous-modèles et des sous-sous-modèles et (mais là je suis moins sur) des fonctions parseurs. Comme je le disais, je ne suis pas spécialiste des modèles mais après plus de 8 ans de Wikipéda, je me dis qu’il y a quelque chose de pourri dans l’appel des modèles {{Coord/dec2dms}}, {{Coord/dec2dms/dms}} et {{Coord/link}} par {{Ligne de tableau MH}} (pourquoi pas juste {{coord}} ? dans ce cas, hypothèse de néophyte, il n’y aurait peut-être même pas de nouveaux modules à créer…).
Au niveau calendrier et synchronisation, il n’y a pas urgence et cela tombe plutôt bien vu que l’on est en plein dans WLM jusqu’à fin septembre (ie. il vaut mieux éviter de tout casser en ce moment cela aurait de conséquences importantes ).
Coord générais justement trop d'appel à des sous-modeles, donc ça avait été optimisé en gardant juste le nécessaire par rapport aux besoins des lignes MH. Maintenant que Coord fait appel à lua, ça pourrait effectivement être simplifié. Zebulon84 (discuter) 12 septembre 2013 à 18:41 (CEST)
Fonction et modèle commun : comme pour les modèles précédents, uniquement si les colonnes sont les même. Il faut aussi savoir comment gérer les personalisation type le lien vers les notices probablement spécifique pour chaque pays.
Je vais regarder ça, mais pas tout de suite, je voudrais finir Ouvrage, Article et Lien web auparavant, qui concernent bien plus de pages.
Fait. Je n'ai pas migré les modèles utilisés sur une seule page, voir pas utilisés du tout, mais s'il faut le faire ce ne sera pas très compliqué. Zebulon84 (discuter) 19 mai 2014 à 17:33 (CEST)
Hello,
j'ai pour ainsi dire terminé le module Module:Test/Nombres. Ce module permet d'écrire un nombre (numérique) entier sous forme textuelle, dans la tranche [-999999999999,999999999999].
Il possède une option de langue (fr, be, ch, ch2) permettant d'activer les septantes, octantes, huitantes et autres nonantes.
Il possède également une option type=ordinal qui transforme le nombre généré en rang (147 → cent quarante septième). En mode ordinal le signe éventuel du nombre est ignoré. Pas de support des nombres à virgule.
Je ne suis pas certain que ça serve beaucoup en pratique mais ça m'a traversé l'esprit et je l'ai donc fait .
Pour tester la performance de mon module, je viens de faire quelques tests sur une page lourde. Je me suis aperçu qu'il y a une grande variabilité dans les temps reporté par le « NewPP limit report » (que l'on trouve en bas du code html de la page), avec une page identique (enfin avec une minuscule modif pour être sur d'éviter le cache).
Exemple 1er rapport :
NewPP limit report
CPU time usage: 7.388 seconds
Real time usage: 8.619 seconds
Preprocessor visited node count: 20 338/1000000
Preprocessor generated node count: 82 052/1500000
Post‐expand include size: 1 294 159/2048000 bytes
Template argument size: 352/2048000 bytes
Highest expansion depth: 3/40
Expensive parser function count: 0/500
Lua time usage: 1.832s
Lua memory usage: 1.61 MB
Lua Profile:
Scribunto_LuaSandboxCallback::gsub 660 ms 30.8%
Scribunto_LuaSandboxCallback::getExpandedArgument 440 ms 20.6%
Scribunto_LuaSandboxCallback::preprocess 220 ms 10.3%
recursiveClone <mw.lua:109> 160 ms 7.5%
Scribunto_LuaSandboxCallback::fullUrl 120 ms 5.6%
Scribunto_LuaSandboxCallback::newChildFrame 80 ms 3.7%
Scribunto_LuaSandboxCallback::find 60 ms 2.8%
Scribunto_LuaSandboxCallback::sub 20 ms 0.9%
type 20 ms 0.9%
init <Module:Date> 20 ms 0.9%
[others] 340 ms 15.9%
deuxième rapport, une minute plus tard :
NewPP limit report
CPU time usage: 13.869 seconds
Real time usage: 16.184 seconds
Preprocessor visited node count: 20 338/1000000
Preprocessor generated node count: 82 052/1500000
Post‐expand include size: 1 294 167/2048000 bytes
Template argument size: 352/2048000 bytes
Highest expansion depth: 3/40
Expensive parser function count: 0/500
Lua time usage: 3.510s
Lua memory usage: 1.64 MB
Lua Profile:
Scribunto_LuaSandboxCallback::gsub 1280 ms 29.8%
Scribunto_LuaSandboxCallback::getExpandedArgument 940 ms 21.9%
Scribunto_LuaSandboxCallback::preprocess 440 ms 10.2%
recursiveClone <mw.lua:109> 300 ms 7.0%
Scribunto_LuaSandboxCallback::fullUrl 200 ms 4.7%
Scribunto_LuaSandboxCallback::newChildFrame 120 ms 2.8%
Scribunto_LuaSandboxCallback::getAllExpandedArguments 100 ms 2.3%
Scribunto_LuaSandboxCallback::find 80 ms 1.9%
Scribunto_LuaSandboxCallback::len 60 ms 1.4%
? 60 ms 1.4%
[others] 720 ms 16.7%
Est-ce la charge ou le type de processeur du serveur qui multiplie par deux le temps ?
Les % sont comparable, et les node et size eux ne bougent heureusement pas.
Oui, a priori la charge des serveurs est assez variable pour expliquer cette différence. Et c'est pour ça que pour tester des performances il faut faire plusieurs mesures (du coup il faut faire des stats dessus après :P). — Dakdada(discuter)19 septembre 2013 à 16:47 (CEST)
Ce qui est effectivement rassurant est que les premières (et plus grosses) fonctions gardent grosso modo le même %age, ce qui est logique si la charge sur les serveurs reste à peu près constante durant le calcul de cette page. Toutefois si une charge serveur démarre au milieu on peut avoir des variations dans les pourcentages, selon la répartition des fonctions durant le calcul de la page. Faire des stats reste le seul moyen fiable .
@Zebulon84 : où sont ces stats ? En chargeant une page utilisant des modules je vois bien dans son code la section NewPP mais pas la partie "Lua profile". Ou bien il faut une option ? Hexasoft (discuter) 19 septembre 2013 à 18:09 (CEST)
Ces stats sont exactement comme ci-dessus à la suite du NewPP, mais j'ai l'impression qu'elles n'apparaissent que si le « Lua time usage » est supérieur à 1 seconde. Sur les pages peu chargée elle n'y sont pas (cf #Demande du projet MH).
J'imagine que tous les serveurs wiki ne sont pas "upgrader" en même temps, et si le materiel est différent, le temps processeur aussi. Sans indication sur le processeur en question ça ne veut pas dire grand chose. Le % est la chose la plus inintéressante pour savoir ou le code lua perd du temps, mais ça ne permet pas de comparer une page avec le modèle classique et une page avec la fonction lua. On fera sans.
Ok, je ferai des essais. Sinon oui, avoir une base "matérielle" pour comparer des temps absolus serait utile (au moins connaître la machine qui a traité, pour ne comparer que des stats de la même machine).
Pour la question des pourcentages ça dépend fortement du code je pense. Sur l'exemple si "gsub" (presque 1/3 du temps total) n'est présent qu'à quelques endroits ça peut permettre de se demander si on n'en utilise pas trop dans certaines fonctions. Mais ça ne remplace pas un vrai outil de profiling, c'est certain. Hexasoft (discuter) 19 septembre 2013 à 18:50 (CEST)
Comme il n'y a quasiment pas de gsub dans ce code, je suppose que ça vient aussi de mw.text.trim utiliser souvent, même si ça n'est pas utile (pour ne pas se poser la question de savoir si c'est un paramètre nommé ou non). A vérifier... mais je ne vais pas me poser trop de question tout de suite, lua ne représente que 25% du temps, et donc gsub n'occupe que 8% du temps processeur.
Un appel à mw.title.new("nom de la page") est très couteux. Mais il y a peut-être un moyen de l'accélérer : en calculant une clé sur un entier de 64 bits comme un CRC à partir du nom de la page, et en créant un quasi-index sur cette clé. Comme il peut y avoir des doublons sur cette clé, elle mènerait à une courte table, de quelques pages, facile et rapide à gérer. Globalement on ramènerait une lourde recherche à un temps très court.
Hmm… La question déjà est de savoir ce qui coûte dans cette fonction : la recherche de l'entrée correspondante ou bien la lecture de leur contenu (il y a beaucoup de choses récupérées, dont le contenu via title:getContent()).
De plus on parle d'une liste de 1.5 million d'entrées (et encore : on peut construire des titles sur les redirects, pages de discussion… qui ne sont pas référencées dans ce compte). De plus (encore) je ne l'ai jamais testé mais on peut créer des titles sur des pages d'autres wikis (par contre j'ignore ce qu'on obtient alors, si par exemple on a accès au contenu aussi).
Au final quel serait le gain global ? Faire 1 ou 2 appels à ça reste faisable (après tout c'est déjà ce que fait #exist) et y-a-t-il beaucoup d'usages pour un accès « volumineux » à beaucoup de titles ? Et ces cas ne seraient-ils pas destinés à passer par wikidata ?
C'est de toute façon une question à poser aux dév., même si je présume que s'il y avait une solution simple à ce problème ils y auraient pensé
Bonjour, On reçoit pas mal de demande sur d:Wikidata:Bistro concernant l'utilisation de données de Wikidata dans Wikipedia et le passage à lua est le seul moyen pour gérer la structure de données qui se construit sur Wikidata. L'idéal serait de créer au sein du projet Scribunto une page d'aide pour l'utilisation de wikidata via lua.
Actuellement il existe un module spécifique à Wikidata, Module:Wikidata et si ce module est bon pour l'utilisation des données de wikidata dans le texte, reste la question des infoboxes.
Mieux vaut-il créer des infoboxes directement en lua ou alors utiliser les modèles existants et ajouter dans ces modèles des appels à Wikidata pour récupérer des données ?
Dans le cas des infoboxes entièrement en lua, il serait bien que l'on simplifie le système actuel des modules. Actuellement on a:
Est-ce que quelqu'un pourrait simplifier par regroupement ces différents modules si possible ? L'idéal serait de n'avoir qu'un module générique et des modules spécifiques si possible sans utilisation de modèles (je ne sais pas si cela est facile ou même possible).
Pour permettre une transition douce, il faut permettre l'utilisation des données existantes dans les articles et ajouter les données de Wikidata uniquement si rien n'est disponible dans l'article. Bref, comme pour les interliens, les données des pages ont la priorité sur les données de Wikidata, ces dernières étant toutefois disponibles par défaut.
pour le point 1 j'aurai tendance à dire qu'il est mieux de passer intégralement par Lua. Passer par Module:Wikidata impose de passer par {{wikidata}}, donc ajouter un appel de modèle + module (autant de fois qu'il y a d'éléments) avant d'appeler l'infobox concernée. L'idée derrière Scribunto est de réduire la complexité et les traitements faits par Mediawiki . Bon, toutefois il faut être réaliste : écrire un module quand il n'y a qu'un appel à remplacer ça se fait quand il y a une bonne motivation.
Pour le point 2 son auteur pourrait t'en parler mieux, mais normalement on ne fait appel qu'à un seul : Module:InfoboxBuilder, les autres étant des sous-modules, ou des descriptions d'infobox.
À noter : on ne doit normalement pas appeler de module directement depuis l'espace encyclopédique, il faut passer par un modèle intermédiaire.
Pour le point 3 c'est plutôt un problème pratique qui ne pose pas spécialement de problème. Après tout de nombreux modèles travaillent comme ça. Cordialement, Hexasoft (discuter) 1 octobre 2013 à 09:28 (CEST)
Merci Hexasoft pour ces réponses très précises. Cela confirme le besoin de créer des infobox en lua plutôt que faire de simples adaption des modèles existants. Snipre (discuter) 1 octobre 2013 à 09:53 (CEST)
Il me semble qu'il faudrait avoir un module réservé à la simple mise en page des infobox (sans doute module:InfoboxBuilder) et confiner Module:Wikidata aux outils généraux d'extraction des données (qui sont déjà parfois un peu complexes). Après, se pose la question de l'échelon intermédiaire : comment traiter les données d'une infobox en particulier. Doit-on faire des modules spécialisés comme module:InfoboxBuilder/Cultivar ? Utiliser Wikidata impose parfois un formatage relativement lourd, et on ne devrait pas avoir besion de le redéfinir pour chaque modèle d'infobox. Il me semble qu'il faudrait donc un ou plusieurs modules, qui se charge de mettre en forme les données, avec, le cas échéant un appel à Module:Wikidata pour le travail de plus bas niveau. Ce module de traitement des données n'a pas forcément besoin d'être réservé aux infobox, il pourrait par exemple être utilisé par les différents tableaux présents dans le corps des articles. Cela semble être en partie ce que fait Module:ControlArgs. Donc en gros, on aurait:
Modèle:Infobox Schtroumpf deviendrait un simple appel à Lua {{#invoke: InfoboxBuilder|bithdate={{{date de naissance|}}}|birthloc={{{lieu de naissance|}}}|activité={{{activité|}}}...}} (voir aussi wikidata:Wikidata:Bistro#Wikidata dans les infoboîtes)
Module:InfoboxBuilder appelerait Module:GetData pour formater les données (getData.birthplace(args['lieu de naissance'])
Module:GetData formaterait les données qu'on lui fournit ou à défaut, définirait comment les chercher sur Wikidata en utilisant Module:Wikidata. --Zolo (discuter) 1 octobre 2013 à 10:34 (CEST)
Note : InfoboxBuilder/Helpers est un ensemble de fonctions ayant pour but de simplifier l'utilisation de InfoboxBuilder, en particulier en « machant » une partie du travail. De plus lorsqu'on a des besoin spécifiques il est possible d'insérer des fonctions de traitement (locales, mais aussi d'utiliser des fonctions d'autres modules au besoin).
Il est donc tout à faire envisageable d'ajouter dans les helpers des fonctions d'aide à la mise en forme et d'accès aux données wikidata, ou bien si ces fonctions existent par ailleurs les appeler depuis les helpers. Ce qui est pénible est qu'on peut difficilement tester wikidata puisque c'est relatif avec l'article ne cours . Hexasoft (discuter) 1 octobre 2013 à 11:05 (CEST)
Pour prendre un exemple plus précis, Module:InfoboxBuilder/Philosophe a une fonction "helper" (qui pourrait d'ailleurs être dans les helpers généraux) pour formater la date de naissance et de décès, en le modifiant pour appeler wikidata en l'absence de données directes.
La partie if frame.args[name] then str = frame.args[name] end se verrait ajouter à la place du "end" un else str = wikidata.formatStatements({ ["property"]="P569" }) end. Hexasoft (discuter) 1 octobre 2013 à 14:01 (CEST)
Si je comprends bien Module:InfoboxBuilder/Helpers aide à la mise en page générale de l'infobox, il ne vaudrait pas mieux tenir ça séparé de la gestion des données dans chaque case (du genre récupérer et formater le lieu de naissance) ? --Zolo (discuter) 1 octobre 2013 à 18:40 (CEST)
Le principe c'est que Module:Infobox permet de créer des infobox. Module:InfoboxBuilder permet de passer une description globale d'une infobox sous forme de tables pour la générer. Module:InfoboxBuilder/Helpers donne des fonctions utiles / simplificatrices pour décrire infobox sous forme de table (le format "table décrivant une infobox" pouvant faire peur à ceux qui ne parlent pas Lua). Hexasoft (discuter) 1 octobre 2013 à 18:50 (CEST)
@Hexasoft. Justement, concernant Module:Infobox et Module:InfoboxBuilder, ne serait-il pas préférable d'avoir un seul fichier pour gérer les infoboxes en lua sur WP:fr ? Mon problème avec la situation actuelle, c'est que Module:Infobox dispose d'une fonction simplifiée pour récupérer des données de Wikidata, mais comme cette fonction est simplifiée et que l'on a développé un outil plus poussé avec module:Wikidata, on dispose donc de 3 modules qui se partagent les fonctions et cela n'aide pas à la compréhension ni au développement.
Bref, on a besoin :
un module pour le formatage général des infoboxes (genre Module:InfoboxBuilder qui puisse fonctionner de manière autonome par rapoort à Module:Infobox)
un module pour extraction des données de Wikidata (typiquement Module:Wikidata). La question est de savoir si on peut gérer l'extraction des données dans les infoboxes et dans le texte des articles via le même module.
un module pour des fonctions utilitaires, mais il faudrait bien répartir ces fonctions entre les modules existants ou créer de nouveaux modules mais uniquement si il y a une utilisation dans d'autres modules clairement identifiée.
On rejoint ainsi ce que Zolo avait proposé, reste à définir clairement la structure globale et les relations entre les modules pour permettre un développement compréhensible. Snipre (discuter) 2 octobre 2013 à 12:07 (CEST)
L'accès à wikidata par Lua est actuellement très pénible et compliqué, mais l'évolution que j'ai demandée devrait tout rendre très facile et s'écrire finalement :
mw.wikibase.getProperty("date de naissance", "Victor Hugo")
ou mw.wikibase.getProperty("p20", "Q535")
pour lire n'importe quelle propriété de n'importe quel élément, peut-être même avec un paramètre de type, et sans erreur de script. En attendant, il ne faut pas investir trop vite dans Module:Wikidata. --Rical (discuter) 2 octobre 2013 à 19:19 (CEST)
@Snipre : Module:Infobox et Module:InfoboxBuilder n'ont pas le même rôle. On utilisera les fonctions du premier si on veut soit même construire les différentes briques d'une infobox et que la structure logique pour y parvenir est complexe. On utilisera le second si l'on veut juste construire une infobox relativement statique dans sa structure (comme c'est le cas de beaucoup d'infobox) et cela sans avoir besoin d'un bon niveau en programmation Lua (c'est au final une simple table de description du contenu). module:InfoboxBuilder/Helpers n'est rien d'autre qu'un essai de jeu de fonctions destinées à simplifier la création des blocs de descriptions destinées à Module:InfoboxBuilder (et pourrait même pourquoi pas être intégré à ce dernier).
Accéder de façon plus ou moins transparente à Wikidata est à mon sens un problème différent. On peut vouloir l'intégrer aux fonctions de Module:Infobox et Module:InfoboxBuilder (et/ou ajouter des helpers qui s'en occupent), ou bien laisser ça en « sur-couche » à celui qui développe l'infobox, la plupart du temps le seul à même de décider s'il faut utiliser wikidata ou pas, pour quoi et avec quelle priorité par rapport aux données locales.
Note : module:InfoboxBuilder/Cultivar et autres ne sont pas des modules spécifiques, ce sont des jeux de données décrivant une infobox. Quand on décide de construire une infobox en utilisant Module:InfoboxBuilder le principe est de créer une table de description dans une sous-page (c'est comme ça qu'a été construit ce module). Le modèle (ici Utilisateur:Hexasoft/Cultivar) appel bien Module:InfoboxBuilder en lui passant en paramètre le nom de la sous-page contenant la description à suivre. Et l'appel au modèle sert à fixer les paramètres de cette infobox (ce principe de sous-page se retrouve d'ailleurs dans de nombreux modèles qui stockent les données spécifiques/thématiques dans des sous-pages). Hexasoft (discuter) 2 octobre 2013 à 21:26 (CEST)
Je crois que Hexasoft à parfaitement exposé mon point de vue : Module:Infobox est là comme "backend" de création d'infobox pour avoir une apparence standardisée et Module:InfoboxBuilder est destiné pour pouvoir créer des infobox à partir d'une configuration, comme le font, plus ou moins, les infobox modulaire v2 ou v3. On peux imaginer avoir, en même temps une InfoboxMagique avec son propre module créant une infobox de toute pièce à partir de Wikidata et des infobox "à l'ancienne", utilisant Module:InfoboxBuilder. Ces deux types reposant sur la base commune, Module:Infobox.
Le support de Wikidata dans module:Infobox est très parcellaire pour l'instant et àmha on devrait l'en retirer pour laisser ce module ne gérer que la sortie des infobox. Je n'ai créer ce jeu de modules (ainsi que module:Wikidata) qu'à des fins de tests uniquement et je n'envisageais pas un usage "en production".
<hors sujet>Si cela vous intéresse, j'ai commencé (rien n'est fini) à créer Module:GlobeCoordinate et Module:Time qui sont des modules "bibliothèque" afin d'autoriser une manipulation facile et standardisée des types de données "complexes" dans les modules. L'API publique de chacun de ces modules se trouve après le commentaire "--Public interface" Qu'en pensez-vous ? Cela, je pense permettrai des modules Lua bien plus propres et réutilisable entre les wikis.</hors sujet> Tpt (discuter) 2 octobre 2013 à 23:12 (CEST)
Merci pour les infos, mais j'avais compris pour les utilisations différentes des modules: la seule chose qui me dérange, c'est la multiplication des niveaux qu'entraîne la création de différents modules. Si je veux comprendre comment le code fonctionne depuis module:InfoboxBuilder/Cultivar, je dois ouvrir Module:InfoboxBuilder et ensuite Module:Infobox.
@Tpt. Encore un histoire classement de module: ne serait-il pas préférable de mettre le code pour Module:Time et Module:GlobeCoordinate dans Module:Outils ? Et ne pas oublier que l'on a déjà module:Date et module:Coordinates. Bref, il faudrait garder une coordination dans la création des modules sous peine de voir leur nombre augmenter et de perdre la connaissance de qui fait quoi pour se retrouver à réinventer la roue. Snipre (discuter) 3 octobre 2013 à 09:39 (CEST)
Je ne suis pas du tout d'accord avec toi. Amhà, il est bien plus simple d'avoir différents modules qui ne font qu'une chose et qui le font bien que d'avoir des gros modules fourre tout qui font tout et qui deviennent des sacs de nœuds difficilement maintenables. Donc je suis d'avis de garder Module:Infobox, de ne pas fusionner Module:Time et Module:GlobeCoordinate dans Module:Outils qui est déjà un gros fourre tout. J'ai créer Module:Time et Module:GlobeCoordinate spécialement pour avoir des API propres pour manipuler ce genre de données complexe facilement dans les autres modules, ce que module:Date et module:Coordinates, ne proposent pas. Je tiens à rappeler que je n'ai créer ces deux modules que comme "test" (d'où leurs localisation sur test2.wikipedia.org) pour savoir si on pouvais vraiment faire de la programmation orientée objet en Lua. La réponse étant positive, tout l'enjeu est de savoir si on adopte ce paradigme de programmation ou pas. Son grand avantage étant une bien plus grande capacité d'abstraction, et donc de modularité. Son inconvénient majeur est, hélàs, sa difficulté d’appréhension pour les non développeurs. Tpt (discuter) 3 octobre 2013 à 13:27 (CEST)
J'ai regardé deux trois infoboxes pour voir comment on pouvait intégrer Wikidata, et c'est vrai que c'est pas toujours évident, donc on n'aura snas doute besoin de plusieurs modules. Cela dit, je ne comprends pas trop comment devrait se faire la répartition des tâches entre module:Coordinates et module:GlobeCoordinates. Etant donné que la possibilité d'utiliser à la fois les formats décimal et dms rend Module:Coordinates assez illisible, je proposerais de réserver un module pour la conversion dms -> décimal et de faire tout traitement de fond des données au format décimal dans l'autre module (ça n'empêche pas de reconvertir en dms après). Les données Wikidata, qui sont toutes en décimal pourraient éviter le premier module. --Zolo (discuter) 3 octobre 2013 à 14:54 (CEST)
Je rejoins Tpt ci-dessus : un module énorme a comme conséquence que 1. le nom (du module) ne correspond pas à la fonction 2. impose de parser/charger un module énorme pour utiliser une petite fonction 3. est bien plus pénible à documenter et à modifier et 4. fait qu'une erreur a bien plus de conséquences. La modularité c'est d'utiliser des briques simple. Toutefois ça impose(ra) d'avoir un index clair de ce qui existe et surtout de ce qui est en prod (code stabilisé) de ce qui relève du test ou du test avancé.
Pour wikidata il me semble qu'on est encore loin d'une utilisation globale, il n'y a donc pas trop urgence je pense. Quant à savoir si il est mieux d'avoir les appels à wikidata "masqués" dans les modules de base (même si c'est via un module dédié) ou bien de laisser à celui qui crée − par exemple − une infobox le choix d'utiliser ou pas wikidata pour tel ou tel champs je n'ai pas d'avis car je n'ai personnellement pas une bonne visibilité de tout ça. Hexasoft (discuter) 3 octobre 2013 à 15:13 (CEST)
@Tpt et @Hexasoft, je vous rejoint sur l'intérêt de disposer de briques avec des fonctions bien précises, mais alors la structure actuelle est bien loin d'aller dans le sens que vous soutenez: en suivant la logique briques, en créant le module:InfoboxBuilder\Composé chimique, je devrais appeler les briques une à une, donc un appel à module:InfoboxBuilder et un appel à module:Infobox. Un module qui appelle un module qui appelle un module, cela indique que l'on a dépassé le stade des briques individuelles. Et selon votre définition module:Infobox est déjà un gros module puisqu'il mélange 2 fonctions: mise en forme d'infobox et extraction de données de wikidata. D'où ma proposition de ne garder qu'un module pour la formation d'infobox et un autre module pour l'extraction de données de wikidata, mais pas trois modules se partageant ces 2 tâches. Et si la formation d'infobox nécessite 2 modules alors il faut supprimer tout ce qui concerne l'extraction de données de wikidata dans module:Infobox et tout transférer dans module:Wikidata.
@ Je vous rejoint sur l'intérêt de faire des modules briques de base, mais si un module possède plus de 3-4 fonctions internes, ce n'est plus une brique. Bref, on a une discussion qui devient philosophique, mais je ne fais que constater que la situation actuelle ne correspond pas à la volonté du projet. Snipre (discuter) 3 octobre 2013 à 22:13 (CEST)
Heu… Une brique de base pour moi ça correspond à une fonctionnalité ou une famille de fonctionnalités (gestion des nombres, des dates, des infobox…). Si un élément est plus complexe il sera plus gros bien sûr. Pour ce qui est de wikidata ça dépend de où tu places la gestion : "dans" le module infobox (transparent pour celui qui construit une infobox) ou "hors" du module (celui qui construit l'infobox se débrouille pour utiliser wikidata). L'un et l'autre n'excluent en aucune manière d'utiliser un module wikidata. Par ailleurs Tpt à indiqué plus haut que les traitements wikidata inclus dans le module infobox ne sont pas satisfaisants et devraient en sortir.
Pour le mode d'utilisation des briques je ne vois pas le problème dans un module qui utilise un module qui utilise un module. C'est même la base de la programmation modulaire. Par ailleurs les module:InfoboxBuilder/Composé chimique et autres ne sont pas des modules per se, ce sont des jeux de données et des traitements associés qui sont utilisés par InfoboxBuilder et jamais utilisés directement.
Ceci dit je ne vois pas trop où tu veux en venir. Les modules « briques » sont des unités de traitement qui ont en leur sein un ensemble (plus ou moins grand) de fonctionnalités liées à une finalité (interfacer wikidata, générer une infobox, traiter des dates, des nombres…), et chaque brique peut utiliser d'autres briques lorsqu'une partie des traitements est déjà regroupée dans un autre module. On peut discuter de la place de telle ou telle fonction, de l'opportunité de séparer ou de regrouper certaines choses, bien sûr, mais à un moment il faut bien choisir en terme de fonctionnalités offertes à ceux qui utilisent les modules ou les modèles liés quel niveau de traitement on intègre et donc quel niveau de liberté on laisse. Hexasoft (discuter) 3 octobre 2013 à 22:46 (CEST)
Pour Wikidata, je proposerais de l'intégrer comme ceci, c'est à dire en donnant la priorité aux données locales. Cela simplifie les choses, et correspond à la manière dont sont traités les interwikis et les fichiers multimédia. S'il y a des demandes pour donner la priorité à Wikidata, on pourra toujours changer après, mais bon si on veut utiliser les données Wikidata, il suffit de supprimer les données locales
Je proposerais aussi de créer une sous-page pour les lignes d'infobox usuelles (dates de naissance, coordonnées etc.). J ai fait un test sur Module:InfoboxBuilder/Stade et ça a l'air de marcher, sauf que je ne comprends pas comment on récupère les éléments du "frame" (j'ai essayé plusieurs manières, mais j'obtiens un message d'erreur du genre "attempt to index global 'frame' (a nil value)".--Zolo (discuter) 3 octobre 2013 à 23:58 (CEST)
@Zolo. Je pense qu'il faut d'emblée intégrer la fonction d'extraction des données de Wikidata comme étant subsidiaire à l'information présente sur la page, comme avec les interwikis. Au vue des grandes questions ayant cours sur Wikidata, je parie déjà que des projets vont refuser d'utiliser les données de Wikidata. De plus, en privilégiant les données existantes dans les articles, on permet une transition douce des modèles: on peut passer du modèle à module sans modifications dans un premier temps et ensuite supprimer au fur et à mesure les données des articles pour utiliser celles de wikidata.
Il faut donc agir sur le code au niveau de module:InfoboxBuilder/Helpers, en intégrant les paramètres nécessaires au module:Wikidata, c.-à-d. qualifier et qualifiervalue.
Ensuite il faut effectuer l'appel au module:Wikidata dans Module:InfoboxBuilder à l'endroit où tu as fait le changement de code.
functionBuilder:buildText(conf)localWikidata=require('Module:Wikidata')ifconf.textthenconf.text=self:getValueForParam(nil,conf.text)elseconf.text=Wikidata:formatStatements(???)endifnotconf.textthenself.infobox:addText({text='<span class="error">Vous devez renseigner le paramètre "text"</span>'})returnendself.infobox:addText(conf)end
Ceci implique toutefois de modifier module:Wikidata pour faire passer en argument les données de wikidata paramètres de la query sous forme de table. Snipre (discuter) 4 octobre 2013 à 15:29 (CEST)
A mon avis, il vaut mieux se restreindre à un paramètre "wikidata" générique dans InfoboxBuilder, et le remplir explicitement avec des choses comme wikidata.formatStatements({property = pXX}). On ne peut pas prévoir tous les manières dont wikidata sera utlisée et formattée, et comme ça on garde plus de souplesse qu'avec une liste de paramètres prédéfinis comme "qualifier" ou "qualifiervalue". Par exemple, pour la propriété "événement clé", il faut faire formatage customisé des dates pour trois qualificatifs (date, date de début, et date de fin). Dans ce genre de cas, il parait nécécessaire d'appeler un module intermédiaire. --Zolo (discuter) 4 octobre 2013 à 17:09 (CEST)
Tu n'as pas à te soucier des différents formats des données de wikidata si tu passes comme argument la variable params dans la fonction formatStatements: l'utilisateur définit les paramètres de la query dans le module spécifique à l'infobox (ex.: ton module:InfoboxBuilder/Stade), le système stocke tout dans une variable et envoie le tout au module:Wikidata. L'avantage, c'est que tu n'auras jamais à te soucier de la fonction Wikidata si tu ne fais que tranférer les paramètres de la query sans appeler la fonction Wikidata. Mais il faut dans ce dernier cas voir pour modifier les arguments du module wikidata pour recevoir une table de paramètres au lieu d'une liste d'arguments. En gros, il faut créer une nouvelle fonction dans module:Wikidata qui gère le format dans lequel les paramètres de la query sont stockés et aini nul besoin de faire wikidata.formatStatements({property = pXX}) dans InfoboxBuilder ou InfoboxBuilder/Helpers ou encore InfoboxBuilder/Stade. Snipre (discuter) 4 octobre 2013 à 17:47 (CEST)
Je ne pense pas que l'on puisse avoir une fonction unique pour tous les cas de figures. Quels paramètres faudrait-t-il spéficier pour obtenir "date de construction : 1945-1955" à partir de propriété événement clé: construction qualificatifs : date de début: 1944 date de fin: 1955 ? --Zolo (discuter) 4 octobre 2013 à 18:40 (CEST)
Je ne vois pas pourquoi tu te focalises sur la question d'une fonction unique pour tous les cas: si on en reste à module:InfoboxBuilder/Stade, module:InfoboxBuilder/Helpers, module:InfoboxBuilder et module:Infobox, la question d'une fonction unique concernant l'extraction des données de wikidata ne se pose pas puisque ces modules ne géreront pas l'extraction des données proprement dite, mais uniquement le transfert des paramètres de la query et du renvoi du module:Wikidata.
Maintenant si tu t'interroges sur comment le module:wikidata va traiter la chose, il faudra simplement ajouter dans module:wikidata une reconnaissance de la structure de la propriété événement clé comme le système reconnait actuellement et traite de manière différente les propriétés avec qualifier de celles sans qualifier.
Le problème n'est lié à la propriété événement clé, mais aux champs de l'infobox qui possèdent plus d'une valeur (comme les paires date début et date fin, ou l'affichage de la valeur du qualifier dans l'infobox, l'affichage des sources dans l'infobox également,...). On voit dès lors que les modules:Infoboxxxx ne sont pas encore dans leur version finale si on tient compte de tous ces paramètres. Snipre (discuter) 4 octobre 2013 à 20:29 (CEST)
J'ai du mal à te suivre. Si on transfert les paramètres de la requête, il faut bien à l'arrivée une fonction qui comprenne ce que cette requête veut dire, et le cas échéant fasse appel à d'autres fonctions pour y répondre. Le problème n'est pas tellement que cette fonction serait trop difficile à développer, c'est qu'elle serait très compliquée à utiliser. Certains paramètres d'infobox, comme "rénovation" dans infobox stade, n'ont pas vraiment vocation à être subdivisées, mais correspondent à des requêtes Wikidata relativement complexes.
Si par, "une reconnaissance de la structure de la propriété événement clé", tu veux dire qu'une requête 'property = PXX, value = QXX' devrait être formatée différemment lorsque PXX est égal à événement clé, ça me parait une très mauvaise idée. Toutes les propriétés sont techniquement identiques, il n'y a aucune raison pour ce qu'une fonction sensée appliquer une requête technique change brusquement de comportement en fonction de la propriété utilisée. Ce qu'on peut faire, c'est ajouter une fonction pour récupérer les informations dans la propriété événement clé et les formater de manière adaptée. C'est très faisable, et même déjà fait. Le problème est donc de pouvoir l'utiliser dans le modèle infobox. Je propose de l'appeler directement (quelque chose comme = wikidata.keydate({event = renovation}). Si je comprends bien, tu proposes de passer par des paramètres. J'imagine que ce serait quelque chose comme "query type= keydate|event= renovation". Je ne vois pas en quoi c'est plus simple, ça demande plus d'effort de maintenance (il faut intégrer tout les paramètres à InfoboxBuilder et à Module:Wikidata), et réduit considérablement la flexibilité si on se retrouve face à un type de requête que l'on avait pas anticipé. --Zolo (discuter) 4 octobre 2013 à 23:37 (CEST)
OK, faut que l'on précise de quoi on parle: jusqu'à présent, on en était à comment intégrer l'extraction des données dans les modules gérant les infobox. La conclusion est qu'il ne faut pas inclure l'extraction de données dans ces modules en écrivant dans les modules gérant les infobox une fonction explicite d'extraction comme wikidata.formatStatements({property = pXX}) parce que si tu définis les arguments à passer dans cette fonction dans le module:InfoboxBuilder, tu devras revenir dans ce module lors de chaque changement de code du module:wikidata impliquant une extension des arguments. En clair, on ne doit jamais voir le terme property, qualifier ou qualifiervalue dans le module:InfoboxBuilder. Donc oui pour wikidata.formatStatements(args), non pour wikidata.formatStatements({property = pXX}).
Non, les propriétés ne stockent pas les informations de manière identique: la plupart des propriétés stocke la donnée qui a de l'intérêt dans la valeur de la propriété, le fameux lieu de naissancepropriété: Berlinvaleur de propriété. Dans le cas de la propriété keydate, la donnée qui de l'intérêt et qu'on veut extraire c'est les dates début et fin qui sont stockées dans le valeurs des qualifiers (P=propriété, V=valeur, Q=qualifier):
Cas 1: P1 = V1 -> on veut V1
Cas 2: P2 = V2 avec Q1= V3 -> on veut V3, et pas V2
On a donc bien des fonctions d'extraction qui sont différentes en fonctions des propriétés. Et tout ceci se fait dans Wikidata, pas dans InfoboxBuilder. Snipre (discuter) 5 octobre 2013 à 09:59 (CEST)
Je sais bien que toutes les propriétés ne sont pas utilisées de la même façon. Ce que je veux dire, c'est que du point de vue technique, elles sont toutes structurées pareil (property, mainskak, datavalue etc.), et ça me paraitrait franchement absurde que la requête "propriété X, valeur Y" fasse quelque chose de différent selon la valeur de X. "propriété X, valeur Y" est une simple requête technique, et il faut que son fonctionnement soit déterministe. On ne peut pas décrêter par avance que telle ou telle propriété devrait toujours être utilisée de telle ou telle façon. On peut très bien imaginer que la propriété événement clé soit utilisée de manière similaire à la propriété date de naissance (par exemple, si on veut une section "biographie" qui liste quelques événements importants. Inversement, on peut très bien imaginer d'utiliser les autres propriétés en se focalisant sur le qualificatifs, comme pour événement clé (pour les monuments historiques, ou pourrait avoir une ligne "partie classée" qui n'afficherait que le qualificatif "pour la partie" d'"instance de: monument historique").
Pardon, je n'avais pas réalisé que ta proposition n'impliquerait effectivement pas de travail de maintenance particulier sur module:InfoboxBuilder, mais ça ne me parait pas l'essentiel. Le principal problème est qu'il faudrait toujours passer par "formatStatements" et ça en ferait une fonction extrêmement complexe et difficile à utiliser. Bien sûr dans beaucoup de cas, la requête sera relativement simple, et on peut penser que "wikidata = wikidata.formatStatements({property=PXX})" est plus compliqué que "property=P18". Mais avec un peu de documentation, ça me parait quand même largement à la portée des développeurs d'infobox, et pour les cas plus complexes, on n'a pas besoin de se restreindre aux requêtes gérables par formatStatements. --Zolo (discuter) 5 octobre 2013 à 11:21 (CEST)
Il peut y avoir une fonction générique qui formate les information de manière standard pour les affirmations qui n’ont rien de particulier, et des fonctions spécialisées à appeler au cas par cas en fonction de ce qu'on veut obtenir. — TomT0m[bla]5 octobre 2013 à 14:09 (CEST)
Oui c'est ce que j'étais en train de me dire aussi :). Je trouve pas ça complètement clair de faire cohabiter deux systèmes, mais au moins ça résoud la question. --Zolo (discuter) 5 octobre 2013 à 14:11 (CEST)
Du point de vue du contributeur ça correspond à deux niveau d'investissements: l'utilisation de l’infobox toute faite, facile, rapide, mais pas forcément optimale ou jolie, et la question qui vient éventuellement après "c'est pas pratique ou ça marche pas dans tel cas, je fais quoi ?" — TomT0m[bla]5 octobre 2013 à 14:33 (CEST)
En fait, il me semble qu'il suffit de dire définir un ordre de priorité: si des données locales, alors données locales, sinon si paramètre Wikidata alors paramètre Wikidata sinon si paramètres property, récupérer tous les autres arguments.--Zolo (discuter) 5 octobre 2013 à 16:14 (CEST)
Bon j'ai corrigé le bug sur module:Infobox qui empêchait l'extraction des données dans Wikipédia ici et j'ai testé une infobox en lua avec uniquement des données de Wikidata cf. Undéc-1-ène.
J'ai ensuite créé une fonction dans module:Wikidata ici qui est sensée extraire les infos utiles à Wikidata dans Wikidata, mais je n'arrive pas à modifier Infobox pour permettre l'utilisation de cette nouvelle fonction ici. Si quelqu'un peut corriger cela, module:Infobox serait totalement insensible à la structure des données ou des besoins de module:Wikidata. Snipre (discuter) 5 octobre 2013 à 14:44 (CEST)
A la limite, si on veut passer l'ensemble des arguments à wikidata.formatStatements sans avoir à les tenir à jour, on n'a pas besoin de fonction particulière. Mais c'est vrai qu'une fonction dédiée, avec les arguments explicitement listés éliminerait les risques de conflits entre les noms de paramètres de module:Wikidata et ceux des modules d'infobox.
J'ai migré Wikidata de Module:Infobox à Module:InfoboxBuilder, parce que ça buggait : on ne pouvait pas ajouter de données locales pour les cases utilisant Wikidata. Je crois que c'était parce que le paramètre "params" était pris en compte après le paramètre Wikidata mais je ne savais pas trop comment changer ça. Ca me parait plus simple de traiter Wikidata dans Module:InfoboxBuilder que dans module:Infobox, mais si ça pose un problème, je suppose qu'on peut faire autrement. --Zolo (discuter) 5 octobre 2013 à 19:15 (CEST)
Merci Zolo pour les corrections et les essais: on a enfin un outil pour construire des infobox avec Wikidata. Il reste pas de boulot pour arriver à un stade similaire aux infobox actuelles. La question est de savoir si la structure actuelle Infobox, InfoboxBuilder et Wikidata est assez stable pour lancer des appels à construire des infobox et travailler avec davantage de personnes ou si on doit encore prendre du temps pour travailler sur ces modules. Snipre (discuter) 5 octobre 2013 à 20:32 (CEST)
La structure de module:Wikidata a des chances de changer, et des paramètres optionnels pourraient être ajoutés, mais à mon avis ce ne seraient que des ajouts ou de la restructuration interne. Je pense que ce que les fonction actuelles avec leurs paramètres actuels devraient continuer à donner le même résultat. Principale exception possible : faudrait-il, à terme, lui faire ajouter la source en note par défaut ? Après il faudrait aussi savoir quelles données de Wikidata sont suffisamment stables pour être utilisées.
Les modules d'infobox semblent encore nécessiter quelques finitions, par exemple pour la gestion des paramètres vides, et éventuellement des catégories de maintenance lorsque des données importantes manquent.
Juste une petite interrogation de forme : dans sa version actuelle, le module n'affiche pas le lien "modifier" en bas d'infobox. Faut-il le remettre sous sa forme ancienne ? A partir du moment où une partie des données sont stockées sur Wikidata, je ne suis pas sûr que ce soit la solution la plus claire. --Zolo (discuter) 6 octobre 2013 à 12:24 (CEST)
Tant que l'on garde la plus grande partie des données dans l'article cela a un sens, mais dès l'on utilisera Wikidata comme source principale, non. Pour l'instant je pense que l'on peut le laisser de côté. Snipre (discuter) 6 octobre 2013 à 13:50 (CEST)
À terme il faudrait deux liens : un vers le code de l'infobox dans l'article et un vers les propriétés de l'élément wikidata, mais la difficulté sera d'indiquer clairement l'endroit précis où modifier la valeur voulue, même pour un débutant, même sous éditeur visuel. — Oliv☮Éppen hozzám?6 octobre 2013 à 19:49 (CEST)
Ceci dit que ce soit des modèles ou des modules il semble difficile d'indiquer clairement (et lisiblement) où trouver / modifier toutes les infos qui viendraient de wikidata, vu qu'il peut y avoir plein de choses différentes. J'ai l'impression que wikidata va rendre assez peu accessible la modification des informations pour le contributeur lambda. Hexasoft (discuter) 6 octobre 2013 à 20:04 (CEST)
Oui il me semble que la seule solution pour règler vraiment le problème serait de ne pas les utiliser directement, mais de les importer périodiquement par bot. Dans les domaines où les données ne changent pas trop souvent ça ne parait pas forcément absurde.
Module:InfoboxBuilder/Stade a l'air de fonctionner, même si, pour ce genre de domaine pas très scientifique, les données ne sont pas forcément très facile à nettoyer et mettre en forme. Je prposerais volontiers d'en parler sur Wikidata:WD:Project Chat avant d'entrer trop dans le détail, l'histoire qu'on ne parte pas tous dans des directions différentes. --Zolo (discuter) 9 octobre 2013 à 09:17 (CEST)
Choix de l'élément Wikidata
Pour l'instant, le module récupère toujours les données de Wikidata lorsqu'il n'y a pas de données locales. Mais parfois, l'article ne correspond pas bien à l'élément Wikidata. Pour gérer cela, chaque infobox devrait avoir un paramètre "Wikidata" que l'on pourrait mettre sur "non" pour désactiver totalement les données Wikidata. Lorsque le logiciel le permettra, il faudrait aussi pouvoir dire "wikidata = QXX", pour que les données Wikidata soient récupérées de l'élément QXX et pas de l'élément lié. Je pense qu'il faudait définir la variable "entity" dans la fonction Builder:build (plutôt que dans buildMixedRow et co), mais je ne sais pas trop comment faire pour faire ça proprement. Une idée ? --Zolo (discuter) 27 octobre 2013 à 08:58 (CET)
Améliorations futures pour infobox en lua
Quelles les améliorations à mettre en place ?
La citation des sources: du moment que les sources ne sont plus forcément présentes dans l'article, il faut ajouter automatiquement les sources ou alors prévoir un paramètre au niveau de l'infobox qui gère l'addition ou non des sources. Mais cela a une grande influence au niveau de InfoboxBuilder puisqu'il faut gérer des nouveaux éléments.
La gestion des champs de l'infobox avec plusieurs valeurs: la date de construction d'un bâtiment correspond en réalité à une période, donc 2 valeurs pour le champ construction, un poste tel que celui d'un politicien consiste également en une période avec 2 dates, certaines valeurs n'ont de sens avec une information supplémentaire, telle la température d'ébullition d'un liquide n'est valable que pour une pression bien précise, ou le nombre d'habitants d'une ville n'est exacte que pour une année définie. Bref, il faut trouver un moyen de gérer ces valeurs multiples à caser dans un champs de l'infobox. Cela se passe principalement dans Wikidata, mais au final Infobox doit pouvoir gérer des retours composés de de plusieurs valeurs en provenance de Wikidata.
Un peu plus de flexibilité au niveau de la mise en page des infobox serait un plus: les infobox actuelles présentent de nombreuses particularités, notamment visuelles et graphiques. Il faudrait pouvoir gérer cela au niveau des modules spécifiques des infobox. Snipre (discuter) 6 octobre 2013 à 13:50 (CEST)
On peut déjà utiliser plisieurs paramètres pour un même champ (voir user:Tpt/test 2, date de naissance). Ca a un aspect relativement complexe, mais je pense que c'est plus ou moins inévitable. Je pense qu'on peut atténuer ça en ayant recours à Module:InfoboxBuilder/Common queries pour les requêtes complexes les plus courantes (par exemple, les coordonnées, qui utilisent la latitude, la longitude, plus quelques paramètres additionnels et obéissent à une syntaxe assez particulière). J'ai essayé pour la date d'inauguration sur Module:InfoboxBuilder/Stade et ça m'a l'air de marcher pas mal.
Du y-a-t-il vraiment un problème pour les sources ? Pour les données Wikidata, ça parait simple : les sources peuvent être automatiquement ajoutées par formatStatements. Il faudrait parfois ajouter une balise references / à la fin de l'article, mais je pense que le mieux est de laisser ça à un bot. Pour les données non-Wikidata, on a deux cas. Soit la source est donnée à l'intérieur du paramètre (|date = 2007<ref>source: XX</ref>), et le nouveau module ne change rien. Soit elles sont fournies dans un paramètre séparé, et dans ce cas là on peut faire la même chose que pour les autres lignes composites. Par exemple, en s'inspirant de Module:InfoboxBuilder/Philosophe : label=date|value = function( frame ) return ShowWithSource( frame, 'date', 'source date' ) end. C'est un peu lourd, mais je ne pense crois pas que les paramètres comme "source date" soient si fréquents que ça. Une autre solution serait d'intégrer un attribut source à Module:InfoboxBuilder, mais j'ai peur que ça ne crée plus de problèmes que ça n'en résoud. Par exemple, dans |coordonnées = 'latitude', 'longitude', la référence doit être commune à latitude et à longitude, alors que dans |date de rénovation = 'date1' (première rénovation), 'date2' deuxième rénovation, on devrait plutôt avoir des références séparées pour les deux rénovations. Il y a tellement de possibilités qu'il me parait mieux de gérer ça au cas par cas. --Zolo (discuter) 6 octobre 2013 à 15:17 (CEST)
Infobox/succession
Bonjour, je vois, suite à une discussion sur le modèle Ouvrage, que vous (Zebulon84 (d · c · b)) savez parser un paramètre. Nous avons perdu en 2009 les flèches cliquables sur le modèle {{Infobox/Diptyque}} (hack incompatible avec l'impression) dont la fonction est maintenant reprise par {{Infobox/Succession}}. Dans ce dernier modèle, le link mal implémenté renvoyait vers l'image de la flèche et a aussi été supprimé. Pour récupérer les flèches cliquables, il faudrait faire quelque chose comme :
Heu, c'est même très simple. Toutefois étant donné la grande simplicité du modèle (donc bien lisible et probablement peu coûteux pour les serveurs) quel serait l'intérêt ? Cordialement, Hexasoft (discuter) 21 octobre 2013 à 20:13 (CEST)
il n'y a pour le moment que 4 "solutions" (ABDA principal, ABDA secondaire, défaut principal, défaut secondaire), mais l'objectif est d'avoir une infobox modulaire unique pour toutes les personnalités, ce qui concernent des dizaines (centaines ?) de domaines et donc potentiellement deux fois plus de "solutions". Cette demande anticipe donc ce problème de ressource aux multiples tests. (Nous sommes désolé de vous apprendre que la signaturea été suspendue pour faute professionnelle) 21 octobre 2013 à 20:33 (CEST)
C'est effectivement assez simple, quelque soit le nombre d'entrées.
Ce qu'il faudrait c'est préciser si le nombre de paramètres va changer, et s'il reste comme actuellement préciser si le mode de sélection reste le même à savoir pour chaque "type" un principal et un secondaire, plus un "défaut" principal et secondaire.
Il est très simple de faire un petit module permettant de faire ça, avec un sous-module de données contenant la liste des "types" et couleurs associées.
À noter que cette approche est assez courante, il pourrait être intéressant de regrouper aussi les chartes d'autre chose que biographie (il existe par exemple un truc similaire pour les tableaux de population) histoire d'avoir un module "charte" où on ajouterait en plus le "thème" (biographie, population…) afin de factoriser des codes qui sont globalement identiques. Hexasoft (discuter) 21 octobre 2013 à 20:47 (CEST)
Le projet modbox avait déjà eu cette idée de regrouper les infobox des personnalités dans un seul modèle en regroupant les éléments comparables (date de naissance,...) dans un sous-module général et en créant des sous-modules spécifiques pour les autres paramètres. Toutefois sache que la résistance sera grande de la part des utilisateurs actuels qui défendent bec et ongles leur infobox avec leurs petites particularités. Il ne reste plus qu'à créer le module:InfoboxBuilder/Biographie. Snipre (discuter) 21 octobre 2013 à 20:57 (CEST)
L'idée est effectivement d'avoir juste une couleurs primaire et une secondaire pour chaque thème, les thèmes pouvant être ajouter au besoin.
Factoriser la chose en y ajoutant de nouvelle option pour d'autres types d'infoboites/modèles peut effectivement être une bonne idée.
À noter ici qu'il ne s'agit que de factoriser les thèmes de couleurs des infobox, en rien changer le code ou les spécificités desdites infobox. Même s'il me semble personnellement intéressant de regrouper les « briques de base » en un seul endroit, tout en laissant à chacun la possibilité de construire au dessus les sur-couches qu'il veut pour gérer les cas particuliers Hexasoft (discuter) 21 octobre 2013 à 21:24 (CEST)
Le principe : Module:Chartes/données contient une table par infobox. Chacune de ces tables contient des entrées contenant 2 (ou 3) chaînes correspondant (dans l'ordre) à la couleur primaire, secondaire, tertiaire (si ça existe). Ces entrées sont indexées par le "type" de charte (dans ton cas "ABDA" ou "default").
On demande donc la couleur correspondant à une infobox (par défaut "biographie"), à un type (par défaut "default") et à une catégorie (par défaut "primaire").
le module acceptant les paramètres venant de l'appel au module ou de l'appel via un modèle il est facile de faire un modèle "charte biographie" qui force le paramètre "infobox=biographie" (idem pour d'autres bien sûr).
Des avis ? Note : ce code n'est pas définitif (en particulier comment on gère les cas par défaut : est-ce qu'un type/catégorie/infobox inexistant est une erreur ou on retombe sur la valeur par défaut, cas actuel). Cordialement, Hexasoft (discuter) 27 octobre 2013 à 20:52 (CET)
Merci
J'ai mis en place le module dans les "modules" de Infobox Biographie [1] et ça marche plutôt bien.
Je cherche un moyen en Lua de récupérer le nom du module lui-même, et non celui de la page ou du module qui l'utilise. Au cas où on le renomme ou au cas ou on l'utilise dans un wiki dans une autre langue. Pour l'instant j'ai perdu du temps mais n'ai rien trouvé. --Rical (discuter) 22 octobre 2013 à 00:57 (CEST)
Un modèle non plus ne sais pas comment il s'appelle. Ce n'est apparemment pas utile aux yeux des développeurs de MediaWiki. Je ne suis d'ailleurs pas sur qu'il y ai beaucoup de langage informatique ou le code exécutable connait le nom du fichier du code source s'il n'est pas préciser dans ce code. — Zebulon84 (discuter) 22 octobre 2013 à 02:01 (CEST)
Oui, mais j'en ai besoin pour pour accéder aux données qui changent d'un wiki à l'autre dans une sous-page du module qui lui est identique. Je vais peut-être poser un bug. --Rical (discuter) 22 octobre 2013 à 13:00 (CEST)
Note : ceci dit tu peux il me semble savoir sur quel wiki tu es. Si le critère de choix "wiki en cours" est suffisant tu peux trier tes accès selon ce critère, plutôt qu'en te basant sur le nom du module. Hexasoft (discuter) 22 octobre 2013 à 13:13 (CEST)
On peut avoir un exemple concret du problème ? Il doit bien y avoir un moyen plus élégant et rigoureux que de récupérer le nom du module lui-même. Si tu veux utiliser un module sur plusieurs wikis, le plus sage est de garder le nom du module identique partout. — Dakdada(discuter)22 octobre 2013 à 15:32 (CEST)
Oui, pour l'instant je fais comme ça, je déclare une variable p.module_name au niveau du module.
L'utilisation est une infobox pour les auteurs dans wikisource, que je rend internationale (messages d'erreurs, noms des arguments du modèle, catégories...). Les traductions sont dans des i18n dans la sous-page /I18N. Il y a un module de base ControlArgs commun (à nom fixe international) et un module multilingue avec son /I18N pour chaque utilisation avec une traduction par wiki. C'est le module de plus haut niveau qui détermine le nom de module pour accéder à la page /I18N adéquate. --Rical (discuter) 27 octobre 2013 à 19:56 (CET)
Gestion des paramètres optionnels d'affichage
Certaines infobox ont des propriétés particulières d'affichage des données. Par exemple lorsque la valeur est particulièrement longue, on peut choisir de masquer son affichage en mode normal. Ce type d'option doit être défini au niveau de l'infobox et gérer au niveau de module:Infobox ou module:InfoboxBuilder. La question est de savoir dans quel module ce genre de détail doit être géré: module:Infobox ou module:InfoboxBuilder ? A terme, il faudra aussi penser à inclure un moyen d'applique une fonction particulière à une valeur pour un rendu graphique genre modèle:NFPA_704/2 ou encore pour générer un lien web qui permette de lier la valeur à une page web (typiquement lorsque la valeur est un identifiant d'une base de donnée on-line et que l'identifiant est utilisé dans l'url de la page web). Bref, quelque chose du genre helper.mixed_n{label = 'InChIKey', params = 'StdInChIKey', property = 'p235', hidden = 1, template = 'NFPA/2', weblink = 'http://pubchem.ncbi.nlm.nih.gov/summary/summary.cgi?cid='}, Snipre (discuter) 27 octobre 2013 à 12:31 (CET)
Masquage:
lien web: partiellement fait. quelqu'un sait-il comment modifier le style par défaut des lien web défini pas lua ?
Mon problème est le suivant: je n'arrive pas à créer le code suivant
Est-ce qu'il serait possible dans la page projet d'avoir une référence vers les pages utilisant le module en question (et pas seulement le code et la doc) ? Cela ferait un bon exemple d'usage "pas chère".
Looking for Lua mentors and tasks for Google Code-in
(Sorry for posting in English, if possible please reply at mw:Talk:Google Code-in) Hi, I'm one of the Wikimedia org admins at mw:Google Code-in. We are looking for Lua related tasks that can be completed by students e.g. rewrite a wikitext template in Lua or fix/extend current templates. We also need mentors for these tasks. You can start simple with one mentor proposing one task, or you can use this program to organize a taskforce of mentors with the objective of getting dozens of templates rewritten/fixed. You can check the current Wikimedia tasks here. The program started today, but there is still time to jump in. Give Google Code-in students a chance!--Qgil (discuter) 19 novembre 2013 à 02:18 (CET)
Bonjour, suite aux modifications effectuées dans le cadre de ce projet, ainsi que celles effectuées par Speculos (d · c · b), je recense deux soucis sur ce modèle :
lorsque le modèle {{Coord}} se trouve déjà dans une page, que les paramètres latitude et longitude sont vides et récupérés dans Wikidata, ça génère le message d'erreur « {{#coordinates:}} : impossible d’avoir plus d’une balise primaire par page » (par exemple, Tribunal social fédéral). Je ne sais pas s'il faut que ce soit le modèle qui doit être adapté ou s'il faut demander à un bot de supprimer le modèle {{Coord}} dans ce cas de figure (ce serait alors un travail récurrent dépenddant des ajouts de coordonnées dans Wikidata).
Pour la question 1, effectivement le fait que des coordonnées sont récupérées par bot et injectées sur Wikidata provoque ce genre de problème, lié à la migration progressive vers Wikidata. De mon point de vue la suppression des modèles coord déjà présents sur les article ne devrait pas se faire par bot, car on risque de ne pas pouvoir détecter les erreurs de géolocalisation, et l'ajout du paramètre "géolocalisation=" ~est difficilement automatisable.
Désolé de mettre le doigt là où ça fait mal mais la situation actuelle est inacceptable. Cette méthode casse toutes les pages qui ont le modèle Coord. Merci de corriger.
Désolé également Speculos mais la longue discussion ne traite pas du même problème (elle concerne la multi-catégorisation). Ici je parle d'une catégorisation à tort. C'est la modification du 23 septembre 2013 à 10:16 qui a amené cette régression. S'agissant d'une brique optionnelle, il n'y a pas à catégoriser. En absence d'argument valable, je vais l'annuler.
Bonjour, pour le message d'erreur "balises primaires", on peut rajouter un "iferror" quelque part (pour l'instant il y en a un dans {{Infobox Subdivision administrative}}, mais en fait ce serait peut-être mieux de le mettre dans {{Coord}} (je pense qu'on devrait essayer de transférer le plus possible de coordonnées vers l'infobox, c'est nettement plus simple à gérer).
Bonjour et merci de ta réponse. Je rebondis sur le dernier point. S'il existe des briques d'Infobox optionnelles c'est qu'il y a des cas où les coordonnées sont facultatives. Les arguments de Gemini1980 (d · c · b) pour l'{{Infobox Montagne}} sont pour moi tout à fait recevables. Comment décider des coordonnées d'un massif montagneux : son centre, son sommet... C'est comme pour un pays : son centre, sa capitale... Donc si le modeliste a décidé d'utiliser une telle brique c'est qu'il a une bonne raison et il faut la respecter.
Pour la solution technique à mettre en oeuvre pour régler le premier point, je vous fait entièrement confiance.
Dans le cas des massifs montagneux il y a en effet une justification, mais je ne pense pas que la méthode utilisée soit la bonne : si on décide qu'il ne faut pas de coordonnées pour les massifs, il faudrait plutôt les désactiver quand l'infobox porte sur un massif : les rendre simplement optionnelles a pour effet de les autoriser là où elles ne sont pas jugées pertinentes, et de ne pas catégoriser correctement les pages où elles seraient nécessaires. Pour la plupart des autres modèles, il ne semble pas y avoir de justification de ce type. Dans certains cas, le modèle n'a apparemment été rendu optionnel que pour éviter les bugs lorsque la page a deux infobox, et là-encore, cette manière de procéder ne permet pas de savoir si l'absence est volontaire ou pas. Il me semble donc nettement plus logique de n'utiliser qu'un seul modèle et de le désactiver lorsqu'il ne faut pas mettre de coordonnées. -Zolo (discuter) 10 décembre 2013 à 12:14 (CET)
Pour ce qui est des massifs, il n'y a actuellement aucun moyen pour les distinguer dans l'{{Infobox Montagne}}. Le paramètre type est le candidat idéal mais vide dans 4/5 des pages. J'ai cherché un moyen automatique de le renseigner pour les massifs à partir de la catégorie:Massif de montagne, mais elle ne contient pas exclusivement des massifs (cherchez l'erreur) ! Je n'ai donc aucune solution pour adapter l'Infobox.
J'ai beau suivre ton raisonnement, j'en arrive toujours à la même conclusion : une brique d'Infobox optionnelle doit être optionnelle.
Pour les montagnes, il devrait être possible de récupérer des informations sur le "type" dans Wikidata. Bien-sûr, il faut que les informations soient déjà renseignées là-bas, mais un bot devrait faire une bonne partie du travail d'ici peu (d:Wikidata:Requests_for_permissions/Bot/PLbot_3).
Pour les autres, dans le principe, une ligne optionnelle doit-être optionnelle bien-sûr être optionnel mais dans la pratique, en comparant les modèles qui ont la ligne optionnelle ou la ligne non optionnelle, j'ai du mal à croire que les choses aient été pensées dans le détail. D'ailleurs, on voit pas mal de modèles (Modèle:Infobox Usine, Modèle:Infobox Abbaye, Modèle:Infobox Musée...) qui utilisent le modèle "optionnel" mais qui dans le même temmps ajoutent une catégorie "à gélocaliser" spécifique. Mettre "géolocalisation = non" sur la page, ou, mieux, faire des modèles capables de déterminer quand il faut ajouter des coordonnées, me parait quand même beaucoup plus net et plus clair. — Le message qui précède, non signé, a été déposé par Zolo (discuter)
+1 On a de gros problème pour trouver les problèmes/erreurs de script. Existe-t-il des modes de debugging ou alors un moyen d'afficher le module étant à la source du problème ? Ou encore une manière de coder qui permettrait d'afficher un texte dans certaines situations causant un bug ? Merci. Snipre (discuter) 4 janvier 2014 à 02:17 (CET)
A cause de cette difficulté de maintenance du code dispersé, j'ai groupé plus de fonctions dans des modules plus gros où il est plus facile de chercher et corriger les bugs.
Mais cela n'empêche pas de s'en servir dans des modèles simples, en ajoutant des fonctions d'interfaces spécialisées.
J'ai même dans certains cas créé des fonctions spéciales de séries de tests unitaires qui aident les développeurs à vérifier si les fonctions de base réagissent normalement dans tous les cas d'usages. Ces fonctions de base retournent en plus un texte de trace à afficher dans une séries de tests élémentaires.
Cela n'alourdit pas beaucoup le code et facilite beaucoup la maintenance à long terme des fonctions les plus critiques et les plus utilisées. Chercher "gener_tests" dans 1 et ":tests:" dans 2
Pour développer je travaille en local dans JEdit ou je peux voir des modules côte-à-côte, ça aide de temps en temps.
Pour les codes d'erreur c'est bien sûr au développeur du module de permettre d'informer précisément des problèmes.
Par exemple il me semble que debug.traceback() permet de récupérer la pile des appels de fonctions, permettant de générer un message d'erreur aidant à trouver l'ordre des appels. Ceci dit si Module:langue retourne une erreur en cas de mauvaise utilisation c'est aussi à la charge du développeur qui appelle ce module de gérer cette erreur.
Le mieux serait d'avoir un exemple concret d'erreur que tu as eu du mal à identifier afin de voir où se trouve le "fautif" Cordialement, Hexasoft (discuter) 4 janvier 2014 à 21:42 (CET)
Ma demande c'est pour corriger les articles de la Catégorie:Page_avec_code_de_langue_invalide. Lorsque on utilise un code langue erroné ( par exemple {{lang|code incorrecte|texte}}) dans un article celui-ci est est catégorisé dans celle-ci. Dans certains articles y a plusieurs appels à ce modèle et ça devient difficile de trouver celui avec l'erreur (par exemple Angela Merkel). Hunsu (discuter) 5 janvier 2014 à 02:54 (CET)
Il faudrait un lien voire une traduction de cette page d'aide qui indique les différentes manières de debugging:
cliquer sur le lien qui apparaît en tête d'article "Erreur de script": cela donne la ligne du module qui pose problème (attention, cela ne veut pas dire que cette ligne de code est erronée)
en mode édition du module, il est possible de faire des tests et de visualiser leur effet sans sauver le code en tapant le nom de l'article contenant le modèle dans la zone "Aperçu de la page avec ce modèle" (située sous le bouton Enregister)
il existe une console de déboggage à la fin de la page, en mode édition du module, qui utilise mw.log() pour transférer des infos du code dans la console, mais je n'ai pas pu tester cette fonctionnalité, si quelqu'un avait des infos, cela serait bien.
Sur ce dernier point j'ai joué un peu avec. Sauf si j'ai raté des fonctionnalités c'est assez limité en ce sens que ça ne permet pas vraiment de se mettre dans le contexte d'un article : ça crée une "frame" bidon, il semble compliqué dans la plupart des cas de lui donner dans la console des valeurs (par ex. les paramètres) ou simplement de simuler l'espace encyclopédique. Par contre c'est pratique pour tester des fonctions (on peut appeler une fonction précise avec les paramètres qu'on veut, et ça retourne le résultat, c'est un peu du Lua en ligne de commande dans l'espace du module en cours).
À noter que dans l'exemple indiqué il ne s'agit semble-t-il pas d'une erreur de script mais du module langue qui génère une erreur "structurée" (insertion dans une catégorie spécifique). La question est de savoir ici par quel modèle/module intermédiaire l'appel invalide au module langue est effectué.
À part modifier le module langue pour qu'il génère un "gros texte d'erreur descriptif" (par exemple en récupérant la callstack) ça me semble difficile surtout si l'appel vient d'un modèle, ces derniers n'ayant aucun moyen de reconnaître une erreur d'appel même si elle leur bouffe la jambe Hexasoft (discuter) 6 janvier 2014 à 18:07 (CET)
Je ne connais pas le Lua mais je vois dans le module qu'une clé clé de tri semble avoir été prévue par Zebulon84 (d · c · b) (en WikiBreack depuis presqu'un mois) : l'argument codeArg. Quelqu'un saurait comment l'utiliser ? --FDo64 (discuter) 7 janvier 2014 à 12:55 (CET)
FDo64 : Les articles sont classés selon le code de langue erroné. Par exemple c'est le code est CodeErroné donc la clé est CodeErroné. Mais ça n'aide pas beaucoup. J'ai réussi à corriger l'article Angela Merkel mais il m'a fallu voir tous les modèle {{lang}} qui y sont présent et c'était difficile de trouver celui avec l'erreur. Hunsu (discuter) 7 janvier 2014 à 15:32 (CET)
Hexasoft : Non y a de problème avec le module Langue. Je voudrais juste qu'on lui ajoute une fonctionnalité. Par exemple si on l'appel comme suit :
{{lang|codeErroné|texte}} je voudrais qu'il affiche Erreur : code langue erroné texte. et non pas texte. Actuellement l'affichage ne diffère pas s'il y a erreur ou pas. Si on lui ajoute cette fonctionnalité on a qu'à chercher Erreur : code langue erroné en mode lecture pour trouver le modèle responsable de l'erreur. Hunsu (discuter) 7 janvier 2014 à 15:42 (CET)
Hmm… Pas forcément opposé à cette idée. Toutefois combien d'articles sont concernés ? Il faudrait éviter de voir apparaître un tel message sur des 100aines d'articles d'un coup, non ? Hexasoft (discuter) 7 janvier 2014 à 15:54 (CET)
Hunsu : : j'ai modifié le code. Voir par exemple Transport ferroviaire au Liechtenstein (que j'ai laissé erroné). Peux-tu valider que 1. cette modification te conviens et que 2. tu ne vois pas d'effet secondaire problématique (j'ai regardé un peu mais il y a tellement d'utilisations que j'ai pu rater des choses). Cordialement, Hexasoft (discuter) 10 janvier 2014 à 11:40 (CET)
dans Aide:Tableau (aide détaillée) on trouve l'équivalence code wiki / code HTML, je pense donc qu'on peut utiliser celle qu'on veut (d'ailleurs techniquement utiliser le code HTML doit éviter la conversion code wiki → code HTML).
Il faut par contre je pense être vigilant et utiliser les mêmes transcriptions car il me semble (de mémoire) que mediawiki n'autorise que certains tags/balises : le risque quand on fait du HTML direct est d'utiliser des codes qui mediawiki va filtrer.
Suite à un sondage sur l'implémentation de Wikidata phase 2, une critique régulière est l'absence de référence ajoutée avec les valeurs en provenance de Wikidata. Je voudrais lancer ce module:référence qui aurait pour but de faire le travail des modèle:Lien web, modèle:Article et modèle:Livre voire modèle:Harvard..
L'idée serait de fournir les données sous forme de table et de ressortir la référence sous forme de string. Des avis ou des conseils ? Snipre (discuter) 19 janvier 2014 à 15:58 (CET)
Sur WP en anglais il y a en:Module:Citation/CS1. Sur WP en hongrois ils ont presque fini en simplifiant au maximum la liste des paramètres pour éviter l'usine à gaz des autres WP et ça génère pas mal de discussions (et de tensions alors je ne regarde ça que de loin). — Oliv☮Éppen hozzám?19 janvier 2014 à 18:25 (CET)
Problème pour tester un module
Bonjour,
J'ai modifié le module lien web (Module:Utilisateur:Hunsu/langue) pour qu'il affiche consulté en si le jour n'a pas été fournée dans la date. Pour cela je teste avec le pattern ^(%d%d? ). Maintenant je voulais tester le résultat alors je l'appelle avec la syntaxe :
{{#invoke:Utilisateur:Hunsu/langue|lienWeb|url=url|titre=titre|consulté le = 22 janvier 2013}} : le résultat est : {{#invoke:Utilisateur:Hunsu/langue|lienWeb|url=url|titre=titre|consulté le = 22 janvier 2013}} (ce module n'existe plus Zebulon84 (discuter) 3 août 2014 à 17:42 (CEST)).
Heu… Pourquoi les parenthèses ? Sinon pour mémoire il est possible de tester ses fonctions à la volée dans la zone en bas, lorsqu'on édite un module. Tu peux donc faire directement des commandes Lua ou appeler certaines de tes fonctions avec des paramètres à toi pour tester. Par ailleurs dans la console de test les commandes "log" s'affichent comme du texte, permettant de faire du debug. Hexasoft (discuter) 22 janvier 2014 à 21:00 (CET)
Rical : Non ça ne marche pas avec les % en double (je crois qu'on double les % pour qu'il chercher un %). Le problème là c'est que les paramètres url et titre (et n'importe quel autre paramètre) ne sont pas "arrivés" au module.
Hexasoft : Comment je peux tester mon module dans le console? Je ne sais comment écrire ma commande.
Pour tester tu édites ton module. Dans l'édition tu vas tout en bas (après la zone d'édition) et tu as un truc qui s'appelle « Console de débogage ». Là-dedans tu peux taper des commandes Lua. Tu peux aussi appeler des fonctions de ton module en cours (à savoir : la "table" de ton module s'appelle "p").
Exemple : en éditant ton module j'ai écrit dans la zone de débogage : print(string.match("23 décembre 2012", '^(%d%d? )')) ce qui m'affiche "23". En tapant print(string.match("décembre 2012", '^(%d%d? )')) ça m'affiche "nil", ce qui semble indiquer que ton test fonctionne, donc le problème vient d'ailleurs (pas le temps de regarder, mais c'est peut-être un problème de nom de variable ou de paramètre mal récupéré). Hexasoft (discuter) 22 janvier 2014 à 21:37 (CET)
Ce qui m’embête c'est que j'ai juste ajouté ce testé et j'ai rien changé d'autre au module d'origine qui fonctionne bien. Hunsu (discuter) 22 janvier 2014 à 21:54 (CET)
Oui, mais comment tu testes ton module ? En l'appelant directement ? Tu évoques le fait que les paramètres ne sont pas "arrivés" au module : il y a une différence entre appeler un module directement et invoquer un module à travers un modèle. Les paramètres sont dans le premier cas dans frame.args et dans le deuxième cas dans frame:getParent().args. Si la fonction initiale suppose que les paramètres viennent d'un modèle elle ignorera les paramètres passés directement. Si c'est le cas le mieux est de créer un modèle temporaire et de tester l'appel à ce modèle (qui appelle ton module). Hexasoft (discuter) 22 janvier 2014 à 22:13 (CET)
Bonjour, je ne suis pas certain d'être sur la page adéquate, mais je tente quand même. Quelqu'un saurait-il corriger ma modification sur l'{{Infobox Prélat catholique}} visant à afficher la valeur de l'identifiant Catholic Hierarchy présente sur Wikidata, sachant que le code en question vient d'ici ? Merci par avance. — Ayack♫♪1 février 2014 à 17:09 (CET)
J'ai bien conscience que nos pages ne sont pas prévues pour peser plus d'un méga, mais le Lua devrait quand-même pouvoir tourner une petite minute, comme PHP avec Apache, non ? JackPotte ($♠) 15 février 2014 à 19:43 (CET)
Bonjour. Non, le temps d'exécution de Lua est beaucoup plus limité que le temps de rendu global. Il n'est que de 10 secondes, je crois. Donc les pages incluses via un module Lua doivent impérativement être légères. Un problème similaire s'est posé sur ce projet lors de la conversion de {{Documentation}}. Cordialement, Orlodrim (discuter) 15 février 2014 à 20:03 (CET)
Je ne pense pas qu'une "upgrade" se fasse un jour. L'objectif numéro 1 de Scribunto était justement d'éviter des temps de parsing trop long et je ne pense pas que les devs acceptent de revenir sur ce genre de limites. Tpt (discuter) 25 février 2015 à 19:01 (CET)
@Zolo: oui, et il devrait être assez facile, car (autant que je sache) la bibliothèque de Scribunto est basé sur le module de la Wikipédia anglophone. --Ricordisamoa19 février 2014 à 13:53 (CET)
J'aurais besoin de l'avis et de l'aide pour finaliser la gestion des styles pour les infobox en lua (via les modules infobox et infoboxbuilder). Un des problèmes est de faire passer les données concernant le style propre à chaque infobox dans le module:infobox. J'ai codé un tableau qui stocke les données sous la forme suivante:
style[1] = "background: #EEEEEE"
style[2] = "text-align: center"
Le tableau est ensuite transféré dans module:infobox pour être concaténé en un seul string avec les ";" entre chaque donnée.
Une première difficulté est de créer le tableau: on ne peut pas en effet coder les données avec la structure suivante
car les tirets ne sont pas acceptés dans les clés du tableau.
Bref, si quelqu'un a une idée pour coder et transférer cette information, je suis preneur. Snipre (discuter) 15 mars 2014 à 11:26 (CET)
Je confirme : la forme { XXX=YYY } peut se généraliser en {["XXX"]=YYY} (en fait la première est un "syntactic sugar" du second, mais − comme souvent − limité par le jeu de caractère des anglophones). De la même façon ceci permet d'accéder à des clés de tableau qui contiennent des caractères interdits (ce qui comprend les caractères accentués pour nous) : table["école-ouverte"].
Pour compléter Combelle tu peux aussi créer des tables multi-entrées avec des clés spécifiques : { ["clé1"]="valeur1", ["clé2"]="valeur2"}. Sans précision ce sont des clés numériques dans l'ordre (1, 2…). Cordialement, Hexasoft (discuter) 24 avril 2014 à 20:05 (CEST)
Module de conversion ?
Hello,
est-ce qu'on a actuellement un module gérant les conversions d'unités ? Du genre °F→°C, m→pouce, …
Je fais des tests pour un remplacement de modèle de températures, et plutôt que de réinventer la roue autant utiliser les éléments existants.
Aide à la création et à l'emploi de "modèles de sources"
Bonsoir à toutes et à tous, Quelqu'un de "Scribunto" peut-il m'aider dans le cadre de cette requête, que j'ai adressée aux dresseurs de bots, mais hors sujet ? Merci infiniment d'avance, amitiés, Jean GUERIN - Paris (discuter) 27 avril 2014 à 23:34 (CEST)
Références ou discussions / décisions justifiant la demande :
Mes propres créations de "modèles de sources" et de bibliographies à base de modèles de sources, à mon sens conformes aux spécifications WP sur le sujet :
Nature de la demande :
Bonsoir à toutes et à tous,
Demande connexe à l'avant-dernière ... En tant que créateur de "modèles de sources" et utilisateur de ces modèles dans les bibliographies, il me semble que les deux procédures suivantes aideraient à la généralisation de cet usage :
Un script se déclenchant automatiquement à l'enregistrement d'un Modèle:Ouvrage ou de quelques autres modèles comme Modèle:Article et Modèle:Lien Web qui propose de le transformer immédiatement en modèle de source, avec rattachement à une catégorie de modèles de source ;
Un script à déclencher à partir de la section "Bibliographie" d'un article, pour aller naviguer dans les catégories de "modèles de source" et choisir ceux que l'on veut utiliser dans cette bibliographie, et permettant d'obliquer vers le modèle Ouvrage et le premier script en cas d'insuccès de la recherche. En somme, généraliser à la partie "Bibliographie" d'un article les ajouts rapides de catégories et de portails.
Le tout pour CREER de nouveaux "modèles de sources" et bibliographies, évidemment - pas question de reprise automatique. Merci à qui voudra bien s'en occuper, sauf si je ne suis pas sur la bonne page ! :) Amitiés, Jean GUERIN - Paris (discuter) 27 avril 2014 à 19:18 (CEST)
Hello Jean GUERIN 2, malheureusement ta demande demande deux choses différentes et ni l'une, ni l'autre n'est du ressort d'un bot. Pour ce qui est de la détection lors d'un Modèle de référence, il faudrait créer un moteur en WP:Lua, pour ceci, tu peux éventuellement regarder avec Projet:Scribunto. Concernant ta seconde demande, il faut voir directement avec les demandes de scripts (désolé je ne retrouve plus la page concernée). Bonne continuation --Scoopfinder(d)27 avril 2014 à 19:38 (CEST)
Je ne crois pas que c'est possible de le faire en Lua. Une solution est d'analyser les dumps de Wikipédia et lister les ouvrages (sources) utilisées dans plusieurs articles et en faire un modèle de source. C'est possible de faire ça avec un bot. Hunsu (discuter) 15 mai 2014 à 10:36 (CEST)
Bonjour Hunsu, Bonjour à toutes et à tous, Merci Hunsu : ! Ma demande est en fait très modeste. Il s'agit d'une aide à la saisie basique ... Le processus actuel est laborieux :
Créer le modèle (ouvrage ou autre ...) ;
Créer le modèle de source (créer le titre, copier-coller du modèle, copier-coller la tripaille - catégorie et autre ...) ;
Copier le titre du modèle pour le reporter dans les biblios des articles ...
Quand on crée des dizaines de modèles de source, ça finit par représenter des heures de saisie pure sans aucune valeur ajoutée. Mon propos est donc de disposer de scripts (genre macros Excel) pour aider à cela, sans plus. Maintenant, pour aller chercher des ouvrages dans les biblios d'articles existants pour en faire des modèles de sources, c'est très dur : chacun a créé ces ouvrages "à sa sauce" (données simples, données montées dans des modèles, avec un contenu très variable ...). Ca me semble surhumain, même pour des bots ... :D Amitiés, Jean GUERIN - Paris (discuter) 15 mai 2014 à 10:52 (CEST)
J'ai essayé de le tester dans Module:Bac_à_sable, mais ça ne marche pas. J'ai essayé plusieurs combinaisons : ajouter une table p, un frame, etc. sans plus de résultats.
Merci de me dire ce qui ne colle pas afin de corriger l'aide,
P.S par ailleurs, j'ai proposé une fusion de Wp:Lua et Aide:Module, voir les PdD de ces pages-ci.
Hello,
j'ai testé le code et il fonctionne comme prévu. Ceci dit c'est du Lua, pas du Scribunto, moi j'ai testé avec un interpréteur Lua. Cordialement, Hexasoft (discuter) 15 mai 2014 à 09:50 (CEST)
Je confirme, ce code fonctionne très bien mais n'est pas adapté pour fonctionner sur Wikipédia. Attention, les paramètres transmis dans frame.args ne sont que des 'string', alors que la fonction factorielle attend un 'number'.
ps : il ne faut pas mettre 'Module:' après '#invoke:' : {{#invoke:Bac à sable|factorielle|5}}
localp={}localfunctionfactorielle(n)ifn==0thenreturn1-- on renvoie la valeur 1 quand le paramètre vaut 0elsereturnn*factorielle(n-1)endendp.factorielle1_5=function()localtabResultat={}forindex=1,5dotable.insert(tabResultat,index..'! = '..factorielle(index))endreturntable.concat(tabResultat,'<br>')endp.factorielle=function(frame)ifframeandframe.argsandtonumber(frame.args[1])then-- appel par invoke et le premier paramètre est un nombrereturnfactorielle(tonumber(frame.args[1]))elseifframeandtype(frame.getParent)=='function'andtonumber(frame:getParent().args[1])then-- appel par modèle dont le premire parmaètre est un nombrereturnfactorielle(tonumber(frame:getParent().args[1]))elsereturn'le premier paramètre doit être un nombre'endendreturnp
Zebulon84 :Il te manque un "}" non (celui de la table du départ) ? Pour ma part j'ai tendance à expliciter la table : local p = {} puis function p.factorielle(…). Hexasoft (discuter) 15 mai 2014 à 12:19 (CEST)
Ah ok ! J'ai cru que tu créais p en mettant directement inline des fonctions dedans . Mais en fait ça ne cadre pas avec le reste. Pas réveillé, moi… Hexasoft (discuter) 15 mai 2014 à 14:46 (CEST)
Merci beaucoup pour cet exemple Zebulon84 (d · c · b) ! Je pense qu'il serait bien de créer le module correspondant « Module:Factorielle » afin de compléter la bibliothèque d'exemples simples pour les débutants. Dans la documentation, on pourrait mettre la comparaison entre le langage Scribunto et Lua, d'ailleurs je ne savais pas qu'ils étaient à ce point différents.
Oupse, j'avais fait une belle erreur de frappe en mettant « Module » après #invoke,
En effet, j'ai lu plus de « function = p.factorielle » que « p.factorielle = function »
J'ai essayé de comprendre comment ce module fonctionne, mais c'est vraiment difficile pour moi !
Je ne vois pas à quoi sert la fonction p.factorielle1_5. Qu'on fasse {{#invoke:Bac à sable|factorielle1_5|3}} ou {{#invoke:Bac à sable|factorielle1_5|4}}, le résultat est le même : 1! = 1 2! = 2 3! = 6 4! = 24 5! = 120
La fonction p.factorielle1_5 ne sert qu'a afficher les factorielles des nombre 1 à 5, comme l'exemple de Wikipédia:Lua#À propos de Lua. C'est effectivement assez inutile.
Je vais créer le « Module:Factorielle » ce soir ou demain, en essayant d'expliquer pourquoi il faut faire tous ces tests.
il n'y a que très peu de différences entre Lua et Scribunto. Ce qui change surtout c'est la façon d'interagir avec les articles (réception des paramètres, création de la sortie).
La fonction factorielle1_5 ne prend aucun paramètre, il est normal qu'elle fasse la même chose dans les deux cas… C'est la fonction factorielle qui traite les paramètres.
Pour les fonctions il y a plusieurs façons de les déclarer, équivalentes (par exemple function p.fact(frame) suffit également, sans "=").
@Hexasoft (d · c · b), d'après ce que j'ai cru comprendre il y a des différences de mots-clés. Dans l'exemple présent sur wp:Lua, le mot-clès « print » est utilisé alors qu'il ne semble pas être présent en Scribunto ! Étrange pour une page d'aide intitulée « Wikipéida:Lua » !
Oui, j'ai déjà essayé de bien me pencher sur l'aide ! J'ai du mal, mais bon je n'ai jamais programmé . Enfin bon, si j'espère y arriver un jour — si j'ai le temps !
@ Zebulon84 (d · c · b), histoire de ne pas polluer cette PdD avec une demande stupide, j'ai cherché à savoir si il existait des explications plus détaillées. Suite à ces recherches, je suis tombé sur Module:Mop créé par Lydie Noria (d · c · b) le 24 avril dernier, du coup j'ai créé Module:Module Factorielle afin de faire un nouvel exemple pour aide:module.
Je suis très preneur d'exemples commentés pour les débutants, parce que je ne comprends pas toutes les différences entre Module:Module Factorielle et ton exemple ci-dessus ! Par exemple, que signifie le mot-clès elseif ?
Juanes852 : print entre dans les "différences de gestion de la sortie" car il sert à afficher des choses. Un module n'affiche rien, il retourne un contenu qui sera ensuite intégré dans la page. À noter que print doit pouvoir marcher dans la console de debug mais c'est une autre histoire.
J'avais déjà regardé, mais je n'avais malheureusement pas compris .
Est-ce que c'est la même chose qu'en php ? « elseif, comme son nom l'indique, est une combinaison de if et de else. Comme l'expression else, il permet d'exécuter une instruction après un if dans le cas où le "premier" if est évalué comme FALSE. Mais, à la différence de l'expression else, il n'exécutera l'instruction que si l'expression conditionnelle elseif est évaluée comme TRUE » (voir http://www.php.net/manual/fr/control-structures.elseif.php).
Hello, j'ai supprimé. Pour le BASENAME bonne question. J'avoue ne pas trop me rappeler. Je sais que j'avais eu des problèmes à une époque quand les éléments de documentation étaient "intégrés" (appels insérés par mediawiki) avec les catégories, qui n'étaient pas évaluées au bon moment. Si ça pose maintenant problème pas de soucis pour virer ! Hexasoft (discuter) 26 mai 2014 à 12:47 (CEST)
Je connaissais pas cette opération, succintement ça fait quoi ? Un simple apport avec conservation d'histo ou les modifications sont synchroniqées ? — TomT0m[bla]16 mai 2014 à 13:00 (CEST)
Comme je suis l’auteur et seul contributeur de ce modèle, il y a pas de problème d'imports alors :) Je peux faire ce que je veux en tant que détenteur des droits d'auteur. Je me contenterai d'un copier coller du code.. — TomT0m[bla]17 mai 2014 à 10:55 (CEST)
Aligner à droite une infobox ?
Bonjour,
Je recherche comment aligner à droite une infobox créée dans un autre wiki sur le modèle Infobox V3. Quelqu'un peut-il, s'il vous plaît, m'indiquer où chercher l'info ? D'avance merci. Gtaf(discuter)19 mai 2014 à 20:01 (CEST)
Hello,
sur Discussion module:Date une IP demande la possibilité de connaître le CET/CEST. Au départ je n'ai pas fait attention mais je me rends compte que ça ne doit pas être possible du tout : os.date ne permet que d'obtenir l'heure UTC ou l'heure locale du serveur, pas l'heure "locale selon la timezone de l'utilisateur qui consulte l'article" (information de toute façon indisponible pour les visiteurs sous IP). D'ailleurs quelles horaires voit un visiteur non connecté dans - par exemple - les historiques ?.
J'ai bon ou quelqu'un voit une solution miracle ? Cordialement, Hexasoft (discuter) 20 mai 2014 à 10:41 (CEST)
Alors j'ai trouvé que lang:formatDate() permet d'utiliser le "pseudo-fuseau horaire" utilisé par les parserfunctions du type #time. On peut alors faire mw.getContentLanguage():formatDate("I", nil, true) pour obtenir un texte contenant 0 ou 1 selon CET ou CEST. C'est toutefois un peu lourd car visiblement ça ne donne que des chaînes et pas une table (comme os.date() par exemple), ce qui veut dire qu'il faut éventuellement extraire les infos de la chaîne s'il y en a plusieurs. Hexasoft (discuter) 20 mai 2014 à 14:47 (CEST)
Module de classement final d'une course cycliste et Lua, ou générer un tableau à partir de Lua
Bonjour. Il y a quelques mois, je me suis reconverti dans le cyclisme. Grand fan de modèles, j'utilisais jusqu'alors Modèle:Classement final pour afficher les premiers arrivés d'une course cycliste de l'UCI. Malheureusement, n'indiquer que les dix ou vingt-cinq premiers, c'est bien, mais j'ai la possibilité et le temps de faire mieux. J'ai créé Modèle:Classement final exhaustif, mais s'agissant d'un modèle classique, générer le tableau se fait impérativement (apparemment) via {{!}}. Tout le problème réside là, ce petit modèle est très consommateur d'inclusions, et j'approche le seuil fatidique avant 40 classés sur Internationale Wielertrofee Jong Maar Moedig 2014. L'avantage d'un modèle, c'est qu'il peut évoluer au fil des années sans devoir intervenir sur les articles, qui ne contiennent que les données, par opposition au modèle qui contient la façon d'afficher. Dans Discussion utilisateur:JÄNNICK Jérémy/Cyclisme, j'ai préparé un patron de texte pouvant me permettre d'afficher les données dans l'article.
Il y a quelques temps, j'avais découvert Lua et regardé un peu ce dont il s'agissait. Autant je comprends assez bien les modèles, ici, je n'y ai absolument rien compris à cette syntaxe, mis à part deux ou trois choses. Est-ce qu'il serait techniquement possible de générer un tableau similaire à celui de l'article sans dépasser les limites imposées par Media-Wiki ? Si quelqu'un me programme la base et les trois premières places, je pourrais par copié-collé écrire les autres. Cordialement, JÄNNICK Jérémy (discuter) 27 juin 2014 à 16:51 (CEST)
Question subsidiaire : si ce modèle/module était créé, est-ce qu'il serait possible qu'à l'ouverture d'une page, seuls les dix premiers soient afficher, et que le reste se déroule lorsque l'on clique sur un lien, un peu comme les schémas des infobos des lignes ferroviaires ? Cordialement, JÄNNICK Jérémy (discuter) 27 juin 2014 à 16:59 (CEST)
Bonjour, je cherche un volontaire pour écrire ce module qui devra reprendre les fonctionnalités du modèle:Palette, y compris la gestion des erreurs et qui permettrait de s'affranchir des exceptions actuelles. En particulier, ce modèle ne fonctionne pas avec les palettes avec paramètres, ce qui est source d'erreurs.
J'ai créé la page Modèle:Palette/Test qui contient tous les cas de tests et les évolutions demandées.
Bien entendu, je reste à la disposition du développeur pour répondre à ses questions et l'aider dans ses tests.
Si on veut avoir des infobox en Lua, il faudrait convertir Modèle:Infobox/Géolocalisation multiple. Mais ce n'est pas évident, il y plein de sous-modèle partout, avec des recours à de l'html/css que je ne maîtrise pas trop. Si quelqu'un connait déjà un peu le modèle, il serait tenté par faire la conversion ? --Zolo (discuter) 16 juillet 2014 à 16:23 (CEST)
J'ai l'intention de faire cette conversion, il faut juste que je décide de m'y mettre. Je voudrais finir quelques travaux sur les modèles biblio auparavant. Zebulon84 (discuter) 16 juillet 2014 à 18:04 (CEST)
L'article Modèle:Barre latérale est proposé à la suppression
Après avoir remarqué que le modèle {{lien web}} affichait « consulté en 2 août 2014 » au lieu de « consulté le 2 août 2014 », je me suis penché sur la question. Il se trouve que c'est la fonction References.affichageLiensExternes du module:Biblio/Références qui pose problème. Il y a un switch qui permet de reconnaître le format : si on a trois mots, on a une date exacte, donc « consulté le ». Or le regexp utilise %w, qui, si la locale sur wp:fr est bien positionnée (voir ici), devrait contenir des caractères tels que û. Mais ici il ne match pas « août » et l'affichage n'est pas le bon. Je pensais à deux solutions :
la plus propre, regarder si y'a moyen de modifier la locale pour inclure ces caractères (locale qui a peut-être été modifiée récemment ???)
la plus rapide, rajouter le « û » de août, le « é » de février, décembre, etc..
J'ai vu une page avec des problèmes de performance : certaines références n'étaient pas affichées car on dépassait les 10 secondes de calcul lua, surtout du à gsub. Donc j'ai cherché à optimiser les patterns, mais j'ai été trop loin ici.
J'ai donc évalué la rapidité de :
[^ /-]
[%wûé]
%w avec mw.ustring (le û en fait parti)
Le plus rapide est le premier, le deuxième est 10-50% plus lent (suivant les chaines) (et équivalent à %w en fait), le dernier est 100 fois plus lent (il faut éviter mw.ustring si le pattern ne le nécessite pas, mais il faut donc faire attention avec %w).
J'en vais donc de ce pas corriger (pour la troisième dois) cette pattern.
Ceci dit, si on peut faire modifier une variable pour que les lettres accentuées (au moins celles courantes en français) fasse partie de '%a' de string sur fr.wiki, ça limitera certainement les bugs de ce style à l'avenir. En attendant j'ai ajouté ce détail sur la documentation en français. Zebulon84 (discuter) 1 août 2014 à 19:23 (CEST)
Merci pour la correction !
Concernant la locale, en fait ils en parlent sur cette page (chercher « current locale ») pour %l. Mais du coup si je ne dis pas de bêtises, %w inclut %l. Peut-être faut-il voir au niveau de mediawiki ou des paramètres du lua ?
Bonjour, je suis nouveau dans cet univers, et j'aimerai savoir comment on peut analyser une page caractère par caractère.MGK (discuter) 1 août 2014 à 17:46 (CEST)
j'ai une mission à confier. J'aimerai faire fonctionner la syntaxe suivante :
{{#property:P348|of=Q7027060}}
Il s'agit d'une requête vers la propriété P348 de l'objet Wikidata Q7027060 pour déterminer la version courante de LiveRC. J'ai intégré cette syntaxe à Wikipédia:LiveRC/Version. Problème : ça ne fonctionne pas en dehors de Wikipédia:LiveRC, c'est à dire que préciser l'item n'a aucun effet, on ne récupère que la propriété de la page courante, donc rien la plupart du temps. J'ai contourné le pb en ajoutant un test et en écrivant la version en dur si on n'a pas l'item, mais ce n'est pas l'idéal.
Si j'en crois le bug 47930, récupérer un propriété d'un page quelconque est tout de même déjà possible via Lua (sous-bug 67538).
Or donc, il faudrait qu'un gentil programmeur Lua me ponde un module qui fasse ce travail et que je puisse ensuite intégrer dans Wikipédia:LiveRC/Version.
J'ai bien essayé de voir Module:Wikidata et ses sous-pages mais j'ai du mal et je pressens que ce sera plus rapide de demander à quelqu'un qui sait que d'apprendre moi-même Lua...
Voir mw:Extension:Wikibase Client/Lua pour les fonctions disponibles. Lorsque cette page sera mise à jour avec un id comme paramètre possible pour la première fonction, on pourra faire la fonction que tu demande.
Plus en détail : D'après [3] et [4] il suffit de transmetre un id à la fonction mw.wikibase.getEntityObject pour obtenir ses données wikidata.
Or lorsque je tape localentity=mw.wikibase.getEntityObject("Q42") dans la console j'obtiens le message Erreur Lua dans mw.wikibase.lua à la ligne 74 : Access to arbitrary items has been disabled..
Pour le moment la seule chose que je sais obtenir pour un autre id, c'est le label et le lien fr.wiki de cet id.
Catégorisation des articles labellisés sur d'autres wikis
Bonjour,
Wikidata permet dorénavant d'indiquer si un article est labellisé dans une langue donnée [6]. La fonction principale de {{Lien AdQ}} et {{Lien BA}}, afficher des étoiles dans la liste des interwikis pour les articles labellisés dans une autre langue, va donc être gérée directement par MediaWiki.
Est-ce possible de créer un module pour effectuer automatiquement cette catégorisation à la place des modèles {{Lien AdQ}} et {{Lien BA}}, en consultant les données présentes sur Wikidata ? (celui-ci pourrait alors être appelé directement dans {{Portail}} ou {{Méta lien vers portail}}, par exemple).
Orlodrim : à tester : {{#invoke:Categorie AdQ | badgesCategories }}
Pour le moment, pour pouvoir tester, les catégories sont affichées et non liées. Il suffira de retirer les deux-points du string.format (actullement ligne 168) pour catégoriser les pages.
Pour limiter les risques d'erreur lors de mise à jour des liens de langue ou de badge il est possible de déporter les tables dans un sous-module de données.
Ça marche, merci ! C'est une bonne idée de mettre les tables dans un sous-module. Idéalement, il faudrait le charger uniquement lorsque la page a au moins un badge, afin qu'il ne soit inclus que dans un nombre limité de pages (comme ça on peut semi-protéger la sous-page plutôt que de la protéger entièrement). Orlodrim (discuter) 2 septembre 2014 à 20:16 (CEST)
Si tu as envie de réorganiser ça mieux, vas-y, j'ai juste fait le minimum pour que ça fonctionne et qu'on puisse enlever les modèles du type {{Lien AdQ}}.
J'ai posé sur la PDD du Module:Diagramme un message concernant un petit problème d'affichage. Je vous pose la question sur les conseils de Elfix, qui vient de m'indiquer ne pas connaître la solution : dans Module:Diagramme#Exemple avec une échelle différente par groupe? savez vous pourquoi le caractère &#nsbp; s'invite dans l'affichage de la valeur dans l'infobulle,lorsqu'on survole le diagramme avec la souris ? Alors que dans la version en:wp du module, dans l'exemple Scale per group, ce problème n'existe pas et l'affichage s'effectue parfaitement. Qu'est ce qu'il y a de particuliers sur fr:wp qui provoque ce phénomène ?
Question bis : est ce qu'on a le droit d'utiliser ce module tel quel dans les articles ? Ou quelqu'un doit il créer préalablement un modèle qui appelle ce module LUA ? (dans ce cas, si les paramètres pouvaient être traduits en français ça serait génial, mais je suppose que ça demanderait beaucoup de travail).
Le bug ne vient pas du module mais d'un bug dans mw.text qui remplace les espaces insécable par &#nbsp; au lieu de (fonction interne htmlencode_map). Sur la version anglophone ça ne se voit pas car le séparateur de millier est une virgule et non un espace insécable.
Les nom de paramètres peuvent être traduit en modifiant la table keywords au tout début du code. Comme on ne peut pas avoir plusieurs valeurs (juste le nom de la clé et la valeur) il vaut mieux faire ce changement maintenant avant que les ce module soit très utilisé. Propose des noms en français, et j'organiserai la modification.
Quelqu'un sait pourquoi il y a plein de pages qui apparaissent dans Catégorie:Page avec des erreurs de script alors qu'elles ne contiennent pas d'erreur de script ? D'ailleurs la plupart n'ont pas été mises à jour depuis plusieurs semaines (idem pour la page wikidata associée) et ont un temps d'exécution lua inférieur à la seconde, donc n'ont pas non plus de raison d'avoir eu temporairement une erreur de script.
Cette catégorie est utile pour pouvoir détecter rapidement les pages avec erreur de script et ainsi repérer une modification qui pose problème. Mais si la catégories est pleines de pages qui n'ont pas lieu d'y être, elle ne sert plus à rien.
Si ça intéresse quelqu'un, une solution générique serait d'avoir un module prenant un nombre illimité de paramètres non nommés. Chaque paramètre est formé d'une clé de tri et une valeur (avec une virgule pour séparer), et le module affiche les valeurs triées selon la clé.
Au vu de cette discussion sur le Bistro, est-ce que serait facile en Lua de permettre en entrée les deux formats de nombre avec (,) et (.) en faisant appel à {{formatnum:, ou est-ce qu'au contraire il vaudrait mieux la solution avec deux {{formatnum: parce que le temps de calcul d'un {{formatnum: est négligeable ? — Oliv☮Éppen hozzám?26 septembre 2014 à 20:49 (CEST)
Bonjour, je ne connais rien au fonctionnement de scribunto. Je souhaiterais ajouter au (ex- ?)modèle {{Lien web}} la possibilité de mettre le numéro de parution, comme il existe pour le modèle {{Article}}, de cette manière là :
Non pour les coordonnées rajoutées sur les communes de Côte d'Ivoire qui n'étaient pas géolocalisées et qui n'ont pas de données sur wikidata, le problème est présent, exemple avec Gligbeuadji--Remy34 (discuter) 27 octobre 2014 à 16:17 (CET)
J'ai vu que la Wikipédia anglaise avait mis à jour en:Template:IMDb name et en:Template:IMDb title pour utiliser Wikidata (comme nous avons fait pour Modèle:Allociné titre). J'ai essayé d'adapter leur code, est-ce qu'un administrateur peut regarder le résultat et mettre à jour les modèles si accord (j'espère que je suis au bon endroit) ?
<noinclude><!--==============================================================ATTENTION:LAMODIFICATIONDUNMODÈLEPEUTENTRAÎNERDESPROBLÈMESSURTOUTESLESPAGESDANSLESQUELLESILESTINCLUS.Veuilleznepastenterdelemodifieràmoinsquevousnesoyezcertaindebiencomprendresaconception.==============================================================--></noinclude><includeonly>{{en}}[http://www.imdb.com/{{#if:{{{1|{{{id|}}}}}}|name/{{#ifeq:{{Strleft|{{{1|{{{id}}}}}}|2}}|nm||nm}}{{Trim|{{{1|{{{id}}}}}}}}|{{#if:{{#property:P345}}|name/{{#property:P345}}|Name?{{urlencode:{{PAGENAME}}}}}}}}/{{#switch:{{lc:{{{section|}}}}}|award|awards=awardsRécompensesde|biography|bio=bioBiographiede}}{{{2|{{{name|{{Titresansdisambig|{{PAGENAME}}}}}}}}}}]surl’{{lang|en|''[[Internet Movie Database]]''}}<includeonly>{{#if:{{{1|{{{id|}}}}}}{{#property:P345}}||[[Category:Modèle IMDb sans id]]}}</includeonly><noinclude>{{Documentation}}</noinclude>
<noinclude><!--==============================================================ATTENTION:LAMODIFICATIONDUNMODÈLEPEUTENTRAÎNERDESPROBLÈMESSURTOUTESLESPAGESDANSLESQUELLESILESTINCLUS.Veuilleznepastenterdelemodifieràmoinsquevousnesoyezcertaindebiencomprendresaconception.==============================================================--></noinclude><includeonly>{{en}}[http://www.imdb.com/{{#if:{{{1|{{{id|}}}}}}|title/{{#ifeq:{{Strleft|{{{1|{{{id}}}}}}|2}}|tt||tt}}{{Trim|{{{1|{{{id}}}}}}}}|{{#if:{{#property:P345}}|title/{{#property:P345}}|Title?{{urlencode:{{PAGENAME}}}}}}}}/{{#switch:{{lc:{{{section|}}}}}|award|awards=awardsRécompensespour}}''{{{2|{{{title|{{Titlewithoutdisambig|{{PAGENAME}}}}}}}}}}''{{{3|{{{description|}}}}}}]surl’{{lang|en|''[[Internet Movie Database]]''}}<includeonly>{{#if:{{{1|{{{id|}}}}}}{{#property:P345}}||[[Category:Modèle IMDb sans id]]}}</includeonly><noinclude>{{documentation}}</noinclude>
Je propose Module:Démographie/Test pour gérer cette évolution. On n'ajoute un espace avant la note sauf si elle ne contient que un ou des éléments retirés par mw.text.unstrip (donc ref, pre ou gallery).
Par contre je ne sais pas comment tester ça avant la mise à jour de Mediawiki ; pour le moment il y a un espace ajouté systématiquement, ce qui est logique avec le fonctionnement actuel de mw.text.unstrip. Ceci dit le code actuel du Module:Démographie ne fera qu'oublier d'ajouter un espace avant les notes contenant un nowiki, donc ce n'est pas catastrophique si on passe un jour ou deux avec cette version après la mise à jour.– Zebulon84 (discuter) 6 décembre 2014 à 20:17 (CET)
Je viens d'ajouter le Modèle:RefDetail et son Module:RefDetail pour réutiliser n'importe quelle référence nommée et y ajouter un détail dans le même style. Mais je ne sais pas trop où l'intégrer dans les documentations. Je l'ai signalé dans Modèle:Ouvrage mais je vous laisse faire pour le signaler au bon endroit. --Rical (discuter) 6 décembre 2014 à 19:26 (CET)
Lua 5.3
Bonjour. Lua 5.3 (en cours de développement) annonce « un » et non « le » support de l’UTF-8 (« a basic utf-8 library »). Je me pose deux questions, pour lesquelles je n’ai pas trouvé de réponses par un simple googlage.
Ce support de l’UTF-8 est-il issu de l’ustring de MW ? Y a-t-il collaboration entre entre les équipes de développement ?
MW/WMF envisage-t-elle un upgradage une évolution de la version de lua utilisée par Scribunto ?
Pour nous informer que Lua 5.3 gérera au moins partiellement l'UTF8 c'est le bon endroit. Mais comme tu sembles en savoir plus que nous sur ce sujet, tu n'auras probablement pas de réponse ici.
Bonjour, j'ai un peu rretravaillé le module d'infobox (avec les nouvelles fonctionnalités html de Lua c'est plus simple qu'au début), et mis en service quelques modèles : voir Catégorie:Modèle infobox Lua. La prochaine étape, c'est Modèle:Infobox Bâtiment dont la version Lua est prête sur Module:Infobox/Monument. Il s'agit d'un modèle assez utilisé, et donc si quelqu'un pouvait y jeter un oeil et donner son avis, ça pourrait être utile.
Le module est relativement complexe, essentiellement du fait de l'utilisation de Wikidata, qui doit parfois demander des ajustements un peu délicats. Une partie du code est stockée sur Module:Infobox/Fonctions/Bâtiment. L'idée est de mettre en commun des fonctions complexes qui peuvent être utilisées par différents types d'infobox architecturales (Modèle:Infobox Stade, Modèle:Infobox Château, etc.). A terme toutes ces infobox pourraient être carrément fusionnées. -Zolo (discuter) 7 janvier 2015 à 15:44 (CET)
Formatages de données wikidata
Dans une infobox internationale pour des auteurs j'ai eu besoin de récupérer des portions de date de wikidata et j'ai trouvé ça compliqué, j'ai donc demandé une évolution. Puis un gérant des bugs a proposé une discussion sur ce sujet. Je l'amorce ici.
Description : Pour les valeurs de texte, un simple formatPropertyValues suffit. Mais pour un module de scribunto on peut avoir besoin seulement du mois ou de l'année. "28 décembre 2014" n'est pas si facile. Cela pourrait être plus facile avec un format fixe de date-temps comme -YYYYMMDD HH:MM:SS nnn (moins ou plus est pour les années antérieures à 1. Et 0 pourrait signifier "n'est pas défini dans ce format". nnn est pour les fractions de secondes). Alors une option pour choisir le type de format pourrait être utile. Un autre cas est l'angle ou les coordonnées géographiques radians / tour / grade / degré.
Quand nous aurons choisi un (ou des) lieu de discussion nous pourrons le/les signaler dans le bug.
Je vous invite donc à en discuter :
Pour quels types de valeurs définir des formatages ? dates, poids et mesures, coordonnées géographiques ... ?
Comment convertir des coordonnées géographiques d'un type de projection en un autre sur les cartes, des dates d'un calendrier dans un autre, des numéros de couleurs vers des couleurs ... ?
Pour les dates avant l'an 1, faut-il utiliser "123 avant J.-C." ou "123 AEC" (AEC = Avant l'ère commune) (BEC en anglais) ?
Quels formats offrir pour chaque type de donnée ?
Quel format par défaut pour chaque type de donnée ?
Quel format par défaut pour chaque langue ?
Comment répartir les formatages entre les niveaux wikidata, modèles, modules scribunto, bibliothèque scribunto de formatage ?
Comment rendre compatibles et complémentaires les formatages des divers niveaux ?
Quels arguments et combien en faut-il pour définir tous les formats et comment les rédiger ?
Comment définir chacun de ces formatages pour rester simple, précis et ouvert aux évolutions ?
Collecter des formatages classiques existants dans les applications (Excell, systèmes PC, Mathlab, ...)
Collecter dans divers domaines : navigateurs, météorologues, sportifs, wikiversity, linguistes
Dans quels wikis discuter pour collecter la diversité des formatages envisageables : français, anglais, japonais, chinois, arabe, hébreu ... ?
Vaut-il mieux centraliser les discussions dans wikidata ?
Vaut-il mieux en discuter dans plusieurs wikis en même temps pour être plus accessible dans toutes les langues, et diversifier les propositions ? Je préfère cette méthode au début. --Rical (discuter) 30 janvier 2015 à 15:18 (CET)
Bonjour, il me semble que ce dont on a besoin est plutôt une bonne librairie de formatage de date, qui fonctionne que la date vienne de Wikidata ou d'ailleurs. On a déjà mw.language.new('fr'):formatDate, mais c'est loin d'être parfait. Si on a ça, n'est pas très compliqué de convertir une date wikibase. D'ailleurs Module:Wikidata.formatSnak a déjà une option "precision" qui permet de n'afficher que l'année, que le mois et l'année, etc. -Zolo (discuter) 2 février 2015 à 10:33 (CET)
Oui. Mais si la date de wikidata est déjà formaté, elle est difficile à récupérer par portions, et en plus différement dans chaque langue.
Tu dis aussi "loin d'être parfait", et wikidata se demande comment faire, c'est le moment idéal pour être précis et constructif.
Est-ce qu'une date à ce format -YYYYMMDD HH:MM:SS nnn convient bien ?
A part la date, faut-il des améliorations pour les coordonnées géographiques ou d'autres types de valeurs ?
Quels formats de bases faciles à convertir nous aideraient dans les modules ? Quelles fonctions dans une bibliothèque LUA ? --Rical (discuter) 13 février 2015 à 10:47 (CET)
Je ne comprends pas trop ce que tu cherches à faire. Ce me parait assez logique qu'il soit difficle de récupérer une portion de date à partir d'une date formatée. Si l'on a besoin de faire quelque chose avec une date, il suffit d'utiliser la date non formatée. Avoir une fonction pour récupérer YYYYMMDD HH:MM:SS, récupéer le mois, etc. pourquoi pas, mais ce n'est pas partiulièrement compliqué à faire soi même. Il y a tellement de fonctions qui pourraient être utiles, que ça parait difficile de toutes les incorporer dans un librairie mediawiki. En fait, ce dont on aurait vraiment besoin, ce serait de modules transwikis pour ne pas avoir besoin de refaire toutes ces fonctions sur chaque projet.
Le parser de date est loin d'être parfait notamment parce qu'il ne supporte pas les date av-JC, et n'ajoute pas le "er" dans 1er janvier, mais cela ne relève pas de Wikidata. --Zolo (discuter) 15 février 2015 à 11:07 (CET)
Dépréciation de mw.wikibase.getEntity
Juste pour être sûr que l'info soit vue aussi ici. Il est fortement conseillé d'utiliser mw.wikibase.getEntityObject à la place de mw.wikibase.getEntity si l'on veut pouvoir profiter dans le futur de l’accès arbitraire. c.f. ce mail. Tpt (discuter) 20 février 2015 à 15:30 (CET)
