Discussion Projet:Modèle

Une page de Wikipédia, l'encyclopédie libre.
Sauter à la navigation Sauter à la recherche
Le salon des modélistes

Questions générales. On discute du projet modèle.

Afin de vous assurer que vous faites votre demande au bon endroit, veuillez consulter l’encadré ci-dessous et déterminer si vous postez au bon endroit.

Le salon des modélistes concerne principalement les discussions à propos du projet, mais aussi les questions générales portant sur les modèles si les différentes rubriques d’aide n’y répondent pas. Toute demande qui aurait dû être faite dans l’une des pages mentionnées ci-dessous n’est pas faite au bon endroit, elle pourrait être ignorée.

Question aux modélistes

Annonces (section remplie automatiquement)

OOjs UI icon block-destructive.svg Modèles proposés à la suppression

OOjs UI icon articles-ltr-progressive.svg Nouveaux modèles

OOjs UI icon bell.svg Le projet « Modèle » n'est pas notifié pour le moment.

Fait {{Date de décès}}[modifier le code]

Bonjour,

Le modèle devrait être converti en Lua comme {{Date de naissance}}, aucune objection ?

Cela permettra entre autre d'utiliser le paramètre républicain=ouieru [Discuter] 23 février 2020 à 09:38 (CET)

Bonsoir Eru Bonsoir C'est déjà le cas puisque ce modèle utilise {{date}} et donc Module:Date. Il devrait suffire de lui transférer ce paramètre. --FDo64 (discuter) 23 février 2020 à 23:16 (CET)
Oui, on pourrait s’embêter à ajouter ce paramètre à la main comme julien, puis le suivant, puis le suivant...
Autant mettre une fois pour toute : <includeonly>{{#invoke:Date|modeleDate|mort=1}}</includeonly><noinclude>{{Documentation}}</noinclude>eru [Discuter] 24 février 2020 à 08:03 (CET)
Bonsoir Eru Bonsoir Malheureusement ça ne fonctionne pas. J'ai aussi tenté sans succès :
{{#invoke:Date|modeleDate|mort=1|âge={{#if:{{{5|}}}|oui}}|qualificatif={{{7|}}}}} mais la date de naissance n'est pas utilisée.
{{#invoke:Date|dateInfobox|mort|1={{{4|}}} {{{5|}}} {{{6|}}}|2={{{1|}}} {{{2|}}} {{{3|}}}|qualificatif={{{7|}}}}} : rien ne va.
Si tu arrives à mettre au point quelque chose dans le bac à sable, je veux bien le mettre en place ensuite.
--FDo64 (discuter) 24 février 2020 à 22:48 (CET)
Effectivement c'est plus compliqué que je pensais, j'aurais dû tester avant, je reviens vers vous quand j'ai trouvé une solution. — eru [Discuter] 24 février 2020 à 23:05 (CET)
┌─────────────────────────────────────────────────┘
Pour l'instant je n'ai trouvé que cette solution, le résultat est correct, mais l'âge est toujours géré via l'appel au modèle {{âge}}.
Voir la page de test.
Il faudrait surement modifier la fonction modeleDate du module Date pour pouvoir automatiser le calcule, l'utilisation de la fonction dateInfobox modifie l'affichage des dates juliennes — eru [Discuter] 29 février 2020 à 11:34 (CET)
Bonsoir Eru Bonsoir. Pour information, j’ai corrigé la page de test et simplifié le bac à sable. Peux-tu me confirmer que c’est correct ?
Pour ce qui serait de faire évoluer le module, je ne sais pas faire.
--FDo64 (discuter) 3 mars 2020 à 22:53 (CET)
Merci FDo64 Clin d'œil, mais en mettant qualificatif= les testes ne fonctionnent plus à part le 5, c'est pour ça que j'avais été obligé de remettre tous les paramètres.
En faite le paramètre qualificatif ne fonctionnait pas pour modeleDate, il prenait toujours les arguments 4 ou 5 même si vide.
Je me suis re-penché dessus et j'ai trouvé ce correctif, les arguments n'étaient pas dans le bon ordre.
Cependant du coup le test 5 ne fonctionne plus, ce qui oblige cette modification...
Bref je revérifierais demain si je trouve une solution plus simple, mais pour l'instant je ne comprend pas pourquoi params.qualificatif = args.qualificatif or params.qualificatif ne fonctionne pas.
Le test 17 permet de vérifier que cela n'impacte pas le modèle {{Date de naissance}}.
Pour la modification du module afin de calculer l'âge, je ne pense pas que cela vaille le coup, le principal est que la date prenne tous les paramètres. — eru [Discuter] 4 mars 2020 à 00:13 (CET)
Bonsoir Eru Bonsoir. J'attends donc. Par contre, vu que le test 12 ne fonctionne pas, il faudra bien indiquer que la syntaxe simplifiée ne fonctionne pas avec deux dates. --FDo64 (discuter) 4 mars 2020 à 00:33 (CET)
Oui, le modèle {{âge}} ne support pas ce type de paramètre, il faudrait que le tout soit en lua.
J'ai trouvé comment calculer l'âge en lua en ajoutant un paramètre dateNaissanceMort, mais je dois encore gérer tous les cas. — eru [Discuter] 4 mars 2020 à 08:39 (CET)
┌─────────────────────────────────────────────────┘
Bonjour FDo64 Bonjour, je pense que c'est stable avec ces modifications du module date et du modèle.
Tous les testes semblent fonctionner (à part du 19 au 25 et les 30 & 31, puisqu'il s'agit d'erreur de syntax, mais au moins maintenant l'affichage est correcte).
J'ai également ajouté des testes au module {{Date de naissance}}, tous semblent fonctionner correctement.
Il faut par contre bien laisser 4= et non qualificatif=, sinon et si le qualificatif est dans un autre argument (le 2 principalement) il est ignoré. — eru [Discuter] 6 mars 2020 à 17:36 (CET)
Bonsoir Eru Bonsoir. Malheureusement, je n'ai pas de bonnes nouvelles. J'ai d'abord constaté des régressions sur la page Modèle:Date/Test : 1) dans le test 9 on perd "mars", 2) dans les tests 74 et 76 on a une redirection pour Jour de la révolution. J'ai ensuite comparé la version actuelle avec le bac à sable pour constater que tu es reparti d'une ancienne version (Smiley: triste). Il faudrait donc recharger la version actuelle dans le bac à sable et reporter tes modifications, puis voir si cela corrige les différences constatées. --FDo64 (discuter) 10 mars 2020 à 18:12 (CET)
Effectivement je ne l'ai pas réinitialisé avant et je n'ai pas pensé à regarder ces tests, je vais m'en occuper dans la semaine — eru [Discuter] 10 mars 2020 à 18:43 (CET)
┌─────────────────────────────────────────────────┘
Bonjour FDo64 Bonjour, j'ai synchronisé avec le code en production mardi, cela a corrigé le problème de redirection, et je viens de trouver l'erreur qui faisant échoué le test 9 : diff
Je ne trouve plus d'erreur dans les 3 tests. — eru [Discuter] 13 mars 2020 à 18:35 (CET)
Bonsoir Eru Bonsoir. Je regarde ça dès que j'ai suffisamment de temps. --FDo64 (discuter) 13 mars 2020 à 18:46 (CET)
Pas de soucie, rien d'urgent. — eru [Discuter] 13 mars 2020 à 18:49 (CET)
Bonsoir Eru Bonsoir. Module et modèle mis à jour. N'hésite pas à me contacter en cas de problème. --FDo64 (discuter) 23 mars 2020 à 22:51 (CET)
Merci FDo64 Clin d'œil, j'ai ajouté républicain=liens sur une page au hasard pour voir, pour l'instant je ne vois pas de soucie. — eru [Discuter] 23 mars 2020 à 23:19 (CET)

wikidata[modifier le code]

Bonjour,

Et vous pensez qu'un modèle qu'on ne fait qu'apposer {{date de naissance}} et qui aille lui même chercher les dates sur Wikidata puisse être possible ? Ludo 10 mars 2020 à 18:22 (CET)

Il me semble que ce n'est pas recommandé en dehors des Infobox, à confirmer. — eru [Discuter] 10 mars 2020 à 18:43 (CET)

Crédit d'auteur[modifier le code]

Bonjour, afin d'uniformiser les noms de modèle pour les crédits d'auteur, je propose de renommer {{Traduction/Référence}} en {{Crédit d'auteurs/Traduction}}

Et {{Traduit de}} en {{Auteurs crédités après traduction}}. Par ailleurs, {{Auteurs crédités après copie d'un autre wiki}} ne respecte pas les crédits car le texte doit obligatoirement avoir été publié sous CC-BY-SA hors il ne parle que de GFDL. -- Nemo Discuter 4 mars 2020 à 15:25 (CET)

Ping @Kropotkine 113 qui avait effectué plusieurs modifs sur ces modèles. -- Nemo Discuter 4 mars 2020 à 15:26 (CET)
Bonjour.
Je ne trouve pas très utile de renommer un modèle aussi utilisé. Ce qui est important c'est plutôt d'uniformiser l'usage et le rendu, pas les noms des modèles.
Pour {{Auteurs crédités après copie d'un autre wiki}}, oui, c'est un peu daté. Mais la GFDL est réputée compatible avec les CC-BY-SA donc a priori le texte copié ne doit pas avoir été « obligatoirement » publié sous CC-BY-SA.
Kropotkine 113 (discuter) 4 mars 2020 à 17:33 (CET)
Bonjour, pas d'opposition de principes, je suis surtout gêné par ta première proposition : le "/" est normalement réservé pour les sous-pages, ce qui ne semble pas le cas ici.
J'allais aussi faire remarquer qu'ils sont très utilisés et qu'il sera dûr de faire changer les habitudes…
--FDo64 (discuter) 4 mars 2020 à 17:42 (CET)
Le but est bien q'un wikipédien qui ne connaît pas le nom d'un modèle de ce type puisse le trouver facilement. On peut voir pour {{Crédit Traduction}} (ma proposiiton étais moins pire que l'actuel où {{Traduction}} et {{Traduction/Référence}} n'ont rien à voir ! Le mieux aurait été de faire un seul modèle pour les pdd et un seul pour les mentions en référence avec un paramètre "type" mais bon, c'est trop tard. Pour {{Auteurs crédités après copie d'un autre wiki}} la page d'aide dit que « Tout contenu uniquement disponible par le biais du GFDL est interdit. » Il faudrait donc changer le modèle. Et {{Modèle:CC-BY-SA hors Foundation}} pourrait pas être renommé en {{Auteurs crédités après copie d'un texte hors Fundation}} ?
PS : Avec l'éditeur visuel ou le nouvel éditeur de wikicode (2017), lorsqu'on recherche un nom de modèle à insérer qui est en fait une redirection, il propose systématiquement le nom actuel du modèle au dessus. -- Nemo Discuter 5 mars 2020 à 19:25 (CET)
@FDo64 et @Kropotkine 113 Vous en pensez quoi ? -- Nemo Discuter 9 mars 2020 à 21:55 (CET)
Bonjour Nemo Le Poisson Bonjour. Comme je l'ai indiqué, pas d'opposition. Pas convaincu non plus : {{Traduit de}} me semblant clair et concis.
D'ailleurs, et sans avoir du tout approfondi la question, je verrais bien une fusion avec {{Traduction/Référence}} et que le modèle prenne la forme d'un élément de liste à puce dans un article principal et un bandeau dans une page de discussion. D'ailleurs certains les confondent et cela remplit les catégories Catégorie:Article utilisant le modèle Traduit de et Catégorie:Page utilisant le modèle Traduction référence en page de discussion.
--FDo64 (discuter) 10 mars 2020 à 12:26 (CET)
Bonjour, pour rappel, il y a aussi {{TradRef}}, qui a la même fonction que {{Traduction/Référence}} en étant beaucoup plus pratique. — Daehan [p|d|d] 10 mars 2020 à 13:16 (CET)
C'est vrai que c'est pas mal, on pourrait rendre obsolète (via un bandeau) {{Traduction/Référence}} ducoup... @FDo64 Je suis aussi pour une fusion des modèles dans la limite du possible ! -- Nemo Discuter 17 mars 2020 à 15:46 (CET)
Bonjour. Deux remarques:
  • Je ne vois pas en quoi {{TradRef}} est beaucoup plus pratique que {{Traduction/Référence}}. Niveau syntaxe, c'est kif-kif.
  • Pour le nom du modèle : avoir le terme « Référence » ou « Ref » dans le nom permet de rappeler au rédacteur qu'il doit le placer dans la section « Références », si cette pratique n'est pas remise en question. Ce mot permet aussi de réduire un peu la confusion possible avec le modèle {{Traduit de}} réservé aux pages de discussion. Pas contre un renommage du type {{Crédit d'auteurs/TradRef}} mais sans être convaincu de l'intérêt et conscient du nombre de "corrections mineures/cosmétiques" que cela engendrerait. --Ideawipik (discuter) 17 mars 2020 à 17:04 (CET)

Modèles versus html : que vaut-il mieux ?[modifier le code]

Bonjour à tous. Ma question est très simple, sur la base d'un exemple typique : vaut-il mieux utiliser {{exp|xxx}} ou <sup>xxx</sup> ? Je croyais avoir lu une recommandation en faveur des modèles mais je ne la retrouve pas, et la situation a pu changer avec l'emploi croissant de l'éditeur visuel (cf. ici). La question concerne bien sûr les modèles simples, pas les modèles sophistiqués comme {{Formule chimique}} ou {{Unité}}. — Ariel (discuter) 9 mars 2020 à 13:07 (CET)

Je sais que, au début, il y a trèèèèès longtemps (c’était peu après l'extinction des dinosaures et un peu avant la naissance de Michel Drucker), on évitait l'utilisation des modèles et on préférait leur version substituée {{subst:monmodèle|tagada}} car ces appels répétés monopolisaient trop les ressources système. Mais ça, c'était avant. Je crois que, aujourd'hui, l'utilisation des modèles est préconisée (maintenance facilitée...) car les ressources système ne sont plus problématique. Tel est actuellement l'état de mes propres connaissances sur le sujet. − ©éréales Kille® [Speak to me]* en ce lundi 9 mars 2020 à 13:19 (CET)
Mon modeste avis, plutôt modèle : pour faire de la maintenance, on peut apprendre par imitation ou observation du code wiki ; à l'inverse le html suppose une connaissance préalable, on ne peut l'apprendre sur le wiki. --Ypirétis (discuter) 9 mars 2020 à 13:46 (CET)
Un nombre en exposant via un modèle est difficilement modifiable avec l'éditeur visuel (par exemple, si on s'est trompé et qu'on a mis en exposant plutôt qu'en indice, il faut changer le modèle, et donc connaître l'autre modèle, ce qui n'a rien d'évident avec l'éditeur visuel). S'il est mis en exposant via html, c'est sans problème (ça marche comme un éditeur de texte, donc à peu près aussi facile que sous Word). Je parle ici essentiellement des modèles {{exp}} et {{ind}}, qui ne font QUE une encapsulation du html sans aucune valeur ajoutée, et dans une moindre mesure des modèles {{2}} et {{3}} qui font carrément une double encapsulation - ce sont des modèles protégés qui utilisent eux-même des modèles protégés pour faire du htlm de base (je considère "de base" globalement tout ce qui est plus simple qu'une balise "ref"). Tout ça rends Wikipédia moins modifiable, et alourdit la charge (d'une manière d'autant plus insidieuse qu'elle est pratiquement imperceptible). En ces temps où on parle de "web vert" et plus généralement de l'impact écologique du net, compliquer les choses pour le plaisir de les compliquer me semble une aberration (je dois néanmoins à l'honnêteté d'ajouter que quand je peste contre ces modèles, je pense moins à l'impact écologique et plus à mon confort d'édition). (discuter) 9 mars 2020 à 13:51 (CET
Notification Ypirétis et Céréales Killer : : il n'est pas nécessaire de connaître de modèle ou html pour mettre en exposant ou en indice, c'est l'éditeur visuel qui convertit la mise en page en html - comme dans Word, il n'est pas nécessaire non plus de connaître les raccourcis claviers pour mettre en gras ou en italique, on surligne avec la souris et on clique sur l'icône de mise en page de l'éditeur visuel. Et ça marche aussi pour les tableaux... sauf si ceux-ci sont générés par des modèles (comme par exemple les lignes des tableaux de monuments historiques). (discuter) 9 mars 2020 à 14:03 (CET)
Si on utilise l'éditeur visuel ! Mais comme on peut utiliser les deux, se poser la question reste primordial. En fait, ce qui ressort de cette discussion, c'est que l'éditeur visuel favorise l'usage - par procuration - du langage html, mais que dans l'éditeur de code, les modèles sont plutôt préférés, parce que compréhensibles et applicables plus facilement. SammyDay (discuter) 9 mars 2020 à 14:06 (CET)
Notification Sammyday : Je comprends que la question soit légitime, mais je m'interroge même sur cette affirmation, "dans l'éditeur de code, les modèles sont plutôt préférés". Préférés par qui ? Je n'ai pas trouvé, ni de recommandation, ni même d'usage noté quelque part, faisant de cette pratique quelque chose de "préféré". Je comprendrais mieux, en fait, si une exclusivité était possible (c'est-à-dire si on n'utilisait plus de html du tout en wikicode), mais l'usage est bâtard, les articles parsemés de balises html "<br/>", "<ref>", "<small>", "<gallery>", ou des marqueurs du wikicode "''italique'', '''gras''', [[lien]] ", etc. Les habitués du wikicode savent gérer ça. Les nouveaux préfèrent l'éditeur visuel, qui invisibilise la syntaxe et la rends indolore même en mode édition... sauf quand on se heurte à une modification que l'on pensait facile, et qui butte sur un modèle. Je ne veux offenser personne, mais je trouve douteux qu'il soit plus simple d'utiliser {{exp|tm}} plutôt que <sup>tm</sup>. La 2e syntaxe utilise à peine 4 caractères de plus pour le même rendu, mais rends ce texte modifiable par les deux modes d'édition, au lieu de le réserver au mode wikicode qui demande plus d'expertise (pas tout à fait réservé, il reste possible de faire quelque chose avec l'EV, mais c'est lourd et pénible). (discuter) 9 mars 2020 à 14:25 (CET)
Il me semble que sur de longs articles, le cumul de modèles pose des problèmes de perfs ET d'affichage même des modèles à partir d'un certain nombre. Il y a clairement des modèles dont on peut se passer. Par ailleurs, je trouve pertinent le commentaire sur le fait qu'il faille connaître les différents modèles, si on veut les corriger ou les changer. — Daehan [p|d|d] 9 mars 2020 à 14:52 (CET)
Je suis d’accord avec les remarques de 空 et Daehan.
Par ailleurs la Wikipédia en anglais recommande à ses utilisateurs de substituer ({{subst:}}) le modèle équivalent pour afficher les balises sup à la place. — Thibaut (discuter) 9 mars 2020 à 15:23 (CET)
En cherchant un peu je n'ai toujours pas trouvé de recommandation, mais j'ai vu passer ça, qui disait en 2017 "L'usage des balises HTML n'est ni recommandé, ni non recommandé" (NB : dans le cas spécifique évoqué par cette discussion, c'était wikicode vs. balise, pas modèle vs. balise - dans ce cas, il me semble que le wikicode devrait primer, et que c'est ce que l'on constate dans les faits). Toujours sur le bistro, cette discussion et la remarque de Thibaut120094 m'inspirent un argument supplémentaire : les modèles ne sont pas nécessairement internationaux, les balises, si, ce qui facilite donc les traductions. Le modèle {sub} existe sur en.wp, par exemple, mais pas {exp} (qui est traduit par {sup} sur en.wp, notre modèle {sup} sur fr.wp n'ayant rien à voir). Les modèles {2} et {3} ne veulent pas dire la même chose d'un wiki à l'autre. (discuter) 9 mars 2020 à 15:40 (CET)
Je n'utilise pas l'éditeur visuel, je suis donc incompétent en la matière. L'avantage des modèles, c'est qu'ils sont documentés (plus ou moins bien) directement sur wp. --Ypirétis (discuter) 9 mars 2020 à 16:34 (CET)
Pour la documentation : une solution est de faire comme sur en:Template:sup : signaler la syntaxe html dans la documentation du modèle correspondant.
Sinon ça m'a toujours surpris de voir utiliser un modèle pour une simple substitution, l'argument de la charge système est évident, mais je n'ai aucune idée de comment le quantifier, et donc je ne sais pas s'il est concluant. L'apprentissage par imitation (ce que nous avons probablement tous fait parmi les participants à cet échange) fonctionne tout aussi bien pour les quelques rares balises html (ça ne demande pas de connaître le html), et ça ne me semble guère concluant non plus. Par contre, s'il est avéré que les balises html fonctionnent mieux avec l'éditeur visuel, là ça paraît assez décisif. Proz (discuter) 9 mars 2020 à 17:51 (CET)
Mon point de vue (qui n'engage que moi et ne cherche à rallier personne), c'est que MediaWiki est un CMS, avec sa propre syntaxe, et que celle-ci n'est pas le HTML, mais le Wikicode. Et les modèles font partie de la syntaxe Wikicode. L'exemple qui me vient est le cas d'une balise type <center>. Alors certes, ce n'est pas trop pertinent car cette balise n'a pas lieu d'être dans l'espace principal mais quand même : cette balise est utilisée un peu partout dans le wiki, et là, paf, elle devient obsolète. Les syntaxes ayant utilisé le modèle correspondant {{Centrer}} peuvent être mises à jour sur l'ensemble des pages en un seul clic. Celles utilisant la balise HTML sont toujours en place. Les modèles permettent de déléguer la syntaxe HTML à un bout de code externe, qui peut être mis à jour si cette même syntaxe évolue, change, doit être mise à jour. Si demain on décide que les exposants et les indices doivent utiliser une mise en forme CSS et non plus HTML : le modèle peut être changé rapidement, les balises non.
Après, n'ayant pas la moindre expérience avec l'éditeur visuel, je ne me prononcerai pas sur ce point, et effectivement sa syntaxe est à prendre en compte à un moment ou a un autre, mais il faut garder à l'esprit que celui-ci est également toujours en mouvement et en développement.
Wikipédiennement, Epok__ (Insultes, éloges, simples discussions : ), le 10 mars 2020 à 08:09 (CET)
Insister lourdement finirait probablement par être contre-productif, je me bornerais donc à constater une dernière fois que les arguments en faveur des modèles (Ypirétis / Les modèles sont documentés (encore faut-il savoir où), ou Epok / Les modèles factorisent la syntaxe et facilitent la mise à jour (même si, étant protégés, ils sont moins facilement accessibles au tout-venant)) sont des arguments de spécialistes déjà installés sur wiki, et ne répondent pas au problème de l'accessibilité aux nouveaux. Les balises "sup" et "sub" dont il est question sont assez universelles sur le web, elles sont plus faciles d'emploi que les balises "ref", elles ne sont peut-être pas "documentées" comme le sont les modèles, mais taper "<sup>" dans la barre de recherche envoie sur Sup où cette syntaxe est clairement expliquée. Et au risque de me répéter, la syntaxe est invisible quand on utilise l'éditeur visuel (comme le font la majorité des nouveaux), sauf quand il y a des modèles, qui empêchent la modification directe. Vous pouvez jeter un œil dans les RCs aux modifs taggées "éditeur visuel basculé" pour constater combien de ces modifs (où un contributeur a commencé en mode EV, mais a dû basculer en mode code) impliquent des modèles. Ou même juste regarder les modifs taggées "éditeur visuel" pour constater à quel point il est utilisé par les nouveaux contributeurs. S'il y a un truc à garder à l'esprit, je pense que c'est plus l'accès pour tous à la modification. Emalquier le faisait remarquer sur le bistro il n'y a pas une semaine (et Trizek semblait se désoler qu'il ne soit pas prêté plus d'attention à son message) : l'ergonomie sur Wikipédia n'est pas idéale, et je trouve dommage de handicaper l'un des rares trucs (l'EV) qui facilite vraiment la modification pour les nouveaux. (discuter) 10 mars 2020 à 10:03 (CET)
Voui, mais le html, ça donne aussi ça : À Durban, la température moyenne est d'environ 21&nbsp;°C et il pleut environ 1000&nbsp;mm d'eau par an​.
J'préfère quand même À Durban, la température moyenne est d'environ {{tmp|21|°C}} et il pleut environ {{unité|1000|mm}} d'eau par an.​
Tant qu'à faire d'apprendre, autant apprendre la logique et la syntaxe des modèles plutôt que des bribes de html. Mais bon, c'est une opinion « qui n'engage que moi et ne cherche à rallier personne Clin d'œil  [sic] ». Ypirétis (discuter) 10 mars 2020 à 10:40 (CET)
Quand on regarde le code, OK (et encore, les modèles mentionnés ne sont pas ceux dont on discutait présentement). Mais avec l'EV, on n'a justement pas besoin d'apprendre l'un OU l'autre, on ne voit pas la différence. Tout ce qu'on voit, c'est que certaines valeurs sont modifiables, comme si c'était un texte sous Word (par exemple, je peux aller dans Durban, cliquer sur "21 °C", et changer en "22 °C" avec l'EV) et certaines valeurs, quand on clique dessus, au lieu de les modifier, un pop-up surgit. Dans le même exemple, si {{tmp|21|°C}} est utilisé, avec l'EV, en cliquant sur le chiffre, j'ai un pop-up "Modèle. Généré depuis : tmp", avec un bouton "modifier" secondaire qui apparaît pour modifier le modèle (...et qui permet d'en modifier les paramètres, mais pas de changer de modèle - pour ça, il faut supprimer le modèle puis en insérer un nouveau). S'il y a une erreur sur une valeur numérique ou un choix de mise en forme, l'usage de modèle rends la correction difficile sous EV. Par ailleurs, je connais un minimum la logique et la syntaxe des modèles (notamment parce que la création d'article, avec infobox, images, portails et catégories, reste plus facile, à mon avis, sous wikicode quand on le maîtrise), la nouveauté s'estompe, et je ne lutte pas contre tous les modèles (j'aurais pas fini), j'aimerais juste que les "anciens" du site ne rendent pas la barre d'entrée plus haute que nécessaire. (discuter) 10 mars 2020 à 11:31 (CET)
La question était "html ou modèle ?", là on est en train de parler d'éditeur visuel vs wikicode. Si l'EV permet de s'affranchir de tout codage, ce n'est pas une réponse à la question puisque, dites-vous, il permet d'éviter (presque ?) tout codage, que ce soit en html ou en syntaxe wiki. Si l'EV ne permet pas de tout faire et qu'il faut en passer par le code, et bien, dans ce cas, tant qu'à faire d'abandonner l'EV, alors, je suggère plutôt "modèle" que "html". --Ypirétis (discuter) 10 mars 2020 à 12:07 (CET)
Il ne s'agit justement pas de html ou modèle en général, mais uniquement dans cas simples, on peut même préciser qui sont pris en charge par l'EV (c'est dans le menu qui est plutôt réduit, pas de risque de débordement), et celui-ci produit en l'occurrence des balises html. Je viens de vérifier avec l'EV, et je confirme qu'un texte avec des balises sup est plus naturellement éditable avec l'EV, sans jamais avoir à savoir ce qu'est un modèle, c'est très accessible. Avec le modèle le message affiché quand on édite le texte doit être assez incompréhensible pour les débutants (il faut déjà comprendre ce qu'est un modèle). Proz (discuter) 10 mars 2020 à 13:21 (CET)
OK, l'EV c'est mieux, on avait compris… --Ypirétis (discuter) 10 mars 2020 à 13:26 (CET)
J'ai essayé d'être précis, c'est un résumé tout à fait malhonnête... Ce n'est pas comme ça qu'on avancera... Proz (discuter) 10 mars 2020 à 14:14 (CET)
Une remarque en passant, si les nouveaux n'apprennent pas le code... alors ils n'interviendront jamais en page de discussion. Et les modèles / balises html sont loin d'être utilisés uniquement sur les articles. Donc c'est très bien de rappeler que l'EV gère parfaitement les balises, mais l'EV est pour l'instant trop limité en termes d'espace, donc on ne peut pas baser toute notre réflexion dessus - ou sur le fait que les nouveaux l'utilisent principalement sur le main. SammyDay (discuter) 12 mars 2020 à 18:11 (CET)
Avec le nouvel outil de discussion, l'utilisation de wikicode est presque inutile sur une page de discussion. Lofhi (me contacter) 12 mars 2020 à 18:15 (CET)
Tu veux parler de celui qu'on est en train d'utiliser en se répondant l'un l'autre ? Parce que si on se contente des PDU et des articles pour les nouveaux, ils vont pas franchement se sentir très intégrés... SammyDay (discuter) 12 mars 2020 à 18:28 (CET)
Je parle du Projet:Outils de discussion. Sourire Lofhi (me contacter) 12 mars 2020 à 19:07 (CET)
Evidemment. Je suis assez étonné que les personnes qui vantent ces nouveaux outils dans une discussion annexe n'aient pas le réflexe "et mais au fait, je n'en utilise aucun dans la présente discussion... et si du coup cette thématique n'était pas liée à la question ?" Bref, dans la question "modèle vs html", l'EV et les nouveaux outils de discussion ne permettent pas de trancher pour le moment. SammyDay (discuter) 13 mars 2020 à 09:36 (CET)
J'utilise actuellement l'outil pour te répondre, mais « bref » j'imagine... Lofhi (me contacter) 13 mars 2020 à 13:59 (CET)

Modèle:NEXTYEAR et Infobox Mois[modifier le code]

Bonjour, Pour info j'ai annulé la modif faite le 9 mars par une IP dans Modèle:NEXTYEAR, car ce n'était pas compatible avec {{Infobox Mois}}.

Dans Mars 2020 par exemple, l'infobox montrait un lien vers « Mars 4040 » au lieu de Mars 2021.

En plus, j'ai demandé une semi-protection étendue par cohérence avec Modèle:Infobox Mois. Tous les modèles utilisés par cette infobox devraient avoir la même semi-protection, il me semble. Ils ont plus de 3000 pages liées (une par mois). - Eric-92 (discuter) 15 mars 2020 à 02:24 (CET)

Module manquant pour le modèle « BillboardURLbyName »[modifier le code]

Bonjour, les appels du modèle {{BillboardURLbyName}} affiche l'erreur « le module « WLink » n’existe pas. » N'étant pas certain, à la lecture du code du module « WLink » (version enWiki), que WLink n'appelle pas d'autres ressources locales, je laisse à quelqu'un d'autre le soin de corriger l'anomalie (voir, par exemple, l'article Spice Up Your Life, réf. no 43, version du 27 décembre 2019). D'avance, merci. --ContributorQ() 19 mars 2020 à 20:08 (CET)

Bonjour ContributorQ. C'est sûr que c'est assez bizarre de créer un modèle par copier-coller depuis enwiki sans vérifier que la version francophone dispose des fonctions (modules) nécessaires à son bon fonctionnement. Si on garde le code du modèle en l'état, il faudrait créer WLink et String2 et vérifier que le module String existant fonctionne comme escompté, par rapport à la version enwiki. Mais une autre possibilité pourrait-être d'adapter le modèle, si le module ne s'avère pas indispensable. Cela demande juste un peu de temps pour étudier le fonctionnement général. À suivre prochainement. --Ideawipik (discuter) 19 mars 2020 à 23:52 (CET)
Merci pour cet éclairage. J'aurais bien effectué la correction, mais mes compétences en Lua sont très limitées et je n'ai pas envie de les approfondir pour si peu. 312 articles sont touchés. --ContributorQ() 20 mars 2020 à 15:43 (CET)
Bonjour ContributorQ. En fait, le module WLink (du enwiki) n'est pas indispensable. Il suffirait d'une seule fonction comme celle intitulée « ansiPercentEncoder » seulement locale dans Module:Classement musical/Données. La seule modification, nécessaire pour la présente application, du code de cette fonction serait de remplacer un + par un - dans la substitution d'espace. La fonction appelée dans le module String2 peut être remplacée par un simple {{lc:…}} donc pas besoin de ce module. L'appel de la fonction « replace » du module String est déjà fait par un autre moyen dans la fonction « ansiPercentEncoder » et est donc dispensable. Faut-il créer un module BillboardURLbyName juste pour héberger cette fonction ? La réponse à cette question dépend des autres besoins de conversions dans l'ensemble des modèles. Il existe d'ailleurs peut-être déjà un tel module-bibliothèque équivalent à WLink. Quelqu'un le sait-il? Dans tous les cas, le code du présent modèle pourra être simplifié. --Ideawipik (discuter) 20 mars 2020 à 16:39 (CET)
Les appels au module « String2 » peuvent, en effet, être remplacés par des appels au modèle spécial « {{lc:...}} ». Il reste quand même du boulot, notamment des tests... --ContributorQ() 20 mars 2020 à 19:57 (CET)

Quasi-doublon de modèles pour mise en colonnes[modifier le code]

Bonjour. Faut-il envisager une fusion entre les Modèle:Début de colonnes et Modèle:Div col qui font sensiblement la même chose ? Quelles sont les subtilités de ces modèles ? Le second, plus récent, est utilisé sur moins de 650 pages et pourrait bien souvent être remplacé par le premier. --Ideawipik (discuter) 20 mars 2020 à 17:14 (CET)

Bonsoir, mon avis (sans avoir vérifié la faisabilité) : reprogrammer le modèle anglais avec le français, sinon à substituer. --FDo64 (discuter) 20 mars 2020 à 19:30 (CET)
Notification Ideawipik pour en revenir au sujet principal (j'ai séparé ma question annexe ci-dessous), je remarque que la majorité des appels n'utilisent que les paramètres cols et/ou colwidth (et 1 qui est un synonyme du premier). Pour ces cas là, un remplacement automatisé par bot serait simple à mon avis. Les cas restants pourraient être traités à la main. Mais oui, je pense qu'il faut privilégier le rassemblement des modèles (et vers le modèle local plutôt qu'un modèle copié-collé de l'anglais et même pas traduit). Je corrige déjà les quelques appels en erreur pour faciliter la tâche si elle doit être menée. Epok__ (Insultes, éloges, simples discussions : ), le 22 mars 2020 à 10:29 (CET)

Question annexe sur les vendor prefixes[modifier le code]

Hello, J'en profite pour demander où on en est concernant les extensions CSS propres aux navigateurs : par exemple {{Div col}} utilise {{Column-width}}, {{Column-count}} ou encore {{Column-rule}}. Il existe également {{Column-gap}} (et certainement bien d'autres). Il me semblait que ces syntaxes étaient maintenant considérées comme obsolètes car es navigateurs avaient adoptés la syntaxe normalisée ? Wikipédiennement, Epok__ (Insultes, éloges, simples discussions : ), le 21 mars 2020 à 10:26 (CET)

Firefox et Chrome semblent supporter les syntaxes sans préfixe pour les colonnes depuis 3~4 ans, effectivement. Pour rappel, quand même faire attention, toujours vérifier avant de supprimer les vendor-prefixes, car tout n'a pas été normalisé en même temps. od†n ↗blah 21 mars 2020 à 12:43 (CET)
Justement, la situation est un peu plus complexe pour column-gap, qui n'a été bien normalisé dans Firefox qu'à partir de la version 61, sortie le . Mais je pense qu'on peut quand même franchir le pas, ça fera bientôt 2 ans (qui deviendront 3, puis 4… ça passe vite), et dans les popups sur la page caniuse.com que j'ai liée, on voit que le pourcentage d'utilisation des versions avant la 61 est très bas. edit : non, là aussi c'est la version 52, car ce qui nous intéresse c'est le layout "multi-column". od†n ↗blah 22 mars 2020 à 08:40 (CET)
Notification Od1n Pour info, utilisation de ces syntaxes dans les modèles :
Auxquelles il faut ajouter les modèles utilisant ceux cités plus haut.
Et je viens de voir que tu les mis ceux-ci à jour : si on va par là, je propose de remplacer leur utilisation par du code en dur et de les supprimer. Je peux le faire si tu es OK (sauf si tu préfères t'en charger).
Tant qu'on y est, y a-t-il d'autres vendor extensions qui pourraient faire l'objet de ce même traitement ?
Désolé Notification Ideawipik, j'ai un peu fait dévier ton sujet...
Notification Epok, il ne faut pas être désolé. J'ai fait exactement le même chemin en sens inverse en découvrant les modèles {{Column-xxx}} avant {{Div col}}. Et me disant qu'on pourrait d'abord s'occuper de ce dernier puisqu'il existe déjà un modèle similaire. La perspective est la même. --Ideawipik (discuter) 22 mars 2020 à 12:11 (CET)
Epok__ (Insultes, éloges, simples discussions : ), le 22 mars 2020 à 09:48 (CET)
J'avais regardé pour remplacer les modèles "column-*" dans {{Div col}} mais attention c'est assez bazardesque : si tu observes bien son code, tu verras qu'il y a des paramètres qui en impactent d'autres… et attention, les modèles "column-*" ont des paramètres par défaut, sur lesquels compte {{Div col}}. Du coup je me dis qu'il y aurait peut-être du ménage à faire concernant {{Div col}}. od†n ↗blah 22 mars 2020 à 10:06 (CET)
Pour info, après une rapide recherche, je trouve des utilisations des propriétés suivantes dans les modèles :
  • -X-border-radius (la plus utilisée)
  • -X-linear-gradient
  • -X-pre-wrap
  • -X-font-feature-settings
  • -X-fit-content
  • -X-border
  • -X-break-inside
  • -X-column-break-inside
  • -X-inline-stack
  • -X-box-shadow
Plus de la doc probablement à mettre à jour à ce sujet (Modèle:Colonnes/Documentation)
Epok__ (Insultes, éloges, simples discussions : ), le 22 mars 2020 à 11:17 (CET)
Remplacé les modèles dans {{Div col}}, et effectuée un peu de mise à jour dans Modèle:Colonnes/Documentation. Relectures et retouches bienvenues. od†n ↗blah 24 mars 2020 à 13:23 (CET)

L'article Catégorie:Modèle de bandeau de section est proposé à la suppression[modifier le code]

Page proposée à la suppression Bonjour,

L’article « Catégorie:Modèle de bandeau de section » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). 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 catégorie:Modèle de bandeau de section/Suppression.

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

GLec (discuter) 30 mars 2020 à 19:11 (CEST)


Pour info[modifier le code]

Que pensez vous de mettre au début le paramètre format sur le modèle lien web ? Je vous invite à venir donner votre avis ici ! Cordialement, -- Nemo Discuter 30 mars 2020 à 19:59 (CEST)

Aide au sujet de la détection de l'espace de nom, pour distinguer les articles des pages[modifier le code]

Bonjour, j'aimerai savoir si ce serait possible (directement en wikicode, avec du lua ou autre) de détecter l'espace de nom d'un lien contenu dans le paramètre d'un modèle.

Prenons par exemple :

Wikipédia:Le Bistro est pourtant une page et non un article ! Il faudrait donc que quand le lien inclus dans le modèle pointe vers une page en dehors de l'espace encyclopédique, il affiche « page détaillée » !

Développer une telle fonction serait utile pour de nombreux modèles qui affichent à chaque fois « article » au lieu de « page », ce qui peut amener un nouveau à confondre ces deux notions. Cela rendrait également caduque pleins de modèles doublon comme {{Aide détaillée}} qui pourraient rediriger vers ici. Exemple d'autre modèle ou une fonction comme ça serait utile : ici ou quand le lien attendu doit être dans un espace particluier, renvoyer un message d'erreur le cas échéant.

J'ai tenté des trucs avec les mots magique if et namespace mais je ne sais pas comment lui faire retirer ça d'un paramètre :

{{#ifeq: {{NAMESPACE}} | {{ns:4}} | article | page}}

. Vous en pensez quoi ? -- Nemo Discuter 30 mars 2020 à 20:29 (CEST)

Bonjour Nemo Le Poisson.
Réponse technique. C'est certainement possible, sans aucun doute.
Quelques raisons pour ne pas le faire :
  • Le coût technique ajout de fonctions relativement coûteuses dans des modèles très répandus,
  • Complexification du code de ces modèles,
  • Pour aider les nouveaux, il vaut mieux utiliser les bons modèles existants pour les bonnes pages, ie utiliser le modèle « Aide détaillée » plutôt que « Article détaillé ».
Ce n'est que mon humble avis, aujourd'hui. --Ideawipik (discuter) 30 mars 2020 à 21:19 (CEST)
Hello,
en Lua c'est relativement simple : il "suffit" d'extraire l'éventuel namespace (ce qui se trouve avant les ":") et de voir à quoi il correspond ou tout simplement de déterminer l'absence de ":" (s'il ne s'agit que de différencier l'espace encyclopédique − qui n'a pas de namespace − du reste).
Après comme le dit Ideawipik ci-dessus, est-ce si confusant de traiter une page d'article ? (d'ailleurs, à l'inverse, on pourrait parler systématiquement de "page", ce qui s'applique aux articles). Est-ce que ça vaut de complexifier (même un peu) le modèle ?
Franchement je n'ai pas d'avis sur ce dernier point. Lua est efficace (plus que les modèles), mais ça ne serait alors vraiment efficace que si tout ce modèle passait en Lua (et pas seulement le test), mais ça aurait pour conséquence de le rendre maintenable par moins de personnes (il y a moins de gens qui lisent Lua que de gens qui lisent le langage des modèles). Hexasoft (discuter) 30 mars 2020 à 22:06 (CEST)