Wikipedia:Village pump (proposals)

"WP:PROPOSE" redirects here. For propose for deletion page, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
• Proposed policy changes belong at Village pump (policy).
• Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

RFC: New PDF icon

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

Background

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

Options

There are three options that should be considered here:

• Option 1 to support using File:Icons-mini-file pdf old.svg  File:Icons-mini-file pdf.svg 
• Option 2 where you agree that we should change File:Icons-mini-file acrobat.gif  but don't like File:Icons-mini-file pdf.svg 
• Option 3 to oppose any changes to File:Icons-mini-file acrobat.gif 
• Option 4 for removing the icon entirely.

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

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

---

Discussion (new PDF icon)

• Option 1. As proposer. –MJL ‐Talk‐^☖ 05:33, 8 September 2021 (UTC)

  Comment. I have uploaded a new file that does not have the GPL copyright concerns attached to it. Please see File:Icons-mini-file pdf.svg  for the old file. Currently, the old one is at File:Icons-mini-file pdf old.svg  and the new one is at File:Icons-mini-file pdf.svg , but they should be swapped in like 30 minutes or so. –MJL ‐Talk‐^☖ 21:38, 8 September 2021 (UTC)

  @Xaosflux, Anomie, WOSlinker, and Wugapodes: Sorry to ping you both again about this I have now replaced the SVG with a CC0 one per your concerns. –MJL ‐Talk‐^☖ 05:00, 9 September 2021 (UTC)

  The link in the summary above doesn't seem to point to that? Perhaps strike and insert to the proposal above? — xaosflux ^Talk 10:46, 9 September 2021 (UTC)

  Fixed. –MJL ‐Talk‐^☖ 15:35, 9 September 2021 (UTC)

• 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)
• Option 2. I would prefer something that isn't tied to Adobe, like File:Icon pdf file.svg: . There are many more options in commons:Category:PDF icons. – Joe (talk) 06:15, 8 September 2021 (UTC)

  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)

  I tweaked it further, but I think there's a limit to how well tiny SVGs can render text: . --Ahecht (TALK
  PAGE) 20:13, 8 September 2021 (UTC)

  It's easy to read, in SVG format, and is clear of copyright concerns. Ultimately, it's probably the best bet for symbol replacement. Plutonical (talk) 14:58, 29 September 2021 (UTC)

• 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×g 06:34, 8 September 2021 (UTC)

  Man, there's some pretty great icons in that category. jp×g 06:37, 8 September 2021 (UTC)

  Do I look like I know what a JPEG is? ~~~~
  User:1234qwer1234qwer4 (talk) 09:41, 8 September 2021 (UTC)

• 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. CaptainEek ^{Edits Ho Cap'n!}⚓ 06:42, 8 September 2021 (UTC)
• Option 3 as a reasonable specific replacement. Robert McClenon (talk) 07:03, 8 September 2021 (UTC)

   Eeeehhhhhhh, @Robert McClenon, are you sure you typed in the right number for your preferred option? ~~~~
  User:1234qwer1234qwer4 (talk) 09:45, 8 September 2021 (UTC)

• Option 1 as a reasonable specific replacement. Robert McClenon (talk) 14:58, 8 September 2021 (UTC)
• 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)
• Option 2 I agree with Joe.--Vulp❯❯❯here! 07:55, 8 September 2021 (UTC)
• Option 2; the new SVG looks wrong to me without a gradient, and I think we should move away from Adobe promotion. ~~~~
  User:1234qwer1234qwer4 (talk) 09:39, 8 September 2021 (UTC)

  Option 4 below does not seem too far fetched either. We don't seem to have this for other file formats, why display an image specifically for PDFs? ~~~~
  User:1234qwer1234qwer4 (talk) 20:42, 8 September 2021 (UTC)

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

  @Certes, note that there are no "letters" in option 1. ~~~~
  User:1234qwer1234qwer4 (talk) 15:15, 8 September 2021 (UTC)

  Oops, I was referring to Icon pdf file.svg. Certes (talk) 17:08, 8 September 2021 (UTC)

  The only candidate I can read at 16px is (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)

