Je marque « pas fait » pour archivage. Demande justifiée de façon très vague qui n'a intéressé personne en un an et demi, et compte du demandeur verrouillé globalement. --l'Escogriffe(✉)10 mars 2025 à 22:09 (CET)Répondre
Dernier commentaire : il y a 1 an3 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 1 mois50 commentaires8 participants à 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.
Le Lexique ne dit rien sur le sujet (en particulier, il n'y a rien sur la typographie dans les tableaux). Le « champ : valeur » est juste votre façon de voir. On pourrait aussi le voir comme une liste avec des items commençant directement par du texte, et là, ce serait plutôt similaire au premier cas de « Au départ d'un alinéa » p. 39 du Lexique, où la règle est d'utiliser une majuscule. Je pense que c'est au choix pour chaque éditeur. Pour Wikipédia, je vois que les exemples d'infobox dans les documentations des modèles (comme pour les écrivains et les personnalités du cinéma) utilisent des majuscules. — Vincent Lefèvre (discuter) 10 février 2025 à 01:08 (CET)Répondre
Bonjour à tous les deux,
[désolé, c'est un peu long, explications d'un ex-maquettiste (à Libé, entre autres) dans sa jeunesse... devenu informaticien bien lus tard ! ]
Figure-toi que je m'exprime un peu partout (PdDUs, Projet Cinoche, etc.) pour essayer de faire passer / comprendre / admettre « ma » vision (qui semble la même que la tienne), qui est de considérer le couple « descripteur de champ » - « valeur » ainsi :
...............Descripteur de champ : valeur
[avec, donc, pour l'infobox les deux-points « sous-entendus »]
Ce qui donnerait :
...............Naissance : 451 gabuzomeu 16783
...............Nationalité : shadokienne
...............Profession : acteur-pompeur
Soit, dans l'infobox :
[...]
...............Nationalité shadokienne
[...]
Comme je l'exposais hier soir à Vincent sur sa PdDU.
Cela me semble beaucoup plus conforme à la typographie de notre langue (et à WP:CT) qui prescrivent toute deux qu'on utilise la minuscule après un deux-points.
Alors qu'à l'heure actuelle (dans le modèle infobox « classique »), on met une maj. aux deux paramètres ce qui revient à faire une phrase contenant deux mots commençant chacun par une majuscule, ce qui me semble bizarre.
C'est un peu comme Si Je Me Mettais À Écrire Ainsi (selon moi).
Et pour reprendre ton exemple d'« items », Vincent, justement, s'il s'agit bien d'une liste, selon moi, elle se présente ainsi :
item 1 :
item 2 ;
[...]
ou
Item 1.
Item 2.
[...]
Mais perso, je ne vois pas que cela puisse se présenter ainsi :
Item 1 Item 1bis
Item 2 Item 2bis
Plutôt :
Item 1
Item 1bis
Item 2
Item 2bis
Donc, quand on a deux items qui se suivent dans la liste, ils sont séparés soit par une virgule, soit par un deux-points ; et dans les deux cas le second item est en minuscule.
Exemple :
Item 1, item 1bis
Item 2 :
Le problème c'est que — justement, ici — on est dans un contexte « infobox », donc ni liste, ni phrase et que, visiblement, les devs ont décidé que ça ne suivrait pas forcément la typo FR.
Je ne vais répondre que pour le champ « Nationalité », en recopiant ce que j’ai écrit sur la page de discussion de WP:BIOFILM. Je confirme préférer la minuscule pour deux raisons importantes :
c’est le seul adjectif de l’infobox, inutile de faire des comparaisons avec les autres champs ;
si on met une majuscule, on crée une confusion car écrire un adjectif de nationalité avec une majuscule entraîne nécessairement que ça devient un nom commun (ou propre ?) de citoyen au féminin — ce nom commun de citoyen, qu’on appelle gentilé (voir la section Gentilé#Usage et l’exemple du « savant A/allemand »), doit en effet prendre la majuscule d’après les règles de typo —, et ça n’est alors plus un adjectif (de ce fait de confusion possible, certains seront alors tentés d’écrire « Français » quand c’est l’infobox d’un homme de nationalité française).
Par ailleurs, les modes d’emploi des Infobox sont faits au mieux par les développeurs mais ne font pas loi pour la typo, si aucune décision n’a été prise sur le sujet dans un sens ou un autre. Cinéma-1930 (discuter) 11 février 2025 à 12:49 (CET)Répondre
effectivement, Menthe Poivrée n'a pas l'air d'accord, mais ses arguments sont presque inexistants « je n'ai jamais vu... », « on fait comme les autres », ça me semble un peu léger, sinon l'autre lien n'a pas exactement le même sujet de discussion.
De plus, « notre » discussion est plus particulièrement liée au champ « nationalité » de l'infobox BPV ciné.
Mais je viens de notifier le Projet Cinéma, on verra.
Pour répondre au point plus haut concernant la nationalité, le fait que la nationalité soit un adjectif ne change rien. Si on considère que le tableau ne casse pas la structure en phrase, alors il doit en être de même pour tous les autres paramètres (avec une majuscule seulement lorsque celle-ci est attendue, e.g. nom propre). — Vincent Lefèvre (discuter) 12 février 2025 à 00:42 (CET)Répondre
Oui, c'est exactement (heuh... pas sûr d'avoir vraiment compris ce que tu veux dire) ce que je pense, il n'y a pas que la nationalité qui pose problème, mais c'est déjà assez compliqué pour ne pas en rajouter, selon moi.<r>
Si un consensus se dégageait sur la nationalité, on pourrait « s'attaquer » au reste, à savoir, par exemple, la profession ; « Actrice » me semble tout aussi incongru que « Française ». — jeep (j33p) ॐ12 février 2025 à 19:56 (CET)Répondre
L'idée (la mienne du moins) étant de respecter WP:CT avec comme préalable qu'il y a un deux-points sous-entendu entre le descripteur de champ et sa valeur, là, tout de vient limpide et simple. — jeep (j33p) ॐ12 février 2025 à 19:57 (CET)Répondre
Le plus important est que ce soit cohérent entre tous les champs; pas question de faire une exception sur la nationalité. Et les WP:CT ne disent nullement que c'est comme d'avoir un deux-points (et au passage, le Lexique indique une majuscule dans certains cas après un deux-points). En revanche, les exemples actuels d'infobox mettent des majuscules. — Vincent Lefèvre (discuter) 13 février 2025 à 00:10 (CET)Répondre
Il me semblerait effectivement utile d'être cohérent dans le traitement des champs.
@J33p : le 2d lien pointe vers une discussion générale, avec 3 ou 3 échanges sur la majuscule, qui peuvent être trouvés en cherchant « majuscule » (le reste du sujet est effectivement distinct). - Lupin (discuter) 13 février 2025 à 09:47 (CET)Répondre
Heuh... la « cohérence » de quel point de vue ? Moi je parle de typographie pas d'esthétique. Si l'on respecte la première, il ne peut pas y avoir de cohérence esthétique (mais dans une encyclopédie, cela me semble secondaire).
Je n'ai *jamais* dit que les WP:CT disent que c'est « comme d'avoir un deux-ponts », j'explique que pour respecter WP:CT, il faut, au préalable, admettre l'existence des deux-points « sous-entendus »; Quant au lexique, bien-sûr qu'il dit que, dans certains cas (noms propres et d'autres, voire WP:CT) il y a bien une majuscule après un deux points ! Je n'ai jamais voulu supprimer les majuscules,je veux qu'il y en ait quand c'est requis par la typo et uniquement dans ce cas, pas « partout par souci de cohérence esthétique ».
Je dis que quand tu as deux mots qui se suivent genre « Nom de naissance Shadoko » ou « Nationalité shadokienne », on peut presque dire qu'il manque un deux-points, si on était dans une phrase, on serait obligé, de par les conventions typo, de mettre un deux-points entre les deux et je dis également que, parce que les devs sont moins sensibles à la typo qu'à l'esthétique, ils ont choisi de virer ces deux-points qui auraient été logiques (par exemple, le descripteur de champ « Nationalité » pourrait, sans que ça ne gêne personne, être « Nationalité : » et, dans ce cas, on respecterait WP:CT et on aurait parfois des minuscules (Nationalité, Activités, etc.) et parfois des majuscules (Nom de naissance, etc.).
On pourrait se référer aux sections « Fiche technique » et « Distribution » qui, quand elles respectent WP:CT (il m'arrive régulièrement de corriger des erreurs dues aux soucis d'esthétique (ou de méconnaissance de la typo)) contiennent les deux. parce que là, les deux-points sont bien présents.
En résumé et pour finir, ce qui me motive, c'est que je pense que dans une encyclopédie la cohérence typographique est d’importance — donc, de priorité — supérieure à celle de la cohérence esthétique. — jeep (j33p) ॐ13 février 2025 à 17:06 (CET)Répondre
Merci @l'Escogriffe pour ces deux pointeurs, la discussion du sondage est très intéressante, je note que tu y dis toi-même : Tout champ d'infobox est assimilable à une phrase ,ce que je me tue à essayer de faire passer ici, dans ce cas, deux-points ou pas deux-points, il est clair que dans la « phrase » « Nationalité française » le second mot ne peut pas commencer par une majuscule, sauf si on n'est concerné que par l'esthétique et pas du tout par les conventions typographiques.
Je te remercie d'autant plus que je vois que @Cyril-83 dit exactement la même chose que ce que je me tue à répéter depuis le début : je rajouterai qu'il est aussi le résultat d'une réponse, à la manière d'un formulaire où il manquerait un deux-points..
Et j'y vois pas mal de pcW qui semblent penser comme moi.
En revanche, je ne comprends pas pourquoi ce sondage semble n'avoir jamais été fait ??? J'y lis :
« Début du sondage : 13 septembre 2021 à 00:01 (CET) Clôture du sondage : 28 septembre 2021 à 23:59 (CET) »
@j33p tu dois avoir sous les yeux une version datant d'avant le vote. La version courante a bien les résultats au début, et les avis en bas.
Dans ce message je ne donnais pas mon opinion, j'essayais de justifier un diff de Cyril-83 où il laissait la majuscule. Il ne devait pas avoir un avis très arrêté sur la question à l'époque puisque dans son message suivant que tu cites il mettait la minuscule.
Comme je disais en 2023, je n'ai pas d'opinion très forte sur cette histoire de majuscule et je suis prêt à mettre en place dans le code toute formule qui ferait consensus, si il y a un vrai consensus (parce que le risque est d'avoir plusieurs discussions éparses à 2-3 contributeurs, pas les mêmes, qui arrivent à des conclusions opposées). l'Escogriffe(✉)13 février 2025 à 22:19 (CET)Répondre
Oui, voilà, je suis parfaitement d'accord @l'Escogriffe, je serais également pour un consensus large (ds un sens ou ds l'autre, ce que je veux, c'est un truc clair écrit noir sur blanc ds une conv' ou, au moins, les docs des modèles), j'ai notifié le Projet Cinéma, mais cela ne semble pas mobiliser les foules.
D'autre part, je vois que, contrairement à ce que la discussion laissait à penser, il n'y a pas eu de question sur la typographie.
Peut-être faudrait-il en organiser un (concernant tous les champs de toutes les infoboxes : Cohérence esthétique (majs partout) ou cohérence typographique (des majs ou des minuscules, suivant WP:CT) ? Mais j'avoue que je ne me sens pas de taille à organiser un truc pareil... — jeep (j33p) ॐ13 février 2025 à 22:31 (CET)Répondre
Oui, merci pour les nouvelles infos. Il faudrait relancer le sondage cité (avec une nouvelle question sur ces minuscules/majuscules) ou en faire un nouveau.
Il faudrait rappeler qu’il faut respecter la typo :
mettre une minuscule à l’adjectif de nationalité sinon ça change le sens du mot qui devient un gentilé (voir Gentilé#Usage) ;
mettre une minuscule à une langue pour la même raison (voir le breton par exemple) ;
mettre une majuscule à un gentilé pour la même raison (voir Espagnols par exemple) ;
pour les autres champs, je ne vois pas de contrainte comme celle que je viens de citer, mais pourquoi pas passer à la minuscule, et remplir « actrice » pour le champ « Profession » ?
Oui, j'ai déjà fait cette proposition (Actrice -> actrice) plus haut (12 février 2025 à 19:56).
Ma proposition (je le rappelle) est de respecter la typographie (WP:CT#Majuscules), donc : tout ce qui, selon ces convs, n'est pas censé commencer par une maj., doit rester en minuscules (en gros, tout sauf les noms propres, certains groupements ou organisations, les dynasties, les établissements d’enseignement d’importance nationale (situés au niveau d’études supérieures) et les États et pays. De cette manière, on conserve la cohérence, chère à toutes les pcWs, mais celle-ci passerait de « esthétique » à « typographique ». Et (oops !) : d'accord avec tes autres propositions (ss réserve que je les ai bien comprises). — jeep (j33p) ॐ15 février 2025 à 18:06 (CET)Répondre
Oui, et... ? Si c'était le cas, il me semble que nous n'aurions pas ce looooong débat !? Les convs parlent de la typographie des articles, mais... seulement du plan ; c'est pourquoi, je propose d'augmenter leur « sphère d'influence » aux infoboxes qui ne respectent aucune règle à part celles de la progammation... et de la cohérence esthétique, or, comme il ne s'agit pas d'un github ou d'un OS, voire d'une page de manuel (et encore), mais d'une encyclopédie, ça me semble important de changer cela. Je vois bien que ce n'est absolument pas ton cas. — jeep (j33p) ॐ15 février 2025 à 20:01 (CET)Répondre
J'ajoute, pour tenter de faire avancer le Schmilblick, que ce serait bien qu'au lieu de répéter en boucle des dénégations d'ordre général :
Le plus important est que ce soit cohérent entre tous les champs
il doit en être de même pour tous les autres paramètres
que ce soit cohérent entre tous les champs
les conventions typographiques ne disent absolument rien sur les infobox
(pour cette dernière, je te propose justement de changer ça)
Pourquoi, donc, est-ce que tu n'argumentes pas sur pourquoi tu penses que l'esthétique doit primer sur la typo, pourquoi les infoboxes ne doivent pas respecter WP:CT ?
Moi j'argumente mes propositions, toi tu ne le fais pas pour tes dénégations, si on continue comme cela, on n'y arrivera jamais.
J'ai simplement fait remarquer que les WP:CT ne disaient rien sur les infobox, contrairement à ce que tu sous-entendais plus haut (cf ton "donc"). Et je n'ai jamais rien dit concernant l'esthétique! — Vincent Lefèvre (discuter) 15 février 2025 à 20:52 (CET)Répondre
Arf... d'accord Vincent, je voulais juste dire qu'il faudrait que les infoboxes respectent les convs (sous-entendu « ce qui les concerne dans les convs »), je me suis mal exprimé, je n'ai jamais voulu dire que le WP:CT concerne les infoboxes ! Je dis au contraire que je déplore que ce ne soit pas le cas et qu'on pourrait peut-être en profiter pour y remédier si cette proposition rencontre l'assentiment.
Et... tu n'as pas prononcé le mot esthétique, mais il m'a semblé que tu parlais de la « cohérence » des infoboxes : « des majs partout » (moi je lis « parce qu'autrement, c'est moche ») => esthétique, mais si je me trompe, vas-y développe tes arguments, pour quelle raison faudrait-il qu'il y ait des majs partout, alors que la typographie indique que dans certains cas c'est nécessaire et d'en d'autres non, chaque cas étant, par ailleurs, développé et expliqué ds WP:CT (je les ai même développées plus haut), je ne dis rien d'autre.
Et, encore une fois, tu me fais une dénégation (justifiée, je te l'accorde et t'en remercie, ça m'a permis de m'expliquer) ; mais tu n'argumentes toujours pas sur ce que tu ne veux ou ne veux pas et pourquoi.
Je suis d'accord qu'il est assez peu logique que les infobox ne respectent pas les CT.
WPfr s'est doté de CT afin d'avoir une cohérence et une infobox fait bien partie de l'espace des articles. Il semble normal que cela s'y applique, comme elles doivent s'appliquer aux légendes des images et figures par exemple. - Lupin (discuter) 17 février 2025 à 20:31 (CET)Répondre
D’autant que ne pas respecter la typo peut changer le sens de ce qu’on écrit : j’ai cité ci-dessus les trois cas de l’adjectif de nationalité, de la langue, du gentilé. Au moins pour ces trois-là, il est souhaitable de respecter la typo qu’on trouve dans une phrase ou un questionnaire. Ensuite pour tous les autres champs, ça peut être un choix, pour simplifier, on peut décider de respecter la typo standard… sauf cas particulier à trouver. P.-S. : il y a une multitude de noms propres qui commencent par une minuscule ; un qui me vient à l’esprit : cathédrale Notre-Dame de Paris. Cinéma-1930 (discuter) 18 février 2025 à 15:59 (CET)Répondre
Arf... mais, dans ce cas @Cinéma-1930, ne serait-ce pas « Notre-Dame de Paris » uniquement le nom propre ? Et « cathédrale » juste un substantif qui n'a pas a être en majuscule, cela suit logiquement WP:CT#Monuments et bâtiments publics il me semble.
Dans ce cas, on a l'infobox qui dit : « Type Cathédrale, basilique mineure », j'y verrais évidemment plutôt : « Type cathédrale, basilique mineure ».
Peut-être même que tout cela serait plus clair / automatique si on intégrait ces deux-points, on aurait :
@j33p (réponse à une remarque plus haut). Par « cohérence », j'entends : la même règle pour tous les champs. Donc systématiquement une majuscule en début de champ ou systématiquement une minuscule en début de champ, mais en tenant compte des règles générales ayant précédence (certains mots commencent toujours par une majuscule ; certains mots commencent toujours par une minuscule ; les titres (ne faisant pas partie d'une phrase) commencent toujours par une majuscule; etc.). — Vincent Lefèvre (discuter) 19 février 2025 à 00:32 (CET)Répondre
D'accord @Vincent, on commence à se comprendre (se rapprocher ?).
Mais alors, dis-moi quelle règle (en tenant compte des règles générales ayant précédence ferait que « Nationalité française » devrait devenir « Nationalité Française » ? Alors que, dans une phrase, la règle est bien d'utiliser la minuscule et il en va de même pour les champs « Formation », « Activités » et certainement beaucoup d'autres (si l'on prend la même règle pour toutes les infoboxes).
Arf... décidément, un coup je crois t'avoir compris et le coup d'après : *pschhttt* !
Tu écris en tenant compte des règles [...], puis quand je demande des précisions, tu me réponds Aucune règle.
De même que la phrase Mais il n'y a aucun rapport avec les infobox veux-tu dire que les infoboxes, selon toi, ne doivent pas suivre les CT ? — jeep (j33p) ॐ21 février 2025 à 15:08 (CET)Répondre
j33p : Il n'y a jamais « Nationalité Française » dans les infobox. C'est « Nationalité » dans une cellule du tableau « Française » dans une autre cellule. Puisque les CT ne donnent aucune règle concernant les cellules d'un tableau, les infobox ne contreviennent pas aux CT sur ce point. — Vincent Lefèvre (discuter) 23 février 2025 à 03:54 (CET)Répondre
Désolé @Vincent d'insister (oui, ça devient pénible, pour moi aussi) :
Je parlais des deux champs de l'infobox, évidemment (je respecte WP:FOI, mais je n'arrrive pas à comprendre ce que j'ai bien pu faire pour que cela ne soit pas clair !?!), [re-belote, donc] : Nationalité (descripteur).......................{F|f}rançaise (valeur)
et toi tu me parles... de « tableau » pourquoi est-ce que tu assimiles l'infobox à un tableau (array ?) et jusqu'ici, on parlait de « champs », voilà que tu me parles de « cellules » ??? j'y comprends de moins en moins, pour moi ce sont deux choses totalement différentes les tableaux et les infoboxes Je me trompe ?
j33p : Pfff... Avant de poser des questions débiles, ça ne te viendrait pas à l'idée de faire un minimum de recherche? Le mot « tableau » est utilisé dans la première phrase de Projet:Infobox. Dans sa présentation, Aide:Infobox utilise aussi le synonyme « table ». Quoi qu'il en soit, les CT ne disent rien sur la présentation en tableau, que ce soit le cas général ou dans un cas particulier comme les infobox. — Vincent Lefèvre (discuter) 23 février 2025 à 17:50 (CET)Répondre
Vincent Lefèvre : J'ai effacé ma réponse, en fait, je n'ai plus envie de continuer puisque tu ne gardes pas tes nerfs.
Le nom complet de l’édifice est cathédrale Notre-Dame de Paris, comme le dit l’article. Il est certes souvent raccourci dans les textes.
Je n’ai pas bien compris votre remarque finale : suggérez-vous d’ajouter des deux-points dans l’infobox ? Si c’est le cas, je serais surpris que ça passe car certains pourront trouver ça lourd esthétiquement, et non nécessaire en fait (car implicite). La question mériterait d’être posée. Cinéma-1930 (discuter) 19 février 2025 à 20:24 (CET)Répondre
Pour les deux-points @Cinéma-1930, comme toi vous, je les considère comme implicites c'est pourquoi je préconise ces minuscules ici et là, mais on me répond que « pas du tout », « où suis-je allé chercher cela », bref, cela n'est pas évident pour tout le monde, donc, j'en déduis que, pour que les minuscules s'appliquent bien en suivant les CT, le seul moyen serait que ces deux points ne soient pas « implicites » mais réels.
Je suis allé poser la question clairement : « est-ce que les infoboxes rentrent dans les CT ? » sur la PdD du projet CT, je n'ai eu de réponse que d'une pcW jusqu'ici et ça va plutôt dans le sens de Vincent que dans le nôtre. Mais c'est intéressant, et sympathique (merci @Pharma. — jeep (j33p) ॐ19 février 2025 à 22:11 (CET)Répondre
Mais j'ai quand même obtenu une « réponse » à ma question : « comme ce n'est effectivement mentionné nulle part, c'est un peu une question d'interprétation ».
Ce qui ne nous aide pas beaucoup, mais nous permet de comprendre pourquoi on a ces discussions interminables pour qq chose qui aurait pu [dû ?] se résoudre en trois posts.
Selon moi, la section « Liste sans : » est mal interprétée (par Pharma dans DW:CT) car chaque item commence avec le nom du champ, pas avec la valeur du champ. Et chaque item se termine avec la valeur du champ. Donc, la typo doit être respectée à l’intérieur de chaque ligne. Ce qui est conforme avec nos préconisations. Cinéma-1930 (discuter) 19 février 2025 à 22:59 (CET)Répondre
Merci de ta votre précision, parce qu'il se réfère à WP:TYPO#LISTES SANS : (que je ne suis pas certain d'avoir bien compris), mais je ne pense pas que cela soit conforme à ce que l'on trouve dans l'infobox (mais j'ai oublié d'aborder ce point, pfff...), pour moi il s'agit d'un couple avec relation entre les deux, comme dans n'importe quel formulaire Donc, effectivement, je suis d'accord avec... vous. J'ai d'ailleurs précisé que, selon moi, la forme « liste à puces » ne correspond en rien à ce qu'on trouve dans les infoboxes. — jeep (j33p) ॐ19 février 2025 à 23:22 (CET)Répondre
Bonjour. Je n'ai pas forcément suivi tous les détails de vos échanges, mais donne mon avis sur les points que j'ai compris : 1 nationalité = adjectif, donc toujours avec une minuscule 2 Noms propres = toujours avec une majuscule 3. autres cas de noms communs = pas de préférence. Cdlt, --Pa2chant.bis (discuter) 19 février 2025 à 23:35 (CET)Répondre
Merci @Pa2chant.bis, d'avoir pris, malgré tout, le temps de venir nous donner ton avis. Je comprends que tu n'aies pas eu l'envie (ni le temps) de tout lire.
Donc, on va considérer que pour le couple « Activités............activité1, activité2 » tu n'as pas de préférence pour « activité1 ». — jeep (j33p) ॐ19 février 2025 à 23:39 (CET)Répondre
Il y a de nombreux cas de noms propres qui commencent avec une minuscule. Je reprends l’exemple donné dans la discussion : cathédrale Notre-Dame de Paris. La distinction n’est donc pas : noms propres - noms communs. Elle devrait se faire sur : nom commençant par une majuscule - nom commençant par une minuscule (dans une phrase).
J’avais aussi indiqué que certains mots doivent commencer par une minuscule, sinon ça change le sens, voir les deux cas : adjectif de nationalité (car Française désigne la citoyenne de France) ; nom d’une langue (breton est la langue, Breton est un homme originaire de Bretagne). Cinéma-1930 (discuter) 20 février 2025 à 05:25 (CET)Répondre
jeep avait me semble-t-il répondu au premier point, du coup je reformule : dans le groupe nominal cathédrale Notre-Dame de Paris, cathédrale est un nom commun, et Notre-Dame de Paris un nom propre. Le nom propre prend toujours une majuscule. Concernant la langue, bretonne est un adjectif, et devrait donc prendre une minuscule (comme tous les adjectfs si l'on respecte la minuscule pour la nationnalité). C'est pour les noms communs que je n'ai pas de préférence (entendu que la règle doit être homogène pour eux). --Pa2chant.bis (discuter) 20 février 2025 à 06:24 (CET)Répondre
Lupin~fr :, j33p :, Cinéma-1930 :, GrandEscogriffe :, Vincent Lefèvre :, TwoWings :, Thibaut120094 :, Voxhominis : (j'ai notifié certains contributeurs qui je pense seront intéressés mais si vous avez d'autres personnes en tête, n'hésitez pas) Et donc, il va y avoir sondage / débat ou pas concernant le champ « Nationalité » ? Des contributeurs font par-ci et là ce qu'ils veulent avec cette histoire de Maj. / Min. Pour ma part, je suis un votant pour la Maj. (et si cela devait en être autrement soit), mais au moins s'il y avait un vrai sondage permettant une décision communautaire, ce serait pas mal, non... ? Skarocket le Doublage18 mars 2025 à 10:44 (CET)Répondre
Oui @Skarock, il y a aussi Pa2chant.bis :, Pharma :, AndréLegault :, Cyril-83 :, et Épicure : a minima, peut-être les Projets Cinéma et TV... mais je ne suis pas sûr qu'un sondage y change grand chose, suffit de regarder ce qu'il se passe avec les drapeaux (WP:DI + le + récent) qui n'ont pas changé grand chose ; tant qu'il n'y a pas une règle officielle dans les convs...
Bonjour chers contributeurs, vous pouvez m'ajouter en notification si un possible sondage/débat est prévu. Je travaille notamment sur les articles liées aux 24 Heures du Mans et cela serait très intéressant pour les {{Infobox Compétition sportive}}. À bientôt. --Smiley („“) 18 mars 2025 à 15:00 (CET)Répondre
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 1 an2 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 1 an3 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 1 an8 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 10 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 10 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 7 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 8 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 4 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 3 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 3 mois54 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)<
Le projet « Infobox » n'est pas notifié pour le moment.
Infoboxes portables
]
[je m'sens moins seul]
,
— jeep (j33p) ॐ 13 février 2025 à 21:57 (CET) 
— jeep (j33p) ॐ 13 février 2025 à 22:31 (CET) 
j33p : Aucune règle. Mais il n'y a aucun rapport avec les infobox. — Vincent Lefèvre (discuter) 20 février 2025 à 02:53 (CET) 
Je me trompe ?
!
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)
.svg){kind=link}