Jump to content

Template talk:Infobox person

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Template talk:Infobox actor)

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

Subordinate countries in infoboxes

[edit]

Should we condense place names by omitting subordinate countries, for example, Berlin, Germany, Belgrade, Yugoslavia or Moscow, Soviet Union from past to present. After a discussion at Template talk:Infobox person/Archive 38#Adding "union republic" notion to the doc, and this edit. Absolutiva (talk) 22:41, 5 June 2025 (UTC)[reply]

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]
Take a look at discussion for Stalin's infobox (also for Putin's infobox as undiscussed), which "Russian SFSR" is omitted to make it concise as per MOS:INFOBOXPURPOSE, stated "...information should be presented in a short format wherever possible, and should exclude unnecessary content". Absolutiva (talk) 14:15, 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]
I agree with @Helpful Cat. The Soviet republics where those people were born are almost always relevant to the latter's notability (e.g. Mila Kunis, Milla Jovovich, and Georgiy Gongadze). Also, per MOS:INFONAT, we should include the former in |birth_place= if they imply the latter's citizenship (e.g. Vladimir Putin, Mikhail Gorbachev, and Alla Pugacheva). Thedarkknightli (talk) 13:53, 8 June 2025 (UTC)[reply]
Yeah, this is a great point about implying citizenship, which lets us skip the citizenship field in those cases. Helpful Cat🐈(talk) 14:41, 8 June 2025 (UTC)[reply]
Most Soviet people are considered to be Russian citizens, you cannot just add into |nationality= parameter, see this example. Absolutiva (talk) 21:52, 8 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)
Also, per MOS:INFONAT, |nationality= should not be used, but |citizenship= is fine (but citizenship can be omitted if it can be inferred from the birth country). Helpful Cat🐈(talk) 02:01, 9 June 2025 (UTC)[reply]
See edits by a user for these examples of removing "Russian SFSR" from the infobox, it should be concise and comprehensible:
Absolutiva (talk) 11:01, 14 June 2025 (UTC)[reply]
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 Novikoff 16:50, 20 June 2025 (UTC)[reply]

Again, Thedarkknightli restoring "Russian SFSR" to infobox for Vladimir Putin and Mikhail Gorbachev. Absolutiva 02:05, 24 July 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]
See RfC discussion at Wikipedia talk:WikiProject Russia#RfC: Omission of Russian SFSR from biographical infoboxes. Absolutiva 03:09, 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

[edit]

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:

  1. 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.
  2. Use |birth_name= only if the name was subsequently changed. This is Absolutiva's interpretation. Examples: ""birthname" is redundant since he never changed it" and "Birth name is redundant".

Which interpretation is correct? Khiikiat (talk) 12:20, 25 June 2025 (UTC)[reply]

The second. Nikkimaria (talk) 00:51, 26 June 2025 (UTC)[reply]
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]
I'd recommend for East Slavic people who had omitted patronymic names for infobox, including Volodymyr Zelenskyy, Boris Yeltsin, etc. Absolutiva 13:05, 17 October 2025 (UTC)[reply]

Criminal convictions

[edit]

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

[edit]

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.  GuardianH  08:34, 6 July 2025 (UTC)[reply]

