Discussion Projet:Modèle/Archive 2020

La palette qui déglingue l'affichage

Bonjour, ce modèle détruit la largeur des pages Wp où il est mis à cause de plusieurs texte qui débordent. Quelqu'un serait-il corriger cela ?

Merci d'avance, -- Nemo ^Discuter 7 janvier 2020 à 21:38 (CET)

 Nemo Le Poisson : Dis donc tu as un petit écran pour avoir ce problème  ! Cela vient du fait que les éléments sont trop longs. Le pire étant :

• Bette Davis, Jean Delannoy, René Ferracci (posthume), Maurice Jarre et Claude Lanzmann (1986)

Il y a deux solutions pour les découper :

Solution 1 :

• René Clément
• Georges de Beauregard
• Edwige Feuillère (1984)
• Christian-Jaque
• Danielle Darrieux
• Christine Gouze-Rénal
• Alain Poiré (1985)
• Bette Davis
• Jean Delannoy
• René Ferracci (posthume)
• Maurice Jarre
• Claude Lanzmann (1986)

Solution 2 :

• 1984
  • René Clément
  • Georges de Beauregard
  • Edwige Feuillère
• 1985
  • Christian-Jaque
  • Danielle Darrieux
  • Christine Gouze-Rénal
  • Alain Poiré
• 1986
  • Bette Davis
  • Jean Delannoy
  • René Ferracci (posthume)
  • Maurice Jarre
  • Claude Lanzmann

Il y a bien une troisième solution mais trop lourde : ajouter le modèle {{Sécable}} à chaque ligne. Je ne la recommande pas.

Une préférence ? --FDo64 (discuter) 7 janvier 2020 à 22:52 (CET)

Aucune idée, je te laisse faire ce que tu crois de mieux. Et mon écran n'est pas du tout petit, c'est un pc portable 15 pouces ! -- Nemo ^Discuter 12 janvier 2020 à 17:01 (CET)

 Nemo Le Poisson :  Fait. Solution 2 mise en place. --FDo64 (discuter) 12 janvier 2020 à 22:24 (CET)

Infobox Aire protégée

Bonjour, un problème perdure sur Infobox Aire protégée quelqu'un aurait une solution ? --Yanik ^B 12 janvier 2020 à 16:57 (CET)

Catégorie « ParserFunctions »

Bonjour,
La catégorie « Modèle utilisant les ParserFunctions » me semble plutôt obsolète : en effet, je pense que le nombre de modèles utilisant les parser functions est bien plus élevé que les 53 modèles présents dans cette catégorie. Elle a été créée en 2006 et depuis, les parser function sont présentes un peu partout dans les modèles... Est-ce bien utile de conserver une telle catégorie qui devrait maintenant contenir la grande majorité des modèles ?
Je notifie  Verdy p, créateur de la catégorie à l'époque.
Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 18 janvier 2020 à 10:26 (CET)

Entièrement d'accord. Noter que la catégorie n'a pas vraiment changé depuis sa création en 2006, et elle est présente seulement sur une poignée de modèles un peu au hasard. (et j'ai bien ri en revoyant ceci, surtout que depuis lors niveau complexité, avec des choses comme Lua et Wikidata, on a monté d'un niveau de magnitude). od†n ↗^blah 18 janvier 2020 à 12:14 (CET)

Je n'ai jamais compris l'utilité de cette catégorie et je l'ai parfois enlevée de modèles qui n'en avaient pas. Surtout que les ParserFunctions sont particulièrement basiques au niveau programmation… L'écriture de tableaux est parfois autrement plus compliquée ! --FDo64 (discuter) 18 janvier 2020 à 18:44 (CET)

A l'époque elles étaient discutées par la Fondation qui envisageait de les supprimer ou les remplacer par autre chose. Elles sont maintenant intégrées (et parfois plus efficace dans divers modèles que de faire un appel à un modèle externe Lua. Ca date quand même d'il y a plus de 15 ans ! Si ça n'a pas été suivi depuis (j'en doute), tant pis on peut supprimer. En revanche la page de doc du modèle devrait mentionner le bandeau d'avertissement : leur syntaxe est compliquée pour un wikibéotien, c'est moins facile à écrire et maintenir dans un modèle que dans un module Lua, et pas toujours très lisible avec toutes les accolades imbriquées, certaines collées et d'autres non selon que les espaces sont signifiants ou pas (un problème qu'on n'a pas en Lua où le texte signifiant est délimité dans des chaines de caractères par des apostrophes ou guillemets ASCII ou encore par des "long strings" entre crochets pour les chaines contenant des sauts de ligne, apostrophes et guillemets ASCII; Lua évite aussi des interactions avec la syntaxe wiki comme l'obligation d'ajouter des commentaires HTML à certains endroits ou des balises nowiki pour éviter une substitution précoce incorrecte; la syntaxe Lua est bien plus simple dans ce cas et plus souple, plus lisible, plus facile à maintenir pour faire des ajouts ou changer des données incluses ou de nouveaux cas d'usage à prendre en compte).

Aussi il y a eu beaucoup plsu de modèles les utilisant dans le passé. Les plus lourds et les plus compliqués (du fait de l'absence de variables et de l'obligation de dupliquer des morceaux entiers de code) ou été convertis en Lua bien plus simples à maintenir. Les modèles qui restent et les utilisent sont bien plus simples et n'ont pas besoin de Lua ou bien l'usage des ParserFunctions est très restreint avant d'appeler les modules Lua. De fait ils sont bien plus lisibles et ce n'est souvent qu'un simple #if pour passer une valeur par défaut différente de celle que prend en charge un module Lua plus générique utilisé par plusieurs modèles similaires. Verdy p (discuter) 19 janvier 2020 à 06:46 (CET)

 Verdy p Du coup, de ce que je comprend, cette catégorie s'appliquait en fait aux modèles utilisant des syntaxes complexes de parser function, qui ont maintenant pour la plupart été convertis en Lua. Dans tout les cas, au vu des modèles restant dans cette catégorie (pour la plupart de simples switch), il me semble que l'on pourrait s'en passer. As-tu une objection à sa suppression ?

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 19 janvier 2020 à 07:59 (CET)

Non car vu ce qui a été retiré de la catégorie depuis et ce qui reste, je ne pense pas qu'il soit encore nécessaire de la maintenir. Les usages restants des ParserFonction devraient être assez simples à suivre. On peut malgré tout vérifier que parmi les membres qui restent, soit il sont complexes et n'utilisent que ça, soit il sont simples et le reste est dans un module. Ce serait mieux de faire ça membre par membre pour voir ce qui reste: si c'est simple (pas d'imbrications complexe de #if et gestion fine des espaces nécessaires ou inerdits), on décatégorise le modèle. Une fois la catégorie vidée seulement on pourra la virer. Ca me semble pragmatique et permet de passer en revue justement les modèles compliqués qui restent et devraient être convertis en Lua (mais pas besoin de le faire si ce ne sont que des #if qui donnent juste une valeur par défaut à un paramètre manquant du modèle).

Si un modèle n'est qu'un simple #switch ou un raccourci pour utiliser une fonction parser avec des paramètres simplifiés, inutile de convertir en Lua, ce serait une complication inutile (et l'appel de Lua est plus couteux qu'une simple fonction parser avec peux de paramètres et pas de duplication de code; tout laisser dans le modèle est plus rapide et plus facile à maintenir) .

Bref la catégorie a toujours été une catégorie destinée à la maintenance des cas compliqués, où des besoins fréquents de modif les rendait fragiles car compliqués à comprendre pour un béotien, et même pour un expérimenté car on avait vite fait de se tromper sur l'imbrication des accolades, même en faisant attention. Les parserfunctions sont toujours très utiles et plus économiques en ressources sur le serveur et temps de traitement/d'afficchage qu'un appel de module Lua (qui nécessaite non seulement de charger ce module, comme on charge un sous-modèle, mais aussi de lancer une VM. Lua n'est pas fait pour tout, c'est dans les cas compliqués (y compris la gestion de nombreuses exceptions et paramètres spéciaux dans des cas "tordus", comme les divers formats de date, ou les #ifexist pour modifier un rendu conditionnel, ou la gestion des traductions synchronisées sur Wikidata pour plus de langues, ou faire des calculs statistiques pour retourner des valeurs d'agrégat cohérentes) que Lua est gagnant en terme de taille totale d'expansion des modèles. Verdy p (discuter) 20 janvier 2020 à 02:55 (CET)

Vu, je vais commencer par retirer les modèles "simples" de la catégorie, et on avisera après. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 20 janvier 2020 à 08:39 (CET)

 Verdy p J'ai fait un ménage des modèles les plus « évidents », mais à mon avis ceux qui restent ne sont pas bien compliqués non plus... En tout cas bien moins compliqués que beaucoup de modèles que j'ai consultés et qui ne font pas partie de la catégorie. Je te laisse jeter un coup d’œil si tu le souhaites, mais mon avis est de terminer la décatégorisation et de supprimer celle-ci. Pour info également : la discussion ayant mené à la suppression de la catégorie sur WP:EN. Je suis assez d'accord avec l'avis « redundant to Category:Templates. »

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 20 janvier 2020 à 16:23 (CET)

Note que les avis sur WP:EN tiennent compte de ce qu'il y a maintenant. Dans le passé cette catégorie avait été réclamée, mais elle a subi aussi le même sort depuis l'arrivée de Lua et la simplication de nombreux modèles lourds en les passant en appels de modules, elle s'est vidée progressivement aussi quand le besoin de maintenance lié aux parser functions ne s'est plus justifié. Verdy p (discuter) 20 janvier 2020 à 17:38 (CET)

Bien entendu, je n'ai jamais dit qu'elle n'avait pas été utile par le passé. Elle aura bien vécu, allez, 14 ans de bons et loyaux services ! Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 20 janvier 2020 à 17:53 (CET)

J'ai procédé au vidage et à la suppression de la catégorie.

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 21 janvier 2020 à 08:33 (CET)

Améliorations du modèle:Infobox Démographie

Bonjour à tous. Des faiblesses du modèle Infobox Démographie avaient été identifiées depuis plusieurs années. Pour y pallier et donc améliorer le modèle, j’ai procédé aux modifications suivantes concernant le bloc "Dynamique".

Ligne population :

