Discussion Projet:Scribunto/Archive 3

Archives

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

mw_interface

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.

Quelqu'un a une solution ?

Zebulon84 (discuter) 28 août 2013 à 07:58 (CEST)

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.

Merci. Zebulon84 (discuter) 29 août 2013 à 02:50 (CEST)

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.

Zebulon84 (discuter) 29 août 2013 à 14:05 (CEST)

Bricolage

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> ?

Exemple : cette version me semble plus claire que celle-là

Merci par avance pour la réponse,

--Juanes852 (me contacter) 9 septembre 2013 à 20:03 (CEST)

Oui, très probablement. À noter que ces pages ont été commencées à un moment où j'ignorais l'existence de ce syntaxhighlight . Hexasoft (discuter) 9 septembre 2013 à 20:18 (CEST)

--Juanes852 (me contacter) 9 septembre 2013 à 21:57 (CEST)

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)

D'après mes recherches, il ne faut pas utiliser <source lang="lua"> (voir mw:Extension:TagCorrection). Où as-tu vu cette balise ? Bien cordialement --Juanes852 (me contacter)10 septembre 2013 à 08:05 (CEST)

Les deux font la même chose : mw:Extension:SyntaxHighlight GeSHi#Alternative .3Csource.3E tag. — Oliv☮ ^{Éppen hozzám?} 10 septembre 2013 à 09:34 (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= ... }}.

Zebulon84 (discuter) 10 septembre 2013 à 12:01 (CEST)

source était utilisé à l'époque avec le style MediaWiki:Geshi.css rendu obsolète depuis un certain moment déjà. Cordialement, Hlm Z. (discuter) 10 septembre 2013 à 13:53 (CEST)

Demande du projet MH

Bonjour,

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).

Davance merci, cdlt, Vigneron * ^discut. 12 septembre 2013 à 16:38 (CEST)

Hello,

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 ».

Note : toutefois ma disponibilité est réduite en ce moment, ne pas prévoir une avant super-rapide Hexasoft (discuter) 12 septembre 2013 à 17:07 (CEST)

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 ).

Cdlt, Vigneron * ^discut. 12 septembre 2013 à 18:35 (CEST)

Je devrais pouvoir regarder ça assez rapidement, je vais m'en occuper. Zebulon84 (discuter) 12 septembre 2013 à 18:38 (CEST)

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)

Voir Module:Tableau MH et Modèle:Ligne de tableau MH/Brouillon. Il restes des optimisations à faire mais ce sera marginal. Je l'ai testé en prévisualisation sur Liste des monuments historiques de Saône-et-Loire, on gagne ~ 1/3 du temps processeur (9s/25), et on doit pouvoir gagner 8% supplémentaire (3s) avec quelques développement de plus.

NewPP limit reports

Avant

NewPP limit report
CPU time usage: 23.121 seconds
Real time usage: 25.295 seconds
Preprocessor visited node count: 132 079 / 1 000 000
Preprocessor generated node count: 113 792 / 1 500 000
Post‐expand include size: 2 048 000 / 2 048 000 bytes
Template argument size: 468 552 / 2 048 000 bytes
Highest expansion depth: 14 / 40
Expensive parser function count: 0 / 500
Lua time usage: 0.421s
Lua memory usage: 1.95 MB

Après :

NewPP limit report
CPU time usage: 14.653 seconds
Real time usage: 16.072 seconds
Preprocessor visited node count: 50 728 / 1 000 000
Preprocessor generated node count: 114 168 / 1 500 000
Post‐expand include size: 1 611 228 / 2 048 000 bytes
Template argument size: 151 790 / 2 048 000 bytes
Highest expansion depth: 13 / 40
Expensive parser function count: 0 / 500
Lua time usage: 6.516s
Lua memory usage: 2.17 MB
Lua Profile:
    Scribunto_LuaSandboxCallback::expandTemplate                    2580 ms     36.9%  -- l'appel à {{lien web}}
    mw.executeModule <mw.lua:142>                                   1380 ms     19.7%
    Scribunto_LuaSandboxCallback::getExpandedArgument                860 ms     12.3%
    Scribunto_LuaSandboxCallback::gsub                               700 ms     10.0%
    recursiveClone <mw.lua:109>                                      360 ms      5.1%
    Scribunto_LuaSandboxCallback::preprocess                         280 ms      4.0%  -- dans la fonction coord
    Scribunto_LuaSandboxCallback::newChildFrame                      240 ms      3.4%  -- pour la fonction coord
    <Module:TableBuilder:49>                                          60 ms      0.9%
    Scribunto_LuaSandboxCallback::sub                                 40 ms      0.6%
    type                                                              40 ms      0.6%
    [others]                                                         460 ms      6.6%

 

Zebulon84 (discuter) 13 septembre 2013 à 00:50 (CEST)

Impressionnant. Pourrais-t-on prévoir un module commun à toutes les lignes de tableau de monuments : {{Ligne de tableau Monument}}, {{Ligne de tableau MH argentin}}, {{Ligne de tableau monument Algérie}}, etc. ? Merci. — Ayack ^♫♪ 13 septembre 2013 à 08:29 (CEST)

Module : oui.

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.

Zebulon84 (discuter) 13 septembre 2013 à 09:40 (CEST)

Hello Zebulon84, je me permets de relancer cette demande en espérant que tu puisses la terminer. Merci par avance ! — Ayack ^♫♪ 1 février 2014 à 17:03 (CET)

 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)

@Zebulon84 Super ! Merci beaucoup ! — Ayack ^♫♪ 19 mai 2014 à 18:14 (CEST)

Module "nombres"

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 .

Cordialement, Hexasoft (discuter) 13 septembre 2013 à 18:47 (CEST)

Note : tests actuels sur Discussion module:Test/Nombres Hexasoft (discuter) 13 septembre 2013 à 18:48 (CEST)