• 1 or 2 is fine for me. --Izno (talk) 12:01, 8 September 2021 (UTC)

  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)

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

  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)

  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)

  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)

  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)

  Striking my !vote until I have time to study the revised options. — JohnFromPinckney (talk / edits) 18:09, 9 September 2021 (UTC)

  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)

  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)

  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>), and just the icon without one (<ref>[https://example.com/Adobe.pdf Without cite template]</ref>). 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)

References

• Option 1. That logo is still the most widely associated with the PDF format, and anything else is just making things less clear for our readers. There doesn't seem to be a clear alternative being posited (the letters in the version proposed by Joe are illegible at this resolution), and most of the reasons above seem to hinge on people's person feelings about Adobe, which shouldn't enter into this debate. Either leave well alone, or adopt the new clearer version proposed by the OP.  — Amakuru (talk) 12:14, 8 September 2021 (UTC)

  "Personal feelings" is a bit dismissive. We're an free knowledge project and have a long history of supporting free software, free licenses, and free formats wherever possible. I highly doubt that the generic 90s software-looking acrobat squiggle is more widely recognised than the letters "PDF", but I agree the legibility of my first suggestion could be improved. – Joe (talk) 12:22, 8 September 2021 (UTC)

  If someone comes up with an alternative that actually works, then I might support it. But I'm not going to give a blank cheque to swap an easily recognisable logo for one which might not immediately convey its meaning to our readers. "Option 2" involves dispensing with the current logo without any consensus as to what we're swapping it for, and I can't support that.  — Amakuru (talk) 12:31, 8 September 2021 (UTC)

• Option 2 - some generic PDF logo (i.e. not the Adobe 'squiggly triangle') to be determined later. SVG > GIF, of course, but I think we should take this opportunity to swap it for a more generic logo. firefly ( t · c ) 12:25, 8 September 2021 (UTC)
• Option 2 or 3 Option 1 is a non-starter due to license. We need something that's public domain or CC0 to avoid a requirement to link back to the file description page for attribution and/or notice of license. I wouldn't oppose an identical image with a proper license; while it's annoying to have the Adobe software's logo in there, it's also recognizable. As for that several people above seem to like, all I see at that size is a document icon with a red bar over it. The text "PDF" is not visible. Again, I wouldn't oppose an alternative that's more legible. Anomie⚔ 12:26, 8 September 2021 (UTC)
  • Striking as the concerns I raised seem to have been addressed, the new image for option 1 has a usable license and people have suggested as a better choice for option 2. I don't have enough of an opinion on the current options to !vote. Anomie⚔ 16:57, 9 September 2021 (UTC)
• Option 2 Let’s move away from Adobe. --Malcolmxl5 (talk) 12:32, 8 September 2021 (UTC)
• Option 3 This is change for the sake of change and doesn't actually accomplish anything. * Pppery * _{it has begun...} 13:21, 8 September 2021 (UTC)

  @Pppery, the current file is 512 pixels, which is too small to be rendered properly on modern screens and appears conspicuously pixelated. ~~~~
  User:1234qwer1234qwer4 (talk) 15:29, 8 September 2021 (UTC)

• Option 3 or 2: the current icon is serviceable as is, but if we were to change, I'd rather something without the Adobe logo. Isabelle ^🔔 14:35, 8 September 2021 (UTC)
• Option 2 per Firefly and others. There is nothing wrong with using a 16-year-old icon per se, and the proposed replacement's only advantage is in file format and that's not enough reason imo to justify a change. However what does justify a change is using a generic icon that doesn't require someone knowing what the logo of a private company represents. Whatever icon we end up choosing, we should probably consider including it as an example in the PDF article. Thryduulf (talk) 15:07, 8 September 2021 (UTC)
• Option 2, PDF files are no longer the sole domain of Adobe and we shouldn't be using their logo, but none of the suggested icons have been readable. I modified one of the existing PDF SVG icons on commons to make it more readable (), but if the intent is to use this at 16px, pixel art is always going to render better than an SVG, e.g. . --Ahecht (TALK
  PAGE) 15:37, 8 September 2021 (UTC)

  I have to admit that the 16px PNG rendering does look like a usable option and also looks way less pixelated than the current icon (where even the border displays very blurry), at least on my end. ~~~~
  User:1234qwer1234qwer4 (talk) 15:48, 8 September 2021 (UTC)

• Ehhhhhhh ---- GPL are we opening a can of worms by changing from a free image to one that has to drag GPL around with it everywhere? — xaosflux ^Talk 16:58, 8 September 2021 (UTC)

  Leaning more towards Option 2 and using File:Icon pdf file.png or something similar, provided it is CC0 or other very-free license. — xaosflux ^Talk 18:50, 8 September 2021 (UTC)

  @Xaosflux and Anomie: Wouldn't a comment in the CSS be sufficient for linking to the license and authorship? –MJL ‐Talk‐^☖ 20:56, 8 September 2021 (UTC)

  Nope. The GPL seems particularly weird when it comes to images, and even more weird when it comes to SVG images. The bottom line is that we need to clearly distribute the image along with the author's copyright notice and the notice that it's under the GPL, which we satisfy by linking the image to the file description page that has all that information. Hiding a comment in a CSS file, where it'll be hard to find and may be minified out, won't cut it. Anomie⚔ 21:55, 8 September 2021 (UTC)

  Okay, I have managed to remake the SVG using stuff that was in the Public Domain. –MJL ‐Talk‐^☖ 05:06, 9 September 2021 (UTC)

• Option 2 I find the PDF text version quite promising. The one I think is the most legible is (show) (File:Icon_pdf_file.png) which is easily readable on both mobile (both vector and mobile version). There are of course scenarios where it wouldn't be legible, but I feel the current icon would be non-distinctive under the same circumstances and I could see many readers not knowing what the acrobat icon means now a days. --Trialpears (talk) 17:03, 8 September 2021 (UTC)
• Option 2 Go for File:Icon_pdf_file.png . It's more readable than the similar svg versions. -- WOSlinker (talk) 18:23, 8 September 2021 (UTC)
• Option generic PDF SVG Headbomb {t · c · p · b} 18:34, 8 September 2021 (UTC)
• Option 4 get rid of it altogether. No GPL license, no trademark (US #3652386 and #3652388, I have no idea how to link these from https://tmsearch.uspto.gov/ so search yourself, it's the squiggly triangle), no BS. The document icon with "PDF", even Joe Roe's improved version, is hard to read and ultimately provides no additional information over just the text "(PDF)". This is currently defined in MediaWiki:Common.css#L-510 btw, it's not template specific or MediaWiki default. — Alexis Jazz (talk or ping me) 19:55, 8 September 2021 (UTC)
• Opposed to any GPL-licensed image or image restricted by trademark. Would prefer CC-0 license. No strong opinions on the design itself, I'm open to a new one but don't see a serious problem with the existing image. — Wug·a·po·des​ 20:29, 8 September 2021 (UTC)

  @Wugapodes: Wouldn't the trademark issue be a problem with File:Icons-mini-file acrobat.gif  as well? I'm a little confused there. –MJL ‐Talk‐^☖ 21:00, 8 September 2021 (UTC)

  I'm not an expert on trademark, but I presume so. My understanding is that having a trademark isn't a problem per se as long as we aren't using it to mislead readers about brand identity or disparage the trademark holder. The issue isn't a legal one, but a philosophical one: I'd prefer we use free equivalents that do not have copyright or trademark restrictions whenever possible. But unless we have consensus for an option that is free of copyright and trademark, I'd rather we have some graphical representation of the PDF over nothing. So by no "serious problem" I mean that it's not enough for me to say get rid of it immediately, but I do think there is room to improve. If we are going to improve, I want us to also move in the direction of copyright- and trademark-free images, but if the option is do nothing or remove the icon without replacement, I'd rather do nothing. (NB I do like Ahect's idea of just using stylized text instead of an icon.) — Wug·a·po·des​ 21:40, 8 September 2021 (UTC)

   Question: Why is specifying the file format necessary for PDF files? ~~~~
  User:1234qwer1234qwer4 (talk) 22:13, 8 September 2021 (UTC)

  Wugapodes, I'm fine with stylized text too. The text "(PDF)" already gets added, seemingly by {{Citation}}. I just think the icon should go away. Trademark is possibly a theoretical legal issue. The squiggly triangle in the infobox of PDF is fine because there is clearly no connection between Adobe and Wikipedia. When used as system icon of sorts, like we have it in MediaWiki:Common.css#L-510, it could cause people to believe there is a connection between Adobe and Wikipedia or MediaWiki, like us relying on Adobe software or being endorsed by Adobe. It's a theoretical issue though, this may or may not actually be a trademark violation and Adobe is unlikely to try and crack down on this kind of unauthorized usage. My main issue is also philosophical: try to avoid trademarks if possible, particularly when they're not being used for commentary. 1234qwer1234qwer4, I think traditionally this kind of indication (not just on Wikipedia) was provided to warn users to get a cup of joe while their computer chugs along for 15 minutes to load Adobe Acrobat Reader. — Alexis Jazz (talk or ping me) 22:33, 8 September 2021 (UTC)

  @1234qwer1234qwer4: PDFs are a bit of a weird file format. Sometimes when you click a link it will automatically download a file on your device, but other times it can just open up in a new tab. The biggest concern, however, is that not all mobile devices support PDFs across the board. My phone can just barely do it (and requires a download everytime I view one.. which can be a problem for larger files), so I have always found these icons helpful. –MJL ‐Talk‐^☖ 05:06, 9 September 2021 (UTC)

• Option Alexis Jazz - WP:ACCIM recommends that information should not be conveyed using only images, and while the revised icon with plain text is a slight accessibility improvement over the corporate logo version, it's still a long way off from meeting that standard. Alt text would help, but a simple (PDF) alongside the link is frankly much better and more useful than a small icon with tiny, barely-legible text. Ivanvector's squirrel (^trees/_nuts) 20:40, 8 September 2021 (UTC)

  Or something like PDF, which is reminiscent of what Google uses. --Ahecht (TALK
  PAGE) 21:14, 8 September 2021 (UTC)

  I see this as a case of progressive enhancement given broadband speeds and the compression of PDFs (which has gotten better since PDFs stopped being all-image files), as the size was predominantly the rationale for ever indicating that a URL pointed to a PDF. Separately, CS1/2 already auto-indicates whether something is a PDF. I don't really see much cause for anyone to generally indicate something is a PDF. (This is not an opinion on this RFC per se, just making a comment about whether we should need to indicate something is a PDF.) Izno (talk) 19:02, 9 September 2021 (UTC)

  There is an old-school web best practice to indicate if a link doesn't take you to a web page, since that's the general expectation (and, yes, size was part of the concern). I'm not sure of the current consensus on this matter in the web design community. isaacl (talk) 19:46, 9 September 2021 (UTC)

  I haven't designed web pages since the mid-90s so I can't really comment on standards, but I'd prefer if there were some kind of indicator, text or otherwise. Compression has improved for sure but PDFs are still multimedia, even a single-page plain-text PDF can be several megabytes. Not everyone who reads Wikipedia benefits from the expansion of broadband in wealthy countries, and third-party software is still generally required to open a PDF or use their full functionality, and this can be severely prohibitive for someone on say a 14.4kbps dialup connection, or using a 2G mobile device. We still warn when a link goes to an external website, and we should do the same with multimedia. Ivanvector's squirrel (^trees/_nuts) 20:52, 9 September 2021 (UTC)

  "We still warn"? We don't (I assume by "we" you mean MediaWiki software, please be precise if otherwise), at least not "accessibly", in the same way we don't as the would-be "replace with 'PDF' in text". Izno (talk) 21:22, 9 September 2021 (UTC)

  If you look at the web, I'd say that mostly doesn't happen any longer. I mostly don't think it should, especially with the advent of "the browser does everything (video, audio, PDFs of late in e.g. Firefox, yadda yadda)". Browsers are monsters not far off from being their own operating systems (oh wait :). Izno (talk) 21:24, 9 September 2021 (UTC)

  Although links to PDF files often lack indicators (with the ubiquity of the format, probably due to both happenstance and successful Adobe marketing), links to video and audio generally still provide some kind of indication. Users generally want to know in advance if they're going to see some kind of audiovisual presentation. Their current browsing environment (such as alone in a room or within a crowd) and personal desires at the moment influence what type of interaction they want to have. isaacl (talk) 00:56, 10 September 2021 (UTC)

  Yes, by "we" I did mean the MediaWiki software, with the little "arrow escaping the box" icon beside all external links (like this, which is, indeed, not accessible). Remember that while progress marches on, it marches past many people who read Wikipedia but don't have access to cutting-edge tech that we do in developed countries, and something as minor to us as loading a couple-megabyte multimedia file could be an outright ordeal for them. On a trip to Cuba a few years ago I turned my phone on when our plane landed, and didn't even get out of the airport before I had a text from my carrier saying I was up to $100 in roaming charges and they had disabled my data. I remember the not-too-distant past trying to edit through Opera on a flip phone, and recently made one edit from my Wii's embedded browser just to see if it would work - it did but it was frustrating. I still see more Windows XP than ChromeOS in checkuser results, and rarely even older OSes. Ivanvector's squirrel (^trees/_nuts) 16:43, 15 September 2021 (UTC)

  Most of the major search engines indicate PDFs (Google, Bing, DuckDuckGo, Yandex, and Baidu do, Yahoo and Ask don't). --Ahecht (TALK
  PAGE) 19:47, 25 October 2021 (UTC)

• With apologies to those who already knew, the choice of icon is implemented in MediaWiki:Common.css line 510. Help:External link icons#Custom link icons informs us that The image must be 16 pixels wide and cannot be SVG format. (That's in an example about adding a custom icon for .xls, but I assume it applies to .pdf too). From my rather basic knowledge of graphics, .png may be the best format for this use case. Certes (talk) 22:52, 8 September 2021 (UTC)

  Certes, I had already mentioned Common.css above, but you inspired me to add an anchor to the line number. — Alexis Jazz (talk or ping me) 23:02, 8 September 2021 (UTC)

  @Certes: Really, SVG is the best format because it is the most scalable (imo). –MJL ‐Talk‐^☖ 05:06, 9 September 2021 (UTC)

  Normally, yes, but the software doesn't seem to accept SVGs here. Also, if it's shown at a fixed 16px, we should probably optimise for that, e.g. align the paper edges and the orthogonal lines of the letters mid-pixel. If the day comes when MediaWiki renders an SVG at 128px on our 16k holodisplays, we can replace the icon again. Certes (talk) 10:19, 9 September 2021 (UTC)

  When it says "cannot be SVG format", I suspect that refers to the URL used. So https://upload.wikimedia.org/wikipedia/commons/c/cb/Icons-mini-file_pdf.svg would fail, but https://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Icons-mini-file_pdf.svg/16px-Icons-mini-file_pdf.svg.png would be ok. For that matter, the restriction on SVG may be outdated (it was written in 2011), or may have been because someone's browser in 2011 didn't support SVGs there, or may be to avoid explaining that the SVG's intrinsic size needs to be 16px; at any rate, I tested it and it seemed to work fine. But I do agree that optimizing the icon for the size would be a good idea. Anomie⚔ 11:51, 9 September 2021 (UTC)

  The "restriction" is outdated. We have been serving SVGs via TemplateStyles for CS1 for a year or two now. My guess is that it is related to IE8 and lower, which MediaWiki no longer supports. The page pointed to by Certes should be updated. Izno (talk) 18:58, 9 September 2021 (UTC)

  But if you're using the png rendering of an SVG file, you get all the downsides of an SVG (e.g. blurry lines and fonts) with none of the advantages of it being scalable. --Ahecht (TALK
  PAGE) 13:14, 24 September 2021 (UTC)

• Option 2 I think File:Icon_pdf_file.png is a much better replacement, is very readable, and is simple. This is the obvious choice for me. DiamondIIIXX (talk) 03:47, 9 September 2021 (UTC)
• Comment This may seem like an odd question but, why is the file in a .gif format anyways? Aren't .gif format files used for animated images? But I support Option 2, per the above discussion. The current file makes it seem like the file is in Adobe Acrobat (which, a few years ago, that was probably the only way to view PDFs) when really it can be viewed in many places besides Adobe Acrobat. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 19:06, 9 September 2021 (UTC)

  GIF format was long used for images on computer networks, pre-Internet, pre-Web, and up to now. Due to patent issues (which are no longer applicable as the patent in question has expired), there was a push to move to PNG format, and JPEG became popular for photos due to better compression and appearance (both due to higher resolution colour not being limited to only showing 256 colours and its compression algorithm being a better fit). GIFs remained in use for animated images as the original PNG specification did not support this capability. The current image being a GIF is reflective of how long ago it was put into place. isaacl (talk) 19:27, 9 September 2021 (UTC)

  Ah ok, thanks for informing me! I've always know .gif format files as being animated images so I was confused when I saw that the current image we're using was in the .gif format but wasn't animated. @Isaacl: Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 19:31, 9 September 2021 (UTC)

• Option 1 as an improvement, until someone thinks of something which is equally clear and less like its own logo. DGG ( talk ) 06:33, 10 September 2021 (UTC)

  I'm confused as to what you mean. Many people have already thought of something equally clear and less like a logo. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) (Stupidity by me) 13:07, 10 September 2021 (UTC)

• I'm not going to pick an "option" because at this point there are too many icons going around, but I support using some sort of SVG icon (preferably without the Adobe logo) that's CC0 (or similarly) licensed. I don't prefer any particular icon. Tol (talk | contribs) @ 21:14, 10 September 2021 (UTC)\]

  @Tol: Option 2 does not require a commitment to any particular proposed icon. All it means is that you are against File:Icons-mini-file pdf.svg  and are also against File:Icons-mini-file acrobat.gif . That sounds like where you are basically at right now. –MJL ‐Talk‐^☖ 06:34, 12 September 2021 (UTC)

  @MJL: Ack, my mistake. Option 2 sounds good. Tol (talk | contribs) @ 17:39, 12 September 2021 (UTC)

• Question Have we asked Adobe what they will allow? I quickly skimmed https://www.adobe.com/legal/permissions/icons-web-logos.html and thought I need to ask someone with expertise in copyright law. Vexations (talk) 22:24, 10 September 2021 (UTC)

  Does it matter? If we don't want to use one vendor's logo for an industry-wide standard, whether they want us to use it is irrelevant. Certes (talk) 22:32, 10 September 2021 (UTC)

• Option 2 (use MediaWiki? fallback). I used inspect element to disable the current icon pulled from Common.css, and discovered that the fallback pdf icon is evidently [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)

For the sake of illustration in this discussion, I have uploaded the icon I am proposing to Commons; it looks like this: (for comparison, here is the external link icon that appears all over Wikipedia, part of the same MediaWiki set: ). — Goszei (talk) 03:43, 20 September 2021 (UTC)

• Option 2 - Personally I like Icon pdf file.png Seddon ^talk 18:47, 13 September 2021 (UTC)
• 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. ― Qwerfjkltalk 19:04, 13 September 2021 (UTC)
• Option 2 per everyone else, and in terms of replacements, first choice: PDF, second choice: File:PDF icon bold.svg , third choice: File:PDF icon.svg . Levivich 05:25, 14 September 2021 (UTC)
• 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)

  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)