• ajout du paramètre nom-pop permettant de personnaliser le type de population et le lien (ex population municipale pour la france
• ajout du paramètre population notes (permettant d’ajouter du texte après hab. et non avant, comme pour la Russie)
• ajout du paramètre population ref (pour mettre une éventuelle référence)
• ajout d’une définition en note propre à la France.

Ligne accroissement naturel : Il y a manifestement erreur de terminologie (l’accroissement naturel, outre le fait qu’il s'agit d’un terme non neutre puisqu'il peut y avoir une diminution, ne prend pas en compte la variation migratoire), mais pour éviter une perturbation sur tous les articles, j’ai maintenu ce paramètre tel quel et ajouté un nouveau paramètre « évolution de la population ».

Ligne évolution de la population :

• ajout des paramètres taux variation et taux variation année
• ajout d’une définition.
• ajout des paramètres solde naturel et solde migratoire pour compléter la définition s’ils existent

Ligne indice de fécondité :

• ajout du paramètre indice de fécondité année
• ajout d’une définition.
• ajout du paramètre indice de fécondité ref (pour mettre une éventuelle référence)

Ligne taux de natalité :

• ajout du paramètre taux de natalité année
• ajout d’une définition.
• ajout du paramètre taux de natalité ref (pour mettre une éventuelle référence)

Ligne taux de mortalité :

• ajout du paramètre taux de mortalité année
• ajout d’une définition.
• ajout du paramètre taux de mortalité ref (pour mettre une éventuelle référence)

Ligne taux de mortalité infantile :

• ajout du paramètre taux de mortalité infantile année
• ajout d’une définition.
• ajout du paramètre taux de mortalité infantile ref (pour mettre une éventuelle référence)

Ligne Espérance de vie à la naissance

• ajout des paramètres espérance vie année, espérance vie hommes et espérance vie hommes
• changement de la présentation
• ajout d’une définition.
• déplacement de l'item dans le bloc "âges"

Pour les autres blocs, je verrai cela plus tard. Je vais également faire passer prochainement un bot pour actualiser l'ensemble des paramètres des Infobox des articles relatifs à la démographie d'un pays. Pour la plupart, ils sont restés bloqués à 2015. Ce qui permettra également de corriger certains paramètres (il y a confusion par exemple entre solde migratoire et taux de migration nette, l'un est compté en personnes, l'autre est un ratio en pour mille). Je corrigerai et complèterai ultérieurement la page de documentation du modèle. Cordialement.Roland45 (discuter) 20 janvier 2020 à 14:40 (CET)

Modèles de siècles

Pour information : je viens d'effectuer un changement sur le modèle {{sp}}, et quelques tripatouillages sur la palette de documentation.

J'ai voulu notifier l'auteur d'un grand développement de la palette remontant à quelques années, mais je constate qu'il est maintenant bloqué indéf…

Bref, n'hésitez pas à vérifier les modifs que je viens de faire là. od†n ↗^blah 20 janvier 2020 à 16:37 (CET)

Bandeaux : Travaux en cours

Bonjour, je vous détaille en toute transparence les travaux que je mène actuellement sur les bandeaux.

Travail effectué :

• Remplacement des méta-modèles de bandeaux utilisés dans l’espace principal (60 articles) par des modèles standard. Pour rappel, les méta-modèles sont interdits dans l’espace principal.
• Réécriture des modèles de bandeaux d’articles et de section utilisant une class ‘bandeau-xxx’ sans faire appel à un méta-modèle (90 modèles).

Reste à faire :

1. Réécriture des modèles de bandeaux qui ne contiennent ni class ‘bandeau-xxx’, ni méta-modèle.
2. Création d’un TemplateStyle afin de déplacer tout le css actuellement dans MediaWiki:Common.css.
3. Classification automatique des bandeaux en fonction de leur niveau :
   1. 5 nouvelles catégories par niveau : grave, modéré, ébauche, information, ou neutre
   2. ranger les trois premières catégories dans Catégorie:Modèle de maintenance
   3. ranger les deux dernières dans Catégorie:Modèle d'avertissement que l’on devrait renommer autrement (« avertissement » étant utilisé en cas de faute, ce qui n’est pas le cas ici).

--FDo64 (discuter) 2 février 2020 à 09:22 (CET)

Bonjour FDo64. Merci pour l'information. Si cela a pour but de donner une meilleure visibilité aux différents bandeaux et faciliter la maintenance, c'est bien. Mais que veut dire « Classification automatique » ?

Pour la dernière catégorie dont le nom est à changer, autant faire le choix le plus tôt possible, pour économiser des re-catégorisations ultérieures. --Ideawipik (discuter) 2 février 2020 à 14:26 (CET)

 Ideawipik : C'est « Catégorisation automatique » que j'aurais dû écrire. La catégorie par niveau de bandeau sera calculée dans les méta-modèles. --FDo64 (discuter) 2 février 2020 à 14:45 (CET)

Cas du modèle Boîtes mouvantes

Bonjour,
Le modèle {{Boîtes mouvantes}} créé par Dr Brains (d · c) (maintenant visiblement bloqué, à priori à sa demande) semble n'être fonctionnel que pour peu que l'utilisateur inclue ce code dans son CSS et ce code dans son js.
Ce fonctionnement ne peut être utilisé pour des modèles de l'espace principal (voire aucun modèle sauf un ultra-spécialisé). Or, il semble utilisé sur plusieurs pages de l’encyclopédie. Il faudrait déjà retirer ce modèle de l'espace encyclopédique : par quoi pourrait-on le remplacer ? Ensuite, il faudrait à mon avis tout simplement le supprimer : il n'est pas envisageable d'avoir un modèle pour lequel une action manuelle est requise par l'utilisateur : si l'on peut placer le CSS en TemplateStyle, je doute que l'on puisse faire de même avec le javascript (ou bien peut-on ?)
Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 19 février 2020 à 08:42 (CET)

Code crade (cf. par exemple rien que les "padding-bot\tom" dans le css), et le code n'est pas de Dr Brains (source : http://www.brothercake.com/site/resources/scripts/dbx/).

Utilisé (pour ainsi dire) uniquement dans {{Croisades}} où il a été ajouté avec l'éditeur visuel et vraisemblablement par erreur.

Bref, pas la moindre objection à la suppression complète.

od†n ↗^blah 20 février 2020 à 17:40 (CET)

 Od1n vu, merci pour la localisation de l'edit source !

Du coup, je supprime purement et simplement l'appel et le modèle.

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 20 février 2020 à 18:18 (CET)

Modèle:Décennie

J'ai proposé des évolutions du modèle {{Décennie}} : Affichage systématique des décennies précédentes et suivantes et Paramètres 4, 5 et 6. J'attends vos commentaires sur la page de discussion du modèle. — Berdea (discuter) 11 février 2020 à 12:44 (CET)

Protection des modèles très utilisés

Bonsoir  Pic-Sou, Azurfrog, Thibaut120094, Epok, Orlodrim, Trizek et Od1n et tous les autres !

Il m’a été demandé de protéger les modèles très utilisés que je créais. Du coup j’ai regardé la page spéciale « Pages les plus incluses » pour me rendre compte que beaucoup de pages très utilisées ne sont pas protégées.

Dans la liste des 5 000 pages les plus incluses, j’ai cherché celles qui ne sont pas protégées et je trouve :

• 2658 modèles dont Modèle:Documentation module données démographiques, Modèle:Centrer, Modèle:Drapeau2/Image/France, Modèle:Footballdatabase, Modèle:Légende Wikidata, Modèle:France (1364-1638) , Modèle:Sources secondaires, Modèle:Catégorie renommée, Modèle:Catégorie architecture et urbanisme, Modèle:Infobox/Ligne donnée valeurs multiples optionnelle, Modèle:Infobox Joueur de basket-ball, Modèle:Country data Slovaquie, Modèle:Portail Mexique, Modèle:Portail XVIIIe siècle
• 114 modules dont Module:Carte/Points, Module:Dictionnaires, Module:Image Wikidata, Module:Country data/belgique, Module:API/Infobulle, Module:API
• 59 feuilles de styles
• 854 redirections (à ne pas négliger !) dont Modèle:Lang, Modèle:... , Modèle:Harvsp, Modèle:N°, Modèle:Tri1, Modèle:Nombre, Modèle:P.S. , Modèle:Homon, Modèle:… , Modèle:Clin, Modèle:Homonyme, Modèle:Refnec, Modèle:Todo, Modèle:Officiel, Modèle:Bienvenue, Modèle:Sup, Modèle:Infobox Politicien, Modèle:Homonymes, Modèle:USA, Modèle:Supp, Modèle:Imdb name, Modèle:HC, Modèle:Fin dynastie, Modèle:Début dynastie, Modèle:U-, Modèle:Insérer dynastie, Modèle:Voir homonymie, Modèle:Mdr, Modèle:Navigation des astéroïdes, Modèle:Reflist, Modèle:References, Modèle:FRA, Modèle:Mérimée, Modèle:Parcours pro, Modèle:Bases footballeur, Modèle:Portail architecture, Modèle:- , Modèle:Bases géographiques, Modèle:Parcours national, Modèle:Cons, Modèle:Fc, Modèle:Tmp, Modèle:Test1, Modèle:ITA, Modèle:Rire, Modèle:Refsou

Remarques :

• Je n’ai listé que les pages utilisées sur plus de 10 000 pages.
• j’ai la liste complète, malheureusement, et pour une raison que j’ignore, il y a des faux positif. Les catégories Catégorie:Modèle protégé, Catégorie:Modèle en semi-protection étendue et Catégorie:Modèle semi-protégé ne sont pas toujours à jour…

Hors modèles et modules, j’ai également trouvé :

• Projet:WikiMOOC/2017/Bienvenue
• Aide:Comment créer un article/brouillon
• Projet:Historiographie/Caption
• Wikipédia:Image du jour/min
• Wikipédia:Image du jour/max
• Wikipédia:Lumière sur/Date de publication
• Utilisateur:Trizek/Bac à sable/bienvenutage
• Utilisateur:Trizek/Brouillon/bienvenutage
• Projet:Protection du patrimoine/image
• Utilisateur:Xinbenlv bot/msg/inconsistent birthday
• Utilisateur:Xinbenlv bot/msg/inconsistent birthday/instructions
• Utilisateur:OrlodrimBot/StatD/date
• Wikipédia:Le Bistro/Heure d'été
• Utilisateur:OrlodrimBot/StatD
• Portail:Probabilités et statistiques/Icône
• Projet:Wikipédia 1.0/Bot/Bandeau navigation
• Projet:Universités françaises/image
• Utilisateur:OrlodrimBot/Suivi catégorie/fin
• Utilisateur:OrlodrimBot/Suivi catégorie
• Wikipédia:Sélection/Au hasard

Question : Quelle est la limite qui déclencherait cette protection ?

Suggestion pour Orlodrim : Si possible lister dans Projet:Modèle/Maintenance/Listes les modèles nécessitant une protection.

--FDo64 (discuter) 13 février 2020 à 22:21 (CET)

Salut  FDo64.

Je pense qu'outre le nombre d'inclusions, il faut surtout regarder où est inclus le modèle. En effet, la protection des modèles est destinée à éviter une attaque sur ceux-ci qui déstabiliserait un grand nombre de page : au hasard, je décide de remplacer les bandeaux d'article par une pub pour ma boîte : elle s'affiche sur de très nombreux articles et fait beaucoup de vues.

Par exemple, le premier cas de ta liste, {{Documentation module données démographiques}} est très utilisé, mais simplement car il est apposé sur tous les modèles de données démographique, et qu'il y en a beaucoup. Néanmoins, il n'a aucune visibilité dans l'espace principal. Il n'est donc vu quasiment que par des wikipédiens d'un niveau plutôt avancé, qui à priori sauraient comment réagir si ce type de problème se posait. Je ne dis pas qu'il ne faut pas le protéger, c'est juste pour l'exemple.

Du coup, je ne pense pas qu'il y ait un seuil, mais plutôt une capacité de nuisance à évaluer.

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 14 février 2020 à 07:49 (CET)

D'ailleurs je constate que mon exemple est bidon : je viens de me rendre compte que le modèle en question a déjà été vandalisé 2 fois depuis que je l'ai créé il y a à peine 3 mois . J'aurai donc dû moi aussi le protéger depuis le début... Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 14 février 2020 à 07:55 (CET)

Wow ! Je ne pensais pas que des utilisateurs utiliseraient une de mes pages de brouillon pour accueillir d'autres utilisateurs. Je vais tâcher de transformer cela en un redirect propre. Trizek ^bla 14 février 2020 à 11:47 (CET)

Enregistré sur Phabricator
Tâche 200614

Bonjour  Pic-Sou, Azurfrog, Thibaut120094, Epok, Orlodrim, Trizek et Od1n. Pour information, tous les modèles et modules listés sont maintenant protégés.

Pour ce qui est des redirections, elles étaient presque toutes protégées sauf une. Le problème c'est qu'elles n'étaient pas catégorisées. Pour cela, j'ai ajouté la détection et l'ajout des bandeaux de protection dans {{Redirection de modèle}}.

Pour ce qui est des feuilles de style, elles étaient presque toutes protégées sauf une (là encore). Le problème c'est qu'elles ne sont pas catégorisées et je ne sais comment faire ça proprement. Dans l'idéal, il faudrait pouvoir ajouter une documentation générique aux feuilles de styles. J'avais posé la question sur Phabricator et ce n'était alors pas possible. En tout cas, ajouter en dur les catégories de protection me semble une mauvaise solution.

Pour les autres espaces de nom, je n'ai rien fait, sauf la première, ces pages entrent sous le seuil de 10 000.

D'ailleurs, je repose la question, est-ce un bon seuil ?

--FDo64 (discuter) 15 février 2020 à 12:52 (CET)

 FDo64 :

Le seuil me semble raisonnable. La dernière fois que je suis passé sur les modèles country data, il me semble que j'avais protégé les modèles avec plus de 100000 inclusions et semi-protégé ceux avec plus de 10000 inclusions (il n'y a avait pas de protection étendue à ce moment-là).

