Template talk:Infobox person

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

Home town field

Should the "Home town" field be removed from infoboxes? 21:48, 7 August 2020 (UTC)

This thread Template talk:Infobox person/Archive 35#Proposal: Repurpose and redocument the home town parameter seems to have been archived without a final decision. I am wondering if there needs to be a full RFC or can this new discussion reach a WP:CONSENSUS without that. I know the documentation reads "The place where the person was raised and matured, if different from birthplace" In spite of that IMO there are a few things that make the field problematic including

1. It's subjectivity. The term seems to mean different things in different cultures.
2. People are often raised in more than one city so it is WP:OR and WP:SYNTH to pick one over the other.
3. Some people may consider one location where they grew up their hometown even though they lived in another location for a longer period of time which adds to the subjectivity.
4. The terms "raised" and "matured" cause further confusion. People can be raised in one location but might not mature until they've left home, gone to college or work etc.
5. What is the cutoff to determine this? Age? Something else? Any answer to this also bumps into OR problems.
6. The trivial nature of the info. Is there encyclopedic value in labeling a place a person grew up as their home town?
7. Sourcing. I have yet to see its use come with a WP:RS.

At this point I would support its outright removal but if this discussion can deal with the above then the focus should shift to clarifying the documentation for the field. Thanks ahead of time to anyone who adds there input. MarnetteD|Talk 02:53, 7 August 2020 (UTC)

• Support removal. And yes, MarnetteD, I would put an RfC tag on this. This parameter does not really serve an encyclopedic function, and is frequently misused, and confusing. No one (least of all the reader) seems really sure whether this is for, since the term is simply ambiguous in English usage. Is it: where someone was born, regardless how long they lived there afterward; where someone grew up; where someone spent the majority of their life; where someone spent the majority of their working life; where someone spent the majority of their life after becoming notable; where someone lives now (or lived at the time of their death); every place in which the subject owns/owned a home; every place the subject has ever lived; or what? The reader, and innumerable editors, perpetually wonder. Just remove it. I would say that it's outlived its usefulness, but it never actually had any. To the extent that someone lives/lived, down to the local level, is important to a particular article, that information belongs in the article body with sufficient context to make it clear why it is relevant. If it's very, truly relevant it will also be reflected in their categorization. A good rule of thumb is that if a categorization ends up being disputed/reverted, or is not present in a long-established and stable article, then that location really is not relevant to the subject's encyclopedic notability, and may not need to be in the article, and definitely does not belong in the infobox, which is a précis of only the most important factoids.  — SMcCandlish ☏ ¢ 😼  10:43, 7 August 2020 (UTC)
• Support Wherever I lay my hat, thats my home. Only in death does duty end (talk) 10:47, 7 August 2020 (UTC)
• A RFC tag would be good as there are 23 different infobox templates that have the home_town parameter. -- WOSlinker (talk) 11:24, 7 August 2020 (UTC)
• Support removal per MOS:INFOBOXPURPOSE: The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance. The few cases where it might be useful is outweighed by those who blindly add it for "consistency" without editorial oversight.—Bagumba (talk) 12:27, 7 August 2020 (UTC)
• Support per MarnetteD. ~ HAL333 17:14, 8 August 2020 (UTC)

Removal of home town field

See above for a discussion regarding my reasons for starting this RFC. MarnetteD|Talk 16:30, 7 August 2020 (UTC)

Support removal

• Support per my post in the thread above. MarnetteD|Talk 16:30, 7 August 2020 (UTC)
• Support Otherwise Paul Simon is from from Widnes. ——Serial 16:50, 7 August 2020 (UTC)
• Support Because the meaning is not precise. It seems to be mostly used when someone is born in one place but spent a substantial part of their childhood somewhere else. I looked at some articles and saw it used for the place someone lived at "shortly after birth", at 2, at 4, at 10, at 12. One infobox listed two hometowns, the article said the first was in "early childhood". When/how to use it is just too subjective. MB 02:27, 25 August 2020 (UTC)
• Support per MarnetteD. Kaldari (talk) 03:07, 22 October 2020 (UTC)

@Kaldari: this discussion was closed on 12 September. -St3095 ^(?) 11:11, 24 October 2020 (UTC)

Oppose removal

