This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

FYI

 – Pointer to relevant discussion elsewhere.

Please see WT:Manual of Style/Infoboxes#RfC on birthplace, nationality, and citizenship parameters with matching values, an RfC opened after initial discussion fizzled out with too few participants. This is about ((Infobox person)) and various derived/related templates.  — SMcCandlish ☏ ¢ 😼  13:43, 2 January 2020 (UTC)

((Tfm/dated|page=Infobox person|otherpage=Infobox Native American leader|link=Wikipedia:Templates for discussion/Log/2020 March 19#Template:Infobox person|bigbox=((#invoke:Noinclude|noinclude|text=yes)))) — Preceding unsigned comment added by PPEMES (talk • contribs) 12:23, 19 March 2020 (UTC)

 Added * Pppery * _{it has begun...} 03:13, 20 March 2020 (UTC)

I was reading a biography today, of https://en.wikipedia.org/wiki/John_Hawkes_(actor). On his page, it lists a birth date of 1959-09-11, but an age of 60 (not 61). Those two are inconsistent on today's date. Therefore, this feels like it must be a template bug somehow (or MediaWiki bug, perhaps).

I have no idea whether this affects all uses of the template or is somehow specific to this one page, or to some class of pages that use the template with some other pattern. I copy the actual Infobox as it appears right now below here.

John Hawkes
Hawkes in 2009
Born	John Marvin Perkins (1959-09-11) September 11, 1959 (age 65) Alexandria, Minnesota, U.S.
Alma mater	St. Cloud State University
Occupation	Actor
Years active	1984–present

Memories of lost time (talk) 02:42, 19 March 2020 (UTC)

Memories of lost time. The age is correct. He does not turn 61 until Sept. 11, 2020 which is 6 months from now. MarnetteD|Talk 02:47, 19 March 2020 (UTC)

MarnetteD has answered this but, while it's not relevant for this issue, I will mention that the age shown was calculated the last time the page was purged. That means it is quite common to see an age that, for example, says 60 when the person turned 61 a couple of days ago. The solution is to purge the page. Johnuniq (talk) 03:57, 19 March 2020 (UTC)

Oops, right. Glitch in my brain last night. It is indeed not Sept 2020 yet. Ignore thread. Memories of lost time (talk) 14:46, 19 March 2020 (UTC)

No worries Memories of lost time sometimes things just look wrong. If I look at the word orange to long my brain goes "that can't be right" :-P MarnetteD|Talk 04:17, 20 March 2020 (UTC)

I have just started making edits for Wikipedia, so pardon me if I'm asking this on the wrong page. I'm struggling with the infoboxes. One page I was working on was for an athlete. The infobox for athletes seems to have some odd restrictions. I was using the Carl Lewis page for my model, and it was notable to me that the Children tag did not appear in the published infobox--even though someone had entered this information for Carl Lewis. While I understand that it's not necessarily appropriate to name a living person's non-celebrity or not-personally-distinguished children, or to use anything but a simple number in this field, there are certainly sports dynasties where this information would be relevent. It seemed odd and tone deaf that children should be excluded as a recognised parameter for athletes. Also--why do athlete's names appear ABOVE the infobox rather than inside as they do for the rest of individuals? What's special or different about athletes in this regard?
And speaking of tone deaf, I was working on an artist's page, and the infobox I was using did not include a parameter for acknowledging anything other than a spouse. The particular artist I was working on, Leon Polk Smith, was a man of a very particular time and place. His New York Times obituary from 1996 noted that he was survived by his long-time companion. That long-time companion was Smith's life-partner of 45 years. Is there some historically appropriate alternative that could be supplied here? I wrote life-partner instead of companion for Smith because companion was used at the time as a euphemism to protect people from the supposedly offensive/unthinkable idea of homosexuality, and therefore I think has offensive connotations in this context. Thanks, Sicklemoon (talk) 14:21, 21 March 2020 (UTC)

@Sicklemoon: Infoboxes are not meant to be a comprehensive database of all information about the subject, but a brief, easily readable summary. Thus, when deciding which fields to include in an infobox, infobox editors have to balance the need to cover key facts and the need to prevent infoboxes from becoming so bloated that they no longer serve their intended purpose. In addition to life-partner, infobox person also does not have fields for friends, rivals, personal idols, or pastors, all of which are often more significant to an individual than any of their life-partners. Your specific concerns about athlete infoboxes sound legitimate to me, though I don't know much about that particular field of Wikipedia, and could be brought up at either Template talk:Infobox sportsperson or Wikipedia talk:WikiProject Sports; the former would be more direct but I think you're more likely to get a response at the latter.--Martin IIIa (talk) 16:56, 21 March 2020 (UTC)

I experimented and looked at a number of other pages. Picasso's infobox listed his partners, Dora Maar and others. I imagine that that field was not originally intended for that purpose--it has a business sound to me! But I'll go with it. Thank you for the response! Sicklemoon (talk) 19:52, 21 March 2020 (UTC)

@Sicklemoon: Your imagination deceives you. As far back as 2010, the |partner= parameter was immediately below the |spouse= parameter with the note Use same format as spouse. The note was expanded in April 2010 to read "For unmarried life partners (of any gender or sexual preference), not business partners. Use same format as spouse." It was never intended for business partners. --RexxS (talk) 19:42, 31 March 2020 (UTC)

Well, fine. Either my imagination or my failure to be able to locate the note line for the infobox templates that I was looking at. For latecomers to Wikipedia editing, there are bound to be misunderstandings, based on the sheer volume of work that has been done by prior editors.

That said, I've read a fair amount here about tone and respect. I think you could usefully remove the first four words in your comment. Sicklemoon (talk) 13:31, 1 April 2020 (UTC)

I searched the Talk archives to become familiar with the issue of naming children in the Infobox. My interest stems from a recent change to Fred Trump, in which "non-notable" children were removed from the infobox. Here's my take: Naming only "notable" children in a Person Infobox (or any other infobox used for a biographical article) is seriously misleading, because it gives the impression that they are the person's only children. The main text of the Fred Trump article (which I'm using as a stand-in example article for all biographies) does list all the children by name, which seems to significantly weaken, probably overturn, the argument that privacy should be protected by not naming non-notable children in the Infobox. Obviously, the infobox is highly visible, so one might argue that privacy is somewhat protected by excluding non-notables from the box, while nevertheless including all the names in the main text. That argument, however, fails to remedy what I regard as the real problem: misleading the reader regarding the subject's children. In my opinion, excluding non-notable names from an Infobox is the worst of the four options, which are: 1) number of children only, without names; 2) names of all children; 3) names of only "notable" children; 4) no mention at all of children in the infobox.

