Jump to content

Wikipedia:Village pump (proposals)/Archive 188

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Negligence of Articles For Improvement

OPTION D, PARTIAL PROCEDURAL CLOSE
Many WikiProjects are inactive these days, but contributors expressed that AFI was within the threshold for an active project, with editors nominating new articles weekly, selecting photos, and performing other technical work. It was conveyed that Articles for Improvement was vital for helping with systemic bias, the gender gap, and serving readers. There is a recommendation for contributors to Articles for Improvement to carefully select articles to improve, keeping in mind potential difficulty in improvement for topics that are obscure, too broad, fairly large already, and with many sub-articles that could be more appropriate for improvement. Although this was not written of by commenters, I will suggest the project to prioritize vital articles due to the importance and high-traffic visitation of them. There is no harm in keeping this project, but if AFI is closed, harm would be done to hard-working contributors who participate in improving articles, even those who only contribute occasionally. Finally, there is a procedural objection in that contributors to the project were not notified appropriately of a discussion to close the project, but rather only that there is a "discussion about Articles for Improvement". I will also note that the original nominator has been blocked for disruptive editing, so they cannot comment on refutations of the proposal. None of the procedural objections are enough to close this discussion, but I believe that with the other reasons it is enough. Conflict of interest disclosure: My only interaction with Articles for Improvement of my knowledge was adding a link to it in the Signpost's News and Notes section as part of my work there. (non-admin closure) 🐶 EpicPupper (he/him | talk) 23:04, 12 March 2022 (UTC)

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 previously started this discussion with no consensus, and I was ready to just give up and accept it when yesterday Google became the AFI and it still hasn´t been edited for an entire day despite being important, its clear that this wikiproject is incredibly denied and I think it should be shown on a high traffic page. Maybe we could add it to welcoming messages and for newcomers who do well we can award them with a Template:Articles for improvement barnstar. Activity on AFI is dead and nobody except for one guy actually participates.
Option A: Add articles for improvement to newcomer welcome messages and award barnstars to good contributors
Option B: Do not add to Welcome notices or Help:Introduction but do add it to some other high traffic page
Option C: Shut down articles for improvement due to no activity
Option D: Do nothing
Option E: Other (Specify what)
I think Option A.Lallint⟫⟫⟫Talk 13:39, 28 February 2022 (UTC)

It would help if someone vetted the suggested articles before they are posted. For example, one AfI proposed recently had been replaced by a dab some time ago and no longer required improvement. Certes (talk) 13:50, 28 February 2022 (UTC)
Option E Something else. Suggesting new users participate in AFI isn't all that good of an idea since new users should probably be sent somewhere else to start. However I don't think it should be deleted either. I think it should probably be made known to other people. ― Blaze WolfTalkBlaze Wolf#6545 15:19, 28 February 2022 (UTC)
Is there some way to find out what benefit AFI has had or its evolution over time? That might be helpful when deciding what to do about it. Presently, however, I agree with Blaze Wolf's perspective on it. A. C. Santacruz ⁂ Please ping me! 15:24, 28 February 2022 (UTC)
Wikipedia:Articles for improvement/Accomplishments is the list of changes they have made, all of the actually effective ones were 6-8 years ago. Lallint⟫⟫⟫Talk 15:37, 28 February 2022 (UTC)
I wonder if there's something that has essentially replaced AFI or if users have just forgotten about it. ― Blaze WolfTalkBlaze Wolf#6545 15:39, 28 February 2022 (UTC)
Also, the 3 suggestions on the talkpage are weirdly specific pages. Would be better to find general topics that have poor quality articles, which wouldn't require people to have knowledge of a very specific topic. For example, next week seems to be First Sudanese Civil War, which would require knowledge of African history. Wouldn't it be better to do something like Wood (which everyone knows something about)? Joseph2302 (talk) 15:50, 28 February 2022 (UTC)
Option E Specifically, scrap the project. All articles should be considered as subject to continual improvement since knowledge about anything may be constantly increasing (or rather, ignorance may be hopefully decreasing since we start with ignorance). Maybe what is meant are articles that are unverified/unverifiable, biased, opinionated, or badly written. Any of those or a combination afflicts the majority of articles in my entirely unscientific survey. However this is borne out by the fact that so-called "good articles" are a tiny minority. It wouldn't be a bad idea to scrap the GA embarrassment as well, as it is glaring proof by the encyclopedia's own admission that it publishes, mostly, junk according to its own metrics. I would give barnstars to anyone who proceeds to do that if I didn't think that such "awards" belong in kindergarten. 65.88.88.126 (talk) 15:56, 28 February 2022 (UTC)
So option C Lallint⟫⟫⟫Talk 18:04, 28 February 2022 (UTC)
Could Option C "shutting down ... due to inactivity" mean mothballing? Scrap=delete the project. 68.173.76.118 (talk) 00:45, 1 March 2022 (UTC)
If instead you were to pick articles that are more obviously incomplete, and had less visibility so someone getting an AFI notice might say - "hey, I didn't realize we had an article about that, I know what I can add", that would be much more effective. I know that was what I thought when I saw Google was the AFI - I looked at it and said "nothing obviously missing here" - and I used to work for the co, so I may know whereof I speak. Also A: Award barnstars. They're free, and praise is a non-negligible motivator, also helps popularize the project when others see them on the awardees talk pages. --GRuban (talk) 19:48, 28 February 2022 (UTC)
I think the difficulty here is that it's hard to come up with articles which are simultaneously obviously lacking in some area, sufficiently obscure that people interested in the topic might not already have known about it, and sufficiently broad that editors who get the notice are likely to have the interest and knowledge to improve it. The problem with picking "less visible" articles to improve is that they're often less visible because they're only of interest to specialists. An article for improvement really needs to be one that non-specialists can meaningfully help with – otherwise more focused collaborations (e.g. by subject-specific wikiprojects), or efforts by interested individuals will be more effective at improving the article. Caeciliusinhorto (talk) 21:15, 28 February 2022 (UTC)
As a starting point, here is a list of articles beginning with A which are rated as both stub or start class and top or high importance by more than one wikiproject. There should be about 1500 of them over the whole alphabet. Certes (talk) 21:25, 28 February 2022 (UTC)
To address GRuban's assertion that nothing is obviously missing from the Google article: my review shows no mention, whatsoever, regarding quantum computers, the milestone of quantum supremacy which they are said to have achieved, nor anything else including rates of progression and timetable goals for reaching the next milestones. Whether there are other articles covering these topics or not, Google is a "main player" in this field and it is a significant omission that they are not, at least, mentioned and linked from the main Google page.--John Cline (talk) 09:22, 2 March 2022 (UTC)
  • I would go with option C/scrap it. We shouldn't all go for the same article at the same time, but spread our net wider. There are literally (and I mean that word literally) millions of articles on English Wikipedia that need improvement. Phil Bridger (talk) 20:24, 28 February 2022 (UTC)
  • WikiProjects which don't affect the rest of the project are usually given latitude to decide for themselves how they'd like to proceed. I feel this discussion should be held on the WikiProject's talk page. If there's no one left interested in participating, then the initiative can be stopped. Otherwise, let the participants figure out the best next steps. isaacl (talk) 22:02, 28 February 2022 (UTC)
  • I have notified the WikiProject of this discussion. But the WP doesn't seem active to me, so I don't imagine many people will reply or would reply to a discussion there. Joseph2302 (talk) 14:34, 1 March 2022 (UTC)
  • D Do nothing. Keeping it around causes no harm, and if someone does become interested in it in the future, let them. --Jayron32 14:20, 1 March 2022 (UTC)
  • D - "do nothing" (1st choice) E - all supporting C, "GFY" (2nd choice)--John Cline (talk) 09:22, 2 March 2022 (UTC)
  • Comment I've struggled to unearth the actual discussion process to see the rationale for how Google was nominated for improvement at WP:AFI, and then automatically flagged by MusikAnimal's bot. However, there is a genuine need to identify and recommend the right sort of article for improvement, and these should be shorter ones with tags indicating clear areas for attention. That didn't seem to apply at that article. But MMiller (WMF)'s Growth Team Features is actively identifying structured improvement tasks for new users. There could be potential for the AFI team to work with the Growth Team to identify the right types of articles to improve, not the wrong ones. Nick Moyes (talk) 21:39, 2 March 2022 (UTC)
    You mean like those identified under "Help out" at Wikipedia:Community portal, which is linked from the sidebar on every page? Phil Bridger (talk) 22:00, 2 March 2022 (UTC)
    If participants in the articles for improvement initiative want to continue (which is an open question (*)), then their task queue ought to be distinct from the structured improvement task queue, since otherwise a separate queue isn't needed. I don't agree that there is a single set of "right" articles to improve; WikiProjects can use whatever criteria its participants find useful, and that can even include throwing in some already large articles that are lacking in some way.
    (*) My recollection is that when it was removed from the main page and renamed from "Today's article for improvement", stats were collected indicating that most improvements were being done by initiative participants, and so they chose to continue the initiative for their own benefit. If there is no longer a core set of interested participants, then the queue may have outlived its purpose. isaacl (talk) 23:00, 2 March 2022 (UTC)
    Hi Nick Moyes. From your comment, I can't tell if you found the discussion after struggling or if you struggled to no avail? In case it's the latter, here is the Google nomination and its discussion unto approval. I can't say what happened after that. Best regards.--John Cline (talk) 00:57, 3 March 2022 (UTC)
    Thanks, @John Cline. It was a 'no avail' situation, albeit in a fairly short time-frame. Thank you. Nick Moyes (talk) 01:20, 3 March 2022 (UTC)
  • Option C Mark as inactive/historical. No activity on the project talk page, and nobody is editing the suggested articles. As I've said above, there are better ways for people to find articles that they might actually be interested in working on. Dan from A.P. (talk)
  • Option D, strongly oppose scrapping. The state of most WikiProjects these days is inactive, but AFI is within the norm. Northamerica1000 has been regularly selecting photos each week, myself and MusikAnimal did a renaming and a bunch of technical work a few months back, and there's a new nomination at WP:AFIN roughly once a week. You could try adding a semi-active tag, especially considering that the AFI rarely gets worked on very much these days, but even that would probably be reverted. What the project needs is an infusion of editors, not deprecation, since it serves a vital purpose serving readers and countering systemic bias. There's no other content project on Wikipedia that specifically targets the overall highest-need articles in the encyclopedia. As Jayron32 noted, the option C !voters have failed to articulate any harm that keeping it around does. Lastly, I have a procedural objection, per Isaacl above and as the notification of this discussion to WT:AFI referred to merely a discussion about Articles for Improvement, not mentioning that it was a proposal to radically overhaul or deprecate the project. {{u|Sdkb}} talk 19:16, 12 March 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Require all good and featured articles that have been a good/featured article to be reevaluated every X amount of years

I think that in order to make sure a Wikipedia article still meets the criteria for a good or featured article, they must be reevaluated on a regular basis in order for an article to be still considered a good/featured article. The reason why I am proposing this is because there are some articles that have been good/featured articles for more than 10 years and haven't been reevaluated since promotion. Examples: Calvin Coolidge (featured article since 2007, never reevaluated) and Battle of Barrosa (featured article since 2007, never reevaluated). I have no opinion regarding the amount of time an article should be reevaluated and I welcome your opinions on what it should be. I think that a process like this will make sure that only the best articles are good/featured articles. Interstellarity (talk) 21:35, 12 March 2022 (UTC)

Are you familiar with the work being done at WP:URFA/2020? Pinging SandyGeorgia for her views.--Wehwalt (talk) 22:46, 12 March 2022 (UTC)
@Interstellarity I do hope you're therefore willing to help out with this!!! Nick Moyes (talk) 22:53, 12 March 2022 (UTC)
@Wehwalt and @Nick Moyes: Hi everyone,

I was unaware of WP:URFA/2020 when I posted this. I'd be willing to help review articles and determine whether they are worthy of their featured articles. Does anyone know if there is an equivalent for good articles? Interstellarity (talk) 23:12, 12 March 2022 (UTC)
Thanks for the ping, Wehwalt!
@Interstellarity: all featured articles theoretically are being reviewed at WP:URFA/2020, but how fast that process can proceed depends on how many editors engage. You can find information about how to help at this January Signpost article, and at our 2021 year-end summary here.
You can see at WP:URFA/2020A that no one has yet looked at Calvin Coolidge or Battle of Barrosa; if you want to enter comments on either of those to get the ball rolling, you should find all the information you need by reading the instructions at WP:URFA/2020 and the two links above. Please keep in mind if you first review an article that one of the goals is to engage editors willing or able to improve articles; we don't want to scare off editors with the idea that older FAs will suddenly all be defeatured, so reading the instructions and understanding the goals and expectations is highly recommended. The more help we get, the sooner we can get through the Very Old FAs.
I am unaware of anything similar for all 36,000 + GAs. SandyGeorgia (Talk) 00:13, 13 March 2022 (UTC)
For GAs, there was Wikipedia:WikiProject Good articles/Project quality task force/Sweeps - back in 2010. Thanks. Mike Peel (talk) 10:33, 13 March 2022 (UTC)
Flattered that the Signpost article was referred to 🙂 🐶 EpicPupper (he/him | talk) 03:31, 14 March 2022 (UTC)

Oppose - This proposal, while given in good faith, entirely misses its mark. A rule, for the sake of process alone, creates its own set of problems (requiring resolution) while resolving nothing (where no problem exists). A GA/FA'S lack of reevaluation is not the sign of problems, having been reevaluated almost certainly is. In theory, every time an article is viewed, its assessment and standing undergoes a concurrent review and the lack of maintenance tags and discussion nominations (including assessment reevaluations) confirm that the current ratings (when viewed) are correct. This system works, and has worked to date; there's no indication that it needs to be changed.--John Cline (talk) 01:53, 13 March 2022 (UTC)

Merging Wikipedia and Wikipedia:About

I would like to know if there has been any past discussion regarding merging these two pages. If so, can you please point me to the link that discusses this? If not, I would like to know if this would be a good idea. My argument for this merge is that this will simplify the need for redundant pages. Other online encyclopedias like Scholarpedia merge their about page and the article about itself while Citizendium has separate pages. Interstellarity (talk) 21:49, 13 March 2022 (UTC)

They're not really redundant—the project space page is targeted more to prospective editors to encourage them to become active editors and includes policy/guideline summaries that would be out-of-scope for the mainspace article. Mz7 (talk) 23:10, 13 March 2022 (UTC)
Wikipedia:About needs a ground-up overhaul. The main problem is that Wikipedians, when presented with a topic, tend to write encyclopedia articles. But about pages shouldn't be encyclopedic—they should be much shorter, for one thing, and they should focus on communicating our mission and helping users get the most out of the site. Take a look at the Wikimedia Foundation's about page—ours should be more like that. {{u|Sdkb}} talk 02:09, 15 March 2022 (UTC)

Issues with Vital Articles

I've noticed several issues with this project, namely at WT:Vital articles/Level/5. First off, this page is overwhelmingly huge at nearly 500,000 bytes, meaning that I'm having trouble both navigating the page and loading the editor. Trying to edit this page, even with a fairly powerful computer and fiber internet, basically turns my computer into a waffle iron. Secondly, the amount of user interaction that exists in this project is basically nonexistent, leading to discussions from four years ago open with less than four replies. Trying to get things accomplished in this project is impossible. Thus, I propose two solutions:

1.) Split the pages into other subpages (such as WT:Vital articles/Level/5/Music or WT:Vital articles/Level/5/Actors)

2.) Allow editors to make their proposed changes if six months have passed without a response. My reasoning is that if no one cares to join the conversation, then no one would object to the proposed changes. Obviously, I expect some opposition to this second proposal, but I'm interested to see what solutions are suggested in its place.

Thank you, Why? I Ask (talk) 08:31, 17 March 2022 (UTC)

I'm not entirely sure the proposals will be effective at fixing the issues with how we manage Vital articles. I wonder if something could be organized similar to the WP:RFA2021 RFA reform to have a comprehensive examination of how we curate content on-wiki. A. C. Santacruz ⁂ Please ping me! 12:09, 17 March 2022 (UTC)
I think this discussion is better held at Wikipedia talk:Vital articles. WikiProjects which don't affect the rest of the project are usually given latitude to decide for themselves how they'd like to proceed. isaacl (talk) 15:43, 17 March 2022 (UTC)

RfC: Categorise male footballers in the same way that we categorise female footballers

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is consensus in favor of both the main proposal and the subproposal. However, these options are contradictory, meaning that the main proposal overrides the subproposal's consensus due to wider participation. Note that this consensus applies to association football only due to the scope of the RfC. If editors wish to determine a consensus across a wider range of sports, they should start a separate RfC on the topic. This consensus also does not apply to the naming of articles (such as teams or leagues). A. C. Santacruz ⁂ Please ping me! 17:58, 17 March 2022 (UTC)


I was surprised to discover that we have Category:Swiss footballers with a subcategory of Category:Swiss women's footballers yesterday, since this seems to contradict Wikipedia:Categorization/Ethnicity, gender, religion and sexuality#Gender, specifically "sportsperson categories should be split by gender, except in such cases where men and women participate primarily in mixed-gender competition". I think that we need to have "men's" subcategories to match "women's". It seems that this is a systematic problem with footballer categories, and the CfD at Wikipedia:Categories for discussion/Log/2022 February 18#Category:Swiss footballers had a lot of procedural opposes since this needs a wider discussion. Hence this RfC - should we have "men's footballers" categories to match the "women's footballers" categories that already exist? Thanks. Mike Peel (talk) 20:38, 19 February 2022 (UTC)

Main proposal (footballer categorisation)