Note bis : suite à intégration dans le module Module:Outils j'ai supprimé ces pages. Hexasoft (discuter) 19 septembre 2013 à 18:00 (CEST)

NewPP limit report

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.

Zebulon84 (discuter) 19 septembre 2013 à 16:12 (CEST)

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.

Zebulon84 (discuter) 19 septembre 2013 à 18:39 (CEST)

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.

Zebulon84 (discuter) 19 septembre 2013 à 20:53 (CEST)

Aide Lua et Wikidata

Je viens de tomber par hasard sur : wikidata:Help:Lua qui conduit à test2:Wikipedia:Guide_to_Scribbling. --Rical (discuter) 23 septembre 2013 à 18:36 (CEST)

Accélérer mw.title.new() ?

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.

Bien sur, c'est les développeurs de mediawiki qui le feraient, mais est-ce que ça vous semble faisable et intéressant ? --Rical (discuter) 23 septembre 2013 à 19:04 (CEST)

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é

Cordialement, Hexasoft (discuter) 23 septembre 2013 à 19:45 (CEST)

Lua et Wikidata

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.

1. 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 ?
2. 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:
   • module:Infobox
   • module:InfoboxBuilder
   • module:InfoboxBuilder/Helpers
   • module:HtmlBuilder
   • modules spécifiques: module:InfoboxBuilder/Cultivar, module:InfoboxBuilder/Composé chimique, module:InfoboxBuilder/Philosophe,... liés à des modèles.

   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).

3. 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.

Merci de l'aide que vous pouvez apporter. Snipre (discuter) 1 octobre 2013 à 03:04 (CEST)

J'importe de wikidata pour la page courante, dans le Module:ControlArgs.

C'est la fonction p.wikidata_props() qui importe les données définies par la table wd_props.

Le code commence en : entity = mw.wikibase.getEntity( ) sur 11 lignes et le résultat est la table wd.

Dans wd_props, n=1 et "numeric-id" est pour les identifiants d'autre pages, pour l'instant inaccessibles.

Dans wd_props, t=1 et ustring.sub extrait l'année d'une date. --Rical (discuter) 1 octobre 2013 à 05:01 (CEST)

Pour répondre plus spécifiquement à Snipre :

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.

Il serait bien que Tpt qui a construit ces modules nous donne son avis sur le philosophie . Hexasoft (discuter) 2 octobre 2013 à 21:20 (CEST)

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.

Personnellement si on passe en production avec Module:InfoboxBuilder, je serai d'avis de transférer tout ce qui manque de Module:Infobox dans Module:InfoboxBuilder et de ne travailler qu'avec Module:InfoboxBuilder et module:InfoboxBuilder/Cultivar dans le futur (en clair supprimer la ligne local infoboxModule = require '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.wiki.x.io) 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)

Ok, si on "nettoie" le code du module:Infobox, alors on redevient cohérent. Snipre (discuter) 4 octobre 2013 à 15:09 (CEST)

Application

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.

function p.mixed(_label, _param, _property)
    local params = { type = 'mixed', label = _label, params = _param, qualifier = _qualifier, qualifiervalue = _qualifiervalue}
    if _property ~= nil then
        params.property = _property
    end
    if _qualifier ~= nil then
        params.qualifier = _qualifier
    end
    if _qualifiervalue ~= nil then
        params.qualifiervalue = _qualifiervalue
    end
    return params
end

Ensuite il faut effectuer l'appel au module:Wikidata dans Module:InfoboxBuilder à l'endroit où tu as fait le changement de code.

function Builder:buildText( conf )
    local Wikidata  = require( 'Module:Wikidata')
    
    if conf.text then
        conf.text = self:getValueForParam( nil, conf.text)
    else
        conf.text = Wikidata:formatStatements( ??? )
    end

    if not conf.text then
        self.infobox:addText( { text = '<span class="error">Vous devez renseigner le paramètre "text"</span>' } )
        return
    end
    self.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 naissance _propriété: Berlin _{valeur 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)

Un truv qui pourrait éventuellement être intéressant dans ce genre de cas c'est d'appliquer les mécanismes de spécialisation / surcharge de méthodes, mais je maîtrise pas trop Lua (http://lua-users.org/wiki/InheritanceTutorial). — TomT0m ^[bla] 5 octobre 2013 à 14:36 (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 ?

1. 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.
2. 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.
3. 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 :

• A => link=A (je ne sais pas si ce cas existe)
• [[A]] => link=A
• [[A|B]] => link=A
• A C etc. => indécidable pas de link

plus les cas avec 2, 3 et 5 quotes de typos. Cordialement - Drongou (discuter) 6 octobre 2013 à 20:12 (CEST)

Détection des parenthèses par {{Voir homonymes}}

Bonjour. J'ai fait une demande qui vous concerne sur Projet:Modèle/Demandes. Thierry Caro (discuter) 20 octobre 2013 à 05:13 (CEST)

Bonjour. Je rajoute qu'un module pour calculer le titre sans parenthèses serait très utile dans d'autres cas également : la valeur par défaut du titre de l'infobox, les liens dans {{Autres projets}}. Orlodrim (discuter) 21 octobre 2013 à 20:20 (CEST)

Charte de couleurs pour infobox

Bonjour.

Est il possible de construire cet outil en utilisant un module plutôt qu'un modèle ? (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 21 octobre 2013 à 20:07 (CEST)

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 signature a é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.

@Snipre> Je sais, je rencontre cette opposition depuis un temps déjà, mais après un coup de mou, j'ai repris un peu de poil de la bête. Cette histoire de particularité de "leurs" infobox m'a toujours paru un peu absurde puisqu'elle concerne uniquement les paramètres non-communs qui se trouveront dans les modules d'activités. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 21 octobre 2013 à 21:03 (CEST)

À 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)

Ju gatsu mikka : j'ai créé Module:Chartes. Voir Discussion module:Chartes pour quelques exemples.

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.

Pour ta dernière question, je ne sais pas. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 1 novembre 2013 à 17:11 (CET)

Un modèle a-t-il encore un sens ou un module pour l'infobox ferait les choses en mieux ? Snipre (discuter) 1 novembre 2013 à 17:19 (CET)

Nom du module lui-même

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

<a rel="nofollow" class="external text" href="http://pubchem.ncbi.nlm.nih.gov/summary/summary.cgi?cid=13190">13190</a>

mais uniquement

<a rel="nofollow" class="external free" href="http://pubchem.ncbi.nlm.nih.gov/summary/summary.cgi?cid=13190">http://pubchem.ncbi.nlm.nih.gov/summary/summary.cgi?cid=13190</a>

A première la différence vient de la classe qui est dans un cas external text et dans l'autre external free.

Comment modifier la classe ? Snipre (discuter) 28 octobre 2013 à 20:49 (CET)

Référence d'usage

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".

Hello,

une recherche de ce type fonctionne bien pour trouver où est utilisé un module. À noter qu'il y en a trop (d'articles) pour tous les lister pour tous les modules. Hexasoft (discuter) 14 novembre 2013 à 15:51 (CET)