• Option 2 as tie to Adobe is no longer appropriate. Use . I'm seeing that around anyway, so more and more becoming the default I guess. Herostratus (talk) 02:48, 15 September 2021 (UTC)
• 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? — GhostInTheMachine ^{talk to me} 08:35, 15 September 2021 (UTC)

  Maybe not ... PDF icon blue.svg and PDF icon black.svg — GhostInTheMachine ^{talk to me} 09:19, 15 September 2021 (UTC)

• Option 2 although I am not fond of the red letters, as it seems redundant For example MyProposal.pdf DGerman (talk) 19:55, 20 September 2021 (UTC)
• Related proposal: I've opened a related proposal; !voters here are invited to comment at Help talk:Citation Style 1/Archive 79#Proposal: Use the document icon instead of the external link icon for documents. {{u|Sdkb}} ^talk 04:42, 23 September 2021 (UTC)
• 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)
• 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:GKFX^talk 17:16, 11 October 2021 (UTC)
• Option 2 so we can stop advertising for Adobe every time we link to a PDF. Calling out PDF links is still useful. Retswerb (talk) 02:12, 13 October 2021 (UTC)
• Option 1 or 2 are equally fine for me. Whatever replaces it should be a SVG and not any other image format. Stifle (talk) 11:12, 13 October 2021 (UTC)
• Option 2 with File:Icon_pdf_file.png or a similar option that reads "PDF". {{Nihiltres |talk |edits}} 01:52, 16 October 2021 (UTC)
• 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)
• 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 Farm _Talk 06:19, 21 October 2021 (UTC)
• 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)
• 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)
• Option 2 with File:Icon pdf file.png . Using lettering rather than a logo makes it clearer to readers what the icon means, and the letteting in this PNG version is much clearer than any of the SVGs posted above. Modest Genius ^talk 10:57, 28 October 2021 (UTC)
• 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)
• 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)

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

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

