Projet:Modèle/Demandes/2021

❌ demande info box pour entreprise modifier

Travail demandé par Sophiewrites (discuter) 11 janvier 2021 à 14:32 (CET)Sophiewrites

  • Avancement :
    0 %
  • Détails de la demande : ...
  • Article(s) pour le modèle : ...; ...; ...
  • Discussions :

Bonjour, j'aimerais obtenir la création d'une Infobox pour l'entreprise dont je dois rédiger une page Wikipédia. il s'agit d'une application de convoiturage française. Je n'ai jamais utilisé Wikipédia de ce fait je ne maitrise pas bien son vocabulaire et son fonctionnement. La page wikipedia a pour but de donner de la crédibilité a l'entreprise.

J'aimerais un modele d'info box avec les champs suivants :

-Création

-Fondateur

-Forme juridique

-Siege social

-Activité

-SIREN

-Site Web

Merci

Bonjour   Sophiewrites. Il n'y a, à priori, pas d'infobox à créer. Rédigez d'abord le corps de l'article. Ensuite seulement, une infobox pourra être ajoutée. Le modèle {{Infobox Société}} semble approprié. Il convient d'attirer votre attention sur Wikipédia:Contributions rémunérées, obligation à laquelle vous devriez vous conformer, pour la transparence, étant donné la nature de votre message de demande. Lire aussi Aide:Admissibilité d'un article. Cordialement. — Ideawipik (discuter) 11 janvier 2021 à 14:50 (CET)

Merci pour la réponse, si je comprends bien je dois rédiger le corps de l'article dans une premier temps et copier puis remplir les champs connus et à la publication de l'article il apparaitra ? — Le message qui précède, non signé, a été déposé par Sophiewrites (discuter), le 12 janvier 2021 à 15:55

