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]
Majuscule ou minuscule pour les valeurs des champs ?
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]
Combien de feuilles de style pour l'infobox Biographie2 ?
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]
Une feuille de style par infobox me semble plus pertinent, sinon on risque de recharger tous les styles sur un article avec deux infobox. Lofhi (discuter) 3 avril 2024 à 09:59 (CEST)[répondre]
Centrage
Bonjour,
Quelqu’un peut m’expliquer pourquoi dans l’infobox commune de France, les blasons, logos et les cartes ne sont jamais centrées sur mobile (Minerva) ?
Est-ce que c’est voulu ? Ou personne ne l’avait remarqué auparavant ?
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]
pictogramme problématique
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...).
Support du mode nuit avec une classe CSS temporaire
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]
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 !
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]
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]
Prononciation dans les infobox
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.
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.
Le projet « Infobox » n'est pas notifié pour le moment.
.svg){kind=link}