Jump to content

Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:IDEALAB)
 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, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66


[edit]

For topics which may not yet meet Wikipedia's inclusion criteria for articles, but for which relevant information is present across multiple articles (such that an editor may have difficulty deciding which page to redirect to), there should be a type of mainspace page dedicated to listing articles in which readers can find information on a given topic. A page of that type would be distinct from a disambiguation page in that, while disambig pages list different topics that share the same name, a navigation page (or navpage) would include a list of articles or sections that all contain information on the exact same topic. In situations where a non-notable topic is covered in more than one article, and readers wish to find information on that particular topic, and that topic can't be confused with anything else (making disambiguation unnecessary), and there turns out to be two or more equally sensible redirect targets for their search terms, then a navpage may be helpful.

Rough example #1

Wikipedia does not have an article on the Nick Fuentes, Donald Trump, and Kanye West meeting, but you can read about this topic in the following articles:

You can also:

Rough example #2

Wikipedia does not have an article on Anti-Bangladesh disinformation in India, but you can read about this topic in the following articles:

You can also:

Besides reducing the prevalence of red links, navpages can also be targets for other pages (e.g. Trump dinner) to redirect to without being considered double redirects. – MrPersonHumanGuy (talk) 16:23, 13 March 2025 (UTC)[reply]

This is a cool idea! Toadspike [Talk] 11:51, 18 March 2025 (UTC)[reply]
I also agree! I'm thinking some disambiguation pages tagged with {{R with possibilities}} could make good navigation pages, alongside the WP:XY cases mentioned above. At the same time, we should be careful to not have any "X or Y" be a navigation page pointing to X and Y – it could be useful to limit ourselves to pages discussing the aspects together. Chaotic Enby (talk · contribs) 13:26, 18 March 2025 (UTC)[reply]
Good idea – people seeing the nav page and how it is split across more than one article could also help drive creation of broad-topic articles. Cremastra (talk) 23:40, 18 March 2025 (UTC)[reply]
Also noting that the small text If an internal link led you here, you may wish to change the link to point directly to the intended page. might not necessarily be needed, as it can make sense to link to navigation pages so readers can have an overview of the coverage, and since that page might be the target of a future broad-topic article. Chaotic Enby (talk · contribs) 23:50, 18 March 2025 (UTC)[reply]
This seems a useful idea. As a similar example I'd like to offer Turtle Islands Heritage Protected Area, which I created as an odd disambiguation page because it was a term people might search, but with little to say that wouldn't CFORK with content that would easily fit within both or either or the existing articles. CMD (talk) 01:32, 19 March 2025 (UTC)[reply]
This is great. I often edit articles related to PLAN ships, and since many ships currently lack articles, we cannot use disambiguation pages for those ships(e.g. Chinese ship Huaibei, which has two different frigates with the same name). This could really help out a lot. Thehistorianisaac (talk) 03:33, 21 March 2025 (UTC)[reply]
This seems like a useful idea. It would benefit readers and probably save time at RFD and AFD. Schützenpanzer (Talk) 15:16, 22 March 2025 (UTC)[reply]
Throwing my support behind this as well. It would be very useful in cases where AFD discussions find consensus to merge the contents of an article into multiple other articles. -insert valid name here- (talk) 05:01, 3 April 2025 (UTC)[reply]
I've just come across Ethiopia in World War II, which is effectively already doing this under the guise of a WP:SIA. CMD (talk) 08:13, 13 April 2025 (UTC)[reply]
Should I WP:BOLDly create {{navigation page}} and put it there? Chaotic Enby (talk · contribs) 12:20, 13 April 2025 (UTC)[reply]
This would be very bold, but no opposition has been raised? If you do, please put it on Turtle Islands Heritage Protected Area too. CMD (talk) 00:10, 14 April 2025 (UTC)[reply]
Done for both! About the technical aspect of things, I added the "you can also search..." in the template (as it could be practical) but it might look less than aesthetic below a "See also" section. I made it into an optional opt-in parameter, is that fine? Chaotic Enby (talk · contribs) 07:34, 14 April 2025 (UTC)[reply]
Also did it for Nick Fuentes, Donald Trump, and Kanye West meeting, with a hidden comment to not convert it into an article per AfD consensus. Chaotic Enby (talk · contribs) 08:07, 14 April 2025 (UTC)[reply]
If this sort of page type is to be used for topics without independent notability (including deleted through an AfD), perhaps it should just drop that part and simply say "You can read about the Nick Fuentes, Donald Trump, and Kanye West meeting in the following articles"? Those with the potential to be expanded could be integrated into the hidden Template:R with possibilities system or something similar. CMD (talk) 08:50, 14 April 2025 (UTC)[reply]
I already added a parameter for that part (on the Fuentes-Trump-West meeting, the link inviting to create the article is not present). But yeah, removing it entirely as an optional parameter could also make sense. Chaotic Enby (talk · contribs) 08:53, 14 April 2025 (UTC)[reply]
Also thinking about the Poor people's rights search below, removal seems best. Alternatively, flipping it so that it is the prompt to create a page that is the optional addition might provide the desired goal while erring on the side of not encouraging creating poorly scoped articles. CMD (talk) 01:49, 15 April 2025 (UTC)[reply]
I also decided to take the liberty of creating a new category and another page (albeit an essay in development) to go along with the new page type. – MrPersonHumanGuy (talk) 01:41, 15 April 2025 (UTC)[reply]
Great job! Just wondering, it makes sense for topics that might be notable but haven't yet been written about (such as Ethiopia in World War II) to be navigation pages, should that be included in the graph? (Also, wondering if this whole conversation should maybe be moved to Wikipedia talk:Navigation pages instead of being pinned here) Chaotic Enby (talk · contribs) 16:10, 15 April 2025 (UTC)[reply]
Also, once that is all done, we should probably update {{Dmbox}} so navpages are a parameter, to avoid them being automatically detected as disambiguations (although that's not really that big of a deal). Chaotic Enby (talk · contribs) 16:15, 15 April 2025 (UTC)[reply]
I think we should decide early on, should this be allowed to have some context or info like WP:SIA? Maybe some content, which not enough for notability (the reason why it's not an article)? ~/Bunnypranav:<ping> 12:04, 15 April 2025 (UTC)[reply]
Yes, I think the amount of info allowed for SIAs should be the minimum along with a brief outline of the topic. Thryduulf (talk) 12:34, 15 April 2025 (UTC)[reply]
@MrPersonHumanGuy Could you possibly implement this in the draft you are writing? :) ~/Bunnypranav:<ping> 14:05, 15 April 2025 (UTC)[reply]
I'm wondering if Poor people's rights, currently being discussed at Wikipedia:Redirects for discussion/Log/2025 April 13#Poor people's rights, might be a candidate for this sort of page? Thryduulf (talk) 10:26, 14 April 2025 (UTC)[reply]

I am not convinced this is a good idea. Of the existing navpages, I boldly redirected Ethiopia in World War II; Armand Biniakounou, Glove and Boots, Amari McCoy, Turtle Islands Heritage Protected Area, and Skillsville all just feel like poor man's duplicates of search that will inevitable go out of date as the will to maintain them won't exist; Goldie (TV series) only isn't that because the term is ambiguous, and the only exception is Nick Fuentes, Donald Trump, and Kanye West meeting. * Pppery * it has begun... 16:37, 18 April 2025 (UTC)[reply]

I also have some concerns about navigation pages. They do indeed seem like they could require a lot of maintenance (especially if they are linking to sections. renaming a heading would break the links). It also seems like this could encourage fragmentation. Perhaps the better approach would be to pick one spot for something like Nick Fuentes, Donald Trump, and Kanye West meeting (pick a section in one of the articles), and redirect to that. Perhaps {{Navigation page}} might need to go to TFD to have a wider discussion to determine if it has consensus. –Novem Linguae (talk) 18:53, 18 April 2025 (UTC)[reply]
I am also unconvinced this is a good direction of travel. The article on the meeting of these three men was deleted; if we think this is a worthy article title, shouldn't we just have the article? There is a longstanding tradition at WP:RFD to delete ambiguous redirects and to rely on our search function instead, see WP:XY. Do we really want to have "navigation pages" for every single sports rivalry (mentioned in articles about both teams), relations between countries that do not suffice for a separate article? Amari McCoy is just bad: it is a bluelink that should be a redlink to show we do not have an article, and it is impeding the search function. If an article could potentially be created, a "navigation page" will impede actual article creation and (in the future) deny the creation credit (and the relevant notifications) to the actual article creator. —Kusma (talk) 19:17, 18 April 2025 (UTC)[reply]
Amari McCoy just looks silly. Why are there references all over a navigation page? That looks like a stub article to me. ~WikiOriginal-9~ (talk) 19:20, 18 April 2025 (UTC)[reply]
Additionally the "navigation page" hides the existence of Draft:Amari McCoy, which would be visible when visiting the red link. —Kusma (talk) 21:41, 18 April 2025 (UTC)[reply]
I would be okay with this one being deleted, as it doesn't actually contribute to navigation in any useful way (none of the target articles do more than list her as one of many actors). However, I mildly disagree with your point about article credit, as it isn't meaningfully different from the current situation with redirects. More generally, I do believe that navigation pages could be useful in a specific case (where there is a substantial amount of information about the same topic on several pages), but that they shouldn't abused to link to every single page that namechecks a subject. Chaotic Enby (talk · contribs) 23:14, 18 April 2025 (UTC)[reply]
I don't think redirects should be given creation credit either. ~WikiOriginal-9~ (talk) 23:17, 18 April 2025 (UTC)[reply]
I think we agree on the point that creating a redirect/navpage shouldn't give you creation credit. But that alone doesn't mean the page type shouldn't be kept, otherwise one could argue that redirects should be deleted for the same reason. Since navpages are functionally intended as multi-redirects, I believe the analogy especially makes sense. Chaotic Enby (talk · contribs) 23:25, 18 April 2025 (UTC)[reply]
I also agree. Even though I created The Book of Bill as a redirect, it was Googabbagabba who ultimately filled it with meaningful article content and thus the one who should've been notified when the article was linked with a Wikidata entry. Nonetheless, I don't think "another editor wants to create an article under this title" would be considered valid rationale for deleting a redirect or navpage. – MrPersonHumanGuy (talk) 00:16, 19 April 2025 (UTC)[reply]
I'd also seen Goldie (TV series) and think it looks like an unholy amalgam of a stub article and a navigation page: it should be one thing or the other, not both. I suppose my principal concern is that permitting adequately-sourced and verifiable content about an otherwise non-notable subject in a legitimate navpage is effectively quite a backdoor to a Wikipedia article about a non-notable subject. Cheers, SunloungerFrog (talk) 20:12, 18 April 2025 (UTC)[reply]
The Goldie page is ridiculous; it should just be a stub. I think navpages have a very specific application: a topic that for whatever policy-based reason does not belong in mainspace as a standalone page but is discussed in multiple pages. I would oppose them having any references or additional formatting at all. It should basically a multiple-choice redirect. Dclemens1971 (talk) 20:44, 18 April 2025 (UTC)[reply]
For the avoidance of confusion, I've turned the page into a stub because it is. Old revision that everybody's talking about is here: Special:Diff/1286214323. GreenLipstickLesbian💌🦋 21:09, 18 April 2025 (UTC)[reply]
Yep, agree with you. I would even clarify that the subject should be discussed relatively in-depth in multiple places, so we don't get lists of articles that namedrop a subject like Amari McCoy. Chaotic Enby (talk · contribs) 23:16, 18 April 2025 (UTC)[reply]
  • Housekeeping note: I've notified WP:WikiProject Disambiguation about this discussion. Mathglot (talk) 23:11, 18 April 2025 (UTC)[reply]
  • I didn't really expect this to go anywhere so I'll now elaborate on "This is a cool idea!". I think these pages can fill a narrow but present gap in our page ecosystem. Essentially, topics where there is more than one possible redirect target about the same subject, which distinguishes them from DABs, which have more than one possible redirect target about different subjects.
Also, since it's relevant to this discussion, I closed an AfD as "Navify" earlier today – feedback from others on the close and the resulting nav page (Armand Biniakounou) would be appreciated. I thought nav pages had been fully approved by the community, but I was clearly mistaken – if I had known that this is still being discussed, I may have closed this AfD differently or not at all. Toadspike [Talk] 00:07, 19 April 2025 (UTC)[reply]
I also misjudged consensus the same way, and that caused me to get carried away until I checked this page again and learned that not everyone was on board with the whole navpage idea, at which point I decided to pull the brakes and stop creating any more navpages. As for Amari McCoy, the fact that two stubs were being suggested for navification was what gave me enough guts to create that navpage in the first place. My reasoning was that "If these athletes can get navpages even though other articles only mention them as entries in lists, then that logic can be applied to other topics as well." In hindsight, that may not have been such a good idea after all. – MrPersonHumanGuy (talk) 01:06, 19 April 2025 (UTC)[reply]
I think your approach was reasonable. Sometimes you need to ramp up a bit to get wider community feedback. I didn't make a decision about this idea until I saw some actual articles with the template. Anyway thank you for stopping now that this is becoming a bit more controversial. –Novem Linguae (talk) 01:13, 19 April 2025 (UTC)[reply]
  • I think the gun was kind of jumped with this, though the topic was posted one month ago. Some more voices weighing in on this would likely be helpful. --Schützenpanzer (Talk) 00:15, 19 April 2025 (UTC)[reply]
  • Chaotic Enby mentioned something above about namedropping a subject, which seems to be similar to something I've been mulling over, and trying to decide how to formulate my concern. Let me start by turning your attention to the issue of WP:NOTTRIVIA just for a moment. I know there are lots of editors who love to dig up every place their fave character was ever mentioned, and there are folks on all sides of the question of sections like "FOO in popular culture". I remember how discouraged I was when I found that the relatively short article on a medieval French poet was about 50% allusions to modern popular culture items which in my view contributed nothing to an understanding of the poet. When you have a good search engine, it becomes trivial to dig up obscure allusions of this type, and so people do.
Transfer that thought now to the nav page concept. At first blush, it kind of seems like a good idea, but how might it morph in the future, and are we maybe opening Pandora's box? Suppose the good guys all do it the right way for a while, and then enthusiastic new editors or SPAs or Refspammers or social media types get wind, and all of a sudden it explodes in popularity and these pages become heavy with idiosyncratic additions based on somebody's fave niche reference? Will we end up needing new guidelines to specify what is or isn't a proper entry? Are we setting ourselves up for a possible giant future maintenance burden for regular editors? Mathglot (talk) 00:53, 19 April 2025 (UTC)[reply]
That is indeed a very good point, and this is why we should, in my opinion, have these guidelines ready before having navpages deployed on a large scale. While every new article or page can be seen as a "maintenance burden", navpages should fill a very small niche: subjects where in-depth content can be found on several pages, but which do not fit the notability guideline by themselves. This should be a much stronger criterion than simple mentions, and likely only apply to borderline cases where notability isn't very far away. Chaotic Enby (talk · contribs) 10:51, 19 April 2025 (UTC)[reply]
Do you have a single example of a subject where we should really have such a navigation page? Everything we have above is "mentions" (we certainly shouldn't allow those, or we will soon have thousands of genealogy stubs on non-notable minor nobility disguised as "navigation"), with the longest discussions being those of the "meeting" above, which are a short paragraph each and fairly repetitive with little critical commentary. If that is the best use case for the concept, I think the negatives strongly outweigh the positives for this idea. —Kusma (talk) 11:36, 19 April 2025 (UTC)[reply]
It was a better situation for Ethiopia in World War II, which probably could be an article, but in the meantime the various links would have been very helpful to readers. Now it is a redirect to an article subsection covering a time period mostly before WWII that also does not cover most of WWII. CMD (talk) 12:49, 19 April 2025 (UTC)[reply]
The classic solution "just write a stub" still looks superior to having a "navigational" pseudo-article to me in that case. —Kusma (talk) 13:07, 19 April 2025 (UTC)[reply]
The stub is much less helpful than some very simply laid out links to multiple not-stubby articles. CMD (talk) 13:15, 19 April 2025 (UTC)[reply]
I agree that the navigation page at Ethiopia in World War II was much more helpful than the current redirect, and I'm not sure what benefit a stub would bring given that we have existing coverage of the topic in multiple places already. Thryduulf (talk) 13:57, 19 April 2025 (UTC)[reply]
I also agree this navpage was better than a redirect. Skarmory (talk • contribs) 05:13, 21 April 2025 (UTC)[reply]
Maybe "just write a stub" situations should be encouraged to have See also links pointing to potentially useful targets. Skarmory (talk • contribs) 05:10, 21 April 2025 (UTC)[reply]
@Kusma Do you think the navpage (Armand Biniakounou) resulting from the AfD I linked is a good use? The two articles it links to don't have in-depth content, but there were two equally-good redirect targets and a consensus to redirect. Toadspike [Talk] 16:17, 19 April 2025 (UTC)[reply]
I think that is terrible. The bluelink promises we have nontrivial information, but there is only a trivial mention in a table. This is what fulltext search is made for. —Kusma (talk) 19:27, 19 April 2025 (UTC)[reply]
Very true. But – and I'm trying to understand the entirety of your argument, not be contrarian – the alternative is a redirect to one of the two bluelinks. This would equally promise nontrivial information, except it only provides half of the information we have.
In this case there was consensus to preserve the edit history; the need for a placeholder limits our options. Toadspike [Talk] 19:46, 19 April 2025 (UTC)[reply]
Speaking not from a Wikipedian's perspective but a reader's perspective, I would be annoyed by that article. The formatting's a bit weird, and it's trying to tell me that it's not an article, but I can see very clearly with my own two eyes that it's just a short article that tells me this man has been in the Olympics, twice. Despite the promise in the template, clicking on those links does not give me any additional information about him. Also, there's a bunch of unsourced biographical details in the categories? My reader self doesn't understand why those aren't in the article. Additionally, I can only see those facts in desktop view, so if I send the article to my friend to tell them that Wikipedia says this sprinter was born in 1961, they're going to be very confused.
On a related note, I think understand ATDs in an abstract way, but it's very annoying when you're a reader, you're trying to look something up, you know Wikipedia used to have an article about the subject, but now you find yourself on a nearly unrelated page that doesn't seem to mention the topic at all? Or, if it does, only very briefly as one entry in a table? It's very frustrating and I don't like it. GreenLipstickLesbian💌🦋 20:06, 19 April 2025 (UTC)[reply]
I understand all your points. The issue is that this case ties into the broader debate over sports stubs and new sigcov requirement of WP:SPORTCRIT – we have a bunch of verifiable information about this guy (and thousands of athletes like him) but they are not notable. What we should do with them instead is a huge can of worms. If you and Kusma believe articles like this should be deleted instead of redirected or navified, we're gonna need an RfC.
As for the categories, I agree that they are questionable way to present unsourced information. Those were added by @MrPersonHumanGuy after I navified the article [1]. Toadspike [Talk] 13:43, 22 April 2025 (UTC)[reply]
To avoid redirection in general? Yes, that's a something even I'm not masochistic enough to deal with (though I will take any opportunity to remind people that we have a fairly functionable search bar for mentions and draftspace/userspace to preserve the history of poorly-sourced but potentially notable articles). To avoid navigation? This produced, again, an unsourced perma stub about a living person. Without sources, we actually don't even know if this is the same person. Sure, the external sources listed in the AfD (that I'm not allowed to put in the stub, aren't present in either of the articles?) seem to confirm that, and his name is unique enough, but we already have enough of an issue with editors accidentally mixing up people just because they have the same name. GreenLipstickLesbian💌🦋 00:14, 23 April 2025 (UTC)[reply]
I agree with Chaotic Enby, would would add a second type of use: Where two or more notable concepts are covered in separate Wikipedia articles but common searched for together - see WP:XY and Wikidata's "Bonnie and Clyde problem". Thryduulf (talk) 11:46, 19 April 2025 (UTC)[reply]
Turtle Islands Heritage Protected Area looks like an example of this type of use in action. – MrPersonHumanGuy (talk) 13:51, 19 April 2025 (UTC)[reply]
Yes, that's a good example. Thryduulf (talk) 13:58, 19 April 2025 (UTC)[reply]
I like the idea, but we definitely need boundaries on what qualifies for a navpage. The current categories seem to be something along the lines of:
  1. Subjects which would be a {{R from subtopic}} as a redirect that have multiple potential targets (Nick Fuentes, Donald Trump, and Kanye West meeting)
  2. Subjects which would be a {{R to subtopic}} as a redirect that have multiple potential targets (Turtle Islands Heritage Protected Area)
  3. Subjects which are more akin to an index of possible articles with content relating to the subject (the old version of Ethiopia in World War II, the example in the original comment about Anti-Bangladesh disinformation in India)
  4. Subjects which are briefly mentioned on a couple pages with very little actual content (Armand Biniakounou, Amari McCoy, Glove and Boots)
It seems like there's more pushback to the fourth category than the first three. The third might be a bit too broad of a category that could be split up; I like the Ethiopia page as a navpage a lot more than the anti-Bangladesh disinformation page. The fourth category seems like a bad use of navpages, just because it leads readers to places that have little or no more information about the subject than the navpage itself. The first two seem to have the most potential. Skarmory (talk • contribs) 00:03, 22 April 2025 (UTC)[reply]
I generally agree with that classification, although I'm not sure "subtopic" is quite the right word for 2 and the line between 2 and 3 seems blurry, with the only difference I can immediately see being 2 has a title that is a proper noun which gives it a firm scope, while 3 has a descriptive title and thus a more fuzzy scope. Is that a useful distinction to make? I'm not sure.
One thought that has just occurred to me with 4 is that this would be used to create pages that are just a list of notable sports teams this player we don't have an article about played for (either because they aren't notable or because nobody has written one yet). I can see arguments both ways about whether such a page is encyclopaedic, but it isn't a navigation page in the same way that 1-3 are. So I think we should come up with a different name for that sort of page and discuss separately whether we want them or not. This does leave open how to determine an appropriate amount of content about a is enough to make it a navigation page, and my thinking is that we want a rule of thumb rather than a hard limit, perhaps "at least a few sentences, ideally a paragraph". Thryduulf (talk) 00:20, 22 April 2025 (UTC)[reply]
I would agree that a few sentences or a paragraph in two separate articles is probably a good bar for navpages, though they probably should also be different sentences and not the same text copied between articles (might be hard to police, but the reader gets no new information on the target by visiting both pages).
I think category 3 is the fuzziest one. I can see the argument for including category 2 in it, but my sense is that category 3 is already broader than I'd like, and I see a distinction there. I would say Ethiopia in World War II (as a redirect) would be more of a {{R from subtopic}}, not a redirect to a subtopic, so it'd be more likely to merge with category 1; the Anti-Bangladesh disinformation in India example is something I wanted to call a broad-concept page, but the definition didn't quite fit, and it's not really a clear subtopic or supertopic of anything (maybe {{R from related topic}} if used as a redirect to any of those?). Meanwhile, the Turtle Islands Heritage Protected Area is clearly a topic that contains both Turtle Islands National Park and Turtle Islands Wildlife Sanctuary; I'd call it a supertopic, but the redirect category is named R to subtopic, so that's what I went with.
I don't get the sense that consensus would like a separate type of page for category 4, though I personally could be swayed either way on it. I do agree that it shouldn't be what we're making navpages. Skarmory (talk • contribs) 08:45, 22 April 2025 (UTC)[reply]
I like this precision, but I worry this whole concept of nav pages is too complex for little benefit. We would have to teach a lot of folks these 4 rules (npps, autopatrollers, wiki project disambig, gnomes) and this has a cost. –Novem Linguae (talk) 00:37, 22 April 2025 (UTC)[reply]
Obviously I don't speak for those groups, but I'm in three of them and I think the idea is definitely worth considering even with the editor hours it'd take to teach editors. It's not that different from the idea of a disambiguation page or a set-index article, and it will be helpful to readers if done right. Skarmory (talk • contribs) 08:49, 22 April 2025 (UTC)[reply]
I don't see how this function could really be useful: it breaks our search function by directing readers to these short, useless articles. And I think they should be considered articles: Amari McCoy and Armand Biniakounou both list the name, vocation, and biographical details about a real person, but would otherwise be rejected as citation-free BLP stubs in AfC or NPP. I fully agree with GreenLipstickLesbian's comments above about the latter article. I worry that this opens the door for a million new context-free stubs for every name we list in the encyclopedia, breaking the hypertext-based structure of linking people's names when they become notable. Search would be totally broken if typing a given name like "John" into the search box returned a list of hundreds of non-notable people in the suggestions just because they'd been listed somewhere and thus got a navigation page. Dan Leonard (talk • contribs) 12:32, 22 April 2025 (UTC)[reply]
I agree that John would make a terrible navigation page, and lists of places a person is trivially mentioned is not a navigation page per my comments above. Please don't be tempted to throw the baby out with the bathwater. Thryduulf (talk) 12:44, 22 April 2025 (UTC)[reply]
My point wasn't about a page called John, it was the issue of the search box's automatic suggestion function. Currently, typing a partial name into the box helpfully prompts the reader with a list of all the notable people with similar names for whom we have actual articles. If we made navigation pages for hundreds of non-notable people like above, this search function would be cluttered with short navigation stubs instead of the notable people we have useful articles on. This proposal is intended to assist navigation, but I think it would do the exact opposite. Dan Leonard (talk • contribs) 13:04, 22 April 2025 (UTC)[reply]
See above where we are dealing with this exact issue (Skarmory's type 4). We intend navigation pages to be used for instances of notable topics that are covered in at least some depth on multiple other articles. Lists of mentions of non-notable people are something qualitatively different - there are arguments for and against having such pages (and you have articulated some of them) but they are not navigation pages and their existence or otherwise should not be relevant to whether pages of Skamoary's types 1-3 should exist. Thryduulf (talk) 13:16, 22 April 2025 (UTC)[reply]
Regardless, these pages exist already and have the {{navpage}} template, so it's worth discussing their place in this proposal and whether to explicitly forbid or allow them. Dan Leonard (talk • contribs) 13:22, 22 April 2025 (UTC)[reply]
My point isn't that they shouldn't be discussed, but that objections to one type should be used as a reason to reject the whole concept, especially when discussion about them being separate is already happening. Thryduulf (talk) 13:42, 22 April 2025 (UTC)[reply]
These are reasonable concerns; when I saw the "navify" option come up at AfD I thought it was already a settled template that was intended to apply to non-notable topics that are mentioned on more than one page and so can't be redirected. If the discussion is instead leaning toward these being restricted to the kinds of intersections of notable topics described by Skarmory, then we probably should make that clearer to AfD. I agree that these navpages showing up in prompts the same way real articles do is not ideal. JoelleJay (talk) 16:52, 22 April 2025 (UTC)[reply]

Next steps

[edit]

Looks like there's 7 pages in Category:Navigation pages. That's good that it's not growing. I think creation of these has mostly paused. I think the next step is for someone to create an RFC on whether navigation pages should be allowed to exist. I guess at WP:VPPR, or at Wikipedia talk:Navigation pages but with notification to many other pages. Does that sound reasonable? Depending on the outcome of that RFC, we can then decide on whether to start peppering navigation pages everywhere, or to turn these 7 existing ones into something else. Whoever creates the RFC should be someone who is pro-navigation page, and should do some work on Wikipedia:Navigation pages to make sure it accurately documents the navigation pages proposal, and that page can be where we have our description of exactly how navigation pages will work. –Novem Linguae (talk) 16:55, 22 April 2025 (UTC)[reply]

I don't think we're ready for an RFC yet as discussion is still ongoing about which of the four types of page outlined above should be considered navigation pages, and if it isn't all of them how to distinguish the type(s) we want from the type(s) we don't. Some discussion on formatting will likely be needed too. Going to an RfC prematurely will just result in confusion and !votes based on different things and different understandings. Thryduulf (talk) 17:44, 22 April 2025 (UTC)[reply]
Agreed. If we were to hold an RfC now, we should at least have separate discussions on each of the four types of navpages laid out by Skarmory, to be authorized or forbidden separately. Toadspike [Talk] 17:57, 22 April 2025 (UTC)[reply]
Also agreeing – I would be in support of types 1 to 3, but opposed to type 4, which I believe is also the case for a lot of navpage proponents.
There are also more technical issues we should consider before going for an all-or-nothing RfC. For instance, whether it would be technically possible to suppress or push down the appearance of navpages in search results (although having limited use cases like types 1 and 2 will likely make these much rarer than actual articles, and limit them to topics with actual content written about them somewhere). Chaotic Enby (talk · contribs) 18:22, 22 April 2025 (UTC)[reply]
Perhaps also a wording tweak to be more conservative. "There is currently no article" feels too encouraging, especially if the template might be used in the wrong locations (much as how Ethiopia in World War II is mischaracterized as an SIA). The closer these stay to disambiguation pages, which are firmly established, the clearer it will be that these are not articles. CMD (talk) 00:38, 23 April 2025 (UTC)[reply]

Metadata gadget as the default experience

[edit]

Is there technical feasibility for including any part of the Metadata gadget in the default experience, or must it remain a gadget?

There seems to be a perennial wish amongst FA/GA contributors to make quality a more visible part of articles, for a number of reasons. The current experience, a topicon, seems to be considered too little. Previous discussions:

I think a good way to resolve this would be to get the FA, FL, and GA experiences from the metadata gadget into the default browsing experience for all users. Having at least the text A featured article from Wikipedia, the free encyclopedia at the top of FAs would certainly make it more explicit to readers, and the wikilink (with a statistical redirect) to Wikipedia:Featured articles would serve the purpose of explaining what the FA process is (many oppose !votes in the above discussions hinged on reader confusion) as well as draw in interested editors (many others in the above discussions mentioned becoming interested in editing after learning about FA/GA).

This would surely be a very contentious RfC if proposed, but I'm not even sure if it's technically possible in MediaWiki, since it currently works via a fairly slow JavaScript gadget. Does anyone know if it would be possible to integrate this experience more deeeply? Dan Leonard (talk • contribs) 21:03, 20 March 2025 (UTC)[reply]

I would support this RfC. Cremastra talk 17:17, 28 March 2025 (UTC)[reply]
I wonder what the WP:PERFORMANCE implications of running that gadget millions of times would be.
Perhaps of more importance: Do we really want Another stub from Wikipedia, the free encyclopedia on about half of the articles?
Combining the two concerns, I suggest that if folks want to celebrate the FA/FL/GA status more, that should be done with ordinary templates that can be added to the individual articles. For example, expand Template:Featured article. WhatamIdoing (talk) 01:52, 30 March 2025 (UTC)[reply]
Perhaps of more importance I think we do. Given we already have stub icons, adding that text under the title is just further incentive for more people to contribute.
Besides, stubs don't make up so many of the most-viewed articles, based on this data I just pulled out of my hat. Cremastra talk 03:06, 30 March 2025 (UTC)[reply]
I don't think that's actually an "incentive" for more people to contribute. WhatamIdoing (talk) 22:55, 31 March 2025 (UTC)[reply]
What do you think is an incentive for contributors, then? Redlinks, annoyning orange banners, tags, and stub categories are all at least partially aimed at getting people to hit the "edit" button for the first time. Cremastra talk 23:06, 31 March 2025 (UTC)[reply]
I don't think those are incentives. Some of them are invitations, but that's different.
For some of us, the incentive is making the internet suck less. Our response to someone being wrong on the internet is to add information where it can be found. For some of us, the incentive is a COI, or something next door to it. I could imagine, for example, someone getting tired of explaining some basic point about their industry/personal interest, so they try to share that information here. For others, it's because our friends are here, and you want to support your community's goals and get social status. Those people sometimes engage in Wikipedia:Hat collecting, but they also slog through difficult situations. Still others' incentive is to stave off boredom or to feel productive.
An incentive is what you get out of it. You don't get anything out of a stub tag. WhatamIdoing (talk) 00:48, 1 April 2025 (UTC)[reply]
The incentive to see an article say "A-class", the incentive to see an article not say "stub". Aaron Liu (talk) 01:01, 1 April 2025 (UTC)[reply]
So the incentive is that you get to feel pride at causing the removal of a badge of shame (except that none of our maintenance tags are supposed to be treated like badges of shame). Sure, I suppose that would motivate some people. WhatamIdoing (talk) 01:12, 1 April 2025 (UTC)[reply]
It ain't much more a badge of shame than the maintenance tag. Aaron Liu (talk) 16:27, 1 April 2025 (UTC)[reply]
Maybe. But the rating would be on every article, without an individual editor thinking that would be helpful for that particular article. And we do see people adding certain maintenance tags because they want to "warn the reader" or because they didn't get their way in a dispute. WhatamIdoing (talk) 17:41, 1 April 2025 (UTC)[reply]
Second. Greater visibility of our better articles is a great thing, and this gadget does it well. Would support this. A star or plus sign means nothing by itself, but the difference between "an article" and "a featured/good article" at least tells the reader something meaningful. JackFromWisconsin (talk | contribs) 03:47, 21 April 2025 (UTC)[reply]
GA, A, and FA are probably roughly fine more accurate than not, however the rest of the ratings are likely of more variable accuracy. A side-effect of them being not that impactful is they often aren't updated. Anecdotally, not a small number of articles are classed as stubs simply because they haven't been updated since the articles were stubs. Displaying these ratings to the reader may give an air of officiality, giving the ratings a meaning we don't want to give them ourselves. CMD (talk) 01:23, 1 April 2025 (UTC)[reply]
I'd like to reiterate that this request is for technical feasibility of an experience similar to the metadata gadget using MediaWiki, not running the current JavaScript gadget. I'd also like to reiterate that it's specific to good and featured content only, as it derives from previous discussions. On the technical feasibility side, I think it'd require mw:Extension:CustomSubtitle embedded within {{Good article}} and {{Featured article}}, but it'd likely require security updates to restrict its use. Dan Leonard (talk • contribs) 15:40, 10 April 2025 (UTC)[reply]
You don't need a consensus discussion to investigate making a software thing without considering whether the community would want it. It's something developers are usually encouraged to just do; try MediaWiki channels if you need help since VPT deals little with non-enwiki-specific backend stuff. Aaron Liu (talk) 16:06, 10 April 2025 (UTC)[reply]
mw:Project:Support desk might be the right place to ask questions about whether that extension would require changes. WhatamIdoing (talk) 17:28, 10 April 2025 (UTC)[reply]
I'm not asking for development on anything, I’m asking if anyone knows whether it's possible at all. Dan Leonard (talk • contribs) 18:30, 10 April 2025 (UTC)[reply]
Anything is possible as long as you develop it. If you mean whether it's possible without changing the current backend (WMF) setup and do not want to involve the usual questions on "should we", that's usually a question for VPT. Using CustomSubtitle would modify the backend. A much more efficient way would probably be modifying mw:Extension:PageAssessments to add a parser function that returns the page class and then putting that parser function in MediaWiki:Tagline. Aaron Liu (talk) 21:28, 10 April 2025 (UTC)[reply]
Oh cool, thanks, that's exactly what I was looking for! I didn't realize there was a MediaWiki extension behind assessments, I thought it was just a relatively simple template design where the |class= parameter of {{WikiProject banner shell}} changes the talk box text and image. I'll read up on the PageAssessments extension and see what's possible there, and then if I can do it myself I'll re-propose a more complete idea here or at one of the other village pump sections. Dan Leonard (talk • contribs) 21:42, 10 April 2025 (UTC)[reply]
No problem! It was just a template, but later the PageAssessments tool was reason so that e.g. you can query assessments by API better and the template was adapted to support PageAssessments. Note that it does not have said parser functions needed yet and you'll have to code or get someone to code the parser functions. Aaron Liu (talk) 21:55, 10 April 2025 (UTC)[reply]
Looks like Module:Page assessment has already been implemented to do just this. Given that modifying the sitewide tagline would run this function a lot, would a parser function built directly into the MediaWiki extension be more efficient, or is this Lua module essentially the same thing? It doesn't look like it's using the API, and is just parsing the wikitext, but I'm not well versed in Lua to be certain. Dan Leonard (talk • contribs) 22:23, 10 April 2025 (UTC)[reply]
Evad37 wrote the module, but has been off wiki for about two months. You should ask technical questions like this at Wikipedia:Village pump (technical). WhatamIdoing (talk) 03:12, 11 April 2025 (UTC)[reply]
As it's trivial retrieval of information, making it a parser function would almost always be better. And getting the wikitext of the associated talk page is effectively querying the API, except it's querying all the wikitext instead of just the pre-stored page assessment class. Aaron Liu (talk) 13:27, 11 April 2025 (UTC)[reply]

Overturning NCCAPS

[edit]

There's a discussion at WT:NCCAPS about the capitalization threshold (the current status quo is to only capitalize a title if it's always [sic] capitalized in sources), but it's gotten kind of personal in the last few comments, so rehashing it here for wider community input. Some editors have supported my proposal, others have opposed, overall something that needs to be discussed further. My original comment is as follows:

TL;DR: The threshold for capitalization or lack thereof should be the same as the threshold for a common name.

WP:AT says: Generally, article titles are based on what the subject is called in reliable sources. There is less than zero reason why the one exception to that should be the most trivial of matters: capitalization. The standard for American Revolution vs. American revolution should be the same as that of, say, Dog vs. Canis lupus familiaris. In the latter case, the majority of sources use Dog, thus that is the common name. In the former case, the majority of sources use American Revolution, thus that is the common name. There is nothing that makes capitalization somehow magically different from every other titling scenario.

If the title of an article in sources is 75% uppercase and 25% lowercase, then NCCAPS recommends we lowercase it. That's just plain wrong. If article titles on based on what the subject is called in reliable sources, then why should we contradict that rule for a small subclass of naming disputes? Going by sources and uppercasing the title violates no core content policies and reinforces the in-a-nutshell core of the titling policy. It's nonsense that we should ignore policy and a supermajority of sources to uphold this dubious guideline.

Thus we should follow the sources, as we always have. The threshold for capitalization should not be 100%, nor 95%, nor 90%. It should be 50.1% (with a ±5 to account for the extreme influence Wikipedia has on sources' titling).

So, what do we want to do? Do we want to follow sources and the core policy on article titles, or do we want to straight-up ignore sources, following an anachronistic guideline and some editors' minority grammatical opinions? Do we want to begin a never-ending shitstorm of "style warfare" over whether 50.1% has been reached, and depart from established grammatical norms, or keep in place a guideline that has been stable for twenty years? (Clearly each side has a different opinion...) 🐔 Chicdat  Bawk to me! 11:35, 31 March 2025 (UTC)[reply]

I see absolutely no justification for capitalisation to differ from other aspects of naming. It's not surprising that the discussion at the MoS has resulted in ad hominems, any discussion proposing anything other than reducing the number of capital letters in article titles almost invariably does. Thryduulf (talk) 12:18, 31 March 2025 (UTC)[reply]
I see no reason to change from the current guideline. Capitalization is a stylistic question. Unless it pretty much is capitalized in all sources, everywhere, all the time, then we are free to choose not to do so. Just as we are free to make other stylistic choices. --User:Khajidha (talk) (contributions) 15:03, 31 March 2025 (UTC)[reply]
I think the underlying logic here—as Khajidha says, that we don't 'follow the sources' when it comes to questions of pure style—is sound and necessary to ensure some level of consistency between articles based on different bodies of sources. Disputes tend to arise when applying this logic to capitalisation because the style we have chosen is quite extreme (i.e. we use as few capital letters as possible without coming off as an art project) and therefore more likely to clash with sources and editors' experiences elsewhere. They are exacerbated by a small group of editors who zealously and tactlessly apply this style across articles, with no regard for the preferences of those that wrote them. I'm unsure that tweaking the rule will solve either issue. – Joe (talk) 15:27, 31 March 2025 (UTC)[reply]
"with no regard for the preferences of those that wrote them" I'm not seeing how this is a problem. You aren't writing for you and your preferences. You are writing for Wikipedia and our style. --User:Khajidha (talk) (contributions) 17:23, 31 March 2025 (UTC)[reply]
The proposal is to change our style… so simply pointing to the current style guidance and saying “you are writing for our style” isn’t really an argument. Please explain why you think the current guidance is better than the proposal. Blueboar (talk) 21:02, 31 March 2025 (UTC)[reply]
Because it looks better and is easier to read with less capitalization. But, as I'm not the one arguing for change, I'm not the one who needs to explain. --User:Khajidha (talk) (contributions) 21:14, 31 March 2025 (UTC)[reply]
So, your reasons are 1) "your personal preference" and 2) "an uncited and possibly wrong factual claim"?
I've seen sources claiming that all lowercase is easier to read than all uppercase (once you know how to read. Brand-new readers often struggle to differentiate lowercase letters like d and b, so all-caps text sometimes works better for them). I don't remember seeing any research saying that "war and peace" is easier to read that "War and Peace".
About as I'm not the one arguing for change, I'm not the one who needs to explain: I guess I hope that editors who join a discussion are trying to find the Wikipedia:Consensus. That only works if everyone is willing to explain their views. Wikipedia:BOLD, revert, discuss cycle, in particular, is entirely dependent upon the reverter/objector being willing to explain why they object to a change. A stonewalling attitude like "You made the change, so I'm not the one who needs to explain my views" will cause BRD – and most other serious discussions – to fail. Please don't do that. WhatamIdoing (talk) 05:12, 1 April 2025 (UTC)[reply]
The problem is that having people who still want to write articles is several gazillion times more important to Wikipedia's future than consistent capitalization of titles. – Joe (talk) 21:51, 31 March 2025 (UTC)[reply]
I have come to believe that enforcing a house style is overall a net negative for Wikipedia. (Personally, I contribute very little to the German Wikipedia although German is my first language, mostly because I disagree with their style choices, which are often different from the near unanimous view of the sources). —Kusma (talk) 08:36, 19 April 2025 (UTC)[reply]
  • I find it interesting that basically everyone in that discussion agrees that "always capitalized in reliable sources" shouldn't be taken literally, but those opposed are saying we can't change it because some parade of horribles will follow. ~~ Jessintime (talk) 19:25, 31 March 2025 (UTC)[reply]
    Perhaps “overwhelmingly capitalized in sources” is closer to how we really operate? Blueboar (talk) 21:08, 31 March 2025 (UTC)[reply]
    It depends on the discussion whether it's "overwhelmingly", "almost always" or "literally always". Often it's "Overwhelmingly (or almost always) capitalised in sources that I can't dismiss as not-independent, unreliable, "specialist", "low quality", or for some other reason". I think it would be much closer to our ethos and a more professional approach to capitalisation if the standard was something like "predominantly capitalised" with usage by subject matter experts weighted a bit higher than usage by others and we treated the context-free evidence from sources like ngrams as a single, relatively low-importance data point. Thryduulf (talk) 21:26, 31 March 2025 (UTC)[reply]
    That "sources I can't dismiss as..." bit sounds like what I've seen in many areas. WhatamIdoing (talk) 05:14, 1 April 2025 (UTC)[reply]
