Discussion Projet:Scribunto/Archive 1

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

Longueur de chaîne

Rien que pour ça, merci Lua -- Xfigpower (pssst) 27 février 2013 à 23:01 (CET)

Module utilisateur

Bonjour,

Pour tester nos codes nous avons besoin de modules de test. Si tout le monde utilise Module:Test on risque de se marcher sur les pieds : conflit de nom, conflit d'edit si deux personnes font des tests en même temps...

Plusieurs possibilité :

• Module:Nom d'utilisateur
• Module:Test/nom d'utilisateur
• Module:Utilisateur:Nom d'utilisateur
• Module:Brouillon Nom d'utilisateur.
• …

Le premier à l'inconvénient d'être mélangé aux autres modules, et comme les noms d'utilisateurs sont très varier cela peut amenè à des confusions / conflit. Je suis donc plutôt contre cette dénomination.

Ma préférence va au troisième. J'ai donc créé mon module en ce sens. Si besoin on renommera en fonction de la décision collective.

— Zebulon84 (d) 28 février 2013 à 04:19 (CET)

Salut, pourquoi nommer en fonction des utilisateurs et non des modules eux-mêmes ? Si je bosse sur un Module:Bidouille, le plus logique serait d'avoir une page Module:Bidouille/Test en guise de test. — Dakdada (discuter) 28 février 2013 à 10:29 (CET)

Hm non en fait j'ai confondu module de test et page de test (que tout module devrait avoir, soit dit en passant). — Dakdada (discuter) 28 février 2013 à 10:33 (CET)

Pour revenir à la question posée, les sous-pages c'est mieux (2). Le nom de la page de base (brouillon, test, essais, expérimental...) n'est pas très important, pourvu qu'il soit clair et unique. — Dakdada (discuter) 28 février 2013 à 10:46 (CET)

Attention : on peut créer un module dans une sous-page de l'espace (Module:Toto/titi). Toutefois − sauf si ça a été corrigé sans que le bug-report associé n'ait été mis à jour − il semble que les mises à jours de modules en sous-pages soient mal gérées. À tester. Cordialement, Hexasoft (discuter) 2 mars 2013 à 18:10 (CET)

Je suppose que le problème de mise à jour se produit, comme avec javascript, lorsque l'on importe un sous-module dans le module principal (avec require pour Lua). Par contre si on fait directement appel à ce sous-module y a-t-il vraiment un problème de mise à jour ? — Zebulon84 (d) 3 mars 2013 à 06:41 (CET)

Ah, pas testé en "direct". De toute façon ça reste pour de la zone de test . Hexasoft (discuter) 3 mars 2013 à 08:37 (CET)

Catégorie

Existe-t-il ou faut-il créer une catégorie "Modèle utilisant Lua" ou quelque chose dans le genre pour retrouver facilement ces modèles ? Ou existe-il une fonction de Scribunto permettant déjà de les retrouver ?

Que ce soit pour avoir des exemples d'implémentation ou pour la maintenance il me parait important de connaitre la liste des modèles faisant appel à du code Lua.

— Zebulon84 (d) 4 mars 2013 à 10:31 (CET)

Autant que je sache ça n'existe pas actuellement.

Les pages liées fonctionnent sur les modules, donc on peut savoir où un module est appelé, mais je ne crois pas qu'on puisse trouver tous les modèles utilisant un module.

Vas-y, juste crée-la . Cordialement, Hexasoft (discuter) 4 mars 2013 à 11:01 (CET)

Catégorie:Modèle utilisant Lua. Évidemment elle est assez vide pour le moment. — Zebulon84 (d) 4 mars 2013 à 11:37 (CET)

Note : à venir (normalement) dans la prochaine release : l'inclusion automatique de pages de doc pour les modules. On devrait donc à terme pouvoir aussi catégoriser les modules eux-mêmes. Hexasoft (discuter) 4 mars 2013 à 12:53 (CET)

Infos

Juste pour info, la librairie "language" permet d'obtenir un comportement "localisé" pour certaines fonctionnalités. En particulier la gestion des dates et le formatage des nombres. Pour l'utiliser il faut faire ça :

-- on récupère un objet "language" correspondant à notre wiki
local lang = mw.getContentLanguage()

-- on peut utiliser lang:formatDate de la même façon que #time et #timel
-- ici le "true" à la fin veut dire "heure locale"
local res = lang:formatDate("Y n/m F W j/d z l N G/H i s  t ", nil, true)
-- Donne : 2013 3/03 mars 10 4/04 62 lundi 1 10/10 59 17 31

-- on peut utiliser lang:formatNum de la même façon que #formatnum
local res2 = lang:formatNum(12345678.9876)
-- Donne : 12 345 678,9876

On trouve quelques autres trucs aussi.

Notez au passage comme vous pouvez le voir ci-dessus que le tag syntaxhighlight support bien lang="lua" .

Cordialement, Hexasoft (discuter) 4 mars 2013 à 11:01 (CET)

Détails : je recommande d'utiliser un nom de variable du type "localisation" plutôt que "lang", pour éviter les confusions avec une variable qui parlerait vraiment d'une langue (avec code ISO, encodages, noms). — Dakdada (discuter) 4 mars 2013 à 12:41 (CET)

Oui, effectivement. J'avais simplement recopié la syntaxe utilisée dans la doc.

Note : au passage la doc française est en retard sur la doc anglaise. Ils ont ajouté des trucs il y a peu et je n'ai pas encore mis à jour la version traduite (c'est long…). Je ne sais pas si vous utilisez la version française, donc pensez à valider coté anglais. Hexasoft (discuter) 4 mars 2013 à 12:56 (CET)

Module:MagicDate

Hop,
juste pour dire que j'ai terminé Module:MagicDate. On peut voir son auto-documentation dans Module talk:MagicDate.
Il n'est actuellement pas utilisable depuis un modèle, mais c'est un détail. Son intérêt est relatif en accès direct : je ne pense pas qu'appeler un (vrai) modèle {{LOCALTIME}} qui appelle ce module soit d'un intérêt quelconque par rapport à appeler directement le pseudo-modèle {{LOCALTIME}} actuel.
Toutefois ça peut servir de base à un module "boîte-à-outils" qui fournirait aux autres modules diverses fonctions permettant d'avoir directement en code Lua des fonctionnalités qu'on a actuellement sous forme de pseudo-modèles ou de parser-functions. Ici je traite tout ce qui est relatif aux dates/heures. La librairie mw.site permet de traiter les autres pseudo-modèles fournissant les données du site. On peut aussi ajouter certains parser-functions (formatnum) ainsi (bientôt) que le ifexist, et la librairie mw.uri permet aussi de traiter la plupart des traitements de liens internes/externes.

Z'en pensez quoi ? Ça a du sens de faire un Module:Outils regroupant les traitements fréquents ou pas-si-simples ? Je pense aussi au nettoyage des paramètres (un paramètre non nommé peut avoir des espaces/tabulations/retour-à-la-ligne avant/après) qui est fréquent, des choses comme le découpage de chaînes (split, l'opération inverse de concat), la création de liens vers des images, médias, …

Cordialement, Hexasoft (discuter) 4 mars 2013 à 16:33 (CET)

Un module outils serai effectivement certainement utile. Il faut juste être sur qu'appeler une fonction d'un autre module n'est pas beaucoup plus long que dupliquer une fonction simple.

J'ai mis une function trim dans le module test qui me semble bien nettoyer les paramètres non nommés.

— Zebulon84 (d) 4 mars 2013 à 19:02 (CET)

Je me rappelle une discussion avec les devs de scribunto où il était dit que le gain global de passer par des modules Lua était de tels ordres de grandeurs par rapport aux appels multiples de modèles (avec à chaque fois des appels au parser de mediawiki) qu'il ne fallait pas s'embêter à chercher la petite bête sur du traitement un poil − ou pas − moins efficace. Après tout on ne s'est jamais posé la question pour les modèles qui appellent des modèles qui utilisent des modèles qui… .

En termes fonctionnels j'aurai tendance à dire qu'il vaut mieux une boîte à outils commune optimisée et chargée depuis d'autres modules que de voir des horreurs algorithmiques dupliquées de partout : au moins on peut veiller à ce qu'une base propre et efficace existe. Sinon on risque de voir des frame:preprocess(...) trainer de partout. Ou, par exemple, un double appel à gsub() pour nettoyer les paramètres alors qu'on peut le faire en un seul, chose que j'avais envisagé sans aller au bout mais que tu as fait dans ta fonction trim . Cordialement, Hexasoft (discuter) 4 mars 2013 à 23:01 (CET)

PS : toutefois oui, je ne suis pas pour dupliquer des choses qui se font en une ligne, hein ! Ceci dit si on fait "bien" les choses on peut peut-être arriver à faire intégrer aux librairies de base certaines fonctions Lua très utilisées (par exemple trim qui me semble obligatoire dès qu'on manipule des paramètres non nommés), et comme les librairies de bases sont partagées et chargées nativement ça peut être largement aussi efficace. Hexasoft (discuter) 4 mars 2013 à 23:04 (CET)

ref

Pour crée une note j'ai été obligé de passer par :

frame:preprocess ('<ref>texte de la note</ref>')

Y a-t-il une façon meilleure façon de faire ?

— Zebulon84 (d) 4 mars 2013 à 23:41 (CET)

Me semble pas. Tout tag qui n'est pas purement mise en forme (nowiki, pre, …) est traité au niveau "du dessus", ce qui passe par preprocess (à ma connaissance). Hexasoft (discuter) 4 mars 2013 à 23:52 (CET)

Voir les nouvelles : apparition (non validée) d'un mw.text contenant des choses qui − peut-être − pourraient aller dans ce sens. Hexasoft (discuter) 5 mars 2013 à 09:51 (CET)

title arrive

test2.wikipedia.org a la version de scribunto qui va arriver dans la semaine sur fr:. J'ai testé quelques trucs.
La librairie mw.title est bien présente et permet plusieurs choses :

• obtenir le titre et le namespace de l'article en cours
• permettre de faire un "#ifexist" en Lua sans tricher (note : cette action reste coûteuse).
• d'autres choses

Exemple : Module:Hexasoft-test sur test2 et le résultat.

L'inclusion d'une page de documentation pour les modules fonctionne. Voir Module:Hexasoft-test en terme d'affichage et Module:Hexasoft-test/doc associé. Notez que :

• cette sous-page spéciale est traitée avec la syntaxe wiki et non Lua (contrairement aux autres sous-pages module)
• on peut y mettre ce qu'on veut, et la catégorisation fonctionne pour la page du dessus (le module)
• on peut modifier sur chaque wiki le nom de la sous-page associée dans les messages système

Hexasoft (discuter) 5 mars 2013 à 11:55 (CET)

À propos de ifexist: quelques modèles cherchent à récupérer des informations dans de multiples modèles ({{drapeau}} par exemple). Avec Scribunto, il faudra mettre les informations actuellement disséminées dans des milliers de modèles, dans un seul tableau, inclus dans un module unique. Pour éviter de charger ce tableau à chaque appel du modèle, il existe une fonction mw.loadData. — Dakdada (discuter) 5 mars 2013 à 12:37 (CET)

Oui. D'ailleurs il me semble qu'on gagnera en lisibilité : avoir à chercher dans des dizaines (centaines) de modèles-sous-pages me semble bien plus lourd pour la gestion qu'un seul module de données contenant les infos. Et pouvant d'ailleurs servir à plusieurs choses (après tout c'est une liste de pays, on peut y associer le drapeau, le lien vers l'article, …). Hexasoft (discuter) 5 mars 2013 à 13:08 (CET)

Ça ressemble à une base de données, comme wikidata et microformat, il faut demander à Tpt comment ça fonctionne et comment s'en servir (il a déjà introduit du microformat dans un de mes modules mais je n'ai pas cherché). --Rical (d) 5 mars 2013 à 15:05 (CET)