• Oppose It can be misused and lead to debates, but there are also legitimate uses where it isn't just trivia. Examples include historical figures, like Jesus and Mary, mother of Jesus, and individuals who changed countries like Emily Ratajkowski, to non-celebrities like Northrop Frye. In such cases, the field is more than just trivia, and its value is supported by RS, so there is a problem with the loss of information. Many examples here. I don't think the nom/supports have taken a broad view of the proposal, and many of the points made are easily refuted just with a couple of examples where it's useful. On balance, this seems like a bad idea to me. ProcrastinatingReader (talk) 14:26, 23 August 2020 (UTC)

Further discussion

If the consensus is to remove the field would someone with the know how please a) make sure that it gets removed from all 23 infoboxes that WOSlinker linked to and b) create a category like Category:Infobox person using residence so that wikignomes far and wide get to work removing it from any articles that it is used in. OTOH if the consensus is keep this request can be ignored. MarnetteD|Talk 16:30, 7 August 2020 (UTC)

Please fix the RfC statement, in accordance with WP:RFCST and WP:RFCBRIEF. The present statement, as copied to the listings, tells us absolutely nothing about the issue. --Redrose64 🌹 (talk) 18:39, 7 August 2020 (UTC)

Doesn't the pointing to the thread immediately above cover this? As mentioned here I have not started one of these in a long time so any moves or fixes that are needed will be appreciated. MarnetteD|Talk 18:47, 7 August 2020 (UTC)

I didn't see that edit, because this page was not on my watchlist at the time. The RfC listings, however, are on my watchlist, so I get news of every new RfC within an hour of it being raised. Remember that many people who come to an RfC will also have come from outside, perhaps via WP:FRS, and will also not have seen the edits that led up to it hitting the RfC listings.

On the listing pages, a phrase like "See above" has neither context nor link - does "above" refer to the previous RfC in the list, for example? This is why WP:RFCBRIEF has the paragraph beginning "The statement should be self-contained". --Redrose64 🌹 (talk) 19:28, 7 August 2020 (UTC)

Redrose64, MarnetteD changed the statement before your last post with this edit. Not optimal, but perhaps WP:NOTBUREAUCRACY applies at this point.—Bagumba (talk) 00:28, 8 August 2020 (UTC)

I know that they changed it, I was replying to their post of 18:47, 7 August 2020 (UTC) where they asked "doesn't the pointing to the thread immediately above cover this?" Explaining how a bot works is not "bureaucracy", because bots aren't that flexible. Since Legobot (talk · contribs) is coded to expect the RfC to be formatted in a particular way, then any deviation from that will cause a sub-optimal listing entry. --Redrose64 🌹 (talk) 12:07, 8 August 2020 (UTC)

Edit request

Per the discussion above Template talk:Infobox person#Home town field it looks like there is a consensus to remove the field. So I am requesting that |home_town= be removed from the template and corresponding documentation. MarnetteD|Talk 23:46, 8 September 2020 (UTC)

@MarnetteD:  Done. Please can you help with removing it from documentation of any template that used this field? — Martin (MSGJ · talk) 12:17, 11 September 2020 (UTC)

Thank you MSGJ. I will add it to my wikignome list and be getting to work on it :-) MarnetteD|Talk 15:30, 11 September 2020 (UTC)

@ProcrastinatingReader: I am getting a deprecated parameter warning at Paulo Freire despite the parameter not being used. I think this may be being caused by your most recent edit. 207.161.86.162 (talk) 02:56, 24 September 2020 (UTC)

Hmm, that is interesting... I've looked at several other pages, on preview and now in live, not having this issue (eg Emma Stone or Erin Phillips). Though, that article is also using |influences= (also deprecated & removed) without it being suppressed from infobox or categorised, which is also making me itch my head a bit. ProcrastinatingReader (talk) 03:16, 24 September 2020 (UTC)

It's not using the influences parameter directly. {{Infobox academic}} is embedded in it. 207.161.86.162 (talk) 03:24, 24 September 2020 (UTC)

I see. That'll be why. I've added |ignoreblank=, which seems to have fixed the issue on that article and others that use wrappers with an empty param. ProcrastinatingReader (talk) 03:26, 24 September 2020 (UTC)

Ahhh, that seems to have fixed it. Thanks! And if that's the issue, would you be able to remove the parameter from {{Infobox academic}} to prevent any issues with embedding it in other infoboxes? 207.161.86.162 (talk) 03:34, 24 September 2020 (UTC)

 Done - thanks for raising the point! Will probably remove it from other wrappers at some point, as well. ProcrastinatingReader (talk) 03:35, 24 September 2020 (UTC)

Thanks! 207.161.86.162 (talk) 03:52, 24 September 2020 (UTC)

Partner