@Chicdat: I wish I had time to write and refine something concise and thoughtful here, because there is considerable history and a lot of nuance. But just to offer a few stray thoughts
In the end content is what's important, style is just the dressing. As a reader, I like to have articles that look nice and are consistently formatted, but what I really want are articles that are well-written and informative.
Maybe the specifics of the guideline shouldn't matter match. Guidelines are supposed to be just that occasional exceptions may apply in principle a solid local consensus should be sufficient to override, though in practice it's complicated.
WP:STYLEVAR works just fine and helps to reduce acrimony, but its not always practicable. Could it work in the area of capitalization? Well in at least one area it already does. Would it work more widely? Difficult to say, not a lot of hard evidence either way.
No matter where you draw the lines there will always be edge cases, one choice or another will not eliminate good-faith disputes among contributors.
NYB once wrote of the potential for a demoralizing effect, I'm confident it exists, but judging its effects is harder. Some might remember the editors lost from WP Birds as a result of a capitalization controversy, but there were other factors at play there as well.
From the beginning the MoS has been one of those perennial dispute/disruption areas, its not everyone's cup of tea, and I certainly would not fault anyone for avoiding it. At the same time if you want to help build consensus you have to be involved. A common complaint is that MoS related discussions are not representative of the community as a whole because only the people who have the MoS as their focus show up in number since they are more likely to monitor Wikipedia talk:Manual of Style#Style discussions elsewhere. Maybe so, but there's nothing that prevents people who are mostly content editors from also monitoring the section and offering their assessments.
Maybe what is really needed is a broader cross section of the community offering input, and regardless of ultimate outcome, that's really desirable for all discussions. You can help. Sure you'll get unpleasant responses, don't let them get under your skin, be assertive not aggressive, stand your ground but be willing to hear others out as well. And know when to disengage. DGG once suggested the principle of limiting your comments in discussions that were primarily contentious rather than collaborative, let everyone have their say and see what shakes out.
Sorry for the length and disorganization, given time constraints I probably shouldn't be editing at all at present, but hopefully you found some of that useful. 184.152.65.118 (talk) 17:04, 6 April 2025 (UTC)[reply]
I agree with Blueboar's comment that what we actually do in RMs is not a literal application of the word "always". I've participated in...a few RMs and I've never understood the "always" in that sentence to mean "in every single source in existence", instead reading it as "grammatically should always be capitalized". In that regard, I support changing the wording of NCCAPS. But Wikipedia prefers to minimize capitalization, so the threshold cannot be 50%+1 of sources, it has to be a large majority. Not sure how best to express this in guideline-speak. Toadspike [Talk] 21:58, 11 April 2025 (UTC)[reply]
  • MOS:CAPS says Wikipedia relies on sources to determine what is conventionally capitalized; only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalized in Wikipedia., I don't see why this shouldn't apply to article titles as well. Kowal2701 (talk) 21:20, 18 April 2025 (UTC)[reply]
  • 100%, nor 95%, nor 90%. It should be 50.1% is frankly absurd for a discussion of pure style. Unlike the name of a subject, for which experts in a field generally converge on a consistent name, capitalization is done stylistically by the editors of the newspaper or journal we use as a source. How could we possibly get a comprehensive survey of sources to enforce a 50% cutoff? For American Civil War, there are likely more journal articles than books mentioning the phrase, and more newspaper articles still. All use varying house styles, and the capitalization comes not from the historian but from the editor. Would we also include historic publications too? Surely it had been discussed in textbooks and the news as far back as the 19th century so those would need inclusion in our survey. This would be far too burdensome to enforce and the discussion would surely be biased toward the easily-accessible online news articles in AP style over print books in Chicago style. Always is fine for this. There's always one or two style guides someone can point to, but it avoids endless debate and the idea of somehow pretending there can be an unbiased and empirical sampling of every mention of the phrase. We have a house style we should enforce because it's consistent for readers and prevents debates and RMs. Dan Leonard (talk • contribs) 15:20, 22 April 2025 (UTC)[reply]

