Jump to content

Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64

WikiRPG Gadget/Extension

[edit]

I had this idea a good bit ago. A gadget or extension for Wikipedia that turns it into an RPG, where you can like, get XP for making good edits and stuff, or maybe even fight enemies on wikipedia articles to make it a real rpg. This is obviously a non-serious idea, and it's just an idea to make editing a bit more fun for some, but I do think it'd be cool. Discuss in the comments, I'm excited to see what y'all add!
From Rushpedia, the free stupid goofball (talk) 18:18, 28 January 2025 (UTC)[reply]

Thinking about it now, this would probably be an extension. It wouldn't fit in as a gadget, since it wouldn't be useful. From Rushpedia, the free stupid goofball (talk) 18:19, 28 January 2025 (UTC)[reply]
It sounds like you'd be interested in Wikipedia:Wikipedia is an MMORPG. WhatamIdoing (talk) 02:09, 29 January 2025 (UTC)[reply]
I don't want to encounter grinders spamming minor edits to level up quick. It would also buff trolls because they'd be treated as a proper enemy instead of something to deny and clean up after.[Humor] ABG (Talk/Report any mistakes here) 05:56, 29 January 2025 (UTC)[reply]
I like the idea, but the execution would be hard. also you would need to make scripts that would detect vandals, but what if the people using the script were vandals? Twineee talk Roc 14:29, 8 February 2025 (UTC)[reply]

Ask the chatbot

[edit]

Have you seen the "Ask the chatbot" feature in Britannica? Honestly I am a bit suprised that they developed something like that. I think that it's a good way to consume the encyclopedia contents for quick questions. One of the most frequent uses for ChatGPT and similar tools (hi DeepSeek R1) is Q&A, and they use to reply using our contents (their models are trained partially using Wikipedia after all), so why don't we develop our own chatbot? What do you think? Regards. emijrp (talk) 18:18, 28 January 2025 (UTC)[reply]

I'm not really a fan of AI, being an artist and all, but this could maybe help students and stuff. I kinda like this idea. From Rushpedia, the free stupid goofball (talk) 18:21, 28 January 2025 (UTC)[reply]
Considering all of the discussion above, what would you consider an acceptable error rate for answers? Donald Albury 18:48, 28 January 2025 (UTC)[reply]
Ideally 0, but that's probably impossible. I am not an expert in the field, though IMHO we could train the model excluding articles with maintenance tags, all sentences without a reference, pages written by newbiews or few editors, etc. Also, adding the "I don't know" sentence to the chatbot vocabulary could be a feature, it's not bad to say it. Furthermore, more than a purely conversational chatbot that can hallucinate, I propose one which replies to your questions pasting the relevant sentences in the articles, with minimum originality. Other features could be "please summarize this article, or all articles in this category, tell me three writers born in France in the 17th century, the most important Van Gogh paintings, etc". Definitely, an improved search engine which helps to consume the content. emijrp (talk) 19:10, 28 January 2025 (UTC)[reply]
That would mean training the model to exclude nearly all of our content. WhatamIdoing (talk) 02:10, 29 January 2025 (UTC)[reply]
To be fair, "pages written by few editors" isn't necessarily something we should exclude: GAs and FAs are usually written by a few dedicated editors, rather than in a slow incremental way (my own example).
Regarding the proposal of adding the "I don't know" sentence to the chatbot vocabulary, while the idea is certainly good, there isn't a specific "chatbot vocabulary" that can be edited: rather, that's something that has to be pushed for during training. However, I do like your proposal of one which replies to your questions pasting the relevant sentences in the articles (there's something similar that can be found in the literature, namely retrieval-augmented generation, which directly adds the relevant sentences to the prompt and answers from there). Chaotic Enby (talk · contribs) 02:17, 29 January 2025 (UTC)[reply]
I don't see any particular need why we should integrate chatbots – a rapidly changing and frequently flawed technology – into our own rapidly changing and frequently flawed encyclopedia. It'll only make matters worse. Cremastra (talk) 20:10, 29 January 2025 (UTC)[reply]
Agree with this. I did give some technical advice above, but it doesn't mean I'm sold on the proposal at all. Chaotic Enby (talk · contribs) 20:15, 29 January 2025 (UTC)[reply]
We should integrate a chatbot that people can ask about future chatbot integration plans, and tells them no. signed, Rosguill talk 17:36, 8 February 2025 (UTC)[reply]
Good plan. We can have a little box off to the side that says, "ask the chatbot ✨" below a little box. Whatever the user enters in the box is replaced with "Will Wikipedia integrate chatbots into its encyclopedia". The response is then "no". I'll get started on development. Cremastra (talk) 17:40, 8 February 2025 (UTC)[reply]
lol send me the link Twineee talk Roc 17:45, 8 February 2025 (UTC)[reply]
No, wikipedia is one of the few places left on the internet not infected by the LLM hypetrain. LLMs have a very antisocial and corporatized connotation, they are the antithesis of what wikipedia is Mgjertson (talk) 16:00, 6 February 2025 (UTC)[reply]
#Implemeting "ChatBot Validation" for sentences of Wikipedia Twineee talk Roc 17:34, 8 February 2025 (UTC)[reply]
[edit]

Reading and going through normal webpages and sites, I started to wonder: Do we really need links to shine blue these days? We are all so used to just "test clicking" on anything, since most things online are clickable these days, so I'm just wondering if we still need to differentiate our links by having them shine blue. This topic might have been discussed before and I've simply missed it.

We have several rules on how to limit the number of links on an article, simply because too many of them disrupts the reading experience. It also takes a lot of time to weed out double links or anything that doesn't fall inside the guidelines. With black links, there wouldn't be any problem with over-linking.

Sure, this is just a very rudimentary idea that would need to be sorted for editors. Like perhaps the links could turn blue (and red) when you open a page in the editing window, black links could be default for when you are not logged in, and when logged in you could select the color in your settings. Or: the second, third, etc. link in an article could automatically be displayed in black, leaving only the first time blue (surely we have the tech for that now). It needs to look good on all platforms. And what about all the menus on wiki pages, do they really need to be blue? What normal websites these days have their menus in a "click color". I think that a reduction of colored links would be a way to give the layout of Wikis a bit of an update.

This question might belong on another forum, but this place is as good as any to start. Cart (talk) 20:21, 29 January 2025 (UTC)[reply]

Respectfully, I don't think that this would be a very practical navigating experience. The idea of having blue links is specifically so the readers don't have to "test click" on every word, and I don't think Wikipedia readers are actually doing it. Having links be black by default would make for a more painful navigating experience, as you'd have to try to click on every word to see if there is a link hidden there.
However, I do agree that making the menus (and only the menus) be black could be a possibility (although not sure if it would be an improvement) as the readers already expect them to be links. Chaotic Enby (talk · contribs) 20:28, 29 January 2025 (UTC)[reply]
I am not used to test clicking. Not differentiating before hovering is just bad UX and has not been and should not be normalized. Not to mention the print view.

With black links, there wouldn't be any problem with over-linking.

I don't understand this rationale at all. We should make it easy for readers to go places. "Solving" navigational issues by breaking navigation entirely is the "nuke the world and just die out" solution. Aaron Liu (talk) 13:28, 30 January 2025 (UTC)[reply]
"We are all so used to just "test clicking" on anything" [citation needed]--User:Khajidha (talk) (contributions) 13:39, 30 January 2025 (UTC)[reply]
Not an expert, but I believe there has to be some way to distinguish between links and plain text to meet accessibility standards (this is why link colors were lightened between Vector 2010 and Vector 2022 – to increase contrast between text colors). RunningTiger123 (talk) 14:11, 30 January 2025 (UTC)[reply]
Do you have any evidence of "We are all so used to just 'test clicking?'" I certainly do not do that and looking over peers shoulders, I don't think I've ever seen anyone do that, period. This is anecdote vs anecdote, but I feel that you're making an extraordinary claim. Most people don't click something unless there's something to differentiate it from surrounding text (or it's obviously part of a menu.) Nebman227 (talk) 14:23, 30 January 2025 (UTC)[reply]
Ok, I was obviously unclear in calling it 'test clicking'. But say that you go on a news website like BBC or CNN, you see no links at all. On a computer the links will show up as underlined when you move your cursor over them, but not so on a phone. You just assume that the headlines are clickable and so you 'test click' on them, and that usually works. You are directed to the article you are looking for.
As for how having the second, third etc. links to the same article on a page turn black automatically, it would reduce the visual number of links, making the page easier to read. The links would be there, just not so much in your face. And if you happen to click on that word it will link as usual. Cart (talk) 15:04, 30 January 2025 (UTC)[reply]
True, but people know that headlines are clickable. People don't know in advance which words inside a chunk of text will be clickable. Chaotic Enby (talk · contribs) 15:07, 30 January 2025 (UTC)[reply]
Those headlines fall under Nebman227's point about "differentiate[d] from surrounding text (or it's obviously part of a menu)". Nobody just randomly clicks on words in the middle of an article.--User:Khajidha (talk) (contributions) 15:09, 30 January 2025 (UTC)[reply]
Indeed the actual links in BBC and CNN articles are underlined see e.g. [1] and [2]. I'd note over linking is also likely to cause problems for touch screen users even worse if these links aren't obvious. Nil Einne (talk) 14:55, 4 February 2025 (UTC)[reply]
A setting to underline links could be helpful for visually impaired readers (assuming it is optional, in order not to add visual clutter to the default experience), although maybe that is already a thing? Chaotic Enby (talk · contribs) 16:56, 4 February 2025 (UTC)[reply]
It is. Appearance->Advanced options->Underline links (dropdown) Aaron Liu (talk) 17:29, 4 February 2025 (UTC)[reply]
Oh that's great, thanks! Chaotic Enby (talk · contribs) 18:41, 4 February 2025 (UTC)[reply]
Blue and purple links are a pretty standardized thing online and have been since the early days. I wouldn't be opposed to the option (more options is never a bad thing), but by default I think wikipedia should stick to common internet standards Mgjertson (talk) 16:02, 6 February 2025 (UTC)[reply]
Since we all read Wikipedia in dark mode, black links would be invisible against the black background. I don't agree that this would increase readability.</sass> See also H:LC and MOS:COLOUR.
One of Wikipedia's foundational ideas is highlighting our intraconnectivity, and bluelinks are basically part of our brand identity (and jargon). I think many desktop browsers have options to use different colours and/or text-decorations for their default link presentation, so some readers can already configure this to their liking.
As to what looks good (even on one platform, let alone all platforms), this value cannot be reliably defined. And the following isn't really a counterargument, but I feel like Wikipedia is one of the only normal websites these days, most of the rest having degenerated into ads and widgets. Folly Mox (talk) 17:36, 6 February 2025 (UTC)[reply]

