Projet:Modèle/Demandes

< Projet:Modèle(Redirigé depuis P:MD)
Demandes/améliorations de modèles

Cette page regroupe les requêtes des modèles à construire ou améliorer. Si votre demande concerne une « Infobox », une « Palette » ou une « Boîte Utilisateur », veuillez consulter les projets respectifs.

Avant de faire une demande :

OOjs UI icon next-ltr-progressive.svg Ajouter une demande pour un modèle

OOjs UI icon next-ltr-progressive.svg Demander une infobox

OOjs UI icon next-ltr-progressive.svg Demander une palette

OOjs UI icon next-ltr-progressive.svg Demander une boîte utilisateur

Cette page est automatiquement archivée. Les sections répondues n'ayant aucune activité depuis 7 jours sont automatiquement déplacées.

Le modèle KML (et GeoGroup) ne marche plus bienModifier

Travail demandé par Jack ma ►discuter 26 janvier 2019 à 07:01 (CET)

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

Bonjour. Le modèle:KML ne marche plus sur les catégories et les listes d'articles géoréférencés (voir les exemples dans la documentation). Par exemple le lien OpenStreetMap dans :

Pour l'ensemble des points mentionnés sur la page Catégorie:Sommet en Belgique : voir sur OpenStreetMap (aide) ou télécharger au format KML (aide).

Il utilise le modèle sous-jacent {{GeoGroup}}, qui appelle kmlexport ou tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl. Le modèle correspondant sur le wiki anglais semble toujours fonctionner. Merci d'avance pour votre aide. Personnellement, je ne me sens plus de taille à maintenir ce modèle partique et utile. Si quelqu'un sait le remettre en marche, ce serait super. Cordialement,

Vérification création modèleModifier

Travail demandé par Bouzinac (discuter) 4 juin 2019 à 15:41 (CEST)

  • Avancement :
    0 %
  • Détails de la demande : Bonjour, j'ai créé un modèle {{Aéroport-Statistiques}} et avant de le déployer un peu partout, j'aimerais qu'un œil averti regarde le code et voir s'il y a d'éventuelles optimisations possibles
  • Article(s) pour le modèle : Exemple de rendu :

Voir la requête brute et les sources sur Wikidata.

  • Discussions :

Bonsoir Bouzinac   Je vois que tu as déployé ce modèle et j'ai donc supprimé le bandeau {{en travaux}}. Je me suis également permis de supprimer les sauts de lignes inutiles. --FDo64 (discuter) 20 janvier 2020 à 22:08 (CET)