There's a discussion on my talk page right now about the |partner=. It sounds like the documentation for this template isn't providing adequate information to some editors about how to differentiate between a romantic partner that should be listed vs a romantic partner that should be excluded. Should we try to clarify this? WhatamIdoing (talk) 22:23, 31 August 2020 (UTC)

@WhatamIdoing: I'm sorry that I didn't see this sooner, otherwise I would have commented sooner. Please put me down on a list of people who perpetually want more clarity with vague Infobox instructions. If people are confused about something, we should establish consensus about it. Cyphoidbomb (talk) 22:55, 13 September 2020 (UTC)

Parent(s)

As we do not currently have human cloning, any person is going to have two biological parents. As such, there is no situation where this field could conceivably be singular. A parent might be unknown, but must exist and could simply be listed as "unknown father/mother". --Khajidha (talk) 13:14, 2 September 2020 (UTC)

The field is for "notable" parents. An unknown parent is certainly not notable. If only one parent is notable, |father= and |mother= can be used. MB 15:18, 2 September 2020 (UTC)

Sounds like a pretty silly way to set it up. Why have a "parents" field if we also have separate fields for father and mother? --Khajidha (talk) 15:58, 2 September 2020 (UTC)

Because that covers the four possible cases:

1. Both parents notable: use |parents=.
2. Only mother notable: use |mother=.
3. Only father notable: use |father=.
4. Neither parent notable: omit the field.

What's the problem? --RexxS (talk) 16:07, 2 September 2020 (UTC)

Because you could just have the mother and father parameters. If both are notable, fill in both. If only one is notable, only fill in that one. If neither is notable, don't fill in either.--Khajidha (talk) 16:27, 2 September 2020 (UTC)

Why would editors have to use two parameters when we can provide the information in a single field? That sounds like a pretty silly way to set it up. --RexxS (talk) 16:54, 2 September 2020 (UTC)

Because they are separate pieces of information. And what happens if person A has one parent who is notable and another who is not, but the non-notable parent later becomes notable? Would you delete the field for the previously notable parent and then put both names in the same field? Seems pretty silly to do it that way, when you could just leave the previously filled in field alone and fill in the other one, too. --Khajidha (talk) 17:31, 2 September 2020 (UTC)

I bet you've already spent more time arguing about this than has been spent in total dealing with the use case you just mentioned. --Laser brain (talk) 17:47, 2 September 2020 (UTC)

Probably. Doesn't make the way the fields are currently set up any less silly. --Khajidha (talk) 18:09, 2 September 2020 (UTC)

@Khajidha: "there is no situation where this field could conceivably be singular." Artificial insemination of single mother by unknown donor? As for the greater point: why have multiple parameters that do the same thing, I tend to agree. It might be wise to drop |mother= and |father= and instead provide better instructions for how to use the |parents= parameter. |parents= seems the more flexible of the three parameters, as it includes binary parent labels, and allows for non-binary parents and for the inclusion of notable same-sex parents who may have adopted. Cyphoidbomb (talk) 18:50, 14 September 2020 (UTC)

Pronouns at a Glance

Using the correct pronouns for people is more important now than ever, and I feel Wikipedia should create this as an option separate from smaller details written later in the text. One of the most important things to know about someone is their pronouns, and it should be easily visible when a person is Googled. For some people, they are cisgender and it is more 'obvious' what their pronouns are, but for others, they do not have that luxury. I propose we add a drop-down menu where we can add pronouns. Having a drop-down would prevent harassment, and require less monitoring and correcting. We should include pronouns such as He/Him, She/Her, They/Them, and Ze/Zir. Genderbandit (talk) 07:51, 4 September 2020 (UTC)

There aren't drop-down menus for anything. WhatamIdoing (talk) 23:37, 13 September 2020 (UTC)

I don't understand the idea for a drop-down menu, but I would agree that adding a pronouns parameter would be an excellent addition and if it was added to as many pages as possible, both cis and trans people, and started being done as common practice, then I think that any sort of harassment would be avoided. Zin373 (talk) 07:40, 20 October 2020 (UTC)

other_names parameter: When is a nickname not appropriate for inclusion

I'm not clear on when the other_names parameter is properly used for nicknames. I've seen lots and lots of usage, often with cute media-applied nicknames.

Extended content

