Jump to content

Wikipedia:Village pump (all)

Page protected
From Wikipedia, the free encyclopedia
(Redirected from Wikipedia:VPA)

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.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Village pump sections
post, watch, search
Discuss existing and proposed policies
post, watch, search
Discuss technical issues about Wikipedia
post, watch, search
Discuss new proposals that are not policy-related
post, watch, search
Incubate new ideas before formally proposing them
post, watch, search
Discuss issues involving the Wikimedia Foundation
post, watch, search
Post messages that do not fit into any other category
View all village pump sections at once
Other help and discussion locations
I want... Then go to...
...help using or editing Wikipedia Teahouse (for newer users) or Help desk (for experienced users)
...to find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute Requests for comment
...to comment on a specific article Article's talk page
...to view and discuss other Wikimedia projects Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to ask questions or make comments Questions


Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Rate-limiting new PRODs and AfDs?

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.

A similar situation happened about four months ago, and the solution was just to procedurally revert all of the PRODs: User_talk:Seefooddiet/Archive_1#109 proposed deletions in a couple of hours?

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]
You can also WP:TBAN them after the fact. WhatamIdoing (talk) 22:30, 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]
This sort of thing in general is a matter of good old common sense, no ammount of policy will help here. If you need one, WP:BULLINACHINASHOP would be it. Headbomb {t · c · p · b} 20:37, 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]
    Years, huh. —Cryptic 15:39, 13 March 2025 (UTC)[reply]
    Redirects aren't articles. WhatamIdoing (talk) 15:57, 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. —Cryptic 16:29, 13 March 2025 (UTC)[reply]
    Disambiguation pages aren't articles, either. BeanieFan11 (talk) 16:32, 13 March 2025 (UTC)[reply]
    Can Quarry filter by Special:Tags or edit summaries? Excluding any edit with "Tags: New redirect" or an edit summary containing words like redirect or disambiguation would help. WhatamIdoing (talk) 17:00, 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]
    I also note that Ponor appears to be using a script (PAWS) to facilitate the masscreation. Cremastra (talk) 20:23, 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.
Of course, on the day that happens, I'll be hitting the slopes with my good buddy Satan.—S Marshall T/C 23:08, 13 March 2025 (UTC)[reply]
  • I think this is a fairly specific issue that is better addressed on a case by case basis
Czarking0 (talk) 04:32, 16 March 2025 (UTC)[reply]
  • You'd like to address 93,000 extremely similar articles one by one because...?—S Marshall T/C 10:26, 26 March 2025 (UTC)[reply]
    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 Marshall T/C 14: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]
    You've had years. How much more time will you need?—S Marshall T/C 16:30, 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 Marshall T/C 16: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]
    And that's why I say that "no venue exists in which I'm allowed to be firm."—S Marshall T/C 17:39, 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]
    @Fram @S Marshall @Thebiguglyalien, according to the OP, "NEXIST and NBASIC override NSPORTS2022" and "SPORTSCRIT #5 does not apply" to athletes who meet a subcriterion, which is why he has been deprodding every Lugstub and insisting editors have to have checked all local offline archives to prove no SIGCOV exists at AfD. This has been a problem in particular for non-English subjects, where he often dumps search results that he hasn't even translated as evidence of "coverage" and obliges others to translate them all, after which he will claim that various sentences and sentence fragments add up to BASIC. See also this ongoing headache, and this, and this. JoelleJay (talk) 02:14, 28 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.
    The one exception is the last bullet item in Wikipedia:Notability (sports) § Basic criteria, which is a documentation requirement that doesn't really belong in this section as it isn't a criterion for evaluating if the standards for having an article are met. Nominally, it does run counter to Wikipedia:Notability § Notability is based on the existence of suitable sources, not on the state of sourcing in an article, but it's an exception that was created by consensus agreement, and is really a "document this when you create an article" requirement, rather than a way to determine if an article should theoretically exist by English Wikipedia's standards. For better or worse, Wikipedia:Deletion guidelines for administrators § Rough consensus doesn't require evaluators of consensus to discount opinions that run counter to guidelines, so it's up to participants in deletion discussions to convince each other of the more compelling argument. isaacl (talk) 22:38, 28 March 2025 (UTC)[reply]
    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]
    I agree with this. Cremastra (talk) 20:25, 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.
    I found this article by glancing through the first page of Special:Contribs for the pages he created (it's mostly redirects).
    The benefits of deleting this article would be:
    • We'd really show that already blocked Very Naughty Editor™ that we're so mad about his bad actions that we'll even delete his good ones.
    • Indiscriminate actions – unlike writing a 368-word-long article with 16 refs – don't require editors' time, effort, or thought.
    The cons are:
    • Readers won't have the information.
    • Removing good information is against the mission.
    • Indiscriminate actions are against the community's values.
    • We're Wikipedia:Here to build an encyclopedia, not to grandstand about how awful the Very Naughty Editor was and how just blocking him is not good enough.
    • 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]
    Or we could just delete the ones that don't currently have significant coverage, like I said above. Thebiguglyalien (talk) 🛸 23:01, 26 March 2025 (UTC)[reply]
    Which requires manual review, which is the opposite of mass deletion. WhatamIdoing (talk) 00:01, 27 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 Marshall T/C 23: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 Marshall T/C 08: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 Marshall T/C 10: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.
If someone would like to do this, then they need to follow the WP:MASSCREATE procedure. Also: We're missing quite a lot of insect articles, but we have almost all the mammals already. WhatamIdoing (talk) 20:13, 27 March 2025 (UTC)[reply]
Why should they be blocked if their creations are perfectly within the guidelines.... JoelleJay (talk) 14:38, 28 March 2025 (UTC)[reply]
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 Marshall T/C 23: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.
I just added two sources to that article, BTW. WhatamIdoing (talk) 04:14, 28 March 2025 (UTC)[reply]
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 Marshall T/C 08: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]
Specifically, I was paying attention to Wikipedia:Administrators' noticeboard/Archive332#Suggested block for Carlossuarez46, where editors say things like "One of the worst periods for Carlos's article creation activities appears to have been in July 2009". WhatamIdoing (talk) 18:33, 28 March 2025 (UTC)[reply]
... nothing there supports your previous claims. The very next post beneath your quote here says " As far back as 2009 Carlossuarez46 has been completely dismissive of anyone who suggested that his article creations were questionable, consistently refusing to acknowledge that his mass-productions include errors or fail to demonstrate verifiability and/or notability. " This was the kind of reaction they gave back in 2009. But sure, Carlossuarez is the one being yelled at unfairly, and somehow this spin means that these current ProDs are unacceptable. Fram (talk) 12:28, 31 March 2025 (UTC)[reply]
Well, I think that when multiple people in a 2021 discussion mention article creations in 2009, then they (i.e., those editors, but not necessarily all editors) are probably talking about edits made in 2009. You are not, however, required to agree with me about that or anything else.
My point is this: The community finally intervened in 2021. We wouldn't have had these problems if the community had taken this action in 2009. What can we do now to avoid future problems?
Or: Do you want, in 2030, to be talking about how User:NewBadJob started producing badly sourced articles about possibly non-notable subjects in 2025, but we ignored it at the time, so now there are not only thousands of Lugnuts stubs and thousands of Carlossuarez46 stubs to deal with, but there are also now thousands of NewBadJob stubs to deal with? I don't. I'd bet "dollars to doughnuts" that you don't either.
So what can we do now to stop that? For example, should someone who noticed an editor regularly creating 50+ non-redirect articles in a single day maybe inquire at ANI about enforcing WP:MASSCREATE on that editor's creations? Should there even be someone regularly checking for that behavior? WhatamIdoing (talk) 20:41, 31 March 2025 (UTC)[reply]
...How is any of this relevant to the post you are responding to?
You said (emph mine) 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. @Fram refuted this with the fact that editors in both 2021 and 2009 were complaining about the CS articles failing V and N, PAGs which far predate 2012. JoelleJay (talk) 21:08, 31 March 2025 (UTC)[reply]
Subazama, California, as he wrote it in 2009, appears to have complied with both WP:N and WP:V. WhatamIdoing (talk) 21:34, 31 March 2025 (UTC)[reply]
  • Just saw this mess, which I was completely unaware of. I'm not really into sports; therefore, I don't closely follow WP articles on Olympics athletes. As a lawyer who occasionally deals with document review issues, it seems to me the best solution would be to cut the Gordian knot by sampling a few dozen Lugnuts articles to identify threshold criteria to establish where such an article is almost certainly bot-created, have a bot scan all of Lugnuts's contributions to identify all such articles, and then get approval to run another bot to delete all of them. For example, if an article was (1) created by Lugnuts and is (2) still currently supported by one or two citations to sources known to be of poor quality (that is, no one coming across that stub has bothered to write a decent article), then delete it. That would likely reduce the article stubs to just the articles that were later edited to add more content about the subject but are still of poor quality. I agree with the editors who argued above the burden was on Lugnuts to establish significant coverage of the subject matter in the first place before creating those articles. I strongly disagree with the editors arguing in favor of keeping the bulk of the articles thus created, the vast majority of which are unlikely to be fixed. As an experienced WP editor, I can tell you that things only get fixed on subjects which people really care about. For example, it took me over five years to research and rewrite Product liability into a decent article about the subject. That's just one article. Lugnuts created tens of thousands. --Coolcaesar (talk) 02:36, 7 April 2025 (UTC)[reply]
    @Coolcaesar, see WP:LUGSTUBS. That very approach encountered a LOT of resistance from people who insisted that losing a few stubs that might be on notable athletes is much worse than clearing out dozens of permastubs... JoelleJay (talk) 15:06, 10 April 2025 (UTC)[reply]
    It was demonstrated that dozens and dozens of them were notable despite having barely any access to archives of the time! BeanieFan11 (talk) 15:36, 10 April 2025 (UTC)[reply]
    While the vast, vast majority were not salvageable and ended up deleted or redirected. 33/924 is 3.6%. JoelleJay (talk) 16:14, 10 April 2025 (UTC)[reply]
    Of Lugstubs? They're all sitting in draftspace because no one wants to work on them, no matter how notable they may be. There's actually a number of them that I've identified as very obviously notable but have never got around to improving. There's like two other people who have even attempted to improve any of them in draftspace. That very few have attempted to work on them does not at all mean they're not notable. BeanieFan11 (talk) 16:18, 10 April 2025 (UTC)[reply]
    It's been over 2 years since LUGSTUBS was started, and 4–15 years since any of the stubs were created, and only 33 of them have become bluelinks. There are two global consensuses that SIGCOV cannot be presumed to exist for any of them. Both the evidence and our PAGs strongly suggest these subjects do not warrant standalone articles. JoelleJay (talk) 17:04, 10 April 2025 (UTC)[reply]
    I agree that SIGCOV cannot be presumed to exist just because they were Olympians. But that isn't relevant. What is relevant is that many, many, many of them have SIGCOV, but due to no editors being interested they are not restored to mainspace even though they absolutely should be. BeanieFan11 (talk) 17:12, 10 April 2025 (UTC)[reply]
    You, personally, presume that many, many, many of them have SIGCOV, against the consensus on that presumption... JoelleJay (talk) 17:21, 10 April 2025 (UTC)[reply]
    No, I've found SIGCOV for many, many of them... BeanieFan11 (talk) 17:23, 10 April 2025 (UTC)[reply]
    And even then, these notable subjects are better off not having articles until someone is willing to come around and actually put a modicum of effort into them, instead of trying to protect mass-produced 1–2 sentence garbage. Thebiguglyalien (talk) 🛸 16:22, 10 April 2025 (UTC)[reply]
    What benefits a reader more: learning two sentences about a subject they want to know about, or absolutely nothing? BeanieFan11 (talk) 16:27, 10 April 2025 (UTC)[reply]
    If this is the metric, then we shouldn't have any minimum in terms of notability or quality. We might as well create a one sentence stub for everything in the world that could feasibly be notable and then remove them one at a time. The fact is that these articles never should have been created as they are in the first place, and the only reason they exist right now is WP:FAITACCOMPLI. Thebiguglyalien (talk) 🛸 16:34, 10 April 2025 (UTC)[reply]
    Of course there still needs to be notability criteria – maybe I should have clarified: what benefits a reader more: learning two sentences about a notable subject they want to know about, or absolutely nothing? You seem to be saying to delete notable subjects on the basis that having nothing at all is better than something, since there's 'the possibility' that at some point in the future, someone will decide to write a longer article on them; of course, the longer article could be written just the same with the short article already being here... BeanieFan11 (talk) 16:39, 10 April 2025 (UTC)[reply]
    Which is missing the point. The fact that longer article could be written says nothing about whether it will ever be written. In the long run, we are all dead and that long article will never be written because most people who care about dead athletes (as distinguished from the currently alive ones on their local major league team) want to write about the winners, not the losers. Not everyone gets to go home with a medal. Not everyone is notable enough to justify a WP article.
    My guess is that the only time people care enough about less prominent athletes to write WP articles about them is that either they are family relatives (which presents WP:COI issues) or out of schadenfreude.
    For example, I recently expanded the short article on John B. Frisbie because I noticed an interesting contrast. Today, Vallejo is among the poorest, polluted, economically depressed and crime-ridden cities in Northern California. I thought it was fascinating that the man who founded and developed that city lived a very full life as a lawyer, politician, military officer, and businessman. Unfortunately, most current residents of Vallejo do not live up to the example of the city's founder.
    If someone really cares about the article subject, they will do the research, then create the WP article again and actually write the article. In the meantime, there's no point keeping empty stubs around. --Coolcaesar (talk) 17:04, 10 April 2025 (UTC)[reply]
    There absolutely is a point to having stubs. A third of this entire website is stubs – and substantial portion of the notable stubs, if deleted, will not be recreated because we don't have enough interested editors. That doesn't mean there aren't interested people. We should do what benefits our readers. Getting rid of notable articles en masse in hopes of some editor deciding to recreate some of them in the future is both a substantial waste of editor time and a disservice to our readers who lose all the information about the notable subjects that they could previously find. BeanieFan11 (talk) 17:12, 10 April 2025 (UTC)[reply]
    Two sentences that could be and much of the time are already stated in the encyclopedia elsewhere... JoelleJay (talk) 16:51, 10 April 2025 (UTC)[reply]
    The Olympians are, usually, only mentioned on the results page in a massive list of competitors with their scores. By getting rid of the articles, we lose the two stats sources that give personal details and sometimes biographies, we lose their birth/death dates, measurements, hometown / place of death, etc., and we also lose links to other language Wikipedias that often give further details. I'd rather have the article than "Athlete - Country - finished 8th", or things like that. BeanieFan11 (talk) 16:57, 10 April 2025 (UTC)[reply]
    Plenty of verifiable details exist that do not belong on Wikipedia. Olympedia should be the top result for anyone interested in that information, just like WormBase should be the top result for details on C. elegans gene orthologs (most of which receive orders of magnitude more IRS SIGCOV than most athletes...). JoelleJay (talk) 17:11, 10 April 2025 (UTC)[reply]
    +1 to what JoelleJay said. Wikipedia cannot be everything to everyone. Cremastra talk 19:42, 10 April 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]
Mass-creation has always been controversial, going all the way back to Rambot in fact and directly led to the creation of the bot policy. See e.g. [5] starting with Dachshund's inquiry. Many of the same arguments presented there are still being made today; nothing new under the sun. 184.152.65.118 (talk) 02:10, 6 April 2025 (UTC)[reply]

Testing the waters: Overturning USPLACE

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.
  • Naturalness: Readers are likely to search Louisville instead of Louisville, Kentucky just because of typing efficiency, and in articles, the short form is usually linked to (example: in Louisville Muhammad Ali International Airport). This satisfies both subcriteria in the Naturalness section.
  • 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.

—🐔 Chicdat  Bawk to me! 19:11, 7 March 2025 (UTC)[reply]

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. 🐔 Chicdat  Bawk 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]
Not everything has a primary topic. John Smith is such a vague, common name, that of course there isn't one. But Boston, Mass., not Boston, Lincolnshire, is clearly the primary topic and thus does not need a disambiguator. voorts (talk/contributions) 22:30, 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]
I'd say that having 15 times as many residents in the city and 70 times as many in the surrounding area is good evidence towards being primary. WhatamIdoing (talk) 02:32, 16 March 2025 (UTC)[reply]
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]
I think Zzyzx11 has the right idea Czarking0 (talk) 04:40, 16 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]

(edit conflict) Admin recall was soundly rejected for two decades before passing in 2024. Consensus can change, and it does. To Davidstewartharvey, the proposal is only for articles such as Louisville, Kentucky, to which Louisville redirects. If this proposal were to pass, Louisville, Kentucky would be moved to Louisville. And once again, no evidence that this is the style in American English. 🐔 Chicdat  Bawk to me! 20:04, 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]
That would make the disambiguation page malplaced. If you think this primary redirect is incorrect, you can request that Louisville (disambiguation) be moved to Louisville. jlwoodwa (talk) 19:33, 10 March 2025 (UTC)[reply]
If Americans want to be excpetional then let's let them do it somewhere relatively harmless, like this. Phil Bridger (talk) 20:41, 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]
Which is my point about Primary that I raised, you dont instantly think Louisville, Kentucky but one of the others! Davidstewartharvey (talk) 06:17, 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. BD2412 T 03:43, 11 March 2025 (UTC)[reply]
I'd go for this too, but wouldn't want to overturn USPLACE entirely. Elli (talk | contribs) 15:37, 27 March 2025 (UTC)[reply]

Reminder that someone should post an announcement at WP:USCITY too, because this topic affect far more editors than just those who watch the WP:USPLACE article. • Sbmeirow • Talk • 00:44, 11 March 2025 (UTC)[reply]

Notified: Wikipedia talk:Naming conventions (geographic names). jlwoodwa (talk) 02:13, 11 March 2025 (UTC)[reply]

Wikipedia:Notability has an RfC

Wikipedia:Notability has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Mrfoogles (talk) 18:54, 4 April 2025 (UTC)[reply]

Wikipedia Talk:Notability (music) has an RfC

Wikipedia Talk:Notability (music) has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you.

Note: The RFC pertains to an interpretive issue with regards to WP:NSONG relative to WP:GNG. The former has an absolute prohibition on album reviews as a source of song notability, because they do not cover the song individually. However, WP:SIGCOV and WP:GNG explicitly allow for "significant" coverage as a grounds for notability, even if it is not the sole or main focus of the source. I would appreciate the feedback of anyone who is very familiar with WP:NSONG FlipandFlopped ツ 18:20, 5 April 2025 (UTC)[reply]

Wikipedia’s Content Integrity in the Age of AI-Dominated Search

The AI Spotlight is being beamed at us from inside the village pump. Boldly hatting, as I see no way this mode of inquiry will end up being productive. Remsense ‥ 论 05:42, 9 April 2025 (UTC)[reply]

Lately, it’s kinda hard not to notice that Wikipedia just doesn’t pop up in search results the way it used to. Instead, more and more, we’re seeing these AI-generated summaries—like the ones from Search Labs or AI Overview—taking the spotlight. That might seem like just another tech trend, but honestly, it could spell trouble for Wikipedia’s future. If people—especially younger folks—aren’t getting directed to the site, it’s gonna get harder and harder for the project to stay relevant or even be seen by the people who’ve always relied on it. Sure, some of this shift is just how search engines are changing. But it also feels like there’s stuff going on inside Wikipedia that’s not helping either. There’s been more talk lately about bias in some articles, and the way certain topics get edited and re-edited can come off as messy or kinda one-sided. It’s not always easy to tell what’s really neutral anymore, and when trust starts slipping, it’s no wonder people look elsewhere. That’s why I think it’s time to double down on keeping things fair and balanced. Nothing too crazy—just some tighter moderation, especially on the kinds of pages that always seem to spark drama. Not to shut anyone up, but to make sure the info stays accurate and doesn't lean too hard in any one direction. Maybe having more experienced editors or small review teams checking in on hot-topic pages could help smooth things out too. Also, if we wanna keep Wikipedia alive for the next gen, we’ve gotta start meeting them where they are. They're growing up with AI and TikTok, not long-form articles. So finding ways to make Wikipedia more approachable—or at least more visible—should be part of the plan too. At the end of the day, Wikipedia's special because it's open, collaborative, and built on trust. If we can keep that spirit alive while adapting just enough to stay in the game, I think it still has a strong future. But if we let it fade out of sight, it’s only gonna get harder to bring it back. Xhivetozaragrivropa (talk) 08:10, 6 April 2025 (UTC)[reply]

I'm from India. In a recent reddit post, I found that Wikipedia is no longer in top 10, whereas ChatGPT is at 7th. I have also noticed that Wikipedia is no longer among the top search results as Google and Bing rush to promote their own AI summaries at the top. It would be good if something could be done about it. —CX Zoom[he/him] (let's talk • {C•X}) 12:46, 6 April 2025 (UTC)[reply]
It depends on what you google, doesn't it? At least for me in the USA, the top two search results for any actor are their Wikipedia article and their IMDB page; an "AI Overview" doesn't pop up. If you google questions like "what is the net worth of selena gomez", then an AI Overview pops up as the first result (Wikipedia doesn't appear on the first page, but it does appear when you click the small icon after the AI-generated answer). Some1 (talk) 13:59, 6 April 2025 (UTC)[reply]
An "AI overview" is not actually part of the search results. It is something that the search engine offers you as an alternative to the search results that you actually asked for. Essentially, it is spam. It's annoying that idiot search companies are wasting huge amounts of carbon footprint on AI output that nobody even asked for but there's nothing we, as Wikipedia, can do about it. Sanity will prevail at some point but, until then, all I can say is that some search engines let you turn it off and I'd recommend using one of those over the ones too arrogant to allow the user to decide what they get. --DanielRigal (talk) 14:14, 6 April 2025 (UTC)[reply]
If they are as useless as you say, I imagine it will quickly vanish. If they remain, though, I suspect that they will improve with time. Wehwalt (talk) 16:48, 6 April 2025 (UTC)[reply]
Appreciate everyone’s views here. The landscape is changing quite fast, but the value of what we do here on Wikipedia hasn’t changing a bit. Xhivetozaragrivropa (talk) 07:37, 7 April 2025 (UTC)[reply]
Please don't start a discussion with a blatantly AI-generated message. It wastes everybody's time. JayCubby 18:23, 6 April 2025 (UTC)[reply]
Fully concur with User:JayCubby's analysis of the situation. A quick comparison of the message above with any three or four of that editor's posts (for what appears to be a WP:SPA) reveals glaring discrepancies in style and tone. Enough said. --Coolcaesar (talk) 02:01, 7 April 2025 (UTC)[reply]
I must say it's not the classic GPT spam, it has been prompted to act more natural, which is why I think more people haven't noticed. @Xhivetozaragrivropa, is this correct? JayCubby 02:13, 7 April 2025 (UTC)[reply]
Well thats incorrect. Xhivetozaragrivropa (talk) 07:33, 7 April 2025 (UTC)[reply]
@Xhivetozaragrivropa Do explain, then, why it reads (and GPTZero detects as) it's been generated by a large language model. JayCubby 13:48, 7 April 2025 (UTC)[reply]
Have you read the disclaimers on those tools? A while ago, I ran some of my own writing (mainspace contributions) through one, and it was 50–50 whether it would tell me that it was written by an LLM. These are things I know I wrote myself; some of them are even things I wrote before LLMs were generally available to the public.
I hope the detection tools are getting more accurate, but do please remember that it's difficult to guess someone's ordinary style from a mere 26 edits (most of which aren't discussion comments, and one comment just says "ok thanks"), and that LLM detector tools are not necessarily any more reliable. WhatamIdoing (talk) 00:41, 9 April 2025 (UTC)[reply]

Point of order This page is for proposals about policies and guidelines. The initial post does not have any actional proposal; it is just a long cry of a despaired soul. Not that I do not share the expressed concerns, but I expect that lacking focus, the section will degenerate into an idle chat (or sizzle). Therefore I suggest to close it. If somebody can filter out some potentially actionable items, it is better to have each of them in a separate focused section. --Altenmann >talk 01:29, 9 April 2025 (UTC)[reply]

Actionable points
1. Revoke exclusive human administrator control over high conflict or contentious topics and enforce ai driven moderation systems to deliver consistent, impartial, and real-time oversight addressing the persistent shortcomings of manual governance. Xhivetozaragrivropa (talk) 04:38, 9 April 2025 (UTC)[reply]
The link between your introduction and this points of action is not apparent. How do search engines rank Wikipedia in their results have to do with content moderation on wiki? – robertsky (talk) 04:47, 9 April 2025 (UTC)[reply]
 Sounds like a duck quacking into a megaphone to me-- GreenC 05:13, 9 April 2025 (UTC)[reply]

OP seems to have an axe to grind with CTOP, but as their AI appears to be the one actually speaking to us—if indirectly, filtered through prompts—I see literally no way for this line of inquiry to be productive. OP, if you want to discuss some aspect of site policy (whatever it is) please be more considerate to those reading your messages going forward, and try using your own words if you can. Trying to decode posts like these is a heretofore-unprecedented level of futile and alienating. We can't be expected to do it. Remsense ‥ 论 05:42, 9 April 2025 (UTC)[reply]

Position of the bottom navbox

Wikipedia screenshot

I was reading the article Rodong Sinmun, scrolled it down to the position shown in the screenshot, thought "OK, I'm done with this one", and was about to close the page but then remembered that there may be a navbox...<scroll-scroll> somewhere...<scroll-scroll-scroll> down... below. And sure it was, and it turned out to be a useful update for whatever I was looking for.

I am pretty much sure that occasional readers might not even suspect that there are navboxen, especially when they are collapsed and do not catch an eye, thus defeating the purpose of a navbox.

Suggestion: Update the guideline to allow the placement of navboxes right above the "References", "Notes" etc. sections, for better visibility on the navigation tool.

  • Clarification per discussion with Moxy: "... for the navboxes which navigate among subtopics of a larger topic. Suitable for move: {{Isaac Asimov novels}}; unsuitable (IMO): {{Academy Award Best Actress}}" - I feel that novels of the same author are more tightly related than the actresses who received the same award.

Reationale:

  • A better visibility of the navbox. Heck, we are already wasting the precious real estate on top with vertical navboxen and infoboxen who are often in numbers and larger than articles themselves :-)
  • Logically a navbox is very close in its function to the "See also" section, so it makes sense to keep them together.
  • It is not detrimental to the "Refs", because people do not peruse the "Refs" like other sections: they click the footnote link, read the ref (may be look into its ext link) and then click the uplink to continue reading the article. Meaning the placement of "Refs" is non-critical and the only concern for it to be somewhere down, to be inobtrusive. But if there are navboxen "REfs" becomes obtrusive.

P.S. Suddenly it came to my mind to take a peek at Donald Trump... Big mistake :-) The article length is 29 screens, while the "Refs" took... <ta-daaa!>... 38 sreens!. So nobody will ever find "Articles related to Donald Trump".
Nu? --Altenmann >talk 01:18, 9 April 2025 (UTC)[reply]

Navbox are not seen by 65 percent of our readers so kind of a pointless thing nowadays that have always been at the bottom of the page. They are omitted from mobile view because they are basically considered mass link spam that cause loading problems as seen at Meryl Streep#External links. As for sources this is literally the purpose of our mission to provide them WP:Purpose. Moxy🍁 01:34, 9 April 2025 (UTC)[reply]
Ideally, in a well-developed page, any very relevant links would be in relevant locations in the article, so the navboxes would be mostly redundant. I doubt most of the Meryl Streep links are in the article, but I also doubt most are hugely relevant. CMD (talk) 01:38, 9 April 2025 (UTC)[reply]
In general it's mainly pop culture articles that have these types of problems..... that is mass template spam. However I guess sidebars are excluded from mobile view as well for the same reasoning? Moxy🍁 01:50, 9 April 2025 (UTC)[reply]
My beginning example begs otherwise: I found the navbox useful. I had no idea about all this North Korea press and I see no reasonable way to squeeze all of them into the article body. --Altenmann >talk 02:10, 9 April 2025 (UTC)[reply]
Squeeze? It's a 550 word article, and Mass media in North Korea also has a lot of space to grow. CMD (talk) 02:43, 9 April 2025 (UTC)[reply]
Huh? That's my point. While all items of the template may (even should) be put into the "Mass media" page, it is meaningless to "squeeze" them into the body of the "Sinmun" article. --Altenmann >talk 02:59, 9 April 2025 (UTC)[reply]
Sorry, Moxy, your comments are not arguments against my proposal. (1) This is the problem of the developers of mobile view. (2) now come navboxes are link spam? (3) Meryl Streep#External links have nothing to do with navboxes. the purpose of our mission to provide them - I always thought that the aim of the purpose of our mission is to provide information, neither I am sugesting to delete the refs. --Altenmann >talk 02:10, 9 April 2025 (UTC)[reply]
Perhaps I am misunderstanding what you're saying....you seem to be proposing adding the navboxes to the see also section....thus we would move all navboes to the see also section? In my view to see also section is for very closely associated articles that actually didn't make it into prose of the article....Navboxes are for loosely related topics..... thus should be seen after references about the actual topic that the article was built on.Moxy🍁 02:20, 9 April 2025 (UTC)[reply]
You understood me almost correctly, with one small, but important difference (sorry I didnt bring a proper attention to this, being not aware of Meryl Streep horror :-): I wrote "to allow the placement of navboxes", rather than "move the navboxes". Suggestion updated. --Altenmann >talk 02:56, 9 April 2025 (UTC)[reply]
I see now. But I would rather put them to AfD. In my view, navboxes are for navigation among subtopics. It is difficult for me to see how Meryl Streep is a subtopic of "Academy Awards". Probably we have to reconsider the whole idea of navboxes. --Altenmann >talk 02:56, 9 April 2025 (UTC)[reply]

The bottom of the page can be quickly accessed by keyboard users using the End key (Command-Down on MacOS), so personally I like having navboxes at the end. Perhaps there should be a standard heading for them so those who are unable to use keyboard shortcuts (or prefer not to) can access them from the table of contents. isaacl (talk) 03:03, 9 April 2025 (UTC)[reply]

One of my points was that a random reader has no reason to look for navboxes, shortcut or wormhole. --Altenmann >talk 03:10, 9 April 2025 (UTC)[reply]
A table of contents entry would both show the presence of additional navigation links as well as their position. isaacl (talk) 03:12, 9 April 2025 (UTC)[reply]
Changing the position after 20 plus years would probably confuse the 30% or so that actually see these. For multiple decades everyone knows the linkspam to loosely related articles can be found at the bottom of the page under the external links header. The most irrelevant stuff ends up at the bottom. Moxy🍁 03:18, 9 April 2025 (UTC)[reply]
I'm not suggesting to change the position. isaacl (talk) 05:31, 9 April 2025 (UTC)[reply]
I think they are placed fine, but I don't have strong opinions on it. About the question of their usefulness more generally, navboxes are very useful IMO. However demonstrated with the Meryl Street example above, there are some specific topics where you get like 40 on one page, which defeats the point utterly... there has to be some solution here but I don't know what. Typically politics and entertainment are the problem areas here. I however do find other kinds of navboxes very useful. This is different to sidebars, which are uniformly terrible outside of like two situations, and which I think should not exist. PARAKANYAA (talk) 03:21, 10 April 2025 (UTC)[reply]

A separate "kids version" of Wikipedia

I understand this is sort of a perennial proposal, but hear me out for this one:

Instead of censoring wikipedia, which goes against WP:NOTCENSORED, we should have a separate, kid-friendly version of wikipedia called "Wikipedia Kids"(bit like how mobile wikipedia is slightly different). This does not go against WP:NOTCENSORED, and protects children at the same time.

Many children use wikipedia for a variety of purposes(hell, I'm still a teenager) and i would rather not have people seeing some not so kid friendly stuff here.

Here is how i think it should work:

Normal version remains uncensored and has no changes

The Kids version is practically the normal version, but:

  1. Sexually explicit articles cannot be accessed and are not available on the kids version(to what extent it should not be available can be debated, such as should we make them unavailable completely or just have a smaller, safe, educational version of the article that focuses on stuff the kids actually need to cover in say, biology).
  2. Gory or violent pictures are unavailable. The pages are still available for reading, e.g. we still keep the nanjing massacre article up however the photos will be removed. This ensures we aren't doing stuff like Holocaust or Nanjing massacre denial while still protecting kids.

Overall this is similar in function to WP:CENSORMAIN

Would like to hear your opinion on this. Additionally, to what extent sexually explicit/violent articles is censored, and what counts as "sexually explicit" or "violent" can be debated. Thehistorianisaac (talk) 15:32, 10 April 2025 (UTC)[reply]

Just noting that there are already a number of these in various languages. Sam Walton (talk) 15:35, 10 April 2025 (UTC)[reply]
maybe it could theoretically work on paper as an option that can be toggled (in which case i'd be against having it on by default), but it absolutely wouldn't work out as its own site (even if it was mostly a mirror) due to the sheer size of the wp-en
even then, i think it'd be way too hard to program, harder to enforce, and even harder to maintain, since how would those filters even work outside of trudging through the entirety of the wmf to filter things on what's effectively a case by case basis?
lastly, it also depends on conflicting definitions of "for kids", because you know one of those ankle-biters will have to study up on world war 2 at some point, or sex, or that one time the british colonized a place, or that one time the americans killed people and took over their land manifested their destiny, or literally anything even tangentially related to any religion that isn't satirical (nyarlathotep help them if they're in a jw or mormon environment), and keeping them out of it would only really cause easily avoidable headaches consarn (prison phone) (crime record) 17:18, 10 April 2025 (UTC)[reply]
I agree on kids the "for kids" definition. That is why I would suggest for the kids version, sex-related articles with no connections to sex ed be unavailable, while sex-related articles related to sex ed only show diagrams and be reduced. As for violence, I would not suggest censoring anything other than some of the photos, or possibly even limiting it to a "Show photo-Disclaimer: may contain violence". Thehistorianisaac (talk) 17:33, 10 April 2025 (UTC)[reply]
Why pick on sexually explicit articles? I don't mind my children or grandchildren (the latter of which are aged five, three, and a month) accessing details about sex, but would prefer that they didn't access some other material, such as graphic violence or material about suicide. I'm sure that there are many different views from parents and grandparents. Phil Bridger (talk) 18:03, 10 April 2025 (UTC)[reply]
it's just the easiest example to name, really consarn (prison phone) (crime record) 18:40, 10 April 2025 (UTC)[reply]
let's say that happens. how, then, do you know what will be taught in sex ed? how would you attempt to reduce what is shown in order to make it less explicit without touching the text? how wo- actually, having to choose to see the pictures is nice, no complaints there consarn (prison phone) (crime record) 18:45, 10 April 2025 (UTC)[reply]
Did you do some thinking on how this can be implemented and how much workforce will be required and how much bitter squabbling will follow on whether a picture of a buttocks is permitted and whether sucking the dick properly is part of sex education. (You may think the latter was a joke, but I remember seeing on a Disney Channel an episode where two low-teen girls pressed a boy to explain them how to suck the dick properly.) --Altenmann >talk 18:04, 10 April 2025 (UTC)[reply]
i say this as a former child from a country best known for playstation 2 piracy (which is to say i knew about the hot coffee mod when i was 8): nearly anything we could do would at best do absolutely nothing to protect children lmao. if anything, it'd just fan the flames of their curiosity, because they wanna see the buttocks!! hell, even the idea of it working by censorship comes off more as pandering to overly sensitive parents than attempting to "protect" the leeches on their legs. even then, protect from what? from knowing what "fuck" means? from knowing what a peepee (that could potentially be the one in their own lower torso) looks like and does? from knowing about that angry mustache model who hated jews for existing?
for better or worse, children will find their way into whatever they want, regardless of whether or not they can handle it (though they usually can), and drawing an arbitrary line would only make them want to cross it more than their tiny, evil brains already instinctively urge them to consarn (prison phone) (crime record) 18:39, 10 April 2025 (UTC)[reply]
This is a great idea for a third-party service, as they can select for inclusion whatever materials they feel meets their own sense of restriction. The Wikipedia license gives them the freedom to do so, and there could even be various versions with different perspectives as to what is appropriate.
It makes a horrible project for Wikipedia itself to do, however, because then we have to establish an Official Standard for what is improper, and that will both lead to endless bickering and complaints from those who want to provide the censored version that we are not censoring the things that they wish to have censored. You can see how we would face massive complaints if we decided, say, that material on drag entertainment was suitable for kids, or if we said that it wasn't. The group control that Wikipedia projects have and our spot at the most visible source of data would just make this too fraught. -- Nat Gertler (talk) 18:10, 10 April 2025 (UTC)[reply]
"For kids" versions of reference materials are usually written for a specific audience based on age/intellectual ability. To meet the expectations set up by the name, the articles should be specifically organized and written at a less complex level, which can mean different ways of breaking down topic areas as well as a different language level. simple:Simple English Wikipedia currently exists to fill that niche, and would be a better starting point for a kids version. As you noted, though, there are a lot of objections from the community to embedding content filtering as a core function that requires altering the underlying base articles. So at present, any filtering would need to be entirely add-on and optional, and using categorization being stored elsewhere, such as on Wikidata. isaacl (talk) 18:14, 10 April 2025 (UTC)[reply]
I was just about to note the existence of the Simple English Language Wikipedia. Isaacl beat me to it. Blueboar (talk) 18:23, 10 April 2025 (UTC)[reply]
I could see something like this becoming its own project, similar to simple English wikipedia. I'd even contribute to it, I enjoy the mental challenge of simplifying a difficult concept into something a child could understand mgjertson (talk) (contribs) 19:26, 10 April 2025 (UTC)[reply]
Since this discussion seems to be moving away from child-protective censorship and towards child-centred language simplification, I'll not the existence of b:Wikijunior, a worthy project. Cremastra talk 19:53, 10 April 2025 (UTC)[reply]

RfC: "Illegal" immigrant vs "Undocumented" immigrant in article mainspace

 You are invited to join the discussion at Talk:Illegal immigration to the United States § Terminology: "Illegal" immigrant vs "Undocumented" immigrant in article mainspace. Some1 (talk) 22:48, 10 April 2025 (UTC)[reply]

Technical

Issues loading images since late-March 2025

Hi, I've recently noticed while browsing Wikipedia and sister projects (Commons) that images are occasionally failing to load. Some will render without issue while others will either appear on the page as a placeholder broken image symbol or still be visible but when clicked and maximised, they fail to load with a "sorry, the file cannot be displayed." error message. Looking at the commons page for an effected image shows that some of the resolutions work fine whilst others still throw errors. It's been a few days and I haven't seen any comments on here on this specific issue yet so I am saying it now. Hopefully the team are working on fixing whatever is causing this behaviour? Slender (talk) 19:17, 2 April 2025 (UTC)[reply]

I had that problem with a single image awhile back. Tried everything, including clearing my browser cache, purging the article containing the image, and restarting my computer. So I gave up, and the problem disappeared after a few days. Patience is a virtue, sometimes. ―Mandruss ☎ IMO. 19:21, 2 April 2025 (UTC)[reply]
Can you share a couple of examples of images that fail and images that work? Matma Rex talk 20:22, 2 April 2025 (UTC)[reply]

Sure. Here's a few of the broken ones pulled from the article Gangway connection:

Working images:

I also uploaded a screenshot to show the broken images and how the page looks on my end. https://en.wikipedia.org/wiki/File:WPBrokenImagesScreenshotExample.PNG Slender (talk) 21:02, 2 April 2025 (UTC)[reply]

All of the images at Gangway connection are working for me. When I had the problem, others didn't see it. That's why I gave up, blaming myself. ;) That was at Donald Trump, btw. Just one problem image. ―Mandruss ☎ IMO. 23:35, 2 April 2025 (UTC)[reply]
@Slenderman7676 Hi, this might be related to the work I'm doing with image thumbnails (phab:T360589). There are multiple ways that this can happen due to that work. 1- The size of image will be different than size of the element (the thumbnail is 250px, the image is shown at 220px) and your browser might not support it. All browsers I have tested so far have worked with no issues. If you're using an uncommon browser or it's not updated for a while, this might be the reason but I need to know what browser is that to check it immediately. I checked all three are broken are using the steps but also two of the ones that are shown too which is weird. So another question I have is also that whether the working images are also now broken too? 2- rate limit: Since we are using steps and also working to bump the default size to 250px (phab:T355914), these are triggering a lot of thumbnail regeneration (combine that AI scrapers), you might be hitting the rate limits of thumbnail generation (I'd have to see the network response for the browser, is it giving 429 when trying to load the image?) specially if you're unlucky with a GCNAT or bad ranges. The 1 is unlikely but would be quite scary as it would block the further roll out and 2 is more likely and less terrible, you just have to wait a couple of days. Please let me know how it is. Thank you and sorry for the issue. Ladsgroupoverleg 23:38, 2 April 2025 (UTC)[reply]
To follow on from that: people might not be aware of the mechanics. In the past, your browser was served a HTML page woth the various image positions specified for an image width of 220px, and was also served the images pre-scaled to 220px wide, so your browser merely had to fit the images into the appropriate boxes without further manipulation. Recently, however, for the same HTML page (still with 220px image boxes) your browser is served images that are 250px wide, and must scale them down itself. --Redrose64 🌹 (talk) 10:00, 3 April 2025 (UTC)[reply]
Yeah but also noting that such scaling won't happen that often once we reach 100% since once the steps are fully rolled out, we will bump the default thumbnail size to 250px which means for majority of cases (when they don't define a thumbnail size), they will be both served as 250px and shown at 250px. Ladsgroupoverleg 13:57, 3 April 2025 (UTC)[reply]
@Slenderman7676: At Gangway connection, all of the images  Works for me. I notice that all of the links that you give are in the form of URLs to Media Viewer. Is this significant? Do direct wikilinks such as File:Mark 1 coach 6313 at Bristol Temple Meads 2006-03-01 03.jpg produce different results? Personally, I turned off MediaViewer almost as soon as it was launched. BTW, thanks for choosing an article that I created for your example. --Redrose64 🌹 (talk) 08:56, 3 April 2025 (UTC)[reply]