Further discussion (PDF icon)

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

• There are 15 icons in Commons:Category:PDF icons under Public Domain that are not based around the Adobe Acrobat logo (which was rejected above), listed below in alphabetical order of file name; the ones in italics were mentioned in the above discusison
  • Option 1: File:.pdf OneDrive icon.svg -
  • Option 2: File:Document-303123.svg -
  • Option 3: File:Icon pdf file.png -
  • Option 4: File:Icon pdf.svg -
  • Option 5: File:Icon-354355.svg -
  • Option 6: File:Ilovepdf.svg -
  • Option 7: File:PDF icon black.svg -
  • Option 8: File:PDF icon blue.svg -
  • Option 9: File:PDF icon bold.svg -
  • Option 10: File:PDF icon.svg -
  • Option 11: File:Pdf link icon.png -
  • Option 12: File:Pdf-155498.svg -
  • Option 13: File:Pdf-2127829.png -
  • Option 14: File:Pdf-47199.svg -
  • Option 15: File:Pdfreaders-f.png -

  I think that is too many options for a single RfC so we should try and narrow it down first. Unless anyone has better suggestions I propose a round of approval voting first to find the top 4/5 that people could support, with those being the options in a full RfC? Thryduulf (talk) 18:09, 11 January 2022 (UTC)

  Seems like a good plan, as I agree that 15 choices is too many. (As an editorial aside, the list could get quickly pruned somewhat by eliminating those which are unusable; some of these are indecipherable to me.) Do we need to first clarify .svg/.png formats? Or do we know that both are equally good (although that seems in some conflict with the note in the RfC close above)? — JohnFromPinckney (talk / edits) 04:52, 12 January 2022 (UTC)

  At their current sizes, I find all but 3, 9 & 10 nearly impossible to read. 7, 8 and 11 are a stretch, but I can make out the letters. I would have no idea what 6 means to indicate without context. Aza24 (talk) 05:15, 12 January 2022 (UTC)

  On my device, with my eyes, I can read option 9, and with difficulty 3, 4, and 10. Since I know I'm looking for "PDF", 5, 11, and 12 are on the boundary of recognizability. I could plausibly make out some of the others by removing my glasses and bringing my phone nearer my face, but I'm unconvinced that is the solution we're seeking. Folly Mox (talk) 05:50, 12 January 2022 (UTC)

  3, 9, 10 are the clearest in terms of legibility and actually conveying meaning. Since I'm aware that I'm on team-letters, one other option should be included which is option 14 that is both legible and would probably be understood over time. The issue is that it makes me think it's powerpoint, but that argument could be had in the 2nd RfC. Nosebagbear (talk) 11:55, 12 January 2022 (UTC)

  To clarify for any reviewer, 3 is the best of these Nosebagbear (talk)

• Yes, let's put one contender forward against the incumbent. Legibility is key here; I find 9, 3, 10 easiest to read in that order. Is it worth considering another alternative with the letters in red on white rather than white on red? That could save a couple of pixels at the sides, enabling the letters to grow slightly. I've tried playing around and can't make anything worth uploading but someone with a clue about graphic design probably could. Certes (talk) 14:31, 12 January 2022 (UTC)

  I think any colored text makes it harder to read the letters at such small size. I prefer something like 11, perhaps 9 with plain black text. MB 14:48, 12 January 2022 (UTC)

  Black lettering on 9 would work too, though readers may associate the red-white-black palette with PDF. Certes (talk) 14:56, 12 January 2022 (UTC)

  Maybe 9 with black text and a red outline of the document symbol is a way to get some red in there. MB 15:21, 12 January 2022 (UTC)

• 3, distant second:9. — xaosflux ^Talk 15:11, 12 January 2022 (UTC)
• For me 3 is the most clear, with 9, 10 and 11 readable but noticeably less so. Thryduulf (talk) 15:55, 12 January 2022 (UTC)

  Looking on a smaller (and dirtier) laptop screen 3 is by far the clearest, 9 is readable but not as easily. 10 and especially 11 I'm not convinced I could read if I didn't know what they said. Thryduulf (talk) 22:58, 17 January 2022 (UTC)

• I don't have clear preferences on what should be the one we should adopt, but I have some arguments against 2, 6, 7, 8, 11, 12, 14, 15.
  • The word "PDF" in 7 & 8 are simply not legible at all, and have an overall bad contrast.
  • 11 & 12 look good on zooming in but on my screen, they can be easily overlooked if one isn't searching for a logo on there.
  • 14 & 15 are not quite associatable with PDFs in general. The huge "P" in 14 makes it appear more like MS PowerPoint logo than PDF. In option 15, the average person will associate the green very closely with spreadsheets rather than PDFs (thanks to Excel & GSheets), plus the word "PDF" on it is too small to be legible.
  • 2 appears more like a basic Windows notepad app, again the word "PDF" is not legible either.
  • 6 is the logo of ilovepdf.com and shouldn't be used due to the very reasons some editors already raised regarding the Adobe relation in current one. Also, what does a reader coming across a random heart symbol in a certain external link understand of it? ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 19:25, 12 January 2022 (UTC)
    • To make it easier for whoever compiles the results, are you saying you have no objections to: 1, 3, 4, 5, 9, 10 and 13? Thryduulf (talk) 21:55, 12 January 2022 (UTC)

      Yes, as of yet, I approve of 1, 3, 4, 5, 9, 10 & 13. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 22:15, 12 January 2022 (UTC)

• On my laptop, I find 3 the easiest to read, then 10, then 9, then 11. 7 and 8 possess bad color combinations, options 4 and 12 are too small, and the others just don't look right, especially option 6. ResPM (T🔈🎵C) 00:01, 13 January 2022 (UTC)
• 3 if we're going to use an image, but I think of a Google-like text tag is still better. If we are using an image, there's no advantage to using an SVG if mediawiki is going to convert it to a raster image anyway. --Ahecht (TALK
  PAGE) 18:40, 13 January 2022 (UTC)
• Option 3 is by far the clearest for me. ― Qwerfjkltalk 18:07, 15 January 2022 (UTC)
• Option 3 Most recognizable for me, alternatively 10 as a second choice. — Preceding unsigned comment added by IAmChaos (talk • contribs) 23:17, 20 January 2022 (UTC)
• I'd suggest we just vote on 3, 9, and 10. They're by far the best options of the bunch. Mlb96 (talk) 04:34, 21 January 2022 (UTC)

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

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

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

Might want to count how many people opined in general. When folks are not treating a RfC as an either-or choice and supporting more than one option, the ratio of "support for a given option"/"total amount of participants" can be an useful metric to gauge consensus. Jo-Jo Eumerus (talk) 11:05, 21 January 2022 (UTC)

