Discussion Projet:Modèle

Bonjour, Le modèle {{Problèmes multiples}} a lui-même un problème notable : la liste des problèmes, visible sur la version de bureau, n'est pas visible sur le version mobile. Voir par exemple dans l'article Institut de minéralogie, de physique des matériaux et de cosmochimie. Pourriez-vous arranger ça ? Merci d'avance. SenseiAC (discuter) 22 mai 2025 à 14:09 (CEST)

L'explication est la présence d'une classe nomobile, qui a été ajoutée au début de l'année ; refs 221871657, 222192510, ainsi que cette discussion. Ping @Escargot. od†n ↗^blah 22 mai 2025 à 14:56 (CEST)

Merci Od1n pour cette explication. Escargot bleu, cette décision manifestement unilatérale de ta part me semble plus que discutable. Un commentaire ? En l'absence de réaction, je supprimerai ce "nomobile" tout aussi unilatéralement qu'il a été ajouté, les lecteurs sur mobiles n'ayant pas lieu de ne pas être informés (encore moins s'ils veulent aider à résoudre lesdits problèmes). Il y a déjà suffisamment de problèmes sur la version mobile (en particulier d'innombrables trucs dont on ne peut que déplorer l'absence d'affichage), ce n'est vraiment pas une bonne idée d'en ajouter encore plus... SenseiAC (discuter) 21 septembre 2025 à 23:33 (CEST)

Je serais aussi d'avis de rétablir ce contenu. Certes, cela rend le bandeau gros, voire très gros (mais voilà, c'est qu'il y a des problèmes et qu'il faut les corriger), mais c'est préférable à n'avoir rien d'autre que le texte « Cet article présente des problèmes à corriger. »… et débrouillez-vous pour savoir c'est quoi qu'il faut corriger, lol. od†n ↗^blah 23 septembre 2025 à 12:58 (CEST)

Idéalement, il faudrait un paramètre classe texte ou affichage mobile qui permette de dire selon le cas s'il faut ajouter la classe nomobile pour que le texte ne s'affiche pas, les classes mw-collapsible mw-collapsed pour que le contenu soit caché mais affichable, ou ne rien ajouter du tout.

Comme cas problématiques avec l'utilisation de nomobile, il y a aussi les bandeaux entrés manuellement comme dans Wikipédia:Que faire en cas d'urgence ?. Escargot (discuter) 23 septembre 2025 à 21:33 (CEST)

L'ajout d'un paramètre classe texte / affichage mobile me semble être une fausse bonne idée : cela ferait un truc de plus à considérer (et éventuellement devoir modifier ultérieurement) pour les rédacteurs, et je crains qu'il y aurait un certain nombre, grandissant au fil du temps, de mauvaises utilisations (classe manquante ou au contraire inadéquatement présente). Et surtout, je ne vois pas vraiment de situation où il serait souhaitable de supprimer ces informations. Enfin, les smartphones sont aujourd'hui très gros (beaucoup trop à mon goût d'ailleurs, c'est horrible à se trimballer), et les utilisateurs sont habitués à scroller (et pas qu'un peu, n'est-ce pas).

Pour ce qui est d'ajouter un système de collapsing, ça semble intéressant, mais je n'ai pas d'idée concernant la faisabilité, et en tout cas, je crains que cela irait fortement compliquer le code : le markup des bandeaux est déjà assez délicat / difficile à gérer, les systèmes de collapsing ont eux aussi une certaine complexité, je crains que la multiplication des deux complexités fasse mauvais ménage ; sans compter qu'en plus ils reçoivent des modifications au fil du temps, donc ça ferait de la maintenance difficile supplémentaire.

Je serais d'avis de simplement supprimer cette classe nomobile et c'est réglé.

od†n ↗^blah 24 septembre 2025 à 09:06 (CEST)

