Discussion modèle:Saison de série télévisée/Épisode

Ajout Paramètre auxiliaire facultatif

Je sollicite votre avis. Le modèle utilise des paramètres les plus courantes et encore plus, mais certains champs auraient besoin d'être ajoutés.

1. Scénariste. Lorsqu'un épisode utilise Story by et Teleplay au lieu de Written by (exemple: The Big Bang Theory), y a-t-il moyen d'utiliser des champs pré-déterminés?
2. Des champs auxiliaires sont utilisés pour certaines séries, tels que Diagnostique final dans Dr House, Ennemi(s) et Lieu dans Supernatural, ou des remarques et la liste de chansons dans Glee, ainsi que d'autres séries qui m'échappent pour le moment.

Devrait-on utiliser des paramètres identiques "div 1" comme dans Modèle:Liste des épisodes? Qu'en pensez-vous? InMontreal (d) 5 février 2012 à 15:59 (CET)

Pour la 1, n'est-il pas envisageable d'écrire « scénario » en lieu et place de « scénariste(s) », et puis éventuellement de faire la distinction entre l'histoire et le script de cette manière :

Jean Sérien (histoire)<br>Jacques Hady (script)

Pour la 2, les champs annexes sont là pour les gimmicks des séries. Dans liste des épisodes, ils étaient essentiellement présents pour les scénaristes et réalisateurs. Je crois que c'est bon de conserver ces gimmicks. Cela répond-il à ta question ou suis-je complètement à côté de la plaque ?

— Frór ^Oook? 7 février 2012 à 23:12 (CET)

Argamea a modifié le modèle pour rajouter un champ gimmick.

Je ne suis pas d'accord avec ces modifications en l'état. Nous avons besoin d'un champ annexe pour le problème 1 souligné par InMontreal. Cependant, cela ne règle pas le problème des gimmicks.

Aussi, je propose d'utiliser les « champ annexe » et « contenu annexe » pour l'usage 1 attendu par InMontreal et de créer une autre paire de champs « nom du gimmick » et « gimmick » pour l'usage 2 montré par InMontreal.

Pour éviter un usage abusif le temps de la discussion, je vais annuler les modifications d'Argamea et les miennes. On n'aura qu'à les replacer une fois la discussion réellement close.

Qu'en pensez-vous ? — Frór ^Oook? 3 avril 2012 à 17:36 (CEST)