3, 9, and 10 are all equally acceptable to me at this stage. KevinL (aka L235 · t · c) 11:14, 21 January 2022 (UTC)

@Jo-Jo Eumerus by a quick count, 13 people expressed an opinion about 1 or more of the options before the summary. The discussion was explicitly set up as approval voting to find the options for an RfC, it was not intended to determine consensus for a final option. Thryduulf (talk) 11:31, 21 January 2022 (UTC)

Since you don't need consensus to start an RfC, Thryduulf, and this discussion seems more than sufficient, I think you should feel free to start it. KevinL (aka L235 · t · c) 02:34, 22 January 2022 (UTC)

@L235 as noted, I'm not going to have time to start it for a few more days. Thryduulf (talk) 01:19, 24 January 2022 (UTC)

RFC: Changing the icon for PDF files

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

Which icon should be used for PDF files?

• Option A: File:Icon pdf file.png
• Option B: File:PDF icon bold.svg
• Option C: File:PDF icon.svg
• Option D: Something else (to be followed up in a new discussion)

Discussion (Changing the icon for PDF files)

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

And the following people commented in the follow-up but not the first discussion: @JohnFromPinckney, Folly Mox, MB, CX Zoom, ResPM, IAmChaos, Mlb96, L235, and Jo-Jo Eumerus:. 09:42, 29 January 2022 (UTC)

Fixing pings: @Malcolmxl5 and Blaze Wolf:. Thryduulf (talk) 09:45, 29 January 2022 (UTC)

• Option A: This is the clearest on all the devices I have available to look at it on (desktop, laptop and Android mobile). Thryduulf (talk) 09:47, 29 January 2022 (UTC)
  • 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)
• Option A looks the best to me. ― Qwerfjkltalk 10:02, 29 January 2022 (UTC)

  Note: I'm on a tablet. ― Qwerfjkltalk 14:38, 29 January 2022 (UTC)

• Option A. The other two look dreadful on my browser, only A is crisp and clean.  — Amakuru (talk) 10:10, 29 January 2022 (UTC)

  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)

  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)

  Also oppose the suggestion of using text. That would be confusing and cluttered, whereas the current icon is fairly clear.  — Amakuru (talk) 17:38, 29 January 2022 (UTC)

• Option A. Seddon ^talk 10:11, 29 January 2022 (UTC)
• Option C - Clearer than option A. A. C. Santacruz ⁂ Please ping me! 11:10, 29 January 2022 (UTC)

  Option A - Nicest looking. A. C. Santacruz ⁂ Please ping me! 10:32, 29 January 2022 (UTC)

• Option A - clearest Nosebagbear (talk) 10:56, 29 January 2022 (UTC)
• @Nosebagbear, A. C. Santacruz, Seddon, Amakuru, and Qwerfjkl: I've just noticed that the image at Option C was actually displaying the option B icon. I've now fixed this, but you may wish to look again. Thryduulf (talk) 11:04, 29 January 2022 (UTC)
• Option C.--Vulp❯❯❯here! 11:14, 29 January 2022 (UTC)
• 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. — xaosflux ^Talk 11:27, 29 January 2022 (UTC)
• Option A: This looks the best at the small size. -- WOSlinker (talk) 11:30, 29 January 2022 (UTC)
• 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)

  I believe that's because A is a .PNG and C is a .SVG. Levivich 16:27, 29 January 2022 (UTC)

• Option B looks best on a small screen — GhostInTheMachine ^{talk to me} 12:24, 29 January 2022 (UTC)
• 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)
• 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)
• Option D (no icon) all of those icons look like they're from the 90s/early 2000s, tbh. And text "(PDF)" is adequate per above. – John M Wolfson (talk • contribs) 15:37, 29 January 2022 (UTC)
• 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. Levivich 16:42, 29 January 2022 (UTC)
• Option D (no icon). But, in case we do stick with one, Option A looks better to me. Isabelle ^🔔 16:47, 29 January 2022 (UTC)
• 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)
• 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)
  • @Huggums537: removing the icon completely was an option in the first RFC, it did not gain consensus then (using a different icon was). Thryduulf (talk) 18:28, 29 January 2022 (UTC)
    • 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)
• My preference would be an icon, as they stand out - lots of the text is just noise. ― Qwerfjkltalk 17:33, 29 January 2022 (UTC)
• Comment - As per a comment above, I will !vote after viewing on another computer and on smartphone. Robert McClenon (talk) 17:48, 29 January 2022 (UTC)
• "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)

  @Izno Can you do me a favor and, whenever asserting that something is not technically feasible, explain why? :-) Thanks, Levivich 18:05, 29 January 2022 (UTC)

  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)

  @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. Levivich 18:31, 29 January 2022 (UTC)

  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)

  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.

  What would we need a bot for? This would be a CSS change, no? Levivich 18:47, 29 January 2022 (UTC)

  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)

  Again, can you explain, rather than assert, why this cannot be done accessibly? What's inaccessible about :after and content: ? Levivich 19:00, 29 January 2022 (UTC)

  It cannot be read by screen readers, which have the same issues as they would with the icon. Izno (talk) 19:29, 29 January 2022 (UTC)

  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? Levivich 19:56, 29 January 2022 (UTC)

  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)

  I'm no expert, but looking at MediaWiki:Common.css and Help:External link icons, it appears the only options supported by MediaWiki are an icon or nothing. You could make an image of the plain text I suppose, but I can't think of any reason off the top of my head why that would be beneficial. Thryduulf (talk) 18:39, 29 January 2022 (UTC)

  @Thryduulf: I was able to accomplish it (replacing the icon with the text "(PDF)") with this local CSS hack just now. Levivich 18:54, 29 January 2022 (UTC)

• Option A Both B and C look blurry to me. I am opposed to no image, since I am personally quite glad to see the pdf icon at a glance, it is useful information. CaptainEek ^{Edits Ho Cap'n!}⚓ 18:06, 29 January 2022 (UTC)
• Option A or D, with "D" being a text-based equivalent such as the PDF used by Google. --Ahecht (TALK
  PAGE) 19:47, 29 January 2022 (UTC)
• Option A... glad to see change is actually taking place here! Aza24 (talk) 20:04, 29 January 2022 (UTC)
• Option A seems better. _{دَستخَط،} اِفلاق ^{(کَتھ باتھ)} 12:44, 30 January 2022 (UTC)
• Option A. Clearest of the A-B-c choices. The argument for no icon is reasonable, I just think an icon stands out more and works better. Herostratus (talk) 14:05, 30 January 2022 (UTC)
• 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)

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

  If that's so I would choose A (which appears to be winning a landslide anyway). Stifle (talk) 15:05, 31 January 2022 (UTC)

• 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)
• 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)
• 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 Genius ^talk 14:06, 31 January 2022 (UTC)
• 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 Wolf^Talk_{Blaze Wolf#6545} 14:47, 31 January 2022 (UTC)
• 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. MB 15:42, 31 January 2022 (UTC)
• 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)
• 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)
• 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)

  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)

  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)

• 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)
• Option A best on my device. — Wug·a·po·des​ 19:52, 1 February 2022 (UTC)

Gadget that simplifies references

I noticed on Watertown (city), New York that after archiving all the references the reference section looks like a mess, how about there should be a tool where reference sections remove the Retrieved on and Archived on text, and only shows "Source name, Source Publisher. Archive."instead of this. It sounds like it might be pretty easy to make, just set all values with the name "archive-date" and "access-date" to hidden, right?Lallint⟫⟫⟫Talk 23:37, 18 January 2022 (UTC)

No. This information (assuming it is entered correctly & justifiably) has semantic significance in verification. Both online sources and their online archives may be subject to change. These values are the only indicators of the consulted versions in Wikipedia's Citation System 1/2, and they should be evident. 68.173.76.118 (talk) 12:50, 19 January 2022 (UTC)

