Wikipedia

Wikipedia:Village pump (proposals)/Archive 176

< Wikipedia:Village pump (proposals)
Latest comment: 3 years ago by Sdkb in topic Cite book display: contributors/contribution should FOLLOW author/title, not precede them
Village pump (proposals) archive  

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

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

English Wikipedia's 20th anniversary

Latest comment: 3 years ago257 comments101 people in discussion

Hello, January 15 is in two days. I see that Wikipedia:20 just has a redirect to Meta. Are there any plans to celebrate it here? --NaBUru38 (talk) 20:36, 13 January 2021 (UTC)

There was some talk on changing the logo for the day but they never gained much traction and ultimately fell through. Besides that, not much chatter has been going on about it on-wiki. — Wug·a·po·des​ 21:43, 13 January 2021 (UTC)
We should at least do something... ~ HAL333 22:20, 13 January 2021 (UTC)
Well then, let's hope it snows. — Wug·a·po·des​ 22:40, 13 January 2021 (UTC)
  • Thanks Wugapodes for starting the RfC below. I wonder, will people clicking the logo on that date expect to be taken somewhere other than the main page? If so, do we have a decent target? WP:About certainly isn't ready, alas, but it'd be nice if we could use some of the buzz around this to direct readers toward trying out editing. Another thought is having a banner notice, or tying in the billionth edit. We're on a short timeline, though. {{u|Sdkb}} talk 23:32, 13 January 2021 (UTC)
Maybe History of Wikipedia? I don't know if it is written well enough to be "featured"... ~ HAL333 23:42, 13 January 2021 (UTC)
Given that it's had a "needs update" banner at the top since 2018, prob. not. Maybe we could have it go to the Main page as normal, but put a variant of one of the banners like File:Wikipedia 20 cover confetti blue.png on the Main page. But that'd still leave the question of where, if anywhere, to point people who click on the banner. Maybe I'm just biased in favor of my own work, but I can't really think of any intro-esque project page other than Help:Introduction to Wikipedia that'd really be ready. {{u|Sdkb}} talk 00:31, 14 January 2021 (UTC)
That would do too. ~ HAL333 01:12, 14 January 2021 (UTC)
@Sdkb: I like your suggestion of linking to a version of the main page with an anniversary banner, but would this be too technical to pull off in time? I'm not convinced about Help:Introduction to Wikipedia, as it's really for people who are already interested in contributing. Just toying with an idea here, but I've always been a fan of the 'Impact of Wikipedia' video, which provides an accessible, inspiring overview, if it could be somehow linked to. If none of these suggestions are practical then I think the normal main page link is best. Jr8825 • Talk 12:02, 14 January 2021 (UTC)
Jr8825, a main page banner wouldn't be that hard technically; I think the harder issue would be just garnering consensus. I like that video as well, and I'd be fine linking to it from the banner. Ideally we'd want it to autoplay, but alas that might not be possible. Give me a few minutes to experiment... {{u|Sdkb}} talk 13:17, 14 January 2021 (UTC)
@Jr8825: Does User:Sdkb/sandbox/Wikipedia:20th anniversary look something like what you envision? (It'd need attention from a CSS expert to get mobile display fully working.) To spell it out, we'd put a banner on the main page something like this, and clicking on it would lead to the page. {{u|Sdkb}} talk 14:29, 14 January 2021 (UTC)
Since we're on such a short timeframe, I went ahead and made a section below. We'll see what folks think; it'll be nice if it succeeds, and worst case scenario we just get stuck with the normal main page. {{u|Sdkb}} talk 15:25, 14 January 2021 (UTC)

Well, it seems as though there's quite a lot of active participation down below. Whatever the logo chosen, I believe it should stay for more than just one day - keep it for a week. Wilhelm Tell DCCXLVI converse | fings wot i hav dun 02:03, 14 January 2021 (UTC)

I would support that. I remember the 6 million articles banner logo lingering for a week or so. ~ HAL333 02:20, 14 January 2021 (UTC)
  • @Sdkb: The WMF has a nice site set up at [1] I'm spread incredibly thin at the moment, but you might want to check it out and see if that's a worthwhile target for the banner. — Wug·a·po·des​ 23:13, 14 January 2021 (UTC)
    Wugapodes, oh wow, I feel silly for assuming that meta:Wikipedia 20 was all there was and not thinking to check the foundation site. That's much more professional than anything we could create (my only quibble being that, alas as expected, it's more focused on getting you to donate than to edit, with the only path toward the latter being a tiny link to the Teahouse). The discussion below is unfortunately running into some disagreement about what the banner should look like, which at this late hour is probably going to result in there being nothing at all, but if we somehow find a way to get past that, pointing to the WMF page seems the way to go. {{u|Sdkb}} talk 23:37, 14 January 2021 (UTC)
    I'm trying to obtain the new video so we can switch to using that at WP:20th, but the WMF extremely frustratingly doesn't appear to have put it on Commons yet. {{u|Sdkb}} talk 02:04, 15 January 2021 (UTC)

Proposal to change logo for 20th anniversary

OPTION D
The result of this discussion is to change Wikipedia's logo to Option D in celebration of this project's 20th anniversary.
It is rather unfortunate that this was proposed so close to the January 15 deadline. However, despite the short time frame, there is a clear consensus in favor of changing the logo to something. (Only two editors expressed any opposition to this idea.)

As far as which logo to use, I'm afraid the community is split almost 50-50 between Option A and Option D. Because this is almost entirely based on personal preference, and this isn't really an important policy discussion, I think the fairest and most efficient method of deciding this is to simply count votes.

Details on the numbers

I started by tallying everyone's first choice votes:

  • Option A: 23 votes
  • Option B: 0 votes
  • Option C: 5 votes
  • Option D: 25 votes
  • Equal preference for A and D: 2 votes
  • Supported but expressed no preference: 5 votes
  • Oppose: 2 votes

I then eliminated all options except Option A and Option D, and I transferred the votes for the eliminated choices to those editors' second choice votes (if the editor did not indicate a second choice, then I didn't count their vote at this stage). This led to the following final tally:

  • Option A: 26 votes
  • Option D: 27 votes
Because of this, in my view, Option D is the winner. There was also some talk of adding also the fact that we just reached 1 billion edits to the logo. Reading through the discussion, there doesn't seem to be any direct opposition to the idea, although most participants were silent on the question. Accordingly, I would say feel free to include that in the logo as a matter of discretion. Mz7 (talk) 22:22, 14 January 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.

Tracked in Phabricator
Task T272094

Should we temporarily change our logo in celebration of Wikipedia's 20th anniversary? — Wug·a·po·des​ 22:40, 13 January 2021 (UTC)

RfC Format

Because of the short time frame, this RfC will only run for 24 hours. To ensure adequate participation in the reduced time frame, notices have been left at the administrators' noticeboard, the centralized discussion notice, and the village pumps.

The original RfC proposed File:WP20 EnWiki20 SimplifiedLogo.svg. Due to editor interest, other options have been added below and are labeled by letters. Please rank your preferences from most to least, and do not list options which you oppose.

Proposed images
 
A Minimal changes
 
B In the style of the WMF campaign
 
C Inspired by the Wikipedia 10 campaign
 
D First iteration in the style of the WMF campaign
Implementation

Details can be found at mw:Manual:FAQ#How_do_I_change_the_logo?. Ideally a server admin can update the server configuration, but the change can also be achieved through edits to MediaWiki:Common.css

Survey
Logo preference is Option A followed by option D. The logo should be changed for the anniversary. --Enos733 (talk) 17:58, 14 January 2021 (UTC)
 
Option D on Vector
Could someone with some photoshop skills modify Option D - the clear frontrunner - so that it reads that beneath the artwork? ~ HAL333
Here it is for Option A, though I think the WIKIPEDIA portion could be moved up a tad. Ovinus (talk) 02:35, 14 January 2021 (UTC)
I'm away from inkscape at the moment, but if we're going to have both 20 years and 1 billion edits, I would suggest they go under the Wikipedia textmark instead of over. Essentially, replaing "The Free Encyclopedia" part with something like "Wikipedia\n20 years and 1 billion edits". Another option is to keep "20 years of" above the mark and have "Over 1,000,000,000 edits" below in small caps. — Wug·a·po·des​ 02:46, 14 January 2021 (UTC)
Good idea! I've put something similar on the right, though I admit I have no background in graphic design so the spacing may not be optimal. Maybe someone can make one using the "The Free Encyclopedia" font. Ovinus (talk) 03:02, 14 January 2021 (UTC)
 
Wugapodes's suggestion, roughly
Having the text above "Wikipedia" looks much better imo. ~ HAL333 03:18, 14 January 2021 (UTC)
A bit busy at the moment, so maybe someone else can create the analogous things for other options/Wugapodes's second idea. Ovinus (talk) 04:09, 14 January 2021 (UTC)
I mocked up the text mark. It's at right or here. This can just be dropped into whatever logo gets chosen except C but that one's a long shot anyway. — Wug·a·po·des​ 04:23, 14 January 2021 (UTC)
 
Text mark to celebrate both Wikipedia 20 and our billionth edit
  • Support A or C, preferring A. The B option has a bizarre number "2" that looks like a 5 that fell over. Both the B and D options do not match any of the look of Wikipedia or the other Wikimedia projects, so unless there is a complete rebrand everywhere, they are too strange. – Jonesey95 (talk) 01:13, 14 January 2021 (UTC)
  • D > C > A > B > nothing. – Teratix ₵ 01:20, 14 January 2021 (UTC)
  • D, C: Currently support D, with C coming a close second. C has the best message to deliver, and it looks really classy, but it's too solemn - maybe have some 50% opacity glyphs, or splashes of colour, on the black background to make it look less like a banner for a memorial service for a recently deceased person. Wilhelm Tell DCCXLVI converse | fings wot i hav dun 01:32, 14 January 2021 (UTC)
Comment: As Ovinus suggested, we have to mention the thing about the billion edits. How can we not? It's a milestone as great as any other, and the billionth edit itself was by Ser Amantio di Nicolao, rather than just some vandal... Wilhelm Tell DCCXLVI converse | fings wot i hav dun 02:12, 14 January 2021 (UTC)
  • Support A or D. My only strong opposition is for option C, which is too big and might be disruptive. If we can't all agree, I suggest just going for A because it's so minimal many won't even notice. 20 years is a long time... I feel like we have to advertise this milestone in some way! — MusikAnimal talk 01:56, 14 January 2021 (UTC)
  • Support A'. Yes, 20 years is a benchmark that should be acknowledged, but I do not think that a dramatic celebratory change is appropriate at this moment in world history. Cullen328 Let's discuss it 02:30, 14 January 2021 (UTC)
Celebration is fun, and the whole world's beginning to look brighter every day. Vaccines are out, and economies are slowly beginning to pick up pace again. Twenty years in pursuit of excellence and a billion edits definitely call for celebration. Wilhelm Tell DCCXLVI converse | fings wot i hav dun 05:01, 14 January 2021 (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.

Main page banner

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.

