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, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188

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

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is a consensus for Option A. Option A was the clear favorite among images and there was a consensus that there should be an image. A minority of editors would prefer to only have a text notation for PDF files (no icon), with this group of editors also largely preferring A if there had to be an image. Best, Barkeep49 (talk) 17:26, 3 March 2022 (UTC)

---

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

Which icon should be used for PDF files?

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

  For whatever reason, mediawiki renders the SVG as a 16x18 png on desktop browsers (which looks like crap) and a 32x37 png on mobile browsers (which looks fine). --Ahecht (TALK
  PAGE) 14:53, 9 February 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)

  @JohnFromPinckney: All the SVG images are converted to PNG by mediawiki before being displayed (see meta:Community Wishlist Survey 2022/Multimedia and Commons/Improve SVG rendering). For whatever reason, mediawiki renders the SVG as a 16x18 png on desktop browsers (which looks like crap) and a 32x37 png on mobile browsers (which looks fine). --Ahecht (TALK
  PAGE) 14:56, 9 February 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)
• Option D ~no icon + text, per Levivich and others; if we have to have an icon, Option B is the only one readable on my screen. Happy days ~ Lindsay^Hello 09:15, 5 February 2022 (UTC)
• Option A looks best to me; the text in the other options looks blurry at small size. kcowolf (talk) 03:48, 9 February 2022 (UTC)
• Option A, being the most legible on my device (a 27" 1080p desktop monitor), for what it's worth in sample size. Regards, User:TheDragonFire300. (Contact me | Contributions). 04:27, 9 February 2022 (UTC)
• Option A as the one that's sharpest, and thus most visible to me without reading glasses. (Sadly, I have become old!) The softer definition on B makes it liable to bleed. Guettarda (talk) 15:50, 9 February 2022 (UTC)
• Option B; second best Option C (1080p desktop monitor) --Wickey (talk) 13:07, 12 February 2022 (UTC)
• Option A, the clearest for me. Paul August ☎ 01:03, 17 February 2022 (UTC)
• Option A is the best clean visual on my monitor and color settings. Carlosguitar ^{(Yes Executor?)} 01:56, 17 February 2022 (UTC)
• Option A The "PDF" text is fuzzy on Option B and C, at least on my monitor/color settings anyway. Some1 (talk) 19:37, 20 February 2022 (UTC)
• Note The RFC tag has expired and it's been over 10 days since the last comment, so I've requested closure at WP:ANRFC. Thryduulf (talk) 16:48, 3 March 2022 (UTC)

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

Something doesn't look right

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

This is already under discussion at Mediawiki talk:Common.css#Protected_edit_request_(3_March_2022). Basically, this has always been an issue, but the new icon makes it much more noticeable. Writ Keeper ⚇♔ 10:55, 5 March 2022 (UTC)

Ah OK, thanks.  — Amakuru (talk) 11:21, 5 March 2022 (UTC)

The RfC implementation should be suspended and the new icon reverted, imo. It is conceivable that this rendering may have affected the result if known. Btw, the misshapen icon appears in Windows 10 and Mac 11 Edge, Chrome and Tor, Mac 11 Safari, and Ubuntu 20 Tor. It also appears in Android 11 desktop view in Edge and Chrome, but not the latest Tor app for Android 11. As of 15 minutes ago. 65.88.88.201 (talk) 17:22, 6 March 2022 (UTC)

It seems Tor 11.0.6 for Android 11 (kernel 4.19.157) desktop view scales the icon down, so it appears whole. 65.88.88.201 (talk) 18:03, 6 March 2022 (UTC)

On an old version of the Pale Moon web browser the icon also looks cut off, along with an old version of Tor browser. Works fine in Chrome, along with updated versions of Pale Moon and Tor. Rlink2 (talk) 18:59, 6 March 2022 (UTC)

As all three icons in the RfC have the same aspect ratio I believe that this issue (which certainly wasn't known to me when I started the RfC) I strongly suspect it will affect all identically so simply re-running the RFC would be pointless, we'd have to go back to evaluating more options (given the clear consensus for an image that isn't based on the Acrobat logo). A solution has been proposed at the MediaWiki talk page (where this discussion should be happening to keep it all in one place), that one other person has stated works for them (I don't understand it enough to test it myself). If that does solve the problem and can be implemented soon without side effect (I have no idea) then just doing that is going to be less disruptive than two additional changes of the icon. Thryduulf (talk) 21:00, 6 March 2022 (UTC)

If this is in reference to Trappist's solution, this probably affects <0.1% of the continuous rolling average of Wikipedia users, i.e. readers logged in (as handle-based accounts). 68.173.76.118 (talk) 00:56, 7 March 2022 (UTC)

Credit for the solution to the clipped-icon problem does not go to Trappist the monk. Credit for the solution (a tweak to Mediawiki:Common.css) goes to Editor Writ Keeper.

—Trappist the monk (talk) 01:48, 7 March 2022 (UTC)

(and also, to be clear, it hasn't actually been implemented yet.) Writ Keeper ⚇♔ 02:03, 7 March 2022 (UTC)

Can confirm that the icon now appears correctly in safari 15.3, MacOS 11.6.4. 68.173.76.118 (talk) 01:26, 7 March 2022 (UTC)

I came here to report the same problem. I've tried doing a hard refresh but the top and bottom of the PDF icons are still getting cut off. Modest Genius ^talk 15:11, 15 March 2022 (UTC)

Weirdly, it now seems to have fixed itself. Modest Genius ^talk 15:25, 16 March 2022 (UTC)

A fix was implemented at MediaWiki_talk:Common.css#Protected_edit_request_(3_March_2022). --Ahecht (TALK
PAGE) 01:45, 24 March 2022 (UTC)

Proposal to change portal links on the Main Page

Should the proposal to change portal links on the Main Page described below be adopted? {{u|Sdkb}} ^talk and JBchrch talk 01:19, 15 March 2022 (UTC)

Notified: WP:CENT, WT:Main Page, WT:Usability, WT:PORT. {{u|Sdkb}} ^talk 01:19, 15 March 2022 (UTC)

Background

Current location of the portal links on the Main Page

Wikipedia's portals have long suffered from low readership and poor maintenance. There have been numerous efforts to curtail them in recent years, some of which garnered substantial support, and the community has chosen to delete many hundreds of unmaintained or unread portals. In contrast to this tenuous state, portals enjoy extremely prominent positioning at the top of the Main Page, where eight of them and the portal contents page is linked in the very top banner, above even the TFA and ITN. The specific portals receive only 2000–5000 pageviews per day, less than well-performing DYK hooks which appear much farther down and often more briefly. The portals contents page does marginally better, with a daily average of 11,800 views.

Separately, the Desktop Improvements Team has introduced a new button for switching between language editions, and has been discussing on Phabricator how it might appear on Main Pages.

Last October, JBchrch made a proposal to remove the portal links from the Main Page, per the web usability principle that underutilized links should be cleared out to reduce clutter. It received 30 !votes in favor and 17 opposed, but was closed as no consensus because it did not offer clear-cut choices and thus did not manage to elicit clear-cut responses. After discussion on the closer's talk page and a challenge at the administrators' noticeboard, the close was left standing. Last month, the closer launched a follow-up discussion asking broadly whether the display should be kept or changed, but it was withdrawn after procedural objections in part about its lack of specificity. {{u|Sdkb}} ^talk 01:19, 15 March 2022 (UTC)

Proposal

We propose the following related changes:

1. Remove the portal links from the top banner and center-justify the Welcome to Wikipedia message.
2. Move the link to the portals contents page to the {{Other areas of Wikipedia}} section lower on the Main Page, adding Content portals – A unique way to navigate the encyclopedia.
3. Add the language switcher button to the newly freed space in the upper right corner.

• Mockups
• 

  Top banner proposal: portals links removed and language switcher added

• 

  Proposed addition of portals contents link to {{Other areas of Wikipedia}}

Best, {{u|Sdkb}} ^talk and JBchrch talk 01:19, 15 March 2022 (UTC)

Survey (Portal links)

• Support as co-proposer. Our Main Page should not be featuring so prominently links that are barely ever used, that don't represent our best work, and that clutter its design. The other areas section is a suitable new home for the portal contents page, offering a middle ground that allows us to avoid complete removal. The language switcher is a helpful feature for the Main Page that will fit nicely in the newly freed space. {{u|Sdkb}} ^talk 01:19, 15 March 2022 (UTC)
• Support as co-proposer. The proposed changes are an improvement on the current design of the main page. They modernize the interface by cutting down on bluelinks and helping the reader focus on more representative parts of the project, such as TFA. The language switcher is not only a functional tool, but also serves as a symbol for the global nature of the Wikipedia project. Access to the portals is relocated in a manner that's proportional to their importance and readership. JBchrch talk 01:53, 15 March 2022 (UTC)

Support looks good and cleaner. We could increase the size of "Welcome area" to lessen white area.Moxy- 02:00, 15 March 2022 (UTC)

• Support, the "Welcome" message is centered which looks much nicer, and having a language switcher front and center when a user goes to the main page of Wikipedia can be very helpful. I only have one critique and that is how the language switcher looks, however it's very minor and not that jarring compared to how much nicer the main page looks in the mockups. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 02:12, 15 March 2022 (UTC)
• Support It looks nicer, more professional, and more modern. Plus, Portals should not be the focus of readers. We have a lot better work to show off. CaptainEek ^{Edits Ho Cap'n!}⚓ 02:33, 15 March 2022 (UTC)
• Support, I like the new proposal, and portals, while an interesting idea for their time, just never really have quite worked out. Seraphimblade ^{Talk to me} 03:27, 15 March 2022 (UTC)
• Support, whatever the importance and relevance of portals, it is certainly not enough to warrant the prominence of their current inclusion. Having our welcome and main title pushed so far to the left (so close to the icon!) is unproductive and generally bad design. This is a definite improvement. Aza24 (talk) 03:47, 15 March 2022 (UTC)

  @Aza24: It doesn't push it over at all. Try viewing at (say) 1280px wide (or zoom out a few steps) - there's a big gap between the three "Welcome to Wikipedia," lines and the three rows of portal links. --Redrose64 🌹 (talk) 09:26, 15 March 2022 (UTC)

  @Redrose64: I was referring to the literal Wikipedia logo (the globe) in the corner being so close to the "welcome to wikipedia", making both feel redundant. Since I am on a standard laptop, viewing the page as many people do, if I have to adjust my screen to see a more desirable layout, that is an issue. Aza24 (talk) 23:16, 15 March 2022 (UTC)

  I don't mean that you should zoom out permanently - just long enough that you can see that no pushing is going on. --Redrose64 🌹 (talk) 21:15, 16 March 2022 (UTC)

• Support, great idea and much better looking. A. C. Santacruz ⁂ Please ping me! 06:58, 15 March 2022 (UTC)

  Actually, maybe it would be best to change the wording on the other areas as "Navigate the encyclopedia by topic". Still support whatever phrasing ends up gaining consensus. A. C. Santacruz ⁂ Please ping me! 10:23, 15 March 2022 (UTC)

• Support, looks much better. Cavalryman (talk) 09:49, 15 March 2022 (UTC).
• Strong support: this is mostly a formality after the previous discussion, and my comment in that discussion still stands. I also agree with much of what others have written. — Bilorv (talk) 10:26, 15 March 2022 (UTC)
• Support: I can maybe add something here insofar that I would like to say that as a fairly long-time reader / passing visitor, I don't recall a single instance of my having clicked any of these portal links before today. This seems like a clear improvement and may even result in these pages functionally becoming more visible to people looking to learn some more about this place, as this proposal would group them up with some of the more dynamic starting points for doing that. Dr. Duh 🩺 (talk) 10:39, 15 March 2022 (UTC)
• Support portals aren't used that much, and don't need to feature so prominently on the main page. Joseph2302 (talk) 10:42, 15 March 2022 (UTC)
• Procedural oppose. Per my extended comments below, this RFC is extremely non-neutral and so invalid. Thryduulf (talk) 12:43, 15 March 2022 (UTC)

  I also oppose on the merits. This proposal would significant inconvenience thousands (at least) of visitors without bringing any benefits to those people who do not use the links, nor does the vague proposal to replace it with nothing or a language switcher come remotely close to providing a similar benefit to a similar number of people. Thryduulf (talk) 17:27, 17 March 2022 (UTC)

• Procedural oppose and speedy close per Thryduulf. This proposal is rehashing a proposal already made last autumn, and which had no consensus because it didn't propose a clear alternative. We asked you to explain how the space freed up by the portal removal would be put to better use, and this has not been answered. Please come up with a concrete proposal, and we can consider it.  — Amakuru (talk) 12:47, 15 March 2022 (UTC)

  Just to add to this, and what I think would make the difference, would be to move the line about "the free enyclopedia that anyone can edit" and the article count over to the right-hand side, while leaving "Welcome to Wikipedia" on its own on the left, and then reduce the overall vertical space of that banner so that the featured sections of the main page are more prominent on first load. I'd support removal of portals if a benefit like that could be demonstrated, but not otherwise. Adding the language dropdown and moving the welcome banner to the centre just makes the issue worse, IMHO. Why are links to foreign-language sites which are external for us more useful to a reader than portals, which are gateways into our own content? Doesn't make sense.  — Amakuru (talk) 12:53, 15 March 2022 (UTC)

  You are of course free to express a view on the proposal, but I would ask you to please not convert it into a procedural argument. This proposal is materially different from the two previous discussions and is not a rehash. Your advice that efforts should be concentrated on the creation of a new, consensual [5][6] and specific [7] proposal was not overlooked, I can assure you of that. The design approach adopted here may not be exactly the one you suggested (there were many), but that does not invalidate the proposal from a procedural standpoint. JBchrch talk 14:56, 15 March 2022 (UTC)

• Weak support. Those portal links get a surprisingly high amount of traffic for static links. Perhaps not enough to justify being right at the top of the page, but enough to be on the page somewhere. Nevertheless this proposal does improve the design and I expect the language button would get more use than the current portals list does. Three caveats:
  1. If we put a language button in such a prominent location, we should remove the 'Wikipedia languages' section at the bottom of the page, to avoid duplication.
  2. The 'unique way' wording is poor and uninformative. I would prefer something like 'browse by topic' or 'content organised by topic' (though the latter has ENGVAR issues).
  3. Implementation clearly has to wait until the language button has been thoroughly tested and is ready for millions of users. The page on Meta still refers to May 2021 as if it's in the future, so is presumably very out of date.

Modest Genius ^talk 13:12, 15 March 2022 (UTC)

• Support Much better than outright removing them. NW1223 <Howl at me•My hunts> 15:22, 15 March 2022 (UTC)
• Support. Ruslik_Zero 20:27, 15 March 2022 (UTC)
• Support as an incremental improvement over the status quo, per nom and other support voters above, and per my comments and others' in the last RFC as to what's wrong with the status quo (low clicks, prime screen real estate, etc.). I also support Amakuru's suggestion to, instead of having the language toolbar, move the logo to the left and the tagline to the right, and reduce the vertical size of the entire grey box at the top. That would be another incremental improvement. I see no problem with the neutrality of the RFC statement, the "proposal" section, or the "background" section (and the last one doesn't need to be neutral anyway, as it's just an extension of the proposer's proposal). Levivich 20:32, 15 March 2022 (UTC)
• Support anything to get the portal links off the top of the page, even though I agree with the Modest Genius about the misuse of the word unique in the proposal. I don't care what happens with the language switcher. I also agree with Levivich in saying that this RFC isn't unreasonably, deceptively, or confusingly non-neutral. Perfection is not required in an RFC question. WhatamIdoing (talk) 03:50, 16 March 2022 (UTC)
• Strong support - a solid step in the right direction. Cleaner, clearer, more useful. Good point from Modest Genius regarding making sure the language button is 100% ready before this is implemented. Retswerb (talk) 05:07, 16 March 2022 (UTC)
•  Support ― Qwerfjkltalk 07:05, 16 March 2022 (UTC)
• Good idea but procedural oppose Biased RFC, and respecting the process matters. Suggest a do-over because this is a good well founded idea. North8000 (talk) 13:11, 16 March 2022 (UTC)
• Support Given most of the previous blockers to actually doing anything have been satisfied. I fully expect more goalpost moving however - its getting to the point of being actively disruptive. Only in death does duty end (talk) 13:29, 16 March 2022 (UTC)
• Support in any form, though I concur with adjusting the description to be more informative and to match the rest of the box, for example Portals –Topic-by-topic overviews of Wikipedia's content. Ninepointturn (talk) 15:11, 16 March 2022 (UTC)
• Support in theory though I think the execution is a little off. I'd prefer the "Welcome to Wikipedia" bit be larger to fill some of the white space. The language menu seems out of place too. Calidum 21:55, 16 March 2022 (UTC)
• Support. Basically, though not the fine details. The portal links space is quite unjustified, and improvements to the Main page should proceed without a requirement for a Village Pump RfC written-in-stone detail for every increment. Yes, move the Portal links as proposed. However, do not lock in decisions on a "language switcher button" or the "unique way" wording that needs copy-editing. In 5 seconds I suggest "Contents portals for navigation", but after typic it am leaning to "Contents portals". If portals do have value, why would the link have to explain them? --SmokeyJoe (talk) 04:38, 17 March 2022 (UTC)
• Support - can be twiddled in the details, but moving portals out of the prime real estate makes sense all round. I like the the language selector up top, but that's definitely secondary to getting the under-maintained portals out of the spotlight. --Elmidae (talk · contribs) 14:03, 17 March 2022 (UTC)
• Support - there's value in whitespace -- not every pixel has to be filled. That said, I'm not a huge fan of the "unique way" wording -- a content directory by category is hardly unique and has been a web staple for 25 years (see DMOZ or Yahoo! Directory). --Ahecht (TALK
  PAGE) 15:14, 17 March 2022 (UTC)
• Support Frankly I would like to see Portals go the way of the dodo and the Book: namespace, but this is a step in what I believe is the right direction casualdejekyll 01:16, 18 March 2022 (UTC)
• Support with the caveat, mentioned by others, that the wording on the new Content portals blurb could be improved. Ganesha811 (talk) 20:05, 19 March 2022 (UTC)
• Support moving Portal links from top of Main Page. The new grey banner with language switcher looks more modern. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:56, 20 March 2022 (UTC)
• Support Long overdue. --Jayron32 13:30, 21 March 2022 (UTC)
• Support. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 09:40, 23 March 2022 (UTC)
• Support If it's moved somewhere, then sure. --99.227.9.86 (talk) 17:00, 24 March 2022 (UTC)
• Support per previous discussions. I'd rather they be removed entirely but this is a step in the right direction. SnowFire (talk) 03:40, 26 March 2022 (UTC)
• Support per previous. No objection to iteration on the wording in the "other things you can do" part of the main page. The language switcher may or may not come (hopefully it does). I am happy to implement on the main page if/when this is closed in support of the change. --Izno (talk) 17:21, 27 March 2022 (UTC)
• Support looks better, cleaner, and the language switcher would help users access other languages easily. Itsquietuptown ✉️📜 02:05, 29 March 2022 (UTC)

  No, the language switcher makes other languages harder to access: they'll be two or three clicks away rather than one. I understand the desire to prevent readers from discovering portals and congratulate the supporters on their tenacity in finally making them invisible, but replacing them by the language switcher would just make another useful feature less accessible too. Certes (talk) 11:50, 29 March 2022 (UTC)

  The language switcher is coming whether we want it or not, though whether it takes this form on the main page is an open question. See phab:T293470. Izno (talk) 19:37, 29 March 2022 (UTC)

• Comment - After the end of this RfC, I suggest individual discussion about the language switcher button. I didn't see clear benefits for readers in replacing links to portals per links to other Wikis. If the initial goal was a clean layout, this change doesn't make much sense.Guilherme Burn (talk) 19:41, 29 March 2022 (UTC)

  Seconded. Part of the case for removing the portal links is that the space is needed for something else, and the language switcher is a convenient "something else" to propose, but we should only adopt it if it's beneficial, not just to fill space. Certes (talk) 21:59, 29 March 2022 (UTC)

Discussion (Portal links)

This RFC has one of the least neutral background statements I've read in a long time with lots of value judgements and disputed statements such as:

• Wikipedia's portals have long suffered from low readership - this has been disputed in every discussion about portals on the main page, with the figures used by those claiming this actually demonstrating the opposite.
• There have been numerous efforts to curtail them in recent years, some of which garnered substantial support and all of which also garnered substantially opposition and none of which achieved consensus to curtail them.
• the community has chosen to delete many hundreds of unmaintained or unread portals. True but completely irrelevant to the portals on the main page.
• In contrast to this tenuous state what tenuous state?
• portals enjoy extremely prominent positioning at the top of the Main Page, where eight of them and the portal contents page is linked in the very top banner, above even the TFA and ITN. There is no neutral explanation of why this is seen a problem?
• The specific portals receive only 2000–5000 pageviews per day, less than well-performing DYK hooks which appear much farther down and often more briefly. The portals contents page does marginally better, with a daily average of 11,800 views Once again, there is no neutral explanation of why this is a problem.
• Separately, the Desktop Improvements Team has introduced a new button for switching between language editions, and has been discussing on Phabricator how it might appear on Main Pages. So?
• Last October, JBchrch made a proposal to remove the portal links from the Main Page, per the web usability principle that underutilized links should be cleared out to reduce clutter. It received 30 !votes in favor and 17 opposed, but was closed as no consensus "because it did not offer clear-cut choices and thus did not manage to elicit clear-cut responses." And also because there was no consensus that there was a problem that required solving.

Given all of this, I'm not convinced that this RFC can be seen as valid. Thryduulf (talk) 12:42, 15 March 2022 (UTC)

I'm not going to try and dismiss your comment, however you have said that it's not neutral, but haven't attempted to show how it could be made neutral. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:52, 15 March 2022 (UTC)

I'm not the one making the proposal, so it's not my job, but it would need to be completely rewritten without the emotive language, without the irrelevancies and based completely on undisputed facts, with a clear statement of what problem has been identified, why that is a problem (again based on facts and acknowledging that everything subjective is disputed), what is being proposed to fix this problem and how this fix will be an improvement. It is not possible to make this neutral with small tweaks. Thryduulf (talk) 14:58, 15 March 2022 (UTC)

Alright then. I was merely saying that because I feel that showing exampled of how it could be made neutral might help with making it more neutral in the future if this is indeed closed due to not being neutral. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 15:00, 15 March 2022 (UTC)

• The proposal itself is neutral… the “background” section is not. Would it help to move that into the survey? Blueboar (talk) 15:56, 15 March 2022 (UTC)

  Not really to be honest as it's already irrevocably invalidated this RFC and even if that weren't the case it would be inappopriately long and out of place in the survey section. It would be distinctly odd at best in the discussion section given that it's written to be a background to the RFC not a response to it. Thryduulf (talk) 18:19, 15 March 2022 (UTC)

  meh… It represents the nominator’s opinion of what led up to this RFC, and so is a factor in explaining his/her opinion as to the outcome. If you think it is flawed, you can always write an “alternative-background” expressing your take on the situation. In any case, I do think that the basic question was neutral. Blueboar (talk) 19:02, 15 March 2022 (UTC)

  There is no requirement that any remarks posted by the OP be neutral beyond the initial question.

  Also, I think it's important not to fetishize neutrality for proposals. If you're proposing a major change, you should be in favor of it. You should not waste our time with a proposal that you oppose or that you don't care about one way or the other. WhatamIdoing (talk) 03:45, 16 March 2022 (UTC)

  They've given their remarks highly prominent positioning above the actual proposal. Normally when starting an RfC, people put their arguments in the survey section. Chess (talk) (please use {{reply to|Chess}} on reply) 14:19, 20 March 2022 (UTC)

  If they put exactly the same words under ===Survey=== instead of under ===Background===, their words would still have "highly prominent positioning". The RFC question (=the thing that needs to be neutral) is "Should the proposal to change portal links on the Main Page described below be adopted?", and that's above both the ===Background=== and ===Proposal=== subsections. WhatamIdoing (talk) 20:14, 21 March 2022 (UTC)

I have to agree that this is a manifesto rather than an RfC. To pick just one point, I don't see how only and 2000–5000 pageviews per day belong in the same sentence. That's about a million visits annually for each portal. Do we really want to frustrate that many readers? (The proposal's title suggests that adding a language button isn't the main goal.) Certes (talk) 23:32, 15 March 2022 (UTC)

The main page gets 5.5 million daily views (that's over two billion a year). I don't think our readers will be frustrated if we move links that are clicked on less than 0.05% of the time (1 million out of 2 billion). Levivich 14:42, 17 March 2022 (UTC)

The issue is that we would be inconveniencing the readers who use the links without providing any benefit for those that don't. Thryduulf (talk) 17:24, 17 March 2022 (UTC)

Of course it would provide a benefit to those that don't (declutter, more attractive interface, etc.), otherwise why would so many of your colleagues support it? Levivich 17:45, 17 March 2022 (UTC)

If something is clicked by 0.05% of visitors, there is a not-unreasonable chance that half that traffic is bottraffic which we are unable to detect as bot traffic... We know that ppl use proper user agents for their bots and we thus have undetected bots. And if I wrote a bot, I too would start by going through all the links on the main page, so anything linked from the main page has a high chance of getting such automated traffic. The point being that it is very hard to estimate if such traffic is significant, without looking at several other elements listed. —TheDJ (talk • contribs) 14:46, 29 March 2022 (UTC)

• @Sdkb and JBchrch: do you have a screenshot of what the new design will look like in Mobile wikipedia? Would be interesting to see where and how much space the language switcher would take. The current one has portal links after the welcome block and takes up 10-15% of screen height. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:37, 20 March 2022 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, for the portal link farther down, you can go here on mobile. I don't have a mobile screenshot of the top, but I'm sure someone else could make it fairly easily. {{u|Sdkb}} ^talk 18:08, 20 March 2022 (UTC)

Proposing a change to the notability declining message in AFC

From:

This submission's references do not show that the subject qualifies for a Wikipedia article—that is, they do not show significant coverage (not just passing mentions) about the subject in published, reliable, secondary sources that are independent of the subject. Before any resubmission, additional references meeting these criteria should be added (see technical help and learn about mistakes to avoid when addressing this issue). If no additional references exist, the subject is not suitable for Wikipedia.

to:

This submission's referencing do not show that the subject qualifies for a Wikipedia article. See an explanation for our inclusion guidelines here.

In summary: the sourcing in this article does not demonstrate significant coverage (not just passing mentions) about the subject in published, reliable, secondary sources that are independent of the subject. Before any resubmission, additional references meeting these criteria should be added (see technical help and learn about mistakes to avoid when addressing this issue). If no additional references exist, the subject is not suitable for Wikipedia.

I think less people will be confused about the decline message then. – AssumeGoodWraith (talk | contribs) 02:35, 16 March 2022 (UTC)

• Support seems more clear than current version. _signed, 511KeV ^(talk) 15:42, 16 March 2022 (UTC)
• Support, but change "do not" to "does not" for grammatical reasons. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 16:08, 16 March 2022 (UTC)

  I would also change "Before any resubmission, additional references meeting these criteria should be added" to "Make sure you add additional references that meet these criteria before resubmitting". Less aggressive but still gets the point across. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 16:13, 16 March 2022 (UTC)

• I think it's important to make it more clear, thanks for the proposal :). The wording is still relatively academic: long sentences, difficult words. Would it work better to use bullet points for the sourcing requirements? This may make it easier to mentally tick the boxes. I may be wrong, but I thought the best convention now is not linking words without meaning (like here). I like Blaze's Wolf suggestion about softening the language. Femke (talk) 20:45, 16 March 2022 (UTC)
• I'm feeling daft - is the only difference here adding a hard return after the main statement with some minor formatting tweaks? (please ping on reply) Primefac (talk) 09:10, 17 March 2022 (UTC)
• Support highlighting the key statement is key to getting many to read anything in these notices. Lots of these templates could be improved with some minor tweaks. Regards KylieTastic (talk) 09:35, 17 March 2022 (UTC)
• Oppose at the moment. In the future I suggest proposing things like this at WT:AFC, or at least leaving us a note on that talk page. By proposing this here I kind of feel like you left WikiProject AFC out of the discussion. Anyway, here are my concerns: 1) This seems to add vertical whitespace. I would suggest removing the line breaks. 2) This links yet another policy page for the draft writer to read. There's a danger of information overload. If anything we could look into making this more concise. –Novem Linguae (talk) 15:18, 17 March 2022 (UTC)

• Trying to address information overload, bringing out the four criteria for sources (which a large portion of new editors struggle with), and cutting out the least helpful link (most people understand how to add a source at this point, the 'verification' decline message can provide technical help if they struggle). On a side note, we don't do that well explaining notability before submission. The Article Wizard has a great short and easy explanation how to use sources, but the notability explanation is a bit vague.. Femke (talk) 17:35, 17 March 2022 (UTC)

This draft's references do not show that the subject qualifies for a Wikipedia article. In summary, the draft needs multiple published sources that are:

• in-depth (not just passing mentions)
• reliable
• secondary
• independent of the subject

Make sure you add references that meet these criteria before resubmitting. Learn about mistakes to avoid when addressing this issue. If no additional references exist, the subject is not suitable for Wikipedia.

Femke (talk) 17:35, 17 March 2022 (UTC)

Seems good. – AssumeGoodWraith (talk | contribs) 23:45, 17 March 2022 (UTC)

However, it should say like “not just passing mentions about the subject” – AssumeGoodWraith (talk | contribs) 23:59, 17 March 2022 (UTC)

I agree. This is a lot simpler compared to the current message, which contains 7 links (compared to the 5 of Femke's proposed message) and takes up 4 lines on my screen size (1366x768). This also gives the reader the main issue in bold so that if they don't want to read the rest, they can see the issue with their article quickly and easily. IF the reader does continue reading, the bullet-points listing what the sources should be make it easy to know what they should be looking for in sources. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 00:09, 18 March 2022 (UTC)

I like this a lot, it breaks up the wall of text and draws attention to the important points. Rusalkii (talk) 18:14, 18 March 2022 (UTC)

@Rusalkii: You pretty much just said the exact thing I did, except in a lot fewer word and it makes more sense than what I was saying. (nothing bad about either of our responses, I just found it kinda funny how we basically said the same thing, but I just chose to go into more detail) ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:46, 18 March 2022 (UTC)

@Femke, I suppose the proposed notability message will be applied downstream on the specific SNG notability messages as well? (see {{AfC submission/comments}} for the full list of the messages possibly applicable) – robertsky (talk) 07:20, 21 March 2022 (UTC)

Support; Femke's version of the message is a clear improvement to the current one. Much more clear and concise. LunarisTFM (💬 • 📝) 15:10, 28 March 2022 (UTC)

This basically says the the sourcing-GNG is the only way in. If you want it to be accurate you'd need to instead say that it's the best way in. (SNG's being the other).North8000 (talk) 19:07, 18 March 2022 (UTC)

I'm fairly sure SNG's basically just build off of GNG. If an article follows GNG it should also be following SNG's, and if it fails GNG I don't think it would be supported by SNG's. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 19:10, 18 March 2022 (UTC)

There are some SNGs that are alternatives to GNG, like WP:NPROF. We have a separate decline message for those (which in the case of an academic not showing notability, doesn't put enough emphasis on the SNG, but that's for another day). I don't think I've changed the meaning here from the old decline message. Femke (talk) 19:14, 18 March 2022 (UTC)

(edit conflict) That's a complicated topic. But the wiki standard is that a new article just needs to meet either the sourcing GNG or the SNG. Why use a different standard at AFC? North8000 (talk) 19:17, 18 March 2022 (UTC)

My concern with all of these versions is that they assume that the AFC reviewer correctly declined the submission, which is not always the case. I remember one BLP declined with this message, and when the editor inquired with the reviewer, the answer amounted to "Oops, nobody ever told me that WP:NONENG sources were okay." Presumably this is not the usual experience, but in that case, what was needed was just a re-submission (to get a reviewer who happened to know the actual rules) instead of adding more sources. WhatamIdoing (talk) 20:18, 21 March 2022 (UTC)

I don't see that as a problem with the text of these messages, but as a problem of screening / providing info for new reviewers. If I'm not mistaken, scrutiny for new reviewers has increased? A second solution to that problem would be to do random checks, and give feedback to reviewers when they make mistakes. Femke (talk) 20:27, 21 March 2022 (UTC)

I think there's a pretty significant ratchet effect at AFC. Nobody wants to be the reviewer who followed the long-standing written directions, because you could be accused of being a lax reviewer who is passing anything with a decent chance of surviving AFD (which is what the AFC directions say all reviewers should do, but...), and that's unpleasant. So the articles that get accepted through AFD are the highest quality ones, and that means the "normal" accepted article is very good, so you want to accept only articles that are better than average, so...

If the trend continues, then of course eventually we'd want to merge FAC and AFC, because the standards would be the same. I don't think we'll get to that point, but we're getting pretty high. Here are the five most recent articles accepted at AFC, with their ORES ratings:

• Voyage to the Stars – C-class
• Seaborn Wright – Stub
• Reading 2100 – C-class
• Choi Jae-seo – C-class
• Pleasant Hill Historic District (Macon, Georgia) – Start-class

The median rating for English Wikipedia's articles is "Stub". C-class and above is the top 10% of all articles. Why aren't most AFC articles also stubs at the time they're accepted?

Here are the five most recently declined drafts (I can't get ORES ratings for drafts, so I add my own comments):

• Draft:Amityville Gas Chamber – no independent sources; I have no idea if it meets WP:NFILM. Probably Start-class.
• Draft:Pixpro Software – four sources cited, one of which might be an independent (but probably also lower-quality) trade rag. Probably Start-class.
• Draft:Lloyd Business School – All India Council for Technical Education-approved school = would almost certainly survive AFD. Stub.
• Draft:Pop Danilo – 17th-century painter with a book for a source = would almost certainly survive AFD. Start-class.
• Draft:Mini Me Dolls – No independent sources. Product likely non-notable. Barely Start-class.

So you can see, I hope, that I agree more often than I don't, but since two notable subjects were declined in this group, I suspect that the AFC reviewers are looking for a "nice" article or an "above-average" article, instead of an article that is likely to survive AFD on the grounds that the subject is notable.

This gap is what makes me wonder whether these instructions should be written more like ClueBot's warnings: Hey, this is just one person's opinion, and that person could be wrong, but that person thinks you need more/better sources. WhatamIdoing (talk) 20:43, 22 March 2022 (UTC)

From what I've seen so far, I think I agree about the standards at AfC being a bit too high. Maybe a reminder on WT:WikiProject Articles for creation about common mistakes? A change to the wording here is unlikely going to change that culture.

I'm open to make the reviewer more visible in the text. Do you have a wording proposal? Atm, I'm only able to come up with quite ugly long sentences. Something like "A volunteer has reviewed the draft. They determined that the references do not show that the subject qualifies for a Wikipedia article It semi-duplicates the "Title" of the decline message, which already gives the information that this is a decision by one person. Femke (talk) 20:51, 23 March 2022 (UTC)

Maybe an “Additionally, if you think this review is wrong, contact the reviewer or go to the help desk.” – AssumeGoodWraith (talk | contribs) 23:20, 23 March 2022 (UTC)

@AssumeGoodWraith, I like that suggestion. If the AFCH script could automagically put the correct username in the link, then that would be terrific. WhatamIdoing (talk) 00:07, 25 March 2022 (UTC)

All of the pressure I've felt to be more strict has come from outside AfC (NPPs draftiying and coming to complain about my acceptance on my talk page, harsh AfDs, etc). No one's done anything wrong, in fact the criticism was often founded, but it's stressful enough to be on the receiving end of that I've been leaving some borderline accepts for another reviewer and generally tightened my criteria.

Though it should be noted that AfC as it was explained to me has as a criteria not "the draft will survive AfD", but "the draft will survive AfD on the strength of existing content", i.e. we explicitly do not do our own checks for sources or other notability criteria. That's a manpower problem, not a culture problem. Rusalkii (talk) 13:03, 24 March 2022 (UTC)

I'm a bit apprehensive about creating more work for reviewers. A large chunk of declined drafts are corporate spam, and those already take up quite a lot of reviewer time. Will they take up a disproportionate fraction of "appeals" too? If we want to tackle overly strict declines, I think a conversation needs to happen at AfC talk, not in these messages. Femke (talk) 17:24, 24 March 2022 (UTC)

@Rusalkii, I think it's a culture problem. First of all, AFD has never had a rule about "on the strength of existing content", so why would anyone impose that non-rule on AFC? WP:DEL#REASON says nothing like that, and the Deletion policy is unquestionably the one that matters at AFD. We should probably correct that AFC page.

Second, why should anyone be complaining on your talk page or posting harsh AFDs? Sure, if someone believed that the draftification of notable subjects is a way to improve visible article content (by hiding all the "bad" articles), or if they think it's a great way to extort extra edits from any interested editors, then I could see that it would be annoying to have someone disagree with them by supporting the long-standing, written policies and guidelines – but the problem is that other editor, and our culture ought to back you up for putting notable subjects into the mainspace.

Ditto for actual mistakes: All of us make mistakes, so all of us should respond with the same kindness and gentleness that we want to receive when we screw up. More relevantly than that, we have different interpretations and different knowledge. A subject that you think is "obviously" notable, because of your own outside knowledge, is one that might be WP:NEVERHEARDOFIT for me (which, you'll recall, is an invalid argument for deletion). So if I were to reject what you think is an notable subject, it would make more sense for me to at least wonder about whether you know what you're talking about, than for me to yell at you for daring to hold a different opinion. That's the culture change that I think we need: To assume that experienced editors who are following the written policies and guidelines are doing the right thing, even when the right thing means putting an "embarrassing" or "overly positive" article in the mainspace. WhatamIdoing (talk) 00:04, 25 March 2022 (UTC)

• I think it important to note that an AFC “decline” is a temporary status, pending further improvement, and resubmission. Reviewers who decline are not rejecting the submission, they are merely stating that the article is not YET ready to be moved to mainspace. Blueboar (talk) 15:30, 28 March 2022 (UTC)

Move protect user namespaces

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

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

• Wasn't this recently discussed somewhere? They will only move articles, or pages like this instead. I'd prefer they make their mess in userspace. -- zzuuzz ^(talk) 20:31, 16 March 2022 (UTC)

  Yeah, I kind of have a feeling it's something I had suggested before, but not exactly this way, or not this board, or I don't know what. I don't remember where it was or what the outcome was, but the vandalism still happens so I guess it wasn't implemented. I think it was brought up before that the vandals would just move articles instead, but I've move-protected a lot of vandalized user pages without seeing an uptick in article move vandalism to go with it. It seems to me to be more like targeted harassment than random vandalism. Ivanvector (^Talk/_Edits) 20:39, 16 March 2022 (UTC)

  Previous discussion. -- zzuuzz ^(talk) 21:15, 16 March 2022 (UTC)

• I concur strongly. I can't think of a reason not to, although I'm somewhat dim at times. ScottishFinnishRadish (talk) 20:34, 16 March 2022 (UTC)
• I can see arguments for and against. On the one hand, we usually protect pages only if they've been attacked or if vandalism would cause havoc (Main Page, Template:Infobox…) On the other hand, I can't think of a single good reason why I should be moving your user pages around. We might want to close any loophole that permitted a vandal to move an article to User:Foo/Lulz with only an admin able to move it back. Certes (talk) 20:57, 16 March 2022 (UTC)
• Would've prevented me from making a fool of myself earlier, which would've been nice. Well, at least we got T304008 out of it.
  One problem I can see with this, though, is trying to move a user's article draft out of their sandbox, either to the draft space or to article space. I know that's what the draft space is for, but I think (without hard evidence) this is still a common enough use case to be worth considering. Writ Keeper ⚇♔ 21:02, 16 March 2022 (UTC)
• The only issue I can think of would be if a user gets renamed. I don't think global renamers are pagemovers or admins by default. If we move-protect all pages in the User: and User talk: namespaces for those who are not the owner or pagemovers/admins by default then that can cause some issues if someone is being renamed. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 21:02, 16 March 2022 (UTC)

  This used to be a problem, see phab:T212082. That should be fixed now; a global rename operation should bypass all filters. Suffusion of Yellow (talk) 21:16, 16 March 2022 (UTC)

  Correct me if I'm wrong but, the proposal is to protect those namespaces except for those specific users which isn't a filter. Unless the proposal is basically proposing a new filter to be created. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 21:22, 16 March 2022 (UTC)

  But how? The only other mechanism (without a major software change) would be the WP:TITLEBLACKLIST, and that can't exempt the "owner". Suffusion of Yellow (talk) 21:26, 16 March 2022 (UTC)

  shrug I don't usually do any software related stuff so I wouldn't know. Upon writing my previous I Did think that if we were taking this literally it would require creating a separate user group for each individual user so that the protection will be applied so that only the user in their own group would be able to edit, which would be really complicated and probably take up a lot of space considering how many users there are. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 21:32, 16 March 2022 (UTC)

  There must be some sort of hook in the code, as I can edit my own /common.js but other unprivileged editors can't. (And I'm really hoping that I can't write some malware elsewhere then move it to User:Victim/common.js!) Extending it would need a software change, though. Certes (talk) 22:14, 16 March 2022 (UTC)

  Yes, the "special" rules for user JS and CSS are basically hard-coded into MediaWiki core. Suffusion of Yellow (talk) 22:16, 16 March 2022 (UTC)

  So in theory it is possible to make it so userpages can only be edited by the user and other users since something similar is done with the JS and CSS pages. I say in theory because there might be something that causes this to not be possible (ignoring all the issues this would cause with legitimate moves from out of userspace). ― Blaze Wolf^Talk_{Blaze Wolf#6545} 22:22, 16 March 2022 (UTC)

  Sure, in theory lots of things could happen - the usercss/userjs was considered important enough to update the software for every project that uses mediawiki; this possible bespoke protection system for one project may not - leaving us to possibly deal with it using the abusefilter. — xaosflux ^Talk 00:06, 18 March 2022 (UTC)

• Is the proposal to also disallow moving subpages? I can think of valid reasons for that; e.g. publishing a draft. Suffusion of Yellow (talk) 21:17, 16 March 2022 (UTC)
• One consideration with any proposal to create a protected namespace is what happens when pages are moved to that space. If moves to that space were prohibited, transferring an essay/article to user space could only be done by admins. If they were allowed, vandals could move articles to user space and only an admin could restore it. Although they might not be deal-breaking issues, the question to answer is if these and similar issues would be more or less hassle than the problem being solved by blocking moves in the user namespace. isaacl (talk) 21:43, 16 March 2022 (UTC)
• Occasionally, I move drafts written on the userpage into draftspace. ― Qwerfjkltalk 22:00, 16 March 2022 (UTC)
• Oppose, if moving from user pages is restricted, we also need to restrict moving to user pages; otherwise anyone moving an article into userspace could only be reverted by people with higher permissions (and then "userfying" would also require more permissions). We should just revert, block, ignore the vandals, not lock everything down to prevent all vandalism, as that also has unintended consequences for non-vandals. —Kusma (talk) 22:13, 16 March 2022 (UTC)

  In particular, a user who accidentally moves a page into a different user's userspace (which can easily happen) should not be prevented from self-reverting. —Kusma (talk) 22:29, 16 March 2022 (UTC)

• Ummmmm..... @Ivanvector: thanks for thinking of things, when you say this is a common form of schoolyard vandalism, would you please quantify that some? I queried the last 5000 moves, going back about 1 year; filtering out only ones where the source was User:* and excluding account renames and a single odd batch by one admin, this leaves only 296 total moves. They can be seen here: Special:PermaLink/1077548981. I'm not seeing rampant vandalism that we should invest new technical controls in. Please let me know if my data looks wrong. — xaosflux ^Talk 22:17, 16 March 2022 (UTC)

  If I can provide a relevant example of the day, it's Minwu. You can add Docria1 for context. The discussion I linked above was based on a few similar examples, and you see it every now and then. I would note we have 294 (hist · log), which might appeal to some as an approach to the issue, although protection of targeted pages would work as well. -- zzuuzz ^(talk) 22:40, 16 March 2022 (UTC)

  Thank you, correction on my stats up there, those certainly don't go back a year that is "of the last 5000 moves", going back about 5 days. — xaosflux ^Talk 22:44, 16 March 2022 (UTC)

  (I didn't catch User_talk: either). Though, @zzuuzz Docria1's page moves were of an article, so aren't really in scope here? — xaosflux ^Talk 22:46, 16 March 2022 (UTC)

  They're the same vandal and the same problem, though as you say the namespace is different. I'd suggest this places them entirely within scope of this discussion (at least from my point of view). -- zzuuzz ^(talk) 22:50, 16 March 2022 (UTC)

  Well, a vandal moving articles is a different situation from ones that only move userpages - if this problem is about restricting all moves its a much bigger scope. — xaosflux ^Talk 23:17, 16 March 2022 (UTC)

  I think my point would be, as I said above, that if they couldn't move a user page, then they'll just move an article instead. -- zzuuzz ^(talk) 23:25, 16 March 2022 (UTC)

• Occasionally, I move drafts written on the userpage into draftspace. ― Qwerfjkltalk 07:13, 17 March 2022 (UTC)

  @Qwerfjkl: You wrote that exact comment at 22:00, 16 March 2022 (UTC). --Redrose64 🌹 (talk) 19:28, 17 March 2022 (UTC)

  @Redrose64: Oops. I think CD saved the edit, but didn't update [whatever else it updates], so I just posted the comment again when I looked at this page. ― Qwerfjkltalk 20:26, 17 March 2022 (UTC)

• There's quite a lot of moving userspace "quasi-drafts" to draftspace that is done atm by non admins/PMs, especially as part of the AfC workflow. Nosebagbear (talk) 10:04, 17 March 2022 (UTC)

  Shouldn’t the moving of a “quasi-draft” from userspace into draftspace be done by the user who created it in their userspace? I know I would object if something I had been working on in my userspace were moved by another editor without my ok. Blueboar (talk) 11:37, 17 March 2022 (UTC)

  I agree with Blueboar. There are only three reasons I can think of for ever moving any page out of userspace without the consent of that editor:

  1. The page was improperly moved there (e.g. page move vandalism)
  2. The page was accidentally moved there (e.g. typo or misclick when moving the page)
  3. There is a consensus in a RM or a similar discussion to move the page. Thryduulf (talk) 12:12, 17 March 2022 (UTC)

  There are a lot of drafts that are created as people's userpages, especially by complete newcomers. It is absolutely fine to move such pages, either to article or draft space as appropriate (often, the user can't even do it themselves, as they are not autoconfirmed). Locking this down prevents very little vandalism (and probably just displaces it to an area where the vandal will do more harm) while impacting legitimate workflows. —Kusma (talk) 12:53, 17 March 2022 (UTC)

  Why is it fine to move a draft from userspace to elsewhere without the user's consent? Note there is no requirement to use draftspace for drafts, regardless of how new an editor is. Moving a draft from user:Foo to user:Foo/draft is not relevant here (as that's moving a page within someone's userspace no out of it), submitting a draft for publication (formally or informally) is consent for the page to be moved to article space and obviously requesting a page be moved (for any or no reason) is consent for the page to be moved. I agree that the proposed automatic protection would cause more harm than good, my comments are trying to ascertain why one of the things it would prevent is regarded as legitimate. Thryduulf (talk) 13:05, 17 March 2022 (UTC)

  "Drafts" aren't the only thing that could be in a userspace; page move vandalism is an easy thing to say could be in userspace. I don't think a situation where anyone can move a page TO their userspace, but only a small group of users can revert that is a great idea. — xaosflux ^Talk 13:28, 17 March 2022 (UTC)

  It would certainly give a huge advantage to one side in, say, move wars about whether some essay should be in user space or in Wikipedia space. —Kusma (talk) 13:44, 17 March 2022 (UTC)

  @Xaosflux indeed, I'm not in favour of this proposal but I'm still waiting for someone to explain why moving a page outside of userspace without that user's consent is appropriate outside of the three situations above (move warring and reverting an undiscussed move would come under point 1). Thryduulf (talk) 17:13, 17 March 2022 (UTC)

  @Thryduulf I can think of numerous situations that fall under "user has left the project". How about a case like: User:User/Sandbox/DraftArticle - where the draft article was collaboratively worked on and the other authors wants to move it to an article? — xaosflux ^Talk 18:07, 17 March 2022 (UTC)

  When the user submits it as a draft using {{subst:submit}}? ― Qwerfjkltalk 18:14, 17 March 2022 (UTC)

  @Qwerfjkl submitting a draft is, as I said above, is consent for the page to be moved to article space. I can't think of a reason why it would need to be moved to a different namespace without their consent?

  @Xaosflux hmm, if that happens often enough to be more than an occasional thing (c.f. WP:IARUNCOMMON) then a fourth criteria of "user is clearly no-longer around" would cover it. If a draft is being collaboratively worked on then it's likely that there will be consensus among those working on it to move it to article space/submit it when ready. If the owner (for want of a better word) is one of them then they will be giving their consent to moving as part of this, if they aren't part of that discussion then point 3 would likely apply. Thryduulf (talk) 18:25, 17 March 2022 (UTC)

  Category:Pending AfC submissions in userspace mentions moving userspace drafts to draftspace. ― Qwerfjkltalk 18:32, 17 March 2022 (UTC)

  @Qwerfjkl any idea why that instruction exists? It seems completely contrary to the use of draftspace being optional. I can understand moving User:Foo/Sandbox to User:Foo/Subject, especially if the draft is accepted, but there seems to be no reason or obvious benefit to moving to draftspace? Thryduulf (talk) 00:04, 18 March 2022 (UTC)

  @Thryduulf digging through the template codes, the Category:Pending AfC submissions in userspace is populated only when the draft in userspace is submitted for review. – robertsky (talk) 00:33, 18 March 2022 (UTC)

  That doesn't explain why the instruction to move the page though? I can't think of any reason why the content of a draft would be different just by moving namespace? Thryduulf (talk) 00:36, 18 March 2022 (UTC)

  Well, personally, I have no qualms editing other people's drafts in draftspace to improve the drafts (on top of processing the submission), but I do have editing in other's userspace without first asking for permission. I guess it's all about perceived/implicit permission to edit (in draftspace) vs asking for permission to edit (in userspace. WP:NOBAN: In general, one should avoid substantially editing another's user and user talk pages, except when it is likely edits are expected and/or will be helpful. If unsure, ask. If an editor asks you not to edit their user pages, such requests should, within reason, be respected. （emphasis mine). But not all editors may follow up on their talk page, for one reason or another. So, do we just let the draft in userspace languish, or have the drafts be improved in the draftspace after submission? – robertsky (talk) 00:55, 18 March 2022 (UTC)

  People don't WP:OWN their userspace. You should be allowed to WP:BOLDly update and then submit abandoned drafts by deceased editors. Most of the times, it is not the polite thing to do to mess with other people's userspace, but that doesn't mean outlawing it improves things. —Kusma (talk) 13:42, 17 March 2022 (UTC)

  People do sort-of own their userspace, to an extent (although certainly not completely). Abandoned drafts by deceased or long-departed editors would be exactly the sort of thing WP:IAR is intended for (once again I'm not supporting to allow only admins and page movers). In other situations get consent or consensus first. Thryduulf (talk) 17:17, 17 March 2022 (UTC)

• Weak oppose. I see the advantages but there are legitimate moves such as User:Foo/Article → Draft:Article, it can make other bad moves hard to undo, and it may drive vandals to make more damaging and less visible moves. Instead, would anyone monitor a regular report of moves of other users' pages? It could exclude legitimate-looking cases either by nature (target in Draft:) or by user (don't report admins, page movers, etc.). Certes (talk) 11:59, 17 March 2022 (UTC)
• 'Oppose, it is a default part of the AfC workflow to move all submitted drafts out of userspace into draftspace. If the draft was submitted from, say, the sandbox, it's impossible for reviewers scanning AfC submissions to tell what it's about; having it at Draft:Title is much clearer. I've also moved drafts from user and talk pages. Rusalkii (talk) 17:06, 17 March 2022 (UTC)
  • Why can it not be moved to User:Foo/Title? Thryduulf (talk) 17:20, 17 March 2022 (UTC)

    You can't move it to User:Foo/Title if it's move protected. If you somehow limited this move protection to allow moves within userspace, what do you do when you've approved the draft and need to move it to mainspace? --Ahecht (TALK
    PAGE) 17:39, 17 March 2022 (UTC)

    Those are reasons why I'm opposing the move protection. Thryduulf (talk) 18:26, 17 March 2022 (UTC)

• Oppose. Nobody should be routinely moving pages out of userspace without consent of that user, but there are exceptions (improper moves to userspace, accidental moves to userspace, and consensus) that happen often enough to make this problematic. It would also make moves more difficult when the editor does consent (e.g. submitting a draft). Thryduulf (talk) 17:20, 17 March 2022 (UTC)

  I might support prohibiting non-autoconfirmed editors from moving pages to or from other editors' userspace (unless they were the ones to move it there to cater for accidental moves), but I don't know if this is something that is possible (my uninformed guess is that it isn't without some serious software work). Thryduulf (talk) 17:23, 17 March 2022 (UTC)

  Errr... non-autoconfirmed editors can't move pages, regardless of namespace. --Redrose64 🌹 (talk) 21:56, 17 March 2022 (UTC)

  I completely forgot about that. Doh! Thryduulf (talk) 00:00, 18 March 2022 (UTC)

  I generally agree with that, and perhaps the Wikipedia:User pages guideline can be improved. — xaosflux ^Talk 18:10, 17 March 2022 (UTC)

• Withdrawn - I think everyone's made good points about why this is either not technically feasible or just not a good idea in general. I'm not closing because some of you are having interesting side discussions and not everything needs to be formally closed. Just on a point that was brought up about the "common-ness" of this vandalism: I don't think we should expect to see patterns of vandalism when we look at all contributions over a time period, we already know that vandalism is a tiny proportion of all editing, and trying to isolate one particular form of vandalism out of that tiny proportion is like finding a needle in a much larger stack of needles. I guess I meant "common" in the sense that it's common among the various LTAs who are known to target specific users they perceive to have done them wrong. I don't think it's a very common form of random vandalism. Everyone who said so is probably right that if we suppress this form of harassment they'll just find another way that might be even more disruptive, and just protecting the pages of users who are known to be targets is probably just as good as making it a software restriction. Thanks for the comments. Ivanvector (^Talk/_Edits) 18:35, 17 March 2022 (UTC)

  @Ivanvector - there could still be some room for improvements in things, namely if there is something more targeted for edit filters (drop examples at WP:EF/R and someone can evaluate the use cases), and a tangent this discussion went in was about what is generally inappropriate, but not outright vandalism, regarding moving of user (sub)pages -- WP:USERPAGE guideline updates could be in order. — xaosflux ^Talk 18:49, 17 March 2022 (UTC)

• Comment - I agree that move protection would be overkill (for this problem) but I definitely believe that the user should receive a notification when someone moves a page from their user space. When it happened to me, I was surprised that I wasn't notified; T296955 was initiated to fix this, but it may be quite a while before anything happens. Best regards.--John Cline (talk) 21:04, 21 March 2022 (UTC)

  I hope that almost all user-space pages are on the user's watchlist, which would be sufficient, except that many editors with user pages are inactive. Certes (talk) 21:31, 21 March 2022 (UTC)

  If I am active when someone happens to edit or move a subpage in my user space, I am pretty sure that I would notice the activity. If I am not active, I am equally as sure that I probably will not. From my perspective, the watchlist is insufficient; I maintain my belief that a notification should be sent. Sincerely.--John Cline (talk) 22:18, 21 March 2022 (UTC)

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

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

---

The ratification voting process for the revised enforcement guidelines of the Universal Code of Conduct will conclude on 21 March 2022 at 23:59:59 UTC.

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

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

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

A configuration problem which broke some voting links has been fixed. Anyone who tried and failed to vote about 12 hours ago should try again now. Certes (talk) 12:33, 21 March 2022 (UTC)

Thanks Certes; about your other query: the poll will close at 23:59:59 (UTC) today, which is I guess technically "until" the 22. This confusion was discussed at watchlist messages with xaosflux. Perhaps the time should be added? Xeno (WMF) (talk) 12:49, 21 March 2022 (UTC)

The 'landing page' for our local WLN is meta:Universal Code of Conduct/Enforcement guidelines/Voting, neither it, nor the central notice have anything about time of day on it; 'until' should suffice on this project. If you really want to globally push that time of day information there are many other places to start. — xaosflux ^Talk 13:05, 21 March 2022 (UTC)

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

Optional thanks message, as gadget

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

---

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

@Theleekycauldron this is not technically possible, the Thanks extension does not support messaging at all - so a gadget would not be able to be used to help send this. You could follow up at mw:Extension talk:Thanks but I doubt this will take off the way you envision: Where would this message go? How would disruptive messages be handled? It could be possible to make a gadget that takes an input, and then posts it to a user's talk page - which also would need to be invented. I suggest you move this to WP:VPI as there is no actionable proposal here. — xaosflux ^Talk 14:08, 22 March 2022 (UTC)

all righty- i guess not, then. cheers! theleekycauldron (talk • contribs) (she/they) 22:02, 22 March 2022 (UTC)

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

Wikipedia:Wikipedia is a tertiary source

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

It doesn't seem the page has any original information to justify active status. 74.64.150.19 (talk) 11:26, 22 March 2022 (UTC)

Seems fine where it is. Labeled a failed proposal. It can not be labeled information or supplemental under those conditions.Slywriter (talk) 11:35, 22 March 2022 (UTC)

On the rare occasions when Wikipedia legitimately cites itself as a source then it's primary rather than tertiary, so the page must be about reading Wikipedia and citing it elsewhere rather than editing. Policies, guidelines, information and supplementary pages are generally aimed at editors, so it's none of those. It may belong with other help on how to read Wikipedia. There's not much of that, as reading is generally a simple and obvious process, but examples include the intricacies of search syntax. Certes (talk) 11:50, 22 March 2022 (UTC)

Leave it exactly as it is. It is listed as a failed proposal. That looks good to me. --Jayron32 11:56, 22 March 2022 (UTC)

See also Wikipedia:Not every page needs a tag (which, despite the short page being entirely about the non-importance of tagging 'backstage' pages, sometimes grows a tag at the top of it).

I'm glad that WP:WITS failed, because the "one step removed" definition of secondary sources has created a lot of confusion. Editors interpreted "one step removed" as meaning that secondary and independent were the same ideas – "one step removed" being (mis)understood as the source being an independent journalist or other author at arm's length from the subject, rather than "one step removed" (correctly) meaning that pre-existing sources were being transformed into a new work of analysis, commentary, etc. Wikipedia:Independent does not mean secondary. WhatamIdoing (talk) 20:00, 22 March 2022 (UTC)

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

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

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

This might be feasible, but I don't know which team would work on it. Let me ask around for a few days... Whatamidoing (WMF) (talk) 00:12, 25 March 2022 (UTC)

Dissociate Fiction from Non-Fiction on the Wikipedia platform

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

---

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

• I propose that folks who make proposals here sign their own posts first. ;-) BusterD (talk) 09:54, 23 March 2022 (UTC)
• Is it not possible to write objectively about fiction? Phil Bridger (talk) 10:48, 23 March 2022 (UTC)
• I approve, but only if we start with the Bible and Hamlet. ;) —TheDJ (talk • contribs) 11:00, 23 March 2022 (UTC)
• Don't see why this is needed. Fictional articles should be written in a way that clearly portrays that they're fictional, if not then they should be tagged for cleanup. Joseph2302 (talk) 11:47, 23 March 2022 (UTC)

Please, don't feed the trolls
The following discussion has been closed. Please do not modify it.
Please include articles that are poorly referenced, unreferenced, or with unverified references. They are also fiction. 68.173.76.118 (talk) 11:54, 23 March 2022 (UTC) No they aren't- they're articles on factual things that need improving.... Joseph2302 (talk) 11:58, 23 March 2022 (UTC) And how is one to know these things are factual? That's supposition. The fact is, absent proof they're fiction. 68.173.76.118 (talk) 12:01, 23 March 2022 (UTC) It is trivially easy for an article to be both poorly referenced and proven factual. For example an article that is supported only by non-independent sources and makes no un-attributed subjective claims. We can't say it's notable, but we can certainly say it's not fiction. Thryduulf (talk) 14:17, 23 March 2022 (UTC) ??? an article that is supported only by non-independent sources and makes no un-attributed subjective claims = article that has no independent sources and makes subjective claims (attributed to these non-independent sources) = that is somebody's fictional (opinion/imagination/etc-based) take. Non-fact (ie POV) dressed up in "references". 65.88.88.93 (talk) 16:01, 23 March 2022 (UTC) That doesn't follow at all. Non-independent sources can be used to verify objective statements and to verify attribution of claims. For example, say the article is about XYZ Ltd and the sources are (1) the company website, (2) a company press release and (3) an advert for the company in a major newspaper, the article also contains three photographs showing (a) the company headquarters, (b) one of their products ("XYZ Super") with branded packaging, and (c) a celebrity (Fred Bloggs) using one of the products. The claims in the article are (i) that there is a company called XYZ Ltd, (ii) with a CEO called Jane Doe, (iii) that is headquarted in Anytown, (iv) that makes a product called "XYZ Super", (v) that is advertised as being "The greenest on the market", and (vi) that it is used by celebrities including Fred Bloggs. Claim i is verified by sources 1-3 and photos a-c, claim ii is verified by 1 and 2, claim iii is verified by 1 and a, claim iv by 1-3, b and c, claim v by 3, and claim vi by c. i.e. everything is factual. Notability is not demonstrated, but that's entirely different. "Non-fact" and "POV" are not synonyms, non-independent is not synonymous with either "non-fact" or "POV". "Opinion" and "fiction" are not synonyms either. Thryduulf (talk) 18:51, 23 March 2022 (UTC) What you demonstrated in the first paragraph is an example of using primary sources to establish certain facts about the sources themselves, an appropriate and narrow application. This is not contested, and it was not part of the argument made in this section. The problem is parts of the second paragraph. Facts are not points of view. They are whole, not just the aspect(s) one knows about or the aspect(s) that one prefers. A fact implies the full view, not one's limited perspective. There is no such thing as "almost factual". That is a an easy way out, an attempt at making something partial and limited equal to the whole. Maybe this kind of mediocrity is accepted because the alternative is really hard work. But unfortunately, in any mix of fact and fiction/opinion/theory/POV the latter wins out. The mix produces yet more non-fact. I leave it to your judgement to decide whether any non-independent position or source can ever substitute or even relate to facts which are by definition independent of perspective. And if they are not facts, they are opinions, POVs and non-facts. This shouldn't be so hard. After all there are very few facts compared to the hyperinflation of opinions. But the overabundance is not the reason opinions are worthless. They are inherently worthless, because they have a limited perspective. That is a useful fact to know. You can proceed more realistically from there, perhaps even produce a better encyclopedia. 65.88.88.57 (talk) 19:53, 23 March 2022 (UTC) Most of that is meaningless. There are no points of view in the sample I wrote, other than those which are clearly attributed (i.e. it is factual that the company claims this, it is not relevant whether the claim is true). An article which relies solely on primary and non-independent sources is poorly sourced. My point is to demonstrate that not all poorly sourced articles are fiction (which is what you were claiming). You also claimed that unsourced articles are fiction - it is entirely possible to write an entirely unsourced article that is self-evidentially factual not fictional - for example an article listing the conversions of 1 metre into various other units of length. Thryduulf (talk) 21:55, 23 March 2022 (UTC) As pointed out, the sample you wrote which utilized primary sources, is not contested. What is contested is eg an article supposedly listing length conversions without any sources to prove that the conversions are in fact correct. An article like that is a work of fiction as far as anyone can tell. 98.7.206.190 (talk) 22:04, 23 March 2022 (UTC) You are still not getting that "Unreferenced" and "Fiction" are not synonyms. If I could change fiction to fact just by adding a citation, I could therefore change fact to fiction just by removing a citation. The world doesn't work like that. Thryduulf (talk) 22:07, 23 March 2022 (UTC) We are talking about Wikipedia, a platform of anonymous contributors with unknown credentials and expertise, whose audience is the general reader, another quantity of unknown credentials and expertise, individually and in aggregate. The prudent and rational approach is to assume/presume nothing else about both groups. In such situations, unverified claims are no different from fiction. Without a proper reference, there is no prior or implied guarantee that they are factual. A reader may justifiably think they are just things somebody came up with, and very easily posted in some online platform. And let the buyer beware. 68.173.76.118 (talk) 00:05, 24 March 2022 (UTC) I don't think this is relevant to the proposal, which was clearly concerned with fiction as an art form, rather than anything to do with whether articles have independent reliable sources. Phil Bridger (talk) 19:31, 23 March 2022 (UTC) The point was that articles that are not verified as having independent reliable references are works of "art". Fiction, for all a reader knows. Maybe they belong in a fiction-publishing platform instead. This is said in all seriousness. The harm that half-truths and opinions can do when presented as facts is great. The proper usage of primary sources was noted above, and is not part of this. 65.88.88.57 (talk) 20:01, 23 March 2022 (UTC)

• Reject - there is no purpose served by this suggestion. The fictions which entertain us are part of our big, complex global culture, as much as our history, politics and religious/philosophical systems. As has already been pointed out, any article about a fiction which does not make it clear from the first sentence that this is fiction, is a junk article. --Orange Mike | Talk 13:24, 23 March 2022 (UTC)
• Reject While I agree that it would be nice to be able to tune search so that whole genres could be omitted, and the people looking for Mercury from respectiely an astronomy, chemistry, religion and space flight perspective could more easily find what they want; I don't see further subdivision of Wikipedia as a good way to do this. Our strength is in being a general interest encyclopaedia, and that means covering the topics that don't interest each of us individually as well as the ones that do. This particular proposal also suffers from boundary issues, many religions might be glad to categorise other religions as fictional, but incensed if that was done to them. The same sort of thing would apply if we tried to spin off sport as something separate, just imagine the arguments as to whether darts, golf, chess, professional wrestling or even punt jousting were real sports. ϢereSpielChequers 11:09, 24 March 2022 (UTC)
• Question: How often do readers end up on an article about a work of fiction when they are searching for something non-fictional? Some examples might help us determine whether this is a serious issue (or not). Blueboar (talk) 11:35, 24 March 2022 (UTC)
• Agree with those above suggesting a can of worms when it comes to mythology and religion and folkloric history. Hyperbolick (talk) 12:45, 24 March 2022 (UTC)
• Reject - fiction exists, it is a "real world" thing. We should, and do, strive to present any work of fiction from a real-world perspective, with limited and (hopefully) clearly demarcated "in universe" material. Also, to take the OP's idea to the extreme, if we do not cover fiction (ie novels, films, tv shows, comic books, etc), then the articles about the people who create these fictions and the companies that distribute them and the fan communities that celebrate them, etc. would be pretty scant at best. --User:Khajidha (talk) (contributions) 14:24, 24 March 2022 (UTC)

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

Logo for Nogai Wikipedia

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

---

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

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

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

This probably belongs somewhere on commons or meta... Sungodtemple (talk) 17:07, 23 March 2022 (UTC)

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

Proposal for Template:Template help

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

They can ask at the technical village pump. Graham87 09:09, 27 March 2022 (UTC)

I believe it's better to separate mere requests for help from technical village pump, the way we separate requests for admin help from Administrator's noticeboard. Thoughts? ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 09:27, 27 March 2022 (UTC)

An interesting idea. It would neatly identify and collate the request, and ping the watchlists of those who maintain that template. On the other hand, it would take the request off VPT which is watched by many people who could help and might not monitor the category. Certes (talk) 11:46, 27 March 2022 (UTC)

This is not me opposed to the idea, but what's wrong with using {{help me}} in these situations? Primefac (talk) 12:21, 27 March 2022 (UTC)

Great idea. Articles can be edited by almost anyone, whereas editing most templates requires skill in coding. I used to use {{edit request}} on templates (as instructed in the header of protected templates) and was often rejected as 1. establish consensus (even for non-controversial changes) or 2. failure to say "change x to y" (which requires specialized coding skill). I've since learned to look though the history for an TE that has recently worked on the template or ping someone I know is likely/willing to make the change. It would never ask for this kind of help at VPT, and {{help me}} is similarly general. I'm sure a specific cat for template help would be monitored by prolific template editors with the right skills and interests. MB 17:03, 27 March 2022 (UTC)

• Instead of a new template it would be good to have a mechanism to alert users that questions can be asked at WT:WPT (WikiProject Templates). That way, multiple people will see the question and be able to respond. Johnuniq (talk) 22:13, 27 March 2022 (UTC)

  I think that's a better option; I have too many cats to keep track of as it is, and honestly the only reason I'm able to respond to {{help me}} requests is because there's a bot in the -helpers IRC channel that pings whenever someone's used it. Primefac (talk) 09:37, 28 March 2022 (UTC)

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

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

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

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

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

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

Sounds to me like it would give undesirable horizontal scrolling for people on mobile devices when links are long. Anomie⚔ 21:36, 27 March 2022 (UTC)

That's the first thing I thought as well. ScottishFinnishRadish (talk) 21:58, 27 March 2022 (UTC)

I presume that one of the reasons for this testing is to show whether that issue commonly arises. Phil Bridger (talk) 08:12, 28 March 2022 (UTC)

Probably the better final implementation (I make no comment on whether preventing nowrapping in hatnotes is desirable) would be to use nowraplinks already defined in Common.css. Mobile.css is more generous with how it treats that class which would take care of the mobile concern. Izno (talk) 23:27, 28 March 2022 (UTC)

@Anomie and ScottishFinnishRadish:, The first thing I though of, too; but the mobile issue turns out not to be a problem; please see the discussion. @Phil Bridger:, yes, exactly. @Izno:, yes, it is; this is only the test phase; please see the linked discussion. Please do have a look and sign up; it would really help. Thanks, Mathglot (talk) 09:46, 29 March 2022 (UTC)

I see nothing in the linked discussion that indicates it's not a problem. Your claim near the start that it's "already the default behavior on mobile" is confused by the fact that your example is in a fixed-width box. Anomie⚔ 11:22, 29 March 2022 (UTC)

Android related question for developers

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

Science Photo Competition 2022 Russia targeting CentralNotice banner

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