What do we want on the front page?

[edit]

A recent RfC was closed with the suggestion that in six months an RfC be held on whether or not to abolish In The News. We could, of course, just abolish ITN without replacing it. However, I wonder if rather than asking "abolish ITN? yes/no" as the survey we might find consensus with "On the front page do we want a section for: In the news or X?" in a way that we wouldn't if we just discuss about abolishing ITN. Looking at some other projects things that I see on their front pages in roughly the place of ITN on ours are a featured image and information about how to participate. But I'm guessing there might be other ideas? And is this concept even a good one rather than the binary abolish/not? Best, Barkeep49 (talk) 22:51, 3 February 2025 (UTC)[reply]

I honestly think that we should revisit the two proposed amendments which were derailed by the added "abolish ITN" option. The close did find consensus against the nominated forms of the proposals though, so I'm not sure if re-asking these questions would be disruptive.
On replacing ITN, we could replace just the blurbs and the title with "Current events"—the newest blurb for each category, with 2 blurbs in a category if needed. (In practice, this will probably mean armed conflicts will have 2 blurbs most of the time and occasionally another category will have 2 blurbs.) Other possible replacements include a short introduction like simplewiki, a blurbed version of Wikipedia:Top 25 Report, {{tip of the day}}, a WikiProject spotlight, and perhaps the WP:Signpost headlines. Looking at all these, perhaps Current events is the only way we can preserve the innocent Current events portal and Recent deaths... Aaron Liu (talk) 23:20, 3 February 2025 (UTC)[reply]
Or we could, I dunno, list recent deaths whenever "deaths in <year>" pops up under Top25. Aaron Liu (talk) 23:28, 3 February 2025 (UTC)[reply]
These suggests strike me as ways of "fixing" ITN (in quotes because I think some argue it doesn't need fixing?) rather than saying what is a different way we could use that mainpage space (which was my hope in this section). I found it interesting and not what I'd have initially thought that the closers felt abolishing was more likely to get consensus than some other form of fixing ITN as the two proposals that were on the table both had consensus against. I'm not sure what the value would be in revisiting either of those so soon. Best, Barkeep49 (talk) 16:17, 4 February 2025 (UTC)[reply]
I did talk about ways to replace the space in my second paragraph and beyond. What do you think of those?

I'm not sure what the value would be in revisiting either of those so soon.

There was a lack of discussion and engagement regarding the fixing proposals after option 3 was introduced. I have had quite a few counterarguments that weren't addressed by newer !votes repeating the previous arguments. Maybe we could just split the RfC into separate, isolated sections. We could also change the proposals to be alternate qualification routes inserted. Aaron Liu (talk) 17:31, 4 February 2025 (UTC)[reply]
Anything featured on the main page needs to be representative of the quality of work that WP can produce, so a blind inclusion from something like Current Events is very much unlikely to always feature quality articles. — Masem (t) 05:04, 5 February 2025 (UTC)[reply]
Makes sense. I guess that also eliminates the "Top 25 Report" option. Aaron Liu (talk) 12:38, 5 February 2025 (UTC)[reply]
I don't agree that everything on the Main Page needs to be "representative of the quality of work that WP can produce", where what we "can" do means "the best we can do". I think we should emphasize timely and relevant articles even when they are underdeveloped. WhatamIdoing (talk) 22:48, 6 February 2025 (UTC)[reply]
In the case of articles about current events, the quality seen on ITN postings often approximates the best that can be achieved. GA, let alone FA, requires a stable article and that is simply not possible when the thing we are writing about is not stable. Obviously not every ITN post is of the same quality, but then the existence of FAR shows that not every FA is of the same quality. Thryduulf (talk) 22:54, 6 February 2025 (UTC)[reply]
I've always liked the {{tip of the day}} concept, in order to get more of our readers to make the jump to editing. Otherwise, something as simple as moving WP:POTD up could be a "band-aid" solution, but I would certainly prefer trying something new rather than just shuffling our sections around. Chaotic Enby (talk · contribs) 17:00, 4 February 2025 (UTC)[reply]
POTD needs more space than ITN has. Aaron Liu (talk) 17:27, 4 February 2025 (UTC)[reply]
  • The main page juggles a lot of tasks, but they can be boiled down to editor retention, reader engagement, and editor recruitment. Most of the main page has long been about showing off our best or most interesting work (reader engagement), and giving a sort of reward to encourage editors (editor retention). Hitting the front page requires dedication, and also a little bit of luck, which really helps with gamification of our work--and that's a good thing! Knowing that I could get something I did on the front page was and remains a major motivation to contribute. I think DYK and FA are currently perfect. If we could come up with a new stream of quality content to hit the front page, that'd be awesome, but perhaps a bit pie in the sky. If we had to replace ITN with DYK, I wouldn't lose much sleep. If we replaced it with OTD, I would want to see the OTD process reformed to encourage higher quality entries. However, that brings up the last, perhaps less frequently considered point of the front page: editor recruitment. I'd be interested to see some data on how much new editor traffic is created from articles that hit the front page. CaptainEek Edits Ho Cap'n!⚓ 17:17, 4 February 2025 (UTC)[reply]
I'll add the suggestions I've raised previously:
  • The best option in my opinion would be an "Intro to Wikipedia" box: a brief explanation of what anyone can edit means, some links to help with the basics of editing, and maybe a tip of the day as suggested by Chaotic Enby above. This might also subsume what currently exists as "Other areas of Wikipedia" toward the bottom of the main page. Editor recruitment is paramount, and something like this could help.
  • We could feature more content with "Today's Good Articles". This would function similarly to TFA, but instead of a full paragraph it would be a bulleted list of ~6 GAs and their short descriptions. We have over 40,000 GAs, so just those alone give us enough material for 20 years, let alone everything promoted in that time.
  • We could add a portal hub with icons that link to the main portals. I'm a little more hesitant about this one given the track record for portals, but I have a hunch that they'd be more useful if we gave them front-and-center attention. The current events portal has a subtle link to it on ITN, and it gets a ridiculous number of page views. There's been talk of Wikipedia's identity in the AI age, and a renewed focus on browsing could be part of that.
  • We could have a display for recently updated articles. This is cheating a little since it's kind of an ITN reform, but a brief list of high quality previously-existing articles that have received substantial updates based on new sources would be more useful than a list of news articles.
Even if there's no consensus to replace ITN, I strongly believe Wikipedia would benefit if we added one or more of these somewhere on the main page. Thebiguglyalien (talk) 17:35, 4 February 2025 (UTC)[reply]
The display for recently updated articles is what DYK is supposed to be, right? CapitalSasha ~ talk 17:46, 4 February 2025 (UTC)[reply]
That's more for new content, such as newly created pages or stubs that got expanded. I'm picturing already-written articles that get large additions based on new developments. It's at the bottom of my list for a reason though, these are in the order of how viable or useful I think they are. Thebiguglyalien (talk) 17:50, 4 February 2025 (UTC)[reply]
I'm partial to the Today's Good Articles box, since I think GAs don't get enough love. Although of course a GA promotion is a DYK qualifying event, so there is some overlap. With the downfall of featured portals, I don't think portals are exactly what we want to be showing off. CaptainEek Edits Ho Cap'n!⚓ 18:03, 4 February 2025 (UTC)[reply]
I'd support replacing ITN with either DYK or Today's Good Articles. SilverTiger12 (talk) 18:08, 4 February 2025 (UTC)[reply]
Another idea would be a “Can you help improve these articles?” Section… each week we nominate a few underdeveloped articles and highlight them for improvement by the community. Not a replacement for draftspace or New Article patrol … for articles after that. Blueboar (talk) 18:40, 4 February 2025 (UTC)[reply]
Asking unacquainted readership to make substantial improvements is a bad idea. Aaron Liu (talk) 19:44, 4 February 2025 (UTC)[reply]
The goal would be to highlight articles for the benefit of experienced editors who are acquainted with the topics, but may not know that a particular article (within their field of expertise) needs work. Blueboar (talk) 02:17, 5 February 2025 (UTC)[reply]
This sounds like WikiProject article improvement drives. Thryduulf (talk) 02:50, 5 February 2025 (UTC)[reply]
Unfortunately, most of our wikiprojects are moribund. Most no longer do article improvement drives. So why not shift that concept to the main page? Blueboar (talk) 12:01, 5 February 2025 (UTC)[reply]
This section header asks "what do we want on the front page", but "we" do not include casual readers or non-editors. Would they really want us to replace ITN with a boring "Please help out with these articles" type of box? Besides, when new people sign up to edit Wikipedia, I believe there's a feature already recommending them articles that need improvement, see Newcomer tasks. Some1 (talk) 12:13, 5 February 2025 (UTC)[reply]
I agree that we should be taking the desires of non-editing readers into account. WhatamIdoing (talk) 22:48, 6 February 2025 (UTC)[reply]
The main page does not filter out non-experienced editors. Aaron Liu (talk) 12:39, 5 February 2025 (UTC)[reply]
It could; we can selectively hide any content from logged-out editors. WhatamIdoing (talk) 22:49, 6 February 2025 (UTC)[reply]
Then what should we display for logged-out editors? Aaron Liu (talk) 02:29, 7 February 2025 (UTC)[reply]
I assume that the logged-out editors would like to see Wikipedia:In the news, but if we don't want to have that, then we could leave it blank. WhatamIdoing (talk) 03:46, 9 February 2025 (UTC)[reply]
As we discussed last year, Wikipedia:Articles for improvement used to have a section on the main page, but it was removed after its trial was considered unsuccessful, as there were few new editors making edits to the highlighted articles. I suggest working with that WikiProject on the feasibility and potential cost/benefit ratio of having a corresponding section on the main page. It could also be something to consider for user home pages, which has a specific intent of suggesting tasks for new users. isaacl (talk) 04:48, 5 February 2025 (UTC)[reply]
Could we do GAs but on a certain topic, using WikiProjects? So for instance if you get 3 GA articles (or another number) tagged for WP:Literature, it gets added to the queue for the main page much like with DYK. If the article has multiple tags, nominator of the GA chooses which WikiProject they want it to be part of. A big benefit of this is that it could revive interest in WikiProjects and give people a common mission that isn’t just vaguely improving Wikipedia’s coverage. Perhaps the display would have the topic at the top, which would link to the WikiProject, and then the three or so articles below maybe with excerpts. Basically something that fostered collaboration, improved collegiality etc. Kowal2701 (talk) 19:51, 4 February 2025 (UTC)[reply]
There are good topics. That's an intriguing concept for me. Between good topics and featured topics there are just under 700 potential topics. That's close to two years of topics to rotate through and if we put it on the front page I can't help but think we'd get more of these made. Best, Barkeep49 (talk) 22:18, 4 February 2025 (UTC)[reply]
I also like that idea! A neat way to emphasize good articles without it being either DYK or "today's good article". Chaotic Enby (talk · contribs) 22:29, 4 February 2025 (UTC)[reply]
We might have 365 days x 20 years of GAs listed at the moment, but if we don't resolve the fundamental disagreement about whether the Main Page can offer links to imperfect content, then we're just replacing "Get rid of ITN because it has so many WP:ERRORS" with "Get rid of GA because it has so many WP:ERRORS".
One of the things that seems to surprise folks is that GA is literally one person's opinion. There's a list of criteria, and one single, solitary editor unilaterally decides whether the article meets with the listed criteria. The most important criteria are largely subjective (e.g., "well written") and therefore something editors can and do disagree about. Most reviewers aren't especially knowledgeable about the subject matter, and therefore they will not notice some errors or omissions. In other words, while GAs are generally decent articles, a critical eye can and will find many things to complain about.
IMO people either need to decide that imperfect content is permissible on the Main Page (and thus quit complaining about how other people have sullied the perfection and ruined our reputation), or that imperfect content is not permissible (and thus get rid of everything except featured content). WhatamIdoing (talk) 05:27, 5 February 2025 (UTC)[reply]
I'm not sure where the WP:ERRORS thing is coming from, because that's not at all why there's such widespread dissatisfaction with ITN. You're also saying that a system that promotes GAs to the main page wouldn't work despite DYK doing exactly that for years. Thebiguglyalien (talk) 05:57, 5 February 2025 (UTC)[reply]
One of the persistent complaints about ITN is that the articles aren't Wikipedia's finest quality. This complaint is also leveled against DYK entries, sometimes including GAs. WhatamIdoing (talk) 06:21, 5 February 2025 (UTC)[reply]
Not sure where GAs come in in all of this. If anything, GA quality is the least controversial thing about DYK, with complaints usually centering around misleading blurbs or recently created articles of mediocre quality.
Our threshold for ITN/DYKNEW quality is way lower than GA, and it doesn't really follow that GAs would have the same quality issues. Lumping GAs alongside ITN/DYK issues as "imperfect content on the Main Page" is oversimplifying the situation. Chaotic Enby (talk · contribs) 10:24, 5 February 2025 (UTC)[reply]
WAID is correct in saying that with GAs, "one single, solitary editor unilaterally decides whether the article meets with the listed criteria" (see Talk:I-No/GA1 for example). The quality of GAs are subjective, the same way the quality of ITN/DYK, etc. articles are. Some1 (talk) 12:21, 5 February 2025 (UTC)[reply]
One of the persistent complaints about ITN is that the articles aren't Wikipedia's finest quality: I don't think many are expecting finest. Are there example threads? ITN is already an editing drive of sorts to meet WP:ITNQUALITY. —Bagumba (talk) 08:39, 7 February 2025 (UTC)[reply]
A few people[3][4] who supported the "abolishment" of ITN at the RfC argued that the main page should only feature "high quality" content. Some1 (talk) 12:41, 7 February 2025 (UTC)[reply]
Much less. Phil Bridger (talk) 20:47, 4 February 2025 (UTC)[reply]
  • However, I wonder if rather than asking "abolish ITN? yes/no" as the survey we might find consensus with "On the front page do we want a section for: In the news or X?" Why ITN vs [X]? What if editors want to keep ITN and replace another section on the main page such as DYK with something else? Any future RfCs regarding the potential removal of ITN from the MP should initially and explicitly ask whether editors want ITN removed or not (a "binary abolish/not?" sort of question).
    We could also go the more general, less ITN-focused route and ask the question you just asked in the heading: "What do we want on the front page?" and in that RfC, provide multiple options, such as ITN, DYK, OTD, TFA, [and any new ideas that people have]; then have the community choose their favorites or rank the choices. Some1 (talk) 00:44, 5 February 2025 (UTC)[reply]
  • I like both the "learn to edit" and "good topics", but given the appalling deficit of editor recruitment on the main page, the former is my decided preference. Cremastra (talk) 00:39, 5 February 2025 (UTC)[reply]
  • If we are going to remove it we shouldn’t replace it with anything, there isn’t anything else that won’t have just as many problems as ITN. PARAKANYAA (talk) 04:01, 5 February 2025 (UTC)[reply]
    A static box as an introduction to editing? Aaron Liu (talk) 12:50, 5 February 2025 (UTC)[reply]
    I am very opposed to that idea. It's just not main page type content. No matter what we put on the main page it should be showing stuff, not begging/pleading for more editors. PARAKANYAA (talk) 18:17, 5 February 2025 (UTC)[reply]
    Why not a simple explanation of the pillars? I could say it features some of our best projectspace work. Aaron Liu (talk) 18:26, 5 February 2025 (UTC)[reply]
    How exactly then are we supposed to continue to attract new editors? Cremastra (talk) 20:46, 5 February 2025 (UTC)[reply]
    In my opinion, part of this exercise should be reconsidering what "main page type content" actually means. Thebiguglyalien (talk) 21:14, 5 February 2025 (UTC)[reply]
  • I looked at page views being driven by the Main Page, using the list of recent deaths from mid-December (the latest data in Wikinav). https://wikinav.toolforge.org/?language=en&title=John_Fraser_Hart is a typical example. Most of the page views for that article came from the link on the Main Page. This makes me wonder whether the question about "What do we want on the front page?" should be interpreted as "What 'categories' or 'departments' do we want?" (e.g., a box dedicated to WP:GAs) vs "What purposes do we believe the Main Page should serve?" (e.g., helping readers find the articles they want to read). I think that ultimately, no amount of rearranging the deck chairs is going to solve the fundamental problem, which is that we need the community to decide whether the Main Page is only for WP:PERFECT content, or whether the Main Page is for WP:IMPERFECT content, too. WhatamIdoing (talk) 05:15, 5 February 2025 (UTC)[reply]
    One of the more common positives of Wikipedia that RSs bring up is the speed and neutrality with which it covers even contentious current events topics. I would say that ITN does reflect the best of Wikipedia in a sense, even if the exact process needs revamping. -- Patar knight - chat/contributions 06:36, 5 February 2025 (UTC)[reply]
    I agree, and apparently our readers agree, too. Current events are one of the places where we shine – some of "the best", just not always "the most polished". WhatamIdoing (talk) 22:51, 6 February 2025 (UTC)[reply]
    It's not "Perfect", it's "quality enough". Very few people !voted option 3 due to perceived quality issues. Aaron Liu (talk) 02:30, 7 February 2025 (UTC)[reply]
  • This is not meant as an idea to replace ITN, but the top box on the main page is extremely sparse compared to any other Wikimedia project page. The top box should serve better as a welcome box to WP for any incoming link so should feature a search bar, links to the key pages about how to contribute to WP, and other similar links. The closest info for that is buried near the bottom of the current main page. --Masem (t) 05:18, 5 February 2025 (UTC)[reply]
    The search bar is at the top of the page. I do think it would be helpful to add at least a more explicit sign-up link or something. We already advertise that anyone can edit, which is sort of an WP:EASTEREGG link to an introduction page, and the number of editors. -- Patar knight - chat/contributions 06:41, 5 February 2025 (UTC)[reply]
  • You know what I'd love? Some widget that features articles on topics from around the globe. Maybe a map with a promoted article for each country, with irregular turnover (so that Burundi isn't expected to have the same frequency of front page-worthy articles as France does). The promotion could be handled by each country's wikiproject ꧁Zanahary꧂ 22:49, 11 February 2025 (UTC)[reply]
    Would love to see something done with WikiProjects. Even if ITN is kept, just get the featured list segment to budge up and introduce a new one Kowal2701 (talk) 23:05, 11 February 2025 (UTC)[reply]
    They're such a great idea—obviously, people will be more motivated to contribute to Wikipedia if they feel they have a community of other active editors passionate about the same topics as them. But they're totally out of reach for inexperienced editors, and the space for that valuable and enticing discussion is tucked in the talk pages of projectspace pages. ꧁Zanahary꧂ 23:24, 11 February 2025 (UTC)[reply]
