Template talk:Infobox person

For pending merger proposals (2009 to date) see Template talk:Infobox person/Mergers

Discussion at Wikipedia:Village pump (miscellaneous) § RFC: Alma mater vs Education in Infoboxes

 You are invited to join the discussion at Wikipedia:Village pump (miscellaneous) § RFC: Alma mater vs Education in Infoboxes. —Myceteae‍🌈 (talk) 19:47, 13 June 2026 (UTC) —Myceteae‍🌈 (talk) 19:47, 13 June 2026 (UTC)

So now we have >23,000 articles in Category:Pages using infobox person with deprecated parameters; to be precise, 11026. How are we going to deal with that? -- Michael Bednarek (talk) 04:05, 18 July 2026 (UTC)

Oh there are going to be WAY more than that... Caching has to catch up. Once the category is fully populated we will get a bot run going. That being said, Category:Pages using infobox musical artist with associated acts (16,493) has been around since 2022. There is no deadline here. These things take time but rest assured there are multiple people watching this. Zackmann (^{Talk to me}/_{What I been doing}) 04:08, 18 July 2026 (UTC)

I'll make a pass through once it's populated to deal with (hopefully) the majority. I will note on Zack's point that deprecated≠removed, so until the param names get swapped over and the param is removed from the template, they'll still be visible on the page. Primefac (talk) 09:57, 18 July 2026 (UTC)

Prime is 100% correct. No information has been removed from articles. Alma mater has been removed from documentation to help prevent future additions of it, but any page currently using |alma_mater= does still display that info!

@Primefac: just a note to keep in mind for the eventual bot run. There are absolutely pages that already have BOTH |alma_mater= and |education= on them, so simply replacing |alma_mater= with |education= will not work... Zackmann (^{Talk to me}/_{What I been doing}) 15:52, 18 July 2026 (UTC)

There are at least a few articles where an attempt was made to separate secondary education (e.g., Eton College) from tertiary ot higher education (e.g., University of Oxford) using both parameters in consort—an idea that seemed appropriate for certain articles. -- Cl3phact0 (talk) 17:46, 18 July 2026 (UTC)

@Zackmann08: Is it possible to create a tracking category for pages that use both |alma_mater= and |education=? Khiikiat (talk) 09:24, 21 July 2026 (UTC)

@Khiikiat: best way to do that is to put them as conflicting parameters. Do you want this for ALL Infoboxes using both? Happy to do this... Zackmann (^{Talk to me}/_{What I been doing}) 23:52, 21 July 2026 (UTC)

@Zackmann08: Yes, I think we should do this for all infoboxes. Khiikiat (talk) 12:38, 22 July 2026 (UTC)

There are also all of the versions that pull alma_mater= parameter from Wikidata. Will you address these as well? -- Cl3phact0 (talk) 12:46, 22 July 2026 (UTC)

Probably not. Primefac (talk) 22:37, 23 July 2026 (UTC)

{{Infobox person/Wikidata}} and all of the similar infoboxs insert the educated at (P69) property into a nominal parameter that displays as "Alma mater". There are thousands of these. If we want to be consistent in the decision to eliminate (poor, dear) Alama, they too should be scrubbed. (I'd offer to do it, but I don't think my coding skills are up to the task.) -- Cl3phact0 (talk) 05:12, 24 July 2026 (UTC)

I have adjusted {{Infobox person/Wikidata}} – Jonesey95 (talk) 22:21, 25 July 2026 (UTC)

Thanks Jonesey95, that seems to work. It's a detail, but in some cases where there are several listed, it can be a bit of a jumble. Are you able to format them as a {{plist}} (or similar) rather than separated by commas? (Don't mean to seem greedy, but it's not every day one has the attention of somebody who knows how to do these things!) Cheers, Cl3phact0 (talk) 03:45, 26 July 2026 (UTC)

Further to the above, also note that we are using academic degree (P512) for "Education". There seems to be some misalignment in our use of both "Alma mater" and "Education" here. -- Cl3phact0 (talk) 14:53, 24 July 2026 (UTC)