My bias is towards inclusion of encyclopedic information, which I believe applies to names of all children, whether living or not. Privacy is important, but naming children does not seem to me to be on par with true privacy violations, such as, for example, false accusations of crime/misconduct/misbehavior, or the like. And I'll repeat: the Fred Trump article does give the names of all the children, so a partial and therefore misleading list in the Infobox is, I believe, a disservice to readers and to the encyclopedia's aspiration to a reputation for reliability.

The instructions in this template (and by extension any template used in a biographical article) should be modified to state that in any biographical article, whether BLP or strictly historical, it is acceptable to do any of three of the four options I listed above: all names; number only; no names--but it is not acceptable to give a partial list of names, which leaves a false impression. Comments please. DonFB (talk) 05:11, 5 April 2020 (UTC)

I have noticed some articles which use the line "x, including John · Jane" (x being the number of children). I think this works best because it doesn't mislead about how many children the subject has and doesn't clutter the infobox with names of non-notable people. In the Fred Trump example I would recommend something like "5, including Maryanne · Donald". Editing with Eric (talk) 07:53, 5 April 2020 (UTC)

@DonFB: I disagree strongly with your proposal. An infobox's purpose is to summarise key facts about its subject. The names of a person's children is not a key fact about them, and the names of children are omitted by default. Of course, if one or more of their children is notable enough in their own right to have a Wikipedia article, then there is a good argument to include a link to their article, so those names (article titles) will probably be included in the parent's infobox. We have a convention that the number of children is acceptable to be included, so we avoid the misleading effect that worries you in the way that Editing with Eric explains: use 5 including ((hlist|[[Maryanne Trump Barry|Maryanne]]|[[Donald Trump|Donald]])). --RexxS (talk) 18:58, 5 April 2020 (UTC)

Thanks for excellent replies, and I agree. Will apply to the article (and others I might encounter). DonFB (talk) 02:31, 6 April 2020 (UTC)

Additionally, I have made two small edits to the Template to give explicit clarifying guidance, based on the suggestions in this conversation. DonFB (talk) 04:34, 6 April 2020 (UTC)

I've noticed for a long time (just never brought it up) that this infobox doesn't have the parameter to add a person's place of residence. For instance, Brent Butt lives in Vancouver, British Columbia. It would be good to be able to put that in the infobox. Mr. C.C.^{Hey yo!}_{I didn't do it!} 07:38, 29 March 2020 (UTC)

Please see Template talk:Infobox person/Archive 34#Residence parameter. MarnetteD|Talk 08:20, 29 March 2020 (UTC)

@MarnetteD: If I'm understanding correctly, a consensus was never reached thus this parameter was never added. The discussion was hard to follow, but I got the vibe that some people didn't understand that the point of this parameter is to put where they currently reside. Mr. C.C.^{Hey yo!}_{I didn't do it!} 16:38, 31 March 2020 (UTC)

No. There was overwhelming consensus to remove |residence=. Read the consensus summary at the top of that discussion. It reads There is consensus to remove the residence parameter. (typo fixed and formatting modified slightly). – Jonesey95 (talk) 16:41, 31 March 2020 (UTC)

Jonesey95 is correct Fishhead2100. The field was part of the infobox for several years. It no longer is. MarnetteD|Talk 17:49, 31 March 2020 (UTC)

@Jonesey95: I misread that consensus. It should have been left apart of it. But such as it is. Mr. C.C.^{Hey yo!}_{I didn't do it!} 04:41, 1 April 2020 (UTC)

I would support adding a parameter like that.Dormsrubi (talk) 06:20, 9 April 2020 (UTC)

I suspect you'd need to open an WP:RFC if you have a significant interest in establishing a new consensus. DonIago (talk) 19:58, 9 April 2020 (UTC)

Curious as to why the weight parameters are depreciated and height is not. One article I've been doing edits to, they have done modeling, so I was adding those things to the infobox. Makes no sense that height parameters are fine but not weight. Mr. C.C.^{Hey yo!}_{I didn't do it!} 05:34, 12 April 2020 (UTC)

I did not see any discussion about this but searching the archive found November 2019. The height of an adult is reasonably fixed but the weight often varies week-by-week. I have seen attempts to "fix" the weight of an athlete by changing it a small amount and that always strikes me as pointless. Johnuniq (talk) 07:41, 12 April 2020 (UTC)

Just to let editors in here know that a discussion has been opened on WP:VPP in regards to net worth and death - Rich^T|C|E-Mail 22:30, 16 May 2020 (UTC)

Rich_Smith It looks unlikely that you will get support to remove "net worth". Therefore, please stop removing it from infoboxes, and restore it to any where you have taken it out. Edwardx (talk) 11:21, 17 May 2020 (UTC)

@Edwardx: I've replied to you on WP:VPP, no point in repeating it here - - Rich^T|C|E-Mail 13:19, 17 May 2020 (UTC)

The parameter |home_town= is presently documented as: "The place where the person was raised and matured, if different from birthplace." Yet this is pointless trivia in most cases, and the pointlessness of it is why we removed the |residence= parameter. I think we can solve all the related problems at once (i.e. this usually being trivia, while where someone lives now often is not trivia, nor is where they mostly resided during their period of notability) by redefining this parameter as: "If different from both birth place and death place, the place or places where the person lived long-term during their period of notability." That will a) get us a useful parameter that will resolve recurrent complaints about nowhere to put non-trivial residence; b) forestall including pointless childhood details in the infobox; and c) forestall recycling death place as well as birth place in multiple parameters. Besides, people have already been using the parameter this way, anyhow. The documentation should match practice and editorial needs, not try to dictate them.  — SMcCandlish ☏ ¢ 😼  21:07, 19 May 2020 (UTC)

Seems reasonable to me. I found 22,243 instances of |home_town= with non-blank values (hastemplate:"infobox person" insource:/| *home_town *= *[^|]/) and 108 instances of |home town= (hastemplate:"infobox person" insource:/| *home town *= *[^|]/) with non-blank values. Would we have to check them beforehand or just let the wiki-gnomes work through them if the guidance changes? --RexxS (talk) 21:27, 19 May 2020 (UTC)

There is certainly no need to remove the parameter from all instances which have it; we can just remove the use of this parameter from the template. If we want fo do it selectively, we need an organized list where users who help can mark which entries should keep the parameter. 80.230.239.165 (talk) 05:31, 22 May 2020 (UTC)

