Discussion Projet:Scribunto/Archive 2

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

Repérer les mots semblables

Merci Hexasoft pour la distance de Levenshtein qui mesure la similarité entre les mots. Tu t'en sers pour corriger les noms dans les classifications, comme dans le Module:Classification ReptileDB, et moi je vais m'en servir pour aider les utilisateurs à bien nommer les paramètres de modèles, dans Module:Multilingual_Arguments. --Rical (d) 23 mars 2013 à 11:59 (CET)

Héhé. Note : je n'avais pas fait de publicité sur cette fonction car j'ai fait ça "vite et mal", en ce sens que je n'ai pas cherché d'algo optimisé traiter ce cas, la fonction est donc sans doute sous-optimale.

Pour info j'ai proposé que cette fonction soit implémentée dans mw.text (module à venir) où elle a sa place, et où elle pourrait éventuellement être codée dans un langage plus adapté (parcourir 1 par 1 les caractères d'une chaîne n'est pas le point fort de Lua en l'absence d'accès direct). Hexasoft (discuter) 23 mars 2013 à 12:03 (CET)

Utiliser Wikidata

Parmi des messages dans http://test2.wiki.x.io j'ai vu ceci :

• We've deployed new code here. This includes replacement of the search box. I hope you like this better than the previous one :)

http://test2.wiki.x.io now also has the ability to include data from Wikidata. It'd be awesome if you'd give it a try to make sure there are no major issues before we roll this out on the first few Wikipedias on Wednesday. There are two ways to include data:

• The first one is by adding a parser function like to the Wikipedia article. This will then get the value that is associated with property p123 on the connected Wikidata item. We're working on making it possible to use the property's label (instead of p123 in this example) and more. See Inclusion syntax for that.
• The second one is via Lua and supposed to be used for more complicated things that can't be done with the parser function. The documentation for that is here.

--Lydia Pintscher (WMDE) (talk) 19:07, 25 March 2013 (UTC) HenkvD (talk)‎2013-03-26T20:10:03

• Je n'ai pas essayé ce Wikidata pour Lua. (et il faut peut-être un temps de déploiement ici ?) --Rical (d) 26 mars 2013 à 23:10 (CET)

Palette de nouvelle génération et introspection

Depuis le 26 mars, les « navbox » du Wikipédia anglophone ont migré vers Lua. L'impact est assez colossale puisque ce sont pas moins deux millions de pages concernées, ce qui n'est pas rien... Il reste quelque bug à corriger mais le déploiement c'est plutôt bien dérouler.

Je propose donc de créer une nouvelle génération de palette afin de répondre aux problèmes d'accessibilité actuels tout en gardant l'aspect esthétique des anciennes palettes. Pour cela, on va donc devoir repenser tout le code HTML actuel. Il existe déjà quelque approche intéressante (ébauche de Lgd, réflexion de Reptilien).

Vos idées sont les bienvenues. Cordialement, ~Hlm Z. [@] 30 mars 2013 à 00:08 (CET)

Si on a des « thèmes de travail » il est peut-être possible de créer des sous-pages dédiées (Projet:Scribunto/Projets/Navbox ici par exemple) pour coordonner les choses, non ?

J'aurai tendance à dire qu'ici le travail n'est clairement pas coté code Lua : c'est assez simple à générer. Le boulot est du coté du code (propre) HTML à générer au final et aussi la façon d'agencer les paramètres.

Note : j'ai indiqué dans Discussion Projet:Palette la création de Module:Liste éléments qui remplace avantageusement le code assez peu digeste de {{liste éléments}} et ses sous-modèles. Cordialement, Hexasoft (discuter) 1 avril 2013 à 18:25 (CEST)

Module:Lambdacolor

Bonjour. Le module (que je viens de créer) fonctionne correctement mais il y a un problème d'affichage : il manque les 6.5 premières lignes de code (qui suivent le commentaire et qui apparaissent bien quand on édite le code et qui s'exécutent également sans problème). C'est probablement dû à la longueur des lignes contenant les tableaux de valeurs RGB. Elles font un peu plus de 500 caractères (sans grand intérêt; je laisse tel quel). Il semble y avoir une limite dans la longueur des lignes (ce qui est un peu étonnant à notre époque) -- Xofc ^{[me contacter]} 1 avril 2013 à 12:38 (CEST)

C'est visiblement effectivement un bug d'affichage du "formateur" de texte. Il faudrait ouvrir un bugreport. Par contre je ne vois pas bien ce qui le déclenche. J'ai tenté de couper les lignes pour voir si ça changeait l'affichage, sans effet. J'ai aussi tenté de reformater certaines parties (idem). En dernier test j'ai inséré un commentaire entre les tables et la fonction : au moins ça permet d'avoir le contenu de la fonction affiché correctement (j'ai l'impression que le commentaire "réinitialise" l'afficheur dans un état correct).

C'est bien le "syntaxhighlight lang=lua" qui déconne. Ci-dessous une copie de ton code dans une balise syntaxhighlight, et l'effet est le même.

Cordialement, Hexasoft (discuter) 1 avril 2013 à 13:35 (CEST)

Note : j'ai créé le bugreport : 46753. N'hésite-pas à indiquer tes observations dessus. Hexasoft (discuter) 1 avril 2013 à 13:45 (CEST)

