:::::::As an information consumer, one can purchase the traditional ''Britannica'' implying they pay to expect information that is concise, reliable, objective, correct and understandable. Wikipedia is free, and there are no such expectations, as is clearly stated in Wikipedia's own literature. As it is also clear from Wikipedia's own processes, otherwise we would not be discussing this. My own assumption as a Wikipedia reader is, if I can't verify it, it is useless. Garbage that just wasted my time. It doesn't matter how well presented, it still stinks. [[Special:Contributions/74.64.150.19|74.64.150.19]] ([[User talk:74.64.150.19|talk]]) 13:54, 8 February 2022 (UTC)
:::::::As an information consumer, one can purchase the traditional ''Britannica'' implying they pay to expect information that is concise, reliable, objective, correct and understandable. Wikipedia is free, and there are no such expectations, as is clearly stated in Wikipedia's own literature. As it is also clear from Wikipedia's own processes, otherwise we would not be discussing this. My own assumption as a Wikipedia reader is, if I can't verify it, it is useless. Garbage that just wasted my time. It doesn't matter how well presented, it still stinks. [[Special:Contributions/74.64.150.19|74.64.150.19]] ([[User talk:74.64.150.19|talk]]) 13:54, 8 February 2022 (UTC)
::::::::What is "traditional Britannica"? I know about Britannica online and what I said is true of it. I don't know about another Britannica. I have no idea what you mean about "liability" - you mean you can sue them? Of course they have professional managers, but so does almost every medium sized company. And you should not assume that because there are no citations that an article is correct. This is waste of time. [[User:Doug Weller|<span style="color:#070">Doug Weller</span>]] [[User talk:Doug Weller|talk]] 14:59, 8 February 2022 (UTC)
::::::::What is "traditional Britannica"? I know about Britannica online and what I said is true of it. I don't know about another Britannica. I have no idea what you mean about "liability" - you mean you can sue them? Of course they have professional managers, but so does almost every medium sized company. And you should not assume that because there are no citations that an article is correct. This is waste of time. [[User:Doug Weller|<span style="color:#070">Doug Weller</span>]] [[User talk:Doug Weller|talk]] 14:59, 8 February 2022 (UTC)
:::::::::One of the small minority of articles in Wikipedia that are more or less adequate is the one on ''[[Encyclopædia Britannica]]''. Maybe it is a starting point for information about it that you can't find. But this is getting off-topic. The OP asks if a metric present in every article regarding accessibility of sources is something that should be done. Are there any substantive points against it, technical or otherwise? It seems sensible, and an improvement. [[Special:Contributions/65.88.88.47|65.88.88.47]] ([[User talk:65.88.88.47|talk]]) 16:34, 8 February 2022 (UTC)
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)[reply]
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.
Option 1. Clean look and close enough to the original. I would also be open to moving away from the Adobe Acrobat logo if someone comes up with a different icon, since the company no longer holds a monopoly over the format. Yeeno (talk) 🍁06:01, 8 September 2021 (UTC)[reply]
Since this option is proving popular, but some have correctly pointed out that the "PDF" text is hard to read, I've created a version which is better optimised for small sizes: File:PDF icon.svg. Please feel free to tweak it further. – Joe (talk) 12:37, 8 September 2021 (UTC)[reply]
Option 2, and concur with Joe that the Adobe logo is mega fail. The icon he posted in the comment above this one seems good, and it's an SVG, which is better than the tiny GIF being used currently as it can be rendered at any size without looking terrible. jp×g06:34, 8 September 2021 (UTC)[reply]
Option 2 The icon must change. The old thing is a relic of the dark ages. Initially I thought ooh the adobe svg looks great. But Adobe are no longer the pdf overlords, and I don't rather like Adobe, evil empire of tech that it is. Joe's suggestion of the generic PDF SVG is the perfect solution. CaptainEekEdits Ho Cap'n!⚓06:42, 8 September 2021 (UTC)[reply]
Comment is licensed as copyright free but is licensed as GPL which could make a diffence as to how it can be used without any linking back to the file. -- WOSlinker (talk) 07:36, 8 September 2021 (UTC)[reply]
Option 2: PDF is no longer specific to Adobe, so let's remove their logo. Option 1 (File:Icon pdf file.svg) looks ideal when enlarged, but the letters are hard to distinguish at icon size. I suggest a new copyright-free SVG with even larger letters (They won't occupy many pixels.) Certes (talk) 11:40, 8 September 2021 (UTC)[reply]
Given that someone added the "ditch it entirely" option 4, put me in that camp as first preference with a fallback to 1, 2, or any other reasonable icon that isn't the old one. I am not strongly persuaded, as below in re to Ivanvector, that we must make these icons more accessible. What I would prefer to see is the block of CSS in Common.css removed and for everyone to enjoy a marginally faster page load. --Izno (talk) 19:07, 9 September 2021 (UTC)[reply]
Still Option 2 (even after addition of an Option 4, edited 20:28, 9 September 2021): Although "oppose any changes" seems pretty strong, I was leaning toward Option 3 since the proposal seemed to be based on the argument It's a .gif made over 16 years ago, with no explanation of why that's bad. Personally, I'd rather use a 291-byte file than one 6 KB in size, ceteris paribus. But then, despite the weird threading, I noticed the replacement suggested by Joe Roe. It doesn't have the Adobe logo or (*gag*) name on it, it's clearly for PDFs, and it's only 2 KB in size. So if we're going to change, let's change to something like that. This one (, 707 bytes) works for me, too. — JohnFromPinckney (talk / edits)12:04, 8 September 2021 (UTC)[reply]
I don't think the file size matters here, because what is actually downloaded by your browser is a server-rendered bitmap of the appropriate size, not the original SVG. That's approximately the same for all the files,[1][2] and less than 1 KB. Also, "weird threading"? – Joe (talk) 12:18, 8 September 2021 (UTC)[reply]
Did not know about the different download file, thanks. And it wasn't actually so much weird threading as it was confusion on my part from JPxG's contributions. My too-quick reading saw the big file image at the upper right, which wasn't either the current icon nor the proposed replacement. When they wrote concur with Joe that the Adobe logo is mega fail I thought they were agreeing with the proposer (which you're not) that the icon was mega fail (although that wasn't clear why). Then JPxG also said there's some pretty great icons in that category [sic], which would have been more appropriate, IMO, as a reply to your 06:15 post, not as a reply to themself. I got a bit lost. Confusion on my part from scanning too quickly, and thinking too slowly. — JohnFromPinckney (talk / edits)14:52, 8 September 2021 (UTC)[reply]
This is untrue in the context of CSS-loaded images (I am not sure whether you meant to distinguish). SVG images are sent as SVGs to the end user when loaded by CSS. In the context of this proposal, we would be making modifications to the CSS, so the end user would receive an SVG at the size of interest.
In the context of any old generic file wikilink, yes, SVGs are rendered to bitmap and served as PNG automatically. Changing that behavior – to use SVGs more directly – is ancient phab:T5593. Izno (talk) 19:11, 9 September 2021 (UTC)[reply]
I suppose the problem isn't directly that "[i]t's a .gif" but rather that it has a fixed resolution looking pixelated on modern screens, while a vector version would be rendered in an appropriate resolution on any device, as Joe pointed out. ~~~~ User:1234qwer1234qwer4 (talk)15:22, 8 September 2021 (UTC)[reply]
Unstriking my !vote above, as I find I still prefer Option 2. The target proposal in Option 1 is now even less appealing, as the new target File:Icons-mini-file pdf.svg looks even worse at 16px on my device than the old target File:Icons-mini-file pdf old.svg. The newly added Option 4 is okay, I guess, after Option 2, but I personally appreciate having an indication of PDF-ness. I sometimes use a different reader than the one my browser tries to use by default, or I can choose to save the PDF file somewhere for later perusal. — JohnFromPinckney (talk / edits)20:28, 9 September 2021 (UTC)[reply]
JohnFromPinckney, in citations there's already "(PDF)" as an indicator, seemingly added by {{Citation}}. Exactly how this is stylized is up for debate (Ahecht made a suggestion below), but the indication is already there without any icon. — Alexis Jazz (talk or ping me) 20:50, 9 September 2021 (UTC)[reply]
Yes, thanks, Alexis Jazz. That means we get icon and "(PDF)" with a CS1|2 template (<ref>{{cite web |title=With cite template |url=https://example.com/Adobe.pdf}}</ref>),[1] and just the icon without one (<ref>[https://example.com/Adobe.pdf Without cite template]</ref>).[2] What would be good for me is to drop the icon but replace it with the textual "PDF" indicator, which I guess would be an Option 5. — JohnFromPinckney (talk / edits)19:19, 11 September 2021 (UTC)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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·des20:29, 8 September 2021 (UTC)[reply]
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·des21:40, 8 September 2021 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)\][reply]
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)[reply]
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 [3]. This is the visual counterpart to the external link icon [4]. 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)[reply]
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)[reply]
I support Option 2 () because it seems the best visual indicator of a PDF. I oppose just using text; the image makes it stand out that it's a PDF. ― Qwerfjkltalk19:04, 13 September 2021 (UTC)[reply]
Option 2. Concur about change from corporate logo; but there's a problem, because we don't seem to be moving towards any consensus whatsoever about what is the substitution. I believe the PDF Google PDF icon is the most legible and does not cram white letters into a red background, which the colour-blind may not see, and that against a white sheet of paper with abnormally thick black margins. Keep it simple, really; there is no obligation for us to keep that red stripe. Szmenderowiecki (talk) 09:46, 14 September 2021 (UTC)[reply]
we don't seem to be moving towards any consensus whatsoever about what is the substitution that's not a problem because this discussion is explicitly not intended to determine that. If (as seems likely) option 2 gains consensus there will be a second discussion to determine what the replacement should be. Thryduulf (talk) 12:23, 14 September 2021 (UTC)[reply]
Option 2 Any icon containing the letters PDF. The best so far seems to be PDF icon.svg, followed by PDF icon bold.svg, but perhaps a version with black/dark blue lettering could be better? — GhostInTheMachinetalk to me08:35, 15 September 2021 (UTC)[reply]
Option 2. Perhaps the new symbol, to be determined, could be a piece of paper with a folded corner (As is seen in most file format icons) with the letters "PDF" on it? Clear of copyright concerns and adobe attachment. (EDIT: Just learned that the comments below indeed have this idea covered) Plutonical (talk) 14:55, 29 September 2021 (UTC)[reply]
Option 2 - PNGs including a 2x resolution version for HiDPI displays. I like with its crisp, white-on-red "PDF" banner across the file, but it needs to stay crisp on high-res displays and that PNG will look bad. User:GKFXtalk17:16, 11 October 2021 (UTC)[reply]
Option 2. The svg is good work, and an improvement over the gif. I don't dislike it, but I like supporting "undisputable" non-commercial generic work much more. So, please go with a generic svg version that has a readable PDF acronym on it. (This one looks best: ) Thanks. Huggums537 (talk) 03:31, 16 October 2021 (UTC)[reply]
Option 2 - clearer than the original and is an improvement (especially since it drops the logo attempt). Oppose option 4, as I believe there is usefulness to pointing it out in both image and text form (see WP:RICHMEDIA, among other things). Hog FarmTalk06:19, 21 October 2021 (UTC)[reply]
Option 2 – the most sensible choice, we should not be tying ourselves to adobe if we can avoid it. HF above sums up my sentiments as well. Aza24 (talk) 00:31, 25 October 2021 (UTC)[reply]
Option 2: get rid of the Adobe logo as first choice, anything with the letters "PDF" will do but is the best. Second choice is to update the extremely pixellated Adobe logo to the new one. — Bilorv (talk) 12:00, 26 October 2021 (UTC)[reply]
Option 4 Most modern browsers can handle PDFs without difficulty, so I think it might be time to eventually remove the icon altogether. Oppose any lettered icons as looking too 90s-esque compared to the sleek Adobe-triangle. – John M Wolfson (talk • contribs) 22:03, 29 October 2021 (UTC)[reply]
Comment restored from the archive. While I am involved here, it's very clear that "no change" (option 3) is not the consensus so someone uninvolved should determine what the consensus is and take the appropraite next steps. Thryduulf (talk) 23:10, 10 January 2022 (UTC)[reply]
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)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. MB14:48, 12 January 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
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)[reply]
I oppose no icon, because highlighting that a link is not an HTML page is useful information for accessibility - not every device can (easily) read PDF files. Thryduulf (talk) 18:28, 29 January 2022 (UTC)[reply]
Update following Thryduulf's note below: Still sticking with A. C is marginally better than B, but A definitely looks by far the clearest. — Amakuru (talk) 11:38, 29 January 2022 (UTC)[reply]
Further comment: I've checked on my phone too, and actually C is indeed very slightly better than A there, which might be what others are seeing, but A still looks fine on mobile, so A remains the clear victor overall given the much better rendering on my Windows 10 / Chrome setup. — Amakuru (talk) 11:42, 29 January 2022 (UTC)[reply]
Option A, C is second, B is nope. In general C seems to be a better file, but when scaled down to 16px for this use case, A seems clearer while C gets a bit of a blur effect. At larger resolutions, I'm seeing the reverse. — xaosfluxTalk11:27, 29 January 2022 (UTC)[reply]
Option A or C: A hard decision for me. On my PC, A is clearly the best, whereas on both my phone & tablet (using mobile version), C appears to be the best. B is last on all platforms though. ---CX Zoom(he/him)(let's talk|contribs)11:58, 29 January 2022 (UTC)[reply]
Option D: get rid of it. Links to files can be indicated with the text "(PDF)", no need for any icon. The option to get rid of it was introduced too late in the first discussion so it couldn't gain enough traction. — Alexis Jazz (talk or ping me) 12:37, 29 January 2022 (UTC)[reply]
Option A or B: A looks slightly better on my laptop. Surprisingly, B is clearer on my mobile. C is a close third on both. I suspect this is very device- (and perhaps eyesight-) dependent; any of the three would be an improvement. Certes (talk) 12:45, 29 January 2022 (UTC)[reply]
D (no icon) - My preference remains to use a non-icon, text marker, like (PDF), or even stylized text, like this: PDF. Icons are more taxing, client and server side, than text, and while PDF icons won't make a big difference on the client side, and we can handle it on the server side, this website is only going to get bigger, and I see no reason to burden it with image icons when text will do. Option A looks better on my desktop; it's a PNG. C looks better on my iPhone; it's an SVG. But on my iPhone, I can't see any of the icons clearly enough to make out "PDF" because of the small screen, unless I zoom in. Also, text is word-searchable, where as icons are not. I just don't see any benefit to using any icon over text. Levivich16:42, 29 January 2022 (UTC)[reply]
Option A or D (no icon): Option A if icons are preferred, but they aren't that necessary. "(PDF)" is five characters, direct and concise. ResPM (T🔈🎵C) 16:54, 29 January 2022 (UTC)[reply]
Option A or D (stylized text: PDF as suggested by Levivich) I think "A" is the best icon if we have to use an icon, but I believe the idea of stylized text is even better, and it should be presented as one of the options in these discussions. Huggums537 (talk) 17:07, 29 January 2022 (UTC)[reply]
What I mean is the stylized text should be presented as an option if there are future discussions as you indicated might happen per your original post by option D. So, we still have yet to see if that discussion will take place or if consensus will call for that option to be presented. Huggums537 (talk) 14:29, 30 January 2022 (UTC)[reply]
"No icon with '(PDF)'" is not technically feasible for generic old links to PDF, so it would need to be policy mandated somewhere or another. "No icon and nothing else" of course is quite feasible. :) My preferences are "no icon at all" (and I don't care about whether it becomes policy or not, but good luck getting that into MOS where it would likely live) followed by A or C (slight preference to A). Preferences exclude B totally. --Izno (talk) 17:52, 29 January 2022 (UTC)[reply]
Levivich What makes you think it would be technically feasible, given that some PDFs do not live in a CS1/2 template or any other template, of which someone or another might have been thinking when they made that proposition? :) Consider WP:CONTEXTBOT in context of any response you might have. Izno (talk) 18:26, 29 January 2022 (UTC)[reply]
@Izno: We have a robot helicopter flying on Mars, is one thing that makes me think it is technically feasible to add "(PDF)" after a link to a PDF on a website. Are you using the words not technically feasible to convey the meaning that a bot that changes PDF icons to text would violate WP:CONTEXTBOT? Because that is not what I think of when I think of the words technically feasible in the context of changing how a website works. Levivich18:31, 29 January 2022 (UTC)[reply]
That is precisely what I mean when I use the word technically feasible, as in technologically feasible, if that makes it easier for you to parse the words. If you think a change to MediaWiki for this would be accepted upstream, I am here to tell you that you are simply wrong, for the same reasons as CONTEXTBOT says. A bot would run into contextbot of course. That leaves a gadget to add it at any given edit time, or editor willpower to do so. Either way, it is not technically feasible to add the words after a link of interest automatically in such a fashion. Izno (talk) 18:41, 29 January 2022 (UTC)[reply]
That is not what I understand "technically feasible" or "technologically feasible" to mean: both those phrases mean there's a technical problem, as in, a software or hardware limitation. A policy prohibition is not a technical problem. I'm glad you've explained it, because heretofore, I understood you to be saying the software can't do it.
No. There is no CSS that will do this for you accessibly, which I presume is the reason you want the parenthetical PDF in the first place. Izno (talk) 18:58, 29 January 2022 (UTC)[reply]
Again, can you explain, rather than assert, why this cannot be done accessibly? What's inaccessible about :after and content: ? Levivich19:00, 29 January 2022 (UTC)[reply]
Ah, thanks for that explanation. Isn't the way it's done currently, with a CSS background image showing a PDF icon, also not web accessible? (It's Failure Technique 3.) So whether we change the icon, or we use text, it makes no difference to accessibility? Levivich19:56, 29 January 2022 (UTC)[reply]
Correct, no external URL icon is accessible. There is an argument that can be made that this is a case of progressive enhancement of course, since the CSS icon/text can be argued are extraneous to a well-titled URL. Izno (talk) 22:13, 29 January 2022 (UTC)[reply]
I prefer SVGs as a concept so option C. The image is not blurred at all, but may have been rendered as such on some browsers. Stifle (talk) 10:59, 31 January 2022 (UTC)[reply]
@Stifle: AIUI, the icon has to be a raster image and so if an SVG is chosen it will be a PNG rendering of the SVG that is displayed. I don't know if that makes a difference to your view. Thryduulf (talk) 12:10, 31 January 2022 (UTC)[reply]
Option A or D, as what there have been good arguments for both sides. Low-res text and Plaintext are both good ideas for cross-platform readability, and I am having a hard time choosing between them. ☢️Plutonical☢️ᶜᵒᵐᵐᵘⁿᶦᶜᵃᵗᶦᵒⁿˢ12:01, 31 January 2022 (UTC)[reply]
Still-unanswered question regarding.svg/.png formats: do we know that both are equally good (although that seems in some conflict with the note in the RfC close above)? I get different results depending on my device. The SVGs are better on my phone; the PNG is better on my desktop. — JohnFromPinckney (talk / edits)12:13, 31 January 2022 (UTC)[reply]
Option A. These appear slightly differently on different browsers, desktop vs mobile etc. probably due to the SVG scaling. I've tested a few and A looks acceptably clear on all of them. C is maybe slightly better when using Safari on mobile, but looks blurry on Firefox desktop. B has the same problem and the bold text is a bit overwhelming. Option A looks good everywhere I tried. It's also the smallest file size of the three, by an order of magnitude. Modest Geniustalk14:06, 31 January 2022 (UTC)[reply]
Option A, with weak support for Option D, looks less blurry than Option C, however I have weak support for D since, if implemented correctly, it just saying (PDF) is fine, however as just plain text it looks weird. ― Blaze WolfTalkBlaze Wolf#654514:47, 31 January 2022 (UTC)[reply]
Option D per the Ahecht example. A-C are all blurry to me with my normal browser and screen size and I can't really read the letters. I can recognized it means PDF by the red band. I would prefer not to go through that mental conversion and just have something clearer. A icon should be as discernible as the rest of the page. MB15:42, 31 January 2022 (UTC)[reply]
Option C/A (don't care which) but also I am still bitter that Option 1() didn't pass from the first RFC (so sorta Option D). It's a lost battle though. Whatever gets us done with the dang gif file faster is basically what I support (except Option B which just looks too silly in my opinion). –MJL‐Talk‐☖00:18, 1 February 2022 (UTC)[reply]
Option A - Definitely looks better on desktop, slightly fuzzier than C for me on mobile but not bad. B doesn't look great on either. Not a fan of "(PDF)" in text but the stylized text suggested by Levivich seems like an ok secondary option. Retswerb (talk) 04:32, 1 February 2022 (UTC)[reply]
Comment: Building on Levivich's text-based proposal and combining the pictures' visual elements into it, I made one that looks like this: PDF The text on it is sharper than it is in pictures, while also retaining the visual elements typically used to denote pdfs. Any suggestion from the community? ---CX Zoom(he/him)(let's talk|contribs)13:44, 1 February 2022 (UTC)[reply]
My initial reaction on a desktop (not looked on other devices yet) is that it's significantly larger than any of the icons, more dominant of its surrounds (not a good thing in this context) and no clearer than option A. Thryduulf (talk) 15:55, 1 February 2022 (UTC)[reply]
I see the same as Thryduulf. I think this idea could be better than A, B or C and is worth pursuing, but that particular implementation isn't a winner. Certes (talk) 18:05, 1 February 2022 (UTC)[reply]
Option B – Nice bold text, perfectly visible. Especially on higher density screen like mine with scale set to 125% it looks okay and is perfectly readable. — Polda18 (talk) 19:05, 1 February 2022 (UTC)[reply]
Option D ~no icon + text, per Levivich and others; if we have to have an icon, Option B is the only one readable on my screen. Happy days ~ LindsayHello09:15, 5 February 2022 (UTC)[reply]
Automatically generate a record of the contents of deleted categories at the time of deletion
When an article is deleted, a record of the contents of the article at the time of its deletion is maintained and is accessible to administrators. Moreover, when an article is merged or redirected, the contents of the article previously at that title typically remain visible to all editors. However, when a category is deleted and links to that category are removed from pages categorized therein, the central set of data of what articles were contained in the category prior to its deletion is lost forever.
There's also the question of when to preserve the snapshot of contents. Categories are typically emptied before being deleted when empty. Certes (talk) 12:43, 19 January 2022 (UTC)[reply]
Is this even possible? Is there a way to track what pages are listed in a category at any given time? Unlike other pages, additions and subtractions to categories are not made on the category page itself... so we can not simply hit the "view history" button to easily see the additions and subtractions (changes) made over time. Indeed, one of my pet peeves is that day to day changes to category pages don't show up on one's watchlist. Blueboar (talk) 13:58, 19 January 2022 (UTC)[reply]
Frankly, that is not as useful, since different editors may take up parts of the task, and hunting through pages of a bot's edit history is quite a bit harder than having a single accessible list. BD2412T16:29, 19 January 2022 (UTC)[reply]
I remember reading discussions over a decade ago where editors were counseling fellow editors to not bother with categorization matters. CFD is one more venue for editors who are off in their own little world, unconcerned with the health of the project as a whole. What is the purpose of someone picking low-hanging fruit by proclaiming "Oh, this should be a list" and the end result is no list? RadioKAOS / Talk to me, Billy / Transmissions 07:20, 20 January 2022 (UTC)[reply]
One of the drivers for this request is that I see CfD discussions where at least some participants propose that the category would be better as a list, but then the category gets deleted with no such list being made, and no easily accessible record remains of what was in the category prior to deletion for the creation of such a list. Perhaps "judges who died in office" would have been better as a list article, but the category was deleted and its hundreds of entries decategorizes, so the rather painstaking process of identifying all the judges who died in office would need to be started from scratch. BD2412T07:31, 20 January 2022 (UTC)[reply]
Preserve at Wikidata?
I've been concerned about this for a while, as it seems that WP:CfD has tightened up their interpretation of WP:DEFINING, which is a valid approach for categories but one that risks deleting information we might like to use elsewhere. The solution I'd like to see is a task force at Wikidata that takes to-be-deleted categories and ensures that the information in them is imported to Wikidata before they are deleted. For instance, the Eagle Scout categories were deleted as non-defining a while back, and it would've been nice if we'd ensured that everyone in them had e.g. award received (P166) = Distinguished Eagle Scout Award (Q5282987) added to their Wikidata item first. This would both make it easy to resurrect categories if we decide we want them in the future, and would allow them to continue to evolve, with contributions from other languages. Cheers, {{u|Sdkb}}talk03:11, 20 January 2022 (UTC)[reply]
I don't know that Wikidata will preserve all the variables that might go into a Wikipedia category that ends up deleted. For example, does Wikidata have a parameter for "died in office", or for "organizations formed by merger", or for "diseases characterized by inflammation"? BD2412T06:09, 20 January 2022 (UTC)[reply]
@BD2412, okay, so I'm by no means an expert in representing things on Wikidata, but I'll take up the challenge for those three:
That is indeed a surprising level of data refinement. I presume Wikidata has some functionality for generating lists of subjects with the specified characteristics? For example, if I want to find people who were judges, and who died in office? BD2412T06:38, 20 January 2022 (UTC)[reply]
The aforementioned property "Category:People who died in office" only collects category pages in other wikis equivalent to the deleted category on this wiki. The property "death in office" is different. You can go to "What links here" in the left menu and get a list. The only problem, it's the same hodge-podge of names cited as part of the CFD rationale. I'll leave it to Sdkb to explain how to refine that further, given the proficiency they've shown in navigating the site. RadioKAOS / Talk to me, Billy / Transmissions 07:34, 20 January 2022 (UTC)[reply]
For any information held in Wikidata, it is possible to form a database query that will retrieve it. As with all Wikimedia projects, Wikidata is a work in progress, so the data is constantly being populated, reviewed and refined. Depending on what you are wanting to find, we may have a lot of high quality data already available, or we may have a large amount of lower quality data that you will need to sift through. If you have additional parameters, you can narrow your search to make your sifting of the data easier. For example, you could look for entries with death in office (Q5247364) and date of death (P570) = 1836. I am not an expert on queries but there is a beginner query tool available at Wikidata Query builder. Users who are familiar with SPARQL will have a greater range of scope for their queries. From Hill To Shore (talk) 14:16, 20 January 2022 (UTC)[reply]
I would take issue with "tightened up their interpretation of WP:DEFINING". There's still next to zero interest in owning up to the problem of countless biographies which categorize the subject only according to their birthplace, when their birthplace has nothing to do with their notability while another place has everything to do with their notability. This POV also often manifests itself through WikiProject tagging on the talk page. RadioKAOS / Talk to me, Billy / Transmissions 07:20, 20 January 2022 (UTC)[reply]
Eventually, I hope all information in categories will be imported to Wikidata, and that we'll use Wikidata to construct the category system as Rhododendrites has envisioned. But in the meantime, with limited editor resources, I think it makes sense for Wikidata to focus on the information with a deadline, i.e. categories about to be deleted. {{u|Sdkb}}talk02:28, 21 January 2022 (UTC)[reply]
Refocus
Whether this is something Wikidata can take up in some form, or that can be tracked down in the edit history of a bot, I think that it would be a minimal technical burden and great benefit to preserve this data in an accessible list in Wikipedia project space. I am wondering whether there is any specific objection to this proposal. BD2412T22:42, 25 January 2022 (UTC)[reply]
Oppose, with alternative. If something has consensus to delete (rather than to reformat or rewrite in a different way), I object to keeping it not-deleted in perpetuity. I think it sounds like a Draft with no 6-month timer, but one that even nobody is actually stating they plan to work on (akin to user-space revival of deleted content). It sounds like the goal is to be able to revive or revisit it in the future, not specifically keep it visible to all readers and editors for all time. So how about making an edit that writes the list of the cat's contents into the cat page itself at the time of deletion? Then an admin can see it but others can't, and the empty+delete action can be undone in the future--all same as a deleted page from any other namespace. DMacks (talk) 08:19, 27 January 2022 (UTC)[reply]
That precludes anyone other than admins working on such a list, which is not desirable. I'm unsure what harm comes from having these pages listed in perpetuity in general (specific exceptions would of course be eligible for MfD), but a normal draftspace page would seem to resolve any issues that exist - e.g. if Category:People with honorary degrees from the University of East London were deleted in favour of a list, then the categorised pages would be written to a list at Draft:List of people with honorary degrees from the University of East London, which would give everybody the chance to work on it. If nothing was done for 6 months then it would be deleted per G13 as any other draft. No need for special procedures or new rules. Thryduulf (talk) 11:30, 27 January 2022 (UTC)[reply]
Those concerns are reasonable. It's true that there are different reasons categories might be deleted, but a common one and I think the one that's most salient here is just categories that are judged too trivial to be WP:DEFINING. I continue to think that porting information to Wikidata rather than to draftspace is the best option, since it can be preserved there in perpetuity and Wikidata doesn't generally care if more trivial information is added to an item. {{u|Sdkb}}talk17:55, 27 January 2022 (UTC)[reply]
Support the data often still exists, publicly available, somewhere in the world (e.g. Category:People who died in office - 07 March 2021); as long as it doesn’t show up in the default search, is there really that much harm in making it easier to access?
Perhaps a ‘last version prior to deletion’ link (even only if off-wiki) on the ‘page does not exist' page?
What about a ‘Deleted’ namespace, for … okay, there are potential name (and thus history) collision issues there … unless deleted content in that namespace had a unique identifier, such as the date deleted, appended to the name.
That might be able to preserve the edit history as well, which would solve for the “everything was removed from the category before it was deleted” issue. (We already have procedures for redacting articles / history that shouldn’t be seen by anyone.)Jim Grisham (talk) 13:16, 27 January 2022 (UTC)[reply]
Major problem is that often a category will be slowly deprecated - with things getting removed from it - or even more rapidly if they are in it via templates - the "moment of deletion" may not be the most relevant time. Strong oppose making a policy that places an administrative burden on admins to make such a export-paste list before any deletion can be carried out. — xaosfluxTalk13:21, 27 January 2022 (UTC)[reply]
I like that idea. Even better, such a bot could be written and operated today, without need for approval or consensus, if the category lists were published in the bot's userspace or as text files on toolforge. I'd do it but I'm not exactly drowning in free time right now. I'll tag in BOTREQ, though. Enterprisey (talk!) 07:45, 30 January 2022 (UTC)[reply]
WP:REFILL is a popular citation maintenance tool with great power, and likewise power to cause great harm. It has been largely abandoned for years, in terms of fixing bugs. The number of errors it creates is increasing with time. Its usage is increasing with time. The talk page is full of bug requests. The home page is full of warnings. The GitHub page is full of bug reports.
These are countless examples of bugs, here are two:
edit and fix required (note the user in this case has only ever edited Wikipedia in one article)
Many editors like reFill, when it works. However, many editors are also not fixing the problems it creates. The errors are increasingly complicated and difficult to determine. By letting the tool run rouge we are causing significant damage to the project. Blocking does not need to be permanent, restoration only requires someone to actively maintain and respond to bugs.
Alternatives to blocking are only for approved users, similar to AWB due to it's powerful ability to cause harm, only proven responsible editors should be allowed. How these things might be technically implemented (block, approved users) is unclear but I believe both are technically feasible with some investigation depending what the community wants to do if anything.
Option A - Do nothing.
Option B - Approved users only.
Option C - Block until most known bugs are fixed.
Option D - Something else.
Poll (block reFill)
Option C. Per nom. This is more a vote for more robust software than anything else really. Old enough to remember a time when no software with known bugs would ever be put, or continue to be, in production. It is true, such software policies did use to apply. 50.74.109.2 (talk) 01:27, 22 January 2022 (UTC)[reply]
A or B ReFill or Reflinks are helpful tools in getting at least some of the info filled in and reducing the repetitiveness of manually filling in references. I do go over the results because they often need fixing and none of these errors seem so major to me that we necessarily have to restrict access. If we do choose to, I think those of us who have proven conscientious enough in how we use the tools should still have access. – Muboshgu (talk) 17:18, 22 January 2022 (UTC)[reply]
A or D. ReFill is not perfect, and never will be. It has always come with a health warning. Its value outweighs its problems. To withdraw it, in any shape or form, will damage the project more than continuing to use it as-is. The 'D' would be to advertise for experienced developers, with the right technical knowledge and spare time to onwardly develop the tool. While there might be some quick fixes, the learning curve given little-to-no documentation and zero handover from the tool's author mean that making even the slightest change comes with too much responsibility for someone not already used to toolforge, and the whole developer stack. Curb Safe Charmer (talk) 23:13, 25 January 2022 (UTC)[reply]
Option A or D -- it's hard to get behind blocking the use of ReFill, since I often use it to write articles. While I've written software to generate full-featured proper citations from Newspapers.com, for everything else I use ReFill. It's an unimaginable pain in the ass to fill out citations manually, and I check all of my ReFill cites by hand -- I'd estimate about one out of every ten will have a couple fields that are erroneously filled in, but even then it saves me several minutes. For example, oftentimes the article's title, publisher and author are fine, but the date is messed up -- this only takes a couple seconds to fix, versus typing in all of this information or copying it from the webpage by hand, which takes forever. At the same time, I understand the importance of fixing the tool, and the possibility that doing something drastic could force some action to be taken; I certainly haven't been devoting any effort to it, despite the fact that I could probably make a couple fixes, because it works well enough for my purposes. Perhaps it would be a useful compromise to block ReFill from being used in articlespace, which wouldn't affect drafts or userspace pages (and if you really wanted to use it in a mainspace page you could copy the source into a userspace sandbox to use it there). jp×g07:33, 1 February 2022 (UTC)[reply]
Options B and D. I use ReFill almost daily. Being aware of the bugs, I adjust results accordingly. I think this is rather like a chainsaw—very effective for the job it does, but dangerous for the person using it without knowing how. Those who know how should not be restricted while work is undertaken to remove the bugs. BD2412T17:54, 6 February 2022 (UTC)[reply]
A or B. I use ReFill enough that I would miss it. Checking for errors is not a burden, although it would be nice if the bugs are fixed. - Donald Albury21:06, 6 February 2022 (UTC)[reply]
A or B/D, it's a tool for humans, not magic. Yes, it would be good if someone tried to fix it. Nonetheless, its results generally range from marginally improved, to improved, imo, and with care, better than that. As for process, it should not be removed from anyone, unless there is a showing of continued problems after discussion with the person. I suppose any "new" access could be restricted like a perm, were B adopted. -- Alanscottwalker (talk) 21:27, 6 February 2022 (UTC)[reply]
Discussion (block reFill)
Administrator note we could use the abusefilter to block or warn on these edits as they seem to have a consistent edit summary we could latch on to; we could also exempt certain usergroups (e.g. extendedconfirmed) or users with an editcount above something from such a filter. While possible, I expect there will be significant pushback about making a new local mediawiki usergroup just for this. If set to "warn" every use would require a reconfirmation after getting the "warning" which can say whatever we want. (Please note one of the sample "bad" edits is by a user with 3000000+ edits that is also a member of restricted groups including autopatrolled). We can not easily make an on-wiki discretionary access control list, as we do not control this software - it is hosted off-site. Traditional administrative options are also available - such as placing editing blocks on users that are making disruptive edits. — xaosfluxTalk22:55, 21 January 2022 (UTC)[reply]
The examples seem to disrespect {{cbignore}}, though one of them has the |bot=medic parameter, which presumably limits cbignore's scope to a different bot. Should a filter warn (or prevent) edits with reFill in the edit summary which remove cbignore (or cbignore without parameters)? Or is the problem more widespread, involving errors other than a failure to respect cbignore? Certes (talk) 23:49, 21 January 2022 (UTC)[reply]
@Certes: that template says it applies to "participating bots". This edit was not made by a bot it was made by a human editor. Is there a reason you think that this utility is otherwise a "participating bot"? It may be possible to code an abuse filter for that though. — xaosfluxTalk00:09, 22 January 2022 (UTC)[reply]
On reflection, I may have expressed a good idea badly. Observations: Certain citations confuse bots. Editors kindly mark these with cbignore. The two examples above are also marked with cbignore. Hypothesis: the sorts of citation that get marked with cbignore also confuse ReFill (though as a non-bot it has no duty to observe cbignore). Suggestion: detect edits where ReFill amends lines containing cbignore, and tag/warn/prevent as appropriate. Certes (talk) 14:26, 22 January 2022 (UTC)[reply]
Comment I would love for some new developers to take over this tool (and Reflinks too), to fix the numerous issues it creates for author/first/last parameters and other parameters. Thanks! GoingBatty (talk) 01:28, 22 January 2022 (UTC)[reply]
The problem is getting a modified version live, I submitted a change to fix one of the errors caused by the tool a couple of years ago. If someone could solve this problem, then pogress could be made. Keith D (talk) 19:45, 22 January 2022 (UTC)[reply]
Also see Wikipedia:Bots/Requests_for_approval/BareRefBot. On hold due to ANI thread. It just fills in the bare refs for now, but the script can be upgraded to match the capabiltities of reFill or refLinks. I think a new tool rewritten from scratch is the future (I've looked at the source code of both tools, I didn't like working with it, but that just is me) Rlink2 (talk) 19:16, 22 January 2022 (UTC)[reply]
Yes agree, best redone from scratch. Hope your bot works out and can convert all those refs before editors feel the need to run reFill. A number of people have tried to adopt reFill with little success fixing the dozens of bugs; it was written by a college student and abandoned. -- GreenC20:07, 22 January 2022 (UTC)[reply]
To anyone writing a new tool: please plan ahead and get a few more people involved in its development and maintenance. It would be greatly appreciated! isaacl (talk) 20:55, 22 January 2022 (UTC)[reply]
It is only one of perhaps 100s of reported bugs ignored for years. Is this bug even reported, and if it was, would it matter? -- GreenC20:27, 25 January 2022 (UTC)[reply]
Monitor for unusual strings by sorting by count and seeing which have high counts and manually skim off into a file the bot can reference. -- GreenC17:02, 26 January 2022 (UTC)[reply]
Note that CurbSafeCharmer is the maintainer of reFill2 on GitHub [5] . I see very little change in the code for 3 years. In the past 24hrs a few issues were closed as invalid, not due to code fixes.[6] It still leaves many open issues.[7] Plus the many talk page reports (including archived pages). There isn't much happening in the code itself. This is not blaming CSC, as they say, it is a steep learning curve and a difficult project which explains why even the "slightest change" is so difficult and never gets done. -- GreenC17:16, 26 January 2022 (UTC)[reply]
@GreenC: There were eight issues in the GitHub repo, most dating back to 2015-2017 that the author and previous maintainer of reFill should have closed - I have done so today as it makes it easier to 'see the wood for the trees'. Of the 27 open issues, almost all are enhancements requests, rather than bugs. It is a small but significant distinction. I do not see the issue raised by Rlink2 above as a bug, for instance, as it is a request for reFill to do something new that it was not designed to do - there's no existing code for that which needs fixing. Curb Safe Charmer (talk) 17:50, 26 January 2022 (UTC)[reply]
Thank you for taking a few minutes to close some years old open tickets that are no longer valid. See the talk page and example diffs for lots more (and Phab). The main thing is no one is actively coding, for years, and so this garbage data continues to get added into Wikipedia at scale. Trouble reports for tools like this should be constant, see Citation bot talk page, it's a process of continually fixing issues. The tool has been effectively abandoned by developers. -- GreenC18:22, 26 January 2022 (UTC)[reply]
I would be willing to try to work on some fixes for the most egregious misbehavior of the tool and submit pull requests -- is there a list of the biggest issues? The GitHub issues don't seem to be prioritized very well. I would also need some instructions for setting up and testing on a local instance. If I had these things, though, I could commit to at least taking a look (although a few have said the codebase is daunting, so it may not result in any progress, but it's at least worth a try). jp×g07:40, 1 February 2022 (UTC)[reply]
Yeah we've heard this in the past, people say they will adopt it then nothing much happens. Similar to Citation bot, tools like this require constant attention to adapt to changing conditions with CS1|2, MOS, best practices, etc... it's a lifestyle not a 1-time fix. The original programmer was a college student, whose code is apparently not easy to work with, who quit and moved on in life. New programmers frequently paint themselves into corners and realize they need to rewrite and find it easier to quit. Others have looked it said it would be best to start over. -- GreenC02:45, 7 February 2022 (UTC)[reply]
Well, I think JPxG is a skilled coder and programmer, and is also a very nice Wikipedia editor who is trusted and easy to get along with. I trust he is more than capable to handle whatever might come in his way. And besides, he never said he would take over maintence of the tool (at least that's not the message I got - I could be wrong though). He said he would fix the most pressing issues as of right now,which is important and could be helpful. Rlink2 (talk) 04:12, 7 February 2022 (UTC)[reply]
Oh sure JPxG is great agree. It's been frustrating to see one person after the next promise to help out keeping the tool alive in the process but no real progress is made. It has nothing to do with good intentions. Sometimes it's a lack of skill, sometimes it's a lack of time, or lack of interest. Going on for years. If it was harmless who cares but not harmless. If we do keep the tool alive, there needs to be a stop button of sorts so users can at least shut it down until certain bugs are fixed. Currently there isn't even that basic functionality which every bot or tool should have. -- GreenC05:58, 7 February 2022 (UTC)[reply]
A more tenable solution
Over the last few days, I've had the opportunity to download the repository for ReFill and take a look at it. It doesn't seem to be badly written by any definition (in fact it seems quite well-written), although it does seem like it'll be very hard to work with. However, the point made above by GreenC is good -- I foresee a particular problem occurring here, and I think we should come up with some way to preempt it.
So, okay, let's say me and CSC sit down and hash it out and... learn how Vue works, I guess -- we figure out how to implement a couple of the most urgent bugfixes, maybe even modify or extend a feature (like, something that fixes cites for some the websites on BHG's lists). This is great, right? Except now I know how Vue works, which means I get a job where they pay me $99999999999, and stop having time to fix bugs in ReFill. This is presumably what happened to Zhaofeng, the original writer -- you can see on his GitHub that he is still making commits on a daily basis, and presumably his life rules because some of this stuff is really cool. But he is not fixing stuff in ReFill. Now, if I spend a million years learning how the hell ReFill works, presumably some day I will go to NASA to be a front-end rocket scientist, or I will get hit in the head with a meteorite, or whatever, and then this knowledge will be of little benefit to anyone (except possibly my web developer colleagues at NASA).
Anyway, the idea I had is that we could build up a decently useful page somewhere - like Wikipedia:Refill/technical and Wikipedia talk:Refill/technical, and everyone who wants to try and dick around with the code can convene there, to a) figure out what the heck is going on and b) share notes on what the heck they think is going on. We manage to do this perfectly well for everything else -- people get into an argument about politics and we end up with an ArbCom casepage filled with thousands of diffs and tens of thousands of words. I think that if we set this up, and still ended up with no progress being made, I'd support blocking ReFill until it was resolved (if only to get people motivated to help out). Alternately, we could leave it unblocked and make it fill in publication titles with auto-generated controversial statements about American politics ("Apollo 11 was an inside job", "the 9/11 landings were fake", "Donald Trump was actually born in Svalbard", etc) because that seems to effectively get people's attention. But I think if some people can be gotten to that page, if they later become busy, or get hit in the head by a meteorite, at least there will be something useful there for others to go off. jp×g21:19, 7 February 2022 (UTC)[reply]
(in fact it seems quite well-written) Good to hear.
FWIW I do have a fix for the broken sites for ReFill specifically. I used it at the very very beginning of my journey of fixing bare refs until I decided to move on to my own stuff. But it might be helpful to you. Let me know if you want it.
Yes, a page like that would be great. Keep everything documented for future maintainers. But, I think the biggest issue is finding someone to work on it. You could have all the documentation in the world, but someone still needs to fix the bugs at the end of the day.
Thanks, JPxG. It is good to hear someone confirm that there's nothing inherently wrong with the reFill code. I would say there's nothing inherently wrong with the software architecture either. And I will stick my neck out and say that GreenC should evidence their claims that it is 'full' of bugs and warnings, or that 'one person after the next promise[s] to help out keeping the tool alive in the process' - who were they? "Others have looked [at] it said it would be best to start over" - who? Curb Safe Charmer (talk) 22:52, 7 February 2022 (UTC)[reply]
Edit requests with canned "please get consensus first" responses are unhelpful to newbs
Most people making edit requests are inexperienced. If we're offering people a chance to make an edit request, responding to them with 'get consensus first' is unhelpful. They have no idea what that's even asking for, and in many cases we know it, and also that they probably aren't even coming back. IMO that response is, I'm sure unintentionally, just fobbing people off. We should be offering them instead a 'make a suggested edit' form that opens a discussion on the edit they're suggesting. This editor is correct. Courtesy ping to @OrewaTel. valereee (talk) 22:15, 24 January 2022 (UTC)[reply]
Wrong place or not, I agree. The issue is that the edit request queue is set up so it's supposed to be used only as a way to action resolved matters, not to prompt discussion. Maybe we could add a stage to the process that instead summons people to the discussion, and then if there's agreement, flip a parameter to turn it into a formal request in the queue. {{u|Sdkb}}talk05:33, 25 January 2022 (UTC)[reply]
Well, as someone who works the ER queue frequently, it depends what they are asking for. The ER process serves as an important check on the protection system. ER's that are not controversial (which are many of them) don't normally need a showing of consensus first. So perhaps updating the directions to give better guidance would suffice? — xaosfluxTalk11:39, 25 January 2022 (UTC)[reply]
The requested edit could have been made by any editor with ten edits. Answering an edit request shouldn't be gatekeeping. Answering an edit request should be, "If this edit had been boldly made by someone with 10,000 edits, would I even question it? Done." valereee (talk) 11:58, 25 January 2022 (UTC)[reply]
@Valereee: that's what I was saying - for uncontroversial edits (e.g. not an edit about content that is currently in dispute that led to the current protection) I assume the edit request is step one of WP:BRD and will make it, if in reviewing I think something is bad about it that I would have reverted on review, I decline and let the requester know that they are now at step three in BRD. But if the edit is about content in current dispute, that means that the material should already be in step 3 of BRD and a showing of consensus should accompany the immediate edit request. — xaosfluxTalk14:26, 25 January 2022 (UTC)[reply]
Specifically the discussion at Wikipedia talk:Edit requests/Archive 1#Requiring verbatim suggestions where there was discussion about elaborating on the templates used for answers. In the George Floyd instance, Also a second "needs consensus" reply that specifically states The subject of this article is controversial and content may be in dispute. As such this edit request will require consensus before being made. Or something along those lines. There's quite a few I've closed as needs consensus because I know the article is controversial and I don't think an edit request patroller who likely has no meta-knowledge of the article should be on the hook for the contents of the edit. would apply. Expecting patrollers to know all the discussions on the lead of an incredibly contentious article is unrealistic. The talk page watchers were still able to respond back to the edit request, and it appears there was no consensus for inclusion. Here's one I closed today, and added the mention that it would be a contentious change. ScottishFinnishRadish (talk) 15:22, 25 January 2022 (UTC)[reply]
Wow, this is actually tangential to something that came up a while back, I think at this very article. If an article is currently being actively edited and has hundreds of watchers, should patrollers even be patrolling that talk page? SFR, you answered that edit request ten minutes after it was made. There are nearly 300 watchers, over 50 of whom visited recent edits. Why not let someone who is familiar with the page respond to that request? Pinging EEng, with whom I discussed this at least a year ago. valereee (talk) 15:28, 25 January 2022 (UTC)[reply]
Would there have been a different outcome? Did my closing prevent any of the 300 talk page watchers from responding, or implementing the edit on their own? It didn't prevent them from discussing it, and establishing there was no consensus. It was poorly written, per Cullen328, If I am correct, then I oppose this proposed change, since that three word phrase "his dying words" already appears in the lead section. Once is OK but twice comes off as hackneyed and clichéd.
If a patroller reads an edit request, and believes that it's not an improvement, is that enough to close as "establish consensus?" Additionally, the template instructions explicitly state to close edit requests when there is discussion on-going, or the request is waiting on editor input. ScottishFinnishRadish (talk) 15:36, 25 January 2022 (UTC)[reply]
I've been completing COI edit requests on-and-off for about a year. I think the theory when edit request was created was that an editor would make a request, then other editors would discuss the edit request like an RFC. In reality, there's over 150 requests in the queue, some from almost a year ago, so now one editor is determining if the request is implemented. I don't think editors should decline any edit request as "get consensus first" because most edit requests are not going to generate discussion. Instead, editors evaluating requests should decide if they want to add it themselves or if they want to reject it for not fulfilling Wiki-policy and guidelines. If a request is closed with "get consensus first", then the closure should be reverted and another editor can evaluate the request. Z1720 (talk) 15:20, 25 January 2022 (UTC)[reply]
For the semi and extended queues, the older ones likely need some specialized knowledge to verify, or a fair amount of research to verify. Talk:Rus' people#editsemiprotected and [Talk:Bioidentical hormone replacement therapy#editsemiprotected] are good examples of aging ones. Every week or two I try to go through all of the aging ones that will take some time, and do the research necessary to close them. Or, if they deal with a rewrite or prose change, I'll often close them as consensus needed at that time, because after a week, if no one has made the edit then there is an implicit consensus against the change. ScottishFinnishRadish (talk) 15:42, 25 January 2022 (UTC)[reply]
Well, we can't really know, because if someone gets to an edit and sees it's been handled by an experienced editor, how closely do they even check the requested edit? In this case it took a bit of reading and comparing, because the editor had included too much of the content. I skipped reading it myself when I first saw it. It wasn't until just now that I bothered to actually read and respond. ETA: Not sure I agree that after a week there's an implicit consensus against, but if that's settled policy, why not wait a week to respond to the ER? valereee (talk) 16:20, 25 January 2022 (UTC)[reply]
The one week thing is not settled consensus, it's just generally how I handle it. There's actually not much "settled consensus" as far as handling edit requests. I operate off the assumption that the templates used for closes, and the wording of the edit request templates themselves, enjoy consensus.
No criticism taken. I think that expanding the templates used for responses could go a long way to help. If the George Floyd request had been closed as The subject of this article is controversial and content may be in dispute. As such this edit request will require consensus before being made. with a yellow icon, instead of red, I don't think we'd even be having this conversation. ScottishFinnishRadish (talk) 16:37, 25 January 2022 (UTC)[reply]
@Z1720: - think this varies by queue, the process for COI may need to vary from the FPROT queue (I don't work COI queue - but am all over FPROT queue). — xaosfluxTalk16:32, 25 January 2022 (UTC)[reply]
I think an expanded amount of templated responses would be the easiest to address some of the concerns. I'd like to know how often there are closes that anyone objects to, as well. I'd hate to see us come up with wait times and such around edit requests for what amounts to less than 5% of closures. ScottishFinnishRadish (talk) 16:51, 25 January 2022 (UTC)[reply]
The change I'd like to see in the Edit Request process is to stop "declining" edit requests that need more discussion and start "rescheduling" them. A desire for an empty queue can result in rejecting viable edit requests. Perhaps whatever code puts AFD pages into the correct date category after 7 days' wait could be adapted to this purpose. WhatamIdoing (talk) 23:44, 25 January 2022 (UTC)[reply]
As it stands, the edit request template instructs editors to close the request while waiting for editor input. From the last discussion I took part in dealing with edit requests there seemed to be a reasonable consensus that edit requests are specifically for edits that are ready to be made, rather than for discussion. Regular talk page discussion doesn't need an edit request template.
I do not think that's sufficient. We need to actively ask people not to rush to answer edit requests at pages they're unfamiliar with. There is no reason any edit request needs to be answered in five minutes by someone who is not familiar with that page. After a week, sure. But it's actually unhelpful for people not familiar with a page that has 500 watchers, 300 of whom have visited recent edits, to answer edit requests at that page with a canned edit request. valereee (talk) 21:03, 3 February 2022 (UTC)[reply]
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 current speedy deletion criteria has criteria U5: blatant misuse of Wikipedia as a webhost and G11: unambiguous advertising or promotion. A lot of user pages created in user space by new users seem to be nothing more than self promotion attempts. And I have seen it all - people using Wikipedia like Facebook, Tumblr, or their own personal website. New users wanting to contribute an article seem to use WP:AFC to do so. On this page, of the 68 user pages that were deleted on that page, all of them were speedied, 36 were deleted under WP:U5, and the rest were deleted under WP:G11, WP:G5, and similar criteria. Only three user pages were deleted under U1. Given this, and the fact that new users often create user pages without thinking about whether they will actually contribute to Wikipedia, I think restricting new users from creating user pages may be necessary to help cut down on the unnecessary user pages that get deleted every day. Aasim - Herrscher of Wikis00:08, 28 January 2022 (UTC)[reply]
Poll (restricting user page creation for new users)
Whoa there some processes - such as enrolling in registered education courses via https://dashboard.wikiedu.org/ help you create your userpage, which you would be doing as a very new user. A quick query right now shows that 18 of the last 75 pages created in User space were base userpages of exactly this sort. Also, this doesn't specify "base userpages" and I certainly wouldn't want to stop sandboxes. — xaosfluxTalk01:38, 28 January 2022 (UTC)[reply]
Oppose In addition to the things this proposition would completely break (like Wikipedia Adventure and WikiEdu), this is a not-as-helpful-as-it-seems proposition because Special:NewPages already makes it very easy to find and tag bad-faith userpages if you know how to use it efficiently. Curbon7 (talk) 03:54, 28 January 2022 (UTC)[reply]
Oppose Having users create their own userpages is a great way to ensure user retention. It worked for me: my first edits were to create my user and talk pages. It was so effective that it ensured that like 4 years later when I actually became an active editor, I didn't just create a new account, I went and found the password to this account so that I could have that user and talk page. The rest is history. CaptainEekEdits Ho Cap'n!⚓04:39, 28 January 2022 (UTC)[reply]
Oppose This measure isn't necessary. I understand where the idea is coming from, but purely promotional accounts that are WP:NOTHERE make themselves known pretty quickly. If they aren't allowed to make userpages, they'll just make other pages, like pages in article space. They'll cause trouble however they want, and we'll root them out sooner or later. We can't really plug every hole in this dyke. The sad thing is that Wikipedia presents an irresistible lure to spammers and self-promoters; it's a website where they think they can host pages they don't have to pay for. There's really nothing we can do to stop that, short of completely shutting out new accounts from literally everything we would even use as a yard stick to even graduate them to trusted statuses like autoconfirmed users — and that obviously isn't going to work. Zeke, the Mad Horrorist(Speak quickly)(Follow my trail)05:44, 28 January 2022 (UTC)[reply]
Oppose A good-faith proposal with some advantages, but they are vastly outweighed by the many good points made by preceding opposers. WP:SNOW is forecast. Certes (talk) 12:39, 28 January 2022 (UTC)[reply]
Oppose. In addition to what everyone else has said, when training we strongly encourage users to start with their userpage as a safe introduction to editing. Editors with blue-linked userpages are also often treated better that those without in the event of any dispute about what they are doing so they are a positive for editor retention. The stats about speedy deletion, rather than showing a problem, seem to actually show the system is working. Thryduulf (talk) 19:24, 28 January 2022 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Decrease edit requirement for being extended confirmed
500 edits is a lot, especially if you compare it to the other requirement for being extended confirmed (30 days). For example, I've been on Wikipedia 2 months and only have 89 edits. Sure, I've been inactive a bit, but if you were on, say, every 2 days, and made 3 edits per day, it would take a whole year to reach extended confirmed status. Plus, it's not about edit count, it's about quality of edits. I propose to decrease the edit requirement to 150-200. That way, it would only take 3-4 months rather than a whole year. Another requirement could be that you should not have more than 5-10 reverted edits (excluding self reverts), to encourage people to make quality edits rather than bad edits. InterstateFive (talk) - just another roadgeek 21:33, 29 January 2022 (UTC)[reply]
Any admin may grant any new user extended confirmed without them having to wait 30/500. So, if you're really doing good work and need to edit a WP:ECP page, all you need do is ask on WP:AN for somebody to grant you the right. -- RoySmith(talk)21:49, 29 January 2022 (UTC)[reply]
There's no minimum requirement for extended confirmed. Extended autoconfirmed has a minimum of 30/500, which is probably about right. Perhaps we should make WP:PERM more visible, so editors who need and can be trusted with extended confirmed don't need to wait for it to appear automatically. Certes (talk) 23:19, 29 January 2022 (UTC)[reply]
I think InterstateFive's idea is short-sighted, but well-intentioned. The problem is that we have so many dedicated sockmasters on this website, and lowering the standards for full editing privileges just makes their jobs easier, and ours harder. --Hunan201p (talk) 14:22, 31 January 2022 (UTC)[reply]
EC protection is rare, by design. There are about 3600 pages that require EC to edit, of over 55 million. The vast majority of these pages are so due to arbitration remedies, which is where the threshold came from. While the committee somewhat recently weakened the restriction to "ecp" instead of literally "500/30" (Wikipedia:Arbitration_Committee/Procedures#Extended_confirmed_restriction) I think in general we should not be easily weakening this - mostly because I don't want arbcom to get "creative" an invent a new massive protection scheme again that we have to scramble to build technical controls for. Yes there are reasons to early promote someone, but so they can edit remedied pages is a weak one at best. — xaosfluxTalk19:11, 7 February 2022 (UTC)[reply]
Dark mode
After starring at a particularly bright and shiny wiki (Hodge conjecture), it struck me that WP needs a dark mode, and maybe a couple more 'easy-on-the-eye' themes, e.g. research lighting, old-fashioned (mood setting) etc..
Hi there. I made an infobox for alloys on Czech Wikipedia as requested there. What I found out is that a Wikidata link has been created and Czech Wikipedia is currently the only one that contains this infobox. Since I know English well enough to communicate and write, I decided that I'd like to translate the infobox to English. I normally translate articles from English Wikipedia to Czech, but I might as well expand this and translate also some templates, and even reverse the process - translate from Czech to English. It is difficult, not gonna lie, I had to double check every translation and had to actually look for exact translations. Since the infobox uses wikilinks to articles that describe what the field is about, I figured out that I might use the Wikidata links to my advantage. Anyway, the infobox is currently in my sandbox, currently lacks documentation, but my question is that if I should actually continue in making the infobox, if it is actually needed. It is used over on Czech Wikipedia, so I figured I would transfer it into English Wikipedia as well, properly translate it, and see. Because English comes in two major forms (British and American), I made a dual parameter that is used in a single one (with American variant being preferred one), you can even see it in the source code if you click Edit.
What I hereby propose is take a look at it, see for yourself, maybe suggest some improvements (maybe colouring would like to improve, overall styling, etc.), and decide wether this infobox is worth the inclusion in English Wikipedia. If not, I can simply remove the content in it and archive the page. — Polda18 (talk) 18:01, 31 January 2022 (UTC)[reply]
I looked at it, and according to link for Czech Wikipedia counterpart, it is used mainly for chemical compounds. An alloy isn't actually a chemical compound, it is mixture of different chemical elements or compounds, typically metals. For example Bronze is an alloy of Copper and Tin for the most part. Copper and Tin do not actually form a chemical compound together, they're still forming standalone structures, it's just it's a mixture of microscopic metal crystals of both types giving it the properties of Bronze. — Polda18 (talk) 07:47, 1 February 2022 (UTC)[reply]
I think that a vast majority of en-wiki infoboxes don't have colors for the labels & data, though a coloring for headings exist. I don't know if there's some kind of guideline on it or not. Otherwise, it looks really good & useful. ---CX Zoom(he/him)(let's talk|contribs)20:36, 31 January 2022 (UTC)[reply]
I can remove the colouring of labels and data (we do occasionally use them on Czech Wikipedia in some infoboxes, not all though), but I'd like to keep the colouring on sections heading and the infobox header itself. — Polda18 (talk) 07:37, 1 February 2022 (UTC)[reply]
Proposal to Change The Romanization of North Korean language in Wikipedia
Even though both Koreas have had their own romanization system, why do we still use the old romanization for North Korean when we use the new revised romanization for South Korean?펑홍한talk04:50, 1 February 2022 (UTC)[reply]
Note: This might not technically be a proposal, but I hope you'll excuse me posting here; I'm doing so in an attempt to make sure lots of people are aware of this upcoming change.
---
Hi y'all – the Editing Team is planning to offer the Reply Tool as an opt out feature to all people – logged in and out – at en.wiki this upcoming *Monday, 7 February 2022*.
The "Deployment Rationale" below is what's leading us to think now is a good time to move forward with this deployment. If this idea brings any concerns/questions to mind, we would value you sharing those thoughts so we can talk about them.
And for people curious about the work the Editing Team will continue doing to improve the Reply Tool, please see this update.
Note the 7 February deployment only pertains to the Reply Tool, NOT the New Discussion Tool (setting name: enable quick topic adding) or Topic Subscriptions (setting name: Enable topic subscription).
EDIT: to clarify, this deployment only impacts people (logged in and out) using talk pages on the desktop site. Said another way: this deployment would have NO IMPACT on people (logged in and out) using talk pages on the mobile site.PPelberg (WMF) (talk) 04:30, 3 February 2022 (UTC)[reply]
Deployment Rationale
The Editing Team has the impression that now is a good time to offer the Reply Tool as a default at en.wiki based on the following:
People do not seem to have any significant concerns about the Reply Tool being offered more broadly.[1]
The Reply Tool is reliable. Over the past 30 days, 99.9% of the 14,000+ comments 800+ people posted with the tool at en.wiki did not impact any other parts of the talk pages it was used on.[2]
Many people have confidence in the Reply Tool. At en.wiki, 2,800+ people have used the Reply Tool to post at least one comment since the tool was offered as a beta feature on 16 March 2021.[3] And of these 2,800+ people, 25% have used the Reply Tool to post 10 or more comments.
While there is additional functionality that could A) increase the range of comments people can use the Reply Tool to publish (e.g. votes[4] and unindented comments within existing discussions[5]) and B) expand how expressive the tool enables people to be (e.g. stronger template support[6] and signature customization[7]), we do not currently understand the implementation of these additional capabilities as needing to prevent people who are new from benefiting from being able to post comments more intuitively and for the comments they post being signed and indented in ways experienced volunteers expect and value.
Yes, the deployment planned for Monday, 7 February 2022only pertains to the Reply Tool, NOT the New Discussion Tool (setting name: enable quick topic adding) or Topic Subscriptions (setting name: Enable topic subscription).
Generally, I think this is the right direction to head—ever since Enterprisey developed his version of a "reply link" tool way back when, I have long been excited at the prospect of deploying this in a widespread format to help new editor engagement. With that being said, I would be mindful that this would be a relatively significant new feature in the editing interface, and some past rollouts of similarly significant new features have led to tension between the WMF and the English Wikipedia community (see e.g. Wikipedia:VisualEditor/RFC and Wikipedia:Arbitration/Requests/Case/Media Viewer RfC). I don't think the Reply tool is quite as invasive as VisualEditor and Media Viewer were, but because of those dark memories, I would be inclined to more broadly advertise to experienced editors that this change is going to occur—specifically, I'm thinking in MediaWiki:Watchlist-messages. Maybe this is overkill, but the English Wikipedia community can sometimes be really passionate against these software changes, particularly when they have the appearance of being performed without their consultation or consent. I've been using the Reply tool for a while now, and it is quite good—I just hope others see it the same way. Mz7 (talk) 09:43, 2 February 2022 (UTC)[reply]
Thanks for the shoutout! I agree with everything you said. I guess it may seem like a silly step (and I think it sort of is). But we should definitely hold an RfC of some sort if we've learned from the history of this sort of thing. It doesn't even have to be that long (a week?) or laborious.PPelberg (WMF) and the team, thank you so much for all your hard work on this! I've been waiting for this day for a long, long time. Would it be possible to get links to some of those "suspicious" edits (I'm assuming that's what "sus" means in that table)? I really appreciate the inclusion of the table in the first place. Enterprisey (talk!) 10:34, 2 February 2022 (UTC)[reply]
@PPelberg (WMF): we may at least post a note somewhere like our watchlist header when it goes live to help head off any "what's this" confusion posts. That being said, probably should have 2 targets ready: (a) the location any issues should be reported; (b) a description/help page of the new feature (which should include the opt-out directions). mw:Talk pages project/Replying isn't really a good landing page for either of those - it is more of a project tracking page. Are there better targets ready somewhere? — xaosfluxTalk11:14, 2 February 2022 (UTC)[reply]
@Xaosflux, there's mw:Help:DiscussionTools, which could be copied here. (Everything in Help: namespace at mw.org is public domain/CC-0, so you don't even have to worry about licensing attribution.) It might make more sense to put the section about the Reply tool in Help:Talk pages than to create another extension-specific page.
That said... it's already default-on for about half the editors in the movement. Across hundreds of wikis, I've seen about five requests for information on how to disable it and almost no bug reports. There have been some feature requests (e.g., support for voting-style discussions) and questions (e.g., why doesn't it recognize this editor's non-standard signature, or work on this page with a colored background?). Someone even wrote a quick user script (check the VPM archives; I copied it here) to change "[reply]" into the emoji or word of your choice. This experience suggests that we probably won't get that many questions, especially after the first day or two. Whatamidoing (WMF) (talk) 17:22, 2 February 2022 (UTC)[reply]
I'm thinking a watchlist notice would be good on launch day, something like:
{{Display/watchlist
|until= 10 DaysFromNowMonth 2022
|cookie=n
|text=The [[Wikipedia:Talk_pages_project#Reply_tool|'''Reply tool''']] from the talk pages project has been enabled for all editors. Should you have any issues or feedback, please [[Wikipedia talk:Talk pages project|let us know]].
}}
Making the reply tool opt-out is a big step for beginner friendliness. Wording should be this imo (with relevant links): "The talk page reply tool has been enabled for all editors. If you spot any issues or have any feedback for the Talk Pages project team, let us know at our talk page" ✨ Edtalk! ✨ 03:43, 3 February 2022 (UTC)[reply]
@Suffusion of Yellow good question. The deployment currently planned for this upcoming Monday will only impact people – logged in and out – who are accessing the desktop site.
hi @Suffusion of Yellow – the mw:Editing Team is planning to offer both the Reply and New Discussion Tools on mobile at an initial set of wikis within the next month or so (you can track progress on this work by following along with phab:T282638).
@GhostInTheMachine good question. This deployment does not include the Reply Tool being made available on mobile because we are still refining the user experience for it. We will have a prototype ready to share soon, would you be interested in trying it out and sharing what you think about it?
A tad short-notice for general awareness of rollout, but I've been using it on meta to get used to it, and it's significantly improved from even 3 months ago - especially in its tolerance to the most common thing I did to break it, which was adding ping templates as the first thing in the message. I think the first week will be a bit of a mess, but the general gain will be significant. Nosebagbear (talk) 09:50, 3 February 2022 (UTC)[reply]
As someone who is not at all tech savvy… please explain what this is and what it is attempting to accomplish - using non-tech language. Don’t assume people know what you are talking about. Blueboar (talk) 00:24, 4 February 2022 (UTC)[reply]
It adds a little reply link after talk page talk page posts that you can click on to reply to that particular message. It opens a small editing window below the message you're replying to, so you can reply without loading a new page. ScottishFinnishRadish (talk) 00:34, 4 February 2022 (UTC)[reply]
Alright y'all: it's been a couple of days since this discussion started and we thought it would be helpful to articulate the information that has surfaced in the discussion thus far. This way, we can collectively decide what happens next with this deployment with a shared set of ideas in our minds.
New Information
People are supportive: Everyone who has commented in the discussion thus far is supportive of the Reply Tool being offered as an opt-out feature, for all users (logged in + out), on desktop
Awareness is important: A significant number of volunteers who have commented in the discussion agree (and so do we!) that it would be wise to make as many people aware of this change as possible, ideally ahead of time. [1][2][3][4][5]
Announcement needs some more thought: There does not yet seem to be an agreement about what the most effective way(s) are of making people aware about the Reply Tool being made available as an opt-out feature on desktop.
*Please comment if you do NOT think aspects of the above are accurate. It's very possible I missed and/or misunderstood something someone said!
Next steps
With the "New Information" above in mind, I'm going to ping a few other folks who have been involved in testing and providing feedback about the Reply Tool[6][7] to hear what they have to say...
As people who are experienced using the Reply Tool at en.wiki[7], we wonder: what do you think might be effective ways for making the wider en.wiki community aware of this Reply Tool deployment?PPelberg (WMF) (talk) 03:06, 4 February 2022 (UTC)[reply]
A question and a couple of comments before as head into the weekend...
Question
@Ed6767, @Enterprisey, @GhostInTheMachine, @Mz7, @Xaosflux: as people who have said this deployment would benefit from many people being made aware of it ahead of time, how do you think this announcement or announcements ought to be made? Would an RfC be valuable? Would a MediaWiki:Watchlist message be effective? Might making more posts on pages experienced volunteers are likely to visit (e.g. a couple relevant noticeboards, Village pump (technical) as @Whatamidoing (WMF)has done) be the best approach? Some combination of these options?
Comments
A couple of thoughts about what the mw:Editing Team is thinking...
We agree with you in thinking that it's worthwhile to make as many people aware of the change before it happens as possible.
We think the deployment date ought to depend on people having enough awareness that it's happening. Said another way: we are committed to revising the deployment date to leave more time for making people aware, if that ends up being necessary.
Next step
At around 16:00 UTC this Monday, 7 February, I'll check back in with you all so we can decide whether we move forward with the deployment on Monday or push it back a few days to execute the plan y'all might've come up with over the weekend.
My only advice is “think in terms of next month rather than next week”. We here at enWP do not like surprises, and we tend to knee jerk reject things when surprised. So go very slowly with the role out. Announce the crap out of it - in as many different forums and formats as you can think of. Give people time to get used to the idea before you go live with it. Blueboar (talk) 02:53, 5 February 2022 (UTC)[reply]
Considering it is still not clear to me, and other members of the Editing Team, whether y'all (all of the volunteers who have participated in this discussion to date) think an RfC for this kind of change is necessary, in the immediate-term, we are delaying today's (7 February) planned deployment of the Reply Tool.
Next step(s)
You can expect to see another comment from me before 5:00 AM UTC (8 Feb) with a proposed next step or steps.
Of course, if any new thoughts/questions emerge between now and then, we would value you sharing them.
Alright y'all, people in this discussion seem to agree:
1) Some volunteers are bound to be surprised by this change, no matter how many announcements are made
2) "1)" notwithstanding, it's preferable the Reply Tool deployment be delayed until more announcements are posted
Next steps
With the above in mind, what do you think of doing the following?
@Enterprisey: are you able to take the lead on making sure this discussion is added to CENT?
@Xaosflux: are you able to finish the work required to ensure the Reply Tool opt-out deployment is included in the watchlist banner?
And then we can all come back together to talk about the deployment timing once we see what people say in response to the announcements Enterprisey and Xaosflux will have posted. PPelberg (WMF) (talk) 01:37, 8 February 2022 (UTC)[reply]
I am going to say that I've only noticed one issue with the reply tool and i Have no clue what causes it or if it can still happen. For whatever reason, in the past some sections people created couldn't be found by the reply tool with no real reason as to why. I don't remember where this was happening or who the users were that were causing this to happen, however it appears to be very rare. ― Blaze WolfTalkBlaze Wolf#654503:10, 4 February 2022 (UTC)[reply]
Could you explain what "a bug in Parsoid causing it to render the page differently from the PHP parser" means in layman's terms? ― Blaze WolfTalkBlaze Wolf#654503:30, 4 February 2022 (UTC)[reply]
That's not relevant and is a distraction. You are being asked whether the explanation given at that link might match your experience. The explanation is saying that certain listed factors might cause "Could not find the comment..." and if those do not apply, the software might have a bug. If the latter, they would like a report including a permanent link to the page involved along with a description of exactly what you did and what you saw. The "file a task" is an overly optimistic request that you can ignore. Instead, post your findings here or at any noticeboard such as WP:VPT and someone will notify the appropriate people. Johnuniq (talk) 04:32, 4 February 2022 (UTC)[reply]
Blaze, the core MediaWiki software that renders wikitext to HTML is written in the PHP programming language, but it's a one-way conversion. There is another component called Parsoid that can do two-way, and Reply Tool uses it because ... reasons. Visual Editor also uses the Parsoid service. (Apologies to all the technical peeps reading my mangled explanation.) ⁓ Pelagic ( messages ) 12:21, 6 February 2022 (UTC)[reply]
This is a visible change. The reply links positioned after every post aren't exactly an obscure UI element tucked away in a toolbar. Will this flip the setting for everyone who hasn't already turned it on then off again? People will notice and say "why weren't we asked?"
Any RFC or banner should run before changeover, not after. Even if it means we have to wait another fortnight or month. Putting it up after the fact would be a very bad look.
On the plus side, a lot of people are already familiar with Discussion Tools thanks to years of fantastic consultation and outreach from Peter and WAID. But enwiki is a big place and we might be surprised to discover how many people still didn't know.
No problem, @Pelagic. The exact date is not important to the Editing team, so if you all think we need to delay, then that's okay. Just please come to some agreement about what should be considered "enough".
To give some context, back in 2013, I personally posted announcements about the visual editor to more than 100 pages at the English Wikipedia, it had been discussed in the village pumps for months, the team ran CentralNotice banners in multiple languages for two straight weeks ...and many editors were still surprised. I remember one person saying that she had been on vacation for the exact 14 days that the banners ran. Most of us in this discussion have probably also seen CENT-listed RFCs that are claimed later to have not been well-advertised enough, because 99% of editors don't follow RFCs or CENT, and they sometimes regret that they missed important discussions. I have also seen an editor participate at length in a discussion about a proposed change, and later ask why there had never been any discussion about that change. All of which is to say: no amount of effort can completely prevent surprises. The English Wikipedia is too big for everyone to know about everything, and we have too much to keep track of to remember even the things we do talk about. I expect that most editors will consider the Reply tool to be a pleasant surprise, but I do expect its appearance to surprise a substantial number of editors no matter what we do or when we do it.
I feel your frustration, Whatamidoing. In my imaginary ideal world there would be a formal RFC that, for once, could come down clearly in favour of change, because of all the great community work you have already invested, and because this is a feature that I believe most people deem beneficial. There's a danger it could get bogged down in "no consensus", which would be a saddening demonstration that participatory decision-making doesn't scale, and that enwiki is something like Conway's Game of Life where interactions are localised to small scale but cause surprising ripples.
As to choice of channel, I almost wrote earlier something like "hey, why not go all out and run a mw:CentralNotice banner, rather than just a watchlist banner or a WP:Centralized discussion listing?" Not knowing that you had been through that before.
Personally, I'd be wouldn't mind if you turned it on tonight. Maybe there's nothing more you can do to influence the amount of pushback. As you say, how much is enough? ⁓ Pelagic ( messages ) 14:17, 7 February 2022 (UTC)[reply]
I'm sure that the product manager would be willing to wait for an RFC, but the number of times volunteer-me has had conversations along the lines of "There should've been an RFC! – There was an RFC last month; here's a link to it – But there should've been an RFC!" leaves me doubtful that even that would work.
For clarity, I really do want as little surprise as possible. I am just not certain that we can materially shift the needle on that with any non-disruptive means. Whatamidoing (WMF) (talk) 16:48, 7 February 2022 (UTC)[reply]
I think that makes a lot of sense. I agree that having a up-or-down vote on the matter is probably not productive. Maybe we should give it a week with a T:CENT banner plus a watchlist notice? Enterprisey (talk!) 22:22, 7 February 2022 (UTC)[reply]
I understand there are those who are suspicious of change, and can find it hard to adapt. Nonetheless, the visual change being proposed is a brief string of text added to the end of comments. Editors remain free to add comments the same way they always have and ignore the new link. I think it's overkill for there to be a large-scale RfC on the matter, absent any indication that there is in fact a significant proportion of editors who object. As an example: once upon a time, the section edit link was right justified. A number of editors raised complaints when it was changed. I could be wrong, but I don't get the sense that it continues to be a simmering irritant to this day. isaacl (talk) 22:40, 7 February 2022 (UTC)[reply]
Articles for improvement would be given the semi-active tag if it wasn't a vital WikiProject, why isn't it shown on the main page or somewhere else that will give it higher traffic. I only heard about it after 5 months of being on wikipedia. Why not link it on the main page or on Help:Introduction to Wikipedia? This would allow for more vital articles to have more edits and finally put this damn thing about how we ignore vital articles to rest. Lallint⟫⟫⟫Talk23:45, 2 February 2022 (UTC)[reply]
Good idea. An argument against it might be the front page is not for highlighting problems with Wikipedia, or to pull readers into helping. But why not? The front page might be used as a recruitment tool to encourage fence sitters to become editing heroes. Granted such articles will need to be watched since new users will do strange things, but the project could have editors willing to adopt articles, like lifeguards. -- GreenC00:39, 3 February 2022 (UTC)[reply]
Some of these are just ridiculous, like look at this:
The 2nd, 4th and last one especially, I'm surprised Genus isn't already a GA or FA. These are incredibly important to daily life and yet they are complete crap. Lallint⟫⟫⟫Talk01:24, 3 February 2022 (UTC)[reply]
Sure it was, 8 years ago. Can't we try again? It doesn't even have to be the main page, why not Wikipedia:Cleanup, or Wikipedia:To-do list? Why do you always shoot me down whenever I say something? Lallint⟫⟫⟫Talk17:09, 3 February 2022 (UTC)[reply]
Wikipedia is not a Gerontocracy, so the amount of time I've been editing is irrelevant. And it's not the case that [I] always shoot [you] down whenever [you] say something, instead that you keep doing things that come to my attention. Nor am I really shooting you down here, as my comment was purely factual and did not imply anything about my position on this proposal. * Pppery *it has begun...17:29, 3 February 2022 (UTC)[reply]
You know, Lallint, proposing a change to the Main Page and immediately personalizing the dispute with the first person to disagree is a pretty generous interpretation of what Rosguill intended by Block converted to partial block to allow for participation in RfD. Or, maybe it isn't. I wouldn't want to speak for them. But either way you should not be editing disruptively while still actively blocked for disruptive editing. -- Tamzin[cetacean needed] (she/they)17:33, 3 February 2022 (UTC)[reply]
I don't think years editing matters to much. I do agree that it was 8 years ago and things can change in 8 years, so it would be logical to at least try again (possibly do something a bit different). It appears it failed 8 years ago because the articles just weren't being edited. From what I"m reading it's because there wasn't anything encouraging the articles to be edited. Maybe awarding barnstars to users who help improve the articles would help (similar to the back log editing drives done by some WikiProjects)? The editing drives some WikiProjects do seem to be successful so maybe we could try and figure out what makes them successful and implement that into this. ― Blaze WolfTalkBlaze Wolf#654517:39, 3 February 2022 (UTC)[reply]
Also, the reason some people always seem to reply when you say something might just be coincidence, and also possibly the fact that you're currently partially blocked and are wanting to make sure you aren't doing anything to violate your block. ― Blaze WolfTalkBlaze Wolf#654517:40, 3 February 2022 (UTC)[reply]
Don't mean to support people who agree with me and not support people who don't like some freedom of speech advocating little b-boy, but this guy logics. Lallint⟫⟫⟫Talk17:43, 3 February 2022 (UTC)[reply]
I agree with 420 Blaze Wolf above, perhaps we could use a positive reward system for doing good on one of those pages instead of rollbacking every edit they made after they accidentally made a typo then indefinitely banning them and accusing everyone with more than 2 letters similar to their name as a sockpuppet Lallint⟫⟫⟫Talk17:53, 3 February 2022 (UTC)[reply]
now that I think about somebody's probably actively refreshing this thread with a bag of popcorn waiting for something to happen again Lallint⟫⟫⟫Talk17:55, 3 February 2022 (UTC)[reply]
That would be a barnstar we could give users. I see your point in giving new users a reason to edit. It's kinda hard to give new users a reason to edit because, well, they're new users. And as I"m thinking about this a bit more, if it were on the main page it might just attract vandals to those articles instead of new users wanting to improve them. Maybe it could be integrated into the new user homepage? I'm trying to think of some reward that would appeal to new users. ― Blaze WolfTalkBlaze Wolf#654518:35, 3 February 2022 (UTC)[reply]
I think in order to come up with a reward for new users, we would have to figure out what appeals to constructive new users the most and causes them to stay. Obviously we can't just make it "If you help edit these pages you won't get blocked!" because if it's a vandal then they will get blocked and that will be shown to be a false statement. ― Blaze WolfTalkBlaze Wolf#654518:39, 3 February 2022 (UTC)[reply]
Whenever someone makes a mistake (such as a typo) I am usually just able to revert with the edit summary of it being in good faith and with an explanation as to why I reverted (and we definitely don't accuse everyone with more than 2 letters similar to their name as a sock, or at least, we don't block them, one of my friends here on Wikipedia had an SPI made against them because someone managed to get a character that looked exactly like a letter in the english alphabet and replaced that letter with the character, making it look like it was the same username). Barnstars are a good idea, although a human should give them out because if it were a bot, then it would probably function like this: Bot sees user has made an edit to article on list, bot awards user barnstar. The bot can't check to see if the edit is constructive or not (or at least, not reliably. we could use something similar to ClueBot NG, however there are false negatives and awarding a user for bad behavior isn't all that constructive) so if a human were to award the barnstars it could be a good system. ― Blaze WolfTalkBlaze Wolf#654517:59, 3 February 2022 (UTC)[reply]
When I first read this idea, my initial reaction was that I rather liked it. However, I can see the following problem. Wikipedia: Main Page is probably one of the most viewed pages in the encyclopaedia (indeed, if you just Google "Wikipedia", you will instantly be taken to the Main Page) and if the first thing that one reads on the Main Page is that there are articles needing improvement, it may put readers off the Wikipedia project. I guess that what I am saying is that there could be problems of putting "Articles for improvement" on a page with too much traffic. That said, tonight I looked at the category called "Articles needing improvement from the Bioguide" and had a look at two articles in this category - that on James Budd and that on Henry P. Haun. It was not clear from these articles in themselves that they needed improvement, that was just mentioned on their talk pages. I agree that we should place notices that articles need improvement in more prominent positions, so how about having a tag at the top of the article saying it needs improvement, just below its title? The article on James Budd is headed by a tag saying that its lead may not summarize its key points adequately. If it were also heading by a tag saying that it needs improvement, that may make more Wikipedians aware of how it needs attention.
The main page has an "Other areas of Wikipedia" section with links to editor-facing areas such as the Teahouse. That might be a good place to link to a list of articles for improvement. Certes (talk) 23:43, 4 February 2022 (UTC)[reply]
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.
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.
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}}talk05:15, 3 February 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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}}talk19:09, 3 February 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
{{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}}talk21:01, 3 February 2022 (UTC)[reply]
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)[reply]
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)[reply]
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) buidhe21:03, 3 February 2022 (UTC)[reply]
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)[reply]
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)[reply]
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 Geniustalk12:48, 4 February 2022 (UTC)[reply]
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. --Jayron3214:16, 4 February 2022 (UTC)[reply]
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)[reply]
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)[reply]
Hatnote ~ the footnote is a pain to have to scroll down to in order for important information ~ or, at most, allow all. Happy days ~ LindsayHello16:26, 5 February 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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}}talk22:12, 7 February 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 ~ LindsayHello13:15, 8 February 2022 (UTC)[reply]
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)[reply]
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}}talk03:42, 4 February 2022 (UTC)[reply]
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)[reply]
Perhaps it can display in parentheses after or below |name=. An example would be:
@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}}talk07:45, 4 February 2022 (UTC)[reply]
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)[reply]
@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}}talk08:09, 4 February 2022 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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 [8].)
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)[reply]
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)[reply]
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 we prevent new/unregistered users from editing featured article and featured lists? Because I see in the last month, many featured articles were vandalised by newcomers and IPs. Vitaium (talk) 23:54, 3 February 2022 (UTC)[reply]
Oppose vandalism is usually swiftly reverted on such articles, as they tend to have a high number of pagewatchers, and if if not, WP:RC has really good vandalism filters now, so they're much more detectable. This is a non-issue. Curbon7 (talk) 02:07, 4 February 2022 (UTC)[reply]
Oppose: Wikipedia prides itself on being editable by anyone. How would it look if our most important and highest quality articles didn't even stick to the core of Wikipedia? bop34 • talk • contribs03:23, 4 February 2022 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I think you are proposing an accessibility meter not a verifiability one? In order to verify wikitext one has to access the cited sources first. And then dig in diligently. But the proposal is excellent otherwise. The article you linked is good, but old news, and a bit depressing all these years later. 65.88.88.71 (talk) 15:53, 5 February 2022 (UTC)[reply]
I strongly disagree that paywalls or the need for an education sign in suggests something is not verifiable. And at least those can be verified if you can get access without leaving your computer, unlike old newspapers, books, etc. Doug Wellertalk15:42, 7 February 2022 (UTC)[reply]
To address the easy part first, WP:V doesn't require that the source be easily accessible. It can be behind a paywall, or not available on-line at all.
The deeper issue is that we are at an information crossroads. Humanity has spent the last several thousand years recording and cataloging information. It's only in the past 150 or so years that we've figured out how to transmit information without having to transport the physical object on which it is stored. And it's only in the past few decades that we've figured out how to let anybody on the planet remotely access information at a time and place that's convenient to them. This is so ubiquitous, convenient, and inexpensive that people are starting to think that "available for free on the web" is synonymous with "exists". While it's a good thing that much information is now available on-line, it's a bad thing that the historical information is fading into non-existence. Either somebody is willing to pay for the conversion to digital form, or the information will disappear. At some point, somebody will look at a building full of dead trees and decide they want to use the space for some other purpose, don't care about preserving the information, and it'll all just get tossed into a landfill.
The issue of scientific journals being behind paywalls is one my my long-term peeves. At least in the US, most scientific research is paid for by federal research grants. It's just plain wrong that having already paid for the research, I now have to pay again to see the result. In the old days, the journals provided the much-needed service of printing. The machinery to do this (i.e. printing presses) is expensive, and they controlled the flow of information by investing in that machinery. The journals also provided editorial oversight, but for the most part, that was delegated to outside reviewers who did the work for free because it was considered an integral part of academic research, and being appointed to an editorial board of a major journal was a gold star on your CV. It's taken the scientific world a long time to grasp that these were two entirely distinct functions. Yes, we still need the reviews and editorial oversight, but we no longer need the printing presses. Which means the journals are living on borrowed time.
But, to get back to where I started, it would be a bad thing if Wikipedia institutionalized a preference for on-line sources. All that will do is hasten the day when the vast store of historical information is lost. -- RoySmith(talk)16:31, 7 February 2022 (UTC)[reply]
Well I doubt that Wikipedia promoting easily accessible sources will hasten the day when the vast store of historical information is lost. After all great stores of historical information stored in physical media have been lost in the past, repeatedly. Granted that accessibility is not an explicit WP:V concern, is an accessibility-of-sources metric useful? I believe it is. Sources that cannot be easily accessed, or that can be accessed only by a minority of privileged users do not promote overall project usefulness. I am a random reader perusing a random Wikipedia article. I read something that I find striking; I need to know the particulars of this. Perhaps for the first time, I decide to click on that small symbol to be eventually guided to a hopefully relevant citation. If it points to an easily accessible and free source I will be able to continue my research of the subject. Wikipedia becomes a relevant link in the chain of this personal research. If not, it is a letdown and Wikipedia becomes a broken link (excuse the pun) and a block. Unless that is, one takes steps more familiar to those doing research as profession and requirement. More likely the example reader will browse away from Wikipedia in frustration. An accessibility-of-sources metric will signal concerned editors accordingly, and may promote overall article quality. It will also, and more importantly, signal readers the true state and status of the article, an overall project reputation/goodwill issue. 65.88.88.62 (talk) 20:07, 7 February 2022 (UTC)[reply]
Let's not have Wikipedia over emphasize accessible from the internet sources. Accessible doesn't mean good. A copyrighted book by a subject matter expert is almost certainly a better quality source than what is easily accessible. Research papers being behind a paywall is just a reality of the 21st century and again those peer-reviewed papers are almost certainly a better source than what's readily accessible.
I think we are discussing accessibility of sources (including print sources), not quality. In order for anyone, reader or editor, to determine the quality of a source, it must be accessible to them. 65.88.88.62 (talk) 20:48, 7 February 2022 (UTC)[reply]
But it does not have to be instantly accessible or even easily accessible.
And, in fact, it does it actually have to be accessible to everyone (since you can always ask someone else to access it FOR you, and report back on whether it is a quality source that verifies the information you are interested in). Blueboar (talk) 21:05, 7 February 2022 (UTC)[reply]
Yes, sources don't have to be easily accessible, but is the overall project more useful and relevant if they are? Is verifiablity also helped by more accessible sources? If the answers are yes, the metric proposed makes sense.
Asking someone else to access the information can happen regardless. It also creates another expert class that must be consulted. There are many such knowledge entities around. For instance Encyclopedia Britannica is one. Their contributors presumably have accessed all the sources. After all they are paid to do it, and have a reputation (and future commissions) to protect. They are also overseen by professional editors who answer to career managers. Taking the almost entirely dissimilar nature of this project into account, and if the objective is to make presumably valuable & relevant knowledge freely available to everyone, then the provenance of such knowledge must be transparent. 65.88.88.62 (talk) 21:27, 7 February 2022 (UTC)[reply]
This claim about the Britannica seems to be a big assumption. First, that somehow an article with no sources is better than one with sources, some of which may be difficult to access. Secondly that the editors are all experts in their fields. Having looked into this I can state that isn't the case. Third that the articles are all reliable in themselves. Yet I know a case where someone who failed to get their fringe (and unsourced) idea into Wikipedia managed to get it into the Britannica. Doug Wellertalk11:10, 8 February 2022 (UTC)[reply]
I don't know if all articles in that commercial property are up to par. I don't know how one manages to get their "fringe ideas" there. Keep in mind that there is a part of the Britannica Online that is crowdsourced just like Wikipedia is. And predictably, with similar overall quality. But I was not referring to the Wikipedia-like part.
So what is a big assumption? That (traditional) Britannica is part of an established knowledge provider that is run by professional managers? That their editorial & supervisory boards are staffed by other, known professionals? That they commission non-anonymous experts to write or contribute to articles? That they employ both proofing and fact-checking staff? That there is both explicit and implied liability regarding every aspect of the operation? Is it also understood that because of the above, articles in that encyclopedia can do without reader verification and the attendant citation system? Although they may as a convenience include a bibliography.
As an information consumer, one can purchase the traditional Britannica implying they pay to expect information that is concise, reliable, objective, correct and understandable. Wikipedia is free, and there are no such expectations, as is clearly stated in Wikipedia's own literature. As it is also clear from Wikipedia's own processes, otherwise we would not be discussing this. My own assumption as a Wikipedia reader is, if I can't verify it, it is useless. Garbage that just wasted my time. It doesn't matter how well presented, it still stinks. 74.64.150.19 (talk) 13:54, 8 February 2022 (UTC)[reply]
What is "traditional Britannica"? I know about Britannica online and what I said is true of it. I don't know about another Britannica. I have no idea what you mean about "liability" - you mean you can sue them? Of course they have professional managers, but so does almost every medium sized company. And you should not assume that because there are no citations that an article is correct. This is waste of time. Doug Wellertalk14:59, 8 February 2022 (UTC)[reply]
One of the small minority of articles in Wikipedia that are more or less adequate is the one on Encyclopædia Britannica. Maybe it is a starting point for information about it that you can't find. But this is getting off-topic. The OP asks if a metric present in every article regarding accessibility of sources is something that should be done. Are there any substantive points against it, technical or otherwise? It seems sensible, and an improvement. 65.88.88.47 (talk) 16:34, 8 February 2022 (UTC)[reply]
Frequency of Changes to Wikipedia Articles
I would like to suggest a metric for science and math articles on how likely a page is to change.
Many fields in mathematics such as number theory and geometry are not likely to change over time even as the content and presentation and clarity and layout of the article is improved.
For example, ellipses will mostly be the same geometrically and so some parts of the article will be less likely to change.
I think its good that articles on developing events include disclaimers on the current status of the article but think it would be helpful to include an opposite notice that for example Maxwell's Equations is invariant.
ScientistBuilder (talk) 02:23, 5 February 2022 (UTC)[reply]
This is interesting, but the way I understand it, you seem to mean that the source information upon which an article is based is not likely to change, not the article itself. I don't know if such a metric is entirely pertinent or relevant to Wikipedia. Current events have very fluid verifiability characteristics, and the warning is relevant. If such a metric is applicable and desirable it should apply to the article as a whole. If applied to parts of articles would probably be too cumbersome for editors and confusing for readers. And first, is it so? Something like "A's equation" obviously is set for posterity, and there is no need to proclaim the fact. One may add to it, but then it is no longer A's equation, it is "B's enhancement of A's equation". However the viability/applicability of any equation may change. Perhaps after the next hypothesis and its related experimentation. 65.88.88.71 (talk) 16:20, 5 February 2022 (UTC)[reply]
Wikipedia is a work in progress and most articles on number theory and geometry are incomplete, contain errors or misleading implications, are suboptimally comprehensible to laypeople, and could be re-organised or give a different balance of subtopic coverage to more properly represent the research area. A page is likely to change if an editor becomes interested in it, and unlikely to change if editors are not. There are trends that can create interest: for instance, news coverage, sudden social media interest or a major update to the topic. However, other trends are less predictable: if I bring 15 Black Mirror episodes to good article status then it becomes a lot more likely that the others will soon follow suit, but if I create a few Rick and Morty episode articles then I might stop with five still missing. I can think of one particular mathematician whose retirement from Wikipedia would dramatically decrease the likelihood of upcoming improvements to any particular mathematics article. — Bilorv (talk) 00:08, 6 February 2022 (UTC)[reply]
When I use Wikipedia to learn math and science topics I would like to know which subjects will be less likely to change in 10 years. For example, I want to work through all the articles on electromagnetism and am interested in which articles are not culture specific and more broadly applicable. ScientistBuilder (talk) 02:12, 8 February 2022 (UTC)[reply]
. 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 
.
but don't like File:Icons-mini-file pdf.svg 
) 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.
. There are many more options in commons:Category:PDF icons. – Joe (talk) 06:15, 8 September 2021 (UTC)
File:PDF icon.svg. Please feel free to tweak it further. – Joe (talk) 12:37, 8 September 2021 (UTC)
. --Ahecht (TALK
Eeeehhhhhhh, @Robert McClenon, are you sure you typed in the right number for your preferred option? ~~~~
is licensed as GPL which could make a diffence as to how it can be used without any linking back to the file. -- WOSlinker (talk) 07:36, 8 September 2021 (UTC)
(File:Icon pdf file.png). Text on other versions, including the SVG auto-converted to a 16px PNG, is illegible. Certes (talk) 18:29, 9 September 2021 (UTC)
, 707 bytes) works for me, too. — JohnFromPinckney (talk / edits) 12:04, 8 September 2021 (UTC)
Question: Why is specifying the file format necessary for PDF files? ~~~~
(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)
and 
— GhostInTheMachine talk to me 09:19, 15 September 2021 (UTC)
Administrator note we could use the abusefilter to block or warn on these edits as they seem to have a consistent edit summary we could latch on to; we could also exempt certain usergroups (e.g. extendedconfirmed) or users with an editcount above something from such a filter. While possible, I expect there will be significant pushback about making a new local mediawiki usergroup just for this. If set to "warn" every use would require a reconfirmation after getting the "warning" which can say whatever we want. (Please note one of the sample "bad" edits is by a user with 3000000+ edits that is also a member of restricted groups including autopatrolled). We can not easily make an on-wiki discretionary access control list, as we do not control this software - it is hosted off-site. Traditional administrative options are also available - such as placing editing blocks on users that are making disruptive edits. — xaosflux Talk 22:55, 21 January 2022 (UTC)
KevinL (aka L235 · t · c) 16:43, 25 January 2022 (UTC)
Mathglot (talk) 23:41, 7 February 2022 (UTC)
![[1]](https://upload.wikimedia.org/wikipedia/commons/thumb/3/38/Icon_pdf_file.svg/16px-Icon_pdf_file.svg.png){kind=link}
![[2]](https://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Icons-mini-file_pdf.svg/16px-Icons-mini-file_pdf.svg.png){kind=link}
![[3]](https://en.wikipedia.org/w/resources/src/mediawiki.skinning/images/document-ltr.svg){kind=link}
![[4]](https://en.wikipedia.org/w/resources/src/mediawiki.skinning/images/external-ltr.svg){kind=link}
