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.
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·des21:43, 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}}talk23:32, 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}}talk00:31, 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 • Talk12: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}}talk13:17, 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}}talk15:25, 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·des23: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}}talk23: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}}talk02: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.
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
Conditional supportoptions since added if there are no other proposals. I'd prefer something bolder than that (which looks like it'll barely be noticeable), but I'll take it over nothing, certainly. Can we have some other proposals? {{u|Sdkb}}talk22:55, 13 January 2021 (UTC)
Follow up: Of these choices, I still prefer the originally posted one, Option A. The remainder are too gaudy, or amateurish-looking, or take up too much space. I prefer the understatement of the original, which is clean and professional-looking. Wikipedia has outgrown its amateurish roots, and we should present ourselves for what we are now, the premiere source of immediate information on the Internet. Beyond My Ken (talk) 01:19, 14 January 2021 (UTC)
Support A - I prefer the fact that it is not too showy or gaudy. A nice commemoration of two decades of building the 'pedia. MarnetteD|Talk23:01, 13 January 2021 (UTC)
Support I want a flashing Wikipedia logo with a comic sans 20 in the middle of it and animated fireworks (preferably yellow and red, green isn't my thing) in the background. Make it happen. --qedk (t愛c)23:03, 13 January 2021 (UTC)
Follow-up The RfC has changed since these first comments. Those indicating support were commenting only on option A. — Wug·a·po·des23:12, 13 January 2021 (UTC)
Option D As Sdkb says: Vibrant yet professional. Followed by: B, C, A. A is hardly noticeable. B is...okay but a bit hard to see what it says. C seems a bit hokey. CaptainEekEdits Ho Cap'n!⚓23:26, 13 January 2021 (UTC)
Option A makes the point in a consistent and elegant style. B and D seem too cartoony and garish. And C risks being quite inaccurate as it supposes that the readership is just like the contributors when their demographics may be quite different. Andrew🐉(talk) 23:29, 13 January 2021 (UTC)
Option D: Here is a mockup on Vector. I thought it might be too busy/colorful, but it seeing it in context – it works, I think. Fits the branding for other 20th anniversary content. Second choice: A, then B. NotC; it looks like we're protesting something or someone died. — The Earwigtalk23:34, 13 January 2021 (UTC)
Yes, I think you might be right. Pad a bit more to match how the current logo looks and possibly give us enough space to properly center "20 years of"? Unfortunately we're running out of time. Ping Wugapodes. — The Earwigtalk19:16, 14 January 2021 (UTC)
Working on the final designs of A and D (since those seem the only real candidates) as we speak. Should have them posted by 20:00 UTC — Wug·a·po·des19:48, 14 January 2021 (UTC)
Option D – followed by C, I've loved the style of D since I first saw it at some WMF page; it should draw attention, worried that the others won't. A and B seem a little too bland for a celebration or anniversary imo. Aza24 (talk) 23:40, 13 January 2021 (UTC)
Option C, unorthodox opinion sure. In your face, yes. But it brings attention to the fact that anyone can become a contributor which is something we need more awareness of and I like its aesthetics... Tayi ArajakateTalk23:50, 13 January 2021 (UTC)
Option D then Option A. But wondering whether a logo would mention we reached one billion edits. "20 years, 1 billion edits" sounds even more grandiose. Ovinus (talk) 00:30, 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·des02: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
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·des04: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: 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 DCCXLVIconverse | fings wot i hav dun01: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 DCCXLVIconverse | fings wot i hav dun02: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! — MusikAnimaltalk01: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. Cullen328Let's discuss it02: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 DCCXLVIconverse | fings wot i hav dun05:01, 14 January 2021 (UTC)
Support generally, first choice being Option A, second choice Option D. No objection to other options presented, though. BD2412T02:59, 14 January 2021 (UTC)
Comment: I think many option A !voters are missing how extraordinarily subtle that change would be. It's one thing to see the extra line when you're looking at it oversized in the context of a discussion you know will be about changing it; it's quite another to be browsing Wikipedia for something totally unrelated. If we want anyone other than ourselves to notice (and I think we do for an anniversary this significant), we should choose a bolder option. {{u|Sdkb}}talk09:30, 14 January 2021 (UTC)
Support C, followed by A As C doesn't seem to be getting much love, please consider A my !vote if that wouldn't win. I prefer the non-cartoony options, 20 years in, Wikipedia is into its adulting phase ;) Nosebagbear (talk) 10:18, 14 January 2021 (UTC)
Support A D looks a bit cluttered and cartoonish, and I like the more simple, minimalistic form of A. B looks ugly, and C is just text.
Support A is the most professional looking one..lets steer clear of child like cartoons on the main page...or any page for that matter.--Moxy🍁14:20, 14 January 2021 (UTC)
Support D - Compared to the other options, actually feels celebratory. D reminds of a vibrant mural on the street. Altamel (talk) 16:51, 14 January 2021 (UTC)
Strong support choosing any of the proposals (though that seems to have consensus now) and I'd like C, D, B and A in that order. C is simple but thought-provoking and could inspire people to think about joining, D is beautiful and hopefully would also get people to reflect a bit on how they use Wikipedia and why, B looks nice and grabs attention and A is similar to banner themes we've used in the past and uncontroversial. — Bilorv (talk) 19:56, 14 January 2021 (UTC)
Just to emphasise: that's a strong support of D over A (since those look like frontrunners). Support mentioning 1 bn edits too. — Bilorv (talk) 22:04, 14 January 2021 (UTC)
I support C, D, B, A, in that order. We've done bolder logos for arguably less important events, and I think C looks really good for WP 20. Best, KevinL (altofL235·t·c) 20:22, 14 January 2021 (UTC)
I thought all this was discussed and dismissed weeks ago. I agree with Mike Peel, oppose a change, but if there is to be one, A looks best.--Wehwalt (talk) 20:43, 14 January 2021 (UTC)
A only. Agreed that the professionalism on the other two is lacking. Especially if we leave this to linger for longer than the day. --Izno (talk) 20:44, 14 January 2021 (UTC)
Support the proposal: Not voting for anything specificially. Like pythoncoder I also ensorse the proposal in general. Let's do it. --Titodutta (talk) 22:16, 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}}talk15:22, 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. — xaosfluxTalk16:06, 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. AsarteaTalk|Contribs16: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. Seddontalk18: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}}talk18:32, 14 January 2021 (UTC)
I do not support the proposed banners. I do support our usual banner like at 6m articles. Something like "Wikipedia celebrates its 20th birthday with 1 billion edits" or something. --Izno (talk) 20:46, 14 January 2021 (UTC)
I agree with Izno, let's do the usual Main Page banner style like at the n-millionth article celebrations. Mz7 (talk) 23:18, 14 January 2021 (UTC)
I should clarify by saying I think something is better than nothing, and I merely prefer the usual banner style, but I don’t want to prevent there from being any banner at all. Mz7 (talk) 00:00, 15 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.
There seems to be the least resistance so far to do "something" over nothing-- going off the styling at Template:Main_Page_banner - can we settle on some text, including a single bolded call to action that has a specific landing page? — xaosfluxTalk00:57, 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. — xaosfluxTalk02: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}}talk12: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). — xaosfluxTalk18: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}}talk18: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.
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}}talk12:42, 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.
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}}talk01: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? — xaosfluxTalk01:55, 16 January 2021 (UTC)
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}}talk02: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. — xaosfluxTalk02: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}}talk02: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.
Banner duration
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? — xaosfluxTalk19:48, 20 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}}talk16:16, 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. BD2412T23:33, 14 January 2021 (UTC)
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·des20: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·des21: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·des21:50, 14 January 2021 (UTC)
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.
@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}}talk22: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)
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. Nihlus02:24, 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 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)
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·des05:12, 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 Earwigtalk05: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. Nemo06:58, 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)
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)
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 — GhostInTheMachinetalk to me20:32, 18 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}}talk13: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. -- Calidum15: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)
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. ---Sluzzelintalk00:31, 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)
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)
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.
Switch to AorRemove 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)
I don't edit here much anymore, but I feel like one month is long enough for a celebration like this. I'm one of the few that actually like Option D as it is a special occasion, but I'm fine with Option A if consensus reaches that conclusion. —Gestrid (talk) 14:29, 19 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.
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. — xaosfluxTalk16: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)
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·des23: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. — xaosfluxTalk01: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)
I've now put this up. Please holler if anything looks busted or needs tweaking. ~ Amory(u • t • c)16:09, 22 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.
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! BD2412T23:44, 14 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. BD2412T00: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.
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: 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. — xaosfluxTalk00: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.
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)
I feel that going off-script is warranted for celebrating 20 years. I'm glad you found your way here to share your opinion though. To 20 more years! Brightgalrs (/braɪtˈɡæl.ərˌɛs/)[ᴛ]03:35, 15 January 2021 (UTC)
A HORSE (as determined by consensus)
I am sorry to say that the new image -- which I dearly hope is only temporary -- is truly, truly awful. I'm afraid this is one of those times when consensus really wasn't the best method to arrive at a good result. Beyond My Ken (talk) 03:54, 15 January 2021 (UTC)
Lugnuts, I agree ("more than" is better grammar, and I think "1" looks cleaner). I thought about bringing it up earlier but decided not to since I didn't want to risk derailing anything. {{u|Sdkb}}talk12:37, 15 January 2021 (UTC)
I never thought I would be so motivated to go out of my way to complain about a new (albeit temporary) logo, but here I am. I agree with BMK; it really is dreadful.--WaltCip-(talk)20:40, 17 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.
Improve tooltip for red links
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?
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}}talk17:37, 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)
"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.- NovovTC08: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)
Replace hyphen with en-dash in Wikipedia browser tab name – MediaWiki:Pagetitle
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):
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). — xaosfluxTalk18: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}}talk22: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. Armadillopteryx00: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}}talk23: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)
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.wikipedia.org/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.wikipedia.org/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)
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. Armadillopteryx00:46, 4 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? blameless21: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. blameless19: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·des23: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)
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 — GhostInTheMachinetalk to me11: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 | Talk20: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)
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 Earwigtalk06:11, 27 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 BushrangerOne ping only07: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–. —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. ◅ Sebastian20: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 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)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal: Adding more links in the sidebar in mobile view
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)
Add a help link in the sidebar linking to Help:Contents
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 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}}talk03:08, 26 January 2021 (UTC)
RfC: Should we have Support/Oppose/etc. survey convenience templates?
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.
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.)
Oppose As I would typically say in TfD, insufficient complexity of markup to warrant a template. I completely fail to see the point of creating a template whose content is its name with three apostrophes prepended and appended, when that is only two characters longer than typing the wikitext out in the first place. * Pppery *it has begun...22:27, 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)
Yeah that works. Unfortunately, the toolbar is above the fold. I wish it could be moved to below the editing window. --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)
One possible work around is to use iOS's text replacement feature (Settings -> General -> Keyboard -> Text replacement). You can choose any sequence of characters to be replaced by another. For example, you could choose bqq to turn into ''' (three single quotes.) isaacl (talk) 20:23, 9 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)
@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)
I would have the string {{Support}} auto-change and substitute to '''Support'''. I would find it useful, for the same end result. --SmokeyJoe (talk) 04:34, 2 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)
<strong {{#if:|role="{{{role}}}"}} {{#if:|class="{{{class}}}"}} {{#if:|id="{{{id}}}"}} {{#if:|style="{{{style}}}"}} {{#if:|title="{{{title}}}"}}>Support</strong>. Oh dear, that's a mess of wikimarkup, isn't it. --SmokeyJoe (talk) 07:48, 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)
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)
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)
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)
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)
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. ◅ Sebastian11: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)). –Davey2010Talk11: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 ▎TALK14: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. --Jayron3215: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). — xaosfluxTalk17: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·des22:20, 4 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·des02: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)
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. SpartazHumbug!19:58, 5 January 2021 (UTC)
@Spartaz: But you just used bold words in your comment? This proposal is for a convenience template to make it easier for other editors to comment, not a substitute. Thanks. Mike Peel (talk) 21: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)
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)
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)
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)
Agreed. It's quite sad to see the amount of attention this is getting, while much more significant issues get crickets. {{u|Sdkb}}talk15: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}}talk12:37, 12 January 2021 (UTC)
Oppose per above. Likely to encourage voting behavior which would not harmonize well with enwp's consensus-based culture. -FASTILY01: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. —Cryptic15:54, 12 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
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.
I'm not sure what you mean by this. That page is where the current gadgets are defined, so would be unaffected by this change. What would be removed are the namespaces above, which are currently entirely unused, but in theory would be by the future gadget reorganization. ~ Amory(u • t • c)22:44, 17 January 2021 (UTC)
I'll withdraw this proposal if there's actual work on gadgets. I don't have a gripe with the namespace, I just didn't get the impression it was ever going to be used at this point. Elliot321 (talk | contribs) 07:56, 16 January 2021 (UTC)
I see it has been added to the RfC list. Can someone clarify if it within the domain of community consensus to even remove the namespace / gadget, and if so is it even a good idea if that Wishlist proposal will happen? If no to either, then RfC is likely a waste of time. ProcrastinatingReader (talk) 18:41, 16 January 2021 (UTC)
@ProcrastinatingReader: As I understand it, adding or removing a namespace is something that only developers can implement, and they will (again AIUI) only do so in two circumstances (1) where it is (no longer) required for a new (or removed) software feature, or (2) clear community consensus. Regarding the Wishlist proposal, it is almost impossible to predict which of the proposals will be actually be worked on beyond investigating in more detail what that work would entail and what resource is required. If there is no clear indication on Phabricator after about 3 months then I'd say to ask for an update, but before that point it's unlikely to be worthwhile even asking. Thryduulf (talk) 03:45, 17 January 2021 (UTC)
I'm not clear on what the point of this RfC is. There's only one page in any of these namespaces (i.e. Gadget:Invention, Travel, & Adventure), and AFAIK, it cannot be modified or deleted by anyone on enwiki without at least steward--if not sysadmin--intervention (which itself is why it exists, as a one-off hack). Is the intent to establish a consensus first, and then open a phab ticket or something to ask for the removal of the namespace by developers, using this RfC as evidence of consensus? I think that would be a platform-wide change, wouldn't it? If so, wouldn't we need more than just enwiki to agree with that before the devs would even begin to listen? I ask because we've been here before, last year, and nothing came of it, and I'm not sure what this RfC would change about that. Writ Keeper⚇♔17:42, 19 January 2021 (UTC)
@Writ Keeper and JJPMaster: I don't think that removing these namespaces would be a platform-wide change given that different wikis can have different namespaces, although it's possible it might be. If it is possible, the developers will not remove the namespace here without evidence of consensus to do so. If it isn't consensus to remove it only on en.wp would be evidence of a good reason to start a discussion on meta. Thryduulf (talk) 12:05, 21 January 2021 (UTC)
@Thryduulf: Generally speaking, yes different wikis can have different namespaces. But my understanding--which is limited for sure--is that these aren't just extra namespaces the way Draft is. The Gadget: and Gadget definition: namespaces are reserved by the Gadgets 2.0 extension, so I think removing the namespaces would require a code change for that extension, which would impact all wikis.
My point isn't ultimately about whether this should be here or on Meta, although that is a pending question. My point is that--again, based on my limited knowledge and unlike a normal modification of namespaces--this is a non-trivial code change that will impact all wikis, not just enwiki, and it's one that the devs have already repeatedly refused to do. (Why we even have a half-finished extension on a production site is another question entirely, but...) I don't think this RfC is formulated in a way that people know what they're asking for, and as such, I don't think it'll go anywhere, even if we get a consensus. Writ Keeper⚇♔14:41, 21 January 2021 (UTC)
Support. Having this sort of thing around contributes to complexity and confusion and, as mentioned, this namespace is only used once. I have always wondered what the point of this namespace was / is and can see now others are in the same boat. With respect to our jurisprudence I think it's perfectly fine to indicate that locally on EN WP we don't see this namespace being useful, and further discussion can happen at a larger venue. Many such technical changes have arisen from discussions locally that indicate the feeling of editors, even if there may need to be other discussions elsewhere. --Tom (LT) (talk) 07:03, 21 January 2021 (UTC)
Additional comment: Unlike the Education Program namespace, which had talk pages (why it was installed back in 2018,) there are no real gadget (definition) talk pages on this wiki, which is another reason why I think it should be deleted. 54nd60x (talk) 09:21, 26 January 2021 (UTC)
Support. It has been several years, and there do not seem to be any concrete plans to do the work which would use this namespace. If there are plans, I'm happy to keep it, but otherwise there's no sense in the extra complexity and confusion it causes by having it appear in every namespace selector. the wub"?!"18:15, 30 January 2021 (UTC)
Support As I wrote in the last of the above list of links, the movement to use the gadget namespace has been stalled with no sign of progress for over 4 years, so there's no reason to expect it to happen [...] in the near future. This namespace's existence is causing periodic problems, for no apparent benefit. * Pppery *it has begun...23:14, 30 January 2021 (UTC)
How often do we need to create articles whose names begin with the seven characters "Gadget:"? There's one documented instance, mentioned above. So, that one aside, which other potential articles is this causing problems for? --Redrose64 🌹 (talk) 08:46, 31 January 2021 (UTC)
Okay, here's my hat: oppose. This namespace is not harming anything, the periodic discussions notwithstanding. The discussions themselves take more time than the actual namespace takes from anyone else. A single page hanging out in the wrong place also isn't breaking the wiki. That we're having this conversation when this is basically a WP:CONEXCEPT question is asinine. Go home, live with it, wait until the namespace is actually used. It's not hard to ignore it, people. Put something on WP:Namespace if it isn't there. --Izno (talk) 07:25, 31 January 2021 (UTC)
It's unclear to me whether this is proposal to temporarily remove these namespaces until Gadgets 2.0 is ready or a request to permanently remove them. If it's the latter, that's a non-starter, if it's the former then I'd ask exactly what the issue is in having them around, albeit unused, given that they will be used...eventually. For context, I was one of the most recent people (like 4-5 years ago) working on Gadgets 2.0 whenever we could find time (usually once a year at the Wikimania hackathon). I do believe that every editor actually wants Gadgets 2.0 to happen, though most won't care and won't notice. Gadgets will be slightly faster and gadget authors will get access to more features. So...if the problem is that these namespaces are sitting unused, I think the best solution/use of time is to find some more technically minded folks who would be interested in contributing to the Gadgets extension and work towards getting 2.0 ready for users, so we can populate those namespaces. Legoktm (talk) 08:00, 31 January 2021 (UTC)
I think moving away from Gerrit will be a boon for code contributions. Moving the code into GitHub would’ve probably helped too, though I guess that’s a non-starter. But there’s still the issue of getting code reviews. ProcrastinatingReader (talk) 10:46, 31 January 2021 (UTC)
When I originally opened this, I was unaware that there was still work being done on Gadgets 2.0. I'm obviously not opposed to that - I was under the impression that these namespaces were long-abandoned. Elliot321 (talk | contribs) 17:26, 31 January 2021 (UTC)
To be clear, no one is currently working on Gadgets 2.0 as far as I know. But eventually, I hope. (I won't make any promises or even suggestions because I already told people we'd have Gadgets 2.0 by 2017 and well, here we are.) Legoktm (talk) 00:02, 2 February 2021 (UTC)
Strong support: Have never been used, unlikely to be used in the future. If there’s no benefit of this namespace and it’s causing problems for any page, I think the namespaces should very well be deleted. 54nd60x (talk) 01:35, 1 February 2021 (UTC)
Oppose any en-wiki specific development hacks to remove namespaces 2300-2303. That would just result in some barely/un-supported technical debt that will likely break down in the future. Strong Oppose any display hacks to try to "hide" this locally, that will certainly break down and be inconsistent across platforms/browsers/etc. Neutral on if the results of this are just to petition the devs to globally remove these namespaces from all/all-wmf projects. — xaosfluxTalk13:58, 2 February 2021 (UTC)
@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. — xaosfluxTalk15: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
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.
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).
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)
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.
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)
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.
(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 talk05:35, 5 February 2021 (UTC)
Should Cewbot remove interlanguage link templates once local articles exist?
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 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.
I wonder whether the conversion could be logged somewhere. Maybe a note on the edited article's talk page ("I changed {{il|French}}toLocal" – 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)
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}}talk16: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)
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
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.
"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.
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
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.
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)
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. BD2412T06: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)
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)
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
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.
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 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)
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}}talk05:10, 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}}talk07:28, 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. ~ HAL33302:54, 6 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)
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, Eddie891TalkWork23: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. Eddie891TalkWork23: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}}talk03: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. Eddie891TalkWork18: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)
It seems unlikely that any experienced editor has not seen and attended a merge discussion such as thisorthat. I am reminded of M. Jourdain who is surprised to learn that he has been speaking prose all his life, without knowing it! Andrew🐉(talk) 09:37, 30 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? — Rhododendritestalk \\ 02:42, 30 January 2021 (UTC)
Oppose Let us count the ways:
Mergers are inherently unproductive because they just move content from one page to another with low value-added
Mergers can mostly be done by anyone using ordinary editing tools, just as anyone can add, remove or move a section in an article
Deletion however is a specially restricted function because it makes the content inaccessible and is not easy to revert
AfD exists primarily for deletion, providing the clear consensus required for admins to use this specially restricted function
AfD is moribund too because it's no fun looking at junk
The longer the AfD list, the less likely that people will look through it and so participation will decline further
Already we see lots of AfD discussions being relisted again and again for lack of participation
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
The proposal therefore risks turning mergers into deletions and content will be lost
There are technical limits on the size of the daily AfD logs due to their heavy use of templates
The AfD process doesn't scale - neither technically nor in its human factors
The proper place to get attention for mergers would be projects staffed by subject-matter experts
But projects are dying too
The main reason that everything is dying is excessive assholery, battleground behaviour, busywork and conflict
We need to focus on fostering collaboration, cooperation and content creation rather than finding new and better ways to annoy each other
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. Levivichharass/hound15: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 here11: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)
Color code http and https links differently
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 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)
/* Blue padlock for secure links */#bodyContenta.external[href^="https://"]{background:url(//upload.wikimedia.org/wikipedia/commons/0/00/Lock_icon_blue.gif)centerrightno-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)
@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
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? BD2412T21: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, Rosguilltalk21: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. BD2412T22: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:ANIorWP: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)
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)
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.
I believe this will help many beginner editors.
When you click it you just type a message and then it automatically puts your signature. SoyokoAnis19:21, 12 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
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.
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)
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)
Science Photo Competition 2021 Russia targeting CentralNotice banner
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)
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)
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. ϢereSpielChequers22:45, 14 February 2021 (UTC)
I of course also agree that "not for Wikipedia" is much too broad and subjective for CSD. As for SNOW, it can't be a CSD because then future iterations of the article wouldn't be G4-eligible. Perhaps a better idea would be to create some sort of "requested SNOW closure" category (perhaps populated via a template) to notify administrators that a SNOW close had been requested. Extraordinary Writ (talk) 22:59, 14 February 2021 (UTC)
Snowball closes are authorized by WP:XFD, which is a guideline. I thus think that a requested SNOW close category would be valid, although the details would probably still need to be fleshed out. (WP:SNOW probably should be a guideline, for what it's worth, although I don't think it's necessary for our purposes.) Extraordinary Writ (talk) 23:25, 14 February 2021 (UTC)
Only if someone has a proposal for something different to what has been suggested and rejected countless times before. Also don't bother unless it meets all four of the criteria at WP:NEWCSD. Thryduulf (talk) 15:14, 15 February 2021 (UTC)
I wonder whether what's needed is actually to change CSD's name, from "speedy deletion" – everyone wants bad articles to be removed quickly, so if CSD doesn't have the right criteria to fit the page I want to get rid of, then we should just expand the list some more – to something like "undiscussed deletion". WhatamIdoing (talk) 06:42, 16 February 2021 (UTC)
Interesting idea. Ideally a new name would include something to indicate that it is an exception to the standard process for exceptional situations not something that's just for "things one or more editors dislike". Thryduulf (talk) 12:31, 16 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)
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.Levivichharass/hound04:27, 23 February 2021 (UTC)
Opposed - WP should not engage in advocacy - no matter how noble the cause. Just spend the day improving articles about women. Blueboar (talk) 15:33, 25 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
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.
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)
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.
Done trimmed Template:Main Page banner. — xaosflux Talk 18:15, 15 January 2021 (UTC)
Resolved
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 . Now, how to lose the gaudy green tick? --SmokeyJoe (talk) 06:55, 2 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)
. We would probably want {{weak meh}} as well — GhostInTheMachine talk to me 10:17, 6 January 2021 (UTC)
(Im not very good at images but you get the general idea)--Ozzie10aaaa (talk) 13:26, 7 February 2021 (UTC)
Regards, GenQuest "scribble" 18:50, 27 January 2021 (UTC)
