Discussion Projet:Infobox/Lua/Archives 2014

Tableau de bord

Version	Brique	Remarques	Avancement
Catégorie:Modèle de brique d'infobox V2
	Modèle:Infobox/Début Modèle:Infobox/Fin
		Gérés par le module.	Inutile
	Modèle:Infobox/Éphéméride
		à faire
	Modèle:Infobox/Géolocalisation multiple
		à faire
	Modèle:Infobox/Image Modèle:Infobox/Image double Modèle:Infobox/Image optionnelle
		Brique Lua : type = 'images'
		Catégories d'erreur (voir discussion) Catégorie:Erreur d'Infobox/Image trop grande Catégorie:Article à illustrer
	Modèle:Infobox/Ligne Modèle:Infobox/Ligne optionnelle
		Brique Lua : type = 'text'
	Modèle:Infobox/Ligne donnée Modèle:Infobox/Ligne donnée valeurs multiples Modèle:Infobox/Ligne donnée valeurs multiples optionnelle
		Brique Lua : type = 'text'
	Modèle:Infobox/Ligne mixte Modèle:Infobox/Ligne mixte optionnelle Modèle:Infobox/Ligne mixte valeurs multiples Modèle:Infobox/Ligne mixte valeurs multiples optionnelle
		Brique Lua : type = 'mixed'
	Modèle:Infobox/Ligne mixte wikidata optionnelle
		on peut définir une valeur Wikidata à retourner par défaut pour n'importe quel type de données	Inutile
	Modèle:Infobox/Ligne mixte densité optionnelle
		à faire
	Modèle:Infobox/Ligne mixte latitude longitude Modèle:Infobox/Ligne mixte latitude longitude optionnelle
		L'affichage des cartes n'est pas encore au point.
		Catégories d'erreur (voir discussion) Catégorie:Article à ne pas géolocaliser Catégorie:Page géolocalisée par Wikidata Catégorie:Page géolocalisable sans coordonnées paramétrées
	Modèle:Infobox/Ligne mixte site web optionnelle
		appeler Module:Weblink ou la fonction "common.weblink"	(à documenter)
	Modèle:Infobox/Notice
		Notice par défaut en pied de page (à rendre customisable ?)
	Modèle:Infobox/Séparateur Modèle:Infobox/Séparateur optionnel Modèle:Infobox/Séparateur optionnel non
		?
	Modèle:Infobox/Sous-titre Modèle:Infobox/Sous-titre optionnel
		Brique Lua : type = 'table'
	Modèle:Infobox/Succession
		à faire
	Modèle:Infobox/Titre Modèle:Infobox/Titre avec icône
		Brique Lua : type = 'title'
Catégorie:Modèle infobox V3 briques
	Modèle:Infobox V3/Début Modèle:Infobox V3/Fin
		Brique Lua : type = 'title'
	Modèle:Infobox V3/Image
		Brique Lua : type = 'images'
	Modèle:Infobox V3/Navigateur
		à faire
	Modèle:Infobox V3/Séparateur
		?
	Modèle:Infobox V3/Tableau début Modèle:Infobox V3/Tableau fin
		Brique Lua : type = 'table'
	Modèle:Infobox V3/Tableau Ligne données
		Brique Lua : type = 'text'
	Modèle:Infobox V3/Tableau Ligne entêtes
		?
	Modèle:Infobox V3/Tableau Ligne mixte
		Brique Lua : type = 'mixed'
	Modèle:Infobox V3/Titre Bloc
		Brique Lua : type = 'table'
Divers
	Formulaires d'Infobox
		voir discussion
		Plusieurs noms pour un même paramètre : possible avec ValidTextArg
	Fusion module:Infobox avec module:InfoboxBuilder
		voir discussion

Plusieurs noms pour un même paramètre

Comment peut-on programmer le cas des modèles qui pour des raisons historiques ou d'harmonisation, ont des paramètres acceptant plusieurs orthographes ? Autrement dit, comment faire un {{{NomParametre|{{{nom paramètre|}}}}}} ? --FDo64 (discuter) 31 janvier 2014 à 12:14 (CET)