Camembert ?

Bonjour, quelqu'un aurait des solutions pour générer des diagrammes en forme de camembert avec Lua ? --Zolo (discuter) 16 novembre 2013 à 10:18 (CET)

 Zolo : ► Module:Diagramme. Cordialement, --Ickx6 17 août 2014 à 16:10 (CEST)

Coordonnées et Wikidata.

Bonjour,

J’ai ouvert une discussion sur Discussion_modèle:Coord#Wikidata_tracking pour laquelle vous pourrez peut-être aider :)

Merci, Jean-Fred (discuter) 16 novembre 2013 à 16:36 (CET)

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)

Modèle:Infobox/Ligne mixte latitude longitude optionnelle (soucis)

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 :

1. 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).
2. il s'agit d'une brique d'Infobox "optionnelle" et malgré tout elle catégorise les pages dans Catégorie:Page géolocalisable sans coordonnées paramétrées (par exemple, Čičarija appelant l'{{Infobox Montagne}} dont les coordonnées sont facultatives pour les massifs). Un comble !

Quelqu'un pour régler ces problèmes ? D'avance, merci. --FDo64 (discuter) 29 novembre 2013 à 11:02 (CET)

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.

Pour la question 2, cela a longuement été discuté ici Discussion_Projet:Géolocalisation#Catégorie Page géolocalisable sans coordonnées paramétrées, et il n'y a pas pour le moment de solution satisfaisante; il faudrait que le code de l'Infobox sache aller vérifier sur Wikidata si la coordonnée est présente ou non pour catégoriser correctement l'article, ce qui n'est pas le cas à ce jour. -- Speculos ^✉ 29 novembre 2013 à 12:39 (CET)

Pour savoir vérifier sur Wikidata : un petit {{#if:{{wikidata|p625}}| ? — Oliv☮ ^{Éppen hozzám?} 29 novembre 2013 à 15:10 (CET)

Bonjour, ci-après mes remarques :

1. 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.
2. 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.

--FDo64 (discuter) 9 décembre 2013 à 11:46 (CET)

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).

Pour la catégorie "géolocalisable sans coordonnées paramétrées", si on ne veut catégoriser comme "à gélocaliser" que les pages qui {{Infobox/Ligne mixte latitude longitude}} et pas celles qui utilisent {{Infobox/Ligne mixte latitude longitude optionnelle}}, c'est très facile à faire. Mais personnellement, je ne vois pas trop de raison pour faire ça. Le choix entre l'"obligatoire" et l'optionnel parait, à quelques semi-exceptions près, très arbitraire, et pratiquement tous les articles de Catégorie:Page géolocalisable sans coordonnées paramétrées sont réellement géolocalisables et me paraitraient gagner à être géolocalisés. --Zolo (discuter) 10 décembre 2013 à 10:08 (CET)

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.

Désolé de pinailler mais je crois que ça a son importance. A+ --FDo64 (discuter) 10 décembre 2013 à 11:34 (CET)

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.

--FDo64 (discuter) 10 décembre 2013 à 15:33 (CET)

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)

Maintenance

Bonsoir, quelqu'un pourrait signaler le modèle ({{Lang}}, {{Citation étrangère}}, {{Langue du titre}}, {{Site officiel}}) qui contient un code langue erroné comme c'est le cas avec le modèle {{lien web}}. Pour cela il faut modifier le module Module:langue. Je fais régulièrement la maintenance des pages de la catégorie Catégorie:Page avec code de langue invalide mais je trouve des difficultés à trouver le modèle qui contient l'erreur. Cordialement. Hunsu (discuter) 20 décembre 2013 à 18:47 (CET)

+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)

Je vais poster aussi cette demande dans Discussion Projet:Modèle#Maintenance. Hunsu (discuter) 4 janvier 2014 à 12:43 (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.
• Comme le LUA est compilé, je ne crois pas que cela ralentisse beaucoup l'exécution normale. --Rical (discuter) 4 janvier 2014 à 19:25 (CET)

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)

1. Lorsque la catégorie d'erreur est gérée par le modèle (et pas le module), on pourrait tout simplement utiliser des clés de tri différentes : par exemple dans Modèle:Langue du titre.  Fait. --FDo64 (discuter) 7 janvier 2014 à 12:24 (CET)
2. Si cette même catégorie d'erreur est générée par le module, il faudra alors que le module reçoive l'information du nom du modèle qui l'appelle.

Je peux m'occuper du premier cas, je vous laisse le deuxième. --FDo64 (discuter) 6 janvier 2014 à 18:38 (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)

Les articles concernés sont dans la Catégorie:Page avec code de langue invalide. Actuellement y a 7 articles. Je la vide régulièrement et je suis pas le seul à le faire. Y a en moyen une dizaine d'articles chaque deux semaines. Hunsu (discuter) 7 janvier 2014 à 17:51 (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)