An Android app screenshot from 2023
  • The Featured Picture would be a natural replacement for the ITN top right slot on the desktop view. Having a prominent picture at top right is our standard look and the featured picture is a logical complement to the featured article.
Otherwise, to see other existing possibilities then try using one of the Official apps. The Android app provides the following sections:
  1. Featured article
  2. Top read (daily most-viewed articles)
  3. Places (nearby articles based on the current location)
  4. Picture of the Day (from Commons)
  5. Because you read (suggestions based on a recently read article from your history)
  6. In the news
  7. On this day
  8. Randomizer (a random article with some filtering for quality)
  9. Suggested edits (suggestions to add content to Wikipedia)
And what's nice is that you can turn these sections on or off in your settings to customize the feed.
Andrew🐉(talk) 09:56, 6 February 2025 (UTC)[reply]

Front‽ Hah! Neither Google nor Bing, nor anyone pointing to Wikipedia for some reason, have taken me anywhere near it in decades. And none of the people who print Wikipedia into books and YouTube videos ever include it.

Whatever you do to it, though, it's probably best not to replace it with things from Project:Community portal, which is there for the potential editors in project space as opposed to the potential readers in article space. Whereever one may go when it comes to the content quality rules, the "main page" being article content as opposed to project content still remains as a distinction.