Il me semble que le cas le plus fréquent est avec majuscule ou sans majuscule, et si c'est nécessaire, on pourrait rendre le module indifférent aux majuscules dans la paramètres. Pour le reste, je pense que ce serait mieux d'harmoniser les noms des paramètres avant, et idéalement de définir des noms de paramètres "transinfobox". Par exemple, les paramètres appelés "latitude" et "longitude" pourraient avoir le même comportement dans différents types d'infobox. Avoir les mêmes noms de paramètres sur différentes infobox permettrait de décloissonner les choses et au final d'apporter plus de souplesse dans les informations que l'on veut afficher. Par exemple, si deux infobox différentes peuvent convenir à un même article, on pourrait faire une sorte de fusion des deux plutôt que d'afficher deux infobox séparées comme c'est le cas actuellement. --Zolo (discuter) 1 février 2014 à 09:01 (CET)

Merci, deux remarques :

1. Il n'est pas question ici de débattre des conventions de nommage des paramètres, tout est dit ici : Projet:Modèle/Harmonisation#Nom des paramètres. Par ailleurs, les modèles évolueront après la migration et les noms de paramètre pourront changer. Il faut donc prévoir ce cas.
2. La question autrement posée est la résolution de ce cas de figure.
   • Comment traduire {{{alternative|{{{légende|Image de la page : {{PAGENAME}} }}} }}}.
   • Je propose, par exemple, la syntaxe suivante : ["alternative"|"légende"|Image de la page : {{PAGENAME}}].

--FDo64 (discuter) 1 février 2014 à 10:17 (CET)

En fait, on a déjà des solutions avec le module actuel, en l'occurrence

function( frame ) return frame.args['légende'] or 'image de la page :' .. mw.title.getCurrentTitle end end

. C'est un peu plus compliqué, mais dans ce cas précis, je ne suis pas sûr qu'on puisse faire plus simple. --Zolo (discuter) 1 février 2014 à 15:55 (CET) corrigé le 2 février

La fonction ValidTextArg de module:Outils permet de faire ça. Vous pouvez regarder comment elle a été utilisé dans le module Module:Biblio/Lien web. Hunsu (discuter) 1 février 2014 à 21:38 (CET)

Oui on pourrait utiliser quelque chose comme ça en autorisant à mettre les paramètres sous forme de table en plus d'autoriser les fonction ou chaîne.

Merci pour le lien vers Projet:Modèle/Harmonisation#Nom des paramètres, mais Lua ouvre de nouveaux horizons pour les infobox, et je pense que ça pourrait justifier une révision de nos politiques.

— Le message qui précède, non signé, a été déposé par Zolo (discuter), le 2 février 2014 à 05:44

@Zolo : Je ne vois pas le rapport entre Lua et les convention de nommage des paramètres. Par ailleurs, ces conventions s'appliquent à tous les modèles et ne sont pas spécifiques aux Infobox. Mais c'est un autre débat sans rapport avec cette discussion.

Pour ce qui est de la solution que tu proposes, elle ne répond pas à ma question, elle ne répond qu'à mon exemple. J'aurais peut-être du utiliser des noms de paramètre tutu, titi, toto...

@Hunsu : ta proposition répond à ma question. Merci !

--FDo64 (discuter) 2 février 2014 à 10:30 (CET)

Le rapport entre Lua et les noms de paramètres est que, comme évoqué plus bas par Snipre, on pourrait utiliser Lua pour décloissoner les infobox, et cela peut diffcilement se faire si les noms de paramètres ne sont pas harmonisés.

Comme j'ai dit, dans le cas titi, toto on peut mettre les argument sous forme de table et utiliser la fonction citée par Hunsu (ou la récréer dans Module:Infobox) mais ça ne marche pas pour l'exemple que tu donnais, donc je pense que ça vaut de mentioner une solution qui peut être appliquée aux cas un peu délicats (et aux cas simples aussi bien-sûr, si on veut). --Zolo (discuter) 2 février 2014 à 10:58 (CET)

Formulaires d'Infobox

Dans un monde idéal, le code des "Module:InfoboxBuilder/nom de l'infobox" serait généré automatiquement à partir d'un simple formulaire de saisie alimenté par les modélistes. Il serait ensuite stocké dans "Module:InfoboxBuilder/nom de l'infobox/Formulaire".

Ainsi, à chaque évolution majeure de InfoboxBuilder, un bot irait re-générer tous les Module:InfoboxBuilder/nom de l'infobox.

Je propose la structure suivantes dans laquelle j'ai indiqué les paramètres des briques élémentaires :