Ignore edits to ones own user area in right counts

[edit]

For additional right given automatically based on number of edits, edits to ones own area of user and user talk space should not be counted. So User:ZcrashZ, if they had 11 edits, one to User:ZcrashZ, one to User talk:ZcrashZ and one to User:ZcrashZ/page1 and eight to other places, the user would count as having made 8 edits and would be unable to move a page because WP:AUTOCONFIRM would not apply. I see editing of their own area a lot on creating accounts for Vandalism.Naraht (talk) 01:23, 5 April 2025 (UTC)[reply]

How often does this happen?
This link will give you a list of every page moved by any account with (if memory serves) 10–500 edits during the last 24 hours. Looking at it, there's been about 125 entries in the move log, but if there's a talk page, then a single "move" action will be logged twice, so there are probably about 50 names to review. I looked at about 10; I found only one that might have been tripped up by such a rule.
The point behind autoconfirm is that obvious vandals are obvious before they make 10 edits. If they're not obvious vandals, then why shouldn't they be able to draft an article in their userspace and move it to the mainspace when they're ready for it to face Wikipedia:New pages patrol? WhatamIdoing (talk) 03:00, 5 April 2025 (UTC)[reply]
Is there any user right besides autoconfirmed that is triggered by edit count? Cambalachero (talk) 03:21, 5 April 2025 (UTC)[reply]
WP:XCON which requires 500, though as with AC it also has a time component, 30 days instead of 4. And yes it is also routinely gamed. 184.152.65.118 (talk) 03:26, 5 April 2025 (UTC)[reply]
WP:XCON (but AIUI not WP:AUTOCONFIRM for technical reasons) can be revoked if a user is judged to be gaming the permissions system. Requiring that edits counting towards AC/EC not be in userspace will probably have limited effect on people actively gaming permissions – they can simply shift their permission-gaming to a different namespace. Especially in the case of autoconfirm, which only requires 10 edits. Caeciliusinhorto-public (talk) 15:53, 7 April 2025 (UTC)[reply]
I think there are some tools that require certain edit counts, though the two I can remember at the moment, being access to the wikipedia library and autowikibrowser, have similar edit requirements to extended confirmed. I believe there's a tool that requires 1k edits but I cannot for the life of me remember what it is, so along with the others I listed I doubt anyone is edit farming for those specific tools. ¿VØ!D? ☄ 21:11, 14 April 2025 (UTC)[reply]
Currently, it seems that there is no documentation if one can restrict edit count by namespace. mw:Manual:$wgAutopromote. If the suggestion is passed in a RfC, technical assessment and work will likely be in order before such conditions by namespace can be used. – robertsky (talk) 09:51, 13 April 2025 (UTC)[reply]
Likely it would require a database change to store the edit count by namespace. Anomie⚔ 12:40, 13 April 2025 (UTC)[reply]
Some editors do start drafting articles in userspace before moving them to mainspace, I'm thinking these contributions should still be counted if that proposal comes to pass. Chaotic Enby (talk · contribs) 12:26, 13 April 2025 (UTC)[reply]
Chaotic Enby, are you saying these edits should count even before the draft has been published (So someone may have 450 mainspace edits and 100 edits to an as-yet-unpublished draft, and they should receive EC rights)? Because if they only count after publication, I think counting edits made to mainspace would include edits made to former drafts that have since been moved to mainspace. ꧁Zanahary꧂ 21:38, 15 April 2025 (UTC)[reply]
I was thinking they would only count after being moved to mainspace, if that's already how they are counted then it's great! Chaotic Enby (talk · contribs) 09:42, 16 April 2025 (UTC)[reply]