Bonjour, en voulant réparer un lien de renvoi bibliographique erroné, j'ai trouvé un ouvrage (diff) dont le paramètre année ne s'affichait pas. Au final, il s'agit d'un problème d'espace invisible à l'oeil nu (diff), reproduit ci-dessous. C'est la première fois que je tombe sur ce cas de figure, est-ce qu'on sait le détecter à plus grande échelle ? Merci. ~2025-41226-7 (discuter) 21 août 2025 à 01:56 (CEST)

• Benoît Rondeau, L'armée allemande 1870-1945 : Grandeur et chute d'une force implacable, Paris, Buchet-Chastel, 351 p. (ISBN 978-2-283-03792-8). 
• Benoît Rondeau, L'armée allemande 1870-1945 : Grandeur et chute d'une force implacable, Paris, Buchet-Chastel, 2024, 351 p. (ISBN 978-2-283-03792-8). 

~2025-41226-7 (discuter) 21 août 2025 à 01:56 (CEST)

Ce n'est pas une espace invisible, mais une espace insécable.

À noter qu'il y a dans les deux exemples ci-dessus la même espace avant le paramètre langue, mais ça ne se remarque pas, car si la langue est le français, elle n'est pas affichée.

J'ai trouvé une tâche similaire sur Phabricator (, ouverte depuis décembre 2020), mais là, c'est une espace entre le paramètre et le signe égal qui rend le paramètre inactif.

Il faudrait demander à  Conteur-momentanement-indisponible comment il a mis cette espace, car a priori ce n'est pas quelque chose qu'on puisse ajouter facilement.

Sinon, je ne sais pas comment détecter ça avec les moyens à ma disposition. AWB ne reconnait pas ce caractère quand on a Uncodify whole page activé. Şÿℵדαχ₮ɘɼɾ๏ʁ, jeudi 21 août 2025 à 13:24 (CEST)

 SyntaxTerror : Bonjour, Je ne sais pas, je me suis juste contenté de faire des copier-coller et de modifier en conséquence. Cette méthode me donne parfois des surprises désagréables, mais bon... Bonne journée. Le Conteur (Livre de contes) 18 octobre 2025 à 12:09 (CEST)

Bonjour très chers modélistes, Existe-t-il un (ou plusieurs) modèle destiné à être envoyé sur une page utilisateur pour l'avertir spécifiquement qu'il pratique un caviardage ?

J'ai récemment ressenti le besoin d'avertir un utilisateur sur cette forme particulière de vandalisme. S'il n'en existe pas, je vous demande s'il est possible d'en faire deux (un premier pour avertir "gentiment" et un second pour avertir en guise de rappel un peu plus sévèrement) dans le genre par exemple de {{Faux décès}} et {{Faux décès 2}}.

Merci d'avance de l'attention que vous porterez à ma demande . Wikipédiennement, --Dr anakin775 ^[Allô ?] 22 septembre 2025 à 17:05 (CEST)

Bonjour @Dr anakin775, Modèle:Test 2- ? — Pharma ^💬 24 septembre 2025 à 22:54 (CEST)

Bonsoir @Pharma, j'imagine que ça peut marcher mais le modèle n'est pas centré sur le caviardage. Ça évoque un retrait vandalisant, je pensais davantage à un modèle d'avertissement évoquant directement le caviardage et mettant en garde sur la pratique avec si besoin une version plus sévère en cas de récidive.

Merci quand même . Wikipédiennement, --Dr anakin775 ^[Allô ?] 24 septembre 2025 à 23:12 (CEST)

Bonjour les modélistes et @Wh160,