J'ai calculé les vues indirectes par modèle dans Utilisateur:Orlodrim/Protection modèles (seulement pour les vues de l'espace principal, je n'ai pas les données pour le reste mais ça doit faire beaucoup moins de toute façon). Il y a pas mal de palettes qui sont très vues parce qu'elles regroupent des articles très consultés, mais ça reste en dessous de la moyenne pour les modèles déjà protégés.

Je verrai si je peux intégrer ça au système de maintenance des modèles.

Orlodrim (discuter) 15 février 2020 à 14:18 (CET)

Merci Orlodrim . Ta liste m'a permis de protéger une redirection que j'avais oubliée. --FDo64 (discuter) 15 février 2020 à 14:43 (CET)

 FDo64 : Sinon, tu peux aussi faire des semi-protection (étendue pour être sur), c'est un bon compromis pour éviter les vandalismes mais permettre aux contributeur de bonne foi de pouvoir facilement contribuer sans se prendre là tête avec des DIP. -- Nemo ^Discuter 15 février 2020 à 15:18 (CET)

 Nemo Le Poisson : C'est ce qui a été fait. --FDo64 (discuter) 15 février 2020 à 15:22 (CET)

┌─────────────────────────────────────────────────┘
Super, merci ! Mais ducoup mon message m'amène à une réflexion, à partir de quand peut-on considérer qu'un modèle doit-être protégé ? Dans quel cas les semi ne suffisent pas (pour éviter les contribution maladroites ou sans consensus par exemple ?) -- Nemo ^Discuter 15 février 2020 à 15:28 (CET)

 Nemo Le Poisson : Lire l'intervention d'Orlodrim. --FDo64 (discuter) 15 février 2020 à 15:40 (CET)

TemplateData

Bonjour ! @Tractopelle-jaune avais lancé un ticket phabricator au sujet d'une mise en forme de code personnalisé sur TemplateData :

{{_\n | _______________ = _\n}}\n 

. C'est très utile pour que EV ne déglingue pas le wikicodedes des modèles qui utilisent une mise en forme spéciale.

Je vois dans le ticket qu'il y a un «  mediawiki/services/parsoid : masterImprove templatedata spec compliance wrt leading and trailing newlines » Est-ce que ça veut dire que le problème est réglé ? Histoire que l'on puisse enfin ajouter des infoboxs correctement avec l'EV !

Merci d'avance, -- Nemo ^Discuter 11 février 2020 à 12:23 (CET)

Salut  Nemo Le Poisson,