Unless you want to take the drastic step, which some wikis (e.g. German, Spanish, and Polish Wikipedias — de:Project:Hauptseite, es:Project:Portada, pl:Project:Strona główna) do take, which is to set the MediaWiki:Mainpage as somewhere outwith article space (vide de:MediaWiki:Mainpage). But then MediaWiki still has a distinct page (set at MediaWiki:Portal-url) for the "community" rather than for the readership.

Uncle G (talk) 07:28, 8 February 2025 (UTC)[reply]

  • There's quite a bit of users who commented in the ITN RfC that they found the box useful, so they must have checked the main page somewhat frequently.
    Main Page is in the article namespace solely because of inertia (from having too many links to it and stuff) and not because it's article content. And the Community portal only links to community forums, which is not what the "introduction to editing" suggestion entails. Aaron Liu (talk) 14:23, 8 February 2025 (UTC)[reply]
    • Hence why I said "drastic". However, it is article content. If it weren't, we wouldn't be having all of these discussions about how it should be the best example of our article content, or whether it should satisfy our Wikipedia is not a newspaper article content policy, or whether (if it is exempt from policy, a huge double-standard given everything else on the main page) it should be more like a real newspaper rather than an obituaries column. (Only 2 death notices, as I type this.)

      The best response to that question is to ask where, in amongst the DYK snippets from articles, the featured articles, the featured pictures, the snippets from the almanac pages, and the featured lists, does the questioner see the non-article content that leads xem to think that it isn't chock full of article content. It's a good question to ask why it's in article space, given that clearly it doesn't have to be and almost none of the ways in which Wikipedia gets re-used ever use it. It's not a good question to argue from the premise that it isn't article content, though. I wonder how many people really have, or whether that's been phrased as a straw man.

      Uncle G (talk) 13:19, 10 February 2025 (UTC)[reply]

  • Yes, the main page is checked quite frequently. It was the most viewed page in January actually - and had over 4.9 million views yesterday alone… ✈ mike_gigs talkcontribs 21:45, 8 February 2025 (UTC)[reply]
    • That's almost certainly bogus, since the $wgMainPageIsDomainRoot setting is turned on for Wikipedia and the sidebar hyperlink is not nofollow for starters. Notice how things are very different for the Wikimedia App, where one has to deliberately choose to go to the main page. Also notice that TopViews excludes the main page alongside excluding other things in the sidebar.

      Are people really still making the "the main page is what people primarily see of Wikipedia" argument? Not since the search engines started putting individual Wikipedia pages in sidebars on their search results, it isn't. I cannot remember who first shot that argument down by pointing that simple reality out, but it was almost a decade ago, shortly after Bing started doing it if memory serves. The most viewed page in January 2025 was really, and unsurprisingly, Donald Trump.

      Uncle G (talk) 13:19, 10 February 2025 (UTC)[reply]

      • Does it matter? Our job is to write and present encyclopedic content, not to rack up clicks. Wikipedia is not about page views. Thebiguglyalien (talk) 15:45, 10 February 2025 (UTC)[reply]
        • Obviously yes it does to all of the other people still making the long-since fallacious "the main page is what people primarily see of Wikipedia" argument, and clearly mike_gigs thinks that it matters. You are trying to have it both ways, now.

          I think that everyone should recognize that this argument from supposed popularity is fallacious, and has been for a decade. It's a lot of fuss about a page that actually not nearly as many people read as the bogus statistics, that the TopViews tool has been excluding for all this time, imply; and it's long since time to more strongly shoot down the "But it's our public face and our most-viewed page!" fallacy.

          Our public face for January 2025 was the Donald Trump article, which was also part of our public face for 2024 per Project:Statistics#Page views.

          I really would like to remember who made this argument all of those years ago, so I could give proper credit. Xe was right. I think that most of the people who concern themselves with the Main Page would find that if they ever stopped being involved in those processes, as simple readers like all of our other readers nowadays they would almost never go to it in the first place. Then perhaps discussions about what belongs on it would be less fraught and more relaxed.

          Mind you, the flip side is that discussions about the Donald Trump article would be even more fraught. ☺

          Uncle G (talk) 09:51, 14 February 2025 (UTC)[reply]

          I'm just pointing out that you are incorrect by saying nobody sees the Main Page, just because you haven't been anywhere near it in decades. And you calling the statistics bogus doesn't change them at all. We won't ever know how many people who land on the Main Page actually look at it, but saying that none of them look at it so we shouldn't even bother with this conversation is absurd.
          And simple readers like all of our other readers nowadays? Really...? ✈ mike_gigs talkcontribs 14:26, 14 February 2025 (UTC)[reply]
          The clickstream data for January shows that, even counting only the top ten most common destinations there were over 2.5 million (2,508,183) instances of people clicking on links on the main page (not including the search) and collectively links on the main page were clicked over 34 million times in that one month (I don't think that includes the search). 31.5% of the views of Deaths in 2025 came from people clicking the link on the main page. This clearly demonstrates that your (Uncle G's) assertion that nobody views or interacts with the main page is the one that is fallacious. Thryduulf (talk) 17:44, 14 February 2025 (UTC)[reply]
      • I'm not sure how being the domain root makes the statistic bogus. Aaron Liu (talk) 15:49, 10 February 2025 (UTC)[reply]
        • Then you need to think about it a bit more. The writers of TopViews did, back in 2015. The people who wrote about unintentional views at Project:Popular pages did, too, as did the people who came up with meta:Research:Page view and the Phabricator bugs tweaking all that for the PageViews and TopViews tools. Uncle G (talk) 09:51, 14 February 2025 (UTC)[reply]
          I don't see anything written to explain why, though. I'm guessing the argument is that readers usually use the main page to search for things. But even in that case, readers do see what is on the main page, especially the graphical content on the top. Not to mention the countless social media posts about main page content. If you know something else about the main page, could you elaborate? Aaron Liu (talk) 14:37, 14 February 2025 (UTC)[reply]