Missed this one (though as the consensus seems neigh unto unanimous to jettison poor, dear, sturdy and time-worn Alma, my staunch and lonely opposition wouldn't have made a fig leaf of a difference). Alas, poor Alma! -- Cl3phact0 (talk) 10:45, 18 July 2026 (UTC)

@Primefac: Is it possible for a bot to remove |alma_mater= and |education= where they are blank? This would reduce the number of pages in Category:Pages using infobox person with conflicting parameters. Khiikiat (talk) 08:10, 26 July 2026 (UTC)

Wouldn't removing just |alma_mater= accomplish the same thing? -- Cl3phact0 (talk) 08:59, 26 July 2026 (UTC)

It would, but if you had (for example) a populated alma_mater and a blank education, skipping the removal of the blank would cause a duplicate param issue when alma_mater got converted. Might as well remove any and all blanks when it comes to duplicates. Primefac (talk) 09:49, 26 July 2026 (UTC)

@Cl3phact0: It wouldn't accomplish the same thing. I wanted to identify the pages in which both parameters are populated (not just used), because these pages will have to be fixed manually (unless someone can think of another solution). Khiikiat (talk) 10:16, 27 July 2026 (UTC)

Yes, there are a lot of things to consider with the coding/setup so I'm taking my time in prepping for it. Primefac (talk) 09:49, 26 July 2026 (UTC)

Infobox academic

I think that the RFC neglected to consider the case of {{infobox academic}}, where both |alma_mater= (which higher education institutions they attended) and |education= (which degrees they earned) may both be useful to summarize in the infobox. – Jonesey95 (talk) 22:26, 25 July 2026 (UTC)

I have never seen both parameters separated out with universities in one parameter and degrees in the other like that. I think the redundancy of the two parameters is no different in infobox academic/infobox scientist than in the other infoboxes for people. —David Eppstein (talk) 23:13, 25 July 2026 (UTC)

I concur with David that this is really un-necessary for all the reasons discussed at the RFC. If the goal is to distinguish between degrees earned and institutions attended then I think different parameter names should be used. We are trying to stay consistent here and if we make an exception for one Infobox that is bound to lead to confusion. I still think the best approach is to simply have |education= where you can list (for example) {{ubl|NYU, BA Physics|Harvard, PhD Dark Magic}}. I don't see the benefit of separating that out into two parameters, one listing the institutions and the other the degrees. Just seems unnecessarily complicated. Zackmann (^{Talk to me}/_{What I been doing}) 23:35, 25 July 2026 (UTC)

OK, after more thought and looking at a random sample of articles that use this template, I think that the above posters are correct. I recommend a tracking category for articles that use both parameters so that editors can do manual merges before any AWB or bot work is performed. – Jonesey95 (talk) 00:12, 26 July 2026 (UTC)

I think the plan is to use the conflicting parameters check for that. Confirming we can revert your change here?

Also, did I just convince someone of something on the internet?!?! Zackmann (^{Talk to me}/_{What I been doing}) 02:29, 26 July 2026 (UTC)

Poor Alma, 2026

I still believe that this is one of the only places left where one might actually "convince someone of something on the internet" without (too much) acrimony, shouting, or undesirable repercussions (or worse). Perhaps I'm naïve (although please note that in spite of the fact that my personal preference would have been to keep poor old Alma breathing a bit longer—as the tides have turned against this point of view, with due respect for consensus, I'm also perfectly willing to lend a hand burying her). Cheers, Cl3phact0 (talk) 04:30, 26 July 2026 (UTC)

Typo in source