@GuardianH: it looks fine to me. Can you post a screenshot of what you are seeing? Also, what is your device, browser, etc? VanIsaac, GHTV contrabout 18:48, 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.  GuardianH  22: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, GHTV contrabout 03:39, 7 July 2025 (UTC)[reply]
@Vanisaac: Where do you see this class42=title? It's not in the page wikitext, and not in the HTML that is served either. --Redrose64 🌹 (talk) 21:01, 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, GHTV contrabout 03:04, 8 July 2025 (UTC)[reply]
Ah, I thought that you meant at Lisa Su. Anyway, as documented at Template:Infobox#Main data and Template:Infobox#HTML classes and microformats, the |class42= parameter is the class associated with the |data42= parameter. The code at Template:Infobox person has: 
| label42    = {{#if:{{{office|}}}|Office|Title}}
| data42     = {{{office|{{{title|}}}}}}
| class42    = title
and since Lisa Su has 
| 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>
  <th scope="row" class="infobox-label">Title</th>
  <td class="infobox-data title"><span class="nowrap">President and CEO of <a href="/wiki/AMD" title="AMD">AMD</a></span> (2014–present)<br>Chair of AMD (2022–present)</td>
</tr>
and that's where the class ends up - in the <td class="infobox-data title"> tag. --Redrose64 🌹 (talk) 18:20, 8 July 2025 (UTC)[reply]
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, GHTV contrabout 21: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.

[edit]

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, GHTV contrabout 04: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

[edit]

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. MB2437 23: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

[edit]

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.
Architect of the Angels by Susan Maclean identifies him as an Anglican. Traumnovelle (talk) 04:26, 20 August 2025 (UTC)[reply]

New Code Alert! Review requested…

[edit]

I have a written a new module… Module:Person date. Loosely based on Frietjes’s incredible work with Module:Person height & Module:Person weight, the purpose of this module is to automatically parse |birth_date= and |death_date= into their proper {{birth date}}/{{death date}} templates. A few things to note about the template:

  • 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.

Pinging frequent editors of {{Infobox person}}: @Frietjes, Hike395, and Jonesey95: —Zackmann (Talk to me/What I been doing) 06:10, 18 September 2025 (UTC)[reply]

I added a degenerate test case called "Still alive MDY much too old". Module:Age checks for life spans of 130 years or more. – Jonesey95 (talk) 13:48, 18 September 2025 (UTC)[reply]
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
Not sure how best to proceed with this. I think it is an extreme edge case that may not need to be accounted for in Module:Person date but should definitely be addressed over at {{b-da}}. Thoughts? Zackmann (Talk to me/What I been doing) 21:20, 18 September 2025 (UTC)[reply]
It might be better for your new module to call Module:Age, which has error-checking features. I don't know if that is feasible. – Jonesey95 (talk) 21:59, 18 September 2025 (UTC)[reply]
Hmmmm. That is worth investigating. —Zackmann (Talk to me/What I been doing) 22:00, 18 September 2025 (UTC)[reply]
I have the basis for an edge check mapped out. Gotta run for a few hours but will finish up this evening. —Zackmann (Talk to me/What I been doing) 23:18, 18 September 2025 (UTC)[reply]
Ok. @Jonesey95: I have implemented a check for the age and used the same MAX_AGE of 130. As you can see in the test case it now displays a pretty clear error message. What you cannot see is that it also does a {{main other|Category:Articles using module person date older than 130}} so it will be easy to monitor any errors that pop up when the code is first implemented. Let me know if you find any other issues or edge cases. —Zackmann (Talk to me/What I been doing) 05:25, 19 September 2025 (UTC)[reply]
Found some more weird edge cases that I just resolved… In all of these the code will now just return the original input and not parse it:
  • {{infobox person/birth|{{bya|1990}}}} → 1990 (age 34–35)
  • {{infobox person/birth|1990 (age 25)}} → 1990 (age 25)
  • {{infobox person/death|1960|{{dya|1965}}}} → 1965 (aged 4–5)
  • {{infobox person/death|1960|1965 (aged 5)}} → 1965 (aged 5)
  • {{infobox person/death|1960|1965 (age 5)}} → 1965 (age 5)
Zackmann (Talk to me/What I been doing) 05:58, 19 September 2025 (UTC)[reply]
Why base your code on the horrible Template:Birth date and age text and not Template:Birth date and age? Gonnym (talk) 17:03, 22 September 2025 (UTC)[reply]

Some more testcases to look at:

  • {{infobox person/birth|Sep 1930}} → September 1930 (age 95)
  • {{infobox person/birth|SEP 1930}} → September 1930 (age 95)
  • {{infobox person/birth|Sept 1930}} → September 1930 (age 95)
  • {{Birth date and age text|Sep 1930}} → Sep 1930 (1930-09) (age 95)
  • {{Birth date and age text|SEP 1930}} → SEP 1930 (1930-09) (age 95)
  • {{Birth date and age text|Sept 1930}} → Sept 1930 (1930-09) (age 95)
  • {{infobox person/birth|1930-31}} → 1930-31
  • {{infobox person/birth|1930-1931}} → 1930-1931
  • {{infobox person/birth|1930 or 1931}} → 1930 or 1931
  • {{infobox person/birth|1930/1931}} →1930 /1931
  • {{infobox person/death|1930-31|1980}} → 1980
  • {{infobox person/death|1930-1931|1980}} → 1980
  • {{infobox person/death|1930|1980-81}} → 1980-81
  • {{infobox person/death|1930|1980-1981}} → 1980-1981
  • {{infobox person/death|1 Jan 1980|1 Jan 1930}} → Error: Death date (first date) must be later in time than the birth date (second date)

-- WOSlinker (talk) 07:20, 19 September 2025 (UTC)[reply]

Why are these here, and not at Template:Infobox person/testcases? --Redrose64 🌹 (talk) 07:53, 19 September 2025 (UTC)[reply]
To prevent filling up Template:Infobox person/testcases with JUST tests of this, can I suggest that we take further testing over to Template:Infobox person/birth/testcase? —Zackmann (Talk to me/What I been doing) 08:01, 19 September 2025 (UTC)[reply]
So I’m going to put this on hold for a little bit. WOSlinker pointed out some really good edge cases that I missed. Been thinking about how to solve them for the past few hours and think I need a new approach… If anyone thinks of more edge cases feel free to add them to Template:Infobox person/birth/testcases but I‘m going to take a few days break from working on it. —Zackmann (Talk to me/What I been doing) 20:26, 19 September 2025 (UTC)[reply]
@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|November 1990}} which should display an age range but instead displays November 1990 (1990-11) (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.
I have also added Category:Age error (0), Category:Pages using age template with invalid date (0) & Category:Articles using module person date older than 130 (0) to the categories I monitor so if/when this is rolled out I can spot any errors right away. Zackmann (Talk to me/What I been doing) 08:18, 23 September 2025 (UTC)[reply]
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]

@WOSlinker: good catch! I have initiated a discussion at Module talk:Age where the underlying problem is. I’m going to hold out implementing a custom solution in my code in hopes that Johnuniq can work some magic with Module:Age but will definitely not roll this out until that is resolved. —-Zackmann (Talk to me/What I been doing) 22:43, 23 September 2025 (UTC)[reply]

So @WOSlinker: turns out it was easier/faster to just implement the code in Module:Person date. Only took a few minutes. Check out the various test cases of DMY vs MDY. I think I checked every permutation possible, but feel free to correct me… Zackmann (Talk to me/What I been doing) 07:06, 24 September 2025 (UTC)[reply]
All looks good now. -- WOSlinker (talk) 10:14, 24 September 2025 (UTC)[reply]
@Jonesey95 and Gonnym: any objections to rolling this out? —Zackmann (Talk to me/What I been doing) 20:35, 24 September 2025 (UTC)[reply]
As a test, I have implemented the templates on {{Infobox Twitch streamer}} (421 transclusions). Hopefully that will help weed out any unforeseen issues…—Zackmann (Talk to me/What I been doing) 03:27, 25 September 2025 (UTC)[reply]
A number of the testcases in the Full birth date set section are failing at the moment for some reason. -- WOSlinker (talk) 06:44, 25 September 2025 (UTC)[reply]
 Fixed @WOSlinker: that would be because I am a complete and total moron… You make ONE TINY LITTLE CHANGE… Oh well. Thanks for catching that. Resolved. —Zackmann (Talk to me/What I been doing) 06:49, 25 September 2025 (UTC)[reply]

The rollout