C'est bon, moi je ne vois pas de problème non plus. Merci Hunsu (discuter) 10 janvier 2014 à 15:35 (CET)

tableaux

il y a une règle pour les tableaux générés utiliser la syntaxe {- } ou la syntaxe <table></table> car si je peux choisir je choisis la deuxième ? Xavier Combelle (discuter) 4 janvier 2014 à 15:47 (CET)

Hello,

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.

Cordialement, Hexasoft (discuter) 4 janvier 2014 à 21:36 (CET)

Module:Référence

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)).

Quelqu'un sait pourquoi m'affiche cela. Cordialement. Hunsu (discuter) 22 janvier 2014 à 13:21 (CET)

Dans certains cas il faut doubler le %, donc peut-être dans ton exemple : %%d%%d. --Rical (discuter) 22 janvier 2014 à 19:56 (CET)

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.

Hunsu (discuter) 22 janvier 2014 à 21:20 (CET)

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)

Projet:Infobox/Lua

Pour information, j'ai créé la page Projet:Infobox/Lua et sa page de discussion dans laquelle j'ai commencé à poser des questions. Le mieux serait que les débats sur les infobox Lua se déroulent làbas. A+ --FDo64 (discuter) 31 janvier 2014 à 12:20 (CET)

Afficher une valeur de Wikidata dans une infobox

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)

. Tpt (discuter) 1 février 2014 à 17:58 (CET)

Afficher une cinquantaine d'articles dans une seule page

b:Module:Version imprimable fonctionne très bien pour afficher une vingtaine d'articles dans une seule page, pourtant il sature dans Programmation Java/Version imprimable qui en contient une cinquantaine.

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)

Merci, je vais la traiter manuellement en attendant une éventuelle upgrade. JackPotte ($♠) 15 février 2014 à 21:56 (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)

Cf. Phabricator:T66163 Zebulon84 (discuter) 25 février 2015 à 23:39 (CET)

Apparemment la limite a été étendue depuis, et le livre de Java fonctionne. Par contre, avec b:Le système d'exploitation GNU-Linux/Version imprimable j'obtiens une erreur Catégorie:Pages contenant trop d'inclusions de modèles. JackPotte ($♠) 23 juillet 2015 à 13:58 (CEST)

Module:HtmlBuilder

Nous avons mw.html maintenant. Pourquoi utiliser celui-là? --Ricordisamoa 19 février 2014 à 04:43 (CET)

Si toutes les fonctionnalités du module sont incluses dans mw.htmk, ce serait effectivement mieux. Tu saurais faire la conversion de Module:Coordinates/Test ? --Zolo (discuter) 19 février 2014 à 09:54 (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. --Ricordisamoa 19 février 2014 à 13:53 (CET)

 Ricordisamoa :. Oui ça a l'air de marcher, merci ! --Zolo (discuter) 19 février 2014 à 22:42 (CET)

 Zolo : fait Module:Gallery. --Ricordisamoa 20 février 2014 à 05:40 (CET)

...mais le Module:Coordinates/Test2 est protégé. --Ricordisamoa 20 février 2014 à 05:50 (CET)

 Ricordisamoa : J'ai déprotégé Module:Coordinates/Test2. Tpt (discuter) 20 février 2014 à 20:28 (CET)

 Tpt et Zolo : Special:Diff/101447247, Module:HtmlBuilder peut donc être supprimé. --Ricordisamoa 20 février 2014 à 22:21 (CET)

Infobox en lue: gestion des styles

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

t2 = {background = "#EEEEEE", text-align = "center"}

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)

Pour avoir des "-" tu peux utiliser cette syntaxe

t2 = {["text-align"] = "#EEEEEE"}

je crois. Tpt (discuter) 15 mars 2014 à 17:08 (CET)

pour créer le tableau

t2 = {"background:#EEEEEE", "text-align:center"}

simplement Xavier Combelle (discuter) 7 avril 2014 à 15:51 (CEST)

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.

Cordialement, Hexasoft (discuter) 24 avril 2014 à 19:58 (CEST)

Pour ne pas réinventer la roue il y a en:Module:Convert. – Zebulon84 (discuter) 24 avril 2014 à 21:06 (CEST)

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)

Demande du 27 avril 2014, par : Jean GUERIN - Paris (discuter) 27 avril 2014 à 19:18 (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 :

• Les deux palettes de modèles de sources à droite,

Modèles de sources musique classique

Données clés

Historiques d'opéras (théâtres)

Périodiques spécialisés XIXe

Presse quotidienne nationale XIXe

Presse étrangère

Monographies de personnalités

Recueils de biographies et assimilés

Autres sources

Modèles de sources
A&M ParisTech

Données clés

Ouvrages

Périodiques

• Arts et Métiers Business Angels, partie "bibliographie"
  
• Utilisateur:Jean GUERIN 2
  

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 :

1. 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 ;
2. 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)

Bonsoir, Scoopfinder,
Mais tu réponds magnifiquement à ma question : j'ai les bonnes adresses ! :D Merci, Scoopfinder !
Amitiés,
Jean GUERIN - Paris (discuter) 27 avril 2014 à 20:27 (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)

Erreur dans Wikipédia:Lua ?

Bonjour,

Dans Wikipédia:Lua#À propos de Lua il est donné un exemple du Lua avec la fonction factorielle.

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,

Bien cordialement,

--Juanes852 (me contacter) 15 mai 2014 à 09:30 (CEST)

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)

Hexasoft (d · c · b) merci pour la réponse,

Comment faut il faire pour qu'il retourne quelque chose  ?

Lorsque je mets :

