Projet:Modèle/Demandes

Données clés
	Aide et syntaxe • FAQ
	Liste • Modèles spéciaux
	Aide:Modèles courants
	ParserFunction • Mots magiques
	Espace Modèle
	Demander un modèle
	Modèle • Apparence
	Projet d’harmonisation
	Qu'est-ce qu'une palette de navigation ?
	{{Méta palette de navigation}}
	Palette de navigation
	Projet palette
	Qu'est-ce qu'une infobox ?
	Demander une infobox
	Apparence
	Modèle infobox
	Projet infobox
	Qu'est-ce qu'un bandeau ?
	Liste des bandeaux de maintenance
	Liste des bandeaux d'avertissements permanents
	Wikidata

Demandes/améliorations de modèles

Raccourci [+]

P:MD

Archives

Archives de l'année :

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 :

consultez la liste des principaux modèles : Liste des modèles ;
vous pouvez rechercher un modèle avec notre moteur ou un externe.

Ajouter une demande pour un modèle

Demander une infobox

Demander une palette

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.

Modules pour les populations des communes de France

Travail demandé par LD ^{• m'écrire •} 29 juin 2021 à 16:08 (CEST)[répondre]

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)[répondre]

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)[répondre]

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)[répondre]

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)[répondre]

@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 :

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.
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)[répondre]

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é :

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 ;
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.
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
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é.
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)[répondre]

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)[répondre] ┌─────────────────────────────────────────────────┘

@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)[répondre]

@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)[répondre]

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)[répondre]

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)[répondre]

Modèle « Article » : paramètre `accès url`

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

Avancement :
91,54 %
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 :

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.
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)[répondre]

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)[répondre]

Bonjour Ariel. Pour information, aux lecteurs de cette section, des paramètres « accès doi » et « accès hdl », associés respectivement aux « doi » et « hdl », ont été ajoutés aux modèles bibliographiques comme Article, Ouvrage, Chapitre ou Lien web. Les documentations sont encore incomplètes.

Le second point reste à faire. C'est peut-être l'occasion de passer {{Lire en ligne}} en Lua. Il existe déjà des fonctions Biblio.enLigne dans Module:Biblio/Références et References.enLigne dans Module:Biblio/Références qui pourraient servir. — Ideawipik (discuter) 31 mars 2022 à 23:47 (CEST)[répondre]

Bonjour Ariel Provost et Ideawipik, j'ai complété les documentations (voir Utilisateur:Vega/Brouillon2), avec quelques réserves :

j'ai ajouté la ligne <code id="doi accès">accès doi</code> et la suivante à {{Lien web}}, à vérifier svp ;
si tout est correct, je compléterai le template data et la doc sur {{Lire en ligne}} et sur {{Chapitre}} (où il manque « hdl »).

J'ai aussi ajouté une mention à {{Lien web}} et {{Article}} à propos de la redondance URL/DOI ; si elle vous convient, je compléterai de même Chapitre et Ouvrage.

En passant, ce ne serait pas l'occasion d'uniformiser "résumé" et "présentation en ligne" entre Article et Chapitre/Ouvrage respectivement, qui y sont inversement des alias ? — Vega (discuter) 23 juin 2022 à 19:50 (CEST)[répondre]

Hello @Ariel Provost, @Ideawipik et @Vega, je sais que le DOI peut être redondant avec l'url, mais même quand les deux adresses sont identiques, c'est bien pratique d'avoir les deux : le doi parce qu'il stable, et l'url parce qu'il est pratique d'en faire un c/c quand on a besoin de vérifier le contenu d'une source sans quitter la page en cours. --Pa2chant.bis (discuter) 12 juin 2023 à 11:17 (CEST)[répondre]

Réf Bible : auteur=Rabbinat

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

Avancement :
30 %
Détails de la demande :
Pour de nombreuses références à la Bible, la version hébraïque est utile. Un excellent site existe : https://www.sefarim.fr/
Il semble peu difficile de créer des liens vers cette version, puisque son url est de type paramètres séparés par "_" comme : https://www.sefarim.fr/Genèse_Noa'h_10_8.aspx ... où "Noa'h" peut être remplacé par "%20"
Quelqu'un pourrait-il s'en occuper ou me montrer comment faire ? Cordialement — Valp 1 octobre 2021 à 15:14 (CEST)[répondre]
Article(s) pour le modèle : Bible du Rabbinat ; Modèle:Réf_Bible ; ...
Discussions :

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)[répondre]

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)[répondre]

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)[répondre]

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)[répondre]

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)[répondre]

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)[répondre]

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)[répondre]

Bug dans le modèle {{Stations voisines}}

Travail demandé par Bouzinac (discuter) 10 mars 2022 à 13:12 (CET)[répondre]