Mon problème est que je n'ai jamais rien compris à wikidata . Je comprends l'idée générale mais je n'ai jamais compris en pratique comment l'utiliser… Je ne trouve pas que les pages d'aide soient très claires. Hexasoft (discuter) 5 mars 2013 à 18:40 (CET)

Moi non plus, demander à Tpt. Pour une documentation générique de module je propose mw:Module:Auteur --Rical (d) 5 mars 2013 à 19:25 (CET)

Les microformats sont un jeu de classes HTML faits pour permettre au logiciel d'extraire des métadonnées du contenu de pages. Par exemple, le modèle {{Coord}} utilise le microformat Geo.

Wikidata est une base de données centralisé destiné à centraliser les liens inerwikis et à stoker des données sur les entitiés décrites dans les pages de Wikipédia afin de permettre de généré automatiquement les infobox (mais les wikis pourrons toujours garder le système actuel) et des liste via un système de requêtes. Une API lua est en train d'être créé afin d’interagir avec cette base de donnée (afin, par exemple, d'obtenir la page sur Wikipédia en français correspondant à l'entrée Wikidata lié par la propriété "père" à l'entré Wikidata QXYZ correspondant à la page chose dont on est en train de régénérer l'infobox...).

Tpt (d) 5 mars 2013 à 20:04 (CET)

Ok pour les microformats. Encore que je ne sache pas si et/ou comment ceci est exploité actuellement.

Par contre pour wikidata je n'ai pas compris . Enfin, si, mais je comprends à travers l'exemple spécifique des interwikis, mais pas son utilisation éventuelle dans d'autres domaines.

Pour prendre l'exemple évoqué plus haut : on a actuellement techniquement des modèles multiples qui définissent des propriétés pour chaque pays (dans le cadre du modèle {{Drapeau}} mais ça va nettement plus loin). Pour la France des choses comme le nom du pays, les drapeaux liés aux différentes périodes, le champs alt, et d'autres trucs que je ne comprends pas .

Le passage aux modules, de prime abord, tendrait à créer un module "de données" qui contiendrait une table des pays, indexé par nom et/ou code, contenant en valeur une liste de champs=valeur qui correspondrait à ces informations → information regroupée et non éclatée, simplicité de mise à jour, d'ajout ou de suppression. Cette (ou ces) table serait chargée dans le ou les modules qui auraient besoin de ces informations. Ce pourrait d'ailleurs être plus large que simplement la gestion des drapeaux, un index d'informations pour chaque pays ayant du sens : langue(s) parlée(s) ; code monétaire ; code ISO ; infos de drapeau ; devise nationale ; hymne ; …

Est-ce qu'à terme (car il me semble qu'actuellement wikidata est "restreint" à quelques usages spécifiques) ce genre de regroupement d'informations serait adapté/possible/pertinent dans wikidata ?

Et si oui est-ce qu'un module peut/pourra obtenir sous forme exploitable (in fine une table Lua) cette liste d'information pour un pays donné, pour − par exemple − afficher le bon drapeau ou afficher le code, la monaie, … ?

Cordialement, Hexasoft (discuter) 5 mars 2013 à 22:35 (CET)

Oui, pour l'instant Wikidata est retreint au liens entre entité et vers les fichiers de commons. Mais demain (mercredi 7 mars) va être ajouté le type de donnée chaîne de caractère, puis dans quelques semaines le type valeur numérique (avec unité et précision), le type date et le type coordonnée géographique. Ce que l'on pourra faire en lua est quelque chose comme cela (ce n'est qu'une vague idée de ce que ce sera réellement) pour obtenir le drapeau de la France :

local item = mw.wikidata.getFromSitelink( "frwiki", "France" ) --On récupère l'entré Wikidata lié à la page [[France]]
if item.claims["p41"] then --Si il y a un au moins un "claim" (ie un couple propriété-valeur avec en plus des sources et des infos complémentaires) pour la propriété n°41: https://www.wikidata.org/wiki/Property:P41
   local drapeau = item.claims["p41"][0].mainSnak.value --On récupère la valeur du couple propriété-valeur principal du premier "claim" qui est ici le nom du fichier sur commons
end

Pour la définition des termes utilisé, regarde le glossaire. Tpt (d) 6 mars 2013 à 09:15 (CET)

Merci pour ces précisions. Cordialement, Hexasoft (discuter) 6 mars 2013 à 10:15 (CET)

{{Projet Scribunto}}

J'ai créé un modèle à implanter dans la documentation des modèles utilisant des modules. Il n'y a pour le moment pas de catégorie automatique pour avoir une liste complète, mais je vous laisse la liberté de la créé et donc de la nommer. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 6 mars 2013 à 23:22 (CET)

Tu aurais pu faire un module ! Hexasoft (discuter) 6 mars 2013 à 23:27 (CET)

j'y comprends rien pour le moment, mais si tu veux convertir le méta modèle (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 6 mars 2013 à 23:28 (CET)

Héhé. Pas de problème, mais ça attendra la fin de semaine que la librairie mw.title soit active, afin d'avoir accès proprement au titre et au namespace de la page (utilisé dans le modèle méta-truc). Hexasoft (discuter) 6 mars 2013 à 23:48 (CET)

Organisation des modules / sous-pages

Hop,
on a évoqué plus haut comment organiser les modules de test.
Avec l'arrivée (cette semaine normalement) des pages de documentation des modules il faudrait voir comment ranger tout ça. Je vois pour ma part :

• le nom de la sous-page de documentation : autant suivre ce qui est fait pour les modèles. Je propose donc /Documentation (ce sera à faire régler dans les messages système).
• il me semble qu'il faudrait aussi prévoir une sous-page (éventuelle) pour la copie d'un module en version "test". Pour les modules gros/très utilisés/complexes − comme pour les modèles − il me semble utile d'avoir une copie exacte du module "officiel", mais :
  • qu'on puisse modifier et casser sans impact
  • sur lequel on puisse tester de nouvelles fonctionnalités sans toucher à l'existant
  • non protégé (modules très utilisés) afin que même les non admins puissent faire des tests.

Pour ce dernier pourquoi pas /Test ou /Essai ? Peut-être pas "Test" car ça donne plus l'impression que c'est pour tester (le résultat) que pour tester (le code).

Autre question : la (future) page de documentation sera incluse directement. Il me semble qu'il faut se mettre d'accord sur ce qui doit aller dans une page de documentation module par rapport à ce qui doit aller dans une page de documentation modèle (ce qui sera utilisé in fine par les éditeurs).
Afin de ne pas repousser le code Lua trop loin après la doc il me semble qu'il faudrait rester court, ou prévoir peut-être des boîtes déroulantes… Par exemple juste un entête indiquant que c'est un module, ce qu'il fait en gros, ainsi que le nom des fonctions exportées et les dépendances éventuelles.
Peut-être aussi un lien vers les pages liées, pour voir où il est utilisé directement. Ensuite, j'aurai tendance à dire dans une boîte déroulante le reste de la doc technique (les fonctions annexes, les éléments techniques, spécifiques, …).

Des avis ? Cordialement, Hexasoft (discuter) 6 mars 2013 à 23:59 (CET)

Oui pour une page de doc réduite, mais aussi à des commentaires en situation dans le code, pour relier chaque portion de code à son objectif et à ses particularités.

La documentation des modèles est orientée utilisation, celle des modules est orientée technique de codage.

Mais aussi : un module peut fournir des fonctions à plusieurs modèles, et un modèle peut combiner des fonctions de plusieurs modules.

Pour la sous-page de nouvelles fonctionnalités, peut-être /Debug, /Evoluer, /Evolution ?

Personnellement j'utilise des indices comme : Auteur, Auteur2, Auteur3, sans sous pages, pour faciliter les tests sur quelques pages banales des nouvelles versions de modules ou de modèles. --Rical (d) 7 mars 2013 à 01:39 (CET)