{{#invoke:Module:Bac à sable|factorielle|5}} ça retourne « Erreur de script »

--Juanes852 (me contacter) 15 mai 2014 à 11:48 (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'.

Le code suivant marchera. – Zebulon84 (discuter) 15 mai 2014 à 12:07 (CEST)

ps : il ne faut pas mettre 'Module:' après '#invoke:' : {{#invoke:Bac à sable|factorielle|5}}

local p = { }

local function factorielle(n)
    if n == 0 then
        return 1 -- on renvoie la valeur 1 quand le paramètre vaut 0
    else
        return n * factorielle(n - 1)
    end
end
 
p.factorielle1_5 = function ()
    local tabResultat = {}
    for index = 1,5 do
        table.insert( tabResultat, index .. '! = ' .. factorielle(index) )
    end
    return table.concat( tabResultat, '<br>' )
end
 
p.factorielle = function (frame)
    if frame and frame.args and tonumber( frame.args[1] ) then
        -- appel par invoke et le premier paramètre est un nombre
        return factorielle( tonumber( frame.args[1] ) )
    elseif frame and type( frame.getParent ) == 'function' and tonumber( frame:getParent().args[1] )  then
        -- appel par modèle dont le premire parmaètre est un nombre
        return factorielle( tonumber( frame:getParent().args[1] ) )
    else
        return 'le premier paramètre doit être un nombre'
    end
end
return p

 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)

Oui, tu as raison. J'ai corrigé le code ci-dessus. –Zebulon84 (discuter) 15 mai 2014 à 13:44 (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

--Juanes852 (me contacter) 15 mai 2014 à 14:58 (CEST)

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.

Zebulon84 (discuter) 15 mai 2014 à 15:22 (CEST)

Conflit d’édition —Hello,

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 "=").

Pour ce qui est de comprendre ce module le mieux est de partir de partir sur Aide:Module puis de suivre Projet:Scribunto/Guide.

Cordialement, Hexasoft (discuter) 15 mai 2014 à 15:23 (CEST)

@Hexasoft (d · c · b) & Zebulon84 (d · c · b) Merci pour vos réponses !

@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 (me contacter) 16 mai 2014 à 12:33 (CEST)

 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.

Pour le elseif c'est un… else if . Regarde Lua reference manual (ou sa version française − que j'avais traduit à l'époque ), le elseif y est. Hexasoft (discuter) 16 mai 2014 à 12:54 (CEST)

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).

--Juanes852 (me contacter) 16 mai 2014 à 15:08 (CEST)

Bug dans la catégorisation des modules ?

Bonjour,

Est-ce normal que Module:ExempleParams ne soit pas catégorisé dans Catégorie:Exemple de Module et qu'il soit catégorisé dans Catégorie:Documentation de module ?

De même, est-ce normal que Module:Module_Factorielle n'apparaisse pas dans Catégorie:Exemple de Module ?

Pourtant dans Module:ExempleParams/Documentation et dans Module:Module Factorielle/Documentation on a bien

<includeonly>
{{Projet Scribunto}}
[[Catégorie:Exemple de Module]]
</includeonly>
<noinclude>
[[Catégorie:Documentation de module|{{BASEPAGENAME}}]]
</noinclude>

J'ai bien pensé à purger

Bizarre,

Merci par avance pour votre réponse,

--Juanes852 (me contacter) 16 mai 2014 à 12:07 (CEST)

Question transférée vers Discussion_Projet:Catégories#Bug_dans_la_cat.C3.A9gorisation_des_modules_.3F --Juanes852 (me contacter) 24 mai 2014 à 13:41 (CEST)

Surement la balise <References>.  Fait. Cordialement, Hlm Z. (discuter) 24 mai 2014 à 14:16 (CEST)

 Hlm Z. : Euh, cela n'a pas résolu le problème ! De plus, Module:Module_Factorielle n'a pas balise <References>, et pourtant il a également un problème de catégorisation similaire. C'est vraiment très étrange ! --Juanes852 (me contacter) 24 mai 2014 à 15:07 (CEST)

 Hlm Z. : merci pour tes essais, mais apparemment le problème ne vient pas non plus de basepagename, Module:ExempleParams et Module:Module_Factorielle n'apparaissent toujours pas dans Catégorie:Exemple_de_Module --Juanes852 (me contacter) 24 mai 2014 à 15:26 (CEST).

 Juanes852 : Le problème vient bien de basepagename. Soit patient, les éléments ne vont pas tarder à s'afficher. Cordialement, Hlm Z. (discuter) 24 mai 2014 à 15:41 (CEST)

 Hlm Z. : En effet, depuis que {{BASEPAGENAME}} a été supprimé, la catégorisation fonctionne bien, merci d'avoir résolu le problème !

Pourtant, Modèle:Documentation/PreloadModule impose la syntaxe [[Catégorie:Documentation de module|{{BASEPAGENAME}}]]. Hexasoft (d · c · b), c'est toi qui a intégré le BASEPAGENAME (voir [2]). Vu le bug rapporté dans cette discussion, faut-il le supprimer ? Bien cordialement --Juanes852 (me contacter) le 26 mai 2014 à 09:50 (CEST)

P.S merci par avance de supprimer Module:Module factorielle/Documentation que j'avais créé pour faire un test pour tenter de résoudre ce problème.

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)

Dans mw:Magic words j'ai trouvé ceci « BASEPAGENAME (…) For more complex splitting, use {{#titleparts:}} ». Apparemment ce mot magique semble bien avoir posé des problèmes par ailleurs. Je le supprime donc de Modèle:Documentation/PreloadModule (déjà fait par utilisateur:Hlm Z.). --Juanes852 (me contacter) le 26 mai 2014 à 14:16 (CEST)

┌─────────────────────────────────────────────────┘
À l'heure actuelle Catégorie:Module infobox connaît ce même problème. J'ai supprimé le BASEPAGENAME pour les pages où j'ai repéré que ça posait problème (Module:InfoboxBuilder/Helpers). Peut-être faudrait-il faire appel à un bot pour qu'il supprime le BASEPAGENAME des 51 pages présentes dans Catégorie:Documentation de module ? Merci par avance de donner votre avis sur cette proposition --Juanes852 (me contacter) le 26 mai 2014 à 14:45 (CEST) P.S d'ailleurs ça m'a permis de repérer que Module:InfoboxBuilder/Composé chimique/Documentation et Module:InfoboxBuilder/Common queries/Documentation étaient orphelins.  Hexasoft :, merci de les supprimer !

{{m}} et paramètre nommés

Question tranférée sur le Projet:Modèle

Salut, j’ai développé un bout de code en lua sur Wikidata d:Module:Template utilisé par d:Template:Tlp pour que {{m}} gère aussi les paramètre nommé. On intègre ça ici ? (je vérifie pas, mais j’imagine que j'ai pas les droits de le faire :) ). — TomT0m ^[bla] 16 mai 2014 à 12:33 (CEST)

Avant tout, penser à demander à un administrateur de l'importer grâce à Spécial:Import ! Bien cordialement --Juanes852 (me contacter) 16 mai 2014 à 12:41 (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)

Cette opération permet d'importer une page avec conservation de l'historique, aucune synchronisation n'est possible. À ma demande fr:Module:BananesArgs vient tout juste d'être importé à partir de en:Module:BananasArgs, je viens de terminer la traduction. Bien cordialement --Juanes852 (me contacter) 16 mai 2014 à 13:21 (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)

C'est fait par css avec un « float: right; »

Voir les class infobox_v2 et infonbox_v3 dans MediaWiki:Common.css. – Zebulon84 (discuter) 19 mai 2014 à 20:19 (CEST)

Merci beaucoup Zebulon84. Tu es toujours aussi précieux. Gtaf ^(discuter) 19 mai 2014 à 22:35 (CEST)

Super, l'infobox est à droite. Encore merci Zebulon84. Gtaf ^(discuter) 20 mai 2014 à 20:30 (CEST)

Dates, CET, 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)

Module:Palette

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.

Merci d'avance. --FDo64 (discuter) 11 juillet 2014 à 16:07 (CEST)

C'est peut-être sans lien, mais il existe sur wp:en le Module:Navbox. — Ayack ^♫♪ 11 juillet 2014 à 17:05 (CEST)

Ce module en: est l'équivalent de {{Méta palette de navigation}} qui est utilisé pour programmer les palettes. Ce n'est donc pas l'équivalent du modèle:Palette qui sert à les regrouper et que je demande ici. Cela dit, merci de ton intervention. A+ --FDo64 (discuter) 11 juillet 2014 à 17:30 (CEST)

Pour votre information, ce module a été développé par  Zebulon84 et a été mis en place le 8 octobre. Merci encore à lui !

--FDo64 (discuter) 26 octobre 2014 à 22:36 (CET)

conversion de Modèle:Infobox/Géolocalisation multiple

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

Page proposée à la suppression

Bonjour,

L’article « Modèle:Barre latérale ^{(page supprimée)} » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). Après avoir pris connaissance des critères généraux d’admissibilité des articles et des critères spécifiques, vous pourrez donner votre avis sur la page de discussion Discussion modèle:Barre latérale/Suppression.