First of all, the infobox isn't accompanied by full sentences, so the meaning of any ambiguities cannot be addressed. Thus, the parameters must be structured, concise, unequivocal, and consistent. Speaking of which - the parameter children. Is it the number of children or the names of children? Or is it just a boolean asking if children exist? I have read the documentation which states,

"The number of children; only list names of independently notable or particularly relevant children."

This clearly isn't structured - packing two types of information into one. Neither is it unambiguous - people will be confused at first glance. Nor is it consistent, doesn't follow the rest of the parameter-value pairs to be simple and easily comprehensible. Hence, I propose the parameter children to be simply a number. Famous children can be put into relatives. I'mFeistyIncognito | Talk 19:42, 20 June 2020 (UTC)

That would seem to also be problematic since the same people would be reflected in more than one parameter. Nikkimaria (talk) 19:46, 20 June 2020 (UTC)

@Nikkimaria: I suggested to include the names of famous children only in relatives. The children will have only the number of children of the person. Therefore, the same people will not be repeated twice. The children parameter should be interpreted as number of children. I'm suggesting to change the meaning of the parameter itself, not just improve the explanation. I'mFeistyIncognito | Talk 21:07, 20 June 2020 (UTC)

I understand your proposal. You're suggesting that if John Doe has 3 children, one of whom is notable, then children=3 and relatives=Jane Doe (daughter) - in other words, Jane will be included in both parameters. Nikkimaria (talk) 21:46, 20 June 2020 (UTC)

I'mfeistyincognito, this topic has been discussed multiple times. Most recent discussion was started on 5 April 2020: Template talk:Infobox person/Archive 35#Children, revisited. The consensus was to use format 4 including ((hlist|[[Jane Doe|Jane]]|[[Joe Doe|Joe]])). Perhaps, the documentation could be made more clear. —⁠andrybak (talk) 20:01, 20 June 2020 (UTC)

@Andrybak: Yes, I am aware that this has been a bone of contention for long. While others have proposed to improve the documentation, I'm offering to shake up the structure itself.

4 including ((hlist|[[Jane Doe|Jane]]|[[Joe Doe|Joe]])) still contains two kinds of information - number of children and names of popular ones. While it could have been better to just include a list of all their names, like the documentation points out, we may not know some or all of their names, or could be against their privacy. So I recommend this -

((Infobox person
|children=4
|relatives=((hlist|[[Ben|Ben(Uncle)]]|[[May|May(Aunt)]]|[[Jane|Jane(child)]]|[[Joe|Joe(child)]]))
))

Rendered like -

Not only did we simplify the values for each parameter, we removed any previously discussed confusions as well. Also, we didn't repeat anything.

I'mFeistyIncognito | Talk 21:07, 20 June 2020 (UTC)

(Edit): I just happened to look at the WikiData page for a person Tom Hanks, and Tom Hanks on Wikipedia. Scroll down to children on both the pages and look at the difference. You can now tell which one of them is easy to read. Also, the proposed change comes with an added bonus - it makes it easier for tools migrating data from Wikipedia to Wikidata.

--I'mFeistyIncognito | Talk 21:21, 20 June 2020 (UTC)

How does it do that? Under the current scheme, you know that if someone is named in the children parameter, then they are almost certainly a child of the subject. Under your proposed scheme, you're increasing the potential pool of relationships covered by the relatives parameter. Nikkimaria (talk) 21:46, 20 June 2020 (UTC)

I think the OP perceives a problem that doesn't exist for most people. The current usage is flexible to allow for different circumstances. -- Michael Bednarek (talk) 03:01, 21 June 2020 (UTC)

This edit request to Template:Infobox person has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

NellyKapo (talk) 22:05, 21 June 2020 (UTC)I need to change the featured search image to from Specioza Kazibwe to the one of Ms Mbayo.

@NellyKapo: You should suggest that at Talk:Specioza Kazibwe. This is an unrelated page used for formatting across various articles. Ian.thomson (talk) 22:17, 21 June 2020 (UTC)

I would just like to ask if filling up and using the “education” part of this infobox is ok for those persons currently taking up their degrees or it can only be used if have already finished their degrees? Thanks! — Emperork (talk) 10:34, 19 June 2020 (UTC)

It is only for completed degrees. See WP:CRYSTAL. If it is notable that someone is enrolled at a university, you can put that in the body of the article with an in-line source. – Jonesey95 (talk) 13:17, 19 June 2020 (UTC)

Should we have two parts, if someone for example received a bachelor's degree at one university and a master's at another? ~EDDY ^{(talk/contribs)}~ 15:24, 20 June 2020 (UTC)

You can put more than one degree in the |education= parameter. See Henry Louis Gates Jr. for an example. – Jonesey95 (talk) 16:12, 20 June 2020 (UTC)

Thanks for answering Jonesey95! Cheers! — Emperork (talk) 02:38, 22 June 2020 (UTC)

This seems to have never been proposed, so here goes .... can we make it so that the infobox allows the option of listing a celebrity's spouse as husband or wife explicitly? I get that 95% of the time we know it's an opposite sex partner, but some foreign names are ambiguous, so it could save time if we knew up ahead of time who was who. Just a thought, —Soap— 15:23, 23 June 2020 (UTC)

The parameter is 'Spouse'. Which should only be filled by a name. What you seem to be suggesting would be further parameters that instead of 'spouse' it would say 'Wife: <name>' or 'Husband: <name>'. Alternatively 'Spouse: <name> (Wife/Husband)' which could be done by just inputting that now. I also had a look back through the archives and cant see it ever having been discussed anywhere either. All the discussions to do with the spouse parameter appear to be issues to do with multiples rather than what sex they are. My opinion: I feel it would be more trouble than its worth in the long term, spouse is sex & gender neutral so is unlikely to provoke heated discussion. If the spouse is notable in their own right, the blue link to their article will contain the relevant details. If they are not, it doesnt actually matter, and certainly in the case of living people, we would seek to minimise details about non-notable people anyway. Only in death does duty end (talk) 15:38, 23 June 2020 (UTC)

I don't think in 2020 we should be modifying templates to reinforce binary gender. As Only in death points out, the current parameter is sex & gender neutral and if a spouse's gender is of interest, their article or else the article listing them as someone's spouse will no doubt provide that info. —Joeyconnick (talk) 01:03, 1 July 2020 (UTC)

Why is birth_name being tagged an unknown parameter? Carl Francis (talk) 23:34, 24 July 2020 (UTC)

It is not, but if it is followed by forbidden invisible white-space characters, as in this version of Frederick Schrecker, the white-space characters will cause an error. I thought there were bots that cleaned up those characters, but they might not be able to find everything all of the time. – Jonesey95 (talk) 23:57, 24 July 2020 (UTC)

