Il me semble que la mention du gentilé serait pertinente dans la section « Démographie ». En utilisant les modèles de données, serait-il possible (et pertinent) d'ajouter une phrase du type « En <dernière année de population présente dans le modèle évolution population>, les habitants de <nom de la ville>, appelés <mention du gentilé s'il est présent dans le Modèle:Données de la ville>, étaient au nombre de <dernière population présente dans le modèle évolution population>. » ? Auxerroisdu68@9 janvier 2013 à 20:42 (CET)[répondre]
C'est difficile à faire. Il existe pour chaque article de commune 2 types de modèles de données dont voici des pages explicatives :
Le problème est que suivant le nom des communes, on ne peut pas mettre le mot "de" comme dans : « les habitants de <nom de la ville> » car imaginons qu'il s'agisse de la ville d'Aix-en-Provence ça donnerait : « les habitants de Aix-en-Provence », il faudrait mettre un "d'", idem pour de nombreuses autres communes...
Par contre, il est plus facile de faire : « En <dernière année de population présente dans le modèle évolution population>, les habitants de la commune, appelés <mention du gentilé s'il est présent dans le Modèle:Données de la ville>, étaient au nombre de <dernière population présente dans le modèle évolution population> habitants. ». Cependant, il faudra modifier la programmation du modèle pour qu'il prenne en compte les absences de gentilé dans certains modèles de données informations générales. En effet, il va falloir ajouter une conditionnelle pour que le modèle ajoute automatiquement le gentilé lorsque celui-ci est dans le modèle information générale d'une commune. Et lorsqu'il n'y a pas de gentilé alors, le modèle devra écarter automatiquement de la phrase le passage : « , appelés <mention du gentilé s'il est présent dans le Modèle:Données de la ville> ».
Bonjour à tous. Je suis très (c'est un euphémisme !) réservé sur l'intégration du gentilé, où qu'il soit. En effet, nous avons bien peu de sources secondaires qui les justifient. De nombreux articles font référence au site de la SARL Patagos, site commercial qui fournit des informations publiées par David Malescourt à partir de données reçues de n'importe quel internaute sans quelque vérification que ce soit. Dois-je rappeler une nouvelle fois qu'il est déconseillé de renvoyer les lecteurs vers des sites qui sont financés par la publicité (selon la fameuse formule « 1 clic -> 1 euro »), ce site ne fournit par ailleurs aucune référence à ses sources.
En conclusion, à part les données que l'on trouve sur les sites des mairies des communes ou les dictionnaires/encyclopédies, je suis très réservé sur la publication de ces informations.
@ Harrieta : Les gentilés sont mis à jour manuellement par les utilisateurs, comme c'est le cas actuellement dans les infobox. A moins que l'on trouve un site complet, où l'on puisse tenter de récupérer les données... amicalement--Wikialine (d) 10 janvier 2013 à 14:25 (CET)[répondre]
Inutile de chercher car ce site ne pourrait pas exister, d'abord parce que de nombreuses communes n'ont pas de gentilés, ensuite parce que certaines communes en ont deux, voire trois (en cas de regroupement notamment) et qu'on assiste à des guerres d'édition parce qu'il semble que le gentilé à placer dans l'Infobox ne soit pas partagé par tous. Bref ... il me semble urgent de ne pas décider sur ce qui reste — àmha — un détail ! Cordialement. AntonyB (d) 10 janvier 2013 à 15:26 (CET)[répondre]
En tout cas les 334 gentilés du Loiret figurant dans habitants.fr sont corrects ... c'est moi qui les ai chargés et ils proviennent d'un ouvrage "l'officiel des élus du Loiret", publié par l'Association des maires du Loiret, une page par commune, où sont mentionnés les gentilés. Mais il et vrai que le site habitants.fr fonctionne comme un wiki, mais sans ref! J'ai en fait la bse complète. Il est vrai que pour certains, une recherche Google ne donne pas grand chose. Cordialement.Roland45 (d) 10 janvier 2013 à 18:33 (CET)[répondre]
Ce n'était qu'une proposition, après, je laisse au projet compétent la décision… Wikialine, tu avais exactement compris ce que je voulais dire !
Quant aux gentilés, je viens de remplir tous ceux du Doubs à partir d'un ouvrage de ma bibliothèque (du même type que celui mentionné par Roland45 ci-dessus), en en profitant pour compléter les EPCI et rectifier les cantons et arrondissements (en particulier ceux à accents). Allez, bonsoir. Auxerroisdu68@11 janvier 2013 à 02:54 (CET)[répondre]
Suite à la mise à jour des données Insee, j'ai un message d'erreur sur la page Ners, pouvez-ous voir d'où vient le problème et le régler, je l'aurai bien fait moi-même mais je n'ai pas l’accès aux modèles.
Avec Safari, le tableau, quand il est situé trop haut dans l'article, rentre dans l'infobox (ce qui n'est pas le cas avec Firefox). Est-il possible d'y faire quelque chose ? Cdlt, Auxerroisdu68@9 février 2013 à 23:52 (CET)[répondre]
Ne serait-il pas plus judicieux de mettre ce {{Clr}} directement dans le modèle, entre {{Introduction population d'article de commune de France}} et {{Tableau population d'article de commune de France}} ? Ce sont le tableau et l'histogramme qui rentrent dans l'infobox, le texte lui s'adapte comme un texte normal à côté de l'infobox, et cela permettrait d'éviter d'avoir de trop grands blancs. Auxerroisdu68@13 février 2013 à 19:50 (CET)[répondre]
Par contre avec Firefox le tableau vient après le fin de l’infobox (le texte d'intro n'est pas impacté); ne peut on faire un {{clr|left}} plutôt qu'un {{clr}}, pour éviter ce décalage? Pano38 (d) 18 février 2013 à 11:16 (CET)[répondre]
C'est normal que le texte introductif ne soit pas impacté car, j'ai placé le {{clr}} entre le texte introductif et le tableau. Car si je l'avais mis avant le texte introductif alors on aurait eu un plus grand blanc sur le coté de l'infobox. Le soucis c'était surtout la collision entre l'infobox et le tableau. A présent, il n'y a plus de collision et on évite un trop grand blanc sur le coté de l'infobox. De toute façon ne perdons pas trop à l'esprit que les articles à l'état d'ébauche vont évoluer. Le modèle section va progressivement trouver place bien en dessous de l'infobox. Je serai tenté de dire que le ieux serait encore d'ajouter quelques sections vides juste avant le modèle section avec dans ces sections (géographie,histoire...) vides le modèle {{...}}. ça inviterai d'une part les visiteurs à contribuer et d'autre part ça évite tout risque de collision. amicalement--Wikialine (d) 18 février 2013 à 11:52 (CET)[répondre]
J'ai retiré l'année 2009. Si vous voyez des erreurs, n'hésitez pas à intervenir directement. Le bot fonctionne avec des tables informatiques faites avec excel... Des erreurs ont pu s'y glisser. Là j'ai terminé l'ajout des recensements de 2010 dans la totalité des modèles de données évolution démographie dans les paramètres "an" et "pop". Je vais bientôt m'occuper de l'ajout des recensements réels de 2010 dans des paramètres "anX" et "popX", cette fois je soumettrais la table aux membres du cdf pour être sûre qu'il n'y ait pas d'erreur. amicalement--Wikialine (d) 14 février 2013 à 01:29 (CET)[répondre]
Années des recensements durant l'annexion en Alsace-Lorraine/Savoie/Nice
Ce modèle ne tient pas compte de la remarque sur le site EHESS concernant les recencements entre années 1870-1819 pour les communes d’Alsace et de Lorraine. Il faudrait trouver une solution pour pouvoir corriger ces informations erronées. Les années des recensements réalisés par l’administration impériale sont 1871, 1875, 1880, 1885, 1890, 1895, 1900, 1905 et 1910. Peut-on espérer une mise à jour du modèle en ce sens ou est-ce trop compliqué ? Il y a aussi des ajustements pour Nice et la Savoie « les recensements de la période 1814-1860 ont eu lieu en 1815, 1822, 1838, 1848 et 1858 ». – A2 (d) 13 février 2013 à 03:08 (CET)[répondre]
Effectivement, j'en avais déjà parlé sur le projet CdF il y a un moment et Roland45 avait adapté ses tableaux Excell en conséquence. Le problème là est que je vois passer depuis quelques semaines des contributions insérant ce modèle sur les articles des communes de Moselle, le modèle semble pris pour acquis alors qu’il n’est pas correct. Ces dates sont à corriger par un bot sur quelques milliers de sous-modèles pour les communes concernées. – A2 (d) 14 février 2013 à 14:57 (CET)[répondre]
Ne vaut-il pas mieux faire passer un bot pour corriger toutes les pages « Modèle:Données/nom de commune/évolution population », comme le suggère A2 ? Il suffit de remplacer les dates citées ci-dessus par les bonnes valeurs dans une liste de pages, je ne suis pas sûr que la création d'un deuxième modèle se justifie. En plus, avoir un modèle qui afficherait une valeur différente de celle présente dans la page de données, ça complexifie un peu plus, non ?--Rehtse (d) 18 février 2013 à 10:59 (CET)[répondre]
En modifiant les « Modèle:Données/nom de commune/évolution population », on permet d'afficher les dates que l'on veut dans les articles. Techniquement les modèles actuels suffisent. Après pour ce qui est du choix des dates et du nombre de population, alinebot a récupérer les dates dans cassini (jusqu'à 1999, puis chez l'insee pour les dates post 1999) en écartant automatiquement les dates dans cassini où il y avait des "abs." ou autre indication non numérique. Pour le reste, j'avoue ne pas être assez pointu avec ces histoires de recensements particuliers pour certains départements. J'ai jeté n œil sur l'article de Metz. Si l'on va sur la fiche cassini : http://cassini.ehess.fr/cassini/fr/html/fiche.php?select_resultat=22347 , on retrouve dans le Modèle:Données/Metz/évolution population les données du tableau qu'à mis Cassini dans sa fiche. Sur la fiche Cassini il y a également la mention « Pour l'Alsace-Lorraine, les recensements de la période 1870-1919 ont eu lieu aux années 0 et 5 sauf 1871, et 1915 qui n'a pas été réalisé. ». C'est un peu du chinois pour moi. Si il faut renommer certaines dates dans certains modèles de données de certains départements, mon bot n'est pas programmé actuellement pour ce type d'activité (il est programmé pour de la récupération de données sur des sites externes), il vaut mieux faire appel à des bots déjà opérationnel et mieux armé pour ce type d'activité (certains bot renomment déjà des paramètres d'infobox dans des séries d'articles... donc ça devrait être faisable).amicalement--Wikialine (d) 19 février 2013 à 12:01 (CET)[répondre]
Le tableau démographique sur Metz me semble correct, mais sur Woippy, par exemple, le modèle a été mis hier et les dates sont maintenant fausses (ici). Je me souviens qu’on avait {{demogAL}} auparavant (supprimé en décembre dernier) qui gérait ce pb de date, mais qui n'était pas vraiment utilisé. Ajouter partout au modèle ces notes du site Ehess ne va faire qu’alourdir les notes (et il est vrai que la note n’est pas facile à comprendre à la première lecture). Je vais regarder avec AWB ce week-end pour changer définitivement les dates une fois pour toute sur les pages de données en sous-modèles, c'est vraiment le plus simple. Quelqu'un confirme qu'il faut changer 9 dates pour _toutes_ les communes de Moselle/Bas-Rhin/Haut-Rhin, et 5 pour toutes celles de Savoie (comme je l'ai mentionné dans le premier message de ce fil) :
Pour la Moselle, Haut-Rhin et Bas-Rhin :
1872 > 1871
1876 > 1875
1881 > 1880
1886 > 1885
1891 > 1890
1896 > 1895
1901 > 1900
1906 > 1905
1911 > 1910
Pour la Savoie :
1814 > 1815 (pas trouvé sur l’exemple que j'ai regardé ?)
Bonjour A2. En ce qui concerne les recensements de l'Alsace, de la Lorraine, de la Savoie, mais aussi du Comté de Nice, je n'ai aucune autre source que celle figurant sur n'importe quelle notice de la base Ldh/EHESS/Cassini, à savoir « Pour l'Alsace-Lorraine, les recensements de la période 1870-1919 ont eu lieu aux années 0 et 5 sauf 1871, et 1915 qui n'a pas été réalisé. Pour Nice et la Savoie, les recensements de la période 1814-1860 ont eu lieu en 1815, 1822, 1838, 1848 et 1858 ». Je sais que nous avions évoqué précédemment en détail cette particularité mais je suis incapable de retrouver la page dans laquelle avait eu lieu la discussion. Si je remets la main dessus, je te préviens. Je validerais donc :
Pour la Moselle, Haut-Rhin et Bas-Rhin (exemple Nancy) :
1872 > 1871
1876 > 1875
1881 > 1880
1886 > 1885
1891 > 1890
1896 > 1895
1901 > 1900
1906 > 1905
1911 > 1910
Pour la Savoie et le Comté de Nice (exemples Annecy et Nice) :
(1814 > 1815) semble ne pas exister sur la base Cassini
Merci. Je créé de suite un compte bot et fait une demande d’autorisation pour qu'AWB puisse enregistrer automatiquement les modèles. Je commencerais par les communes d’Alsace-Moselle. Pour cette modification, je trouve quelques autres sources en ligne qui semblent confirmer des recensements à certaines de ces dates « rondes » (celui de 1900 revient assez souvent). Je passerais ensuite placer le modèle en question sur les articles où il n’y est pas encore (à la main, j’imagine, car il y a parfois des infos ou autres références à garder). Par contre, je bloque un peu sur cette histoire de Savoie et comté de Nice. Je suggère que la « Savoie » représente « toutes les communes des deux départements de la Savoie actuelle » (soit 599 modèles), mais je ne sais pas quelles sont les communes concernées par cette modification pour le comté de Nice. Au §Géographie, on lit : « Le territoire du comté de Nice correspondait à peu près à l'actuel arrondissement de Nice ». L’arrondissement compte aujourd’hui 101 communes d’après l’infobox. Ce « à peu près » est à préciser, sans la liste exhaustive des communes concernées par ces recensements je ne peux pas corriger les modèles adéquats. – A2 (d) 26 février 2013 à 19:02 (CET)[répondre]
Les années erronées ont été corrigées pour l’Alsace-Moselle par StarusBot (d · c · b) la semaine dernière (merci Starus). Les modèles des communes des deux départements de Savoie vont être corrigés de la même manière. Pour « Nice », il faudrait documenter ça, j'ai posé la même question sur la pdd du portail à défaut de réponse précise ici. À suivre. – A2 (d) 11 mars 2013 à 21:27 (CET)[répondre]
J’ai corrigé à l’aide de mon robot les données pour la Savoie il y a une semaine et quelque et suis en train de finaliser ce point pour les communes de l’ancien comté de Nice. Sur les 101 communes de l’arrondissement de Nice actuel, 89 avaient des recencements entre 1814-1860 et, à défaut de réponse plus précise à ma question à ce sujet plus haut, tous ont été corrigés comme pour la Savoie (il vaut mieux en corriger 2 ou 3 de trop que ne pas corriger ce lot du tout). – A2 (d) 3 avril 2013 à 15:50 (CEST)[répondre]
Mise à jour des modèles de données pour les recensements réel année 2010
Bonjour, je viens de terminer l'ajout, temporaire pour 1 an (jusqu'au prochaine recensement de l'année prochaine), des recensements de l'année 2010 dans les modèles de données (paramètres "an" et "pop") pour la totalité des communes (...Avancement des mises à jour des recensements temporaires année 2010).
A présent, il va falloir ajouter dans ces modèles de données (paramètres "anX", "popX", "max" et "nombre") les recensements réels pour l'année 2010. Avant de lancer le bot, je tiens à vous soumettre les listes des communes concernées afin de ne pas faire d'erreur. Voici les 2 listes des articles que le bot va mettre à jour pour les recensements réels de 2010 :
Bonjour Wikialine. À quoi correspondent les résultats que l'on voit sur la droite de chaque ligne ? Serait-ce un numéro d'ordre ? Père Igor (d) 12 mars 2013 à 21:32 (CET)[répondre]
C'est l'url de la fiche cassini de chaque commune. Par exemple pour la ligne 1, on a l'adresse http://cassini.ehess.fr/cassini/fr/html/fiche.php?select_resultat=4 pour la commune Abainville. Avec Roland, on a laissé les adresses url des fiches cassini mais pour la mise à jour ça ne change rien car le bot ne va pas les utiliser. Le bot va utiliser le nom des articles et le n° insee... Donc ce qu'il faut vérifier c'est que les 2 listes de communes soient correctes et que les codes insee correspondantes (mais là ça devrait aller car Roland s'y est collé). Je vais bientôt lancer le bot pour l'ajout des recensements réels. Pour l'instant personne n'a rien dit. Au cas où il y a une erreur, il faut en parler à Roland, c'est lui qui supervise la constitution de ces tables. amicalement--Wikialine (d) 12 mars 2013 à 22:05 (CET)[répondre]
Améliorations possibles
Suite à plusieurs discussions ouvertes actuellement il est apparu qu'il faudrait modifier et améliorer quelques aspects du modèle. Voici différents points évoqués (liste non exhaustive, rajoutez ce que vous jugez nécessaire)--Mattho69me joindre20 février 2013 à 22:55 (CET)[répondre]
Cyril8181b, farouchement attaché à une maîtrise complète manuelle des articles de l'Essonne, a émis à de multiples reprises des critiques sur l'utilisation du modèle. Si la plupart de ses observations ne sont pas recevables au regard d'une approche collaborative, celles qui touchent sur la forme ou la technique doivent être analysées. Ainsi l'incohérence soulevée entre les couleurs du tableau du modèle et la charte des communes me paraît réelle.
D'abord il convient de souligner, en amont de la problématique propre au modèle, que l'application de la charte de couleurs ({{charte de couleur}}) simultanément aux tableaux et aux graphiques présente en elle-même une incohérence : dans le graphique, on colorise les barres de données et les millésimes des années sont noirs sur fond blanc, alors que dans le tableau on colorise les millésimes des années et les données restent noires sur fond blanc. Ceci vient du fait que dans un tableau, la couleur vise à mettre en valeur la désignation de la donnée (ligne de titres), apparaissant en général sous la forme d'une seule ligne, les données étant sur plusieurs lignes. Les tableaux de démographie présentent quant à eux la particularité d'avoir plusieurs lignes de titres, et autant de lignes de données.
Si on admet ce principe, il y a bel et bien une incohérence actuellement dans le modèle.
Oui. Cette modification est à faire. Beaucoup de contributeurs oublient que les notes ou les légendes d'images doivent logiquement se terminer par un point. Autant éviter de propager l'erreur au travers d'un modèle.Roland45 (d) 22 février 2013 à 08:12 (CET)[répondre]
Précision, ne pas oublier les titres qui eux aussi doivent respecter cette règle orthographique. Cdlt,--Cyrilb1881 (d) 23 février 2013 à 14:37 (CET)[répondre]
Ca, j'en suis moins sûr. C'est comme si on mettait un point à chacun des titres de sections d'un article. En tout cas la presse n'applique pas cette disposition.Roland45 (d) 23 février 2013 à 15:55 (CET)[répondre]
Le Lexique des règles typographiques en usage à l’Imprimerie nationale, dont les Wikipédia:Conventions typographiques sont un extrait, étant mon livre de chevet, et vu l'heure, je n'en suis pas loin. Donc je viens de le consulter. Pour info : on ne trouvera pas grand chose sur le sujet, car je rappelle que les textes de loi ne contiennent que du texte composé uniquement de phrases, jamais de schéma, de croquis, jamais de dessin ... Je n'ai donc rien trouvé de spécifique à la question posée, à part cette phrase, dans le chapitre PONCTUATION en page 146, le titre est EMPLOI DES SIGNES DE PONCTUATION (tel que, sans caractère de ponctuation) : « Le point termine une phrase. Il se confond, le cas échéant, avec les points de suspension. On le supprime dans les titres centrés (j'ajoute en sous-entendu : lorsque ces titres sont des phrases). Le point d'interrogation termine toute phrase interrogative en style direct. Il subsiste dans les titres centrés. ». J'ai parcouru les 197 pages du livre : les titres ne sont pas suivis d'un point, également pour un titre de tableau (voir page 178 par exemple). Je poserai demain la question à l'atelier typographique. Ils ont toujours de très bonnes réponses. Cordialement. AntonyB (d) 24 février 2013 à 00:39 (CET)[répondre]
C'est effectivement un problème. Il suffit en fait que le maximum de la période, X dans "Period =from:0 till:X", soit un multiple de l'échelle principale Y ( dans ScaleMajor = gridcolor:darkgrey increment:Y start:0). A la main, on met le paramètre intuitivement. Ici il faut trouver une formule (assez élémentaire) arrivant à la même chose.Roland45 (d) 22 février 2013 à 08:37 (CET)[répondre]
On doit pouvoir peaufiner cet aspect. Reste à trouver la solution qui comme Roland l'a souligné tourne principalement autour de formules. Le 1er qui trouve la solution tient le autres au courant. amicalement--Wikialine (d) 23 février 2013 à 00:25 (CET)[répondre]
Par rapport à ce que je dis ci-avant, le maximum à utiliser n'est pas le max qui est dans le modèle de données, mais un max arrondi supérieur à un nombre rond en centaines, milliers ou dizaines de milliers. Une fois qu'on a ce max arrondi, on en déduit les paramètre d'échelles (principale et secondaire). Dans mon script Excel, j'introduisais aussi plusieurs tests pour définir l'échelle secondaire : selon l'échelle principale et le max arrondi, la secondaire était obtenue de la principale par une division par 2, 5 ou 10, afin que ce soit plus harmonieux. Le pb est maintenant de codifier tout ça!!Roland45 (d) 23 février 2013 à 09:13 (CET)[répondre]
... sauf pour les communes de plus de 100 000 habitants où l'écart entre la limite supérieure et la plus grande barre est trop important, si la population dépasse à peine les 100 000 habitants (voir démographie d'Orléans. Il faudrait ajouter un test de plus, mais est-ce vraiment utile ?Roland45 (d) 24 février 2013 à 10:24 (CET)[répondre]
Histoire de jouer la sécurité, fais beaucoup de tests histoire d'être sûre que ça fonctionne bien. Après ça va pour une mise à jour. Au pire si il s'avère que le rendu est moins bien, on peut toujours revenir en arrière. L'important c'est qu'il n'y ait pas de bugs, mais avec des tests tu devrais être vite fixé. amicalement--Wikialine (d) 25 février 2013 à 01:54 (CET)[répondre]
Fait. Fait dans {{Histogramme population manuel}}. Pour info j'ai indiqué le calcul utilisé en commentaire dans la source du modèle (j'ai conservé le principe d'utiliser une fonction mathématique utilisant des logarithmes mais je l'ai perfectionnée), commentaire que je reproduis ici:
Calcul automatique des échelles :
Dans le cas où les échelles principale et/ou secondaire ne sont pas fournies, elle sont calculées automatiquement de la façon suivante:
- si on note MAX la valeur de {{{max échelle|{{{max|1000}}} }}}
- à partir de MAX on calcule:
- le coefficient multiplicateur (1, 10, 100, etc.) qui divise MAX pour lui donner une valeur à deux chiffres (>=10 et <100)
MUL = 10 ^ (floor(ln MAX/ln 10)-1)
- une valeur réduite aux deux chiffres significatifs de MAX et arrondie à l'entier supérieur, entre 10 et 100
RED = ceil(MAX/MUL)
- ensuite on utilise la fonction f(n)=floor((100+RED)/100+n) qui vaut 0 si RED<n et 1 si RED>=n
- en additionnant les fonctions f(n) pour différents seuils (en l'occurrence 31, 61 et 76), avec pour chacune d'entre elles un coefficient multiplicateur adapté, puis en multipliant le résultat par MUL, on arrive à obtenir les échelles que l'on veut en fonction de la valeur de RED.
* Calcul automatique de la valeur maximale de l'échelle (si {{{max échelle}}} n'est pas fourni):
- si on note ECH_MINEURE l'incrément d'échelle secondaire on prend comme valeur ceil(max/ECH_MINEURE)*ECH_MINEURE
Le cas particulier où MAX<100 est traité de façon séparée mais selon le même principe (sans toutefois avoir besoin de MUL).
Oui, les échelles obtenues avec cette méthode sont toujours des chiffres ronds, avec celui de l'échelle secondaire qui divise l'échelle principale en 2, 4, 5 ou 10 graduations secondaires par graduation principale, selon les cas. C'est d'ailleurs pour avoir des chiffres ronds que le cas particulier MAX<100 est traité séparément, car pour MAX=700, par exemple, les échelles principales et secondaires seront 100 et 25, mais pour MAX=70, elles ne seront pas 10 et 2,5 mais 10 et 5. Le maximum de l'échelle (le haut du graphique) est ajusté à la première échelle secondaire au-dessus du max, sauf lorsque MAX<10 où il est fixé à 10. -- Carfois (d) 6 février 2014 à 12:51 (CET)[répondre]
ma position personnelle est que la présence de Notes où figure du texte qu’on n’a pas pu placer dans l’article est une faiblesse, ou une paresse, car en général, on résout en quelques secondes le problème. Soit le contenu est important, et une simple reformulation permet de le placer dans l’article. Soit il ne l’est pas, et il vaut mieux le supprimer. Soit encore, il est important, mais un lien permet de rediriger vers un article où il trouve mieux sa place que dans une répétition à 36 000 exemplaires ;
dans ce cas précis :
la première note réexplique les modalités des sondages en France depuis 2006. Un lien vers Recensement de la population en France accompagné d’une phrase (les modalités du recensement en France ont beaucoup évolué de 1793 à nos jours) suffit ;
la seconde est d’ordre éditorial. On peut soit la réduire et la faire figurer avec le tableau, sur le modèle de Cassini, soit la supprimer. Je n’ai qu’une préférence, la retirer des notes. Azoée (d) 24 février 2013 à 11:35 (CET)[répondre]
J'abonde dans le sens d'Azoée, d'autant que les conventions présentées par la deuxième note ne sont que rarement respectées.
L'ajout d'un lien {{Lien vers modèle}} donnerait l'accès vers la documentation qui donnerait toutes les explications.
Toutes les adresses de l'insee sont référencées au code insee de la commune. Celui-ci figure dans le modèle {{Données/commune/informations générales}}. Introduire des liens vers les bonnes pages de données des communes conduira à faire pointer le modèle sur cet autre modèle de données, sauf à le renter en paramètre en clair. Utiliser ce modèle de données ne pose pas de pb si on est dans l'article de la commune, mais si on est dans un autre (dont le titre n'est pas celui de la commune, comme celui d'un article détaillé sur la démographie de la commune), cela ne marchera pas.Roland45 (d) 23 février 2013 à 16:13 (CET)[répondre]
Dans D-tableau2, une variante du modèle d'Aline, (utilisé par exemple dans (Démographie d'Artenay, j'entre le paramètre en clair. Ce modèle n'est toutefois pas abouti d'une part parce que les liens s'arretent en 2010, et d'autre part parce qu'il réfère toutes les années entre 2006 et 2010.Roland45 (d) 23 février 2013 à 16:18 (CET)[répondre]
Une référence bien présentée doit être de la forme : Auteur (si identifiable, sinon collectivité auteur), Titre (ou « Titre » si l’élément cité est un article ou une notice rattachable à un ensemble plus vaste, dans ce cas suivi de Ensemble), Éditeur, date de publication, date de consultation si le contenu est susceptible de modifications. En pratique, on n’a pas ça, mais une phrase explicative.
Quoiqu’ici, la présentation la plus correcte serait peut-être :
Insee, « 04090 - Le Fugeret », Populations légales 2010, Insee, 1er janvier 2013, consulté le XX/XX/2013. ::Pour les notices Cassini, je propose :
EHESS, « Le Fugeret - Notice Communale », Cassini, EHESS consultée le 18 juillet 2009. (sic, pour la typographie de l’EHESS reprise telle quelle).
On peut aussi ajouter comme date de publication 1999, ou 1999- si on considère que c’est une publication continue, en cours depuis 1999, mais si ça existe en bibliothéconomie, ça ne me paraît pas le plus adapté ici. Azoée (d) 24 février 2013 à 11:25 (CET)[répondre]
Les références bien présentées utilisent le modèle{{Lien web}}, mais dans le cas présent dès lors qu'il convient de référencer plusieurs années, on ne va pas mettre une ligne de ref par année, d'où l'idée de compacter en une seule ligne.Roland45 (d) 24 février 2013 à 12:19 (CET)[répondre]
Ta formulation m’étonne : non, c’est lien web qui suit une bonne présentation. Il n’y a que deux années à référencer (ou si je me trompe, merci de me détromper), si on veut faire du bon travail, on ne compacte pas tout mais on suit une bonne présentation. Azoée (d) 24 février 2013 à 13:15 (CET)[répondre]
Le pb soulevé par certains n'est pas dans la forme, mais dans le fait que certains liens ne renvoient pas vers les bonnes pages. Et c'est là toute la difficulté de modéliser le fait que d'une année sur l'autre la ref doit changer. Par exemple la dernière année (2010 en l'occurrence) est toujours à référencer, mais si l'année suivante (en 2014, correspondant aux chiffres 2011) on aura des articles où 2010 correspond à un recensement intermédiaire, en théorie ces données ne seraient du coup plus à référencer, puisqu'elles ne sont plus affchées. Aline a résolu le problème en renvoyant vers des pages génériques, pour ma part en référençant toutes les années depuis 2006, car après tout il s'agit de populations légales. Mais mon modèle n'est que sur les articles détaillés des communes du Loiret.Roland45 (d) 24 février 2013 à 14:24 (CET)[répondre]
J’aurais plutôt écrit « contourné » le problème, mais même comme ça on ne décrit pas la manœuvre, puisqu’on n’arrive pas au but, référencer toutes les données présentes, de manière correcte, et rien qu’elles. On peut envisager plusieurs solutions :
puisqu’on a un paramètre restrictif, déjà renseigné pour un certain nombre de communes, on peut envisager de modifier la manière dont il est utilisé et présenté par le modèle. Cela permet d’améliorer la présentation (j’espère jusqu’à une présentation correcte), et de ne pas refaire ce qui a déjà été fait ;
réécrire le modèle pour qu’il présente bien les sources. Je n’ai pas mis le nez dedans, donc je ne sais pas ce qui est possible ;
réécrire le modèle pour qu’il nous permette de bien présenter les sources (ou au moins laisser un champ libre, puisque de toute façon il faut envisager d’autres sources qu’Insee et EHESS).
En tout cas, l’esprit wiki est la légèreté qui permet d’aller loin et bien, et pas l’antériorité de la technique. J’espère que l’on pourra trouver une solution satisfaisante qui permette d’avancer dans cette direction. Azoée (d) 24 février 2013 à 15:48 (CET)[répondre]
Il faut bien suivre tous les débats. Le débat sur la forme est plutôt ici. Si tu veux intervenir sur cet aspect, je pense que c'est le lieu le plus adapté. Ici c'est plutôt le code (et le code en question est complexe, car ce n'est pas du simple sourçage avec {{Lien web}} en clair). Plusieurs formes des notes et sources liées au tableau sont indiquées (en sus de la discussion propre à la forme du tableau). Si on retient la forme préconisée par @Pere Igor, on aboutit au code ci-dessous.
Merci : si tu lis bien ce débat que tu pointes, il est demandé de venir discuter ici des propositions de modifications, alors que j’avais commencé là-bas ! Donc vous êtes gentils avec Wikialine, mais après avoir commencé cette discussion sur CdF, l’avoir repris ici laborieusement, quand on aborde le cœur du sujet, tu me dis de repartir sur CdF si j’ai bien compris, et en plus c’est de ma faute parce que je ne suis pas ? Mettez-vous d’accord, et si vous n’avez pas envie de changer le modèle, dites le directement, ça nous épargnera du temps. Ce soir, entre JPS68 et ces aller-retours, j’ai vraiment l’impression de faire des efforts pour rien. Azoée (d) 24 février 2013 à 21:56 (CET)[répondre]
Je pense que tu plaisantes. Tu as peut-être vu quand même qu'il y a du code sur cette page, ça veut dire qu'on essaye de changer le modèle. Et écrire du code c'est autre chose que d'écrire 3 mots dans une pdd pour râler. Avant d'écrire 3 mots dans du code, plus d'une fois on passe une heure à chercher auparavant (tout au moins pour moi qui ne suis pas programmeur de naissance)!. Quant à savoir où tu dois écrire sur la forme, il me semble qu'actuellement c'est sur l'autre page que ça se passe.Roland45 (d) 24 février 2013 à 22:13 (CET)[répondre]
Réellement, quand je lis le titre des sections précédentes (Rajout de point et de majuscules manquantes), j’ai réellement l’impression qu’on parle aussi de forme ici. Et je pense réellement que les références de ce tableau sont mal présentées. Merci de mettre tes compétences techniques au service de la communauté, mais peut être que dans d’autres domaines aussi nous avons de la rigueur et qu’elle peut être utile à l’amélioration du modèle ? Azoée (d) 10 mars 2013 à 21:59 (CET)[répondre]
Le code
Sur la base de la proposition de Pere Igor, le code peut être, pour un article dont le titre n'est pas précisément le nom WP de la commune, le suivant. Attention, dans ce cas où le titre n'est pas le nom de la commune, on est obligé d'entrer des paramètres extérieurs (nom de la commune/code insee Ainsi pour Moulon, dans le Loiret, on écrira {{D-tableau2|nom=Moulon_(Loiret)|dep=45|insee=45219}} (D-Tableau2 étant le modèle dérivé du modèle d'Aline), et on obtiendra ceci
. |notes= De 1962 à 1999 : [[Chiffres de population de la France#Aspect statistique|population sans doubles comptes]] ; à partir de 2006 : [[Chiffres de population de la France#La population municipale|population municipale]] [[Chiffres de population de la France#Aspect législatif|légale]].
|sources=Ldh/[[École des hautes études en sciences sociales|EHESS]]/Cassini{{#if:{{Modèle:Données/{{{nom|}}}/évolution population|source1}}|<ref name="Cassini">[{{Modèle:Données/{{{nom|}}}/évolution population|source1}} Des villages de Cassini aux communes d'aujourd'hui] sur le site de l'École des hautes études en sciences sociales.</ref>}}, jusqu'en 1962 puis [[Institut national de la statistique et des études économiques|Insee]] : 1968-1999 {{#tag:ref|[http://www.statistiques-locales.insee.fr/Fiches/DL/{{#switch:{{{type|}}}|dep = DEP/DL-DEP{{{dep|}}}|arr = ARR/DL_ARR{{{insee|}}}|can = DEP/{{{dep|}}}/CV/DL_CV{{{insee|}}}|DEP/{{{dep|}}}/COM/DL_COM{{{insee|}}}}}.pdf Évolution et structure de la population (de 1968 à la dernière population légale publiée)] sur le site de l'Insee.}}{{,}} {{#tag:ref| Fiches Insee - Populations légales {{#switch:{{{type|}}}|dep = du département|arr = de l'arrondissement|can = du canton|de la commune}} pour les années
[http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/populations-legales/{{#switch:{{{type}}}| can|arr|dep=departement.asp?dep={{{dep|}}}| #default=commune.asp?depcom={{{insee|}}}}}&annee=2006{{#switch:{{{type}}}| can=#pop_can| arr=#pop_arr}} 2006], [http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/populations-legales/{{#switch:{{{type}}}| can|arr|dep=departement.asp?dep={{{dep|}}}| #default=commune.asp?depcom={{{insee|}}}}}&annee=2007{{#switch:{{{type}}}| can=#pop_can| arr=#pop_arr}} 2007],
[http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/populations-legales/{{#switch:{{{type}}}| can|arr|dep=departement.asp?dep={{{dep|}}}| #default=commune.asp?depcom={{{insee|}}}}}&annee=2008{{#switch:{{{type}}}| can=#pop_can| arr=#pop_arr}} 2008],
[http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/populations-legales/{{#switch:{{{type}}}| can|arr|dep=departement.asp?dep={{{dep|}}}| #default=commune.asp?depcom={{{insee|}}}}}&annee=2009{{#switch:{{{type}}}| can=#pop_can| arr=#pop_arr}} 2009],
[http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/populations-legales/{{#switch:{{{type}}}| can|arr|dep=departement.asp?dep={{{dep|}}}| #default=commune.asp?depcom={{{insee|}}}}}&annee=2010{{#switch:{{{type}}}| can=#pop_can| arr=#pop_arr}} 2010]
}}}}|<hr style="border:1px dashed red;" />
<center>
La référence à Cassini est en ref n°3, celle à l'Insee en n°5 (ou 1 et 3 dans cette page)(toutes les années compactées sur une seule ligne).Roland45 (d) 24 février 2013 à 16:23 (CET)[répondre]
C'est sympa de se référer à mes préconisations. Je suis perdu dans le code mais pourrait-on, histoire d'être plus crédibles, lier dans l'exemple ci-dessus la référence EHESS à celle de Moulon (notice n° 24224) et non celle de Lille ? Père Igor (d) 24 février 2013 à 18:03 (CET)[répondre]
C'est capricieux, ces petites bêtes de modèles. Il leur faut pas grand chose pour refuser de marcher. J'ai eu du mal à trouver pourquoi Lille s'affichait non seulement sur Moulon, mais sur les autres articles. Mais bon, ça y est.Roland45 (d) 24 février 2013 à 21:39 (CET)[répondre]
J’avais déjà fait une demande il y a quelques mois, mais il me semble important, quand ils existent, de pouvoir intégrer des dénombrements d’Ancien Régime. Cela permet d’allonger la série, parfois avec une demi-douzaine voire une dizaine de dates. Qu’en est-il de la réflexion ? Azoée (d) 10 mars 2013 à 22:02 (CET)[répondre]
Il me semble que ça ne pose pas de problème technique, puisqu'il suffit de rajouter des dates et des valeurs correspondantes (ça peut par contre poser un problème pour le graphique, si on remonte trop loin dans le temps, puisque ça « écrase » graphiquement les nombreuses valeurs depuis 1793). Par contre, si je me souviens bien, ça pose un problème éditorial, puisque la notion de recensement exposée dans les tableaux démographiques est celle d'un recensement « moderne » (se voulant exhaustif, ou plus récemment s'appuyant sur la science des statistiques). Pour l'Ancien Régime, il le semble que le mode de décompte est déductif (à partir d'un nombre de feux), mais là je m'avance sur un terrain que je connais mal. Je me rappelle juste que tout le monde n'est pas d'accord pour mélanger les valeurs d'avant 1793 et celles d'après. Pour ma part, je trouve plus judicieux d'écrire un paragraphe avant la partie « depuis 1793 », avec éventuellement la création d'un autre tableau s'il y a beaucoup de valeurs à présenter.--Rehtse (d) 11 mars 2013 à 00:56 (CET)[répondre]
attention avant la révolution de 1789, il me semble que les registres étaient tenus par les paroisses et non par les communes; je ne vois pas très bien comment on va pouvoir faire un rapprochement entre ces deux notions surtout pour les villes ... la prudence impose de se rappeler que « le mieux est l’ennemi du bien » ... Pano38 (d) 11 mars 2013 à 08:19 (CET)[répondre]
Je suis bien d'accord, ça rejoint ce que j'écris (mais je formule sans doute mal). Je répondais juste que ce n'est pas un problème technique, mais éditorial. Tout dépend si on considère les infos sourcées concernant avant 1789 comme de la démographie, ou de l'histoire. Ça ne me choquerait pas de voir en section démographie une partie retraçant l'évolution antérieure, dans une sous-section distincte pour ne pas créer de confusion. Mais je comprend aussi qu'on puisse préférer créer cette sous-section en Histoire.--Rehtse (d) 11 mars 2013 à 08:54 (CET)[répondre]
Je vois difficilement comment dans un article qui concerne une commune actuelle on va pouvoir faire un rapprochement avec les paroisses d’avant 1789. Il faudrait faire comme nos amis Québecois et créer des articles paroisses différents de commune, mais cela me semble assez compliqué du fait que ces archives sont des archives papier qui doivent être consulté dans chaque église et que beaucoup on été brulées en 1789 ... est-ce indispensable? Pano38 (d) 11 mars 2013 à 09:06 (CET)[répondre]
C'est un point de vue. Mais très souvent, la délimitation des paroisses a été la base de celle des communes. (Juste pour dire : la commune de Nantes a vu son étendue modifiée au fil du temps, par absorption d'autres communes ; ça n'empêche pas de faire figurer toutes les données dans le même tableau, alors que ces chiffres ne correspondent pas au même territoire.) Et, de la même manière que ça ne gène personne que la section histoire ne traite pas que la période depuis 1793 (commencer à cette date comme s'il n'y avait rien eu avant paraîtrait très étrange...), ça ne dérange pas tout le monde que des données sur estimations de population sous l'Ancien Régime apparaissent quelque part dans l'article. D'ailleurs, ça se fait déjà ; je peux, encore une fois, comprendre que ça gène, ou que ça ne paraisse pas indispensable, mais c'est un point de vue, d'autres voient les choses autrement, et du moment que c'est sourcé, je ne vois pas de raison de l'interdire. L'objet de la présente discussion est plutôt de savoir où placer ces informations.--Rehtse (d) 11 mars 2013 à 14:19 (CET)[répondre]
<conflit d’Édith>Alors, quelques précisions sur la démographie historique :
les recensements par tête, et non par feux, ont commencé à être fait au XVIIIe siècle, et on en trouve d’assez nombreux, mais tous partiels (une subdélégation, une province, voire quelques provinces). Ils comportent des renseignements complémentaires, et sont tout aussi exploitables que les premiers de la série générale (1793, 1800, 1821...) puisque effectués avec les mêmes méthodes ou des méthodes voisines, qui ont évolué graduellement et ne sont pas nées spontanément en même temps que la Révolution ;
auparavant, on avait de grands dénombrements par province, comptabilisant les feux (c’est à dire, les familles) ou parfois par maison habitée. Le premier dénombrement national date de 1315. Là, les historiens trient entre les dénombrements complets, et ceux à visée uniquement fiscale, où de nombreux villages font déduire des foyers pour diminuer l’imposition totale de la communauté. Mais là, nous n’intervenons pas, nous suivons les historiens. Soit ils jugent possible de retenir un chiffre, ou non. Évidemment, dans le second cas, je ne reprend pas le chiffre du recensement ;
dans les articles actuels, on mélange déjà des recensements aux méthodologies très différentes. Entre les registres de la période révolutionnaire, les questionnaires remplis par les maires au XIXe (et qui donnent parfois trois ou quatre recensements d’affilée avec un chiffre rond), les populations sans doubles comptes du XXe et les recensements interpolés du XXIe, on a déjà un joyeux mélange ;
les historiens, dont le père de la démographie historique Édouard Baratier, dont les méthodes sont toujours utilisées, juxtaposent ces recensements (par exemple, pour la Provence dans l’Atlas historique), pour chaque commune on a les chiffres de 1315, 1471 (en feux et en habitants), 1765, 1851 (qui correspond à un maximum historique dans les campagnes) et 1968. Ces cinq enquêtes sont menées avec des méthodes différentes, pourtant des noms comme Duby, codirecteur de l’Atlas, ont vu un grand intérêt de les faire figurer dans l’ouvrage ;
il existe des coefficients fiables pour retrouver le chiffre d'une population à partir des feux. Globalement, c’est 5, avec des variations ville/campagne et régionales. Par exemple, dans le Nord, c’est 5,5 en campagne et 4,5 en ville ; en Provence et en Italie, c’est le contraire. Ce coefficient, établi dans les années 1960, a été recoupé et fiabilisé, et est encore retenu comme pertinent au bout de 50 ans de recherches historiques [1].
Après, il existe des communes pour lesquelles on dispose d’une dizaine de recensements anté-1793. Vaut-il mieux, pour celles-ci, placer un tableau démographie historique dans la section Histoire ? Et où arrêter ce tableau ? 1792 ? 1800 ? Azoée (d) 11 mars 2013 à 14:42 (CET)[répondre]
Il y a là actuellement, à mon sens, une sorte de gros bug avec les sections démographie des communes: les données antérieures à 1793 tendent à être systématiquement supprimées!! Or bien sûr l'histoire des villes et villages de France, qui est traitée par les articles des communes, ne commence pas en 1793... Leur démographie non plus. Les données antérieures à 1793 sont même en fait beaucoup plus précieuses que celles postérieures car plus difficiles à trouver (pour celles postérieures à 1793 il suffit de consulter les bases Ldh/EHESS/Cassini ou de l'INSEE).
Le chiffre en feux de 1789, dument sourcé, est rétabli par moi en 2012 après le même vandalisme involontaire de NonaBot : [6]
Cette donnée, ainsi que la note qui l'accompagnait, est purement et simplement supprimée en 2013 par AntonyB : [7]
Le modèle Démographie2 permettait de gérer dans un même tableau toutes les données démographiques, quelle que soit la date et que les chiffres soient en habitants ou en feux (d'ailleurs la gestion des populations d'Ancien Régime était l'une des raisons pour laquelle j'avais créé ce modèle), et d'ajouter très facilement des années anciennes. Le modèle Démographie, qui a repris les évolutions apportées par Démographie2, permet toujours de le faire mais les modèles intermédiaires Projet:Communes de France/Modèles de données évolution population apparemment ne gèrent pas cela... Je ne sais pas si l'impasse a été faite volontairement ou bien si c'est un oubli dans ces modèles.
Quoiqu'il en soit, je m'insurge contre la suppression dans les articles des précieuses données antérieures à 1793. Ce sont des données démographiques qui ont toute leur place dans la section démographie (et où elles ont mieux leur place qu'en section histoire). On peut scinder le tableau en deux si la gestion des données dans un même tableau pose maintenant des problèmes techniques mais je trouve très embêtant que divers contributeurs effacent des articles les données d'Ancien Régime.
Que faire pour retrouver dans quels articles ces données ont été supprimées et les rétablir? Et que faire pour que les contributeurs (et spécialement les honorables participants du Projet Communes de France) arrêtent de supprimer les données démographiques d'Ancien Régime? -- Carfois (d) 15 janvier 2014 à 02:59 (CET)[répondre]
Merci azoée pour le lien vers ton exemple où je vois que c'est encore un autre contributeur qui avait voulu supprimer supprimé (edit suite à remarque ci-dessous) purement et simplement les données de population d'Ancien Régime (modif de Marianne Casamance). Décidément certains des contributeurs qui mettent en place les modèles de rédaction automatique de section démographique ne semblent pas se soucier du tout de conserver le précieux contenu des données d'Ancien Régime! Heureusement que tu étais là pour veiller au grain ! Malheureusement il n'y a pas quelqu'un pour "surveiller" chaque commune et les 2 exemples de suppression que j'ai signalés plus haut étaient passés inaperçus et ont bien failli le rester. Je pense que pas mal de ces données d'Ancien Régime ont été définitivement perdues des articles car personne ne va aller maintenant rechercher dans les milliers d'articles de communes là où il y a eu de telles suppressions. Je vais prévenir les contributeurs concernés pour les sensibiliser et comprendre si c'est volontaire ou par erreur qu'ils suppriment ces données.
Bonjour, Je n'ai pas voulu supprimer « purement et simplement les données de population d'Ancien Régime » ! Tu aurais pu avoir la délicatesse d'attendre ma réponse avant de l'affirmé ! Que fais tu de la bonne foi. Mais passons. Je n'ai, il y a près d'un an, que mise en place le modèle {{Section démographie d'article de commune de France}}, certes qui peu être améliorer. La seule question est : comment automatiser les mises à jours des données de démographies actuelles, dans les tableaux de plus de 36.000 communes (pour ma part, par le biais des modèles), sans perdre les données de l'ancien régime. Car cher Carfois (d · c · b), le problème vient visiblement de là, et non d'une volonté de « suppressionité aigüe et volontaire (ou pas) » de certains contributeurs ? Marianne Casamance (discuter) 17 janvier 2014 à 08:05 (CET)[répondre]
D'après ce que j'ai vu, il y a au moins trois façons de présenter cela :
une phrase en section Histoire, qui indique « En xxxx, Saint-Tonlieu comptait xx habitants/feux (en xxxx, 18). », phrase qui peut/est parfois répétée en section Démographie. C'est ce que j'ai fait pour certaines communes du 36 et du 18, pour lesquelles je n'avais que deux dénombrements du début du XVIIIe siècle ;
un tableau supplémentaire en section Démographie : cela déconnecte totalement les deux périodes avant/après 1793, et donc permet de traiter facilement les modèles à mise à jour automatique et logiquement de conserver ces données rares. C'est ce qui a été fait dans les Pyrénées-Orientales, en suivant la source historique (CNRS, donc bon niveau) ;
tout intégrer dans un seul tableau. C'est ce qui existe pour certaines communes de la Haute-Saône, et ce que j'ai fait pour le 04, cela obligeant à maintenir le modèle Démographie2 et à faire de la maintenance dans les pages Données des articles. J'ai suivi pour cela ma source, qui présentait des recensements de 1315, 1471, 1540, 1765, 1851 et 1968, les chiffres de population pour 1315 et 1851 étant souvent proches et correspondant à deux maximums démographiques et à deux apogées de l'économie rurale.
Je n'ai pas de règle absolue : intégrer le recensement de 1765 dans Modèle:Données/Nom_commune/évolution population permet d'allonger l'histogramme de population avec des chiffres pas trop éloignées, donc un blanc pas trop important (28 ans). Si dans d'autres communes, les recensements d'Ancien Régime ne datent que du début du XVIIIe, voire du XVIIe (comme souvent pour la Haute-Saône), l'ajout de ces chiffres dans le Modèle:Données rendrait le graphique peu lisible (à cause d'un grand blanc entre 1650 et 1793 et à cause du tassement des barres des recensements de 1831 à 1936 ; après 1936, les recensements sont plus espacés, donc le problème s'estompe sans disparaître). azoée (discuter) 17 janvier 2014 à 10:22 (CET)[répondre]
Tout à fait d'accord avec toi azoée sur les 3 manières, en l'état actuel des modèles, de traiter les cas de communes ayant des données de population d'Ancien Régime. Je pense que la section démographie est par définition la plus appropriée pour ces données, quitte à les répéter en cas de besoin spécifique en section histoire.
Marianne Casamance (d · c · b), autant pour moi, je m'étais mal exprimé et ai corrigé ci-dessus mon propos. D'ailleurs sur le message laissé dans ta page de discussion j'avais bien précisé « Je ne sais pas si c'était volontaire ou non (...) et je sais aussi que cela avait été peut-être fait par inadvertance au cours d'une modification plus globale qui en tout cas partait d'une bonne intention pour améliorer un article ». Je ne sais pas qui tu cites dans tes guillemets qui parlent de volonté de « suppressionité aigüe et volontaire (ou pas) » mais ce n'est en tout cas pas moi contrairement à ce que pourraient faire croire tes guillemets dans une phrase qui m'est adressée. Merci de ne pas m'attribuer des propos qui ne sont pas les miens.
Je ne critique pas non plus le fait en soi d'ajouter les nouveaux modèles dans les articles comme le modèle {{Section démographie d'article de commune de France}}. Au contraire, c'est une bonne chose d'automatiser les mises à jour des populations. Ce que je critique est le fait de remplacer aveuglément les anciennes sections Démographie des articles par ces modèles, sans reprendre le contenu de l'article. Car le modèle ne préserve pas automatiquement le contenu, il faut le faire manuellement dans la page de données du modèle lorsque c'est possible, ou dans la section de l'article lorsque le modèle n'est pas adapté aux données (cas des populations en feux qui, sauf erreur de ma part, ne sont pas supportées par le modèle). Il y a au moins trois façons de préserver le contenu comme indiqué par azoée ci-dessus, dont deux qui utilisent le modèle {{Section démographie d'article de commune de France}} ou ses sous-modèles. -- Carfois (d) 17 janvier 2014 à 11:41 (CET)[répondre]
Pour info, voilà ce que je répondu ce matin à Carfois (autre discussion mais sur le même sujet) à la suite de ses judicieux signalements (relatifs aux articles consacrés aux communes Noisseville, Mey et Nouilly) :
Voilà c'est fait, j'ai corrigé comme demandé. Mais je n'ai bien sûr pas remis le graphique d'origine pour Noisseville, graphique qui était faux, faux et archi-faux du point de vue statistique. Il me semblait que depuis 2008, tous ces types de graphique avaient été retirés. Cet article avait dû passer entre les mailles des filets de correction. J'ai par ailleurs corrigé les données passées lorsqu'elles étaient erronées. Ce qui me confirme une fois de plus que cette façon de faire (i.e. d'ajouter le nombre de feux dans le tableau générique) ne me semble vraiment pas la meilleure, d'autant que les années indiquées n'étaient pas les bonnes années de recensement. Bref, je persiste à penser que la meilleure façon de faire est d'utiliser tableau+diagrammes générés automatiquement car on est sûr que les données/années sont correctes, puis ajouter tout le texte qu'il convient, référencé par la source ad-hoc, pour le nombre de feux avant 1793. Et même si on conserve ces pages telles que je les ai remises en l'état, qui va s'engager à ce qu'elles soient mises à jour une par une dans les années à venir, et cela en prenant bien soin de faire figurer les bonnes données avec les bonnes années de recensement ??? Cordialement. AntonyB (discuter) 17 janvier 2014 à 14:28 (CET)[répondre]
Merci AntonyB pour tes commentaires et le rétablissement des données d'Ancien Régime, et la correction de deux données en effet erronées pour Noisseville.
Je suis tout à fait d'accord avec toi que la solution de mettre dans l'article le tableau qui ne reprend pas les données de la feuille de données n'est pas une solution satisfaisante. J'essaierai, lorsque j'aurai le temps, de faire un modèle de tableau qui permette d'afficher les données de la feuille de données tout en affichant les populations d'Ancien Régime (qui seraient stockées soit sur la feuille de données, soit dans l'article au niveau de l'appel du modèle de tableau). Ce n'est probablement pas difficile à faire. Comme toi je suis en faveur des solutions qui permettent la mise à jour automatique.
En revanche sur la question du type de représentation graphique, je ne partage pas ton point de vue sur les courbes. Je pense que la représentation sous forme de courbe est tout à fait pertinente et au moins autant que celle sous forme d'histogramme. Voir mes explications très détaillées sur Discussion modèle:Graphique population d'article de commune de France#Histogramme ou courbe?. Il ne faut pas perdre de vue qu'une représentation graphique de l'évolution de la population n'est qu'une représentation graphique et n'a pas pour objet d'effectuer une analyse statistique mais seulement de faire ressortir visuellement une évolution démographique. La représentation sous forme de courbe n'est pas fausse, c'est son interprétation qui éventuellement peut être fausse (si par exemple on considérait les points des droites comme la meilleure estimation possible de la population à un instant t, ce qu'ils ne sont pas forcément en effet car des méthodes mathématiques d'analyse statistique associées à une analyse démographique spécifique à la commune permettraient d'obtenir une meilleure estimation). A noter que les diagrammes en histogramme ne sont pas totalement exempts non plus de possibilité d'erreur d'interprétation (si par exemple on considérait que l'absence de barres signifiait une absence de population). Comme je l'ai exposé dans la discussion que j'ai citée plus haut, la courbe est aussi en sciences démographiques la manière habituelle de représenter l'évolution au cours du temps d'un nombre d'habitant. -- Carfois (d) 17 janvier 2014 à 15:11 (CET)[répondre]
Voilà, j'ai créé un modèle de tableau qui permet à la fois d'afficher les données présentes en page de données de la commune et à la fois d'afficher quelques années supplémentaires (celles des dénombrements d'Ancien Régime par exemple) passées directement en paramètre du tableau:
Je l'ai inséré sur Gionges pour donner un exemple.
Qu'en pensez-vous? Si cette évolution du modèle actuel est jugée utile, il suffit de mettre à jour le modèle actuel et sa doc avec cette petite évolution. -- Carfois (d) 18 janvier 2014 à 03:30 (CET)[répondre]
Personnellement, je suis pour une séparation stricte des tableaux, avec les feux d'un côté, nécessitant une explication spécifique avec lien vers l'articlefeu fiscal pour le lecteur, et la population de l'autre. Père Igor (discuter) 18 janvier 2014 à 12:37 (CET)[répondre]
Bonjour. Je plussoie à la proposition de Père Igor, comme déjà dit plusieurs fois ; de toute façon l'histogramme ne démarre qu'en 1793. Merci encore, la sagesse serait-elle de retour ? Cordialement.
Je suis d'accord aussi avec la proposition de Père Igor. J'y vois en effet un triple avantage:
d'être applicable à tous les articles, quelle que soit la situation d'Ancien Régime du territoire communal (1 ou plusieurs paroisses, etc.) ;
vertu pédagogique: inciter le rédacteur à expliquer les spécificités de ce temps là (et le lecteur à se poser des questions) ;
avoir des tableaux principaux plus homogènes d'un article communal à l'autre, puisque limités donc à la période post-1793.
Le seul inconvénient que je vois est que du coup dans les cas particuliers où un tableau et/ou un graphique aurait été particulièrement pertinent sur une période plus longue, on perd cette vision plus long terme. Mais les avantages me paraissent dépasser l'inconvénient, et surtout les cas particuliers peuvent toujours être traités avec un graphique et/ou un tableau et/ou un article supplémentaire si nécessaire.
C'est le cas par exemple de Paris, où l'article dédié Démographie de Paris présente un tableau allant de l'an 250 à nos jours. Dans ce tableau la donnée la plus récente n'était toutefois aujourd'hui pas jour (2010 au lieu de 2011). Alors le modèle modifié pour autoriser l'ajout de données supplémentaires aurait-il quand même une utilité pour ces cas particuliers, non pas pour créer des tableaux principaux mais pour créer le cas échéant des tableaux supplémentaires qui restent mis à jour automatiquement? Si jamais vous y voyez un intérêt on peut modifier le modèle. En attendant je viens de traiter le cas de Démographie de Paris en conservant l'utilisation directe du modèle {{Démographie}} mais en paramétrant la dernière case pour aller lire la dernière valeur connue dans la page de données (voir diff). -- Carfois (d) 19 janvier 2014 à 11:43 (CET)[répondre]
Rapport d’utilisation
vous en ferez ce que vous voudrez, mais je le fais ici, j’imagine que le climat est plus favorable à la discussion.
J’ai testé quelques uns des modèles liés à ce projet :
sur l'utilisation de {{Dernière population commune de France}} : très bon, sur 200 articles un seul souci (déjà signalé plus haut). À ne pas négliger toutefois, car à l’échelle de la France 200 articles ou plus avec le modèle mais une population non-actualisée ça commence à devenir gênant ;
j’ajoute donc petit à petit le modèle de graphique sur les communes des Alpes-de-Haute-Provence, ce qui remplace avantageusement les courbes qui arrivaient en bout de course (finalement pas si difficile à mettre à jour, mais bon). Et là je tombe sur des Données mises à jour incorrectement : Le Fugeret (Données), Aiglun (Données), idem pour Allemagne-en-Provence (Données). À chaque fois une base incomplètement mise à jour. Alors, un petit passage supplémentaire d’Alinebot ?
Sur les Alpes-Maritimes non plus, aucun tableau de données n’est mis à jour correctement
Et j’ai l’impression que c’est aussi le cas pour la Vienne
Attention à ne pas mélanger certaines notions. Il a été retenu de n'afficher que les recensements exhaustifs. Ainsi pour Allons, le premier recensement a eu lieu en 2008 et les suivants auront lieu en 2013, 2018, etc. Ainsi la population de 2010 est un recensement intermédiaire. Donc pour cette commune, il convient bien de garder la population de 2008 (131 habitants) et ne pas inscrire dans le dur l'année 2010. Il n'y avait pas donc lieu de reverter le travail d'Alinebot. Je vais reverter cette modif. Et c'est semble-t-il la même chose pour les autres communes incriminées. Cordialement.Roland45 (d) 18 mars 2013 à 08:24 (CET)[répondre]
OK, je vais réverter. Y-a-t-il un endroit où ces dates de recensement ferme sont notées, afin de mettre un commentaire à chaque fois ?
Pour chaque département, les dates des recensements peuvent être trouvées dans des pages comme celle-ci. Il suffit de changer le numéro du département souhaité dans l'adresse pour avoir le calendrier que l'on souhaite. Cordialement.Roland45 (d) 18 mars 2013 à 13:59 (CET)[répondre]
Ou plus exactement, le calendrier de l'Insee affiche la date du prochain recensement (exemples : « Chaque année » correspond à une commune de + de 10 000 habitants recensée partiellement tous les ans ; pour celles de moins de 10 000, on peut avoir « 2013 », recensement réel effectué en 2008 ; « 2014 », recensements réels effectués en 2004 (population provisoire) et 2009 ; « 2015 », effectués en 2005 (population provisoire) et 2010 ; « 2016 », effectués en 2006 et 2011). Père Igor (d) 18 mars 2013 à 15:29 (CET)[répondre]
Pour Aiglun, les recensements ont lieu en 2007 et 2012. Les deux recensements affichés sont ceux de 2010 (logique, celui de 2012 n’est pas publié), et de 2006. Là, ça me pose question. Il était bien prévu de n’afficher que les recensements exhaustifs et la dernière estimation ?
Pour Allons, les recensements ont lieu en 2008 et 2013. Et là, on affiche 2008 (là ça me semble logique), 2006 (d’où il sort celui-là ?) et pas 2010. D’où requestions. Azoée (d) 1 avril 2013 à 17:38 (CEST)[répondre]
Bonjour Epi, le choix des dates a fait l'objet de nombreux débats. Aujourd'hui la règle est de ne retenir que les recensements réels (dans les paramètres anX et popX, X étant un nombre) et de mettre temporairement chaque année le dernier recensement (exhaustif et partiel) dans les paramètres an et pop pour la totalité des communes. Au départ, on était partie sur l'ajout systématique des dates, on a également étudier des possibilités de sélection d'affichage des données par les modèles mais ce fut trop complexe... Il y avait aussi ces histoires de recensements intermédiaires pour certaines communes qui ont eu lieu vers 2004 ou quelque choses comme ça, l'année 2006 a été mise pour toute les communes. A présent les règles sont plus claires, pour ceux qui le souhaitent, ils peuvent retirer 2006 si ce n'est pas un recensement réel.Pour ce qui est de Allons (Alpes-de-Haute-Provence). Le bot a bien mis temporairement l'année 2010 dans les paramètre an et pop. Par contre le bot n'a pas ajouté de paramètre anX et popX, car (semble-t'il, 2010 n'est pas une année de recensement réel pour cette commune. Le bot met à jour bêtement les modèles de données que l'on a décidé préalablement de mettre à jour. Pour ce faire, s'agissant des recensements réels, le bot utilise les tables Utilisateur:Alinebot/index table annuels et Utilisateur:Alinebot/index table 2010. Comme cette année ce fut la 1ère année où le bot allait fonctionné normalement (on a terminé de créer les modèles de données, de rapatrier les données de Cassini...), j'ai bien pris soin de prévenir tout le monde (ici, ici et ici) pour la mise à jour des recensements réels de 2010 en indiquant les tables que je viens de citer, afin qu'il n'y ait pas de soucis sur le choix des communes. Pour ce qui est du choix des communes concernés par des recensements réels, je ne suis pas assez compétente, Roland s'occupe de cette partie, il maitrise bien ce sujet. Parles en avec lui pour voir ce qu'il en est. amicalement--Wikialine (d) 1 avril 2013 à 18:36 (CEST)[répondre]
Je n'ai pas envie de te dire de bêtises. Je ne suis pas assez pointu sur la question. Vois avec Roland45 qui utilise également le site de l'Insee pour produire les tables. Vous pourrez comparer les sources que vous avez chacun de votre coté. Et on avisera. amicalement--Wikialine (d) 1 avril 2013 à 19:01 (CEST)[répondre]
Mises à jour à venir
Liste (non définitive que je vais tenir à jour ici) des mises à jour à venir pour le modèle section démographique :
Suppression de la référence : « Évolution et structure de la population (de 1968 à 2007) sur le site de l'Insee. » (suite à la mise en place du référencement automatique)
Suppression de la référence : « Recensement de la population au 1er janvier 2006 sur le site de l'Insee. » (suite à la mise en place du référencement automatique)
Celle où il y a écrit : « Fiche Insee - Populations légales de la commune pour les années 2006, ... » et qui succède aux références : « Évolution et structure de la population (de 1968 à 2007) sur le site de l'Insee. » et « Recensement de la population au 1er janvier 2006 sur le site de l'Insee. ».amicalement--Wikialine (d) 20 mars 2013 à 21:23 (CET)[répondre]
Pour les années depuis 2006, on a effectivement un lien de l'Insee par commune et par année. J'utilise à la place ce lien qui a deux avantages : 1°) pour un département, pas de champ communal à modifier ; 2)° celui de rassembler les populations municipales des communes, des cantons, des arrondissements et du département pour une année donnée sur le même document. Il suffit qu'il soit utilisé une seule fois sur une commune ou une autre division administrative pour qu'il reste disponible dans wikiwix, pour tout autre commune ou division administrative, même si on ne l'utilise que plusieurs années plus tard sur un autre article. Par ailleurs, j'utilise sur presque tous mes tableaux manuels l'évolution et la structure de la population de 1968 à 1999 de l'Insee, dont les chiffres sont parfois différents de ceux de l'EHESS, notamment pour 1999. Ça se traduit comment, le référencement automatique ?
Techniquement ça paraît possible d'ajouter automatiquement 2 nouvelles références que sont :
La difficulté consiste à trouver pour chaque commune son n° de département. En connaissant déjà le code Insee de chaque commune grâces aux modèles de données, on peut logiquement retrouver le n° de département en procédant ainsi par exemple pour la commune de Bergerac (code commune 24037) : 24037 /1000 puis arrondir le résultat en supprimant tous ce qui est après la virgule ce qui donnera donc 24 soit le n° de département. Donc techniquement ça me paraît faisable. Maintenant, est ce vraiment utile de multiplier les références ? Actuellement la référence automatique que génère le modèle section dont le lien mène vers une url de cette forme :
présente un gros avantage. Comme tu peux le voir dans cette url, il suffit de modifier la date et le code insee soit 2 informations que l'on a déjà. Je crois que l'adresse http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/populations-legales/departement.asp?dep=24&annee=2010 serait un doublon dans nos articles de communes. En revanche, cette adresse serait intéressante à retenir pour les articles de collectivités supérieures (région, département...). On n'a pas encore automatisé ces articles mais on pourrait parfaitement le faire et encore plus facilement grâces à cette adresse. Par contre l'adresse http://www.statistiques-locales.insee.fr/Fiches%5CDL%5CDEP%5C24%5CCOM%5CDL_COM24037.pdf que tu utilises pour présenter l'Évolution et structure de la population, me paraît intéressant. Cette adresse deviendra essentiel à l'avenir lorsque l'on tentera d'ajouter les pyramides des ages automatiques ainsi que d'autres informations éventuelles qui pourraient figurer sur cette page. Donc, si tu y tiens vraiment je peux tenter d'ajouter une référence supplémentaire qui mènerait vers l'adresse http://www.statistiques-locales.insee.fr/Fiches%5CDL%5CDEP%5C24%5CCOM%5CDL_COM24037.pdf en anticipation sur l'ajout futur de pyramides et autres informations possibles. Je l'ajouterai si tu me le demande. amicalement--Wikialine (d) 21 mars 2013 à 23:55 (CET)[répondre]
Ce qui me gêne, c'est ta volonté de niveler systématiquement les tableaux en modèles prédéfinis où l'humain, hormis toi, n'intervient plus. Je me sers du modèle:Démographie2 pour les articles des anciennes communes et il faut donc que la partie notes et/ou sources(s) soit libre pour moduler les informations (voir Sireuil (Dordogne) et Saint-Pardoux-de-Mareuil. Quant au lien PDF, je l'utilise également dans la partie économie des communes où je me réfère aux tableaux EMP T2 et EMP T4 de la page 5 pour les actifs et les chômeurs et au tableau CEN T1 page 16 pour la répartition des établissements et leur type sur la commune (voir exemple sur Dussac). Père Igor (d) 22 mars 2013 à 10:52 (CET)[répondre]
Le modèle section est surtout utile pour les communes actuelles et non pour les anciennes communes (même si il est potentiellement utilisable). Pour les anciennes communes il vaut mieux utiliser des modèles comme {{Démographie2}} (où tu mets ce que tu veux dedans avec les couleurs, les références, les sources et la forme que tu veux, bref la liberté où l'harmonisation des articles de communes françaises est laissé aux critères subjectifs de chacun) ou {{Tableau population}} qui est un dérivé de {{Démographie2}} qui encadre la forme du tableau afin de respecter progressivement les chartes graphiques, la forme va d'ailleurs évoluer suivant le résultat du sondage en cour, de même que certaines couleurs vont changer pour certaines collectivités... Le modèle {{Tableau population}} et le tableau du modèle section seront dans leur forme scrupuleusement identique afin de respecter au mieux les décisions communautaires comme le sondage... Au passage les 2 modèles se complémentent car certains peuvent utiliser le modèle section et le modèle tableau population dans un même article pour ajouter un second tableau (dans certains cas particuliers...).
Pour ce qui est de ces histoires d'url, moi je débats ici uniquement de ce qui concerne le contenu affiché par le modèle section. Les références sont là pour appuyer la véracité des données affichées par le modèle section. Lorsque tu écris : « lien PDF, je l'utilise également dans la partie économie des communes où je me réfère aux tableaux EMP T2 et EMP T4 de la page 5 pour les actifs et les chômeurs... », et bien je viens d'écrire ci-dessus que j'accepte d'ajouter cet url dans les références quand bien même elle n'a pas de rapport direct avec le contenu affiché (pour le moment car ça viendra) par le modèle section (il y a déjà des références ciblées par commune avec les populations municipales ce qui permet aux lecteurs de vérifier par eux même l'exactitude des données affichées). D'autre part, le lien PDF si tu l'utilises dans d'autres sections de tes articles pour parler des actifs et les chômeurs, de la répartition des établissements et leur type sur la commune, et bien il vaut mieux mettre le lien PDF dans ces sections dont les données sont directement issues de ce lien. Je trouve ça plus logique que de le mettre dans le tableau d'évolution démographique où les données ne figure pas dans ce lien. Le lien PDF sera vraiment utile dans le modèle section lorsque l'on ajoutera les pyramides des âges et d'autres informations... Mais encore une fois, je peux me tromper et je te le répète, si tu tiens absolument à glisser ce lien PDF de façon automatique dans le modèle section, je veux bien le mettre ça ne me pose pas plus de problème que cela.
Quand tu écries : « Ce qui me gêne, c'est ta volonté de niveler systématiquement les tableaux en modèles prédéfinis où l'humain, hormis toi, n'intervient plus. ». Le tableau généré par le modèle section est le strict miroir de ce que contiennent les modèles de données. Les modèles de données peuvent être modifiés par tout à chacun librement. Tu veux ajouter ou retirer des dates, pas de problèmes. Tu veux ajouter des sources et des notes, là encore pas de problème (en écrivant ce que tu veux dans le paramètre "sources"). Tu veux ajouter des autres références avec entre autre le lien PDF, là encore pas de problème toujours grâces au paramètre "sources"... Le modèle section impose un cadre au niveau de la forme et encore, là rien n'est gravé dans le marbre. Cela est constamment démontré depuis le début (sondage en cour sur la forme au niveau communautaire, couleur verte pour respecter les chartes graphiques géographiques, ouverture du débat pour la forme et le contenu minimum du pied du tableau...). L'humain intervient donc si il le souhaite. Pour ma part, certes j'interviens beaucoup sur la maintenance de ce modèle, mais je n'ai pas d'exclusivité sur tout cela. Si le cœur t'en dit vraiment n'hésites pas à prendre des initiatives directes sur le modèle. Comme ça il n'y a pas que moi qui intervient sur le tableau. Jusqu'à présent je fais en sorte de satisfaire le plus grand nombre de demandes bien que ce soit très difficile de faire tomber tout le monde d'accord. Rien que cette histoire de "INSEE" et "Insee" démontre la difficulté de l'exercice. Pour moi, la question est simple, on décide d'une convention sur ce point et on s'y tient. Mais cela est vrai pour tout. On décide d'une forme de tableau une fois pour toute et l'on s'y tient (en utilisant soit le modèle section, soit le modèle démographie2, soit le modèle Tableau population, peu importe du modèle employé du moment que l'on respecte une convention sur la forme pour ne pas avoir à débattre constamment de la même chose)... Par ailleurs, mon rôle devraient considérablement diminuer avec la montée en puissance de wikidata. De même que suite aux sondages et aux multiples débats, peu à peu beaucoup de points sont traités collectivement. Ma volonté est pas mal guidée par des décisions collectives. Par exemple, à la fin du sondage sur la forme du tableau le modèle section sera mis à jours pour respecter le vote et bien je vais le faire, mais là encore si le cœur t'en dit n'hésites pas occupe toi de cette mise à jour, ainsi il n'y aura pas que moi qui intervient. Fais une page test comme je le fais avant toute demande auprès des admin et donc contacte les admin pour qu'il mettent à jour le modèle (car il est protégé contre écriture). Autre exemple, quand Alinebot tourne sur les modèles de données, ce n'est pas moi qui intervient mais moi et Roland qui a créé les Tables (ainsi que les wikipédiens qui apportent des corrections aux tables lorsqu'ils trouvent une erreurs)... Conclusion, je ne suis pas infaillible, je peux me tromper donc si tu penses que je fais fausse route alors n'hésites pas à me remettre en place et à lancer des débats, et si tu veux intervenir directement sur le tableau du modèle sections, vas y également, lances toi, vraiment je ne le prendrai pas mal. Je ne veux pas que mon rôle au sein du développement et de la maintenance de ce modèle donne un sentiment d'omniprésence de ma part. Ma volonté ne doit primer sur aucune autre. amicalement--Wikialine (d) 23 mars 2013 à 01:25 (CET)[répondre]
Merci de prendre le temps à chaque fois de me répondre calmement. En fait, mes compétences en termes de programmation étant nulles, il est hors de question que je puisse intervenir au niveau d'un modèle tel que celui-ci, d'où ma propension à utiliser le modèle:Démographie2 que j'arrive à maîtriser tel qu'il est. Cordialement. Père Igor (d) 23 mars 2013 à 12:26 (CET)[répondre]
Documentation à revoir
Bonjour. La première phrase de la documentation indique « Ce modèle permet, de façon entièrement automatique, la mise en place de la sous-section « évolution démographique » au sein de la section « démographie » dans les 36 700 articles relatifs aux communes de France », ce qui laisse supposer que ce modèle est destiné à remplacer tous les autres, d'où certaines incompréhensions récentes entre contributeurs. Il serait souhaitable d'atténuer la portée de cette phrase et d'indiquer qu'il existe d'autres possibilités, au vu des discussions récentes sur le sujet. Père Igor (d) 2 avril 2013 à 22:36 (CEST)[répondre]
lignes horizontales dans l'histogramme : transition d’échelle
Il y a AMHA un petit souci dans les échelles choisies pour définir le nombre de lignes horizontales. C’est toutefois un problème mineur .
Exemple : sur un article dont la population est proche de 1000 habitants, on indique un maximum de population proche de 1000. On a donc des lignes grasses tous les 100 habitants, et maigres tout les 50, ce qui permet avec 19 lignes une lecture aisée du graphique (certains diront qu'il est touffu). Je retiens qu'on a une abondance de lignes-guides, mais que pour les dernières population au-dessus de 900, on est un peu perdu, justement, et on ne sait pas visuellement si la population passe la barre des 1000 habitants ou pas Fleuré.
Si on indique un maximum de population supérieur à 1000 habitants, on a seulement trois lignes, ce qui fait un peu pauvre au point de vue guide de la lecture. Azoée (d) 24 avril 2013 à 20:49 (CEST)[répondre]
Bonjour. Même litanie que les fois précédentes. Pour la Xième fois, je me retrouve avec un historique pondu tout fait grâce au sacro-saint modèle ci-joint, mais qui me chagrine beaucoup. Holmium vient de gratifier l'article de qualité Royan de ce modèle, alors que j'avais pris la peine, dès le 31 décembre 2012, de mettre à jour sa population 2010 (difficile d'être plus réactif) avec des sources qui vont bien. Or, à l'heure actuelle, ce modèle présente plusieurs anomalies dont la principale réside dans le fait que la période 1968-1999 n'est sourcée par aucune référence valide. Sous le tableau, il est indiqué que ce devrait être l'« Insee à partir de 1968 », mais quand on clique dessus, pas de période 1968-1999 (mais par contre, tous les liens, année par année, depuis 2006). Au vu de la valeur (17 102 habitants) inscrite dans le tableau pour 1999, elle est tirée de la base Cassini et non pas de l'Insee qui annonce 17 210 habitants.
Cette situation erronée se retrouvant sur tous les tableaux présentés avec ce modèle, quelqu'un peut-il modifier ledit modèle pour qu'apparaisse la mention « (Sources : Ldh/EHESS/Cassini jusqu'en 1999 puis Insee au-delà.) » ou quelque chose d'approchant ? L'historique démographique sur la période 1962-1999 serait alors sourcé en cohérence avec les données du tableau ? Ce serait une amélioration encourageante pour l'utilisation du modèle, et une cohérence encyclopédique. Père Igor (d) 6 juillet 2013 à 16:47 (CEST)[répondre]
Bonjour, Père Igor. Le modèle n'est pas sacro-saint. Tu demande
a) la correction des nombres
b) la correction des liens.
Les nombres ici se référent à la page EHESS. Tu as indiqué que insee.fr compte 17 210 habitants (source: RP1999 ... exploitations principales). En fait, je ne comprend pas la composition du tableau - si c'est une anomalie général (EHESS / INSEE à échanger), on doit donner cela au bots. Si les liens sont à compléter, également. Une adaptation manuelle est à éviter. --Holmium (d) 7 juillet 2013 à 14:47 (CEST)[répondre]
Les bots ne sont pas concernés. Les tableaux sont tous issus du même modèle:Section démographie d'article de commune de France dont nous sommes sur la page de discussion. Donc, s'il y a une modification à effectuer, c'est sur le modèle (ou un modèle associé), qui automatiquement, se répercutera sur tous les tableaux existants ou à venir. N'étant pas en mesure d'effectuer cette modification, je demande aux habitués de bien vouloir le faire. Père Igor (d) 7 juillet 2013 à 22:34 (CEST)[répondre]
A faire une substitution des références dans le modèle pour corriger ehess => insee, on doit chercher un mécanicien de précision dans les modèles qui je ne suis pas. --Holmium (d) 8 juillet 2013 à 00:02 (CEST)[répondre]
Il y a aussi une source en concordance avec ces tableaux par l'Insee lui-même : il suffit de télécharger le fichier 1962 (!) - 2010 par le lien en « Historique des populations par commune depuis le recensement de 1962 (1961 pour les Dom) » sur → cette page. Dans ce fichier l'Insee donne bien 17 102 pour la population de 1999 (voir à ce sujet le tableau en fin de → cette discussion dans laquelle j'avais tiré au sort La Rochelle qui avait trois chiffres différents de recensement 1999). Il y a donc aussi une possibilité de source par l'Insee. Mais tu as raison, Père Igor, ce modèle est mal fini, à commencer par l'intro qui annonce en note 2 un choix éditorial qui n'est pas celui retenu (2006, 2011, 2016…). ---- Ikmo-ned (discuter avec) 8 juillet 2013 à 00:05 (CEST)[répondre]
À la première publication de l'Insee (celle qui a été reprise par EHESS), c'était officiellement 17 102. Mais, quelques années plus tard, on a vu apparaître, tout aussi officiellement, 17 210, chiffre actuellement retenu par l'Insee. D'où l'importance que j'accorde à une source (peu importe laquelle) cohérente avec le chiffre annoncé dans le tableau, plutôt que l'absence actuelle de source sur cette période. Père Igor (d) 8 juillet 2013 à 11:49 (CEST)[répondre]
Bonjour à tous. Je rappelle que pour chaque commune et chaque année, l'Insee publie une estimation du nombre d'habitants, estimation éventuellement réévaluée par la suite en fonction de recalculs effectués par l'Insee (ces différences de quelques unités ont souvent été expliquées dans la PDD du projet). C'est pourquoi il faut toujours prendre en compte les dernières données publiées par l'Insee, les seules officielles. Je rappelle également que pour chaque commune, l'Insee publie un récapitulatif des données de la commune dans un fichier qui se trouve à l'adresse http://www.statistiques-locales.insee.fr/FICHES/DL/DEP/XX/COM/DL_COMYYYYY.pdf où XX est le numéro du département et YYYYY le n° INSEE de la commune. Exemple pour Royan en cliquant ici. Dans les articles de commune, on ne devrait faire référence qu'à cette seule source pour les données à partir de 1968. Cordialement. AntonyB (d) 8 juillet 2013 à 13:57 (CEST)[répondre]
« les dernières données publiées par l'Insee, les seules officielles ». Sauf erreur de ma part, je ne crois pas avoir vu un choix si catégorique (de la part globalement du projet, j'entends) sur les pages de discussion. Une source Insee en vaut à mon avis une autre, tant qu'on a pas l'explication du changement. S'il faut convenir d'un choix sur les trois possibles ([édit.] qui apparaissent pour deux d'entre eux dans des fichiers récents, le troisième [9] parlant de population municipale, notion finalement plus récente), convenons-en, soit, mais ça ne me semble pas avoir été fait. ---- Ikmo-ned (discuter avec) 8 juillet 2013 à 14:21 (CEST)[répondre]
Je me suis peut-être mal exprimé ayant voulu faire court. J'ai en effet résumé en une phrase ce que GabrieL, contributeur actif au projet et responsable du recensement à l'Insee (nous avons la grande chance au sein de l'encyclopédie d'avoir qqn qui connait bien le sujet, je vais en profiter pour lui signaler cette discussion) nous a plusieurs fois expliqué. Je tenais donc à rappeler l'explication des différences dans le temps entre les données publiées pour une même commune, et je tenais à rappeler qu'il faut toujours utiliser le fichier pdf qui — lui — a toujours la même url et qui est mis à jour régulièrement par l'Insee. Bien cordialement. AntonyB (d) 8 juillet 2013 à 14:40 (CEST)[répondre]
En fait pour 1999, il y a souvent des différences entre les sources de l'époque et les chiffres utilisés dans la documentation actuelle. C'est dû aux changements de méthode de comptage entre les recensements ancienne méthode et nouvelle méthode, je crois que la population légale reposait avant sur la population sans double compte alors qu'elle repose maintenant sur la population municipale. Pour permettre des comparaisons entre 1999 et la dernière population en vigueur, la documentation actuelle a remplacé la pop sans double compte 17102 par celle municipale 17210. Comme l'article source "De 1962 à 1999 : population sans doubles comptes ; pour les dates suivantes : population municipale.", il faut laisser 17102. Mais avec "De 1962 à 1990 : population sans doubles comptes ; pour les dates suivantes : population municipale rénovée.", il faudrait mettre 17210 et cela serait tout aussi juste. En soit, les deux chiffres sont bons, ils représentent juste des choses différentes. Sur Chiffres de population de la France, il y a un chapitre Différences entre l'ex-population sans doubles comptes et la population municipale (rénovée). Pour 1999, ce remplacement n'est pas un recalcul des chiffres mais plus un remplacement de chiffres par d'autres pour comparer des chiffres calculés de manière identique. Le recalcul n'a pas touché les dates antérieures car le détail n'est plus assez connu pour connaître ce qu'aurait donné 1990 avec la pop municipale rénovée. GabrieL (d) 8 juillet 2013 à 15:18 (CEST)[répondre]
Il y a d'autres chiffres de populations légales qui sont quelquefois recalculés mais uniquement dans les documents de travail : pour les communes de moins de 10000, c'est le cas des années entre deux années de recensement réel. Pour prendre l'exemple de Rablay-sur-Layon recensée en 2005 et en 2010 :
2005 : 703 habitants (chiffres réels et officiels de recensement mais pas pop légale, les nouvelles ont commencé en 2006) ;
2006 : 712 habitants (estimation calculée à partir des chiffres de 2005 et de l'évolution dans les fichiers des taxes d'habitation en résidence principale entre 2005 et 2006 : population légale en vigueur en 2009) ;
2007 : 721 habitants (estimation calculée à partir des chiffres de 2005 et de l'évolution dans les fichiers des taxes d'habitation en résidence principale entre 2005 et 2007 : population légale en vigueur en 2010) ;
2008 : 721 habitants (estimation faite à partir des chiffres de 2005 et de 2010, 2010 est en effet déjà déjà connu à la publication car pop légale en vigueur qu'en 2011) ;
2009 : 726 habitants (estimation faite à partir des chiffres de 2005 et de 2010, 2010 est en effet déjà déjà connu à la publication car pop légale en vigueur qu'en 2012) ;
2010 : 732 habitants (chiffres réels et officiels de recensement, pop légale en vigueur en 2013).
Ici, les pop légales de 2008 et de 2009 sont calculées en même temps en 2010 quand les chiffres de 2010 sont connus, ces chiffres ne représentent rien de réels et sont lissés pour que la hausse soit progressive, le saut entre 2008 et 2009 et celui entre 2009 et 2010 sont identiques à une unité près. Si on enlève le même saut entre 2007 et 2008, on aura probablement un chiffre plus fiable pour 2007. Les chiffres intermédiaires entre deux recensements se veulent le plus proche possible de la réalité pour les deux années qui suivent un recensement réel (ici 2006 et 2007) mais les chiffres du recensement précédent retouchés de l'évolution de la taxe d'habitation ne peuvent donner qu'une tendance par manque de connaissance du nombre d'habitants dans les logements concernés ainsi que par des fichiers de taxes d'habitation pas toujours très à jour. Ici, la tendance était bonne en 2006 et 2007 mais sans doute légèrement surévaluée d'environ 5 habitants. Dans les documents de travail, on les utilise peu ou quelques fois remodifiés quand arrive la préparation du recensement suivant. Pour les deux années qui précédent un recensement réel (ici 2008 et 2009), elle ne se veulent pas exacts mais juste conduire progressivement au chiffre réel du recensement l'année qui suit (2010) avec les à-coups les plus faibles possibles. Contrairement aux chiffres intermédiaires, les chiffres des années de recensement ne sont pas retouchés. Mais même pour les années intermédiaires, les réestimations, s'il y en a en interne, ne sont pas recommuniquées publiquement mais juste remplacées par les chiffres des populations légales suivantes pour le public. GabrieL (d) 8 juillet 2013 à 15:43 (CEST)[répondre]
Dernière chose, pour revenir sur Royan, ici, c'est une commune de plus de 10000, donc méthode différente, la première nouvelle pop légale (celle de 2006) a été estimée à partir du recensement de 40% des logements entre 2004 et 2008 (sur cinq ans). Statistiquement, il n'est pas correct donc de comparer 2006 à 2007 puis à 2008 jusqu'en 2010 car entre 2006 et 2007, l'estimation aux deux dates a quatre cinquièmes des données de départ identiques. Il faut logiquement attendre 2011 calculé à partir des données de 2009 à 2013 pour avoir un renouvellement complet des données. Il ne faut donc ne laisser dans le tableau que 2006 et la dernière pop légale jusqu'à ce que 2011 soit communiqué, puis, quand on aura 2011, 2006+2011+dernière pop légale jusqu'à ce que 2016 soit communiqué, etc. GabrieL (d) 8 juillet 2013 à 15:43 (CEST) P.S. : c'est une des raisons pour lesquelles l'INSEE continue jusqu'à l'année prochaine de comparer la dernière pop légale avec 1999. A partir de l'année prochaine, l'INSEE comparera les chiffres avec ceux de cinq ans avant.[répondre]
Encore moi, pour une courte réexplication sur EHESS, tous les chiffres indiqués sur le site de l'EHESS proviennent à l'origine de l'INSEE à partir des années 1960 (y compris 1999, cf. un peu haut). Mais les chiffres indiqués sous la mention 2006 ne correspondent pas à la population légale 2006 pour toutes les communes (cf. Sources sur [10] vers le bas de page). Pour les communes de moins de 10000, les trois cinquièmes environ des communes ont des chiffres en face de 2006, les deux cinquièmes restant n'ont rien. Celles qui n'ont rien ont été recensées qu'en 2007 ou 2008, les autres en 2004, 2005 et 2006 et le chiffre indiqué comme 2006 correspondant au recensement réel d'une de ses trois dernières années (pour connaître l'année réelle, aller sur [11], enlever 10 ans à la date du prochain recensement). Pour les communes de plus de 10 000, les estimations à la mention 2006 correspond à des chiffres provisoires estimés pour la population de la commune début 2004, ces chiffres ont été calculés fin 2004 à partir des recensements de 1999 (exhaustif) et de 2004 (partiel). Elles ont été très largement revues et pour certaines communes, les chiffres étaient si éloignés de la réalité (on l'a su à partir des autres recensements partiels d'entre 2005 à 2008) qu'elles n'ont pas servies longtemps dans les documents de travail. Ces chiffres pour 399 des communes de plus de 10 000 ont été publiés en janvier 2005 dans les médias de l'époque. Il n'est pas recommandé de les conserver. GabrieL (d) 8 juillet 2013 à 16:13 (CEST)[répondre]
Merci cher ami de ces explications très précises. Je ne regrette pas de t'avoir signalé cette discussion afin que tu y apportes ton incontestable expertise. Personnellement, je lis tout cela avec intérêt pour ma connaissance encyclopédique mais je laisse à Roland45 et à Wikialine le soin de rédiger en conséquence les textes qui accompagnent le tableau et le graphique. Bien cordialement. AntonyB (d) 8 juillet 2013 à 17:17 (CEST)[répondre]
Mise en page
Transféré depuis la PDD du projet Communes de France
Bonjour, Je ne suis pas très au fait de ce qui se passe dans le projet, mais je tombe souvent sur les articles des communes et il y a un effet de bord sur le modèle {{Section démographie d'article de commune de France}} mis en place récemment. Il semble qu'il y ait une commande {{clr}} placée au hasard de l'usine à gaz mise en place (j'ai pas réussi à voir où il fallait intervenir, c'est pour dire :D) alors qu'il serait préférable de mettre un {{clr|left}}, afin que les tableaux soient dans une suite "normale" des paragraphes (et non alignés sur la fin de l'infobox). C'est particulièrement flagrant sur les communes peu développés ou il y a un "gros pavé blanc" avant les tableaux démographiques.--Sacamol (d) 7 juillet 2013 à 20:51 (CEST)[répondre]
La question a été évoquée plusieurs fois sur cette page, je l'ai encore reprise sur le projet Communes de France en reprenant une perche tendue par Azoée : pourrait-on alléger le texte généré par ce modèle lorsqu'il ne concerne pas spécifiquement la commune (et il est parfois carrément hors sujet lorsqu'il parle de communes de plus de 10 000 habitants sur la page d'un petit village) :
supprimer, dans le corps du texte, les deux phrases suivantes : « L'évolution du nombre d'habitants est connue à travers les recensements de la population effectués dans la commune depuis 1793. À partir du XXIe siècle, les recensements réels des communes de moins de 10 000 habitants ont lieu tous les cinq ans, contrairement aux autres communes qui ont une enquête par sondage chaque année » ;
supprimer la première note (description générale des principes du recensement) ;
conserver la deuxième note (qui décrit la convention suivie sur Wikipédia) en ajoutant au début de la note une phrase telle que celle-ci : « Pour les modalités d'organisation du recensement, voyez Recensement de la population en France. ». Quitte à améliorer cette dernière page s'il y manque quelque chose.
(Cela dit, la deuxième note pourrait être allégée par un lien vers une page décrivant les principes suivis sur Wikipédia en matière démographique, mais je ne sais pas bien où l'on pourrait mettre cette page).
Bonjour. Pourquoi pas en effet. Je tiens toutefois à préciser que ces notes sont le résultat de bien des discussions et qu'elles s'avèrent utiles à mon avis dans le principe, mais leur contenu peut toujours être amélioré en effet. Cordialement. AntonyB (d) 12 juillet 2013 à 21:39 (CEST)[répondre]
<conflit d'edith>à Seudo
La 2e note ressemble au texte « Les résultats provisoires du recensement par sondage annuel réalisé en 2004, 2005 et 2006 selon les communes sont tous, par convention, affichés à 2006 (voir dossier Sources et site Insee). » qui figure sur le site de l’Ehess (cassini), qui lui n'est pas en note. On pourrait, autre possibilité, l’inclure dans le tableau, afin que chaque lecteur de chaque tableau puisse la voir (ce qui n'est pas le cas avec un article déporté). Les techniques de recensement sont par contre plus à leur place sur un article dédié, avec lien à partir de la section : pourquoi décrire les deux derniers recensements, et pas les questionnaires des années 1790-18xx remplis par les maires ? Azoée (d) 12 juillet 2013 à 21:42 (CEST)[répondre]
à AntonyB : certes il y a eu des discussions, mais la portée de celles-ci (et des demandes, par ricochet) a été limitée dès le départ par l’ampleur des difficultés techniques et du travail à réaliser pour mettre en place ces modèles mis à jour automatiquement. Il était alors malvenu, et je me suis moi-même retenu, de discuter de multiples modifications de détail. Azoée (d) 12 juillet 2013 à 21:46 (CEST)[répondre]
Me trouvant dans un département dont 555 communes sur 557 ont une population inférieure à 10 000 habitants, ces notes ne m'ont jamais inspiré et dans mes mises à jour, manuelles bien sûr, j'use et j'abuse de la formulation suivante : « À partir du XXIe siècle, les recensements réels des communes de moins de 10 000 habitants ont lieu tous les cinq ans. Pour [nom de la commune], cela correspond à 200X, 201X, 201X, etc. Les autres dates de « recensements » (2010, etc.) sont des estimations légales ». Il me parait en effet beaucoup plus important pour le lecteur de connaître les dates réelles de recensement et les dates correspondant à des calculs, plutôt que tout le blabla ayant précédé la mise en place des nouveaux types de recensement. Et je souhaite que cette particularité, qui concerne quand même plus de 97 % des communes françaises, (voir ce document), soit intégrée dans les modèles tout faits, que fort malheureusement, je suis infoutu de programmer. Père Igor (d) 12 juillet 2013 à 22:37 (CEST)[répondre]
Bonjour à tous. Les discussion multiples qui ont eu lieu ont porté sur l'affichage des années dans les tableaux et les graphiques à partir de 2006, précisément du fait du changement du mode de recensement. Et manifestement, beaucoup n'ont pas encore compris, quant aux nouveaux, extérieurs au projet "Commune de France", n'en parlons pas!! Sans explication, ils se demanderont pourquoi sur une commune on affiche la population de 2005, 2010, etc et sur telle autre 2006, 2011, etc et ils seront tentés d'ajouter les données manquantes. Ces notes ne me paraissent pas superflues. Elles n'expliquent aucunement le recensement, mais le mode d'affichage des données, qui, je le rappelle, n'est que conventionnel, car toutes les années publiées sont légales, mais comme on ne peut pas comparer des données à moins de 5 ans d'intervalle, autant n'afficher que les recensements exhaustifs (pr les - de 10 000). Et on ne peut pas parler de cette convention d'affichage sans dire un mot sur ce nouveau recensement. Il ne faut pas oublier que le lecteur nouveau, n'appartenant pas au projet "Commune de France", doit pouvoir comprendre l'article sans être contraint d'aller tel ou tel autre article. Le contenu est quant à lui améliorable probablement, mais pour améliorer, il faut ce n'est pas qu'une question de texte, mais aussi de code, car il faut a minima introduire une condition dans le modèle (commune inférieure ou supérieure à 10 000 habitants), et là ça se complique un petit peu, sauf à utiliser deux modèles (... il faudrait dès lors changer tous les modèles de communes de population > 10 000 habitants, mais comme le signale Pere Igor, il n'y en a pas tant que ça!). Introduire les années réelles de recensement dans le texte est aussi faisable, mais là aussi ... qui écrira le code?! Quant à supprimer le corps du texte (ainsi que les notes puisqu'il n'y aurait plus de texte) et donc ne laisser que le tableau et le graphique, je suppose que c'est une provocation de Seudo. En tout cas, je n'y souscris aucunement. Cordialement.Roland45 (d) 12 juillet 2013 à 22:55 (CEST)[répondre]
Parler du mode de recensement en note sur tous les articles de communes, c'est comme si on parlait du mode d'élection du maire sur chacun de ces articles. Personnellement, dans ce dernier exemple, je place un lien dans une phrase parlant du conseil municipal et ça doit suffire, faire plus est de la digression. Pour les années de recensements réels, oui, ça doit être précisé, manuellement s'il le faut, ou par un modèle du type {{Recensement Insee|2008}} par exemple, mais pour le reste, c'est un lien vers l'article Chiffres de population de la France ou Recensement de la population en France qui doit juste figurer, articles éventuellement à améliorer. Si l'on doit s'adresser à l'éditeur sans alourdir la lecture, il y a pour cela le commentaire invisible. J'appuie la remarque d'Azoee concernant la retenue due aux priorités : on en est maintenant à une phase d'amélioration. Cordialement, ---- Ikmo-ned (discuter avec) 13 juillet 2013 à 00:47 (CEST)[répondre]
« le lecteur nouveau [...] doit pouvoir comprendre l'article sans être contraint d'aller tel ou tel autre article » : c’est en contradiction complète avec l’esprit d’une encyclopédie, web ou pas. Toute notion déjà définie par ailleurs ne doit pas être réexpliquée à l’infini sur les autres pages. Si le boulot est fait quelque part, autant y renvoyer le lecteur. S’il comprend, ou s’il se passe de l’explication (parce qu’il ne se pose pas la question de recensement réel, sondage, et veut simplement le dernier recensement), la présentation est allégée pour lui. Et s’il ne comprend pas et a du temps pour lui, il va lire l’article détaillé, où il a plus d’informations que dans une note de bas de page. Azoée (d) 13 juillet 2013 à 08:11 (CEST)[répondre]
Cela dit, j’attire l’attention sur les réels éléments de souplesse contenus dans les modèles. Il est d’abord possible de se passer de l’introduction, ce qui résout le problème pour ceux qui ne veulent pas de notes ou qui rédigent un réel paragraphe d’introduction. Il est également possible, pour ceux qui font des recherches dans les bibliothèques et trouvent des recensements antérieurs à la Révolution, de les ajouter dans le tableau et de les faire apparaître dans le graphique. Je ne le fais que lorsqu’ils sont proches de 1793, pour éviter de faire apparaître un hiatus, mais c’est un réel avantage. Donc, même si je trouve que dans la forme, cette introduction est perfectible, elle laisse le choix au contributeur. Père Igor et moi-même usons de ce choix, libre à chacun de le faire. Azoée (d)
Le modèle étant protégé et toute modification étant difficile, le plus simple, pour ceux qui trouvent que ces notes sont trop lourdes, est de rédiger une introduction en clair et de n'utiliser que les modèles produisant le tableau et le graphique.Roland45 (d) 13 juillet 2013 à 08:50 (CEST)[répondre]
Voici pour mieux comprendre le contenu des deux notes, en tout cas telles qu'elles apparaissent sur la page Coquelles (c'est peut-être différent sur d'autres pages ?)
Première note :
Au début du XXIe siècle, les modalités de recensement ont été modifiées par la loi no 2002-276 du 27 février 2002 [archive], dite « loi de démocratie de proximité » relative à la démocratie de proximité et notamment le titre V « des opérations de recensement », afin de permettre, après une période transitoire courant de 2004 à 2008, la publication annuelle de la population légale des différentes circonscriptions administratives françaises. Pour les communes dont la population est supérieure à 10 000 habitants, une enquête par sondage est effectuée chaque année, la totalité du territoire de ces communes est prise en compte au terme de la même période de cinq ans. La première population légale postérieure à celle de 1999 et s’inscrivant dans ce nouveau dispositif est entrée en vigueur au 1er janvier 2009 et correspond au recensement de l’année 2006.
Deuxième note :
Dans le tableau des recensements et le graphique, par convention dans Wikipédia, et afin de permettre une comparaison correcte entre des recensements espacés d’une période de cinq ans, le principe a été retenu, pour les populations légales postérieures à 1999 de n’afficher dans le tableau des recensements et le graphique que les populations correspondant aux années 2006, 2011, 2016, etc., ainsi que la dernière population légale publiée par l’Insee.
Plusieurs remarques :
la première note apporte une information générale sur les modalités du recensement et n'a donc pas sa place dans les articles sur les communes, d'autant qu'elle parle des villes de plus de 10 000 habitants qui sont très minoritaires en France ;
la deuxième note est utile pour comprendre à fond les chiffres, mais elle est redondante avec les explications (beaucoup plus claires) données en-dessous du tableau (« De 1962 à 1999 : population sans doubles comptes ; pour les dates suivantes, etc. »). Ne suffirait-il pas, en-dessous du tableau, d'écrire « populations municipales tous les cinq ans » pour donner la même information au lecteur ? Si on veut garder cette note, c'est en-dessous du tableau qu'il faut la mettre, sous forme de précisions à ces explications.
Enfin, je ne remets pas du tout en cause le tableau et le graphique, malgré la complexité des modèles utilisés qui m'a parfois causé un mal de tête lorsque j'ai voulu comprendre pourquoi il empêchait certaines pages de se charger. C'est seulement, me semble-t-il à première vue, le très simple {{Introduction population d'article de commune de France}} qu'il faudrait alléger. Seudo (d) 13 juillet 2013 à 10:05 (CEST)[répondre]
Oui, l'exces de modèles empêche certaines pages de se charger. Et puis, on peut alléger les notes par un simple renvoi à la page explicative du modèle. On n'explique pas à chaque page en note ce qu'est l'INSEE, ni ce qu'est la base Mérimée, etc. --Havang(nl) (d) 22 juillet 2013 à 13:08 (CEST)[répondre]
Bonjour, pour faire suite à cette discussion, je suggère de corriger une ou deux imperfections typographiques, de retirer les redondances, remplacer les deux notes par une seule en y mettant tout ce qui est d'ordre méthodologique. Je ne retire absolument aucune information (je prends l'exemple d'Auch) :
En 2014, la commune comptait 21 807 habitants. L'évolution de la population est la suivante[Note 1] :
(ici le tableau et le graphique)
↑L'évolution du nombre d'habitants est connue à travers les recensements de la population effectués dans cette commune depuis 1793. Par convention dans Wikipédia, et afin de permettre une comparaison correcte entre des recensements espacés d’une période de cinq ans, le principe a été retenu, pour les populations légales postérieures à 1999, de n’afficher dans le tableau des recensements et le graphique que les populations correspondant aux années 2006, 2011, 2016, etc., ainsi que la dernière population légale publiée par l’Insee. En effet, les modalités de recensement ont été modifiées par la loi no 2002-276 du 27 février 2002 relative à la démocratie de proximité, afin de permettre, après une période transitoire de 2004 à 2008, la publication annuelle de la population légale des différentes circonscriptions administratives françaises. Pour les communes dont la population est supérieure à 10 000 habitants, une enquête par sondage est désormais effectuée chaque année, la totalité du territoire de ces communes étant prise en compte au bout de cinq ans. La première population légale postérieure à celle de 1999 et s’inscrivant dans ce nouveau dispositif est entrée en vigueur au 1er janvier 2009 et correspond au recensement de l’année 2006.
« le principe a été retenu, pour les populations légales postérieures à 1999, de n’afficher dans le tableau des recensements et le graphique que les populations correspondant aux années 2006, 2011, 2016, etc. » : en fait, le principe appliqué (et c'est mieux ainsi, d'après ce que j'ai compris) est de n'afficher pour les communes de moins de 10 000 hab. que les « recensements exaustifs », pour reprendre le terme utilisé dans Histoire du recensement de la population en France. Sinon, la remarque d'Azoee est pertinente. ---- Ikmo-ned (discuter avec) 4 décembre 2013 à 18:53 (CET)[répondre]
J'ai repris le texte actuel qui parle de "population légale". Si je comprends bien, cela devrait inclure aussi bien les recensements incrémentaux (villes de plus de 10 000 habitants) que les recensements exhaustifs (communes de moins de 10 000 habitants).
Quoi qu'il en soit, voici une version 2 plus concise, qui garde la description des conventions spécifiques à Wikipédia :
En 2014, la commune comptait 21 807 habitants. L'évolution de la population est la suivante[Note 1] :
(ici le tableau et le graphique)
↑L'évolution du nombre d'habitants est connue à travers les recensements de la population effectués dans cette commune depuis 1793. Compte tenu de la réforme des modalités de recensement survenue au début des années 2000, il est décidé par convention dans Wikipédia d'afficher la population légale tous les cinq ans à partir de 2006 (première population légale correspondant au nouveau mode de recensement), ainsi que la dernière population légale.
Bonjour et merci pour cette nouvelle proposition qui me semble aller dans le bon sens. Compte tenu de mon expérience (pour avoir expliqué N fois à de nouveaux contributeurs ce sujet), je tiens absolument à ce que l'explication soit mise en note, aussi courte que possible bien sûr, mais il faut que le lecteur comprenne sans avoir besoin d'aller chercher l'explication dans un article connexe. Cordialement. AntonyB (discuter) 4 décembre 2013 à 23:29 (CET)[répondre]
Bon, pour satisfaire cette demande récurrente de suppression de notes de bas de page, tout en donnant un minimum d'information, j'ai corrigé le texte sur des modèles tests (le modèle principal étant protégé). Il y aurait désormais deux modèles : {{Introduction population d'article de commune de France 1}} et {{Introduction population d'article de commune de France 2}}. Ceci permet d'ajouter manuellement tous les textes que l'on veut pour les périodes intermédiaires entre 1793 et les années 2000. Pour le descriptif de l'organisation du recensement, un lien renvoie vers la page de l'Insee correspondante, bien plus explicite que l'article de Wikipédia. Pour les communes de moins de 10000 habitants, le texte comprend désormais formellement l'année du premier recensement, qui est elle-même sourcée sur le site de l'Insee. Un exemple est donné pour la commune d'Adon, dans le Loiret (Adon#Démographie). Bien entendu, le modèle ne fonctionne que si on a saisi dans le modèle de données de la commune les paramètres "année du premier recensement" et "source du calendrier". Ceci ne pourra donc être mis en œuvre qu'après révision complète de tous les modèles de données. Mais désormais vous "noterez" ... qu'il n'y a plus de bloc "Notes"!!
Notez également qu'en appliquant la charte retenue pour l'affichage, une nouvelle anomalie apparaît : les sources du tableau font apparaitre les sources de chacune des années entre 2006 et 2010, y compris donc celles qui ne sont pas affichées (voir ref 15 pour Adon). Ceci aussi pourra être corrigé, mais uniquement quand tous les paramètres "année de recensement" auront été saisis.Roland45 (discuter) 5 décembre 2013 à 08:34 (CET)[répondre]
Très bien ! J'avais déjà noté dans mon essai de résumé introductif les années réelles pour les communes du 04, ne sachant si l'information serait conservée ou pas.
Merci pour ces explications : on se rend compte que l'élaboration de ces nouveaux paramètres doit représenter un boulot de réflexion monstre (sans compter la mise en oeuvre). Le tri dans le sourçage est aussi un ménage très intéressant. azoée (discuter)
C'est beaucoup mieux en effet, merci ! Le texte généré à l'intérieur de l'article même me gêne un peu (pourquoi ne pas le mettre en note, vu que cela ne concerne que ceux qui veulent tout savoir sur la méthodologie ?), mais ce n'est pas très grave. Seudo (discuter) 5 décembre 2013 à 09:44 (CET)[répondre]
Le texte en question concerne le recensement de la commune et est donc propre à la commune. Il comporte en outre deux sources externes. Pour ces deux raisons, il s'agit donc bien d'une information à mettre dans le corps de l'article. On ne met jamais (ou rarement en tout cas) des infos sourcées dans une note, qui doit en principe se résumer à un simple commentaire. Le groupe de notes précédent était assurément abusif.Roland45 (discuter) 5 décembre 2013 à 13:34 (CET)[répondre]
Discussions depuis le 23 janvier 2014
Moi aussi je trouve le texte d'introduction trop lourd et trop imprécis ("À partir du XXIe siècle" pour dire depuis 2004, "recensements réels" pour dire enquêtes de recensement...), même encore actuellement. Et pourquoi expliquer dans l'article d'une commune de moins de 10 000 habitants comment on recense la population dans les communes de plus de 10 000? et réciproquement. Alors j'ai créé un nouveau modèle d'introduction en m'inspirant du texte d'introduction déjà amélioré de l'article de Corbières (Alpes-de-Haute-Provence).
J'ai supprimé la phrase « L'évolution du nombre d'habitants est connue à travers les recensements de la population effectués dans la commune depuis 1793. » qui n'a pas d'intérêt, me semble t-il, et ne fait qu'alourdir le texte de l'article. Sans compter qu'elle est très imprécise (le nombre d'habitant de quoi?) et n'est pas forcément juste (la série de recensements donnée sur Wikipédia ne commence pas toujours à la même date que le premier recensement de la commune).
A la suite de la première phrase qui donne la dernière population, on trouve pour les communes de :
plus de 10 000 habitants la phrase suivante avec une note unique : « Depuis 2004, les recensements des communes de plus de 10 000 habitants ont lieu au moyen d'enquêtes annuelles par sondage. »
moins de 10 000 habitants la phrase customisée suivante (ici dans le cas de Mey): « Depuis 2004, les enquêtes de recensement dans les communes françaises de moins de 10 000 habitants sont effectuées tous les cinq ans (2005, 2010, 2015, etc. pour Mey) et les chiffres de la « population municipale légale » fournis par l'Insee les autres années sont des estimations. »
Le plus simple pour se rendre compte de ce modèle amélioré donne (et voir les notes et références dans l'un et l'autre cas) est de le regarder sur une commune où je l'ai mis:
C'est OK pour moi. Une petite observation pour les communes de 10000 habitants, je propose d'ajouter le bloc de texte souligné suivant « Depuis 2004, les recensements des communes de plus de 10 000 habitants ont lieu au moyen d'enquêtes annuelles par sondage auprès d'un échantillon d'adresses représentant 8 % de leurs logements. » Car le terme "sondage" peut prêter à confusion. Notez également que la documentation du modèle de données comporte désormais aussi un texte explicatif, issu directement du site de l'Insee, ce qui justifie d'autant plus de supprimer ces notes de bas de page.
Concernant le cas de Cournon, il y a manifestement une erreur sur l'année 1831, erreur qui figure sur le site de l'EHSS (qui n'est pas infaillible). Une vérification sur les archives locales s'imposerait.
Petite observation complémentaire, mais qui n'a rien à voir avec la suppression des notes de bas de page du texte introductif : le texte des sources du tableau est encore erroné : il manque la ref pour la période 1793-1962!Roland45 (discuter) 23 janvier 2014 à 07:05 (CET)[répondre]
Évidemment OK pour la modification, mais je suis incapable de vérifier que le code fonctionnera bien partout. Et avant de faire la modification, vérifions ici ET sur le Projet les accords, désaccords et remarques. La note 2 devient toutefois inutile, avec les liens ajoutés dans le texte, qui renvoient vers des articles qui contiennent le même texte. azoée (discuter) 23 janvier 2014 à 09:54 (CET)[répondre]
L'allégement du texte inséré dans le corps de l'article est une bonne chose, mais pourquoi proposer un nombre considérable de notes dont certaines sont particulièrement longues ?
En prenant le cas de Cournon (Morbihan), la "Note 1" ne devrait pas être nécessaire puisqu'un lien est fait vers population municipale légale, la "Note 2" pourrait être considérablement raccourcie (ou remplacée par un lien vers une page d'aide). De toute manière, ces deux notes ne sont pas nécessaires puisque les données du tableau sont déjà sourcées avec des liens situés au-dessous de ce tableau (liens d'ailleurs incomplets : il manque la période avant 1962, ainsi que l'année 2011).
On a ainsi pas moins de cinq notes pour le sourçage des données, ce qui, me semble-t-il, ne peut qu'introduire de la confusion chez le lecteur. Je pense que seules les notes en-dessous du tableau devraient être conservées (et éventuellement celle qui donne la date du prochain recensement).
Bonjour.
Je ne comprends pas bien ton commentaire. Personnellement je vois deux notes de bas de page et trois références de sources, la troisième contenant cinq url. Peux-tu préciser où tu vois cinq notes ?
Je confirme (cela a déjà été dit N fois) qu'on peut alléger les textes, mais qu'il est absolument indispensable de conserver pour chaque commune :
en note de bas de page : une explication — aussi claire que possible — relative aux années retenues par la fr.wikipédia pour cette commune : cela permettra aux contributeurs qui modifient sauvagement les modèles de ne pas ajouter de données inutiles, voire erronées ;
en référence de sources : les url des données publiées par l'Insee depuis 2000 pour cette commune, et ce en complément de l'url spécifique de la base Cassini pour cette commune, puisque la base Cassini s'arrête en 1999.
AntonyB : : AntonyB, en français courant, le mot note désigne à la fois ce que tu appelles notes de bas de page, et références de sources. Ça fait donc bien cinq notes.
Azoee : : Je le sais bien et tu le sais ! Mais dans le cas présent, Seudo avait précisé « cinq notes pour le sourçage des données », je comprends donc qu'il évoquait le « sourçage » (désolé pour cet affreux mot du jargon wikipédien, auquel j'ai toujours préféré l'appellation « références de sources », appellation plus usuelle) et non pas les notes de bas de page. J'ai eu l'impression qu'il évoquait les cinq références de sources. Attendons donc son explication. Cordialement. AntonyB (discuter) 23 janvier 2014 à 15:47 (CET)[répondre]
Azoée a bien expliqué les « 5 notes ». J'ai tendance à confondre notes et références car la distinction est une subtilité de Wikipédia dont je ne comprends pas l'intérêt pratique. Ça fait concrètement cinq allers-retours vers le bas de page pour le lecteur curieux qui veut comprendre les chiffres affichés dans le tableau (ou quatre si on ne compte pas celui qui concerne le prochain recensement) et ça me paraît un peu trop.
Merci de ton ajout. je précise toutefois que cette subtilité n'est en rien imputable à l'encyclopédie wikipédia. Tu trouveras des notes en bas de pages dans bien des ouvrages. AntonyB (discuter) 23 janvier 2014 à 17:26 (CET)[répondre]
Sur la question des dégâts que pourraient faire les contributeurs en modifiant les modèles : dans ce cas il faut mettre ces indications dans la documentation du modèle (voire dans son code source, entre commentaires HTML). Et de toute manière, un modèle tel que {{Tableau population d'article de commune de France}} est protégé et la complexité du système le réserve à des utilisateurs avancés.
Je me suis mal exprimé, j'évoquais ici les modifications faites par de contributeurs au sein des 36 780 pagesde modèles de données (une page de données par commune). Mais heureusement, ces modifications sont rares, je te rassure. Pour ton info : il n'a jamais été envisagé de bloquer ces pages en écriture. Il me semble que ce serait contraire aux principes d'égale collaboration. Cordialement. AntonyB (discuter) 23 janvier 2014 à 17:26 (CET)[répondre]
Peut-être craignais-tu en fait que les contributeurs rajoutent des données directement dans l'article en contournant les modèles standards. Dans ce cas, la solution serait plutôt de mettre, dans l'une des notes de bas de page, une indication telle que : « Les chiffres de population légale sont présentés tous les cinq ans à partir de 2006. Pour plus de précisions, voir la page XXX. ». XXX serait une page (dans le projet Communes ?) où tout cela serait expliqué bien plus clairement que dans une note de bas de page. Seudo (discuter) 23 janvier 2014 à 16:04 (CET)[répondre]
Pour ton info : il fut un temps où j'avais renvoyé la définition des noms d'usage de communes vers la page ad-hoc du projet:Communes de France, et dans les jours qui ont suivi, j'ai été l'objet de tirs à boulets rouges de nombreux contributeurs expliquant (à juste titre à la réflexion) qu'on ne devait pas — dans un article du main — faire un renvoi vers un article d'un projet. Tout est rentré très vite dans l'ordre et je ne recommencerai pas ! Un article doit se suffire à lui-même. S'il faut donner des explications, alors soit elles font l'objet d'un article détaillé et alors les hyperliens sont là pour ça (c'est le principe même de la technologie wiki utilisée ici via le logiciel MediaWiki), et s'il n'y a pas d'article détaillé alors on utilise les notes en bas de page, elles sont là pour ça. Cordialement. AntonyB (discuter) 23 janvier 2014 à 17:26 (CET)[répondre]
Oui, ma suggestion d'un renvoi vers le projet n'était pas bonne, d'autant que les articles n'appartiennent pas à un projet mais à Wikipédia dans son ensemble. Mais c'est tout aussi contraire aux usages de répéter un texte générique dans des milliers d'articles différents. On devrait bien trouver une solution intermédiaire, soit avec une page hors du projet, soit au moins en réduisant cette fameuse Note 2 de manière à supprimer ce qui est expliqué (ou devrait être expliqué) dans les pages encyclopédiques relatives au recensement. Par exemple : « Par convention et dans un souci d'harmonisation sur Wikipédia, le tableau et le graphique présentent les chiffres de population municipale légale tous les cinq ans à partir de 2006, ainsi que la dernière population légale. » Seudo (discuter) 23 janvier 2014 à 18:04 (CET)[répondre]
Enfin, si tu supprimes la phrase « L'évolution du nombre d'habitants est connue à travers les recensements de la population effectués dans la commune depuis 1793 » (ce que j'approuve), il faudrait aussi supprimer (ou mettre en note) la phrase « Depuis 2004, les enquêtes de recensement, etc. », car on se demande pourquoi le texte n'évoque que les années récentes. Un article ne devrait comporter dans le corps du texte, dans la mesure du possible, que des informations spécifiques au sujet de l'article. Seudo (discuter) 23 janvier 2014 à 10:52 (CET)[répondre]
Bonjour et tout à fait d'accord avec toi. C'est pourquoi je retire bien souvent des explications ici et là au sein des articles (lorsqu'elles ne sont pas spécifiques de la commune ou de la section dans laquelle elles se trouvent) pour les mettre en notes de bas de page. Cordialement. AntonyB (discuter) 23 janvier 2014 à 15:39 (CET)[répondre]
Effectivement, je suis d'accord concernant les notes, à mon avis aussi:
la Note1 peut être avantageusement supprimée
la Note2 peut être raccourcie et améliorée (mais il est en effet indispensable d'au moins maintenir, comme l'écrit AntonyB « une explication — aussi claire que possible — relative aux années retenues par la fr.wikipédia pour cette commune »)
Par ailleurs:
Pour la phrase sur le mode d'enquête, effectivement elle ne concerne que les dernières années mais elle trois utilités :
indiquer qu'il y a une rupture de série due à un changement de méthode entre les chiffres d'avant 2004 et ceux d'après, et même au sein des chiffres d'après 2004 puisque certains sont des estimations. De même, il faudrait indiquer pour chaque commune les ruptures de série dues à un changement de champ (particulièrement les changements de territoire dans le cas des fusions, etc.), voir l'exemple de Bains-sur-Oust où est précisé le changement de territoire survenu en 1872.
préciser les années spécifiques à la commune des enquêtes de recensement, dans le cas des communes de moins de 10000 habitants,
permettre de placer la Note2 relative à la convention particulière utilisée par Wikipédia. Pour les années antérieures, le mode d'enquête est le même pour toutes les communes avec les mêmes années, et ne donne pas lieu à une convention particulière sur Wikipédia.
et accessoirement fournir un lien interne vers l'article qui explique les recensements de population en France.
Cette phrase est certainement perfectible et peut-être est-ce mieux de la présenter ailleurs, par exemple dans les notes du tableau, juste avant les sources. Je ne sais pas si ce serait mieux à cet endroit mais c'est parfaitement faisable aussi (il faudrait modifier le modèle {{Tableau population d'article de commune de France}} pour qu'il accepte en entrée un paramètre notes, comme le fait le modèle {{démographie}}, d'ailleurs j'en avais fait la demande sur la page de discussion du modèle).
Effectivement dans les notes du tableau, on a actuellement des explications pour la nature des données mesurées depuis 1962 mais rien avant. Effectivement ce n'est pas très cohérent et un renvoi à un article explicatif pour toutes les années serait peut-être plus adapté.
Concernant le fait de mettre des notes spécifiques sur des années, c'est supporté par le modèle {{démographie}} (il suffit de mettre la balise <ref> après le chiffre de la population) mais à ma connaissance ce n'est pas supporté par la feuille de données car elle sert aussi au modèle qui génère le graphique, lequel, sauf erreur de ma part, ne supporte pas d'avoir une telle balise.
Concernant la fiabilité des données Ldh/EHESS/Cassini, effectivement elles ne sont pas infaillibles. J'ai corrigé par exemple une donnée pour Metz en sourçant la correction. Dans le cas de Cournon (Morbihan) je pense que le chiffre curieux de 1831 est exact et qu'il s'agit d'un événement ponctuel (camp militaire temporaire?) car on retrouve la même "anomalie" en beaucoup plus léger dans les communes voisines de Glénac etSixt-sur-Aff mais effectivement si quelqu'un a accès aux données ce serait très bien de vérifier cette donnée et de voir si une explication en est donnée dans la liste nominative de cette année là.
Je reste persuadé que les dates de recensements réels des petites communes, qui concernent plus de 90 % des communes, doivent être annoncées au lecteur avant le tableau et l'histogramme, pour qu'il n'y ait pas d'ajout intempestif, de la part de participants non au courant. Pour cela, j'ai repris une idée déjà exprimée par d'autres : je préfère actuellement utiliser plusieurs modèles permettant d'insérer cette information, plutôt que le modèle:Section démographie d'article de commune de France, trop limitatif (exemple : Parentignat#Démographie). Et je fais précéder le tout de deux articles connexes sur la démographie et les recensements en France. Père Igor (discuter) 23 janvier 2014 à 17:16 (CET)[répondre]
En tant que lecteur naïf, je trouve l'exemple de Parentignat#Démographie intéressant car le texte comme les notes évitent une verbosité excessive. Les liens internes encouragent le lecteur curieux à en savoir plus sur les méthodes de recensement. Seudo (discuter) 23 janvier 2014 à 18:21 (CET)[répondre]
Oui, cet exemple est bien, dont le texte est:
« En 2011, Parentignat comptait 475 habitants. À partir du XXIe siècle, les recensements réels des communes de moins de 10 000 habitants ont lieu tous les cinq ans (2005, 2010, 2015, etc. pour Parentignat3). Depuis 2005, les autres dates correspondent à des estimations légales. »
A vrai dire le texte du modèle que je propose était déjà assez semblable, et je l'ai rendu encore plus concis et similaire à cet exemple. Sur la même commune cela donne:
« En 2011, la commune comptait 475 habitants. Depuis 2004, les enquêtes de recensement dans les communes de moins de 10 000 habitants ont lieu tous les cinq ans (en 2005, 2010, 2015, etc. pour Parentignat3) et les chiffres de population municipale légale des autres années sont des estimationsNote 1. »
[Edit : est-ce que la fin de la phrase vous parait mieux que la version que j'avais mise antérieurement qui était plus précise mais moins compacte? (« ...et les chiffres de la population municipale légale fournis par l'Insee les autres années sont des estimations. » ) ]
La formulation « à partir du XXIe siècle » est amusante mais ne me parait pas très bonne. On croirait que nous sommes au XXIVe siècle et qu'on parle de ce qui se passait les siècles précédents... Malheureusement nous ne sommes pas encore capables de donner les chiffres jusqu'au XXIIe siècle :) Et qu'est-ce qu'un recensement « réel » (ou irréel)? J'aime le côté lyrique de ces formulations mais à mon sens ce n'est pas approprié.
Je trouve que c'est très bien de mettre les articles connexes mais dans le modèle ce n'est pas adapté car après on ne pourra plus écrire au-dessus du texte généré, or il est parfois bien de le faire (voir Metz). Mais rien n'empêche de les ajouter à la main en plus du modèle.
Sinon j'ai apporté les autres corrections suivantes dans {{Introduction population d'article de commune de France 4}}:
Suppression de la première note pour les communes de moins de 10 000 habitants
Élagage de la 2e note avec suppression de toute sa deuxième partie pour ne conserver plus que la partie sur la convention utilisée dans Wikipédia, à savoir :
« Dans le tableau des recensements et le graphique, par convention dans Wikipédia, et afin de permettre une comparaison correcte entre des recensements espacés d’une période de cinq ans, le principe a été retenu, pour les populations légales postérieures à 1999 de n’afficher dans le tableau des recensements et le graphique que les populations correspondant aux années 2006, 2011, 2016, etc., ainsi que la dernière population légale publiée par l’Insee. »
Utilisation d'un texte différent pour cette note dans le cas d'une commune de moins de 10 000 habitants, à savoir
« Dans le tableau des recensements et le graphique, par convention dans Wikipédia, afin de permettre les comparaisons entre communes selon une périodicité de cinq ans, le principe a été retenu, pour les populations légales postérieures à 1999, de n’afficher dans le tableau des recensements et le graphique, outre les années correspondant à une enquête exhaustive de recensement, que les années 2006, 2011, 2016, etc., ainsi que la dernière population légale publiée par l’Insee. »
Et j'ai corrigé des détails de code pour gérer les cas particulier (si jamais, pour les communes de moins de 10 000 habitants, la date des deux premiers recensements n'est pas renseignée dans le modèle de données, la parenthèse est supprimée).
Enfin dans le cas d'une commune inhabitée, cela affiche « En 20xx, la commune était inhabitée. » plutôt que de parler de 0 habitants. De toutes les façons c'est un cas particulier qui peut être rédigé manuellement.
Pour ma part, cela me semble OK. Quatre observations :
Sur le texte sous le tableau : cela a déjà été abordé antérieurement, mais une phrase commençant par "De 1962 à 1999 : population sans doubles comptes ..." introduit un questionnement sur la nature de la population avant 1962. Je pense qu'il conviendrait de reformuler comme suit : "Population totale avant 1962, population sans doubles comptes de 1962 à 1999, puis population municipale." Il faut quand même vérifier si on tient en nb de lignes. Les séries 1851-1962 correspondent à la définition ancienne de la population totale (municipale et comptée à part), les séries 1962-1990 à la définition nouvelle de la population totale (sans doubles comptes dans la population comptée à part). Entrer plus dans le détail sur les définitions entre avant et après 1962 dans le tableau est impossible (voir détails ici par exemple).
Pour le calendrier du recensement, le modèle d'introduction renvoie sur le-recensement-et-moi.fr, nouveau site spécifique de l'Insee apparu en 2014. Le paramètre source-recens, qui donne le calendrier départemental des recensements, avait été introduit dans le modèle de données pour donner cette information, mais autant utiliser ce lien qui est plus spécifique (même s'il faut regarder à deux fois que l'information propre à la commune est en bas à droite!);
D'une manière générale, il ne me parait pas bon de mettre un texte complémentaire après le graphique. L'ordre à prévilégier me paraît être : modèle intro/texte en clair si nécessaire/ modèle tableau/modèle graphique.
Je pense que c'est à voir au cas par cas mais qu'il ne faut pas écrire entre le tableau et le graphique car il est utile de voir les chiffres du tableau quand on lit le graphique. Ensuite entre écrire avant, ou bien écrire après pour analyser les chiffres et le graphique, pour moi les deux peuvent être tout à fait valables. -- Carfois (d) 24 janvier 2014 à 17:35 (CET)[répondre]
Pour Bains-sur-Oust, j'ai ainsi ajouté un texte plus explicite, après l'intro. S'agissant d'une commune scindée en 1872, il me semble que deux tableaux et graphiques auraient pu être utiles, un pour chacun des territoires avant et après 1872. En tout cas, cet exemple ainsi que celui des communes inhabitées, incitent à ne pas utiliser un modèle complet, mais bien les trois modèles séparés (intro/tableau/graphique). Probablement qu'à terme il faudra faire passer un bot pour remplacer le modèle de section complète par l'enchainement des trois modèles (en ajoutant un texte, visible que dans le code, disant qu'on peut ajouter du texte en clair après le modèle d'intro. Cela permettra d'éviter toute critique du type de celle du bistro d'hier sur l'impossibilité de toucher aux modèles).Roland45 (discuter) 24 janvier 2014 à 08:20 (CET)[répondre]
D'accord avec toi, il me parait mieux aussi d'utiliser les trois modèles en clair afin de permettre les ajouts rédactionnels. -- Carfois (d) 24 janvier 2014 à 17:35 (CET)[répondre]
Il y a une erreur de syntaxe et deux répétitions dans la note 2 (le n’ implique un que et non un ainsi que ; on écrit par convention puis le principe a été retenu — on écrit dans le tableau des recensements et le graphique puis de n’afficher dans le tableau des recensements et le graphique) :
« Dans le tableau des recensements et le graphique, par convention dans Wikipédia, afin de permettre les comparaisons entre communes selon une périodicité de cinq ans, le principe a été retenu, pour les populations légales postérieures à 1999, de n’afficher dans le tableau des recensements et le graphique, outre les années correspondant à une enquête exhaustive de recensement, que les années 2006, 2011, 2016, etc., ainsi que la dernière population légale publiée par l’Insee. »
que je corrigerai en :
« Par convention et afin de permettre les comparaisons entre communes, Wikipédia affiche dans le tableau des recensements et le graphique, outre les années correspondant à une enquête exhaustive de recensement, les années 2006, 2011, 2016, etc. [car 2016 n’est pas affiché], ainsi que la dernière population légale publiée par l’Insee. »
cela pour la formulation.
graphique de Bayons avec les recensements intermédiaires pour comparaison.
Cependant, sur le principe d’afficher 2006, 2011, 2016 partout :
on compare un recensement exhaustif (pour un peu moins de 20 % des communes) à des estimations (pour un peu moins de 80 %) et des enquêtes, donc on fait des comparaisons imparfaites ;
on rend les graphiques particulièrement illisibles, comme on le voit ci-contre, on ne distingue aucune des variations (le tableau affiche seulement les recensements exhaustifs) : la barre 2004 (recensement exhaustif) recouvre la barre 2006 (pour comparaison), qui touche la barre 2009 (nouveau recensement exhaustif) qui recouvre la barre 2011 (pour comparaison). La situation est moins moche sur les communes recensées en 2005 (2005 et 2006 se recouvrent, mais il y a de l'espace entre 2006 et 2010) et 2007 (idem, mais de l'autre côté) et celles recensées en 2008 sont à peu près présentables, mais les barres ne sont pas toujours séparées par un espace. D’où la question : conserve-t-on systématiquement les estimations de 2006 dans le graphique ? Si oui, avec une présentation différente ? azoée (discuter) 24 janvier 2014 à 09:18 (CET)[répondre]
Le site le-recensement-et-moi.fr ne me semble pas une bonne source puisqu'il ne donne pas directement l'information recherchée contrairement aux listes départementales (voilà celle du Puy-de-Dôme pour Parentignat). En cas de modifications d'architecture du site de l'Insee, l'archive wikiwix ne pourra jamais permettre d'accéder à une deuxième page à partir de celle qu'on appelle. C'est ainsi qu'on a réussi à sauvegarder l'historique des recensements de 2004 et 2005 sur un tiers seulement des départements français, mais permettant d'accéder à l'information de toutes les communes de ces départements. Père Igor (discuter) 24 janvier 2014 à 09:26 (CET)[répondre]
Le fait de préciser trois dates 2006, 2011, 2016, ou pour les recensements réels 2008, 2013, 2018, a pour but de bien faire assimiler la périodicité de cinq ans à un plus grand nombre de lecteurs (et pas seulement à ceux qui auront compris dès la première lecture, ou aux piliers du projet). Père Igor (discuter) 24 janvier 2014 à 09:42 (CET)[répondre]
OK sur le but et le moyen. Il faut encore reformuler pour que la note corresponde au contenu du tableau, peut être par un futur ou un exemple entre parenthèses. Pour l’instant ça ne me vient pas. azoée (discuter) 24 janvier 2014 à 10:07 (CET)[répondre]
Les modèles comportent actuellement les recensements réels + 2006 + la dernière année publiée (2011). Pour répondre à la question d'afficher ou non 2006 systématiquement, même quand ce n'est pas un recensement exhaustif, c'est ce qui avait été retenu en son temps. Mais lors de la prochaine actualisation, on pourra de fait n'afficher que les recensements exhaustifs et la dernière population. On gagnera en lisibilité.Roland45 (discuter) 24 janvier 2014 à 12:38 (CET)[répondre]
La formulation, "n'afficher, outre x, que y, z ainsi que w" me parait tout à fait juste grammaticalement mais on peut aussi tourner "n'afficher, outre x, que y, z et w" si ça semble mieux et plus clair dans la phrase. A mon sens le 2016 dans "2006, 2011, 2016, etc." ne pose pas de problème dans la formulation actuelle qui expose un principe. C'est juste dans la formulation proposée sans le mot principe que cela pose problème, d'où l'utilité à mon avis de conserver le mot principe.
Pour le lien à mettre, effectivement c'est une très bonne question. Le lien vers le site dédié a l'avantage que c'est justement un site dédié avec d'autres infos pratiques utiles mais je ne suis pas sûr de ce qui, compte tenu des avantages de chacun, est le mieux, d'autant plus que pour des cas limites où la population tourne autour de 10000, comme Marquette-lez-Lille, les deux sites de l'Insee peuvent donner des infos contradictoires! Cette ville est-elle recensée en 2015 ou bien recensée tous les ans? Cela pose aussi la question de savoir si on donne la bonne info ou non pour ces cas limites (et parfois l'on donne actuellement la mauvaise info comme pour Pierre-Bénite, cf. [13] et [14]).
Sorry ! Je n'avais même pas vu qu'il y avait la réponse sur le site dédié, perdue qu'elle était, en bas à droite, à côté de plein d'autres choses, non demandées. De plus, lorsque j'ai voulu y aller, j'ai eu droit à un questionnaire de l'Insee sur l'utilité de ce site, que j'ai voulu abandonner en cours de route et dont je n'ai pu sortir qu'en fermant sauvagement la fenêtre. Selon le nombre d'habitants de la commune en 2011, elle devrait être enquêtée chaque année mais le mieux serait peut-être de consulter la mairie à ce sujet, pour être fixés. Père Igor (discuter) 24 janvier 2014 à 18:12 (CET)[répondre]
« La commune de Marquette-lez-Lille est depuis plusieurs années à la limite du seuil des 10 000 habitants. Jusqu'en 2013 inclus, elle était interrogée chaque année par sondage, à raison de 8 % de sa population chaque année, en tant que commune de plus de 10 000 habitants. La décision a été prise de la faire passer dans le groupe des moins de 10 000 habitants : elle sera donc désormais interrogée exhaustivement. Sa première collecte exhaustive aura lieu en 2015. Elle ne sera pas du tout concernée en 2014, pour qu'elle puisse se préparer sereinement à la collecte de 2015. »
A noter toutefois que Starus (d · c · b) a indiqué qu'il craignait que la gestion du cas particulier des communes inhabitées constitue pour les serveurs Wikipédia une charge qui n'en vaut pas la peine (voir Discussion modèle:Introduction population d'article de commune de France#Communes sans habitants). La gestion d'un affichage adapté à la commune des dates de recensements exhaustifs entraîne également une charge légèrement plus importante, surtout en l'absence d'un paramètre spécifique donnant cette date dans le modèle de données (ce qui oblige à faire quelques tests pour savoir si elle s'y trouve néanmoins indirectement, comme c'est presque toujours le cas, et si oui de quelle date il s'agit). Mais je crois que c'est assez négligeable en comparaison de la charge générée par les modèles de tableau et de graphique et que cela en vaut la peine. -- Carfois (d) 30 janvier 2014 à 17:35 (CET)[répondre]
De toutes façons, aucune formulation préprogrammée ne peut expliquer les recensements de Marquette-lez-Lille passés ou à venir. L'ajout d'une phrase explicative en-dehors du (ou des) modèle(s) me parait, dans un tel cas, une évidence. Père Igor (discuter) 31 janvier 2014 à 12:22 (CET)[répondre]
barre 2010 (ou 2011) dans l’histogramme
Visuellement, une chose qui me gêne c’est quand je cherche la correspondance entre les valeurs du tableau et l’histogramme (alternance montée-descente de la population). Mais du fait que le recensement/estimation de 2010 n’est pas dessiné, on tombe toujours faux, c’est trompeur. Est-ce qu’il est prévu de le modifier dans les prochaines passes d’Alinebot ? Azoée (d) 26 juillet 2013 à 22:20 (CEST)[répondre]
Cette anomalie vient du fait de n'avoir voulu représenté dans le graphique que les recensements exhaustifs. Pour avoir l'affichage de la dernière barre dans le graphique, il suffit en fait de mettre en doublon la population du dernier recensement, dans à la fois le paramètre popn et le paramètre pop. Le nouveau programme d'actualisation 2014 corrigera cette anomalie.Roland45 (discuter) 4 décembre 2013 à 22:27 (CET)[répondre]
D'un point de vue « facilité d'édition », il me semble qu'inclure une référence via un modèle de Démographie me semble une mauvaise idée. Je pense qu'il est préférable de mettre la référence directement dans les articles concernés. — Mirgolth27 décembre 2013 à 16:25 (CET)[répondre]
Starus n'y était pour rien, c'est une de mes modifications qui avait apporté cette régression. C'est maintenant corrigé. Désolé, et merci d'avoir rapporté ici ce problème. --FDo64 (discuter) 29 décembre 2013 à 16:40 (CET)[répondre]
Corrigé. Répondu sur le bistro. Rien n'impose d'utiliser ce modèle complet avec un texte automatique. Dans les cas spécifiques, il est évident qu'il faut écrire un texte en clair.Roland45 (discuter) 23 janvier 2014 à 22:17 (CET)[répondre]
Petit défi pour les programmeurs
Dans la perspective de cheminer lentement vers wikidata (tout en progressant dans nos modèles de données), je propose un petit défi aux programmeurs et plus généralement à tous ceux qui connaissent un peu le codage des modèles (les spécialistes pourront relayer le problème dans des instances peut-être plus appropriées (dans cette première phase, l'appel vise a minima Kvardek du (d · c · b), VIGNERON (d · c · b), Carfois (d · c · b), FDo64 (d · c · b), Hexasoft (d · c · b), Starus (d · c · b)), et tous ceux qui le veulent bien.
Sachant que pour une commune de moins de 10000 habitants, on n'affiche que les années modulo 5 à partir de la première année de recensement et la dernière année, à savoir dans le cas présent 2004, 2009 et 2011, la question est : compléter le modèle d'affichage du modèle de {{Tableau population d'article de commune de France-test}} afin que le tableau produit n'affiche que 2004, 2009 et 2011 en utilisant le paramètre recens1 et bien entendu que le modèle puisse s'appliquer à tout autre modèle de données. A priori un simple test, ce ne doit pas être trop difficile. (on passera aux autres pb ensuite) (PS, j'ai volontairement simplifié le pb car actuellement on affiche aussi 2006 systématiquement. En réalité on ne devrait afficher 2006 que pour les communes dont recens1 est postérieure à 2006, donc on pourra voir ce cas de 2006 en pb n°2).Roland45 (discuter) 30 janvier 2014 à 22:04 (CET)[répondre]
Je vais faire une proposition théorique tout à l'heure, assez simple sur le principe mais surtout plus générale et portant sur le modèle de données car à mon sens la bonne solution est de faire évoluer le modèle de données, pas seulement le modèle d'affichage, sachant que les données que nous avons à manipuler ne sont pas aussi simples qu'il y parait. -- Carfois (d) 30 janvier 2014 à 23:30 (CET)[répondre]
Recensements de population en France, objectifs éditoriaux de Wikipédia et pistes d'évolutions pour traiter les données
Le paragraphe qui suit tente de faire le point sur les problématiques que nous avons avec les données de population et de proposer des idées d'évolution. Cela répond, je pense, aux problèmes soulevés par Roland45 au paragraphe précédent, tout en adressant les choses de manière beaucoup plus large.
Recensement de la population en France : les données
Les chiffres des populations des communes sont devenus d'une grande complexité depuis 1999, avec une mise à jour annuelle, et nous ont posé et nous posent encore sur le projet pas mal de fil à retordre. Je pense que le plus gros du travail a été fait mais il reste encore des éléments à mettre au point ou améliorer alors je vais tenter de récapituler la problématique de ces chiffres qui est à la base de tout.
Les chiffres de la population depuis 1999 sont obtenus selon quatre méthodes distinctes, que je vais noter en abrégé E, EC, S et ER:
(E) enquête exhaustive
1999 pour toutes les communes
années enquêtées pour les communes de moins de 10000 hab.: 2004 pour 1/5 de ces communes, 2005 pour 1/5, 2006 pour 1/5, etc.
(EC) estimation utilisant les enquêtes exhaustives d'autres années, avec calcul de type extrapolation/interpolation
années non enquêtées pour les communes de moins de 10000 hab.
(Note: la méthode exacte de calcul varie selon que l'enquête la plus proche se trouve avant ou après l'année considérée, mais je ne rentre pas dans ce niveau de détail.)
(S) estimation utilisant 5 enquêtes annuelles par sondage (formant un échantillon total de 40% des logements)
toutes les années à partir de 2006 pour les communes de plus de 10000 hab.
(ER) enquête exhaustive recalculée
1999 pour toutes les communes, recalculées par l'Insee fin 2008 avec la nouvelle définition de la population municipale (au lieu de la population sans doubles comptes) de façon à être comparables aux chiffres postérieurs (et de façon aussi à pouvoir être utilisé dans le calcul des chiffres (EC) des millésimes 2006 à 2010 inclus)
Il me semble que l'Insee a recalculé également un chiffre de population municipale pour 1990 et peut-être des années antérieures.
Donc il faut distinguer trois périodes :
en 1999 il existe deux chiffres pour toutes les communes, (E) et (ER)
en 2004 et 2005, il existe des chiffres (E) pour un peu moins de 20% des communes chaque année
en 2006 et après, il existe des chiffres pour toutes les communes, obtenus par les méthodes (E), (EC) ou (S) selon les cas, et qui sont appelés dans tous les cas "population légale".
Pour une même commune, il existe chaque année depuis 2006 un et un seul chiffre de population municipale, et sauf exception une même commune a soit toujours des chiffres méthode (S), soit toujours des chiffres méthodes (E)/(EC).
communes qui ont été créées récemment et dont la série de chiffres commence plus tard que 2006.
Je n'aborde pas ici la question des recensements antérieurs qui est finalement plus simple, y compris pour l'Ancien Régime.
Notre problématique sur Wikipédia
Les questions qui se posent pour nous sur Wikipédia sont principalement, à mon sens:
quels chiffres publier dans les tableaux?
quels chiffres utiliser pour les représentations graphiques?
quels chiffres stocker dans notre base de données?
comment les stocker et comment stocker leur sourçage?
comment traiter les cas particuliers, principalement les fusions, créations et remembrements de communes?
comment traiter les données antérieures à 1793?
comment faire en sorte que les articles et les données soient robustes aux initiatives désordonnées et non contrôlées des contributeurs? et qu'en même temps ils puissent bien sûr contribuer (dont notamment corriger les données de population erronées).
L'Insee a fait le choix de ne plus publier actuellement sur son site web les chiffres 2004 et 2005 (car ils ne sont pas dispos pour toutes les communes), de remplacer les chiffres 1999-E par les chiffres 1999-R (car il sont comparables aux chiffres plus réçents), et de publier pour toutes les communes les chiffres de toutes les années depuis 2006, qu'ils soient issus des méthodes (E), (EC) ou (S)
"LaDéHiS/EHESS/Cassini" n'a semble t-il pas mis à jour ses chiffres depuis 2008 (le site publie les chiffres 2004-E, 2005-E, 2006-E et 2006-S dans la case "2006", et laisse la case "2006" vide pour les communes qui n'ont aucun de ces chiffres, quant à 1999 il s'agit du chiffre 1999-E). "LaDéHiS/EHESS/Cassini" ne disposait probablement pas de toutes les façons des chiffres EC et ER à la date où le site a été mis à jour.
Dans Wikipédia, il a été jusqu'à présent décidé de:
publier tous les chiffres (E) quand ils sont disponibles
publier tous les chiffres des années 2006 et 2011 (E, EC ou S)
ne pas stocker dans les feuilles de données les chiffres des autres années s'ils sont de type (EC) ou (S)
Modèles existants et base de données existante
On a en gros actuellement trois familles de modèles éditoriaux spécifiques à la démographie: ceux de tableau (qui tous font appel in fine au modèle {{Démographie}} lequel utilise lui-même le module de même nom), ceux de graphique et celui de paragraphe introductif.
Ce dernier modèle, en apparence simple, montre aussi les limites de notre système actuel. L'introduction automatique de section démographie:
rédige une phrase pour indiquer la dernière population,
précise si une commune est à sondage ou à enquête exhaustives, avec une note expliquant la convention éditoriale utilisée pour les chiffres fournis dans le graphique et le tableau,
et si possible (dans la nouvelle version en test du modèle) précise le cas échant les dates des enquêtes exhaustives.
Mais les deux derniers points ne peuvent pas être traités tout à fait correctement en l'état de notre base de données car on ne peut pas traiter certains cas particuliers, cf. ceux des communes "hybrides" qui sont passées d'une méthode de recensement à l'autre en franchissant dans un sens ou l'autre le seul fatidique des 10000 habitants. Bien sûr ces cas particuliers sont peu nombreux (quoique amenés à se multiplier au fil des années) et on peut décider de les traiter manuellement et de ne pas y mettre le modèle d'introduction automatique. Mais ce n'est jamais très satisfaisant.
Toujours est-il que ceci m'a amené à me pencher sur la question du stockage des données, et je tire mon chapeau à tous ceux qui ont travaillé à la mise au point et la mise en place de la base de données constituée de pages de modèles de données car c'est un énorme travail (auquel je n'ai pas du tout participé) et très réussi, qui fonctionne.
Notre base de données est constituée pour chaque commune:
Pour le futur, j'ai lu, notamment dans les discussions du jour sur la PDD de Roland45, qu'il était question:
de transférer cette base de données vers Wikidata (actuellement pas encore opérationnel pour cet usage, si j'ai bien compris),
de ré-évaluer plus tard (l'année prochaine?) quelles conventions éditoriales utiliser.
Je constate aussi que le système actuel pose plusieurs problèmes (contributeurs qui ajouteraient trop d'années dans la base par rapport à ce que l'on veut afficher, barres qui se retrouvent collées dans les graphiques, gestion des cas particuliers, etc.).
Idées pour la base de données
J'espère que ma récapitulation ci-dessus de la problématique telle que je la vois peut aider à la réflexion.
Également voici quelques idées d'évolution pour la base de données.
A titre personnel, si je devais améliorer la base de données actuelle faite d'attributs (ou "champs" ou "paramètres" selon la terminologie qu'on emploie) dans des feuilles de données par commune, je verrais une structure comme suit (en l'occurrence avec l'exemple d'Adon), en notant:
en rouge les ajouts par rapport à la structure existante
en violet le déplacement au sein de la feuille de donnée de certains attributs concernant les sources particulières aux années 2000 (suppression des attributs recensn et renommage des attributs source-rencensn)
en vert ce que je renommerais (facultatif, c'est mieux mais c'est du détail)
Attributs graphn et tabn (s'ils sont non définis ou vides on affiche l'année en question ; s'ils valent "masquer" on ne l'affiche pas) [NB: on pourrait aussi nommer l'attribut d'affichage du graphique histn au lieu de graphn sachant qu'a priori c'est pour un histogramme.]
Facilité de réglage de l'affichage, potentiellement différencié entre le graphique et le tableau (utile pour quand dans le graphique trop d'années trop proches sont dessinées).
Un bot peut initialiser les attributs d'affichage (sortes de tags) en fonction de la convention voulue. Ensuite un contributeur peut les adapter en fonction du résultat souhaité et du cas particulier.
Présence de toutes les années :
Pas de problème d'ajout non souhaité d'années supplémentaires par des contributeurs puisque normalement tout y est déjà, et que si on en ajoute on peut en neutraliser l'affichage dans le tableau et/ou le graphique s'il n'est pas souhaité.
Flexibilité d'avoir les données dans la base, si on en a besoin dans certain cas ou si on change de convention d'affichage
Ancien Régime :
Cette base de données supporte le stockage et l'affichage des données d'Ancien Régime, et on peut très bien décider, par exemple, de les afficher dans le tableau et pas dans le graphique. C'est avant tout une question éditoriale car techniquement tout est faisable.
La nomenclature an-n est en fait exactement la même que pour les années post-1793 mais avec des numéros d'index négatifs (finalement cet index est une sorte d'avatar du calendrier républicain!). Cette propriété pourrait potentiellement être pratique. Ceci étant, on peut aussi appeler l'attribut an-ARn si on trouve que c'est plus adapté de mettre en évidence que c'est de l'Ancien Régime.
La numérotation séparée des années post-1793 facilite l'insertion d'une donnée d'Ancien Régime: pas besoin de redécaler tous les index.
Attribut methoden :
Il peut être utilisé pour décider des valeurs à donner aux attributs d'affichage, selon la convention Wikipédi que l'on décide. (on peut faire passer un bot pour changer les attributs d'affichage en fonction de l'attribut de méthode, si l'on continue à avoir une convention qui utilise ce critère pour l'affichage ou non de certaines années).
On pourrait éventuellement l'utiliser pour modifier l'affichage des données en fonction de la méthode utilisée (mettre une note précisant la nature du recensement, ou bien afficher en italique, gras, couleur ou autre lorsque c'est un recensement exhaustif, ou couleur de barre plus sombre dans l'histogramme, etc.). Les possibilités sont nombreuses
Éventuellement si pour un besoin ponctuel (dans un article dédié à la démographie d'une ville?), on veut afficher les données pour une série particulière, on peut faire un modèle qui affiche le type de données que l'on veut. (par exemple si l'on fait une série allant de 1999 à maintenant, on prendra pour 1999 la valeur en population municipale et non en population sans doubles comptes).
Il peut servir à décrire quel est le mode de recensement utilisé dans la commune, y compris pour les cas particuliers.
A vrai dire l'attribut methoden serait d'une utilité a priori moindre que les autres mais je pense qu'il peut être utile de l'avoir.
De manière générale flexibilité de manière générale pour gérer les cas particuliers ou pour si on décide de changer de convention d'affichage (par exemple peut-être un jour nous déciderons de faire comme l'Insee et ne pas afficher les années 2004 et 2005, ou de prendre en 1999 les données de population municipale (methoden=ER) plutôt que de population sans double compte (code>methoden=E entre 1962 et 1999).
Je pense que disposer d'un attribut n2006 contenant le numéro d'index de l'année 2006 permet d'accéder facilement aux années post-2006, et de faciliter le travail des modèles qui n'afficheraient que ces données ou bien qui les traiteraient de façon différenciée (par exemple ne faire attention à methoden qu'à partir de 2006. Idem pour n1990 quoique j'en sois moins sûr.
Il n'est pas trop compliqué de passer du modèle de feuille de donnée existant au modèle proposé puisqu'il n'y a que des paramètres à ajouter (plus quelques-un en violet à supprimer mais cela ne gène pas si on les laisse temporairement), et que d'autre part les modèles d'affichage mis à jour afficheront correctement les données d'une commune ayant une feuille de données de la forme actuelle (sauf pour les sources mais il suffit de prévoir ce cas dans le code, ce qui est très simple puisqu'il suffit par exemple de faire un appel au modèle actuel d'affichage des sources dans le cas où le paramètre recens1 est défini).
On peut aussi imaginer d'autres attributs, comme des références ou notes optionnelles pour chaque année (un attribut notesn). Le modèle {{Démographie}} sait déjà très bien gérer ça et il n'y a "que" à adapter le modèle intermédiaire.
Voilà les quelques idées que je voulais proposer, mes deux centimes du jour, et dans lesquelles on peut éventuellement piocher pour faire évoluer la base de données population et les modèles. Ce n'est rien de fondamentalement nouveau d'ailleurs, juste des extensions de l'existant.
Il me semble que Wikidata, si on décide d'aller vers une base de donnée Wikidata lorsqu'il sera prêt, ne sera pas fondamentalement différent dans les principes. A vérifier au fait dans le choix de migrer ou non vers Wikidata si ce dernier est réellement plus performant, par exemple en termes de rapidité (est-ce plus rapide de lire une donnée dans Wikidata où dans un modèle de donnée?), et s'il est plus simple d'utilisation pour les contributeurs ou plus compliqué pour corriger une donnée erronée.
La récapitulation que j'ai faite dans les premiers sous-paragraphes peut être également utile à une éventuelle réflexion sur la convention à utiliser sur Wikipédia (par exemple, après tout, pourquoi ne publierait-on pas tout simplement les mêmes données que l'Insee?). Personnellement je n'ai rien contre la convention actuelle, au contraire elle me parait bien, mais je suis conscient que d'autres conventions seraient valables aussi. En matière de convention, à mon sens l'important est de savoir ce que l'on fait et pourquoi. -- Carfois (d) 31 janvier 2014 à 06:19 (CET)[répondre]
Discussion
Merci Carfois (d · c · b) pour cette mise au point, la méthode de discussion proposée et les propositions.
Comment fait-on pour discuter : une sous-section discussion dans chaque section (pour vérifier que nous sommes d’accord sur les constats techniques, les problématiques, les objectifs, puis une discussion sur les paramètres) ? Ou une sous-discussion globale ici ? azoée (discuter) 31 janvier 2014 à 07:54 (CET)[répondre]
Merci aussi. Avant d'ordonner la réponse, voici quelques éléments de réponse globaux.
Carfois (d · c · b) a parfaitement résumé la situation.
Sur la proposition, il apparait, selon mon point de vue que, en se donnant comme objectif de simplifier le modèle de données, il se complexifie sacrément en ajoutant de nouveaux paramètres. Je m'explique.
Sur la suppression des lignes violettes : pourquoi pas. Je les ai ajoutées cette année pour éviter d'ajouter du code dans le modèle et avoir directement en clair les années à afficher et leur sources. Il est évident que si on peut calculer automatiquement les années à afficher, on peut reconstituer automatiquement les url des sources à partir de fragments d'url génériques. D'où précisément le problème que je pose ci-dessus : comment trouver les années à afficher à partir de l'année de recensement. C'est un test simplissime dans Excel, mais je suis moins bon dans le codage des modèles, d'où le problème posé.
Sur l'ajout de nouveaux paramètres associés aux données de population. Tu t'affranchis du test ci-dessus en ajoutant de nouveaux paramètres (ou attributs) dans le modèle. Il faut en effet toujours faire un choix : met-on l'info dans le modèle ou la recalcule-t-on ? Selon mon point de vue, in fine, le modèle de données doit (dans Wikidata) être le plus épuré possible. En effet chaque année on chargera des données brutes (en 2015, pour chaque commune, on chargera population 2012 = popx, ou tout au moins, le doublet (popx,2012). Vouloir ajouter en même temps des paramètres complémentaires (comme tu le proposes) conduit à introduire des tests dans le modèle (ou script) de chargement des données (sur Wikipédia ou wikidata), qui pourraient être faits dans le modèle (ou script ou module) d'affichage.
Bien entendu certains ajouts comme unit-1, unit-2 sont utiles.
Il me semble donc que l'on doive plutôt réfléchir à une amélioration des modèles pour traiter un ensemble de données du type (popx, annéex) (si tant est que l'on puisse bien traiter ces deux données entièrement dans les modèles d'affichage récupérées sur Wikidata en tant que variables). Par rapport au modèle de données actuel devraient donc disparaitre les données suivantes : max (ou pop-max), nombre. Concernant le nombre, il ne faut pas oublier que dans Wikidata, les années ne seront pas numérotées, mais il ne s'agira que d'une suite de doublets (popx,anx) (a moins que je me trompe). Il faudra donc savoir dénombrer ces doublets, les ordonner selon anx, trouver le maximum et introduire des tests pour l'affichage. C'est pourquoi avant d'en arriver là, je propose d'y aller pragmatiquement et, pas à pas, de lever chacune des difficultés (ce qui n'empêche pas de réfléchir à l'amélioration du modèle).Roland45 (discuter) 31 janvier 2014 à 08:17 (CET)[répondre]
Ouch, on rentre dans la programmation là :-).
Je n'objecte rien à tes observations techniques, mais à la fois mon expérience dans une boite d'édition de logiciels, et ce que je sais du monde du logiciel libre, c'est que toute programmation est bien meilleure (plus efficace) quand on a soigneusement réfléchi avant de jeter le moindre morceau de code sur « la page blance », qu'il y a souvent moins de bogues en faisant ainsi qu'en ajoutant au fur et à mesure, et que les ajouts ultérieurs sont plus faciles (parce qu'au moins on en a prévu quelques uns).
Azoee :, oui, cela me parait très bien de faire la discussion dans ce paragraphe là, dans lequel on pourra d'ailleurs si besoin faire des sous-paragraphes selon le thème discuté). D'accord aussi avec toi qu'il vaut mieux commencer par une réflexion d'ensemble que de vouloir ajouter des couches de code successives pour traiter les problèmes un à un. Cela n'empêche pas après de faire les choses par étapes mais c'est utile de savoir dès le départ où on va.
Roland45 :Merci pour toutes tes remarques. Ceci dit, je ne partage pas tes craintes.
Je ne connais pas Wikidata, mais je serais très surpris qu'on ne puisse pas continuer à utiliser des index, avec des triplets ou plus (n, popn, ann,...) plutôt que des doublets (n, popn). Si jamais Wikidata permet de créer des données de type tableau, n pourrait aussi être le numéro de ligne dans le tableau.
Sur les lignes violettes, je ne propose pas de les supprimer, elles sont très utiles, mais simplement de les déplacer, plus précisément de renommer les attributs source-rencensn (avec n de 1 à 4) en attributs sourcen (avec n prenant la valeur de l'index de l'année, ce qui rend inutile de répéter l'année dans un attribut recensn puisqu'elles sont déjà dans ann et c'est pour ça que je supprime les recensn). Le contenu de sourcen reste le même, c'est-à-dire une url complète, pas question de mettre des fragments d'url (j'ai mis des ... ci-dessus dans les liens juste de manière à alléger la présentation mais ce sont toujours des url complètes en réalité). Ensuite techniquement pour les afficher, si on veut faire comme maintenant, au lieu de parcourir les source-rencensn de 1 à 4 en testant leur existence, on parcourra les sourcen de n2006 - 1 à nombre, en testant sur leur existence et sur la valeur de l'attribut d'affichage tabn. Cette manière de stocker les données permet 1° de faire l'économie des attributs recensn, 2° d'avoir un système homogène avec une seule série d'index et 3° d'apporter plus de flexibilité (par exemple si dans le tableau on souhaite plutôt afficher les sources relatives à une seule année sous forme de référence accolée à la population de l'année en question à l'intérieur du tableau, ce sera techniquement tout à fait faisable et simple à faire).
Oui, effectivement, la présence de certains attributs dans la base de donnée permet de s'affranchir de faire certains tests dans les modèles d'affichage. Cela simplifie considérablement la programmation des modèles ou modules d'affichage et accélère leur exécution. Je ne vois pas où est l'inconvénient et suis très défavorable à la suppression de l'attribut nombre.
Tu écris « le problème que je pose ci-dessus : comment trouver les années à afficher à partir de l'année de recensement. C'est un test simplissime dans Excel, mais je suis moins bon dans le codage des modèles, d'où le problème posé. » Ce constat abonde dans le sens de la solution que je propose. Oui, tu as parfaitement raison, c'est compliqué de multiplier les tests dans les modèles, en tout cas dans ceux écrits avec les fonctions parseurs dont la typographie épouvantable rend très vite le code difficilement lisible (avec des dizaines de {{ et de }} dont on a rapidement du mal à repérer lesquels ferment lesquels) et difficile à maintenir, et en plus cela augmente la charge des serveurs et ralentit l’exécution des modèles. Alors si c'est simplissime à faire sous Excel, autant charger un bot de mettre une bonne fois pour toutes la valeur voulue dans des attributs d'affichage ("masquer" ou non), que l'on n'aura pas à redéterminer à chaque exécution d'un modèle. Sans compter la souplesse apportée qui permet de gérer les cas particuliers et de donner la main au contributeur pour les cas les plus particuliers. -- Carfois (d) 31 janvier 2014 à 12:47 (CET)[répondre]
sur les paramètres complémentaires associés aux données : Je doute que ceux qui vont charger les données sur Wikidata se posent des questions existentielles par rapport à l'utilisation future des données (à moins que ce ne soient des adeptes des pdd du projet commes de France et qu'ils les aient toutes lues!). Les données étant publiées par l'Insee (une donnée pour une commune), ils vont charger les données direct sur Wikidata, sans les mouliner au travers d'un système expert qui ajouterait des paramètres spécifiques sur les modes d'affichage de chacune d'entre elles. C'est pourquoi je dis qu'il faut s'orienter vers un traitement des données dans le modèle d'affichage. Quant à l'ergonomie des modèles en parseur fonctions, c'est vrai que ça fait peur. Dès le troisième niveau de doubles accolades, on s'y perd. Mais il n'empêche que ça fonctionne et tout le monde peut y avoir accès.
Sur le numéro n de l'année, j'ai dit qu'on ne le chargeait pas sur wikidata pour chaque doublet ou triplet pour la bonne raison que si on ajoute une valeur de population dans la base, il faudrait modifier la valeur n de toutes les populations déjà chargées et dont la date est postérieure à n. C'est en tout cas ce que l'on fait sur notre modèle actuel où la modification est élémentaire, alors que ce le sera particulièrement moins sur Wikidata.
« ceux qui vont charger les données sur Wikidata » : ah bon, ce ne serait pas nous? Aucun intérêt d'utiliser Wikidata alors si on n'a pas le contrôle des données qui s'y trouvent et si les contributeurs ne peuvent pas corriger les données erronées. Autant rester sur la solution actuelle de feuilles de données (ce que j'appelle "feuilles de données" sont techniquement les modèles dédiés à contenir les données que l'on a actuellement).
plus généralement je crois AMHA qu'il ne faut pour l'instant pas trop se focaliser sur Wikidata alors que cet outil n'est, si j'ai bien compris, même pas encore prêt pour stocker des données numériques et qu'on ignore en grande partie comment il sera fait. Je pense qu'il faut déjà voir comment on fait avec la "technologie" actuelle et on verra bien le moment venu comment transposer dans la technologie future, si toutefois on trouve un intérêt à changer de technologie. -- Carfois (d) 31 janvier 2014 à 14:08 (CET)[répondre]
PS: Je viens néanmoins de jeter un œil sur Wikidata:Glossary#Claims and Statements et je vois que manifestement il existe au moins une manière de transposer nos feuilles de données actuelles : on aurait l'identifiant de la commune comme "item" (a priori son nom Wikipédia), lequel contiendrait des "property" (correspondant à ce que j'ai appelé attributs dans notre système actuel) an1, pop1, an2, pop2, etc., lesquels contiendraient des "valeurs" (numériques ou chaînes de caractères), exactement comme maintenant. Ce ne serait peut-être pas la meilleure manière de transposer notre base de données mais c'en est au moins une donc sur le principe, je ne crois pas qu'il faille s'inquiéter de ce que l'organisation des données dans nos feuilles de données ne serait pas transposable d'une manière ou d'une autre sur Wikidata. -- Carfois (d) 31 janvier 2014 à 14:48 (CET)[répondre]
Version "substable" de ce modèle
Comme indiqué sur Discussion Projet:Communes de France#Introductions automatiques des sections "Démographie", j'ai lu assez souvent que le modèle {{Section démographie d'article de commune de France}} n'était finalement pas une bonne idée et qu'il valait mieux avoir son contenu en dur, à savoir les trois modèles d'introduction, de tableau et de graphique. Je partage totalement cet avis et j'ai donc créé une version « substable » de ce modèle, en une sous-page /subst. Concrètement cela veut dire qu'il suffit de remplacer {{Section démographie d'article de commune de France}} par {{subst:Section démographie d'article de commune de France/subst}} pour après enregistrement ne plus avoir dans l'article {{Section démographie d'article de commune de France}} mais avoir à la place les trois modèles spécifiques. Un bot pourrait d'ailleurs certainement effectuer ce remplacement. -- Carfois (d) 5 février 2014 à 17:33 (CET)[répondre]
N'allons pas trop vite en besogne, il faudrait déjà que tous les articles possèdent une section démographique à jour de ses données ! Je préfère que l'on consacre du temps à finir ce déploiement sur les 10,44 % qui restent Ceci dit, je suis assez d'accord sur le côté « pis aller », ce qui m'importe plus, ce sont bien les tableaux et les graphiques, plus que cette introduction qui, si elle est parfois un peu confuse, n'en reste pas moins juste au niveau des informations qu'elle contient. — S t a r u s – ¡Dímelo!–5 février 2014 à 18:54 (CET)[répondre]
J'abonde la proposition de Carfois. Outre la résolution quasi-immédiate des principaux problèmes d'accessibilité du modèle, le remplacement des modèles existants pourrait être fait par bot, ce qui ne demandera qu'un minimum de travail. - Bzh99(discuter)5 février 2014 à 19:07 (CET)[répondre]
Ok Starus, chaque chose en son temps, je suis d'accord, si ce n'est qu'AMHA en l'occurrence il vaut mieux justement dès à présent pour les 10,44% qui restent (sauf les cas particuliers où il existe une meilleure solution que ces modèles) mettre {{subst:Section démographie d'article de commune de France/subst}} plutôt que de mettre {{Section démographie d'article de commune de France}}, sachant que le constat semble général qu'il vaut mieux avoir les trois modèles "intro", "tableau" et "graphique" séparément plutôt que de les avoir de manière cachée dans le modèle unique "section". -- Carfois (d) 5 février 2014 à 19:15 (CET)[répondre]
Déjà, il valait mieux que que j'aille voir à quoi ressemblait ce modèle, ce que je viens de faire et qui me permet de constater que j'étais complètement à côté ! En fait, j'avais compris que le subst servait à passer en dur (en mode texte, donc) la seule introduction. Or, ce test montre qu'il s'agit simplement de remplacer un seul modèle par trois, je ne vois donc pas trop l'intérêt de subster, sachant qu'en effet, il vaut mieux passer un bot une fois pour toutes et supprimer ce modèle, surtout qu'après déploiement complet, quelles que soient les conditions spécifiques qui pourraient s'appliquer, une utilisation nouvelle ne se fera guère que dans les rares cas de fusion ou défusion de communes (sauf évidemment si la France annexe un pays et qu'elle crée 10 000 communes de plus ). En revanche, ne vaut-il pas mieux profiter du passage du bot pour subster l'introduction, en conservant en variable (j'y tiens !) la toute première phrase « En XXXX, la commune comptait YY YYY habitants » grâce à {{Dernière population commune de France}}. — S t a r u s – ¡Dímelo!–5 février 2014 à 19:55 (CET)[répondre]
Ah effectivement, je ne l'avais pas testé, donc je retire ce que j'ai dis : il n'améliore pas significativement l'accessibilité... Pour bien faire, il faudrait subster les trois modèles en question. - Bzh99(discuter)5 février 2014 à 20:08 (CET)[répondre]
Euh, non, j'aurais tendance à dire « surtout pas », car si on le fait, le code va redevenir celui-ci, ce qui n'apportera rien par rapport au modèle actuel, plus compact et moins sujet à des modifications hasardeuses. Il vaut mieux réserver l'option de subster les deux derniers modèles aux contributeurs qui savent ce qu'ils font et qui ont un besoin bien particulier (je pense aux cas où la démographie est traitée dans un article à part et dans lequel les couleurs ou dimensions des tableaux/graphiques sont personnalisées). — S t a r u s – ¡Dímelo!–5 février 2014 à 20:46 (CET)[répondre]
Tout à fait d'accord avec toi, Starus sur ton avant dernier post (et pas d'avis tranché sur le dernier). Il faudrait à terme subster le modèle d'introduction également (en conservant effectivement la dernière population et son année sous une forme qui la met à jour automatique).
Je vois ce travail en 4 étapes dont les 3 premières sont en fait parallèles :
Mise en place dans les articles des 3 modèles, intro, tableau et graphique. (presque terminé mais fait de manière indirecte dans la plupart des articles avec un modèle "section")
(dès que possible) Dans les articles où le modèle "section" a été inséré, remplacement par les trois modèles en clair. (c'est le subst dont je parlais en initiant cette discussion)
(en même temps que les deux étapes précédentes) Amélioration du texte de l'introduction automatique (en cours)
Lorsque le texte de l'intro est au point, c'est-à-dire lorsqu'il recueille un consensus suffisant, on le subste dans tous les articles.
Effectivement si on dispose d'un texte d'intro au point suffisamment vite, on peut faire les étapes 2 et 4 en un seul passage de bot. Par ailleurs on peut aux étapes 1 et 2 préciser dans le commentaire html qui suit le modèle intro qu'il s'agit d'un modèle dont l'existence est temporaire et qu'il sera automatiquement remplacé par du texte en dur quand le texte sera au point, voire même inviter les contributeurs à donner dans la PDD du modèle d'intro leur avis et leurs remarques sur le texte.
Oui Bzh-99, c'est sûr, le subst partiel de l'étape 3 ne règle pas tous les problèmes et je ne vois cela que comme une étape. Mais cette étape qui met les 3 modèles en clair au lieu d'un permet déjà aux contributeurs d'écrire dans la section Démographie (y compris entre l'introduction et le graphique) alors qu'avec un seul modèle "section", la section entière parait être verrouillée et totalement inaccessible au contributeur lambda.
Tout à fait d'accord avec toi sur l'objectif d'un subst du modèle intro.
En revanche la question est plus compliquée pour le subst des deux autres modèles. Cela signifierait d'abandonner l'utilisation des feuilles de données de population et de mettre ces données en fait directement dans les articles (dans les paramètres du modèle {{Démographie}} pour le tableau et dans les paramètre du modèle {{Histogramme population manuel}}). J'avoue que c'est ce que j'ai fait moi-même pour l'instant dans l'article de Paris car le modèle général, du moins en l'état actuel, ne me paraissait pas adapté à ce cas particulier, notamment pour les indications des sources et pour le fait de n'afficher dans le graphique qu'une partie des données (histoire de ne pas afficher des recensements trop proches dont les barres se confondent et de ne pas afficher les données d'Ancien Régime). Je suis certain de l'utilité de stocker le dernier chiffre de population dans la feuille de donnée. Mais concernant les autres chiffres, qui ne requièrent pas une mise à jour annuelle, je n'ai personnellement pas d'avis tranché sur la meilleure marche à suivre. En tout cas si on souhaite continuer à utiliser pour cela les feuilles de données, autrement dit une base de données de population, j'ai fait une proposition d'amélioration du format de cette feuille de données afin de lui donner la souplesse de gérer les cas particuliers. -- Carfois (d) 5 février 2014 à 21:23 (CET)[répondre]
J'ai mis à jour {{Introduction population d'article de commune de France 4}} de sorte qu'il est dorénavant substituable (et toujours utilisable en inclusion également). Cependant je pense qu'avant de l'utiliser en mode substitution, il faut être d'accord sur le texte et en particulier sur la présence ou non de la note sur la convention Wikipédia (car on pourrait aussi la mettre dans le tableau) et si on la laisse dans l'intro si on tient vraiment à l'avoir en dur ou bien si on la met dans un modèle (par exemple {{note convention affichage données population commune moins de 10000}})) au cas où on ferait un jour évoluer la convention.
Une restriction d'utilisation est qu'il faut au préalable rendre les feuilles de données également substituables, ce qui se fait en changeant {{#switch en {{safesubst:#switch. Pour une commune, une fois que cette petite addition est faite dans la feuille de données de population (diff pour Argentan) et dans la feuille d'informations générales (diff pour Argentan), il suffit d'appliquer {{subst:Introduction population d'article de commune de France 4}} pour avoir le texte de l'introduction en dur. Voir le diff pour Argentan (plus de 10.000 habitants) et le diff pour Cournon (Morbihan) (moins de 10.000 habitants). -- Carfois (d) 6 février 2014 à 03:38 (CET)[répondre]
Dieu sait que j'aime ce qui est vite fait bien fait mais j'ai quelques inquiétudes (je ne crois d'ailleurs pas être le seul !) sur une précipitation malencontreuse.
1. L'avantage du modèle {{Section démographie d'article de commune de France}} est qu'il a été étudié pour s'adapter à l'ensemble des communes de France, avec certes quelques nuances qui sont actuellement gérées en local. Le transformer en trois modèles est une étape quasi irréversible car si l'on se rend compte que c'est problématique, il sera difficile de gérer les adaptations qui auront pu être faites entre temps.
2. Subster l'introduction sur 31150 communes c'est pire, car si l'on se rend compte d'une erreur et d'un truc mal calibré, retransformer du texte en modèle sera catastrophique.
3. Pour garder le même mot, je suis catastrophé à l'idée qu'on retransforme déjà toutes les données chiffrées de Roland45 (d · c) « en dur » dans les 36700 articles. Petite digression, ce train dans lequel j'avoue être monté en marche a été l'objet d'années de mises au point, c'est la première année que dans les tout premiers jours de janvier l'intégralité des infoboxes ont possédé une population à jour. Il reste encore environ 8 600 communes qui n'ont pas de démographie complète (70 % des modèles démographie que j'ai remplacés jusqu'à présent avaient des données de 1962 à 2009 !). Sans doute y a-t-il dans ce chiffre les quelque 1500 fusions qui rendent bancales des données linéaires de 1793 à 2011, mais c'est finalement un pourcentage faible.
4. Alors que l'objectif était de créer des modèles qui s'adaptent à toutes les communes en conservant la même pertinence, je vois se développer des versions 1, 2 et 4, je commence à être perdu et il faut aussi penser à ceux qui prendront la relève.
5. Les discussions s'éparpillent, celle-ci est, par exemple, 7 fois moins suivie que la page du projet.
OK pour remplacer le modèle {{Section démographie d'article de commune de France}} par les trois modèles intro/tableau/graphique. Mais se pose déjà une question de fond : quelle forme retenir : les modèles en enfilade, ce qui donne un affichage où tableau et graphique sont empilé, particulièrement disgracieux sur un écran 16:9, ou bien les mettre en tableau avec un appui à gauche (solution retenue pour certaines communes du Loiret), permettant un affichage cote à cote pour un écran 16:9 (voir Artenay) ?
Pas formellement contre pour écrire en dur l'intro à terme. Mais le texte n'est actuellement pas encore suffisamment stabilisé. Ce texte doit contenir en clair les vraies années de recensements avec les références correspondantes (ex : "pour la commune de xx, les recensements sont éralisés, en 2007, 2012, 2017, etc"). C'est précisément pour cela que j'ai introduit dans les modèles les paramètres recensn et source-recensn. Si on écrit en dur le texte actuel, autant dire que ces paramètres ne servent à rien. Prochainement je proposerai un nouveau code pour l'intro, prenant en compte ces paramètres.
Formellement contre l'écriture en dur des données dans les articles. On reviendrait trois ans en arrière et on ne pourrait plus actualiser (sans compter qu'on irait à l'encontre de la perspective des données sur Wikidata).Roland45 (discuter) 6 février 2014 à 13:59 (CET)[répondre]
Oui, il n'est pas question de se précipiter, ni de remettre en cause l'énorme travail réalisé depuis quelques années dont les résultats sont excellents (plus qu'un seul modèle de base pour les tableaux démographique, {{Démographie}}, là où autrefois une myriade de modèles ne pouvaient chacun gérer que des cas particuliers, un modèle capable de générer a priori les graphiques de n'importe quelle commune {{Histogramme population manuel}}, des feuilles de données qui associées aux modèles communaux de tableau et de graphique permettent la mise à jour automatisée des populations chaque année, une charte graphique, des données depuis 1793 pour presque toutes les communes, etc.). Mon propos est juste de continuer ce travail, au rythme qu'il faudra, afin de continuer à améliorer les sections "Démographie" des communes.
Pour reprendre la numérotation de Starus ci-dessus:
Oui, si on supprime {{Section démographie d'article de commune de France}}, il sera difficile de revenir en arrière, mais n'a t-on pas aujourd'hui déjà assez de recul et de feed-back pour voir que c'est mieux sans ce modèle? qui en pratique empêche les contributeurs de contribuer en section "Démographie", c'est-à-dire d'écrire dans cette section. Et que c'est mieux d'avoir à la place tout simplement en clair les 3 modèles intro, tableau et graphique. Roland45, merci pour l'info sur la question de l'affichage en 16/9e, je n'avais pas vu cette problématique. Ceci étant, la question de l'alignement du tableau n'est pas gérée par le modèle "section" mais par le modèle "tableau", donc il n'y a pas d'inconvénient me semble t-il à supprimer le modèle "section". Mais si vraiment on veut y aller par étapes, on peut dans un 1er temps conserver le tableau et le graphique dans un même modèle, et ne couper section qu'en deux, "intro" et "tableau & graphique".
Oui, il faut y aller très prudemment et très progressivement pour un substage de l'intro car ce sera irréversible et il faut que l'intro soit bien au point. D'abord mettre au point le texte, mettre à jour le modèle intro pour que ce texte soit rendu sur les communes, attendre le feed-back, l'améliorer encore probablement, et ensuite seulement subster par étapes, essayer dans quelques articles, puis généraliser par étapes.
Les feuilles de données ont permis d'accomplir trois objectifs de natures distinctes: 1) automatiser la mise à jour annuelle des données; 2) avoir des articles qui contiennent presque tous les données depuis 1793; 3) n'avoir les données qu'à un endroit (et non pas une fois dans le tableau et une fois dans le graphique). La décision éventuelle de transférer les données anciennes en dur dans les articles, puisque l'objectif 2) est définitivement atteint ou en passe de l'être, ne peut être prise le cas échéant qu'après une longue réflexion. Je ne suis pas spécialement en faveur de cette option, loin de là, je suis même a priori favorable à conserver la base de donnée et à l'étendre sur Wikidata pour qu'elle puisse servir aux autres Wikipédia, mais je pense aussi que cette option de mettre en dur les données n'étant pas sujettes à mise à jour ne peut pas non plus être totalement écartée d'emblée avant d'avoir mené une réflexion approfondie sur les objectifs éditoriaux et l'usage que l'on veut faire de la base de données. Concernant le chiffre des 1532 fusions, c'est le chiffre depuis 1943. Il est probablement à multiplier par 3 environ si on veut avoir une estimation à la louche du chiffre depuis 1793 (voire plus car il y a eu beaucoup de remaniements avant 1900). La base de données actuelle ne gère que de manière incomplète ces cas mais à vrai dire ce n'est pas un problème de fond car on pourra facilement y trouver des solutions (comme créer une feuille de donnée par ancienne commune) et cela ne change rien à la problématique générale.
Le modèle intro 4 répond toujours à l'objectif de créer un modèle unique qui s'adapte à toutes les communes en conservant la même pertinence. L'idée est qu'il s'adapte encore mieux et soit encore plus pertinent que le modèle actuel qu'il se propose de remplacer. Roland45, pas la peine de proposer un nouveau code pour afficher en clair "pour la commune de xx, les recensements sont réalisés, en 2007, 2012, 2017, etc" au moyen de recens1 : c'est précisément l'essentiel de l'amélioration apportée par intro 4! Sur 87 lignes de code, 48 (dont 20 de commentaires explicatifs) sont dédiées à ce point précis, en allant lire les valeurs de recens1 et recens2 dans les feuilles de données pour afficher le texte qui convient, et en gérant tous les cas possibles de manière à fonctionner pour n'importe quelle commune (même si recens1 et/ou recens2 n'est pas renseigné, auquel cas un lien reste néanmoins fourni en référence vers la page donnant l'année de prochain recensement). Il vaut mieux, AMHA, consacrer ton énergie à améliorer intro 4 (formulation, notes, etc.) qu'à recoder ce qu'il fait déjà.
oui, en effet les discussions s'éparpillent sur les différentes PDD. Je vois ces PDD ainsi: les PDD des modèles "intro", "tableau" et "graphique" pour les questions qui ne concernent que l'un de ces modèles, la PDD du modèle "section" pour les questions touchant le modèle "section" ou plusieurs de ses modèles sous-jacents (intro, tableau, graphique), la PDD Modèles de données pour les questions relatives uniquement au modèle de donnée, la PDD Projet pour quand on veut toucher plus de monde (il manque cependant une PDD pour les questions touchant à la fois le modèle de donnée et les modèles d'affichage, donc dans ce cas, en ce qui me concerne, j'écris alors sur la PDD section). Mais il y a peut-être moyen de mieux organiser tout ça. -- Carfois (d) 6 février 2014 à 16:21 (CET)[répondre]
Autant, quand un contributeur ou un groupe de contributeurs suit régulièrement ou apporte une valeur ajoutée spécifique à la section, à partir de sources complémentaires, l'usage distinct de Intro, Tableau et Graphique, apporte une réelle souplesse ; autant le modèle Section, sur les articles « morts », où personne n'intervient jamais, me semble préférable. On a tout ce qui est nécessaire, c'est difficilement vandalisable (ou alors trop gros pour que ça passe inaperçu). Qui ira un jour vérifier les chiffres d'un tableau démographie ?
si on subste, on va au moins conserver les modèles Dernière population et Dernière population avec paramètre date, avec probablement un autre modèle pour indiquer l'année de recensement. Soit : un peu de texte, beaucoup de code, un risque d'erreurs, pour un texte qui a peu vocation à être changé. Pas sûr d'en voir l'intérêt (sauf permettre une édition et faciliter la lecture du code aux contributeurs, ce qui certes est déjà énorme).
en tout cas, ce point demande réflexion. Notez aussi qu'il y avait environ 41 000 communes recensées en 1793. Sauf exception (connaissance d'un chiffre de population entre 1789 et 1793, ça arrive), les 1000 à 3000 communes disparues entre 89 et 93 ne nous intéressent pas pour cette discussion. On a donc environ 5000 communes qui ont disparu à la suite de fusions, donc logiquement moins de 5000 articles qui concernent des communes fusionnées. Des 1316 communes fusionnées en 1968-1975, 300 ont défusionné, ce qui rajoute 300 cas particuliers. Si on considère les cas de fusion à 3, 4 communes et plus comme Castellane (fusion de 8 communes) ou de Paris (fusion de 12 communes), on peut considérer que environ 4000 articles sont concernés, à la louche.
Alors, c'est un bon modèle qui est en route.
c'est le dilemne éternel de l'internet, donc résolvable dans notre en présentant un bilan de nos discussions. Faire une proposition sur la PdD du projet rallonge d'une quinzaine ou d'un mois le processus, mais ceux qui n'ont pas envie de se plonger dans les discussions détaillées seront aussi consultés ainsi. Pour un consensus large. azoée (discuter) 6 février 2014 à 20:04 (CET)[répondre]
C'est actuellement le cas, toutes les pages qui sont archivées ne sont pas actualisées puisque c'est justement la source qui a été mis en liens qui intéressent la communauté. C'est pour cela que je proposai d'utiliser un espace de stockage ( archive2014, archive2015, ...) pour permettre de stocker des contenus qui sont différents d'année en année mais dont l'url ne bouge pas. --Pmartin (discuter) 29 mars 2014 à 13:29 (CET)[répondre]
Si je comprend bien le fonctionnement, à chaque fois qu’un lien externe est ajouté dans W, son contenu est archivé dans wikiwix. Si le contenu de la cible du lien change, l’archive n’est pas actualisée, même par l’ajout de nouveaux liens ailleurs dans W ? Comment alors signaler qu’il est souhaitable d’avoir un nouvel archivage ? azoée¿∞?1 avril 2014 à 22:36 (CEST)[répondre]
Tout à fait lorsqu'un lien est ajouté dans wikipedia, il est normalement archivé par wikiwix. Il arrive dès fois que nous ne soyons plus synchronisé pour plus de sureté un simple clique sur le lien archive enclenche la procédure d'archivage. Pour signaler un nouvel archivage, deux façons soit créer un espace dédié année par année que je proposai ci dessus, soit de modifier l'url en ajoutant par exemple une ancre html ex :"#XXXXX" à la fin cela permet de modifier une url pour un nouvel archivage de son contenu. --Pmartin (discuter) 7 avril 2014 à 12:08 (CEST)[répondre]
à améliorer
Bonjour,
Il y a certaines choses à améliorer :
pour une commune de moins de 10 000 habitants, faire figurer 2006 alors qu'elle a été recensée exhaustivement une autre année du cycle (2004, 2005, 2007 ou 2008) est une erreur. C'est mélanger les torchons et les serviettes.
Re:C'est la convention qui avait été retenue. 2006 étant la première année où des populations légales ont été publiées, il avait été retenu par convention de publier systématiquement l'année 2006, par convention. "On ne mélange pas des torchons et des serviettes" est probablement exagéré. Une population légale est une population officielle. J'ai déjà exprimé mon point de vue dans le passé, à savoir qu'on peut publier toutes les populations légales, et cela faciliterait les choses pour Wikidata. On a arrêté une convention qui dit qu'on ne publie que les années de recensements réels et l'année 2006. Si on veut supprimer l'année 2006 quand on a un recensement réel en 2004 ou 2005, pas de pb, ça pourra se faire lors de l'actualisation de 2015.Roland45 (discuter) 4 octobre 2014 à 15:23 (CEST)[répondre]
Il y a aussi pour ces communes ayant des chiffres de 2004 ou de 2005 : où ces chiffres sont disponibles ? sur Cassini la plupart du temps et non sur le site de l'INSEE comme l'indique le modèle.
Pour. Je note des pertes d'informations avec ce modèle sur des années intermédiaires sur des chiffres officiels INSEE pourtant et ce depuis 2006. L'INSEE fait un recensement partiel roulant et réactualise les chiffres tous les ans pour certaines communes. Ce modèle est-il toujours pertinent ? --AFAccord (discuter) 3 octobre 2014 à 19:15 (CEST)[répondre]
Je ne peux que plusseoir, ayant déjà effectué les remplacements en ce qui concerne ton 1) sur le 04 ; et aussi pour les recensements 2004 et 2005 pour les mêmes communes (mais seulement en me référant à ce qui est présent dans l'historique, car DasBot avait mis à jour ces données) ; et pour ton 3), :soupir:. azoée¿∞?4 octobre 2014 à 01:35 (CEST)[répondre]
Bonjour à tous. Merci du signalement. J'ai répondu ci-dessus dans le corps du texte. Pour l'année 2006, je pourrai la faire disparaitre lors de l'actualisation 2015 pour les années dont le recensement exhaustif n'est précisément pas 2006. Mais je pense que dans la perspective du passage à wikidata, il serait souhaitable en fait de saisir toutes les années à partir de 2006 avec pour chaque année un indicateur associé qualifiant la nature de la donnée (recensement réel ou intermédiaire). Ce serait dans le modèle d'affichage qu'on testerait la nature de cet indicateur et que l'on afficherait ou pas la donnée. Cela présenterait l'inconvénient de modifier le code des modèles d'affichage, mais l'avantage énorme que l'actualisation annuelle serait simplifiée et un bot pourrait je pense plus facilement être développé, car l'actualisation est actuellement faite via Excel (et VBA) de manière assez complexe et le système est donc très fragile puisque dépendant d'une seule personne (... voir Wikialine qui ne contribue plus depuis mi-2013).
Pour l'apostrophe courbe, les modèles sont protégés, il faudrait demander à un administrateur qu'il le fasse, c'est élémentaire, me semble-t-il. Cordialement.Roland45 (discuter) 4 octobre 2014 à 15:23 (CEST)[répondre]
Dans le tableau Évolution de la population, (Sources : Ldh/EHESS/Cassini jusqu'en 1999 puis Insee à partir de 2004.), pouvez-vous ajouter un point de conclusion à la référence attachée à 2004 ? Voir par exemple la référence 78 de l’article Chédigny, qui donne : « Fiches Insee - Populations légales de la commune pour les années 2006 [archive], 2007 [archive], 2011 [archive] », sans le « . » final.
Sur la commune de Saint-Georges-de-Reneins, la donnée de population 2012 est fausse (2843 contre 4381 en réalité).
Comment faire pour la corriger ? Merci !
Bonjour. Il y a un lien au dessus du tableau pour modifier dans une page annexe. J'ai rectifié moi même, le cas étant un peu plus complexe (il s'agit d'un nouveau maximum). Merci du signalement. Cordialement, ---- Ikmo-ned (discuter avec) 15 mars 2015 à 10:25 (CET)[répondre]
C'est quand même très inesthétique ce blanc à côté de l'infobox (voir par exemple : Grâces (Côtes-d'Armor)) alors que la largeur du tableau et du graphique démographique pourraient très bien faire qu'ils soient situés à gauche de l'infobox. Ne pourrait-on faire quelque chose ? Le paramètre {{Clr}} est en tout cas à éviter, éventuellement {{Clr|left}}. J'ai même trouvé un article (Le Juch) où la section Démographie est mis en bas de l'article pour ne pas avoir le problème avec l'infobox. — Berdea (discuter) 5 mars 2015 à 11:38 (CET)[répondre] La dernière discussion sur le sujet s'étant tenue en 2013, il me semble intéressant de la réactiver dans une nouvelle section. Ne pourrait-on résoudre le problème en mettant le tableau et le graphique à gauche au lieu de les centrer ? — Berdea (discuter) 15 mars 2015 à 11:29 (CET)[répondre]
Bonjour. Effectivement, cela a déjà développé dans cette page (ce qui faisait suite à une modification dans le modèle) sans avoir été résolu. Surtout que les problèmes d'affichage diffèrent selon les configurations (je n'avais d'ailleurs pas de problèmes d'affichage avant la modif de février 2013). Ceci dit, l'article Grâces (Côtes-d'Armor) cumule les facteurs repoussant le tableau : début d'article léger, image format portrait en infobox et, sous IE notamment, image de la mairie calée à droite sous l'infobox (hors paragraphe, du coup) précédant encore le tableau. Je ne suis pas sûr non plus que le calage à gauche du tableau contente tout le monde. Cordialement, ---- Ikmo-ned (discuter avec) 15 mars 2015 à 12:47 (CET)[répondre]
Bonjour. Au risque de me répéter, je persiste à penser qu'il est plus utile de compléter l'article que de trouver des parades pour cacher la misère. Je viens de passer 4 minutes et 42 secondes à améliorer cet article, il n'y a a plus de problème de mise en page ; et en plus j'en ai profité pour corriger des erreurs grossières (quant aux noms successifs de la commune), des manques (le nom du maire actuel n'était même pas dans la liste des maires), des oublis (quant aux monuments répertoriés à l’inventaire des monuments historiques) alors que toutes ces infos sont immédiatement disponibles grâce à la page d'aide.
Je précise que je ne connaissais rien de cette commune, même pas son existence avant d'avoir lu le message ci-dessus.
Je ne nie pas du tout le travail que tu as fait, mais on a réussi à contourner le problème, notamment en ajoutant des sections ou sous-sections qui sont actuellement vides et en ayant donc un sommaire qui prend plus de place. Je ne vais pas passer en revue toutes les communes où on a un problème avec l'infobox. Je prend par exemple Brandérion où on a le même problème. Alors bien sûr on peut prendre du temps pour compléter l'article, mais on peut également trouver une solution pour que les graphiques se glissent à gauche de l'infobox, avec pourquoi pas un paramètre optionnel, qui permettrait quand l'article n'est pas trop développé de glisser optionnellement le tableau et le graphique à gauche. Le fait est qu'actuellement les rédacteurs placent souvent la section démographie en bas de page pour contourner le problème et parce qu'ils ne peuvent faire autrement, alors que normalement la démographie devrait intervenir assez tôt dans l'article. — Berdea (discuter) 16 mars 2015 à 16:12 (CET)[répondre]
Pas de problème de mon côté si on trouve une solution de contournement pour déplacer les graphiques. Personnellement, quand je vois un article dans un triste état comme Brandérion, je ne peux pas m'empêcher de passer trois à quatre minutes pour l'améliorer un tout petit peu (ne serait-ce localiser la commune), et immanquablement, il n'y a plus de « collision ». Bien cordialement. AntonyB (discuter) 16 mars 2015 à 17:59 (CET)[répondre]
Dysfonctionnement du modèle
Bonjour,
Je voudrais signaler un dysfonctionnement du modèle au sein de la page de la commune de Londinières. Quelles corrections serait-il possible d'y apporter pour éviter cette absence d'affichage de l'histogramme de l'évolution démographique ?
Bonjour LllC et merci du signalement. Voilà, c'est corrigé (voir en cliquant ici). Maintenant pour l'explication de l'anomalie, pourquoi trois lignes mises à 0 le 3 janvier 2015 à 14:08 par Roland45-Bot puis retirées le 11 avril 2015 à 16:09 par WikiCleanerBot, je laisse à l'ami Roland45 le soin de l'explication. Bien cordialement. AntonyB (discuter) 19 mai 2015 à 13:53 (CEST)[répondre]
Bonjour. J'ai corrigé à nouveau. Il manquait 2012. Je ne me lancerai pas dans l'explication du bug du bot, qui reste somme toute un bug, donc une erreur. A +.Roland45 (discuter) 19 mai 2015 à 14:12 (CEST)[répondre]
Bonjour,
Et tous mes vœux pour cette nouvelle année. Je ne sais pas si je doit poster ici, mais je ne trouve pas la raison de l'erreur d'affichage sur Sévrier#Démographie. Si vous pouviez y jeter un coup d'oeil, merci. --AlpYnement vôtre,B-noa (d) 3 janvier 2016 à 10:51 (CET)[répondre]
Ajout d'un tableau montrant l'évolution du rang de la commune au sein de son département
Bonjour, Je viens de créer ce modèle {{Tableau rang commune de France}} qui permet d'insérer un tableau montrant l'évolution du rang d'une commune donnée, selon sa population municipale, par rapport à l'ensemble des communes du département. Il s'agit d'une extension des modèles {{Données Rang2009}} et {{D-Nbcom}}, dupliqués pour les années 1968, 1975, 1982, 1990, 1999, 2006 et 2013 (premiers et derniers chiffres disponibles auprès de l'Insee).
Vous pourrez voir un exemple sur la commune de Siradan.
Ne serait-il pas intéressant d'ajouter ce tableau à la fin de la section démographie ?
Terfilo : Nous sommes en train de réorganiser tous les modèles de données et de calcul en lien avec le domaine de la population et les transformer en modules. Finalement, ce tableau est assez intéressant et on va essayer d'ajouter quelques paramètres dans les modèles/modules de données pour le produire automatiquement et de manière plus efficace. Note quand même qu'il y a un pb : les sources données pour les années 1968 à 2006 sont des données harmonisées par rapport à une année de référence (le 1er janvier 2015 dans ce que tu donnes), à savoir que les données sont calées sur le découpage géographique au 1er janvier 2015). C'est-à-dire d'une part que l'année suivante, certaines données peuvent changer si la géométrie territoriale change et d'autre part que le nombre de communes de l'année 1968 n'est pas celui de 1968, mais celui du 1er janvier 2015 (donc certaines données des tableaux actuellement dans les article sont fausses (selon mon point de vue). Toutefois ceci n'est pas rédhibitoire. Il suffit en fait de l'expliquer dans l'article, et d'avoir un tableau clean, ce qui n'est pour l'instant pas le cas.Roland45 (discuter) 12 janvier 2017 à 16:23 (CET)[répondre]
Bonjour. Le modèle Introduction population d'article de commune de France comporte une coquille pour l'année de comparaison, écrite avec une espace (p. ex. 2 008 plutôt que 2008). D'après le texte source, cela est dû à la présence d'un formatnum qui ne devrait pas être là :
par rapport à {{formatnum:{{Données/{{#if:{{{nom|}}}|{{{nom|}}}|{{SUBPAGENAME}}}}/évolution population|an_5}} |NOSEP}}
Céphide : Tout-à-fait. Je m'en suis aperçu après avoir demandé à Starus :, administrateur, de modifier le code (n'étant pas administrateur je ne pouvais pas le faire car ce code est protégé). En première lecture on peut penser que c'est dû effectivement à ce formatnum, mais bizarrement en l'enlevant on a toujours cette anomalie. J'ai essayé en rajoutant |R à formatnum qui permet de faire l'invers à savoir d'enlever le format, mais rien n'y fait. Vous pouvez tester avec ce modèle test {{Introduction population d'article de commune de France/Test1}}. Sinon, il y a une autre faute de typo (manque un point à la fin de la ligne). C'est corrigé dans le modèle test. J'espère qu'on va trouver la solution.Roland45 (discuter) 30 décembre 2016 à 17:30 (CET)[répondre]
Les modèles d'affichage ont été changés. Ils nécessitent désormais un paramètre d'affichage complémentaire (recens) qui permet d'afficher ou non la donnée. Les modèles de données des COM n'ont pas encore été modifiés, d'où ces messages d'erreur. Pour l'instant je suis sur l'actualisation 2017 avec les données 2014 pour France et DOM. Je reviendrai plus tard sur ces modèles. Sinon, le principe est simple, il suffit d'ajouter |recensn=1 au bout de chaque ligne de données n du modèle (voir le modèle de n'importe quelle autre commune).Roland45-Bot (discuter) 3 janvier 2017 à 14:10 (CET)[répondre]
Trouvé dans Garéoult :
« En 2014, la commune comptait 5 403 habitants, en diminution de -3,9 % par rapport à 2009 (Var : 2,98 % , France hors Mayotte : 2,49 %) ».
En bonne logique il s'agit d'une « diminution de 3,9% » et non de « -3,9% », ou d'une « variation de -3,9% ».
--Jojo V (discuter) 9 janvier 2017 à 13:55 (CET)[répondre]
Bonjour, Dans l'article sur Redon, c'est écrit que depuis le début des années 2000, la population légale est annuellement mise à jour. Or, c'est depuis la fin des années 2000, la première à avoir été publiée est la population légale 2006 publiée fin 2008 en vigueur en 2009 et calculée notamment avec le recensement 2004. Petitbeur (discuter) 8 avril 2017 à 11:30 (CEST)[répondre]
Bonjour, L'article a été modifié mais je n'ai pas compris comment. C'est maintenant écrit milieu des années 2000. Comment met-on fin des années 2000 ? Puisque c'est depuis décembre 2008. Petitbeur (discuter) 10 mai 2017 à 14:26 (CEST)[répondre]
Bonjour. Les premières populations légales publiées selon le nouveau mode de recensement l'ont été officiellement en 2006. Mais certaines communes ont eu leur premier recensement publié en 2004 et 2005. Donc milieu des années 2000 est correct. Cordialement.Roland45 (discuter) 10 mai 2017 à 16:34 (CEST)[répondre]
Re-bonjour, je recopie la phrase du texte sur Redon : 'À partir du milieu des années 2000, les populations légales des communes sont publiées annuellement.' Or la première population légale publiée est celle de l'année 2006 mais n'a été publiée qu'en DÉCEMBRE 2008 pour rentrer en vigueur au 1-er janvier 2009 jusqu'au 31 décembre 2009. Soit la toute fin des années 2000. Les chiffres publiés avant décembre 2008 n'étaient pas des populations légales, certaines ont pu le devenir si le chiffre diffusé correspondait à un recensement de l'année 2006, 2007 ou 2008 mais il aura fallu attendre presque trois ans supplémentaires pour que cela soit 'légal'. On peut remplacer la mention par 'À partir de la fin des années 2000, les populations légales des communes sont publiées annuellement.' ou si on remanie la phrase par 'Depuis la population légale 2006 diffusée fin 2008, les populations légales des communes sont publiées annuellement.' mais 'À partir du milieu des années 2000, les populations légales des communes sont publiées annuellement.' reste faux même si la première population légale diffusée était une population légale correspondant à une année située dans le milieu des années 2000. Petitbeur (discuter) 10 mai 2017 à 17:06 (CEST)[répondre]
Petitbeur : Les premières populations légales des communes établies selon le nouveau mode de recensement sont effectivement entrées en vigueur au 1er janvier 2009 et correspondent aux populations légales millésimées 2006, établies sur les limites territoriales en vigueur au 1er janvier 2008 (voir ici). En toute logique, il convient donc d'écrire, pour être précis, "À partir du , les populations légales sont publiées annuellement". Je vais voir celà.Roland45 (discuter) 14 mai 2017 à 19:10 (CEST)[répondre]
Bonjour à vous deux. Il va falloir effectivement résoudre ces deux problèmes (division par zéro et orthographe). Probablement dans le nouveau module à venir. Pour l'instant je suis sur autre chose et ne peux pas trop m'y pencher dessus. Cordialement.Roland45 (discuter) 14 mai 2017 à 18:45 (CEST)[répondre]
J'ai récemment renommé la page « Bagard (Gard) » en « Bagard » suite à la suppression d'une page d'homonymie. Cela a créé une erreur d'affichage des données sur la population, à la fois dans l'infobox et dans la section « population ». Quelqu'un pourrait-il m'aider ?