Finally back on my PC so I can reply, I did a refresh with cache clear. The images at the top of the article which originally failed to load now load. But now a bunch of other images near the bottom of the article have broken. I do think this is some sort of API thumbnail issue. Looking up my current IP on here shows no blocks. It's only a Dynamic UK Residential IP by Virgin Media. Unless VM are also using their residential IPs for scraping? As for browser. I'm currently rocking Chrome ver 124.0.6367.61 on Windows 10 build 22H2, I know Chrome is a tad out of date but I need it in order to keep my MV2 extensions working properly. FYI, my replies may be slow because my mobile devices (iPhone and iPad) are global IP blocked even when logged in and it's a bit of a hassle to have to disable and then re-enable Private Relay in order to make edits, but I digress. Slender (talk) 20:58, 3 April 2025 (UTC)[reply]

Chrome 124 is not that old to be the culprit. Given that the ones that load and the broken ones are changing, this is quite likely just rate limit issues. It's not really about VPN. Some ISPs do IP assignment really terribly (some are called CGNAT) and you might be hitting the rate limits because of that. It all should go away soon. Ladsgroupoverleg 10:46, 4 April 2025 (UTC)[reply]
I had the same problem, also with a Chromium 124 based browser. Installing a user agent modifying extension and changing the 124 to 125 or even 123, or to Firefox or some other browser fixes it.
Going back to 124 makes it start happening again, but images that had already loaded properly remain visible, even after clearing cache, and even if the working request was from a different browser, suggesting it could be thumbnail generation related. When it isn't working, no amount of refreshing makes it work, and the images appear as soon as I change the user agent, so not likely to be rate limiting, unless there's some very specific and easily-reached limit against certain browser versions.
Going to a bad image directly, ("upload.wikimedia.org/wikipedia/en/...") shows "Error Our servers are currently under maintenance or experiencing a technical issue" but also "Error: 403, Too many requests.", so some kind of block/limit that affects direct images and thumbnail generation from certain browsers, but not already-generated thumbnails? ThisNewSkinIsAwful (talk) 17:13, 6 April 2025 (UTC)[reply]
Thumbnails have never regenerated by refreshing a page a thumbnail of them is on. In order to get new thumbnails, go to the image page of the images in question and purge those. Give the images at least one minute to regenerate.
Error 403 is from the thumbnailer, it is a rate limiter. You will hit it consistantly if you ask to regenerate 50+ images. Snævar (talk) 17:29, 6 April 2025 (UTC)[reply]
Then it may not be thumbnail generation related after all, as purging a "broken" image didn't make it appear, and just refreshing an article with broken images after changing user agent makes them appear. And the error was seen on the full image too. ThisNewSkinIsAwful (talk) 19:37, 6 April 2025 (UTC)[reply]
It could be a broken file yes. I think it is time to file a bug at phab:. On phab, "thumbor" is the thumbnailer and "sre-swift-storage" is the server thumbnail cache. Mark it as you see fit.
What is generally happening here is that the server has a cache of thumbnails that is now being regenerated. In some cases the thumbails are several years old. So these pictures get new thumbnails that are being created by newer versions of mostly the same thumbnailing software, which produces in some cases different results or even broken files. All requests from you go to the server cache, and if it does not have it, to the thumbnailer. Snævar (talk) 23:28, 6 April 2025 (UTC)[reply]
I'm with the SRE team at the Foundation, and I'm responsible for your issues, most likely.
We were blocking requests from a very specific version of Google Chrome because of some crawler that was very aggressively downloading large TIF and JPG files from our infrastructure, to the point of causing an outage over the last weekend of March, and persisted for days afterwards.
At the time the false positive traffic was low enough, and the crawler spread enough across different IP spaces, that I made the call to block requests unconditionally. I apologize for the inconvenience - I've verified that currently the crawler has ceased to operate and lifted the ban.
I apologize again for your inconvenience: while at the time it was our only option, and I stand by the decision I made to ban the requests, I dropped the ball on disabling the rule after the crawler had ceased to be around.
You should be ok now. GLavagetto (WMF) (talk) 18:59, 7 April 2025 (UTC)[reply]
Yes, can't reproduce the problem here now. Thanks! ThisNewSkinIsAwful (talk) 19:13, 8 April 2025 (UTC)[reply]

Longest possible video

Video of 25 h 5 min 58 s

I was shocked to discover File:Cory Booker's 25-hour speech.webm, which has a length of 90,358 seconds. I just assumed that videos had a much shorter time limit, so if you attempted to upload a video anywhere close to this in length, it would get rejected. Does MediaWiki impose a limit on the length of a video, or from a technical perspective, can you upload any video you want, regardless of length? Also, what about non-video files, like OGG recordings? Nyttend (talk) 21:53, 2 April 2025 (UTC)[reply]

