Dernier commentaire : il y a 10 mois3 commentaires2 participants à la discussion
Bonjour,
Est-ce qu’il serait techniquement faisable sans grosse prise de tête de fusionner Modèle:Infobox Missile dans Modèle:Infobox Arme ? Pour certains types d’armes (torpilles par ex) on a parfois l’une et parfois l’autre parce que ni l’une ni l’autre n’a tous les paramètres qu’il faudrait. En revanche en ayant un même modèle avec juste une charte différente on aurait tous les paramètres nécessaires. Cela serait aussi plus cohérent et plus facile d’usage : pour l’instant pour harmoniser je dois remplacer l’infobox complète alors qu’avec une même infobox il suffirait de changer la charte.
Bonjour @Runi Gerardsen, as-tu un exemple d'article concerné par la problématique ? Et pourrais-tu réexpliquer alors pourquoi dans le cas de cet article cela coince ? Ne décris pas une solution adéquate, mais le problème afin de mieux généraliser à tous les articles ! Lofhi (discuter) 11 mars 2024 à 01:07 (CET)Répondre
Dernier commentaire : il y a 10 mois1 commentaire1 participant à la discussion
Bonsoir,
je souhaiterais savoir si il y a une bonne pratique pour la typographie des valeurs définies dans les champs des infobox ?
Cela dépend sans doute de la manière dont on voit les champs.
Les champs et leurs valeurs sont semblables à un définition « champ : valeur », les conventions typographiques françaises recommandant alors une minuscule à la première lettre de « valeur ».
Néanmoins, je vois des infobox avec des majuscules.
Si les classes des infoboîtes v2 et v3 sont incompatibles, il me semble que la problématique pourrait être réglée en finissant la migration des infoboîtes V2. C'est quelque chose qui a été entamé avant mon arrivée, je ne sais pas si les infoboîtes V2 restantes le sont pour des problématiques techniques ou un manque de mains. Certaines boîtes ont un contenu assez simple et les migrer vers la v3 devrait être suffisant. Les plus complexes devraient sans douter être refaites en Lua. En tout cas, je compte m'y atteler. Il y en a plus de 500. Une par jour... à l'année prochaine ! Lofhi (discuter) 11 mars 2024 à 00:50 (CET)Répondre
En vrai, le mieux serait peut-être une migration totale vers Lua des V2 restantes... mais j'ai toujours eu peur de l'accessibilité de ces infoboîtes par la suite. Lofhi (discuter) 11 mars 2024 à 00:56 (CET)Répondre
En tout cas, il n'est pas question de dégrader l'accessibilité des infobox V3 qui ont été conçues spécifiquement pour ça.
Ensuite : c'est aux projets concernés de décider s'il faut passer en V3 ou en Lua. Il n'est pas question d'imposer sur WP (c'est la base).
Enfin (mais là ce n'est qu'un avis), il n'est pas nécessaire de coder en Lua des infobox codées en langage wiki : les infobox codées en Lua sont encore plus obscures que celles codées en langage "wiki" (sauf pour les informaticiens). Elles sont cependant utiles pour traiter certaines données que le langage wiki se sait pas traiter, mais toutes les infobox n'en n'ont pas besoin. Donc le passage de V2 à V3 semble suffisant parce que dans tous les cas (me semble-t-il), les V3 peuvent faire le même boulot que les V2. Après, si un projet préfère passer à Lua au lieu de V3, c'est le projet qui est décideur 'toff [discut.]11 mars 2024 à 19:20 (CET)Répondre
Il y a peu de raisons, outre l'accessibilité, de continuer à supporter différentes manières de faire. La communauté souhaite certaines choses, c'est bien, mais le nettoyage des modules est certainement plus aisé que le nettoyage de la créativité permise par la flexibilité du wikicode et ses nombreuses particularités-surprises.
Non pas que je souhaite que les infobox ne soient pas accessibles puisque j'ai soulevé le doute, mais depuis mon retour je ne vois plus autant de profils techniques. Ça ne m'inspire pas confiance. Cependant, j'ai aussi l'impression que la communauté a pris le temps de s'habituer à travailler avec Wikidata au lieu de simplement le fuir.
Quitte à faire un gros travail de documentation des modules Lua : les bases peuvent être limpides. J'accepte de dire que pas mal de modules sont sous-documentés.
Aussi, nous sommes dans une ère où Wikifonctions est en développement actif : nul doute que les interactions seront plus évidentes avec Lua. L'informatique est un moyen et non une fin, mais il y a tout de même certaines contraintes qu'il faut rappeler liées à l'agenda de bénévoles... Et la viabilité des solutions adoptées sur le long terme. Lofhi (discuter) 11 mars 2024 à 19:34 (CET)Répondre
Je précise ma pensée : je ne vois pas de raisons de migrer les V3 vers Lua comme précisé hier, mais je ne vois pas de raisons de ne pas migrer les V2 vers Lua. Les modèle restants semblent liés à des thématiques moins sensibles (que par exemple les infobox de biographies) et sont assez stables. La grande majorité pourrait être migrée avec peu de difficultés. Lofhi (discuter) 11 mars 2024 à 19:38 (CET)Répondre
Tu n'as pas saisi ma pensée pour la migration des V2 vers Lua : certains contributeurs savent assurer le suivi et les modifications des infobox en langage wiki alors que Lua est réservé aux programmeurs/informaticiens. C'est confisquer certaines choses au profit d'un petit groupe que de passer en Lua : ceux qui savent programmer en Lua comprennent le langage Wiki; l'inverse n'est pas vrai. Donc non, ce n'est pas à une seule personne de décider s'il faut migrer mais aux projets concernés.
Ensuite, je ne vois pas ce que vient faire Wikidata dans l'histoire ? Wikidata est accessible via langage wiki ET Lua : on essaie toujours d'opposer Lua + Wikidata à Infobox V2/V3 en faisant croire que Wikidata=Lua alors que c'est faux. Exemple d'une infobox V3 qui intègre Wikidata : Modèle:Infobox Personnalité du football américain... 'toff [discut.]11 mars 2024 à 20:17 (CET)Répondre
Il y a trois jours, une autre personne centrale dans la maintenance de notre projet a pris ses distances au moins temporairement alors que la dette continue de s'accumuler au fil du temps et d'autant plus avec le rythme des nouveautés dans MediaWiki. Je dis ça, je dis rien. Soit, allons pour préférer la V3 torturée, mais il ne faudra pas me demander de migrer vers Lua des infobox récemment migrées vers V3. À la base, la migration vers Lua ce n'était pas un plaisir type complexe de Dieu de quelques barbus, c'était pour corriger des problèmes de performances liées à du wikicode torturé jusqu'à l'os. Lofhi (discuter) 11 mars 2024 à 20:41 (CET)Répondre
Je me répète : je ne dis pas qu'il ne faut pas (même si je n'aime pas cette prise en otage de quelques barbus), je dis qu'un individu ne peut pas imposer quoi que ce soit sur Wikipédia qui est une encyclopédie collaborative. Opposer la notion "collaborative" à la notion "ce qui est nouveau est mieux" est complètement contre ce qu'est l'esprit de Wikipédia => si un projet décide que Lua c'est mieux que V2 ou V3, alors Lua c'est mieux. L'inverse est vrai, c'est aussi simple que ça.
Je n'oppose rien du tout, il n'y a pas d'amertume, du tout. Je souhaite seulement que la lourde tâche portée par les plus techniciens du projet soit aussi considérée à un pied d'égalité avec le principe d'accessibilité des modèles. Je préfère aussi des réponses rapides et directes comme les tiennes qu'un vent puis une notification dans 3 mois me disant de tout refaire.
J'ai pris acte pour la migration par défaut vers la V3 des infobox V2 restantes et vers Lua seulement dans les cas où cela fait sens. Cela ne me plaît pas, mais il y a des urgences et je n'ai pas envie de démarrer une prise de décision ou un sondage : les récents exemples de consensus communautaires m'ont un peu donner des haut-le-cœur. V3 ou Lua, j'en ai de toute manière pour des semaines. Lofhi (discuter) 11 mars 2024 à 21:32 (CET)Répondre
Bonsoir Lofhi et Supertoff. Histoire d'être au moins trois à donner notre avis, voici le mien.
J'ai toujours été contre la migration des V2 vers les V3 qui sont mal fichues et difficiles à mettre au point. Dans le cas contraire, il y a longtemps que ce serait fait ! Je n'ai pas changé d'avis.
J'ai aussi été contre une migration vers les infobox Lua parce que, comme le dit Supertoff, ce sont des infobox créées par des informaticiens pour les informaticiens. Ce matin j'ai en partie changé d'avis quand j'ai vu des modules comme Module:Infobox/Artère, Module:Infobox/Chaîne de télévision, Module:Infobox/Cheminée et Module:Infobox/Chute d'eau (je t'invite à les regarder, Supertoff). Au final, je les trouve très lisibles, voire même plus simples. La programmation compliquée se trouvant dans Module:Infobox/Fonctions et ses sous-modules.
Je me sens donc capable de réécrire les infobox simples en Lua, et totalement incapable pour les infobox compliquées.
Pour ce qui est des classes d'infobox, il y en a deux : V2 pour les V2 et V3 pour les V3 et Lua. D'où l'idée de migrer toutes les V2 pour simplifier le CSS qu'il faudrait revoir pour le mode nuit.
J'ai recensé aujourd'hui tous les modules d'infobox et j'en ai trouvé une quarantaine à l'état de prototype. J'en parlerai dans une prochaine discussion.
Pour ce qui est des V2, on parle de plus de 600 modèles donc au final, je ne sais pas ce qui donnera le plus de travail : leur récriture ou l'adaptation du CSS ?
Pour résumer au sujet des V2 : s'il faut choisir entre la peste et le choléra, je préfère le Lua !
C'est quoi le(s) problème(s) avec les migrations V2 vers V3 ? L'adaptation du CSS sera plutôt dans une seconde phase... Mais avec des infobox qui utilisent les mêmes styles, cela devrait grandement simplifier la tâche. Il faut juste espérer une non prolifération des sous-feuilles de styles (TemplateStyles). Merci pour l'avis. Lofhi (discuter) 11 mars 2024 à 23:33 (CET)Répondre
FDo64 : j'ai regardé tes exemples et ça me conforte dans mon idée que ça reste accessible à une minorité : je ne comprends quasiment rien (j'ai compris où sont les commentaires). Même si il faut un minimum de connaissance "informatique" à priori pour s'auto-former au wikicode (ce qui restreint déjà l'accès), apprendre un langage de programmation comme Lua est encore moins évident : le wikicode est très limité et est donc plus accessible. C'est ce qui fait sa force et sa faiblesse (ou inversement). Perso, je me suis auto-formé sur le wikicode, mais je ne me vois pas apprendre un langage informatique comme le Lua, ce qui, de plus, me rangerait avec les barbus
Je pensais exactement comme toi jusqu'à hier au sujet du Lua. Et j'ai partiellement changé d'avis.
Je vais te donner un exemple : autrefois il y avait plus de 5000 modèles de bandeaux d'ébauches. On a réussi à tous les supprimer en les remplaçant pas un seul module qui contient toute la programmation (donc maintenable que par les programmeurs Lua) et un sous-module qui ne contient que le paramétrage qui lui est actuellement mis à jour par un peu tout le monde.
Je pense qu'il est possible de faire de même avec les infobox. Dans les exemples que je t'ai donné, il y a moins de programmation que dans une infobox classique. Le langage est différent mais il reste lisible.
Il faut donc pousser les programmeurs Lua à mettre toute la programmation dans les modules "Infobox/Fonctions/xxx" afin que les sous-modules d'infobox soient les plus simples possibles.
FDo64 : tu vois justement là, je ne comprends rien à ce que tu racontes. C'est typique de la problématique... (par exemple "mettre toute la programmation dans les modules "Infobox/Fonctions/xxx"" ???) Et le maintenable que par les programmeurs Lua aurait tendance à me hérisser le poil mais comme je n'ai rien compris, je dois avoir tort. Et sinon, je ne suis pas sûr que les "plus simples possibles" soient suffisants pour les ignares en programmation comme moi. 'toff [discut.]12 mars 2024 à 23:38 (CET)Répondre
Je viens de migrer {{Modèle:Infobox Site web}} vers V3. C'était horrible et long (+ 1h, mais j'imagine que cela sera plus rapide au fil des essais). J'ai dû ajouter un paramètre texte blanc abusivement supporté en V2 à l'aide d'un titre passé avec {{Blanc}}. Je dois repasser sur tous les article qui utilisent l'infobox...
Même en finissant la migration des V2, je pense qu'on aura des emmerdes à cause des règles CSS inlines. Je ne suis pas sûr de vouloir y réfléchir avant de finir les migrations. Peut-être qu'on pourra modifier les modèles fondateurs (par exemple {{Infobox V3/Tableau début}}) pour ajouter violemment des classes CSS si une forme de couleur blanche est détectée (genre #FFFFF)... J'en fais déjà des cauchemars.
Bonsoir Lofhi. Si tu fais des recherches dans le Bistro, tu verras que c'est presque un marronnier...
Il y a plusieurs projets qui tiennent à ces couleurs et ont défini une charte (biographie, communes, sport...).
Il y aura le même problème avec les palettes qui utilisent bien souvent les mêmes chartes.
Mais de ce que j'ai vu dans le lien fourni hier à 17h52, l'urgence n'est pas pour les infobox. Elles sont lisibles puisqu'elles restent en mode jour.
De mon point de vue les problèmes suivants sont plus graves :
Benoît Saint Denis : certaines colonnes des tableaux sportifs sont illisibles. Là c'est dû aux modèles du style {{Récapitulatif MMA}}, et je pense que beaucoup de modèles de tableaux sont dans le même cas.
Lu' FDo64, je n'ai pas compris l'histoire de l'urgence... c'est bien parce qu'on doit se retaper toutes les infobox que j'ouvre la question des couleurs qui sont compliquées à gérer et qui dépassent les affections personnelles. Je n'ai pas spécialement envie qu'on ait besoin de se taper huit vagues de corrections puisqu'on a des milliers d'infobox. Aujourd'hui il n'y a rien de normal puisque tout doit être rediscuté y compris avec la WMF vu que le mode nuit est incompatible.
Aussi, ce n'est pas parce que des couleurs sont fixées depuis 10 ans qu'elles sont accessibles. Et ce n'est pas parce qu'elles sont plus ou moins visibles aussi sur le mode nuit par plus ou moins de chance qu'il ne faut pas privilégier une alternative pensée pour le mode nuit. Certaines choses que tu cites comme déjà corrigées le sont parce que justement la WMF applique des règles par-dessus, voire corrige directement le wiki. Désolé, mais ce orange n'est plus possible, par exemple. Lofhi (discuter) 13 mars 2024 à 23:48 (CET)Répondre
Lofhi : Désolé mais je ne comprends pas ta réponse et je ne suis pas sûr que tu aies lue la mienne. Je ne donne pas mon avis, je t'informe juste que tu auras probablement beaucoup de mal à faire passer ton message. Pour ton information, j'ai écrit des centaines d'Infobox V2 et V3 et j'ai donc déjà rencontré de fortes résistances aux changements.
Tu as posté ton message sur le bistro avec un jour d'avance. Tu verras bien les réactions.
J'ai bien précisé dans mon message que je n'avais pas compris ta réponse ! La question de la couleur est un sujet à traiter parce que nous sommes limités en nombre de mains (cas d'usage problématique après migration de {{Infobox Site web}} : diff) et parce que les couleurs et l'accessibilité est un sujet sérieux dans le développement web qui dépasse les goûts visuels de la communauté. Un résumé simple qui montre que rien que pour les infobox nous sommes en contresens total du point de vue de l'industrie puis des choix adoptés par la WMF : mw:Recommendations for night mode compatibility on Wikimedia wikis. Lofhi (discuter) 14 mars 2024 à 11:51 (CET)Répondre
Ce que j'ai tenté de t'expliquer à travers les 3 exemples que je t'ai fourni c'est que l'urgence hier n'était pas les Infobox. Je vois à l'instant que les problèmes que je signalais ont été en partie réglés. Peut-être par Escargot bleu et cette modification ?
Je constate néanmoins que les wikitables (voir France, par exemple) ont maintenant le même soucis que les Infobox, elle restent en "mode jour".
Pour ce qui est de la réécriture des Infobox V2, je propose une idée peut-être pas si stupide que ça : plutôt que de continuer à faire des Infobox spécifiques, ne suffit-il pas d'enrichir Module:Infobox/Infobox universelle ? C'est surtout vrai pour celles qui sont 100% wikidata et sans doute moins pour celles qui sont compliquées. Si je reprends l'exemple de Module:Infobox/Artère, tout pourrait y être déversé.
Je n'ai pas encore résolu le problème en question avec mes modifications, mais il devrait effectivement être plus simple à résoudre que celui des infobox. Escargot (discuter) 14 mars 2024 à 14:36 (CET)Répondre
Je devrai de toute façon repasser sur ma modification. Les couleurs que j'ai mises pour les tableaux alternance en mode nuit ne rendent pas bien. Ce sont celles issues de l'inversion de la palette des couleurs, et on peut faire mieux.
Et pourtant, c'est le thème officiel. Après si la communauté veut continuer à utiliser des valeurs arbitraires en désaccord total avec les directions choisies par la WMF, très bien... mais qu'on utilise au moins des variables CSS, par pitié. Qu'on reparte sur des bases saines si déjà on doit tout retravailler. Lofhi (discuter) 14 mars 2024 à 20:56 (CET)Répondre
L'idée de l'infobox universelle a été plus ou moins mise en place avec {{Infobox Biographie2}} et n'est pas utilisée par plusieurs projets : elle n'est pas désirée au profit d'une infobox spécifique (elle a même déjà grandement fait débat). Je ne pense pas que ce soit réalisable (voire souhaitable). L'uniformisation a ses limites. 'toff [discut.]14 mars 2024 à 17:45 (CET)Répondre
Supertoff : Pour ton information, cette infobox universelle existe, elle s'appelle {{Infobox}} et utilise le module que j'ai indiqué précédemment.
Pour le coup on commence à tourner en rond. Est-ce qu'on ne pourrait pas se limiter à migrer vers V3 dans la majorité des cas, puis discuter du reste quand le terrain de travail sera plus propre ? Cela va un peu dans tous les sens là. {{Infobox}} me plaît dans l'idée, mais cela reste du Lua et là en plus avec une indirection puisque cela appelle des sous-modules d'infobox Lua.
Migrer une infobox V2 en V3, c'est déjà une galère. On vient par exemple de demander de retirer le titre dans {{Infobox Site web}}, ce qui veut dire qu'on a des infobox qui n'ont même pas la même structure. Je pensais que c'était au moins accepté d'avoir forcément un titre pour un infobox. Lofhi (discuter) 14 mars 2024 à 19:36 (CET)Répondre
Dernier commentaire : il y a 10 mois2 commentaires2 participants à la discussion
Bonsoir,
Pour l'adaptation de {{Infobox Biographie2}} (comme toutes les autres infobox), il va falloir déplacer les couleurs dans des classes.
Ma question est : faut-il définir une seule feuille de classe reprenant tous les cas de Module:Infobox/Biographie/Chartes, ou bien faut-il définir une feuille de style par cas ?
La première solution a l'avantage d'être plus simple à maintenir, mais est moins bonne en termes de performances puisque énormément de styles non utilisés seront chargés. La deuxième est meilleure en performance, mais fait perdre l'avantage que l'infobox avait jusque là d'être simple à maintenir. Escargot (discuter) 16 mars 2024 à 01:16 (CET)Répondre
Je viens de me pencher sur le sujet, voir mes modifs dans MediaWiki:Minerva.css. C'est un enfer d'empilages de styles CSS qui se défont les uns les autres à coup de "!important", principalement à cause de styles rajoutés par la skin Minerva qui sont absolument infects, mais dans nos styles locaux aussi on a quelques empilages un peu bazardesques. À cela s'ajoute la difficulté que pour chaque situation (desktop, mobile) il faut déterminer quels fichiers sont chargés (Common, Mobile, Minerva), et il faut penser à toutes les combinaisons… Et en plus, ça va encore être modifié à l'avenir, argh. En tout cas, les infoboxes v2 rendent maintenant un peu mieux. od†n ↗blah2 mai 2024 à 07:47 (CEST)Répondre
Merci infiniment @Od1n ! Cela rend beaucoup mieux. Les cartes sont désormais parfaitement centrées et les infoboxes mieux calibrées. Il manque uniquement les logos et blasons (voir Bordeaux sur mobile) qui sont toujours collés à gauche de l’infoboxes. Mais je pense que ce style doit être compliqué à imbriquer avec les autres ? Menthe Poivrée, 2 mai 2024 à 11:22 (CEST)Répondre
Dernier commentaire : il y a 10 mois3 commentaires3 participants à la discussion
Bonjour,
je suis tombé sur le modèle {{Infobox Relations bilatérales}}, et le pictogramme qui figure dans l'entête présente deux phylactères. Si je pourrais comprendre l'usage de ce pictogramme dans des infobox dédiées à la bande dessinée, il fait assez désordre quand il est présent dans l'infobox présentant les relations entre deux pays, surtout quand les relations les deux pays sont compliquées (Relations entre l'Iran et Israël, Relations entre la Russie et l'Ukraine, relations entre l'Allemagne nazi et n'importe quel pays...).
Dernier commentaire : il y a 9 mois8 commentaires3 participants à la discussion
La migration des infobox V2 vers V3 ou Lua pour utiliser qu'une classe (.infobox) au lieu des deux (.infobox_v2 et .infobox_v3) actuellement prendra des mois au grand minimum.
D'ici là, pour faciliter l’intégration du mode nuit du côté de la WMF, une solution qu'on espère temporaire serait d'ajouter la classe .fr_infobox à toutes les infobox. Qu'importe sa dénomination à dire vrai, tant qu'elle est signalée à la WMF.
Je ne dis pas ça pour toi Lofhi, mais c'est quoi cette obsession de vouloir migrer toutes les infoboxes vers un format unique, que j'ai déjà constatée plusieurs fois dans des discussions ? Un chantier qui serait démesurément gigantesque, et cela pour un gain très faible ; autrement dit une gigantesque perte d'énergie pour rien. Il est tout à fait possible que plusieurs formats d'infoboxes coexistent, et qu'une classe commune soit ajoutée à l'ensemble des formats. Je pense que c'est évident pour toi, mais j'ai l'impression que certains ne l'ont peut-être pas compris. od†n ↗blah11 avril 2024 à 16:00 (CEST)Répondre
Je veux mettre un terme à cet état intermédiaire qui ne satisfait personne : ni les contributeurs axés sur le contenu éditorial qui se sentent perdus, ni ceux à l'aise avec l'écriture et la technique, ni même ceux ayant des compétences techniques avancées et qui s'embrouillent dans la maintenance. Sauf que je suis encore indécis sur la manière de procéder.
La migration complète vers les infobox V3 (et Lua par choix) semble être la meilleure option à long terme, mais comme tu l'as souligné, c'est un projet colossal. Actuellement, la coexistence des versions V2 et V3 entrave encore la progression des V3 et les modifications apportées à une version ne bénéficient (et ne bénéficieront) pas à l'autre. Puis en conservant cette coexistence, personne ne cherche à apporter des modifications à la V3 pour satisfaire les besoins. Même en adoptant une approche avec une classe générique partagée (par exemple .infobox) et des classes spécifiques à chaque version (.infobox--v2 et .infobox--v3), les infobox restent sensiblement différentes. Et en plus viennent les problèmes des styles embarqués par MediaWiki qui se mélangent aux nôtres. On notera aussi que des projets sont parfois simplement dans l'attente de la migration de leurs infobox, qu'il n'y a même pas de réticence, juste un manque de bras.
Je suis conscient que cette uniformisation donne l'impression de vouloir effacer les différences (je sais très bien que c'est ce qui est ressenti), mais après avoir examiné une bonne partie des infobox, il semble que ce qui est commun à toutes, c'est la présentation synthétique du sujet. Il ne semble pas déraisonnable de convaincre la communauté de la nécessité de retirer certaines extravagances. Par exemple, les {{Infobox Voie de Paris}} ont leur charme, mais leur présentation non standard pose problème, car elle complique la lecture (dans le sens où elles différent de la version attendue dans notre imaginaire, au fil des lectures). Pareil pour le cas des infobox sans entêtes. Un article de presse par exemple, il ressemble souvent à la même chose. Pareil pour l'industrie du livre, il y a des conventions de présentation assez partagées entre les éditeurs. Elles permettent au lecteur de facilement identifier le livre, sans pour autant les rendre sans vie ou moroses.
Aussi, le travail d'accessibilité concernant l'utilisation des couleurs est rendu plus difficile, car toutes les infobox V2, V3 et Lua permettent de choisir les couleurs de manière arbitraire... Je ne me vois pas créer un sous-ensembles de modèles ou de modules puis les intégrer dans les trois versions. Cela serait plus simple en laissant coexister les infoboîtes wikicode et Lua ; deux versions par technologie. Là encore, je tâtonne sur la solution. Proposer uniquement des chartes comme ce qui peut exister pour les infobox de biographies ; ou alors proposer un modèle qui pour une couleur de fond propose une couleur vraisemblablement accessible pour le texte ; puis comment mesurer ? Se baser sur WCAG 2.3 ou faire le choix d'APCA ?
Et sur le plus long terme, j'ai un souhait qui est de proposer un relifting du style des infoboîtes pour coller à Codex et Vector 2022 (parce que c'est ce que les lecteurs anonymes voient). Là encore, je ne me vois pas gérer trois ensembles de règles différents. Je dis je non pas par égo, mais je crois que je suis le seul à soutenir l'idée aujourd'hui. Il y a quelques voix dans la communauté rédactrice qui partagent simplement le souhait d'une modernisation des infobox sans précisions. Je réalise d'ailleurs du lobbying auprès de la WMF de manière plus générale pour qu'on ait accès aux composants CSS-only de Codex dans le wikicode (puisque les tokens CSS atomiques de Codex le seront partout dans quelques semaines).
Enfin sur le long terme, cela pourrait stabiliser la documentation : il y a plein de trucs cachés dans les infoboîtes et je ne parle même pas des modules Lua. Je finis par m'y plonger, puis par oublier. Documenter lourdement les modèles principaux me semble une bonne idée : pour les éditeurs qui fonctionnent simplement avec les pages de documentation, mais aussi pour que les nouveaux contributeurs puissent utiliser correctement les modèles avec l'éditeur visuel.
Donc si tu vois d'autres alternatives ; un fil conducteur pour tout ça. Beaucoup de choses dites pour pas grand chose, vu que même des modifications simples sont bloquées (le cas des infobox pour les sites web par exemple). Lofhi (discuter) 11 avril 2024 à 17:08 (CEST)Répondre
Une autre chose, que j'aurais dû poster auparavant dans la discussion plus haut, est qu'il reste d'anciennes classes infobox qui traînent sur le wiki, voir cette recherche (il y a aussi des classes "infobox-truc" (e.g. "infobox-header"), ça a l'air d'être encore une autre histoire). Cela remonte aux toutes premières infoboxes, celles-ci ont bien été supprimées du wiki et le code CSS a été supprimé en 2013, mais il reste encore ces leftovers. od†n ↗blah20 avril 2024 à 22:26 (CEST)Répondre
Ai commencé à traiter le sujet la semaine dernière. Je n'ai pas tout terminé. Je cherche la cause dans l'outil de traduction. Je ne comprends pas pourquoi ils nous importent des choses assez... créatives. Voir Spécial:Diff/214474781 pour exemple. Lofhi (discuter) 1 mai 2024 à 22:21 (CEST)Répondre
Dernier commentaire : il y a 7 mois4 commentaires2 participants à la discussion
Salutation,
Est ce que quelqu'un peut m'aider à mettre en forme mon infobox. En effet, je rédige une notice biographique sur une personnalité militaire française. Mon militaire en question fut secrétaire général de la Défense et de la Sécurité nationale. J'ai pu voir que plusieurs d'autres eux avait un afficher comme une fonction politique (voir Michel Fourquet). Ce que j'entends par comme une fonction politique, c'est la présence de la fonction avec le prédécesseur, le succésseur ainsi que les années actives. J'espère avoir été clair, sinon je reste disponible pour plus d'info. Yuilo (discuter) 11 juin 2024 à 15:30 (CEST)Répondre
Pour faire comme sur Michel Fourquet il faut utiliser {{Infobox Biographie2}} et renseigner les informations sur Wikidata. Le prédecesseur, le successeur et les dates se rentrent avec des qualificatifs : si la fonction est présente mais sans ses qualificatifs, faire "modifier" (à droite) > "ajouter un qualificatif" (juste en-dessous).
En revanche {{Infobox Personnalité militaire}} ne permet actuellement pas de renseigner les fonctions exercées à ce niveau de détail : avec ce modèle il faut se contenter du champ « autres fonctions » où on peut mettre les dates entre parenthèses, mais il n'y a pas vraiment assez de place pour les prédecesseur et successeur. l'Escogriffe(✉)11 juin 2024 à 17:03 (CEST)Répondre
Complément : pour utiliser une infobox fondée sur Wikidata telle que Biographie2 lorsqu'on travail au brouilon, il faut renseigner l'identifiant de l'élément en paramètre : wikidata = Q110952594 pour la lier à Q110952594 (« Michel de Brébisson »). Une fois que l'article est publié dans l'espace principal et lié à l'élément Wikidata, on peut l'enlever. --l'Escogriffe(✉)11 juin 2024 à 17:09 (CEST)Répondre
Merci ! Ok je modifierais l’info box lors de sa publication !
Dernier commentaire : il y a 7 mois8 commentaires3 participants à la discussion
Bonjour aux membres de ce projet. En consultant l'article Bataille de la Peene, je trouve que, cette fois, une carte de géolocalisation dynamique serait d'un apport indéniable. Qu'en pensez-vous ? Pour le reste, concernant d'autres cas de figure, tels que les infoboxes des édifices religieux, avoir une vraie carte géographique me semble préférable.
En effet, l'utilisateur lambda qui consulte un article sur une église, par exemple, n'a pas besoin a priori de savoir précisément la localisation de l'édifice, mais plutôt dans un premier temps, de le situer au milieu d'une entité géographique plus explicite, tels qu'un pays, une région, ou une circonscription encore plus réduite.
Actuellement, le fait que la communauté ait décidé, au sein des différentes infoboxes, que la carte de géolocalisation dynamique était, par défaut, celle retenue, me semble une erreur. Ne peut-on pas envisager que l'option retenue par défaut puisse être une vraie carte géographique, pour certains cas de figure ? Libre ensuite au contributeur développeur de proposer une option afin de pouvoir visualiser cette vue dynamique.
Salut. Juste un truc qui me choque : « le fait que la communauté ait décidé, au sein des différentes infoboxes, que la carte de géolocalisation dynamique était, par défaut, celle retenue ». Sur un projet communautaire comme WP, si la communauté décide, ce n'est pas un seul utilisateur, ou un petit groupe qui a le droit d'aller contre cette décision non ? Je ne sais pas de quelle décision il s'agit mais si une décision communautaire existe, une nouvelle décision communautaire doit être prise pour amender la première. 'toff [discut.]13 juin 2024 à 06:43 (CEST)Répondre
Salut, tout d'abord, je ne sais pas précisément qui a décidé que les cartes des Infoboxes devaient être dynamiques, le problème étant que de telles dispositions viennent des développements associés à Wikidata, et que la communauté des wikipédiens a peu de leviers pour orienter les différents développements de cette plateforme. Maintenant, je ne prends pas la décision de modifier ce qui existe actuellement, c'était juste une réflexion. N.B : es tu en mesure de me procurer l'origine de cette décision communautaire ? Cordialement. --Sergio1006 (observateur de l'encyclopédie, responsable, libre et indépendant) 14 juin 2024 à 00:37 (CEST)Répondre
Bonjour Sergio1006 et Supertoff. Ce qui se rapproche le plus d'une « décision de la communauté » est Wikipédia:Sondage/Remplacement des cartes statiques par les cartes dynamiques, en 2017. Seulement un sondage et avec une participation assez faible, donc à mon sens rien qu'on soit forcés d'appliquer de façon rigide, mais c'est quand même intéressant. Les participants étaient favorables aux cartes dynamiques pour géolocaliser les bâtiments mais pas dans les autres cas.
Personnellement je nuancerais en étant favorable aux cartes assez fortement zoomées pour géolocaliser les bâtiments se trouvant dans une ville (géolocalisation à l'échelle de la ville, ou du centre-ville) ce qui peut être la carte dynamique ou une carte statique lorsque le bon modèle existe. Je ne crois pas qu'une géolocalisation à l'échelle du pays ou de la région soit très intéressante dans ces cas ; c'est une information qu'on s'attend plutôt à trouver dans l'article sur la ville. Par contre pour une bataille on a plutôt besoin d'une géolocalisation à grande échelle donc je ne vois pas bien ce qu'apporte la carte dynamique. l'Escogriffe(✉)14 juin 2024 à 01:43 (CEST)Répondre
Merci GrandEscogriffe pour ta réponse. Je pense pour ma part qu'on pourrait envisager pour certaines infoboxes les deux types de cartes, statique et dynamique, l'une par défaut et l'autre par un accès sous forme d'un clic à actionner. Concrètement, je ne suis pas d'accord avec ton avis sur le besoin de géolocalisation à grande échelle concernant une bataille, et je pense au contraire qu'il faut un zoom assez fort pour entrer dans les détails d'une bataille. S'agissant des bâtiments, je pense là encore que la carte dynamique n'est pas la plus utile, je me suis expliqué dans mon premier message à ce sujet. S'agissant des villes, pas de problème, la carte statique d'un pays ou d'une circonscription est préférable, en effet. --Sergio1006 (observateur de l'encyclopédie, responsable, libre et indépendant) 14 juin 2024 à 02:19 (CEST)Répondre
@Sergio1006 salut. Non je n'ai pas d'info sur une telle décision : c'est toi qui en a parlé, j'ai donc supposé qu'elle existait et que tu avais l'info. Je ne suis intervenu que pour rappeler qu'une décision communautaire (au sens règle ou recommandation) ne peut être modifiée que par une autre décision communautaire. Pour ce qui est des sondages, il est bien précisé : Les sondages ne sont pas des prises de décisions et sont juste effectués à titre indicatif. Toutefois, s'ils n'établissent pas de règles, les sondages peuvent suffire à constater qu'un consensus existe sur une question donnée. Donc, à mon sens, rien n'empêche de modifier comme tu le suggère au cas par cas (projet par projet), mais il ne faut pas généraliser. 'toff [discut.]14 juin 2024 à 07:13 (CEST)Répondre
@Sergio1006 point important : lorsqu'on affiche une carte statique la carte dynamique est accessible en cliquant sur les coordonnées.
Tu as raison sur l'utilité d'une carte à petite échelle pour suivre le déroulé des combats (en complément d'une géolocalisation à grande échelle pour la situation stratégique), par contre les informations pertinentes sont souvent absentes de la carte dynamique Mediawiki (nom des cours d'eau, forêts, relief...). L'idéal reste les cartes faites spécifiquement pour la bataille avec le contexte pertinent et les mouvements des troupes. Mais ce n'est pas automatisable. l'Escogriffe(✉)14 juin 2024 à 14:33 (CEST)Répondre
@GrandEscogriffe : merci pour ce que tu indiques dans ton post, en effet, j'ai vérifié, on accède bien à une carte dynamique lorsque l'on clique sur les coordonnées situées au-dessus d'une carte statique. C'est même rapide et impressionnant ! Maintenant, je pense que pour situer les différents édifices au niveau d'une Infobox, une carte statique me semble par défaut préférable. S'agissant des batailles, d'accord pour l'usage du zoom en fonction de ce que l'on veut observer, et cela à partir d'une carte dynamique. --Sergio1006 (observateur de l'encyclopédie, responsable, libre et indépendant) 14 juin 2024 à 20:01 (CEST)Répondre
Dernier commentaire : il y a 4 mois20 commentaires5 participants à la discussion
Bonjour, j'ai commencé il y a quelques jours un travail de remise à neuf des articles en lien avec la typographie sur Wikipédia. Dans ce cadre, j'ai quelques questions dans le but d'homogénéiser les Infobox des ≈200 articles de polices. En fait, deux Infobox différentes se partagent équitablement ces articles :
Je me demande comment m'y prendre : quelle Infobox préserver et transformer en "standard", et pourquoi ? Une chose importante que je sais pour le moment c'est que le créateur de l'Infobox Fonte m'a indiqué qu'elle fonctionnait automatiquement en récupérant à les données Wikidata (contrairement à l'autre, qu'il faut effectivement remplir à la main).
Autre point important : l'Infobox Fonte semble être construite à partir de la redirection Infobox Police d'écriture (d'après son wikicode et cette catégorie en tout cas), et ce malgré le renommage de février 2024 mentionné avant. Bref, raison de plus pour unifier une bonne fois pour toute toutes ces Infobox, non ? N'y a t-il pas moyen de faire ça en transférant les quelques avantages de l'une vers l'autre ? À savoir qu'il y avait précédemment 57 d'articles qui utilisaient la redirection « Police d'écriture » comme Infobox, ce que j'ai modifié aujourd'hui. Je n'ai par contre pas osé supprimer la redirection.
Les avantages de l'Infobox Police de caractères (ex « Police d'écriture ») sont d'après moi sa forme (il n'y a pas l'espèce de boussole en haut, mais je suppose que c'est un détail facilement changeable) et surtout son nom (elle est plus intuitive à trouver lors de la création d'un article et « fonte » réfère qu'à une seule graisse alors que « Police de caractères » est un terme plus large).
Pour moi, une infobox Lua et intégrée à Wikidata étant plus moderne, elle qui doit être retenue au détriment de l'autre. Cela dit, il y a du travail du coté l'infobox Fonte, à commencer par sa page de documentation. Borvan53 (discuter) 30 juillet 2024 à 17:14 (CEST)Répondre
Même conseil, et en gardant le meilleur nom.
Par contre, il faudra veiller à ne pas perdre d'informations en modifiant les 111 articles. Comme ça ne peut être fait que manuellement, je veux bien y participer.
Merci à vous deux ! Oui ce sera fait manuellement dans tous les cas. D'ailleurs, savez-vous où je peux consulter le code de l'Infobox Fonte ? Je n'ai pas réussi à trouver, j'aimerais connaître les "champs" que l'infobox est capable de remplir automatiquement en fonction de Wikidata avant de me lancer là dedans, histoire de ne rien oublier (comme le dit Borvan53, la page de l'Infobox n'est pas documentée…). « Même conseil, et en gardant le meilleur nom » : qu'entends-tu par là FDo64 ? Qu'il faudrait renommer l'Infobox avant ?
En cliquant sur « modifier le code » depuis l'{{Infobox Fonte}}, on trouve {{#invoke:Infobox|build|nom=Police d'écriture}}. Cette ligne est (indirectement) un appel au Module:Infobox/Police d'écriture où se trouve le code propre à cette infobox.
Si tout va bien il n'y aura pas à modifier les 111 articles : il suffit de rajouter au module les éventuelles fonctionnalités de l'{{Infobox Police de caractères}} qu'il ne possède pas encore, puis transformer cette dernière en l'appel au module qui se trouve actuellement dans l'{{Infobox Fonte}}, et enfin rediriger {{Infobox Fonte}} vers {{Infobox Police de caractères}}. l'Escogriffe(✉)30 juillet 2024 à 18:54 (CEST)Répondre
Honnêtement, je pense qu'il serait quand même mieux d'avoir la même infobox partout — en l'occurence plutôt Infobox Fonte d'après vos retours — pour que ce soit homogène et plus simple de s'y retrouver. C'est un travail assez long et rébarbatif, certes, mais ça ne dérange pas de m'en occuper ! — VVLLAACC30 juillet 2024 à 20:33 (CEST)Répondre
J'ai préparé la documentation sur Infobox Fonte en attendant, il faut juste compléter la description des différents paramètres (exemples etc.). Je vais regarder un peu la compatibilité inter-paramètre pour faire comme l'Escogriffe le suggère, ça me fera un peu d'entraînement. Omnilaika02 (d) 30 juillet 2024 à 21:27 (CEST)Répondre
Ça avance bien. Oui, il faudra une infobox unique à la fin ; on transformera en redirection la vieille. Un renommage pourra toujours permuter les appellations. Borvan53 (discuter) 30 juillet 2024 à 22:29 (CEST)Répondre
C'est fait ! Je n'ai par contre pas repris les paramètres exemples (que j'ai déprécié dans la doc). À mon sens, ils alourdissent l'infobox (puisque l'illustration est elle-même un exemple=, sont souvent repris dans le corps de l'article et donc pas vraiment nécessaires. Omnilaika02 (d) 13 septembre 2024 à 21:57 (CEST)Répondre
Merci beaucoup @Omnilaika02 ! D'un point du vu esthétique, penses-tu qu'il serait possible d'ajouter un picto à l'infobox, à la manière des chartes de l'infobox Biographie2 ? J'avais déjà laissé un message à ce sujet dans l'optique de le faire moi-même, sans réponse. Par exemple, cette image pourrait peut-être fonctionner, avec un effet d'opacité bien-sûr. J'hésite aussi à changer le fond beige en blanc, mais ça je pourrais le faire moi-même si besoin. — VVLLAACC13 septembre 2024 à 22:58 (CEST)Répondre
Dernier commentaire : il y a 6 mois12 commentaires6 participants à la discussion
Bonjour,
À l'occasion des JO, j'ai enregistré via Lingua Libre les noms de (presque) tous les athlètes olympiques français participant à cette édition 2024. Ces fichiers sont donc disponibles sur Commons, et ajoutés comme prononciation en français sur tous les éléments Wikidata correspondants que j'ai pu trouver.
Si pour certains articles comme Eve Planeix, l'infobox utilisée utilise les données de Wikidata (la prononciation est donc déjà visible), j'ai été surpris de constater que beaucoup d'articles concernant les athlètes utilisent des modèles d'infobox qui ne sont pas reliés à Wikidata (par exemple Modèle:Infobox Judoka, Modèle:Infobox Rugbyman). Le constat est le même sur la Wikipédia anglophone.
Est-il envisageable (ou envisagé) de connecter les infobox d'athlètes (et même à terme toutes les infobox) à Wikidata ? Pour la question des prononciations audio, ça faciliterait les choses (plutôt que d'ajouter un paramètre de prononciation sur chaque modèle d'infobox).
Désolé par avance si la réponse est évidente pour vous, elle ne l'est pas pour moi qui jusqu'ici ai moins contribué à cette partie des projets Wikimédia.
Supertoff : De ma compréhension, {{Infobox Biographie2}} est "connecté à wikidata" dans le sens où les informations présentes sur l'élément Wikidata associé à l'article sont ajoutées automatiquement à l'infobox (d'où mon exemple avec la prononciation sur Eve Planeix).
Ça n'a pas l'air d'être le cas pour toutes les infobox, celles données en exemple n'incluent pas automatiquement la prononciation de l'élément Wikidata associé. — WikiLucas(🖋️)3 août 2024 à 19:39 (CEST)Répondre
Félicitations pour l'enregistrement !
infobox biographie2 est une infobox v3, c'est-à-dire qu'elle est connectée à Wikidata en effet.
les infobox manuelles, dont la plupart des modèles spécialisés pour les biographies, sont v2, donc pas liées à wikidata. En soi, ce serait possible de les moderniser, mais…
C'est compliqué. J'ai vu le souci en 2017 et à ma connaissance personne ne s'est penché dessus, pas forcément par manque d'envie.
C'est aussi assez discuté : les conventions interdisent par exemple de remplacer une infobox wikidata par une non-wikidata, et vice-versa, pour privilégier les préférences personnelles du « principal rédacteur » et éviter les guerres de modifications.
Bref : c'est compliqué. Manuellement, il y a un modèle prononciation quelque part à mettre à côté du nom de la personne dans le RI, mais je crois qu'il n'y a pas de bonne solution automatisée. — Exilexi[Discussion]3 août 2024 à 19:47 (CEST)Répondre
WikiLucas00 : infobox biographie2 est une infobox v3, c'est-à-dire qu'elle est connectée à Wikidata : non c'est faux. Les infobox V3, dont j'ai participé à la construction, sont des infobox accessibles ce qui n'a rien à voir avec WD.
Si tu parles d'infobox qui tirent des infos de WD, c'est au choix des projets, et, par exemple, {{Infobox Personnalité du hockey sur glace}} (mon principal axe de contribution) est une V3 qui ne prend aucune info de WD et qui n'en prendra probablement jamais.
Pour être concret, WD n'est pas forcément voulu dans divers projets et il n'y aura pas de consensus général sur le sujet : WD est un beau projet mais il :
permet un vandalisme global
ne respecte pas les volontés des sourçage qui sont différentes suivant les versions linguistiques
Bonsoir Exilexi, désolé d'en ajouter mais il y a au moins deux erreurs dans tes explications :
{{Infobox Biographie2}} n'est pas une V3 mais une Infobox Lua (il suffit de regarder son code et sa catégorisation)
Il y a trois types d'Infobox : les V2, les V3 et les Lua. Dans les trois cas elles peuvent totalement, partiellement ou pas du tout Wikidata. C'est au choix de leur développeurs (et des projets).
Légère correction à la correction, @FDo64 et @Exilexi : les infobox codées en Lua sont des V3, au sens qu'elles appartiennent à la classe CSS infobox_v3, qui leur est mise par le Module:Infobox (ligne 1095).
Les trois types d'infobox, indépendamment de l'appel ou non à Wikidata, sont donc les V2 (toutes codées en Wikicode), les V3 codées en Wikicode et les V3 codées en Lua. l'Escogriffe(✉)3 août 2024 à 23:54 (CEST)Répondre
Bien entendu, sauf que moi je parlais du code (la partie programmation), pas du CSS. Et ce n'est pas le CSS qui permettra d'avoir l'audio. --FDo64 (discuter) 4 août 2024 à 00:01 (CEST)Répondre
Certes, mais puisqu'on en est à récapituler les types d'infobox, la précision n'est pas inutile. L'idée que V3 = Lua, bien que fausse du point de vue de la structure du code, est vraie du point de vue du rendu. l'Escogriffe(✉)4 août 2024 à 00:52 (CEST)Répondre
Merci à tou-te-s pour vos réponses. Je vois que le sujet n'est pas simple ! Le moyen le plus efficace pour que les ~500 prononciations audio que j'ai réalisées soient affichées dans les infobox de chaque article serait donc d'aller modifier le code de chaque infobox pour qu'elle supporte un paramètre "prononciation", qui ne serait pas forcément synchronisé avec l'élément Wikidata ? 😨 — WikiLucas(🖋️)4 août 2024 à 23:52 (CEST)Répondre
Bonjour Chaps the idol Je ne suis pas certain de comprendre ta démarche pour créer cette Infobox en Lua. Pour ma part je commencerai par m'inspirer d'une autre Infobox en Lua du Wikipédia en français, par exemple {{Infobox Saison d'équipe cycliste}}. Mais si tu n'as pas d'expérience des Infobox en Lua, je te conseille de commencer par des activités plus simples que de créer un infobox à partir de rien. --Dom (discuter) 20 novembre 2024 à 21:07 (CET)Répondre
Bonjour Chaps the idol. Les modèles de base pour construire des infobox ne sont pas du tout les mêmes entre wikipédia en français et en anglais. Donc tu ne pourras pas calquer le code d'une infobox de en.wp ici. Par contre tu peux viser de créer un modèle qui présente les mêmes infos sous une forme similaire.
Au niveau du code, le mieux est de partir de celui d'une autre infobox de wikipédia en français qui présente des similarités de forme avec ce que tu veux obtenir. Si tu veux que ton infobox comporte un tableau (comme celle de Wikipédia en anglais), je te propose de calquer le code de l'{{Infobox Conflit militaire}} qui en comporte plusieurs. Ce code n'est pas du Lua (qu'on ne retrouve que dans l'espace de noms Module:), c'est du wikicode qui utilise les modèles de brique d'infobox V3 et la fonction #if.
Dernier commentaire : il y a 1 mois2 commentaires2 participants à la discussion
Bonjour,
petite question de wikicode. Comment utiliser les #expr ou #ifeq par exemple avec des nombres qui n'arrivent pas exactement en tant que nombre. Par exemple dans {{#expr: {{{annee|}}} - 1976}} annee peut-être {{date|2000}} ou issu de wikidata {{wikidata|P1435|targetvalue = Q9259 |showonlyqualifier = P580|linktopic = -}}
J'ai ajouté des "frontier" patterns pour plus de robustesse, mais ils ne sont pas obligatoires.
Le code avec {{remplace}} est plus court, mais je n'aime pas ces paramètres non nommés (il faut deviner dans quel ordre renseigner les paramètres, et le code n'est pas descriptif), et il y a les problématiques des espaces qui ne sont pas trimmées. J'opterais donc pour le code avec #invoke.
À propos, à cette occasion j'aurais eu cette petite discussion : T382514.
Dernier commentaire : il y a 1 mois3 commentaires2 participants à la discussion
Bonjour,
Depuis un certain temps, je me dis qu'il serait intéressant que Infobox Biographie2 puisse afficher la durée d'une fonction/mandat comme le fait par exemple Infobox Personnalité politique (ex: Willy Demeyer avec l'infobox spécialisée et Henri Schlitz avec Biographie2). J'en ai discuté avec @Utilisateur:Mr Tortue et il est d'accord de regarder à cette modification. Cependant, étant donné que ce modèle 300k pages, on préfère d'abord avoir l'avis de la communauté. Qu'en pensez-vous ?
Personnellement, je pense que cela permettrait de réduire un peu les critiques classiques à propos d'Infobox Biographie2. L'idéal serait d'arriver à un visuel qui serait proche des infobox spécialisée, et donc d'utiliser wikidata avec les paramètres bien encodés.
Le meilleur moyen d’obtenir un consensus sur l'admissibilité 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.
Dernier commentaire : il y a 7 jours54 commentaires33 participants à la discussion
Bonjour,
Les infobox actuelles contiennent environ 160 pictogrammes (les petites icônes situées en haut à droite des cadres qui résument les informations essentielles d'un article), introduits il y a plus de 11 ans. Bien qu’ils aient été pertinents à l’époque, leur utilité est aujourd’hui discutable. Ces icônes apportent peu de valeur ajoutée pour le lecteur, et leur design, déjà daté, nécessiterait une refonte coûteuse en temps et en ressources.
Même une mise à jour graphique ne serait qu’une solution temporaire, car les tendances évoluent rapidement, rendant ces pictogrammes à nouveau obsolètes dans quelques années. Au lieu de s’engager dans ce cycle sans fin, il serait plus judicieux de simplifier les infobox et de se concentrer sur des éléments qui enrichissent réellement l’expérience du lecteur.
Donc je suggère de se passer des pictogrammes dans les infobox pour les raisons suivantes :
Format PNG au lieu de SVG : Les pictogrammes sont en format PNG, ce qui les rend flous sur certains PC avec des écrans larges. Un léger zoom sur la page accentue ce problème.
Affichage médiocre en mode Free Basics : Les pictogrammes sont souvent répétés de manière maladroite dans des contextes comme Free Basics (Wikipedia gratuite).
Vieillissement du design : Le design des pictogrammes devient rapidement obsolète, et les actualiser face aux nouvelles tendances graphiques représente un énorme défi.
Absence de charte graphique : Les pictogrammes ne sont plus conçus suivant une charte graphique précise, ce qui entraîne un style aléatoire.
Problèmes de lisibilité : Les pictogrammes perturbent (autre exemple) parfois la lecture, car ils ne sont pas conçus avec une couleur monochrome harmonisée avec le fond.
Affichage non adapté aux standards actuels : Un affichage plus simple et épuré, comme sur enwiki, correspondrait davantage à l'ère actuelle.
Représentation subjective : Certains pictogrammes ne sont pas toujours pertinents ou adaptés à tous les thèmes.
Incompatibilité avec le mode sombre : Les pictogrammes ne s’intègrent pas bien au mode sombre (Dark Mode), ce qui dégrade l’expérience utilisateur.
Inadaptation à la version mobile : La plupart des utilisateurs consultent la version mobile, où les pictogrammes sont peu ergonomiques et souvent inutiles.
Contre fort. 1. Aide visuelle quelquefois utile. 2. Si "l'ère actuelle" consiste à ne pas vouloir faire l'effort d'actualiser ce qui nécessiterait de l'être, et donc à tout virer, je crois que je préfère encore rester dans "l'ancien monde". Effacer 1500 pictogrammes sous prétexte que ce serait du boulot de les actualiser, c'est pas croyable. --Pa2chant.bis (discuter) 16 janvier 2025 à 16:07 (CET)Répondre
Justement, ils sont quelquefois utiles. Par exemple, sur enwiki, ils sont plus adoptés. Pour une raison simple, personne ne va mettre à jour les 1500 pictogrammes. Riad Salih (discuter) 16 janvier 2025 à 16:13 (CET)Répondre
Par "quelquefois" je résumais à la fois "de temps en temps" et "assez systématiquement, pour quelques personnes". Sans compter leur aspect rendant la lecture agréable. Si vous ne vous sentez pas de mettre à jour ceux qui vous déplaisent, laisser tomber, c'est tout. Quand je pense que ce matin vous demandiez une déprotection de page pour "remplacer" un pictogramme, et que maintenant on apprend qu'en réalité vous voulez tout supprimer, la machoire m'en tombe. --Pa2chant.bis (discuter) 16 janvier 2025 à 16:24 (CET)Répondre
Plutôt Pour. J'ai été à l'origine de plusieurs infobox. A l'époque (fin des années 2000), cela faisait parti du décorum d'internet, comme les torches animées faisaient parti du décorum d'internet dans les années 1990. Le temps est passé, il est temps de passer à des modèles moins chargés. On ne met plus de petits drapeaux dans les infobox, on doit pouvoir se passer de pictogrammes totalement inutiles. Cdlt, XIII,東京から[何だよ]16 janvier 2025 à 17:00 (CET)Répondre
Pour aussi, arrêtons 2 minutes de nous braquer et analysons posément les arguments du proposant qui a dans le fond tout à fait raison. Il y a beaucoup trop de ces pictogrammes qui sont datés, peu cohérents avec le reste de l'interface, pixelisés, subjectifs et eurocentrés sur certains thèmes. A mon avis, si ces picto sont une "Aide visuelle quelquefois utile" c'est que l'article rate sa mission et n'est pas synthétique puisqu'il faut lire l'infobox pour comprendre de quoi il en retourne. Et la maintenance des 1500+ images n'est pas un travail d'intérêt encyclopédique, en plus du fait qu'il est humainement lourd et complexe (je pense qu'on a mieux à faire). Pensons à nos lecteurs et adaptons les codes visuels de notre encyclopédie, pour leur confort et notre efficacité. — Omnilaika02 (d) 16 janvier 2025 à 17:06 (CET)Répondre
Pour Entièrement d’accord avec l’argumentaire de Riad Salih. Pour moi, ils ne rendent nullement « rendent la lecture agréable », au contraire, ils la gênent. Question de génération peut-être… Mais la sobriété est une vertu intemporelle. Punctilla (discuter) 16 janvier 2025 à 17:10 (CET)Répondre
Plutôt contre Assez d'accord avec Pa2chant.bis. Sur le projet suisse, on a tout un groupe de la wp:de qui s'est piqué de refaire tous les blasons de commune pour des nuances de teinte que je peine à distinguer à l’œil nu ou aussi essentielles que remplacer le mat par le brillant (ou le contraire, je ne sais plus ou peut-être que ça varie selon la couleur)... je peine donc à croire qu'il serait impossible d'organiser et trouver des personnes motivées pour retravailler des images intégrées aux infoboîtes.
Si je reprends les arguments un à un :
Ad argument 1 : les formats se changent, non ?
Ad 2 et 5 : admettons que les anciens designs, qui plaisaient, soient devenus insupportables : mettre à jour plutôt que supprimer
Ad 3 et 6 : l'aléatoire, on le retrouve dans le style des articles, dans leur structure, et j'en passe... pourquoi, sur ce point précis, l'uniformisation doit-elle primer ?
Ad 4 : si c'est "des fois", c'est un argument pour changer ces pictogrammes perturbants, pas pour tous les changer ou supprimer
Ad 7 : si le mode sombre était la norme, d'accord ; mais à nouveau, c'est plutôt une solution technique à trouver qu'un argument pour tout supprimer.
Cela dit le débat sur la couleur des blasons est une question encyclopédique ("de fond") tandis que le débat sur les pictogrammes est une simple question de forme. Il ne faut pas exciper de la motivation des contributeurs à faire de l'encyclopédique qu'ils le seront aussi à faire de la mise à jour de (bêtes) pictogrammes. Omnilaika02 (d) 17 janvier 2025 à 08:37 (CET)Répondre
Plutôt contre Pour l'argument 5, je n'ai pas constaté que ma lecture ait été perturbé de quelque manière que ce soit dans les deux maigres exemples proposés. Je n'ai tellement pas été perturbé que je n'ai même pas compris quelle indication était censée être moins lisible. Cordialement Yelti (discuter) 16 janvier 2025 à 22:38 (CET)Répondre
Pour Complètement, ou alors changer complètement les pictogrammes pour en avoir de qualité. Les pictogrammes des infobox sur les sports sont biens, le reste est à jeter. Selon moi il y a un chantier bien plus prioritaire sur les infobox qui est l'utilisation abusive de couleurs à tord et à travers, à l'encontre de l'accessibilité (notamment avec le mode sombre maintenant). Il faudrait se baser sur la charte graphique Codex, mais c'est un autre débat. Goombiis•~Δ~•16 janvier 2025 à 23:13 (CET)Répondre
Pour fort, pour les raisons données par Riad Salih, auxquelles j'ajoute :
le cas où une infobox doit gérer deux sujets (ou plus), et où il est alors difficile de choisir un thème ;
la difficulté et le temps long pour changer quelque chose, certaines icônes datent du temps de Monobook, non ?
Plutôt pour Je comprends ceux qui aimeraient les garder, mais les arguments avancés me laissent quand même assez nettement penser que les inconvénients sont supérieurs aux avantages. Esprit Fugace (discuter) 18 janvier 2025 à 13:26 (CET)Répondre
Contre C'est un peu fatigant, cette tendance ces dernières années à essayer de se débarrasser d'illustrations pour ne garder que du noir sur blanc. Je ne suis pas non plus convaincu par l'idée de dégager plein de pictogrammes au lieu d'essayer une refonte et de tenter de mobiliser du monde (et un dresseur de bot) pour améliorer ça. Bref, d'accord avec Pa2chant et Sherwood. — Exilexi[Discussion]19 janvier 2025 à 14:44 (CET)Répondre
Contre fort une suppression, je trouve que la présence de pictogrammes favorise une lecture rapide. Pourquoi pas les rafraichir / améliorer techniquement leur affichage ? Pas très convaincu par des arguments de type "c'est l'air du temps", je trouve que ça remplit une vraie utilité. D'accord avec les commentaires point par point de Sherwood6 plus haut. levieuxtoby✍ · w (il/lui) – le 19 janvier 2025 à 15:18 (CET)Répondre
Contre Ils permettent une identification rapide du domaine ce que les chartes de couleur ne suffisent pas à faire. Ok pour les passer en svg et les moderniser si besoin (et surtout en créer de nouveaux). L'argument du cout en travail n'a pas de raison d'être sur un projet porté par des bénévoles. --A1AA1A (discuter) 19 janvier 2025 à 15:32 (CET)Répondre
Contre Une des rares fantaisies sur les articles. J'ignorais totalement que ces visuels posaient problème et je ne suis absolument pas convaincue par les arguments présentés. -- Guil2027 (discuter) 19 janvier 2025 à 16:01 (CET)Répondre
Pour car ces pictogrammes sont loin d'être indispensables et la plupart d'entre eux semblent effectivement dépassés (techniquement mais aussi visuellement). Les infobox de certains wikis étrangers (comme les versions en anglais ou en allemand) sont par exemple beaucoup plus neutres et universelles dans leur présentation : pas de picto et parfois pas de couleur, une manière de présenter l'information qui est donc plus en accord avec les valeurs d'intemporalité et d'universalité centrales à une encyclopédie. — VVLLAACC19 janvier 2025 à 16:25 (CET)Répondre
L'existence d'une charte graphique, d'un contenu avec un peu de mise en forme, n'est pas incompatible avec le principe d'écrire une encyclopédie. levieuxtoby✍ · w (il/lui) – le 19 janvier 2025 à 16:42 (CET)Répondre
L'absence de pictogrammes et/ou de couleurs ne signifie pas l'absence d'une charte graphique ou de mise en forme. Et je ne dis pas que c'est incompatible, je dis qu'il est plus cohérent avec le projet de simplifier et d'épurer lorsque c'est possible. Aussi, bien que je sois pour la suppression des pictos, je ne me suis pas exprimé au sujet des couleurs, sujet qu'il faudrait sûrement traiter dans un second temps. — VVLLAACC19 janvier 2025 à 16:57 (CET)Répondre
Plutôt pour Les pictogrammes (et leur maintenance) ne justifient pas leur bilan carbone. En fait, je les remarque tellement peu que j'ai mis une minute à comprendre que la discussion ne portait par si les pictogrammes des bandeaux. Cela dit, Riad Salih a présenté une liste d'arguments qui tient la route. Les arguments pour les conserver m'ont beaucoup moins convaincu : on a toujours fait ainsi donc c'est bien => pas convaincant ; yaka les mettre à jour => pas convaincant ; c'est rigolo => peu convaincant ; aide visuelle => à creuser, je ne les ai jamais vraiment remarqués, mais c'est suggestif. Marc Mongenet (discuter) 19 janvier 2025 à 17:27 (CET)Répondre
Il y a plusieurs problématiques. Le principal problème de cohérence, ce n'est pas entre les images qui ont un style différent, mais entre les infobox qui ont ces images et les infobox qui les ont pas. Et oui, il y a surement autant qui en ont, qu'il y en a qui n'en ont pas. Par exemple, il y en pas pour Modèle:Infobox Joueur d'échecs (par contre l'infobox Biographie2 qui simule cette dernière, elle a une icone...ça devient comique...) mais il y en pour Modèle:Infobox Joueur de go. Même Projet:Infobox/Pictogramme ne semble pas à jour (et les promesses de mode ilyakafonkon j'y crois absolument pas). Le deuxième problème de cohérence, c'est qu'il y a des images très réussies d'autres beaucoup moins (celle du cinéma est très réussie et très visible, alors que celle sur le sujet de la photographie beaucoup moins). Il y a des images très discrètes (celle sur la santé est quasiment invisible), au point d'être quasiment invisible, d'autres vraiment visible au point d'être trop visible. Avoir un consensus sur la question de manière globale me semble très compliqué à avoir même sur le long terme (je dirais même totalement impossible). Et puis dit plus haut, le débat devrait aussi porté sur l'abus de couleur (par exemple sur l'infobox entreprise, il y a eu une mode à un moment de mettre la couleur de l'infobox en accord avec les couleurs de l'entreprise, j'ai toujours trouvé cela pas du tout pertinent, mais s'est resté comme usage...). Si il y a une possibilité d'actions à faire à faire qui pourrait faire consensus, donc mettre à jour la documentation et faire le ménage des quelques icones peu esthétiques. Et ça serait déjà pas mal. (Et j'y crois encore une fois moyennement). Nouill19 janvier 2025 à 19:55 (CET)Répondre
Neutre. Pictogrammes assez discrets (contrairement aux icônes de drapeaux), qui gênent peu ou pas du tout la lecture du titre. Indispensables ? Pas vraiment. Donc : bof. --Warp3 (discuter) 19 janvier 2025 à 21:01 (CET).Répondre
Contre choix de chaque portail. Déjà que les infobox en lua ne sont pas capable de le faire alors si en plus on ajoute des considération de "trop fatiguant à faire" on n'est pas sorti --GdGourou - Talk to °o°17 janvier 2025 à 09:07 (CET)Répondre
Neutre Sur le principe pourquoi pas, en revanche il n'y a aucune urgence réelle à se lancer dans des changements en masse. Il faut prendre le temps d'informer les projets concernés, de les laisser réagir et, en cas de désaccord, de parvenir à un consensus après discussion. Gentil Hiboumon arbre20 janvier 2025 à 10:48 (CET)Répondre
Plutôt contre ça fait partie un peu de notre charte graphique, même si c'est facultatif. A force d'épurer, on va supprimer la couleur pour un tableau noir et blanc. Après, ne pas aller dans l'excès et on devrait se limiter à un calque discret transparent sans rajouter de la sur-couleur. -- Xfigpower (pssst) 20 janvier 2025 à 12:43 (CET)Répondre
La question actuelle porte sur les pictogrammes, les couleurs relèvent d'un autre sujet, et nous avons toujours la possibilité de créer d'autres styles et d'autres chartes graphiques, et sans limites. Riad Salih (discuter) 20 janvier 2025 à 13:50 (CET)Répondre
Neutre Ces pictos n'amènent pas grand chose à l'encyclopédie et concernent principalement les sportifs. Mais ils ne gênent pas vraiment non plus... Wikipédiennement, --Desman31 (discuter) 20 janvier 2025 à 15:08 (CET)Répondre
Neutre, je ne'y fait pas attention, comme Marc, plus discrets que les drapeaux (contre lesquels j'ai voté), comme Warp3, d'accord avec Pa2chant.bis sur le fait qu'il vaut toujours mieux améliorer que jeter, mais dans ce cas précis et, vu ce que ça représenterait comme boulot (après, si des pcW s'y attellent, why not ?). Quant au mode sombre, je suis un utilisateur des premiers jours, j'ai beaucoup souffert, mais maintenant ça semble s'arranger, petit à petit, ces pictogrammes ne sont pas ma priorité (il reste encore des pages où j'ai laissé des messages en PdD parce qu'elles sont pratiquement illisibles, là, ça craint), en revanche, je croyais que mode sombre / mode clair était une histoire de choix, je ne comprends pas bien ce que @Sherwood6 entend par « si le mode sombre était la norme, d'accord » (sans vouloir troller / lancer un débat sans fin). — jeep (j33p) ॐ20 janvier 2025 à 19:55 (CET)Répondre
Cosmophilus : bonjour. Le pictogramme est juste décoratif. Qu'il soit présent ou pas il n'est pas lu par les lecteurs d'écran. Donc pas d'incidence à sa présence ou non d'un point de vue accessibilité. 'toff [discut.] 22 janvier 2025 à 07:09 (CET) PS : ce qui ne veut pas dire qu'il faut se baser là-dessus pour la suppression ou le maintien : ça reste un choix communautaire. 'toff [discut.]22 janvier 2025 à 07:14 (CET)Répondre
Plutôt contre En phase avec le principe « améliorer au lieu de supprimer » défendu par d'autres ci-dessus, attendu qu'aucun des problèmes soulevés ne semble insoluble. Ces pictogrammes ne posent en définitive pas plus de difficultés que les icônes de portails, ne nuisent pas à l'accessibilité des lecteurs d'écrans (critère important à mes yeux) et apportent une touche d'originalité qu'il me paraît dommage d'effacer. --Cosmophilus (discuter) 22 janvier 2025 à 22:45 (CET)
Pour c'est souvent inutile et peu raccord avec le thème du projet (la boussole pour les transports en commun... alors que sur d'autres Wiki il y a des choses plus raccord). Pour les couleurs il faudrait en revoir l'usage oui. Cdlt, Lyon-St-Clair[Hon hon hon]26 janvier 2025 à 15:22 (CET)Répondre
Comme j'avais du mal à voir la tendance des avis, j'ai fait un petit décompte (sauf erreur) :
Somme des "pour" : pour fort (1) + pour (6) + plutôt pour (3) = 10 (33,3 %)
Neutre : 4 (13,3 %)
Somme des "contre" : contre fort (4) + contre (8) + plutôt contre (4) = 16 (53,3 %)
Contrairement à ce que je croyais (ça me semblait équilibré à vue de nez), il se dégage plutôt une majorité d'avis vers le "contre". C'était équilibré pendant un temps, mais les 10 derniers avis on fait pencher la balance (6 contre, 4 neutre). Mais tout comme en dda, le nombre ne suffit pas : les arguments sont à prendre en considération. Et il se pourrait aussi que la balance s'inverse soudainement.
PS : je n'ai pas émis d'avis, je n'en ai pas de définitif (ce qui pourrait s'apparenter à neutre) donc je n'ai pas de vue biaisée sur le sujet. 'toff [discut.]28 janvier 2025 à 05:13 (CET)Répondre
Nous devrions ouvrire un sondage généralisée; les gens ont tendance à suivre la majorité ; si les votes penchent davantage du côté du contre, les utilisateurs se tourneront également vers cette position. Pour l'instant, il s'agit simplement d'une phase de discussion. Riad Salih (discuter) 28 janvier 2025 à 13:52 (CET)Répondre
Ce n'est pas une décision à prendre à la légère. L'impact de la suppression de l'ensemble des pictogrammes dans les infobox sera important. C'est donc une décision à prendre de manière bien plus large que sur ce projet. --JmH2O(discuter)16 janvier 2025 à 17:18 (CET)Répondre
Complètement en accord avec Jmh2o : ce n'est pas ici que ça doit être décidé mais de façon plus large. Peut-être un sondage ? (si toutefois ça n'est pas porté ailleurs de façon plus large, je voterai ici contre). 'toff [discut.]16 janvier 2025 à 17:51 (CET)Répondre
Pas trop d'avis sur le fond, si ce n'est que je suis d'accord, moi aussi, avec Jmh2o : je pense que c'est une décision qui nécessite une réflexion collective large, plus qu'ici. HistoVG (discuter) 16 janvier 2025 à 19:00 (CET)Répondre
Clairement pas : si les infobox de beaucoup de projets ont des logos, c'est que quasiment ces projets l'ont adopté. Donc non, on ne prend pas une décision dans un coin : on consulte l'ensemble de la communauté. Il si elle décide de supprimer, on supprime : encyclopédie collaborative 'toff [discut.]16 janvier 2025 à 22:09 (CET)Répondre
@Supertoff : autant je suis plutôt contre la proposition, autant demander des sondages (pour ensuite dire que ce ne sont que des sondages !) et prises de décision me semble totalement disproportionné et tout simplement propre à encourager l'inertie et la sclérose. Sherwood6 (discuter) 16 janvier 2025 à 22:26 (CET)Répondre
Conflit d’édition — Ca n'est pas la question : d'autres projets l'ont adopté donc ils sont aussi impliqués. Perso, j'ai créé l'infobox de mon projet et j'y ai inclus le picto à l'époque en accord avec mon projet. Mais il ne me viendrait pas à l'esprit de l'imposer aux autres membre de mon projet s'ils veulent la supprimer, ou de la supprimer sans leur demander. C'est un respect de l'esprit encyclopédique de wikipédia : les infobox touchent tous les projets et je ne vois pas en quoi un contributeur qui ne participe pas à un projet supprimerait arbitrairement (i.e. sans consulter la communauté dans son ensemble) les pictos sur toutes les infobox. De toute façon, ici il n'y a pas consensus (loin de là : 3 pour, 2 contre). Donc, pour toutes ces raisons, la question doit s'étendre ailleurs. 'toff [discut.]16 janvier 2025 à 22:29 (CET)Répondre
Je pense que l'atelier n'est pas très actif. Il faut le consulter en premier, en gardant à l'esprit que les anciens designs ne sont pas tous adaptés pour être convertis en SVG. Riad Salih (discuter) 17 janvier 2025 à 21:39 (CET)Répondre
À mon humble avis, la suppression de ces pictogrammes n'aura aucun impact, que ce soit sur le code ou sur le contenu des infobox. L'impact significatif introduit n'est pas détaillé. La page Wikipédia:Prise de décision explique qu'il faut consulter les pages des projets concernés et le Bistro, mais si le débat s'élargit beaucoup plus, un sondage peut être envisagé. Riad Salih (discuter) 17 janvier 2025 à 13:12 (CET)Répondre
Concernant le code, cela le simplifiera en retirait un paramètre d'affichage. On simplifiera le code encore plus quand on retirera les options de couleurs, tout aussi problématiques que les images.
+1 sur une prise de décision : la présente conversation est déjà un bon indicateur des différentes options qui pourraient être présentées. Trizekbla17 janvier 2025 à 19:07 (CET)Répondre
J'allais entamer la question des couleurs aussi après les icônes. C'est un grand chantier, malheureusement un sujet très important mais qui est rarement discuté. Riad Salih (discuter) 17 janvier 2025 à 21:32 (CET)Répondre
Aucun impact ? L'utilité des pictogrammes est évident et universel, une image vaut mille mots. Il serait radical de les supprimer sous prétexte que certains sont flous. Pour ce qui est des couleurs, ceux qui ne les aiment pas ont la possibilité de mettre leur affichage en noir et blanc. --YanikB20 janvier 2025 à 20:39 (CET)Répondre
Un pictogramme est dépendant d'une certaine culture : une image vaut bien mille mots, mais uniquement quand tout le monde a la même interprétation de l'image. Idem pour la couleur : rattacher une couleur à un certain thème est dépendant d'une culture et du temps. Le blanc : couleur du mariage (en Europe) ou du deuil (au Japon) ? Le rose : couleur des filles (de nos jours) ou des princes (à la cour de France) ?
est un pictogramme que tous les lecteurs francophones reconnaissent. Certaines personnes aimeraient bien que tous les gens soient pareils, qu'ils s'habillent et pensent de la même façon alors que la beauté de la vie est sa diversité. --YanikB21 janvier 2025 à 16:33 (CET)Répondre
HelloYanikB, ou bien peut-être que « Certaines personnes aimeraient bien que tous les gens soient francophones, qu'ils s'habillent et pensent de la même façon francophone, alors que la beauté de la vie est sa diversité » ?
Précisément, un monde formaté et sans couleurs est le contraire de l'ouverture. Par ailleurs un lecteur qui ne connait pas le français ne viendra pas sur WP:fr. --YanikB21 janvier 2025 à 17:17 (CET)Répondre
De la même manière qu'on ne remplit pas un article d'images juste pour faire joli (il y a un choix éditorial) on ne met pas de la couleur partout pour le plaisir de mettre de la couleur. On met de la couleur parce qu'elle est pertinente.
Les couleurs suivantes sont utilisées dans des infobox. Sans chercher dans la doc, pouvez-vous me dire à quoi elles font référence en tant que contenu éditorial ?
Si vous n'y arrivez-pas, c'est sans doute que la couleur n'est pas pertinente en tant qu'information éditoriale.
Cela vaut aussi pour les icônes : savez-vous à quoi celles-ci dessous, utilisées dans des infobox en service, elles correspondent ?
1
1
2
2
3
3
Les réponses sont dans le nom des fichiers, trichez pas ! :D
Dans ce contexte, si une image valait vraiment mille mots, on se contenterait uniquement de Wikimedia Commons et on se passerait de Wikipedia et de ses articles.
Si l'on est un peu réaliste, le lecteur ne s'intéresse même pas à ces pictos qui n'enrichit en rien ses connaissances. À cela s'ajoutent les multiples problèmes techniques déjà mentionnés, comme c'est le cas, par exemple, sur d'autres plateformes telles que Wikiwand qui sont également très visitées mais où les pictos ne sont pas bien intégrés. Riad Salih (discuter) 21 janvier 2025 à 18:57 (CET)Répondre
Moi je dis qu'on devrait enlever les liens bleus et les liens rouges dans les articles pour ne laisser que des liens noirs : ah bas les couleurs ! 'toff [discut.]21 janvier 2025 à 19:42 (CET)Répondre
@Riad Salih Bien entendu, cela fait plus de dix ans que j'améliore les articles et la mise en page est ma spécialité. D'autre part le graphisme est une des cordes à mon harpe, notamment pour les cartes géographiques. Et vous ?
┌─────────────────────────────────────────────────┘
Les réponses au jeu sont ci-dessous (ping Marc Mongenet, seule personne a avoir tenté l'aventure) :
C'est aussi la couleur de la médecine pour l'infobox « Personnalité des sciences humaines et sociales » (example). Mais un médecin avec l'infobox Biographie2 aura pour couleur... (exemple, à comparer avec cette doc)
J'avais noté cet article pour exemple, présentant une infobox Événement, avec la charte incendie, mais il semble que j'ai du mal copier un truc, car sa valeur est en réalité .
Cependant, , c'est pour infobox Feu de forêt, que j'avais croisée. La différence se justifie-t-elle ? Elle est facile à unifier, mais elle montre qu'il manque une coordination réelle concernant les couleurs des chartes.
Infobox Géographie (trouvée sur l'article consacré à une ville)
Infobox Géographie (trouvée sur l'article consacré à une ville)
Infobox Université
Infobox Université
Infobox Cardinal
Infobox Cardinal
Pour les couleurs, on découvre la même couleur utilisée pour plusieurs sujets sans rapport, et un manque de cohérence entre infobox couvrant le même sujet. Cela justifie de trouver une couleur par grans thème (biographie, géographie... — encore faut-il qu'elle soit en adéquation avec les principes de design généraux), voire de se débarrasser de ces couleurs pour avoir une présentation unifiée. Il faut aussi rappeler que certaines infobox permettent d'outrepasser les couleurs définies par la charte actuelle.
Concernant les icônes dans les infobox, outre le fait qu'elles soient peu lisibles, personne ne semble avoir deviné à quoi elles correspondaient. Elles sont donc là pour faire joli, et ne se justifient pas en tant qu'objet éditorial (sans compter les cas où l'icône gène la lecture).
J'espère que la démonstration est assez éloquente pour alimenter le reste de la conversation, et que nous réfléchirons à tout cela en terme génériques, et non pas en explorant les exemples un par un.
Trizekbla26 janvier 2025 à 12:30 (CET), édité le 26 janvier 2025 à 12:36 (CET)Répondre
C'est rigolo ! Merci pour ce très bon exemple qui illustre bien le problème : on met des couleurs... pour mettre des couleurs, ça n'a aucun sens. Et c'est pareil pour les pictogrammes des infobox, à mon sens. Omnilaika02 (d) 26 janvier 2025 à 15:04 (CET)Répondre
Omnilaika02 : je ne comprends pas le sens de ta phrase « on met des couleurs... pour mettre des couleurs » tu veux dire quoi par là ? Les couleurs c'est esthétique, ça n'a aucun autre but. 'toff [discut.]26 janvier 2025 à 19:08 (CET)Répondre
Mais si on veut juste faire du joli, il me semblerait plus indiqué d'ouvrir un blog pour laisser libre cours à sa créativité. Attention, je ne dis pas que Wikipédia doit être moche ! Ce que je veux dire, c'est que dans une immense œuvre collaborative, si chacun met sa propre touche de « joli » sans se coordonner avec les autres, le résultat sera plus confus que joli. Enfin, j'écris « sera », mais je crois qu'on peut écrire qu'il l'est. Marc Mongenet (discuter) 26 janvier 2025 à 23:57 (CET)Répondre
Généralement c'est une histoire de projet, donc il y a déjà une coordination. Rien n'empêche de faire encyclopédique et joli. Après, si tu préfères la vie en noir et blanc 'toff [discut.]27 janvier 2025 à 07:19 (CET)Répondre
Je préfère quand on lit mes message en entier, surtout quand ils ne contiennent que 4 phrases. A part ça, s'il n'y a coordination qu'au niveau des projets et pas au niveau de l'encyclopédie, c'est bien mais pas sufisant. Marc Mongenet (discuter) 27 janvier 2025 à 16:48 (CET)Répondre
Pour moi on met visiblement des couleurs pour mettre des couleurs, donc sans but en soi (à part peut-être faire joli). J'arrive à cette conclusion parce qu'il n'y a visiblement aucune cohérence encyclopédique entre les codes couleurs des différentes infobox. Omnilaika02 (d) 27 janvier 2025 à 08:36 (CET)Répondre
Il y a quand même des cas où ces icones ont un sens de lecture immédiate. A propos de Zidane par exemple, on a deux articles portant des icones, l'un sur le joueur de foot, l'autre sur un film le concernant. Et il y a deux intrus. Je suis persuadée que tout le monde sait reconnaitre au premier coup d'oeil les intrus et associer les deux icones à leur contenu :
Et sur Guynemer de Boulogne ça veut dire quoi ? Qu'il est mort ? Celle de Zidane est minuscule sur mobile, là où est pourtant la grande majorité de nos lecteurs (et où cela justifierait de pouvoir "reconnaître" du premier coup le "type" d'article, vu la petite taille de l'écran).
Historiquement les infobox ont été développées il y a plus d'une quinzaine d'années, chacun copiait du code par-ci par-là et ajoutait sa touche personnelle. C'est comme ça qu'on en est arrivés à avoir des infobox qui ont des apparences différentes, des champs qui arrivent dans un ordre différent, et pire encore un joyeux bordel dans le code (où une chatte n'y retrouverait pas ses petits ; mais c'est ce qui fait le charme de Wikipédia), et il faut savoir que chaque version linguistique (et il y en a plus de 300) a ses propres infobox... ça a de quoi donner le vertige. Il y a une réflexion à avoir sur un panel d'infobox communes, c'est certain, mais également au niveau des chartes et des icônes. Il y a plus de 200 chartes. Ça ne serait pas choquant éventuellement de tout reposer à plat, de revoir les icônes et les couleurs, de simplifier. Jérémy-Günther-Heinz Jähnick (discuter) 27 janvier 2025 à 10:11 (CET) (je viens de m'apercevoir que pour les Wikipédias en breton et en aragonaisMaggie Smith était toujours de ce monde. Non vraiment, il n'y a que moi qui pense qu'une telle mise à jour effectuée source à l'appui en un seul point devrait se répercuter immédiatement dans toutes les versions linguistiques avec des infoboxes ayant le même aspect — ça n'exclue pas la couleur et les pictogrammes — ?)Répondre
@Pa2chant.bis, explorer les exemples un par un ne permettra pas de justifier de l'utilisation des icônes de manière globale. Et s'il y a des exemples qui fonctionnent dans la lecture de l'icône, mais il n'y a toujours pas de justification éditoriale.
Ce n'est pas "un par un" : tu as montré 3 cas où l'apport est difficile à percevoir, j'en montre 4 où ils prennent tout leur sens, c'est assez symétrique comme illustration. Pas sûre de comprendre ce que tu appelles "la justification éditoriale", mais pouvoir reconnaitre au premier coup d'oeil, sans même besoin de lire le texte, si un article porte sur un footballeur ou un cycliste, rien que pour cela, cela vaut le coup. Sur les doubles activités, le problème est bien plus général, le pictogramme doit être celui de l'infobox retenue, cela ne peut pas constituer il me semble une raison de suppression de ces pictogrammes. (Et sur David Douillet, j'aurais choisi sportif, mais c'est hors-sujet). Cdlt, --Pa2chant.bis (discuter) 28 janvier 2025 à 01:28 (CET)Répondre
C'est bon, on est en 2025. Prenons cette infobox, il faut une imagination débordante pour deviner ce que le pictogramme veut dire.
Mais soyons honnêtes : ce n’est pas parce qu’un élément graphique a eu son heure de gloire à un moment donné qu’il doit rester figé pour l’éternité comme un fossile. Même le design de Wikipédia a évolué plusieurs fois, en changeant sa charte et son style visuelle. Il faut avancer, moderniser, et éviter de rester coincés dans le passé. Riad Salih (discuter) 28 janvier 2025 à 02:01 (CET)Répondre
@Pa2chant.bis, si on se contente d'ouvrir Wikipédia et de regarder les icônes pour savoir qui fait quoi, à ce compte, Yannick Noah ne serait que chanteur. Et, en poussant le raisonnement à l'absurde, David Douillet ne ferait donc rien, vu que l'infobox « personnalité politique » n'a pas d'icône ? ;)
La question générale reste de savoir ce qu'apportent les icônes, à part de la confusion (car elles ne sont pas toutes identifiables), de l'incohérence (car elles ne sont pas présentes partout), de l'absence de neutralité (en se contentant de ne mettre en avant d'une seule activité) et — en toute subjectivité — un esthétisme quelque peu passé ?
« Excellent résumé » Hum. Je pensais que tu avais plus de tact que cela. Bon, nous n'avons pas la même perception, inutile de faire dans l'attaque personnelle avec ces "Soyons honnêtes (je suis malhonnête ?), "il faut avancer, éviter de rester dans le passé" (je suis une vieille schnoque passéiste attachée aux fossiles ?). Restons en là. --Pa2chant.bis (discuter) 28 janvier 2025 à 20:07 (CET)Répondre
@Pa2chant.bis Je pense que le contexte était assez clair. Je ne peux pas contrôler comment vous comprenez mes mots, et je n'essaie pas d'y mettre de sous-entendus. Vous êtes assez perspicace pour le savoir. On parle de manière générale de modernisation des designs, donc débattons sur le fond. Riad Salih (discuter) 28 janvier 2025 à 20:32 (CET)Répondre
Je pense que le résumé est juste dans le sens qu'il faut savoir évoluer, surtout quand il n'y a pas de sens à conserver l'existant. Si on en arrive à parler de la forme des messages, c'est que le fond est sans doute épuisé.
Ce type de changement ne sera pas sans passer par une consultation plus globale, qu'il va falloir mettre en place. L’avantage des arguments présentés sur cette page est qu'ils résument assez bien les différentes opinions.
« surtout quand il n'y a pas de sens à conserver l'existant » ça c'est une opinion, pas un fait Mais d'une manière générale, je pense que les discussions ne servent à rien et que ceux qui "discutent" (un bien grand mot) sont campés sur leurs positions... 'toff [discut.]29 janvier 2025 à 19:57 (CET)Répondre
Je n'ai jamais dit que ce n'était pas une opinion.
J'espère avoir un peu de temps bientôt pour faire un résumé des faits, afin de préparer une discussion plus large. Si quelqu'un à envie de s'y attaquer avant moi, no problem. :) Trizekbla30 janvier 2025 à 17:33 (CET)Répondre
Le projet « Infobox » n'est pas notifié pour le moment.
'toff [discut.] 11 mars 2024 à 19:20 (CET)
. Histoire d'être au moins trois à donner notre avis, voici le mien.
!
FDo64 : j'ai regardé tes exemples et ça me conforte dans mon idée que ça reste accessible à une minorité : je ne comprends quasiment rien (j'ai compris où sont les commentaires). Même si il faut un minimum de connaissance "informatique" à priori pour s'auto-former au wikicode (ce qui restreint déjà l'accès), apprendre un langage de programmation comme Lua est encore moins évident : le wikicode est très limité et est donc plus accessible. C'est ce qui fait sa force et sa faiblesse (ou inversement). Perso, je me suis auto-formé sur le wikicode, mais je ne me vois pas apprendre un langage informatique comme le Lua, ce qui, de plus, me rangerait avec les barbus 
.
Escargot bleu et cette modification ?
Menthe Poivrée • 25 mars 2024 à 20:37 (CET)
Menthe Poivrée • 25 mars 2024 à 21:55 (CET)
Menthe Poivrée, 2 mai 2024 à 11:22 (CEST)
,
je compte modifier {{Infobox Chimie}} (qui nécessite une modification de {{Infobox/Image/}} et {{Infobox/Image optionnelle/}}) et attend donc vos retours ici.
Pour, Proposant Riad Salih (discuter) 19 janvier 2025 à 22:29 (CET)
Contre fort proposition radicale donc refus radical. --JmH2O(discuter) 16 janvier 2025 à 16:01 (CET)
Contre Des améliorations ou des évolution à apporter surement, mais reste des marqueurs intéressants. --KPour les intimes © 16 janvier 2025 à 16:02 (CET)
Plutôt contre Assez d'accord avec Pa2chant.bis. Sur le projet suisse, on a tout un groupe de la wp:de qui s'est piqué de refaire tous les blasons de commune pour des nuances de teinte que je peine à distinguer à l’œil nu ou aussi essentielles que remplacer le mat par le brillant (ou le contraire, je ne sais plus ou peut-être que ça varie selon la couleur)... je peine donc à croire qu'il serait impossible d'organiser et trouver des personnes motivées pour retravailler des images intégrées aux infoboîtes.
Pour fort, pour les raisons données par Riad Salih, auxquelles j'ajoute :
Plutôt pour Je comprends ceux qui aimeraient les garder, mais les arguments avancés me laissent quand même assez nettement penser que les inconvénients sont supérieurs aux avantages. Esprit Fugace (discuter) 18 janvier 2025 à 13:26 (CET)
Neutre. Pictogrammes assez discrets (contrairement aux icônes de drapeaux), qui gênent peu ou pas du tout la lecture du titre. Indispensables ? Pas vraiment. Donc : bof. --Warp3 (discuter) 19 janvier 2025 à 21:01 (CET).
Contre fort pour les infoboxes compatibles avec Wikidata. Jérémy-Günther-Heinz Jähnick (discuter) 21 janvier 2025 à 14:19 (CET)
Plutôt contre En phase avec le principe « améliorer au lieu de supprimer » défendu par d'autres ci-dessus, attendu qu'aucun des problèmes soulevés ne semble insoluble. Ces pictogrammes ne posent en définitive pas plus de difficultés que les icônes de portails, ne nuisent pas à l'accessibilité des lecteurs d'écrans (critère important à mes yeux) et apportent une touche d'originalité qu'il me paraît dommage d'effacer. --Cosmophilus (discuter) 22 janvier 2025 à 22:45 (CET)
Pour c'est souvent inutile et peu raccord avec le thème du projet (la boussole pour les transports en commun... alors que sur d'autres Wiki il y a des choses plus raccord). Pour les couleurs il faudrait en revoir l'usage oui. Cdlt, Lyon-St-Clair [Hon hon hon] 26 janvier 2025 à 15:22 (CET)
du mode sombre. — jeep (j33p) ॐ 20 janvier 2025 à 19:58 (CET)
est un pictogramme que tous les lecteurs francophones reconnaissent. Certaines personnes aimeraient bien que tous les gens soient pareils, qu'ils s'habillent et pensent de la même façon alors que la beauté de la vie est sa diversité. --Yanik B 21 janvier 2025 à 16:33 (CET)
— jeep (j33p) ॐ 21 janvier 2025 à 17:07 (CET)
Trizek bla 26 janvier 2025 à 15:46 (CET)
_pictogram_test.png)
.svg){kind=link}