Anybody interested in helping to clarify the instructions at |death_cause=? They're a bit vague. A cause of death could be thought of a few different ways. James Dean's article is one of the examples in the template instructions, and "car crash" is listed, which is more about the circumstance of his death, than the actual cause, which, according to his death certificate under "Cause of death", was "broken neck". In contrast, John Lennon's cause of death on Wikipedia is "Gunshot wound", which is consistent with the cause of death on his death certificate, but doesn't describe the circumstance of his death, i.e. that he was "assassinated" or "murdered". Thus, the two examples seem inconsistent with one another. Thanks, Cyphoidbomb (talk) 20:02, 26 July 2020 (UTC)

Cyphoidbomb, I do wonder whether this should be split into two fields - cause (broken neck), and manner (car crash). Could well give undue weight to the death in the infobox, though. Darren-M talk 20:03, 26 July 2020 (UTC)

Cyphoidbomb, Darren-M, I feel inclined to agree that having two parameters seems clunky for an infobox. Also, I think we should note that the basis for this conversation on 'cause' and 'manner/circumstance' of death (I believe) arises from this source cited on cause of death. I don't think there is consensus amongst the editors of the cause of death wiki article for differentiating between those two criteria either, because list of causes of death by rate does list suicide as a cause of death. But coming back to that cited source, that's a US county government's recommendation to medical examiners so as to follow Washington state (of the US's) laws regarding how they classify deaths. How relevant can that be for other jurisdictions that don't follow those definitions and differentiate between 'cause' and 'manner' of death?

The cause of death article defines its subject as the "official determination of conditions resulting in a human's death." It seems to me that, for our purpose, a Wikipedia infobox's cause of death should mention the conditions of a person's death as reported in reliable sources. Since there aren't different parameters available for the cause and circumstance of death, I think we should assume that it is expected that we should conflate them both (or not) where required. The places where this is required is where reliable sources conflate the two when reporting a subject's death (as an example: Lennon was murdered by Chapman with a gun, or, James Dean died in a car crash). If reliable sources feel the need to conflate the medical cause of death and the legal (and also medical?) manner of death, when reporting on the conditions of a person's death—then that should be the clearest hint to us that we should do the same. —I'llbeyourbeach (talk) 20:58, 26 July 2020 (UTC)

@I'llbeyourbeach: In response to your impugning the source cited on Wikipedia's cause of death, I have added a reference at that page to a scholarly article published in the American Journal of Public Health in August 2017 and posted at the U.S. National Institutes of Health's National Library of Medicine digital repository PubMed Central. It states, Accurately classifying how someone died (by natural causes, accident, suicide, homicide, or an undetermined cause), called manner of death (MOD), is critical to public health. This generally accepted scientific nomenclature is not limited to any one state, county or municipality. I submit you would be hard put to find a jurisdiction in the United States that does not legally differentiate between cause of death (medical) and manner/method of death. NedFausa (talk) 22:08, 26 July 2020 (UTC)

@NedFausa:, oh I really don't have doubts about the importance of thorough classifications of death in relation to public health, just on the conciseness of Wikipedia infoboxes. —I'llbeyourbeach (talk) 15:52, 27 July 2020 (UTC)

Oh, this is interesting. The background for Cyphoidbomb's question is a discussion on the page Talk:Sushant Singh Rajput, who died of suicide by hanging (or asphyxiation). For most infoboxes with a suicide-related death cause the cause is given as "Suicide by [method]".

I also think a car crash is a reasonable cause of death in an encyclopedia, even if it's not medical terminology. A crash and a broken neck are both causes, but on slightly different levels. The level of car crash and "suicide by [method]" seems right for the infoboxes.

I do not have any suggestion at the moment on exactly how to formulate a policy, but I would aim for a slightly higher level cause than the medical analysis of what body part broke and how. Perhaps giving examples is a good way to start. We have a de facto consensus when it comes to suicides. I wonder what the precedents are when it comes to murders. It seems like a reasonable harmonization to me to have Lennon's death cause entry modified from "gunshot wound" to "murder by gunshot". -- St.nerol (talk) 21:04, 26 July 2020 (UTC)

I checked two similar prolific cases. John F. Kennedy, cause of death "Assassination (Gunshot wound)" and also Olof Palme, where the cause of death is given as "Assassination by gunshot". The wikilinks are as in the infoboxes. The last one seems ideal to me. ––St.nerol (talk) 21:56, 26 July 2020 (UTC)

The heading is Death_cause clarity but so far I don't see much clarity here. Editors seem determined to conflate cause of death and manner of death. Wikipedia has two standalone pages because those are distinctly different topics.

• Cause of death: In law, medicine, and statistics, cause of death is an official determination of conditions resulting in a human's death, which may be recorded on a death certificate. A cause of death is determined by a medical examiner. The cause of death is a specific disease or injury, in contrast to the manner of death which is a small number of categories like "natural", "accident", "suicide", and "homicide", which have different legal implications.
• Manner of death: In many legal jurisdictions, the manner of death is a determination, typically made by the coroner, medical examiner, police, or similar officials, and recorded as a vital statistic. Within the United States and the United Kingdom, a distinction is made between the cause of death (sometimes referred to as the "mechanism of death"), which is a specific disease or injury, versus manner of death, which is primarily a legal determination. Different categories are used in different jurisdictions, but manner of death determinations include everything from very broad categories like "natural" and "homicide" to specific manners like "traffic accident" or "attempted or self-induced abortion".

The fact that certain celebrity pages contain infoboxes where the death_cause parameter is mistakenly populated with manner of death does not justify Status quo stonewalling. We need separate parameters—death_cause and death_manner—and lucidity in the Explanation column as to what each term means and how to use it. NedFausa (talk) 15:54, 27 July 2020 (UTC)

Not every factoid is important enough to justify a separate field in an infobox. WP:INFOBOXPURPOSE states When considering any aspect of infobox design, keep in mind the purpose of an infobox: to summarize (and not supplant) key facts that appear in the article ... The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance. What makes cause/manner of death so important to justify two separate fields? --RexxS (talk) 18:09, 27 July 2020 (UTC)

I'm not advocating verbose content in infoboxes. To the contrary, one or two words will often suffice. In the case of John Lennon, for example, death_cause parameter would say Gunshot wound and death_manner would say Assassination. Each of these is concise, to the point, and most importantly offers the reader an immediate understanding of why and how the person died. NedFausa (talk) 18:49, 27 July 2020 (UTC)