@Nyttend a file can be up to 5 GB large, which this file is just under at 4.5 GB. That does not mean you can directly upload 5 GB. Some high quality NASA images are massive, and having the full file is great. For other stuff, less so. See c:Commons:Maximum file size and more broadly the setting in MediaWiki software. mw:Manual:$wgMaxUploadSize ~ 🦝 Shushugah (he/him • talk) 22:15, 2 April 2025 (UTC)[reply]
So there's no time limit, per se, for uploads? I'm left imagining someone uploading a ridiculously long MIDI file. Nyttend (talk) 00:09, 3 April 2025 (UTC)[reply]
No, but of course there are humans patrolling the upload log who will (hopefully) cut down on crap like that. * Pppery * it has begun... 00:10, 3 April 2025 (UTC)[reply]
That would make the transcode timeout, though.
On an unrelated note, why can't we switch to a service which allows files above 5gb? JayCubby 13:03, 3 April 2025 (UTC)[reply]
@JayCubby, it's not a technical limitation (which is why it's a setting). Qwerfjkltalk 13:13, 3 April 2025 (UTC)[reply]
Interesting. The Foundation has plenty[dubious – discuss] of server resources and capital[citation needed]. Why do we have a limit in the first place?
I suppose it is very rarely an issue (only, I dunno, for moderately high-resolution full-length films, but Commons totally doesn't host too many of those). JayCubby 13:20, 3 April 2025 (UTC)[reply]
5GB is still a technical limitation (phab:T191802) just a different one from before. the wub "?!" 14:07, 3 April 2025 (UTC)[reply]
The longest audio files on Commons are over 6 days long: File:WV-FrenchCourse-Step001-Exercise01.ogg, File:Es-mx-población.ogg, File:Es-mx-personal.ogg and File:Eo-plezuro.ogg.
The longest audio files on English Wikipedia are around 1 hour long: AlanFreed-WinsNewYork-March231955.ogg and File:Adolf Eichmann trial opening statement.opus. Snævar (talk) 02:16, 3 April 2025 (UTC)[reply]
I am surprised that someone managed to upload a huge video like this that also has a suitable file size for Commons :D --PantheraLeo1359531 (talk) 08:26, 3 April 2025 (UTC)[reply]
Low resolution, and lossy-compressed to the max? --Redrose64 🌹 (talk) 08:59, 3 April 2025 (UTC)[reply]
Videos at a different resolution are saved after rendering. It takes longer than saving a text file. Snævar (talk) 11:01, 3 April 2025 (UTC)[reply]
I'm the guy who uploaded this video. Here are some comments for you.
Indeed, there is no limit on recording length, but only on file size. It is actually at least theoretically possible to make a video file that is much longer in playback time than this (and at a much smaller file size, too). The simplest way to do this would be by creating a long video with a (very low) frame rate. Such a video would be useless, but definitely possible to create.
@Redrose64 I think you would be surprised to find that this video is, relatively speaking, not lossily compressed to the max, although it is fairly compressed. I used AV1 to compress this video. The source (C-SPAN) is a 576p H264 video, which itself is fairly lossily compressed. The portion of the video in question was already over 6 GB using H264 in the original C-SPAN encode. AV1 is a lot more modern than H264 (or, for that matter, VP9), so it is capable of producing a pretty decent result. The ffmpeg command I used to encode this video was:
ffmpeg -i source.mp4 -ss 04:00:14 -to 29:06:12 -c:v libsvtav1 -b:a libopus -b:a 64k -g 400 -preset 4 -crf 41 -pix_fmt yuv420p -svtav1-params tune=0 booker.webm
This yielded the 4.5 GB AV1 file that you see here. Actually, AV1 is pretty good for hosting high-res feature films, @JayCubby. You can see some AV1 encodes I made of feature films on Commons: The Jazz Singer, Glorifying the American Girl, Zaza, Cyrano de Bergerac, Night of the Living Dead. 5 GB is still limiting as a file size cap, but you can squeeze a fairly decent 1080p encode into that file size using AV1, which you really can't do with other codecs supported on Commons.
The only downside of AV1 is that AV1-WebM, while working perfectly in Firefox and Chrome, is not supported in Safari. (Newer versions of Safari support AV1-WebRTC on new Mac/iOS chips with hardware AV1 decoders, but apparently AV1 in WebM isn't supported.) Normally, this isn't a huge issue, because Commons automatically transcodes to VP9 (which is the process to which @snaevar was alluding). For the feature films I linked above, you can see a transcoded VP9 copy (actually, that's the default unless you switch to the original source file in the Commons streaming player). On Safari, the original is not shown as an option, only the VP9 streams.
This is a slight problem for the Cory Booker video, because the system refuses to transcode the file to VP9 at all. This is because the estimated size of the transcoded file is too big. The smallest option, which is the 240P VP9 encode, gives the following error:
estimated file size 3397249 KiB over hard limit 3145728 KiB
Now, this 3 GB limit is actually below the 5 GB limit for original files, but it's still fairly large. This is because the system, I believe, just uses a fixed bitrate to estimate file size, and, well, this video is over 25 hours long, so any video of this length will, even at a fairly low bitrate, end up pretty large. There are definitely ways to get a VP9 encode to be under 3 GB (and definitely under 5 GB, too).
Ideally — and I don't know that this is possible within Commons' infrastructure — a sysadmin would be able to run a custom transcode for this file (using a custom ffmpeg command — or I could provide a transcoded file myself) which would produce an appropriately transcoded file (using a lower bitrate, slower encode speed or perhaps a higher file size limit) — just so Safari users would see something. Alternatively, I could replace my AV1 encode with a VP9 WebM encode of my own creation; this would be definitely worse in quality (I've tested it out, and it is noticeable, but maybe I can make it closer to the AV1 quality), but would be supported in Safari. Eventually, I figure Safari will join the party and support AV1 in WebM like the other browsers, at which point this will cease to be a problem.
(Side note: I am using a very powerful CPU — an Apple M4 Max — and libvpx-vp9 is slower for me than libsvtav1!)
D. Benjamin Miller (talk) 16:21, 3 April 2025 (UTC)[reply]
D. Benjamin Miller, thanks for the explanation and for putting in the work to get this file. I extracted the audio, available at File:Cory Booker's 25-hour speech audio.opus. Do you have the means to extract the subtitles from C-SPAN? I tried to use OpenAI's Whisper to generate a SRT (in Google Colab), but it got an hour in and crashed for unknown reasons (though you might have better luck). JayCubby 15:36, 4 April 2025 (UTC)[reply]
Yes, I have the means to extract them, but you must understand that they're represented in this "scrolling CC" format, where lines are spelled out and re-spelled out in the next caption. I also think that the captions may be too long to put in the Commons TimedText. I'll look into it when I have the time. D. Benjamin Miller (talk) 23:40, 4 April 2025 (UTC)[reply]
An regex could remove every other line. You need a program that does Regex replacements, like Notepad++. For example "([^\n]+)\r\n\r\n[^\n]+\r\n" with the replacement "$1\r\n" will remove line 2 and 4 in this text:
lorem ipsum1
lorem ipsum2
lorem ipsum3
lorem ipsum4 Snævar (talk) 13:05, 5 April 2025 (UTC)[reply]
Snævar, just curious, what does the \r do in that regex? I'd use something more like (.+)\n.+ → $1. — Qwerfjkltalk 15:33, 5 April 2025 (UTC)[reply]
\r is needed to match newlines on Windows, because they decided to emulate typewriters and have both a return and a newline at the end of a line. Izno (talk) 16:42, 5 April 2025 (UTC)[reply]
There isn't a single character named "newline". Different operating systems use various characters or char combinations to signify a new line. Unix (Xenix, Linux etc.) use the line feed (U+000A) for the newline; Apple Mac uses the carriage return (U+000D). Windows uses carriage return directly followed by line feed, which it inherited from MS-DOS, which in turn got it from CP/M.
I have used a Creed teletype to input programs via five-bit punched paper tape for an Elliot 803, and that teletype had carriage return and line feed on separate keys. You needed to press both in turn because if you forgot to include line feeds in your data stream, each line would be overtyped on the last, like this:
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
if you forgot the carriage returns, you got an effect something like this: 
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
                                                        sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
A manual typewriter (like this Olympia, similar to the one that my mother owned) has a large lever on the left which, when pulled to the right, first advances the paper (effectively, the line feed) and then moves the carriage to the start of the (new) line. --Redrose64 🌹 (talk) 18:38, 5 April 2025 (UTC)[reply]
I know how to use regex, but this is a lot more complex than that. The captions are scrolled in word by word (if you know how CC works on live television, this is similar). Anyway, I'll work on it and get a synced set of captions. D. Benjamin Miller (talk) 20:50, 5 April 2025 (UTC)[reply]
After doing some minor correction (much more needed), it still won't work:
The text you have submitted is 2,347.347 kilobytes long, which is more than the maximum of 2,048 kilobytes.
So, anyway, if you wanna try to somehow make this small enough to fit (or whatever, after correcting it), see User:D. Benjamin Miller/booker subtitles 1.srt and User:D. Benjamin Miller/booker subtitles 2.srt. D. Benjamin Miller (talk) 01:52, 6 April 2025 (UTC)[reply]
The most obvious thing I can think of is abbreviate common and long words (e.g. government --> gvt), which could cut it down by a few kb. JayCubby 02:33, 6 April 2025 (UTC)[reply]
This feels like a problem that should be directed at people who care about big Commons things and possibly the WMF. Izno (talk) 03:42, 6 April 2025 (UTC)[reply]
It's not really a mystery; it's just the max text page length setting in MediaWiki D. Benjamin Miller (talk) 14:46, 6 April 2025 (UTC)[reply]
I didn't say it was a mystery. I said it was a problem and suggested you talk to people who might actually know the answer. I doubt anyone at en.wp VPT is aware of how Commons works with Big Things. Izno (talk) 16:24, 6 April 2025 (UTC)[reply]
Commons has its own VPT at, as might be expected, c:COM:VPT. --Redrose64 🌹 (talk) 17:10, 6 April 2025 (UTC)[reply]

Identifying and Removing Predatory Sources

Hey everyone, I was wondering if there are any tools available that could help identify citations that link to PDFs, as many predatory journals often use direct PDF links instead of proper journal indexing. While manually checking for predatory sources is possible, a tool to automate or streamline this process would be really useful. This is a consistent problem in wikipedia, as many articles are out there with almost all predatory sources. For instance, do look at Mizo names. After I removed all the predatory sources, there is only one citation left.

I understand that Special:Linksearch can be used to find citations linking to specific domains, which is helpful for flagging known predatory journals. However, I don’t think there’s currently a way to search for all citations that link to PDFs in general.

Would it be possible to implement such a search function, or has anyone come across a method to filter citations by file type? If not, I’d like to discuss whether this is something that could be proposed at WP:VPT or WP:RSN. Looking forward to hearing your thoughts! — Flyingphoenixchips (talk) 01:29, 3 April 2025 (UTC)[reply]

@Flyingphoenixchips: You should check out @Novem Linguae:'s script User:Novem Linguae/Scripts/CiteHighlighter which could help with this task. Polygnotus (talk) 01:49, 3 April 2025 (UTC)[reply]
Do you know any other predatory journals? Searching for insource:ijnrd.org and insource:ijsr.net yields 64 results. Polygnotus (talk) 01:52, 3 April 2025 (UTC)[reply]
Really cool to say the least. Just downloaded it. There are many predatory journals out there, and as someone working in academia I can for sure say that 99% of times, the citations that leads to pdf of a Journal, is most definitely predatory. This is why I was hoping to search for a tool, that can search the database of wikipedia, to find all citations that link to a pdf. Yes, there are many other predatory journals like http://www.ijst.co.in/ https://tlhjournal.com/ https://ijssrr.com/journal and https://www.mkscienceset.com/. There are many more besides these, and many more that I might not be aware of. This is partly the reason I am interested in this. I did a few clean up of ijnrd.org
But yea the script you shared is quite cool :) installed it Flyingphoenixchips (talk) 02:03, 3 April 2025 (UTC)[reply]
@Flyingphoenixchips I don't know how nerdy you are, but AutoWikiBrowser includes a database scanner and I don't think you even need AWB permission to use it. I also have a tool that can search through the dump. Polygnotus (talk) 02:09, 3 April 2025 (UTC)[reply]
Could you share the link for it. Much appreciated. Flyingphoenixchips (talk) 02:10, 3 April 2025 (UTC)[reply]
WP:AWB. Polygnotus (talk) 02:11, 3 April 2025 (UTC)[reply]
Thanks will have a look :) Flyingphoenixchips (talk) 02:12, 3 April 2025 (UTC)[reply]
@Flyingphoenixchips The scanner is explained here. If you want someone else to do it you can ask at WP:AWBREQ. Polygnotus (talk) 02:13, 3 April 2025 (UTC)[reply]
@Flyingphoenixchips I was too lazy to download a new dump so I used one that I had laying around. A text file containing just the articlename and then the PDF URL is 373MB. There are 3.257.740 URLs that end in .pdf, if you only search articles and only inside ref tags. Polygnotus (talk) 04:27, 3 April 2025 (UTC)[reply]
Here is the first MB: https://en.wikipedia.org/w/index.php?title=User:Polygnotus/Flyingphoenixchips&action=edit Polygnotus (talk) 04:34, 3 April 2025 (UTC)[reply]
Note that there is also a WP:BLACKLIST which prevents future additions but does not work retroactively. Polygnotus (talk) 05:18, 3 April 2025 (UTC)[reply]
Hm, I restricted it to only articles that contain "India" and only references that contain ".pdf" and I get 96.847 results (roughly a 10mb file) most of which are fine. Polygnotus (talk) 14:17, 3 April 2025 (UTC)[reply]
Hmm interesting, did you happen to notice links to dubious journals? Flyingphoenixchips (talk) 02:24, 7 April 2025 (UTC)[reply]
@Flyingphoenixchips No. You can have a look. This list excludes all articles that do not have a category whose name contains the word "India" and of those it takes the references that contain ".pdf"
https://en.wikipedia.org/w/index.php?title=User:Polygnotus/e437895&action=edit Polygnotus (talk) 02:30, 7 April 2025 (UTC)[reply]
I see thanks for sharing Flyingphoenixchips (talk) 02:33, 7 April 2025 (UTC)[reply]
Flyingphoenixchips, can you elaborate on this:

I can for sure say that 99% of times, the citations that leads to pdf of a Journal, is most definitely predatory.

That seems dubious, unless you think that, say, all of these citations from Wikipedia articles hosted by JSTOR are all from predatory journals. Citations from the top of that list include articles from: American Historical Review, American Literature, Annual Reports of the Dante Society, Proceedings of the New York State Historical Association, Urban Studies, Science & Society, PMLA, Journal of Marketing Theory and Practice, American Journal of Sociology, and Political Science Quarterly. I couldn't find any that seemed likely to be from a predatory journal before I stopped looking. Or did I miss your meaning? Mathglot (talk) 21:29, 6 April 2025 (UTC)[reply]
@Mathglot I searched through the dump for them and my conclusion is that that is not an efficient way of finding predatory journals (even in articles related to India). So we should continue with our approach of searching for the name or domain of the journals.
There appears to be a (somewhat outdated) list here: https://ugccare.unipune.ac.in/apps1/home/index that is comparable to Beall's List. I have mentioned the domains listed in this thread over at Wikipedia:Reliable_sources/Noticeboard#Predatory(?)_journals Polygnotus (talk) 21:38, 6 April 2025 (UTC)[reply]
This is valid too. Honestly we can do this, but the problem is- there are so many predatory journals out there, that it will be hard keeping track of all the domains. Flyingphoenixchips (talk) 02:26, 7 April 2025 (UTC)[reply]
@Flyingphoenixchips Problem is, there are even more valid links to .pdf files. So keeping track of the domains is the only option we have. Polygnotus (talk) 02:31, 7 April 2025 (UTC)[reply]
True Flyingphoenixchips (talk) 02:32, 7 April 2025 (UTC)[reply]
What I meant by this, was 100% of the times, predatory journals do not have a doi index, and thus whenever they are cited in Wikipedia, they are cited in the form of a pdf. Does it mean all pdfs are unreliable? Of course no! I was trying to find patterns in order to identify predatory journals, and this was one thing that I had noticed. This is why I brought it up, as a possible method to search for predatory journals Flyingphoenixchips (talk) 02:24, 7 April 2025 (UTC)[reply]
Can you contact the people behind https://ugccare.unipune.ac.in/apps1/home/index and ask if we can have their list? https://web.archive.org/web/*/https://ugccare.unipune.ac.in/apps1/home/index Polygnotus (talk) 02:33, 7 April 2025 (UTC) Polygnotus (talk) 02:33, 7 April 2025 (UTC)[reply]
https://ugccare.unipune.ac.in/Apps1/User/lr/login
you should be able to access their list, after making an account here. Also not sure if this would help as well, since UGC has been used by predatory publishers to get legitimacy most of the times. Flyingphoenixchips (talk) 02:35, 7 April 2025 (UTC)[reply]
@Flyingphoenixchips I cannot even open that site, it just keeps loading forever. We need an Indian equivalent of Beall's List. Polygnotus (talk) 02:36, 7 April 2025 (UTC)[reply]
I am not sure if users outside India can access it. I am currently not in the country as well, but since I had made an account here, maybe thats why I still have he access. Well good point. Let me see if I can work on building such a site. Would you be willing to help? Lemme try posting this in Wikiproject:India Flyingphoenixchips (talk) 02:41, 7 April 2025 (UTC)[reply]
I am willing to help, but not able, because I know nothing about predatory publishers in India. Posting in Wikiproject:India is a good idea, there may be more people who know about these things. Polygnotus (talk) 02:44, 7 April 2025 (UTC)[reply]
Noted :) Flyingphoenixchips (talk) 02:45, 7 April 2025 (UTC)[reply]

It can depend on the subject area, but as someone who has been in the academic publishing business for decades as author, editor, and technical manager, I strongly disagree that the absence of a doi is an indicator of being predatory. Getting doi coverage for a journal involves no quality-related test at all. It is just for the asking plus a small fee. The total cost for a whole year of articles is about 1/10 of the typical page charge for one article. It is actually journals which have no cash flow at all which are most likely to not have dois, and they are the least likely to be predatory. Conversely, dois are one cheap way that predatory journals use to make themselves look legit. Zerotalk 10:05, 7 April 2025 (UTC)[reply]

@Flyingphoenixchips: As another person who has been involved in academic publishing for decades (as an author and peer reviewer), I agree with Zero's statement above. There are lots of older or smaller independent journals that are completely legitimate and peer reviewed but do not have DOIs or similar registrations. This is especially true of niche zoological and botanical journals. I'm curious how you are distinguishing between those and predatory journals. Nosferattus (talk) 00:13, 11 April 2025 (UTC)[reply]

Hello, does anyone know how to access the article at [6]? The first snapshot, specifically June 21, 2011, is cited on an article, but if it loaded once it doesn't now. Thanks, CMD (talk) 06:48, 3 April 2025 (UTC)[reply]

So that people don't waste their time: insource:NewsID=72917. Polygnotus (talk) 14:18, 3 April 2025 (UTC)[reply]
That source is as good as dead, because WebArchive seems to have changed its syntax so that the source doesn't show and archive.today redirects to the main page. You can try contacting the WebArchive but I'd simply consider some other sources Szmenderowiecki (talk) 15:00, 3 April 2025 (UTC)[reply]
Thanks, a shame but I suppose it is what it is. CMD (talk) 15:19, 3 April 2025 (UTC)[reply]
One would think that the article in question ought to be listed in the Express archive for the date claimed in the article, but I don't see an obvious title in that list although in theory, it has to be there, so perhaps it's buried in an article about something else? Sufficient sleuthing through that list might turn it up, but that's a lot of effort for an uncertain result about one citation. Mathglot (talk) 01:04, 7 April 2025 (UTC)[reply]
I agree with both of you! As of now, I was evaluating predatory journals by visiting their website and seeing how they advertised themselves. A journal that promises turn around of less than a week, is definitely predatory. It can also be determined by looking at the quality of the papers published in itself. Flyingphoenixchips (talk) 03:32, 11 April 2025 (UTC)[reply]

Onlyinclude

How to prevent empty row appearing after "onlyinclude" tag? Examples: 1 2 Lado85 (talk) 13:16, 4 April 2025 (UTC)[reply]

Can anyone help me? Lado85 (talk) 09:56, 5 April 2025 (UTC)[reply]
@Lado85: The thing about <onlyinclude>...</onlyinclude> is that everything between the tags is transcluded, including any whitespace (spaces, tabs and newlines), so if you don't want those occurring in the page that it's transcluded to, you need to ensure that they don't occur either between the opening <onlyinclude> tag and the "real" content that you want to include, nor between the "real" content and the closing </onlyinclude> tag. See WP:ONLYINCLUDE. --Redrose64 🌹 (talk) 12:14, 5 April 2025 (UTC)[reply]
I know this. The empty row is spontaneously added sometimes, when somebody edits article (not omly this, everywhere). I am tired to delete it every time it appears. Lado85 (talk) 12:34, 5 April 2025 (UTC)[reply]
I did two test edits which added a space (now reverted). The first in the standard editor just added the space.1 The second in the Visual Editor added the extra line after the onlyinclude tag.2 I only added the space after the "Pool A". So it looks like a VE issue.  —  Jts1882 | talk  12:59, 5 April 2025 (UTC)[reply]
VE is known to be buggy, that's why it's still in beta. I never use it because I want to know exactly what I'm altering before I go for "Publish", I don't want hidden extras. --Redrose64 🌹 (talk) 13:19, 5 April 2025 (UTC)[reply]
I found a bug report for this problem in the visual editor: T283353.
However, the first two examples are actually in edits made using AWB, which has to be a different problem. Matma Rex talk 20:22, 6 April 2025 (UTC)[reply]

Reboot

Lado85, one issue I have frequently seen, especially with folks with technical chops, is a design-based question, rather than a function-based nne. (I have been guilty of this.) This tends to hamstring the responders, who, rather than responding to your underlying issue, are trying to repair your solution. That sometimes works, sometimes not. Your question is semi-design-based, because you are asking how to make '<onlyinclude>' jump the hoops you want it to jump. But what about restating it functionally, to open up the range of possible solutions? Would it be accurate to restate your question as follows?

  • How do I selectively include or exclude certain rows from a table without introducing unwanted rows or white space in the rendered page?

If so, there are solutions, but they do not necessarily involve <onlyinclude> tags. I am of course trying to mind-read your intent by reverse-engineering your design solution, and maybe I got your intent wrong. But I bet if you restate your question functionally, you will arrive at a solution more quickly, and maybe more easily. Cheers, Mathglot (talk) 00:39, 11 April 2025 (UTC)[reply]

Now need to use email code to login?

I've tried to login to both of my accounts but I am being asked to provide an email code. I have never had this requirement before and the only change I can notice is that I am logging at auth.wikimedia.org instead of en.wikipedia.org

Is this a new requirement? Why was it never advertised/mentioned? 206.83.102.24 (talk) 22:40, 4 April 2025 (UTC)[reply]

Hi, a small percentage of logins now require that the account owner input a one time password emailed to their account. This will occur for example when the device and IP are both new. This is currently in initial testing, for security reasons related to the recent problem. Wider announcements will come soon. Quiddity (WMF) (talk) 23:06, 4 April 2025 (UTC)[reply]
I'm regularly changing both user agent and IP, is there no option to disable this in settings (I cannot look right now for obvious reasons)? All my passwords are uniquely generated. 206.83.102.24 (talk) 23:34, 4 April 2025 (UTC)[reply]
You can setup 2FA for your account, which will stop this. See m:Help:Two-factor authentication for details on that (and make sure to save the recovery codes it gives you, if you decide to follow the process to opt-in). Quiddity (WMF) (talk) 23:53, 4 April 2025 (UTC)[reply]
I don't want to have to enter a code at all. The only way to avoid this it appears is to simply disable/remove an email, which would only worsen account security. 206.83.102.24 (talk) 00:38, 5 April 2025 (UTC)[reply]
Please could you write (perhaps privately to me, contact details on my userpage) some details about why your user agent and IP are regularly changing? Then I can bring that info to the devs in case it's something they can help you workaround, or can consider for the system as a whole. Thanks. Quiddity (WMF) (talk) 16:37, 5 April 2025 (UTC)[reply]
You can see my provider, as for the user agent, well my I update my browser regularly. 206.83.103.99 (talk) 22:01, 8 April 2025 (UTC)[reply]
Thanks for the reply. I believe you are correct, and the three technical options for you are: (1) use 2FA which will allow you to remain logged-in for a year (assuming you allow cookies) per device, (2) encounter these EmailAuth verification code requests, but (again assuming you allow cookies for Wikimedia domains) you should only need to go through the EmailAuth workflow once per year per browser, (3) remove your email from the account (which as you note has significant drawbacks). Overall, I would encourage option 1, and if you have additional concerns about using 2FA that aren't addressed in the Help page, please let me know (or comment on the talkpage there). I hope that info helps. Quiddity (WMF) (talk) 16:35, 10 April 2025 (UTC)[reply]
Logging in on auth.wikimedia.org is a separate change, which has been announced in #Tech News: 2025-14 and elsewhere. You can find documentation about it here: [7]. Matma Rex talk 23:35, 4 April 2025 (UTC)[reply]

Finding pageviews of vital articles

For WP:The core contest, I'd like to get an overview of the most-read vital articles. On {{Core topics}}, there is a dead link to wikistics that supposed to do this, but I can't figure out how to replicate this with massviews, given that VIT3+ are not separate categories. Instead, they are classified in subtopics such as Category:Wikipedia level-3 vital articles in Geography, so that Massviews shows only the most-read articles in that subcategory.

Is it possible to get an overview of the most-read vital articles? Or most-read VIT3 articles? —Femke 🐦 (talk) 12:13, 6 April 2025 (UTC)[reply]

The box that says "Category" in Massviews is a dropdown. There are other sources implemented there, at least one of which should work. I think either page pile or wikilinks will do the trick. Izno (talk) 16:26, 6 April 2025 (UTC)[reply]
@Femke: [8] – DreamRimmer (talk) 16:30, 6 April 2025 (UTC)[reply]
Thanks both! —Femke 🐦 (talk) 20:02, 6 April 2025 (UTC)[reply]

Pblock question

Resolved

Does p-blocking an editor from "Creating new pages" prevent them from:

  1. Starting a new article in Draft space?
  2. Moving an existing page to a (non-existent) title?

I didn't find the answers at WP:PBLOCK although I assume this is documented somewhere. Thanks. Abecedare (talk) 15:28, 6 April 2025 (UTC)[reply]

I tested this on my clone account and verified that the pblock prevents the blocked editor from doing (1) and (2). Abecedare (talk) 17:44, 6 April 2025 (UTC)[reply]
Both are technically creations. A Draft, is just a place (a namespace), a redirect is a special type of content of a page. Both situations require the technical creation of a page. —TheDJ (talk • contribs) 09:55, 8 April 2025 (UTC)[reply]

Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"

Tracked in Phabricator
Task T390510

Hi! I just got some errors like [be090329-f0a7-45b7-8ad7-17a7fca893e3] 2025-04-06 20:30:10: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError" on multiple pages, including the Main Page (this specific one is from https://en.wikipedia.org/wiki/Template:Sentence_fragment). 2A00:807:D7:AA94:CD3B:F89A:966C:8FA7 (talk) 20:39, 6 April 2025 (UTC)[reply]

Yeah that is annoying, thanks for reporting. The good news is that the people who deal with the servers also see those errors so they will be working on a fix. Polygnotus (talk) 22:51, 6 April 2025 (UTC)[reply]
Could you add the relevant phabricator ID to this section, if there is one? (I'm guessing it's probably T389734?) 2A00:807:D7:AA94:C06A:461B:F9:6B92 (talk) 23:10, 7 April 2025 (UTC)[reply]
This time it was probably the issue tracked at T390510. Matma Rex talk 23:20, 7 April 2025 (UTC)[reply]

dumpparsers

So recently I wanted to search through the dump and:

  • Ignore all articles that are not in a category whose name contains the word "India".
  • Of the remaining articles, check all references and output only those that contain .pdf to a textfile with the article title

I now have a tool that can do that (and all kinds of similar tasks) but I wondered if there is something already out there. I know about the Database scanner in AWB but it can't do something like this. I can't be the first person on earth who needed something like that, right? Polygnotus (talk) 22:55, 6 April 2025 (UTC)[reply]

Polygnotus, you could probably use pywikibot with XMLDumpPageGenerator or xmlreader.XmlDump — Qwerfjkltalk 11:49, 7 April 2025 (UTC)[reply]

I found meta:Data dumps/Other tools but what I want is to be able to output article titles or references or external links based on one or more selection criteria (e.g. contains string or not, matches regex or not). Polygnotus (talk) 23:02, 6 April 2025 (UTC)[reply]

The two I know of are Wikipedia:Typo Team/moss and Wikipedia:WikiProject Check Wikipedia. There's probably a few out in the wide world of academia. Izno (talk) 23:19, 6 April 2025 (UTC)[reply]
Otherwise, you're probably SOL for arbitrary queries. Izno (talk) 23:19, 6 April 2025 (UTC)[reply]
Those also parse Wikipedia dumps, but what I mean is downloadable programs that endusers can use that can search through the dump and filter. So for example the program I have can filter articles (based on criteria like does/does not match regex, does/does not contain matching string), and can then filter external links or references in those filtered articles (with the same criteria), and output the article titles or the article titles + reference or the article titles + external links. Polygnotus (talk) 05:32, 7 April 2025 (UTC)[reply]
In AWB, in the database scanner combine your two search queries. The category is going to appear later than the ref. Also, I do not like your double negitive. As for your boolean does it contain it or not, search for one of the criterions at a time and use the 'list comparer' to compare it against the combined run. Snævar (talk) 09:04, 7 April 2025 (UTC)[reply]

6'

In the search bar for desktop, why does entering 6' lead to the redirect 6˚? I can't reproduce this with any other string ending with ' (an apostrophe). –LaundryPizza03 (dc̄) 10:09, 7 April 2025 (UTC)[reply]

Special:Search/6' also demonstrates it. It also happens for Special:Search/361' and Special:Search/36'30'N. In the latter example, the first ' matches ˚ in 36˚30'N while the second ' matches itself. I guess ' will always match ˚ in searches when there exists a page with ˚ but not with '. It may be something about character folding in Elasticsearch, similar to letter case where Special:Search/EXAMPLE matches Example. The wikilink 6' is red like EXAMPLE. ˚ can mean degree (angle) and ' can mean arcminute (1/60 of a degree) so the symbols are related in that context without meaning the same. There may be languages where they are often interchanged. PrimeHunter (talk) 13:31, 7 April 2025 (UTC)[reply]

Tech News: 2025-15

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

Updates for technical contributors

  • The Design System Team is preparing to release the next major version of Codex (v2.0.0) on April 29. Editors and developers who use CSS from Codex should see the 2.0 overview documentation, which includes guidance related to a few of the breaking changes such as font-size, line-height, and size-icon.
  • The results of the Developer Satisfaction Survey (2025)  are now available. Thank you to all participants. These results help the Foundation decide what to work on next and to review what they recently worked on.
  • Recurrent item Detailed code updates later this week: MediaWiki

Meetings and events

  • The 2025 Wikimedia Hackathon will take place in Istanbul, Turkey, between 2–4 May. Registration for attending the in-person event will close on 13 April. Before registering, please note the potential need for a visa or e-visa to enter the country.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 18:49, 7 April 2025 (UTC)[reply]

The hovering lead-image

You know that thing when you hover the cursor on a wikilink and get to see a bit of text and possibly the WP:LEADIMAGE? When the lead-image is a bit tall, like at current Jesus, Eve and Women in the Bible, you get a cropping. I'm guessing this falls under MediaWiki, but I'm not sure. Would it be worth the effort to ask "them" to look into this, maybe there's some simple improvement to be done? I don't think this should be an issue for choice of lead-image, so I'd prefer a technical solution. Gråbergs Gråa Sång (talk) 12:13, 8 April 2025 (UTC)[reply]

It's part of mw:Extension:Popups, also called Page Previews and previously Hovercards. There is an old declined request at phab:T65162. PrimeHunter (talk) 14:07, 8 April 2025 (UTC)[reply]
Thanks! So, declined in 2014. Gråbergs Gråa Sång (talk) 14:17, 8 April 2025 (UTC)[reply]

Came across this referencing style

I recently came across a referencing nomenclature that I am unfamiliar with and was wondering if it's in use in any other article around here.

  • <ref>[[#authoryear|author, year]]pages xxx-xxx.</ref>

It actually works great, links to the cited reference in the WP article with the effect being the same as the sfn/harv styles. I just had never seen it before and thought maybe there's a informational page or a section on some page around here that I have missed but that describes the style. Has anyone else seen this style? Is there something that describes it and how to implement it? Thanks for any info. - Shearonink (talk) 14:28, 8 April 2025 (UTC)[reply]

Not really a 'technical' issue. This particular 'style' is a maintenance headache. For example, in the article United States (permalink), ref 52 is written as:
<ref>[[United States#Ripper2008|Ripper, 2008]], p. 6.</ref>
and ref 56 is written as:
<ref>[[#Ripper2008|Ripper, 2008]] p. 5</ref>
Why are they written differently? Both of those link to:
{{cite book |last=Ripper |first=Jason |title=American Stories: To 1877 |year=2008 |ref=Ripper2008 |publisher=M.E. Sharpe |url=https://books.google.com/books?id=vX-fYvoAeHwC |page=299 |isbn=978-0-7656-2903-6}}
On the other hand, ref 57 is written:
<ref>[[#Calloway1998|Calloway, 1998]], p. 55</ref>
and is supposed to link to:
{{cite book |first=Colin G. |last=Calloway |title=New Worlds for All: Indians, Europeans, and the Remaking of Early America |url=https://books.google.com/books?id=edYbAZ7ECEoC |publisher=[[Johns Hopkins University Press|JHU Press]] |ref=Calloway 1998 |page=229 |isbn=978-0-8018-5959-5 |year=1998}}
but doesn't because the manually created |ref=Calloway 1998 does not match the link created in ref 57.
Further, floating your mouse pointer over the short refs 52, 56, or 57 does not cause MediaWiki to popup the contents of the linked long-form references as it should. For comparison, float your mouse pointer over ref 54, to see the popup created from:
{{sfn|Joseph|2016 |page=590}}
—Trappist the monk (talk) 15:10, 8 April 2025 (UTC)[reply]
I think we should get consensus to convert them to the correct style (if that is even necessary, which I doubt), and then replace them with sfn because creating your own personal style of using references is a terrible idea. Polygnotus (talk) 15:14, 8 April 2025 (UTC)[reply]
This search finds about 9250 articles that use this 'style'.
—Trappist the monk (talk) 15:40, 8 April 2025 (UTC)[reply]
@Trappist the monk Thank you. If the number is that large it may be better to post a WP:BOTREQ. Do you think we need to get consensus to officially deprecate this 'style', and if so where would be an appropriate place? Polygnotus (talk) 16:06, 8 April 2025 (UTC)[reply]
I suspect that there are editors out there who would oppose a bot that changes:
<ref>[[#Ripper2008|Ripper, 2008]] p. 5</ref>
to:
{{sfn|Ripper|2008|p=5}}
and then deletes |ref=Ripper2008 from the matching long-form cs1|2 template. Such a bot might be considered to run afoul of WP:COSMETICBOT. I also suspect that there are editors who will object because they would view the deprecation of this 'style' as unnecessary regulation creep. A widely publicized RFC would seem to be required.
Imposition-of-consistent-style might be a WP:CITEVAR argument for some articles that use both this manual 'style' along with a templated style. These are variants of the above search where articles that use the manual style also use one (or more) of these templated forms:
That's about 1750 articles that use a mixed style of short-form referencing leaving about 7500 others.
There is also {{wikicite}} which gives examples that use this 'style'. Searching for this style in articles that also use {{wikicite}} finds 176 results.
As for where? I don't know. Where was the parenthetical reference deprecation RFC held? Might be a good choice to hold an RFC about this 'style' at the same place.
—Trappist the monk (talk) 17:10, 8 April 2025 (UTC)[reply]
@Trappist the monk On the Village pump (proposals) https://en.wikipedia.org/w/index.php?oldid=976895063#Deprecate_parenthetical_citations Polygnotus (talk) 17:23, 8 April 2025 (UTC)[reply]
Trappist the monk, is it possible to do a search for articles where the reference name text before the '#', per your example of ref 52 in the United States article? -- LCU ActivelyDisinterested «@» °∆t° 10:53, 9 April 2025 (UTC)[reply]
This search times out. Interestingly, quite a few of the articles it finds use <ref>...</ref> tags with this 'style' to link to other articles. Seems a rather poor editorial choice to me.
The search is the {{sfn}} search from above modified in the same way.
—Trappist the monk (talk) 13:29, 9 April 2025 (UTC)[reply]
Thanks I can never quite get complex regex to work. It's shows what I expected, references that use the contents of other articles as references (a doubly broken way of doing things). -- LCU ActivelyDisinterested «@» °∆t° 14:01, 9 April 2025 (UTC)[reply]
For the historical point of view, my understanding is that this reference style mostly more or less predates the development of Module:Footnotes. I'm sure there's a few people who have added it post-development because they generally prefer template-less citations. Using {{sfn}} and friends is just categorically superior for a lot of different reasons.
That said, yes, replacing these en-masse would likely require an RFC at WT:CITE deprecating the style along WP:CITEVAR concerns, because stopping a switch from manual citations to templates is one of the few more or less explicit protections CITEVAR provides. I've nudged a few manually before without "getting permission" and not be shouted at, but it's something you probably should generally avoid. Izno (talk) 17:21, 8 April 2025 (UTC)[reply]
@Izno Apologies if this is a stupid question but why would anyone prefer template-less citations? That doesn't make sense to me. Polygnotus (talk) 17:25, 8 April 2025 (UTC)[reply]
They're easier to type just what you want or need and aren't "finicky" about the metadata piece of it associated with making sure everything gets put in the right parameters and rightly named parameters. Templates are much noisier in the wikitext. There was probably originally some concern that they would cause article rendering or the database to tip over (c. 20 years ago).
I don't hold these views myself, especially for something as easily-used as {{sfn}} when you want a link on the page and inevitably write something longer than the template, but it does and has existed for a very long time. Izno (talk) 17:30, 8 April 2025 (UTC)[reply]
See help:wikilink. I would think that using |ref={{sfnref|Joseph|2016}} in a CS1 or CS2 and referring to it in a {{harvnb|Joseph|2016|page=590}}template would be better form than <ref>[[#anchor]Joseph, 2016, page=590]]</ref>. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:23, 8 April 2025 (UTC)[reply]

@CaptainEek: You started the RFC to deprecate parenthetical citations and it was a great success, what do you think about the idea to deprecate these "fake sfn" citations? Polygnotus (talk) 17:33, 8 April 2025 (UTC)[reply]

@Polygnotus My concern with the parenthetical refs was that they were affecting the reader experience. This is more of an editor side issue, so I'm not really pressed about it. I can't say I'd use this fake sfn style personally, it seems like a pain, but not sure that alone is a reason to deprecate given our desire to allow a range of citation styles. I don't feel strongly about it though and frankly wouldn't stand in the way of greater citation conformity. CaptainEek Edits Ho Cap'n!⚓ 17:39, 8 April 2025 (UTC)[reply]
The range of citation styles I desire allowing consists of CS1 and CS2. Two whole options! Am I a citation extremist?
Allowing too much creativity with citations makes life very difficult for newbies, and these fake sfn citations do not have the many advantages that proper citation templates have (e.g. automatic detection of problems, automatic categorization, a GUI, popups, being usable in VE (allegedly)). Polygnotus (talk) 17:51, 8 April 2025 (UTC)[reply]
Yes, that preferred range does tend toward extreme, even today. :) Izno (talk) 17:58, 8 April 2025 (UTC)[reply]

Thanks for all the responses. Every day I learn more about this place. If anyone is interested in where I came across this issue take a look at Benjamin Franklin. (I am trying to fix/adjust Harv warnings & errors when I come across them and this article was chock-full when I started with 43, it's now down to 22 "Harv warnings".) The parenthetical refs of [[# etc popped up and I could not figure out why some cites were linking within the article to the named sources and mine weren't working... The mix of cites in this article are personally problematic for me and I'm somewhat experienced. I can't even imagine what it's like if a newbie tries to use the parentheticals, the sfns & harvs are thorny enough to deal with.
I didn't realize that so many - 9000+ articles use this style. I would hesitate to change allll these refs in Wikipedia en-masse... In the Franklin article itself there are only 4 refs that use this style - a single Encyclopaedia Brittanica, 4 Nash, a single Franklin Institute, and 24 for Isaacson. If I can wrap my head around the technicalities of converting these 4 refs to sfn, I'll do that and see if my possible changes are according to editorial consensus at this particular article. - Shearonink (talk) 19:50, 8 April 2025 (UTC)[reply]

The style referred to at the top of this section by Shearonink definitely predates modules, and was certainly established at the time that I wrote Abingdon Road Halt railway station way back on 22 September 2009. Within eight hours of writing it, I wrote the very similar Hinksey Halt railway station, which used {{sfn}} from the start. I did this in order to compare the two styles, which I had heard about independently, to see which one was more satisfactory. My decision was firmly for future articles to use {{sfn}}, but I have deliberately refrained from harmonising Abingdon Road Halt railway station, so that a comparison is still available. --Redrose64 🌹 (talk) 21:34, 8 April 2025 (UTC)[reply]
Aha, I'm pretty sure it was Wikipedia:Citing sources/Further considerations, which was created in March 2008, see original version. It still describes the technique, now at Wikipedia:Citing sources/Further considerations#Using freehand anchors. So, Polygnotus, it's not creating your own personal style of using references. Since it's been documented for over seventeen years, WP:CITEVAR applies to any article using it. --Redrose64 🌹 (talk) 22:04, 8 April 2025 (UTC)[reply]
Yeah, back then this may've been a reasonable choice, but back then there weren't all these far superior alternatives. Lua in templates has been supported since 2013. The fact that mistakes have been made in the past does not mean we gotta keep repeating them. And I'm all for variety; but against making the life of Wikipedians harder for no advantage. The reason why it was used in the past is no longer valid. Polygnotus (talk) 22:19, 8 April 2025 (UTC)[reply]

My least favoured style of referencing, as they generate no errors if they're broken (and they are often broken). At least with plain text you don't get a comforting blue link. But CITEVAR does apply and there are editor who prefer them, if anyone looks to get consensus to do something about them please ping me. -- LCU ActivelyDisinterested «@» °∆t° 10:49, 9 April 2025 (UTC)[reply]

Differentiating between a user talkpage and a subpage of a user talkpage.

If I tag a talkpage in my userspace with {{db-g7}} the following text shows up (e.g. on User talk:Polygnotus/Scripts/WikiTextExpander):

Please use the rationale parameter to explain why this user talk page should be deleted. (E.g., {{db-g7|rationale= }}.) Thanks! Per the User page guidelines, user talk pages are generally not deleted, barring legal threats or other grievous violations that have to be removed for legal reasons; however, exceptions to this can be and are made on occasion for good reason (see right to vanish). In addition, nonpublic personal information and potentially libellous information posted to your talk page may be removed by making a request for oversight.

I think it should use the trick in User:Polygnotus/Templates/Subpage or something similar to differentiate between user talk pages and subpages of user talkpages, and only show that warning on a user talk pages. Polygnotus (talk) 17:20, 8 April 2025 (UTC)[reply]

Note user talk page archives are typically subpages of a user talk page. isaacl (talk) 17:37, 8 April 2025 (UTC)[reply]
Good point, but that is fixable. User:Polygnotus/Templates/Subpage2. Also I'd assume it is pretty rare that people actually nominate their talkpage archives, and the vast majority of talkpages in someone's userspace that get nominated for deletion are only edited by the !owner of the userspace. Polygnotus (talk) 17:47, 8 April 2025 (UTC)[reply]
I imagine it's rare that people nominate any of their user talk pages for deletion, so perhaps an easier approach is to clarify the intent of the message. On a side note regarding the logic on your subpage, archive pages don't have to follow any specific naming convention. isaacl (talk) 02:41, 9 April 2025 (UTC)[reply]

add button to visual editor

Tracked in Phabricator
Task T390807
Tracked in Phabricator
Task T136152

i have a code in my User:Gryllida/common.js that adds a button to the wikitext2017 editor. i would like to add a button to visual editor instead though. could you please suggest an example? it needs to alert('hi') or something similar as i will add a custom function. i checked mw:VisualEditor/Gadgets and it is not particularly enlightening. Gryllida (talk, e-mail) 19:56, 8 April 2025 (UTC)[reply]

@Gryllida You could file a ticket on Phabricator but VE doesn't appear to be under active development. The solution is probably similar to T390807. Polygnotus (talk) 20:07, 8 April 2025 (UTC)[reply]
Hi Polygnotus, What is active developed if not VE, then? Thanks for the links, I will check them out. (see also: Live Chat Link (#wikimedia-tech connect)) Thanks -- Gryllida (talk, e-mail) 03:29, 9 April 2025 (UTC)[reply]
Just to be clear: VE is being actively worked on. E.g. the current Edit Check project is a major new VE feature. DLynch (WMF) (talk) 14:10, 9 April 2025 (UTC)[reply]
@Gryllida: Here you go: User:Polygnotus/Scripts/VEbutton.js it adds a star button, if you click on it it says "hello world". Polygnotus (talk) 20:20, 8 April 2025 (UTC)[reply]
Thank you @Polygnotus for the example, I will check it out. Gryllida (talk, e-mail) 10:24, 10 April 2025 (UTC)[reply]
If you want to be able to define buttons in a JSON file, and use any image instead of only these, you can use User:Polygnotus/Scripts/VEbuttons.js (note: plural!) which loads its configuration from User:Polygnotus/VEbuttonsJSON.json. Please copy them to your userspace; I might mess around with those which might break things. Polygnotus (talk) 21:08, 8 April 2025 (UTC)[reply]
See also Wikipedia:User_scripts/Requests#Adding_custom_buttons_to_VE_and_DiscussionTools. Polygnotus (talk) 21:39, 8 April 2025 (UTC)[reply]
There's also w:de:Benutzer:Schnark/js/veCustomize, which may or may not work. — Qwerfjkltalk 11:45, 9 April 2025 (UTC)[reply]
you can activate the script in the Fliegelflagel configuration German is such a beautiful language. Polygnotus (talk) 11:49, 9 April 2025 (UTC)[reply]
Your common.js is adding a button to WikiEditor, not to the 2017 wikitext editor. If it was adding it to the latter, it'd also be added to VE unless you had actively avoided doing so. (E.g. this script that I wrote the other day does that.)
This page may be more helpful since it has some direct examples about how to add a tool to the toolbar: https://www.mediawiki.org/wiki/VisualEditor/Gadgets/Add_a_tool DLynch (WMF) (talk) 13:35, 9 April 2025 (UTC)[reply]
Thank you @Qwerfjkl and @DLynch (WMF) I will check them out. Gryllida (talk, e-mail) 10:24, 10 April 2025 (UTC)[reply]
@Polygnotus and @Qwerfjkl and @DLynch (WMF) i see it works, how do I implement adding text at cursor position? For example, add 'hi' at cursor position when the button is clicked. Cannot use some simpler methods because the 'hi' will be determined after running a custom javascript subroutine, so it will not always be the same content to add. So it has to be a javascript function to add the text, not an 'encapsulate' type of button or the like. Thank you in advance for your help!!! Gryllida (talk, e-mail) 12:06, 10 April 2025 (UTC)[reply]
@Gryllida See User:Polygnotus/Scripts/VEbutton2.js Polygnotus (talk) 12:09, 10 April 2025 (UTC)[reply]
So basically:
var surface = ve.init.target.getSurface();
var fragment = surface.getModel().getFragment();
fragment.insertContent('hello world', true);
Documentation is over at https://doc.wikimedia.org/VisualEditor/master/js/
Polygnotus (talk) 12:12, 10 April 2025 (UTC)[reply]
Awesome, thanks! I will make use of this and then go back to the API documentation to form a more systematic understanding; appreciate your prompt assistance. :-) Gryllida (talk, e-mail) 12:40, 10 April 2025 (UTC)[reply]
@Gryllida Kinda curious what you are building. And for the record, I am no RTFM guy, I just linked the documentation in an attempt to be helpful. Polygnotus (talk) 12:47, 10 April 2025 (UTC)[reply]
n:User:Gryllida/js/add-source-in-visual-editor.js (background info: n:Template:Source). Has a few bugs, discussed on script's talk page. Gryllida (talk, e-mail) 13:04, 10 April 2025 (UTC)[reply]
I'll respond on that talkpage. Polygnotus (talk) 13:24, 10 April 2025 (UTC)[reply]
@DLynch_(WMF) @Gryllida On the English Wikipedia you can use WP:REFVISUAL, specifically this thing (I think that that is the VisualEditor citation tool). Gryllida here is trying to reinvent that wheel, but that would only fix the problem for whoever installs their script so I think the real question is: "Can you please install/enable the VisualEditor citation tool on wikinews.org?".
Looking at User:Diegodlh/Web2Cit/script it looks like this thing uses Citoid, because that script adds web2cit to it, so there is probably a reason the WMF decided to go with Citoid over Web2cit.
It looks like both enwiki and wikinews are using the same version of the Visual Editor enwiki wikinews.
If installing/enabling the VisualEditor citation tool is not an option for some reason then the question is: When you have a button on the VisualEditor in Visual mode, how can you make it actually insert wikicode at the cursor position so that you get to see the parsed result? Polygnotus (talk) 19:34, 10 April 2025 (UTC)[reply]
@User:Gryllida It seems likely that a Phabricator ticket is required. Do you want to make one or should I? This says: It is currently deployed in all VisualEditor-enabled WMF-Wikis [1], though the extension is only configured on some of them. Polygnotus (talk) 19:57, 10 April 2025 (UTC)[reply]
Hi @Polygnotus
The differences are [at least] that:
1) My home wiki does not use inline citations. The VE utility for adding sources would need to be modified to accommodate that.
2) Source 'publisher' needs to be human readable name, which, when possible, should be possible to link to an English Wikipedia wiki page.
3) As a result, as this would be used on some other wiki, it would need to use the w: prefix for wikilinks.
I am happy to beta test this, if available. Gryllida (talk, e-mail) 04:53, 11 April 2025 (UTC)[reply]

SPARQL query

Hi everyone,

I am trying to use Sparql in Wikidata to list all national parties that are members of a European party and whose country is a member of the European Union. That much I have. However, I also want to display their number of seats in the European Parliament (but it should not be a requirement to have such an entry).

So far, I have: 

SELECT ?item ?itemLabel ?countryLabel ?seats
WHERE {
  ?item wdt:P463 [wdt:P31 wd:Q24649]; #member of an instance of European party
        wdt:P17 [wdt:P463 wd:Q458]; #from a country that is a member of the European Union
        wdt:P17 ?country;
        OPTIONAL { ?item p:P1410 [ps:P1410 ?seats; pq:P1410 wdt:Q8889]. }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en-gb". }  } 
ORDER BY ?countryLabel ?itemLabel

The OPTIONAL line is what doesn't work as it yields an empty column. What did I do wrong? Julius Schwarz (talk) 12:26, 9 April 2025 (UTC)[reply]

Asking at d:WD:RAQ is likely to be more fruitful. Izno (talk) 16:16, 9 April 2025 (UTC)[reply]
Fair point, thanks! Julius Schwarz (talk) 20:27, 9 April 2025 (UTC)[reply]
For those interested, this was solved here. Julius Schwarz (talk) 08:36, 10 April 2025 (UTC)[reply]

Wikipedia down?

Tracked in Phabricator
Task T389734
Tracked in Phabricator
Task T390510
Tracked in Phabricator
Task T391695

Is it just me or did Wikipedia just go down for 30-ish seconds? I could provide screenshots if necessary. User:Chorchapu (talk|edits|commons|wiktionary|simple english) 12:26, 9 April 2025 (UTC)[reply]

It just stopped working for another ~10 seconds just now. This comment itself didn't work the first time due to "[4e2970bf-d02b-40d2-903e-74f84962d144] Caught exception of type Wikimedia\Rdbms\DBUnexpectedError" User:Chorchapu (talk|edits|commons|wiktionary|simple english) 12:29, 9 April 2025 (UTC)[reply]
DownDetector appears to say a few others are having problems, but I can't tell if it's a site-wide problem. User:Chorchapu (talk|edits|commons|wiktionary|simple english) 12:30, 9 April 2025 (UTC)[reply]
On the main page just now: "
MediaWiki internal error.
Original exception: [5a674d58-d26d-438e-901b-ad12e3582647] 2025-04-09 12:28:10: 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.
" User:Chorchapu (talk|edits|commons|wiktionary|simple english) 12:32, 9 April 2025 (UTC)[reply]
I just briefly encountered this error when I tried to preview an edit I was making, but thankfully things have quickly gone back to normal. – MrPersonHumanGuy (talk) 15:11, 9 April 2025 (UTC)[reply]
I'm not sure, it seems like every 15 or so Wikipedia pages I've been today on showed the error. Weird thing is, before today I'd never seen it before despite it apparently happening for a few weeks. User:Chorchapu (talk|edits|commons|wiktionary|simple english) 17:08, 9 April 2025 (UTC)[reply]
See also https://www.wikimediastatus.net/, which does signal a huge wiki error spike. — Alien  3
3 3 12:34, 9 April 2025 (UTC)[reply]
That also signals that it's now going down (300/s vs 700/s at top of spike), so it should settle. — Alien  3
3 3 12:35, 9 April 2025 (UTC)[reply]
Hm, that's good, would you happen to know what caused it? User:Chorchapu (talk|edits|commons|wiktionary|simple english) 12:36, 9 April 2025 (UTC)[reply]
Probably a database error? (DB often stands for that). Don't know more. — Alien  3
3 3 12:39, 9 April 2025 (UTC)[reply]
Alright then, well thanks anyways! User:Chorchapu (talk|edits|commons|wiktionary|simple english) 12:43, 9 April 2025 (UTC)[reply]
This has been going on for a while. The production folks are aware of the problem and are working on it. See T389734 for more info. RoySmith (talk) 13:34, 9 April 2025 (UTC)[reply]
I've just tried performing 12 different types of edit. 5 of them came back with the error message. I realise this has been going on for quite a while, but it is becoming increasing impossible to edit Wikipedia. It seems to be getting worse, not better.
The edit I tried to perform include, edits to article talk page, preview edit, edits to an article and so on. Knitsey (talk) 14:25, 9 April 2025 (UTC)[reply]
Oh, that's interesting, I just got the error when trying to read pages, I didn't realise it was editing too. User:Chorchapu (talk|edits|commons|wiktionary|simple english) 14:26, 9 April 2025 (UTC)[reply]
I noticed on wikipediastatus.net that there have been 2 other large error spikes since the one I originally noticed. Something interesting is that they all seem to correlate with temporary drops in successful edits. I'm not necessarily implying causation but this appears to be having at least some impact on people trying to edit. The one at 10:15 today seemingly temporarily halved the number of successful edits from around 20 to around 10. User:Chorchapu (talk|edits|commons|wiktionary|simple english) 17:23, 9 April 2025 (UTC)[reply]
Could someone with a bit more techinical knowledge than me interpret this? I've read through T389734 and it looks like it's something to do with Lua...? I'm a bit confused. User:Chorchapu (talk|edits|commons|wiktionary|simple english) 14:25, 9 April 2025 (UTC)[reply]
As I understand it, the root cause is a bug in a low-level library (glibc) which is used by pretty much everything in the universe. The particular path that most commonly tickles the bug is in some Lua code, so the workaround is to disable that bit of Lua. The real fix has to happen in the glibc code, but that will take a while because it has external dependencies (i.e. somebody else manages glibc). In a case like that, you do what you can quickly to make the immediate problem go away. It's kind of like the old joke where you tell the doctor, "It hurts when I do this" and the doctor says "So, don't do that".
It also sounds like the Lua problem is only one of several manifestations of this bug, so the Lua workaround only reduced how often this happens but didn't eliminate it completely. I'm sure the dev folk are working hard on this so best to just give them some space to do what they need to do. RoySmith (talk) 14:45, 9 April 2025 (UTC)[reply]
Interesting, alright then. User:Chorchapu (talk|edits|commons|wiktionary|simple english) 14:54, 9 April 2025 (UTC)[reply]

Thought I was the only person having issues, that is interesting. And for the record, I did encounter internal errors of the same type, while reading articles, and whilst attempting to go to other articles. Codename AD talk 14:32, 9 April 2025 (UTC)[reply]

Pretty sure this is phab:T390510 (see #10725847 and #10726321), T389734 is for a timeout error (caused by a bug), one that was essentially 'fixed' by removing some logging that was making it likely for the bug to happen. – 2804:F1...E8:9AA2 (::/32) (talk) 19:52, 9 April 2025 (UTC)[reply]

Oh, thank you. I've read the phabricator page, is there any other info on what's causing this? User:Chorchapu (talk|edits|commons|wiktionary|simple english) 22:58, 9 April 2025 (UTC)[reply]
See also phab:T390510#10717702 and #10726260. It's due to an overload after an unexplained spike a) in read requests in one database (not always the same), and b) in connections in all databases. — Alien  3
3 3 06:35, 10 April 2025 (UTC)[reply]
Oh, interesting. Seems like I'm obviously a bit ignorant of all the computer talk on the phabricator page. User:Chorchapu (talk|edits|commons|wiktionary|simple english) 12:07, 10 April 2025 (UTC)[reply]

Source of request spike has been identified: it was a Growth Experiments script aggressively scanning way too many rows of the database. See phab:T391695. It's been disabled until it gets fixed, so normally this shouldn't happen again. — Alien  3
3 3 15:49, 11 April 2025 (UTC)[reply]

Oh, thanks. Glad to see it's been remedied now. User:Chorchapu (talk|edits|commons|wiktionary|simple english) 16:06, 11 April 2025 (UTC)[reply]

Why is this query so slow?

[10] has been running for a long time. It's just: 

select * from revision
where rev_timestamp = 20250409001450

which hits an indexed column, so I would expect it would return almost immediately. What's going on here? RoySmith (talk) 13:36, 9 April 2025 (UTC)[reply]

It did eventually finish, returning the one row I expected it to. Run time was 1205.90 seconds! RoySmith (talk) 15:18, 9 April 2025 (UTC)[reply]
Use timestamp as string;
select * from revision
where rev_timestamp = '20250409001450'

– DreamRimmer (talk) 15:16, 9 April 2025 (UTC)[reply]

Yeah, that worked (0.06 seconds). It's weird that not quoting it allowed the query to run and return the right result, but not hit the index. RoySmith (talk) 15:22, 9 April 2025 (UTC)[reply]
It's weird, but true… Confirmed by EXPLAIN query result:
mysql:research@dbstore1008.eqiad.wmnet [enwiki]> explain select * from revision where rev_timestamp = 20250409001450;
+------+-------------+----------+------+---------------+------+---------+------+------------+-------------+
| id   | select_type | table    | type | possible_keys | key  | key_len | ref  | rows       | Extra       |
+------+-------------+----------+------+---------------+------+---------+------+------------+-------------+
|    1 | SIMPLE      | revision | ALL  | rev_timestamp | NULL | NULL    | NULL | 1153964976 | Using where |
+------+-------------+----------+------+---------------+------+---------+------+------------+-------------+
1 row in set, 4 warnings (0.001 sec)

mysql:research@dbstore1008.eqiad.wmnet [enwiki]> explain select * from revision where rev_timestamp = '20250409001450';
+------+-------------+----------+------+---------------+---------------+---------+-------+------+-----------------------+
| id   | select_type | table    | type | possible_keys | key           | key_len | ref   | rows | Extra                 |
+------+-------------+----------+------+---------------+---------------+---------+-------+------+-----------------------+
|    1 | SIMPLE      | revision | ref  | rev_timestamp | rev_timestamp | 14      | const | 1    | Using index condition |
+------+-------------+----------+------+---------------+---------------+---------+-------+------+-----------------------+
1 row in set (0.001 sec)
I didn't know about this either. I found some discussion of the problem here: https://stackoverflow.com/a/16791526, https://use-the-index-luke.com/sql/where-clause/obfuscation/numeric-strings Matma Rex talk 20:48, 9 April 2025 (UTC)[reply]
Thanks for the pointers. I especially like where use-the-index-luke.com says "Although it is a very bad practice, it does not automatically render an index useless" :-) RoySmith (talk) 22:13, 9 April 2025 (UTC)[reply]

DiscussionTools/Reply Tool stores both keystrokes and the draft?

Tracked in Phabricator
Task T341845

Why does the DiscussionTools/Reply Tool store keystrokes in localstorage? For undoing? If you look in localStorage where the key starts with mw-ext-DiscussionTools-reply you see for example:

{"start":6,"transactions":[[1,["","W"],3],"h","a","t"," "]} in ve-changes

This appears to be a security risk, especially for non-public wikis.

Polygnotus (talk) 14:56, 9 April 2025 (UTC)[reply]

It is for edit recovery, for accidentally closed browsers. It was a very popular requested featured. Not sure why a "non-public" wiki would be a security risk, your browser can already see everything you do. Perhaps if you were using a shared computer, in which case you could use a private browser session. — xaosflux Talk 15:13, 9 April 2025 (UTC)[reply]
@Xaosflux Yeah that is what I thought originally, but weirdly it contains both keystroke information and what I actually wrote (at the end of ve-changes). I understand that it needs to store the draft, but that does not require keystroke information. And if the information is stored as keystrokes then it doesn't need the draft message; or at least that is what I would think. See User:Polygnotus/Scripts/DTreplies.js, then scroll to the bottom of User:Polygnotus/sandbox to see it in action.
Not sure why a "non-public" wiki would be a security risk because, if Bob logs out from his account on a non-public wiki that uses DiscussionTools, he does not expect that Alice can read his drafts without ever logging in to the non-public wiki.
It seems to also store drafts when you haven't actually typed anything which is weird. Polygnotus (talk) 15:18, 9 April 2025 (UTC)[reply]
I don't think Bob should expect that in general when Alice uses Bob's computer, Bob's browser, and Bob's browser profile - that there would be much secrecy from things done within the browser.
However, clearing this local storage is a feature request that is being looked in to in phab:T341845. Feel free to follow or contribute to that task. — xaosflux Talk 15:37, 9 April 2025 (UTC)[reply]
Agreed, but you know Bob. He loves football, he can't dance, and he knows little about computers. He won't expect that the browser remembers stuff like this. Polygnotus (talk) 15:39, 9 April 2025 (UTC)[reply]
Hm, I think it may be a performance thing, using many small transactions instead of 1 bigger one. Polygnotus (talk) 17:34, 9 April 2025 (UTC)[reply]
Yes, this data is stored as part of the undo stack. It doesn't exactly record keystrokes, it's the same "granularity" of changes that you can see when you perform undo/redo in the tool (the text is separated into 1-character strings for technical reasons – see [11] – but this does not reflect how it was typed). This happens just incidentally in DiscussionTools, because the draft autosave mechanism is shared with VisualEditor's autosave mechanism. FYI, if you switch between Visual and Source modes, all of the details are discarded. Matma Rex talk 21:01, 9 April 2025 (UTC)[reply]
The internet is a security risk. If you don't want Big Brother to watch you, don't connect. Get out your old Apple II and run VisiCalc. --Redrose64 🌹 (talk) 22:03, 9 April 2025 (UTC)[reply]
@Matma Rex (or anyone): is this autosave feature documented? I asked on mediawiki.org recently and received no response. Commander Keane (talk) 02:03, 10 April 2025 (UTC)[reply]
@Commander Keane I don't think those details were ever written down. The feature uses localStorage with all of its limitations, plus an expiry of 30 days. [12][13] Matma Rex talk 02:28, 10 April 2025 (UTC)[reply]

Prosesize

Prosesize has stopped working for me, all articles reading as 0b. Have cleared cache and tried through another browser, and in incognito mood. Still all articles showing as 0b. Thanks Hildreth gazzard (talk) 19:54, 9 April 2025 (UTC)[reply]

@Hildreth gazzard It works fine for me. I installed it with Preferences → Gadgets → Browsing → Prosesize and then I went to a random article and clicked the "Page size" option in the tools menu and it says:
HTML document size: 143 kB
Prose size (including all HTML code): 5956 B
References (including all HTML code): 9977 B
Wiki text: 23 kB
Prose size (text only): 3312 B (575 words) "readable prose size"
References (text only): 912 B
What browser and device are you using? Do you see an error in the browser console? Polygnotus (talk) 20:00, 9 April 2025 (UTC)[reply]
Yes, I did that, installed it with Preferences → Gadgets → Browsing → Prosesize on an
iphone and it was working fine. It just stopped the last few hours. No error message. It shows HTML document size and Wikitext size, but all other values are blank Hildreth gazzard (talk) 20:16, 9 April 2025 (UTC)[reply]
For example: this is what it shows for the Mandarin duck
Document statistics (more information):
HTML document size: 212 kB
Prose size (including all HTML code): 0 B
References (including all HTML code):50 kB
Wiki text: 27 kB
Prose size (text only): 0 B (0 words) "readable prose size"
References (text only): 5751 B Hildreth gazzard (talk) 20:18, 9 April 2025 (UTC)[reply]
@Hildreth gazzard You could try User:Polygnotus/Scripts/ProseSize.js Polygnotus (talk) 20:19, 9 April 2025 (UTC)[reply]
If you go to User:Hildreth gazzard/common.js and add the following text: {{subst:iusc|User:Polygnotus/Scripts/ProseSize.js}} then you should get a "Calculate prose size" option in the Tools menu. Polygnotus (talk) 20:26, 9 April 2025 (UTC)[reply]

Is there a valid use for empty section headers?

T368722 proposes to create new Linter tracking for empty section headers (e.g. === ===). Are there valid uses for empty section headers that outweigh the negatives? Please respond at the original thread: Wikipedia talk:Linter#New lint category for empty headings. Thanks. – Jonesey95 (talk) 00:54, 10 April 2025 (UTC)[reply]

Is it possible to change my username posted in warn templates?

Typically I use Twinkle to perform warns, but it starts all of my messages with "Hello, I'm Guninvalid". I prefer my name to be written lowercase, "Hello, I'm guninvalid". How could I change this in my preferences? guninvalid (talk) 05:41, 10 April 2025 (UTC)[reply]

Not really, that script doesn't collect a custom username - and even if it did it mostly uses templates that don't support inserting a custom username (e.g. Template:uw-vandalism1). — xaosflux Talk 13:12, 10 April 2025 (UTC)[reply]
@Guninvalid: For manually selected messages you could make your own version in userspace, e.g. copying Template:uw-vandalism1 to User:Guninvalid/uw-vandalism1 with {{safesub<noinclude></noinclude>st:REVISIONUSER}} replaced by guninvalid. See Wikipedia:Twinkle/doc#Warn (user talk warnings) for how to use it. PrimeHunter (talk) 15:32, 10 April 2025 (UTC)[reply]

Difficulty reading some user pages in Dark Mode

Hello, I use Dark Mode on Wikipedia, and I have noticed that when I try to read certain User Pages, the text on the User Pages does not change color, and so if I want to read the user pages, I have to highlight all of the text to be able to see it. A good example of this is User:Valjean for the majority of text on their User Page. I have experienced the problem on other user pages, but I do not remember which one. Could this please be fixed? If there is somewhere else I should bring this up, please let me know, so I can bring it up in that place. Thank you very much. Fun Chaos (talk) 15:28, 11 April 2025 (UTC)[reply]

I have found another page where it is a problem, though less of one: User talk:Keeper76. Fun Chaos (talk) 15:42, 11 April 2025 (UTC)[reply]
Users have a lot of flexibility in how they manage and layout their own user pages. You should be able to just toggle dark mode off on the page, that should be much easier than trying to highlight text. — xaosflux Talk 15:45, 11 April 2025 (UTC)[reply]
How do I change that or a single page, I see how to change that for all pages, but that is process that involves me going to my preferences and changing it, and then changing it back after I have finished reading the user page. Is there a more efficient process? Fun Chaos (talk) 15:54, 11 April 2025 (UTC)[reply]

Proposals

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

Bibliography

There could be a table of articles with more bibliographies; collecting data from ISSN, ISBN, ASIN and others for example. Exxxtrasmall (talk) 21:41, 18 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]
Like this one, but per books. Exxxtrasmall (talk) 03:48, 19 March 2025 (UTC)[reply]
I know that there are articles like that in Wikipedia, but I am not convinced that they belong. I feel that they fall afoul of Wikipedia:What Wikipedia is not#Wikipedia is not a directory. Donald Albury 13:48, 19 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]
That's actually a cool idea. (Maybe WP:RA should also be in Annex?) Cremastra (talk) 21:17, 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 Albury 22:48, 19 March 2025 (UTC)[reply]
I do agree with that! Chaotic Enby (talk · contribs) 00:00, 20 March 2025 (UTC)[reply]
Standalone lists are technically a kind of article, but your point still stands with disambiguation pages. jlwoodwa (talk) 23:02, 25 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]
As I have little time, a lot of burnout and the chance of the WP:RA formatting going wrong is immense, could someone use a bot or help me in some way with this? WP:RA formatting going wrong is immense, could someone use a bot or help me in some way with this? Calvice feminina (talk) 14:23, 31 March 2025 (UTC)[reply]
Help were, @Xavier1824, Rodrigo Padula, RodRabelo7, and Jvbignacio9:. Calvice feminina (talk) 15:05, 31 March 2025 (UTC)[reply]

Will an infobox have ... a collapse button?

Original heading: "Will an ibox have ... a collapse button?" ―Mandruss ☎ IMO. 06:31, 27 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}}. Cremastra talk 22:10, 27 March 2025 (UTC)[reply]
I would rather say now, that "all infobox should have a collapse button". I would rather hear more opinions from the others. Dedhert.Jr (talk) 02:53, 28 March 2025 (UTC)[reply]
If an infobox needs to be collapsed it’s a good sign it should probably be trimmed. Collapsing is generally not a solution I support in mainspace— either trim the cruft or split the article. Dronebogus (talk) 00:38, 2 April 2025 (UTC)[reply]
While I agree, this is a much easier and more permanent solution. I'd be in favor of looking into this further. Toadspike [Talk] 08:59, 11 April 2025 (UTC)[reply]

Show total amount of bytes added on contributions page

In the article history tab, the amount of bytes is shown(and the amount of bytes a contribution added/removed is also shown, own both the history). I propose that we show the total amount of bytes added from a user to their contributions page, as currently it own shows the total amount of contributions. Thehistorianisaac (talk) 03:47, 31 March 2025 (UTC)[reply]

They bytes change is listed on every line of user contributions already, see Special:Contributions/Thehistorianisaac. — xaosflux Talk 09:22, 31 March 2025 (UTC)[reply]
I do know that, but i am proposing that it show the total amount, not just the byte change every contribution, like how there is a total contribution count Thehistorianisaac (talk) 09:30, 31 March 2025 (UTC)[reply]
That is not something that we can configure here on the English Wikipedia, however you could file a feature request for that to be added to the software. — xaosflux Talk 09:43, 31 March 2025 (UTC)[reply]
This feature could incentivize the wrong behaviours by gamifying byte collection. At the same time, a byte difference does not display total changes, but the net of addition/deletion. So if I replace 1000 bytes with 1,001 bytes, it will show an addition of one byte instead of 2,001 different bytes. Counter-vandal editors and bots might find it useful for detecting unusual editing, but in of itself, the byte differences don't say much and if we were to make MediaWiki edits, it should be to hide this altogether. ~ 🦝 Shushugah (he/him • talk) 00:09, 1 April 2025 (UTC)[reply]
What would be the use of this number? A good editor may do more for the quality of an article by removing over-verbosity someone else added, or by reverting long vandal screeds. So what, other than a new kind of Wikipedia:Editcountitis, would benefit from this? Anomie⚔ 11:48, 31 March 2025 (UTC)[reply]
One can see this per page via Xtools. This is accessible by clicking Page information under Tools, and then selecting Revision history statistics. Note however that it only tallies positive contributions.  novov talk edits 12:01, 31 March 2025 (UTC)[reply]
New modified version:
Show bytes removed plus bytes added. Thehistorianisaac (talk) 00:18, 1 April 2025 (UTC)[reply]
@Thehistorianisaac for small edits this would be helpful. No matter what two-bytes are changed, I know I can quickly review that. Whereas if a change has 5,000 bytes, it could be a false positive (indenting is an example) or could be genuinely larger change. It would still be questionable, but certainly more useful. See mw:Edit Review Improvements pinging @Pppery@Trizek (WMF) who may know of relevant discussions. ~ 🦝 Shushugah (he/him • talk) 00:26, 1 April 2025 (UTC)[reply]
If I understand correctly, the idea would be to show all bytes additions and bytes removals, instead of just the computed total. In a history page, I imagine it would be shown as something like this (please remember that I'm not a designer. ^^):
  • +173 (+173;0)
  • -1,250 (+102;-1,352)
  • +1 (+1,353;-1,352)
Am I understanding it correctly?
I checked on Mediawikiwiki, so as on Phabricator, and I found nothing that looks like this request.
A good option would be to submit this idea to the Wishlist, under Task prioritization. I think it is the best focus area, as the idea is to help users to spot possible remplacmeents of contents (bullet point #2) or byte-for-byte changes (bullet point #3). Trizek_(WMF) (talk) 16:07, 1 April 2025 (UTC)[reply]
Maybe show added and removed separately so people who stop vandalism also get recognition
overall pretty similar Thehistorianisaac (talk) 16:24, 1 April 2025 (UTC)[reply]
Could another possibility be to compute edit distance, if it isn't too heavy on computational resources? Chaotic Enby (talk · contribs) 15:53, 3 April 2025 (UTC)[reply]
I know nothing * Pppery * it has begun... 00:27, 1 April 2025 (UTC)[reply]

Request For Comment - changing the metals in medals in Wikipedia Service Awards

You are invited take part in a request for comment re the service award system. Wikipedia:Request For Comment - Service Awards proposal Should we move from a motley collection of real and fictional elements to one based at the heavy end of the periodic table? Or a logical scientific one where the closest available halflife is used for each service award? Your input would be appreciated. ϢereSpielChequers 23:45, 31 March 2025 (UTC)[reply]

What about starting with low-number metals, like scandium, and then continuing? I like the idea of climbing the elemental chain element by element, but I think we should start with the lowest-number transition metal and then continue. Then there would be more novelty to having high-number elements. Mrfoogles (talk) 00:26, 1 April 2025 (UTC)[reply]
I suppose it depends on the number of likely discoveries in the next few decades. I'll concede that Scandium as a start point would work for the next few decades. But then so would the half life option. ϢereSpielChequers 00:34, 1 April 2025 (UTC)[reply]
If we are actually going to reconsider the metallurgy, there are plenty of non-meme metals we could use: vanadium, tungsten, columbium, iridium, et cetera. I think a lot of the higher synthetic elements are kind of fake, e.g. how many atoms of seaborgium even exist in the world right now?? jp×g🗯️ 12:24, 3 April 2025 (UTC)[reply]
I agree with JPxG that there are many metals which are far more "real" (in the sense that they exist as macroscopic pieces of metal today) than transactinide elements, which have a very short half-life and are only created a few atoms at a time. It can also help with the future-proofing, as we currently don't have elements past oganesson (118, corresponding to 25 years of service in the proposal) and we are discovering new elements at a way lower rate than one per year.
Starting with low-number metals could be a good idea, although it means newer editors might get lost if we start with some little-known element like scandium. Instead, we could begin with iron (number 26 instead of 21), giving newcomers five familiar metals (iron, cobalt, nickel, copper and zinc) to start with. Then, we can loop to the next row of the table (except if someone wants their medal to melt in their hand, of course). For reference, silver would correspond to Master Editor (6 years / 42k edits) and gold to Most Sagacious Editor (25 years / 235k edits) in this proposal.
Using exclusively transition metals gives little future-proofing (mercury is next, which again might be a bit too liquid, and then we get to transactinide elements), so an option would be to make the medals beyond gold/mercury out of lanthanides and actinides. Having lanthanides go before period 6 transition metals (like platinum and gold) would be more consistent with atomic numbers, but would give a more boring experience for our older editors and make traditional precious metals out of reach for them.
My proposal is thus: transition metals from iron to gold, followed by lanthanides and actinides. Chaotic Enby (talk · contribs) 15:42, 3 April 2025 (UTC)[reply]
That would be more sensible than the sort of award system I was considering. ϢereSpielChequers 17:42, 4 April 2025 (UTC)[reply]
This is pretty much what I was going for, so I might support something like this. Mrfoogles (talk) 17:02, 9 April 2025 (UTC)[reply]

As April Fools day ended I moved the proposal back to userspace at User:WereSpielChequers/Request For Comment - Service Awards proposal I may revive this at some future April if I have more time to promote it. ϢereSpielChequers 17:42, 4 April 2025 (UTC)[reply]

Well, I think they should have iridium and carbide in them for real. jp×g🗯️ 11:41, 7 April 2025 (UTC)[reply]
All this discussion of iridium reminds me of Foundation. Would be a good idea though. Toadspike [Talk] 09:01, 11 April 2025 (UTC)[reply]
And we mustn't overlook mercury: the sweetest of the transition metals! Also bismuth, because FUCK YEAH BISMUTH --Slowking Man (talk) 18:40, 8 April 2025 (UTC)[reply]
Refrigeration technology has been improving, so I don't think we should be so quick to overlook Gallium, Mercury and any other medals that are liquid at blood temperature. Especially when we consider current and future diversity of the editing community, lets not be parochial here. ϢereSpielChequers 13:25, 11 April 2025 (UTC)[reply]
Oh, I completely did not realize this was not serious. The description text did seem a little bit humorous. Mrfoogles (talk) 17:03, 9 April 2025 (UTC)[reply]

Bot that corrects date formats

Would it make sense to have a bot that corrects date formats outside of links, images/other files, templates, and references? Such a bot would probably need to be semi-automated (to reduce the number of false positives) and would change an mdy date to dmy on an article with {{Use dmy dates}} (or vice versa).

I've already made some code for this at User:PharyngealImplosive7/Date-checker.py, though it doesn't completely work yet.

I would like to get others' opinion on such an idea before any bot is actually accepted. – PharyngealImplosive7 (talk) 23:46, 31 March 2025 (UTC)[reply]

Sources already render according to {{Use dmy dates}} no matter what the format is (Day Month YYYY, YYYY-MM-DD or Month, Day YYYY). Why can't we implement this logic in the body? It would spend less time editing source code and more time on rendering the output consistently. Editors who add YYYY-MM-DD would be confident their date is correct/useful regardless. The downside I can imagine of course is variation/ambiguity when it's just DD-MM or MM-DD but contextually relevant within larger paragraph. Lastly, if we are to encourage editing, this would be a beginner task for WP:Suggested edits, where if editors make mistakes it would be acceptable generally (if solely switching order of dates). ~ 🦝 Shushugah (he/him • talk) 00:17, 1 April 2025 (UTC)[reply]
I guess such a method would probably require the creation of a new template that automatically formats all dates based on whether the article has {{Use dmy dates}} or {{Use mdy dates}} (since most dates in articles are just free text, not in any template). Then, a bot would have to add such a template to every date on the encyclopedia, and these templates could misformat dates in quotes, links, and templates incorrectly. Like you said, ambiguity is also a problem. As a result, I think that a supervised bot is a better idea since it requires much less work. – PharyngealImplosive7 (talk) 00:40, 1 April 2025 (UTC)[reply]
I can't immediately find where, but automatic formatting of dates (either in software or by unsupervised bot) has been rejected at least a couple of times before, largely for the reasons PI7 gives around context (especially regarding quotes) and ambiguity of things that look like dates but aren't (software version numbers and phone numbers come to mind as examples). There are also places where it is desirable or even necessary to have inconsistency (e.g. when discussing different date formats). I don't recall seeing a discussion about a supervised bot previously but as long as articles without any date format tag are left unchanged the only issue I can think of is whether just changing the date format would be regarded as a cosmetic edit. I don't think I would classify it as such, but I can see why some people might so definitely best to get multiple opinions on this. Thryduulf (talk) 01:31, 1 April 2025 (UTC)[reply]
@Dabomb87:There is a summary of some of the discussions at User:Dabomb87/Summary of the Date Linking RFCs. That was a little different because they tried to show different date formats according to the readers' preferences, which was a huge failure. But many of the pitfalls of attempting an automated change apply to this proposal. Jc3s5h (talk) 02:18, 1 April 2025 (UTC)[reply]
It is the height of frustration when spreadsheet programs decide to turn what you've written into dates and then decide to reformat your input. Importing such automatic 'help' into Wikipedia sounds like a nightmare. CMD (talk) 02:22, 1 April 2025 (UTC)[reply]
Yeah, I've seen some of the failed proposals before, which is why I made the decision to make any implementation of such a bot supervised and excluding a wide variety of things (after all, false negatives are better than false positives here). – PharyngealImplosive7 (talk) 02:26, 1 April 2025 (UTC)[reply]

RfC to determine how reflinks are linked or not in the |work= field as done by bot. -- GreenC 20:05, 3 April 2025 (UTC)[reply]

User:GreenC bot (WaybackMedic) fixes broken URLs semi-manually per request at WP:URLREQ on a per domain basis. The bot is uniquely programmed for a single domain.

One of the features is incidentally adding reflinks in the |work= field for example converting |work=theguardian.com --> |work=The Guardian. This is done per the MOS WP:REFLINK which states

"Citations stand alone in their usage, so there is no problem with repeating the same link in many citations within an article".

This is done mostly cosmetically, when making other changes within the citation or article. It is not the bot's primary purpose, but since I am making bespoke code specific to a domain, I can easily do this at the same time.

An editor recently requested this feature be disabled. So that I may continue fixing dead links, I complied and set to feature set 2A below. However I would like to see if there is preference from other editors, and to offer a set of features available.

There are 2 choices (bot or nobot), and if bot, 4 choices how:

1. Don't mess by bot
2. Acceptable by this bot, within certain rules.
A) Convert domain names to work name but don't wikilink - template documentation requires name of the work: |work=theguardian.com --> |work=The Guardian
B) Convert domain name to work name and wikilink it: |work=theguardian.com --> |work=The Guardian -- default for the past 5 years it is low volume
C) Wikilink existing work names: |work=The Guardian --> |work=The Guardian - can be high volume
D) Both B and C - recently done for thetimes.co.uk only, that triggered the complaint due to the high volume
E) No opinion
3. Other suggestion. I can not guarantee other suggestions could be programmed. Thus, please include one of the above in addition to any custom suggestions. Custom suggestions without one of the above will default to #2.E the closer will sort it out.

Note: |work= could also be: |website=, |magazine=, |newspaper=, |publisher=

The complainant User:SchroCat at User_talk:GreenC_bot#Stop_linking_newspapers. Others who may be interested based on their knowledge of this tool and CS1|2: @Οἶδα, MrLinkinPark333, Pppery, Chew, Sariel Xilo, Lyndaship, Nemo bis, Kailash29792, Random fixer upper, Headbomb, Trappist the monk, Redrose64, Izno, ActivelyDisinterested, and Lewisguile:

A !vote might look like Option 1 or Option 2B etc.. -- GreenC 20:05, 3 April 2025 (UTC)[reply]

  • I don't see why we should stop linking newspapers, etc. Linking is extremely useful. Headbomb {t · c · p · b} 20:08, 3 April 2025 (UTC)[reply]
    I !vote 2B, fwiw. Headbomb {t · c · p · b} 16:06, 4 April 2025 (UTC)[reply]
  • Option 2B, second choice 2D. Like Headbomb, I am a passionate supporter of linking reference works. In the current information environment, a top question every literate reader should be asking when they look at a reference is "Is this source reliable?" They should not have to blindly trust that it is, and a link to the article about it provides an easy way for them to investigate further. And there is extremely little downside, since references are out of the way at the bottom, and external links are marked as external with the icon, so the source links aren't distracting anyone (thus the guidance at MOS:REFLINK; WP:REFLINK goes elsewhere).
    That said, as much as I urge all editors to make linking the default in their articles, it is something where we allow variation per WP:CITEVAR, and linking only one/some source(s) could create discrepancy. For the situation in B, if an article has not had enough care put into its references to specify the publication name rather than just the URL, I see no issue with updating it to our best practice. (I make a similar call in the AWB task where I correct e.g. |work=New York Times → |work=The New York Times.) But I'm slightly more hesitant to do so for the situation in C. Sdkb talk 20:32, 3 April 2025 (UTC)[reply]
  • Option 2B - If it ain't broke, don't fix it. But when it is, may as well kill two birds with one stone. Adding wiki-links to citations is entirely unnecessary unless you are already fixing the citation. I would, at the very least, want it to change from the URL to the name, and if we're already updating it, why not also add a wiki-link? But forcing it to be linked without changing the contents (what is suggested in 2C) doesn't feel super necessary, unless you are already updating the citations.
    The bigger concern here is seeing what should be in the work param in the publisher param. I would, regardless of how it gets changed, make sure the publisher param is moved to work. E.g. changing |publisher=New York Times to become |work=New York Times . And, of course, you can add the wiki-link to this as well when doing so. This might end up being option 3, if the bot doesn't already do this, but I need to make sure I get this comment out. Chew(V • T • E) 21:07, 3 April 2025 (UTC)[reply]
  • Option 2A. (Second choice option 1). It should be a decision by editor discretion at page level whether to link newspapers or not. It should not be decided by a few of people here or a bot. Having inconsistently formatted references, which is what this will lead to, is amateurish and second rate; it also clashes with the consistency requirements required for featured articles. The MOS does not require these links, and bots should not be forcing a change if editors have decided on following the MOS to keep them unlinked. - SchroCat (talk) 21:11, 3 April 2025 (UTC)[reply]
  • Option 2D or 2B. One complaint in 5 years does not override the clear and demonstrated usefulness of wikilinking reference names. If volume is a concern for 2D I would support rate limiting it (e.g. a maximum number of otherwise unchanged articles per day) Thryduulf (talk) 21:29, 3 April 2025 (UTC)[reply]
  • A - please, per SchroCat, or a lot of editors are in for a lot of work undoing well intentioned bot edits. Gog the Mild (talk) 21:34, 3 April 2025 (UTC)[reply]
    Which they should not undo if there is a consensus per this discussion. Izno (talk) 21:50, 3 April 2025 (UTC)[reply]
    There is no requirement in the MOS for them to be linked, so when editorial discretion follows the line of the MOS in not linking, people will (rightly) revert something that has forced inconsistency into an article. - SchroCat (talk) 01:44, 4 April 2025 (UTC)[reply]
    Reverting a bot performing a job with consensus of a level that might be demonstrated in this discussion is simply disruptive behavior and would be worthy of a block. Izno (talk) 18:04, 4 April 2025 (UTC)[reply]
    No it isn’t. It is editing within the confines of the MOS. If you think editing within the MOS is worthy of a block, that’s a little on the extreme side that wouldn’t stand up long at a review. - SchroCat (talk) 18:34, 4 April 2025 (UTC)[reply]
    I'm not arguing about the MOS though. If a consensus is established here, you have to abide by this consensus also. Not doing so is what earns you the block. Izno (talk) 18:40, 4 April 2025 (UTC)[reply]
    I think you’re misunderstanding what this is about. This discussion is about whether to allow a bot to undertake one single step: it is not a discussion that forces all those aspects of the articles to remain like that forever. If this proposal gets consensus I will not stop the bot from undertaking that task (pressing the stop button to stop it, for example, would be against the consensus, and yes, it would be disruptive and blockable). But I am allowed to edit the article afterwards in my way I wish: this discussion does not change the MOS which will continue to allow flexibility on the point that the linking is based on editorial discretion on individual articles. - SchroCat (talk) 18:47, 4 April 2025 (UTC)[reply]
  • At least 2A. I'm pretty ambivalent about whether something is linked in the work field and have personally disagreed with the practice in the past, mostly because people must eventually figure out what the Guardian is. Izno (talk) 21:54, 3 April 2025 (UTC)[reply]
  • Option 2B, or 2D; per Sdkb and Thryduulf. Also per Chew, I have also personally not witnessed the bot adding reflinks ONLY. It is an addition made alongside a different function the bot is already performing, for example the migration of URLs from thetimes.co.uk to thetimes.com. If the bot were "fixing" every article without reflinks then that would absolutely be excessive and would have been complained about already. Instead it is merely performing a useful addition, one which is supported by MOS:REFLINK, and one within and edit that is already being performed. This had certainly already been discussed, but I fail to see how reflinks are not helpful. Look at a recent page creation like If You Only Knew (Acetone album). Not a single reflink, and most sources being ones I am unfamiliar with. I agree with Sdkb. Every reader should be wondering, "Where is this information supported?", and upon hovering/clicking on an inline citation and seeing no reflink (made even worse in the absence of URLs) readers are not helped. On the aforementioned article, I would have to copy and paste 20 work titles to even somewhat determine that these are reliable sources. I also believe most references are now being auto-generated from URLs with tools like the one in visual editor, which does not add reflinks. Οἶδα (talk) 22:25, 3 April 2025 (UTC)[reply]
  • 1 or 2A. MOS:REFLINK allows repetition of wikilinks within references, but does not require them. Until that changes (which would be a different discussion), linking or not is discretionary, and consistently not linking (or other consistent approaches, like linking only first appearance) shouldn't be changed without discussion. On top of that, changing it as this bot does - on a per domain basis - would introduce inconsistency in most articles, unless one happens to cite only sources from the domains the bot is working on. Nikkimaria (talk) 00:03, 4 April 2025 (UTC)[reply]
  • Option 2B or 2D; the links are useful, especially for sources that users may not know about. For instance, most people who actually read the sources will have some idea of what The Guardian is, but I've edited NZ-focused articles that link to The Post which readers may not be familiar with. I personally only add links to the first mention of a work in citations, but IMO a bot adding redundant links is better than there being no links because humans have better things to do than add them to all articles.  novov talk edits 01:08, 4 April 2025 (UTC)[reply]
  • I don't oppose links in work fields, although I haven't been using them myself much recently, but it does feel close to a cosmetic change. It may be preferable for 2C to happen only alongside other changes. CMD (talk) 02:50, 4 April 2025 (UTC)[reply]
  • 2A. I don't think it's a big consistency problem if some instances of The Guardian in the citations are wikilinked and some are not, or if The Guardian is wikilinked but The New York Times is not, but I don't think a bot should be making that call. 2A is a useful clean up, though. I would be OK with 2B if an editor specifically invoked the bot for a given article, if there's any way to do that. An edit that just adds a wikilink is not cosmetic, but has the potential to flood watchlists so I would prefer not to see 2C. Mike Christie (talk - contribs - library) 04:06, 4 April 2025 (UTC)[reply]
  • 2A I don't understand why we would wikilink the Newspaper if there is a URL linking the actual article that is being referenced, which shows where it comes from. It's also not part of MOS either.Davidstewartharvey (talk) 05:21, 4 April 2025 (UTC)[reply]
  • 2A, for the convincing reasons above. Tim riley talk 07:29, 4 April 2025 (UTC)[reply]
  • 2B I tend to wiki-link from the work/newspaper/magazine/etc. field when I'm constructing citations, as I think it helps to establish reliability, as well as providing sometimes much-needed disambiguation when titles are similar, if not the same, for several publications. That The New York Times is often referred to as The Times is a good example of why such disambiguation is needed. Dhtwiki (talk) 10:05, 4 April 2025 (UTC)[reply]
    But it you sctuslly link the article by URL, it takes you directly, so why would you need a wikilink to show who the works is? Davidstewartharvey (talk) 10:17, 4 April 2025 (UTC)[reply]
    You may be assuming that the cited article remains live on the newspaper's main active site. Older newspaper articles are often to be found only on archive sites such as British Newspapers Online, Newspapers.com or Gale. The article is normally paywalled and most readers can't click through; even if they can, the link won't help them find the newspaper's main website. MichaelMaggs (talk) 13:17, 4 April 2025 (UTC)[reply]
    For some publications, especially those that are less well known or are published in foreign languages and using non-Latin scripts, it's not easy to discern whether they are legitimate news sources or something less reliable. Dhtwiki (talk) 14:50, 4 April 2025 (UTC)[reply]
    @MichaelMaggs and @Dhtwiki That may be the case, however, automatically linking the work of each reference, which in some cases may have been used more than once (I.e. two or three Times articles), would be overlinking. Davidstewartharvey (talk) 15:03, 4 April 2025 (UTC)[reply]
    Not when it’s useful, namely in the references. MichaelMaggs (talk) 15:25, 4 April 2025 (UTC)[reply]
    How can overlinking of, for example, The Times, been useful? If an article is linked to three different articles, a bit would link every single ref to it. That is overkill. Which is why it should be down to editors to link the article. Davidstewartharvey (talk) 15:44, 4 April 2025 (UTC)[reply]
    To help to avoid overlinking is in large part why I voted for 2B, not 2C. Dhtwiki (talk) 15:58, 4 April 2025 (UTC)[reply]
    Reflinks stand alone in their usage with regards to overlinking. Whether the bot should do it is another argument which is already being discussed here. But simply put, how many times a work is reflinked is not an instance of overlinking (MOS:REFLINK). Οἶδα (talk) 20:37, 4 April 2025 (UTC)[reply]
    I fail to see how reflinks should ever be suppressed in the absence of URLs. Readers are not further directed anywhere for content or context. But as you alluded to, URLs correct that somewhat. However, in my view, readers are still lacking necessary context, as a URL is only a primary source for information about itself, without providing broader context for readers to discern whether the source they are reading is reliable. Unless a source is deprecated or blacklisted, any URL can be added. Also a lot of cited news sources have generic names (“Gazette”, “Herald”, “Star”, “Record”, “Mirror”), often cited without the added context needed to disambiguate, such as location. I understand the argument here is that the bot should not be making the decision to add reflinks, but this is what I find to be true at least with regards to best informing readers. Οἶδα (talk) 22:23, 4 April 2025 (UTC)[reply]
    I also find it interesting that WP:CITEVAR states: "The data provided should be sufficient to uniquely identify the source, allow readers to find it, and allow readers to initially evaluate a source without retrieving it." How does one "evaluate a source without retrieving it" in the absence of further context or content? Οἶδα (talk) 05:18, 5 April 2025 (UTC)[reply]
    If it were the case that a link is needed to uniquely identify a source or to evaluate it, then the MOS would already insist on the need for such links. It doesn’t and instead leaves the question down to editor discretion at the level of individual articles. If you wish to claim that this is the only was to identify or evaluate a source, then you’ll need to open an RfC to change the MoS to do just that. - SchroCat (talk) 05:56, 5 April 2025 (UTC)[reply]
    I was not claming that MOS:REPEATLINK prescibes reflinks as mandatory. I was merely quoting a guideline whose choice of words I found interesting in the context of what I emphasized above. You are correct though, this would require an RfC. Οἶδα (talk) 08:19, 5 April 2025 (UTC)[reply]
  • Option 2B, or second choice 2D, per Headbomb, Sdkb, Thryduulf and Οἶδα. I’m particularly unconvinced by the argument that as MOS:REFLINK permits non-linking, the bot should never be allowed to do anything better, and that if it does “people will (rightly) revert”. The MOS no more says it's right to unlink than it does to link. Convenience links to newspapers and other works are extremely useful, and that utility is in my view far more important than trying to enforce essentially trivial internal consistency within a single article's source formatting. The difference, after all, is merely that the names of some works within sources may appear in blue, and some may not. So what? In the longer term, we'd serve our readers better by gradually moving towards linking all works where possible. MichaelMaggs (talk) 11:10, 4 April 2025 (UTC)[reply]
    If you wish to rewrite the MOS to insist on links, then you will need to have the discussion there to change it. At present it does not require links to be linked or unlinked: it is down to the consensus of editors at each individual article. Trying to force the issue by having a bot do it is a form of back-door instruction creep by proxy. - SchroCat (talk) 11:17, 4 April 2025 (UTC)[reply]
    Bots are permitted to do whatever the community authorises them to do, in discussions such as this. Their actions must be consistent with the MOS, yes, but few would be able to operate if they could do only what is specifically insisted upon by the MOS. We're not addressing here what individual editors must or can do; only what authorisation the bot should have to do something that is generally permitted by the MOS. MichaelMaggs (talk) 11:47, 4 April 2025 (UTC)[reply]
    As I've said, it's a back-door instruction creep by proxy. If this rather disruptive measure passes, I don't look forward to reverting these when I see them, but will do so. - SchroCat (talk) 12:00, 4 April 2025 (UTC)[reply]
    You have voiced your opinion and it is well-understood. To be clear though, you reverted the bot wholesale, which included the main edit it was performing (migrating The Times URLs). Such a reversion would be disruptive. Οἶδα (talk) 20:41, 4 April 2025 (UTC)[reply]
    MichaelMaggs, you say that REFLINK doesn't imply that bots should not link; I'd like to ask you more about that. If one of two options is allowed by the MoS, but the community authorizes a bot to always apply one of those two options, that clearly doesn't contradict the MoS, but doesn't it effectively implement one of those two options to the exclusion of the other? I think the issue here is whether the assertion in the MoS that something is up to editor discretion implies that it should not be changed globally (that is, it should be decided at the individual article level). Do you see this differently? Mike Christie (talk - contribs - library) 14:54, 4 April 2025 (UTC)[reply]
    Yes, if what the bot is doing is authorised globally. The point of this discussion is to determine that. MichaelMaggs (talk) 15:31, 4 April 2025 (UTC)[reply]
  • Option 2A (second choice option 1). Linking works should not be automatic -- that is antithetical to MOS:REPEATLINK. If the work is referred to repeatedly in the article, it will create unhelpful overlinking. Instead, linking should be a decision made by the editors at each page. -- Ssilvers (talk) 14:11, 4 April 2025 (UTC)[reply]
    References are not the article. If I click on reference 3, I want a link in reference 3. If I click a link on reference 49, I want a link in reference 49. That it's linked in reference 3 is irrelevant. Headbomb {t · c · p · b} 15:11, 4 April 2025 (UTC)[reply]
    One could make the same strawman argument about wikilinks in general, but we don't link everything, everywhere. - SchroCat (talk) 15:36, 4 April 2025 (UTC)[reply]
    Wholly concur with SchroCat. A modicum of common sense is wanted here. Tim riley talk 18:02, 4 April 2025 (UTC)[reply]
    @Ssilvers: To be clear, what you said is not correct. As I stated above, and which is actually quoted in the OP, reflinks stand alone in their usage with regards to overlinking. Whether the bot should do it is another argument which is already being discussed here. But it is not correct to suggest this is antithetical to MOS:REPEATLINK. What you are referring to is the guideline for links within article sections, not for citations. Οἶδα (talk) 21:31, 4 April 2025 (UTC)[reply]
    To be clear, what you are saying is not correct. It is not necessary or helpful for refs to link the names of works again and again, no matter how many times you repeat that you like it. -- Ssilvers (talk) 00:31, 5 April 2025 (UTC)[reply]
    Okay I'm not sure what we're doing here. Yes, I have voiced support for reflinks in this discussion. It appears I misunderstood what you wrote here and for that I apologise. You stated rather forthrightly that repeat links constitute overlinking, but then stated that it is up to consensus. I understood "overlinking" not as a general reference to an article's "citation style", so I again apologise for misunderstanding. No need for snark. Οἶδα (talk) 04:19, 5 April 2025 (UTC)[reply]
  • Option 2A (second choice option 1). Linking publications/publishers should not be automatic. We have WP:CITEVAR for a reason; it's disruptive to force a certain citation style using a bot. I had a situation with an article several months ago where there was some controversy over the linking of publishers for book citations; I see no reason why |work= can be thought to be exempt from such differences in opinions. With citation formatting, it is much better to allow human flexibility than to force-format things a certain way with a bot. We should be deferring to human judgment here. This proposal honestly feels like a backdoor attempt to force a certain citation style across a wide range of articles, contrary to common sense. Hog Farm talk 20:11, 4 April 2025 (UTC)[reply]
    It is clear the issue is boiling down solely to WP:CITEVAR. So I must ask, to what extent are reflinks actually considered part of a specific "citation style", meaning that they can become part an article's established and consistent stylistic choice, one that must be deferred to and adhered to, with any addition/removal seen as an undue disruption warranting reversion? When I think of WP:CITEVAR, I think of everything outlined at Wikipedia:Citing sources: full citation, short citation (Harvard, MLA), general references, templates, no templates, citation order, etc. Not the "variation" of whether there are reflinks or not. Could an editor also be reverted for adding an author link to a citation because it is not "consistent" in the article or because the most significant contributor of the page decides it goes against their personal/established preference? This seems like a possibly misguided cross-application being that it is not unambiguously supported by WP:CITEVAR or consensus elsewhere. Otherwise, if they are considered a component of "citation style" or the ambiguity skews toward that interpretation, then I suppose 2A really would have to be the way to go. At least until the bot can account for an article's prevailing practice. Οἶδα (talk) 05:26, 5 April 2025 (UTC)[reply]
    The broader MOS:VAR indicates: "Sometimes the MoS provides more than one acceptable style or gives no specific guidance. When either of two styles is acceptable it is generally considered inappropriate for a Wikipedia editor to change from one style to another unless there is some substantial reason for the change...Unjustified changes from one acceptable, consistently applied style in an article to a different style may generally be reverted. Seek opportunities for commonality to avoid disputes over style. If you believe an alternative style would be more appropriate for a particular article, seek consensus by discussing this at the article's talk page or – if it raises an issue of more general application or with the MoS itself – at Wikipedia talk:Manual of Style." With regards to the matter of wikilinking works within references, MOS allows but does not require this be done, bringing VAR into play. Nikkimaria (talk) 13:58, 5 April 2025 (UTC)[reply]
    @Οἶδα: Try running an article with inconsistent linkage through FAC and you'll probably see where this gets sticky. Hog Farm talk 17:00, 5 April 2025 (UTC)[reply]
    Then an RfC would be appropriate. I understand that the MOS leaves the door open to variety, but this does not appear to be a very common or contentious phenomenon on Wikipedia and as such this exact point does not seem to have been deliberated much before. If such a discussion exists, I cannot find it. In the absence of such discussions, it's hard to not bring these aspects up because CITEVAR is being cited as if a community consensus was determined to remand the issue of reflinks in citations to individual consensus. Rather than a general application of MOS:VAR. Was there ever a discussion to determine consensus for a large-scale disruption of established citation styles by the addition/removal of reflinks? I don't believe so. Again, it's not a very common or contentious phenomenon, nor have I seen bots performing these additions which would trigger such discussions until now. If this discussion indicates anything it is that the community would like a consensus on reflinks, and apparently we are not going to have it through a decision about this bot. There is enough ambiguity with WP:CITEVAR as it makes no prescriptions for reflinks (literally no mention whatsoever) nor does it confirm that reflinks are an established component of an article's "citation style", which is what I was referring to above. Οἶδα (talk) 23:18, 10 April 2025 (UTC)[reply]
  • 1 or 2a: per above, and WP:CONLEVELS -- a discussion as to how to programme a bot shouldn't override the MoS, which is to leave this up to individual discretion. We already see good-natured but time-consuming bot edits from various bots which are, by their nature, unable to understand the citation practices established in an article (WP:CITEVAR), and end up acting in ways (such as repeatedly editing an article to change its established citation style) which would see a human editor criticised or sanctioned. 2B, 2C and 2D would all make this problem worse. UndercoverClassicist T·C 20:21, 4 April 2025 (UTC)[reply]
    So then if a bot was hypothetically able to determine the "citation practices established in an article" by assessing whether the citations fully or at least consistently (greater than 50%) included reflinks, you would endorse it? Οἶδα (talk) 22:47, 4 April 2025 (UTC)[reply]
    It would be easy for the bot to determine a prevailing practice of reflinks: parse all the templates and count how many have links. A bot could be more aware and consistent of prevailing practice than humans. BTW in all my years making millions of edits, not a single editor has ever complained of an edit war, it's not that kind of bot constantly running unattended across 6 million pages. It's targeted based on requests for certain domains only, and I don't usually repeat the same domain. -- GreenC 00:32, 5 April 2025 (UTC)[reply]
    I suspect that's because 2B, as you note at the top, includes the conversion of the domain name to the work name, which is a useful thing to do, and because it's relatively low volume. If I had seen one of those edits on an article for which the link contradicted an established consensus, I would not have reverted; I'd have just unlinked. Mike Christie (talk - contribs - library) 09:30, 5 April 2025 (UTC)[reply]
  • Option 2B or 2D: as other editors above have highlighted, linking within sources can be useful; I don't think whether or not something is linked is really an citation style issue so much as many editors use automated tools for creating citations to save time which may or may not include a link for them leading to inconsistency. The fundamentals of the citation format doesn't change (ie. WP:LDR vs in-line with the visual editor) by improving existing citations with links. I've mostly seen requests for consistency (ie. either all sources link or all sources don't link) in good/featured article reviews so having an option for the bot to convert one direction or the other on demand would be useful. Sariel Xilo (talk) 21:20, 4 April 2025 (UTC)[reply]
  • GreenC, would it be possible for the bot to include an option for the requesting user to ask for all links, no links, or as you suggested above to follow the prevailing practice? That would ensure that the decision is always left to editor discretion rather than being a bot default. MichaelMaggs (talk) 04:01, 5 April 2025 (UTC)[reply]
    eh? It wouldn’t be editor discretion, would it? That would be a single editor’s personal preference enforced across several hundred or thousand articles at any one time, regardless of the local consensus at each individual page. - SchroCat (talk) 04:11, 5 April 2025 (UTC)[reply]
    With such an option, the editor has discretion to instruct a globally approved bot to follow existing prevailing practice on every page, in perfect compliance with the MOS. Though I’m not expecting that even that will be enough to change your mind, it does at least dispose of all the arguments you have enunciated thus far. MichaelMaggs (talk) 08:26, 5 April 2025 (UTC)[reply]
    Sorry, but that's nonsense, and it disposes of absolutely nothing. If there is "an option for the requesting user to ask for all links", it enables a single editor to overrule the status quo on hundreds or thousands of individual pages. That's ridiculous. It would be akin to an editor ordering a bot to add (or remove) every serial comma to their own preference, or change language parameters - not just to one article but to thousands. And that's before you even think about what happens when Editor A asks for links to be added and Editor B comes along with the next request and exercises "an option for the requesting user to ask for ... no links" - ie, asking for them to be removed? This isn't a question that can be determined by this RfC - it would need a more fundamental change of the MOS before it even comes close to this. - SchroCat (talk) 08:37, 5 April 2025 (UTC)[reply]
    If I understand correctly, you're not objecting to Option 3: the bot is changed so that it always follows existing prevailing practice on every page. MichaelMaggs (talk) 09:14, 5 April 2025 (UTC)[reply]
    There is no option three at present. - SchroCat (talk) 09:26, 5 April 2025 (UTC)[reply]
  • I propose the discussion of a new Option 3A: that the bot is changed so that it always follows the existing prevailing reflink practice on every page. GreenC has stated above that this would be easy to program, and it avoids the objection of some contibutors that the editor who instructs the bot could potentially be overriding local page consensus, where that exists. MichaelMaggs (talk) 11:11, 5 April 2025 (UTC)[reply]
    I think we should have a clear definition of what the set of "existing prevailing reflink practices" are before this can be considered. Also, a problem I see is that if the practice is being consistently followed already at a given page, there's nothing for the bot to do; and if it's not being consistently followed, it can't determine what the prevailing practice is. It would not be OK to then assume there is no prevailing practice, since a recent edit might have rendered the page inconsistent and not yet been reverted. Mike Christie (talk - contribs - library) 11:29, 5 April 2025 (UTC)[reply]
    I am a bit confused by the different uses of "prevailing practice" and "consistently followed" here. I believe you're saying local page consensus might not be reflected in the current revision of an article due to a recent edit. Yes, each article can have their own documented consensus for reflinks and the bot needs to account for that. But in reality, they typically do not. It hasn't exactly been a very common or contentious phenomenon from what I can find. An article's current makeup should be enough for the bot to run. If a revert is already needed then the bot can be reverted as well, at which point the bot will not perform that same edit. If anything, I was more wondering if the bot could account for pages where the reflink style is MOS:LINKONCE. Without mistakenly linking twice, for example. Οἶδα (talk) 05:27, 7 April 2025 (UTC)[reply]
  • 2D Per Dhtwiki, when the work is wikilinked, I immediately know that the source is notable, and I can read its article to determine reliability before heading off-wiki. When the work is simply a URL, I am potentially left confused between sources with similar names or wary of heading to an unfamiliar site. When MOS:REPEATLINK exists to avoid a sea of blue in the article text, I agree with GreenC that the current guideline that "citations stand alone in their usage" justifies this new wikilinking function. While I can understand requesting the bot to not wikilink in citation templates that do not support it, the appeal to WP:FACRITERIA is maddening. WP:CITE's discussion of consistency in citation styles explicitly refers to the big choices over templates, not whether some works are wikilinked and some are not, even stating that "the data provided should be sufficient to uniquely identify the source, allow readers to find it, and allow readers to initially evaluate a source without retrieving it." Thanks for maintaining this useful bot work, GreenC! ViridianPenguin🐧 (💬) 16:05, 5 April 2025 (UTC)[reply]
  • 2B My personal preference would be 2A, as I dislike the sea of blue that overlooking in references can cause. However other editors appear to find such linking useful, and my distaste of it is not enough to impede other editors. The flip side of that though is that high volume edits such as 2C/D also impact editors, so the lower volume of 2B seems like a sensible compromise. -- LCU ActivelyDisinterested «@» °∆t° 20:44, 5 April 2025 (UTC)[reply]
  • 2A per comments above. If someone prefers the "link each one" style, go for it, but the default bot-level option should be the safest option. If a reader is curious about a reference, we generally want them to click on a URL of the article itself, not an article about the work it was published in. There are times when adding such links is good, but let humans do that, not bots. SnowFire (talk) 04:11, 7 April 2025 (UTC)[reply]
  • 2B In a multicultural English language encyclopedia, linking to the Wikipedia article for the publication is a benefit for users of this Wikipedia. I know it would be for me when I check a citation to an unfamiliar publication. — Neonorange (talk to Phil) (he, they) 14:53, 8 April 2025 (UTC) —[reply]
  • 2B Others have said it better, but I think having the publisher linked to its WP article is good for the encyclopedia, even it I personally don't do so consistently when creating citations. - Donald Albury 15:52, 8 April 2025 (UTC)[reply]
    There is no option to link to the publisher and no-one has suggested that would be a beneficial step. That is not what this RfC is about at all! - SchroCat (talk) 04:26, 9 April 2025 (UTC)[reply]
  • 2B citevar is not an excuse for avoiding doing something that has a clear, tangible benefit to any reader. PARAKANYAA (talk) 02:32, 9 April 2025 (UTC)[reply]
  • 2D or 2B. Wikilinks are very useful in giving context to the citation. I've also found that when the values aren't linked, then there are often times typos in his field which are left uncaught because they aren't linked.
Gonnym (talk) 07:20, 9 April 2025 (UTC)[reply]
The issue you are complaining about won't be resolved by a bot adding wikilinks to correctly spelt titles. Traumnovelle (talk) 09:26, 11 April 2025 (UTC)[reply]
  • 2A definitely oppose 2C/2D. I've only ever once clicked on a wikilink to a work in a reference and it was an accidental click when I was aiming for the url. I have never found these useful, some readers may find them useful but I do not believe their usefulness justifies the the enormous amount of edits this bot would be undertaking to do so. Traumnovelle (talk) 09:23, 11 April 2025 (UTC)[reply]
  • 2B – everything should be wikilinked. As Wikipedians, it should be obvious that wikilinks are useful – I use wikilinked source names all the time, for instance when trying to figure out the ownership and biases of the many Hong Kong newspapers. The easiest, most consistent, and only sustainable solution is to link every reference. Linking the only first instance means that whenever the reference order is changed (a very common occurrence) the link has to be moved, which is busywork that nobody should actually bother doing. Toadspike [Talk] 09:30, 11 April 2025 (UTC)[reply]
  • 2D with the exception of not converting |work=[url name] to a wikilink. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:28, 11 April 2025 (UTC)[reply]

Wikipedia:Notability has an RfC

Wikipedia:Notability has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Mrfoogles (talk) 18:54, 4 April 2025 (UTC)[reply]

mass-creation of china township articles

hello i want to mass-create china township articles i have this brilliant python codelink redacted — Tamzin that i spent weeks creating that mass-creates the pages and then posts them like bam bam bam and it cites citypopulation.de which is a good source for its population and demographics and exact coordinates and area and even its chinese/pinyin text. its very robust and if there's a single bit with an error or if the formatting doesn't add up its like "nope" and skips onto the next article so it never posts buggy stuff and i could red-to-blue like 90% of the china township articles with it in all provinces. i already generated 90% of a-g hebei townships (until someone threatened me) like this one this one and this one and this one and even ethnic townships with no mistakes they're all 100% perfect can i do it thankyou. i can also reprogram it so that submits them all to the draftspace for review if you dont trust theyll be up to standard for publication. Mayeva8823 (talk) 12:42, 9 April 2025 (UTC)[reply]

and yes ill be around to look at them and make sure theyre ok before theyre published i wont just leave the script on while im at college or something Mayeva8823 (talk) 12:46, 9 April 2025 (UTC)[reply]
Never heard of citypopulation.de but I can see it's popular around here:[14] Gråbergs Gråa Sång (talk) 14:44, 9 April 2025 (UTC)[reply]
It may be popular, but is it reliable? From a quick look it seems to be the work of one person. Phil Bridger (talk) 14:58, 9 April 2025 (UTC)[reply]
Some hits at RSN [15], including Wikipedia:Reliable_sources/Noticeboard/Archive_339#citypopulation.de. Gråbergs Gråa Sång (talk) 15:03, 9 April 2025 (UTC)[reply]
Not reliable. Some of the UK tien and cities quote census results but they don't match. Davidstewartharvey (talk) 16:29, 9 April 2025 (UTC)[reply]
Absolutely opposed. Mass geostub creation has wasted more cleanup time around here than almost anything else. How are you going to demonstrate that these are real settlements which really are at the locations given, and really have the names supplied? If you are willing to go over the output of this script and check it, one by one, then I might reconsider. But given that someone else is going to have to do just that, I have to object. We have spent several years cleaning up the US mass creation spree, and we're nowhere near finished. China is surely a much larger project, and verification is surely going to be more difficult considering the PRC's location falsification. Also, haven't we already agreed we aren't going to do this anymore? Mangoe (talk) 16:02, 9 April 2025 (UTC)[reply]
Total agreement! Mass creation should be banned. Davidstewartharvey (talk) 16:30, 9 April 2025 (UTC)[reply]
Yes, we had bad experiences with GNIS, but that doesn't mean that every country has equivalently bad databases. Phil Bridger (talk) 19:17, 9 April 2025 (UTC)[reply]
I also think we should keep in mind the systemic bias aspect. A stub is better than nothing, and often for non-Western countries, the choice is between having a mass-generated stub or having nothing. I'm not saying this alone is sufficient reason to let OP go forward, but it leaves a sour taste in my mouth for us to say that we were willing to permit and then spend the effort to clean up mass stub creation for U.S. municipalities but that we're not willing to do likewise for China. Sdkb talk 19:29, 9 April 2025 (UTC)[reply]
An inaccurate or completely false stub is worse than nothing, and we've had too many problems to assume that any source is reliable enough. And I'm sorry, but even where the databases are relatively good, we still have to interpret them properly. I don't think it is unreasonable to expect some degree of human verification on everything we publish, and for geography that means checking to see that it's really there. The choice is never between having a mass-generated stub or nothing, and our experience here is that database dumps for third-world countries have been particularly bad precisely because of the poor quality of information about them. Mangoe (talk) 19:58, 9 April 2025 (UTC)[reply]
Looking at what this now blocked editor has added today, he has just added stubs based upon an unreliable website which reportedly use census data, which probably do not meet WP:GEOLAND. Davidstewartharvey (talk) 20:33, 9 April 2025 (UTC)[reply]
What do you mean by "threat"? The closest I can find is User talk:Mayeva8823 § Rapid recreation of many articles, and Chaotic Enby was not threatening you there. jlwoodwa (talk) 16:41, 9 April 2025 (UTC)[reply]

If a bot could be coded to be consistent and accurate with decent facts using PRC sites it would actually be beneficial long term and reduce inconsistencies. We do need the articles on township divisions. But it needs to be done right and ideally a start class article or meaty stub. I would allow this editor to generate an example and we can survey it. But use direct government sources, not that website. If all you add is a population figure and create short stubs I oppose. They've got to be informative and accurate if using a bot.♦ Dr. Blofeld 19:44, 9 April 2025 (UTC)[reply]

Since I got a question on my talk assuming otherwise, just to clarify, I've blocked Mayeva for account security reasons ancillary to this thread, but this is not a for-cause block related to their editing. -- Tamzin[cetacean needed] (they|xe|🤷) 20:18, 9 April 2025 (UTC)[reply]

Not advocating for or against, but one might look into Qbugbot, which created about 20k insect articles, and Lsjbot, which has created ~3M articles in Swedish, Dutch, Cebuano, and Waray Wikipedias.
Mathglot (talk) 05:50, 10 April 2025 (UTC)[reply]
I think the Swedes decided to stop Lsjbot because problems. Gråbergs Gråa Sång (talk) 06:01, 10 April 2025 (UTC)[reply]
I think it's terrible what has happened to Cebuano and Swedish Wikipedia, so many bot generated articles renders them soulless. But for missing places where there is generic data I think long term it works out better if started consistently with a bot. Spanish municipalities are a mess and some still without infoboxes, basic data and maps. They should have been generated consistently back in like 2006. Somebody competent with coding bots should sort out China.♦ Dr. Blofeld 09:57, 10 April 2025 (UTC)[reply]

Idea lab

Add an AI-Talk tab to each page

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]
@Mgjertson Well, except for AI-generated images... JoelleJay (talk) 01:02, 26 March 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é Couriano v^_^v threads critiques 16:24, 21 February 2025 (UTC)[reply]
Wikipedia is the opposite of AI. It’s like oil and water; they just don’t mix. Pablothepenguin (talk) 19:57, 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. ϢereSpielChequers 22: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. ϢereSpielChequers 18:24, 22 February 2025 (UTC)[reply]
Strong point, well made. Thanks. DecFinney (talk) 09:46, 24 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.
Even non-BLP falsehoods are not things that we want to commit to the database. I don't think you realize the extent to which this stuff accumulates on even prominent articles, or talk pages with enough activity to get really long. We do not need an accelerant, there are already 20+ years of this shit to clean up. Gnomingstuff (talk) 17:19, 22 February 2025 (UTC)[reply]
@DecFinney: Do the words Seigenthaler incident mean anything to you? —Jéské Couriano v^_^v threads critiques 17:21, 22 February 2025 (UTC)[reply]
@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]
@DecFinney: In order:
Does this help? —Jéské Couriano v^_^v threads critiques 19:05, 24 February 2025 (UTC)[reply]
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]
@DecFinney:
  • 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.
—Jéské Couriano v^_^v threads critiques 06:49, 27 February 2025 (UTC)[reply]
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]
Red X symbolN 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)[reply]
Ah well, this is a great idea. I'm sure they won't violate WP:BLP! Worgisbor (Talking's fun!) 20:40, 7 March 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]
{{nutshell}} isn't for use on articles; summarizing articles is what leads are for. jlwoodwa (talk) 23:04, 25 March 2025 (UTC)[reply]
And AI:s don't know about WP:LEAD or WP:NPOV. I'm reminded of Talk:Intelligent_design#Intelligent_Design_and_the_Law. Gråbergs Gråa Sång (talk) 07:02, 26 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]
{{Oppose|Strong}} Nope. Wikipedia is the only website remaining with a human touch. I say keep it that way. Batorang (talk) 12:25, 4 April 2025 (UTC)[reply]
{{oppose|Strong}} wrong template Batorang (talk) 12:26, 4 April 2025 (UTC)[reply]

AI can go die in a hole far away from Wikipedia. Dronebogus (talk) 09:08, 26 March 2025 (UTC)[reply]

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

Rough example #1

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

You can also:

Rough example #2

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

You can also:

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

This is a cool idea! Toadspike [Talk] 11:51, 18 March 2025 (UTC)[reply]
I also agree! I'm thinking some disambiguation pages tagged with {{R with possibilities}} could make good navigation pages, alongside the WP:XY cases mentioned above. At the same time, we should be careful to not have any "X or Y" be a navigation page pointing to X and Y – it could be useful to limit ourselves to pages discussing the aspects together. Chaotic Enby (talk · contribs) 13:26, 18 March 2025 (UTC)[reply]
Good idea – people seeing the nav page and how it is split across more than one article could also help drive creation of broad-topic articles. Cremastra (talk) 23:40, 18 March 2025 (UTC)[reply]
Also noting that the small text If an internal link led you here, you may wish to change the link to point directly to the intended page. might not necessarily be needed, as it can make sense to link to navigation pages so readers can have an overview of the coverage, and since that page might be the target of a future broad-topic article. Chaotic Enby (talk · contribs) 23:50, 18 March 2025 (UTC)[reply]
This seems a useful idea. As a similar example I'd like to offer Turtle Islands Heritage Protected Area, which I created as an odd disambiguation page because it was a term people might search, but with little to say that wouldn't CFORK with content that would easily fit within both or either or the existing articles. CMD (talk) 01:32, 19 March 2025 (UTC)[reply]
This is great. I often edit articles related to PLAN ships, and since many ships currently lack articles, we cannot use disambiguation pages for those ships(e.g. Chinese ship Huaibei, which has two different frigates with the same name). This could really help out a lot. Thehistorianisaac (talk) 03:33, 21 March 2025 (UTC)[reply]
This seems like a useful idea. It would benefit readers and probably save time at RFD and AFD. Schützenpanzer (Talk) 15:16, 22 March 2025 (UTC)[reply]
Throwing my support behind this as well. It would be very useful in cases where AFD discussions find consensus to merge the contents of an article into multiple other articles. -insert valid name here- (talk) 05:01, 3 April 2025 (UTC)[reply]

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]

@Batorang You only get the article editor if you are logged into an account - logged out users get the "this page does not exist" notice defined at MediaWiki:Noarticletext. 86.23.109.101 (talk) 15:32, 19 March 2025 (UTC)[reply]
But most users are signed into Wikipedia- in fact, Wikipedia actively discourages signed-out editing. Batorang (talk) 04:08, 22 March 2025 (UTC)[reply]
When I clicked on Noarticletext, first of all, it doesn't exist.
Then I purged it and still nothing appeared. It asked me to create the page. Batorang (talk) 04:11, 22 March 2025 (UTC)[reply]
Does Noarticletext need to be created or are you seeing Noarticletext's content itself? LightNightLights (talk • contribs) 07:34, 22 March 2025 (UTC)[reply]
The MediaWiki page just transcludes Template:No article text.
@Batorang, I could be wrong, but I believe this may be a side effect of using the 2017 wikitext editor. WhatamIdoing (talk) 01:37, 30 March 2025 (UTC)[reply]
I don't even use wikitext. I prefer visual editors, for that matter. If you click the link by @86.23.109.101 you'll find that it says that Wikipedia does not have a template of that exact name. Batorang (talk) 11:45, 4 April 2025 (UTC)[reply]
@Batorang The page I linked to is the "this page doesn't exist" message, which includes a link to the search results. 86.23.109.101 (talk) 12:48, 4 April 2025 (UTC)[reply]
i have a screenshot of the page as proof @86.23.109.101 Batorang (talk) 07:35, 5 April 2025 (UTC)[reply]
I don't understand what you're trying to say. Proof of what? Why would I need a screenshot of the page I linked you to? 86.23.109.101 (talk) 11:01, 5 April 2025 (UTC)[reply]
@Batorang, I have two troubleshooting tasks for you.
First: Please open the red link for Random weee (from your example above) in a private/incognito window. Report back here to say:
  1. Whether the private/incognito window has the behavior you want.
  2. Whether the private/incognito window is different from what happens when you click that link while you're logged in.
Second: Please go to Template:No article text and tell me:
  1. Whether the tabs at the top of the page say things like "Create/Create source" vs "Read/View source/View history".
WhatamIdoing (talk) 17:38, 5 April 2025 (UTC)[reply]
Or just scroll down on TM:No article text and see the template's documentation. Plus see if the red link already asks you to Search for "Random weee" in existing articles. Aaron Liu (talk) 21:10, 6 April 2025 (UTC)[reply]
@LightNightLights check below Batorang (talk) 11:49, 4 April 2025 (UTC)[reply]
Whether one gets an editor page or a missing-page warning, having search results would be a good idea. If a specific page does not exist, but closely related pages do, linking something may be a better response than creating a new page. One only knows this after doing a search. Let's make this easy, yes? RayKiddy (talk) 22:47, 30 March 2025 (UTC)[reply]
Agreed. We would also need to think about how it looks if the page was deleted, ie linking to previous AfDs, so that signed in users don't blindly start recreating the article. Most people however would prolly benefit from a search. ~ 🦝 Shushugah (he/him • talk) 00:37, 1 April 2025 (UTC)[reply]

Metadata gadget as the default experience

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

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

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

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

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

Removing "Month and Day" from date of 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.

Policy has to follow practice. You're vastly overestimating the practicability and the tradeoff for something so trivial. Aaron Liu (talk) 14:17, 26 March 2025 (UTC)[reply]
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.
We should consider that such detail "for majority is annoying" and "for minority is beneficial". Hooman Mallahzadeh (talk) 14:22, 26 March 2025 (UTC)[reply]
I doubt anyone finds it annoying. Aaron Liu (talk) 14:24, 26 March 2025 (UTC)[reply]
Citation needed that anyone other than yourself finds it annoying.--User:Khajidha (talk) (contributions) 18:01, 1 April 2025 (UTC)[reply]
@Khajidha This is the Occam's razor principle. This rule says putting unnecessary details in the definition is annoying. The first line (and paragraph) should be as "parsimony" as possible, because it is defining a concept. So it should include only main information and lack any less important ones. Hooman Mallahzadeh (talk) 04:06, 2 April 2025 (UTC)[reply]
A person's full dates are "main information". Thryduulf (talk) 09:32, 2 April 2025 (UTC)[reply]
@Thryduulf I think "person's full birthdate" is not "main information" when defining a person. The reason is that without "full date" and mentioning only "year", the definition experiences no problem. Hooman Mallahzadeh (talk) 09:36, 2 April 2025 (UTC)[reply]
Some detail that does not affect the "defining whole concept" may be omitted. Hooman Mallahzadeh (talk) 09:39, 2 April 2025 (UTC)[reply]
As someone else pointed out, that's not Occam's razor. --User:Khajidha (talk) (contributions) 09:39, 2 April 2025 (UTC)[reply]
Besides whether it is Occam's razor or is not, the important thing is that we should make our "introduction paragraph" of articles in Wikipedia as parsimony as possible. Do you disagree with that? Hooman Mallahzadeh (talk) 09:52, 2 April 2025 (UTC)[reply]
Yes, I disagree that introduction paragraphs should be as parsimony as possible. The lead section provides an overview introduction to the article as a whole. Conveying the least amount of information possible is neither the goal nor beneficial. Thryduulf (talk) 10:06, 2 April 2025 (UTC)[reply]
@Thryduulf We have
  1. Introduction (writing)
  2. Abstract (summary)
  3. Lead paragraph
each of which introduces different concepts, but we have "summarizes" and "brief explanation" and "brief summary" in their definitions. These are other names of "parsimony". Hooman Mallahzadeh (talk) 11:32, 2 April 2025 (UTC)[reply]
We're just back at #c-Aaron_Liu-20250326134100-Hooman_Mallahzadeh-20250326130000 now. Aaron Liu (talk) 11:46, 2 April 2025 (UTC)[reply]
No, parsimony is not a synonym of "summarise", "brief explanation" or "brief summary", it means The quality or characteristic of using the fewest resources or explanations to solve a problem. Absolutely nothing requires or even encourages us to use the fewest words or convey the least amount of information possible. Thryduulf (talk) 11:52, 2 April 2025 (UTC)[reply]
@Thryduulf No, I only said that

If you encounter a definition that incorporates some data that is not considered "the most important data", then remove that part (data) from the definition and mention that somewhere else.

Is the above idea wrong? Hooman Mallahzadeh (talk) 12:02, 2 April 2025 (UTC)[reply]
I'm not quite sure what your asking here, but none of "Summarise", "brief explanation" or "brief summary" restrict the summary/explanation to only "the most important data", and separately it seems that your view of what "the most important data" is is very significantly narrower than pretty much everybody's else's. Thryduulf (talk) 12:33, 2 April 2025 (UTC)[reply]
@Khajidha See Occam's razor article

It recommends searching for «explanations» constructed with the smallest possible set of elements.

Hooman Mallahzadeh (talk) 09:54, 2 April 2025 (UTC)[reply]
Which is completely different frem what we are discussing.--User:Khajidha (talk) (contributions) 10:40, 2 April 2025 (UTC)[reply]
We are dealing with "definitions" in the leading sentence of articles. I really surprise about why you say it is different. Hooman Mallahzadeh (talk) 11:36, 2 April 2025 (UTC)[reply]

This philosophical razor advocates that when presented with competing hypotheses about the same prediction and both hypotheses have equal explanatory power, one should prefer the hypothesis that requires the fewest assumptions

Another way of saying it is that the more assumptions you have to make, the more unlikely an explanation.

Aaron Liu (talk) 11:43, 2 April 2025 (UTC)[reply]
Occam's razor is about constructing hypotheses (or choosing between hypotheses), not writing definitions. --User:Khajidha (talk) (contributions) 12:48, 2 April 2025 (UTC)[reply]
This article uses the word "explanation" multiple times, I think it implies "definition". Hooman Mallahzadeh (talk) 15:17, 2 April 2025 (UTC)[reply]
I think it implies "definition" it doesn't. Thryduulf (talk) 15:47, 2 April 2025 (UTC)[reply]
It's an explanation of "how", not "what". Aaron Liu (talk) 15:59, 2 April 2025 (UTC)[reply]
I think that we are running up against WP:CIR here. --User:Khajidha (talk) (contributions) 16:32, 2 April 2025 (UTC)[reply]
I'm becoming increasingly inclined to agree. Thryduulf (talk) 17:19, 2 April 2025 (UTC)[reply]
@Khajidha@Thryduulf I really don't want to disrupt Wikipedia. Even in IELTS Exam, there exists some policies about how to write introduction and a rule says: introduction should not contain numbers at all.
I only want to impose a policy on "how to write introduction" of Wikipedia articles. Exactly the same as IELTS writings. This policy would says in the introduction paragraph of Wikipedia:
  • What should be included
  • What should be omitted
Because it seems that no policy exists till now. Hooman Mallahzadeh (talk) 17:20, 2 April 2025 (UTC)[reply]
Why should we care what the IELTS says? --User:Khajidha (talk) (contributions) 18:31, 2 April 2025 (UTC)[reply]
Not everything needs a policy. Thryduulf (talk) 19:50, 2 April 2025 (UTC)[reply]
It is a matter of quality of Wikipedia articles. Like IELTS, such policies about introductions of Wikipedia articles impact "Coherence" of that article. "High coherence" means "easier reading". Therefore, quality of Wikipedia articles increases this way. Hooman Mallahzadeh (talk) 03:45, 3 April 2025 (UTC)[reply]
I searched it up; that guideline is just for summarizing a chart and also recommends you to include dates in the first paragraph when appropriate. There is no IELTS guideline for writing a biographical profile. Aaron Liu (talk) 11:33, 3 April 2025 (UTC)[reply]
You should get the idea of IELTS not its instruction. It says:

Do something that your reader understands your essay by just one time reading.

and this is achieved by TA, CC, GRA and LR. The idea of coherence of articles is applied beyond IELTS, for example, when writing an academic article for a journal, there exist policies related to coherence. It says what data should be inserted in what part of that scientific article.
Why Wikipedia hadn't obeyed similar cohesive policies? Our goal is:

Makeing Wikipedia article more readable.

Hooman Mallahzadeh (talk) 11:45, 3 April 2025 (UTC)[reply]
And I'm saying #c-Aaron_Liu-20250326142400-Hooman_Mallahzadeh-20250326142200. Aaron Liu (talk) 12:01, 3 April 2025 (UTC)[reply]
You said "anyone". That's completely true. If someone wants to take a birthday party, or commemorate his death, then such data would be very helpful for that person. But the problem is that majority of readers would neither want to take birthday party for him nor to commemorate his death date. Threfore an approximate date is more useful for them. Hooman Mallahzadeh (talk) 12:09, 3 April 2025 (UTC)[reply]
Here's what I actually said, translated into Persian: من شک دارم کسی آن را آزاردهنده بداند. Aaron Liu (talk) 12:38, 3 April 2025 (UTC)[reply]
No need to Persian, just mathematically:
For myself it is annoying. So the above rule has a counterexample and it is not true. Hooman Mallahzadeh (talk) 12:45, 3 April 2025 (UTC)[reply]
If here "anyone" implies "majority", then we can apply a psychological test:
  1. Apply two versions of an article by "Full date" and "Abstract date" to a group of people
  2. Ask them which one is more annoying
Then we can report the result. Hooman Mallahzadeh (talk) 12:58, 3 April 2025 (UTC)[reply]
  1. 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.
  2. "I just don't fancy it," is not a very good rationale for a change that would affect a million plus articles. GMGtalk 14:30, 26 March 2025 (UTC)[reply]
    In my opinion using tooltip is a reasonable policy in such cases, we can use a sentence like this:

    Steven Paul Jobs (1955 – 2011) was an American businessman, inventor, and investor best known for co-founding the technology company Apple Inc.

    and by tooltip, we can satisfy both minority and majority of viewers. Hooman Mallahzadeh (talk) 14:37, 26 March 2025 (UTC)[reply]
    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. GMGtalk 14: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]
The month and day are potentially harmful per Wikipedia:Biographies of living persons#Privacy of personal information and using primary sources (though Steve Jobs is no longer a BLP). WhatamIdoing (talk) 02:04, 30 March 2025 (UTC)[reply]
I like the idea, if – and only if – there is either an infobox containing the full dates, or if the exact dates are mentioned in the body of the article (e.g., in the ==Childhood== and ==Death== sections).
Additionally, I'd leave the first-sentence dates in place for recent births/deaths, since someone might look up "New Baby Royal" or "Celebrity Justin Died" for the primary purpose of finding that recent date. WhatamIdoing (talk) 02:07, 30 March 2025 (UTC)[reply]
We have talked about this before in the past..... I also think there's no need to write it out two times if the info box has the information. As we know most people scan the infobox [16] and it would reduce first sentence clutter that's always a consideration in bios. Moxy🍁 02:15, 30 March 2025 (UTC)[reply]
Turning everything into “clutter” is a good way to start chopping off half the encyclopedia. 99% of Wikipedia is meaningless junk to 99% of people. Dronebogus (talk) 17:25, 1 April 2025 (UTC)[reply]
ِDear @Dronebogus

Turning everything into “clutter”

Not everything! Not clutter! I mean, "first lines" should be as parsimony and concise as possible. This rule also exists in "introduction" Writing part of IELTS. The reason is that many people would only read "first line(s)" and would not read the rest. Removed data are not clutter, in fact they should be mentioned somewhere else, possibly using techniques like incorporating tooltip or footer. Hooman Mallahzadeh (talk) 03:58, 2 April 2025 (UTC)[reply]
I see no evidence that IELTS is the undisputed pinnacle of writing at all, let alone in any and every context for any and every audience. It is merely one set of style choices for demonstrating ability in one way, chosen as such for one specific purpose. DMacks (talk) 17:36, 2 April 2025 (UTC)[reply]
I absolutely hate it when basic information is hidden away in the infobox (which I often do not notice). There should usually be no information in the infobox that is not in the prose somewhere. —Kusma (talk) 20:36, 2 April 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.

Thanks! Aoppo (talk) 15:45, 26 March 2025 (UTC)[reply]

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.
Kind thanks Jeffme (talk) 19:48, 26 March 2025 (UTC)[reply]
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]
Thanks a lot for the technical details! @Aoppo, @Jeffme, are you interested in making it a user script? Chaotic Enby (talk · contribs) 13:01, 27 March 2025 (UTC)[reply]
Just so I can confirm your question made it through to me :) , Minh Nguyễn and I are in close communication & I follow his lead on these things. Jeffme (talk) 19:51, 28 March 2025 (UTC)[reply]
Yes, it could be cool! Are you interested in contributing? 2A01:827:1A72:8001:39E8:1AB:7F45:DD6F (talk) 09:53, 29 March 2025 (UTC)[reply]
Not directly, but I would be happy to help if you have any specific questions! Chaotic Enby (talk · contribs) 11:49, 29 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? Cremastra talk 22: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. Cremastra talk 00: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.
 – Minh Nguyễn 💬 00:25, 28 March 2025 (UTC)[reply]