ADD translate.google.com into wikipedia

[edit]

Having a feature like translate.google.com integrated into Wikipedia could provide users with audio pronunciations and translations directly within articles, enhancing accessibility and language learning. Thanks deo! 2A06:5900:42A:F000:F05B:AF:54A7:FBB4 (talk) 15:09, 5 February 2025 (UTC)[reply]

Fairly sure there's already a browser extension for that. Aaron Liu (talk) 15:30, 5 February 2025 (UTC)[reply]
Also, not sure if either the Wikipedia community or the WMF would be okay with adding a non-transparent, non-open source commercial feature on the website like this. Chaotic Enby (talk · contribs) 16:12, 5 February 2025 (UTC)[reply]
Unless things have massively changed over there, WMF would certainly be against it. I think most of us here would be against it as anything other than an optional user script people could install too (I know I would). Anomie⚔ 00:55, 6 February 2025 (UTC)[reply]
I also would be against it, for that matter – not a great plan for a free encyclopedia to be dependent on commercial software for some features. Chaotic Enby (talk · contribs) 10:03, 6 February 2025 (UTC)[reply]
many mainstream browsers nowadays have this integrated natively into the software, ie Chrome would use Google Translate if the user right clicks to open the context options menu and then selects Translate this page. – robertsky (talk) 03:46, 6 February 2025 (UTC)[reply]
no, integrating a proprietary, closed source, often wrong service into Wikipedia runs contrary to its purpose Mgjertson (talk) 16:54, 5 February 2025 (UTC)[reply]
Well, I'm sorry to hear that people dislike this idea, because the community wrote a gadget for that years ago. It's in Special:Preferences#mw-prefsection-gadgets-gadget-section-browsing, third item. I don't recommend it because of phab:T156228 and phab:T65598. Also, as Robert and others point out, your web browser probably has that option for you anyway. WhatamIdoing (talk) 00:14, 7 February 2025 (UTC)[reply]
Yeah, the second phab ticket with respect to the Google-related privacy issues is what's especially concerning for me. While a minor shift key bug isn't a big deal, a potential breach of privacy by a private company's API is exactly what I would've expected from using proprietary software in our gadgets, and, well, I've made my opinion on it pretty clear already. Chaotic Enby (talk · contribs) 01:26, 7 February 2025 (UTC)[reply]
Not Google Translate, but Wikimedia now has its own translation service, mw:MinT, which uses open-source models. – SD0001 (talk) 09:37, 11 February 2025 (UTC)[reply]
That is actually much better, great to know! Chaotic Enby (talk · contribs) 16:41, 11 February 2025 (UTC)[reply]

Account deletion proposal

[edit]

I know that it is not possible to delete user accounts on Wikipedia. I was wondering if there could be a possibility of if an account is deleted, that there could be a placeholder that would look something like this: [deleted] The edit would remain there, but it would indicate that it was made by a deleted account. Hope to get some ideas. Interstellarity (talk) 16:16, 5 February 2025 (UTC)[reply]

See Wikipedia:Courtesy vanishing for how an account can be renamed to an anonymous string. isaacl (talk) 16:27, 5 February 2025 (UTC)[reply]
Edits legally must be attributable to someone. The best that can be done is a vanishing as isaccl describes. Identifying an edit as by "deleted" would be insufficient. 331dot (talk) 16:38, 5 February 2025 (UTC)[reply]
Now I'm curious, would there be a way to legally cede the copyright of your edits to the WMF or the community at large when vanishing? Chaotic Enby (talk · contribs) 16:55, 5 February 2025 (UTC)[reply]
Under Creative Commons, it would be CC0. Otherwise, it would be a Terms of Service thing whereby the registered user explicitly assign the copyright ownership of their contributions to WMF or the community (the latter would be a headache if there's a legal issue as the community isn't a legal body per se), and then WMF/community rededicates the contributions accordingly. I can imagine pushbacks if done so this way. – robertsky (talk) 01:27, 6 February 2025 (UTC)[reply]
You can never revoke your CCBYSA/GFDL license, but you can declare an additional CC0 license. Procedurally this would have many issues such as: (a) you make a derivative version of an existing article, even declaring CC0 right then, (b) someone else makes a future derivative. Well you can't relicense the edits before you, and the future edits are still going to not be in CC0 so it's not very useful for those wanting to reuse the page again in the future. One place something like that would likely have the most use would be if you upload original media and would like to add additional free-er licenses later. A utility to help with that might be useful, and discussing that idea over at commonswiki is probably the best venue. — xaosflux Talk 10:50, 6 February 2025 (UTC)[reply]
More generally, copyrights can be assigned, through contracts, your will, etc. However, I'm not sure whether the WMF would appreciate having someone unilaterally assign their copyrights to the WMF ("Hi Legal, so User:Example died, and left the copyright to all their edits to the foundation, so I have some papers for you...". WhatamIdoing (talk) 00:09, 7 February 2025 (UTC)[reply]
I do think that you can dedicate all of your contributions to the public domain (I’ve done that). JJPMaster (she/they) 10:44, 10 February 2025 (UTC)[reply]
I guess attribution is always maintained in the sense that actor.actor_id and user.user_id are retained in the database regardless of changes to the user_name. But user names must be unique, so I guess any kind of non-unique placeholder like [deleted] would have to happen outside the database. I'm not sure how it would be better than the current vanisheduser_somenumber or whatever it is now. Sean.hoyland (talk) 17:04, 5 February 2025 (UTC)[reply]