Agree summarizing cause & manner in one field is sufficient. An infobox should be concise. MB 19:07, 27 July 2020 (UTC)

@NedFausa: The cause/manner distinction is not unproblematic. The Cause of death article has some issues, and a dig in the history reveals some contentiousness. According to a WHO definition that was cited prior to a copyright-related major revert in August 2016, the cause of death is "all those diseases, morbid conditions or injuries which either resulted in or contributed to death and the circumstances of the accident or violence which produced any such injuries" (emphasis mine). St.nerol (talk) 20:43, 27 July 2020 (UTC)

• Comment: I still don't feel like I understand how we're supposed to use this field, which is why I was hoping the community could figure out a way to clarify the instructions. Different people seem to have different perspectives on what a cause of death is, and I believe the example articles listed have death causes that are not consistent with one another, so I'm not really sure what, if any consensus there is about this parameter, nor how anybody could enforce a particular version. Without that clarity, I would argue that if NedFausa wanted to list "asphyxia due to suicide by hanging", that would be as valid as anybody else's interpretation of what sort of content should be put there. Cyphoidbomb (talk) 03:08, 2 August 2020 (UTC)

What do you think of the edits that I've made to the Infobox person/sandbox template and should they be be implemented in the main Infobox person template? -- PK2 (talk) 11:18, 1 August 2020 (UTC)

PK2, please consider explaining the goal of these changes. Why these changes are needed? —⁠andrybak (talk) 11:41, 1 August 2020 (UTC)

PK2, you have made a ton of changes to the sandbox, including adding parameters for custom styling that are probably undesirable. Please list the changes that you have made, and add some test cases to the testcases page that demonstrate the differences. – Jonesey95 (talk) 13:13, 1 August 2020 (UTC)

Jonesey95, Ive added the basestyle, headerstyle, headercolor, header1color, header2color, textcolor, text1color and text2color, like in ((Infobox sportsperson)), and I've also removed native_name from the 'subheader' parameter and I've placed it under the 'above' parameter, like in ((Infobox musical artist)). The reason I've made those edits to the template sandbox is because I want to make the template look nicer in the future, and also to make it easier for other 'people and person' infobox templates to call this one in the future and to manage and to reduce overhead maintenance. -- PK2 (talk) 11:25, 10 August 2020 (UTC)

Again, please add some test cases to demonstrate your proposed functionality. At the moment I'm not seeing a significant benefit, and the header1 addition seems particularly unnecessary. Nikkimaria (talk) 13:03, 10 August 2020 (UTC)

Here are some of the following test cases:

Old versus new (for regular people)

Old	New
Carl Peter Thunberg Born (1743-11-11)11 November 1743 Jönköping, Sweden Died 8 August 1828(1828-08-08) (aged 84) Thunaberg, Uppland, Sweden Nationality Swedish Other names Carl Pehr Thunberg Carl Per Thunberg Thunb. Occupation Naturalist	Carl Peter Thunberg Born (1743-11-11)11 November 1743 Jönköping, Sweden Died 8 August 1828(1828-08-08) (aged 84) Thunaberg, Uppland, Sweden Nationality Swedish Other names Carl Pehr Thunberg Carl Per Thunberg Thunb. Occupation Naturalist

Old versus new (for musicians)

Old

New

honorific_prefix name native_name honorific_suffix caption Background information Birth name birth_name Also known as alias Born birth_date birth_place Origin origin Died death_date death_place Genres genre genre genre Occupations occupation occupation occupation Instruments instrument instrument instrument Years active years_active years_active years_active Labels label label label Members current_members Past members past_members Website website module module2 module3

honorific_prefix name honorific_suffix native_name caption Born birth_name birth_date birth_place Died death_date death_place Other names alias Occupations occupation occupation occupation Years active years_active years_active years_active module module2 module3 Website website

Old versus new (for sportspeople)

Old	New
Andre Agassi Personal information Born (1970-04-29) April 29, 1970 (age 54) Las Vegas, Nevada, United States Height 1.80 m (5 ft 11 in) Weight 80 kg (180 lb) Spouse Steffi Graf Sport Country  United States Turned pro 1986 Retired September 3, 2006	Andre Agassi Born (1970-04-29) April 29, 1970 (age 54) Las Vegas, Nevada, United States Height 1.80 m (5 ft 11 in) Spouse Steffi Graf Sports career Weight 80 kg (180 lb) Country  United States Turned pro 1986 Retired September 3, 2006

Old versus new (for sportspeople)

Old

New

Person Name native_name Musical career caption Background information Birth name birth_name Also known as alias Born birth_date birth_place Origin origin Died death_date death_place Genres genre genre genre Occupations occupation occupation occupation Instruments instrument instrument instrument Years active years_active years_active years_active Labels label label label Members current_members Past members past_members Website website module module2 module3

Person Name native_name Musical career caption Background information Birth name birth_name Also known as alias Born birth_date birth_place Origin origin Died death_date death_place Genres genre genre genre Occupations occupation occupation occupation Instruments instrument instrument instrument Years active years_active years_active years_active Labels label label label Members current_members Past members past_members Website website module module2 module3

-- PK2 (talk) 12:15, 11 August 2020 (UTC)

Yep, IMO not improvements. All that's changing in the default case (standard template only) is an extraneous header. Nikkimaria (talk) 12:24, 11 August 2020 (UTC)

Comments:

• Nirvana is not a person, so "Personal information" is not valid.
• The Nirvana box has a new, unneeded blank space before the native_name.
• The Andre Agassi box has removed the coloring for the "Sport" header and added a second, incorrect "Personal information" header.

I recommend copying these test cases to the testcases page and creating additional cases (or modifying these) to show the advantages of the new features that have been added. – Jonesey95 (talk) 14:56, 11 August 2020 (UTC)

Infoboxes are implemented as tables of data. All tables need captions. It is a retrograde step to change captions into header cells. --RexxS (talk) 18:43, 11 August 2020 (UTC)

I've just added these test cases to the testcases page and it should be under the section 'Standard vs sandboxed template testcases. -- PK2 (talk) 00:17, 12 August 2020 (UTC)

1. @Jonesey95: How do I make it possible to automatically change "Personal information" to "Background information" when the background parameter is set 'group_or_band', 'classical_ensemble', or 'temporary' in the new ((Infobox musical artist))? template

2. I've tried my hardest to place the native_name parameter under the 'above' parameter in the sandbox after removing it from the 'subheader' parameter, like in ((Infobox musical artist)), but unfortunately, there's a blank line after it, and not before it. How do I get rid of that extra blank line?