@GiantSnowman: I understand where you're coming from - men's football is much more popular than women's football - but I'm not convinced that we should wait for external sources before we change our category structure to something that is gender-balanced. We have established categorisation for other sports, why not adopt that here? Thanks. Mike Peel (talk) 20:55, 19 February 2022 (UTC)
No we don't - Category:English cricketers and Category:English women cricketers; Category:Players of American football and Category:Female players of American football etc. etc. GiantSnowman 21:00, 19 February 2022 (UTC)
@GiantSnowman: Sigh, those are also sexist and should be fixed. Mike Peel (talk) 21:02, 19 February 2022 (UTC)
I wondered how long it would take until "sexism" entered the argument, didn't expect it to be so soon! If that's your tack, why split categories by sex/gender at all? GiantSnowman 21:04, 19 February 2022 (UTC)
@GiantSnowman: I'd be equally happy to see Category:Swiss women's footballers merged with Category:Swiss footballers. Let's enter 'equality' into the argument. Thanks. Mike Peel (talk) 21:07, 19 February 2022 (UTC)
  • ? maybe? And maybe this will be sport by sport. A quick read suggests that women are not allowed to play association football, and are only allowed to play Women's association football. In some other sports there is often a women's league, restricted to women, but the "primary" league isn't sex restricted - but as it is competitive women rarely or never get a spot (though they could). — xaosflux Talk 21:27, 19 February 2022 (UTC)
    • @Xaosflux: Please expand on why this should be sport by sport, and why women are excluded from playing specific sports because they are female. Mike Peel (talk) 21:35, 19 February 2022 (UTC)
      • @Mike Peel: generally it is the opposite; men may not play in women's leagues (e.g. the Women's National Basketball Association) but women may play in the traditionally men's league (e.g. the National Basketball Association). However in limited cases, such as association football, women have been excluded by rules (References: <http://news.bbc.co.uk/2/hi/americas/4110027.stm> ; <https://theconversation.com/footballs-unnoticed-scandal-men-only-competitions-43162>). So in some cases, the "women's" game is effectively a different sport, and its common name just so happens to be "women's SPORT". So, as far as categories go - are you trying to categorize things by which sport they belong to, or what the sex of a specific player just happens to be? — xaosflux Talk 22:07, 19 February 2022 (UTC)
        • @Xaosflux: The whole issue makes no sense to me, why is the gender of the player relevant, and why does it need to be reflected in our category structure? Thanks. Mike Peel (talk) 22:16, 19 February 2022 (UTC)
          • @Mike Peel: My understanding is that "association football" and "women's association football" are different sports, so the categorizations of players would be about which sport they play, not really about their own sex - it's just that it happens to be that they are exclusive. In the future perhaps "association football" will become open, in which case a woman could be an "association footballer" or they could be a "women's association footballer". — xaosflux Talk 23:21, 19 February 2022 (UTC)
            • @Xaosflux: - My understanding is that "association football" and "women's association football" are different sports - this is 100% untrue, no idea where this suggestion came from. It is the exact same sport, played with the same rules, same equipment, etc, just by players of different genders. And here is a news article about a couple of women who played on "men's" teams...... -- ChrisTheDude (talk) 08:22, 20 February 2022 (UTC)
            If that is true (I don't know) then the category for players of "women's association football" should not be a subcategory of players of a different sport in the same way that categories for Rugby League players are not subcategories of categories for Rugby Union players. Indeed there should be a whole category tree for "Women's association football" in Category:Football codes (or possibly parallel trees for "Association football (men's)" and "Women's Association Football" in Category:Association football). Thryduulf (talk) 23:28, 19 February 2022 (UTC)
            • @Thryduulf: - If that is true (I don't know) then the category for players of "women's association football" should not be a subcategory of players of a different sport - it isn't true, they are not different sports, in the same way that the men's 100m sprint and the women's 100m sprint aren't different sports -- ChrisTheDude (talk) 08:22, 20 February 2022 (UTC)
    • Weak no - in that 'footballers' and 'women's footballers' are about players of those specific sports, not necessarily players, by sex, of those specific sports. As such, we don't need a "men's footballers", because there isn't a sport called "men's football". — xaosflux Talk 05:54, 20 February 2022 (UTC)
      • There isn't a sport called "women's football" either, it's just football played by women. There is no difference in the rules, playing equipment, or anything other than the sex of the players, it's the exact same sport in the same way that the men's 100m sprint and the women's 100m sprint are the same sport -- ChrisTheDude (talk) 10:40, 20 February 2022 (UTC)
        Doesn't "women's football" have a special rule, that player must only be women. Whereas football only has a rule that women can not play on mens teams sometimes (from U18 and up). I'm rather "weak" on my opposition - but think it could be useful to the readers, under the current technological limitations of categories, to be able to browser players that play in women's leagues - and also to be able to browse players that play in the non-womens-only leagues (such as the player in this youth league: <https://www.newstatesman.com/culture/sport/2015/09/meet-footballer-niamh-mckevitt-girl-who-joined-boys-league>). I'm pretty "weak" on this still, and football may be special compared to some other sports where there are more technical differences between "sport" and "women's sport". — xaosflux Talk 12:42, 20 February 2022 (UTC)
        Different leagues, not different sports. FIFA is the governing body for both men and women assoc football, but FIFA is not the governing body for more than one sport. Also, FWIW, our articles on women's association football and association football both say this explicitly. "Women's association football" is simply association football played by women. Levivich 12:52, 20 February 2022 (UTC)
        OK fair, but readers looking for players of one league are still going to be looking at the category, and the common name in references for the women's league is "women's football"; the common name for the other league is just "football", not "men's football". There is the FIFA Women's World Cup and the FIFA World Cup, not the FIFA Men's World Cup, etc. — xaosflux Talk 11:28, 21 February 2022 (UTC)
        This is true, I just don't don't think we should follow suit (calling it "football" when it's played by men but "women's football" when the same sport is played by women). I don't think, for example, any readers will be confused by a category called "male football players" and "female football players" (especially since readers don't even use categories anyway, as they're mostly used by editors for maintenance purposes). Although, the more I think about it, the more I think just doing away with gender categories altogether may be best. Levivich 14:22, 21 February 2022 (UTC)
  • Yes, though not sure a corresponding male category is always needed. Remember the discussion in 2013 about women novelists being moved out of Category:American novelists, triggered by an article in The New York Times. The solution was to make American women novelists a non-diffusing category and put the American novelist category back on their pages. All such gendered categories should be non-diffusing, since female soccer players are still soccer players. Wikipedia does have a guideline on this, also at Wikipedia:Categorization/Ethnicity, gender, religion and sexuality, that says In almost all cases, gendered/ethnic/sexuality/disability/religion-based categories should be non-diffusing, meaning that membership in the category should not remove membership from the non-gendered/non-ethnic/etc. parent category. StarryGrandma (talk) 22:18, 19 February 2022 (UTC)
    If we have categories for female foo we should have a parallel category at the same level for male foo (and non-binary foo if the category would not be empty), regardless of whether the category is diffusing or not. If you don't think a category for male foo is relevant then neither is a category for female foo (and vice versa). i.e we should always have either no gender categories or categories for all genders, with all such categories at the same level. Thryduulf (talk) 23:03, 19 February 2022 (UTC)
    @Thryduulf: see also above (and I'm far from well-read on this) - but it seems that the difference in the categories isn't a category of players, who are women, who play sport X; but instead players of sport X, which just so happens to be called "women's X". — xaosflux Talk 23:24, 19 February 2022 (UTC)
    @Xaosflux see also my reply to you above (which edit conflicted with your writing this), but this comment is more general than association football. We do have categories where we are categorising people doing the same thing based on their gender, e.g. novelists. In neither case should the category for one gender be a subcategory of the category for any other gender. Thryduulf (talk) 23:32, 19 February 2022 (UTC)
    @Thryduulf: (putting it out there that I only have weak opinions on all of this thread so far) I don't think we need to be as specific as we are on many categories, and should instead use category intersection better; e.g. if you want a female author of novels, look for pages where the subject is a "novelist" and is also "female". I understand the category system is very old and doesn't do this very well, so these extra unrelated subcategories exist to help readers find things like that. A quick look in that category is also Category:LGBT novelists, I'd say the same sort of better way of doing things should be figured out (unless these are novelists who write about the topic of "LGBT") --- else the same, they should be "LGBT people" and "novelists". But until a better way for readers to navigate categories (perhaps with some sort of dynamic category linking) exists, if we have "Women novelists" we might as well have "Men novelists" -- or have neither. I do think this is a much different conversation then that about if "women's football" and "football" are different sports though. — xaosflux Talk 23:47, 19 February 2022 (UTC)
    For the purposes of this discussion it is sufficient to say that where gendered categories exist they should always be parallel and at the same level. Whether gendered categories should exist and if so what part of which tree they should be on are valid questions but not relevant here - they are questions for the individual categories concerned. Awkward42 (talk) [the alternate account of Thryduulf (talk)] 03:53, 20 February 2022 (UTC)
  • Yes, might as well get this over and done with.--Ortizesp (talk) 23:03, 19 February 2022 (UTC)
  • Comment I have a feeling this is obvious to most people but in this case it is referring to what Americans call "soccer", and not American football (which to my knowledge has never had a female player on a team, dunno if it's because women just aren't allowed to play American football or if it's because usually women aren't interesting in American football, I don't know because I don't care that much about American football). ― Blaze WolfTalkBlaze Wolf#6545 23:51, 19 February 2022 (UTC)
    @Blaze Wolf: List of female American football players - Levivich 00:12, 20 February 2022 (UTC)
    Well I've been corrected. Doesn't appear any of them have played on NFL teams but they do clearly exist. ― Blaze WolfTalkBlaze Wolf#6545 00:18, 20 February 2022 (UTC)
    They face serious challenges in college. Here is a timely video Toni Harris posted two days ago talking about her college career: [1]. Levivich 00:33, 20 February 2022 (UTC)
    The NFL had one female player, in the 1970s. There's a WP article on her, but I don't recall her name. Her position was Holder, and her husband was the Kicker. 2600:1702:4960:1DE0:6136:D2CD:D164:1BED (talk) 07:50, 3 March 2022 (UTC)
  • Support change, but there are multiple ways of changing that I would support, none of which is the status quo: (1) split into separate male/female subcategories, with the parent category a container category that is not allowed to directly include male athletes or male-athlete subcategories, more or less as in the current proposal (2) make the female footballer subcategories non-diffusing and require the other subcategories to accept women into them, (3) abolish gendered subcategories and require this part of the category hierarchy to accept both men and women. Anything else (including the current ghettoized status quo) is unequal treatment, sexist, and making a show of how sexist our sports editing often is. —David Eppstein (talk) 00:05, 20 February 2022 (UTC)
  • Support change, oppose the current ghettoized status quo, to borrow the phrase from David Eppstein above. I support the proposal per nom but I wonder what we are going to do about nonbinary athletes, and that makes me wonder why we're categorizing athletes by gender at all. So I also support merging, as well as the non-diffusing, solutions proposed above. Whatever works and doesn't imply that females athletes are a subset of male athletes, or that male athletes are the default athletes, because that's sexist (and yes, this is about sexism, at least for me it is). Levivich 00:17, 20 February 2022 (UTC)
@Levivich: the only non-binary footballer that I know of is Jaiyah Saelua, who I'm not sure I'd be comfortable categorising as a "men's footballer", when that's not a common term for the sport as a whole, or the male part of the sport. Microwave Anarchist (talk) 09:32, 20 February 2022 (UTC)
Yes. If a tree is categorized by gender, then a male one should be created. I really don't see how we can justify this any other way. If this RfC passes, WP:CATGENDER should be updated. Gonnym (talk) 10:51, 20 February 2022 (UTC)
  • Yes, but's let's clarify the category descriptions as "people who play[ed] men's football" and "people who play[ed] women's football", allowing us to categorise the likes of Quinn (soccer) and Jaiyah Saelua correctly. Certes (talk) 13:10, 20 February 2022 (UTC)
    I'm closer to this one - in that it should be about who played what type of football - but the common name of "men's football" is just "football" (and in some cases it is mixed sex football) as opposed to "women's footbal" is sex restricted. — xaosflux Talk 13:32, 20 February 2022 (UTC)
    A good point, but mixed-sex football is rare at professional level, and people don't become notable for playing it. Certes (talk) 14:39, 20 February 2022 (UTC)
    ...and yes, I'm was using "men's football" as a slightly incorrect shorthand for "football in competitions either limited to men, or open to all but in practice entered almost exclusively by men". Certes (talk) 14:46, 20 February 2022 (UTC)
  • Oppose and abolish the gendered categories (upmerging to the general category). No need to split by gender, and would cause issues for players who have gender changes. Joseph2302 (talk) 18:19, 20 February 2022 (UTC)
I would agree with abolishing gendered categories and simply having everybody in Category:English footballers etc. GiantSnowman 18:46, 20 February 2022 (UTC)
This would not cause issues with players that underwent gender transitioning. The categories are not referring the gender of the player, but rather as players of men's/women's association football. S.A. Julio (talk) 16:10, 21 February 2022 (UTC)
  • Weak Yes would prefer to abolish the gendered categories. --dashiellx (talk) 14:28, 21 February 2022 (UTC)
  • Comment - there are now three potential proposals/outcomes (categorise by gender, namely 'male footballers' and 'female footballers'; or abolish these gendered categories completely; or maintain the status quo) and it is not entirely sure which editors are supporting/opposing which. I therefore suggest that @Mike Peel: invites everyone who has !voted to far to make a clear vote on each, perhaps under a new sub-section? GiantSnowman 14:56, 21 February 2022 (UTC)
    • @GiantSnowman: I think my question was clear (the first option vs. status quo), it's not my problem if people then think they are !voting for something else. If you want to add other questions more clearly in subsections below this (perhaps specifically for your middle option), go for it. Thanks. Mike Peel (talk) 17:33, 21 February 2022 (UTC)
  • Support creating "men's footballers" categories This is a better and more consistent way of categorizing, and will allow men's footballers to be subcategories of Category:Sportsmen (which is currently not the case). I disagree with upmerging the women's categories into a single men's/women's footballer category, it is useful to be able to be able to search specifically for players of [[women's association football}} and follows other sports such as Category:Volleyball players. S.A. Julio (talk) 16:10, 21 February 2022 (UTC)
  • No/Oppose - football played by men is far more popular than that played by women. In standard coverage the gender is never mentioned unless its women (for example it's the FIFA World Cup, not the FIFA Men's World Cup, while the women's version is always referred to as the FIFA Women's World Cup). Wikipedia should reflect what the sources and coverage say on a topic, and not what editors believe to be more gender-balanced or politically correct. Inter&anthro (talk) 22:37, 21 February 2022 (UTC)
    This is not a proposal to change the names of articles, it is solely to change how we categorise articles. Subcategories should be a more specific type of the parent category, e.g. Footballers → Association football players → British footballers → English footballers, but female football players are not a type of male football player. Thryduulf (talk) 13:15, 22 February 2022 (UTC)
    • No you are misinterpreting my argument, if none of the article about the organizations concerning men's football even make mention of the gender, then why should the categories? I wasn't saying the articles should be changed, I was saying the categories should reflect the articles. Inter&anthro (talk) 18:19, 22 February 2022 (UTC)
      In that case it seems your objection is to the name "men's footballers" rather than the principle of subcategorising female players below male players? Thryduulf (talk) 19:05, 22 February 2022 (UTC)
  • Support either placing all players (male and female) into a single category or moving all male players to a new subcategory with no individuals in the non-gendered parent category. As this is solely about Wikipedia categorization, the objection that men's teams are not called men's teams "in the wild" is irrelevant. --User:Khajidha (talk) (contributions) 13:10, 22 February 2022 (UTC)
  • Yes per Thryduulf (who of course says "If we categorise people by gender...". If folks decide there's not much benefit to categorising these articles by gender, that's fine by me as well). Ajpolino (talk) 17:01, 23 February 2022 (UTC)
  • Yes sex matters in sport and we have men's and women's teams.Melissa Highton (talk) 14:07, 25 February 2022 (UTC)
  • Support any categorization that means that men and women are categorized in the same way. Also, the problem is not limited to football, I assume the same change would take place for other sports as well. Gunnar Larsson (talk) 13:13, 27 February 2022 (UTC)
  • Support. We should not treat genders differently. Though I'd prefer to just abandon the gendered categorisation. /Julle (talk) 20:39, 2 March 2022 (UTC)
  • No Men's football receives much more attention and coverage than women's. Men's is a different level than Women's. They should only be treated as they same if the sport becomes the same for both genders. ArsenalGhanaPartey (talk) 17:18, 10 March 2022 (UTC)
  • Just rename the category to women's football players, so it is clear that the women's relates to the name of the sport and not the sex of the players. Ludost Mlačani (talk) 11:27, 16 March 2022 (UTC)

Sub-proposal 1 (footballer categorisation)

Abolish gendered categories in association football and so merge e.g. Category:English women's footballers into Category:English footballers. However, separate categories should remain for men's and women's national teams players e.g. Category:United States men's international soccer players and Category:United States women's international soccer players GiantSnowman 18:42, 21 February 2022 (UTC)

Then how do you deal with non-binary etc. players? Add them to their own category? what about men who manage in women's football and vice versa? GiantSnowman 09:45, 22 February 2022 (UTC)
I'd think that a category like "Women's association football players" is different from "Women that play association football"; that is we shouldn't categorize based on the gender or sex of the person in the category - but can still categorize upon what they played. — xaosflux Talk 10:36, 22 February 2022 (UTC)
Meaningless. GiantSnowman 17:10, 23 February 2022 (UTC)
What a well-reasoned and eloquent counter argument... --Ahecht (TALK
PAGE) 14:25, 3 March 2022 (UTC)
  • Support My preference is for the main proposal (which is why I phrased this RfC that way), but this approach would work as well. Thanks. Mike Peel (talk) 16:30, 25 February 2022 (UTC)
  • Support per my comments on original proposal. Joseph2302 (talk) 17:32, 25 February 2022 (UTC)
  • Support. This would be my preferred solution. /Julle (talk) 20:40, 2 March 2022 (UTC)
  • Oppose, per Ahecht and some others; and honestly, I cannot believe how this concept is completely flying over so many of your heads: we aren't categorising the players based on their sex; we are categorising them based on which leagues they play in! For soccer football there are "football (teams, leagues etc)" and there are "women's football". The ones that men play in are not called "men's football", they're just called "football". I am sympathetic to the notion that they ought to be called "men's football", but the fact is that they're not, and we aren't here to right great wrongs. Note that, there ARE sports where this is not the case: the men's and women's divisions ARE each labeled as such, but football is not one of such sports (at this time). I also oppose lumping them all together into one category. In this sport they are sex-segregated, and I sincerely hope for the physical safety and well being of all the female players that they remain sex-segregated. 2600:1702:4960:1DE0:6136:D2CD:D164:1BED (talk) 08:20, 3 March 2022 (UTC)
  • Support. Sorting by league seems to be the problem here. While I am sensitive that some footballers in the Women's League do not have a team or club so would fall through this categorization system, I don't think the league they play in is a distinct thing about them or their careers. I'm also going to hope folks are going to just continue to ignore the obvious polemic bait above. –MJL ‐Talk‐☖ 03:45, 5 March 2022 (UTC)
  • Oppose Mens and womens football are effectively seperate sports. They do not meet each other. Rathfelder (talk) 18:40, 5 March 2022 (UTC)
    That's illogical. Real Madrid CF doesn't meet Gold Coast Suns but they still play the same sport. Different leagues are not different sports. Levivich 20:16, 15 March 2022 (UTC)
  • Support per nom and above and my !vote in the previous section, this would be an improvement. I don't see the value in categorizing by gender. I don't see the value in categorizing by league, either. I do see the value in categorizing by team, and then they'll end up in sub-categories of leagues, but I don't see the value in separating those categories by gender (even if the name of a gender is part of the name of the team or league). Levivich 20:22, 15 March 2022 (UTC)
  • Oppose It seems a bit strange to have players of two different sports in the same category. Ludost Mlačani (talk) 15:54, 17 March 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Bot proposal (AFC submission templates)

There is consensus for such a bot, provided that it does not tag drafts created by experienced editors. The consensus on which users are experienced enough is less clear, but it looks like (auto)confirmed is a generally agreed upon threshold. (non-admin closure) Tol (talk | contribs) @ 19:01, 18 March 2022 (UTC)

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 a bot that adds AFC templates to drafts be made? – AssumeGoodWraith (talk | contribs) 08:08, 15 February 2022 (UTC)

I propose a bot that adds AFC submission templates ({{afc submission/draft}}) to new drafts that are missing them. (in draftspace)

Why?

  • I've seen newcomers make drafts, without any submission template. Whatever the reason is, most of them probably don't know how to submit the draft.
  • Even if the draft is hopeless, the newcomer can still learn from it.
  • Experienced users can easily remove the template, if it is undesired.
  • The template contains some useful links for those newcomers who are looking to actually create an article.

Some samples: [2], [3]

Please note: The template being added is the unsubmitted template, not the template you get from {{subst:submit}}

Discussion (AFC submission templates)

@AssumeGoodWraith: Why is this an RFC and why is it here? You should read WP:RFCBEFORE to see the steps you are expected to have taken before starting a formal request for comments. Requests/ideas for bots are much better placed at WP:Bot requests. 192.76.8.70 (talk) 14:41, 15 February 2022 (UTC)

  • I don’t have a problem with adding the AFC template to drafts that are in DRAFTSPACE. I would have an issue with doing so to “drafts” located in USERSPACE. The latter should be thought of as sandboxes - pages where a user is playing around with ideas. Those ideas might not be intended to be viable as potential articles (for example, I have created “drafts” in my userspace that are half formed ideas for a potential new section for an already existing article). Blueboar (talk) 16:23, 15 February 2022 (UTC)
    @Blueboar: The OP specified in their proposal that this bot would only add templates to pages in draftspace. 192.76.8.70 (talk) 18:06, 15 February 2022 (UTC)

I've seen the problem of a user not knowing their draft was not going to get any atttention, recently. But I don't think auto tagging it that way is a good solution. Better would be to leave the creator a talk-page message explaining what to do when they're ready to submit. It would probably be easy to get approval for such a bot. Dicklyon (talk) 17:27, 15 February 2022 (UTC)

  • Invalid RFC there is a clear process that should be used for this: WP:Bot requests. As such, an RFC is not needed, as RFC is meant for when a process doesn't exist. Joseph2302 (talk) 17:31, 15 February 2022 (UTC)
    I disagree. It's better to have a wider discussion on such a thing to establish consensus before doing a bot request, where the review will be much more narrow and technical, and will want to see an established consensus for the proposed changes. Dicklyon (talk) 17:35, 15 February 2022 (UTC)
  • As a BAG member any such request at WP:BOTREQ would be told to get consensus for the task at WP:VPR (those who actually read WP:BOTREQ would know this, see third sentence for those new to bots), so this is the right place to hold that RFC. Headbomb {t · c · p · b} 18:12, 15 February 2022 (UTC)
    What part of this task is controversial enough to require an RFC? As far as I can see this is basic maintenance, - these templates are already added to pages in draftspace if you use the article wizard, any of the preload templates, any of the draftification scripts and there's a small army of volunteers running around adding these templates by hand to pages that don't have them. If we've already have had editors running around draftsapace with AWB for years doing the same thing I don't see why this would be controversial enough to require a central RFC, it's certainly going to be less controversial than the bot that was changing indents on every talk page on the project. 192.76.8.70 (talk) 18:40, 15 February 2022 (UTC)
There has been substantial objections from the community on tagging drafts as drafts before. This is another proposal along the same idea. Not saying this will or won't pass, or if even if this is a good or bad idea, but mass tagging drafts with anything is something that requires clear consensus. Headbomb {t · c · p · b} 21:26, 16 February 2022 (UTC)
  • If we are going to have a RFC on this then Yes, obvious support from me since these templates are added to basically every page in draftspace by hand anyway, they're basically required to use the AFC process, a frequently recurring source of confusion I've seen at the teahouse is people not knowing how to submit a draft without the template on it, the template performs a number of other maintenance tasks in draftspace (e.g. tagging G13 eligible pages) and editors who don't want them will almost certianly be experienced enough to use user space drafts, botsdeny or similar. Anything that makes it easier for people to write their first article is a good thing. 192.76.8.70 (talk) 18:40, 15 February 2022 (UTC)
  • Strong Support Reduce headaches for new users & AFCers. Can't think of a negative aspect to it. Happy Editing--IAmChaos 00:15, 16 February 2022 (UTC)
  • Maybe for drafts created by non-confirmed editors who are still non-confirmed at time of bot run, who are effectively going to have to go through AfC, but for everyone else this wouldn't be appropriate, because AfC is not a compulsory process for anyone, and the purpose of draftspace is not solely for AfC drafts, even if they constitute a large number of drafts. ProcrastinatingReader (talk) 12:35, 16 February 2022 (UTC)
  • Support for pages created by non-confirmed editors per ProcrastinatingReader. I have notified Wikipedia talk:WikiProject Articles for creation and Template talk:AfC submission of this discussion. --Ahecht (TALK
    PAGE    ) 18:18, 16 February 2022 (UTC)
  • Support for pages by inexperienced editors. I took a look at a day's worth of new drafts. We don't want to make difficulties for the experienced editors who use Draft space for translations and other new articles before moving their work to mainspace themselves. I would suggest using extended confirmed user as the criterion. StarryGrandma (talk) 20:02, 16 February 2022 (UTC)
  • Support for all new draft pages, regardless of the editor. Much simpler. Experienced editors who don't like the templates can remove them. Also, auto-welcome the editor of they have no non bot edits to their user_talk page. --SmokeyJoe (talk) 03:52, 17 February 2022 (UTC)
    Auto welcoming is a perennial proposal. That's going to probably require a separate RFC (if I wanted to add it) – AssumeGoodWraith (talk | contribs) 06:09, 17 February 2022 (UTC)
  • Support for inexperienced editors or time delayed if applied to all drafts, maybe 1 day from creation delay? The draft could still be worked on by experienced editors even though it is created thus the delay. Some editors may have the habit to do incremental saves while fleshing out the draft. – robertsky (talk) 08:49, 17 February 2022 (UTC)
  • Support for non-confirmed editors (or non-XC editors). I'd alternately (maybe even additionally) support a bot message to user talks letting them know how to add the template themselves (with a Teahouse link or some way to ask "can someone add this template for me? I don't understand wikitext"), for non-XC editors only. It is worth a little bit of headache to any cases where an extraneous template is added or message is sent to someone who knows how to revert it, for the cases where a newbie will be unable to navigate AfC when that is the process they should be using. And even though confirmed-but-new editors can move drafts into mainspace themselves, in many cases it would be much better for them and for us were they to go through AfC. — Bilorv (talk) 00:23, 19 February 2022 (UTC)
  • Support procedurally, this is in order; procedurally we will discuss, !vote, and approve the proposal here, then the BAG will validate the specific bot doing this. As far as whether this is a good idea: yes, it is. If a non-ECP editor creates a draft, a bot should add the AFC template (but not start the "submitted" timer) in all situations. When it is an ECP editor ... normally probably also yes, but maybe it gets complicated. But BAG won't approve a bot that edit-wars, so it will be fine. User:力 (powera, π, ν) 01:48, 20 February 2022 (UTC)
  • Support for non-XC editors I also like Bilorv's idea. casualdejekyll 01:12, 18 March 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Method of surname clarification

Which format should we prefer to clarify the surname of biographical subjects with non-English names: hatnotes, explanatory notes, or something else? {{u|Sdkb}} talk 05:15, 3 February 2022 (UTC)

Background and rationale (surnames)

For many years, Wikipedia used hatnotes at the top of biographical articles for subjects with names that used Eastern name order or other naming conventions likely to be unfamiliar to English speakers. Since 2020, these have been consolidated in {{Family name hatnote}} (examples: 1, 2). Also since 2020, a set of templates has been available that clarifies surnames using an explanatory footnote (examples: 1, 2), although so far their use has been relatively limited.

As far back as 2011, concerns have been raised repeatedly about the hatnote approach (discussions: WP:VPP 2011, WT:MOSCHINA Feb. 2020, WT:HATNOTE Sept. 2020, and others). There are two main issues:

  1. Emphasis: A hatnote is arguably the single most prominent place in an article after the title, since it appears above even the first paragraph and is emphasized through italics and indentation. However, the information in surname hatnotes is not all that vital compared to the essential biographical information in the first paragraph. Eastern name order, while an interesting factoid, does not relate specifically to an individual person. Further, because we refer to a person by their surname throughout an article, most readers would likely pick it up even if it were not spelled out for them. We normally try to avoid putting trivial pieces of information in the lead, as such information would be undue weight. The same principle applies to layout, where trying to include too much leads to banner blindness (as we see on many talk pages). Overall, the information in a surname hatnote is not as essential as the information elsewhere in the lead and does not seem to warrant a prominent placement if avoidable.
  2. Fittingness: Per the WP:Hatnote guideline, hatnotes have a discrete and clearly defined purpose, which is to help readers locate a different article if the one they are at is not the one they're looking for. Under this core definition, using them instead for surname clarification is a misuse which muddles their purpose. It seems that (as with emphasis), the choice to use surname hatnotes way back in the early 2000s was likely not a deliberate preference, but rather an awkward shoehorn of information that did not easily fit elsewhere at the time.

Surname footnotes address both these issues: they reduce the visual emphasis of the clarification, while still preserving it for any interested readers and converting it to a form that fits its purpose. I therefore propose that we adopt a preference for surname clarification via explanatory footnotes. If passed, this would permit interested editors to transition articles to the footnote format, but it would not override local consensus at any article where editors decide to keep the hatnote format (which could be noted in a hidden comment). Relevant guidelines would be updated to state that footnote clarification is preferred but hatnote clarification may be kept if desired. {{u|Sdkb}} talk 05:15, 3 February 2022 (UTC)

Notified: WP:CENT, WT:Hatnotes, WT:Footnotes. {{u|Sdkb}} talk 05:15, 3 February 2022 (UTC)

Survey (surnames)

Please !vote Hatnote, Footnote, or something else.

  • Footnote preference, as proposer. {{u|Sdkb}} talk 05:15, 3 February 2022 (UTC)
  • Footnote exactly per nom. Levivich 05:24, 3 February 2022 (UTC)
  • Footnote a.k.a. Support proposal per nom. I'll also go farther and ask to deprecate surname hatnotes community-wide (if this extra bit doesn't pass, then the proposer's version is still very good). In this case, they would be phased out gradually as editors get around to updating articles.
    These hatnotes I find to be quite bizarre, giving WP:UNDUE weight to trivia, and violating WP:HATNOTE's well-reasoned direction that such prominent placement is only for navigation. The WP:TRHAT section of HATNOTE especially applies here. Explaining naming conventions, regardless of what it is, is not so important a matter that it deserves to have the most prominent place in an article. A footnote (or failing that, anything else) serves the same purpose much better.
    The existence of these has also occasionally been used to justify arguments to add hatnotes for other personal information, such as gender pronouns. However, current practice is that any time such in-article clarification is done, a footnote is used, and it works well for these cases. (Example: ND Stevenson.) If that can work for gender pronouns, it can definitely work for surnames. Crossroads -talk- 05:48, 3 February 2022 (UTC) updated Crossroads -talk- 05:29, 4 February 2022 (UTC)
  • Not hatnote per OP. No great opinion on the alternative, though I think I would recommend footnote if deemed necessary locally as advisement and not as general expectation. It probably just isn't necessary at all to point out which is the family name, also per the OP. --Izno (talk) 06:10, 3 February 2022 (UTC)
  • Currently not voicing a preference, however I oppose the "preference" wording used in the proposal. If a decision is made that hatnotes shouldn't be used based on the arguments provided, then a a local consensus shouldn't override it. So if consensus arises for footnotes, I support complete adoption of it. This would also make it possible to very easily convert {{Family name hatnote}} (which has 66719 transclusions) without needing to check with the local editors of each page. --Gonnym (talk) 06:25, 3 February 2022 (UTC)
  • Not footnote I'm not particularly vibing with the idea of adding to 66000 biographical articles an entire level 2 Notes subheading consisting entirely of "a. ^ This is an East Asian name. The surname is {{{1}}}." Folly Mox (talk) 07:19, 3 February 2022 (UTC)
  • Allow all depending on level of likely confusion. I like the historically widely used hatnote approach because it sets out the conventions used in an article without impacting on the body. A footnote is the minimum that is necessary, as it is non-obvious which name ordering is used. This is especially confusing with Chinese compound surnames like Sima or Ximen: the family name of Sima Qian is Sima. With names like Lee Kuan Yew, it is hopeless to guess what is the last name, so the article needs to tell you. A reader searching for Cixin Liu needs to be reassured that Liu Cixin is the same person (so there is some navigational use for the hatnote). —Kusma (talk) 10:48, 3 February 2022 (UTC)
    For Cixin Liu, both orders are bolded per MOS:BOLDLEAD, which is how we normally handle topics with multiple names and I think is sufficient here. For a name where one order goes to one person and a different order goes to another, I'd support a hatnote. {{u|Sdkb}} talk 19:09, 3 February 2022 (UTC)
    Any decision here applies only to hatnotes about surname clarification. So Lu Ping would keep the hatnote For the Taiwanese writer, see Ping Lu. but the hatnote In this Chinese name, the family name is Lu. might be relegated. Certes (talk) 19:36, 3 February 2022 (UTC)
  • Footnote or other non-hatnote. A hatnote is too prominent and usually applies to the entire article rather than to a detail such as surname clarification. Certes (talk) 11:27, 3 February 2022 (UTC)
  • Allow either per Kusma. Stifle (talk) 12:00, 3 February 2022 (UTC)
  • More information, please Hatnote Both of the examples given, the family name comes first, so at first glance it looks like the hatnote is worthless, that people should just know that in a Chinese name the family name is first. But I don't think that is the case. In the discussions, editors have already mentioned that sometimes it is unclear which name is the family name. I think to be fair, you should list examples of articles with hatnotes where the family name does not come first. This, I think would give editors trying to weigh in here a better snapshot of the impact/value of these hatnotes. I reserve my vote until I understand this better. StarHOG (Talk) 14:39, 3 February 2022 (UTC)
Okay, the article on Raul Neto sealed the deal for me. Thank you Kusma for providing several examples. This along with Mathglot's comments about wanting to know up front how to read an article and have a person's name in your mind correctly. The Antonio Arias (referee) article is also a good example of why we do not want this information as a footnote. It is only the brevity of this article that the reader is given information about the naming almost immediately. In a longer article, that footnote would be lost or never referenced by your average reader. I am now strongly for using the Hatnote to explain to readers the naming convention a person uses. StarHOG (Talk) 03:22, 4 February 2022 (UTC)
  • Raul Neto has a hatnote and Antonio Arias (referee) a footnote about naming conventions with given names appearing first. Certes (talk) 14:45, 3 February 2022 (UTC)
    The last name doesn't always come first with Chinese name, especially with people who have lived elsewhere. There's Shiing-Shen Chern (family name is Chen) and the wonderfully weird Lowe Kong Meng. Category:Members of Academia Sinica is a bit of a mess with both naming orders widely used. —Kusma (talk) 15:14, 3 February 2022 (UTC)
    For some non-Chinese examples, consider Gloria Macapagal Arroyo or Arantxa Sánchez Vicario. —Kusma (talk) 15:18, 3 February 2022 (UTC)
  • Footnote (ie Support proposal per nom). Makes perfect sense. MichaelMaggs (talk) 14:59, 3 February 2022 (UTC)
  • Hatnote per Folly Mox, and the fact this is pretty important information you shouldn't have to dig for when you need it, and names don't often need other hatnotes so it's fine to use it for a non-disambiguating purpose for people. 107.242.121.51 (talk) 18:29, 3 February 2022 (UTC)
  • I think Folly Mox, Kusma, and StarHOG make good points. If the way that hatnotes are actually used on thousands upon thousands of articles is inconsistent with WP:HATNOTE, perhaps it is WP:HATNOTE (a guideline, not policy) that needs revising. Should we also eliminate {{correct title}}, since that doesn't direct readers to another article with a similar name? Hatnotes in general resolve possible confusions regarding article titles, and their use in this respect is entirely consistent with that broader purpose. XOR'easter (talk) 19:38, 3 February 2022 (UTC)
    {{Correct title}} is the other notable exception to WP:HATNOTE, but it's much less common – <1k pages – and something that we will hopefully one day no longer need once future software improvements are made to MediaWiki. I'd rather reign in the purpose of hatnotes than let it broaden out to the point of meaninglessness, since allowing it to broaden has costs to readers: with a discrete purpose, it's safe for readers who know they've landed at the right page to ignore hatnotes, whereas if we allow them to become a catch-all place for important information, that no longer holds true and opens us to a bunch of sure-to-be-messy discussions about whether to have hatnotes for things like pronouns (see Crossroads' !vote above).
    With that said, I do acknowledge that fittingness is more of a secondary consideration than emphasis. The main reason I'm putting this forward is the emphasis concern, and the fact that clarifications would also fit better purpose-wise with footnotes is just an added bonus. {{u|Sdkb}} talk 21:01, 3 February 2022 (UTC)
    The article title would be the same regardless of which of the names is the surname, so I fail to see how this is consistent with the purpose of handling title confusions. The "correct title" template does 'alter' the title, so that placement makes sense - and is ideally temporary until MediaWiki is improved as noted by Sdkb. Crossroads -talk- 05:29, 4 February 2022 (UTC)
    The possibility of title-related confusion exists because readers are not unlikely to come to those pages from somewhere that used a different order. A hatnote is a convenient place to ameliorate that confusion. WP:HATNOTE was made for editors, not editors for WP:HATNOTE. I guess I fall into the allow all, including possible-something-else camp on this one, with a preference against footnotes but a recognition that a one-size-fits-all, across-the-board rule is probably suboptimal. XOR'easter (talk) 00:00, 5 February 2022 (UTC)
  • Allow either per Kusma. There are cases where it's genuinely confusing enough to merit a hatnote, and other cases where it isn't. (t · c) buidhe 21:03, 3 February 2022 (UTC)
  • Not sure yet; leaning 'something-else' (Summoned by bot) – I take the point about the original purpose of hatnotes, and that's somewhat persuasive, but otoh, presenting information clearly to the reader trumps just about anything else in my book, and if a majority of surveyees say hatnote makes it clearer, then I'm fine with that choice, too. Otoh, not sure footnote helps as much as I would like. I think a major part of the calculus for me, is I *want* to know how to properly identify someone, and I don't want to have to hunt for whether the Singaporean politician is Mr. Lee, Mr. Kuan Yew, or something else, and a corollary of this is that I don't want to feel like a fool after getting halfway through the article, and realize with embarrassment that I've had it backwards in my mind up to that point. That would be the fault of the article, not my ability to understand, and I would resent it. So, I'm basically okay with any solution that avoids that, and I think at this point, I'd like either a clear statement in the first or second sentence ("Lee Kuan Yew (surname: Lee) was a Singaporean lawyer and politician...") or a usage such as "Mr. James", "Prime Minister Martin" that makes it clear by implication, without necessarily stating it outright: ("Lee Kuan Yew was a Singaporean lawyer and politican. Lee was Prime Minister from 1959 to 1960..."). So basically, just get me the information by sentence #2, don't make me hunt too hard to find it, and I'm good. I'm not categorically opposed to having the surname in a hatnote just because hatnotes were initially designed for disambiguation, because it satisfies the "clarity" issue; but if a just-as-good solution offers itself, I'd vote for the latter. Mathglot (talk) 01:19, 4 February 2022 (UTC)
  • something-else Perhaps a |surname= added to {{Infobox person}}. Tvquizphd (talk) 03:29, 4 February 2022 (UTC)
  • Allow all per Kusma, specifically including Mathglot's something-else. On the one hand I'm sensitive to the slippery slope argument made by Crossroads, the last thing we need is a list of hatnotes at the top of articles. However I also agree with those who want to make sure that it gets communicated right away, and I'm conscious that getting it right - and communicating it right - matters. To inadequately purvey this info is to continue biases already rampant here and elswhere. What to do, then? Let's allow a variety of practices to flourish here and if the benefits of a particular approach eventually become clear we can prescribe/prefer/deprecate as needed. Retswerb (talk) 07:27, 4 February 2022 (UTC)
  • Footnote, but use <ref group=note> to avoid it getting confused with normal references. Hatnotes are overkill for this - they should be used when there is potential for confusion with another article, not minor clarifications of surnames. Modest Genius talk 12:48, 4 February 2022 (UTC)
  • Allow all There is unlikely to be a one-size-fits-all solution to this, and having options for how to handle it best per article is the best option. --Jayron32 14:16, 4 February 2022 (UTC)
  • Against explicit preference for footnotes. The current practice doesn't fit well with the overall purpose of hatnotes, but I wouldn't like to see a shift from the misuse of hatnotes to the misuse of footnotes. Explanatory footnotes are used for tangential details, not for information that may be necessary to understand how to read the article.
    I would like to note that even though I disagree with the proposed solution, I don't question the existence of a problem, but that's part of a bigger issue that we need to tackle. The first sentence of a biography article will often contain a lot of details – nicknames, maiden name, spelling of name in native orthography, transliteration(s), pronunciation (in English or native language) – that create a difficult to parse thicket that stands in the way of readers getting to the bit that describes who the subject is. I think we need a dedicated space for that information: one that doesn't clutter the first sentence but is still prominent enough (the end of the first paragraph? the end of the lede? a new lede paragraph that's visually set off from the rest? a section of the infobox? a dedicated (info)box?....). Once that is done, and we have a space where readers will learn to expect all name-related information, then the content of those hatnotes will naturally fit in there. – Uanfala (talk) 15:34, 4 February 2022 (UTC)
    I agree with that problem statement, though I have no brilliant solutions. Footnotes seem less bad than hatnotes but I hope there's a better way. Certes (talk) 17:02, 4 February 2022 (UTC)
    Definitely a separate conversation to be had about this, I completely agree. Retswerb (talk) 09:31, 12 February 2022 (UTC)
  • Hatnote ~ the footnote is a pain to have to scroll down to in order for important information ~ or, at most, allow all. Happy days ~ LindsayHello 16:26, 5 February 2022 (UTC)
  • Hatnote - the votes are leaning otherwise, and I assume that is because there are a ridiculous number of completely unnecessary hatnotes for names on biography articles that should be removed. Just because someone is from Asia doesn't mean they need a naming hatnote. However, when there is a reason that the name must be clarified, a hatnote is the correct way to do so. User:力 (powera, π, ν) 00:00, 6 February 2022 (UTC)
  • Hatnote Understanding a person's name is quite important and so clarification should go at the top of their article, not the bottom. An infobox entry may be adequate and so we shouldn't be rigid about this. Andrew🐉(talk) 14:41, 7 February 2022 (UTC)
  • Hatnote this information is too critical for a footnote, most of which don't get read. Headbomb {t · c · p · b} 21:43, 7 February 2022 (UTC)
  • Hatnote much too important to have to go looking for it, and much too hard to explain and re-explain Spanish surnames, and way too many hispanic names that are first, middle and last name the same, so need the fourth surname as per Spanish language customs spelled out right up front. SandyGeorgia (Talk) 21:54, 7 February 2022 (UTC)
    @LindsayH@力@Andrew Davidson@Headbomb@SandyGeorgia, if you think that putting the information in a footnote would be insufficient emphasis, I'd urge you to consider @Mathglot's idea above to put it in the parenthetical after the name, where we already put name information like pronunciation and native language spellings, and to adjust your !votes if you'd consider it an acceptable outcome.
    I understand where you're coming from, in that names are an inherently important thing, but I think it's important to remember that in many cases (albeit not all), we can clarify a surname easily just by using it in the rest of an article, and we wouldn't want a strict outcome of "hatnote" here to prevent us from using other methods for the articles where they fit better. It's also worth remembering that anything is going to seem more important in a discussion where it's the explicit focus, but hatnotes don't just note the information alongside other things, they prioritize it by emphasizing a generalized note on naming conventions more than even an individual subject's nationality/occupation/birth date. No matter your preferred solution, I hope we can reach a consensus at least that that isn't ideal. {{u|Sdkb}} talk 22:12, 7 February 2022 (UTC)
    In hispanic names, the parenthetical just wouldn't make sense as part of the text; one's full name is Joe Bloe FatherLastName MotherLastName, and the parenthetical would take up valuable real estate in the middle of the first line to explain how hispanic surnames work. So our text would be cluttered with Thor Leonardo Halvorssen Mendoza (Halvorssen is his father's paternal family name, Mendoza is his mother's paternal family name, according to Spanish naming customs) ... it's just goofy to take up precious real estate for that. Hatnote does the job, is easier, and standard. SandyGeorgia (Talk) 23:08, 7 February 2022 (UTC)
    Sandy, I believe this is not the issue we are trying to solve. In fact, Nil Einne addressed this confusion directly below. What we care about in this discussion, if I'm not mistaken, is not *really* what the surname is, but *how we are going to refer to Mr. XYZ in the rest of the article. In that sense, we don't care if "Mr. Lee" means that "Lee" is his surname or first name, we just care that in this article, we refer to him as "Mr. Lee", because that's what the sources do. Same thing with a Hispanic surname, Russian patronymics, or Sitting Bull; it doesn't matter which one is the surname, or if the term "surname" even applies at all.
    In your example, therefore, there would be no long parenthetical at all; in your Halverson example, the second sentence already solves this, and says: "The New York Times described Halvorssen as a maverick 'who champions the underdog...'" so now we know that he is referred to as "Halverson" in the article, and that's all we need to know. Mathglot (talk) 23:22, 7 February 2022 (UTC)
    Missing ping User:Nil Einne. Mathglot (talk) 23:29, 7 February 2022 (UTC)
    @SandyGeorgia, sure it could work. Here's that article with efn footnotes and here it is with a hybrid parenthetical/footnote format. {{u|Sdkb}} talk 23:24, 7 February 2022 (UTC)
    The first (footnote via efn) was so hard to see that I had to go look for it in the footnotes and then backtrack to see where you had placed the efn (meaning, a casual Wikipedia reader will probably miss it, or not go look for it). The second is just what I said in terms of convoluted and cluttering the first line.
    To Mathglot, consider a common issue (not in this case because they don't have a close relationship, but I digress); father and son do business or politics together and their article deals a lot with both of them and has to distinguish them. If is very common for mothers and daughters, and fathers and sons, to have the same name, and even the same middle initial. Then, per Spanish naming customs, we would refer to them in text as Halvorssen Mendoza and Halvorssen Vellum. The hatnotes are doing a good job educating readers about Spanish naming customs and how they are used in writing; I don't see a way around it, and I consider them a valuable aid to readers. SandyGeorgia (Talk) 23:46, 7 February 2022 (UTC)
    Hi Sandy, that's possibly a good use case for keeping the hatnote, it might help in that case. If this is a fairly common situation, can you link a few examples so we can see what they actually do now? I'm particularly interested in how they handle this in the body of the articles.
    But even here, I can see an argument for dropping the hatnote: partly due to banner blindness, and partly due to proximity: if I were reading one of those articles, I presume that the person named in the article title would be introduced in the lead sentence and paragraph, and I'm not sure how far down the same-named father would be introduced. I think *that* is where I would want to see the explanation; by the time I get there, I won't remember the hatnote (assuming I ever read it, which I might not if I saw a picture or a lead sentence with a bolded title in the first sentence letting me know I was on the right page). When they bring up the father, that is the point where I want to know who is who; if they use words like "Senior" in their culture, maybe that is sufficient; or pere, and so on.
    In the George W. Bush article for example, his similarly named father isn't mentioned by name in the five-paragraph lead at all; he first shows up in section #Early life and career as "He was the first child of George Herbert Walker Bush and Barbara Pierce." and by that time, the hatnote is a distant memory, if it ever registered at all. Perhaps you are talking about father-son pairs with identical names, not even differing by a middle initial; here, I'd like to see those links and see how the articles treat them now. See also Alexandre Dumas. Mathglot (talk) 00:20, 8 February 2022 (UTC)
    My memory won't cough up the example I am trying to recall of two Panamanians who got mixed up on Wikipedia; it will likely come to me when this discussion is over. But the George H. W. Bush example accomplishes same. Do a ctrl-f on the word son to notice how awkward the text is, particularly starting with the Appearances section. If those two had Spanish names, that awkwardness would go away, as we would have clear names for both: Bush Walker is the father and Bush Pierce is the son. Ah, but it gets better in this case, because Jeb is also Bush Pierce. So, this is probably as good of an example as it gets.
    Gow to move forward with this example: I believe the goal of this discussion is to reduce the number of banners at the top of the article per banner blindness. A different goal is to educate about Spanish naming customs at the very top of the article, without adding clutter to the text. My concern with removing the banner is that you remove something that editors creating articles in the Spanish-language realm will clearly have noticed and can see how to easily use, and serves to educate broadly about Spanish names. We would be replacing it with either a footnote or in-text clutter that offer the potential for inconsistent use. I am sympathetic to your goals and open to being convinced, but we're not there yet. Maybe there's a third alternative, that we could explore with the Bush Walkers and the Bush Pierces. SandyGeorgia (Talk) 14:50, 8 February 2022 (UTC)
    I understand what you're arguing (purely in the sense of "discussing") for, but i'm not sure i agree; i have read Mathglot's suggestion and, i'm afraid, in mine opinion that would be far more disruptive to the flow of the lead sentence/paragraph. To take the example given there, i think it is essential that we are clear that Lee is the surname, and just using it in the next sentence is not clear, especially and specifically because the name order is different from that expected by what is probably the majority of our readers; in particular with this name it rather clashes with expectations because "Lee" is sometimes a forename in English, so it has the immediate appearance of being over-familiar, and did i (and therefore probably others) not know i might try and change to what appeared to be a more formal and appropriate usage. As for the first suggestion with this example, putting "(surname: Lee)" immediately after the name is very interuptive (surely there's a word for that?) to the flow of the sentence and i would strongly oppose that. I recognise the argument that it's not what hatnotes are for, but...so what? It works and (if it's essential we use them only as intended) we can say we are disambiguating any confusion over the name. Happy days ~ LindsayHello 13:15, 8 February 2022 (UTC)
  • Footnote. There's lots of background information that is often absolutely crucial to understanding a biography. Why stop at naming conventions? Often there's far more significant background detail relegated to a wikilink - if you're reading an article on a Qin dynasty court official, a completely blank slate reader may well need to click multiple other history articles before they can really get it. A hatnote just isn't the right place for this; stick it in text (if the name is expected to cause unusual confusion / dispute) or in a footnote, same as all other relevant content. A hatnote simply isn't the right spot in the same way that a maintenance banner isn't the right tool for the job; hatnotes are for Wikipedia navigation, not explaining background detail. SnowFire (talk) 10:21, 8 February 2022 (UTC)
  • Hatnote as it's an important detail which often explains inconsistencies in the article between people's full and common names e.g. why Spanish/Portuguese people have multiple surnames, and why we only use one of them to refer to them. Allowing any type seems sensible too, but footnotes will never be read. Joseph2302 (talk) 00:38, 9 February 2022 (UTC)
  • Hatnote per basically all of the above. I don't need to repeat what everyone else already said. I don't object to footnote templates also existing for this purpose, e.g. to use at an article that already has a lot of hatnotes. And we don't need either for a lead like "A B (Chinese: B A) ...". But use hatnote by default.  — SMcCandlish ☏ ¢ 😼  05:37, 11 February 2022 (UTC)
  • Hatnote for now, as though there's the possibility of a better solution somewhere down the line that this discussion might lead to, hatnotes are the best we have for now. I feel that anyone advocating footnotes or presuming that readers will be able to work things out for themselves just by reading the article is confusing the average reader of English Wikipedia with the average editor, regarding their knowledge of MediaWiki's conventions, those of web pages in general, and their global perspective. When writing for a general natively English-speaking readership, I don't think of what I would understand, I think of what my parents or grandparents would understand. They do not know that Wikipedia has footnotes and that clicking the blue superscript characters leads to them. No matter how many times I explain it to them, they cannot remember that cultures other than their own, indeed all but a minority of the world's population, use naming systems other than <personal name> <family name>. They will read an article about an Icelandic person and be confused why the person is only referred to by their personal name, not by what they think is the person's family name. They will read an article about a Chinese person and be confused by why the person's name is shortened to what they think is the person's personal name. I will explain why they are mistaken, and they will have forgotten my explanation in a few days' time. These kinds of people need these things to be mentioned first of all, every time a name is not in <personal name> <family name>. Hatnotes are good at doing this (even if it's not their original purpose) because they at the same time visually get this information out of the way for people who don't need it, and it avoids making the first mention of the person's name even more complex. Tempjrds (talk) 19:12, 18 February 2022 (UTC)
  • Hatnote. Long story short, hatnotes for this particular use enjoy a strong and longstanding consensus. The guideline on them should be updated to reflect this. – Finnusertop (talk ⋅ contribs) 17:54, 21 February 2022 (UTC)
  • Hatnote While not perfect, at present this seems to best way to make it clear to our readers (many of which may not even be aware of Eastern-naming order) which name is the surname. At least for me as a mobile reader and editor, I would prefer a hatnote. I would also be opposed to adding something only in the infobox as not every last-first person article has an infobox. Link20XX (talk) 04:03, 22 February 2022 (UTC)
  • Footnote per OP, Crossroads and Izno. WP:UNDUE weight to trivia. I really think that the best solution is to use a explanatory footnote, but just when it is necessary. Alexcalamaro (talk) 22:09, 1 March 2022 (UTC)
  • Hatnote I find the arguments against footnotes more compelling than the arguments for footnotes. To me, the argument over the wording of WP:HATNOTE isn't compelling and seems like wikilawyering over the wording of policy rather than engaging with what's practical---if the OP's interpretation is correct, why have hatnotes endured for a decade? The OP claims that it's trivial information which doesn't serve a navigation purpose, but I don't agree with that interpretation. Joseph2302 says it's an important detail which often explains inconsistencies in the article between people's full and common names, which to me contradicts the claim that name style hatnotes don't serve a navigational purpose. They do. Our articles are titled after names, and clarifying how that name is styled can clarify article titles which may or may not follow the English COMMONNAME. The OP's argument seems self-contradictory as well; it claims that surname hatnotes give undue emphasis, but also that no one reads them because fo banner blindness. If no one is reading them, then it's not a prominent or undue position; if it's prominent and undue then people aren't blind to them. I don't think either is really the case, certainly not a serious problem, and I'd be open to evidence suggesting that one of these is in fact the case, but arguing both seems self-contradictory. Lastly, the argument to put them in a footnote runs into actual practical problems. First, no one reads that far down the page. Second, not all articles have them. We'd be forcing level-2 heading sections on thousands of articles for a single footnote that no on will read. Why? To create artificial consistency with a policy we could just rewrite to reflect the practical reality? Seems contrary to WP:NOTBURO. People have made various proposals to try and remedy this problem, like parentheticals and putting it in infoboxes, but these have their own problems and run into the same issue as the original proposal: the problem with hatnotes is bureaucratic not practical. The closest we get to a practical issue is banner blindness, but there's no particular evidence for that and other support arguments about undue prominence contradict claiming that point. Just rewrite the policy to fit the decade-old reality. Let writers use the efn surname templates if they like, but enforcing an artificial consistency at this point is premature. — Wug·a·po·des​ 22:05, 3 March 2022 (UTC)
    I responded to the idea we should just adapt WT:HATNOTE to match usage above here. I don't see any contradiction in discussing both prominence and banner blindness—banner blindness by definition happens when too much is made too prominent. {{u|Sdkb}} talk 01:42, 4 March 2022 (UTC)
  • Edit notice – This will probably disappear in the void of this conversation, but I don't think either solution is helpful. The reason this is even an issue is because novice editors (or anons, or otherwise) go and change the name, thinking they're correct. This group of people will almost certainly never read the footnote (which you have to "go out of your way to click"), and it seems very possible that they will ignore the hat note by clicking edit too quick or editing a section not near the top of the article. The only place we know they will go to is the editing screen, so we may as well put it there. Aza24 (talk) 01:56, 4 March 2022 (UTC)
    @Aza24, not lost in the void The reader-editor distinction is an interesting angle to look at this from, and the editor perspective might help explain why some above seem to consider this information so crucial. I think it does still have some value for readers, so perhaps a footnote-editnotice combo could be a possibility. {{u|Sdkb}} talk 07:19, 4 March 2022 (UTC)
  • Footnote as proposed. While this is may not be a perfect solution, we should move on from hatnotes as they occupy an undue position for such trivial information. -- Ab207 (talk) 15:49, 6 March 2022 (UTC)
  • Footnote. The current hatnoted-based system is very out of step, I think, with how hatnotes are meant to be used: for navigation. I find Crossroads's arguments very compelling as well. -BRAINULATOR9 (TALK) 19:12, 19 March 2022 (UTC)

Discussion (surnames)

A |surname= parameter could also be added to {{Infobox person}}. Or guidance should be given to note the surname under the template's "Notes" section. 71.247.146.98 (talk) 12:46, 3 February 2022 (UTC)

I agree that this information belongs as structured data in the {{Infobox person}}. Tvquizphd (talk) 03:25, 4 February 2022 (UTC)

Tvquizphd and IP, how would you want it to display in an infobox? Make a sandbox mockup if you'd like. I'm not sure how viable that could be as a main method, though, since infoboxes are already trying to cram in a lot of information, and not all articles have them.
If we're exploring alternatives, I think Mathglot's idea of putting it in the parenthetical is the most viable I've heard so far. The advantage is that it'd place the information in the body, in a space that's already communicating name info (typically pronunciation). The disadvantage is that we'd only be able to reasonably fit a very short e.g. (surname: Lee), which would cause problems for the more complicated examples like Raul Neto above or Vietnamese people like Phan Xích Long. {{u|Sdkb}} talk 03:42, 4 February 2022 (UTC)
  • The idea of developing this as Infobox information is appealing. It would match the Wikidata P734 family name, which is present for cases such as Sima Qian, Gáspár Miklós Tamás and other interesting cases such as Jan Vennegoor of Hesselink (see also this on the latter's doubling), but seems to be omitted for patronyms that might be associated with Mongolian people,for example. Populating an optional line in Infoboxes from Wikidata could allow a gradual move away from the use of hatnotes and towards more structured information which might embed types of naming? AllyD (talk) 08:44, 4 February 2022 (UTC)
Perhaps it can display in parentheses after or below |name=. An example would be:
|name=Name (Surname: |surname=Surname)
To display
Name (Surname: Surname)
Note variable values are slanted as a coding convention.
Or a structured note under |Notes= can be used.
Also there is the issue of meta-templates & related templates based on the infobox. A look at Category:People and person infobox templates shows a bunch. 71.247.146.98 (talk) 13:49, 4 February 2022 (UTC)

@Retswerb: I appreciate you bringing up the topic of bias in your !vote. One angle to look at this from is that the hatnote convention includes some strong biases about what readers know and don't know. We would never (and should never) put a hatnote at John Smith saying "the surname is Smith", since we assume that readers are familiar with Western name order, but we also assume that they're unfamiliar with Eastern name order and need this explained to them prominently. Granted, on a practical level, this is English Wikipedia and our efforts to take a global perspective need to have some limit. But I think it's worth noting that one benefit of making the clarification less prominent is that it'd also make these names less marked, meaning that we wouldn't be assuming so strongly that readers have a Western perspective in which non-Western names are this exotic other. {{u|Sdkb}} talk 07:45, 4 February 2022 (UTC)

  • Surnames in an unfamiliar position is probably the easiest name hatnote situation to solve. Other naming conventions, such as patronymics, or perhaps having no surname, seem more difficult to clearly imply through usage in prose alone. Is this proposal aimed at removing Surname Firstname hatnotes, but leaving other Family Name hatnotes in place? CMD (talk) 07:57, 4 February 2022 (UTC)
    @Chipmunkdavis, any naming convention hatnote can be pretty easily converted to a footnote: just take the text in the hatnote and put it in a footnote. The same general considerations apply.
    I think that it's important that we're able to handle edge cases in whatever system we end up with, but I also think we should take care not to focus so much on the most complicated instances that we lose the forest for the trees, as I see happening a little above. It's also worth remembering that this information is going to seem a lot more important here where we're hyperfocused on it than it will in the context of an actual article where it's one of many things to arrange in balance. {{u|Sdkb}} talk 08:09, 4 February 2022 (UTC)
    It does not make sense (and feels like a bit of the bias Retsweb mentions) to treat patronymics and single names as edge or particularly complex cases; they are established and regularly used naming systems. They might be unfamiliar to some or most English speakers, but they're whole forests in themselves. Framing a discussion as relating just to surname firstname order when it is intended to have a wider impact seems likely to lead to more confusion, not less. Footnotes may work for whatever the case is, but other suggestions above that were built in response to the framing of the question, like the "(Surname: Lee)" and the infobox surname parameter, will simply not work. CMD (talk) 08:24, 4 February 2022 (UTC)
    @CMD It would be nice if the Template:Infobox person could accomodate many naming conventions with many options |surname=, |matronym=,|patronym=, |tekonym=, |laqab=, |nisba=, and even perhaps |mononym=. Some examples might look like |surname=Lee or |mononym=triyatno. If no infobox or too much infobox, I think a simple parenthetical "(Surname: Lee)" or “Triyatno (mononymous, born 20 December 1987)” would do. I’ll post on Project Anthroponymy to see if anyone there has ideas.Tvquizphd (talk) 17:07, 4 February 2022 (UTC)
    I would not object to that. If it is done, perhaps the relevant wikilink could serve as the communicating text to the reader in place of the hatnote. CMD (talk) 17:59, 4 February 2022 (UTC)
Entirely a fair point! My personal take is that our general readership is probably unfamiliar enough with non-Western naming conventions that the value of pointing them out overcomes the detriment of marking them - but that's entirely an assumption on my part. Retswerb (talk) 08:08, 4 February 2022 (UTC)
The occasional Western surname also needs a note: Emile Smith Rowe (surname Smith Rowe) vs. Leo Stanton Rowe (surname Rowe). Certes (talk) 16:56, 4 February 2022 (UTC)
I'd welcome an explanatory note at Marion Zimmer Bradley. Never sure what end of the bookshelf to use for her books. —Kusma (talk) 18:28, 4 February 2022 (UTC)
  • I'm slightly confused here. The opening comment etc refers only to surnames. But the template also deals with patronyms although for some reason we still have stuff Template:Malay name. Is this proposal only to deal with surnames? Also the opening comment claims "because we refer to a person by their surname throughout an article" but again that is not the case. We use whatever is the norm to refer to the person so for people without surnames this is often (but not always) their given name. Also we should not forget that even for people with surnames, name order can be more complicated than simple family name given name, given name family name e.g. Carrie Lee Sze Kei, Michelle Yeoh Choo-kheng or Daniel Lee Chee Hun. Nil Einne (talk) 06:45, 7 February 2022 (UTC)
    @Nil Einne: Yes, I can validate that confusion. In fact, I don't think this is really about surnames at all; I believe it's about how to refer to someone via a short name (if any) throughout the article, when we are not referring to them by their long, convoluted name, as in Sandy's example of Thor Leonardo Halvorssen Mendoza.
    Imho, we don't really care which is the father's name, mother's name or any of that; what we care about, is how they are referred to "for short". This is cleared up in sentence #2 of that article, and the answer is: Halvorssen. Who cares which ancestor bore that name? I don't. In such articles as importance would attach to knowing about their mother and father, because it's duly covered by reliable sources, than by all means, go into it in the body of the article, and even link our articles (not hatnotes!) about Hispanic surnames as appropriate. But I see no reason why the Thor Halvorssen (human rights activist) article needs a hatnote, and I don't care what his surname is. The #Background section explains in some detail his relationship to famous ancestors including a President Mendoza, and for anyone who's interested, they can read that, and follow the links. But all we really need to know about Thor Leonardo Halvorssen Mendoza's name, is that he is referred to as "Halvorssen" in the article, presumably because that's what the sources do. I don't see why a hatnote would be required at all, or even helpful. By the way, what is Sitting Bull's surname? Mathglot (talk) 23:41, 7 February 2022 (UTC)

    One more thing that occurs is that in some cases, the current family name template actually servers another purpose although I'm doubtful many readers understand this who didn't already know. If we take Chinese names like Lee Hsien Loong and Chong Sin Woon, it mentions the generation name. This isn't of relevance to how we refer to the person in the article since we use the family name but it conveys an important point.

    If you are referring to these people by their given name, it should be Hsien Loong or Sin Woon, never Hsien or Sin. While this applies to most two character Chinese given names too (double characters is sort of exception I guess), it's a special problem with generation names because calling someone Hsien/Sin or Hsien Lee/Sin Chong (as may happen in the west, even if you put the first name as Hsien Loong/Sin Woon in the form) can be confusing when multiple siblings are involved as it's unclear precisely who you're referring to. (If you did want to use one character only Woon or Loong will me more appropriate.)

    This is mostly a problem with Malaysian and Singaporean given names as it's where the practice of rendering the two characters as two "words" with spaces predominates. Those from Mainland China generally follow pinyin and don't include a space; those from Taiwan and Hong Kong, and while not Chinese names, those from (either) Korea where there's a similar issue, generally use hypens. Those in Western countries mostly use either don't include a space or use hypens since they're aware of the problem if they don't.

    That said, the generation name parameter seems to be hardly ever used (those were the only 2 examples I could find with a space in the given name) and I think it's hard to populate especially without OR since not all 2 character given names include a generation name. Also as said, this is an issue which technically applies to all 2 character Chinese give names even in cases where it's not a generation name; and I'm very doubtful anyone reading our hatnote is going to understand this point if they didn't already know from the name.

    And there are plenty of other naming issues which can cause confusion which we do not clarify in each article. For example Karpal Singh was not Muslim and while his name may sometimes be referred to as Karpal Singh al Ram Singh the al is from a/l and is unrelated to the al in Arabic names. (Having trouble finding links talking about this now, but in the past, there were reports of people coming under special scrutiny because their passport rendered the a/l as al since / cannot be used in the name part of machine readable passports and assumptions were made that the al meant they were Muslim. I suspect this is one reason why that is no longer done [4].)

    Nil Einne (talk) 00:30, 8 February 2022 (UTC)

    @Nil Einne: (edit conflict) This is more of an aside, but the generation name param |suffix= is used in template {{Portuguese name}}, which was sufficiently different due to this very param, that that template did not get merged into the {{Family name}} template when the mega-merge took place. There are 90 occurrences of the template that use param |suffix=. Mathglot (talk) 01:05, 8 February 2022 (UTC)
    Just pinging User:Primefac to this discussion and proposal, as they were responsible for the family name hatnote mega-merge, and may have something to say either about the somewhat narrower issue in this discussion, or the larger one at the top of this proposal. Mathglot (talk) 01:28, 8 February 2022 (UTC)
    Taking into account Mathglot's comments, would a "commonly known as" property be more apt? Or is this making the issue even more convoluted? 68.173.76.118 (talk) 02:04, 8 February 2022 (UTC)
    As a reply to the ping - I genuinely don't care how this information is displayed (my prior involvement has largely been in standardising template usage and minimising maintenance burdens). If necessary, though, I'm happy to consult on the hows, whys, and "what ifs" so that others may make a better decision. Primefac (talk) 09:23, 8 February 2022 (UTC)
  • Suggestion. Okay, this is going to sound absolutely buck-wild, so I am going to drop this radical idea and walk away: use {{Notice}}. I know; I know.. This is heresy. I'm talking something small like this. Not going to make any arguments for this suggestion since I know it's one of those things that will probably appease zero sides of this discussion. If I'm wrong, then let me know. –MJL ‐Talk‐☖ 19:21, 15 February 2022 (UTC)
    Alas, I think you're correct that that wouldn't appease anyone. My whole goal here is to decrease the prominence of the information to something more commensurate with its importance, whereas that would increase its prominence. {{u|Sdkb}} talk 19:30, 15 February 2022 (UTC)
I guess this is a vote for hatnote presentation in some form. I am a bit confused as to why user MJL considers it "radical". 74.72.146.123 (talk) 19:04, 19 February 2022 (UTC)
Actually, I think something like this could be an excellent way forward, provided the notice is floated to the right, like Template:IPA notice. This would be similar to the way natives names for Buddhist concepts are currently formatted using a dedicated template (example of use: Four Noble Truths). – Uanfala (talk) 20:46, 19 February 2022 (UTC)
  • Suggestion I agree that knowing the surname can be helpful for understanding the article (and less importantly for editing the article when there is inconsistent usage). Adding to the infobox doesn't seem practical since they are not required, and there are over 150 different templates that are used on biographies. Coordinates are displayed at the very top right, and that space should always be available in a biography article. What if we use that space for a very short note (e.g. "Subject shortname is foo[a]") with a footnote link allowing the full explanation to be provided in a footnote. I don't know if "shortname" is the best way to collectively refer to all the variations that have been mentioned here, but the concept is to use both a brief hatnote-like statement of the shortname with an explanatory footnote. MB 22:53, 19 February 2022 (UTC)
    I really like this idea, or something similar that might provide a third way. Retswerb (talk) 00:51, 20 February 2022 (UTC)
    Just want to point out that looking cursorily, it seems that many of the person infoboxes are meta- or wrapper templates for {{infobox person}}. In such cases, adding a surname parameter to the core code would make it generally available. 104.247.55.106 (talk) 14:21, 20 February 2022 (UTC)
    Many are also wrappers of {{infobox sportsperson}}. Yes, updating the core code would make it available to the wrapper template, but each of them would still need an update to use it. MB 19:00, 20 February 2022 (UTC)
    That's an interesting idea and I can imagine that it can be made to work. But the text will need to be visually more prominent (say, surrounded in a box), otherwise, I'm sure that most readers won't think to look at the tiny text in the top-right corner for that sort of information. – Uanfala (talk) 23:12, 26 February 2022 (UTC)
  • I'll throw out another, perhaps more creative type of possible solution. This comes from what I've observed sports broadcasters tend to do, e.g. here/here, which is to use capitalization. In our implementation, this could come through smallcaps, e.g. this, or even a combination of smallcaps and tooltips, e.g. this. I'm curious what folks think of these, as my read of the discussion above so far is that few editors see hatnotes as the ideal solution but many also don't like footnotes. {{u|Sdkb}} talk 22:18, 23 February 2022 (UTC)
    There's no accounting for taste, but I find the caps solution very unappealing aesthetically. These pages will stand out as a sore thumb imo, and applying this format will probably necessitate changes to several established MOS guidelines. 71.105.141.131 (talk) 01:53, 24 February 2022 (UTC)
    Another interesting idea, but I'm not sure I can imagine people accepting it. It's also not going to work well in all cases (what do you do with Slavonic patronymics?) and if in the end we're going to rely on footnotes (or tooltips) this brings us back to the start of this discussion. – Uanfala (talk) 23:12, 26 February 2022 (UTC)

Move protect user namespaces

withdrawn but left open for discussion; see below Ivanvector (Talk/Edits) 18:35, 17 March 2022 (UTC)

To stop a common form of schoolyard vandalism, I propose we move-protect all pages in the User: and User talk: namespaces, so that they can only be moved by the owner of the userspace, or by pagemovers/admins. Thoughts? Ivanvector (Talk/Edits) 20:28, 16 March 2022 (UTC)

  • Wasn't this recently discussed somewhere? They will only move articles, or pages like this instead. I'd prefer they make their mess in userspace. -- zzuuzz (talk) 20:31, 16 March 2022 (UTC)
    Yeah, I kind of have a feeling it's something I had suggested before, but not exactly this way, or not this board, or I don't know what. I don't remember where it was or what the outcome was, but the vandalism still happens so I guess it wasn't implemented. I think it was brought up before that the vandals would just move articles instead, but I've move-protected a lot of vandalized user pages without seeing an uptick in article move vandalism to go with it. It seems to me to be more like targeted harassment than random vandalism. Ivanvector (Talk/Edits) 20:39, 16 March 2022 (UTC)
    Previous discussion. -- zzuuzz (talk) 21:15, 16 March 2022 (UTC)
  • I concur strongly. I can't think of a reason not to, although I'm somewhat dim at times. ScottishFinnishRadish (talk) 20:34, 16 March 2022 (UTC)
  • I can see arguments for and against. On the one hand, we usually protect pages only if they've been attacked or if vandalism would cause havoc (Main Page, Template:Infobox…) On the other hand, I can't think of a single good reason why I should be moving your user pages around. We might want to close any loophole that permitted a vandal to move an article to User:Foo/Lulz with only an admin able to move it back. Certes (talk) 20:57, 16 March 2022 (UTC)
  • Would've prevented me from making a fool of myself earlier, which would've been nice. Well, at least we got T304008 out of it.
    One problem I can see with this, though, is trying to move a user's article draft out of their sandbox, either to the draft space or to article space. I know that's what the draft space is for, but I think (without hard evidence) this is still a common enough use case to be worth considering. Writ Keeper ⚇♔ 21:02, 16 March 2022 (UTC)
  • The only issue I can think of would be if a user gets renamed. I don't think global renamers are pagemovers or admins by default. If we move-protect all pages in the User: and User talk: namespaces for those who are not the owner or pagemovers/admins by default then that can cause some issues if someone is being renamed. ― Blaze WolfTalkBlaze Wolf#6545 21:02, 16 March 2022 (UTC)
    This used to be a problem, see phab:T212082. That should be fixed now; a global rename operation should bypass all filters. Suffusion of Yellow (talk) 21:16, 16 March 2022 (UTC)
    Correct me if I'm wrong but, the proposal is to protect those namespaces except for those specific users which isn't a filter. Unless the proposal is basically proposing a new filter to be created. ― Blaze WolfTalkBlaze Wolf#6545 21:22, 16 March 2022 (UTC)
    But how? The only other mechanism (without a major software change) would be the WP:TITLEBLACKLIST, and that can't exempt the "owner". Suffusion of Yellow (talk) 21:26, 16 March 2022 (UTC)
    shrug I don't usually do any software related stuff so I wouldn't know. Upon writing my previous I Did think that if we were taking this literally it would require creating a separate user group for each individual user so that the protection will be applied so that only the user in their own group would be able to edit, which would be really complicated and probably take up a lot of space considering how many users there are. ― Blaze WolfTalkBlaze Wolf#6545 21:32, 16 March 2022 (UTC)
    There must be some sort of hook in the code, as I can edit my own /common.js but other unprivileged editors can't. (And I'm really hoping that I can't write some malware elsewhere then move it to User:Victim/common.js!) Extending it would need a software change, though. Certes (talk) 22:14, 16 March 2022 (UTC)
    Yes, the "special" rules for user JS and CSS are basically hard-coded into MediaWiki core. Suffusion of Yellow (talk) 22:16, 16 March 2022 (UTC)
    So in theory it is possible to make it so userpages can only be edited by the user and other users since something similar is done with the JS and CSS pages. I say in theory because there might be something that causes this to not be possible (ignoring all the issues this would cause with legitimate moves from out of userspace). ― Blaze WolfTalkBlaze Wolf#6545 22:22, 16 March 2022 (UTC)
    Sure, in theory lots of things could happen - the usercss/userjs was considered important enough to update the software for every project that uses mediawiki; this possible bespoke protection system for one project may not - leaving us to possibly deal with it using the abusefilter. — xaosflux Talk 00:06, 18 March 2022 (UTC)
  • Is the proposal to also disallow moving subpages? I can think of valid reasons for that; e.g. publishing a draft. Suffusion of Yellow (talk) 21:17, 16 March 2022 (UTC)
  • One consideration with any proposal to create a protected namespace is what happens when pages are moved to that space. If moves to that space were prohibited, transferring an essay/article to user space could only be done by admins. If they were allowed, vandals could move articles to user space and only an admin could restore it. Although they might not be deal-breaking issues, the question to answer is if these and similar issues would be more or less hassle than the problem being solved by blocking moves in the user namespace. isaacl (talk) 21:43, 16 March 2022 (UTC)
  • Occasionally, I move drafts written on the userpage into draftspace. ― Qwerfjkltalk 22:00, 16 March 2022 (UTC)
  • Oppose, if moving from user pages is restricted, we also need to restrict moving to user pages; otherwise anyone moving an article into userspace could only be reverted by people with higher permissions (and then "userfying" would also require more permissions). We should just revert, block, ignore the vandals, not lock everything down to prevent all vandalism, as that also has unintended consequences for non-vandals. —Kusma (talk) 22:13, 16 March 2022 (UTC)
    In particular, a user who accidentally moves a page into a different user's userspace (which can easily happen) should not be prevented from self-reverting. —Kusma (talk) 22:29, 16 March 2022 (UTC)
  • Ummmmm..... @Ivanvector: thanks for thinking of things, when you say this is a common form of schoolyard vandalism, would you please quantify that some? I queried the last 5000 moves, going back about 1 year; filtering out only ones where the source was User:* and excluding account renames and a single odd batch by one admin, this leaves only 296 total moves. They can be seen here: Special:PermaLink/1077548981. I'm not seeing rampant vandalism that we should invest new technical controls in. Please let me know if my data looks wrong. — xaosflux Talk 22:17, 16 March 2022 (UTC)
    If I can provide a relevant example of the day, it's Minwu. You can add Docria1 for context. The discussion I linked above was based on a few similar examples, and you see it every now and then. I would note we have 294 (hist · log), which might appeal to some as an approach to the issue, although protection of targeted pages would work as well. -- zzuuzz (talk) 22:40, 16 March 2022 (UTC)
    Thank you, correction on my stats up there, those certainly don't go back a year that is "of the last 5000 moves", going back about 5 days. — xaosflux Talk 22:44, 16 March 2022 (UTC)
    (I didn't catch User_talk: either). Though, @zzuuzz Docria1's page moves were of an article, so aren't really in scope here? — xaosflux Talk 22:46, 16 March 2022 (UTC)
    They're the same vandal and the same problem, though as you say the namespace is different. I'd suggest this places them entirely within scope of this discussion (at least from my point of view). -- zzuuzz (talk) 22:50, 16 March 2022 (UTC)
    Well, a vandal moving articles is a different situation from ones that only move userpages - if this problem is about restricting all moves its a much bigger scope. — xaosflux Talk 23:17, 16 March 2022 (UTC)
    I think my point would be, as I said above, that if they couldn't move a user page, then they'll just move an article instead. -- zzuuzz (talk) 23:25, 16 March 2022 (UTC)
  • Occasionally, I move drafts written on the userpage into draftspace. ― Qwerfjkltalk 07:13, 17 March 2022 (UTC)
    @Qwerfjkl: You wrote that exact comment at 22:00, 16 March 2022 (UTC). --Redrose64 🌹 (talk) 19:28, 17 March 2022 (UTC)
    @Redrose64: Oops. I think CD saved the edit, but didn't update [whatever else it updates], so I just posted the comment again when I looked at this page. ― Qwerfjkltalk 20:26, 17 March 2022 (UTC)
  • There's quite a lot of moving userspace "quasi-drafts" to draftspace that is done atm by non admins/PMs, especially as part of the AfC workflow. Nosebagbear (talk) 10:04, 17 March 2022 (UTC)
    Shouldn’t the moving of a “quasi-draft” from userspace into draftspace be done by the user who created it in their userspace? I know I would object if something I had been working on in my userspace were moved by another editor without my ok. Blueboar (talk) 11:37, 17 March 2022 (UTC)
    I agree with Blueboar. There are only three reasons I can think of for ever moving any page out of userspace without the consent of that editor:
    1. The page was improperly moved there (e.g. page move vandalism)
    2. The page was accidentally moved there (e.g. typo or misclick when moving the page)
    3. There is a consensus in a RM or a similar discussion to move the page. Thryduulf (talk) 12:12, 17 March 2022 (UTC)
    There are a lot of drafts that are created as people's userpages, especially by complete newcomers. It is absolutely fine to move such pages, either to article or draft space as appropriate (often, the user can't even do it themselves, as they are not autoconfirmed). Locking this down prevents very little vandalism (and probably just displaces it to an area where the vandal will do more harm) while impacting legitimate workflows. —Kusma (talk) 12:53, 17 March 2022 (UTC)
    Why is it fine to move a draft from userspace to elsewhere without the user's consent? Note there is no requirement to use draftspace for drafts, regardless of how new an editor is. Moving a draft from user:Foo to user:Foo/draft is not relevant here (as that's moving a page within someone's userspace no out of it), submitting a draft for publication (formally or informally) is consent for the page to be moved to article space and obviously requesting a page be moved (for any or no reason) is consent for the page to be moved. I agree that the proposed automatic protection would cause more harm than good, my comments are trying to ascertain why one of the things it would prevent is regarded as legitimate. Thryduulf (talk) 13:05, 17 March 2022 (UTC)
    "Drafts" aren't the only thing that could be in a userspace; page move vandalism is an easy thing to say could be in userspace. I don't think a situation where anyone can move a page TO their userspace, but only a small group of users can revert that is a great idea. — xaosflux Talk 13:28, 17 March 2022 (UTC)
    It would certainly give a huge advantage to one side in, say, move wars about whether some essay should be in user space or in Wikipedia space. —Kusma (talk) 13:44, 17 March 2022 (UTC)
    @Xaosflux indeed, I'm not in favour of this proposal but I'm still waiting for someone to explain why moving a page outside of userspace without that user's consent is appropriate outside of the three situations above (move warring and reverting an undiscussed move would come under point 1). Thryduulf (talk) 17:13, 17 March 2022 (UTC)
    @Thryduulf I can think of numerous situations that fall under "user has left the project". How about a case like: User:User/Sandbox/DraftArticle - where the draft article was collaboratively worked on and the other authors wants to move it to an article? — xaosflux Talk 18:07, 17 March 2022 (UTC)
    When the user submits it as a draft using {{subst:submit}}? ― Qwerfjkltalk 18:14, 17 March 2022 (UTC)
    @Qwerfjkl submitting a draft is, as I said above, is consent for the page to be moved to article space. I can't think of a reason why it would need to be moved to a different namespace without their consent?
    @Xaosflux hmm, if that happens often enough to be more than an occasional thing (c.f. WP:IARUNCOMMON) then a fourth criteria of "user is clearly no-longer around" would cover it. If a draft is being collaboratively worked on then it's likely that there will be consensus among those working on it to move it to article space/submit it when ready. If the owner (for want of a better word) is one of them then they will be giving their consent to moving as part of this, if they aren't part of that discussion then point 3 would likely apply. Thryduulf (talk) 18:25, 17 March 2022 (UTC)
    Category:Pending AfC submissions in userspace mentions moving userspace drafts to draftspace. ― Qwerfjkltalk 18:32, 17 March 2022 (UTC)
    @Qwerfjkl any idea why that instruction exists? It seems completely contrary to the use of draftspace being optional. I can understand moving User:Foo/Sandbox to User:Foo/Subject, especially if the draft is accepted, but there seems to be no reason or obvious benefit to moving to draftspace? Thryduulf (talk) 00:04, 18 March 2022 (UTC)
    @Thryduulf digging through the template codes, the Category:Pending AfC submissions in userspace is populated only when the draft in userspace is submitted for review. – robertsky (talk) 00:33, 18 March 2022 (UTC)
    That doesn't explain why the instruction to move the page though? I can't think of any reason why the content of a draft would be different just by moving namespace? Thryduulf (talk) 00:36, 18 March 2022 (UTC)
    Well, personally, I have no qualms editing other people's drafts in draftspace to improve the drafts (on top of processing the submission), but I do have editing in other's userspace without first asking for permission. I guess it's all about perceived/implicit permission to edit (in draftspace) vs asking for permission to edit (in userspace. WP:NOBAN: In general, one should avoid substantially editing another's user and user talk pages, except when it is likely edits are expected and/or will be helpful. If unsure, ask. If an editor asks you not to edit their user pages, such requests should, within reason, be respected. （emphasis mine). But not all editors may follow up on their talk page, for one reason or another. So, do we just let the draft in userspace languish, or have the drafts be improved in the draftspace after submission? – robertsky (talk) 00:55, 18 March 2022 (UTC)
    People don't WP:OWN their userspace. You should be allowed to WP:BOLDly update and then submit abandoned drafts by deceased editors. Most of the times, it is not the polite thing to do to mess with other people's userspace, but that doesn't mean outlawing it improves things. —Kusma (talk) 13:42, 17 March 2022 (UTC)
    People do sort-of own their userspace, to an extent (although certainly not completely). Abandoned drafts by deceased or long-departed editors would be exactly the sort of thing WP:IAR is intended for (once again I'm not supporting to allow only admins and page movers). In other situations get consent or consensus first. Thryduulf (talk) 17:17, 17 March 2022 (UTC)
  • Weak oppose. I see the advantages but there are legitimate moves such as User:Foo/Article → Draft:Article, it can make other bad moves hard to undo, and it may drive vandals to make more damaging and less visible moves. Instead, would anyone monitor a regular report of moves of other users' pages? It could exclude legitimate-looking cases either by nature (target in Draft:) or by user (don't report admins, page movers, etc.). Certes (talk) 11:59, 17 March 2022 (UTC)
  • 'Oppose, it is a default part of the AfC workflow to move all submitted drafts out of userspace into draftspace. If the draft was submitted from, say, the sandbox, it's impossible for reviewers scanning AfC submissions to tell what it's about; having it at Draft:Title is much clearer. I've also moved drafts from user and talk pages. Rusalkii (talk) 17:06, 17 March 2022 (UTC)
  • Oppose. Nobody should be routinely moving pages out of userspace without consent of that user, but there are exceptions (improper moves to userspace, accidental moves to userspace, and consensus) that happen often enough to make this problematic. It would also make moves more difficult when the editor does consent (e.g. submitting a draft). Thryduulf (talk) 17:20, 17 March 2022 (UTC)
    I might support prohibiting non-autoconfirmed editors from moving pages to or from other editors' userspace (unless they were the ones to move it there to cater for accidental moves), but I don't know if this is something that is possible (my uninformed guess is that it isn't without some serious software work). Thryduulf (talk) 17:23, 17 March 2022 (UTC)
    Errr... non-autoconfirmed editors can't move pages, regardless of namespace. --Redrose64 🌹 (talk) 21:56, 17 March 2022 (UTC)
    I completely forgot about that. Doh! Thryduulf (talk) 00:00, 18 March 2022 (UTC)
    I generally agree with that, and perhaps the Wikipedia:User pages guideline can be improved. — xaosflux Talk 18:10, 17 March 2022 (UTC)
  • Withdrawn - I think everyone's made good points about why this is either not technically feasible or just not a good idea in general. I'm not closing because some of you are having interesting side discussions and not everything needs to be formally closed. Just on a point that was brought up about the "common-ness" of this vandalism: I don't think we should expect to see patterns of vandalism when we look at all contributions over a time period, we already know that vandalism is a tiny proportion of all editing, and trying to isolate one particular form of vandalism out of that tiny proportion is like finding a needle in a much larger stack of needles. I guess I meant "common" in the sense that it's common among the various LTAs who are known to target specific users they perceive to have done them wrong. I don't think it's a very common form of random vandalism. Everyone who said so is probably right that if we suppress this form of harassment they'll just find another way that might be even more disruptive, and just protecting the pages of users who are known to be targets is probably just as good as making it a software restriction. Thanks for the comments. Ivanvector (Talk/Edits) 18:35, 17 March 2022 (UTC)
    @Ivanvector - there could still be some room for improvements in things, namely if there is something more targeted for edit filters (drop examples at WP:EF/R and someone can evaluate the use cases), and a tangent this discussion went in was about what is generally inappropriate, but not outright vandalism, regarding moving of user (sub)pages -- WP:USERPAGE guideline updates could be in order. — xaosflux Talk 18:49, 17 March 2022 (UTC)
  • Comment - I agree that move protection would be overkill (for this problem) but I definitely believe that the user should receive a notification when someone moves a page from their user space. When it happened to me, I was surprised that I wasn't notified; T296955 was initiated to fix this, but it may be quite a while before anything happens. Best regards.--John Cline (talk) 21:04, 21 March 2022 (UTC)
    I hope that almost all user-space pages are on the user's watchlist, which would be sufficient, except that many editors with user pages are inactive. Certes (talk) 21:31, 21 March 2022 (UTC)
    If I am active when someone happens to edit or move a subpage in my user space, I am pretty sure that I would notice the activity. If I am not active, I am equally as sure that I probably will not. From my perspective, the watchlist is insufficient; I maintain my belief that a notification should be sent. Sincerely.--John Cline (talk) 22:18, 21 March 2022 (UTC)

Universal Code of Conduct Enforcement guidelines ratification voting period will close 23:59 UTC on 21 March 2022

Voting is closed. — xaosflux Talk 14:09, 22 March 2022 (UTC)

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 ratification voting process for the revised enforcement guidelines of the Universal Code of Conduct will conclude on 21 March 2022 at 23:59:59 UTC.

I shared some voter turnout data here: Wikipedia:Village pump (policy)#Update on Universal Code of Conduct Enforcement guidelines ratification vote (as of 20 March).

Please share the information links with interested users: Project Overview • Universal Code of Conduct • Enforcement guidelines (proposed) • Voting • Voter information

The poll can be accessed via w:en:Special:SecurePoll/vote/802 or m:Special:SecurePoll/vote/391. Xeno (WMF) (talk) 02:00, 21 March 2022 (UTC)

A configuration problem which broke some voting links has been fixed. Anyone who tried and failed to vote about 12 hours ago should try again now. Certes (talk) 12:33, 21 March 2022 (UTC)
Thanks Certes; about your other query: the poll will close at 23:59:59 (UTC) today, which is I guess technically "until" the 22. This confusion was discussed at watchlist messages with xaosflux. Perhaps the time should be added? Xeno (WMF) (talk) 12:49, 21 March 2022 (UTC)
The 'landing page' for our local WLN is meta:Universal Code of Conduct/Enforcement guidelines/Voting, neither it, nor the central notice have anything about time of day on it; 'until' should suffice on this project. If you really want to globally push that time of day information there are many other places to start. — xaosflux Talk 13:05, 21 March 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Wikipedia is a tertiary source

Should this page be an essay page, a supplemental page, or an information page? This can't be policy or guideline, as it was proposed back in 2016 on this articles talk page, but many users opposed. AKK700 03:35, 22 March 2022 (UTC)

It doesn't seem the page has any original information to justify active status. 74.64.150.19 (talk) 11:26, 22 March 2022 (UTC)
Seems fine where it is. Labeled a failed proposal. It can not be labeled information or supplemental under those conditions.Slywriter (talk) 11:35, 22 March 2022 (UTC)
On the rare occasions when Wikipedia legitimately cites itself as a source then it's primary rather than tertiary, so the page must be about reading Wikipedia and citing it elsewhere rather than editing. Policies, guidelines, information and supplementary pages are generally aimed at editors, so it's none of those. It may belong with other help on how to read Wikipedia. There's not much of that, as reading is generally a simple and obvious process, but examples include the intricacies of search syntax. Certes (talk) 11:50, 22 March 2022 (UTC)
Leave it exactly as it is. It is listed as a failed proposal. That looks good to me. --Jayron32 11:56, 22 March 2022 (UTC)
See also Wikipedia:Not every page needs a tag (which, despite the short page being entirely about the non-importance of tagging 'backstage' pages, sometimes grows a tag at the top of it).
I'm glad that WP:WITS failed, because the "one step removed" definition of secondary sources has created a lot of confusion. Editors interpreted "one step removed" as meaning that secondary and independent were the same ideas – "one step removed" being (mis)understood as the source being an independent journalist or other author at arm's length from the subject, rather than "one step removed" (correctly) meaning that pre-existing sources were being transformed into a new work of analysis, commentary, etc. Wikipedia:Independent does not mean secondary. WhatamIdoing (talk) 20:00, 22 March 2022 (UTC)

Optional thanks message, as gadget

Withdrawn by proposer. — xaosflux Talk 09:34, 23 March 2022 (UTC)

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.

Shouldn't allow for more than 50 characters, but i'd like to be able to say, like, "whoops, sorry about that!" in a thanks message instead of just "thanked". Not for everyone, but I'd like the option- talk messages are just very cumbersome. theleekycauldron (talk • contribs) (she/they) 01:31, 22 March 2022 (UTC)

@Theleekycauldron this is not technically possible, the Thanks extension does not support messaging at all - so a gadget would not be able to be used to help send this. You could follow up at mw:Extension talk:Thanks but I doubt this will take off the way you envision: Where would this message go? How would disruptive messages be handled? It could be possible to make a gadget that takes an input, and then posts it to a user's talk page - which also would need to be invented. I suggest you move this to WP:VPI as there is no actionable proposal here. — xaosflux Talk 14:08, 22 March 2022 (UTC)
all righty- i guess not, then. cheers! theleekycauldron (talk • contribs) (she/they) 22:02, 22 March 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Logo for Nogai Wikipedia

Wrong venue, I recommend moving this to Commons:Graphic Lab/Illustration workshop. 🐶 EpicPupper (he/him | talk) 22:25, 23 March 2022 (UTC)

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.

Hello, I need help... Can somebody make a Wikipedia logo for Nogai Language, please....

Wikipedia The Free Encyclopedia → Википедия Ашык Энциклопедия

https://meta.m.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Nogai TayfunEt. (talk)

This probably belongs somewhere on commons or meta... Sungodtemple (talk) 17:07, 23 March 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RFC: New PDF icon

Should we replace the current PDF icon? –MJL ‐Talk‐☖ 05:33, 8 September 2021 (UTC)

Background

Our current PDF icon is File:Icons-mini-file acrobat.gif . To put it simply, it isn't particularly good. It's a .gif made over 16 years ago. Berrely mentioned this in WP:Discord, so I set about coming up with a modern SVG version of the file. The result was File:Icons-mini-file pdf old.svg  File:Icons-mini-file pdf.svg .

Options

There are three options that should be considered here:

Consensus for Option 2 should be followed up in a separate discussion. [Updated 15:35, 9 September 2021 (UTC)]

CONSENSUS TO CHANGE THE ICON, BUT NO CONSENSUS YET ON WHAT TO CHANGE IT TO
Seems pretty clear that most participants want to change the icon from its current form File:Icons-mini-file acrobat.gif, with typical arguments being that the current form is tied to Adobe (and thus advertises for the company, or is tied too much to a company) and outdated. There was some discussion on whether an external link icon for PDFs was needed at all, with reasonable arguments presented on both sides but most people are supporting a different icon not "no icon at all".

What's not so clear is what to replace it with - many of the editors who support a change did not specify what to change it to, and some comments are ambiguous. The main point of discussion about each of the numerous proposed files is the legibility of each icon at the size of an external link logo and whether to use SVG or PNG (apparently nobody demands GIF). On balance it looks like the most popular option is File:Icon_pdf_file.png () but there are a lot of people who didn't specify what they wanted or preferred something else. Thus there does not seem to be a clear consensus for a particular option, so we need further discussion to determine the outcome.

Technical implementation details: As noted in the discussion the file is used through MediaWiki:Common.css, row 314, which as a .css page will need to be edited by an interface administrator. I note that there is a bit of uncertainty if the files used there can be SVGs - apparently the URL cannot be .svg but it can be .svg.png? - among the participants. Jo-Jo Eumerus (talk) 16:41, 11 January 2022 (UTC)

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.

Discussion (new PDF icon)

References

  1. ^ "With cite template" (PDF).
  2. ^ Without cite template
  • Option 1. That logo is still the most widely associated with the PDF format, and anything else is just making things less clear for our readers. There doesn't seem to be a clear alternative being posited (the letters in the version proposed by Joe are illegible at this resolution), and most of the reasons above seem to hinge on people's person feelings about Adobe, which shouldn't enter into this debate. Either leave well alone, or adopt the new clearer version proposed by the OP.  — Amakuru (talk) 12:14, 8 September 2021 (UTC)
    "Personal feelings" is a bit dismissive. We're an free knowledge project and have a long history of supporting free software, free licenses, and free formats wherever possible. I highly doubt that the generic 90s software-looking acrobat squiggle is more widely recognised than the letters "PDF", but I agree the legibility of my first suggestion could be improved. – Joe (talk) 12:22, 8 September 2021 (UTC)
    If someone comes up with an alternative that actually works, then I might support it. But I'm not going to give a blank cheque to swap an easily recognisable logo for one which might not immediately convey its meaning to our readers. "Option 2" involves dispensing with the current logo without any consensus as to what we're swapping it for, and I can't support that.  — Amakuru (talk) 12:31, 8 September 2021 (UTC)
  • Option 2 - some generic PDF logo (i.e. not the Adobe 'squiggly triangle') to be determined later. SVG > GIF, of course, but I think we should take this opportunity to swap it for a more generic logo. firefly ( t · c ) 12:25, 8 September 2021 (UTC)
  • Option 2 or 3 Option 1 is a non-starter due to license. We need something that's public domain or CC0 to avoid a requirement to link back to the file description page for attribution and/or notice of license. I wouldn't oppose an identical image with a proper license; while it's annoying to have the Adobe software's logo in there, it's also recognizable. As for that several people above seem to like, all I see at that size is a document icon with a red bar over it. The text "PDF" is not visible. Again, I wouldn't oppose an alternative that's more legible. Anomie⚔ 12:26, 8 September 2021 (UTC)
    • Striking as the concerns I raised seem to have been addressed, the new image for option 1 has a usable license and people have suggested as a better choice for option 2. I don't have enough of an opinion on the current options to !vote. Anomie⚔ 16:57, 9 September 2021 (UTC)
  • Option 2 Let’s move away from Adobe. --Malcolmxl5 (talk) 12:32, 8 September 2021 (UTC)
  • Option 3 This is change for the sake of change and doesn't actually accomplish anything. * Pppery * it has begun... 13:21, 8 September 2021 (UTC)
    @Pppery, the current file is 512 pixels, which is too small to be rendered properly on modern screens and appears conspicuously pixelated. ~~~~
    User:1234qwer1234qwer4 (talk)     15:29, 8 September 2021 (UTC)
  • Option 3 or 2: the current icon is serviceable as is, but if we were to change, I'd rather something without the Adobe logo. Isabelle 🔔 14:35, 8 September 2021 (UTC)
  • Option 2 per Firefly and others. There is nothing wrong with using a 16-year-old icon per se, and the proposed replacement's only advantage is in file format and that's not enough reason imo to justify a change. However what does justify a change is using a generic icon that doesn't require someone knowing what the logo of a private company represents. Whatever icon we end up choosing, we should probably consider including it as an example in the PDF article. Thryduulf (talk) 15:07, 8 September 2021 (UTC)
  • Option 2, PDF files are no longer the sole domain of Adobe and we shouldn't be using their logo, but none of the suggested icons have been readable. I modified one of the existing PDF SVG icons on commons to make it more readable (), but if the intent is to use this at 16px, pixel art is always going to render better than an SVG, e.g. . --Ahecht (TALK
    PAGE    ) 15:37, 8 September 2021 (UTC)
    I have to admit that the 16px PNG rendering does look like a usable option and also looks way less pixelated than the current icon (where even the border displays very blurry), at least on my end. ~~~~
    User:1234qwer1234qwer4 (talk)     15:48, 8 September 2021 (UTC)
  • Ehhhhhhh ---- GPL are we opening a can of worms by changing from a free image to one that has to drag GPL around with it everywhere? — xaosflux Talk 16:58, 8 September 2021 (UTC)
    Leaning more towards Option 2 and using File:Icon pdf file.png or something similar, provided it is CC0 or other very-free license. — xaosflux Talk 18:50, 8 September 2021 (UTC)
    @Xaosflux and Anomie: Wouldn't a comment in the CSS be sufficient for linking to the license and authorship? –MJL ‐Talk‐☖ 20:56, 8 September 2021 (UTC)
    Nope. The GPL seems particularly weird when it comes to images, and even more weird when it comes to SVG images. The bottom line is that we need to clearly distribute the image along with the author's copyright notice and the notice that it's under the GPL, which we satisfy by linking the image to the file description page that has all that information. Hiding a comment in a CSS file, where it'll be hard to find and may be minified out, won't cut it. Anomie⚔ 21:55, 8 September 2021 (UTC)
    Okay, I have managed to remake the SVG using stuff that was in the Public Domain. –MJL ‐Talk‐☖ 05:06, 9 September 2021 (UTC)
  • Option 2 I find the PDF text version quite promising. The one I think is the most legible is (show) (File:Icon_pdf_file.png) which is easily readable on both mobile (both vector and mobile version). There are of course scenarios where it wouldn't be legible, but I feel the current icon would be non-distinctive under the same circumstances and I could see many readers not knowing what the acrobat icon means now a days. --Trialpears (talk) 17:03, 8 September 2021 (UTC)
  • Option 2 Go for File:Icon_pdf_file.png . It's more readable than the similar svg versions. -- WOSlinker (talk) 18:23, 8 September 2021 (UTC)
  • Option generic PDF SVG Headbomb {t · c · p · b} 18:34, 8 September 2021 (UTC)
  • Option 4 get rid of it altogether. No GPL license, no trademark (US #3652386 and #3652388, I have no idea how to link these from https://tmsearch.uspto.gov/ so search yourself, it's the squiggly triangle), no BS. The document icon with "PDF", even Joe Roe's improved version, is hard to read and ultimately provides no additional information over just the text "(PDF)". This is currently defined in MediaWiki:Common.css#L-510 btw, it's not template specific or MediaWiki default. — Alexis Jazz (talk or ping me) 19:55, 8 September 2021 (UTC)
  • Opposed to any GPL-licensed image or image restricted by trademark. Would prefer CC-0 license. No strong opinions on the design itself, I'm open to a new one but don't see a serious problem with the existing image. — Wug·a·po·des​ 20:29, 8 September 2021 (UTC)
    @Wugapodes: Wouldn't the trademark issue be a problem with File:Icons-mini-file acrobat.gif  as well? I'm a little confused there. –MJL ‐Talk‐☖ 21:00, 8 September 2021 (UTC)
    I'm not an expert on trademark, but I presume so. My understanding is that having a trademark isn't a problem per se as long as we aren't using it to mislead readers about brand identity or disparage the trademark holder. The issue isn't a legal one, but a philosophical one: I'd prefer we use free equivalents that do not have copyright or trademark restrictions whenever possible. But unless we have consensus for an option that is free of copyright and trademark, I'd rather we have some graphical representation of the PDF over nothing. So by no "serious problem" I mean that it's not enough for me to say get rid of it immediately, but I do think there is room to improve. If we are going to improve, I want us to also move in the direction of copyright- and trademark-free images, but if the option is do nothing or remove the icon without replacement, I'd rather do nothing. (NB I do like Ahect's idea of just using stylized text instead of an icon.) — Wug·a·po·des​ 21:40, 8 September 2021 (UTC)
     Question: Why is specifying the file format necessary for PDF files? ~~~~
    User:1234qwer1234qwer4 (talk)     22:13, 8 September 2021 (UTC)
    Wugapodes, I'm fine with stylized text too. The text "(PDF)" already gets added, seemingly by {{Citation}}. I just think the icon should go away. Trademark is possibly a theoretical legal issue. The squiggly triangle in the infobox of PDF is fine because there is clearly no connection between Adobe and Wikipedia. When used as system icon of sorts, like we have it in MediaWiki:Common.css#L-510, it could cause people to believe there is a connection between Adobe and Wikipedia or MediaWiki, like us relying on Adobe software or being endorsed by Adobe. It's a theoretical issue though, this may or may not actually be a trademark violation and Adobe is unlikely to try and crack down on this kind of unauthorized usage. My main issue is also philosophical: try to avoid trademarks if possible, particularly when they're not being used for commentary. 1234qwer1234qwer4, I think traditionally this kind of indication (not just on Wikipedia) was provided to warn users to get a cup of joe while their computer chugs along for 15 minutes to load Adobe Acrobat Reader. — Alexis Jazz (talk or ping me) 22:33, 8 September 2021 (UTC)
    @1234qwer1234qwer4: PDFs are a bit of a weird file format. Sometimes when you click a link it will automatically download a file on your device, but other times it can just open up in a new tab. The biggest concern, however, is that not all mobile devices support PDFs across the board. My phone can just barely do it (and requires a download everytime I view one.. which can be a problem for larger files), so I have always found these icons helpful. –MJL ‐Talk‐☖ 05:06, 9 September 2021 (UTC)
  • Option Alexis Jazz - WP:ACCIM recommends that information should not be conveyed using only images, and while the revised icon with plain text is a slight accessibility improvement over the corporate logo version, it's still a long way off from meeting that standard. Alt text would help, but a simple (PDF) alongside the link is frankly much better and more useful than a small icon with tiny, barely-legible text. Ivanvector's squirrel (trees/nuts) 20:40, 8 September 2021 (UTC)
    Or something like PDF, which is reminiscent of what Google uses. --Ahecht (TALK
    PAGE    ) 21:14, 8 September 2021 (UTC)
    I see this as a case of progressive enhancement given broadband speeds and the compression of PDFs (which has gotten better since PDFs stopped being all-image files), as the size was predominantly the rationale for ever indicating that a URL pointed to a PDF. Separately, CS1/2 already auto-indicates whether something is a PDF. I don't really see much cause for anyone to generally indicate something is a PDF. (This is not an opinion on this RFC per se, just making a comment about whether we should need to indicate something is a PDF.) Izno (talk) 19:02, 9 September 2021 (UTC)
    There is an old-school web best practice to indicate if a link doesn't take you to a web page, since that's the general expectation (and, yes, size was part of the concern). I'm not sure of the current consensus on this matter in the web design community. isaacl (talk) 19:46, 9 September 2021 (UTC)
    I haven't designed web pages since the mid-90s so I can't really comment on standards, but I'd prefer if there were some kind of indicator, text or otherwise. Compression has improved for sure but PDFs are still multimedia, even a single-page plain-text PDF can be several megabytes. Not everyone who reads Wikipedia benefits from the expansion of broadband in wealthy countries, and third-party software is still generally required to open a PDF or use their full functionality, and this can be severely prohibitive for someone on say a 14.4kbps dialup connection, or using a 2G mobile device. We still warn when a link goes to an external website, and we should do the same with multimedia. Ivanvector's squirrel (trees/nuts) 20:52, 9 September 2021 (UTC)
    "We still warn"? We don't (I assume by "we" you mean MediaWiki software, please be precise if otherwise), at least not "accessibly", in the same way we don't as the would-be "replace with 'PDF' in text". Izno (talk) 21:22, 9 September 2021 (UTC)
    If you look at the web, I'd say that mostly doesn't happen any longer. I mostly don't think it should, especially with the advent of "the browser does everything (video, audio, PDFs of late in e.g. Firefox, yadda yadda)". Browsers are monsters not far off from being their own operating systems (oh wait :). Izno (talk) 21:24, 9 September 2021 (UTC)
    Although links to PDF files often lack indicators (with the ubiquity of the format, probably due to both happenstance and successful Adobe marketing), links to video and audio generally still provide some kind of indication. Users generally want to know in advance if they're going to see some kind of audiovisual presentation. Their current browsing environment (such as alone in a room or within a crowd) and personal desires at the moment influence what type of interaction they want to have. isaacl (talk) 00:56, 10 September 2021 (UTC)
    Yes, by "we" I did mean the MediaWiki software, with the little "arrow escaping the box" icon beside all external links (like this, which is, indeed, not accessible). Remember that while progress marches on, it marches past many people who read Wikipedia but don't have access to cutting-edge tech that we do in developed countries, and something as minor to us as loading a couple-megabyte multimedia file could be an outright ordeal for them. On a trip to Cuba a few years ago I turned my phone on when our plane landed, and didn't even get out of the airport before I had a text from my carrier saying I was up to $100 in roaming charges and they had disabled my data. I remember the not-too-distant past trying to edit through Opera on a flip phone, and recently made one edit from my Wii's embedded browser just to see if it would work - it did but it was frustrating. I still see more Windows XP than ChromeOS in checkuser results, and rarely even older OSes. Ivanvector's squirrel (trees/nuts) 16:43, 15 September 2021 (UTC)
    Most of the major search engines indicate PDFs (Google, Bing, DuckDuckGo, Yandex, and Baidu do, Yahoo and Ask don't). --Ahecht (TALK
    PAGE    ) 19:47, 25 October 2021 (UTC)
  • With apologies to those who already knew, the choice of icon is implemented in MediaWiki:Common.css line 510. Help:External link icons#Custom link icons informs us that The image must be 16 pixels wide and cannot be SVG format. (That's in an example about adding a custom icon for .xls, but I assume it applies to .pdf too). From my rather basic knowledge of graphics, .png may be the best format for this use case. Certes (talk) 22:52, 8 September 2021 (UTC)
    Certes, I had already mentioned Common.css above, but you inspired me to add an anchor to the line number. — Alexis Jazz (talk or ping me) 23:02, 8 September 2021 (UTC)
    @Certes: Really, SVG is the best format because it is the most scalable (imo). –MJL ‐Talk‐☖ 05:06, 9 September 2021 (UTC)
    Normally, yes, but the software doesn't seem to accept SVGs here. Also, if it's shown at a fixed 16px, we should probably optimise for that, e.g. align the paper edges and the orthogonal lines of the letters mid-pixel. If the day comes when MediaWiki renders an SVG at 128px on our 16k holodisplays, we can replace the icon again. Certes (talk) 10:19, 9 September 2021 (UTC)
    When it says "cannot be SVG format", I suspect that refers to the URL used. So https://upload.wikimedia.org/wikipedia/commons/c/cb/Icons-mini-file_pdf.svg would fail, but https://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Icons-mini-file_pdf.svg/16px-Icons-mini-file_pdf.svg.png would be ok. For that matter, the restriction on SVG may be outdated (it was written in 2011), or may have been because someone's browser in 2011 didn't support SVGs there, or may be to avoid explaining that the SVG's intrinsic size needs to be 16px; at any rate, I tested it and it seemed to work fine. But I do agree that optimizing the icon for the size would be a good idea. Anomie⚔ 11:51, 9 September 2021 (UTC)
    The "restriction" is outdated. We have been serving SVGs via TemplateStyles for CS1 for a year or two now. My guess is that it is related to IE8 and lower, which MediaWiki no longer supports. The page pointed to by Certes should be updated. Izno (talk) 18:58, 9 September 2021 (UTC)
    But if you're using the png rendering of an SVG file, you get all the downsides of an SVG (e.g. blurry lines and fonts) with none of the advantages of it being scalable. --Ahecht (TALK
    PAGE    ) 13:14, 24 September 2021 (UTC)
  • Option 2 I think File:Icon_pdf_file.png is a much better replacement, is very readable, and is simple. This is the obvious choice for me. DiamondIIIXX (talk) 03:47, 9 September 2021 (UTC)
  • Comment This may seem like an odd question but, why is the file in a .gif format anyways? Aren't .gif format files used for animated images? But I support Option 2, per the above discussion. The current file makes it seem like the file is in Adobe Acrobat (which, a few years ago, that was probably the only way to view PDFs) when really it can be viewed in many places besides Adobe Acrobat. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 19:06, 9 September 2021 (UTC)
    GIF format was long used for images on computer networks, pre-Internet, pre-Web, and up to now. Due to patent issues (which are no longer applicable as the patent in question has expired), there was a push to move to PNG format, and JPEG became popular for photos due to better compression and appearance (both due to higher resolution colour not being limited to only showing 256 colours and its compression algorithm being a better fit). GIFs remained in use for animated images as the original PNG specification did not support this capability. The current image being a GIF is reflective of how long ago it was put into place. isaacl (talk) 19:27, 9 September 2021 (UTC)
    Ah ok, thanks for informing me! I've always know .gif format files as being animated images so I was confused when I saw that the current image we're using was in the .gif format but wasn't animated. @Isaacl: Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 19:31, 9 September 2021 (UTC)
  • Option 1 as an improvement, until someone thinks of something which is equally clear and less like its own logo. DGG ( talk ) 06:33, 10 September 2021 (UTC)
    I'm confused as to what you mean. Many people have already thought of something equally clear and less like a logo. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 13:07, 10 September 2021 (UTC)
  • I'm not going to pick an "option" because at this point there are too many icons going around, but I support using some sort of SVG icon (preferably without the Adobe logo) that's CC0 (or similarly) licensed. I don't prefer any particular icon. Tol (talk | contribs) @ 21:14, 10 September 2021 (UTC)\]
    @Tol: Option 2 does not require a commitment to any particular proposed icon. All it means is that you are against File:Icons-mini-file pdf.svg  and are also against File:Icons-mini-file acrobat.gif . That sounds like where you are basically at right now. –MJL ‐Talk‐☖ 06:34, 12 September 2021 (UTC)
    @MJL: Ack, my mistake. Option 2 sounds good. Tol (talk | contribs) @ 17:39, 12 September 2021 (UTC)
  • Question Have we asked Adobe what they will allow? I quickly skimmed https://www.adobe.com/legal/permissions/icons-web-logos.html and thought I need to ask someone with expertise in copyright law. Vexations (talk) 22:24, 10 September 2021 (UTC)
    Does it matter? If we don't want to use one vendor's logo for an industry-wide standard, whether they want us to use it is irrelevant. Certes (talk) 22:32, 10 September 2021 (UTC)
  • Option 2 (use MediaWiki? fallback). I used inspect element to disable the current icon pulled from Common.css, and discovered that the fallback pdf icon is evidently [7]. This is the visual counterpart to the external link icon [8]. I suppose this is a !vote to remove the text in Common.css, and let this fallback icon take its place, since it establishes a nice visual consistency, and doesn't stick out as much as the ones that have been proposed so far, which I don't like. — Goszei (talk) 04:46, 11 September 2021 (UTC)
For the sake of illustration in this discussion, I have uploaded the icon I am proposing to Commons; it looks like this: (for comparison, here is the external link icon that appears all over Wikipedia, part of the same MediaWiki set: ). — Goszei (talk) 03:43, 20 September 2021 (UTC)

Option 2 (can't close - don't know how to execute), using the letter option mooted above by numerous others. It's clearer, which is really the only basis for decisions we have here Nosebagbear (talk) 15:48, 11 January 2022 (UTC)

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

Further discussion (PDF icon)

Since opinions are split and some people noted that further discussion would be needed, leaving this section open. Jo-Jo Eumerus (talk) 16:41, 11 January 2022 (UTC)

  • There are 15 icons in Commons:Category:PDF icons under Public Domain that are not based around the Adobe Acrobat logo (which was rejected above), listed below in alphabetical order of file name; the ones in italics were mentioned in the above discusison
    • Option 1: File:.pdf OneDrive icon.svg -
    • Option 2: File:Document-303123.svg -
    • Option 3: File:Icon pdf file.png -
    • Option 4: File:Icon pdf.svg -
    • Option 5: File:Icon-354355.svg -
    • Option 6: File:Ilovepdf.svg -
    • Option 7: File:PDF icon black.svg -
    • Option 8: File:PDF icon blue.svg -
    • Option 9: File:PDF icon bold.svg -
    • Option 10: File:PDF icon.svg -
    • Option 11: File:Pdf link icon.png -
    • Option 12: File:Pdf-155498.svg -
    • Option 13: File:Pdf-2127829.png -
    • Option 14: File:Pdf-47199.svg -
    • Option 15: File:Pdfreaders-f.png -
    I think that is too many options for a single RfC so we should try and narrow it down first. Unless anyone has better suggestions I propose a round of approval voting first to find the top 4/5 that people could support, with those being the options in a full RfC? Thryduulf (talk) 18:09, 11 January 2022 (UTC)
    Seems like a good plan, as I agree that 15 choices is too many. (As an editorial aside, the list could get quickly pruned somewhat by eliminating those which are unusable; some of these are indecipherable to me.) Do we need to first clarify .svg/.png formats? Or do we know that both are equally good (although that seems in some conflict with the note in the RfC close above)? — JohnFromPinckney (talk / edits) 04:52, 12 January 2022 (UTC)
    At their current sizes, I find all but 3, 9 & 10 nearly impossible to read. 7, 8 and 11 are a stretch, but I can make out the letters. I would have no idea what 6 means to indicate without context. Aza24 (talk) 05:15, 12 January 2022 (UTC)
    On my device, with my eyes, I can read option 9, and with difficulty 3, 4, and 10. Since I know I'm looking for "PDF", 5, 11, and 12 are on the boundary of recognizability. I could plausibly make out some of the others by removing my glasses and bringing my phone nearer my face, but I'm unconvinced that is the solution we're seeking. Folly Mox (talk) 05:50, 12 January 2022 (UTC)
    3, 9, 10 are the clearest in terms of legibility and actually conveying meaning. Since I'm aware that I'm on team-letters, one other option should be included which is option 14 that is both legible and would probably be understood over time. The issue is that it makes me think it's powerpoint, but that argument could be had in the 2nd RfC. Nosebagbear (talk) 11:55, 12 January 2022 (UTC)
    To clarify for any reviewer, 3 is the best of these Nosebagbear (talk)
  • Yes, let's put one contender forward against the incumbent. Legibility is key here; I find 9, 3, 10 easiest to read in that order. Is it worth considering another alternative with the letters in red on white rather than white on red? That could save a couple of pixels at the sides, enabling the letters to grow slightly. I've tried playing around and can't make anything worth uploading but someone with a clue about graphic design probably could. Certes (talk) 14:31, 12 January 2022 (UTC)
    I think any colored text makes it harder to read the letters at such small size. I prefer something like 11, perhaps 9 with plain black text. MB 14:48, 12 January 2022 (UTC)
    Black lettering on 9 would work too, though readers may associate the red-white-black palette with PDF. Certes (talk) 14:56, 12 January 2022 (UTC)
    Maybe 9 with black text and a red outline of the document symbol is a way to get some red in there. MB 15:21, 12 January 2022 (UTC)
  • 3, distant second:9. — xaosflux Talk 15:11, 12 January 2022 (UTC)
  • For me 3 is the most clear, with 9, 10 and 11 readable but noticeably less so. Thryduulf (talk) 15:55, 12 January 2022 (UTC)
    Looking on a smaller (and dirtier) laptop screen 3 is by far the clearest, 9 is readable but not as easily. 10 and especially 11 I'm not convinced I could read if I didn't know what they said. Thryduulf (talk) 22:58, 17 January 2022 (UTC)
  • I don't have clear preferences on what should be the one we should adopt, but I have some arguments against 2, 6, 7, 8, 11, 12, 14, 15.
    • The word "PDF" in 7 & 8 are simply not legible at all, and have an overall bad contrast.
    • 11 & 12 look good on zooming in but on my screen, they can be easily overlooked if one isn't searching for a logo on there.
    • 14 & 15 are not quite associatable with PDFs in general. The huge "P" in 14 makes it appear more like MS PowerPoint logo than PDF. In option 15, the average person will associate the green very closely with spreadsheets rather than PDFs (thanks to Excel & GSheets), plus the word "PDF" on it is too small to be legible.
    • 2 appears more like a basic Windows notepad app, again the word "PDF" is not legible either.
    • 6 is the logo of ilovepdf.com and shouldn't be used due to the very reasons some editors already raised regarding the Adobe relation in current one. Also, what does a reader coming across a random heart symbol in a certain external link understand of it? ---CX Zoom(he/him) (let's talk|contribs) 19:25, 12 January 2022 (UTC)
  • On my laptop, I find 3 the easiest to read, then 10, then 9, then 11. 7 and 8 possess bad color combinations, options 4 and 12 are too small, and the others just don't look right, especially option 6. ResPM (T🔈🎵C) 00:01, 13 January 2022 (UTC)
  • 3 if we're going to use an image, but I think of a Google-like text tag is still better. If we are using an image, there's no advantage to using an SVG if mediawiki is going to convert it to a raster image anyway. --Ahecht (TALK
    PAGE    ) 18:40, 13 January 2022 (UTC)
  • Option 3 is by far the clearest for me. ― Qwerfjkltalk 18:07, 15 January 2022 (UTC)
  • Option 3 Most recognizable for me, alternatively 10 as a second choice. — Preceding unsigned comment added by IAmChaos (talk • contribs) 23:17, 20 January 2022 (UTC)
  • I'd suggest we just vote on 3, 9, and 10. They're by far the best options of the bunch. Mlb96 (talk) 04:34, 21 January 2022 (UTC)

This has been open a few hours short of 10 days and we have three clear favourites so is seems an appropriate time to close this round. Allocating 1 point for a first or equal first choice and 0.5 for a second or equal second choice the scores are:

Option Votes
1 1
2 0
3 10
4 1
5 1
6 0
7 0.5
8 0.5
9 7
10 5.5
11 2
12 0
13 1
14 1
15 0

As 3, 9 and 10 are clearly the most supported, they should be the options for the formal RfC. I did initially say "4 or 5" options, but while there is a clear 4th choice (option 11) it is a long way behind and it doesn't seem sensible to make the RfC more complicated just to include it. I don't have time now to set that up, I might later today but after that it will likely not be until about Thursday so someone else taking point would be good. Thryduulf (talk) 10:57, 21 January 2022 (UTC)

Might want to count how many people opined in general. When folks are not treating a RfC as an either-or choice and supporting more than one option, the ratio of "support for a given option"/"total amount of participants" can be an useful metric to gauge consensus. Jo-Jo Eumerus (talk) 11:05, 21 January 2022 (UTC)
3, 9, and 10 are all equally acceptable to me at this stage. KevinL (aka L235 · t · c) 11:14, 21 January 2022 (UTC)
@Jo-Jo Eumerus by a quick count, 13 people expressed an opinion about 1 or more of the options before the summary. The discussion was explicitly set up as approval voting to find the options for an RfC, it was not intended to determine consensus for a final option. Thryduulf (talk) 11:31, 21 January 2022 (UTC)
Since you don't need consensus to start an RfC, Thryduulf, and this discussion seems more than sufficient, I think you should feel free to start it. KevinL (aka L235 · t · c) 02:34, 22 January 2022 (UTC)
@L235 as noted, I'm not going to have time to start it for a few more days. Thryduulf (talk) 01:19, 24 January 2022 (UTC)

RFC: Changing the icon for PDF files

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is a consensus for Option A. Option A was the clear favorite among images and there was a consensus that there should be an image. A minority of editors would prefer to only have a text notation for PDF files (no icon), with this group of editors also largely preferring A if there had to be an image. Best, Barkeep49 (talk) 17:26, 3 March 2022 (UTC)


Which icon should replace the currently used ones for PDF files? At #RFC: New PDF icon there was consensus to replace the current PDF icon (File:Icons-mini-file acrobat.gif ) with one that is not based on the Adobe Acrobat logo, but not on a specific replacement. At #Further discussion (PDF icon) all the public domain icons currently available at Wikimedia Commons that are not based on the Acrobat logo were considered and three identified as clearly better than the others, this RFC seeks to determine which of those options should be used. Thryduulf (talk) 09:37, 29 January 2022 (UTC)

Which icon should be used for PDF files?

Discussion (Changing the icon for PDF files)

The following people commented in the first discussion: @MJL, Xaosflux, Yeeno, Joe Roe, Ahecht, Plutonical, JPxG, 1234qwer1234qwer4, CaptainEek, Robert McClenon, WOSlinker, Vulphere, Certes, Izno, JohnFromPinckney, Amakuru, Firefly, Anomie, Malcomxl5, Pppery, Isabelle Belato, Trialpears, Alexis Jazz, Wugapodes, PEIsquirrel, Isaacl, DiamondIIIXX, Blaze The Wolf, DGG, Tol, Vexations, Seddon, Qwerfjkl, Levivich, Szmenderowiecki, Herostratus, GhostInTheMachine, DGerman, Sdkb, Retswerb, Stifle, Nihiltres, Huggums537, Hog Farm, Aza24, Bilorv, Modest Genius, John M Wolfson, and Nosebagbear: Thryduulf (talk) 09:41, 29 January 2022 (UTC)

And the following people commented in the follow-up but not the first discussion: @JohnFromPinckney, Folly Mox, MB, CX Zoom, ResPM, IAmChaos, Mlb96, L235, and Jo-Jo Eumerus:. 09:42, 29 January 2022 (UTC)
Fixing pings: @Malcolmxl5 and Blaze Wolf:. Thryduulf (talk) 09:45, 29 January 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Something doesn't look right

@Barkeep49: thanks for your close above, but I'm not sure if it's been implemented correctly. I just viewed the article PlayStation (console) using Chrome on Windows 10, and the icon appears to be chopped off at the top and bottom. Please could you look into what's going on with that? I !voted for Option A above, but I didn't envisage it looking this way. Thanks  — Amakuru (talk) 10:52, 5 March 2022 (UTC)

This is already under discussion at Mediawiki talk:Common.css#Protected_edit_request_(3_March_2022). Basically, this has always been an issue, but the new icon makes it much more noticeable. Writ Keeper ⚇♔ 10:55, 5 March 2022 (UTC)
Ah OK, thanks.  — Amakuru (talk) 11:21, 5 March 2022 (UTC)
The RfC implementation should be suspended and the new icon reverted, imo. It is conceivable that this rendering may have affected the result if known. Btw, the misshapen icon appears in Windows 10 and Mac 11 Edge, Chrome and Tor, Mac 11 Safari, and Ubuntu 20 Tor. It also appears in Android 11 desktop view in Edge and Chrome, but not the latest Tor app for Android 11. As of 15 minutes ago. 65.88.88.201 (talk) 17:22, 6 March 2022 (UTC)
It seems Tor 11.0.6 for Android 11 (kernel 4.19.157) desktop view scales the icon down, so it appears whole. 65.88.88.201 (talk) 18:03, 6 March 2022 (UTC)
On an old version of the Pale Moon web browser the icon also looks cut off, along with an old version of Tor browser. Works fine in Chrome, along with updated versions of Pale Moon and Tor. Rlink2 (talk) 18:59, 6 March 2022 (UTC)
As all three icons in the RfC have the same aspect ratio I believe that this issue (which certainly wasn't known to me when I started the RfC) I strongly suspect it will affect all identically so simply re-running the RFC would be pointless, we'd have to go back to evaluating more options (given the clear consensus for an image that isn't based on the Acrobat logo). A solution has been proposed at the MediaWiki talk page (where this discussion should be happening to keep it all in one place), that one other person has stated works for them (I don't understand it enough to test it myself). If that does solve the problem and can be implemented soon without side effect (I have no idea) then just doing that is going to be less disruptive than two additional changes of the icon. Thryduulf (talk) 21:00, 6 March 2022 (UTC)
If this is in reference to Trappist's solution, this probably affects <0.1% of the continuous rolling average of Wikipedia users, i.e. readers logged in (as handle-based accounts). 68.173.76.118 (talk) 00:56, 7 March 2022 (UTC)
Credit for the solution to the clipped-icon problem does not go to Trappist the monk. Credit for the solution (a tweak to Mediawiki:Common.css) goes to Editor Writ Keeper.
—Trappist the monk (talk) 01:48, 7 March 2022 (UTC)
(and also, to be clear, it hasn't actually been implemented yet.) Writ Keeper ⚇♔ 02:03, 7 March 2022 (UTC)
Can confirm that the icon now appears correctly in safari 15.3, MacOS 11.6.4. 68.173.76.118 (talk) 01:26, 7 March 2022 (UTC)
I came here to report the same problem. I've tried doing a hard refresh but the top and bottom of the PDF icons are still getting cut off. Modest Genius talk 15:11, 15 March 2022 (UTC)
Weirdly, it now seems to have fixed itself. Modest Genius talk 15:25, 16 March 2022 (UTC)
A fix was implemented at MediaWiki_talk:Common.css#Protected_edit_request_(3_March_2022). --Ahecht (TALK
PAGE) 01:45, 24 March 2022 (UTC)

Dissociate Fiction from Non-Fiction on the Wikipedia platform

This is somewhere in realm of WP:SNOW. --Izno (talk) 17:17, 27 March 2022 (UTC)

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.

While fiction-related articles, such as motion pictures, books, comics & animation in general are readily available on the wiki.riteme.site domain, which is very useful for various people, the proposal is for them to be migrated on another domain of Wikipedia, perhaps on another server as well, so that they do not get mixed up during a search, and also to better distinguish the objective nature of Wikipedia from the fiction-oriented one. — Preceding unsigned comment added by Barracuda stew (talk • contribs) 09:45, 23 March 2022 (UTC)

Please, don't feed the trolls
The following discussion has been closed. Please do not modify it.
  • Please include articles that are poorly referenced, unreferenced, or with unverified references. They are also fiction. 68.173.76.118 (talk) 11:54, 23 March 2022 (UTC)
    • No they aren't- they're articles on factual things that need improving.... Joseph2302 (talk) 11:58, 23 March 2022 (UTC)
      • And how is one to know these things are factual? That's supposition. The fact is, absent proof they're fiction. 68.173.76.118 (talk) 12:01, 23 March 2022 (UTC)
        • It is trivially easy for an article to be both poorly referenced and proven factual. For example an article that is supported only by non-independent sources and makes no un-attributed subjective claims. We can't say it's notable, but we can certainly say it's not fiction. Thryduulf (talk) 14:17, 23 March 2022 (UTC)
          • ??? an article that is supported only by non-independent sources and makes no un-attributed subjective claims = article that has no independent sources and makes subjective claims (attributed to these non-independent sources) = that is somebody's fictional (opinion/imagination/etc-based) take. Non-fact (ie POV) dressed up in "references". 65.88.88.93 (talk) 16:01, 23 March 2022 (UTC)
            That doesn't follow at all. Non-independent sources can be used to verify objective statements and to verify attribution of claims. For example, say the article is about XYZ Ltd and the sources are (1) the company website, (2) a company press release and (3) an advert for the company in a major newspaper, the article also contains three photographs showing (a) the company headquarters, (b) one of their products ("XYZ Super") with branded packaging, and (c) a celebrity (Fred Bloggs) using one of the products. The claims in the article are (i) that there is a company called XYZ Ltd, (ii) with a CEO called Jane Doe, (iii) that is headquarted in Anytown, (iv) that makes a product called "XYZ Super", (v) that is advertised as being "The greenest on the market", and (vi) that it is used by celebrities including Fred Bloggs.
            Claim i is verified by sources 1-3 and photos a-c, claim ii is verified by 1 and 2, claim iii is verified by 1 and a, claim iv by 1-3, b and c, claim v by 3, and claim vi by c. i.e. everything is factual. Notability is not demonstrated, but that's entirely different. "Non-fact" and "POV" are not synonyms, non-independent is not synonymous with either "non-fact" or "POV". "Opinion" and "fiction" are not synonyms either. Thryduulf (talk) 18:51, 23 March 2022 (UTC)
            What you demonstrated in the first paragraph is an example of using primary sources to establish certain facts about the sources themselves, an appropriate and narrow application. This is not contested, and it was not part of the argument made in this section.
            The problem is parts of the second paragraph. Facts are not points of view. They are whole, not just the aspect(s) one knows about or the aspect(s) that one prefers. A fact implies the full view, not one's limited perspective. There is no such thing as "almost factual". That is a an easy way out, an attempt at making something partial and limited equal to the whole. Maybe this kind of mediocrity is accepted because the alternative is really hard work. But unfortunately, in any mix of fact and fiction/opinion/theory/POV the latter wins out. The mix produces yet more non-fact. I leave it to your judgement to decide whether any non-independent position or source can ever substitute or even relate to facts which are by definition independent of perspective. And if they are not facts, they are opinions, POVs and non-facts.
            This shouldn't be so hard. After all there are very few facts compared to the hyperinflation of opinions. But the overabundance is not the reason opinions are worthless. They are inherently worthless, because they have a limited perspective. That is a useful fact to know. You can proceed more realistically from there, perhaps even produce a better encyclopedia. 65.88.88.57 (talk) 19:53, 23 March 2022 (UTC)
            Most of that is meaningless. There are no points of view in the sample I wrote, other than those which are clearly attributed (i.e. it is factual that the company claims this, it is not relevant whether the claim is true). An article which relies solely on primary and non-independent sources is poorly sourced. My point is to demonstrate that not all poorly sourced articles are fiction (which is what you were claiming). You also claimed that unsourced articles are fiction - it is entirely possible to write an entirely unsourced article that is self-evidentially factual not fictional - for example an article listing the conversions of 1 metre into various other units of length. Thryduulf (talk) 21:55, 23 March 2022 (UTC)
            As pointed out, the sample you wrote which utilized primary sources, is not contested. What is contested is eg an article supposedly listing length conversions without any sources to prove that the conversions are in fact correct. An article like that is a work of fiction as far as anyone can tell. 98.7.206.190 (talk) 22:04, 23 March 2022 (UTC)
            You are still not getting that "Unreferenced" and "Fiction" are not synonyms. If I could change fiction to fact just by adding a citation, I could therefore change fact to fiction just by removing a citation. The world doesn't work like that. Thryduulf (talk) 22:07, 23 March 2022 (UTC)
            We are talking about Wikipedia, a platform of anonymous contributors with unknown credentials and expertise, whose audience is the general reader, another quantity of unknown credentials and expertise, individually and in aggregate. The prudent and rational approach is to assume/presume nothing else about both groups. In such situations, unverified claims are no different from fiction. Without a proper reference, there is no prior or implied guarantee that they are factual. A reader may justifiably think they are just things somebody came up with, and very easily posted in some online platform. And let the buyer beware. 68.173.76.118 (talk) 00:05, 24 March 2022 (UTC)
            • I don't think this is relevant to the proposal, which was clearly concerned with fiction as an art form, rather than anything to do with whether articles have independent reliable sources. Phil Bridger (talk) 19:31, 23 March 2022 (UTC)
              The point was that articles that are not verified as having independent reliable references are works of "art". Fiction, for all a reader knows. Maybe they belong in a fiction-publishing platform instead. This is said in all seriousness. The harm that half-truths and opinions can do when presented as facts is great. The proper usage of primary sources was noted above, and is not part of this. 65.88.88.57 (talk) 20:01, 23 March 2022 (UTC)
  • Reject - there is no purpose served by this suggestion. The fictions which entertain us are part of our big, complex global culture, as much as our history, politics and religious/philosophical systems. As has already been pointed out, any article about a fiction which does not make it clear from the first sentence that this is fiction, is a junk article. --Orange Mike | Talk 13:24, 23 March 2022 (UTC)
  • Reject While I agree that it would be nice to be able to tune search so that whole genres could be omitted, and the people looking for Mercury from respectiely an astronomy, chemistry, religion and space flight perspective could more easily find what they want; I don't see further subdivision of Wikipedia as a good way to do this. Our strength is in being a general interest encyclopaedia, and that means covering the topics that don't interest each of us individually as well as the ones that do. This particular proposal also suffers from boundary issues, many religions might be glad to categorise other religions as fictional, but incensed if that was done to them. The same sort of thing would apply if we tried to spin off sport as something separate, just imagine the arguments as to whether darts, golf, chess, professional wrestling or even punt jousting were real sports. ϢereSpielChequers 11:09, 24 March 2022 (UTC)
  • Question: How often do readers end up on an article about a work of fiction when they are searching for something non-fictional? Some examples might help us determine whether this is a serious issue (or not). Blueboar (talk) 11:35, 24 March 2022 (UTC)
  • Agree with those above suggesting a can of worms when it comes to mythology and religion and folkloric history. Hyperbolick (talk) 12:45, 24 March 2022 (UTC)
  • Reject - fiction exists, it is a "real world" thing. We should, and do, strive to present any work of fiction from a real-world perspective, with limited and (hopefully) clearly demarcated "in universe" material. Also, to take the OP's idea to the extreme, if we do not cover fiction (ie novels, films, tv shows, comic books, etc), then the articles about the people who create these fictions and the companies that distribute them and the fan communities that celebrate them, etc. would be pretty scant at best. --User:Khajidha (talk) (contributions) 14:24, 24 March 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Science Photo Competition 2022 Russia targeting CentralNotice banner

On April 2, the «Science Photo Competition 2022» started, traditionally the photo marathon is being held jointly with the Nauka television channel, it will be interesting. We invite everyone who is interested in science and who is able to hold a camera in their hands. The rules of the contest are very simple, prizes have a place to be! Colleagues, to attract external participants, we proposed a banner of the competition through CentralNotice. JukoFF (talk) 19:33, 28 March 2022 (UTC)

Moved to WP:VPT#Android related question for developers. --Izno (talk) 23:31, 28 March 2022 (UTC)

Adding no-wrap to hatnote links: low-involvement testers needed for proposed change

We need some volunteers at Template talk:Further#Volunteer sign-up to help assess a proposed change to hatnote link wrapping. This will take very little of your time. A proposal at Template talk:Further#Adding nowrap calls for no-wrapping links in hatnotes to prevent undesirable line breaks in the middle of a link, such as:

Further information: World War II, Events preceding World War II in Europe, and Causes of World War
II

This currently may happen in a hatnote link such as in template {{Further}} where a link happens to bump up against your window's right margin, or a right-floated sidebar or other element. Implementation would involve a simple change to Module:Hatnote, but as this represents a change to the current behavior of a high risk template, we don't wish to make such a change lightly. Fortunately, the module already has an optional class which permits this to be tested in situ with a simple addition to your common.css, as follows:

.hatnote a {white-space: nowrap;} /* Test for nowrap hatnote links */

We are seeking volunteers to add this line to your css, and then just go about your business as before. In around a month or so (or whatever period seems right), we'll ping you and ask for your comments, and if feedback is supportive, we'll make the change to the module. If you can help, please add your name at Template talk:Further#Volunteer sign-up so we can contact you later for your impressions. Thanks, Mathglot (talk) 20:09, 27 March 2022 (UTC)

Sounds to me like it would give undesirable horizontal scrolling for people on mobile devices when links are long. Anomie⚔ 21:36, 27 March 2022 (UTC)
That's the first thing I thought as well. ScottishFinnishRadish (talk) 21:58, 27 March 2022 (UTC)
I presume that one of the reasons for this testing is to show whether that issue commonly arises. Phil Bridger (talk) 08:12, 28 March 2022 (UTC)
Probably the better final implementation (I make no comment on whether preventing nowrapping in hatnotes is desirable) would be to use nowraplinks already defined in Common.css. Mobile.css is more generous with how it treats that class which would take care of the mobile concern. Izno (talk) 23:27, 28 March 2022 (UTC)
@Anomie and ScottishFinnishRadish:, The first thing I though of, too; but the mobile issue turns out not to be a problem; please see the discussion. @Phil Bridger:, yes, exactly. @Izno:, yes, it is; this is only the test phase; please see the linked discussion. Please do have a look and sign up; it would really help. Thanks, Mathglot (talk) 09:46, 29 March 2022 (UTC)
I see nothing in the linked discussion that indicates it's not a problem. Your claim near the start that it's "already the default behavior on mobile" is confused by the fact that your example is in a fixed-width box. Anomie⚔ 11:22, 29 March 2022 (UTC)
nowrap is bad. It's a webpage, they are supposed to wrap flexibly and you cannot predict all the content and all the widths that this content is rendered at. Every time ppl introduce more nowrap, it is just waiting for the next report where it has broken something else. In my opinion it should never be used for anything over say.... 10 characters long. —TheDJ (talk • contribs) 09:48, 30 March 2022 (UTC)

Proposal for Template:Template help

Hi everyone, I realise that we have templates such as {{Help me}} & {{Admin help}} that categorises the pages where it is used, so that other editors/admins can respond to their queries. Now, I also realise that even unprotected templates (& template styles/modules) can sometimes be very complicated for the average editor to understand or edit. Currently, for them to seek help or suggest a reasonable change, they'd have to ask other editors directly on their talk page. I think a template {{Template help}}, like Admin help would be much efficient & useful for such editors seeking help. Thanks! ---CX Zoom(he/him) (let's talk|contribs) 07:14, 26 March 2022 (UTC)

They can ask at the technical village pump. Graham87 09:09, 27 March 2022 (UTC)
I believe it's better to separate mere requests for help from technical village pump, the way we separate requests for admin help from Administrator's noticeboard. Thoughts? ---CX Zoom(he/him) (let's talk|contribs) 09:27, 27 March 2022 (UTC)
An interesting idea. It would neatly identify and collate the request, and ping the watchlists of those who maintain that template. On the other hand, it would take the request off VPT which is watched by many people who could help and might not monitor the category. Certes (talk) 11:46, 27 March 2022 (UTC)
This is not me opposed to the idea, but what's wrong with using {{help me}} in these situations? Primefac (talk) 12:21, 27 March 2022 (UTC)
Great idea. Articles can be edited by almost anyone, whereas editing most templates requires skill in coding. I used to use {{edit request}} on templates (as instructed in the header of protected templates) and was often rejected as 1. establish consensus (even for non-controversial changes) or 2. failure to say "change x to y" (which requires specialized coding skill). I've since learned to look though the history for an TE that has recently worked on the template or ping someone I know is likely/willing to make the change. It would never ask for this kind of help at VPT, and {{help me}} is similarly general. I'm sure a specific cat for template help would be monitored by prolific template editors with the right skills and interests. MB 17:03, 27 March 2022 (UTC)
  • Instead of a new template it would be good to have a mechanism to alert users that questions can be asked at WT:WPT (WikiProject Templates). That way, multiple people will see the question and be able to respond. Johnuniq (talk) 22:13, 27 March 2022 (UTC)
    I think that's a better option; I have too many cats to keep track of as it is, and honestly the only reason I'm able to respond to {{help me}} requests is because there's a bot in the -helpers IRC channel that pings whenever someone's used it. Primefac (talk) 09:37, 28 March 2022 (UTC)
    I understand that this would add to the number of tasks many editors have to keep an eye on. But, as Certes notes above, this system would ping the template's maintainers' watchlists to review the requested changes themselves, allowing them to review the requested change. Maybe we can add one more task to the bot which pings the IRC if there is some backlog, say 5 requests, using this template. Or when, a request is unanswered for, say 5 days, a bot automatically moves it to WP:WPT or WP:VPT. ---CX Zoom(he/him) (let's talk|contribs) 21:05, 30 March 2022 (UTC)

Moving "Sitting Bull" to "Tatanka Iyotake"

Wrong venue. Use WP:RM. —Kusma (talk) 12:07, 1 April 2022 (UTC)

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.

We need to known the real name, not the nickname. Please do this treatment to other languages of Wikipedia. — Preceding unsigned comment added by CafeGurrier66 (talk • contribs) 10:31, 1 April 2022 (UTC)

No, we don't. We use the most common name, which in this case is "Sitting Bull". Not only that, but the name you want to use is literally the fourth and fifth words of the article at Sitting Bull, moreover, Tatanka Iyotake redirects to the article at its current name. I suggest you close this section, as it's very unlikely to go anywhere. Happy days ~ LindsayHello 11:31, 1 April 2022 (UTC)
Also, the proper process for move requests is WP:RM, not here. Iffy★Chat -- 11:50, 1 April 2022 (UTC)

Help

Use Support if you agreed or Oppose if you disagreed

Support

If you agreed, type your rational here

Oppose

If you do not agree, type here your rational CafeGurrier66 (talk) 10:31, 1 April 2022 (UTC)

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

Allow emails from brand-new users

Addressed at VPT. — xaosflux Talk 14:03, 1 April 2022 (UTC)

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 word "brand-new users" in the preference should be wikilinked to "WP:AUTOCONFIRM". (Context at Wikipedia:Village_pump_(technical)#"Allow_emails_from_brand-new_users") Venkat TL (talk) 13:16, 1 April 2022 (UTC)

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

Proposal to extend April Fools Day

Narrator: "The Wikipedia community, aghast at the audaciousness of the proposal, is stunned into silence. They allow the opportunity to slip by without comment and it elapses." Trouts to all Rainbow troutWhack! (non-admin closure) {{u|Sdkb}} talk 04:52, 2 April 2022 (UTC)

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.

So we sadly have less than half an hour left before April Fools Day ends and we all have to go back to be super serious editors. Given the unquestionable positive impact April Fools Day has had on our project and community, I consider this to be a shame. Further, like most years this April Fools Day fell over a school/work day, meaning many of our editors barely got to participate. In light of all of this, I think some changes are in order: we should extend the April Fools Day tomjerryfoolery to cover the entire month of April! Let me know what you all think please. Spirit of Eagle (talk) 23:35, 1 April 2022 (UTC) [April Fools!]

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.

Highlight the syntax highlighter with a ONE OFF message when we open the source editor

Tracked in Phabricator
Task T305424

I have been editing for years and only just found out by chance that there is a syntax highlighter. It seems that https://phabricator.wikimedia.org/T288161 will probably turn it on by default for new accounts. But that it won't be obvious for existing users https://phabricator.wikimedia.org/T174145

When someone opens the source editor but has syntax editing turned off could a ONE TIME message be displayed to ask whether we want to turn on syntax highlighting? Chidgk1 (talk) 07:04, 23 March 2022 (UTC)

This might be feasible, but I don't know which team would work on it. Let me ask around for a few days... Whatamidoing (WMF) (talk) 00:12, 25 March 2022 (UTC)
  • @Whatamidoing (WMF): Are we still in the asking around "for a few days" frame? The idea seems worthy of consideration and shouldn't be archived (nine days) for lack of traffic if still being pursued. -- Otr500 (talk) 06:42, 2 April 2022 (UTC)
    I'd definitely like to see some movement on this. The community has made clear we like this feature, and the ball is now in the technical folks' court to either implement something or send a specific proposal for us to consider. {{u|Sdkb}} talk 06:54, 2 April 2022 (UTC)
This section should be excluded from archiving while this is being worked on. -- Otr500 (talk) 08:25, 2 April 2022 (UTC)
Sorry about the delay. We have some progress (phab:T305424) but no promises of real action. This is one of those small requests that no team is actively assigned to handle. I haven't encountered any significant opposition to the idea, but I also haven't found anyone volunteering to make sure that it happens soon. Whatamidoing (WMF) (talk) 02:44, 5 April 2022 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_188&oldid=1082604189"