Discussion Projet:Modèle/Archive 2020
|
||||||||||||||||||||||||||||||||||||||
|
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. |
GLec (discuter) 30 mars 2020 à 19:11 (CEST)
Modèles versus html : que vaut-il mieux ?
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
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)
- 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)
- 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)
- 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)
- 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 balisessupà 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 °C et il pleut environ 1000 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
[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.
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)
- 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)
- Je parle du Projet:Outils de discussion.
- 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)
- 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)
- 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)
- 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)
- OK, l'EV c'est mieux, on avait compris… --Ypirétis (discuter) 10 mars 2020 à 13:26 (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)
- 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)
- 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)
- Voui, mais le html, ça donne aussi ça :
- 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)
- 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)
- 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)
Modèle:NEXTYEAR et Infobox Mois
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)
Crédit d'auteur
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
. 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 Nemo Le Poisson
- @FDo64 et @Kropotkine 113 Vous en pensez quoi ? -- Nemo Discuter 9 mars 2020 à 21:55 (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)
- Bonjour. Deux remarques:
- 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)
Si quelqu'un pouvait faire en sorte que ça fasse un retour à la ligne dans le cas où plusieurs articles de presse sont mentionnées (ça me paraît beaucoup plus lisible), j'ai essayé mais je n'y suis pas arrivé... À moins qu'il vaille mieux faire cela avec un module Lua ? -- Nemo Discuter 10 avril 2020 à 21:45 (CEST)
- Nemo Le Poisson :
Fait. Pour information, « bricoler » des listes à puces (tel que c'était fait auparavant) est à proscrire, cela pose des problèmes d'accessibilité. - J'en ai profité pour revoir la mise en forme de certaines discussion ou le bandeau se trouvait plusieurs fois. Par exemple, Discussion:Ronan Kerdraon.
- --FDo64 (discuter) 10 avril 2020 à 22:52 (CEST)
- Merci beaucoup ! -- Nemo Discuter 10 avril 2020 à 22:55 (CEST)
Module manquant pour le modèle « BillboardURLbyName »
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)
- 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)
- 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)
Quasi-doublon de modèles pour mise en colonnes
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)
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
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)- Od1n Pour info, utilisation de ces syntaxes dans les modèles :
- -moz-column-width : 5 utilisations / -webkit-column-width : 4 utilisations
- -moz-column-count : 10 utilisations /-webkit-column-count : 4 utilisations
- -moz-column-gap : 3 utilisations / -webkit-column-gap : 3 utilisations
- 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é Ideawipik, j'ai un peu fait dévier ton sujet...
- 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)
- Pour info, après une rapide recherche, je trouve des utilisations des propriétés suivantes dans les modèles :
- 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)
- Justement, la situation est un peu plus complexe pour
Pour info
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)
Manipulation de variables
Une question, avec mes excuses s'il s'agit d'un marronnier : savez-vous pourquoi la manipulation de variables, le b-a-ba de la plupart des langages, n'a pas été implémentée ? Ça permettrait d'alléger tellement le codage de nombreux modèles ! — Ariel (discuter) 9 avril 2020 à 07:04 (CEST)
- Ariel Provost :
- L'activation a été refusée plusieurs fois. Au départ, c'était par volonté de ne pas introduire de fonctionnalités trop complexes dans le wikicode. De plus, l'évaluation d'un bloc de code ne doit pas dépendre du contexte. L'éditeur visuel en dépend selon phab:T65324#anchor-667308.
- Vu qu'on a maintenant les modules pour faire des traitements complexes, il est peu probable que des fonctionnalités de programmation "avancées" soient ajoutées au wikicode.
- Pour éviter les répétitions, j'ai parfois employé une autre méthode : utiliser un modèle auxiliaire. Par exemple, {{Annonce liste de suivi}} fait des calculs et passe les valeurs à {{Annonce liste de suivi/Affichage si valide}} qui reçoit les valeurs dans des variables et peut les utiliser plusieurs fois sans répéter les calculs.
- Orlodrim (discuter) 9 avril 2020 à 16:33 (CEST)
- OK, OK, je mets ça (les variables) sous mon mouchoir (plein de larmes). Et Merci Orlodrim for the trick. — Ariel (discuter) 9 avril 2020 à 17:04 (CEST)
- OK, OK, je mets ça (les variables) sous mon mouchoir (plein de larmes). Et Merci Orlodrim
Modèle:Siècle
Pour info, je propose de simplifier le modèle en se passant du second paramètre, voir ; Discussion modèle:Siècle#On pourrait se passer du paramètre prononciation en français (2). N'hésiter pas à venir donner votre avis ! -- Nemo Discuter 12 avril 2020 à 22:30 (CEST)
Aide au sujet de la détection de l'espace de nom, pour distinguer les articles des pages
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)
- Donc si j'ai bien compris impossible d'avoir une fonction de ce style en wikicode ? Ok pour garder Aide détaillée si ça aide les nouveaux.
- Mais je pense qu'une fonction pareille même en LUA serait bien utile, de nombreux bandeaux sont apposés sur les pages méta mais aussi sur les articles (ou leur pdd) une distinction entre page et article me paraît donc nécessaire.
- Je vois d'autres utilité à ceci : Lorsqu'on crée une pàs à l'aide du bandeau, ça utilise {{Initialiser PàS}}. Si c'est pour un modèle ou une catégorie par exemple, il met toujours : Trouver des sources pour « Modèle:XXX » hors ça s'applique aux article ça ! Il pourrait au contraire renvoyer vers des pages qui pourrait exister dans le futur si la communauté en discute du style : « Critère d'admissibilité des modèles/catégories).
- Enfin, pour la complexification du code, je trouve que ça se justifie car sinon il faudrait créer pleins de modèles différents en fonction de l'espace de nom où ils sont apposés." Modèle: Discussion détaillée, ...
- Après, je reconnais que ce sont des petites incohérences qui ne tueront pas l'encyclopédie mais si on a les moyen techniques de les enlever autant le faire ! -- Nemo Discuter 4 avril 2020 à 15:17 (CEST)
Non catégorisation de la documentation d'un modèle
C'est quelque chose que je ne maîtrise pas bien.
Par exemple pour le Modèle:Instructions pAdQ est ajouté à la documentation : {{Instructions pAdQ}}, ce qui permet de visualiser le message généré par le modèle. Mais du coup la documentation est catégorisée ici : Catégorie:Wikipédia:Archives pAdQ. J'aimerais enlever cette catégorisation tout en gardant la visualisation. J'ai ajouté un peu de manière empirique {{Instructions pAdQ|nocat=oui}}, mais cela ne marche pas. Que faut-il faire ?
Après on pourra évoquer cette question dans la page d'aide : Aide:Documentation de modèle. — Berdea (discuter) 12 avril 2020 à 18:27 (CEST)
- Berdea : Ce que tu décrits n'est pas spécifique aux documentations de modèles. C'est vrai pour toute page hors espace principal. Par exemple, les pages d'aide ou de discussion.
- L'idéal serait que tous les modèles qui catégorisent incluent ce fameux
nocat=oui, et aussi qu'il ne catégorisent que là où c'est attendu. - Comme je l'ai déjà dit à un autre projet, je vais lancer un chantier sur ce sujet. En commençant par faire une demande aux bots pour identifier tous les cas. Après, comme le travail sera très conséquent, de l'aide ne sera pas de refus. --FDo64 (discuter) 12 avril 2020 à 19:58 (CEST)
- Hello Berdea et FDo64
pour moi, ce type de modèle destiné à un espace de nom particulier devrait réaliser un test d'espace de nom avant d'appliquer sa catégorie. Ici, il est clairement mentionné dans la doc du modèle qu'il est destiné aux pdd d'articles et de portails. J'ai donc conditionné l'apposition de la catégorie à ces espaces de noms. Le nocat devrait potentiellement être présent également pour les cas particuliers (si il est possible de vouloir apposer ce modèle sur une pdd d'article sans le catégoriser par exemple ?). - Wikipédiennement, Epok__ (Insultes, éloges, simples discussions : ✉), le 13 avril 2020 à 10:49 (CEST)
- Du coup la catégorisation que j'avais ajoutée ici est à proscrire ? Discussion Projet:Bases/Archive 4#Catégorisation des propriétés & Catégorie:Page utilisant P5377 — eru [Discuter] 16 avril 2020 à 07:58 (CEST)
- Bonjour Eru ,
- Il me semble effectivement que ce code devrait tester l'espace de nom avant d'appliquer la catégorisation pour éviter de catégoriser les modèles eux-mêmes. En Lua, un simple test de ce type suffit :
if page.namespace == 0 then -- 0 = espace principal -- Code ajoutant une catégorie end
- Wikipédiennement, Epok__ (Insultes, éloges, simples discussions : ✉), le 16 avril 2020 à 09:12 (CEST)
- En fait j'avais fait une modification dans la documentation qui n'est utilisée que dans l'espace modèle pour que cela la catégorise.
- Je viens de l'enlever, je ferai autrement. — eru [Discuter] 16 avril 2020 à 18:36 (CEST)
- Eru : Je n'ai peut-être pas bien compris ta modif : si l'objectif était de catégoriser les modèles, alors il n'est pas nécessaire de l'annuler. Ce que je voulais dire, c'est que si l'on souhaite ne catégoriser que les pages de l'espace principal (ce qui me semblait être l'objectif de ces modèles), alors il valait mieux restreindre explicitement cette catégorisation. Mais il est possible que ce ne soit pas souhaitable ici... Je ne connais pas assez ces modèles pour me prononcer.
- Toutefois, mon expérience dans ce domaine me pousse à penser que, si l'objectif est de lier un modèle à une catégorie, alors le mieux est en général d'ajouter un lien vers le modèle dans la catégorie (lien direct ou en utilisant le modèle {{Catégorisée par}} par exemple).
- Wikipédiennement, Epok__ (Insultes, éloges, simples discussions : ✉), le 17 avril 2020 à 00:21 (CEST)
- C'est ça, les pages utilisant la propriété via le modèle sont catégorisé, mais je voulais faire apparaître le modèle aussi.
- J'avais fait cela pour éviter d'avoir à passer sur sur chaque page, surtout pour la difficulté de maintenance, les propriétés étant défini dans le module de chaque base.
- Le modèle sport en ayant 500, cela fait 1446 propriété à l'heure actuelle...
- Peut en ajoutant quelque chose sur {{Catégorie d'une propriété}}, je ne sais pas encore. — eru [Discuter] 17 avril 2020 à 06:59 (CEST)
- Eru : Si l'objectif est de faire apparaître un seul modèle dans la catégorie, les deux solutions les plus simples sont d'ajouter un lien vers le modèle dans le texte de description de la catégorie (je privilégierais plutôt cette approche), ou d'ajouter la catégorie dans la liste des catégories du modèle (dans sa sous-page de documentation), plutôt que d'ajouter ça au code du module (et de catégoriser toutes les sous-pages Documentation et Bac à sable au passage). Epok__ (Insultes, éloges, simples discussions : ✉), le 17 avril 2020 à 11:17 (CEST)
- Oui le 1er problème était la catégorisation des sous-pages, j'aurai pu le résoudre avec des tests.
- Les deux solutions simples impliquent de modifier les 1446 pages à la main, a moins de le demander à un bot qui vérifie les modules data de temps en temps, tu en connais qui font ce genre de choses ? — eru [Discuter] 17 avril 2020 à 12:59 (CEST)
- Eru : Ah, Ok, je n'avais pas compris que tu souhaitais catégoriser toutes les propriétés... Dans ce cas effectivement le mieux serait de faire comme tu as fait, mais je ne suis toujours pas sûr de comprendre : est-ce que ça veut dire appliquer 1446 catégories à un modèle ? Si c'est le cas, ça me semble très moyennement recommandable... Un lien vers le ou les modèles concernés dans le bandeau {{Catégorie d'une propriété}} me semble alors la meilleure solution, et peut certainement se coder sur le même principe que ce que tu avais fait. Epok__ (Insultes, éloges, simples discussions : ✉), le 17 avril 2020 à 16:20 (CEST)
- Bonjour, @FDo64 et @Epok j'ai un problème similaire avec Catégorie:Modèle sans TemplateData serait-ce possible qu'il n'inclue que le modèle et pas sa sous page de doc ? C'est avec {{Modèle sans TemplateData}}. Cordialement, -- Nemo Discuter 20 mai 2020 à 16:59 (CEST)
- Nemo Le Poisson Fait. Epok__ (Insultes, éloges, simples discussions : ✉), le 20 mai 2020 à 18:54 (CEST)
- Merci ! -- Nemo Discuter 20 mai 2020 à 18:56 (CEST)
- Bonjour, @FDo64 et @Epok j'ai un problème similaire avec Catégorie:Modèle sans TemplateData serait-ce possible qu'il n'inclue que le modèle et pas sa sous page de doc ? C'est avec {{Modèle sans TemplateData}}. Cordialement, -- Nemo Discuter 20 mai 2020 à 16:59 (CEST)
- Bonjour Eru
- Du coup la catégorisation que j'avais ajoutée ici est à proscrire ? Discussion Projet:Bases/Archive 4#Catégorisation des propriétés & Catégorie:Page utilisant P5377 — eru [Discuter] 16 avril 2020 à 07:58 (CEST)
- Hello Berdea et FDo64
Proposition de fusion de deux modèles
Je vous invite à donnez votre avis là-bas : Wikipédia:Pages à fusionner#Modèle:Encadré texte et Modèle:Citation boîte Cordialement, -- Nemo Discuter 4 avril 2020 à 15:01 (CEST)
- Autre discussion de ma part (rien à voir) qui concerne le projet : Discussion_Projet:Wikidata#Wikidata_et_les_labels. N'hésitez pas encore une fois à venir donner votre avis ! -- Nemo Discuter 6 avril 2020 à 22:01 (CEST)
Wikipédia:Articles de qualité/Justification de leur promotion/A
J'ai découvert la page Wikipédia:Articles de qualité/Justification de leur promotion/A qui permet de lister les différentes pages de vote pour la promotion d'articles au titre d'articles de qualité.
Cette page présente plusieurs difficultés :
- Sommaire inutilisable
- Utilisation mystérieuse de <includeonly> et <noinclude>
- Mauvaise catégorisation.
Afin de m'y retrouver, j'ai créé 3 pages :
- Utilisateur:Berdea/Wikipédia:Articles de qualité/Justification de leur promotion/A Version actuelle
- Utilisateur:Berdea/Wikipédia:Articles de qualité/Justification de leur promotion/A Version d'origine
- Utilisateur:Berdea/Wikipédia:Articles de qualité/Justification de leur promotion/A Version corrigée
La version actuelle est la page actuelle dans laquelle je n'ai retenu que 2 pages de vote (pour qu'on comprenne plus facilement la structure de la page).
La version d'origine est la version établie en 2005 par Pseudomoi (qui ne contribue plus). Il y avait donc à l'origine 2 sections "Liste de liens" et "Détails" oubliées dans la version actuelle.
Les <noinclude> puis les <includeonly> ont été introduits par Verdy p également en 2005. Je ne comprends pas pourquoi (peut-être pour gérer le problème de catégorisation). La logique des 2 parties introduites par Pseudomoi a disparu.
J'ai enfin créé la version corrigée pour faire des tests et arriver à une version finalisée. Dans cette version j'ai rétabli les 2 parties. Par contre du fait de l'utilisation de {{Discussion:Accent circonflexe en français/Article de qualité}} qui comprend le modèle {{Article déchu en BA}}. Ce modèle induit une catégorisation qui n'est pas souhaitable : Catégorie:Wikipédia:Article déchu en BA (il y également les Catégorie:Wikipédia:Article déchu en AdQ et Catégorie:Wikipédia:Article promu en BA générées par les autres modèles présents). Je ne sais vraiment pas comment enlever ces catégorisations. Alors si vous pouvez trouver une solution, je suis preneur.
PS : On a par ailleurs la génération d'une table de matières que j'ai pu neutraliser en mettant __NOTOC__.
— Berdea (discuter) 15 avril 2020 à 03:37 (CEST)
- Les noinclude sont (étaient) là car ce sont aussi des pages transcluses (juste les sections alphabétiques) et effectivement les catégories mais aussi les panneaux de navigation en bas ne sont pas à répéter sous chaque section transcluse dans la page maître qui continent l'index, mais ne sont là que si on navigue sur une des sous-pages (il y a une sous-page par lettre initiale de A à Z).
- Maintenant s'il n'y a plus de page maître faisant une transclusions pour l'index complet, les noinclude ne sont plus nécessaires (il faut alors inclure un panneau de navigation d'une lettre à l'autre dans la nouvelle version de ces pages).
- Ces modifs datent tout de même de très longtemps, à une époque où il y avait encore peu d'articles promus et la classification était différente. Je pense que depuis les classements par date, thématique, et la réorganisation des votes et du suivi ne justifie plus forcément leur transclusion si on a une palette de navigation dans l'alphabet. Pour savoir si c'est utile ou pas, regarder la liste des pages qui font une inclusion de ces sous-pages (totale, ou partielle pour seulement certaines sections). Sinon en soi des noinclude autour de la catégorisation en coute rien (ce pourrait même être systématique sur plein de pages sans se poser de question si elles sont transcluses ou pas, sachant que l'inclusion des catégories a un effet de bord souvent indésirable en terme de catégorisation et sur les clés de tri utilisées qui sont valides seulement pour la page source mais pas pour la page cible de la transclusion).
- Et visiblement il semble que la page ma$itre contenant l'index alphabétique des pages promues (affichant seulement les liens seulement vers les pages de justification) a été retirée; les sous-pages lettre par lettre ne sont plus transcluses, et je ne trouve plus aucun accès à la liste alphabétique disparue mystérieusement on ne sait où; on n'a plus que des listes par date (sous-classées par année).
- La raison d'être des noinclude était la présence dans les mêmes sous-pages de deux sections: la section d'index transcluse en includeonly (avec les liens vers la page dans sa sous-section, cette section d'index étant invisible quand on visite la page mais générant très peu de code) , le reste des sections (contenant la liste détaillée et volumineuse avec les justifications) restant en noinclude; ces deux sections étant maintenues en parallèle dans la même sous-page, première partie en includeonly pour l'index (tout petit en taille) à transclure mais inutile à afficher sur la sous-page elle-même qui affiche sa propre table des matières, la seconde en noinclude avec le contenu effectif (qui peut être très long et qu'on ne peut pas transclure).
- Bref où est passée la page maître contenant l'index des articles par nom (qui existait en 2005!). et qui transcluait les 26 pages de A à Z ? Verdy p (discuter) 15 avril 2020 à 14:13 (CEST)
- Merci beaucoup pour ta réponse. Saurais-tu supprimer les catégories induites par les modèles intégrés ? — Berdea (discuter) 15 avril 2020 à 15:37 (CEST)
- C'est comme un voyage temporel de 15 ans ! — Berdea (discuter) 15 avril 2020 à 15:51 (CEST)
- Bonjour. Juste pour info. Vu sa demande d'établissement par bot de listes, il me semble que FDo64 a entrepris de corriger les modèles qui catégorisent de manière non satisfaisante. Il aura certainement besoin d'un coup de main. --Ideawipik (discuter) 15 avril 2020 à 17:43 (CEST)
Au cas où vous n'auriez pas vu ma notification du projet, j'ai posé une question sur le positionnement du rendu du modèle ici. — Berdea (discuter) 4 mai 2020 à 18:12 (CEST)
Modèle:Barre de progression 3
Bonjour,
Je vous informe que j'ai créé un modèle de barre de progression n°3 à partir de celles de WP:2 500 000, WP:3 000 000, etc.
Athozus Discussion, le 9 mai 2020 à 10:16 (CEST).
Modèle:Vid->Modèle:Vidéo ?
J'ai proposé un renommage ici sur le nom du modèle [vidéo]. Ci je trouve utile d'avoir vid en tant qu'abréviations (donc on laisse de toute façon une redirection), je pense que le nom le plus approprié est Modèle:vidéo, plus clair pour tous le monde. N'hésitez pas à donner votre avis là-bas ! Sinon je me dis que ce serait utile d'avoir une page équivalente à la page anglophone en:Wikipedia:Templates_for_discussion pour notamment ce genre de chose. -- Nemo Discuter 29 avril 2020 à 15:51 (CEST)
- Hello Nemo Le Poisson : je corrige, si débat il doit y avoir, c'est ici ou sur la pdd du modèle et non là-bas ! La page des demandes de renommage n'est pas destinée à discuter sur la pertinence du renommage.
- De mon point de vue : 1198 inclusions de la redirection {{Vidéo}} sur 5611 utilisations totale du modèle, la syntaxe "Vidéo" est donc déjà loin d'être anecdotique (par contre, je ferai bien sauter la redirection {{Video}}, mal orthographiée et peu utilisée). Tant qu'on garde une redirection vers le nouveau nom depuis l'ancien modèle, je suis
Pour une clarification du nom du modèle. Epok__ (Insultes, éloges, simples discussions : ✉), le 29 avril 2020 à 17:27 (CEST)
- J'ajoute que si on renomme celui-ci il faudrait également faire de même avec {{Img}} -> {{Image}}, par cohérence. Epok__ (Insultes, éloges, simples discussions : ✉), le 2 mai 2020 à 09:09 (CEST)
- Je suis également favorable à Modèle:Vidéo. Je n'aime pas trop les abréviations, car parfois on ne sait pas ce que cela veut dire. — Berdea (discuter) 4 mai 2020 à 18:10 (CEST)
- J'ajoute que si on renomme celui-ci il faudrait également faire de même avec {{Img}} -> {{Image}}, par cohérence. Epok__ (Insultes, éloges, simples discussions : ✉), le 2 mai 2020 à 09:09 (CEST)
┌─────────────────────────────────────────────────┘
Je suis aussi favorable pour {{Image}} semble aussi aller dans ce sens. Mais tant qu"on y est, je propose de systématiquement mettre le nom du format tel qu'affiché :
Je ne sais pas si l'idée de base était de mettre 3 lettres pour tous les modèles de format mais en tous cas c'est plus d'actualité. Qu'en pensez-vous 
Berdea et Epok :, je notifie aussi les créateurs de ces modèles : @Liné1, @Cantons-de-l'Est et @Weft. -- Nemo Discuter 5 mai 2020 à 16:45 (CEST)
- Nemo Le Poisson, Je préfère {{vidéo}}, {{image}}, {{TeX}} et {{Audio}}, mais je suis neutre pour {{XML}}. — Cantons-de-l'Est p|d|d [sysop] 5 mai 2020 à 19:05 (CEST)
- {{Vidéo}} est le plus utilisé donc Pour, ce n'est pas le cas de {{Image}} et {{Audio}} mais il faut rester cohérent et cela favorisera leurs usages.
- {{XML}} pourquoi pas vu que le rendu est en capital, même s'il n'existe pas actuellement.
- Par contre {{Tex}} et {{TeX}} ont un rendu différent actuellement. — eru [Discuter] 5 mai 2020 à 19:12 (CEST)
- Si il faut généraliser :
- {{Vidéo}}, {{Image}} et {{Audio}}, même combat : Pour.
- {{TeX}} :
Plutôt contre. Pas convaincu car il existe déjà un modèle différent à ce nom, qui totalise presque 90 inclusions contre... 7 pour le modèle {{Tex}}, soit 10 fois plus... - {{XML}} :
Neutre. L'un comme l'autre me vont : {{Xml}} pour la majuscule initiale (comme les autres), {{XML}} pour le rendu, kif-kif de mon point de vue. Par contre, si on va dans ce sens, il faut probablement renommer {{Mp3}}, {{Pdf}}, etc. donc ça implique sûrement un débat complet sur la capitalisation, différent de celui en cours qui concerne les abréviations. Et si on tranche en faveur de la majuscule initiale, il faudra alors renommer {{RAR}}.
- {{Vidéo}}, {{Image}} et {{Audio}}, même combat :
- Epok__ (Insultes, éloges, simples discussions : ✉), le 5 mai 2020 à 20:17 (CEST)
- Il ne semble pas y avoir d'opposition pour les 3 modèles {{Vidéo}}, {{Image}} et {{Audio}}, je renomme donc ceux-ci. Pour les autres, la discussion peut se poursuivre. Epok__ (Insultes, éloges, simples discussions : ✉), le 8 mai 2020 à 09:40 (CEST)
- Ok, c'était le principal, pour le reste ça reste du détail. Le plus simple reste donc de renommer RAR. Mais je suis satisfait des trois renommage qui rendent le tout plus compréhensible/ -- Nemo Discuter 10 mai 2020 à 18:43 (CEST)
- Il ne semble pas y avoir d'opposition pour les 3 modèles {{Vidéo}}, {{Image}} et {{Audio}}, je renomme donc ceux-ci. Pour les autres, la discussion peut se poursuivre. Epok__ (Insultes, éloges, simples discussions : ✉), le 8 mai 2020 à 09:40 (CEST)
- Si il faut généraliser :
- {{Vidéo}} est le plus utilisé donc
Modèle liés
FDo64 : Vu que tu travaille en ce moment sur le sujet des catégorisations inappropriées des documentation de modèles, est-ce que tu pourrais jeter un coup d'oeil sur {{Projet}} ?
Par exemple un {{Projet|Infobox}} hors includeonly sur une page de documentation d'infobox catégorise à la fois le modèle et sa page de doc dans Catégorie:Projet:Infobox/Modèles liés, cela est parfois contourné en mettant le {{Projet|Infobox}} dans les balises includeonly (avec les catégories pour le modèle), mais ce n'est pas idéal, et parfois compliqué à comprendre quand on ne connaît pas.
Aucune urgence, ce petit problème est présent depuis longtemps, mais si on peut le corriger un de ces jours, tant mieux 
.
Merci d'avance.
--Tractopelle-jaune (discuter) 22 mai 2020 à 16:21 (CEST)
- Bonjour Tractopelle-jaune . Je veux bien m'en charger mais ce n'est pas aussi simple puisque la modification n'est pas à faire dans le modèle {{Projet}} mais dans les 29 modèles de projets de la Catégorie:Modèles liés par projet. Dans ton exemple, c'est {{Projet Infobox}}.
- Pour simplifier, il faudra créer un modèle qui catégorise.
- Question : faut-il aussi filtrer les bacs à sable et les pages de test ?
- --FDo64 (discuter) 22 mai 2020 à 18:28 (CEST)
- Bonsoir Tractopelle-jaune . C'est encore pire que ce que j'expliquais hier. Il y a deux types de modèles qui effectuent ces catégorisations : ceux du style {{Projet Infobox}}, mais aussi ceux du style {{Catégorie tunnels}}.
- Et encore, ça ce n'est rien ! Dans ces deux familles de modèles, il y en a qui ne génèrent que la catégorie
/Modèles liéset ceux qui traitent jusqu'à 4 cas :/Modèles liés,/Références liées,/Catégories liéeset/Articles liés. - Du coup je ne sais pas trop quoi faire : uniformiser à 4 sous-catégories ou laisser ainsi ?
- --FDo64 (discuter) 23 mai 2020 à 22:54 (CEST)
- Bonjour Tractopelle-jaune . J'ai remis un peu d'ordre hier dans tout ça en créant les catégories principales manquantes et quelques bandeaux.
- Voici l'état des lieux :
- Catégorie:Articles liés par portail, {{Articles liés}} : 66 sous-catégories
- Catégorie:Catégories liées par projet, {{Catégories liées}} : 1 174 sous-catégories
- Catégorie:Fichiers liés par portail, {{Fichiers liés}} : 6 sous-catégories
- Catégorie:Modèles liés par projet, {{Modèles liés}} : 29 sous-catégories
- Catégorie:Références liées par projet, {{Références liées}} : 2 sous-catégories
- et il faut rajouter 7 catégories
/Pages liées:- 5 pour des pages de discussion utilisant le modèle {{Suivi des discussions}} : Catégorie:Projet:Bob Dylan/Pages liées, Catégorie:Projet:Boxe anglaise/Pages liées, Catégorie:Projet:Catch/Pages liées, Catégorie:Projet:Îles/Pages liées, Catégorie:Projet:Nord-Amérindiens/Pages liées
- 1 qui devrait être à priori renommée
/Articles liés: Catégorie:Projet:Biologie/Pages liées - 1 qui est bien nommée : Catégorie:Projet:Correction syntaxique/Pages liées
- En regardant le contenu de ces catégories, seules les
/Modèles liéscontiennent des pages non désirées, on peut donc se contenter de rajouter un contrôle uniquement pour celles-là. - --FDo64 (discuter) 23 juin 2020 à 09:08 (CEST)
- Tractopelle-jaune : Fait. --FDo64 (discuter) 24 juin 2020 à 00:33 (CEST)
- Bonjour Tractopelle-jaune
- Bonsoir Tractopelle-jaune
Utilisation du modèle Liste horizontale sur la Palette Corée du Nord
Bonjour,
J’ai remarqué un problème graphique gênant, sur la palette {{Palette Corée du Nord}}, j’ai un bug graphique provenant du fait que chaque lien interne de la palette se situe à l’intérieur du modèle {{liste horizontale}}, et le texte dépasse du cadre ajoutant une barre de défilement horizontale inutile (exemple sur cette page Division 39).
Voici un screenshot du problème graphique :
Pourriez-vous résoudre ce problème ? Savez-vous d’où vient ce souci et comment le résoudre ? En vous remerciant ! — Koreller 17 avril 2020 à 19:32 (CEST)
- Je n'ai pas la réponse mais tu devrais peut-être indiquer quel système tu utilises (système d'exploitation, navigateur) car ce n'est pas reproductible partout avec la version classique. La palette n’apparaît pas sur la version mobile. --Ideawipik (discuter) 17 avril 2020 à 20:05 (CEST)
- Ce problème est connu et se produit dans de (rares) conditions précises avec le navigateur Mozilla Firefox (et probablement ceux utilisant le même moteur de rendu). Il s'agit a priori d'un bug dans le moteur de rendu Gecko du navigateur.
- Citation de Zebulon84 de 2018 sur la PdD du modèle : « C'est lié à une balise dans le dernier élément de la liste, quelle qu'elle soit [...]. Dans ton exemple il y a une balise <a> (un lien) dans une balise <i> (l'italique) [...] ».
- Voir cette discussion Discussion modèle:Liste horizontale#Bug d'affichage et le rapport de bug chez Mozilla : https://bugzilla.mozilla.org/show_bug.cgi?id=1497833.
- Il n'y a rien qui puisse être fait en l'état pour le corriger.
- Ce serait bien de préciser ton navigateur, et sa version (l'information peut généralement être obtenue dans le menu « Aide » → « À propos » de ton navigateur) pour confirmer qu'il s'agit bien du même bug.
- --Tractopelle-jaune (discuter) 17 avril 2020 à 21:27 (CEST)
- Je suis sur Mozilla Firefox 75.0 (64 bits), si le problème est rare alors ça me va, j’utiliserai ce modèle plus souvent alors — Koreller 19 avril 2020 à 22:31 (CEST)
- Je suis également sur Firefox (comme beaucoup). Ce modèle ne gère pas l'insécabilité. Personnellement dans ce cas là j'utilise le modèle:liste éléments. — Berdea (discuter) 4 mai 2020 à 18:08 (CEST)
- Berdea : Bonsoir, je réagis à ton (mauvais) conseil : il ne faut surtout plus utiliser {{Liste éléments}} qui est obsolète et qui pose des problèmes d'accessibilité. Nous sommes au moins deux à le remplacer systématiquement par {{Liste horizontale}}. Peut-être qu'un filtre serait nécessaire pour empêcher qu'on l'utilise encore ?
- Pour ce qui est du bug signalé, cela semble ne concerner que le tout dernier élément de la liste. J'ai donc ajouté le modèle {{Sécable}} là ou cela posait problème dans la copie d'écran. Est-ce mieux ?
- --FDo64 (discuter) 4 mai 2020 à 19:20 (CEST)
- Je me doutais que tu réagirais () ! Ne pourrait-on ajouter les paramètres "séparateur" "espaces" et "sécable" au modèle comme pour le modèle:Liste éléments ? Cela résoudrait le problème sans utiliser le modèle:sécable — Berdea (discuter) 4 mai 2020 à 19:41 (CEST)
- Berdea : Comme je ne demande qu'à te contenter
, j'ai testé en ajoutant | style = white-space:normaldans {{Liste horizontale}}, mais ça ne fonctionne pas. Il me semble que Tractopelle-jaune avait l'intention de travailler sur ce sujet. --FDo64 (discuter) 4 mai 2020 à 19:56 (CEST)
- Je me doutais que tu réagirais (
- Je suis également sur Firefox (comme beaucoup). Ce modèle ne gère pas l'insécabilité. Personnellement dans ce cas là j'utilise le modèle:liste éléments. — Berdea (discuter) 4 mai 2020 à 18:08 (CEST)
- Je suis sur Mozilla Firefox 75.0 (64 bits), si le problème est rare alors ça me va, j’utiliserai ce modèle plus souvent alors — Koreller 19 avril 2020 à 22:31 (CEST)
┌─────────────────────────────────────────────────┘
Berdea et FDo64 : En effet, en fouillant un peu, suite à cette discussion de juillet 2019, j'avais fait quelques tests sur Utilisateur:Tractopelle-jaune/BrouillonL (avant d'arrêter de contribuer en août 2019 par manque de temps) visant surtout la gestion de la sécabilité dans {{Liste horizontale}}. Je vais donc reprendre en bonne ce que j'avais écris là-bas, en adaptant au besoin.
L'utilisation du modèle {{Liste horizontale}} (qui utilise la classe .liste-horizontale, définie dans MediaWiki:Common.css) permet de construire des listes conformes aux principes d'accessibilité du contenu, permettant d'améliorer fortement la sémantique et l'accessibilité de la consultation de l'encyclopédie pour les personnes malvoyantes (qui utilisent des outils comme un lecteur d'écran, celles utilisant un navigateur en mode texte, ou encore dont les styles de mise en page sont désactivés.
Plus d'informations sur Wikipédia:Atelier accessibilité/Bonnes pratiques#Listes à puces et listes numérotées.
Concernant la puce, elle est générée par du « contenu ajouté » CSS (propriété content: "· ";), imposant donc l'utilisation de sélecteurs CSS et de pseudo-éléments CSS, ce n'est donc techniquement pas modifiable dynamiquement avec un paramètre, même avec la nouvelle extension TemplateStyles. La seule possibilité d'utiliser d'autres séparateurs repose sur la possibilité de définir en dur une nouvelle classe CSS, utilisant un autre caractère séparateur. Mais je ne suis vraiment pas chaud pour cela (solution très lourde pour juste changer un caractère).
Le modèle {{Liste horizontale}} et sa classe .liste-horizontale étant avant tout utilisés sur les palettes de navigation, cela ne ferrait que reproduire les mêmes dérives que l'on essaie au contraire progressivement de réduire. J'entends par là l'utilisation de telle ou telle mise en forme par préférence personnelle.
Concernant la gestion des diverses formes de sécabilité ou non, c'est assez compliqué, mais c'est clairement un point qui laisse effectivement à désirer dans certains cas.
Le principe actuel (qui ne doit pas être modifié, car il est correct dans 99 % des cas), c'est que les éléments sont insécables, donc un retour à la ligne ne peut être fait par le navigateur qu'au niveau des puces (séparateurs). Et si un élément de la liste contient des sous-éléments (2e niveau ou plus d'une liste ; code wiki : ** ...), les sous-éléments peuvent aussi être séparés au niveau de leurs séparateurs.
Il serait parc contre souhaitable d'avoir d'autres comportements possibles, par exemple :
sécable=restreint: autoriserait de séparer entre les éléments de premier niveau uniquement (interdiction de la séparation entre les sous-éléments). Serait parfois utile pour garder une certaine cohérence visuelle sur des palettes de navigation avec de nombreux sous-éléments, sans aucun impact sur l'accessibilité. Exemple récent que j'avais gardé en tête : Modèle:Palette Champions d'Europe du relais 4x400 m (voir avant) (à noter que je suis pas un fan de l'utilisation de<small>pour les sous-éléments comme utilisé sur cette palette, mais j'ai comme habitude de ne pas trop toucher à ce genre de choix).sécable=auto: mode actuel ; par défaut.sécable=oui: tout est sécable, partout.
Voici les règles CSS que j'ai surchargées pour le test (CSS sur Utilisateur:Tractopelle-jaune/Brouillon/styles.css, rendu sur Utilisateur:Tractopelle-jaune/BrouillonL) :
.liste-horizontale.liste-horizontale-secable-restreint li li:first-child:before,
.liste-horizontale.liste-horizontale-secable-restreint li li + li:before
{
white-space: nowrap;
}
.liste-horizontale.liste-horizontale-secable li
{
white-space: normal;
}
(note : noms des classes et paramètres encore à étudier)
Par contre, cela n'est pas des plus simples à réaliser.
Du fait qu'il n'est pas possible d'utiliser des attributs HTML style="" (à cause de l'utilisation obligatoire de sélecteurs CSS), je ne vois que deux possibilités, mais aucune des deux n'est parfaite :
- Créer deux nouvelles classes dans MediaWiki:Common.css, en surchargeant les sélecteurs CSS concernés de la classe
.liste-horizontale(par augmentation de la spécificité via la seconde classe). Implique l'envoi à tous les navigateurs de plusieurs règles CSS supplémentaires inutiles dans la quasi-totalité des cas. Par contre, cela permettrait de modifier la sécabilité à la demande partout où la classe.liste-horizontaleest appelée (mais l'intérêt de cette possibilité reste très limité...). L'intérêt principal de cette option reste la clarté du code CSS du wiki, en regroupant tout au même endroit. - Créer deux nouvelles classes dans Modèle:Liste horizontale/styles.css (feuille de style chargée par l'extension TemplateStyles), mais toujours en surchargeant les sélecteurs CSS concernés de la classe
.liste-horizontaledéfinie dans MediaWiki:Common.css (par augmentation de la spécificité via la seconde classe). Le modèle {{Liste horizontale}} injecterait néanmoins la feuille de style Modèle:Liste horizontale/styles.css uniquement en cas de besoin (afin d'éviter l'envoi de données inutiles au navigateur, ce qui, vu le nombre de pages appelant au moins une palette, n'est pas négligeable du tout). Cette solution est également plus souple. Par contre, elle implique que la mise en forme CSS du modèle serait gérée à deux endroits différents, ce qui n'est pas top, sans être absolument rédhibitoire pour autant.
Je notifie 
Od1n pour avoir son avis
Concernant les problèmes avec Firefox sur la {{Palette Corée du Nord}}, ils sont causés par un bug de Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1497833). Ce bug ne touche que le dernier élément d'une liste, et se produit (d'après ce que j'ai compris) quand cet élément contient une balise qui en contient une autre (du genre <a href="...">texte lien <i>en italique</i></a>). Cela peut donc concerner les derniers éléments qui comportent une mise en forme particulière (gras/italique/small) ou qui utilisent le modèle {{Lien}}). Le navigateur, au lieu de renvoyer l'ensemble du dernier élément à la ligne suivante, le laisse alors déborder du cadre. Firefox est utilisé par environ 12 % des visiteurs de WP (+ sûrement quelques % des navigateurs autres, utilisant le même moteur de rendu).
--Tractopelle-jaune (discuter) 4 mai 2020 à 21:10 (CEST)
- Merci Tractopelle-jaune pour cette proposition qui répond bien au besoin, même si je ne saurai t'aider pour les aspects CSS.
- --FDo64 (discuter) 4 mai 2020 à 21:52 (CEST)
- Ben ça c'est du rapport de qualité :) Du coup, pas grand chose à ajouter. Pour les valeurs de paramètres, je proposerais plutôt
sécable = oui / non / partiel. Pour les deux possibilités (Common.css ou TemplateStyle conditionnel), on doit penser la même chose : les deux solutions sont acceptables, mais chacune a des défauts, et je n'arrive pas à me décider laquelle serait la "moins pire". À la rigueur, c'est un détail d'implémentation qui peut toujours être modifié plus tard sans trop de difficulté. - Si ça peut aider à choisir, en plus de la taille de code transmis au navigateur, j'essaie de penser aussi à l'impact sur les performances du parsage CSS (certes on considère généralement que ce n'est pas un point de préoccupation, mais les petits fleuves font les grandes rivières). En l'occurrence, ça fait analyser tous les éléments <li> de la page (rappel : évaluation right-to-left), potentiellement nombreux (par exemple dans des palettes, justement). Avec la solution 1 il y aura l'impact sur toutes les pages, avec la solution 2 il y aura l'impact seulement sur une partie des pages (pas parfait non plus, car là aussi on a un modèle qui provoque un impact sur l'ensemble de la page ; mais c'est quand même moins pire, vu que moins de pages sont touchées).
- En cas d'utilisation de la solution 2, il faudra impérativement ajouter un commentaire de ce style dans le Common.css :
/* voir aussi [[Modèle:Liste horizontale/styles.css]] qui est optionnellement chargé par [[Modèle:Liste horizontale]] */- od†n ↗blah 5 mai 2020 à 07:58 (CEST)
- Pour info nous avons un problème similaire ici : Discussion modèle:Bases art#Retour à la ligne — eru [Discuter] 28 mai 2020 à 08:40 (CEST)
- Eru : Bonjour, il s'agit du même problème puisque Module:Bases utilise la class 'liste-horizontale'. --FDo64 (discuter) 28 mai 2020 à 08:59 (CEST)
- Pour info nous avons un problème similaire ici : Discussion modèle:Bases art#Retour à la ligne — eru [Discuter] 28 mai 2020 à 08:40 (CEST)
- Ben ça c'est du rapport de qualité :) Du coup, pas grand chose à ajouter. Pour les valeurs de paramètres, je proposerais plutôt
Afficher le bandeau de lecture d'un fichier-son juste sous une icône cliquable
Bonjour à tous,
J'espère être au bon endroit, à tout le moins parmi des gens bienveillants, pour ce qui m'amène. Dans l'Incubateur, nous développons depuis des mois un projet de WP pour la langue Kotava (n'hésitez pas à le visiter, je pense que le projet est de qualité).
Nous avons déjà notamment des centaines d'articles consacrés aux espèces animales, et je voudrais pourvoir associer des fichiers-son de prononciation de mot (qui existent déjà sur Commons et sont utilisés dans plusieurs wiktionary dont celui en français), d'une façon à la fois simple, élégante et efficace. La solution consiste in fine à atterrir sur un appel à [[File :xxx.wav]].
Voyez ces deux tests :
Dans le premier, cela affiche une petite icône (avec un fichier-image choisi et paramétré librement) qui passe en "link" l'appel au fichier-son correspondant (passé en paramètre au cartouche-modèle). Dans le second cas, il y une insertion directe du fichier-son, bricolée et tronquée en affichage ; un clic dessus effectue la lecture.
L'avantage du second est qu'on reste dans l'article et la page, et la lecture est immédiate. L'inconvénient fondamental, par contre, est graphique. Il est impossible de placer "l'image" autrement qu'à gauche (sinon sauts de lignes) ni d'en changer l'aspect. Je pourrais juste bricoler un peu mieux, je pense, les propriétés "margin" pour mieux la caler.
J'aimerais beaucoup plus une solution type n°1, avec une icône non qui enverrait sur la lecture extérieure dans Commons du fichier-son (par le lien), mais qui ouvrirait plutôt juste dessous (donc en ne quittant pas la page, avec certes clic de plus mais vraiment volontaire, à la manière des tips ou d'une boite déroulante) l'affichage standard d'un bandeau fichier-son, sous donc la forme , de la même manière que lorsqu'on clique sur le bouton "menu" de cet affichage cela ouvre dessous. J'ai bien tenté par le biais d'insertion dans une boîte déroulante, mais cela ne fonctionne pas : seul l'espace en bande grise de la barre de lecture apparait (réglable en longueur), mais aucun des boutons normalement présents. Evidemment je pourrais faire une insertion simple, mais cela casserait totalement le visuel des infobox dans lesquelles je souhaite les faire apparaître.
Je pense que la solution doit exister au travers de l'utilisation de modules, mais j'avoue que je ne suis pas très à l'aise là-dessus. En outre, l'Incubateur révèle des restrictions parfois assez surprenantes par rapport aux espaces autonomes de projet, et peu de contributeurs experts sur ces questions.
Voilà, j'espère avoir été suffisamment explicite sur ma difficulté. Si des personnes expérimentées peuvent m'apporter la solution ou des pistes, j'en serai ravi. Et mes excuses si je me suis trompé d'endroit. Nevatovol (discuter) 21 mai 2020 à 16:53 (CEST)
- Bonsoir Nevatovol . J'avoue que je n'ai pas bien compris ce que tu recherches, ne serait-ce pas le modèle {{Prononciation}} ?
- --FDo64 (discuter) 21 mai 2020 à 22:05 (CEST)
- Bonsoir FDo64
- Non. Tel quel, ce modèle {{Prononciation}} est le même que mon actuelle solution n°1 incomplète ; il est juste un lien qui envoie ensuite sur une autre page (celle du fichier-son). Ce que je voudrais au mieux, c'est qu'une icône cliquée affiche visuellement en dessous et attachée à elle la barre de lecture standard d'un fichier-son, mais cela sans quitter la page où on est, que donc la barre se retrouve en sur-impression, ou comme dans le principe du Hide/Show des listes déroulantes (que cela décale ou non momentanément la suite normale des affichages). Sur le même principe en sorte que le bouton "menu" de cette fameuse barre, qui ouvre une sorte de fenêtre attachée en surimposition et contenant divers éléments eux-mêmes affectables de liens et autres.
- Ma solution n°2 arrive à un résultat direct (la lecture du fichier-son sans quitter la page), mais elle est inélégante, non personnalisable visuellement et n'offre aucun développement possible de contenu (comme ne seraient-ce que les mentions d'identité du fichier ou un éventuel message d'avertissement, etc.).
- J'ai aussi fait des tests avec des inclusions avec
<ImageMap>ou<Gallery>, mais à chaque fois seule l'empreinte grise de réservation de la barre de lecture apparait et ses boutons eux ne sont pas émulés. - En programmation classique, c'est tout simple à réaliser, mais là c'est un problème d'insertion dynamique d'un objet que semble ne pas bien gérer l'interpréteur wiki.
- Merci. Nevatovol (discuter) 22 mai 2020 à 04:26 (CEST)
- Bonjour Nevatovol . Dans ce cas, je laisse d'autres répondre. Et comme je viens seulement de comprendre ton besoin, je leur indique que cela concerne le titre de l'Infobox.
- D'autre part, comme il ne s'agit pas de Wikipédia, pas sûr que quelqu'un te réponde…
- --FDo64 (discuter) 22 mai 2020 à 12:27 (CEST)
- Bonjour Nevatovol
- Bonsoir FDo64
Création de modèles et de modules à partir d'autres versions linguistiques
Bonjour.
- Lors de la création sur frwiki de modèles ou de modules, par copier-coller depuis des wikis dans d'autres langues, la moindre des choses ne serait-elle pas de l'indiquer, au moins dans le commentaire de création de la page ou en page de discussion du modèle. Quel est l'usage ?
- Quid de la création de modèles ou modules inutilisés ?
- Dans quelle mesure les titres doivent-il être francisés ?
- Attention à adapter le reste du contenu du modèle ! nom des catégories, etc.
Pour prendre un exemple récent : FrenchPower59500 : modules et modèles mais la question est plus générale et ne vise pas un contributeur en particulier. Il n'y a rien en ce sens dans les Aide:Modèle/Aide:Module.
Remarque annexe : il faudra penser à mettre davantage en valeur les quelques conventions sur les titres spécifiques aux modèles (Nom en majuscule et pas de mot « navigation » dans les palettes, etc) et les catégorisations, pour faciliter la vérification qu'aucun « modèle équivalent n’existe sous un titre différent ».
Cordialement. --Ideawipik (discuter) 17 juin 2020 à 16:47 (CEST)
- Salut Ideawipik ,
- De mon point de vue :
- Oui, et on peut utiliser pour cela le modèle {{Traduit de}} en pdd, comme pour les articles (j'ai déjà vu ce modèle apposé dans la doc, pourquoi pas aussi).
- Ils doivent être identifiés, et si vraiment sont inutiles (doublon d'un modèle français, modèle inutile pour notre version linguistique, modèle toujours inutilisé un certain temps après sa création, etc.), supprimés. Une liste de modèles inutilisés existe déjà : y'a du boulot;
- Obligatoirement, avec éventuellement une redirection depuis le titre anglais dans le cas où ils sont susceptibles d'êtres utilisés dans des articles par copier-coller entre les versions linguistiques.
- Pareil pour les paramètres et catégories : sur WP en français, les modèles doivent être francisés. La seule exception que je vois est le cas d'un mot dans une autre langue couramment utilisé en français (je ne suis pas un intégriste qui refuse l'ajout de mots étrangers dans une langue, loin de là : si le mot est dans l'usage courant, je l'accepte sans problème).
- Wikipédiennement, Epok__ (Insultes, éloges, simples discussions : ✉), le 17 juin 2020 à 17:07 (CEST)
Modèle:Élu - Ajout couleur politique
Bonjour,
Je viens vers vous pour avoir votre ressenti concernant une modification de Modèle:Élu. En effet, je souhaiterais que l'on ajoute une colonne supplémentaire dans 'Parti' pour afficher la couleur politique du parti en question, sur le modèle 'Infobox Parti politique français/couleurs'. Le modèle actuel est assez triste, terne, et ajouter une pointe de couleur permettrait d'y voir plus clair (et de terminer la tendance politique d'une commune en un coup d'oeil).
Nous sommes deux à faire cette requête (voir Discussion_modèle:Élu), néanmoins la page est assez inactive donc je fais appel à vous. L'on me demande d'avoir un consensus du projet pour pouvoir faire modifier le modèle (Wikipédia:Demande_d'intervention_sur_une_page_protégée#Modèle:Élu_(d_·_h_·_j_·_↵)).
--Julmath (discuter) 30 juin 2020 à 14:33 (CEST)
- Julmath : Bonsoir, notre projet peut principalement donner un avis technique. Ce qui n'est pas le cas de ta question. Personnellement je n'ai pas d'avis, juste te faire constater que cela ajouterait une colonne, alors que Roland45 tente de le réécrire en ce moment en en supprimant deux.
- Peut-être voir avec le projet:Politique ou le projet:Communes de France ?
- --FDo64 (discuter) 30 juin 2020 à 22:19 (CEST)
- Bonsoir FDo64, je n'ai pas non plus d'avis tranché sur le fond et ai donné exactement la même réponse que toi au requérant sur la pdd du modèle. Techniquement, il n'y aurait pas forcément besoin d'ajouter une colonne. Cf le tableau suivant, avec deux exemples légèrement différents du paramétrage à régler. L'accessibilité ne devrait pas en être affectée.
- Remarque hors sujet : Julmath, il est préférable d'éviter les symboles barre verticale (pipe) dans les titres de section ou de discussion. Pas évident à manipuler pour créer des liens internes.
- Test : FDo64. Pourrais-tu, STP, me dire si tu a reçu cette notification (doute sur le fonctionnement avec le tableau placé en dessous). Merci. — Ideawipik (discuter) 30 juin 2020 à 23:39 (CEST)
- Ideawipik : Les notifs fonctionnent à partir du moment où on ne modifie pas le texte qui précède le nouveau message, et que l'on signe. --FDo64 (discuter) 1 juillet 2020 à 00:24 (CEST)
- Hors sujet, notifs
- Donc d'après ton expérience, les notifications fonctionnent même si on utilise plusieurs niveaux d'indentations (deux points) dans sa propre réponse, même avec des tableaux intercalés et même si on ne signe pas à la toute fin du message.
Si on répond d'un bloc, en respectant l'indentation et la signature, même avant le dernier message présent, la notification fonctionne bien. Bien reçu celle du message de Julmath écrit après (23:56) et au-dessus du sien antérieur (23:45). Tout ce qui précède est cohérent si on peut se fier à mw:Manual:Echo. Elle marcherait également quand on fait des réponses point par point intercalées dans le message de son interlocuteur, du moment qu'on ajoute des lignes sans nouvelle section et que la notification n'est pas placée dans un modèle. — Ideawipik (discuter) 1 juillet 2020 à 08:46 (CEST) - Fin du hors sujet.
| Période | Identité | Étiquette | Qualité | |
|---|---|---|---|---|
| Début | Fin | Identité | Parti | Qualité |
| Début | Fin | Identité | Parti | Qualité |
| Début | Fin | Identité | Parti | Qualité |
- Ideawipik : Le tableau rend assez bien, le seul problème est que ça obligerait à renseigner les codes couleur à chaque fois en lieu et place des codes parti définis à Modèle:Infobox Parti politique français/couleurs (et qui nous simplifient bien la vie...). Ça fait un peu mal aux yeux avec des couleurs claires également (ex. #ffeb00), le fait de ne pas avoir de fin de case à proprement parler manque un peu.
- J'avoue ne pas être spécialiste des règles d'accessibilité, Modèle:Infobox Parti politique français/couleurs contrevient-il à ces règles? Parce qu'on le voit déjà un peu partout, y compris sur des articles récents...
- Merci pour l'avertissement sur les barres verticales, c'est une vieille habitude mais je ne pensais pas qu'elle posait problème avec WP ^^ --Julmath (discuter) 30 juin 2020 à 23:56 (CEST)
- Hors sujet, pipe
- Comme les crochets et les accolades, le caractère « barre verticale » est un élément très utilisé de la syntaxe wiki : dans les modèles (paramètres), dans les fonctions d'analyse, dans les liens internes, dans les tableaux. Pas la peine d'en rajouter ailleurs ni de compliquer les choses quand ce n'est pas indispensable. Par exemple le code
[[Discussion Projet:Modèle#Modèle:Élu | Ajout couleur politique|libellé souhaité du lien]]permettrait de créer un lien vers la présente section. Pas forcément intuitif ce code ascii ! - Fin du hors sujet.
- Le tableau proposé… Il s'agit juste d'une maquette pour minimiser ma première réaction identique à celle de FDo64 et montrer qu'il existe des réponses aux difficultés entraperçues. L'ajout d'une colonne est une astuce souvent mise en pratique dans WP pour ce genre de "fonctionnalité" mais n'est pas vraiment idéal pour l'accessibilité des tableaux. Il existe donc au moins une alternative. Je ne suis pas assez calé pour juger de l'accessibilité des couleurs choisies. L'intégration, dans le fonctionnement du modèle Élu, des couleurs prédéfinies, via {{Infobox Parti politique français/couleurs}} est prévue. Il y aura un choix à faire pour la méthode d'intégration des couleurs. On peut déjà imaginer des possibilités :
- un paramètre supplémentaire couleur à renseigner par un code de la liste, avec l'avantage de laisser de la souplesse pour le contenu du paramètre Parti/Etiquette ;
- pas d'ajout de paramètre et une utilisation du paramètre déjà existant. On perdrait l'avantage précédent ;
- un fonctionnement hybride mais qui pourrait aboutir à un modèle plus complexe et gourmand en ressources, avec un recours à davantage de tests internes
- Mais attendons les avis des projets concernés avant d'agir,seulement si un consensus en ce sens est établi.
- — Ideawipik (discuter) 1 juillet 2020 à 08:46 (CEST)
- FDo64 : Bonsoir, merci pour ta réponse. À vrai dire je me suis un peu mal exprimé, c'est une colonne en plus en termes de data mais stricto sensu c'est plutôt une espèce de division d'une colonne déjà existante, une bordure de case peut-être (cf Élections_municipales_de_2020_en_Seine-et-Marne#Maires_sortants_et_maires_élus, ça sera plus clair).
- J'ai posté sur les pages de discussion des deux projets cités et attends une réponse de leur part. --Julmath (discuter) 30 juin 2020 à 23:45 (CEST)
- Bonjour à tous. Pour ma part je ne suis pas contre l'ajout d'une couleur au modèle pour définir la nuance sur laquelle est élu le maire, mais ceci ne s'appliquerait qu'aux élections après la Libération, avant cela ne veut pas dire grand chose, et encore moins avant 1884 puisque qu'avant cette date les maires étaient nommés et non élus au suffrage universel. Donc je confirme par ailleurs mon souhait de disposer d'un modèle ne comportant pas cette colonne parti. La présentation des données pourrait être éclatée en deux tableaux : avant et après Libération, ou avant et après 1884, comme on veut. On pourrait donc avoir deux modèles. Cordialement.Roland45 (discuter) 1 juillet 2020 à 14:16 (CEST)
- Roland45 : Bonjour, bonne remarque. Certains articles de commune font déjà la distinction entre l'après- et l'avant-Libération, ça serait quelque chose à généraliser. Avant Libération, la colonne "Parti" est presque totalement inutile car souvent vide dû au manque de disponibilité de la donnée.
- Plusieurs exemples pour chaque cas de figure: Moret-sur-Loing possède deux tableau séparés, un pré-44 l'autre post-44; Fontainebleau possède un tableau déroulant pré-45 dans le tableau général; Montereau-Fault-Yonne ne fait la distinction que par rapport à la Révolution, etc... --Julmath (discuter) 1 juillet 2020 à 14:37 (CEST)
- Bonjour à tous. Pour ma part je ne suis pas contre l'ajout d'une couleur au modèle pour définir la nuance sur laquelle est élu le maire, mais ceci ne s'appliquerait qu'aux élections après la Libération, avant cela ne veut pas dire grand chose, et encore moins avant 1884 puisque qu'avant cette date les maires étaient nommés et non élus au suffrage universel. Donc je confirme par ailleurs mon souhait de disposer d'un modèle ne comportant pas cette colonne parti. La présentation des données pourrait être éclatée en deux tableaux : avant et après Libération, ou avant et après 1884, comme on veut. On pourrait donc avoir deux modèles. Cordialement.Roland45 (discuter) 1 juillet 2020 à 14:16 (CEST)
┌─────────────────────────────────────────────────┘
Bonjour Amrcmln, Ideawipik, Tyseria, Julmath, FDo64 et Roland45,
Désolé de n'avoir pas pu répondre tout de suite à la notif sur Discussion modèle:Élu#Couleur des tendances politiques, pas eu le temps.
Pour l'accessibilité, je confirme qu'il faut vraiment éviter de créer des colonnes vides pour y mettre uniquement un arrière-plan.
J'ai fait un test avec le lecteur d'écran NVDA, et les colonnes vides sont bien traitées comme des colonnes normales, et annoncées comme telles. Donc cela complique bien la lecture du tableau.
D'autant plus qu'il ne faudrait pas utiliser du balisage HTML, qui a une signification sémantique, pour faire de la mise en forme, qui relève du CSS.
La manipulation de bordures est évidement la première solution à laquelle j'ai pensé, mais le problème, c'est que la modification d'une bordure, par exemple la bordure gauche d'une cellule de la colonne « étiquette », s'applique au centre de cette bordure, soit moitié sur « Identité » et moitié sur « Étiquette ». Le rendu n'est donc pas très esthétique, et peu compréhensible.
Dans le but d'avoir une solution supportées par le plus de navigateurs possibles, pas uniquement les plus récents, j'ai fait quelques tests avec la propriété CSS box-shadow: combinée à un padding-left:. Voici le rendu :
Cette méthode est parfaitement accessible, reposant uniquement sur le CSS.
L'utilisation de box-shadow: est préférable à linear-gradient(), car mieux supportées par les navigateurs.
Elle est supportée par tous les navigateurs supportant CSS3, soit en gros, tous les navigateurs de moins de 10-12 ans. En pratique, seul Internet Explorer 8 n'est pas compatible (Internet Explorer 6 et Internet Explorer 7 ne peuvent plus consulter les wikis Wikimedia, car non compatibles TLS 1.2, plus de détails sur cette discussion).
Le non support par Internet Explorer 8 et des autres vieux navigateurs n'est pas bloquant dans le cas présent, ces navigateurs n'étant quasiment plus utilisés, et s'agissant d'une information additionnelle. Il n'y a pas de perte d'information réelle en l'absence d'indication de la couleur.
Pour la couleur, elle devrait être gérée soit par un sous-modèle dédié, soit en réutilisant un sous-modèle existant, comme {{Infobox Parti politique français/couleurs}} ou {{Élu2/Couleur}}.
Si vous avez des questions, n'hésitez pas !
--Tractopelle-jaune (discuter) 2 juillet 2020 à 20:43 (CEST)
- Honnêtement ça rend plutôt bien! Et correspondrait en plus aux standards d'accessibilité et de compatibilité. Ça me paraît également plus esthétique qu'un dégradé.
- Mieux vaudrait faire gérer la couleur par {{Infobox Parti politique français/couleurs}} qui est plus simple d'utilisation et (beaucoup) plus complet. Élu2 ne s'applique qu'aux élections départementales.
- J'attends encore une réponse de Projet:Politique et Projet:Communes de France mais j'ai l'impression que les communautés sont assez inactives sur leurs pages de discussion... Néanmoins un tel ajout me paraît relever du bon sens et ne devrait pas rencontrer d'opposition.
- J'en profite pour rappeler que ça serait le moment parfait pour effectuer ce genre de modification, dans la mesure où les nouveaux conseils municipaux seront installés dans les jours qui viennent et avec eux viendront tout un tas de mises à jour des articles Wikipédia correspondants.
- --Julmath (discuter) 2 juillet 2020 à 22:43 (CEST)
- Bonjour. Pas le courage de relire toute la discussion, mais concernant le rendu de la couleur c'est très bien selon moi. Si c'est accessible, c'est excellent ! Est-ce qu'il est aussi prévu qu'il soit utilisé dans les autres tableaux de ce type ? Dans ce cas, est-ce qu'il possible que le code soit plus simple ? Sinon ça va être difficile à imposer comme mode d'affichage.
- Je vais déposer un message au Projet:Politique française, p-e plus actif.
- — tyseria, le 3 juillet 2020 à 16:31 (CEST)
- Tyseria : Pour le code, je comprend pas trop ce que tu veux dire par « plus simple ». Il n'y a que deux propriétés CSS utilisées :
style="box-shadow:12px 0 gold inset; padding-left:20px;". - Et le tout est destiné à être géré à l'interne par le modèle. Les contributeurs ne doivent bien entendu pas à avoir manipuler ces propriétés CSS. Il y a deux possibilités :
- Ajouter un nouveau paramètre à {{Élu}} pour passer un code compatible avec {{Infobox Parti politique français/couleurs}}. Mais cela complexifie le wikicode dans les articles en ayant à saisir deux fois les partis (une fois le nom au long/code à afficher, et une fois un code autorisé).
- Compléter la table de correspondance de {{Infobox Parti politique français/couleurs}} pour gérer également les noms au long courants, avec ou sans lien interne. Et créer un paramètre (par ex.
Couleur) optionnel pour les cas inhabituels/non répertoriés, ou pour les nécessités occasionnelles de forcer un code. Deux sous-possibilités :- a. La bande de couleur est activée par défaut (si le code/parti est valide, bien entendu), et il faut utiliser
Couleur=nonpour la désactiver. Peut poser problème quand ce modèle est utilisé dans des articles concernant d'autres pays que la France. - b. La bande de couleur est désactivée par défaut, il faut utiliser le paramètre
Couleur=ouiouCouleur=CODEpour l'activer.Couleur=ouise baserait sur les couleurs de {{Infobox Parti politique français/couleurs}}. On peut aussi imaginer des paramètres pays-spécifiques.
- a. La bande de couleur est activée par défaut (si le code/parti est valide, bien entendu), et il faut utiliser
- Je précise que je ne contribue pas au domaine de la politique, ce ne sont que quelques propositions d'un point de vue technique. D'autres possibilités existent.
- --Tractopelle-jaune (discuter) 3 juillet 2020 à 18:36 (CEST)
- Bonjour. Je confirme ces propositions qui correspondent à celles envisagées supra.
- À mon avis, si c'est une solution du type #2b qui est plébiscitée, puisqu'il faudrait spécifier un paramètre dans tous les articles concernés, autant choisir la #1 avec un paramètre couleur à introduire correspondant à l'un des codes définis dans la documentation du Modèle:Infobox Parti politique français/couleurs et éventuellement un code pour les cas indéfinisRemarque.. Cela éviterait d'avoir des paramètres inopérants
couleur=ouidans des modèles dont le parti spécifié n'est pas connu du sous-modèle …/couleurs. - Il y a aussi une possibilité :
- La bande de couleur est activée par défaut si le parti en version longue est connu par le sous-modèle ; désactivable par un paramètre
Couleur=nonet activable si besoin par unCouleur=CODEvalide – ce dernier ayant la priorité sur le fonctionnement par défaut –. En relisant, c'est la #2a me semble-t-il.
- La bande de couleur est activée par défaut si le parti en version longue est connu par le sous-modèle ; désactivable par un paramètre
- Remarque : Même si cela n'est pas très important et dépend de l'option choisie, il faut penser à la gestion des alignements du texte de la colonne dans les cas où l'intégralité ou seulement une partie des lignes du tableau ne contient pas de couleur précisée.
- — Ideawipik (discuter) 3 juillet 2020 à 20:03 (CEST)
Nouveau modèle Biographie
J'ai créé {{Biographie}} qui permet d'afficher directement la date de décès et de naissance pour une personnalité (exemple Modèle:Biographie ou Modèle:Biographie). N'hésitez pas à me dire ce que vous en pensez et surtout si vous trouver ça utile ou non. --PAC2 (discuter) 9 juillet 2020 à 22:25 (CEST)
- Bonjour PAC2. Quelle est la destination de ces modèles ? Voici des remarques, qui se révèlent au final légèrement orientées, mais qui initialement relèvent de réelles limitations techniques objectives plutôt problématiques.
- Avantages.
- On n'a pas besoin d'entrer les dates. Cela dit, ces dates ne changent pas tous les quatre matins.
- Dans l'utilisation avec le paramètre
Q, si l'article n'existe pas en français mais existe en anglais, on a le lien vers l'article wiki anglophone ; s'il n'existe pas non plus en anglais, lien vers la page Wikidata. Alternative : il existe le modèle {{Lien}}.
- Critiques et limites du fonctionnement actuel. Potentiellement corrigeable, (pas certain ou à quel prix ?)
- La présence des liens internes pour les années de naissance et de mort me semble superflue (point de vue personnel).
- Si on utilise le modèle pour un article dont les données Wikidata ne sont pas renseignées, on obtient un lien interne suivi de « (-) »
- Le modèle en l'état ne fonctionne pas de façon optimale pour les pages intitulées « Prénom Nom (précision) » ou si on souhaite un libellé de lien différent du nom entier de l'article. Par exemple pour une mise en forme particulière (exposant…).
- Si on utilise le modèle pour un
articleexistant mais qui n'a pas d'élément Wikidata associé, alors apparaît un gros message d'erreur. - Si on utilise le modèle pour un
articleétant une redirection, il y a un message d'erreur, potentiellement pour la même raison que le point précédent. Donc un renommage anodin d'article altère l'affichage dans toutes les pages contenant un lien vers cet article via ce modèle. La correction immédiate de la redirection dans toutes les pages concernées serait nécessaire. - Dans le même genre, avec
Q=si un modèle était lié à un élément Wikidata fonctionnel récent ayant un article sur frwiki. S'il s'avère plus tard que cet élément était un doublon sur Wikidata, la fusion dans Wikidata au sein de l'élément le plus ancien entraînera une perte de la détermination du nom de l'article sur frwiki et donc la disparition du lien interne au profit du lien wikidata. Voir la différence : via la redirection WD Q3175768 : « Modèle:Biographie » ; avec l'élément WD cible Q1698791 : « Modèle:Biographie » comme cela serait apparu avec la première syntaxe avant l'action de fusion externe à Wikipédia.
- Inconvénients :
- Une façon de plus d'introduire un lien interne somme toute assez simple pour un apport mineur. Pensons aux nouveaux, pour leur permettre d'assimiler la syntaxe classique des liens internes.
- L'ajout d'un modèle va encore compliquer les tâches des contributeurs et des bots qui corrigent/détectent les liens vers les pages d'homonymie et les confusions ou qui remplacent des liens internes suite à des renommages pour homonymie, surtout dans la formulation avec le paramètre
Q. Ou bien ces liens ne seront pas maintenus.
- Avantages.
- Les questions de maintenance et surtout les deux ou trois derniers points critiques, font pour moi pencher la balance (bénéfice)/(complexité, risque). Pour comparaison, introduire des données Wikidata dans un article directement lié à un élément Wikidata propre, comme c'est le cas dans certaines infobox, est bien moins risqué que la proposition faite ici, les renommages ou fusions étant alors directement répercutés d'un wiki à l'autre de façon automatisée presque imperceptible pour l'utilisateur et sans conséquence sur l'affichage des infobox. — Ideawipik (discuter) 10 juillet 2020 à 09:31 (CEST)
- La critique 6 ressemble à un bug, ça n’a pas l’air normal de pouvoir accéder à la date de naissance sur WD si l’élément est une redirection sur WD mais pas aux articles liés à la redirection. — TomT0m [bla] 11 juillet 2020 à 17:07 (CEST)
Merci pour ce retour détaillé. Je suis d'accord avec la limite no 1 et évidemment conscient des limites actuelles (problèmes de redirection, renommage, etc.)
Effectivement la balance bénéfices inconvénients se discute. Je me donne quelques jours pour y réfléchir
PAC2 (discuter) 12 juillet 2020 à 08:55 (CEST)
Couleur de fond par défaut des modèles
Bonjour ! Les thèmes sombres sont appréciés par certains utilisateurs pour le confort oculaire qu'ils procurent. Wikipedia n'en propose pas, mais on trouve des CSS personnalisé assez satisfaisants. Avec un thème sombre, le texte a en général une couleur proche du blanc, et il est difficile de s'en éloigner significativement. Le souci est qu'actuellement, de nombreux modèles (en-têtes, infobox, ...) ont un fond blanc et que le texte devient ainsi illisible : si l'on veut les rendre lisibles, on se retrouve à ajouter à son CSS une ligne pour chaque modèle à adapter. J'ai même l'impression que pour certains modèles (comme Modèle:Boîte colorée), ce n'est pas modifiable par CSS.
Comme il me semble que les thèmes sombres ont une certaine popularité, je me demandais :
- Si, lorsque la couleur de fond d'un modèle est le blanc, on pourrait le remplacer par du transparent ;
- De même si, lorsque cette couleur de fond est paramétrable, la couleur par défaut pourrait être le transparent au lieu du blanc ;
- Si cette modification est d'une complexité technique raisonnable (si ça implique d'ajouter 10 lignes de code par modèle, le jeu n'en vaut peut-être pas la chandelle) ;
- Si vous pensez que la tolérance aux thèmes sombres, et plus généralement aux thèmes utilisateurs, justifient de telles modifications des modèles.
Je suis informaticien, mais je n'ai qu'une connaissance superficielle du CSS. Si ces questions reçoivent une réponse positive, je serais potentiellement volontaire pour modifier les principaux modèles de la manière prescrite. Cordialement, Vincent P. (discuter) 11 juillet 2020 à 01:14 (CEST)
Bonjour. J'ai posté cette requête sur Discussion Projet:Scribunto#Module:Biblio/Références il y a deux semaines, mais pas de réponse. Donc je poste ici en espérant avoir plus de chance.
Sur le bistro du 29 juin j'ai fait une suggestion qui n'a pas reçu énormément de réponse, mais globalement des réponses positives. Il s'agit de modifier l'affichage des numéros de notice BNF, pour harmoniser avec tous les autres numéros (ISBN, OCLC, etc.) :
| Avant | Après |
|---|---|
| (BNF 34063996) | (BNF 34063996) |
Je sais que ça se passe sur Module:Biblio/Références mais je n'ai ni les droits d'administrateurs pour intervenir sur cette page protégée, ni les compétences suffisantes pour dire exactement comment modifier pour obtenir l'effet voulu. Enfin je pense que ça consiste grosso modo en ça, mais je ne suis pas certain :
function References.bnf( bnf )
bnf = Outils.trim( bnf )
if bnf then
local texte = ''
local category = ''
local bnfId = bnf:upper():match( 'BNF(%d+%w)' ) or
bnf:lower():match( 'cb(%d+%w)' ) or
bnf:match( '^%d+%w' )
if bnfId then
-- bnf contient une suite de chiffres qui peut être un ark valide
local base = bnfId:sub( 1, 8 )
local arkId = References.arkId( 'cb' .. base )
if bnfId:len() == 8 then
-- il manque la clé, on l'ajoute
bnf = base .. arkId
texte = base
elseif bnfId:len() > 8 and bnfId:sub( 9, 9 ) == arkId then
-- ark valide
bnf = bnfId:sub( 1, 9 )
texte = base
else
-- ark qui semble non valide
bnf = bnfId
texte = bnfId
category = '[[Catégorie:Recension temporaire pour le modèle Ouvrage|bnf]]'
end
else
-- le paramètre ne semble pas un ark valide
texte = bnf
category = '[[Catégorie:Recension temporaire pour le modèle Ouvrage|bnf]]'
end
-- dans tous les cas on renvoie l'adresse, on catégorise juste pour vérifier ce qui ne va pas
local lien = databaseExterne(
bnf,
'[[Bibliothèque nationale de France|BNF]]',
'catalogue.bnf.fr/ark:/12148/cb',
'.public',
texte
)
return lien .. category
end
end
À vrai dire je ne sais même pas comment tester... Quelqu'un ayant des droits d'admin peut-il tester et faire la modification pour moi ? Ça serait sympa. Merci . — Hr. Satz 16 juillet 2020 à 10:26 (CEST)
Création d'un nouveau modèle
Bonjour, comment s'y prendre pour demander la création d'un nouveau modèle à insérer dans C-helper? Il s'agit d'un modèle qui simplifierait pour la patrouille le passage en brouillon d'une page vraiment pas au point.
Discussions ici : Bistro du 21 août [[1]] ; patrouille [[2]] ; Bistro du 28 août [[3]].
Je n'ai aucune idée sur la démarche à suivre. Formule cordiale, --Msbbb (discuter) 28 août 2020 à 18:08 (CEST)
- {{Retour en brouillon}} créé, voir BulPat. --FDo64 (discuter) 30 août 2020 à 22:09 (CEST)
À propos de la catégorie « Modèle par langue »
Bonjour,
j'ai remarqué une nouvelle venue à la racine de la catégorie « Espace Modèle » : Catégorie:Modèle par langue, créée par Mywiz en début d'année. Outre le fait qu'il y a là une fantastique arborescence de 11 sous-catégories réparties en 3 branches, tout ça pour casser ultimement un seule et unique catégorie (Catégorie:Palette Écrivain québécois), je ne crois pas vraiment au potentiel de ce classement. De plus, le nom même de la catégorie me semble erroné : il ne s'agit pas de la langue des modèles, mais de modèles relatifs à une langue. Je propose soit de supprimer ce classement, soit éventuellement de le déplacer vers un catégorie de modèles liés à la linguistique, mais en tout cas de le sortir de la racine des catégories de modèles, où elle n'a rien à faire à mon avis.
Votre avis ?
Wikipédiennement, Epok__ (Insultes, éloges, simples discussions : ✉), le 16 juillet 2020 à 09:12 (CEST)
- Bonjour, Epok. Pour visualiser, un peu mieux.
- Catégorie Modèle par langue introuvable
- J'avoue ne pas comprendre non plus à quoi correspond vraiment cette catégorie. Modèle « par langue », mais par langue de quoi ? Il ne s'agit pas nom plus de modèles « relatifs à une langue » comme on peut en trouver dans Catégorie:Projet:Langues, mais plutôt à des modèles relatifs à un sujet ayant un rapport avec une langue. C'est un pendant à Catégorie:Modèle par pays ; vraisemblablement en ayant à l’esprit uniquement la littérature. Catégorie:Modèle littérature par pays,qui contient de façon abusive (?) Catégorie:Modèle littérature québécoise en dehors de la catégorie canadienne, et Catégorie:Palette Littérature par pays. La volonté de faire aussi une classification par langue peut se justifier compte tenu des pays partageant plusieurs langues, comme le Luxembourg, la Belgique, Suisse, Canada… et pour prendre en compte les langues "régionales". Mais à mon avis, dans le projet Wikipédia, peut-être qu'on peut se contenter d'une telle classification au sein des thématique (Littérature, Musique, Cinéma…) et uniquement si c'est pertinent. Pour une classification de modèles, je ne vois pas l'intérêt de trop catégoriser. J'imagine qu'un contributeur qui chercherait une palette aura la présence d'esprit de faire une recherche par nom ou par thématique/projet (en ajoutant par exemple
intitle:/Palette/à la recherche). - Généralement, le désir de réaliser ce type de catégories « par <une caractéristique> » (« par pays », « par sexe » pour les personnes, ou par type de modèle) entraîne une nécessité de rediviser/préciser toutes les catégories thématiques existantes concernées. Cela conduit dans certains cas à des catégories avec très peu d'éléments. Exemple : Catégorie:Justice dans l'Égypte antique. Le but initial de permettre plusieurs accès à une donnée (ce qui devrait faciliter la recherche) conduit à une architecture moins lisible de la structure de la catégorisation. Une architecture simple avec une méthode adaptée peut s'avérer plus efficace. Il est important de bien définir le contenu des catégories et les relations d'appartenance. Tout comme il ne faut pas regarder les choses sous le spectre de la langue ou du pays. Néanmoins, on peut apprécier une certaine rigueur dans la catégorisation faite par Mywiz (Bjr).
- Quant au contenu de la présente arborescence consistant en deux pages uniquement : une palette {{Palette Mel Gosselin}} et un modèle {{Palette Écrivains québécois}} mal nommé puisqu'il ne correspond pas à une palette au sens éditorial de Wikipédia mais à un outil de navigation entre des pages de listes, à l'image d'un sommaire sur plusieurs pages ou de liens présents sur des pages de Chronologies ({{Chronologie littérature}}). À la limite, serait acceptable le titre « Palette Listes d'écrivains québécois par ordre alphabétique » la précision en petit étant facultative.
- Autre point, personnellement, je sortirais Catégorie:Modèle littérature francophone de la catégorie:Littérature francophone cette dernière étant encyclopédique, la première, technique, et déjà accessible via Catégorie:Projet:Littérature francophone et via l'arborescence des modèles. Bref, pas fan de la nouvelle catégorisation. — Ideawipik (discuter) 27 juillet 2020 à 23:58 (CEST)
- Hello Ideawipik . Oui, je pense effectivement que dans certains cas, une catégorisation par langue/pays est utile (j'ai par exemple moi-même créé récemment la catégorie « Modèle transport par pays » pour y rassembler les catégories par lieu déjà présentes, totalement justifiées lorsque l'on parle des transports d'une ville ou autre). Néanmoins, c'est plutôt la présence de cette catégorie à la racine, et donc en tant que catégorie maîtresse dans laquelle on doit essayer de caser la plupart des modèles, qui me chagrine... Comme tu le dis, cela risque d'exploser toutes les catégories thématiques existantes en sous-catégories pas forcément très fournies. D'autant plus que je ne vois pas vraiment ce que veut dire "par langue", car les modèles sont censés être en français... "Relatifs à une langue" me semblerait plus correct, à condition que la catégorie soit classée dans une arborescence liée à la linguistique (comme la catégorie « Modèle par pays » est située dans la catégorie « Modèle géographie »).
- Bref, on est d'accord
- Wikipédiennement, Epok__ (Insultes, éloges, simples discussions : ✉), le 28 juillet 2020 à 10:05 (CEST)
- En l'absence de réponse de Mywiz malgré un message sur sa pdd, je vais procéder à la suppression des catégories Modèle par langue, Palette Littérature par langue et Modèle littérature par langue. Les autres sous-catégories ne seront pas impactées.
- Wikipédiennement, Epok__ (✉), le 6 septembre 2020 à 10:49 (CEST)
- (ajout) J'ai finalement également supprimé Catégorie:Palette par langue qui se retrouvait vide après la manip. Epok__ (✉), le 6 septembre 2020 à 10:53 (CEST)
- En l'absence de réponse de
- Hello Ideawipik
Bug modèle territoires limitrophes
Bonjour. Quelqu'un peut-il regarder modèle:Communes limitrophes ? La dernière modification du modèle sous-jacent fait que la boîte n'est plus centrée par défaut depuis presque 1 mois, et ce modèle est très utilisé (voir pdd). Il faudrait affiner selon le paramètre "align". Merci d'avance, Jack ma ►discuter 18 septembre 2020 à 08:17 (CEST)
- Jack ma : de ce que je vois, la modification en question a pour effet d'ajouter une balise div dans un paramètre align. Je ne suis pas expert dans ce domaine, mais ça me semble assez suspect comme type de construction... Epok__ (✉), le 18 septembre 2020 à 08:53 (CEST)
- Bonjour. Effectivement très étrange. Je pense que l'on peut légitimement annuler cette dernière modification ou éventuellement déplacer l'ajout avant le tableau. Prométhée, quelle était ton intention ? — Ideawipik (discuter) 18 septembre 2020 à 13:06 (CEST)
- Bonjour, je viens de corriger, ne pas hésiter si d'autres bugs. Prométhée (discuter) 18 septembre 2020 à 14:17 (CEST)
- Bonjour. Effectivement très étrange. Je pense que l'on peut légitimement annuler cette dernière modification ou éventuellement déplacer l'ajout avant le tableau.
Modèle Année
Bonjour, après avoir vainement cherché, y aurait-il un wikipédien qui pourrait me dire s'il existe une recommandation pour l'utilisation du modèle année, d'avance je vous remercie. Bernard Botturi (discuter) 7 août 2020 à 10:56 (CEST)
- Bonjour Bernard Botturi. Le modèle nommé « Année » a existé sous forme de redirection jusqu'en 2015 et été supprimé pour cause de non pertinence. Il est inutilisé. Voulez-vous parler de {{date}} ? Ou de {{Palette Années}} ? Ou d'un autre modèle qu'il faudrait alors préciser, si possible avec un lien ? Ou d'un mot magique comme
{{CURRENTYEAR}}? Cordialement. — Ideawipik (discuter) 7 août 2020 à 13:23 (CEST)- Bonjour Ideawipik (discuter) , tout d'abord merci pour votre réponse, je vous sollicite car systématiquement lorsque je crée ou j'enrichis un article à chaque année je précise la nature de l'année (en littérature, en musique , aux Etats-Unis, au cinéma, etc...) exemple d'article récent que je viens de finir de réviser : Daniel Hale Williams , or un contributeur m'a dit que j'encombrais le texte qu'il fallait unique indique l'année et son type que pour des événements importants... Ce qui me laisse dubitatif qu'est ce l'importance pour une page ? une date d'obtention d'un diplôme va être importante pour la personne concernée mais aux yeux de l'histoire générale c'est peanuts. N'ayant pas d'idée arrêtée j’aimerais avoir un avis éclairé. D'avance merci Bernard Botturi (discuter) 7 août 2020 à 14:05 (CEST)
- Bernard Botturi. Même si des liens internes thématiques de ce type peuvent être introduits via des modèles comme {{date}}, {{date de naissance}} (deuxième ou quatrième paramètre selon la syntaxe choisie) ou {{date de décès}}, il ne s'agit nullement d'une question de modèles mais de liens internes et de choix éditorial. Personnellement, je ne suis pas fan de la multiplication de ces liens vers les années, mais respecte le choix des rédacteurs. Peut-être pourriez-vous vous contenter d'un lien sur la première occurrence d'une année dans l'article et plus généralement d'user de ces liens avec parcimonie. Je n'ai pas cherché dans les archives de discussions mais imagine qu'il y en a déjà eu sur le sujet. Sinon, vous pourriez solliciter des avis sur d'autres espaces de discussion communautaire. — Ideawipik (discuter) 7 août 2020 à 14:34 (CEST)
- Merci pour votre réponse, de fait, en général, je me contente d'un lien sur la première occurrence d'une année dans l'article, en l'absence de recommandation je continuerai selon mon habitude.. Dans un premier temps on m'a reproché de ne pas mettre systématiquement des liens et d'autres ensuite le reprochent... C'est comme les liens rouges, j'ai assisté à des débats hallucinants où se disait une chose et son contraire. C'est pourquoi, je préfère éviter les discussions communautaires, car selon l'heure, la saison, et autres variables telle proposition sera acceptée et à un autre moment refusée voire fustigée, elles tournent trop souvent en des débats d'opinions plus ou moins acerbes... je préfère m'adresser à des spécialistes dédiés à un projet donné... d'autant qu'il ne s'agit que d'un détail qui ne change rien à la nature des articles et quand on appuie sur le lien on s'aperçoit que les ajout du modèle année ne change strictement rien à la page de l'année. Cordialement Bernard Botturi (discuter) 7 août 2020 à 14:58 (CEST)
- Bonjour Ideawipik (discuter) , tout d'abord merci pour votre réponse, je vous sollicite car systématiquement lorsque je crée ou j'enrichis un article à chaque année je précise la nature de l'année (en littérature, en musique , aux Etats-Unis, au cinéma, etc...) exemple d'article récent que je viens de finir de réviser : Daniel Hale Williams , or un contributeur m'a dit que j'encombrais le texte qu'il fallait unique indique l'année et son type que pour des événements importants... Ce qui me laisse dubitatif qu'est ce l'importance pour une page ? une date d'obtention d'un diplôme va être importante pour la personne concernée mais aux yeux de l'histoire générale c'est peanuts. N'ayant pas d'idée arrêtée j’aimerais avoir un avis éclairé. D'avance merci Bernard Botturi (discuter) 7 août 2020 à 14:05 (CEST)
Comment corriger ça ? Modèle Coord2
Bonjour,
dans Spécial:Catégories demandées, on peut remarquer la présence de Catégorie:Coordinates on Wikidata et Catégorie:Coordinates not on Wikidata, liée à {{Coord2}} (copie d'un modèle anglophone). Je ne sais pas comment corriger ça (je ne vais pas créer de catégories sous ce titre...). Si quelqu'un à une idée. --Skouratov (discuter) 6 septembre 2020 à 12:00 (CEST)
- Bonjour Skouratov. La création du modèle {{Coord2}} a été faite assez récemment par un contributeur constatant que le modèle {{Coord}} placé dans un modèle {{Carte de localisations multiples}} conduisait à une erreur d'affichage. La solution de facilité qu'il a proposée a été de créer ce nouveau modèle en copiant un modèle de enwiki. Peut-être qu'une autre solution permettrait d'éviter la multiplication du nombre de modèles pour pas grand chose qui ne facilite pas la compréhension des contributeurs.
- Explication de l'erreur constatée.
- Le modèle Coord permet le formatage de coordonnées sous la forme sexagésimale (DMS). Il existe déjà une option
|format=decmais elle n'est pas satisfaisante ici. - Les paramètres
coordinatesdu modèle « Carte de localisations multiples » requiert des coordonnées exprimées en degrés décimaux, sour la forme 46.5°N 17.5°E (i.e. avec points pour marques les décimales (pas de virgule), pas de ponctuation entre latitude et longitude et présence de signes ° devant les NSEW).
- Le modèle Coord permet le formatage de coordonnées sous la forme sexagésimale (DMS). Il existe déjà une option
- Autres solutions envisageables sans recourir au modèle Coord2 :
- Soit ajouter un paramètre optionnel au modèle Coord pour obtenir un formatage en degrés décimaux.
- Soit permettre au modèle « Carte de localisations multiples » d'accepter aussi les coordonnées exprimées en DMS.
- Soit obliger les contributeurs à entrer en dur les coordonnées décimales sans passer par de modèle (Coord ou autres). J'avoue que cette troisième solution ne me satisfait guère.
- L'une ou (non exclusif) l'autre de ces méthodes me paraissent préférables à ce qui a été fait. Qu'en pensent les modélistes ?
- PS : La question de la catégorisation me semble anecdotique mais serait résolue en adoptant une de ces alternatives. — Ideawipik (discuter) 7 septembre 2020 à 14:18 (CEST)
- Bonsoir Ideawipik . Favorable également à la suppression de ce doublon.
- En regardant comment font les Infobox qui acceptent les deux formats, je me dis qu'une solution serait peut-être d'utiliser le module:Coordinates. Voir par exemple {{Infobox/Ligne mixte latitude longitude optionnelle}} et {{Infobox/Géolocalisation multiple}}. Cela dit, je n'ai pas approfondi la question donc ma suggestion n'est peut-être pas pertinente…
- --FDo64 (discuter) 7 septembre 2020 à 22:55 (CEST)
- Bonsoir Ideawipik
Comment ne pas se perdre dans les modèles de formatage des dates de naissances et décès ?
Bonjour. Je découvre les modèles {{Naissance décès âge}} et {{Naissance&décès âge}} (le second offrant la possibilité d'afficher les lieux de naissance/décès)
Il existe aussi les modèles
- {{Année de naissance et âge}}, {{Année de décès et âge}}
- et {{Date de naissance}}, {{Date de décès}} (et idem avec des signes moins) qui permettent l'affichage de l'âge courant ou celui au moment du décès (respectivement activable et désactivable via le paramètre
âge)
Ne faudrait-il pas favoriser l'usage de ces derniers plutôt que « Naissance décès âge » en l'indiquant dans leur documentation… quitte à modifier légèrement le comportement des modèles Date de naissance/décès pour les cas de calculs indécis. — Ideawipik (discuter) 7 septembre 2020 à 14:18 (CEST)
- Salut Ideawipik je suis sur le dossier depuis quelques temps aussi (cf ceci), et je plussoie ta remarque. J'avais également pour intention de proposer ce genre de chose au projet, donc j'en profite :
- Même remarque pour {{Birth date and age}}, qui bien que remplaçable par AWB contient un certain nombre d'appels, notamment des appels erronés au vu de [4].
- Il me semble qu'il faudrait également fusionner les modèles {{Nbjours}} et {{Age en jours}} avec {{Durée en jours}}, en faisant remplacer par un bot les appels aux deux premiers par des appels au dernier. Ils me semblent totalement compatible, à la différence que les 2 premiers utilisent des formats américains, tandis que le dernier utilise le format francophone (ou français) le plus répandu pour les dates sur WP:FR.
- Je renommerais bien {{Âge en années}} pour {{Durée en années}}, comme j'ai fait pour {{Durée en jours}} et {{Durée en mois}}, mais je voulais d'abord l'avis du projet car celui-ci semble légèrement plus utilisé que les deux autres, donc je n'ai pas pu vérifier qu'il s'agissait bel et bien de l'usage majoritaire du modèle (les deux autres étaient évidents, aucun âge n'étant présenté en jours ou en mois dans l'encyclopédie, il s'agit uniquement de durées).
- Wikipédiennement, Epok__ (✉), le 7 septembre 2020 à 18:55 (CEST)
- Ideawipik et Epok : Toujours favorable à ce genre d'initiative. Et comme ça fait longtemps que je n'ai pas remplacé {{Birth date and age}} laissé par des traducteurs, qu'il y a peu de cas dans l'espace principal et que j'ai déjà les regex pour le remplacer, je vais m'en charger.
- --FDo64 (discuter) 7 septembre 2020 à 22:59 (CEST)
- Ideawipik : pour en revenir à ta question initiale, je constate qu'un grand nombre d'appels de {{Naissance décès âge}} remplissent la totalité des paramètres. Dans ces conditions, le comportement est le même que celui des modèles "habituels". Je propose d'agir en 2 temps : d'abord, faire passer un bot pour remplacer les appels de ce modèle avec les règles suivantes :
- Si le premier paramètre est vide (cas décès), et que la totalité des autres paramètres est remplie, remplacer par {{Date de décès}} avec les paramètres dans l'ordre suivant : 5, 6, 7, 2, 3, 4 (l'ordre naissance-décès est inversé dans les 2 modèles).
- Si le premier paramètre contient la valeur N (cas naissance), il me semble que seuls les paramètres 2, 3 et 4 sont pertinents (je ne vois pas l'intérêt de fournir les dates de décès dans un modèle naissance). Alors si ces trois paramètres sont remplis, remplacer par le modèle {{Date de naissance}} en conservant les paramètre 2, 3 et 4 en position respective 1, 2 et 3, et ajouter le paramètre âge=oui.
- Ensuite, au prochain dump, on pourra surveiller la liste des appels du modèle pour voir si il reste vraiment un nombre significatif de cas, et aviser.
- En ce qui concerne le modèle {{Naissance&décès âge}}, il me semble que les appels pourraient aussi être remplacés par un bot pour extraire le lieu de naissance et le placer dans une phrase : ce modèle n'a que 913 appels, ce qui me semble dérisoire par rapport au nombre d'articles utilisant un modèle "standard" avec une précision sur le lieu dans une phrase. Toutefois, ce modèle à un comportement différent des autres en ce sens qu'il rassemble les 2 infos (naissance et décès) en un seul appel, là où les autres ne traitent qu'un seule des deux infos à chaque appel. Donc il faut peut-être réfléchir un peu plus pour voir ce qu'il convient d'en faire.
- Pour info, j'ai traité tous les paramètres erronés sur les 2 susdits modèles, afin d'éviter tout problème si on fait passer un bot.
- Epok__ (✉), le 11 septembre 2020 à 09:19 (CEST)
- Bonjour Epok et merci pour les corrections. On a raison, en concentrant initialement la conversion sur les cas où :
- soit le premier paramètre est vide et les sept paramètres sont remplis – au moins les années (4 et 7) non vides ;
- soit le premier paramètre est un N et les trois paramètres suivants (2,3 et 4) sont non vides. Il faut juste espérer que le rédacteur n'ait pas inversé l'ordre des paramètres (date de naissance et date de décès) Si un paramètre 7 est non vide et valide, le bot pourrait vérifier que valeur7>valeur4.
- Parce que les cas comme
{{Naissance décès âge||22|05|2000|4||}}→ ou{{Naissance décès âge||22|05|2000|4|9|}}→ , s'il y en a, sont rares et très vraisemblablement manquent d'une information. - Note pour le dresseur du bot : le modèle accepte pour valeur valide pour les mois les numéro (4, 04), les noms (avec ou sans capitale initiale) en anglais (April) et en français (avril) et les abréviations en français uniquement (avr.). Pour les jours, il accepte 1, 1er et même {{1er}} qu'il faudrait simplifier le cas échéant. En pratique, il n'y a pas d'occurrence de la dernière forme.
- Je peux me charger du bot.
Étant donné que tous les articles (850) portant un modèle « Naissance&décès âge » ont aussi un modèle « Naissance décès âge » (Petscan:17333416), il conviendrait d'élaborer un petit algo de remplacement du modèle& et de traiter les deux modèles en même temps. — Ideawipik (discuter) 11 septembre 2020 à 16:54 (CEST) Edit: J'ai dit une bêtise. Le résultat de la recherche s'explique parce que le modèle "&" fait appel dans son code au modèle "sans &". Mais la bonne pratique demeure identique.- Ideawipik : Effectivement, si il y a un tel entrelacement dans l'utilisation des modèles, il faut traiter les 2 de front.
- En étudiant le rendu du modèle "&" (que ne je trouve pas satisfaisant dans un article, mais bon...), je te propose l'algo suivant, le terme "fourni" voulant dire "présent et contient une valeur" :
- Si les paramètres 1 à 6 sont tous fournis (cas équivalent à la discussion ci-dessus sur l'autre modèle), alors
- Si le paramètre lieunaissance est fourni, écrire
valeurLieuNaissance,(espace) - écrire
{{Date de naissance|1|2|3}}(espace)–(espace) - si le paramètre lieudeces est fourni, écrire
valeurLieuDeces,(espace) - écrire
{{Date de décès|4|5|6|1|2|3|âge=oui}}
- Si le paramètre lieunaissance est fourni, écrire
- Si les paramètres 1 à 6 sont tous fournis (cas équivalent à la discussion ci-dessus sur l'autre modèle), alors
- Ça me semble correspondre au rendu du modèle, du moins dans les cas évidents. Pour les autres encore une fois, il faudra faire du cas par cas, ou modifier les modèles de remplacement pour gérer ces cas avec une date floue. Mais je pense qu'on n'aura pas tant de cas que ça au final, donc cela vaut-il vraiment la peine d'avoir un modèle qui fait le job là où on peut utiliser du texte manuel pour quelques exceptions ?
- Pour les cas où on aurait dans la page plusieurs modèles dont au moins un qui ne permet pas un remplacement automatique, je propose également que l'on ne touche pas à la page pour l'instant.
- Epok__ (✉), le 11 septembre 2020 à 17:26 (CEST)
- Epok. J'ai repris ma constatation biaisée ci-dessus. J'approuve la dernière remarque, identique à ce que j'envisageais pour ne pas surcharger inutilement les historiques. Je regarde assez vite mais les effets ne seront peut-être pas visibles avant le dump du . Je te tiendrais au courant. — Ideawipik (discuter) 11 septembre 2020 à 17:55 (CEST)
- Ideawipik : Super, et pas de soucis, j'ai l'habitude d'attendre les dump ^^.
- Si tu es également d'accord avec mes remarques concernant les autres modèles, je pourrai te solliciter pour remplacer {{Nbjours}} et {{Age en jours}} ? Sachant que là, c'est un poil plus compliqué car il faut découper des paramètres selon un pattern pour obtenir les nouveaux...
- Epok__ (✉), le 11 septembre 2020 à 18:09 (CEST)
- Epok. Vas-y ! Balance les règles du jeu ! Je préfère regrouper les modifications dans les articles et donc le codage. Vu les paramètres autorisés pour ces deux autres modèles, il ne doit pas être trop sorcier de faire ces découpages. Mais il est toujours utile de regarder les contenus valides dans le code du modèle et surtout ceux réellement présents dans les articles. Un coup d’œil à wstat.fr donne les tendances et exceptions qui ne respectent pas les recommandations de la documentation. — Ideawipik (discuter) 11 septembre 2020 à 19:00 (CEST)
- Ideawipik : Il s'agirait de remplacer les modèles {{Nbjours}} et {{Age en jours}} par le modèle {{Durée en jours}}. Les "règles du jeu" seraient les suivantes :
- Pour le modèle {{Nbjours}}, on a 2 paramètres 1 et 2, formatés chacun DD-MM-YYYY. On va dire D1-M1-Y1 pour le premier paramètre et D2-M2-Y2 pour le 2e. Il faudrait donc remplacer {{nbjours|1|2}} par {{Durée en jours|D1|M1|Y1|D2|M2|Y2}}. Si seul le paramètre 1 est renseigné, il suffit d’omettre les paramètres *2 ({{Durée en jours|D1|M1|Y1}}). Si Seul le 2e paramètre est renseigné (à priori pas de cas, mais il peut exister), laisser tel quel.
- En ce qui concerne le modèle {{Age en jours}}, c'est plus simple, il faut remplacer {{Age en jours|1|2|3|4|5|6}} par {{Durée en jours|3|2|1|6|5|4}}. Si seuls 3 paramètres sont renseignés, il faut alors remplacer {{Age en jours|1|2|3}} par {{Durée en jours|3|2|1}}. À noter toutefois que les paramètres 1, 2, 3 et 4, 5, 6 de ce modèle ont pour homonymes respectifs year1, month1, day1 et year2, month2, day2.
- Il me semble que tous les cas sont traités comme ceci, mais dans le doute (un modèle ne correspondant pas aux patterns ci-dessus), laisser tel quel.
- Epok__ (✉), le 11 septembre 2020 à 22:16 (CEST)
Woups, je viens de me rendre compte qu'il y avait 2 cas pour le modèle {{Nbjours}}... La date peut être formatée soit DD-MM-YYYY, soit YYYY-MM-DD... Donc il faut également prendre en compte la longueur de chaque membre de l'expression pour déterminer si on est dans le premier ou le second cas 
... ça commence à devenir compliqué ! Epok__ (✉), le 11 septembre 2020 à 22:42 (CEST)
- Re-bonjour Epok. Cela reste très acceptable. Il "suffit" que le bot fasse comme le modèle/module pour accéder aux différents paramètres. Une recherche d'expression régulière sur chaque contenu de paramètre pour voir s'il correspond à une syntaxe valide. Tu remarqueras que la syntaxe
{{Nbjours|1/24/2000|2 May 2001}}est aussi valide. Dans ce cas, on à MM/JJ/AAAA ou une date en anglais. En revanche une date en français n'est pas valide. Mais il suffirait de prendre les syntaxes réellement vues sur un dump pour traiter presque tous les cas. - Pour rebondir sur les paramètres/alias. Le seules choses que j'ai besoin de savoir sont l'ordre de priorité entre les noms de paramètres (nommés ou numéroté) et le type de sélection « premier présent (même vide) » ou « premier non vide ». Merci d'avoir bien dégrossi le travail. — Ideawipik (discuter) 11 septembre 2020 à 23:42 (CEST)
- Ideawipik : Sur {{Nbjours}}, à l'heure actuelle on a uniquement les 2 syntaxes que j'ai mentionné, aucune trace des autres possibilités à priori.
- En ce qui concerne l'ordre de priorité des paramètres pour {{Age en jours}}, la sélection des paramètres se fait sur le premier présent, même vide. La priorité est à la version nommée du paramètre, et en son absence on regarde la version numérotée. Toutefois, je ne vois pas de mélange de types de paramètres dans les appels, donc ça ne devrait pas poser problème.
- Merci pour ton boulot futur !
- Wikipédiennement, Epok__ (✉), le 12 septembre 2020 à 10:29 (CEST)
- Re-bonjour
- Bonjour Epok et merci pour les corrections. On a raison, en concentrant initialement la conversion sur les cas où :
Légifrance
Bonjour,
Le nouveau site de Légifrance a été déployé hier. Y'aura sans doute du boulot à faire sur {{Légifrance}}. J'ai commencé le recensement des cas où liens fonctionnent ou fonctionnent pas sur Discussion modèle:Légifrance#Nouveau Légifrance : liens à tester. Pyb (discuter) 13 septembre 2020 à 11:23 (CEST)
Un nouveau modèle pour la mise en colonnes
Bonjour Simon Villeneuve. Il existe déjà plusieurs modèles permettant une mise en colonnes, notamment {{Colonnes}}, recommandé, qui est assez simple d'utilisation et répond à des critères d'accessibilité. Il existe aussi {{Col-début}}, {{Col-fin}} et modèles associés qui génèrent un tableau et semblent satisfaire à des besoins particuliers. Est-il indispensable de créer un nouveau modèle Modèle:Columns, basé sur un tableau ? Merci aux modélistes de donner leur avis et d'évaluer la pertinence de cet ajout quant au code HTML/CSS de ce modèle importé depuis enwiki. Peut-être pour améliorer l'existant… — Ideawipik (discuter) 16 septembre 2020 à 11:57 (CEST)
- Je partage la remarque d'Ideawipik, et j'ajouterai que ce modèle dispose d'un nombre conséquent de paramètres différents et pas la moindre documentation, ce qui le rend tout bonnement inutilisable en l'état, sauf à étudier en détail son code avant utilisation, ce qui n'est pas à la portée de tout wikipédien.
- En général, si besoin d'un tableau avec une mise en forme particulière, l'usage à l'heure actuelle est soit de créer le tableau sur mesure directement dans l'article, soit de créer un modèle dédié à cet usage spécifique si celui-ci est destiné à être utilisé sur plusieurs articles (cf. les sous-catégories de la catégorie « Modèle tableau »).
- Par ailleurs, l'usage qui en est fait actuellement semble tout à fait à la portée du modèle {{Colonnes}}, donc a-t-on réellement besoin d'une telle usine à gaz si c'est pour l'utiliser à 1% de ses capacités ?
- Enfin, si un tel modèle est vraiment nécessaire, il vaudrait mieux créer un modèle en français (nom du modèle et des paramètres) plutôt que de copier-coller un modèle anglais tel quel sans traduction.
- Epok__ (✉), le 19 septembre 2020 à 08:18 (CEST)
Rendre sécable le modèle Liste horizontale
Bonsoir, je relance la discussion qui a eu lieu en mai dernier et qui a été archivée. Cela fait suite à une annulation hier de la mise en place du modèle {{Liste horizontale}} que j'ai effectuée dans une palette, à la place du modèle {{Liste éléments}} (obsolète car non accessible).
Je notifie Tractopelle-jaune qui avait fait une proposition, mais qui n'est plus présent en ce moment, et Od1n qui pourrait peut-être reprendre ces travaux s'il trouve le temps et la motivation.
Le problème de sécabilité de {{Liste horizontale}} est régulièrement remonté et il faudrait le régler afin de pouvoir s'attaquer au 32 218 pages qui utilisent encore {{Liste éléments}}.
Je reste bien entendu disponible pour toute aide (même si je n'y connais rien en CSS).
--FDo64 (discuter) 20 octobre 2020 à 23:12 (CEST)
Deux nouveaux paramètres pour l'Infobox Communes de France
Bonjour à tous et particulièrement à @FDo64, @Orlodrim et @Zebulon84. Je butte sur une question élémentaire d’ajout de paramètres à l'Infobox Commune de France. Je ne dois pas avoir les idées claires et préfère donc faire appel à un ou des connaisseurs des Infobox.
Le question qui se pose est explicitée ici. Pour faire simple, depuis des années il y a, dans l’Infobox Commune de France, confusion entre unité urbaine et aire urbaine. Cela n’a jamais été corrigé, mais maintenant le problème est dépassé puisqu’à l’occasion de la révision des différents zonages effectuée tous les 10 ans par l'Insee (et qui vient d’être publiée il y a quelques jours), la notion d’aire urbaine a disparu pour être remplacée par celle d’« aire d’attraction des villes » (AAV) (l’article n’existe pas encore dans WP puisque cela vient d’être publié). Toutes les Infobox, mais aussi tous les articles vont devoir être corrigés (tout au moins ceux qui abordaient cet aspect !)
Ainsi il y aurait lieu de créer deux indicateurs (la proposition initiale est de @Herminien2) :
- « Unité urbaine », qui pourrait prendre comme valeur banlieue / ville-centre / ville isolée / commune rurale
- « Aire d’attraction des villes », avec comme valeur le nom de l’AAV concernée ou « hors AAV »
Il ne s’agit pas de zonages d’administration, mais de zonages d’étude, cela devrait donc être positionné dans la section « géographie » de l'Infobox (et non administration). On pourrait donc utiliser les paramètres de m:Infobox Subdivision administrative:
- nom divers géo = Unité urbaine
- divers géo =
- nom divers géo2 = Aire d'attraction des villes
- divers géo2 =
Dans l'Infobox communes de France, pour que ce soit explicite pour les contributeurs , on devrait avoir comme paramètre à renseigner : unité urbaine et Aire d'attraction des villes (ou AAV si on veut faire plus court), qu'il convient donc de relier à divers géo et divers géo2.
Il y aura lieu également de supprimer la notion de population d'aire urbaine, mais c'est une autre question. Dans l'immédiat, le plus important est ces deux paramètres nouveaux.
Quelqu'un se sent-il pour cette modification ?
Merci par avance.
Cordialement. Roland45 (discuter) 31 octobre 2020 à 17:45 (CET)
- J'ai transféré la demande sur Projet:Modèle/Demandes.Roland45 (discuter) 31 octobre 2020 à 19:11 (CET)
Références
Palette Impact anthropique sur l'environnement
Bonjour,
Je suis en train de créer {{Palette Impact anthropique sur l'environnement}} sur le modèle de {{Palette Canard}}.
J'ai quelques problèmes de rendus, si quelqu'un peut y jeter un oeil, ce serait grandement apprécié , merci ! --LD • m'écrire • 5 décembre 2020 à 19:22 (CET)
Précisions:
| Général | Liste | |
| Causes - Origines | (Sous-groupes:) Agriculture Industrie énergie Biodiversité Industrialisation Vie marine et aquatique Comportements sociaux |
Liste par sous-groupe |
| Conséquences - Effets | (Sous-groupes:) Biodiversité Réchauffement climatique ecosystèmes |
Liste par sous-groupe |
| Atténuations - Mitigations - Compensations « Éviter, réduire, compenser » |
Liste |
Chaque sous-groupe une ligne avec sa liste comme la palette Canard ^^ --LD • m'écrire • 5 décembre 2020 à 19:36 (CET)
- LD. Bonjour. Quelle impatience ! Il s'agissait d'une ou deux paires d'accolades (ou crochets) mal placées. — Ideawipik (discuter) 5 décembre 2020 à 20:23 (CET)
- (conflit d'édition) Salut, je n’étais pas vraiment impatient, je voulais vraiment comprendre le problème ^^ merci beaucoup ! --LD • m'écrire • 5 décembre 2020 à 20:24 (CET)
À propos de modèle:doublage
Bonjour,
Petite question à propos de Modèle:Doublage est-il possible de mettre deux champs VF= (ou VO= ou VQ=)? Il arrive parfois, surtout dans le cas des longues séries, qu'une compagnie de doublage change de doubleur au fil du temps. Rien dans la documentation n'indique si c'est possible. L'auteur du modèle étant inactif depuis près de 3 ans et le bistro étant plutôt muet sur le sujet, je m'adresse ici.
--Myloufa Discuter ou faire Appel? 22 octobre 2020 à 17:10 (CEST)
- Bonjour Myloufa. Le modèle actuel ne le permet pas. Les cas concernés relèvent-ils de l'exception ? Si oui, pour de telles éventualités, il est possible de procéder comme dans cet exemple de section, en utilisant des balises
<small>et au besoin les modèles {{VO}}, {{VQ}}, {{VF}} ou {{VFB}}. On peut aussi envisager une modification technique du modèle pour permettre la prise en compte de plusieurs noms. Mais, avec des paramètres numérotés, il risque d'y avoir régulièrement des enchérissements dans les demandes (deux noms possibles puis trois, etc. ; et cela pour chaque type de paramètres). Sauf si on définit un fonctionnement alternatif (soit des nouveaux paramètres dans le même modèle avec une priorité à définir, soit un modèle distinct) avec une syntaxe du type{{Doublage2|VOtexte=…|VFtexte=…|VQtexte=…}}(et éventuellement|b=ou|VFBtexte=) dans laquelle les valeurs des paramètres seraient du texte wikifié à sa guise par le rédacteur. Dans l'attente de ta réponse et d'autres avis. — Ideawipik (discuter) 26 octobre 2020 à 23:38 (CET)- Bonjour Ideawipik :
- Merci pour la réponse! Il est vrai qu'il n'en a pas beaucoup. Souvent il s'agit d'un changement de doubleur après 10-15 saisons d'une série, et il est rare que cela arrive plus d'une pour un personnage (je ne l'ai jamais vu). L'option du fonctionnement alternatif pourrait être une bonne idée, cela permettrait d'avoir une liste plus uniforme dans la présentation que l'usage simple de la balise « small ».
- --Myloufa Discuter ou faire Appel? 27 octobre 2020 à 13:28 (CET)
- Bonjour Myloufa. J'ai proposé un modèle {{Doublage2}}
<includeonly><small>({{#if: {{{VO_texte|}}} |{{VO}} : {{{VO_texte}}} }}<!-- -->{{#if: {{{VF_texte|}}} | {{#if: {{{VO_texte|}}} | {{espace}};{{espace}} }}{{VF}} : {{{VF_texte}}} }}<!-- -->{{#if: {{{VFB_texte|}}} | {{#if: {{{VO_texte|}}}{{{VF_texte|}}} | {{espace}};{{espace}} }}{{VFB}} : {{{VFB_texte}}} }}<!-- -->{{#if: {{{VQ_texte|}}} | {{#if: {{{VO_texte|}}}{{{VF_texte|}}}{{{VFB_texte|}}} | {{espace}};{{espace}} }}{{VQ}} : {{{VQ_texte}}} }})</small></includeonly> - Mais… Je me rends compte qu'avec le modèle {{Doublage}}, on peut déjà faire des choses équivalentes, bien que ce ne soit pas aussi simple pour le rédacteur. Ainsi
{{Doublage2|VF_texte=[[Émile Duard (acteur)|Émile Duard]]<ref>Source1.</ref> (2000-2010) puis [[Jean-Henri Chambois]]<ref>Source2.</ref> (2010-2015) |VQ_texte=Ella Padvoua<ref>Source3.</ref> depuis 2005}}- peut être obtenu avec :
{{Doublage|VF=Émile Duard |VF_lien=Émile Duard (acteur) |VF_source=Source1. |VF_rem={{espace}}(2000-2010) puis [[Jean-Henri Chambois]]<ref>Source2.</ref> (2010-2015) |VQ=Ella Padvoua |VQ_lien=non |VQ_source=Source3. |VQ_rem={{espace}}depuis 2005}}- Donc, malgré la souplesse apportée, faut-il conserver la nouvelle proposition ? Le seul autre apport est la possibilité de spécifier conjointement VF et VFB, ce qui en soi est déjà techniquement possible en plaçant {{VFB}} et du texte dans le paramètre
VF_rem. La discussion a été élargie en pdd du projet Cinéma. — Ideawipik (discuter) 31 octobre 2020 à 23:23 (CET)
- Bonjour Myloufa. J'ai proposé un modèle {{Doublage2}}
- Bonjour
Modèles à modifier
Hello et pardon si ce n'est pas au bon endroit, mais je ne sais pas trop où demander ça. Est-ce que quelqu'un sait modifier le modèles suivant pour que les liens cliquables ne fassent pas apparaître les parenthèses de résolution d'homonymie dans la graphie apparente. Il faut corriger l'homonymie Agustín Codazzi par Agustín Codazzi (municipalité) dans {{Carte/Cesar}}. Merci d'avance Nonopoly (discuter) 2 novembre 2020 à 09:20 (CET)
- par la syntaxe suivante {{G|Cesar|10.033333|-73.233333|Agustín Codazzi (municipalité){{!}}Agustín Codazzi|Ville|4|s}} -- Xfigpower (pssst) 2 novembre 2020 à 09:51 (CET)
Modèles de révisions
Bonjour les modélistes, je pense qu'il serait utile de jeter un œil aux modèles de la Catégorie:Modèle de révision.
- J'ai proposé la fusion de {{Mal dit}} et {{Style non encyclopédique}} : Wikipédia:Pages à fusionner#Modèle:Mal dit et Modèle:Style
- Je ne vois pas l'intérêt du modèle inutilisé {{Passage absurde}} qui est méprisant et doublon de {{Passage contradictoire}} et {{Pas clair}}
- Je propose aussi de fusionner {{Contrad}} avec {{Passage contradictoire}} et {{Langue compréhensible}} avec {{Incompréhensible}}, tous les deux des doublons.
- Je doute aussi de {{Critique}}, ce genre de chose se fait normalement en page de discussion et encore une fois un modèle quasi-inutilisé
- Modèle:Ortho !, me semble superflu, je pense qu'on devrait plutôt créer un bandeau de section à {{Orthographe}}
Quant à la façon de nommer ce genre de modèle, je pense que le plus simple c'est que le nom corresponde au libellé de l'avertissement du modèle. J'ai ainsi renommé {{Pertinence contestée}} (voir ici). Ce n'est pas encore le cas partout... L'un des plus parlant, c'est {{Style à revoir}} qui redirige vers le bandeau qui s'appelle pourtant autrement, {{Style non encyclopédique}}. Je serai donc pour renommer {{Style}} en « style non encyclopédique ». Dans la même lignée, {{Fix}} n'est pas un nom très clair, je proposerai un truc comme {{méta révision de passage}}. Que pensez-vous de tous ça ? (Ou en tous cas d'une de ces choses ?) -- Nemo Discuter 5 novembre 2020 à 19:43 (CET)
- notif des personnes concernées (ayant créé/modifier ces modèles en question) : @Zebulon84, @Azurfrog @Olevy @Jerome Charles Potts @Céréales Killer -- Nemo Discuter 5 novembre 2020 à 19:50 (CET)
- Je ne vois pas d'objections à supprimer les modèles créés il y a fort longtemps {{Passage absurde}} et {{Passage contradictoire}}. Je préfère nettement {{Incompréhensible}} à {{Langue compréhensible}} qui me paraît incompréhensible. Quant à Modèle:Ortho !, il faut le supprimer et celui qui voudrait l'utiliser ferait mieux de corriger l'orthographe en question. Si tout l'article doit être corrigé, un bandeau est plus utile. --Olevy (discuter) 6 novembre 2020 à 10:09 (CET)
- J'ai lancé les différentes PÀS pour les modèles précisés et ais effectué la fusion de Modèle:Mal dit. Mon deuxième paragraphe reste par contre toujours matière à débattre ! -- Nemo Discuter 18 novembre 2020 à 21:52 (CET)
- Je ne vois pas d'objections à supprimer les modèles créés il y a fort longtemps {{Passage absurde}} et {{Passage contradictoire}}. Je préfère nettement {{Incompréhensible}} à {{Langue compréhensible}} qui me paraît incompréhensible. Quant à Modèle:Ortho !, il faut le supprimer et celui qui voudrait l'utiliser ferait mieux de corriger l'orthographe en question. Si tout l'article doit être corrigé, un bandeau est plus utile. --Olevy (discuter) 6 novembre 2020 à 10:09 (CET)
Discussion transférée sur Discussion modèle:Style à revoir#Rennomage pour une meilleure conservation. -- Nemo Discuter 26 novembre 2020 à 12:24 (CET)
- Zivax : n'a pas tout compris... il vient de supprimer {{style à revoir}}... j'ai restauré. Et comme il y a pas mal de pages qui font référence à {{style}}, il vaut mieux ne pas le supprimer ! − ©éréales Kille® [Speak to me]* en ce vendredi 27 novembre 2020 à 10:21 (CET)
- Avec mes excuses... --Zivax (discuter) 27 novembre 2020 à 10:27 (CET)
- Pardonné. − ©éréales Kille® [Speak to me]* en ce vendredi 27 novembre 2020 à 11:09 (CET)
- Avec mes excuses... --Zivax (discuter) 27 novembre 2020 à 10:27 (CET)
Appel à commentaire pour la documentation du Modèle:Réponse FdN
Bonjour tout l'monde !
Ne sachant pas si les contributeurs veillent aux notifications, je préfère passer ici pour vous inviter à vous rendre sur la page Discussion modèle:Réponse FdN et répondre, si vous le souhaitez, au sujet que je viens de créer. Dans un futur plus ou moins proche, je prévois de remplir les méta-données du modèle et vos réponses m'y aideront ! Merci d'avance, bonne journée | TechAcquisitor (discuter) 21 décembre 2020 à 14:55 (CET)
- Ayant reçu une réponse plutôt exhaustive, je retire ma notification. Tout le monde est cependant le/la bienvenu(e) si quelqu'un à quelque chose à ajouter; merci ! | TechAcquisitor (discuter) 21 décembre 2020 à 17:59 (CET)
Généalogie animaux
Bonjour,
Il se trouve que pas mal d'animaux sont sélectionnés dans des élevages ou, comme les ours dans les Pyrénées, particulièrement scrutés pour leur gènes. Serait-il possible à quelqu'un d'ajouter des champs "familiaux" récupérés de wikidata sur {{Infobox Animal}} un peu comme dans {{Infobox Biographie2}} ? -- -- El Caro bla 28 décembre 2020 à 13:26 (CET)
- Bonsoir El Caro .
- Pour les infobox Lua, mieux vaut s'adresser à leurs développeurs. Voir pour cela l'historique du Module:Infobox/Animal.
- J'ai tout de même tenté de comprendre ta demande. J'ai donc regardé les données Wikidata de la page ours dans les Pyrénées, et il n'y a pratiquement rien. Donc impossible d'y chercher ce que tu souhaites.
- J'ai également regardé le module, il récupère déjà
'père', property = 'P22'et'mère', property = 'P25'. Quelles autres propriétés souhaiterais-tu (voir ici) ? - --FDo64 (discuter) 29 décembre 2020 à 22:10 (CET)
- Un meilleur exemple aurait été Cachou (ours) qui a d'ailleurs son père de renseigné, Ours dans les Pyrénées n'a pas d'infobox et de donnée car il parle d'un cas localisé d'ours, ni d'une espèce ni d'un individu.
- Comme le dit FDo64 si d'autres données intéressantes sont disponibles sur wikidata cela ne devrait pas poser de problème pour les récupérer, mais il faudra des exemples.
- Je pense qu'il manque déjà P40 (« enfant ») et P3373 (« frère ou sœur »). — eru [Discuter] 29 décembre 2020 à 22:38 (CET)
- En faite toutes les données de family me semblaient utiles ou au moins plausibles, je l'ai donc ajoutés directement diff, voir sur Balou pour Enfant — eru [Discuter] 29 décembre 2020 à 22:46 (CET)
Infobox Société et référence tirée de wikidata
Bonsoir,
dans la version courante (175566830) de Pixar Animation Studios on voit dans l'infobox :
Actionnaires The Walt Disney Company et Steve Jobs1,2
et la référence en question était en erreur. Pour l'erreur j'ai modifié Wikidata même si c'est un peu discutable.
Néanmoins l’affirmation dans l'infobox reste fausse. Pour une raison évidente Steve Jobs n'est plus actionnaire, et c'est bien décrit dans la déclaration qui va bien dans Q127552 où pour P126 l'entrée Steve Jobs est accompagnée d'un qualificatif « date de fin » avec une valeur valide.
Je ne sais pas comment se fait l'intégration de cette info depuis wikidata, mais il me semble qu'il faudrait prendre en compte l'éventuel qualificatif « date de fin » pour ne pas mentionner les actionnaires qui ne le sont plus.
Bonne soirée,
--Gaillac (discuter) 26 octobre 2020 à 21:52 (CET)
- Bonjour Gaillac
- On peut mettre showdate=true et sorttype=chronological ce qui donnerait :
- Steve Jobs (-
)[1],[2] et The Walt Disney Company (depuis le ) - Bonjour,
- désolé de ne pas avoir pris le temps de répondre. Je n'ai pas d'avis sur le comment, mais le résultat proposé me semble très bien.
- --Gaillac (discuter) 1 novembre 2020 à 11:28 (CET)
- Bonjour Gaillac et tout le monde, je trouve également que c'est une bonne idée ! Serait-il également possible de remplacer le "et" par un retour à la ligne entre chaque actionnaire ? Il me semble que ce serait plus lisible dans une infobox.
- --2A01:CB14:A61:EC00:F9D6:94CC:55A8:E83E (discuter) 26 novembre 2020 à 12:00 (CET)
- Bonjour Gaillac
Références
- ↑ (en) Donna K. H. Walters, « Jobs Acquires Lucasfilm’s Graphics Unit », Los Angeles Times, El Segundo, (ISSN 0458-3035 et 2165-1736, OCLC 3638237, lire en ligne).
- ↑ (en) « Steven Jobs Buys Lucasfilm Unit », Associated Press, New York, AP, (BNF 13176480, lire en ligne).
Appel aux commentaires pour Modèle:Site_officiel
Bonjour 
tout le monde, nous sommes quelques Wikipédistes à avoir ressenti un besoin d'évolution du modèle Site officiel et eru a eu la gentillesse de se pencher sur la réalisation des améliorations attendues ! Cependant, nous aimerions ouvrir la réflexion sur ces changements à plus de personnes : vos conseils, observations et remarques seraient d'une aide précieuse, à la suite de cette discussion. Vous pouvez également observer l'avancement du nouveau modèle sur cette page de test. Merci 
de votre intérêt !
--2A01:CB14:A61:EC00:95CC:B337:5C13:8BA7 (discuter) 27 novembre 2020 à 13:16 (CET)
- Bonjour 2A01:… et Eru. Pas d'objection quant à la modification apportée aux trois modules. N'afficher qu'un lien est préférable dans le cas général i.e. quand il y a, dans Wikidata, un unique site officiel décliné en plusieurs langues dont le français. Il pourrait y avoir quelques exceptions avec deux sites officiels différents du type nom.fr et nom.com pour lesquels l'affichage des deux ne serait pas problématique. Mais une telle pratique doit être assez rare. Une recherche rapide permettrait-elle de lister ces cas particuliers qui seront "altérés" par le basculement ?
- Autre question : même s'il sera conseillé de laisser le comportement par défaut, est-ce qu'un paramètre maxLang sera ajouté au modèle ou bien la valeur restera-elle à 3 partout ?
- — Ideawipik (discuter) 30 novembre 2020 à 11:06 (CET)
- Bonne idée, je vais voir pour faire quelques recherches statistiques et ajouter un paramètre de modèle maxLang. — eru [Discuter] 30 novembre 2020 à 18:27 (CET)
- Bonsoir ! Merci pour ton intervention Ideawipik, Eru a indiqué avoir ajouté maxLang en paramètre, là-bas : https://fr.wikipedia.org/wiki/Discussion_mod%C3%A8le:Site_officiel#En_fran%C3%A7ais
- --2A01:CB14:A61:EC00:DD35:9AD5:870F:5FE2 (discuter) 1 décembre 2020 à 17:53 (CET)
- Bonsoir
- Bonne idée, je vais voir pour faire quelques recherches statistiques et ajouter un paramètre de modèle maxLang. — eru [Discuter] 30 novembre 2020 à 18:27 (CET)
Bug d'affichage si le lien « lire en ligne » a des guillemets droits doubles
Bonjour
Je viens de m'apercevoir d'un bug après avoir mis https://books.google.fr/books?id=yAoVAAAAIAAJ&pg=PA134&dq="I+Ketut+Gedé" dans le paramètre « lire en ligne » d'un modèle {{ouvrage}} (&dq="I+Ketut+Gedé" indique que ces mots sont recherchés et sont surlignés dans le texte du livre de la page Google Books).
À la place de l'habituel lire en ligne, il est affiché "I+Ketut+Gedé" lire en ligne [archive] et le lien ne fonctionne pas et renvoie à la place sur https://books.google.fr/books?id=yAoVAAAAIAAJ&pg=PA134&dq=#v=onepage&q&f=false
C'est dans la bibliographie de l'article I Ketut Gedé, ([EDIT] corrigé depuis) je reproduis le bug ici:
{{Ouvrage|auteur=Auteur|titre=Titre|lire en ligne=https://books.google.fr/books?id=yAoVAAAAIAAJ&pg=PA134&dq="I+Ketut+Gedé"}}.
donne : Auteur, Titre ("I+Ketut+Gedé" lire en ligne).
À noter que le bug avec des guillemets droits doubles affecte les liens WikiMedia depuis des années :
https://books.google.fr/books?id=yAoVAAAAIAAJ&pg=PA134&dq="I+Ketut+Gedé" ne fonctionne pas correctement.
Cela est rapporté sur Phabricator depuis 2013 ([5]) sans avoir été réglé.
Il semble qu'on puisse contourner le problème en remplaçant les guillemets par " :
https://books.google.fr/books?id=yAoVAAAAIAAJ&pg=PA134&dq=%22I+Ketut+Gedé%22 fonctionne.
Si jamais le problème ne peut être réglé du coté des modèles/modules, il serait peut-être souhaitable de le faire corriger par un bot qui devrait passer le plus souvent possible.
J'ai également mis le même message sur la Discussion module:Biblio mais il vaudrait mieux tenir la discussion ici, car le problème touche potentiellement tous les modèles avec des liens externes comportant des guillemets droits doubles.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 15 décembre 2020 à 12:25 (CET)
- Bonjour SyntaxTerror :. Peut-être utiliser {{Google Livres}}, et remplacer les
"par%22? Jack ma ►discuter 15 décembre 2020 à 15:59 (CET)- Bonjour Jack ma :. J'ai déjà réglé mon problème en utilisant
"(résultat identique avec%22), mais ce truc devrait être réglé en amont, au niveau des modules (à bien y réfléchir, ce ne doit pas être possible d'éviter ça dans les modèles), parce que la majorité des contributeurs ne connaissent pas le truc et ne s'en rendent d'ailleurs pas forcément compte (je l'ai remarqué par hasard en repassant sur l'article que j'avais créé hier). - Je suis en train de télécharger le dernier dump pour voir avec AWB si le cas est fréquent ou pas. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 15 décembre 2020 à 16:09 (CET)
- Bonjour. Pas forcément adapté ici, mais dans d'autres modèles non basés sur un module, cela pourrait être pris en compte directement dans le modèle, en appelant le module String ou le modèle {{Remplace}}.
- Dans notre cas, est-ce que le remplacement systématique des guillemets droits pourrait introduire des erreurs ou bien est-il sûr à 100 %. Auquel cas l'ajout d'une ligne au(x) module(s) bibliographique(s) devrait suffire. Il y a d'ailleurs déjà des substitutions similaires dans le Module:Biblio/Références. — Ideawipik (discuter) 15 décembre 2020 à 18:04 (CET)
- Bonjour Ideawipik :. La question de savoir si remplacer
"par%22ou"casse quelque chose importe peu si le lien ne fonctionne déjà pas avec les guillemets... Bien sûr, je rate peut-être quelque chose et de toute façon il vaut mieux demander le plus d'avis possibles avant de lancer un bot sur l'ensemble de Wikipédia. - Le dump que je viens de passer un bon moment à télécharger et à décompresser semble corrompu, donc je vais surement devoir en télécharger un autre. La liste des occurences des guillemets droits doubles dans les articles ne sera donc pas poiur tout de suite apparement... Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 15 décembre 2020 à 22:12 (CET)
- Si on fait passer un bot
- Bonjour SyntaxTerror. Avec ma proposition ci-dessus, pour les liens introduits par un modèle, on ne fait pas passer de bot puisqu'on modifierait juste le modèle/module. On peut d'ailleurs repérer les guillemets présent dans les paramètres (url, lire en ligne, etc.) par des recherches sur les résultats d'analyse de dump comme ici.
- Pour les liens externes introduits par la syntaxe classique entre crochets, il y aurait besoin d'analyser un dump puis de modifier les liens dans les articles, mais idéalement, le bot devrait pouvoir vérifier que les pages cibles ne sont pas des cibles brisées ou des pages d'erreur. Sinon, cette action serait sans intérêt. — Ideawipik (discuter) 15 décembre 2020 à 22:28 (CET)
- Bonjour
- Bonjour
- Bonjour
┌─────────────────────────────────────────────────┘
- Résultat de la recherche sur le dump de novembre : 250 occurences dont 184 articles (liste).
- J'ai cherché avec
https*:\/\/[^\r\n\t\f\v \|\<\>]*?"[^\r\n\t\f\v \|\<\>]*?"mais je ne suis pas sûr que ce soit le plus efficace, ni si ça a permis de tout trouver. - Il y a des liens inclus dans des modèles (ouvrage, lien web, etc.) mais aussi des liens webs simples (avec ou sans crochets), donc faire passer un bot semble nécessaire.
- Il me semble possible de faire passer un bot en automatique, je vais faire proposition sur WP:RBOT pour receuillir plus d'avis.
- Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 16 décembre 2020 à 17:43 (CET)
Fusion de modèles bandeau d'archive
Pour info, Wikipédia:Pages à fusionner#Modèle:Archive et Modèle:Archive de discussion/simple et Modèle:Archive de discussion. -- Nemo Discuter 15 décembre 2020 à 23:25 (CET)
TemplateData, majuscule ou pas dans les libellés de modèles ?
Discussion transférée sur Discussion Projet:Modèle/TemplateData. N'hésitez pas à intervenir là-bas. -- Nemo Discuter 22 décembre 2020 à 07:36 (CET)
Portal di Ensiklopedia Dunia