Wouldn’t it be possible to retain that semantic information but not display it, at least in certain circumstances? Example: certain site themes (e.g. mobile), or display via JS/CSS as a tooltip type display (similar to ‘efn’ popups?) Jim Grisham (talk) 12:47, 27 January 2022 (UTC)

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.

For example, the category tree of Category:People who died in office contained hundreds of articles at the time that it was deleted. Quite possibly, that list of articles could have been retained as a list, or some subset of particular interest could have been retained as a list (we have, for example, List of presidents of the United States who died in office, List of heads of state and government who died in office, and List of members of the New Zealand Parliament who died in office). I know of no way, at this point, to recover the contents of that category and its subcategories to determine whether additional such lists could be compiled from the data, which is a rather disappointing black hole of information.

I therefore propose that at the time that a category is deleted, a record should automatically be made of the list of articles contained in that category at the time of its deletion, unless some specific reason is articulated to avoid even the creation of such a record (e.g., the category was a BLP violation along the lines of a hypothetical Category:Politicians who probably secretly engage in insider trading and get away with it, or a straight-up hoax along the lines of a hypothetical falsely populated Category:University of Northeast Rhode Island alumni). BD2412 T 07:59, 19 January 2022 (UTC)

• @BD2412: if implemented, I think meta:Community Wishlist Survey 2022/Categories/Help to know if an article exists in a certain language from the categories. might solve your problem? — xaosflux ^Talk 10:31, 19 January 2022 (UTC)

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)

@Certes: I would say that the contents should be preserved before any emptying begins. BD2412 T 16:30, 19 January 2022 (UTC)

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

  Category changes can be configured to show up on the watchlist. See Help:Watchlist#Limitations. * Pppery * _{it has begun...} 14:05, 19 January 2022 (UTC)

  If memory serves, that's not a particularly reliable technique and it can't be shared between numerous people. Jo-Jo Eumerus (talk) 16:28, 19 January 2022 (UTC)

• Such a record is already retained in the contribution history of whoever emptied the category, which is usually JJMC89 bot III. * Pppery * _{it has begun...} 14:05, 19 January 2022 (UTC)
  • 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. BD2412 T 16:29, 19 January 2022 (UTC)
• 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)
  • 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. BD2412 T 07:31, 20 January 2022 (UTC)

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}} ^talk 03:11, 20 January 2022 (UTC)

*upvote*, great idea. Enterprisey (talk!) 04:15, 20 January 2022 (UTC)

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"? BD2412 T 06:09, 20 January 2022 (UTC)

@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:

1. I'd go to their last instance of position held (P39) and add the qualifier end cause (Q22087155) = death in office (Q5247364).
2. I'd go to both of the organizations that were merged and add merged into (P7888). For the resulting merger organization, if you look at examples like ExxonMobil (Q156238), you can see the merger expressed through follows (P155) and replaces (P1365).
3. I'd add symptoms and signs (P780) = inflammation (Q101991) (or a more specific item for a subclass of (P279) inflammation).

Hopefully most categories wouldn't be as complex as these. Many are already represented on Wikidata through the category combines topics (P971) property (for your first example, see Category:People who died in office (Q65757798)). Cheers, {{u|Sdkb}} ^talk 06:33, 20 January 2022 (UTC)

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? BD2412 T 06:38, 20 January 2022 (UTC)

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)

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)

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)

• Why soon-to-be-deleted? If WD people want to do this they can start anytime, no? — xaosflux ^Talk 23:40, 20 January 2022 (UTC)

  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}} ^talk 02:28, 21 January 2022 (UTC)

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. BD2412 T 22:42, 25 January 2022 (UTC)

• Support this seems like a very good idea that will improve the encyclopaedia. Thryduulf (talk) 08:07, 27 January 2022 (UTC)
• 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)

  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)

  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}} ^talk 17:55, 27 January 2022 (UTC)

• 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)
      • @Jim Grisham: I do appreciate the tip about the Internet Archive version, but it only saved the first page of results here (through G). Still, it's something to start with. BD2412 T 07:47, 30 January 2022 (UTC)
  • 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. — xaosflux ^Talk 13:21, 27 January 2022 (UTC)
    • • I was actually thinking that a bot could do it, and could pick up the category as soon as the nomination was filed. BD2412 T 17:28, 27 January 2022 (UTC)

        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)

RfC: Block reFill tool until fixed

Block reFill tool until fixed. -- GreenC 21:53, 21 January 2022 (UTC)

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.
• 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)
• 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)
• Option C first or B second as nom. -- GreenC 20:33, 22 January 2022 (UTC)
• Option C to start, but Option B is the better alternative once a process for approval is in place. Headbomb {t · c · p · b} 18:41, 25 January 2022 (UTC)
• 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)
• 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×g 07:33, 1 February 2022 (UTC)

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. — xaosflux ^Talk 22:55, 21 January 2022 (UTC)

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)

@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. — xaosflux ^Talk 00:09, 22 January 2022 (UTC)

No, my mistake, though authors of tools which suggest edits might want to consider complying as if they were bots. Certes (talk) 00:56, 22 January 2022 (UTC)

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)

• Is it possible to restrict usage of the tool by protection?--John Cline (talk) 00:43, 22 January 2022 (UTC)

  @John Cline: no, the protection tool can not distinguish the content or metadata of an edit. — xaosflux ^Talk 01:03, 22 January 2022 (UTC)

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

  +1 – Muboshgu (talk) 17:18, 22 January 2022 (UTC)

  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)

• See meta:Community Wishlist Survey 2022/Citations/New reference-filling tool. DMacks (talk) 19:09, 22 January 2022 (UTC)

  And Wikipedia:Village pump (technical)/Archive 194#Proposed Google Summer of Code project: expanding citations. Enterprisey (talk!) 06:05, 23 January 2022 (UTC)

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

  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. -- GreenC 20:07, 22 January 2022 (UTC)

  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)

• Here is another bug (i think?) on the Chris Lattner article. The first and last names are obviously not "Apple" and "Inc.", doesn't make sense. But could be wrong Rlink2 (talk) 19:39, 22 January 2022 (UTC)
  • This is not ideal but is it really worth blocking the tool over something so innocuous as this? – Muboshgu (talk) 19:50, 25 January 2022 (UTC)

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? -- GreenC 20:27, 25 January 2022 (UTC)

@Rlink2 and GreenC: looking at the markup of https://www.swift.org/ the head element contains the following:

<meta name="author" content="Apple Inc." />

Practically, how would you envisage that reFill, or any tool, should automatically determine that this is not the actual name of the author? Curb Safe Charmer (talk) 10:09, 26 January 2022 (UTC)

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. -- GreenC 17:02, 26 January 2022 (UTC)

• 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. -- GreenC 17:16, 26 January 2022 (UTC)

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

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. -- GreenC 18:22, 26 January 2022 (UTC)

• 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×g 07:40, 1 February 2022 (UTC)

  @JPxG: Great, thanks for your offer of help. I will contact you on your talk page. Curb Safe Charmer (talk) 09:51, 1 February 2022 (UTC)

Non-diffused category checker

Large categories are often broken down into smaller ones. The parent category may be "diffused", meaning that articles are held only in the child categories, or "undiffused", meaning that articles are held both in the parent category and in one or more of the child categories. With undiffused categories there is always the possibility that an article may be added to a child category but not to the parent, or vice-versa. To help detect these problems, which can then be easily fixed, I have mocked up {{Parent cat}} a category-heading template that can hold links to canned PetScan queries. To avoid clutter, it can also take the functions of the {{cat main}} and {{All included}} templates.

Example, for Category:Rivers of Pennsylvania:

This is a non-diffused parent category for categories in Category:Rivers of Pennsylvania by county‎‎. It should hold all the pages in the county-level categories, and may hold other pages such as lists.

• All county-level articles for this parent
• county-level articles not in this parent category
• articles in this parent but not in a county-level category

• The main article for this category is List of rivers of Pennsylvania

At time of writing,