Je viens de tester sur mon brouillon : Special:Diff/167484616/167484650, le problème est toujours présent (cf. ligne vide ajoutée avant le modèle lorsque modifié avec l'éditeur visuel).

Le problème en question concerne les formats d'indentation pour les modèles pouvant se retrouver en première ligne d'un article. Dans les formats d'indentation personnalisés, il est possible de définir si le modèle peut contenir ou pas (sur la même ligne) du texte avant et/ou après le modèle.

Mais suite à une implémentation défaillante, le cas où le format personnalisé indique qu'il ne doit pas y avoir de texte sur la même ligne avant le modèle provoque la création d'une ligne vide avant le modèle si ce dernier se trouve sur la 1re ligne.

Comme je l'ai indiqué sur Aide:TemplateData#Formats personnalisés de mise en forme du wikicode, c'est pour cette raison qu'il faut utiliser la variante {{_\n | _______________ = _\n}}\n au lieu de \n{{_\n | _______________ = _\n}}\n pour les infobox (pas de \n au début du format).

Mais l’absence du \n au début du modèle n'a normalement que peu de conséquence en pratique du moment que les différents modèles d'en-tête (infobox, bandeaux, homonymie, etc.) possèdent un format avec un \n à la fin, car ce sera au final lui qui ordonnera l'ajout d'un retour à la ligne avant le modèle suivant.

Je reste à disposition en cas de question.

--Tractopelle-jaune (discuter) 16 février 2020 à 14:46 (CET)

Infobox de personnalité

Bonjour, Je propose de modifier les infobox pour préciser certaines informations sur la personne. On devrait présenter P27 (« pays de nationalité ») et P172 (« groupe ethnique ») pour plus de précision (notez que chacun peut en avoir plus d'un). Citoyenneté étant un synonyme de Nationalité mais ce dernier étant un concept plus large, il serait peut-être judicieux d'utiliser les libellés : Citoyenneté et Ethnie. --Yanik ^B 17 février 2020 à 14:56 (CET)

Bandeaux d’homonymie

Bonjour, j’expose ici l’état de mes travaux en cours pour les bandeaux d’homonymie.

Partant du constat qu’un bandeau d’homonymie ressemble à un bandeau de section sans bordure et avec une ligne de séparation, je cherche à utiliser le module:Bandeau afin de produire le même résultat. Dans tous les cas, que ce soit avec le module:bandeau ou sans, la réécriture de tous les bandeaux d’homonymie avec un méta-modèle est indispensable pour une meilleure maintenabilité et une harmonisation.

Problème avec la class « homonymie » : une conversation avec  Mywiz a mis en évidence que la class « homonymie » était mal nommée puisqu’elle est également utilisée pour d’autres bandeaux de début d’articles. En faisant des recherches sur wp:en, j’ai découvert qu’ils avaient nommé cette class « hatnote » (qui signifie « note de début d’article », voir en:Wikipedia:Hatnote). Leur common.css contient par ailleurs le commentaire « Hatnotes and disambiguation notices ». Comme toutes les class utilisées par notre module sont appelées « bandeau-<forme> », je propose donc de créer une nouvelle class nommée « bandeau-note » en remplacement de la class « homonymie ».

Travail effectué :

• Écriture d’un prototype pour les bandeaux d’homonymie : Modèle:Bandeau homonymie/Bac à sable et Modèle:Bandeau homonymie/Test. L’on constate que pour l’instant le résultat n’est pas satisfaisant et je vais continuer à y travailler.

Reste à faire :

• Trouver un développeur Lua pour faire évoluer le module:bandeau (je suis très pessimiste, il y a bien longtemps que j'en cherche)
• Mise au point du prototype
• Création du Modèle:Méta bandeau de note (ou tout autre nom mieux approprié)
• Réécriture des modèles de bandeaux d’homonymie avec ce méta-modèle. Remarque, le même modèle servira pour les pages d’homonymie, il suffit juste d’ajouter id=homonymie.

--FDo64 (discuter) 2 février 2020 à 09:36 (CET)

Bonjour FDo64. Ok pour la maintenabilité et une harmonisation avec un méta-modèle dédié. Par contre, je ne suis pas certain qu'il faille utiliser le méta-modèle ou module existant pour les bandeaux. C'est juste une crainte ; pas pour une raison linguistique mais pour une raison technique (utilisation d'un outil sur-dimensionné ?) et pour la simplicité du code. Le code du module en question n'est pas long. Tu voudrais créer une nouvelle fonction à l'image des "bandeauAvertissement" ou "bandeauSection" ? Il existe aussi déjà un méta-modèle tout simple : Modèle:Bandeau standard pour page d'homonymie. --Ideawipik (discuter) 2 février 2020 à 14:26 (CET)

 Ideawipik : Sauf erreur de ma part, c'est ce que fait l'équivalent wp:en de notre module.

Je ne programme pas en Lua, j'ai tout de même regardé le code du module et je vois que c'est juste une question de « class ». Le module devrait pouvoir être enrichi d'une fonction "bandeauNote". --FDo64 (discuter) 2 février 2020 à 14:54 (CET)

 FDo64 : Pour l'homonymie, en anglais, le méta-modèle en:Template:Dmbox, qui ne correspond pas vraiment aux rubans simples de haut de page, n'utilise pas de module Lua mais seulement une feuille de style CSS en:Wikipedia:TemplateStyles. Les autres modèles de ce type (ruban), regroupés dans cette palette en:Template:Hatnote templates, utilisent chacun un module associé, avec en commun deux supra-modules en:Module:Hatnote et en:Module:Labelled list hatnote. Certains de ces modèles sont redondants ; plusieurs anciens modules ont d'ailleurs déjà été supprimés (tels Module:Details, Module:Further, Module:See also) et leurs modèles associés uniformisés. Sur frwiki, rien n'empêche de regrouper les modèles d'homonymie sous un seul module (Bandeau ou autre).
Pour mieux comprendre la démarche, quelle fonctionnalité manque-t-il actuellement, par rapport à ce qu'offre Modèle:Bandeau standard pour page d'homonymie ? --Ideawipik (discuter) 2 février 2020 à 19:19 (CET)

 Ideawipik : Ça ne me semblait pas aussi confus côté wp:en et je te fais confiance !

Pour les homonymies il y a actuellement deux méta-modèles sous-utilisés : {{Bandeau homonymie}} et {{Bandeau standard pour page d'homonymie}} qu'il serait facile de fusionner puisque la seule différence c'est un id=homonymie. J'ai fait un premier test non concluant avec {{Bandeau homonymie/Bac à sable}}.

Mais le problème n'est pas là : la class homonymie est utilisée pour des bandeaux qui n'ont rien à voir avec des homonymies, il faut donc créer un méta-modèle qui englobe toutes les notes de début d'article qui ont toute la même apparence.

--FDo64 (discuter) 2 février 2020 à 21:09 (CET)

Bonjour FDo64. Une recherche dans l'espace des modèles montre qu'effectivement parfois cette classe est utilisée pour des cas où une confusion est possible sans qu'il s'agisse strictement d'homonymie. Est-ce grave ? Faut-il créer une classe "(dé-)confusion" ou une classe générale "note de début de page"/"hatnote". Remarque: il y a aussi une quinzaine d'articles utilisant la classe "homonymie" directement dans leur code.

Une recherche du mot « homonymie » ne donne rien en rapport avec les bandeaux dans l'espace des modules.

Techniquement, les deux méta-modèles existant pourraient être fusionnées et intégrer un méta-modèle plus général mais y a-t-il besoin d'un module Lua pour un code qui se résume à une ligne de texte avec icône (et une ligne horizontale) ?

Curiosité : quel est l'utilité de l'identifiant HTML dans ce cas précis (créer des liens internes vers le chapeau ? utilité pour des bots ou l'API pour identifier le type de page (page d'homonymie) ? ...)

J'ai survolé le module que tu cherches à utiliser. Le "problème" dans ton essai vient des classes utilisées pour les balises «  »div. Graphiquement, tu peux essayer le paramètre forme=simple, enlever les border (0px) sauf pour le bas et mettre un padding-left: 1em;. Et ce n'est pas encore cela (parce qu'il y a un padding-right: 1em; dans le style de la classe bandeau-icone de MediaWiki:Common.css). Mais surtout c'est vraiment du bricolage pas propre. L'utilisation du module imbrique des div class="bandeau-section bandeau-niveau-information plainlinks", div class="bandeau-cell bandeau-icone" pour l'image et div class="bandeau-cell" pour le texte. Et on ajoute tout un tas de styles pour contrer/rectifier les styles des classes spécifiées, et encore uniquement où le méta-modèle le permet avec son paramètre. On perd l'intérêt des styles de classes et la lisibilité du code HTML en prend un coup.

La question concerne donc davantage les styles et le nommage des classes. Je ne vois toujours pas ce qu'apporterait de plus un module Lua pour les bandeaux/rubans d'homonymie.

Si tu veux absolument passer par le module existant Bandeau, il doit être possible d'agir soit en créant une "fonction" bandeauNote comme évoqué plus haut soit en définissant une nouvelle forme. La première option me semble préférable.

--Ideawipik (discuter) 3 février 2020 à 09:31 (CET)

 Ideawipik : J'avais un peu regardé de mon côté, j'avais trouvé que l'id "homonymie" est utilisé par des gadgets comme BandeauxPortails et PaletteDeluxe, et de mémoire, je crois bien que je n'en avais pas trouvé d'autre utilité. od†n ↗^blah 3 février 2020 à 16:43 (CET)

 Ideawipik : Tout d’abord, merci de t’intéresser au sujet, c’est toujours appréciable de confronter constructivement des idées.

Plusieurs questions/remarques, donc plusieurs réponses :

1. J’ai étudié la totalité des modèles qui utilisent la class « homonymie » qui a été détournée dans bien des cas. Elle sert aussi pour signaler des caractères Unicode, des redirections, signaler que les dates sont Av. J.-C., sans parler des modèles {{Lire d'abord}} et {{ Article général}}. Avoir un nom de class qui ne correspond pas à l’usage qui en est fait n’apporte que confusion. Dommage qu’on n'ait pas l’équivalent de « hatnote » qui est plus clair.
2. J’ai également étudié la totalité des autres espaces de noms.
3. Pour ce qui est de l’identifiant HTML des pages d’homonymies, il avait été ajouté le 6 novembre 2010 avec le commentaire suivant : « id pour repérer que la page est une homonymie ».
4. Avoir un nouveau module serait pour moi une mauvaise idée, alors que quelques lignes ajoutées au module:Bandeau devraient suffire. C’est ma préférence, mais je ne vais pas m’obstiner si je suis le seul à être persuadé de l’utilité d’avoir un unique module qui génère la totalité des bandeaux.
5. Le bac à sable que j’ai indiqué est clairement un bricolage qui avait pour objectif de simuler ce qui serait faisable avec le module. Il ne fonctionne pas parce que qu’il n’est pas possible de forcer la class. Je n’avais pas l’intention de le mettre en place en l’état. J’avais d’ailleurs présenté à  Od1n une première version « propre » qui changeait trop l’apparence, donc irrecevable. Si ce n’est déjà fait suite à son intervention, je te conseille la lecture de sa réponse qui répond à certaines de tes questions.

En attendant, je vais écrire le Modèle:Méta bandeau de note qui sera un « vrai modèle en wikitexte » qui reprend les fonctionnalités de trois modèles actuels qu’il remplacera. Si un jour module:Bandeau ou le nom de la class évoluent, il n’y aura plus qu’à modifier ce modèle. Comme l’implémentation de ce méta-modèle est indépendante de la façon dont il est programmé (wikitexte/Lua), je vais commencer à le déployer.

--FDo64 (discuter) 4 février 2020 à 00:55 (CET)

Pour information, tout est terminé, hormis l'évolution du module. --FDo64 (discuter) 9 février 2020 à 16:39 (CET)

┌─────────────────────────────────────────────────┘
 Mywiz, Od1n, Ideawipik et Pic-Sou : Bonsoir. Il devient de plus en plus nécessaire d’ajouter le bandeau de notes dans le module:Bandeau. Il y a déjà {{Article général}} qui doit pouvoir prendre la forme de bandeau de note ou de section, maintenant il est demandé la même chose pour {{Redirect}} et {{Redirect confusion}}.

J’ai donc pensé à une solution élémentaire consistant à ajouter deux lignes (en tout trois mots) dans module:Bandeau/Class/Bac à sable et c’est presque parfait ! Juste un décalage que je ne m’explique pas (voir {{Méta bandeau de note/Test}}). Quelqu’un pour m’aider ?

--FDo64 (discuter) 24 février 2020 à 21:28 (CET)

Bonjour FDo64. Le décalage vient de la classe utilisée. Voir le code HTML de la page dans lequel apparaissent des <div class="bandeau-cell bandeau-icone">. (cf aussi mon message plus haut). Classe CSS à retoucher ou en utiliser une autre ou aucune. Dans le premier cas, vérifier ses utilisations dans l'encyclopédie avant de modifier. Ce type de solution assez simple pourrait convenir. Merci pour ton activité. --Ideawipik (discuter) 24 février 2020 à 22:18 (CET)

Les classes bandeau-icone et bandeau-cell ont apparemment vraiment été prévues pour les bandeaux d'articles. La classe bandeau-icone n'a pas l'air réutilisable en l'état, et il me parait aussi "dangereux" de réutiliser la classe bandeau-cell. À première vue, le mieux me semblerait de créer de nouvelles classes : bandeau-homonymie-icone, bandeau-section-icone… pourquoi pas aussi renommer bandeau-icone en bandeau-article-icone… od†n ↗^blah 24 février 2020 à 23:12 (CET)

Bonsoir, avec les indications de  Ideawipik et avant celles de  Od1n, j'ai modifié le bac à sable pour retirer la class bandeau-icone pour les notes et, en apparence, cela semble parfait. Au moins au niveau du rendu (Cf. page de test).

--FDo64 (discuter) 24 février 2020 à 23:51 (CET)

Bonjour, comme je reste persuadé de l’utilité d’avoir un unique module pour générer les différentes formes de bandeaux, je vais mettre en place la nouvelle version.

Pour ce qui est du nettoyage du code Lua ou du CSS, cela ne fait pas partie de mes domaines de compétences, donc je ne saurai m’en charger.

Par ailleurs, comme je pensais comme  Od1n que le paramètre nohr était inutile, j’ai ajouté un exemple sans paramètre nohr=1 dans la documentation de {{Méta bandeau de note}} pour me rendre compte qu’il y a bien une différence. Du coup je ne sais pas à quoi sert l’instruction .homonymie + .homonymie dans MediaWiki:Common.css qui est justifié par « Masque les bordures adjacentes ».

--FDo64 (discuter) 29 février 2020 à 09:35 (CET)

Le "nohr" semble être un reliquat (qui a perduré) de l'époque où le masquage des bordures adjacentes n'était pas automatique (refs par exemple 18131232, qui date de 2007). Le masquage automatique a été implémenté en 2011 (refs 68363639). Code que j'ai retouché en 2017 (refs 137935694 et suivants), parce que les bandeaux adjacents étaient trop "collés".

Dans ta page de documentation, les exemples avec et sans "nohr" ont effectivement (et logiquement) des rendus différents. Le rendu souhaité est le rendu sans le "nohr".

Du coup, je serais d'avis de complètement supprimer le paramètre "nohr" des modèles, et de le supprimer dans les articles (environ 200 occurrences dans les articles, et une centaine d'occurrence un peu en pagaille dans les autres namespaces).

od†n ↗^blah 29 février 2020 à 16:01 (CET)

Pour information, je viens de remarquer une différence de rendu entre les modèles {{Article général}} et {{Article principal}} :

od†n ↗^blah 1 mars 2020 à 03:08 (CET)

Aussi remarqué à l'instant : dans les inclusions du méta-modèle "bandeau de section", nombreuses présences d'un paramètre "titre" vide, paramètre qui n'existe pas dans le méta-modèle en question. À noter que cela se retrouve sur toutes les nouvelles pages de bistro (il y a un preload quelque part ?). od†n ↗^blah 1 mars 2020 à 03:22 (CET)

Il faudrait implémenter le mode "position=section" dans le modèle {{Confusion}}, j'ai repéré trois occurrences où cela serait nécessaire : BMW Série 1#1 M Coupé, Saint-Affrique#L'histoire et Château de Kincardine (Fettercairn)#Sheriffdom de Kincardine.  FDo64 : je préfère te confier le soin d'effectuer cette implémentation, si tu le veux bien ;)

Aussi, je viens de finir de nettoyer les "nohr" dans le namespace principal.

On devrait être tout proche de pouvoir complètement supprimer le paramètres "nohr" des codes des modèles :)

od†n ↗^blah 1 mars 2020 à 03:44 (CET)

Bonjour et merci Od1n pour tes efforts.

Pour la question liée à l'initialisation des pages du Bistro, s'il faut modifier quelque chose, il vaut mieux demander à ZéroBot ou à Framawiki, mais je pense avoir trouvé (voir ici). Après réflexion, peut-être que FDo64 veut faire quelque chose de ce paramètre ? N'hésite pas à annuler si c'est le cas.

Pour la question du mode "position=section", ne serait-il pas à implémenter dans {{Méta bandeau de note}} plutôt que dans Confusion ?

Pour la différence encore une question de classe :

• Article général (class="bandeau-section metadata bandeau-niveau-information")
• Article principal (class="bandeau-section metadata bandeau-niveau-detail general") avec l'image intégrée à la classe.

Cdlt. --Ideawipik (discuter) 1 mars 2020 à 10:48 (CET)

od†n: Le préload utilisé par le bot est là: Wikipédia:Le Bistro/préchargement. --Framawiki ^✉ 1 mars 2020 à 12:25 (CET)

Le paramètre "position=section" est de toute façon à implémenter dans le modèle "final" {{Confusion}}, qui appellera le méta-modèle {{Méta bandeau de section}}. En gros c'est comme dans le modèle {{Article général}}, par exemple. À propos, il devrait y avoir moyen de réaliser de la factorisation de code entre {{Méta bandeau de note}} (encore à propos, j'aime pas ce « note » dans le nom du modèle…) et {{Méta bandeau de section}}, je crois que FDo64 est déjà au courant de cela.

Et effectivement, avant de supprimer le paramètre "nohr" des modèles, et les paramètres "titre" vides des modèles "bandeau de section", j'attends déjà de voir si FDo64 aurait éventuellement des précisions à apporter.

od†n ↗^blah 1 mars 2020 à 15:31 (CET)

 Od1n et Ideawipik : Bonsoir, je viens de voir vos messages. Je vous reviens d'ici demain soir. --FDo64 (discuter) 1 mars 2020 à 21:42 (CET)

 Od1n et Ideawipik : Finalement déjà quelques réponses :

• modèle {{Article principal}} : corrigé.
• modèle {{Article général}} : la différence d'icone sera corrigée lorsque les notes seront intégrées au module. Il faudra d'ailleurs que je regarde un jour les icônes n'utilisant pas une class.
• paramètre "titre" vide : c'est un loupé de ma part.
• factorisation : oui, et il faut pour cela que tout soit fait dans le même module.

--FDo64 (discuter) 1 mars 2020 à 23:12 (CET)

• J'ai supprimé les paramètres "titre" vides, normalement tout est traité.
• J'ai supprimé un bon paquet de paramètres "nohr". Avec une recherche insource:nohr insource:/nohr/ (qui ratisse large, avec quelques faux positifs), on est passé sous la barre des 30. Il reste donc encore un peu à nettoyer, mais ce n'est pas insurmontable. J'ai quand même trouvé une utilité au paramètre "nohr" : pour afficher des exemples de bandeaux, par exemple dans des discussions. Néanmoins, c'est peut-être plus joli sans la barre, mais ce n'est pas le vrai rendu du modèle. Et surtout, je pense qu'il est quand même préférable de complètement supprimer le paramètre (penser aux contributeurs qui ajoutent les modèles dans les articles, avec l'éditeur visuel).

od†n ↗^blah 2 mars 2020 à 03:11 (CET)

Je viens de réaliser ceci : 168007513. Cela permet que les exemples de bandeaux ne soient plus "collés" au texte se trouvant au-dessus. od†n ↗^blah 2 mars 2020 à 03:44 (CET)

 FDo64 : Si tu en as le temps et la motivation, pourrais-tu te charger d'ajouter le mode "position=section" au modèle {{Confusion}} ? J'ai évidemment déjà regardé pour le faire moi-même, mais j'ai constaté que pour les icônes il y a actuellement tout un tas de méthodes qui cohabitent (keyword avec classe CSS pour image background, nom de fichier, balise de fichier complète…). Du coup, je ne voudrais pas empirer la situation, et je pense que ça sera plus propre/maintenable si c'est toi qui le fais. od†n ↗^blah 4 mars 2020 à 02:21 (CET)

 Od1n : C'est prévu, normalement ce soir ou demain. --FDo64 (discuter) 4 mars 2020 à 13:47 (CET)

 Od1n et Ideawipik : J'ai mis en place l'évolution du module et tenté une factorisation dans {{Article général/Bac à sable}}. Elle n'est pas encore concluante. On voit dans {{Article général/Test}} qu'il y a un problème d'alignement de l'icône et du texte. À creuser donc… --FDo64 (discuter) 4 mars 2020 à 18:53 (CET)

Si on compare {{Article principal|Agriculture}} (implémentation déjà existante, avec {{Méta bandeau de section}}) et {{Article général/Bac à sable|Agriculture|position=section}} (ton bac à sable, avec {{Méta bandeau}}), les markups sont effectivement très différents :

Comme l'implémentation "bandeau de section" en Lua semble déjà exister, ne faudrait-il pas la réutiliser ? Je pense à ce code pour {{Méta bandeau}} :

{{#ifeq: {{{forme|}}} | section
  | {{#invoke:Bandeau|bandeauSection}}
  | {{#invoke:Bandeau|bandeau}}
}}

On peut faire plus élégant, mais si le résultat est bon et que ça fait avancer le chantier c'est déjà super. L'essentiel est que le code des modèles finaux soit bien factorisé, on pourra toujours nettoyer le code des méta-modèles et du module après. od†n ↗^blah 5 mars 2020 à 06:13 (CET)

Bonjour  FDo64 et Od1n
C'est sûr qu'en utilisant la même fonction du module qu'actuellement ie bandeauSection pour les sections et bandeau pour les haut de pages, on aura un rendu identique à l'existant. C'est aussi le plus simple dans l'immédiat. Si on veut vraiment tout factoriser en utilisant la fonction bandeau du module, comme a tenté de la faire FDo64, cela doit être possible. Il existe déjà un paramétrage pour les sections dans cette fonction. Voilà l'explication des décalages qui viennent du méta-modèle {{Méta bandeau}}. Il y a les mêmes décalages (problématiques ?) dans les exemples sa documentation.

• Origine du décalage vertical : le paramétrage des paragraphes dans les classes qui nous intéressent. Illustration en regardant ce que fait concrètement le modèle
  
• Origine du décalage horizontal observé. Il provient de l'espace demi-cadratin   inséré par le modèle et qui sert(/servait?) à être positionné entre l'image et le texte quand l'image est(/était?) insérée dans un autre div à gauche du texte.
  Cet espace n'est pas ajouté par le modèle quand l'image est insérée via une classe dans un bandeau de haut de page, mais il l'est dans un bandeau de section.

Bandeau haut d'article, proposition actuelle <div class="homonymie plainlinks" style=""><div class="bandeau-cell general"><p>Texte</p></div></div>

Texte

Bandeau haut d'article, sans balise p idem en retirant les balises de paragraphe

Texte

Bandeau de section, proposition actuelle<div class="bandeau-section bandeau-niveau-information plainlinks"><div class="bandeau-cell general"><p>&#8194;Texte</p></div></div>

 Texte

Bandeau de section, sans balise p et sans &#8194;

Texte

Pour voir l'alignement vertical en couleur <div class="bandeau-section bandeau-niveau-information plainlinks" style="background:blue"><div class="bandeau-cell general"><p style="background-color:red">&#8194;Texte</p></div></div>

 Texte

Avec les balises p, c'est la présence de la classe "bandeau-cell" qui impose un margin-bottom:0 à la dernière entité p contenue dans le div de classe bandeau-cell. Par contre le margin-top est non nul. Avant de faire une modification de fonction du module, il faudrait établir tous les cas de figure de bandeaux faisant appel au module et saisir toutes les subtilités d'insertion en rapport aussi avec les classes CSS utilisées (first-child, last-child .class+.class...), et avec les 2/3 façons différentes d'insérer les icones.

--Ideawipik (discuter) 5 mars 2020 à 12:50 (CET)

 Od1n : Bonjour, cela ressemble à une excellente idée ! Je l'ai heureusement testée dans {{Méta bandeau/Bac à sable}}, pour me rendre compte que ça ne fonctionne pas dans deux cas : les mises en forme particulières (un seul cas : {{Presse}}), et les bandeaux avec une partie collapsible (c'est le cas de {{Section à sourcer}} que l'on voit dans {{Méta bandeau/Test}}. Sur ce deuxième cas, il y a une proposition de ma part dans sa page de discussion laissée sans réponse.

Réponse écrite avant le message de  Ideawipik.

--FDo64 (discuter) 5 mars 2020 à 12:56 (CET)

 FDo64. Le problème que tu rencontres avec les modèles qui utilisaient auparavant la fonction bandeau du module avec l'option forme=section et maintenant la fonction bandeauSection du module vient encore d'un caractère d'espace   ajouté avant le texte qui est problématique quand le "texte" commence par un <div class="mw-collapsible mw-collapsed">. Pour s'en convaincre comparer les deux codes HTML suivants.Ne pas se fier à la position des images, j'ai triché!

et

Dans son fonctionnement, la fonction bandeau ne met pas cet espace et inclut le texte dans un div propre sans problème.

Plus généralement, faut-il revoir un cahier des charges des bandeaux histoire de clarifier les choses et les paramètres du méta-modèle principal. Y aurait-il un intérêt, pour une quelconque fonctionnalité, de distinguer des paramètres forme et position. Avoir des options forme=note et forme=section est un peu hybride. Non? --Ideawipik (discuter) 5 mars 2020 à 19:02 (CET)

À propos, je pense qu'il serait bien de faire sauter le <p> généré par le {{Méta bandeau}}. D'expérience, ce genre de <p> rajoute énormément de complications pour le CSS / la mise en page, et comme c'est déjà assez compliqué comme ça… (comme je dis, « avec div, pas de surprise »). od†n ↗^blah 6 mars 2020 à 01:13 (CET)

 Od1n et Ideawipik : Bonsoir, j’ai beau chercher, je ne trouve pas de balise <p> dans le module. Uniquement des balises <div>. Il faut dire que je n’ai jamais caché mon incompétence en Lua .

Histoire d’avancer, je pense mettre en place des solutions non factorisées pour les modèles {{Redirect}}, {{Redirect confusion}} et {{Confusion}}.

J’hésite dans le nom du paramètre : faut-il position=section comme dans {{Article général}} ou section=oui comme dans {{Sans source}} (et bien d’autres). Je préfère le deuxième parce que c’est juste un booléen, donc pas besoin d’un ifeq.

--FDo64 (discuter) 6 mars 2020 à 23:48 (CET)

mobile

Bon début de semaine à tous, je m'incruste un peu vu les tâches à réaliser. Je suis tombé sur cette page MediaWiki Recommendations for mobile friendly articles on Wikimedia wikis l'an dernier et il me semble que si le module doit être retravaillé, il devrait prendre en considération les éléments présents sur cette page. Plus particulièrement la section Making page issues (ambox templates) mobile friendly. Je lirai toute la discussion demain, désolé si je fais doublon. Lofhi (me contacter) 2 mars 2020 à 01:39 (CET)

Rendu actuel

Je ne sais pas si c'est lié mais il y a un gros espace quand il y a deux bandeau et pas de séparation alors que c’était le cas auparavant, exemple sur Titanic, qq a une solution ? -- Nemo ^Discuter 6 mars 2020 à 22:41 (CET)

Bonsoir Nemo Le Poisson . Je laisse  Od1n répondre, il me semblait qu'il avait modifié le common.css pour éviter cela. --FDo64 (discuter) 6 mars 2020 à 23:48 (CET)

Bonsoir Nemo Le Poisson. Pas certain mais j'ai un petit pressentiment que la différence pour le positionnement vertical est en partie lié à ce diff car on réduit désormais la marge du haut uniquement pour le premier élément (div) présent et pas pour les suivants. Si c'est cela, ce serait à mettre aussi en rapport avec le code suivant qui devrait prendre en compte le nouveau margin-top

   .homonymie + .homonymie {
	margin-top: calc(-0.5em - 1.05px); /* -margin-bottom - (1px + léger excédent) */
}

Peut-être que je dis des bétises.  Od1n ?

Pour info, le source actuel ressemble à peu près à cela

::<div id="" class="homonymie plainlinks bandeau-entete-label" style=""><div class="bandeau-cell">[[File:Article de qualité.svg|15px]]</div><div class="bandeau-cell">
<p>&#8194;Vous lisez un «&#160;article de qualité&#160;».
</p>
</div></div>
<div id="" class="homonymie plainlinks" style=""><div class="bandeau-cell">[[Fichier:New_disambig.svg|20px]]</div><div class="bandeau-cell">
<p>&#8194;Pour les articles homonymes, voir Titanic (homonymie).
</p>
</div></div>

Le rétablissement d'une classe "bandeau-cell bandeau-icone" (à coder dans le module) pour le div de l’icône permettrait d'aligner horizontalement les textes à coté des icônes comme ce qui suit. Serait-ce mieux ?. Qu'entends-tu par « pas de séparation » ? À tout hasard Nemo, aurais-tu une capture d'écran ? Cdlt. --Ideawipik (discuter) 7 mars 2020 à 00:27 (CET)

Vous lisez un « article de qualité ».

Pour les articles homonymes, voir Titanic (homonymie).

• Il y a effectivement trop d'espace au-dessus du bandeau AdQ. C'est parce que dans le HTML généré de cet article il y a un <p> vide, et du coup ça rend ce nouveau CSS ineffectif… :\
  • Corrigé, en espérant ne pas avoir à répéter ce genre de rustine…
• Il y a effectivement trop d'espacement entre les deux bandeaux. C'est dû au <p> dans le 2^e bandeau. Je vous l'ai dit, les <p> ça met la pagaille !
  • C'est un effet de bord de cette modification.
  • Corrigé aussi, et idem, je suis toujours attristé quand il y a complexification du code…

od†n ↗^blah 7 mars 2020 à 01:19 (CET)

C'est nickel maintenant ! Au niveau d'une séparation, je parlais d'une barre ____________________________ entre AdQ et homonymie mais en fait ça donne bien comme ça. -- Nemo ^Discuter 7 mars 2020 à 10:42 (CET)

Merci Od1n , tu as en plus corrigé le problème de factorisation (c'est à dire, la solution initiale sans passer par bandeauSection). --FDo64 (discuter) 7 mars 2020 à 14:08 (CET)

Néanmoins, avec l'utilisation des icônes background dans 2 types de bandeaux très différents, il ne me parait pas souhaitable de réutiliser les mêmes ajustements "background-position de quelques pixels". Les bandeaux étant différents, les ajustements seront eux aussi différents. Il serait donc nécessaire dans le Common.css d'avoir des ajustements différents selon le type de bandeau.

Et comme ça va devenir bien lourd en quantité de CSS, la question d'externaliser via des TemplateStyles pourrait à nouveau se poser ;)

C'est là où je vois l'intérêt d'avoir une base de code propre : car après, on peut très facilement faire des remaniements.

od†n ↗^blah 8 mars 2020 à 01:47 (CET)

Edit : à la réflexion, comme dans les 2 cas on aura le même contenu, généralement une icône et une ligne de texte, il n'y a pas de raison pour que le décalage vertical de l'icône diffère. Je veux dire que si les bandeaux sont bien réalisés, pour les 2 types de bandeaux on aura normalement le même positionnement vertical de l'icône par rapport au texte. od†n ↗^blah 8 mars 2020 à 18:18 (CET)

┌─────────────────────────────────────────────────┘
Bonsoir, j'ai réécrit les 4 bandeaux qui doivent pouvoir avoir comme forme note ou section. Je considère donc cette discussion achevée et je l'ai fermée.

Dans le cas d'une réécriture du module et des classes, travail que je ne saurai faire, je veux bien aider pour une éventuelle migration. --FDo64 (discuter) 8 mars 2020 à 23:23 (CET)

Bonsoir.

1. Ce sont ces décalages verticaux dont tu parles, Od1n ? Voir deux premiers exemples plus bas, modèles « Article général » et « Confusion » avec |position=section. Actuellement, dans le premier cas l'image est introduite par la classe "general" et l'espace avant le texte généré par un &#8194; dans le second cas, l'espace (ou plutôt l'alignement) est défini par la classe "bandeau-icone" du div contenant l'image. La différence vient de l'existence de la classe correspondant à l'image (paramètre icone) dans Common.css et Module:Bandeau/Class et un traitement particulier dans le module.
   Question que l'on peut se poser. Pour simplifier les choses, qu'est-ce qui serait le plus propre ? :
   • créer des classes pour chaque image que l'on souhaite utiliser (un nombre limité)
   • ou bien modifier le module pour traiter toutes les images de la même façon, dans un div dédié en s'affranchissant des classes définies précédemment.
2. Une question pourrait aussi être :Que souhaite-t-on pour deux bandeaux : voir conservés les espaces entre image et texte ou avoir des débuts de textes alignés sur une même verticale ?
3. Le début de cette section commence par le constat que la classe "homonymie" est souvent utilisée à mauvais escient. C'est encore le cas à chaque fois qu'on utilisera le module avec la fonction « bandeau » et l'option forme=note (ce qui correspond à utiliser le méta-modèle {{Méta bandeau de note}}, comme sur les deux derniers exemples ci-dessous). Est-ce ce qui est souhaité ?

--Ideawipik (discuter) 9 mars 2020 à 01:01 (CET)

(message rédigé avant de voir la réponse d'Ideawipik)

Comme on peut encore le voir dans mes exemples plus haut, les markups sont différents (et causent des petites différences d'alignement) :

le premier :

<div class="bandeau-section bandeau-niveau-information plainlinks">
<div class="bandeau-cell general">
...contenu...
</div>
</div>

et le deuxième :

<div class="bandeau-section metadata bandeau-niveau-information general">
...contenu...
</div>

Il faudra donc travailler le module de sorte à uniformiser les markups générés.

réponse rapide à Ideawipik : je parlais de la différence entre bandeau de note et bandeau de section, pour un modèle donné.

od†n ↗^blah 9 mars 2020 à 01:51 (CET)

Un autre souci, c'est qu'avec les icônes en background CSS, il n'est pas possible d'ajouter un lien sur celles-ci ; en l'occurrence vers Aide:Homonymie dans un certain nombre de cas. Je pense à deux solutions :

• faire en background CSS pour tous les bandeaux, en supprimant donc ces liens
• implémenter un mode "icône avec lien", permettant d'utiliser une icône en image classique et avec un lien ; un mode qui resterait "acceptable" mais qui serait à utiliser seulement lorsque nécessaire (tradeoff fonctionnalité vs qualité du code)

od†n ↗^blah 10 mars 2020 à 00:23 (CET)

Après avoir remarqué un défaut d'espacement dans un bandeau de section, où l'espacement icône-texte était trop grand (en raison d'un CSS ".bandeau-icone{width:45px}" qu'il recevait inopinément), j'ai essayé d'arranger un peu la codebase (uniformisation markups, fiabilisation CSS, etc). Voir mes modifs sur Module:Bandeau et MediaWiki:Common.css. Mais franchement, je n'en suis pas vraiment satisfait… Le module est un peu simplifié, les résultats sont un peu plus propres et harmonieux, en revanche le CSS s'est un peu complexifié. Le problème est que les classes sont génériques et on les retrouve un peu partout, du coup il est délicat d'effectuer des modifications ciblées, qui iront uniquement impacter les bandeaux que l'on veut et rien d'autre. C'est surtout la pagaille au niveau de la gestion des icônes… od†n ↗^blah 13 mars 2020 à 05:36 (CET)

Bonjour Od1n. On pourrait par exemple utiliser cette page existante pour tester les différents types de bandeau selon les cas de figure. Il y a déjà quelques cas, à partir des possibilités offertes par le module. L'affichage de certains bandeaux, qui possèd(ai)ent l'image en background par la classe et avaient un texte sur l’icône a déjà été amélioré depuis la semaine dernière. Pour la diffusion partielle des bandeaux dans l'encyclopédie, on a Aide:Liste des modèles de maintenance.--Ideawipik (discuter) 19 mars 2020 à 13:01 (CET)

New template using Wikidata

Hi All,

Sorry for writing in English. If you can, please have a look at my proposal and contribute with your opinions: en:Wikipedia:Village_pump_(proposals)#Connecting_Wikipedia_articles_to_reliable_sources_through_new_template

Thanks, --Adam Harangozó (discuter) 23 février 2020 à 15:34 (CET)

2020 -> L'Éditeur Visuel casse encore et toujours nos infoboxs !

Pour info, Discussion Projet:Infobox#2020 -> L'Éditeur Visuel casse encore et toujours nos infoboxs ! en espérant qu'on trouve une solution... -- Nemo ^Discuter 26 février 2020 à 10:54 (CET)

Bandeau

Je constate que les bandeaux tels que les ébauches prennent beaucoup moins de places car l'explication se met sur la même ligne. Je ne sais pas à quoi c'est dû mais je trouve ça très bien, ils prenant beaucoup trop de place avant ! -- Nemo ^Discuter 17 mars 2020 à 17:48 (CET)

Ah, c'est un effet non prévu, et je ne suis pas encore allé chercher quelle est la cause. C'est peut-être lié à mes modifs, peut-être lié à d'autres. Pas encore d'avis sur le meilleur résultat ; ça prend peut-être moins de place en hauteur, mais le retour ligne permet une meilleure distinction. od†n ↗^blah 19 mars 2020 à 02:26 (CET)

Plutôt d'accord avec Nemo : un bandeau légèrement plus discret est préférable (en tête d'article, il est suffisamment mis en exergue). Quant à la « meilleure distinction », la mise en gras de la première phrase fait déjà le job. — Ariel (discuter) 19 mars 2020 à 07:37 (CET)

Bonjour Od1n . En consultant Aide:Liste des modèles de maintenance on constate que le saut de ligne a aussi été supprimé, à de rares exceptions que je n'explique pas, dans les bandeaux d'avertissements. --FDo64 (discuter) 19 mars 2020 à 09:16 (CET)

Saut de ligne normalement rétabli. Une fois de plus, illustration qu'il va falloir éradiquer ces <p> automatiques… od†n ↗^blah 20 mars 2020 à 01:12 (CET)

Modèle:Browsebar, renommage

Que pensez vous d'un rennomage du modèle:Browsebar ? Ne donner pas votre avis ici, mais sur la page de discussion associée. -- Nemo ^Discuter 20 mars 2020 à 11:14 (CET)

{{Date de décès}}

Bonjour,

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

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

Bonsoir Eru C'est déjà le cas puisque ce modèle utilise {{date}} et donc Module:Date. Il devrait suffire de lui transférer ce paramètre. --FDo64 (discuter) 23 février 2020 à 23:16 (CET)

Oui, on pourrait s’embêter à ajouter ce paramètre à la main comme julien, puis le suivant, puis le suivant...

Autant mettre une fois pour toute : <includeonly>{{#invoke:Date|modeleDate|mort=1}}</includeonly><noinclude>{{Documentation}}</noinclude> — eru ^[Discuter] 24 février 2020 à 08:03 (CET)

Bonsoir Eru Malheureusement ça ne fonctionne pas. J'ai aussi tenté sans succès :

{{#invoke:Date|modeleDate|mort=1|âge={{#if:{{{5|}}}|oui}}|qualificatif={{{7|}}}}} mais la date de naissance n'est pas utilisée.

{{#invoke:Date|dateInfobox|mort|1={{{4|}}} {{{5|}}} {{{6|}}}|2={{{1|}}} {{{2|}}} {{{3|}}}|qualificatif={{{7|}}}}} : rien ne va.

Si tu arrives à mettre au point quelque chose dans le bac à sable, je veux bien le mettre en place ensuite.

--FDo64 (discuter) 24 février 2020 à 22:48 (CET)

Effectivement c'est plus compliqué que je pensais, j'aurais dû tester avant, je reviens vers vous quand j'ai trouvé une solution. — eru ^[Discuter] 24 février 2020 à 23:05 (CET)

┌─────────────────────────────────────────────────┘
Pour l'instant je n'ai trouvé que cette solution, le résultat est correct, mais l'âge est toujours géré via l'appel au modèle {{âge}}.

Voir la page de test.

Il faudrait surement modifier la fonction modeleDate du module Date pour pouvoir automatiser le calcule, l'utilisation de la fonction dateInfobox modifie l'affichage des dates juliennes — eru ^[Discuter] 29 février 2020 à 11:34 (CET)

Bonsoir Eru . Pour information, j’ai corrigé la page de test et simplifié le bac à sable. Peux-tu me confirmer que c’est correct ?

Pour ce qui serait de faire évoluer le module, je ne sais pas faire.

--FDo64 (discuter) 3 mars 2020 à 22:53 (CET)

Merci FDo64 , mais en mettant qualificatif= les testes ne fonctionnent plus à part le 5, c'est pour ça que j'avais été obligé de remettre tous les paramètres.

En faite le paramètre qualificatif ne fonctionnait pas pour modeleDate, il prenait toujours les arguments 4 ou 5 même si vide.

Je me suis re-penché dessus et j'ai trouvé ce correctif, les arguments n'étaient pas dans le bon ordre.

Cependant du coup le test 5 ne fonctionne plus, ce qui oblige cette modification...

Bref je revérifierais demain si je trouve une solution plus simple, mais pour l'instant je ne comprend pas pourquoi params.qualificatif = args.qualificatif or params.qualificatif ne fonctionne pas.

Le test 17 permet de vérifier que cela n'impacte pas le modèle {{Date de naissance}}.

Pour la modification du module afin de calculer l'âge, je ne pense pas que cela vaille le coup, le principal est que la date prenne tous les paramètres. — eru ^[Discuter] 4 mars 2020 à 00:13 (CET)

Bonsoir Eru . J'attends donc. Par contre, vu que le test 12 ne fonctionne pas, il faudra bien indiquer que la syntaxe simplifiée ne fonctionne pas avec deux dates. --FDo64 (discuter) 4 mars 2020 à 00:33 (CET)

Oui, le modèle {{âge}} ne support pas ce type de paramètre, il faudrait que le tout soit en lua.

J'ai trouvé comment calculer l'âge en lua en ajoutant un paramètre dateNaissanceMort, mais je dois encore gérer tous les cas. — eru ^[Discuter] 4 mars 2020 à 08:39 (CET)

┌─────────────────────────────────────────────────┘
Bonjour FDo64 , je pense que c'est stable avec ces modifications du module date et du modèle.

Tous les testes semblent fonctionner (à part du 19 au 25 et les 30 & 31, puisqu'il s'agit d'erreur de syntax, mais au moins maintenant l'affichage est correcte).

J'ai également ajouté des testes au module {{Date de naissance}}, tous semblent fonctionner correctement.

Il faut par contre bien laisser 4= et non qualificatif=, sinon et si le qualificatif est dans un autre argument (le 2 principalement) il est ignoré. — eru ^[Discuter] 6 mars 2020 à 17:36 (CET)

Bonsoir Eru . Malheureusement, je n'ai pas de bonnes nouvelles. J'ai d'abord constaté des régressions sur la page Modèle:Date/Test : 1) dans le test 9 on perd "mars", 2) dans les tests 74 et 76 on a une redirection pour Jour de la révolution. J'ai ensuite comparé la version actuelle avec le bac à sable pour constater que tu es reparti d'une ancienne version . Il faudrait donc recharger la version actuelle dans le bac à sable et reporter tes modifications, puis voir si cela corrige les différences constatées. --FDo64 (discuter) 10 mars 2020 à 18:12 (CET)

Effectivement je ne l'ai pas réinitialisé avant et je n'ai pas pensé à regarder ces tests, je vais m'en occuper dans la semaine — eru ^[Discuter] 10 mars 2020 à 18:43 (CET)

┌─────────────────────────────────────────────────┘
Bonjour FDo64 , j'ai synchronisé avec le code en production mardi, cela a corrigé le problème de redirection, et je viens de trouver l'erreur qui faisant échoué le test 9 : diff

Je ne trouve plus d'erreur dans les 3 tests. — eru ^[Discuter] 13 mars 2020 à 18:35 (CET)

Bonsoir Eru . Je regarde ça dès que j'ai suffisamment de temps. --FDo64 (discuter) 13 mars 2020 à 18:46 (CET)

Pas de soucie, rien d'urgent. — eru ^[Discuter] 13 mars 2020 à 18:49 (CET)

Bonsoir Eru . Module et modèle mis à jour. N'hésite pas à me contacter en cas de problème. --FDo64 (discuter) 23 mars 2020 à 22:51 (CET)

Merci FDo64 , j'ai ajouté républicain=liens sur une page au hasard pour voir, pour l'instant je ne vois pas de soucie. — eru ^[Discuter] 23 mars 2020 à 23:19 (CET)

wikidata

Bonjour,

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

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

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

Bonjour, L’article « Catégorie:Modèle de bandeau de section » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). Après avoir pris connaissance des critères généraux d’admissibilité des articles et des critères spécifiques, vous pourrez donner votre avis sur la page de discussion Discussion catégorie:Modèle de bandeau de section/Suppression. Le meilleur moyen d’obtenir un consensus pour la conservation de l’article est de fournir des sources secondaires fiables et indépendantes. Si vous ne pouvez trouver de telles sources, c’est que l’article n’est probablement pas admissible. N’oubliez pas que les principes fondateurs de Wikipédia ne garantissent aucun droit à avoir un article sur Wikipédia.

Accéder au débat

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

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 ^tm. La 2e syntaxe utilise à peine 4 caractères de plus pour le même rendu, mais rends ce texte modifiable par les deux modes d'édition, au lieu de le réserver au mode wikicode qui demande plus d'expertise (pas tout à fait réservé, il reste possible de faire quelque chose avec l'EV, mais c'est lourd et pénible). 空 (discuter) 9 mars 2020 à 14:25 (CET)

Il me semble que sur de longs articles, le cumul de modèles pose des problèmes de perfs ET d'affichage même des modèles à partir d'un certain nombre. Il y a clairement des modèles dont on peut se passer. Par ailleurs, je trouve pertinent le commentaire 空 sur le fait qu'il faille connaître les différents modèles, si on veut les corriger ou les changer. — Daehan ^[p|d|d] 9 mars 2020 à 14:52 (CET)

Je suis d’accord avec les remarques de 空 et Daehan.

Par ailleurs la Wikipédia en anglais recommande à ses utilisateurs de substituer ({{subst:}}) le modèle équivalent pour afficher les balises sup à la place. — Thibaut (discuter) 9 mars 2020 à 15:23 (CET)

En cherchant un peu je n'ai toujours pas trouvé de recommandation, mais j'ai vu passer ça, qui disait en 2017 "L'usage des balises HTML n'est ni recommandé, ni non recommandé" (NB : dans le cas spécifique évoqué par cette discussion, c'était wikicode vs. balise, pas modèle vs. balise - dans ce cas, il me semble que le wikicode devrait primer, et que c'est ce que l'on constate dans les faits). Toujours sur le bistro, cette discussion et la remarque de Thibaut120094 m'inspirent un argument supplémentaire : les modèles ne sont pas nécessairement internationaux, les balises, si, ce qui facilite donc les traductions. Le modèle {sub} existe sur en.wp, par exemple, mais pas {exp} (qui est traduit par {sup} sur en.wp, notre modèle {sup} sur fr.wp n'ayant rien à voir). Les modèles {2} et {3} ne veulent pas dire la même chose d'un wiki à l'autre. 空 (discuter) 9 mars 2020 à 15:40 (CET)

Je n'utilise pas l'éditeur visuel, je suis donc incompétent en la matière. L'avantage des modèles, c'est qu'ils sont documentés (plus ou moins bien) directement sur wp. --Ypirétis (discuter) 9 mars 2020 à 16:34 (CET)

Pour la documentation : une solution est de faire comme sur en:Template:sup : signaler la syntaxe html dans la documentation du modèle correspondant.

Sinon ça m'a toujours surpris de voir utiliser un modèle pour une simple substitution, l'argument de la charge système est évident, mais je n'ai aucune idée de comment le quantifier, et donc je ne sais pas s'il est concluant. L'apprentissage par imitation (ce que nous avons probablement tous fait parmi les participants à cet échange) fonctionne tout aussi bien pour les quelques rares balises html (ça ne demande pas de connaître le html), et ça ne me semble guère concluant non plus. Par contre, s'il est avéré que les balises html fonctionnent mieux avec l'éditeur visuel, là ça paraît assez décisif. Proz (discuter) 9 mars 2020 à 17:51 (CET)

Mon point de vue (qui n'engage que moi et ne cherche à rallier personne), c'est que MediaWiki est un CMS, avec sa propre syntaxe, et que celle-ci n'est pas le HTML, mais le Wikicode. Et les modèles font partie de la syntaxe Wikicode. L'exemple qui me vient est le cas d'une balise type <center>. Alors certes, ce n'est pas trop pertinent car cette balise n'a pas lieu d'être dans l'espace principal mais quand même : cette balise est utilisée un peu partout dans le wiki, et là, paf, elle devient obsolète. Les syntaxes ayant utilisé le modèle correspondant {{Centrer}} peuvent être mises à jour sur l'ensemble des pages en un seul clic. Celles utilisant la balise HTML sont toujours en place. Les modèles permettent de déléguer la syntaxe HTML à un bout de code externe, qui peut être mis à jour si cette même syntaxe évolue, change, doit être mise à jour. Si demain on décide que les exposants et les indices doivent utiliser une mise en forme CSS et non plus HTML : le modèle peut être changé rapidement, les balises non.

Après, n'ayant pas la moindre expérience avec l'éditeur visuel, je ne me prononcerai pas sur ce point, et effectivement sa syntaxe est à prendre en compte à un moment ou a un autre, mais il faut garder à l'esprit que celui-ci est également toujours en mouvement et en développement.

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 10 mars 2020 à 08:09 (CET)

Insister lourdement finirait probablement par être contre-productif, je me bornerais donc à constater une dernière fois que les arguments en faveur des modèles (Ypirétis / Les modèles sont documentés (encore faut-il savoir où), ou Epok / Les modèles factorisent la syntaxe et facilitent la mise à jour (même si, étant protégés, ils sont moins facilement accessibles au tout-venant)) sont des arguments de spécialistes déjà installés sur wiki, et ne répondent pas au problème de l'accessibilité aux nouveaux. Les balises "sup" et "sub" dont il est question sont assez universelles sur le web, elles sont plus faciles d'emploi que les balises "ref", elles ne sont peut-être pas "documentées" comme le sont les modèles, mais taper "<sup>" dans la barre de recherche envoie sur Sup où cette syntaxe est clairement expliquée. Et au risque de me répéter, la syntaxe est invisible quand on utilise l'éditeur visuel (comme le font la majorité des nouveaux), sauf quand il y a des modèles, qui empêchent la modification directe. Vous pouvez jeter un œil dans les RCs aux modifs taggées "éditeur visuel basculé" pour constater combien de ces modifs (où un contributeur a commencé en mode EV, mais a dû basculer en mode code) impliquent des modèles. Ou même juste regarder les modifs taggées "éditeur visuel" pour constater à quel point il est utilisé par les nouveaux contributeurs. S'il y a un truc à garder à l'esprit, je pense que c'est plus l'accès pour tous à la modification. Emalquier le faisait remarquer sur le bistro il n'y a pas une semaine (et Trizek semblait se désoler qu'il ne soit pas prêté plus d'attention à son message) : l'ergonomie sur Wikipédia n'est pas idéale, et je trouve dommage de handicaper l'un des rares trucs (l'EV) qui facilite vraiment la modification pour les nouveaux. 空 (discuter) 10 mars 2020 à 10:03 (CET)

Voui, mais le html, ça donne aussi ça : À Durban, la température moyenne est d'environ 21 °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)

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, pour rappel, il y a aussi {{TradRef}}, qui a la même fonction que {{Traduction/Référence}} en étant beaucoup plus pratique. — Daehan ^[p|d|d] 10 mars 2020 à 13:16 (CET)

C'est vrai que c'est pas mal, on pourrait rendre obsolète (via un bandeau) {{Traduction/Référence}} ducoup... @FDo64 Je suis aussi pour une fusion des modèles dans la limite du possible ! -- Nemo ^Discuter 17 mars 2020 à 15:46 (CET)

Bonjour. Deux remarques:

• Je ne vois pas en quoi {{TradRef}} est beaucoup plus pratique que {{Traduction/Référence}}. Niveau syntaxe, c'est kif-kif.
• Pour le nom du modèle : avoir le terme « Référence » ou « Ref » dans le nom permet de rappeler au rédacteur qu'il doit le placer dans la section « Références », si cette pratique n'est pas remise en question. Ce mot permet aussi de réduire un peu la confusion possible avec le modèle {{Traduit de}} réservé aux pages de discussion. Pas contre un renommage du type {{Crédit d'auteurs/TradRef}} mais sans être convaincu de l'intérêt et conscient du nombre de "corrections mineures/cosmétiques" que cela engendrerait. --Ideawipik (discuter) 17 mars 2020 à 17:04 (CET)

Modèle:Article mentionné par la presse

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. n^o 43, version du 27 décembre 2019). D'avance, merci. --ContributorQ^(✍) 19 mars 2020 à 20:08 (CET)

Bonjour ContributorQ. C'est sûr que c'est assez bizarre de créer un modèle par copier-coller depuis enwiki sans vérifier que la version francophone dispose des fonctions (modules) nécessaires à son bon fonctionnement. Si on garde le code du modèle en l'état, il faudrait créer WLink et String2 et vérifier que le module String existant fonctionne comme escompté, par rapport à la version enwiki. Mais une autre possibilité pourrait-être d'adapter le modèle, si le module ne s'avère pas indispensable. Cela demande juste un peu de temps pour étudier le fonctionnement général. À suivre prochainement. --Ideawipik (discuter) 19 mars 2020 à 23:52 (CET)

Merci pour cet éclairage. J'aurais bien effectué la correction, mais mes compétences en Lua sont très limitées et je n'ai pas envie de les approfondir pour si peu. 312 articles sont touchés. --ContributorQ^(✍) 20 mars 2020 à 15:43 (CET)

Bonjour ContributorQ. En fait, le module WLink (du enwiki) n'est pas indispensable. Il suffirait d'une seule fonction comme celle intitulée « ansiPercentEncoder » seulement locale dans Module:Classement musical/Données. La seule modification, nécessaire pour la présente application, du code de cette fonction serait de remplacer un + par un - dans la substitution d'espace. La fonction appelée dans le module String2 peut être remplacée par un simple {{lc:…}} donc pas besoin de ce module. L'appel de la fonction « replace » du module String est déjà fait par un autre moyen dans la fonction « ansiPercentEncoder » et est donc dispensable. Faut-il créer un module BillboardURLbyName juste pour héberger cette fonction ? La réponse à cette question dépend des autres besoins de conversions dans l'ensemble des modèles. Il existe d'ailleurs peut-être déjà un tel module-bibliothèque équivalent à WLink. Quelqu'un le sait-il? Dans tous les cas, le code du présent modèle pourra être simplifié. --Ideawipik (discuter) 20 mars 2020 à 16:39 (CET)

Les appels au module « String2 » peuvent, en effet, être remplacés par des appels au modèle spécial « {{lc:...}} ». Il reste quand même du boulot, notamment des tests... --ContributorQ^(✍) 20 mars 2020 à 19:57 (CET)

Quasi-doublon de modèles pour mise en colonnes

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 26 juin 2018. 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

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)

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)

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)

Et aussi Wikipédia:Pages à fusionner#Modèle:Inédit et Modèle:Passage inédit -- Nemo ^Discuter 15 avril 2020 à 11:00 (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)

Modèle:Catégorie principale

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)

┌─────────────────────────────────────────────────┘
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é :

• {{Tex}} -> {{TeX}}
• {{Aud}} -> {{Audio}}
• {{Xml}} -> {{XML}}

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}}.

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)

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és et ceux qui traitent jusqu'à 4 cas : /Modèles liés, /Références liées, /Catégories liées et /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és contiennent 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)

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 :

Palette corée du nord avec le modèle liste horizontale qui crée un bug 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:normal dans {{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)

┌─────────────────────────────────────────────────┘
 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 (2^e 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 :

1. 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-horizontale est 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.
2. 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-horizontale dé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)

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 :

1. Rhinoceros (Rhinocerotidae)
2. Rhinoceros (Diceros)

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)

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 :

1. 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).
2. 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;
3. 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.
4. 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 :

1. 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 ;
2. pas d'ajout de paramètre et une utilisation du paramètre déjà existant. On perdrait l'avantage précédent ;
3. 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  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 :

Test {{Élu}}

Période		Identité	Étiquette	Qualité
Début	Fin	Identité	Parti	Test modèle {{Élu}} actuel
Début	Fin	Identité	Parti	Proposition avec box-shadow:
Début	Fin	Identité	Parti	Proposition avec box-shadow:

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 :

1. 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é).
2. 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=non pour 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=oui ou Couleur=CODE pour l'activer. Couleur=oui se baserait sur les couleurs de {{Infobox Parti politique français/couleurs}}. On peut aussi imaginer des paramètres pays-spécifiques.

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éfinis^Remarque.. Cela éviterait d'avoir des paramètres inopérants couleur=oui dans 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=non et activable si besoin par un Couleur=CODE valide – ce dernier ayant la priorité sur le fonctionnement par défaut –. En relisant, c'est la #2a me semble-t-il.

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.
  1. On n'a pas besoin d'entrer les dates. Cela dit, ces dates ne changent pas tous les quatre matins.
  2. 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 ?)
  1. La présence des liens internes pour les années de naissance et de mort me semble superflue (point de vue personnel).
  2. 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 « (-) »
  3. 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…).
  4. Si on utilise le modèle pour un article existant mais qui n'a pas d'élément Wikidata associé, alors apparaît un gros message d'erreur.
  5. 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.
  6. 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 :
  1. 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.
  2. 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.

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)

Module:Biblio/Références

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)

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)

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)

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=dec mais elle n'est pas satisfaisante ici.
• Les paramètres coordinates du 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).

Autres solutions envisageables sans recourir au modèle Coord2 :

1. Soit ajouter un paramètre optionnel au modèle Coord pour obtenir un formatage en degrés décimaux.
2. Soit permettre au modèle « Carte de localisations multiples » d'accepter aussi les coordonnées exprimées en DMS.
3. 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)

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||}} → 4 ou {{Naissance décès âge||22|05|2000|4|9|}} → 4 septembre , 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}}

Ç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 1^er octobre 2020. 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 2^e. 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 2^e 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)

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).

Voir Discussion Projet:Modèle/Archive 2020#Utilisation du modèle Liste horizontale sur la Palette Corée du Nord.

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)

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:

Dans ce style (je ne sais pas non plus faire de beaux tableaux... désolé )

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)

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)

 Xfigpower : merki Nonopoly (discuter) 2 novembre 2020 à 14:21 (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)

Modèle:Style

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)

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)

Merci Eru et FDo64 , c'est exactement ce qu'il fallait ! Vous avez des exemples dans Boutxy et Pyros. -- -- El Caro ^bla 30 décembre 2020 à 09:36 (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 Jobs^1,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 (1986-2006) et The Walt Disney Company (depuis le 5 mai 2006)

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)

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)

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 %22 ou " 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)

┌─────────────────────────────────────────────────┘

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)