Bug dupliqué (je n'avais pas cherché dans la bonne catégorie). Ils travaillent dessus. Hexasoft (discuter) 1 avril 2013 à 17:19 (CEST)

-- usage {{#invoque:lambdacolor|lambdacolor|longueur_d_onde_en_nanometres}}
local c = {}
c.reds = {0,0,0,0,0,0,36,36,31,25,51,44,36,31,44,54,57,76,85,82,97,107,110,112,110,108,110,112,111,108,106,103,103,97,92,87,89,84,78,67,51,31,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,57,89,115,138,157,171,187,199,213,223,234,243,253,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,247,243,232,224,215,207,201,191,181,175,169,157,151,143,136,128,118,110,100,98,98,87,74,85,70,70,51,51,51,51,48,48,48,48,48,48,48}
c.greens = {18,18,18,18,25,25,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,25,60,80,97,112,127,141,157,163,177,182,187,196,205,214,223,227,235,246,253,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,250,246,241,236,230,225,218,206,192,179,168,156,145,135,124,112,106,94,85,72,65,51,44,18,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
c.blues = {31,31,31,31,48,48,54,62,67,72,82,89,97,106,120,135,150,168,188,205,226,248,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,250,245,237,230,225,221,218,216,213,212,213,212,207,202,196,191,186,181,178,173,170,166,164,160,156,151,148,142,139,130,126,118,106,92,70,36,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,18,40,44,54,60,65,65,67,67,76,72,74,74,78,70,70,67,62,67,62,57,57,60,54,48,48,48,40,40,31,25,36,36,25,0,36,25,25,0,0,0,0,25,25,25,25,25,25,25}
function c.lambdacolor(frame)
    local lambda = tonumber(frame.args[1])
    return lambda
end

Merci! -- Xofc ^{[me contacter]} 1 avril 2013 à 18:40 (CEST)

Pour la petite histoire : il semble que ce soit un problème lié à une regex qui traite la mise en valeur des nombres, et sur de très grandes séries elle explose la limite de profondeur de récursion. Hexasoft (discuter) 1 avril 2013 à 18:48 (CEST)

Comme tu as suggéré que les commentaires (--) semblaient remettre un compteur à zéro, j'en ai ajouté un à la fin de chaque longue ligne et l'affichage est maintenant correct. (le bug est 'contourné') -- Xofc ^{[me contacter]} 2 avril 2013 à 14:27 (CEST)

De l'utilisation des "micro-modules"

Hello,
en regardant {{Titre en italique}} je me rends compte d'un problème que j'avais évoqué il y a un certain temps : le code de ce modèle utilise des fonctions élémentaires de Lua (#invoke:String) pour faire un travail qu'il est très facile de faire intégralement en Lua.
On a donc une utilisation de Lua ne servant qu'à créer de nouveaux parser-functions ou extensions, ce qui va un peu à l'encontre du rôle prévu par Lua, à savoir réduire la complexité des modèles (au contraire on se retrouve avec plus de fonctionnalités élémentaires donc de nouveaux modèles et/ou des modèles plus complexes gérant plus de cas).
Dans l'exemple en question le modèle utilise 3 #if, 1 #ifeq, 2 #invoke, plus 3 appels à PAGENAME et 2 appels à NAMESPACE, alors que le code correspondant en Lua est assez simple.

Il ne s'agit pas de pointer ce modèle en particulier, mais je pense qu'il faudra être vigilant sur l'utilisation faite des "micro-modules" (nom que je donne aux modules servant uniquement à fournir une interface aux fonctionnalités de base de Lua). Il me semble qu'il est intéressant d'avoir cela pour des cas d'utilisation unitaires, ou pour tester de nouvelles fonctionnalités, mais qu'il faut éviter à terme leur utilisation significative en lieu et place d'une migration de code vers Lua (ou alors ce serait acter la conservation du fonctionnement pré-Lua, avec juste des fonctionnalités additionnelle sans passer par les extensions mediawiki).

Cordialement, Hexasoft (discuter) 1 avril 2013 à 17:29 (CEST)

Module:InfoboxBuilder

J'ai complété le module Infobox afin d'y ajouter tout les fonctionnalités "de base" (de nombreuses manquent encore) et créé un nouveau module, Module:InfoboxBuilder, qui permet de construire une infobox v3 à partir d'un tableau Lua. Voici un exemple de configuration pour l'{{Infobox Philosophe}} et un exemple de rendu. Le contenu du modèle est réduit à {{#invoke:InfoboxBuilder|build|nom=Philosophe}}. Qu'en pensez-vous ? Des remarques/suggestions ? Je vais me mettre à l'écriture de la documentation. Tpt (d) 1 avril 2013 à 20:35 (CEST)

Ça paraît sympa ! Il est certain qu'une documentation sera nécessaire .

Note : dans certains cas on aura besoin d'utiliser l'interface "bas niveau". Je pense aux taxobox dont le format est libre (non pré-contraint) de par le fait qu'il existe une trop grande variété de cas pour gérer ça facilement dans une structure rigide. J'avais prévu le coup : mon module de taxobox utilise un sous-module "infobox" car dès le départ j'ai séparé au maximum la structuration des infos et le rendu, je devrais donc pouvoir facilement passer à cette version .

Du bon boulot, en tout cas ! Hexasoft (discuter) 1 avril 2013 à 21:27 (CEST)

J'ai fait une doc assez complète pour Module:InfoboxBuilder. Pour les contenus spéciaux, il y a le composant "text" qui permet d'ajouter ce que retourne une fonction prenant en paramètre le frame courant. Pour les taxobox et autres infobox modulaires, il y a l'option isPart qui permet d'utiliser la classe Infobox sans qu'elle n'ajoute la <div> contenant l'infobox. Ce serait bien d'avoir pas mal de retours d'utilisateurs afin d'améliorer la syntaxe de définition des infobox qui semble un peu lourde. Il reste aussi quelques composant à ajouter (les barres de séparation, les tableaux spéciaux, les feuilles de styles...) Tpt (d) 1 avril 2013 à 21:38 (CEST)

Oh, je ne trouve pas ça "un peu lourd". De toute façon la création de nouvelles infobox n'a jamais été à ma connaissance un truc "pour tous" mais nécessitant un minimum de « bouteille » .

Pour l'utilisation "bas niveau" je pensais plutôt à la possibilité d'insérer les éléments un par un, au fur et à mesure. "ouvrir infobox, tel style, largeur…" + "insérer un titre principal, tel titre, tel style…" + "ouvrir une table avec tel titre et tels options" + "insérer une ligne de données" + "fermer la table" + …

Cordialement, Hexasoft (discuter) 1 avril 2013 à 21:50 (CEST)

Dans la continuité des infobox actuels, il ne serait pas préférable d'initialiser « cette table Lua » directement dans le modèle en question ({{Infobox Philosophe}} dans ton exemple) ?

En gros, pour faire simple, on pourrait avoir :

• Un « module:Infobox » avec toutes ses fonctionnalités possibles.
• Un « modèle:Infobox » contenant « {{#invoke:Infobox|infobox}} ».
• Et les infobox habituels (monobloc donc) ; « modèle:Infobox Bidule » par exemple, appelant le modèle infobox avec tous les paramètres nécessaires à initialiser.

Cette implémentation serait àmha la plus simple et la plus évidente. Cordialement, ~Hlm Z. [@] 1 avril 2013 à 21:55 (CEST)

Petite question : avec ce module, quant est-il des infoboites modulaire ? (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 1 avril 2013 à 23:35 (CEST)

@Ju Il y a l'option isPart pour cela (c. f. Module:InfoboxBuilder#Documentation).

@Hexasoft pour le bas niveau, il y a le Module:Infobox avec l'option isPart si on veux faire des infobox "à la main", le type "text" du builder qui permet d'injecter ce que l'on veux et la possibilité d'appeler des fonctions pour les valeurs des différents composants.

@Hlm Z. Il n'est pas possible de mettre la configuration des infobox dans un modèle car on ne peux pas charger via Lua le contenu entier d'une page wiki. On ne peux seulement accéder aux paramètres passés au module lors de son appel et ceux passés aux modèles contenant un appel du module. C'est donc très contraignant. De plus, on se priverais en passant par cette technique de la possibilité d'utiliser facilement du code Lua dans la configuration. Tpt (d) 2 avril 2013 à 21:54 (CEST)

@Tpt : ben en fait si, on peut lire le contenu d'un modèle . En fait de toute page, d'ailleurs, en créant un title sur la page cible et en utilisant la méthode getContent() dessus. Toutefois c'est coûteux, et on obtient le code non traité (raw), il faudrait donc coder un interpréteur pour analyser et utiliser le contenu.

Pour le reste j'ai en projet de ré-écrire proprement Module:Taxobox et ses modules dépendants (je l'ai écrit au début de Scribunto, avant qu'il soit sur fr:, j'avais moins de recul et il manquait pas mal de fonctionnalités comme title et d'autres). J'en profiterai pour éliminer le code spécifique correspondant à ma mini-implémentation des V3 (en fait juste les quelques parties que j'utilise, ce n'était pas mon but de travailler là-dessus). Hexasoft (discuter) 2 avril 2013 à 22:20 (CEST)

Il y a surement des choses qui me dépassent, mais bon... Je ne dis pas que cette implémentation est mauvaise, elle est simplement mal adaptée. Il faut penser à l'utilisateur Lambda, celui qui ne veut pas mettre les mains dans le cambouis, celui qui sait utiliser la syntaxe wiki et qui ne veut pas en savoir plus.

Si j'ai bien compris le principe de ce constructeur : il faut créer une sous-page pour chaque infobox (Module:InfoboxBuilder/Bidule). Or ce n'est pas ce qu'on recherche, on veut initialiser (déclarer plutôt) ces paramètres directement dans le corps du modèle concerné (Modèle:Infobox Bidule) pour éviter de toucher au Lua (la syntaxe wiki est larguement accessible à tous, contrairement à un vrai langage de programmation fonctionnel tel que le Lua script). ~Hlm Z. [@] 3 avril 2013 à 12:54 (CEST)

C'est exact. Toutefois même avec la syntaxe wiki plus accessible est-ce que « l'utilisateur lambda » crée des infobox ? Même créer un nouveau bandeau d'ébauche est chiant !

Notons qu'il existe une autre façon de passer un contenu non module à un module lors de son appel : {{#invoke:monModule|maFonction|{{le contenu de la page à inclure}}}}. Si la description peut être dans un format "indépendant" ça peut être géré comme ça. Hexasoft (discuter) 3 avril 2013 à 13:06 (CEST)

┌─────────────────────────────────────────────────┘
En travaillant sur WP à rédiger des articles puis à créé ou modifier des modèle de plus en plus complexe, j'ai appris à utiliser la syntaxe wiki et à être suffisamment compétent pour être en mesure de faire des choses. Je pense donc que toute personne est en capacité d'apprendre à créer des modèles en wiki à partir de son « travail ordinaire » s'il en a le désir et qu'il se fait un peu curieux.

Pour Lua en revanche, il s'agit d'apprendre un nouveau langage spécifiquement pour cela et qui ne peut être utilisé ailleurs sur l'encyclopédie. Ce n'est pas quelque chose qu'on peut apprendre sur le tas à force d'expérience personnelle mais bien quelque chose qu'il faut apprendre préalablement.

Donc non monsieur Toutlemonde ne fait pas de modèle en wiki mais a la possibilité de le faire ou d'apprendre à le faire sur la base de son expérience de contributeur (formation continu) contrairement au "modèle" en lua (formation initiale). (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 3 avril 2013 à 14:39 (CEST)

Justement, dans ma proposition d'implémentation, on ne demande pas au contributeur qui créé une nouvelle d'apprendre Lua en entier mais juste la syntaxe de déclaration des tableaux + faire des appels de fonctions (si on implémente l'idée d'Hexasoft proposée plus bas) qui est àmha bien moins complexe que celle des parser functions. La capacité d'utiliser des fonction écrites en Lua est juste là pour les fonctions "avancés". Je n'arrive à imaginer une syntaxe qui serait en même temps plus simple, garantissant des performances relativement convenables et une assez bonne souplesse. Vous auriez une idée ? Tpt (d) 4 avril 2013 à 21:39 (CEST)

Une forme du style classique :

{{Infobox V3/Début|text={{{nom|}}}}}
{{Infobox V3/Tableau début|class=hidden}}
{{Infobox V3/Tableau Ligne mixte|Entête1|{{{donnée1|}}}}}
{{Infobox V3/Tableau Ligne mixte|Entête2|{{{donnée2|{{{contenu2|}}}}}}}}
{{Infobox V3/Tableau fin}}
{{Infobox V3/Fin}}

En une structure monobloc (un peu à la manière d'une palette de navigation) du style :

{{Infobox
| titre = nom

| entête1 = Entête1
| donnée1 = donnée1

| entête2 = Entête2
| donnée2 = donnée2
| donnée2 = contenu2 <!-- ou alors « |donnée2=donnée2, contenu2 » mais très couteux -->
}}

n'est pas réalisable ? ~Hlm Z. [@] 4 avril 2013 à 23:12 (CEST)

Après on peut aussi faire un parser. C'est ce qu'on trouve dans Module:Taxobox pour gérer un format "libre". Hexasoft (discuter) 4 avril 2013 à 23:19 (CEST)

je rebondis sur le sujet

Je pense qu'il faut faire attention à l'utilisation des module Lua. Ceux-ci doivent permettre avant tout:

1. de réaliser des opérations qu'on ne pouvait pas avant faire en wiki : je pense à manipulation de chaines ou appel à des fonctions mathématiques
2. d'optimiser le temps d'exécution de certains modules : c'est-à-dire de packager les usines à gaz ou il y avait plein d'imbrication.

Si je prend le cas de l'infobox, je serais favorable à la réécriture de {{Infobox/Succession}} et compagnie, mais beaucoup moins à {{Infobox Philosophe}}. Le Lua touche vraiment une infime partie des contributeurs (moi-même ne maitrisant pas encore le langage) et on risque d'avoir une communauté de maintenance trop réduite. Tout est luaisable mais on ne doit pas tout ré-écrire (sinon, on lance luapedia). Je crois que dans la documentation ou quelque part ailleurs, il faudrait justifier l'utilisation des modules Lua -- Xfigpower (pssst) 2 avril 2013 à 09:55 (CEST)

À mon sens il y a deux choses différentes, comme tu l'indiques :

• les fonctionnalités nouvelles
• l'efficacité

Or il me semble que faire des modèles qui exploitent juste des fonctionnalités nouvelles (à travers ce que j'appelle des « micro-modules », des modules fournissant uniquement un accès à des fonctions de base de Lua) ce n'est rien d'autre que de considérer Lua comme une super-extension, amenant donc l'ajout de multiples appels qui vont fleurir dans les modèles, ce qui est antinomique avec le deuxième point, l'efficacité.

Un exemple simple que j'ai indiqué plus haut : {{Titre en italique}}. Son contenu est relativement simple (pour quelqu'un ayant l'habitude des modèles). On se retrouve quand même avec 3 #if, 1 #ifeq, 3 appels à PAGENAME, 2 à NAMESPACE. Et bien qu'il soit simple − et bien que j'ai l'habitude des modèles − je trouve qu'il faut quand même bien y regarder pour être certain d'avoir saisi les subtilités. Le code Lua correspondant serait assez court (le traitement est simple) et aux dires des techs à des ordres de grandeur en terme d'efficacité. De ce qu'on m'a dit : du moment qu'il y a plus de 2 ou 3 appels de modèles/parser-functions on gagne en performance à passer par Lua.

Je suis d'accord avec toi sur le fait qu'il faudrait une « masse critique » de contributeurs à même de faire le suivi des modules, et on en est sans doute pas encore là.

Mais à l'inverse la majorité des modèles qui ne sont pas « basiques » sont en général proprement imbitables et la plupart du temps soit quelqu'un passe du temps à faire de l'essai/erreur pour modifier ces modèles soit c'est fait par quelqu'un qui connait le modèle par cœur… Il n'y a qu'à voir certaines discussions et tests autour de certains modèles. Hexasoft (discuter) 2 avril 2013 à 10:44 (CEST)

+1 avec Hexasoft. Pour les infobox, soit on est dans des cas simples et alors la configuration sous forme de tableau de données n'est àmha pas plus complexe que les appels de modules, soit on est dans les cas complexes et là il est intéressant de passer au Lua pour plus de performance et de lisibilité. Tpt (d) 2 avril 2013 à 21:54 (CEST)

Note : il est par contre peut-être possible d'intégrer des "helper-functions" qui retourne les sous-tables correspondant aux éléments les plus fréquents ?

Par exemple dans l'exemple de configuration que tu indiques :

{

type = 'mixed',

label = 'Nationalité',

params = 'nationalité'

},

Le type "mixed" est fréquent, ce pourrait être simplifié par un :

ib.helper_mixed("Nationalité", "nationalité"),

une fonction retournant tout bêtement une table de la forme "{ type = 'mixed', label = <param1>, params = <param2> }", et qui serait fournie dans une "boîte à outils" accessible dans les configurations.

Une idée comme ça, hein . Cordialement, Hexasoft (discuter) 2 avril 2013 à 22:20 (CEST)

Oui, les helpers c'est une très bonne idée. Tu t'en charges ? Tpt (d) 4 avril 2013 à 21:39 (CEST)

Je peux regarder, oui. Je suis un peu charette ces temps-ci, mais je vais prendre le temps de voir comment les inclure dans les définitions (au moins pour 1 ou 2 types qui semblent très souvent utilisés). Hexasoft (discuter) 4 avril 2013 à 21:47 (CEST)

J'ai fait un premier test. Voir ce que ça change dans la configuration. Je n'ai appliqué la modification que sur quelques champs. De plus ici le format est fixe (paramètres positionnels) ce n'est peut-être pas adapté pour tout.

De ce que j'en vois il faudrait probablement :

• gérer les paramètres multiples (par exemple plusieurs images)
• voir si il y a des cas où certains paramètres sont optionnels ou pas (gérer par paramètres nommés revient quasiment au même que la syntaxe des tables, à mon sens)
• peut-être prévoir des helpers de structure (helper.table). Mais là il faudrait pour la cohérence du code Lua que tout soit à l'intérieur de la fonction. Ça me parait difficile.

C'est juste un premier jet, hein. Des avis ? Hexasoft (discuter) 4 avril 2013 à 22:01 (CEST)

Helpers

Une chtite section dédiée, pour ne pas tout mélanger.

Quelques remarques/suggestions et questions :

• il serait sans doute intéressant d'ajouter aux différents types un champs "if", permettant de conditionner l'affichage. Dans mon idée : soit "if = true" et alors le test s'applique au champs "param" de l'entité considérée soit "if = 'param'" auquel cas il s'applique au paramètre dont le nom est indiqué. C'est à mon avis un cas de figure fréquent et on peut garder les syntaxes plus "libres" pour des cas plus complexes (par exemple conditionner une ligne à un contenu précis ou à une combinaison de paramètres). Note : éventuellement supporter "if=false", pour permettre facilement de désactiver certaines choses.
• la fonction "formatEvent()" ainsi que quelques autres pourraient devenir aussi partie intégrante du "helper" : je pense qu'il y a des cas de figure qu'on va rencontrer souvent, autant factoriser leur code. Je pense par exemple aux dates de naissance et de décès. Une fonction toute faite appelant le formatage des dates de naissance et de décès, avec test du type : si naissance et pas mort ajouter âge dans naissance ; si naissance et mort ajouter âge décès dans décès. C'est le genre d'outils qu'on va rencontrer pour toutes les infobox sur des personnes.
• remarque générale : si on veut une adoption large je pense qu'il faudra traduire les termes . Comme toi j'ai l'habitude de coder en anglais, mais ça va être utilisé par des francophones
• est-ce que certains champs sont optionnels ? Ça conditionne le choix du fonctionnement des "helpers". Par exemple des helpers avec paramètres nommés peuvent être intéressants si il y a de nombreux paramètres dont une bonne part optionnelle. Je veux dire, si (mettons) le format "mixed" a des champs label, value, param, style, color, background… mais que la plupart du temps on ne passe que label et param un appel du genre helper.mixed{ label="Langue", param="langue" } serait sans doute plus pertinent, et pas si différent des paramètres nommés des appels de modules. Ça complique un poil le code des helpers mais ce n'est pas grave (de plus ça permet éventuellement de gérer facilement des valeurs par défaut, mais c'est un autre point).
• point de détail : on pourrait même considérer que si "param==nil" (non indiqué) alors "param=mw.ustring.tolower(label)"

On pourrait au final arriver à quelque chose de très compact et simple pour tous les cas classiques. Pour les autres soit le besoin peut resservir et on intègre un nouveau helper soit c'est très spécifique et on fait une fonction dédiée dans la conf comme pour "formatEvent()" dans ton exemple.

Note annexe : en fait ce fonctionnement va très bien pour les taxobox. Le code des taxobox a juste à générer un fichier de conf à la volée au fur et à mesure qu'il traite les paramètres puis au final à appeler la génération d'une infobox sur cette conf
Cordialement, Hexasoft (discuter) 5 avril 2013 à 10:19 (CEST)

Entêtes de modules pour Wikisource

Dans wikisources, je voudrais installer les mêmes entêtes de modules qu'ici, basées sur le même module. La-bas je suis administrateur et je désire apprendre, comment faire ? --Rical (d) 1 avril 2013 à 21:30 (CEST)

Les entêtes, tu veux dire la "documentation automatique" ?

Ça tombe bien c'est moi qui l'ai fait ! . Tu crées le module Module:Documentation module (copie, crédit aux auteurs, toussa). Tu édites les messages système qui vont bien :

• MediaWiki:Scribunto-doc-page-does-not-exist : quand la page de doc n'existe pas
• MediaWiki:Scribunto-doc-page-header : quand la page de doc existe
• MediaWiki:Scribunto-doc-page-show : depuis la page de doc

Il faut regarder le contenu et recopier la même chose.

Il faut aussi ajuster MediaWiki:Scribunto-doc-page-name, le nom de la page de doc (chez nous "Module:$1/Documentation").

Note que si vous avez un autre nom pour la page de documentation il faudra faire quelques petites retouches dans le module car le chemin est codé en dur dedans (ce n'est pas supposé changer !).

N'hésite-pas si tu as besoin de plus de détails.

Note : le lien pour création de la page de doc fait référence à Modèle:Documentation/PreloadModule comme contenu de pré-chargement.

Note bis : ce contenu contient {{Projet Scribunto}}, à supprimer ou modifier selon les besoins.

Cordialement, Hexasoft (discuter) 1 avril 2013 à 21:43 (CEST)

À propos, Catégorie:Documentation de module ne s'affiche pas comme il faut, si tu pouvais y jeter un petit coup d'œil. Cordialement, ~Hlm Z. [@] 1 avril 2013 à 22:01 (CEST)

Marf ! Je ne comprends pas pourquoi ! En mettant la sortie du code dans un nowiki j'ai bien la catégorie. J'ai tenté de l'appeler dans un preprocess mais ça reste sans effet.

Je ne vois vraiment pas d'où vient le problème, même en mettant la catégorie en dehors des div et autres span (ce qui ne devrait pas influencer je pense).

Si quelqu'un a une idée je suis preneur. Hexasoft (discuter) 1 avril 2013 à 22:58 (CEST)

J'suis pas le seul à galérer, c'est déjà ça . ~Hlm Z. [@] 1 avril 2013 à 23:21 (CEST)

héhé.

Je pense qu'il y a quelque chose de "spécial" à ce niveau de traitement par mediawiki : j'ai remplacé le comportement du module par un retour inconditionnel d'une catégorie → la catégorie n'apparaît pas.

Ceci semble indiquer que les catégories ne sont pas interprétées au "niveau" où ce code est transclu. J'ai également tenté de mettre la catégorie dans le message système correspondant, sans effet non plus.

Je pense que je vais poser la question aux techs, parce que le code est correct et devrait marcher. C'est soit un bug soit un fonctionnalité Hexasoft (discuter) 1 avril 2013 à 23:26 (CEST)

Ok. Vu avec les techs. Cette partie est incluse comme un "message" et ne fait pas partie de la page elle-même. Ce message échappe donc au parsing des catégories. Je vais enlever l'ajout de la catégorie dans le module, et il faudra la déplacer dans la documentation elle-même (je vais l'ajouter à Modèle:Documentation/PreloadModule pour que ce soit insérer par défaut). Hexasoft (discuter) 1 avril 2013 à 23:36 (CEST)

Voilà : j'ai viré l'élément inutile du module et modifié le preload pour inclure la catégorie dans le bon noinclude. Il faudra modifier les différentes docs existantes pour ajouter à la fin :

<noinclude>
[[Catégorie:Documentation de module|{{BASEPAGENAME}}]]
</noinclude>

Cordialement, Hexasoft (discuter) 1 avril 2013 à 23:51 (CEST)

Merci pour toutes ces bonnes choses, ça a marché du premier coup, il n'y avait même pas de poisson d'avril, exemple : Module:Auteur

Et le processus d'installation est à la fin du code de Module:Documentation module/Documentation. --Rical (d) 2 avril 2013 à 01:30 (CEST)

J'ai remanié {{Sous-page de documentation}} pour qu'il soit compatible avec les modules et corrigé le code du module en conséquence (plus simple d'utilisation). Il y a peut-être des variables obsolètes dans le module du coup. ~Hlm Z. [@] 2 avril 2013 à 01:53 (CEST)

Mouaif… Tout d'abord je trouve dommage d'inclure {{Sous-page de documentation}} dans les pages de doc puisque mediawiki nous offre pour les pages de doc des modules l'inclusion systématique du message système Scribunto-doc-page-header (même s'il est dommage de ne pouvoir inclure automatiquement la catégorie par ce moyen). Ensuite il ne me semble pas que ce modèle apporte plus d'info que ce que produisait le module. Enfin l'autre point est que ça formait une unité d'aspect entre la doc vue depuis le module et depuis la page elle-même.

M'enfin après je dois dire que je m'en moque un peu, mais si on devait rester sur cette approche il faudrait enlever l'appel à Module:Documentation module qui n'a plus rien à faire dans ce cas.

Hexasoft (discuter) 2 avril 2013 à 08:59 (CEST)

Protection

Hello,
on aura besoin de protéger certains modules, comme pour les modèles.
J'ai adapté {{Protection}} pour qu'il reconnaisse les modules, et créé la catégorie Catégorie:Module protégé qui va avec. Ce modèle est bien sûr à mettre dans la page de documentation du module.

Cordialement, Hexasoft (discuter) 4 avril 2013 à 09:27 (CEST)

Il y a déjà une liste des pages protégées : [1]. — Dakdada (discuter) 4 avril 2013 à 11:57 (CEST)

Ben j'ai adapté {{Protection}} parce que c'est lui qui fait l'affichage "ce modèle est protégé blabla", et que c'est le genre de chose à mettre dans la doc (comme pour les modèles). La catégorie en question est la même que celle générée par ce modèle (Catégorie:Modèle protégé). Si cette catégorie n'est pas utile ce serait sans doute à faire corriger globalement au niveau de {{Protection}}, pour les modèles et les modules. Hexasoft (discuter) 4 avril 2013 à 12:09 (CEST)

Discussion module:Coordinates

Si des gens pouvait regarder le module coord. Il reste deux trois bricoles à régler. ça permettrait de gagner en appel notamment les tableaux triables sur critère de coordonnées. -- Xfigpower (pssst) 15 avril 2013 à 13:47 (CEST)

J'ai finalisé l'appel sur dsm long. Si des gens sous vector pouvait comparer les résulats

Gérer des listes de liens internes/interprojets en paramètre d’un modèle, qui entre autre affiche le nombre d’élément de chaque liste

Salut, dans le cadre de la création d’un modèle de connaissances prérequises , j’essaie de trouver un moyen de faire deux liste déroulantes dont l’intitulé indique le nombre d’éléments de chacune des listes. Je voudrais donc savoir quel est la façon d’implémenter recommandé.

Au passage je veux bien des conseils sur l’interface que devrait proposer le modèle, sachant que le but est de proposer deux listes de liens :

1. une liste de liens internes vers les articles wikipédia traitant des concepts ;
2. une liste de liens wikiversité vers les leçons qui traitent ces concepts.

Mon interrogation est donc, l’utilisateur devrait-il écrire :

{{Préalable|
* [[élément 1 de la première liste|libellé]]
* [[élément 1.2]]
* …
| <!-- seconde liste, second paramtère -->
* [[v:élément 1 liste 2|libellé]]
* [[v:2.1]]
*…
}}

Où pensez-vous qu’il est préférable d’avoir des paramètres nommés pour chaque élément et chaque libellé éventuel à lui associer ?

PS : J’écouterais vos éventuels avis sur l’utilité du modèle quand je le proposerait à la communauté, pour le moment je cherche juste des conseils techniques, merci. --Psychoslave (d) 25 avril 2013 à 13:57 (CEST)

Si tu n'a pas à manipuler le texte mais juste à compter les lignes, mieux vaut les donner directement en paramètre, comme ce que tu as écris. Compter le nombre d'éléments d'un texte est enfantin en Lua. NB : en fait même si tu voulais manipuler les éléments, les donner comme ça pourrait marcher aussi. — Dakdada (discuter) 25 avril 2013 à 16:53 (CEST)

L'avantage du texte donné comme tel, bien sûr, est que tu peux le formater comme tu veux, donc autant faire une liste wiki normale. — Dakdada (discuter) 25 avril 2013 à 16:57 (CEST)

Qu’entends-tu par liste normal ? L’inconvénient que je trouve au liste numéroté en dur dans les paramètre c’est que c’est beaucoup plus lourd à l’usage. --Psychoslave (d) 30 avril 2013 à 16:06 (CEST)

En pratique coté Lua tu peux faire comme tu veux, traiter le tout est assez simple dans tous les cas :

• que des paramètres nommés : (exemple) "| l1.1=el1 | l1.2=el2 | l1.3=el3 … | l2.1=el1 | l2.2=el2 …" → il suffit en Lua de construire le nom du paramètre à partir d'un indice de boucle et de tester son existence
• un paramètre nommé ou pas pour chaque liste : (exemple) "| liste1=… | liste2=…" ou encore "| ma liste 1 | ma liste 2" → peu importe que les éléments de chaque liste soient mis en forme avec "*", avec des virgules, des retours à la ligne ou autre : pour Lua c'est juste des éléments à chercher dans une chaîne (les modules reçoivent par exemple les liste de "*" ou de "#" avant leur interprétation). Note : voir mw.text.split() qui fait (fera) se travail plus simplement.
• un paramètre non nommé par élément. La seule difficulté est de "signaler" au module quand est-ce qu'on passe de la première à la seconde liste, ce qui peut se faire par un mot-clé séparateur ou autre. (exemple) "| el1.1 | el1.2 | el1.3 | … | fin de liste | el2.1 | el2.2 | el2.3 | …"

Le choix est vraiment juste une question d'ergonomie pour l'utilisateur du module. De mon point de vue l'intérêt du format "* el1\n* el2" est que 1. tu peux utiliser ce format directement en sortie et 2. les éditeurs ont l'habitude de manipuler ce formatage. Cordialement, Hexasoft (discuter) 30 avril 2013 à 16:40 (CEST)

@Psychoslave : liste normale = liste à puce wiki (avec * et [[]]). Donc avec les mêmes conclusions que Hexasoft. — Dakdada (discuter) 30 avril 2013 à 21:49 (CEST)

Un module étonnant chez nos amis anglo-saxons : en:Module:Chart

Je ne sais pas ce que l'on a ici dans le genre graphique mais là, je suis impressionné... En fait en cherchant des exemples de modèles graphiques, je ne suis pas parvenu à trouver une catégorie regroupant les trucs du genre {{Pyramide des âges 2}} en ne tenant compte que du côté graphique (je pense, par exemple, aux graphes climatiques). -- Xofc ^{[me contacter]} 26 avril 2013 à 18:16 (CEST)

Le problème c'est que tout est réalisé en CSS. Donc l'Atelier accessibilité risque de préciser qu'il ne faut pas utiliser ce module dans l'espace principal, d'où une certaine perte d'intérêt du module. — Zebulon84 (d) 27 avril 2013 à 22:28 (CEST)

C'est un peu vrai... Et, à la réflexion, c'est un peu un détournement de l'outil qui rappelle l'utilisation des tableaux pour faire de la mise en page avant l'invention des CSS. D'un autre côté, il est probable que les mal-voyants ne puisse de toute façon pas jouir d'un graphique. Il doit sûrement y avoir un moyen pour prévenir les lecteurs d'écran de ne pas s'y perdre. (Je me demande ce que cela donnerait de générer du SVG en Lua; pour le moment je ne pense pas que cela passe (ou que l'on puisse écrire du SVG dans le wiki-code)) -- Xofc ^{[me contacter]} 28 avril 2013 à 10:19 (CEST)

L'extension EasyTimeline génére un png, mais c'est programmé en perl, en dehors du « wiki-code ». — Zebulon84 (d) 28 avril 2013 à 19:01 (CEST)

Librairie "mw.text" disponible

Hello,
j'ai vu que la librairie mw.text était maintenant disponible sur test2.wiki.x.io. Pour ceux qui s'intéressent à certaines de ces fonctionnalités c'est l'occasion de tester. Fonctions présentes : listToText, gsplit, split, encode, trim, tag, nowiki, truncate, decode, unstrip.

Cordialement, Hexasoft (discuter) 30 avril 2013 à 13:58 (CEST)

Quelques détails : mw.text.listToText( { 1, 2, 3, 4, 5 }, '; ', ' or ' ) donne « 1; 2; 3; 4 or 5 »

mw.text.trim(s) vire les séparateurs en début et fin de s (fonction qu'on trouve codé dans de nombreux modules)

mw.text.unstrip(s) supprime l'encapsulation de tags spécifiques (en pratique nowiki, ref et pre, je crois). Pour mémoire si on appelle un module en lui passant un paramètre qui contient (par exemple) "<nowiki>toto</nowiki>" ce qu'on reçoit n'est pas une chaîne manipulable (on n'a pas accès à la partie "toto", par exemple pour un gsub ou autre). unstrip va retourner le contenu de la chaîne sans les tags (dans cet exemple "toto"). Notez qu'il n'est pas possible de savoir quel était le (ou les) tag enlevé. De même il semble que ce qu'on obtient n'est pas forcément le code d'origine (par exemple ref est pré-traité avant, on obtient donc un texte ne correspondant pas au contenu wiki. Note bis il manque à mon sens une fonction permettant de 1. détecter que la chaîne reçue est "taguée" et 2. de savoir quel(s) tag(s) sont présents ou enlevés (via unstrip).

nowiki(s) se contente en réalité de remplacer les caractères sensibles par leur version HTML

truncate() permet de limiter la longueur d'un texte en coupant le trop plein, avec ajout de "..." et autres options

split()/gsplit() permet de découper un texte en donnant le motif de séparation des éléments, et retourne une table contenant ces éléments (sans la partie "séparateurs").

Les autres me semblent de prime abord de moindre intérêt. Hexasoft (discuter) 30 avril 2013 à 15:25 (CEST)

Pour préciser : unstrip sur la chaîne <ref name="toto">reference…</ref> retourne <a href="#_note-toto-1">[1]</a>, ce qui n'est certainement pas un élément qu'on voudra traiter (et qui en plus ne marchera pas car le tag HTML <a> n'est pas autorisé dans le wikitext). Hexasoft (discuter) 30 avril 2013 à 15:36 (CEST)

mw.text est aussi disponible ici. c. f. Discussion module:Test. Tpt (d) 30 avril 2013 à 19:30 (CEST)

Ah cool, j'avais même pas vu Hexasoft (discuter) 30 avril 2013 à 19:58 (CEST)

Modèle de remplacement pour impression

Bonjour,

Quelqu'un sait il si on peut intégrer les modèle du style {{Coord/display/title/Imprimer}} en Lua, c-à-d s'il existe un moyen de savoir à l'intérieur d'un module qu'on est dans une version imprimable (voir Catégorie:Modèle de remplacement)? -- Xfigpower (pssst) 6 mai 2013 à 13:53 (CEST)

Je comprends rien à ce modèle. Il ne fait rien . Hexasoft (discuter) 6 mai 2013 à 14:20 (CEST)

J'ai déjà rencontré ces manipulations de balises noinclude includeonly print noprint, quand j'ai écrit un livre dans wikibooks et que j'ai cherché à obtenir la meilleure présentation, parce qu'en standard les raccords n'étaient pas très agréables.

Pour rassembler toutes les pages par transclusion et former une seule grande page imprimable :

• Il faut par exemple masquer les notes et références de chaque page pour qu'elles se retrouvent toutes à la fin de la page de regroupement à imprimer.
• La page de regroupement de mon exemple est ici et il faut aller voir les débuts et fins des sous pages, pour mieux comprendre et faire pareil.
• Il faut aussi signaler la version imprimable, soit dans la première page soit dans toutes, et dans mon cas, dans un modèle à part.

Et convertir le tout en Lua. --Rical (d) 6 mai 2013 à 15:44 (CEST)

Là c'est moi qui n'est rien compris...J'ai juste trouvé en rapport MediaWiki:Print.css qui permet sans doute de retirer des balises gênantes à l'impression.

Il y a également un suffixe dans le titre (&printable=yes) qu'on pourrait detecter dans l'url? Je vois qu'il y a également Catégorie:Exclure lors de l'impression mais dont la page de discussion me parait surréaliste... -- Xfigpower (pssst) 6 mai 2013 à 19:20 (CEST)

Bon, je suis pas sur qu'il y ait besoin de se préoccuper plus que ça. J'ai fait des tests d'impression et ça ma l'air régler uniquement avec les bon css et des display none pour cacher les bloc indésirable --Xfigpower (pssst) 6 mai 2013 à 19:20 (CEST)

Note : j'ai fait un test : le "printable=yes" n'est pas visible depuis Lua (fait en regardant le fullUrl de title() en mode imprimable ou non). Je pense effectivement que c'est à faire au niveau des CSS. Hexasoft (discuter) 6 mai 2013 à 19:16 (CEST)

Rah ! Y'avait un nowiki pas fermé. Donc plein de ~~~~ non traités. Comme j'ai corrigé le nowiki tous ces quadruples ~ sont devenus… ma signature + date. Que chacun regarde l'historique s'il veut savoir qui a dit quoi et quand, mais soyez certains que je ne me parlais pas à moi même Hexasoft (discuter) 6 mai 2013 à 19:18 (CEST)

Modèles Categ ?

Bonjour,

Je me demandais si il ne serait pas très intéressant de réécrire les modèles Categ ({{Categ Océanie}}, …, qui sont dans Catégorie:Modèle chronologique de l'espace Catégorie) qui sont utilisés pour le texte des catégorie « Année en XXX » pour simplifier l'appel de ces modèles. En effet, pour utiliser ces modèles il faut actuellement passer 4 paramètres déterminés à partir de l'année (décennie de l'année, chiffre de l'unité de l’année, décennie précédente, décennie suivante). Il me semble que les nouvelles fonctionnalités permettrait de n'avoir à passer que l'année en paramètre, le module s'occupant de construire les informations dont il a besoin. Voire aucun paramètre si le modèle utilise le titre de la catégorie pour déterminer l’année… --NicoV (d) 15 mai 2013 à 13:48 (CEST)

Utilisation dans l'espace principal

Bonjour, j'avais cru comprendre que l'utilisation des modules ne pouvait/devait pas se faire dans l'espace principal car cette fonctionnalité est encore en phase de test. Si tel est le cas, pourquoi le module Italiques biologiques est-il utilisé dans un grand nombre d'articles ? Je soupçonne son utilisation dans le modèle Infobox, mais où ? Aurais-je manqué une quelconque discussion (prise de décision) sur une phase de déploiement ? Cordialement, – Je viens en paix, Reptilien.19831209BE1[Bonjour,_✎] 24 mai 2013 à 11:25 (CEST)

Hello,

oui, il est accédé à travers quelques modèles taxobox (c'est d'ailleurs pour ça que j'ai protégé le module). Mais pour autant que je sache Scribunto n'est plus en test. Sur en: par exemple ils ont remplacé plusieurs gros modèles par des modules.

La demande de ne pas utiliser Scribunto « en production » concernait les premiers déploiements, à une époque où ils préféraient se prémunir contre des retours en arrière liés à des bugs non détectés, ou des problèmes de performance non visibles jusqu'à présent.

Je peux me tromper mais pour autant que je sache Scribunto est pleinement opérationnel et utilisable . Hexasoft (discuter) 24 mai 2013 à 11:41 (CEST)

Slt Hexasoft, c'est une bonne nouvelle que tu m'apprends là. Y a-t-il eu des discussions concernant la façon de nommer les modules (conventions sur les titres des modules) ? Par exemple, le nom du module format n'est pas très explicite (ça fait un peu fourre tout, format de quoi ?). De plus, il serait peut-être intéressant de séparer les modules qui effectuent du traitement de données (calcul: puissance d'un nombre, conversion en d'autres unités; manipulation de chaines de caractères: sous-chaîne, remplacement d'un mot par un autre) de ceux destinés à retourner des éléments graphiques (mise en forme d'une chaîne de caractère, liste de navigation, infobox, etc). Voilà, selon moi, un module bien conçu (en)String qui n’effectue que tu traitement sur les chaînes de caractères. – Je viens en paix, Reptilien.19831209BE1[Bonjour,_✎] 24 mai 2013 à 17:30 (CEST)

Note : les modules comme String me semblent être une mauvaise idée : ils fournissent aux articles ou aux modèles des briques de base, ce qui à mon sens décourage de porter des modèles en tant que module en donnant accès à des fonctionnalités trop bas niveau. Sinon il aurait été plus simple de considérer Lua comme une grosse parser-function .

Pour les conventions de nom on en a parlé un peu au début. Toutefois il me semble qu'il y a plusieurs catégories de modules : ceux fournissant un servir « complet » à l'utilisateur et ceux fournissant un service intermédiaire (comme par exemple le module infobox présenté plus haut). Hexasoft (discuter) 24 mai 2013 à 17:43 (CEST)

Tester si un article contient une section

Salut ! Dans le cadre de la création d’un modèle qui suppose l’existence de sections particulières dans l’article où il est placé, je cherche un moyen de tester si l’article contiens bien les chaînes correspondantes, et d’afficher un message d’erreur si ça n’est pas le cas (comme avec les balises ref quand references n’est pas présent). --Psychoslave (d) 29 mai 2013 à 09:39 (CEST)

Hmmm. C'est possible. On peut créer un title (voir mw.title dans la doc) sur n'importe quel article. L'une des actions qu'on peut faire sur un title valide est d'obtenir le raw content de l'article (le code wiki brut). Il est donc possible de cibler un article, générer son title, accéder à son contenu et rechercher dedans une expression du type "^[=]*[ ]*Nom de ma section[ ]*[=]*[ ]*$" (expression à affiner) pour valider sa présence.

Note toutefois que générer un title pour autre chose que l'article courant est une fonction coûteuse (notée dans le compte des "expensive functions" comme #ifexist) et qu'il faut donc éviter de trop y faire appel, surtout au sein d'un modèle qui pourrait être appelé de multiples fois dans un même article (il existe une limite au nombre d'"expensive functions" qui peuvent être appelées dans un article).

J'espère que ça t'aidera. Si tu veux des détails sur title n'hésite-pas à demander. Cordialement, Hexasoft (discuter) 29 mai 2013 à 14:28 (CEST)

Fusion du modèle:Démographie et modèle:Démographie2

Bonsoir, comme suggéré suite à ma demande de bot de migration du modèle:Démographie vers modèle:Démographie2, il serait plus efficace de réécrire ces modèles et de les fusionner. L'idée serait d'avoir à nouveau des paramètres nommés comme dans l'ancien modèle qu'un module en lua saurait déchiffrer. Tout le détail se trouve dans la requête aux bots.

Y a-t-il un volontaire ? Je reste à sa disposition pour toute question. D'avance, merci !--FDo64 (d) 6 juin 2013 à 22:00 (CEST)

OMG ! C'est quand on voit la complexité de ce type de modèles qu'on se dit que Scribunto est une bonne idée . Hexasoft (discuter) 6 juin 2013 à 22:23 (CEST)

L'écriture d'un nouveau module est en cours, voir Discussion module:Démographie, venez y participer si cela vous intéresse.

--FDo64 (d) 9 juin 2013 à 23:13 (CEST)

Mis en place aujourd'hui. Merci à Hexasoft !--FDo64 (d) 17 juillet 2013 à 14:22 (CEST)

Modèle Gallery et Module:HtmlBuilder

Bonjour,

Je viens d'importer textuellement ces deux scripts de la Wikipédia en anglais. J'utilise déjà le premier, via {{Gallery}}, dans projet Manhattan, tellement il m'a plu. Je n'ai cependant pas traduit les documentations.

Cantons-de-l'Est (d) 12 juin 2013 à 02:28 (CEST)

Catégories et erreurs selon les espaces et édit

@ Hexasoft, pour adapter les catégories et erreurs selon les espaces de noms, je faisais autrement mais par table c'est mieux (plus facile à faire évoluer et à comprendre, le code est plus compact et plus rapide à l'exécution). Il faut aussi pouvoir donner des exemples dans les pages de documentations, de discussions et d'aides.

Mais certaines erreurs que je signale sont pour l'utilisateur au moment ou il saisit les paramètres dans le modèle et ne doivent surtout pas perturber le simple lecteur. Je voudrais détecter si la page est en edit ou non, j'ai cherché sans succès. Quelqu'un a-t-il une solution ? Sinon il faudra demander une évolution par "bug". -- Rical (d) 3 juillet 2013 à 13:25 (CEST)

Lua, Wikidata, classifications et généalogies

Dans l'état actuel de Scribunto pour accéder à Wikidata, on ne peut obtenir que des propriétés de l'article où l'on est.

Mais on n'a aucun moyen pour collecter des informations sur plusieurs pages, comme les taxons, famille ... d'une espèce. De même pour les généalogies royales, les membres d'une équipe de foot ...

J'ai donc demandé une évolution pour pouvoir écrire :

• mw.wikibase.getProperty("p20", "Q535") et obtenir n'importe quelle propriété de n'importe quel article.

Mais il faudra un peu de patience. --Rical (d) 17 juillet 2013 à 10:33 (CEST)

Pas besoin de demander une évolution, c'est déja dans la roadmap, même si ce sera prêt quand c esera prêt :) c'est vrai que c'est un point bloquant pour énormément de choses. (par exemple j’avais idée d'un modèle {{InfoItem|article}} pour afficher en infobulle la description d'un item qui n’a pas d'article dans Wikipedia par exemple par qu'il fait l'objet d'une section dans Wikidata, c'est pour l’instant pas possible. — TomT0m ^[bla] 17 juillet 2013 à 12:36 (CEST)

C'est où la/les roadmap ? --Rical (d) 17 juillet 2013 à 15:28 (CEST)

Ça passe sur la mailing list et le project chat, il doit y avoir une vague roadmap sur le site de l’extension Wikibase, mais c'est pas super précis en l’état. — TomT0m ^[bla] 13 août 2013 à 15:56 (CEST)

J'ai tenté Module:WBHacks sur fr mais sans succès. Pourtant ça marche sur wikidata mais ça passe par des appels http en json (une usine à gaz quoi)

Je n'ai pas compris comment l'équipe de dev ait pu passer à coté : par exemple, on prend les listes de style Liste des pays et territoires par superficie, ça devrait faire objet à une consultation de la base Wikidata. -- Xfigpower (pssst) 18 juillet 2013 à 11:44 (CEST)

L'évolution demandée est lancée, attendons. ("L'usine JSON" me rappele que j'ai déjà développé un client de rendez-vous médical par JSON pour iPhone, mais la BDD le gérait mal, on a du abandonner.)

Mais j'ai une autre demande à wikidata : définir un nom et un prénom pour toutes les personnes. Je n'ai pas eu de réponse, où placer cette demande ? Déclarer aussi un bug ? --Rical (d) 18 juillet 2013 à 13:32 (CEST)

Bonjour, tu as fait ta suggestion sur la page de discussion d'un bot, ce n'est pas le bon endroit. Il n'y a pas besoin de déclarer un bug, mais il faut juste que la communauté décide de la façon dont on veut exprimer ça sur Wikidata. Il y a eu une discussion (d:Wikidata:Requests for comment/Personal names), mais il n'y a toujours aucune décision de prise :[...--Zolo (discuter) 13 août 2013 à 17:50 (CEST)

Module:Documentation

Bonjour,

Le module semble trop gourmand en ressources, par exemple sur Modèle:Arbre généalogique, mais son créateur n'a pas pu résoudre le problème. Quelqu'un aurait-il une idée pour améliorer les choses ?

Orlodrim ^[discuter] 21 juillet 2013 à 17:10 (CEST)

À la louche déjà je dirais : trop de frame:preprocess() appliqués à des pseudo-modèles. Chacun de ces appels lance une instance du parser mediawiki, qui doit lui-même en relancer une pour traiter le pseudo-modèle (si j'ai bien suivi le fonctionnement de Scribunto et de mediawiki). Il me semble qu'il faudrait déjà remplacer tous ces appels par l'utilisation de mw.title et par du traitement Lua si les données de la table title ne sont pas de la forme voulue. Dans la même veine on peut faire #ifexist via Lua (et mw.title), et il y en a beaucoup.

Cordialement, Hexasoft (discuter) 21 juillet 2013 à 21:30 (CEST)

Le code PHP exécuté par le parser lors de l'appel à frame:preprocess est compté sur la limite de temps Lua ? Si c'est le cas, ça risque de compromettre l'utilisation d'un module pour {{Documentation}}, vu que le seul appel à "frame:preprocess('{{' .. p.docname(frame) .. '}}')" prend environ 17 secondes (c'est le temps qu'il faut pour prévisualiser la sous-page de documentation de ce modèle). Orlodrim ^[discuter] 21 juillet 2013 à 22:11 (CEST)

J'ai créé dans le module une fonction p.docname2() utilisant les fonctionnalités Lua plutôt que de passer par les parser-functions et les appels à frame:preprocess(). Il faudrait tester avec ça pour voir si c'est plus rapide. Je peux tenter de ré-écrire ce module en excluant un maximum de fonctions "externes", mais pas cette semaine. Cordialement, Hexasoft (discuter) 21 juillet 2013 à 22:43 (CEST)

La fonction que tu as créé ne prend pas en compte l'espace de nom, elle retourne par exemple Lorem/Documentation au lieu de Modèle:Lorem/Documentation. À noter que j'ai volontairement externalisé les fonctions ifexist() et docname() pour pourvoir les modifier par la suite. Hlm Z. [@] 21 juillet 2013 à 23:19 (CEST)

Ah tu as raison. J'ai l'habitude de faire des modules pour l'espace principal, j'ai tendance à ne pas penser à ça (bien que la page de doc d'un article ça n'ait pas trop de sens…). Note que pour la commande {{page de doc}} je ne sais pas ce qui est plus rapide : faire un preprocess sur l'inclusion de la sous-page ou utiliser preprocess sur un titre:getContent de la page de doc cible. Hexasoft (discuter) 21 juillet 2013 à 23:50 (CEST)

Ba c'est justement la question que je me posais. Y'a pas une instruction donnant le temps d'exécution en Lua (mettons je veux tester la différence entre docname() et docname2() en temps) ? Hlm Z. [@] 22 juillet 2013 à 00:04 (CEST)

Ben dans la console de test tu peux appeler chaque fonction et mesurer le temps . Il me semble qu'il y a un truc pour faire des tests de perfs mais pas accessible aux péons que nous sommes. Hexasoft (discuter) 22 juillet 2013 à 08:46 (CEST)

Si le calcul en Lua prend plus de 1 seconde, alors il y a un résumé de ce qui est fait dans le code source de la page générée (vers la fin de la page, au-dessus du print-footer). SI c'est moins il y a quand même des indications du type « expensive parser function count ». Il y a aussi une indication du temps total pour envoyer la page à la toute fin du source. — Dakdada (discuter) 22 juillet 2013 à 15:31 (CEST)

Ici, j'utilise os.clock() pour afficher des temps d'exécutions partiels datés en bas de page (init, import des arguments, génération de la page). --Rical (d) 23 juillet 2013 à 00:01 (CEST)

Merci Rical, cette méthode est relativement efficace. Hlm Z. [@] 23 juillet 2013 à 15:53 (CEST)

Oui, c'est à noter. Ça peut être utile dans les phases de développement des modules, c'est clair (en tout cas pour les modules un peu « complexes »).

Au passage il pourrait être intéressant de connaître le coût en temps de frame:preprocess(). On pourrait ainsi calculer le temps d'exécution d'un modèle en faisant frame:preprocess("{{LeModèleDontOnVeutConnaitreLeTempsDExécution}}) (et en soustrayant le temps du preprocess lui-même) afin d'effectuer des comparaisons avec des modules donnant des fonctionnalités équivalentes. Hexasoft (discuter) 23 juillet 2013 à 16:35 (CEST)

J'ai tenté de corriger au mieux le module (voir Module:Documentation/Bac à sable), mais le problème semble bien venir du modèle et de sa documentation, beaucoup trop lourde pour être chargée. Hlm Z. [@] 27 juillet 2013 à 16:36 (CEST)

Cela me semblait une évidence depuis le début, mais les améliorations de performance sont toujours les bienvenues. Les nombreux appels à ce modèle compliqué devaient déjà poser problème auparavant.

Peut-on détecter ces pages de documentation trop lourdes pour les alléger ou les découper en plusieurs sous-pages ?

--FDo64 (d) 27 juillet 2013 à 17:12 (CEST)

Il y a une solution générique mais vous n'allez pas aimer ça. En gros, il faudrait réécrire le module en deux bouts pour que le parsing de la page soit fait à l'extérieur, dans le modèle :

{{#invoke:Documentation|affiche_la_documentation_a_partir_du_code_en_argument|{{ {{#invoke:Documentation|calcule_le_nom_de_la_page_de_documentation}} }} }}

Orlodrim ^[discuter] 27 juillet 2013 à 17:21 (CEST)

Le plus simple serait d'exporter les exemples dans une sous-page. Il faudrait au passage protéger au plus vite Module:Documentation. Cordialement, Hlm Z. [@] 29 juillet 2013 à 23:10 (CEST)

Je peux le protéger si tu veux. Juste dis-moi. Hexasoft (discuter) 30 juillet 2013 à 09:49 (CEST)

Tu peux le protéger . Hlm Z. [@] 30 juillet 2013 à 12:52 (CEST)

. J'ai aussi ajouté le modèle de protection dans la doc. Hexasoft (discuter) 30 juillet 2013 à 13:11 (CEST)

Module:Langue

Je viens de créer le Module:Langue, qui reprend les fonctionnalité des modèle de tel que lang, Code langue, Nom langue...

J'ai commencé à tester ces fonctions sur cette page : Utilisateur:Zebulon84/Brouillon3. Merci de jeter un œil pour m'aider à trouver les bug que je n'ai pas encore repérer. Vous pouvez modifier ma page de brouillon si besoin. Je testerai demain avec des appels en passant par un modèle.

D'une part ces modèles langues sont directement ou souvent indirectement présent sur beaucoup de pages, d'autre part certaines fonction seront utiles pour des d'autres modules. Je prévois par exemple de travailler sur les modèles Article et Ouvrage qui ont besoin de ces fonctions et qui, vu leur utilisation et relative complexité, gagneront certainement à être traduit en Lua.

Si j'ai oublié une fonction langue essentielle, n'hésitez pas à le signaler.

— Zebulon84 (d) 26 juillet 2013 à 20:11 (CEST)

Il y a un module similaire si le Wiktionnaire, cf wikt:Module:langues (et wikt:Module:langues/data).

il y a des milliers de langues existantes : y a-t-il une sélection dans Module:Langue/Data ? Quelle est la limite des « langues les plus courantes » ? — Dakdada (discuter) 26 juillet 2013 à 21:10 (CEST)

J'ai simplement repris la liste des modèles Nom langue et Code langue 2. Avec la performance du lua les listes pourraient être allongées, mais je doute qu'il soit utile d'être exhaustif. Et avoir un long fichier sera toujours plus long à charger qu'un court. Je définirais la limite aux langues qui sont réellement cité sur fr.wiki.x.io, mais c'est bien sur ouvert à discussion. — Zebulon84 (d) 26 juillet 2013 à 21:39 (CEST)

Remarque, Lua est très performant quand il s'agit de gérer des listes très longues, d'autant plus si la liste est stockée en cache (si elle est utilisée plusieurs fois dans une page). Par exemple, sur le Wiktionnaire, il y a 4600 langues dans la liste actuelle, et le chargement de la liste est de l'ordre de quelques centièmes de secondes, en prenant 3-4 Mo de mémoire. Donc s'il y a une limite elle doit être d'ordre pratique et non technique. — Dakdada (discuter) 26 juillet 2013 à 21:59 (CEST)

Les fonctions de ce module sont désormais utilisés par les modèles correspondant. Ne pas modifier sans précaution. — Zebulon84 (d) 5 août 2013 à 03:10 (CEST)

TableBuilder

Serait-il possible de simplifier l'utilisation de « table.insert(maTable, maChaine) » en une implémentation fluide du style :

local maTable = {}

maTable.insert("Ma").insert("Chaine")
       .insert("Est").insert("Inseree")

return maTable.concat()

Cordialement, Hlm Z. [@] 2 août 2013 à 18:08 (CEST)

---

C'est possible de cette façon :

local function fluide_insert(t, ...) 
    table.insert(t, ...) 
    return t
end

local maTable = { insert = fluide_insert }
maTable:insert(" Chaine"):insert(" Est")
       :insert(1, "Ma"):insert(" Inseree")
return table.concat(maTable )

Il est certainement possible d'en faire autant pour concat, mais l'intérêt me semble faible.

— Zebulon84 (d) 7 août 2013 à 07:41 (CEST)

Juste pour s'amuser, définition de l'objet table avec toutes les méthode de la librairie table et un constructeur :

local function fluide_concat( t, ... ) 
    return table.concat( t, ... )
end
local function fluide_insert( t, ... ) 
    table.insert( t, ... ) 
    return t
end
local function fluide_maxn( t )
    return table.maxn( t )
end
local function fluide_remove( t, ... )
    table. remove( t, ... )
    return t
end
local function fluide_sort( t, ... )
    table.sort( t, ... )
    return t
end
local function fluide_const( t )
    local t1 = mw.clone( t )
    return t1
end

local tableObject = { 
    concat = fluide_concat, 
    insert = fluide_insert, 
    maxn   = fluide_maxn,
    remove = fluide_remove,
    sort   = fluide_sort,
    new    = fluide_const,
}

local maTable = tableObject:new()

maTable:insert( "chaine" ):insert( "est" )
      :insert( 1, "Ma" ):insert( "inseree" )

return maTable:concat( ' ' )

On peut même appeler l'objet mw.table si on veut, mais cela pourrait faire croire que c'est dispo partout...

Zebulon84 (discuter) 25 août 2013 à 07:51 (CEST)

Je voulais utiliser cette structure mais le problème c'est qu'elle utilise l'opérateur « : » qui diffère de l'utilisation classique de la syntaxe objet. Le module HtmlBuilder utilise une méthode de chainage particulière formant du pseudo-objet, c'est cette méthode que je voudrais utiliser. (Désolé je n'avais pas vu ta réponse précédente) Cordialement, Hlm Z. [@] 25 août 2013 à 15:33 (CEST)

Merci, je n'avais pas analyser HtmlBuilder et j'ai pu approfondir un peu les metatables. Voici le résultat (avec  :

local meta = { }
meta.concat  = function ( t, ... ) return table.concat( t, ... )   end
meta.insert  = function ( t, ... ) table.insert( t, ... ) return t end
meta.remove  = function ( t, ... ) table.remove( t, ... ) return t end
meta.sort    = function ( t, ... ) table.sort( t, ... )   return t end
meta.maxn    = function ( t )      return table.maxn( t )          end
meta.__index = function ( t, key ) 
    local metafunc = meta[key]
    if type( metafunc ) == 'function' then
        return ( function ( ... ) return metafunc( t, ... ) end )
    end
end

local tableObject = {
    new = function ()
        local t = { }
        setmetatable( t, meta )
        return t
    end
}

local maTable = tableObject.new()
maTable.insert("chaine").insert("est")
       .insert(1, "Ma").insert("inseree")

return maTable.concat( ' ' )

L'avantage, c'est que ça n'ajoute pas d'éléments dans la table, donc il doit être possible d'utiliser pairs normalement.

Zebulon84 (discuter) 25 août 2013 à 19:05 (CEST)

C'est parfait, c'est exactement ce que je voulais. J'ai donc créé Module:TableBuilder. Ça m'énerve, les méta-tables j'y comprends rien, faut vraiment que j'y travaille. Merci encore. Cordialement, Hlm Z. [@] 25 août 2013 à 20:12 (CEST)

Nouvelles fonctionnalités

Je propose trois nouvelles fonction pour TableBuilder qui me paraissent très utile dans le cadre de création de wikicode. J'aimerai votre avis sur les noms :

• Une fonction pour insérer de multiples éléments en une seule opération, mais qui n’insère pas les éléments nil. Cela permet d'éviter les petites concaténation avant l'insertion, et s'abstenir de test ou de « or  » lors de la compilation de texte. Je propose le nom « minsert » pour « multiple insert ».
• Une fonction pour pour insérer dans la table tous les éléments d'une autre table séquence. Je propose le nom « tinsert » pour « table insert ».
• Une fonction pour transformer une table normale en table type TableBuilser. « set » ?

le code de ces fonctions

meta.minsert = function( t, ... )
    local sel
    for i = 1, select( '#', ... ) do
        sel = select( i, ... )
        if sel then
            table.insert( t, sel )
        end
    end
    return t
end

meta.tinsert = function( t, tab, first, last )
    for i = ( first or 1 ), ( last or #tab ) do
        table.insert( t, tab[i] )
    end
    return t
end 

set = function( t )
    setmetatable( t, meta )
    return t
end

 

Par ailleurs je signale que je viens de modifier new pour que les données transmise à la fonction soient les éléments de la table retournée. Un petit exemple des possiblités :

local tab1 =  TableBuilder.new( 'a', 'b', 'c' )
local tab2 = { 'd', 'e' }
TableBuilder.set(tab2)
tab2.minsert('f', nil, 'g', 'h' )
tab1.tinsert(tab2)
return tab1.concat( ', ' )

retourne « a, b, c, d, e, f, g, h »

Zebulon84 (discuter) 2 septembre 2013 à 14:41 (CEST)

Oui, c'est plutôt une bonne idée. Aucun désaccord avec le nom des méthodes. Cordialement, Hlm Z. (discuter) 2 septembre 2013 à 17:11 (CEST)

J'ai ajouté une fonction clone pour dupliquer une sous-table chargée par mw.loadData et que l'on veut modifier.

J'ai aussi crée une fonction if_insert, proche du #if: du wikicode. Ça marche, c'est concis, mais ça fait un code illisible. J'ai donc choisi de ne pas l'intégrer. Au cas ou ça intéresse quelqu'un le code est ci-dessous.

Zebulon84 (discuter) 8 septembre 2013 à 17:43 (CEST)

meta.if_insert

meta.if_insert = function ( t, test, yes, no )
    local function insertResult( result )
        local tr = type( result )
        if tr == 'number' or tr ==  'string' then
            table.insert( t, result )
        elseif tr == 'table' then
            meta.tinsert( t, result )
        end
        return t
    end
    
    local function validText( texte )
        local tt = type( texte )
        return ( tt == 'string' and mw.text.trim( texte ) ~= '' ) or tt == 'number' 
    end
    
    if type( test ) == 'table' then
        for i = 1, #test do
            if validText( test[i] ) then
                test = true
                break
            end 
        end
    end

    if test == true or validText( test ) then
        return insertResult( yes )
    else
        return insertResult( no )
    end
end

 

Date

La fonction mw.title.new( page ).exists est maintenant disponible mais reste couteuse.

Pour faire un modèle Date efficace, pensez-vous qu'il soit raisonnable de créer une base de donnée des plages de date dont les pages existent déjà ou dont les pages ont très peu de chance d'exister à moyen terme, pour éviter une bonne partie des appel à cette fonction ?

J'ai créé la fonction pour tester ce que cela pourrait donner (adapté du code du module Date), à voir sur mon module et le résultat sur cette page de brouillon. La base est pour le moment directement dans le module, mais elle sera séparée et chargée avec mw.loadData. Les données qu'elle contient déjà sont correctes mais il faudra bien sur l'étendre à la majorité des thèmes existant. Mais même incomplète c'est déjà un avantage important.

Le problème est évidemment la gestion des mises à jour des données de cette base.

— Zebulon84 (d) 7 août 2013 à 08:29 (CEST)

Après avoir développé ma méthode, et ajouter de nouvelles fonctionnalités demandées, j'ai mis à jour le module:Date, et crée sa base de données module:Date/Data.

La base de données doit être complétée pour la partie géographie, mais l'essentiel est là.

J'ai essayé de faire une documentation utilisable par des non expert en lua, notamment pour la base de donnée. Comme je suis nul en orthographe, je remercie par avance ceux qui vont corriger ces pages.

La réduction des fonctions couteuses peu être intéressante pour des articles chargées en dates. Pour Seconde Guerre mondiale on passe de 55 à 11. Ce sera surtout sensible pour les dates lié à un qualificatif.

La fonction peut peut être testée avec #invoke: ou avec le modèle Utilisateur:Zebulon84/bac à sable/Modèle:Date et appliqué à n'importe quelle page avec template Sandbox.

Des critiques (+ ou -) ?

Zebulon84 (discuter) 31 août 2013 à 15:40 (CEST)

Coordonnées et Wikidata

Les coordonnées me paraissent une des choses pour laquelle l'usage de Wikidata devrait être la plus simple (sujet peu polémique, pas vraiment besoin de sources, pas de différence culturelle notable entre les différentes langues). Il n'y aurait pas quelqu'un pour intégrer ça à module:Coordinates. On récupère la latitude et la longitude par :

mw.wikibase.getEntity().claims.p625[0].mainsnak.datavalue.value["latitude"]
mw.wikibase.getEntity().claims.p625[0].mainsnak.datavalue.value["longitude"]

--Zolo (discuter) 13 août 2013 à 09:29 (CEST)

j'ai fait des tests mais sur Module:Coordinates/Test mais ça plante. L'idée est de préciser 'src=wikidata' pour récupérer les argument 1 et 2 -- Xfigpower (pssst) 13 août 2013 à 12:05 (CEST)

Sur Wikipédia hongrois j'ai rajouté ça à leur Module:Wikidata pour les tout premiers tests, mais peut-être qu'ici vous avez d'autres idées sur la façon de faire. — Oliv☮ ^{Éppen hozzám?} 13 août 2013 à 12:19 (CEST)

J'ai corrigé la proposition d'Xfigpower. Cela fonctionne maintenant (exemple). Tpt (discuter) 13 août 2013 à 15:00 (CEST)

Super merci, peut-être qu'on peut passer ça sur le module principal et l'intégrer aux modèles ? En fait, je ne sais pas quelle est la meilleure méthode. Il me semble que les modèles du genre Modèle:Infobox/Ligne mixte latitude longitude, devraient afficher par défaut les coordonnées Wikidata , et je ne sais pas si un paramètre "src" est ce qu'il y a de plus simple. A la limite on pourrait se passer de Wikidata dans le module, et simplement le mettre dans les modèles (du gendre {{#invoke:Coordinates|coord|{{#if: {{{2|}}} | {{{2}}} | latitude Wikidata }} }} ? --Zolo (discuter) 13 août 2013 à 16:34 (CEST)

J'ai été obligé de ne pas passer par src car le display title affiché une erreur. Conclusion, on passe juste rien est puis voilà -> cf Roumanie. Je dois me pencher aussi sur le passage du paramètre globe et scale qui dépendent encore de l'entrée wikidata -- Xfigpower (pssst) 13 août 2013 à 16:50 (CEST)

Je ne sais pas, dans ta version, ça n'a l'air de marcher qu'avec un paramètre source. Peut-être simplement comme ça ? --Zolo (discuter) 14 août 2013 à 11:55 (CEST)

J'ai juste oublier de remettre à niveau le module de test -- Xfigpower (pssst) 14 août 2013 à 16:53 (CEST)

J'ai ajouté un petit paramètre pour désactiver plus facilement Wikidata. Quand ce sera possible, ilfaudrait ajouter la possibilité d'aller chercher les coordonnées sur un autre élément Wikidata, mais en attendant, je peux mettre ça en circulation ? Je pense que ça vaudrait le coup pour Modèle:Infobox/Ligne mixte latitude longitude. --Zolo (discuter) 8 septembre 2013 à 10:36 (CEST)

Je pense qu'il ne peut pas y avoir de problème avec mon ajout sur Module:Coordinates/Test. Un administrateur pourrait-il reporter les changement sur la version non test ? --Zolo (discuter) 10 septembre 2013 à 09:58 (CEST)

Comment concaténer deux trucs concaténés ?

Bonjour

Par exemple j'ai :

local wikitext1 = '* Le '
.. fruit .. ' est un fruit.'
local wikitext12 = '* Le '
.. animal .. ' est un animal.'

J'aimerais renvoyer "wikitexte1 .. wikitexte2", c'est surement tout simple, mais je n'y arrive pas...

"wikitext = wikitext1 .. wikitext2
return wikitext" ne semble pas marcher, ni mettre les "wikitext1 & 2" dans une table pour y ressortir avec table.concat() (ou alors je me suis trompé dans la syntaxe).

Donnez-moi si possible un exemple, pas une méthode Merci . — Şÿℵדαχ₮ɘɼɾ๏ʁ ^{You talkin' to me?} 17 août 2013 à 05:13 (CEST)

Bon, j'ai trouvé : je mets tout dans des tables, j'ajoute deux tables concaténées dans une expression et je renvoie l'expression :

local text1 = { '* Le ' , fruit , ' est un fruit.' }

local text2 = { '* Le ' , animal , ' est un animal.' }

local wikitext = table.concat( text1 ) .. table.concat( text2 )

return wikitext

C'est peut-être un peu lourd, mais en fait je veux deux phrases — dont une est optionnelle — avec le même texte et seulement des variables aux noms différents qui changent aux mêmes positions, donc je crée la première table et j'en fais un clone avec mw.clone , puis je change juste les variables à certaines positions.

Par contre, est-ce que quelqu'un peut me dire comment insérer deux fois la même variable à plusieurs positions dans une table ? — Şÿℵדαχ₮ɘɼɾ๏ʁ ^{You talkin' to me?} 17 août 2013 à 06:56 (CEST)

Tu peux tout a fait faire return wikitext1 .. wikitext2

Mais ton code ci-dessus ne marche pas car :

• tu as déclaré deux fois wikitext1, donc wikitext2 n'existe pas
• dans ton return tu as mis un « e » à la fin de « wikitext2 »

Dans ton code tu as probablement fait une erreur de ce genre, une majuscule ici et pas là... Je me suis déjà arraché les cheveux à cause de bêtises de ce genre.

Ces derniers jours j'utilise eclipse, version Lua Development Tools, qui met en gras les variables non déclarées, ça permet de les repérer plus facilement. Ça me permet aussi de tester en bonne partie mon code sans faire des dizaines d'édits sur wiki.

Zebulon84 (discuter) 17 août 2013 à 08:34 (CEST)

J'ai pas fait attention à ce que j'écrivais ! Dans mon modèle pourtant tout me semblait bon (ce n'était pas le même code qu'ici bien sur), mais je n'y arrivais pas à y faire fonctionner. Là je viens de réessayer et ça marche...

Sinon, peut-on insérer un truc dans une table à plusieurs endroits à la fois (en une seule ligne je veux dire) ?

Pour insérer plusieurs élément dans un texte il y a la fonction string.format (ou pour l'UTF-8 mw.ustring.format) qui doit être plus efficace que la concaténation vu l'usage qu'en fait MediaWiki dans son code.

wikitext = mw.ustring.format( '* Le %s est un fruit.\n*Le %s est un animal.', fruit, animal)

La doc manque de précisions sur les possibilités de cette fonction pour ceux qui ne connaisse pas le C. Si quelqu'un à un site avec plus d'explication je suis preneur.

Pour insérer plusieurs données dans une table déjà crée en une seule fois je ne connais pas. si tu en a besoin régulièrement tu peux créer une fonction qui le fait.

local function multiInsert(t, ...) for i = 1, select( '#', ... ) do table.insert( t, ( select( i, ... ) ) ) end end local fruit, animal = 'abricot', 'crocodile' local maTable = { '*Le ', fruit, ' est un fruit.' } multiInsert( maTable, '\n', '*Le ', animal, ' est un animal.' ) local wikitext = table.concat( maTable )

Zebulon84 (discuter) 17 août 2013 à 10:23 (CEST)

Comment faire une condition si un paramètre existe ou pas ?

On continue...

J'ai par exemple un modèle {{Truc|fruit=<un fruit>|animal=<un animal>}} où les paramètres ne sont pas obligatoirement nommés et où le paramètre "animal=" n'est pas forcément rempli.

On peut donc avoir par exemple {{Truc|kiwi}} ou {{truc|fruit=kiwi|animal=chien}}.

Mon module ressemble à ça :

local a = { }
  
function a.truc(frame)
    local args = ( frame.getParent and frame:getParent().args ) or frame or { }
    local fruit = args[1] or args["lang1"] or ''
    local animal = args[2] or args["art1"] or ''
 
    local wikitext1 = '* Le '
    .. fruit .. ' est un fruit.'
    local wikitext2 = '\n* Le '
    .. animal .. ' est un animal.'
 
    return wikitext1 .. wikitext2
end
  
return a

Comment faire pour que si j'ai {{Truc|kiwi}}, le résultat soit seulement :

* Le kiwi est un fruit.

Dès que c'est trop simple, je coince ! Merci de recopier l'exemple de modèle en le corrigeant, je comprends mieux que des explications — Şÿℵדαχ₮ɘɼɾ๏ʁ ^{You talkin' to me?} 17 août 2013 à 23:16 (CEST)

Je ferais un truc comme ça :

local a = { }
  
function a.truc(frame)
    local args = ( frame.getParent and frame:getParent().args ) or frame or { }
    local fruit = args[1] or args['fruit']
    local animal = args[2] or args['animal']
    
    local reponse = {}
    
    -- Fruit
    if fruit != nil and fruit != '' then
        table.insert(reponse, '* Le ' .. fruit .. ' est un fruit.')
    end
    
    -- Animal    
    if animal != nil and animal != '' then
        table.insert(reponse, '* Le ' .. animal .. ' est un animal.')
    end
    
    return table.concat(reponse, "\n")
end
  
return a

Un paramètre non défini vaut nil. J'ai ajouté une condition si le paramètre est donné mais vide (''). J'ai aussi ajouté le table.insert/table.concat que j'utilise quand il y a plusieurs choses à écrire en liste, mais c'est autre chose. — Dakdada (discuter) 18 août 2013 à 00:17 (CEST)

Ça ne semble pas marcher : si je copie ça et que j'essaye d'enregistrer ça me dit "Erreur de script : Erreur Lua à la ligne 11: 'then' expected near '!'."

Si je remplace les "!=" par des "~=", je peux enregistrer mais ça me fait des erreurs de script, idem si je remplace les "and" par des "or"...

De plus, "return table.concat(reponse, "\n")" va sauter une ligne entre chaque expression de la liste, non ?

J'ai recopié ce code dans Module:Utilisateur:SyntaxTerror/Test, vous pouvez essayer là-bas (le modèle de test est Utilisateur:SyntaxTerror/Brouillon/Modèle). — Şÿℵדαχ₮ɘɼɾ๏ʁ ^{You talkin' to me?} 18 août 2013 à 01:43 (CEST)

Oui pour le != c'est une erreur (je ne me rappelle jamais qu'il faut écrire ~=). Sinon c'est bien and. Le problème était dans l'invocation, là marche.

La concaténation avec \n saute une ligne entre chaque élément oui (mais on peut mettre ce qu'on veut). — Dakdada (discuter) 18 août 2013 à 02:10 (CEST)

Pour la table reponse, on peut plus simplement faire :

reponse {'* Le ' .. fruit .. ' est un fruit.'}

non ? (cette phrase apparaissant forcément de toute façon) — Şÿℵדαχ₮ɘɼɾ๏ʁ ^{You talkin' to me?} 18 août 2013 à 02:56 (CEST)

Je ne vais pas pouvoir faire exactement comme ça, en tous cas merci, ça m'a permis de faire marcher mon module. — Şÿℵדαχ₮ɘɼɾ๏ʁ ^{You talkin' to me?} 18 août 2013 à 05:47 (CEST) On passe à la suite dans le message suivant !

@SyntaxTerror : on peut écrire {{Truc|animal=kiwi}}. Même si en principe "fruit" doit être toujours rempli, il faut bien le le vérifier, sous peine d'erreur. — Dakdada (discuter) 18 août 2013 à 16:48 (CEST)

Pour le module que je suis en train de créer ça ne pose pas de problème, c'est un module pour remplacer le code du modèle:Traduction/Référence. D'ailleurs, il est (presque) fini et on peut l'admirer ici : module:Utilisateur:SyntaxTerror/2. Merci pour ton aide qui m'a ouvert des pistes. — Şÿℵדαχ₮ɘɼɾ๏ʁ ^{You talkin' to me?} 18 août 2013 à 17:43 (CEST)

Au fait, à propos des vérifications : ce serait plus lisible de faire des tableaux que des listes. — Dakdada (discuter) 19 août 2013 à 11:24 (CEST)

Comment invoquer la fonction d'un autre module dans un module ?

Avec « require » on peut charger un module dans un autre, mais comment faire pour charger seulement une fonction d'un autre module ?

En clair, je veux utiliser la fonction « indicationMultilingue » du Module:Langue dans un autre module. Comment faire avec par exemple comme paramètres « en » et « de » ? (les paramètres n'ont pas de nom, cette fonction est utilisée par le Modèle:Mul et {{mul|en|de}} donne (en + de) )

— Şÿℵדαχ₮ɘɼɾ๏ʁ ^{You talkin' to me?} 18 août 2013 à 05:47 (CEST)

À ma connaissance il n'est pas possible de ne charger qu'une fonction d'un module.

Donc soit tu recopie la fonction, soit tu charge tout le module. La deuxième solution est conseillée sauf cas de fonction très simple : ce n'est pas un module de 14 ko (non compilé) qui va poser problème. Surtout si ton module n'est utilisé qu'une fois par page.

Zebulon84 (discuter) 18 août 2013 à 10:06 (CEST)

C'était pour sauver deux lignes, si je recopie le modèle ça en rajoute plus que ça n'en enlève. — Şÿℵדαχ₮ɘɼɾ๏ʁ ^{You talkin' to me?} 18 août 2013 à 10:30 (CEST)

module drapeau ?

Bonjour,

J'ai crée Module:Drapeau qui doit remplacer {{Drapeau2}} et autres flagicon. A priori, grace au lua, il devrait être beaucoup moins dispendieux. Il me reste à intégrer la gestion des erreur mais ça me semble complet.

Tant que je suis chaud, voyez vous des optimisations? C'est juste histoire de ne pas oublier un paramètre et se repalucher les 200 pays -- Xfigpower (pssst) 20 août 2013 à 20:10 (CEST)

Oui, voilà quelques commentaires : les listes Module:Drapeau/Data et Module:Drapeau/Image devraient être chargées avec mw.load.data() pour garder ces tables en cache, ce qui serait crucial si leur contenu est important et que le modèle est utilisé plusieurs fois par page. Mettre domainelist, genre et jo dans des pages séparées (ou une seule, ensemble) permettrait également de les charger en cache. J'ai l'impression qu'il manque aussi des local quand les variables sont créées. Il y a une fonction mw.text.trim() pour remplacer match( '^%s*(.-)%s*$' ). Il manque aussi des commentaires (les lignes 303 et suite sont difficile à comprendre par exemple). — Dakdada (discuter) 20 août 2013 à 20:42 (CEST)

Voici mes quelques réflexions.

• Lorsque l'on voudra appeler cette fonction depuis un autre module, il serai intéressant de ne pas avoir a définir frame.args mais simplement frame.
• Je n'ai pas compris l'utilité de latinisé args[1] à args[10] puisque seul args[1] est utilisé par la suite.

fait

• Actuellement le paramètre {{{2}}} de drapeau2 est l'année.

fait

• Il serait probablement plus efficace de faire « local taille = args["taille"] or '20x15' », puis d'utiliser taille.

• Je n'avais pas encore réalisé que l'on pouvait appeler une fonction de string comme méthode d'une chaine : merci.
• Si domaine n'est pas dans la liste on a une « erreur de script »

fait

• lors du chargement des sous-modules, prévoir une gestion d'erreur au cas ou un contributeur fasse une bêtise lors de la modification. Vu l'utilisation massive de ce module en cas d'utilisation par drapeau2, il faut éviter les « erreur de script » sur 20% des pages Wikipédia, même pour quelques minutes.

fait

• _cletri devrait être systématique (comme pour Drapeau2).

fait

• style="display:none;">‍ est une horreur nécessaire uniquement s'il n'y a rien d'autre dans le span. Autant mettre le drapeau et son nom à l'intérieur. (encore une fois comme la modèle drapeau 2 actuel).

fait

• Comment seront mises à jour les bases de données ? Bot depuis le système country ? depuis WikiData ? Parce-que ça risque d'être assez illisible par le contributeur wikipédia.
  • Si c'est un bot, pourquoi avoir deux bases ?
  • Si ce sont les contributeurs, des noms plus parlant que « flag000100 » serait peu-être préférable. Et éviter les « $name » que l'on risque de retrouver dans la base de donnée d'un autre module qui n'est pas prévu pour récupérer les données d'un autre élément de cette façon.

    fait

beaucoup des données aurait pu être récupérer de wikidata. Aujourd'hui, seuls libellé et pays pourrait être rapatrié. C'est dans ce but que les tableaux sont indexés par l'identifiant wikidata. Mon but est de pouvoir installer une gestion des drapeaux sans avoir à créer 200 sous modèles. La structure la plus imbittable est celle de la récupération des drapeaux.

• Quelques espaces autour des « = » est des « .. » seraient les bienvenus.
• printCible n'affiche pas args["cible"] mais le pays, c'est un peu perturbant.

fait

Zebulon84 (discuter) 21 août 2013 à 02:59 (CEST)

mw.load.data() ne marche pas. Si quelqu'un sait faire? -- Xfigpower (pssst) 21 août 2013 à 10:08 (CEST)

Pardon, c'est mw.loadData(). — Dakdada (discuter) 21 août 2013 à 10:51 (CEST)

je ne connaissais pas la différence donc merci--Xfigpower (pssst) 21 août 2013 à 12:12 (CEST)

Juste une idée sur le temps CPU d’utilisation: pour une inclusion de 500 flagicon France,

• {{pays}} : 4.996 secondes
• {{drapeau2}} :30.394 secondes
• module:drapeau :4.264 secondes

Comment savoir si une expression se trouve ou non dans une table ?

J'ai une table de codes de langue des Wikipédias et je veux faire un test pour savoir s'ils correspondent aux paramètres « lang1 » et « lang2 ».

J'ai trouvé le moyen, mais ça me semble un peu lourd, existe-il une solution plus économique que cela :

local wikilist = { 'aa' , 'ab', 'ace', 'af', 'ak', 'als', 'am', 'an', 'ang', 'ar', 'arc', 'arz', 'as', 'ast', 'av', 'ay', 'az', 'ba', 'bar', 'bat-smg', 'bcl', 'be', 'ne-x-old', 'bg', 'bh', 'bi', 'bjn', 'bm', 'bn', 'bo', 'bpy', 'br', 'bs', 'bug', 'bxr', 'ca', 'bck-zam', 'cadeau', 'ce', 'ceb', 'ch', 'cho', 'chr', 'chy', 'ckb', 'co', 'cr', 'crh', 'cs', 'csb', 'cu', 'cv', 'da', 'de', 'diq', 'dsb', 'dv', 'dz', 'ee', 'el', 'eml', 'en', 'eo', 'es', 'et', 'eu', 'ext', 'fa', 'ff', 'fi', 'fiu-vro', 'fj', 'fo', 'fr', 'frp', 'frr', 'fur', 'fy', 'ga', 'gag', 'gan', 'gd', 'gl', 'glk', 'gn', 'got', 'gu', 'gv', 'ha', 'hak', 'haw', 'he', 'hi', 'hif', 'ho', 'hr', 'hsb', 'ht', 'hu', 'hy', 'hz', 'ia', 'id', 'ie', 'ig', 'ii', 'ik', 'ilo', 'io', 'is', 'it', 'iu', 'ja', 'jbo', 'jv', 'ka', 'kaa', 'kab', 'kbd', 'kg', 'ki', 'kj', 'kk', 'kl', 'km', 'kn', 'ko', 'koi', 'kr', 'krc', 'ks', 'ksh', 'ku', 'kv', 'kw', 'ky', 'la', 'lad', 'lb', 'lbe', 'lez', 'lg', 'li', 'lij', 'lmo', 'ln', 'lo', 'lt', 'ltg', 'lv', 'map-bms', 'mdf', 'mg', 'mh', 'mhr', 'mi', 'min', 'mk', 'ml', 'mn', 'mo', 'mr', 'mrj', 'ms', 'mt', 'mus', 'mwl', 'my', 'myv', 'mzn', 'na', 'nah', 'nap', 'nds', 'nds-nl', 'ne', 'new', 'ng', 'nl', 'nn', 'no', 'nov', 'nrm', 'nso', 'nv', 'ny', 'oc', 'om', 'or', 'os', 'pa', 'pag', 'pam', 'pap', 'pcd', 'pdc', 'pfl', 'pi', 'pih', 'pl', 'pms', 'pnb', 'pnt', 'ps', 'pt', 'qu', 'rm', 'rmy', 'rn', 'ro', 'roa-rup', 'roa-tara', 'ru', 'rue', 'rw', 'sa', 'sah', 'sc', 'scn', 'sco', 'sd', 'se', 'sg', 'sh', 'si', 'simple', 'sk', 'sl', 'sm', 'sn', 'so', 'sq', 'sr', 'srn', 'ss', 'st', 'stq', 'su', 'sv', 'sw', 'szl', ' ta', 'te', 'tet', 'tg', 'th', 'ti', 'tk', 'tl', 'tn', 'to', 'tpi', 'tr', 'ts', 'tt', 'tum', 'tw', 'ty', 'tyv', 'udm', 'ug', 'uk', 'ur', 'uz', 've', 'vec', 'vep', 'vi', 'vls', 'vo', 'wa', 'war', 'wo', 'wuu', 'xal', 'xh', 'xmf', 'yi', 'yo', 'za', 'zea', 'zh', 'zh-classical', 'zh-min-nan', 'zh-yue', 'zu' }

function Test.test(frame)
    local args = frame:getParent().args
    local lang1 = args[1]
    local lang2 = args[2]
    local langinvalide1 = '* <span style="color:red">Erreur dans {{Traduction/Référence}} : le code de langue ' .. lang1 .. ' ne correspond à aucun Wikipédia.</span>'
    local langinvalide2 = '* <span style="color:red">Erreur dans {{Traduction/Référence}} : le code de langue ' .. lang2 .. ' ne correspond à aucun Wikipédia.</span>'

    local x = 0
    repeat       -- teste toutes les clefs valides de la liste
        x = x+1
        if lang1 == wikilist [ x ] then
            langinvalide1 = ''
        end
        if lang2 == wikilist [ x ] then
            langinvalide2 = ''
        end
    until wikilist [ x ] == nil
    if langinvalide1 ~='' or langinvalide2 ~= '' then
        return langinvalide1 .. '\n' .. langinvalide2
    end

    return lang1 .. ', ' .. lang2
end

On peut aussi mettre tous les codes de langues en clefs de la table et faire un test pour voir si ces clefs existent, un peu comme ça :

local wikilist = { 'aa' = 'oui' , 'ab' = 'oui', 'ace' = 'oui', 'af' = 'oui', 'ak' = 'oui' -- etc.

function Test.test(frame)
    local args = frame:getParent().args
    local lang1 = args[1]
    local lang2 = args[2]
    local langinvalide1 = '* <span style="color:red">Erreur dans {{Traduction/Référence}} : le code de langue ' .. lang1 .. ' ne correspond à aucun Wikipédia.</span>'
    local langinvalide2 = '* <span style="color:red">Erreur dans {{Traduction/Référence}} : le code de langue ' .. lang2 .. ' ne correspond à aucun Wikipédia.</span>'

    if wikilist [ lang1 ] then
        langinvalide1 = ''
    end
    if wikilist [ lang2 ] then
        langinvalide2 = ''
    end
    if langinvalide1 ~='' or langinvalide2 ~= '' then
        return langinvalide1 .. '\n' .. langinvalide2
    end

    return lang1 .. ', ' .. lang2
end

La seconde solution est peut être meilleure car il n'y a pas besoin de faire un repeat sur toutes les clefs de la table, mais en même temps il y a plus de caractères (toutes les clefs et les données correspondantes de la table).

Vous pouvez aller faire des tests sur le Module:Utilisateur:SyntaxTerror/Test, le modèle montant les résultats est Utilisateur:SyntaxTerror/Brouillon/Modèle.

Merci — Şÿℵדαχ₮ɘɼɾ๏ʁ ^{You talkin' to me?} 20 août 2013 à 21:05 (CEST)

Dans le manuel de Scribunto : mw:Extension:Scribunto/Lua_reference_manual

Il existe des fonctions pour savoir si le langage existe ou non dans MediaWiki :

• mw.language.isKnownLanguageTag( code ) -- oui si le code est celui d'une langue connue de MediaWiki.
• mw.language.isSupportedLanguage( code ) -- oui si le code est celui d'une langue utilisée par MediaWiki.

C'est mieux qu'une table figée qui ne s'adaptera pas aux évolutions de MediaWiki. --Rical (discuter) 21 août 2013 à 00:23 (CEST)

---

Certainement préférable, mais il faudra toujours gérer les cas ou wiki utilise un code de langue non valide.

Sinon pour répondre à la question dans l'absolu, indépendamment de ce cas, je ne connais pas de fonction intégrée simple type
if arg in list then ...
Il faut donc bricoler.

Dans le cas de ta deuxième solution il vaut mieux utiliser directement le type booléen :
local wikilist = { 'aa' = true , 'ab' = true , 'ace' = true , 'af' = true , 'ak' = true -- etc.
Ça prend presque autant de place à écrire, mais certainement moins une fois compilé. Cette solution (booléen ou non) est a utiliser si tu teste souvent ta liste car les algorithmes de recherche sur index sont certainement optimisés pour ne pas tout tester.

Sinon pour la première solution, je ferai plutôt :

local wikilist = { 'en' , 'de', 'es', 'it', 'fr', 'aa', 'ab', -- etc.
    }
function Test.test(frame)
    local args = frame:getParent().args
    local lang1 = args[1]
    local lang2 = args[2]
    local langInvalide = '* <span style="color:red">Erreur dans {{Traduction/Référence}} : le code de langue %s ne correspond à aucun Wikipédia.</span>'
    local function inList( list, arg )
        for i, v in ipairs( list) do
            if arg == v then
                return ''
            end
        end
        return string.format( langInvalide , arg or '' )
    end
 
    langInvalide = inList( wikilist, lang1 ) .. '\n' .. inList( wikilist, lang2 )
    if langInvalide == '\n' then
        return lang1 .. ', ' .. lang2
    else
        return langInvalide 
    end
end

Si ta liste est trié avec les valeurs de lang1 / lang2 les plus fréquentes en premier, tu ne parcours souvent qu'un petit bout de ta liste.

Zebulon84 (discuter) 21 août 2013 à 00:30 (CEST)

Ça dépend aussi de ce qu'on veut faire avec la liste, et si la liste est longue. Si on va utiliser de nombreuses fois la fonction/le modèle dans une page, sans forcément préjuger de la fréquence des langues, alors il est raisonnable de mettre le tout dans une table indexée (avec clés donc) et la charger en cache avec mw.load.data() mw.loadData(). — Dakdada (discuter) 21 août 2013 à 10:47 (CEST)

@Rical : j'utilise déjà la liste du module:Langue/Data en ce moment pour savoir si un code est invalide ou non, mais comme le dit Zebulon, le problème est pour les codes des wikipédias qui ne correspondent pas au code IETF. Là je résous le problème simplement, j'ai juste besoin de savoir si le code qui va être utilisé dans l'url correspond à un Wikipédia existant. Aussi, le problème ne se pose que pour un très petit nombre d'articles.

@Zebulon84 : j'ai testé ta version mais ça me fait une erreur de script. Je vais prendre l'idée de classer les langues les plus utilisées en premier, mais je garde mon code pour l'instant (je ne comprends pas trop le tien ). On pourra toujours l'améliorer si mon module est accepté pour remplacer le code de {{Traduction/Référence}}.

@Dakdada : c'est pour être utilisé dans le modèle:Traduction/Référence, c'est à dire un modèle utilisé le plus souvent une seule fois par article et au grand maximum quatre fois (c'est très rare). Je voulais une solution simplissime mais elle ne semble pas exister.

Merci de votre aide à tous les trois en tous cas. — Şÿℵדαχ₮ɘɼɾ๏ʁ ^{You talkin' to me?} 21 août 2013 à 11:02 (CEST)

Ma faute, j'ai voulu aller trop vite, et je n'ai pas testé → variable qui change de nom dans le code. J'ai corrigé ma proposition.

@ rical : mw.language.isSupportedLanguage('gsw') = true et mw.language.isSupportedLanguage('als') = false. Pourtant gsw.wiki.x.io n'existe pas et als.wiki.x.io existe. Certes la langue de ce dernier est 'gsw', mais c'est justement ce qui pose problème.

Zebulon84 (discuter) 21 août 2013 à 12:01 (CEST)

En terme de performance il est très probable qu'il soit plus rapide de tester l'existence d'une entrée (tableau [ lang ] vrai) que de parcourir la table car a priori (je n'ai pas lu le code C de Lua mais c'est logique) les tables sont des hashs et tester l'existence d'un élément est probablement en temps constant. On évite de plus la gestion d'une boucle.

La notation ["code-langue"] = true est plus longue en code Lua mais je ne pense pas qu'elle occupe plus de mémoire que l'autre version. Cordialement, Hexasoft (discuter) 26 août 2013 à 16:58 (CEST)