Le meilleur moyen d’obtenir un consensus pour la conservation de l’article est de fournir des sources secondaires fiables et indépendantes. Si vous ne pouvez trouver de telles sources, c’est que l’article n’est probablement pas admissible. N’oubliez pas que les principes fondateurs de Wikipédia ne garantissent aucun droit à avoir un article sur Wikipédia. Olivier LPB (discuter) 18 juillet 2014 à 02:48 (CEST)

Problème de regexp des dates avec %w

Bonjour,

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..

Qu'en pensez-vous ?

Gonzolito ^Pwet 1 août 2014 à 15:16 (CEST)

Merci d'avoir signalé le problème.

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.

Zebulon84 (discuter) 1 août 2014 à 18:29 (CEST)

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 ?

Gonzolito ^Pwet 2 août 2014 à 00:00 (CEST)

Juste deux liens pour ce soir : os.setlocale sur lua.org, Lua Locales sur lua-users.org. Zebulon84 (discuter) 2 août 2014 à 00:41 (CEST)

Analyser une page

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)

La fonction mw.title.getCurrentTitle().getContent() permet d'obtenir le wikitexte de la page en cours. Après on peut l'analysé avec les fonctions de mw.ustring.

Cependant il faut utiliser cette fonction avec précaution, car

• il y a des problèmes de cache qui nécessite d'enregistrer deux fois la page pour que les changements soient pris en compte.
• Si ce que tu cherches est dans un déporté dans un modèle, tu ne le trouvera pas dans la page.

Zebulon84 (discuter) 11 août 2014 à 06:22 (CEST)

Module demandé

Voir la demande sur Discussion_Projet:JavaScript/Demande_de_fonction#Calculer_les_distances_des_sondes_voyager..

Comme je l'explique là-bas, un module serait sans doute bien plus approprié qu'un gadget javascript pour faire ce genre de calcul.

⇨ D^r Brains ^{∞ Consultation ∞} 8 août 2014 à 14:41 (CEST)

Récupérer une propriété wikidata d'une autre page

 Hexasoft, Tejgad, Arkanosis, Xfigpower, Zebulon84 et Hlm Z. :

Bonjour,

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...

⇨ D^r Brains ^{∞ Consultation ∞} 10 août 2014 à 19:50 (CEST)

 Dr Brains : Ce n'est pas encore actif.

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 local entity = 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.

print( mw.wikibase.label( "Q500787" ) ) → Cristián Sánchez

print( mw.wikibase.sitelink( "Q500787" ) ) → Cristián Sánchez (présentateur)

Zebulon84 (discuter) 11 août 2014 à 06:08 (CEST)

Merde.

Bon, tant pis. Pensez à me tenir au courant dès que ça fonctionnera. Merci.

⇨ D^r Brains ^{∞ Consultation ∞} 11 août 2014 à 17:27 (CEST)