• The parent category held 1,276 pages, including 4 like Class A Wild Trout Waters that do not belong in a county-level category.
• The list in All county-level articles for this parent had 1,278 results
• The list in county-level articles not in parent category had 17 results. E.g. Bentley Run is not in Category:Rivers of Pennsylvania, but should be.
• The list in Parent articles not in county-level category had 8 results. E.g. Deer Creek (Maryland) is not in Category:Rivers of York County, Pennsylvania, but should be

The first list is mainly useful if the template is put at the top of a diffused category, where it could replace a {{Category diffuse}} template. In theory, the query results should be exactly the same as the contents if the parent category were not diffused. For a diffused category such as Category:Rivers of England it would look like:

This is a diffused parent category for categories like Category:Rivers of Bedfordshire‎‎. It should not hold pages that belong in the county-level categories, but may hold other pages such as lists.

• All county-level articles for this parent

• The main article for this category is List of rivers of England

For non-diffused categories, the "child not in parent" and "parent not in child" lists can be used by any editor who wants to do category maintenance. They may not know how write PetScan queries, but they can review and correct anomalies, an ongoing process.

Comments? Aymatth2 (talk) 13:28, 22 January 2022 (UTC)

Seems like a good idea to me. Readers who are unsure if they are really looking at every article subcategorized under a parent category, could use the link to help find what they're looking for. For editors like me, who hadn't heard of the tool until recently, we can now easily use the tool to help find items missing from categories they should belong to (or remove ones that don't). DB1729 (talk) 15:04, 22 January 2022 (UTC)

Good idea. We could even have a bot to populate the parent from the children (are sort codes a problem?), though probably not vice versa. Can we improve the wording to clarify that pages like Class A Wild Trout Waters belong in the parent category only? Populated with the same pages as the child categories might be misinterpreted to imply ...and no other pages. Certes (talk) 15:13, 22 January 2022 (UTC)

I have tweaked the wording to "It should hold all the pages in the child categories, and may hold other pages such as lists." A bot to add the parent category to all child pages seems possible. I don't see a sort problem if the child pages use DEFAULTSORT... but a bot is a different discussion. Aymatth2 (talk) 15:58, 22 January 2022 (UTC)

Aymatth2. In my experience, many pages in the types of categories we've mentioned, do not use DEFAULTSORT because many are custom sorted differently for each category they're in. List of rivers of California is an interesting example. Despite it (redundantly) containing a DEFAULTSORT, every category it is in has a custom sortkey overriding the default.

I suppose there are problems like Thames River / River Thames. If a bot were developed, it would have to decide on an approach. Aymatth2 (talk) 17:18, 22 January 2022 (UTC)

Also just to clarify, I'm understanding it would replace the existing {{All included}} or {{Category diffuse}} template banners on the category pages. This change will be done on large categories only, correct? How large? Is there a threshold you had in mind? DB1729 (talk) 16:53, 22 January 2022 (UTC)

I would see {{Parent cat}} replacing {{All included}} or {{Category diffuse}} to avoid clutter, but only where someone has taken the time to write the queries. They are mostly simple enough though. I did not see any particular lower or upper size limit. I suppose the larger the parent category the more likely it is to drift out of sync. With Category:Rivers of the United States (which is diffused) PetScan returns only the first 10,000 pages to the browser, although it will generate a complete file for download. Aymatth2 (talk) 17:18, 22 January 2022 (UTC)

I'm not involved enough with categories to weigh in on the details here, but we should absolutely have an automated system (probably a bot) handling category diffusion. It doesn't seem very complicated from a technical standpoint.

I'm glad to see that the discussion above is taking into account that category pages are (at least ostensibly) reader-facing. {{u|Sdkb}} ^talk 06:23, 24 January 2022 (UTC)

A version of PetScan could present results of the "all child" query in a format identical to Wikipedia. Perhaps a template like {{unite|metacategory}} could automatically generate the list of child pages when the parent category is displayed, or when the reader clicks on a Show/hide sub-pages button, which would solve the maintenance problem. This may be a small step in that direction. Aymatth2 (talk) 13:40, 24 January 2022 (UTC)

Mohs hardness, Neel temperature, quantum physics, and curie temperature

Hi. I was wondering if you could add the mohs hardness ratings of all the metals? There's a conspiracy to replace mohs hardness scale with other scales in order to sell the testing machine.

Also, please recreate the neels temperature page. (I think Linus Torvalds was being extra special again).

Add seebeck coefficient to all the metals' wiki page.

Err... Add curie temp or Neel temp too.

Redirect quantum physics pages to relevant particle physics/nuclear physics pages.

And niobium has been removed from the curie temperature page? It was the most significant metal on that page because of super conductors.

@ElSeaLC: Very interesting, but I must digress from the topic you mention: @El C: FYI, seen this before? Mako001 (C)  (T)  04:03, 23 January 2022 (UTC)

Wait, now I have variances? Damn you, pocket dimensions! El_C 14:09, 23 January 2022 (UTC)

AFC reviewer bot

Should there be a bot to automatically decline unsourced drafts? (read this discussion) – AssumeGoodWraith (talk | contribs) 09:58, 23 January 2022 (UTC)

Not sure if we should be splitting the discussion from there to here, but I'll go ahead and repeat what I just wrote there: I agreed with Rusalkii that instead of having a bot outright decline unsourced submissions, let's have the bot list such submissions on a page so that human reviewers can more easily identify them to be declined. Mz7 (talk) 10:11, 23 January 2022 (UTC)

Ideally a bot that does that and pings the article creator going "This aint going to pass without sources". Only in death does duty end (talk) 12:30, 23 January 2022 (UTC)

The AfC submission script already does that (see [8]), even before the draft gets submitted. – SD0001 (talk) 15:51, 23 January 2022 (UTC)

@SD0001: That's very cool! I'd certainly support making that warning message a little bolder, though (maybe make it orange or red, not just yellow, and add a box). {{u|Sdkb}} ^talk 06:30, 24 January 2022 (UTC)

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)

Dammit, am I in the wrong place? valereee (talk) 22:19, 24 January 2022 (UTC)

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}} ^talk 05:33, 25 January 2022 (UTC)

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? — xaosflux ^Talk 11:39, 25 January 2022 (UTC)

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)

@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. — xaosflux ^Talk 14:26, 25 January 2022 (UTC)

Ah, sorry, I didn't read you correctly! :) valereee (talk) 14:35, 25 January 2022 (UTC)

Edit request procedures are usually discussed at Wikipedia talk:Edit requests (see Archive 1 for prior discussions). If the discussion stays here then a notification should be posted there. PrimeHunter (talk) 11:57, 25 January 2022 (UTC)

Sorry about that. Whichever is better is fine by me. valereee (talk) 12:01, 25 January 2022 (UTC)

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)

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)

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)

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)

Is there a reason ER patrollers aren't answering old requests instead of new ones? valereee (talk) 15:34, 25 January 2022 (UTC)

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)

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)

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.

This general discussion has happened on a few occasions, but never seems to come to anything definite. Wikipedia talk:Edit requests/Archive 1#Requiring verbatim suggestions is really worth a read, as we're just rehashing that conversation with fewer people at this point. ScottishFinnishRadish (talk) 16:34, 25 January 2022 (UTC)

SFR, just to be clear, I am not intending a criticism of your work. I'm questioning our standard operating procedure on this. valereee (talk) 16:24, 25 January 2022 (UTC)

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)

@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). — xaosflux ^Talk 16:32, 25 January 2022 (UTC)

I agree with this general concern but don't have any immediate thoughts on how to fix it. But I support doing something KevinL (aka L235 · t · c) 16:43, 25 January 2022 (UTC)

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)

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)

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.

Again, I think a lot of the concerns could be mitigated with better wording in the response templates, and some additional templates to cover more cases. ScottishFinnishRadish (talk) 00:05, 26 January 2022 (UTC)

Request for comment on template protection

Should the template protection cannot be applied to articles? Articles are rarely or almost never transcluded into another articles. Vitaium (talk) 01:15, 26 January 2022 (UTC)