Random article button for specific wikiproject proposal

[edit]

Would be really nice if individual wikiprojects had their own random article button purely for articles under the scope of that wikiproject.

It would also help out stuff like random page patrol, as most users are more knowledgeable than others. I see that the featured article page already has a similar function, so would be great if we did this also to wikiprojects. Thehistorianisaac (talk) 09:19, 6 February 2025 (UTC)[reply]

This can be achieved with Special:RandomInCategory (for instance, Special:RandomInCategory/WikiProject Dinosaurs articles gives you a random dinosaur or dinosaur-related topic), and it could definitely be great to have that link available directly on WikiProject pages. Chaotic Enby (talk · contribs) 10:08, 6 February 2025 (UTC)[reply]
Thanks! Thehistorianisaac (talk) 10:19, 6 February 2025 (UTC)[reply]

A new hidden category for articles using raw HTML for built-in MediaWiki features

[edit]

For example, what will be in this category - an article using <i>...</i> for italic text instead of ''...'', or an article using <h2>...</h2> for lv. 2 header instead of ==...==. This will be useful to replace raw HTML with proper wikitext. 5.228.112.228 (talk) 22:27, 6 February 2025 (UTC)[reply]

Probably need to exclude div and span tags from this, those are everywhere. Also probably exclude anywhere with user signatures (talk pages, etc). Gnomingstuff (talk) 23:36, 6 February 2025 (UTC)[reply]
category for articles. 5.228.112.228 (talk) 09:05, 7 February 2025 (UTC)[reply]
See Wikipedia:WikiProject Check Wikipedia. It's already being handled. If you're interested in helping out, create a free account (only a username and password is needed; e-mail is optional) and join in. WhatamIdoing (talk) 00:00, 7 February 2025 (UTC)[reply]

Age in days

[edit]

How about adding whatever script would be required to include a person's age measured in days along with their approximate age in years among their personal details? Peter Jedicke (talk) 11:44, 7 February 2025 (UTC)[reply]

I'm not too sure how useful this would be, as well as how acceptable under WP:BLP, but we do have the template {{age in days}}. Phil Bridger (talk) 12:34, 7 February 2025 (UTC)[reply]
I mean, we could, but I don't see the point of this. Learning that someone is 3017 days old is honestly useless. There may be extremely select circumstances when this is needed, but that's no reason to include it. Cremastra (talk) 20:52, 7 February 2025 (UTC)[reply]
Why would someone need a person's age in days? 5.228.112.228 (talk) 22:32, 7 February 2025 (UTC)[reply]
Yeah lol. Your age in days becomes useless information after you are 1 month old. And besides, it would have to be updated daily, which is time consuming manually and resource intensive automatically. Gallus lafayettii (talk) 23:53, 8 February 2025 (UTC)[reply]
Honestly, I think this should be implemented as a joke every April fools day as "age in days as of April 1st." Gallus lafayettii (talk) 23:57, 8 February 2025 (UTC)[reply]

Geography, countries, image switcher : design improvement

[edit]

Hello, I have recently noticed that, plenty countries have only the ortographic projection as geography representation, I would just like to know if, it is necessary to add a second picture (ONLY FOR COUNTRIES WHICH DOES NOT HAVE AN IMAGE SWITCHER; like the majority of American, Asian and Oceanian countries). On the Indonesian version, an image switcher is present to the majority of the countries, it have the map of the country with the flag in it and it is presented like this (Kirgizstan actual article in Indonesian Language, to see the improvement of the geography representation, go on the second option of the image switcher to see the map.)). Please take time and feel free to answer me, if you want to go deeper with the subject, go on my talk page. Thanks. QwertyZ34 (talk) 19:58, 7 February 2025 (UTC)[reply]

Does this mean:
If so, it's already here. For example, Mexico contains both File:MEX orthographic.svg and File:Mexico states map w names.png. United Kingdom lets you switch between four maps. It is not used in all articles. This is probably because nobody bothered. You could WP:Be bold and add suitable maps where they are missing. WhatamIdoing (talk) 04:04, 9 February 2025 (UTC)[reply]
The linked id.wiki page switches to a flag map, these are not hugely encyclopaedic or helpful to a reader, and we should not boldly copy that. CMD (talk) 04:10, 9 February 2025 (UTC)[reply]
Yes, I know, I rather prefer to add a map of the country with the largest cities, than this. Please tell me if it is necessary or not, to add it. QwertyZ34 (talk) 15:32, 9 February 2025 (UTC)[reply]
Yes, that's why I want to add a second image in the infobox, like a map of Kyrgyzstan with its largest cities, it will be for sure better for the reader, and also more encyclopaediv, in the term of imformation. QwertyZ34 (talk) 15:34, 9 February 2025 (UTC)[reply]
You can add any second image you want. If someone disagrees, they'll revert it or change it to an image that they think is better. WhatamIdoing (talk) 17:25, 9 February 2025 (UTC)[reply]
And if you still think that your images are better, you can talk about it on the article talk page. Phil Bridger (talk) 18:15, 9 February 2025 (UTC)[reply]
Thanks for the information QwertyZ34 (talk) 22:20, 9 February 2025 (UTC)[reply]
Thanks for the imformation. QwertyZ34 (talk) 22:20, 9 February 2025 (UTC)[reply]

Would a filter to identify changes from "transgender" to man, boy, girl, female, woman be appropriate

[edit]

I'm seeing editors make such changes, presumably related to the Trump's making official there are only two choices, male or female. Doug Weller talk 12:19, 9 February 2025 (UTC)[reply]