C'est en cours de traitement chez les développeurs : voir ici. Cela devrait être réglé d'ici quelques mois. Snipre (discuter) 13 août 2014 à 10:10 (CEST)

L'accès à des données d'un autre élément est en phase de test sur le serveur de test de wikidata. Snipre (discuter) 19 août 2014 à 19:35 (CEST)

Bonjour,

Du nouveau sur ce sujet ?

⇨ D^r Brains ^{∞ Consultation ∞} 20 février 2015 à 22:58 (CET)

C'est une lourde tache pour les développeurs, et qui dépend d'une dizaine d'autres évolutions, "Blocked By" en bleu à faire, et en gris barré déjà faites. --Rical (discuter) 22 février 2015 à 00:17 (CET)

Ça s'approche : [5]. C'est en test sur nl.wiki et fr.wikisource. — Zebulon84 (discuter) 11 mai 2015 à 22:26 (CEST)

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.

Mais ces deux modèles servent aussi à catégoriser les articles dans des catégories comme Catégorie:Article de qualité en anglais. Cela est utilisé pour fournir des listes d'articles qu'il est potentiellement utile de traduire par portail, à l'aide de {{Palette Articles de qualité dans une autre langue}} et {{Palette Bons articles dans une autre langue}}.

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 (discuter) 26 août 2014 à 18:57 (CEST)

 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.

J'ai créé un Module:Categorie AdQ, mais vu que la fonction est très simple cela pourrait éventuellement être intégré au module:Wikidata.

Zebulon84 (discuter) 2 septembre 2014 à 06:53 (CEST)

Ç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)

Bon, maintenant :

• {{Portail}} et {{Méta lien vers portail}} appellent...
  • {{Catégorisation badges}} qui appelle...
    • Module:Catégorisation badges/Détection sur l'ensemble des articles ayant un portail (protection complète).
    • Module:Categorie AdQ, renommé en Module:Catégorisation badges, seulement quand il y a au moins un badge (semi-protection).

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}}.

Orlodrim (discuter) 7 septembre 2014 à 20:56 (CEST)

Petit bug d'affichage sur le Module diagramme

Bonjour,

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).

Merci par avance, --Ickx6 26 août 2014 à 20:25 (CEST)