"Fergie" for Sarah Ferguson the Duchess of York, the common nickname that was ubiquitous throughout the tabloids? "The Governator" for Arnold Schwarzenegger, what some US media outlets called him when he was governor of California? "Ilyathalapathy" (young commander) and "Thalapathy" (commander) for Indian Tamil actor Vijay?[1] "Megastar Mammootty" for Indian Malayalam actor Mammootty?[2] "Megastar Chiranjeevi" for Indian Telugu actor Chiranjeevi?[3] "Megastar Amitabh Bachchan for Amitabh Bachchan?[4]. And while we're on the subject of Bachchan, what about the five other nicknames in his infobox? "Angry Young Man", "Shahenshah of Bollywood", "Star of the Millennium", and "Big B"? "Machine Gun Kelly" for George Kelly Barnes? "Bunny" for Allu Arjun because he played a character called Bunny in a film and some media outlets call him that?[5] "Crooked Hillary"? "America's Sweetheart" for various American actresses? Various nicknames for Al Capone? "Jack Spot" for Jack Comer? "King of Pop" for Michael Jackson? (It's not in the infobox.) Bollywood's Dhoni for Sushant Singh Rajput?[6][7]. "Melody Queen Of India" for Shreya Ghoshal?[8] "The Marlon Brando of South Indian cinema" for Sivaji Ganesan?[9] Intuitive nicknames like "A. R. R." for A. R. Rahman? "Thalaiva" (leader) for Rajinikanth? "Tarak, Tollywood Thalaiva, Young Tiger" for N. T. Rama Rao Jr.?[10] Here I see a whole bunch of superlative nicknames for Rajkumar: Golden Man, Gifted Actor, Universal Man, Respected Elder Brother, Should those go in there? Some seem to make their way in here.

Without clear criteria, I'm really not sure how these should be properly used and it's difficult to educate people on proper usage. Some nicknames seem very promotional, especially when the press is drooling over the person, or when fans are drooling over the person and want to add these nicknames. But I can't quantify the difference between "King of Pop" and "Megastar" or many of the others. So how can I explain why I deleted "Big B"? And if the media has a bunch of nicknames for someone, should those all be included? Or should we only be using this parameter for professional nicknames like Duane "The Rock" Johnson? Or nicknames that the subject's peers gave them, vs. what the media calls them? That would at least seem more consistent with Al Capone, assuming his peers called him "Snorky". Thoughts? Cyphoidbomb (talk) 16:59, 5 September 2020 (UTC)

Cyphoidbomb, I think I can give you about half of an answer, and perhaps someone else has more.

The first thing is that it needs to be a name, i.e., not a title or description. So if you can imagine someone (e.g., a fan) actually addressing the person that way, then it's possible that it would be worth included. That suggests that options such as "King of Pop", "America's Sweetheart", "Megastar", "The Marlon Brando of South Indian cinema", and "Gifted Actor" are all out. "Big B" might be acceptable under this rule.

Second, there shouldn't a large number of them. Duane "The Rock" Johnson is an example of this. He's got one nickname that anyone knows about. The long list at Amitabh Bachchan would not be acceptable there.

Third, the nicknames should be stable. They should not represent a single moment (e.g., an actor gets called Bunny for a year, and then everyone forgets about that movie) or try to record an ever-changing and perpetually outdated list. If it's the custom in the relevant sources to make up a new way to refer to a celebrity every few months, then we should neither try to catalog all of them nor even to record the most recent. WhatamIdoing (talk) 23:52, 13 September 2020 (UTC)

• Concur with the above. Re. parameter misuse, unfortunately this happens to many "subjective" fields especially, which tend to draw trivia or fan labels. I'm not a big fan of "other name" params in general, e.g. at {{Infobox station}} (where we sometimes used it for native names, like Chinese text of the romanised title) this has been labelled instead as |native_name=, to help prevent such param abuse. I think my personal rule for this field, in this infobox, would be (a) a bunch of RS confirming the term is in common usage and (b) ideally showing said usage has been sustained over a period of time. And ideally keep the values to a minimum imo, 2-3 values max in most cases. ProcrastinatingReader (talk) 01:43, 14 September 2020 (UTC)

New parameter

Please add the new parameter, |raised=, because the parameter shall be used for the place where the person was raised, and put it under |birth_place= label. Thanks. St3095 ^(?) 08:15, 13 September 2020 (UTC)

Please get consensus for that proposed change before requesting it. Nikkimaria (talk) 14:05, 13 September 2020 (UTC)

@Nikkimaria: How to get consensus? St3095 ^(?) 17:05, 13 September 2020 (UTC)