Salut FDo64 (d · c · b) euh oui merci, mais comme le modèle Graph (cf https://www.mediawiki.org/wiki/Extension:Graph/fr ) ne fonctionne pas pour taper dans Wikidata, et bien... ce n'est juste qu'un lien pour obtenir de la donnée. Mais si tu avais une meilleure idée pour représenter visuellement un graphique avec données Wikidata régulièrement màj ...? --Bouzinac (discuter) 20 janvier 2020 à 23:08 (CET)
  Bouzinac : Aucune idée. Je rouvre donc la requête puisque ton modèle ne fonctionne pas… --FDo64 (discuter) 20 janvier 2020 à 23:11 (CET)
Bonsoir Bouzinac  . Je reviens vers toi pour deux remarques :
  1.   Simon Villeneuve : a développé le modèle:Wikidata list. Peut-être saura-t-il t’aider ?
  2. Comme j’avais un doute, j’ai consulté Wikipédia:Utilisation de données Wikidata dans les articles et ce modèle entre bien dans la catégorie « Parties des articles où des données Wikidata peuvent être utilisées (…) dans les tableaux, histogrammes et autres graphiques de présentation de données ».
--FDo64 (discuter) 21 janvier 2020 à 22:19 (CET)

Création Modèle:Tournoi sur 5 tours et 6 toursModifier

Travail demandé par William Jexpire (discuter) 29 septembre 2019 à 22:35 (CEST)

Modèle:Graphique démographiqueModifier

Travail demandé par Roland45 (discuter) 23 janvier 2020 à 16:47 (CET)

  • Avancement :
    0 %
  • Détails de la demande : Le modèle:Graphique démographique a été créé il y a quelques années (2014). Quantd il est utilisé, il est couplé avec un tableau permettant de visualiser les données. Une amélioration qui me paraîtrait utile si on veut s’affranchir d’afficher ce tableau de données (lourd visuellement quand il y a beaucoup de données) serait d’afficher les données en infobulles. Comme on peut le voir dans ce graphiques de l’université de Sherbrooke.
    Cette amélioration parait-elle faisable ? et si oui merci par avance à celui qui voudra bien se pencher sur le sujet. Cela constituerait un pas considérable pour tous les graphiques (pas uniquement de population). Cordialement.
  • Discussions :

Boîte déroulante fonctionnelle pour mobileModifier

Travail demandé par — Cantons-de-l'Est p|d|d [‌sysop] 5 février 2020 à 02:26 (CET)

  • Avancement :
    0 %
  • Détails de la demande : {{boîte déroulante}} fonctionne bien si la page est consultée avec un portable ou un ordinateur de bureau. Si elle est consultée avec un smartphone (donc via fr.m.wikipedia.org), la boîte déroulante est toujours déroulée et aucun bouton n'apparaît pour la faire enrouler. J'ai essayé une boîte déroulante avec les classes mw-collapsible, mw-collapsed et mw-collapsible-content (tel que recommandé dans [1]), mais le même problème persiste. Pourtant, la table des matières (appelée « Sommaire » pour les smartphones) réagit comme une boîte déroulante « normale ». Merci de vous pencher sur ce problème, peu importe s'il y a une solution ou pas.
  • Article(s) pour le modèle : ...; ...; ...
  • Discussions :
+1, je l'avais déjà demandé en page de discussion et c'est vrai que certaines pages (notamment en dehors de l'espace encyclopédique) peuvent vite devenir illisible sur mobile à cause de ces boites déroulées... -- Nemo Discuter 24 mars 2020 à 19:50 (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 Infobox LivreModifier

Travail demandé par Auctores varii (discuter) 24 mai 2020 à 21:31 (CEST)

  • Avancement :
    0 %
  • Détails de la demande : Pourrait-on ajouter à ce modèle les 3 paramètres suivants, demandés sur la page de discussion du modèle ?
    • un paramètre permettant d'afficher le lien vers Wikilivres quand il existe ;
    • un paramètre permettant d'afficher le nom de l'illustrateur/illustratrice de l'édition originale quand l'édition en français n'est pas illustrée par le même artiste, voire pas illustrée du tout ;
    • un paramètre permettant d'afficher le nombre de mots d'un roman, plus parlant que le nombre de pages, qui change en fonction de très nombreux paramètres.
  • Article(s) pour le modèle : {{Infobox Livre}}
  • Discussions :

Ces demandes existent sur la page de discussion du modèle — qui n'est pas, disons-le, très fréquentée^^ — certaines depuis plusieurs mois. C'est pour cette raison que je me permets de les reporter ici. Merci d'avance pour votre travail^^
Auctores varii (discuter) 24 mai 2020 à 21:31 (CEST)

Bonjour Auctores varii  , la page du modèle étant en semi-protection, je n'ose pas trop y toucher s'il n'y a pas de consensus concernant l’intérêt de ces ajouts. Peut-être faudrait t-il initier une discussion sur le projet:Littérature ? Noritop      24 août 2020 à 18:41 (CEST)

Masquer certaines infos en fonction affichage mobile/PCModifier

Travail demandé par Bouzinac (discuter) 29 mai 2020 à 15:59 (CEST)

  • Avancement :
    0 %
  • Détails de la demande : Bonjour, existe-t-il un paramètre qui permettrait d'afficher, soit l'ensemble des points, soit les points jugés les plus importants en fonction de si ça s'affiche sur un tél mobile ou sur un PC ? L'idée est de :
    • simplifier si mobile, c'est à dire afficher seulement X, Y, Z ,
    • compléter si PC fixe, c'est à dire afficher X,Y,Z,A,B,C etc.
  • Article(s) pour le modèle : {{Carte/Aéroports en Amérique du Sud/Brésil}}
  • Discussions :

Modèle "inflation" indexé sur le PIB ?Modifier

Travail demandé par rob1bureau (discuter) 28 juin 2020 à 14:48 (CEST)

  • Avancement :
    0 %
  • Détails de la demande : Bonjour, selon https://en.wikipedia.org/wiki/Template:Inflation, l'inflation des dépenses publiques (entre autres) devrait être calculée sur la base du PIB et non sur l'indice des prix à la consommation. Or, s'il existe un modèle:Inflation pour ce dernier cas, je n'ai pas trouvé d'équivalent pour le premier. Si l'info est exacte (je ne suis pas économiste), je pense que ce serait très utile. (A noter qu'il existe un Modèle:PIB Arménie TAB.)
  • Article(s) pour le modèle : tous les articles où on indique un prix passé devant être calculé de cette manière (j'ai découvert la question en voulant indiquer le prix unitaire du Lockheed SR-71 Blackbird, faute de mieux j'ai utilisé le modèle inflation).
  • Discussions :

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

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)

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

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)