Bonjour   Sophiewrites. Une réponse détaillée à été apportée sur votre page de discussion Utilisateur.
Note, limite hors-sujet, à destination d'un modéliste pouvant modifier {{Infobox Société}}, protégé, (peut-être FDo64 ?) :
  • pour la moindre surprise, il serait préférable de passer le paramètre « Partenaires » tout en minuscule (en gardant l'autre en alias) ;
  • voir s'il convient d'ajouter des paramètres pour « président » et « directeurs », données qui sont uniquement importées depuis WD ;
  • simplifier l'inutile redondance dans {{{direction actuelle|{{{direction actuelle|}}} }}} ;
  • voir aussi Discussion modèle:Infobox Société#Documentation pas à jour et paramètres redondants.
Merci. — Ideawipik (discuter) 12 janvier 2021 à 19:16 (CET)
  Pas fait. Demande initiale inappropriée.
  Fait. Le reste des remarques a été pris en compte dans le modèle. Merci FDo64 ! — Ideawipik (discuter) 22 février 2021 à 11:05 (CET)

✔️ Demande de langues supplémentaires pour le Modèle:Langue modifier

Travail demandé par TED 22 février 2021 à 04:28 (CET)

✔️ Soi-disant mauvais emploi du mot magique {{formatnum:}}, mais où ? modifier

Travail demandé par Ariel (discuter) 11 novembre 2020 à 16:59 (CET)

Bonjour Ariel Provost  , les mauvais usages de formatnum sont souvent cachés et non présents directement dans la page incriminée. Ce sont souvent les infobox ou les modèles appelés dans l'article qui posent problème. Lors de l'entrée d'une valeur dans un champ défini dans un modèle ou une infobox, afin d'améliorer la lisibilité du code de l'aticle, il y a souvent une espace entre le nom du champ et le égal, ainsi qu'entre le égal et la valeur entrée (typiquement | profondeur = 25). Or, si le modèle ou l'infobox fait ensuite appel à {{formatnum:}}, cette espace est considéré comme impropre et une erreur est renvoyée, la page se retrouvant dans la catégorie « Page avec des arguments non numériques dans formatnum ». Pour l'article A Pobra do Brollón par exemple, le problème venait de cette palette, et plus particulièrement du champ reste : dans le modèle, il y avait : {{formatnum: {{{reste|}}} }}, or la variable reste était égale à 147 avec une espace devant (| reste = 147, l'espace entre le égal et le nombre est prise en compte) !! Et c'est cette espace qui fait entrer l'article A Pobra do Brollón dans la catégorie « Page avec des arguments non numériques dans formatnum ». Un trim a permis de résoudre le problème. Pour l'article Air, c'est Modèle:Infobox Chimie/Capacité thermique et Modèle:Infobox Chimie/Masse volumique qui posent problème, il faudrait ajouter un trim à chaque formatnum. --Noritop      11 novembre 2020 à 18:47 (CET)

C’est faux, ça ne vient pas des espaces entre = et la valeur (qui sont ignorées), exemple ici où la catégorie n’apparaît pas.
Pour Air, ça vient du modèle {{tmp}} comme expliqué ici par Ideawipik. — Thibaut (discuter) 11 novembre 2020 à 19:00 (CET)
Merci Noritop et Thibaut120094  . Cette explication m'a étonné parce que je pensais que les paramètres (nommés ou nom) d'un modèle étaient, à la transmission ou à la réception, débarrassés des espaces devant et derrière. Mais à la réflexion je dois me tromper, car j'ai effectivement repéré quelques modèles (dont {{Incise}}, je crois) dans lesquels ces espaces sont prises en compte. — Ariel (discuter) 11 novembre 2020 à 19:13 (CET)
Bonjour. Dans les modèles, pour les paramètres nommés, les espaces ou sauts de lignes sont retirés automatiquement. Ce n'est pas le cas pour les paramètres non nommés ({{{1}}}, etc.) ce qui peut expliquer la présence indésirable de deux espaces lors d'insertions du modèle {{incise}} par exemple. L'explication dans « Palette Succession/Étape de Compostelle » était la présence d'une parenthèse mal placée, dans le formatnum. Plus généralement, comme déjà dit dans la discussion mentionnée par Thibaut, il me semble préférable d'attendre que les modifications récentes ou à venir prochainement dans le logiciel, modifications liées à des signalements concernant cette catégorisation, soient appliquées et fassent leur effet. Pas d'urgence ! — Ideawipik (discuter) 11 novembre 2020 à 20:32 (CET)
Effectivement, bien vu à vous deux ! Noritop      11 novembre 2020 à 20:52 (CET)
Niveau stabilité, un nombre sous son écriture scientifique sera bientôt valide (exemple : 1.0E-6), mais je ne pense pas qu'il y aura d'autres changements après cela. La voie me semble tracée. Lofhi (discuter) 11 novembre 2020 à 21:43 (CET)
  Noritop : Bonsoir, aide utile : Aide:Créer un modèle#Nom de paramètre explicite : les paramètres nommés dans laquelle il est indiqué : « Note : Les espaces, retours chariots, sauts de ligne, tabulations, … au début et à la fin des paramètres nommés sont automatiquement enlevés. ». --FDo64 (discuter) 11 novembre 2020 à 23:11 (CET)
Merci   à tous. À défaut de faire avancer le schmilblick, j'aurais appris des choses (même s'il me reste une large marge de progression). — Ariel (discuter) 12 novembre 2020 à 06:58 (CET)

┌─────────────────────────────────────────────────┘
Bonjour Ariel Provost  . Je ferme cette demande, il y a un chantier en cours sur ce sujet et tout le monde peut y participer. --FDo64 (discuter) 26 avril 2021 à 08:55 (CEST)

✔️ Création des Modèles:Géolocalisation des États du Brésil modifier

Travail demandé par Arturo63 (discuter) 22 janvier 2021 à 14:20 (CET)

Cordialement.

  • Article(s) pour le modèle : Brésil, etc...
  • Discussions :
Bonsoir Arturo63  . Je te conseille de contacter le Projet:Cartographie qui est plus apte à écrire ce genre de modèle. --FDo64 (discuter) 22 janvier 2021 à 21:54 (CET)
Bonjour FDo64 (d · c · b), le Projet:Cartographie est inactif... J’ai besoin d’aide pour terminer le Modèle:Géolocalisation/Cincinnati, il manque les coordonnées géographiques. Merci d'avance. Arturo63 (discuter) 30 janvier 2021 à 14:37 (CET)
Bonsoir Arturo63  . Si j'interprète correctement les statistiques de consultation de la page, il y a une dizaine de « suiveurs de la page ayant consulté les modifications récentes de la page ». Il n'est donc pas inactif, par contre il est peu réactif et quand il répond à une demande, c'est souvent plusieurs semaines après. Celle que j'ai postée en août 2019 attend toujours. C'est malheureusement le meilleur endroit pour faire ce genre de demande et je n'ai pas de meilleur conseil que j'ai à te donner. --FDo64 (discuter) 30 janvier 2021 à 21:05 (CET)

✔️ Biographie personnalisée modifier

Travail demandé par Elea Kayne

  • Avancement :
    0 %
  • Détails de la demande : Je voudrais d'autres descriptifs dans la partie biographie déjà existante en plus des données habituelles.

J'aimerais que vous m'aidiez à créer un modèle avec les caractéristiques suivantes et une insertion de PHOTO : NOM - PSEUDO - DATE ET LIEU DE NAISSANCE - NATIONALITÉ - PROFESSIONS - AUTRES ACTIVITÉS - DEBUT DE LA CARRIÈRE - TAILLE - SITE WEB - TRAVAIL NOTABLE Je vous en remercie par avance

  Elea Kayne :   Fait. {{Infobox Biographie2}} a été mise à l'article. --FDo64 (discuter) 26 avril 2021 à 08:52 (CEST)

✔️ Infobox Isotope modifier

Travail demandé par Ariel (discuter) 8 avril 2021 à 17:07 (CEST)

  • Avancement :
    100 %
  • Détails de la demande : En bas de l'infobox Isotope il y a deux tableaux (exemple : Carbone 14) ; le premier (ligne de titres : Isotope parent – Désintégration) concerne les isotopes radiogéniques et le second (ligne de titres : Désintégration – Produit – Énergie (MeV)) les isotopes radioactifs. Le problème est que beaucoup d'isotopes ne sont pas comme le carbone 14 à la fois l'un et l'autre (c'est d'ailleurs une erreur pour le carbone 14 car il n'est pas radiogénique mais cosmogénique, je corrigerai plus tard). De nombreux isotopes ne sont que radiogéniques (exemple : le strontium 87, mais qui n'a pas encore son propre article), de nombreux autres ne sont que radioactifs (exemple : l'aluminium 26), et de nombreux autres encore ne sont ni l'un, ni l'autre (exemple : oxygène 18). Il faudrait donc que chacun des deux tableaux n'apparaisse que quand il est pertinent : le premier quand le paramètre parent1 est renseigné, le second quand le paramètre desintegration_mode1 l'est. Je pense que c'est facile à coder. Merci d'avance.
  • Article(s) pour le modèle : Tous les articles consacrés à un isotope, cf. Catégorie:Isotope et ses sous-catégories.
  • Discussions :

  Fait. Ajout de deux tests qui acceptent techniquement encore la possibilité d'avoir :

  • desintegration_parent1 sans parent1 ;
  • produit_desintegration1 ou desintegration_energie1, sans desintegration_mode1.

Si c'est inutile (les derniers étant obligatoires dans ces tableaux), on pourrait simplifier les tests dans le code. @Ariel. À toi de voir ce qui est le mieux.
En revanche, il n'est plus possible de spécifier un « paramètre2 » (ou 3 ou 4) sans « paramètre1 ». Je viens de vérifier que l'on n'a pas d'appel du modèle de la sorte. Donc pas de problème.
Ideawipik (discuter) 18 avril 2021 à 12:04 (CEST)

Super ! Comme je n'avais pas d'exemple d'isotope seulement radiogénique (1er tableau), j'ai créé l'infobox de Plomb 208 : ça marche aussi.
Pour simplifier le code je pense qu'on peut sans crainte se contenter du test sur le premier paramètre de chaque tableau (parent1 et desintegration_mode1). En tout cas le test sur desintegration_energie1 est vraiment inutile car on n'aura jamais l'énergie d'une désintégration sans savoir de quoi il s'agit, mais même les deux autres ne sont pas vraiment utiles (on aura toujours l'indication du parent avec le mode de désintégration (1er tableau), et toujours le produit de désintégration avec le mode de désintégration (2e tableau). Vraiment merci. — Ariel (discuter) 19 avril 2021 à 07:55 (CEST)
P.S. (1) Maintenant que je sais que ça marche, je vais corriger l'infobox de Carbone 14 (qui n'est pas radiogénique mais cosmogénique, ce qui n'entre pas dans ces tableaux). Il y a sûrement d'autres isotopes qui sont (réellement) à la fois radiogéniques et radioactifs (par exemple tous les intermédiaires des chaînes radioactives), mais j'ai la flemme de chercher.
(2) On pourrait inventer un 3e tableau pour les isotopes cosmogéniques (avec la cible et la réaction nucléaire correspondante), mais on verra (peut-être) plus tard (à chaque fois que je tente de résoudre un problème j'en débusque deux autres, mais les journées continuent à n'avoir que vingt-quatre heures).
Bonjour Ideawipik  . Je suis allé voir le code du modèle et ta modif. Je pense avoir compris l'un et l'autre, ou du moins je me sens capable de modifier le modèle (et de l'amplifier par un 3e tableau facultatif). Pour l'amplification (plus le remplacement d'un paramètre et l'ajout d'un autre), je vais d'abord passer par la PdD du projet Chimie (ici). Juste une question, concernant les tests non indispensables évoqués plus haut : si je les enlève, l'allégement du code sera-t-il significatif ? Si oui je m'en occuperai. Amitiés. — Ariel (discuter) 21 avril 2021 à 10:53 (CEST)
Bonjour Ariel. Conserver ou retirer un {{{desintegration_parent1|}}} dans le test ? Pour le rendu HTML cela ne change strictement rien, dans les cas normaux.
  1. Si on le garde, à l'exécution on a une "expansion" de paramètre supplémentaire mais qui ne doit pas être très coûteuse, l'utilisation d'un paramètre étant un élément de base des modèles.
  2. Si on l'enlève, on risque de voir se propager (par reproduction copier/coller) dans le code des articles la présence d'un paramètre non vide inutilisé. Ce dernier a plus de chance d'être corrigé ou retiré s'il est affiché explicitement dans l'article.
Autres possibilités :
  • alternative A, qui peut se révéler avantageuse sur ces deux points, serait de modifier très légèrement la structure :
    Si "parent1" alors
        "affichage du tableau"
    sinon
        si "desintegration_parent1" alors
            "affichage d'un message d'erreur dans l'infobox" et/ou "alimentation d'une catégorie de maintenance qui devrait être vide*"
    
    (* Catégorie de maintenance des modèles devant être vide). Revers de la médaille : dans les articles qui n'ont pas "parent1", on ajoute deux test "if" au lieu d'un seul. Or un tel test est plus coûteux qu'une utilisation de paramètre. Donc le bénéfice global s'aligne sur la proportion dans l'encyclopédie de sollicitations du modèle avec un paramètre "parent1" non vide et comme ce taux est d'environ 25 % à ce jour …
  • alternative B, on adopte la solution 2 et demande à un outil automatisé de rendre compte des utilisations incorrectes. Un bot peut scanner, une fois par mois (ou semaine), les infobox de ce type et rapporter les cas ambigus. Inconvénients : il faut déterminer à quel endroit ce rapport sera placé et s'il y a des cas, cela nécessitera des éditions de page par le robot.
Ou alors on relit WP:Ne vous préoccupez pas de performance et on adopte ce que l'on préfère parmi les quatre options décrites ci-dessus. La première, qui correspond à ce qui a été mis en place, n'est pas aberrante.
Voilà pour l'aspect technique. Quant à la suite et à l'évolution éditoriale proposée au projet Chimie, il est préférable d'en discuter sur la page de discussion du modèle. Cordialement. — Ideawipik (discuter) 24 avril 2021 à 20:12 (CEST)
Merci Ideawipik   pour ces explications, très claires. J'en conclus que le rapport bénéfice/coût est en faveur, pour chaque tableau, du test sur le renseignement d'au moins un paramètre de la 1re ligne (= expansion de tous dans un seul #if:), comme tu as fait. Quant à l'emplacement de la discussion, tu as bien sûr raison (pour la pérennité de ladite discussion) = j'ai interverti. Amitiés. — Ariel (discuter) 25 avril 2021 à 06:16 (CEST)
Bonjour Ariel. En réalité, je voulais juste dire la suite, ailleurs que sur la présente demande qui va être archivée. L'inversion n'était pas forcément attendue, mais c'est sans doute un peu mieux ainsi. — Ideawipik (discuter) 26 avril 2021 à 23:17 (CEST)

✔️ Autres projets : paramètre wikt4 modifier

Travail demandé par Ariel (discuter) 26 avril 2021 à 20:37 (CEST)

  • Avancement :   Fait.
  • Détails de la demande : Bonjour. J'ai modifié le modèle « Autres projets » en lui ajoutant une 4e entrée pour le wiktionnaire, en ayant besoin pour l'article « Camelus ». Ça semble marcher, mais quand j'ai voulu modifier aussi la doc du modèle j'ai reçu le message « Propriété « paramOrder[50] » obligatoire non trouvée. ». Dans un cas comme dans l'autre je me suis contenté de doublonner le bloc concernant la 3e entrée puis de remplacer "3" par "4" partout dans le doublon.
  • Article(s) pour le modèle : Camelus, notamment.
  • Discussions :

  Ariel Provost :   Fait. Dans le TemplateData, il faut bien renseigner "params" mais aussi "paramOrder" si ce dernier est présent. — Ideawipik (discuter) 26 avril 2021 à 23:17 (CEST)

Ah, OK, j'avais loupé l'un des blocs. Merci Ideawipik  . — Ariel (discuter) 27 avril 2021 à 08:28 (CEST)

✔️ Modèle:A modifier

Travail demandé par LD m'écrire 3 mars 2021 à 16:40 (CET)

  • Avancement :
    100 %
  • Détails de la demande :

Bonjour,

Conjointement à cette procédure d'intervention par un administrateur d'interface, il serait nécessaire de modifier {{A}} afin d'identifier la sous-page à afficher selon l’espace de nom. Par exemple, en dehors du main et dans l'espace de nom "Portail", il est nécessaire d'afficher {{TALKPAGENAME:{{{1}}}}}/Portail de qualité et {{TALKPAGENAME:{{{1}}}}}/Bon portail.

Pour le suivi, je notifie également :   Gemini1980

Bien à vous, --LD m'écrire 3 mars 2021 à 16:40 (CET)

  • Inclusions du modèle : 13719 inclusions en pdd dans divers espaces de nom.
  • Discussions :

Je viens de réaliser ceci. od†n ↗blah 17 mars 2021 à 09:23 (CET)

Bonjour Od1n  , merci d'avoir corrigé le modèle. Tout est en ordre. Bien à toi, LD m'écrire 19 mai 2021 à 02:53 (CEST)

❌ Correction du modèle « Bases » modifier

Travail demandé par 2A01:CB00:A05:D100:7CDF:1DC3:1308:A101 (discuter) 15 mai 2021 à 21:08 (CEST)

  • Avancement :
    0 %
  • Détails de la demande : Bonjour, les « Ressources relatives aux beaux-arts » générées par le modèle {{Bases}} donnent éventuellement un lien vers le Répertoire de sculpture française, mais ce lien ne fonctionne plus alors que le site existe toujours (https://frenchsculpture.org/). On peut le constater par exemple ici. Est-il possible de réparer ce lien ? Merci. Cordialement. 2A01:CB00:A05:D100:7CDF:1DC3:1308:A101 (discuter) 15 mai 2021 à 21:08 (CEST)
  • Article(s) pour le modèle : ...; ...; ...
  • Discussions :
Bonjour. Merci pour le signalement. Ce problème concerne davantage le projet:Bases et Wikidata. L'information leur a été relayée ici et . Cordialement. — Ideawipik (discuter) 26 juin 2021 à 12:09 (CEST)

✔️ Cassini EHESS - modèle préfixe d'URL modifier

Travail demandé par LD m'écrire 5 février 2021 à 15:30 (CET)

  • Avancement :
    100 %
  • Détails de la demande :

Bonjour,

Suite à un remplacement du lien de http://cassini.ehess.fr/cassini/ vers http://cassini.ehess.fr/ et à la requête formulée par @Roland45 (et plus largement le Projet:Communes de France) pour rétablir ces liens cassés, j'aimerai savoir s'il est judicieux d'intervenir en créant un modèle utilisant le nouveau préfixe de manière à opérer, si le lien rechange, avec une seule modification.

Dans les meilleurs des cas, il faudrait un modèle simple pour les contributeurs et une syntaxe simple. En regardant la recherche spéciale de lien, tous les liens ont le même format.

Donc a priori, j'imaginais un remplacement du type {{Cassini EHESS}}html/1_navigation.php# dans lequel {{Cassini EHESS}} = http://cassini.ehess.fr/fr/

Sinon, quelque chose dans cet esprit : {{Cassini EHESS|urlcomplet=http://cassini.ehess.fr/fr/html/1_navigation.php#}} qui puisse corriger http://cassini.ehess.fr/fr/ si cela revenait à changer.

Bref, je ne connais pas toutes les subtilités possibles, ni la meilleure manière de le faire.

Merci pour vos retours, --LD m'écrire 5 février 2021 à 15:30 (CET)

@Ideawipik vient de me notifier l'existence de {{Cassini-Ehess}}. La requête est caduque, modèle corrigé aujourd'hui. --LD m'écrire 5 février 2021 à 16:03 (CET)
Il faudrait néanmoins un modèle de liens exteres, type {{Gallica}}, je tente de le faire sous {{Cassini-Ehess 2}}. --LD m'écrire 5 février 2021 à 16:18 (CET)
Travail effectué conjointement avec de Ideawipik ; également, {{Cassini-Ehess/ancre}} a été créé. LD m'écrire 29 juin 2021 à 15:54 (CEST)

❌ Proposition de remplacement des émoticones modifier

Ps : Message déjà posté içi, sans réponse.

Discussions :

  • Bonjour Thomasbr33  , et merci pour cette proposition. Je suis   Plutôt pour ce changement, bien que je sois attaché à nos bons vieux émoticônes   ! Pourquoi ne pas laisser le choix ? En tous cas, c'est une bonne initiative. Cdt — Aymeric50800 7 août 2021 à 11:59 (CEST)
      Aymeric50800 : Haha, je comprends l'attachement aux anciennes émoticônes. Effectivement, on peut laisser le choix en ajoutant un paramètre dans le modèle, qui permettrai d'indiquer que l'on souhaite utiliser une émoticône à la place d'un émoji ... Je n'y avais pas pensé mais c'est faisable ! — Thomas (N'hésitez pas à me notifier) Chit chat ? 7 août 2021 à 12:03 (CEST)
  •   Contre un remplacement des modèles/icônes existantes /   indifférent quand à la création d'un nouveau jeu de modèles utilisant les emoji. Cela avait déjà été discuté à plusieurs reprises (et abandonné à chaque fois), entre autres sur Projet:Charte graphique/Logos/Archive 1#Émoticônes (mais aussi à divers autres endroits que je n'ai plus en tête). Le problème d'une modification est que certaines nuances (au-delà de leur affectation première) seraient modifiées ou perdues, et ce qu'on le veuille ou non. Et cela impactera toutes les anciennes discussions les utilisant. Il s'agit d'un point extrêmement délicat, car changer un smiley aboutit in fine à une modification des messages d'autrui, pouvant aller jusqu'à changer le sens d'un message. --Tractopelle-jaune (discuter) 7 août 2021 à 13:56 (CEST)
      Tractopelle-jaune : Je comprends ce que tu veux dire, mais je ne vois pas bien en quoi une simple mise à jour des icones peut radicalement changer une conversation. Les smileys sont rarement utilisés pour autre chose que de remercier quelqu'un, ou pour dire bonjour. De plus, je ne voit pas bien en quoi est-ce un problème que les anciennes conversations soient légèrement modifiées — Thomas (N'hésitez pas à me notifier) Chit chat ? 7 août 2021 à 14:53 (CEST)
  • J'aimerais rajouter un nouveau thème d'émoji que je vais créer avec Wikiou, la mascotte de Wikipédia Francophone.

Manjiro91Discuter 7 août 2021 à 13:03 (CEST)

✔️ Bandeau d'ébauche au féminin modifier

Travail demandé par Speculos 25 novembre 2021 à 17:32 (CET)

  • Avancement :
    100 %
  • Détails de la demande : Est-il possible d'afficher "une joueuse" quand un article a comme bandeau {{Ébauche|joueuse française de rugby à XV}} et non pas ".. une joueur..."

  Speculos :   Fait. Corrigé. --FDo64 (discuter) 25 novembre 2021 à 23:02 (CET)

✔️ Modèle Gaffiot modifier

Travail demandé par Ariel (discuter) 14 décembre 2021 à 08:37 (CET)

Bonsoir Ariel Provost  . Le modèle {{Documentation de source}} contient un paramètre contenu qui devrait répondre à ta demande. --FDo64 (discuter) 14 décembre 2021 à 23:34 (CET)

Bonsoir, j’ai plutôt créé une sous-page de documentation. LD (d) 14 décembre 2021 à 23:56 (CET)
Merci LD  . Je ne pense pas que le paramètre contenu du modèle {{Documentation de source}} aurait suffi pour bien documenter le paramètre. — Ariel (discuter) 18 décembre 2021 à 16:42 (CET)

✔️ Modèle hors sujet pour le forum de relecture modifier

Travail demandé par NeptuneJunior (discuter) 21 décembre 2021 à 23:26 (CET)

  Cette question est hors sujet par rapport à la mission de cette page d'entraide.

Je voulais savoir s'il était possible de faire le même pour le forum de relecture avec une phrase de ce type : « Cette demande est hors sujet par rapport à la mission du Forum de relecture. ». J'ai vérifié et je ne crois pas qu'il existe déjà. J'aurais pu le faire moi-même je pense mais j'avoue ne pas avoir la motivation pour me plonger dans les pages d'aide pour créer un modèle.

Merci et bonne journée ! — NeptuneJunior (discuter) 21 décembre 2021 à 23:26 (CET)

Bonjour NeptuneJunior.
Pour les discussions en wikicode (comme Wikipédia:Forum de relecture/wikicode ou Wikipédia:Questions techniques), il existe {{Réponse wikicode|HS}}.
En ce qui concerne les discussions structurées (flow), quand on regarde les modèles listés dans la page fournie ci-dessus, le seul appel qui mentionne une page précise (le forum des nouveaux) est {{Réponse flow|hors sujet}}. Je propose de modifier le texte « Cette question est hors sujet par rapport à la mission du Forum des nouveaux. » en « Cette question est hors sujet par rapport à la mission du présent forum. ». Ainsi le même modèle générique conviendra à plusieurs pages de réponses/aide aux nouveaux. Je pense qu'il est inutile de multiplier le nombre de modèles pour de tels détails mineurs. — Ideawipik (discuter) 22 décembre 2021 à 16:02 (CET)
Bonjour, oui, je n'avais pas pensé à cette solution mais ça serait parfait. Actuellement on utilise le modèle du forum des nouveaux sur le forum de relecture donc ce n'est pas l'idéal mais ce que tu proposes permettrait de régler ce petit soucis sans avoir à créer un nouveau modèle. - NeptuneJunior (discuter) 22 décembre 2021 à 17:03 (CET)
  NeptuneJunior. Proposition appliquée : « Cette question est hors sujet par rapport à la mission de cette page d'entraide. » Une formulation différente mais générique conviendrait autant. Sans réaction des acteurs du forum des nouveaux ou d'un autre modéliste, la requête pourra être classée. N'hésitez pas ! — Ideawipik (discuter) 22 décembre 2021 à 18:39 (CET)

❌ Problèmes d'affichage du modèle « Intervalle » modifier

Travail demandé par Ariel (discuter) 3 mai 2020 à 08:12 (CEST)

  • Avancement :
    0 %
  • Détails de la demande : Trois problèmes liés :
    (1) quand les deux dates sont av. J.-C. mais indiquées avec le signe "−", on se retrouve avec un affichage fort inélégant, p. ex. −664–−525 (infobox de l'article XXVIe dynastie égyptienne), car les dates négatives ne sont pas considérées comme « composées » (cf. la documentation du modèle) ;
    (2) quand seule la 2e date est « composée », on a des espaces indésirables, p. ex. 750 – 332 avant notre ère (infobox de l'article Basse époque).
    Je ne suis pas sûr du meilleur moyen de régler ces deux problèmes. La solution à laquelle j'ai pensé, afin de ne pas perturber les autres pages appelant le modèle, est d'ajouter un paramètre nommé facultatif permettant d'imposer les espaces insécables ou leur absence (en court-circuitant alors le choix fait par le modèle), paramètre qui serait facile à transmettre depuis les pages appelant le modèle, par exemple le modèle Infobox Ancienne entité territoriale (appelé par XXVIe dynastie égyptienne comme par Basse époque).
    (3) Par ailleurs il serait peut-être préférable d'afficher "à" plutôt que "–" quand il y a les espaces avant et après (notamment quand le tiret sépare deux dates négatives), soit systématiquement (je n'ai pas réfléchi aux inconvénients possibles, c'est peut-être imprudent), soit au vu d'un paramètre nommé facultatif (qu'on pourrait peut-être combiner en un seul avec celui évoqué ci-dessus, pour ne pas compliquer à l'excès l'appel et la documentation du modèle).
    Merci d'avance, et bon courage !
  • Article(s) pour le modèle : XXVIe dynastie égyptienne et articles similaires ; Basse époque et articles similaires
  • Discussions :
  Ariel Provost : Je constate que le modèle {{Intervalle}} n'est utilisé que par {{Infobox Ancienne entité territoriale}} et qu'il y a d'autres cas ou l'affichage est bancal. Par exemple dans l'article Commonwealth des Philippines il y a « 1935-1942–1945-1946 ». Je pense aussi que replacer le tiret par « à » est la meilleure solution.
  Recruos : Qu'en penses-tu ?
--FDo64 (discuter) 15 octobre 2020 à 21:57 (CEST)
Bonsoir Ariel Provost  . J'ai tenté de remplacer le tiret par « à » et ce n'est pas la bonne solution. Cela peut donner, par exemple « 30 décembre 1922 à 25 décembre 1991 ». Par ailleurs, je ne suis pas favorable à ajouter des paramètres comme tu le suggères quand on voit qu'il peut y avoir jusqu'à 4 périodes (voir par exemple Royaume de Géorgie occidentale). Donc même si ce n'est pas parfait, je suggère de laisser ainsi. À moins que quelqu'un d'autre n'ait une idée lumineuse ! --FDo64 (discuter) 15 mars 2021 à 22:38 (CET)

❌ Demande de modifications sur le modèle Résultats électoraux modifier

Travail demandé par Goultard59 (discuter) 22 juin 2021 à 14:17 (CEST)

Bonjour,

Dans le mode Scrutin uninominal à deux tours Je souhaiterais rajouter une option retrait pour les candidats se retirant aux seconds tours, ainsi qu'une autre option pour indiquer les candidats sortants. Je souhaiterais également retirer la dernière ligne 'Autres candidats' s'il ne reste plus de voix restante (si tous les bulletins exprimés ont était attribués à un candidat).

Merci pour votre travail.

Bonjour   Goultard59. Cela est-il indispensable ? Si la case est vide au second tour, cela veut dire que la liste n'était pas présente au second tour. La raison, que ce soit un retrait (plutôt rare) ou une élimination au premier tour (classique), peut être expliquée dans le texte ou en note. Il existe déjà les paramètres note1 et note2. Il parait un peu superflu d'ajouter autant de paramètres (un par candidat/liste) pour une utilisation très épisodique. Concrètement, dans quelle case aurais-tu voulu que cela apparaisse ? Pour l'accessibilité du tableau, évitons de fusionner ses cases.
En revanche, a été appliqué le retrait de la dernière ligne du tableau si le nombre d'exprimés est égal à la somme des voix des candidats listés. La seule différence avec le rendu antérieur est que les éventuelles erreurs de totaux sur les voix du second tour seront moins facilement repérables. Cordialement. — Ideawipik (discuter) 25 juin 2021 à 20:16 (CEST)

❌ Modèle Biographie modifier

Travail demandé par Jmax (discuter) 30 août 2021 à 07:37 (CEST)

  • Avancement :
    0 %
  • Détails de la demande :

A force de voir les modèle Autorité, Bases et Dictionnaires utilisés pour chaque biographie, je me demande s'il ne serait pas opportun de créer un modèle Biographie qui engloberait ces trois modèles. Dans les avantages de ce modèle unique, on peut citer qu'on ne peut pas oublier un des modèles (oubli souvent explicable par le fait qu'au moment où on pose le modèle, il n'y a pas de données ce qui peut évoluer), le respect d'un ordre assez logique qui va du plus peuplé au moins peuplé, une simplification d'usage (un item au lieu de trois).

Il semble que cela existe déjà avec le modèle Liens biographiques, même si l'ordre adopté du moins utilisé vers le plus utilisé est étrange. Jmax (discuter) 7 septembre 2021 à 09:04 (CEST)

modèle « Autres projets » : problème de mise en page pour les mobiles modifier

Travail demandé par Ariel (discuter) 13 novembre 2020 à 14:42 (CET)

  • Avancement :
    0 %
  • Détails de la demande : Je vous transmets cette diff, où une IP explique que le positionnement standard du modèle « Autres projets » (c.-à-d. juste après le titre de section « Voir aussi ») pose des problèmes d'affichage sur les mobiles. Pour ma part je n'en sais rien, je ne consulte quasiment jamais Wiki sur mon mobile.
  • Article(s) pour le modèle : quasiment tous
  • Discussions :

Effectivement, j'avais déjà remarqué que la boîte {{Autres projets}} a un mauvais rendu sur mobile. Le modèle utilise les classes .boite-a-droite et .boite-grise (et il y a par ailleurs .boite-sans-fond), qui sont définies dans le MediaWiki:Common.css mais pas dans le MediaWiki:Mobile.css.

En revanche il ne faut pas se contenter de recopier le CSS, pour la version mobile il faudrait que la boîte prenne toute la largeur de page. Il faudrait aussi vérifier le rendu des autres modèles qui utilisent ces classes.

Vu l'omniprésence de ce modèle, je pense qu'il serait assez important de traiter la chose. Avis aux intéressés ;-)

od†n ↗blah 14 novembre 2020 à 03:37 (CET)

Merci od†n  . À propos du même modèle, et si tu as un moment (?), pourrais-tu m'expliquer pourquoi on m'a refusé d'ajouter un paramètre nommé facultatif pour permettre de mettre la boîte à gauche, ce qui serait très utile quand l'infobox est plus haute que le texte (voire énormément plus haute, ça se produit dans un grand nombre d'articles scientifiques sur des composés chimiques ou des minéraux où il n'y a pas grand chose à dire à part la foultitude de données dans l'infobox) ? Je me rappelle qu'on m'avait dit que ça avait déjà été refusé antérieurement, mais sans me donner d'autre explication). Merci d'avance. — Ariel (discuter) 14 novembre 2020 à 07:32 (CET)
@Ariel Provost et @Od1n : il faudrait surtout que la version mobile donne accès aux autres projets en colonne de gauche, comme pour les liens interwikis. Cela permettrait de supprimer la boîte autres projets. TED 19 janvier 2021 à 05:14 (CET)

Conventions typographiques et modèle/module Langue modifier

Travail demandé par LD m'écrire 12 février 2021 à 21:20 (CET)

  • Article(s) pour le modèle : beaucoup trop  
  • Discussions :

Problème des titres de section de la page Wikipédia:Demande de suppression immédiate modifier

Travail demandé par Ariel (discuter) 2 novembre 2020 à 17:51 (CET)

  • Avancement :
    0 %
    Le modèle créé sous le nom {{noredirect'}} devrait répondre aux attentes. 24 mars 2021 à 11:30 (CET)
  • Détails de la demande : Ce n'est pas exactement un problème de modèle, mais c'est un problème de la compétence des modélistes : quand la page à supprimer est une redirection, quand on clique dessus on arrive sur la page de destination alors que la demande de suppression immédiate porte sur la page de redirection elle-même. Du coup, quand un administrateur voit plein de pages à supprimer et qu'il fait ça un peu vite, il risque de supprimer la page de destination au lieu de la page de redirection. Il faudrait qu'en cliquant sur le titre de la section on arrive sur la page à supprimer elle-même, que ce soit ou non une redirection. Il faudrait donc ajouter un &redirect=no quelque part dans le code des sous-pages, mais je ne sais pas bien où. Pouvez-vous y jeter un coup d'œil, si vous avez compris ma demande ? — Ariel (discuter) 2 novembre 2020 à 17:51 (CET)
  • Article(s) pour le modèle : (hors-sujet)
  • Discussions :
    Si j'ai bien compris il faudrait modifier le modèle {{a'}}, mais celui-ci est protégé et est surement utilisé par ailleurs. Il faudra peut-être faire un autre modèle dérivé. — eru [Discuter] 2 novembre 2020 à 18:45 (CET)
    Bonjour Ariel. C'est bien le modèle {{a'}} qui est utilisé. Pour les redirections, il existe déjà {{noredirect}} ou {{noredirect-}}. Mais, le premier fait appel à une fonction d'analyse coûteuse à éviter sur ce type de page où le modèle est répété ; le second n'est pas adapté ici, étant donné que le lien reste bleu que la page existe ou ait été supprimée. Il existe aussi {{A-redir-simple}} plus léger. Voici une autre proposition de modèle, par exemple, nommé « Modèle:A'redir » qui afficherait les deux liens et pourrait être utilisé, uniquement pour les redirections. Néanmoins, il faudrait revoir la page Wikipédia:Demande de suppression immédiate, pour différencier la création de section selon que l'on demande la suppression d'un article (a') ou d'une redirection (a'redir), avec deux boutons distincts.
    Le code du modèle pourrait-être quelque chose comme :
    <includeonly><span class="plainlinks" id="<nowiki>{{</nowiki>a'redir{{!}}{{anchorencode:{{{1|}}}}}<nowiki>}}</nowiki>">[{{fullurl:{{{1|}}}|redirect=no}} <span title="Redirection">↳Redir. : </span>] [[:{{{1|Titre manquant}}}]]<!--
    --> · {{Abréviation discrète|1=[{{fullurl:{{{1|}}}|action=history}} h]|2=Historique}}<!--
    --> · {{Abréviation discrète|1=[{{fullurl:Spécial:Journal|page={{urlencode:{{{1|}}}}}}} j]|2=Journaux}}</span><!--
    --> · [[Spécial:Pages liées/{{{1|}}}|<span title="Pages liées">↵</span>]]<!--
    --></includeonly>
    
    Ideawipik (discuter) 5 novembre 2020 à 23:28 (CET)
    Merci Ideawipik  , je vais tester cette proposition en sous-page de ma page utilisateur. — Ariel (discuter) 6 novembre 2020 à 07:25 (CET)
    Bonjour Ariel. Un modèle de ce type pourrait également s'intituler « Noredirect' » puisqu'il serait applicable pour plusieurs espaces par exemple pour une redirection de modèle ou une redirection de catégorie. Comme l'est d'ailleurs « A' » qui accepte la syntaxe {{a'|Catégorie:…}}. Il s'agirait d'une version allégée du modèle Noredirect (qui lui appelle une fonction coûteuse lors du test d'existence de la page). Si un simple test if n'est pas trop lourd, on peut gérer le cas de l'argument vide dès le début.
    Pour la mise en œuvre sur la page des suppressions immédiates, il suffirait d'ajouter, dans l'en-tête, un bouton comme [{{fullurl:Wikipédia:Demande de suppression immédiate|action=edit&section=new&preload=Wikipédia:Demande_de_suppression_immédiate/preload&editintro=Wikipédia:Demande_de_suppression_immédiate/editintro&preloadtitle=%7B%7Ba%27redir%7C1%3DTitre+de+la+page%7D%7D}} {{bouton cliquable|Lien direct, cas d'une redirection}}] (← exemple pour a'redir à adapter au nom choisi). Idem dans Wikipédia:Demande_de_suppression_immédiate/Utilisation.
    Enfin, il serait bien d'actualiser l'aide Wikipédia:Demande de suppression immédiate/editintro, en fonction du choix retenu, pour gagner en cohérence.
    Je te laisse voir ce qu'il en est et faire la proposition, sur la page de discussion de la page concernée, d'une évolution qui réduirait les confusions sur l'objet de la demande de suppression. Je me tiens disponible pour les questions techniques. — Ideawipik (discuter) 11 novembre 2020 à 20:32 (CET)
    En fait, et je regrette de ne pas l'avoir fait remarquer plus tôt (je n'y pensais alors plus), ce que je souhaite est exactement ce qui se passe avec le modèle « Demande de renommage/Titre » (appelé dans la page WP:DR) : quand l'une ou l'autre des deux pages mentionnées (voire les deux) est une redirection, en cliquant dessus on n'arrive que sur la page, pas sur la destination finale. — Ariel (discuter) 4 janvier 2021 à 18:44 (CET)
    Bonjour Ariel. Le modèle que tu cites fait appel à la même technique que la proposition ci-dessus (lien "externe" sans suivre la redirection). Le petit problème est qu'un tel lien vers une page supprimée n’apparaîtra pas en rouge. C'est pour cette raison qu'il est préférable de mettre deux liens : un "normal" (entre doubles crochets qui initialement suit la redirection et qui deviendra rouge à la suppression de la page) et un lien « redirect=no » conduisant à la page à supprimer et qui après suppression mènera à la même page (confirmant sa suppression) mais restera bleu. C'est ce qui avait été proposé en novembre. L'affichage de rouge dans le titre de section permet aux opérateurs de voir que la tâche est déjà accomplie. Bonne année à toi. — Ideawipik (discuter) 4 janvier 2021 à 23:29 (CET)
    Bonjour Ariel. Comme j'ai aussi eu besoin d'un modèle de ce type, pour une liste, j'ai finalement créé {{noredirect'}}, après avoir hésité sur le nom « Noredirect' » ou « A'redir ».
    En ce qui concerne la page, Wikipédia:Demande de suppression immédiate (h). J'ai remarqué un autre défaut, à propos des ancres sollicitées dans les commentaires de modification de la page. Les sections sont initiées dans « Faire une demande ». Le lien vers la section, généré par défaut pour le résumé de modification, correspond à la syntaxe choisie pour le code mais le titre réel de la section sera « Titre (d · h · j · ↵) » dans le cas du modèle A'. Pour pallier cette différence, le modèle A' génère une ancre tentant d'imiter le code et valant {{a'|Titre}} (accessible par un lien interne [[#&#123;&#123;A'&#124;Titre&#125;}]]). Donc si le champ est rempli avec exactement la syntaxe précédente, le lien sera fonctionnel vers l'ancre du modèle. En revanche, si le contributeur choisit {{a'|1=Titre}} ou même {{A'|Titre}}, le lien ne marchera pas et mènera en haut de la page. Techniquement, on doit pouvoir améliorer cela soit en examinant la présence du paramètre "nommé" « 1= », soit en générant plusieurs ancres au même endroit. Dans les deux cas, ce serait soit lourd pour le code du modèle et son exécution, soit très lourd pour le code HTML de la page générée … et encore, il ne sera pas évident de bien prendre en compte les distinctions « 1=Titre » et « 1= Titre » ni les variantes (majuscules initiale ou alias) dans les noms de modèles. Je ne pense pas que le jeu en vaille la chandelle, mais si quelqu'un a une idée lumineuse… Une alternative pourrait-être de préconiser la syntaxe {{a'|Titre}} et d'inviter le contributeur à remplacer manuellement les éventuels (très rare) signes « = » du titre par « {{=}} ». Cordialement. — Ideawipik (discuter) 24 mars 2021 à 11:30 (CET)
    Merci Ideawipik  . Je n'imaginais pas que ma demande poserait autant de difficultés. Ton modèle {{noredirect'}} est intelligent, mais j'ai peur qu'il n'aide pas beaucoup à éviter la suppression intempestive de la page de destination (dans le cas d'une redirection à supprimer), car il propose les deux liens (vers la redirection et vers la destination) : comme pour les non-redirections ça donne la même chose et que le 2e lien est plus visible que le premier, la confusion reste probable.
    Sinon, j'avoue ne pas avoir compris le problème d'ancrage posé par la syntaxe 1=. — Ariel (discuter) 24 mars 2021 à 14:02 (CET)
    @Ariel. Pas facile de concilier tous les avantages… Il est tout à fait possible de revoir la présentation du modèle proposé. En gardant les deux liens mais inversant les libellés ? Donc, voici un résumé.
    • 1a. Soit on considère que le nombre de suppressions de redirections sur une même page de WP:SI (y compris les archives) est potentiellement élevé et alors, pour ne pas prendre le risque d'un problème d'affichage (Catégorie:Page avec trop d'appels dispendieux de fonctions parseurs, cela altérerait l'affichage de WP:SI mais aussi l'apparition de la page WP:SI dans les pages liées à la page de redirection), il est impératif de privilégier un modèle sans ces fonctions comme {{noredirect-}} (avec l'inconvénient que le lien "externe" restera bleu même quand la page sera supprimée), ou en compromis, un modèle affichant les deux liens comme {{A-redir-simple}} ou le récent {{noredirect'}}.
    • 1b. Soit on considère que le nombre de demandes de suppression de redirections est faible, et alors le modèle {{noredirect}} est approprié, car il génère un lien vers la page de redirection si elle existe puis un lien rouge lorsque cette dernière n'existe plus.
    Dans tous les cas, l'usage d'un de ces modèles est préférable à celui de {{A'}} qui, avec un seul lien vers la page cible via la redirection, présente un risque de suppression de la mauvaise page. Cela dit, le reste est une question de praticité et de prise d'habitudes pour les usagers (demandeurs et opérateurs).
    • 1c. Si le problème est intermédiaire et ne concerne que les archives, il serait envisageable que le bot archiveur, lors des transferts quotidiens, remplace les appels au modèle {{noredirect|…}} par des liens rouges simples [[…]], uniquement si la page « … » a été supprimée. Ou bien qu'il fasse une substitution de modèle ou, encore plus simple, remplace le nom du modèle par celui d'un modèle plus sobre. Mais pour voir la possibilité de cela, il faut demander au dresseur   Orlodrim, ce qu'il en pense.
    2. La question des ancres est indépendante. Va sur historique de la page « Wikipédia:Demande de suppression immédiate », cherche le texte {{a'| et essaye de cliquer sur les liens. Par exemple, aujourd'hui, on a {{a'|Commune de Mugongomanga}} qui mène à l'ancre existante (générée par le modèle) et {{a'|1=Ovide nombre livre}} qui ne mène pas à l'ancre {{a'|Ovide nombre livre}} générée par le modèle. Est-ce plus clair ?
    3. Mise en œuvre. Une fois fixés sur le choix pour le point 1, il sera possible d'adapter en-têtes/formulaires comme indiqué dans le message du .
    Ideawipik (discuter) 24 mars 2021 à 16:12 (CET)

Travail demandé par LD m'écrire 29 juin 2021 à 15:52 (CEST)

Ajouter un paramètre au modèle « Test 0 » modifier

Travail demandé par Bru [M'écrire] 27 avril 2021 à 01:54 (CEST)

  • Avancement :
    65 %
  • Détails de la demande : Bonjour  ,

Il faudrait, si possible, rajouter un paramètre style dans le modèle {{test 0}}, qui, si le champ contient oui, ajoute le texte « Elle n'est pas rédigée dans un style encyclopédique. Sur Wikipédia, soignez l'orthographe, la compréhensibilité, la clarté, la neutralité, la sobriété et la précision du texte ('''[[Aide:Style encyclopédique|aide]]'''). » dans le message posté, de la même manière que pour les autres paramètres du modèle.

Par ailleurs, il faudrait modifier le lien interne apparaissant à la fin de la phrase présente si le paramètre pov est ajouté, afin qu'il ne dirige pas vers Wikipédia:Style encyclopédique mais vers Wikipédia:Neutralité de point de vue.

Enfin, la phrase du modèle : « Cependant, j'ai dû la retirer car : » devrait être remplacée par : « Cependant, j'ai dû la retirer pour les raisons suivantes. » afin d'être typographiquement correcte.

Merci beaucoup de votre aide par avance, et n'hésitez pas s'il y a besoin de davantage de précisions.  

Cordialement.

  • Article(s) pour le modèle : Pages de discussion des débutants, probablement plusieurs milliers.
  • Discussions : Juste ici.

Bonjour Bru. Je n'ai pas les droits pour modifier la page mais voici une proposition de wikicode à enregistrer dans la page du modèle. J'ai ajouté :

  • quelques simplifications du code final après substitution sur la page de discussion de l'utilisateur ;
  • un paramètre « 3 » ou « oldid » permettant de citer une modification ayant eu lieu sur plusieurs éditions (à l'image du modèle {{non signé}}) et un alias (« diff ») pour « 2 ».

La mise à jour de la documentation suivra. Elle en a d'ailleurs besoin car il y a dans le Templatedata une erreur de confusion entre « Valeur automatique » et « Exemple ». Je pourrai m'en charger une fois la modification effectuée. Je rajouterai aussi la catégorie Catégorie:Modèle à subster.

Remarque annexe. L'idéal pour ce modèle serait que, dans le cas où le paramètre autre n'est pas défini et aucun des paramètres (sources, POV, style, wikif, LE) ne vaut « oui », l'enregistrement ne soit pas effectué et qu'apparaisse un message d'erreur. Mais je ne sais pas faire cela. Si quelqu'un le sait, merci. En revanche, il ne doit pas être trop difficile de catégoriser, lors de l'enregistrement, les pages sur lesquelles l'insertion ne respecterait pas la règle, afin de signaler la mauvaise utilisation aux poseurs. Faut-il faire cela ?

En espérant ne pas avoir fait de boulette. Une fois le code fixé, on pourra solliciter un opérateur sur Wikipédia:Demande d'intervention sur une page protégée avec un simple lien interne ancré vers la présente section. Alternative : demander à Ariel qui s'était intéressé au modèle {{Test 1}}, il y a quelque temps. En attendant vos réactions, salut. — Ideawipik (discuter) 27 avril 2021 à 11:53 (CEST)
PS: Ces stats laissent à penser qu'il serait préférable de faire de raison un alias de autre. Certainement une question de moindre surprise avec les paramètres d'autres modèles semblables. — Ideawipik (discuter) 27 avril 2021 à 12:03 (CEST)

Merci Bru pour la demande et Ideawipik pour la réponse. Tant qu'à faire, serait-il possible de mentionner plusieurs articles, à l'image de ce que Modèle:Test 1 permet ?
Pour le cas où aucune raison n'est indiquée, on peut aussi afficher le modèle sans liste, en supposant que le poseur détaillera dessous les raisons (exemple), éventuellement après un message d'avertissement (du type "Vous n'avez pas indiqué de motif. Confirmez ?"). — Vega (discuter) 27 avril 2021 à 19:45 (CEST)
PS : avec mon message, je ne sais s'il faut passer à 45,43 % d'avancement ou reculer à 45,08 % =)
  Vega et Ideawipik : bonsoir !
Un grand merci, Ideawipik, pour le travail effectué et les bonnes idées d'amélioration que tu as apporté. Merci également de prendre en charge l'actualisation de la documentation.
Dans le cas où aucun motif n'est fourni, pour moi, sauf si on adapte le modèle pour qu'il soit malgré tout cohérent, je suis d'accord qu'il faudrait qu'apparaisse un message d'erreur au lieu du message peu sensé actuel, et catégoriser les mauvais usages me paraît également utile. Dans ton exemple, Vega, tu as tout de même signalé un motif, ce qui ne pose alors pas de problème.
Deux remarques supplémentaires :
  • je crois que C-helper a du mal avec ce modèle, car il indique que fournir un motif à l'annulation est facultatif (ce qui n'est pas le cas), et recopie tout le code du modèle (voir ce diff).
  • serait il possible de faire en sorte que, si un seul motif est fourni, la phrase ne soit pas Cependant, j'ai dû la retirer pour les raisons suivantes. mais Cependant, j'ai dû la retirer pour la raison suivante. ?
Merci encore !  
Cordialement, — Bru [M'écrire] 27 avril 2021 à 20:38 (CEST)
  Vega et Bru Water : Quelques réponses, en vrac. Pour ceux qui veulent aller à l'essentiel : passer directement ici.
Il y a différents types de messages d'erreur, en général.
  1. Message d'erreur, généré dans le modèle, affiché en rouge dans le texte. Pas très adapté ici car le poseur ne prévisualisera pas forcément la page et ne relira pas forcément la page après enregistrement. Il ne serait pas très sérieux qu'un nouveau trouve sur sa page un message d'avertissement avec une erreur.
  2. Un pop-up apparaissant au moment de la validation. Peut-être faisable dans un gadget. Je ne connais pas C-helper, mais si les « patrouilleurs », qui apposent régulièrement des messages préformatés en pddU, l'utilisent et vu la structure du formulaire, j'imagine qu'il ne devrait pas être trop compliqué de rajouter une étape ou un contrôle dans le cas du modèle « Test 0 ». Si quelqu'un sait où sont les sources de cet outil, je pourrai y jeter un coup d'œil, sans garantie de résultats.
  3. Un avertissement dans l'esprit de ce qui se passe en cas de conflit d'édition, lors de l'enregistrement
Je ne maîtrise pas techniquement les deux derniers cas. Mais fait remarquer que si quelque chose est mis en place pour cela, le système ne doit considérer que les ajouts sur la page éditée (diff) et non le préexistant dans la page. Sinon, des contributeurs venant juste déposer une message sans aucun rapport pourraient avoir des surprises si la page contient un {{Test 0}}. Il y a aussi une particularité à prendre en compte. Puisque le modèle subit une substitution le wikicode qui sera enregistré sur la page diffère de celui entré par l'utilisateur. À quel moment un contrôle est possible ?
Pour le reste (fait dans le bac à sable) :
  •   Le "code" dans le résultat final (visible dans le diff) n'est pas lié à C-Helper ou un quelconque éditeur mais au modèle lui-même. Le premier point de la première réponse et l'ajout de plusieurs "safesubst" déjà effectué dans la proposition initiale résoudra le défaut actuel qui entraîne du texte inutile, des octets "consommés" pour rien (taille, stockage) et un code pas simple du tout pour un nouveau qui éditerait le message.
  •   Gestion du singulier/pluriel. J'ai bien une petite idée et ferai des tests. Si aucun motif n'est donné, le message pourrait être « Pseudo du poseur vous en expliquera les raisons. » Comme le texte est rédigé à la première personne, plutôt « Je devrais vous fournir des explications. » Dans le même temps, on catégoriserait la page dans « Catégorie:Modèle de message « Test 0 » utilisé sans motif/explication/raison » Alternative possible : utiliser une catégorie commune avec d'autres modèles de message qui seraient dans le même cas de figure et utiliser des clés de tri (lettres) pour distinguer les différents modèles.. Les patrouilleurs surveilleraient régulièrement la catégorie et "gronderaient" leurs acolytes dont l'action au rabais l'alimenterait. Et on aurait moins besoin du message d'avertissement/erreur dont on a parlé précédemment.
    Techniquement, dans tous les cas, le modèle sera un peu plus lourd, il sera donc encore plus important de s'assurer que le modèle est bien substitué sur les pages et non pas simplement inclus. Il y aurait une évolution qui réduirait légèrement la complexité du code du modèle. Pour les paramètres optionnels (sources, POV, style, wikif, LE), au lieu d'avoir une activation [« oui » → ON ; tout le reste → OFF], serait-il acceptable de passer au fonctionnement suivant : [Paramètre non vide (même "non") → ON ; paramètre inexistant ou vide → OFF] ? L'utilisation serait la même qu'aujourd'hui, sauf pour les usagers, s'il y en a qui ont pris l'habitude de renseigner tous les paramètres [oui/non]. Sur les 12 000 modèles non substitués seulement sept portent des paramètres valant « non ». Ces derniers et un wikif=Hors sujet mis à part, on n'a jamais autre chose que vide ou « oui » exemple pour LE Un avantage, mineur, serait que |LE=x suffirait à activer le paramètre. Ne sachant comment fonctionne le C-Helper, je ne me risquerais pas à faire cette modification pour l'instant. Et puis finalement, ce n'est pas plus mal d'avoir un paramètre uniformisé, imposé, On pourrait aussi en tirer avantage.
  •   Possibilité de mettre plusieurs articles et plusieurs liens vers des modifications. Envisageable mais cela voudrait dire de passer à des paramètres nommés, ce qui ne serait pas plus mal, quand on voit les confusions comme le montre cette recherche. En effet, il faudrait des articleN, diffN et oldidN.
Après avoir écrit tout cela, j'ai trouvé Modèle:Test 0/Bac à sable et me suis amusé, avec une proposition assez complète. N'hésitez pas à tester dans des pages de discussion utilisateur ou brouillons. Vous n'êtes pas obligés d'enregistrer.
  •   Pas fait. Si on veux exploiter les options du modèle amélioré, à partir de C-Helper, ce dernier aura peut-être besoin d'une mise à jour, pour y implémenter les nouvelles possibilités. C'est par où ?
Ideawipik (discuter) 28 avril 2021 à 20:49 (CEST)
  Ideawipik et Bru Water : pfiou, j'avais sous-estimé le chantier que ça demanderait. Merci pour ces investigations ! Et pour les LI qui m'ont permis de comprendre enfin l'intérêt de substituer ou pas. Quelques éléments de réponses :
  • Message d'erreur : l'avertissement "type 3" est ce à quoi je pensais, mais si c'est compliqué on pourra sûrement s'en passer. Je ne sais pas modifier ta recherche pour vérifier s'il y a des cas où tous les paramètres >1 sont vides (et encore, seulement pour ceux non substés)... À vrai dire, m'est avis que l'utilisation étendue de ce genre de messages avant publication (détection d'erreurs de modèles, de vandalismes, de LE dans le texte, etc.) économiserait beaucoup de ressources humaines et machines prises par les corrections, mais des facteurs m'échappent peut-être. Ils ne sont pas déjà davantage utilisés sur en.wiki ?
  • Paramètres nommés : personnellement, je trouve plus rapide de ne pas avoir à nommer les paramètres, en tout cas le premier.
Salutations — Vega (discuter) 29 avril 2021 à 00:03 (CEST)
Bonjour,
Quel travail ! Merci infiniment.  
Je suis d'accord avec Vega pour le type d'avertissement, mais je n'ai aucune idée de comment configurer ça sur le plan technique. L'idée que le modèle indique que les raisons seront détaillées en dessous si aucun paramètre n'est renseigné me semble par ailleurs bonne.
Pour afficher la phrase par simple inclusion du paramètre et pas seulement si oui est présent, je trouve ça également plus simple, donc j'y suis favorable si ça ne cause pas de problème ! J'ai mal compris le rapport entre cette modification et C-helper, par ailleurs, mais tu peux trouver le code du gadget sur cette page — le script est géré par 0x010C, mais celui-ci est absent jusqu'en février 2022.
Enfin, merci pour le brouillon, je vais aller tester tout ça !
Cordialement, — Bru [M'écrire] 29 avril 2021 à 09:24 (CEST)
  Vega et Bru Water
Messages. De ce que j'ai vu comme messages lors de l'édition et sur lesquels on pourrait jouer :
  • les messages d'avertissement préventifs qui apparaissent en haut de page lorsque l'on clique sur « Modifier le code » d'une page particulière. Il rappelle les instructions spécifiques pour ladite page (on peut le voir pour certaines pages de requêtes). Pas adapté ici.
  • les messages qui à la prévisualisation avertissent d'une possible erreur. Par exemple, il arrive de voir « Avertissement : <Nom de la page éditée> appelle Modèle:<Untel> avec plus d'une valeur pour le paramètre « 1 ». Seule la dernière valeur fournie sera utilisée. ». Ce serait un bon début mais encore faut-il que le patrouilleur prévisualise.
  • l'avertissement de "type 3", après validation et prévenant l'enregistrement jusqu'à correction. Piste à creuser. Il demandent un développement plus en amont. Si vous avez des exemples observés, histoire de s'inspirer de l'existant… Mais n'attendons pas qu'une solution sur ce point soit établie pour modifier le modèle.
Paramètres
  • Bien sûr, les paramètres positionnels 1 et 2 restent et resteront des alias des nouveaux article1 et diff1. Mais pour la suite, il est impossible de mettre des paramètres non nommés ayant des fonctions différentes et dont le nombre est variable, sauf à soit analyser le contenu (et encore ... comment savoir si en écrivant 123, le contributeur veut dire article 123, diff=123 oldid=123), soit se trimballer des « ||||| » pour les paramètres vides (Bonjour les yeux, confusions assurées. Et qu'adviendra-t-il si on augmentait un jour le nombre de paramètres acceptés ?)
  • La question du changement de critère ON/OFF n'est pas indispensable. Le gain en performance serait faible, vu que pour chaque message déposé, la fonction (le modèle) est sollicité une seule fois, au moment de sa substitution. Il est préférable de laisser ainsi une chose qui roule et à laquelle sont habitués les utilisateurs.
Vega, il convient de garder en mémoire que les inclusions reportées sur wstats.fr sont des utilisations, parfois anciennes, pour lesquelles, il aurait été préférable de voir le modèle substitué. Mais elles permettent de repérer des tendances ou utilisations incorrectes (ou obsolètes) des paramètres. Cela veut aussi dire que potentiellement, il y a plein d'autres pages où le modèle a pu être substitué avec un texte ne correspondant pas aux attentes.
Merci pour le lien vers le code de C-helper. Dans, MediaWiki:Gadget-C_helper_message.js, on trouve {category:1, display:'Test 0', template:'Test 0|$(page)|raison=$(extra)|user=$(user)', extra:'Type de maladresse (facultatif) :', help:''},. Si je comprends bien, il en est resté à une ancienne version du modèle « Test 0 » pour laquelle le paramètre « raison » était valide, comme le paramètre « user » (aujourd'hui inutile, remplacé par une détection automatique du poseur lors de la substitution). Du coup, je ne comprends pas immédiatement comment il permet l'entrée du motif (activation d'options préformatées), ni s'il permet d'entrer un lien vers la modification annulée. Je devrais tester ce gadget.
Voici un bon exemple de ce qu'il ne faut pas faire avec les modèles à "subster". Le but est que le concerné par le message ait un message en dur dans sa page, sans qu'il ait besoin de chercher d'où vient le message ni de comprendre l'usage des modèles sur Wikipédia. En plus, cela induit un autre problème. Si l'utilisateur Toto va sur la page donnée en exemple clique sur « Modifier le code », pour y faire une modification quelconque et enregistre la page, le lien « me contacter » ne sera plus un lien vers la page de discussion utilisateur du poseur initial mais vers celle de Toto. Cela est confirmé par cet exemple Discussion utilisateur:LE REAL BRO où le modèle a été posé par   Dfeldmann mais le lien dirige vers la pdd du dernier intervenant sur la page. D'où l'importance du subst: dans {{subst:Test0|…}} quand on pose le message en wikicode. Dans la doc de C-helper, il y a une image montrant une case à cocher. Pour information   Harrieta171 et JLM.
Bonjour Ideawipik  , merci pour ce travail. Je n’ai pas compris ce qu’il faut faire pour cocher la case mentionnée ci-dessus. Désolé d’être aussi crasse. Bien à vous.--Harrieta171 (discussion) 3 mai 2021 à 11:52 (CEST)
Encourager la substitution. Je me demande s'il ne serait pas préférable que le texte du message soit automatiquement "substé", par défaut (dans tous les cas), même si le poseur oublie le « subst: ». (Note pense-bête, l'opération inverse consistant à empêcher la substitution – ou plutôt à se servir de la substitution pour convertir un appel {{subst:Modèle|…}} en texte {{Modèle|…}}) – est possible ; voir notamment du côté de Module:Unsubst.) Je n'ai pas trouvé de solution immédiate. En revanche, on peut mettre un message d'erreur lorsque le modèle est inclus au lieu de subir une substitution. Voir la proposition actualisée (Modèle:Test 0/Bac à sable).
Il reste juste une broutille à régler dans {{BMA début}} (passage à la ligne superflu lors de la substitution, on y remédie facilement mais il y a un choix à faire entre plusieurs techniques) Edit :   Fait.
Dans l'attente de vos réactions. — Ideawipik (discuter) 2 mai 2021 à 23:52 (CEST)
Bonjour Ideawipik  , merci beaucoup du travail accompli, encore une fois. Je crains qu'une bonne partie de ton message ne dépasse mes compétences techniques, je n'ai donc pas grand chose à rajouter sur ce que tu expliques vis-à-vis des avertissements ou de C-helper.
Pour les paramètres, c'est un peu pareil : si tu indiques que c'est mieux de laisser ainsi, je te fais confiance.
Pour ce diff, je ne comprenais pas l'intérêt de substituer un message au moment où j'ai effectué la modif, ni les problèmes que ne pas le faire peut engendrer. Je tâcherai de faire attention, mais, du coup, je suis favorable — si c'est faisable techniquement — à ce que le modèle substitue le texte par défaut puisque ça permettrait d'éviter les problèmes que tu mentionnes : c'est plus pratique qu'un gros message d'erreur en rouge, et ça faciliterait probablement la vie aux patrouilleurs peu habitués.  
Deux autres remarques qui me viennent à l'esprit :
  • il faudrait, idéalement, que lorsque les modifications annulées sont plurielles, toute la phrase le prenne en compte. Dans cet exemple, la phrase n'est pas accordée correctement (« je vous remercie de vos modifications » mais « voir la modification » ; « j'ai dû les retirer » mais « elle contient », etc.) ;
  • j'ai l'impression que lorsqu'aucun champ de motif n'est rentré, le message censé indiquer que les raisons seront détaillées plus bas ne s'affiche pas (voir ici, à priori je n'ai pas fait d'erreur dans l'insertion du modèle). Par ailleurs, c'est un détail, mais tant que j'y suis, je pense que la phrase qui apparaît devrait plutôt être formulée ainsi : Cependant, j'ai dû la retirer et vais vous fournir des explications ci-dessous. vu qu'il est impératif que le patrouilleur fournisse des explications.
Merci encore ! Cordialement, — Bru [M'écrire] 3 mai 2021 à 09:05 (CEST)
Bonjour
  Harrieta171. N'ayant pas testé C-Helper, je ne suis pas sûr mais imagine que la case est cochée par défaut ? On lit dans son code : « Substituer les modèles / Cette case doit rester cochée dans la plupart des cas. » Quelqu'un pourrait confirmer ? En wikicode, l'appel de ce modèle, comme celui de certains autres messages similaires, doit se faire en le substituant, selon la syntaxe donnée ci-dessous.
  Vega et Bru Water. « Que le modèle substitue le texte par défaut », ce serait l'idéal. Je n'ai pas trouvé la solution pour ce faire. Donc la syntaxe à adopter restera {{subst:Test 0|…}}. Il faudrait le mettre davantage en avant dans la documentation du modèle (fait avec le modèle {{modèle à subster}}) et sur l'aide aux patrouilleurs. Le message en rouge est conservé en cas de non-substitution mais le texte du modèle est également présent.
  • Menues corrections du texte. En ce qui concerne, les remarques sur le code, les phrases ont été légèrement revues pour éviter le passage entre le singulier et le pluriel. Est-ce que cela convient ? Le dernier problème était lié à un simple commentaire dans le code qui était invisible lors d'une inclusion (transclusion) mais affectait le test lors d'une substitution. Il est corrigé sur le Bac à sable. J'attends vos dernières remarques sur le contenu du texte avant de demander l'intervention d'un administrateur pour mettre à jour le code du modèle. Cela peut être réalisé indépendamment des retouches qui seraient utiles dans C-Helper. Les substitutions seront plus propres qu'actuellement.
  • Il y aussi la question des catégories, Je pense qu'on peut créer la « Catégorie:Page contenant un message d'avertissement qui devrait être substitué », elle sera alimentée par le modèle s'il est inclus sans substitution et ne se retrouvera jamais en dur dans le code des pdd utilisateur. En revanche,la « Catégorie:Page contenant un message « Test 0 » utilisé sans explication », envisagée un temps, aurait été écrite en dur sur la page où le modèle aurait été substitué si aucun des paramètres optionnels d'explication n'avait été activé au moment de la pose. Si le texte introductif de la "non-liste" est modifié en « Cependant, j'ai dû la retirer et vais vous fournir des explications ci-dessous. » et si les utilisateurs expliquent effectivement leur action, il me semble préférable d'abandonner l'idée de cette catégorie qui demanderait une édition supplémentaire de la page pour la retirer si le message est effectivement motivé sous le modèle. — Ideawipik (discuter) 6 mai 2021 à 17:46 (CEST)
Bonsoir  ,
Pour C-helper, Harrieta171, la case est effectivement cochée par défaut lorsque le gadget est utilisé pour laisser un message sur une PDDU. Le champ, nommé « Substituer les modèles », se situe juste au dessus de la liste des messages apposables, et juste en dessous du champ permettant d'indiquer l'article où les modifications ont été révoquées.
  Ideawipik : pas de soucis pour la substitution, ça me convient. Pour les catégories, je te rejoins également : une qui répertorie les modèles non-substitués est utile, mais pas une qui répertorie les messages sans paramètre prédéfini tant que les patrouilleurs expliquent les raisons en dessous du message automatique — il est, par conséquent, important de bien expliquer dans la documentation du modèle que détailler les motifs du revert est capital.
Sur les phrases, c'est mieux ainsi, merci ! Un dernier cas qui me chiffonne est celui-ci, puisque le modèle parle d'une modification au singulier alors qu'il y en a plusieurs, mais si c'est trop compliqué à corriger, ce n'est pas très grave. Je me suis par ailleurs permis de modifier la phrase qui apparaît dans le cas où aucun paramètre prédéfini n'est rempli, j'espère ne pas avoir fait de bêtise  .
Hormis ça, tout me paraît bon, merci encore une fois de tout ton travail ! En l'absence de contre-indication future, tu peux introduire une DIPP quand tu le souhaites  .
Bonne soirée, — Bru [M'écrire] 7 mai 2021 à 02:23 (CEST)
Bonjour Bru. Tu as bien fait de modifier le texte ; le brouillon ne m'appartient pas. Dans l'occurrence qui te chiffonne, La formulation est normale, selon moi. Cet appel est fait avec le paramètre pluriel=non qui force le singulier. Inversement pluriel=oui force le pluriel. Si tu fais le même appel sans ce paramètre optionnel, le pluriel sera mis automatiquement, en raison de la présence de article2 ou de diff2. Il est vrai que l'exemple n'est pas forcément idéal ni nécessaire dans la documentation. Dans le cas où un utilisateur fait exactement la même modification dans une série d'articles, cette formulation ne serait pas fausse, celle au pluriel non plus. Bref, c'est un détail et ce paramètre sera rarement utilisé mais a le mérite d'exister pour des exceptions.
OK pour la demande d'intervention. J'actualiserai dans la documentation, juste après. Ensuite, rien ne t'empêchera d'y faire les retouches nécessaires.
J'ai juste un peu de scrupules à alimenter une « Catégorie:Page contenant un message d'avertissement qui devrait être substitué » avec 12 000 pages (liste rien que pour Test 0).   FDo64, NicoV et Thibaut120094, qu'en pensez-vous ? Un bot devrait-il chercher les poseurs et substituer les modèles de ce type ? Inutile de lire toute la discussion, le problème réel est expliqué, un peu plus haut, ici et permet de comprendre pourquoi parfois des réactions sont adressées au mauvais destinataire. Et vous pouvez jeter un coup d’œil au brouillon de proposition récente à transférer (la partie initiale, avant la Documentation, seulement) dans le code du modèle {{Test 0}}. Merci. — Ideawipik (discuter) 7 mai 2021 à 14:56 (CEST)
Re, Ideawipik,
Ça roule, pas de soucis pour la formulation, et, oui, je relirai la documentation avec plaisir. Pour la catégorie à alimenter ou pas, la question me dépasse sur le plan technique donc je laisse ma place aux utilisateurs compétents notifiés.
Cordialement, — Bru [M'écrire] 7 mai 2021 à 15:47 (CEST)

Modules pour les populations des communes de France modifier

Travail demandé par LD m'écrire 29 juin 2021 à 16:08 (CEST)

  • Avancement :
    0 %
  • Détails de la demande : Création d'un sous-module contenant la racine des adresses url les plus communes pour le projet : www.insee.fr/fr/information/ ; www.insee.fr/fr/statistiques ; cassini.ehess.fr/fr/html/ ; etc.
  • Pour tous les modules : notamment, catégorie:Module de données démographiques
  • Discussions :

L'idée serait d'appeler le sous-module en tête (comment  ) et ensuite de réaliser une inclusion, par ex. dans Module:Données/Boigny-sur-Bionne/évolution population, passer de http://cassini.ehess.fr/fr/html/fiche.php?select_resultat=2397 à 'sous-module' + '2397' Je ne connais pas Lua, j'aurais besoin de quelques précisions pour pouvoir ensuite passer sur tous mes modules concernés (pour les modifier avec mon bot), notamment : comment inclure un sous-module et l'inclure ; un exemple suffirait, je me chargerais ensuite du reste  , merci -LD m'écrire

Bonjour LD. Il y a déjà pas mal de choses dans Module:Population de France. En résumé, tu veux juste que les racines des sites soient stockées dans des "variables" à un seul endroit et ne conserver dans la base de données des communes que les identifiants numériques de celles-ci. Bonne idée ! Même s'il est possible de le faire, je doute qu'il soit nécessaire/productif d'appeler ce module (ces variables) dans tous les modules du type « Données/commune/évolution population ». Il serait peut-être plus pertinent de l'appeler uniquement dans les fonctions ("sur-modules") qui affichent les données, en l’occurrence les liens externes, dans les articles. Est-ce que les données seront stockées dans des champs « ID_Cassini », « ID_INSEE_info », « ID_INSEE_stats », etc. ? Est-ce que ces données pourront se substituer aux « source1 », « source2 », « source3 » ? Fonctionnement global à vérifier.   Roland45 ? PS: En réponse à la question technique, pour une utilisation locale, avec un nom : …=require("Module:…") (exemple et doc genérale).Ideawipik (discuter) 1 juillet 2021 à 19:53 (CEST)
Bonjour Ideawipik  
Pour mémoire, tu avais préconisé cette solution lors de la RBOT associée ;
L'idéal serait de centraliser la racine, quelque part, et que ce soit modifiable en une correction pour tous les modules parce que le site continue de déplacer ses pages. Stricto sensu, seul Cassini-Ehess m'intéresse vraiment mais quite à créer un module-racine, autant ouvrir le champ des possibles aux autres formes de liens racines.
Pour le stockage des variables, je ne sais pas trop à vrai dire ; vu que je ne sais pas vraiment lire Lua, je peine à comprendre ce qui a déjà été fait (surtout que le dossier est relativement lourd et complexe pour un néophyte lua). Mais dans l'esprit, ce serait : ["source1"] = ["Module.RACINE-CASSINI"] + "2397", (bon le code doit pas s'écrire comme ça, mais en python ça donnerait source 1 = function(racine + "2397")) ;
Une autre possibilité envisageable serait que je contacte Cassini-Ehess pour essayer d'avoir une BDD SQL pour les associations, si ça peut aider à simplifier les modules...
Dans cet esprit de centralisation, j'ai mis à jour {{Cassini-Ehess}}, ainsi la plupart des liens sont déjà encodés et pour les notices communales, cela fonctionne par racine + id.
J'espère que cela t'éclaire un peu,
Question connexe : peut-on détecter les références par inclusions de modules (comparer les sources provenant du wikicode à celles des modules) ? Parce que la correction des liens brisés entraîne des doublons de références pas fameuses dans les cas où les modules sont appelés... LD m'écrire 1 juillet 2021 à 20:28 (CEST)
Merci LD. Oui j'ai bien compris. Reformulation de ma première question.
  • Est-ce que vous voulez continuer à utiliser les "source1", "source2", "source3" ? S'ils sont tous de la même forme, autant passer à des paramètres précis et générer l'url un peu plus haut dans le module et pas dans la base de donnée pour laquelle le stockage de l'"identifiant" (2397 dans ton exemple) suffirait. Dans le cas contraire, il peut-être préférable de garder le mode de fonctionnement actuel. Je n'ai pas de vue d'ensemble.
  • Est-ce que quand un module « Module:Données/Commune/évolution population » est sollicité, le modèle associé à cette opération affiche toujours une référence (source1 et/ou 2 et/ou 3) ? C'est juste qu'il serait inutile de charger le sous-module, si son contenu (la/les racine(s) de l'url) n'est pas utilisé
Pour la question connexe. Je ne vois pas trop le rapport direct avec les liens brisés. Dis-moi si je comprends correctement. Veux-tu parler de ceci ? Un modèle M qui introduirait une référence <ref>BlaBla_CASSINI</ref> et cette référence serait aussi appelée, en dur dans le code de l'article <ref>BlaBla_CASSINIbis</ref> avec la même URL cible, éventuellement sous une forme légèrement différente, pour sourcer un autre point.
Je n'ai pas de réponse technique pour la vérification des url en doublon. Il faudrait travailler sur le code HTML final de l'article ou la liste des liens externes.   Orlodrim, qui génère une liste de liens externes sur les pages d'homonymie, aura peut-être une idée. Mais j'irais du côté des références nommées avec une nomenclature bien définie, propre au projet. Par exemple dans le cas de Cassini, le module/modèle pourrait générer une référence <ref name="CassiniEhess_2397">{{Cassini-Ehess|id=2397|…}}</ref>. Il conviendrait alors que les rédacteurs suivent la même forme/convention pour citer la source dans l'article. Le pseudo-doublon dans le wikicode ne serait à priori pas problématique puisque les deux références contiendraient le même contenu et le même identifiant. Dans ce cas, le logiciel groupe les références. C'est sur ce principe que fonctionne le modèle {{sfn}}. Et même si le modèle M était un jour retiré de l'article, la référence serait encore présente, en dur. Pour faciliter la chose, tu peux créer un modèle RefCassini-Ehess qui générerait la référence nommée. La seule petite difficulté peut survenir si les notes/références sont dans un "group" précis. Donc il conviendrait d'ajouter un paramètre "groupe" à RefCassini-Ehess, par rapport à ceux de Cassini-Ehess.
Là où les deux points se rejoignent : manipuler des « ID_Cassini », « ID_INSEE_info », « ID_INSEE_stats », plutôt que des "sourceN" permettrait de mettre cela en place plus facilement (sans avoir besoin d'ajouter des "sourceN_name" dans la base). Autre avantage : permettre d'avoir des références davantage conformes à la présentation des liens externes comme celles des modèles « Cassini-Ehess » ou « Lien web ». — Ideawipik (discuter) 1 juillet 2021 à 22:44 (CEST)
Amha, on peut passer à des paramètres précis plutôt que conserver une BDD de variables, à confirmer par @Roland45 cela dit ;
Pour la question connexe, les sous-modules créent <ref name=Cassini>{{Cassini-Ehess|id=2397|…}}</ref> et depuis le wikicode via AWB, quand je transforme un lien brisé vers un modèle Cassini <ref>{{Cassini-Ehess|id=X|…}}</ref>; il m’est impossible de vérifier que l'id du lien brisé (transformé en modèle) correspond (ou non) à l'id de la réf. du modèle inclu ; sinon je réutiliserais <ref name=Cassini/> ; autrement dit, je crée (parfois) des doublons de références si je passe dans les pages contenant des liens brisés ET un modèle de ce groupe de modules ; en plus, j'ai vérifié, ces doublements de réfs. sont indétectables par WPCleaner, ce qui rend la gestion ultérieure entièrement manuelle ; donc pour j'évite de passer là où les modèles/modules sont inclus, mais tôt ou tard, je devrais privilégier la requête initiale (la réparation) plutôt que le rendu lui-même, sauf si je trouve une solution; car aussi, a contrario, il n'est pas concevable de mettre <ref name=Cassini/> à chaque fois puisque parfois, les liens brisés renvoient vers une source différente, cela détournerait la source d'adopter ce système. LD m'écrire 1 juillet 2021 à 23:16 (CEST)
@LD. L'id utilisé par le module correspond bien à quelque chose : soit à (ou via) un paramètre du modèle M (celui qui sollicite le module) soit à une donnée liée à la page (titre, nom de commune, élément Wikidata). Question préliminaire : peut-il y avoir deux modèles M dans la même page (avec des id différents) ?
Remplacer une référence Cassini brisée par <ref name=Cassini/> ne me semble pas être une bonne idée, d'une part en raison de ta remarque sur la vérification nécessaire de X=2397 (Bien que ce soit faisable en utilisant la correspondance de la question du paragraphe précédent et si besoin allant lire le sous-module de donnée correspondant) et d'autre part dans l'éventualité d'un retrait du modèle M de la page ou l'arrêt de l'introduction du lien via ce modèle. C'est pourquoi, ma proposition de remplacer les liens erronés<ref>Texte actuel de la référence Cassini pour l'id X</ref> dans les articles par {{RefCassini-Ehess|id=X|…|groupe=…}} me semble préférable. 1) L'utilisateur n'aurait pas à se préoccuper des "name=" intégrés automatiquement au nouveau modèle. 2) On n'aurait pas les problèmes de doublon qu'engendreraient des références non nommées <ref>{{Cassini-Ehess|id=X|…}}</ref> ou pas assez précises (name="Cassini"). Important, en revanche, il faut s'assurer que le modèle M utilise la même mise en forme pour cette référence que le futur modèle {{RefCassini-Ehess}} (idéalement il devrait le solliciter dans son module) si on ne veut pas avoir d'erreurs « Références nommées définies plusieurs fois avec des contenus différents ».
Implémentation des modèles. J'ajoute tout de suite une question. Dans le lien actuel (référence) vers Cassini dans les pages de communes n’apparaît pas le nom de la commune, mais seulement le numéro (id). Si on garde cette particularité, cela nous arrange pour la suite. Dans le cas contraire, l'idéal serait soit a) de trouver un moyen d'obtenir ce nom à partir de l'id ce qui permettrait de s'affranchir du paramètre "titre" du modèle Cassini-Ehess, soit b) de définir un identifiant unique à partir des paramètres "id" et "titre" (cette deuxième option nécessitera de bonnes explications pour l'usager (dans le choix du "titre") et est moins bien pour la maintenance, en cas de changement du nom de la commune ayant un identifiant donné.
Ensuite, les seuls point délicats lors des remplacements sont :
  • la gestion des éventuels <ref name="Toto">Texte actuel de la référence Cassini pour l'id X</ref> associés à des rappels <ref name="Toto"/> (et variantes typo)
  • celle des <ref name=Cassini/> déjà présents, (si non définis en dur dans l'article)
  • le respect des groupes (ce point n'est pas très gênant puisque techniquement deux références dans deux groupes différents peuvent avoir le même "name").
  • la présence antérieure éventuelle dans l'article d'une référence nommée de la même façon que le nom retenu pour les modèles RefCassini-Ehess et M.
Maintenance : il y aura des doublons pendant la phase de transition.
Remarques finales :
  1. On est parti sur les id des url, ce qui est vraisemblablement le plus simple mais un autre identifiant unique relatif à la commune serait envisageable mais peut-être plus lourd.
  2. Simple curiosité. Y a-t-il une raison de ne pas se servir de la donnée Wikidata P8422 (« identifiant Ldh/EHESS/Cassini ») ?
PS : Venant de découvrir{{Cassini-Ehess/ancre}}, je te suggères d'introduire les identifiants des ancres (div id=…) directement dans le modèle Cassini-Ehess, avec par défaut un identifiant basé sur l'id Cassini, comme dans ma suggestion pour RefCassini-Ehess dont le code pourrait ressembler, avec l'éventualité b), à {{#tag:ref|{{Cassini-Ehess|id={{{id}}}|titre={{titre}}}}}|name={{#if:{{{name|}}}|{{{name}}}|Cassini-Ehess_{{#if:{{{id|}}}|{{{id}}}}}{{#if:{{{titre|}}}|{{{titre}}}}}|group={{{groupe|}}}}}, en faisant en sorte de ne pas avoir de nom défini plusieurs fois avec des contenus différents.
Ideawipik (discuter) 2 juillet 2021 à 14:43 (CEST)
Salut Ideawipik  
Je vais tenter de répondre point par point  , n'hésite pas à me soliciter sur un point que je n'aurais pas suffisament détaillé :
  1. Dans une même page il peut y avoir deux modèles M, c'est parfois le cas dans les anciennes communes ou les communes avec plusieurs ID Cass selon son histoire ;
  2. Créer {{RefCassini-Ehess}} me paraît une bonne idée mais ne pourra pas non plus être utilisée dans 100% des cas, certaines références contiennent par exemple un commentaire du style « Contrairement à l'Insee, Cassini-Ehess ne dit rien sur le statut de la ville en 1870, la population (...) voir (la réf. Cassini) ». A moins de rajouter un paramètre commentaire et une position av./ap. pour déterminer son emplacement. Mais par conséquent, ça ne matcherait pas avec le module   donc {{Cassini-Ehess}} pourrait toujours être utile pour intégrer un commentaire. Du coup on partirait sur au moins deux modèles pour Cassini : l'un pour une référence basique : {{RefCassini-Ehess}} ; l'autre {{NoteCassini-Ehess}} (l'actuel {{Cassini-Ehess}}) et l'ancre : {{Cassini-Ehess/ancre}} ; sauf si tu vois une meilleure solution pour gérer les noms et leurs problèmes.
  3. Sur l'implentation, gardons ID Cassini, créer un ID est inutilement lourd, je partage ton avis : communes fusionnent régulièrement, il faudra une maintenance... tandis que les ID Cassini, ben ils s'en chargent eux-mêmes  
  4. Pour ta curiosité, P8422 (« identifiant Ldh/EHESS/Cassini ») est l'ID de la commune définie selon son statut "moderne" mais chaque page de commune peut regrouper plusieurs ID Cassini : les anciennes communes ou les communes qui ont fusionné sont de bons exemples, mais il y a également les pages de cantons regroupant un tas de communes où P8422 (« identifiant Ldh/EHESS/Cassini ») n'est pas envisageable. Et enfin, Cassini a des IDs différents pour les grandes villes selon leurs époques (le coeur historique, tel ou tel identité qui s'est fusionné, etc.). Donc, il faudra renseigner l'ID, cela laisse le choix à l'éditeur directement sur WP de renvoyer vers la bonne notice à chaque fois qu'il emploie une référence Cass.   pour le principe de vérifiabilité.
  5. Pour l'ancre, je suivrais ce conseil.
Bon ... quelle est la prochaine étape ?  
Merci de ta réponse LD m'écrire 7 juillet 2021 à 02:46 (CEST)

Bonjour @LD et @Ideawipik . Je n'ai pas bien compris la conclusion de la proposition : il s'agirait de transférer l'id Cassini, actuellement dans le module de données, directement dans le corps de l'article, en tant que paramètre associé au modèle {{Cassini-Ehess}} ? Mais comment gère-t-on alors les doublons de ref avec le module:Population de France, que la racine de l'url soit à l'intérieur du code du module de traitement ou dans le module de données ?
La meilleure solution me parait être de modifier la fonction p.source_cassini dans Module:Population de France/Sources en mettant en dur la racine de l'url et ne garder dans le module de données en source1 que l'id Cassini, puis en cas de réutilisation de la ref dans le corps de l'article, on écrit <ref name=Cassini/>. Pour quelqu'un qui maîtrise le lua, cela me parait pas trop compliqué. On n'a pas besoin d'un quelconque sur-module.
Au fait, petite précision : « ... tandis que les ID Cassini, ben ils s'en chargent eux-mêmes ». Cela ne me parait pas exact. La base Cassini est une base historique et est figée dans le temps ... en 2006. Les communes nouvelles n'y sont pas. Et il n'y a eu aucune modif depuis cette date.
Maintenant on peut aussi faire passer un bot pour modifier l'url Cassini dans tous les modules de données. C'est encore plus simple. Ce n'est pas tous les jours qu'il y a un changement de racine d'url. De toutes façons en tout état de cause si on veut faire passer la racine de l'url dans le module de traitement, il faudra modifier tous les modules de données. Cordialement.Roland45 (discuter) 7 juillet 2021 à 10:09 (CEST) ┌─────────────────────────────────────────────────┘

@Roland45
Pour rappel, tu avais demandé en février de faire ceci.
Mais plutôt que de conserver une URL, j'ai proposé que de conserver l’ID dans les modules d'évolution de population et centraliser la racine quelque part. Et l'idéal serait même de nommer la référence des modules Cassini<numéroID> pour être certain que ça colle avec les modèles.
Il n'y a pas eu de mise à jour depuis 2006, mais il est probable qu'ils en refassent une. En tout cas, il est préférable qu'ils gèrent leurs IDs plutôt qu'on y travaille, à mon avis. LD m'écrire 7 juillet 2021 à 16:45 (CEST)
@LD Oui. Je me rappelle bien de ma demande qui portait sur une modif de l'url dans tous les modules. Ce que je dis, c'est que si tu veux ne conserver que l'id dans le module de données, il faut simplement modifier la fonction p.source_cassini dans Module:Population de France/Sources en mettant en dur la racine de l'url. Mais dans tous les cas on doit faire un passage sur les 25000 modules de données, ainsi d'ailleurs que sur les modèles de données qui n'ont pas été transférés en modules.
Pour ce qui est de renommer le nom de la référence en Cassini<numéroId>, il faudrait aussi changer le module de traitement, mais par contre on ne sait pas si cette ref Cassini simplement, qui correspond à l'id de la commune, n'est pas utilisée par ailleurs. Je ne le préconise donc pas. Cordialement.Roland45 (discuter) 7 juillet 2021 à 19:04 (CEST)
Oui, et quite à passer sur les modules, autant les retravailler en même temps. Mais mes compétences en Lua s'arrêtent à la réflexion globale, je vous laisse choisir l'optimum et j'appliquerais bêtement les modifications avec mon bot  
D'expérience sur plus de 2000 articles, il y a bien plus souvent un conflit entre deux références appelées "Cassini". L'association et la réflexion sur une mise en forme identique du texte des références (module / modèles) me semble une solution plus adéquate pour éviter les erreurs comme soulignées par Ideawipik.
--LD m'écrire 7 juillet 2021 à 19:12 (CEST)
Bonjour   LD et Roland45
Présentation des articles. Avis personnel sur un point connexe : je ne vois pas trop l'intérêt de mettre la référence à Cassini dans une section dédiée comme illustré dans la documentation du nouveau modèle {{Cassini-Ehess/ancre}}.
  • … ou alors, il faudrait vérifier que le bas de page associé à la ref (ou note) soit sur toutes les pages qui contiennent le modèle {{Population de France/introduction}} (et peut-être les autres {{Population de France/…}}). Une sorte de fonctionnement par paire.
  • Cette présentation complexe n'est pas forcément à adaptée pour de simples ref/notes qui, à mon avis, n'ont pas à être mises en avant plus que cela.
C'est pourquoi, conserver de simples références (éventuellement dans un groupe "Notes"), comme c'est le cas actuellement, me semble préférable. Le seul problème qui puisse arriver est l'absence d'un {{Références|groupe=Note}} en fin de page, pour laquelle un message explicite apparaît dans l'article (recherche), avec une résolution relativement aisée.
Avez-vous un exemple de page qui porterait deux modèles {{Population de France/introduction}} (ou deux autres modèles du même acabit), en utilisant son paramètre nom (non documenté mais valide) ? C'était la question préliminaire de ma précédente intervention. Parce que sur ce genre de pages, un nom de référence unique name="Cassini" ne convient pas. Cela est illustré dans les notes avec messages d'erreur visibles sur Projet:Communes de France/Module démographique/Comparatifs. Wstat.fr donne très peu de cas d'utilisations du paramètre nom et aucun appel en double. Il faudrait vérifier la même chose pour les modèles …/tableau, …/graphique, etc. J'ai juste trouvé une balise "ref" nommée définie plusieurs fois avec des contenus différents pour le nom « Cassini » dans Mauzac-et-Grand-Castang, avec une définition locale dans l'article. Attention particulière pour les articles avec définition en dur, si on devait y ajouter un modèle « Population de France ».
Inversement, il ne semble pas y avoir de problème de référence non définie pour Cassini du type rappel <ref name="Cassini"/> sans définition, bien que le nombre de insource:/name\=\"?Cassini/ soit élevé.
Le règlement de la question des doublons dans les références passe par la nécessité d'avoir une cohérence (un rendu et un nom de référence identiques) dans le modèle « Population de France » et dans le modèle {{RefCassini-Ehess}} suggéré plus haut. Les name="Cassini_<numéroID (ou quelque chose d'autre de distinctif)>" sont requis pour faire un lien vers la page web Cassini d'une commune A dans l'article d'une commune B, ou plusieurs appels de {{RefCassini-Ehess}} dans une même page.
En partant du principe hypothétique que l'on n'a jamais deux appels du "modèle" « Population de France » sur une même page, il serait possible de conserver un simple name="Cassini" :
  • pour un appel sans paramètre de « Population de France ». L'idCassini étant alors celui défini dans le module de données associé (correspondance du titre) à l'article courant.
  • pour un appel de {{RefCassini-Ehess}}
    • soit sans paramètre.
    • soit avec un id (ou titre article, lire la suite) correspondant à celui de l'article courant (si ce dernier est associé à un module, avec id défini.
Explications. Vu que le(s) modèle(s) « Population de France » (et la base de sous-modules) fonctionnent à partir des titres des pages, il pourrait être intéressant de rendre possible l'utilisation de {{RefCassini-Ehess}} sans paramètre et {{RefCassini-Ehess|titre article=…}} au lieu de (ou comme alternative à) {{RefCassini-Ehess|id=…}}, le modèle sollicitant le sous-module existant. Idem éventuellement pour {{Cassini-Ehess}}. On garderait quand même le paramètre id valide pour les éventuelles localités sans article/module. Inconvénients de ce fonctionnement : 1. Code des modèles plus lourds avec passage en Lua, 2. Lors du renommage d'un article A et de son module, maintenance à faire dans les appels du modèle avec un paramètre titre article=A. Cependant, plus généralement, l'invalidité du paramètre titre article pourrait figurer dans une catégorie de maintenance, tout comme l'invalidité d'un appel sans module de données associé. Avantage : possibilité de mettre facilement dans le texte de la référence à la fois le nom de la commune et le bon lien externe, sans générer de problème d'unicité sur les "name" des ref.
Si j'ai bien lu les modules, l'adresse internet dans "source1" devrait toujours être une adresse vers le site Cassini, sauf en cas d'appel de module avec "division" = « commune en COM1 » (recherche, ce qui correspond à 35 cas – intitle:Données – dont 33 "source1=http://www.isee.nc" et deux autres liens web pour Miquelon et St Pierre). Si les autres adresses sont toutes sous la même forme (même racine), on peut effectivement, dans les modules de données remplacer le contenu des sources1 par les ID_Cassini (numéros dans les url) mais ne serait-il pas plus clair d'y définir une nouvelle entrée, avec, pour ce nombre, un nom explicite ? (N.B. pour la vérification il suffirait de se contenter des modules de données sans "division" ou avec une valeur différente de celles traitées à part dans la fonction p.sources des modules Module:Population de France/Sources et Module:Population/France.) La racine de l'url pourrait être définie en dur dans ces deux modules. @Zolo. À quoi sert le second ?
Notes au passage :
  • Pour une éventuelle utilisation des titres, il y a la particularité des modules Données/<numéroINSEE>/évolution population mais ceux-ci ne sont pas utilisés dans l'encyclopédie par le module qui affiche le lien "source1", sauf un exemple dans une documentation. Ils sont sollicité par « Population de France/dernière pop », …/dernière année, …/tableau, …/graphique.
  • Le lien externe sur "Calendrier départemental des recensements" établi dans le module:Population de France/Introductions est un lien mort. Faut-il le remplacer par https://www.insee.fr/fr/statistiques/fichier/2383265/Fichier_historique_2015_2021.xlsx ou autre chose ?
  • retrait contenu de la référence "Struct", à corriger peut-être ailleurs.
  • Exemple avec plusieurs références en double, c'est à dire avec des intitulés légèrement différents mais des url identiques : Démographie de Bordeaux-en-Gâtinais
  • @Roland,
    • Que contiennent les "source2" et "source3" des modules de données ? quels modèles les utilisent ?
    • Pourrais-tu préciser le « ainsi d'ailleurs que sur les modèles de données qui n'ont pas été transférés en modules » de ton dernier message. Est-ce que ce sont des insertions dans les articles pour lesquelles le contenu de la référence est définie en dur dans un paramètre de modèle ? ou bien des tableaux en dur, sans modèle ?
  • @LD. À la première lecture, je n'ai pas bien compris ce que serait {{NoteCassini-Ehess}}, la même chose qu'un {{RefCassini-Ehess|groupe=Note}}. Ou autre chose ? S'il s'agissait juste de renommer {{Cassini-Ehess}}, je n'en vois pas l'utilité, le « Note », n'étant pas très clair. Difficile choix du nom des modèles.
Ideawipik (discuter) 8 juillet 2021 à 21:50 (CEST)