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
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]
    100%, absolutely, this.
    People are like “Mass creation isn’t a problem because we blocked Lugnuts” and they forget that they either did nothing about Lugnuts or supported him, and that Lugnuts was only blocked in the end because of uncivil behaviour. FOARP (talk) 07:03, 12 April 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]
    "I do think prods/noms should provide evidence that a search was done in the native language" - I genuinely think this is a "nice to have", not a total requirement. Take for example Indian subjects - the likelihood is that if there is any information available at all, then it's going to be in English-language sources. Often the local version of the athelete's name isn't clear from the Romanisation of it that was pulled off Olympedia so it's not even clear what you are supposed to be searching in the local language.
    I would say that if there's no non-procedurally-generated local-language Wiki article to look at for sourcing (recalling that there are some wikis that have simply machine-translated large numbers of EN-wiki articles), and the Google search is coming up empty, then this is sufficient BEFORE for a database-generated article. FOARP (talk) 18:16, 12 April 2025 (UTC)[reply]
    This is why I support a requirement to search for sources in the place they are most likely to exist. Sometimes that will be in the local/native language of the subject, but not always. If you haven't looked where sources are most likely to exist then it is not reasonable to conclude that sources are unlikely to exist, let alone do not exist. Thryduulf (talk) 18:39, 12 April 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]
    ” properly review each article” - OK, and when are you planning to get started on doing that? Because as far as I can see it is *only* when deletion is proposed for these articles that anything is done at all. FOARP (talk) 07:07, 12 April 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]
I don't think a link to a listing that can't be found on GNIS would have complied with anything. and let's be clear: that "article" still isn't about anything notable and can just be covered in a list of Salinan place-names: the only sources are brief mentions, no WP:GNG pass needed for something without legal recognition.
And C46 "wrote" at least 135 articles that day (the ones that have since been deleted won't show up in this search) and simply flipped off anyone who tried to stop him. But hey, at least he left us with great articles like Guayusta, California and Tecolom, California before he got desysoped for incivility and retired under a cloud after reacting badly to people from the Persian wiki article pointing out that he his misguided mass-production of articles based on a total misunderstanding of the Iranian census was trashing their information space. FOARP (talk) 22:21, 12 April 2025 (UTC)[reply]
”you might have noticed that Lugnuts is blocked” - but not for mass creation, and only over the indifference/opposition of the defenders of his articles.FOARP (talk) 07:11, 12 April 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]
    @JoelleJay - Last I checked, which admittedly was some time ago, only a handful of those 33 were actually non-redirect articles brought back to main space after the draftification of these articles, and none of them had been done within the last 6 months. Basically, for all the protestation of the opponents that these were all GA-candidates-in-waiting, no-body cared once they were gone. FOARP (talk) 18:06, 12 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]
    You're assuming the existence of some benefit. You're assuming that a one or two-line article with bare-bones biographical information that can be easily obtained elsewhere (and was in fact scraped from other web sites) is somehow beneficial to readers. But the WP community has already had that discussion many times, and the consensus is found in WP:NOT: Wikipedia is not a directory. Specifically, Wikipedia should not have "Simple listings without contextual information showing encyclopedic merit." Stubs that fail to provide meaningful information provide no benefit and merely irritate readers.
    The point is that it takes a lot of valuable time, money, and energy to write decent biographical articles which touch upon all the key highlights of a person's education and career, like what I did for Roger J. Traynor. (For example, I majored as an undergraduate in history in one of the highest-ranked departments in the world, which means I took a modern American history course taught by a winner of the Pulitzer Prize for History.) Most people with the skills to do that well are already working on their doctorates or trying to get tenure (meaning they don't do it for free). So WP has to rely on the generosity of people like myself who have real jobs and volunteer in their spare time. And most volunteers prefer to write about winners, not losers. I never served in the U.S. military, but I always thought the Navy SEALs put it best: "It pays to be a winner". --Coolcaesar (talk) 01:32, 12 April 2025 (UTC)[reply]
    Yes, Simple listings without contextual information showing encyclopedic merit – such as telephone books, if you keep reading to the very next sentence – but it's not relevant because a stub about (e.g.,) an individual athlete is not a Wikipedia:Stand-alone lists, which is what that part of NOT says it's about. WhatamIdoing (talk) 02:23, 12 April 2025 (UTC)[reply]
    You're confusing whether an article is notable and whether an article has an editor ready to recreate it after it is already deleted. While its always nice when articles like this can be expanded to include more content, the Olympian bios always give contextual information showing encyclopedic merit -- it explains the athlete in question competed at the biggest sporting event in the world, which, although does not guarantee notability, is at least a reasonable claim to merit (i.e. not like, WP:A7 actionable). I agree that it takes a lot of valuable time, money, and energy to write decent biographical articles which touch upon all the key highlights of a person's education and career – and my point is, we should not be creating more work for our editors by deleting what we already have and hoping they can create it again, given that it either (a) results in a waste of editor time or (b) results in readers losing the information they could previously find. And most volunteers prefer to write about winners, not losers – remember that this is the Olympics we're talking about. For someone to qualify for the Olympics, especially in the modern era, they have to be a "winner" to begin with... BeanieFan11 (talk) 02:25, 12 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]