J'avoue ne plus te suivre, Frór. Juste au-dessus, tu mentionne d'utiliser les champs annexes pour ajouter les gimmicks, que tu précises souhaiter conserver. Puis, entre ma PDD et ici, tu souhaites non seulement les séparer des champs annexes, mais tu dis que les gimmicks n'ont que peu d'utilité? Il n'y a aucune agressivité dans mes propos, j'essaie juste de comprendre ton cheminement de pensée (en me relisant je me rends compte que cette phrase peut paraître mesquine, elle ne l'est en aucun cas).

Pour répondre à ta question du dessus, je pense qu'il serait bon d'ajouter un champ où inclure les gimmicks (qui sont vraiment un effort de production, à mon sens), et afin de se blinder pour l'"usage 1", autant faire d'une pierre deux coups et les mettre en "champ annexe". C'était là le cheminement de mes pensées qui m'ont conduit à ces ajouts.

Très cordialement, Argamea (d) 3 avril 2012 à 17:58 (CEST)

Un processus de pensée est évolutif, et je peux très bien ne plus être en complet accord avec ce que j'ai écrit il y a un mois. Tu as fait une implémentation, je l'ai regardée et j'ai observé les besoins. Ma conclusion a changé par rapport à il y a un mois.

En résumé, je pense qu'il faut faire la distinction entre un champ annexe qui est un problème plus large que les gimmicks. Il s'agit de rajouter des informations de production sur l'épisode.

Un gimmick est accessoire mais est incompatible avec les champ que InMontreal soulève dans son point 1. Je préfère choisir une option où les gimmicks sont clairement définis et encadrés.

Est-ce plus clair ? — Frór ^Oook? 3 avril 2012 à 18:11 (CEST)

P.S. Je n'ai vu aucune agressivité ni mesquinerie dans tes propos ;-)

Ajout :

De plus, cela évitera les plaintes du genre : "mais j'ai un gimmick et un paramètre extra, moi". — Frór ^Oook? 3 avril 2012 à 18:13 (CEST)

C'est tout à fait clair, et je trouve que cette solution (gimmick + annexes) répond bien à notre problème. Et en effet, cette option apporte une flexibilité pour d'éventuelles plaintes.

Argamea (d) 3 avril 2012 à 19:26 (CEST)

Bon, eh bien, techniquement, je propose de rajouter donc le champ « gimmick » juste sous le résumé et « champ annexe » sous « réalisateur ».

À propos et après vérification, gimmick est un anglicisme, donc accepté en langue française. Il n'est pas nécessaire de le placer en italique.

D'ici 24 h si aucun avis négatif ne se manifeste, je pense qu'on peut procéder à l'implémentation. — Frór ^Oook? 4 avril 2012 à 11:04 (CEST)

24 h plus tard, pas de réponse négative, je procède aux changements. — Frór ^Oook? 5 avril 2012 à 11:10 (CEST)

Petit problème avec Gimmick. Dans Saison 4 de Glee, en voulant fournir les chansons dans une liste (*), la première option est ignorée et apparaît comme une simple étoile. Ça fonctionne pourtant bien avec les diffusions, audiences et invités. InMontreal (d) 28 juin 2012 à 22:23 (CEST)

Fixé : j'ai repris la structure, légèrement différente, de l'audience pour ça et l'ai adaptée. — Frór ^Oook? 29 juin 2012 à 01:27 (CEST)

Après réflexion, les champs "annexe" ne sont pas utiles et non-utilisés, et il est plus facile d'intégrer Histoire (Story) et Mise en scène (Teleplay) dans le champ du scénario. Le problème est dans la suite logique: en utilisant le champ annexe, le crédit pour l'histoire serait situé après le réalisateur. C'est donc un champ à supprimer. Le champ suivant (autres crédits) est aussi rarement utilisé, mais il est là juste au cas où... InMontreal (d) 12 juillet 2012 à 19:22 (CEST)

Traduction littérale du titre

Bonjour,

Note : j'aurais du en discuter ici auparavant. Je n'y ai pensé qu'après, désolé. Si ça gène, n'hésitez pas à reverter.

Bref, j'ai donc rajouté un paramètre, appelé "traduction littérale" qui affiche la traduction littérale du titre, s'il est indiqué. Ceci car je remarque pas mal de problèmes d'affichage, notamment l'écriture en italique de la traduction par défaut si elle est simplement adjointe au paramètre "titre original". Le comportement actuel n'est pas changé.

J'ai adapté Saison 2 du Trône de fer pour refléter ce changement, si vous voulez voir ce que cela donne.

— Frór ^Oook? 23 mai 2012 à 14:20 (CEST)

Salut, j'avais remarqué que ça publiait par défaut les traductions en italique alors que c'est réservé aux titre d'œuvres principalement et cela était gênant. Donc, je suis Pour cette solution.

Par contre, je viens de modifier un article de saison afin de le mettre à jour et il manque un espace entre le titre original et la parenthèse de la traduction. Cdlmt. --Skarock ^Psychuck 23 mai 2012 à 17:40 (CEST)

C'est bizarre, parce que le code du modèle contient cette espace. Ce n'est par contre pas une espace insécable, mais une simple espace normale. Peut-être que le parseur la supprime. Je vais vérifier plus en détails. — Frór ^Oook? 23 mai 2012 à 17:49 (CEST)

Ok c'est bon, l'espace est pris en compte maintenant. Merci. --Skarock ^Psychuck 23 mai 2012 à 18:31 (CEST)

Section « résumé » à rendre invisible quand le champs n'est pas renseigné

Bonjour,

Ne serait-il pas possible de rendre invisible le champ « résumé », comme tous les autres, lorsqu'il n'est pas renseigné ?! Car actuellement, cela donne ceci.

Je ne sais pas le faire, alors si quelqu'un a les compétences nécessaires...

Merci d'avance, — Jules ^{• Discuter •} 23 juin 2012 à 15:41 (CEST)

J'ai essayé, j'ai raté.

Que penses-tu de mettre le modèle {{...}} à la place du résumé si le champ n'est pas renseigné ? — Frór ^Oook? 23 juin 2012 à 16:49 (CEST)

Salut, (ma réponse est une simple remarque et constation.)

En réalité, je pense que le champ « résumé » apparaît d'office car c'est lui qu'il faut privilégier et renseigner et non le champ « synopsis ». Je suis allé voir l'article que tu donnes en exemple et en déplaçant les qlqs lignes inscrites dans le champ « synopsis » vers celui du « résumé » cela réglera le problème (le « synopsis », lui n'apparaîtra pas). De plus, il n'y a que quelques lignes pour décrire l'épisode ce qui (à mon avis) correspond plus à un résumé.

Maintenant, si tu souhaites conserver le champ « synopsis » pour les résumés des épisodes, la solution de Frór est à choisir. Cdlmt --Skarock ^Psychuck 24 juin 2012 à 11:46 (CEST)

Ok, merci à tous deux ! Simple question : Entre synopsis et résumé, lequel des deux mots désigne un résumé court (qui donne juste envie de regarder l'épisode/lire le livre, etc.), et lequel désigne un résumé complet ? Amicalement, — Jules ^{• Discuter •} 24 juin 2012 à 11:49 (CEST)

Celui qui désigne un résumé court c'est le champ « résumé » (d'où son nom ) et le synopsis l'inverse puisqu'il peut servir pour développer l'histoire ou l'intrigue. Cdlmt. --Skarock ^Psychuck 24 juin 2012 à 11:58 (CEST)

Ok ! Je croyais que c'était l'inverse... Bon, ben j'ai plus qu'à tout inverser . Bonne journée ! — Jules ^{• Discuter •} 24 juin 2012 à 12:23 (CEST)

Du coup, j'ai inversé les champs « synopsis » et « résumé » : il est plus logique pour le lecteur d'avoir en premier un résumé court qui ne lui dévoile pas le fin mot de l'énigme, et seulement après un (éventuel) synopsis complet. Cdlt, — Jules ^{• Discuter •} 24 juin 2012 à 12:33 (CEST)

Et, tant qu'on y est, j'ai supprimé ceci : {| style="background-color:#FFFFFF;" dans le champs « résumé », qui ne sert plus maintenant que le fond est blanc... Cdlt, — Jules ^{• Discuter •} 24 juin 2012 à 12:43 (CEST)

Stop ! Le résumé correspond à l'intégralité de l'histoire résumée. Le synopsis à un aperçu léger de l'épisode. C'est ce qui est donné aux chaînes pour leur faire acheter l'épisode. Le résumé se doit d'être complet. En clair Jules78120, tu avais raison et Skarock, désolé, tu avais tort. — Frór ^Oook? 24 juin 2012 à 22:44 (CEST)

Ah bon, car pourtant un résumé c'est quelque chose que l'on résume... donc en quelques lignes. Cdlmt --Skarock ^Psychuck 25 juin 2012 à 10:56 (CEST)

Il me semblait bien, Frór... J'ai tout annulé. @Skarock : Pas grave, l'erreur est humaine . Du coup, « résumé » devrait bien disparaître quand non renseigné, mais comme on ne sait pas comment faire... — Jules ^{• Discuter •} 25 juin 2012 à 11:13 (CEST)

Skarock, un script de série, c'est 40 pages. Ici, nous ne notons jamais qu'une demi page au maximum. C'est donc bien un résumé. — Frór ^Oook? 25 juin 2012 à 12:44 (CEST)

dates de diffusion et les audiences en colonnes ?

 InMontreal : il faudrait mettre sur deux colonnes les dates de diffusion et les audiences, parce que qu'en il y en a beaucoup cela créé des sections à rallonge (cf Saison 1 de Stargate Universe). Pense tu que {{Colonnes}} avec nombre=2 fonctionnerai au lieu de taille=30 ? (PS : si tu pouvais me donner un ou des exemples d'articles à problème pour que je puisse voir). Prométhée33 (discuter) 8 septembre 2014 à 19:02 (CEST)

Je suis en désaccord à afficher des champs sur deux colonnes. Voir Catégorie:Saison en cours de diffusion qui inclut des séries dont l'ajout de dates dans les pays francophones sont en cours. Il n'y en a pas "beaucoup" : Pays d'origine, Canada, Belgique, Suisse, France et Québec. Une série américaine diffusée en simultané au Canada verra une ligne, mais peut aller sur deux lignes en cas de changement d'horaire (voir Saison 6 de Castle). Un lecteur qui ne regarde que la ligne d'un pays aura les yeux à gauche, puis à droite, puis de nouveau à gauche, et ooops, l'info est disparue. Trop d'inconvénients pour une minime économie d'espace verticale. La liste d'invités est la mieux appropriée pour des colonnes. InMontreal (discuter) 8 septembre 2014 à 20:18 (CEST)

D'accord, mais il y a tout de même un problème général de taille. Là où je pouvais voir deux épisodes sur mon écran sans le modèle, maintenant il y en a à peine un qui tient. Ne pourrais pas t'on éviter le retour à la ligne entre les noms des champs simples (qui tiennent en une ligne et leurs données. (exemple : Titre original, Numéro, Première diffusion, Scénario, Réalisation...) Prométhée33 (discuter) 8 septembre 2014 à 22:12 (CEST)

Mise en forme de paragraphes dans le champ « Résumé détaillé »

Bonjour.
J'ai constaté que lorsque le contenu du champ « Résumé détaillé » contient deux retours à la ligne consécutifs (dans le corps d'un article, cela entraîne le passage à un nouveau paragraphe), ce contenu ne s'affiche pas de la même manière selon qu'il y ait deux ou plus de deux paragraphes : s'il y en a plus de deux, tout va bien mais s'il n'y que deux, le changement de paragraphes ne s'effecture pas. Si je ne suis pas tout à fait clair, vous pouvez regarder cette page cette page. Le premier épisode ne contient que deux paragraphes et un contributeur a été obligé de rajouter un troisième saut de ligne consécutif car le passage au paragraphe suivant ne s'effectuait pas (il suffit de regarder cette version de l'historique). Il en résulte un affichage disgracieux. À l'inverse, l'épisode suivant qui contient trois paragraphes s'affiche correctement.
Quelqu'un aurait-il une idée ?
Cordialement, Patangel (discuter) 14 mai 2016 à 10:53 (CEST)

exemple

Autre(s) titre(s) francophones

Ligne 1

Ligne 2

Numéro de production

Ligne 1

Ligne 2

Première diffusion

Ligne 1

Ligne 2

Réalisation

Ligne 1

Ligne 2

Scénario

Ligne 1

Ligne 2

Audiences

Ligne 1

Ligne 2

Synopsis

Ligne 1

Ligne 2

Résumé détaillé

Ligne 1

Ligne 2

Ligne 3

Commentaires

Ligne 1

Ligne 2

 

Bonjour, j'ai ajouté un exemple ci-dessus qui illustre bien le problème qui est global pour tous les paramètres. La ligne vide qui devrait provoquer un retour à la ligne est sans effet. Par contre, je n'ai pas trouvé d'explication. Peut-être demander à WP:QT ? --FDo64 (discuter) 14 mai 2016 à 15:09 (CEST)

J'ai ajouté Ligne 3 dans le champ Résumé qui illustre bien que lorsqu'il y a au moins 3 paragraphes, le problème disparaît !!!

Et j'ai corrigé dans mon premier message le premier lien vers la page qui met en évidence le problème, je m'étais lamentablement trompé !

Cordialement, Patangel (discuter) 14 mai 2016 à 19:54 (CEST)

Problème discuté sur le Bistro. — Oliv☮ ^{Éppen hozzám?} 15 mai 2016 à 07:47 (CEST)

Bonjour, j'ai appliqué la recommandation à tous les champs du modèle et en ai également profité pour enlever des tests complètement inutiles (en double). Voir résultat dans l'exemple ci-dessus. A+ --FDo64 (discuter) 15 mai 2016 à 16:38 (CEST)

 FDo64 : je ne sais pas si c'est volontaire, mais il y a maintenant un espace assez important entre les paramètres et les informations. --Anakindu72 ^(discuter), le 15 mai 2016 à 17:36 (CEST)

J'ai suivi à la lettre le conseil de  Od1n qui permet d'avoir un interligne standard. Si par contre on veut resserrer le texte, il suffit de ne pas passer à la ligne avant le /div. C'est comme vous voulez ! --FDo64 (discuter) 15 mai 2016 à 19:01 (CEST)

Je parle des paramètres, comme « Titre original » et tous les autres, pas du résumé. Anakindu72 ^(discuter), le 15 mai 2016 à 20:44 (CEST)

Moi aussi. L'interligne est devenu standard pour l'ensemble du modèle. Voir l'exemple. --FDo64 (discuter) 15 mai 2016 à 21:13 (CEST)

Standard peut-être, mais je trouve que c'est trop espacé entre le paramètre et l'information. Du coup la section dédiée à l'épisode est encore plus longue. --Anakindu72 ^(discuter), le 15 mai 2016 à 22:20 (CEST)

D'accord concernant l'espacement vertical trop grand. Comme mentionné ci-dessus par FDo64, j'ai défait les sauts de ligne avant les </div. od†n ↗^blah 15 mai 2016 à 23:34 (CEST)

Depuis les modifications de Voxhominis du 2 mai dernier où il a décidé d'inverser les champs de scénariste et réalisateur, la bouette d'éditeur visuel déplace les champs "réalisateur" et "scénariste" tout en bas du modèle, pour aucune raison valable. Quelqu'un a une idée du bug de cette bouette ? InMontreal (discuter) 18 mai 2016 à 14:26 (CEST)

 InMontreal : Bonjour, l'éditeur visuel trie les champs dans l'ordre où ils sont affichés dans la section TemplateData de la documentation du modèle. Je constate que les modifications ont eu deux objectifs : remettre les champs dans l'ordre où ils sont affichés et le remplacement de scénariste par scénario et réalisateur par réalisation pour être conforme aux titres affichés par le modèle. Ce sont ces renommages qui posaient problème parce qu'ils ne se trouvaient pas dans la section TemplateData. Je les ai ajouté, peux-tu confirmer que l'EV fonctionne bien à présent ? --FDo64 (discuter) 18 mai 2016 à 18:26 (CEST)

Négatif, Houston : diff. InMontreal (discuter) 20 mai 2016 à 16:39 (CEST)

Alors je ne sais pas ... --FDo64 (discuter) 20 mai 2016 à 19:55 (CEST)

Bonjour à tous. Je viens de tester l'EV (il y a un début à tout !). Si tant est que j'aie compris le problème soulevé, les champs apparaissent non seulement au bon endroit dans les options, mais s'affichent aussi correctement. L'exemple fourni semble être un ajout manuel de contributeur, renforcé par le fait que ce sont les anciens libellés qui sont utilisés (réalisateur/scénariste)et non ceux du modèle. Cordialement, --V°o°xhominis ^[allô?] 21 mai 2016 à 12:01 (CEST)

Code de production et numéro de production

Bonjour @Frór, @Heddryin, @Prométhée, @Jules78120, @Voxhominis, je me permets de vous solliciter étant donné que vous êtes les principaux rédacteur du modèle. Quel est la différence entre un code de production et un numéro de production ? Je ne suis pas sur que tout le monde connaisse la différence, il faudrait à mon avis l'expliquer quelque part dans le modèle.--Clodion 7 septembre 2016 à 12:13 (CEST)

C'était plus clair avant la modification. Le "numéro" est habituellement l'ordre de diffusion du diffuseur original choisi par wikipedia (ex: 45 (3-01) = 45^e épisode depuis le début de la série, 1^er épisode de la 3^e saison), alors que le code est celui fourni par la production (ex : NG-301), qui est utile surtout avec les sitcoms pour indiquer au lecteur dans quel ordre ils ont été produits. Lors de la sortie d'une saison en DVD, l'ordre de diffusion (numéro) ou l'ordre de production (code) sera conservé, selon l'impact des épisodes sur la continuité. InMontreal (discuter) 15 septembre 2016 à 17:01 (CEST)

Je rejoins l'avis d'InMontreal. Comme je l'ai déjà dit sur l'une des discussions qui concerne ce « problème », la version actuelle porte à confusion et pose une question de différence entre les deux. --Anakindu72 ^(discuter), le 15 septembre 2016 à 17:39 (CEST)

Donc concrètement on fait quoi ? --Clodion 20 septembre 2016 à 16:38 (CEST)

On précise :

code de production : code interne du producteur permettant d'identifier l'épisode (par exemple).

ordre de diffusion : quantième de l'épisode dans l'ordre de diffusion original (par exemple aussi).

Des avis ?

Cordialement,

Heddryin ^💭 20 septembre 2016 à 17:25 (CEST)

"Ordre de diffusion" va semer aussi la confusion. Par exemple, durant la Saison 1 de Supergirl, les épisodes 4 et 5 ont été inversés sur CBS à la suite des attentats de Paris de 2015, mais il y a un détail de continuité qui fait que l'épisode diffusé le 23 est listé avant celui du 16 novembre. Quant à Épisodes de Pan Am, c'est carrément l'incompétence d'ABC, déçu des cotes d'écoute, qui a résulté que le 7^e épisode qui concluait un arc avec un personnage, a été diffusé avant la finale. Parlant d'ABC, pourquoi pas mentionner Body of Proof, qui a débuté dans d'autres pays avant ABC, trop tard au printemps, et dont le découpage est un vrai casse-tête. Treize épisodes pour la saison 1, mais pas d'après l'ordre de diffusion d'ABC. Dans ces trois exemples, les pays francophones ont diffusé ces séries dans l'ordre logique. Tant qu'à y être, Firefly a été diffusé dans le désordre total avant d'être annulé. Je vote pour l'ordre logique/chronologique par-dessus la volonté des diffuseurs pour les dramatiques. Pour les sitcoms, c'est généralement plus facile d'inverser des épisodes sans effet sur la continuité. InMontreal (discuter) 20 septembre 2016 à 18:22 (CEST)

Je comprends très bien ton point de vue... auquel je n'avais pas songé. Voir Fringe, également, qui voit au cours de la saison 2 la résurrection d'un personnage mort durant la saison 1...

Dans ce cas, que proposes-tu à la place d'ordre de diffusion ? Personnellement, je n'ai pas d'idée. Pour le moment...

Heddryin ^💭 20 septembre 2016 à 23:02 (CEST)

EDIT : ordre dans la saison, ou quelque chose d'approchant ? Heddryin 20/09
23:05

Ajout de la possibilité de rendre les résumés déroulants

Bonjour, suite à mes modifications sur l'article Saison 1 des Soprano, je pense qu'il serait nécessaire de rendre les résumés déroulants. En effet, je trouve que ces résumés alourdissent l'article (en longueur) et qu'ils gagneraient à être cachés à moins que le lecteur désire les voir. De plus, cela permet de rendre ces articles « spoiler free » (bien qu'à mon avis personne ne devrait lire ces articles sans avoir vu les épisodes avant…). Il s'agirait cependant de rendre le déroulement optionnel (avec une option oui/non) au cas où. J'attends des retours ; je serais peut-être capable de faire la modification moi-même, mais si quelqu'un a de l'expérience je passe volontiers mon tour. Salutations, Espandero (discuter) 14 février 2021 à 10:08 (CET)

Pour info, j'ai fait un premier test d'affichage dans mon brouillon (voir ici). Il manque les if mais je ne sais pas comment en faire hors des modèles. J'ai également remarqué que, n'étant pas administrateur, je ne peux pas modifier ce modèle moi-même. - Espandero (discuter) 14 février 2021 à 14:26 (CET)

Ce que vous cherchez, c'est le modèle {{Boîte déroulante}} (lire la documentation). Mais les boîtes déroulantes ne sont pas conseillées dans un article de saison : Le lecteur visite cette page principalement pour lire le synopsis et/ou le résumé de chaque épisode. InMontreal (discuter) 14 février 2021 à 14:46 (CET)

Non, ce n'est pas ce que je cherche. J'aurais pensé à quelque chose plus proche de {{Album}} (sans le trait sous le titre), avec une certaine transparence (en gros, la boîte ne devrait pas être visible). Le test dans mon brouillon correspond à ce que j'ai en tête. - Espandero (discuter) 14 février 2021 à 15:00 (CET)

Fond blanc

Bonjour,

Y a-t-il un réel intérêt d'avoir défini le blanc en tant que couleur de fond de ce modèle (background-color:#FFFFFF) ? Cela ne pose pas de problème la plupart du temps mais il s'avère que le fond blanc apparaît sur l'application mobile lorsque le thème de l'application est défini sur sombre. C'est assez disgracieux sachant que tout le reste de la page est sur un fond noir (avec une écriture blanche, cette couleur étant je suppose générée automatiquement selon la couleur de fond). Ne serait-il pas tout simplement plus simple de supprimer ce paramètre dans la balise <div> ?

Apparemment, la présence d'un tel paramètre est historiquement dû au fait que le fond était au départ gris et qu'il a ensuite été changé en blanc. Cordialement, — Antimuonium ^{U wanna talk?} 2 février 2023 à 22:01 (CET)

Comme je n'ai pas eu de réponse au bout de plus de 2 semaines et que la modification est assez mineure et cosmétique, j'ai effectué la modification. On peut revenir à la version précédente si besoin. — Antimuonium ^{U wanna talk?} 19 février 2023 à 09:12 (CET)