You would need an RFC. Given that the discussion above closed fairly recently I'd suggest waiting a while, unless you feel you have strong arguments that were not considered in that conversation. Nikkimaria (talk) 18:02, 13 September 2020 (UTC)

Here is a link to the conversation that Nikkimaria is referring to Template talk:Infobox person#Home town field. MarnetteD|Talk 16:39, 14 September 2020 (UTC)

Oppose this parameter. It has the same trivia problems as the "residence" and "home town" parameters did. Considering how families tend to move in this day and age the potential for infobox bloat is also a problem. The info is better handled by prose in the body of the article. MarnetteD|Talk 16:37, 14 September 2020 (UTC)

@MarnetteD: I support as per Template talk:Infobox person#Oppose removal. St3095 ^(?) 05:56, 15 September 2020 (UTC)

Oppose as well. Define "raised". It is possible to be born in one place, grow and become cognisant in another, enter puberty in another place, then live to adulthood in another. Who's going to decide where that person was "raised"? And, I'd imagine that a person would have different perspectives on where they were raised, depending on who they were talking to and what story they were telling. Cyphoidbomb (talk) 18:36, 14 September 2020 (UTC)

Add alias parameter |army_brat= but multiplex it with up to 15 occurrences: |army_brat1=, |army_brat2=, ... |army_brat15=, to handle the case of military families that moved around a lot so that they were raised all over the place. Just kidding. Oppose. Mathglot (talk) 10:13, 15 September 2020 (UTC)

Sorry to pile on, but oppose per MarnetteD's argument. Kaldari (talk) 03:03, 22 October 2020 (UTC)

RFC: Should mother and father parameters be removed?

There are three template parameters that cover a subject's parentage: |mother=, |father= and |parents=. Should the mother and father parameters be removed and the content folded into |parents=? Cyphoidbomb (talk) 19:51, 23 September 2020 (UTC)

Previous discussion above: #Parent(s). {{u|Sdkb}} ^talk 20:08, 23 September 2020 (UTC)

Survey

• No: this would lose information for no gain. Simply using a Parents field would leave the reader guessing for values like Alex and Leslie Jones. I was mistaken about how the individual mother and father fields would be displayed. I think that it would be better to use Father and Mother labels in preference to parentheticals, but the template isn't set up to do that. --RexxS (talk) 02:00, 24 September 2020 (UTC)

  In those cases, couldn't that information just be added as a parenthetical? 207.161.86.162 (talk) 03:29, 24 September 2020 (UTC)

• Yes – Not a useful clarification in 99.99% of cases and has problematic implications as discussed at #Parent(s). 207.161.86.162 (talk) 03:29, 24 September 2020 (UTC)
• No: per reason by RexxS. CruzRamiss2002 (talk) 11:39, 24 September 2020 (UTC)

  If CruzRamiss2002 doesn't provide an updated argument, I'm going to propose that their !vote be ignored, since they were !voting based on RexxS's argument, and RexxS was mistaken about how the parameters resolved. Cyphoidbomb (talk) 16:27, 8 October 2020 (UTC)

• No This is yet another solution in search of a problem. If you are going to use a parenthetical you might as well use the field that already exists. MarnetteD|Talk 15:44, 24 September 2020 (UTC)
• Yes – A singular parameter, |parents=, allows for the standard mother/father binary labels, but it also allows for all forms of gender expression and parental expression within that spectrum. So far, it seems the only benefit to the |mother=/|father= parameters is that by default they add a "(mother)" or "(father)" parenthetical after a name. If that's the primary reason for maintaining three parameters, that doesn't seem very strong position to me. Clear instructions will remedy most Alex/Leslie confusion, except for the segment of the population who aren't reading template instructions anyway, but those people may not even know there are mother and father parameters. Quoting RexxS in a section above, "Not every factoid is important enough to justify a separate field in an infobox" so it's odd to me to see an argument for having multiple parameters for the same factoid. Oh, and there's no loss of information, since we would ostensibly have bots parse the mother/father parameters and format that content into |parents=. Cyphoidbomb (talk) 16:58, 24 September 2020 (UTC)
• No per MarnetteD, not worth changing; no real problem here. MB 04:14, 25 September 2020 (UTC)
• Yes no reason to have three parameters when one can do the job. --Khajidha (talk) 16:19, 25 September 2020 (UTC)
• Yes per Cyphoidbomb. Z1720 (talk) 22:23, 29 September 2020 (UTC)
• Preliminary oppose per my comments above. I cannot see the benefit, but I can see that this would cause a large-scale nightmare in terms of infobox maintenance. It's a generally irreversible change, so once it inevitably does cause issues, we cannot really track them and I doubt anyone will be bothered to put in the effort to fix it. I don't see having to specify mother/father status textually as being an improvement - it will definitely cause general inconsistencies, which are not ones desired by article editors themselves. ProcrastinatingReader (talk) 19:22, 8 October 2020 (UTC)
• Neutral: I decided to withdraw my "no" vote and change into "neutral" vote because I sightly agree with Cyphoidbomb. But in my opinion, there should be a Template:Parents that simply like this: {{Parents|Father=Name of Father|Mother=Name of Mother}}, this is to avoid the usage of the "< br >" code, and this can be used exclusively on the |parents= parameter. CruzRamiss2002 (talk) 09:42, 9 October 2020 (UTC)
• Yes per Cyphoidbomb. Kaldari (talk) 03:02, 22 October 2020 (UTC)
• No All fields serve a purpose right now. The father and mother fields provide more error-proof way to identify them as typos in the relationship can be quickly identified. They also provide explicit form of the data in case the display of the form changes in the future to display these relationships explicitly. Removing them will make future changes to the infobox harder in this area as the data of the explicit relationship will need to be extracted from the parents field. On the other hand, the parents field is important when gender data are not available, when the relationship (mother or father) is not known, or in case parents were a LGBT couple. Knowledge Contributor0 (talk) 01:27, 25 October 2020 (UTC)