At least the security team plans say they'll give an answer with some policy updates this quarter, which ends March... Aaron Liu (talk) 14:15, 28 March 2025 (UTC)[reply]
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]
Hello, first version of the userscript. It works, but is a little buggy.
https://github.com/theRAGEhero/GlobStory-Wikipedia-user-script/tree/main Aoppo (talk) 12:39, 5 April 2025 (UTC)[reply]
@Aoppo It would be a good idea to have a copy of this script as a subpage in your userspace (e.g. at User:Aoppo/Globstory.js) so that other people can load it into their common.js pages. 86.23.109.101 (talk) 15:18, 5 April 2025 (UTC)[reply]
Seconding this, user scripts hosted on-wiki are more practical, and (optionally) you can even add a documentation page at User:Aoppo/Globstory that will automatically be linked! {{Infobox Wikipedia user script}} can be helpful if you want to do that! Chaotic Enby (talk · contribs) 15:39, 5 April 2025 (UTC)[reply]
Thank you, I'll do it soon. Aoppo (talk) 18:42, 5 April 2025 (UTC)[reply]
Done! Aoppo (talk) 22:01, 5 April 2025 (UTC)[reply]
Hi everyone, a user script has been created:
Instructions: https://en.wikipedia.org/wiki/User:Aoppo/Globstory
User script: https://en.wikipedia.org/wiki/User:Aoppo/Globstory.js
Any feedback or suggestion is welcome.
Thanks! Aoppo (talk) 12:41, 7 April 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]