There is some discussion above about having a banner on the main page leading to a page with some additional information and encouragement to try editing. I've put together a rough mockup of what that could look like. It needs some technical attention to get the width working properly, so apologies for not having something more refined, but I want to put it out here because we're on such a short timeframe. The main page would be changed to add a banner like this, which would lead to this page with a video and further reading/learning links (again, it still needs a few technical tweaks, and it'd of course be moved to Wikipedia:20th anniversary if adopted). Is there general support for doing something like this? {{u|Sdkb}} talk 15:22, 14 January 2021 (UTC)

I think that banner is way to big, would rather something less intrusive like we did for 6MM articles (example). Keep in mind there is already also a huge CN banner for the New York area at the top of the page, landing on Wikipedia:Meetup/NYC/Wikipedia_Day_2021. — xaosflux Talk 15:48, 14 January 2021 (UTC)
Xaosflux, While the banner could be slightly smaller this is wikipedia's 20th anniversary and I think something big would be appropriate Asartea Talk | Contribs 15:52, 14 January 2021 (UTC)
@Asartea: I'm assuming this would be in addition to already styling the logo special as well - that's why I'm suggesting not making it so large in addition. — xaosflux Talk 16:06, 14 January 2021 (UTC)
Support mainpage banner and the page Asartea Talk | Contribs 15:53, 14 January 2021 (UTC)
Support Good idea ....but could we incorporate a few more options like above. Just not sure a cartoonish look is apprioate during a world wide pandemic...should look more academic in my view.--Moxy 🍁 16:01, 14 January 2021 (UTC)
Moxy, considering my quick reading of the Logo seems to indicate D will win this banner would be in the same kind of style. A more academic banner might clash with the logo otherwise. Asartea Talk | Contribs 16:08, 14 January 2021 (UTC)
Agree D will win.... the one that looks like the stickers on my granddaughters baby monitor ...sad face. Can we get color blind friendly version at least.--Moxy 🍁 00:08, 15 January 2021 (UTC)
  • Note: There is a banner campaign planned in support of WP20 in place of the usual WMF fundraising thank you campaign and will follow a similar format to that run in previous major anniversary. Seddon talk 18:21, 14 January 2021 (UTC)
Seddon, that's good to know. I'm not sure it'd interfere with this unless it's being planned to launch tomorrow. The aim is also different if it's fundraising vs. seeking editors. {{u|Sdkb}} talk 18:32, 14 January 2021 (UTC)
  • Support, it's a bit odd to have the page icon and not a banner. As for the format of this, I'm not really sure on what would be appropriate but do support a graphical style one.
✨ Ed talk! ✨ 23:48, 14 January 2021 (UTC)
  • Xaosflux, Would it be simplest to just use a modified version of the "x million articles" message? For instance, The English-language Wikipedia is celebrating its 20th birthday! Learn how you can take part in the encyclopedia's continued improvement. Sam-2727 (talk) 01:07, 15 January 2021 (UTC)
  • I've added the plain-ish banner via Template:Main Page banner; the landing page is Wikipedia:20th anniversary. I'm at least slightly involved in this preference, but "anything is better than nothing" seems to be prudent initially - discussion on further improvements to the banner are more than welcome to continue here and any admin is welcome to revert me if they think this is out of line without more discussion. — xaosflux Talk 02:33, 15 January 2021 (UTC)
    Xaosflux, I'm glad we managed to get something up. No one has addressed the technical stuff I mentioned above, though, so it currently works terribly on mobile or screens with an unusual resolution. Could we get someone good at CSS to address those things as soon as possible? {{u|Sdkb}} talk 12:33, 15 January 2021 (UTC)
    @Sdkb: can you be a bit more specific? The banner seems to be displaying at least as well as any of the other page content to me at very small and very large resolutions, in vector/monobook/minerva/timeless, also via the minerva on the mobile site (en.m.wikipeida). Are you referring to the banner itself or the landing page (Wikipedia:20th anniversary) itself (I think that one certainly could use some work but I didn't have anything to do with that page). — xaosflux Talk 18:02, 15 January 2021 (UTC)
    Xaosflux, I was referring to the landing page. BrandonXLF swooped in and fixed the issue, so we're set now. (Not the first time he's helped fix a CSS issue for mobile; many thanks!) {{u|Sdkb}} talk 18:05, 15 January 2021 (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.
Updated. — xaosflux Talk 19:48, 20 January 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.

The text of the banner current says The English-language Wikipedia is celebrating its 20th birthday! I think we should change it to Wikipedia is celebrating its 20th birthday! The founding of English Wikipedia and Wikipedia were the same, and founding Wikipedia as a whole is the bigger event, so that's what we're celebrating. Plus it's just cleaner. And I don't think we need the wikilink when this banner is appearing directly below the permanent banner which already includes a wikilink to Wikipedia. {{u|Sdkb}} talk 12:42, 15 January 2021 (UTC)

Xaosflux, courtesy pinging you on this since you implemented; would you be willing to switch the language? {{u|Sdkb}} talk 18:07, 15 January 2021 (UTC)
  Done trimmed Template:Main Page banner. — xaosflux Talk 18:15, 15 January 2021 (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.
Mooted as our banner has been removed. — xaosflux Talk 17:58, 22 January 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.

When I go to a page logged out, I see a banner with the rather silly tagline "celebrating 20 years human", linking to the WMF page. There doesn't seem to be anything on it at meta:CentralNotice; does anyone know where this is coming from? {{u|Sdkb}} talk 01:07, 16 January 2021 (UTC)

@Sdkb: I'm not seeing that one, just the CN notice with "Thank you for making 20 year..." that has a javascript easteregg to the foundation site (sigh....). Can you inspect that element you are seeing and provide more info? Also is this on desktop, mobile, or mobile app? — xaosflux Talk 01:55, 16 January 2021 (UTC)
@Sdkb: OK those seem to be coming from CN's as well (e.g. in pages like meta:MediaWiki:Centralnotice-template-WP20 test1 Cake20 I see the text) - think these are all being managed by User:Seddon (WMF). — xaosflux Talk 02:02, 16 January 2021 (UTC)
 
Variant I was originally seeing
 
Changed (current) variant
Xaosflux, when I just tried reloading the page, it changed the text, so we're seeing the same thing now. Attaching screenshots. If you'd like to know anything about the source code, just tell me what to look for when I inspect the element.
The main issue is that these duplicate our banner on the main page, creating some redundancy. Not a super urgent issue, but not totally ideal either. {{u|Sdkb}} talk 02:09, 16 January 2021 (UTC)
@Sdkb: think they have a few CN's that will cycle and they also have impression diets that make them not always show, and they show on every page not just MP - don't think we should remove our MP banner just because of that. — xaosflux Talk 02:13, 16 January 2021 (UTC)
Yeah, sounds fine. It might be nice to suppress the CN banner on the Main Page to get rid of the duplication, but I don't feel strongly. {{u|Sdkb}} talk 02:21, 16 January 2021 (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.

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.

This type of banner isn't really designed to be long-term, suggest taking it back down either (A) when changing to the more subtle site logo soon or (B) in about 2 weeks when we revert to the standard site logo. Any feelings one way or the other? — xaosflux Talk 19:48, 20 January 2021 (UTC)

Barring any objections, I'll stand this down whenever A occurs (see other section for progress on that). — xaosflux Talk 11:20, 22 January 2021 (UTC)
Removed from Template:Main Page banner. — xaosflux Talk 16:21, 22 January 2021 (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.

What about launching a campaign to candidate the Wikimedia Foudation for the Peace Nobel Prize?

Candidates for the Nobel Prize will be examined as from February 1st, there's still some time and this might be a favourable momentum! Lichinga (talk) 15:47, 14 January 2021 (UTC)

  • Something like that would have to be thoroughly planned and considered. There's no chance of us being ready to launch by tomorrow. {{u|Sdkb}} talk 16:16, 14 January 2021 (UTC)
  • I agree w/ Lichinga--Ozzie10aaaa (talk) 17:57, 14 January 2021 (UTC)
  • This is something that would need considering in great depth, researching thoroughly and a very strong and detailed nomination prepared if there is going to be any hope of it getting past even the first sift. Another consideration is that only certain people can make a nomination and still there are around 200 different nominees a year from a much higher number of nominators.[2] So in short, not this year. Thryduulf (talk) 22:36, 14 January 2021 (UTC)
  • Given that we're not going to win it this year, I think the nomination would be harmless. Certainly we can't prevent any eligible nominator from nominating us if they wish. BD2412 T 23:33, 14 January 2021 (UTC)

On other projects

Just wanted to note plans I've noticed at other projects. FrWikipedia are discussing the same options (except our option C) at w:fr:Wikipédia:Le Bistro du jour#Vote express d'un logo temporaire pour les 20 ans du projet. CsWikipedia chose a logo in the same art style as B and D at w:cs:Wikipedie:Pod lípou#20. narozeniny Wikipedie. Probably too late to take this into consideration, but if people are interested in being consistent with other projects, it's worth looking at. — Wug·a·po·des​ 20:04, 14 January 2021 (UTC)

Finalizing images

 
Final draft of option A
 
Final draft of option D

Given the discussion, the main candidates are A and D (the eventual closer will need to figure out which has consensus) and there's interest in memorializing the one billion edit milestone. In prep for deployment, I've finalized these two images based on the feedback. Let me know if there are any other issues that should be fixed before midnight UTC. — Wug·a·po·des​ 20:14, 14 January 2021 (UTC)

Given that there’s only a few hours till midnight, Wug, and also the last deployment window before Monday, do you have someone ready who can close this? And it may be worth contacting a sysadmin on IRC to have them (or someone else CR) look over the patch to make sure it, and the asset, looks okay, since there’s not much slack room I suppose. ProcrastinatingReader (talk) 20:21, 14 January 2021 (UTC)
Chatted up #wikimedia-operations and that seems ready when the time comes. Based on feedback, it seems the deployment window isn't as tight as I first thought so we we've got a bit of wiggle room (but not a ton). Mz7 said on IRC that they're willing to close. — Wug·a·po·des​ 21:06, 14 January 2021 (UTC)
The "20 years of" text needs to be properly centred under the puzzle-globe, it looks totally slapped on and unprofessional being slightly too much to the right. -- AxG / ✉  21:28, 14 January 2021 (UTC)
@AxG: I uploaded an example here, but imo it doesn't look much better. It leaves more white space between the small-cap letters and the italic text and still looks somewhat off-center because of the asymmetric width of the "W" and "A". — Wug·a·po·des​ 21:50, 14 January 2021 (UTC)
The centered text looks slightly better to me. {{u|Sdkb}} talk 23:42, 14 January 2021 (UTC)
I disagree. The non-centered text doesn't bother me. ~ HAL333 22:43, 14 January 2021 (UTC)
Wug·a·po·des​, the final deployed logo is cut-off at the bottom on MonoBook. See comments at Talk:Main page. Fences&Windows 23:33, 14 January 2021 (UTC)
Yep, we're working on it with Seddon on IRC as we speak. I'll leave a message there as well. — Wug·a·po·des​ 23:35, 14 January 2021 (UTC)

Duration

The logo's been up for almost 6 days now, and at this time, I believe there is consensus that the current logo ("Option D") has been up long enough. There also seems, however, to be consensus to switch the logo to Option A (i.e. File:WP20 EnWiki20 SimplifiedLogo BillionEdits.svg) for a limited time, rather than remove the logo completely. As for how long Option A should stay up, there isn't a universally agreed upon answer, with some editors suggesting 2 weeks (resulting in 20 days of changed logo total), others suggesting up to 1 year, and others advocating switching back to our standard logo immediately. However, if I were to announce a rough consensus, I would say the compromise that has the most support is to switch to Option A for the next two weeks, after which we should switch back to our standard logo. Respectfully, Mz7 (talk) 19:02, 20 January 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.

Tracked in Phabricator
Task T272108
  • @Mz7: Thanks for the close. Do we have any conclusions on the preferred duration? Up above there seems to be desire for it to be longer than a single day, but no firm consensus on exactly how long. {{u|Sdkb}} talk 22:37, 14 January 2021 (UTC)
    @Sdkb: Unfortunately, the discussion above only focused on which logo to use, so there aren't any conclusions on the preferred duration. I would say "do what you think is right", but if you want a definitive answer, then more discussion is needed. Mz7 (talk) 22:40, 14 January 2021 (UTC)
    I was expecting we might have another "24-hour RfC" on when to remove when it seemed the mood was for changing it back, but perhaps starting an RfC now on duration might be best, closing ad hoc when it's been almost the period of time that has the most agreement. (I'd like a week but I am but one mortal.) — Bilorv (talk) 22:47, 14 January 2021 (UTC)
  • FYI, per our normal deployment procedure, there shouldn't be any deploys until Tuesday, at the earliest (Monday is a US holiday so few people are around). Jdforrester (WMF) (talk) 23:26, 14 January 2021 (UTC)
  • This doesn't happen that often, I'm good for anything up to a month. — xaosflux Talk 00:54, 15 January 2021 (UTC)
  • Two weeks would be reasonable imo. ~ HAL333 01:26, 15 January 2021 (UTC)
  • one month since this is a unique achievement perhaps it should stay like this one year(however I'd switch to option A)--Ozzie10aaaa (talk) 02:22, 15 January 2021 (UTC)
  • It shouldn't go beyond the 15th unless it is changed to a variant of the original logo. We had a rushed RfC that installed a hideously tacky logo that barely fits with Wikipedia branding, regardless if these were picked by Wikimedia. Nihlus 02:24, 15 January 2021 (UTC)
  • Two weeks to a month sounds reasonable. I absolutely opposes 24 hours. OhanaUnitedTalk page 03:00, 15 January 2021 (UTC)
  • IMHO, the current logo (option D) is too distracting and loud to be used for a whole month. On the other hand, I'd be okay with having the logo up for a whole month if one of the more subtle options (e.g., option A) were used after the first 24 hours. 72.209.60.95 (talk) 03:15, 15 January 2021 (UTC)
  • I agree with the IP above that the current logo (D) is not suitable for long-term use, and with Nihlus that the 15th (or soon after) would be long enough. Two weks or a month would be too long. I wouldn't object to Option A (the original choice) replacing it for the remainder of 2021, though, since it's only a small adjustment from our regular logo. We'd then go back to the normal logo in 2022. Beyond My Ken (talk) 04:31, 15 January 2021 (UTC)
  • I have a slightly radical suggestion - keep option D for anywhere between three days to one week, and then keep option A for one year, till 15 January 2022. Wilhelm Tell DCCXLVI converse | fings wot i hav dun 04:52, 15 January 2021 (UTC)
  • I preferred Option D, then Option A in order - as the Option D is way cooler than Option A, but I didn't realize how ugly it was until today. I agree that Option D should be used for a short while, then Option A for the rest of the year until 2022. MarioJump83! 04:57, 15 January 2021 (UTC)
  • 20 days for 20 years. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)[ᴛ] 05:02, 15 January 2021 (UTC)
  • I agree that option D is probably not a great option for a long term logo, though I do like the idea of switching to option A for the rest of our 20th year. It shouldn't be hard to implement either as long as we can find someone to do the deployment. We've probably got this one through the weekend though. — Wug·a·po·des​ 05:12, 15 January 2021 (UTC)
  • D only for a day as a nice joke...use A for the month.--Moxy 🍁 05:25, 15 January 2021 (UTC)
  • I'm also liking the idea to switch to A after a bit. I don't think we need to keep D for more than a few days to a week at the most. Switch to A for the remainder of the month, or longer. — The Earwig talk 05:57, 15 January 2021 (UTC)
  • ~20 hours should be enough: with all these colours and everything there's hardly a need to keep it longer, people will have understood that we do indeed care a lot about this occasion. The logo File:WP20 EnWiki20 SimplifiedLogo.svg would be ok for longer periods. Nemo 06:58, 15 January 2021 (UTC)
  • No more than a week of Option D; I don't know how long celebrations will be going but they should be done by then. power~enwiki (π, ν) 07:00, 15 January 2021 (UTC)
  • 20 days sound good. —TheDJ (talk • contribs) 09:18, 15 January 2021 (UTC)
  • No more than a week of our painfully bright logo (fine for big splash, not a good long-runner), 72 hours would be better. Against just 1 day. Like some of the above, I'd be happy with 2-4 weeks of the calmer "A" logo. Nosebagbear (talk) 09:50, 15 January 2021 (UTC)
  • 20 days sounds good. imo keep D for the entire duration. No opinion on whether to revert to original logo, or option A, for some period afterwards. ProcrastinatingReader (talk) 10:25, 15 January 2021 (UTC)
  • Only 1 day seems good to me, if you must keep it longer then changing to (A) would be better for the rest of the time. Also, can we go back to 'The Free Encyclopedia' please? We're still about a factor of 1,000 from 1 billion edits, we're only at around 1000 million. Thanks. Mike Peel (talk) 10:54, 15 January 2021 (UTC)
  • There is more than one definition of a billion. See our article. Britmax (talk) 11:17, 15 January 2021 (UTC)
    • @Britmax: Exactly, that's why it's best to avoid using the word. Thanks. Mike Peel (talk) 11:37, 15 January 2021 (UTC)
      • Good point. Britmax (talk) 11:39, 15 January 2021 (UTC)
        • One million million as a billion is supposed to be the English variant, but my English self has never heard a single person use it that way IRL, and that's not what the news, books etc. use. I'm sure it's different in different countries but I think it's predominant enough to use here. At some point you have to make a regional choice. No-one has yet suggested "100 crore", which millions (rather: tens of lakhs) of our readers would find most natural. — Bilorv (talk) 15:16, 15 January 2021 (UTC)
          • I'm from the UK, but whenever I hear 'billion' I have to double-check what is actually meant... Good examples with crore/lakh. Why not avoid the whole issue by either just giving it as a number, or going back to the standard tagline? Thanks. Mike Peel (talk) 18:05, 15 January 2021 (UTC)
          • Then I suspect that you, Bilorv, are rather younger than me. When I was at school in England in the 1960s and 1970s "billion" very definitely meant a million million in British English, but by the time my children went to school in the 1990s the more common meaning had become a thousand million. Some of us old codgers are still alive and reading an online encyclopedia so ambiguity should be avoided if at all possible. Phil Bridger (talk) 18:47, 18 January 2021 (UTC)
            • Of course, the "correct" understanding of the term billion is indeed one million million. We do all know this. Sadly, we in the homeland are over-influenced by the usage of our ex-colonies and so tend to use their understanding of a billion to be a thousand million. We know that they are wrong, but the usage is spreading all over the place. Hence "billion" is likely to be a confused term for some people. I suspect though, that in this case, most people will not internalise the word billion to be a real number and will just accept that Wikipedia has done "lots" of edits. That is enough really. We have done lots, are justifiable happy about that and that is a Good Thing — GhostInTheMachine talk to me 20:32, 18 January 2021 (UTC)
  • One to a few days, I think it tends to confuse users about whether they are at the correct site. Alanscottwalker (talk) 13:12, 15 January 2021 (UTC)
  • 1 week seems reasonable to me. My rough sense is that most people visit Wikipedia at least that often, so keeping around for that long will give everyone a chance to see it. Anything beyond that and it just gets tired. {{u|Sdkb}} talk 13:32, 15 January 2021 (UTC)
  • I wouldn't mind it being used on a permanent basis going forward. It adds some new color the site and breaks the monotony of gray and white. -- Calidum 15:35, 15 January 2021 (UTC)
  • As briefly as humanly possible. Imho this is an abomination, and I came to this page to say as much. Put the number 20 in a wreath or something if you want to celebrate "20 years", when I saw this, my first thought was that Wikimedia has finally sold out to Google. This "Silicon Valley" art style is ugly aesthetically as it is soulless. Maybe it is only fitting that Wikimedia finally wears this style on its sleeve, but it doesn't suggest a celebratory mood, at least to me. --dab (𒁳) 19:18, 15 January 2021 (UTC)
  • The instituted icon should be up for minimal time. I think rest-of-the-month-to-20-days is a reasonable time for option A, since several seem to be suggesting that. --Izno (talk) 19:45, 15 January 2021 (UTC)
  • Leave D up over the weekend, switch to A on Monday. Mjroots (talk) 20:15, 15 January 2021 (UTC)
  • Option D should only stay up until the end of the day today (24 hours from when it was implemented, whenever that is). Option A is much better, in my opinion, and I am willing to see it for up to two weeks. A whole month seems silly to me, and a year even more so. — Goszei (talk) 21:30, 15 January 2021 (UTC)
  • Switch to A as soon as possible. D is ugly, off-brand and (to many non-American liberals) it also features a symbol of female oppression. Crazy. Rollo (talk) 22:10, 15 January 2021 (UTC)
  • 1 day sitewide / 1 week main page. Switch to A if long-term. This is a good compromise for both the celebrators and the let's-get-back-to-work people. Cordially, History DMZ (talk)+(ping) 00:22, 16 January 2021 (UTC)
  • I hope this won't last long. Yes, I missed my chance on !voting for another option, though I probably wouldn't have voted for any. Honestly, I first thought this was a feature letting me click on one of the four images (which are in fact one) depending on what device I was using (phone, desktop, tablet, other). As dab pointed out, these cutesy-primary-colors aesthetics don't quite cut it. ---Sluzzelin talk 00:31, 16 January 2021 (UTC)
  • I'd say 2 days for option D, then switch to option A and let it stay that way for 20 days. pandakekok9 (talk) 03:21, 16 January 2021 (UTC)
  • comment there are about 8 editors that both would agree to change to option A and leave for a year (there are several more indicating at least a month; also one gets the feeling from reading the above posts that the majority prefer option A)...Ozzie10aaaa (talk) 01:29, 17 January 2021 (UTC)
  • Wikipedia is for readers. Most readers couldn't care less that it's an anniversary, and the anniversary logo's visual heft is distracting. Wikipedia is for its contributors. Its contributors have spent years contributing to a site with a playful puzzle ball. Count this as another vote for "as soon as possible." (Option A is fine, but consider that many readers won't know what "one billion edits" even means. Yes, the process by which Wikipedia is made is something to celebrate, but at the end of the day, people only care if the information they're looking for is here, and whether it's right.) -- Zanimum (talk) 15:32, 17 January 2021 (UTC)
  • If it's going to be for longer than today, we need a much wider discussion. I predict a vote of 10–1 against the current banner. To me this is a cautionary lesson about making site-wide changes without a fully representative discussion. DGG ( talk ) 18:42, 17 January 2021 (UTC)
  • Switch to Option A starting 0:00 UTC January 19 and keep Option A for the remainder of the month. Some1 (talk) 23:55, 17 January 2021 (UTC)
  • It's time to take it down, in my opinion. ~48 hours (the time period in which it was Wikipedia's birthday in at least one time zone) would have been long enough. --Yair rand (talk) 00:02, 18 January 2021 (UTC)
I would say take it down at 0000 tomorrow. That's enough.--Wehwalt (talk) 01:41, 18 January 2021 (UTC)
  • Option D is horrible (accepted by a mere 1 vote "majority"), the sooner it is gone, the better (yesterday was too late). Pavlor (talk) 06:16, 18 January 2021 (UTC)
  • Remove immediately I've been puzzling over the elements of the image.
strike 1: The four pictures are supposed to come from the official resources but only 3 of them do so – the mobile phone at bottom left is not part of that set, which has this instead to represent mobile usage.
strike 2: The top left image is supposed to symbolise Wikiversity, not Wikipedia. Using an icon intended for a different project seems quite erroneous.
strike 3: None of the icons created to symbolise the point of the occasion have been included – no cake, fireworks or even the number 20.
Andrew🐉(talk) 11:36, 18 January 2021 (UTC)
Switch to A ASAP. Leave A for 2 more weeks — GhostInTheMachine talk to me 11:48, 18 January 2021 (UTC)
  • Switch to A or Remove I !voted for D on the assumption that it was running for one day, because it was unsubtle enough to (hopefully) be noticed by site visitors. Agreed that's it's too flashy to stay medium- or long-term. YorkshireLad  ✿  (talk) 12:02, 18 January 2021 (UTC)
D has been on for long enough Switch to A sooner rather than later, or go back to the original. Not particularly concerned if A stays on for a month or so. · · · Peter Southwood (talk): 15:52, 18 January 2021 (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.

Duration next steps

Tracked in Phabricator
Task T272526

I voted above, so need someone else to review next steps on the duration - seems like this is moving towards at least a "Change to special Logo A" soon (possibly during this weeks deployment) - though there were some concerns in another sections about the ambiguity of "billion" that may need to be addressed if we want that in the logo as well. So long as this is the next step, we've got time to determine how long "option A" will stay up once it is there, so determining that shouldn't block the switch to it if that is going to be the next step. — xaosflux Talk 16:18, 18 January 2021 (UTC)

  • would agree w/ above editor as to next step (option A asap), as seems to be the majority of editors above...(as to duration 8 editors have indicated a year, and several others about a month; since this is an achievement which will not happen again, 1 Billion, why not keep it up between a few months to a year, I guess we can vote only on duration)--Ozzie10aaaa (talk) 18:37, 18 January 2021 (UTC)
Huh? Option D is still here. What's going on? ---Sluzzelin talk 01:03, 19 January 2021 (UTC)
GET OPTION A UP, Pronto! Mjroots (talk) 08:50, 19 January 2021 (UTC)
Nearly everyone working on this is a volunteer, and speaking for myself I can't exactly take another day off work to wrangle all of the stakeholders again. If swapping the logo immediately is important to you, be bold and do it; nothing I did required advanced permissions. Log on to #wikimedia-operations and ask someone to deploy option A, and if it helps point them to change 656268, patch set 1, which has option A prepped already. You can also ask an interface administrator to temporarily deploy option A using css (see MediaWiki manual) while waiting for ops to deploy the config change. — Wug·a·po·des​ 23:14, 19 January 2021 (UTC)
@Wugapodes: I don't think there is any "pressing need" to rush the change - and also until someone actually closes the RfC above we should be blocked on community consensus. — xaosflux Talk 01:07, 20 January 2021 (UTC)
  • two weeks? (per pure math of the above 'duration' per editor it would seem at the least a month, if not more?)...update 'option D' is still up after two days??(22/1/21)--Ozzie10aaaa (talk) 19:36, 20 January 2021 (UTC)

margin overlap problem (resolved)

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.

  Resolved
 – Margin increased in site css files. — xaosflux Talk 00:59, 15 January 2021 (UTC)

Guys, right now this looks like this on my main page:

 

"OVER ONE BILLION EDITS" is cut off, and "Navigation" overlaps. It's like this on other pages also. Please fix. Cheers! BD2412 T 23:44, 14 January 2021 (UTC)

I see this has already been raised above. BD2412 T 23:47, 14 January 2021 (UTC)
@BD2412: this should be all patched in now, let us know if it isn't working for you please. — xaosflux Talk 00:50, 15 January 2021 (UTC)
It's good enough. The overlap is gone, and the "OVER ONE BILLION EDITS" is all there, although it seems a bit sharp at the bottom. BD2412 T 00:53, 15 January 2021 (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.

image text accessibility problem

Image is being removed, so no additional work is needed on this. — xaosflux Talk 19:44, 20 January 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.

Can we fix the color combination in the 4th image....as of now not visible to color blind readers.--Moxy 🍁 00:02, 15 January 2021 (UTC)

@Moxy: We can try. What color combination would look better for color blind users? You can see the palate at meta:Wikipedia 20/Resources#How to customize the mark but feel free to pick whatever colors you think look best. — Wug·a·po·des​ 05:47, 15 January 2021 (UTC)
Accessible Colour Contrast.--Moxy 🍁 06:04, 15 January 2021 (UTC)
@Moxy: this seems stalled, someone will have to want to work on this before the "duration" discussion decides to remove it -- feel free to mock up a new logo if you would like, but it's not a matter of just uploading it to deploy it to code either. — xaosflux Talk 00:04, 16 January 2021 (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.

New image feedback

This is being removed, see phab:T272526. — xaosflux Talk 19:12, 20 January 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.

Take this for what it's worth to you, coming from an editor who mostly just does drive-by edits here and there and who's not really part of the "meta-community"... but the new temporary image is so garish it actually motivated me to try and find a place to discuss it. :) I find the colors distract from the article texts, and the overall "aesthetic" sort of reminds me of K-12 sites from 20 years ago. The drawings themselves are competently-executed, it's just really out of place in what has traditionally been a greyscale, unobtrusive area. I appreciate that someone put some time and energy into it and that at least several people seem to have figured it was okay enough to win the above vote, but... man... oof. Anyway, feel free to refactor or move this to wherever people are discussing the image post-implementation, not calling for anyone's head here, just felt like I had to speak out! WonnE66 (talk) 01:23, 15 January 2021 (UTC)

 
A HORSE
(as determined by consensus)
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.
Latest comment: 3 years ago10 comments10 people in discussion

If a red link is supposed to indicate that an article on that subject is needed, and is not supposed to be used for anything else, and should be removed if misused, why is the only thing you see when you place the cursor over that word "the article does not exist". Why doesn't it say "article needed"? Imagine being a living person whose name is red-linked and all you see is "the article does not exist"! Wikipedia can be so confusing when it comes to living people. Sometimes we really care about how they are treated. Could we get that tooltip (cursor message) changed?

Proposal: Change the red link tooltip to read "Article needed". --SergeWoodzing (talk) 17:22, 14 January 2021 (UTC)

  • Hmm, interesting suggestion. Two questions that come to mind are: (1) Would we be concerned about erroneous overuse of red links (which, like it or not, happens) leading to the software encouraging the creation of non-notable articles? (2) Is there potential for confusion by moving away from the straightforward "page does not exist" to something else? Also, we'd need to refine a bit, since redlinks exist beyond just mainspace; for instance, I'm looking at a red link to Template:Editnotices/Group/Wikipedia:Village pump (proposals) from my current edit window, an example of a page that doesn't exist and probably shouldn't exist. We'd have to handle circumstances like that before moving forward with this sort of proposal. {{u|Sdkb}} talk 17:37, 14 January 2021 (UTC)

Comment: the tooltip adds (page does not exist) to the name. Page, not article. CapnZapp (talk) 18:58, 14 January 2021 (UTC)

I think the description should remain literal, rather than assuming that every dangling link indicates a page is needed. isaacl (talk) 19:00, 14 January 2021 (UTC)

Much less that every red link is for an "article". — xaosflux Talk 19:05, 14 January 2021 (UTC)

"Imagine being a living person whose name is red-linked and all you see is "the article does not exist"!" Okay, I'm imagining it. My reaction? So? It simply means that no one has written about me at this time. Is that supposed to bother me? --Khajidha (talk) 01:23, 15 January 2021 (UTC)

To add on to what others are saying, I've occasionally seen red links for articles that have been AfDed. Needless to say, those are almost definitely not needed.- Novov T C 08:07, 15 January 2021 (UTC)

  • in practice, ti appears whenever the article is not there for any reason: this may be because the article is needed, but it an also appear because the article has never been &should never be written because it would be inappropriate to do so for any one of a variety of reasons, or because of a typographical difference or mis-spelling. In the first case, the correct way to deal with it is to write the article; in the second, to either leave it alone or remove the link, in the third case to make a redirect if it's likely to be more than just idiosyncratic. Perhaps might do well to have more specificity--but considering the possibility of misuse and confusion, we might do just a swell to let things be, and leave it to the judgment of the editor encountering the link. DGG ( talk ) 11:06, 17 January 2021 (UTC)
  • Red links, ugh. They're even using them in citations. What would it hurt to simply do away with them? If you're taking time to redlink, just create the article. We've got enough delegators on WP as it is when coupled with format tagging, etc.[citation needed] Atsme 💬 📧 15:50, 17 January 2021 (UTC)
    Back in the day, there was actually a rule that when creating an article, you should deliberately and obviously leave something unfinished. The idea was that it was an invitation to others to join in. I don't think anyone saw it as an attempt to boss people around. WhatamIdoing (talk) 20:11, 22 January 2021 (UTC)

RFC at WP:POLITICS

Latest comment: 3 years ago1 comment1 person in discussion

See here for RFC on US party nominee succession boxes in US political bios. GoodDay (talk) 21:02, 23 January 2021 (UTC)

Replace hyphen with en-dash in Wikipedia browser tab name – MediaWiki:Pagetitle

Latest comment: 3 years ago49 comments33 people in discussion
The result is no consensus. Many editors supported this proposal, pointing out that the en-dash is more gramatically correct than a hyphen in this context (MOS:ENDASH). However, many other editors expressed hesitation and also stressed the low importance of this issue, pointing out that other reputable websites (e.g. The New York Times) also use hyphens or even pipes in their page titles. Additionally, other editors pointed out that most readers will never notice this change and that an en-dash would take up more of the already limited amount of space inside of a browser tab than hyphens. In my view, the community is sufficiently divided here that there is no consensus in support of either view, and because of this, at this time we will keep using the hyphen as the status quo ante. Mz7 (talk) 23:49, 23 January 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.

HTML tag <title> defines the text, which web browsers usually use to label tabs. The <title> tag on English Wikipedia is controlled through the page MediaWiki:Pagetitle (see mw:Manual:Interface/Pagetitle for details). English Wikipedia uses the default $1 - {{SITENAME}}, where $1 is replaced by the full page name, magic word {{SITENAME}} is substituted to "Wikipedia", and they are separated by a spaced hyphen. For example, this page has <title>Wikipedia:Village pump (proposals) - Wikipedia</title>. Different wikis use different separators. Examples (note that wiki-local internationalization preferences affect the page title—use incognito/private tab to see actual tab name):

MediaWiki:Pagetitle on different wikis
Wiki Separator Example of <title>
English Wikipedia hyphen Earth - Wikipedia
German Wikipedia en-dash Erde – Wikipedia
Spanish Wikipedia hyphen Tierra - Wikipedia, la enciclopedia libre
French Wikipedia em-dash Terre — Wikipédia
Russian Wikipedia em-dash Земля — Википедия
Chinese Wikipedia hyphen 地球 - 维基百科，自由的百科全书
Wikimedia Commons hyphen Earth - Wikimedia Commons
MediaWiki's own wiki hyphen Help:Editing pages - MediaWiki

I propose replacing the hyphen at English Wikipedia's MediaWiki:Pagetitle with an en-dash, which is a more appropriate separator—see MOS:ENDASH. —⁠andrybak (talk) 16:29, 3 November 2020 (UTC)

  • I don't think this is necessary, and keep in mind would only change for users with the English interface language set (everyone else will still get the system default). — xaosflux Talk 18:29, 3 November 2020 (UTC)
  • Support per MOS:ENDASH. This seems like a pretty simple grammar fix (albeit with a huge scale), so I'm not sure it needs a giant discussion here, but I'm also not sure where else the discussion would've been hosted, so I can see why you brought it here. To speak to Xaosflux's point, this shouldn't be something that only applies to English, so if we can figure out how to apply it to all languages, that'd be even better. {{u|Sdkb}} talk 22:56, 3 November 2020 (UTC)
    Shouldn't the punctuation on each project conform to its own language and MOS? The MOS on enwiki would certainly indicate that an en dash, not a hyphen, should be used here, but an em dash or hyphen may be correct in other languages. A centralized discussion on Meta would be a good place to confirm that each project's tab punctuation adheres to its own MOS. Armadillopteryx 00:46, 4 November 2020 (UTC)
  • Meh for en.wiki; they're all just horizontal lines. 99% of users have never noticed, and of that 1%, 96% won't care. None of our business for all other wikis. I assume I'm misunderstanding Sdkb's comment; you aren't suggesting that the result of a discussion here should affect all other wikis? --Floquenbeam (talk) 23:29, 3 November 2020 (UTC)
    @Floquenbeam: From what Xaosflux said above, it seems that a fix might only apply to the English Wikipedia with the English language interface set, not all language interfaces. We control all language interfaces on English Wikipedia. As for other Wikipedias, it might be nice to standardize among those, but that discussion would probably have to be held somewhere on Meta. {{u|Sdkb}} talk 23:35, 3 November 2020 (UTC)
    It's very likely you know more than me about this. But "We control all language interfaces on English Wikipedia" doesn't sound right at all. I think I must be missing a subtlety or distinction or term of art? Anyway, it isn't important that I understand. As long as you're not saying we should make changes for, say, es.wiki or Commons too - which it looks like you're not saying - then we're good. --Floquenbeam (talk) 23:42, 3 November 2020 (UTC)
    In Special:Preferences you can set your language. If unset or set to a language that doesn't have a locally created MediaWiki page, there is a default MediaWiki page used. Killiondude (talk) 00:19, 4 November 2020 (UTC)
    MediaWiki has a framework to support translations into different languages in its own user interface messages, as described by Killiondude, which is what Sdkb is describing regarding having control over all language interfaces on English Wikipedia. It has been long recommended for users not to change their preferences to another language, though, as a lot (most? all?) of customized messages have not been translated (and as I recall, even specifying a country-specific English variant, like en-uk, will cause a fallback to the default message, thereby losing the customization). isaacl (talk) 00:36, 4 November 2020 (UTC)
    @Killiondude and Isaacl: actually it seems that if a custom message is set but not translated, the custom message is used. At least in the sidebar - go to https://en.wiki.x.io/wiki/Earth?uselang=de (an en.wp page but with the interface language set to German). The second item in the "contribute"/"Mitmachen" section is the custom English "Learn to edit" in both English and German interfaces rather than the default "Introduction" / "Einführung". Thryduulf (talk) 01:41, 4 November 2020 (UTC)
    You can see what impact changing the interface language would have by appending ?uselang=xx (where xx is the language code you want to use) to the URL (or &uselang=xx if the URL already contains a ?). For example go to https://en.wiki.x.io/wiki/Earth?uselang=de to see an English Wikipedia article with the interface language in German. The article text remains in English, but all the tabs, sidebar links, etc. are in German. Thryduulf (talk) 01:41, 4 November 2020 (UTC)
    It took you all more effort than it was probably worth, but I finally understand. Thanks everyone for the patient explanations, sorry everyone for being technologically incompetent, and sorry User:Sdkb for momentarily implying you might have been saying something crazy. --Floquenbeam (talk) 16:26, 4 November 2020 (UTC)
    No worries at all! {{u|Sdkb}} talk 19:31, 4 November 2020 (UTC)
  • Support this change on enwiki (and other English-language projects) per MOS:ENDASH; projects in other languages should make sure the dash (or hyphen) used conforms to their own MOS. Armadillopteryx 00:46, 4 November 2020 (UTC)
  •   Comment: previous relevant discussion: Wikipedia:Village pump (proposals)/Archive 135 § Proposal: Amend page title element to remove "Wikipedia, the free encyclopedia". —⁠andrybak (talk) 01:08, 4 November 2020 (UTC)
Support, hyphens are not used for this purpose, WP:NDASH.  Nixinova   T   C   02:23, 4 November 2020 (UTC)
  • Support. It's a tiny, tiny thing...but honestly, I would be happy to see it happen.—Neil Shah-Quinn (talk) 15:11, 6 November 2020 (UTC)
  • Support on enwiki per Armadillopteryx. 〈 Forbes72 | Talk 〉 16:28, 6 November 2020 (UTC)
  •   Comment: should an RFC be opened to gather more feedback? —⁠andrybak (talk) 16:01, 8 November 2020 (UTC)
  • Support – It shouldn't be a question that our interface should generally conform to the MOS absent any reason to the contrary. 207.161.86.162 (talk) 03:26, 9 November 2020 (UTC)
  • Tentative support, but I am wonder whether there is a technical reason that hyphens in page titles are so common, even for sites with strict style manuals. For example, both the New York Times and the BBC have hyphens in their page titles. Indeed, it looks like every site in my browser bookmarks that has equivalent punctuation has a hyphen (except that my university's Blackboard Learn site has both a hyphen and an en dash in the title, which looks quite ugly now that I have noticed it). Any thoughts about why that might be? blameless 21:01, 9 November 2020 (UTC)
    • Withdrawing my support per the below and continued investigation. It was said above that "hyphens are not used for this purpose"--I am certainly a descriptivist, and I would say that hyphens are used for this purpose for purely internet-based instances of language (such as browser tabs) that are entirely separate from prose content, for the sake of consistency and reliability across browsers and character sets. Neutral. blameless 19:26, 26 November 2020 (UTC)
  • Oppose or replace with pipe. Browser tabs have limited horizontal space, and the only effect of this proposal is to waste a bit more of it. Perhaps this is why it is so common to use a hyphen or a pipe rather than an en-dash or em-dash. ST47 (talk) 21:29, 9 November 2020 (UTC)
    ST47, I'd have thought that the pipe would take up less space than an endash. I've tested in Firefox and Chromium in Ubuntu. In Firefox the pipe takes up more space than endash (font Noto Sans 10pt). In Chromium both take up the same amount of space (I couldn't figure out which font is used). —⁠andrybak (talk) 23:06, 9 November 2020 (UTC)
  • My browser (Firefox on Debian) follows our page title (and every other page title) with " - Mozilla Firefox" so using a dash or pipe would make my browser title look weird. Is that enough to oppose? I don't know, but clearly hyphens are pretty standard separators in how browsers display page titles. Additionally, it's probably better that our page titles are ASCII-compliant, and this change would move us away from that. This could affect page downloads or distribution on offline hardware. My main concern is that we gain pretty much no benefit, but there might be hidden problems it introduces. — Wug·a·po·des​ 23:55, 9 November 2020 (UTC)
  • Meh Not worth the trouble for all the reasons Wugapodes mentioned. Probably nothing will break, but the benefit is so small it's not worth doing. The hyphen-minus is also the standard window title element separator on every non-Apple platform. An en/em dash will take up more space, which is undesirable. Switching to pipes would change the visual style, and I'm not a fan of that idea either (the hyphen-minus is the most common <title> separator anyway. --AntiCompositeNumber (talk) 00:27, 10 November 2020 (UTC)
  • Oppose Browser has limited space. Also, the proposal text doesn't clearly say which Hyphen#In_computing is currently used. Hyphen-minus is ASCII. If it currently is ASCII, then stay with ASCII for less interference with third party systems. TerraCyprus (talk) 23:26, 10 November 2020 (UTC)
    Sticking to ASCII is about 3 decades out of date, and is in general too limiting, even for English. Dicklyon (talk) 21:56, 10 December 2020 (UTC)
    TerraCyprus, regarding If it currently is ASCII, then stay with ASCII for less interference with third party systems. tag <title> already contains dashes and much more of the Unicode. E.g. Ágústa Þorsteinsdóttir, 燒酒. —⁠andrybak (talk) 16:59, 31 December 2020 (UTC)
  • Meh (Is Meh a valid voting option?) The title is also used for bookmarks, and so the site suffix has some value there, but I generally edit the titles to make sense to me and normally remove the suffix. Most of the time the tab is too narrow to display all of the article title, so the "- Wikipedia" site suffix is lost anyway. Personally, I would delete the site suffix from the titles as the icon at the start is enough to identify the tab, but I do suspect that would be seen as a step too far — GhostInTheMachine talk to me 11:59, 14 November 2020 (UTC)
  • Meh because I'm not sure I'll ever encounter a Wikipedia debate that warrants "meh" as much as this one. I'm sympathetic to both sides, but would probably favor the character that can be entered with one tap of the keystroke and is easily identified by non-native English speakers who don't even know what an en- or em-dash is. On the other hand no one's really going to be typing this on their own. Also, what were French and Russian Wikipedias thinking when they instituted the em-dash? -- Fuzheado | Talk 20:46, 16 November 2020 (UTC)
    Fuzheado, Russian Wikipedia's MOS is based mostly on current Russian grammar and typography practices. Same is probably true for the French Wikipedia. —⁠andrybak (talk) 07:49, 23 January 2021 (UTC)
  •   Comment: I have requested closure of this discussion at WP:ANRFC. —⁠andrybak (talk) 18:25, 23 November 2020 (UTC)
  • Support. The use of the hyphen here is an old "lazyism" from pre-MOS:DASH days. Should have been corrected a long time ago.  — SMcCandlish ☏ ¢ 😼  03:49, 8 December 2020 (UTC)
  • Support –definitely. It's professional English, and apart from being in accordance with the major style guides (including ours), it's slightly easier to read. I don't care if other languages want to stick with their shabby little hyphens. Tony (talk) 09:34, 8 December 2020 (UTC)
  • Yes, Support the hyphen is a lazy substitute for the intended punctuation, a dash of some sort. The spaced en dash is a good choice. Those who won't notice the difference won't be bothered. Dicklyon (talk) 06:58, 9 December 2020 (UTC)
  • Support. It's a very minor thing, but we may as well follow proper professional usage. Alkari (?), 10 December 2020, 04:29 UTC
  • Oppose Pretty much what Floq said. I don't have a real "side" as far as the actual issue, because, like most people, to me the distinction is essentially meaningless.(Please, please don't feel compelled to explain to me how very important it is) So, the only concern here is "will this break anything?" And it seems that a few people here are concerned that it might. So, very, very little benefit (arguably none at all) and some risk, so that's a no for me. Beeblebrox (talk) 00:04, 19 December 2020 (UTC)
  • Support. I found myself on both sides while writing this comment, but settled in support. The MOS is clear that an en-dash is preferred over a hyphen as a separator here. The most cogent objection is that the en-dash may cause certain technical issues, and there's a lesser point that it takes up more space. However, this same reasoning would apply to our many articles that are titled with – or — instead of -, or indeed any other non-ASCII characters, which all show up in the <title> tag. And yet, MOS:DASH has been in place for article titles for many, many years with no apparent problems. The fact that dewiki, frwiki, and ruwiki all use some form of dash also supports this point. We can always revert the change if we find out about some unexpected side effect. — The Earwig talk 06:11, 27 December 2020 (UTC)
  • Oppose If it works, don't fix it. Andrew🐉(talk) 13:00, 28 December 2020 (UTC)
  • Oppose Why so many people have this thing for a character that's not standard and cannot be typed is beyond me. It's constantly forced down our throats for no reason. - The Bushranger One ping only 07:20, 31 December 2020 (UTC)
    The Bushranger, regarding a character that's [...] cannot be typed. On Windows, it can be typed using the ⊞ Win+. menu (under Ω tab), on macOS it is ⌥ Option+-, on most Linux distributions it is Alt+-+-+. (via XCompose feature), on Android and iOS most keyboard apps support it on long press of the hyphen -. On Wikipedia, the en-dash can be inserted using both the editor toolbar (Special Characters > Symbols) and CharInsert extension (first character in the "Insert" group)—both UIs are enabled by default. Also, there is HTML entity &ndash;. —⁠andrybak (talk) 16:44, 31 December 2020 (UTC)
    And it doesn't matter anyway in this context. Bushranger's "utility" argument is inapplicable to something that is simply part of the interface display.  — SMcCandlish ☏ ¢ 😼  22:50, 1 January 2021 (UTC)
  • Support per MOS:ENDASH resp. Sdkb and particularly 207.161.86.162 and SMcCandlish, who both expressed my view very succinctly. Similar to The Earwig, I was wavering for some of the same reasons, but above all because of GhostInTheMachine's statement. However, my support was strenghened when I saw that a significant portion of the Oppose votes were because of a fear that something could break, which is absurd IMO given andrybak's point that the title already often contains non-ascii characters. ◅ Sebastian 20:38, 1 January 2021 (UTC)
  • Support. It's small change but conforms better to English style guides. I don't see how typing it is such a problem. This is not a change that implies the need of manually entering the character, and MOS:ENDASH already mandates it for a lot of content. --MarioGom (talk) 14:25, 4 January 2021 (UTC)
  • Support, per the MOS & correct punctuation. Cavalryman (talk) 04:23, 6 January 2021 (UTC).
  • Support it's hard to take a side here, and indeed I don't take either with much confidence. But as a small change that better conforms with MOS and standard English, I think we may as well. Aza24 (talk) 01:39, 8 January 2021 (UTC)
  • Don't think MOS applies to page titles. Most sites - massive, big, and small - use a hyphen in page titles. English Wikipedia would be sticking out like a sore thumb. Keep the hyphen. ProcrastinatingReader (talk) 16:40, 13 January 2021 (UTC)
  • Support. MOS:ENDASH. Personally, I was quite getting used to this. MarioJump83! 04:32, 15 January 2021 (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.
Latest comment: 3 years ago7 comments3 people in discussion

I think that the mobile view should have more links directing users to appropriate places. I think one link that should be added is a help link and tutorial. I will create specific sections to try to propose and hopefully get community support for the idea. I am now editing in mobile view more than desktop view now and hopefully these changes will help Wikipedia become a more user-friendly site in the future. Interstellarity (talk) 16:57, 24 January 2021 (UTC)

  1. Support as proposer. Interstellarity (talk) 16:57, 24 January 2021 (UTC)
  1. Support as proposer. Interstellarity (talk) 16:57, 24 January 2021 (UTC)
Question....I don't see any sidebar in mobile view..do you mean the top banner? Also is the tutorial accessible to you in mobile view? --Moxy 🍁 17:09, 24 January 2021 (UTC)
I’m talking the hamburger menu in mobile view to clarify. Interstellarity (talk) 17:24, 24 January 2021 (UTC)
Oh and I forgot to answer your second question. I had no problems with viewing tutorial on my mobile device. Interstellarity (talk) 18:44, 24 January 2021 (UTC)

General discussion

I find mobile extremely complex, since there's not just one mobile version—there's the mobile web browser, the mobile web browser in advanced mode, the Android app, the iPhone app, and possibly others I'm forgetting. I agree that it'd be good to have some discussion about which links from the desktop left sidebar to include on the mobile version, but without knowing exactly what's currently there for the different mobile versions or what the space/design considerations are, it's hard to make judgements about specific changes. {{u|Sdkb}} talk 03:08, 26 January 2021 (UTC)

RfC: Should we have Support/Oppose/etc. survey convenience templates?

Latest comment: 3 years ago97 comments44 people in discussion
Consensus continues to be not to have these templates Even setting aside the (lengthy) history, the myriad arguments in opposition make a strong case. ~ Amory (u • t • c) 19:25, 1 February 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.

Should we have survey convenience templates? Mike Peel (talk) 22:07, 1 January 2021 (UTC)

While WP:NOTVOTE is really important, we have a lot of discussions/debates (like this one) that people Support/Oppose and comment on. A lot of the Wikimedia projects use templates like {{Support}}, {{Oppose}} etc. to help with this, often also including a symbol. These templates were deleted here back in 2005, mostly because people objected to the inclusion of the symbol.

In this RfC I propose restoring these templates but without the symbol. This would mean that editors could use {{Support}} rather than '''Support''', but it would look the same. It would not be compulsory to use one or the other, and of course the !vote should be accompanied by a rationale regardless. The templates would simply be a convenience for editors that are used to using the other syntax, and would avoid a lot of follow-up edits to fix formatting after trying to use the templates instead of the bold formatting (which I at least frequently do, either after saving or in preview!). Their use would have negligible impact on server load (another concern from 2005), but could easily be bot-substituted (by batches every day/week/month) if that really is still a concern.

(These templates have been frequently recreated since their deletion, to the extent that it is a perennial request (the difference with this !vote is that it's to meet cross-wiki expectations, and I'm not proposing to use icons). I originally took this to WP:DRV last month as per the latest deletion/protection edit summaries, but an RfC was recommended instead.)

Thanks. Mike Peel (talk) 22:07, 1 January 2021 (UTC)

Survey (survey convenience templates)

Notified: Wikipedia talk:Templates for discussion. * Pppery * it has begun... 22:31, 1 January 2021 (UTC)
  • @Pppery: It's not about the number of characters, it's about the time it takes to remember the syntax, and that the syntax shouldn't depend on which Wikimedia project you are using. The human cost is much more than the syntax cost. It's the same as {{tq}} vs. this alternative way of writing it. Thanks. Mike Peel (talk) 22:38, 1 January 2021 (UTC)
  • I would prefer to type “ {{Support}}” rather than “'''Support'''” because the “'” character is not on the iPad keyboard. {{Support}} could be made to auto-subst. Oppose cut or gaudy pictures. —SmokeyJoe (talk) 23:05, 1 January 2021 (UTC)
  • Oppose Sorry but no. I understand that moving between projects is a mental pain (I struggle with the equivalent of {{tl|xxx}} at Commons) but hiding simple syntax does not help the project. Some projects appear more focused on a vote count, and that idea should not be encouraged here. Johnuniq (talk) 23:08, 1 January 2021 (UTC)
  • Oppose per Johnuniq's comments, especially about hiding syntax. We should not be encouraging anything that gives the impression that votes are more important than the rationale accompanying them. Thryduulf (talk) 23:14, 1 January 2021 (UTC)
    @Thryduulf: How exactly does the existance of a convenience template give that impression, please? Thanks. Mike Peel (talk) 21:07, 3 January 2021 (UTC)
    @Mike Peel: the existence of a template, regardless of the formatting it outputs, elevates the importance of that output - if it wasn't important then why would anybody make a template for it? Why would any template be kept if it wasn't adding something of value? Experienced editors will unlikely gain this impression, but that is not necessarily true of those who are new to Wikipedia or who have a limited understanding of how XfD discussions work (if there wasn't an impression they are votes then we wouldn't need boilerplates like {{not a vote}}). Thryduulf (talk) 23:57, 3 January 2021 (UTC)
    I disagree with that thinking, I don't think having the template would give any more weight to a new user's thinking that they can !vote than seeing a list of bold-formatted support/oppose votes that they could copy/paste would. Thanks. Mike Peel (talk) 09:30, 4 January 2021 (UTC)
  • Oppose what would the Support template expand to, other than Support in bold? — GhostInTheMachine talk to me 23:45, 1 January 2021 (UTC)
  • weak support I don't think it unreasonable request--no reason to make anyone's editing harder and it sounds like there are a few people it would help. That said, the help is minor and the worries about a slippery slope to voting aren't utterly trivial. So a small thing that helps people now vs. a very unlikely thing (but not impossible) that might hurt the culture down the road? I'm gently leaning toward the short-term gains being worth the improbable long-term risk. Hobit (talk) 04:32, 2 January 2021 (UTC)
  • Oppose per Johnuniq ~ HAL333 04:45, 2 January 2021 (UTC)
  • weak Support If we can have {{Agree}} and {{Disagree}} why not Support or Oppose? RudolfRed (talk) 05:03, 2 January 2021 (UTC)
  • Usually I eschew starting my comment with a bolded word, precisely to place emphasis on discussion over voting. Assuming the community is truly dedicated to making decisions through discussion, I do not favour having templates that give more prominence to votes. isaacl (talk) 07:18, 2 January 2021 (UTC)
    @Isaacl: the opposite is that there are so many words in a section that prefacing the section with a bold helps you know what to expect, especially in confusingly worded arguments you know better what they're trying to get at. eg when closing RfCs I don't necessarily close based on vote, but knowing a binary yes/no before a comment helps follow the comment and get a general feel of where the discussion lies. ProcrastinatingReader (talk) 19:20, 2 January 2021 (UTC)
    I wrote something similar once about how knowing where an argument is heading can help provide context and thus improve understanding. Nonetheless, it can be done with a thesis sentence, rather than a single bolded word. I appreciate many people like starting with a single bolded word. I believe, though, that it puts more emphasis on voting and tabulation of votes versus discussion. isaacl (talk) 19:28, 2 January 2021 (UTC)
    User:Isaacl, you are assuming that others find it as easy to read or write a thesis sentence as you do. E.g. people with dyslexia, ESL, inexperience with writing topic sentences) I personally struggle to summarise positions into a sentence for many reasons. It was also helpful to me as a new editor that there's a format which people are generally using to help me feel able to engage with discussions. --Xurizuri (talk) 11:33, 12 January 2021 (UTC)
    If someone can't, that's OK. Starting with "I support the proposal," is fine. If we're trying to encourage discussion amongst those who have opted to contribute to a writing project, though, I think it's reasonable to aspire for participants to craft a concise explanation of their viewpoint. Though it'll likely remain an ideal, it's a good target to aim for. isaacl (talk) 17:00, 12 January 2021 (UTC)
    The practice became widespread because editors felt it worked best. It has persisted because editors continue to feel it works best (for the most part, although many surely do it because they see others doing it). To my mind, there is no higher principle than that, and there is something to be said for consistency in formatting (some handle the variation better than others, and I'm in the latter group). But whether to use a bolded first word and whether to create templates for it are separate and independent questions. ―Mandruss ☎ 18:42, 12 January 2021 (UTC)
    Yes, as I said, I appreciate many people like to start their response with a bolded word. isaacl (talk) 01:01, 13 January 2021 (UTC)
  • I'll support such templates, not because I'd use them myself, but I see no justification for preventing other people from using them. When instructions are given for how to participate in XFD discussions, a summary word in bold is suggested.[3][4][5][6][7] On the rare occasions when I take part in such discussions on other wikis I have to go round searching other people's comments for the appropriate syntax so I can sympathise with the difficulties of occasional !voters here. Thincat (talk) 09:48, 2 January 2021 (UTC)
  • Oppose. This is a good example of the failure to understand the cost of complexity in terms of barrier to entry. Multiple ways to accomplish the same thing is unnecessary complexity, unjustified by the perceived need to let every editor "have it their way" (apparently because they are unpaid). Anyway, the template syntax is no less prone to typing error than the markup. In the worst case the editor can omit the bolding and it may be fixed by another editor per TPO. To the extent that is not done, a few very rare cases of unbolded !votes are not a significant problem. ―Mandruss ☎ 11:29, 2 January 2021 (UTC)
  • OPPOSE - The goal is simply to highlight what your opinion is. There are lots of ways to do this. As demonstrated here, ALL-CAPS works too. Blueboar (talk) 14:16, 2 January 2021 (UTC)
  • To disincentivise plain voting, we could adopt these templates, but ensure they only output an empty string :) – Uanfala (talk) 16:56, 2 January 2021 (UTC)
  • Oppose This is NOT a problem. No SOLUTION is necessary. GenQuest "scribble" 22:02, 2 January 2021 (UTC)
  • Oppose - per User:GenQuest and User:Mandruss (and probably a few others that I agree with for other points). Or, if you wish for greater detail, why would we decrease inconsistency between multiple projects by increasing inconsistency in one project? Having the same method for producing bold "oppose" and "support" as is used for making other things bold throughout Wikipedia is beneficial to the general run of users on Wikipedia.--Khajidha (talk) 00:33, 3 January 2021 (UTC)
  • Support. Minimal implementation cost, minimal burden on other users, and well-defined use case. Thincat put it well. I understand the instinctual "no voting templates!" response, but there's no icon and no emphasis on the opinion. It would be a good idea to brainstorm ways to enforce current community norms around !voting if these templates are created, though. Enterprisey (talk!) 00:52, 3 January 2021 (UTC)
  • Sure. If there are no icons, {{Support}} and {{Oppose}} become shortcuts for wiki markup. As with SmokeyJoe I use an iPad to edit Wikipedia, and typing {{Support}} would be slightly better for me than '''Support'''. I also agree on what Thincat and Enterprisey said. GMX (on the go) 16:00, 3 January 2021 (UTC)
  • {{Support}} The cognitive dissonance of people typing '''Oppose''' in this discussion is remarkable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:19, 3 January 2021 (UTC)
    • As one of the several people who have explained why a template producing the same output as '''Oppose''' is not desirable I find this ad hominem to be in rather bad taste. Thryduulf (talk) 20:40, 3 January 2021 (UTC)
      • @Thryduulf: Andy has a point here about how people comment regardless of the existence of the template, it's not an ad hominem. Thanks. Mike Peel (talk) 21:07, 3 January 2021 (UTC)
        • Effectively calling everyone idiots, without explaining why they're being called idiots, sort of looks like an ad hominem, doesn't it? – Uanfala (talk) 21:45, 3 January 2021 (UTC)
        • @Mike Peel: if Andy has a point other than insulting the intelligence of people with a different opinion on these templates to him then I am at a loss as to what it is. I can't prove it, obviously, but the impression I get is that he has read only the bolded words (which would be rather ironic for this discussion). Thryduulf (talk) 23:57, 3 January 2021 (UTC)
        • Competent editors can see that Andy's comment was 100% insult and 0% argument, and therefore a "not-not-vote" of no consequence. A competent closer, if there is a closer, would simply discard it. ―Mandruss ☎ 16:10, 4 January 2021 (UTC)
  • weak support I would not use it, but why not have such a template if it makes it easier for some? Graeme Bartlett (talk) 02:52, 4 January 2021 (UTC)
  • Oppose. Tends to encourage voting rather than discussion aimed at generating a consensus. Solution looking for a problem. Stifle (talk) 09:56, 4 January 2021 (UTC)
  • OPPOSE per Thryduulf, isaacl and Stifle. Those who can't write bold should use the workarounds mentioned above, address their shortcomings (which would help in a far wider range of applicability) or simply write all caps, as Blueboar suggested. ◅ Sebastian 11:17, 4 January 2021 (UTC)
  • Oppose per Johnuniq, Mandruss and GenQuest - This really is a solution looking for a problem. I appreciate Commons etc use {{Support}} however we're not Commons, Every project has their own way of doings things and "'''Support'''" is our way of doing things. Personally I use "'''Support'''" on all projects as it's what I'm used too (unless it looks out of place which I then change it after (ie with RFAs etc)). –Davey2010Talk 11:30, 4 January 2021 (UTC)
  • Support: trivial implementation, no disruption of previous practices, no migration cost, aligns well with other Wikimedia projects, probably slightly less chance of unbalanced markers (e.g. 2x2 vs 3x3). --MarioGom (talk) 14:06, 4 January 2021 (UTC)
  • As much as I myself mostly start comments with a bold oppose text, I don't think this a template necessary. Firstly, per there being a wide range of commonly used !vote strings and having a template for each is a massive overkill. Will we be needing {{Option|2}} for Option 2 or something? This proposal fails to list (even as example) the actual templates, there are surely more than the two mentioned. And having only a few of these will just create extra differences in markup. I would want to see some statistics of the commonly bolded terms in discussion first. Furthermore, the non-existent complexity of the output does not warrant a template, it is unnecessarily convoluting what is a simple text message, nor is having (even more) templates in text helpful when it's literally default bold syntax. Then there's grammar -- what if I want it lowercase or add other words that need bolding? These just feel like ballot checkboxes rather than a summary of the opinion to follow. Finally, pretty sure this will just make using visual editor way more complicated needing to insert a template when one could have clicked/tapped bold like is standard in every other text editor. —  HELLKNOWZ   ▎TALK 14:39, 4 January 2021 (UTC)
    This is a good point - the common recommendations at current discussions are: "allow recreation", "containerize"/"containerise", "convert to an article"/"write an article", "delete", "disambiguate", "draftify", "dual merge", "endorse", "keep", "listfy", "merge", "move", "oppose", "overturn", "purge", "redirect", "refine", "relist", "rename", "rename", "restore", "retarget", "reverse merge", "revert", "setindexify", "soft redirect", "split", "subst", "support", "upmerge", "userfy", "wrap"/"wrapperify" and "wrong venue". Then you have modifiers like "all", "don't", "for now", "in principle", "leaning", "speedy", "strong", "weak" and "without prejudice" and non-recommendation bolds like "comment", "note", "question" and "update". Covering all these would need between 40 and 50 templates. Thryduulf (talk) 13:09, 5 January 2021 (UTC)
    @Thryduulf: We're only talking about the most common uses of such templates, which are also used on other wikis, like those mentioned in the proposal. There's a latin phrase you could use to explain your comment if you want, though. Thanks. Mike Peel (talk) 22:04, 5 January 2021 (UTC)
    These are the the recommendations used multiple times in a current discussion and/or in multiple current discussions on en.wp (AfD, RfD, CfD, TfD, MfD, DRV, MRV and RM; although there were none exclusive to MfD). To be useful to editors at en.wp they will need to cover the !votes they will commonly make otherwise they will frequently have to use the standard ''' markup which negates the whole point of having templates in the first place. What other wikis do is not relevant to discussions on the English Wikipedia. Thryduulf (talk) 00:43, 6 January 2021 (UTC)
  • Why not I would never use them, but that doesn't mean that others wouldn't find them useful. Most of the oppose votes are people who have no personal use for them. Why is this even a vote? The OP could have saved themselves some trouble by just creating them. I am struggling to figure out why we needed to even have this discussion/vote. --Jayron32 15:43, 4 January 2021 (UTC)
    No trouble would have been saved by doing that, because (a) the templates are salted and (b) I would have tagged than as {{db-g4}} if I had noticed them being recreated. We would have ended up here anyway after a few more rounds of bureaucracy. * Pppery * it has begun... 15:47, 4 January 2021 (UTC)
    It's quite apparent that this is controversial. Sure, people often slip in new templates that would be controversial if discussed beforehand, but I don't consider that good faith practice. Editors are less likely to challenge by WP:TFD because it's such a hassle (and, for some, because they aren't aware of TfD or don't have the time to learn how to use it correctly). If the creation of a template were as easily challenged as an ordinary edit, standard BRD process would work fine, but that is unfortunately not the case. I commend the proposer for "discussing first" in this case, despite the fact that it likely would have been easier to get forgiveness than permission. ―Mandruss ☎ 16:38, 4 January 2021 (UTC)
My primary concern is that templates (in general) too often shift from being “optional” to being “preferred” ... and then to “expected” and finally to essentially “mandatory”. I know this is not the intent here, but I have seen this shift occur too many times with other templates to be comfortable with it now. Blueboar (talk) 17:03, 4 January 2021 (UTC)
@Blueboar: Definitely not the intent here. I can't say that this won't happen, but if it does, then presumably it would be accompanied by discussions that you and others (including myself) could object to. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)
My experience with “template creep” is that there often isn’t any discussion in which to state an objection. So I am objecting NOW, while I have a chance to do so. Blueboar (talk) 22:25, 5 January 2021 (UTC)
  •   Orz... can we have "Strong Meh" as well? But really we already have Template:Done/See_also and we also don't have a problem with people actually typing "Support" so I really don't care if a template does it as well, however I don't want to see a proliferation of media like File:Symbol confirmed.svg on every discussion, less concerned if it is stylized text (even check marks that are not image files). — xaosflux Talk 17:22, 4 January 2021 (UTC)
  • Even without images, we can still run into problems with a page's transclusion limit which could end up breaking the village pumps or ANI where there are lots of proposals with lots of bolded !votes. Not worth the trouble just to save two keystrokes. I'm also worried about what Blueboar points out with templates going from "optional"->"preferred"->"required" over time. In this case, it would threaten to undermine the already weak "discussion-not-vote" consensus process which worries me per WP:NOTAVOTE and meatball:VotingIsEvil. — Wug·a·po·des​ 22:20, 4 January 2021 (UTC)
    We could always have a bot auto-subst them (although it would clutter the page history). Enterprisey (talk!) 08:54, 5 January 2021 (UTC)
    @Enterprisey: I suggested that in the proposal. I could code up a bot to do so if needed. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)
    I left it vague, but to be clear, I think that's a worse idea for precisely the reason Enterprisey hints at. The last thing I want is a WP:COSMETICBOT roaming around making non-visible changes to markup and cluttering discussion diffs just to help powerusers save 2 keystrokes. It would probably also make people think they themselves ought to be substituting it which actually costs them 4 keystrokes compared to just using bare markup. — Wug·a·po·des​ 02:23, 6 January 2021 (UTC)
  • Support without the icon and with substitution to avoid transclusion limit. As other projects have implemented it, I have found myself trying the template before realize that here doesn't work. Alexcalamaro (talk) 23:59, 4 January 2021 (UTC)
  • O - or a bold S is simple enough or better yet, separate the sections like we do at RfA. Atsme 💬 📧 15:30, 5 January 2021 (UTC)
  • Oppose: or alternatively doing it properly, Hell no. I despise bolded words as a substitute to discussion and the lack of nuance of just going support or oppose is not to be encouraged. Spartaz Humbug! 19:58, 5 January 2021 (UTC)
  • Oppose. The convenience factor does not outweigh the barrier to newcomer participation created by use of excessive templates in simple discussions. --SmokeyJoe (talk) 00:19, 7 January 2021 (UTC)
  • Support I support anyone making and using almost any template, and the creation of templates rarely requires a vote or discussion. I must be misunderstanding something here. As noted above, we already have {{agree}} and {{meh}} which are similar templates that people can use or ignore. Why the opposition? No one is proposing to force or require the use of this template, so most people would either not know it exists or not care. Other Wikimedia projects like Commons use these templates, so it is understandable to me that if some people want to use it, then they might look for it across projects. In 2005 the template was deleted for use of images, but no one is proposing that right now. To a typical reader they would not know a template is being used at all.
I think the point of this discussion is that this template has been deleted ~10 times since 2005 because of prior use of images, but I see no harm or cost in having the template available for those who want to use it now. Blue Rasberry (talk) 16:25, 7 January 2021 (UTC)
  • {{weak strongest possible oppose}} Majavah (talk!) 18:51, 7 January 2021 (UTC)
  • Oppose: (1) It's not that hard to type the non-templated equivalent (2) It encourages !voting without !vote rationale, (3) It only increases the number of templates transcluded on discussion pages. Thanks! Plastikspork ―Œ(talk) 20:03, 7 January 2021 (UTC)
    @Plastikspork, you don't ever edit from a smartphone, right? We have editors above who say that it actually is "that hard" for them to type straight apostrophes ('). I think we can trust them that they struggle with this. WhatamIdoing (talk) 23:21, 8 January 2021 (UTC)
    Then type in all caps (as suggested above), which is even easier than finding the {} symbols. Thanks! Plastikspork ―Œ(talk) 23:30, 8 January 2021 (UTC)
    That's a good point. On my bog-standard Android keyboard ' is on the first page of symbols, { and } are on the second page. Additionally, when editing using the Wikipedia Android app there is a single button that automatically inserts the markup for bold text, there is no equivalent for templates. Unless iOS works very differently (I own no Apple products so can't check) then it seems very likely that templates being easier to insert than bold markup for smartphone users looks fallacious. Thryduulf (talk) 14:01, 9 January 2021 (UTC)
    @Thryduulf: Checking on an iphone (in a text application not in a Wikipedia app), ' is on the first page and { is on the second, but if I enter ' then the characters go back to the alphabet, while if I enter { then it stays on the second page, so it's easier to add a second {. Does android behave the same? Thanks. Mike Peel (talk) 17:31, 9 January 2021 (UTC)
    I just tried editing in the Wikipedia app on iPhone, and I see the same keyboard behavior there. Thanks. Mike Peel (talk) 17:33, 9 January 2021 (UTC)
    If there is a consensus to try to make it easier to enter bold or italic text without using a straight single quote, then I'd prefer it be done in a generic way for all text, not just specific words. Let's extend wikitext markup in some way, for example. Maybe something like @‘’’, @’’’, and other combinations of typographical quotes can be supported. isaacl (talk) 17:01, 9 January 2021 (UTC)
  • This is a textbook example of a solution looking for a problem. – Teratix ₵ 14:23, 10 January 2021 (UTC)
    Agreed. It's quite sad to see the amount of attention this is getting, while much more significant issues get crickets. {{u|Sdkb}} talk 15:21, 10 January 2021 (UTC)
    It's a simple solution to a problem I and others encounter regularly. I know others don't have this problem, but I am surprised at how many have gone out of their way to oppose this. Thanks. Mike Peel (talk) 16:06, 10 January 2021 (UTC)
    Mike Peel, perhaps we are not simply going out of our way, but instead many more people than expected felt strongly about this. (Similarly, User:Sdkb perhaps what you feel is significant is not the same as for others.) That does however not mean that its not a real problem, but perhaps instead that this is not the best solution. Personally, I wish I could have a panel of formatting/template shortcuts that I could customise to address a related problem I have with often forgetting specific template names (even if I use them regularly). --Xurizuri (talk) 11:33, 12 January 2021 (UTC)
    Xurizuri, significance is not some wishy-washy subjective value. Yes, assessments differ, but there are objectively things that have a big impact on readers and things that don't. The size of this discussion is perfectly indicative of our worst navel-gazey tendencies. {{u|Sdkb}} talk 12:37, 12 January 2021 (UTC)
  • Oppose per above. Likely to encourage voting behavior which would not harmonize well with enwp's consensus-based culture. -FASTILY 01:04, 12 January 2021 (UTC)
  • Oppose because this method of bolding is very simple. As someone that recently began editing, the vast numbers of templates have frankly been barriers to me engaging with some parts of WP thus far, particularly when there's no immediately obvious consistency in when people use one method or the other. And trying to remember all the templates and their parameters, and type them out correctly, is one of the biggest barriers from editing resulting from my ADHD that I've had. I would greatly prefer to not have more of either of those issues. The bolding and italicising are, to me, the simplest/easiest type of formatting we've got and making that more confusing is frankly not worth it. --Xurizuri (talk) 11:33, 12 January 2021 (UTC)
  • If the arguments about how very difficult it is to type straight apostrophes with a smartphone were being made in good faith, this would be a discussion about undeleting Template:Bold. —Cryptic 15:54, 12 January 2021 (UTC)
  • (Restored from archive as the RfC is still active. Thanks. Mike Peel (talk) 12:57, 22 January 2021 (UTC))
  • Oppose as a solution in search of a problem, and seconding Cryptic on the matter of bolding templates. Vaticidalprophet (talk) 04:59, 23 January 2021 (UTC)
  • Support per SmokeyJoe's comments. On Apple mobile devices such as iPhones or iPads, it defaults to ‘, and a good half-second press is needed for ', which is very tedious and seemingly time consuming, much more than typing {{}}. This would solve all the mistakes when mobile editors try to bold text. Using <b></b> isn't any better, as you would need to switch from the default keyboard to the symbols keyboard for the "<", then go back to the default for "b", then go back for ">", then back to default for text, then rinse and repeat with an additional "/". D🐶ggy54321 (let's chat!) 04:25, 1 February 2021 (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.

Delete Gadget and Gadget Definition namespaces

Latest comment: 3 years ago43 comments20 people in discussion

The Gadget and Gadget Definition namespaces are unused, have never been used, and have confusing documentation at Wikipedia:Gadget due to having never been used. Apparently, all relevant gadgets are in MediaWiki-space (for example, MediaWiki:Gadget-Twinkle.js). Considering this, there is no reason to keep the namespaces around.

Somewhat relevant:

If after five years nothing has happened, I doubt anything will happen with the namespace in the future. Elliot321 (talk | contribs) 20:25, 15 January 2021 (UTC) 

.mw-advancedSearch-namespace-2300, .mw-advancedSearch-namespace-2301,
.mw-advancedSearch-namespace-2302, .mw-advancedSearch-namespace-2303 {display:none !important;}
@Xaosflux: What do you mean by "some barely/un-supported technical debt that will likely break down in the future?" These namespaces have never been used on this wiki, aren't likely to be used in the future, and cause too many problems for the page Gadget:Invention, Travel, & Adventure. There are no archives to keep - unlike the Education Program namespace. I don't see any benefit in keeping these namespaces as they are currently unused and have never been used, and cause so many problems for every edit request to Gadget:Invention, Travel, & Adventure. I know that one page hanging out in the wrong place may not be that big of deal, but that's not the only problem readers face. There are problems in Special:Search as well. 54nd60x (talk) 14:29, 3 February 2021 (UTC)
@54nd60x: these namespaces are deployed to the 700+ WMF integrated projects, so making some special one-off configuration that is only for the English Wikipedia would mean an exception that has to be cared for indefinitely by the developers. — xaosflux Talk 15:08, 3 February 2021 (UTC)
  • Oppose, if it wasn't clear. The request is a non-starter; it's something we as a community can't do, and the people who can won't. Given that there is a sum total of one page across the entire enwiki that's affected by it (a redirect that does not require ongoing editing or maintenance), I don't see the benefit in a massive effort to change their minds. This is by far too much effort for not enough payoff for the wiki; I'd almost call it a solution in search of a problem. Writ Keeper ⚇♔ 14:50, 3 February 2021 (UTC)
  • Amusing how all this discussion and still the only repeated example above is one article, this gadget movie, not a particularly popular article by any metric either, nor do I think any readers care. I’m getting the feel that people just have an axe to grind with WMF/dev actions, tbh. There are far bigger problems, community caused, that nobody seems to care about doing anything about. ProcrastinatingReader (talk) 15:56, 3 February 2021 (UTC)
If my opinion wasn't clear enough, the reason I want to delete these namespaces isn't because of that one article, but because they have never been used and won't likely to be used in the future. So there's no use in keeping these namespaces if they are not used and won't be used. But @Xaosflux: was right, that the gadget and gadget definition namespaces are used on just about every wiki, so uninstalling those namespaces on enwiki would mean that an exception would have to be cared for indefinitely by the developers. Only Wikimedia Vote Wiki and Wikimedia Login Wiki I know of don't have these namespaces. 54nd60x (talk) 01:15, 4 February 2021 (UTC)

New template (a new way) to track how many times an article is listed at Portal:Current events

Latest comment: 3 years ago14 comments6 people in discussion

So Wikipedia has a template that is able to track daily page views and that template can be placed on any article when it is relevant or wanted by the community. I am proposing to create a template that can track the number of times and/or the dates when an article is listed on the Portal:Current events.

This would allow people to know when an article was relevant in the international/national news and this would also allow for people to know when an article most likely had a major update of content.

For example, Biden–Ukraine conspiracy theory was created during the first set of allegations. The article saw a massive spike in the number of views and number of edits. The number of edits/vandalism was so big that active arbitration remedies were placed on the article. After about a week, the articles edits died to almost none and a 23 day long request for a copy-edit took place. During those 23 days, only 4 edits were made to the article. About two weeks later, the article was back in the US national news, so the article had tons of new content being added.

Another example is the Sandy Hook Elementary School shooting happened in 2012. Of course it was a major thing in the international news, so it saw major content for the week or two that it was in the news. The article was slowly updated, but on December 12, 2019, the article was in the news against due to a trial. The article had 8 edits during that week alone, when it was getting maybe 4 edits a month.

Some articles never see the Portal:Current events, and some may only see it once. For example, 2019 Bagram Airfield attack only saw the portal 1 time and that was on the day of the attack.

If this is added, people could fairly easily find the dates when the article had new content added. It would also allow people to know how many times (or how many days in a row) the article was of importance in the world (or national importance).

Elijahandskip (talk) 15:11, 28 January 2021 (UTC)

That'd be good, providing it's easy to use & clear to understand.
Some major events which should be on CE never are, although I don't know how to solve that problem. Jim Michael (talk) 15:37, 28 January 2021 (UTC)
My mind is thinking of a copy/paste type template with some fill in spots that the editor adds, so it would be easy to use. Elijahandskip (talk) 17:37, 28 January 2021 (UTC)
I think this is a great idea.~~ 🌀𝕾𝖚𝖕𝖊𝖗 𝕮𝖞𝖈𝖑𝖔𝖓𝖎𝖈 𝕾𝖙𝖔𝖗𝖒 𝕮𝖔𝖗𝖔𝖓𝖆🌀 17:58, 28 January 2021 (UTC)
This is just more talk page cruft. When there are multiple discussions elsewhere about reducing how much Stuff is at the top of talk pages, this is not a socially-feasible proposal. Certainly not as its own template. Going beyond that, I doubt Portal:Current events drives much if any traffic at all. --Izno (talk) 20:41, 28 January 2021 (UTC)
@Izno: according to that daily page views, it gets about 60,000 views daily.Elijahandskip (talk) 21:03, 28 January 2021 (UTC)
"Drives" is a key word in context. --Izno (talk) 21:12, 28 January 2021 (UTC)
Why wouldn't it drive traffic? Many people read what's happened recently & click on the links to find out more. Jim Michael (talk) 22:48, 28 January 2021 (UTC)
But compared to the number of people coming in via Google, social media etc. it's likely insignificant. We need fewer templates cluttering up talk pages, not more. If for some reason you want to check when something was on the portal, it's easy to do via Special:WhatLinksHere/Biden–Ukraine_conspiracy_theory and filter to the Portal namespace. the wub "?!" 23:07, 28 January 2021 (UTC)
Being very honest, I am a 2 year Wikipedia editor and I have never seen that before. Highly unlikely 99% of that 60,000 even know what that is. But I would guess maybe 75% of them would click on the articles and maybe 30% of them would click the talk page of that article. That is at least a few thousand up to 10k. Elijahandskip (talk) 23:30, 28 January 2021 (UTC)
Besides 75% click-through from the portal being very unlikely, you're significantly overestimating readers' interest in talk pages as well. The number of views of the talk page is about 2% that of the article [9]. the wub "?!" 00:59, 29 January 2021 (UTC)
The featured article two days ago, The Holocaust in Slovakia, had a gracious 60k views. That's 1 in 100 clickthroughs from the main page, which gets 6-7 million (which is fairly high for recent TFAs). Let's assume that a secondary portal, though linked prominently with its own 60k pageviews, has a similar clickthrough. That's 600 pageviews a day from the one page.
No thank you to a new template. --Izno (talk) 06:40, 29 January 2021 (UTC)
A stronger argument is not that it drives traffic, but correlates with it—as in the examples given by the OP. It could still be useful for someone trying to work out what made the pageviews/edits spike. But I think this would be better as a tool of some kind than a talk page banner (even one minimized by default). "Track when page X was linked on page Y" would work for this use case (Y = Portal:Current events) and might plausibly be useful in other situations too. — Bilorv (talk) 20:55, 4 February 2021 (UTC)

An idea is to make it similar to how the ITN recognition that is placed on talk pages. Elijahandskip (talk) 22:21, 28 January 2021 (UTC)

Some countries aren't even protected!

Latest comment: 3 years ago4 comments4 people in discussion

While I was searching about Burma, I then went to Israel. It was "Extended-Confirmed". Then I went to the Malta page and it didn't have any protection! There should be a policy that all countries MUST have at least some protection on their articles.

Avishai11 (talk) 23:59, 4 February 2021 (UTC)

Avishai11, articles are protected only when it's truly necessary. You can learn more at WP:PP. Schazjmd (talk) 00:04, 5 February 2021 (UTC)
(edit conflict) @Avishai11: We do not pre-emptively protect pages; we apply protection when it is necessary to do so - persistent vandalism, for example. What kind of edits are you thinking of that protection would have prevented? --Redrose64 🌹 (talk) 00:08, 5 February 2021 (UTC)
Avishai11, like most Israel-Palestine related articles, the Israel article has Extended confirmed protection because of ArbCom enforcement. You can read about that here - WP:A/I/PIA. As for other country articles, they can be protected individually if they have persistent disruption. Otherwise it is not necessary. AVSmalnad77 talk 05:35, 5 February 2021 (UTC)
Latest comment: 3 years ago28 comments14 people in discussion

This task ([[10]]) destroys the information about which other wikis have relevant articles about the subject. For instance, if the article is created, and then one week later is deleted again, the {{ill}} link is gone and the work of the editor who originally placed it there is lost.

The reason for this odd behavior has been that the bot is computationally intensive. Now, the bot was recently given the ability to bypass this load. The idea is that an editor adds |display=force to the {{Interlanguage link}} when the English article exists. The template will then render as a regular blue link but retain the information about other wikis, so if that article is deleted, an editor can simply turn off the |display= parameter again. Of course, the bot itself should be this editor.

Another reason brought up is that {{ill}} create clutter in the editing window, but I see nothing worse than when you have a load of references interspersed in running text.

One argument is also that Cewbot waits one week before removing the {{ill}} links. But articles quite often take more than one week to go through PROD or AfD.

So should Cewbot remove interlanguage link templates once local articles exist?

I say there's gotta be a better solution that doesn't destroy the work of editors. CapnZapp (talk) 10:47, 22 January 2021 (UTC)

I should add that I brought this up at the bot's talk page but was shut down twice and told the Bot Noticeboard was a more appropriate place to have this discussion. Then that discussion was shut down and I was told to go to the Village Pump. So far I've complied, but this is the end of the line.
User talk:Kanashimi/Archive 1#Task 1 Convert interlanguage link templates with local article to wikilinks
Wikipedia:Bots/Noticeboard#Should_Cewbot_remove_interlanguage_link_templates_once_local_articles_exist?
CapnZapp (talk) 10:51, 22 January 2021 (UTC)
  • To answer the question in the headline, absolutely. --Izno (talk) 19:25, 22 January 2021 (UTC)
  • I wonder whether the conversion could be logged somewhere. Maybe a note on the edited article's talk page ("I changed {{il|French}} to Local" – please revert if Local gets deleted)? Maybe a note on the possibly-to-be-deleted article's talk page ("If you delete this, please go revert this edit by the bot")? Maybe a central log, which any interested editors could scan it for red links later? WhatamIdoing (talk) 20:38, 22 January 2021 (UTC)
  • Forum shopping is not OK. That said, perhaps the bot could run this task every month rather than every week to reduce the chances of article creations being subsequently deleted. Or better, the deleting admins could restore the interlanguage links while they are deleting the article. In general, it's better to link to a local language article where it exists, though. Thanks. Mike Peel (talk) 21:13, 22 January 2021 (UTC)
    • @Mike Peel:, CapnZapp was directed here by the BAG. No one at WP:BOTN supported stopping Cewbot, because no one saw any consensus to stop it. This RFC is a legitimate attempt as checking if C has C'd. There's also the possibility that while Cewbot still has a general consensus to do its task, the community finds its preferable to tweak certain behaviour. Headbomb {t · c · p · b} 05:18, 23 January 2021 (UTC)
      • Thanks for the background, I've struck that part of my comment. It still sounds like waiting a bit longer, or perhaps checking for deletion tags in the article to be linked to, would be an improvement. Thanks. Mike Peel (talk) 18:54, 23 January 2021 (UTC)
  • Yes it should. I also don't see any reason to change its one week delay, especially if it removal of {{ill}} is halted during an ongoing AFD/PROD discussion. Having logs could be a good idea though. Headbomb {t · c · p · b} 05:18, 23 January 2021 (UTC)
What does especially if it removal of {{ill}} is halted mean, Headbomb? It can very easily be more than just a week before an article even starts the PROD or AfD process, so arguing the bot respects that process (if indeed that is the case?) seems insufficient... CapnZapp (talk) 11:01, 25 January 2021 (UTC)
Articles may be deleted at any point, from seconds, to days, to weeks, to years after their creation. That something might potentially be deleted is not a valid argument against suspending basic maintenance tasks. Headbomb {t · c · p · b} 16:17, 25 January 2021 (UTC)
  • Yes Pointless wikitext makes editing the article more difficult. Having {{ill}} in some articles but plain wikilinks in others invites hapless gnomes to go round "fixing" one or the other. I don't think logs are warranted: just another unloved maintenance page to be ignored. All that is needed is an edit summary spelling out what was done (not each link) so it could be found in article history or the bot's contributions. Perhaps the bot could wait longer than a week from page creation. Johnuniq (talk) 06:06, 23 January 2021 (UTC)
    I'm arguing the wikitext isn't pointless. It was useful info added before the local article was created and this usefulness is exactly the same after it gets deleted. Having {{ill}} in some articles but plain wikilinks in others is just a hypothetical I'm having trouble taking in good faith. What has your conspiracies against "wiki gnomes" to do with my question and my arguments, Johnuniq? What do you mean by "plain wikilinks" in this context (I haven't mentioned any)? All that is needed is an edit summary spelling out what was done (not each link) so it could be found in article history or the bot's contributions. You appear to miss one step of reasoning - why would anyone think to check the edit summaries when the bot leaves no trace of anything to find - unless there's say, an editor comment of some kind: "here was once useful interlanguage links, check the page history for details"? I will note I haven't asked for any logs, so we're in agreement there. As of yet I haven't seen a single editor arguing why the bot should wait such a desperately short time, so, yes, waiting more than a week seems like one easy step to take, whatever else we agree on. CapnZapp (talk) 11:09, 25 January 2021 (UTC)
    One article might have a plain link such as [[Example]] while another has {{ill|Example|de}}. Johnuniq (talk) 00:27, 26 January 2021 (UTC)
  • Yes As per the comment above, pointless wikitext should be removed. Editing is difficult enough already for new editors. What would be the point of a log? How would it advance the project? Peter coxhead (talk) 07:33, 23 January 2021 (UTC)
No, that comment doesn't explain or justify why the wikitext is "pointless". (I invite you to be the first to actually start the argument, Peter coxhead) Personally, I don't find {{ill}} templates more difficult than a jumble of references/citations where it can be quite tricky to find the actual article text among the sea of reference parameters, and you don't see any bots obsessively messing around with them... I am not asking for a log, I am asking for a discussion wherein we don't just take cewbot for granted, but arrive at alternatives that don't erase information volunteered by editors. Cheers CapnZapp (talk) 11:13, 25 January 2021 (UTC)
@CapnZapp: if there's no article here, then {{ill}} is of some value. Once there is an article here, it isn't. The links to other language wikis are then provided via Wikidata. Yes, full references in text are also confusing, especially to new editors, which is why I always prefer the list-defined approach with the minimum reference in the text. But the argument that X is confusing so it doesn't matter if Y is as well isn't, in my view, convincing. We should remove as much complexity as possible. Peter coxhead (talk) 11:30, 25 January 2021 (UTC)
  • Yes. I struggle to think of a situation in which we'd need to retain an ill when a local article exists. If the article in the other language is better, just tag the English page with {{Expand language}}, which is plenty enough of a signal to readers that they might want to just use Google Translate. And if the article in English is created and then deleted as not notable, then it shouldn't have an ill as an ill is just a type of redlink and non-notable pages shouldn't be redlinked. {{u|Sdkb}} talk 16:40, 23 January 2021 (UTC)
To ease your struggle, I started the very first talk section with If an article is created, but later deleted (perhaps a person article that's deemed not notable enough), the ill link is lost and we have a red link instead. saying the bot actually destroys input added by editors (the existence of the foreign-language wiki article). Regards, CapnZapp (talk) 11:21, 25 January 2021 (UTC)

Let me respond to Mike Peel in a more prominent place since this is important. It has been very hard indeed to actually get a discussion started where people look at the bot's job critically and were we discuss alternatives that still accomplish what the bot set out to do but in a way that does not actively destroy the work of editors. I have mainly had to battle editors who focus solely not just on shunting the discussion elsewhere like a hot potato but actively shutting it down before arguments were even considered. Here seems to be the only place where there's nowhere else to point, so I look forward to an open-minded discussion which does not avoid the greater issue. With that in mind, thank you for striking that part of your comment, and thanks to Headbomb for highlighting the struggle to even start the discussion. CapnZapp (talk) 11:27, 25 January 2021 (UTC)

  • Yes The question contains an unstated supposition that "the work of editors" is somehow sacrosanct and "destroying" it is axiomatically a "bad thing". I don't believe this idea has any merit at all. In any case an "ill" link is intended to only be a temporary "patch" to cover a supposed hole in the 'pedia. Roger (Dodger67) (talk) 17:10, 25 January 2021 (UTC)
  • Yes. Removing an obsolete {{ILL}}, is helpful, and deletion of the article is not the expected/common path. The week delay should cover almost all speedy deletes, and that delay could be increased if we want to catch a higher number of AFD/PRODs. However we should not halt this useful work and obviously not permanently retain ILLs, just because an article might eventually be deleted. Alsee (talk) 02:20, 26 January 2021 (UTC)
  • Yes – good idea and would certainly be an example of a bot doing helpful "edits that would be extremely tedious to do manually". Can see no reason why we'd want the ill links to stick around. Aza24 (talk) 07:18, 26 January 2021 (UTC)

Two takeaways: 1. If the bot updates wikidata thereby retaining the information otherwise lost, that'd be sufficient. 2. Several posters have qualified their response by saying a longer waiting time could be useful. What would then be a more reasonable length of time for the bot to wait? Three months? More? Less? CapnZapp (talk) 09:22, 1 February 2021 (UTC)

  • Question. If {{ill|Example|simple}} and [[Example]] both result in Exemplum/Example.. then isn't this a cosmetic bot task? –MJL ‐Talk‐☖ 03:57, 5 February 2021 (UTC)
    With the parameters in your example, {{ill|Example|simple}} incurs the cost of one "expensive parser function" since it checks for the existence of the Example page on the English Wikipedia. davidwr/(talk)/(contribs) 04:05, 5 February 2021 (UTC)
    A cosmetic bot task is one that makes a change which has no effect on reader-facing aspects of the encyclopaedia. So, yes, this is cosmetic. Thryduulf (talk) 11:15, 5 February 2021 (UTC)
    Ah, but it does have an effect on reader-facing aspects of Wikipedia if removing an expensive parser function call will cause the formerly-501st expensive parser function call on that page to succeed instead of "failing because it was the 501st" and produce different output to the user. Therefore, it is not necessarily a cosmetic bot when used on pages that are already over the limit. davidwr/(talk)/(contribs) 19:54, 5 February 2021 (UTC)
    Also, it is effectively not a cosmetic change if it removes Template:Interlanguage link then the en-wiki page is deleted or changed into a redirect. Had the bot NOT run, the interlanguage link template would've shown a link to the other-language page as soon as the en-wiki target was deleted or changed into a redirect. So, I guess technically it's a cosmetic change at the time the bot is run, but it is effectively a non-cosmetic change in that if the bot runs AFTER the en-wiki link is deleted or changed into a redirect, the bot will skip it and the end result will be different for the reader. davidwr/(talk)/(contribs) 19:58, 5 February 2021 (UTC)

Bot to remove year of birth/death categories when the claim is removed from the article body

Latest comment: 3 years ago3 comments2 people in discussion

This proposal is related to an open bot approval request (BattyBot 53). AWB, as part of its current genfixes, will add birth/death categories (like Category:1980 births) to biographies that contain a birth/death statement in the article body (either the lead sentence or the infobox, I think). However, it seems no process exists to remove the categories if the corresponding statement is later removed from the article. An example of this problem is at Advaitha (actress): [11] adds an uncited date of birth, [12] (automated) adds the corresponding category, and [13] removes the date of birth as unsourced, but misses the category and it is left unsupported by the article, until manually removed by me much later.

I'm wondering if there is support for a bot to automatically remove these categories in this type of situation. Some additional thoughts, open questions, and potential objections:

  • The bot should only remove the category if a birth/death claim formerly existed in the article and was removed, not if the category was added without a corresponding claim ever being present. (This would lead to the bot directly reverting a manual edit, which is not my intention.)
  • To prevent edit warring, the bot should not remove a category from the same article multiple times, and could wait for some grace period (a day? a week?) before removing in case the removal of the claim itself was mistaken/vandalism.
  • Should the bot replace the category with Category:Year of birth missing or a related category, or just remove it?
  • "This would just result in multiple bot edits when there could be none. My watchlist and I hate bots with a passion." Yes, fair. The current situation, though, appears to be that these categories get added and are not always maintained. It is also possible that the category was originally added by a human, so this is not always a case of "bots reverting bots", but a bot cleaning up something a human missed.
  • "Not a good bot task, too situational." Perhaps. The bot could log these issues and not directly action them. Would anyone bother to check the log? Part of the justification for this proposal is to avoid unsourced BLP information, on which I believe we should err on the side of removal.
  • "The category should be automatically handled by the infobox/Wikidata, so there aren't multiple places to maintain this information." Maybe? This is a very different proposal. Not every article has an infobox, and not every {{Infobox person}} is in the lead section of a biography. There is frequent opposition to using Wikidata for this due to lack of review/quality sourcing.
  • "The category system is terrible." Yes, but this is a non sequitur. The category system exists and we must maintain it, particularly for BLPs.

Thanks. — The Earwig ⟨talk⟩ 16:29, 4 February 2021 (UTC)

  • My first thought is that this is a good idea, but as you say it needs workshopping a bit before implementation. For example, how will it cope if a duplicate year of birth/death statement is added and then removed, or the statement is changed without being removed (e.g. Born 1986 changed to Born 1987)? If it adds any categories it should be ones that are flagged as needing human review (perhaps "year of birth possibly missing" or something) - especially for deaths (we don't want living people in year of death missing cats). The bot will need to cope with people changing e.g. "born 1930" to "1930–2021" in a variety of formats. How will it cope with the year of birth/death being removed from the prose or infobox but not both? Maybe an edit filer for year of birth/death removed would be a good first and/or additional step? Thryduulf (talk) 02:30, 5 February 2021 (UTC)
    • Thanks Thryduulf, this is helpful. My original idea was to simply check whether the claimed year of birth/death is present in the page text or infobox at all, except for the category itself. It would be prone to false negatives, but seemed like a safe starting point for detecting situations where the category is completely unsupported. Of course, you are right to bring up the case where the year changes; I would be less comfortable about a bot doing something in that situation, but removing the category wouldn't be strictly improper? (I don't think I'd want the bot to change the category to the new birth year without human review.) Your comment on adding categories makes me think that it would be best to not add any due to uncertainty—a "year of birth possibly missing" category does not seem especially useful. I know there has been some prior discussion about the (lack of) utility of these. An edit filter is a good suggestion, but it might be difficult to build a useful one. I will think more about this. — The Earwig ⟨talk⟩ 08:44, 7 February 2021 (UTC)

Warn new editors before putting in a date-of-birth less than 18 years ago

Latest comment: 3 years ago9 comments7 people in discussion

Lately I've found and reported more than a handful of minors posting their own year-of-birth or that of a family member, or people creating drafts about non-notable teenagers complete with real name and date-of-birth.

I propose an edit filter for non-(auto)confirmed editors that that would throw up a warning recommending that the editor read Wikipedia:On privacy, confidentiality and discretion, Wikipedia:Guidance for younger editors, and WP:AUTOBIOGRAPHY before publishing anything that looked like a date of birth 5-17 years ago. This wouldn't prevent publication, but it would at least put some "friction" in the process giving the editor a chance to think about it. For obvious reasons, the filter should be set to "private" and edits that are saved anyway should be flagged for review by someone with visibility to that edit filter, as a fair number of them would likely need to be immediately WP:REVDELed away and referred to WP:OVERSIGHT.

I wanted to get feedback on the idea here before making a more formal proposal on Wikipedia:Village pump (technical) or Wikipedia:Edit_filter/Requested in case there's some good reason NOT to proceed.

It's not part of this proposal (first things first) but a similar proposal to flag new editors putting up email addresses or social-media links on user- and draft- pages and new-ish pages in other namespaces would also help cut down on naive users posting things that have to be cleaned up later. davidwr/(talk)/(contribs) 03:06, 27 January 2021 (UTC)

... in what context? Edit filters are not magical. --Izno (talk) 04:41, 27 January 2021 (UTC)
Moreover, this seems better for WP:VPI since you don't know what you want exactly. --Izno (talk) 04:43, 27 January 2021 (UTC)
I suppose we could flag new articles with Category:2004 births or later, but I doubt that editors unsophisticated enough to attempt to make articles on themselves or their family members of that age are adding birth categories. BD2412 T 06:20, 27 January 2021 (UTC)
It's impossible to make an edit filter totally private. The username and page title will always be visible. Are you sure you want to make a handy list of minor editors? Suffusion of Yellow (talk) 06:25, 27 January 2021 (UTC)
I'm sure I do NOT want such a list, at least not one that is visible to the public or unprivileged editors. I had forgotten about the limitations of the privacy features of the edit filter log. From re-reading the edit filter documentation, it looks like this is not currently possible in en-wiki. That said, in principle it looks like the edit filter extension could be "cloned" so there could be two independent groups of edit filters, one that is very locked-down to the point that its logs were invisible to most editors. That said, it's not the simple undertaking I envisioned, which makes my suggestion impractical at least in the short term. davidwr/(talk)/(contribs) 19:15, 27 January 2021 (UTC)
Yes, please move this to VPI. {{u|Sdkb}} talk 14:53, 30 January 2021 (UTC)

Many non-notable people (most of them young) have created articles about themselves or non-notable people whom they personally know. Even more have added their births to year and day articles. I can't work out a way to prevent this while not preventing articles & additions being made which are useful & justified. Jim Michael (talk) 15:40, 28 January 2021 (UTC)

The birthdatescammers!

Proof https://i.pinimg.com/originals/87/86/66/878666a2074787830017c0981de58e10.jpg --2A01:C23:7033:1D00:115B:35E7:3490:2E47 (talk) 13:02, 7 February 2021 (UTC)

Proposal: Add notable people when browsing Wikipedia in the WP:Contents page such as in WP:Contents/Overviews

Latest comment: 3 years ago2 comments2 people in discussion

All of the links in the contents seem to cover every part of the encyclopedia. The only part that seems to be missing is listing notable people like Jesus, Albert Einstein, Isaac Newton, Leonardo da Vinci, and Aristotle. All of the links with the exeption of meta's articles every Wikipedia should have and the vital articles list notable people. Please let me know what your thoughts are regarding this. I want to help improve browsing Wikipedia for people who prefer not to do a search. Interstellarity (talk) 19:16, 9 February 2021 (UTC)

Who says that someone's historical impact or fame (which I can only assume is the basis for the five figures you list) correlates with what people want to read on Wikipedia? Look at the page views for Trump compared these people [14] last year; I doubt he would be included in the list of Jesus, Leonardo, Aristotle etc. yet he receives significantly more attention from readers. I could understand having a most viewed articles section for the day or week (mobile already has something like this) but trying to create a list of people we're guessing readers consider the most "notable" seems impossibly arbitrary and serves no real purpose. Aza24 (talk) 23:46, 9 February 2021 (UTC)

Wikipedia as fact-checker

Latest comment: 3 years ago4 comments4 people in discussion

Hey, my name is Joey.

I think Wikipedia is great and would like to try to contribute to its success in the future.

Wikipedia is full of facts, making it a great place for research. It is also highly monitored, making it trustworthy. I think Wikipedia could fill another, in my opinion much needed, position in our modern society. Nowadays people have the option to post whatever they please on social media. I feel like a fact-checker, like the one Twitter recently implemented, is highly needed. I think Wikipedia could fill that role. The digital engineers behind the site could develop a system that would be able to check videos, text and images for how factually true it is. Then Wikipedia could strive to have a fact-check button implemented on every social media platform.

I think this is something that is indefinitely going to happen in the future and I think that Wikipedia would be the perfect organization to make it happen.

Thanks for listening to my idea. Greetings, Joey — Preceding unsigned comment added by 2001:1c04:3f14:6d00:5091:fa99:3bbc:f338 (talk • contribs) 13:09, 4 February 2021 (UTC)

Joey, please read about how Wikipedia is not a reliable source, or in other words, not trustworthy. We don't deal in truth, but in what can be verified. 331dot (talk) 08:03, 7 February 2021 (UTC)
  • The problem is that a fact checking system like twitter’s would likely violate our WP:No original research policy.
All we can do is ensure that our information is accurate, based on what reliable sources tell us. And sometimes, the reliable sources disagree. When this happens, our WP:Neutral point of view policy says we can not choose between them, but must present what the various reliable sources say (even if we, as individuals, think one side of the disagreement may be wrong). Blueboar (talk) 14:31, 7 February 2021 (UTC)
The English Wikipedia is already being used as a source of ground truth for fact checkers (including automated systems). If you are interested this subject, see Diego's talk at mw:Wikimedia Research/Showcase#December 2020. Whatamidoing (WMF) (talk) 05:18, 10 February 2021 (UTC)
Latest comment: 3 years ago14 comments7 people in discussion
The logo has been changed back. No need for further discussion. Interstellarity (talk) 19:17, 9 February 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.


 
see newer version down below

Recently the logo was temporarily changed to.....see image at right. In this case I'm proposing adding back 'The Free Encyclopedia' however with '20 Years over one Billion edits' the idea is that it is a milestone and hence would give even more credibility to the movement as its indicating how many years its been helping readers, and how many edits have been done--Ozzie10aaaa (talk) 19:15, 4 February 2021 (UTC)

@Coffeeandcrumbs, Valereee, and Armadillopteryx: who have very recent feedback on this on Talk:Main Page that I'm going to point to here. — xaosflux Talk 19:45, 4 February 2021 (UTC)
thank you(it could be 'more than')--Ozzie10aaaa (talk) 19:49, 4 February 2021 (UTC)
  • Support as proposer--Ozzie10aaaa (talk) 16:47, 5 February 2021 (UTC)
  • Oppose. Pretty much every reader knows that Wikipedia is a very popular and well-established website, so we don't need to use up the most valuable space in our layout (since people begin reading at upper left) to remind them of that fact. I'd rather we keep using the official tagline ("the free encyclopedia"), which at least says something about our editorial philosophy. {{u|Sdkb}} talk 05:10, 5 February 2021 (UTC)
what I propose is this same logo with "The Free Encyclopedia" as usual on it--Ozzie10aaaa (talk) 15:51, 5 February 2021 (UTC)
Ozzie10aaaa, if you're proposing a logo change at VPR, it's preferable to have an actual logo file in hand, so that this sort of confusion doesn't happen. You could request that at the WP:Graphics lab if you don't know how to make it yourself. Without knowing where exactly you'd want to place each piece of text, I have to continue to oppose, although if you came back with a file and it looks better than I expect it to, there's a slight chance I'd change my mind. {{u|Sdkb}} talk 07:28, 7 February 2021 (UTC)
ok its here  (Im not very good at images but you get the general idea)--Ozzie10aaaa (talk) 13:26, 7 February 2021 (UTC)
  • Support Until February 15th and then bring back the normal logo in march unless the WMF opposes this idea and wants us to keep using the normal logo before the 15th 🌸 1.Ayana 🌸 (talk) 11:27, 5 February 2021 (UTC)
  • Oppose We should stick with this one for a while more. Pretty notable milestone. Someone should really ping all of the editors who contributed to the previous discussion on this. ~ HAL333 02:54, 6 February 2021 (UTC)
HAL333 did you vote 'oppose' if your saying We should stick with this one for a while more. Pretty notable milestone....--Ozzie10aaaa (talk) 20:28, 8 February 2021 (UTC)
  • The back and forth logo changes are probably confusing to the average reader who notices. Though, I guess that is quite representative of Wikipedia’s consensus building process, so perhaps a good thing to showcase. ProcrastinatingReader (talk) 08:59, 7 February 2021 (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.
  • note this discussion was closed too soon as what was being discussed was merging to a new logo for a non-specific time..."the logo has been changed back" is not a valid reason to close as there are ongoing discussions on the matter(as seen above)...IMO--Ozzie10aaaa (talk) 18:11, 10 February 2021 (UTC)

mergers @ AfD (yes, again)

Latest comment: 3 years ago21 comments14 people in discussion
  Moved from Wikipedia:Village pump (idea lab)/Archive 34 § mergers @ AfD (yes, again)

Yes, I know it's a perennial proposal, and yes I've read over quite a few discussions in the past and yes I do feel times are different now. Mergers often stay open exorbitantly long times . This is not practical, and the system of proposed mergers is clearly struggling with low participation and interest (not to suggest that other areas aren't). It is more effective and efficient to nominate an article for deletion if you want it to be merged. Like it or not, that would seem to be a fact at this point based on my highly unscientific day-to-day life. See, for instance, 1 and 2, where unanimous consensuses were reached in a week-- this would usually take months to a year or more if you followed the 'correct' way of proposing a merge. Currently, some users will !vote "keep: a merger should be discussed elsewhere" and I'd argue that more often than not no discussion happens elsewhere.

I'm not suggesting completely folding PROPMERGE into AfD and I'm not suggesting necessarily renaming AfD to articles for discussion, I just think it past time that we seriously consider making 'merge' a valid option to start an AfD for. Is AfD exactly booming with participants? no, but I'd argue it's higher visibility than proposing a merger, the format works just as well better, and I highly doubt the number of new merges would overwhelm the system. We could always do a trial for X months and reassess... Cheers, Eddie891 Talk Work 23:22, 25 January 2021 (UTC)

  • To clarify I'm suggesting that we make merge an acceptable proposal to suggest when opening an AfD, but leave Proposed mergers as a functional place where people can still file proposals if they either feel that system would work better (perhaps for a sufficiently high traffic article) or if the AfD is closed as no consensus (but, of course, not 'keep' or 'delete). This would allow most merger suggestions to get more discussion (because of higher visibility) and closed faster (time limit of AfD) and may also have the benefit of more controversial Proposed mergers getting more attention because there are more manageable amounts. Eddie891 Talk Work 23:38, 25 January 2021 (UTC)
    Eddie891, I agree (as I hope everyone does) that the merge proposal system is clearly broken and needs some sort of reform. I'll leave it to others more familiar to decide whether folding it into AfD is the best approach, but I'm down to try something, and worst case scenario it fails and we return to the status quo.
    Since this is a developed, actionable proposal, you might want to move it to WP:VPR, as the idea lab isn't a place for !voting. {{u|Sdkb}} talk 03:18, 26 January 2021 (UTC)
  • I think we should redirect RMergers to AFD and be done with it. (Regardless of that opinion, we should also make it doubly clear somewhere on WP:Deletion policy and/or WP:ATA and/or WP:AFD/AI that not-votes like "AFD is not for merging" get kicked to the curb.) --Izno (talk) 03:58, 26 January 2021 (UTC)
  • Unless someone provides a good reason for the bureaucracy that is having completely separate and non-overlapping (by policy, if not practice) procedures for merging versus deletion versus draftication versus etc of articles, I agree completely that AfD should serve as a central point of discussion for any article that people feel should not be an article - be that "it should be a redirect" or "it should be merged" or "it's too soon so draftify". -bɜ:ʳkənhɪmez (User/say hi!) 04:09, 26 January 2021 (UTC)
  • I have concerns about the actual execution as well as diluting AfD participation with large numbers of merge articles. While the discussion and closing don't take too long, merging requires a lot of execution effort. I don't do AfDs that have a merge close likely result since I don't want to merge them, and without someone agreeing to do it (say, the nom), it risks the close of discussions without actual merging being carried out on a reasonable timescale. Nosebagbear (talk) 10:15, 27 January 2021 (UTC)
    Even in that scenario though, you still get a decision and anyone can act without sitting in ambiguity. And that decision is timely, and it's visible on the article that the article is long in the tooth. RFM is like AFC except it can be years rather than months before you know. --Izno (talk) 18:28, 27 January 2021 (UTC)
    What plays the biggest role in diluting AFD is when users go on large nominating sprees of 20+ articles in a single day. So far in january there have been 200 proposed mergers, or about seven a day. I don't see adding those to the 100+ AFDs regularly nominated each day as holding the potential for overwhelming that process. Eddie891 Talk Work 18:35, 27 January 2021 (UTC)
    @Eddie891: I wouldn't say that reasoning is entirely cast-iron. You'd like this change because it would make it easier to get merges to happen, presumably encouraging more. That would logically bump up the figures far more than the 7/day (which would be notable, but certainly tolerable). If it didn't bump it up, then the change would probably not be worth making. Nosebagbear (talk) 10:35, 29 January 2021 (UTC)
  • I have been editing WP since 2006... and I didn’t know a separate Merger process even existed! It certainly was not advertised widely (When was it created?) I have no problem dealing with contentious merger proposals through AFD. Why do we need two separate bureaucracies? Blueboar (talk) 13:19, 27 January 2021 (UTC)
    Probably because it's listed somewhere in PEREN. :^) --Izno (talk) 18:28, 27 January 2021 (UTC)
  • Comment: The general Articles to be Merged backlog is now below 12 months (this used to be 2.5+ years), and the AfD resulting in Decision to Merge backlog is again below 90 days and rapidly being reduced. Just so you know. Anyone who wishes to help out, you now have the links to do so.   Regards, GenQuest "scribble" 18:50, 27 January 2021 (UTC)
  • Comment, I have similar concerns to Nosebagbear but I see merit in the idea that likely contested nominations could be nominated at AfD with the nominator proposing a merger. I would however oppose anything that would prevent editors from conducting bold mergers/redirects (obviously bold deletion is unavailable to most of us, for good reason), if contested they could then be formally nominated (as is currently the case). Cavalryman (talk) 11:50, 29 January 2021 (UTC).
  • I've never really understood why they're separate. If anyone wishes to only watch for deletion discussions or only watch for merger proposals, that can be handled via one of the several ways we already organize AfDs. AfDs don't get lost in talk page archives, are more centralized, and have a structure that can already result in merger. I say take this opportunity to reduce our number of complicated processes. Or perhaps try it out for a while? — Rhododendrites talk \\ 02:42, 30 January 2021 (UTC)
  • Oppose Let us count the ways:
  1. Mergers are inherently unproductive because they just move content from one page to another with low value-added
  2. Mergers can mostly be done by anyone using ordinary editing tools, just as anyone can add, remove or move a section in an article
  3. Deletion however is a specially restricted function because it makes the content inaccessible and is not easy to revert
  4. AfD exists primarily for deletion, providing the clear consensus required for admins to use this specially restricted function
  5. AfD is moribund too because it's no fun looking at junk
  6. The longer the AfD list, the less likely that people will look through it and so participation will decline further
  7. Already we see lots of AfD discussions being relisted again and again for lack of participation
  8. AfD tends to attract zealots who tend to vote delete as a knee-jerk reflex, without regard to the merits of the topic and its potential
  9. The proposal therefore risks turning mergers into deletions and content will be lost
  10. There are technical limits on the size of the daily AfD logs due to their heavy use of templates
  11. The AfD process doesn't scale - neither technically nor in its human factors
  12. The proper place to get attention for mergers would be projects staffed by subject-matter experts
  13. But projects are dying too
  14. The main reason that everything is dying is excessive assholery, battleground behaviour, busywork and conflict
  15. We need to focus on fostering collaboration, cooperation and content creation rather than finding new and better ways to annoy each other
Andrew🐉(talk) 08:21, 30 January 2021 (UTC)
  • I agree with merging merges into AFD. One place to discuss what happens to a stand alone page (delete, draftify, merge, etc) seems to make the most sense and will avoid the duplication of effort and dilution of attention that happens now with multiple processes. Levivich harass/hound 15:15, 4 February 2021 (UTC)
  • Support folding it into AfD Didn't even know WP:PROPMERGE existed (note, most merge discussions I've closed on WP:ANRFC didn't use such a process either but were just regular talk page discussions). Looks like a useless process to me. Personally I'd have taken "blank-and-redirect" type merges into AfD anyway. It's a centralised venue which achieves conclusive outcomes, whereas many talk page discussions take far more weeks and still end up with minimal participation. I dislike that some admins refuse to acknowledge merge consensus imo, with the rationale that AfD isn't for merges, even if the AfD reached a consensus for merge. That part seems to be dependent on the closing admin (some allow it, others don't and say "can be discussed elsewhere", from what I've seen). ProcrastinatingReader (talk) 16:06, 4 February 2021 (UTC)
  • Support The only place where such a discussion will get any attention at all is AfD--though participation is lower than it should be, it's still the best-attended of such processes. Since merge has in the past been used as a surreptitious method of deletion by calling it a merge, but not actually merging anything substantial, it makes sense. We should probably specify that the action in such discussions if there is no participation is not the soft delete we use for articles, but merge, as undisputed. Both are easily reversible if challenged. As Levivich says, the virtue of AfD is that if disputed, it comes to a conclusion. Yes, AfD tends to attract people who try to find reasons to vote delete, but it also attracts those who seek every possibility for keep. Those in each party have always been sure they were a struggling minority. I'm not sure how that would translate into merges--each side sometimes suggests it to find a compromise solution. Merges are not unconstructive--they move the information, but they remove the often extensive duplication and all the overhead associated with being a separate article.~~
  • No, AfD often does not come to a conclusion. Many times, AfDs are closed as no consensus. Or a supposed consensus doesn't stick. For example, today I closed an AfD. Notice that there had been 8 previous discussions! And notice that no-one suggested merger of the subject into Kennedy family, even though this was an obvious alternative. AfD encourages the adversial extremism of Keep/Delete rather than more complicated compromises. Andrew🐉(talk) 23:47, 11 February 2021 (UTC)
Eddie891, As a regular at AfD, I have no problem with a merge result, nor with a nominator proposing merge as one of the alternatives. And you are right that merge discussions are much slower. However, we should not just convert merges into AfD discussions as obviously the process is for deletions, not merges. What we need instead is an AfD like process, where merges are listed in a central directory, sorted, and gain more visibility than they do currently. Piotr Konieczny aka Prokonsul Piotrus| reply here 11:57, 12 February 2021 (UTC)
  • I don't understand why we have so many policies for merging, AFD, Prod it is just mad. New users find it difficult, and I have been on and off Wikipedia for several years and still finding stuff because it's not the easiest of layouts. I stated on a previous AFD policy that I think Prod should be done away with, and Merger should be integrated into the AFD policy and process, making it simpler for users to find and discuss. I know Andrew has commented about poor quality of some mergers, but this should be made part of AFD process i.e. If editors decide a concensus to merge, then it should be then left open to discuss level of merger. Davidstewartharvey (talk) 16:03, 14 February 2021 (UTC)
Latest comment: 3 years ago19 comments8 people in discussion

Should we indicate by color code whether a link to a website has an SSL certificate? For example, Wikipedia shows a box/arrow that is blue. That's good because it is https. However, a site like CI, which has no SSL certificate and connects as http has the same color (blue) box/arrow. I suggest we turn that red. Charles Juvon (talk) 00:19, 11 February 2021 (UTC)

I think they could be coded to display a lock to show it is a secure connection. I remember seeing this on FANDOM. Aasim (talk) 04:27, 11 February 2021 (UTC)
I don't know what you two are talking about; I'm using Firefox 52 (yeah, I know) on Vista (can't help it) with the Modern skin, and I see a yellow lock next to the blue link for Wikipedia, and a blue box with an arrow coming out of it next to the blue link for CI. If I saw a red link, it would make me think a wiki target didn't exist, so it'd be confusing. IOW, for me, the "problem" is already solved. Ergo, no, we don't need to add an unexpected color to our hyperlinks. — JohnFromPinckney (talk) 06:29, 11 February 2021 (UTC)
JohnFromPinckney, Modern is not a maintained skin beyond what it takes for it to function from a PHP perspective. Don't use it if you want to have a good representation of what most people see today. (I am minded to hunt down the relevant CSS and have it removed if it still displays as such.) --Izno (talk) 15:29, 11 February 2021 (UTC)
Thanks for the tip, Izno. But: how am I supposed to know that? I was using Vector, but several things (Alerts, Notifications, show/hide on collapsed items) stopped working, so I tried one of the four other skins in my Preferences list. Modern didn't exhibit any of those problems, so I thought I was up to date. And besides: "Modern". IYKWIM.
And now, it seems that my obsolete skin is more functional (in terms of http/https icons) that what other WP users use. So I'm totally confused. — JohnFromPinckney (talk) 15:49, 11 February 2021 (UTC)
JohnFromPinckney, to answer the question in your edit summary, Modern has been a skin for at least a decade and offhand I believe it predates Vector. The name "Modern" is just a 'pretty' name. --Izno (talk) 15:59, 11 February 2021 (UTC)
I'm calling my lawyer to see about suing for false advertising. I require a remedy for the mental anguish I've endured... — JohnFromPinckney (talk) 16:03, 11 February 2021 (UTC)
Oh rats, here I was hoping I wouldn't need to block you for using Firefox 52 on Vista. C'est la vie. --Izno (talk) 16:08, 11 February 2021 (UTC)
Don't block me for using Vista; it's not my fault and, trust me, I'm suffering enough. You should block me for WP:THREAT. ;-) — JohnFromPinckney (talk) 16:20, 11 February 2021 (UTC)
Enforcing actual policy? Sounds like bologna. --Izno (talk) 16:29, 11 February 2021 (UTC)
I do not anticipate a change here. The previous differentiating "lock" for HTTPS was removed because they had become noise to most people (most sites were migrating or had been migrated to HTTPS by that time). They were removed in 1.23/1.24, nearly 7 years ago. It would be just as noisy for us to add something to unsecured links. Moreover, some websites do not keep up their actual certificates, so at best we are linking to something with HTTPS in the scheme but which we can only guess as being secured. Bad idea overall.--Izno (talk) 15:29, 11 February 2021 (UTC)
@Charles Juvon: You can change it for yourself only. This is the CSS rule to put in Special:MyPage/common.css: 
/* Blue padlock for secure links */
#bodyContent a.external[href ^="https://"] {
  background: url(//up.wiki.x.io/wikipedia/commons/0/00/Lock_icon_blue.gif) center right no-repeat;
}
With this rule, links to https: sites will get a blue padlock, links to http: sites will retain the arrow-out-of-box icon. --Redrose64 🌹 (talk) 16:39, 11 February 2021 (UTC)
We should prefer HTTPS links, but it's not important enough to the average reader to justify the extra visual clutter. It would be better to have some sort of bot or userscript that can change/highlight HTTP links for editors who opt-in (if it doesn't already exist). – Joe (talk) 16:46, 11 February 2021 (UTC)
For most common/big sites, MediaWiki does an automatic transform of HTTP to HTTPS since a year or two ago. There is additionally a bot for that to change the wikitext. RR above provides the perhaps-desired CSS for indicating which are secure; one could change it trivially for the reverse case. --Izno (talk) 17:10, 11 February 2021 (UTC)
Thank you all for considering my proposal and discussing it in such an informed manner. Special thanks to @Redrose64: for the CSS rule. I remain concerned about our readership. Most know not to click a link in spam email, but they might not expect WP to send them off to a bad site. There is another issue: Recently, I obtained an SSL certificate for my personal website. I had to remove every single http link in my site to obtain a certificate. So, I assume, there is an exception for large well known sites like WP. Is that correct? Charles Juvon (talk) 17:32, 11 February 2021 (UTC)
That's not a requirement to get an SSL/TLS certificate for anyone... where did you get it from? How could it possibly be enforced? Anyway, something like 10% of major websites still use HTTP, so it's not intrinsically dangerous to follow a link to one. Wikipedia itself has enforced HTTPS for years and I don't think it's our responsibility to point out that other websites don't; most people using a modern browser will already see a warning. – Joe (talk) 10:42, 12 February 2021 (UTC)
Agree with Joe. No need for Wikipedia to provide this clutter. This is a problem for browsers. Lack of TLS isn't inherently dangerous anyway. ProcrastinatingReader (talk) 00:18, 13 February 2021 (UTC)
@Joe Roe: I am not at SSL expert, but I definitely had to remove all http links from a Yahoo Business website as per their policy. Our own article on TLS is rather complicated, and it references many sources including this. Perhaps one can conclude that individual web hosting services are setting policy. Charles Juvon (talk) 17:45, 13 February 2021 (UTC)
@Charles Juvon: nothing in the document you linked to says anything about need to remove HTTP links to obtain a certificate. It says nothing about the requirements to obtain a certificate at all. All it says is that if you use HTTP resources on your site, browsers and other tools may warn that your site is insecure or has mixed content. Note that despite some confusing wording, this refers to resources only i.e. files that need to be loaded to render the page e.g. images (with <img> or whatever), fonts, scripts. It doesn't refer to hyperlinks (<a href> etc) on a website to other pages or websites. (I.E. Other sites or pages that may be loaded by the end user clicking on them, but which aren't loaded to render page.) Also, the very fact they mention this means it's possible to obtain a certificate even with insecure resources, let alone links. Otherwise you could never have a mixed content site. Nil Einne (talk) 17:23, 14 February 2021 (UTC)

Topic blocks to complement topic bans

Latest comment: 3 years ago11 comments8 people in discussion

Now that we have the capability of blocking editors from editing specific articles, is there a way that we can bundle together all articles within a specific topic area (e.g. post-1992 American politics, COVID-19, Beyoncé) so that an editor who has been topic-banned from editing in those areas could in fact be blocked from editing pages deemed to fall within those areas? BD2412 T 21:19, 8 February 2021 (UTC)

Thought about this before, and imo it seems to be technically infeasible. There's no special way to determine whether an article is really within the AP2 editing area. There are talk page DS notices ({{Ds/talk notice}}), but anyone can place that so relying on it would be problematic (eg I'd be able to place that notice on a random article to block people from editing it. highly likely to be abused). Of course, this assumes that the page blocking functionality could work with categories or templates, which it can't. ProcrastinatingReader (talk) 21:26, 8 February 2021 (UTC)
Another problem is articles that include both content under the ban and content not under the ban. For example, the article for any year since 1992 is going to include both AP2 and non-AP2 content. signed, Rosguill talk 21:30, 8 February 2021 (UTC)
I had two thoughts for specific approaches. One would be by the category tree where the Tban is specific to something like a country or a musical artist. The other would be to manually construct a list on a protected page in project space and reference it. An actual block on editing would likely only apply to pages squarely within the Tban. BD2412 T 22:18, 8 February 2021 (UTC)
I don't think the DS notice is an issue - if someone places those maliciously, it just gets reverted (obviously if someone topic-banned hit an invalid one they would immediately raise the issue on WP:ANI or WP:AE or wherever is appropriate) and the user who placed it sanctioned if the maliciousness is self-evident. It's generally clear-cut so it wouldn't be an issue. The issue with articles that contain things both inside and outside the topic area is harder to deal with, though. --Aquillion (talk) 21:52, 15 February 2021 (UTC)
  • I believe there was an RFc before pblocks were implemented discussing this and "category" style pblocks being too easy to game...CUPIDICAE💕 22:31, 8 February 2021 (UTC)
    See m:Community health initiative/Partial blocks#Category blocks for more information about that approach. Whatamidoing (WMF) (talk) 05:47, 10 February 2021 (UTC)
    The issue with category blocks is really twofold. Anyone can add them, anyone can remove them. Which de facto gives anyone the ability to block certain users (eg I can add American Politics to this page. It might be quickly reverted, but still). The third issue is that the idea of a protected page / admin list may be infeasible. I’m not sure admins could really maintain their own list. Maybe they could get a category list at a given time, skim check it over and then add it to the protected page, which will at least be mostly complete. But mostly I’m not sure this is a problem. I mean, topic ban evasion isn’t hard to identify. People are usually quick to report each other to AE for even the slightest violations. ProcrastinatingReader (talk) 06:39, 10 February 2021 (UTC)
  • As touched on above, this is a nice idea on paper but would just create more issues. ~ HAL333 22:18, 10 February 2021 (UTC)
  • It would need to be done on a case-by-case basis and would require a code change, but it is do-able. One way to do it would be to get rid of the low limit on page blocks, which I think is 10 or something like that. If this were a very high number - say 5000 - then in most cases it would be easy enough to generate a "snapshot in time" list of pages from categories, manually filter out the obvious "false positives," then page-block the person from all of those pages. This would make for very long block logs though, but it is do-able. It won't work for "mixed content" pages though, where the topic-ban, even "broadly construed," only covers part but nowhere near all of the content of a given page. I don't see any easy way to enforce that in software without over-kill. It also would do nothing about pages that aren't properly categorized or which don't exist yet, but which are covered by the topic-ban. Bottom line: I think it's a good idea, if you accept the limits involved and don't consider it a magic bullet to enforce topic-bans. davidwr/(talk)/(contribs) 22:29, 10 February 2021 (UTC)
    I haven't been directly involved in any of the partial-block work, but from what I've overheard, being able to partial-block someone from 5,000 pages is unlikely to be acceptable to Ops for performance/database reasons. Whatamidoing (WMF) (talk) 21:40, 15 February 2021 (UTC)

Adding a reply button on all talk pages.

Latest comment: 3 years ago7 comments6 people in discussion

I believe this will help many beginner editors. When you click it you just type a message and then it automatically puts your signature. SoyokoAnis 19:21, 12 February 2021 (UTC)

This is part of the WP:Talk pages project. There's an ongoing discussion about experiences using the tool here. ProcrastinatingReader (talk) 19:23, 12 February 2021 (UTC)
It's an excellent suggestion that everybody wants. In addition to the Talk pages project tool linked to above, there is a script, User:Enterprisey/reply-link, that you can install. Levivich harass/hound 21:13, 12 February 2021 (UTC)
Which doesn't allow an edit summary, so I don't use it. Doug Weller talk 19:58, 13 February 2021 (UTC)
It can be configured to allow an edit summary to be entered. isaacl (talk) 23:06, 13 February 2021 (UTC)
Almost nobody actually types meaningful manual edit summaries on talk page edits, and even the editors who use the edit summary option the most on talk pages will use pointless edit summaries such as c (meaning "comment") on occasion. Whatamidoing (WMF) (talk) 21:50, 15 February 2021 (UTC)
Sure; I was just addressing Doug Weller's issue. Looking at that editor's contributions made me think that admins are probably more likely to use edit summaries on user talk pages in order to explain their actions. isaacl (talk) 22:33, 15 February 2021 (UTC)

Adding more information in templates

Latest comment: 3 years ago4 comments4 people in discussion

Dear editors and others of Wikipedia. Forgive me for I am new to this site. I have enjoyed using Wikipedia for as long as I can remember. However, after visiting the site so many times, I feel that somethings are missing. For those who don't have time to read every single piece of information on some historical or current leader. politician, etc, etc. They don't know how to get this information. I propose a couple of ideas for the templates.

Ideas

What I am proposing is this.

Tenet: Progressive, Neutral or Conservative

With this, users and those visiting the site can learn what their favorite historical or current leaders' tenet is.

For example. These are just a couple of historical individuals to give you an idea.

Progressive: Oda Nobunaga, Qin Shi Huang, Date Masamune and Cao Cao.

Those who wish to move forward towards a better future and life.

Neutral: Sun Quan, Sanada Yukimura, Zhang Liao, Minamoto no Yoshitsune and Tokugawa Ieyasu.

Those who wish to join neither side whether it be a conflict, war, religious matter, etc, etc.

Conservative: Adolf Hitler, Takeda Shingen, Liu Bei and Zhuge Liang.

Those who wish to stay in the past and protect old traditions.

Ideals: Ambition, Fame, Talent, Family, Determination, Mastery, Greed, or Justice.

Fame: Those who wish to obtain as much glory and status as possible.

Ambition: Those who have big ideas for the future and the world.

Talent: Those who wish to show their talent and make themselves known.

Greed: Those who wish to achieve everything they want by any means.

Determination: Those who wish to achieve their goals with any opportunity that comes or is available.

Family: Those who goals are solely to ensure that their family, clan, business, etc, etc, stays strong and endures.

Justice: Those who wish to make sure evil does not prevail and to protect those whom they love.

Mastery: Those who wish to continue to prefect their craft whether they are a swordsman, priest, blacksmith, merchant, etc, etc.

With this, users and those visiting the site can learn what their favorite historical or current leaders ideals are.

Fame: Shimazu Yoshihiro and Minamoto no Yoshitsune

Talent: Toyotomi Hideyoshi and Kuroda Yoshitaka.

Greed: Dong Zhuo, Tokugawa Ieyasu, Matsunaga Hisahide and Lu Bu.

Justice: Sanada Yukimura, Hosokawa Tadaoki, Liu Bei, Zhuge Liang and Zhao Yun.

This give you an idea.

Tier: C, B, A or S.

With this, users and those visiting the site can learn what their favorite historical or current leaders tier.

S: Cao Cao, Oda Nobunaga, Zhang Liao, Imagawa Yoshimoto, Zhuge Liang, Qin Shi Huang, Minamoto no Yoshitsune and Toyotomi Hideyoshi.

A: Kuroda Yoshitaka, Miyoshi Nagayoshi, Hosokawa Tadaoki, Akechi Mitsuhide and Shimazu Iehisa.

This gives you an idea.

Rebellious: 1 ~ 15

14: Date Masamune and Ōtomo Sōrin.

13: Miyoshi Nagayoshi.

12: Oda Nobunaga, Toyotomi Hideyoshi and Kuroda Yoshitaka.

11: Imagawa Yoshimoto.

This gives you an idea.

If these ideas are added to templates, it should help users and newcomers learn must faster and more efficiently on what or who they wish to learn about. It doesn't have to just apply on people, but policies, groups, organizations or whatever it can be applied to.

This is what I propose to help Wikipedia help those who want to known this type of information is essential to any avid leader or newcomer. Like with everything, Wikipedia must move forward. If not, those who do not are doomed to fail. That is all I have to propose at the moment. — Preceding unsigned comment added by Azuchi1579 (talk • contribs) 10:34, 26 February 2021 (UTC)

Why would need this? There's a search bar. And what templates are you talking about? Lettlerhello • contribs 20:56, 27 February 2021 (UTC)
It would be a gargantuan task to class all article subjects according to their ideals without violating WP:NPOV; managing the inevitable editwarring and POV-pushing would require ten times more effort, to say nothing of the complaints and lawsuits from article subjects angry that they've been classified as "greedy" or put in the same tier as Hitler. I couldn't think of a better way to drive Wikipedia into the ground. – Teratix ₵ 04:52, 28 February 2021 (UTC)
I'll do my best not to bite here– but Wikipedia can't appeal to the lowest common denominator. Our apologies if you can't read the whole article, but usually, if the political beliefs of someone are notable, they'll be included in the lead or a relevant section. Also, this would be impossible to do without violating WP:NPOV. theleekycauldron (talk • contribs) (they/them) 23:41, 1 March 2021 (UTC)

Notification of an RFC

Latest comment: 3 years ago1 comment1 person in discussion

Users may be interested in the RFC at Wikipedia talk:Page mover/delete-redirect § RFC on granting delete-redirect to page movers. Thanks, -- DannyS712 (talk) 23:29, 18 February 2021 (UTC)

Science Photo Competition 2021 Russia targeting CentralNotice banner

Latest comment: 3 years ago1 comment1 person in discussion

On Marth 1, the «Science Photo Competition 2021» 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) 11:43, 21 February 2021 (UTC)

New speedy delete criterion (Not for Wikipedia)

Latest comment: 3 years ago15 comments9 people in discussion

This AfD could have been resolved earlier if there was this criterion. It was clearly not for Wikipedia, and it was a WP:SNOW anyway. The text should read as follows:

Ax. Not for Wikipedia.

Pages which qualify under Not for Wikipedia as not for Wikipedia. (templates)

-or something to that effect. This should be numbered A12. Please consider this, as it will help avoid future unnecessary AfDs like that. AnotherEditor144 talk contribs 21:56, 14 February 2021 (UTC)

Just let the process work out. It will be gone within a week. --Malcolmxl5 (talk) 22:18, 14 February 2021 (UTC)
Clearly not for Wikipedia is far too broad and subjective for a speedy deletion criteria. I'm a little more sympathetic to AFD snow as a speedy deletion criteria, except for the issue that sometimes it can be a while before someone comes along and does the legwork to find spources and save an article. ϢereSpielChequers 22:45, 14 February 2021 (UTC)

CentralNotice proposal for International Women's Day

Latest comment: 3 years ago16 comments10 people in discussion

A proposal has been made to run a CentralNotice banner for both anonymous and logged-in users from March 1-10 for International Women's Day, highlighting gender gap issues. The proposal is at m:CentralNotice/Request/Int. Womens day 2021. --Yair rand (talk) 11:36, 22 February 2021 (UTC)

I'm only a man, but can somebody tell me when International Women's Day is? You know, a date? Neither of those two links tell me when this damned thing is supposed to be. I guess all the women already know it, but if we're all supposed to celebrate it, or it's supposed to mean something, why is it kept such a big secret? — JohnFromPinckney (talk) 02:09, 23 February 2021 (UTC)
International Women's Day is 8 March. --Malcolmxl5 (talk) 02:25, 23 February 2021 (UTC)
Maybe the reason all the women already know when it is, is because they tried clicking the links, or reading the first sentence of International Women's Day. ¯\_(ツ)_/¯ Levivich harass/hound 02:29, 23 February 2021 (UTC)
If you don't fancy Google, then there is this nifty online encyclopaedia that has articles about things like this and much more. It's called Wikipedia, you might even have heard of it? Anyway, you can find their article at International Women's Day, and in the very first sentence it says International Women's Day (IWD) is celebrated on 8 March every year around the world. it's got a citation and everything! Thryduulf (talk) 02:32, 23 February 2021 (UTC)
Yes, friends, thanks for providing the actual date along with the snide remarks. I was 98.3% sure somebody was going say, "but it's right there in big <color> letters!", and I had just completely overlooked it. And yes, I could have googled, or looked directly for a WP article on International Women's Day, but I foolishly followed the provided link to International Women's Day, thinking (sort of on autopilot) that that must be it.
And while it's good and right that International Women's Day (the unlinked one) included the date, I still think two other pages which make a big deal out of "International Women's Day" would at least mention when it is. You know, for us ignorant people who might learn something. I know when Christmas Day and the Fourth of July and New Years Day are, but I haven't learned IWD yet. Or maybe I'll know it now. — JohnFromPinckney (talk) 04:20, 23 February 2021 (UTC)
Second link in the OP, top of the page: One global banner for International Womens day 2021, available for all gender gap activities around the 8th of March. Levivich harass/hound 04:27, 23 February 2021 (UTC)
Ah, now I see it. Still took me a whole minute, even with your directions. Thanks. — JohnFromPinckney (talk) 04:36, 23 February 2021 (UTC)
You're welcome. As a man, I'm proud you even asked for directions. Levivich harass/hound 05:52, 23 February 2021 (UTC)
International Men's Day is 19th of November. Emir of Wikipedia (talk) 21:51, 23 February 2021 (UTC)
Well, shoot, everybody knows that. Minor, finicky detail: I didn't know there even was a International Men's Day. — JohnFromPinckney (talk) 22:47, 23 February 2021 (UTC)
This is not advocating for a cause, this is a notice bringing to our attention several events aimed at filling in gaps in the encyclopedia. --Malcolmxl5 (talk) 15:35, 25 February 2021 (UTC)
Reiterating support for this central notice. You may disagree with advocacy, but worth noting English Wikipedia in general has done advocacy e.g. Wikipedia:SOPA initiative, and while not community sanctioned, the Wikimedia Foundation sued NSA. This event itself is not advocacy and most concretely is a call to improve content on Wikipedia. Shushugah (talk) 15:49, 25 February 2021 (UTC)
I try to avoid where possible much celebration of such days, because they often serve as excuses to ignore relevant issues for the rest of the year, but if this encourages people to take part in events that aim to improve Wikipedia then I see no reason to oppose it. It is not advocacy, as in telling people what they should think, which I do oppose. Phil Bridger (talk) 16:32, 25 February 2021 (UTC)
  • I believe that the actual proposal for the banner has been made on meta. The original post by Yair rand above contains a link. Probably editors wanting to express support/oppose opinions should do so there, not here. Nsk92 (talk) 18:11, 25 February 2021 (UTC)

Cite book display: contributors/contribution should FOLLOW author/title, not precede them

Latest comment: 3 years ago4 comments3 people in discussion
Moved to CS1 talk. Please comment further there. {{u|Sdkb}} talk 07:16, 2 March 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.

Here I'm editing Carl Marzani#Published by Marzani & Munsell. The entry of concern displays as

  • King, Jr, Martin Luther; Nelson, Truman (1962). Foreword. Negroes with Guns. By Williams, Robert F. New York: Marzani & Munsell. OCLC 340047.

Only on Wikipedia does the citation give top billing to the author of the Foreword. That's not good, please fix it, so that the entry appears like this:

  • Williams, Robert F. (1962). Negroes with Guns. with Foreword by Martin Luther King, Jr; Truman Nelson. New York: Marzani & Munsell. OCLC 340047.

Even better, since the "Foreword" is actually two separate essays by King & one by Nelson, it would be best to have contribution1, contribution2 and contribution3 as parameters. Larry Koenigsberg (talk) 18:38, 1 March 2021 (UTC)

Please raise this at Help talk:Citation Style 1 which is where citation template issues are discussed. Peter coxhead (talk) 19:33, 1 March 2021 (UTC)
Done. Raised at Help talk:Citation Style 1/Archive 75#Cite book display: contributors/contribution should FOLLOW author/title, not precede them. Larry Koenigsberg (talk) 21:50, 1 March 2021 (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.
Retrieved from "https://en.wiki.x.io/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_176&oldid=1110681200"