Discussion

Rather than have threaded discussion in the Survey section, I'll start a discussion section here. My stance is to provide the maximum flexibility for editors, which ensuring the maximum information for editors in the restricted space available in an infobox. If an editor wants to include both notable parents in a Parents field, they should be able to, but we still need the flexibility to identify the mother and father without cramming parenthetical disambiguators into the right-hand column.

Sadly, the template won't deliver this

Father	Alex Featherstonehaugh-Jones
Mother	Leslie Featherstonehaugh-Jones

even though I think it would be better than

Parents	Alex Featherstonehaugh-Jones (father) Leslie Featherstonehaugh-Jones (mother)

Nevertheless Parents is slightly better when the father and mother are obvious. For Joe Pritchett:

Parents	Jay Pritchett Gloria Delgado-Pritchett

No amount of bot-parsing will keep the information about Alex and Leslie if the bot throws away the distinction between father and mother. If the bot adds the parenthetical {father) and (mother) in every case, we end up with masses of unneeded disambiguation. If you think that the bot can tell when to add the parentheticals, I'd love to see the algorithm it would use.

Of course, we need the flexibility of Parents for same-sex couples. For Lily Tucker-Pritchett:

Parents	Cameron Tucker Mitchell Pritchett

I would prefer the compactness of a single field where both parents are notable and distinguishable; otherwise having the flexibility to use Father or Mother or both remains too useful to throw away for no good reason. --RexxS (talk) 18:25, 24 September 2020 (UTC)

Hi Rexx, a few thoughts: "but we still need the flexibility to identify the mother and father without cramming parenthetical disambiguators into the right-hand column." If I type |father = Max Mustermann into the infobox, on the published page the infobox resolves "Parent(s): Max Mustermann (father)" (colon added for clarity). Same with the mother parameter and for both together. So am I misinterpreting your argument, because (respectfully) it sounds like you are under the impression the infobox resolves "Father: Max Mustermann"? Otherwise, I'm not sure what you mean about not wanting to cram parentheticals on the right, since they're already there. As for the algorithm stuff, hey, I won't pretend to know anything about regex, but would it really be hard to teach a bot to look for |father = Max Mustermann and |mother = Erika Mustermann and convert that to |parents = Erika Mustermann (mother) <br /> Max Mustermann (father)? It looks to me like the template already has this coding built in. Cyphoidbomb (talk) 16:10, 25 September 2020 (UTC)

I fail to see the problem you or anyone has with the second example. I find the parentheticals much better looking than having an inconsistency of some boxes having separate mother and father fields and some having a single parents field.--Khajidha (talk) 16:18, 25 September 2020 (UTC)

Especially when the second example appears to be the actual page output. See Dakota Johnson. Cyphoidbomb (talk) 16:23, 25 September 2020 (UTC)

@Cyphoidbomb: that's my mistake. I was under the impression that the infobox displayed the labels Father and Mother when the corresponding parameters were present and the parent parameter was absent. I'm scared to check who wrote the code for label57 and data57 in case it was me! Just apply a small trout and ignore my objection. --RexxS (talk) 23:31, 25 September 2020 (UTC)