[edit]

Starting VERY slow and checking for breakage along the way. A few tracking categories and searches to track the progress for those interested…

Keep the feedback coming and let me know if any issues arise. —Zackmann (Talk to me/What I been doing) 07:47, 25 September 2025 (UTC)[reply]

So just an update. I’ve run into a few issues.
  1. 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.
  2. 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.
—Zackmann (Talk to me/What I been doing) 05:21, 26 September 2025 (UTC)[reply]
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, GHTV contrabout 17:11, 26 September 2025 (UTC)[reply]
Yes, please don't add visible "unknown"s. Nikkimaria (talk) 04:37, 27 September 2025 (UTC)[reply]

Need for custom header when embeded

[edit]

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 

…
| module  = '''Criminal information'''<br />{{infobox criminal
| child   = yes
…

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?

For context I created a tracking category: Category:Pages using infobox criminal embeded (0).

— Zackmann (Talk to me/What I been doing) 21:39, 26 September 2025 (UTC)[reply]

I’ve mocked up a fix in the sandbox See this comparison. SHOULD have no impact on existing pages. Will slowly rollout with {{Infobox criminal}}. @Jonesey95: can I request a peer review? —22:38, 26 September 2025 (UTC) Zackmann (Talk to me/What I been doing) 22:38, 26 September 2025 (UTC)[reply]
I think you've got the wrong end of the stick. Look at the code for |subheader= at {{Infobox military person}}. – Jonesey95 (talk) 00:27, 27 September 2025 (UTC)[reply]
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]
Yea the issue is precisely that {{Infobox criminal}} is a wrapper for {{infobox person}}. Otherwise this would be much more trivial. — Zackmann (Talk to me/What I been doing) 03:29, 27 September 2025 (UTC)[reply]

The recent changes you have made have caused misnested tags at articles such as Hiroyasu Koga, where a child infobox is being used in |native_name=. More testing may be needed. See this new test case, copied from that article. – Jonesey95 (talk) 20:21, 27 September 2025 (UTC)[reply]

Thanks Jonesey95. I thought I had thought of everything when I tested it but there is always an edge case. I’m starting to think I should just never use span tags in infoboxes… — Zackmann (Talk to me/What I been doing) 20:31, 27 September 2025 (UTC)[reply]
The div tags don't work either. That's why I didn't change the main template. I think those tags need to come out entirely. – Jonesey95 (talk) 20:35, 27 September 2025 (UTC)[reply]
Wait… I’m not seeing any errors at Lint errors. What am I missing… —Zackmann (Talk to me/What I been doing) 20:37, 27 September 2025 (UTC)[reply]

Reported MOS:SMALLFONT problems

[edit]

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]
This tweak, to merge the two div tags, appears to maintain the larger font size for the native name and also avoid the Linter misnested div tag errors that we currently see at Hiroyasu Koga. – Jonesey95 (talk) 12:09, 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]
@Jonesey95: just wanted to say thanks for all your work on cleaning this up! --Zackmann (Talk to me/What I been doing) 18:00, 3 October 2025 (UTC)[reply]
[edit]

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.

Or is this instead a job for {{authority control}} - I'm not sure it is, because none of these were ever intended to be authority control identifiers. — The Anome (talk) 13:38, 27 September 2025 (UTC)[reply]

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]

RFC: Should color headings be removed from all person infoboxes

[edit]
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
  1. No change should be made to policy or practice.
  2. If an Infobox does violate MOS:COLOR that should be addressed on an individual basis.
-Zackmann (Talk to me/What I been doing) 07:45, 18 October 2025 (UTC)[reply]

Should color in headings be removed from Infoboxes about people and persons? —Zackmann (Talk to me/What I been doing) 09:40, 2 October 2025 (UTC)[reply]

Background

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.

  1. Color for headers, subheaders and above removed entirely from the infoboxes.
  2. A standard color be agreed upon and used for ALL headers in People and person infobox templates
  3. 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.

—Zackmann (Talk to me/What I been doing) 09:40, 2 October 2025 (UTC)[reply]

Discussion

[edit]
  • I think I'm actually the opposite here. I'm vaguely opposed to removing infobox colours atm but imo infoboxes for American sports biographies are exceptions. The colours used in such infoboxes vary so wildly based on the player's team that it's actually distracting, and often makes them hard to read. I don't see why the team affiliations are so important as to warrant such major stylistic variations on every article. Loytra✨ 08:13, 6 October 2025 (UTC)[reply]

Discussion Part 2

[edit]