• 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 &nbsp; (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.

Zebulon84 (discuter) 2 septembre 2014 à 01:18 (CEST)

En attendant que le bug soit éventuellement corrigé, j'ai ajouté une ligne pour corriger le résultat de la fonction buggée. -- Zebulon84 (discuter) 2 septembre 2014 à 02:42 (CEST)

Merci Zebulon84 pour ton intervention. Je vais donc faire des propositions dans la PDD du module. --Ickx6 2 septembre 2014 à 20:32 (CEST)

Page sans erreur de script

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.

Zebulon84 (discuter) 2 septembre 2014 à 08:38 (CEST)

En cherchant autre chose je suis tombé sur le bug 70177 qui as probablement quelque-chose à voir avec le problème. Zebulon84 (discuter) 2 septembre 2014 à 09:36 (CEST)

Tableau triable du côté serveur

Bonjour,

Je signale cette requête bot, où comme suggéré par JackPotte (d · c · b) un module Lua serait plus adapté.

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é.

Par exemple, cette entrée :

{{#invoke:Tri arguments|triArguments
|120,* Personne 1 (120 ans)
|100,* Personne 2 (100 ans)
|{{#expr:{{#time:Y}}-1900}},* Personne 3 ({{#expr:{{#time:Y}}-1900}} ans)
}}

donnerait cela :

• Personne 2 (100 ans)
• Personne 3 (124 ans)
• Personne 1 (120 ans)

Orlodrim (discuter) 8 septembre 2014 à 20:51 (CEST)

Relecture Coordinates

Bonjour,

Si quelqu'un pourrait vérifier le code de la fonction wikidatacat() du Module:Coordinates/Test.

On la teste via {{#Invoke:Coordinates/Test|coord |wikidata=true|display=title}} dans des article comme Saint-Lô,Mont-Blanc,Jérusalem,Cité de Carcassonne, Abbe (cratère)

Merci -- Xfigpower (pssst) 10 septembre 2014 à 19:58 (CEST)

Modèle:Unité

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)

Module:Biblio

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à :

{{Lien web|auteur=Robert Boyce|titre= Historiographies|url=http://www.histoire-politique.fr/index.php?numero=22|numéro=22}}.

Merci d'avance ! FF 19.10.14 16:38 CEST.

Erreur sur Module:Coordinates

Salut,

Depuis cet après-midi, certains pages (pas toutes) utilisant les coordonnées et le module:Coordinates ont un affichage de code d'erreur i.e. Z 12 Erich Giese). Tout comme la page de test : Module:Coordinates/Test.

Erreur Lua : callParserFunction: function "#coordinates" was not found

Quelqu'un sait pourquoi ? Merci, Gonzolito ^Pwet 27 octobre 2014 à 15:03 (CET)

Je plussoie. J'ignore qui a fait quoi, mais ça ne fonctionne plus pour par exemple

{{coord|26|24|30|N|3|58|15|W}} : 26° 24′ 30″ N, 3° 58′ 15″ O.

— Cantons-de-l'Est ^discuter 27 octobre 2014 à 15:54 (CET)

A priori tous les articles utilisant un Infobox avec géolocalisation sont touchées. La dernière modification de Module:Coordinates date du 16 septembre (Xfigpower (d · c · b) est notifié), le problème est sans doute plus global. -- Speculos ^(discuter) 27 octobre 2014 à 16:00 (CET)

Comme je l'ai indiqué dans Wikipédia:Questions techniques/semaine 44 2014‎, le problème ne se produit que si les coordonnées sont cherchées dans Wikidata. Lorsqu'elles sont dans l'article, ça marche. --FDo64 (discuter) 27 octobre 2014 à 16:08 (CET)

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)

Pareil sur WP en anglais et en hongrois où ils disent que mw:Extension:GeoData incluant le tag {{#coordinates: est temporairement désactivé. Ils mentionnent bugzilla:72559, pas bien compris le rapport. — Oliv☮ ^{Éppen hozzám?} 27 octobre 2014 à 16:20 (CET)

C'est apparemment corrigé à présent, le message d'erreur disparait après purge du cache. -- Speculos ^(discuter) 27 octobre 2014 à 17:00 (CET)

Modèles IMDb

Bonjour,

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) ?

Modèle:Imdb nom :

<noinclude><!--==============================================================

          ATTENTION : LA MODIFICATION D UN MODÈLE PEUT ENTRAÎNER DES PROBLÈMES 
         SUR TOUTES LES PAGES DANS LESQUELLES IL EST INCLUS.

Veuillez ne pas tenter de le modifier à moins que vous ne soyez certain de bien comprendre sa conception. 

==============================================================-->
</noinclude><includeonly>{{en}} [http://www.imdb.com/{{#if:{{{1|{{{id|}}}}}}|name/{{#ifeq:{{Str left|{{{1|{{{id}}}}}}|2}}|nm||nm}}{{Trim|{{{1|{{{id}}}}}}}}|{{#if:{{#property:P345}}|name/{{#property:P345}}|Name?{{urlencode:{{PAGENAME}}}}}}}}/{{#switch:{{lc:{{{section|}}} }}
|award|awards=awards Récompenses de
|biography|bio=bio Biographie de
}} {{{2|{{{name|{{Titre sans disambig|{{PAGENAME}}}}}}}}}}] sur l’{{lang|en|''[[Internet Movie Database]]''}}<includeonly>{{#if:{{{1|{{{id|}}}}}}{{#property:P345}}||[[Category:Modèle IMDb sans id]]}}</includeonly><noinclude>{{Documentation}}</noinclude>

Modèle:Imdb titre :

<noinclude><!--==============================================================

          ATTENTION : LA MODIFICATION D UN MODÈLE PEUT ENTRAÎNER DES PROBLÈMES 
         SUR TOUTES LES PAGES DANS LESQUELLES IL EST INCLUS.

Veuillez ne pas tenter de le modifier à moins que vous ne soyez certain de bien comprendre sa conception. 

==============================================================-->
</noinclude><includeonly>{{en}} [http://www.imdb.com/{{#if:{{{1|{{{id|}}}}}}|title/{{#ifeq:{{Str left|{{{1|{{{id}}}}}}|2}}|tt||tt}}{{Trim|{{{1|{{{id}}}}}}}}|{{#if:{{#property:P345}}|title/{{#property:P345}}|Title?{{urlencode:{{PAGENAME}}}}}}}}/{{#switch:{{lc:{{{section|}}} }}
|award|awards=awards Récompenses pour
}} ''{{{2|{{{title|{{Title without disambig|{{PAGENAME}}}}}}}}}}'' {{{3|{{{description|}}}}}}]  sur l’{{lang|en|''[[Internet Movie Database]]''}}<includeonly>{{#if:{{{1|{{{id|}}}}}}{{#property:P345}}||[[Category:Modèle IMDb sans id]]}}</includeonly><noinclude>
{{documentation}}
</noinclude>

Merci pour votre aide. Cordialement, Thomas Linard (discuter) 28 octobre 2014 à 17:40 (CET)

Changement de Scribunto incompatible avec Module:Démographie

Il va y avoir un changement de mw.text.unstrip. D'après cette liste, c'est utilisé dans un seul module, Module:Démographie. J'ai l'impression que le code actuel pour détecter les références ne fonctionnera plus, mais je ne sais pas résoudre le problème. Orlodrim (discuter) 6 décembre 2014 à 15:01 (CET)

Comme l'auteur  Hexasoft n'est plus actif depuis fin juin, y a-t-il quelqu'un d'autre pour regarder ? --FDo64 (discuter) 6 décembre 2014 à 17:54 (CET)

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)

Merci. J'avais en tête que ça servait à quelque chose de plus compliqué, mais j'ai dû confondre avec les paramètres de notes dans {{Infobox Subdivision administrative}}. Bon, du coup, on peut effectivement attendre pour tester. Orlodrim (discuter) 6 décembre 2014 à 22:52 (CET)

Le module de test semble fonctionner comme prévu, la modification peut donc être appliquée au module:Démographie. – Zebulon84 (discuter) 12 décembre 2014 à 01:41 (CET)

Orlodrim (discuter) 26 février 2015 à 00:02 (CET)

Modèle:RefDetail pour toutes les références

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.

1. 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 ?
2. MW/WMF envisage-t-elle un upgradage une évolution de la version de lua utilisée par Scribunto ?

Merci si vous pouvez m’éclairer. --GaAs (discuter) 9 décembre 2014 à 19:36 (CET)

Me suis-je trompé d’endroit ? --GaAs (discuter) 11 décembre 2014 à 22:05 (CET)

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.

Je suggère de poser la question sur mw:Extension talk:Scribunto. — Zebulon84 (discuter) 12 décembre 2014 à 01:32 (CET)

Nouvelles de Module:Infobox

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.

• Le bug T85412 The formatPropertyValues needs an option to format data from date-time, angle or geographic coordinates :
• 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 1^er 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)

À première vue, les modules concernés ici (Module:Test0, Module:InfoboxBuilder, Module:Chronologie, Module:Autres projets/éssai et Module:Autres projets) ne sont pas utilisés.

Amicalement — Arkanosis ^✉ 2 mars 2015 à 18:16 (CET)

Wikidata et infobox

J'ai lancé une discussion sur le Bistro en voyant une modif sur WP hongrois, vos avis y sont les bienvenus. — Oliv☮ ^{Éppen hozzám?} 7 mars 2015 à 09:09 (CET)