This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
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.
Using AI to write your comments in a discussion makes it difficult for others to assume that you are discussing in good faith, rather than trying to use AI to argue someone into exhaustion (see example of someone using AI in their replies "Because I don't have time to argue with, in my humble opinion, stupid PHOQUING people"). More fundamentally, WP:AGF can't apply to the AI itself as AI lacks intentionality, and it is difficult for editors to assess how much of an AI-generated comment reflects the training of the AI vs. the actual thoughts of the editor.
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.
RfC: Amending ATD-R
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Much discussion preceded this RfC's filing. In 2018, consensus was found that "AfD is a right venue to seek for redirect(s), which have been challenged" (emphasis in original). In 2021, consensus was found that "Most users believe that AfD should be used to settle controversial or contested cases of blanking and redirecting". Then, in October 2024, a discussion was had at Wikipedia talk:Redirect about whether WP:ATD-R should mention WP:RFD specifically as an available venue. This gained some participation with ultimately no one gaining any ground. This then led to a discussion at Wikipedia talk:Deletion policy, with the same stalemate with the same editors continuing, which then led to this RfC. This issue has continually been discussed within this RfC by the same editors (with minimal new participants) as well.
WP:DISCARD explains that closers are "there to judge the consensus of the community, after discarding irrelevant arguments... [and] those based on personal opinion only" (emphasis mine). As previously mentioned, a lot of prior discussion involved WP:RFD's suitability in some context. However, the scope of this RfC does not relate to WP:RFD's suitability in any context. Nor did a plurality of participating editors in this RfC comment on it. This RfC asks whether or not, when a BLAR has been contested as outlined by WP:ATD-R, whether going to the deletion venue appropriate to the page's pre-direct content — as determined by existing guidance — is the preferred option to determine consensus, rather than it being held as an equal option to that of the talk page. The question of what, for an individual page, is the appropriate deletion venue is not in scope nor a topic a plurality of participating editors engaged in. As such, discussion outside of this scope, such as arguments made solely on the basis of the WP:RFD dispute, were discarded.
I have opted to interpret supports which indicate a preference for a deletion venue over the talk page, yet only mention a specific venue (e.g AfD), as ultimately being in support of the proposed wording. The spirit of such supports is that the appropriate deletion venue is preferable to the talk page. Otherwise, if such supporters were literal, that would mean they'd want files and templates, as two examples, to go to their singularly named deletion venue. Given the experience level of most all participants, I find this very unlikely.
In the support camp, most editors argued that AfD (and thus, a deletion venue) is far more likely to get eyes both from more editors in general and from editors which possess relevant knowledge of policy, such as WP:NOTABILITY. Because of this, they argue a more binding consensus is likely to develop, unlike for the talk page, which may have as little as 2 participants. In the oppose camp, there were 2 arguments shared by more than a single editor. The first is the axiomatic preference that XfD and talk pages be equally valid venues. The second is the preference for talk pages over the deletion venue, with an editor using WP:NOTBURO to justify it. These arguments do not weigh well and, in my view, are defeated by the aforementioned supports and their own rationale. A lot of the remaining oppose discussion revolved around material that I classified, as closer, as "irrelevant arguments".
As such, I find there is rough consensus to adjust the wording as currently proposed at time of close. This close does not comment on WP:RFD suitability for BLARs in any scenario, nor does it comment on what deletion venue is appropriate for what kind of page. Questions about those things will require separate consensus discussions to resolve. —Sirdog(talk) 07:13, 23 March 2025 (UTC)[reply]
The following has been added with Chetsford's consent (diff):
The lead closer suggested a collaborative close on this RfC. I have independently reviewed the discussion and arrived at an identical conclusion drawn from identical reasoning as the lead closer. I concur with the closing statement.Chetsford (talk) 06:56, 23 March 2025 (UTC)[reply]
A page can be [[Wikipedia:BLANKANDREDIRECT|blanked and redirected]] if there is a suitable page to redirect to, and if the resulting redirect is not [[Wikipedia:R#DELETE|inappropriate]]. If the change is disputedviaa [[Wikipedia:REVERT|reversion]], an attempt should be made to reach a [[Wikipedia:Consensus|consensus]] before blank-and-redirecting again. Suitablevenues for doing so include the article'stalkpageand[[Wikipedia:Articles for deletion]].
+
A page can be [[Wikipedia:BLANKANDREDIRECT|blanked and redirected]] if there is a suitable page to redirect to, and if the resulting redirect is not [[Wikipedia:R#DELETE|inappropriate]]. If the change is disputed, such as by [[Wikipedia:REVERT|reversion]], an attempt should be made to reach a [[Wikipedia:Consensus|consensus]] before blank-and-redirecting again. The preferred venue for doing so is the appropriate [[WP:XFD|deletion discussion venue]] for the pre-redirect content, although sometimes the dispute may be resolved on the page's talk page.
As proposer. This reflects existing consensus and current practice. Blanking of article content should be discussed at AfD, not another venue. If someone contests a BLAR, they're contesting the fact that article content was removed, not that a redirect exists. The venue matters because different sets of editors patrol AfD and RfD. voorts (talk/contributions) 01:54, 24 January 2025 (UTC)[reply]
Summoned by bot. I broadly support this clarification. However, I think it could be made even clearer that, in lieu of an AfD, if a consensus on the talkpage emerges that it should be merged to another article, that suffices and reverting a BLAR doesn't change that consensus without good reason. As written, I worry that the interpretation will be "if it's contested, it must go to AfD". I'd recommend the following: This may be done through either a merge discussion on the talkpage that results in a clear consensus to merge. Alternatively, or if a clear consensus on the talkpage does not form, the article should be submitted through Articles for Deletion for a broader consensus to emerge. That said, I'm not so miffed with the proposed wording to oppose it. -bɜ:ʳkənhɪmez | me | talk to me!02:35, 24 January 2025 (UTC)[reply]
I don't either, but I see the wording of although sometimes the dispute may be resolved on the article's talk page closer to "if the person who contested/reverted agrees on the talk page, you don't need an AfD" rather than "if a consensus on the talk page is that the revert was wrong, an AfD is not needed". The second is what I see general consensus as, not the first. -bɜ:ʳkənhɪmez | me | talk to me!02:53, 24 January 2025 (UTC)[reply]
I broadly support the idea, an AFD is going to get more eyes than an obscure talkpage, so I suspect it is the better venue in most cases. I'm also unsure how to work this nuance in to the prose, and not suspect the rare cases where another forum would be better, such a forum might emerge anyway. CMD (talk) 03:28, 24 January 2025 (UTC)[reply]
Support, although I don't see much difference between the status quo and the proposed wording. Basically, the two options, AfD or the talk page, are just switched around. It doesn't address the concerns that in some cases RfD is or is not a valid option. Perhaps it needs a solid "yes" or "no" on that issue? If RfD is an option, then that should be expressed in the wording. And since according to editors some of these do wind up at RfD when they shouldn't, then maybe that should be made clear here in this policy's wording, as well. Specifically addressing the RfD issue in the wording of this policy might actually lead to positive change. P.I. Ellsworth , ed.put'er there17:26, 24 January 2025 (UTC)[reply]
Support the change in wording to state the preference for AFD in the event of a conflict, because AFD is more likely to result in binding consensus than simply more talk. Robert McClenon (talk) 01:04, 25 January 2025 (UTC)[reply]
Support. AfD can handle redirects, merges, DABifies...the gamut. This kind of discussion should be happening out in the open, where editors versed in notability guidelines are looking for discussions, rather than between two opposed editors on an article talk page (where I doubt resolution will be easily found anyways). Toadspike[Talk]11:48, 26 January 2025 (UTC)[reply]
Support firstly, because by "blank and redirect" you're fundamentally saying that an article shouldn't exist at that title (presumably either because it's not notable, or it is notable but it's best covered at another location). WP:AFD is the best location to discuss this. Secondly, because this has been abused in the past. COVID-19 lab leak theory is one example; and when it finally reached AFD, there was a pretty strong consensus for an article to exist at that title, which settled a dispute that spanned months. There are several other examples; AFD has repeatedly proven to be the best settler of "blank and redirect" situations, and the best at avoiding the "low traffic talk page" issue. ProcrastinatingReader (talk) 18:52, 26 January 2025 (UTC)[reply]
Support, my concerns have been aired and I'm comfortable with using AfD as a primary venue for discussing any pages containing substantial article content. Utopes(talk / cont)22:30, 29 January 2025 (UTC)[reply]
Support - So as I see it, the changes proposed are simply to say that disputes should be handled at AfD in preference over the talk page, which I agree with, and also to acknowledge that a dispute over a BLAR could consist of something other than a reversion, which it can. Sounds like a good wording adjustment to me, and it matches what I understand to be already existing wikipedian practice anyway. I agree that it may be a good idea to expressly state in policy that a BLAR should not be deleted at RfD, ever... a BLAR could be retargetted at RfD, but if a BLAR is proposed for deletion it needs to go to AfD instead... but that's not at issue in this proposal, so it's off topic for now. Fieari (talk) 06:13, 13 February 2025 (UTC)[reply]
Support. I've made use of ATD-R, but it did occur to me that it is something of a back door option. If a redirect is reverted, that means we have a controversial article which must be brought before wider scrutiny. You can't achieve that on the article talk page, unless the redirect supporter concedes the point, and so it must go to AFD. Having said that, I see no reason to amend the words "via a reversion". Spartathenian (talk) 14:02, 13 March 2025 (UTC)[reply]
It's necessary because not everyone may have the ability or desire to use reversion to challenge the deletion. For example someone who lacks sufficient permission to edit the page may still wish to dispute a redirection. Or perhaps they don't want to get into edit wars and would rather leave the task of reverting to the status quo to someone else. The key point is that the action is disputed, not how the dispute manifested itself. — Amakuru (talk) 12:03, 21 March 2025 (UTC)[reply]
Support - although talk page discussions are useful for most processes, I think those which affect the fundamental existence or otherwise of the page should go to a formal venue if there is a dispute. The big advantage of XfD is that it has a large number of eyes on it and is frequented by people with lots of experience in notability and deletion policy; whereas a talk page probably has a much smaller number of watchers, some of whom may have particular alignments or points of view. Blank-and-redirect may not meet the technical definition of deletion, but it amounts to the same thing. A similar system applies for requested moves too - if a bold move is reverted per WP:RMUM then the next step it to start a formal WP:RM discussion, not for informal discussions on the talk page. — Amakuru (talk) 12:00, 21 March 2025 (UTC)[reply]
The section in question is about pages, not articles. If the proposed wording is adapted, it would be suggesting that WP:BLAR'd templates go to AfD. As I explained in the previous discussion, that's part of the reason why the proposed wording is problematic and that it was premature for an RfC on the matter. --Tavix(talk)17:35, 24 January 2025 (UTC)[reply]
considering the above discussion, my vote hasn't really changed. this does feel incomplete, what with files and templates existing and all that, so that still feels undercooked (and now actively article-centric), hence my suggestion of either naming multiple venues or not naming any consarn(speak evil)(see evil)23:28, 24 January 2025 (UTC)[reply]
Agree. I'm beginning to understand those editors who said it was too soon for an RfC on these issues. While I've given this minuscule change my support (and still do), this very short paragraph could definitely be improved with a broader guidance for up and coming generations. P.I. Ellsworth , ed.put'er there23:38, 24 January 2025 (UTC)[reply]
If you re-read the RFCBEFORE discussions, the dispute was over what to do with articles that have been BLARed. That's why this was written that way. I think it's obvious that when there's a dispute over a BLARed article, it should go to AfD, not RfD. I proposed this change because apparently some people don't think that's so obvious. Nobody has or is disputing that BLARed templates should go to TfD, files to FfD, or miscellany to MfD. And none of that needs to be spelled out here per WP:CREEP. voorts (talk/contributions) 00:17, 25 January 2025 (UTC)[reply]
If you want to be fully inclusive, it could say something like "the appropriate deletion venue for the pre-redirect content" or "...the blanked content" or some such. I personally don't think that's necessary, but don't object if others disagree on that score. (To be explicit neither the change that was made, nor a change to along the lines of my first sentence, change my support). Thryduulf (talk) 00:26, 25 January 2025 (UTC)[reply]
Exactly. And my support hasn't changed as well. Goodness, I'm not saying this needs pages and pages of instruction, nor even sentence after sentence. I think us old(er) farts sometimes need to remember that less experienced editors don't necessarily know what we know. I think you've nailed the solution, Thryduulf! The only thing I would add is something short and specific about how RfD is seldom an appropriate venue and why. P.I. Ellsworth , ed.put'er there00:35, 25 January 2025 (UTC)[reply]
I'm going to back down a bit with an emphasis on the word "preferred". I agree that AfD is the preferred venue, but my main concern is if a redirect gets nominated for deletion at RfD and editors make purely jurisdictional arguments that it should go to AfD because there's article content in its history even though it's blatantly obvious the article content should be deleted. --Tavix(talk)01:22, 25 January 2025 (UTC)[reply]
this is a big part of why incident 91724 could become a case study. "has history, needs afd" took priority over the fact that the history had nothing worth keeping, the redirect had been stable as a blar for years, and the ages of the folks at rfd (specifically the admins closing or relisting discussions on blars) having zero issue with blars being nominated and discussed there (with a lot of similar blars nominated around the same time as that one being closed with relatively litte fuss, and blars nominated later being closed with no fuss), and at least three other details i'm missing
as i said before, if a page was blanked relatively recently and someone can argue for there being something worth keeping in it, its own xfd is fine and dandy, but otherwise, it's better to just take it to rfd and leave the headache for them. despite what this may imply, they're no less capable of evaluating article content, be it stashed away in the edit history or proudly displayed in any given redirect's target consarn(speak evil)(see evil)10:30, 25 January 2025 (UTC)[reply]
As I've explained time and time again it's primarily not about the capabilities of editors at RfD it's about discoverability. When article content is discussed at AfD there are multiple systems in place that mean everybody interested or potentially interested knows that article content is being discussed, the same is not true when article content is discussed at RfD. Time since the BLAR is completely irrelevant. Thryduulf (talk) 10:39, 25 January 2025 (UTC)[reply]
if you want to argue that watchlists, talk page notifs, and people's xfd logs aren't enough, that's fine by me, but i at best support also having delsort categories for rfd (though there might be some issues when bundling multiple redirects together, though that's nothing twinkle or massxfd can't fix), and at worst disagree because, respectfully, i don't have much evidence or hope of quake 2's biggest fans knowing what a strogg is. maybe quake 4, but its list of strogg was deleted with no issue (not even a relisting). see also quackifier, just under that discussion consarn(speak evil)(see evil)11:03, 25 January 2025 (UTC)[reply]
I would think that as well, but unfortunately that's not reality far too often. I can see this new wording being more ammo for process wonkery. --Tavix(talk)02:49, 25 January 2025 (UTC)[reply]
Unless a note about RfD being appropriate in any cases makes it clear that it strictly limited to (a) when the content would be speedily deleted if restored, or (b) there has been explicit consensus the content should not be an article (or template or whatever), then it would move me into a strong oppose. This is not "process wonkery" but the fundamental spirit of the entire deletion process. Thryduulf (talk) 03:35, 25 January 2025 (UTC)[reply]
See what I mean this attitude is exactly why we are here. I've spent literal years explaining why I hold the position I do, and how it aligns with the letter and spirit of pretty much every relevant policy and guideline. It shouldn't even be controversial for blatantly obvious the article content should be deleted to mean "would be speedily deleteable if restored", yet on this again a single digit number of editors have spent years arguing that they know better. Thryduulf (talk) 03:56, 25 January 2025 (UTC)[reply]
both sides are on single digits at the time of writing this, we just need 3 more supports to make it 10 lol
ultimately, this has its own caveat(s). namely, with the csd not covering every possible scenario. regardless of whether or not it's intentional, it's not hard to look at something and go "this ain't it, chief". following this "process" to the letter would just add more steps to that, by restoring anything that doesn't explicitly fit a csd and dictating that it has to go to afd so it can get the boot there for the exact same reason consarn(speak evil)(see evil)10:51, 25 January 2025 (UTC)[reply]
oppose, though with the note that i support a different flavor of change. on top of the status quo issue pointed out by tavix (which i think we might need to set a period of time for, like a month or something), there's also the issue of the article content in question. if it's just unsourced, promotional, in-universe, and/or any other kind of fluff or cruft or whatever else, i see no need to worry about the content, as it's not worth keeping anyway (really, it might be better to just create a new article from scratch). if a blar, which has been stable as a redirect, did have sources, and those sources were considered reliable, then i believe restoring and sending to afd would be a viable option (see purple francis for an example). outside of that, i think if the blar is reverted early enough, afd would be the better option, but if not, then it'd be rfd for this reason, i'd rather have multiple venues named ("Suitable venues include Articles for Deletion, Redirects for Discussion, and Templates for Discussion"), no specific venue at all ("The dispute should be resolved in a fitting discussion venue"), or conditions for each venue (for which i won't suggest a wording because of the aforementioned status quo time issue) consarn(speak evil)(see evil)17:50, 24 January 2025 (UTC)[reply]
Oppose. The proper initial venue for discussing this should be the talk page; only if agreement can't be reached informally there should it proceed to AfD. Espresso Addict (talk) 16:14, 27 January 2025 (UTC)[reply]
Oppose as written to capture some nuances; there may be a situation where you want a BLAR to remain a redirect, but would rather retarget it. I can't imagine the solution there is to reverse the BLAR and discuss the different redirect-location at AfD. Besides that, I think the intention is otherwise solid, as long as its consistent in practice. Moving forward it would likely lead to many old reversions of 15+ year BLAR'd content, but perhaps that's the intention; maybe only reverse the BLAR if you're seeking deletion of the page, at which point AfD becomes preferable? Article deletion to be left to AfD at that point? Utopes(talk / cont) 20:55, 27 January 2025 (UTC), moving to support, my concerns have been resolved and I'm happy to use AfD as a primary venue for discussing article content. Utopes(talk / cont)22:29, 29 January 2025 (UTC)[reply]
Oppose - the first part of the new wording makes it more vague than before. "If the change is disputed via a reversion" was clear. "If the change is disputed, such as by reversion" is vague. What other ways of dispute other than reversion are there? I am assuming "reversion" here implies reversion to pre-redirect content. If the intent of the change in wording to is incorporate scenarios where an editor prefers a redirect target of "Article B" instead of "Article A", or a dab page, or sees no appropriate target, where it is not a reversion, but a bold edit or an RfD nomination, then the accompanying phrase "before blank-and-redirecting again." does not make sense.
I oppose the second part of the new wording as well. The current wording gave editors an equal choice of forum - talk page vs XfD. Why should XfD be the preferred venue, and the talkpage be the forum only "sometimes". I see what Berchanhimez says. If an editor wants to revert and add a {{mergeto}} as a better alternative to BLAR, and all parties are agreeable to in the talk page, why force them to go to XfD. Although, I won't go as far as Espresso Addict in saying the talk page "should" be the proper initial venue, the current wording of giving equal choice of venu goes better with me, than forcing a preference. If editors do not agree on a talk page, it is understood one of them, or a neutral party will take to AfD/XfD.
I support the third part of the change, courtesy Thryduulf, of "appropriate deletion discussion venue for the pre-redirect content" which resolves Tavix's concern of AfD/TfD/MfD.
Note that I haven't touched upon RfD at all, or the prior heated discussions around it, because I don't see the current or new wordings addressing anything about Rfd. It would require a separate RfC to resolve the RfD concerns.
The first part was intended to make clear that if someone doesn't revert, but nonetheless contests the BLAR, they should still bring it to the appropriate non-RfD XfD. The second part doesn't limit anyone from going to talk to discuss things first. It merely makes clear that if something can't be resolved, it should go to the appropriate XfD. voorts (talk/contributions) 19:02, 28 February 2025 (UTC)[reply]
How can a nomination can be made at the appropriate (non-RfD) XfD without first reverting to the pre-redirect content? To repeat my question from the earlier comment - what other ways of dispute other than reversion are there? One way to contest the BLAR is to go to RfD to state that turning the article to a redirect was not an acceptable ATD, and that the page should be completely deleted. Someone could overwrite the page with new article content, or non-article content (disambiguation, SIA, for example), but that wouldn't be seen as contesting the BLAR, more like overwriting the BLAR.
For the second part, why will editors use the talk page, if policy sets the preference to XfD? Why do you want XfD to become more preferable over the article talk page discussion? What is the basis for that? Jay 💬13:36, 14 March 2025 (UTC)[reply]
Oppose in strongest possible terms. XFD is a process-heavy, red-tape-filled procedure that is used solely for two reasons; first, because deletion is impossible for regular editors to implement or reverse; and second, because the WMF requires that we have a way to remove things from where ordinary editors can see them. A blank-and-redirect meets neither of these criteria - it is inappropriate to send it to XFD. I would in fact support language specifically discouraging taking such disputes to AFD, where they waste time and energy and involve far more bloated red tape than such discussions ought to have, while also creating a bias towards retaining newly-added disputed material that goes against WP:BRD, WP:BURDEN, and WP:ONUS. Making it possible to send a redirect to AFD implies that an editor can add something on which there is no consensus, then respond to any attempts to remove it by demanding a hearing at AFD, leading to it being retained if discussions there fail to reach a consensus; this is inappropriate and against our other practices and policies, which normally result in new additions that fail to obtain a consensus getting removed. If anything we should therefore prohibit sending redirects to AFD in situations where an actual deletion is not being requested, or make it clear that if the article is newly-created and was redirected prior to being sent to AFD, an AFD outcome of no consensus leads to it remaining a redirect, such that editors cannot abuse AFD to turn WP:BURDEN on its head like this. --Aquillion (talk) 12:19, 13 March 2025 (UTC)[reply]
I know it's not really in the scope of this discussion but to be perfectly honest, I'm not sure why BLAR is a still a thing. It's a cliche, but it's a hidden mechanism for backdoor deletion that often causes arguments and edit wars. I think AfDs and talk-page merge proposals where consensus-building exists produce much better results. It makes sense for duplicate articles, but that is covered by A10's redirection clause. J947 ‡ edits03:23, 25 January 2025 (UTC)[reply]
BLARs are perfectly fine when uncontroversial, duplicate articles are one example but bold merges are another (which A10 doesn't cover). Thryduulf (talk) 03:29, 25 January 2025 (UTC)[reply]
I didn't say, or intend to imply, that every BLAR is related to a merge. The best ones are generally where the target article covers the topic explicitly, either because content is merged, written or already exists. The worst ones are where the target is of little to no (obvious) relevance, contains no (obviously) relevant content and none is added. Obviously there are also ones that lie between the extremes. Any can be controversial, any can be uncontroversial. Thryduulf (talk) 18:20, 25 January 2025 (UTC)[reply]
I'm happy to align to whatever consensus decides, but I'd like to discuss the implications because that aspect is not too clear to me. Does this mean that any time an redirect contains any history and deletion is sought, it should be restored and go to AfD? Currently there's some far-future redirects with ancient history, how would this amendment affect such titles? Utopes(talk / cont)09:00, 29 January 2025 (UTC)[reply]
see why i wanted that left to editor discretion (status quo, evaluation, chance of an rm or histmerge, etc.)? i trust in editors who aren't that wonk from rfd (cogsan? cornsam?) to see a pile of unsourced cruft tucked away in the history and go "i don't think this would get any keep votes in afd" consarn(speak evil)(see evil)11:07, 29 January 2025 (UTC)[reply]
then it might depend. is its status as a blar the part that is being contested? if the title is being contested (hopefully assuming the pre-blar content is fine), would "move" be a fitting outcome outside of rm? is it being contested solely over meta-procedural stuff, as opposed to actually supporting or opposing its content? why are boots shaped like italy? was it stable as a redirect at the time of contest or not? does this account for its status as a blar being contested in an xfd venue (be it for restoring or blanking again)? it's a lot of questions i feel the current wording doesn't answer, when it very likely should. granted, what i suggested isn't much better, but shh
going back to that one rfd i keep begrudgingly bringing up (i kinda hate it, but it's genuinely really useful), if this wording is interpreted literally, the blar was contested a few years prior and should thus be restored, regardless of the rationales being less than serviceable ("i worked hard on this" one time and... no reason the other), the pre-blar content being complete fancruft, and no one actually supporting the content in rfd consarn(speak evil)(see evil)13:54, 29 January 2025 (UTC)[reply]
Well that case you keep citing worked out as a NOTBURO situation, which this clraification would not override. There are obviously edge cases that not every policy is going to capture. IAR is a catch-all exception to every single policy on Wikipedia. The reason we have so much scope creep in PAGs is becaude editors insist on every exception being enumerated. voorts (talk/contributions) 14:51, 29 January 2025 (UTC)[reply]
if an outcome (blar status is disputed in rfd, is closed as delete anyway) is common enough, i feel the situation goes from "iar good" to "rules not good", at which point i'd rather have the rules adapt. among other things, this is why i want a slightly more concrete time frame to establish a status quo (while i did suggest a month, that could also be too short), so that blars that aren't blatantly worth or not worth restoring after said time frame (for xfd or otherwise) won't be as much of a headache to deal with. of course, in cases where their usefulness or lack thereof isn't blatant, then i believe a discussion in its talk page or an xfd venue that isn't rfd would be the best option consarn(speak evil)(see evil)17:05, 29 January 2025 (UTC)[reply]
I think the idea that that redirect you mentioned had to go to AfD was incorrect. The issue was whether the redirect was appropriate, not whether the old article content should be kept. voorts (talk/contributions) 17:41, 29 January 2025 (UTC)[reply]
Alright. @Voorts: in that case I think I agree. I.e., if somebody BLAR's a page, the best avenue to discuss merits of inclusion on Wikipedia, would be at a place like AfD, where it is treated as the article it used to be, as the right eyes for content-deletion will be present at AfD. To that end, this clarification is likely a good change to highlight this fact. I think where I might be struggling is the definition of "contesting a BLAR" and what that might look like in practice. To me, "deleting a long-BLAR'd redirect" is basically the same as "contesting the BLAR", I think?
An example I'll go ahead and grab is 1900 Lincoln Blue Tigers football team from cat:raw. This is not a great redirect pointed at Lincoln Blue Tigers from my POV, and I'd like to see it resolved at some venue, if not resolved boldly. This page was BLAR'd in 2024, and I'll go ahead and notify Curb Safe Charmer who BLAR'd it. I think I'm inclined to undo the BLAR, not because I think the 1900 season is particularly notable, but because redirecting the 1900 season to the page about the Lincoln Blue Tigers doesn't really do much for the people who want to read about the 1900 season specifically. (Any other day I would do this boldly, but I want to seek clarification).
But let's say this page was BLAR'd in 2004, as a longstanding redirect for 20 years. I think it's fair to say that as a redirect, this should be deleted. But this page has history as an article. So unless my interpretation is off, wouldn't the act of deleting a historied redirect that was long ago BLAR'd, be equivalent to contesting the BLAR, that turned the page into a redirect in the first place, regardless of the year? Utopes(talk / cont)20:27, 29 January 2025 (UTC)[reply]
I don't think so. In 2025, you're contesting that it's a good redirect from 2004, not contesting the removal of article content. If somebody actually thought the article should exist, that's one thing, but procedural objections based on RfD being an improper forum without actually thinking the subject needs an article is the kind of insistence on needless bureaucracy that NOTBURO is designed to address. voorts (talk/contributions) 20:59, 29 January 2025 (UTC)[reply]
I see, thank you. WP:NOTBURO is absolutely vital to keep the cogs rolling, lol. Very oftentimes at RfD, there will be a "page with history" that holds up the process, all for the discussion to close with "restore and take to AfD". Cutting out the middle, and just restoring article content without bothering with an RfD to say "restore and take to AfD" would make the process and all workflows lot smoother. @Voorts:, from your own point of view, I'm very interested in doing something about 1900 Lincoln Blue Tigers football team, specifically, to remove a redirect from being at this title (I have no opinion as to whether or not an article should exist here instead). Because I want to remove this redirect; do you think I should take it to RfD as the correct venue to get rid of it? (Personally speaking, I think undoing the BLAR is a lot more simple and painless especially so as I don't have a strong opinion on article removal, but if I absolutely didn't want an article here, would RfD still be the venue?) Utopes(talk / cont)21:10, 29 January 2025 (UTC)[reply]
Alright. I think we're getting somewhere. I feel like some editors may consider it problematic to delete a recently BLAR'd article at RfD under any circumstance. Like if Person A BLAR's a brand new article, and Person B takes it to RfD because they disagree with the existence of a redirect at the title and it gets deleted, then this could be considered a "bypassal of the AfD process". Whether or not it is or isn't, people have cited NOTBURO for deleting it. I was under the impression this proposal was trying to eliminate this outcome, i.e. to make sure that all pages with articles in its history should be discussed at AfD under its merits as an article instead of anywhere else. I've nommed redirects where people have said "take to AfD", and I've nommed articles where people have said "take to RfD". I've never had an AfD close as "wrong venue", but I've seen countless RfDs close in this way for any amount of history, regardless of the validity of there being a full-blown article at this title, only to be restored and unanimously deleted at AfD. I have a feeling 1900 Lincoln Blue Tigers football team would close in the same way, which is why I ask as it seems to be restoring the article would just cut a lot of tape if the page is going to end up at AfD eventually. Utopes(talk / cont)21:36, 29 January 2025 (UTC)[reply]
I think the paragraph under discussion here doesn't really speak to what should happen in the kind of scenario you're describing. The paragraph talks about "the change" (i.e., the blanking and redirecting) being "disputed", not about what happens when someone thinks a redirect ought not to exist. I agree with you that that's needless formalism/bureaucracy, but I think that changing the appropriate venue for those kinds of redirects would need a separate discussion. voorts (talk/contributions) 21:42, 29 January 2025 (UTC)[reply]
Fair enough, yeah. I'm just looking at the definition of "disputing/contesting a BLAR". For this situation, I think it could be reasoned that I am "disputing" the "conversion of this article into a redirect". Now, I don't really have a strong opinion on whether or not an article should or shouldn't exist, but because I don't think a redirect should be at this title in either situation, I feel like "dispute" of the edit might still be accurate? Even if it's not for a regular reason that most BLARs get disputed 😅. I just don't think BLAR'ing into a page where a particular season is not discussed is a great change. That's what I meant about "saying a redirect ought not to exist" might be equivalent to "disputing/disagreeing with the edit that turned this into a redirect to begin with". And if those things are equivalent, then would that make AfD the right location to discuss the history of this page as an article? That was where I was coming from; hopefully that makes sense lol. If it needs a separate discussion I can totally understand that as well. Utopes(talk / cont)21:57, 29 January 2025 (UTC)[reply]
In the 1900 Blue Tigers case and others like it where you think that it should not be a redirect but have no opinion about the existence or otherwise of an article then simply restore the article. Making sure it's tagged for any relevant WikiProjects is a bonus but not essential. If someone disputes your action then a talk page discussion or AfD is the correct course of action for them to take. If they think the title should be a red link then AfD is the only correct venue. Thryduulf (talk) 22:08, 29 January 2025 (UTC)[reply]
Alright, thank you Thryduulf. That was kind of the vibe I was leaning towards as well, as AfD would be able to determine the merits the page's existence as a subject matter. This all comes together because not too long ago I was criticized for restoring a page that contained an article in its history. In this discussion for Wikipedia:Articles for deletion/List of cultural icons of Canada, I received the following message regarding my BLAR-reversal: For the record, it's really quite silly and unnecessary to revert an ancient redirect from 2011 back into a bad article that existed for all of a day before being redirected, just so that you can force it through an AFD discussion — we also have the RFD process for unnecessary redirects, so why wasn't this just taken there instead of being "restored" into an article that the restorer wants immediately deleted? I feel like this is partially comparable to 1900 Lincoln Blue Tigers football team, as both of these existed for approx a day before the BLAR, but if restoring a 2024 article is necessary per Thryduulf, but restoring a 2011 article is silly per Bearcat, I'm glad that this has the potential to be ironed out via this RfC, possibly. Utopes(talk / cont)22:18, 29 January 2025 (UTC)[reply]
There are exactly two situations where an AfD is not required to delete article content:
The content meets one or more criteria for speedy deletion
Understood. I'll keep that in mind for my future editing, and I'll move from the oppose to the support section of this RfC. Thank you for confirmation regarding these situations! Cheers, Utopes(talk / cont)22:28, 29 January 2025 (UTC)[reply]
@Utopes: Note that is simply Thryduulf's opinion and is not supported by policy (despite his vague waves to the contrary). Any redirect that has consensus to delete at RfD can be deleted. I see that you supported deletion of the redirect at Wikipedia:Redirects for discussion/Log/2024 September 17#List of Strogg in Quake II. Are you now saying that should have procedurally gone to AfD even though it was blatantly obvious that the article content is not suitable for Wikipedia? --Tavix(talk)22:36, 29 January 2025 (UTC)[reply]
I'm saying that AfD probably would have been the right location to discuss it at. Of course NOTBURO applies and it would've been deleted regardless, really, but if someone could go back in time, bringing that page to AfD instead of RfD seems like it would have been more of an ideal outcome. I would've !voted delete on either venue. Utopes(talk / cont)22:39, 29 January 2025 (UTC)[reply]
@Utopes: Note that Tavix's comments are, despite their assertions to the contrary, only their opinion. It is notable that not once in the literal years of discussions, including this one, have they managed to show any policy that backs up this opinion. Content that is blatantly unsuitable for Wikipedia can be speedily deleted, everything that can't be is not blatantly unsuitable. Thryduulf (talk) 22:52, 29 January 2025 (UTC)[reply]
Here you go. Speedy deletion is a process that provides administrators with broad consensus to bypass deletion discussion, at their discretion. RfD is a deletion discussion venue for redirects, so it doesn't require speedy deletion for something that is a redirect to be deleted via RfD. Utopes recognizes there is a difference between "all redirects that have non-speediable article content must be restored and discussed at AfD" and "AfD is the preferred venue for pages with article content", so I'm satisfied to their response to my inquiry. --Tavix(talk)23:22, 29 January 2025 (UTC)[reply]
Quoting yourself in a discussion about policy doe not show that your opinion is consistent with policy. Taking multiple different bits of policy and multiple separate facts, putting them all in a pot and claiming the result shows your opinion is supported by policy didn't do that in the discussion you quoted and doesn't do so now. You have correctly quoted what CSD is and what RfD is, but what you haven't done is acknowledged that when a BLARed article is nominated for deletion it is article content that will be deleted, and that article content nominated for deletion is discussed at AfD not RfD. Thryduulf (talk) 02:40, 30 January 2025 (UTC)[reply]
I requested closure at WP:CR, but that was a week ago. Fortunately, I changed the "do not archive" date to two more weeks before the bot does something. Is one closer sufficient? If so, why hasn't the closure been done yet? George Ho (talk) 02:02, 28 February 2025 (UTC)[reply]
Well, we'll agree to disagree then. From what I learned so far, having two or more closers is more efficient and quicker than waiting for just one who usually understands the policies very lot. Usually, a two-person closure is (unofficially) reserved mostly for more complex cases. Nonetheless, I think it would resolve backlogs. But your wishes and decision then. George Ho (talk) 02:42, 28 February 2025 (UTC)[reply]
I close a lot of discussions. It is much faster to read a discussion and write a close than it is to work on a close, send it to another person for additions/edits, wait for them to send it back, ad nauseam. voorts (talk/contributions) 02:53, 28 February 2025 (UTC)[reply]
For example, this discussion would probably take me about half an hour to an hour to read, then write a close I'm happy with. If I then had to have a back-and-forth with another editor until we were both happy with the close, things would take much longer. voorts (talk/contributions) 02:54, 28 February 2025 (UTC)[reply]
Or, if we decided to write it together over google docs or something simultaneously, we'd both have to first read the discussion, schedule a time to chat or post messages back and forth on wiki to determine that we're on the same page (and if we're not, then neither of us should probably close it), and then actually write the close. voorts (talk/contributions) 02:56, 28 February 2025 (UTC)[reply]
the result is going to make some (i.e., a lot of) people very unhappy.
The idea with having multiple closers is that the larger number will silence some complaints (sure, you didn't get what you wanted, but multiple admins said you lost, so complaining's probably a waste of time) and spread out some of the others (each unhappy person yells at a different closer, instead of everyone yelling at a single person).
If you are not expecting drama, you don't need multiple closers. In fact, if the answer is completely obvious, and even the people who are "losing" agree that the consensus is against them, then you don't need any uninvolved closers. WhatamIdoing (talk) 06:07, 28 February 2025 (UTC)[reply]
we're at 11 supports, meaning my throwaway joke about waiting to close until there were 10 has been fulfilled. though i still disagree with how that's written, that's really the one worry i had about closing the discussion consarn(prison phone)(crime record)10:52, 28 February 2025 (UTC)[reply]
I take issue with the fundamental position some people are taking, above, that BLAR is some sort of loophole around the AFD process. It's the AFD process that is unusual - our normal way of handling disputed additions is covered by WP:BRD, WP:ONUS and WP:BURDEN. That is to say that if someone creates a new article, and I immediately BLAR it, the default if there is no consensus ought to be that remains a redirect. They boldly added new material, I removed it, now they must demonstrate consensus for it before restoring it. AFD inverts this for complicated reasons that are hard to change; but the idea that even edits that don't require actual AFDs ought to be required to go through that simply to... cause that inversion is absurd. If anything, I would take the opposite tack and forbid BLAR disputes from being sent to AFD. It's a normal content dispute, and should be handled in the normal way - which includes, crucially, the presumption that if there's no consensus for a recently-created article, it must remain a redirect. It's the person who attempts to send it to AFD who is abusing process to force through new material without consensus in violation of WP:ONUS / WP:BURDEN, not the person who objected and redirected it. --Aquillion (talk) 12:25, 13 March 2025 (UTC)[reply]
By your logic, as an admin, I should be able to unilaterally delete a new page per ONUS/BURDEN even if it meets none of the CSD criteria and then insist that the editor who created the article satisfy me that it should be undeleted. voorts (talk/contributions) 13:25, 13 March 2025 (UTC)[reply]
Also, what evidence do you have that XFD favors keeping pages. It's been my experience that redirects are often retained at AfD on contested BLARs, but both of our experiences are anecdotal and this is a factual question. voorts (talk/contributions) 13:32, 13 March 2025 (UTC)[reply]
admittedly, i think an editor who blars something should have the burden of explanation as well, and the policy could try to cram that in somewhere. granted, it's a burden they can fulfill in edit summaries, talk pages, or, and hear me out because this is something that has never ever been said before ever by anyone ever[citation needed], rfd, so it's not a hard criterion to fill if it's done in good faith. then again, if an edit war happens over it, i do think a page should be restored to its pre-war diff (which might even not be a redirect), but that's probably besides the point since other policies have that covered consarn(prison phone)(crime record)13:39, 13 March 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.
RFC: Allow for bots (e.g. Citation bot) to remove redundant URLs known to not host a full freely-accessible version.
The reason is that those links will never contain free versions of articles, they will link to either the PubMed database, which only contain abstracts (free versions would be hosted at PubMed Central instead), or the OCLC database, which formerly held google book previews (then deemed useful), but no longer does.
This means that these urls make it look like a free version is accessible, when really none are, making readers click through links that lead them to nowhere useful. Note that this isn't a proposal to removal any URL covered by an identifier (e.g. |url=https://www.jstor.org/stable/123456 → |jstor=123456) that may or may not be free, only these two, known to never host free versions.
Support as proposer. These link are reader-hostile. They also discourage the addition of free links because it makes it look like there already are such links. Headbomb {t · c · p · b}09:25, 17 February 2025 (UTC)[reply]
I have no particular assessment of PubMed, but I would oppose this for OCLC because a lot of citations to OCLC for articles on books aren't citing the work attached to the OCLC, but the bibliographic data in OCLC itself. Links to it when that is not the case should be removed, but the bot cannot tell those apart. PARAKANYAA (talk) 09:41, 17 February 2025 (UTC)[reply]
Then that would be a {{cite web}} with an OCLC url, not a {{cite book}} with a url pointing to OCLC. The RFC concerns the latter, not the former. E.g., the bot would cleanup
Carlisle, Rodney P.; Golson, J. Geoffrey (2007). Manifest destiny and the expansion of America. Turning Points in History Series. Santa Barbara, Calif.: ABC-CLIO. p. 238. ISBN978-1-85109-834-7. OCLC659807062.
Assuming that Headbomb's description of the situation is accurate (it does fit with my knowledge of PubMed and OCLC, but my knowledge esp. of the latter is limited), I support this proposal. Toadspike[Talk]13:31, 17 February 2025 (UTC)[reply]
Support per WP:SURPRISE. When we link to a title, readers expect to find the linked reference at the link. No information will be lost because the discussed cases always involve an id containing the same link. —David Eppstein (talk) 19:46, 17 February 2025 (UTC)[reply]
Henderson, Jillian T.; Webber, Elizabeth M.; Weyrich, Meghan S.; Miller, Marykate; Melnikow, Joy (2024-06-11). "Screening for Breast Cancer: Evidence Report and Systematic Review for the US Preventive Services Task Force". JAMA. 331 (22): 1931–1946. doi:10.1001/jama.2023.25844. ISSN1538-3598. PMID38687490.
then I'd actually prefer having a link on the title take me to the abstract on PubMed (or at least not object to it). Those of us who are familiar with the literature and our citation conventions know that this is a "duplicate" or "redundant" link, but ordinary people don't know what all those acronyms mean. They expect that clicking the link on the title will take them to some useful place, so it should do that. WhatamIdoing (talk) 21:10, 19 February 2025 (UTC)[reply]
Hi, I was recommended to post this at the village pump by a a comment here.
There has been a recent issue where dozens of PRODs and AfDs (about 80 of them last month) of pre-Internet-era track and field Olympians were all created in a short timespan. For comparison, the usual rate that these get created is one or two per week. The rate is of particular importance here because unlike most processes on Wikipedia, there is a one-week deadline for most PRODs and AfDs, so when many are created all at once it can be difficult to properly address them in time.
While it's true that some of these articles were created by User:Lugnuts without SIGCOV references, it's also true that significant coverage exists for most of them -- to quote User:WhatamIdoing at the above linked thread, At some level, we all know that there is local coverage on every modern Olympic athlete, because (a) local newspapers always run the 'local kid does well internationally' kinds of stories, because articles that combine national pride, local people, and good news sell well, and (b) every time someone has actually done the work of getting access to paper copies, they've found these sources.
Because finding pre-Internet newspaper sources for non-English speaking countries can be labor intensive, is there a policy solution to the above problem? --Habst (talk) 20:45, 2 March 2025 (UTC)[reply]
I don't think this is something we can solve with more rules.
Making 109 PRODs in one hour is just silly, and there's no amount of regulation that will stop people from doing silly things. I do understand this kind of rate is frustrating, but I think creating and enforcing rules about the rate of nominations will create unforseen problems. You can't stop people from being silly, but you can trout them after the fact. Cremastra (talk) 21:56, 2 March 2025 (UTC)[reply]
109 PRODs in one hour sounds like a WP:MEATBOT issue. There is no way you can evaluate that many articles in that amount of time, so the first step would be to deprod with the summary that no WP:BEFORE was done and the article needs a full evaluation. Thryduulf (talk) 23:36, 2 March 2025 (UTC)[reply]
Note it's possible, if unlikely, that the tagger spent significant time researching the 109 articles individually before tagging them all at once. A single rapid tagging session does not by itself indicate WP:MEATBOT. Anomie⚔13:23, 3 March 2025 (UTC)[reply]
For small groups of closely related articles that is possible, but it's not at all plausible that you'd research that many before nominating them - you'd tag them as you go. Especially if you are not doing a group nomination. Thryduulf (talk) 14:34, 3 March 2025 (UTC)[reply]
This is mostly something that can be dealt with informally through current P&G (disruptive editing applies to all sorts of things). For larger deletion projects, it would be preferable to either bundle them or start a community discussion, depending on the nature of the articles. With that said, note that per WP:NSPORTS2022 Proposal 5 there's already consensus to delete any sports bios that do not currently have significant coverage in the article, overriding WP:NEXIST and WP:BEFORE. These deletions aren't indefinite, they're just until someone gets around to finding significant coverage. I'd also ask about whether local coverage is "significant" as opposed to routine; if all athletes have local coverage regardless of notability, it's unlikely to be significant. Thebiguglyalien (talk) 🛸00:23, 3 March 2025 (UTC)[reply]
I have a relevant discussion open at WT:NOT about the definition of 'routine'. We're just getting started, so things may change, but from early comments, it appears that 'routine' is frequently understood to have no particular relationship to 'significant coverage'. SIGCOV is how many (encyclopedically useful) words/facts were written. 'Routine' is that if every ____ automatically gets (e.g.,) one article printed about it the next morning, then that is the routine. ("____" is a relevant large category, like "film" or "sports game" or "election", not a small category like "films starring Joe Film" or "FIFA World Cup finals").
With these two models, it is possible for routine coverage to provide SIGCOV. And if you agree or disagree with that, then I invite you to join that discussion and tell us so. WhatamIdoing (talk) 00:39, 3 March 2025 (UTC)[reply]
Absolutely not, not unless a similar rate limit is applied to article creation. At the moment an editor can mass-create a ton of articles very rapidly; to avoid a WP:FAIT situation, it is obviously necessary for another editor to be able to challenge those articles equally-rapidly. Regarding the evaluation of articles, above - often when people do this, it's in response to discovering such a mass-creation. In that case all the articles can reasonably contain the same crucial flaw that means they shouldn't have been created; I continue to assert that WP:BEFORE is advisory and optional (otherwise it would invert WP:BURDEN, which obviously places the burden to search for sources on the people who add or wish to retain material - you can't add something and then insist other people do that search before deleting it.) But even for people who try to insist that it is mandatory, it only requires "reasonable" searches, and when dealing with mass-created articles it is reasonable to simply evaluate the method they were created by and therefore examine them all at once before mass-prodding or mass-AFDing them. Obviously such mass actions are meant to be taken cautiously but we can't forbid them here, since they're sometimes clearly necessary. --Aquillion (talk) 12:36, 13 March 2025 (UTC)[reply]
Editors can't mass-create more than 25–50 articles per day without getting written permission (and nobody's actually done that for years). If the goal is to mirror creation limits, then that suggests a rate limit of 25–50 AFDs per day. WhatamIdoing (talk) 14:55, 13 March 2025 (UTC)[reply]
That's a limitation of the data available. Manual inspection of the results reveals plenty of instances where the created pages are mostly non-redirects. Example. —Cryptic16:29, 13 March 2025 (UTC)[reply]
"Editors can't mass-create more than 25–50 articles per day without getting written permission (and nobody's actually done that for years). " ??? Where do you get that idea from? See e.g. User:Ponor, who created 235 articles between 02.27 yesterday and 06.10 today. Fram (talk) 12:32, 26 March 2025 (UTC)[reply]
From WP:MASSCREATE, which says "large-scale" creations require written permission in advance, and adds that "While no specific definition of "large-scale" was decided, a suggestion of "anything more than 25 or 50" was not opposed."
If Ponor has not received permission under this policy provision, then any concerned editor can take the violation off to ANI, with the possible results including mass deletion. WhatamIdoing (talk) 19:47, 26 March 2025 (UTC)[reply]
So not "can't" but "aren't theoretically allowed to, but nothing's stopping them". There is no rate limit like there is with account creations and so on. Fram (talk) 11:07, 27 March 2025 (UTC)[reply]
On the very rare occasions it is actually desirable (it's never "necessary") to mass-delete articles then we have processess for that - namely group AfDs and in extreme cases RFCs. PRODs should never be used en-mass because PRODs are explicitly only for uncontroversial deletions, and mass deletion is always controversial. And anyway it should never be easier to delete an article than create one - our goal is to build an encyclopaedia not to delete one. Thryduulf (talk) 15:02, 13 March 2025 (UTC)[reply]
mass deletion is always controversial Is that a guideline or your opinion? I was reading this because in December I proded a bunch of articles a single editor had made in a short period of time and I think most of them were deleted. I do not recall anyone mentioning this to me at the time Czarking0 (talk) 04:29, 16 March 2025 (UTC)[reply]
How many is "a bunch"? On 18 December 2024, I see five articles that you prod'd but that did not get deleted. They were by two different editors, writing about two unrelated subjects. Two or three articles per editor/subject is not "mass deletion". Something like 25–50 articles, all on the same subject, and especially if it were all of the articles on that subject or if the prod statement had a lousy rationale (such as "No ____ is ever notable" – something an experienced editor like you would never claim) would be mass prodding.
Reasonable people could disagree on exactly where to draw the line between those two extremes, but I don't think that, say, five articles on the same subject would count. And if the article is unsourced and qualifies for WP:BLPPROD, then any editor who runs across it should either promptly make it ineligible (i.e., add a source) or prod it. WhatamIdoing (talk) 05:26, 16 March 2025 (UTC)[reply]
I think there needs to be proportionality here, and specifically that the effort required to delete an article should be proportionate to the effort spent in its creation. Lugnuts stubs were created at extremely high rate, often several per minute, from databases. Therefore they should be proddable at an extremely high rate; but they aren't, because we have editors who insist on laborious and time-intensive processes that have the practical effect of making them ludicrously difficult to get rid of.
Per policy, we're expected to be very firm about the use of high quality sources for biographies of living people. Lugnuts' creations very largely consist of undersourced, unmaintained, unwatchlisted BLPs and in my view they represent the most ghastly risk to the project. I continue to feel that the best thing we could do with Lugnuts articles is purge them all. In due course, good faith editors who will actually curate and maintain them will be ready to bring the appropriate ones back.
While the articles may be similar the subjects are not necessarily so. It is very significantly more important to get things right than to do them quickly, so we need to take the time to assess what the correct action for each article is. I'm not advocating individually in every case, but any grouping must be done carefully and thoughtfully. Thryduulf (talk) 12:18, 26 March 2025 (UTC)[reply]
I would agree with you if the subjects were similar, but they are from wildly different countries and time periods. Just because the article format or length is the same doesn't mean the subject matter is. --Habst (talk) 12:43, 26 March 2025 (UTC)[reply]
These would be the editors who insist on laborious and time-intensive processes to whom I referred. The time should have been taken at creation, because these are biographies. It was not. Lugnuts made these very rapidly from a database, and they read almost identically. I do feel that it is for those who advocate keeping them to review and watchlist them all.—S MarshallT/C14:46, 26 March 2025 (UTC)[reply]
How much time should have taken at creation is irrelevant now they have been created. What matters now is that two wrongs don't make a right and those who wish to review articles before deletion be given the time to do so. Thryduulf (talk) 15:15, 26 March 2025 (UTC)[reply]
Assuming your figure of 93,000 articles is correct, and an average of 10 minutes to do a full and proper BEFORE and add make any relevant improvements to the article (I don't know how accurate this is) comes to 645 days, 20 hours. That's about 1¾ years of volunteer time assuming no duplication of effort, no time spent pushing back against proposals to just delete the lot without adequate review, no time spent on other articles, no time defending articles improved (but not sufficiently to someone) from PRODs/AfDs, no time discussing articles on talk pages (e.g. merge/split proposals), no time dealing with vandalism, no time improving articles to more than the bare minimum standard, etc. Thryduulf (talk) 16:43, 26 March 2025 (UTC)[reply]
There are exactly 93,187. Lugnuts' autopatrolled rights were removed in April 2021, so the community has been well aware of the magnitude of the problem with his creations for about four years. I would like to comply with policy by being very firm about the use of high-quality sources for these biographical articles. But I can't: no venue exists in which I'm allowed to be firm. If I tried to mass-PROD or mass-AFD them then I would be told off for being disruptive. The whole quagmire is unfixable in any rational or acceptable timescale, which is why I keep saying that the incredible number of unwatchlisted biographies represents the most ghastly risk to the project.—S MarshallT/C16:56, 26 March 2025 (UTC)[reply]
The whole quagmire is unfixable in any rational or acceptable timescale that depends entirely on your definitions of "rational" and "acceptable". In the view of myself and many others, any way forward must allow time to properly review each article, search for high quality sources in the place they are most likely to be found (which may be offline and/or not in English) and (where applicable) add them to the article. Anything shorter than that is neither rational nor acceptable. Thryduulf (talk) 17:06, 26 March 2025 (UTC)[reply]
Then create them after the sources are found. Would you still believe we should leave them be if someone used bots to create articles for all ~10 million people listed on IMDB? Also going to note (somewhat in response to S Marshall) that as I said above, this was addressed at WP:NSPORTS2022 where it was decided that sports biographies must have sigcov in the article. So any without already-existing sources in the article are fair game. This includes but is not limited to the articles in Category:Sports biographies lacking sources containing significant coverage. There's already consensus for this. Thebiguglyalien (talk) 🛸18:45, 26 March 2025 (UTC)[reply]
He's not deprodding every Lugstub – its mainly only ones that have a high chance of being notable (I've seen hundreds of Olympian PRODs recently, many of which are probably notable, get deleted without anyone attempting to take a look into it) – nor is he insisting editors have to have checked all local offline archives to prove no SIGCOV exists at AfD. All we want is that some archives be searched – its very frustrating when we're having some of the all-time greatest African athletes deleted because no one is checking any relevant places. What's wrong with listing coverage of a subject that one can't translate themselves so that someone who can speak the language can hopefully see if its sufficient for notability? BeanieFan11 (talk) 02:35, 28 March 2025 (UTC)[reply]
If All we want is that some archives be searched then why wasn't searching all Czech newspaper archives available at Charles University, or all Al-Anwar and Al-Ahram and Akhbar Al-Usbo and Addustour newspaper archives, or any of the other archives in dozens of other AfDs enough? BEFORE does not even hint at recommending a local or even nation-specific archives search, so you are demanding WAY more than is expected at AfD ON TOP of ignoring a global consensus requirement. JoelleJay (talk) 03:09, 28 March 2025 (UTC)[reply]
I'm more talking about the many African and Asian subjects being deleted, rather than the one Czech athlete for which the argument was in part that the sources were sufficient (even if you disagreed). I'm going to go through the last few Olympian AFDs that have been deleted/redirected and note if a relevant archive was searched: Mohamed Al-Aswad? No. Bohumír Pokorný? Yes, but no one was willing to look at the coverage. Kamana Koji? No. Sami Beyroun? No. Alfredo Valentini? No. Artur Elezarov? No. Faisal Marzouk? No(?). Piero Ferracuti? No. For many of these, there's not even evidence that any search anywhere is being done. Suggesting that someone should look for sources from that subject's nation is not "demanding WAY more than is expected". BeanieFan11 (talk) 03:18, 28 March 2025 (UTC)[reply]
It absolutely is demanding way more when there is literally nothing in BEFORE that suggests anything close to what you are asking for. JoelleJay (talk) 03:51, 28 March 2025 (UTC)[reply]
However, as I've stated in other threads, I do think prods/noms should provide evidence that a search was done in the native language. But it's not editors' faults that potentially notability-demonstrating sources are not verifiable; we don't keep articles on other GNG-dependent topics just because no local resources are accessible. I've asked WMF numerous times, including in several on-wiki discussions, to put their considerable largesse into media digitization efforts in underrepresented countries, but they would rather spend it on ridiculous unvetted grants and on attempts at enshittifying the platform. JoelleJay (talk) 14:35, 28 March 2025 (UTC)[reply]
Wikipedia:Notability (sports) § Basic criteria (with one exception) describes how the individual bullet points at Wikipedia:Notability § General notability guideline are interpreted in the context of sports figures. Thus it serves as an overall framework for the sports-specific guidelines for presuming the existence of suitable sources which demonstrate that the general notability guideline is met. This framework is also suitable for sports without sports-specific guidelines. It's not a case of one overriding the other, but the two complementing each other.
As I explicitly stated earlier, what should be done before creation is irrelevant now they have been created. Every discussion about NSPORTS2022 and similar has found either no consensus for or explicit consensus against mass deletion or deletion without review, so no there isn't consensus for that. Thryduulf (talk) 19:37, 26 March 2025 (UTC)[reply]
what should be done before creation is irrelevant now they have been created – Not true. We could absolutely revert to the status quo ante, but people make a stink about it whenever the solution is raised. Thebiguglyalien (talk) 🛸20:24, 26 March 2025 (UTC)[reply]
Reverting to the status quo ante is a method of dealing with the situation we find ourselves in now, we could apply that regardless of what was or wasn't done before creation. I will continue to oppose that solution as deleting articles about notable subjects just because someone also created articles about non-notable subjects is very much cutting off one's nose to spite one's face. Thryduulf (talk) 20:46, 26 March 2025 (UTC)[reply]
Reverting to "status quo ante", aka mass deleting everything a Very Naughty Editor™ created, means deleting Muzamil Sherzad, which had 16 refs at the time of creation.
It's illogical to say that we want to promote the creation of well-sourced articles, and then propose deleting some well-sourced articles. (By that "logic", if you miss any questions on your math test, the teacher should mark everything wrong, including the once you answered correctly.)
I would like to prevent the creation of badly sourced articles. But since nobody's given me a working time machine, that can't be done for Lugnuts' articles. The options available to us are:
Review them one by one (cons: lots of work)
Mass delete them (cons: see above)
Stop caring about whether some usually unimportant, usually accurate, and usually low-traffic pages exist, and do something that you think is actually important with your time.
This is fundamentally the "fast, cheap, good" problem. At most, you can get any two of those qualities. So if you say "I want to solve the Lugnuts problem quickly and with minimal effort", you are effectively saying "I want low-quality results from this process". WhatamIdoing (talk) 22:20, 26 March 2025 (UTC)[reply]
Which is what the original Prods did, apparently. They manually reviewed the articles, saw they had only had non-significant coverage (sports-reference.com), and prodded them (e.g. [1][2][3]). And still they are accused of mass deletion. You can't have it both ways. Fram (talk) 11:15, 27 March 2025 (UTC)[reply]
I think it's far worse than WAID makes out. Reviewing them one by one would be the least rotten option, if we could review them, find they're crap, prod them, and move on. But we can't. We're barred from prodding them at a rate that would get the job done in the next decade, because we'd overwhelm the self-appointed proposed deletion proposers.—S MarshallT/C23:06, 26 March 2025 (UTC)[reply]
25 a day would cover every article Lugnuts created in almost exactly one decade. (I assume the ~90K article count does not include his 75K redirects.) The prod folks are unlikely to complain about 25 in a day. WhatamIdoing (talk) 00:04, 27 March 2025 (UTC)[reply]
The 77,502 redirects aren't included. For the 10 years without a day off that it will take to clear this backlog, who will watchlist and maintain these poorly sourced biographies?—S MarshallT/C08:43, 27 March 2025 (UTC)[reply]
Bear in mind that there are also all the articles that Carlossuarez46 created from databases. Those aren't biographies so they're less appallingly risky, but the volumes are extremely high. PROD can only cope with so much, and it's not reasonable to make PROD sclerotic for that long.
So even if I could, by working for ten years solidly without a day off, clean up Lugnuts' mess, he would still need his own personal CSD criterion. Something like "article that's sourced only to databases", so it covers Carlossuarez46 as well.—S MarshallT/C10:20, 27 March 2025 (UTC)[reply]
That CSD criterion isn't viable, because it conflicts with WP:NEXIST and is therefore controversial. The notability of a subject isn't determined by whether someone has already added a suitable source. If "didn't add a good source yet" were a viable CSD criterion, then Category:Articles lacking sources could be emptied by bot. That might be no skin off my nose – WPMED's articles are all sourced now – but it would be controversial, and thus not a candidate for CSD. WhatamIdoing (talk) 19:20, 27 March 2025 (UTC)[reply]
"Who will watchlist and maintain these" – the same people who do now; the same people who would do so if they had better sources.
Also, keep in mind that it doesn't have to be you spending 10 minutes x 25 articles x 3650 days to either add a decent source or suggest a WP:PROD. A couple dozen editors could each do one a day. WhatamIdoing (talk) 19:22, 27 March 2025 (UTC)[reply]
If this is the path we choose to go down, we might as well update WP:MASSCREATE to clarify that your articles will be allowed to stay up if you violate it, no matter how many you make. I should have some fun with five-digit or six-digit mass creation. I know for a fact that it will be basically impossible to get rid of them once I create them. Thebiguglyalien (talk) 🛸19:55, 27 March 2025 (UTC)[reply]
I mean, it shouldn't be too hard to write a bot to scrape databases for new species articles, the majority of which are already written by lazy editors who can't be bothered to write beyond "a is a species of b described by c in d" and who should honestly be blocked at this point. Cremastra (talk) 20:05, 27 March 2025 (UTC)[reply]
As I have previously demonstrated, you can write a whole lot more than a single sentence from a species database – including the addition of non-database SIGCOV sources.
MASSCREATE is a behavioral rule, which means you are more likely to get blocked for violating it than to have content deleted for violating it. You might have noticed that Lugnuts is blocked. WhatamIdoing (talk) 20:09, 27 March 2025 (UTC)[reply]
The reason why Wikipedia works is because of proportionality. Edits can be reverted with less effort than it took to make them. That's how it's possible to have an encyclopaedia that anyone can edit; we can fix things with a reasonable amount of labour.
This violates that principle. It's a free gift to griefers and bad actors. As soon as you've got an autopatrolled account, you can create two or three articles a minute, and they'll take (on Thryduulf's estimate above) 10 minutes' labour just to go through the WP:BEFORE.
BEFORE is the right principle when it protects people who care, and try. If you spend an hour researching and drafting an article then a ten minute BEFORE is perfectly fair.
It's not the right principle for people who splurge out thirty articles in thirty minutes.
The answer to Lugnuts and Carlossuarez46 is definitely fast and cheap, not good. They created fast and cheap so good's unviable.
They need reviewing individually but there's got to be a proportionate workflow. It has to be glance, see if there's a non-database source, draftify if there isn't, move on. It cannot possibly be prod-deprod-triptodramaboards-argue-tag-detag-argue-AFD-DRV-argue. And the people who advocate the long-winded process need to be the ones responsible for watchlisting and maintenance.—S MarshallT/C23:52, 27 March 2025 (UTC)[reply]
In terms of preventing future such problems, I think the answer is that we need to stop people when they're in the "first hundred" range, and not wait until they're on the multi-ten-thousands.
Carlossuarez46 was yelled at in March 2021 because articles he created in ~2008–2009 (example) did not comply with a guideline that was adopted in December 2012. Yes, it would be nice if those articles were in better shape, but it's also unfair to tell people that they've done a bad thing because they didn't predict how the rules would change in the future.
Okay, but now that we've shut the stable door, the horse still needs to be caught and returned. We still need to agree a reasonable and proportionate workflow for dealing with the lugstubs we have, and "do a full before for each one" isn't it.—S MarshallT/C08:12, 28 March 2025 (UTC)[reply]
Oh, did we only have a guideline or policy from 2012 on that articles had to be verifiable and truthful? E.g. not creating articles claiming to be about villages when they weren't about villages at all? Carlossuarez was "yelled at" because "we have one-sentence articles hanging around for years where that one sentence is an outright falsehood."[4] Please don't write alternative truths to support your position. That there were occasionally correct articles among the thousands of dubious or outright wrong ones is hardly an excuse. Fram (talk) 08:52, 28 March 2025 (UTC)[reply]
Support - As we saw with the mass Lugnuts deletions, many of the articles had sources out there and were able to be fixed if you just looked. But despite there being WP:NORUSH, the articles just HAD to be drafted ASAP. It can take me hours to days to write various articles and if you are able to nominate dozens a day, you are probably not doing the proper research. Foreign articles also need extra care since you have to search in different languages and databases.
I also do think something needs to be done with Lugnuts being brought up time and time again. It's just harassment at this point and despite nobody being able to WP:OWN an article, it sure seems like many people think he does.KatoKungLee (talk) 13:13, 28 March 2025 (UTC)[reply]
I think that the complaints about Lugnuts show a breakdown in the community. We're no longer in this together. Instead, some of us see WP:IMPERFECT contributions as a burden being foisted on to us. He gets to make an article, and now I'm stuck watching to see whether anyone vandalizes it? (The article I expanded yesterday has averaged less than one edit per year. Most of them were bots/scripts, and zero touched the article's content.)
Perhaps we're feeling the strain more than we used to? We used to spend a huge amount of time – perhaps as much as a third of active registered editors – manually reverting blatant vandalism. The bots have taken over most of that, so perhaps that has given us enough space to start complaining about things that are at the Paper cut level rather than the serious injury level? When you spend your day reverting poop vandalism, then a new article that contains no vandalism at all might seem particularly good. When you almost never see blatant vandalism, maybe the problem of a single-sentence stub seems more burdensome. WhatamIdoing (talk) 18:44, 28 March 2025 (UTC)[reply]
Recent deaths are nominated at WP:ITNC where they are reviewed for quality purposes, and if they don't reach sufficient quality in 7 days, the nomination fails. Most celebrities (particularly actors and musicans) do not have quality articles due to unsourced filmography or discography tables, nor get improved, so many of these are not posted. — Masem (t) 17:12, 6 March 2025 (UTC)[reply]
It also sometimes happens that people are not nominated, although this is uncommon with people likely to be described as a celebrity. Unsourced or partially sourced filmographies and discographies is by the most common reason but the whole article needs to be fully cited and free of orange maintenance tags and other significant issues. By far the best thing to do if there is someone you really think should be featured is to make sure their article is of good quality - and you don't need to wait until they die to start doing this.— Preceding unsigned comment added by Thryduulf (talk • contribs) 17:53, 6 March 2025 (UTC)[reply]
Remember that this is an encyclopedia, not a news site. The idea of this section is to show what encyclopedic content we have about the person who has died, not to report that fact. Phil Bridger (talk) 18:22, 6 March 2025 (UTC)[reply]
Deaths in 2025 indicates that about 20 deaths/day are recorded on Wikipedia. ITN's RD section only seems to do about 4/day on average. The selection of this fraction seems quite arbitrary. For instance, the current selection is:
Eddie James – American murderer and sex offender (1961–2025)
Munir Shakir – Founder of terrorist group Lashkar-e-Islam (1969–2025)
Dik Wolfson – Dutch economist and politician (1933–2025)
Eddie Jordan – Irish motorsport executive and broadcaster (1948–2025)
Aaron Gunches – American murderer executed in Arizona (1971–2025)
The most prominent celebrity death currently is George Foreman – American boxer (1949–2025) but that article has not been posted yet. It still got millions of readers so ITN's failure doesn't much matter – most readers access such articles using search engines, not the main page. (see What's known about how readers navigate Wikipedia)
Yes, I know this is at perennial proposals, which is why I'm not jumping straight ahead to an RFC, but WP:USPLACE, the guideline that determines the titles of settlements in the United States, is fundamentally at loggerheads with the five criteria:
Recognizability: Large cities that are not usually associated with their state may astonish readers who see the page name connected to the state (for instance, when I hear Louisville, I don't think of it being in Kentucky). Yes, this is a double-edged sword, as people with no knowledge of the city might not know of it, but this can easily be solved with textual disambiguation. For instance, 2022 Ürümqi fire says in its lead sentence: On 24 November 2022, a fire broke out... in Ürümqi, Xinjiang, China, because the average reader will not recognize Ürümqi as being in Xinjiang or China, yet no disambiguation is present in the Ürümqi article. We could easily use this in the lead sentences of articles concerning these cities. Also, the short descriptions and previews of the articles with USPLACE disambiguation, which include the state, are redundant to the disambiguation in the title.
Precision: In cases where there is a primary redirect, such redirect is unambiguous if a hatnote is added, as is present on Boston, Cleveland, and most of the other 26 undisambiguated city articles. If the title was ambiguous in any way, there would be no primary redirect.
Concision: Raleigh, North Carolina is almost three times longer than just plain old Raleigh, which redirects there already, so moving the much longer name to the shorter name breaks nothing and makes Wikipedia more efficient.
Consistency: Another double-edged sword. The argument for consistency is clear: not a single other country uses USPLACE. Yes, consistency has been used by supporters of USPLACE to argue that it goes against consistency to have some articles using commas while others don't. However, we don't worry about that in any other country: we have Valence, Drôme but Biarritz not Biarritz, Pyrénées-Atlantiques. There's no reason we need to treat the US different from literally every other country.
The argument is that appending the state is part of American English. That is not even remotely true. No source describes American English as such (see American English, which does not mention the comma convention at all) and other articles that use American English, such as Agua Prieta, whose article uses American English and with the town just across the border, even so, the article is not titled Agua Prieta, Sonora, which would be the title if the comma convention were part of American English. Yes, the AP Stylebook recommends the comma convention. But if we followed the AP stylebook, then we'd be ending quotes with ." instead of "., our article on the Salem witch trials would have to be moved to Salem Witch Trials, and our article on Gulf of Mexico would have to be moved to Gulf of Mexico/Gulf of America. Simply put, USPLACE violates our guidelines on article titles.
Furthermore, many editors oppose USPLACE, as can be shown by the three RMs opened in the last month, all of which unfortunately failed, on removing the state name from Brownsville, Lubbock, and Redmond. Even some of the oppose !votes in those RMs and others expressed dissatisfaction with USPLACE, with one editor calling it peculiar and another saying they were personally opposed to it. Consensus can change, especially when consensus is determined to be in conflict with policy. Thank you for considering my request.
I can't see what the arguement is. We gave naming conventions for most of the world. In the case of Brownsville there us clearly two places on wikipedia with that name, so we need to distinquish them and the US has a lot of places with the same name. If we didn't have these conventions, based upon some of the arguments raised, Boston, Lincolnshire should be just plain Boston as it is the original - which is just silly. Davidstewartharvey (talk) 19:48, 7 March 2025 (UTC)[reply]
Yes, but that's true of lots of topics. Having the larger area name is something we do for disambiguation, and like anything that we disambiguate, there can be a primary name. We even do that geographically; we have an article on Paris and don't feel the need to specify it's the one in France and not Paris, Texas. -- Nat Gertler (talk) 19:57, 7 March 2025 (UTC)[reply]
But we should not have "Primary pages", as how can we determine what is primary? Boston, Lincolnshire or Boston, Massachusetts, or the 16 places in the US or the 34 other places around the world? Paris should be Paris, France. Even Britannica has it as Paris (national capital, France) so we are following normal conventions. Davidstewartharvey (talk) 20:17, 7 March 2025 (UTC)[reply]
Interesting viewpoint, however, it is not the consensus of Wikipedians, who believe that it is much more convenient to have a primary topic, with such a high consensus that it became one of our policies and guidelines. Feel free to open an RM at Paris asking to have it moved to Paris, France, however, in accordance with the primary topic guideline, it will likely fail. 🐔ChicdatBawk to me!20:22, 7 March 2025 (UTC)[reply]
Concensus? In Bios it isn't. Take John Smith, there is no primary article. What is the primary article is conjecture, which leads to edit wars. Clearly making something clear and simple is easy, and falls in line with what Encyclopedias have done for years. Davidstewartharvey (talk) 20:28, 7 March 2025 (UTC)[reply]
So how is Boston MA the primary? The tea party may have taken place their, but that is a page on its own? Boston, Lincolnshire has a history of over 1000 years, while Boston MA is named after the UK town by settlers from their? I would say neither are primary, as they are amongst how over 40 world wide. Davidstewartharvey (talk) 02:05, 8 March 2025 (UTC)[reply]
Boston: population of 675,000 in the city proper, and 4,900,000 in the Greater Boston area.
Boston, Lincolnshire: population of 45,000 in the city proper, and 67,000 in the borough.
We do it all the time in bios, when there's a clear "primary" topic -- i.e., the one that most of the people entering the name are looking for. Consider, say, Robin Williams, which takes you right to the comedian, even though Robin Williams (disambiguation) shows you eleven other Robins Williams. Over 13,000 page views a day for the comedian's page, and less than a quarter of one percent of those end up on the disambiguation page looking for the other Robin Williams they were looking for. See WP:DETERMINEPRIMARY for how we judge this. -- Nat Gertler (talk) 05:58, 8 March 2025 (UTC)[reply]
I'm not going to go into why Boston is the primary topic, but you can read WP:DETERMINEPRIMARY and then do the analyses between the former and the latter. In any event, Boston isn't a great example since we have an exception for major US cities that don't require disambiguation. voorts (talk/contributions) 02:26, 8 March 2025 (UTC)[reply]
You might want to first look at all the archived discussions and proposals listed near the top of Wikipedia talk:Naming conventions (geographic names). I count almost 30 dating back to May 2004 discussion, with the last one in February 2023. Even getting the AP Stylebook exception for the 28 or so for the larger cities seemed to be a hassle. I think it had gotten to the point in that last discussion, with over 20 years and 30 discussions with this disputed issue, that the titles are "stable" now and it would be more of a disruption for a massive change rather than keep retaining this existing style. Zzyzx11 (talk) 19:52, 7 March 2025 (UTC)[reply]
Well thats just plain wrong! Louisville should redirect to Louisville (disambiguation) as there is more than Louisville in the US - 8 in the US alone plus 1 in Belize! Davidstewartharvey (talk) 20:23, 7 March 2025 (UTC)[reply]
Oh and I forgot to say, what do American reality programs for food and property do when they go anywhere? They normally flash the name up in the convention i.e. Boston, MA, which is just an abbreviation of what USPLACE is doing so it is used in American English Davidstewartharvey (talk) 21:14, 7 March 2025 (UTC)[reply]
It's not plain wrong. That is not how we deal with ambiguous names. If something is the primary topic (that is, it is either the most likely reference of that topic that someone is looking for or "itt has substantially greater enduring notability and educational value than any other topic associated with that term"), then the article is placed at that page, and a hatnote to a disambiguation page is provided. voorts (talk/contributions) 22:36, 7 March 2025 (UTC)[reply]
Chicdat, WP:ADMINRECALL finally passed in 2024 partly because it was initially identified as part of the larger urgent need to reform RFA. I did not see that sense of urgency in that last 2023 USPLACE discussion -- everybody basically repeats all the same arguments as in the previous discussions, and it ends with no consensus. I do not think you bring anything significantly new to the table that has not already been discussed repeatedly. Zzyzx11 (talk) 20:53, 7 March 2025 (UTC)[reply]
Fully concur with User:Zzyzx11's assessment. Also keep in mind that for many American attorneys and other legal professionals, the first Louisville they think of when they hear Louisville is Louisville, Colorado, because that is where the National Institute for Trial Advocacy is currently based. Most people who have heard of Louisville, Kentucky think of it only because they are fast food fans, and of course, all true fast food fans around the world love Yum! Brands. --Coolcaesar (talk) 05:13, 8 March 2025 (UTC)[reply]
I had no idea NITA was based in Louisville or Colorado. We also don't base a primary topic or decision to disambiguate on whether a small population of people associate something with a place. voorts (talk/contributions) 17:37, 8 March 2025 (UTC)[reply]
I strongly disagree with that last point. There are over 1.3 million lawyers in the United States, and that's not counting allied legal professionals like paralegals, assistants, and secretaries, many of whom have also heard of NITA because the lawyer they work for ran off to attend a NITA learning-by-doing program. --Coolcaesar (talk) 11:47, 18 March 2025 (UTC)[reply]
I would definitely be in favor of allowing more specific exceptions to USPLACE, for additional large or particularly famous cities, and for unambiguously named state capitols. BD2412T03:43, 11 March 2025 (UTC)[reply]
Thank you for your sound argumentation, Chicdat. I agree with your points, but as I am not familiar with the history of USPLACE I don't know how much of a trainwreck yet another RfC would be. Toadspike[Talk]10:58, 12 March 2025 (UTC)[reply]
Completely disagree. That someone created an article about the city in California and gave it a non-disambiguated title is not evidence that the non-disambiguated title was correct. That said, I could see an argument for saying that the redirect should point to Palo Alto (disambiguation). Blueboar (talk) 18:38, 16 March 2025 (UTC)[reply]
@Blueboar: I'm not saying these articles should be automatically moved. I'm just trying to get the rule prohibiting such a thing out of the way before opening a bunch of RMs on those articles. If evidence can be provided that the city in California is not the primary topic for Palo Alto, it is likely an RM would fail. 🐔ChicdatBawk to me!18:41, 16 March 2025 (UTC)[reply]
The “rule” is fine as is. Far simpler to go the other way… and file an RM arguing for an “occasional exception” when appropriate. Blueboar (talk) 19:25, 16 March 2025 (UTC)[reply]
My concern would be that by snipping the states we'd end up with yet another round of RMs on things like Plymouth (MA) v Plymouth (UK) or Birmingham (AL) v Birmingham (UK). Neither US city in these cases is close to being the primary use, but that hasn't stopped people wasting everyone's time over and over before. Black Kite (talk)19:36, 16 March 2025 (UTC)[reply]
They can still make an RM request for Birmingham or Plymouth, claiming that the UK cities are not primary topics (this would necessarily be the case if the US cities are). And if we applied USPLACE-like rules for the UK, we would be much more likely to have an edit war than allowing any real chance for a discussion (an RM would attract attention, while discussion about a redirect target would probably escape all attention). Animal lover|666|08:31, 18 March 2025 (UTC)[reply]
It has been 22 years and 9 days since MartinHarper made an edit that quite a lot of people have missed since.
I wrote Special:Diff/1278668922 on the 22nd anniversary, entirely coincidentally since someone was talking about the history and I thought that I should write it up.
I didn't even spot the date when I was doing it.
(I'm not aware that this came up on the mailing list prior to that, although memory is hazy and I'd have to pore over the archives to refresh it.
However, there is context in the form of m:What to do with entries related to September 11 casualties, which was a contemporary issue.
c.f. Special:Diff/715056 on the policy talk page the day before.)
Thank you for this. It is sometimes difficult to trace the history of our rule and processes, but knowing the history can help understand why things developed the way they did. I hope that you left a note at Wikipedia talk:Notability about this as well. WhatamIdoing (talk) 02:36, 16 March 2025 (UTC)[reply]
Thank you for this explanation. I'm trying to wrap my head around notability, as my first article, Draft:Josephine Semmes, was rejected based on notability and is now again awaiting review. After reading your article, I'm still baffled, as Semmes's notability as a scientist seems to me to have been pretty well-established in the previous article drafts, per what you wrote about authors (also seen at WP:ACADEMICS). Aurodea108 (talk) 05:48, 23 March 2025 (UTC)[reply]
Usually, WP:NPROF is looking for someone with a "named chair" – "The David Donor and Molly Millionaire Professor of Something Or Another". People who "only" discover useful things about the world don't necessarily qualify. If you haven't done so before, you might drop by Wikipedia talk:Notability (academics) to ask for advice. WhatamIdoing (talk) 22:03, 23 March 2025 (UTC)[reply]
My question is this, do we or should we have a policy on electoral results? We state that wikipedia is not a Gazetter but has elements of a Gazetter, so should we have lists of results? Davidstewartharvey (talk) 09:21, 19 March 2025 (UTC)[reply]
I wouldn't look to create a new policy over a few AfDs with the same participants. Lots of AfD outcomes do somewhat contradict policy. Traumnovelle (talk) 03:36, 25 March 2025 (UTC)[reply]
ASIN links
We have thousands of links to Amazon via the {{ASIN}} template. This seems to me to be entirely inappropriate.
There is a neutral and globally unique identifier (ISBN) which every book from a serious publisher carries. If you use the {{ISBN}} template, we will help the user find the book in their own region, from a library or a choice of bookstores. An ASIN is a link directly (and only) to the Amazon sales page.
I strongly believe that we should not permit the use of a vendor-specific product SKU and sales link, through a template, in this way. And, as a matter of policy, I believe we should ban the use of sales links as references generally. Guy (help! - typo?) 13:35, 20 March 2025 (UTC)[reply]
We are not limited to books from serious publishers. We conditionally accept self-published sources, particularly for autobiography and material from subject matter experts, which may be in niches that do not interest the "serious" publishers. Where you're most likely to have an ASIN without an ISBN available is when the book is published as a Kindle ebook only, no physical edition. (This does not mean that we should necessarily display the ASIN the way that we do an ISBN.)
An Amazon sales page provides more than just sales information on such an ebook; it provides a preview of the portion of the book, which may be useful in verification of content. A book that is released primarily as a Kindle ebook may have no other significant web presence such as a Worldcat page to point to. And while I understand the desire for Wikipedia not to be a pipeline to Amazon sales, I'm not sure there is a meaningful difference between pointing to an Amazon page for a work that is only available on Kindle and to pointing to other paywalled sources, such as places that will show you the summary of a journal article but sell you the whole thing for $65. -- Nat Gertler (talk) 16:34, 20 March 2025 (UTC)[reply]
ISBNs don't exist for some books, including anything printed before 1966 (when the "SBN" [ISBN's predecessor] was first invented) and quite a lot printed before about 1980.
ASINs also exist for sources that are not books (e.g., music, maps, pamphlets, instruction manuals). Clicking on ASINB000003F6R will verify the fact that David Bowie really did narrate Peter and the Wolf. There is no ISBN for that recording.
Nat, thinking back to previous discussions, I think part of the problem is that it's Amazon. All the people who hated Walmart in the 1990s have turned to Amazon as the destroyer of working-class life now; we should try to hurt them or de-platform them whenever possible.
I agree with you that some of the objections amount to squeamishness about money. In this model, however, the cachet of an 🌟academic💫 journal offsets the vulgarity of money changing hands. An unabashedly commercial website has no such defense. I would expect "Don't use Amazon" – "No, don't use Barnes and Noble, either" – "No, you can't use the label's webpage" – "No, don't use the band's webpage either!" – and then we end up citing, e.g., a dust jacket cover, and what could previously be checked by anyone who clicked the ASIN link can now only be checked by people who can get their hands on a physical copy.
And some of it may be a game of WP:FETCH. I recall seeing an editor insist that iTunes and similar music services were unacceptable sources for track listing information. It turned out that what the editor actually meant was a lot closer to "I don't think we should have articles about this music genre" than to "I think this source has incorrect information".
I would, therefore, not recommend deleting the ASIN template. But I would recommend minimizing its use. In particular, if the ISBN works, then I'd be happy for the CS1 templates to automatically not display the ASIN. It IMO should be used when we need it, not just because it's an available parameter. WhatamIdoing (talk) 20:18, 20 March 2025 (UTC)[reply]
{{ASIN}} is what we call an identifier of last resort. Some things have no ISBNs, no OCLC numbers, no ISSNs, no DOIs, no PMIDs, etc... but will have an ASIN. It it then, and only then, that ASIN should be used. Take for example
Dyas, William J. (August 1889). "Necessity for Discretion". The Canadian Druggist. 1 (2): 30-38. ASINB0DQPPGTXZ.
"An identifier of last resort" is exactly my feeling. If that isn't already in the template's documentation, then I support adding it. WhatamIdoing (talk) 22:07, 20 March 2025 (UTC)[reply]
We should note that ASINs assigned to pre-ISBN work are slipshod. That's because it's generally used items being entered into Amazon's database by third parties. Sometimes the seller won't find/won't bother to find the previous listing which is there, giving the same publication multiple ASINs; sometimes they find the listing for a different edition (or even different work of a similar title) and assign their item to that, making the ASIN unreliable for what you get. The data that populates the page is not being provided by the publisher and is thus much less reliable. There is also some incentive for deliberate misinformation that allowed some things to show up higher in certain search results; Amazon seems to have reined in the used items that were supposedly being published in 2040, but that was a regular thing for a while. None of this is to say "no ASINs", but just putting a realistic cap on their usefulness on some fronts. -- Nat Gertler (talk) 21:38, 20 March 2025 (UTC)[reply]
I vaguely remember having this discussion on here somewhere in about 2005, and I think I made more or less the same comments at the time as you do now, but sadly failed to get traction then. I'm weirdly reassured it's only now used about 5k times, to be honest! I expected it to be a lot more prolific.
I would strongly recommend that at the very least we consider migrating any ASIN starting with a digit - ie presumably a valid ISBN - to an ISBN field/template and remove the ASIN template as duplicative. I don't see any obvious reason for using those outside of the very rare circumstance in which we are somehow citing the Amazon page itself, and those could (should?) be using a direct URL instead. A search for these using {{ASIN}} - searchAndrew Gray (talk) 21:49, 20 March 2025 (UTC)[reply]
That found 783 for me before it timed out. I checked one (Viv Richards) and was easily able to replace the ASIN with an ISBN (by clicking through to the Amazon page and copying the ISBN-13 listed there, but the ASIN was the same as the ISBN-10, which is also valid for us). Should we suggest this as a task at Wikipedia:AutoWikiBrowser/Tasks? WhatamIdoing (talk) 22:16, 20 March 2025 (UTC)[reply]
I think assuming that the ASIN resolves to a valid ISBN-10, there would not be any particular problem replacing it with an ISBN. The ISBN-10 can be converted to an ISBN-13 if desired. This might be a little too complex for AWB however (it needs ISBN validation/conversion). Andrew Gray (talk) 23:11, 20 March 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.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal: Mandatory Guideline Reading for New Users Before Article Creation
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.
Many new users create articles that fail Wikipedia’s notability and neutrality standards, often due to ignorance rather than malice. This leads to frequent deletions, wasted editor effort, and unnecessary disputes. To address this, Wikipedia should implement a mandatory tutorial that all new users must complete before they can create a new article.
Problem
Currently, Wikipedia allows new users to create articles without requiring them to read or understand basic policies. This results in:
✔ Promotional or non-notable articles (e.g., local businesses, places, personal pages).
✔ Inappropriate content that requires admin intervention and speedy deletions.
✔ Time wasted by editors and admins who must review, warn, and delete these articles.
While Wikipedia provides guidelines (e.g., WP:NPOV, WP:Notability), new users are not forced to read them before creating pages. Many users skip policies or are unaware of them, leading to repeated mistakes.
Proposed Solution
Wikipedia should require all new users (those with fewer than 10 edits) to complete a short interactive tutorial before creating an article. This tutorial should include:
✅ What makes a topic notable (e.g., independent sources, significant coverage).
✅ Why Wikipedia is not a promotional platform (e.g., no self-promotion, local business pages).
✅ Basic policies like Neutrality (NPOV) and Reliable Sources (WP:RS).
🔹 Implementation Ideas:
Interactive pop-up quiz before article creation (e.g., “Does your topic have independent coverage?”).
Minimum 10 constructive edits before gaining article creation rights.
A required short reading with a "Confirm Understanding" button.
Expected Benefits
✔ Fewer promotional articles → Less admin workload on deletions.
✔ Better new user experience → Newcomers won’t waste time on non-notable pages.
✔ More encyclopedic content → Articles will be higher quality from the start.
This proposal does not block new users but ensures they understand Wikipedia’s purpose before contributing.
Request for Feedback
🔹 Should Wikipedia require mandatory policy reading before allowing new users to create articles?
🔹 What is the best way to implement this without discouraging new contributors?
Personal preferences aside, Wikipedia decisions should be based on policy and reasoned discussion. If you have a counterpoint regarding the proposal’s merits, feel free to present it. Sys64wiki (talk) 02:18, 21 March 2025 (UTC)[reply]
Whether or not to use LLM is not a "personal preference". Wikipedia (and many places) discourage using LLMs due to serious issues (see WP:LLM). This particular message, being entirely AI-generated without any updates to follow Wikipedia norms, also shows a lack of knowledge about how Wikipedia works. This is particularly concerning given that you are proposing changes to how we handle new articles, a discussion that occurs regularly among seasoned editors, such as those with AFC and NPP. I am further concerned about you raising this, given your recent BITEY behaviour toward new editors (e.g., [5]). You are certainly welcome on Wikipedia, and we appreciate input from new users such as yourself. However, it may be worthwhile familiarizing yourself with Wikipedia culture and behind-the-scenes work. Significa liberdade (she/her) (talk) 19:20, 21 March 2025 (UTC)[reply]
Whether it was written with AI assistance or not shouldn’t really matter—what matters is the content and whether it aligns with Wikipedia’s policies. If there’s an issue with the proposal itself, let’s discuss that.
Dismissing something just because AI was involved doesn’t address the actual topic. AI is just a tool, like a spell checker or a research assistant. If we start rejecting proposals just because they were refined with AI, we’re shifting the discussion away from what’s actually important.
Funny, you actually wrote "I like the idea" before you reverted due to another person's interaction changed your view. Maybe at first you focused on proposal which itself is important but then you become 'a nerd meme guy'. If you are not interested, there is nobody forcing you to join but I will advise you to put suggestions for greater good of Wikipedia. Sys64wiki (talk) 05:08, 21 March 2025 (UTC)[reply]
We already limit article creation to at least 10 edits. As for the rest, it's complicated and likely ineffective. CMD (talk) 02:23, 21 March 2025 (UTC)[reply]
If the concern is that enforcing guideline reading before article creation would be complicated and ineffective, that depends on how it’s implemented.
A simple 10-edit requirement doesn’t ensure users actually understand Wikipedia’s policies—many just make random edits to bypass it. If we want to improve article quality, simply displaying guidelines won’t help, because most users will click through without reading.
However, an interactive approach, like a short quiz on core policies (NPOV, verifiability, and notability), could be more effective. It wouldn’t need to be complicated—just a few key questions to confirm that new users grasp the basics before creating articles.
So, instead of dismissing the idea as ineffective, we should consider better ways to implement it rather than assuming it won’t work at all. Sys64wiki (talk) 02:30, 21 March 2025 (UTC)[reply]
No, the llm doesn't grasp that you can click through a quiz fine. Nor does the llm understand that we do want new users, or that promotional editors often aren't trying to meet quality standards. Most crucially, the llm doesn't understand the existing systems we have in place around article creation, such as but not limited to the existing 10 edit threshold. CMD (talk) 02:39, 21 March 2025 (UTC)[reply]
Its funny you are using 'LLM' to show that this is a chatbot comment, actually this is going over the discussion.
However, for the discussion, it is incorrect to say that "good faith editors (or new users)" always act as promotional editors. In fact, many new users struggle with Wikipedia’s complex policies simply because they are introduced to a trial-and-error system rather than a structured "learn and write" approach. I personally went through this phase for months, so I understand the issue firsthand.
My proposal is not about changing the existing system but improving how new users understand their expected behavior on Wikipedia—similar to how a school teaches rules and structure. This is not about blocking participation but guiding it.
That's an odd thing to a reply to a comment which was all about the proposal and said nothing about how the proposal was written? CMD (talk) 03:38, 21 March 2025 (UTC)[reply]
The we are two of us and ready to discuss real material. Actually i deleted those messages (and this will also be deleted) to remove garbage riots from a sincere topic. Sys64wiki (talk) 06:42, 21 March 2025 (UTC)[reply]
And I undeleted the material, as your deleting people who did not support you because you didn't like what they were criticizing was inappropriate. (You are free to strike through - but not delete - your own comments in those sections.) -- Nat Gertler (talk) 12:54, 21 March 2025 (UTC)[reply]
The mentoring system actually focus on trial and error and many are forceful. Such as many experienced editor uses their position as 'dictator' rather than cooperators, as I have said i have gone through this, like reverting edits without explaining or helping inexperienced about the things that are appropriate in wikipedia. Also it would be complicated for a beginner to go through mentoring system rather than a system that is available in his own homepage and wherever he visit within wikipedia {such as while making edit, creating article or influencing other people articles}. Sys64wiki (talk) 04:31, 21 March 2025 (UTC)[reply]
The Topic was about......actually, read downside discussions to understand what i am saying because this is a biographical bulk which almost all newcomer will reject to read. Sys64wiki (talk) 06:41, 21 March 2025 (UTC)[reply]
I'm referring to the general introduction that most people have, which often lacks a structured way to learn. While the mentorship program (WP:MENTOR) exists, it isn't something every new editor engages with, and it doesn't fully address the issue of onboarding.
Instead of relying on either mentorship (which is limited in availability) or just expecting new users to figure things out through trial and error, Wikipedia could benefit from a more interactive step-by-step tutorial system. This would guide new users through essential Wikipedia skills by providing structured tasks, real-time feedback, and simulated editing exercises before they start making real changes.
For example, a new editor could go through a guided process where they practice adding citations, making minor edits, and understanding policies in a controlled environment. This would help reduce mistakes, make the learning process clearer, and create a smoother experience for both newcomers and experienced editors. Sys64wiki (talk) 02:34, 22 March 2025 (UTC)[reply]
I agree, the Wikipedia Adventure had good intentions but ultimately failed due to its flawed design. It was a standalone module rather than an integrated guidance system, making it feel disconnected from real editing. Instead of helping new editors navigate actual challenges, it provided general trivia and surface-level interactions. A better approach would be a front-mode HUD or real-time interactive assistance within the editing interface. New users need practical, in-context guidance—not just theoretical lessons—so they can confidently contribute without getting lost in complex policies. Sys64wiki (talk) 03:27, 22 March 2025 (UTC)[reply]
Glad you took interest. The problem should not be how challenging but how we can implement because i am always ready to help AS MUCH AS possible. Sys64wiki (talk) 04:25, 22 March 2025 (UTC)[reply]
That seems highly impractical. Setting such a high edit threshold would discourage new contributors and create unnecessary barriers rather than improving article quality. Sys64wiki (talk) 03:11, 22 March 2025 (UTC)[reply]
I was being hyperbolic. But in reality, a new user should have been around for a spell and have gotten his hands dirty. 10 edits does not do that. Not even close. Masterhatch (talk) 04:38, 22 March 2025 (UTC)[reply]
It varies so much on the individual, though. Someone who's vaguely competent, cautious, and reads instructions can do fine writing an article after their first ten edits, especially if it isn't an especially tricky subject like a BLP, and especially if they have a little bit of help. Adding more hoops to jump through, on the other hand, isn't going to stop the POV-pushers, COI editors, and dumb people from writing bad articles sooner or later, but will dissuade the competent editors we need from jumping in. Cremastra (talk) 19:36, 23 March 2025 (UTC)[reply]
I am intrigued by the notion of a required tutorial before writing a first article. I have worked at several institutions that require all employees to take, for example, mandatory IT training to avoid phishing attacks, and these are structured much like the proposal, usually doable in a few minutes. BD2412T03:20, 21 March 2025 (UTC)[reply]
Wikipedia:The Wikipedia Adventure was mentioned by CMD. I don't know if it proved effective, or what it might have been effective at (something could be effective at teaching wikitext but not at teaching notability, and vice versa), but it didn't take a huge amount of time, and people were generally successful at getting to the end of it (or as much as they wanted to do).
I propose quiz and summarised way to propose WK:What Wikipedia is not rather than just approving a complete biography. It is actually overwhelming to read guidelines, I can assure, but would you agree that there is not any better way to work on wiki without guidelines? The quick boxes, prompts, quizzes and etc would make it much easier to understand wiki policy and we should also make a "child" article about these bulky policies for nerds.
Yes BD, I am student and I too have to face this everywhere. This ensures that you are ready to deal with things rather than coming without any prior info and making 100 mistakes. Sys64wiki (talk) 04:22, 21 March 2025 (UTC)[reply]
I think an overarching issue is that we don't intend for new editors to create articles. On the list of tasks, article creation is recommended for advanced editors--not even intermediate editors. However, many new editors want to create articles right away and then are frustrated that they run into barriers. Conversations about fixing this issue have been happening for over a decade with back-and-forth between the WMF and experienced editors who work behind-the-scenes, including those who regularly help new editors. Significa liberdade (she/her) (talk) 02:41, 22 March 2025 (UTC)[reply]
I disagree with this perspective because it contradicts Wikipedia’s collaborative nature. If Wikipedia truly did not want new editors to create articles, then why is article creation an option for them at all? Instead of discouraging new contributors, the focus should be on providing a structured pathway for them to improve their skills before they attempt article creation. If this issue has been debated for over a decade, doesn’t that suggest it’s time for a more effective solution rather than maintaining the status quo? Sys64wiki (talk) 02:51, 22 March 2025 (UTC)[reply]
Much has happened in the past decade to improve the new user experience. I have not personally been involved in conversations about improving the experience (in part because I haven't been around nearly that long), so I cannot speak to how the conversation goes. However, from the people I have spoken with about such issues, there is back-and-forth with the Wikimedia Foundation, as well as between editors, given that large changes cannot occur without community support. Significa liberdade (she/her) (talk) 02:58, 22 March 2025 (UTC)[reply]
I can't think of any better way of discouraging people from being involved in Wikipedia at all than by making required classes and quizzes. We've somehow managed to get millions of articles created without those impediments. The suggestion seems unlikely to discourage people who come here with the goal of creating the sort of article that we find problematic any more than it will those who have more appropriate intents and just need a bit of practice. Plus, with the new temporary accounts coming to replace IPs, it would effectively mean that every time someone who was not a registered user wanted to create an article, they'd have to go through all that again, even if they had ample experience. -- Nat Gertler (talk) 04:16, 22 March 2025 (UTC)[reply]
Gertler, I don’t see a strong basis for your argument. While classes and quizzes might seem unnecessary to experienced users, they can be incredibly useful for newcomers. How exactly does gaining structured knowledge discourage participation? If anything, these tools would help new users understand how Wikipedia functions more effectively. Sys64wiki (talk) 04:23, 22 March 2025 (UTC)[reply]
Putting barriers between people and the thing they want to do is a discouragement, and there are few people who say "yippee, a quiz!". Tools for learning are already available for those who want them. Making things mandatory is a discouragement for those who don't. -- Nat Gertler (talk) 04:36, 22 March 2025 (UTC)[reply]
No, you are not actually right. Since doing things in right way is a mandatory issue in Wikipedia it is also necessary to implement these things with care and in sense of learning program rather than a rule of concentration camp. I think I didn't proposed quiz as priority of this method but a kind of HUD, as we see in video games, but with such options that guide you with Wikipedia rules. This is Mandatory to guide editors to work within rules that Wikipedia allows because that will implement quick adaptations and less mess. I think this is a very simple things but misunderstood by many, what my proposal was about. Sys64wiki (talk) 05:19, 22 March 2025 (UTC)[reply]
As for tool for learning, their are huge thousand of words of guidelines that of course no beginner wants to read same as you decline to read any app's user agreement policy even though they contains potential informations. If you meant tool such as article wizard, they are tools to create article rather than any kind of rule that tells how Wikipedia works. Sys64wiki (talk) 05:21, 22 March 2025 (UTC)[reply]
Please don't use AI. I ran this through an AI checker, and it claims it was fully generated by AI
I overall agree with the idea that we need mandatory reading for every person's first new article. This helps us distinguish good and bad faith edits, and as someone who helps out creators of potential new articles on WP:AFCHELP, this will help prevent tonnes of time wasted on both ends.
@Sys64wiki Even if this was a pop up that you had to click out of, most new Wikipedians will likely just ignore it. The only real way for them to learn is to go in, find out what they are doing is wrong, fix their mistake (or get blocked). Also new users get an introduction that details all of the policies, noticeboards, etc. DotesConks (talk) 18:55, 22 March 2025 (UTC)[reply]
Gotta be honest, I ignored most of the introductions outside of the teahouse (and ones I knew previously as an IP editor), which is probably why my first several contributions were not that great, which is why I believe mandatory reading would be much better than simply "hey, you may want to read these documents". Thehistorianisaac (talk) 19:03, 22 March 2025 (UTC)[reply]
Would you please edit your proposal to be in your own voice? On the merits, it’s not a terrible idea to have a new role (like EC) that can be attained via reading and attesting to having read, notability, etc. I’m not optimistic that it would reduce the reviewer burden though. Dw31415 (talk) 21:46, 24 March 2025 (UTC)[reply]
While I don't think the questionnaire idea is going to fly, we can ask whether we can do better than now. When someone starts a new article, what they see is
You can also start your new article at Special:Mypage/WhateverTheNameIs. There, you can develop the article with less risk of deletion, ask other editors to help work on it, and move it into "article space" when it is ready.
This is out of date and can be improved. (1) There is no mention of notability. (2) There is no mention of draft space. (3) We usually do not want new users creating their articles in main space or moving their articles to main space by themselves. What the template should do is to direct them to Wikipedia:Articles for creation, where their new article will be in draft space and subject to approval by someone else. (As an aside, I wonder if the techs can display one template for new users and a different one for experienced users.) Zerotalk06:50, 21 March 2025 (UTC)[reply]
Is Draft space a better target than userspace (Special:Mypage/WhateverTheNameIs)? They achieve similar purposes, so we should probably have one or the other to keep instructions simple. The other suggestions seem sound. CMD (talk) 08:29, 21 March 2025 (UTC)[reply]
Eh, there are lots of reasons for this. I create all my articles in draft space. I often get started, thinking something is notable, then realize it's probably not or at least not yet -- or perhaps I lose interest. That doesn't mean that draftspace was the problem. Significa liberdade (she/her) (talk) 02:18, 22 March 2025 (UTC)[reply]
Your approach to the draftspace is distinctly uncommon.
The usual approach is: Create article. It's WP:UGLY but possibly notable, so someone moves it to the draft space. Very little happens after that, and then it gets semi-automatically deleted.
The more effective approach is: Create article. It's ugly but possibly notable. Leave it in the mainspace, where other/experienced editors will improve it (or they will take it to AFD to get a notability determination). WhatamIdoing (talk) 22:12, 23 March 2025 (UTC)[reply]
I've used draft space as Significa liberdade has. Draft:Rennie Garden will probably self-destruct in a few months. I don't think deliberately adding to AfD work is a collaborative default. CMD (talk) 03:09, 24 March 2025 (UTC)[reply]
Different people work in different ways. The proposal would suit someone (like me, and, I presume, the OP) who likes to read "the rules" before doing anything, but would discriminate against those who prefer to learn by doing. We shouldn't try to force people into one way of doing things. Phil Bridger (talk) 10:17, 21 March 2025 (UTC)[reply]
Well, this is what the discussion is about trying to reach newcomers through prompts and messages rather than telling him to read guidelines only after they make mistakes. Sys64wiki (talk) 12:07, 21 March 2025 (UTC)[reply]
It is worth considering that expecting people to "learn by doing" and not having a clear way for someone to avoid mistakes is probably intimidating to many potential contributors. At least that's what I've heard from many people as to why they haven't edited ("don't want to mess something up"). Elli (talk | contribs) 02:02, 22 March 2025 (UTC)[reply]
The main issue is that Wikipedia lacks clear, structured guidance for new contributors. Experienced editors and long-time article creators are already familiar with policies and workflows, so they don’t require tutorials. However, newcomers—especially those with little prior experience—find Wikipedia overwhelming due to its complexity. I don’t mean to undermine experienced editors, but their perspective often doesn’t align with that of new users. You’re absolutely right that many people hesitate to contribute because they don’t know where to start. Instead of intuitive onboarding, they’re faced with extensive guidelines that can feel more like an academic textbook than practical instructions Sys64wiki (talk) 02:31, 22 March 2025 (UTC)[reply]
Any one way is going to lose people. Folks learn in different ways, and even if there was a normal one that worked for most human beings, I don't think we can count on Wikipedia editors as being in the center of that bell curve. So we should be making multiple ways of learning available, but forcing none. -- Nat Gertler (talk) 22:25, 23 March 2025 (UTC)[reply]
(edit conflict) I prefer to learn first and do later, but I have always been told that most people learn better by doing. I'm not too sure about Wikipedia editors though, particularly ones who hang out at noticeboards. Maybe we are not representative of the general population? Anyway, there is a significant number of people that "learning by doing" does not suit. Phil Bridger (talk) 22:37, 23 March 2025 (UTC)[reply]
I was a "learning by doing" editor
First few edits were not that good, slowly learnt more and more policies
Although I think I understood the spirit of policy and guidelines early on, I'm still ocassionally surprised by the details after 63,000 edits. Donald Albury16:16, 24 March 2025 (UTC)[reply]
This proposal will just drive good faith editors away - you are forcing volunteers to jump through hoops to add content. It won't discourage spammers as there is the expectation that there employers will pay them.Nigel Ish (talk) 14:30, 23 March 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.
Special permission to create an article
WRONG VENUE
This isn't the place to request an appeal to a topic ban. Also to note, the t-ban is not appealable until six months after its enactment, which would be May. Aydoh8[contribs]14:13, 25 March 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.
Hi. I'm Pek and I'm not allowed to create new articles. However, I would like to ask for special permission to create article about web browser that doesn't yet have an article on Wikipedia. Could I just create this one article? (Please, I'm begging on my knees.) Instabridge Browser needs it's own article. There is currently no article that I could edit to add content about Instabridge Browser. I found some sources too: #1, #2 & #3. --Pek (talk) 15:17, 23 March 2025 (UTC)[reply]
Pek - looking at your profile, you have been editing for over 10 years… why are you “not allowed to create new articles”? Were your privileges removed? Blueboar (talk) 15:47, 23 March 2025 (UTC)[reply]
And, as CMD said, the browser is not mentioned or only mentioned in passing in those sources. I can't help wondering what is so important about that browser that it has to have an article before Instabridge itself does. Phil Bridger (talk) 16:56, 23 March 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.
Reviewing the use of "indefinite" page protection beyond semi-protection level, and prohibiting it for all TALK pages
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.
Understanding the need for page protection of some sort in identified controversial areas, it seems that in attempting to overcome the mayhem of more heat than light that many editors have overcorrected with very liberal use of "indefinite E-C protection" and admin protection. The due process involved in these decisions seems opaque, at least to this user. The ability to appeal such peremptory decisions is unduly cumbersome and a very uphill climb. The very idea of indefinitely protecting an article's TALK page practically excludes most Wikipedia editors from any participation whatsoever from influencing content, flying directly in the face of "an encyclopedia anyone can edit." Therefore, the notion of "indefinite" restrictions above semi-protected level should be reconsidered in general, in favor of a sunset provision (say, six months) on articles, and absolutely forbidden on an article's TALK page. Also, 500 edits seems a rather arbitrary and for newbies unreachable level of edits. Why not 200? Just asking... Kenfree (talk) 10:13, 25 March 2025 (UTC)[reply]
Happy to, Phil. I have mede several edit requests at the E-C protected page WP:Alison_Weir_(activist) page, the oldest of which is dated 11 January, and they are still languishing in the backlog as I write this reply. Efforts to interst E-C editors at WP:Teahouse have been unavailing. Surely Wikioedia users are not well served in such a case. Kenfree (talk) 13:43, 25 March 2025 (UTC)[reply]
A WP:RFC is a somewhat formal procedure, lots of rules/details. For example, "Include an initial brief, neutral statement or question about the issue in the talk page section..." You missed this part and went straight into arguing. Gråbergs Gråa Sång (talk) 10:37, 25 March 2025 (UTC)[reply]
This is merely a personal matter for User:Kenfree and doesn't require any large scale community discussion to solve it. They've been been editing en.wiki since 2011 (and still don't have 500 edits, yet). Over time they have demonstrated why they are here through their actions. In their sixth edit (2011), they characterize another wikipedian thusly: It is very difficult to accept that the editor who chose the single excerpt from the Green Book did so in good faith. In their ninth edit (2011) they complain a whole slew of late Cold Warriors are making a very unfair characterization of RT. In 2014 they edit warred on RT (TV network) and got blocked for it. On May 25, 2024 at 12:59, User:Kenfree returned after seven years to make their last mainspace edit. Since that time, they've stayed strictly on talk pages and noticeboards, usually discussing their inability to edit EC restricted topics. They turned their attention to Talk:Alison Weir (activist). They've tried to make their case (on the merits) at Help desk, an EC-protected edit request on 03:45, 11 January 2025, again at help desk on January 20, then on Teahouse to fret about how much time it was taking for an EC request to be processed. They filed another help desk request on January 27, canvassed an editor to help them on February 4, accused another of edit warring, pinged the help desk again on February 9, once again on Feb 25, and finally talked directly to an admin on March 8. Over and over it's been explained to them that if they were to put in the minimum effort (they are currently 92 edits short of 500), this wouldn't be an issue for them. They are quite interested in arguing about extended-confirmed permissions on a few contentious topics and not anything else. I'm wondering when assuming good faith for a low edit-count but longtime editor becomes merely facilitating a bad actor. All this help desk and EC banter seems to be covering up a perverse form of WP:PGAME. In any event, their desire for permissions doesn't extend far enough as to actually make effort to earn them. BusterD (talk) 13:19, 25 March 2025 (UTC)[reply]
It is just because of such lengthy ad hominems by such editors that I sometimes question the good faith of such. In all these wasted words not a single one is addressed to the concern I have raised, just one long diatribe attacking me personally, cherry picking as he goes. Disgusting! Kenfree (talk) 13:36, 25 March 2025 (UTC)[reply]
the issue here is your behavior, which is relevant to a thread you've started. i have to agree with buster that your lack of attempts to be productive and wanting to skip straight to an ec-protected page (as straight as something can be when you've been around since 2011, anyway) and then to attempting to rework how ec protection works can very easily come off as gaming the system, regardless of whether or not it actually is an attempt to do so
the important part aside, i don't think this needs reworking. there are several valid reasons to protect an article (persistent vandalism, disruptive editing, edit warring, technical stuff...), and most of them can just as easily apply to a talk page (or even the teahouse lmao). in such cases, it can then be deduced that certain types of editors are generally not trusted to handle delicate topics with the level of care that's necessary of it, and thus discussion is locked to editors who have proven that they're here to be productive (and me for some reason), be it by being autoconfirmed (at least 10 edits across at least 4 days) or extended confirmed (at least 500 edits across at least 30 days). if you really want something unprotected, you can just request it here. if the reason is deemed good enough (at least more than just "i want to edit it", for starters) and made in good faith, an admin can then unprotect it. this request, for example, is one i believe didn't meet either criterion, especially after the ensuing complaints over it being declined, and considering why it was protected in the first place. while i would discuss the exceedingly simple solution to this whole issue (that is, you editing more stuff), the current direction of the ani thread seems to suggest that i'm a little late for that consarn(prison phone)(crime record)16:27, 25 March 2025 (UTC)[reply]
If I wanted the page to be unprotected, I would have said so. I do not. What I want is some guarantee that protecting a page does not throw it into pemanent stasis. Fully or e-c protecting a page (and especially a TALK page) "indefinitely" is tantamount to locking it uo and throwing away the key...thus, my appeal for a sunset parameter on all such protections. Kenfree (talk) 18:11, 25 March 2025 (UTC)[reply]
If you (or anybody else) feels that a page no longer needs to be protected then you can request unprotection at WP:RFPP. As with all things on Wikipedia, indefinite does not mean permanent. Thryduulf (talk) 18:36, 25 March 2025 (UTC)[reply]
Ok, if indefinite does not mean permanent, then what is its endpoint? This is the whole concern I am raising: once a page is protected "indefinitely" there is no automatic review parameter, and it goes into limbo. I am arguing for the institution of such a parameter to replace the literally indefinite "indefinitely." I have suggested six months as a reasonable outside parameter on when a review should be imposed, a review open to all interested editors, not simply those already allowed to edit on the restricted page. What I am striving for here is a return to the democratic ideal that once characterized Wikipedia in its salad days: "An encyclopedia anyone can edit." Not a very limited group of editors with 500+ edits to their credit.
As I peruse the various responses here, it seems that a kind of nascent elitism is expressing itself as disdain for those editors who are not "everyday" editors. Well I am not one of those and don't expect to be...I have too many other demands on my time. I am a casual editor, and I think the record shows that from time to time, when I am using Wikipedia for research, I will make a correction or correct a typo here and there to improve readability. These good faith efforts on my part are disparaged by some commenters as "cosmetic." To each his own. If someone can point to a Wikipedia policy that privileges or shows preference for everyday editors over casual editors, please indicate here...otherwise this is a useless distinction IMHO.Kenfree (talk) 18:53, 25 March 2025 (UTC)[reply]
The end point is when protection is not required. As noted, a review can be initiated by anybody at any time by simply asking for one. Thryduulf (talk) 18:58, 25 March 2025 (UTC)[reply]
No, the issue here is NOT my behavior, the issue is whether the current tendency to, in my opinion, overprotect some Wikipedia pages (especially article TALK pages) serves the inclusivity mission of Wikipedia. You keep TRYING to make it about my behavior, but it's a red herring, and the way you have characterized my behavior, which I won't dignify with a refutation, as a strawman. Kenfree (talk) 18:59, 25 March 2025 (UTC)[reply]
i wouldn't agree that it's a red herring. as detailed by cullen in ani, you specifically bringing up this specific issue in this specific way with your specific edits under your belt (that is, the edits at alison weir, and other articles related to the israel-palestine war) implies shenanigans might be at hand (that is, promotional editing, if not outright a conflict of interest), which if proven true, would damage your credibility in this discussion. it absolutely is something worth looking into
and in the specific context of this war, i'm also 99.69% sure that going lighter on protection in pages related to it would invite some absolutely hilarious comedians (vandals) in the mood to enact their endlessly funny jokes (the exact same boring memes over and over), people seeking to right great wrongs, and general bad-faith editors to disrupt said pages even harder than usual, so that's even more of a reason to oppose it. there's also the issue of 500 not actually being all that many edits once you get the hang of things, i guess
Ridiculous suggestion. Three years ago, I lost access to this account (trashing three computers and a spell in hospital were involved). So, until I worked out how to recover my passwords, I set up an alternate account. It took me (checks notes) four days making small constructive edits to get it EC. It could have been only one day, but my stamina is not what it was. Narky Blert (talk) 15:34, 25 March 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.
Whenever I press Add topic on a semi-protected talk page(the talk page itself is protected, not the origin page) the browser crashes with error code Aw Snap SIGSEGV. This implies that the page was trying to edit a part of restricted memory. This does not happen on non-protected pages. I am using a Chromebook model name CR1104CGA updated to the latest version, and with browser version 126.0.6478.265 It seems that the computer that you are doing this on matters a lot as other computers, and even other Chromebooks do not give the same outcome. Caleb's World11 (talk) 19:39, 14 March 2025 (UTC)[reply]
I am properly connected to the internet and have no issues on other web pages.
Unable to do so, however the issue persists across multiple computers.
when the only app open is wikipedia, the crash still happens. note that I am unable to remove extensions and that this is most likely not a crash due to running out of memory.
Issue persists across restarts
Chrome is on the latest version
Unable to remove all extensions because I am using a managed computer.
Issue with editing any protected pages on Chromebook.
Hello, I have been having issues with editing any protected articles on my Barla chromebook. Whenever I attempt to edit it, it gives the "oh snap" error screen, with the "SIGSEGV" error code. I have tried shutting off my Chromebook, changing Wi-Fi, signing in and then out, clearing my cache/cookies, making sure my Chromebook version is up to date, and switching from visual to source editor. None of it worked. Some options are unavailable as this chromebook is run by an administration, so some features are not available.
I tried freeing up space, didn't work. I'm gonna procrastinate on the second one since it will be a major hassle to deal with getting everything back to order once I reset the Chromebook, since, like I said, it is administration ran. Gaismagorm(talk)18:02, 18 March 2025 (UTC)[reply]
Anyone else having issues today with randomly finding themselves logged out? Just had that happen a couple of times when opening pages in new tabs, and had it happen earlier once on Commons while uploading. - The BushrangerOne ping only00:37, 19 March 2025 (UTC)[reply]
I've been having the same issue for several hours. I'm guessing it's either a Firefox thing or something related to the SUL work. Jay8g [V•T•E] 03:42, 19 March 2025 (UTC)[reply]
This is probably the same issue that has been reported at T389159 (and maybe the same as #I need help with my Ip address? though that's a bit vague). It's probably caused by the SUL3 changes in some way or another (sorry!). Some information that would help:
your browser (and whether you use non-standard privacy/security settings, like incognito mode, an ad filter, third-party cookie blocking in Chrome)
if you have an idea exactly when this started happening
whether you are browsing multiple wikis at the same time and the behavior seems related to that (e.g. when you visit a page on wiki 1, you get logged out on wiki 2)
whether getting logged out seems to correspond with inactivity (specifically, not doing anything on a specific wiki for 5 or 10 minutes)
whether fully logging out and logging back in helps
Have Firefox (136.0.2), NoScript and uBlock Origin. There have been occasional, very very rare, instances of this for awhile but it happened "regularly" yesterday. Was happening mid-editing on single pages on Wikis - for instance opening a page from my Watchlist on en. in a new tab logged it out once. Another time I was logged out on Wikidata in between entering parameters on the same page back to back. Another time on Commons I was uploading an image, hit upload, sat uploading for a bit and then said "cannot upload because you're logged out". Seemed to get better later on though? Note that the first one described there I was logged out completely until I clicked "log in" - where I did not have to enter any data, it just logged me right back in - but all the other times simply refreshing the page saw me recognized as loggedin. - The BushrangerOne ping only22:19, 19 March 2025 (UTC)[reply]
Exactly the same, although with GoogleChrome, yesterday and today, seemingly random. Sometimes saying I was logged out, but accepting edits, sometimes not. Martinevans123 (talk) 20:31, 20 March 2025 (UTC)[reply]
Are you still having problems? I can't find any bugs in the login code (which is not saying much, it's a very complex system), and the person who first reported T389159 isn't experiencing it anymore.
If you are still being affected, do you feel we could set up a debug session with a developer where you look at things on your browser's developer toolbar (such as what cookies are set, or what requests are made) and describe them via chat or in a video meeting or similar realtime communication? It's very hard to diagnose login problems without seeing what actually happens in the browser. --Tgr (WMF) (talk) 21:43, 25 March 2025 (UTC)[reply]
Navigation
Hi,
A reader of the Oberon book asked me to add at the top and bottom of each page, navigation buttons similar to the "← previous" "↑ top" "next →" links of some Web based documents. A reasonable request and I've put two mock-ups in my sandbox. In Wikipedia the button templates work except for the style attribute. According to the table at the bottom of the button document style is available. Seems my syntax is wrong. Furthermore, the template is unavailable in Wikibooks?
In the div box mock-up, the text is linked; not the whole box. The person asking for navigation insisted the box be clickable. He noted "... really frustrating to click a box, only to find out that you have to click the link." I agree but couldn't make the markup work. Help to fix either of these arrangements appreciated. Thanks, ... PeterEasthope (talk) 18:31, 19 March 2025 (UTC)[reply]
Hello Jonesey95, appears we're at crossed purposes. The skip templates are for navigation within a page; correct? I'm interested in navigating between pages. Thx, ... 22:12, 23 March 2025 (UTC) PeterEasthope (talk) 22:12, 23 March 2025 (UTC)[reply]
@PeterEasthopeAccording to the table at the bottom of the button document style is available. Seems my syntax is wrong - you need to remove the quotation marks from the values, and "BG" is not a valid CSS selector - it needs to be "background-color". I've fixed the ones in your sandbox.
Furthermore, the template is unavailable in Wikibooks? - you would need to ask an admin on wikibooks to import it, along with all it's prerequisite templates.
In the div box mock-up, the text is linked; not the whole box. You need to replace the divs with spans, add the class "mw-ui-button" to the span elements, and move the spans inside the link markup.
Just for documentation, in case it is a bigger problem:
MediaWiki internal error.
Original exception: [c946df9e-af42-4d60-87c9-0136bcf9d82d] 2025-03-19 20:28:25: Fatal exception of type "Wikimedia\RequestTimeout\EmergencyTimeoutException"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.
Xaosflux According to my contributions, leaving a talk page message for someone who asked a Teahouse question. Even though it was an old question, it looked like something the person might still want the answer to.— Vchimpanzee • talk • contributions • 14:35, 21 March 2025 (UTC)[reply]
Original exception: [c2b93251-f505-4c5f-9026-64c87b61f28c] 2025-03-20 11:03:13: Fatal exception of type "Wikimedia\RequestTimeout\EmergencyTimeoutException"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.
I have no idea how significant this is. Went to the history of a page I'd just edited (Ming Xia), and got this error message:
MediaWiki internal error.
Original exception: [0fce64a5-248a-4907-aaa2-f2546651ae9c] 2025-03-20 22:32:02: Fatal exception of type "Wikimedia\RequestTimeout\EmergencyTimeoutException"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.
Moments later I was able to view the page history as normal. Posting here for the eyes of those who understand this sort of thing. DuncanHill (talk) 22:43, 20 March 2025 (UTC)[reply]
I had this message about 30 minutes ago. At first I wondered if it was because the editors edit had remained on my screen (I went to make a cuppa) but I've done that before, and for longer and never had that notice. It has only happened once, so far. Knitsey (talk) 20:04, 21 March 2025 (UTC)[reply]
Just happened again. Loggingthe message here. Clocked on an edit to view it and it came up with this...
MediaWiki internal error.
Original exception: [694e5180-5ffd-47ba-8b0e-ff44245737e2] 2025-03-21 21:13:21: Fatal exception of type "Wikimedia\RequestTimeout\EmergencyTimeoutException"
MediaWiki internal error.
Original exception: [e769a451-ba7d-44c9-a141-3d95e8d86266] 2025-03-22 03:10:59: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.
I got the error when going to an editor's contributions page. I did a hard refresh of the page and got the error three or four times. I went to another browser, where I am logged out, and the page worked. When I went back to my main browser, a hard refresh of the page worked fine, showing the contributions. – Jonesey95 (talk) 12:58, 22 March 2025 (UTC)[reply]
Original exception: [fd2a3012-a533-4401-9fc2-e2cc86e2f104] 2025-03-23 00:50:33: Fatal exception of type "Wikimedia\RequestTimeout\EmergencyTimeoutException"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.
In case it helps, I just hit:Original exception: [cdbe9231-712e-4418-86b1-50cd13482f3c] 2025-03-24 03:20:31: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"The rest of the message was the same as the others above. It persisted for perhaps half a minuteish. CMD (talk) 03:27, 24 March 2025 (UTC)[reply]
I got this error ([89a1c80c-8a68-426a-a142-c6d17893edd3] 2025-03-24 17:41:41) at [6]. I don't get how there is a "RequestTimeout" because it appeared immediately after I clicked "View history". 216.58.25.209 (talk) 17:44, 24 March 2025 (UTC)[reply]
Like others above, encountered the following when visiting my contributions page:
MediaWiki internal error.
Original exception: [3343407a-0463-4fe2-97c7-8026a81ccac7] 2025-03-24 23:13:07: Fatal exception of type "Wikimedia\RequestTimeout\EmergencyTimeoutException"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.
I just had this error again when I tried loading 500 revisions of an IP range, again more or less just a second after clicking, it is just a blank page with just the error message: [imgur.com]
My bot just started getting an error "invalid returnUrlToken" when it tries to edit. Anybody know what this is related to? Presumably there's been a recent change to Mediawiki, because this only started happening a few days ago. —scs (talk) 03:38, 20 March 2025 (UTC)[reply]
@Tgr (WMF): What, not scrape the web interface? Oh, don't I know it. (Over the years I've made several desultory attempts to use the API, like a regular botherd. Pretty sure now's the time to do that for real.)
Anyway, yes, checking the actual URLs is my next step, when I have time to dig into it. (My bot uses a crufty old framework that I can barely remember the details of.)
Keep in mind, oauth/bot passwords are certainly a good idea, but the main change would be to use the api vs screenscraping the webui. — xaosfluxTalk12:46, 20 March 2025 (UTC)[reply]
FWIW returnUrlToken is used for top-level autologin, a chain of redirects when you visit Special:Userlogin. It's not SUL3 related per se but there have been some small changes to its behavior recently. As a quick workaround, you can avoid autologin by setting the CentralAuthAnonTopLevel=1 cookie or the centralAuthAutologinTried=1 URL parameter when visiting Special:Userlogin. The login UI and workflow is changing in other ways, though, and will probably break your bot soon anyway if it uses web scraping. Tgr (WMF) (talk) 12:54, 20 March 2025 (UTC)[reply]
@Tgr (WMF): Thanks. For what it's worth, I tried adding ¢ralAuthAutologinTried=1 to the URL when fetching Special:Userlogin, and it successfully worked around the "invalid returnUrlToken" issue, but it left the bot not logged in at all. (Perhaps that's what you meant by "avoid autologin".) —scs (talk) 03:04, 28 March 2025 (UTC)[reply]
@Tgr (WMF):Mirabile dictu, that seems to have worked. Thank you again.
The bot is working again, for now, although I realize full well that it is living on borrowed time. If I'm lucky, I'll manage to get it rewritten to use the API before the next domino falls. —scs (talk) 00:35, 29 March 2025 (UTC)[reply]
Bottom of page overflowing into footer
The bottom of the main content of pages is now overflowing into the footer so they are rendered over categories. As I create this new talk section right now, the "Welcome to the village pump" instructions banner is rendered mostly behind the section above mine (the "i" icon is on top though). I am using Monobook theme with Chrome 135.0.7049.17. Disabling the code in my common.css did not help. I had enabled some gadgets but I can't figure out what would cause this (it's not HotCat). yutsi (talk) 22:47, 20 March 2025 (UTC)[reply]
If it's not happening in safe mode, and you've already tried disabling your own common.css, the next step is probably to start turning off gadgets and seeing when it stops happening. DLynch (WMF) (talk) 01:33, 21 March 2025 (UTC)[reply]
edit api with oauth javascript (not nodejs) (not mediawiki js) example
Hello, https://www.mediawiki.org/wiki/API:Edit#JavaScript actually is nodejs. Could you please share with me an example, that allows to auth using OAuth and create a page with content I have in my variable in JavaScript, for client-side in-browser JavaScript without involving nodejs? It will be outside of wiki page, so I won't have access to mw.utils and the like. Could you please share a few examples? (I've asked here also hoping for faster replies here.) Gryllida (talk, e-mail) 04:27, 21 March 2025 (UTC)[reply]
It looks too complicated for me, as I am not familiar with the corresponding libraries used nor with npm. I have code like this: (there actually is more, as user generated page content from a few other variables in my app, but this is the part I am having trouble with)
varpageName='Gryllida Test 2';varurl='http://test.wikipedia.org';varcontent='Hello world';
What is the code to insert afterwards to get this content added to the page with this pageName on that wiki?
After waiting a bit the error I got was "Our servers are currently under maintenance or experiencing a technical issue", though after refreshing it went back to being "Too Many Requests" again. – 2804:F1...96:5BD7 (::/32) (talk) 00:57, 24 March 2025 (UTC)[reply]
It occurs on my Windows desktop. In both Firefox and Google Chrome. My MacOS laptop sitting right next to it loads the page correctly. I am getting "Error Too Many Requests - Request served via cp5026 cp5026, Varnish XID 574968787 Upstream caches: cp5026 int Error: 429, Too Many Requests at Mon, 24 Mar 2025 04:49:34 GMT" from thumb. (Although the Mac loads the page correctly, it gets the same error from the thumb link.) Hawkeye7(discuss)04:48, 24 March 2025 (UTC)[reply]
The HTML on desktop is: <img src="//upload.wikimedia.org/wikipedia/commons/thumb/a/a5/NYTMapNeuveChapelle1915.png/270px-NYTMapNeuveChapelle1915.png" decoding="async" width="270" height="334" class="mw-file-element" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/a/a5/NYTMapNeuveChapelle1915.png/405px-NYTMapNeuveChapelle1915.png 1.5x, //upload.wikimedia.org/wikipedia/commons/a/a5/NYTMapNeuveChapelle1915.png 2x" data-file-width="480" data-file-height="593">. That means MediaWiki offers three sizes to the browser which picks one depending on circumstances. This is normal. The first two are 270px and 405px resizings which don't work for me. The last is the original upload which works for me. MediaWiki is unable to make any resizing I have tested. I guess it just varies which size people are getting. PrimeHunter (talk) 07:04, 24 March 2025 (UTC)[reply]
I've looked at them from production side. It's triggering 500 so it's very very likely an issue with thumbor. Please create a ticket against thumbor in phabricator. It can be also an issue with original file not being available in the local datacenter that thumbor is trying to access (mediawiki's implementation of swift API is known to have issues like this). Let me check that. Ladsgroupoverleg17:29, 24 March 2025 (UTC)[reply]
This image has now been repaired. Phabricator closed as a duplicate of a declined ticket. Looks like failures will have to be reported as they are encountered. Hawkeye7(discuss)04:51, 25 March 2025 (UTC)[reply]
Do archived adminship templates need to be substituted?
These are {{rfap}}, {{rfaf}}, and {{rfab}}. I'm sure that since {{subst:finaltally}} automatically fills the tally when substituted, it makes sense for that to be substituted when closing an RfA. But do the archive top and bottom templates need to be? 0xDeadbeef→∞ (talk to me) 11:17, 24 March 2025 (UTC)[reply]
Well they all have {{subst only}} on them ... I'd argue yes, because the RFA almost always doesn't change after it's closed and neither should what's on its page change due to modifications of the templates. We substitute {{Afd top}}, {{Mfd top}}, etc. Graham87 (talk) 06:06, 25 March 2025 (UTC)[reply]
Wikimedia log in
Hi. This happened once before and as I recall the answer was check back later. I am trying to reach the Wikipedia Library for a couple days. The Wkimedia log in page gives me the error: Incorrect username or password entered. Please try again. -SusanLesch (talk) 18:23, 24 March 2025 (UTC)[reply]
@SusanLesch If you use a password manager, and you have several accounts in Wikimedia-adjacent projects (e.g. something like Phabricator), double-check that it's filling in the password for the correct account. Recent changes to logins (see recent Tech News entry) have made it easier to mix them up. Matma Rextalk18:55, 24 March 2025 (UTC)[reply]
@SusanLesch Hi, we've reviewed the system logs related to logins to your account to try to get to the bottom of this. They indicate that your password was changed earlier this year. I may be able to share more details with you, but I don't think I should share them on this public page, so please feel free to contact me by email if that would help you (I have the address on my WMF user page, or you can use Special:EmailUser). As far as we can tell, this is not caused by any problem with the Wikipedia Library or with the new login system. --Matma Rex / Bartosz Dziewoński (WMF) (talk) 19:21, 25 March 2025 (UTC)[reply]
Resolved. Truly bizarre. I was able to sign in but cannot account for the failures of a well-respected password manager. Thank you for your help, Matma Rex. -SusanLesch (talk) 22:31, 29 March 2025 (UTC)[reply]
Tech News: 2025-13
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
The Wikimedia Foundation is seeking your feedback on the drafts of the objectives and key results that will shape the Foundation's Product and Technology priorities for the next fiscal year (starting in July). The objectives are broad high-level areas, and the key-results are measurable ways to track the success of their objectives. Please share your feedback on the talkpage, in any language, ideally before the end of April.
Updates for editors
The CampaignEvents extension will be released to multiple wikis (see deployment plan for details) in April 2025, and the team has begun the process of engaging communities on the identified wikis. The extension provides tools to organize, manage, and promote collaborative activities (like events, edit-a-thons, and WikiProjects) on the wikis. The extension has three tools: Event Registration, Collaboration List, and Invitation Lists. It is currently on 13 Wikipedias, including English Wikipedia, French Wikipedia, and Spanish Wikipedia, as well as Wikidata. Questions or requests can be directed to the extension talk page or in Phabricator (with #campaigns-product-team tag).
Starting the week of March 31st, wikis will be able to set which user groups can view private registrants in Event Registration, as part of the CampaignEvents extension. By default, event organizers and the local wiki admins will be able to see private registrants. This is a change from the current behavior, in which only event organizers can see private registrants. Wikis can change the default setup by requesting a configuration change in Phabricator (and adding the #campaigns-product-team tag). Participants of past events can cancel their registration at any time.
Administrators at wikis that have a customized MediaWiki:Sidebar should check that it contains an entry for the Special pages listing. If it does not, they should add it using * specialpages-url|specialpages. Wikis with a default sidebar will see the link moved from the page toolbox into the sidebar menu in April. [7]
The Minerva skin (mobile web) combines both Notice and Alert notifications within the bell icon (). There was a long-standing bug where an indication for new notifications was only shown if you had unseen Alerts. This bug is now fixed. In the future, Minerva users will notice a counter atop the bell icon when you have 1 or more unseen Notices and/or Alerts. [8]
VisualEditor has introduced a new client-side hook for developers to use when integrating with the VisualEditor target lifecycle. This hook should replace the existing lifecycle-related hooks, and be more consistent between different platforms. In addition, the new hook will apply to uses of VisualEditor outside of just full article editing, allowing gadgets to interact with the editor in DiscussionTools as well. The Editing Team intends to deprecate and eventually remove the old lifecycle hooks, so any use cases that this new hook does not cover would be of interest to them and can be shared in the task.
Developers who use the mw.Api JavaScript library, can now identify the tool using it with the userAgent parameter: var api = new mw.Api( { userAgent: 'GadgetNameHere/1.0.1' } );. If you maintain a gadget or user script, please set a user agent, because it helps with library and server maintenance and with differentiating between legitimate and illegitimate traffic. [9][10]
Not entirely sure what the technical question is, but in general.. don't wrap text, as it severely limits the flexibility of presentation on multiple devices. —TheDJ (talk • contribs) 16:28, 25 March 2025 (UTC)[reply]
Special:Homepage
Can Special:Homepage be changed on this wiki, or do we need a Phabricator ticket?
Mine currently tells me:
Your recent activity (last 60 days) - 1,000 Edits - 300 Views on articles you've edited
Infobox templates seem to push images down the page.
In Beryllium the long infobox on the right size seems to prevent any images on the left side. The result is that all the images in the page are pushed to start at the end of the infobox, far away from the content they are related to. I've seen this in other articles as well. Any hints?
Thanks! Johnjbarton (talk) 03:20, 27 March 2025 (UTC)[reply]
You can left-align images against an infobox (although probably best not to have such a long infobox). What does push images down is a right-aligned image above them. However, I'm not seeing any pushing in Beryllium, the first left-aligned image is after the infobox. CMD (talk) 05:37, 27 March 2025 (UTC)[reply]
Johnjbarton identifies a long-standing annoyance about layout, which becomes increasingly problematic as one's window gets wider. Chipmunkdavis, I think you are mis-understanding the terms "left" and "right" in this context. A "left-aligned" image is one that is on the left of the screen, not adjacent to the left edge of another floating item. The Beryllium article is a great example of that: where do you see the "Solar Activity Proxies" graph? It's not displayed in the Isotopes and nucleosynthesis section where the source actually has it. Adjusting screen-width maintains the incorrect vertical placement vs that section; editing that section itself confirms that it's not a bug in that section itself.
But it does appear to relate to image-stacking on the right, in a subtle way. If there is no image in the article that is right-aligned (other than the infobox object) prior to the left-aligned image, then the left-aligned image does display in the correct section. Does this revision display correctly for everyone? The situation seems to be that objects cannot display in inverted order compared to the source: if an File:A is after File:B in the source, layout cannot place File:A earlier than File:B. Because the metal-lump image on the right is stacked and pushed down by the infobox, the graph-image on the left that is after the metal-lump image in the source can't display any earlier than the metal-lump image. DMacks (talk) 13:58, 27 March 2025 (UTC)[reply]
Yes, the version of DMacks solves the problem with "Solar Activity Proxies", thanks!
Is it possible to not stack the right-align images? So the metal-lump image would be right of the text and left of the infobox?
I checked the Beryllium page and the sandwich is not a serious problem.
The exact words: "5. The outer top of a floating box may not be higher than the outer top of any block or floated box generated by an element earlier in the source document." If the source order is Infobox, File:B, File:A, then Template:Stack can make Infobox and File:B part of the same floating box. This enables File:A to be displayed above File:B (but not above Infobox). PrimeHunter (talk) 12:58, 28 March 2025 (UTC)[reply]
At least in the case of the Elements pages, using {{Stack}} would not be a good choice. We want the images to be next to the content, whether are left or right align to the text.
That's exactly what {{Stack}} achieves for left-floating images which can otherwise be pushed below the infobox. We don't allow your wanted layout with both a left-floated image, text, and a "right-floated" image to the left of an infobox. That would give poor results on too many screens without enough room. PrimeHunter (talk) 20:54, 28 March 2025 (UTC)[reply]
Well I'm confused. If I use "left" then things work, I don't need {{Stack}}. If I use "right" things "fail" -- meaning the images are out of position -- with or without Stack. Why do I need Stack? (I get that we don't want |Left Image| Text |Right Image| |Infobox|, but that is not what we are looking for). Johnjbarton (talk) 21:10, 28 March 2025 (UTC)[reply]
You came here for help because left did not work in [12] where the code for the plot image is in the "Isotopes and nucleosynthesis" section but the image is pushed down below the infobox. I'm saying {{Stack}} could have fixed that. You made a different fix [13] where the code for another image was moved below the plot image code. After that change {{Stack}} was no longer needed. Here is the fix with {{stack}}. I'm not judging which fix is best in this case but just demonstrating how stack works. PrimeHunter (talk) 23:37, 28 March 2025 (UTC)[reply]
Thanks! Your result is what I expected based on your explanation. It is not what we want: putting images below the infobox means they won't be with the text they are related to. It would be ok if the images where just extra stuff related to the infobox.
I think the best compromise is to Left all images that fall before the end of the infobox. Sadly this will be a continual maintenance issue and require guessing the common page width to start default/right images. Johnjbarton (talk) 00:37, 29 March 2025 (UTC)[reply]
Yes. If it helps, don't think of images and infoboxes as distinct concepts - think of both of them as boxes, or even as objects. Objects that are aligned to the left margin or to the right margin. The order in which these objects are displayed is the same as the order in which they occur in the page source. --Redrose64 🌹 (talk) 19:38, 29 March 2025 (UTC)[reply]
This URL is managed by the afdstats tool, maintained by 0xDeadbeef, Ahecht, APerson, Legoktm, Scottywong, Σ.
Perhaps its files are on vacation, or the link you've followed doesn't actually lead somewhere useful?
You might want to look at the list of tools to find what you were looking for. If you're pretty sure this shouldn't be an error, you may wish to notify the tool's maintainers (they are listed above) about the error and how you ended up here."
@DreamRimmer, @Maile66: For the first one, the logs show that the redis service on Toolforge went down, which brought the randomincategory webservice down as well. Randomincategory can take some time to load on larger categories (the one in the example has 22,000+ pages), but category contents are cached for 10 minutes so subsequent requests should be faster.
The logs for afdstats show that it was shut down and restarted twice recently, probably due to the same Toolforge server issues. It can be slow as it has to retrieve each AfD page and process it so it can take a while for someone with almost 1,000 AfDs. Somewhere on my to-do list is a future project to do some caching with that tool as well to speed it up. --Ahecht (TALK PAGE)19:21, 27 March 2025 (UTC)[reply]
Is there a way of getting overall page views per day of every article a user has contributed to?
Hi all
I've seen the pageview counter on the new HomePage feature but this only seems to be showing statistics for the past 60 days. Is there a way of seeing pageviews of all articles a user has contributed to since their account was created? For someone who has been around for a while, this could be 1000s of articles.
Hi @John Cummings, I'm the Product Manager for the Growth team, which developed the Homepage and Impact Module that displays these statistics. As far as I know, there isn't currently an easy way to view the pageviews of all articles a user has contributed to since their account was created. The Impact Module was originally designed with new editors in mind, which is why it’s limited to 60 days and only reflects a user's most recent 1,000 edits.
That said, we’ve been actively exploring ways to make the Impact Module more valuable for experienced editors, as outlined in T341599 and T388558. This includes the possibility of increasing the upper limit of the underlying query and adding additional statistics. While we can likely adjust the time period and the number of edits tracked, we'll still need a reasonable upper limit to ensure these improvements are balanced with system performance considerations.
I’d love to hear your thoughts—do you have any specific feedback on the Impact Module? Are there particular types of data that would be especially useful to you? Also, if you haven't already, you can access your Impact data directly here: Special:Impact.
I apologize if this isn't exactly what you were hoping for, but I hope it's at least nice to know that a WMF team is thinking of improvements that might help (at least partially) address this question. :) Best, -- KStoller-WMF (talk) 23:05, 27 March 2025 (UTC)[reply]
Can somebody ELIF why the action API has a choice of formatversion=1 or formatversion=2? As far as I can tell from trying both (version 1, version 2), v2 gives you the same information but in a data structure which is more complicated and more difficult to navigate. What am I missing here? RoySmith(talk)00:49, 28 March 2025 (UTC)[reply]
Following a couple of links from that page, I found mw:API:JSON version 2#Changes to JSON output format, which I think more directly answers the question, although maybe we could document the reasons for the changes in more detail. I've always felt that version 2 is the easier one to use, can you say more about what makes you feel the opposite way? Matma Rextalk09:22, 28 March 2025 (UTC)[reply]
While that link has a good summary of what the differences are, the "why" is that we wanted to clean up a bunch of odd quirks in the API output but didn't want to just break most things using the API. Thus the new formatversion parameter, so old clients aren't broken but new clients can opt-in to the new format. I'm also curious as to what you see as more complex in the version 2. Anomie⚔12:59, 28 March 2025 (UTC)[reply]
The most confusing change is adding an extra array level (see this result). After (to use python notation) result['query']['pages'], I'm left with an array of one value, so I need to do [0]. What's the point of that? If I got back multiple pages, there's no indexed way to find the one I want, so I'd have to do a linear search of all the array elements to find the one with the right pageid value. RoySmith(talk)13:11, 28 March 2025 (UTC)[reply]
There's no extra level. With formatversion=1 you'd have to do result['query']['pages']['79457898'] rather than result['query']['pages'][0]. The point of it is to have the same result structure whether you happened to receive one page or multiple pages in the response (note it's not really possible for the server generating the response to know whether the client doing titles=Foo really intended to query exactly one page or if it happened to have just one page in its array of pages to request). Regarding If I got back multiple pages, there's no indexed way to find the one I want, that's true but most queries are by title rather than pageid so clients would still have to iterate to find the one they want, and for the single-page case it allows for doing direct access by [0] instead of having to iterate or run it through some sort of values() function first. Anomie⚔13:37, 28 March 2025 (UTC)[reply]
Regarding "most queries are by title rather than pageid so clients would still have to iterate to find the one they want", I assume what comes back in the "title" slot is the canonicalized title, so I'd need to canonicalize my original search key to do that comparison? RoySmith(talk)14:51, 28 March 2025 (UTC)[reply]
Yes, but the API does give you an explanation of the normalization it did. There's a normalized field under query that you could use to translate your inputs for said iteration, without having to manually do any canonicalization via mw.Title or whatever.
I have several templates in userspace that I'd like to start using for real. However, they're not ready for general use, so need to stay where they are. This means that in order to use one of them, I have to type {{subst:user:Musiconeologist/ }} before I even get to the name of the template. Using a relative path won't help outside of my own user space, since it's relative to the page calling the template.
So, is there some variable, parser function, shortcut or similar that replaces the User:Musiconeologist part of that? So far I've not been able to find anything. Basically something that acts as a path prefix. Musiconeologist • talk • contribs14:18, 29 March 2025 (UTC)[reply]
You should not use templates in your userspace outside of your own userspace. Move them to template namespace if they are being used elsewhere. You can always edit them as and when required. —CX Zoom[he/him](let's talk • {C•X})14:25, 29 March 2025 (UTC)[reply]
Is this correct? My understanding is that you shouldn't transclude them outside of your userspace (for pretty obvious reasons), but that substituting is fine. I'll check the guidelines again, but I'm pretty sure it's something like "if you use them outside your own userspace, always substitute them". Musiconeologist • talk • contribs14:34, 29 March 2025 (UTC)[reply]
It's fine if you're substing them and the substed output is clean. User:CX Zoom apparently overlooked that part of your question. As for the original question, I don't think there's any magic to replace having to type out subst:User:Musiconeologist; the best you might do is add a user script to add your templates to the CharInsert gadget, assuming you don't have that gadget disabled and don't use VE. Anomie⚔14:39, 29 March 2025 (UTC)[reply]
Thanks! The first part of that is a relief, and the second part is as I feared. I hoped there might be a {{#me:}} parser function or something. My solution will probably be a shortcut in SwiftKey, then, but I'll investigate that gadget too. Musiconeologist • talk • contribs14:55, 29 March 2025 (UTC)[reply]
I believe {{subst:User:{{subst:REVISIONUSER}}/the_template}} answers the question, though I don't guarantee you'll find it useful. -- zzuuzz(talk)15:00, 29 March 2025 (UTC)[reply]
Seems worth a try. Maybe if I wrap it in something shorter . . . Oh but then that's in my userspace itself, with a long name. I'll play around with that, though. Thanks! Musiconeologist • talk • contribs15:21, 29 March 2025 (UTC)[reply]
When you say search, what do you mean? My understanding is that all of our searches whether of the Special:Search or the "auto displayed results" do take into account character folding (which is the special phrase for "it looks like a U so it should be a U" in search). Maybe you mean something somewhere else? Particularly, links are not red or blue based on search, they're red or blue based on whether they exist in the database, and that doesn't (and shouldn't, for a few reasons) do character folding by itself (e.g. WP:BLP concerns that we already have with people red linking names that turn blue later but it's a completely different person). Izno (talk) 20:04, 29 March 2025 (UTC)[reply]
In this case I typed into the article (in English alphabet, so u instead of ú in La República (Costa Rica) and Magon Prize instead of Magón Prize) what I assumed would be an existing redirect and placed brackets around it, and the link was red. It was very weird. I've done a bit of work in other alphabets because I work a lot on foods that are rendered in several alphabets, and I haven't had this happen before. Always, if there's an existing article, using the English alphabet finds it. But this happened twice in a few minutes. Valereee (talk) 20:14, 29 March 2025 (UTC)[reply]
So yes, your case is the second case: article text ("red link") is a check against the database and not the search system. You just found names that didn't have a redirect is all. Izno (talk) 21:22, 29 March 2025 (UTC)[reply]
@Izno, but why wouldn't La Republica (Costa Rica) automatically redirect to La República (Costa Rica) without me having to create that redirect? I apologize if I'm being obtuse, not intentional. Valereee (talk) 21:29, 29 March 2025 (UTC)[reply]
As above, they're red or blue based on whether they exist in the database, and that doesn't (and shouldn't, for a few reasons) do character folding by itself (e.g. WP:BLP concerns that we already have with people red linking names that turn blue later but it's a completely different person).
There are no automatic redirects for page titles. There are automatic redirects for namespaces - this is why we can use WP:Village pump (technical) interchangeably with Wikipedia:Village pump (technical), this is something built into the MediaWiki software and configured on a per-site basis. --Redrose64 🌹 (talk) 22:14, 29 March 2025 (UTC)[reply]
MediaWiki allows separate pages for a title with and without diacritics, e.g. José and Jose. Then I think it makes sense that the latter link would be red if the page doesn't exist. Imagine it was an automatic redirect to José. Then somebody creates a new page at Jose and the existing links suddenly get a new target. That would be confusing. And what if there is more than one potential target by changing diacritics? PrimeHunter (talk) 22:36, 29 March 2025 (UTC)[reply]
CharInsert missing on Vector Legacy (2010) edit page
Hi, this seems to be a problem only affecting Firefox as when I tried it on a different computer using Chrome or Microsoft Edge it showed up, but for some reason on my home computer whenever I try editing pages, the CharInsert bar no longer shows up. I looked it up on here but the most recent thing I could find was from 2012 so I'm not sure if that would still apply. Has anyone else using Firefox experienced this problem or is my best option right now while doing edits that need that bar, to use another browser? VampireKilla (talk) 21:53, 29 March 2025 (UTC)[reply]
In Wikipedia:Village pump (proposals)/Archive 216#Allowing page movers to enable two-factor authentication, many people advocated for other advanced and even that all used should be able to use 2FA by default. This RfC clearly asks which groups should get 2fa. This is asking for them to have the permission/ability to turn 2FA on, i.e. have the oathauth-enable right, not require these group holders to use 2fA. This will allow these users to enable 2FA themselves and not have to ask stewards at meta. Feel free to choose one or more options:
Option 1: Autoconfirmed users with a registered email
Support option 2, since that adds a basic barrier of I know what I'm doing. As said by me in the previous discussion, the responsibility and accountability of protecting your account lie on you and not WMF. Yes, they can assist in recovery, but the burden should not lie on them.~/Bunnypranav:<ping>16:13, 11 February 2025 (UTC)[reply]
Oppose 1 and 2 - what this really would do is allow people to enroll in 2FA without asserting that they know what they're doing, which seems bad. Weak oppose 6, since rollback doesn't really grant you the ability to do anything you couldn't already, so it shouldn't be a distinguisher here. Weak support the others, I guess. * Pppery *it has begun...16:45, 11 February 2025 (UTC)[reply]
Support 2 and weak support 1. We don't need to put a barrier to make sure people know what they're doing if they choose to set up 2FA. If they activate it, we can presume that they have an idea of how it works, and any consequence for their mistakes only affects them. Only weak support for 1 as the presumption of "they have an idea of what they're doing" is a bit lower for very new editors who might not be as familiar with the interface, but we can still presume that a new user finding the 2FA setting didn't do it fully by accident. Chaotic Enby (talk · contribs) 16:54, 11 February 2025 (UTC)[reply]
I was the person who made the original page mover 2FA proposal. I think that out of these groups, only file movers have a significant need for 2FA access, since that right allows for the ability to make rapid changes that could affect tens of thousands of pages (similar to template editors). However, I'm not opposed to allowing all autoconfirmed users to enable 2FA, as long as they must turn on a preference where they accept the risks of using it. This is similar to how the IP Information tool works. JJPMaster (she/they) 17:02, 11 February 2025 (UTC)[reply]
Oppose all. Despite the improved message, I'm convinced by the arguments below that the whole system is still not robust enough for casual adoption. It's true that going to meta to make a request is a small, arguably tedious hurdle, but it forces turning on 2FA to be a considered, conscious action which serves to reduce the number of people who will get locked out of their account accidentally. Thryduulf (talk) 14:29, 27 February 2025 (UTC)[reply]
Oppose all. There is already insufficient support for those who currently must or may have the WMF 2FA. The software is not yet properly supported, the planned-for upgrades are not yet complete, the documentation for the software is incomplete and not intuitive, and the only people who can turn off 2FA in case of loss of device are the very very small number of people with shell access. None of the roles listed above have the ability to adversely affect any project any more than an average user, unlike those few roles that today are required to have 2FA. Risker (talk) 19:01, 11 February 2025 (UTC)[reply]
This might sound a bit blunt, but why should WMF care so much about recovering account who lost 2FA. If a user with no email given loses their password, its their own fault, WMF need not take any responsibility it tediously recovering it. Then can try and help, but they are not liable. Also, as SD has said below, the most newbie and non-techie friendly version a 2FA app, at least on android, is Google Authenticator, which drastically minimizes risk of losing by automatically syncing to a google account. Other platforms also offer such easy to use solutions. ~/Bunnypranav:<ping>12:20, 12 February 2025 (UTC)[reply]
How many people will even take the time and effort to enable 2FA? One has to install an authenticator app (probably with cloud backup enabled by default), scan the code, and enter a verification code from the app before even turning it on. This is not something like I clicked a button and now I'm locked out account level easy to mess up; those people who manage to enable this, and lose access to it should be less than people without an email who lost the password and now did a clean start. We can advise these limited people to do the same as well (fresh start, with a CU verify if they need advanced perms early). ~/Bunnypranav:<ping>07:29, 13 February 2025 (UTC)[reply]
Trust me, a shockingly high number of people screw up 2FA. There are 2 solutions to this problem. Either a) we don't care. We put a big warning, and if you mess it up you are permanently locked out. Or b) we decide its acceptable to use a lower level of validation for unprivleged accounts. Something like we send an email and wait 7 days and unlock the account if nobody responds. This defeats some of the point of 2FA, as an attacker can now attack this weaker process, but perhaps is a reasonable compromise. It all comes down to what you want to protect against with 2FA. There is a certain sense that in practise the real thing 2FA protects against is people reusing passwords (credential surfing), because in essence its a fancy password that wikipedia chooses for you. Bawolff (talk) 12:51, 13 February 2025 (UTC)[reply]
"The software is not yet properly supported, the planned-for upgrades are not yet complete" – as far as I know, and based on ACN's comment at the last discussion, 2FA is not being actively worked on. If we are waiting for upgrades, we will likely be waiting years.
"None of the roles listed above have the ability to adversely affect any project any more than an average user" – Autopatrolled and NPP can bypass article review processes and are highly coveted by promotional scam rings like Orangemoody, which you should be very familiar with. In my opinion, these groups are, right behind governments, the largest and most organized threat to Wikipedians. Toadspike[Talk]07:48, 18 February 2025 (UTC)[reply]
Oppose I am an admin and I don't use 2FA. The reason for that is that the implementation is (as Risker says above in far more polite language that me) a pile of crap, and I don't think the devs want an ever-increasing list of people who have managed to lock themselves out. Black Kite (talk)19:13, 11 February 2025 (UTC)[reply]
Support 3–6 Like I mention in the reply below to Risker, a lot of the opposition to 2FA arises out of ignorance of how 2FA works. People seem to assume that the "multitude of commercial and free 2FA software" are incompatible with Wikimedia sites when in fact, they aren't. You can very well use Google Authenticator, Authy, Ente Auth and other 2FA apps with WMF sites – all three of these apps support syncing of your tokens in the cloud, ensuring that even if you lose your device, you can still view tokens using another device. – SD0001 (talk) 12:15, 12 February 2025 (UTC)[reply]
The real problem is the collision of two situations: (a) many end users are ignorant of how 2FA works technically, and have no idea how to properly manage their recovery codes or backup and restore anything; (b) unlike many other places you may set up 2FA, we don't have good other ways to authenticate someone to aid in helping them recover from their errors in (a), nor a support system to with cycles to do it if they could. — xaosfluxTalk23:29, 12 February 2025 (UTC)[reply]
Support all, but from what I understand of the conversation above is that it's not well-implemented. MFA/2FA is great for account security, which is why nearly every service does it. Google can enable it for every user, why shouldn't we? SWinxy (talk) 16:53, 13 February 2025 (UTC)[reply]
Google can enable it for every user, why shouldn't we? The biggest difference between Google's 2FA and Wikimedia's 2FA is that Google has approaching infinitely better support for those that are locked out of their account due to 2FA than we do, both in terms of number of options and in terms of support bandwidth. Google has multiple options available to establish identity, and literal teams of customer support people who can implement and help. Wikimedia sometimes has an email address, very occasionally has personal knowledge and very little else in terms of options, and rather than dedicated customer support people only a circa single digit number of developers who can implement and help. The difference is comparable to that between a multi-lane highway and a barely used footpath through the woods - both will get you from A to B but that's about where the similarities end. Thryduulf (talk) 18:39, 13 February 2025 (UTC)[reply]
Support 3, 4, and 5 based on ACN's comment and ToBeFree's comment, especially "there will be page movers who wouldn't request a global permission for 2FA yet would enable it in their preferences if it was a simple option", at the pagemover discussion. Autopatrolled and NPP are the most coveted userrights to scam rings and other malicious groups targeting Wikipedians. It is ridiculous that a user wishing to use 2FA has to bother a Steward to do so. 2FA is not going to get any better anytime soon, so we may as well encourage folks to start using it now and lower the barriers to doing so.
I am neutral on 1, 2, and 6. I don't think rollbackers need extra security, and while I agree in principle that most users should have access to 2FA I strongly disagree that extended confirmed = "I know what I'm doing". On the other hand, checking a box in your Preferences to activate 2FA does mean you should know what you're doing, and (assuming the explanatory pages are well-written) it's mostly your fault if you screw up. Toadspike[Talk]07:37, 18 February 2025 (UTC)[reply]
Support 2 as optional choice for EC - i see args for technical limitations and user incompetence to be strange. It should not be hard to extend a preexisting system to other users, including those seeking additional protection. Honestly, if its buried as a preference for an account, most folks won't use it. User:Bluethricecreamman(Talk·Contribs)04:46, 19 February 2025 (UTC)[reply]
If you really want 2FA you can just go to Meta and get the requisite user right freely - provided you've understood the risks involved. It would be better and easier to direct users interested in 2FA to go there, IMHO, and make that venue more visible. No need to separately enable 2FA access for a large number of users here - that's redundant, at the least. JavaHurricane23:24, 20 February 2025 (UTC)[reply]
Because we actually want people to understand the problems with the current 2FA system that Risker brings up before they get it for themselves. And if it really is a big deal to have to actually click on a link, read through a documentation page and write two lines in a request: well, what do I know. I for my part see this as a solution in search of a problem, and one that may result in users not being aware of the issues by default. And your blunt reply to Risker above is poorly thought: people can lose access to their authenticator app and security codes without any fault of their own, such as purely accidental loss of device, or a change in device, etc. It definitely is the WMF's job to care about if 2FA users can get locked out of their accounts and what should be done in such circumstances. For what it's worth, I had got 2FA for myself but had to turn it off when changing devices because for whatever reason Google Authenticator wouldn't load my Wikimedia 2FA on the new device. JavaHurricane19:30, 21 February 2025 (UTC)[reply]
If a person is signing up for a service [MFA], I guess they should be aware of the risks involved and what they're getting into? WMF should not have the job of taking care of users who just like to turn on stuff for the sake of testing it, and then lose their account. If I have to give a comparison, this is like saying you should request someone to be able to add a password to your account, because some people do not know how to save it and lose access to their account (lost password, no email set). If we can entrust saving a password to every user, why can't the same be extended to MFA? After all, it's another password. ~/Bunnypranav:<ping>07:18, 22 February 2025 (UTC)[reply]
The flaw in this analogy is that there is no way to "not have a password" or some other authorization credential and still have user accounts be a thing—there must necessarily be some credential for the computer at the other end to request, for you to prove that you are actually User:Example and not, J. Q. Random, or, another computer executing a program to guess passwords and crack into people's accounts. (And of course, as-is, people can edit without any account, subject to some restrictions.)
This in fact—no accounts—is precisely how Wikipedia was when it first began back in the primeval eons of 2001 on Usemodwiki! There are no user accounts on Usemodwiki; the site is simply world‐writable by all and sundry. "Administrative tasks" such as deleting and blocking were protected behind "the admin password": the way you originally became an admin was, you asked Jimbo on the mailing list and if he approved he emailed you the password. (Have a look at nostalgia:Wiki Administrators.)
This is the origin of what functions were originally bundled into the "administrator" package. When what became Mediawiki was first written, it essentially just copied the functions of UseMod and that distinction between "regular user" and administrator, only now with actual individual user accounts with password authentication, hooked into the Mediawiki SQL database backend. --Slowking Man (talk) 05:33, 23 February 2025 (UTC)[reply]
@Slowking Man The analogy seems wrong, but it is actually being done, IRC. Unless you specifically set a password, your nickname is free for anyone to use (Ofcourse I'm not ranting about IRC, it is an example). Same can be extended for my argument about widely available MFA in Wikimedia, like we have a password granted by default to users, why can't we give them the opportunity to get a second password (MFA)? ~/Bunnypranav:<ping>06:02, 23 February 2025 (UTC)[reply]
There is a bit of a distinction: In IRC, two clients can't both have the same nick at once. The distinction arises because IRC is a stateful protocol, while HTTP (Web) is stateless. In IRC, servers keep track of which client currently has nick X; in HTTP servers have no concept of "users" or "usernames" or "user X is currently connected to me" (a connection state), anything like that. All that, where it exists, is implemented "on top" of HTTP in the application layer via mechanisms like Web cookies. (Similarly IRC nick "ownership" and authentication are implemented "on top" of IRC—which is a very rudimentary protocol—by adding "network services" like NickServ, which are just "bot" programs that sit on the network as users with superuser powers and (in the case of nicks) kick people off a nick unless they authenticate with the password.)
The IRC case is actually quite similar to how "anonymous" users work in Mediawiki: because of TCP being stateful and connection-oriented, and IP using globally-unique "public" addresses, two clients can't both have the same IP address at once (analogy: IRC nicks). There can't be a situation where one-half of an edit from 1.2.3.4 is from one person, and the second half of the edit is from a different person on another continent. However IP addresses can be reassigned, so from one edit to the next, 1.2.3.4 can be different people.
Also, from reading others' comments, my understanding is that 2FA de facto already is available to anyone who wants it? You just have to jump through the hoop of going to Meta and asking for it. --Slowking Man (talk) 17:02, 23 February 2025 (UTC)[reply]
Also, from reading others' comments, my understanding is that 2FA de facto already is available to anyone who wants it? You just have to jump through the hoop of going to Meta and asking for it.
Yes, anyone who wants it and isn't in a 2FA group here just needs to:
Know they need to ask at Meta
Ask at Meta
Convince whoever it is at Meta that does the processing of requests that they understand the risks.
My understanding is that all that is required for 3 is:
Making the request in the right place
Stating that you have read the documentation and/or understand the risks
Not doing/saying something that makes it obvious you don't understand the risks
Apologies if I did not get it clear, IRC was just an example with no intentions to get into the nitty-gritties of the tech behind it. Since 2FA is just frame a rationale to stewards that you know what it is and what can be the risks, I proposed that everyone*(EC if option 2, autoconfirmed if option 1) have it by default, with an additional change to the 2FA interface message (MediaWiki:Oathauth-ui-general-help) to clearly indicate the risks. I believe that it should help give the opportunity to help more people to secure their accounts. ~/Bunnypranav:<ping>12:47, 24 February 2025 (UTC)[reply]
In re If we can entrust saving a password to every user, why can't the same be extended to MFA?
We entrust saving a password to every user, and people do lose their accounts this way. However, the difference is that the password works the way people expect, and the 2FA software is ...maybe not quite so likely to meet people's expectations. WhatamIdoing (talk) 19:27, 26 February 2025 (UTC)[reply]
Support > 3 provided it is optional, tbh the current defacto granting standard for oauth-testers on meta seems to be "has a pulse and/or has eyes". We are merely going to save folks a trip down to meta with this change. Sohom (talk) 04:50, 21 February 2025 (UTC)[reply]
Support 3, 4, 5 and 6 per Toadspike and TBF. Users in these groups are trusted by the community to wield advanced permissions that can do damage in the wrong hands so any argument about incompetence does not convince me, especially after MediaWiki:Oathauth-ui-general-help was updated to mention the risks. If such users want to secure their accounts with 2FA, they shouldn't need to ask anyone for it. Nickps (talk) 16:18, 4 March 2025 (UTC) 6 added on 18:52, 4 March 2025 (UTC)[reply]
On second thought, supporting 6 as well. While not as dangerous as the others, I think that a user trusted with rollback can be trusted with 2FA as well. Nickps (talk) 18:52, 4 March 2025 (UTC)[reply]
I don't think 2FA is a trust-based permission. Whether or not someone can use it is determined more by a baseline understanding of the technical risks of using it rather than trust. JJPMaster (she/they) 13:32, 11 March 2025 (UTC)[reply]
That's not what I'm saying. My point is that editors are expected to be competent. This is even more true for editors holding advanced permissions. Therefore, we shouldn't insult their intelligence by having them tell the stewards that they understand the risks before they gain access. We should just assume they do. Nickps (talk) 13:56, 11 March 2025 (UTC)[reply]
We expect editors to be competent at editing the encyclopaedia, we do not require them to be competent with poorly supported technologies with risks that are significantly greater than (and significantly different to) anything else you can casually turn on in your settings. Ensuring someone is actively aware of the risks of permanently losing access to their account is not an insult to their intelligence but a proportionate precaution. Thryduulf (talk) 14:28, 11 March 2025 (UTC)[reply]
anything else you can casually turn on in your settings There's nothing casual about enabling 2FA even if you don't have to ask the stewards for permission. It's an process with multiple steps involving at least 2 different UIs, (WP and the 2FA app). Multiple warnings are given before and during this process. If the user ignores them and gets locked out of their account because of it, it's on them to convince T&S to let them back in. Otherwise, that's a CIR global lock right there. Nickps (talk) 15:49, 11 March 2025 (UTC)[reply]
Oppose all, you can already get 2FA tester by just asking the stewards for it, and they'll just ask if you actually read the policy (ie: don't blame us if you screw up 2FA because you didn't read it). I don't think we should really need to make it easier, especially when the only support for being locked out is essentially to convince Trust and Safety/sysadmins that you're the legitimate owner of the account. EggRoll97(talk) 16:34, 4 March 2025 (UTC)[reply]
Oppose all, as the benefits basically consist of a couple fewer requests on SRP and are far outweighed by the massive backlog for T&S/sysadmins that would result. I am not convinced that occasional non-admin compromised accounts pose a major security risk. ⟲ Three Sixty!(talk, edits)16:07, 11 March 2025 (UTC)[reply]
Support 2 I've been waiting for the day when more users will be able to use 2FA. This would allow more users to be able to protect their accounts even if they don't pose a greater security risk. Extended confirmed users will know what they are doing and are far less likely to cause problems in this area than autoconfirmed users. Knowledgegatherer23 (Say Hello) 17:43, 21 March 2025 (UTC)[reply]
This would allow more users to be able to protect their accounts even if they don't pose a greater security risk. given that anybody can currently request 2FA at Meta, this won't increase the number of people able to use 2FA. Thryduulf (talk) 18:27, 21 March 2025 (UTC)[reply]
"with a registered email" isn't even an available option in this software. If someone wants this, I hope they are ready to write a patch to build it... — xaosfluxTalk19:11, 11 February 2025 (UTC)[reply]
Just noting that a lot of people already have non-WMF 2FA in one form or another. For me, it's that I need it to open my password keeper, which I need to do because I have no idea what my passwords for WMF wikis are. So I've already done a 2FA before I even log into my account. There is a multitude of commercial and free 2FA software, much of which is better supported than the WMF variant; if people are really concerned about the security of their account, they should consider that. Or not do things like use public computers or wifi in Starbucks, or choosing easy passwords; account security is ultimately the responsibility of the user. Note that I'm not kicking the WMF on this point; I know that improving this software and ensuring proper "ownership" and ongoing maintenance is very much on their radar, but there's still a lot of work to be done. We do need to keep in mind that the underlying software was created for WMF staff (at the time a much smaller and cohesive group), and it was maintained by volunteers for most of its existence. Risker (talk) 22:50, 11 February 2025 (UTC)[reply]
There is a multitude of commercial and free 2FA software, much of which is better supported than the WMF variant Please avoid spreading FUD about 2FA. There is no WMF "variant" – Wikimedia uses the same, standard TOTP protocol like most other websites. I have been using 2FA for Wikimedia and other accounts for 5 years and have never faced any issue, nor seen any difference in Wikimedia's implementation as compared to others. – SD0001 (talk) 12:15, 12 February 2025 (UTC)[reply]
My point is that many people are already using 2FA just to get to their WMF account. Having to then use the WMF 2FA on top of that adds zero security. The WMF requires the use of its own software (what I call the WMF variant) for certain permission types. It is in fact distinct from others, only a very limited number of WMF people are authorized to reset it. This is all well and good for English Wikipedia, but we are the exception. We speak the same language as the primary contacts to get things fixed. Most of the rest of the world doesn't. There is zero security or other benefit for those groups to use 2FA on their WMF account. The project doesn't benefit. The more people who use this particular extension, the more WMF resources are needed to support users who mess up. Given the non-existent security benefit for the websites, that is not good use of our resources. (And yes, I would call the one that I need for my password keeper a variant, just as I would the one I need for Google, and the one I need for two other apps I use. They may use the same principles, but they are all linked to specific functions and are only useful on that one site or group of sites.) Risker (talk) 19:01, 12 February 2025 (UTC)[reply]
We don't use the term 2FA for anything other than mw:Extension:OATHAuth – doing that would be very confusing. The WMF requires the use of its own software (what I call the WMF variant) for certain permission types. It is in fact distinct from others,... Which permission types? Which software? I don't think what you are referring to has anything to do with this proposal. – SD0001 (talk) 07:23, 13 February 2025 (UTC)[reply]
This is a bit of a pet peeve of mind, but i think we should stop telling people not to use the wifi in starbucks. While that was good advice in 2010, its not really accurate anymore (hsts preload makes pulling off a MITM attack against Wikipedia very difficult even if you are on path). As far as what you're describing with a password manager - that is very good security practise, but would traditionally not be considered a form of 2FA (arguably though the security benefits are mostly the same). Bawolff (talk) 12:34, 13 February 2025 (UTC)[reply]
Pure technical note: things like password managers are nice, but they don't add any "extra" security to your WMF account—besides encouraging you to use a better password. The password is the only thing that proves your identity as the account owner to WMF's computers, and anyone with it "is you" as far as the computers know and has total control over the account. This is "one-factor authentication": the password is the only thing, factor, needed to authenticate. Calling a password manager "non-WMF 2FA", while I understand where that's coming from, can mislead those not fluent with the concepts. The point of 2FA is that authenticating to the system on the other end, requires you to provide both of those two factors. Just the password by itself isn't sufficient. Hence if a malicious actor guesses or obtains the password, they still can't do anything with it without also obtaining access to that second factor. Analogy: something locked with two locks, keyed to different keys, so that both keys are required to unlock. --Slowking Man (talk) 21:57, 18 February 2025 (UTC)[reply]
IMO Option 1 (and maybe Option 2) should, if they gain consensus here, also require global consensus. It wouldn't make much sense for 2FA access to be automatically granted to anyone who makes a few en.wikipedia edits but restricted to advanced permission holders on every other WMF wiki. ⟲ Three Sixty!(talk, edits)15:58, 13 February 2025 (UTC)[reply]
Basically, yup. I tried to pass an RFC on meta-wiki to enable for all there, so that you would at least have to make a trip over to a non-content project and read a centralized, translated warning - but it failed to gain consensus. The lack of support is a real problem, but once someone makes it over to metawiki 2FA access is pretty much shall-issue - we mostly only check that a requester says that they read the warning. — xaosfluxTalk16:11, 13 February 2025 (UTC)[reply]
Sorry, Exxxtrasmall, but I can't make sense of either your original post or the reply above. Could you elaborate a bit, or say what you want to say in your native language and let the reader translate? Phil Bridger (talk) 13:40, 12 March 2025 (UTC)[reply]
I don't know much Portuguese (only a few words I have learnt from friends, mostly Brazilian), but I think that translates to "I prefer the second option as a native Portuguese speaker". Phil Bridger (talk) 19:10, 12 March 2025 (UTC)[reply]
Podia criar uma tabela atualizada por um bot "ranqueando" (ranking) as 5000 páginas do domínio principal com mais "thanks log" (agradecimentos em português). Exxxtrasmall (talk) 19:16, 12 March 2025 (UTC)[reply]
You're saying that you'd find it useful to have a way to see a compact list of distinct contributors to an article instead of combing through every one of the thousands of contributions from a few contributors in order to get their names? If you want to get a list of who's contributed to an article instead of a list of every contribution, that's not currently easy to do AFAIK.
Now I'm trying to think of what that might be used for. If I understand your message correctly, your use case is to thank everyone who contributed to an article? (Sorry, I don't speak Portuguese either; just attempting to understand based on French and Latin cognates.) -- Avocado (talk) 22:31, 12 March 2025 (UTC)[reply]
Google Translation: "But using articles from the main domain, not the user domain, as the Cartesian axis/vector of the main table". ―Mandruss☎ IMO. 05:57, 24 March 2025 (UTC)[reply]
I'm sorry, I can't understand what you are saying(even with the help of google translate, because it is a bit confusing). May I ask if you could please use english instead? This is english wikipedia after all. there is portguese wikipedia in case you need it. Thehistorianisaac (talk) 05:58, 23 March 2025 (UTC)[reply]
But I don't want statistics on the top contributors, I want statistics on the top bibliographies cited and/or the top articles with the most bibliographies. Calvice feminina (talk) 20:23, 23 March 2025 (UTC)[reply]
In addition to what others have said, if you're looking for the most used reference within a given article you can check the number of pointers used in the references section, though that can vary based on citation style. If instead you're curious about the most times a single reference is used in any one article, at present that would be Smith's sea fishes in List of marine bony fishes of South Africa. 184.152.65.118 (talk) 20:06, 25 March 2025 (UTC)[reply]
Or the number of times citation |title= links are followed? I doubt that would be technically possible, as Wikipedia software is not involved in the processing of clicks on links. I detect a bit of a language barrier, and Google isn't helping much. ―Mandruss☎ IMO. 06:15, 24 March 2025 (UTC)[reply]
Encouraging use of alt text in lead images
Note: prior topic name was "Mandatory use of alt text in lead images"
As someone who is active on the Fediverse, cases of persons with impaired visibility are rising, this is why I encourage everyone to read WP:ALTTEXT before adding alt text to lead images. This suggestion might be useful because without the alt text on lead images (long pressing or hovering to the lead image), how can they describe them? Ahri Boy (talk) 06:34, 14 March 2025 (UTC)[reply]
It certainly is a useful suggestion, but it should not be mandatory. We should do everything we can to assist editors and readers with disabilities. ALTTEXT is a big step forward. Spartathenian (talk) 07:06, 14 March 2025 (UTC)[reply]
I do support encouraging the use of alt text as much as possible, and having more editors familiarize themselves with WP:ALTTEXT. However, regarding making it mandatory, I'm afraid that it might be counterproductive, as not all editors know from the get-go what makes a good alt text, and might add something unhelpful instead (as I've also seen happen with short descriptions). To take Fram's example, the alt text on that picture is Tintin is standing in front of all of his friends. While technically accurate, it doesn't really match the image's function (to introduce the cast of the Tintin series), and the caption is in fact more helpful for that purpose. In that case, |alt=refer to caption could be more optimal. Chaotic Enby (talk · contribs) 09:52, 14 March 2025 (UTC)[reply]
Are you running in to situations where you have added alt text and other editors are arguing with you that there should be no alt text? What do you suggest is done for violations of this "mandatory" requirement? — xaosfluxTalk11:00, 14 March 2025 (UTC)[reply]
I would worry that too strong language would discourage people from going out and finding images, which can be quite a task.--Wehwalt (talk) 13:34, 14 March 2025 (UTC)[reply]
Personally I expect alt text on FAs and require it if I am checking them out for FA. FAs are supposed to be the best work on Wikipedia, and so should not have any identifiable deficiencies. Graeme Bartlett (talk) 20:33, 14 March 2025 (UTC)[reply]
If someone were to open another RfC on requiring alt text at FA, I would definitely support it. Honestly I'm rather surprised by the arguments that were made against it in that 2019 RfC. --Grnrchst (talk) 11:43, 17 March 2025 (UTC)[reply]
I believe the Design team has been looking at making this a structured/suggested task for more experienced users (suggested tasks are things that are evaluated while you edit the page and then make suggestions to editors) —TheDJ (talk • contribs) 12:39, 17 March 2025 (UTC)[reply]
We've actually fiddled around with it as an edit check as well, which is more of a helpful hint for newbies in terms of targeting.
Check out this userscript that I made and which is running on this patchdemo: add an image to that page, don't give it a caption, and try to publish changes -- it should show you an edit check asking whether you really want to publish something without a caption.
I made a version specifically for alt text as well -- if you look at the script you can probably see that it'd just be a minor change -- but captions are already used as an alt text fallback when there's no explicit alt provided, and the manual-of-style says that there should always be a caption and sometimes be an alt if the caption isn't sufficient. So in terms of nudges-for-new-editors, getting them to definitely add a caption seems easier to explain than walking them through "does this image also need alt text?"... DLynch (WMF) (talk) 01:28, 21 March 2025 (UTC)[reply]
Yeah, this is a good idea. We already have {{Alt text missing}} for categorizing and tracking but it doesn't render anything on the page, so it's only useful if you go looking in the category for pages that are tagged. I just threw together {{No alt text}} for a cleanup banner, but haven't made the companion category or documentation, if anyone wants to run with it. Or maybe merge it with the first one since the structure is already there. Ivanvector (Talk/Edits) 13:02, 17 March 2025 (UTC)[reply]
This could be an intriguing idea, but you will have to give a little more context and explain what you're talking about. What is meant by "more" bibliographies?, and are you referring to Bibliography sections in articles or list articles like this one? Thanks, Cremastra (talk) 23:44, 18 March 2025 (UTC)[reply]
I wholly agree. I once nominated a Bibliography article for deletion, with a similar rationale, not knowing that it was actually a type of article. Needless to say, it was kept, but I'm still not convinced they're encylcopedic. Cremastra (talk) 21:06, 19 March 2025 (UTC)[reply]
I do also agree, although I believe bibliographies can be useful – just not necessarily as article themselves. It is true that we do have non-articles in the article namespace: lists, disambiguation pages, etc. However, bibliographies can be a bit more problematic as they may easily fall under WP:INDISCRIMINATE. Some other Wikipedia editions have a separate "Annex" namespace from which we might take inspiration, so these bibliographies can still be used as resources without necessarily being under the same status as mainspace. Chaotic Enby (talk · contribs) 21:15, 19 March 2025 (UTC)[reply]
Citizendium has a Bibliography sub-page for articles that includes all sources used in the article and Further reading. Personally, I want to keep cited sources in the article, but a Bibliography sub-page would be nice for an expanded Further reading section. Donald Albury22:48, 19 March 2025 (UTC)[reply]
I previously proposed to Wikimedia the creation of a new page titled "Library" to be placed alongside the talk page. This page would serve as a dedicated space for listing the essential bibliographies. Given the impracticality of including an extensive list of references in a single article. Riad Salih (talk) 21:22, 19 March 2025 (UTC)[reply]
That's a great idea, and could be an implementation of the "Annex" namespace I suggested earlier! Looking at other Wikipedia editions, Spanish Wikipedia has a very broad view of what goes in annexes, including a lot of list material which we would most likely prefer to keep in mainspace (Portuguese Wikipedia also used to have it, although it has been deprecated due to its subjectivity/vagueness in scope). On the opposite side, French Wikipedia has a Reference namespace, which only stores different editions of a single work.I do believe that a middle ground aiming at covering bibliographies and lists of reference materials (including "Further reading" sections and {{refideas}}) could be a helpful namespace to have. Chaotic Enby (talk · contribs) 21:52, 19 March 2025 (UTC)[reply]
Set mentor status to away for other users
Sadly, sometimes Wikipedians take a break, or leave and never come back. If they were signed up as mentors, they keep getting assigned new mentees. Is there a way to set mentor status to "away" for another user? If not, this is urgently needed. I discovered this issue while looking at User talk:Bsoyka, who is currently MIA. Toadspike[Talk]10:03, 20 March 2025 (UTC)[reply]
Well, I just discovered that admins can edit Special:ManageMentors. Not sure if they can only remove mentors, or also change their mentor status. Anyone mind setting Bsoyka to "away" or removing him from the list? We might also want to check for other inactive users, or automatically set mentors who haven't edited for two weeks to "away". It is pretty bad that we're directing new editors to mentors who are not active. Toadspike[Talk]10:06, 20 March 2025 (UTC)[reply]
One can actually edit directly, by clicking on the "edit" button in the corresponding line....I tried some things (just setting on "away", but then you need to set a date, and you have to edit the welcome text). Lectonar (talk) 10:11, 20 March 2025 (UTC)[reply]
Thanks. I cannot see the history of that page, but it looks like it's worked. I feel like marking inactive mentors as "away" would be a good bot task. Toadspike[Talk]12:11, 20 March 2025 (UTC)[reply]
MediaWiki:GrowthMentors.json is some of the data underlying Special:ManageMentors. The latter is a sortable list, and admins also get two buttons on each row - Edit and Remove. The Edit feature produces a small form, that includes four or five items:
"Introduction message" - single-line text box, this sets the "Message for newcomers" column
"Number of newcomers assigned" - four-option radio, offering: None (I claim them manually); About half the average; Average (the default); About twice the average
"Is away? - checkbox: if unchecked, sets the "Status" column to "Active"; if checked, offers a further entry item
"Away until" - date & time entry (with popup calendar): sets the "Status" column to "Away until" plus this date
Changed to only the "away" status are not logged anywhere (T345272). Other changes are logged in the history of MediaWiki:GrowthMentors.json. And I've been manually marking mentors who have been MIA for ~2 months as away for a while (apparently since July 2024, although I no longer remember what made me start doing it) - Bsoyka was missed by that since he's only been gone for one month. * Pppery *it has begun...20:58, 20 March 2025 (UTC)[reply]
Hotcat for stub-sorting?
I don't know whether this is the right village pump but anyway: Hotcat is a pretty useful gadget that makes categorizing articles a lot intuitive and easier by recommending potential categories. And stub-sorting is a pretty important task too in categorizing different stubs on different subjects. So it seems weird to me that a Hotcat analogue designed to stub-sort isn't a thing. The basic principle is the same for both in that you categorize articles. Ofr how it could work, it's basically like Hotcat: Whenever this "StubCat" detects that you're on a stub page, it automatically at the end of the page but before the category list gives an option to easily add stub templates and suggest them. Seems like a pretty useful gadget to me, though I might be wrong since I'm by no means an experienced user yet. Yelps :) talk11:51, 20 March 2025 (UTC)[reply]
Hi, I started a discussion about some texts I found unclear, at least for me, regarding when we don't have to add captions. Those who are interested, please share your opinion here. Regards Riad Salih (talk) 23:59, 24 March 2025 (UTC)[reply]
Consistency in coverage of Jeffrey Epstein ties
I had brought up this issue in individual discussion pages, but the argument generally ran afoul of WP:OSE, so I was advised to take the issue up to a community level. I hope this is an appropriate venue for it.
Currently, the articles for Bill Clinton, Bill Gates, Peter Mandelson, Lawrence Krauss, Nathan Myhrvold, Steven Hoffenberg and Jes Staley have detailed sections accounting their relationships with sex offender Jeffrey Epstein. The article on Donald Trump, who also had a well-documented relationship with Epstein, has no such section. This strikes me as a clear double standard. I had suggested adding an equivalent section to Trump's article, but got shot down on the grounds of it lending undue weight to the matter and assigning guilt by association to Trump.
That may be, but if that is the case, the sections in the other articles I mentioned shouldn't have such a section either. There simply is no valid reason to treat the Epstein connection as worth reporting on for all these other people, but not in Donald Trump's article. Either an equivalent section should be added, or the sections should be removed from the other articles where it's not essential.
The double standard seems especially galling due to the inclusion of Epstein info in Clinton and Gates' articles. By mentioning the matter in their pages, but omitting in in Trump's article, Wikipedia seems to be replicating Trumpian propaganda where the Epstein associations are treated as being of huge importance for Trump's political foes, but are minimized and treated as unimportant for Trump himself. I see this as an effective breach of Wikipedia's neutrality rules, and one that needs to be corrected. TKSnaevarr (talk) 23:20, 26 March 2025 (UTC)[reply]
If you want to bring it to community level, the appropriate venue is probably an RFC, I think -- the Trump article has a lot of those -- unless you're proposing something more general than just for Trump's article, which is probably unnecessary. Mrfoogles (talk) 16:07, 27 March 2025 (UTC)[reply]
My bad, then, since I'm the one who sent the OP in this direction. But I think an RfC should be here, not at the Trump article, since it will potentially impact at least three articles (Trump, Clinton, Gates). Pardon my pesky, obsessive need for organization. ―Mandruss☎ IMO. 17:02, 27 March 2025 (UTC)[reply]
Another possible location to discuss it is WP:NPOVN or WP:BLPN (but it should be in one location, not several.) That said, my experience is that weighing articles directly against each other rarely goes anywhere constructive - even aside from WP:OCON, there's too many individual differences, both in the articles and their subjects. A more useful discussion might be to take a step back and ask what the general threshold should be for including Epstein file stuff on BLPs, at various levels of granularity (no mention / brief sentence / paragraph / subsection / full section, hopefully based on coverage levels) Making the discussion general and limiting specific focus on individuals (although some will obviously come up as examples) is more likely to produce useful results. Then, once those guidelines have been hammered out, you can turn around, figure out which articles are out of line with them, and raise that issue on their talk pages. --Aquillion (talk) 20:19, 27 March 2025 (UTC)[reply]
Is there really anything to discuss at a general level other than "follow WP:DUE" and assess whether content at issue complies with the policy? signed, Rosguilltalk23:36, 27 March 2025 (UTC)[reply]
Yes, there is - we could establish clear guidelines on what the threshold ought to be for each. For example, a devoted section could require WP:SUSTAINED coverage (eg. over the course of several months) in high-quality sources devoted solely to the subject's connection to Epstein (as opposed to just sources that mention them in passing as one of many people connected to them), or actual legal processes that sources treat as placing them in genuine jeopardy, or dedicated high-quality sourcing outside of the news media, or something of that nature. If there's sparse coverage dedicated to the figure specifically but none of the other things, it might get a paragraph rather than a section. If no coverage is dedicated to the figure specifically, and they're just mentioned in passing in larger articles, they might get a sentence or nothing. Part of the issue is that the conspiratorial thinking surrounding Epstein and many related figures makes it hard to judge due weight objectively; it also attracts many editors who are inexperienced with our processes and who therefore may feel that the simple fact that coverage exists makes a section due. Having guidelines we can point to saying "roughly this threshold" will make it easier to either decrease excessive weight where it doesn't belong, or increase it where we need more focus. And it'll give us at least something vaguely objective to use as a yardstick - otherwise WP:DUE can become highly subjective, which is a problem when dealing with so many highly controversial political figures. If you look at the figures mentioned here - Bill Clinton, Bill Gates, Peter Mandelson, Lawrence Krauss, Nathan Myhrvold, Steven Hoffenberg, Jes Staley, Donald Trump, etc - they differ wildly in how much weight the article gives them, for reasons that are simply unclear; establishing guidelines would avoid that problem. --Aquillion (talk) 13:55, 29 March 2025 (UTC)[reply]
I suspect the question, for all the Myhrholds there may be, and however responses would be phrased, would come down to Donald Trump, as if often does, whether there should be such a section on his page. Thus, my view is having another discussion elsewhere, when the Trump talk page has extensively discussed this matter, would be WP:FORUMSHOP.--Wehwalt (talk) 14:09, 29 March 2025 (UTC)[reply]
Trump is certainly an outlier, but the point is partially to avoid getting bogged down in people's opinions on highly-divisive individuals like that, and partially to escalate to a broader consensus on how to handle Epstein-related stuff about individuals due to concerns about inconsistency - it is not forum-shopping to escalate a potential problem that affects multiple articles to seek a broader consensus, which would (obviously) override any local consensuses on the affected articles per WP:CONLOCAL, and which is therefore clearly not duplicitive. That said, depending on where we set the threshold, it could just eg. result in less coverage on other articles (or more). If the problem is that we're doing it inconsistently, though (and I think there's a fair case for it), talking about broad guidelines might make people approach it more objectively and produce more constructive discussions. (Truthfully, my honest expectation is that the main thing such a review would discover is that we're probably significantly over-emphasizing Epstein stuff on a wide range of articles - for many of the listed articles it's just really hard to justify the level we have with the sources that are present. But that's an easier argument to make if we can determine rough guidelines first.) --Aquillion (talk) 14:15, 29 March 2025 (UTC)[reply]
Regarding WP:OCON, it's often cited without reading it; While consistency with other pages is not a good argument by itself, comparisons between pages are often made in order to illustrate a more substantial argument; as such, comparative statements should not be dismissed out of hand unless they lack any deeper reasoning. While relying on comparisons to other articles is generally unconvincing, articles that have been through some form of quality review—such as featured articles, good articles, or articles that have achieved a WikiProject A-class rating—are often the way they are for good reasons informed by site policy. If such articles have remained current with policy since their promotion, they are often more compelling examples to illustrate arguments. Many of the articles in question have undergone feature review, and a lot of the discussion has emphasized commonalities in sourcing that are not accurately reflected in our level of coverage, so there's an obvious deeper reasoning here. This shows that, yes, there is probably an underlying problem, which is best resolved by the sort of centralized discussion I outlined above that at least attempts to avoid getting bogged down in people's opinions about individual article subjects and instead tries to determine rough guidelines that can be used to then look back at the list of articles and confirm in a more systematic way whether WP:DUE is being properly applied. --Aquillion (talk) 14:22, 29 March 2025 (UTC)[reply]
It seems more clearly pertinent in his case, since he faced pretty substantial consequences over his Epstein accusations and was personally accused by one of Epstein's victims of complicity, which is why I didn't include his article when I wrote the OP. TKSnaevarr (talk) 22:01, 29 March 2025 (UTC)[reply]
In some articles, the infobox visually may have disregarded the cause of squeezing text with a left image, as per MOS:SANDWICH. One explanation of the disadvantage of the longing information of ibox is pushing down the image. Removing the whole short information in an ibox is a shortcut solution but MOS:INFOBOXPURPOSE mentions the purpose of providing information, or expanding too much lead in order to push down the body's text, aligning a little bit of space below the infobox, but MOS:LEAD is meant to summarize the article's body entirely, not explaining it in a superfluous way. For example, the featured article Hydrogen has a longer infobox, pushing down to two or three subsections in a section. The previous two probably worked with the 2010 Vector preference, but what about the 2020 Vector preference?
To be short, will each infobox have a collapse button, so whenever readers don't want to read the longing page, they can easily tap on the collapse button, providing a much more short summary? I was hoping this is a proposal to change the feature of an infobox in some many Wikipedia's preferences. Hopefully this is the right place to ask. Dedhert.Jr (talk) 05:13, 27 March 2025 (UTC)[reply]
Doesn't seem unreasonable, and it would solve the headache of editing in V10 and having everything look nice and then looking at your article in V22 and being horrified. Of course, this could also be remedied by the WMF not dictatorially insisting on V22 here and on more and more other projects, but we all know that isn't going to happen.
I don't know about "will", but this is certainly a "could", maybe even a "should" – and should be relatively easy to implement, given some changes to the meta-template {{infobox}}. Cremastratalk22:10, 27 March 2025 (UTC)[reply]
A recent RfC was closed with the suggestion that in six months an RfC be held on whether or not to abolish In The News. We could, of course, just abolish ITN without replacing it. However, I wonder if rather than asking "abolish ITN? yes/no" as the survey we might find consensus with "On the front page do we want a section for: In the news or X?" in a way that we wouldn't if we just discuss about abolishing ITN. Looking at some other projects things that I see on their front pages in roughly the place of ITN on ours are a featured image and information about how to participate. But I'm guessing there might be other ideas? And is this concept even a good one rather than the binary abolish/not? Best, Barkeep49 (talk) 22:51, 3 February 2025 (UTC)[reply]
I honestly think that we should revisit the two proposed amendments which were derailed by the added "abolish ITN" option. The close did find consensus against the nominated forms of the proposals though, so I'm not sure if re-asking these questions would be disruptive.On replacing ITN, we could replace just the blurbs and the title with "Current events"—the newest blurb for each category, with 2 blurbs in a category if needed. (In practice, this will probably mean armed conflicts will have 2 blurbs most of the time and occasionally another category will have 2 blurbs.) Other possible replacements include a short introduction like simplewiki, a blurbed version of Wikipedia:Top 25 Report, {{tip of the day}}, a WikiProject spotlight, and perhaps the WP:Signpost headlines. Looking at all these, perhaps Current events is the only way we can preserve the innocent Current events portal and Recent deaths... Aaron Liu (talk) 23:20, 3 February 2025 (UTC)[reply]
These suggests strike me as ways of "fixing" ITN (in quotes because I think some argue it doesn't need fixing?) rather than saying what is a different way we could use that mainpage space (which was my hope in this section). I found it interesting and not what I'd have initially thought that the closers felt abolishing was more likely to get consensus than some other form of fixing ITN as the two proposals that were on the table both had consensus against. I'm not sure what the value would be in revisiting either of those so soon. Best, Barkeep49 (talk) 16:17, 4 February 2025 (UTC)[reply]
I did talk about ways to replace the space in my second paragraph and beyond. What do you think of those?
I'm not sure what the value would be in revisiting either of those so soon.
There was a lack of discussion and engagement regarding the fixing proposals after option 3 was introduced. I have had quite a few counterarguments that weren't addressed by newer !votes repeating the previous arguments. Maybe we could just split the RfC into separate, isolated sections. We could also change the proposals to be alternate qualification routes inserted. Aaron Liu (talk) 17:31, 4 February 2025 (UTC)[reply]
Anything featured on the main page needs to be representative of the quality of work that WP can produce, so a blind inclusion from something like Current Events is very much unlikely to always feature quality articles. — Masem (t) 05:04, 5 February 2025 (UTC)[reply]
I don't agree that everything on the Main Page needs to be "representative of the quality of work that WP can produce", where what we "can" do means "the best we can do". I think we should emphasize timely and relevant articles even when they are underdeveloped. WhatamIdoing (talk) 22:48, 6 February 2025 (UTC)[reply]
In the case of articles about current events, the quality seen on ITN postings often approximates the best that can be achieved. GA, let alone FA, requires a stable article and that is simply not possible when the thing we are writing about is not stable. Obviously not every ITN post is of the same quality, but then the existence of FAR shows that not every FA is of the same quality. Thryduulf (talk) 22:54, 6 February 2025 (UTC)[reply]
Yeah, apart from TFA I really don't get the impression that any of the Main Page sections actually are showcasing particularly "high-quality" articles, but rather represent what the average reader would expect to see with any topic that has received above-average editorial attention. Merely meeting the core requirements of V, NPOV, and OR isn't "the best we have to offer", it's just the minimum we feel comfortable advertising so publicly. JoelleJay (talk) 23:19, 20 February 2025 (UTC)[reply]
ITN was set up in reaction to how well an article about 9/11 came together when that happened, and not just a breaking news article but at least writing towards an encyclopedic style. We've done similar with more recent examples such as 2024 South Korean martial law crisis or back when Jan 6 was happening. Importantly all within a few hours of the onset of these events it was immediately clear they would be topics that meet NEVENT and had long term significance, so their posting to ITN was in part that they showed clear quality including notability concerns. What's been happening far more recently is that editors are writing articles on minor news stories without clear long-term significance (such as traffic accidents that happen to have a larger loss of life), and then trying to nominate those as ITN. The problem is that in the bigger picture of NOTNEWS and NEVENT, most of those are not suitable encyclopedic topics, and because they lack the encyclopedic weight, the articles read more like news coverage than encyclopedic coverage. Thus the quality issues are compounded by both notability (for purposes of an encyclopedic) and writing style (more proseline than narrative). There is a need to address the NOTNEWS issue as a whole as it has longterm problems across the entire encyclopedia, but for ITN, we need to be more wary of that stuff. But if there is a good change the news event will have longevity, and we know similar events in the past have generally proven to be good encyclopedic articles, as the case for most commercial airplane accidents and major hurricans/typhoons, then the quality check should be to be assured that the article is moving towards what is eventually expected, but definitely does not need to be super high quality. Its far easier when we are dealing with ITN stories that involve an update to an existing article, which is where most of the recurring ITN topics (at ITNR) make sense, since quality should have already been worked on before the known recurring event occurs. Similarly, when we do blurbs for recent deaths, quality of the bio page should be very high to even consider a topic for a blurb (we get complained at alot of times for not promoting "famous" people's death to blurbs, but often this is a quality factor related to their bio page like filmographies). — Masem (t) 13:37, 21 February 2025 (UTC)[reply]
I've always liked the {{tip of the day}} concept, in order to get more of our readers to make the jump to editing. Otherwise, something as simple as moving WP:POTD up could be a "band-aid" solution, but I would certainly prefer trying something new rather than just shuffling our sections around. Chaotic Enby (talk · contribs) 17:00, 4 February 2025 (UTC)[reply]
The main page juggles a lot of tasks, but they can be boiled down to editor retention, reader engagement, and editor recruitment. Most of the main page has long been about showing off our best or most interesting work (reader engagement), and giving a sort of reward to encourage editors (editor retention). Hitting the front page requires dedication, and also a little bit of luck, which really helps with gamification of our work--and that's a good thing! Knowing that I could get something I did on the front page was and remains a major motivation to contribute. I think DYK and FA are currently perfect. If we could come up with a new stream of quality content to hit the front page, that'd be awesome, but perhaps a bit pie in the sky. If we had to replace ITN with DYK, I wouldn't lose much sleep. If we replaced it with OTD, I would want to see the OTD process reformed to encourage higher quality entries. However, that brings up the last, perhaps less frequently considered point of the front page: editor recruitment. I'd be interested to see some data on how much new editor traffic is created from articles that hit the front page. CaptainEekEdits Ho Cap'n!⚓17:17, 4 February 2025 (UTC)[reply]
I'll add the suggestions I've raised previously:
The best option in my opinion would be an "Intro to Wikipedia" box: a brief explanation of what anyone can edit means, some links to help with the basics of editing, and maybe a tip of the day as suggested by Chaotic Enby above. This might also subsume what currently exists as "Other areas of Wikipedia" toward the bottom of the main page. Editor recruitment is paramount, and something like this could help.
We could feature more content with "Today's Good Articles". This would function similarly to TFA, but instead of a full paragraph it would be a bulleted list of ~6 GAs and their short descriptions. We have over 40,000 GAs, so just those alone give us enough material for 20 years, let alone everything promoted in that time.
We could add a portal hub with icons that link to the main portals. I'm a little more hesitant about this one given the track record for portals, but I have a hunch that they'd be more useful if we gave them front-and-center attention. The current events portal has a subtle link to it on ITN, and it gets a ridiculous number of page views. There's been talk of Wikipedia's identity in the AI age, and a renewed focus on browsing could be part of that.
We could have a display for recently updated articles. This is cheating a little since it's kind of an ITN reform, but a brief list of high quality previously-existing articles that have received substantial updates based on new sources would be more useful than a list of news articles.
That's more for new content, such as newly created pages or stubs that got expanded. I'm picturing already-written articles that get large additions based on new developments. It's at the bottom of my list for a reason though, these are in the order of how viable or useful I think they are. Thebiguglyalien (talk) 17:50, 4 February 2025 (UTC)[reply]
I'm partial to the Today's Good Articles box, since I think GAs don't get enough love. Although of course a GA promotion is a DYK qualifying event, so there is some overlap. With the downfall of featured portals, I don't think portals are exactly what we want to be showing off. CaptainEekEdits Ho Cap'n!⚓18:03, 4 February 2025 (UTC)[reply]
Another idea would be a “Can you help improve these articles?” Section… each week we nominate a few underdeveloped articles and highlight them for improvement by the community. Not a replacement for draftspace or New Article patrol … for articles after that. Blueboar (talk) 18:40, 4 February 2025 (UTC)[reply]
The goal would be to highlight articles for the benefit of experienced editors who are acquainted with the topics, but may not know that a particular article (within their field of expertise) needs work. Blueboar (talk) 02:17, 5 February 2025 (UTC)[reply]
Unfortunately, most of our wikiprojects are moribund. Most no longer do article improvement drives. So why not shift that concept to the main page? Blueboar (talk) 12:01, 5 February 2025 (UTC)[reply]
This section header asks "what do we want on the front page", but "we" do not include casual readers or non-editors. Would they really want us to replace ITN with a boring "Please help out with these articles" type of box? Besides, when new people sign up to edit Wikipedia, I believe there's a feature already recommending them articles that need improvement, see Newcomer tasks. Some1 (talk) 12:13, 5 February 2025 (UTC)[reply]
Could we do GAs but on a certain topic, using WikiProjects? So for instance if you get 3 GA articles (or another number) tagged for WP:Literature, it gets added to the queue for the main page much like with DYK. If the article has multiple tags, nominator of the GA chooses which WikiProject they want it to be part of. A big benefit of this is that it could revive interest in WikiProjects and give people a common mission that isn’t just vaguely improving Wikipedia’s coverage. Perhaps the display would have the topic at the top, which would link to the WikiProject, and then the three or so articles below maybe with excerpts. Basically something that fostered collaboration, improved collegiality etc. Kowal2701 (talk) 19:51, 4 February 2025 (UTC)[reply]
There are good topics. That's an intriguing concept for me. Between good topics and featured topics there are just under 700 potential topics. That's close to two years of topics to rotate through and if we put it on the front page I can't help but think we'd get more of these made. Best, Barkeep49 (talk) 22:18, 4 February 2025 (UTC)[reply]
We might have 365 days x 20 years of GAs listed at the moment, but if we don't resolve the fundamental disagreement about whether the Main Page can offer links to imperfect content, then we're just replacing "Get rid of ITN because it has so many WP:ERRORS" with "Get rid of GA because it has so many WP:ERRORS".
One of the things that seems to surprise folks is that GA is literally one person's opinion. There's a list of criteria, and one single, solitary editor unilaterally decides whether the article meets with the listed criteria. The most important criteria are largely subjective (e.g., "well written") and therefore something editors can and do disagree about. Most reviewers aren't especially knowledgeable about the subject matter, and therefore they will not notice some errors or omissions. In other words, while GAs are generally decent articles, a critical eye can and will find many things to complain about.
IMO people either need to decide that imperfect content is permissible on the Main Page (and thus quit complaining about how other people have sullied the perfection and ruined our reputation), or that imperfect content is not permissible (and thus get rid of everything except featured content). WhatamIdoing (talk) 05:27, 5 February 2025 (UTC)[reply]
I'm not sure where the WP:ERRORS thing is coming from, because that's not at all why there's such widespread dissatisfaction with ITN. You're also saying that a system that promotes GAs to the main page wouldn't work despite DYK doing exactly that for years. Thebiguglyalien (talk) 05:57, 5 February 2025 (UTC)[reply]
One of the persistent complaints about ITN is that the articles aren't Wikipedia's finest quality. This complaint is also leveled against DYK entries, sometimes including GAs. WhatamIdoing (talk) 06:21, 5 February 2025 (UTC)[reply]
Not sure where GAs come in in all of this. If anything, GA quality is the least controversial thing about DYK, with complaints usually centering around misleading blurbs or recently created articles of mediocre quality.Our threshold for ITN/DYKNEW quality is way lower than GA, and it doesn't really follow that GAs would have the same quality issues. Lumping GAs alongside ITN/DYK issues as "imperfect content on the Main Page" is oversimplifying the situation. Chaotic Enby (talk · contribs) 10:24, 5 February 2025 (UTC)[reply]
WAID is correct in saying that with GAs, "one single, solitary editor unilaterally decides whether the article meets with the listed criteria" (see Talk:I-No/GA1 for example). The quality of GAs are subjective, the same way the quality of ITN/DYK, etc. articles are. Some1 (talk) 12:21, 5 February 2025 (UTC)[reply]
One of the persistent complaints about ITN is that the articles aren't Wikipedia's finest quality: I don't think many are expecting finest. Are there example threads? ITN is already an editing drive of sorts to meet WP:ITNQUALITY. —Bagumba (talk) 08:39, 7 February 2025 (UTC)[reply]
However, I wonder if rather than asking "abolish ITN? yes/no" as the survey we might find consensus with "On the front page do we want a section for: In the news or X?" Why ITN vs [X]? What if editors want to keep ITN and replace another section on the main page such as DYK with something else? Any future RfCs regarding the potential removal of ITN from the MP should initially and explicitly ask whether editors want ITN removed or not (a "binary abolish/not?" sort of question). We could also go the more general, less ITN-focused route and ask the question you just asked in the heading: "What do we want on the front page?" and in that RfC, provide multiple options, such as ITN, DYK, OTD, TFA, [and any new ideas that people have]; then have the community choose their favorites or rank the choices. Some1 (talk) 00:44, 5 February 2025 (UTC)[reply]
I like both the "learn to edit" and "good topics", but given the appalling deficit of editor recruitment on the main page, the former is my decided preference. Cremastra (talk) 00:39, 5 February 2025 (UTC)[reply]
If we are going to remove it we shouldn’t replace it with anything, there isn’t anything else that won’t have just as many problems as ITN. PARAKANYAA (talk) 04:01, 5 February 2025 (UTC)[reply]
I am very opposed to that idea. It's just not main page type content. No matter what we put on the main page it should be showing stuff, not begging/pleading for more editors. PARAKANYAA (talk) 18:17, 5 February 2025 (UTC)[reply]
I looked at page views being driven by the Main Page, using the list of recent deaths from mid-December (the latest data in Wikinav). https://wikinav.toolforge.org/?language=en&title=John_Fraser_Hart is a typical example. Most of the page views for that article came from the link on the Main Page. This makes me wonder whether the question about "What do we want on the front page?" should be interpreted as "What 'categories' or 'departments' do we want?" (e.g., a box dedicated to WP:GAs) vs "What purposes do we believe the Main Page should serve?" (e.g., helping readers find the articles they want to read). I think that ultimately, no amount of rearranging the deck chairs is going to solve the fundamental problem, which is that we need the community to decide whether the Main Page is only for WP:PERFECT content, or whether the Main Page is for WP:IMPERFECT content, too. WhatamIdoing (talk) 05:15, 5 February 2025 (UTC)[reply]
One of the more common positives of Wikipedia that RSs bring up is the speed and neutrality with which it covers even contentious current events topics. I would say that ITN does reflect the best of Wikipedia in a sense, even if the exact process needs revamping. -- Patar knight - chat/contributions06:36, 5 February 2025 (UTC)[reply]
I agree, and apparently our readers agree, too. Current events are one of the places where we shine – some of "the best", just not always "the most polished". WhatamIdoing (talk) 22:51, 6 February 2025 (UTC)[reply]
This is not meant as an idea to replace ITN, but the top box on the main page is extremely sparse compared to any other Wikimedia project page. The top box should serve better as a welcome box to WP for any incoming link so should feature a search bar, links to the key pages about how to contribute to WP, and other similar links. The closest info for that is buried near the bottom of the current main page. --Masem (t) 05:18, 5 February 2025 (UTC)[reply]
The search bar is at the top of the page. I do think it would be helpful to add at least a more explicit sign-up link or something. We already advertise that anyone can edit, which is sort of an WP:EASTEREGG link to an introduction page, and the number of editors. -- Patar knight - chat/contributions06:41, 5 February 2025 (UTC)[reply]
You know what I'd love? Some widget that features articles on topics from around the globe. Maybe a map with a promoted article for each country, with irregular turnover (so that Burundi isn't expected to have the same frequency of front page-worthy articles as France does). The promotion could be handled by each country's wikiproject ꧁Zanahary꧂22:49, 11 February 2025 (UTC)[reply]
Would love to see something done with WikiProjects. Even if ITN is kept, just get the featured list segment to budge up and introduce a new one Kowal2701 (talk) 23:05, 11 February 2025 (UTC)[reply]
They're such a great idea—obviously, people will be more motivated to contribute to Wikipedia if they feel they have a community of other active editors passionate about the same topics as them. But they're totally out of reach for inexperienced editors, and the space for that valuable and enticing discussion is tucked in the talk pages of projectspace pages. ꧁Zanahary꧂23:24, 11 February 2025 (UTC)[reply]
Also, I second calls for some feature showing articles that are trending or the top viewed for a certain period. It's one of the unique features of Wikipedia that we can stay up to date on new things. ITN does a more flawed and complicated job at this than a trending module would. ꧁Zanahary꧂01:51, 6 March 2025 (UTC)[reply]
The ITN process often responds to new stories by motivating a rapid effort to improve relevant articles as quickly as possible. I believe the same would happen for the top-viewed articles. ꧁Zanahary꧂03:14, 6 March 2025 (UTC)[reply]
But on ITN, the articles have to be improved to a certain quality before they are on the main page. Quite a bit of the most viewed articles would fail ITN for quality. Without an actual nomination process or "risk" of the article not being featured, there's way less motivation to improve the articles. Aaron Liu (talk) 14:12, 6 March 2025 (UTC)[reply]
Maybe then, there can be a buffer wherein articles are not featured until they meet a quality greenlight. I think it would move fairly quickly, since highly-viewed articles often have a lot of eyes on them to begin with. ꧁Zanahary꧂14:37, 6 March 2025 (UTC)[reply]
I don't think ITN is really more flawed than a traffic analysis, unless your goal is a traffic analysis. ITN (in my opinion) isn't just for what's being read about, but also about historically significant events happening in the world -- like the end of the Gaza ceasefire, and civil wars starting, and stuff like that. I've found out a bunch of interesting stuff over time, that I wouldn't have noticed just from a "Top 25 articles" list that mostly centered around celebrities and movies that are coming out. Mrfoogles (talk) 02:58, 20 March 2025 (UTC)[reply]
second, Random Article just generally bigger and better;
I remember some nights just smashing on the random button article, it was great fun and I wasn't depressed
On English Wikipedia, the amount of informative articles; e.g. some historical figure, concepts, buildings etc. i would get was fairly low compared to German random articles, (I just tried that again and I hit warhammer 40k and Monsters Inside me, these are tier A hits for me) but I thought someone could make a filter: I want to read a random article, but it has to be say about 16th century polish history or only articles with keywords plants+south america, or music related but not mexico, full random but in English or French
third, Moving Text
I see that the main page is meant to be lean and clean and non-distracting, but this is the 21st century, at least we need a (lean and clean) 90s moving text banner, better-yet an RSS feed that I can sync to my Divoom (hey look which article is missing) even better: you make your own little informative reading screen I can put on my wall.
fourth, The News
i don't see whats wrong about the news at all (other than it is likely a lot of work) and agree it is best to feature high quality articles over sloppy or hastily established singular-event articles, especially regarding Wikipedias high standard on sources and citations
I would also use a section with "random article under some filters" -- there are too many random sportspeople in the random article selector currently. Mrfoogles (talk) 02:59, 20 March 2025 (UTC)[reply]
An Android app screenshot from 2023
The Featured Picture would be a natural replacement for the ITN top right slot on the desktop view. Having a prominent picture at top right is our standard look and the featured picture is a logical complement to the featured article.
Otherwise, to see other existing possibilities then try using one of the Official apps. The Android app provides the following sections:
Featured article
Top read (daily most-viewed articles)
Places (nearby articles based on the current location)
Picture of the Day (from Commons)
Because you read (suggestions based on a recently read article from your history)
In the news
On this day
Randomizer (a random article with some filtering for quality)
Suggested edits (suggestions to add content to Wikipedia)
And what's nice is that you can turn these sections on or off in your settings to customize the feed.
I'm probably biased an as involved party at ITN, but I really don't think doing away with ITN is a worthwhile idea. As much as it has it's issues, I don't think we have proof that non-editor readers (aka the majority of readers) are displeased with ITN. Understanding that getting sentiment of non-editor readers is hard (see the discussion on Vector 2022), I feel like we should try and find out more about what the larger readerbase thinks before doing anything drastic with ITN. For what it's worth, I'm not moved by many of the replacement proposals. I think having a box directly about active goings on in the world is a useful and interesting feature for the main page, which contrasts with how the other three top boxes work. I interact a lot more with ITN's hooks than any others on the Main Page. DarkSide830 (talk) 18:01, 6 February 2025 (UTC)[reply]
ITN doesn't show the active goings on in the world in a fair way. It provides a slanted overview based on the (often death-obsessed) fascinations of editors who camp out there. This does a disservice to readers if not outright misleads them. This is why people who write content on Wikipedia apply policies on original research and balanced proportions. We follow the lead of reliable secondary sources instead of holding our judgement above them. Thebiguglyalien (talk) 18:20, 6 February 2025 (UTC)[reply]
I'm not convinced that your assertions are true, but "original research" is irrelevant (ITN is a navigational element, not an encyclopedia article) and if you wanted to apply the concept of "balanced proportions", it would be judged against today's headlines, not against secondary sources. WhatamIdoing (talk) 22:59, 6 February 2025 (UTC)[reply]
To be fair, nothing on Wikipedia is perfect, including our own policies and guidelines. Getting rid of ITN because of perceived problems feels like throwing the baby out with the bathwater. If you have ideas for improving ITN, you can always suggest them at Wikipedia talk:In the news. Some1 (talk) 04:07, 7 February 2025 (UTC)[reply]
See, that's where the two of us just disagree. I'm not entirely favorable to current posting policy, but I really don't believe it's as substantial a problem as you do. DarkSide830 (talk) 17:17, 7 February 2025 (UTC)[reply]
@DarkSide830, I think you're right that it's hard for editors to get information about non-editors. If we wanted some proper user research, we could talk to the WMF about having their UX researchers do this. It's February, which means now's time to make requests for their next fiscal year. WhatamIdoing (talk) 22:55, 6 February 2025 (UTC)[reply]
Thanks. It was just a bit slow to load (to be expected for such a high-traffic page), but it's working now.
If you were at the Main Page last month, the most popular articles to click on were:
Deaths in 2025 (by a lot – about 5% of outgoing clicks were to this page, and 30% of the people reading that page arrived there by clicking the link in the Main Page)
All this tells me is that ITN's distortion of due weight is even worse than we thought and it's irresponsible of us to do nothing. Why in the name of God should "guy drives truck into crowd" and "building burns down" be presented as main entries in an encyclopedia when they're just poorly written rehashes of news stories? Sure, the main page isn't an article so WP:BALANCE doesn't apply. No, this is a different form of the same problem that's worse by several orders of magnitude and doesn't have a corresponding policy to fix it. Thebiguglyalien (talk) 15:42, 10 February 2025 (UTC)[reply]
This is not what the original research policy means. Synthesizing information and drawing original conclusions is disallowed. Summarizing and collecting information from various sources is the entire point of the encyclopedia. Mrfoogles (talk) 03:02, 20 March 2025 (UTC)[reply]
I think the right question is "Why shouldn't we help readers find the pages they want to read?"
I think the wrong attitude is "What's wrong with our readers, that they want to read those kinds of articles, when they could be reading articles of no immediate relevance or interest to them, but which I think are more worthy subjects for an encyclopedia?" WhatamIdoing (talk) 22:17, 10 February 2025 (UTC)[reply]
If I may make a bold statement, this ban on an article sourced only to primaries, just like the GNG requirement for multiple sources, is over-strict enforcement of the letter of a rule that should correctly be treated as broad guidance. An encylcopedia covers so many different topics that it is difficult to make content policy that seems relevant and reasonable in every subject. And that's why WP:Nis a guideline, not a policy. But we have a tendency to treat it as if it is unassailable gospel, even when it honestly doesn't make sense. Try telling someone not overfamiliarized with WP policy that the 2000-word article they wrote based on five sources doesn't merit inclusion in the encyclopedia because although all the sources cited are reliable, three of them are primary; the fourth, while secondary, might not be independent and in any case doesn't have sigcov as it was only used to cite tangential facts; so really it's only the fifth source counting to GNG so we'd better delete this article, hadn't we?; and also, no, you absolutely can't cite the length of the article as a reason to keep, go see WP:ASZ, you fool; why should we pragmatically do what is helpful to people? I'm just here to enforce Wikipedia guidelines (as policy). And the more this becomes common, the more this becomes standard. I have certainly made AfD nominations where if it was up to my own discretion, I'd keep the article, but as a new page reviewer I feel obligated to follow the guidelines. And there's the problem: I don't doubt I'm the only person to have reservations of this kind (the primary-source rule I especially object to as awfully arbitrary), but the practice of treating WP:GNG (or one of the SNGs) as near-dogma is now so entrenched that everyone is expected to treat it that way. And we do. I do (although I'm going to try not doing so).
Primary source stuff is just another aspect of this underlying problem. Why can't we source an entire article to primary sources? 'Cause it says so in policy, that's why. Well, what if it's a good article? What if it helps people? What if it improves our encyclopedia? The response is: it says so in policy. You shouldn't invoke IAR in deletion discussions. (Apparently it's a cop-out; I mean, if have all these rules, why'd we want to skip them?).
I don't think news articles are primary sources. Any article that isn't mostly based on secondary sources is going to suffer from a ton of bias with things that may as well be lies, which is why we get GNG. But on a related note, I've always found the prohibition on "routine coverage" such as funding announcements to be incredibly weird. Aaron Liu (talk) 12:33, 11 February 2025 (UTC)[reply]
Any article that isn't mostly based on secondary sources... in some topic areas. Some consider a research article a "primary source", but it would be absurd to force species articles, for example, to include secondary reviews of those sources. Cremastra (talk) 13:32, 11 February 2025 (UTC)[reply]
Literally every non-editor I've talked to about the Main Page (like 10+) has said they only visit it to see what's in the news and, to a lesser extent, what the featured article is (or at least that, if they find themselves on the Main Page, the only things they click are ITN and TFA). My impression is that they see ITN as an extremely filtered selection of "the most important things happening around the world". JoelleJay (talk) 00:11, 21 February 2025 (UTC)[reply]
Whatever we may end up doing, I just propose that the replacement for ITN (1) is dynamic and (2) is not more DYK. Per above, the same quality arguments against ITN can be applied to DYK for non-GA noms. But more importantly I just think that the replacement needs to be a dynamic module that changes daily to keep readers engaged. Most of the proposals so far have satisficed that aside from the "introduction to editing" and "portals" idea. ✈ mike_gigstalkcontribs19:52, 6 February 2025 (UTC)[reply]
But more importantly I just think that the replacement needs to be a dynamic module that changes daily to keep readers engaged: There's nothing inherent at WP:ITN that mandates that the content cannot change more frequently. New people can begin participating at ITN to help make it happen, countering current regulars that value significance more. —Bagumba (talk) 08:52, 7 February 2025 (UTC)[reply]
Front‽
Hah!
Neither Google nor Bing, nor anyone pointing to Wikipedia for some reason, have taken me anywhere near it in decades.
And none of the people who print Wikipedia into books and YouTube videos ever include it.
Whatever you do to it, though, it's probably best not to replace it with things from Project:Community portal, which is there for the potential editors in project space as opposed to the potential readers in article space.
Whereever one may go when it comes to the content quality rules, the "main page" being article content as opposed to project content still remains as a distinction.
Hence why I said "drastic". However, it is article content. If it weren't, we wouldn't be having all of these discussions about how it should be the best example of our article content, or whether it should satisfy our Wikipedia is not a newspaper article content policy, or whether (if it is exempt from policy, a huge double-standard given everything else on the main page) it should be more like a real newspaper rather than an obituaries column. (Only 2 death notices, as I type this.)The best response to that question is to ask where, in amongst the DYK snippets from articles, the featured articles, the featured pictures, the snippets from the almanac pages, and the featured lists, does the questioner see the non-article content that leads xem to think that it isn't chock full of article content. It's a good question to ask why it's in article space, given that clearly it doesn't have to be and almost none of the ways in which Wikipedia gets re-used ever use it. It's not a good question to argue from the premise that it isn't article content, though. I wonder how many people really have, or whether that's been phrased as a straw man.Uncle G (talk) 13:19, 10 February 2025 (UTC)[reply]
That's almost certainly bogus, since the $wgMainPageIsDomainRoot setting is turned on for Wikipedia and the sidebar hyperlink is not nofollow for starters. Notice how things are very different for the Wikimedia App, where one has to deliberately choose to go to the main page. Also notice that TopViews excludes the main page alongside excluding other things in the sidebar.Are people really still making the "the main page is what people primarily see of Wikipedia" argument? Not since the search engines started putting individual Wikipedia pages in sidebars on their search results, it isn't. I cannot remember who first shot that argument down by pointing that simple reality out, but it was almost a decade ago, shortly after Bing started doing it if memory serves. The most viewed page in January 2025 was really, and unsurprisingly, Donald Trump.Uncle G (talk) 13:19, 10 February 2025 (UTC)[reply]
Obviously yes it does to all of the other people still making the long-since fallacious "the main page is what people primarily see of Wikipedia" argument, and clearly mike_gigs thinks that it matters. You are trying to have it both ways, now.I think that everyone should recognize that this argument from supposed popularity is fallacious, and has been for a decade. It's a lot of fuss about a page that actually not nearly as many people read as the bogus statistics, that the TopViews tool has been excluding for all this time, imply; and it's long since time to more strongly shoot down the "But it's our public face and our most-viewed page!" fallacy.Our public face for January 2025 was the Donald Trump article, which was also part of our public face for 2024 per Project:Statistics#Page views.I really would like to remember who made this argument all of those years ago, so I could give proper credit. Xe was right. I think that most of the people who concern themselves with the Main Page would find that if they ever stopped being involved in those processes, as simple readers like all of our other readers nowadays they would almost never go to it in the first place. Then perhaps discussions about what belongs on it would be less fraught and more relaxed.Mind you, the flip side is that discussions about the Donald Trump article would be even more fraught. ☺Uncle G (talk) 09:51, 14 February 2025 (UTC)[reply]
I'm just pointing out that you are incorrect by saying nobody sees the Main Page, just because you haven't been anywhere near it in decades. And you calling the statistics bogus doesn't change them at all. We won't ever know how many people who land on the Main Page actually look at it, but saying that none of them look at it so we shouldn't even bother with this conversation is absurd.
The clickstream data for January shows that, even counting only the top ten most common destinations there were over 2.5 million (2,508,183) instances of people clicking on links on the main page (not including the search) and collectively links on the main page were clicked over 34 million times in that one month (I don't think that includes the search). 31.5% of the views of Deaths in 2025 came from people clicking the link on the main page. This clearly demonstrates that your (Uncle G's) assertion that nobody views or interacts with the main page is the one that is fallacious. Thryduulf (talk) 17:44, 14 February 2025 (UTC)[reply]
not to rack up clicks. Wikipedia is not about page views I mean, we have GalliumBot notifying "nominators when their [DYK] hooks meet a certain viewcount threshold." Some1 (talk) 23:30, 18 February 2025 (UTC)[reply]
Then you need to think about it a bit more. The writers of TopViews did, back in 2015. The people who wrote about unintentional views at Project:Popular pages did, too, as did the people who came up with meta:Research:Page view and the Phabricator bugs tweaking all that for the PageViews and TopViews tools. Uncle G (talk) 09:51, 14 February 2025 (UTC)[reply]
I don't see anything written to explain why, though. I'm guessing the argument is that readers usually use the main page to search for things. But even in that case, readers do see what is on the main page, especially the graphical content on the top. Not to mention the countless social media posts about main page content. If you know something else about the main page, could you elaborate? Aaron Liu (talk) 14:37, 14 February 2025 (UTC)[reply]
I think the idea is that most people aren't going to the Main Page for its own sake. There are presumably some who want to know what the TFA is, but for the most part, people go to the MP so that they can get somewhere else, and not for the purpose of reading the MP itself.
Thinking of my own behavior, I end up at the MP several times a day, usually because I want to search for an article whose title I don't know. An empty page with a Special:Search box would be equally effective for me. (If I know the title, I'll just hand-edit the URL to go straight there.) Maybe once a month, I might drop by to glance at the TFA or ITN (not counting when I check the MP due to a discussion on wiki). A couple of times a year, I might glance at DYK. But mostly, if I end up at the MP, it's for a purpose other than reading the MP. If readers are like me (hint: That is not usually a valid assumption), then the "page views" for the MP are not representative, and the MP should be treated like a transit hub instead of a destination. Sure, sometimes a student will go to Grand Central Station to look at its artwork or its architecture. But most of the time, people are going through there to get to their real destination. WhatamIdoing (talk) 22:46, 19 February 2025 (UTC)[reply]
I naturally go to the main page several times a day either because I'm opening the site from a shortcut in a browser or because I click on the globe icon to get to a standard start point in the site. Having gone to the main page, I will naturally tend to browse it.
The number of people who browse the main page on a given day seems to be about 100K. I say that because that seems to be about the peak readership for articles when that's mainly driven from the main page. Featured articles get the most attention with about 50K views while ITN articles get about 20K readers from the main page and DYKs get about 10K.
These numbers aren't huge but they are better than nothing. If you've written or improved an article then it's nice to get some attention and comment. A problem with just writing an article that's reasonably complete and competent is that you usually get little feedback. The main page thus provides a good showcase for such work and so helps motivates editors. This is not a problem.
ITN is not such a good driver of editing because articles such as Donald Trump have been written already and are often battlegrounds or needs lots of fixing up. The focus at ITN then seems to be on gatekeeping rather than editing and this is why it's not as productive as the other main page sections.
While the effort level needed would be much, much higher, making our DYKs into short-form videos could actually be an interesting idea. Probably not on the Main Page itself (at least at first), but it could be an interesting side project. Chaotic Enby (talk · contribs) 14:51, 16 March 2025 (UTC)[reply]
What about a set of featured outlines? We could have symmetry with the featured article/featured outlines, and they're a really good way to find stuff to browse if you're interested. Their main problem is honestly that they're obscure and sometimes hard to find. This would solve that. I actually think ITN should be kept, but it would be cool to add this to the main page. Mrfoogles (talk) 19:56, 22 March 2025 (UTC)[reply]
I like this idea in general, but Chaotic Enby is right that we have too few. Even with a heavy focus on them going forward, we still won't have enough for a dedicated section for quite a while. If we were to work on them and get them working—which I'd be willing to help with—it might be viable to include them as Today's Featured List features, or to have a today's featured outline appear once a week on a day when there's no featured list. I think we'd need a better sense of what a featured outline actually looks like first. Thebiguglyalien (talk) 🛸20:31, 22 March 2025 (UTC)[reply]
We don’t need any changes and should not try to implement them. It’s a lot of work maintaining the front page as it is without trying to include a how to edit tutorial, a custom daily featured video, a game where you feed a wikipetan tamagotchi, a social media feed, a playlist of lo-fi beats to study/chill to, stock market analytics, top 10 most popular articles, a personalized article recommendation feature, an overstimulation feature, a widget management widget… Dronebogus (talk) 09:07, 26 March 2025 (UTC)[reply]
We only need one thing, and to properly discuss the question of replacing ITN in an RfC we need to have ideas of replacements. Keep in mind the significant amount of option 3 !votes we had. Aaron Liu (talk) 11:24, 26 March 2025 (UTC)[reply]
I don’t think it should be abolished; I think it should be limited to things that have obvious worldwide notability even if routine (national elections, major multinational sporting events) or are of once-in-a-decade notability (new tallest building in the world opens, outbreak of war, global pandemic, first manned mission to Mars, etc.). Right now there’s too many “thing crashes, people die” events (tragic but routine and without obvious immediate impact) or things that seem arbitrary (why do some media personalities get a headline when they die while others end up in the “recent deaths” box?) Dronebogus (talk) 14:51, 26 March 2025 (UTC)[reply]
I know, I also oppose replacing it and I wanted a stricter version of option 2. But the next abolishing proposal must have things to replace it with. Aaron Liu (talk) 14:54, 26 March 2025 (UTC)[reply]
The simplest option would be a minimalist “ongoing events/recent deaths” ticker, since the former usually only has one or two major wars, the Olympics, and stuff like the COVID-19 pandemic and the latter has such lax standards of inclusion I don’t think it’s really controversial. Dronebogus (talk) 15:03, 26 March 2025 (UTC)[reply]
I missed the opportunity to support closing ITN, which is a shame, but in its place, a list of "Currently popular pages" or "Pages being read" section with a list of the week's most popular pages, class icon, the short description of the page and the number of pageviews of the previous seven days. It would, naturally, include some of the articles that currently appear at ITN but would actually reflect reader numbers. If it can be automated to exclude the main page, non-article pages (such as redlinks, disambig pages, etc) and anomalous entries, then it could be a runner. - SchroCat (talk) 15:58, 27 March 2025 (UTC)[reply]
That is someone's opinion, not holy writ. A well-phased introduction to the section would point out that "as this is 'the encyclopaedia that anyone can edit', many of our articles are works in progress, including possibly those in the list". If we slavishly stick to the line of "quality", much of the ITN and DYK product would be barred by virtue of the relatively low quality of some of the product that gets shown. - SchroCat (talk) 14:15, 28 March 2025 (UTC)[reply]
But ITN and DYK still have a quality standard. As long as it's quality enough; but just showing all the most popular pages would not have such a barrier. Aaron Liu (talk) 14:16, 28 March 2025 (UTC)[reply]
So? What's the problem with that? If we're honest and open about it, I don't see a problem with showing what people actually want to read - it seems better than falsely pretending it doesn't exist.Much of the output of DYK and ITN is poor, regardless of the purported "quality standard". Acknowledging the most popular pages seems a reasonable step: people—a lot of people—are looking at those pages anyway, regardless of their condition. At least if we have a 'top read pages' on the front page, we get to set the context of it being a work in progress and I think that's more likely to get people editing than anything else currently on the MP. There is already a lot of quality product being pushed with FAs, FLs and FPs; this simply reflects existing reader preferences. - SchroCat (talk) 15:24, 28 March 2025 (UTC)[reply]
I don’t really see the benefit of having what is, essentially, a “trending” section. It’s dangerously evocative of the sort of social media-derived enshittification that ruined Fandom. The appeal of the main page, including ITN and DYK, is that it’s curated to cut out the faddish crap and automation that plagues the rest of the internet. Dronebogus (talk) 17:01, 28 March 2025 (UTC)[reply]
Straw man argument that misrepresents what is shown on the top 10 or top 25 pages. There's more than enough popular culture being pushed through DYK to put paid to the thought that the content is somehow "curated". It's really not. - SchroCat (talk) 17:10, 28 March 2025 (UTC)[reply]
The point of DYK is to highlight articles that will literally never get read otherwise and inject some levity into Wikipedia’s dry encyclopedic content. You just want to direct people to the same articles they’re already reading. Isn’t that the job of the search autofill? Dronebogus (talk) 17:16, 28 March 2025 (UTC)[reply]
DYK is solely for editors to show off their GAs on the front page. It's certainly not anything for the benefit of readers, and may contain levity only once a month at best.It's crass misrepresentation to claim this is to direct people to what they are already reading. Demonstrating to readers what the most read articles of the previous seven days are will partly reflect what was at ITN but not what we think they should read. It you want to force a narrow remit of certain types of article onto the page for people to ignore, we become out of touch with the readership and just continue to offer the same stale third hand news that they've picked up off the BBC, CNN, Fox or wherever, but we mangle it and write it in a poor fashion compared with the professional output. (And you have zero idea what I "want", so don't even try to guess). - SchroCat (talk) 17:24, 28 March 2025 (UTC)[reply]
I don’t know why you were so offended by my remarks even if they were a misinterpretation. My only point was that your proposal seems redundant. Everything on the main pagr is non-neutrally curated, primarily for the benefit of editors. Featured articles (which are 90% niche topics your average reader doesn’t care about) are picked by hand. So are featured lists and images, and “on this day” entries. Readers don’t acknowledge and don’t care about any of these things unless it’s something shocking like when The Human Centipede (First Sequence) was a featured article. Dronebogus (talk) 17:33, 28 March 2025 (UTC)[reply]
Your thoughts about what readers want are an opinion that carries zero weight (much like mine or anyone else's): it's pointless guesswork because no-one has bothered to ask them. We know by pageviews that things like the TFA are popular (despite what you may think) and that holds true for some other parts too, but with so much curated content being pushed, why is there no space to reflect what the reality of reader choice? Why are you so afraid of allowing readers to see a slimmed down version of [Wikipedia:Wikipedia Signpost/2025-03-22/Traffic report this] instead, or is that something that you need to be in a secret editor club to see? - SchroCat (talk)
Readers dont care about quality, which for the main page has always been the minimum requirement to be featured. Readers also favor pop culture and Western topics over any other field (easily seen when looking at TOP25), and catering to what is effectivley the lowest common denominator is not a sign of how we want WP to be developed. Of course we can feature popular culture topics on the main page, but these should be curated against articles of academic, scientific, and historic significance. Masem (t) 18:21, 28 March 2025 (UTC)[reply]
For parts of the MP "quality" is only a passing acquaintance, rather than anything of serious note. ITN and DYK are often far from any decent measure of "quality". You can decry what readers want to read as much as you want, but having a MP that focuses on quality in addition to reflecting current read patterns seems a stronger offering that the second rate dross that is often pedalled, under the misleading claim that we are putting out "quality" product, when we're really not. We currently have curated articles of academic, scientific and historic significance and unfortunately it shares the MP with ITN and, to a lesser extent, DYK (which is largely a vanity project). Swapping out the poorly written stale third hand news section would be an excellent start, but I see no problem in adding the reality of reader interest in its place (not necessarily physically - it could go on a different part of the page if FLs or FPs are moved up into the top right-hand corner). - SchroCat (talk) 18:50, 28 March 2025 (UTC)[reply]
You’re not really addressing the issue raised by me and Masem that featuring the top 25 most viewed articles is only going to lower the quality standard on the main page which you claim to care so much about. Dronebogus (talk) 19:16, 28 March 2025 (UTC)[reply]
I have dealt with it at least a couple of times, but you may have missed them (even though one of them in was the comment you fist replied to). Firstly, so what? People are reading these articles anyway, but we get to set some the context of it being a work in progress by having a well-phased introduction to "as this is 'the encyclopaedia that anyone can edit', many of our articles are works in progress, possibly including those in this list". Given we have enough quality on the front page, honestly pointing out that not everything they read is of such a high standard is no great loss. There's actually more of a chance that people will start editing by clicking onto an article that needs work than if they click onto a piece of featured work. There's not going to be any real lowering of standards, just a more honest and open acknowledgment of our overall product. - SchroCat (talk) 19:29, 28 March 2025 (UTC)[reply]
But you aren’t pointing out any quality deficiency that’s perceptible to lay-readers. Most people who read blindly trust Wikipedia, or at best complain about it without doing anything. Most people who “edit” just want to right great wrongs. Even most people who edit constructively only fix extremely obvious issues like typos and grammar mistakes, and those are mostly on articles nobody visits. Dronebogus (talk) 19:39, 28 March 2025 (UTC)[reply]
Yes, we are. By showing the class of article in the list and stating the articles are works in progress that's just what we're doing (and many of those will be in better shape than the third-rate "news" articles that TN pushes out with no warnings about them being low standard). This isn't the thread to complain about how people decide to edit WP, so I'll ignore the further straw men. - SchroCat (talk) 19:44, 28 March 2025 (UTC)[reply]
I missed that part about the WIP stuff. I like it, but I worry no-one will read it let alone apply its message. And I still don’t like the idea of what is essentially automated content on the MP. Dronebogus (talk) 20:11, 28 March 2025 (UTC)[reply]
Most of it will still be of higher quality than the "curated" stuff and have the additional benefit of being things people are actually interested in, rather than a patronising idea of what someone thinks they should be reading. - SchroCat (talk) 20:13, 28 March 2025 (UTC)[reply]
I question how the top 25 articles is really a meaningful improvement over ITN; it’s essentially identical but worse because it’s biased towards celebrities and recent movies topically and hugely biased towards the Core Anglosphere and India geographically. At least with ITN and DYK I might learn something I didn’t already know and not have my view of the world narrowed to whatever the internet hive mind is thinking this week. Dronebogus (talk) 20:36, 28 March 2025 (UTC)[reply]
It’s obviously not identical, so that’s yet another straw man. You’ve already expressed you opposition the idea, you don’t need to keep finding different ways of saying the same thing as you’ve not convinced me to change my mind one iota, and I’m ambivalent about trying to change yours. - SchroCat (talk) 20:41, 28 March 2025 (UTC)[reply]
LLMs are now useful in their ability to generate encyclopedic-like material. Quite rightly Wikipedia heavily limits bot/AI editing. It is not possible to make use of LLMs within those bounds, and the bounds should not be loosened to accommodate LLMs. So how can the power of LLMs be harnessed for the benefit of Wikipedia without undermining well-established and successful processes for developing content?
I believe it would be useful to add a 3rd tab to each page where AI generated content either from human activity or bots could be posted, but clearly distinguished from other discussion.
On the (existing) Talk page, an appropriate response to lack of engagement to one's proposal is be WP:BOLD.
However, on the AI-Talk page the default response must be to resist editing. This would allow human contributors to check proposed AI based edits for value and encourage or enact them following normal Wikipedia guidance. However, if no human editors engaged with the AI proposal then no harm would be done because no edit would be made without such engagement.
The approach I propose allows the wikiepdia editing community to organically determine how much effort to put into making use of AI-generated content, and in doing so may make clear what kind of AI involvement is helpful. DecFinney (talk) 15:38, 21 February 2025 (UTC)[reply]
Wikipedia will not, and will never implement AI slop content. We are one of the few places left on the internet that haven't embraced this corporatized, overhyped technology and most people firmly intend to keep it that way Mgjertson (talk) 16:08, 21 February 2025 (UTC)[reply]
@DecFinney: No. AI has a known problem with blatantly making things up and is incapable of actually assessing sources. You're proposing to include a section which by default is going to be filled with junk to the point people will just blatantly ignore it to avoid wasting their limited time. (On a related note, I recently had to help assess a fully-AI-written draft; aside from the usual tells the reference list included cites to two books that did not exist.) —Jéské Courianov^_^vthreadscritiques16:24, 21 February 2025 (UTC)[reply]
A few years ago we had an article suggestions system, but for human rather than AI suggestions. One of the reasons why it failed, and was predicted to fail from the outset, is that we are primarily a community of people who want to write and correct an encyclopaedia, with an emphasis on the first part of that. Hence we have to have measures such as quid pro quo at DYK, and a bunch of watchlisting and other systems to encourage our volunteers to play nice with others who add cited info to their work. We find it easier to recruit volunteers who want to write than volunteers who want to check other people content. Before we take on a scheme to create loads of content suggestions for our volunteers to check and integrate into articles, we need to find a way to recruit a different sort of volunteer, someone whose favourite task is checking and referencing other people's work. Otherwise we have a scheme to make Wikipedia less attractive to our existing volunteers by trying to distract them from the sort of thing they have volunteered to do and instead direct them into something they find less engaging. Worse, like any attempt to organise Wikpedians and direct them towards a particular activity, we undermine one of the main areas of satisfaction that editors have, the autonomy that comes from choosing which tasks they want to undertake. That isn't to say we can't have AI tools that make Wikipedia a better place, but we need to find ways that work with the community rather than against it. That said, I'm currently testing some typo finding AI routines, and I think there is some potential there. ϢereSpielChequers22:13, 21 February 2025 (UTC)[reply]
Thanks for such a thought-through reply. Ultimately, I don't think having an AI-Talk page would require that anyone change how they currently interact with editing Wikipedia (nobody has to use the existing Talk page). Therefore, I don't think the feature would act against the community except indirectly through the potential for wasted effort/resources. The Ai-Talk page would be there for those that were interested.
Nevertheless, you make some good arguments that this kind of feature is not one likely to be well-used by existing users.
You also make me think about how such an approach could lead to an overly homogeneous style to Wikipedia articles. I'm not sure everyone would consider this a bad thing, but I do think that could be an unfortunate consequence of using AI-generated content. DecFinney (talk) 14:38, 22 February 2025 (UTC)[reply]
Maybe an AI talkpage would be treated differently than the normal talkpage. But we have a lot of editors, and many of those who write content are the people who are hardest to engage with proposed changes to the features. I'm thinking of the proverbial person who spends an hour or to a month checking some articles they watch. I suspect a lot of those editors would feel they had to respond to the AI talk as well, otherwise eventually someone would change the article with an edit summary of "per AI talk" and they'd feel they lost the opportunity to point out that the paywalled sites they have access to take a very different line than the fringe sites that are free to access. ϢereSpielChequers18:24, 22 February 2025 (UTC)[reply]
Absolutely not. It is a terrible idea to let the junk generators (and possible WP:BLP violation generator) loose on a page that, let's be real, is not going to be closely watched. We do not need a graveyard of shit attached to every article. Gnomingstuff (talk) 23:45, 21 February 2025 (UTC)[reply]
@Jéské Couriano @Gnomingstuff - The proposed AI-Talk page is a self-contained space for proposed content that has involved AI-generation. The default is that no edit to the article can be made unless human contributors permit it (i.e. they would not be "loose on a page". Therefore, I don't understand what you are afraid of. If you are correct and AI-generated content is never good enough, then it would not be used. If I'm correct in thinking that at times AI-generated content may be useful in improving a page, then it would be used in such cases, while poor AI-generated content would be left to archive on the AI-Talk page.
My impression from your responses is that either: 1) You're worried Wikipedia's human editors are not capable of effectively using AI-generated content from an AI-Talk page, or 2) You're scared that in some cases AI-generated content may actually prove good enough to improve Wikipedia articles and therefore be used.
Just to note, that various safeguards could be put in place that would deal with most of the tangible concerns you raise, e.g. no AI-Talk page for featured articles, no AI-Talk page on WP:BLP, possibly only allow registers users or users with advanced experience to view and use the AI-Talk page. DecFinney (talk) 14:54, 22 February 2025 (UTC)[reply]
I don't really understand what the proposal is trying to do. Is the idea to have an AI evaluate all ~7million articles? If so, how frequently? If anyone wants AI feedback on a particular article, they can input the current version of an article into their AI engine of choice. This is possible without any of the work needed to add a whole new area to en.wiki. CMD (talk) 15:11, 22 February 2025 (UTC)[reply]
I imagine, that in the same way that people make bots that make direct edits to pages, their might be useful tasks that bots could do but which are too subjective and risky to allow direct edits. Instead they could post to AI-Talk, to allow a check of what they are doing. What tasks AI bots were allowed to contribute could still be constrained but there would be more opportunity to explore their potential without doing direct harm to a page. In summary, I don't have a prescribed view of what would be undertaken, it would be dependent on what bot develops would look to address and the constraints on that agreed by the Wikipedia community. DecFinney (talk) 09:49, 24 February 2025 (UTC)[reply]
I understand what and where this page is proposed to be. Your impression is wrong. My response is:
3) I am concerned -- with good reason -- that AI-generated content produces false statements, and that when they are applied to real, living people, those false statements are likely to be WP:BLP violations. There is no way for a human editor to "effectively" use false statements, and there is no point at which they are "good enough." The problem is that they exist in the Wikipedia database at all.
As such, the BLP policy is that we need to be proactive, not reactive, in not inserting BLP violations anywhere, and should remove them anywhere they come up -- including on talk pages and project pages, which are still pages. So, one way to be proactive about that is to not do something that risks them accumulating on largely unmonitored (but still visible and searchable) pages.
@Jéské Couriano @Gnomingstuff - Thanks both for the follow-up. I am a physical scientist, I don't engage much with BLP side of Wikipedia but I appreciate it's a major component and I see your concerns. I don't see why there couldn't be a ban on AI referring to BLP, and no AI-Talk page on BLP pages. In which case, LLM's would still be able to benefit the non-BLP parts of Wikipedia.
@Jéské Couriano - Regarding falsehoods, I consider LLMs to have moved on a bit in the last year. They certainly do hallucinate and state things falsely at times (I don't deny that). But they are much more accurate now, to the extent that I think they possibly don't make more mistakes than humans on small bits of certain kind of text (I don't claim they could usefully write a whole article unaided, as things stand). That said, I think you are potentially acknowledging the fallibility of humans as well as AI in your "20+ years of this shit" statement. In which case I respect you point regarding not wanting "an accelerant" -- I would probably agree. DecFinney (talk) 09:57, 24 February 2025 (UTC)[reply]
In re LLMs used in BLPs, WP:Biographies of living persons pretty much precludes hosting any amount of inaccurate/unsourced claims anywhere on the project (except for discussions of those claims and how to source them, if at all possible). This would include any AI-talk userspace. AIs' tendency to hallucinate would just make a lot of mess that would need a lot of cleanup when - not if - they Vergheze v. China South Airlines particularly controversial/outrageous claims, such as accusing a sitting legislator of involvement in assassinations.
In re accuracy, and speaking from experience (I recently assessed a completely AI-generated and -sourced draft), AI is utterly incapable of assessing sources, especially sources that are scanned printed books or otherwise inaccessible to the AI. Two of the sources provided in the draft were hallucinated, and the other two didn't come within a light-year of supporting the claims they were used for. Source assessment is one of the most, if not the most, important skills for an editor on Wikipedia to have, and based on what I saw with this draft - which I and other helpers wasted 45m on just trying to verify that all the sources existed - there is no chance in Hell that AI output as it stands right now is ready for this sort of scrutiny.
Even if/when AI gets better, there are already loads of places where readers can get an AI summary of the subject (for example, the top of a Google search - and I'm quite sure Google will continue to improve their use of the technology). The world needs an alternative place, a place which gives a human-written perspective. It may or may not be better, but it's different, so it complements the AI stuff. My strong feeling is that Wikipedia should avoid AI like the plague, to preserve its useful difference! In fact the best reason I can think of to provide an AI tab is so that there is somewhere where people who really, really want to use AI can stick their stuff, a place that the rest of us can steadfastly ignore. In effect, the extra tab would be a sacrificial trap-location. Elemimele (talk) 18:04, 25 February 2025 (UTC)[reply]
I respect this point of view, and may even agree with it. However, I wonder if the wider global population in such a future is likely to continue visiting Wikipedia to any significant extent. And if not, then would editors still feel motivated to maintain such an alternative place?
I know you are probably jesting, but I do see the AI tab for human proposed edits that have a amajor AI comoponent, as well as bot generated proposed edits. So my suggesting is consistent with your proposed use of the AI tab :D DecFinney (talk) 10:08, 26 February 2025 (UTC)[reply]
It was a very early development of LLMs that they can be forced not to discuss certain topics. Since a list of topics off-bounds could be produced, I still do not see BLP has meaning LLMs could not be used on non-BLP topics. I understand your arguments but I think either you don't understand that, or disagree that, LLMs can be constrained. Either way, I respect your disagreement but I feel like we are now going round in circles on this particular point. I am happy to agree to disagree on it.
I see your experience and impression of AI-generated content. It is familiar. Nevertheless, I have experience that LLM-generated content is at times effective, though it still requires human engagement with it.
I agree with your point around "source assessment" being key, and agree that AI is not good at this. I do, however, think AI has been steadily improving on this skill over the last year. Though it is still not good enough. DecFinney (talk) 10:16, 26 February 2025 (UTC)[reply]
Even if you constrained the LLMs, contentious topics are broadly construed, and as such include discussions and sections on pages otherwise unrelated to the contentious topic. (To use a recent example, Sambhaji falls under WP:CT/IPA, WP:RFPP/E does not, and a request for Sambhaji on RFPP/E falls under WP:CT/IPA.) You would likely have to hand-code in every single article that is under a contentious topic - which I'd estimate to be at or around 1 million (and I'm low-balling that) - which becomes more and more untenable due to tech debt over time, either due to new articles being created or CTOP designations lapsing (YSK, HE) or being revoked (SCI, EC). And this would still result in the AI potentially sticking its foot into its mouth in discussions on unrelated pages.
You can't improve AI's ability to assess something it is fundamentally incapable of interpreting (scanned media and offline sources). The (legitimate) sources in the draft mentioned were both scans of print media hosted on the Internet Archive.
Thanks @Jéské Couriano I respect your view, and your concerns are well-founded. I think our experiences and impression of LLM potential is different so I'm afraid I do not agree that it is definitely impossible to address your concerns. I do not intend to take this idea further at this point, so I will not continue to try to persuade you otherwise. Thank you for engaging in the discussion, I have found it interesting. DecFinney (talk) 08:24, 27 February 2025 (UTC)[reply]
Let us imagine if Wikipedia did implement this, Wikipedians would fight hard to reverse it. Plus, on a heavily vandalized page, or any page for that matter, it could spew out incorrect and/or offensive text. Really the only way it could make sense, would be a "Summary" tab. But, even if, Wikipedia has a nutshell template. Codename Abrix (talk) 22:56, 17 March 2025 (UTC)[reply]
Keep AI out of wikipedia. I believe we should defend Wikipedia at all costs from AI. AI will just spew out inaccurate stuff that new editors or editors who are not aware of those topics. I have asked AI questions before, and multiple times they are wrong. they will also violate wikipedia policies, and make wikipedia even less credible.
Your quote "So how can the power of LLMs be harnessed for the benefit of Wikipedia without undermining well-established and successful processes for developing content?" is hilarious, if we use LLMs that will not benefit wikipedia at all Thehistorianisaac (talk) 03:28, 21 March 2025 (UTC)[reply]
How actually “useful” is AI-generated text (or images) to Wikipedia? What is this site missing that having a tab for AI chatbots to spam inside of would fix? One more question: what is the purpose of Wikipedia, “the encyclopedia that anyone can edit”, if humans won’t be doing any of the writing? If I wanted to read what ChatGPT has to say about the Russo-Japanese War, for example, I’d just ask it directly. There’s no reason Wikipedia needs to become a dumping ground for AI slop. 296cherry (talk) 23:37, 26 March 2025 (UTC)[reply]
Someone started a discussion at WP:RSN about whether a video was an RS. It turned out that the intended use was not as a source, but to embed the video in an article. Since I had no experience with the question of adding video content, I went looking for information. MOS:IMAGES § Video content is relevant, but doesn't give a great deal of guidance: "Videos should be used as a supplement to article material, to concisely illustrate the subject in a way that a still image or text cannot do. Videos should not replace article text, and articles should remain coherent and comprehensive when video playback is not available" strikes me as the most relevant part. The WP:VIDEO infopage also has a bit of relevant discussion; the Examples of videos we can use section has several didactic/summary videos.
Some editors at the RSN felt that since the video wasn't being used as a source, the RSN wasn't the right venue to discuss the video's use, and that it should instead go to WP:NPOVN to assess whether the video is DUE in the article. I don't know whether the involved editors will take it there, but regardless of what's decided with that specific video and article, this all made me think that the video policy needs some work. In particular, it seems to me that a didactic video is like presenting content in wikivoice, but without any other source supporting it. Are we supposed to assess the video as an RS (e.g., do the creators/publisher have a reputation for fact-checking and accuracy)? Are we supposed to check that everything said/shown in the video is supported by existing text in the article that's sourced to other RSs? How long can a video be before it exceeds being a "concise" illustration? If it's intended to serve as a summary video, is that really a question of whether it's DUE? Etc. I figured I'd bring this here for discussion. @Rhododendrites, @Bastique, pinging you since you seemed interested in a more general discussion of video use (apologies if I misunderstood). FactOrOpinion (talk) 21:52, 4 March 2025 (UTC)[reply]
If I've posted this to the wrong Village Pump, please let me know the correct place to raise it. I'm not experienced at starting topics here. FactOrOpinion (talk) 21:56, 4 March 2025 (UTC)[reply]
I support the inclusion of summary and didactic style videos, as those supplement the article, made them more accessible and improve the overall experience of the readers. Many articles are long, and having summary videos will improve the learning experience in the core of the word encyclopedia. There are many examples of videos that could add to the articles, even documentary ones. This kind of videos are being used in other language Wikipedias, and adopted widely, but English Wikipedia is now lagging behind. And this goes against the current learning strategies people have (let's remember that Encyclopedias are for learning), where video and podcasts are consumed way more than written text. There's a huge gap between those who want to complement their readings with a summary video or extra learning material (it may be a didactic video about a subtopic, or a whole documentary) and what we are currently offering. Wikipedia should be the primary place to learn, and people is currrently going to YouTube or, even worse, TikTok, where standards for accuracy are worryingly low. Adding videos doesn't harm Wikipedia, it makes it stronger and more useful. Theklan (talk) 10:35, 5 March 2025 (UTC)[reply]
Doc James, I have to admit that my response to the TB video was mildly negative. I didn't feel like I got anything useful from it being a video rather than just audio (and it sounded to me like an AI-generated voice). A video should "illustrate the subject in a way that a still image or text [or audio] cannot do." Did I miss something in the visuals?
Theklan, none of that really addresses my questions, which are not about whether videos should be included in Wikipedia, but about what it is that we're supposed to assess in determining whether a given video is appropriate to insert into a given article. For example, do we need to assess that all of the content in the video is supported by existing RSs in the article, or by a combination of those and RSs that aren't in the article? (See, e.g., the Example that Doc James linked to, which identifies RSs for the video's content.) If it's intended as a summary video, are we supposed to identify the key ideas in the article and then check that the video addresses all of them? We have policies for the use of videos as sources, but we have very little policy that addresses the use of videos as article content. It seems to me that existing policy is insufficient. FactOrOpinion (talk) 15:50, 5 March 2025 (UTC)[reply]
Yes, I understand that. But we are in a loophole here, because we also have policies against adding videos or images which repeat the content of the article. So, if the video has the same content the article has, but with visuals to make it more appealing, the argument against it would be that the content is already in the text. And, if the video adds content, like a documentary video, or the example that triggered this conversation, then it is not accepted because it doesn't reflect the text. As far as I see it, there are two different issues stopping us to innovate and add some interesting content (and maybe new contributors) to our project. Theklan (talk) 20:21, 5 March 2025 (UTC)[reply]
Videos are great. Every part of an article should add something; you don't want a video that just repeats what is in the text, narrated in a monotone, but that almost never happens. Primary source videos produced by or about a topic are helpful as sources that can be embedded if appropriate, and should be verifiably cited to an appropriate source; secondary source videos providing analysis should be from an RS or should include their own sources (could be in a caption or footnote); tertiary source videos made as encyclopedic illustrations, just like other illustrations, can be made by editors to enhance the article and should include sources. That holds for most formats; with a short clip this is quite similar to an image, with a longer one the associated footnote might be longer and compound. – SJ +18:10, 18 March 2025 (UTC)[reply]
That essay has two problems. The first one is in the nutshell section, when it says "Encyclopedia" means "not YouTube". The second one is letting all the knowledge in the world to YouTube, instead of claiming that we should be the center for those who want to learn something. It happened something similar in the late 1980s and early 1990s when printed encyclopedia editors claimed that "Encyclopedia" meant "not online". We can see where they are. Theklan (talk) 20:22, 5 March 2025 (UTC)[reply]
While hosting an encyclopedia on YouTube could be a possibility, it doesn't mesh well with the model of Wikipedia, as videos are not really user-editable. Not sure about your historical analogy, given how major print encyclopedias like Encyclopedia Britannica did go online. Chaotic Enby (talk · contribs) 20:31, 5 March 2025 (UTC)[reply]
I'm not suggesting to host an encyclopedia on YouTube, but to have more videos in Wikipedia. There are plenty of learning materials nowadays on YouTube, that are encyclopedic/educative. If Wikipedia is seen as a place where videos can help the text, there will be more people doing those videos, so we will have a better understanding of what is possible. Technically, videos are user-editable, in the same way that audios or images are user editable: it just takes more time. And we have Wikipedia:WikiProject Videowiki, which a software allowing the collaborative scripting and edition of videos.
About the analogy, it comes from the book All the Knowledge in the World. And you are right, after a decade claiming that printed books were superior to online text, they ended up closing their printing media and adapting to the online world. I see that we are in the same point: we think that text is superior to other media, and that other media is going faster and deeper than we thought. We can adapt and see how we include rich media, or we can be a one-generation-wonder. Theklan (talk) 22:21, 5 March 2025 (UTC)[reply]
Maybe you could request that the WMF create a new video-focused project called "Wikivideos" (en.wikivideos.org) or something similar. Some1 (talk) 23:33, 5 March 2025 (UTC)[reply]
Eventually, that may happen, but we don't need it now, as we already have Commons. We can even make dedicated video portals at Wikipedia using the videos in Commons. Take a look to eu:Atari:Hezkuntza/Ikusgela for an idea on how a didactic video project can be organized at Wikipedia. Theklan (talk) 07:01, 6 March 2025 (UTC)[reply]
I can't see a problem with videos created through consensus and normal contribution-tracking editing, following all content policies, and that respect copyright, being included as a summary of a topic. Tools to make such could be a barrier. In terms of video as content, the block here is more accessibility, since those reliant on screen readers will not see it, so the video must stay within bounds of what is already presented in text. Masem (t) 16:00, 5 March 2025 (UTC)[reply]
Masem, your idea about videos requiring the same kind of sourcing and allowing editing makes sense to me, though I wonder how we'd be able to track the effects of edits, as I don't know what the equivalent of a diff would be. My impression is that the video that Doc James linked to is consistent with your intent. I'm not sure how to address the accessibility issue, and I'll see whether there's a WikiProject that could provide guidance about that; one approach might be to add subtitles explaining the visuals, just as subtitles for the deaf include important sound effects, not just dialogue.
Theklan, I think that adding examples of key uses could be a good addition to the existing policy. I don't know if one intent is to use visuals to make content more appealing; that's possible, but it involves judgements about what visuals are appealing (for example, I like good animation, but I find some animation visually boring, and I don't know that my assessments of "good" and "boring" would be widely shared). Personally, I'm more interested in visual content that accomplishes something more effectively than can be accomplished with words, still images, or audio. If a video adds content, then perhaps we should have an expectation that the editor adding the video will also add written content to the article. FactOrOpinion (talk) 20:54, 5 March 2025 (UTC)[reply]
Thank you for starting this discussion @FactOrOpinion! One of my responsibilities at WMF is to track where and how people like to get information online globally outside of Wikipedia, and for the past ~4 years I've been keeping a close eye on the growing global popularity of video platforms (i.e., TikTok, Instagram, and YouTube) as not just entertainment platforms but sources of learning and information. Here are some insights we have gathered via large-scale global surveys on this topic over the past couple of years that might be relevant for this conversation:
Gen Z-aged people (18-24 years old) around the world increasingly see video apps like TikTok and YouTube as places to get overviews of a wide variety of topics (both encyclopedic and non-encyclopedic) and find them more relevant and useful than visiting Wikipedia. (Source: Brand Health Tracker)
Despite this, we still have many Gen-Z-aged people coming to read Wikipedia today! In fact, most of our readers globally fall into this age group. The Gen Z people who do visit Wikipedia are quite different from those who don't in some key ways (e.g., they skew more male than the general population, and they report far less social media usage than the general population of 18-24-year-olds), but even they are currently also turning to video apps like TikTok and YouTube for information at greater rates than older Wikipedia visitors. (Source: Meta:Research:Knowledge Gaps Index/Measurement/Readers Survey 2023)
(We don't survey people younger than 18, so we don't have data on even younger people and their preferences in this regard, but I strongly suspect all of the above holds true for Gen Alpha, as well.)
I do think this may be indicating a growing preference for video as a learning format among younger people. However, it's not so straightforward to draw conclusions from this data about what kinds of videos might help people learn on Wikipedia. (We don't know, for example, to what degree the reason video apps are so relevant and useful for younger audiences is that they serve both encyclopedic and non-encyclopedic content – e.g., DIY, lifestyle tips, humor, etc. – that doesn't belong in Wikipedia.) And none of this data can answer the question of how/if videos could or should be used on Wikipedia in a way that respects the editable, collaborative, reliability-focused nature of the project – which is why I'm happy to see this discussion starting to flush out some of these deeper questions! Maryana Pinchuk (WMF) (talk) 21:08, 5 March 2025 (UTC)[reply]
@MPinchuk (WMF), it seems to me that if videos should be editable, one challenge is developing some means of identifying how a video has changed, without having to rewatch the entire video each time it's edited or having to assume that someone's edit summary is accurate and complete. With text, we have diffs that enable us to see all of the changes, and that helps in reverting vandalism or simply assessing whether a given edit improved the article. But I'm not sure how that would work with video content. Is this something that WMF is thinking about / working on / plans to work on? FactOrOpinion (talk) 00:06, 6 March 2025 (UTC)[reply]
@FactOrOpinion that's definitely a challenge (both making videos collaboratively editable and having some way to track changes made by multiple users) and is not something we're working on. But I imagine the level of complexity in reviewing would vary greatly depending on how long the video is and how often/by how many people it was being updated. With a short video and only the occasional edit, it probably wouldn't be much more work to get a sense of what the changes were than, say, reviewing that the sources added in a new text revision of Wikipedia accurately summarize from (and paraphrase without copyvio-ing) the source But I'm guessing a video over a few minutes long and/or with multiple people editing would get exponentially more tricky to manage. Maryana Pinchuk (WMF) (talk) 01:42, 6 March 2025 (UTC)[reply]
VideoWiki already handles diffs between videos, as the changes are done via text. However, that is one of the video types we could be adding. If you open WMF's TikTok account, you will find videos that summarize topics "Did you know" style, and could be a good addition to both articles or even the Wikipedia main page. In this videos you should follow AGF as we follow for other media. Imagine that I download Beethoven's 9th symphony file, I add randomly at 3:56 another sound, and I reupload the audio to Commons. That would be clear vandalism, but the file would still be available at Wikipedia until noticed. The same applies to other media. Theklan (talk) 07:05, 6 March 2025 (UTC)[reply]
I don't understand "the changes are done via text." Could you link to an example? I don't understand what "you should follow AGF as we follow for other media" refers to. We absolutely don't assume that potential sources are created in good faith, whatever media they're in. FactOrOpinion (talk) 13:32, 6 March 2025 (UTC)[reply]
Much of the above discussion is the reason why we don't have more video. The thing is, that fundamentally a good video is engaging, coherent and it tells a story. That makes it much more suited to being edited by one ore multiple people ONCE. This is also why many of the most successful science channels on YouTube are heavily focused around a single person Veritasium, Tom Scott, SmarterEveryday, physics girl, numberphile, just as it was in TV land with David Attenborough and Brian Cox. Being a good presenter and story teller matters. Creating a good coherent story with a TON of very expensive preparation, matters.
We on the other hand focus on bland facts, sourcing, completeness and changing our material all the time. Those are two styles that simply do not match very well (not impossible, just incredibly hard). It is like comparing a textbook at school with a video of the teacher explaining a single chapter in that book. Or thinking we could collective wikiwrite poetry at the level of the Illiad or The Complete Tales and Poems of Edgar Allan Poe. We can't, the work would lack the personality that makes those things as good as they are.
If people are really interested in creating a wiki version for educational video content, you'd be much better off indexing, sorting and verifying youtube content and making that presentable and navigable for an audience, then it is to write your own video for wikipedia in my opinion. —TheDJ (talk • contribs) 20:48, 6 March 2025 (UTC)[reply]
I think you are giving a good example of one of the problems we are facing within the media revolution. If we had, let's say, Veritasium videos with a Creative Commons license, or BBC would republish David Attenborough's documentaries with one of those licenses... what would we do? The current policies point towards not including those videos in articles, even as supplementary materials. Theklan (talk) 09:05, 7 March 2025 (UTC)[reply]
Those videos could be uploaded to the Commons then added to the hypothetical video-focused "Wikivideos" project. Some1 (talk) 10:16, 7 March 2025 (UTC)[reply]
I think that the good videos tend to be copyrighted for example Ken Burn's history videos or even The Great Courses videos by actual professors and experts. Ramos1990 (talk) 02:04, 10 March 2025 (UTC)[reply]
Hello all, as a member of the Wiki Loves Broadcast project, I think that videos can generally contribute to a good article (which is obviously not the controversial topic here). We have already gained some experience with this in the German Wikipedia and so far we have only included videos that come from a reliable source (public broadcasters from German-speaking countries) and also do not contradict the article and summarise the content from the article (either a section or completely). We have deliberately not included videos that have nothing to do with the article or have touched on topics that are not covered in the article. In addition, there are of course general criteria such as no topicality, no annoying music, etc. As we are also planning to collaborate with English-language content in the future, or perhaps videos other than these short explanatory videos will come about as part of these collaborations, I am following this discussion here with great interest. More information about Wiki Loves Broadcast can be found on Meta (page still under construction). — Preceding unsigned comment added by New York-air (talk • contribs) 14:29, 11 March 2025 (UTC)[reply]
Hi User:New York-air, Wiki Loves Broadcast looks amazing. Good videos definitely contribute to good articles! Thanks for your work. I like criteria such as "no annoying music" -- some of these are things that one could modify uploads to meet. – SJ +18:10, 18 March 2025 (UTC)[reply]
A quick intro about what I mea by "floating decorative elements": I am talking about the stuff you can see on display at User talk:HouseBlaster/sandbox, which follows you down the screen when you scroll. I am not talking about {{skip to top and bottom}} (which is very helpful for longer talk pages), or other functional stuff. I am talking about the stuff which we put there for fun and decoration.
I love that people find a way to enjoy Wikipedia. "It is fun" is the main reason why I edit Wikipedia, and I'd imagine it is for many others, too. WP:MALVOLIO is a really good essay. The idea is not to ban this way of expressing yourself. But some people (myself included) find the elements annoying and distracting. They make it harder to read the content on the talk page by covering part of the text. This hurts most on mobile, where your screen space is already quite limited.
What I propose is adding a section to Wikipedia:User pages stating that these floating elements should be wrapped in a CSS class, such as floating-decoration. This is easy for anyone to do: simply place <div class=floating-decoration> before the wikitext generating the floating element and </div> after it. The CSS class lets anyone who finds these floating decorations annoying opt-out by adding a line to their common.css page hiding these elements if they so choose. (An example CSS line is at User:HouseBlaster/sandbox.css.) The CSS class only affect the appearance of the elemnts for people who have explicitly modified their common.css.
The idea is to provide an opt-out, not to ban the practice altogether.
Editors are permitted to have a reasonable number of decorative elements which follow the reader down the screen on their user page, their talk page, or both. Some editors find these elements distracting or otherwise annoying. If they are included, they should be wrapped in class=floating-decoration. This allows anyone to opt-out of seeing floating elements by adding the following line to their common.css:
.floating-decoration{display:none;}
Functional elements (such as {{skip to top and bottom}}) are not required to should not be wrapped in class=floating-decoration.
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:
This navigation page lists articles containing information on Nick Fuentes, Donald Trump, and Kanye West meeting.
If an internal link led you here, you may wish to change the link to point directly to the intended page.
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:
This navigation page lists articles containing information on Anti-Bangladesh disinformation in India.
If an internal link led you here, you may wish to change the link to point directly to the intended page.
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]
On Mar. 17, 2025, I visited the page for Saint Patrick's Day, and I noticed that the page had Temporary Protection. I feel like it should have different icon. This could be the normal lock color with a clock in the middle, and a different notice when viewing the source. Here is a mockup of what it could possibly look like:
I'm saying it could use better indication, especially for mobile which gives a vague, "This page is protected to prevent vandalism," pop up. Codename Abrix (talk) 10:49, 18 March 2025 (UTC)[reply]
In some articles, red links like this immediately redirect you to the article creator. Instead of that, red links can redirect to a search page for that topic. And we can explain at the top, like with a template saying "This article does not exist, but if you want to create it, click here." Batorang (talk) 12:42, 19 March 2025 (UTC)[reply]
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]
Tool to convert red links into inter-language links
Hey,
I often edit Chinese related topics, and often I convert red links into interlanguage links. It often is a long and frustrating process(because red links are text, but interlanguage links are templates), so I propose that there be a tool to convert a red link into an interlanguage link much more easily. Thehistorianisaac (talk) 03:59, 21 March 2025 (UTC)[reply]
Edit: initial title was "Community consensus on bans”, but concerns are more valid for AE
Hi, as I understand it, it's well documented avenues like ANI and AE were weaponised to get rid of opposing POVs in the IP topic area, and I think this often happened after community consensus, which rather than being representative of the community would involve people of the same POV, and an admin might've been wary of going against what looked like strong consensus. I assume community consensus on bans is a longstanding practice, and my idea probably goes against strong convention, but I think only admins should be able to !vote in ANI threads and the like. But I suppose this widens the divide between admins and community members and puts more pressure on them. Be interested to hear people's thoughts Kowal2701 (talk) 07:28, 25 March 2025 (UTC)[reply]
Agreed, but I’m struggling to think of anything for AE. We could have lawyers, one for each side of the debate, who’d do their best to present their cases? That way it’d be 1:1 good faith debating rather than 5:8 (or whatever) POV laden debating. Idk Kowal2701 (talk) 11:36, 25 March 2025 (UTC)[reply]
Yeah I’d say ANI is much more functional, idk I just remember being surprised when people engaged in disputes could !vote on a sanction. But it’s usually good faith regs !voting so it may be less of an issue. Kowal2701 (talk) 11:44, 25 March 2025 (UTC)[reply]
I'm not sure I follow this, or at least the "and the like" part. There are no !votes at AE. Evidence is presented and admins decide on a remedy, or not. Consensus at AE doesn't include non-admins. AE seems much more like SPI than ANI to me. People can present evidence to support their claim of ban/block evasion, others can comment, but only the clerks get to create a consensus and make a decision. Sean.hoyland (talk) 17:17, 25 March 2025 (UTC)[reply]
Tbh my initial concern was with community consensus bans at ANI, this might do better as a place to bounce ideas about improving AE, I’ll change the title Kowal2701 (talk) 17:47, 25 March 2025 (UTC)[reply]
MOS for active/passive voice
Hey all. Something that has come up a few times while reviewing good article nominations has been the issue of whether to use active or passive voice, and whether one or the other preserves a neutral point of view. It has occurred to me that there are cases in which it would be more neutral to use one, and where using the other could be considered non-neutral. I tried looking through the Manual of Style to see if there were any guidelines for the use of active vs passive voice, but I couldn't find anything in the current version; the closest I could find was a draft page about clarity written by Ohms law, but this was archived back in 2010.
I wanted to see how others here might feel about adding something to the MoS about active/passive voice. If a proposal were made, what do you think should be included? Are there specific cases you think an active voice would be better than a passive voice, or vice versa, for reasons of neutrality or otherwise? --Grnrchst (talk) 16:30, 25 March 2025 (UTC)[reply]
Instances where someone does something harmful to someone else should be in active voice, I remember there being controversy around some American media outlets using passive voice for Israeli air strikes. But I’m not aware of other contexts for active/passive, would also like to hear from others Kowal2701 (talk) 17:52, 25 March 2025 (UTC)[reply]
Whether active or passive voice is most appropriate for a sentence is context-dependent. I worked as a tech writer for decades, and I can't come up with a general guideline that can't be rendered meaningless with exceptions. Kowal's example is a good one to dig into: is it more important to note that Oz was destroyed by Munchkin rebels or Munchkin rebels destroyed Oz? The choice depends on whether the key point in the context of that section/article is the destruction or who did it. I'd much rather see editors debating the implications of an active version vs. a passive version for a specific sentence than editors pointing to an MOS statement that "active voice is generally preferred" to demand that any other choice must be an exception that has to be justified. Schazjmd(talk)18:39, 25 March 2025 (UTC)[reply]
I suppose if the article is on Oz, then Oz would be the subject of the sentence, and vice versa for Munchkin rebels? But what if the article's on the "Munchkin destruction of Oz"? (Personally I'd say active as passive might look like Munchkin apologia) You could probably write a whole essay on passive/active voice Kowal2701 (talk) 18:47, 25 March 2025 (UTC)[reply]
Exactly. The point is that neither version is wrong, and whether one version is better than the other depends on the overall narrative. Schazjmd(talk)19:13, 25 March 2025 (UTC)[reply]
You've made a good point here for it being context-dependent, rather than something a MoS statement can develop a "one-size-fits-all" solution to. I think something that is a general guideline, rather than a hard "only this in this case" rule, could work well, but perhaps that'd be a better fit for somewhere other than the MoS. --Grnrchst (talk) 11:31, 26 March 2025 (UTC)[reply]
I don’t think this needs an MoS rule; it’s usually a matter of aesthetics and personal preference. It could be pointed out that the passive voice can be used more non-neutrally than active voice (i.e. Mistakes were made) but I wouldn’t go as far as to recommend it as a default. Dronebogus (talk) 15:12, 26 March 2025 (UTC)[reply]
Avoiding the passive is a strange thing which shows up in a lot of style guides and even Orwell's Politics and the English Language. It is much less frequently occuring than the active, because it's longer and more complex. But because it's rarer, it also has a special meaning and its own uses. Being proficient in the English language just kind of entails knowing this, like knowing how to conjugate avoid in the Simple Past.
Now, there may be a tendency in written (and formal) English to overuse the passive. Scientific articles do it all the time because they don't allow personal pronouns. There doesn't seem to be much written about this in the MoS, but in Wikipedia:Make technical articles understandable it does say: use language similar to what you would use in a conversation. That's the point, I think, to not overuse the passive, more than one would in normal conversation.
To mindlessly avoid the passive is a bad idea. In the article on Orwell's essay, Merriam-Webster is quoted: "the highest incidence of passive constructions [in normal English prose] was 13 percent. Orwell runs to a little over 20 percent in 'Politics and the English Language'. Clearly he found the construction useful in spite of his advice to avoid it as much as possible". Aspets (talk) 17:36, 26 March 2025 (UTC)[reply]
Editors using their best judgement in writing will just as well get us to a good ratio of active vs. passive sentences. Wikipedia:Avoid instruction creep has some relevant points on writing policies and guidelines. If there's not a pressing need to decide on something, it should probably be left out of the rulebook. There are practically inifinite amounts of rules that could be created and added to the MoS, so we should limit it to those which are necessary.
It's not a "rule" per se, but a footnote in the MoS does mention the use of passive voice on Wikipedia. The point is essentially the same as Schazjmd's - it all depends on context. There's no consistent guideline we could develop since the function (and therefore appropriateness) of active vs passive voice will be different in every article. That being said, I wouldn't be opposed to an MoS guideline that more closely guides editors in deciding between the two. Anerdw (talk) 07:15, 27 March 2025 (UTC)[reply]
Removing "Month and Date" from the leading sentence of articles about humans
Hi, according to Occam's razor or the "principle of parsimony", the first line of articles should only contain the main important data and does not contain any "less important" data. For example, in the article Steve Jobs, the leading sentence is:
Steven Paul Jobs (February 24, 1955 – October 5, 2011) was an American businessman, inventor, and investor best known for co-founding the technology company Apple Inc.
Here, I think "February 24" and "October 5" are not so much important to be included in the leading sentence of this article. So, according to "principle of parsimony", I propose to remove that, which yields:
Steven Paul Jobs (1955 – 2011) was an American businessman, inventor, and investor best known for co-founding the technology company Apple Inc.
I think removing such data makes the article and its leading sentence more usable and practical. These "Month and Date" can be mentioned later in that article or in its Infobox. Please discuss. Thank, Hooman Mallahzadeh (talk) 09:28, 26 March 2025 (UTC)[reply]
Occam's razor has nothing to do with this; it's for asking for the least amount of coincidences in logical explanations, not hiding the most detail. I see no reason to remove the month and date. (Also, some people are against infoboxes on certain articles.) Aaron Liu (talk) 12:55, 26 March 2025 (UTC)[reply]
@Aaron Liu Let's say an example, if someone asks you: who was Steve Jobs? Do you mention his birthday in Month and Day in details? Probably no. You only mention his birth year as an approximation. I think in these cases, mentioning details is wrong. Hooman Mallahzadeh (talk) 13:00, 26 March 2025 (UTC)[reply]
Do I mention his death year? Do I mention his middle name? Would I recall that he was a notable investor when giving basic details, even though it's quite important? Besides the questions of purpose (what if the person died on say 9/11 and is notable for doing so?), you would have to change over 4 million articles. Aaron Liu (talk) 13:41, 26 March 2025 (UTC)[reply]
Me telling someone who a person is/was in response to a verbal question is a very different context to reading about who someone is/was in an encyclopaedia article. There are many times I've looked up articles just to find someone's date of birth or death, sometimes I've wanted to be more specific than the year, sometimes I haven't. The precise date being there when I'm not interested has never negatively impacted me, the absence when I was interested would have done. Thryduulf (talk) 13:49, 26 March 2025 (UTC)[reply]
@Aaron Liu Over 4 million articles will be modified by this policy by many editors, so don't worry about that. We only want to decide on its policy.
I think most visitors only read the one or two top sentences of each article, without need to read the rest. When they encounter some details that they don't really need, I think it's a drawback of Encyclopedia.
Dear @Thryduulf in the first sentence we only provide approximation, and in the remaining parts the exact "Month and Day" is mentioned. I don't believe exact date is not encyclopedic! I only say that the leading sentence should not contain such details, except for some reason we must do that. Hooman Mallahzadeh (talk) 13:58, 26 March 2025 (UTC)[reply]
So you are proposing to have the date of birth and death twice in the lead paragraph, years only in the first sentence and the full dates subsequently? That's a hard no from me - it doesn't bring any significant benefits to anybody while making the full dates harder to find and the duplication both bring disbenefits to others. Thryduulf (talk) 14:09, 26 March 2025 (UTC)[reply]
don't worry about that. We only want to decide on its policy.
I mean most viewers of Steve Jobs article don't want to take a Birthday party for him, for only very few of them this detail i.e., "February 24" is important.
Occam's razor involves constructing explanations with the smallest number of unknown or assumed entities, being unnecessarily more complex and so less plausible than an explanation using fewer entities and those that are known. It does not mean that we should all be using shorter sentences.
And even in the best case, it is a barely noticeable improvement that would require an inordinate amount of time to implement. The answer is going to be no. GMGtalk14:40, 26 March 2025 (UTC)[reply]
The month and day should not be removed; it’s harmless and potentially useful. If we actually did remove this 4/6ths of the Encyclopedia would need modification, which is incredibly pointless busywork even for bots. Dronebogus (talk) 15:08, 26 March 2025 (UTC)[reply]
And unless the consensus was that all dates more precise than a year should be removed (which even the OP doesn't seem to desire) it couldn't be done by a bot (c.f. WP:CONTEXTBOT). Thryduulf (talk) 15:18, 26 March 2025 (UTC)[reply]
Adding support for OpenHistoricalMap inside Wikipedia
Hello, I'm an historian/computer scientist and I thought that would be cool to connect Wikipedia with OpenHistoricalMap.
I actually built a small prototype (open source) and I've put it online at globstory.it
Basic functioning is:
1. You search for a Wikipedia article (in EN at the moment, or you can insert manually the link to every language).
2. While reading the article you over the mouse (or tap the finger) on a year, and the map is updated to that year.
3. While reading the article you over the mouse (or tap the finger) on a place (town, state, continent,etc.), and the map is updated to that geographical location.
My initial idea was to build it as a free (community based) platform for digital humanities, but recently a person (thanks Susan), suggested me to ask to Wikipedia if it could make sense to directly integrate it inside Wikipedia, eventually as a plugin for Wikimedia.
Do you think it is doable? I'm thinking about many other functions that could be added and I'm very excited to propose you this idea.
Hi - I'm an OHM advisory group member and I just wanted to give a little boost to Aoppo's post here. The OHM team would be very excited to be more tightly integrated with Wikipedia & Wikidata. OHM is very open data / CC0 focused and highly encourages tight integration with the Wikimedia ecosystem - Wikidata Q codes are one of the most important tags for our relation data structures, and we're working to ensure that link is 2-way (see: https://www.wikidata.org/wiki/Property:P8424). The types of integrations Aoppo is already working on is a key focus area for our team. To be clear, Aoppo is the lead on this suggestion, but we are very supportive.
Hello! This looks like a very interesting project, and I wonder if something that could be possible would be to start working on it as a Wikipedia:User script? That way, users could add it if they wish, and it can be a good way to test it out before having it become a full extension. Chaotic Enby (talk · contribs) 20:57, 26 March 2025 (UTC)[reply]
I echo Chaotic's suggestion, though do note that extensions for MediaWiki (Wikipedia's site software) use PHP while userscripts use JS (with optional Vue.js support). This also seems like a thing many would prefer opting into instead of being enabled by default, making userscripts the better option. Aaron Liu (talk) 21:25, 26 March 2025 (UTC)[reply]
There’s a gadget implementing OSM and OHM vector maps on the OSM Wiki. It isn’t as interactive as Globstory.it, but it shows how something like that could be integrated into the site. I agree that it’s important for readers to be able to disable the maps, because they often require more resources than raster maps like Kartographer or WikiMiniAtlas, depending what you’re looking at, and some computers don’t have adequate graphics capabilities. While a pure frontend solution like a user script or gadget can adequately populate a map in an infobox, an extension would be more appropriate for something that’s more important to understanding the article content. After all, it shouldn’t be possible to turn off an interface gadget or consume the article via the API and be left with a gaping hole in an article. (Though I guess the Graphs extension shows this can happen anyways.) Minh Nguyễn💬22:40, 26 March 2025 (UTC)[reply]
A user script is definitely the way to go. Writing an extension that's suitable for installation is extremely difficult, and it's highly likely that the WMF won't allow the extension to be deployed due to lack of capacity to maintain it, see mw:Writing an extension for deployment. The WMF would not install an extension that loads data from a third party website, so the entire OpenHistoricalMap software and database setup would have to be duplicated by the WMF (and brought up to the same standard required by the rest of the extension). 86.23.109.101 (talk) 08:57, 27 March 2025 (UTC)[reply]
I don't think it would be a new extension anyways. Wikimedia Maps already replicates OpenStreetMap data, so that Kartotherian generates vector tiles which get rasterized. In principle, an OHM map could use the same exact stack, except for the last stage (because you don't want to have to rasterize a separate tileset for every date in history). Instead, Kartographer would need to incorporate MapLibre GL JS instead of Leaflet. But I tried to convince the Foundation to adopt client-side vector rendering technology a decade ago and I don't know that it's much closer to happening. Minh Nguyễn💬00:36, 28 March 2025 (UTC)[reply]
This is a very cool idea! The problem with having a userscript, however, is that only a very select minority of WP readers (logged-in editors who know about the script) can use this. Is it possible for this to integrated into the logged-out reader's interface, with the option of opting in page-by-page? Cremastratalk22:05, 27 March 2025 (UTC)[reply]
Not easily, no.
To serve this to logged out users you have two options, a default gadget loading the data from their website, or a mediawiki extension.
From the gadget perspective there are multiple issues - the WMF privacy policy bans loading third party content without consent, so you would need to explain to every person that uses the gadget that it is loading data from another website, and what this means in terms of their privacy. I also seriously doubt that the existing OpenHistoricalMap servers would be able to cope with tens of thousands of requests per second from wikipedia.
Writing an extension would most likely be a waste of time because it would not end up being installed. The WMF requires that extensions be "sponsored" by a team within the WMF, and that new extensions go through usability and security reviews. As an example, the Russian wikipedia currently wants to add an extension which allows new talk page sections to be placed at the top of pages. The extension in total consists of 49 lines of PHP. The request to intall this extension has been open since August 2023, and it has been waiting for ~15 months for a security review and to find someone to sponsor it: Phab:T344501/phab:T355161. 86.23.109.101 (talk) 23:06, 27 March 2025 (UTC)[reply]
That's what I figured. :/ Oh well. It's a cool project – we could always point WP readers towards it once it's finished development. Cremastratalk00:08, 28 March 2025 (UTC)[reply]
OpenHistoricalMap will never be finished! If the concern were only about OHM's cloud hosting melting from overuse, then setting up OHM's tile generator on Toolforge or Wikimedia Cloud Services would be a way to sidestep that concern. But it would still be a second stack for the Wikimedia Maps team to take responsibility for or at least "sponsor".
A much simpler step would be to fix {{coord}} and {{GeoTemplate}} to correctly link to spatiotemporal maps like OHM as of a specific date. I proposed a simple change to this effect a couple years ago, but now I realize I should've come here first.
Thank you all for the replies! I'm super happy with the feedback. I need to understand how the user scripts work, as it's seems to be the simplest solution at the moment. Maybe we can have a call with the interested people so that we can agree on a common direction. 2A01:827:1A72:8001:39E8:1AB:7F45:DD6F (talk) 09:59, 29 March 2025 (UTC)[reply]
m:OpenHistoricalMap has a broad overview of opportunities for cooperation between the OHM and Wikimedia communities. I hope participants in this discussion will take a look. There are lots of possibilities that aren't necessarily conditioned upon the WMF's engineering resources. Minh Nguyễn💬20:40, 29 March 2025 (UTC)[reply]
Redirect pages should not be accessible to editing by IPs or non-autoconfirmed users
Our policy for starting new pages is that the person should be using a registered username which is four days old and has made 10 edits.
A loophole in that policy is that any brand new or IP editor can start an article if there is already a redirect sitting on the article page name.
I propose a technical restriction disabling brand new users and IPs from being able to change a redirect in any fashion.
The background to this proposal is that there are blocked and banned users who habitually bypass our policy by using IPs to create new articles from redirects. Some of these even go to the page Wikipedia:Articles for creation/Redirects and ask for redirects to be created, after which the IP will start a new article on that redirect page. For instance, relative to Wikipedia:Sockpuppet investigations/Rishabisajakepauler, a person from Greater Dallas Texas who was blocked as Rishabisajakepauler and then banned per three strikes has been requesting redirects, and then creating articles from those redirects.[17][18]
"Eligibility", "Suitability", or "Admissibility" instead of "Notability"
This isn't a completely new idea, but I've seen it proposed here several times that we use another word than "Notability" to convey to newcomers that it's not about how important they are, but rather whether they meet specific criteria. I think this makes a lot of sense as people will intuitively respond to "notability" -- are they notable -- in a different way than they intuitively respond to "eligibility" -- are they eligible enough, and what are the criteria for eligibility. And I just noticed that the French wiki uses "Admissibilité" (see https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:D%C3%A9bat_d%27admissibilit%C3%A9), which translates to "admissibility" or "eligibility". It's very interesting that this idea actually has been adopted by, and works for, another Wikipedia, and I wanted to make that more known here. What do people think about it? Mrfoogles (talk) 05:22, 29 March 2025 (UTC)[reply]
I don’t think anyone is going to want to implement such a minor change when it requires changing a huge number of pages, especially when it’s so fundamental to Wikipedia canon and part of every experienced editor’s vocabulary. Dronebogus (talk) 14:06, 29 March 2025 (UTC)[reply]
Way to know if an editor has been asked about paid editing, and if they answered.
I'm posting to idea lab about the idea of having/creating the possibility for a search tool to answer the bolded question in the following paragraph.
I see lots of behavior from several editors on topic that is indistinguishable from that which I would expect of a paid editor. Which leads me to wonder: Have there been inquiries as to paid editing? How would one search to find out if an editor had been asked about paid editing? Had answered? (Is there a search that would work? As I have tried to answer this, I found that guidance is really vague on when it's OK to ask about when noticing a pattern of editing indistinguishable from that one would expect of a paid editor, such as in a topic area where there are relatively large financial incentives to push one point of view and disallow others. RememberOrwell (talk) 07:39, 29 March 2025 (UTC)[reply]
I'm not aware that there is an easy way to do this. The most likely places someone will be asked are their user talk page and the talk page of article(s) where their edits are concerning. Searching through those pages for terms like "paid", "conflict of interest", "coi" and "financial" are likely to find most instances of questions and answers. Thryduulf (talk) 11:36, 29 March 2025 (UTC)[reply]
WMF annual planning: How can we help more contributors connect and collaborate?
Hi all - the Wikimedia Foundation is kicking off our annual planning work to prepare for next fiscal year (July 2025-June 2026). We've published a list of questions to help with big-picture thinking, and I thought I'd share one of them here that you all might find interesting: We want to improve the experience of collaboration on the wikis, so it’s easier for contributors to find one another and work on projects together, whether it’s through backlog drives, edit-a-thons, WikiProjects, or even two editors working together. How do you think we could help more contributors find each other, connect, and work together?KStineRowe (WMF) (talk) 20:27, 10 January 2025 (UTC)[reply]
I think opening up the article translation features to more people would be beneficial for collaboration between the various languages of wikipedia. I also think english wikipedia and simple english wikipedia should collaborate more, but I don't have any ideas for that specifically (other than maybe having a button to link users to a simple english version of a page if it exists) Mgjertson (talk) 16:06, 6 February 2025 (UTC)[reply]
I think WikiProjects could get more promotion with maybe a popup for new editors saying "talk with other editors active in this topic area here". ꧁Zanahary꧂22:51, 11 February 2025 (UTC)[reply]
To me it seems like WikiProjects are mostly handy to get assistance from other people interested in a topic area / get consensus for some widespread change, but they only really work if the talk pages aren't dead. So links might help, although every article in a WikiProject's talk page already links to the project, though. Mrfoogles (talk) 03:50, 25 February 2025 (UTC)[reply]
I concur with more support to WikiProjects. These projects are invaluable to content diversity and surely there should be an effort to link these projects with both direct funding from WMF as well as other Affiliates. The synergy is obvious. — Thuvack | talk00:18, 5 March 2025 (UTC)[reply]
What would the funding be used for, and who would receive it, though? It doesn't seem like most WikiProjects always have formal leaders or much monetary needs. Mrfoogles (talk) 20:04, 13 March 2025 (UTC)[reply]
@Zanahary, @Mrfoogles, @Thuvack, thanks for bringing up WikiProjects! I work on a team at WMF that focuses on how we can improve the experience of people collaborating together on the wikis, and we have developed some tools that can help WikiProjects, as part of the CampaignEvents extension. The extension is already enabled on English Wikipedia, as well as other wikis (see deployment status). The extension has 3 tools: 1) Event Registration (a way to register participants & run collaborative activities on the wikis), 2) Collaboration List (a way to discover events and WikiProjects to join - see example on English Wikipedia), and 3) Invitation Lists (a way to find people to invite to events or WikiProjects, by identifying editors who made significant contributions to articles).
We also have some current & upcoming work that can support WikiProjects, which is: 1) allowing event registration in alternative namespaces (T385341), so that it can be used in namespaces like Wikipedia or WikiProject, if wikis want to allow it, and 2) allowing an embeddable version of the Collaboration List (T385347), so a WikiProject could have an automated "calendar" of events, filtered by the wiki(s) and topical area(s) of its interest, that could be added to any of its pages. Finally, we are in the early stages of exploring some future potential project ideas, including: 1) adding a version of the Collaboration List to the Newcomer Homepage, so newcomers could learn about events and/or WikiProjects that may interest them (T387792) and 2) tracking collaborative contributions through Event Registration, so that the contributions that are a part of an activity/event/project can be easily tracked on the wikis (T378035).
We're continuing to develop the extension, so we're very interested in any suggestions of what to work on next and/or what could be most impactful. So, I'm wondering: Do you think the tools that are a part of the extension today could be helpful to WikiProjects? Do any of our upcoming/future project plans sound like good or bad ideas? What do you see as some of the biggest gaps related to tooling on WikiProjects, and how could we potentially help address these gaps? Thank you again for all of the ideas you already shared, and I look forward to any feedback! IFried (WMF) (talk) 21:24, 19 March 2025 (UTC)[reply]
My experience is mostly with the unreferenced articles project, and their backlog drives. They could probably use a software-supported method for people to sign up for things and to invite people to things, etc., I think? Currently people just put themselves on the page with the list -- it's a bit hacked together, like a lot of things end up being.
All I can think of would be to say that it's probably best to make sure events don't keep getting automatically scheduled when a WikiProject is dead, as a lot of them become -- that would probably pollute the queue.
Do a lot of people actually use the Newcomer Homepage, so far? I've heard about it, but I didn't run into it when I got started editing. It would definitely be interesting if that could be used as a recruiting tool, and I think it would probably work well -- the whole point of backlog drives/etc. is to have good contained tasks -- but I didn't get the impression that the Newcomer Homepage was fully rolled out yet from the various pages. Mrfoogles (talk) 02:43, 20 March 2025 (UTC)[reply]
@Mrfoogles, thanks for the reply! Good to hear you think there's a chance that tools like Event Registration and Invitation Lists could be useful to WikiProjects. Yes, like you wrote, a lot of the current solutions are hacked together, so we're hoping to provide optional alternatives for all sorts of activities (such as edit-a-thons, WikiProjects, etc), which can provide a bit more structure and ease of use.
As for automatic scheduling of events: Fortunately, the Event Registration tool doesn't allow events to be automatically scheduled. An organizer needs to deliberately create an individual event page and then enable registration. Wiki admins have the powers to grant/revoke the event-organizer right (which enables users to enable event registration), if the privileges are being abused. Also, event pages are wiki pages, which can be handled in the same way as any other wiki page.
As for your question about the Newcomer Homepage, which was: Do a lot of people actually use the Newcomer Homepage, so far? Here's more context: The Homepage is enabled by default for all new accounts made on Wikipedia, so it is definitely used by newcomers. It is also available to all accounts (via Preferences). While most Homepage impressions come from users with very few edits (which is expected, given the audience), about a quarter of Homepage visits comes from users with more than 100 edits. On English Wikipedia, about 47% of active editors have the Homepage enabled. You can see some recent data about impressions in T382046#10560682.
So, it is good to hear that you think it could be interesting to use the Newcomer Homepage as a recruiting tool for events and/or WikiProjects. We're also really interested in exploring this idea. Thank you again for your feedback and ideas! IFried (WMF) (talk) 22:39, 20 March 2025 (UTC)[reply]
Kill switch to delete information on user IP and email addresses
WMF should have a kill switch to delete all information on the IP addresses and email addresses associated with all user accounts. If DOGE can just walk in and seize the US treasury, seize USAID, gain access to the federal payment system and potentially everyone's SSN's, etc., then there is no reason to think people couldn't just show up at the WMF some day and seize all of our user data. The WMF should have a protocol in place to rapidly delete user data should that occur. Photos of Japan (talk) 07:16, 4 February 2025 (UTC)[reply]
I think WMF would just say "No". DOGE is only able to do the stuff it does the federal government because it has the President, who can at least lie to people who work for him he has authority over this stuff. WMF would instead say something like "Do you have a warrant?" and suchlike. Mrfoogles (talk) 18:23, 20 February 2025 (UTC)[reply]
Why would they care about the WMF saying "No."? They just show up to federal agencies with armed officers and waltz on in, who is going to stop them? Some office worker in the WMF, "Do you have a warrant?", bunch of armed people just walk right past them. Photos of Japan (talk) 18:31, 20 February 2025 (UTC)[reply]
Do you have any evidence of DOGE going in to any organisation that is not government owned? I'm no fan of Elon Musk, but I don't think he has any control over Wikipedia (much as he'd like to). Phil Bridger (talk) 18:51, 20 February 2025 (UTC)[reply]
They are too busy to care about something like Wikipedia right now. They are also in the process of flushing out the Department of Justice and mass firing FBI agents to replace them with their own people. They just released an EO declaring Trump determines the authoritative legal interpretation of the law for all employees of the executive branch, and has complete supervision and control over the executive. If Trump has thousands of FBI agents that do whatever he says, then one year from now there's no reason to assume the WMF won't be subjected to some illegal raid. You prepare for problems before they happen, you don't wait for them to occur and then react to them. Photos of Japan (talk) 19:16, 20 February 2025 (UTC)[reply]
I think that currently both the main and backup sites are in the USA, along with the WMF and the endowment. Maybe now would be a good time to move some or all of that to countries with a greater seperation of powers between the executive and the judiciary. Or at least change the fundraising model to a more decentralised one where the money raised in each country where we have a national charity is under the control of that charity. ϢereSpielChequers21:44, 21 February 2025 (UTC)[reply]
Yeah. Regardless of who's in charge, it's just a good idea to not keep everything in the same place. We should probably think about setting up a backup site in Europe Mgjertson (talk) 19:30, 11 March 2025 (UTC)[reply]
WP has "caching" data centers in Amsterdam and Marseille, as well as Singapore and Sao Paolo. What I don't know is how much would need to be done to move the "application" functions from the data centers in the US to one of those non-US facilities. I don't know how much protection that would provide, as the Foundation is a US registered corporation, and some European standards, such as the "right to disappear", clash with WP aims. Donald Albury21:22, 11 March 2025 (UTC)[reply]
Hey, I wanted to add my two cents. This is not really related to any recent events, but is about privacy and data we collect. The Trust and Safety Product team is working on Temporary Accounts, something which really strengthens the logged-out editors' privacy. The feature is live on 12 wikis already, and we are expecting it to be ready for deployment everywhere (yeah, on all our wikis) later this year. You are welcome to subscribe to the newsletter to keep track of our work, and to comment on the draft plan for the team's work in the next fiscal year. SGrabarczuk (WMF) (talk) 00:46, 5 March 2025 (UTC)[reply]
SGrabarczuk (WMF), this discussion was raised due to a potential concern about the privacy of logged-in users, whose accounts are not temporary. I see the draft plan includes some items on reducing abuse for logged-in users, but don't see any notes about data or privacy relating to logged-in accounts. CMD (talk) 01:25, 5 March 2025 (UTC)[reply]
I would suggest that you follow WP:NPOV and not demonize DOGE.
As for the Kill switch, I believe (as an amateur historian) that records are important, and I believe that i think if they are getting investigated for their crimes, we should not be hiding criminals. Thehistorianisaac (talk) 04:02, 21 March 2025 (UTC)[reply]
Agreed. I do suspect the CIA/FBI/NSA is monitoring recent changes. Often users part of the recent changes patrol (such as me) already are able to see what edits people make, I would be surprised if they don't monitor recent changes. Also see Template:National Intelligence Agencies for everyone who is watching us right now.(Hello my NSA Agent, how's life over there in Fort Meade?) Thehistorianisaac (talk) 05:39, 22 March 2025 (UTC)[reply]
I think the idea is to buy books that are requested at places like WP:RX but are not easy to obtain. I think this idea was first proposed on a talk page somewhere during a discussion about non-ideal ways the WMF was spending their money and what they should be spending it on instead. I'm actually quite happy to see that the WMF took the idea seriously and is trying to meet volunteers in the middle by listening to their ideas and turning them into an actionable program. Full credit to WMF for trying this out. –Novem Linguae (talk) 23:11, 28 February 2025 (UTC)[reply]
@Novem Linguae All wikilinks to the article ANI v. WMF should be removed as the article isn't even an article. Its just a template saying "Asian News International is trying to censor Wikipedia for simply telling the truth". DotesConks (talk) 04:24, 10 March 2025 (UTC)[reply]
I think it's better we try to heal into a self-consistent state involving that article not existing, rather than deliberately sending people to the memory hole. Reverts are cheap, so when it comes back it won't be hard to revert my edits. I likewise would prefer that the article on the individual case be a redirect to an appropriate section rather than a visible sore (assuming that's legally allowed). I totally get the other viewpoint, though. * Pppery *it has begun... 15:39, 21 October 2024 (UTC)
Rephrased, I don't think it's appropriate to have a link that looks like it's going to point to something, but instead points to nothing. The only information the link conveys is that the WMF has blocked access to the article. In all of those cases the article still says that later in the same paragraph, so the link is redundant. I was inspired to do this now (after having been previously reverted in October) because months later I think the case for doing this is stronger than it was back them when things were still in flux. * Pppery *it has begun...04:27, 10 March 2025 (UTC)[reply]
(edit conflicted but applicable here too) If that is the consensus, is there a Template:ill type solution that could hide the wikilink if that is the case? Usually for pages with possibility redlinks mean there is not a need to redo all links if a page is created, however in this case there the wikilink removal is creating future work that would involve tracking down prior links as well as reverting. CMD (talk) 04:30, 10 March 2025 (UTC)[reply]
I'd prefer that we retain the links. The situation has already forced us to make extraordinary against-encyclopedic-interests changes, and modifying other articles as well would be an unforced deepening of the wound. Links, even when not clicked, reveal information to readers about e.g. which topics are notable enough to merit coverage. Removing them would send the false message that we don't consider the topic notable. This is also analogous to the situation with red links for notable topics, which we retain despite them not leading to information, so I don't find the "links need to lead to info" argument above persuasive. Lastly, reverts aren't the most expensive change, but they do take some work, especially once an article has evolved around them (e.g. by providing more context when a link is absent or by adjusting MOS:SOB workarounds). Keeping the links takes the longer-term view, in which the article will eventually go up again and we won't have to reintegrate it into the rest of the encyclopedia. Sdkbtalk07:02, 10 March 2025 (UTC)[reply]
I came in here with no strong opinion, but I think Sdkb makes a good point that the links, even to a removed topic, are valuable information. Valereee (talk) 12:59, 10 March 2025 (UTC)[reply]
Keep the links. Our practice is to wikilink notable topics on which we have no article. These links may be red (for logged-in editors) or may redirect to a related topic such as a list entry. In this unique case, the link is to a page documenting the WMF's redaction but the principle remains valid: if the topic is notable, we link to whatever we have. Certes (talk) 08:45, 21 March 2025 (UTC)[reply]
While we're all here, can we get an update on the case itself? Is there a time estimate on when the page could be made available again? Are the editors out of legal risk? Is this case going to lead to risks of other articles going down and/or restricted availability in India? Tazerdadog (talk) 08:37, 13 March 2025 (UTC)[reply]
@Tazerdadog: There's been some updates over at WP:ANIVWF, and you can follow the court case directly here. Most recent update is that the WMF has appealed for the plaint to be rejected; the editors' details were disclosed to the court under a sealed cover and they have been served with a summons, but no affidavit has been filed by them and nobody has appeared in court on their behalf. There haven't been any real proceedings since this update as the presiding officer was on leave. Unfortunately I can't answer the rest of your questions, as it all depends on how the court case proceeds. --Grnrchst (talk) 20:09, 16 March 2025 (UTC)[reply]
I was recommended a short from what seems to be the WMFs official youtube channel. It was basically an AI narration of a wikipedia pages lead with relatedish images lifted from the commons. Is this actually the Wikimedia foundations youtube channel? I find it hard to believe we'd make AI generated voiceovers and link to articles via Linktree but the account also says it's from 2007. Is this an experiment or something? mgjertson (talk) (contribs) 15:38, 13 March 2025 (UTC)[reply]
Hi @Johan (WMF), m:Future Audiences/Generated Video raises the question "Is there a risk of damaging Wikipedia’s brand or enriching a non-free company’s brand by publishing content on TikTok?", and discusses this further at various points. However, it does not discuss the seemingly far more crucial question of considerations for the brand of directly associating it with AI-generated content. If you're trying to lead editors to Wikipedia, linking it to the suggestion it might be AI-generated is probably not a productive way towards that. If the trade-off does not lean that way that would be good to know, but it's surprising to see it just not even mentioned when there seems to be considerable effort made to manage concerns about TikTok. CMD (talk) 03:46, 14 March 2025 (UTC)[reply]
Chipmunkdavis: For clarity, I want to stress that the content isn't generated by an AI. The content is coming from Wikipedia articles. The AI usage here is as a packaging tool with human oversight. Damian, who is the PM for the Future Audiences experiments, will give a longer answer. Johan (WMF) (talk) 15:41, 14 March 2025 (UTC)[reply]
I feel like it's mostly fine as long as the actual text is not AI-generated -- text-to-speech is not the same thing as ChatGPT, really. Mrfoogles (talk) 02:44, 20 March 2025 (UTC)[reply]
As far as I can tell, AI stuff is currently the center of a very large amount of political contention, and moreover (not wholly unrelatedly) considered highly uncool by teens/etc. jp×g🗯️11:28, 14 March 2025 (UTC)[reply]
AI narration not necessarily (cf these AI-narrated Reddit threads someone showed me once), but it does feel a bit weird for WP's image. Aaron Liu (talk) 15:15, 16 March 2025 (UTC)[reply]
Hi @Mgjertson – Maryana from the WMF Future Audiences team here (h/t for the tag-in @Sdkb). As @Johan (WMF) mentioned, we're creating these short videos using Wikipedia content to see if we can reach new audiences that don't know about or visit Wikipedia today. We know from global surveys that today's 18-24-year olds are the least aware of or inclined to visit Wikipedia of all the age groups we survey, but they love learning on platforms like TikTok and YouTube Shorts. So if we want to introduce this generation to Wikipedia, we're going to have to do it on the platforms they spend a lot of time on.
The videos you're seeing are our first lightweight steps to seed the short video space and see which topics work and which don't. We've managed to get a few viral moments (interestingly, @Dumelow's DYKs have been some of our best performers! This is some DYK magic that we're studying and trying to replicate ), and have gotten millions of views and thousands of likes, comments, and new followers on our accounts since the start of this experiment last fall. In addition to learning and continuing to build up an audience on these channels, we want to invite Wikipedians and anyone who wants to make their own fun-fact/explainer video content to join us and participate in these channels. We'll have some videos made by communities appearing on these channels soon, so stay tuned!
Also, a little more detail on how this set of videos has been made to date: we start by handpicking either existing DYKs curated by the community or other topical/relevant-to-younger-audiences topics. We then use an AI-powered tool to summarize the text and images associated with the article into a short 30ish-second video and add an AI voiceover, and then get human review/editing on the text and images to make sure they're accurate. The AI tool and narration saves us some production time (which helps us learn more efficiently by allowing us to put out more content and understand how a broader range of topics perform), but it's still a pretty human/manual content creation process. It's true that AI has a certain stigma to it, which we're closely monitoring and collecting feedback on. Though we haven't seen a signal that AI is creating any major risk or pushback (e.g., we're growing followers on these channels, not losing them), our strong hunch is that once we start posting community videos that feature humans and are narrated by humans, they'll perform much better than this initial batch. But like I said, these AI-assisted videos were a way for us to get the ball rolling & start learning quickly/efficiently.
If you have any more questions, my colleague @DLin-WMF is happy to answer them! He has recently joined the Future Audiences team to lead this and other experiments, and he ran into some posting permissions issues because his WMF account is so new, so Johan & I jumped in here to help out in the meantime. Maryana Pinchuk (WMF) (talk) 14:46, 15 March 2025 (UTC)[reply]
Wikipedia is fairly ubiquitous (yay!). I don't think we need to be explicitly trying to "introduce" teens to Wikipedia, because the majority already know about and probably use it sometimes. Some of them even edit it. Cremastra (talk) 22:35, 15 March 2025 (UTC)[reply]
@Cremastra, here's a link to the survey data Maryana mentioned. It shows that most teens are aware of it, yes, but they're less aware of it and use it less than older groups, so there's a concerning trend. Also keep in mind that this is global data, and Wikipedia may not be as ubiquitous in other communities as it is in yours. Sdkbtalk04:25, 16 March 2025 (UTC)[reply]
Yes, and: awareness doesn't necessarily equate to positive sentiment or usage. 18-24-year-olds have also been reporting the lowest net promoter score of Wikipedia of any generation we survey (NPS measures "would you recommend Wikipedia to a friend?", which is a way to get a sense of people's sentiment towards a product or service). This indicates that some young people may be aware of Wikipedia because e.g. a teacher told them about it and told them not to use it (so they don't), or because they saw someone on social media talking about how terrible and biased it is (which unfortunately is also growing more common), etc. Maryana Pinchuk (WMF) (talk) 14:25, 17 March 2025 (UTC)[reply]
"The videos you're seeing are our first lightweight steps to seed the short video space and see which topics work and which don't. We've managed to get a few viral moments (interestingly, @Dumelow's DYKs have been some of our best performers! This is some DYK magic that we're studying and trying to replicate ), and have gotten millions of views and thousands of likes, comments, and new followers on our accounts since the start of this experiment last fall." Where would this be? At the "official channel for Wikipedia and other Wikimedia products", when I rank the video's[26] by popularity^, all the popular ones are at least 5 years old. Looking at the latest, there are from the last 12 months 2 video's which barely make 1K views, the remainder is less popular. Or do you mean the "shorts"? [27] There is one with 2.8K views, 2 others which just get 1K views, and all others get less than that. So where can I find these video's created since "last fall" which have amassed these millions of views? Fram (talk) 14:57, 17 March 2025 (UTC)[reply]
They mirror the same content, and evidently nearly nobody in this thread uses TikTok, therefore Jertson discovered this content through YouTube (Shorts) instead. Aaron Liu (talk) 17:00, 17 March 2025 (UTC)[reply]
This page I assume? Clicking "Popular" doesn't actually sort by popularity, but at least for me it shows the flat roof pub video near the top with 234.4K views. CMD (talk) 02:33, 18 March 2025 (UTC)[reply]
"Did you know that most people in North Korea cannot afford pizza?" seems a bit heartless for a specifically made official video. CMD (talk) 02:35, 18 March 2025 (UTC)[reply]
DYK is a fast-moving process where most hooks only get seen by a few people. It has redundancies in place, but it isn't perfect and shouldn't be assumed to be. CMD (talk) 02:41, 18 March 2025 (UTC)[reply]
That a hook got viewed isn't relevant to my point about DYK. On the aside though, I don't have an issue with the Pizza in North Korea article, which has the relevant text in context. Nor is the DYK still on the mainpage (buried on the talkpage and in archives), whereas that TikTok was one of the first things I saw when looking at the Wikipedia (that's us!) TikTok account. If you think it is good for an official Wikipedia platform to prominently host "Did you know North Koreans are poor" as an interesting fact, please say that rather than discussing the foibles of DYK. CMD (talk) 02:52, 18 March 2025 (UTC)[reply]
How is it irrelevant? If the hook got 54k clicks from being on the main page, how is that only "seen by a few people"? Way more people got an impression of Wikipedia from this main page hook just during its that one day while only 4.4k got the impression from an AI-generated TikTok short.
If you think it is good for an official Wikipedia platform to prominently host "Did you know North Koreans are poor" as an interesting fact
As I said above, DYK isn't perfect, and so because DYK did something does not make it perfect. "Seen by a few people" referred to the DYK review process, where hooks are seen by 1) the nominator, 2) the initial reviewer, 3) the prepper, 4) the queuer. Likely it'll get seen by a handful more who aren't engaged directly with it, and then a few editors check things for ERRORS, but yes, it's a few people. I'm not asking for what people have done on DYK and TikTok, I am asking for you to state your views, because it is unclear why you have decided to extend this discussion without commenting on the core subject matter that I raised in a very brief note. CMD (talk) 14:26, 18 March 2025 (UTC)[reply]
I don't think it's a problem, and the handful of DYK people (way more than the one person that is you) did not find it a problem. Aaron Liu (talk) 15:07, 18 March 2025 (UTC)[reply]
I just don't see anything that heartless about it. It's not much more heartless than say when the Brighton Town Commissioners wanted to build Queen's Road through a slum district, they invited all the residents to a festival and demolished their houses while they were away? to me. You're not gonna get some sound logos out from me since this is pretty much all about subjective pathos. Aaron Liu (talk) 16:30, 18 March 2025 (UTC)[reply]
The sound logos stuff is red herring, I was seeking any actual opinion to explain the cause of this discussion, given all previous statements were about DYK. That said, your example doesn't seem similar at all, it's recounting an event rather than making a blanket statement about a group of people. Replace X in "Did you know most X can't afford pizza?" with other labels, saying group Y or Z are poor as a fun factoid is both not that interesting and easily coopted into harmful stereotypes. CMD (talk) 17:03, 18 March 2025 (UTC)[reply]
Oh well, let's be happy that they took their soundbites from DYK, which is often wrong or in poor taste, and not from "On this Day", were between 2012 and, er, two days ago[28] we proudly presented Remembrance Day of the Latvian Legionnaires, "a day when soldiers of the Latvian Legion, part of the Waffen-SS, are commemorated." as the bolded top item for that day. Would be a hit on TikTok I suppose. Fram (talk) 17:18, 18 March 2025 (UTC)[reply]
For short-form content that would fit our aesthetic, one could look at the NYT's grey-background stuff (e.g. https://www.youtube.com/watch?v=6L1AYL6oxlU), except we'd have way less motion and mostly just grey-background guy talking with images Ken-Burns b'rolled to taste (plus ofc a short ident at the end, perhaps with the sound logo). Aaron Liu (talk) 01:05, 18 March 2025 (UTC)[reply]
The proposed WMF Annual Plan OKRs page has a section on Social video (they want 5,000,000 views etc) and some discussion. That wasn't the right place for my comment, but like the original poster here the concept was new to me.
It seems to me that many want an opportunity to work on this content: the "radio voices" comment; the series of alternate topic suggestions; and the Ken-Burns thing (I didn't really get that one Aaron Liu, but euwiki's video project has some presenters with backgrounds).
2020 US court case affecting Google's contributions to Wikipedia?
As I fear, whatever remedies or sentence of the US case (2020) against Google will be might affect Google's ability to contribute to Wikipedia, its sister projects, and the WMF (Wikimedia Foundation). I can stand corrected about this.
Well, as we know so far, the sentencing/remedial trial will occur next month, and the judge will decide in August this year.
Open call for US & Canada Regional Fund Committees members
Hi everyone. The Wikimedia Foundation Community Resources team is seeking new members for the US & Canada Regional Fund Committee, which supports funding needs in the General Support Fund program. The committee maintains responsibilities to review and make final funding decisions for proposals received for this program, as well as working together with applicants on preparing robust proposals that benefit Wikimedia projects and the communities that contribute to them and use them.
The Regional Fund Committees' work is guided by the principles of participatory decision-making and subsidiarity, and aims to support the needs of many communities in the Wikimedia movement, including those based on gender, ethnicity, age, and geography, amongst other characteristics.
To learn more about Regional Fund Committees in general, eligibility criteria for joining, roles and responsibilities, training information, and procedure for review and selection, please review our general open call information on Meta-wiki.
To apply as a candidate for the US & Canada Regional Fund Committee, please review our candidates page on Meta-wiki for more information. Applications may be submitted on Meta-wiki or sent directly to me (cschillingwikimedia.org). No deadline is set for applications for this open call, and will remain open until otherwise notified.
Please feel free to share this invitation and open call with any interested Wikimedians and other professionals who may be interested in committee participation. I'm also open to responding to any questions or needs for clarification here. With thanks, I JethroBT (WMF) (talk) 12:56, 17 March 2025 (UTC)[reply]
@Chipmunkdavis: Thanks for your question. Yes, open calls for the Sub-Saharan Africa and CEE/Central Asia regions are also open for review, and so editors are welcome to apply there if interested. Information about Open Calls for those regions are available here on Meta-wiki:
Wikitranslate, the free translator, uses information from the web and Wiktionary. Also Wikifilm, the free streaming service, mostly of public domain films. An editor from Mars (talk) 04:27, 19 March 2025 (UTC)[reply]
To be honest, I'm not sure that there's enough demand for public domain films a whole streaming service is needed; people can already watch them fairly well on Commons if they want to. And Google Translate already uses information from Wikipedia -- that's not a distinguishing feature. Mrfoogles (talk) 02:45, 20 March 2025 (UTC)[reply]
Yes, but this still seems to violate trademark rights. I believe the WMF holds the trademark to "Wikipedia". Anyway, if it violates copyright, the writers of the articles concerned would have to take action as the copyright holders. Phil Bridger (talk) 18:12, 24 March 2025 (UTC)[reply]
Yes, attribution requires the word "Wikipedia", but it certainly doesn't mean that the word has to be in the title of the book, which is the trademark issue. Phil Bridger (talk) 21:08, 24 March 2025 (UTC)[reply]
P&T Annual Planning: The Product & Technology department publishes its plans early in the annual planning process, which is on Meta-Wiki and open for feedback. These objectives and key results are not a list of projects, but instead, a set of directions for problems to solve and impacts to achieve over the course of the year. We look forward to engaging with the community on this plan.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!
I keep thinking that they can't be that bad, but then they come out with something that shows that they are. I'm just glad that I don't live in the US. Phil Bridger (talk) 16:00, 25 March 2025 (UTC)[reply]
WMF is closing the MS forums. please see the link below for details.
Here is the official WMF announcement: Based on the data and the learning, we will be archiving the Forum in April 2025. It will be put in read-only mode for a year - during this time all the discussions will be available online, but no new discussions can be started. After this period we will export all the data and retain a full archive.
Thanks for sharing. Sunsetting the Movement Strategy forum is probably a good move, in my opinion. The Movement Strategy forum's location and software is a bit on the bespoke side, and runs the risk of raising barriers to entry, and fragmenting policy discussions away from the already existing place for such discussions (metawiki). –Novem Linguae (talk) 22:11, 25 March 2025 (UTC)[reply]
This is the first I've heard of the MS forums, so anecdotally I feel that the attempts to promote it were unsuccessful. Also, The hosting and maintenance cost of the MS Forum is $20K per year. Even if it had worked, I can't imagine it would have ever given us anything near $20k-worth of benefit. I'm wondering if there was ever demand for this, or if it was one of the WMF's many "initiatives" that no one asked for. Thebiguglyalien (talk) 🛸22:54, 25 March 2025 (UTC)[reply]
WMF announcement: Strengthening Wikipedia’s neutral point of view
Sounds like the first step towards creating a global NPOV policy.
In general and in my opinion, English Wikipedia doesn't really benefit from global policies much since we have our own mature policies, so I guess the idea is to provide an NPOV policy for smaller wikis? Reminds me a bit of the meta:UCOC.
As I sometimes see with initiatives on meta, the exact motivation for this has been stated very generally ("global trends", "how trust in information online is declining and a fragmentation of consensus about what information is true"), without giving many specifics about who is pushing for this and what specific incident(s) led to it getting on the radar. –Novem Linguae (talk) 23:51, 27 March 2025 (UTC)[reply]
What are the improvements?
The improved translation dashboard allows all logged-in users of the tool to enjoy a consistent experience regardless of their type of device. With a harmonized experience, logged-in desktop users can now access the capabilities shown in the image below.
Notice that in this screenshot, the new dashboard allows: Users to adjust suggestions with the "For you" and "...More" buttons to select general topics or community-created collections (like the example of Climate topic). Also, users can use translation to create new articles (as before) and expand existing articles section by section. You can see how suggestions are provided in the new dashboard in two groups ("Create new pages" and "Expand with new sections")-one for each activity.In the current dashboard, you will notice that you can't adjust suggestions to select topics or community-created collections. Also, you can't expand on existing articles by translating new sections.
Does this improvement change the current accessibility of this tool in this Wikipedia?
The Content translation tool will remain in beta; therefore, only logged-in users who activated the tool from the beta features will continue to have access to the content translation tool. Also, if the tool is only available to a specific user group, it will remain that way.
When do we plan to implement this improvement?
We will implement it on your Wikipedia and others by 24th, March 2025.
What happens to the former dashboard after we implement the improvement?
You can still access it in the tool for some time. We will remove it from all Wikipedias by May 2025, as maintaining it will no longer be productive.
If you notice an issue related to the improved dashboard in the test wiki, please let us know in this thread and ping me, or report it in Phabricator, adding these tags: BUG REPORT and ContentTranslation.
Please ask us any questions regarding this improvement. Thank you!
This isn’t related to the improvement, but about the content translation dashboard, do you know if there’s any way to get it to stop autofilling new paragraphs with the foreign-language text? Currently when I click “add paragraph” it automatically copies the French text, presumably as an alternative to machine translation, which I must then delete. It would be useful to be able to disable this, as en WP has disabled machine translation, and obviously having French in the final En article is not helpful. Mrfoogles (talk) 15:31, 26 March 2025 (UTC)[reply]
Are any of the 90 or so "comparative ranks" articles in Category:Military comparisons actually about a notable topic, a standard grouping / comparison? Or are they just galleries? I personally see zero reason why enwiki should have something like Comparative army enlisted ranks of the European Union, but perhaps others can argue in general why such articles belong here, or else whether they should be deleted or transwikied somewhere? Not wanting to start 90+ AfDs or one mass AfD if I'm missing something obvious. Fram (talk) 18:30, 14 March 2025 (UTC)[reply]
The ones that deal with one country (say, Military ranks of Eritrea), are probably acceptable as a topic, even if the current execution may be lacking. An encyclopedic article about the military ranks of an individual country should in most cases be possible and should have good sources, considering how many books about military topics get written. Fram (talk) 20:07, 14 March 2025 (UTC)[reply]
Are any of the comparison articles between countries which don't have articles for the individual countries with the insignia already shown? If not then they don't add anything to Wikipedia. I think this problem spreads to comparison articles about other things. Those that aren't galleries are consumer guides, such as the software comparison articles. Phil Bridger (talk) 20:58, 14 March 2025 (UTC)[reply]
This feels like a lot of original research to try to say that ranks in one country's military forces is equality to ranks in another country's military forces, in addition to excessive comparison via mostly images. I see no reason we should have these lists. --Masem (t) 02:32, 15 March 2025 (UTC)[reply]
I would expect state departments to track this so they can get the Order of precedence correct in ceremonial circumstances. You don't want to insult your guests by saying that their 'X' officer is less than your 'Y' officer, when it's the other way around. WhatamIdoing (talk) 05:30, 15 March 2025 (UTC)[reply]
Firstly, articles about the military ranks of a single country are entirely encyclopaedic, as Fram appears to accept above. The question being posed appears to be whether articles on comparative ranks are. Many military history sources provide equivalent ranks to assist the reader in understanding. The fact that a SS-Oberführer in the Waffen-SS didn't really have an equivalent even in the German Army of WWII is useful for the reader to know when mentioning an officer of that rank. If you look at Ranks and insignia of the Waffen-SS it provides equivalents in the German Army of the same period and in the UK and US militaries cited to what appear to be reliable sources. This is exactly what can be found in the appendices of many WWII history books. My preference would be for individual country (or branch) articles of this type to provide information on their equivalents in standard English-speaking militaries like the UK/US rather than attempt to cover a huge number of countries in one article in the way that Comparative army officer ranks of Africa attempts to do. I've mentioned this discussion at MILHIST as others might like to chime in. Cheers, Peacemaker67 (click to talk to me) 02:49, 15 March 2025 (UTC)[reply]
Regardless of all else, all the MOS:DECOR-violating insignias in those comparison articles make it impossible to easily compare ranks... and that kinda defeats the purpose of those articles. Ed[talk][OMT]03:15, 15 March 2025 (UTC)[reply]
I agree that these articles are a problem. Besides the gallery-only nature of many of them, many of the articles have large detailed images of insignia that have not been used for decades or centuries. While there may be discussion in reliable sources about the significance of the appearance of such insignia, that should be conveyed in prose, with images used only to illustrate salient points. Donald Albury15:23, 15 March 2025 (UTC)[reply]
(The latter, btw, has a ton of value as an article beyond just the tables of ranks. I don't know how much there really is to say about comparisons between modern ranks, but articles with that richness seem like what we should be striving for in an article. On the other hand, most of these comparison articles are really just over-illustrated lists.)
And agreed that we should not have to scroll past all the insignia to unearth the data. The insignia aren't what make the comparison useful -- the names and levels of the ranks are. (And on the off chance one has any desire to see the insignia for some specific military/branch/rank, those are easy enough to locate on the pages about that particular military/branch/rank).
For instance, the format in this template is utterly fantastic: {{United States uniformed services comparative ranks}}. Clear, compact, and information-dense. With a sentence or two of context, that could stand alone as a pretty good List article.
Cleaning up Category:Wikipedia requested images/photographs
I've been cleaning up the category Wikipedia requested images. One of the things I found frustrating was that when using the template Image requested there was no quick way to know what subject I could write. So I made this list. The problem I ran into was that there was no consistency of when to use the word images and when to use photographs in the category name. Examples aircraft and aircraft, airports and airports, architecture and architecture, beer and beer just to name a few. (Usually the category for photograph is inside of the category for images of the same subject). Another problem is that some categories don't follow the naming convention of the template, for example Star Wars articles needing photos should be Wikipedia requested images of star wars, Ant articles needing images should be Wikipedia requested images of ants. Obviously not all of the categories can follow this naming convention, but many of them can and should.
From what I can gather a large part of the inconsistency comes from the fact that when you write in a WikiProject template that the article needs a photo (example: {{WikiProject Food and drink|needs-photo=yes}}) then it goes into the photograph category. But when you use the template Image requested it goes into the image category.
I was not sure where to bring this up since there is no WikiProject Images. Also, before someone says it, I know that image and photograph don't mean the same thing. Images can be maps, diagrams while photographs are (as far as I know) usually taken by a camera. In other words: Photographs are always images but images are not always photographs. My point is to simplify these categories and standardise them so that there aren't unnecessary duplicates. And so that we can use the Image requested template more consistently.
My suggestion is that we always use the word images instead of photographs because images includes all photographs but photographs doesn't include all images. Steinninn05:01, 18 March 2025 (UTC)[reply]
I believe the hope here was that it could turn into a work list for photographers: "If you are in Lake Wobegon, please take a picture of..." Non-photo images may be wanted, but I don't think that was the original intention behind this process. WhatamIdoing (talk) 16:46, 21 March 2025 (UTC)[reply]
Wikipedia policy/essay about not citing wikipedia policy/essays without elaborating
Funnily enough, you're the one who motivated me to ask for this, but I digress. I don't see how that wikilink has anything to do with what I'm talking about. Senomo Drines (talk) 20:07, 19 March 2025 (UTC)[reply]
You might be looking for WP:UPPERCASE, thought that's a bit more about not trusting the shortcut to be a full, complete, and accurate description of the rule.
That is very surprising. I expected there to be at least 1 page (essay or policy) dedicated to this topic. All the examples you've listed don't exactly fit in with what I am saying. WP:UPPERCASE is about misinterpreting the shortcut. What I said was to not use the policy without explanation, 2 different things. The other 3 options are also very different. The first is about essays not being the same as policy, the second is on not using "per nom" as a reason, and the third is just an explanation on what "per" means. Senomo Drines (talk) 02:48, 20 March 2025 (UTC)[reply]
Wikipedia does not have policies on details like that. You might not have clicked the WP:WTF link. But it is a good essay on the topic of the question. Johnuniq (talk) 03:31, 20 March 2025 (UTC)[reply]
That one doesn't exactly relate to it either. It is based on excessive use of shortcuts and jargon, different to using them without elaborating. Senomo Drines (talk) 03:37, 20 March 2025 (UTC)[reply]
I'm not being funny, but having to explain WP:UCN (or whatever) as well as direct an editor to WP:UCN where they can read the policy themselves seems redundant. And a waste of time. Sometimes I quote a sentence of a policy and say "per WP:FOOIAN" but that's about it. I'm all for welcoming new people, but we also have policies and editors (even new ones) need to be familiar with them. If someone doesn't like being directed to policy so they can familiarise themselves with it, then I'm not sure how they are going to navigate WP. Peacemaker67 (click to talk to me) 07:19, 20 March 2025 (UTC)[reply]
A common situation is that a group of not-newbie editors are discussing some disagreement over whether certain text should be included, or whatever. In that kind of situation, someone posting a comment consisting of WP:RS or WP:NPOV is unhelpful and borderline trolling. Instead, an attempt should be made to explain why a particular source is or is not a reliable source for a particular claim, or why particular text is or is not neutral. Johnuniq (talk) 08:15, 20 March 2025 (UTC)[reply]
Well, that I understand. But a general policy against using policy shortlinks when interacting with other editors seems unnecessarily draconian. This seems like a sentence along the lines you mentioned could be added to WP:EQ. Peacemaker67 (click to talk to me) 08:35, 20 March 2025 (UTC)[reply]
No one is suggesting there be a new policy. The OP is asking whether there is a policy or other page with the advice in the OP. Johnuniq (talk) 10:27, 20 March 2025 (UTC)[reply]
Don't misunderstand. I am not saying you need to explain what the shortcut means. I am saying you can't just cite it as the basis of your argument. You need to elaborate, ideally quoting a section from it, not just use the shortcut verbatim as is. Senomo Drines (talk) 12:37, 20 March 2025 (UTC)[reply]
Please consider that in accordance with the desire to not just point to an essay, it may be simpler for you to say something like "Can you provide more details on how (page X) applies in this situation?", and of course customizing the question to fit the specific circumstances. isaacl (talk) 17:21, 20 March 2025 (UTC)[reply]
Yes, you could say that, but that doesn't enforce anything. Linking to a rule in Wikipedia pertaining to not elaborating would give you more persuasion in a dispute. Senomo Drines (talk) 17:26, 20 March 2025 (UTC)[reply]
Part of collaborating is engaging in discussion to gain understanding. The simplest remedy to someone not explaining adequately is to politely ask them to explain. (There is of course context to consider as well, so a response has to be tailored to fit the circumstance.) Personally, I feel the existence of an essay on this specific point is too specialized to have much effect on the community. Of course, you can still write one anyway (often essays are most helpful to the author, as the writing process helps clarify their thoughts). I'm just cautioning you to not get your hopes up that it will help with any specific discussion. isaacl (talk) 17:49, 20 March 2025 (UTC)[reply]
In re Yes, you could say that, but that doesn't enforce anything: Policies do not enforce themselves. Editors do that.
Here is a simpler solution… If/When someone points to a policy or guideline, and you are not sure how that policy or guideline applies to what is being discussed… it is your responsibility to ASK for clarification. Blueboar (talk) 19:56, 21 March 2025 (UTC)[reply]
The concept is definitely the same to what I am referring to, but I would like it to not be specific to deletion pages. I suggest moving that section to a more broad-spanning article, there is no reason to have it be selective to deletion discussions. Senomo Drines (talk) 16:10, 22 March 2025 (UTC)[reply]
"degrade" - some staff removed, some services ended, de-funding eg. Pentagon
"dismantle" - massively degraded by removing key staff, most services stopped, massive de-funding to the maximum extent allowed by law eg. US Dept of Education
"closed" - formally closed, no longer a institution
Thanks helpful. I wonder, we need a master list. It's not only DOGE, or DEI. The scale of changes to the Federal gov are unprecedented in US history, and far from over. It's unlike any other previous administration. It's too soon to coin a name for it, like Great Society ("a series of domestic programs enacted by President Lyndon B. Johnson in the United States from 1964 to 1968") but that's probably what will happen using my proverbial crystal ball, this period will get named. We might still start an encompassing article until the name becomes clear. Changes to the U.S. Federal government during the second Trump administration is descriptive but long. -- GreenC20:25, 22 March 2025 (UTC)[reply]
I agree that the changes are unprecedented, and I wouldn't be surprised if it gets named. But I don't know what you envision by an article with a "master list." You can certainly try to create an article that gives an overview, summarizing other relevant articles (e.g., the ones about DOGE, the one about the mass removal of federal data, the one about the mass federal layoffs, the court cases that have already been filed), and identifying them as "Main" articles. But I don't see how you could create a comprehensive article about everything that's going on. FactOrOpinion (talk) 20:46, 22 March 2025 (UTC)[reply]
The changes involved in destroying and weakening America are so vast and occurring so quickly (a drug fueled frenzy) that a timeline/list article will likely be the best we can do. It would link to other articles and use only one wikilink or one or two RS for each listing. With time, some themes will emerge as good enough for their own articles. Check out the timelines listed here to get an idea of how it works: Timelines related to Donald Trump and Russian interference in United States elections They are a very valuable resource. -- Valjean (talk) (PING me) 21:27, 22 March 2025 (UTC)[reply]
Google is misrepresenting Wikipedia with its answer to the search "how did james cook die". When I performed this search, the fourth simple textual response said "He died of tuberculosis on 22 August 1779 and John Gore, a veteran of Cook's first voyage, took command of Resolution and of the expedition. James King ..." This is headed up with the Wikipedia logo and the url to the article. The first search hit is Wikipedia with the correct cause of death, linking to Death of James Cook, whilst the erroneous "tuberculosis" is taken from a misreading of James Cook.
My immediate reaction is that Google are misrepresenting Wikipedia with this incorrect reading of a perfectly well-written article. What is the response of Wikipedia to this sort of thing? ThoughtIdRetiredTIR20:11, 23 March 2025 (UTC)[reply]
Wikipedia has no responsibility for and, moreover, no control over Google or any website or anybody misrepresenting or misinterpreting what they read on Wikipedia, especially when Wikipedia itself doesn't have consistent information. It's a combination of "not our problem" and "who has time for that?". You can always send a correction to Google yourself, but good luck with that. Google Nick Lazzarini (a dancer), and Google will present the beginning of Wikipedia's article on him and then inform you that his spouse is Elizabeth Lazzarini. This information appeared in his article when a vandal put it there in January 2014 (also changing his birth year to 1944 in a subsequent edit), and stayed there till someone removed it in January 2015. Here we are 10 years later, and Google hasn't gone back for a refresh.
Just to be clear, there is nothing wrong with the facts stated in either Wikipedia article dealing with James Cook. This is simply a case of google's AI not being very intelligent. ThoughtIdRetiredTIR08:06, 24 March 2025 (UTC)[reply]
There is a 'large gap' between the date and the actual cause of his death in the James Cook article. This probably led to the error. Secondly, ", who" instead of ". He" in the 'Aftermath' section might have prevented the error. Riteze12:22, 24 March 2025 (UTC)[reply]
W._B._Yeats has an RfC for possible consensus. Infoboxes have been a highly contentious topic in the past so getting more comments would be helpful to help find a consensus. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. It can be found under the heading RFC: Infobox writer proposal. - Nemov (talk) 14:43, 24 March 2025 (UTC)[reply]
Feedback wanted on Wikidata in Watchlist and Recent Changes
Hello everyone,
We are looking for a few Wikipedians to speak with us about their experiences looking at Wikipedia watchlist and recent changes lists. We are especially interested in your understanding and interpretation of the information displayed when the edits are caused by Wikidata.
The format will be a roughly 1-hour long interview with our UX researcher and conducted in English, compensation is available.
If you would like to participate, please register your interest as a reply to this post or on our Talk_page and we will shortly be in touch.
Wait… I thought we had consensus that edits should NEVER be caused by Wikidata. Or am I misinterpreting what is being discussed? Blueboar (talk) 13:18, 25 March 2025 (UTC)[reply]
Ha, well we certainly wouldn't fill the hour with silence, but would have a series of questions and visuals about the information that is currently shown from those watchlist entries caused by a Wikidata edit. You absolutely do not need to be a Wikidata-expert to participate, but we do welcome a cross-section of experience. Feel free to reach out with any more questions -Danny Benjafield (WMDE) (talk) 13:49, 25 March 2025 (UTC)[reply]
These entries caused by Wikidata in your Wikipedia Watchlist or the Recent Changes list can be triggered by a number of ways, including but not limited to:
adding, removing or changing
a language link
a badge
Wikidata item label, description and/or alias
a claim (Property and/or value-pair)
connecting or disconnecting an article to a Wikidata item
Wikidata edits in the watchlist are not visible by default. To include them, you can toggle them from your preferences/watchlist/advanced options section.
It won't take up an hour, but as an initial piece of feedback, enabling the watchlist toggle means every wikidata change is displayed separately, as opposed to the (default) article behaviour of only showing the most recent edit, which can absolutely wreck watchlists. For example, if I currently enable the toggle, my watchlist is a wall of changes to wikidata:Q9027, apparently because Nordic Council is on my watchlist(?). CMD (talk) 15:38, 25 March 2025 (UTC)[reply]
Well no, I didn't. Why is an option for watchlist customisation in the recent changes tab rather than the watchlist tab, and why is its default setting the opposite of what would be implied by the existing watchlist toggle "Expand watchlist to show all changes, not just the most recent"? Questions and anecdote for the UX team. I might give it a try with that enabled. CMD (talk) 15:59, 25 March 2025 (UTC)[reply]
My watchlist is ok on desktop, where the multiple changes to a Wikidata item are rolled up under a clickable right-pointing triangle, but I know what you mean on my phone/Minerva, where I spend more time these days and where the watchlist can be an unsummarised mass of property value and reference changes to a single item. That's where I look forward to discussing th euser experience... AllyD (talk) 16:01, 25 March 2025 (UTC)[reply]
I have this disabled because I don't edit Wikidata anyway, but also because it is mostly useless (as in, you know something has changed, but that's the end of the useful information). If I would get instead of "(diff | hist) . . Dm Michael Buxton (Q133464990); 03:08 . . AntiCompositeNumber (talk | contribs) (Created claim: Property:P106: Q1642960)" the actual values of the P and Q numbers, I might have an idea whether I should check if I were so inclined. And then there are pure errors, like this appearing twice in my watchlist. It's also confusing that "(diff | hist) . . Dm Wikipedia:Authority control (Q76); 14:03 . . Prototyperspective (talk | contribs) (Created claim: Property:P12361: barackobama.bsky.social)" is given as a change to Authority Control, when it is a change to Barack Obama (yes, Obama = Q76, but that's not really something I know for every article on my watchlist).
I thought this option was restricted so only changes which impact enwiki were shown (say, things which would appear in an infobox), but this is no longer the case?
I have no idea what the line "(diff | hist) . . Dm User:Andrawaag (Q31); 18:28 . . RVA2869 (talk | contribs) (Set [nl] aliases: Koninkrijk België, Belgie, BE, BEL, 🇧🇪, be)" does in my watchlist: the diff goes to [29]. Similarly, I get 6 changes like "(diff | hist) . . Dm User:Saarik (Q95592946); 08:06 . . Saarik (talk | contribs) (Removed claim: Property:P8687: 45)" which are changes to a Wikidata article, not a Wikidata user page([30])
I get "(diff | hist) . . Dm Help:Authority control (Q414110); 09:28 . . Ham II (talk | contribs) (Changed [cy] label, description and aliases: Akademie der Künste Berlin, amgueddfa yn yr Almaen, Academi Celfyddydau Berlin, Academi y Celfyddydau, Berlin, Academi Celfyddydau, Berlin)" which is not a change to Help:Authority control but this.
Oh wow, thank you for all the feedback and examples, this is very helpful. Addressing the techno-babble and jargon to those unfamiliar with Wikidata terminology is something we would like to improve. Danny Benjafield (WMDE) (talk) 17:21, 25 March 2025 (UTC)[reply]
MOST ASSISTIVE READERS CANNOT PASS THE NEW CAPTCHA TEST, BLOCKING ALL SUCH EDITORS FROM THEIR ACCOUNTS. PERSISTENT RANGEBLOCKS COVERING THINGS LIKE THE VODAFONE GATEWAY PREVENT EVEN IP ACCESS FOR MANY.
In protest, I am totally off-wiki from this moment on, unless and until this abuse of the disadvantaged ends. So no point in your replying to me personally. (Though I have passed a suggestion for a workable captcha to phabricator).
Hey @ScottishFinnishRadish, I wanted to clarify that this particular change wasn't related with the tests. It was a separate decision, more like a one-off, that's also why we didn't check all accessibility consequences and rolled back that easily. SGrabarczuk (WMF) (talk) 23:26, 28 March 2025 (UTC)[reply]
I think that this should serve as a reminder to many people (including me) that accessibility is not a "nice-to-have" afterthought, but that systems are unusable to many people when it is not designed in from the start. Phil Bridger (talk) 14:16, 28 March 2025 (UTC)[reply]
). There was a long-standing bug where an indication for new notifications was only shown if you had unseen Alerts. This bug is now fixed. In the future, Minerva users will notice a counter atop the bell icon when you have 1 or more unseen Notices and/or Alerts. [8]
View all 23 community-submitted tasks that were resolved last week.
Works for me Firefox 136.0.4 (64-bit). --Redrose64 🌹 (talk) 22:12, 29 March 2025 (UTC)
Oppose. I don't want to see AI taking over Wikipedia. The Master of Hedgehogs (talk) (contributions) (Sign my guestbook!) 16:10, 27 February 2025 (UTC)
But I'm guessing a video over a few minutes long and/or with multiple people editing would get exponentially more tricky to manage. Maryana Pinchuk (WMF) (talk) 01:42, 6 March 2025 (UTC)
Fixed. HouseBlaster (talk • he/they) 19:09, 16 March 2025 (UTC)
You are invited to join the discussion at Wikipedia talk:User pages § RfC: allowing editors to opt-out of seeing floating decorative elements. HouseBlaster (talk • he/they) 23:03, 16 March 2025 (UTC)
wikimedia.org). No deadline is set for applications for this open call, and will remain open until otherwise notified.
#c-AbchyZa22-20250327135300-File:Liverpool_FC.svg){kind=link}