Infobox TraitéModifier

Travail demandé par Bouzinac (discuter) 21 novembre 2020 à 13:58 (CET)

  • Avancement :
    0 %
  • Détails de la demande : Modernisation de {{Infobox Traité}} : pouvoir s'appuyer sur du wikidata si le champ est vide côté frwiki.
  • Article(s) pour le modèle : Traité_de_Managua_(1860)
  • Discussions :

À celui qui traitera cette demande : en regardant les données qui pourraient être récupérées dans Wikidata pour le Traité de Versailles, je n'en ai trouvé que très peu :

  1. image (P18)
  2. type (P31)
  3. langues (P407)
  4. date_de_signature (P585)
  5. dépositaire (P2058)

Pour ce qui est des signataires, il y a bien P1891 mais sans distinction des parties, donc inexploitable.

  Bouzinac : Si tu vois d'autres données, merci de les signaler. En l'état, je ne suis pas persuadé par cette demande.

--FDo64 (discuter) 11 décembre 2020 à 00:13 (CET)

Changer l'alternance d'un tableauModifier

Travail demandé par --Nebuno (discuter) 8 janvier 2021 à 21:55 (CET)

  • Avancement :
    0 %
  • Détails de la demande : Bonsoir, j'aimerais changer l'alternance du tableau du modèle:Fstats qui pose notamment problème avec les sous-totaux gris. J'ai travaillé sur un exemple de tableau avec une alternance blanche/bleue et je trouve le résultat satisfaisant. À noter que sur la partie parcours au Real Madrid, la non alternance sur la colonne Saison est faite à dessein afin de comparer les différentes possibilités. Je pense aussi qu'il serait bien d'appliquer la couleur blanche sur la colonne Club sachant que le paramètre rowspan est possible.
Saison Club Championnat Coupe(s) nationale(s) Compétition(s) continentale(s) Total
Division M B Pd M B Pd C M B Pd M B Pd
2004-2005   Boca Juniors Primera División 15 0 0 - CL 1 0 0 16 0 0
2005-2006   Boca Juniors Primera División 34 0 3 - RS+CS 2+6 0 0 42 0 3
2006-2007   Boca Juniors Primera División 21 1 2 - RS+CS 2+1 0 0 24 1 2
Sous-total 70 1 5 0 0 0 - 12 0 0 82 1 5
2006-2007   Real Madrid Liga 13 0 1 2 0 0 C1 2 0 0 17 0 1
2007-2008 Liga 31 0 2 5 0 1 C1 6 0 1 42 0 4
2008-2009 Liga 26 1 7 1 0 0 C1 6 0 0 33 1 7
2009-2010 Liga 18 0 1 2 0 0 C1 2 0 0 22 0 1
2010-2011 Liga 4 0 0 3 0 0 C1 - 7 0 0
Sous-total 92 1 11 13 0 1 - 16 0 1 121 1 13