• Comment – Parts of articles are increasingly transcluded into other articles using {{Excerpt}} (examples). However, that doesn't make template protection appropriate, as they are still articles rather than templates. Transcluded text typically appears in only a few articles, whereas template protection is typically applied to pages with thousands of transclusions, such as Template:Excerpt itself. Certes (talk) 01:29, 26 January 2022 (UTC)
• @Vitaium: Why do you think this is some sort of problem that needs an RFC? As of this posting there are exactly zero articles template protected. — xaosflux ^Talk 02:00, 26 January 2022 (UTC)
• If an article were excerpted into enough articles that it would qualify for template protection if it were a template, then it should be template protected. But I fail to see how that situation could possibly occur. Let's close this speculative RfC and cross that bridge when we get to it. * Pppery * _{it has begun...} 02:15, 26 January 2022 (UTC)
• I see there are some template-protected move articles in Category:Wikipedia template-protected pages other than templates and modules. Vitaium (talk) 02:28, 26 January 2022 (UTC)
  • @Vitaium: there are like three of them, and that's probably just due to misclicks. I really don't see why this needs an RfC, so I'm going to remove the RfC tag as none of the steps that are usually taken prior to a policy-changing RfC have been followed here. Elli (talk | contribs) 02:36, 26 January 2022 (UTC)
    • I went through and reset many of the levels from that page. — xaosflux ^Talk 11:38, 26 January 2022 (UTC)

Should the link to Wikipedia policies and guidelines in Template:Db-notice be changed?

(Original discussion here) Should the link to Wikipedia policies and guidelines be changed? Imagine this: You have joined Wikipedia a few hours ago. Your draft is deleted, for being a "test page" (or any other CSD criteria), and the only help available is this giant list.

Wikipedia:List of policies

Should this link/text be changed, and what to? – AssumeGoodWraith (talk | contribs) 10:57, 26 January 2022 (UTC)

Nice catch. I’ve been a casual editor for 15+ years now, and I can still get lost in the policies / docs / essays trying to find things… can’t even imagine coming in from scratch trying to get bearings.

(One of these days, I might make good on my threat to write a proposal for a global draft / clipping namespace, not tied to any one user and with no deletion time limit… a safe incubator for anonymous collaboration, like in the old days - it could be filtered out of normal maintenance tooling so as to not affect backlog, and maybe avert some issues like this as well)

Okay, a few actual ideas / thoughts:

• maybe it could point less to a single link / page, but more of a tree or a FAQ-type document / set of documents.
  • Something like a chat bot flow, perhaps, (but less reductive)?
• It’s probably worth asking someone who’s never edited Wikipedia before what questions they might have in this sort of situation… perhaps a retired middle-school language teacher, then a middle schooler herself.
• Perhaps we could survey new editors after their first 1, 5, 10 edits, and after deletions?
  • (but not via User:Talk page templates or notifications, please - that’s another learning curve all together!)
• An infographic or graphic novel policy introduction?
• (Finally, it shouldn’t need to be said, but experienced Wikipedia editors are probably poorly-suited for this kind of task.)
• Compare Wikipedia:List of policies and Wikipedia:Policies and guidelines. Now do the same thing from a smartphone browser. Jim Grisham (talk) 14:04, 27 January 2022 (UTC)

Maybe it should link to Wikipedia:Core content policies instead.

Also, "speedy deletion" is confusing jargon. Perhaps explain that it is "deletion without waiting for a discussion"? WhatamIdoing (talk) 02:12, 28 January 2022 (UTC)

Not too sure about "speedy deletion" being that confusing; it would be like calling "vandalism" confusing. It is, in fact, deletion which is speedy. – AssumeGoodWraith (talk | contribs) 09:39, 28 January 2022 (UTC)

Speedy deletion is not always speedy, and is not required to be speedy. WhatamIdoing (talk) 19:03, 28 January 2022 (UTC)

Invitation to an ongoing discussion

Hi, I recently started a discussion at Wikipedia:Village pump (policy) § Criteria for Speedy Draftifying. I have seen some similar discussions on this page too and maybe editors on this page would show interest, so I want to invite you all to participate in the discussion if you wish to. Thanks! ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 10:30, 27 January 2022 (UTC)

Restricting user page creation of new users

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 new (non-autoconfirmed) users be restricted from creating new user pages? Aasim - Herrscher of Wikis 00:08, 28 January 2022 (UTC)

Background

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 Wikis 00:08, 28 January 2022 (UTC)

Poll (restricting user page creation for new users)

• Agree - Is there any immediate need to have a userpage as soon as you register? I think this would cut down on the userpage spam. – AssumeGoodWraith (talk | contribs) 00:58, 28 January 2022 (UTC) Oppose 04:03, 28 January 2022 (UTC)
• 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. — xaosflux ^Talk 01:38, 28 January 2022 (UTC)
• Oppose – I'm pretty sure this would break Wikipedia:The Wikipedia Adventure. Also, user pages turn into a kind of honey trap for self-promoters and people with a conflict of interest. We actually want them to put that content there, right away, before they edit the mainspace. WhatamIdoing (talk) 02:14, 28 January 2022 (UTC)
• Oppose. Sure, miscreants can abuse their user page, but if it's not happening in mainspace, I just can't get too worked up over it. WP:AGF, my friend. -- RoySmith (talk) 03:11, 28 January 2022 (UTC)
• 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)
• Oppose; given how disclosure works this would make it impossible to comply with WP:PAID as it is presently written until the user became autoconfirmed. —A little blue Bori v^_^v ^{Jéské Couriano} 03:59, 28 January 2022 (UTC)
• 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. CaptainEek ^{Edits Ho Cap'n!}⚓ 04:39, 28 January 2022 (UTC)
• 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)
• 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)
• Oppose Many editors before me already noted why we shouldn't be restricting new users from creating Userpages and I agree with their reasoning. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 18:46, 28 January 2022 (UTC)
• 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)

Discussion

The snow is falling here. Selfstudier (talk) 18:55, 28 January 2022 (UTC)

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

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)

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)

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)

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)

File File:Prince logo.svg copyright status

It is believed that File:Prince logo.svg is copyrighted. However, it is very simple and therefore I believe that it is way below the threshold of originality. The file is in the public domain because it is too simple.--Alex Mitchell of The Goodies (talk) 22:32, 29 January 2022 (UTC)

@Alex Mitchell of The Goodies: ask at WP:MCQ where editors versed in copyright answer questions like this one. RudolfRed (talk) 00:24, 30 January 2022 (UTC)

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..

Darcourse (talk) 07:36, 30 January 2022 (UTC)

There is: wikipedia:Dark mode (gadget). ― Qwerfjkltalk 08:45, 30 January 2022 (UTC)

See also meta:Community Wishlist Survey 2022/Larger suggestions/Dark mode. Thryduulf (talk) 14:57, 30 January 2022 (UTC)

I made a Solarized skin for Vector (the default Wikipedia skin), which is here and looks like this. Perhaps you would find it helpful. jp×g 07:35, 1 February 2022 (UTC)

Infobox alloy

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)

You should take into account that there is quite a general Template:Chembox. Ruslik_Zero 20:00, 31 January 2022 (UTC)

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)

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)

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)

Proposal to Change The Romanization of North Korean language in Wikipedia

Annyŏnghasimnikka!

In 1992, the North Korean government sent a document containing official guidelines for romanization of the (North) Korean language to the United Nations. 29 years have passed, and Wikipedia is still using the 1939 McCune–Reischauer romanization for romanizing all things about North Korean.

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? 펑홍한talk 04:50, 1 February 2022 (UTC)

I can't answer your question, and have no opinion on the proposal, but I've left a note about this section at Wikipedia talk:WikiProject Korea where knowledgeable and interested Wikipedians are most likely to see it. Thryduulf (talk) 08:44, 1 February 2022 (UTC)

Offering the Reply Tool as an opt-out feature

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. PPelberg (WMF) (talk) 22:12, 1 February 2022 (UTC)

=== 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 experienced volunteers expect and value.

PPelberg (WMF) (talk) 22:13, 1 February 2022 (UTC)