Jump to content

Template talk:Infobox person: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
→‎Proposal to remove salary parameter: Removed BRAINULATOR9s support as this had long closed before their support (sorry Brainulator) / closed "RFC"
Dormsrubi (talk | contribs)
Line 273: Line 273:
* '''No''' A signature is a major aspect of any person. It helps to give a rounded view of the subject in question. It doesn't detract from an article whatsoever. ~ [[User:HAL333|<span style="background:gold; color:white; padding:2px;">HAL</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px;">333</span>]] 22:31, 24 January 2020 (UTC)
* '''No''' A signature is a major aspect of any person. It helps to give a rounded view of the subject in question. It doesn't detract from an article whatsoever. ~ [[User:HAL333|<span style="background:gold; color:white; padding:2px;">HAL</span>]][[User talk:HAL333|<span style="background:black; color:white; padding:2px;">333</span>]] 22:31, 24 January 2020 (UTC)
* '''Yes''' as it's purely decorative, Unless the persons writing or signature is notable in some way than I see no reason why it should be included in an infobox. –[[User:Davey2010|<span style="color:blue;">'''Davey'''</span><span style="color:orange;">'''2010'''</span>]]<sup>[[User talk:Davey2010|<span style="color:navy;">'''Talk'''</span>]]</sup> 22:44, 24 January 2020 (UTC)
* '''Yes''' as it's purely decorative, Unless the persons writing or signature is notable in some way than I see no reason why it should be included in an infobox. –[[User:Davey2010|<span style="color:blue;">'''Davey'''</span><span style="color:orange;">'''2010'''</span>]]<sup>[[User talk:Davey2010|<span style="color:navy;">'''Talk'''</span>]]</sup> 22:44, 24 January 2020 (UTC)
*'''No''' This makes no sense[[User:Dormsrubi|Dormsrubi]] ([[User talk:Dormsrubi|talk]]) 03:49, 25 January 2020 (UTC)

Revision as of 03:49, 25 January 2020

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

Proposed removal of Weight parameter

I'm proposing we remove the Weight parameter from this infobox. Weight is almost never an encyclopedic, it can rarely be properly sourced to reliable sources, is often the source of fierce and pointless edit wars (see the recent edit history of Brendan Schaub) and, worst of all, it changes frequently during the subject's life. Which weight is this parameter meant to record? Because it's meaning isn't specified, it is almost impossible to populate this parameter in a verifiable way. I think it causes plenty of trouble without adding value and should be removed. It appears it was added here during the infobox actor merge, and looking through the talk page archive it's addition was never discussed and has always been controversial. Thoughts? The Mirror Cracked (talk) 21:31, 31 August 2019 (UTC)[reply]

The Mirror Cracked You forgot to sign your post :-) I would support the removal of the field. I don't know that I've ever seen a number in the field reliably sourced and, as you so rightly point out, it changes during a persons lifetime. MarnetteD|Talk 21:28, 31 August 2019 (UTC)[reply]
Support - I can't imagine a single case where weight should be in the infobox. Even in cases where a person's weight is notable (such as people who are remarkably skinny or remarkably fat), the article can state their body type or particular weight points that were notable for them. 李艾连 (talk) 16:16, 11 November 2019 (UTC)[reply]
This is uncontroversial so I'm going to move it forward to an edit request. Sandbox with proposed edit here: https://en.wikipedia.org/w/index.php?title=Template:Infobox_person/sandbox&oldid=925720681 李艾连 (talk) 22:24, 11 November 2019 (UTC)[reply]
 Done despite limited discussion here. Weight parameters appear to be used in about 1,300 articles. In case this is controversial after the fact, I did not renumber the labels. Please adjust the template's documentation to match this change. – Jonesey95 (talk) 00:34, 12 November 2019 (UTC)[reply]
Post-support The weight of athletes in certain sports is notable, but their specific infoboxes can handle that. With any other person, the info becomes dated, if it was even notable to begin with.—Bagumba (talk) 04:07, 27 December 2019 (UTC)[reply]
^.^b Brilliant, that kills the weight also on old permalinks. –84.46.52.55 (talk) 09:17, 29 December 2019 (UTC)[reply]
I also want to to give my support to this move. Having this parameter gave our articles undue weight. –MJLTalk 16:31, 29 December 2019 (UTC)[reply]

Residence parameter

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


The |residence= parameter of the {{Infobox person}} instructions say: "Location(s) where the person notably resides/resided, if different from birthplace." Assuming all information is sourced, how should this parameter correctly be used:

  • Option A - Multiple locations the subject has resided. (Judi Dench, John Waters)
  • Option B - Wherever the subject currently lives. (Amitabh Bachchan, Theresa May)
  • Option C - Only if the subject is notable for living in that location or those locations. (Angelyne, Snooki)
  • Option D - Some other idea, please explain.

Thanks, Cyphoidbomb (talk) 06:26, 5 November 2019 (UTC)[reply]

  • Option D Remove the parameter altogether.
  • Option E Some other idea, please explain.
Since nobody has commented yet, I'm adding a new Option D.—Bagumba (talk) 11:11, 5 November 2019 (UTC)[reply]

Survey

  • Option D The few people for which this parameter might truly be relevant is outweighed by the copycat nature it gets added for ones that don't. (Bill Gates in Medina, Washington?) Per MOS:IBXPURPOSE: The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance. The nature to which they might strongly be tied to a particular location outside of their birthplace should be obvious in the body, if not the lead.—Bagumba (talk) 11:11, 5 November 2019 (UTC)[reply]
  • Option D Bagumba is correct. The field is rarely sourced in my experience - nor does it get updated when people move. MarnetteD|Talk 19:21, 5 November 2019 (UTC)[reply]
  • Option D I can see ways in which this could inadvertently promote publicising information about LPs which should not be on Wikipedia (eg actual addresses).--Goldsztajn (talk) 22:21, 5 November 2019 (UTC)[reply]
  • Option D Remove the parameter. Per Bagumba et al. - Ryk72 talk 04:50, 6 November 2019 (UTC)[reply]
  • Yep, option D. If there's ever a case where it's somehow really, really important to indicate something like this (e.g. someone very notable for two different things in two different places), then it can be done on a case-by-case basis with a custom parameter.  — SMcCandlish ¢ 😼  10:33, 6 November 2019 (UTC)[reply]
  • Option C + option Wikidata It is not possible to understand a biography without having location context. The infobox should contain this location information. The Wikipedia default outsider of infoboxes is to present information which is notable. In infoboxes, for most people there will be one location affiliation, for some people 2-3, and rarely more for anyone before the modern age. For the modern age we should say something but it would be hard to come up with a rule quickly. Wikidata is the right place to sort most of this. Blue Rasberry (talk) 16:38, 15 November 2019 (UTC)[reply]
    • Option D, delete I changed my mind. In cases where this is most relevant, the circumstances are too often too difficult to explain as statements of fact in an infobox. If someone's residence is near their place of birth, then that is the historic norm. Historically if someone traveled, they had an unusual reason, and that is too much for an infobox. Nowadays when people change national residence it may not have particular meaning. This is not an easy field to interpret. Let's keep place of birth and remove this field. The place for this information is in the prose article and in Wikidata, but not the infobox. Blue Rasberry (talk) 13:53, 18 November 2019 (UTC)[reply]
  • Option D per Bagumba. Nikkimaria (talk) 02:27, 16 November 2019 (UTC)[reply]
  • Option D per above. Levivich 04:50, 17 November 2019 (UTC)[reply]
  • D is for Delete per the above arguments. If a residence is notable it can always be outlined (and sourced) in prose. DonIago (talk) 04:54, 17 November 2019 (UTC)[reply]
  • Option D per others, as it have no value there. -BRAINULATOR9 (TALK) 22:27, 24 November 2019 (UTC)[reply]
  • Option A but if Option D is chosen by consensus, then I would ask that we ensure there are multiple "other" parameters which could be used for residence/birthplace/etc. and which allow us to set custom names for the parameters. Doug Mehus T·C 16:51, 26 November 2019 (UTC)[reply]
  • Option D because the majority of people adding this parameter to articles leave it unsourced. If somebody's residence is notable, it can be added and sourced to a personal life section. – DarkGlow (talk) 20:15, 4 December 2019 (UTC)[reply]

Discussion

  • Comment To get some idea of how and where the residence parameter is being used, I've added a tracking category to the template. See Category:Infobox person using residence. It will take several hours to populate properly, so it won't give a good estimate of how many articles have the parameter until tomorrow.
    Using an insource search (hastemplate:"infobox person" insource:/residence *= *[A-Za-z\[]/) shows 36,844 results, but it might have missed a few (like {{plainlist}}); there are at least 766 uses of the parameter with a blank value. --RexxS (talk) 23:43, 5 November 2019 (UTC)[reply]
Thanks, I checked some of these, and I was seeing that the place of birth was often near the residence. To me that is not the meaningful information I want in an infobox. Blue Rasberry (talk) 13:57, 18 November 2019 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Removal

As a first step I've commented out the parameter in the template and removed it as valid in the check. That leaves us with a temporary marker where the parameter was, just in case. At some future point that can safely be removed.

I think I've removed from the documentation all mentions of residence that need to be removed.

There are still over 38,000 pages in Category:Infobox person using residence, so there's some clean-up to do, but it's obviously not urgent. It will show up as an unknown parameter in preview mode, so it will eventually be eliminated, but if anybody wants to do a bot run, that would speed things up substantially. --RexxS (talk) 22:24, 25 December 2019 (UTC)[reply]

@RexxS: Is removal of dead code that doesn't affect the display considered a cosmetic change or a minor edit?—Bagumba (talk) 05:49, 26 December 2019 (UTC)[reply]
@Bagumba: It's the sort of change that should not be done alone – not because it's intrinsically "cosmetic" or "minor", but because it's not urgent. There's no good reason to hit the server job queue for so many pages just to remove a hidden comment, so it's best done later at the same time as a substantial edit. Hope that makes sense. --RexxS (talk) 17:20, 26 December 2019 (UTC)[reply]
That is a stupid bot job, nine characters residence vs. nine characters home_town. Or use {{{home_town|{{{residence}}}}}}, or any other recipe not ending up with thousands of mutilated BLPs. –84.46.52.176 (talk) 02:20, 27 December 2019 (UTC)[reply]
@RexxS: so they should all be removed (i.e. a simple find-and-replace removal of the residence parameter)? DannyS712 (talk) 02:44, 27 December 2019 (UTC)[reply]
It would be better to wait until the holiday season is over and people have had a chance to absorb the fact that residence no longer does anything other than show a warning in preview. Perhaps wait until 13 January 2020 to see if anyone raises a problem. I would hope that a bot can do something other than remove this parameter if it is going to edit over 38,000 articles. I think AWB has the ability to remove parameters as part of its general cleanup, and that might be better. Johnuniq (talk) 03:03, 27 December 2019 (UTC)[reply]
Just as a note re: removal, I do have a bot task that is approved for removing deprecated parameters in order to clear out categories. Primefac (talk) 16:23, 27 December 2019 (UTC)[reply]
I agree that there is no reason even to use a bot to remove these and clutter-up watchlists. They can be removed over time when other edits are made to the articles. I would use AWB to remove these eventually, but only if there are other non-cosmetic changes to the article. MB 05:08, 3 January 2020 (UTC)[reply]

There is still documentation in wrapper templates (e.g. {{infobox artist}} to update. Is anyone going to find all of these? MB 05:16, 3 January 2020 (UTC)[reply]

Should there be a discussion somewhere about removing |residence= from other infoboxes? I just ran across {{Infobox Twitch streamer}} and there are probably others. {{Infobox officeholder}} has it, but that is so common maybe it should have its own discussion. MB 21:53, 4 January 2020 (UTC)[reply]

I disagree with the idea of mutilating 38,000 BLPs, and let folks clean it up over the next decades as they see fit, because my suggestion to replace all "residence" by "home town" with a bot failed miserably in my 3rd manual attempt, a province is no town. –84.46.53.207 (talk) 18:39, 11 January 2020 (UTC)[reply]

Residence can not be assumed to be the same as a person's home town; in most cases, they are different. There's nothing really too harmful if the "residence" remains in the wikitext. It doesn't harm the reader.—Bagumba (talk) 19:23, 11 January 2020 (UTC)[reply]
Out of curiosity, what was the purpose of this RfC? I'd like to see where folks currently live, it is not necessarily a privacy issue (for comparison, we still have "height", but I killed it in one BLP on demand.) –84.46.53.207 (talk) 19:34, 11 January 2020 (UTC)[reply]
You can read my !vote above, along with everyone else's if you want to see more arguments. Regards.—Bagumba (talk) 19:40, 11 January 2020 (UTC)[reply]
Anon, circa early November 2019, an editor was adding this content en-masse to articles, typically unsourced, but also where there were questions as to whether or not the content was relevant, i.e. adding that content to an article about a person who was not notably from Town X. Does it matter to us that game developer Mohammad Alavi resides in Los Angeles? Or that Sir Charles Palmer resided at Wanlip Hall? The parameter documentation was not clear on its intended purpose, so I asked for clarification. Cyphoidbomb (talk) 20:16, 12 January 2020 (UTC)[reply]
Thanks for info, at least I know how to fix it in most cases, where home_town=… works. Checking that it's also sourced is a good idea. on Jimmy Dore I take "stated" as good enough. If you want that on more templates, {{infobox YouTube personality}} has a residence, just seen on Hannah Witton. –84.46.53.221 (talk) 04:24, 13 January 2020 (UTC)[reply]
@MrX: One disadvantage of closing RFCs, you need a plan how to implement it: Template:Infobox artist/doc has to be updated, it spooked me on Kent Tate. –84.46.53.221 (talk) 09:29, 15 January 2020 (UTC)[reply]

Let's not insult the natives (BLP)

Template:infobox officeholder does not show the string native_name if the native_name parameter is filled; instead it shows that native name in a similar fashion (centred, bold, large font) to the English transliteration, without telling the reader that it is a "native name" (the reader will presumably infer this without having to be told, as s/he also has to infer from the English transliteration of the name).

It seems to me that in Template:infobox person, writing the string native_name explicitly violates WP:BLP for many of our articles whose subjects are living people, for obvious reasons of colonial history and some of the connotations of "native" being pejorative. I propose that at least for the moment we make the minimal edit from:

 | label1     = Native name

to

 | label1     = 

In other words, we leave the label blank. Or we could use something like the officeholder code, if it applies without too much change:

 | subheaderstyle = font-size:125%; font-weight:bold;
 | subheader = {{#ifeq:{{lc:{{{embed}}}}}|yes||{{#if:{{{native_name|}}}|<div class="nickname" {{#if {{{native_name_lang|}}}|lang="{{{native_name_lang}}}"}}>{{{native_name}}}</div>}}}}

An example to check right now is Seham Sergiwa, a psychologist who happens to also be a member of parliament, so Infobox person is her main template, infobox officeholder is a module. She's hopefully still a living person, although chances are she was assassinated (see the article for details). Boud (talk) 22:44, 14 November 2019 (UTC)[reply]

The heading is informational. Rather than just displaying a string of characters in the infobox, we tell readers what that string of characters represents. You have not provided a reliable source for your implied claim that the phrase "native name" is pejorative. Since it is used tens of thousands of times in articles on Wikipedia, you might want to move this discussion to a more wide-ranging venue, like Wikipedia:Village pump (policy). – Jonesey95 (talk) 23:19, 14 November 2019 (UTC)[reply]
this was discussed for infobox islands and the result was to remove the label as suggested if |local_name= were used instead of |native_name=. Frietjes (talk) 15:31, 15 November 2019 (UTC)[reply]
Suggest to remove param Foreign names can already be in the lead sentence per MOS:FORLANG. However, this is English Wikipedia, so I do not see the need to also overload an infobox with this foreign name. Per MOS:IBXPURPOSE: The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance.Bagumba (talk) 05:24, 17 November 2019 (UTC)[reply]
Oppose the removal of the parameter. This is the English-language Wikipedia, but it's not the Wikipedia-only-for-English-readers-who-are-monolingual-and-monoscriptual. Some readers will know the original script and wish to see the name in that script. The case of Arabic names is an especially strong argument against this suggestion. Not only does Arabic in common written usage omit most vowels, but the pronunciation of some of the consonants varies across the Arabic-speaking world, and presumably within Arabic-speaking countries. Which makes it unsurprising that a person with a well-defined name in Arabic can easily have half-a-dozen different English/roman transliterations in English-language sources (and French/roman transliterations will tend to vary a bit too). There are also many readers in between, who know enough of a non-roman script to be able to search on it, without being fluent. It also seems a bit disrespectful to the subject of an article to suggest that only the English/roman version of his/her name is significant. Boud (talk) 20:03, 20 November 2019 (UTC)[reply]


Summary: The Village pump proposal got comments, overt support from several people, and only mild opposition.

Could someone with technical access please make the changes? Either my minimal edit (leave label1 blank) or a better formatted equivalent. Thanks. Boud (talk) 22:49, 10 December 2019 (UTC)[reply]

native_name pointer

This is just a pointer to Template_talk:Infobox_person#Let's_not_insult_the_natives_(BLP) above, which after giving plenty of time for discussion appears ready for someone with editing access to act on. Boud (talk) 22:51, 10 December 2019 (UTC)[reply]

Template-protected edit request on 14 December 2019

The minimal edit request is to change from:
| label1 = Native name
to
| label1 =
in order to avoid the risk of the label being perceived as insulting (colonial) (BLP issue) and/or because the rendered result looks better without the label.
For a more detailed discussion see Template_talk:Infobox_person#Let's_not_insult_the_natives_(BLP) and the discussion at village pump, which got comments, overt support from several people, and only mild opposition. One month is plenty of time for anyone to lodge serious objections if there were any. A more sophisticated, stylish way of implementing this BLP fix is possible too - I'm requesting a minimal version that is fairly sure to work. Boud (talk) 10:20, 14 December 2019 (UTC) (copyedit Boud (talk) 10:21, 14 December 2019 (UTC))[reply]

A centered subheader under the English name would be better than having right-adjusted data in the infobox table without a label.—Bagumba (talk) 11:03, 14 December 2019 (UTC)[reply]
No objections from me - but someone with editing rights needs to actually do one option or another... :). Boud (talk) 11:26, 14 December 2019 (UTC)[reply]
How would the centred subheader look if the infobox were used as a child of another infobox? Can we see sandbox and mockups, please, because templates with very high levels of transclusions shouldn't be updated until we're absolutely sure the change is correct. If any tweaks needs to be made, it's best they happen in the sandbox to avoid overloading the job queue. --RexxS (talk) 19:13, 14 December 2019 (UTC)[reply]
I tried Infobox person/sandbox in Seham Sergiwa and previewed based on the sandbox with these two edits by Galobtter. It looks fine to me. I tried Infobox person/sandbox on Abdalla Hamdok with a preview and it also looks OK to me. Boud (talk) 22:18, 14 December 2019 (UTC)[reply]
I'd suggest adding a testcase to Template:Infobox person/testcases as well, so this isnt broken in the future. Also, what does it look like when |honorific_suffix= is specified?—Bagumba (talk) 23:42, 14 December 2019 (UTC)[reply]
I added Sergiwa + Hamdok to the /testcases page - this is a good way of testing. I arbitrarily converted Hamdok into an Esquire, for the honorific_suffix. I guess if a suffix is needed, that should be OK. I also added a Hamdok copy with the |native_name_lang= missing; the rendered output looks the same to me, but the source html has lang="ar" missing. For the sake of readers for whom these hidden attributes are important, I guess a warning in red could be given when editing if |native_name_lang= is missing - or else robots could add those in later. Boud (talk) 00:03, 15 December 2019 (UTC)[reply]

information Administrator note I find there is consensus for this change. RexxS above questions how the change will look in child infoboxes, and I just wanted to confirm that this has been addressed. — Martin (MSGJ · talk) 10:31, 16 December 2019 (UTC)[reply]

@RexxS: Would the generic Infobox person ever be embedded into another (more specific) infobox?—Bagumba (talk) 10:36, 16 December 2019 (UTC)[reply]
Yes. Here is a list of 800+ articles that use Infobox person as a child infobox. Sheryl Crow, for example. – Jonesey95 (talk) 13:30, 16 December 2019 (UTC)[reply]
Interesting backdoor.—Bagumba (talk) 13:49, 16 December 2019 (UTC)[reply]
@Boud: can you do some tests with Sheryl and confirm that everything looks okay? — Martin (MSGJ · talk) 04:20, 17 December 2019 (UTC)[reply]
@MSGJ: - Template:Infobox_person/testcases#Sheryl_Crow_with_fictitious_japanese_native_name uses testcase table in the outer infobox, and looks fine, but I don't think that tests the potential flaw. Have a look instead at Template:Infobox_person/testcases#Sheryl_Crow_with_fictitious_japanese_native_name_in_inner_infobox and Template:Infobox_person/testcases#Buzz_Aldrin_with_fictitious_arabic_name. These both appear somewhat odd, because the native_names, which I have inserted into the inner infobox, appear mid-way along the main list of parameters. For these two insertions of a native_name to occur, the Sheryl Crow version would appear to a parameter at the same level as alma_mater; and the native_name in the Buzz Aldrin case is for an inner infobox of which the only original (native ;)) parameters are children, spouse, website, signature. If باسس الادرين really were a native_name for Aldrin's family, then this would make sense, and to me look OK, especially as the hypothetical editor of the wiki source would appear to see this as something more closely associated with Buzz Aldrin's family, and as a separate sub-group to his space career, rather than a native_name of Buzz Aldrin himself.
Template:Infobox_person/testcases#Abu_Bakr will have duplicates of the native name, but that in fact is already the case in Abu Bakr, where the version with the label "native_name" appears at the bottom of the box, and another copy is hacked into the name parameter using the br tag. So cases like this could be argued to already look a bit odd, and fixing cases like this by hand will help remove some cases of hacked name parameters, like this.
I checked a few others on the list like Boris Grebenshchikov and Hirokazu Tanaka; these have native_name in the outer infobox, so no problem is expected; Abdullah ibn Alawi al-Haddad uses {{Infobox religious biography}}, where native_name is already a subheader.
To summarise: there is at least one use of native_name in an inner infobox that is redundant with a hacked name parameter (Abu Bakr), but even without editing, it will still look OK, and with editing, it will be cleaner (no need for the Arabic version both at the top and the bottom); any other uses of native_name inside an inner infobox are likely to be rare, and if they exist (the Crow and Aldrin examples have artificially inserted native_names), would probably make sense with the new layout, and if not, would probably be noticed quickly and fixed. So no 100% guarantee of no complaints, but to me it looks reasonable to make the present /sandbox version live, unless someone can think of more tests to make. [The testcase table itself failed to be useful for these inner infoboxes - but that's a bug in testcase table, not a test of the sandbox version of Infobox person.] Boud (talk) 22:55, 17 December 2019 (UTC)[reply]
Not sure if it's technically possible, but native name should ideally be disabled if detectable as a child. Editors should keep it in the parent infobox paired with the English version of their name.—Bagumba (talk) 01:59, 18 December 2019 (UTC)[reply]
It's technically quite possible. Something like | data1 = {{#if:{{{child|}}}{{{embed|}}} || {{#if:{{{native_name|}}}|<div class="nickname" {{#if:{{{native_name_lang|}}}|lang="{{{native_name_lang}}}"}}>{{{native_name}}}</div>}} }} will suppress the field if the parameters |child= or |embed= have values – you could refine it by testing for the parameters having the value "yes", which Module:Infobox tests for. However, I'm not sure if that's always going to be a good idea, because it presupposes that the parent infobox processes the |native_name= parameter. As we don't know which parent infobox may be used (and that's open-ended), that presupposition may not always be true. --RexxS (talk) 03:11, 18 December 2019 (UTC)[reply]
I have deployed a version of the above test in the sandbox. If I am reading this discussion correctly, our goal is to display the person's name in their native language below the name they are usually known by in English. If this infobox is used as a child infobox, I do not think having the |native_name= parameter from Infobox person display anywhere within the rendered Infobox person template will be useful in achieving that goal. I welcome a test case that shows that I am incorrect, as I may be misunderstanding the goal, the technical function of the infobox, or both. – Jonesey95 (talk) 04:31, 18 December 2019 (UTC)[reply]
Yes. The testcases starting from Template:Infobox_person/testcases#Sheryl_Crow_with_fictitious_japanese_native_name_in_inner_infobox and below demonstrate that native name is not displayed when specified in a child. I'm satisfied.—Bagumba (talk) 05:38, 18 December 2019 (UTC)[reply]
I've added Template:Infobox_person/testcases#Lennon/Ono_devil's_advocate_case to test the current version by Jonesey95 at 04:26, 18 December 2019. In this hypothetical case, the editor decided that Yoko Ono's Japanese script name is vital to the article about John Lennon, so s/he inserted 小野洋子 into the inner infobox as native_name, along with spouse = Yoko Ono.
The result is that this gives a misleading result with the standard (existing) template: the reader gets the impression that 小野洋子 is Lennon's Japanese script name, unrelated to any spouse(s) he may or may not have. With our sandbox version, 小野洋子 disappears totally, so the reader is not misled. On the other hand, the reader is unaware of how to write Yoko Ono's name in Japanese. I don't think that this is a problem: the article is mainly about Lennon, not his best-known wife. If his wife is WP-notable, then she can have her native_name in the main infobox on her own article. In the spirit of not overloading the reader with too much info in infoboxes, this effective ignoring of native_name in inner infobox person infoboxes seems reasonable to me. The editor will be annoyed, but if this really is an exceptional case, then a hack using 'br' and including extra text in the spouse parameter will not be blocked by the template (it will be up to editors to discuss its exceptional justification).
Current status: all the test cases look OK to me. Boud (talk) 22:38, 18 December 2019 (UTC)[reply]

 Done. – Jonesey95 (talk) 04:57, 24 December 2019 (UTC)[reply]

Criminal charge(s)

Please change the label "Criminal charge" to "Criminal charge(s)" (or "Criminal charges") and the variable "Criminal_charge" to "Criminal_charges". This is necessary because criminals are often charged with multiple serious crimes. 12:22, 16 November 2019 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. Sceptre (talk) 07:04, 17 November 2019 (UTC)[reply]
Sceptre Do we actually need consensus to pluralize something already in the infobox that should have been pluralized to begin with? Also, WP:BOLD. - MrX 🖋 13:00, 17 November 2019 (UTC)[reply]
Why does this template need any criminal parameters at all? Seems like {{Infobox criminal}} would be used for most notable criminals. In the other rare cases when it passes BLP and UNDUE muster, the criminal template should just be embedded into this one.—Bagumba (talk) 07:35, 17 November 2019 (UTC)[reply]
Bagumba that's not really my concern, although it's probably because some people are known primarily for heinous crimes, and other are known for other things and less heinous crimes. It is in the infobox, so I just want it to be pluralized. - MrX 🖋 13:00, 17 November 2019 (UTC)[reply]

RfC: Should the Criminal charge label be changed to Criminal charge(s)?

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


Should the label "Criminal charge" be changed to "Criminal charge(s)" (or "Criminal charges") and should the parameter variable "Criminal_charge" be changed to "Criminal_charges"? - MrX 🖋 13:08, 17 November 2019 (UTC)[reply]

  • Yes - This is necessary because criminals are often charged with multiple serious crimes. template:Infobox criminal is not appropriate for people who have not committed heinous crimes. See for example, Roger Stone. - MrX 🖋 13:08, 17 November 2019 (UTC)[reply]
  • Embed Infobox criminal into Inbox person using |module=, and have it be consistent with {{Infobox criminal}}. Ibx criminal currently shows "Criminal charge". Not saying that is right, but we should not reinvent the wheel, whatever direction we decide to take. Embedding the template ensures a solution only needs to be implemented once, and not have to propagated to multiple other templates. It ensures consistency.—Bagumba (talk) 09:06, 18 November 2019 (UTC)[reply]
    Yes, I agree that we should implement the change in one place and propagate it to the others. - MrX 🖋 13:27, 18 November 2019 (UTC)[reply]
  • Yes – usually there's more than one. Levivich 18:33, 20 November 2019 (UTC)[reply]
  • Per WP:TESTCASES, I suggest that the proposed changes be put into Template:Infobox person/sandbox and demonstrated at Template:Infobox person/testcases, so that we can see exactly what is intended. For instance, this use of the word "variable" - Wikipedia does not use variables except in JavaScript and in Lua modules, and I don't see any suggestion of how such code will be incorporated. --Redrose64 🌹 (talk) 21:56, 5 December 2019 (UTC)[reply]
    Redrose64 there is no code and no need for a test case. This is a simple cosmetic change to a label and the corresponding parameter name. Obviously, I was referred to "variable" in the general sense of the word, not the programming sense. Was it really not clear that I was referring to the parameter "Criminal_charges"? What else would I be referring to? - MrX 🖋 20:35, 7 December 2019 (UTC)[reply]
    There is no parameter |Criminal_charge= - there is |criminal charge= and its alias, |criminal_charge= - parameter names are case-sensitive. If we change these to |Criminal charge(s)=/|Criminal charges= and |Criminal_charges= respectively, existing uses will break. This is why I want to see exactly what is intended in the sandbox. --Redrose64 🌹 (talk) 11:02, 8 December 2019 (UTC)[reply]
    I am proposing an unambiguous change to the label, and a corresponding change to the parameter name so that the parameter name reflects the change to the label. The fact that I capitalized the first letter of the label, which is obviously a typo, does not result in confusion with any other label and parameter in this template. This leads me to believe that you are being intentionally obtuse. There is nothing stopping you or anyone else from creating a test case. However, it is not relevant to RfC process, which is simple seeking consensus for the change. - MrX 🖋 18:43, 27 December 2019 (UTC)[reply]
    Changing the label is one thing, changing the parameter name is quite another. If the parameter name is altered, existing uses will break. Show me the testcases that demonstrate that there will be no breakage, and I may agree to the proposal. --Redrose64 🌹 (talk) 13:16, 28 December 2019 (UTC)[reply]
  • Yes That would be helpful. Most criminals don't commit just one crime.HAL333 00:59, 6 December 2019 (UTC)[reply]
  • In theory, yes. Like Redrose64, I want to see it sandboxed and testcased, and like Bagumba I want to see parameters consistent between i-boxes, and even directly reusing code where possible.  — SMcCandlish ¢ 😼  12:57, 7 December 2019 (UTC)[reply]
Let's not complicate this. See my response to Redrose64 above.- MrX 🖋 20:35, 7 December 2019 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal to remove salary parameter

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


I think revealing someone's salary in the infobox is quiet disrespectful. In many cultures, asking about someone's salary is considered disrespectful. I think it is too personal and too private. Therefore, I think it should be removed from the infobox.--SharabSalam (talk) 23:45, 27 November 2019 (UTC)[reply]

☑Y Removed.—Bagumba (talk) 10:54, 14 December 2019 (UTC)[reply]

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

Category:Articles with missing wikidata information

Agnes Geijer is being placed in Category:Articles with missing wikidata information rather than Category:Articles with missing Wikidata information (capitalising Wikidata) and I assume it's something to do with this template being called but can't see immediately where it's happening. Can someone help? Le Deluge (talk) 12:43, 10 December 2019 (UTC)[reply]

The template in question was {{infobox person/Wikidata}}, which is (somewhat confusingly) not this template. I have implemented a workaround there and posted a query on that template's talk page. – Jonesey95 (talk) 15:35, 10 December 2019 (UTC)[reply]

Implement RfC to change Criminal charge

Please change the label "Criminal charge" to "Criminal charge(s)" (or "Criminal charges") and the parameter "criminal_charge" to "criminal_charges" per the results of the RfC above. Please test in the template's /sandbox or /testcases subpages as appropriate. - MrX 🖋 12:10, 30 December 2019 (UTC)[reply]

 DoneJonesey95 (talk) 13:46, 30 December 2019 (UTC)[reply]
I've updated the documentation and I think I've caught them all, but I'd be happy for someone to check and fix any mistakes I've made. --RexxS (talk) 16:53, 30 December 2019 (UTC)[reply]

Birthplace, nationality, and citizenship bio infobox parameters with matching values

 – 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)[reply]

TemplateData

Some recent edits at Template:Infobox person/doc added some extra autovalue and suggested fields. They apparently cause editors using the visual editor to add extra infobox entries such as in diff which added caption + birth_name + birth_date + birth_place with no useful information. I changed the entry for birth_date because I do not think we should encourage people to add such information unless it is reliably sourced. What about the others? Is it useful for that bloat to build up? Johnuniq (talk) 08:44, 4 January 2020 (UTC)[reply]

Yes, some technical details are documented on mw:Help:TemplateData, for an example see mw:Template;special or {{special}} here, it has an optional parameter, and IIRC (after four years) that's just not suggested, let alone required. –84.46.53.221 (talk) 04:30, 13 January 2020 (UTC)[reply]

"residence" parameter preview warning message problem

I have seen a problem on this is site, but when i click edit source button on some page and make some edits on the same page and click show preview it shows that there is a warning message like on many another pages on this site. So it is unlikely that the "residence" parameter will be restored anytime soon, thank you. Salomeeaalexandru899 (talk) 14:10, 15 January 2020 (UTC)[reply]

Was that last sentence a question or a statement? Thanks. Martinevans123 (talk) 14:22, 15 January 2020 (UTC)[reply]
It was a statement. Salomeeaalexandru899 (talk) 17:31, 17 January 2020 (UTC).[reply]

the "signature" parameter

Why is it that there's a |signature= parameter? I feel like this opens up a whole host of identity theft problems and I can't see how it's encyclopedic to include. —Joeyconnick (talk) 03:11, 17 January 2020 (UTC)[reply]

I have seen several inconclusive discussions about this, example here which points to WP:Signatures of living persons. Apparently the current situation is that if reliable sources have discussed someone's signature, and if that signature is publicly available, it's ok to include it. I would be happy to see it go. Johnuniq (talk) 03:42, 17 January 2020 (UTC)[reply]
If there is a problem with identity theft, and I doubt it, it's not this parameter but the collection at Commons:Category:Signatures. A person's signature is indeed sometimes subject to discussion in reliable sources, so removing the parameter seems like a one-size-fits-all approach. In any case, without the parameter, signatures will just be added somewhere else in the subject's article. Windmills. -- Michael Bednarek (talk) 03:55, 17 January 2020 (UTC)[reply]
I doubt there's much future for a fraudster who tries to hijack Ludwig van Beethoven's identity, so signatures of long-dead personalities aren't going to be controversial. On the other hand, I've always regarded the signature field as universally trivial, and therefore unsuitable for inclusion in an infobox (which is supposed to contain key information about the subject). --RexxS (talk) 00:10, 18 January 2020 (UTC)[reply]
Completely non-educational unless you're some sort of handwriting analysis expert. Should be dropped as trivial decorative junk.--Moxy 🍁 00:35, 18 January 2020 (UTC)[reply]
If the article did have handwriting analysis, the signature image should be next to the relevant text, not floating up top in the infobox.—Bagumba (talk) 03:19, 18 January 2020 (UTC)[reply]
I just noticed this on a random article, thought about bringing up a discussion here, and can't believe the timing of this one that was just started. My thoughts seem to be closely aligned with a lot of what I see here. I'm not really concerned about the identity theft issue for BLPs, but regardless, it's difficult to see how it's encyclopedic. In that extremely rare case where there's actually mention of someone's signature in the body of the article, the image can be included along with the discussion. Keeping it in the infobox is not an appropriate use of an infobox. What are the next steps here; would we need a full-blown RfC to nix the parameter? –Deacon Vorbis (carbon • videos) 16:02, 18 January 2020 (UTC)[reply]
While being WP:BOLD is an essential part of the 'pedia a full RFC is usually the best way to go with any changes to this infobox. MarnetteD|Talk 17:11, 18 January 2020 (UTC)[reply]
^.^b, FWIW the "trivial decorative junk" is also known as an autograph, some hobbies are as strange as editing esoteric templates. –84.46.52.152 (talk) 10:02, 22 January 2020 (UTC)[reply]

Signature parameter RFC

Should the signature parameter be removed from the infobox? –Deacon Vorbis (carbon • videos) 19:50, 20 January 2020 (UTC)[reply]

Background

See the preceding section for a little discussion that's already taken place. If anyone wants to link to anything older, please feel free to include here. An RFC was suggested as the best way to make a change like this, so here we go. –Deacon Vorbis (carbon • videos) 19:51, 20 January 2020 (UTC)[reply]

I remember discussing this some years ago, maybe around 2010-2013. Anyway, I have found Talk:Stephen King/Archive 1#Removal of signature image - request for comments. --Redrose64 🌹 (talk) 20:20, 20 January 2020 (UTC)[reply]

Survey (signature parameter )