Je cite une partie de la réponse que m'a apporté Ideawipik sur le Café du foot :

  • Solution 4, hypothétique, à étudier : utiliser un CSS qui va bien, en définissant des classes et des règles. Pas sûr que ce soit
    • effectif sur tous les navigateurs pour les lecteurs ;
    • possible sans changer la structure du tableau (code des articles) qui est un facteur limitant ;
    • possible en pur CSS, sans recourir à du JavaScript. Le sélecteur :nth-of-type ne convient pas. Il était envisagé de développer un sélecteur « E:nth-child(n [of S]?) » ([2]). Mais l'option n'a pas été ajoutée. Auquel cas en définissant une classe pour les lignes du tableaux (autres que les sous totaux, dans le modèle), une syntaxe du type tr:nth-child(even of .classeFstatsligne) {background: red;} dans une feuille de style, en sous-page du modèle, aurait pu servir. Ou inversement, une classe à exclure pour les sous-totaux. Autre idée : peut-être voir les successions « classesoustotal + classeFstatsligne », pour réinitialiser à une couleur claire après chaque ligne de sous-total, indépendamment de ce qui la précède, et « classeFstatsligne + classeFstatsligne » pour les autres successions de saisons, avec alternance.

Bonne soirée.

  • Article(s) pour le modèle : Tous les articles de footballeurs et de handballeurs ayant un tableau de statistiques, donc énormément.
  • Discussions :

Outil pour sourcer pour l’éditeur normalModifier

Travail demandé par TED 19 janvier 2021 à 05:17 (CET)

  • Avancement :
    0 %
  • Détails de la demande : Bonjour ! Il existe en mode « éditeur visuel » un outil pour créer des sources à partir d’un lien http, un ISBN, un DOI ou autre… mais cet outil n’est pas disponible avec l’éditeur normal. Serait-il possible de l’ajouter ? TED 19 janvier 2021 à 05:17 (CET)
(NB : ne sachant pas exactement où poser cette question, je l’ai posée aussi là : Discussion Projet:Scripts et gadgets/Demande de fonction#Outil pour sourcer pour l’éditeur normal) TED 20 janvier 2021 à 20:24 (CET)
  • Article(s) pour le modèle : potentiellement tous.
  • Discussions :
@Thomasbr33, vu que tu sembles pouvoir créer des gadgets similaires, je me permets de te notifier sur cette demande. LD m'écrire 29 juin 2021 à 16:10 (CEST)
  LD : Yep merci je vais voir ce que je peux faire, mais je ne garantis rien   --Thomasbr33 (discuter) 29 juin 2021 à 17:20 (CEST)

Conventions typographiques et modèle/module LangueModifier

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

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

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)

Traduction des modèles "series overview" et "episode table"Modifier

Travail demandé par RdNetwork (discuter) 31 mai 2021 à 20:08 (CEST)

  • Avancement :
    0 %
  • Détails de la demande : Bonjour, en travaillant sur l'article Last Week Tonight with John Oliver qui a besoin d'une grosse mise à jour, je me suis aperçu que le modèle actuel de "liste des épisodes" était globalement inutilisable avec l'éditeur visuel, et manquait de fonctionnalités face aux très bons modèles du wiki anglais (et traduits dans beaucoup d'autres wiki) que sont Series overview et Episode table.

Je ne sais toutefois pas du tout comment marchent les modules en général et comment en "traduire" ou en importer un de Wiki étrangers. Serait-il donc possible de récupérer ces modèles très pertinents pour faire (re)vivre les articles "médiatiques" du Wiki FR qui sont parfois un peu vétustes ?

Merci d'avance pour votre aide ! :)

Cordialement, RdNetwork (discuter)

  • Article(s) pour le modèle : Tous les articles d'émissions ou de séries TV, donc sans doute plusieurs milliers ?
  • Discussions :

Bonjour RdNetwork. Pour comprendre, en quoi le modèle {{Liste des épisodes}} serait-il inutilisable avec l'éditeur visuel ? La liste des paramètres valides est bien renseignée dans la documentation du modèle (Aide:TemplateData). Sur les nombreuses utilisations du modèle, très peu présentent un paramètre erroné. Cf « Liste des épisodes » sur wstat.fr.