Rishabisajakepauler has been abusing the system for four years. I would like to close the loophole. Binksternet (talk) 23:28, 28 March 2025 (UTC)[reply]

Maybe an edit filter disallowing removal of #redirect\[\[.*\]\] from pages by non-autoconfirmed users?
!("confirmed" in user_groups) &
page_namespace == 0 &
removed_likes irlike "#redirect\[\[.*\]\]" &
!(added_lines irlike "#redirect\[\[.*\]\]")
Chaotic Enby (talk · contribs) 11:51, 29 March 2025 (UTC)[reply]
We could also just target the "mw-removed-redirect" tag. Aaron Liu (talk) 19:26, 29 March 2025 (UTC)[reply]
Certainly a better idea! Chaotic Enby (talk · contribs) 19:33, 29 March 2025 (UTC)[reply]
If it's technically feasible, I think it's a good idea that helps enforce the spirit of the 4/10 rule. Schazjmd (talk) 13:35, 29 March 2025 (UTC)[reply]
Previously discussed in 2023 at Wikipedia:Village pump (proposals)/Archive 206 § Proposal: extend ACPERM to IP editors overwriting redirects. I'll just copy-paste what I wrote there:
1) This will also prevent non-autoconfirmed users from restoring a long-standing page that has been turned into a redirect. There's no way for an edit filter to "see" the old revisions of a page, apart from the timestamp of creation, a list of recent contributors, and the name of the first contributor. Best we could do exclude summaries containing "undo", etc., but that could be trivially exploited by bad-faith users, and won't help people who try to manually revert.
(2) Edit filters (as opposed to page protection, the title blacklist, or the hard-coded ACPERM restriction) lead the user down the garden path of thinking their edit will save, until they actually click "publish". I am thinking about the user who discovers some notable subject is a redirect, spends hours composing a carefully referenced page, then clicks "publish", only to be told "nope". Yes, their edit is saved in the filter log, and we can recover it for them at WP:EFFP, but they may be so dispirited at that point that they just give up. Most filters either deal with actual abuse, in which case this is a feature, or are warn-only, so they can still click "publish" and fix the problem later. This problem could partly mitigated, I guess, by putting a big shouty message wrapped in <div class="unconfirmed-show">{{#invoke:Page|isRedirect| ... }}</div> in Template:Editnotices/Namespace/Main, but editnotices are easy to miss, and I'm not sure if that hack will even work in every editor.
Now we don't have to stick with using an edit filter. If someone can think of another method that addresses these concerns (especially the second one), I don't have a major objection to this on principle. Suffusion of Yellow (talk) 01:33, 30 March 2025 (UTC)[reply]
I would much rather see an edit filter put in place, and if it needs a shouty notice, so be it. Regarding the notional vandalism of a longstanding page turned into a redirect, we could also require such redirects to be placed only by auto-confirmed users. The redirect should be off limits to newbies and returning vandals. Binksternet (talk) 01:16, 1 April 2025 (UTC)[reply]
I guess that an admin bot could semi-protect all redirects if there was consensus for that. It wouldn't be perfect - it would prevent new editors from doing things like retargetting or categorising redirects, and from nominating them at RfD; there would inevitably be a lag between redirect creation and protection and there might be edge cases regarding redirects protected at different levels. Semi-protection also wouldn't solve Suffusion of Yellow's first concern but I think it would at least reduce the impact of their second. I suspect placing a template on a redirect page would allow individual redirects to remain unprotected if there was a desire for that for some reason (I don't know if that could be gamed). Independently of method used, if we decide to go down this route, we need to decide which namespace we want it to apply to (both a bot and an edit filter can be configured by namespace, I don't know about other methods).
Without knowing how big the issue is, I'm wondering whether a warn and/or tag ("new user removing redirect") filter would be sufficient. Obviously it wouldn't stop editors from hijacking redirects, but it would make it much easier to detect, revert and (where appropriate) sanction.
If the issue is related to contentious topic areas then maybe a bot that protects redirects to EC-protected pages at that level (and unprotects them if the protection is removed/downgraded) would help. Thryduulf (talk) 02:02, 30 March 2025 (UTC)[reply]
I'm not sure this is a good idea. Whenever possible, one bad actor should be dealt with as one bad actor, rather than by placing restrictions on everyone else in the world.
Perhaps Wikipedia:Requested moves/Technical requests could be advised of the problem, and any requested redirects be given a long semi (e.g., a year, or even a few years)? WhatamIdoing (talk) 02:26, 30 March 2025 (UTC)[reply]
Whenever possible, one bad actor should be dealt with as one bad actor, rather than by placing restrictions on everyone else in the world agreed, which is why I suggested at least starting with warning/tagging rather than protection. Thryduulf (talk) 18:35, 30 March 2025 (UTC)[reply]
I think you meant Wikipedia:Articles for creation/Redirects.
I do not like the idea of semi-protecting redirects. There's menial tasks that can be done on redirects which IP editors can help with. I think an edit filter preventing removal of the redirect is a better solution than semi-protecting redirects which are not necessarily subject to abuse, but it also has issues as mentioned above. Skarmory (talk • contribs) 23:01, 3 April 2025 (UTC)[reply]
Instead of restricting edits completely, why not let a bot move it automatically into draft space? —CX Zoom[he/him] (let's talk • {C•X}) 17:30, 30 March 2025 (UTC)[reply]
The bot would need to recreate the redirect afterwards, and things might get complicated if the redirect has previous history and the new addition needs reverting. Even more so if we end up with parallel histories. Thryduulf (talk) 18:34, 30 March 2025 (UTC)[reply]
1. I doubt how common incidences of 1) that should be kept are.
2. I believe that an edit notice would indeed solve the problem (perhaps + a part of the edit filter message that says it's recoverable from logs).
However, in the discussion you linked I did find an I-M-O extremely persuasive argument that NPP already checks removals of redirects. Aaron Liu (talk) 18:52, 31 March 2025 (UTC)[reply]
I've encountered this too, with a banned editor CFORKing through redirects. The issue with general solutions that add another layer of review like edit filters and pending changes is that unless reviewers are familiar with a particular user they won't have much notification that anything is amiss. CMD (talk) 03:58, 31 March 2025 (UTC)[reply]
What is the scale of the issue trying to be addressed here exactly? Off-handedly the vast majority of unregistered and new user edits to redirects seem to be fine, tweaking r-cats and the like. Fixing broken {{R to section}}s or finding better targets for existing redirects is a relatively newcomer friendly set of tasks.
There's also all sorts of weirdness that results. If I redirect a page for lacking sources could I then not revert myself if I subsequently do the research and find some sources? The change is stated to be for the purpose of combating LTAs, but there are also LTAs that turn pages into redirects which then need to be reverted, so even as one type of disruption is impeded another will persist for longer. Comparative scales aren't easy to judge, but even restricted to the area of dealing with disruption this is not clearly a net positive.
Furthermore, this idea seems to have arisen due to the actions of a single LTA. Now, I am not familiar with them specifically, however as a general rule of thumb semi- is only a speedbump for the obsessive types and not even that for the more clever among them, so it may not even achieve its stated purpose while still incurring the associated costs.
Bottom line, we've been dealing with disruptive conversions both to and from redirects for quite a while now and not just from non-autoconfirmed users, and we have well-honed procedures for doing so, the soft security works fine. 184.152.65.118 (talk) 17:34, 4 April 2025 (UTC)[reply]
Maybe you missed the link to a previous discussion in 2023: Wikipedia:Administrators'_noticeboard/IncidentArchive1139#Cleaning up after protracted move vandal. That was a different vandal. I imagine there are more, but searching for them is close to impossible. Even good-faith IP editors should be prevented from changing a redirect to an article. The proposal is just to enforce existing policy by using technical means. Binksternet (talk) 18:30, 4 April 2025 (UTC)[reply]
Except that some sockmasters disruptively convert pages into redirects I just reverted one of them today. You can find some new users who first got involved with the project by reverting the conversion of an article to a redirect which they felt was improper, sometimes they were even right. The majority of the time it's not an issue.
I'm aware there are other sockmasters who disrupt redirects, my point is the present proposal appears to have arisen from the recent actions of one of them, and it seems unlikely they would be stopped, as opposed to merely inconvenienced, by its implementation. I'm not all that confident the others will either.
Even good-faith IP editors should be prevented from changing a redirect to an article why? Is there any issue that soft security has been unable to redress here? Are you aware that some unregistered users including myself have over the years needed to revert autoconfirmed sockmasters who were disruptively changing pages to redirects? Sure it can be handled through reporting but why not spread the work around. Furthermore obvious disruption should ideally be revertable by anyone around the world; you don't need to have ever edited before to recognize that redirecting a bio to something obscene is wrong, the undo interface is fairly intuitive, and we have on many occasions been aided in fixing those promptly by users around the world who may have that as their only ever contribution. Far to many downsides to implement. 184.152.65.118 (talk) 18:51, 4 April 2025 (UTC)[reply]
The filter could also just log only if the Undo tag is also present. Aaron Liu (talk) 01:40, 5 April 2025 (UTC)[reply]
Yes we could limit filtering to only those cases were a redirect was removed, and the edit was not an undo, and that is a much better idea than what was earlier proposed, but I'm still unconvinced the level of disruption is sufficient to warrant even that more limited measure or that the usual soft security cannot be relied on here. 184.152.65.118 (talk) 01:54, 5 April 2025 (UTC)[reply]
Do we even know what the level of disruption is? It feels like different people have different anecdata but actual hard numbers don't exist? If the average number of instances is about one a week then the proportional response is rather different to what it would be if it's regularly happening multiple times a day). Thryduulf (talk) 03:44, 5 April 2025 (UTC)[reply]
https://en.wikipedia.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1&namespace=0&tagfilter=mw-removed-redirect&limit=50&days=7&urlversion=2 should be useful. If we don't allow non-autoconfirmed to create pages, we shouldn't allow them to turn redirects into pages. Aaron Liu (talk) 21:17, 6 April 2025 (UTC)[reply]
Exactly. Binksternet (talk) 11:30, 11 April 2025 (UTC)[reply]
  • @Aaron Liu: you twice mentioned revision tags, unless I'm having some major brain fog, "tag" isn't a variable exposed to the abusefilter, as it occurs post-edit - whereas abusefilter processes pre-publishing. Am I missing something? Here is a recent example of an IP user converting an article redirect to a non-redirect: Special:AbuseFilter/examine/1893987261. Using tags is something that recent changers patrollers may find useful, and other detection systems could use. — xaosflux Talk 12:56, 11 April 2025 (UTC)[reply]

"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. (got confused, this is false, see below) 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]
It's a great idea. It would be a really valuable contribution. And if we had done it 20 years ago, we'd be reaping the benefits now.
But change is hard. This change is really, really hard. It's not just that old editors like me would need to change their language. (A lot of us won't, and that's okay, because the redirects would still work.) But we (i.e., the experienced editors; the power users; the core community) would have to agree that this actually is super confusing to newcomers; that we don't want newcomers to be confused about this; that we want the newcomers and total outsiders to understand this fundamental point enough that we're willing to give up our "traditions" and "history" and "insider jargon" to accomplish it.
And that's the easy part. After that, we'd have to choose a specific alternative. mw:Naming things is hard.
For me, the question is: Twenty years from now, do I want editors to still be explaining "Yes, I see you have a reliable source using the exact words 'Alice Author is a notable new author', but that doesn't mean she's WP:Notable according to Wikipedia"? My answer is no. Therefore, in principle, I support changing the name.
If we can come up with a suitable alternative, then I suggest using it for a few years as a synonym. A hard change from "Notability is how Wikipedia editors decide whether to create a separate article" straight into "Eligibility is how Wikipedia editors decide..." is too abrupt and will probably provoke a backlash. Instead, I think we'd be best off with "Notability, or eligibility, is how Wikipedia editors decide..." for a good long while. Eventually the more ambiguous older term could be gently reduced in prominence. WhatamIdoing (talk) 02:37, 30 March 2025 (UTC)[reply]
I think that would be good, having a soft transition into eligibility. As a lot of newcomers and outsiders think of notability as a general they are worth noting and not do the qualify under WP:Notability. Where as eligibility makes people aware that there is requirements to have a article. Sheriff U3 03:17, 30 March 2025 (UTC)[reply]
I also do agree that this change (especially with a soft transition) would be ideal. People come here with an intuition of what "notability" means to them, as it is a generic word, while "eligibility" is more clearly "elibigility for Wikipedia". To use the example above, "Alice Author is an eligible new author" doesn't make sense without asking for what she is eligible, which automatically makes it a better word to give a Wikipedia-specific definition to.
One thing I have in mind is the case of lists of individually notable subjects – many of them use "notable" as a way to limit the eligibility criteria to subjects already having a standalone article, but play on the ambiguity of "notable" being a natural English word to avoid making an obvious self-reference like "eligible" would. Chaotic Enby (talk · contribs) 10:34, 30 March 2025 (UTC)[reply]
Agree that eligibility fits what is meant much more clearly, and is more obviously a reference to en.wiki criteria. CMD (talk) 10:52, 30 March 2025 (UTC)[reply]
To be fair, it is often the criteria they actually use —- you could argue a notable person without coverage would not be featured on Wikipedia lists, making them inaccurate Mrfoogles (talk) 16:35, 30 March 2025 (UTC)[reply]
Also agree a soft transition might be more feasible, as well as more easy of a sell to the community. Mrfoogles (talk) 16:36, 30 March 2025 (UTC)[reply]
"Worth noting" is WP:NOTEWORTHY, which is different from notability. But I understand that this distinction isn't obvious at first glance. jlwoodwa (talk) 21:16, 30 March 2025 (UTC)[reply]
I think the idea of a soft transition from "notability" to "eligibility" over an extended period is worth exploring. i would like to see what arguments are raised against that change before committing to it. Donald Albury 17:27, 30 March 2025 (UTC)[reply]
It might be worth laying out exactly what things would need to be changed. Old essays would probably remain, but policy, guidelines, and prominent essays would need to be fixed. And some sort of notice would probably need to be posted that Wikipedia was transitioning from "notable" to "eligible" -- probably in stages e.g. something like
1. Eligibility may be used and is mentioned (i.e. "Notability, or eligibility is") in policy
2. Eligibility is recommended to be used and is used by policy (i.e. "Eligibility, or notability is")
3. Eligibility should be used and is solely used by policy (i.e. "Eligibility is") Mrfoogles (talk) 20:57, 30 March 2025 (UTC)[reply]
@Donald Albury, there are a few predictable objections:
  • There are one-time costs associated with any change. (There are also ongoing costs for not making this type of change.)
  • Change is bad. Or at least hard. Neither the costs nor the benefits will be evenly distributed, and I may believe that the expected cost-to-me-personally will be higher than the expected benefit-to-me-personally. I might therefore oppose it as a waste of time and effort, especially if I look at it from the POV of myself only (rather than the whole community), or if I look at only the cost/benefit in the near term (rather than for coming decades).
  • Whatever is chosen, some editors will dislike it, and at least one of them will be noisy about it.
  • Someone will believe (incorrectly, but genuinely) that any such change must be a an all-or-nothing change, and will thus object on the grounds that any effort will doubtless overlook some obscure welcome template, and then what will we do, because on the 32nd of Octember, we're changing all the wording, and by the next morning we'll have completely forgotten what WP:N used to mean. Yes, it's a silly objection. But I predict some variation on this will happen anyway. People aren't always as logical or as thoughtful as they'd like us to think.
  • We'll have to make some sub-decisions, e.g., about whether to rename the WP:SNGs at the same time. The one-time costs (of decisions, discussions, implementation...) can be spread out over ~five years, but they're not necessarily small.
If you want to take a different approach to predicting objections, then Yes Minister explains how to avoid doing things that you don't want to do: First, you claim that it's too soon (really, it's early days... We should have another discussion or five). After that, you can agree that something should be done, but question whether this the right thing to do. (This is the most effective way to derail a proposal at the English Wikipedia. Editors can get stuck here for years, with endless debates about what, exactly, the True™ Ideal replacement word/phrase should be.)
If we manage to get page that stage, you can claim that now is not the time, because there's always some crisis around the corner. AI's taking over, or mw:Temporary accounts is going to swap the CheckUsers, so we can't do it right now. And, finally, there will be unspecified technical or legal problems, all of which are too vague to fix and too serious to permit advancement. And now it's too late, because we've wasted a decade. WhatamIdoing (talk) 05:58, 31 March 2025 (UTC)[reply]

about whether to rename the WP:SNGs at the same time

Easy: We rename Notability to Nellijability, or "Nelly" for short.[Joke] Aaron Liu (talk) 21:47, 31 March 2025 (UTC)[reply]
What do people think is better, by the way -- "eligibility" or "admissibility"? Because "eligibility" might force people to change e.g. Articles for improvement/Eligibility criteria, but "admissibility" is sort of an odd phrasing, and "eligible for inclusion" seems better than "admissible". "Suitability" is interesting, but still not as direct an expression of "eligible for an article" as "eligibility". Overall I prefer "eligibility", but I'm not sure what other people think, and no one has mentioned it yet. Mrfoogles (talk) 21:14, 30 March 2025 (UTC)[reply]
"Eligibility" makes it implicit that it is about being eligible in the context of something, so Wikipedia:Articles for improvement/Eligibility criteria should be fine as it is clear that it's being used in a different context. Although I wouldn't be opposed to changing that one to Wikipedia:Articles for improvement/Criteria for the sake of conciseness. Chaotic Enby (talk · contribs) 22:13, 30 March 2025 (UTC)[reply]
Made a post on WP FR asking what their experience is: https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/30_mars_2025#L'admissibilit%C3%A9 Mrfoogles (talk) 21:39, 30 March 2025 (UTC)[reply]
The problem with these terms is that notability here is not the only reason that we would not allow an article on a topic. Much of WP:NOT plays into this, as well as issues around BLP. So anything along the lines of "eligibility" or the like as a simple replacement for notability is not going to work. Masem (t) 22:17, 30 March 2025 (UTC)[reply]
I'm not sure I understand your point. Couldn't you just say "this article is not eligible per WP:NOT" or something like that? The idea is that would be a more accurate representation of our criteria because we have reasons for refusing articles other than just "notability" in the common sense. Mrfoogles (talk) 22:49, 30 March 2025 (UTC)[reply]
First, there is a reason why notability is a guideline and not policy, because it is highly subjective, so trying to place any type of language that suggests that it is a requirement like eligibility is a problem. And notability is a separate test from the content limitations that WP:NOT sets out (which is policy). Trying to treat notability as eligibility or admissibility implies that it is more important than NOT, when it really is the other way around. Masem (t) 00:41, 31 March 2025 (UTC)[reply]
I see your point, but there still are problems with the word "notability", which implies things other than what it actually means. To newcomers and anyone who doesn't understand the jargon, it means "important enough". Mrfoogles (talk) 01:43, 31 March 2025 (UTC)[reply]
We use the term "worthy of note" to indicate if someone is important enforce, which is why we call it notability, the essence that the topic's worthiness has been "noted" or documented in sources. — Masem (t) 02:27, 31 March 2025 (UTC)[reply]
A replacement I've sparsely heard is wikinotability, which might be promising. LightNightLights (talk • contribs) 00:34, 31 March 2025 (UTC)[reply]
Eh, I'd prefer to use an actual word. Besides, "eligible" is more intuitively obvious to newcomers than "wikinotable" Mrfoogles (talk) 00:35, 31 March 2025 (UTC)[reply]
What we are really looking for is “notedness”… ie has the article topic been noted and commented upon by independent reliable sources. That said, “Notability” has been used for so long that I don’t think it is practical to change it at this late date. Blueboar (talk) 01:04, 31 March 2025 (UTC)[reply]
Eligibility makes me think of bachelorhood. BD2412 T 01:16, 31 March 2025 (UTC)[reply]
I'd say there's a bit of sunk cost fallacy in there: while it is certainly less practical to change it now, the cost of keeping our more confusing definition of notability is still something that we're paying, and that we'll be paying in the long term if we never change it. It's never the most practical moment to change important things like this, but having some years of hindsight on how "notability" has been a confusing word makes a change today better in some aspects than a change a decade ago. Chaotic Enby (talk · contribs) 13:01, 31 March 2025 (UTC)[reply]
Actually, this might be a good term, especially if we’re not using eligibility. The change would then be from newcomers saying “This author is definitely notable” to “this author is definitely noted in reliable sources”, of which the second is harder to slip up into arguing based on achievements. “Noted in reliable sources”, or “noted” would replace “notable”. As another advantage we could keep the acronyms starting with N. Mrfoogles (talk) 15:26, 31 March 2025 (UTC)[reply]
Update: I actually got confused. French wikipedia uses "Notoriété" (~=fame) for notability (see https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Notori%C3%A9t%C3%A9), but it calls AFD discussions discussions of "admissibilité". I actually just got confused. Still think it's worth using another word than notability, if maybe not eligibility as notability isn't all of what makes an article eligible per @Masem. Mrfoogles (talk) 01:45, 31 March 2025 (UTC)[reply]
I do think it could also be worth it to have a single word (maybe eligibility) encompassing both notability and WP:NOT. Having them as fully separate concepts means we often fail to see the big picture (say, focus on notability while forgetting WP:NOT). Focusing on a broader issue like eligibility could help us keep this in mind, and match what French Wikipedia does (with "admissibilité" corresponding to whether the article should be kept, rather than just notability). It also frees us from the "what does notability really mean?" question, as WP:GNG addresses the extent of sourcing while some SNGs might ignore it and focus on other aspects. Chaotic Enby (talk · contribs) 12:58, 31 March 2025 (UTC)[reply]
Keeping notability and NOT separate is sorts necessary. Besides guideline versus policy issues (editors get upset if we even breathed mention of notability in policy pages), notability is a positive inclusion metric and meant to apply at the article level, while NOT is a negative metric that applies to both content and article levels. Masem (t) 13:10, 31 March 2025 (UTC)[reply]
I'm not saying they should be merged, but that we should have a concept encompassing both about "whether an article is suitable to be kept". Otherwise, it can get confusing for new editors learning about notability and not necessarily realizing it isn't the only factor in keeping an article. Chaotic Enby (talk · contribs) 13:34, 31 March 2025 (UTC)[reply]
That starts getting into an essay area, since it would be summarizing the steps an editor should review before creating an article. We likely already have that. Masem (t) 13:56, 31 March 2025 (UTC)[reply]
I was skeptical at first (expecting this to WP:SNOWBALL and not really seeing the point), but reading the discussion, especially the idea of a soft transition, I'm kind of sold. Building consensus would be the hardest part, but the discussion so far suggests there's actually a decent chance of it passing. -- Avocado (talk) 17:00, 31 March 2025 (UTC)[reply]
Eligibility is far a better word than notability. I have always thought Notability on Wikipedia and what it means in the real world is confusing. Eligibility - as an old British ad said, does exactly what it says on the tin. We are telling users what is eligible to be in Wikipedia.Davidstewartharvey (talk) 17:13, 31 March 2025 (UTC)[reply]
Still, you could argue WP:NOT can counteract it — e.g. words are covered in multiple dictionaries, but can’t have articles necessarily. But now that I say that, I remember there are encyclopedic articles on some words. Reading WP:NOT again, I wonder if most of the things can’t be described as “these things violate e.g. NPOV”. I think it has to be phrased specifically as what topics are eligible, rather than articles, as we have e.g. outline articles. Mrfoogles (talk) 18:55, 31 March 2025 (UTC)[reply]
Well... Not really? I know where you're coming from, but WP:N already includes WP:NOT. It's right there in the lead (where I put it myself, back in 2010 ;-)):
On Wikipedia, notability is a test used by editors to decide whether a given topic warrants its own article...
A topic is presumed to merit an article if:
  1. It meets either the general notability guideline (GNG) below, or the criteria outlined in a subject-specific notability guideline (SNG); and
  2. It is not excluded under the What Wikipedia is not policy.
The original form of this sentence was focused on the GNG, and it actually used to say "A topic is presumed to be notable..." (I rephrased it, because to avoid getting close to a tautology). The end result, though, is that if the subject is excluded per NOT, then the subject isn't notable.
"Notability" is not the same as WP:General notability guideline. WP:N is the whole ball of wax.
BTW, by way of making that clearer, we recently talked about splitting the GNG section out WP:N, to be its own separate guideline. I think it's a good idea (e.g., clearer distinction between the whole ball of wax and the GNG; perhaps if there's less on the page, some people will read more of it), and I think it would be good to do that soon/first. WhatamIdoing (talk) 22:23, 31 March 2025 (UTC)[reply]
Your linked change changed it from, basically, "a topic is presumed notable if it meets GNG or an SNG" to "a topic merits an article if it's notable (i.e. meets GNG or an SNG) and isn't excluded by NOT". That doesn't read to me as in any way including WP:NOT in WP:N, just cross-referencing that there's something besides WP:N that's needed to have an article. Anomie⚔ 23:09, 31 March 2025 (UTC)[reply]
Let us not focus on the names of specific policies, whether it's WP:N, WP:GNG, or specific SNGs. While I recognize the challenge of changing the naming conventions of multiple Wikipedia project areas, I see this change bringing the most glaring improvements for reviewers and editors alike at WP:AFC and WP:NPP. When reviewers explain to newer editors why their article isn't eligible, using clearer English instead of argumentative/judgmental language like what is notable (wouldn't my dear pet rabbit be notable for the digital encyclopedia?) versus eligible, which makes it clear that there are some policy reasons. The eligible or notable dual-phrase least allows us to use both terms interchangeably and in a transitional way. A decade ago, Wikipedia:Votes for deletion was renamed Wikipedia:Articles for deletion, and this was an improvement, if only semantically but also improved the philosophical approach of the arena. ~ 🦝 Shushugah (he/him • talk) 23:20, 31 March 2025 (UTC)[reply]
Wasn't it two decades ago? jlwoodwa (talk) 02:55, 1 April 2025 (UTC)[reply]
I don’t find t to be a good analogy— in 2005 Wikipedia was still going through growing pains and had a lot of weirdness needing to be ironed out (mixed metaphor, sorry). This feels like one of those tweaks that should have been done back then, but wasn’t. It’s a bit like when Valve realized Scout’s pants were the wrong color in Team Fortress 2 almost 20 years after release and “fixed” them, then realized it was a little too late for last-minute design tweaks. Dronebogus (talk) 17:20, 1 April 2025 (UTC)[reply]
There are several other reasons beyond just NOT (like BLP) that we'd not want an article that appears to meet the GNG or and SNG. Too many to get into within a nutshell sentence. GNG and SNGs can be seen as "necessary but not sufficient" conditions for an article, but even then that could be taken too strongly as the are reasons for standalone articles that do not meet GNG or SNGs. Masem (t) 23:21, 31 March 2025 (UTC)[reply]
Ok, so I think "eligibility" has some support. But how exactly should we do the transitional period? I think only 2 stages -- transitional and full adoption -- is probably best to minimize complexity. But if we change WP:N to "Eligibility, or notability", what should the full article use? I'd say eligibility, but I'm not sure what could get consensus. That said, a possible RFC could just offer a few options for how the transitional period would go, but it's obviously better to have the best option as fully displayed as possible. Mrfoogles (talk) 00:03, 1 April 2025 (UTC)[reply]
"Eligibility" also has some reasonable objection, expressed by Masem above. Let's not succumb to the politician's fallacy here; just because "notability" is problematic in some ways doesn't mean we have to switch to something else that will be problematic in different ways. Anomie⚔ 11:38, 1 April 2025 (UTC)[reply]
I still don’t get what policies Masem is pointing to, though — WP:NOT is a separate thing from notability, but it mostly describes ways in which articles should not be written and some specific non-notable things. They’ve mentioned some other reasons, but haven’t specified them. Personally, I think that if a topic is covered significantly in multiple reliable sources, there’s probably no reason there can’t be an article on it. The other option is “notedness”, true, but I don’t think it has the effectiveness of “eligibility”, and I’m not sure it’s worth making such a relatively small change in wording. Mrfoogles (talk) 14:56, 1 April 2025 (UTC)[reply]
Concur that this is a fundamentally trivial change that would create disproportionate amounts of work. Dronebogus (talk) 17:21, 1 April 2025 (UTC)[reply]
I disagree. "Eligibility", to me, is significantly clearer to those who aren't steeped in Wikipedia lore and memes than "notability" is, since the definition we use for that term is, to some degree, at loggerheads with how everyone else on the planet interprets it. Any effort to make our somewhat byzantine inclusion guidelines more understandable is inherently worth whatever work we have to put in for it. —Jéské Couriano v^_^v threads critiques 17:27, 1 April 2025 (UTC)[reply]
You are going to have a huge raft of the so called inclusionists take issue with using "eligibility" since that makes it sound more policy-like.
The essence that is at the heart of what we call notability is a necessary but not sufficient condition to have a stand alone article on a topic. The article must still meet all other content policies (V, NOT, NPOV, NOR, and BLP), so it is not the sole defining reason to make a stand alone. That's why terms like eligibility are bad because that implies that it is a one stop shop for determining the appropriateness for a standalone. Masem (t) 17:46, 1 April 2025 (UTC)[reply]
Then what term would you prefer, given that "notability" inherently causes confusion that a more direct term such as "eligibility" or "suitability" would not? —Jéské Couriano v^_^v threads critiques 17:49, 1 April 2025 (UTC)[reply]
Yes, both terms suggest it is a more black or white test a article must pass, which isn't true at all for notability works on WP. You are trading one type of confusion foranother Masem (t) 18:46, 1 April 2025 (UTC)[reply]
It’s true the article needs to meet those criteria, but the usual response at AFD to those who say the article doesn’t meet NOR or NPOV is to fix the issues — as long as the topic is notable issues with the article don’t warrant deletion. “Eligibility” would apply to topics, not the actual article text, just as “notability” does. Mrfoogles (talk) 17:50, 1 April 2025 (UTC)[reply]
I'm an inclusionist*. We don't oppose WP:N. (At most I just oppose the routine coverage standard, but there is absolutely no issue with actually sounding like a Wikipedia thing.) Aaron Liu (talk) 17:59, 1 April 2025 (UTC)[reply]
  • The reason this has been suggested multiple times is because most people aren't willing to commit large amounts of time and effort into changes that are mainly cosmetic. WP:N exists so that people who are confused can read the guidance there. WP has a few unfortunate barriers to entry, but semantics isn't really high on the list. If people can't get a warm and fuzzy for N, then they're doomed when The Wikipedia and Associates Law Firm comes out of the woodwork and starts quoting 5,000 different SNGs. GMGtalk 18:07, 1 April 2025 (UTC)[reply]
    Semantics ain't just cosmetic. Just the avoidance of "what do you mean they's not notable they're on Netflix and is child to Celeb McFameyFace" for the billionth time would be worth it. It's one of the most common discussions from newbies on Wikipedia and calling it "eligibility" would incentivize reading the criteria way more. Aaron Liu (talk) 18:22, 1 April 2025 (UTC)[reply]
    Or at the very least cutting down on the confusion between two different definitions for the same word. "Eligibility" as a term wouldn't be dissimilar to how it's used outside of Wikipedia, in sharp contrast to "notability". —Jéské Couriano v^_^v threads critiques 18:33, 1 April 2025 (UTC)[reply]
    Exactly. Notability of a celebrity in the real world relates to how famous they are, while here it means do we have enough independent third party references. If the world Eligibility is used, it means the same here as it does in the world outside of Wikiworld. Davidstewartharvey (talk) 18:45, 1 April 2025 (UTC)[reply]
    That's not how it would work. Assuming we are talking a one for one replacement, the way the notability guidelines work would not change, which is where the bulk of the confusion comes from, not because we use a word in a different meaning on WP than in normal English. The GNG and SNG and not eligibility criteria by any means. Masem (t) 19:01, 1 April 2025 (UTC)[reply]
    I'm not convinced. Pretty much all confusion I've seen is from equating it to fame. Aaron Liu (talk) 19:06, 1 April 2025 (UTC)[reply]
    That is one point of confusion but the bulk I've seen is in the implementation. And I stress again that the practice of the GNG and SNGs do not work like the word eligibility implies, so even if confusion was limited to just the use of "notability", you'd be trading one problem for another.
    Trying to rename notability is a PEREN type problem. We know the word creates confusion but there is no other simple replacement that would not also create additional confusion. And because notability has been around that long, retaining that term is the path of least disruption in trying to balance other posdible terms. Masem (t) 19:21, 1 April 2025 (UTC)[reply]
    Masem, I respectfully disagree. We've had literally countless examples of new/unfamiliar users arguing a subject is notable for reasons which make no sense if you're not applying the non-Wikipedia sense of the word, such as being associated with a notable entity, being someone who works in social justice matters, or being a local celebrity. "Eligibility" or something similar would cut almost all of that out, because the sense in which we would use it would hew much closer to how it's used outside of Wikipedia, eliminating a tonne of confusion in the process. This isn't a Musk-like "Move fast and break shit" matter, especially if we gradually phase it in over a course of months (as people have been suggesting) to get established users used to the term and to slowly bring the guidelines around to using the new term. —Jéské Couriano v^_^v threads critiques 21:10, 1 April 2025 (UTC)[reply]
    A big problem with eligibility is the aspect that notability is a rebuttable presumption. We use the language "presumed notable" frequently in the GNG and SNG pages because we generally give a benefit of doubt to allow standalone articles to be created with a minimal showing of notability, but that presumption can always be challenged if additional sources do not emerge in the future. So by using a term that has no black or white mean but implies levels and degrees of notability, it fits with the presumption and need to improve. "igibility" is a black or white term, and does not suggest this, and language like "presumed eligible" makes zero sense in that context. Masem (t) 21:47, 1 April 2025 (UTC)[reply]
    I think if you define "eligible" as "possible to write an article following policy (e.g. NOR, NPOV, V, etc.)", than "presumed eligible" makes a lot of sense. Mrfoogles (talk) 21:49, 1 April 2025 (UTC)[reply]
    But that is changing what purpose notability currently serves, which is an extra step beyond the bounds set by the content policies. And dealing with how that propagate into the SNGs would be very messy.
    Again, trying to rename notability with s an effective PEREN problem for at least a decade but no word has ever been proposed that serves as a drop in replacement that would create problems elsewhere. Masem (t) 22:06, 1 April 2025 (UTC)[reply]
    I would define it as "Has enough sources to support a robust encyclopaedia article on the topic". That's basically what reviewers and those at help fora are looking at in the first place, with other matters only addressed alongside or after determining if the sourcing is okay. —Jéské Couriano v^_^v threads critiques 22:14, 1 April 2025 (UTC)[reply]
    I agree with Masem that "notability" is (probably) not the best word we could use, but on balance "eligibility" is not an improvement. Thryduulf (talk) 23:14, 1 April 2025 (UTC)[reply]
    Then what term would you suggest, Thryduulf? —Jéské Couriano v^_^v threads critiques 00:23, 2 April 2025 (UTC)[reply]
    I don't know, but that's part of the point - if nobody in two decades has come up with something better than "notability" it's ridiculous to assume that an individual can in the space of a couple of days. They might, but not doing so is not a barrier to having or expressing the opinion that any given suggestion is not an improvement on the status quo. Thryduulf (talk) 00:39, 2 April 2025 (UTC)[reply]
    I mean, yes... semantics in this instance is in the pejorative sense, of changing wording without changing meaning. You can rearrange the furniture all you like, but it will still have a specific technical meaning in the context of Wikipedia that even old farts like me don't fully agree on even after years of arguing about it. GMGtalk 19:35, 1 April 2025 (UTC)[reply]
    Thats why eligibility is a better word. We have rules that make an article eligible to be on the site. Notability does not say this. Davidstewartharvey (talk) 19:56, 1 April 2025 (UTC)[reply]
Asking again because the discussion got a bit sidetracked —- what do people think about this transition method?
I figure three months is about the ideal length for a transition period. In the first month, the use of either would be allowed in policy and debate, and policies would be updated to mention it as an alternative term. In the second month, policies would use eligibility, and notability would be mentioned once as an alternative term; use of either would be allowed. In the third month, notability would be referred to as a former term; use of eligibility would be recommended. Mrfoogles (talk) 21:23, 1 April 2025 (UTC)[reply]
Three months sounds ideal, but if people feel it's too short, I'll offer up six months as a counter-proposal for the transition period. —Jéské Couriano v^_^v threads critiques 21:38, 1 April 2025 (UTC)[reply]
I suspect that a LOT of editors will never hear about the suggested change… so they will continue to use and link to the term they have gotten used to (Notability).
More importantly, when (after the fact) they discover that it has changed, they will begin to clamor to change it back. And so … I think changing it will be disruptive, and thus cause even more confusion than exists now. Blueboar (talk) 21:40, 1 April 2025 (UTC)[reply]
We would of course need an RfC (with some sort of banner at Notability) which would notify a lot of people. I also find it implausible that editors would not see others saying "eligibility" in the three months 'tween. Aaron Liu (talk) 21:45, 1 April 2025 (UTC)[reply]
And keep in mind we just had a central discussion on the posdible renaming of notability in the last six months. Yet another RFC this soon is not likely to be seen as helpful. Masem (t) 21:48, 1 April 2025 (UTC)[reply]
Do you have a link? I didn't see that one. Mrfoogles (talk) 21:49, 1 April 2025 (UTC)[reply]
I think he might be referring to Wikipedia:Village pump (idea lab)/Archive 61#Describing Notability in plain English. jlwoodwa (talk) 22:01, 1 April 2025 (UTC)[reply]
Looking at that, it doesn't seem like that came anywhere close to any sort of consensus. —Jéské Couriano v^_^v threads critiques 22:09, 1 April 2025 (UTC)[reply]
If that's the one meant, then I don't think an RFC would be inappropriate -- there's supposed to be discussion before an RFC. Mrfoogles (talk) 22:49, 1 April 2025 (UTC)[reply]
Alright, I'm thinking about opening an RFC on whether we should use "eligibility" for topics rather than "notability" for topics, with a three-month transition period as described above -- the first month policy pages will mention it as an alternative, the second they will use it primarily, and the third month notability will be described as a "former" term and the use of "eligibility" will be recommended, rather than both being allowed as in the first two months. Anyone have anything that they think should be changed before the RFC opens, or comments? Mrfoogles (talk) 22:54, 1 April 2025 (UTC)[reply]
Just let me know when it goes live. Blueboar (talk) 00:21, 2 April 2025 (UTC)[reply]
I think it’s a waste of time. It probably won’t pass just because of user conservatism, and it shouldn’t pass because it’s unhelpful busywork a la the law of triviality. I’m all for sanding down the learning curve for new editors, but this isn’t something that needs to be sanded. People aren’t that clueless— they pick up new jargon all the time. This is barely even jargon. Dronebogus (talk) 00:35, 2 April 2025 (UTC)[reply]
It's also about significantly reducing the newbie first impressions of "what do you mean up for deletion he's FAMOUS". Aaron Liu (talk) 00:53, 2 April 2025 (UTC)[reply]
I've said this before, but if we are simply talking about a word replacement, even assuring all P&G updated to reflect that word change, you still would have confusion on the practice of how notability / eligibility is used (questions about what "significant coverage" is a constant matter for example), and you will create confusion in areas that were not previously areas of confusion, such as when we have talked of notability being a rebuttable presumption as well as having level or degrees by which a topic could be notable, which "eligibility" does not imply.
I will also express the concern that based on this discussion and past RFCs that yet another RFC is going to be a waste of time. Masem (t) 12:25, 2 April 2025 (UTC)[reply]
Nobody claimed that this would solve all the problems, just the biggest, extremely common, and very repetitive one.

such as when we have talked of notability being a rebuttable presumption as well as having level or degrees by which a topic could be notable, which "eligibility" does not imply.

Where is the confusion? "Eligibility is presumed but rebuttable", "this is very eligible", "this has borderline eligibility".
Could you link the RfC? Aaron Liu (talk) 13:48, 2 April 2025 (UTC)[reply]
Eligibility is a black or white term, you are either eligible or not. But notability in practice has multiple levels, and even the real world meaning of notability implies that it's a range of quality and not back or white. You would be removing one part of confusion but replacing it with others. Masem (t) 14:07, 2 April 2025 (UTC)[reply]
"Notable" is no less black and white than "suitable". Aaron Liu (talk) 14:24, 2 April 2025 (UTC)[reply]
Words like eligible or suitable all imply a single test or gate to pass, you either are or you are not eligible. With notable, at least, that has degrees, we routinely say in normal language about a person being barely, somewhat, or highly notable (in it's normal meaning, not WP meaning), but applying that same approach to eligible or suitable is odd, eg "somewhat eligible" makes no sense. Masem (t) 14:47, 2 April 2025 (UTC)[reply]
Again I agree with Masem here. "Borderline eligible" implies to me that there is a hard line and either it is unclear which side of that line you are on or you are clearly right up against the line (probably more often not quite over it, but just over it is also possible). "Borderline notable" implies that you are in the fuzzy area where you are sort of notable and sort of not notable. Thryduulf (talk) 14:52, 2 April 2025 (UTC)[reply]
A distinction without a difference. In practice there is a hard line, thanks mainly to improved enforcement of our P&Gs. And nothing about "eligible" would stop there being multiple levels as there is now; the phraseology would just be "eligible under <foo>". Just like in the real world, eligibility isn't always just based off of one criterion; there can still be multiple ways to be so. —Jéské Couriano v^_^v threads critiques 16:57, 2 April 2025 (UTC)[reply]
This issues isn't about there being multiple routes to notability, but that there is a continuum of how well a topic has shown its notability (eg we speak if topics barely passing the GNG and thus needing improvement). While there may be multiple ways you can reach something with eligibility, it still implies that you either are or are not eligible with no middle ground. But notability does not work on a black or white concept like that, so eligibility simply does not work. Masem (t) 17:12, 2 April 2025 (UTC)[reply]
I have nothing to say except "suitability" is also clearly a spectrum. Aaron Liu (talk) 11:28, 3 April 2025 (UTC)[reply]
The thing is, it would benefit from being sanded, because it's almost a trope at AFD that people misinterpret notability in this exact way. So I think it would be worth it as eligibility or suitability or something, maybe the 2nd one. Eventually they pick it up, but there's a continuous stream of people who misunderstand, is the problem. Not that it's the most crucial thing, but it's not that much effort, either. Mrfoogles (talk) 01:03, 2 April 2025 (UTC)[reply]
I agree with that. While there are many hurdles to making Wikipedia more accessible to new editors, all of them could be said to individually be "trivial" compared to the rest, but removing hurdles one by one still helps. Chaotic Enby (talk · contribs) 12:07, 2 April 2025 (UTC)[reply]
RfC open at Wikipedia_talk:Notability#RfC on change of name Mrfoogles (talk) 18:51, 4 April 2025 (UTC)[reply]
So if we look at the definition of the words being argued and see what actually matches what we mean:

Notability - important and deserving attention, because of being very good or interesting. Eligibility - the fact of having the necessary qualities or satisfying the necessary conditions Suitability - the fact of being acceptable or right for something or someone Admissibility - the fact of being considered satisfactory and acceptable in a law court To me the only one that meets what we use it for is Eligibility, as we have rules why articles are allowed on Wikipedia, as WP:N is just that, as is WP:NOT, GNG and SNG too.Davidstewartharvey (talk) 16:57, 2 April 2025 (UTC)[reply]

I’m actually leaning a bit towards “suitable” as in “suitable topic”, because while still implying that the criteria are specific to wikipedia (suitable for what?), it also helps capture the idea that it’s fuzzy rather than a strict set of criteria, as argued above. Plus it sounds similar. Mrfoogles (talk) 18:58, 2 April 2025 (UTC)[reply]
  • Support I've been spending time at In the News lately. There are regular discussions there about whether topics should be posted. In those discussions, editors often use the words "notable" or "notability" to mean importance or significance. They are not referring to the level of coverage in reliable sources and, if you mention that, some editors that ITN doesn't care about the level of coverage in the news media. So, in the context "notability" can mean the opposite of what is meant elsewhere.
Note also that WP:N is not a policy; it's just a guideline. Editors who regard it as a core policy are quite mistaken. It is therefore not fundamental and so open to adjustment. Amending the language would be a good way of getting everyone to understand it better.
Andrew🐉(talk) 20:00, 2 April 2025 (UTC)[reply]
None of the new three terms describe how notability is used in practice, going off those definitions. Notability is not a bright line test as those terms suggest. Masem (t) 20:31, 2 April 2025 (UTC)[reply]

I think that it would be good to change to "suitability" or "eligibility" and it would more accurate. It still doesn't acknowledge how WP:notability actually works . Besides being a set of guidelines, or the criteria which the guidelines are "getting at" (which are never agreed on) it's actually the name for the suitability decision-making process, which is based on the notability guideline criteria as well as the degree of enclyclopedicness and secondarily on the degree of importance/impact/recognition. BTW the SNG's also incorporate the latter criteria, even though they generally claim to be just about prediction of existence of GNG sources. Here's an idea that would be a baby step towards the ideas in this thread, avoid immediately taking on the overwhelming hugeness a full change (which would probably doom a proposed immediate huge change) Pick one of the proposed words, introduce it in the lead of the top level wp:Notability guideline, and say that wp:notability is a synonym for it. That would be a do-able baby step 1 for resolving and clarifying many things. North8000 (talk) 20:31, 2 April 2025 (UTC)[reply]

Agree that it could be a good first step in a soft transition. While I do believe that it's best to have the roadmap laid out, making it an "accepted" synonym is also a good first step, and could be a helpful way to clarify the situation to newcomers going "but it's notable!" (replying with something like "what we mean by notability is actually suitability/eligibility for a Wikipedia article"). Chaotic Enby (talk · contribs) 20:54, 2 April 2025 (UTC)[reply]

"Notability" on Wikipedia has a very specific meaning, perhaps not related to the word's meaning in the outside world. If we want to fix that, we should not use any other pre-existing word, but just invent our own word that means exactly what WP:N means. That would not change the fact that our jargon is pretty much incomprehensible to normal people, but at least it would be clear that people have to learn our jargon to participate in debate here. —Kusma (talk) 21:15, 2 April 2025 (UTC)[reply]

That's basically what using "suitability" or "eligibility" does -- it naturally sparks the question "suitable for what?" or "eligible for what?", which makes people learn what the criteria actually are. Mrfoogles (talk) 23:59, 2 April 2025 (UTC)[reply]
How about Wp:Eligible and Suitable? We keep saying one word but would it be better as two? Davidstewartharvey (talk) 05:22, 3 April 2025 (UTC)[reply]
Two words for the same thing? Mrfoogles (talk) 05:54, 3 April 2025 (UTC)[reply]
That makes it sound like two things. Aaron Liu (talk) 11:29, 3 April 2025 (UTC)[reply]
I said this imm above: people learn new jargon all the time. Notability has a highly specialized and technical sense of its definition on Wikipedia, but it’s still basically the standard definition. Compare that to the jargon used in many popular video games, which is usually either complete gibberish or a completely new definition of a given word that is sometimes the exact opposite of what it usually means— i.e. “mob” for a single creature in Minecraft. Dronebogus (talk) 05:31, 4 April 2025 (UTC)[reply]
"Notability" (it has lotsa specific kinds of coverage) has as much relation to the actual thing as "mob" in Minecraft (they're mobile objects that gang up on you) Aaron Liu (talk) 11:36, 4 April 2025 (UTC)[reply]

"Eligibility" is probably more accurate but sounds a bit pompous / high-handed. Maybe "suitability" is a better choice. For my do-able baby step idea above, it could be to add the following to the first paragraph of wp:notability: ""Suitability" is an alternate term for "Notability", meaning suitability to have a separate article on the topic". North8000 (talk) 18:51, 3 April 2025 (UTC)[reply]

Even with the above, any of the above terms gives the impression that this is the only step you need to pass to have a standalone article, which is of course wrong, and perhaps that's also a fundamental fallacy when trying to see how to rename it. Notability is one step, a significant one but not the only one, and notability is not always required for a standalone article (hence why it remains a guideline). Knowing how notability works, I would infer that that page would be more like a checklist for determining if a topic is suitable for a standalone article, which would include evaluating notability, making sure it doesn't fail NOT, meets the other content policies, and isn't going to be stubby and not better covered in a more comprehensive article. Otherwise we are going to again create a problem of using a real world term to mean something different, eg we may be telling people that their topic may be "suitable" (placeholder for notability) for an article but really it's not due to something like being a BLP violation. It's trading one problem for at least one new problem. Masem (t) 19:10, 3 April 2025 (UTC)[reply]
That is a far better confusion than "Notable articles are generally included and the subject is famous!". Newbies are far more likely to check out what Suitability means (as opposed to e.g. assuming WP:N is just a list of criteria for possible ways to evaluate fame) and see the fairly big numbered list in WP:N's lede that cites WP:Not and WP:Merge, furthermore. (Also, I struggle to see anything meeting WP:N and being a BLP violation.) Aaron Liu (talk) 19:36, 3 April 2025 (UTC)[reply]
BLP-violating articles on notable subjects are quite easy to write. jlwoodwa (talk) 19:53, 3 April 2025 (UTC)[reply]
BLP is an article content issue rather than a question of whether a seperate article on the topic should existNorth8000 (talk) 19:57, 3 April 2025 (UTC)[reply]
No, BLP can apply to article level stuff, notably BLP1E and BLPCRIME. And if a BLP is written only using weakly reliable sources and appears to be problematic, that's another reason to remove said article. Masem (t) 22:30, 3 April 2025 (UTC)[reply]
I do not see anything with suitability that would imply that the speedy deletion criteria would not apply. That the article content for a topic is bad does not alone mean a topic is not suitable for an article when it meets GNG. Aaron Liu (talk) 23:51, 3 April 2025 (UTC)[reply]
Not all BLP-violating articles easily meet the speedy deletion criterion, and may require longer-term processes to evaluate; a good example was the article for Brian Thompson, the health insurance CEO that was killed recently. That went through a length AFD process but was deleted on BLP1E terms, even though one could argue he met the GNG, just barely. Masem (t) 00:07, 4 April 2025 (UTC)[reply]
That seems to be a specific set of cases supplemental to Sustained that is common enough to warrant its own section on another page combined with WP:Not. Aaron Liu (talk) 00:47, 4 April 2025 (UTC)[reply]
Doesn't mean such articles should be deleted. Aaron Liu (talk) 21:18, 3 April 2025 (UTC)[reply]
Masem's idea of a separate meta suitability page covering: "is this topic suitable to have a seperate article?" is a framework for total solution. A mini version of this is confusingly placed in the lead of wp:notability where it says that an article must also comply with wp:not. North8000 (talk) 20:03, 3 April 2025 (UTC)[reply]
I'm a bit confused about the specifics of this idea, as I thought Masem disagreed with a similar proposal above – is there some nuance to it that I'm missing? Chaotic Enby (talk · contribs) 20:19, 3 April 2025 (UTC)[reply]
Didn't disagree with it, just that either we I feel we already have such a page and if not then this would make for a great essay that potentially can be made into a guideline. Masem (t) 22:31, 3 April 2025 (UTC)[reply]
Thanks for the clarification! Chaotic Enby (talk · contribs) 11:32, 4 April 2025 (UTC)[reply]

Site-wide assessment page

How about having a site-wide assessment page with tables and a request section. It would use the current Wikiproject banner shell class parameter. WikiProjects would still be able to have their own assessments because they can use the class parameter in their own banner (for an example of this check out WP:WikiProject Military history/Assessment#Instructions). That way it would fix the issue of deciding which projects assessment tables to use for the main banner, and would also remove a lot of traffic on Wikipedia:WikiProject_Wikipedia/Assessment as currently everyone is going there to get articles assessed and technically they are only supposed to do the ones within their scope as outlined in WP:WikiProject Wikipedia. The ground work is already set from what I can see for a site-wide assessment page, we just need to work out the finer details. Such as what should the criteria be, what the title should be, where it should be located and other such stuff.

Anyways I would like to hear what everyone thinks of this and if there is anything that we need to work out first before I propose it. Sheriff U3 03:09, 30 March 2025 (UTC)[reply]

For context there was some discussion on this earlier today. I also think this would be nice. Currently this work is done on the scale of individual WikiProjects (except for WikiProject Wikipedia which, for reasons, has accidentally shouldered the burden of doing this for the whole encyclopedia) but it'd get a lot more attention on the issue of unassessed or under-assessed articles to have one centralized place for people to request re-assessments if they want a second perspective. A few ways I could imagine this being done:
  • An extension to WP:Peer Review which in practice focuses more on prospective GA and FA nominations, rather than lower classes of articles
  • Some sort of WikiProject on the subject of assessment itself
  • A maintenance page that aggregates the assessment pages of multiple WikiProjects
Viv Desjardin (talk) 03:44, 30 March 2025 (UTC)[reply]
Article assessments are already site-wide. The WikiProject banner shell holds this site-wide assessment. Any user, a member of a WikiProject or not, can re-assess any article for anything B-class or below. Members of WikiProject Wikipedia are thus as able to carry out assessments as anyone else. In general, WikiProject-specific assessments are deprecated, following WP:PIQA, although even this only formalised what was already practice. CMD (talk) 06:15, 30 March 2025 (UTC)[reply]
This suggestion isn't about establishing a site-wide system for assessments, which as you mentioned is already a thing; the suggestion is to create a place on Wikipedia where people can request (re)assessments where the scope is the whole encyclopedia (e.g. anyone can file a request for an article on any topic).
At the moment there's lots of topic-specific pages where you can request re-assessments, like Wikipedia:WikiProject Military history/Assessment#Requests for military history articles, but there isn't really a place like that with a broad scope. Viv Desjardin (talk) 06:22, 30 March 2025 (UTC)[reply]
That isn't clear to me from the proposal. For example, "That way it would fix the issue of deciding which projects assessment tables to use for the main banner" is describing an issue that does not happen under WP:PIQA. I also see that Wikipedia:Content assessment does say that Wikipedia:WikiProject Wikipedia/Assessment#Requesting an assessment is the place to go, so the situation seems more formal than the opening suggests it is. CMD (talk) 06:54, 30 March 2025 (UTC)[reply]
My earlier message was based on a prior discussion Sheriff U3 and I had on the topic though I might have misunderstood the proposal as they've written it here.
The issue with WikiProject Wikipedia is that, according to it: This department focuses on assessing the quality of Wikipedia-related articles (for scope, see the WikiProject page). It seems like the link to it was added by mistake, and everyone's gone along with it. We could keep it the way it is, since it's been that way for about a year and a half now but if this is something WikiProject Wikipedia explicitly wants to handle then it'd be good to clarify this at least. Viv Desjardin (talk) 14:27, 30 March 2025 (UTC)[reply]
I would suggest moving it to somewhere like Wikipedia:Content assessment/Requests. It would be great to continue the service that WikiProject Wikipedia has been offering, but put it somewhere more appropriate. — Martin (MSGJ · talk) 18:46, 30 March 2025 (UTC)[reply]
I think a good option might be to put it as a task force in WikiProject Peer Review -- just wherever gets it the most eyes. The biggest problem with the WP:Wikipedia section, as someone who's messed around with it a bit, is that there are so few people who review it. It's a huge issue when someone just nominates 20 articles. That said, having its own place at "Content assessment/Requests" does seem like sort of the most obvious place to put it.
What about some sort of template? E.g. you tag your article (the main page, not the talk, for visibility) {{Assessment requested}} and then someone comes by, rates it, and maybe gives you some advice. I'm not sure if we should mandate that some advice be given -- i.e. leave a rationale in the edit summary -- but I feel like the advice is the main benefit of having someone else rate your article. It doesn't matter whether every article is assessed correctly, but it does matter that people who write articles have an accurate understanding of how good their article is and how to improve it.
Then there could be a category, e.g. [[Category:Articles assessment requests]], and Content assessment/Requests could be a sort of tiny project (something you can sign up for) for reviewing them. Mrfoogles (talk) 21:06, 30 March 2025 (UTC)[reply]
I like this idea. On expecting advice being given, one approach could be to have a template parameter that adds a message saying something like "An editor has requested specific feedback on this article's assessment. Please share your rationale for any new assessments on this article's Talk Page", which links to a particular section. So, if people don't really care and just want a second opinion, they can leave it off, and people who want some specific feedback know where to find it. This would be similar to a pattern lots of templates have, inviting discussion in the talk page.
I do think that in general the kind of person who'd want to specifically respond to re-assessment requests would also be open to sharing specific feedback. Lots of the feedback would likely be fairly standard (e.g. people who took an article from Stub- to Start-class), but it'd be easy to prepare templates for things like that Viv Desjardin (talk) 21:48, 30 March 2025 (UTC)[reply]
Personally, I mostly leave my feedback on the requests page where people add a request, as part of the reply where you mark it as done, rather than on the talk. That seems like significantly more work, to be honest, although it might be a good idea. Mrfoogles (talk) 22:00, 30 March 2025 (UTC)[reply]
I agree if there's somewhere we're expecting people to explicitly go to submit requests then that'd probably be the best place to leave feedback, since there's more of an expectation that they'll be returning to it. Though this sort of thing would more generally be good to keep in the talk page's history it'd get pretty tedious Viv Desjardin (talk) 22:53, 30 March 2025 (UTC)[reply]
I agree. A quick reply is fine on the requests page. But any extended discussion should be on the article's talk page where other editors will be able to see it easily. — Martin (MSGJ · talk) 11:28, 31 March 2025 (UTC)[reply]
I also like this idea, although I would prefer it be on the talk page. (This is an editing issue not sometime we need to bother the reader with.) Alternatively we can maybe code up something like this when a particular word is used in the class parameter, e.g. |class=requested — Martin (MSGJ · talk) 11:31, 31 March 2025 (UTC)[reply]
I think that the parameter would work. It would eliminate the need for a requests page. We would still need a page to tell people how to request and how to review the requests. We also could try this on a smaller scale first to see if it would work. (Maybe a WikiProject would be willing to test out the idea.) Sheriff U3 22:16, 1 April 2025 (UTC)[reply]
Not exactly related, but I had previously suggested that a parameter for assessment date be included in the shell. This could be useful in identifying stale assessments. —CX Zoom[he/him] (let's talk • {C•X}) 23:31, 1 April 2025 (UTC)[reply]
Since the banner shell includes wikiprojects you'd think it'd be easy to then use it to identify articles requiring assessment by topic. I say that having never built on MediaWiki but it'd be a lot more seamless than having people track down individual wikiprojects for assessment requests. Viv Desjardin (talk, contrib) 23:43, 1 April 2025 (UTC)[reply]
Given there are categories for articles by class and wikiproject (placed on the talk pages), this would just become another one of those. Skarmory (talk • contribs) 10:19, 3 April 2025 (UTC)[reply]
Greetings, Lately I've been active with Category:Unassessed articles and discovered that blanking the class parameter like WikiProject banner shell|class=|, causes an "automatic" assessment request. I have no idea how to document/promote (maybe Signpost?) so I'm just adding my two-cents here. Cheers, JoeNMLC (talk) 13:29, 7 April 2025 (UTC)[reply]
Where does it send the "automatic" request? Think that.will use it for if I ever need someone else to review an article. Definitely should be advertised at the Signpost. I think that I will check if the same can be done with project importance ratings. Thanks for noticing that, never knew it would do that. Sheriff U3 14:02, 7 April 2025 (UTC)[reply]
@Sheriff_U3 - when class is blanked, the article is added into whatever categories for the talk page WikiProjects. For example: "Unassessed biography articles"; "Unassessed basketball articles", etc. At Category:Unassessed articles there are over 600 pageviews the past month, so a good amount of visibility. JoeNMLC (talk) 14:20, 7 April 2025 (UTC)[reply]
Ok I see, yes that would be like a assessment request. Sheriff U3 14:26, 7 April 2025 (UTC)[reply]
As a follow-up to above idea of blanking WikiProject "Class" to request an article assessment, I added that info at WikiProject_Wikipedia/Assessment#Assessment_requests. If any clarification or changes needed there, feel free to update. Cheers, JoeNMLC (talk) 14:37, 11 April 2025 (UTC)[reply]

A bot that gathers references cited in AfDs

Many AfD discussions contain references to useful sources which people often don't get around to adding to the actual article if it is kept.

The proposal is to have a bot that extracts all the references cited in the AfD discussion and automatically adds them to the article Talk page if it is kept. It would make it easier for people to at least see the bare URLs for any online sources and work out whether they should be cited within the article or not. At the moment, you have to be willing to find the closed AfD template and click on individual links, one by one, often without really knowing what you are clicking on.

An alternative would be for the bot to simply copy the AfD comments that contain article links and paste them in to the Talk page as a reference (so that the context remains somewhat intact). Cielquiparle (talk) 19:23, 30 March 2025 (UTC)[reply]

I really like the idea, if it can be made to work. Blueboar (talk) 19:47, 30 March 2025 (UTC)[reply]
This sounds like a very good idea. I'm not a programmer by any stretch of the imagination, but it doesn't sound like it would be difficult to implement. If page exists as something other than a redirect after an AfD is closed, copy a list of all external links to (non-WMF sites) to a new section on the talk page that also includes a link to the AfD. Ideally formatted with the metadata but that is not essential. Bots that generate lists are pretty much always uncontroversial and I think the worst thing this bot could do is duplicate sources already added to the article, but that's not really a problem, so unless there is some significant opposition I'd say go ahead and start writing the bot (you will need to get approval at WP:BRFA before operating it) or make a request at WP:BOTREQ. Thryduulf (talk) 20:06, 30 March 2025 (UTC)[reply]
Maybe it would even be possible for the bot to put them into a Refideas template. Although that may get too complicated to be worth it. Donald Albury 20:25, 30 March 2025 (UTC)[reply]
I like this idea. I think a good algorithm would be to have a bot or user script scrape the AFD page for external links, then add all those external links to a refideas template. This would contain the links in a nice spot, stripping away the commentary they are attached to. –Novem Linguae (talk) 09:25, 3 April 2025 (UTC)[reply]
I don't think the comments should be copied, but it does seem like a good idea to have a bot copy all urls in the AFD to the talk. Although obviously some of them will end up being unreliable references, and what do you do if there are e.g. 100 urls? People tend to list many URLs of unreliable sources in attempts to show notability. Mrfoogles (talk) 21:09, 30 March 2025 (UTC)[reply]
Are there many examples of AfDs that get multiple tens of unreliable sources listed and which are kept? Thryduulf (talk) 21:42, 30 March 2025 (UTC)[reply]
I think it happens, but I don't think it's common. Gråbergs Gråa Sång (talk) 04:52, 31 March 2025 (UTC)[reply]
I wonder what motivated this suggestion. I sometimes encounter a deletion nomination that feels a bit like this:
  • A: I'm soooo sad to be nominating this article for deletion. If someone would just please, please, please show me the sources, I wouldn't have been forced to send this to AFD, practically against my will!
  • B: Okay, here are nicely formatted citations for two books and four academic articles entirely about this exact subject. You could just copy and paste the citations into the article.
  • A: [total silence]
But more often I see sources that are not so relevant or so useful. As a result, I'm not certain that setting up a bot like this would actually produce useful information. WhatamIdoing (talk) 06:08, 31 March 2025 (UTC)[reply]
Perhaps rather than a full-on automated bot, it would be better to have a tool that can be used by the AfD closer at their discretion, to extract references and put them on the talk page. Closers could be encouraged to use the tool when appropriate, and to prune out references that the AfD discussion has identified as poor. Elemimele (talk) 13:16, 1 April 2025 (UTC)[reply]
Oooooooooooooh. Like the sound of that. @The wub One for Team WMF? Cielquiparle (talk) 13:25, 1 April 2025 (UTC)[reply]
@Cielquiparle It's a fine idea, but feels a bit too specialised for WMF developers. A volunteer familiar with the process could probably create it more easily. Perhaps it could be an addition to the existing XFDcloser script. @Novem Linguae, any thoughts?
This conversation also makes me wonder: @Cyberpower678 and Harej, I know the Internet Archive proactively saves snapshots of URLs added to articles. Do you know if they do this for Talk and/or project pages too? It might be useful to save such potential references from link rot. the wub "?!" 00:20, 3 April 2025 (UTC)[reply]
XFDcloser is currently unmaintained. I only have time to do unbreak now tickets. Above I mention that a good algorithm would be to have a bot or user script scrape the AFD page for external links, then add all those external links to a refideas template. Something like that is actionable now if someone wants to post it at WP:US/R or WP:BOTREQ. The difference between a bot or user script is that a bot would always check every AFD and run automatically, whereas a user script would need to be manually triggered. Also, a bot would probably need more maintenance since Toolforge is a headache, goes down sometimes, etc. –Novem Linguae (talk) 09:27, 3 April 2025 (UTC)[reply]

Overturning NCCAPS

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

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

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

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

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

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

I see absolutely no justification for capitalisation to differ from other aspects of naming. It's not surprising that the discussion at the MoS has resulted in ad hominems, any discussion proposing anything other than reducing the number of capital letters in article titles almost invariably does. Thryduulf (talk) 12:18, 31 March 2025 (UTC)[reply]
I see no reason to change from the current guideline. Capitalization is a stylistic question. Unless it pretty much is capitalized in all sources, everywhere, all the time, then we are free to choose not to do so. Just as we are free to make other stylistic choices. --User:Khajidha (talk) (contributions) 15:03, 31 March 2025 (UTC)[reply]
I think the underlying logic here—as Khajidha says, that we don't 'follow the sources' when it comes to questions of pure style—is sound and necessary to ensure some level of consistency between articles based on different bodies of sources. Disputes tend to arise when applying this logic to capitalisation because the style we have chosen is quite extreme (i.e. we use as few capital letters as possible without coming off as an art project) and therefore more likely to clash with sources and editors' experiences elsewhere. They are exacerbated by a small group of editors who zealously and tactlessly apply this style across articles, with no regard for the preferences of those that wrote them. I'm unsure that tweaking the rule will solve either issue. – Joe (talk) 15:27, 31 March 2025 (UTC)[reply]
"with no regard for the preferences of those that wrote them" I'm not seeing how this is a problem. You aren't writing for you and your preferences. You are writing for Wikipedia and our style. --User:Khajidha (talk) (contributions) 17:23, 31 March 2025 (UTC)[reply]
The proposal is to change our style… so simply pointing to the current style guidance and saying “you are writing for our style” isn’t really an argument. Please explain why you think the current guidance is better than the proposal. Blueboar (talk) 21:02, 31 March 2025 (UTC)[reply]
Because it looks better and is easier to read with less capitalization. But, as I'm not the one arguing for change, I'm not the one who needs to explain. --User:Khajidha (talk) (contributions) 21:14, 31 March 2025 (UTC)[reply]
So, your reasons are 1) "your personal preference" and 2) "an uncited and possibly wrong factual claim"?
I've seen sources claiming that all lowercase is easier to read than all uppercase (once you know how to read. Brand-new readers often struggle to differentiate lowercase letters like d and b, so all-caps text sometimes works better for them). I don't remember seeing any research saying that "war and peace" is easier to read that "War and Peace".
About as I'm not the one arguing for change, I'm not the one who needs to explain: I guess I hope that editors who join a discussion are trying to find the Wikipedia:Consensus. That only works if everyone is willing to explain their views. Wikipedia:BOLD, revert, discuss cycle, in particular, is entirely dependent upon the reverter/objector being willing to explain why they object to a change. A stonewalling attitude like "You made the change, so I'm not the one who needs to explain my views" will cause BRD – and most other serious discussions – to fail. Please don't do that. WhatamIdoing (talk) 05:12, 1 April 2025 (UTC)[reply]
The problem is that having people who still want to write articles is several gazillion times more important to Wikipedia's future than consistent capitalization of titles. – Joe (talk) 21:51, 31 March 2025 (UTC)[reply]
  • I find it interesting that basically everyone in that discussion agrees that "always capitalized in reliable sources" shouldn't be taken literally, but those opposed are saying we can't change it because some parade of horribles will follow. ~~ Jessintime (talk) 19:25, 31 March 2025 (UTC)[reply]
    Perhaps “overwhelmingly capitalized in sources” is closer to how we really operate? Blueboar (talk) 21:08, 31 March 2025 (UTC)[reply]
    It depends on the discussion whether it's "overwhelmingly", "almost always" or "literally always". Often it's "Overwhelmingly (or almost always) capitalised in sources that I can't dismiss as not-independent, unreliable, "specialist", "low quality", or for some other reason". I think it would be much closer to our ethos and a more professional approach to capitalisation if the standard was something like "predominantly capitalised" with usage by subject matter experts weighted a bit higher than usage by others and we treated the context-free evidence from sources like ngrams as a single, relatively low-importance data point. Thryduulf (talk) 21:26, 31 March 2025 (UTC)[reply]
    That "sources I can't dismiss as..." bit sounds like what I've seen in many areas. WhatamIdoing (talk) 05:14, 1 April 2025 (UTC)[reply]
@Chicdat: I wish I had time to write and refine something concise and thoughtful here, because there is considerable history and a lot of nuance. But just to offer a few stray thoughts
In the end content is what's important, style is just the dressing. As a reader, I like to have articles that look nice and are consistently formatted, but what I really want are articles that are well-written and informative.
Maybe the specifics of the guideline shouldn't matter match. Guidelines are supposed to be just that occasional exceptions may apply in principle a solid local consensus should be sufficient to override, though in practice it's complicated.
WP:STYLEVAR works just fine and helps to reduce acrimony, but its not always practicable. Could it work in the area of capitalization? Well in at least one area it already does. Would it work more widely? Difficult to say, not a lot of hard evidence either way.
No matter where you draw the lines there will always be edge cases, one choice or another will not eliminate good-faith disputes among contributors.
NYB once wrote of the potential for a demoralizing effect, I'm confident it exists, but judging its effects is harder. Some might remember the editors lost from WP Birds as a result of a capitalization controversy, but there were other factors at play there as well.
From the beginning the MoS has been one of those perennial dispute/disruption areas, its not everyone's cup of tea, and I certainly would not fault anyone for avoiding it. At the same time if you want to help build consensus you have to be involved. A common complaint is that MoS related discussions are not representative of the community as a whole because only the people who have the MoS as their focus show up in number since they are more likely to monitor Wikipedia talk:Manual of Style#Style discussions elsewhere. Maybe so, but there's nothing that prevents people who are mostly content editors from also monitoring the section and offering their assessments.
Maybe what is really needed is a broader cross section of the community offering input, and regardless of ultimate outcome, that's really desirable for all discussions. You can help. Sure you'll get unpleasant responses, don't let them get under your skin, be assertive not aggressive, stand your ground but be willing to hear others out as well. And know when to disengage. DGG once suggested the principle of limiting your comments in discussions that were primarily contentious rather than collaborative, let everyone have their say and see what shakes out.
Sorry for the length and disorganization, given time constraints I probably shouldn't be editing at all at present, but hopefully you found some of that useful. 184.152.65.118 (talk) 17:04, 6 April 2025 (UTC)[reply]

Standardized rendition of foreign terms

Wiki articles using foreign terms have a variety of markup for the terms, translations, transliterations and pronunciations. I propose that Wikipedia recommend a style and provide a template that automatically renders in that style. Before making a concrete proposal I'd like to see some discussion on, e.g., numbered parameters versus keyword parameters, typefaces, punctuation, affixes.

The most obvious approach is to add parameters to the existing {{lang}} and {{langx}} templates. Thus {{lang|he|גָּמָל|gamal|camel}} might render as "גָּמָל (gamal transl. he – transl. camel)" -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:20, 31 March 2025 (UTC)[reply]

I don't think you're using {{translation}} correctly there. Do you mean גָּמָל (gamal transl. camel)? jlwoodwa (talk) 18:06, 31 March 2025 (UTC)[reply]
I gave {{lang|he|גָּמָל|gamal|camel}} as an example of what the proposed extension might look like; the double transl. comes from {{lang|he|גָּמָל}} ({{xlit|he|gamal}} {{translation|he|camel}}). You appear to be correct: {{tl:translation}} does not take a language parameter, and without it I get "גָּמָל (gamal transl. camel)" -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:04, 1 April 2025 (UTC)[reply]
Some languages have standardized orthography. Others like Yiddish are quite inconsistent (though YIVO attempts to standardize this). What should happen if the Hebrew example has no diacritics/nekudot? It's obvious to hebrew readers or a bot with a multi-lingual dictionary, but there may be homonyms too. Worth advertising this discussion at Template talk:langx as well ~ 🦝 Shushugah (he/him • talk) 01:11, 1 April 2025 (UTC)[reply]
I don't want the template to change the orthography of the word, just markup with bold or italics, add punctuation and add affixes in accordance with whatever Wikipedia recommends. No adding or removal of Niqqued, no conversion between Ktav male and Ktav chaser. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:04, 1 April 2025 (UTC)[reply]
The discussion at Wikipedia talk:Manual of Style#Should we generally prefer romanizations over non-Latin script in running text? suggests a use case for such a consolidated template together with a template to specify a per-article formatting option. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:44, 1 April 2025 (UTC)[reply]
Because it has been used twice without either using the spelling that the Wikipedia article uses... Niqqud. and the Ktav Male is talked about on Ktiv hasar niqqud. Basically, the question is whether to do (example from the translation at Ktiv hasar niqqud)
  • Hebrew without any changes (מכמן) *or*
  • Hebrew with the addition of Niqqud (the vowel dots and dashes) (מֻכְמָן) *or*
  • Hebrew with the addition of the letters Yud and Vov in certain places to help understand the niqqud/vowel sounds that would be there (מוכמן)

Naraht (talk) 18:50, 1 April 2025 (UTC)[reply]

@Chatul could you re-clarify what you want, and what is not happening in current {{langx}}? I am confused now if this is solely about italicizing certain cases, or automatic romanization, or providing a user-input for romanization. Can you include example code you'd want, and expected output? I also am confused if trans. refers to translation or transliteration. ~ 🦝 Shushugah (he/him • talk) 16:35, 2 April 2025 (UTC)[reply]
I want a single template that accepts a language code, a foreign phrase, and optional parameters
  • Transliteration (Romanization)
  • Translation
  • IPA
  • Processing options
that displays the unaltered[a] foreign phrase, transliteration, translation and IPA text in a style consistent with a default Wikepedia style or a style requested for the article, applying bold and italic, adding parentheses and other punctuation and inserting affixes in according to the selected style. The current {{langx}} only handles the foreign phrase, not the transliteration, translation or IPA.
I'm not asking for automatic Romanization of the input phrase; au contraire, I want the ability to prevent any automatic transformations of the inputs.
The text transl. is generated by {{translation}} and is not part of my suggestion, unless one of the supported styles requires it.
Possibly with a template name other than {{lang}} or {{langx}}, I want {{lang|he|גָּמָל|gamal|camel}} to render as, e.g., "גָּמָל (gamal transl. camel)"; I have no opinion on what styles should be supported. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:38, 2 April 2025 (UTC)[reply]
@Chatul I show below two example markups and what they render as. trans. is still a bad shorthand, because it can be confused with translation or transliteration. lit. (literal translation) and romanized are the two terms I see on Wikipedia a lot.

This is the default use case

Markup Renders as 
{{langx|he|גָּמָל|gamal|camel}}

Hebrew: גָּמָל, romanized: gamal, lit. 'camel'

Without labels

(no option to exclude specific labels, but I can imagine support for language-label=none) field.

Markup Renders as 
{{langx|he|גָּמָל|gamal|camel|label=none}}

גָּמָל, gamal, 'camel'

~ 🦝 Shushugah (he/him • talk) 11:28, 6 April 2025 (UTC)[reply]

MOS:SIMPLEGLOSS recommends to remove the comma between "gamal" and "'camel'", to give "גָּמָל, gamal 'camel'". Otherwise, should we use {{lang}} instead of {{langx |label=none}}? LightNightLights (talk • contribs) 14:30, 6 April 2025 (UTC) (edited LightNightLights (talk • contribs) 14:56, 6 April 2025 (UTC))[reply]
I was relying on the differences of {{langx}}, but looking at the list of parameters I see that it is almost what I want. The only things that I would change are
  • Distinct parameters for literal translation and translation of the idiom
  • IPA parameter
  • Support Wiki style guidelines, e.g, MOS:SIMPLEGLOSS
I would support using a lit prefix for literal translations and translation for others; I agree that transl is ambiguous. The documentation for {{lang}} does not show parameters for translation and transliteration. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:37, 7 April 2025 (UTC)[reply]


Notes

  1. ^ In particular, for Hebrew
    • Don't add Niqqud
    • Don't add Vav
    • Don't add Yod
    • Don't remove Niqqud
    • Don't remove Vav
    • Don't remove Yod

Ignore edits to ones own user area in right counts

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

How often does this happen?
This link will give you a list of every page moved by any account with (if memory serves) 10–500 edits during the last 24 hours. Looking at it, there's been about 125 entries in the move log, but if there's a talk page, then a single "move" action will be logged twice, so there are probably about 50 names to review. I looked at about 10; I found only one that might have been tripped up by such a rule.
The point behind autoconfirm is that obvious vandals are obvious before they make 10 edits. If they're not obvious vandals, then why shouldn't they be able to draft an article in their userspace and move it to the mainspace when they're ready for it to face Wikipedia:New pages patrol? WhatamIdoing (talk) 03:00, 5 April 2025 (UTC)[reply]
Is there any user right besides autoconfirmed that is triggered by edit count? Cambalachero (talk) 03:21, 5 April 2025 (UTC)[reply]
WP:XCON which requires 500, though as with AC it also has a time component, 30 days instead of 4. And yes it is also routinely gamed. 184.152.65.118 (talk) 03:26, 5 April 2025 (UTC)[reply]
WP:XCON (but AIUI not WP:AUTOCONFIRM for technical reasons) can be revoked if a user is judged to be gaming the permissions system. Requiring that edits counting towards AC/EC not be in userspace will probably have limited effect on people actively gaming permissions – they can simply shift their permission-gaming to a different namespace. Especially in the case of autoconfirm, which only requires 10 edits. Caeciliusinhorto-public (talk) 15:53, 7 April 2025 (UTC)[reply]

Discussion at Wikipedia talk:Autopatrolled § Activity requirements for autopatrolled

 You are invited to join the discussion at Wikipedia talk:Autopatrolled § Activity requirements for autopatrolled. HouseBlaster (talk • he/they) 01:50, 5 April 2025 (UTC)[reply]

hoy

you could have a count of edit filters per article I think, that would be useful to keep track of the most problematic and priority articles. (red annales) (talk) 20:00, 6 April 2025 (UTC)[reply]

The Wikipedia:Edit filter applies globally, so I assume you mean the pages to whom the most edits triggering the edit filter are made. It's also important to note not all edit filters are meant to track non-constructive edits. -insert valid name here- (talk) 20:54, 8 April 2025 (UTC)[reply]

More formal "green" and "gold" concepts for Good and Featured article qualities

The Featured star doesn't look quite right but this is a good concept

I saw the graphic for the Four Award and it struck me that Featured-class content really doesn't flow the best with Good-class content in a stylistic sense. Notice that all of the icons about the award are all in a similar style yet the Featured-class star is just pasted on a gold badge and that's that. The featured star is lovely for what it is but I personally think it should, at least in some sense, be partially retired, in exchange for a new graphic of a golden star. This would appear very similar to the one in the top-right corner of the Four Award graphic, but would, of course, have a simple shape instead of the complex star.

Purely from a cosmetic standpoint, the Featured star already kind of blurs together. It's got a hell of a lot more lines than would be expected of a standard graphic. A simple golden star badge akin to that of the Good-class content badge would be more understandable to newcomers, more intuitively clear being above Good-class content, and straight-up be cleaner, flowing with the design of the other 99.9 percent of content on the project.

Not only would this look better alongside the myriad of other simple icons we have on site, but would flow better with the concept of Featured content being obviously higher quality than Good content - green and gold. For instance, Wikipedia:WikiProject Women in Green is called that due to their work getting articles to good-status, or "green", so I don't see why featured content shouldn't have its own simple color designation - in this case, "gold".

I understand how potentially controversial replacing an icon that has been on the site for years might be, and to that end, I propose in addition that a Featured content barnstar be added for serial contributors to featured content, etc. I'm a bit shocked there isn't one now but if replacing the Featured star for something more standardized and stylistic with the rest of the icons is going to happen I don't want to see the Featured star gone for good, as it's a good graphic, and it'd make a better barnstar. This is just an idea as is. I don't know what popular reception will be and I take it this isn't going to be the most popular thing, but I'd appreciate anyone's input on this. Departure– (talk) 14:00, 11 April 2025 (UTC)[reply]

A FA star is given, so to speak, upon the passing of an FA, so it probably does not exist as a separate barnstar because that would be somewhat redundant. The design has made it into other barnstars though, like the File:Reviewer's Award2.png. As you state, this is a somewhat perennial proposal, previous simply star designs (eg. File:Symbol star gold.svg) have not garnered support. I think if you want to promote "gold" as a concept though, there isn't any inertia in the way of that. CMD (talk) 14:56, 11 April 2025 (UTC)[reply]

WMF

Wikilinking to Asian News International vs. Wikimedia Foundation

Recently an editor removed wikilinks to Asian News International vs. Wikimedia Foundation from many articles. [19][20][21][22][23] What are our thoughts on if we should or should not wikilink to the article Asian News International vs. Wikimedia Foundation? I am inclined to keep these links and have said so before, but would appreciate hearing some other thoughts. cc Pppery. –Novem Linguae (talk) 04:17, 10 March 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]
(edit conflict) My comment there:

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. Sdkb talk 07:02, 10 March 2025 (UTC)[reply]
I agree with the idea that links should be retained, unless there is any legal compulsion against it. —CX Zoom[he/him] (let's talk • {C•X}) 08:40, 10 March 2025 (UTC)[reply]
Sdkb makes sense to me. Gråbergs Gråa Sång (talk) 12:32, 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]
I see a rough consensus to restore the wikilinks. Any objections before I go making edits? –Novem Linguae (talk) 11:48, 11 March 2025 (UTC)[reply]
 Done –Novem Linguae (talk) 06:08, 13 March 2025 (UTC)[reply]

Status

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]
@Tazerdadog Recent coverage: ANI vs Wikipedia: Supreme Court questions Delhi HC over Wikipedia page takedown order. Gråbergs Gråa Sång (talk) 15:26, 17 March 2025 (UTC)[reply]
The Delhi High Court has now issued an interim order for the WMF to take down alleged "defamatory statements" on the ANI article. (Bar and Bench) --Grnrchst (talk) 10:39, 2 April 2025 (UTC)[reply]
@Jimbo Wales or anyone from WMF who is reading here...is it possible to get some discussion here of what WMF's response to this will be? The community will want to be able to give input if there's any chance WMF is considering anything like edit/blacklock or remove that article. While either would be objected to, it's likely the reaction from the community will be worse if WMF simply presents us with a fait accompli. Valereee (talk) 10:58, 2 April 2025 (UTC)[reply]
Adding to this, editors are trying, based on media-coverage and discussion, to do something constructive with the ANI article over at Talk:Asian News International. However, without any word on WMF-intent regarding article content, it may just be a waste of time and energy. Gråbergs Gråa Sång (talk) 18:10, 10 April 2025 (UTC)[reply]

US government questionnaire

The organisation I work for has been sent this questionnaire by the US government. It has 36 questions that produce a score between 12 and 180. I would like to know what WMF's score is. Hawkeye7 (discuss) 20:23, 24 March 2025 (UTC)[reply]

combatting Christian prosecution I would normally think this was a typo. But given the circumstances... GMGtalk 13:59, 25 March 2025 (UTC)[reply]
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]
Me neither, but I still have to deal with the questionnaire. Hawkeye7 (discuss) 21:14, 27 March 2025 (UTC)[reply]
I have to wonder what the actual US government would score on that thing. Seraphimblade Talk to me 03:48, 28 March 2025 (UTC)[reply]
The WMF doesn't need to do it though. And I'm not sure why you are posting here instead of contacting the WMF directly. Doug Weller talk 08:26, 28 March 2025 (UTC)[reply]
Universities in Europe are generally advising not to fill in or respond to the survey. – Joe (talk) 08:36, 28 March 2025 (UTC)[reply]
We have to encourage free speech and encourage open debate and free sharing of information but also be sure to not work with any party that espouses anti-American beliefs, I guess. jp×g🗯️ 04:56, 1 April 2025 (UTC)[reply]

The MS forums will be CLOSED soon

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.

--Sm8900 (talk) 21:30, 25 March 2025 (UTC)[reply]

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]
There was demand from multiple groups:
  • Groups that needed private off-wiki discussions. For example, event planners or admins sometimes need to talk privately, because you don't want discussions about some subjects (e.g., venue contract negotiations or the latest move by a long-term abuser) to be publicly visible to anyone on the internet. These have always happened, but they have previously happened via private m:IRC channels or private m:mailing lists.
  • People who wanted a discussion system with built-in machine translation available so they could have discussions across language barriers. Japanese editors have been particularly under-represented in prior movement discussions, and they have been somewhat over-represented in the Movement Strategy Forums.
  • People who wanted to be certain that the person they're talking to is actually the editor of the same name. On the Forums, you can be certain that "WhatamIdoing" is me. On most other channels used by editors, you have no such certainty, because anyone can sign up under any name. For example, years ago, an LTA impersonated me on a couple of social media websites.
  • People who don't use the Latin alphabet. Several language communities have relatively little discussion on wiki, because typing in their home language, and especially typing wikitext codes, has been difficult. We don't necessarily want editors to use external apps, with their anti-privacy policies, to talk about Wikipedia's everyday business. Having a bespoke forum under our own privacy policies helps keep editors safe. (The Reply tool is another initiative from the WMF to reduce this voluntary, editor-initiated fragmentation.)