@RexxS: I appreciate your adjustment, thank you. Any way you might change your !vote above? I'm also concerned that if CruzRamiss2002 !voted in objection based on your objection, does their objection still stand, or the opinions of others who might not have known about how the parameter resolves on the page. I'm also wondering if I should clarify that in the RFC question. Regards, Cyphoidbomb (talk) 02:48, 26 September 2020 (UTC)

@Cyphoidbomb: Of course, and I've tried to revise my examples in the discussion to reflect the reality of the infobox. I still think that the individual labels are more compact that displaying parentheticals, but if the template doesn't do that, there's no point in me advocating for it. Cheers --RexxS (talk) 23:10, 26 September 2020 (UTC)

I am still confused here. Cyphoidbomb, the template currently shows this:

John Doe Parents Daddy (father) Mommy (mother)

when used with |father=Daddy and |mother=Mommy. Are you proposing that these two parameters be removed, and to achieve the same effect |parents={{ubl|Daddy (father)|Mommy (mother)}} be used? Or that the (father) (mother) labels be scrapped and instead |parents={{ubl|Daddy|Mommy}} be used? Or something completely different? ProcrastinatingReader (talk) 23:51, 26 September 2020 (UTC)

@ProcrastinatingReader: Sorry for the delay in responding. We currently have three parameters for the same content: |mother=, |father= and |parents=. I am proposing that we deprecate |mother= and |father= and use |parents= instead. And yes, our instructions will have to change to make it clear that when we propagate this field, we should add "(mother)", "(father)" or other relevant labels as parentheticals. Cyphoidbomb (talk) 16:22, 8 October 2020 (UTC)

Cyphoidbomb, hmm okay, so everything I said above in my summary is correct? If so, what's the goal here? Wikipedia, naturally, has some "quality assurance" issues at times. One of these is that infoboxes are wildly misused. If there's any doubt in that statement, see this, this and the 12k pages in Category:Pages using infobox person with unknown parameters (give or take wrappers). The first link will show how nonsensical some of these params are - some are just blatantly made up. Just to convert the parameters we're talking ~10k bot edits. And so initially everything will be fine. But it won't take long until people are making up names and we've got various inconsistencies in how mother and father are output visually. A good infobox is one that cannot be misused; this makes it easier to misuse with no seeming benefit? ProcrastinatingReader (talk) 19:18, 8 October 2020 (UTC)

@ProcrastinatingReader: The goal is to reduce three existing parameters to one. I would think that would be a popular and useful suggestion, since we typically don't like to have multiple parameters for the same content. The |parents= parameter is also more flexible, as it allows for non-binary gender labels and non-traditional family structures. For instance, if an article subject had two notable same-sex parents, we couldn't use |father= twice. There should be no substantive increase in future misuse, since the |parents= parameter already exists, and can already be misused. If anything, we would be reducing misuse by removing two parameters. As for the bots, I'm sure there are bots that do regular maintenance, and this could be piggy-backed on those bots' workloads. Cyphoidbomb (talk) 20:06, 8 October 2020 (UTC)

|parents= can already be used now for non-binary gender labels. The reality is that most notable biographies have binary parents, however. Especially since most notable biographies aren't of currently alive young people, where I suspect the labels are more common. In this substantial majority, asking editors to fill in |parents= correctly (with the brackets and all) is too much of an ask. The difference now is that the template is taking care of formatting behind the scenes when used with either of the specific parameters. This change doesn't achieve much other than removing the work the template does behind the scenes, requiring local articles to do it instead, and thus introducing unnecessary variance. Since |parents= already exists, where it would be preferred, I just cannot see what possible benefit this could have. ProcrastinatingReader (talk) 20:40, 8 October 2020 (UTC)

Your argument seems to pre-suppose that ignorant editors know to use |mother= and |father=, but not |parents=, which is a stretch of the imagination. Anyhow, since I can't sway your opinion, I'll put you in the column of people who prefers three parameters for data that could be included in one parameter. Cyphoidbomb (talk) 21:06, 8 October 2020 (UTC)

It's not at all unusual for biographies from well before the current era to include something other than 1 mother and 1 father - plenty of cases of adoption, stepparents, etc. Nikkimaria (talk) 21:08, 8 October 2020 (UTC)