Je suis favorable à garder « /Test » pour les tests unitaires (et donc pas les « branches » — pourquoi pas « /Branches/NomDeLaBrancheQuiDitCeQuIlYADedans », d'ailleurs ?),

Concernant la documentation, on pourrait s'inspirer des documentations déjà existantes, type Doxygen ou Luadoc, voire Apiary. D'ailleurs je ne suis pas certain que ce soit pertinent d'écrire la doc « à la main » hors du code source des modèles, si on se limite à une documentation purement technique — on pourrait la générer pour l'essentiel à partir des commentaires.

Amicalement — Arkanosis ^✉ 7 mars 2013 à 02:52 (CET)

Repousser le code Lua n'est franchement pas le plus important (c'est facile d'y accéder). Je pense qu'au contraire la doc doit être suffisamment complète pour qu'on n'ait justement pas à parcourir le code pour savoir quelles fonctions le module propose (en listant les seules fonctions utilisables, leur rôle, leurs entrées et sorties). Bien sûr si on pouvait extraire ces infos des commentaires du code ce serait pas mal, mais difficile à réaliser.

Sinon : ok pour /Documentation. Pour les pages de bidouillage des modèles : peut-être /Clone ou /Beta ? /Debug n'est pas mal non plus. /Test est ambigü : on ne sait pas s'il s'agit d'un code ou d'une page de test du code. — Dakdada (discuter) 7 mars 2013 à 10:10 (CET)

Assez d'accord. En ce cas on pourrait avoir quelque chose comme :

• description synthétique du module
• les dépendances (autres modules utilisés par ce module)
• liste des fonctions publiques, avec leur description, paramètres…
• les autres fonctions éventuelles (non publiques), avec leur description, paramètres… Cette dernière partie pourrait être en déroulant car ne concernant pas ceux qui souhaitent utiliser le module mais seulement ceux qui souhaitent modifier le module.

D'accord aussi sur le /Test ambigü. Je n'aime pas trop /Debug, qui a un sens trop "typé" à mon goût. /Beta, pourquoi pas. Hexasoft (discuter) 7 mars 2013 à 10:55 (CET)

Je suis également de l'avis des propositions précédentes. Utiliser des sections déroulantes dans une sous-page de type /Documentation, c'est plutôt une bonne idée.

Le modèle {{Documentation}} autorise les sous-pages de type /Bacasable et /Test, on pourrait s'en inspirer. Le tout, c'est de minimiser les sous-pages pour éviter de ce retrouver avec du contenu partiellement utile. ~Hlm Z. [@] 7 mars 2013 à 11:37 (CET)

Tester Scribunto

L'exemple Hexasoft de liste de la table mw m'a paru très intéressant parce que j'ai souvent des problèmes de bugs. Je l'ai adapté à mes besoins et intégré à mon testeur de Scribunto où j'ai limité les namespaces trop envahissants. --Rical (d) 8 mars 2013 à 17:42 (CET)

Merci. Je viens de découvrir que la liste des fonctions disponible ici est sur Module talk:Test. Donc il est normal que mw.loadData ne marche pas dans mon module, elle n'est pas encore disponible sur fr.wp. C'est ce que j'avais compris, mais maintenant je sais ou regarder avant d'essayer de réactiver cette fonction, ou d'autres. — Zebulon84 (d) 8 mars 2013 à 18:13 (CET)

Oui, je n'avais pas pris le temps d'en parler ici. On devrait aussi voir apparaître (le 11 normalement) la table mw.title qui contient des choses intéressantes.

Notez toutefois que ceci ne permet pas de voir les méthodes (les éléments appelés avec ":" et non "."), il serait intéressant de voir si c'est possible de les détecter automatiquement. Hexasoft (discuter) 8 mars 2013 à 18:38 (CET)

Quand j'ai voulu importer ici la doc de mon testeur, je n'ai pas pu. Alors que dans MediaWiki et WikiSources, la page de doc des modules est prévue automatiquement. Et les fonctions de mw.title ne fonctionnent pas, comme si vous aviez été oubliés lors de la dernière mise à jour. Et je ne sais même pas à qui demander ça. Faut-il attendre la suivante ? --Rical (d) 12 mars 2013 à 20:26 (CET)

Ha, non ! En fait, vous êtes les derniers à recevoir les versions, pour vous c'est demain d'après le planning en phase 4, All other Wikipedias. --Rical (d) 12 mars 2013 à 22:56 (CET)

Ouaich, c'est ce que j'indique plus bas (on n'est plus privilégiés). Ça arrive demain normalement. Au passage il n'y aura pas le module mw.text qui contient quelques fonctions utiles, et surtout (de mon point de vue) unstrip() qui permet (normalement) de traiter les paramètres reçus avec des tags. Sur ce point attention : string comme ustring sont actuellement incapables de traiter correctement un paramètre qui contiendrait des tags comme nowiki, pre et ref (bien qu'on puisse retourner la chaîne et qu'elle fonctionne on n'a pas accès au contenu complet, par exemple ce qui est à l'intérieur du nowiki). Hexasoft (discuter) 12 mars 2013 à 23:05 (CET)

Navigateur

Y a-t-il un moyen d'avoir un code spécifique pour IE6/7 (voire 8) pour pouvoir utiliser les fonctions moderne du html / css et avoir malgré-tout une présentation fonctionnelle sur ces vieux navigateurs ? Ou est-ce que l'on peut oublier la compatibilité Ie6 (pour) et Ie7 (peut-être encore un peu tôt) ?

Question annexe, existe-t-il une nouvelle version de ce rapport qui n'est plus mis à jour depuis novembre dernier ?

— Zebulon84 (d) 11 mars 2013 à 19:40 (CET)

Hmmm… Pour autant que je sache Scribunto n'apporte scrictement rien sur ce plan-là. Il a accès aux mêmes informations que les modèles (grosso modo), et c'est donc dans le JS/CSS que ce genre de problème doit se gérer.

On pourrait sans doute envisager une librairie mw.client (ou un truc du genre) qui retournerait des infos sur la connexion en cours mais je doute que cela ne se fasse jamais pour plusieurs raisons :

• je présume que ça tuerait tout le système de cache, puisque l'exécution serait dépendante de qui regarde la page et non pas seulement du contenu de l'article et des modules/modèles utilisés (à préciser, je ne suis pas tech ) ;
• j'ai le sentiment que ça serait refusé de la même façon que les parser-functions similaires ont été refusées, à savoir que l'aspect éditorial ne doit pas se préoccuper de ça et que ça peut dériver (infos de navigation privées).

Après même si je suis certain que ça apporterait une vraie souplesse de codage (par rapport au CSS+JS) je me demande si ça ne risquerait pas de compliquer les codes des modules…

Cordialement, Hexasoft (discuter) 11 mars 2013 à 20:19 (CET)

Je ne pense pas que cela soit du ressort de Scribunto. Néanmoins, je ne crois pas que supporter des navigateurs qui ne sont plus à jour soit une bonne chose. Si quelqu'un utilise un navigateur périmé, qu'il en assume les conséquences. En bref : normalement on n'a pas à se préoccuper des navigateurs. — Dakdada (discuter) 11 mars 2013 à 20:22 (CET)

Zebulon84 : j'ai posé la question. Il faudrait a priori un exemple concret pour ouvrir une discussion là-dessus, si tu pouvais indiquer ça ?

Je vais assez dans le sens de Darkdadaah : sans être un adepte de "soyons à jour" gérer les problèmes de logiciels hors d'âge semble difficile à assumer sur WP (après tout où est la limite : j'ai une vieille silicon graphic au labo qui a toujours un Netscape Navigator ). Hexasoft (discuter) 11 mars 2013 à 20:45 (CET)

Merci de vos avis.

Exemple concret : Utilisateur:Zebulon84/Brouillon10 utilise des display:table-cell et est donc en vrac sur Ie7.

Avec Ie7, il faudrait remplacer chaque couple de table-cell par une table complète, donc plus lourd, ou reprendre le tableau actuel plus pénible à programmé et maintenir (le modèle actuel et ses frères posent des problème de performance lorsqu'il y en a plusieurs dans le page, c'est pourquoi je travaille dessus).

Par ailleurs comment définir un navigateur périmé ? Netscape ou Ie5 sont sans conteste périmés, mais par exemple IE6 reçois encore des mise à jour de sécurité et il est toujours possible de le télécharger donc Microsoft ne le considère pas encore comme définitivement supprimé. Mais s'il suffit d'avoir une page correcte sur Ie8 ça me va bien, ça évite les prise de tête.

— Zebulon84 (d) 11 mars 2013 à 22:27 (CET)

Microsoft lui-même veut se débarrasser de IE6 [1], donc voilà. Quant à IE7 il est moins utilisé que IE6. Mon avis est donc de ne réfléchir qu'à partir de la version 8 (qui respecte la plupart des standards de base). — Dakdada (discuter) 11 mars 2013 à 23:32 (CET)

Bandeaux d'ébauche

Bonjour à tous ! J'ai terminé ce matin une conversion du modèle {{Ébauche}}. Voici la page du modèle et les tests. Le code se trouve dans le module Bandeau. Je vais probablement continuer sur ma lancée avec les modèles de portails et de drapeaux. Vos remarques et corrections sont les bienvenues Tejgad (d) 12 mars 2013 à 12:26 (CET)

Vu le code actuel du modèle {{Ébauche}}, il y a de fortes chances pour que ton module soit bénéfique. Une question me turlupine, est-il possible de faire des tests (concrets) de rapidité entre les deux versions (Parser vs Lua) ? ~Hlm Z. [@] 12 mars 2013 à 12:36 (CET)

Note à garder en tête pour quand ça viendra : mw.text.listToText sera une fonction pour faire du "X, Y, Z et W" à partir des éléments, avec choix des séparateurs… Ce n'est pas encore disponible mais noté pour intégration. Hexasoft (discuter) 12 mars 2013 à 12:52 (CET)

Note bis : si tu fais les autres bandeaux, tu peux jeter un œil à Module:Article détaillé (qui fait "article détaillé", fort logiquement) et sa doc Modèle:Article détaillé/Lua/Documentation. Tu peux peut-être y récupérer des morceaux si besoin. Hexasoft (discuter) 12 mars 2013 à 12:55 (CET)

Modèles de données

Quelques modèles ne sont utilisés que pour stocker des données. Ces données devront être déplacées soit dans Wikidata (recommandé), soit dans une table dans un module (si ce sont des données vraiment locales). Quelques exemplaires :

• Modèle:Couleur parti politique québécois/*
• Modèle:Country alias *
• Modèle:Country data *
• Modèle:Country flag alias *
• Modèle:Dernière version avancée/*
• Modèle:Dernière version stable/*
• Modèle:Données/*/informations générales
• Modèle:Données/*/évolution population
• Modèle:Données année/*
• Modèle:Drapeau2/*
• Modèle:Démographie commune d'Italie/*
• Modèle:Géolocalisation/*
• Modèle:Géolocdual/*

Rien que ceux-là représentent probablement plus de 10 000 modèles. Et je n'en suis qu'à la lettre D. — Dakdada (discuter) 12 mars 2013 à 14:53 (CET)

Ouarf. J'aurai tendance à dire qu'il faut les passer en Scribunto. Il semble que l'utilisation de wikidata pour du stockage "libre" de données soit pour "dans un certain temps". En tout cas pour ce qui est local (par exemple ce qui a été fait sur la partie ébauche) ça me semble une bonne idée. Hexasoft (discuter) 12 mars 2013 à 18:56 (CET)

Pour l'interaction avec Wikidata, je ne sais pas vraiment, mais il a peut-être une interaction à double sens entre chaque wiki et Wikidata. Par exemple j'ai vu que les liens interwikis entre articles sont déjà migrés vers Wikidata. Il vaut mieux demander à Tpt comment migrer des données de Wikipedia à Wikidata grâce aux modules dès le début, si la méthode est au point et permet d'économiser du travail. --Rical (d) 12 mars 2013 à 20:07 (CET)

J'ai lancé le calcul de recherche de modèles gourmands hier, en espérant que la connexion ne soit pas interrompue d'ici la fin. Pour l'instant j'en suis à peu près à la moitié des modèles, soit ~80 000. Je publierai la liste une fois fini. — Dakdada (discuter) 14 mars 2013 à 15:24 (CET)

Doublon ?

Catégorie:Modèles utilisant des modules Lua et Catégorie:Modèle utilisant Lua ne font elles pas doublon ? D'après ce que j'ai compris, le langage Lua doit être utilisé dans l'espace module donc à priori tout modèle utilisant Lua utilise des modules Lua. Non ? (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 12 mars 2013 à 20:27 (CET)

Il semble que ça fasse doublon, effectivement. Pour autant que je sache il n'est pas possible d'appeler du code Lua en dehors de l'espace Module, puisque #invoke attend un nom de module sans préfixe (Toto et non Module:Toto) laissant donc à penser qu'il n'y a pas le choix. D'ailleurs l'éditeur de code Lua ne se déclenche que dans l'espace module, et il me semble que le code Lua est pré-compilé à la sauvegarde, ce qui doit sans doute ne se produire que dans cet espace. Maintenant faut choisir lequel garder . D'ailleurs, sans vouloir chipoter, ne serait-ce pas Scribunto, et non Lua, qu'il faudrait ? Hexasoft (discuter) 12 mars 2013 à 21:08 (CET)

Pas nécessairement je pense, en effet Scribunto ne peut gérer pour le moment que le langage Lua, mais qui sait ce que réserve l'avenir. Après pour ce qui est de l’appellation de la catégorie, àmha, cela devrait être Catégorie:Modèle appelant des modules en langage Lua. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 12 mars 2013 à 21:50 (CET)

Oui, soit on parle de langage Lua, soit on parle de Scribunto − le module mediawiki qui permet de programmer en Lua . Hexasoft (discuter) 12 mars 2013 à 22:49 (CET)

Désolé d'avoir créé ce doublon. Mes recherches visiblement trop succinctes ne m'avais pas permis de trouvé la catégorie Catégorie:Modèles utilisant des modules Lua crée quelques jours plus tôt. Je n'ai pas d'avis tranché sur la meilleure façon d'appelé cette catégorie ; du moment qu'elle existe je suis content. — Zebulon84 (d) 13 mars 2013 à 03:13 (CET)

Fusionné et renommé. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 14 mars 2013 à 15:43 (CET)

Plus de privilèges :(

Je viens de vérifier sur en: : ils ont la mise à jour et pas nous. Ça veut dire qu'on n'est plus dans les "mises à jour en prime-time" . Il faudra donc attendre le 13 pour voir mw.title arriver. Hexasoft (discuter) 12 mars 2013 à 21:26 (CET)

De quoi tu parles ? --pixeltoo (discuter) 14 mars 2013 à 11:03 (CET)

Ben de ce qui est écrit . Nous avons eu au début une situation "en avance de phase" pour les mises à jour de scribunto, ce n'est plus le cas maintenant. Hexasoft (discuter) 14 mars 2013 à 11:12 (CET)

C'est quoi mw.title ? --pixeltoo (discuter) 14 mars 2013 à 11:14 (CET)

Voir Projet:Scribunto#Nouvelles et le Manuel de référence de Lua en anglais (je n'ai pas encore traduit cette partie dans le manuel en français). Hexasoft (discuter) 14 mars 2013 à 11:34 (CET)

Ok. Merci.--pixeltoo (discuter) 14 mars 2013 à 11:50 (CET)

{{PAGESINCATEGORY}}

Bonjour. Il y a une fonction de Scribunto qui va faire la même chose. Quelqu'un qui s'y connaît peut-il tester un module utilisant cette fonction ? L'actuel {{PAGESINCATEGORY}} bugue, depuis longtemps, quand on l'utilise sous la forme {{PAGESINCATEGORY:{{PAGENAME}}}} dans une catégorie dont le nom comprend par exemple une apostrophe, ce qui me pose problème à plusieurs titres, par exemple dans la gestion des articles liés. Thierry Caro (d) 14 mars 2013 à 10:57 (CET)

C'est possible, oui. Peux-tu préciser exactement ce que tu veux ? Un module qui prennent en paramètre un nom de catégorie et qui retourne la liste des articles qui sont dedans ? (je ne connais pas PAGESINCATEGORY). Hexasoft (discuter) 14 mars 2013 à 11:12 (CET)

À la base, je voudrais exactement ce que fait PAGESINCATEGORY. Il donne juste le nombre d'entités dans une catégorie donnée. Un paramètre optionnel permet de déterminer quel type d'entité compter : pages seulement, sous-catégories seulement, fichiers seulement ou tous les types d'entités, ce dernier choix par défaut. Mais tu laisses entendre qu'on pourrait obtenir des listes ? Est-ce que ça veut dire qu'on pourrait aussi avoir un module cherchant par exemple la cinquième page, par ordre alphabétique, à l'intérieur de la catégorie ? Ou tous les articles classés à la lettre B ? Ou plus loin encore classer les articles par date de création, etc. ? Si ton module peut faire ce genre de choses, c'est certain que c'est bienvenu. Thierry Caro (d) 14 mars 2013 à 11:28 (CET)

Ah non, j'avais mal lu. La fonction fait partie de mw.site.stats, et retourne donc uniquement un nombre d'articles. Je fais un test dans la foulée. Hexasoft (discuter) 14 mars 2013 à 11:41 (CET)

Voici un résultat : Discussion module:Test (partie test pagesInCategory). Tu peux reprendre ce code pour tester si le comportement est correct par rapport à ce que tu attends.

Note : la fonction permet aussi de récupérer en une fois une table avec chaque valeur séparément. Si tu as des besoins de mise en forme ça peut peut-être servir plutôt que d'appeler la fonction avec "subcats", puis "files", puis "pages". Cordialement, Hexasoft (discuter) 14 mars 2013 à 11:57 (CET)

Note 2 : ne pas utiliser en prod, hein ! C'est vraiment codé vite fait pour tester. Il faut au minimum ajouter le formatage en français des nombres retournés, et voir que faire dans les cas invalides (retourner 0, une erreur ?). Hexasoft (discuter) 14 mars 2013 à 12:18 (CET)

Merci. Malheureusement ça ne permet pas de résoudre le bug généré par l'apostrophe. Invoqué dans une catégorie comme Catégorie:Province d'Anvers, {{#invoke:Test|pageincat|{{PAGENAME}}|pages}} retour 0 au lieu de 28. Thierry Caro (d) 14 mars 2013 à 14:10 (CET)

J'ignore la raison de ce comportement. D'autant plus que {{#invoke:Test|pageincat|Province d'Anvers|pages}} fonctionne très bien, et qu'en ajoutant du debug j'ai dans les deux cas le même texte. Il faudrait que je regarde dans la chaîne reçue pour voir si il n'y aurait pas des caractères spéciaux qui trainent.

En attendant j'ai modifié le comportement : si on ne donne pas le nom de la catégorie il prend le nom de la page où il est. Si tu utilises ça en dehors d'une catégorie le résultat est non prédictible mais ça semble marcher en tout cas. Hexasoft (discuter) 14 mars 2013 à 14:59 (CET)

Si ça se trouve le invoke n'interprète pas {{PAGENAME}} et cherche vraiment dans une catégorie:{{PAGENAME}}, nécessairement vide. — Dakdada (discuter) 14 mars 2013 à 15:11 (CET)

C'est possible, il faut que je creuse. Toutefois normalement l'appel au module ne se fait qu'après le traitement des modèles et pseudo-modèles. Et dans le debug je retournais à la fois le nombre et le terme reçu. Sauf si le terme reçu était {{PAGENAME}} et qu'il est interprété après le retour . Je vais creuser, mais si c'est le cas c'est lourd… Ici c'est aussi simple de laisser le module détecter le titre de la page (après tout que ce soit PAGENAME ou Lua qui fasse l'accès au titre ça ne change rien… et au moins ça marche ). Hexasoft (discuter) 14 mars 2013 à 15:34 (CET)

Tant que ça marche, ça me va ! Serait-il possible d'obtenir ça de façon propre avec Module:Pagesincat et Modèle:Pagesincat dédiés ? En outre, je préfère que le truc retourne un nombre non formaté, et donc sans préciser « pages » etc. En tout cas merci, c'était un problème persistant. Thierry Caro (d) 14 mars 2013 à 16:04 (CET)

Si tu n'est pas pressé je regarde ça ce soir. Le "pages" a été ajouté entre temps pour test. J'ajouterai je pense une option "|mise en forme=oui" (inactive par défaut) pour ceux qui voudraient avoir le formatage. Il faudra que mette le tout dans un "vrai" module. Le module "Test" n'est pas la meilleure place pour du code en prod . Hexasoft (discuter) 14 mars 2013 à 16:12 (CET)

← Modèle:Pagesincat est créé, ainsi que Module:Pagesincat. Voir la doc correspondante dans le modèle.
Dis-moi si les fonctionnalités conviennent. Faut-il d'autres options ? La possibilité de ne pas afficher les erreurs ? Une catégorie d'erreur en cas de mauvaise utilisation ? Hexasoft (discuter) 14 mars 2013 à 21:33 (CET)

Au passage : voir Module:Pagesincat, où je teste une mise en forme des documentations de modules. Dites-moi si ça vous semble lisible… Cordialement, Hexasoft (discuter) 14 mars 2013 à 22:15 (CET)

Merci. J'ai déployé ça. Thierry Caro (d) 15 mars 2013 à 19:42 (CET)

Outil de développement pour Lua

Je voulais signaler qu'il existe des plugins pour développer en Lua sous Eclipse comme LDT que j'ai installé via le Market place. Mon problème étant que je n'ai pas trouvé le moyen d'avoir l'autocompletion comme c'est le cas en java. --pixeltoo (discuter) 14 mars 2013 à 11:27 (CET)

C'est arrivé pendant qu'on en parlait

La mise à jour vient de se faire sur fr:. Dans les nouveautés on a :

• mw.loadData qui permet de charger plus rapidement des modules ne contenant que des données (voir la doc pour les restrictions)
• mw.getContentLanguage : raccourci vers mw.language.getContentLanguage qui permet d'avoir un objet "local" qui contient des fonctions et méthodes adaptées à la langue (par exemple formater un nombre au format français ou obtenir l'heure sur wp.fr)
• mw.title, la fameuse table permettant de faire des choses intéressantes :
  • getCurrentTitle() retourne un objet titre pour la page en cours. Contient (entre autre) le nom de la page (sous diverses formes) et le namespace
  • makeTitle() permet de "créer" un titre (autre que notre propre titre). Permet de savoir si la page existe (id différent de 0). Attention : fonction "coûteuse".
  • getContent() (une méthode d'un titre) permet d'obtenir le contenu de la page, en format brut, non interprété.

Hexasoft (discuter) 14 mars 2013 à 12:06 (CET)

Note : comme vous pouvez le voir dans Module:Test on a aussi l'inclusion de la sous-page de documentation.

Actuellement c'est "/doc" par défaut. Il faut faire changer le message système associé avant d'en créer de partout (pour éviter des renommages plus tard).

Il me semble que "/Documentation", comme pour les modèles, est bien. Il faudrait probablement faire un module de doc (histoire d'avoir des entêtes standards et tout).

Note bis : mw.text sera pour la prochaine mise à jour. Cette librairie contient divers fonctions utiles, y compris une permettant de faire un "unstrip" sur des textes (venant de paramètres) qui contiendraient des tags encapsulés (ref, nowiki, pre), sachant qu'actuellement il n'est pas possible de connaître le contenu d'une telle chaîne. Hexasoft (discuter) 14 mars 2013 à 12:16 (CET)

Rapidement pour ceux qui veulent un équivalent du PAGENAME : mw.title.getCurrentTitle().text (ou fullText pour FULLPAGENAME).

Sinon pour faire un ucfirst : mw.language.new('fr'):ucfirst( mot ). — Dakdada (discuter) 14 mars 2013 à 14:09 (CET)

Peut-être est-ce de ça dont j'ai besoin pour mon problème plus haut ? Thierry Caro (d) 14 mars 2013 à 14:12 (CET)

Dakdada : il me semble que mw.getContentLanguage():ucfirst( mot ) est plus direct. Inutile de spécifier la langue (dans ce cas) et en plus c'est probablement pré-chargé pour 'fr' sur 'fr'. Hexasoft (discuter) 14 mars 2013 à 14:49 (CET)

Ça dépend sur quoi on fait ucfirst. Si l'environnement de langue est anglais (mettons) et qu'un modèle veut mettre un mot français en majuscule, c'est pas sûr que ça marche. La langue doit correspondre au mot qu'on veut traiter, sinon ça n'a pas trop de sens. — Dakdada (discuter) 14 mars 2013 à 15:08 (CET)

Oui, bien sûr. J'étais dans le cas simple (mais sans doute fréquent) d'un module sur fr:, pour fr:, traitant des mots français . Hexasoft (discuter) 14 mars 2013 à 15:36 (CET)

J'ai ajouté un petit test à la doc, ça permet de classer automatiquement. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 14 mars 2013 à 15:54 (CET)

Nom de la sous-page de doc

Hello,
en fait au final c'est une pas une sous-page de doc, mais une page, donc il n'y aura pas de changement à venir.
Actuellement c'est "Module:$1/doc". Il faudrait choisir rapidement le nom histoire de ne pas avoir trop de pages à renommer plus tard.
Il me semble que /Documentation avec les faveurs, car c'est comme pour les modèles. Ça vous va ?
Dans les autres trucs à changer :

• scribunto-doc-page-does-not-exist : ''Documentation for this module may be created at [[$1]]'' → ce qui apparaît en l'absence de page de doc. J'ai mis ''La documentation de ce module peut être créée dans [[$1]]''
• scribunto-doc-page-header : '''This is the documentation page for [[$1]]''' → apparaît en début de page de doc, quand on visualise cette page directement. Si on prend l'habitude de mettre un modèle de doc dans les pages de doc c'est peut-être inutile… Il faudrait à mon sens que ce soit plus discret quoi qu'il en soit. Virer le gras (et éventuellement mettre dans un div pour le différencier du reste de la page ?).
• scribunto-doc-page-name : Module:$1/doc → le nom de la page, avec $1 le nom du module concerné. On met donc : Module:$1/Documentation ?
• scribunto-doc-page-show : {{$1}} <hr /> → transluction de la page de doc. Pas obligatoire, on pourrait juste mettre un lien vers la page au lieu de l'inclure. Ça me parait bien comme c'est.

Note : d'après la doc includeonly et noinclude fonctionnent comme pour les docs de modèles dans les modules. On peut donc (par exemple) catégoriser le module dans un includeonly et la doc dans un noinclude.

Cordialement, Hexasoft (discuter) 14 mars 2013 à 16:24 (CET)

Je vois '''This is the documentation page for [[$1]]''' ici. Juste peut être rajouter un lien pour allez sur la page de doc et éditer celle-ci depuis le module. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 14 mars 2013 à 16:42 (CET)

Attention : ça ne s'affiche que quand on regarde directement la page de doc : Module:Test/doc on voit le texte, mais Module:Test on le voit pas. Ça sert uniquement à prévenir quelqu'un qui arrive ici qu'il est pas sur une page "normale" mais sur une page de documentation de module. Hexasoft (discuter) 14 mars 2013 à 16:45 (CET)

Note : ah tiens, ça y est… L'espace de discussion a été traduit (Discussion module et non plus Module talk) Hexasoft (discuter) 14 mars 2013 à 16:48 (CET)

Oui, ça marche normalement avec la sous page "doc" comme dans tous les autres wikis, voir Module:Unitest_Scribunto. C'est comme dans les modèles, mais il faut colorer soi-même la page de "doc" et y ajouter les liens pour voir et modifier la "doc".

Il faudrait que la coloration soit automatique et les liens aussi, comme pour les modèles.

Désolé, je me suis trompé en renommant, il faudrait effacer la page Discussion Module:Unitest Scribunto‎/doc, s'il vous plait. --Rical (d) 14 mars 2013 à 19:12 (CET)

pour l'effacement. La question reste : qu'est-ce qu'on choisi comme nom pour la sous-page de doc ? /doc comme actuellement (on ne change rien) ? /Documentation (comme les sous-pages de modèles) ? Autre ?

C'est juste que si ça doit changer autant le faire tout de suite, histoire d'éviter des renommages ultérieurs pour les pages de doc créées entre temps. Hexasoft (discuter) 14 mars 2013 à 20:29 (CET)

àmha, il faudrait resté sur la lancé des modèles donc /Documentation. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 14 mars 2013 à 21:24 (CET)

C'est aussi mon avis. Hexasoft (discuter) 14 mars 2013 à 21:34 (CET)

Dans tous les autres wiki, c'est "doc" pour les modules. Peut-être parce-que personne ne s'est posé la question. Je suis d'accord avec "Documentation". Mais il va y avoir des modules de mêmes noms que les modèles, ou très voisins. Un nom différent pour les doc aiderait à rester bien conscient de ce que l'on est en train de faire, modèle ou module. --Rical (d) 14 mars 2013 à 23:56 (CET)

Sur wikisource je crois (au moins) ils ont changé la page. Note : si on a un modèle de doc dédié, on peut faire un affichage différent (fond autre que bleu par ex.), et puis au début de chaque page de doc il y a écrit "Cette page contient la documentation de Module:XXX" Hexasoft (discuter) 15 mars 2013 à 07:58 (CET)

Note : maintenant qu'il y a gestion des docs ça serait bien de trancher sur le nom de la sous-page. On valide "/Documentation" ? Aller, disons que lundi on valide si pas d'opposition . Hexasoft (discuter) 15 mars 2013 à 22:23 (CET)

Pour --Rical (d) 16 mars 2013 à 01:52 (CET)

Pour — Zebulon84 (d) 16 mars 2013 à 08:11 (CET)

Pour, il suffit de demander à un admin de changer MediaWiki:Scribunto-doc-subpage-name. — Dakdada (discuter) 17 mars 2013 à 18:12 (CET)

→ je suis admin, hein . C'est comme ça que j'ai pu faire tous les textes sur les scribunto-doc-* pour inclure automatiquement le module de documentation dans les modules et leurs pages de doc Hexasoft (discuter) 17 mars 2013 à 18:59 (CET)

J'ai appliqué la modification. Voir section dédiée plus bas. Hexasoft (discuter) 18 mars 2013 à 10:03 (CET)

Documentation modèle vue directement

Il faudra faire un {{Documentation module vue directement}} sur le modèle de {{Documentation modèle vue directement}}, ne serait-ce que pour catégoriser automatiquement comme il faut.
Au passage j'utilise {{Documentation modèle vue directement}} dans ma doc, quelqu'un sait pourquoi je n'ai pas la couleur et autres trucs habituel ? Sans doute parce que ce n'est pas "Modèle:"…
Cordialement, Hexasoft (discuter) 14 mars 2013 à 22:55 (CET)

Qu'entends tu par « la couleur et autres trucs habituel » ? S'il s'agit du bandeau de signalisation, cest parce qu'il teste que la sous-page se nomme /Documentation mais on peut corriger cela. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 14 mars 2013 à 23:05 (CET)

Discussion obsolète : j'ai fait un module qui fait tout ça (voir plus bas). Hexasoft (discuter) 17 mars 2013 à 18:59 (CET)

Extraire le contenu d'un article

Voir Discussion module:Test à la fin. Un exemple de récupération de contenu d'une page autre.
Je doute que ça ait un intérêt pour des modules/modèles d'édition classique, mais ça peut servir pour des programmes spécifiques. Par exemple j'ai un module Taxobox dont le modèle n'a pas exactement la même syntaxe. J'ai aussi une fonction qui fait une conversion du format actuel vers le nouveau format. Avec ça je peux faire une page d'outil (interactif ?) permettant de sélectionner un article et de fournir directement le code à mettre à la place. Ça peut servir.
Cordialement, Hexasoft (discuter) 15 mars 2013 à 09:13 (CET)

Intéressant. On pourrait même collecter des infos de plusieurs pages pour une synthèse. Pour les taxobox, les niveaux de classifications supérieurs. Mais collecter des pages et fouiller dedans pour trouver l'info doit être gourmand en ressources. C'est une sorte de transclusion active, ou de mini bot. Il faut en plus que les pages importées aient un contenu adapté, où l'on ne risque pas de récupérer une mauvaise info. Il faut aussi surveiller à long terme que les pages importées n'ont pas changé de noms ou de structure et signaler l'erreur dynamiquement. Intéressant, mais acrobatique et risqué. --Rical (d) 15 mars 2013 à 10:35 (CET)

Tout à fait. C'est bien pourquoi ce n'est pour moi qu'un outil de test et d'assistance. De plus pour récupérer un contenu il faut générer un title, ce qui est une "expensive function", dont le total reste limité même en Lua. On ne peut donc pas faire un bot au vrai sens du terme dans la mesure où c'est limité en nombre de pages qu'on peut traiter. Sans compter qu'il y a une limite de ressources (mémoire + temps) pour un script Lua.

Mais pour du module outil de maintenance, à appeler explicitement au coup par coup pour tester certaines choses, ça peut le faire.

Par exemple ici Utilisateur:Hexasoft/Scribunto j'affiche le format actuel d'une taxobox, sa version convertie, et l'interprétation de sa version convertie, ce qui permet de tester facilement la qualité du convertisseur. Hexasoft (discuter) 15 mars 2013 à 11:32 (CET)

Fonctions de bases

On aura vraisemblablement besoin d'un module contenant des fonctions de base. Il faudrait alors choisir un nom. J'ai déjà créé un module de ce type sur le Wiktionnaire : wikt:Module:bases. — Dakdada (discuter) 15 mars 2013 à 13:57 (CET)

Module:String recouvre certaines fonctions amha. Sinon on pourrait l'appeler [[Module:Outil]].--pixeltoo (discuter) 15 mars 2013 à 14:02 (CET)

J'ai l'impression que Module:String est essentiellement un adaptateur pour utiliser directement dans les modèles des fonctions qui existent déjà dans Scribunto (toutes les fonctions de ce module ont comme entrée un frame). Un modèle Bases (ou Outils) tel que je l'entend contiendrait des fonctions (qui ne se trouvent a priori pas dans les modules par défaut) utilisables par les autres modules, mais pas directement dans les modèles. — Dakdada (discuter) 15 mars 2013 à 17:17 (CET)

Ok si tu t'en sent l'envie n'hésite pas !--pixeltoo (discuter) 15 mars 2013 à 17:35 (CET)

Je suis d'accord avec Dakdada : si ce sont des fonctions de base Lua on ne va pas les inclure dans d'autres modules mais utiliser directement la fonctionnalité Lua.

Pour ce qui est d'un module fournissant des fonctionnalités directes (comme celui-ci) je vois deux choses :

• les choses qu'on peut déjà faire directement (pseudo-modèle, parser-functions…). Est-il plus efficace de remplacer l'appel à un pseudo-modèle par l'appel à un module ? Je ne sais pas. Je pense que le gain est probablement faible (s'il existe).
• les choses qu'on ne peut pas faire (traitements des chaînes par exemple). Ça peut être intéressant, pourquoi s'en priver. Toutefois à part peut-être pour des cas simple ceci ne va-t-il pas être utilisé dans des modèles existants ou nouveaux ? Si oui ça a un intérêt transitoire mais je pense qu'à terme il est plus rentable de remplacer ces modèles − et d'utiliser les fonctions internes − plutôt que de développer dans l'approche modèle.

Après tout est du cas par cas, il existe probablement des modèles simples qu'il n'est pas pressé de remplacer.

Cordialement, Hexasoft (discuter) 15 mars 2013 à 18:02 (CET)

Pour revenir sur ces fonctions de base, en voici quelques unes qui pourraient être utiles (pour éviter de réinventer la roue à chaque fois) :

• suppression des espaces de tous les paramètres (trim)
• création d'une catégorie (en donnant simplement le couple nom + clé de tri)
• création d'un tableau (entête, ligne et fin)
• mise en majuscules ou minuscules

J'utilise ces choses-là assez souvent sur le Wiktionnaire : n'hésitez pas à vous servir (ou créer un module pour ça) si vous pensez en avoir besoin. — Dakdada (discuter) 1 juillet 2013 à 15:43 (CEST)

Note : trim existe en fonction directe : mw.text.trim(s). Il semble donc inutile d'en faire une fonction outil.

Une suggestion sur le contenu de wikt:Module:bases : sans être certain à 100% je pense qu'appeler mw.language.new('fr') doit avoir un coût. Utiliser mw.getContentLanguage() doit être plus léger (car certainement caché pour chaque wiki), mais bien sûr ne fonctionne identiquement que sur un wiki "français". Sinon comme tu stockes le résultat dans une variable globale locale tu gagnerais sans doute à remplacer locale = mw.language.new('fr') par locale = locale or mw.getContentLanguage() (ou locale = locale or mw.language.new('fr')) ce qui permet de n'appeler qu'une seule fois la création de l'objet language (gain si le module appelant utilise plusieurs fonctions de ce module, surcoût négligeable sinon).

Cordialement, Hexasoft (discuter) 1 juillet 2013 à 16:33 (CEST)

La fonction mw.text.trim(s) ne marche que sur une seule chaîne : la fonction trim_parametres() le fait sur toutes les valeurs d'une liste de paramètres : local args = b.trim_parametres(frame.args).

Sinon pour l'histoire de locale : apparemment mw.getContentLanguage() récupère le code du site puis créé et renvoie un objet avec mw.language.new() (source). Écrire directement fr fait donc gagner une étape. Le seul intérêt d'utiliser mw.getContentLanguage() serait si on veut partager le code avec d'autres wikis dans d'autres langues.

Enfin, oui stocker la locale dans le module pourrait être utile, dans les cas où un modèle invoquerait les fonctions de majuscule/minuscule plusieurs fois. — Dakdada (discuter) 1 juillet 2013 à 17:07 (CEST)

Ah, je n'avais pas vu le détail de trim_parametres(). Je me demande s'il est possible de surcharger la méta-méthode d'accès à args pour y inclure l'appel à trim. Note qu'il n'est pas nécessaire de trimer les paramètres nommés, mais je ne suis pas sûr qu'il soit plus économique de n'appliquer trim que s'il le faut avec le coût d'un test en plus.

Ok pour le getContent. Il m'avait semblé lire quelque part que c'était caché, j'ai dû me tromper. Cordialement, Hexasoft (discuter) 1 juillet 2013 à 17:30 (CEST)

J'ai quelques propositions à partir de Module:Auteur :

• isIn(word, list) verifer si un mot est dans une phrase, une liste d'options ou une table.
• wordstotable(txt, opt) convertit un texte en table de mots.

Et à partir de Module:ControlArgs :

• isDef(x) pour vérifier qu'une variable est définie quand elle peut provenir de modules où les valeurs par défaut sont diverses.
• p.catGen(catName, catText, c) -- générer une catégorie, et l'accumuler dans une table. Le paramètre "c=:" permet de visualiser la catégorie dans les pages de documentations, au lieu de catégoriser vraiment.
• p.categ_lister(sep) -- generer les categories à la fin d'un des exemples d'une documentation.
• p.ta(txt, val) -- met en forme un argument et sa valeur dans une documentation
• p.Boite_Deroulante(titre, contenu, alignT) mais qui ne fait qu'appeler un modèle.
• p.doctable_args(table, tablename, opt) et p.doctable_recursive pour lister une table et ses sous tables, leurs variables et fonctions, avec leurs nombres et leurs types, et limitable en nombre de niveaux ou d'éléments.
• p.error_color(t), p.message_color(t), p.wikidata_color(t) des styles usuels centralisés.

Et à partir de Module:MathRoman :

• p.roman2int(rm, err) et p.int2roman(i, err) pour convertir un nombre décimal en romain et retour, avec des erreurs très détaillées. Rical (d) 2 juillet 2013 à 19:28 (CEST)

Oui, je n'avais pas précisé. J'ai des fonctions "ajoute_cat()" et "ajoute_erreur()" qui ajoute une catégorie et une catégorie d'erreur (selon le cas). Ce sont des tables qui sont insérées en tant que catégories (+ clé) ou en tant que sous-boîte selon l'espace d'édition (cat dans encyclo et boîte dédiée en dehors). Pour les erreurs j'ajoute les catégories (si espace encyclo) ou une liste dans une boîte dédiée sinon. L'idée est de présenter les erreurs éventuelles en tant que catégorie dans l'espace encyclo et en tant que liste détaillée ailleurs.

D'une manière générale comme les catégories sont "sensibles" (à savoir que selon où on les insert ça ne fait pas la même chose) je préfère dans mes modules gérer une table cat+clé durant la génération, et selon l'espace traiter en inline ou en box dédiée.

Cordialement, Hexasoft (discuter) 2 juillet 2013 à 20:59 (CEST)

Demande de réécriture des modèles de tableau pour monuments historiques

Bonjour, les modèles {{En-tête de tableau MH}} et {{Ligne de tableau MH}} (ainsi que d'autres qui en dérivent) sont très consommateurs de ressources obligeant à scinder en plusieurs pages les listes de monuments historiques. Serait-il possible de les réécrire en Lua pour ne plus dépendre de cette limitation technique ? Merci par avance. — Ayack ^♫♪ 15 mars 2013 à 18:14 (CET)

Pour l'entete je ne pense pas qu'on y gagnerait. Pour le second modèle je pense qu'on pourra faire quelque chose. On y gagnera en lisibilité du code c'est certain après je ne sais pas si ce sera moins consommateur en ressource. A voir donc. --pixeltoo (discuter) 15 mars 2013 à 18:35 (CET)

L'entête gagnerait à être réécrite ne serait-ce que pour être lisible :) Côté performance, Scribunto gagne dès qu'il y a ne serait-ce qu'un #if dans le modèle. — Dakdada (discuter) 15 mars 2013 à 18:55 (CET)

Protection

Je viens de remarquer que les modules ne sont pas protégés par défaut (i.e. une IP peut les modifier). Étant donné que certains sont appelés à être très utilisés, il serait plus sage d’au moins protéger les très-utilisés contre les IPs. Qu’en dites-vous ?

Et à ce propos, je n’ai pas trouvé de compteur du nombre d’appels direct puis de second, troisième,… niveau pour voir le taux d’utilisation des modèles/modules, est-ce qu’il y a une page MediaWiki ou un outil toolserver qui fait ça ? (en gros qui compte le nombre d’items sur Spécial:Pages liées/Module:Math et qui ordonne en fonction du niveau d’appel) ~ Seb35 [^_^] 15 mars 2013 à 19:15 (CET)

Modules auto-documentés

Hello,
j'ai fait un module Module:Documentation module, qui a une fonction "doc" qui s'occupe de générer la mise en forme autour de la doc.
Ce module gère 3 cas :

• affiché dans un module : affiche des infos proches de ce qu'on a pour les modèles (entête, lien vers la doc par exemple)
• affiché depuis la page de doc : affiche des infos proches de ce qu'on a pour les docs de modèles (idem)
• affiché depuis un module qui n'a pas de doc : affiche un texte explicatif + lien pour créer la doc (avec preload)

Et j'ai testé un truc : on peut appeler des modules depuis les messages système qui affichent l'absence de page de doc ou le fait qu'on soit dans une page de doc, ou encore pour transluction de la page de doc. J'ai donc modifié les messages système. Voir : Spécial:Messages système&prefix=Scribunto-doc.
Vous pouvez voir que dans les 3 cas (transluction de la doc, annonce qu'on est dans la doc et annonce de l'absence de doc) j'appelle Module:Documentation module:doc(). Et ça marche \o/

Voici 3 exemples :

• module sans page de doc : Module:Math
• module avec une page de doc : Module:Documentation module
• page de doc d'un module : Module:Documentation module/Documentation

Donc en gros : on n'a plus à s'occuper d'inclure quoi que ce soit de relatif à la doc des modules, ça se fait tout seul, il n'y a rien d'autre à faire que de s'occuper de remplir la doc .

Cordialement, Hexasoft (discuter) 15 mars 2013 à 21:27 (CET)

Bien évidemment j'invite tout le monde (pas en même temps, hein) à améliorer la typo, les infos ou la mise en forme des différents éléments affichés. Hexasoft (discuter) 15 mars 2013 à 21:30 (CET)

J'ai aussi créé Modèle:Documentation/PreloadModule, contenu inséré lorsqu'on suit le lien proposé pour créer la documentation d'un module n'en ayant pas encore.

Là encore n'hésitez-pas à modifier le contenu proposé, sachant que j'ai mis dedans le style de formatage des documentations que j'ai proposé, sans que ce soit forcément le plus adapté. Hexasoft (discuter) 16 mars 2013 à 18:40 (CET)

J'ai tenté d'améliorer le module de documentation. À voir si c'est mieux. ~Hlm Z. [@] 29 mars 2013 à 22:54 (CET)

Je constate que la documentation ne s'affiche pas correctement dans Module:Documentation. Son nom peut-être ? ~Hlm Z. [@] 8 juin 2013 à 22:32 (CEST)

Ah oui ! Amusant . J'ai dupliqué le module (sous le nom de Documentation2) ainsi que sa page de doc (Module:Documentation2/Documentation) et la doc apparaît normalment. Il semble donc que ce soit bien un bug lié au nom du module qui correspond à la sous-page.

Je vais ouvrir un bug. Cordialement, Hexasoft (discuter) 8 juin 2013 à 22:39 (CEST)

En fait le bug était dans Module:Documentation module ! Il y a un test qui regarde si title.subpageText est égal à "Documentation". Sauf que, semble-t-il, subpageText vaut title.text lorsque ce n'est pas une sous-page, ce qui déclenchait le mauvais comportement. J'ai corrigé en ajoutant comme test que subpageText ~= text. C'est un correctif incomplet (ça risque de ne pas marcher pour un module qui serait lui-même une sous-page s'appelant Documentation… Gardons le cas en mémoire si d'aventure… Hexasoft (discuter) 9 juin 2013 à 16:50 (CEST)

{{Infobox V3}}

Est il possible avec Lua de créer une brique de carte avec géolocatisation et accessible qui ne soit pas du bricolage comme les modèles actuelles ? Et éventuellement de faire un test de conversion pour chaque brique déjà existante. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 15 mars 2013 à 22:57 (CET)

Il n'est pas possible de faire un module géolocalisation qui respecte la philosophie des Infobox V3 car le positionnement en CSS pour donner du sens n'est pas considéré comme "accessible". Ceci-dit j'ai essayé de préparer un modèle qui s'intègre dans les deux (voir Utilisateur:Zebulon84/Mod8). Il faut juste que je le finalise, notamment en refaisant la programmation en lua. — Zebulon84 (d) 16 mars 2013 à 08:32 (CET)

Je suis d'accord : Lua n'apporte pas de résultats nouveaux, il permet juste d'arriver à ces résultats de façon plus souple et plus clair.

Par contre dans Module:Taxobox-briques on trouve une partie des briques de base V3 (enfin, pas avec toutes les options). J'avais externalisé ça car il me semble à terme qu'il faudrait une module Infobox-V2 et Infobox-V3 contenant les différentes briques, afin de permettre de factoriser les éléments de construction dans les modules d'infobox. Hexasoft (discuter) 16 mars 2013 à 09:48 (CET)

Infobox

J’ai commencé à écrire un module pour les infobox v3. Il est conçus pour être utilisé comme une bibliothèque par d'autres modules. Voici un exemple de ce que je voudrais lui faire faire :

local Infobox = require 'Module:Infobox'
local infobox = Infobox.new()
infobox:addTitle( {
   text = 'Infobox'
} )
infobox:openTable()
--.....
infobox:closeTable()
return infobox --Infobox est converti automatiquement en chaîne de caractère par lua grâce au __tostring de la metatable

Que pensez vous de cette manière de procéder ? Des remarques, des suggestions ? Je suis assez occupé en ce moment donc, si quelqu'un est intéressé par ce travail, qu'il n'existe pas à le reprendre. Tpt (d) 16 mars 2013 à 12:32 (CET)

Ça me paraît bien (encore que : pourquoi des méthodes ?).

Si ça peut t'aider une partie des briques de base (simplifiées) sont dans Module:Taxobox-briques, justement séparées du reste pour le jour où ce genre de module existera Cordialement, Hexasoft (discuter) 16 mars 2013 à 13:12 (CET)

J'utilise des méthodes afin d'avoir quelque chose de plus "naturel" : on manipule une infobox comme un type de donnée et permettre de faire des chose comme définir via le constructeur une feuille de style qui sera appliqué pour chaque entête de section sans avoir à passer la feuille de style en paramètre à chaque création d'entête. Tpt (d) 16 mars 2013 à 14:16 (CET)

Modèles gourmands

J'ai enfin pu dresser une liste des modèles gourmands en fonction parseur (via le script parsercount de pywikipedia; que j'ai bidouiller un peu salement pour exploiter les dumps xml). Vous pourrez trouver la liste ici : Utilisateur:Darkdadaah/ParserFunctionCount. Il y a presque 200 pages avec plus de 100 fonctions, certaines dépassent 1000 et le maximum est 6725. — Dakdada (discuter) 16 mars 2013 à 12:59 (CET)

Puré : j'ai jeté un œil à {{Générateur de code de courbe d'affluence/Code Timeline}}. Quelqu'un sait ce que ça fait (je veux dire, dans le dedans du code, hein) ? Hexasoft (discuter) 16 mars 2013 à 13:16 (CET)

Je crois que c'est un modèle qui génère du code pour être utilisé par l'extension EasyTimeline. En d'autres termes, c'est un modèle utilitaire qui n'est pas utilisé dans les articles (ouf). Pareil pour {{Générateur de code de courbe démographique/Code Timeline}}. — Dakdada (discuter) 16 mars 2013 à 13:27 (CET)

On pourrait avoir un compte des modèles et pages qui utilisent des parser gourmands (comme ifexist)? Il me semble que c'est ça entre qui est responsable des longtemps de chargement pour certaines pages. Kyro ^{me parler} le 16 mars 2013 à 14:03 (CET)

Difficile d'estimer ça avec les modèles imbriqués. — Dakdada (discuter) 16 mars 2013 à 14:21 (CET)

Oui, difficile. Il y a quelque part (je l'ai trouvé une fois mais je ne sais plus où) une liste des pages utilisant le plus de "expensive functions" (typiquement ifexist). En y regardant de plus près difficile d'y apporter un mieux : toutes les premières pages sont des énumérations qui utilisent le modèle {{Date}} (mise en forme de la date). J'ai fait un module faisant la même chose mais quoi qu'il en soit pour respecter le fonctionnement du modèle (ce qui peut se discuter, toutefois) même en Lua il faut faire des ifexist (leur équivalent avec mw.title) qui sont aussi comptabilisés en "expensive functions".

Donc au final on échange un appel coûteux par un autre mais ces pages resteront structuellement coûteuses. Hexasoft (discuter) 16 mars 2013 à 14:46 (CET)

Sous-pages de documentation changées

Hello,
j'ai appliqué le changement de nom de sous-pages de documentation : c'est désormais "$1/Documentation" au lieu de "$1/doc".
Au passage j'ai déplacé les pages de docs de "doc" vers "Documentation". J'ai dû le faire par copier-coller (désolé pour les historiques) car il n'est pas possible de renommer d'un espace module vers un espace non module (ou inversement). Or quoi qu'on fasse soit "/doc" soit "/Documentation" est l'un et l'autre non.
J'ai aussi modifié le module Module:Documentation module pour tenir compte du nouveau nom. Heureusement il n'y a pas de raison que ça change, maintenant.

Cordialement, Hexasoft (discuter) 18 mars 2013 à 10:06 (CET)

Si c'est pas possible de renommer, alors c'est un bug auquel il faudrait remédier :/ Il faut le signaler (où ?). — Dakdada (discuter) 18 mars 2013 à 10:49 (CET)

Note : tu peux renommer un module pour un autre nom de module. Par contre tu ne peux pas renommer (par exemple) "Module:Test" en "User:Toto/module test" ou inversement, visiblement parce que les modules sont "traités" à l'enregistrment, chose court-circuitée lors d'un renommage.

La question est : a-t-on besoin de pouvoir déplacer un module vers une zone non module ou inversement ? Hexasoft (discuter) 18 mars 2013 à 10:51 (CET)

C'est le fait de ne pas pouvoir déplacer les docs qui me posait problème. On peut contourner le problème en renommant temporairement MediaWiki:Scribunto-doc-page-name en un autre nom, le temps de déplacer les pages en tant que wikitext (c'est ce que je viens de faire sur le Wiktionnaire). — Dakdada (discuter) 18 mars 2013 à 11:01 (CET)

Oui. C'est pourquoi je "pressais" un peu pour décider du nom à utiliser afin d'éviter d'avoir trop de pages à renommer. Là il devait y avoir 4 ou 5 pages de doc, dont au moins une contenant uniquement du test (module test) et une autre initialisée mais vide. La gène était légère, et ne devrait plus se reproduire . Hexasoft (discuter) 18 mars 2013 à 11:10 (CET)

D'ailleurs, n'y aurait-il pas moyen d'avoir une page "bac à sable" dédiée liée par défaut à un module (genre : Module:Nom/Banc d'essai) ? Je trouve que ce n'est pas pratique de chercher la page de test appropriée et de recopier son nom à chaque fois. — Dakdada (discuter) 18 mars 2013 à 11:18 (CET)

Tu veux dire une sous-page d'un module qui − plus ou moins automatiquement − permettrait de tester ce module ? Pas que je sache. En effet à part "Module:Nom/Documentation" toute page et sous-page de l'espace Module: est traitée comme un module, donc aussi (dans ton exemple) "Module:Nom/Banc d'essai".

Les seules accessible simplement je pense sont la page de discussion (et ses éventuelles sous-pages) et la page de documentation. Note : d'ailleurs une sous-page de la page de documentation est aussi un module, pas une page de doc. On ne peut donc pas faire "Module:Nom/Documentation/bac à sable".

On peut soit considérer que (par ex.) "Discussion module:Nom/bac à sable" est réservé pour ce genre d'usage ou bien qu'une section dédiée (masquée / enroulée par défaut) peut servir pour ça. Ceci dit je ne vois pas comment on pourrait faire (facilement) pour par exemple ajouter un bouton du style "Pré-visualiser la page de banc d'essai avec les modifications en cours" ce qui serait assez pratique je pense.

Il est peut-être possible de demander un bouton spécial à ajouter dans son propre JS. Hexasoft (discuter) 18 mars 2013 à 11:46 (CET)

Note sur la performance de certaines opérations

Hello,
en mettant à jour la traduction du Reference Manual de Lua j'ai trouvé des détails sur les performances de la concaténation "..". Il est dit que comme Lua crée une nouvelle chaîne à chaque concaténation des opérations nombreuses de type "t = t .. "blabla" ; t = t .. "blabla" ; … peuvent être coûteuse puisqu'à chaque fois t est dupliqué (avec l'ajout) et affecté dans t, créant plein de références mortes de plus en plus grosse et donc consommant mémoire et temps.
Si le nombre d'opération est significatif ils indiquent : « it may be faster to use string.format() or to insert all the strings into a sequence and use table.concat() at the end »
À l'occasion il faudra que je corrige certains de mes modules Hexasoft (discuter) 18 mars 2013 à 12:12 (CET)

J'ai tendance à découper les éléments et à les ajouter un à un de cette manière-là. Dans ce cas je pense que je vais préférer table.concat(). Merci de l'indication. — Dakdada (discuter) 18 mars 2013 à 12:29 (CET)

J'avais effectivement oublié ce point. C'est ballot car pour former du wikitexte on a souvent besoin de concaténer de multiples chaines, et c'est moins parlant de tout mettre dans une table. Ceci dit si c'est plus performant il va aussi falloir que je revoie mes modules. — Zebulon84 (d) 18 mars 2013 à 16:18 (CET)

Ceci dit je suppose qu c'est surtout problématique sur des boucles importantes, pas lorsque on a juste

a = 'xxx' .. b .. 'yyy' .. c .. 'zzz'

— Zebulon84 (d) 18 mars 2013 à 16:38 (CET)

C'est problématique quand on fait genre :

local texte = ''
for mot in dictionnaire do
  motdif = motdification(mot)
  texte = texte .. ' ' .. motdif
end

Je pense. — Dakdada (discuter) 18 mars 2013 à 17:14 (CET)

Il n'y a pas de précision (juste « If many strings need concatenating (…) »). Je pense qu'il ne faut pas se casser la tête pour concaténer quelques chaînes, et je suis d'accord que ça semble moins parlant de passer par une table. Par contre ça apporte sans doute sur des cas comme indiqué par Darkdada où il y a des boucles de construction. Hexasoft (discuter) 18 mars 2013 à 17:51 (CET)

Classement alphabético-numéique

Bonjour, désolé de vous déranger, ça n'est pas pour Wikipédia, mais on peut toujours essayer. Je suis en train de faire un module sur Commons (Louvre rooms), et j'essaie de classer les valeurs d'une table en fonction de leur clé. Le problème est que certaines sont des nombres (traité comme des chaînes de caractère), et d'autres sont des lettres. Je voudrais me retrouver avec l'ordre A, B, C, 1, 2, 3, mais je n'arrive pas à faire quelque chose qui marche à la fois pour les lettres et pour les chiffres. --Zolo (d) 22 mars 2013 à 10:08 (CET)

Je travaille bien sur le Wiktionnaire moi ^^. La fonction table.sort accepte en paramètre supplémentaire une fonction de tri, donc tu peux créer toi-même une fonction qui trierait selon tes propres règles (je n'ai pas encore essayé de faire ça). — Dakdada (discuter) 22 mars 2013 à 11:34 (CET)

Merci, j'ai vu ça et ça marche, mais en fait ce que je n'arrive pas à faire c'est la fonction pour classer dans cet ordre : 1, 2, 11, A, C. --Zolo (d) 22 mars 2013 à 12:40 (CET)

Oups, je viens de découvrir qu'en fait, dans mon cas, c'est plutôt plus pertinent de garder l'odre initial. Je serais toujours intéresé par la solution, mais en fait je n'en ai pas vraiment besoin :)--Zolo (d) 22 mars 2013 à 12:50 (CET)

Attention : il me semble bien que le tri, et la fonction de tri qu'on peut fournir, travaille sur les valeurs de la table et non sur les clés de la table (voir l'excellente traduction de la doc ici ).

Si tu veux trier sur les clés je n'ai pas trouvé de solution directe. La solution indirecte consiste à :

parcourir les clés/valeurs (pairs()) "cle"+"val" de la table et remplir une autre table avec "cle" comme valeur (table.insert(table, cle)). Ensuite tu fais le tri sur cette table, et au final tu parcours (ipairs() ou for numérique) ta table triée en affichant table_initiale[table[i]]. C'est plus lourd, je sais pas s'il existe une autre approche plus simple. Hexasoft (discuter) 22 mars 2013 à 13:48 (CET)

Merci. Oui en fait, je me suis trompé, j'avais déjà transformé la table, donc c'était sur les valeurs que je travaillais, et donc le j'arrivais à faire une fonction qui classe. Mais bêtement, je n'arrive pas à classer dans l'odre "1, 2, 11, A, Abis, C". D'après ce que j'ai compris, le classment par défaut, c'est espace blanc < chiffre < lettre. Donc, par défaut on a 1 < 11 < 2. Je pensais règler ça avec quelque chose comme :

function sort_rooms(a, b) -- should return true if a < b
    a = string.upper(a)
    b = string.upper(b)
 
    if #a < #b then 
        shortest = a
        result = true
    else 
        shortest = b
        result = false
    end

    for c in 1,#shortest do 
        if a[c] < b[c] then 
            result = true
            break end
        end
    end
    return result
end 

Ce genrMais je ne comprends pas comment fonctionne les "break" et les "end", j'ai beau rajouter plein de "end" il me dit toujours qu'il mangue un end "near break"...--Zolo (d) 22 mars 2013 à 14:36 (CET)

Plusieurs remarques :

• en Lua les chaînes ne sont pas des tableaux. On ne peut pas faire a[c] si a est string. Il faut utiliser quelque chose comme mw.ustring.codepoint() pour extraire un caractère (en UTF8)
• si tu dois manipuler des chaînes UTF-8 penser à utiliser mw.ustring et pas string, sinon par exemple string.upper() va retourner des choses fausses dans certains cas
• break qui la boucle dans laquelle on se trouve. Il doit − comme return obligatoirement se trouver en fin de bloc (avant un end)
• ici le end après le break est en trop
• il est inutile de faire un break pour sortir de la boucle et retourner result, il suffit de faire un return true à la place.

Cordialement, Hexasoft (discuter) 22 mars 2013 à 14:45 (CET)

Merci beaucoup, tout ça me sera sans doute très utile. --Zolo (d) 22 mars 2013 à 15:31 (CET)

Si tu veux classer 1, 2, 11 en même temps que ABC, tu peux séparer nombres et chiffres ainsi :

function sort_rooms(a, b) -- should return true if a < b and 1 < 2 < 11 < A < Z
    a = string.upper(a)
    b = string.upper(b)
    na = tonumber(a) -- il y a aussi un tostring(na) dans l’autre sens
    nb = tonumber(b)
    if na == nil then 
        -- ici a est un string, et tu tiens compte aussi de nb pour classer a et b
    else 
        -- ici a est un nombre, et tu tiens compte aussi de nb pour classer a et b
    end
...

--Rical (d) 22 mars 2013 à 17:55 (CET)

Rical a tout à fait raison. J'ajouterai par rapport à ton bout de code en haut que Lua sait comparer des chaînes entre elles. Donc si tu es dans le cas a et b sont des chaînes et pas des nombres tu peux faire a < b. Après il faut voir si tu veux traiter "123A" comme une chaîne ou comme un nombre . Hexasoft (discuter) 22 mars 2013 à 18:08 (CET)

Ah d'accord, merci, je n'avais pas compris que tonumber(lettres) donnait "nil", je croyais que ça donnait une erreur. Ca simplifie effectivement les choses, même si dans mon cas il faudrait encore bricoler pour obtenir les salles "12 bis". --Zolo (d) 22 mars 2013 à 19:58 (CET)