Might not be a bad idea. A lot of that may start to happen in relatively unventilated corners (i.e., little-watched BLPs), and a filter could, in the first place, be helpful to figure out whether it is going to be a problem. --Elmidae (talk · contribs) 12:40, 9 February 2025 (UTC)[reply]
Maybe, provide some diffs as examples so we can evaluate from a technical perspective. — xaosflux Talk 12:58, 9 February 2025 (UTC)[reply]
I only have one right now.[5] Doug Weller talk 13:44, 9 February 2025 (UTC)[reply]
Notifying WP:EFR of this. Also agree with the proposal, presuming it's only logging rather than completely disallowing. The amount of false positives might be pretty high, so it's best that humans take a second look at them. Chaotic Enby (talk · contribs) 14:46, 9 February 2025 (UTC)[reply]
I would hope that most filters, apart from ones that deal with an urgent problem, start life by only logging, so we can get a better idea of how prevalent the problem is, how many false positives are thrown up etc. Phil Bridger (talk) 15:13, 9 February 2025 (UTC)[reply]
Oh definitely, and I'd also be interested in seeing the editors. Doug Weller talk 15:15, 9 February 2025 (UTC)[reply]
Is there an actual problem that needs fixing, or just the chance that there may be a problem some day? So far, it seems just the standard levels of vandalism. Cambalachero (talk) 15:20, 9 February 2025 (UTC)[reply]
I think it's a real problem - part of the problem that certain Wikipedia editors feel emboldened towards particular kinds of disruption by the current power shift in the US. Here's an example, with a specific reference to "the government" having ruled that trans women are men. Bishonen | tålk 15:35, 9 February 2025 (UTC).[reply]
So? Did that user edit articles in a way that this proposed filter would catch? All I see in that link is a user explaining his view over the way the article is written. And citing big proponents of a given idea (such as the government of the US) is a way to show the weight of that idea. Cambalachero (talk) 01:43, 10 February 2025 (UTC)[reply]
Sorry, I should have given the actual diff rather than assume it would be easy to find from the conversation I linked. Here it is. Bishonen | tålk 02:23, 10 February 2025 (UTC).[reply]
That doesn't add much. Remember, the proposal here is about a specific type of vandalism (changing pronouns from biographies), and an edit filter that would detect those; not about the presence of editors with certain ideas. But before implementing a solution for a problem (which requires time, resources, and editor's work) we need to know that the problem actually exists (because if it ain't broke, don't fix it). For example, 10 or 15 examples of such vandalism reverted on the last week. Cambalachero (talk) 13:20, 10 February 2025 (UTC)[reply]
Here's a two-edit diff from a brand new account today, undoing an announcement of trans status and updating of pronouns that had happened just yesterday in the face of the subject's public announcement of trans status. No visible alarms were triggered other than reference removal. Not the precise text change originally noted by OP, but pronoun reversal and in general an example of what we're facing. -- Nat Gertler (talk) 20:53, 10 February 2025 (UTC)[reply]
I think Special:AbuseFilter/1200 tries to catch some versions of this, but limited only to BLP articles. 86.23.109.101 (talk) 20:26, 9 February 2025 (UTC)[reply]
  • What I would filter for is something along the lines of... changes from one gendered word to another (pronoun or gender-identifier), especially on articles categorized as trans-related in some way, and particularly on biography articles for trans individuals. Some false positives are inevitable and there's no way to catch everything, but it could probably get the number flagged for review down to a reasonable number and could catch a lot of the blatant "someone sweeps in and changes pronouns throughout the article" stuff. --Aquillion (talk) 20:35, 9 February 2025 (UTC)[reply]
    Even "someone sweeps in and changes pronouns throughout the article" is occasionally going to be correct, such as when some notable person first publicly comes out as transgender, so human review will always be needed. However flagging them so that humans know there is a need for review seems like a very sensible idea. Thryduulf (talk) 23:56, 9 February 2025 (UTC)[reply]
    Special:AbuseFilter/1200 covers most of what you mention (it flags people changing a bunch of pronouns on a trans person's page), but if people want more filters like that, diffs are useful - generally it is hard to create a useful filter without a few diffs which help to figure out patterns that can be filtered for. Galobtter (talk) 01:49, 10 February 2025 (UTC)[reply]
Hmm. Just reverted one last night (sorry not sorry for the RV edit summary). Did this pop up on the filter? I can't check, I assume. --Elmidae (talk · contribs) 11:06, 10 February 2025 (UTC)[reply]
@Elmidae I don't see it here.[6].. Doug Weller talk 13:33, 10 February 2025 (UTC)[reply]
@Galobtter That filter looks good but of course doesn't have "transgender" in it. And It looks as though it didn't pick on up last night. Doug Weller talk 13:34, 10 February 2025 (UTC)[reply]
The general idea of a filter sounds good. Even better if it can capture articles with trans or transgender in as well. Lewisguile (talk) 18:31, 10 February 2025 (UTC)[reply]
I saw the request for diffs so I had a look at edits I had reverted in the recent past. I thought I had more diffs to hand than I do. In many cases I see these bad edits after somebody else has already reverted them. Even so, I've found a few and I think we can extrapolate a few patterns from them. Let's try to break them up into categories and suggest some possible rules.
Flag on addition of phrases "Trans identified men" and "Trans identified women". These are never legitimate except when discussing the dog-whistle phrases themselves.
  • Suggestion 2:
Flag on changing "trans/transgender woman/women" to a phrase containing "man/men/male/males"
Flag on changing "trans/transgender man/men" to a phrase containing "woman/women/female/females"
  • Suggestion 3:
Flag on addition of common slurs, particularly when used to replace "trans" or "transgender". Whitelist articles that specifically discuss the slurs as they will need to contain them.
Flag on replacing "cisgender" or "cis" with "biological", "actual" or "real"
(Not sure how much a filter can help with this type.)
  • The Ferengis:
    • I didn't find any examples of this in my recent reverts but we should probably flag for changing any gendered term to "males" or "females". I'm not sure if my suggestion 2 covers this sufficiently.
And finally, here is a good example of a troll trying to leverage Trump's pronouncements as an excuse to censor Wikipedia. I don't think that can be dealt with by a filter. Maybe a FAQ would help or maybe it would just invite more of the same.
--DanielRigal (talk) 19:20, 10 February 2025 (UTC)[reply]
Not sure if this would count as recent enough, but this is another example, non blp but another example, this edit stayed around for a month so it would have been useful to have been flagged. It used the phrase "trans-identified males" so we might have to do quite a few variations to be able to flag this kind of language appropriately. LunaHasArrived (talk) 09:12, 17 February 2025 (UTC)[reply]

Only 1 of those diffs is from the last week. So far, it seems like a minor problem that can be perfectly dealt with with the current anti-vandalism tools. Cambalachero (talk) 19:57, 10 February 2025 (UTC)[reply]

@Cambalachero you really seem to object to this. But you aren’t being asked to do any work here, why try to stop it from being created? Doug Weller talk 20:08, 10 February 2025 (UTC)[reply]
I don't think it's relevant, but if you need to know, I don't like edit filters. They make the watchlist increasingly busy. I understand why they are there, but I would prefer them to be added only when really necessary, when there's an actual ongoing problem to fix, not "just because", because each new filter adds some extra technical gibberish next to many watchlist entries. As said, don't fix it if it ain't broke. Cambalachero (talk) 01:06, 11 February 2025 (UTC)[reply]
@Cambalachero Tagging and logging are separate things. Tags are what you see adjacent to a watchlist entry (e.g. "possible unreferenced addition to BLP"), the log is a list of edits that have matched the given filter that you have to actively look at to be aware of. For example the edit to South Korea at 05:28, 11 February 2025 is listed in the log for filter 833 but this is unknowable if you look at the edit history or see the edit in your watchlist. Thryduulf (talk) 05:41, 11 February 2025 (UTC)[reply]
Seems fine, then. Cambalachero (talk) 18:07, 11 February 2025 (UTC)[reply]

I don't see any problem with a logging only filter to attempt to catch changes in pronouns or the addition/removal of "transgender". I do, however, want to point out that a filter that looks for "trans" or "trans-" or "trans " potentially cause many false positives from science articles, where trans (and cis) can be used to describe cis–trans isomerism of a molecule. In the chemical names, this would be (properly) written as trans-(name of molecule) or cis-(name of molecule). But after it's first referred to, it is common to simply refer to "the trans isomer" or similar, rather than repeating the whole name. I suspect there may be a way to account for this in the filter design to reduce the false positives. -bɜ:ʳkənhɪmez | me | talk to me! 20:06, 10 February 2025 (UTC)[reply]

Yeah. That's definitely a risk. If the filter can handle it, it might make sense to do something like:
  • On any article, if they mess with "transgender", "trans woman" or "trans man" then apply the filter. The risk of false positives is small.
  • Only apply the filter on "trans" if the article has categories indicating that it is about transgender people or topics or if "trans" is linked to an article about a transgender topic.
I think that would be enough to avoid stomping on any chemistry articles, unless there are any transgender chemists who specialise in isomerism, in which case I guess that's one to whitelist.
I agree that logging only is the best way to go, except maybe for the outright slurs. --DanielRigal (talk) 20:38, 10 February 2025 (UTC)[reply]

Is this idea limited to just English Wikipedia? If so, then a gadget perhaps. Of course, a user would have to go to user preferences to enable that. For logged-out users, that's a huge challenge, and an edit filter would be too limiting. If the issue goes beyond English Wikpedia, then why not take this to Meta-wiki RFC? George Ho (talk) 18:41, 17 February 2025 (UTC); edited, 20:05, 17 February 2025 (UTC)[reply]

Really not sure why a gadget would be more useful than an edit filter, as those already have the functionality we're looking for. And yes, this is for the English Wikipedia. Chaotic Enby (talk · contribs) 19:22, 17 February 2025 (UTC)[reply]
Personally, I'm not a fan of edit filtering except in Commons and to combat spamming and questionable sources. As I fear, any more of edit filtering would lead to more outrage and attempts to bypass the filter. IMO, a gadget would appease those who would make preferences as they see fit without having to edit (over and over probably). George Ho (talk) 19:35, 17 February 2025 (UTC); struck, 20:05, 17 February 2025 (UTC)[reply]
As I fear, any more of edit filtering would lead to more outrage and attempts to bypass the filter. To clarify, we're talking about a filter for logging, not for disallowing the edits. We already have more than a thousand edit filters for various purposes, and many of them just log the edit in the edit filter log (the edit isn't even tagged in the history page, and shows up as normal). Chaotic Enby (talk · contribs) 19:54, 17 February 2025 (UTC)[reply]
As I realized, even as a longtime Wikipedian, I'd been unfamiliar with logging-only filtering (or "log the edit" setting/option as WP:Edit filter guideline calls it) until now. George Ho (talk) 20:05, 17 February 2025 (UTC)[reply]
Someone seeking to make such edits would not activate a gadget that logged the edit (or that tried to block it), so I don't think it would help. isaacl (talk) 19:55, 17 February 2025 (UTC)[reply]
Rescinding my gadget suggestion then. George Ho (talk) 20:05, 17 February 2025 (UTC)[reply]