type	contenu	condition	style	paramètres
title	text		style	class ; params
text	text		style	class
images	images ; property
	legend			legendParams
table	text		styleCaption	class ; params
	rows		style
mixed	label		styleHeader	params ; hidden
	value ; property		styleValue	weblink
doubled	label		styleHeader	params ; hidden
	value ; property		styleValue	weblink

Pour les tables, le principe est le suivant : la première ligne concerne le header, les lignes suivantes les colonnes ou les lignes.

Si je prends l'exemple de l'{{Infobox Ambassadeur}}, cela donnerait la page Module:InfoboxBuilder/Ambassadeur/Formulaire du Module:InfoboxBuilder/Ambassadeur :

type	contenu	condition	style	paramètres
title	[nom|{{PAGENAME}}]		background-color:#4682B4	entete defaut
images	["image"|property:P18]
	légende
table	"ambassadeur"		background-color:#4682B4
text	"ambassade 1"		text-align:center;background-color:#B0C4DE
text	Actuellement en fonction	"depuis le 1"	text-align:center
text	"début 1" - "fin 1"	"début 1"	text-align:center
mixed	Prédécesseur
	"prédécesseur 1"
mixed	Successeur
	"successeur 1"
table	Biographie		text-align:center;background-color:#4682B4
mixed	Nom de naissance
	"nom de naissance"
mixed	Surnom
	"surnom"
mixed	Date de naissance
	["date de naissance"|property:P569]
mixed	Lieu de naissance
	["lieu de naissance"|property:P19]
mixed	Origine
	"origine"
mixed	Date de décès
	["date de décès"|property:P570]
mixed	Lieu de décès
	["lieu de décès"|property:P20]
mixed	Nationalité
	["nationalité"|property:P27]
mixed	Conjoint
	"conjoint"
mixed	Enfants
	"enfants"

Remarque : je n'ai fait figurer que "ambassade 1", il y a jusqu'à "ambassade 9".

Cela reste très perfectible, bien évidement ! --FDo64 (discuter) 1 février 2014 à 11:55 (CET)

 FDo64 : Avec ton idée de formulaire, tu compliques encore la chose: il ne devrait y avoir qu'une page pour l'infobox, et cette page c'est infoboxBuilder/Nom de l'infobox. Je comprends le besoin d'avoir un code simple, mais plus on multiplie les couche de code, plus la gestion devient compliquée. Snipre (discuter) 1 février 2014 à 20:58 (CET)

Pour être très clair, je suis totalement apte à écrire des "Module:InfoboxBuilder/nom de l'infobox" tels que vous les avez conçus. Il n'empêche que ce ne sera peut-être pas le cas de tous les modélistes et encore moins de ceux qui modifient les Infobox de façon très ponctuelle. Nous en sommes aujourd'hui au premier prototype et c'est donc le moment de se poser les bonnes questions, comme le fait Hlm Z ci-dessous sur d'autres aspects. On peut encore remettre tout en question, même s'il fait réécrire ce prototype 10 fois. L'idée, que ce soit sous la forme d'un formulaire ou tout autre chose, c'est que les modélistes ne s'occupent que du paramétrage. Les aspects programmation doivent être réservés aux programmeurs. Je suis sûr que ce que je propose est faisable techniquement. Il faut juste que quelqu'un s'y mette.

Cela révolutionnera les infobox et permettra d'effacer toutes les critiques aux briques actuelle.

Une critique néanmoins aux "Module:InfoboxBuilder/nom de l'infobox" : si elles doivent être faites "à la main", plein de gens y toucheront, armés de bonnes intentions, feront des erreurs et deviendront des usines à bugs. C'est pour cela que ce code doit être généré, quitte à compliquer la programmation, si cela doit simplifier la vie des modélistes et la maintenance des modèles.

Le travail que vous avez déjà effectué est très prometteur et je cherche juste la bonne méthode pour pouvoir nous lancer prochainement dans une migration des Infobox actuelles, en recherchant les points bloquants et en levant les freins qu'on ne manquera pas de rencontrer.

Tout est donc discutable. Discutons !

--FDo64 (discuter) 1 février 2014 à 21:30 (CET)