3. How do I get rid of the second "Personal information" header and correctly style the 'title' parameter? The coloured "Sport" header can be added back in the new ((Infobox sportsperson)) template.

4. @RexxS: Which captions were I trying to change into header cells? -- PK2 (talk) 11:42, 13 August 2020 (UTC)

@PK2: examine the Andre Agassi infoboxes. The old one has a caption, "Andre Agassi", but the new one has no caption and you've placed "Andre Agassi" in a false header cell. Please see MOS:DTAB. --RexxS (talk) 21:25, 13 August 2020 (UTC)

Re item 2, I have fixed the blank line in the sandbox. As for the other items, I think you changed too much of the code and now the sandbox is broken. Try starting from the live, working template and making small changes, checking the testcases page after each change. Make sure that there is at least one test case that actually tests the new code that you are implementing. – Jonesey95 (talk) 22:23, 13 August 2020 (UTC)

This edit request to Template:Infobox person has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I an just trying to add one more parameter that hold the religious status of a person. Thanks. A. Shohag (ping_me||Talk) 07:25, 19 August 2020 (UTC)

 Not done for now: please establish a consensus for this alteration before using the ((edit template-protected)) template. And please use the sandbox rather then put the code here. Nardog (talk) 09:45, 19 August 2020 (UTC)

Template:Infobox person includes a box near the top saying "Please note that in 2016, the |religion= and |ethnicity= parameters were removed...". Please see that for more information. In short, religion was purposefully removed four years ago. Johnuniq (talk) 09:48, 19 August 2020 (UTC)

Could someone please revert the unexplained edit that removed the tidy spacing[1] without any explanation and for no apparent reason? This template serves as the example for many articles. Great big walls of text, or markup without any spacing makes it more difficult to avoid mistakes and check markup. Wiki markup is part of a tradition of user friendly human readable markup, so please revert this unfortunate change that only makes things more difficult to read and use. Clarity and readability is more important than saving a few characters, Wikipedia is not short of space. -- 109.77.214.47 (talk) 23:44, 18 August 2020 (UTC)

That edit removed the space after the pipe (|) in the infobox example: | name... → |name.... I don't have any facts at hand but I suspect that removing that space is becoming standard. Some older pages also have a space before the pipe and that is definitely being removed. Johnuniq (talk) 00:03, 19 August 2020 (UTC)

I really hope that isn't the case, it a terrible idea to make that the standard, people make enough accidental mistakes in markup, there's no benefit in making markup any harder to read.

If there is a consensus to do it that way the editor definitely should have been able to follow the very simple basic rules and good courtesy of providing a relevant edit summary and pointed to a relevant policy or discussion. Please restore the WP:STATUSQUO until there is at least an edit summary, and ideally an explanation or indication of some larger policy to explain the change.

If there is a change of policy it seems strange that it would have been done by a manual edit and not a mass change by bot across many templates. I would also have expected Template:Infobox to have been changed but it (mostly) does use tidy spacing. -- 109.77.214.47 (talk) 00:19, 19 August 2020 (UTC)

It is neither a standard nor a policy. For named parameters, the presence or absence of whitespace (spaces, newlines, tabs) after the pipe, the parameter name, the equals sign and the parameter value has no bearing upon how the template is parsed. So ((template|para=value)) is exactly equivalent to ((template | para = value )). Whitespace is only significant (i) within parameter names; (ii) within parameter values; and (iii) before, within and after positional (unnamed) parameters. --Redrose64 🌹 (talk) 20:19, 19 August 2020 (UTC)

Butwhitespaceissignificantforreadability. --RexxS (talk) 22:18, 19 August 2020 (UTC)

User:Redrose64 I didn't mean to suggest there was any technical need to include spaces, only that it was desirable for readability. Also there isn't any good reason to do otherwise. It doesn't surprise me that there's no policy to avoid untidy layout OnlyaPERLprogrammercouldl0ve$h1tawallofGARBAtext but originally wiki markup was desirable exactly because it wasn't as overcomplicated and unpleasant to read as XML.

Thanks for restoring the spacing [2] User:Jonesey95 (if you even saw this request). -- 109.78.209.8 (talk) 23:24, 19 August 2020 (UTC)

Several fields, including "Spouse(s)", "Parent(s)", and "Criminal charge(s)" display with a (s) at the end. Looking to an ideal, we shouldn't be doing this, since if someone has multiple spouses, the label should read "Spouses", and if they have only one, it should just read "Spouse". That would be a lot cleaner. Technically, would there be any way to implement this? ((u|Sdkb)) ^talk 06:32, 24 August 2020 (UTC)

Probably not worth the effort, which is why we uses the "( s)" format. BilCat (talk) 07:16, 24 August 2020 (UTC)

BilCat, fair enough, although it depends on how much effort it'd actually take, and I'm not equipped to answer that. Given the massive number of transclusions of this infobox, though, if it's feasible, it could fall into the very-small-changes-at-very-large-scale-becomes-important category. ((u|Sdkb)) ^talk 07:34, 24 August 2020 (UTC)

It is possible, but it requires a lot of gnome work. See ((Infobox settlement)) and its tracking categories with the phrase "possible... list" in them, then look in the code to see how they are applied. Then look at this edit to Aldridge, Alabama, which removed the tracking category and changed "(s)" to "s". I haven't dug up the template talk archives to figure out when and how we made the change (try looking in the November 2018‎ archives), but you shouldn't have much trouble finding the discussion. – Jonesey95 (talk) 16:03, 24 August 2020 (UTC)

I've done this before, but I can't remember which infobox it was on. The simplest idea is use two parameters: |spouse= and |spouses=, and then set label54 to "Spouses" if the |spouses= parameter is used and to "Spouse" otherwise. Then you let editors fix the inconsistencies. (a bit like the fix I did for Organisation / Organization, which seems to work).

Is it worth the effort to try to use programming to ascertain whether the field contains multiple values or just one spouse? You could look for any of , ; | <br in the parameter value and assume that means there are multiple values (punctuation, templated lists, <br>). What do folks think? --RexxS (talk) 16:33, 24 August 2020 (UTC)