@Jonesey95, Emmentalist, Bagumba, Flibirigit, GiantSnowman, CLalgo, Llammakey, Mb2437, Surtsicn, Nikkimaria, Aszx5000, Rikster2, Rikster2, Loytra, Festucalex, Isaidnoway, Vanisaac, GothicGolem29, WhatamIdoing, and Mdm.Bla: (I think I pinged everyone who commented... Thank you everyone for the comments and feedback. It seems there is pretty clear consensus at this point to not remove all color nor to disallow team colors such as those seen on {{Infobox baseball biography}} and others. With that being said, I'm curious what your thoughts are on the final idea. That is standardizing the colors used. My thinking would be something along the lines of a list of allowed color combinations or at least preferred color combinations? The goal here would be to prevent the wild west that we currently have of providing literally any color you want in a transclusion of an infobox. This would presumably go somewhere in the WP:MOS. That way if things do start to get out of hand (such as was seen with the social media infoboxes) we have an MOS page to refer to and say essentially "Hey, here are you color options. Pick one of these 5 (or 10 or 15) color patterns that have been agreed upon and are known to pass WP:ACCESSIBILITY standards." What exactly those color combinations should be would be a whole different conversation (though I think Help:Using colours#Wikimedia colour schemes would be a good place to start). Again this would NOT apply to Infoboxes that set their color based on a parameter and a switch statement (such as {{Infobox baseball biography}} or {{Infobox religious biography}}). In my opinion, there is clear consensus to keep those functioning as they are. Thanks again! --Zackmann (Talk to me/What I been doing) 07:12, 9 October 2025 (UTC)[reply]

Standardisation is a matter of their respective projects. I would contact WP:NFL, WP:BBALL, WP:NHL, etc. MB2437 07:36, 9 October 2025 (UTC)[reply]
@Mb2437: those templates are well established and all use the format I referred to regarding setting their color based on a parameter. What I'm more thinking of is things like {{Infobox Twitch streamer}}, {{Infobox noble}} or whatever the next up and coming Infobox is. This will help get some consistency. There are also a LOT of person Infoboxes with NO color in their headers. Perhaps that is less readable than have a standardized color? Zackmann (Talk to me/What I been doing) 07:42, 9 October 2025 (UTC)[reply]
It feels as though these instances can be addressed individually. Consensus has already been set by MOS:COLOR. MB2437 08:00, 9 October 2025 (UTC)[reply]
@Mb2437: I guess what I'm pushing for is an sentence or two added to MOS:COLOR that specifically addresses Infobox colors and what colors should be used. Now as I write that, I realize that this probably isn't the right place for that discussion, but here we are... Zackmann (Talk to me/What I been doing) 18:21, 9 October 2025 (UTC)[reply]
I think that "except for sports teams, if team colors are used throughout the page" might be a reasonable approach. Some sports have the whole page coordinated with the team colors (a red link?!), and using Wikipedia's standard color schemes might make that page match less. WhatamIdoing (talk) 18:01, 9 October 2025 (UTC)[reply]
Agree with User:Mb2437 this can be handled individually. GothicGolem29 (talk) 13:04, 9 October 2025 (UTC)[reply]
It'll be quicker and easier to "handle them individually" if we have a list of standard colors. "I see you made this green. Our standard green is #CEF2E0 – shall I standardize for you?" is a lot easier than "I don't like these colors. Let's change it." WhatamIdoing (talk) 17:58, 9 October 2025 (UTC)[reply]
I have doubts projects would widely accept the change to a predefined set for all. In WP:MOTORSPORT, for example, we have used standard colours for well over a decade on all results sheets—proposed changes to these in recent years, even minor, have been swiftly opposed. As long as colours are readable and meet the WCAG guidelines stated—admittedly, this should be explained clearer, ideally with maximum saturation and minimum/maximum brightness for background colours to black/white text—we should be able to use whatever shade we like to convey meaning. This has implications in sport (team colours, results matrices), politics (party colours, national colours), etc.; it would be an overreaching guideline that would be uncontrollable and ultimately cause continual divide over what is, really, a non-issue. MB2437 19:09, 9 October 2025 (UTC)[reply]

Leaning towards closing this RFC soon. Seems like there is pretty clear consensus at this point that:

  1. No change should be made to policy or practice.
  2. IF an Infobox does violate MOS:COLOR that should be addressed on an individual basis.

Anyone feel strongly that further discussion is needed? --Zackmann (Talk to me/What I been doing) 19:30, 13 October 2025 (UTC)[reply]

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.

Person date

[edit]

With the new Module:Person date now fully implemented, is there any objection to cleaning up the documentation and removing the HTML comments saying that {{birth date and age}}, {{death date and age}}, etc. should be used as they are no longer necessary? My thinking is that this cleans up the sample code a bit and makes it more readable.

As a reminder, those templates CAN still be used, but they are no longer necessary to get properly formatted dates. --Zackmann (Talk to me/What I been doing) 05:32, 14 October 2025 (UTC)[reply]

I think it's a good idea to encourage the use of those templates. If someone puts in a plain-text birth date of "November 11, 1743" or just "1743" and no death date, they will get a big red error message. The template documentation needs to provide some guidance for that, and the current guidance has been stable for a long time. – Jonesey95 (talk) 17:41, 15 October 2025 (UTC)[reply]
That is good point that I hadn't considered. Disregard. I'll leave as is. Zackmann (Talk to me/What I been doing) 17:47, 15 October 2025 (UTC)[reply]

@ User:Jonesey95 / @ User:Zackmann08. Coming across quite a few not displaying error messages, unless there's some lag? Gerda Schneider (b. 1900) and Ayres Borghi-Zerni (b. 1895) for example have ages listed & no red text. Schneider has full birth date in infobox and Borghi-Zerni just birth year. Jevansen (talk) 00:56, 18 October 2025 (UTC)[reply]

125 years is not technically an error, per a previous consensus reached at a discussion for Module:Age, if I recall correctly. Error descriptions and how to fix them are listed at Category:Pages using age template with invalid date. For unlikely ages such as 125 years, changing the infobox to use {{birth year}} is a sensible fix. – Jonesey95 (talk) 01:40, 18 October 2025 (UTC)[reply]
Fair enough, if that has been decided. I guess my concern is with articles like Ayres Borghi-Zerni ... is this page not going to display any error message because the age is under 130? We really need to be identifying articles where we have determined the subject deceased, including those with Category:Year of death missing, yet now have a current age listed. Your work around is great but we probably need it to be a maintenance category going forward? Jevansen (talk) 02:39, 18 October 2025 (UTC)[reply]
Sorry been offline for a bit. @Jevansen: I agree this is less than ideal... Category:Pages where birth or death is being automatically determined (73,432) currently tracks all the pages where the age is being calculated by the Module. Obviously with caching, it is growing by the minute... The hard part with a tracking category for possibly dead persons is there is not a way that I can think of to remove them from the tracking category once they have been checked. In other words, say I make it so every person over 100 is put in the tracking category, once you find someone who actually is still alive and over 100, how do you remove them from the category to denote they have been checked off the list (for lack of a better phrase).
If you have a suggestion, I'm 100% open to it! As Jonesey95 said, there is an easy fix. Wrapping the birth date in {{birth-date}}, {{birth date}} or {{birth year}} will remove the automatic age calculation from the page. The question remains, how to track and find those pages that need this and those that don't.
For what it is worth, I would argue that the problem still existed before this implementation. If I went to Joe Smith's wikipedia page and saw Born 10 May 1922 with no death date listed, I personally would interpret that to mean they are still alive. Maybe that is just my take, but the addition of the age doesn't change how I view that information except that I don't have to do mental math to calculate how old they are.
In any event, as I said above, if you have a suggested improvement or a good way to track the pages needing correction I'm all ears and happy to help make it happen. Zackmann (Talk to me/What I been doing) 06:38, 18 October 2025 (UTC)[reply]
Hey. Appreciate the detailed response and thanks for your work implementing this change.
Could we not have a version of Category:Pages where birth or death is being automatically determined, but only for those of above say 120, to capture the most extreme examples? Current world's oldest person is 116 so we can be confident everyone in the category would be in need of correction. They would be removed from the category upon the birth date/birth year being converted into a template. If at any point someone reaches 120 the same action would remove them from the category. You could probably lower it to 110 frankly without having to "fix" too many living people. Jevansen (talk) 08:15, 18 October 2025 (UTC)[reply]
That seems pretty reasonable to me. Jonesey95 what do you think? Zackmann (Talk to me/What I been doing) 08:17, 18 October 2025 (UTC)[reply]
I think that a number much detection limit than 130 makes sense for people whom Wikipedia is claiming are still alive. It might be possible to add a second bit of code to Module:Age, or just lower the limit to 117. We'll still need to do manual searches for articles where people are claimed to be e.g. 109 years old, just because that is so unlikely. We should be able to search for the presence of the "automatically..." category and the text "age 1[01][0-9]", but I have been unable to get searching for regular expressions in rendered text to work for me. – Jonesey95 (talk) 14:00, 18 October 2025 (UTC)[reply]
This is on my todo list, I'll find a way to create an additional tracking category in the next few days. Zackmann (Talk to me/What I been doing) 18:01, 18 October 2025 (UTC)[reply]

Making decent progress with the fixes. I've updated around 1,000 pages so far to an appropriate template, using Petscan to identify pages with an issue.

If Category:Pages where birth or death is being automatically determined is still being populated than this query will grow again, but as of now all biographical articles have been fixed. There remains a bunch of bands, assorted groups and "Murder/Disappearance of _ _ _" type pages.

I'm still working my way through this one.

Jevansen (talk) 01:39, 19 October 2025 (UTC)[reply]

Awesome! great work! Zackmann (Talk to me/What I been doing) 04:38, 19 October 2025 (UTC)[reply]
So this raises a really interesting issue... When I wrote this, I did not have any concept that |disappeared_date= was even a thing... However, both {{Infobox person}} (and its MANY wrappers) and {{Infobox military person}} have this parameter. Should I adapt this module to account for that... It would require extensive overhaul, but right now a person with a |birth_date= and a |disappeared_date= is considered still alive by the module...
@Jevansen: given the success you are having using WP:Petscan, I'm inclined to lean my focus into this disappeared_date issue instead... Any thoughts? Zackmann (Talk to me/What I been doing) 05:35, 19 October 2025 (UTC)[reply]
That sounds like a good idea. The parameter's a new one to me too. Happy to keep working through the Petscan queries on my end. Cheers. Jevansen (talk) 07:24, 19 October 2025 (UTC)[reply]
Maybe the simplest options is to not add an age to any birth dates if disappeared_date is set to any value? Also, here's a slightly different Petcat query looking for those with an age set but not in the Living person category. -- WOSlinker (talk) 08:00, 19 October 2025 (UTC)[reply]
LOL!!! @WOSlinker I literally am seconds away from saving code in the Module's sandbox that does EXACTLY that... You hit the nail on the head! Great minds... I'll tag you in my request to review the code. Zackmann (Talk to me/What I been doing) 08:02, 19 October 2025 (UTC)[reply]
Several people have disappeared - Amelia Earhart, Glenn Miller and Lord Lucan are some of the best known. For two of these three, we can estimate a death date with reasonable accuracy - how long can you survive at sea with no raft or boat? But Lucan may still be alive and well living in an assumed name. --Redrose64 🌹 (talk) 10:58, 19 October 2025 (UTC)[reply]
@Redrose64: of for sure. To be clear, this is absolutely something that should be supported. It just wasn't something that I considered when I first wrote the code. Zackmann (Talk to me/What I been doing) 17:31, 19 October 2025 (UTC)[reply]
@Jevansen: With this and this you should see a drop in your query over the coming weeks. Now when |disappeared_date=something age is not calculated. I couldn't find any other Infoboxes (that weren't wrappers of {{Infobox person}}) with a disappeared_date so this should cover em all. . Zackmann (Talk to me/What I been doing) 18:19, 19 October 2025 (UTC)[reply]
Excellent, good job. I'll skip anyone with this parameter. Jevansen (talk) 00:19, 20 October 2025 (UTC)[reply]