WhatamIdoing (talk) 22:58, 4 April 2025 (UTC)[reply]
@WhatamIdoing Agree i absolutely agree with you, 100%!! well said!! Sm8900 (talk) 15:27, 7 April 2025 (UTC)[reply]
@WhatamIdoing It shouldn't be too difficult to implement oAuth on existing forum software (Flarum?), and add some JS that translates posts. If that demand still exists I'll do it for 19K USD per year. Polygnotus (talk) 18:42, 9 April 2025 (UTC)[reply]

WMF announcement: Strengthening Wikipedia’s neutral point of view

See WMF announcement and Meta page and Meta discussion page Hemiauchenia (talk) 20:39, 27 March 2025 (UTC)[reply]

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]
I think you'll find the radar image two sections up. Hawkeye7 (discuss) 03:42, 28 March 2025 (UTC)[reply]
That will likely have contributed to it. There probably isn't a clear single cause, it will have been hazily floating around for awhile, notable items that spring to mind include the meta:Croatian Wikipedia Disinformation Assessment-2021, the zh.wiki office actions, longstanding jp.wiki concerns, the ruwiki split, and other issues that have popped up in meta RfCs. CMD (talk) 06:34, 28 March 2025 (UTC)[reply]

Hi

Could have its own artificial intelligence from the wikimedia foundation to be consulted in auxiliary ways. (red annales) (talk) 19:51, 6 April 2025 (UTC)[reply]

