Il y a déjà plusieurs semaines que j'ai remarqué ce fait. Dans un premier temps, j'ai pensé que cet infobox n'était pas prévu pour légender les photos jusqu'à ce que je consulte la documentation. Ce jour, j'ai créé l'article Skidmore College. J'ai fait plusieurs essais en prévisualisions mais je n'ai pas réussi à légender la photo.
Est-ce qu'il serait possible de supprimer définitivement l'affichage de l'image dans l'infobox depuis Wikidata ? Il y avait déjà eu une longue discussion à ce sujet[2], et il y a encore actuellement au bas mot 90 % des articles qui aujourd'hui ont des images en[3]. L'infobox indique le logo, mais il n'y a aucun intérêt à afficher un bâtiment au hasard. Cdlt, XIII,東京から[何だよ]21 février 2021 à 12:14 (CET)
Création Infobox - Club de tir à l'arc
Bonjour, travaillant sur le Projet:Tir à l'arc, et ayant l'occasion de créer/modifier des pages de club, j'ai remarqué que l'infobox Club sportif n'est pas parfaitement adapté aux besoins de ce sport. Je pense notamment aux exemples suivants :
Impossible d'afficher le nombre de licenciés.
Impossible de déclarer des infrastructures (qui ont parfois des centaines d'années), sans avoir le label "stade :" devant. Alors que le tir à l'arc se pratique rarement dans un stade (hors compétition).
Impossible de déclarer le "capitaine" et le "lieutenant" pour les compagnies d'arc (club qui sont crées depuis très longtemps et ont un statut particulier).
Le terme "Joueur le plus capé" qui ne s'applique pas ici puisqu'on parle d'archer et non de joueur.
Pouvoir déclarer les affiliations qui sont parfois multiples : FFTA, FFH, UFOLEP ...
Le label donné par la fédération française.
Le "Roy" du club ou de la compagnie
...
Ce sont les premières raisons auxquelles j'ai pensé, mais il y en a sûrement d'autres.
L'Aide:Créer une infobox m'oriente donc vers cette page pour demander votre avis avant de créer une infobox. Je souhaiterai donc avoir des retours avant de pouvoir créer une infobox "Club de tir à l'arc".
--Nhhi (discuter) 2 mai 2020 à 16:23 (CEST)
Bonjour,
Une proposition de fusion est proposée entre ces deux modèles, avoir des avis serait précieux pour savoir si cette fusion est pertinente. Nouill6 février 2021 à 19:28 (CET)
Impossible d'afficher un drapeau dans une infobox
Bonjour à tous,
Dans l'infobox de l'article Emil Walter, on remarque que l'affichage du drapeau de la Catalogne produit une erreur. J'ai essayé de bidouiller l'élément Wikidata mais rien à faire. Pouvez-vous m'aider ?
Merci. Je voulais le faire moi-même mais ne trouvais pas comment faire. En fait, je m'aperçois que c'est codé en dur dans un fichier ? Je suis surpris, j'aurais pensé que le programme regardait sur Wikidata s'il y avait un article en français, et mettait sinon un lien vers l'article en anglais ou dans une autre langue ? 82.124.78.228 (discuter) 18 août 2021 à 02:11 (CEST)
Shev123 : J'ai tenté une correction, ça s'affiche visiblement mieux. Mais comme j'ai modifié divers éléments et corrigées au passage d'autres problèmes syntaxiques dans le code, je ne suis pas certain à 100 % d'où ça venait.
Mais je pense que cela devait probablement venir des valeurs 2 passées au paramètre positionnel 5 de différents appels à {{Infobox/Ligne mixte optionnelle}}.
Ce paramètre sert à faire une fusion de colonnes sur la partie droite. Mais il ne me semble pas (après une vérification rapide) qu'il y ait des cas de lignes avec 2 colonnes de valeurs.
Il y a 2-3 autres petits points à vérifier pour le bon fonctionnement de ton infobox, mais comme le problème ne pouvait pas venir de cela, je n'ai pas approfondi en l'état.
J'ai testé sur quelques situations appelant certains paramètres spécifiques de https://wstat.fr/template/info/Infobox_Combin%C3%A9_nordique, mais comme ton modèle fait appel à Wikidata, difficile de déterminer quels articles utilisent certains champs de l'infobox, et de vérifier leur bon fonctionnement.
Mais comme l'infobox n'est utilisé que sur 25 articles, j'ai appliqué mes modifications en l'état. Le risque de dommages étendus étant limité.
Est-ce que tu remarque un problème sur certaines pages ? Si oui, n'hésite pas à corriger ou révoquer mes modifs. Je n'ai pas eu le temps d'approfondir immédiatement le fonctionnement de cette infobox. Je le ferais plus tard ce soir ou demain.
J'ai détecté plusieurs modèles dont le nom commence par Projet:Infobox. En voici la liste.
Le problème avec les modèles dont le nom commence par Espace de noms: est que cela complexifie leur utilisation. En effet, si l'on souhaite inclure l'un de ces modèles, il est impossible d'utiliser leur nom brut, car l'espace de nom présent au début du nom du modèle préempte l'utilisation de l'espace de noms Modèle: par le logiciel MediaWiki . Par exemple, il est impossible d'écrire, comme pour tous les autres modèles, {{Projet:Infobox/Didacticiel infobox modulaire ex mod compl}}, il faudra obligatoirement apposer le préfixe Modèle: : {{Modèle:Projet:Infobox/Didacticiel infobox modulaire ex mod compl}}. Le même problème existe si l'on utilise le modèle {{m}} pour y faire référence. Voyez comme il affiche un lien rouge : {{Projet:Infobox/Didacticiel infobox modulaire ex mod compl}}.
Ces 3 modèles (et leur doc) étant quasiment les seuls concernés (il n'y en a qu'un seul qui ne soit pas lié à ce projet, et deux avec l'espace de nom Wikipédia:), je propose qu'ils soient renommés. Une modification simple serait de remplacer le : entre Projet et Infobox par une espace, pour éviter la confusion de MediaWiki due à ce pseudo-espace de noms.
Bonjour Epok. Autre question, avant de leur chercher un nom. Ces modèles sont-ils utiles ? Sans avoir pris le temps de regarder, j'ai comme l'impression qu'il s'agit de brouillons de modèles déployés tel {{Infobox Protéine/Caractéristiques espèces}}.
Ils semblent aussi utilisés pour l'aide (didacticiel) à la création de certains types d'infobox : Projet:Infobox/V2#Programmation d'une infobox modulaire. Cependant cette aide, ancienne devrait être mise à jour, à partir d'un exemple de modèle existant dans l'espace des modèles. Ce serait plus simple. D'autre part, existerait-il un synonyme de « modulaire » qui permettrait d'éviter une confusion avec les modules de MediaWiki, espace de nom réservé à la programmation en Lua ? Les modèles V2 dont il est question dans le didacticiel ne reposent pas forcément (ou plutôt reposent rarement directement) sur du code en Lua. Autre subtilité, quelle est la différence entre une aide et un didacticiel ? Enfin, s'il faut privilégier la création d'infobox V3 par rapport aux infobox V2, faut-il conserver cette partie de l'aide très peu consultée (Modèle:Projet:Infobox/Didacticiel infobox modulaire ex mod princi : 0 vue dans les 30 derniers jours ; idem pour …ex mod compl) ? — Ideawipik (discuter) 26 septembre 2021 à 23:55 (CEST)
Bonsoir Epok. Ces modèles sont des bacs à sable qui datent de la préhistoire (avant que je n'arrive sur Wikipédia ). Peut-être que la meilleure solution serait de les supprimer.
HelloIdeawipik et FDo64, merci pour vos réponses. Je propose donc de procéder à la suppression de ces modèles plutôt qu'à leur renommage. Au vu du nom et de leur utilisation par cette page, j'avais la vague impression qu'ils étaient utile pour le projet, mais si ce n'est pas le cas, zou ! Si pas d'objection, je les supprime d'ici quelques jours.
Que faire lorsque d'une infobox renvoie à une illustration qui n'a aucun sens dans le contexte donné ? Exemple : l'article RuSHA en français comporte l'infobox organisation2 ; la carte qu'elle comporte n'a aucun sens durant la période donnée : je m'explique, proposer une carte actuelle pour un article traitant d'une organisation disparue en 1945 ne se justifie pas, sachant que les frontières légales de l'Allemagne en 1945 sont celles définies au (pour mémoire, à cette date, l'Autriche fait partie du Reich, les Sudètes aussi, la Yougoslavie est un état indépendant et les frontières orientales de l'Italie ne sont pas celle d'aujourd'hui), ou celles de 1940 ou de 1944. On peut discuter pendant des jours sur le choix d'une carte, rendant compte des frontières en 1930,1939, 1940 ou 1944, mais proposer une carte de 2000 pour une organisation dissoute en droit en 1945 est clairement anachronique. Que faire alors pour résoudre cette erreur (et d'autres, par exemple celle-ci : dans ce cas, la géolocalisation est correcte, mais pas la situation stratégique, la double monarchie, les frontières allemandes, tant à l'Est qu'à l'Ouest...)?
Sur cet article : Francis Bardot, qui fut apparemment Vénérable Maître d'une loge maçonnique, je vois dans l'Infobox un lien vers l'article anglophone Vénérable. Cela me semble étonnant car premièrement il existe l'article Vénérable en français, deuxièmement aucun des deux articles anglophone ou francophone ne semble parler de Vénérable maître dans une loge, mais parlent de Vénérable dans la religion catholique, ce qui semble bien différent... Il faudrait à mon avis tout bonnement supprimer le lien. Ou le modifier... 92.151.90.73 (discuter) 26 octobre 2021 à 07:42 (CEST)
Modifications sur Infobox Livre, Ouvrage, Pièce de théâtre, etc.
Bonjour à tous,
Suite à ce message sur le Bistro littérature, il semble apparaître qu'une case "lire en ligne" dans les Infobox d'oeuvres écrites libres de droit (cela concerne donc évidemment Infobox Ouvrage et Livre, mais ça peut s'étendre à toutes les infobox concernant une oeuvre écrite précise) soit justifié. Je réitère mon exemple : cela consisterait à modifier l'infobox de Les Trois Mousquetaires en mettant un lien vers le texte sur Wikisource. L'idéal serait que cette case soit directement reliée à Wikisource quand le lien vers celui-ci est déjà présent dans "Voir aussi" ou mieux via Wikidata, cependant il faudrait que l'on puisse mettre manuellement un lien vers Gallica ou autre car tous les textes ne sont pas sur Wikisource. Avez-vous des idées pour réaliser ça efficacement ?
Je notifie ceux qui ont répondu sur la précédente discussion : @VIGNERON, @Koreller et @Lorlam
Paramètres du modèle:Infobox Organisation2 non documenté
Bonjour,
Le modèle {{Infobox Organisation2}} a été introduit de manière systématique dans un peu plus de dix mille articles généralement par des personnes ne contribuant pas à ceux-ci en supprimant des modèles spécifiques. Le résultat est souvent très mauvais (lacunaire / non pertinent) car s'appuyant sur wikidata. Si en tant que contributeur on veut améliorer la situation on tombe sur un double mur :
Si on souhaite effectuer cet enrichissement dans wikipedia, il n'existe aucune documentation. Or les paramètres sont très nombreux. N'étant pas listés, leur mode d'emploi n'est évidement pas documenté alors que leur utilisation dépend du type d'organisation.
Si on souhaite passer par Wikidata ... avez vous déjà essayer d'alimenter wikidata avec le niveau de compréhension d'un wikipedien moyen ?
J'ai déjà soulevé le problème sur le bistro sans réponse à ce jour. Il me semble qu'on a affaire dans le cas présent à une forme de vandalisme. Aussi si aucune documentation n'est créée et/ou que wikidata n'améliore pas de manière substantielle l'ergonomie de l'écran de saisie des paramètres (ce qui inclue a minima pouvoir lister les paramètres dans une fenêtre déroulante et disposer d'un commentaire expliquant leur utilisation), je supprimerais à chaque fois que je le rencontrerais le modèle concerné.--Pline(discuter)27 mai 2021 à 21:49 (CEST)
Bonjour
Je pense qu'il y a plusieurs points dans la discussion.
Premièrement, Infobox Organisation2 n'est pas documenté et c'est très mal. On peut faire un effort là dessus pour que le fonctionnement soit transparent. Je vais essayer de regarder dans les prochains jours.
Deuxièmement, Wikidata est très complexe. Même quand on est expérimenté, il y a toujours de l'ambiguïté (est ce qu'il faut qualifier telle organisation d'entreprise ou de firme ? Est ce qu'il faut utiliser la propriété partie de ou filiale de ?). Wikidata est très général et il semble illusoire d'en réduire la complexité à court terme.
En revanche, ça n'est pas pour ça qu'il faut jeter l'infobox Organisation2. En effet, même avec une infobox en Lua, on peut toujours écrire la valeur des paramètres en dur dans Wikipédia si la valeur de Wikidata est aberrante.
Personnellement, je trouve l'infobox Organisation2 très utile et je n'ai pas eu de mauvaise expérience avec des valeurs insatisfaisantes. PAC2 (discuter) 28 mai 2021 à 21:03 (CEST)
Bonjour Pline, PAC2 et Dom. Une ébauche de TemplateData a été mise en place à partir du code du module. L'exhaustivité n'est pas assurée, en raison de l'existence de nombreux paramètres communs aux infobox. Cela devrait néanmoins permettre d'y voir un peu plus clair dans les paramètres valides lors de la prochaine analyse de dépôt (dump) sur wstats.fr (lien donné plus haut). Une relecture et des compléments (descriptions et exemples) seraient grandement appréciés. — Ideawipik (discuter) 30 mai 2021 à 02:11 (CEST)
Merci ! Ideawipik, PAC2 et Dom Quelques questions sur la documentation générée :
Pour certaines données il existe plusieurs types de paramètres. Faut-il privilégier le paramètre en gras ? Ou sont ils tous utilisables ?
Certains paramètres dépendent du type d'organisation me semble t'il. Cela n'apparait pas dans la documentation générée ?
Bonjour Pline. Mon intention était de commencer le développement de la documentation et de relever des paramètres valides. J'en ai immanquablement oublié et compte sur PAC2 qui s'est proposé pour améliorer la documentation.
Les noms de paramètres sont des alias et ont le même rôle. Il n'y a pas vraiment de raison d'utiliser l'un plutôt qu'un autre. L'usage d'une dénomination est généralement liée au type d'organisation. Par contre, il faut veiller à ne pas avoir en même temps deux alias du même paramètre (parfois, même vide) dans un appel de modèle car un des deux prendrait le pas sur l'autre. Le paramètre en gras est celui qui me paraissait plus naturel, il ne correspond pas toujours au paramètre prioritaire.
Paramètres dépendant du type d'organisation. Oui, c'est le cas, du moins dans le fonctionnement par défaut. Cela est difficilement documentable dans le TemplateData (index de paramètres). Voir plutôt l'ajout d'exemples types pour quelques organisations ou une petite explication.
Quant à l'association entre paramètre et donnée Wikidata. Il y a deux cas :
des paramètres optionnels pour lesquels l'infobox ne récupère pas de donnée Wikidata (utilisation exclusivement lors de l'appel du modèle : paramètre=…), par exemple notation.
des paramètres pour lesquels la donnée récupérée n'est pas une simple propriété (attribut) de l'élément Wikidata mais une donnée en relation avec l'élément, de façon plus ou moins complexe. Par exemple, pour « président d'honneur » ou « vice-président », la relation est assez simple et a été indiquée. Pour d'autres, elle l'est moins. Si quelqu'un veut prendre le temps de davantage décortiquer la chose, il est remercié par avance.
@Ideawipik Bonjour, J'ai rajouté les explications fournies dans la documentation du modèle avec mon niveau de compréhension en tentant d'être compris du plus grand nombre. N'hésitez pas à corriger le tir ! --Pline(discuter)31 mai 2021 à 14:12 (CEST)
Une possibilité est de rédiger une "double documentation" : une fonctionnelle et pratique, rédigée comme on le souhaite et indépendamment, dans une boite déroulante, le TemplateData (dont la description des paramètres n'autorise pas la présence de liens) conservé pour l'outil d'insertion des modèles via l'éditeur visuel et pour les outils de maintenance vérifiant la validité des paramètres des modèles (fonction dans WPCleaner, wstats, etc.) qui pour être fiables requièrent une telle liste à jour. Ainsi, je ne vois pas trop l'intérêt d'inonder les description: des paramètres dans le TemplateData par les numéros des propriétés Wikidata (Pxxxx). Ou alors, peut-être, dans les default: ?
Autant il est relativement facile de renseigner et de maintenir à jour les documentations des modèles classiques, avec un peu de rigueur de la part des modélistes, autant il est plus complexe de le faire pour les modèles basés sur des modules Lua dont une modification peut parfois avoir des répercussions dans de nombreux modèles.
Pline. J'ai lu votre ajout. Parler de « code » n'est pas très clair. Préférer les mots « paramètre » pour le modèle et « propriété Wikidata » (ou « élément » ou « donnée ») pour ce qui relève de WD. L'exemple des alias domaine, discipline, secteur… n'était pas approprié car le libellé dans le rendu de l'infobox est toujours « domaine d'activité » ou « domaines d'activité ». Dans ma réponse ci-dessus, il fallait lire que l'existence des alias (noms de paramètres) est justifiée par des raisons de moindre surprise pour les rédacteurs. Techniquement, les alias sont complètement interchangeables. Des « pas de donnée WD correspondante » ont été ajoutés à la documentation pour les paramètres propres à l'infobox dans Wikipédia. La formulation est éventuellement à revoir.
Je vois deux visions possibles pour la documentation, en ce qui concerne les paramètres importés depuis Wikidata (WD) :
une orientée Wikipédia, indiquant pour chaque paramètre valide du modèle quelle donnée WD est utilisée par défaut ;
une orientée Wikidata incitant les contributeurs à renseigner dans WD les éléments relatifs aux organisations afin qu'ils apparaissent dans les infobox (voir l'exemple donné dans le premier point du présent message).
Un large consensus a voté pour la fusion de ses deux Infobox. Or, nous avons trouvé personne pour fusionner ses deux Infobox, les rares ayant tenté ont jeté l'éponge. Quelqu'un peut-il nous aider ? Cela nous enlèverait une sacrée épine du pied. Amicalement. MenthePoivrée • 20 juin 2021 à 01:13 (CEST)
En modifiant la page Roland Brisset j'ai remarqué l'horrible Jusqu'en 22 décembre 1643.
Le problème vient de p.floruit dans Module:Infobox/Fonctions/Personne qui appel complexdate.daterange avec en paramètre des dates obtenues via wikidata.formatAndCat.
Ces dates sont passées brute, via upto, à setprecision dans Module:Date complexe, celui-ci ce contentant de faire un tonumber sur la date qui renvoie donc toujours 0, d'où le texte erroné dans upto.
Bref, je n'arrive pas à trouver quoi mettre pour corriger cela, je pense que le mieux serait de modifier p.floruit pour passé une table à setprecision, mais je ne trouve pas comment.
j'ai remarqué que de nombreux articles - notamment biographiques - ne sont pas recensés dans Catégorie:Article à illustrer et ses sous-catégories à cause de la présence dans le paramètre "image" de Fichier:Defaut.svg. Avec Modèle:Infobox Biographie2 par contre, elle sont comptabilisées, et une image apparait automatiquement quand elle est présente sur Wikidata (sinon, il y à Fichier:Defaut 2.svg). Serait-il à votre avis possible et utile de modifier les autres modèles (j'imagine qu'il y en a beaucoup...) afin qu'ils fonctionnent de la même manière, ou au moins de supprimer "Default" pour que ces pages soient plus facilement identifiées comme à illustrer ? Merci. --Skouratov (discuter) 6 août 2021 à 13:50 (CEST)
Bonsoir Skouratov. Serait-il possible d'avoir un exemple ? Parce que pour les Infobox V2 la catégorisation se fait également avec defaut.svg ou defaut 2.svg.
Pour ce qui est de « supprimer "Default" », je vois régulièrement la demande inverse. Certains voudraient le généraliser.
En fait, c'est quand j'ai fait cette modif. En testant sans image en prévisualisation, l'article est inclus dans Catégorie:Article à illustrer Personnalité du cinéma, et pas avec default ou évidemment maintenant avec la photo que j'avais trouvé en anglais (mais qui dans ce cas là, n'est pas sur Wikidata...). Je ne suis pas contre la généralisation de default, mais pour que ces fichiers soient comptabilisés comme une absence d'image. Si ça n'est pas possible, on pourrait se contenter d'un bot qui enlèverait default quand une image existe sur Wikidata, si ce n'est pas déjà le cas. Et pour bio 2 je me suis trompé : c'est la même chose en fait ! --Skouratov (discuter) 10 août 2021 à 00:51 (CEST)
Les V3 ont juste une brique : {{Infobox V3/Image}} et rien ne permet d'indiquer que l'image est optionnelle. Il n'y a donc pas de test de présence.
Il est possible de catégoriser les Infobox Lua, mais ça ne fonctionne que s'il n'y a aucun fichier. Il faudrait qu'un développeur Lua teste la présence de defaut.svg ou defaut 2.svg comme le fait {{Infobox/Image}}.
OK, merci. Ça reste donc assez compliqué pour le moment. Je vais me contenter pour le moment d'une requête bot pour identifier les articles ayant "default" en Infobox et une image sur Wikidata. --Skouratov (discuter) 10 août 2021 à 08:58 (CEST)
J'ai fait la requête, à laquelle Ideawipik (d · c · b) a répondu rapidement avec cette page (encore merci !). Vous pouvez la vider, en supprimant ou "default" en le remplaçant par l'image indiquée (ce n'est pas automatique pour toutes les infobox), sachant qu'il y a sûrement des exceptions (photo peu pertinente, problème de licence (?)...). --Skouratov (discuter) 12 août 2021 à 13:55 (CEST)
Résoudre le problème de disparité des noms de paramètres valides pour l'image alternative (accessibilité)
Le problème concerne les paramètres permettant d'ajouter une description alternative pour l'accessibilité des images (cf Images (accessibilité) ou Bonnes pratiques (images)). Dans le fonctionnement actuel, bien souvent (notamment dans de nombreuses infobox en Lua) un seul nom de paramètre est valide pour cette information (pas d'alias de paramètre) et il varie selon le modèle.
Bref, c'est du cas par cas avec parfois heureusement des alias autorisés. On rencontre encore dans les articles des paramètres « légende alternative » invalides.
Comme premièrement le nom du paramètre varie d'un modèle à l'autre, deuxièmement les documentations sont souvent manquantes ou incomplètes, sans TemplateData, troisièmement il n'est pas aisé de vérifier si le paramètre a un effet*, on se retrouve avec un nombre conséquent de valeurs renseignées, avec l'effort du contributeur, mais non prise en compte par le modèle car le nom du paramètre n'est pas le bon.
Un autre réalité est le remplacement d'un type d'infobox par un autre, qui semble plus approprié pour l'auteur de la modification. Mais comme le paramètre n'a pas le même nom dans la nouvelle infobox, il devient invalide/inutilisé. Pour ces raisons, une harmonisation des noms ou au moins la prise en compte de plusieurs alias semble indispensable. * Sauf à aller lire le code source de la page. Même le gadget Accessibilité ne signalera pas le problème, le modèle mettant par défaut une valeur générique « Image dans Infobox ».
Précaution : il faut toutefois garder à l'esprit que potentiellement un modèle peut avoir un paramètre portant un de ces noms pour autre chose que cette description (par exemple aujourd'hui, dans {{Infobox Espace vert}}, alt pour l'altitude et dans {{Infobox Torero}}, alternative pour l'Alternative (corrida) ; peut-être à changer !). Le nom « alternative image », semble à la fois clair et distinctif (aussi par rapport aux autres « alternative logo » et consorts dans un même modèle). Il pourrait être généralisé par défaut dans tous les modèles, comme « accès url », commun à plusieurs modèles bibliographiques, est réservé à cet usage. Le seul petit inconvénient est la longueur de la chaîne. En réalité, peu importe le nom mais il est préférable d'un avoir un nom de paramètre commun, valide dans tous les modèles du même type. Et peut-être à terme, un unique nom, pour la moindre surprise.
Pour pallier ce défaut, plusieurs idées, dans les infobox Lua :
Quelque part dans Module:Infobox (re)définir une "donnée locale du modèle" 'alternative image' dans le tableau des paramètres, avec le contenu d'un des alias valides (liste à définir) avant l'appel des autres fonctions et ensuite, ne se servir que de cette donnée. Mauvaide idée.
Plus simple et proche du fonctionnement actuel définir la listes des noms de paramètres dans la fonction mainimage de Module:Infobox/Fonctions, par exemple : remplacer altparameter=args.altparameteror'alternative image', par altparameter=args.altparameteror{'alternative image','alternative','alt'},. Mais cela reste risqué (cf paragraphe précédent) et n'ajouterait pas d'alias pour les modèles pour lesquels altparameter est défini en amont, il est préférable de plutôt spécifier les alias dans chaque module spécifique, utilisé dans un seul modèle (ou un petit nombre de modèles). D'où la proposition suivante
De façon plus localisée, dans chaque modèle et module spécifique. Par exemple pour Module:Infobox/Monument, remplacer building.mainimage('Article à illustrer Monument'), par building.mainimage({cat='Article à illustrer Monument',altparameter={'alternative image','alternative','alt'}}),, si l'on souhaite autoriser ces trois alias.
Dans les infobox classiques, définir un paramètre principal, conserver les autres comme alias et actualiser les documentations et TemplateData.
Parallèlement, on peut envisager que les bots et outils qui passent fréquemment dans les articles, se chargent au fil de l'eau, en modification cosmétique additionnelle, de remplacer les paramètres pour généraliser l'usage d'un nom unique pour l'encyclopédie.
Salut. J'ai pas bien compris (parce que Lua et moi...) : tu veux remplacer/ajouter des paramètres dans les modèles génériques d'infobox (V2/V3) ou tu veux harmoniser les différents modèles d'infobox ? Si c'est la première question, je vois pas l'intérêt puisque c'est le modèle d'infobox spécialisé qui gère tout seul l'appel du paramètre, si c'est la deuxième question, je ne vois pas comment il est possible d'harmoniser sans l'aval de chaque projet concerné. Dans les deux cas, l'intérêt d'une harmonisation me semble limité tant que la doc est claire et à jour et de toute façon, moins de 1 % des contributeurs sait utiliser correctement l'alternative textuelle, les autres, quand ils l'utilisent, confondent avec la légende. 'toff [discut.]15 août 2021 à 22:20 (CEST)
Bonsoir Ideawipik. Si je m'étais attaqué à ce chantier, j'aurais généralisé l'utilisation du paramètre alternative (qui respecte les recommandations), tout en acceptant l'alias alt.
Pas fan de alternative image qui est trop long, même s'il est plus précis.
Pour ma part pas fan de alternative qui n'est pas assez explicite pour les personnes ne sachant pas de quoi il s'agit. Pourrais-je suggérer aussi alt image ? od†n ↗blah16 août 2021 à 00:21 (CEST)
Pour en revenir à la question que j'ai comprise à posteriori (oui des fois je suis lent), au vu des exemples que tu as indiqués (alt= altitude, alternative=alternative corrida) et si tant soit est que l'harmonisation soit faite en accord avec les projets (j'y tiens), alt n'est pas la bonne solution car elle n'est pas explicite, alt image est mieux mais toujours pas explicite, alternative ne renvoit pas à l'image donc n'est pas explicite non plus. Pour moins, même si c'est long alternative image est le meilleur terme car le plus explicite. Et pour ce qui est de la longueur @FDo64, ça n'est pas plus long que date de naissance ou lieu de naissance par exemple. 'toff [discut.]16 août 2021 à 08:51 (CEST)
Réponse à Supertoff et pour ceux pour lesquels mon premier message n'était pas assez clair. Dans le cas contraire, vous pouvez aller directement au résumé. Parmi le moins de 1% des contributeurs qui connaît l'alternative textuelle et la remplit à l'occasion, il y en a peut-être un tiers qui croit que le seul paramètre à utiliser est celui qu'il utilise systématiquement quelle que soit l'infobox concernée, un tiers qui croit que tous les alias sont équivalents et toujours valides, un tiers qui sait que le paramètre change d'une infobox à l'autre sans forcément savoir lequel est à utiliser dans les modèles non documentés, si tant est que la documentation soit valide. Et donc l'effort d'accessibilité peut rester vain.
Il y a plusieurs façons, à plusieurs niveaux de générer et propager des paramètres "invalides", qu'il soient remplis ou vides,
par une modification volontaire du nom de paramètre d'un modèle mais sans corriger ce paramètre dans les appels du modèle dans les articles ou sans actualiser la documentation.
par inattention d'un modéliste, lors de l'évolution du code d'un modèle comme la transformation d'un modèle classique en modèle Lua.
Dans le code des articles
erreur d'insertion parce qu'on croit le paramètre valide (les 2/3 des 1% mentionnés plus haut et même plus s'il y avait présence dans le wikicode du paramètre erroné vide).
erreur d'insertion parce que la documentation n'était pas à jour. (Si la validité d'un paramètre est relativement facile à établir en lisant le code d'un modèle classique (recherche des {{{<paramètre>), c'est plus complexe pour un modèle qui sollicite plusieurs modules Lua).
par remplacement d'une infobox par une autre, plus "moderne", sans vérifier les paramètres. Déjà que les artisans de ces actions ne vérifient pas toujours une éventuelle perte d'information, dans le résultat affiché lors du passage d'une infobox à une autre. Alors comment repéreraient-il la nécessité de modifier le nom d'un paramètre pour une donnée disponible dans l'article uniquement dans son code source HTML ou dans son wikicode à examiner au regard de la documentation du nouveau modèle ? C'est une des principales raison de la présence de paramètres invalides en tous genres dans les insertions de modèles infobox dans les articles. Deux exemples sont données dans une autre discussion.
par copier/coller et mimétisme depuis un autre article présentant l'erreur.
La question de l'harmonisation est plus vaste qu'une simple question de clochers/infobox. Y a-t-il vraiment une raison objective pour qu'actuellement le seul paramètre valide soit :
« alt » pour une personnalité militaire ou un artiste, « alternative » pour une personnalité du cinéma — cf. Infobox Cinéma (personnalité) —, « alt légende » pour une personnalité politique ;
« alt » pour une société, « alternative » pour une organisation, « alternative image » pour une usine ou un musée ;
« alt » pour une abbaye cistercienne, « alternative » pour un édifice religieux, « alternative image » pour un temple bouddhiste ;
« alternative » pour un lac, « alternative image » pour un plan d'eau ou une chute d'eau ;
etc. ?
Résumé. Une harmonisation avec unicité du paramètre réglerait ces problèmes, faciliterait la vie de tous et donnerait peut-être de la visibilité à ce paramètre. C'est le projet WP:Accessibilité/Atelier accessibilité qui se met des bâtons dans les roues. S'il faut passer par une consultation de la communauté, allons-y. Cela aura le bénéfice de faire connaître un peu mieux les bonnes pratiques à ce sujet.
L'avantage de « alt image » est qu'il ne dénote pas avec le alt= des paramètres de fichiers/images et qu'il contient le « image » qui le rattache au paramètre contenant le nom du fichier (très utile quand il y a plusieurs illustrations). Dans ce cas, il serait bon d'harmoniser aussi les « alternative logo » en « alt logo ». Le choix « alternative image », me conviendrait aussi. Il peut y avoir des alias, ils seront forcément nécessaires, au moins au début de l'action progressive d'harmonisation qui devra commencer par celle des documentations.
Précautions
« alternative » ne convient pas plus pour {{Infobox Biographie2}} que pour {{Infobox Torero}}, il affiche un champ « Alternative » dans la partie « Autres informations » de l'infobox. Voir exemples visuels (jusqu'à correction dans l'article ou dans le modèle) : Léon Poussigue ou Arthur de Buyer. C'est normal ils sollicitent la même fonction : person.torero(). Donc soit on réserve « alternative » comme alias du paramètre dont on parle ici, on renomme le paramètre pour les toreros, avec passage de bot dans les 300 articles liés, soit on éradique pour l'accessibilité le paramètre « alternative » au profit de celui choisi (à choisir). Mais on risque de voir réapparaître, au moins au début, dans d'autres articles ces champs déplacés, par habitude des contributeurs. La première option est bien plus simple, comme suggéré par Supertoff.
« alt » est aussi utilisé dans des modèles de boîtes utilisateur pour un usage différent. Exemple : {{Utilisateur bénévole sur Wikipédia}}. Comme ce type de modèles n'ont rien à voir avec une infobox et ne sont pas destinés à l'espace principal, ce n'est pas problématique. Mais il ne faut pas y toucher. L'information peut être utile aux dresseurs de bots ou pour AWB.
il faudra faire le tour des modèles pour repérer d'éventuels usages particuliers.
Ideawipik : note que je n'ai rien contre l'uniformisation, ni contre l'accessibilité puisque je suis le principal (voire le seul) "spécialiste" de cette dernière (entre guillemets parce que je ne suis pas expert) au niveau du projet hockey sur glace et du projet sport (mais j'arrive à fédérer un peu) Mais au niveau des infobox, c'est souvent un peu crispé quand il n'y a pas de discussion préalable (même si j'espère qu'ici ce ne sera pas le cas). Sinon, l'atelier accessibilité ne se met pas de bâton dans les roues puisqu'il ne gère pas les infobox En ce qui concerne la consultation je suis plutôt pour. D'abord pour ce que je disais plus haut, la communauté dans son ensemble pourra se prononcer sur le terme qu'elle préfère. Ensuite, comme tu l'as dit, ça amènera un peu de visibilité sur l'accessibilité (et on pourra en profiter pour expliquer au passage que l'alternative n'est pas une légende ). Évidemment, les logos sont concernés.
J'avais pensé aussi que plutôt que choisir un paramètre, on pouvait, dans toutes les infobox, mettre toutes les 3-4 formes existantes mais (je ne sais pas pour Lua) je trouve que ça alourdit le code des infobox standard puisqu'il faut imbriquer des #if:. Ca reste cependant une possibilité qui permet de solutionner les problèmes de changement d'infobox.
L'uniformisation serait évidemment très souhaitable. Si on élimine alt et alternative qui ne sont pas assez explicites (n'indiquent pas que c'est en rapport avec l'image), il reste par élimination alternative image.
J'aime bien aussi mon alt image, effectivement qui coïncide avec le nom de l'attribut HTML ; ça pourrait éventuellement être ajouté en alias pour ceux qui veulent un nom plus court, mais pour l'instant, on en est à supprimer des noms de paramètres, pas à en rajouter !
Concernant le alternative de la corrida, j'avais envisagé de le renommer pour éviter les confusions/collisions, mais je ne vois pas par quoi ça pourrait être remplacé… Ça serait dommage de rallonger inutilement en cérémonie d'alternative / confirmation de cérémonie d'alternative, prise d'alternative / confirmation de prise d'alternative…
Ce que je verrais bien, c'est la solution 2 évoquée dans le premier message (la solution 3 serait vraiment laborieuse, et avec une grande répétition de code), en configurant le altparameter dans les infoboxes problématiques (en fait si on traite les quelques histoires avec alt pour altitude, alt légende… il resterait seulement la corrida, où on retirerait le alternative de la liste). Puis tranquillement on migre les articles de alternative et alt (encore une fois en excluant les exceptions) vers alternative image. On pourrait aussi remplacer alternative en alternative image et alt en alt image.
À terme, on pourrait enfin supprimer les noms inutilisés ajoutés lors de la "solution 2", puis les (rares) exceptions implémentées dans quelques infoboxes.
Bonjour, j'ai jeté un oeil à Aide:Insérer une image (wikicode, avancé) qui explique pourquoi ça s'appelle "alternative"" : « description alternative qui décrit brièvement (éviter de dépasser 120 caractères) l'image pour le visiteur n'y ayant pas accès. Une image ne voulant pas ou ne pouvant pas se charger sera remplacée par ce texte ; dans un navigateur en mode texte, c'est ce texte alternatif qui est affiché ; pour les malvoyants, le synthétiseur vocal lira ce texte alternatif. »
Avec cette explication, ce nom de paramètre devient explicite.
Par ailleurs, ceux qui insèrent les images en wikicode ont l'habitude d'appeler ce paramètre alt puisque c'est celui de la syntaxe.
Sinon, on peut proposer description (ou description image) plus explicite et qui se démarque de légende.
Je ne suis pas favorable à "description". Ca n'est pas assez explicite et ça va encore être confondu avec légende à coup sûr. Et "alternative" est le nom exact en matière d'accessibilité, il n'y a pas lieu de changer (pour le coup, c'est se tirer une balle dans le pied côté accessibilité). Et je pense que pour les plus curieux, le mot "alternative" les interrogera plus que le mot "description". 'toff [discut.]17 août 2021 à 12:39 (CEST)
Y a-t-il une infobox pour les compétitions et les concours non sportif ?
Bonjour FDo64 Ça ne me semble pas être adapté non plus, car il n'y a pas de notion de récompense à l'issue d'une compétition, généralement périodique. {{Infobox Distinction}} ne convient pas non plus. La meilleure solution est d'utiliser {{Infobox Récompense}} en ne respectant pas la condition sur la cérémonie artistique qui n'est pas justifiée et qui a souvent été enfreinte. Je pense qu'il faudrait modifier la documentation du modèle sur ce point. -- Dom (discuter) 21 novembre 2021 à 14:13 (CET)
Suppression d'une partie des archives
Bonjour,
j'ai cherché pendant un long moment une vieille archive de demande de création d'infobox sans succès. Finalement, j'ai réalisé que la discussion que je cherchais était cachée dans une version antérieure de l'Archive5 et qu'un bot avait supprimé 172000 octets de cette page. Est-ce normal et devrions-nous annuler cette suppression?
Bonjour ElMagyar, Effectivement ça surprend au départ, mais ce mécanisme d'archivage est général sur beaucoup de pages de discussion. Tu peux même le mettre en place sur ta page de discussion pour qu'il soit fait automatiquement par un bot. Dom (discuter) 28 novembre 2021 à 13:24 (CET)
Je ne suis pas sûr que nous nous soyons bien compris. Je comprends qu'OrlodrimBot (d · c) nettoie régulièrement la page actuelle (Projet:Infobox/Demandes) pour enlever les vieilles discussions et les place dans des sous-pages d'archive.
Ce que je ne comprends pas c'est pourquoi Zebulon84bot (d · c) a supprimé 86% de la page Archive5 créée par OrlodrimBot, ce qui rend de nombreuses anciennes demandes et discussions totalement inaccessibles sans retourner dans les anciennes versions de l'archive elle-même (et non de la page principale). Est-ce que Zebulon84bot les a placées ailleur?