Implement Wikidata for image

[edit]

I have found that a number of infoboxes now have a call to Wikidata to retrieve an image, if one exists. Was going to add that here with the following caveats:

  • If |image=something, that something will always override the wikidata value
  • If |child=yes or |embed=yes then there will NOT be a call to wikidata (this to prevent duplicate images from appearing when the template is nested.

Per this search there are at least 38 infoboxes using this method (full disclosure some of them need updating to account for the case of child/embed being true, I'm working on fixing that also).

I don't see any downside here... I cannot come up with a situation where you would call {{Infobox person}} as the parent Infobox (i.e. not child or embeded) and be disappointed that an image of the person showed up. That being said, I want to get another perspective on this. Is there a use case I'm not thinking of??? Zackmann (Talk to me/What I been doing) 07:43, 18 October 2025 (UTC)[reply]

Don't think we should do that - see this discussion. Nikkimaria (talk) 13:52, 18 October 2025 (UTC)[reply]
Please do not. There are tons of images for people on Wikidata that are not appropriate for their infoboxes. To browse through Category:No local image but image on Wikidata is like panning for gold: lots of junk, some false gold, and only the occasional nugget. The images for Maksat Atabayev and Giovanna Oliveira and Victor Osuagwu are not ones that meet our infobox criteria, for example. Peter O'Sullevan is inexplicable. Julio Pérez (footballer, born 1926) is an all-too-common team photo. There are drawings, Arabic names inside badges, and much more that just won't work. – Jonesey95 (talk) 13:57, 18 October 2025 (UTC)[reply]
Support. Would require a parameter to not include image from Wikidata. I think the problematic pictures can either be fixed on wikidata, or excluded on enwiki. Most images on wikidata looks good, and it will help bringing more pictures to enwiki. Tholme (talk) 17:54, 18 October 2025 (UTC)[reply]
So based on Nikkimaria's and Jonesey95's responses I'm not going to just plow ahead with this, but I do think it warrants further discussion. Perhaps another RFC...
Nikkimaria, I did NOT read through the entire discussion thread you linked too, but I do note that it is from about 7 years ago. I'm wondering if Wikidata has gotten better and more stable in the interim. Perhaps consensus has shifted and it warrants a new discussion.
Jonesey95 excellent points. I particularly like your statement that it is like panning for gold: lots of junk, some false gold, and only the occasional nugget. I wonder if the benefits outweigh the occasional bad image (is it occasional, I don't know... You sure found a number of great counterexamples). In any case I do think this warrants further discussion but I will NOT push this change through without clear consensus. Zackmann (Talk to me/What I been doing) 18:13, 18 October 2025 (UTC)[reply]
I'd actually suggest you do what Jonesy95 proposed: go through Category:No local image but image on Wikidata and see how many cases there are where there is not a local image and where the Wikidata image would be appropriate for the infobox. I just looked at 20 from the first page of entries; I found one worth adding (and a few cases where there actually was already an image). Nikkimaria (talk) 18:23, 18 October 2025 (UTC)[reply]
Sounds good. I'll investigate further. Appreciate the feedback. Always helpful to get another perspective. Zackmann (Talk to me/What I been doing) 18:26, 18 October 2025 (UTC)[reply]
I'm generally pro-Wikidata (and I like the {{Infobox person/Wikidata}} version of this template very much – when the Wikidata side is in good order, the implementation is well done, etc.). That said, looking at the examples Jonesey95 linked, I'd also agree that restraint is in order here. There's a qualitative difference between using Wikdata (carefully and skilfully) to facilitate and improve what's done here on enwiki vs. (somewhat indiscriminately) hoovering up every Commons photo that's been added to Wikidata without due diligence. In my view, if one exists isn't enough of a filter. This approach seems risky and fraught with potential downsides. -- Cl3phact0 (talk) 19:32, 18 October 2025 (UTC)[reply]
Strong oppose. There are many reasons why the wikidata image might be a bad choice for an infobox. For an egregious example see Hypatia where long consensus on talk is that the early-20th-century American image of an idealized and demure young woman from a children's work of historical fiction (filled with anachronistic early-20th-century American attitudes that overflow onto the image) belongs in the article's discussion of that work of fiction but not in the infobox. Alerting human editors to the existence of a wikidata image that might be manually added to the infobox is fine. Adding these images automatically and forcing human editors to clean up the resulting mess is the opposite of fine.
Incidentally, I recently took a pass through a dozen or so articles in the no local image category and agree with Jonesey95's point about panning for gold. Maybe half were usable automatically, charitably. The other half included user-generated portraits of the subject (not generally usable by consensus here), images that already appeared elsewhere in the article with better context than could be provided in the infobox (not a good choice for the infobox), images that appeared elsewhere but were ok for the infobox (required manually editing to avoid duplication) and images that required a human-edited caption to provide enough context to be usable in the infobox (ok for the infobox but not ok for automatic inclusions). —David Eppstein (talk) 20:44, 18 October 2025 (UTC)[reply]
Oppose Tried 30 or so, and found few good ones. Selected people with unusual surnames, as that might also lead to a new surname page or at least a redirect. Edwardx (talk) 22:11, 18 October 2025 (UTC)[reply]

Groups using infobox

[edit]
Moved from Template talk:Infobox social media personality § Groups using the infobox
 – Zackmann (Talk to me/What I been doing) 08:19, 21 October 2025 (UTC)[reply]

I noticed that Sidemen uses the YouTube template but needs to hack it to work for multiple people which isn't ideal as the key/value way a table works fails here. The "birth_date" parameter with a value Olajide Olayinka Williams Olatunji (KSI) 19 June 1993 (age 32) isn't correct as that obviously isn't a birth date.

One option would be to add multiple |birth_namex= and |birth_placex= parameters. Another would be to just use |current_members= and |past_members= like {{Infobox musical artist}} (without birth date and location). There probably are other ways to handle this. Gonnym (talk) 08:57, 19 October 2025 (UTC)[reply]

Well, isn't it possible to just say X (birth date) Y (birth date) Z (birth date)? Earth605talk 12:27, 19 October 2025 (UTC)[reply]
Not if you want the data to be meaningful for screen readers. The infobox is basically a table so for each cell you should have one type of data. If the label is "Born" and your value is "X (birth date) Y (birth date) Z (birth date)" that is meaningless (It's also meaningless for those that can see the text, but at least they can more easily understand the context). Gonnym (talk) 12:50, 19 October 2025 (UTC)[reply]
@Gonnym: I'm glad you brought this up. I have stumbled across a few of these as I've been working on the conversion. This is not a new problem. For example, see Penn & Teller. I think it it is a fairly rare use case, BUT I am 100% open to any way to improve it. I would suggest that this conversation be moved to Template talk:Infobox person as it is not unique to this template and any fix to Infobox person will fix it for all the wrappers including this one. Zackmann (Talk to me/What I been doing) 17:36, 19 October 2025 (UTC)[reply]
I just went to check how this is done on other articles, and it looks like the Wright brothers have found a solution. This article uses Template:Infobox person embedded within another use of the same template, which essentially divides the infobox into sections for Orville and Wilbur. I think this is the right way to do it, as it is clearly readable, so there is no need to change the template itself. — Vigilant Cosmic Penguin 🐧 (talk | contribs) 03:00, 21 October 2025 (UTC)[reply]
So I think that is an excellent solution when you have TWO people who are equally notable. Would certainly work for Penn & Teller. But going back to the original example, I don't think that is a good solution for Sidemen where you have seven people. The infobox would be absurdly long. --Zackmann (Talk to me/What I been doing) 03:04, 21 October 2025 (UTC)[reply]
I also don't think this is the same situation. Orville Wright and Wilbur Wright don't have stand-alone articles so their complete bio information is located in the group article (Wright brothers). Penn Jillette and Teller (magician) have stand-alone articles, so the infobox at Penn & Teller should be about the act, not the individuals, as that information is already located a click away. The same is true for the Sidemen, which each has a stand-alone article. Gonnym (talk) 08:15, 21 October 2025 (UTC)[reply]
Very valid point... Zackmann (Talk to me/What I been doing) 08:17, 21 October 2025 (UTC)[reply]
@Gonnym, Vigilantcosmicpenguin, and Earth605: just a courtesy ping that this discussion has been moved. -Zackmann (Talk to me/What I been doing) 08:22, 21 October 2025 (UTC)[reply]

Remove and truly deprecate nationality

[edit]

Per MOS:INFONAT: In biographies, a |nationality= field should not be used. This is the result of a 2024 discussion. In Template:Infobox person#TemplateData the |nationality= is marked as deprecated and in multiple places on the doc page it specifically says NOT to use this parameter. But yet we still support AND display the parameter.

It seems pretty clear that this should be removed. I don't feel the need to do a true RFC since it is literally in the MOS not to use it AND this template's own documentation says do not use.

What I am suggesting is the following:

  1. Remove it from being displayed as per this comparison
  2. To prevent an explosion of Category:Pages using infobox person with unknown parameters (which I monitor daily for other issues), leave it in the Module:Check for unknown parameters call
  3. Add Module:Check for deprecated parameters. For those unfamiliar with this module, it will add a preview warning that will say Page using Template:Infobox person with deprecated parameter "nationality". It should be removed.. It will also add pages to Category:Pages using infobox person with deprecated parameters, which I will create and can be used to quickly clean up these transclusions by a bot.
  4. Remove |nationality= from Template:Infobox person/doc and all wrapped template documentations.

Does anyone see any reason that this violates what is clearly spelled out in MOS:INFONAT and on this templates own documentation page? Zackmann (Talk to me/What I been doing) 20:26, 27 October 2025 (UTC)[reply]

Is 2/3 intended to be a transitional status, or permanent? Nikkimaria (talk) 23:52, 27 October 2025 (UTC)[reply]
Are there any wrappers of this template that use |nationality= to mean something other than the meaning indicated in MOS, such as sporting nationality? If so, they may need to be migrated to do something different rather than having this parameter removed. – Jonesey95 (talk) 00:12, 28 October 2025 (UTC)[reply]
@Nikkimaria: numbers 2 & 3 are transitional to facilitate the removal. The ultimate goal being to completely remove {{{nationality}}} from this template. I don't want to blow up the unknown params category with the roughly 100,000 pages that currently use nationality. Hence the use of a deprecation category to track those cases. Thanks for the clarifying question. Zackmann (Talk to me/What I been doing) 01:15, 28 October 2025 (UTC)[reply]
@Jonesey95: a quick perusal of Category:Templates calling Infobox person the only one I see is {{Infobox boxer}}. That should be calling {{Infobox sportsperson}} (which to be clear I do not intend to change at this time). I will switch Boxer to use sportsperson. Zackmann (Talk to me/What I been doing) 01:18, 28 October 2025 (UTC)[reply]
@Jonesey95: {{infobox boxer}} is converted. --Zackmann (Talk to me/What I been doing) 06:44, 28 October 2025 (UTC)[reply]
Also needs another step: "Remove from documentation on templates where it should no longer be used". -- WOSlinker (talk) 11:15, 28 October 2025 (UTC)[reply]
WOSlinker yes, thank you. I didn't mention that because I kind of took it as a given, but I'm going to add it now for clarity. Zackmann (Talk to me/What I been doing) 15:08, 28 October 2025 (UTC)[reply]
As long as it doesn't affect the parameter country= {{ESP}} or country_represented= {{ESP}} then I think the WikiProject Tennis template "Infobox tennis biography" is ok. Fyunck(click) (talk) 03:54, 29 October 2025 (UTC)[reply]
@Fyunck(click): this is about removing |nationality= from {{Infobox person}}... In no way, shape or form does it affect your tennis biography template which doesn't use this code in anyway... not really sure what your concern is? Zackmann (Talk to me/What I been doing) 04:28, 29 October 2025 (UTC)[reply]
I just wanted to make sure that nationality= and country= weren't bound together in any way. Thanks. Fyunck(click) (talk) 06:18, 29 October 2025 (UTC)[reply]
You precious tennis template has NOTHING to do with this Infobox... Zackmann (Talk to me/What I been doing) 06:22, 29 October 2025 (UTC)[reply]
Thanks for clarifying that in your usual flowery way. Fyunck(click) (talk) 09:26, 30 October 2025 (UTC)[reply]
Alternatively, could pages using the template with |nationality= be placed in a dedicated tracking category instead (e.g. Category:Pages using infobox person with nationality)? That category can be a holding area while the value is moved to another parameter or removed as unneeded (e.g. duplicates |birth_place)=, etc.) That would seem to result in no downtime of information being lost. It can be removed from being displayed by the template once all instances have been removed on transcluded pages.—Bagumba (talk) 06:21, 30 October 2025 (UTC)[reply]
Bagumba so from a technical standpoint that is definitely an option... That being said, I don't feel the need to do it that way. We are talking about nearly 100,000 pages here. I don't see a scenario where 100,000 pages are manually checked and the |nationality= value sometimes moved to |birth_place=. I think that overwhelming majority of these cases have a nationality as just that, a nationality (e.g. American, Russian, French, etc.), not a place of birth (e.g. Paris, France; New York City, United States; Moscow, Russia) which is supposed to be more specific than a nationality. Are you seeing something different where a large amount of place of birth data will be lost? - Zackmann (Talk to me/What I been doing) 15:06, 30 October 2025 (UTC)[reply]
Perhaps I misunderstood #3's quickly clean up these transclusions by a bot. Would that not add an appropriate |citizenship=, when applicable? —Bagumba (talk) 15:50, 30 October 2025 (UTC)[reply]
That was not my thinking... Per MOS:INFONAT, |citizenship= should only be used in very specific circumstances. There is an argument to be made that each of the 100,000 articles needs to be manually checked, but I just don't see that EVER happening. My (admittedly limited) research, tells me that 99+% of |nationality= uses violate MOS:INFONAT. Rather than manually check 100,000 articles which could take ages, my personal recommendation is to just mass delete the parameter. On those few pages where it doesn't violate MOS:INFONAT, |citizenship= can be added back by watchers of the particular page. Zackmann (Talk to me/What I been doing) 15:59, 30 October 2025 (UTC)[reply]
Would this be submitted to WP:BOTREQ? If so, "quickly clean up" should be clarified as something like "blindly remove". Note that for a tool like WP:AWB, WP:AWBRULES reads:

You are responsible for every edit made. You are expected to review every edit, just as if you were making an edit using Wikipedia's edit form when editing by hand. Do not sacrifice quality for speed, and review all changes before saving.

—Bagumba (talk) 16:21, 30 October 2025 (UTC)[reply]
If the consensus is in fact to just remove the parameter (you are correct that should have been clearer) then I would request a run from PrimeBOT who already has bot approval to perform this exact type of task, blind removal of deprecated/no longer used parameters. Zackmann (Talk to me/What I been doing) 22:28, 30 October 2025 (UTC)[reply]
Based off of a cursory search, my concern with blind removal are cases like Henry Cavill (country should be added to birthplace) or John Singer Sargent ("American" in lead sentence, but birthplace is Tuscany and died in England.—Bagumba (talk) 23:19, 30 October 2025 (UTC)[reply]
Thank you for coming back with examples! Not just using weasel words. Very helpful.
Hmmm. Henry Cavill doesn't worry me. Yes the Country can be added to the birthplace, but the birthplace already indicates where he is from. If you don't know where Jersey is/what country it is in, that answer is literally a click away since it is wikilinked.
The case of John Singer Sargent is different. That goes to the heart of the discussion that led to MOS:INFONAT. This information doesn't belong in the Infobox. It belongs exactly where it is, the lead sentence of the article. You say you are objecting the the blind removal of the parameter, but this example seems to imply you are objecting to it being removed from JSS at all. Is there somewhere in his infobox (besides |nationality= that you feel this information should go? As you point out he has a birth and death place...
Keep those examples coming if you find others that are concerning though! Zackmann (Talk to me/What I been doing) 23:27, 30 October 2025 (UTC)[reply]
re: Cavill: For {{Infobox basketball biography}}, nationality was removed in bios when it matched the country in the birthplace, but editors manually added it to |birthpace=, when missing, mostly retaining information—not newly forcing a click—when one wasn't needed before. —Bagumba (talk) 23:32, 30 October 2025 (UTC)[reply]
re: Sargent: I don't have an immediate opinion, other than the concern of whether it should be retained in the infobox somewhere else should be a human decision on a per-case basis, not a blind removal. —Bagumba (talk) 23:35, 30 October 2025 (UTC)[reply]
re cavil: Again though, are you saying that if nationality does not match the birthplace it should stay? Because that goes completely against the MOS which clearly says nationality should go entirely...
re Sargent: my only point is that if there is no other place in the infobox to put that data, what difference does it make if it is blind removed or not.
Again let's remember we are talking about nearly 100,000 pages with this parameter alone. {{Infobox basketball biography}} has barely 23,000 TOTAL uses. I would imagine the uses of |nationality= were far less. I would also point out that basketball biography did NOT remove the nationality parameter... It just deprecated it. We are talking about removing it from {{Infobox person}} entirely. Two different situations. Zackmann (Talk to me/What I been doing) 23:38, 30 October 2025 (UTC)[reply]
Again though, are you saying that if nationality does not match the birthplace it should stay?: I'm saying that a conversation should be had on if it is acceptable to blindly remove, when it might sometimes be appropriate to be retained by placing the country to birth_place or citizenship. I operate on WP:THEREISNODEADLINE, so I don't think there necessarily needs to be a rush. Thanks. —Bagumba (talk) 00:09, 31 October 2025 (UTC)[reply]
gotcha. sorry if I came across confrontational... was just trying to understand... Zackmann (Talk to me/What I been doing) 02:25, 31 October 2025 (UTC)[reply]

Date of Birth

[edit]

Hey, guys. I don't know if you are aware of this, but there is an ongoing discussion going on at Wikipedia talk:Manual of Style#DOB but without year? regarding the birth dates. Your input would be greatly appreciated. Thanks, sjones23 (talk - contributions) 07:30, 28 October 2025 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_person&oldid=1319652406"