BonjourPère Igor en attenant les changements effectifs de nom au nouvel an prochain, je pense que ce ne serait pas une mauvaise chose que les nouveaux noms soient des redirects.SenseiAC (discuter)21 août 2024 à 16:45 (CEST)
Père Igor : Pas de problème, je m'en occupe tout de suite. Au passage, je constate qu'il n'y a aucune cohérence dans la façon dont les articlesChangement de nom de communes en France... sont organisés. Certains sont triés chronologiquement (l'article généralChangement de nom de communes en France ; les articles par siècle :XIXe siècle,XXe siècle etXXIe siècle ; l'articleavant 1840 ; et quelques articles par décennie :années 1840,années 1850 et le susmentionnéannées 2020), tandis que les autres sont triés anti-chronologiquement (tous les articles par décennie deannées 1860 àannées 2010). Il faudrait donc remettre tout ça dans le même ordre. L'ordre croissant me semble plus cohérent ici. Qu'en penses-tu ?SenseiAC (discuter)21 août 2024 à 18:05 (CEST)
En effet, bonne remarque de la part de @Père Igor.
Oui, faudrait tout basculer en mode chronologique qui est la norme actuelle sur le Wikipédia francophone, à la base tout était en antichronologique, mais vu que changer d'ordre ça prend un max de temps (et que ça doit être en un temps relativement court pour chaque article, pour pas laisser l'article ad vitam en plein chantier), j'avais du m'atteler qu'au basculement que pour les articles les plus courts, dans un premier temps.
Bonjour à tous et notamment @SenseiAC. La totalité des 1929 communes n'est pas concernée, car je me suis aperçu entre-temps du problème, mais je ne suis pas revenu sur les fautives. Il y en a donc effectivement un grand nombre. Le plus simple est tout simplement de supprimer cette phrase ou bout de phrase. Je vais faire passer mon bot pour corriger.Roland45 (discuter)22 août 2024 à 09:49 (CEST)
Dernier commentaire :il y a 1 an3 commentaires2 participants à la discussion
Bonjour, Je constate que l'intercommunalité de diverses communes n'est pas à jour dans leur infobox. Je viens de mettre à jour l'infobox (et, quand il y avait lieu, le RI) des communes deCollines Isère Nord Communauté (dont le nom a visiblement changé en 2022 -- l'article d'aucune des communes membres n'était à jour sur ce point), mais ce ne sont vraisemblablement pas des cas uniques. Ne pourrait-il pas y avoir (via bot ?) une vérification et mise à jour régulière (une fois par an ?), au minimum pour les infobox ?SenseiAC (discuter)20 août 2024 à 18:32 (CEST)
« Ne pourrait-il pas y avoir (via bot ?) une vérification et mise à jour régulière (une fois par an ?), au minimum pour les infobox ? » Ben oui. Ya ka faukon.
C’est d’ailleurs ce que je me dit depuis longtemps quand je vois les multiples données périmées des articles. La difficulté, c’est de disposer de bases de données des noms wiki de toutes les divisions, croisées avec la dernière version du découpage supracommunal (issues d'Admin Express). Et ça, ce n’est pas simple, car même avec les requêtes sur Wikidata (ici), on est très loin d’avoir résolu le problème.
Je m’y suis néanmoins attelé cette année en juillet (voirici). On peut y lire dans le commentaire de diff « Vérification du zonage et correction liens brisés (voir lapage projet) ».
En fait cette mention de diff est erronée en ce qui concerne la vérification du zonage, car une erreur de tri dans une des bases, notamment celle des EPCI, a conduit à un bug sournois qui faisait que certaines actualisations n’étaient pas prises en compte. L’ennui, c’est qu’il est impossible d’identifier quelles communes sont concernées. Un repassage général sera nécessaire.Roland45 (discuter)22 août 2024 à 09:55 (CEST)
Fait. La totalité des articles de communes de métropole a été balayée et les Infobox ont été corrigées si nécessaire. En réalité, il n'y avait quasiment pas d'erreurs sur le nom de l'interco en tant que tel, mais plus de 4000 corrections ont quand même été faites en ce qui concerne l'orthographe, en général des questions de majuscules (qui ne se voyaient pas car il y avait des redirections).Roland45 (discuter)31 août 2024 à 18:18 (CEST)
Dernier commentaire :il y a 1 an15 commentaires5 participants à la discussion
Bonjour, DansLe_Rousset#Démographie, on peut lire« en diminution de −1,19 % ». Cette formulation est incorrecte. Il faudrait dire que l'évolution / la variation / le changement est de −1,19 %, ou bien que la diminution est de 1,19 % (sans signe moins : « diminution » signifie déjà que l'évolution est négative). Étant donné que la fin de la phrase est simplement« (Saône-et-Loire : 0,19 %, France hors Mayotte : 2,49 %) » — bref, « territoire + nombre » sans mots de liaison entre —, mieux vaudrait employer une formulation qui puisse s'appliquer sans ambiguïté également à ces pourcentages (tous deux positifs), donc éviter le mot « diminution ». Je serais donc favorable à l'emploi de « en évolution de -1,19 % », avec l'avantage que « en évolution » convient aussi bien pour les pourcentages positifs que négatifs et évite donc d'avoir à distinguer les deux cas. Accessoirement, quitte à mettre ces phrases au propre, autant le faire jusqu'au bout en rappelant que la ponctuation a un sens : pour la parenthèse, il faudrait donc écrire soit directement « (Saône-et-Loire 0,19 %, France hors Mayotte 2,49 %) », sans les deux deux-points si on veut utiliser une virgule entre les deux « territoire + nombre » (option qui aurait ma préférence), soit « (Saône-et-Loire : 0,19 % ; France hors Mayotte : 2,49 %) », avec un point-virgule au milieu si on veut utiliser les deux-points. Dans tous les cas, vu le nombre de pages qui devront être traitées, il faudrait faire passer un bot pour corriger tout ça. Merci d'avance.SenseiAC (discuter)20 août 2024 à 19:07 (CEST)
@SenseiAC Oui. L’expression « Une diminution de -1.19 % » est fautive.
Pour la question des doubles points entre parenthèses, je serais moins affirmatif.
Roland45 : J'ai fait le changement dans{{Introduction population d'article de commune de France}} ([1]+[2]). Peux-tu contrôler ? Surtout la deuxième modif, parce que c'est une retouche après avoir vérifié ce que la première modif avait donné dansLe_Rousset#Démographie. Sur cet article, maintenant ça a l'air OK, mais je ne voudrais pas que ça ait cassé un truc ailleurs par inadvertance.
Pour ma part, j'aurais préféré que les motsaugmentation oudiminution soient conservés et que l'on ait ensuite une valeur absolue du résultat, mais bon, soit. Pour le module, il faut a priori intervenir entre les lignes 252 et 290 deModule:Population de France/Introductions. Mais je ne suis pas un expert en lua. Peut-être qu'@Hexasoft ou @Od1n ou @Zolo a son idée sur la question ?Roland45 (discuter)22 août 2024 à 19:24 (CEST)
Je me suis un peu penché sur le modèle, ça m'aura d'ailleurs permis d'améliorer son code (cf.217909938,217910334,217910636). Mais je ne suis pas certain de la formulation à utiliser… (cf.217909347,217911050,217911221)
Pour l'instant je suis resté sur la même formulation que SenseiAC :
en évolution de −1,19 % par rapport à 2009 (Saône-et-Loire : 0,19 %, France hors Mayotte : 2,49 %)
J'avais essayé ceci, mais en fait ça ne me plait pas du tout ("mélange" d'écritures) (à propos, je viens de remarquer que c'est précisément comme ça qu'affiche le module Lua actuellement) :
en diminution de 1,19 % par rapport à 2009 (Saône-et-Loire : +0,19 %, France hors Mayotte : +2,49 %)
J'ai le sentiment que le mieux serait de tout mettre en écriture « +/− » :
en évolution de +1,19 % par rapport à 2009 (Saône-et-Loire : +0,19 %, France hors Mayotte : +2,49 %)
Problème, ça alourdirait le modèle juste pour ajouter ces « + ».
Roland45 etSenseiAC : Il y a évidemment ce sous-entendu dans mon message : merci de vous mettre d'accord sur la formulation à utiliser et de me l'indiquer. Actuellement le modèle et le module ont des formulations différentes, ce qui me gêne pas mal. Vous pouvez me notifier après, ou bien en observant les modifs que j'ai déjà faites, on peut facilement trouver comment il faut modifier le code.od†n ↗blah23 août 2024 à 11:56 (CEST)
Od1n : Merci pour ton intervention. Pour ma part, je me range à la phrase comportant le motévolution mais avec un + à toutes les variations positives, ainsi que le maintien des deux points avec un point-virgule séparant les deux expressions. Mais peut-être qu'il conviendrait que d'autres contributeurs s'expriment car cela concerne la totalité des communes.Roland45 (discuter)24 août 2024 à 10:45 (CEST)
J'ai appliqué cette écriture dans le module (217967473) et dans le modèle (217967471). J'ai aussi implémenté un sous-modèle (217968305), parce que le code ce n'était plus possible… (petit regret : pour chaque pourcentage, les données "pop" sont "pop_5" sont encore récupérées deux fois chacune, ce qui n'est pas optimal ; mais il s'agit d'un modèle utilisé une seule fois par page, donc ce n'est pas très grave)
Pas d'avis concernant l'histoire de point-virgule : le point-virgule serait peut-être davantage correct, mais je trouve que c'est plus fluide à lire avec la virgule. Bon, ça reste vraiment un détail, je vous passe la main, pour modifier cela c'est très facile.
Après avoir remarqué deserreurs Lua, je viens d'appliquer cecorrectif rapide. Le problème se situe dans l'infobox, pas dans la section « Démographie » de l'article.
Avant les changement récents, ça affichait simplement l'icône "en stagnation".
Après ces changements, on se retrouvait avec une erreur Lua.
Et avec le correctif que je viens d'appliquer, on a un message« Erreur : données pour cette requête non trouvées »).
Là fatigué et pas l'énergie de chercher davantage… (edit : j'ai trouvé la cause, c'est parce qu'il y a une division par zéro ; reste à corriger cela ; et du coup le modèle aussi est peut-être concerné)
Pour l'histoire des divisions par zéro, je viens d'appliquer des correctifs,dans le modèle etdans le module. Ça complique les codes, mais bon pas le choix, ce sont des cas de figure qu'il faut gérer. Le problème existait déjà auparavant, mais avait été inaperçu : il n'y a peut-être pas d'utilisations du modèle avec des communes problématiques, et le module fonctionnaitpar chance dans le cas "0 → 0". Concernant le« +999 % » (cas "0 → N"), cette valeur n'est bien entendu pas vraiment correcte, mais c'est simplement faute de mieux.od†n ↗blah25 août 2024 à 13:09 (CEST)
Od1n : Pour les hypothétiques rares cas "0 → N", le mieux ne serait-il pas de ne mentionner aucun pourcentage, ou d'afficher une phrasead hoc (mais je ne vois pas trop quoi) ? D'ailleurs, je pinaille un peu, mais pour que les phrases des cas "N → N" (strictement le même N) sonnent elles aussi moins "robotiques", ne pourrions-nous pas écrire qqch comme "sans évolution" plutôt que "en évolution de (+/-?)0,00 %" ?SenseiAC (discuter)26 août 2024 à 20:18 (CEST)
La mise en œuvre de phrases différentes compliquerait fortement le code. Pour ma part, le« en évolution de 0 % » ne me choque pas. Concernant le cas de figure "0 → N", il doit être rarissime, et je pense qu'il est préférable de ne pas complexifier le code juste pour cette situation. Cela m'a déjà bien embêté de compliquer significativement le code à cause de l'histoire des divisions par zéro, mais c'est vraiment parce qu'il n'était pas concevable de laisser des erreurs d'exécution…od†n ↗blah27 août 2024 à 00:30 (CEST)
Dernier commentaire :il y a 1 an5 commentaires2 participants à la discussion
Bonjour, À Coulonges (Charente-Maritime) en 2018, il paraît que 100,1 % (sic) du territoire était agricole : voirCoulonges_(Charente-Maritime)#Occupation_des_sols. Je me demande bien comment une telle absurdité a pu finir dans un article (le fait que ces sections aient été remplies de façon automatique par bot n'est pas une excuse). Cet article n'est vraisemblablement pas un cas unique, donc une fois de plus il faudrait faire passer un bot pour corriger ces erreurs. Je suis d'ailleurs prêt à parier que ces erreurs — selon toute vraisemblance, des erreurs d'arrondi (par défaut ou par excès) issues d'un calcul ou d'un autre — existent aussi pour des valeurs autres que 100 %, donc il faudrait contrôler tous les articles de communes de France.SenseiAC (discuter)21 août 2024 à 16:32 (CEST)
« Comment une telle absurdité a pu finir dans un article ? » Oui, on peut bien se le demander ! Celui qui a écrit ça doit vraiment être débile. Il doit avoir un bug dans sa tête. N’importe qui sait qu’il ne peut pas y avoir plus de 100 centièmes dans un tout. Comme n’importe qui peut comprendre qu’il s’agit effectivement d’une question d’arrondis, ou plutôt d'arrondis de sommes d’arrondis. « Je suis d'ailleurs prêt à parier que ces erreurs existent aussi pour des valeurs autres que 100 % ». Bravo, gagné ! C’est sûr, le cas de Coulonges est particulier puisque la totalité des terres est agricole, dans tous les autres cas on peut avoir des chiffres différents de 100 avec potentiellement une erreur de décimale.
Pour info (et éventuelle vérification), les données sont surcette page. Le fichier présentant la répartition en 15 postes des superficies des communes de la métropole comporte 286 053 lignes et 18 colonnes, avec des chiffres avec 9 décimales. Pour faciliter le traitement et avoir un visuel j’ai traité en amont les pourcentages. Mal m’en a pris. Le principe de traitement n’est en soi pas faux, mais c’et une question de précision (de décimales). En additionnant des pourcentages avec une décimale, j’aurais dû afficher le résultat avec 0 décimale.
C’est d’ailleurs ce qu’il suffira de faire : arrondir le résultat à la décimale la plus proche dans la première phrase. Pour Colonges, cela donnera « marquée par l'importance des territoires agricoles (100 % en 2018), une proportion identique à celle de 1990 (100 %) ».
Bon, le principe est simple. La mise en œuvre est un peu plus problématique.
Si je ne savais pas à quoi occuper mon temps, voilà donc du boulot en perspective. Mais je ne m’y mettrai que lorsque j’aurai terminé ce sur quoi je travaille hors WP, à savoir la création d’un jeu vidéo (avec le moteurUnreal Engine 5, pour ceux qui connaissent).Roland45 (discuter)22 août 2024 à 10:05 (CEST)
Roland45 : Je n'ai insulté personne de« débile » qui« a[urait] un bug dans sa tête » ; évite d'en faire trop... Désolé si mon ton était certes un peu agacé, mais je me permets juste de trouver étrange qu'on ne trouve, et par suite ne corrige, ce genre de problème que des années après la mise en place de ces paragraphes (2021 pour le moins pour cet article), d'autant que ça concerne potentiellement des dizaines de milliers d'articles. D'ailleurs, contrairement à ce que je pensais, ces ajouts n'ont pas été faits par bot puisque la modif a été faite en ton nom propre : tu as ajouté 36 000 paragraphes à la main ??? ou il y a en fait un script derrière, bref un travail de bot sans être tagué bot ?? Car, si l'ajout était vraiment à la main (ce qui me surprendrait, ou vraiment tu as eu un sacré courage...), ce« 100,1 % » était vraiment le cas qui aurait dû être repéré (sauf si en réalité ce qui était ajouté aux articles n'était pas le paragraphe avec les valeurs en tant que telles et que, par une technique qui m'est inconnue, les valeurs numériques n'apparaissaient qu'à l'enregistrement sans être vues au préalable par le contributeur, mais là on retomberait dans des ajouts « à l'aveugle » comparables à des ajouts par bot). Je profite de l'occasion pour essayer de comprenre le processus, puisqu'on peut imaginer que la même chose pourrait servir ailleurs.
Àma, la précision à 0,1 % près dans les articles est très bien. En tout cas, c'est cohérent avec la répartition détaillée donnée dans la phrase suivante, et je pense qu'il faudrait garder cette cohérence. Pourquoi ne calcules-tu pas directement le total avec les valeurs d'origine à 9 décimales (même si on peut discuter de la pertinence d'autant de décimales) puis en arrondissant seulement après (tant pour le total que pour les valeurs individuelles) ? C'est ce qui éviterait le plus le rique d'erreurs d'arrondi. En tout cas, je ne voudrais pas dire de bêtises, mais en principe on pourrait avoir jusqu'à [(n+1)/2*arrondi] d'erreur cumulée, donc potentiellement 0,8 % d'erreur cumulée en additionnant 15 valeurs arrondies à 0,1 % près. Il faudrait donc partir de valeurs individuelles arrondies au maximum à 0,001 % près (erreur max cumulée = 0,008 %) pour être sûrs que le résultat final à 0,1 % près n'a pas de problème (une décimale de moins et l'erreur max cumulée de 0,08 % pourrait s'arrondir à 0,1 %).SenseiAC (discuter)22 août 2024 à 17:31 (CEST)
Les ajouts en question ont bel et bien été faits par mon bot. Mais il est arrivé que, contribuant sur d'autres sujets en même temps que le bot, pour éviter d'arrêter le bot, le déconnecter, puis me reconnecter sous mon identifiant, puis actions inverses pour revenir à l'action du bot, je connecte le bot sous mon identifiant. Maintenant le pb est réglé puisque je travaille avec deux ordis et deux écrans.
J'aurais bien entendu pu travailler avec les données d'origine, mais le fichier aurait été relativement gros. Pour la première phrase du texte, si on veut rester avec une décimale (par homogénéité avec le reste du texte), il suffit de partir du fichier en 5 postes (et non 15) et on a directement le bon résultat, avec très peu de calculs.Roland45 (discuter)22 août 2024 à 19:12 (CEST)
en attenant les changements effectifs de nom au nouvel an prochain, je pense que ce ne serait pas une mauvaise chose que les nouveaux noms soient des redirects.SenseiAC (discuter)21 août 2024 à 16:45 (CEST)
SenseiAC : bonjour. Oui, tu as raison. Tu peux t'en charger ?Père Igor (discuter)21 août 2024 à 17:37 (CEST)
Fait. La totalité des articles de communes de métropole a été balayée et les Infobox ont été corrigées si nécessaire. En réalité, il n'y avait quasiment pas d'erreurs sur le nom de l'interco en tant que tel, mais plus de 4000 corrections ont quand même été faites en ce qui concerne l'orthographe, en général des questions de majuscules (qui ne se voyaient pas car il y avait des redirections).Roland45 (discuter)31 août 2024 à 18:18 (CEST)