Pas de soucis, je ne défends pas bec et ongles le prototype actuel, c'est juste que je n'aime pas ces interfaces qui empêchent d'avoir une vision claire de ce qui se passe. Oui, tout le monde n'est pas un génie de la programmation, mais je pense que tous ceux qui veulent toucher aux infobox doivent se plonger dans le code un minimum. Je ne dis pas cela pour obliger ces contributeurs à s'impliquer, je dis cela parce que lua offre davantage de possibilités et qu'il est faux de limiter les options à ce que l'on connaît aujourd'hui. Bref, une interface limitée, c'est autant de limites ajoutées aux possibilités de lua.

Concernant la critique, je suis désolé, mais la structure proposée ne change en rien aux modèles actuels: module:InfoboxBuilder/Composé chimique correspond exactement à Modèle:Infobox Chimie. La seule différence, c'est que lua est visible, contrairement aux modèles où il faut passer en édition pour voir le code. Or je ne crois pas que l'on ait beaucoup de problèmes avec les modèles. Si tu veux vraiment protéger le code, alors il faut mettre le module en semi-protection voire en protection complète. Snipre (discuter) 2 février 2014 à 00:12 (CET)

Remise en question de la structure

Je ne suis pas tellement d'accord avec la structure proposée (je parle ici des InfoboxBuilder). En effet, pour une seule infobox, on se retrouvera avec plusieurs sous-pages. De plus, même si le Lua script est un langage de haut niveau, cette structure rend la création d'infobox beaucoup plus difficile qu'auparavant. Sur wpen, on remarque que seul le méta-modèle est passé au Lua, sans aucune répercussion sur le contenu des infobox.

Proposition

Voici une éventuelle proposition sans répercussion majeure :

• L'implémentation d'un module qui permet de définir des infobox directement dans le contenu du modèle (je donne un exemple ici).
• Il existe donc un modèle de même nom contenant l'appel de ce même module.
• Une infobox qui appelle le modèle précédent et qui instancie une infobox tout en gardant les caractéristiques des infobox actuelles. Une syntaxe simpliste est utilisée pour omettre au maximum le ParserFunctions.
• Par exemple, l'entité « , » permet l'orthographe de plusieurs mots : {{{paramètre1| {{{paramètre2|}}} }}} est équivalent à paramètre1, paramètre2 (voir exemple).

La conception d'un parser sera donc nécessaire, mais cette structure est tout à fait concevable – elle est même beaucoup plus simple que le ParserFunctions.

Exemple

Dans cette exemple, l'héritage est respecté :

1. le module est appelé Module:Infobox
2. le modèle est appelé Modèle:Infobox
3. l'infobox est appelé Modèle:Infobox Lorem
4. Lorem ipsum la page d'article.

Le modèle contient l'appel du Module:Infobox :

{{#invoke:Infobox|infobox}}

L'infobox contient l'appel du Modèle:Infobox :

{{Infobox
| titre = nom <!-- correspond à {{{nom|}}} sans ParserFunctions) -->

| entête1 = Origine
| donnée1 = origine <!-- correspond à {{{origine|}}} sans ParserFunctions) -->

| entête2 = Valeur sémantique
| donnée2 = valeur, sens <!-- correspond à {{{origine|{{{sens|}}}}}} sans ParserFunctions) -->
}}

La page Lorem ipsum contient l'appel du Modèle:Infobox Lorem :

{{Infobox Lorem
| nom     = Lorem ipsum
| origine = Ouvrage de [[Cicéron]]
| valeur  = Aucun <!-- équivalent : |sens=Aucun -->
}}

À noter qu'une discussion similaire est présente sur le projet Scribunto. Dans tous les cas, si modification il y a, une profonde discussion avec la communauté sera nécessaire. Cordialement, Hlm Z. (discuter) 1 février 2014 à 15:02 (CET)

Je dois avouer que je ne comprends très bien ce que tu proposes de nouveau, à part, je crois de renommer Module:InfoboxBuilder/Philosophe en Module:Infobox Philosophe.

On ne se retrouve pas vraiment avec "plusieurs sous pages" dans la solution envisagée prédécemment. On a une page Lua pour construire l'infobox et un appel vers cette page Lua dans l'espage de nom modèle, mais cette dernière ne fait qu'une demi-ligne, et constitue un appel au module indispensable si on veut éviter d'avoir des #invoke: dans l'espage de nom principal. en.wikipedia n'utilise Lua que dans Module:Infobox et fabrique les différents modèles d'infobox en Wikitexte. Ca fonctionne, mais ça me parait manquer l'essentiel des bénéfices du Lua. --Zolo (discuter) 1 février 2014 à 16:07 (CET)