Je découvre avec perplexité l'attribut deprecated, ajouté à {{Ouvrage}} (après l'ajout de cette précision). Ne fait-il pas carrément disparaître les paramètres (en l'occurence extrait et commentaire) ? Ce serait excessif, alors que ces paramètres ne sont pas vraiment obsolètes (voir, dans mon commentaire, Discussion modèle:Article#Modèles citation et commentaire, alias en anglais). Salutations — Vega (discuter) 23 septembre 2025 à 14:38 (CEST)

Bonjour, je n'ai fait cela que parce que c'était fait comme cela sur article (en plus de changer préalablement le libellé qui lui n'apporte aucune contrainte, y compris pour les novices dans un système qui garde le commentaire s'il existe - ce que je viens de vérifier sur Abbaye Notre-Dame de Sénanque-), c'est parfaitement réversible le jour où les commentaires et citations sont re-admises, (mais rien n'a bougé depuis 1 an). Wh160 (discuter) 23 septembre 2025 à 15:29 (CEST)

Bonjour, Problème analogue à celui déjà signalé pour d'autres modèles, cette fois-ci avec {{Infobox Conflit militaire}} : voir par exemple Seconde guerre médique, avec "Guerres médiques", "Batailles" et le nom des batailles listées qui, sur mobile, apparaissent plus gros que le reste. Merci d'avance si vous pouvez régler le problème. SenseiAC (discuter) 13 novembre 2025 à 03:56 (CET)

C'est causé par cette règle :

.mf-font-size-clientpref-small .mw-body p,
.mf-font-size-clientpref-small .content p {
  font-size: 1rem;
}

… qui override notre .infobox_v3 { font-size: 0.9em; }.

Et cela vient encore de cete saloperie de MobileFrontend : resources/mobile.init.styles/mobile.less.

Il faudrait donc — encore — ajouter une rustine à cause du MobileFrontend, et c'est complexifié par le fait qu'il existe plusieurs tailles de texes (.mf-font-size-clientpref-regular, etc.) (d'ailleurs, c'est censé pouvoir se choisir où ça ?) et en prime deux conteneurs, ce qui conduit à une "multiplication" des sélecteurs.

Un truc dans le genre :

/*
veiller à avoir la priorité sur ces sélecteurs du MobileFrontend :
.mf-font-size-clientpref-small .mw-body p,
.mf-font-size-clientpref-small .content p
*/
body.mw-mf .mw-body p,
body.mw-mf .content p {
	font-size: 0.9em;
}

Ah, et il y a aussi des « line-height », j'imagine que ça aussi ça va aller poser problème.

Oui, c'est lourd et sale. Comme d'hab' à chaque fois qu'il faut "défaire" le MobileFrontend.

À propos, je viens de remarquer que le Common.css est maintenant aussi chargé sur mobile. Ce changement brutal (alors qu'il aurait été possible d'aider à la transition en procédant par étapes, ce qui aurait été vraiment appréciable) était effectivement prévu, mais là ils l'ont fait sans prévenir sans rien. Pour ce qui est de la migration pour les wikis, c'est « on a fait le changement, démerdez-vous ». Bon courage à ceux qui vont essayer de démêler tout ça.

od†n ↗^blah 13 novembre 2025 à 13:30 (CET)

 Od1n : problème analogue sur {{Infobox Musique (style)}} (voir par exemple Reggae). SenseiAC (discuter) 24 novembre 2025 à 15:02 (CET)

Bonjour

Au moins sur wp.en et wp.de, les templatedata peuvent utiliser des liens et modèles wiki et des balises HTML dans les champs des templatedata.

Y a-t-il une raison pour laquelle on ne peut pas le faire ici ?

Ce serait une amélioration notable, car bien souvent, on a besoin de mettre des liens (vers des modèles similaires par exemple), d'utiliser des modèles de mise en forme ({{1er}}, {{nobr}}, etc.) ou des balises HTML (<br>, etc.). Ça permettrait une importation plus facile des documentations d'autres langues également.

Le seul problème que je vois est qu'il faudrait passer avec un bot pour ajouter des balises <nowiki> à celles déjà existantes (j'ai mis une <br> dans la doc de {{Liste simple}} par exemple), et éventuellement des {{m}} si on a des doubles crochets, mais les cas ne doivent pas être si nombreux a priori.