I think that actually existing ai like chatgpt is useful if one needs it as one possible resource for simple research. Sm8900 (talk) 02:05, 10 April 2025 (UTC)[reply]
Can we add anything related to AI to WP:PEREN? I feel like by now it's clear how wikipedians feel about the topic by now and the recent AI hype means we'll keep seeing proposals like this until the WMF makes a statement mgjertson (talk) (contribs) 19:44, 10 April 2025 (UTC)[reply]

Wikimedia Foundation Bulletin 2025 Issue 6

Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on 21 March. Please help translate.

Upcoming and current events and conversations
Let's Talk continues


Annual Goals Progress on Infrastructure
See also newsletters: Wikimedia Apps · Growth · Research · Web · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on MediaWiki.org


Annual Goals Progress on Knowledge Equity
See also a list of all movement events: on Meta-Wiki

  • Wikipedia Library: What’s new from January to March 2025.
  • Let's Connect Learning Clinic: Missed the last Learning Clinic on "Safe Spaces, Strong Voices: Advancing Inclusion through the UCoC"? Recording is now available.


Annual Goals Progress on Safety & Integrity
See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog


Annual Goals Progress on Effectiveness
See also: quarterly Metrics Reports


Board and Board committee updates
See Wikimedia Foundation Board noticeboard · Affiliations Committee Newsletter


Other Movement curated newsletters & news
See also: Diff blog · Goings-on · Planet Wikimedia · Signpost (en) · Kurier (de) · Actualités du Wiktionnaire (fr) · Regards sur l’actualité de la Wikimedia (fr) · Wikimag (fr) · Education · GLAM · The Wikipedia Library · Milestones · Wikidata · Central and Eastern Europe · other newsletters

Subscribe or unsubscribe · Help translate

For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. Let askcac(_AT_)wikimedia.org know if you have any feedback or suggestions for improvement!