@RexxS: Either of those would be great, although automatic detection would obviously be most ideal. But the best option is the one that we actually go through with, so if there are roadblocks to automatic detection (for instance, commas from ", Jr.") then just stick with introducing an option (so long as it's future-compatible for when we decide to make it automatic someday). ((u|Sdkb)) ^talk 18:22, 24 August 2020 (UTC)

(edit conflict) Tests:

• ((#invoke:String|match|s= [[Elizabeth Taylor]] |pattern= [,;<] |nomatch= No match )) → No match
• ((#invoke:String|match|s= [[Sybil Williams]], [[Elizabeth Taylor]] |pattern= [,;<] |nomatch= No match )) → ,
• ((#invoke:String|match|s= ((ubl | [[Sybil Williams]] | [[Elizabeth Taylor]] )) |pattern= [,;<] |nomatch= No match )) → <
• ((#invoke:String|match|s= [[Sybil Williams]] <br> [[Elizabeth Taylor]] |pattern= [,;<] |nomatch= No match )) → <

I think that the following might do the trick:

• |label54 = ((#if:((#invoke:String|match|s= (({spouse|))}(({spouses))} |pattern= [,;<] |nomatch= )) |Spouses |Spouse))

Needs some testcases and might need a broader pattern if I've missed any variations. By the way, it will screw up if a single spouse contains the <small>...</small> tag, but that's deserved as there should be no small tags in infoboxes anyway. --RexxS (talk) 18:32, 24 August 2020 (UTC)

@Sdkb: the ", Jr" is indeed a stumbling block. I could write a module to detect a list and then skip exceptions like ", Jr", etc. but that's a bit more work when we could probably get away with:

• |label54 = ((#if:(({spouses|))} |Spouses |Spouse))

Perhaps that's best for the moment. We also really need to deprecate the |spouse(s)= parameter. --RexxS (talk) 18:41, 24 August 2020 (UTC)

Why reinvent the wheel? ((Infobox settlement)) uses ((Detect singular)), and it seems to work pretty well. – Jonesey95 (talk) 20:59, 24 August 2020 (UTC)

I'd expect there will be errors with catching <br> - I've seen many articles where that's been used to force dates of marriage to a following line. Nikkimaria (talk) 21:37, 24 August 2020 (UTC)

@Jonesey95: The wheel keeps getting reinvented when it's a well-kept secret. Unfortunately ((Detect singular)) suffers from similar problems:

• ((Detect singular|[[Joffre]])) → 1
• ((Detect singular|[[Joffre, First of his name]])) → 1
• ((Detect singular|[[Frank Sinatra, Jr]])) → 1
• ((Detect singular|[[Dave Nellist]])) → 1

Too many exceptions for template syntax to handle for my taste. Back to the simple idea, methinks. --RexxS (talk) 22:10, 24 August 2020 (UTC)

currently, module:infobox only understands |child=yes for the embedding parameter, but, this infobox turns off |native_name= for any non-blank value for |child=. to trigger the bug, try using ((infobox person|child=foobar|name=This appears|native_name=This does not appear)). for consistency, I think we should change

| subheader  = ((#if:(({child|(({embed|))))))|<!--empty when this infobox is embedded-->|((#if:(({native_name|))}|<div class="nickname" ((#if:(({native_name_lang|))}|lang="(({native_name_lang))}"))>(({native_name))}</div>)) ))

to

| subheader  = ((#switch:(({child|(({embed|))))))|yes=<!--empty when this infobox is embedded-->|#default=((#if:(({native_name|))}|<div class="nickname" ((#if:(({native_name_lang|))}|lang="(({native_name_lang))}"))>(({native_name))}</div>)) ))

if there are no objections, I (or someone else) will make it so. Frietjes (talk) 16:14, 24 August 2020 (UTC)

now implemented. Frietjes (talk) 18:58, 30 August 2020 (UTC)

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)

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.

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)

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)

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)

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)

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)

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)

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)

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

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

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)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your 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)

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)

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

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

even though I think it would be better than

Nevertheless Parents is slightly better when the father and mother are obvious. For Joe 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:

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:

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)

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)

No Too much information in the infobox makes it harder for readers to quickly skim and find what they are looking for. That's why we need to be careful about what we add to the infobox and include only what would be of interest to the majority of the readers which I don't think the astrological sign is. Knowledge Contributor0 (talk) 01:37, 25 October 2020 (UTC)

No Anyone interested in that knows straight away from the birth date, there is no need to tell them. Also no anyway. --Mirokado (talk)

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)

MB, I added some generic tracking Category:Pages using infobox person with conflicting parameters. please let me know if there are any problems. I already had to scale it back in a couple places due to false positives, and found/fixed a bug in ((infobox spy)). there are likely more issues. it will complain even if both parameters are blank, but, due to the nested parameters in the infobox, the complaining is probably a good thing since an editor filling in one of the subordinate blank parameters may be surprised when nothing appears in the infobox. Frietjes (talk) 15:11, 26 October 2020 (UTC)

((rfc|bio))

Last month, I requested new parameter named |raised= (to be added into ((Infobox person))) on #Home town field. The new parameter shall be used for the place where the person was raised (and put it under |birth_place= label). (For example, Justin Bieber was born in London, Ontario and raised in Stratford, Ontario.) 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 he opposed the parameter, then I replied her him 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) Fixed erroneous gender pronouns. Sorry. St3095 ^(?) 14:25, 25 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. and 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)

@Nikkimaria: what is "ec"? Edit comment? Edit count? St3095 ^(?) 05:23, 25 October 2020 (UTC)

H:EC. Nikkimaria (talk) 13:04, 25 October 2020 (UTC)

@Nikkimaria: thanks. St3095 ^(?) 14:25, 25 October 2020 (UTC)

No If the home town is the same as the place of birth, it won't add new information. If the home town is different from the place of birth, there will be lot of controversy as to how many years should be spent in a town to be considered home town. Since in many instances the infobox is used in living persons articles, it will be better to avoid controversial information. Furthermore, I don't see the home town information of much value to the reader to be added in the infobox. I can't see this as the first piece of information the readers will look for when they open the article, so putting it in the infobox will be misplacing. Knowledge Contributor0 (talk) 01:58, 25 October 2020 (UTC)

Oppose - This seems very similar to the "home town" parameter that was just removed. I think it will cause problems due to ambiguous definitions. I also don't think it's especially useful information to include in the infobox. Kaldari (talk) 21:46, 26 October 2020 (UTC)

A report at WP:VPT by Cyphoidbomb points out that this edit displayed Religion in the infobox at Dhruv Rathee. That is because the infobox used is ((Infobox YouTube personality)) which uses |label11= to display Religion rather than a |religion= parameter. Any thoughts on how to track down other similar occurrences? An insource search would probably find most of them. Johnuniq (talk) 05:31, 1 November 2020 (UTC)

A suitable search might be this. There are several hits but the only dubious one appears to be ((Infobox YouTube personality)) (and its sandbox). Johnuniq (talk) 06:54, 1 November 2020 (UTC)

I just removed four or five |religion= parameters from person infoboxes. ((Infobox character)) strikes me as an edge case. Here are a couple of searches: living people with religion parameter (note that some are religious figures like clergy); template pages with infobox and religion parameter (note that the actual template page does not appear in the listing); possibly better search for infoboxes using religion. – Jonesey95 (talk) 14:50, 1 November 2020 (UTC)

@Johnuniq and Jonesey95: I appreciate you all picking up the ball on this. Thank you. Cyphoidbomb (talk) 18:50, 1 November 2020 (UTC)

Can we change party and political party to political affiliation or affiliation? I think it's a good choice espacially for Independent politicians and (affiliation: Independent) seems better fitting than (party: Independent) --Maudslayer (talk) 21:41, 3 November 2020 (UTC)

The parameter |notable_works= currently outputs the label Notable work, which is confusing. The documentation suggests this field is for listing significant individual works, not the range of work, i.e. the wider area of activity, in which the subject is notable for (which should probably be listed in |known_for=). The label being "Notable work" suggests the second meaning (an uncountable noun) rather than the first. This was the result of an effort back in 2015 to get rid of the (s) from what was previously Notable work(s), but why not have the label as Notable works, which would make the meaning clearer? The majority of uses will probably include multiple works (as suggested by the parameter name), and having a single item under a plural label is still less awkward than having a label that suggests a different meaning. --Paul_012 (talk) 23:01, 4 December 2020 (UTC)

Pinging editors from previous discussion Gerda Arendt, Musdan77, DePiep and Pigsonthewing, as well as Netoholic and Nikkimaria from an earlier discussion in 2014. --Paul_012 (talk) 11:29, 5 December 2020 (UTC)

I never fill that parameter. I use |list_of_works=, which results in the same output. See Beethoven. I am no friend of "Notable" in the output for both, and think just "Work" should be fine. For Max Reger, it's |works=, resulting in output "Works" which perhaps would better be "Work". Unless we change something, if you want "Works", take that parameter. --Gerda Arendt (talk) 12:14, 5 December 2020 (UTC)

Keep the "notable" in there, no harm done. Prevents infobox creeping into full article reproduction. -DePiep (talk) 11:49, 5 December 2020 (UTC)

What do you think of Castor et Pollux? - We could still have "notable" in a parameter, but why in the output? All mentioned in an infobox should be "notable", but I see no need to say "Notable occupation" and "Notable partner".--Gerda Arendt (talk) 12:14, 5 December 2020 (UTC)

Castor et Pollux: example of bad. No infobox-discipline. Note that, if you have to add a 'show/hide' button to an infobox, you are having too much info in there (hide=contradicting the infobox principle of summary). If that whole list is 'notable', it should be mentioned as a whole (see Beethoven). For example, Shakespeare, Bach and Picasso could have their Revolution In Their Field as "Known for", not individual works. Yes "notable" could be left out of the visual text (becasue infobox does notable info ony, in principle), but editors and readers alike are helped (guided) by it. -DePiep (talk) 12:56, 5 December 2020 (UTC)

Oops, Castor et Pollux does not have this infobox. Only a topical sidebar on the composer (which, interestingly, is not present in Rameau?!; not any infobox in there at all). So the question does not apply to Castor et Pollux. -DePiep (talk) 13:00, 5 December 2020 (UTC)

Hmm. I asked mostly because |notable_works= is listed as a suggested default parameter in the documentation, and wasn't really questioning what kind of inclusion would be appropriate. Come to think of it, though, in most cases this field seems quite redundant with |known_for=. We could say Charles Darwin was known for conceiving the theory of evolution, with notable works including The Origin of Species, but do we need to mention both separately? (The current article actually lists the works in the |known_for= field.) --Paul_012 (talk) 16:31, 6 December 2020 (UTC)

About the plural "s": add parameter |notable_work=. Then editors can handle.

Yes "Notable works" and "Known for" are partially redundant, but not completely similar. To me, the subtle difference between a work and, say, a new idea is very useful. Darwin having both: fine. Is there any example of a Reader being misguided by current options? -DePiep (talk) 17:39, 6 December 2020 (UTC)

Are you suggesting |notable_work= as another alias, or that the choice of singular/plural parameter affect the output? (I've seen the latter distinction used in other infoboxes, but thought that there was preference not to do so here.) Regarding the second point, I wouldn't say it's misguiding, but the inconsistency in the way they are used can be confusing (as in the Darwin example, though that's probably because the ((Infobox scientist)) wrapper doesn't include the notable_works parameter). Probably more a problem for editors than readers. --Paul_012 (talk) 08:41, 7 December 2020 (UTC)

Yes I meant to say: when |notable_work= is used, the label says "... work" in singular, and the plural shows plural.

Isn't that inconsistency a problem that can be solved by editing? I'd be very happy to pick an appropriate one (or both, as Darwin might have). -DePiep (talk) 09:43, 7 December 2020 (UTC)

Using different parameters could also solve the issue for parent(s), spouse(s), partner(s) etc., which have previously been raised. The inconsistency issue probably isn't that big a problem, I guess. Yes it can be solved by editing (and modification of some wrapper templates). --Paul_012 (talk) 09:52, 7 December 2020 (UTC)

This edit request by an editor with a conflict of interest was declined.

This is a continuation from #New parameter and its RFC.
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. (For example, Justin Bieber was born in London, Ontario and raised in Stratford, Ontario.)
I support per #Oppose removal by ProcrastinatingReader. Thanks. St3095 ^(?) 09:17, 16 December 2020 (UTC)

 Declined Please listen to the responses from the previous discussions you linked.—Bagumba (talk) 09:40, 16 December 2020 (UTC)

The documentation currently states that |employer= can be used for "employer(s)", indicating presumably that it's for all major employers over someone's life, not just their current employer (which would be a bit of recentism). However, the parameter is only set up to display the singular "employer", not the plural "employers". Would it be okay for me to enable the plural label for anyone who uses |employers= rather than |employer=, as done in the sandbox here? (For anyone who wants to discuss plurality more, see a draft RfC here and the associated talk page. The trickiness there applies more to instances where there's a more complicated status quo than here.) ((u|Sdkb)) ^talk 00:26, 19 December 2020 (UTC)

No opinion about the plural, but before anything is changed, I'd like to get more of an explanation from the community about what this parameter is intended to be used for. I've seen it used in very weird ways, like for actors, listing networks or studios they've worked for, or jobs they had before they became notable. Cyphoidbomb (talk) 00:37, 19 December 2020 (UTC)