Index of Deleted Pages (Categorized and or Searchable by Topic)

[edit]

A wish for the benefit of subscribers who may hold memory of a page that had existed and find no redirection that relates to the topic. Each item in this Deleted Articles index might hold a jumplink to the actual deleted article, which itself is of course only accessible to admins. There might be appended right to each index item a coded reason for the article deletion.
Case in point, this user wanted to know what happened to the article on Technofeudalism. Googling "Technofeudalism Wikipedia" gets a "redirect" to Neo-feudalism as the first hit, but there are no redirects from Technofeudalism in the Wikipedia article for Neo-feudalism. If it is known by this index there once existed a page for Technofeudalism, the Neo-feudalism page can be updated, if not, there may be a case for a separate and new page for Technofeudalism.
Such an index may fill some of the gaps Deletionpedia had covered, it's clear the formulation and structure would require the drawing on considerable resource particularly if a search term can rely on keywords within the deleted articles. Also possibility for a bot. Lmstearn (talk) 14:32, 14 February 2025 (UTC)[reply]

Many deleted pages should not be searchable and we often even hide the fact that an article has ever existed at a certain name. (some vandals like to create pages with titles like "Kusma's phone number is 1-812-555-6969, call today for [illegal activity]"). Making metadata about deleted pages more available than through the deletion log risks leaking all kinds of private data and would require substantial effort; also, to help with issues like the one mentioned above you might need to search not just the top revisions of deleted pages, but also content that is hidden away in old revisions of pages that used to be articles and are now redirects (or deleted). I don't think this is feasible, and I also do not think it is desirable without a huge amount of manual effort that would further reduce the feasibility. —Kusma (talk) 14:47, 14 February 2025 (UTC)[reply]
Would you please you explain your use case example more? Are you trying to provide an example of a page that was deleted? I'm not seeing such a page deletion. — xaosflux Talk 15:03, 14 February 2025 (UTC)[reply]
Neither did I, but someone there claimed in that [page] they did. The point is a subscriber may wish to know whether a page had ever existed. For example, Google might throw hits for a search term like "Wubblies", but there is no Wikipedia page for that, so one may wish to to know if a page for "Wubblies" was ever published in Wikipedia. And yes, the Deleted Articles index would not want to contain vandalised data.Lmstearn (talk) 15:28, 14 February 2025 (UTC)[reply]
The deletion log is publicly viewable and can be used to determine whether a page by a given title ever existed, and if it did why it was deleted. This does not page titles that have been oversighted (e.g. for containing private information), which are not visible even to administrators, but it is very unlikely that someone other than the page creator will be looking for that. Searching the contents of deleted pages is not something that will ever happen. Thryduulf (talk) 18:01, 14 February 2025 (UTC)[reply]
Exactly what was required, thanks! Lmstearn (talk) 02:24, 15 February 2025 (UTC)[reply]

A limit on an editor's unsolicited responses to an AfD discussion??

[edit]

I'm wondering if it would be helpful to have some sort of limit on how many responses a person can post in a single AfD discussion.

The background to this is that I've noticed it's increasingly common for an editor to appoint themselves as "prosecution" or "defence" attorney in an article's discussion, and respond to every !vote that they disagree with, often in very terse, dismissive (borderline aggressive) language. This has a very chilling effect on discussion.

AfD is poorly attended. It's desperately important, because decisions at AfD can leave utter junk in Wikipedia, or remove valuable subjects. Decisions like this ideally shouldn't be taken based on a consensus of just three editors! We should be encouraging more participation, but if potential contributors get intimidated into submission by aggressive disagreement backed up by a ferocious dollop of Wiki-acronyms, is it surprising people steer clear?

Almost all of the follow-ups are unhelpful. People who close AfD discussions know the policy. They don't need to read diatribes from editor A about how editor B has failed to read N:PROF or GNG. Extra words just mean more to read.

There are situations where multiple responses may be needed, for example where a delete-voter asks if someone active in editing the article can find additional sources. For this reason, I think maybe a blanket "one response per AfD only" might not work; we might need to allow follow-up answers to direct questions.

WP:BLUDGEON is supposed to deal with this problem, but is itself a blunt instrument. Being accused of bludgeoning is no fun, and just makes people get defensive and polarised. A more concrete limit might make it easier for people to know how far they can go, without bludgeoning. To be honest, I can't see how most people responding to an AfD need to do more than a single statement of why they think the article should be deleted or kept, and leave it at that.

Any thoughts? Elemimele (talk) 17:31, 14 February 2025 (UTC)[reply]

One reason why I don't take part in AfD discussions nearly as much as I used to is that I could see them becoming more of a vote and less of a discussion. I see this proposal as exacerbating that tendency, and so a step in precisely the wrong direction. The one proposal that I would make is to discourage (or at least stop encouraging) people from making bold "keep" or "delete" opinions, which seem to stop people changing their minds in response to the discussion. Phil Bridger (talk) 17:49, 14 February 2025 (UTC)[reply]
You don't need to respond to such attorneys, especially if they don't bring up new arguments. If their walls of text and aggression endure after asking them to stop, you could ask an administrator for their view. Aaron Liu (talk) 18:04, 14 February 2025 (UTC)[reply]
I don't see how a hard limit would work in practice. However, I was surprised to find that there was no mention of the etiquette around responding to other people's comments in the AfD instructions; perhaps a note there to say that responding to all or multiple comments is often unproductive and can constitute bludgeoning? Espresso Addict (talk) 23:49, 16 February 2025 (UTC)[reply]

A way to view edits made to a user's talk page, as a "diff"

[edit]

Seeing what other editors have had to say about another editor is a useful tool, which is limited of course when potentially problematic editors just delete every negative interaction. It would of course be useful to have a tool which would allow one to view the activity on someones talk page, as a "diff". That may be contrary to an assumed or actual goal of Wikipedia, which may be to allow someone to make a fresh start or some such, which I can respect. Also, I have to figure such a tool would hit the Wikiservers kind of hard, so it may be undesirable to allow such functionality. Marcus Markup (talk) 14:40, 17 February 2025 (UTC)[reply]

You can already view revision diffs on anypage, including user talk pages. For example, here is a link to just that on your own talk page: https://wiki.riteme.site/w/index.php?title=User_talk%3AMarcus_Markup&diff=1276205804&oldid=1276205492 — xaosflux Talk 14:44, 17 February 2025 (UTC)[reply]
What I meant was... without having to open each red link on the edit history. Because for some editors, that could take some time. I'm talking about a one page solution. Marcus Markup (talk) 14:46, 17 February 2025 (UTC)[reply]
mw:Extension:RevisionSlider provides a timeline-based approach for history pages. It could simplify on how you access the history and grasp the activity there. It is at the top of the page for any diff you check. Maybe it would help? Trizek_(WMF) (talk) 16:31, 17 February 2025 (UTC)[reply]
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(idea_lab)&oldid=1276252530"