Même requête ! J'aurais volontiers modifié le modéle pour intégrer la commande {{formatnum}}, mais hélas, ce modèle est protégé . Quelqu'un pourrait-il s'en charger ? Pymouss4414 août 2007 à 18:52 (CEST)[répondre]
Avez-vous pensez qu'une liste exhaustive sur une ligne c'est pas terrible? Non je ne pense pas, il faudrais faire un passage à la ligne outs les X années.--— Pako-13 août 2007 à 02:05 (CEST)[répondre]
Ça existe, mais il ne prend en compte que les recensements quinquennaux, et pas ceux d'Ancien Régime, ce qui est gênant pour une commune comme Mons (Var), et d’autres de Provence sur lesquelles je travaille. Celui-ci est le seul à nous laisser libre, et il est plus joli. Un volontaire ? Épiméthée (d) 3 février 2008 à 11:20 (CET)[répondre]
J'ai modifié le modèle modèle:DemogFR de sorte qu'il permette d'insérer jusqu'à neuf recensements ou estimations de population d'avant 1793 (ancien régime, ou même gaulois, préhistoire, ce qu'on veut). J'espère que cela pourra répondre à certains besoins. J'ai ajouté aussi un paramètre sources au pluriel qui permet de citer plusieurs sources. Carfois (d) 3 janvier 2009 à 09:44 (CET)[répondre]
Merci, il ne me reste qu’une modification de détail, c’est mettre en valeur la différence avant 1793/après, quand le recensement est en feux (mais actuellement il suffit d’écrire feux en italique après le nombre et c’est bon). À l’occasion de l’actualisation des données sur le 04, je vais en profiter pour modifier le modèle sur toutes les communes. Épiméthée (d) 4 janvier 2009 à 13:20 (CET)[répondre]
Dans le modèle, pourrait-on rajouter une ligne entre sansdoublescomptes et enquêteannuelle : populationmunicipale ? Ce, afin de tenir compte du nouveau recensement à partir de 2006 (recensement de la population légale publié par l'INSEE le 1er janvier 2009).Merci. Matth97 (d) 5 janvier 2009 à 02:19 (CET)[répondre]
Ce n'est pas un bug, la position des pipes est indifférente. Le premier exemple est juste une manière moins courante d'écrire un appel de modèle. Remplacer à l'occasion par la seconde écriture évitera de dérouter les gens. --Lgd (d) 12 juillet 2009 à 14:31 (CEST)[répondre]
Coucou. J'aimerais bien optimiser le modèle:Démographie. Il sert à faire des simples petits tableaux avec des années, est actuellement composé de 1000 « {{#if:{{{...}}}... », soit deux pour toutes les années entre 1600 et 2100. Alors qu'on pourrait avoir le même résultat avec 40 « #if », soit 25x moins de code. Donc remplacer :
Pour ce faire, il faudrait ajouter les 40 nouveaux paramètres dans le modèle avant un passage d'un bot. Et après le passage du bot, on pourrait enfin enlever les 1000 paramètres en trop du modèle. Est-ce qu'il y a des oppositions, avant que je fasse les demandes correspondantes ? Bien à vous, Dodoïste[ dring-dring ]30 juillet 2010 à 19:18 (CEST)[répondre]
OK, mais :
ça demande le passage d’un robot (pas difficile) ;
ça demande le changement des utilisateurs de ce modèle (a priori, un peu plus difficile, mais pas insurmontable) ;
40 paramètres, c’est un peu léger. Ça convient pour les 36 recensements français depuis 1793 ; mais pour peu qu’on ait quelques recensements d’Ancien Régime, on se retrouve coincé. Par exemple, rien que le bouquin {{Atlas historique de la Provence}} en donne deux ou trois pour toutes ces communes. Sachant qu’il y en a eu d’autres, on risque d’être vite coincés. D’autant qu’on attend d’autres recensements pour 2011 et après. Épiméthée (d) 3 septembre 2010 à 18:53 (CEST)[répondre]
Oui pour les points 1 et 2. Pour le n°3 : si je comprends bien ta remarque, le modèle démographie s'affiche sur une ligne (sans retour à la ligne). On ne peut pas utiliser les 40 paramètres sans faire sortir le tableau de la vaste majorité des résolutions. Il est d'usage dans les articles d'utiliser plusieurs fois le modèle démographie, à la suite, pour faire un retour à la ligne dans le tableau. Comme dans Doubs_(département)#Démographie. Le nombre de paramètres n'est donc pas un problème à priori. Bien à toi, Dodoïste[ dring-dring ]6 septembre 2010 à 01:14 (CEST)[répondre]
Oh pardon, j’ai cru que j’étais sur {{Démographie2}}. Je croyais que celui-ci avait été supprimé, justement à cause des problèmes évoqués. Donc oui, fais la modif', pas d‘opposition (sauf les 1 et 2, mais ce n’en était pas, juste des signalements). Épiméthée (d)
Après réflexion, il y a un ennui avec le modèle que je propose : si on ajoute une date avant tout au milieu de la numérotation, il faut déplacer le contenu des champs, pour refaire l'ordre dans le nouvel ordre. Alors qu'avant c'était tout simple.
Ben, je ne comprends peut-être pas tout, mais j'ai l'impression qu'on complique la saisie en s'éloignant de la syntaxe habituelle des modèles, pour finalement arriver à un modèle très similaire à {{Démographie2}}. Dans ce cas, autant proposer directement le changement de modèle dans les articles, mais même pour cela, je ne suis pas sûr qu'il y ait un intérêt… En ce qui me concerne, je prend le modèle Démographie lorsque les tableaux ont peu de colonnes, et Démographie2 dans le cas contraire. ---- Ikmo-ned (discuter avec) 9 septembre 2010 à 19:37 (CEST)[répondre]
Oui. Au vu du texte source, les seules valeurs permises avant 1600 sont 1300, 1400, 1500 et 1502 (?!). Il faut noter que ce modèle devient petit à petit obsolète et qu'il semble préférable de basculer vers le modèle {{Démographie2}}, plus facilement adaptable. Cordialement, ---- Ikmo-ned (discuter avec) 17 septembre 2011 à 18:28 (CEST)[répondre]
Hello,
quelques remarques sur les éléments indiqués dans la documentation :
« Le nombre maximal de colonnes est 17 et le nombre maximal de lignes est 12 » : en pratique c'est faux. Je n'ai intégré aucune limite supérieure sur le nombre de colonnes et le nombre de lignes. Je peux facilement le faire pour les colonnes si besoin. C'est un poil plus compliqué pour les lignes, mais faisable.
« hyperliens-années » : la valeur reconnue est on ou oui (soyons francophones ). Toute autre valeur que on ou oui signifie off ou non.
il faudrait préciser le comportement ajouté aujourd'hui : si une seule ligne affichée et si paramètre "colonnes=" non indiqué et si le nombre d'années est inférieur au nombre de colonnes (9, puisque valeur par défaut) alors le nombre de colonnes effectif est ramené au nombre d'années indiqué
Note : sur le dernier point, il y a un comportement qui peut être gênant : la largeur du tableau est calculée avant l'ajustement du nombre effectif de ligne (parce qu'on ne connait le nombre d'années indiquées que plus tard). Ainsi si 5 années sont indiquées le tableau n'aura bien que 5 colonnes mais fera la même largeur totale que si le tableau avait 9 colonnes (donc avec des cellules plus larges). Je modifie ? Hexasoft (discuter) 17 juillet 2013 à 12:36 (CEST)[répondre]
Point 1 : je suis favorable à ce qu'il n'y ait plus de limites. Ne modifie donc pas le module.
Point 2 : OK pour rajouter ces précisions.
Point 3 : OK pour rajouter ces précisions + corriger ce disfonctionnement.
Pour le point 3 voir le 1er exemple de Discussion module:Démographie/Test/Documentation. Principe : si réduction du nombre de colonnes et que l'utilisateur n'a pas fixé la largeur du tableau alors la largeur est recalculée à partir du nouveau nombre de colonnes. Si l'utilisateur à fixé la largeur du tableau je ne change pas la taille (il l'a probablement fixé pour des raisons d'alignement avec d'autres tableau). Question : dans ce dernier cas est-ce que je réduit quand même le nombre de colonnes (qui vont apparaître plus large, donc) ? Hexasoft (discuter) 17 juillet 2013 à 12:57 (CEST)[répondre]
J'ai ajouté un exemple illustrant ton dernier point. Je pense qu'on peut partir du principe que si l'utilisateur spécifie une largeur, c'est de sa responsabilité et je laisserais ainsi en réduisant le nombre de colonnes. Si quelqu'un d'autre a un autre avis, on avisera. --FDo64 (d) 17 juillet 2013 à 13:27 (CEST)[répondre]
Bonjour, Le code du modèle n'apparaît pas en clair. Il est appelé avec la fonction "invoque". Mais où trouve-t-on le code de "Demographie" ? Désolé pour cette question de béotien.Roland45 (d) 1 août 2013 à 06:46 (CEST)[répondre]
Oups, je suis allé trop vite pour poser ma question. J'ai trouvé le module. Mais cela ne me parait pas vraiment transparent comme principe.Roland45 (d) 1 août 2013 à 06:48 (CEST)[répondre]
Ignare que je suis, je n'avais pas vu qu'on était passé en lua! Ca va être dur à intégrer pour les vieux apprentis modélistes, mais bon ça ressemble un peu au VBA, sans les sous-programmes (...je ne suis pas informaticien :)).Roland45 (d) 1 août 2013 à 07:29 (CEST)[répondre]
Oui, Lua/Scribunto est arrivé. Note : ça ne remplace pas les modèles (enfin, à terme peut-être) qui existent toujours.
Un module est appelé avec #invoke en lui donnant le nom du module et le nom de la fonction dans ce module. Les modules écrits pour remplacer des modèles suivent donc généralement le même principe : le modèle contient uniquement un #invoke, le code étant dans le module.
Voir Projet:Scribunto (le nom de l'implémentation Lua dans mediawiki) pour trouver des ressources autour de ce langage.
J'ai regardé : « il n'y a pas de problème » . En fait devant 1450 c'était un autre type d'espace que l'espace habituel. Du coup visiblement mediawiki ne le considère pas comme un espace mais comme faisant partie du paramètre. Forcément ce paramètre n'est plus un nombre et est donc considéré comme une option (inexistante). Pour donner un exemple c'est comme s'il y avait eu « |x1450 = … » → c'est le paramètre nommé « x1450 » et non le paramètre numérique 1450.
Il semble difficile de traiter ça depuis le module : en effet c'est mediawiki/scribunto qui rangent les paramètres selon leur type (nommé ou pas). Ça obligerait à analyser dans le module tous les paramètres nommés pour voir si certains ne seraient pas en fait des paramètres non nommés mal récupérés. Il me semble que ce serait plutôt un bug à ouvrir coté mediawiki. Hexasoft (discuter) 7 janvier 2014 à 13:26 (CET)[répondre]
Hmmm… J'ai analysé ce code et il ne semble pas correspondre à un caractère UTF-8 connu. C'est donc plutôt un bug lors de la saisie qu'une mauvaise détection de la part de mediawiki. Le code est A0-C2. Or le code UTF-8 pour l'espace insécable est C2-A0. Donc c'est probablement un bug d'édition (ceci dit je ne suis pas certain qu'insérer une espace insécable dans les noms de paramètres de modèles soit de toute façon une bonne idée ). Hexasoft (discuter) 7 janvier 2014 à 13:47 (CET)[répondre]
Je ne pense pas. D'abord tu n'es pas le seul dans ce cas à éditer sur WP et tu as fait d'autres éditions, y compris dans cette partie, qui n'ont pas eu ce problème. Ça ressemble soit à un bug ponctuel soit à un copier/coller entre des supports différents (fichier texte ou autre → web) qui serait mal passé. Quoi qu'il en soit ce n'est pas très grave . Cordialement, Hexasoft (discuter) 7 janvier 2014 à 15:53 (CET)[répondre]
Désolé de revenir à la charge, mais l’article Colmars a vraiment un drôle de rendu ce soir. Je cherche ce qui peut provoquer l’erreur, peut être quelque chose dans les modèles démographie. Je poste pour avertir, mais j’ai l’impression que c’est le seul article touché. azoée (discuter) 7 janvier 2014 à 22:06 (CET)[répondre]
Ikmo-ned (d · c · b) a résolu le problème de couleur en ajoutant le paramètre « années-fond = #ffffbb ». Peut-on quand même prévoir d'ajouter cette possibilité parmi les chartes, plus compréhensible par certains utilisateurs ? Père Igor (discuter) 19 octobre 2016 à 12:24 (CEST)[répondre]
Père Igor : Bonjour, en constatant qu'Évol appelle le modèle:Tableau population avec la charte « localité », cela m'a permis de constater diverses incohérences dans ce modèle :
FDo64 : bonjour. Je suis bien évidemment pour une cohérence globale des chartes mais ne connaissant rien à cette programmation et aux différentes couleurs, je fais confiance à ceux qui savent pour harmoniser tout ça. Père Igor (discuter) 19 octobre 2016 à 15:55 (CEST)[répondre]
FDo64 : pas de problème pour corriger ce module. L'idée c'est quoi ? Appeler Module:Chartes pour récupérer ces valeurs ? Si oui le problème (semble-t-il) c'est que ce module n'est pas prévu pour être appelé directement depuis un autre module. Visiblement il s'agit de la charte "géographie", qui semble contenir les éléments que j'avais codé (canton, département…), et pour autant que je puisse voir dans mon code je n'utilise qu'une seule valeur : (type)"normal".
Par contre mon module exporte aussi la fonction charte_de_couleur, qui permet de retourner juste la couleur (en fonction du type), il faudrait donc aussi s'assurer que personne ne l'utilise ! Hexasoft (discuter) 19 octobre 2016 à 16:20 (CEST)[répondre]
Père Igor : Merci pour ton approbation, par contre quelles couleurs faut-il utiliser dans les deux cas listés ?
Hexasoft : Je ne m'y connais pas du tout en programmation de modules, je ne peux donc pas te conseiller. En plus, c'est toi qui les as écrits. Pour ce qui est de l'appel, il faut faire comme dans le Modèle:Charte de couleur.
FDo64 : oh purée je me rappelais même pas que c'est moi qui avait créé Module:Chartes !
Je vais voir dans un premier temps pour remanier Module:Chartes afin de pouvoir l'utiliser aussi depuis un autre module. Ensuite je vais faire des tests (dans un module de test) pour modifier ce module démographie afin d'utiliser directement ça, histoire que tout soit au même endroit.
C'est normalement terminé pour moi et c'est maintenant à Hexasoft (quand il aura le temps) de modifier le Module:Démographie pour qu'il appelle le Module:Chartes/données.
En cas de problème ou de demande complémentaire, notifiez-moi.
j'ai commencé à me replonger dans le code (ça fait un moment…). Une question : la charte « codée en dur » dans le module démographie correspond-elle à la charte « infobox géographie » ?
Parce que le module chartes lui fonctionne par infobox/type/catégorie, il me faut donc le type d'infobox.
Note : j'ai créé Module:Chartes/Test pour tester un ajout à ce module : la fonction chartes_m() qui contient le code de la fonction chartes(). En effet chartes() est destinée à être appelée depuis les articles (directement ou via un modèle), or là j'ai besoin d'une fonction appelable depuis un autre module directement. La fonction chartes() devient ainsi juste un wrapper des paramètres qui appelle chartes_m(). Hexasoft (discuter) 15 novembre 2016 à 21:43 (CET)[répondre]
Il me semble que c'est ok, mais d'autres relectures / validations sont bonnes à prendre.
Question : est-il possible de connaître les articles/modèles qui appellent une fonction précise d'un module ? En effet j'avais créé aussi la fonction charte_de_couleur() devenue obsolète de part l'existence du module Chartes. Je l'ai modifié pour faire appel au module Chartes mais sa présence est plutôt un problème. J'aimerai être certain qu'elle n'est pas utilisée avant de la supprimer ! Cordialement, Hexasoft (discuter) 15 novembre 2016 à 23:05 (CET)[répondre]
Je doute en pratique que la fonction qui me tracasse soit utilisée (en tout cas je ne vois pas d'appel depuis un modèle, mais il peut y avoir des appels directement depuis les articles).
Je suis d'avis de supprimer cette fonction inutile et probablement pas appelée et de traquer ensuite les pages en erreur d'appel d'un module (via la catégorie "page en erreur d'appel" ou un truc du genre).
pour info j'ai un coup de bourre imprévu au boulot (l'un des serveurs centraux qui est parti en cacahuète) je vais donc être indisponible pour l'horizon proche
Je viens de reporter les modifications dans Module:Chartes d'une part (pour extraire la fonction principale et la rendre appelable depuis un autre module) et dans Module:Démographie (pour faire appel à cette fonction et donc ne plus utiliser les données de chartes locales à Module:Démographie).
Bonjour, je demande une intervention sur cette page afin de retirer le titre en gras par la suppression des """. En effet, celui étant déjà en gras "natif" il n'a pas besoin de ces """. Cela relève de l'esthétique mais impacte de nombreuses pages. Amicalement — Mentheà l'eau - 5 juillet 2017 à 16:08 (CEST)[répondre]
Paramètres annéen notes, annéen unité et annéen affichage
Bonjour, il semble que les paramètres documentés annéen notes, annéen unité et annéen affichage ne fonctionnent pas.
J'ai repéré la source du problème : la fonction de départ p.demographie() lit les paramètres listés dans la table p.parametres, puis les paramètres numériques ; mais elle ne lit pas les paramètres <année> <unité/affichage/notes>, ceux-ci ne sont donc pas ajoutés dans la table pm qui est ensuite transmise à p.demographie_m(pm). L'erreur remonte aux modifs de par Hexasoft sur Module:Démographie/Bac à sable. od†n ↗blah21 février 2022 à 13:33 (CET)[répondre]
Golmote et Od1n : effectivement la lecture des paramètres travaille soit sur la liste des paramètres nommés connus soit sur les valeurs numériques. Il faut que je réfléchisse à ça. Je vais sans doute "casser" Module:Démographie/Bac à sable pour faire des tests. Hexasoft (discuter) 18 mars 2022 à 14:55 (CET)[répondre]
@Hexasoft Merci d'avoir pris le temps de regarder. Le résultat me semble bien correspondre au comportement attendu. Par contre, dans le code, la variable tst ne semble pas utilisée ? (C'est peut-être juste ma compréhension de Lua qui fait défaut. ^^) --Golmote (discuter) 18 mars 2022 à 20:37 (CET)[répondre]
Golmote : tu as raison, et elle devrait l'être ! Là en gros il devrait utiliser le résultat du test pour faire (ou pas) l'insertion. Donc ça permet actuellement d'accepter des paramètres non valides ! Je corrige ça demain Hexasoft (discuter) 18 mars 2022 à 21:44 (CET)[répondre]
J'ai effectivement passé la modif en production, et effectué quelques retouches à cette occasion.
Pour expliquer la situation concernant la validation des paramètres :
Lorsque le module est utilisé par des modèles, ces modèles peuvent envoyer des paramètres avec des noms qui ont été modifiés afin de rendre ces paramètres inopérants (et éviter des doublons de noms de paramètres). Les modèles utilisent la fonction demographie(), qui va appeler la fonction demographie_m() en lui transmettant les paramètres reconnus, et en ignorant les autres. Les vérifications effectuées dans demographie_m() sont donc superflues dans ce cas (sous réserve que demographie() et demographie_m() soient bien coïncidés, ce qui n'était justement pas le cas et a conduit au problème sujet de cette discussion).
Lorsque le module est utilisé par d'autres modules (e.g. Module:Population, Module:Population de France), ceux-ci utilisent directement demographie_m(), les noms de paramètres sont validés et tout nom qui n'est pas reconnu déclenchera une erreur.
Concernant demographie() qui est appelé par les modèles (le premier point dans mon message précédent), désormais tous les paramètres, sauf ceux dont le nom commence par "_", sont transmis à demographie_m(), qui ira donc valider leurs noms : 192047525.
Golmote et Od1n : effectivement la lecture des paramètres travaille soit sur la liste des paramètres nommés connus soit sur les valeurs numériques. Il faut que je réfléchisse à ça. Je vais sans doute "casser" Module:Démographie/Bac à sable pour faire des tests. Hexasoft (discuter) 18 mars 2022 à 14:55 (CET)
Là en gros il devrait utiliser le résultat du test pour faire (ou pas) l'insertion. Donc ça permet actuellement d'accepter des paramètres non valides ! Je corrige ça demain 
Hexasoft (discuter) 18 mars 2022 à 21:44 (CET)