Éditorialement, avant de modifier ou de remplacer des modèles, il serait bien d'en discuter avec les projets thématiques concernés (ceux des Portail:Télévision et Portail:Médias), afin que soient évalués collectivement votre proposition et les bénéfices de l'évolution envisagée. Cordialement. — Ideawipik (discuter) 31 mai 2021 à 21:40 (CEST)

Merci pour votre retour ! Je vais essayer d'être assez clair car je ne suis pas bien sûr de comprendre moi-même mon souci.
J'ai fini par comprendre que le modèle "Liste des épisodes" ne s'utilisait qu'au sein d'un tableau et j'ai donc essayé de l'utiliser moi-même sur la page que je souhaitais modifier. La liste d'épisodes existante utilise en effet un tableau avec pour chaque épisode une occurrence du modèle. Toutefois, si j'arrive à éditer les propriétés du tableau et ses "headers", je n'arrive pas à éditer les occurrences individuelles de chaque épisode avec l'éditeur visuel. A aucun moment l'infobulle indiquant que je veux modifier un modèle n'apparait, contrairement à celle pour le Tableau qui apparaît quand je clique sur la première ligne du tableau contenant chaque modèle. J'ai beau double-cliquer sur un titre ou un résumé, tout reste en lecture seule...
C'est cela qui me poussait à croire que ce modèle n'était pas tout à fait compatible avec l'éditeur visuel. Il est possible que je n'aie tout simplement pas trouvé la bonne manipulation à faire pour éditer le modèle. Y a-t-il une solution ?
Cordialement,
RdNetwork (discuter) 31 mai 2021 à 22:10 (CEST)
  RdNetwork. Vous avez bien cerné le problème. Il s'agit donc d'une question de tableaux dont les lignes sont générées par des modèles*. Vous remarquerez que pour utiliser « Episode table », générant un tableau, sur enwiki (Wikipédia en anglais), il est également nécessaire de rentrer les lignes du tableau ({{Episode list|…}}) en wikicode dans le paramètre episodes du premier modèle, puisque ce n'est pas faisable, récursivement (modèles imbriqués), avec l'outil d'insertion des modèles intégré à l'éditeur visuel. Je vous conseille, pour les opérations sur ces tableaux de changer temporairement d'éditeur et de copier le patron du modèle « Liste des épisodes » dans sa documentation. Il est possible de basculer à tout moment entre les deux éditeurs au cours de la rédaction. Rédiger en wikicode (Aide:Syntaxe) n'est pas aussi compliqué que cela puisse paraître au premier abord et la possibilité de prévisualiser avant d'enregistrer est bien pratique.
* Note : pour les tableaux générés intégralement par des modèles successifs, comme les tableaux des footballeurs ({{Fstats}} et consorts), l'éditeur visuel est capable de demander individuellement tous les paramètres de chaque modèle intérieur. Cela a le mérite de fonctionner même si ce n'est, à mon avis pas plus pratique qu'en wikicode. Vous pouvez tester dans un des articles incluant le modèle, sans enregistrer bien sûr. Dans le cas présent, peut-être qu'en créant un modèle paramétré (intitulé par exemple « Modèle:Liste des épisodes/Début ») ayant pour fonction de générer l'en-tête (header) du tableau, un fonctionnement similaire serait possible. On peut essayer, dans les prochains jours, si vous le voulez.
PS : je me suis permis d'indenter votre message conformément à l'usage dans les discussions (en faisant débuter, en wikicode, les lignes par des « : » incrémentés. Voir l'aide.)
PPS. Je ne suis pas de retour.  .
Cordialement. — Ideawipik (discuter) 31 mai 2021 à 23:47 (CEST)

Demande de modifications sur le modèle Résultats électorauxModifier

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:lang-ruModifier

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

Modules pour les populations des communes de FranceModifier

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)

Modèle « Article » : paramètre accès urlModifier