Can a template editor please fix: {{tq|preview warning:|Page using Template:Infobox person with deprecated parameter alma_mater which should be merged with/replaced by education

there's a missing "D". Thanks! Electricmemory (talk) In solidarity 03:23, 24 July 2026 (UTC)

Facepalm @Electricmemory: you missed a perfectly good opportunity to TROUT me for that one. . Fixed Zackmann (^{Talk to me}/_{What I been doing}) 03:27, 24 July 2026 (UTC)

We need a journalist infobox

Request to create Template:Infobox journalist. Guylaen (talk) 12:58, 24 July 2026 (UTC)

It would help if you explained why you feel we need one. DonIago (talk) 13:01, 24 July 2026 (UTC)

Actually, I think it would be fine simply adding the following parameters to another infobox;

• Publication(s)
• Station(s)
• Primary Medium or Media
• Editorial position
• Typesetting position
• Supervising Editor, Managing Editor, or Director (their boss)
• Appointed by
• Term_start
• Term_end
• Beats or subjects
• Name of Column
• Miltary unit deployed with
• Battles or wars covered
• Captured by
• Years in captivity

Guylaen (talk) 13:20, 24 July 2026 (UTC)

None of this is stuff that needs to go in an Infobox per MOS:INFOBOXPURPOSE. Just use {{Infobox person}} (which {{Infobox journalist}} already redirects to) and put the rest in the body of the article. Zackmann (^{Talk to me}/_{What I been doing}) 14:10, 24 July 2026 (UTC)

Why is it allowed for a soldier to have their wars, but not an embedded journalist who was literally standing next to that soldier? Why are soldiers allowed to have their units, but journalists not allowed their papers? This makes no sense at all. Guylaen (talk) 16:39, 24 July 2026 (UTC)

Going to war is one of the accepted risks that recruits are aware of when they join up. Not all journalists are sent to war zones - many spend their whole careers covering more everyday matters like elections, medical advances, railway delays, road traffic accidents, sports events and cat shows. --Redrose64 🌹 (talk) 09:06, 25 July 2026 (UTC)

I at least want to know what paper a journalist worked for before I start reading the article. I don't want to have to scan the article or the introduction, it should be in the infobox. Guylaen (talk) 10:09, 25 July 2026 (UTC)

Then you have |employer= already... Just set |employer=New York Times or |employer=CNN. You already have ways to do this without needing to create an entirely new Infobox for 1 parameter. Zackmann (^{Talk to me}/_{What I been doing}) 15:43, 25 July 2026 (UTC)

Background color for title of Infobox

Hi, please change this code

| above      = {{#if:{{{honorific_prefix|}}}|<div class="honorific-prefix" style="font-size: 80%; font-weight: normal;">{{{honorific_prefix|}}}</div>}}<div class="fn">{{if empty|{{{name|}}}|{{PAGENAMEBASE}}}}</div>{{#if:{{{honorific_suffix|}}}|<div class="honorific-suffix" style="font-size: 80%; font-weight: normal;">{{{honorific_suffix|}}}</div>}}

to

| above      = {{#if:{{{honorific_prefix|}}}|<div class="honorific-prefix" style=" font-size: 80%; font-weight: normal;">{{{honorific_prefix|}}}</div>}}<div class="fn" >{{if empty|{{{name|}}}|{{PAGENAMEBASE}}}}</div>{{#if:{{{honorific_suffix|}}}|<div class="honorific-suffix" style="font-size: 80%; font-weight: normal;">{{{honorific_suffix|}}}</div>}}
| abovestyle = padding-bottom:0.2em;{{{titlestyle|}}}; background-color: #e0e0e0; color:Black;

To discreminate title of Infobox from rest of it. Sandboxed here successfully. Thanks, Rais-Ali Delvari (talk) 10:25, 2 August 2026 (UTC)

Please put your test code in the /sandbox page to show how it works on the /testcases page. Specifying background-color without a text color causes a Linter error. – Jonesey95 (talk) 14:48, 2 August 2026 (UTC)

@Jonesey95 Hi, I applied that with "abovestyle" in /sandbox, and also set text color to avoid linter error. Please check /testcases page. Thanks, Rais-Ali Delvari (talk) 15:25, 2 August 2026 (UTC)

Thanks. Now you need to get consensus for this significant change that would be applied to over half a million pages. – Jonesey95 (talk) 16:59, 2 August 2026 (UTC)

Please vote

Hi, in my opinion this simple style

 abovestyle = padding-bottom:0.2em;{{{titlestyle|}}}; background-color: #e0e0e0; color:Black;

Significantly improves the readability of infobox. Please vote, which one of these Infoboxes is better? See Template:Infobox person/testcases#Demonstration 1, 3 August 2026

• I vote for the second. Rais-Ali Delvari (talk) 03:23, 3 August 2026 (UTC)

  Why is this demonstration here, and not at Template:Infobox person/testcases? --Redrose64 🌹 (talk) 17:00, 3 August 2026 (UTC)

  I moved the testcases to the proper place, Template:Infobox person/testcases#Background color for title of Infobox. --Redrose64 🌹 (talk) 12:37, 4 August 2026 (UTC)

  Bill Gates was already on the list of test cases; not sure the new one is any different than the one that was there before? -- Beland (talk) 07:43, 5 August 2026 (UTC)

• I prefer the first one, because of the greater contrast between text and background and because the extra shaded rectangle does not impart any meaningful information. —David Eppstein (talk) 18:13, 3 August 2026 (UTC)

  @David Eppstein Hi, no

  extra shaded rectangle does not impart any meaningful information.

  It specifies that "this part" is "title of infobox", and discriminating title from rest is very important. Using "shade style" beside "bold" is really helpful for this purpose. Please see Template:Infobox person/testcases also for other usages. Thanks, Rais-Ali Delvari (talk) 02:45, 4 August 2026 (UTC)

  discriminating title from rest is very important. Why, and why is bold insufficient? Nikkimaria (talk) 03:13, 4 August 2026 (UTC)

  @Nikkimaria Hi,

  "Why" because we are humans and human brains use "abstraction" for inferring. Therefore having a separated title that expands to details is important. See Phrase structure grammar and Psycholinguistics.

  why is bold insufficient?

  See, "shade" complements "bold".

  • You may see a "bold text" and need some time to infer it is title.
  • After seeing a "bold shaded text" you immediately infer that this part is title without spending time.

  This reduction of time in inferring is the reason that shade is crucial. Rais-Ali Delvari (talk) 03:40, 4 August 2026 (UTC)

• Definitely the first one. The second adds gratuitious shading that doesn't serve any purpose. Schazjmd (talk) 18:27, 3 August 2026 (UTC)

  @Schazjmd: No, it serves as discriminator of "title" from rest. See this infobox also Template:Infobox person/testcases#Demonstration 2, 4 August 2026. In this case this separation of title from rest is more prominent. Rais-Ali Delvari (talk) 02:49, 4 August 2026 (UTC)

• Fix bugs - There is a defect in the status quo which this change highlights. The left and right edges of the main image need to be expanded so they line up with the edges of the new shadow box and the main text of the infobox. The new shadow box also does not show up in dark mode. Template:Infobox person/testcases#Abdalla Hamdok shows a case where a non-English original written form is present (via the native_name parameter); it shows up outside the shadow box, which looks weird. For infoboxes with an image, I don't think this shadow box is needed, as there's no adjoining text for it to be distinguished from. When there is no image, however, there is adjoining text, and I think the shadow box makes things looks a bit nicer. (See Template:Infobox person/testcases#Child Ofparents and later, in light mode.) Not a big difference, though, as the name is already distinguished by alignment, size, and bolding. -- Beland (talk) 22:05, 3 August 2026 (UTC)

  @Beland Hi, we should make title as discriminating as we can. Alignment, size, and bold are discriminating but "shade" makes title more discriminating and by making it more discriminating, the readability of such infoboxes is promoted.

  I am ready for fixing the bugs you mentioned after consensus. These bugs are not serious ones and can be resolved with ease. Rais-Ali Delvari (talk) 03:05, 4 August 2026 (UTC)

  Opinion seems to be running strongly in favor of not having the shadow box, which to me is an acceptable outcome. So I think it would be safe to fix the image alignment bug and call it a day. I would not support adopting the second version without actually seeing the bug fixes to the shadow box demonstrated, given the huge number of articles that would be affected by a botched fix, and the very large amount of cache invalidation that I assume would induce a noticeable performance hit. -- Beland (talk) 07:47, 5 August 2026 (UTC)

  @Beland My goal is to make infobox «more» readable (note that this infobox is readable significantly, but we attempt to «improve» it). This means reading with fewer mental attempt, one factor is in time:

  Which infobox for Bill Gates is read faster?

  The answer to this question needs a highly expensive psychological test both in time and money, but I reasonably guess that the second infobox of Bill Gates is read faster, because we break this infobox into "title" and "body". Rais-Ali Delvari (talk) 09:13, 5 August 2026 (UTC)

  That is not a question that I - or as far as I can tell, anyone else in this thread - has asked, and I don't agree with the conclusion for that particular instance.

  I was suggesting that the bugfixes you are contemplating should be implemented before we endorse publishing them, and there is no need to await further input as the preferred version is clear. -- Beland (talk) 08:09, 6 August 2026 (UTC)

• I support the first one - to the extent that discrimination is necessary, the existing formatting provides it, and the proposed change introduces its own issues. Nikkimaria (talk) 03:42, 4 August 2026 (UTC)

  @Nikkimaria As my final argument, many existing infoboxes use "shade" for title, which in my opinion is true:

  1. Template:Infobox album
  2. Template:Infobox dam
  3. Template:Infobox school
  4. Template:Infobox song
  5. Template:Infobox musical artist
  6. Template:Infobox airport

  If you search between other infoboxes in Wikipedia, definitely you encounter other usages of shade for making title more discriminate. In my opinion this convention is true and might be applied here. Any bugs can be resolved conveniently. Rais-Ali Delvari (talk) 04:49, 4 August 2026 (UTC)

  This feels like an "other stuff exists" argument to me. I agree with most of the other opinions that the shading adds no real benefit and possibly comes with costs, and that other infoboxes are using it may be more of an argument for reevaluating their use of shading. DonIago (talk) 13:43, 5 August 2026 (UTC)

  Those other templates use a non-greyscale color, which does a better job drawing the eye to the title (if that is a goal) and also have multiple bars of the same color, which break up the infobox nicely. The proposed change does neither of those things, which I think makes it look not as nice. -- Beland (talk) 08:10, 6 August 2026 (UTC)

• This a slippery slope which will lead to exhaustive "color of shade" arguments (neutral term).--☾Loriendrew☽ ☏(ring-ring) 13:59, 5 August 2026 (UTC)

  Clearly it should be determined by their skin color favorite flavor of ice cream. DonIago (talk) 16:27, 5 August 2026 (UTC)

Children

Question: Do we have any guidance on the question of enumerating all children, or only children surviving infancy?

Currently we state "Typically the number of children (e.g., 3); only list names of independently notable or particularly relevant children. Names may be preceded by a number to show total children and avoid implying that named children are the only offspring."

While I can find several previous talk discussions leading up to this distinction (avoiding giving the impression notable children are the sum of all offspring sounds great) I could not find anything on what I suspect is a convention used by primarily historical articles. Or is it?

For example, an article of a person living in, say, the year 1700. If we specify |children=9 does that imply this person had either

a) nine children and no more than nine children?

or

b) maybe fourteen children, five of which died in infancy?

Genealogical records will often show the number of children to be larger than Wikipedia's reported |children= number. I don't have a particularly strong opinion either way, but I do want to know what the official guidance on using this parameter is? In this hypothetical, is |children=9 correct and |children=14 to be avoided, perhaps to avoid becoming reliant on first-party sources? Or is |children=9 simply wrong, and, assuming records establish, in this example, the true number to be 14, that editors should feel free to update to |children=14? Even if the consensus is "either is just fine" it would be beneficial to state this explicitly.

As stated previously I could not find any previous discussion, but I only searched archives here, so if this has been discussed elsewhere feel free to simply point me in a fruitful direction. Best Regards, CapnZapp (talk) 13:01, 12 August 2026 (UTC)

A famous, well-known example is J. S. Bach who had 20 children (his organ didn't have stops 🦆🙇‍♂️). The article ought to mention that number, not only the ones that survived infancy. Same for Mozart and his six children (only 2 survied). -- Michael Bednarek (talk) 13:44, 12 August 2026 (UTC)

@CapnZapp: A possible solution would be an {{efn}}? Something like {{efn|10 total, only 5 survived past 12 months}}. I don't think there is a clear guidance on this so I would air on the side of clarity for the casual reader. Zackmann (^{Talk to me}/_{What I been doing}) 03:26, 13 August 2026 (UTC)

• I would say that you just need to follow the sources for number of children, no matter their ages or notability. If sources include a child that died at a young age, or even a stillbirth, as long as they include them as a child, it counts. Children named in the infobox, on the other hand, are fundamentally a function of notability, with the caveat that referred notability (e.g. Eric Clapton's son Conor) is going to be more compelling for naming family in an infobox than for independent articles under WP:GNG. VanIsaac, GHTV ^contr_about 03:57, 13 August 2026 (UTC)

Just as a heads-up, Michael Bednarek: neither article you mention feature the |children= parameter in their respective infobox? — Preceding unsigned comment added by CapnZapp (talk • contribs) 10:43, 13 August 2026 (UTC)

With good reason. There are miles of discussion about infoboxes for composers, and it was concluded that the number of their offspring is immaterial. -- Michael Bednarek (talk) 11:10, 13 August 2026 (UTC)

Are you on the same track here, Michael? I am asking questions about how to use |children=. How is it relevant that there exists cases where this parameter is deemed unnecessary? Could I ask you to come up with examples that do feature the parameter? CapnZapp (talk) 11:56, 13 August 2026 (UTC)

My mistake. I replied after reading the 1st sentence above, not realizing on which exact talk page it appeared. -- Michael Bednarek (talk) 13:01, 13 August 2026 (UTC)

Perhaps I should clarify - I am primarily discussing old historical data, where some biographer state there was 9 children, but where genealogical records show the couple really had 14 children (in our example), five of which died in infancy. So it is clear that the first source made the choice to only include the 9 children that lived a somewhat long life. I suspect this is very common, especially for older sources. Should an editor correct |children=9? Or is perhaps an editor in the right if they revert such a detail correction? Perhaps based on the "use primary/secondary sources" discussion? Either way, my aim here is to break the current silence on this issue from the children entry of the Parameters section. I don't have a strong opinion on what we should choose to say, only that we ought to say something, even if that something is "both approaches are acceptable" or "up to editor discretion". Hope this helps! CapnZapp (talk) 10:52, 13 August 2026 (UTC)

Reliable sources always win on Wikipedia; no further guidance is needed. -- Michael Bednarek (talk) 11:10, 13 August 2026 (UTC)

I disagree. Otherwise I wouldn't have started this thread? We already point out that this parameter can be useful to avoid implying someone's total offspring consists of only named/notable children. You could apply the same incredibly generic argument to why that, and lots of other useful advice, is not "needed". So perhaps... don't do that? I'm asking, what guidance can we add to avoid people disagreeing about specific numbers when sources differ? Should we lean towards a complete count, or counting only "able" offspring, or leave it up to individual discretion? Silence seems the inferior choice when a very short number of words could actually help editors keep on track. Regards, CapnZapp (talk) 12:03, 13 August 2026 (UTC)

I'm certain that in a battle RS vs. OR, RS will win. -- Michael Bednarek (talk) 13:01, 13 August 2026 (UTC)

I believe I am in full agreement. Furthermore, that I have never questioned this. In fact I am not talking about RS vs. OR. I am discussing the |children= parameter, and what guidance to add regarding any discrepancies caused by chroniclers choosing to omit children that lived short lives. CapnZapp (talk) 17:58, 14 August 2026 (UTC)

Okay so here is what I ended up with given the limited feedback:

−

Typically the number of children (e.g., 3); only list names of independently notable or particularly relevant children. Names may be preceded by a number to show total children and avoid implying that named children are the only offspring. For multiple entries, use an [[#Inline lists|inline list]]. <em >For [[Wikipedia:Biographies of living persons#Privacy of names|privacy reasons]], consider omitting the names of living children, unless notable.</em>

+

This entry can contain a number or individual names or both. Typically only list the number of children (e.g., 3); only list names of independently notable or particularly relevant children. Some sources give the total number of children including children that died in infancy; other sources give as the number of children the amount that survived to a certain age. Using either is fine. Including both names and number of children can be used to avoid implying that named children are the only offspring. For multiple entries, use an [[#Inline lists|inline list]]. <em >For [[Wikipedia:Biographies of living persons#Privacy of names|privacy reasons]], '''do not include''' the names of living children, unless notable.</em>

Let's discuss each change:

1. This entry can contain a number or individual names or both. Let's start by explaining what you can enter in this parameter.
2. Some sources give... other sources give... Using either is fine. We explain how some sources can give a number that doesn't match the genealogical records without that being an error or something other editors should necessarily correct.
3. stronger emphasis on not naming children of BIO articles

Remember, the main question here is Do we have any guidance on the question of enumerating all children, or only children surviving infancy? If your consensus isn't to leave this up to individual judgement, say so.

I'm going to edit the Template parameters section now. For some reason every bit of info here is duplicated?

Regards, CapnZapp (talk) 11:00, 15 August 2026 (UTC)

CapnZapp (talk) 11:00, 15 August 2026 (UTC)

A child born is a child, it should not matter how long they live. ☾Loriendrew☽ ☏(ring-ring) 12:56, 15 August 2026 (UTC)

Tell that to biographers born hundred of years ago? I'm just happy if we acknowledge the practice. CapnZapp (talk) 14:26, 15 August 2026 (UTC)

Proposal: Re-introducing 'ethnicity' to Template:Infobox person with strict data-parity controls

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Rationale

A decade ago, the site-wide consensus to remove biographical parameters like religion and ethnicity from Template:Infobox person successfully mitigated high-frequency vandalism and localized edit warring. However, ten years of downstream data tracking show that this complete removal resulted in an unintended consequence: a critical loss of public-facing structured data. For researchers, historians, and genealogists, the complete absence of a standardized heritage field reduces the utility of Wikipedia’s quick-reference layout, forcing users to comb through long-form prose for basic demographic metadata.

While the 2016 resolution addressed an administrative burden, its execution bypassed an alternative, more constructive solution: creating a strictly regulated, policy-backed parameter rather than an outright deletion. We should correct this data gap. This proposal outlines a compromise to reintroduce the ethnicity parameter under strict, non-negotiable editorial guardrails designed specifically to prevent the legacy issues of the pre-2016 era.

Proposed Technical and Policy Guardrails

To prevent a resurgence of identity-tagging or edit warring, the ethnicity parameter will only be permitted if it meets three distinct criteria:

Strict Self-Identification or Definitive Genealogic Record: The subject must explicitly self-identify with the ethnic group in reliable sources, or have a direct, universally accepted ancestral record (e.g., parental lineages documented in peer-reviewed biographies).Direct Relevance to Notability: The ethnicity must be directly tied to why the individual is notable (e.g., a cultural figure, a civil rights leader, an indigenous advocate, or a historian whose work directly stems from that heritage). It may not be used as a routine cataloging tool for individuals whose careers have no structural relationship to their ethnic background.Wikidata Integration: The field should ideally be pulled directly from, or mapped to, Wikidata property P172 (ethnic group), ensuring that changes must pass through structured tracking rather than raw, unmonitored wikitext inputs.

Discussion

Support as proposer. The 2016 deletion was an overcorrection. We can preserve both data utility and article stability simultaneously by implementing rigid formatting rules instead of hiding verifiable historical heritage.

{ ~2026-45120-41 (talk) 04:38, 17 August 2026 (UTC)

• Oppose. I think this proposal is misguided, for much the same reason that we needed to remove these parameters previously. It's not "high-frequency vandalism and localized edit warring" that are the main problem. There is a much bigger problem with good faith editors who think they know the ethnicity because of the surname and think that the presence of a parameter in an infobox means that that parameter should be filled whenever it can be guessed. Your supposed "technical and policy guardrails" are merely a repetition of existing policies and guidelines and will do nothing to prevent these sorts of bad edits. —David Eppstein (talk) 05:41, 17 August 2026 (UTC)

  I get the concern about people guessing ethnicity based on last names Mr@David Eppstein.

  But that's exactly why this proposal is different. By pulling the data qtrinctly from Wikidata, casual editors can't just type a guess into infobox anymore.

  The 2016 ban fixed some childish editing headache, but it erased really important history. For many historical figures and minority groups, heritage isn't trivia and is crucial for understanding who they were and their impact. We shouldn't hide vital history forever just because managing it is tough like we could use better tech controls to keep the data clean instead of deleting it.

  NEVER ONCE DELETING HISTORY WAS FOR A GOOD CAUSE. ~2026-45126-33 (talk) 06:52, 17 August 2026 (UTC)

  Oh. Pulling information from Wikidata. Which does not have the same standards for BLP sourcing and ethnicity categorization as we do here on en, which does not have any way of encoding the information that the ethnicity it codes is or is not central to the notability of the subject, which also does not distinguish whether the claim of ethnicity is supported by a direct statement from the subject, and which is actively hostile to removal of bad data as long as that data comes from some other database that it pulls from. Nonstarter. —David Eppstein (talk) 06:59, 17 August 2026 (UTC)

  You are overcomplicating a simple issue with academic jargon. No one is asking to import unverified data blindly. The goal is simply to find a secure way to reintegrate verifiable historical facts so we don't erase vital heritage. Surely we can use better tech controls to enforce BLP standards instead of just giving up and deleting history. ~2026-45132-33 (talk) 07:07, 17 August 2026 (UTC)

  I struggle to see how David introduced more jargon than your original post. I'll try to keep it more accessible. The main issue is that Wikidata has less control than Wikipedia. Anyone can still edit it, but it doesn't have the same rules about sources, or about when to keep the data. And Wikidata doesn't have a way to say whether data is important or not.

  Also, if it changes on Wikidata, the change doesn't show up in the Wikipedia history. So it is easier to miss the change. Chaotic Enby (in solidarity · talk · contribs) 17:07, 17 August 2026 (UTC)

• Oppose Not only is it a exceedingly good idea for Wikipedia to not touch issues of race with a ten-feet pole (quick reminder: outside of the US nobody thinks it is a good idea to classify people based on a nebulous and vague and unscientific and abusable characteristic such as "ethnicity", as it can only reinforce racism by moving away people's minds from the irrefutable fact we're all the same species!), but I especially oppose the notion "let's bury it in Wikidata regular editors don't understand how to change". Wikidata is generally an overengineered solution made by editors that fail to appreciate the value of keeping the project editable by regular people. We should fight the idea to move ever-more data out of regular text in articles, not embrace it! CapnZapp (talk) 08:40, 17 August 2026 (UTC)

  I really do not mean to be rude but your reply screams AI and LLM typical pattern as an LLM Engineer i don't see value from just prompting it with "oppose strongly and give convincing arguments" type of prompt and then it responds with 'we're all the same species!' And i especially don't like the idea and then proceeds to remention random parts with non-convcing arguments.

  Just in case i am mistaken i apologize upfront and say that the second argument is invalid considering the sensitivity of the topic. And my whole point is that deleting history is not logical and doesn't align with the purpose of Wikipedia. ~2026-44851-68 (talk) 09:20, 17 August 2026 (UTC)

  There's nothing in CapnZapp's response suggesting that it was written by an LLM at all, no idea where you get that idea from. It reads like a 100% pure human text. Please only accuse people of LLMuse when it is blindingly obvious, not like this. Fram (talk) 10:23, 17 August 2026 (UTC)

  This user is new (hasn't even registered an account yet) so plenty of newcomer mistakes; not worth getting bothered by. Please consider not responding to each individual !vote against your proposal, ~2026-44851-68, it certainly does not predispose other editors to side with your cause. Thanks to Fram, though! CapnZapp (talk) 11:00, 17 August 2026 (UTC)

• Oppose readding this field, strong oppose taking it from Wikidata, the site that lists Patrice Lumumba as an "African Brazilian". Fram (talk) 10:30, 17 August 2026 (UTC)
• Oppose Pulling directly from Wikidata is bad. Pulling directly from Wikidata in the service of what is, at best, an appeal to laziness (oh no, "researchers" have to read a few lines of an encyclopedia article?!)... Let's call that "fundamentally untenable" and move on with our lives. Stepwise Continuous Dysfunction (talk) 15:50, 17 August 2026 (UTC)
• Oppose as utterly wrong-headed. The 'ethnicity' parameter wasn't removed just because of 'vandalism', and there are no circumstances whatsoever where such sensitive material should be sourced to WikiData, an inherently unreliable source. If an individual's ethnicity merits discussion in an article at all, it needs to be done in a manner that makes it clear why it is relevant. AndyTheGrump (talk) 15:58, 17 August 2026 (UTC)
• Oppose Re-including ethnicity in the infobox is a bad idea. (See Talk:John Vincent Atanasoff for an example of why.) Pulling it directly from Wikidata is Much Much Worse. SarekOfVulcan (talk) 16:08, 17 August 2026 (UTC)
• Oppose, also WP:SNOW This has been litigated time and time again. Proposal contains misinformation about the goals and reasons for why this information was removed and gives no valid qrguments for overturning the clear WP:CONSENSUS. Zackmann (^{Talk to me}/_{What I been doing}) 22:36, 17 August 2026 (UTC)
• Oppose. There will be 3 problems with doing this: headache, headache and headache. We have enough headaches dealing with the never ending LLM edits, do not need any more. So, super-snow please. Yesterday, all my dreams... (talk) 09:37, 18 August 2026 (UTC)
• Oppose readding this field. Should definitely not be imported from wikidata, that's a terrible idea. -- LCU ActivelyDisinterested «@» °∆t° 13:16, 18 August 2026 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Question about birth/death entries

Per template instructions, place the birth and death using the appropriate templates. I have noticed infoboxes without the date templates still produce an age. For example, see , which has plain written birth/death dates but still gave an age at death. If the infobox template can handle this, do we need to have birth and death sub-templates?--☾Loriendrew☽ ☏(ring-ring) 19:37, 1 September 2026 (UTC)

If you look at the source code of Template:Infobox person, you will see that Module:Person date is calculating what is being put into the fields "Born" and "Died". If you can read a little bit of Lua code, see Module:Person_date#L-123--L-129 for birth_date and the corresponding Module:Person_date#L-189--L-196 for death_date.

I figured out what happens under the hood above by just putting the wikitext of the infobox from Special:Permalink/1372610842 into Special:ExpandTemplates and noticing in the result that Category:Pages where birth or death is being automatically determined shows up right after. The category page links to the module.

You can see some additional context related to this module at Template talk:Infobox person/Archive 40#New Code Alert! Review requested… and Template talk:Death date and age text#Can this template go away? —⁠andrybak (talk) 21:21, 1 September 2026 (UTC)

I will let SME's look under the hood; my coding days stopped around Pascal.

1. If putting in plain dates work, can the instructions signify that
2. Did notice putting in birth as plain date does not give an age, so it seems not fully implemented

☾Loriendrew☽ ☏(ring-ring) 21:54, 1 September 2026 (UTC)

Did notice putting in birth as plain date does not give an age, so it seems not fully implemented – the age is put next to the death date if a value for parameter death_date is present. It is put next to the birth date, if death_date is absent. Compare {{Infobox person|birth_date=January 14, 1941|death_date=August 22, 2026}} and {{Infobox person|birth_date=January 14, 1941}}. —⁠andrybak (talk) 22:33, 1 September 2026 (UTC)

@Loriendrew: as Andrybak pointed out, this was the result of my creating Module:Person date last year. To address your points above:

1. If putting in plain dates work, can the instructions signify that: that was left by request as using the proper date templates is still helpful in some edge cases (such as birth_date that is way in the past and person is obviously deceased, but no death_date is known). I am happy to revisit that topic though.
2. Did notice putting in birth as plain date does not give an age, so it seems not fully implemented: Can you give an example? Either link to a page where you are seeing this behavior or show an example here? If there is a bug I definitely want to fix it!

Thanks! Zackmann (^{Talk to me}/_{What I been doing}) 23:56, 1 September 2026 (UTC)

What about diff at Henry Ainsworth (MP) which added a stub infobox with birth_date = 1502 resulting in "1502 (age 523–524) invalid year, age > 130"? I couldn't see any advice covering that. In this case, the death year is apparently semi-known but is either 1556 or 1557. Johnuniq (talk) 09:43, 11 September 2026 (UTC)

Super easy to fix: Special:Diff/1374320055/1374409891. The code assumes that if no death date is provided AND the birth date is in raw form, then the person is still alive. Two solutions...

1. (the one I chose), supply something for death date
2. Use one of the birth_date templates such as {{birth_year}} for this situation.

Zackmann (^{Talk to me}/_{What I been doing}) 22:30, 11 September 2026 (UTC)