Avancement :
0 %
Détails de la demande : Cf Modèle:Stations_voisines/Documentation#Bugs_connus_à_résoudre : il se peut parfois qu'une station de métro ne soit desservie que dans un seul sens. Exemple de Gulleråsen, cf cette carte. Je ne sais trop comment prendre le problème, s'il faut affiner côté Wikidata ou ajouter une règle de gestion dans le lua du module associé au modèle (ou probablement un peu des deux). Actuellement le modèle part de deux postulats : soit la station est un terminus, soit elle est entre deux stations. Merci pour vos idées !
Article(s) pour le modèle : Gulleråsen (métro d'Oslo)
Discussions :

Bonjour Bouzinac

, quel affichage attends-tu du modèle {{Stations voisines}} ? Lepticed7 (Viens tcharer ! :D) 19 avril 2023 à 02:56 (CEST)[répondre]

Bonjour, j'avais complètement oublié cette demande.

Dans l'exemple de Gullerasen, peut être lire un très petit texte "(ne prend pas de voyageur)" juste en dessous de Gråkammen si le qualifier P5051 n'est pas présent ou a la valeur "aucune valeur" ? Bouzinac (discuter) 19 avril 2023 à 10:21 (CEST)[répondre]

@Bouzinac Bonjour. Il semble que ça soit la seule station qui soit représentée de la sorte sur Wikidata et qui n’est pas sur une boucle. À moins de pouvoir identifier une autre station de métro dans le même cas (station sur une ligne linéaire desservi que d’un côté), le plus simple serait peut-être de modifier le modèle côté WP plutôt que de réfléchir à la modélisation sur WD. Je vais fouiller un peu. Ça laisse à d’autres le temps de donner leurs avis. Lepticed7 (Viens tcharer ! :D) 19 avril 2023 à 11:31 (CEST)[répondre]

SELECT distinct ?rezoLabel ?station ?stationLabel ?subwayLineLabel ?predLabel ?towardsLabel  WHERE {
?search wdt:P527|wdt:P121 ?lignes.#Quelles sont les lignes de ce métro
?lignes wdt:P5817 wd:Q55654238.#Lignes qui fonctionnent
?lignes wdt:P559 ?termini.#Quels sont les terminus de ce métro
?station wdt:P31/wdt:P279* wd:Q928830; #station de métro ou assimilé
wdt:P5817 wd:Q55654238;#Qui fonctionnent
 wdt:P31 wd:Q108667555; #station de métro à sens unique
 wdt:P16 ?rezo;#Qui font partie du réseau recherché
 wdt:P81|wdt:P1192 ?subwayLine; wdt:P197 ?pred.
 ?pred wdt:P625 ?coords_pred; wdt:P81|wdt:P1192 ?subwayLine_pred.#station précédentes et suivantes
 ?station p:P197 _:b1.
 _:b1 ps:P197 ?pred ; pq:P5051 ?towards;
 pq:P81|pq:P1192 ?line_pq. 
 ?pred wdt:P5817 wd:Q55654238.#Voisines qui fonctionnent
 optional{?subwayLine wdt:P1671 ?line_number.}#Numéro alphanumérique de la ligne de métro
FILTER(?subwayLine_pred = ?lignes)#On ne prend les lignes que si la correspondance est sur la même ligne
FILTER(?subwayLine = ?lignes)#On ne prend les lignes que si la station est sur la même ligne
FILTER(?subwayLine = ?line_pq)#On ne prend les lignes que si la station voisine est sur la même ligne que la station
FILTER(?towards = ?termini) #On ne prend que les directions, problématique : comment n'en choisir qu'une seule
SERVICE wikibase:label { bd:serviceParam wikibase:language "fr".
 } } 
order by ?rezo xsd:decimal(?line_number ) ?line_number ?subwayLine

Cliquez pour essayer ! Bouzinac (discuter) 19 avril 2023 à 12:40 (CEST)[répondre]

Modification du modèle « Température »

Travail demandé par Ariel (discuter) 3 mai 2022 à 09:47 (CEST)[répondre]

Avancement :
0 %
Détails de la demande : Actuellement le modèle « Température » (1) accepte différents symboles d'unité, (2) affiche la température en °C, et (3) montre par survol de la souris sur le ou les nombre(s) la valeur correspondante en °F et K. Je formule deux demandes distinctes mais cohérentes consistant à modifier le point n^o 2 optionnellement et le point n^o 3 systématiquement.
- Affichage de la température (point n^o 2) : il faudrait ajouter au modèle un paramètre optionnel permettant de garder à l'affichage le symbole d'unité utilisé dans l'appel au modèle (et donc de ne pas effectuer la conversion en °C). Ce serait utile pour les kelvins dans un contexte thermodynamique (notamment lors de l'usage de nombres ronds ou de très basses températures comme 300 K et 2,3 K (le modèle « Unité » n'offrant pas la conversion — souvent utile — par survol de la souris) et pour les autres unités dans un contexte géographique (°F) ou historique (°Ré, etc.).
- Survol de la souris (point n^o 3) : en cohérence avec la demande précédente, il faudrait afficher systématiquement la température dans les unités actuellement en usage dans la francophonie (°C, °F et K) s'il est bien vrai que les Canadiens francophones utilisent parfois les degrés Fahrenheit (seulement °C et K dans le cas contraire). On peut trouver bizarre d'éventuellement inclure la valeur qui s'affiche mais ce n'est pas très grave, et ce serait trop compliqué de demander au modèle de modifier l'effet du survol en fonction de ce qui est demandé pour l'affichage.
Article(s) pour le modèle : (innombrables)
Discussions :

Bonjour, n’y gagnerait-on pas à transformer en Lua ce modèle ? Dans tous les cas, il faudra l’intervention d’un·e admin, le modèle est protégé. Lepticed7 (Viens tcharer ! :D) 19 avril 2023 à 11:35 (CEST)[répondre]

Modèle:Ouvrage

Travail demandé par J. N. Squire (discuter) 12 juin 2022 à 15:37 (CEST)[répondre]

Avancement :
0 %
Détails de la demande : Importé de Discussion modèle:Ouvrage

Bonjour,

Actuellement, seul le titre peut être traduit en français. Serait-il possible d'ajouter au modèle les paramètres manquants ("traduction sous-titre", "traduction titre volume", "traduction titre collection", "traduction titre série", "traduction titre chapitre") s'il-vous-plait ?

Merci d'avance.

Article(s) pour le modèle : Takatāpui ; etc. (modèle massivement utilisé)
Discussions : Discussion modèle:Ouvrage#Traduction pour les sous-titres, titres de volumes, de séries, de chapitres et de collection ?

Traduction du modèle Plantilla:Gráfico de audiencias en televisión (es) en français

Travail demandé par DesPsyCHo (discuter) 13 juillet 2022 à 11:51 (CEST)[répondre]

Avancement :
0 %
Détails de la demande :

Bonjour, Je souhaiterais un assistance pour la traduction du modèle Plantilla:Gráfico de audiencias en televisión (es) vers le français. Il m'a été conseillé de vérifier s'il était possible de rapatrier le module Módulo:Gráfico de audiencias en televisión (es) vers le wiki-fr, ce qui permettrait de n'avoir à traduire que la documentation. Merci pour votre aide.

Article(s) pour le modèle : Tiempos de guerra (es) ; La que se avecina (es) ; ...
Discussions :
Bonjour DesPsyCHo. Au-delà de l'aspect technique, il y a une question plus importante sur la nécessité de ce type de modèle et de représentation graphique pour les articles du portail Télévision. Il faudrait interroger les autres contributeurs (Discussion projet:Télévision) sur l'intérêt de ces tableaux et illustrations de statistiques d'audience. Un simple tableau classique est peut-être suffisant. Cordialement. — Ideawipik (discuter) 13 juillet 2022 à 13:31 (CEST)[répondre]

retouche des modèles Base POP Palissy, Base Palissy

Travail demandé par Thierry74 (discuter) 12 septembre 2022 à 23:35 (CEST)[répondre]

Avancement :
0 %
Détails de la demande : retouche des modèles {{Base POP Palissy}}, {{Base Palissy}}
Article(s) pour le modèle : toutes les communes de France utilisant le modèle

Bonjour à tous. Depuis le basculement des bases Mérimée sur la plate forme « POP : la plateforme ouverte du patrimoine » les modèles par recherche croisées ne fonctionnent plus et renvoi vers la page d’accueil : POP : la plateforme ouverte du patrimoine. Serai-t’il possible de retoucher ces autres modèles afin d'arriver sur les objets d'une église, exemples :

{{Base Palissy|champ=REQ|((16015) :LOCA,PLOC,INSEE ET ((Saint-Martial) :EDIF ))|Objets mobiliers de l'église Saint-Martial d'Angoulême}}
- « Objets mobiliers de l'église Saint-Martial d'Angoulême », sur la plateforme ouverte du patrimoine, base Palissy, ministère français de la Culture

ou d'une commune

{{Base Palissy|champ=INSEE|60612|Liste des notices pour la commune de Senlis}}
- « Liste des notices pour la commune de Senlis », sur la plateforme ouverte du patrimoine, base Palissy, ministère français de la Culture
- « Liste des notices pour la commune de Senlis », sur la plateforme ouverte du patrimoine, base Palissy, ministère français de la Culture
- « Liste des notices pour la commune de Senlis », sur la plateforme ouverte du patrimoine, base Mérimée, ministère français de la Culture
- « Liste des notices pour la commune de Senlis », sur la plateforme ouverte du patrimoine, base Mérimée, ministère français de la Culture
{{Base Palissy|champ=LOCA|Senlis|Œuvres mobilières à Senlis}}
- « Œuvres mobilières à Senlis », sur la plateforme ouverte du patrimoine, base Palissy, ministère français de la Culture

Merci aux contributeurs qui voudaient y consacrer un peu de temps et d'énergie. Très cordialement et boone continuation sur Wikipédia--Thierry74 (discuter) 12 septembre 2022 à 23:35 (CEST)[répondre]

Discussions :

Bonjour Thierry74. Peux-tu donner les pages web vers lesquelles ces modèles devraient pointer ? Ça aiderait à trouver le problème. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 13 septembre 2022 à 00:45 (CEST)[répondre]

À première vue, {{Base POP Palissy}} semble marcher comme convenu (les Modèle:Base POP Palissy#Exemples fonctionnent tous).

Ce sont les Modèle:Base Palissy#Autres exemples qui ne marchent pas bien.

Je notifie Herr Satz qui a créé ce dernier modèle.

Şÿℵדαχ₮ɘɼɾ๏ʁ 13 septembre 2022 à 01:06 (CEST)[répondre]

Bonjour @SyntaxTerror. Effectivement, aussi bien {{Base Palissy}} que {{Base POP Palissy}} fonctionnent pour des requêtes simples, c'est-à-dire pour une notice d'un objet donné.

Mais si tu veux faire une requête complexe comme c'était possible avant le basculement sur POP, par exemple pour avoir une liste de notices situés dans un édifice ou une commune (cf. les exemples donnés par @Thierry74 qui viennent de {{Base Palissy}}#Autres exemples), ça ne fonctionne plus, et je n'ai sincèrement aucune idée de comment le faire, hélas. — Hr. Satz 13 septembre 2022 à 02:38 (CEST)[répondre]

En fait, le problème vient du méta-modèle {{Méta base Culture}}, tous les modèles utilisant son paramètre champ sont touchés (y'en a un wagon, ça impacte des milliers d'articles).

Par contre, je ne vois pas de problème avec {{Base POP Palissy}} qui utilise un autre méta-modèle ({{Méta base POP}}).

Thierry74 : quel est le problème rencontré avec ce modèle ? Il ne permet pas de faire de recherche croisée et ne comporte pas de paramètre champ (enfin, sauf les 34 fois où il est confondu avec {{Base Palissy}}, mais ça n'est pas censé marcher de toute façon).

Je suis en train de regarder les codes et les utilisations des modèles utilisant {{Méta base Culture}} et j'ai pas mal de surprises... Şÿℵדαχ₮ɘɼɾ๏ʁ 13 septembre 2022 à 07:51 (CEST)[répondre]

C'est moins pire que je croyais, on a :

Modèles utilisant le méta-modèle {{Méta base Culture}} / pages utilisant le paramètre champ :

Avec POP, la syntaxe des URL est devenue plus simple à mon avis, il devrait suffire de remplacer {{Méta base Culture}} par un autre méta modèle (ou peut être de le modifier, mais je ne sais pas comment ça va impacter les modèles n'utilisant pas de paramètre champ).

Sinon, il ne semble plus possible de faire une recherche avec le n° INSEE.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 13 septembre 2022 à 11:20 (CEST)[répondre]

Aéroport-Statistiques

Travail demandé par Bouzinac (discuter) 1 février 2023 à 06:24 (CET)[répondre]

Avancement :
0 %
Détails de la demande : Pour le modèle {{Aéroport-Statistiques}}, en cas d'un seul paramètre iata, rajouter un bouton de raccourci vers la P3872 de l'item wikidata de l'iata. Exemple,

Pour des raisons techniques, il est temporairement impossible d'afficher le graphique qui aurait dû être présenté ici.

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

devrait proposer un petit texte "(crayon) éditer sur wikidata" avec un raccourci vers https://www.wikidata.org/wiki/Q2876104#P3872 . Encore mieux, mais je pense pas trop que ce soit possible, mais un raccourci direct vers cette IHM ?

(cf https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:WE-Framework )

Article(s) pour le modèle : ...; ...; ...
Discussions :

@Bouzinac C’est un gadget, il semble qu’il y ait pas spécialement besoin d’un lien pour y accéder, il faut a priori mettre les lignes suivantes

if ( mw.config.get("wgDBname") !== 'ruwiki')
    mediaWiki.loader.load( '//ru.wikipedia.org/w/index.php?title=MediaWiki:WEF_AllEditors.js&action=raw&ctype=text/javascript' );

dans son Special:MyPage/common.js, si tu l’as pas fait. Sinon je suis pas certain de comprendre ?

Hello TomT0m , le pb n'est pas pour moi (j'utilise très régulièrement l'IHM en question) mais c'est pour les autres, ceux pour qui éditer sur wikidata n'est pas évident. Bouzinac (discuter) 1 février 2023 à 17:44 (CET)[répondre]

Ajout de modèles en lien vers les forces armées dans système country

Travail demandé par Alpha568 (discuter) 22 février 2023 à 06:13 (CET)[répondre]

Avancement :
0 %
Détails de la demande : En regardant les modèles pour l'Armée de terre, la Marine et l'Armée de l'air, j'ai essayé de voir s'il y avait aussi un modèle plus général pour les Forces Armées dans leur ensemble, l'idée étant de l'utiliser pour les éventuelles infobox de branches des forces armées (marine, armée de terre, armée de l'air...). On m'a renvoyé vers la page Projet:Modèle/Système Country ou il apparaît que ce modèle n'existe pas encore de manière générale, à l'instar des modèle pour les gardes côtes et les infanteries de marines, mais uniquement pour certains pays (Canada, Belgique,...). Je demande donc la création de ces modèles encore manquant, et je propose également la création d'un modèle général pour les gendarmeries et les forces spatiales (mais je concède que ce dernier point ne concerne peut-être pas assez d'article que pour être pertinent). En outre, je me demande si on pouvait compléter les modèles concernant les branches de l'armée américaine: on a les modèle pour l'US Army, l'US Navy, l'Air Force et le Corps des marines, mais il manque ceux pour l'US Coast Guard et l'US Space Force.
Article(s) pour le modèle : Voyska PVO; Armée de l'air et de l'espace (France); United States Space Force
Discussions :

Infobox géoloc

Travail demandé par Ellicrum _{(bablute [...])} 23 février 2023 à 23:59 (CET)[répondre]

Avancement :
0 %
Détails de la demande :

Bonjour, dans les infobox qui contiennent de la géolocalisation, il y a la possibilité actuellement de renseigner quatre entités géographiques (de ce que je comprends). Et pourtant, bien des toponymes pourraient justifier l'accueil d'une cinquième « entité », avec par exemple :

pour Douvres : « | géolocalisation = Royaume-Uni/Angleterre/Angleterre du Sud-Est/Kent/Manche »
pour Saint-Pétersbourg : « [...] Russie/Russie européenne/district fédéral du Nord-Ouest/mer Baltique/golfe de Finlande »
ou pour le mur des Lamentations : « Israël/Palestine/Cisjordanie/Jérusalem/vieille ville de Jérusalem »

Ainsi, le dernier champ renseigné (en gras) ne peut pas apparaître dans l'article, compte tenu de cette limitation. Est-il possible alors de changer cette délimitation, avec à la place cinq entités ? — Ellicrum _{(bablute [...])} 23 février 2023 à 23:59 (CET)[répondre]

On pourrait relever également que d'autres toponymes biens spécifiques pourraient théoriquement abriter bien plus de cartes géolocalisables dans leur infobox :

pour le mont Blanc : « [...] France/Italie/Auvergne-Rhône-Alpes/Haute-Savoie/Vallée d'Aoste/Alpes » (six subdivisions)
pour le Vignemale : « Espagne/France/Aragon/Occitanie/province de Huesca/Hautes-Pyrénées/Pyrénées » (sept subdivisions)

Mais puisqu'il faut prendre en compte également l'affichage sur les petits écrans et garder une taille d'infobox assez compacte, je suppose que rehausser sensiblement cette délimitation n'est pas le choix le plus optimal. — Ellicrum _{(bablute [...])} 24 février 2023 à 00:26 (CET)[répondre]

Article(s) pour le modèle : ...; ...; ...
Discussions :

Ces infobox appellent indirectement Modèle:Infobox Subdivision administrative ou Modèle:Infobox/Géolocalisation multiple, et le paramètre concerné est carte dans le premier cas, géolocalisation dans le deuxième. Actuellement il y a un bout de code pour {{#titleparts:{{{carte|}}}|1|1}} jusqu'à {{#titleparts:{{{carte|}}}|1|4}} mais rien pour {{#titleparts:{{{carte|}}}|1|5}}. Escargot (discuter) 24 février 2023 à 00:32 (CET)[répondre]

Merci Escargot vert pour ces informations, des modèles qui sont sans surprise entièrement protégés. — Ellicrum _{(bablute [...])} 24 février 2023 à 16:49 (CET)[répondre]

Bonjour Ellicrum et Escargot vert. Je ne suis pas persuadé qu'il faille multiplier le nombre des fonds de cartes dans une infobox et fuir en avant. Ainsi, sur l'exemple du mur des Lamentations, il n'est pas utile de resituer la ville de Jérusalem dans chaque division administrative la concernant. Cette géolocalisation se trouve dans l'article Jérusalem. C'est une sorte d'application du principe de proximité. Une sélection est d'ailleurs déjà opérée puisque la position sur le planisphère n'est pas proposée au lecteur, ni même celle à l'échelle du continent. De même, pour Douvres, il n'est pas forcément nécessaire de la placer sur les cartes "intermédiaires" « Angleterre » et « Angleterre du Sud-Est », d'autant plus qu'un petit plan est encarté dans celle de niveau « Kent ». Avec une sélection judicieuse, on peut normalement s'en sortir avec le nombre actuel de cartes.

Pour les exemples transfrontaliers, il serait peut-être intéressant de créer des fonds de cartes annotés présentant un niveau de "zoom" intermédiaire entre le niveau continental et le niveau national. Techniquement, cela demande d'analyser un peu le code, pour voir s'il est facilement possible d'adapter, voire de retirer, les liens internes associés à la mention « Géolocalisation sur la carte : … ». — Ideawipik (discuter) 24 février 2023 à 19:50 (CET)[répondre]

Salut Ideawipik, d'où ma déclaration précédente de ne pas effectivement « multiplier le nombre des fonds de cartes » (avec les exemples en montagne) mais plutôt d'avoir une légère rehausse de cette limite avec cinq entités possibles, sans que ce soit non plus pléthorique. Les exemples cités ne sont visiblement pas les meilleurs, mais ceux qui pourraient en accueillir au moins cinq ne sont pas difficiles à trouver ; en tout cas, la limite actuelle de quatre fait perdre amhà en flexibilité. Mais je comprends bien sûr les avis contraires ou que cette requête n'obtiendrait pas de suite.

Concernant ton second point sur les « exemples transfrontaliers », là pour le coup je maîtrise encore moins. Tant mieux au moins que cette requête permet de soulever cette proposition. — Ellicrum _{(bablute [...])} 25 février 2023 à 18:58 (CET)[répondre]

Fortuitement, en tombant entre autres sur le Parc des Princes et le palais omnisports de Paris-Bercy, je constate qu'ils disposent tous deux de cinq géolocalisations dans leur infobox. Je ne sais pas si c'est une spécificité du modèle:Infobox Stade ou s'il y a une manip cachée pour permettre cette mise en forme. Puisque les articles concernés ne semblent pas particulièrement surchargés par cette mise en forme, pourquoi après tout en faire part dans cette requête. — Ellicrum _{(bablute [...])} 20 juin 2023 à 22:51 (CEST)[répondre]

Statut UICN DD

Travail demandé par Ellicrum _{(bablute [...])} 24 février 2023 à 17:50 (CET)[répondre]

Avancement :
0 %
Détails de la demande : Bonjour, pour revenir rapidement sur cette thématique, le statut dit « à données insuffisantes » () a dans les taxobox un affichage différent des autres statuts UICN. Si je prends comme exemple Myotis alcathoe, on peut voir un assez sommaire « DD : Données insuffisantes », sans fichier qui l'accompagne. Pour comparer avec en:Alcathoe bat, il y a la présence ici d'un diagramme de ce type. Ainsi, est-il possible d'intégrer ce dernier fichier quand on entre l'option « {{Taxobox UICN|DD}} » ? — Ellicrum _{(bablute [...])} 24 février 2023 à 17:50 (CET)[répondre]

Article(s) pour le modèle : ...; ...; ...
Discussions :

Ce n'est que mon avis, mais je trouve que la présence du graphique rend la chose moins claire, puisque DD n'en fait pas partie et que si on ne connait pas le sujet le lien entre Données manquantes et le graphique n'est pas si évident. Escargot (discuter) 24 février 2023 à 18:07 (CET)[répondre]

On peut estimer effectivement que dans l'absolu cet ajout n'apporte pas davantage de clarification. Le graphique actuel étant ce qu'il est, où on a l'absence entre autres des statuts DD et NE. Disons que cela montre a minima que l'espèce concernée n'est pas catégorisée dans les statuts « classiques ». — Ellicrum _{(bablute [...])} 24 février 2023 à 19:58 (CET)[répondre]

Pas d'autre avis pour cette requête ? — Ellicrum _{(bablute [...])} 8 avril 2023 à 13:21 (CEST)[répondre]

Pas certain non plus que ça soit intéressant pour le lecteur. On sait qu'il n'y a pas (assez) de données, est-ce nécessaire de rappeler les statuts existants alors que le taxon n'est dans aucun ?

Ceci dit je vais répercuter la question sur le café des biologistes : après tout le contenu des taxobox intéresse ce portail / projet. A+ Hexasoft (discuter) 8 avril 2023 à 14:25 (CEST)[répondre]

Bonjour, la présentation actuelle me convient - où placer sinon cette absence de données ? Le diagramme permet de situer où en sont les préoccupations concernant l'espèce en question, mais dans le cas présent... on n'en sait absolument rien. Par conséquent à ne pas changer (à mon avis). Givet (discuter) 15 avril 2023 à 08:58 (CEST)[répondre]

Bonjour, je partage les avis précédents, pas sûr que ce soit très utile. Le DD est suffisant pour moi. Cordialement GF38storic (discuter) 15 avril 2023 à 22:21 (CEST)[répondre]

J'en prends note, merci pour vos avis. Mais pour rebondir sur la même thématique, qu'en est-il de la proposition de Tricholome sur la refonte des icônes des statuts de conservation ? — Ellicrum _{(bablute [...])} 20 juin 2023 à 23:22 (CEST)[répondre]

Modèle:Données de la pandémie de Covid-19

Travail demandé par SenseiAC (discuter) 15 mars 2023 à 19:00 (CET)[répondre]

Avancement :
0 %
Détails de la demande : Bonjour, Serait-il possible de rectifier ce qui suit dans le modèle {{Données de la pandémie de Covid-19}} ?
- À la ligne « Saint-Barthélemy (Antilles françaises) », afficher correctement le drapeau (soit le drapeau de la France, soit le drapeau de Saint-Barthélemy, selon ce qui se fait habituellement chez nous pour ce territoire) à la place du lien rouge Modèle:Country data Saint-Barthélemy (Antilles françaises) ;
- À la ligne « Saint-Martin (royaume des Pays-Bas) », afficher le drapeau de Saint-Martin (royaume des Pays-Bas) et non le drapeau de la France ;
- Remplacer « Pays-Bas (pays constitutif) » par « Pays-Bas » (cet article se limite déjà au Covid-19 aux Pays-Bas européens), de façon analogue à ce qu'il y a déjà pour « Danemark ». Au passage, une même note, proprement écrite « Concerne le pays constitutif. » (avec majuscule et point final), peut convenir pour les deux pays, à la place des deux notes actuelles écrites un peu à l'arrache ;
- Étant donné le statut contesté du Sahara occidental, utiliser à la ligne correspondante le drapeau de la République arabe sahraouie démocratique me semble jeter inutilement de l'huile sur le feu. On notera au passage que, contrairement à pour toutes les autres lignes, le tableau ne pointe pas vers un potentiel article dédié Pandémie de Covid-19 au Sahara occidental, mais vers l'article sur le territoire. Le fait est que, manifestement, les données de la ligne « Maroc » incluent déjà les données concernant le Sahara occidental, donc il faudrait que, d'une façon ou d'une autre, le tableau soit cohérent concernant le traitement de ce territoire.

Merci d'avance.

Article(s) pour le modèle : ...; ...; ...
Discussions :

J'ai créé une redirection pour que le drapeau de Saint-Barthélemy s'affiche correctement, mais pour le reste seul @Tol peut s'en occuper puisque c'est son bot qui entre quotidiennement les données sur Modèle:Données de la pandémie de Covid-19/données (Les modifier manuellement ne sert à rien). Escargot (discuter) 15 mars 2023 à 21:05 (CET)[répondre]

Veuillez m'excuser; je ne parle pas français. Merci de m'avoir prévenu. Pour Saint-Martin : il faut le fixer sur Modèle:Country data Saint-Martin. Pour les Pays-Bas et le Danemark : modifié. Pour le Sahara occidental : si vous pouvez écrire une note, je peux l'ajouter. Tol (discuter | contributions) 16 mars 2023 à 01:33 (CET)[répondre]

Modèle:Brouillon relecture

Travail demandé par 80.214.120.121 (discuter) 12 juin 2023 à 00:23 (CEST)[répondre]

Avancement :
0 %
Détails de la demande : Bonsoir tout le monde, je souhaiterais que le modèle {{Brouillon relecture}} (en) existe en français car ce modèle permet de catégoriser des brouillons à relire, tout comme sur les brouillons en anglais (exemple). Ce modèle existe bien sur d’autres langues, y compris la catégorie (que j’ai créé) et j’aimerais bien que ce modèle (en) existe en français.

Concernant les catégories associées au modèle, j’ai ébauché Catégorie:Brouillons à relire, principale catégorie du modèle (également disponible sur d’autres langues), Catégorie:Brouillon relu, pour catégoriser des brouillons relus après le traitement, Catégorie:Brouillon non publiable (disponible sur d’autres langues) qui permet de lister des brouillons non publiables après le traitement, ensuite j’ai inventé des catégories : Catégorie:Brouillon prêt à être publié : qui permet de lister des brouillons à renommer vers la page à publier, Catégorie:Brouillon publié dans l'espace encyclopédique : qui permet de lister automatiquement des brouillons publiés par l’auteur du brouillon ou par d’autres utilisateurs et le but de cette catégorie est de retirer des doublons avec des articles existants, et Catégorie:Brouillon déjà publié : qui permet de lister automatiquement des brouillons a relire qui ont été déjà publiés par l’auteur du brouillon ou par d’autres utilisateurs, et toutes les informations concernant les catégories que j’ai créé sont sur la documentation du modèle.

Et ce n’est pas tout : je n’ai peut-être pas tout traduit mais j’ai aussi inventé quelque chose : des instructions automatiques en fonction de l’utilisation du modèle dédiés au demandeur, aux bénévoles et aux administrateurs afin de mieux comprendre et de mieux participer à la maintenance des brouillons. J’ai passé une semaine à construire ce modèle tout en lisant "Aide:Syntaxe" (vu depuis "Aide:Créer un modèle" et en copiant certains codes de modèle (par exemple : {{Brouillon}}).

Si vous souhaitez relire et corriger quelques erreurs sur mon modèle, voici mon brouillon ^{(page supprimée)} avec sa page de documentation ^{(page supprimée)}.

Une fois le traitement terminé, vous pouvez renommer mon brouillon vers {{Brouillon relecture}} (en) (ainsi que sa page de documentation vers ici (en)) ou vers un autre nom si vous avez un nom meilleur ?

Article(s) pour le modèle : Brouillons listés (y compris anciens) sur le forum de relecture.
Discussions :

Notice de la British Library

Travail demandé par Harmonizator (discuter) 19 juin 2023 à 18:21 (CEST)[répondre]

Avancement :
0 %
Détails de la demande : Création d'un modéle pour les notices de la British Library
Article(s) pour le modèle : ...; ...; ...
Discussions :

Bizarrement je n'ai pas trouvé de modèle pour les notices de la British Library.
Voici le modèle anglophone. Il faudrait aussi le rajouter au modèle Autorité après création. Merci.

Au passage, est-ce que ce genre de modèle est facile à créer à partir d'un autre modèle proche? Harmonizator (discuter) 21 juin 2023 à 15:17 (CEST)[répondre]

Bonjour Harmonizator. Ce type de modèle est très facile à écrire ; il s'agit d'un simple lien externe. Bémol : la Wikipédia anglophone ne sollicite ce modèle que sur 26 articles ; l'usage de ce modèle sur la Wikipédia francophone sera donc très sporadique. Mais, on peut tout de même le créer, à mon avis. Je suggère un nom plus explicite que BLCAT, avec éventuellement ce raccourci comme alternative (redirection). Par exemple, « Modèle:Notice British Library ». Le modèle sera (depuis sa page de documentation) à catégoriser dans Catégorie:Modèle créant un lien externe. Voici une proposition simplissime pour le code du modèle :

[[British Library]], [http://explore.bl.uk/BLVU1:LSCOP-ALL:BLL01{{{1|}}} {{{1|Catalogue}}}]<noinclude>
{{Documentation}}
</noinclude>

Mais peut-être serait-il préférable d'avoir un second paramètre pour spécifier un titre plutôt que le numéro de notice (et dans ce cas, deux paramètres nommés ?). — Ideawipik (discuter) 21 juin 2023 à 20:01 (CEST)[répondre]

Modèle:Page à publier

Travail demandé par 80.214.18.13 (discuter) 20 juin 2023 à 10:53 (CEST)[répondre]

Avancement :
0 %
Détails de la demande : Bonjour, j'ai inventé un modèle: ce modèle permet d'afficher un lien vers un brouillon à côté d'un lien inexistant. Ce qui est peut-être utile dans certaines pages de discussion. Voici à quoi ressemble cette phrase quand on utilise ce modèle.

Voici mon brouillon ^{(page supprimée)} avec sa page de documentation ^{(page supprimée)}. Si vous trouvez ça correct, vous pouvez publier ce modèle ? Merci. --80.214.18.13 (discuter) 20 juin 2023 à 10:53 (CEST)[répondre]
Article(s) pour le modèle : Certaines pages de discussions où il contient une page à publier.
Discussions :

Bonjour. Vous pouvez inventer des centaines de modèles. S'ils ne répondent pas à un besoin réel, ils seront inutiles. À quoi ce type de lien servirait-il dans la pratique ? Si quelqu'un veut mentionner une page de brouillon, dans l'espace non-encyclopédique, il introduit un lien classique, entre crochets doubles. Idem pour un article non encore existant (lien rouge avec la syntaxe classique des liens internes). D'avis de refuser (comme lors de deux demandes antérieures dans le mois). — Ideawipik (discuter) 21 juin 2023 à 13:46 (CEST)[répondre]

@Ideawipik en-ce qui concerne l’utilité de ce modèle c’est quand il commence un brouillon par exemple, il met par exemple "{{Page à publier|Cerise|page:Utilisateur:Jean Dunom/Brouillon/Cerise}}" en plein milieu de sa phrase et le lien de son brouillon apparaîtra automatiquement à côté du lien inexistant, et si la page est publiée, le lien de son brouillon disparaît automatiquement. 80.215.134.49 (discuter) 21 juin 2023 à 20:09 (CEST)[répondre]

Lire ma réponse commune dans la section suivante. — Ideawipik (discuter) 21 juin 2023 à 21:10 (CEST)[répondre]

Modèle:Lien à publier

Travail demandé par 80.215.134.49 (discuter) 21 juin 2023 à 19:38 (CEST)[répondre]

Avancement :
0 %
Détails de la demande : Bonsoir, ce modèle permet d’afficher un bouton "Publier" à côté d’un lien vers un brouillon. Ce qui est de spécial avec ce modèle c’est quand une page est publiée, le bouton "Publier" à côté du lien s’efface tout seul et le lien affichera la page publiée à la place du brouillon. Voici à quoi ça ressemble cette phrase quand une personne a fini son brouillon.
En-ce qui concerne le bouton "Publier", je ne sais pas si il fonctionne correctement parce-que je n’ai pas l’autorisation de renommer, mais pour le tester, le bouton se trouve dans un brouillon vierge ^{(page supprimée)} qui permet de déplacer automatiquement la page vers un autre titre.

Voici mon brouillon ^{(page supprimée)} avec sa page de documentation ^{(page supprimée)} et une redirection ^{(page supprimée)} intitulée "Brouillon à publier" pour lui donner un deuxième nom.
Article(s) pour le modèle : Certaines pages de discussion (notamment le forum de relecture) quand une personne a fini un brouillon.
Discussions :

Réponse commune avec la demande précédente #Modèle:Page à publier. Et si on se contentait d'utiliser des fonctions coûteuses (comme #ifexist) uniquement quand cela est opportun et d'arrêter de proposer des modèles gadget ? D'une part, les phrases risquent de devenir incompréhensibles après création de l'article (ou renommage du brouillon) et changement de comportement du modèle. En outre, qui dit que le brouillon sera finalement publié sous le nom initialement envisagé lors de la rédaction du message (valeur du paramètre du modèle). Et si une autre personne crée un article à ce nom, indépendamment de ce brouillon existant, on perdra le lien vers le brouillon et donc le sens de la rédaction/demande initiale. Bref, une source de quiproquos ! D'autre part, si on veut une Wikipédia plus verte ou sobre, ce n'est pas la marche à suivre : exécution permanente de fonctions coûteuses, ou génération d'une nécessité de maintenance qui elle aussi aura un impact (multiplication des éditions).

Comme pour la proposition précédente, le rédacteur peut, si besoin, écrire deux liens internes classiques : « Voici mon brouillon B pour la création de l'article A » ou dans le texte dans un espace personnel de travail « A (brouillon) », avec des liens.

Il y a assez de maintenance à faire dans les articles publiés. Inutile d'ajouter des gadgets destinés aux brouillons et à l'intérêt plus que limité. Les contributeurs disposent déjà d'un bouton permettant la publication de leur brouillon, bouton présent sur ledit brouillon. Les plus expérimentés connaissent la procédure de renommage. — Ideawipik (discuter) 21 juin 2023 à 21:10 (CEST)[répondre]

J’avais regardé si il y avait un bouton "Publier" et je ne le vois pas sur mon brouillon, même sur les autres brouillons… Est-ce qu’il y a aussi un bouton "Publier" dans un autre nom d’une sous page (par exemple : Utilisateur:Jean Dunom/Mon modèle) ? 176.173.217.215 (discuter) 22 juin 2023 à 09:44 (CEST)[répondre]

Le bouton « Publier » n'apparaît que pour les utilisateurs connectés. Escargot (discuter) 22 juin 2023 à 11:41 (CEST)[répondre]

Aube de l'humanité

Travail demandé par Ellicrum _{(bablute [...])} 21 juin 2023 à 20:55 (CEST)[répondre]

Avancement :
0 %
Détails de la demande : Bonjour, pour ce qui concerne le Modèle:Évolution Hominines, est-il possible de reprendre la mise en forme utilisée par son équivalent en:Template:Human timeline ? Pour les wikiliens à traduire :

Denisovans → Dénisovien
Hominids → Hominidés
Modern humans → Homme moderne
Earliest clothes → Vêtements
Earliest rock art → Art rupestre
Earliest fire → Domestication du feu
Dispersal beyond Africa → Sorties d'Afrique
Earliest bipedal → Bipédie
Earliest apes → Grand singe

Mais contrairement à la version anglaise, je suggère également de conserver les industries lithiques (Moustérien, etc.). — Ellicrum _{(bablute [...])} 21 juin 2023 à 20:55 (CEST)[répondre]

Article(s) pour le modèle : ...; ...; ...
Discussions :

Bonjour Ellicrum. Seulement deux articles, récents (quatre et huit mois d'existence), sont liés à ce modèle. Un le porte en inclusion ; l'autre contient un lien en section « Voir aussi ». Avant d'envisager une mise à jour du modèle, il conviendrait de s'assurer que l'utilisation d'un tel modèle (dans sa version anglaise) est consensuel. Venant de voir Discussion modèle:Évolution Hominines/Admissibilité datant de 2019, avec certes peu de participants, et une demande de suppression immédiate associée qui n'a pas été traitée à l'époque, je notifie la demande aux intervenants :

Pierrette13, Keranplein, El Caro et Sergio1006. — Ideawipik (discuter) 22 juin 2023 à 00:18 (CEST)[répondre]

Bonjour,

J'avais demandé en 2019 la destruction du Modèle:Évolution Hominines car il est obsolète depuis longtemps et irrécupérable. Il montre en effet une forme d'évolution linéaire de la lignée humaine, alors qu'on admet depuis près de 20 ans que cette évolution est buissonnante.

Ce modèle a donc été retiré de tous les articles WP où il figurait et sera retiré des deux nouveaux articles qui l'ont incorporé à tort. Son emploi erroné justifie a posteriori ma demande de destruction de 2019, qui n'avait malheureusement pas été exécutée. Il existe plusieurs modèles alternatifs à utiliser à la place.

Cordialement, Keranplein (discuter) 22 juin 2023 à 00:39 (CEST)[répondre]

Compte tenu du sombre tableau que tu dresses Keranplein, c'est à se demander pourquoi ce modèle existe encore

. Il me vient alors deux remarques subsidiaires. Quels sont donc ces modèles alternatifs et plus adaptés qui retraceraient l'évolution humaine ? Et si jamais ces derniers modèles ne montrent pas ce cheminement entre Toumaï et la modernité comportementale (contrairement au modèle qui nous concerne ici), rien n'empêche de recycler ce dernier pour qu'il acquière une mise en forme buissonnante (rien n'est irrécupérable après tout). — Ellicrum _{(bablute [...])} 22 juin 2023 à 14:17 (CEST)[répondre]

Voici quelques modèles et schémas existants et en usage en 2023 :

Les Hominines au cours du temps (échelle : milliers d'années)

v · d · m

Phylogénie des espèces récentes du genre Homo, d'après Strait, Grine & Fleagle (2015)^[1], et Meyer & al. (2016)^[2] :

Homo

Homo antecessor †

Homo heidelbergensis †

	Homo denisovensis †

	Homo neanderthalensis †

	Homo rhodesiensis †

	Homo sapiens

Cordialement, Keranplein (discuter) 22 juin 2023 à 14:42 (CEST)[répondre]

Merci Keranplein pour cette réponse très détaillée. Et effectivement, à la lumière des modèles présentés, maintenir celui qui fait l'objet de cette section ne se justifie pas. Peut-être qu'un modèle dédié pour les principales avancées « techniques » (outils, feu, sépultures, écriture, etc.) en fonction du temps peut se justifier, mais dans ce cas « Évolution Hominines » n'est pas le titrage le plus adapté. Si je puis suggérer une chose pour le tableau et le second arbre phylogénétique, c'est de mettre en italique les noms binominaux. — Ellicrum _{(bablute [...])} 22 juin 2023 à 16:34 (CEST)[répondre]

Références

↑ [Strait, Grine & Fleagle 2015] (en) David Strait, Frederick Grine et John Fleagle, « Analyzing Hominin Phylogeny : Cladistic Approach », dans Winfried Henke & Ian Tattersall, Handbook of Paleoanthropology, janvier 2015 (ISBN 9783642399787, lire en ligne), p. 1989-2014.
↑ [Meyer et al. 2016] (en) Matthias Meyer et al., « Nuclear DNA sequences from the Middle Pleistocene Sima de los Huesos hominins », Nature, vol. 531, n^o 7595,‎ mars 2016, p. 504-507 (DOI 10.1038/nature17405, résumé).

Géoloc complexe

Travail demandé par Ellicrum _{(bablute [...])} 26 juin 2023 à 20:15 (CEST)[répondre]

Avancement :
60 %
Détails de la demande : Bonjour, est-il possible de rendre opérationnel les modèles de géoloc suivants ? Contrairement aux interwikis qui les utilisent, je n'ai pas réussi à les faire fonctionner. — Ellicrum _{(bablute [...])} 26 juin 2023 à 20:15 (CEST)[répondre]

Modèle:Géolocalisation/Eurasie

Modèle:Géolocalisation/Amérique 2

Modèle:Géolocalisation/Union soviétique (1937)

Modèle:Géolocalisation/Terre du Nord

Modèle:Géolocalisation/Îles de Nouvelle-Sibérie

Modèle:Géolocalisation/Raïon dolgano-nénètse de Taïmyr

Modèle:Géolocalisation/Archipel Arctique

Article(s) pour le modèle : ...; ...; ...
Discussions :

Bonjour @Ellicrum,
Pour les cartes qui contenaient déjà une formule, j'ai modifié selon les indications données dans Aide:Modèle de paramétrage de carte. Il faut vérifier que ça fonctionne.

Pour la première, les coordonnées de la carte ne sont pas indiquées, pour la deuxième il faudrait recalculer la formule à partir des informations données sur la carte. En tout cas, ce n'est pas une projection equirectangulaire. Escargot (discuter) 2 juillet 2023 à 19:01 (CEST)[répondre]

Salut Escargot bleu, merci pour tes retouches et après un rapide test, tout porte à croire que cela fonctionne pour les ~~cinq~~ quatre derniers. Pour l'Amérique, je mets ici le module utilisé sur le wiki:en (avec sûrement les bonnes coordonnées). Pour l'Eurasie, le modèle sur le wiki:ru semble fonctionner très différemment (en tout cas, il est opérationnel ici ou là). — Ellicrum _{(bablute [...])} 2 juillet 2023 à 21:15 (CEST)[répondre]

@Ellicrum J'ai copié les formule pour ces deux modèles. Pour le modèle russe, elles sont dans des sous-pages de la forme ru:Редактирование: Шаблон:ПозКарта Евразия/x.

Dans les deux cas, il faut vérifier que je n'ai pas inversé longitude et latitude. Pour celle d'Eurasie, il faut aussi vérifier que le passage en relief fonctionne correctement.

Et pour Modèle:Géolocalisation/Union soviétique (1937), la formule utilisée ne dépend pas des paramètres donnés au modèle, donc il faut la corriger. Escargot (discuter) 2 juillet 2023 à 21:57 (CEST)[répondre]

L'Amérique en mode Lambert semble aussi fonctionnelle. Un peu de précipitation effectivement pour l'URSS 1937 (je voulais dire « les quatre derniers »), puisque le modèle de point sort de l'infobox. Et après vérification, c'est la même chose pour le « modèle:Géolocalisation/Union soviétique » : à comparer avec la formule sur le wiki:de, qui utilise d'ailleurs les deux modèles soviétiques. Idem pour l'Eurasie, que ce soit le blank et le relief, où il y a peut-être une inversion du paramètre x et y. — Ellicrum _{(bablute [...])} 3 juillet 2023 à 13:36 (CEST)[répondre]

Modèle:Ajouter du texte

Travail demandé par 80.215.38.27 (discuter) 30 juin 2023 à 15:42 (CEST)[répondre]

Avancement :
0 %
Détails de la demande : Bonjour, ce modèle permet d’ajouter uniquement du texte sur une page (c’est à dire, ne doit pas être confondu avec le modèle {{Ajouter un sujet}}).
Quand on clique sur le bouton Utilisateur:80.215.80.133/Mon modèle
ça affiche uniquement une fenêtre d’édition et on peut écrire se qu’on veut.

D’habitude quand on clique sur le bouton Demander un renommage
avec le modèle {{Ajouter un sujet}}, ça affiche le champ "Sujet / titre" et dès fois, des personnes font mal les demandes (1, 2, 3…) et ce qui est pourrait être utile avec ce modèle c’est de l’inclure dans l’introduction de la page Wikipédia:Demande de renommage et voici à quoi ressemblerait les instructions ^{(page supprimée)} une fois qu’on a remplacé le bouton.
Pour tester le bouton, voici une fausse page des demandes de renommage ^{(page supprimée)} pour voir à quoi ressemblerai quand on demande un renommage. Pour faire d’autres essais, vous pouvez aussi utiliser le bac à sable…

Voici mon brouillon ^{(page supprimée)} avec sa page de documentation ^{(page supprimée)}.
Si le bouton fonctionne bien, vous pouvez le publier ?
Article(s) pour le modèle : Wikipédia:Demande de renommage/En-tête ; ou certaines pages d’en-têtes…
Discussions :

Ce modèle fait la même chose qu'Ajouter un sujet. En mettant dans l'url &section=new, on crée toujours un nouveau sujet avec un champ pour le titre que les gens risquent de remplir. Et il n'y a pas moyen de faire autrement. Escargot (discuter) 30 juin 2023 à 15:57 (CEST)[répondre]

@Escargot bleu mais si j’ai réussi à faire autrement en lisant Manuel:Création de pages avec du texte préchargé mais sauf que vous n’avez pas cliqué sur des boutons. Ce modèle fait exactement la même chose sauf que le champ " Sujet / titre" n’apparaît pas. Vous pouvez le tester sur la fausse page de demande de renommage ^{(page supprimée)} et puis vous verrez bien qu’il n’y a pas le champ "Sujet / titre"… 80.215.38.27 (discuter) 30 juin 2023 à 16:19 (CEST)[répondre]

Ah pardon, en fait avec l'éditeur de sources 2017 que j'utilise il n'y a pas de différence entre les deux, mais il y en a bien une dans l'éditeur de wikicode par défaut. Escargot (discuter) 30 juin 2023 à 16:31 (CEST)[répondre]

Amélioration du modèle Suppression Immédiate

Travail demandé par 80.215.38.27 (discuter) 30 juin 2023 à 23:12 (CEST)[répondre]

Avancement :
100 %
Détails de la demande : La semaine dernière j’avais demandé une intervention sur ce modèle pour modifier le bouton WP:SI mais il n’y a aucune réponse : Ce qu’il y a de spécial avec le bouton WP:SI c’est que d’habitude, quand on insère une raison sur le modèle (par exemple : {{Suppression Immédiate|Essai}}) et qu’on clique sur le bouton WP:SI, on n’a pas la raison préchargée et on est obligé de réécrire la raison. Et quand j’ai trouvé comment faire pour précharger son motif en lisant Manuel:Création de pages avec du texte préchargé, j’ai fini par trouver comment faire et j’ai essayé également le nouveau bouton (qui redirige vers une fausse page de demande de suppression ^{(page supprimée)}) et après 4 ou 5 essais, ça a fonctionné correctement. Voici à quoi ressemble le nouveau bouton qui se trouve en dessous de ce modèle :

Utilisateur:176.173.221.160/Mon modèle

Pour commencer, il faudra renommer le brouillon du préchargement ^{(page supprimée)} vers Wikipédia:Demande de suppression immédiate/preload2 et ensuite dans le code du vrai modèle, il faudra juste remplacer le code du bouton WP:SI (toucher le bouton "Modifier le code" dans la demande pour voir ce qu’il faut remplacer).

Discussions :

Escargot (discuter) 1 juillet 2023 à 11:36 (CEST)[répondre]

@Escargot bleu merci, le bouton précharge désormais la raison correctement quand on appuie dessus (exemple). 80.215.11.232 (discuter) 1 juillet 2023 à 13:38 (CEST)[répondre]

Modèles permettant d'obtenir les coordonnées latitude et longitude d'une gare

Travail demandé par Poudou! (discuter) 1 juillet 2023 à 13:55 (CEST)[répondre]

Avancement :
100 %
Détails de la demande :

Bonjour

Je souhaiterais disposer de deux modèles permettant d'obtenir les coordonnées latitude et longitude d'une gare, à l'instar du modèle uic8 qui permet d'extraire le code UIC d'une gare à 8 chiffres (à partir de la propriété wikidata P722).

Normalement, pour une entité wikidata de type gare, les coordonnées sont contenues dans la propriété P625 (exemple : Gare de Zéralda).

Ces deux modèles auront comme paramètre le nom d'une gare (non précédée de gare de) et seront utilisés dans le corps de l'article d'une gare pour, par exemple, positionner une ou des gares sur une carte géolocalisée. Cela dans le but d'éviter d'écrire en dur les valeurs latitude et longitude comme dans cet exemple :

Alger

Zéralda

Birtouta

Réghaïa

Localisation de la gare de Zéralda dans la wilaya d'Alger.

où :

la ligne : {{Géolocalisation|Réseau ferroviaire de la wilaya d'Alger|36.779247|3.061821|Gare d'Alger{{!}}Alger|Ville|5|e}}
sera remplacée par la ligne : {{Géolocalisation|Réseau ferroviaire de la wilaya d'Alger|{{modèle_XXX/latitude|Alger}}|{{modèle_XXX/longitude|Alger}}|Gare d'Alger{{!}}Alger|Ville|5|e}}

où {{modèle_XXX/latitude|Alger}} et {{modèle_XXX/longitude|Alger}} sont les deux modèles demandés et utilisés pour récupérer les coordonnées de la gare d'Alger.

A noter que ces modèles seront utilisables pour n'importe quelle gare ayant une entité Wikidata.

Article(s) pour le modèle : tout article ferroviaire
Discussions :

Bonjour @Poudou!

Les modèles seront bien plus simples à faire s'ils prennent en paramètre l'identifiant Wikidata plutôt que le nom de la ville. Si vraiment vous voulez utiliser les noms de ville, il faudra construire une table donnant pour chaque ville l'identifiant wikidata de sa gare. (ou bien une table donnant pour chaque ville la latitude et la longitude de sa gare) Escargot (discuter) 2 juillet 2023 à 19:32 (CEST)[répondre]

Bonjour @Escargot bleu

J'ai commencé à réfléchir à la structure de base de ces modèles. Ils seraient basés sur ces instructions :

{{str split|{{#property:P625|from=<Qitem>}} |, | 1}} pour la longitude
{{str split|{{#property:P625|from=<Qitem>}} |, | 2}} pour la latitude

Ce qui donnerait pour la gare de Paris-Saint-Lazare :

{{str split|{{#property:P625|from=Q747506}} |, | 1}} → 48°52'37"N pour la longitude
{{str split|{{#property:P625|from=Q747506}} |, | 2}} → 2°19'28"E pour la latitude

Il me reste deux choses à trouver :

récupérer automatiquement le numéro d'item Wikidata à partir du nom de la gare Paris-Saint-Lazare" → Q747506
transformer les coordonnées DMS de la forme 35°23'8.07421"N à la forme N|35|23| 8.07421 qui est la forme des paramètres du modèle {{Coord/dms2dec}} pour convertir des coordonnées DMS en coordonnées décimales (nécessaires pour le modèle {{G}})

--Poudou! (discuter) 2 juillet 2023 à 20:04 (CEST)[répondre]

@Poudou!

Récupérer le numéro d'item n'est pas faisable par un module / modèle. Ca doit être fait manuellement ou par un bot.

Le mot magique {{#property:}} ne permet pas de traiter les donner sous forme de tableau. Il faut utiliser Module:Wikidata à la place, qui permettra naturellement de séparer les coordonnées.

Exemple de code lua pour Paris Saint-Lazare :

local wd = require("Module:Wikidata")
table = wd.getClaims({entity="Q747506", property="P625"})
latitude = table[1]["mainsnak"]["datavalue"]["value"]["latitude"]
longitude = table[1]["mainsnak"]["datavalue"]["value"]["longitude"]
precision = table[1]["mainsnak"]["datavalue"]["value"]["precision"]

donne respectivement 48.876944444444, 2.3244444444444 et 0.00027777777777778.

Le traitement effectué par le modèle {{Coord/dms2dec}} peut aussi être effectué en lua. Escargot (discuter) 2 juillet 2023 à 21:29 (CEST)[répondre]

Merci @Escargot bleu pour ces conseils.

Je vais donc me pencher sur le développement de module Lua (je sentais bien que j'allais y passer tôt ou tard). --Poudou! (discuter) 2 juillet 2023 à 22:04 (CEST)[répondre]

@Escargot bleu : voila ce que cela donne (dans mes brouillons) :

le module : Utilisateur:Poudou!/hello| WD_Coord → retourne les valeurs "latitude" et "longitude" sous la forme d'un couple "latitude ; longitude"
le modèle : Utilisateur:Poudou!/WD_Coord → retourne une des deux valeurs "latitude" ou "longitude"
la page de brouillon : Utilisateur:Poudou!/Brouillon/Modèle WD Coord test le modèle et le module

Vous en pensez-quoi ? Ça serait correct ? --Poudou! (discuter) 3 juillet 2023 à 01:31 (CEST)[répondre]

@Poudou! Le modèle fonctionne ! Ce n'est pas très propre ni optimisé de fusionner les deux coordonnées pour ensuite les reséparer. Il faudrait plutôt créer deux fonctions p.latitude(frame) et p.longitude(frame) renvoyant respectivement latitude et longitude et appeler soit l'une soit l'autre dans le modèle.

Habituellement, on place les imports de module en début de code, à part ça c'est du lua correct. Escargot (discuter) 3 juillet 2023 à 09:38 (CEST)[répondre]

@Escargot bleu

J'ai modifié (et renommé) le module : Utilisateur:Poudou!/WD_Coord avec deux fonctions "Lat" et "Lon".

Je n'ai pas bien saisi votre remarque : « Habituellement, on place les imports de module en début de code » (le problème d'apprentissage d'un nouveau langage de programmation ce n'est pas tant de le maitriser mais de savoir l'utiliser pour résoudre un problème, de concevoir l'algorithme pour l'implémenter et surtout dans un contexte de données et de structures. Là, il faut avouer que le contexte Wikipedia/Wikidata n'est pas trivial).--Poudou! (discuter) 3 juillet 2023 à 22:02 (CEST)[répondre]

C'est juste une manière d'organiser le code, ça ne change pas forcément grand chose à son fonctionnement. Ca permet de voir rapidement quelles bibliothèques externes sont appelées par le code. J'ai fait la modification en question.

Bien sûr, ce n'est pas simple. Je retourne sur la page mw:Extension:Scribunto/Lua reference manual/fr très fréquemment. ChatGPT peut aussi aider à comprendre le fonctionnement de base du lua. (Mais il a tendance à se tromper sur ce que font les fonctions propres à wikipédia). Escargot (discuter) 3 juillet 2023 à 22:35 (CEST)[répondre]

@Escargot bleu

J'ai mis au point une requête SPARQL qui extrait de Wikidata les Qid et les Noms de toutes les gares ferroviaires situées en Algérie. J'ai mis le résutat dans une liste à l'intérieur du modèle : Utilisateur:Poudou!/SNTF/WD_GetId (il fera partie des modèles SNTF liés aux gares de la SNTF, comme modèle:SNTF et modèle:SNTF/switch).

J'ai testé dans mon brouillon : Utilisateur:Poudou!/Brouillon/Modèle WD Coord , ça marche.

Idéalement, il faudrait développer directement un module dans Wikidata qui retourne le Qid d'une gare. Mais à ce stade, j'ai de quoi être contenté pour continuer mon travail de positionnement de plusieurs gares sur des cartes géolocalisées. --Poudou! (discuter) 4 juillet 2023 à 11:31 (CEST)[répondre]

┌──────────────────┘
Si vous n'y voyez pas d'inconvénient, je clos ma demande en considérant réalisée. --Poudou! (discuter) 5 juillet 2023 à 05:46 (CEST)[répondre]

Amélioration du modèle Suppression Immédiate 2

Travail demandé par 80.214.20.127 (discuter) 6 juillet 2023 à 20:16 (CEST)[répondre]

Avancement :
0 %
Détails de la demande : Bonsoir, cette amélioration du modèle contient 2 nouveautés : La première c’est le texte qui devient plus intelligent qu’avant : quand on pose le modèle par exemple, sur un article, ça affichera "a demandé la suppression immédiate de cet article…", quand on le pose sur une sous page d’utilisateur, ça affichera "…de cette sous-page utilisateur…", etc… ; et la deuxième c’est une deuxième instruction (comme sur Wikipédia en anglais) d’insérer un modèle BSI pour avertir le créateur que la page va être supprimée. Voici le code à copier dans le bac à sable sauf {{Utilisateur:80.215.38.27/Mon modèle ^{(page supprimée)}}} qui est un modèle personnel et la page de test ^{(page supprimée)} pour voir à quoi ressemble ce modèle. J’ai également fait ces expériences sur une fausse page de demande de suppression ^{(page supprimée)} et une fausse page de discussion ^{(page supprimée)}. Est-ce que tout est correct pour copier tout le code ?
Discussions :

[1] [Strait, Grine & Fleagle 2015] (en) David Strait, Frederick Grine et John Fleagle, « Analyzing Hominin Phylogeny : Cladistic Approach », dans Winfried Henke & Ian Tattersall, Handbook of Paleoanthropology, janvier 2015 (ISBN 9783642399787, lire en ligne), p. 1989-2014.

[2] [Meyer et al. 2016] (en) Matthias Meyer et al., « Nuclear DNA sequences from the Middle Pleistocene Sima de los Huesos hominins », Nature, vol. 531, n^o 7595,‎ mars 2016, p. 504-507 (DOI 10.1038/nature17405, résumé).

[1]

[2]

v · m Demander
Demander…	un article une traduction une fusion une scission un modèle (infobox géolocalisation boîte utilisateur) une illustration (photographie image carte logo blason animation) une relecture
Requêtes à…	un administrateur un arbitre un agent VRT un robot un bureaucrate un vérificateur d’adresses IP un modificateur de filtre anti-erreur
Requêtes pour…	bloquer un vandale supprimer une page restaurer une page protéger une page effectuer une modification sur une page protégée effectuer une modification d'un message système renommer une page masquer des modifications une fusion d'historiques autoriser l'utilisation de contenu protégé

Projet:Modèle/Demandes

Modules pour les populations des communes de France

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

Réf Bible : auteur=Rabbinat

Bug dans le modèle {{Stations voisines}}

Modification du modèle « Température »

Modèle:Ouvrage

Traduction du modèle Plantilla:Gráfico de audiencias en televisión (es) en français

retouche des modèles Base POP Palissy, Base Palissy

Aéroport-Statistiques

Ajout de modèles en lien vers les forces armées dans système country

Infobox géoloc

Statut UICN DD

Modèle:Données de la pandémie de Covid-19

Modèle:Brouillon relecture

Notice de la British Library

Modèle:Page à publier

Modèle:Lien à publier

Aube de l'humanité

Références

Géoloc complexe

Modèle:Ajouter du texte

Amélioration du modèle Suppression Immédiate

Modèles permettant d'obtenir les coordonnées latitude et longitude d'une gare

Amélioration du modèle Suppression Immédiate 2

Modèle « Article » : paramètre `accès url`