Travail demandé par Ariel (discuter) 6 juillet 2021 à 08:19 (CEST)

  • Avancement :
    0 %
  • Détails de la demande : Le modèle « Article » comporte depuis peu le paramètre accès url (valeurs autorisées : libre, inscription, limité et payant). Il faudrait que ce paramètre induise un affichage, non seulement quand le paramètre lire en ligne est renseigné, mais aussi quand c'est le cas du paramètre doi. Le doi est en effet définitif alors que l'url peut changer (réorganisation du site web du périodique, à la suite d'une fusion, d'une scission, d'un rachat ou même d'un simple problème technique) : quand le doi existe il est déconseillé de mettre aussi l'url (qui au mieux fait doublon, au pire devient fausse).
  • Article(s) pour le modèle : Tous articles de sciences (inhumaines aussi bien que molles)
  • Discussions :
Bonjour Ariel. Ce point (WP:Accès url) concerne tant le modèle article « Article » que « Ouvrage », « Chapitre », « Lien web » (j'en oublie peut-être) qui passent tous par le module:Biblio.
Voici d'autres questions :
  1. Faut-il décliner le paramètre "accès url", en fonction des catalogues ou bibliothèques, afin que le cadenas informatif soit placé à côté du lien concerné ? Lire aussi Discussion modèle:Ouvrage#Accès URL. On est d'accord que le DOI est un élément un peu à part. Il faudra éviter les guirlandes de cadenas.
  2. Faut-il ajouter une gestion des "accès url" dans le modèle {{Lire en ligne}} ? dans le modèle {{Bibliographie}} ?
Ideawipik (discuter) 6 juillet 2021 à 09:57 (CEST)
Tu as raison, j'oubliais que les ouvrages et même les liens web pouvaient aussi avoir un doi. Je pense que le cadenas doit être affiché dès que l'un au moins des paramètres lire en ligne et doi est renseigné. Le cadenas peut être différent pour le doi et pour le lien direct (qui peut être sur le site d'une université, par exemple) donc il faudrait un cadenas pour chacun des deux paramètres (et donc des tests indépendants). La redondance devrait être évitée parce qu'on ne devrait jamais renseigner le paramètre lire en ligne quand il renvoie à la même adresse que le doi (et peut devenir obsolète), il faudrait à mon sens rajouter cette recommandation aux docs.
Quant au modèle Lire en ligne, dont j'ignorais l'existence, oui, il faudrait lui ajouter le paramètre accès url. — Ariel (discuter) 6 juillet 2021 à 10:38 (CEST)

Modèle BiographieModifier

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)

Réf Bible : auteur=RabbinatModifier

Travail demandé par — Valp 1 octobre 2021 à 15:14 (CEST)

Bonjour Valp. Le modèle pourrait utiliser le modèle {{Ouvrage}} ou {{Lien web}}.
Veux-tu un modèle avec des paramètres {{Réf Bible Rabbinat|livre=|paracha=|chapitre=|verset=}}. « paracha » serait facultatif, utilisé seulement pour le libellé du lien/titre, pas pour l'adresse internet.
Faut-il prendre en compte aussi la « collection » (Pentateuque, Prophètes, Hagiographes) ? Pour le passage donné en exemple, en plus des deux adresses valides données ci-dessus, on a aussi la suivante : « https://www.sefarim.fr/Pentateuque_Genèse_10_8.aspx ». Quel est le format le plus universel ?
Note technique, il faudra dans le modèle penser à remplacer les espaces éventuels par des %20 (utile par exemple pour « Rois 2 », module String).Ideawipik (discuter) 1 octobre 2021 à 19:37 (CEST)
Bonjour Ideawipik   et merci de votre réponse.
Je crois que le mieux serait un modèle comme les autres (ici) : {{Réf Bible|livre|chapitre|verset|auteur=Rabbinat}}.
Renvoyant à www.sefarim.fr OU à Wikisource Bible du Rabbinat.
Cordialement — Valp 2 octobre 2021 à 16:24 (CEST)
Rebonjour Ideawipik
STOP ce modèle existe ! Mais il n'est pas documenté là où il faut ! Voyez par exemple {{Réf Bible|Josué|10|35|auteur=Rabbinat}}=Js 10,35
Valp 2 octobre 2021 à 18:01 (CEST)
Bonjour Valp. Oups, ma faute. J'aurais dû lire tous les liens. Merci pour les précisions et l'ajout à la documentation. {{Réf Bible|Genèse|10|8|auteur=Rabbinat}} (Gn 10,8) correspond à ton exemple initial. Cela convient-il ? S'il manque des livres, dans le modèle, il est possible de les paramétrer dans {{Livre de la Bible sur Wikisource}}. On abandonne l'idée d'utiliser www.sefarim.fr ? Est-ce que Wikisource est suffisant et exhaustif ? Cordialement. — Ideawipik (discuter) 2 octobre 2021 à 18:33 (CEST)
Bonsoir Ideawipik,
Wikisource paraît complet et correct pour ce que j'en ai vu. Par contre le paramètre extra-long de |display= du modèle {{Réf Bible |auteur=Rabbinat}} ne fonctionne pas.
Quant à Sepharim, c'est une très belle édition électronique, bilingue, et {{Réf Bible |auteur=Sepharim}} ferait un beau modèle, à mon avis.
Par curiosité, pourriez-vous me montrer comme un modèle comme {{Réf Bible}} est codé ?
Cordialement — Valp 2 octobre 2021 à 21:06 (CEST)
Bonsoir Valp. Réponse apportée sur votre page de discussion. Faites juste savoir si un modèle dédié, hors de {{Réf Bible}}, par exemple {{Réf Sepharim}} ou {{Réf Bible Sepharim}} serait utile pour des liens externes vers le site.
Dans {{Réf Bible}}, avec le paramètre display à la valeur « extra-long », l'url était bonne mais le libellé affiché était toujours identique à celui généré pour auteur=Segond, quel que soit l'auteur. Le plus simple, à court terme, est d'ajouter un paramètre « auteur » au modèle {{Livre de la Bible}} et de rendre Rabbinat mais aussi Darby et Crampon valides dans {{Livre de la Bible sur Wikisource}} ce qui est déjà le cas pour beaucoup de livres (tous ?) ex. : {{Livre de la Bible sur Wikisource|Gn|auteur=Rabbinat}} (Bible du Rabbinat 1899/La Genèse) fonctionne déjà. La modification effectuée requiert une exhaustivité des livres pour chaque auteur dans ce dernier ou le passage à un autre fonctionnement*. Cependant, si la modification faisait apparaître un problème d'affichage quelque part, cela correspondrait à un appel pour lequel le lien généré était déjà invalide.
Exemple d'application, après la modification : {{Réf Bible|Genèse|10|8|auteur=Rabbinat|display=extra-long}} (Bible du Rabbinat 1899/La Genèse 10,8). N'hésitez pas à tester.
Note *. Je n'y ai pas touché mais le titre "extra-long" pour le modèle {{Livre de la Bible}} doit-il être par exemple « Bible Segond 1910/Évangile selon Jean » (rendu actuel) ou simplement « Évangile selon Jean ». En faisant sortir l'auteur du titre "extra-long", on pourrait ajouter son nom directement dans le libelle du lien depuis le modèle principal et ainsi simplifier légèrement le modèle {{Livre de la Bible}}. Mais cela reste un détail.
On peut aussi s'étonner des disparités sur wikisource, dans la formation des titres utilisés pour la version "extra-longue", auteur parfois au début, parfois à la fin, séparateur tantôt « / », tantôt « - ».Ideawipik (discuter) 3 octobre 2021 à 20:34 (CEST)
Bonsoir Ideawipik.
Merci pour le display=extra-long "Bible du Rabbinat 1899/La Genèse 2,3". Je l'ai documenté dans Réf Bible. J'aurais préféré "Bible du Rabbinat 1899, Genèse 2,3", avec virgule plutôt que barre, et sans l'article défini devant le nom du livre, article superfétatoire et non standard, mais c'est quand même bien. J'ai répondu sur l'autre page de discussion. Cordialement — Valp 3 octobre 2021 à 22:03 (CEST)

Géolocalisation du SinaïModifier

Travail demandé par Ellicrum {bablute [...]} 1 novembre 2021 à 15:49 (CET)

✔️ Modèle hors sujet pour le forum de relectureModifier

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)

Création de numéro de lignes pour le transport urbain de RoanneModifier

Travail demandé par Modifroanne42