Merci pour vos avis éclairés, je ne suis pas très fort en JSON.

Bonne journée, Şÿℵדαχ₮ɘɼɾ๏ʁ, vendredi 12 décembre 2025 à 09:15 (CET)

Tu as des exemples de ça ? Je ne pense pas que ces choses soient interprétées par l'éditeur visuel, ce qui poserait problème à l'utilisation. Ce que j'ai trouvé c'est des modèles comme en:Template:Format TemplateData qui prennent en paramètre du json et le formatent dans la doc, sans doute en plus de générer la balise <templatedata> à partir de ses paramètres, mais c'est tout. Exemple d'utilisation : en:Template:National_football_squad_player — TomT0m ^[bla] 12 décembre 2025 à 15:48 (CET)

@TomT0m : ça m'est arrivé deux fois hier :

• de:Vorlage:Str match/Doku (wp.de utilise le modèle de:Vorlage:TemplateData)
• en:Template:Number table sorting hidden/doc (balises <templatedata> classiques) [EDIT : ha non, il y a un en:Template:Format TemplateData, j'avais pas remarqué... ]

Ça serait pas mal si on pouvait avoir au moins la syntaxe wiki pour l'éditeur classique (m'en fous un peu de l'éditeur visuel ).

Şÿℵדαχ₮ɘɼɾ๏ʁ, vendredi 12 décembre 2025 à 16:10 (CET)

Ça passe effectivement par le modèle "Format Templatedata" qui formate pour la documentation, et doit regénérer du templatedata . On y trouve une fonction flat qui supprime le formatage pour générer le templatedata final pour l'EV. Je ne pense pas que l'éditeur classique l'utilise, tu as de la doc quand tu veux insérer un modèle ? — TomT0m ^[bla] 12 décembre 2025 à 18:04 (CET)

@TomT0m : j'avais pas vu le modèle sur wp.en.

Je suis en train d'importer leurs modules et modèles, c'est un sacré boxon, mais je suis pas encore tombé sur des incompatibilités de modules. Je croise les doigts.

cf. {{TemplateData}}

Je voulais cette fonction depuis un moment , ça vaut le coup de traduire tout ça.

Şÿℵדαχ₮ɘɼɾ๏ʁ, vendredi 12 décembre 2025 à 18:16 (CET)

Bonjour, Il y a manifestement un problème avec le "sticky header". Niivlem a annulé ma modif ajoutant ledit "sticky header" sur un article. Il prétend que le modèle "ne marche ni sur l'ordi, ni sur l'appli" et que ça rendrait "la lecture sur ordinateur bien moins pratique". Cependant, de mon côté, le modèle fonctionne comme il se doit sur la version de bureau de Wikipédia (aussi bien sur mon ordi que sur mon téléphone), et c'est bien plus pratique d'avoir le header visible à tout niveau qu'être obligé de remonter tout le tableau pour voir l'entête, donc l'affirmation est erronée en prétendant sans nuance un problème général. Si le modèle n'avait pas fonctionné correctement quand je l'ai ajouté, je n'aurais pas fait le changement ; à ce titre ça me rassure que ça fonctionne toujours sur la version de bureau (j'avais fait ce changement sur mon ordi, où c'est l'affichage par défaut). Par contre, je me dois de constater que, de mon côté, il y a un problème sur la version mobile (découvert aujourd'hui en voyant sur mon téléphone l'annulation faite par Niivlem) : sur mon ordinateur, le tableau est correctement fermé, mais le "header" ne reste pas collé ; et sur mon téléphone (où la version mobile est la version par défaut), le "header" n'est pas collé et il manque en outre la ligne fermant le tableau à droite. Plutôt qu'un problème général ou une absence de problème générale, il semble donc qu'il y ait des problèmes avec certaines configurations et pas d'autres. Il faudrait donc ajuster le modèle afin qu'il fonctionne correctement dans toutes les situations (bureau/mobile, ordi/téléphone/appli, etc.) plutôt qu'annuler purement et simplement son utilisation. Merci d'avance.
P.-S. Niivlem : ton annulation sans nuance a enlevé du même coup le "sortable" qui rend le tableau triable, alors que ce tri fonctionne correctement partout et qu'il est indépendant du "sticky header". Ton annulation a du même coup rétabli la disposition en trois tableaux, qui empêche bien évidemment toute possibilité de tri général pour qui voudrait la liste triée selon le nombre de sénateurs et non selon l'ordre des départements. Je t'invite donc à faire preuve d'un peu plus de discernement avant d'annuler de façon globale des modifications. Merci d'avance.
SenseiAC (discuter) 12 décembre 2025 à 15:38 (CET)

Bonjour @SenseiAC,

J'ai bien conscience que la disposition en 3 tableaux que j'ai rétabli a également ses défauts que tu as d'ailleurs mentionnés, j'ai annulé ta modification car cela me semblait être la meilleure chose à faire, et j'ai essayé de résumer ça dans la note de modification ce qui me limitait dans ce que je pouvais dire. En l'occurrence le fait d'avoir une illustration puis un tableau tout en longueur dont le "sticky head" ne suivait pas, rendait la lecture du tableau et de la carte moins évidente, je suis désolé si mon annulation a pu paraitre brutale, la création d'une mise en page intermédiaire à mi-chemin entre les deux me semblant assez compliqué à mettre en place, j'ai, comme dit précédemment, fait ce qui me semblait être le mieux. A noter que j'ai considérer que la lisibilité était détériorée mais pas complètement impossible, j'ai simplement estimé que les gains ne compensaient pas les pertes, mais si mon avis n'est pas partagé, il est évident que je ne ferai pas de passage en force.

Pour développer un peu sur le "sticky head", celui-ci ne fonctionnait effectivement pas sur la version bureau (ou ordi), lorsque je suis allé sur la page tout à l'heure, en me rendant dans l'historique de la page pour revérifier puisque tu dis de ton coté que ça marche, il s'avère que cette fois, ça marche également. Alors erreur de ma part, bug d'affichage de mon ordinateur ou autre chose, je n'en sais rien. Je maintiens toutefois que lorsque je passe par l'application iOS, le "sticky head" ne marche purement simplement pas, quand à la version mobile sans appli je ne l'avait pas testée. Niivlem (discuter) 12 décembre 2025 à 16:06 (CET)

Bonjour, En voulant remercier Niivlem pour sa réponse au-dessus, j'ai remarqué que sur le téléphone (version mobile) ça pose problème : j'ai un début de phrase qui s'affiche, mais impossible de faire glisser l'affichage pour voir la fin et les boutons pour "remercier"/"annuler", sauf (et c'est vraiment un coup de bol que j'aie essayé ça) en surlignant le texte en glissant vers la droite. Ce n'est vraiment pas pratique et intuitif comme façon de faire, contrairement à sur la version de bureau. SenseiAC (discuter) 12 décembre 2025 à 16:32 (CET)

Bonjour

Je viens d'importer de wp.en le modèle:clc qui permet d'avoir un lien vers une catégorie et le nombre d'articles dans cette catégorie.

Ça peut être utile pour avoir un œil sur les catégories de maintenance, ou bien pour afficher la catégorie de maintenance associée à un modèle sur sa page de documentation.

Par exemple : {{clc|Page avec code de langue invalide}} donne : Catégorie:Page avec code de langue invalide (1)

On peut bien sûr aussi se servir d'{{Utilisateur:OrlodrimBot/Suivi catégorie}} si on veut les liens vers les articles récemment ajoutés.

Bonne journée, Şÿℵדαχ₮ɘɼɾ๏ʁ, vendredi 12 décembre 2025 à 18:41 (CET)

Bonjour @SyntaxTerror, ça m'intéresse ! Quelle différence avec le mot magique PAGESINCATEGORY ? Je peine à la saisir en regardant le code du modèle — non pas qu'il soit mal fait, mais mes connaissances sont limitées  —. Également, je ne comprends pas l'exemple du « nom alternatif ». Bien à toi, Pharma ^💬 29 décembre 2025 à 01:05 (CET)

Bonjour Pharma.

Ce modèle est bien l'équivalent de [[:Catégorie:Page avec code de langue invalide]] ({{PAGESINCATEGORY:Catégorie:Page avec code de langue invalide}}).

Le code du modèle est en effet un peu complexe. J'ai recopié le modèle depuis en:Template:Category link with count, les appels au module:string ne servent qu'à mettre en forme le texte et à ce qu'il soit possible de mettre ou non Catégorie:.

Quant au « nom alternatif », je viens de me rendre compte que j'avais mal traduit la documentation pour l'exemple.

Voilà le résultat attendu : {{clc|Côte-d'Or|nom=Cd'O}} donne : Cd'O (32)

Bonne journée et joyeuses fêtes, Şÿℵדαχ₮ɘɼɾ๏ʁ, lundi 29 décembre 2025 à 03:58 (CET)

Bonjour,
Je me demandais pourquoi le modèle {{sticky header}} n'était pas ajouté par défaut dans les modèles de création de tableaux.
Ce modèle est très utile lors de la navigation sur Wikipédia (se repérer dans chaque colonne sans devoir remonter, pareil pour les trier) et je n'y vois aucuns inconvenants.
Qu'en pensez-vous ? - Musstruss (discuter) 2 janvier 2026 à 20:41 (CET)

Bonsoir, intuitivement je dirais qu'il y a sans doute des problématiques d'accessibilité derrière. Je pense par exemple aux utilisateurs sur mobile dont l'écran est trop petit pour se permettre de « gâcher » 1 cm d'espace de manière permanente. Vous pouvez vous tourner vers l'atelier accessibilité pour vérifier si mon intuition est juste, et ils pourront peut-être même vous en dire plus. Cordialement — V_VL_LA_AC_C 2 janvier 2026 à 23:01 (CET)

Bonjour à tous,

Pourquoi est-ce que le modèle {{voir homonymes}} affiche pour les articles homonymes et les modèles dérivés, du genre {{2autres}}, affichent Pour les autres significations ?

Je me dis que c'est parce qu'un modèle comme {{2autres}} a déjà listé un autre article homonyme mais c'est parfois beaucoup moins pertinent. Par exemple, quand j'utilise sur la page 7e régiment d'artillerie à pied (1910-1918) ça donne « Pour le 7^e régiment d'artillerie à pied existant au XIX^e siècle, voir 7^e régiment d'artillerie (France). Pour les autres significations, voir 7^e régiment. » Ce qui est étrange car les autres 7e régiment d'artillerie à pied et 7e régiment d'artillerie listés sur la page d'homonymie 7^e régiment ne sont pas des autres significations mais des articles homonymes (ou quasi-homonymes).

Je sais que je peux modifier la mise en forme avec un paramètre dédié, au cas par cas, mais je pense que, dans le cas général, il faut mieux pour les articles homonymes. Le Petit Chat (discuter) 10 janvier 2026 à 16:57 (CET)

Bonjour Le Petit Chat. Dis-toi bien que si on change le texte affiché, toutes les pages où ce modèle est présent seront affectées, avec sans doute des formulations qui vont devenir bizarres.

On a affaire à presque 700 000 pages , toutes les vérifier est virtuellement impossible.

Même si les différents modèles ne sont pas exactement identiques, ça nous oblige à garder le texte affiché comme il est.

Comme tu dis, il existe un paramètre dédié pour changer la formulation, donc il n'y a pas vraiment de problème. Şÿℵדαχ₮ɘɼɾ๏ʁ, samedi 10 janvier 2026 à 18:03 (CET)

Justement  SyntaxTerror je pense qu'il faudrait tout changer car Pour les articles homonymes me paraît, dans tous les cas, au moins autant (et souvent plus) adapté que Pour les autres significations. Le Petit Chat (discuter) 10 janvier 2026 à 19:54 (CET)

Attendons de voir les avis des autres modélistes.

Je ne vois pas vraiment l'intérêt d'une telle modif, étant donné qu'on peut faire afficher le texte qu'on veut et qu'il vaut mieux éviter de vouloir réparer ce qui n'est pas cassé. Şÿℵדαχ₮ɘɼɾ๏ʁ, samedi 10 janvier 2026 à 22:17 (CET)

Hello,

si je comprends bien, l'idée serait de modifier le texte du modèle {{2autres}}. Celui-ci n'a "que" 2000 utilisations dans des articles (voir ici), soit bien moins que {{voir homonymes}}.

Ceci dit, je ne suis pas sûr que ce soit plus (ou moins) compréhensible, il me semble qu'il s'agit d'une distinction mineure.

Epok (✉), le 10 janvier 2026 à 22:35 (CET)

Bonjour,

L’article « Modèle:Décoration » fait l'objet d'un débat d'admissibilité (cf. Wikipédia:Débat d'admissibilité). Il débouchera sur la conservation, la suppression ou la fusion de l'article. Après avoir pris connaissance des critères généraux d’admissibilité des articles et des critères spécifiques, vous pourrez donner votre avis sur la page de discussion Discussion modèle:Décoration/Admissibilité.

Le meilleur moyen d’obtenir un consensus pour la conservation de l’article est de fournir des sources secondaires fiables et indépendantes. Si vous ne pouvez trouver de telles sources, c’est que l’article n’est probablement pas admissible. N’oubliez pas que les principes fondateurs de Wikipédia ne garantissent aucun droit à avoir un article sur Wikipédia.

Accéder au débat

Şÿℵדαχ₮ɘɼɾ๏ʁ, jeudi 15 janvier 2026 à 12:58 (CET)

Bonjour

Il y a un problème avec le modèle:Magazine et les langues multiples dans le paramètre langue dans Futur simple en français#Monographies.

Il y a une erreur de code langue dans l'article alors qu'elle ne se déclenche pas ici :

• {{Magazine|langue=en+fr|périodique=Canadian Journal of Linguistics / Revue canadienne de linguistique|volume=61|numéro=3|année=2016|titre numéro=Future temporal reference in French / La référence temporelle au futur en français}}.
  • donne « Canadian Journal of Linguistics / Revue canadienne de linguistique, vol. 61, n^o 3 « Future temporal reference in French / La référence temporelle au futur en français », 2016. »

Je n'ai pas trouvé d'où venait l'erreur, par contre je trouve assez bizarre d'appeler des modèles ainsi :

• {{Module biblio/identifiants normalisés internationaux}}
• {{Module biblio/indication de langue}}
• {{Module biblio/libellé}}
• {{Module biblio/responsabilité principale}}
• {{Module biblio/responsabilité principale/responsable}}
• {{Module biblio/responsabilité secondaire}}
• {{Module biblio/span initial}}

Si on ne connait pas la finesse du truc, ça complique juste les choses, surtout que ces faux modules n'invoquent même pas le module:Biblio à ce que j'en ai compris.

Je n'ai pas corrigé l'erreur sur Futur simple en français#Monographies, c'est le modèle:Magazine qui doit être corrigé.

Il serait sans doute préférable de faire vraiment prendre en charge ce modèle par le module:Biblio, mais ça semble beaucoup de travail pour une utilisation modérée (478 utilisations sur 256 pages ). On pourrait aussi le supprimer et le remplacer par {{article}}, comme proposé par  Berdea dans Discussion modèle:Magazine#Pertinence du modèle et présentation à revoir.

Bonne journée, Şÿℵדαχ₮ɘɼɾ๏ʁ, mercredi 11 mars 2026 à 14:58 (CET)