This template is within the scope of WikiProject Infoboxes, a collaborative effort to improve the coverage of Infoboxes on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InfoboxesWikipedia:WikiProject InfoboxesTemplate:WikiProject InfoboxesInfoboxes
This template is within the scope of WikiProject Biography, a collaborative effort to create, develop and organize Wikipedia's articles about people. All interested editors are invited to join the project and contribute to the discussion. For instructions on how to use this banner, please refer to the documentation.BiographyWikipedia:WikiProject BiographyTemplate:WikiProject Biographybiography
I think subordinate countries should generally be included, because removing them makes the infobox much less informative. Using your examples, for instance:
Berlin: whether someone was born in East or West Germany makes a major difference in their biography
Soviet republics: removing them makes the location information 15 times less informative - we can no longer tell if someone was born in Russia, Ukraine, Belarus, Uzbekistan, Georgia, etc but just a vague "Soviet Union". This is especially true for less widely known place names, e.g. (picking a random place) Korostyshiv, Soviet Union would not say very much to many people, whereas Korostyshiv, Ukrainian SSR, Soviet Union would at least let readers see that the person was born in Ukraine.
How I think we should condense place names in infoboxes instead is to remove subdivisions below the level of subordinate countries - e.g. the Oleksandr Syrskyi article's infobox now lists his birthplace as Novinki, Vladimir Oblast, Soviet Union. This is the worst of both worlds as it skips mentioning that he was born in Russia, but instead includes an oblast name that most readers not already familiar with the region wouldn't be able to place. Instead, I think this should be Novinki, Russian SFSR, Soviet Union. We also shouldn't list both subordinate countries and their subdivisions, e.g. Kryvyi Rih, Dnipropetrovsk Oblast, Ukrainian SSR, Soviet Union would be too long, but Kryvyi Rih, Ukrainian SSR, Soviet Union is just right IMO. Helpful Cat🐈(talk)13:32, 7 June 2025 (UTC)[reply]
Thanks for linking these. I do disagree that Soviet republics are unnecessary content, for the reasons I outlined above - Novinki, Russian SFSR, Soviet Union is useful in a way that Novinki, Soviet Union is not, because "born in the Soviet Union" is true of most people from that region who are 35 or older, and adds very little value. I can see the argument for removing Soviet republics when the city is very well-known (e.g. Moscow), but I wouldn't want to create a blanket guideline that subordinate countries should never be listed.
Per MOS:INFOBOXPURPOSE, the reason for conciseness is to [allow] readers to identify key facts at a glance - I think this would err too far on the side of removing key facts, rather than making them more accessible. If I saw Novinki, Soviet Union in an infobox, I would have to look at the article text to see where that is, defeating the point of the infobox. But this is my opinion, and it would be good to see if there's a community consensus on this. Helpful Cat🐈(talk)17:16, 7 June 2025 (UTC)[reply]
Most Soviet people are considered to be Russian citizens
Well, no, that only applies to people from the Russian SFSR, not people from the other 14 Soviet republics. (Arguably the likelihood that readers will assume the Soviet Union = Russia is another reason why listing Soviet republics is an important clarification)
Yeah, I see that some users are currently doing this. My opinion (since I guess this discussion is meant to gather opinions) is that they shouldn't for all the reasons I listed above, though. Helpful Cat🐈(talk)13:33, 14 June 2025 (UTC)[reply]
Not for people born in (or near) the largest cities in historical period (for example, Berlin, Germany, but not Berlin, Kingdom of Prussia, German Empire, because the German Empire or Weimar Republic is the common name for Germany). Everybody knows what capital and largest cities (including Berlin or Moscow) are. Infoboxes should be concise. On the other hand, specifying a small town and administrative division (for example, Gorki-10, Moscow Oblast, Soviet Union, but not Gorki-10, Russian SFSR, Soviet Union) because it forces the reader to follow the link for the town that they might not know. Absolutiva (talk) 03:37, 15 June 2025 (UTC)[reply]
Yeah, I can see the argument for leaving out Soviet republics or other subordinate countries when the city is extremely well-known.
On the other hand, specifying a small town and administrative division (for example, Gorki-10, Moscow Oblast, Soviet Union, but not Gorki-10, Russian SFSR, Soviet Union) because it forces the reader to follow the link for the town that they might not know.
Sorry, I don't really understand this sentence, maybe you could clarify?
I generally think that if we're going to list one subdivision, it should be a Soviet republic rather than an oblast (or in general, a subordinate country rather than a lower subdivision). Let's change your example a bit (because Moscow Oblast is obviously in Russia as you said). I think Gorki-10, Gorki Oblast, Soviet Union tells the reader very little, while Gorki-10, Russian SFSR, Soviet Union at least tells the reader that this place is in Russia. Helpful Cat🐈(talk)14:15, 17 June 2025 (UTC)[reply]
By avoiding the use of Soviet republics, for example, in Maxim Gorky's infobox where he died, in a small town: Gorki-10, Moscow Oblast, Soviet Union should be different by using subdivisions of the Russian SFSR. For the capital city in oblasts, krais and autonomous oblasts, by avoid repeating unnecessary subdivision: Moscow, Moscow Oblast, Soviet Union, so that Moscow, Soviet Union, would be simple and concisely. Absolutiva (talk) 01:35, 18 June 2025 (UTC)[reply]
At the very least, let's establish that no further regional clarification is needed for immediately recognizable major cities such as Berlin, Moscow, St. Petersburg, Kiev. (For Berlin, one can use West Berlin if necessary, which is indeed important.) Similarly, for a small town in a large city's area it would be precise and sufficient to specify Moscow Oblast or Leningrad Oblast. And even if RSFSR ever needs to be mentioned, this alone is just too broad, it could be anywhere between Kaliningrad and Vladivostok. It's much less of a problem for the other Soviet republics since they are all much smaller. — Mike Novikoff16:50, 20 June 2025 (UTC)[reply]
I agree with @Thedarkknightli here; I think "Russian SFSR" is useful in those infoboxes. One can easily imagine a reader with the basic question "Was Putin/Gorbachev born in Russia?", and the infobox should answer that quickly. This is especially true for Gorbachev, as Privolnoye, North Caucasus Krai is not an easily recognisable place; however, I would argue it's also useful and does no harm for Putin, as Leningrad has undergone so many historical name changes that readers could be forgiven for not instantly recognising it. Infoboxes should be useful to readers and allow them to "identify key facts at a glance"; while that means being concise, it also means not removing key facts that are useful to readers. Helpful Cat {talk}03:05, 24 July 2025 (UTC)[reply]
"Russian SFSR" is not any more recognizable than Leningrad - most readers will not understand that to be the country now known as Russia. Nikkimaria (talk) 05:38, 25 July 2025 (UTC)[reply]
I've got to disagree - I think it's intuitive to many/most readers that the Russian SFSR corresponds to Russia, the Ukrainian SSR corresponds to Ukraine, etc. In comparison, if you don't know a city name, you have no way of placing it. Helpful Cat {talk}10:20, 26 July 2025 (UTC)[reply]
Birth name
The guidance for |birth_name= at Template:Infobox person states: "Name at birth; only use if different from |name=." This has been interpreted in two ways:
Use |birth_name= for the full birth name, unless the full birth name already appears in |name=. Example: |name=Richard Nixon and |birth_name=Richard Milhous Nixon in the article about Richard Nixon.
I am fairly sure the intended meaning is the first one. I have looked at many biographical articles, including many good articles and featured articles, and they all include the birth name in the infobox. Template:Infobox person gives the example of Bill Gates: |name=Bill Gates|birth_name=William Henry Gates III. And Template:Infobox academic gives the example of C. S. Lewis: |name=C. S. Lewis|birth_name=Clive Staples Lewis. Khiikiat (talk) 10:44, 27 June 2025 (UTC)[reply]
Criminal convictions
We have the parameter "criminal_charges", which is "for convicted criminals only". So shouldn't the parameter rather be "criminal_convictions"? —St.Nerol (talk, contribs) 15:45, 2 July 2025 (UTC)[reply]
Title parameter issue
Something has gone wrong in the "title" parameter. The text appears extremely large, a different font, etc. etc. See for example: Lisa Su. This is an issue going on with every article with the parameter. GuardianH08:34, 6 July 2025 (UTC)[reply]
Vanisaac Possibly this is an issue going on only with my system (Macbook, Chrome). For some reason, anything in the parameter appears in an enlarged white-only font. GuardianH22:49, 6 July 2025 (UTC)[reply]
I can only surmise it has something to do with the class42=title for that data. Anyone know what's going on there or why it's in the code? I don't know how CSS works on Wikipedia, and it's very badly documented, but that seems misplaced to me. VanIsaac, GHTVcontrabout03:39, 7 July 2025 (UTC)[reply]
When I use "View Source" for {{Infobox person}}, somewhere around line 125 is "| class42 = title". My understanding is that will format data42= based on the CSS class "title", whatever that is. I'm wondering if that's causing the issue with that line specifically on their device. VanIsaac, GHTVcontrabout03:04, 8 July 2025 (UTC)[reply]
| title = {{no wrap|President and CEO of [[AMD]]}} (2014–present)<br/>Chair of AMD (2022–present)
this is as if Template:Infobox was being fed
| label42 = Title
| data42 = {{no wrap|President and CEO of [[AMD]]}} (2014–present)<br/>Chair of AMD (2022–present)
| class42 = title
and the emitted HTML is
<tr><thscope="row"class="infobox-label">Title</th><tdclass="infobox-data title"><spanclass="nowrap">President and CEO of <ahref="/wiki/AMD"title="AMD">AMD</a></span> (2014–present)<br>Chair of AMD (2022–present)</td></tr>
I feel that class="infobox-data title" seems like it would be a CSS class for formatting article titles in an infobox, and that it would probably be inappropriate for a job title. I think it's probably what is causing the issues for GuardianH. VanIsaac, GHTVcontrabout21:53, 8 July 2025 (UTC)[reply]
A class is not necessarily used for CSS formatting; some classes have purposes that are totally unrelated to formatting. In this case, the infobox-data is used for formatting (it applies two declarations, text-align: left; and vertical-align: top; to the data cell where that "President and CEO of ..." text appears), but the title class is present for the benefit of external tools, in order to detect the type of data held in each cell - in this case, a job title. --Redrose64 🌹 (talk) 23:32, 8 July 2025 (UTC)[reply]
Issue with "Spouse" section and divorce.
I noticed on Miley Cyrus' page it says her spouse is Liam Hemsworth. (and vice versa) They are divorced and were married for barely over a year. One of these people was really abusive to the other. Google searches for "Who is Miley Cyrus' Spouse" gives her ex husband's name in enourmous 150 pt font with Wikipedia listed as the source. I know the idea is that it says Spouse if there's one and Spouses if there's two or more. I also understand the section is designed to be a list. Can we make it say "Marriage history" or "Former spouse" if there's one person AND a divorce date? Is there a better idea for renaming? A lot of the history of Marriage comes from literal ownership, Mrs. means "belonging to the mister." I don't think people who were divorced want listed under "Spouse" and it's generally confusing. GlowingLava (talk) 14:12, 21 July 2025 (UTC)[reply]
The infobox states both the year they were married, as well as the year they were divorced, directly after the name of the respective spouse. Google AI's inability to glean context is a Google problem, not a Wikipedia problem. The information is clearly and concisely stated, with context provided immediately after the name. Literally within a dozen text characters after the name, you can see that they are divorced. I don't know what else we can do without misleading readers by withholding pertinent information. Talk to Google - they're the ones lying to readers. VanIsaac, GHTVcontrabout04:09, 24 July 2025 (UTC)[reply]
Thanks, the Google thing is just an example. The issue is more fundamental to the English language. If someone asked who your spouse was and you said your ex-spouse's name, you'd be wrong. Does the infobox have the ability to avoid this confusion? More than half the marriages in my country end in divorce, the infobox should be able to elegantly handle this situation or be worded as not to cause the problem in the first place. GlowingLava (talk) 06:14, 24 July 2025 (UTC)[reply]
Tooltips for relatives and partners
Should we add a tooltip for the relatives and partners parameters? I frequently see a lot of back-and-forth edits of users adding exhaustive lists of non-notable relatives and partners to infoboxes. The labels would read Relatives and Partners. MB243723:42, 31 July 2025 (UTC)[reply]
Nay. It's semantically redundant, and would imply any other parameter in the infobox somehow needn't be "notable"—i.e. key information on a topic. What's more, given the majority of our readers are on mobile, which has as a rule spurned use of the <abbr>...</abbr> HTML tag, our style policy of avoiding it whenever possible and never using it for bespoke information seems better-justified than ever. Remsense 🌈 论23:46, 31 July 2025 (UTC)[reply]
(It seems to me that infobox inclusion tugs-of-war are more or less endemic to how Wikipedia works, and there's not really any quick fix for that other than educating newer editors about the consensus regarding what information infoboxes are capable of presenting well.) Remsense 🌈 论23:51, 31 July 2025 (UTC)[reply]
Religion parameter for non-clergy
The RFC deprecrating the parameter stated it would 'Permit inclusion in individual articles' infoboxes (through the template's ability to accept custom parameters) if directly tied to the person's notability, per consensus at the article.', would someone be able to explain how one can do this? I believe including religious affiliation of ecclesiastical architects is appropriate and within the scope of the infobox purpose. Traumnovelle (talk) 00:48, 20 August 2025 (UTC)[reply]
Can you link to an article as an example where this would be helpful? In that article, what source identifies the religious affiliation? Johnuniq (talk) 02:57, 20 August 2025 (UTC)[reply]
I haven't finished writing the expansion but I was planning on using it for Frederick de Jersey Clere, an architect who primarily designed churches, was hired as an architect by an Anglican diocese, member of the synod, and whose most notable work was on Anglican churches.
If one of the many date templates is in use already (i.e {{birth date}} or {{death date and age}}) the module does nothing. It will not change the output in any way.
If raw dates are passed in (|birth_date=12 Nov 2002, |death_date=2009 etc.) the code will call the appropriate template to wrap the value in hCard microformat. The code will also automatically place the age in either the birth or death section depending on whether the person is still alive (determined by whether the |death_date= is set to a value or not).
The code will automatically determine if an age range is appropriate (this occurs when only a year is provided and not a full date).
The code will also allow for cases where a reference appears after the date. It will parse the date and leave the reference in place.
I have created a myriad of test cases which can be found in the respective documentations for {{Infobox person/birth}} and {{Infobox person/death}}. I have also implemented the code in {{Infobox person/sandbox}} as well as added a number of testcases to the testcases page for the infobox.
I would LOVE some feedback on what people think of this code. Please try to break it and let me know if there are edge cases I have not accounted for. I’d love to add this to the Infobox but want to get a little peer review before I shove it into use.
The "Month and Year only" does not always compute the age correctly. Somebody born on 30 September 1993 is not 32 years old on 18 September 2025, while someone born on 1 September 1993 is. Shouldn't the output be "31–32 years"? —Kusma (talk) 13:55, 18 September 2025 (UTC)[reply]
Nice catch. I worked back in 2015, I think, to get this range issue sorted out in some of the age templates. I have further adjusted two of the test cases to use the current month name in order to test this age range ambiguity. – Jonesey95 (talk) 15:14, 18 September 2025 (UTC)[reply]
@Jonesey95: it would appear you have found a bug in {{b-da}} because:
{{b-da|Dec 12, 1795}} → Dec 12, 1795 (1795-12-12) (age 229)
{{bda|1795|12|12}} → Error: Invalid birth date for calculating age
@Redrose64, WOSlinker, and Jonesey95: went back to the drawing board and made some major changes. It is a bit more selective now. It will NOT process date ranges (i.e. |birth_date=1990-1991) and will simply display the unparsed input, but it is far less likely to break. The regex now matches from start to finish, rather then just the start of the line. So hopefully there will be fewer issues. Please test away at your leisure and let me know if you find any errors.
Note that I have initiated a discussion at {{b-da}} about the case where the day is not known and the month is the current month (ex: {{b-da|October 1990}} which should display an age range but instead displays October 1990 (1990-10) (age 35)). That discussion can be found here. I’ll keep an eye on that but is a fairly small use case and is a preexisting bug so I don’t think it should delay this module… Thanks in advance for the assistance! —Zackmann (Talk to me/What I been doing) 09:16, 22 September 2025 (UTC)[reply]
I don't love the last bit, where you would be spreading known bugs into this template. We know that Module:Age does some validity checks; why not use that module instead of a buggy template? – Jonesey95 (talk) 12:12, 22 September 2025 (UTC)[reply]
@Jonesey95 and Gonnym: The reason for using {{Birth date and age text}} is it simplifies the parsing of string. I don’t have to convert 12 August 1990 to 1990|8|12 to call the agreeably better {{birth date and age}} (or related template). If you feel strongly that this code needs to use that format, I can certainly venture down that avenue. Literally as I’m typing this I’m thinking that I actually agree with you… … So I will make that my goal tonight. I’ll do another refactor. I think I can make use of Module:Date to simplify my work… To be continued. Thanks again for the feedback! Zackmann (Talk to me/What I been doing) 21:47, 22 September 2025 (UTC)[reply]
This happens to me all the time. It takes me actually typing out a response or a question to figure out what I should really do. Keep plugging away, and ask for feedback when you make some progress. – Jonesey95 (talk) 00:15, 23 September 2025 (UTC)[reply]
Ok… Jonesey95 I think I’ve got it working. I’ve looked through the testcases as well as the documentation for both {{Infobox person/birth}} & {{Infobox person/death}} (which both have a bunch of their own test cases). There are definitely areas for future improvement. For example, at the moment the code will not parse dates that have a reference (it just displays the original input unchaged). But I cannot find any testcases that break or cause errors.
The functions should not be changing a DMY formatted date into a MD,Y formatted date. {{infobox person/birth|1 January 2000}} → (2000-01-01) 1 January 2000 (age 25) -- WOSlinker (talk) 20:59, 23 September 2025 (UTC)[reply]
Lots of pages with a birthdate but the deathdate is unknown. The workaround is of course to just set |death_date=Unknown. This suppresses the code from trying to calculate the age. An example of this is Lucas Boada. I would imagine that someone may want to be able to suppress the display of deathdate from the infobox when it is unknown without causing the code to go berserk… Anyone have thoughts on that? Maybe creating another param along the lines of |suppress_death_date=? Open to any suggestions.
There are a few pages that are {{Infobox royalty}} for fictional characters. For example Belgarion. This fictional character was born in the year 5355 so naturally this causes the code to get very confused. My thinking of how to resolve this is that the page should use {{Infobox character}} (which will NOT get the Module:Person date treatment because fictional characters can live longer than 130 years). Again open to suggestions.
For the unknown death dates, maybe just embed the date/age template inside a conditional {{#switch:deathdate|unk|unknown=birth date info|#other=date/age template logic}}. VanIsaac, GHTVcontrabout17:11, 26 September 2025 (UTC)[reply]
So ran into an issue… When you embed a {{Infobox person}} wrapper, you have to manually pass in a header. For example see 9lokkNine which embeds {{Infobox person}}. In order to get a header over the criminal section, you must do
I’m going to modify {{Infobox person}} so that wrapper templates can pass in a custom header for when |child=yes or |embed=yes. Wanted to make sure there are no unforeseen consequences to this. Anyone have objections?
On second thought, it's a bit more complex than I thought, since {{infobox criminal}} is a wrapper for infobox person. I wonder if there is code in the template wrapper that allows passing a subheader when the template is a child template. I have been on WP too long today to go looking now. – Jonesey95 (talk) 00:36, 27 September 2025 (UTC)[reply]
I removed the div tags in |subheader2= after the above discussion in order to fix Linter misnested tag errors. That edit was reverted without discussion by Goszei, who claims that it violated MOS:SMALLFONT. That piece of MOS says that font sizes can't go below 85% of the article's base font size. When I look at this test case, in which the live template has a 125% increase in font-size, the subheader2 text (the Russian name) is rendered at 110% of the base font size (i.e. 125% * 88%). When I look at the sandbox, which has the pre-revert state with no change in subheader2 font sizing, the subheader2 text (the Russian name) is rendered at 88% of the base font size (i.e. the default font size for infobox text). Goszei, how does an 88% font size violate MOS:SMALLFONT? – Jonesey95 (talk) 02:05, 1 October 2025 (UTC)[reply]
Sorry, my math was wrong here. It is indeed 88% of the base font size, and therefore not violating MOS:SMALL. However, the change does put the size of the native_name field out of step with similar, widely-used infoboxes (Template:Infobox officeholder, Template:Infobox musical artist, Template:Infobox scientist, etc.). For the sake of consistency (as well as a guideline/discussion, which I vaguely recall but can't find right now, that strongly discourages Chinese characters and other intricate scripts from appearing below the base font size for readability reasons), is there a remedy for this? — Goszei (talk) 02:24, 1 October 2025 (UTC)[reply]
Thank you! However, maintaining the larger font size now appears to rely on having a language in the "native_name_lang" field. Is there a way to maintain it when that field is blank? — Goszei (talk) 15:07, 1 October 2025 (UTC)[reply]
Under what valid circumstances would that field be blank? Hiroyasu Koga inserts a template, which does its own thing, but a plain-text non-English name should have a language to go with it, I would think. – Jonesey95 (talk) 21:40, 1 October 2025 (UTC)[reply]
Not any valid circumstance, just wanted to account for the case if possible, since I do see it sometimes. I suppose having the text be smaller when the lang field is blank could encourage remediation. If there's no simple fix, the edit is ready to go live in my opinion. Thank you for your work here. — Goszei (talk) 22:26, 1 October 2025 (UTC)[reply]
Thanks. I will implement the fix, since it improves things in general. If someone else comes up with an even better fix (like adding |subheader2style= to {{Infobox}}), we can implement that when it arrives. – Jonesey95 (talk) 01:09, 2 October 2025 (UTC)[reply]
It turns out that |subheaderstyle2= is a valid but undocumented parameter. I saw it working in another infobox, so I tweaked the template today to use it here. That avoids the problem of having it in the if statement and sometimes not being applied. – Jonesey95 (talk) 15:20, 3 October 2025 (UTC)[reply]
Should we consider having a row of icons/badges at the bottom of the box for social media links etc. as most living public figures now have one or more of these?
These would only include the most prominent social media sites:
Facebook, Instagram, Threads [Meta]
X/Twitter [Elon Musk]
LinkedIn, GitHub [Microsoft]
YouTube [Google]
Snapchat [Snap Inc.]
Reddit [Reddit Inc.]
TikTok [ByteDance]
Bluesky [???]
Mastodon [???]
and of course, personal website, which should be first. I would not, however, include handles for 1:1 communicator apps like WhatsApp or Signal, which are not meant to be public-facing, nor media sites like OnlyFans, which seem inappropriate for general use on Wikipedia.
These can all easily be brought in from Wikidata, and the use of their copyrighted/trademarked site icons would be justified by their use to refer to those sites, a clear case of fair use. We could also use letter-in-a-circle icons to denote sites, if there were to be licensing issues.
Per WP:ELMIN, "Wikipedia does not attempt to ... provide readers with a handy list of all social networking sites". Before discussing how such a thing could be implemented, that guideline saying we shouldn't do it at all would need to be changed. Nikkimaria (talk) 14:21, 27 September 2025 (UTC)[reply]
Should color headings be removed from all person infoboxes
This WP:RFC is specifically about those Infoboxes found in Category:People and person infobox templates. It is my opinion that the color headings have gotten out hand. It seems that every new Infobox has found the need to have their own custom hex color. One pair of example that comes to mind are {{Infobox skier}} and {{Infobox alpine ski racer}}. While I understand and appreciate that they are for different sports, they are both about skiing and yet have different colors.
This issue is compounded when you get pages where multiple Infoboxes are embedded (for example someone who participated in multiple sports or who also served in the military). Now it is true that many of these template include a check for if the template is embeded. If it is, the header color is removed, but not all do. Either way you get a bad user experience. On the one case the parent and child infoboxes have different color headers, while on the other case the parent’s headers have color and the child’s have none.
Some infoboxes actually have multiple different colors in the same infobox, see for example {{Infobox rugby biography}}. What’s more, {{Infobox sportsperson}} actually has |headercolor= so you can set any color for a page further allowing for widely varying color schemes that can violate MOS:COLOR.
A quick search reveals there are at least 80 pages in the category (and subcategories) that have some form of color setting. I don’t have an exact count on how many of those colors are unique, but many are.
Proposal
It is my proposal that one of the following options be implemented as standard practice.
Color for headers, subheaders and above removed entirely from the infoboxes.
Standardize color but keep an exception for certain templates that set the color based on certain parameters. An example here would be {{infobox baseball biography}} which makes use of Module:Sports color to colorize the infobox based on the persons current team.
I like that infobox person has no colour and I therefore use it for all people, as for example project opera recommends for singers. I hope it will stay neutral like that. If all others do the same, fine with me. --Gerda Arendt (talk) 12:47, 2 October 2025 (UTC)[reply]
I agree with the proposer and suggest that a reasonable effort should be made (e.g. through RFC) to agree common colouring and if that fails then no colour is used. Emmentalist (talk) 16:44, 2 October 2025 (UTC)[reply]
What does this mean, exactly? Using a standard header color unless the non-standard parameter name |header-color= (instead of |header_color=) is used? BTW, that parameter is used in 0.1% of transclusions. – Jonesey95 (talk) 19:54, 2 October 2025 (UTC)[reply]
I wonder if GiantSnowman is even aware that standard we should aim for includes the very issue I pointed out. Namely that {{Infobox football biography}} ALSO allows for EVERY transclusion to set a custom color. I would agree that the default header color of used in that template could be a good standard to move towards if option 2 of the proposal is implemented. Zackmann (Talk to me/What I been doing) 19:59, 2 October 2025 (UTC)[reply]
While I do see the proposer's point in objecting to a too wide divergence in header color schemes, I find the proposals posed dabble in WP:IDONTLIKEIT. True, pro color usage arguments might falter opposingly in WP:ILIKEIT, but there is, in my opinion, a benefit in the usage of colors.
I do completely agree with the proposer that {{Infobox sportsperson}}'s untamed |headercolor= may lead to guideline violations and cause articles, even in the same category, to be visually inconsistent. That is why, for example, when creating {{Infobox judoka}} as a wrapper for Infobox sportsperson I've limited the range of color schemes to only 2 'extra' options to the default, hard-coded into the template and with meaning to the topic.
My point: both proposals are overreaching. Even IF color usage should be limited, there are other ways to do so. Perhaps every subject should have its own color, helping set the page, acting as a sort of "Syntactic sugar" that lets the reader know they're in the right place. Maybe a discussion should be had on where to draw the line separating topics, as the proposer exampled with Infobox skier & Infobox alpine ski racer. Or maybe, all that should be done is keeping articles consistent within each topic.
I oppose both options proposed. I do think that consistency should be brought to infobox coloring, at least within topics, but find the sentiment edging towards throwing the baby out with the bathwater. CLalgo (talk) 19:31, 2 October 2025 (UTC)[reply]
Oppose - this reeks of overreach. As a colour-blind person, the way this is trending is monotone white pages. Heck, I half expect demands for just black and white photographs. Llammakey (talk) 19:50, 2 October 2025 (UTC)[reply]
@Llammakey: You misunderstand my goal. It is actually the opposite. I am trying to avoid colors that violate MOS:COLOR and are therefore unreadable/difficult to read for people with color blindness. I do not have color blindness so I can’t speak to the exact issues you must face, but the nature of some of these templates ({{Infobox sportsperson}} for example) is that you can set any color you want when you use the template, including color combinations that would be unreadable to someone like yourself. I DO NOT support just black and white photographs or anything of that nature, I want to make sure that the experience of ALL persons on Wikipedia is the best possible. —Zackmann (Talk to me/What I been doing) 19:56, 2 October 2025 (UTC)[reply]
Support. The colour situation is a bit of a mess and lowers the quality of Wikipedia, who has always had a simple but high-quality feel to its look / fonts etc., (i.e. not a school art project vibe). I would however like one simple standardised colour - Option 2. with pale blue - so that navigating the sections of the infoboes is clear. Aszx5000 (talk) 20:00, 2 October 2025 (UTC)[reply]
Oppose. So what if there are lots of colors? The justifications given are barely even notable given the radical changes proposed. Keep it colorful, it's not hurting anyone. 〜 Festucalex • talk22:51, 2 October 2025 (UTC)[reply]
Oppose per Nikkimaria. If there is a specific color scheme in an ib that goes against MOS:COLOR, then please address on the talk page associated with that particular ib. "Conformity is the jailer of freedom and the enemy of growth".—Isaidnoway(talk)17:44, 4 October 2025 (UTC)[reply]
Oppose. Although it is true that "varying color schemes [...] can violate MOS:COLOR", that is not even close to a valid argument for banning all color schemes. If you have MOS concerns about any particular uses of color, please be WP:BOLD and let people know about the MOS:COLOR violations you are seeing. VanIsaac, GHTVcontrabout18:53, 4 October 2025 (UTC)[reply]
_-_The_Noun_Project.svg){kind=small}