MediaWiki message delivery 15:53, 7 April 2025 (UTC)[reply]

Update on developments in India

This communication is intended to provide an update on ongoing developments in New Delhi, India, involving Wikipedia, which have also been reported in the media. In the interest of transparency, our endeavour remains to keep Wikimedia volunteers informed regularly; however, please note that commentary on pending litigation by the parties involved is limited due to the sub judice rule.

We currently have two important updates to share:

  • Supreme Court Proceedings: On April 9, 2025, the Foundation concluded its arguments before the Supreme Court of India in its challenge [SLP (Civil) Diary No(s). 2483/2025] to the Delhi High Court's takedown order concerning the English Wikipedia article "Asian News International v. Wikimedia Foundation". The Supreme Court has now reserved its judgment (i.e., it will deliberate and deliver its written verdict in due course).
  • Interim Injunction Order and Appeal: On April 2, 2025, the Single Judge Bench of the Delhi High Court issued an order on interim injunction in the ongoing civil suit titled ANI Media Private Limited v. Wikimedia Foundation and Ors [CS (OS) 524/2024, IA 32611/2024]. In response, the Foundation filed an appeal before the Division Bench of the Delhi High Court [FAO (OS) 41/2025]. The Foundation's Legal Department is currently awaiting the Division Bench's order.

Please note that the Foundation is unable to respond to specific questions or discuss the ongoing proceedings further at this time; however, the Foundation has also taken note of concerns raised by members of the Wikimedia community.

As developments unfold, we will continue to provide updates to the extent permissible under applicable laws. The Foundation remains steadfast in its commitment to access to knowledge as a global human right and will continue to take all necessary measures to ensure that everyone can share and access free knowledge on Wikipedia. Joe Sutherland (WMF) (talk) 23:37, 10 April 2025 (UTC)[reply]

@JSutherland (WMF): On April 8, the Division Bench upheld the single bench judgment and ordered the content to be taken down. Wikipedia is an intermediary, can’t appeal takedown court order on merits: Are you not updated with this news? GrabUp - Talk 04:15, 11 April 2025 (UTC)[reply]
They will have been, by their lawyers, and not a media source. Slatersteven (talk) 10:27, 11 April 2025 (UTC)[reply]

Miscellaneous

An improved dashboard for the Content Translation tool

Hello Wikipedians,

The Language and Product Localization team has improved the Content Translation dashboard to create a consistent experience for all contributors using mobile and desktop devices. Below is a breakdown of important information about the improvement.

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.

Where can I test this improvement and report any issues before it is implemented in this Wiki?
You can try the improved capabilities in the test wiki using this link: https://test.wikipedia.org/w/index.php?title=Special:ContentTranslation&campaign=contributionsmenu&to=es&filter-type=automatic&filter-id=previous-edits&active-list=suggestions&from=en#/

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!

On behalf of the Language and Product Localization team. UOzurumba (WMF) (talk) 17:56, 14 March 2025 (UTC)[reply]

Thanks for the update! —Ganesha811 (talk) 21:03, 18 March 2025 (UTC)[reply]
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]
@Mrfoogles, there is a feedback button in Special:ContentTranslation. You might try using that.
Alternatively, perhaps some system could be set up to allow trusted users access to machine translation, which would help with (e.g.,) links. Send me an e-mail message if you'd like to know how to get machine translation. WhatamIdoing (talk) 03:27, 29 March 2025 (UTC)[reply]
I asked free ChatGPT "How, as a Wikipedia editor, would you respond to the person who wrote the original post in the discussion at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(miscellaneous)#I_boldly_put_LLM-generated_summary_suggestions_on_the_talk_pages_of_the_68_most_popular_articles_with_Technical_templates". After it replied, I asked it to reformat its reply as wikicode to be pasted here. Here it is, for what it's worth:
== Response to LLM-generated summary suggestions ==
As a fellow Wikipedia editor, I appreciate your initiative in exploring the use of Large Language Models (LLMs) to generate summary suggestions for the talk pages of high-traffic articles. Integrating advanced technologies like LLMs can potentially enhance our collaborative editing process. However, it's crucial to approach this integration thoughtfully, considering both the benefits and the challenges.
=== Key Considerations ===
1. Accuracy and Reliability: LLMs, while powerful, can produce content that appears factual but may contain inaccuracies or fabrications. Relying solely on LLM-generated summaries without thorough verification could lead to the dissemination of incorrect information. (Source)
2. Attribution and Transparency: When incorporating LLM-generated content, it's essential to clearly indicate its origin. This transparency allows other editors to critically assess the content's validity and ensures adherence to Wikipedia's commitment to verifiability. (Source)
3. Community Guidelines: The Wikipedia community is actively discussing the role of AI-generated content. Current guidelines advise against publishing content solely produced by LLMs without substantial human oversight and caution against using LLMs to create original content or references. (Source)
=== Recommendations ===
  • Collaborative Review: Encourage fellow editors to review and refine LLM-generated summaries. This collaborative approach leverages human expertise to validate and improve AI-generated content.
  • Ongoing Discussion: Engage in community forums to share experiences and gather feedback on using LLMs in the editing process. Collective insights can guide the development of best practices and policies.
  • Adherence to Policies: Stay updated with evolving guidelines regarding AI-generated content to ensure compliance and maintain the integrity of Wikipedia's information.
Your proactive efforts highlight the potential of integrating AI tools into our editing workflows. By proceeding with caution and fostering open dialogue, we can harness these technologies to enrich Wikipedia while upholding its standards of accuracy and reliability.
== Related Reading ==
Largoplazo (talk) 22:04, 2 April 2025 (UTC)[reply]

Edit count of users blocked as LLMs increasing 10x per year

English Wikipedia non-IP Accounts Blocked as LLMs

Please see this WT:LLM discussion.

Cramulator (talk) 01:37, 30 March 2025 (UTC)[reply]

Can I get credit for predicting this at Wikipedia:Eleventy-billion pool#2038 with my predictions for January 19?-Gadfium (talk) 02:53, 30 March 2025 (UTC)[reply]
Half credit. Cramulator (talk) 12:40, 3 April 2025 (UTC)[reply]

I have to start work very shortly, but I've been repeatedly urged to start a discussion here, so please pardon my brevity.

This morning, I posted summaries from the 68 most popular articles or their sections with the {{Technical}} template to their talk pages. So far I have about two positive, two neutral, and four negative comments. My major error was asking for fifth grade reading level summaries (because I had a vague recollection that was the target for the World Book Encyclopedia reading level) but I have since learned that STEM articles on Wikipedia are preferably written at the ninth grade reading level, when e.g. WP:ONEDOWN or the other conditions at WP:JARGON don't apply.

I did carefully read WP:LLM, which says, among many other pertinent things, that "LLMs can be used to copyedit or expand existing text and to generate ideas for new or existing articles." And generally, other pages such as Wikipedia:Using neural network language models on Wikipedia and this discussion seem even more positive on this use case. However, I agree that the summary should be sourced to the sources for the statements being summarized, and I don't know what I should do about that. I also read all of the 68 articles I generated summaries for and the summaries themselves. Anyway, here are the fifth grade and ninth grade level summaries, and I've released the source code into the public domain.

Please share your opinions! Cramulator (talk) 16:46, 2 April 2025 (UTC)[reply]

I think this was a reasonable idea. * Pppery * it has begun... 16:47, 2 April 2025 (UTC)[reply]
Thank you. As is evident below, the vast majority of editors disagree, so I am immediately halting all non-userspace work on this project. I will post a short retraction of the suggestions to the 68 talk page sections in a day or two, barring any objections to doing that. In a week or two, I will write a postmortem report in my userspace in an attempt to summarize all of the comments received here, on the talk page sections, and on my user talk page, and link to it from the examples on WP:LLM and the other AI use guidance pages as a cautionary tale. Of course I will also post a link to that postmortem here.
I would like to thank everyone, especially those whose sensibilities I offended, for your frank and forthright criticism, and the words of support from the handful in the minority. There is so much I want to say about specific objections, some of which may never be able to be addressed adequately, some of which might be with varying degrees of difficulty, and some of which were probably based on misconceptions about my aspirations, the language I used when posting the 68 suggestions, the process used, what LLMs can and can not do, and other assumptions. That can wait. But no matter how much progress I can make improving the quality, style, appropriateness, presentation, and referencing of these suggestions, I will not be proposing to continue this project. Perhaps if I can show enough progress, someone else in coming years might.
I will say this in my defense: While I fully admit I have inadvertently caused disruption and anger far beyond what I expected, nevertheless, after just over half a day there are now five of the 68 articles which had been tagged as overly technical, all viewed by 500 to 2,500 readers per day, that have had their prose improved and their years-old cleanup tags removed. I will take some consolation that I may have spurred some help for those roughly half a million readers annually, from humans, not machines. Cramulator (talk) 06:42, 3 April 2025 (UTC)[reply]
In my opinion, bullshit-bot-generated text should be deleted from Wikipedia (articles, talk pages, everywhere) on sight. If a contributor can't communicate in their own words, they should leave such matters to people who can. AndyTheGrump (talk) 16:51, 2 April 2025 (UTC)[reply]
Please don't do this. It hurts to read these. I checked this ("A rainbow table is like a special cheat sheet that helps bad people guess passwords."), this and this ("If the minimum wage is already high, raising it more could make fewer people want to work"?). Fram (talk) 17:01, 2 April 2025 (UTC)[reply]
I'd like to comment on the Minimum wage#Welfare and labor market participation section summary. It is a poor summary of the final sentence, and a wholly inaccurate summary of the final paragraph, of the tagged section added by User:Mersenne56 in 2019, sourced to this book. I am unable to verify that the source actually supports the final sentence of that section. The plain language said to follow from the mathematics does not appear to me to follow at all. If prevailing wages are greater than those attainable by bargaining, an increase in the minimum wage should still increase labor force participation. I suggest the final paragraph is in error, and that the surprising statement was called out by the LLM because it is so counter-intuitive. I am not trying to make excuses for it; just understand why it happened. Cramulator (talk) 07:26, 3 April 2025 (UTC)[reply]
The statements I included are on p. 797-798 of the cited textbook. If the authors are wrong, so be it; however, I make no apologies for including material from a highly-cited textbook on labor economics. Mersenne56 (talk) 08:09, 3 April 2025 (UTC)[reply]
I am not sure that pages 797 and 798 support the final sentence of the section in question. Do you believe that they do? Cramulator (talk) 10:35, 3 April 2025 (UTC)[reply]
@Mersenne56: regarding this excerpt:
On the other hand, if w ≥ w*, any increase in the minimum wage entails a decline in labor market participation (because V_u decreases) and an increase in unemployment, which necessarily leads to a fall in employment.
What do you believe Vu represents? Cramulator (talk) 10:58, 3 April 2025 (UTC)[reply]
I fear imputing motive and awareness to that LLM, as in called out by the LLM because it is so counter-intuitive, might be an anthropomorphism that doesn't help us understand why it happened or generally use the LLM well. NebY (talk) 12:28, 3 April 2025 (UTC)[reply]
The LLM did not catch the problem, and neither did I. Fram did. Cramulator (talk) 12:41, 3 April 2025 (UTC)[reply]
Thanks for the clear demonstration that it's thoroughly inappropriate to generate summarires like that for Wikipedia. From your ninth-grade file:
to begin 5.56×45mm NATO#Cartridge dimensions: "The 5.56x45mm NATO cartridge has specific measurements and its case can hold 1.85 mL of volume."
to begin DisplayPort: "DisplayPort (DP) is a digital connection primarily used to link video sources, like computers, to display devices, such as monitors."
to begin Avicenna#Metaphysical doctrine: "Avicenna, an important Islamic philosopher, explored deep questions about reality, known as metaphysics."
Did you prompt it to write like a struggling ninth-grader? NebY (talk) 17:21, 2 April 2025 (UTC)[reply]
I looked through a few and found some striking issues. The whole of the summary on the Whore-Madonna complex I think would be unusable. It seems that the time spent making all these questions and discussing them could instead have been used to just read and summarize the articles. Sock-the-guy (talk) 19:21, 2 April 2025 (UTC)[reply]
As usual for LLM on Wikipedia, this appears to be creating more work than it is saving. Please discontinue. –Novem Linguae (talk) 21:10, 2 April 2025 (UTC)[reply]
Wikipedia content is required to be verifiable from reliable sources. If an editor pastes AI-generated content here, and they don't know where the LLM got the information from, they aren't in a position to vouch for it. If the LLM is asked to supply sources, there's still the matter of responsibility for vetting those sources and knowing whether the content the LLM attributes to those sources is actually in those sources and assessing whether the LLM has indulged in unpermitted synthesis. Ultimately, earnest Wikipedia editors out to be able to justify their contributions. The burden of doing so when the contributor didn't create the content seems pretty high. Largoplazo (talk) 21:49, 2 April 2025 (UTC)[reply]
There are ways to force it to use provided sources, and while there is still significant effort in double checking everything and doing some tidying it isn't too onerous. You can't just ask an LLM to do it, there's a process involved. Garbage in, garbage out. ScottishFinnishRadish (talk) 22:10, 2 April 2025 (UTC)[reply]
My opinion is the same as Andy's. There is zero value to any of this crap. Delete on sight. And make it absolute policy that LLM-generated text is not allowed on Wikipedia at all. And if someone spams that crap, they should be indeffed after one warning. oknazevad (talk) 01:38, 3 April 2025 (UTC)[reply]
Shit flow diagram is mostly LLM generated. I used chatgpt 4.5 with project mode and with the LLM only able to draw from specific sources as an experiment to see if there was any use cases. There were some things that required cleanup but it didn't do a bad job. It requires a fair amount of setup and guidance and obviously verifying everything, but it did a good job at accurately summarizing and citing the sources I provided. ScottishFinnishRadish (talk) 01:49, 3 April 2025 (UTC)[reply]
I don't give a damn. You managed to corral the bot, and did work needed to fix it up.Probably would have been easier just to write it from scratch. It's still starting with a fundamentally flawed source. I'd rather not have an article that have one that's unverifiable, unoriginal, and unneeded. oknazevad (talk) 15:03, 3 April 2025 (UTC)[reply]
It was much easier to produce the article with the LLM, although it still involved a decent amount of work. The article is verifiable, I'm not sure what "unoriginal" means in this context, and unneeded is subjective. I will say that public sanitation is an enormous and challenging issue for more than half the population of the planet, so it seems like a topic that deserves coverage. ScottishFinnishRadish (talk) 17:07, 3 April 2025 (UTC)[reply]
"Unoriginal" as in "not originally composed text" as in "LLMs pay little attention to whether or not they have copied exact phrasing, and therefore plagiarize and even creep into copyvio territory". Even if you looked through the sources and didn't see any specific plagiarism in this case, doesn't mean it isn't plagiarized form other sources that it doesn't link to. I see little reason to trust these programs. oknazevad (talk) 23:59, 3 April 2025 (UTC)[reply]
  • It reads very polished, though not being expert on the subject it's incredibly difficult to know. I once read an AI generated article that I thought was really good and let it be. Then on a whim I dug into sources, and discovered it was riddled with subtle but significant problems. It took another week to unpack and rewrite. The whole thing was generated in about 30 seconds by a newbie who did not speak English. They even used AI to have conversations on the talk page. This is how they contributed to Enwiki without learning English. They said in their own language wiki, they lacked freedom of speech. -- GreenC 16:53, 3 April 2025 (UTC)[reply]
    I'm not a shit flow diagram expert, but I researched and wrote the original article, and I found and read all of the sources used in the article. Nothing stands out to me as incorrect, subtly or otherwise, but I'm pretty sure every article has some mistakes. The method I used to significantly longer than 30 seconds, but I think that attention is a good thing when dealing with an LLM in this way. ScottishFinnishRadish (talk) 17:19, 3 April 2025 (UTC)[reply]
These LLMs sound a lot like they know what they're on about... until they're on something you know about. And that's their biggest problem, even when used by well-informed editors. Less time spent writing content sounds great until you have to instead spend that time scrutinizing its output. XtraJovial (talk • contribs) 06:05, 3 April 2025 (UTC)[reply]
Thank you for trying and thank you for accepting the judgement of your peers. Constant314 (talk) 03:03, 5 April 2025 (UTC)[reply]

Although I'm not completely against use of AI to assist a well informed editor in writing, we should not be suggesting it's widespread use by the average editor with only a superficial understanding of a topic. I've used AI to help write professional material off-wiki in areas of my expertise. But like much technology, use by those without expertise risks serious errors. Wikipedia already fights an uphill battle with editors who have little understanding of topics they write about. AI can make writing appear impressive and give the writer a false sense of confidence, but if you look at professional reviews of its use it's scary. Sundayclose (talk) 17:05, 2 April 2025 (UTC)[reply]

I agree. I made similar points at Talk:Waste management where AI assumes that waste = trash. It doesn't.  Velella  Velella Talk   17:18, 2 April 2025 (UTC)[reply]
LLM-generated texts often violate Wikipedia guidelines. For example, both your 5th-grade and 9th-grade AI summaries of Existentialism#Facticity violate MOS:YOU. Phlsph7 (talk) 17:15, 2 April 2025 (UTC)[reply]

I'm going to hop in here, as it's related, to further publicize that I used ChatGPT 4.5 in project mode with sources uploaded directly for an experimental rewrite of Shit flow diagram. While converting all of the references to {{sfn}} I checked sources, verified content and rewrote some parts that had issues. ScottishFinnishRadish (talk) 17:24, 2 April 2025 (UTC)[reply]

  • These summaries are all really bad. LLMs are notoriously bad in particular at summarizing mathematical content. Tito Omburo (talk) 23:03, 2 April 2025 (UTC)[reply]
    I'd have to suggest that rather than being 'notoriously bad' regarding maths, the bullshit bots are similarly bad at summarising anything else one has an actual understanding of. They merely give a superficial appearance of being competent in regards to stuff one doesn't have said expertise in. Observer bias... AndyTheGrump (talk) 23:18, 2 April 2025 (UTC)[reply]
    That's fair and certainly keeping in my own experience. I didn't want to step out of my lane though. Tito Omburo (talk) 09:23, 3 April 2025 (UTC)[reply]
    I agree that we shouldn't use these, but I thank @Cramulator for trying. AI is not going away, and it will only get better. Continuing to experiment with the technology is the best was to understand it and doing so on talk pages and asking for comments here was a responsible way to do that. RoySmith (talk) 11:23, 3 April 2025 (UTC)[reply]
    True, but even then I'm not sure "better bullshit" will automatically translate into a net positive for the encyclopedia. Tito Omburo (talk) 11:32, 3 April 2025 (UTC)[reply]
    We aren't trying to improve the quality of bullshit, we're putting the LTA vandals' ideas into a big wood chipper, and spreading the detritus on the side of the house, because we believe doing so can improve the mean quality of articles. Cramulator (talk) 12:44, 3 April 2025 (UTC)[reply]

I've tried to improve the prompt to source the suggestions. The output is at User:Cramulator/Summaries9a.json. Cramulator (talk) 14:13, 3 April 2025 (UTC)[reply]

I am really unsure what is being achieved here. The proposed summary for Waste management is almost identical to the existing first four paragraphs of the summary. What differences there are could be considered to be cosmetic. It is certainly true that the later paragraphs in the summary should probably be moived in shortened form to the body of the article as this summary has gradually becoming more bloated over the years, but the key paragaphs are so similar that I suspect that the LLM has simply read the original summary and thought "That will do nicely". I cannot see any value added benefit arising from this approach.  Velella  Velella Talk   14:36, 3 April 2025 (UTC)[reply]
You're clearly correct. So now my inclination is to take the reading grade level down from 9 to 7:User:Cramulator/Summaries7a.json. Cramulator (talk) 16:53, 3 April 2025 (UTC)[reply]

This is outright disruptive. :bloodofox: (talk) 23:49, 3 April 2025 (UTC)[reply]

Agreed. oknazevad (talk) 23:59, 3 April 2025 (UTC)[reply]

@Cramulator: Forget reading levels. The important issue, and the general consensus in this discussion, is that LLM has no benefit for Wikipedia and poses serious problems if used, especially if used by someone who has superficial knowledge of the subject. People who do have the prerequisite knowledge can write better than LLM, so it's pointless for them to use LLM. It's time to drop the stick and move on to more important matters. Sundayclose (talk) 00:44, 4 April 2025 (UTC)[reply]

Fully agreed. XtraJovial (talk • contribs) 02:08, 4 April 2025 (UTC)[reply]
  • Just another one wanting to thank Cramulator for their work here. Whatever one thinks of LLMs, the way we really get to know what we're talking about is by thorough work like this. Using the talk: pages also meant that none of this was in any way disruptive. Andy Dingley (talk) 23:08, 4 April 2025 (UTC)[reply]

Final proposed modifications to the Universal Code of Conduct Enforcement Guidelines and U4C Charter now posted

The proposed modifications to the Universal Code of Conduct Enforcement Guidelines and the U4C Charter are now on Meta-wiki for community notice in advance of the voting period. This final draft was developed from the previous two rounds of community review. Community members will be able to vote on these modifications starting on 17 April 2025. The vote will close on 1 May 2025, and results will be announced no later than 12 May 2025. The U4C election period, starting with a call for candidates, will open immediately following the announcement of the review results. More information will be posted on the wiki page for the election soon.

Please be advised that this process will require more messages to be sent here over the next two months.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review was planned and implemented by the U4C. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Please share this message with members of your community so they can participate as well.

-- In cooperation with the U4C, Keegan (WMF) (talk) 02:04, 4 April 2025 (UTC)[reply]

It is a serious matter

I am a simple article writer on the Persian Wikipedia. Unfortunately, Wikipedia administrators. Those who are senior. Most of them have leftist or Islamist beliefs and hide this. And they do not allow us, neutral article writers, freedom of expression. I wish something could be done. Rashidi8080 (talk) 08:49, 4 April 2025 (UTC)[reply]

We cannot help you with issues on the Persian Wikipedia, which is a separate project from the English Wikipedia. You will need to discuss your concerns there, using whatever forum that they have to do so. 331dot (talk) 08:50, 4 April 2025 (UTC)[reply]
It may be a serious matter, but, as 331dot says, it is not one that we can deal with at the English Wikipedia. If you have a very strong case, and it is not listened to at the Persian Wikipedia, it is possible that you may get some redress at Meta:. But I think that is unlikely at a Wikipedia as large as the Persian. Phil Bridger (talk) 09:04, 4 April 2025 (UTC)[reply]
In former times you could appeal to the founder at User talk:Jimbo Wales but I'm not sure that that is useful anymore. Might be. Couldn't hurt I guess. Herostratus (talk) 18:56, 6 April 2025 (UTC)[reply]

Nation names

It is English language Wikipedia policy, largely defined, to use English language word for some nations, even if they've requested otherwise. The most obvious example is Côte d'Ivoire, the name used by FIFA, still known as [[Ivory Coast]]. The argument is that usage dictates policy, and I don't know how much usage changes that policy. A recent example is Czechia, which is stil [[Czech Republic]] (though an article such as this year's Berlin Film Festival uses Czechia and this hasn't been edited, interestingly). I think we all know the talk page of the Turkey article is now a daily request bonanza of editors asking it to be renamed Türkiye.

Is there any chance of the policy being reexamined? I notice, obviously, that Eswatini was changed from Swaziland. There is inconsistency and I wonder if that inconsistency will ever be resolved doktorb wordsdeeds 13:01, 4 April 2025 (UTC)[reply]

The policy is WP:COMMONNAME (part of Wikipedia:Article titles), there is no specific policy about the names of nations. As someone who has followed relevant move requests for a few years, I don't think there is inconsistency, and I have not seen any real enthusiasm to either ditch the article title policy, or create specific carve-outs. CMD (talk) 13:06, 4 April 2025 (UTC)[reply]
Thanks @Chipmunkdavis I think Turkey vs Eswatini shows there is some inconsistency. But obviously I know that editors tend to be cautious about policy changes like this. I'm just curious (and with Czechia being used in some articles unedited I wonder if these things will change organically.). doktorb wordsdeeds 13:13, 4 April 2025 (UTC)[reply]
Swaziland was moved to eSwatini in 2018, in an RM that included a survey of RS that found that the common name had changed to reflect the name change. Further discussion later moved it to Eswatini. RMs for Turkey have included surveys of RS that have found that the common name has not significantly shifted. The inconsistency here reflects real-world inconsistency, it is not an en.wiki creation. It also is not restricted to country names, take Indian cities. Mumbai appears to have been the main article since before article history was fully worked out, which was only about half a decade after renaming. On the other hand, Bengaluru was only moved late last year, a decade and a half after its official renaming. Pondicherry has not been renamed Puducherry, although this may be partially disambiguation. Why was Swaziland changed much faster than Turkey? Hard to say, but English is an official language in Swaziland so perhaps its writers had more cultural pull. Do these change organically? Yes, Timor-Leste was only recently moved, and its RM cited a spike in 2024 in the use of "Timor-Leste", which, as far as anyone has theorised, was due to the pope travelling there late that year. CMD (talk) 13:28, 4 April 2025 (UTC)[reply]
Our consistency lies, rightly, in applying WP:COMMONNAME. That Eswatini has become the common name fairly fast may indicate that "Swaziland" was not mentioned often or embedded in global-north consciousness to the extent of "Czech Republic" and "Turkey". NebY (talk) 13:36, 4 April 2025 (UTC)[reply]
Yes there are a few that are actively debated and there is no one answer that will satisfy everyone. A few. One thing we want to watch out for is nationist special pleading. I'm not saying that that is a major problem. But sometimes. It isn't a mjor problem regarding Türkiye, for instance, but still I would expect that naming to be favored by Turks, who would likely be somewhat nationalistic, not in a bad or toxic way, but in understandably wanting to not use a foreign name for their country. But we really don't care what a native Turkish speaker prefers much more than what a native Humgarian speaker prefers, or shouldn't, and we care more about what native English speakers prefer, or should. We are supposed to be ice-cold neutral about these things. Granted that there will always be political feelings around these things, that is normal, but not a feature.
IMO diacritics are a complication (not all agree). I have no idea how that ü is pronounced, nor ı, and can't be bothered to learn and for good or ill that applies to most readers, who pronounce "straße" as "strabe" and "kanał" as "canal" and just blip over others. Granted the camps for "use diacritics generously" and "use diacritics sparingly" are divided about 50/50 last I knew. Herostratus (talk) 00:09, 7 April 2025 (UTC)[reply]

Just shoot me

Trying to work on article relating to Israel. I am finding it less pleasant than french kissing an alligator. I think we need to have a banner like this on some articles:

Herostratus (talk) 05:50, 7 April 2025 (UTC)[reply]

It's a good idea but will likely only lead to the ire of editors being directed even more fiercely or towards others/the creator of said banner(s). See: any time someone is told to cool off and work on something else (here or elsewhere). Reconrabbit 14:58, 7 April 2025 (UTC)[reply]
The only topic notices I can find are Template:Contentious topics/Arab-Israeli editnotice and Template:Contentious topics/Arab-Israeli talk notice that appear as an edit notice and on the talk page, respectively, and the user talk page CTOP notice. Nothing as bluntly honest as yours. Progress was made at WP:ARBPIA5 in getting some of the hateful/unreasonable editors out of the topic area, but there are still plenty more. All we can do is to be active at WP:AE and tell administrators that the community wants long-term pov pushing to be sanctioned more severely, especially in this topic area. Thebiguglyalien (talk) 🛸 16:14, 7 April 2025 (UTC)[reply]
Right. We do have {{POV}} for article pages. Problem I am having with that is my colleagues on the article we are engaging on are like "No, we can't have that tag. No sane, reasonable person could believe that the article is POV" (altho it is actually quite POV, or at any rate arguably so). So I mean if we did have a tag -- alright, not like the one I wrote about, but something along the general lines of "Because of the topic, this article may not meet our usual standards for neutrality and veracity" or something -- it would have to be placed by some outside agency, such as members of the admin corps or something. But that's not an admin function and would be viewed poorly, with perhaps some justification.
We do have {{Recent death}} which has

This article is currently being heavily edited because its subject has recently died. Information about their death and related events may change significantly and initial news reports may be unreliable. The most recent updates to this article may not reflect the most current information. Please feel free to improve this article (but edits without reliable references may be removed) or discuss changes on the talk page.

which is kinda-sorta similar in way, at least in that it warns about possible unreliablity. But people are usually on one side or the other of a clear DEAD/NOT DEAD line where there's no arguing over whether the tag should apply or not.
Oh wait we do have {{Unbalanced}} and {{cherry-picked}} and various kinds of POV templates. But all those have the same problem: "Article is fine, removed per WP:BRD, make your case [which we will never, ever accept or even bother to read] on the talk page." I mean we could have a rule that everything in Category:Israeli–Palestinian conflict gets tagged. Some won't rate having it but some do, and it gives a clear GO/NOGO line. (Yeah then you coulg get "This article doesn't belong in Category:Israeli–Palestinian conflict so I am removing the category and the tag" even if it does belong. But unless it really is a marginal case that might not be super easy. IDK.
Oh well. Governance here is pretty much Rube Goldberg. I hope the Foundation doesn't feel they have to come in and basically take over editorial oversight, at least on this subject. But, entities that are unable to govern themselves find themselves governed by someone else sooner or later. So maybe. Herostratus (talk) 02:07, 10 April 2025 (UTC)[reply]
{{POV}} should be used as a link to active discussion. If there's not an active discussion on the talk page, then drive-by POV tags should be removed. But if there is an ongoing discussion at the talk page, it belongs on the page per WP:WNTRMT and I'd support a pban or a topic ban against people who keep removing it. But again, the most efficient way to handle this is to have these people removed from the topic area, which many admins are too scared to do. Thebiguglyalien (talk) 🛸 02:53, 10 April 2025 (UTC)[reply]
Scared of what? Herostratus (talk) 03:23, 10 April 2025 (UTC)[reply]
Scared to impose topic bans at WP:AE on the basis of WP:TENDENTIOUS POV pushing. (They can also impose them unilaterally, but that should only be used for egregious offenses rather than long-term issues.) Thebiguglyalien (talk) 🛸 05:39, 10 April 2025 (UTC)[reply]

"Aftermath" sections

aftermath noun the period that follows an unpleasant event or accident, and the effects that it causes

I'm not sure if it's limited to specific domains on Wikipedia, but I often see subsequent events and news under a page section titled "Aftermath", even if the page is not about a disaster, accident, etc. For example, 2020 United States presidential election § Aftermath and 2024 United States presidential election § Aftermath. Is there an alternative meaning of aftermath that is not necessarily preceded by negative circumstances? Or is this a case of Wikipedia misuse that could end up speaking it into existence? —Bagumba (talk) 06:51, 8 April 2025 (UTC)[reply]

Collins says "an important event, especially a harmful one", and gives an example where the "event" is "the Soviet era", so it is not necessarily preceded by negative circumstances (opinions on the Soviet era may vary). That said, your examples seem to indicate a use here as more of a synonym of "impact"/"effects"/"legacy", which is definitely out of proportion to the dictionaries defining it as predominantly linked to negative events. CMD (talk) 07:09, 8 April 2025 (UTC)[reply]
"Legacy" or "retrospective" is often more appropriate describing second-order analysis and long-term effects, but I ruminated and flipped around thesauruses and there would seem to be no formal English word that has a similar sense when it comes to summarizing the short-term ramifications of an event. Remsense ‥ 论 07:57, 8 April 2025 (UTC)[reply]
Sports championship pages sometime use "Aftermath" to document how the winner and loser fared afterwards e.g. 2019 NBA Finals § Aftermath. Sometimes I wonder if it's just a WP:COATRACK, but it's rarely about the "Legacy" or a "retrospective" of the event itself. —Bagumba (talk) 10:23, 8 April 2025 (UTC)[reply]
For the 2019 NBA Finals#Aftermath example, I would probably use "Post-series developments" instead of "Aftermath". Some1 (talk) 23:08, 8 April 2025 (UTC)[reply]
Agree that it is probably the most appropriate word for short- or medium-term effects of events, including battles, disasters, accidents, and I often use it in that way myself. In my experience "Legacy" is more often used for bios to cover longer-term impact of a person's life and work, I'm not sure how often it is used for events, I certainly haven't seen it used much for war-related events. Peacemaker67 (click to talk to me) 09:40, 8 April 2025 (UTC)[reply]
Great Tea Race of 1866 uses "Afterwards" to head the section that says what happened to the ships mentioned (and some captains) after the race. "Aftermath" seems to me to be entirely inappropriate in that situation. Whatever such a section is called, it really counterbalances any "Historical background" (or similar section). ThoughtIdRetired TIR 11:49, 8 April 2025 (UTC)[reply]
Section names should normally be a noun or noun phrase, but Afterwards is an adverb. —Bagumba (talk) 11:57, 8 April 2025 (UTC)[reply]
Desperate times call for desperately taking measures? Remsense ‥ 论 12:00, 8 April 2025 (UTC)[reply]
"Normally" gives some latitude, surely. Given the struggle here to find the right word, is that latitude needed? ThoughtIdRetired TIR 19:35, 8 April 2025 (UTC)[reply]
Afterward or Afterword seem distinctly plausible, especially in the singular. Maybe Postface? The first two are potentially a hair over-narrative-y, the latter potentially not enough so?
(Maybe it's a bit of a generational distinction, perhaps even one mediated by younger people having grown up reading Aftermath sections on Wikipedia?) Remsense ‥ 论 11:58, 8 April 2025 (UTC)[reply]
I was going to suggest sequelae, but that seems to have been hijacked by the medical profession and since nobody learns Latin now, the specialised meaning is fixed as the sole one. ThoughtIdRetired TIR 14:01, 8 April 2025 (UTC)[reply]
I'd love a better word to describe relevents as a result of the big thing implied by the topic. Eg in various SCOTUS cases, events that occurred after the decision. Wording like Legacy or Impact doesn't seem to make sense when we are discussing events after the fact. Masem (t) 14:05, 8 April 2025 (UTC)[reply]
"Impact" would be more encyclopedic, but imagine they often are reduced to WP:EXAMPLEFARMs instead of a summary of consequences. —Bagumba (talk) 07:36, 9 April 2025 (UTC)[reply]
I think "Aftereffects" or "Consequences" would be more suitable for subsequent events that were directly attributable to the occurrence of the event. In the case of sporting events where the section is used to describe the next time the teams made the playoffs, I think that content should be removed, as it is not a direct consequence of the event, and is better covered in the team's article (or a spinout article on the team's history). isaacl (talk) 16:41, 8 April 2025 (UTC)[reply]
"What happened next" may be essential for completeness, but not "after effects" or "consequences" of the article subject.
For example, suppose there was an article on Emigration from Scotland, 1750-1930 (there is a reasonable case for such an article – it covers the demographics of when people left in large numbers and, in total, matches the dates used by sources, the end date being the economic depression in the USA). A closing "what happened next" paragraph would not be a result of the events in the article – covering, among other things, post WW2 emigration and present day events. But without some brief summary mention of emigration after the period, it leaves the subject in a contextual vacuum, making it difficult to understand the significance of this huge outflow. As already suggested above, this would be mirrored by a "historical background" section which covers the "beforehand". The "after" is equally essential for an understanding of the subject. Clearly if the "after" is a big enough subject for its own article, that is a different situation.
(I am aware of Scottish diaspora but that covers a different aspect of the same story.) ThoughtIdRetired TIR 08:20, 9 April 2025 (UTC)[reply]
Sure, whether or not such a section should exist is subject to editorial judgement on what best serves coverage of the event in question. isaacl (talk) 16:35, 9 April 2025 (UTC)[reply]
If there is a better word I have not found it. Legacy is good for long-term consequences, but that is not aftermath, which is shorter term. Consequences or after effects is along the lines of legacy, and is also not quite the same, as something can happen in the aftermath that is relevant but not necessarily a consequence. Afterward/Afterwards seems inappropriate for a section heading. Aftermath does have a connotation of a negative event, but not exclusively as shown by the Soviet example. PARAKANYAA (talk) 03:31, 10 April 2025 (UTC)[reply]
Aftermath does have a connotation of a negative event, but not exclusively as shown by the Soviet example.: I'd argue that aftermath there was meant to imply a negative, as the Soviet Union is often portrayed negatively by Western media. —Bagumba (talk) 03:57, 10 April 2025 (UTC)[reply]
If there is more events to cover after the main subject of the article, then I feel a topic-specific heading should be used, rather than a generic one. isaacl (talk) 04:35, 10 April 2025 (UTC)[reply]

Is it permitted to remove the "External links modified" sections from Talk pages? Hej Simon (talk) 12:40, 8 April 2025 (UTC)[reply]

Yes. * Pppery * it has begun... 13:51, 8 April 2025 (UTC)[reply]
Okay! Hej Simon (talk) 13:56, 8 April 2025 (UTC)[reply]

Wikipedia:Seven million articles

Seeing as we are probably about less than two months away from reaching 7,000,000 articles, I created Wikipedia:Seven million articles, based off of Wikipedia:Six million articles, and updated what I could. If anyone else thinks there are enhancements to the page, please feel free to add to it! Cheers, « Gonzo fan2007 (talk) @ 17:36, 8 April 2025 (UTC)[reply]

Many editors think that stubs should be merged to other articles. As one of the dwindling number of editors that remembers paper encyclopedias, where most articles consisted of one or two sentences, if that, I happen to disagree, but I seem to be in a minority. Please be aware that such people do not regard large numbers of articles as something to celebrate. Phil Bridger (talk) 19:22, 8 April 2025 (UTC)[reply]
I think it is a good thing than you did prepared this text for this article that was not published yet.
Maybe it was not wrote yet.

My point of view is the next. This page is acceptable.

I saw only a minor problem.
It's wrote : "* Wikipedia in more than 350 language editions with over 64 million articles in total."

There are 341 active editions when I'm writing this message. I don't know if it's better to take into accounts only the active Wikipedias. Anatole-berthe (talk) 06:52, 9 April 2025 (UTC)[reply]

WP:UPSD Update

Following Wikipedia:Village_pump_(policy)/Archive_201#URLs_with_utm_source=chatgpt.com_codes, I have added detection for possible AI-generated slop to my script.

Possible AI-slop sources will be flagged in orange, thought I'm open to changing that color in the future if it causes issues. If you have the script, you can see it in action on those articles.

For now the list of AI sources is limited to ChatGPT (utm_source=chatgpt.com), but if you know of other chatGPT-like domains, let me know!

Headbomb {t · c · p · b} 22:13, 8 April 2025 (UTC)[reply]

@Riad Salih: this may be of interest to you. Headbomb {t · c · p · b} 22:45, 8 April 2025 (UTC)[reply]

Non-free licenses for PD-USonly works

I've got a file that's {{PD-USonly}} but also available under a non-free Creative Commons license. I'm sure there are readers outside the United States who'd benefit from knowing that reuse is allowed, albeit with restrictions. Unfortunately, the only relevant licensing tags I can find are {{Non-free with NC and ND}} and {{Non-free file with no derivative works license}}, which assume the file has a non-free license tag.

Is there any good way to tag files with these licenses without putting them in Category:Wikipedia non-free files? Should we modify these templates so they can be used with PD-US files, or maybe create alternate versions of them? hinnk (talk) 08:20, 11 April 2025 (UTC)[reply]

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