Unblock request wizard

[edit]

 Courtesy link: User talk:Joe Roe § An idea
See the aforementioned discussion for some context, but basically I think it'd be good to have a wizard (like Wikipedia:Edit request wizard) for unblock requests. Feedback regarding the idea is very much welcome. Clovermoss🍀 (talk) 21:54, 11 April 2025 (UTC)[reply]

Anecdotally, the proportion of malformed unblock requests that make valid cases for being unblocked is low but not zero, so I’m open to a suggestion like this. I’m wondering if we could also include some invisible AI spoilers in the Wizard prompts to catch people who try to game the system (e.g. "include the phrase 'sequitur absurdum' in your response", "include an explanation of Wikipedia's General Mobility Guideline"). signed, Rosguill talk 15:39, 12 April 2025 (UTC)[reply]
I don't think we should aim to trick people (it'll probably just end with people addressing unblock requests being confused as well), but a prompt asking someone whether they attempted to write their unblock request with AI with a "yes" or "no" selection might be enough to prevent most instances of it (especially if it includes a statement about it being discouraged and requesting someone to rewrite it in their own words to show that they understand what they're saying). Kind of like the commons upload form that asks if you're uploading a file to promote something and just doesn't let you continue if you click "yes". Alternatively the request could just have an extra "this editor says they used AI while writing this unblock request" added somewhere. Clovermoss🍀 (talk) 16:51, 12 April 2025 (UTC)[reply]
1. Rosguill's text would be invisible and only shown when copied/selected and dragged and dropped. (I think there is an HTML attribute that would make something not picked up by screenreaders either.)
2. We're fighting AI-generated unblock responses, not bots. The usual scenario would be someone asking the AI for an unblock request and then pasting that into the box manually. Aaron Liu (talk) 17:38, 12 April 2025 (UTC)[reply]
FWIW I don't consider my spoiler suggestion to be absolutely necessary for my supporting the general proposal, but yes, what I had in mind is to render the text in such a way that it will only show up in any capacity for people who try to copy-paste the prompt into another service, which is becoming a standard practice for essay questions in school settings to catch rampant AI use. signed, Rosguill talk 17:49, 12 April 2025 (UTC)[reply]
I like this idea. voorts (talk/contributions) 18:47, 12 April 2025 (UTC)[reply]
That might scare people who composed their unblock requests in a Word document, though. I've gotten fairly good at gauging whether something was AI-generated, I assume admins who patrol RfU are the same. JayCubby 15:58, 14 April 2025 (UTC)[reply]
Definitely opposed to this, as it'll only lead to some humans inevitably getting accused of using AI. ꧁Zanahary꧂ 04:45, 14 April 2025 (UTC)[reply]
If it's invisible text, how? voorts (talk/contributions) 12:27, 14 April 2025 (UTC)[reply]
If “invisible” means it’s just the same color as the background, people are going to see it (by highlighting, with alternative browsers, etc) ꧁Zanahary꧂ 14:54, 14 April 2025 (UTC)[reply]
Make it super small text size with same color as background and add a style/attribute that'd prevent screenreaders from reading it. Plus it'd be a very unreasonable request to most humans. Aaron Liu (talk) 16:13, 14 April 2025 (UTC)[reply]
It’s just silly. We do not know that this would trick AI, I’m not convinced that undetected AI use is a problem (it’s pretty easy to clock), and there is reason to believe it will catch innocent people. ꧁Zanahary꧂ 16:43, 14 April 2025 (UTC)[reply]
I’m not aware of any style or attribute that hides text from screen readers. As far as I know, it’s impossible on purpose. 3df (talk) 05:59, 24 April 2025 (UTC)[reply]
A blind user with a screen reader wouldn’t know that the text is not visible. An image with an imperceptibly faint message and a blank alt text could work, but not every bot is likely to fall for it, if they even process it. 3df (talk) 05:55, 24 April 2025 (UTC)[reply]
I would also agree with an unblock request wizard, although I might be less focused on the technical side. From having guided users in quite a few unblock requests, the main issues I've seen (although I concede there might be a selection bias) are in understanding what is required of an unblock request. A good wizard would summarize WP:GAB in simple terms to help blocked users navigate this – as writing a good unblock request is certainly less obvious than it seems for people unfamiliar with Wikipedia.
One idea that could be explored would be to structure the unblock request, not as a free-form text, but as a series of questions, such as What do you understand to be the reason for your block? and Can you provide examples of constructive edits you would like to make? Of course, these questions can be adapted based on the specifics of the block (a user caught in an IP rangeblock wouldn't see the same questions as a username-hardblock, for example), but this could make for a good starting point that would be less confusing than the current free-form unblock requests. Chaotic Enby (talk · contribs) 18:08, 12 April 2025 (UTC)[reply]
I like that idea. My concern is that the specific reason for the block may not always be clear from the block template used, and the block log entry may be free text that, while important for identifying the reason for the block, is not easy to parse by a wizard.
Example: "disruptive editing" could be anything from extremely poor English to consistently violating the Manual of Style to deadnaming people to ... you name it. — rsjaffe 🗣️ 20:04, 12 April 2025 (UTC)[reply]
Good point. What I had in mind was something like this part of the AfC wizard, where the user can click to select their situation, rather than it being automatically guessed from the block template (which would be prone to frequent errors). Chaotic Enby (talk · contribs) 21:03, 12 April 2025 (UTC)[reply]
Could be a hybrid work flow. For certain block templates, e.g., {{uw-copyrightblock}} or {{uw-soablock}}, there could be a set of standard questions, for others, e.g., {{uw-block}} there could be a "choose your situation" flow. — rsjaffe 🗣️ 21:14, 12 April 2025 (UTC)[reply]
That could be great! Chaotic Enby (talk · contribs) 22:54, 12 April 2025 (UTC)[reply]
I'm having some difficulty imagining a positive reaction by an aggrieved editor facing a menu of options, but I think a more concrete proposal might help. Perhaps those interested in a multiple workflow concept could mock something up? isaacl (talk) 21:29, 12 April 2025 (UTC)[reply]
Going to do it! Ideally, it shouldn't be something that would comfort them in their grievances or make them feel lost in bureaucracy, but more something like "we hear you, these blocks happen, for each of these situations you might be in, there is a way to get out of it". Chaotic Enby (talk · contribs) 22:56, 12 April 2025 (UTC)[reply]
I do think that some editors don't realize they even can get unblocked at all. Or that it isn't even nessecarily their fault if they're an IP editor... some situations where innocent bystanders were affected by a rangeblock and frustrated come to mind. Clovermoss🍀 (talk) 00:51, 13 April 2025 (UTC)[reply]
I think it's easier than asking someone to copy a template and then edit wikitext. voorts (talk/contributions) 01:54, 13 April 2025 (UTC)[reply]
My comments weren't about the general idea of a guided workflow, but a branching workflow based on the answers to initial questions. It brings to mind the question mazes offered by support lines. Although I think a more general workflow might be better, I'm interested in seeing mockups of a branching workflow. isaacl (talk) 16:43, 13 April 2025 (UTC)[reply]
I like the general idea, but anything with prompts, etc needs to take into account there are at its most basic three categories of reasons to request an unblock: (1) the block was wrong and shouldn't have been placed (e.g. "I didn't edit disruptively"); (2) the block is not needed now (e.g. "I understand not to do that again"); and (3) the block doesn't make sense.
Sometimes they can be combined or overlap, but for type 2 appeals it is generally irrelevant whether the block was correct or not at the time. Type 3 often shouldn't be unblock requests but often it's the only way people see to get help so anything we do should accommodate that. Perhaps a first question should be something like "why are you appealing the block?" with options "I understand the reason given but think it was wrong", "I understand why I was blocked but think it is no longer necessary" and "I don't understand why I was blocked."
I'm neutral on an AI-detection, as long as it is made explicit in instructions for those reviewing the blocks that a request using AI is not a reason in and of itself to decline (using AI is discouraged, not forbidden, and someone may say yes even if they've only used it to check their spelling and grammar). Thryduulf (talk) 08:03, 13 April 2025 (UTC)[reply]
Currently working on User:Chaotic Enby/Unblock wizard! Chaotic Enby (talk · contribs) 15:05, 14 April 2025 (UTC)[reply]
Regarding the sub menu for "I am not responsible for the block": my preference is not to provide a set of pre-canned responses like "Someone else I know has been using my account" and "I believe that my account has been compromised". I think we should avoid leading the editor towards what they may feel are plausible explanations, without any specific evidence. isaacl (talk) 16:56, 14 April 2025 (UTC)[reply]
True, that makes sense, even though I tried to provide an outlet with the "I don't understand" before. Although I'm planning a full rework of this on the advice of @Asilvering, as whether the user believes they have been blocked incorrectly might not be the most important first question to ask. Chaotic Enby (talk · contribs) 18:09, 14 April 2025 (UTC)[reply]
I agree with isaacl that the "I don't understand" outlet is just not good enough.
What did asilvering suggest as a more important thing? Aaron Liu (talk) 19:53, 14 April 2025 (UTC)[reply]
Basically, sorting appellants into boxes that are actually useful for giving them tips, rather than asking them to tell us what their rationale for appeal is. We're not actually all that interested, functionally, in whether an appellant thinks the block was wrong or not (lots of people say they are when they were obviously good blocks), so there's no reason to introduce that kind of confusion. There are, however, some extremely common block reasons that even a deeply confused CIR case can probably sort themselves into. eg, "I was blocked for promotional editing". "I was blocked as a sockpuppet". etc. -- asilvering (talk) 20:17, 14 April 2025 (UTC)[reply]
That makes a lot of sense! Aaron Liu (talk) 20:43, 14 April 2025 (UTC)[reply]
I think it would be better for the blocking admin to do the sorting with the aim of providing relevant guidance. Maybe it's better to have a block message wizard. isaacl (talk) 21:54, 14 April 2025 (UTC)[reply]
What is relevant guidance depends in part on when and why someone is appealing, which is unknowable to the blocking admin. Thryduulf (talk) 23:22, 14 April 2025 (UTC)[reply]
Twinkle has blocking built in. voorts (talk/contributions) 23:19, 14 April 2025 (UTC)[reply]
Does it customize the block message with guidance to appropriate policies based on input from the admin? isaacl (talk) 01:25, 15 April 2025 (UTC)[reply]
See File:MediaWiki 2025-04-15 02-32-10.png and File:MediaWiki 2025-04-15 02-32-55.png. voorts (talk/contributions) 02:36, 15 April 2025 (UTC)[reply]
There are different ways to implement my suggestion. For example, the standard template (whether added by Twinkle, another tool, or manually) could be enhanced to accept a list of preset reasons for blocking, which the template could turn into a list of appropriate policies. Twinkle can feed the preset reason selected by the admin to the template to generate the list. isaacl (talk) 02:54, 15 April 2025 (UTC)[reply]
You can already select various different block templates (see CAT:UBT) through Twinkle that link to appropriate PAGs or use a generic block template to list reasons for a block / link to relevant PAGs. voorts (talk/contributions) 03:03, 15 April 2025 (UTC)[reply]
Perhaps whatever tips that would be provided by an unblock wizard could instead be added to the block templates? I appreciate that there's a tradeoff between crafting a message that's too long to hold the editor's attention, though. I just think that communicating this info earlier is better. isaacl (talk) 03:26, 15 April 2025 (UTC)[reply]
There is never going to be consensus to rework every single block template and extensively modify Twinkle. voorts (talk/contributions) 12:07, 15 April 2025 (UTC)[reply]
Regarding what is unknowable to the blocking admin: I was responding to Asilvering's comments on sorting blocked editors into categories for which appropriate tips can be given. I agree there can be benefits in providing a guided workflow for blocked editors (and am interested in seeing what gets mocked up). I just think that it will improve efficiency overall to start providing targeted guidance as soon as possible, and providing some kind of automated assistance would make it easier for admins to do this by default. isaacl (talk) 01:25, 15 April 2025 (UTC)[reply]
I think it's a good idea. ꧁Zanahary꧂ 04:46, 14 April 2025 (UTC)[reply]
  • I do think many people get tripped up on the wikicode(and when they click "reply" to make their request it adds to formatting issues) so I'd be interested in what people can come up with. I do agree with Issacl above regarding pre-canned responses. 331dot (talk) 20:31, 14 April 2025 (UTC)[reply]
    I think we could point people to the relevant policy pages, then give them a form to fill out, sort of like the draft/refund/etc wizards. Don't give them a prefilled form, instead an explanation (maybe even a simplified version) of the policies from which they are expected to explain their rationale. JayCubby 20:36, 14 April 2025 (UTC)[reply]
    Perhaps a block message wizard for the admin would be more helpful: they can specify the relevant areas in which the editor must be better versed, and the wizard can generate a block message that incorporates a list of relevant policies for the editor to review. isaacl (talk) 21:50, 14 April 2025 (UTC)[reply]

A prototype is ready!

[edit]

Over the last few days, I have worked on User:Chaotic Enby/Unblock wizard, now a fully functional unblock wizard prototype!

Currently, you need to add User:Chaotic Enby/Unblock wizard.js to your common.js for the subpages to load correctly. If there is a consensus to make it official, it could be moved to MediaWiki namespace and called through mw:Snippets/Load JS and CSS by URL, like other wizards currently do.

Please give me your feedback on it! Chaotic Enby (talk · contribs) 16:29, 22 April 2025 (UTC)[reply]

Prose comments: On the first page, remove the comma before "and" and remove the words "only" and "key". I suggest rewording the last sentence to "For an idea of what to expect, you can optionally read our guide to appealing blocks." Not sure if the word "optionally" is strictly needed, but I get the idea behind it. Toadspike [Talk] 18:15, 22 April 2025 (UTC)[reply]
Done! I left "Optionally", mostly because I don't want to drown the people using the wizard with more pages to read, especially since some points of GAB are redundant with the wizard's questions. Chaotic Enby (talk · contribs) 18:18, 22 April 2025 (UTC)[reply]
Sockpuppetry page: "While not binding," is extremely confusing. Is it trying to say that not everyone gets the offer? If so, I would remove it, since "often" later in the sentence means the same thing. "good will" --> "goodwill". I think the standard offer should be explained, especially if it is listed as a question later on.
The whole sentence "While some blocks for sockpuppetry..." seems unnecessary. Blocked users shouldn't be worrying about who can lift their blocks. At most this should be a short sentence like "Some blocks for sockpuppetry cannot be lifted by regular admins." or "Some unblock requests require CheckUser review." I would prefer removing it outright, though.
I think "Which accounts have you used besides this one, if any?" should be strengthened to "Please list all accounts you have used besides this one." This isn't some fun optional question you can answer partially – it should be clear that any omission will likely end in a declined unblock request. Toadspike [Talk] 18:25, 22 April 2025 (UTC)[reply]
For the first one, I just wanted to avoid the "I went through the standard offer, so I'm entitled to an unblock!!!" which I've actually seen from some users, but you're right that it is a bit redundant. Also implementing the other changes, thanks a lot for the detailed feedback! Chaotic Enby (talk · contribs) 18:45, 22 April 2025 (UTC)[reply]
Promo page: Remove commas before "or" and "and", remove "in these cases", remove "just" (it is not easy to tell your boss "it can't be done"). I would change the "and" before "show that you are not..." to "to": "to show that you are not..."
"why your edits were or were not promotional?" is a bit confusing. I would just say "why your edits were promotional" – if they disagree, they are sure to tell us. I'm open to other ideas too.
The third question is very terse and a little vague ("that topic"). Suggest: "If you are unblocked, will you edit any other subjects?" (closed) or "If you are unblocked, what topic areas will you edit in?" (open)
The username question isn't explained at all – perhaps say "If you were blocked for having a promotional username" instead of "if required", with a link to a relevant policy page.
I tested this and was surprised to find that the questions aren't required. I would make at least the first and second questions required or at least check that the form isn't empty before allowing it to be submitted. Toadspike [Talk] 18:37, 22 April 2025 (UTC)[reply]
I've made the changes, with the exception of changing "and" to "to": usually, admins will want editors blocked for promotional editing to show that they're not only here to edit about their company, which involves more than just disclosing their COI. I'm going to add a check for the forms, that's definitely an oversight on my side. Chaotic Enby (talk · contribs) 18:50, 22 April 2025 (UTC)[reply]
It seems the autoblock request has nowiki tags around it that prevent transclusion. I'm also pretty sure it should be subst'd, not transcluded. [2]. Is it correct that there is no field in the unblock wizard for a reason? It looks like that is a valid template param. Toadspike [Talk] 18:41, 22 April 2025 (UTC)[reply]
Oh, my bad. I forgot to remove the nowiki tags after I tested it on testwiki.wiki. The message at Wikipedia:Autoblock does tell users to transclude (not subst) the template, apparently with no message although that was also confusing to me. Thanks again! Chaotic Enby (talk · contribs) 18:54, 22 April 2025 (UTC)[reply]
IP block: The second sentence feels like it could be more concise, but it also is missing an explanation of our open proxy rules. I think it needs words to the effect of "VPNs are not okay, unless you really really need one". I would also prioritize the term "VPN" over "open proxy", since that is less confusing to most people. It might be worth linking to a page that lists other VPN-like services/device settings that often cause issues, if we have one. Toadspike [Talk] 18:48, 22 April 2025 (UTC)[reply]
Tiny nitpick on the IP block form: Since there are no user input fields, why do I get a "your changes may not be saved" pop-up when I try to leave the page?
Something else form: remove comma before "and". Not sure if "(if applicable)" is needed, but again I understand the intent and won't argue against it. Toadspike [Talk] 18:52, 22 April 2025 (UTC)[reply]
Oh, the "your changes may not be saved" is another thing I forgot to tweak the code for, since it reuses the same code for all pages. I'll fix this and make the other changes you listed after eating! Chaotic Enby (talk · contribs) 18:55, 22 April 2025 (UTC)[reply]
First, thanks for getting the ball rolling! Now, some some technical concerns (yes, I realized this is only a prototype):
  • There will need to be a fallback when the user has JavaScript disabled, is using an outdated browser, or the script fails to load. Right now I see something about "the button below" when there's no button. Assume helpful users will deep-link into the wizard from time to time.
  • The from will need a copyright notice, and a "you are logged out" warning if the user is logged out.
  • There will need to be to a meaningful error message for every possible problem that can occur when saving the edit: e.g. network error, session failure, blocked from own talk page, globally blocked, talk page protected, warned or disallowed by edit filter, disallowed by spam blacklist, edit conflict, captcha failure, and probably a dozen other reasons I haven't thought of yet. For example, I just tried from behind a globally blocked IP and I got a big pink box full of unparsed wikitext with no "click here to appeal a global block" button. One way to avoid most of these problems might be to submit the request through the web interface instead of the API.
I realize other scripts may play fast and loose here, but (except for the copyright and logged out messages) the worst that can happen is someone decides they don't like the script and uninstalls it. Here, they're stuck, and can't even ask for help on WP:VPT. Suffusion of Yellow (talk) 19:26, 22 April 2025 (UTC)[reply]
Thanks a lot! Yes, those points are the reason why I really wanted feedback – lots of stuff I didn't really think of spontaneously, but that will very much have to be considered before deploying it. I'll try to work on this!
For the case of JavaScript not being installed/not working, I'm thinking we could show a message informing the user that the wizard is not functional, and link them to WP:GAB and/or a preloaded unblock request template on their user talk page?
A bit curious about the copyright notice, what do you mean by that?
Regarding logged-out users, I agree that a message informing the user would be helpful, although I'm also thinking of adding options for IPs (depending on whether they have a regular block, rangeblock, hardblock, proxy block, etc.) Chaotic Enby (talk · contribs) 19:39, 22 April 2025 (UTC)[reply]
Mediawiki:wikimedia-copyrightwarning should appear next to every form where someone can make a copyright-eligible edit. And the "Submit" button, now that I think about it, should probably say "Publish" so they know the whole word can see their appeal. We don't want someone putting personal info in there thinking it's a private form. Suffusion of Yellow (talk) 19:48, 22 April 2025 (UTC)[reply]
Thanks, didn't realize that! Chaotic Enby (talk · contribs) 19:52, 22 April 2025 (UTC)[reply]

Antivirus

[edit]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
It looks like the OP has earned a CU block. WhatamIdoing (talk) 18:21, 16 April 2025 (UTC)[reply]

We could create a bot that removes links to computer viruses, only from the wikimedia foundation. (red annales) (talk) 19:38, 13 April 2025 (UTC)[reply]

A way to try this out would be to make your bot make a report. It could publish a report of Page, link (don't make it clickable), and perhaps the name of the threat on the link. — xaosflux Talk 19:42, 13 April 2025 (UTC)[reply]
Simple just use virustotals api although we would need to pay or ask for the enterprise version but i believe virustotal is an Wikipedia in terms of verification and community I don’t think the foundation wouldn’t mind much. Edit: we could take this further and do phishing detection and ip logger detection. Even in commons we could use this just to run files and pdfs through •Cyberwolf•. talk? 15:17, 15 April 2025 (UTC)[reply]
How often are virus links even posted to Wikipedia? Aaron Liu (talk) 15:20, 15 April 2025 (UTC)[reply]
Rarely but it can prevent it when it does id rather stop one virus than just sit by and let it go undetected •Cyberwolf•. talk? 15:24, 15 April 2025 (UTC)[reply]
on the Russian-language wiki tends to appear more often, a project abandoned to its own fate just as it was with China. (red annales) (talk) 22:09, 15 April 2025 (UTC)[reply]
They don't have an edit filter against non-autoconfirmed users adding external links? Aaron Liu (talk) 02:15, 16 April 2025 (UTC)[reply]
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.
Well i can write a script- its quite simple and i have been learning java script so might as well try •Cyberwolf•. talk? 12:52, 17 April 2025 (UTC)[reply]
Doing a plug in •Cyberwolf•. talk? 13:36, 17 April 2025 (UTC)[reply]

A problem with pushpin maps

[edit]

Hi, follow this scenario

  1. Go to article Tehran
  2. Click on pushpin map in its Infobox
  3. This image is shown that lacks marker of Tehran

This scenario does not seem true. So I propose that after clicking on Tehran's pushpin map, then its OpenStreetMap containing marker of Tehran will be shown in the new page. This way, the user has the ability to zoom in and out. Please discuss. Thanks. Hooman Mallahzadeh (talk) 11:52, 15 April 2025 (UTC)[reply]

The object above what you are talking does this •Cyberwolf•. talk? 15:09, 15 April 2025 (UTC)[reply]
@Cyberwolf Sometimes this OSM map does not exist. This behavior of
  • Showing a map without any indicator
after clicking on pushpin_map is not reasonable. I think the true scenario would be showing OSM map with an indicator. I think its implementation is very fast and convenient. This problem for Sydney article is more observable. Hooman Mallahzadeh (talk) 15:27, 15 April 2025 (UTC)[reply]
Then add a osm to the info box •Cyberwolf•. talk? 15:28, 15 April 2025 (UTC)[reply]
You are right, we can do everything. The problem is that this behaviour is a malfunction and is considered a software bug. Do you agree? Hooman Mallahzadeh (talk) 15:33, 15 April 2025 (UTC)[reply]
I don’t see it as a software bug tbh cause its an image with a marker overlay for precise location you use the other map •Cyberwolf•. talk? 15:36, 15 April 2025 (UTC)[reply]
See, this image https://en.wikipedia.org/wiki/Sydney#/media/File:Australia_relief_map.jpg which is shown after clicking on pushpin map of Sydney article does not contain any marker. Do you see any marker? So it is not useful at all. Hooman Mallahzadeh (talk) 15:39, 15 April 2025 (UTC)[reply]
It’s not the point of the pushpin map •Cyberwolf•. talk? 15:42, 15 April 2025 (UTC)[reply]
Yes you're right. We are redirected to a picture (of Australia) from Wiki Commons. I think this redirection is not true, because it does not contain any marker. We should redirect to somewhere that in addition to a marker, we can "zoom in" or "zoom out". This is only achieved by OSM maps. And I strongly believe that implementation of this redirection is very convenient. Hooman Mallahzadeh (talk) 15:47, 15 April 2025 (UTC)[reply]
Well I did some hands on with pushpin maps a relief map is what’s used which is just an image of the country making an image for it that’s a duplicate of what the push pin looks like will fix this •Cyberwolf•. talk? 15:55, 15 April 2025 (UTC)[reply]
I don't get what you said. How will fix it? The relief map that is shown after clicking is from Wiki Commons, and it does not contain any marker. How it would be fixed? Hooman Mallahzadeh (talk) 16:01, 15 April 2025 (UTC)[reply]
So by taking a screenshot of the marker and map uploading that and place that in the map thing •Cyberwolf•. talk? 16:19, 15 April 2025 (UTC)[reply]
This process is too hard to implement. I really think that a redirection to its place in OSM map would be implemented very fast and easily. Hooman Mallahzadeh (talk) 16:26, 15 April 2025 (UTC)[reply]
In addition, OSM has the ability to Zoom in/out that screenshot map lacks. I really think that this ability is very useful for every user. Hooman Mallahzadeh (talk) 16:29, 15 April 2025 (UTC)[reply]
I'd support this, if there's an easy way to implement it technically. Elli (talk | contribs) 16:52, 15 April 2025 (UTC)[reply]

@Elli:This is my proposed easy implementation:

1- Create an OSM map by this code:

{{Infobox mapframe|wikidata=yes|id ={{get QID|Tehran}} |zoom=4| stroke-width=1 |shape-fill-opacity=0|geomask={{get QID|Iran}}|mapframe-frame-coordinates= {{WikidataCoord|Tehran}}|marker=city}}

Which yields:

Map

2-place the above code in a hidden div tag

3-change hyperlink of pushpin map to something like "https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)#/map/0"

The same is true for other pushpin maps, just change Iran and Tehran to for example Australia and Sydney.

So easy-peasy. Hooman Mallahzadeh (talk) 17:28, 15 April 2025 (UTC)[reply]

The above implementation takes advantage of "geomask" argument of OSM which makes it completely the same as previously clicked pushpin map. I mean it is not just coordinates that redirects to https://geohack.toolforge.org site as this link for Tehran. Hooman Mallahzadeh (talk) 07:55, 16 April 2025 (UTC)[reply]

Helping bring more interest in Wikipedia with racing fans

[edit]

I have had an idea for the last couple months which has incubated a lot. It’s sorta a gathering for the current editors of motorsports articles to talk and watch the race while having a front end that brings in new editors for a potiential workshop on how to edit tables (pretty big issue) and create articles. What usually stops my train of thought is money I don’t know how expensive one of these would be but i want to just throw this at the wall and see if it sticks •Cyberwolf•. talk? 14:47, 15 April 2025 (UTC)[reply]

Are you thinking about a virtual event or an in-person one? WhatamIdoing (talk) 18:22, 16 April 2025 (UTC)[reply]
Any? •Cyberwolf•. talk? 18:48, 16 April 2025 (UTC)[reply]
Virtual events are cheap. You need a way to find and recruit potentially interested people (e.g., social media) and a way for them to talk (e.g., a Zoom account). Editing ordinary tables is easy: you use the visual editor on the desktop site (i.e., not mobile).
I suggest attending a couple of events before you trying hosting one. Check the m:Events calendar or similar pages to find something that sounds similar to what you'd like to do. The event coordinators might even be willing to talk to you about their planning work. WhatamIdoing (talk) 19:02, 16 April 2025 (UTC)[reply]
Everything can be improved even further, but, having this in mind, I've sometimes thought that having all articles with the same quality as we have in articles about Formula 1 or some other sport competitions (for example, FIFA World Cup), would be a good target to set. Their consistent structure is really great. MGeog2022 (talk) 11:02, 19 April 2025 (UTC)[reply]

Could drafts be protected instead of deleted?

[edit]

After I saw a draft for Sprunki get nominated for deletion for the same reason that the one for Battle for Dream Island had been deleted and salted, that got me thinking:

Instead of deleting drafts that are resubmitted to oblivion, why not semi-protect or extended confirmed protect them so unregistered (and newly registered) users won't be able to submit them anymore?

In order to submit a draft, the template {{AfC submission}} has to be placed on the page. If it's semi-protected, then only autoconfirmed editors should be able to submit it. If it's extended confirmed protected, then only extended confirmed editors could submit it, and everyone else would have to place edit requests on its talk page where they can be declined by other editors.

Here's a list of times that the Sprunki draft was submitted:

Date Account age then Edit count then Autoconfirmed? Extended confirmed?
October 12, 2024 Unregistered; not applicable ☒N ☒N
November 24, 2024 Unregistered; not applicable ☒N ☒N
December 15, 2024 0 days 11 ~ Not until Dec. 19 ☒N
April 3, 2025 2 days 12 ~ Not until Apr. 5 ☒N

Just for the sake of comparison, here's a list of the times that Barron Trump had been submitted whilst it was still a draft:

Date Account age then Edit count then Autoconfirmed? Extended confirmed?
November 28, 2023 19 days 109 checkY ☒N
November 9, 2024 493 days 858 checkY checkY
January 21, 2025 Unregistered; not applicable ☒N ☒N
January 24, 2025 Unregistered; not applicable ☒N ☒N
January 26, 2025 2,292 days 189 checkY ☒N
March 4, 2025 16 days 28 checkY ☒N
March 16, 2025 27 days 25 checkY ☒N
March 23, 2025 34 days 51 checkY ☒N

If protecting drafts isn't a good way to deter resubmissions and save reviewers' time in the process, I'd like to know why not. – MrPersonHumanGuy (talk) 15:43, 15 April 2025 (UTC)[reply]

Sprunki isn’t an good example due to it’s lack of coverage and it’s lacking general notability •Cyberwolf•. talk? 15:57, 15 April 2025 (UTC)[reply]
Protecting page names is what should be done •Cyberwolf•. talk? 15:59, 15 April 2025 (UTC)[reply]
@MrPersonHumanGuy: This would also require move protection at the same levels, so that an autoconfirmed editor can't just move it into mainspace and bypass the process. And given that drafts are NOINDEXed and hard to find unless you're willing to use the internal search engine and know their exact title, this would end up causing a lot of drafts that don't have a chance to languish. Another factor to consider is that, unless express permission is given, people generally are unwilling to edit someone else's draft. —Jéské Couriano v^_^v threads critiques 16:02, 15 April 2025 (UTC)[reply]
As a contributor who would be unwilling to edit other people's drafts myself, you are especially correct about that, which is why I like to copy userspace drafts into draftspace and edit such copies as I see fit. Of course, I could just move a draft, but I would be concerned that its creator may get surprised to find out that it's been moved all of a sudden. Then again, some drafts do get forgotten for months before they're rediscovered by at least one other contributor.
Topic Original userspace draft Draftspace counterpart
A World Without (web series) User:FroggyTranslator/A World Without... Draft:A World Without (web series)
Time Traveler Luke User:DDG9912/Time Traveler Luke Draft:Time Traveler Luke
I'm only bringing these up on a case-in-point basis. These two drafts don't (and won't) need page protection at this time, as neither of them have been submitted, nor do they (as of yet) appear to have the sort of meme status or popularity with certain demographic niches that would cause them to be at risk of being submitted by obsessive fans of their respective subjects in the foreseeable future. Please excuse my darned affinity for tables. – MrPersonHumanGuy (talk) 19:32, 15 April 2025 (UTC)[reply]
Doesn't protection automatically apply move protection? Aaron Liu (talk) 22:29, 15 April 2025 (UTC)[reply]

Color "additional considerations apply" as purple and "no consensus" as yellow at RSP

[edit]

Currently, the "additional considerations apply" and "no consensus" statuses have the same "MRel" yellow grouping at WP:ReliableSourcesPerennial. This has caused some confusion for closers and those unfamiliar with what RSP actually is: a summary of past consensus and not any sort of guideline; "no consensus" makes a source's status "no consensus" instead of preserving the previous status. This also makes it a bit harder to differentiate "consensus for additional considerations" from "no consensus". Thus, I propose we add purple200 (#d9d0e9) as a color for "additional considerations apply". This color provides sufficient color contrast against foreground text and seems the most friendly to colorblind people. Aaron Liu (talk) 22:28, 15 April 2025 (UTC)[reply]

I agree with the general shape of this proposal but would reverse the colors. IMO "additional considerations apply" should be thought of as the actual step between WP:GREL and WP:GUNREL, with "no consensus" as a sort of "null" represented by a color outside the normal range. Loki (talk) 00:37, 16 April 2025 (UTC)[reply]
"No consensus" doesn't mean null guidance; it's indeed more caution than GRel and less caution than GUnRel. Aaron Liu (talk) 02:14, 16 April 2025 (UTC)[reply]
Notified: Wikipedia talk:Reliable sources/Perennial sources. Thryduulf (talk) 22:50, 15 April 2025 (UTC)[reply]
I don't see a need for this distinction. A source in yellow means spend some time thinking about this one. Purple would also mean spend some time thinking about this one... a meaningless distinction. Headbomb {t · c · p · b} 00:53, 16 April 2025 (UTC)[reply]
One has full consensus behind spending time thinking about this one and detailed directions on how to, as opposed to the far more general "we're not sure if this source is reliable, double-check". Contrary to Loki I feel like the former is on a different spectrum. Aaron Liu (talk) 01:06, 16 April 2025 (UTC)[reply]
"No consensus" doesn't mean "welp, no idea" - it means there was a discussion that failed to achieve a consensus that the source was reliable and it definitely has a lesser status than reliable - David Gerard (talk) 20:15, 18 April 2025 (UTC)[reply]
I agree. That's why it should be clearly distinct from "just make sure to check these specific things", don't you think? (By "not sure" I do mean what you meant; "not sure" is not "no idea", her means it decidedly falls short of reliable from community consensus.) Aaron Liu (talk) 21:02, 18 April 2025 (UTC)[reply]
No, this doesn't seem to match what these do - David Gerard (talk) 20:16, 18 April 2025 (UTC)[reply]
How so? Aaron Liu (talk) 21:02, 18 April 2025 (UTC)[reply]

Moving logos, album covers etc out of infoboxes

[edit]

I am concerned that the current default practice of adding logos, album covers, film posters, box art etc to infoboxes is stifling commentry, criticism and free content generation.

Very often these items are fair use whose purpose is for "criticism, comment, news reporting, teaching, scholarship, or research" (random website) and the Non-free content guideline lists Contextual significance as a factor. By moving these images out of infoboxes we would be encouraging captions that provide critical commentary, enhancing contextual significance. And hopfully free alternatives would be generated.

Current examples:

  • National Hockey League: the uncaptioned logo is the only image you see on the page on mobile, an interesting caption is only found on the child article for some reason. An alternative would be a photo of an NHL game.
  • GoldenEye: the film poster actually has a caption, but the image would be better placed in the section that discusses poster curation. Ideally a free photo of the film's production could be used in the infobox.
  • Let's Get Out of This Country: no caption for this album cover, which actually has an interesting backstory. I suppose I am meant to write the sourced passage about the cover down in the body, add a synopsis in the infobox caption and expect the reader to scroll up and down when reading the passage. Ideally a free photo of the band in the recording studio could be used in the infobox.

I understand that having these logo/album cover type images in infoboxes is an easy way to make the article look pretty and to help familiarise the reader with the promotional materials, but is that our priority? It can be difficult to find freely licenced ideal alternatives, but we should try. Commander Keane (talk) 00:15, 16 April 2025 (UTC)[reply]

I don’t see how placement in the infobox precludes sourced critical commentary in the body. ꧁Zanahary꧂ 00:20, 16 April 2025 (UTC)[reply]
I agree. These examples can all be changed: I would support the recommended changes to the latter two pages, and for the first page I would just copy over (and condense) the caption on the child page and throw it into the infobox. None of this needs something that says such images shouldn't be in infoboxes. Aaron Liu (talk) 01:42, 16 April 2025 (UTC)[reply]
Am I right in reading this as a question about whether WP:NFC used in the infobox meets the WP:NFCCP policy, rather than a general question about whether logos, album covers, etc. should be in infoboxes or not? CMD (talk) 00:33, 16 April 2025 (UTC)[reply]
Per NFCI#1, images that are used for identification in infoboxes are presumed to meet NFCC#8 as they provide implicit branding and marketing of the topic in question. If they can also be used for additional purposes (for example, Ico's cover is discussed in the article as being based on a classical work of art), great, but we do not have that requirement to require more than the topic being notable in the first place to use identifying images. Masem (t) 02:13, 16 April 2025 (UTC)[reply]
I think the biggest hurdle to my idea is in WP:LEADIMAGE: which says the purpose of these is to ...give readers visual confirmation that they've arrived at the right page.
I am trying to encourage critical commentary on images, fair use or not; free material is certainly a bonus. I guess placement in the infobox doesn't prevent that, but is it appropriate to double up usage in the body? It would be better to place a captioned image next to the relevant discourse in the body. Ico, a featured article, is interesting in that an unreferenced caption is in the infobox, the inspiring artwork with one reference is in the Development section and commentary with two other references is in the Release section, along with the alternate box art.
Getting implicit branding and marketing in the infobox is certainly the goal of many an articles-for-creation contributor, which actually sparked my initial post. Also, as a newbie when looking to illustrate an article I uploaded a logo rather than look for a public domain image or request for a Wikipedian to take one. In that case, my critical commentary was actually moved away from the logo's caption when an infobox was introduced.
I had assumed that there was no policy problem with non-free content in infoboxes, and my examples all feature non-free content because that is what you typically find in infoboxes. I had no intention of splitting infobox image usage by copyright status, or giving non-copyright promotional material a free ride on critical commentary. Commander Keane (talk) 06:37, 16 April 2025 (UTC)[reply]
It's a cupcake. Do we really need critical commentary on the photo?
About I am trying to encourage critical commentary on images, fair use or not: Why?
I wonder if we have different ideas about what "critical commentary on the image" means. So I've added a photo. IMO critical commentary on the image would sound like "The cupcake is placed off center on a neutral background, with multiple lighting sources from the back and left, causing a shadow to fall to the right and front".
I suggest to you that the article Cupcake needs many images, but does not need any critical commentary on its images. WhatamIdoing (talk) 18:32, 16 April 2025 (UTC)[reply]
Indeed "critical commentary on images" is not the phrase I meant. More of an "useful encyclopedic comment for image captions", of which every image in Cupcake has. By critical I was intending, in your photo for example, "A sample from the Cupcake Camp Montreal fundraiser" rather than "A pretty one with sprinkles", or nothing. Commander Keane (talk) 23:38, 16 April 2025 (UTC)[reply]
Citation needed that it is a cupcake from the Montreal fundraiser. Sounds like OR to me. Blueboar (talk) 23:52, 16 April 2025 (UTC)[reply]
Yes, imagine a culture where you need to put a caption and find a reliable source to back it up. The Hostess Cupcake photo used in Cupcake may well have been baked by the photographer's grandmother for all I know. I would say images get a special treatment for OR, so I will trust that editors familiar with the brand have confirmed the photo is legit. I trusted the Montreal cupcake's file page, but if that is not enough then better sourcing is required. Effort is not a bad thing. My point of the caption was to introduce the reader to cupcake's cultural significance to fundraising, not mentioned in the article yet.
I don't know why we are talking about cupcakes, my problems were:
  • the culture of not bothering with captions in infoboxes, and when we do we must condense the message - which is reasonable as infoboxes are required to be simple, and
  • the editorial constraint of not being able to use those infobox images in the body near where they are discussed.
For the second problem, the proposed little anchor symbol that I think was suggested for the Barack Obama lead that would jump readers to the relevant section would help (I can't find the guideline on that anymore). Looking at the feature article Ico it seems the current idea is that readers intend to sit down and read the entire article so we can spread information, in that case about box art with accompanying images, throughout the article. Fair enough. I will leave it at that and try my best at working with current practice. Commander Keane (talk) 01:43, 17 April 2025 (UTC)[reply]
An image is supposed to illustrate something in the article. The point being illustrated might be, especially for a lead (including, but not limited to, infobox) image, "This is what the subject of the article looks like". There's nothing wrong with Barack Obama having a simple caption like "Official portrait". There's also nothing wrong with Ico having a caption that's 27 words long. The caption should serve the needs of the article.
If we had a section in Cupcake about its use in (US and Canadian) fundraising bake sales, then the photo above would need a caption like "A cupcake from a fundraising event" or "Cupcakes are popular at bake sales", or something like that. But:
  • If it's not saying anything 'new' compared to the text, there's no need to duplicate the citation just so there's a little blue clicky number visible in the caption. There is no need for a paragraph that says "Cupcakes are sold at fundraisers[1]" followed by an image caption that says "Cupcakes are sold at fundraisers[1]". Citing once per fact is enough.
  • The same photo can often be used to illustrate multiple points. If this image were in a ==Fundraising== section, then the caption should be about fundraising. But if this image were in a ==Decorating== section, then the caption should be about icing and sprinkles. And if it were used in a different article, it would need still yet a different caption. For example, if it were in Red dye number 3, next to a paragraph noting that most of Europe can't get such beautifully red sprinkles, because – unlike Canada, whence this cupcake hails – Europe has banned red dye number 3, then it would need a caption about the food dyes used in sprinkles. (Hmm, no photos in that article. Maybe I'll have a look around. A comparison of Red 3 vs some other red might be very nice.)
WhatamIdoing (talk) 03:35, 17 April 2025 (UTC)[reply]
1. User:WhatamIdoing stop talking about Cupcakes it is making me hungry!.
2. I am with WhatamIdoing on his comments about captions. Infoboxes are supposed to be a quick view outlining info on the article, so as per previous example the Goldeneye poster is enough for the infobox, the same as as Cadbury logo in the Cadbury page - it does enough to show what it is. Davidstewartharvey (talk) 05:05, 17 April 2025 (UTC)[reply]
Particularly for non-free which are only being used under a NFCI#1 claim as an identifying image and have zero further commentary about them, then the caption should be brief, or in cases where what the image like a movie poster or album cover, the caption omitted entirely.
Its when the image has more purpose for inclusion beyond just identification, as in the case of Ico as I've mentioned, then a more fleshed out caption should be reasonable, as that should help the reader locate where the image may be discussed more in the body. The caption should not include information not included in the body, however (eg LEDECITE should apply) Masem (t) 13:08, 17 April 2025 (UTC)[reply]
I don't think you can complain about cupcake examples and substitute with chocolate! I can now see that people love their branding in infoboxes, images with their captions are incidental to the cited text and that some images don't need a caption.
For Cadbury I would at least like to see a "Current logo" caption to prompt me to realise it hasn't been that way for 201 years. Then it is up to me to clunkily ctrl-F for "logo" (if magical links are forbidden) to be enlightened by the origin story in the Advertising section. You could say "go for it, add the caption as it increases value" (or maybe not) but my point is why no editor has added a caption already. A better caption could be "Current logo. Since the 1970s logos have been based on the signature of the founder's grandson", but that is too much for the infobox. I am going around in circles in this discussion. I want to have great captions on the relevant images near the relevant text. I understand this has to be balanced with the brevity and visual confirmation objectives of the infobox, and the need to distribute images throughout an article for aesthetics. Unfortunately all of these things can't be achieved and maybe my desire is unfounded.
Admittedly, removing official branding from infoboxes is not a good idea as it would introduce the problem of de minimis substitutes, like the way File:Cadbury World sign, Bournville.JPG is used in the Cadbury#Advertising section, and again in United Kingdom company law.
I probably should have started this idea thread stating that I really enjoy a good caption and encouraging free content. The way I skim an article is to read the intro and look at captions to see if anything piques my interest.
The blue magical clicky thing I mentioned is not a citation, and adding new information in captions can be a chicken-and-egg scenario with a work-in-progress. Commander Keane (talk) 01:56, 19 April 2025 (UTC)[reply]

Nostalgia Wikipedia 25th anniversary

[edit]

On January 15, 2026, Wikipedia will turn 25 years old. As part of the celebrations, it would be fine to have a new edition of Nostalgia Wikipedia for the future, with its content as of that date, as we have it from December, 20, 2001 (https://nostalgia.wikipedia.org/wiki/HomePage). The same mechanisms used by Wikipedia Version 1.0 Editorial Team could be used to remove vandalisms that are active at the very moment that the snapshot is taken.

It could be deployed online (as is the case with the 2001 version) and be also made available for download as a ZIM file.

This way, it would be easier to have a quick view of the evolution and improvement of Wikipedia over the years (2001, 2026, 2051...). Having a look at 2001 Nostalgia Wikipedia, the enormous progress made since then is really obvious. MGeog2022 (talk) 12:42, 18 April 2025 (UTC)[reply]

This is a good idea. Thryduulf (talk) 14:21, 18 April 2025 (UTC)[reply]
Meh ... that's what the Wayback Machine is for (and unlike Wikipedia's servers, it's actually designed to archive things). The overhead of permanently hosting a 2026 version of Wikipedia would be orders of magnitude greater than that of hosting the Nostalgia Wikipedia, not just because of the vast increase in database size but also because there were no inline images/videos/audio files in 2001. The other advantage of the Nostalgia Wikipedia is that it contains edits that aren't in the current Wikipedia database (or weren't until I and others imported them), which is much less likely to be an issue now. Re curating the entire current Wikipedia database for vandalism: that's logistically impossible and highly unrealistic. Graham87 (talk) 03:11, 19 April 2025 (UTC)[reply]
I understand your viewpoint. Media files could be taken from Commons (yes, some of them could be eventually deleted or overwritten), so only text would need to be saved (around 90 GB, I believe, that shouldn't be too much for WMF). The current financial and infrastructure (including backups, or more precisely, the absence of them) resources of Internet Archive (owner of Wayback Machine), make it difficult to assume its long-term permanence. Fortunately, Wayback Machine also takes content from external open projects such as Common Crawl, that stores many sites, including all or most content of English Wikipedia. Wikipedia's own full dumps also include revision history for all articles (history that is also available online for each article). Both Common Crawl and dumps with full history provide a guarantee of long-term preservation. My idea was about making this more accessible to the general public, rather than only preserving it. MGeog2022 (talk) 11:15, 19 April 2025 (UTC)[reply]
Media files wouldn't just be taken from Commons; they'd also have to be taken from local uploads (especially our non-free content, if we chose to include it in the hypothetical snapshot). Luckily our non-free content policy has become relatively stable. Graham87 (talk) 11:37, 19 April 2025 (UTC)[reply]
In the long term, it may be worth developing a feature to view the encyclopedia at a specific date into a MediaWiki extension (or client side Javascript extension that fetches the data using the API), else we may end up with masses of redundant copies. Simlar to how GitHub and its competitors allow viewing a repository at a certain commit.  novov talk edits 09:53, 20 April 2025 (UTC)[reply]
That's phab:T7877, which will celebrate it's 19th birthday next month. Thryduulf (talk) 10:40, 20 April 2025 (UTC)[reply]
It's a great idea. Let's hope it won't be necessary to wait for another 19 years before it's implemented. Many things can be learned from past versions of articles, but it isn't easy to navigate in hundreds or thousands of revisions. And many people aren't aware of this or of the option to read the article's past versions in Wayback Machine. MGeog2022 (talk) 14:37, 20 April 2025 (UTC)[reply]
Objects in git can't include content from another object without running a build process to generate the combined objects. Just considering the pages within English Wikipedia, every transclusion would have to be mapped to a specific version, and each time a transcluded page is changed, all of the pages transcluding it would have to be updated to the new version. (This mechanism would have also have to handle content transcluded from Commons.) This would massively increase the version history of pages (at least within the database) and the processing load for changing transcluded pages. Any pages, or specific revisions of pages, that have ever been transcluded couldn't be deleted from the database. It could be made to appear deleted to regular editors, which may add some complications if, for example, a template is created, used, no longer used and pseudo-deleted, and then a new template with the same name is recreated. The history of the two templates should remain distinct.
Alternatively, the MediaWiki software could be rewritten to take the git approach of versioning the entire repository as a whole. But this requires locking the entire repository for each commit being made, so there's always a distinct set of files being changed from one version of the repository to another. This doesn't scale well to the size of Wikipedia's editor base, and doesn't handle content transcluded from Commons. It would also be a fundamental change to how pages are managed. isaacl (talk) 17:51, 20 April 2025 (UTC)[reply]
Of course doing something which works exactly the same way as Git would be an impossible undertaking. I was thinking something more limited, where a page is only computed on-demand for a timestamp, where the last revision before that timestamp is fetched for page content and transclusions. If images/transcluded content is deleted, then it still isn't shown. Of course it wouldn't be fully accurate with moves/deletes/creations etc but it'd be more accurate than current page history and IMO "good enough" for a good portion of pages.  novov talk edits 10:56, 23 April 2025 (UTC)[reply]
Sure; the comparison to git just seemed inapt for what is achievable. A more limited capability would put the burden on browsing time and I'm not sure how usable it would be, given the slowness and inaccuracy. isaacl (talk) 17:41, 23 April 2025 (UTC)[reply]

Tasks/Missions

[edit]

New policy: The users can make their own pages as task boards, with two tabs: tasks, which show what it will do in the future, and missions, important things of the user that will be done soon. 2001:1308:2695:7300:E167:FFB0:A392:8002 (talk) 15:18, 20 April 2025 (UTC)[reply]

It is not for posting spam, etc, nor do you need to post one. 2001:1308:2695:7300:E167:FFB0:A392:8002 (talk) 15:19, 20 April 2025 (UTC)[reply]
Can't we already? Aaron Liu (talk) 19:56, 20 April 2025 (UTC)[reply]
We can put that content on our user page if we wish to. The proposal seems to be to have predefined tabs. I oppose it for two reasons:
  1. It assumes everyone wants to put the same stuff on their user page, and
  2. It makes this seem like a social media site, rather than an encyclopedia.
Phil Bridger (talk) 20:07, 20 April 2025 (UTC)[reply]

Grant move-subpages to template editor user group

[edit]
Moved to Wikipedia:Village pump (proposals) § Grant move-subpages to template editor user group
 – There is an unanimous support in the discussion so far. However, I am moving the discussion to VPP to gain a wider consensus before filing a phab ticket. – robertsky (talk) 14:21, 24 April 2025 (UTC)[reply]

What to do about prior draft decline notices

[edit]

If a draft is declined several times, users usually have to scroll a lot to see the content beneath all of those notices.

Idea A: Collapsible
Other AfC submission notices

Initially, I thought it would be neat if prior notices could be put in a collapsible box like how most talk page notices are encased within {{banner holder}}. I've experimented with putting decline notices in {{collapse}}, but when I set their width to match those of decline notices, it always causes decline notices to become significantly narrower, as if to maintain the presence of two gaps beside each.

It's possible for a box of this width to be positioned in the center...
Other AfC submission notices
...and still be able to fit in a collapsible box of equivalent width without becoming narrower.
Nevermind, draft decline notices already shrink like this. The {{AfC submission}} template also has small as one of its parameters, but it unfortunately hides the reason as well, so I'm sticking with an improved version of my other idea.
P.S. The blue background makes the box inside look gray. – MrPersonHumanGuy (talk) 01:21, 24 April 2025 (UTC)[reply]

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.

Idea B: Shrinking

Alternatively, a parameter (like small) could be added to {{AfC submission/declined}} that would allow for a notice to be shrunk down to a fraction of its usual height by hiding the {{blist}} and {{AfC submission/helptools}} stuff in order to reduce their redundant presence in repeatedly declined drafts. If implemented, such a parameter should cause an example blank notice to look like this when enabled:

Since other types of AfC submission notices usually don't appear below any subsequent AfC submission notices on drafts, it may not be necessary for us to be able to shrink those other types. I know these templates can only be edited by template editors, but these suggestions are specifically directed towards them too. – MrPersonHumanGuy (talk) 16:01, 21 April 2025 (UTC)[reply]

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 prefer the second idea, but I'd suggest something even shorter and with more information: "Submission declined by [user] on [date]: [Reason here]". Most of the decline message consists of general advice for the author, which I agree we do not need to repeat three or four times verbatim. I also like the idea of collapsing declines after rejection. Toadspike [Talk] 19:55, 22 April 2025 (UTC)[reply]
When used on drafts to indicate legitimate declines, they generally include user and date information on their bold text already, along with reasons if any are provided. I'm not saying those details should be removed or altered in any way, they should continue to appear as they would usually appear in a normal-sized notice. Are you saying that the reason should appear in the top text itself instead of a box below it? – MrPersonHumanGuy (talk) 01:18, 23 April 2025 (UTC)[reply]
Update: I just looked at a couple of drafts again and found out that my second idea has already been in fruition. However, if a draft is declined several times, then I think a template like an {{AfC decline notice shell}} might still come in handy if that were to ever be invented one day. On the other hand, being able to collapse/expand the reason-boxes wouldn't seem like a bad idea either. – MrPersonHumanGuy (talk) 01:30, 23 April 2025 (UTC)[reply]
Chiming in to say that the box with the text "It's possible for a box of this width to be positioned in the center..." and the collapsible box are currently broken for me on this page. It is going past the right bounds of the text and covering up the "appearance" options that show on the right by default. When lowering the width of my browser window, the box goes past the right edge of the window and at certain sizes the text in the box goes past as well. This is a tiny bit disruptive to reading, and I'm not gathering that it's an intentional effect. Nebman227 (talk) 14:20, 23 April 2025 (UTC)[reply]
In this case, {{hidden}} appears to be a better notice holder than {{collapse}}, except it would have to be rendered as {{hidden|ta1=center|style=font-size:100%}} so it doesn't shrink the text inside. I think it could still work especially if the collapsible/expandable template is also wrapped in an {{ombox}}.
The notices would still get narrower, but if a template editor adds a wide parameter to {{AfC submission}} just for such cases by simply replacing the string ombox with {{#ifeq:{{{wide|}}}|yes|fmbox|ombox}}, then the notices would be able to fill the container like this:
Yes, I figured out how to simulate the notice's reason box this time.
If the example code is implemented, editors wishing to make the notices less narrow in the notice holder would have to put wide=yes on each notice within. That aside, the source for a hypothetical {{AfC notice shell}} template may look like this:
{{ombox|image=none|style=background:#fee;|text={{hidden begin|title=Prior draft decline notices|ta1=center|style=font-size:100%}}
{{{1}}}
{{hidden end}}}}
– MrPersonHumanGuy (talk) 23:16, 23 April 2025 (UTC)[reply]

Preferences for Units

[edit]

As far as I'm aware, Wikipedia does not have a system for converting measurement units to those of other systems. The idea is to add certain editing syntax to allow editors to specify which system of measurement is being used, alongside its amount. This could be used to add user preferences that apply globally, by converting the variables in that syntax to those of the user-selected measurement system.

For example, instead of writing: "Mount Everest is 29,031.69 feet (8,848.86 meters) in height," it would be written (in Wikitext), approximately as: "Mount Everest is [is ("is" being short for Imperial System); ft: 29,031.69] in height," which would then be converted to the user's preferred measurement system, or remain as the author wrote it in case of correspondence. I'm not very familiar with Wikitext, so the syntax may seem messy. Some English Monarch IV (talk) 10:31, 22 April 2025 (UTC)[reply]

And if the user has no preference, or is logged out, then they get metric ( "Mount Everest is 8,848.86 metres in height") right? Hawkeye7 (discuss) 10:34, 22 April 2025 (UTC)[reply]
It's the system most use, so yes. Although a more sophisticated system, perhaps using geolocation to determine the country of the user—and the popular system therein—could also exist. Some English Monarch IV (talk) 10:40, 22 April 2025 (UTC)[reply]
I think {{convert}} does some or most of what you want? For example:
Mount Everest is {{convert|29031.69|ft|m}} in height
renders as:
Mount Everest is 29,031.69 feet (8,848.86 m) in height
SunloungerFrog (talk) 10:45, 22 April 2025 (UTC)[reply]
Yes, the {{convert}} template should be used. As most measurements are approximate, and the degree of approximation is not often specified, I think it's best to use the sourced units first. As regards user preferences, I know of no people who are actually offended by seeing different units, and what would you do about the UK, where I buy petrol in litres but measure its consumption in miles per gallon? Phil Bridger (talk) 10:55, 22 April 2025 (UTC)[reply]
Yes, that does resolve most of my problems. Thank you for the information. Some English Monarch IV (talk) 11:47, 22 April 2025 (UTC)[reply]
Also see Wikifunctions, which could eventually replace {{convert}}. --Ahecht (TALK
PAGE) 17:21, 24 April 2025 (UTC)[reply]

The Wikipedia:Community portal page sucks.

[edit]

It sucks. There are way too many headers. It is impossible to navigate. Think if it were simplified, the immense joys that life would behold. JustMakeTheAccount (talk) 06:01, 23 April 2025 (UTC)[reply]

I think the headers are clear. Which headers are you confused by? Aaron Liu (talk) 11:55, 23 April 2025 (UTC)[reply]

proposed template, for contentious topic areas

[edit]

initial idea

[edit]

i have drafted the template below, for use with Israeli-Palestinian articles, but it could work with any highly contentious topics. what do you think of this?

Sm8900 (talk) 20:46, 21 April 2025 (UTC)[reply]

I feel like that goes against Wikipedia:No disclaimers. And any article that has content issues may already use the relevant maintenance tags. (Also, I love the second paragraph, but surely you know that cannot represent Wikipedia.) Aaron Liu (talk) 15:17, 23 April 2025 (UTC)[reply]
@Aaron Liu, fair enough, those are valid points. to address your last point, i added the tag [just kidding]. maybe that helps? Sm8900 (talk) 15:27, 23 April 2025 (UTC)[reply]
It doesn't. Aaron Liu (talk) 16:54, 23 April 2025 (UTC)[reply]

comments

[edit]

post comments below. --Sm8900 (talk) 15:15, 23 April 2025 (UTC)[reply]

Although this is a fun idea, it is in no way of the proper tone for a world-wide audience, let alone making WP appear as a serious resource. It is self-contradictory, contradicts multiple guidelines/policies, and is disrespectful to good-faith editors. DMacks (talk) 15:38, 23 April 2025 (UTC)[reply]
@DMacks let me try to address your points. i do hear your concerns, and I absolutely do respect all of them as important and valid.
  • no way of the proper tone for a world-wide audience, let alone making WP appear as a serious resource.
    • you have a valid point here; however i would suggest a slightly different take. i feel this promotes transparency to some extent, by taking a highly contentious and volatile editing area, and openly stating that one method used to cover the topic of this conflict, is by being fair to some degree to both sides.
  • self-contradictory, contradicts multiple guidelines/policies
    • a valid concern, but what you are perhaps omitting slightly is that in fact, real compromise is totally valid, especially when two groups of competent editors each have massively different versions of the essential facts for an important current topic.
  • is disrespectful to good-faith editors
    • since this references my own personal feelings, let me say that a) i appreciate you expressing your sincere concerns on this, b) i absolutely do respect good-faith editors; c) since i am in fact an experienced editor and a good-faith editor, my own ideas above are in fact full in good faith, so perhaps i would ask for that consideration as a courtesy, based on WP:AGF.
Again, i do sincerely appreciate your concerns,, and your insights above. thanks. Sm8900 (talk) 20:43, 23 April 2025 (UTC)[reply]
It would cause way more confusion than the little benefit it does. Why do we need this when we can already do maintenance tags, especially since that banner would need to be manually added to every page anyway (without going through the bureaucratic process of asking WMF to install an extension)? And Wikipedia:No disclaimers has guideline-level consensus backing; the little amount of dispute should tell you how much this rule is respected.
(Also, I think DMacks only said that the wording was disrespectful and didn't mean to imply you meant to be disrespectful.) Aaron Liu (talk) 00:43, 24 April 2025 (UTC)[reply]
Correct, sorry if I wasn't clear. DMacks (talk) 01:47, 24 April 2025 (UTC)[reply]
@DMacks, ok appreciate your helpful clarification on that. and thanks @Aaron Liu. Sm8900 (talk) 17:53, 24 April 2025 (UTC)[reply]
You can't be serious. jlwoodwa (talk) 21:32, 23 April 2025 (UTC)[reply]
@Jlwoodwa, i am serious, and don't call me Shirley. (you didn't, but my reply seems a bit funnier, if i reply as if you did.) Sm8900 (talk) 18:03, 24 April 2025 (UTC)[reply]
@Jlwoodwa, the note of whimsy/humor/jocularity actually in fact does serve a valid purpose; namely, using humor to restore the tone of collegiality/cooperation which wikipedia relies upon, to keep our work and our efforts going on a positive basis. Sm8900 (talk) 19:49, 24 April 2025 (UTC)[reply]
Note that this spawned from a very tongue-in-cheek post made by Herostratus at Wikipedia:Village pump (miscellaneous)#Just shoot me; possible hatnote template, for Israel-Palestinian articles. And I have to say that the template in the original joke post was much more accurate. Thebiguglyalien (talk) 🛸 05:09, 24 April 2025 (UTC)[reply]
I'm not a fan of the suggestion there is a true NPOV that can be expected, rather than NPOV being a idealistic goal we try and figure out to varying degrees of success. CMD (talk) 05:15, 24 April 2025 (UTC)[reply]
Personally, I find the editors who make holier-than-thou vagueposts in a "pox on both your houses" vein to be the most annoying part of this topic. If you see a problem with an article or with an editor's behavior, address it directly. Moreover, the suggestion that it is two distinct groups at odds with each other in this area also belies a very simplistic understanding of the conflict; if we're talking about discrete positions, especially with respect to how an encyclopedia treats the topic, the number is closer to 20 (or possibly even 200) than 2. signed, Rosguill talk 14:34, 24 April 2025 (UTC)[reply]
@Rosguill ok, good points, i have revised it, based on your suggestion on amount of differing groups. Sm8900 (talk) 17:54, 24 April 2025 (UTC)[reply]
@Rosguill, also please note: I said "for truly updated information"; i never said the article itself is invalid, i simply meant that the article's content may lag slightly, due to contentious issues that need to be resolved, and other reliable sources might be more timely. Sm8900 (talk) 17:59, 24 April 2025 (UTC)[reply]
There is a true NPOV as the average of RSes that exist, but this template's "both sides" reeks of Wikipedia:False balance. Aaron Liu (talk) 14:45, 24 April 2025 (UTC)[reply]
I don't know about that. Even taking that as true and the goal of NPOV, anyone saying they can average all RS that exist on Israel and Palestine is not telling the truth. Also, as Rosguill notes, you're looking at some sort of n-dimensional hypercube of views, and there's only so far you can navigate that in written language. CMD (talk) 16:38, 24 April 2025 (UTC)[reply]
Of course; everyone has their own subjectivity. That doesn't mean NPOV isn't what we strive for. We only navigate views with Due weight for good reason. Aaron Liu (talk) 13:12, 25 April 2025 (UTC)[reply]
This whole thread is very Sarcastaball. ScottishFinnishRadish (talk) 17:54, 24 April 2025 (UTC)[reply]
@ScottishFinnishRadish, actually... it so happens that that's not such a bad metaphor, i.e. for the initial item that i was trying to address in fact. so thanks! Sm8900 (talk) 18:00, 24 April 2025 (UTC)[reply]
Not familiar with that as a metaphor but I think that sometimes we need to IAR and get to the heart of a problem. I believe the problem in this topic area is a fundamental failure of our NPOV guardrails. Honesty is the best policy. Coretheapple (talk) 19:49, 24 April 2025 (UTC)[reply]
Agree Sm8900 (talk) 19:52, 24 April 2025 (UTC)[reply]

Archives

[edit]

There is a growing number of articles with a growing number of archives, and searching these archives is not easy. It would be really helpful if the archiving bot also could make a list of all closed discussions (requested moves, requests for comments etc) with a link to the discussion and the summary of the conclusions. So when a new editor comes along and requests a change, and an old editor thinks, but didn't we have this long discussion about it, when was it, a year ago? can easily find this discussion. Lova Falk (talk) 15:03, 24 April 2025 (UTC)[reply]

ClueBot automatically generates an index (e.g. User:ClueBot III/Master Detailed Indices/Talk:Switzerland) if it used to archive instead of the more popular Sigmabot. Many talk pages like Talk:Persecution of Uyghurs in China include a list of frequently cited discussions with an {{FAQ}}. Aaron Liu (talk) 15:55, 24 April 2025 (UTC)[reply]
For instance, look at Talk: African Americans. Rather regularly, editors propose a name change to Black Americans. When searching the archives for Black Americans, you get 27 results, about as many as there are archives. Search for Move, also more than 20 results. It would be so good to have a list of all Move discussions! Lova Falk (talk) 08:24, 25 April 2025 (UTC)[reply]
I just mentioned two methods you can have such a list. Another method using another bot to retrofit an index is described at Help:Archiving a talk page#Archive indexing. Aaron Liu (talk) 11:20, 25 April 2025 (UTC)[reply]

Bias in reliable sources

[edit]

If some reliable source which has good editors. high standard reporting, good journalists, but show bias in some religious conflicts or political issues, then what can be done?

In political conflict they will allow spokesperson of one political party to write articles in their website and then will not listen to the other side.

In a country if politicians of one political party is arrested for murder they will cover it, but another politician from a different party is arrested for rape they will not cover it.

Community A kills community B they cover it. Community B kills community A, they don't cover it. They cant be accused of fake news.

Large scale violence and deaths in poor countries will get zero coverage while two three people stabbed in developed countries will get huge coverage. 2409:40E1:106D:DEAC:AC0C:C273:A383:8CA (talk) 03:34, 25 April 2025 (UTC)[reply]

French Wikipedia Modèle:Articles liés

[edit]

Hi there. Before making this request, I want to note that I attempted to replicate a good practice I found on the French Wikipedia. I have limited coding skills, and unfortunately, it did not work. On the French Wikipedia, they use hidden categories related to WikiProjects (or "Portails/Projets" in their case) to automatically create lists of all articles within the scope of that project/portal's main category, without the need for a bot. This list allows users to see changes related to the WikiProject's scope in one click.

For example, here on the French Wikiproject, they have a "Related Changes" page (called "Suivi") that uses this category type to populate the list. I find this tool extremely helpful, as it prevents one's watchlist from becoming cluttered. Please weigh in and let me know if we have something similar, and if we can adopt this tool. I am willing to help with whatever limited knowledge I have.el.ziade (talkallam) 13:38, 25 April 2025 (UTC)[reply]

Clarifying BLPCRIME - Input Welcome

[edit]

I've started a discussion proposing updates to the wording of WP:BLPCRIME to better reflect how editors apply it in practice. The current language, while well intentioned, has led to inconsistent interpretations, especially in borderline cases where a name is widely reported but the subject is not a public figure. You can view and join the discussion here: 

👉 Making BLPCRIME clearer and more consistent

The goal is to provide clearer guidance that acknowledges the nuanced spectrum of coverage and better supports editor judgment. Your input, especially from those experienced in BLP, dispute resolution, or policy drafting, would be greatly appreciated! Thanks Nemov (talk) 13:46, 25 April 2025 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)&oldid=1287324675"