Non, en suivant ta logique, je renomme plutôt Module:InfoboxBuilder/Philosophe en Modèle:Infobox Philosophe (qui existe déjà, ce qui est logique). Le Module:Infobox s'occupera de gérer les paramètres de Modèle:Infobox Philosophe (rien à voir avec la syntaxe actuelle de wpen). Cordialement, Hlm Z. (discuter) 1 février 2014 à 16:18 (CET)

Euh, on ne peut pas avoir de code Lua hors de l'espace module. --Zolo (discuter) 1 février 2014 à 16:39 (CET)

Je ne suis pas un spécialiste, mais je crains que mélanger deux langages pour générer une infobox soit plus gourmand en ressources. Avec la méthode InfoboxBuilder, tout est en Lua.

 Hlm Z. : Je ne comprends pas ta remarque concernant plusieurs sous-pages pour une infobox: il n'y a une sous-page pour chaque infobox, ensuite il y a module:InfoboxBuilder qui formate les données et ensuite module:Infobox qui construit l'infobox. Les sous-pages module:InfoboxBuilder/Helpers et module:InfoboxBuilder/common queries sont des groupes de fonction du module:InfoboxBuilder qui peuvent être intégrés dans module:InfoboxBuilder si on veut éviter de disperser les fonctions entre plusieurs pages.

Mais je reconnais que la situation actuelle est assez dispersée et que l'on pourrait condenser le tout dans un seul module. Je l'avais déjà proposé, mais plusieurs personnes voulaient garder le module:Infobox distinct d'infoboxBuilder pour pouvoir l'utiliser de manière directe si besoin. Snipre (discuter) 1 février 2014 à 20:40 (CET)

Fusion module:Infobox avec module:InfoboxBuilder

C'est une vision personnelle de la programmation, mais pour moi, une fonction ou un module doit avoir une entrée et une sortie. Or ce n'est pas tout à fait le cas avec les 2 modules cités: en principe, module:Infobox devrait être indépendant, c.-à-d que si on lui fournit toutes les infos nécessaires, il doit être capable de produire l'infobox. or ce n'est pas le cas, car actuellement module:infobox est dépendant du module:InfoboxBuilder. Il suffit de voir que c'est dans le code du module:InfoboxBuilder que se trouve la boucle qui passe tous les éléments de l'infobox en revue et qui appelle les différentes fonctions du module:Infobox en fonction des types d'éléments. A mon avis, il faut soit séparer davantages les 2 modules, module:InfoboxBuilder ne faisant que du pré-processing en préparant les données dans une unique table qui est ensuite passée au module:Infobox qui reçoit la table et sort le code de l'infobox, bref une entrée avec un table et une sortie avec du code, et non pas un aller retour entre les 2 modules, soit une fusion des 2 codes en 1 seul module. Cette dernière proposition peut sembler bizarre, car elle risque de conduire à un énorme module, mais je crois qu'en travaillant sur la simplification du code notamment en déterminant précisément les fonctions de base, on peut réduire la taille du code. Snipre (discuter) 2 février 2014 à 01:06 (CET)

Pas trop d'avis, plutôt pour sur le principe, mais je ne suis pas sûr de la marche à suivre. En fait, je me demande s'il ne faudrait pas se commencer par se débarasser de Module:InfoboxBuilder/Helpers. Module:InfoboxBuilder/Philosophe s'en passe quasiment, et ça n'allonge pas vraiment le texte. Je dirais même que supprimer un intermédiaire permet de mieux comprendre la logique.--Zolo (discuter) 2 février 2014 à 06:48 (CET)

Je n'ai pas l'intention de me plonger dans le code de ces deux modules, je n'interviens donc pas pour donner un avis technique, mais quand je lis « une entrée avec une table et une sortie avec du code », cela me plaît parce que ça semble rejoindre l'idée de « Formulaire » que j'ai exprimée. Mon objectif, c'est que le modéliste n'ait à renseigner que cette table et, de façon idéale, qu'il soit assisté par un écran de saisie avec des listes déroulantes, des cases à cocher, des contrôles de cohérence... --FDo64 (discuter) 2 février 2014 à 12:22 (CET)