Unusual, no. Relative minority, yes. And in any case a significant number defaulting to infobox built-in formatting. The usage of the gendered parent params makes up around 35-40% of total usage of parent-related params, which is significant. It's not that they will be too incompetent to use it, it's that they will structure mother and father differently when there is no need to do so. Perhaps (mom) (dad), (mam), (MOTHER), and this is just my less creative ideas. Template params tend to be far more creative. I can be swayed, although it's probably not worth the effort compared to just getting other votes, but I just cannot see the purpose of removing two params in favour of a third that already exists. It's a destructive change, by definition, so there must be a problem being solved to make it a good idea. What problem is being solved here? ProcrastinatingReader (talk) 23:55, 8 October 2020 (UTC)

I also don't like the idea that the "sex of the parent is usually obvious so we shouldn't have to put (father) or (mother)". 1) Lots of names are used for both men and women. I have often been surprised by the sex of a person that I thought I knew based on their name, 2) names from non-English speaking areas may not be obvious to native English speakers, 3) names in English may not be obvious to non-native speakers.--Khajidha (talk) 14:57, 30 September 2020 (UTC) Please solve this with wikidata? Mysteriumen•♪Ⓜ ^•♪talk _{♪• look} 01:33, 25 October 2020 (UTC)

Subtemplate "Infobox person/Internet info" proposed for deletion

A subtemplate of this Infobox person template, {{Infobox person/Internet info}}, has been nominated for deletion. Feedback is welcome at the deletion discussion. – Jonesey95 (talk) 03:33, 16 October 2020 (UTC)

Line break

Is it possible to introduce line breaks in the labels Notable work or Notable credit(s), so the entire text of the infobox isn't pushed too far right (as in Sulla)? Avis11 (talk) 17:36, 21 October 2020 (UTC)

RFC: Consensus for including astrological sign

Interested to know people's thoughts on including a field with the subject's astrological sign. This could be easily generated from existing birth date data, and I feel would be an interesting addition to the infobox. Orangeisacop (talk) 19:29, 21 October 2020 (UTC)

I removed the RfC tag since there's been no preliminary discussion on this. Also, it doesn't stand a snowball's chance in hell of being supported. See e.g. this image, which should explain the basics. –Deacon Vorbis (carbon • videos) 19:42, 21 October 2020 (UTC)

Oh goodness no. I'm tempted to {{atop}} this thread, but it might be fun to see what others have to say. – Jonesey95 (talk) 19:51, 21 October 2020 (UTC)

please no - one of the perennial arguments to not have any infobox is that it attracts trivia, which this would be. --Gerda Arendt (talk) 21:06, 21 October 2020 (UTC)

20 mule team no As Carl Sagan said "the specific gravity of the obstetrician has more to do with your birth than the arrangement of the stars as seen from earth." Add to this the fact that there is more than one zodiac so edit warring and/or infobox bloat would also be a problem. MarnetteD|Talk 21:51, 21 October 2020 (UTC)

I'm sure astrological sign is a lot more relevant to most people's lives than half the crap that gets put in people's infoboxes. Nonetheless, I can't support adding more parameters to this already-crufty infobox template. Kaldari (talk) 03:00, 22 October 2020 (UTC)

RFC: New parameter

Last month, I requested new parameter named |raised= on #Home town field. The new parameter shall be used for the place where the person was raised (and put it under |birth_place=). However, Nikkimaria told me get consensus.

The next day, MarnetteD moved my request from #Edit request to #New parameter (then "New field") and finally she opposed the parameter, then I replied her to support per #Oppose removal by ProcrastinatingReader. It means the result of the discussion on the section will not add "raised" parameter. Is it so? -St3095 ^(?) 15:46, 24 October 2020 (UTC)

To clarify a) You had posted your request to an already existing thread which was both confusing and likely to be missed since that thread was almost finished. b) I moved your request to a separate thread to avoid the problems already mentioned. c) As it was not a proper edit request (the same thing applies to this thread) I renamed it. and d) I am a man. MarnetteD|Talk 16:04, 24 October 2020 (UTC)

(after ec) At the moment, you do not have consensus for your proposed field addition, correct. If you'd like to start an RfC to attempt to get consensus as I indicated you should, I would suggest you review the instructions for RfCs, as what you've posted here is more of a process question than an actual RfC. What you would need to post instead is a neutral question regarding your proposal, and then you could post a support vote indicating why you believe this field should be added. Nikkimaria (talk) 16:06, 24 October 2020 (UTC)

Parameter conflict

With |relations= and |relatives=value nothing is displayed and there is no warning message. If both have a value, one is displayed. Frietjes? MB 20:52, 24 October 2020 (UTC)