I have also been directed here after raising a couple of questions about the AfD process after a similar flood of 52 AfDs in an hour on a niche subject. My feeling is that as Wikipedia stands at present putting in a delete vote for an article should be a little more balanced. Someone should not be able to simply drop a template with minor tweaks into 52 articles in an hour and - by default or design - just leave the mess up to someone else - generally resulting in voter fatigue, and copy-and-paste votes winning the day. Even a checkbox-type form where someone ticks "I have checked the refs in the article", "I have checked GNews", "I have checked that this page cannot be merged to somewhere more suitable", etc. would stop it being so mechanical (with the Bundle Nomination function being a good call for situations where that sort of thing would be called for). I mean, IMHO it isn't actually that easy to create an article anymore, if they're not well-referenced they seem to be nipped in the bud very quickly by the excellent patrollers on that end. And if you really feel that a page does not belong on Wikipedia having to take 5 minutes to type out a more detailed rationale and verify that you've done BEFORE surely wouldn't be that much of a barrier?
It seems to me that a mechanism designed to curb spam, people making Wikipedia articles on girls they fancy and self-promotion now has the side effect of making it very, very easy for editors to quickly get rid of articles that through GF or BF they personally feel don't 'belong'. The above incident seems to have been done on Good Faith by a committed editor, with spotty Before seeming to be an innocent misunderstanding, but we've had users in the past who have blatantly been gaming the system. The former should be made aware of the work they are causing for other editors, and have to take some responsibility if they've not done it properly; the latter should be stemmed so they find something more constructive to do with their time.
I don't pretend to speak for anyone else, but participating in AfDs as they run has put me off actual constructive editing of Wikipedia as I could spent an afternoon sourcing up an article, and then if someone takes 60 seconds to slap a template on it without doing any basic checking first it can be deleted outright if I'm not on hand to provide additional sourcing. BoomboxTestarossa (talk) 16:14, 13 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]
  • Strongest possible oppose - Articles should be as deletable as they are creatable. Otherwise we are giving carte blanche to mass creators to flood the encyclopaedia with low quality stubs. FOARP (talk) 07:50, 12 April 2025 (UTC)[reply]
  • Oppose unless and until we have similar rate-limiting for mass creation, and articles that were demonstrably mass-created at a high rate have been substantively reviewed. Vanamonde93 (talk) 18:56, 12 April 2025 (UTC)[reply]
  • Strong oppose until there are equal rules for mass article creation. Let'srun (talk) 18:04, 13 April 2025 (UTC)[reply]
    @Let'srun, the policy on mass article creation says:
    • Any large-scale automated or semi-automated content page creation task must be approved by the community.[1][2] Community input may be solicited at WP:Village pump (proposals) and the talk pages of any relevant WikiProjects. Creators must ensure that all creations are strictly within the terms of their approval. All mass-created articles (except those not required to meet WP:GNG) must cite at least one source which would plausibly contribute to GNG, that is, which constitutes significant coverage in an independent, reliable, secondary source.[3]
  • ^ This requirement initially applied to articles but has since been expanded to include all "content pages", broadly meaning pages designed to be viewed by readers through the mainspace. These include articles, most visible categories, files hosted on Wikipedia, mainspace editnotices, and portals.
  • ^ While no specific definition of "large-scale" was decided, a suggestion of "anything more than 25 or 50" was not opposed.
  • ^ Wikipedia:Arbitration Committee/Requests for comment/Article creation at scale/Closing statement § Question 2: Should we require (a) source(s) that plausibly contribute(s) to WP:GNG?
    • Would you support a rule that says something similar? Maybe instead of "Any large-scale automated or semi-automated content page creation task must be approved by the community", it could say "Any large-scale automated or semi-automated nomination of articles for deletion must be approved by the community". Maybe instead of "While no specific definition of "large-scale" was decided, a suggestion of "anything more than 25 or 50" was not opposed", it would say "This means anything more than 25 or 50 AFDs" (possibly adding "per day" to both of them). Perhaps instead of "All mass-created articles...must cite at least one source which would plausibly contribute to GNG, that is, which constitutes significant coverage in an independent, reliable, secondary source", it would say "All mass-nominated articles must include a description of the nominator's WP:BEFORE search, including for subjects associated with a particular place or culture, a description of a search in the relevant language or national newspapers".
      I think that a parallel set of rules would be fine. WhatamIdoing (talk) 00:57, 14 April 2025 (UTC)[reply]
      No, because article-creation and AFDs/PRODing are not equivalent. Once articles have been mass-created, they are on the encyclopaedia without any further consensus being required, and only a laborious process can remove them. In contrast each PROD is subject to being removed by any editor for any reason and can still be declined by the admin, similarly AFDs still require a consensus to go ahead after having been brought.
      Additionally, it has to be noted that MASSCREATE simply hasn't been enforced 95%+ of the time, and instead only ever serves (if it serves at all) to be a retrospective behaviour rule. FOARP (talk) 08:24, 14 April 2025 (UTC)[reply]
      Let'srun said they opposed limiting mass AFDs until there are equal rules for mass article creation. I'm trying to understand whether they would support limits on mass AFDs that parallel the existing limits on mass article creation, using (as close as seemed to make sense) the same words as the limits on mass article creation. WhatamIdoing (talk) 22:23, 14 April 2025 (UTC)[reply]
      As for the lack of enforcement... Earlier, an editor said they thought someone was violating mass create right now, but my direct suggestion that they take that complaint to ANI for enforcement of MASSCREATE rules appears to have not interested them. Perhaps we don't agree with Wikipedia:Policies and guidelines#Enforcement? Perhaps it felt like a minor or technical violation, rather than a serious problem? Perhaps we like whingeing? I don't know, but I do know that there's nothing stopping you from monitoring for MASSCREATE violations and reporting all of them, whenever you want to. WhatamIdoing (talk) 22:26, 14 April 2025 (UTC)[reply]
      I would have to see a concrete proposal, but I think that the issues resulting from mass article creation are different than the issues resulting from mass AfDs and PRODs and as such a equalivant policy dealing with them isn't what is needed. With mass article creation, they are on the encyclopedia permanently save for a user bringing forth a PROD or AfD, which takes up valuable community time. Part of the issue is that the policy on mass article-creation did not address the articles which had been mass created previously, and they have effectively been grandfathered into place with a utter lack of WP:SIGCOV. Let'srun (talk) 23:39, 14 April 2025 (UTC)[reply]
      Any limit on PRODs/AfDs needs to be based on the number of concurrent nominations not a per day figure, and 50 concurrent nominations would make it impossible to give most of them a proper review if they are at all complicated. 50 articles about contemporary American pop culture, likely no problem as if sourcing exists it will be trivially findable. Even doing a proper BEFORE for 50 articles about Brazilian scholars active in the 19th century, Kazakh bandy players active in the 1980s or railway stations in India built in the 1910s would take more than a week. Thryduulf (talk) 10:21, 14 April 2025 (UTC)[reply]
      So if the goal is equal rules for mass article creation, then you'd suggest limiting both AFD noms and article creations to 50 per week for a given (narrow) subject area (e.g., "Brazilian scholars active in the 19th century", not "biographies"). WhatamIdoing (talk) 22:27, 14 April 2025 (UTC)[reply]
      "Equal rules" isn't my phrasing, and I'm not sure its a particularly helpful one. As noted, I believe deletion limits should be set in terms of concurrent nominations (not every nomination lasts exactly one week), but this is not a concept that is meaningful for article creation. Thryduulf (talk) 23:21, 14 April 2025 (UTC)[reply]
      If limits were to be put into place, that would be the way to do it, considering that with the lack of activity at AfD many nominations are relisted for multiple weeks. Let'srun (talk) 23:41, 14 April 2025 (UTC)[reply]
      I think AFD might have less of a "lack of activity" and more of a "spirit of timidity". Someone checked a while ago, and AFD has gone from (if memory serves) an average of three editors up to an average four editors in recent years. But we seem to be more likely to re-list nominations that "only" have two or three responses now than we used to. WhatamIdoing (talk) 01:25, 15 April 2025 (UTC)[reply]
      "Equal rules" was a direct quotation from Let'srun's comment. WhatamIdoing (talk) 01:27, 15 April 2025 (UTC)[reply]
      And while I probably could have phrased that better, my point was more that a rate-limit would allow for low-quality stubs (which may not be entirely accurate in some cases) to remain even when there is no evidence that whoever created them checked the same sources that certain editors insist much be checked before we considering deleting them or redirecting to another article. Let'srun (talk) 03:02, 15 April 2025 (UTC)[reply]
      I don't think I've seen anyone demanding a WP:BEFORE search prior to a redirect. IMO it wouldn't hurt Wikipedia or its readers if quite a lot of (e.g.,) two-sentence 20th-century Olympian stubs got redirected to a nice little table in a List of 1952 Olympic athletes from Ruritania.
      Strictly speaking, it doesn't even require a discussion, as boldly Wikipedia:Merging articles is permitted, and there's already consensus in principle, as merging up apparent Wikipedia:Permastubs is WP:MERGEREASON #3. But anyone who wanted to do that could also start a discussion, wait a week, notice the (likely) absence of any responses, and then merge as "no opposition". WhatamIdoing (talk) 05:33, 15 April 2025 (UTC)[reply]
      Great! But then what happened when we actually tried to do this? *PLOT TWIST* The same people who obstruct every deletion and insist it be examined in exquisite detail obstruct that too. We had a consensus to redirect Lugnuts Turkish "village" articles, but the redirection has been steadily undone. FOARP (talk) 07:28, 15 April 2025 (UTC)[reply]
      Systematically, by one or two editors, or just a case of every now and again, someone splits off a specific article? WhatamIdoing (talk) 22:07, 15 April 2025 (UTC)[reply]

    Did I miss where this became a formal RfC? In any case, I also oppose any rate limits on Prods and AfDs as long as there are so many sub-stubs with no reliable sourcing with little or no chance of being improved in the next few decades. - Donald Albury 20:07, 13 April 2025 (UTC)[reply]

    The surest way to ensure that a stub is not improved is to delete it without giving people sufficient time to determine whether reliable sourcing exists or not. Coincidentally this is also the surest way to ensure that articles about notable topics which can be improved are not improved, thus harming the encyclopaedia. Thryduulf (talk) 20:11, 13 April 2025 (UTC)[reply]
    Hard disagree: it allows the article to be re-created by someone who is actually here to build an encyclopaedia rather than rack up article creation scores. FOARP (talk) 08:25, 14 April 2025 (UTC)[reply]
    Do you have any evidence at all for that sweeping assumption of bad faith? Thryduulf (talk) 10:13, 14 April 2025 (UTC)[reply]
    I direct counsel's attention to the entire editing history of Lugnuts and Carlossuarez46. Particularly the way that Lugnuts posted a link to every thousandth "article" (half of which are now red-links or redirects) to his user page and clearly had the list of top article-creators on watch-list (he would quickly respond to anything posted on the talk page there).
    I also have to ask why this is news to you: You were active on the AN and ANI pages on the days when Lugnuts came up there, sometimes being involved in the discussions directly above and below his. Did you just not notice him coming up there?
    Negligent mass-creation is clear WP:NOTHERE behaviour. A small number of editors got away with it for years in large part because any time anyone tried to do anything about it they were flipped off and faced a wall of indifference and hostility from other editors happy to turn a blind eye to, for example, the entire Persian wiki information space being trashed by tens of thousands of fake "village" articles that we are still trying to clean up. FOARP (talk) 07:25, 15 April 2025 (UTC)[reply]
    • Support for both AFD and PROD for different reasons: in the case of AFD, if you have a group of related pages which should be deleted for the same reason, you should make a group nomination as opposed to a separate discussion for each. The number of pages per AFD should be unlimited. In the case of PROD, the process depends on the number of PROD articles at any given time being low en6such that they will all be reviewed by multiple users before the PROD expires. Animal lover |666| 19:04, 14 April 2025 (UTC)[reply]

    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]

    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 • {CX}) 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]

    Does !voting with simply the words "Support/oppose per user" violate WP:VOTE?

    I'm coming to ask this question here because I've seen this interaction happen frequently enough that I now want to clarify with other more seasoned editors.

    I would say that at least once or twice per week, across areas ranging from WP:CTOP talk pages to AfD to ITN, I will see an interaction which essentially goes like this:

    Proposal to use X and not Y

    Based on [insert here] reasons, I think that the article should say X and not Y, and am seeking consensus. Signed, UserNominator

    • Oppose Based on the detailed rationale that the article should say Y, for policy reason WP:WIKIPEDIA, as opposed to saying X. DetailedWriter
    • Oppose per Detailedwriter. Signed, PerUserGuy.
    • Support For separate reasons than the nominator based on WP:ABOUT, I support this proposal. NotAVoter99
    • Support per nom. AgreeingGal
    AgreeinGgal, this is a consensus discussion, not a !vote. You need to explain your rationale and address the opposing arguments, or this comment will not be weighed when assessing the consensus. DetailedWriter

    WP:VOTE states that "It serves as a little reminder of the communal norm that it is "not the vote" that matters, but the reasoning behind the !vote that is important [...] A "vote" that doesn't seem to be based on a reasonable rationale may be completely ignored or receive little consideration, and a discussion close may be escalated to wider attention if it appears to have been treated as a simple vote count. It is important therefore to also explain why you are voting the way you are. I'm curious how administrators assessing for consensus reconcile this with our widespread community practice of "Per User" rationales.

    On the one hand, merely adding two words "per X" doesn't really seem to meet the spirit of WP:VOTE, which calls for users to provide explanation. I can also see how it might be difficult for the closer if there are 7 supporters and 3 opposers, but the 3 opposes wrote out detailed rationales while 6 of the 7 supporters only wrote "per nom".

    On the other hand, if a prior user in the discussion applies policy correctly and explains themselves well, it seems a little silly to require a subsequent user to re-word and re-phrase the already well-stated rationale in order to have their opinion considered in the consensus assessment. Also, "per nom" is indeed a rationale: it is a more efficient way of saying "This user stated a strong argument for Y over X that I agree with it because of reasons 1, 2, and 3" (which is simply writing back out the full rationale of the prior user in your own words).

    So, to put it succinctly: when I am contributing to a consensus discussion and agree with the rationale someone has already said, should I be restating what they said in my own words to meet WP:VOTE? Or does the community accept the two-word rationale "per User" an a valid rationale? FlipandFlopped 21:41, 12 April 2025 (UTC)[reply]

    When closing I give "per x" responses the same weight as the response they're referencing. There's no need to repeat an argument or post. People cite essays in their !votes for the same reason. ScottishFinnishRadish (talk) 22:10, 12 April 2025 (UTC)[reply]
    I think the proposer is basing this on editirs at RFC who vote for Keep based on an argument that a previous editor put down, but doesn't meet rules or guidelines of wikipedia that someone had already challenged. For example footballers or cricketer stubs at AFD - with keep votes stating notable when clearly are not. Davidstewartharvey (talk) 06:07, 13 April 2025 (UTC)[reply]
    The counter point there would be that editors may not agree with the challenge, and so still support the original argument. -- LCU ActivelyDisinterested «@» °∆t° 12:44, 13 April 2025 (UTC)[reply]
    And then you have the issue with editors pointing out that their argument does not meet rules/guidelines and get accused of bludgeoning! Davidstewartharvey (talk) 05:13, 14 April 2025 (UTC)[reply]
    This is probably the least bad option. The alternative is each new !vote rewriting the same comment with different wording. Thebiguglyalien (talk) 🛸 00:40, 13 April 2025 (UTC)[reply]
    I agree with DetailedWriter's !vote 100% and have nothing to add. Why should I find different words to say the same thing? Even if I agree 100% and have something to add, I can !vote "Oppose per DetailedWriter. [something to add]." ―Mandruss  IMO. 06:18, 13 April 2025 (UTC)[reply]
    IMO the rationale is mostly not for the closer, it's for other participants in the discussion. The closer's job is to reflect what the discussion agreed on and so should generally not discard !votes for their rationale alone unless it's super clearly false (e.g. "no source says X" when the other side has several quotes from good sources that say X) or against policy.
    If a lot of participants seem to think a given rationale is strong than for the purposes of the discussion it's strong, even if it's short and even if the closer personally thinks it's dubious. Loki (talk) 06:32, 13 April 2025 (UTC)[reply]
    When a closer sees people !voting “per user:so-and-so” they know that these people found so-and-so’s comments persuasive. The closer should go back and read so-and-so’s comments again.
    However, that does not mean so-and-so’s comments “win”. Consensus isn’t a vote. The closer should also pay attention to any comments that attempt to refute or rebut what so-and-so said (especially if the refutation/rebuttal is based on policy). Blueboar (talk) 15:12, 13 April 2025 (UTC)[reply]
    Strongly disagree with this, at least as written. It's a closers job to weight comments with regards to policy and no matter how many people make them, non policy based rationales can and should be disregarded when assessing the consensus (at least assuming there's not a complete absence of policy in the area). Scribolt (talk) 07:22, 15 April 2025 (UTC)[reply]
    There are definitely cases where a closer should strongly deweight or ignore certain votes, but in those cases it's usually blindingly obvious that it's correct to do so. E.g. if there's a ton of new WP:SPAs on one side that seem to have been canvassed from off-wiki a closer should ignore them.
    But consensus really does just mean "general agreement", and so absent that sort of concerted attempt to manipulate the consensus from outside, the job of the closer is to figure out if the discussion agreed on something, and if so what. I fear that the presence of a few lines designed to protect Wikipedia from outside attacks like "consensus is not a vote" and "consider the strength of the arguments" are starting to outweigh the basic facts of what consensus is in the minds of editors. A closer is not a WP:SUPERVOTEer and their job is not to decide which arguments are stronger based on some sort of view-from-nowhere, it's to decide which arguments in this specific discussion convinced the most people.
    Which is to say, if a bunch of people familiar with Wikipedia policy thought one argument was stronger, the closer's opinion on that issue doesn't matter. Many content disputes originate from conflicting opinions on policy and the job of the closer is not to judge which arguments were policy-based based on their own personal opinion, it's to decide which interpretation of policy the discussion ended up agreeing on. Loki (talk) 21:34, 15 April 2025 (UTC)[reply]
    • WP:VOTE is an essay, so it can't really be "violated". — xaosflux Talk 15:17, 13 April 2025 (UTC)[reply]
    • I find it amusing that DetailedWriter pushes back on AgreeingGal's "Support per nom" but doesn't challenge PerUserGuy's "Oppose per Detailedwriter". Schazjmd (talk) 16:11, 13 April 2025 (UTC)[reply]
      Haha, yes, that was intentional. It made the interaction a little more realistic, LOL. FlipandFlopped 04:40, 14 April 2025 (UTC)[reply]
    • eh? what's so bad about them? it only really means someone agree with someone else, and if this is addressed but votes of that nature keep coming in, it only really means they still agree with the editor they're voting per. this is something i don't think there's any need to change, since it's not even on the more incomprehensible side of wp lingo
    of course, this doesn't necessarily mean any rationale automatically wins or loses because someone used the p word, nor does it automatically validate or invalidate any given vote. of course, there are the relatively common problematic votes, but that has nothing to do with them being per someone. in the end, i guess this means oppose, with the caveat that i'm not even entirely sure what the problem is supposed to be
    unless it's about usernominator, who is a menace we should all run from as fast as we possibly can or, preferably, surrender to, knowing that our days are already over, then this is fair game consarn (prison phone) (crime record) 11:10, 14 April 2025 (UTC)[reply]
    consarn, I've seen it happen multiple times where folks make either pointed comments, or post general warnings, when there are a lot of "per [user]" type !votes on the basis that they lack a proper rationale. This confused me, and it's helpful to have clarification that the community takes no issue with the "p word". FlipandFlopped 16:27, 15 April 2025 (UTC)[reply]
    i blame usernominator, they might as well be wikipedia's thelegend27 consarn (prison phone) (crime record) 17:14, 15 April 2025 (UTC)[reply]
    A support/oppose vote per user is basically a statement that said user has expressed the voter's rationale well enough. As such, it is a properly-reasoned vote. Animal lover |666| 19:09, 14 April 2025 (UTC)[reply]
    • Per votes aren't a problem for WP:VOTE, per Animal lover and Blueboar and others No but really, if someone else has already articulated your position well, there is no reason to waste words reiterating. Consensus isn't a vote, neither is it a word count measuring contest. "Per User:X" is a great way to express that you found someone's reasoning compelling, which is an important part of the consensus process, since one of the ways you can tell an argument is well-reasoned is that others understand it and are persuaded by it. Even when your position is more nuanced, saying "per so-and-so, except/and also/despite..." simplifies the comprehension task for closers and other participants. -- LWG talk 23:20, 14 April 2025 (UTC)[reply]
    @LWG: but it does not tell you that others understand it. They don't even need to have read the comment or all of it, they can just write "Keep per User L." You would need a longer comment to know whether they understood it or not. Horse Eye's Back (talk) 19:49, 15 April 2025 (UTC)[reply]
    "need" is a strong word, because sometimes the simplest arguments are the best, and tacking more words into "i found no sources :(" is kind of unnecessary consarn (prison phone) (crime record) 20:00, 15 April 2025 (UTC)[reply]
    Need applies to the ability to establish understanding. A simple "I agree with argument Y" can not demonstrate that I understand argument Y. Horse Eye's Back (talk) 23:44, 15 April 2025 (UTC)[reply]
    • per user is fine, you're expressing that you agree with their argument as stated and the weight the closer puts on your comment should be equivalent to the original (for better or worse). Scribolt (talk) 07:22, 15 April 2025 (UTC)[reply]
    • The purpose of Consensus is to find agreement, so various expressions of agreement (viz. 'I agree with Sara', or 'per Sara') should be expected. Alanscottwalker (talk) 17:07, 15 April 2025 (UTC)[reply]
    • It all depends on context, in general I don't think its prohibited or anything like that but I also don't in general think its a very smart or helpful way to contribute. That being said closers really shouldn't be counting them for anything, the strength of an argument doesn't change no matter how many people offer simple agreement or disagreement. Horse Eye's Back (talk) 19:45, 15 April 2025 (UTC)[reply]
      The strength of an argument is all about how many people agree or disagree with it. The goal is to figure out if there's a consensus, which is not a jargon word here: it really does just mean "general agreement" same as it always does. Obviously knowing how many people agree is crucial to knowing if there is general agreement. Loki (talk) 21:24, 15 April 2025 (UTC)[reply]
      "The strength of an argument is all about how many people agree or disagree with it" what you are describing is a popular vote, not a consensus. In a consensus the argument that bears out may not be the one which most people agreed with, thats kind of the whole point. Horse Eye's Back (talk) 23:41, 15 April 2025 (UTC)[reply]
      Consensus is indeed a jargon word on English Wikipedia, as in the real world, consensus decision-making means everyone is willing to go along with a decision. However I don't agree with the view that "In a consensus the argument that bears out may not be the one which most people agreed with." While on English Wikipedia, it can be true that arguments with majority support can be superseded, it's isn't due to English Wikipedia's consensus-based decision-making traditions, but because of arguments being counter to existing guidance that has stronger community support. isaacl (talk) 02:00, 16 April 2025 (UTC)[reply]
    • If you can't agree with someone who said exactly what you would have said, what's the point of a discussion at all? --SarekOfVulcan (talk) 20:34, 15 April 2025 (UTC)[reply]
    • At RfD per X comments are very common for all four of the most common outcomes (keep, delete, retarget, disambiguate) and frequently nothing else needs to be said. Sometimes the editor who wrote the comment being endorsed has done a detailed analysis that needs no further explanation (e.g. Wikipedia:Redirects for discussion/Log/2025 April 13#Hungarian Horntail), other times its a simple expression of opinion that can be fully endorsed without need for further explanation (e.g. Wikipedia:Redirects for discussion/Log/2025 April 12#Fire in the hole!). There is no reason to treat these with lesser weight than if the editors had used more words. If you are not certain that someone has understood then you can ask them about it specifically. Thryduulf (talk) 20:51, 15 April 2025 (UTC)[reply]

    Default thumbnail size changing from 220 to 250px

    Hello! A bit over a year ago, this noticeboard hosted an RfC, and consensus held to increase the default thumbnail size on Wikipedia from 220 to 250 pixels. That became a Phabricator task. It took a while to implement, for various complicated technical reasons I don't really understand, but with the deployment of CodeMirror 6, this has been completed and is being rolled out! See the Phabricator task and the recent Tech News for more details. No action is required from us - just an update on a long-discussed change! —Ganesha811 (talk) 16:52, 13 April 2025 (UTC)[reply]

    This actually requires changes to all the images that use |upright= as the scaling they use are all based on the old thumbnail size, and will need to be corrected. -- LCU ActivelyDisinterested «@» °∆t° 23:27, 15 April 2025 (UTC)[reply]
    Probably they won't - most are too small anyway, & I believe "upright" doesn't affect the majority of our readers on mobiles. Assuming all upright images need re-scaling would be a mistake. Johnbod (talk) 23:31, 15 April 2025 (UTC)[reply]
    Images should be no more 300px in the lead or 400px in the body of the article, MOS:IMAGESZ. That was 1.3 and 1.8, and is now 1.2 and 1.6 scaling. No discussion was had about changing those figures. -- LCU ActivelyDisinterested «@» °∆t° 23:53, 15 April 2025 (UTC)[reply]

    FYI: Commons Discussion on Supposed CCTV Copyrights

    Just wanted to bright to users' attention that I've opened up a discussion on Commons about whether CCTV images and video should be copyfree. Anyone is welcome to participate. -- Veggies (talk) 22:09, 13 April 2025 (UTC)[reply]

    i have one. 173.206.111.217 (talk) 22:27, 15 April 2025 (UTC)[reply]

     You are invited to join the discussion at Wikipedia talk:Speedy keep § Low-effort mass nominations. HouseBlaster (talk • he/they) 03:08, 15 April 2025 (UTC)[reply]

    Technical

    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]
    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. @Nosferattus Flyingphoenixchips (talk) 18:10, 13 April 2025 (UTC)[reply]
    As someone that's dealt with predatory journals, the best way to find them used on Wikipedia is probably WP:CITEWATCH (pages 2+ especially, page 1 has a lot of corner cases). I also maintain the WP:UPSD script. That said
    1. Lack of DOI, especially for new journals published after 2000, is a fairly strong sign that a journal might be predatory. Older journals without DOIs just might not have been online and stopped publishing. Of course plenty of exceptions exist.
    2. Plenty of predatory journals have DOIs. When that's the case, it's often with a DOI prefix over 10.10000+/.... Of course plenty of exceptions exist. OMICS for example, has a DOI prefix of 10.4172/...
    3. Having a PDF is completely irrelevant either way.
    Headbomb {t · c · p · b} 19:15, 13 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]
    Wrong section? jlwoodwa (talk) 15:48, 12 April 2025 (UTC)[reply]
    Sorry replied in the wrong section 😭 Flyingphoenixchips (talk) 16:52, 12 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]

    add button to visual editor

    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]

    Wikipedia down?

    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]
    Excellent, self-DOS. Izno (talk) 16:59, 11 April 2025 (UTC)[reply]
    I don't think that's entirely fair. These are big complicated systems. Stuff happens. Take a look at the example I gave just below. I made a trivial mistake in my query which caused a 20,000x performance hit. Fortunately, the quarry database is sufficiently isolated from production that I assume I only caused a problem to other quarry users. RoySmith (talk) 17:26, 11 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]
    Hi, I was having the same issue with prosesize (although in my case it's been down for over a year and displays no output at all after freezing). I tried your script and it worked, but would it be possible for the output to be displayed with greater accuracy i.e. the number of bytes instead of just 2 kB or 3 kB? AryKun (talk) 11:47, 15 April 2025 (UTC)[reply]
    @AryKun Sure, I updated it to show both. Polygnotus (talk) 11:56, 15 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]

    The official gadget (MediaWiki:Gadget-Prosesize.js) uses a Toolforge thing under the hood. A request would look like https://prosesize.toolforge.org/api/en.wikipedia.org/Foobar but if that isn't available there is a fallback so I am surprised that it does not work. Polygnotus (talk) 12:22, 15 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]
    You can't, but you can toggle it on or off whenever you want, which should be a simpler thing to do than trying to highlight text. There should be a dark mode selector on the appearance menu on the page, if you collapsed that menu look for the symbol that looks like eyeglasses at the top of the screen. — xaosflux Talk 17:50, 11 April 2025 (UTC)[reply]
    Thank you, found it. This was helpful and I will do that in the future. Fun Chaos (talk) 20:27, 11 April 2025 (UTC)[reply]
    Generally speaking, anything is permitted on user pages, unless explicitly prohibited by WP:UP#NOT. That section does not mention accessibility, colour, contrast or dark mode. --Redrose64 🌹 (talk) 19:31, 11 April 2025 (UTC)[reply]
    For what it's worth, the markup on that page is flagged by Linter's night-mode-unaware-background-color option: [8]. Matma Rex talk 21:56, 11 April 2025 (UTC)[reply]

    VisualEditor is broken for me

    I could barely add this topic in, since it uses VisualEditor which is broken for me. More details in this link: [9] (imgur)

    Problems with Tables in the paragraph below: Blitzkriegfree (talk) 18:49, 11 April 2025 (UTC)[reply]

    Have you tried using a different web browser? Or loading in a private window? You could also try disabling any browser extensions that might be interfering. --Chris 06:57, 12 April 2025 (UTC)[reply]
    Alright, it works on Chrome. I think it's broken for FireFox. Disabling browser extensions, or editing in private mode did not help. I hope it will work again someday.
    I will now ping user:Cremastra, as they also expirenced the same issues. {{Ping|Cremastra}} Blitzkriegfree (talk) 12:32, 12 April 2025 (UTC)[reply]
    That will not have notified anybody, least of all Cremastra, who I have now notified. More at WP:MENTION. --Redrose64 🌹 (talk) 13:51, 12 April 2025 (UTC)[reply]
    Thanks. Cremastra talk 13:58, 12 April 2025 (UTC)[reply]

     You are invited to join the discussion at Wikipedia:Village pump (proposals) §a few standards. Thryduulf (talk) 15:07, 12 April 2025 (UTC)[reply]

    Template:Chem generating line breaks

    Hi,

    the {{chem}} template currently generates HTML that includes line breaks:

    <span class="chemf nowrap">CO<span class="nowrap"><span style="display:inline-block;margin-bottom:-0.3em;vertical-align:-0.4em;line-height:1em;font-size:80%;text-align:left"><sup style="font-size:inherit;line-height:inherit;vertical-align:baseline"></sup><br /><sub style="font-size:inherit;line-height:inherit;vertical-align:baseline">2</sub></span></span></span>

    So when one copies and pastes from a Wikipedia article into plaintext, one gets results like this (from Naked mole-rat § Metabolism and respiration where I noticed it):

    It can live in an atmosphere of 80% CO
    2 and 20% oxygen.
    

    That's a bit annoying and surely avoidable, as the {{chem2}} template does not have the same quirk. Could someone who knows what they're doing take a look? Cheers!

    - 2A02:560:4D16:1800:9905:C7AA:90CA:BB25 (talk) 16:19, 12 April 2025 (UTC)[reply]

    Generated by Module:Su. Izno (talk) 17:28, 12 April 2025 (UTC)[reply]
    See Template:Su#Line breaks. — Qwerfjkltalk 17:53, 12 April 2025 (UTC)[reply]
    Thanks, both! I looked at the code for both templates, and the difference stems from these two approaches to stacking super- and subscripts, AFAI can tell:
    • {{chem}}, via the invoked module
      • generates (without the text formatting) SO<span style="display:inline-block"><sup>2-</sup><br /><sub>4</sub></span>
      • which displays as (with the text formatting) SO2−
        4
      • and plaintext-pastes as SO2−
        4
    • {{chem2}}
      • generates SO<span style="display:inline-block"><span style="display:block">2−</span><span style="display:block">4</span></span>
      • which displays as SO2−4
      • and plaintext-pastes as SO2−4
    - 2A02:560:4D16:1800:9905:C7AA:90CA:BB25 (talk) 18:53, 12 April 2025 (UTC)[reply]
    Why is {{su}} implemented in a module? The module seems to provide functionality that could be trivially implemented in wikitext. 86.23.109.101 (talk) 21:15, 13 April 2025 (UTC)[reply]
    See Template talk:Su#Conversion to Lua. * Pppery * it has begun... 21:33, 13 April 2025 (UTC)[reply]

    Active users at Category:User languages

    How I can see users from language category that been active in current month? For example, most users at Category:User gsw-4 was active 2-3 or 10 years ago, which is kinda useless information. Eurohunter (talk) 10:46, 13 April 2025 (UTC)[reply]

    Also the same thing but for those who are members of a wikiproject, ideally weighted to those with the most edits. Polygnotus (talk) 12:54, 13 April 2025 (UTC)[reply]
    This should probably be moved to WP:SCRIPTREQ or, preferably, WP:BOTREQ. Polygnotus (talk) 13:09, 13 April 2025 (UTC)[reply]
    True, but I have a database query for users who have done edits in the last three months here. Doesn't notice whether have performed logged actions such as issue thanks or blocking. William Avery (talk) 14:10, 13 April 2025 (UTC)[reply]
    @William Avery I think that usually people want to know "who should I contact" which means that a user with 1 edit who edited 1 second ago is a worse option than a user with 180.000 edits who edited 3 days ago. Polygnotus (talk) 15:49, 13 April 2025 (UTC)[reply]
    You can use this script. – DreamRimmer (talk) 17:58, 13 April 2025 (UTC)[reply]

    Modern JavaScript is an error?

    If you look at for example User:Andrybak/Scripts/Contribs ranger.js then Wikipedia claims that script contains 129 errors.

    Is the thing that checks for errors very outdated? It may be JSHint and I don't see any releases post 2022.

    If so, can we change the CodeEditor to use something more modern?

    I see T250315 so I'll ping @ESanders (WMF):. Polygnotus (talk) 13:05, 13 April 2025 (UTC)[reply]

    Running ESLint is technically possible but quite complex, I'm not sure who will be able to prioritise it in the near future. ESanders (WMF) (talk) 16:27, 13 April 2025 (UTC)[reply]
    @ESanders (WMF) This is not the worst problem ever™, but it can be quite annoying when messing about with JavaScript because JSHint keeps warning you of errors that do not exist. Is there maybe an alternative to ESLint that is easier to implement? Polygnotus (talk) 18:07, 13 April 2025 (UTC)[reply]
    It may be (?) related to the fact that what's here signaled are private identifiers, which are added in ECMA2026. — Alien  3
    3 3
    19:46, 13 April 2025 (UTC)[reply]
    The most recent version supported is ES 2016, see phab:T381537. Snævar (talk) 07:50, 14 April 2025 (UTC)[reply]
    If by errors you mean when you go to edit the page, which no one else can, that is strictly identified by the syntax highlighter, which in this case is Ace AFAIK. It simply has not been updated for newer syntaxes yet. (Such issues are relevant when editing CSS as well, e.g. phab:T263852.) The final says on whether a script is valid is the ResourceLoader checker + minifier, for when a script is loaded as a gadget, and your browser.
    My understanding, based on conversation with a relevant volunteer dev, is that phab:T250315 is particularly difficult, and that Ace does not provide the necessary APIs so it would be a lot of developer overhead to support something like that.
    Ace may be removed in favor of CodeMirror at some date, see e.g. activity with phab:T373711. Izno (talk) 22:20, 13 April 2025 (UTC)[reply]

    Range block calculator?

    I used to use this tool to calculate IP ranges for potential blocks, but now I'm getting a 'not found' error. Has it moved, or been replaced with something else, or just died a dignified natural death, does anybody know? Thanks, Justlettersandnumbers (talk) 19:46, 14 April 2025 (UTC)[reply]

    @Justlettersandnumbers: https://nativeforeigner.com/calc/ GMGtalk 19:49, 14 April 2025 (UTC)[reply]
    {{IP range calculator}} also exists. Izno (talk) 20:24, 14 April 2025 (UTC)[reply]
    It looks like the original moved to https://ftools.toolforge.org/general/ip-range-calc.html (and the template that Izno links to has a "See also" link to an alternative at https://galaxybots.toolforge.org/iprangecalculator, and via m:Toolhub there's yet another alternative at https://iprange.toolforge.org/) HTH. Quiddity (talk) 20:29, 14 April 2025 (UTC)[reply]

    Tech News: 2025-16

    MediaWiki message delivery 00:21, 15 April 2025 (UTC)[reply]

    Regarding the first item about the default thumbnail size, please see Wikipedia talk:Image use policy#Displayed image size. --Redrose64 🌹 (talk) 08:07, 15 April 2025 (UTC)[reply]

    Proposals

    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]

    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. Sdkbtalk 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(VTE) 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]
      In any way that you wish is in fact not the truth, because that leads to edit warring with the bot. Good luck with your interpretation if the bot's approach becomes consensus. Izno (talk) 16:09, 12 April 2025 (UTC)[reply]
      Editing one part of something a bot does that is still within the MoS will not lead to a block, unless the admin rally wants to be dragged to ANI for overstepping any reasonable grounds of behaviour. There is nothing in the RfC that means titles can be unlinked or that all titles must be linked. The MoS says differently and there is nothing in the RfC that will change that. It’s certainly not edit warring either: it’s entirely within WP:BRD to delink the names. I’m not sure why you’re so keen to block people for editing within the bounds of the MoS and our existing editing guidelines, but I hope you try and look at this more rationally before you act. - SchroCat (talk) 16:49, 12 April 2025 (UTC)[reply]
      As I said, good luck with your interpretation. Izno (talk) 19:59, 12 April 2025 (UTC)[reply]
      My “interpretation” of the MoS and the project norms of editing are the commonly accepted ones. I’m not the one trying to stretch a possible consensus on one bot’s actions to cover an entirely different part of the MoS. - SchroCat (talk) 20:28, 12 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]
    Yes they would. Linked redirects that are tagged with {{R from misspelling}} appear on Wikipedia:Database reports/Linked misspellings, which then can be fixed. Gonnym (talk) 07:57, 13 April 2025 (UTC)[reply]
    The bot wouldn't add wikilinks to misspelt names unless it was coded to recognise them, in which case it may as well just fix the spelling. Traumnovelle (talk) 23:07, 13 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]
    2B - as a reader, my preference is for the work to be wikilinked whenever it can be. This link leads me to an article where I can learn more about the publication and its reliability, which is a crucial and core service of Wikipedia. Helping readers assess the reliability of a work helps readers assess the reliability of a citation and thus the accuracy of a Wikipedia article.
    The URL to the work is not a substitute for information about the publication; more information about the publication will often be available in a Wikipedia article about the publication than on the publication's own website (which will inevitable have a pro-publication bias).
    Wikilinking the work field in every reference is important, even though that results in repeated wikilinks in the reference section. To understand why, first remember that the vast majority of readers read on a mobile phone. Next, take out your phone and browse (in default mobile mode, not desktop-on-mobile mode) to any article and click on any reference. Note how it just shows you the one reference you clicked on--it doesn't take you to the references section the way desktop mode does. If that one reference you clicked on doesn't have the work wikilinked, you won't see another wikilink on your screen. Even on desktop mode, in articles that have hundreds of references (which most highly read articles do), if the one you clicked on doesn't have a wikilink to the work, it can be hard to find that link amongst the hundreds of other references listed. For both mobile and desktop users, it's important that the work field be linked in every citation. Levivich (talk) 15:46, 13 April 2025 (UTC)[reply]
    • 2A would be preferable to prevent further fighting. I appreciate the attention to cleaning up citations, but it would be jarring to introduce linking inconsistency to an otherwise stable article, all at the hand of a bot without a human to sign off on every edit. SounderBruce 00:10, 14 April 2025 (UTC)[reply]

    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. Sdkbtalk 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]
    I don't know about China in particular, but we've had issues with setting bots to work using official census data that turned out to include a lot of statistics tied to census dropoff locations that are not standalone places. In particular, this was a problem for Iran and Russia, with the former listing gas stations and convenience stores as census locations, and the latter assigning arbitrary geolocations in rural areas where there are no distinct populated settlements. I would be very hesitant to do any automated locality-article creation unless the datasets have first been vetted by editors fluent in the language and familiar with the country in question, and at that point the benefits of automation in terms of time saved would likely be marginal. signed, Rosguill talk 15:57, 12 April 2025 (UTC)[reply]
    Lsjbot is possibly the worst thing that ever happened to Wikipedia. Because of it we have about 10 million out-of-date, rotting stubs that are full of bogus information from low-quality self-published databases and will never be updated or maintained. Even worse, the 10 million junk articles have polluted Wikidata and other projects due to efforts to synchronize content (e.g. Joopwikibot on Vietnamese Wikipedia). So now in Wikidata we have entries for places and taxa that never actually existed but are impossible to remove since they have articles in 3 or 4 different wikis (two of which are ghost towns), all created by Lsjbot. Please don't let this happen again. Nosferattus (talk) 18:26, 13 April 2025 (UTC)[reply]
    Agreed that Swedish wiki bot articles are hideous and that there are potential problems. The Demographics bloat in US place articles are also hideous due to the generic bot generation and 2010 and 2020 updates. But with a country like China, articles run the risk of being a mess and inconsistent without at least some sort of organized manual approach. Any thoughts Markussep ? For me I want to see consistency with data and infoboxes, but loathe seeing hundreds of articles in categories which all read the same. It makes us look soulless and like a database. ♦ Dr. Blofeld 18:43, 13 April 2025 (UTC)[reply]
    I think this would work if the articles were created in a liminal space such as draftspace, project space, or userspace, and then promoted to mainspace upon some minimal review. BD2412 T 18:55, 13 April 2025 (UTC)[reply]
    Yup, just said the same thing. Ideally a bot which can mass generate basic entries with consistent data in the WikiProject space and then an editor or two gradually manually working through them writing unique content for each and gradually creating in the mainspace would be better. At the very worst, meaty stubs which are consistently formatted and sourced with government data and sites and which are individually written on top of the raw data, no generic soulless articles allowed.♦ Dr. Blofeld 18:59, 13 April 2025 (UTC)[reply]

    a few standards

    I have a system I would like to suggest. How about picking a few of the simplest and most frequently used templates or luas and designating them as something like "Standard Lua" or "Standard Templates"? These templates or luas would use the same scripts and syntax in all language versions and sister projects. Whatback11 (talk) 15:01, 12 April 2025 (UTC)[reply]

    I've left a note at Wikipedia:Village pump (technical) about this discussion as folks there are likely to be interested/knowledgeable. 15:08, 12 April 2025 (UTC) — Preceding unsigned comment added by Thryduulf (talkcontribs)
    That could be interesting (I'm thinking of templates connected to a Wikidata item), but the issue is that it might require a lot of standardization as each project might have its technical ecosystem already adapted to specific variants of these templates. In my opinion, the benefits of intercompatibility outweigh the cost of changing the syntax of frequently-used templates on many projects.
    One point where this has already been done is citation templates, where foreign-language parameters are often interpreted correctly when copy-pasted from one language version to another. However, these are implemented as aliases for similar parameters, and don't imply that all the versions of the citation templates must function the same way "under the hood". Chaotic Enby (talk · contribs) 16:21, 12 April 2025 (UTC)[reply]
    phab:T121470 is an old request. There are other connections there that you can look at. Izno (talk) 16:37, 12 April 2025 (UTC)[reply]
    This is being implemented as WikiFunctions In the future: It will be possible to call Wikifunctions functions from other Wikimedia projects and integrate their results into the output of the page., which has... an interesting approach to things. The wiki-functions are already available on the Dagbani wiki. Aaron Liu (talk) 18:10, 13 April 2025 (UTC)[reply]

    Space tourists: "crew" or "passengers"

    Our spaceflight articles seem to continue to call the paying passengers without duties on recent spaceflights "crew", despite the fact that this doesn't match the normal meaning of the word. While this glorifying of what these actually do (spend 1 minute in actual space, have no duties at all on board), is uncritically repeated by too many news reports, I don't think Wikipedia should contribute to such incorrect promotalk. We clearly use the distinction in every other type of article (e.g. for airline crashes, we list "crew" and "passengers" separately), and no one would dream of calling themselves crew simply for boarding a plane or train. Can we please bring back some accuracy to our spaceflight articles as well? Fram (talk) 16:48, 14 April 2025 (UTC)[reply]

    • Personally I agree, but what matters is what terminology sources use and how. It's possible that "crew" in reference to a spaceflight means "anyone on board a spacecraft" while with aircraft it means "those tasked with operating the aircraft". 331dot (talk) 16:57, 14 April 2025 (UTC)[reply]
    • We could use quotes around crew, as did you. O3000, Ret. (talk) 17:05, 14 April 2025 (UTC)[reply]
      WP:SCAREQUOTES might be a reason not to. Sdkbtalk 17:45, 14 April 2025 (UTC)[reply]
      I don't think that applies in a case where the word is used metaphorically. We're not making an accusation. O3000, Ret. (talk) 17:53, 14 April 2025 (UTC)[reply]
    • I agree with Fram (which doesn't happen often!). Six people who take a boat on a pleasure cruise are no "crew" and nor are these people. In the same way that we don't uncritically repeat other neologisms from press releases, we shouldn't stretch the plain-English definition of a term here and there's nothing in policy that binds us to the exact wording used by the sources. HJ Mitchell | Penny for your thoughts? 17:28, 14 April 2025 (UTC)[reply]
    • I'm inclined to agree here, but I would like to know a little more about how much safety training etc. is involved for paying voyagers on spacecraft. Another way to look at the promotionalism concern is that these companies may want to minimize how much preparation is required to make the flights seem more routine than they actually are yet. Sdkbtalk 17:49, 14 April 2025 (UTC)[reply]
    Might be worth using the NASA definition Mrfoogles (talk) 19:22, 14 April 2025 (UTC)[reply]

    Crew. Any human on board the space system during the mission that has been trained to monitor, operate, and control parts of, or the whole space system; same as flight crew.

    Passenger. Any human on board the space system while in flight that has no responsibility to perform any mission task for that system. Often referred to as "Space Flight Participant."
    — NASA Procedural Requirements 8705.2C, Appendix A: Definitions

    I don't know if those are the right NASA definitions, but using NASA definitions or other scientific/academic expert definitions, rather than promotional media spin, seems to be the better choice for wikivoice. Levivich (talk) 20:03, 14 April 2025 (UTC)[reply]
    Have you got an example as to when this comes up? Can we not just say that eight people were "on-board" rather than give them a job. Lee Vilenski (talkcontribs) 20:07, 14 April 2025 (UTC)[reply]
    Every article about a human spaceflight names the participants, currently called the "crew". Having passengers not involved in the operation of the craft is a relatively recent development. 331dot (talk) 20:11, 14 April 2025 (UTC)[reply]
    First let me say that I know everyone working on these articles has been doing so with good intent and every effort at NPOV, it's just that language evolves very quickly sometimes and there may not be good models on how to write about very recent innovations, and thus Fram has identified a received weakness in existing published matter on this topic.
    In any case: If you pay for a ride you are a passenger; if you get paid for going on a ride, you are crew.
    I personally think we should use Fram's first phrase in his subhed and just should call them space tourists. Why? Because they're not even passengers on a journey to a destination in the sense that the spaceship is going from a port on Earth to a port on the Moon. They're going on a canned tourist cruise to see whales in the bay or look at that famous rock formation or view the reef by glass-bottom boat, and then return from whence they began. Similarly, people who pay for passage on submersible trips to shipwrecks should be referred to as deep-sea tourists.
    FWIW, there is already sitcom-theme-song canon law on this issue:
    The mate was a mighty sailing man,
    The skipper brave and sure.
    Five passengers set sail that day
    For a three hour tour, a three hour tour.
    So yeah I vote passengers over crew (although I would personally prefer tourists over both although I'm simultaneously concerned it has a slightly disparaging connotation).
    jengod (talk) 20:50, 14 April 2025 (UTC)[reply]
    You mean Tina Louise and Jim Backus weren't crew members? O3000, Ret. (talk) 21:15, 14 April 2025 (UTC)[reply]
    For those three hours, they were just passengers. But then the weather started getting rough... oknazevad (talk) 18:04, 15 April 2025 (UTC)[reply]
    We call Dennis Tito a "space tourist", Donald Albury 22:59, 14 April 2025 (UTC)[reply]
    Did I mention that I'm an official part of the crew of planet Earth? O3000, Ret. (talk) 23:01, 14 April 2025 (UTC)[reply]
    Tito was a space tourist, who was a member of the 3-Man SM-24 mission crew*, people can be multiple things at the same time. (According to NASA NASA - NSSDCA - Spacecraft - Details JeffUK 17:25, 15 April 2025 (UTC)[reply]
    You still call people on boats passengers though even if the route is a circular sightseeing one. Same goes for other forms of transport, cf. Mount Erebus disaster. In this case I think passengers is the best term  novov talk edits 00:52, 15 April 2025 (UTC)[reply]
    Wait, does this mean that the flight was "uncrewed"? We have been using that term for robotic missions. Hawkeye7 (discuss) 01:04, 15 April 2025 (UTC)[reply]
    We could say the Blue Origin flight earlier today was "unmanned". (Duck and run.) Donald Albury 01:23, 15 April 2025 (UTC)[reply]
    I would just urge some caution here. I wouldn’t count the passengers of the New Glenn flight as crew. It’s a fully-automated capsule on a suborbital flight. They get basic training on “safety systems, zero-g protocols, and execute mission simulations”. They’re tourists/passengers.
    However, the occupants of the recent Fram2 mission trained for months and while the Dragon is highly automated, it’s not fully automated. They still had a lot to learn. They’re definitely a crew.
    The problem with the term spaceflight participant is that the Russians define pretty much everyone who’s paying them for a ride as a spaceflight participant… including those who undergo extensive professional training and for whom conducting scientific research is the primary reason for their spaceflight. RickyCourtney (talk) 07:03, 15 April 2025 (UTC)[reply]
    They are as much made crew by the safety briefing as my going to muster drill on a cruise ship makes me a member of its crew. If they are a) not paid for their services aboard ship and b) take no real part in controlling the craft or operating onboard equipment, I don't see them as crew. That being said, there is always going to be a gray zone.Wehwalt (talk) 13:10, 15 April 2025 (UTC)[reply]

    I dropped a note about this discussion at Talk:Blue Origin NS-31#"Crew" or "passengers", which has so far fewer participants but a quite different point of view... Fram (talk) 13:25, 15 April 2025 (UTC)[reply]

    Crew is clearly the common term. NASA refer to the 'participants' on a missions who's only purpose was tourism as 'crew' here The Soyuz MS-20 and Expedition 66 crews - NASA
    The European Space Agency refer to the 'tourists' amongst the crew here too.
    'Crew' is clearly just 'the people on board' when talking about spaceflight. Maybe that will shift if the distinction between 'crew' and 'passengers' continues but it hasn't yet. The recent 'all-female crew' aboard the latest Blue Origins flight are referred to in all reliable sources as 'A crew', as are the crew-members of all previous blue origins flights. JeffUK 17:11, 15 April 2025 (UTC)[reply]

    I am going to drop out of this convo now bc I realized I might reinforcing or enabling misogynist presumptions that "if a bunch of women can do it must not be hard work." And that's absolutely on me because I have long-standing bitter POV feelings about Lauren Sanchez dating to So You Think You Can Dance. ANYWAY, my take is that the bifurcation is very clear and has been so since humans first started offering to ferry other humans across the river on janky rafts:

    If you pay for a ride, you're a passenger. If you get paid to give a ride, you're crew. Participation in tasks onboard is not the determinant.

    If we have reliable sources stating that someone paid money or items of equivalent value (publicity valued at X?) to go on a space trip or were sponsored to go on a space trip, they are passengers (and space tourists).

    If we have reliable sources stating that someone is getting paid money by any space agency or rocketship-owning private company to go on a space trip, they are crew.

    If we have no reliable sources about the financial/funding arrangements that determined which people are getting onboard a rocket ship, it seems fine to fall back on the default and current practice of using crew. But also don't let marketing practices and publicity stunts fool you.

    This debate is a legacy of the Space Age when all space flight was quasi-military, government-sponsored, and "exploration." The transition to commercial space flight and private exploitation of extra-atmospheric travel is obviously well underway and will require a transition in perspective, including perhaps additional skepticism about motive.

    Good luck on your debate and I hope you all have a wonderful April!!

    jengod (talk) 17:57, 15 April 2025 (UTC)[reply]

    Space tourists are barely one step up from luggage and are not crew, are not astronauts, are not exceptional except perhaps in the size of their bank accounts. Simonm223 (talk) 20:13, 15 April 2025 (UTC)[reply]
    Some might qualify as “experiments”… so “equipment”. :) Blueboar (talk) 20:17, 15 April 2025 (UTC)[reply]
    Participation in tasks onboard is absolutely a determinant.
    I’d argue that if you have an active role in the operation of the craft, you’re part of the crew… even if you’re paying for the privilege.
    If you’re paying to be there and you’re just along for the ride without any active operational duties (and knowing what to do in an emergency doesn’t count)… you’re a passenger. RickyCourtney (talk) 00:21, 16 April 2025 (UTC)[reply]

    Idea lab

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

    Rough example #1

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

    You can also:

    Rough example #2

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

    You can also:

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

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

    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 (talkcontribs) 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 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 (19552011) 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]
    Hooman Mallahzadeh, think you are overlooking the substantial proportion of our population, which assigns astrological significance to dates. Knowing Jobs’s date of birth informs, those readers immediately that he was a Pisces ascendant in Virgo, which might shape views of him for them. Hyperbolick (talk) 07:10, 13 April 2025 (UTC)[reply]
    @Hyperbolick "Astrological significance of dates" is related to computers. But for humans, an approximate date which has no "Astrological significance" is more useful. For example, instead of "February 24, 1955", we can use:
    • 1955 - As year
    • 1950s - As decade
    • second half of 20th contury
    • 20th century
    All of them are useful for different purposes, because we are human, not computer. Our goal is to provide a
    "Highly readable" article for "Humans".
    It can be achieved by using approximate dates, somehow that does not harm the definition.
    This "principle of parsimony" is applied in "introduction writing instruction" for of all scientific articles but not yet in Wikipedia. The problem is that we are human not computer. Hooman Mallahzadeh (talk) 07:54, 13 April 2025 (UTC)[reply]
    Hyperblock's comment has nothing at all to do with computers and your (@Hooman Mallahzadeh's) comment completely misses the point. Thryduulf (talk) 08:13, 13 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]

    References

    1. ^ Wells, John C. (2008). "Ali". Longman Pronunciation Dictionary (3rd ed.). Longman. ISBN 978-1-4058-8118-0. the former boxer Muhammad Ali pronounces ɑːˈliː

    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 • {CX}) 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]
      I didn't know that. In that case, we do need some sort of matching. We should only need to check the first line since no characters before the # are permitted for valid redirects. Aaron Liu (talk) 18:12, 11 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 • {CX}) 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]

    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]
    I agree with Blueboar's comment that what we actually do in RMs is not a literal application of the word "always". I've participated in...a few RMs and I've never understood the "always" in that sentence to mean "in every single source in existence", instead reading it as "grammatically should always be capitalized". In that regard, I support changing the wording of NCCAPS. But Wikipedia prefers to minimize capitalization, so the threshold cannot be 50%+1 of sources, it has to be a large majority. Not sure how best to express this in guideline-speak. Toadspike [Talk] 21:58, 11 April 2025 (UTC)[reply]

    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: גָּמָל, romanizedgamal, 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 (talkcontribs) 14:30, 6 April 2025 (UTC) (edited LightNightLights (talkcontribs) 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]
    I think there are some tools that require certain edit counts, though the two I can remember at the moment, being access to the wikipedia library and autowikibrowser, have similar edit requirements to extended confirmed. I believe there's a tool that requires 1k edits but I cannot for the life of me remember what it is, so along with the others I listed I doubt anyone is edit farming for those specific tools. ¿VØ!D?  21:11, 14 April 2025 (UTC)[reply]
    Currently, it seems that there is no documentation if one can restrict edit count by namespace. mw:Manual:$wgAutopromote. If the suggestion is passed in a RfC, technical assessment and work will likely be in order before such conditions by namespace can be used. – robertsky (talk) 09:51, 13 April 2025 (UTC)[reply]
    Likely it would require a database change to store the edit count by namespace. Anomie 12:40, 13 April 2025 (UTC)[reply]
    Some editors do start drafting articles in userspace before moving them to mainspace, I'm thinking these contributions should still be counted if that proposal comes to pass. Chaotic Enby (talk · contribs) 12:26, 13 April 2025 (UTC)[reply]
    Chaotic Enby, are you saying these edits should count even before the draft has been published (So someone may have 450 mainspace edits and 100 edits to an as-yet-unpublished draft, and they should receive EC rights)? Because if they only count after publication, I think counting edits made to mainspace would include edits made to former drafts that have since been moved to mainspace. Zanahary 21:38, 15 April 2025 (UTC)[reply]

    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]
    FA star looks different and fancier because it is different and fancier. Making it bland like the other icons defeats the purpose. Cremastra talk 20:02, 11 April 2025 (UTC)[reply]
    IMO we should even remove the Norro (the circley thing and its shadow) for that and replace the neutral symbol with something (swap its location with the bottom left even), perhaps the AfC logo. Aaron Liu (talk) 02:51, 12 April 2025 (UTC)[reply]

    Unblock request wizard

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

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

    False Positives.

    Antivirus

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

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

    A problem with pushpin maps

    Hi, follow this scenario

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

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

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

    @Elli:This is my proposed easy implementation:

    1- Create an OSM map by this code:

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

    Which yields:

    Map

    2-place the above code in a hidden div tag

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

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

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

    Helping bring more interest in Wikipedia with racing fans

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

    Could drafts be protected instead of deleted?

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

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

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

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

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

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

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

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

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

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

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

    I agree with the general shape of this proposal but would reverse the colors. IMO "additional considerations apply" should be thought of as the actual step between WP:GREL and WP:GUNREL, with "no consensus" as a sort of "null" represented by a color outside the normal range. Loki (talk) 00:37, 16 April 2025 (UTC)[reply]
    "No consensus" doesn't mean null guidance; it's indeed more caution than GRel and less caution than GUnRel. Aaron Liu (talk) 02:14, 16 April 2025 (UTC)[reply]
    I don't see a need for this distinction. A source in yellow means spend some time thinking about this one. Purple would also mean spend some time thinking about this one... a meaningless distinction. Headbomb {t · c · p · b} 00:53, 16 April 2025 (UTC)[reply]
    One has full consensus behind spending time thinking about this one and detailed directions on how to, as opposed to the far more general "we're not sure if this source is reliable, double-check". Contrary to Loki I feel like the former is on a different spectrum. Aaron Liu (talk) 01:06, 16 April 2025 (UTC)[reply]

    Moving logos, album covers etc out of infoboxes

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

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

    Current examples:

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

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

    I don’t see how placement in the infobox precludes sourced critical commentary in the body. Zanahary 00:20, 16 April 2025 (UTC)[reply]
    I agree. These examples can all be changed: I would support the recommended changes to the latter two pages, and for the first page I would just copy over (and condense) the caption on the child page and throw it into the infobox. None of this needs something that says such images shouldn't be in infoboxes. Aaron Liu (talk) 01:42, 16 April 2025 (UTC)[reply]
    Am I right in reading this as a question about whether WP:NFC used in the infobox meets the WP:NFCCP policy, rather than a general question about whether logos, album covers, etc. should be in infoboxes or not? CMD (talk) 00:33, 16 April 2025 (UTC)[reply]
    Per NFCI#1, images that are used for identification in infoboxes are presumed to meet NFCC#8 as they provide implicit branding and marketing of the topic in question. If they can also be used for additional purposes (for example, Ico's cover is discussed in the article as being based on a classical work of art), great, but we do not have that requirement to require more than the topic being notable in the first place to use identifying images. Masem (t) 02:13, 16 April 2025 (UTC)[reply]

    WMF

    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. Sdkbtalk 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 • {CX}) 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]
     DoneNovem 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]
    All right, I filled it out. Somewhat surprisingly, Wikipedia scores a respectable 90/180 (a lot more than you would expect given the fact the organization has a suspicious absence of minerals):
    1: Yes, I would hope so. (5)
    2. Yes, collaborating with any such organization (or any organization with a political viewpoint at all) would violate WP:COI (5)
    3: No, most Wiki-meetups are informal gatherings of editors so vetting them for being terrorists would be a waste of time as well as pointless. (0)
    4: WTF. No. Clear WP:NPOV vio. (0)
    5: Yes, per WP:NOTCENSORED, and WP:FREECONTENT. Speech is constrained by the practical constraints of an encyclopedia but that’s about it. (5)
    6: Yes? We don’t really collaborate with any organizations with policies for or against the US, per WP:COI. (5)
    7: No, per WP:NOTCENSORED, we have abortion information on our website. (0)
    8: Yes. Wikipedia is a well-funded organization with more than enough money to cover its operating cost. (5)
    9: Yes. Let’s be honest, there is a fair amount of complaining on the site of Wikipedia’s high overhead costs, but the overhead costs of Wikipedia are dwarfed by the impact of the site. (5)
    10: No. Why would we? We’re an encyclopedia? (0)
    11: Yes? Again, we don’t really collaborate with any organizations with policies for or against the US, per WP:COI. (5)
    12: No. As an international organization with global governance structures, we collectively politely tell you to go soak your head over this one. (0)
    13: Yes. Local branches of Wikipedia have, at points, received money from Russia, and worked with groups such as Wikipedians in Mainland China. That being said, Wikipedia no longer receives funding from those organizations and has never partnered with them per WP:COI. (5)
    14: No, per WP:NPOV. (0)
    15: No. We have programs that seek to include and improve coverage of areas not currently covered. That’s a good thing. (0)
    16: Yes. Endorsing any policy positions officially would be WP:NPOV. We let the facts speak for themselves. (5)
    17: No, per WP:NPOV. (0)
    18: No. Even though sometimes it sure feels like it. (0)
    19: No per WP:NOTCENSORED. Although, let’s be honest, the fact that Wikipedia fails this is more because “Gender Ideology” is really just talking about trans people. (0)
    20: No per WP:NOTCENSORED (0)
    21: Yes. Wikimedia Enterprise is the business arm of the foundation. (5)
    22: Yes. Millions of people across the US use Wikipedia every day. Not to mention search engines rely on it. (5)
    23: Yes. We’ve already done so. (5)
    24: Yes. If the free flow of and access to information is a national security need, you could hardly find a better organization to fulfill this need. (5)
    25: Providing access uncensored information to authoritarian regimes who are (for now) the primary “malign influencers” undermines their interests. (4)
    26: I doubt Wikipedia has any impact whatsoever. We let the facts speak for themselves, and people make their decisions with those. (1)
    27: I doubt Wikipedia has any impact whatsoever. We let the facts speak for themselves, and people make their decisions with those. (1)
    28: Ironically, we probably do a better job of providing accurate health information than the current US government, which definitely mitigates biological threats and pandemics. As per “foreign dependence on medical supplies”, why even include that in this question you morons? (4)
    29: Again free speech has generally helped promote US national security interests (we’ll see for how much longer). (2)
    30: I guess disclosing what they are and providing information helps, sort of? That being said, WP:NPOV applies here. (1)
    31: WP:NOTCENSORED means Wikipedia has information on most religions, benefiting religious minorities. Unfortunately, as you may know, the facts have a well known anti-Christian bias.(3)
    32: None beyond letting the facts speak for themselves. That may be a bad thing for the current regime. (1)
    33: People like Wikipedia, and many Wikipedia editors are American. That sort of cultural exchange hopefully helps people abroad see not everybody in the US is quite as bad as the current regime. (3)
    34: The financial return of Wikipedia, when taking into account the benefits its provides, is massive. We’re one of the most visited websites in the world (5)
    35: Wikipedia Enterprise makes bank, man [24]. (5)
    36: Wikipedia is an encyclopedia. It is a concept, not a mining company. (0) Allan Nonymous (talk) 15:53, 15 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]

    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


    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, in accordance with the applicable law, 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).
    • Delhi High Court Proceedings: 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 under applicable laws to ensure that everyone can share and access free knowledge on Wikipedia in accordance with its Terms of Use and applicable policies. 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]
    Thanks for the update Joe. I hope for the best possible outcome from the Supreme Court proceedings. Unfortunately I can't say I'm optimistic about the appeal to the Delhi High Court, given how it's gone so far, but it's good to hear the WMF is challenging these orders at each possible opportunity. --Grnrchst (talk) 11:14, 12 April 2025 (UTC)[reply]
    Joe, the Division Bench's order has long been available. Upd Edit (talk) 18:42, 12 April 2025 (UTC)[reply]
    I think a backend tool for WMF legal that gives HTTP 451 for specific pages might actually be better than a plastered notice. I don't think anyone likes censorship (not even me), but this may be the best option to preserve access to the most number of Wikimedians. And if it is necessary to block VPNs from those same pages, so be it. It unfortunately would also mean that the page would be inaccessible from logs and recent changes. Aasim (話すはなす) 02:43, 14 April 2025 (UTC)[reply]

    Miscellaneous

    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]
    Because of being brigaded and scolded by one "side" or the other? Herostratus (talk) 04:42, 13 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]

    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]
    Headbomb, do you also want to update User:Headbomb/unreliable/testcases to show this? --rchard2scout (talk) 14:40, 15 April 2025 (UTC)[reply]
    Sure, added. Headbomb {t · c · p · b} 17:27, 15 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]

    How about just stating the licence without using a template? If there are several of them, then it could be worth having a teplate set up. Graeme Bartlett (talk) 10:13, 13 April 2025 (UTC)[reply]
    I think it's gonna end up being more. A lot of material archived by the National Library of Norway (and still under copyright there) is available as CC-BY-NC, so anything pre-1930 may end up falling into this category. hinnk (talk) 22:46, 13 April 2025 (UTC)[reply]

    Random drive-by talk page posts by IPs

    Talk pages of articles get a large number of random drive-by talk page posts by IPs, consisting of single words, nonsense or complete gibberish, which may normally be presumed to be test edits. But some pages seem to attract disproportionately more than others. Can anybody suggest why Talk:XXX and Talk:XXXX get so many of these? --Redrose64 🌹 (talk) 20:32, 11 April 2025 (UTC)[reply]

    Redrose64, a bunch of Xs is associated with porn and forbidden topics. That's catnip to people with certain immature and disruptive personality traits. Cullen328 (talk) 22:54, 13 April 2025 (UTC)[reply]

    How ridiculous

    The featured article for today is about a single planned edition of an annual competition that never happened. Am I the only one who finds this absurd? 2601:644:8184:F2F0:A15D:AF8E:82A5:35DA (talk) 01:21, 13 April 2025 (UTC)[reply]

    It's part of a historical event that was postponed by a historical event: it's notable for being a long-running tradition that couldn't be allowed, with tonnes of evidence and context to justify its importance. Sometimes what doesn't happen is as important as what does. doktorb wordsdeeds 02:11, 13 April 2025 (UTC)[reply]
    For the lazy, The Boat Race 2020. It's not compulsory to read it. Johnuniq (talk) 02:15, 13 April 2025 (UTC)[reply]
    It is an unwritten law of Wikipedia that The Boat Race must receive maximum exposure on the main page, even when it does not happen. Cullen328 (talk) 22:57, 13 April 2025 (UTC)[reply]

    Wikidata edits: P- and Q-numbers

    Hi everyone, I am wondering what your thoughts on how P- and Q-numbers are displayed in an edit summary (when the edit is from Wikidata). Currently, the edit summary will just show a P-number and Q-number or the value text. Could that be improved if we showed the labels instead, or both? I'd like to hear your thoughts over on this discussion page.

    How a (Wikidata) edit summary appears in Wikipedia Watchlist Thanks, - Danny Benjafield (WMDE) (talk) 12:58, 15 April 2025 (UTC)[reply]

    Globally locked

    See Wikipedia talk:Courtesy vanishing#Globally locked. CambridgeBayWeather (solidly non-human), Uqaqtuq (talk), Huliva 18:49, 15 April 2025 (UTC)[reply]

    Spanish Wikipedia

    Hello, I'd like to revive a topic that has been mentioned here a long time ago: the problem that existed, and still exists, on Spanish Wikipedia. Reverters and patrollers are abusive toward ordinary users, especially anonymous users, reverting legitimate edits without reason. Administrators (librarians) do the same, reverting users who protest and, in extreme cases, blocking them. It's a kind of "dictatorship" on Spanish Wikipedia. I'll mention a few: UA31 (admin, abuses the automatic revert button and blocks users without reason); Rafstr (admin, deletes protests); Luicheto (reverter, abuses reverts, persecutes anonymous users); and there are others who do the same or similar things. If there's a victim of this persecution on Spanish Wikipedia here, feel free to share your experience here so we can all be heard. 181.20.199.64 (talk) 22:45, 15 April 2025 (UTC)[reply]

    We cannot help you with issues on the Spanish Wikipedia, nor is this the forum to air grievances with the Spanish Wikipedia or its administrators. If administrators there are behaving badly, you need to take that up with the WMF. 331dot (talk) 22:47, 15 April 2025 (UTC)[reply]
    Actually, the U4C would be the right place. RoySmith (talk) 23:41, 15 April 2025 (UTC)[reply]