Je me permet de rééditer cette discussion pour expliquer pourquoi j'ai différencié ces deux modules : Module:Infobox est là pour gérer l'affichage de l'infobox (i.e. créer un titre, une ligne de donnée avec telle en-tête et telle valeur) et Module:InfoboxBuilder est là pour pouvoir créer facilement des infobox à partir d'une table Lua avec support de Wikidata et autre choses sympas. L'idée est que la plus part des infobox utilisent simplement Module:InfoboxBuilder et que Module:Infobox ne soit là que pour les opérations "bas niveau" d'affichage réutilisable par des infobox "customisées". Peut être qu'un renommage de Module:Infobox en Module:InfoboxFormatter serait pertinent. Tpt (discuter) 3 mars 2014 à 22:15 (CET)

 Tpt :Pour avoir un peu bidouillé sur ces modules, je dis que la séparation si elle est logique du point de vue programmation, n'est pas vraie en réalité: j'ai customisé pasmal de bout de code de module:infobox à partir de structure définie dans module:InfoboxBuilder, si bien que module:infobox n'est plus un code indépendant et généraliste, mais une sous-structure de module:InfoboxBuilder et que ta vision d'un module:infobox pouvant être appelé de manière indépendante de module:InfoboxBuilder n'est pas vraie actuellement dans le code. Pour que module:infobox puisse jouer le rôle que tu lui prêtes, il faut définir des entrées et des sorties capables de gérer n'importe quel appel. A l'heure actuel, tu dois passer par module:InfoboxBuilder pour être sûr de formater correctement les entrées. Snipre (discuter) 4 mars 2014 à 22:17 (CET)

 Snipre et Tpt : : la libraire html de Lua permet de simplifier pas mal de choses. J'ai fait une nouvelle version sur Module:Infobox/Test qui fusionne module:Infobox et module:InfoboxBuilder, et qui permet de se passer facilement de Module:InfoboxBuilder/Helpers. Je peux faire le remplacement ? --Zolo (discuter) 8 mai 2014 à 07:41 (CEST)

Oui, je suis ok pour le remplacement. Tpt (discuter) 8 mai 2014 à 20:17 (CEST)

 Zolo : Si ton code fait ce que le code actuel fait, pas de problème pour moi. Snipre (discuter) 13 mai 2014 à 10:17 (CEST)

(mais peut-être qu'il ne vaut mieux pas effacer tout de suite Module:InfoboxBuilder. Il y a des parties de code qui pourraient encore servir.--Zolo (discuter) 24 mai 2014 à 12:37 (CEST)

Remaniement

J'ai un peu remanié Module:Infobox, et j'ai déployé les infobox Lua sur deux petits modèles : Modèle:Infobox Fort romain et Modèle:Infobox Panchen Lama

Pour les images, comme suggéré par user:FDo64, la fonction mainimage() catégorise dans Catégorie:Article à illustrer. mainmage('Article à illustrer Château') catégorise dans Catégorie:Article à illustrer Château. mainmage('Article à illustrer Château', 'foo.jpg') ajoute aussi 'foo.jpg' comme image par défaut. Pour signaler qu'un paramètre est intentionnellement vide, et donc pour désactiver l'appel à Wikidata et ne pas ajouter la catégorie de maintenance, on peut mettre "-". Les images de plus de 280 px de largeur sont également catégorisées. Je crois que la raison pour laquelle on ne catégorisait pas les images qui n'existent pas est que "ifexist" est une fonction "coûteuse". On a le même problème en Lua, mais si on veut être dépensier, c'est facile d'ajouter ça.

La géolocalisation fonctionne désormais. Si on veut ne veut pas de cartes de géolocalisation mais qu'on veut des coordonnées, on met "géolocalisation = non (ou "géolocalisation = -") et "coordonnées = oui". Si on ne veut que des coordonnées en titre, on met "coords en ligne = -" (ou inversement "coords en titre = -"). En revanche les cartes ne fonctionnent pour l'instant que pour la France et la Gironde. Pour les autres il faudrait convertir tous les modèles de géolocalisation en Lua (il y en a un bon petit paquet...). A la limite, on pourrait, en faire par défaut un appel au modèle non-Lua le temps de la migration.

Voilà, il reste certainement pas mal de réglages à faire, mais c'est peut-être plus facile si on commence à vraiment utiliser le module. Il me semble qu'il y a déjà plein de petits modèles dans Utilisateur:Underlying lk/List of infoboxes qu'on pourrait convertir. --Zolo (discuter) 25 septembre 2014 à 12:05 (CEST)