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.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
Proposed edit to the BLP
Hello, at the BLP talk page, I proposed adding 17 words to the policy. That was a couple days ago, and there's been no comment. So here I am!
I would like to suggest a small modification: "A living person accused of a crime is presumed innocent until convicted by a court of law, and upon conviction there is an exception to the usual BLP policy on the inclusion of denials." This would clarify an exception to the usual BLP policy ("If the subject has denied such allegations, their denial(s) should be reported too"). We shouldn't feel obliged to always include denials of convicted people.
This small modification matches what the essay WP:NOTMANDY has said for years: "the Biographies of Living Persons (BLP) policy does not require denials be mentioned if a person has been 'convicted by a court of law', in which case they can be presumed guilty" (N.B. I was the lead author of that essay). Of course, this BLP clarification would still allow denials to be included in the rare case of convicted people whose denials are still reported after conviction, in reliable sources. Nor would this clarification apply in the rare case that a conviction is overturned (i.e. the clarification applies "upon" conviction, not forever "after" conviction).
Have you considered the possibility of a wrongful conviction? Why wouldn't we include denials, such as:
He was convicted but plans to appeal.
He was convicted but continues to claim that he is innocent.
Even including a sentence such as "He entered a plea of not guilty" is including the accused's denial of the allegations in the article.
I think that a small change might be appropriate: It might be better to say that "their denial(s) should normally be reported too". I wouldn't weaken it beyond that. WhatamIdoing (talk) 00:00, 8 June 2026 (UTC)[reply]
If there’s RS reporting about a wrongful conviction or an appeal, then that can be included per usual Wikipedia editing rules. But most convicted felons will always say they’re innocent, I don’t see the point in including that, the presumption of innocence no longer applies to people who have been convicted. I feel that invariably requiring a denial be included in a BLP even for convicted felons leads to people just ignoring WP:DENIALS altogether. There is also not generally a tradition among journalists or scholars of mentioning denials of people who have been convicted. Note that I haven’t suggested any change to the language of WP:DENIALS, but you’ve done so; I think your insertion of the word “normally” would make more people ignore WP:DENIALS than already ignore it…which is the exact opposite of what I’m trying accomplish. Every situation is abnormal in some sense. Anythingyouwant (talk) 00:13, 8 June 2026 (UTC)[reply]
If RSes are reiterating the denial of guilt by the convicted, there's zero reason to not include it. MANDY was a dangerous essay and we should avoid going there in BLP. Masem (t) 03:06, 8 June 2026 (UTC)[reply]
I agree about reiteration, but consider there’s an arrest of John Doe, and a not guilty plea which are both recited in RS. Then after a fair trial and unanimous conviction by a jury, the RS’s stop talking about any denial. Do we have to keep saying it? That’s what the policy currently requires, Anythingyouwant (talk) 10:52, 8 June 2026 (UTC)[reply]
If John Doe pleaded guilty at the trial we would undoubtedly mention that, so why would we not mention a not guilty plea? I'm struggling to understand how a lack of mention would improve the article? Thryduulf (talk) 11:04, 8 June 2026 (UTC)[reply]
If someone is convicted, it’s normal to drop any mention of the trial, including the plea. We just say the person served 10 years in jail for embezzlement. Do we have to say, he served 10 years for embezzlement, although he argued at his trial that he was innocent? Even though no post-conviction RS’s discuss the denial? Anythingyouwant (talk) 11:11, 8 June 2026 (UTC)[reply]
Dropping coverage of the trial would depend on how much coverage the trial got. Some persons have had very public trials (Weinstein, Cosby, for example), and just because the end result is a conviction doesn't mean it would be appropriate to remove any discussion of the trial (and of course their plea of innocence before it). But this is usually the exception, most people are convicted with a relatively quiet coverage of the trial itself, and in that case, yes we can jump to the conviction and likely not have to worry about any claims made by the convicted if there's no significant coverage of that.
A key to remember is that the decision from a trial is only a legal determination of any guilt. The decision should not be taken as a factual account of the actual events, only whether the person is guilty on the legal presentation of those events to a judge or jury. Masem (t) 11:29, 8 June 2026 (UTC)[reply]
If no RS covers the claim of the convicted suspect that they are innocent after the trial concludes, I would agree we should not cover that as well. Masem (t) 11:25, 8 June 2026 (UTC)[reply]
@Anythingyouwant, I don't think it's actually true that most convicted felons will always say they’re innocent. Plea bargaining happens precisely because so many convicted felons were willing to admin that they were guilty. I've read that in the US, that's 98% of convictions. WhatamIdoing (talk) 20:52, 8 June 2026 (UTC)[reply]
I'll confess I am having a hard time imagining a situation in which a denial of a noteworthy criminal conviction would not itself be a noteworthy part of the story. Are there some recent examples where this has been controversial? Is this limited to situations where the only source for the denial is a primary one? (That is, situations where the denial is verifiable but has not been reported in any reliable secondary source?) If so, I think the proposed language would be improved by clarifying that. -- Visviva (talk) 03:00, 8 June 2026 (UTC)[reply]
As I just mentioned to Masem, consider there’s an arrest of John Doe, and a not guilty plea which are both reported in RS. Then after a fair trial and unanimous conviction by a jury, the RS’s stop talking about any denial. Do we have to keep saying it? Anythingyouwant (talk) 10:54, 8 June 2026 (UTC)[reply]
The key here is determining how much WEIGHT to give the denial, not whether to include/exclude. I can see the argument that we should give less weight to a post-conviction denial than we would to a denial at the accusation stage. But that doesn’t mean we should not mention the denial at all. Blueboar (talk) 12:42, 8 June 2026 (UTC)[reply]
Your comment about weight brings up a couple related points. It seems obvious to me that whenever WP:DENIALS requires us to include a denial, the denial ought to be in the same paragraph as the accusation, not hidden far away, maybe even in a footnote where it’s almost completely useless. Another thing that seems obvious is that editors should be sanctioned for violating WP:DENIALS, claiming WP:IAR shouldn’t cut it. (I actually was sanctioned for insisting it be followed despite local consensus to ignore it.) The USSR had a wonderful constitution that protected all kinds of civil liberties, but it was never enforced. I often get that feeling about Wikipedia’s policies and guidelines. Anyway, there’s probably a category for living convicted felons, and I bet you not 10% of those BLPs mentions their denials. Nor should they be mentioned, if no post-conviction RS’s mention them. I don’t see why we must. If there’s consensus to do so in a particular case, that’s fine. Anythingyouwant (talk) 13:11, 8 June 2026 (UTC)[reply]
It seems obvious to me that whenever WP:DENIALS requires us to include a denial, the denial ought to be in the same paragraph as the accusation - no, that is absurd. Per WP:NPOV, weight and focus is decided based on the weight in the sources, not based on editors' gut feelings about fairness or what they personally think is important. If you want to put a denial in the lead, you need to produce sourcing strong enough to justify it there. Other policies cannot overrule NPOV on this (as I suspect you found out in the dispute you mentioned.) They can put a great deal of weight on the scale in ambiguous cases, and most cases are ambiguous to an extent; but no policy can say "you MUST do XYZ, without regard for sourcing." When other policies and guidelines come into direct contradiction with WP:NPOV and WP:V, NPOV and V win. With well-considered and well-worded policies, this rarely happens; if you find a particular policy is coming into conflict with NPOV and V usually often, that's probably an indicator that that policy should have its wording toned down. --Aquillion (talk) 03:11, 18 June 2026 (UTC)[reply]
A relevant and topical article is Wrongful conviction of Andrew Malkinson. In this case, recently concluded when the actual offender was convicted, Malkinson actually served 10 years longer than necessary in jail because to apply for parole, he would have had admit that he committed the crime, which he refused to do. Black Kite (talk)11:22, 8 June 2026 (UTC)[reply]
I appreciate such concerns, and I think my proposal can be improved. But in the vast majority of Wikipedia articles that mention people who have served jail time for crimes, nothing like that is involved. They typically have a trial where they claim innocence, then there’s a conviction, and the claim of innocence is never mentioned in RS’s after the conviction. So I would tweak my proposal: “A living person accused of a crime is presumed innocent until convicted by a court of law, and upon conviction there is an exception to the usual BLP policy on the inclusion of denials unless the relevant reliable sources are post-conviction.." That doesn’t mean such details cannot be included, just that they don’t have to be included, in a BLP. My experience is that WP:DENIALS is still widely ignored at Wikipedia (even at BLPN!), so I would like to get rid of aspects of WP:DENIALS that are overkill. Then maybe people will adhere to it. Anythingyouwant (talk) 11:53, 8 June 2026 (UTC)[reply]
Can you give 3 example articles where this would make a difference? I'm having a hard time imagining articles where we mention a conviction and shouldn't at least briefly include the position of the convicted, but having actual examples where this should be removed (or not be included if it isn't there now) might convince me or others otherwise. Fram (talk) 13:03, 8 June 2026 (UTC)[reply]
I am disinclined to name particular BLPs. I do not relish the thought of being accused (not by you) of trying to manipulate policy to advance my position in any particular content dispute, which of course I am not trying to do. Anyway, I don’t think it should require examples to see that it’s silly to require we mention a denial when no post-conviction RS does so. Allowing inclusion of such denials is fine, but requiring them is absurd. And we rarely do require it, even though it’s plainly required by the policy. I would prefer to have a policy that we can rely on, and that means what it says. Anythingyouwant (talk) 13:29, 8 June 2026 (UTC)[reply]
There are many things that should (not "must") be included but often are not (yet). The policy mainly protects those wanting to include it from others wanting to remove it "because they are convicted" or "because they are obviously lying" or whatever reason is given for the removal. It should not get undue weight, we don't strive for equal balance between conviction and denial in most cases, but there's nothing silly about including it even if post-conviction it is no longer mentioned by the sources. Fram (talk) 13:39, 8 June 2026 (UTC)[reply]
News reports about an accusation typically include denials, so when we omit a denial in that situation, it implies the person does not dispute guilt. That situation is entirely different after conviction, there is no journalistic practice of mentioning denials after conviction. So that aspect of our policy is absurd, and is often rightly ignored. That undermines the policy. As for the idea that the policy protects any editors, that’s a sweet notion, but untrue. For example, I was banned from American politics articles for five years merely because I insisted on reinserting an obvious denial into a BLP. But I agree with you that the policy *should* protect editors who follow it, and so I’m striving here for a policy that makes good sense and can command respect. Anythingyouwant (talk) 14:01, 8 June 2026 (UTC)[reply]
We are not journalists, we don't do journalism. We take a wider view. Sources from before or during a case don't become inadmissible because we also have sources from after the case. Of course, we should present up-to-date information wherever possible, but without an indication that they no longer claim to be innocent (or often that they claim to be innocent of certain aspects), there is no reason to ignore these previous sources. As for your topic ban, as far as a brief search informs me it was (after a series of escalating issues I haven't checked) for edit warring about the inclusion of denial in the lead, not simply for including the denials in the article (where they already were), on a page with an editing restriction against all edit warring. That's not an issue with this policy or its application, but about which aspects of an article are important enough to also be in the lead. The policy just says that they should be included, not that they should be given equal weight or position. I don't think changing policy on this basis is a good idea. Fram (talk) 14:37, 8 June 2026 (UTC)[reply]
I mentioned above that, “It seems obvious to me that whenever WP:DENIALS requires us to include a denial, the denial ought to be in the same paragraph as the accusation, not hidden far away, maybe even in a footnote where it’s almost completely useless.” Obviously, the edit that I am proposing here does not address that problem. So I’m not proposing to change “policy on this basis”. My proposal here is simply that, after conviction, we should give editors some flexibility about whether to include denials if no post-conviction RS’s say anything about any denial. But I suppose this is a trivial BLP requirement if it can be satisfied by sticking the denial in a footnote. Or perhaps we can even put it in a sub-article instead of a footnote? Is that a proper interpretation of BLP? Anythingyouwant (talk) 14:59, 8 June 2026 (UTC)[reply]
Belonging in the same paragraph of the body doesn't mean it should also be in the lead. Take as an example Marc Dutroux, one of the most notorious Belgian criminals. The lead says nothing about his denial, the section on "Dutroux's testimony" gives his denials. As it should be. It's not hidden away in a footnote, but it's also not given equal weight or emphasis. Fram (talk) 15:52, 8 June 2026 (UTC)[reply]
I have no problem with the Dutroux BLP. He’s been convicted of various crimes, so the allegation in the lead that he committed those crimes doesn’t need to be accompanied by his denial in the lead. When someone has been convicted, it means the denial has been adjudicated and found legally void. If this were an article about a Belgian accused serial killer, instead of a convicted one, then the denial should accompany the accusation in the lead for at least two reasons: (1) he’s entitled to a presumption of innocence, and (2) reciting the accusation without the denial gives the impression that he hasn’t denied it, because such things are customarily described together for people who haven’t been convicted. Anythingyouwant (talk) 17:23, 8 June 2026 (UTC)[reply]
Presumption of innocence is something that the accused are entitled to only within the legal system. The accused is not entitled to a presumption of innocence from his accusers, his mother, his employer, his bank, or (relevantly for us) newspapers and other reliable sources. I think therefore that we can dispense with your reason #1.
Your reason #2, on the other hand, is important to Wikipedia. We don't want to give the impression that the accused has confessed to guilt, when that's not true. However, that doesn't mean that a denial always has to be described along with the first mention of the accusation. After all, it's only "customarily" done, which is another way of saying that it's "not always" done, and the custom, when I flip through some news articles, is "in the same article" rather than "right at the start". (Examples: 4th paragraph, 4th paragraph, subhead plus 4th paragraph, 15th paragraph, 3rd paragraph, 12th paragraph, 3rd paragraph, 4th paragraph, 4th paragraph, 15th paragraph, 7th paragraph, 13th paragraph. If the main point of the article is the denial, then it may appear in the 1st sentence [ example, example ].)
Deciding how much prominence in a Wikipedia article to give to a denial should be handled like anything else: very prominent in some cases (e.g., trumped-up prosecutions of political dissidents in repressive countries), given some space in other cases (e.g., when most reliable sources suggest that factual innocence is a significant possibility), mentioned briefly in others (e.g., all the information we can source amounts to 'He denied it'), and barely mentioned at all in others (e.g., most people post-conviction: "He entered a plea of not guilty in March, and was convicted of six of the nine charges at the trial the next month" or "As of Octember 2025, he is appealing the conviction"). There isn't a one-size-fits-all answer. Editors will have to use their judgment to decide where and how to handle denials. WhatamIdoing (talk) 22:47, 8 June 2026 (UTC)[reply]
WhatamIdoing, I didn’t suggest one size fits all, that’s why I’m suggesting an exception for the particular situation where a person has been convicted and there’s no post-conviction RS’s that discuss the denial. So I would weaken WP:DENIALS to fit that common circumstance, and let editors decide in the usual way. Conversely, where an accusation is in the lead, I would strengthen WP:DENIALS to fit that circumstance. Consider that WP:LEAD correctly says this: “The lead is the first thing most people read upon arriving at an article, and may be the only portion of the article that they read…. The lead should stand on its own as a concise overview of the article's topic. It should identify the topic, establish context, explain why the topic is notable, and summarize the most important points, including any prominent controversies.” If editors decide to put an accusation in the lead, then it seems obvious that the denial should be briefly mentioned there too (putting aside situations where there’s been a conviction). Putting it in the lead still leaves lots of room for discretion, it might be a whole sentence, or it might be just three words (“which she denies”). If WP:DENIALS is so elastic that it can be evaded by putting an accusation in the lead while the denial is put in a footnote or a sub-article or buried in a subsection, then WP:DENIALS seems pretty much useless to me. Readers who just read the lead will be misled, because readers are accustomed to seeing any denials in conjunction with accusations. Anythingyouwant (talk) 09:18, 9 June 2026 (UTC)[reply]
You want to change DENIALS to require mentioning any denial in the lead, if the allegation is in the lead. This is not ordinary practice in reliable sources. You are proposing DENIALS have a one-size-fits-all rule that if an allegation is mentioned in the lead, then the denial should also be mentioned in the lead. The way that we avoid WP:GEVAL problems with denials is precisely letting editors decide for each article individually and not according to any one-size-fits-all rule at DENIALS:
whether, if the lead mentions the allegation, the lead should also include the denial, or if the denial should only appear in the body, and
whether the denial should be described expansively or if it should be mentioned only in passing or be "buried in a subsection".
In other words, the current wording ("If the subject has denied such allegations, their denial(s) should be reported too") provides the flexibility that we need. Expanding it to say something like "If the allegations are mentioned in the lead, then the denial has to be mentioned in the lead, too" would mean making some articles less compliant with NPOV. WhatamIdoing (talk) 17:58, 9 June 2026 (UTC)[reply]
Thanks for the discussion. We disagree. WP:NPOV also says, “Wikipedia aims to describe disputes, but not engage in them.” Putting accusations in the lead without even three or four words on the other side of the dispute (“which she denies” or “which she implausibly denies”) does not seem consistent with that philosophy, nor with WP:LEAD, nor with WP:DENIALS, and I don’t see any issue about false balance either, because we can make crystal clear that RS say the denial is implausible or dishonest or what have you, which is also quite revealing about the BLP subject. Anythingyouwant (talk) 22:38, 9 June 2026 (UTC)[reply]
If the sources treat the denial as unimportant or irrelevant or as a throw-away comment, then Wikipedia should, too. And one of the ways that we treat information (of any kind, including denials) as being unimportant or irrelevant or as a throw-away comment is to omit it from the lead. Ergo, if we are, as best we can, providing a fair and unbiased summary of the sources, then that will occasionally mean omitting the denial from the lead.
Additionally, facts that require complex and nuanced explanation don't belong in the lead. "He denied everything" is just three words, but what about when he admits that as a matter of ordinary fact, he did kill someone, but there were mitigating circumstances, or he thinks the world's a better place now that the victim is dead, so he doesn't feel guilty, and besides, the charges are against his strawman instead of against the real him, because he's a sovereign citizen?
I'm planning on discussing this issue of splitting up the accusation and the denial, in the essay WP:NOTMANDY if the other editors there don't mind. If and when that's done I'll give you a heads up so we can discuss further, and/or you can edit that new essay section if you want. WP:BLP (especially combined with other policies) properly treats denials as a special aspect of a BLP, not merely a routine editing decision. If sources include a denial, mindreading the importance the s0urces attach to it is often difficult, whereas it's not difficult to conclude that many times a Wikipedia editor will like or dislike a BLP subject and edit accordingly. This policy on denials is a rare obstacle to subjective editing, to protect BLP subjects and give them a small voice. I don't understand your comment about being a sovereign citizen. As to admitting a kill, but claiming mitigating circumstances, or claiming he thinks the world's a better place now that the victim is dead, so he doesn't feel guilty, you seem to be arguing that WP:DENIALS should either be broadened or abolished, but I think keeping it a narrow requirement is the best and most practical compromise so it's not burdensome but does have a real impact in our BLPs. Anythingyouwant (talk) 12:36, 10 June 2026 (UTC)[reply]
I gave you an example in which a denial can't be presented in just "three or four words". You seem to be treating all denials alike. Here are two scenarios in which that doesn't work:
Sometimes a denial is not really a denial. Sometimes the "denial" is an admission ("I killed him") while claiming that the admitted facts do not rise to a legal violation ("but it was in self-defense" or "but my client was legally insane at the time") or even that the person does not recognize the court's authority ("I believe a conspiracy theory that says you can't prosecute me").
Sometimes a denial is complex, e.g., admitting some and denying others. Especially when the allegations are a minor part of the article (e.g., allegations made during the course of a celebrity divorce), then it might not be appropriate to highlight this in the lead, especially if doing so would require a long explanation.
Remember that there are two ways to end up with WP:UNDUE attention to a denial:
Giving too much "space" to the denial: If sources mention the denial briefly, or only once, then the Wikipedia article should be concise, too. That includes not repeating the denial multiple times in the same article (e.g., lead plus body).
Giving too much "prominence" to the denial: If sources mention the denial at the end of an article, then the Wikipedia article should not put the denial in the lead. Conversely, if the sources focus on the denial, then the Wikipedia should make the denial prominent in the article.
Understanding how a source treats a denial doesn't require "mindreading". Editors should understand how all the sources are treating the denial (the same way you should understand how all the sources treat anything about the subject), and they should consider these general views or trends in reliable sources when writing the article. If the sources tend to emphasize the denial (e.g., it's at the top of the news articles, it's the main subject of some news articles, it's given a lot of space in the news articles), then the Wikipedia article should equally emphasize the denial (e.g., put the denial in the lead, give the denial a whole section, or at least a whole paragraph). If the reliable sources downplay the denial (e.g., mention it only in passing, place it at the end of the news article), then the Wikipedia article should do the same (e.g., omit the denial from the lead, use only three or four words in the body of the Wikipedia article to mention it).
This isn't difficult. Editors manage to do this all the time. If you personally struggle to do this, then I suggest that you step back from that and let other editors take the lead on this point. WhatamIdoing (talk) 23:30, 10 June 2026 (UTC)[reply]
If you somehow got the idea that I think every denial in a BLP should go in the lead, that’s incorrect, I don’t think that. I’m saying that if the accusation is in the lead, then the denial should be mentioned in the lead too, however briefly. Whatever the proper resolution to this issue is, it ought to be made clearer in at least one relevant policy or guideline, because right now editors could easily think that an accusation in the lead should be accompanied by its denial; BLP does not say otherwise but it does indicate that a denial is an important feature of a BLP, and policy on the lead says the lead should be able to stand on its own. It’s obvious that a denial is often simple and straightforward and wouldn’t require more than three words. I don’t need to take a step back, it seems a perfectly legitimate topic of discussion here, and I hope the situation will be improved one way or the other. Perhaps we can agree that if an error is made regarding whether to put a denial in the lead of a particular BLP, it would be better to err by putting it there than to err by only having the accusation in the lead. Anythingyouwant (talk) 03:03, 11 June 2026 (UTC)[reply]
I think it's a moot point. WP:DUE is core policy and is non-negotiable; we cannot have policies that require or circumvent it. And DUE is based only on the sourcing, not on editors' personal opinions about what is significant (as expressed in essays or, indeed, non-core policies.) That means that in situations where the sourcing plainly makes it WP:UNDUE to put a denial in the lead, it cannot be placed in the lead. This would remain true even if someone attempted to edit BLP to require denials in the lead unequivocally - DUE would still override it in cases where doing so would be clearly undue; and DUE, as part of NPOV, is non-negotiable core policy, so it cannot be change to require this, and would override even another policy (even a very weighty policy like BLP) unambiguously trying to force something into the lead without regard for sourcing. This has been hashed out before with WP:WTW - people have sometimes tried to use it to argue that something must be attributed even when conceding that the sourcing unequivocally establishes it as uncontested fact, per WP:NPOV's Avoid stating facts as opinions. They have always, when they took that route, lost, because NPOV trumps WTW. The same principle applies here - we can set a very high bar; we can advise extreme caution. We can write policies under the assumption of "well, with this thing it'll never be so clear-cut as to put this policy in direct contradiction with NPOV." But when that does happen, no policy can ever directly instruct editors to ignore or override the weight of the sources completely, and any attempts to do so will fail in practice. The ultimate arbiter for weight and placement and inclusion is always the sources themselves, and no policy can completely overrule that. --Aquillion (talk) 03:00, 18 June 2026 (UTC)[reply]
Some thoughts. I am certainly not of the opinion that denial should be mentioned in every BLP case with conviction, in an ideal world. Things we might consider:
While the legal principle "innocent until proven guilty" applies in some jurisdictions, it does not apply in all.
Some systems are manifestly corrupt.
Further we know that even in the best systems innocent people are found guilty and guilty people are found innocent.
Denial of one thing is not denial of another. Often many counts are brought together.
Sometimes someone is found innocent in a privately brought criminal prosecution, although they are found guilty later. For example one of Stephen Lawrence's murderers.
If someone was found guilty of a minor crime, how they pled may not be significant. For example a minor traffic or parking offence.
If someone has a very long history, for example was found guilty dozens of times of shoplifting, their pleas may not be readily available, and may overwhelm the statement about guilt if they need to be itemized.
Is a cast-iron rule a good way of ensuring the above are dealt with, or does it just create more un-necessary verbiage?
The community generally recognizes that it is good practice to provide notification of a discussion at a centralized noticeboard when a specific article is being discussed, but the community is generally against requiring notifications. For example, they aren't required for any of the deletion processes. voorts (talk/contributions) 02:20, 10 June 2026 (UTC)[reply]
Bizarrely, we require notifications if you're dragging an editor to AN/I or Arbcom (but not if you're saying they're a sockpuppet). But you don't have to tell the talk page if, for example, you're discussing the sources on RSN, or the formatting at some obscure subpage of the Manual of Style where a "consensus" of three editors is about to reach a decision that will bugger up thousands of pages. I think these rules aren't very well thought out, though.—S MarshallT/C17:23, 10 June 2026 (UTC)[reply]
That's what has bugged me a while. There is A) no uniformity/standard and B) what we have seems decidedly arbitrary.
Like, if you're sending an article that has 3000 watchers to RSN, NOR, BLP or FTN boards for content issues (especially with no prior talk and editing engagement there in any recent memory), it feels really odd to bring in outside consensus views without allowing the local talk watchers to be fully aware and participatory.
You're conflating a lack of notification requirement with editors being in favor of not providing notice. As I said, the community thinks notifications are a best practice but routinely rejects extending those requirements to new areas. It is what it is. This discussion won't go anywhere IMO. voorts (talk/contributions) 17:43, 10 June 2026 (UTC)[reply]
What's your basis for saying the community routinely rejects extending notification requirements to new areas? Have there been RFCs or something about this recently? FWIW, I think OP's idea is a good one, at least for certain types of noticeboard threads (particularly content ones, like RSN, NPOVN, etc.). Levivich (talk) 18:12, 10 June 2026 (UTC)[reply]
Yes, there have at least been other discussions like this. I don't remember where. It may have been regarding speedy deletion. I'm fine requiring notifications, but I think it would be an uphill battle. voorts (talk/contributions) 18:23, 10 June 2026 (UTC)[reply]
Notifications are required for deletion processes: when an article is AfD'd, there's a notice on the article itself. (And also, centralized notification at WikiProject pages and elsewhere.) Seems to me to make sense to post, eg, a notification at article talk pages when sources used at that article are being discussed at RSN. (I'd rather have a bot or script do it, à la XfD, rather than require a human to do it manually.) Levivich (talk) 18:16, 10 June 2026 (UTC)[reply]
At least some notification is required. For example, tagging the article (which is notification) is required by AfD Step 2. The same step also requires listing it in the AfD log (a centralized notification). Step 3 is called "notify interested parties" (delsorts, WikiProjects, and individual contributors), and while Step 3 is not required, it is almost always done, because Twinkle does it and almost everyone uses Twinkle. My point is that under XfD procedure, some notification is required, the notification that is not required is nevertheless widely done, and all of that says to me that the community does indeed want and value notification. I do not believe the community is generally against notifications. Levivich (talk) 21:22, 10 June 2026 (UTC)[reply]
All I'm saying is that there are many editors who have been vocally against requiring notifications in other contexts. I'm not opposed to such a rule, but I doubt it will gain consensus. voorts (talk/contributions) 21:45, 10 June 2026 (UTC)[reply]
Do you recall if they objected to the action requirement being directly on them to do the thing, or was it opposition to a proposed standard that if Article whatever gets invoked for a discussion on say WP:RSN, that the local Talk:Article whatever folks must be informed/told so they can participate in the "off venue" chat?
It's two different things. I can see resistance (though I can't fathom why anyone would resist it) to the rule being on THEM to do it, but I can't possibly see any justification for the latter. If no one opposed the latter then this is a bot-level problem to fix probably? — Very Polite Person (talk/contribs)21:55, 10 June 2026 (UTC)[reply]
I don't know exactly how notification bots work but I assume they are triggered by the structured nomination templates at forums like RM and XFD. Almost all other notice boards and discussion forums I can think of have pretty much free-form posts and not formal "nominations". And I would object to complicating the discussion procedure by introducing formalized, structured nominations as a requirement for posting on most discussion pages. —Myceteae🌈 (talk) 23:53, 10 June 2026 (UTC)[reply]
From what I recall, the context of the discussion was CSDs and the objection was that this should be discretionary, while acknowledging the norm that it's usually appropriate to notify relevant pages. I can't find the discussion. voorts (talk/contributions) 23:58, 10 June 2026 (UTC)[reply]
Yes, that is the choice of each WikiProject. Some WikiProjects are okay with talk page notices; some do not want them at all. I don't see any reason to change the status quo. voorts (talk/contributions) 00:17, 11 June 2026 (UTC)[reply]
Just to be totally clear, my suggestion was Article talk page notifications if the article came up on a central board - specifically to prevent isolated clusters of competing consensus and so all editors are nominally /forced/ to equal procedurally/awareness footing at all times. — Very Polite Person (talk/contribs)00:21, 11 June 2026 (UTC)[reply]
It seems like a basically sound idea to me, although I admit there may be some hidden downside I'm not thinking of. I think it would prevent some perverse behavior.
Sometimes people will misuse WP:CONLEVEL to reach a local consensus on an article that contravenes policy. But sometimes, too, people will go to a noticeboard to "pre-win" some argument they're having on a talk page, by presenting some rather self-serving version of the argument and getting everyone to agree that of course the policy shouldn't be applied that way, et cetera. A classic move if you are losing an RfC is to go to some policy page and quickly roust up a consensus that the RfC is invalid because it violates WP:OMGWTFBBQ... jp×g🗯️08:19, 16 June 2026 (UTC)[reply]
What we quite often get is people bringing things to policy talk pages, but stripped of context. Two editors get in an argument over whether the Patterson-Gimlin tape was faked, and then one of them comes to WT:V to ask, "Should Wikipedia publish unproven speculation and rumour?" and the other one goes to WT:NOT to ask, "Should we censor widely published information just because some people don't believe clear evidence?" (Basically, if anyone comes to a policy talk page or RSN to ask a question "in principle", it's best to go over their recent contributions and work out what arguments they're currently involved with before you reply.) I think that any proposed rule requiring notification on the article talk page would need quite thoughtful phrasing to ensure it has the intended effect.—S MarshallT/C19:06, 10 June 2026 (UTC)[reply]
I think that any proposed rule requiring notification on the article talk page would need quite thoughtful phrasing to ensure it has the intended effect. I agree. There should almost always be a notice on the talk page of an article that is being discussed at a content notice board. For behavior issues, it's perhaps a little more complicated. If an editor's current or recent behavior at a particular article or its talk page generates an ANI report then other editors who have been involved or impacted should be made aware but I don't know that this should always be memorialized on the article talk page. For content notice boards, this would seem uncontroversial and I think it is not too onerous most of the time but there may be exceptions and I would want to think through the scope, purpose, and implications of following or not following a new requirement for notification. —Myceteae🌈 (talk) 23:44, 10 June 2026 (UTC)[reply]
We would need to word it so that it covered only actual discussions and not just calls for attention. A non-trivial portion of the posts at noticeboards are of the "We could use eyes on this article" or "we could use experienced input on this talk page" variety, and that really shouldn't require a notice. What are the other editors from the article going to say, "no, we don't want anyone else looking at it, stay away"? That's different from an actual discussion on the noticeboard. -- Nat Gertler (talk) 12:43, 11 June 2026 (UTC)[reply]
Forgive me, in what theoretical scenario of a discussion (vs a notification) of something going down on a talk page of an article, related to content, that is discussed on a noticeboard... where the article/talk participants shouldn't be made aware of the bridged/side discussion? — Very Polite Person (talk/contribs)16:14, 11 June 2026 (UTC)[reply]
For example, where you have reasonable grounds to suspect that a high proportion of the article/talk participants have a point of view or what Wikipedians miscall a "conflict of interest".[1]—S MarshallT/C17:46, 11 June 2026 (UTC)[reply]
[2] A high proportion of the article/talk participants or just a single person who bludgeoning the discussion by posting many more comments that anyone else on the talk page? --Guy Macon (talk) 03:48, 18 June 2026 (UTC)[reply]
I don't know that I would go so far as to say that article/talk participants shouldn't be notified. But I see a material difference between posts that reduce to "What should we do with this article?" versus "Please take a look at this". In the first instance, where there is a substantive discussion about the article content that generates (or may generate) a decision about how to edit the article, I think there should generally be a notification on the talk page of the article in question. In the case of "Please take a look" where there is no additional discussion or decision making, I think it is probably best to leave a notice but is less important. And even in the first instance ("What should we do?") there probably needs to be room for discretion and practical consideration. For example, a discussion on the talk page of a WikiProject or policy or guideline may impact dozens, hundreds, or even thousands of pages and notifying each and every one may be impractical. —Myceteae🌈 (talk) 20:06, 11 June 2026 (UTC)[reply]
It's worth pointing out that we do already have policies and guidelines against non-neutral notifications, I think. I wrote an essay about a particular form of this I sometimes see, WP:MOTTE; in general I feel that part of the solution is for experienced editors to be cautious when they see someone (especially another experienced editor, who ought to know better) asking a question which on the surface seems to have a very obvious answer. I've often found that when I see that and I dig into it, it turns out that there's a much more complicated underlying issue. That said, I don't think notification would help - the real problem with such discussions is that they often end up wasting people's time to no end, because when eg. the editor who brought the discussion over whether something was WP:DUE to RSN triumphantly returns to the article where there was a conflict and says "look, look, RSN said my source is reliable!" the person they were in dispute with will just go "...yesssss, but my objection was that this particular use of it was undue?" And then the dispute continues with that digression having accomplished nothing. Such interactions frustrate everyone involved but a notification wouldn't usually solve it. --Aquillion (talk) 03:27, 18 June 2026 (UTC)[reply]
Imagine that you run into a situation where an article talk page has huge problems -- an editor bludgeoning the discussion, a couple of editors flinging insults at each other, someone pushing a company, religion, or political view, or maybe just a bunch of well-intentioned new editors who think "reliable source" means "source that agrees with me."
In the middle of this huge fight you see something that makes you think "Hmmm. Is that source reliable for that claim?" so you pop over to RSN for a calm, reasoned discussion with a group of experienced editors who understand the subtleties of evaluating sources. In some cases inviting the disruptive editors who are tearing up an article talkpage to come on over and pull the same shit on the noticeboard is a very bad idea.
It's good practice to notify relevant pages, whether that's an article's talk page, a WikiProject, or any other places that's relevant, but I don't think this should ever be made a requirement. Not only does this not fit with other expectations, there's very places that say editors 'must' do something, but would likely to open to abuse and wikilayering over what should have been notified. -- LCU ActivelyDisinterested«@» °∆t°17:14, 14 June 2026 (UTC)[reply]
Yeah… I worry that if we make notification mandatory, wikilawyers will try to “negate” a consensus at a noticeboard on the technical grounds of “bad consensus - no notification”. Blueboar (talk) 10:25, 16 June 2026 (UTC)[reply]
^What Wikipedians call a "conflict of interest", isn't. Wikipedia is not your client. It is not your customer. You do not owe Wikipedia a fiduciary duty. You do not owe Wikipedia a higher duty than you owe to your employer, or employees, or your country, or your monarch or republican equivalent. You have a basic moral responsibility to tell the truth, and we'd prefer it if you owned up to your financial interests or biases, but that's laughably far from adding up to a "conflict of interest" situation.~~~~
^I object to the above editorializing in a ref. I think you should express your opinions in inline signed comment just like everyone else. Using a ref gives one voice undue prominence. --~~~~ Plus, the signature function doesn't work.
Recent changes to WP:LLM are too restrictive and actively harm some parts of Wikipedia
A bit of background: I primarily edit medicine articles on Wikipedia. There are not many people who are regular contributors to WP:MED, only ~100-150 in the past month, but these pages are relied on by countless thousands of users. There is a need to keep them updated, high-quality, and well-supported, but not enough qualified people to make those edits.
LLMs are a force multiplier. They allow us to conduct literature reviews, draft text, and produce high-fidelity articles that are both scientifically accurate and readable by a general audience. They allow us to make meaningful expansions to a section or page in under half an hour, on a lunch break or a day off. And there is a way to do this that is quite productive: feeding the LLM academic articles, and instructing it to use that text to add the type of content you want. Let me give you an example. This diff, which I have self-reverted after reading the recent LLM policy update, was the product of feeding Sonnet 4.6 (a robust flagship LLM) the cited article and instructing it to add content to the existing version of the pathogenesis section. As a result, it was a major expansion of the section, completely compliant with the source. I believe it is very hard to claim that this diff was detrimental to the page or non-compliant with Wikipedia policies other than the policy preventing LLM usage wholesale; and since that non-compliance is the ostensible reason justifying the blanket ban, I think this diff also demonstrates why the recent version of the policy needs major revision.
I also acknowledge the problem of slop. This affects medicine pages too, but I'd bet it is a bigger problem on articles that are less technical in nature, since people tend not to feel qualified to edit technical articles on unfamiliar subjects. This serves as the foundation for my second idea, outlined below.
To find a more balanced equilibrium, I have the following (draft) proposals, which at this time are generalized ideas on how to edit the policy, and which I think could be discussed and built into something more concrete. I am also willing to volunteer my time to create prompts, rulesets, etc as needed, if some or all of these were to go through.
Create an official Wikipedia prompt for LLM use in editing. System prompts are guidelines for LLMs that have high impact on how they function, and which are rarely if ever violated by the LLM. A robust system prompt can implement guardrails against all specific objections I have seen in previous RfC discussions about allowed LLM use. This would be a major project, probably involving multiple people who are familiar with both LLM functionality and Wikipedia editing principles.
Restrict LLM editing usage to certain domains and/or projects on Wikipedia. WP:MED is the one I'm familiar with, but I'd imagine that many other scientific domains will benefit in similar ways. This may be a good option because people making large contributions to these pages already tend to be abiding Wikipedia policy, have higher standards for references, and are capable of cross-checking output text against peer-reviewed articles. This could also be taken a step further, by only whitelisting active and listed participants in scientific WikiProjects; I dislike this sort of gatekeeping, but I think it could assuage some concerns.
Expand allowed forms of LLM editing to allow LLM-generated content under specific conditions. The primary condition I'd propose is the one seen in the diff I linked above: already having found an appropriate reference, feeding it to the LLM with the intent of making specific directed edits based solely on the contents of that reference document. I'd also like for literature searches to be explicitly allowed (I think the current guidelines allow for this, but it's not clear).
Limiting LLM editing to specific models. I would propose these be Claude Sonnet 4.5+, Claude Opus 4.5+, and GPT-5.4+ (note: this is not the same as ChatGPT, which is a different OpenAI model). I don't think it's necessary or appropriate to exclude GPT-5.X (non-pro) and Claude Sonnet, since beyond this point cost becomes prohibitive and the differences in quality when references are provided are negligible at best. This already represents a massive step up above the models that are most commonly used for editing on Wikipedia.
I don't think I'm ready to formulate these into a concrete and actionable proposal yet, and would like to get some additional input before doing so. My intent is to create a framework that helps people to use LLMs for appropriate, beneficial, and policy-compliant Wikipedia page editing and creation, with well-elaborated rules that establish clear lines between what is and is not acceptable use. As it stands, the policy is overly restrictive and is detrimental to technical articles. Just-a-can-of-beans (talk) 20:09, 13 June 2026 (UTC)[reply]
was the product of feeding Sonnet 4.6 (a robust flagship LLM) the cited article and instructing it to add content to the existing version of the pathogenesis section. Why not just feed the LLM the articles and ask it to generate notes with page citations for yourself so that you can then read those particular pages and write your own NPOV and MEDRS compliant content? voorts (talk/contributions) 20:58, 13 June 2026 (UTC)[reply]
Basically it's a time concern. I'm busy. Most people qualified to write and edit medical pages are busy. If I can find it a good source, feed it the PDF, and then just verify that all the information matches up with the source, this saves me a lot of time compared to typing it all up myself.
Re: [Slop] affects medicine pages too, but I'd bet it is a bigger problem on articles that are less technical in nature, since people tend not to feel qualified to edit technical articles on unfamiliar subjects. and the proposal to restrict this to MED and similarly technical topics – I'm skeptical of the premise. One of the problems with LLMs is that they facilitate the generation of massive amounts of superficially good-sounding text by people who lack the domain expertise (or writing proficiency) to effectively evaluate the end product. The LLM ban maintains the barrier to entry that, in your experience, is what keeps problematic contributions to a minimum. I also don't agree that it's true in the first place that MED articles don't attract problematic content, whether LLM-generated or otherwise. This is probably true for a rare disease like adrenoleukodystrophy but many alternative medicine and general medical or scientific topics are magnets for fringe claims. Many topics and articles that are not strictly under the MED umbrella contain biomedical information that is subject to higher WP:MEDRS standards. This includes many hot button "culture wars" topics that attract readers and editors with a wide range of backgrounds and motivations. I do think you raise some valid issues and I've not yet thought through the rest of it. I have some concerns about over-broad bans restricting quality contributions but I also understand that LLM-generated content is flooding the site and that creating too many loopholes or exceptions creates additional problems. —Myceteae🌈 (talk) 21:01, 13 June 2026 (UTC)[reply]
Just running this up the flagpole to see if anyone salutes (might be a terrible idea); what if we gave certain trusted editors permission to use AI, maybe after some training or perhaps passing a test? Take the permission away the first time they screw up. Maybe make them post the first N AI edits as a draft in userspace and ask someone else to review it and post it? --Guy Macon (talk) 21:44, 13 June 2026 (UTC)[reply]
Not saluting. What trusted editors can do is use LLMs for their behind the scenes research… this is OK because we trust them to double check what the LLM generates, and then take what they have checked and re-work it into something appropriate for WP. Blueboar (talk) 22:15, 13 June 2026 (UTC)[reply]
My understanding from the newest version of the guideline is that this is no longer allowed. I'd also argue that this isn't really how many would prefer to do things; it's relatively quick and easy for many medical professionals to find an academic source and read it and understand it, but it is quite time-consuming to actually type up an entire section. Hence why major medical pages can go years and years without significant contributions. Just-a-can-of-beans (talk) 20:42, 17 June 2026 (UTC)[reply]
Is that the full version of the flagpole expression? I've only ever heard the "run this up the flagpole" part before, and interpreted it like "run this up the totem pole" as in "run this upstairs to the higher-ups". Very interesting. ~2026-35116-29 (talk) 09:36, 15 June 2026 (UTC)[reply]
Shit flow diagram and Malacca dilemma were both primarily written with an LLM by a (I assume) trusted editor. There's a lot of work that goes into verification and such, but it is possible. Shit flow diagram is better than what I threw together years ago, and Malacca dilemma is certainly better than nothing at all. ScottishFinnishRadish (talk) 11:27, 15 June 2026 (UTC)[reply]
This is similar the second proposal in my initial post, which I don't agree with from an ethical standpoint because I dislike gatekeeping. But for both that and your suggestion, I do think they'd be effective if the broader community found them acceptable. Just-a-can-of-beans (talk) 20:38, 17 June 2026 (UTC)[reply]
Wikipedia must maintain high standards where possible. LLM use is a way to degrade and join the morass of AI slop, garbage and misleading text that is already prevalent now in journalism and on the internet. We need our editors to take full responsibility for the content. If LLM output is thoroughly checked by the contributor then it could be used. Our problem is when LLM output is not checked and the problems slip past. Graeme Bartlett (talk) 22:56, 13 June 2026 (UTC)[reply]
Alas the problems are likely to "slip past" in far too many cases. LLM output is typically far too large to be totally checked by humans. That is the whole point of LLM use: outrun humans. I would prefer policies that are extremely strict against LLM use. Yesterday, all my dreams... (talk) 15:45, 17 June 2026 (UTC)[reply]
This is completely untrue when using a flagship LLM under a properly constructed system prompt's guidance. This is applicable only to basic consumer-facing chat models that are not designed for professional use. I understand that many people do not know the difference, hence why one of the purposes of the proposals are to create a well-defined framework. Just-a-can-of-beans (talk) 20:35, 17 June 2026 (UTC)[reply]
I mean yeah, that's basically what I'm proposing here, a set of guidelines for responsible use, not a free-for-all. LLM use can be used to make slop but it can also be used by responsible professionals to produce more work, at higher quality. Just-a-can-of-beans (talk) 20:32, 17 June 2026 (UTC)[reply]
Wikipedia does not have high standards this is a false premise 95% of the articles on this cite are terrible. I agree that GA and FA should have high standards Czarking0 (talk) 05:31, 19 June 2026 (UTC)[reply]
While I have my reservations regarding the proposed policy (for example, the vast majority of regular LLM users will not be the kind of power users knowledgeable enough to configure a system prompt, and a much clearer line is needed to stem the tide), a more fundamental disagreement lies in what Wikipedia itself means, in the future. Our decision to ban LLM content was very positively received, and it is becoming clear that a Wikipedia by humans, for humans is desperately wanted, especially as people are increasingly skeptical of the "AI revolution" accentuating divides and making tokens the world's new currency. Like many others, I don't want a future where meaningful Wikipedia editing is contingent on having enough to spend on generating content at scale. Let's see the bigger picture here. Chaotic Enby (in solidarity · talk · contribs) 23:56, 13 June 2026 (UTC)[reply]
Keep in mind that this whole business of "pay one of six giant companies a boatload of money to run crappy AI on giant racks of servers in data centers" will inevitably turn into "pay the price of an evening out on a computer you own that runs pretty good AI free in your bedroom forever" and those six companies will collapse. I was there when the company I was working for bought a Wang Word Processor (see Wang Laboratories#Word processors). It was very expensive, but so was retyping entire documents on a typewriter, which is what it replaced. Anyone reading this editing text on a Wang? Anybody? We will need to rethink things as the technology changes. --Guy Macon (talk) 01:15, 14 June 2026 (UTC)[reply]
On the other hand… I can remember when the laser disk was being touted as future of home entertainment. LLMs may turn out to be a dead end… tech nobody wants. Blueboar (talk) 01:37, 14 June 2026 (UTC)[reply]
The only way LLMs end up that way is if an even better AI platform supplants them, in which case we will be debating the use of that platform on Wikipedia. BD2412T12:18, 14 June 2026 (UTC)[reply]
ln time most technologies will be improved or superseded, but may have a long life. Newtonian mechanics ideas were considered flawed by relativity theory but are still used in every car on the street. From a practical point of view LLM techs have gathered so much investment that their momentum is hard to ignore, despite their amazing computational inefficiency. So let us not consider them dead while they are still breathing. They will be a problem for crowd sourced efforts for sure. Sigh... Yesterday, all my dreams... (talk) 15:38, 17 June 2026 (UTC)[reply]
I disagree with this fundamentally. It should not matter how the content is written, all that matters is how strong Wikipedia can be for the reader. If taking a stand about subjective personal ethics means a measurable decrease in overall utility of Wikipedia, then it could be said that these ethics are harmful to Wikipedia.
Further, I find the line of thinking about cost and access to be inherently invalid. Nobody is forced to use these tools - the idea is just to create a tightly regulated pathway for those who do wish to use them. The decision to ban LLM content was very positively received... by those who participated in the discussion, who are largely those users who care about LLM use in the first place. In other words, there is a strong element of response bias at play. That being said, it's not an unpopular opinion by any stretch, which is why I'm requesting here something that would allow only a limited form of use, and why I've sought feedback here.
Your priorities are mixed up here, the argument it is not if LLM's could help Wikipedia, the argument is if they could harm Wikipedia. While this sounds like semantics these are very different arguments. This is a tad bit extreme of an example, but I feel it helps illustrate this point. Sure, an axe murderer killing a certain man with a mustache who failed art school would absolutely not be condoned if the public knew what he was to do eventually, but I still don't think we condone axe murdering. AI, while with some human help, can produce good content, can also do the opposite just as much if not more frequently when it comes to BLP and CTOP. In a perfect, idealistic world, using an LLM would be a-ok on Wikipedia as everyone would make sure the content it provided was good, but we are not in that world. Even the good AI-generated content generally takes more time to convince the AI to write factually without errors, then to just write it yourself. AI does also not source information well or sometimes not at all, making this take even longer. Sure, if 25% of AI content added to Wikipedia is good, (and that's a unrealistic number; Wikipedia is drowning in bad hallucinated AI edits) that's all fine and dandy, but if the rest is bad, then sometimes we simply have to make a blanket rule in hopes of catching as much errors, vandalism and what-have-you on Wikipedia. If we analyzed every AI edit on Wikipedia, we would never get a thing done around here.Ilov3gam3z (talk) 20:19, 17 June 2026 (UTC)[reply]
Should a medicine be banned because a small fraction of people get severe side effects or an allergic reaction to it? The argument is about the net good or bad to Wikipedia. I contend that there is a very strong potential for good, and when used appropriately, a very weak (if present) potential for bad. If you are about to argue that people would not follow these guidelines, this is a fallacy, because they're not going to follow the existing wholesale ban either. The ban only affects editors who care enough to read and abide Wikipedia policies and guidelines.
I don't know if you've actually read through my proposal to be honest, because it directly addresses most of what you've written here, and other things (such as bad sourcing habits) are irrelevant to the proposals I've made, which are specifically in a framework of not allowing the LLM to source material. Just-a-can-of-beans (talk) 20:30, 17 June 2026 (UTC)[reply]
"a small fraction of people get severe side effects"
This is, wrong? Like literally just wrong. This is not a 'small fraction' in any way whatsoever. I would say when it comes to premium LLM's, they are still not good enough to evade these problems. While topics with immense amounts of research and coverage, sure, can be written about fairly decently by AI (even flagship), niche topics (which is a good bit of Wikipedia, to be honest) has been a pain point with AI for quite some time, and top-of-the-line models still have problems with this exact issue. This whole 'flagship vs non-flagship' argument is not a good train of logic, as all AI's are fallible, (and much more fallible then humans) but they are especially fallible when a topic has less information on it online. No flagship, nor currently existing LLM, can evade this issue. Also, this aside, one of the main issues is aesthetics. AI writes very differently from humans, and this can be a turnoff for many people. One of those is myself. AI uses words people don't use very often, techniques and sentence structure that people also don't use very often, and in general something written by an LLM sounds very AI. Yes, all the techniques used by AI are good and together are better, but no person writes THAT well, and uses THOSE rare techniques that much. It becomes an uncanny valley of sorts. Even your example diff has this clear problem, I would instantly flag that article as written by an LLM, it reads like it. Also, I know you are responding to everyone at once, but I feel you are not adequately reading and addressing the concerns of all the people against this, which let's face it: is the majority. Some of your responses come off as genuinely hostile and not in good faith. Remember WP:BATTLEGROUND. I would advise you (not trying to be condescending here) to take a step away and take some time to read and maybe edit your proposal to try and address the concerns. Ilov3gam3z (talk) 21:46, 17 June 2026 (UTC)[reply]
There is probably some response bias at play. Sure, editors who care the most about this have been most involved in crafting the current guideline and are most likely to be interested in this discussion. My observation, as someone who does not spend a lot of time on LLM problems, is that many editors have objected to such broad bans. Over time, as the AI problem grows, and as attempts to define more detailed rules and exceptions have failed to to concerns about implementation and interpretation, is that the community has come around to accepting this broad and straightforward ban. I'm someone who has been, and remains somewhat, uncomfortable with it, for reasons similar to yours. But I accept that the current ban reflects consensus, meets a pressing community need, and that alternative proposals to date do not address the problems. Several editors have provided substantive critiques of the details of your proposal, which you have not engaged with. Dismissing every single one of us as biased as though we speak with a single voice is neither accurate nor constructive.. —Myceteae🌈 (talk) 20:38, 17 June 2026 (UTC)[reply]
In fairness to OP, it looks like you've just returned to this thread and started responding. But still, I find fault with the blanket characterization in the response I replied to. —Myceteae🌈 (talk) 20:43, 17 June 2026 (UTC)[reply]
I think you have some wisdom here. As someone who was opposed to the LLM ban and did not even see the discussion for some of the consensus, I believe a minority of the active editors care a lot about banning LLMs. In part they want the ban for the harms LLMs bring to wikipedia, but they also want the ban because they are opposed to LLMs in every aspect of their life. They constantly started new and very lengthy discussions that most of the editors are not really interested in participating in and they would have continued to do so until they got the total ban.
The fact that we ban LLMs but not paid editing goes to show how much less the current generation of policy leaders is willing to think about nuance in our policies than the previous ones were. Czarking0 (talk) 05:39, 19 June 2026 (UTC)[reply]
I, too, missed the discussion which resulted in the current version of the guideline. Part of me was surprised to see it had gone live, given the opposition I have seen (and offered) to such bans in the past. But perhaps it was inevitable. I am sympathetic to the editors who spend a tremendous amount of time cleaning up after AI crap that floods the project. In theory there are acceptable use cases even but I understand that the sheer volume of bad content and the work required to review, verify, and fix it makes a broad ban much more workable. I'm at a state of uneasy acceptance. —Myceteae🌈 (talk) 02:31, 20 June 2026 (UTC)[reply]
"I'd bet it is a bigger problem on articles that are less technical in nature, since people tend not to feel qualified to edit technical articles on unfamiliar subjects" doesn't gel with how llms seem to be used. People make the most use of them in topics they don't understand, relying on the llm to do the understanding. The promoted example of WMF's own experiment with llm text in mainspace was a MEDRES article. CMD (talk) 02:22, 14 June 2026 (UTC)[reply]
At the moment LLM issues are considered "problems" but in time will become "nightmares" for crowd sourcing. We must take a very strong stand against them, unless we all like nightmares, I do not. Yesterday, all my dreams... (talk) 15:56, 17 June 2026 (UTC)[reply]
As it stands, the policy is overly restrictive and is detrimental to technical articles.
I appreciate your concerns about this "policy" (ahem... guideline), and I admire your acknowledgment on issues with AI slop. Nonetheless, the consensus overwhelmingly favored extending the rule from only new LLM-generated articles to rewriting an existing one with LLM-generated content. I even favored extending the scope of the rule. I dunno how many threads like this we will see in the future, but I can't stop them until this matter will be considered a perennial issue. Better yet, we're still in a very long road until the time the consensus changes its mind about LLMs. —George Ho (talk) 03:10, 14 June 2026 (UTC)[reply]
I've observed that both Claude and GPT have strong safeguards in place about these topics specifically, but the crux of the argument is still valid. Hence why I proposed a source-provided model of text generation. If the model is given 1-3 high quality academic source PDFs and told to construct a particular section of a particular page, using only information which is taken directly from those source articles, it will avoid these things. The models are pretty good at following directions when you instruct them to avoid drawing any conclusions or relying on any information outside of source articles. Just-a-can-of-beans (talk) 20:25, 17 June 2026 (UTC)[reply]
I'm not convinced that creating official system prompts or whitelisting models is the right fix. System prompts might help the AI fit in, maybe even get it to use higher quality sourcing, but they never stop hallucinations and inaccuracy. Limiting LLM use to specific topics does nothing as well AI can and will introduce inaccurate info na matter the topic and most people wont check even on medicine articles. I do agree that the current AI guidelines and rules are to restrictive in some ways but I do not think this is how or the way to fix it. I find it acceptable when LLM output actually is checked by someone knowledgeable, but most of it isnt. Like Graeme Bartlett said Wikipedia must maintain high standards where possible. This proposals does not address these issues. Luka Maglc (talk) 06:50, 14 June 2026 (UTC)[reply]
What do you think of a guideline update that specifically allows text generation or editing based on a provided (user-sourced) academic source? With explicit instruction to only utilize information available in the document. It seems like this would address a lot of the other concerns I've seen in these comments and I'm curious what you think of the idea, since you seem to have a good understanding of LLM-related concepts and limitations Just-a-can-of-beans (talk) 21:14, 17 June 2026 (UTC)[reply]
One of the problems is the particular type of hallucination; an experience from work had an LLM cite a paper. Correct paper, incorrect author list. Unless you know about the field, those sort of errors can be hard to catch. Red Fiona (talk) 07:43, 14 June 2026 (UTC)[reply]
Comment: The best way to use AI I've found is as a reviewer. A prompt I've used is "You are an expert of ______ known for being harsh, precise, and demanding. You are asked to peer-review the following text: ____." Another is "You are an expert of _____ asked by a colleague to proof read their writing. Review the following draft and provide recommendations for improvement: ____." I use these as a filter before sending text off to be proofread by a human. I've found that changing "a colleague" to "your student" sometimes gives better results, but not always. This is the kind of use I can see AI being helpful with on Wikipedia, not generating original text. Fundamentally, Wikipedia was likely used to train most if not all of these models, so we're just feeding Wikipedia back into itself if we use it to liberally to generate new content. GeogSage (⚔Chat?⚔) 08:48, 14 June 2026 (UTC)[reply]
You'd be surprised, the top models have actually been fed entire academic databases. I've seen Opus accurately cite obscure medical information with correct DOI links and everything. Still iffy on the cites outside of that anecdote, but the actual knowledge base is very solid Just-a-can-of-beans (talk) 21:10, 17 June 2026 (UTC)[reply]
No doubt, I've seen it give some impressive suggestions for citations using it as a "reviewer." I've also seen it hallucinate sources, or make up stuff and misattribute it. The problem is that you need an expert human in the loop to catch some of these mistakes. It isn't really a huge time saver if you need to rely on accurate outputs, it can be useful to polish existing work though. Like, if you write something organically, asking AI about what could be improved isn't going to hurt anything (worst case, you ignore the suggestions) as long as you don't take the suggestions at face value. GeogSage (⚔Chat?⚔) 05:18, 18 June 2026 (UTC)[reply]
And then we must consider other editors' time required to review and possibly clean up any such contributions. Another editor below raised the case of an editor who was viewed (not without controversy) as generating high quality, acceptable LLM contributions to a large number of articles in under-covered technical fields. It proved too good to be true and has created a massive amount of work for the community. —Myceteae🌈 (talk) 15:29, 18 June 2026 (UTC)[reply]
That will be a problem beyond Wikipedia. Self published (or low quality) books or blogs with LLM content will grow like mushrooms, and will become input to other LLMs. How do you spell nightmare? Yesterday, all my dreams... (talk) 06:10, 18 June 2026 (UTC)[reply]
NO. LLM-generated content, especially medical content, should never be permitted here under any circumstance. I can't believe this is even a discussion. JoelleJay (talk) 13:26, 14 June 2026 (UTC)[reply]
It's not very helpful to make such a strong statement without providing any reasoning. The fact that others agree to it, also providing no reasoning, may demonstrate that community consensus in this case is a product of hysteria. Just-a-can-of-beans (talk) 20:05, 17 June 2026 (UTC)[reply]
The reasoning should be obvious from what others have said here and from the many other discussions the community has had on genAI. We went two decades without having LLMs, we don't need them now. So what if it hypothetically takes us longer to write quality articles ourselves than if we were assisted by AI? I'd rather that be the case than a single LLM-generated article come out where we must trust that the "author" had sufficient expertise (and for very technical medical topics that would mean an MD or PhD with several years of postgrad experience in that area(*)) to evaluate the output. What is much more likely to happen (and is already happening) is editors who don't have the necessary expertise and thus historically didn't have the ability to write efficiently on a certain topic would nevertheless feel qualified "enough" to guide an LLM-generated summary. And then, because it's a niche topic, it doesn't get evaluated by an actual expert and any errors subsequently get consumed and propagated by other LLMs. And the time the editor would have spent painstakingly understanding the topic enough to summarize it themselves will instead be put towards more lazy LLM-generated creations that never get properly validated. (*)In some previous thread I linked to a study that examined how well medical trainees/professionals were able to detect errors in various different AI-generated diagrams of the heart. IIRC the results were that med students, nurses, and interns/residents gave a passing accuracy grade to some highish (20-50+) percentage of diagrams, attendings in adjacent but non-heart-specific fields passed fewer, and experienced cardiologists passed almost zero. JoelleJay (talk) 16:30, 18 June 2026 (UTC)[reply]
So the detection of AI errors clearly relates to the expertise of the human evaluator. Not surprising but a source would be good. Would you like to add this source to the "top 10 list" below? Thanks. Yesterday, all my dreams... (talk) 20:36, 18 June 2026 (UTC)[reply]
This is the study I was referencing. It's on AI-generated diagrams of various congenital heard defects. From the abstract: The nurses and medical interns were found to have a more positive perception about the AI-generated cardiac images compared to the faculty members, pediatricians, and cardiology experts. From the body: Medical students, interns, and residents were significantly more likely to perceive the images as anatomically accurate, find the illustrative text useful, and consider the images both usable for medical education and visually appealing compared to other evaluators (p-value < 0.001) Nurses found the images notably more attractive and useful for medical education, and they also rated the accompanying text as highly useful, compared to other groups of evaluators (p-value < 0.001). [...] Conversely, the cardiology experts were significantly more inclined to perceive the images as (inaccurate, not attractive, not for medical education and their illustrative text being not useful) compared to the other evaluators. [...] In comparison to cardiology experts; the nurses perceived images more positively with [significantly] the highest relevance score compared to cardiology experts (34.1% higher p < 0.001), followed by medical students/interns/residents (26.6% higher p < 0.001), then faculty staff/academician (15.5% higher p < 0.001) and pediatric consultant/specialist ( 14.5% higher p < 0.001). JoelleJay (talk) 14:00, 19 June 2026 (UTC)[reply]
I also acknowledge the problem of slop. This affects medicine pages too, but I'd bet it is a bigger problem on articles that are less technical in nature, since people tend not to feel qualified to edit technical articles on unfamiliar subjects.
No, it's the exact opposite; on less technical topics, the (inevitable) errors and source-to-text integrity problems are easier to identify and fix than topics that require greater subject matter expertise to do so. I don't even know if there's more than a handful of people's worth of overlap between people knowledgeable about medical topics and people who do AI cleanup. Gnomingstuff (talk) 05:41, 15 June 2026 (UTC)[reply]
One question about LLM use that I have always had is what degree of reliability folks want from a LLM before allowing it to edit/rewrite an article. Errors aren't a purely machine phenomenon, humans do them too. I know about the scale issue but scale in the past has been an issue with human editors too. Jo-Jo Eumerus (talk) 12:54, 15 June 2026 (UTC)[reply]
The problem isn't errors. The errors are a symptom of the real problem, which is that LLMs (fundamentally, unchangeably, by nature of their architecture) can never be reliable. They can never stop lying. They can never notice when two things they say back-to-back directly contradict each other. It's absurd to trust such a machine with any task that relies on verifying that written words align with sources.
I just recently responded to an AI-generated query by a user which stated that they were aware their draft was based entirely on primary sources and therefore wasn't fit for mainspace, and then just a few lines later asked for an experienced editor to check whether they had sufficient secondary sources to publish the article to mainspace. There's no logical component that allows the LLM to realise it just said the exact opposite thing. It's a glorified text-prediction algorithm. That's why there's all those viral clips of people asking it to count to 100 and it says "1, 2, 3, 4... all the way to 100" and then tries to gaslight the user into thinking it counted all the way (or it apologises, says it'll really do it this time, then does the exact same thing) Athanelar (talk) 06:22, 16 June 2026 (UTC)[reply]
The errors are in fact the problem, as one can see from pretty much every discussion on AI/LLM . LLMs (fundamentally, unchangeably, by nature of their architecture) can never be reliable. They can never stop lying. They can never notice when two things they say back-to-back directly contradict each other. It's absurd to trust such a machine with any task that relies on verifying that written words align with sources. definitively don't think that this is true at all and viral clips are not proper evidence that LLMs/AIs are inherently error-prone, let alone more so than human editors are. Wikipedia has been putting up with human fallibility for decades. Jo-Jo Eumerus (talk) 12:20, 16 June 2026 (UTC)[reply]
I think it's partly true and partly false. Whether hallucinations are an inherent an unavoidable aspect of LLMs is currently a hot topic, and there is plenty of researching suggesting this, eg. [1][2][3][4]. However, "They can never notice when two things they say back-to-back directly contradict each other" is false and easy to disprove: just give an LLM two contradicting statements and ask it if they contradict; at least some (if not most or all) of the time, it will correctly identify contradictions. Also, anyone who uses Claude Opus knows that it regularly spots mistakes in its own responses and self-corrects. Not always, maybe not even "often enough" but to say "they can never" do it is just not true. At least some of them do it at least sometimes, and there is plenty of work underway to attempt to improve this aspect. Now per the above research, some say that meaningful accuracy is unobtainable. I don't know if that's true or not, it remains to be seen. Levivich (talk) 16:07, 17 June 2026 (UTC)[reply]
As someone who has used a good bit of AI models, (Claude, ChatGPT and Gemini (mainly for tinkering and my own curiosity to push their limits)) for a decent peroid of time, other then what Anthropic is doing, (which is an anomaly when it comes to model quality) AI (and again, only in my experience) has gotten worse. Like, significantly worse. While modern AI models have gotten better at sounding less-AI and more human, Gemini specifically constantly conflates information that is unrelated with each other, says blatantly incorrect outdated information as fact, and if you are having a niche problem, just gives you patent unsourced falsehoods, and ChatGPT is just a joke now. Most decent LLM's are either locked behind a paywall (which many will not pay for, including me) or just don't exist (especially in Gemini's case). I am actually decently fine with Claude though, they are a major exception to the rule and the only slightly moral AI company I have seen so far. Ilov3gam3z (talk) 16:32, 17 June 2026 (UTC)[reply]
Have you really tried all the old models, though? Because I'm surprised that's your take-away. I think objective benchmarking, and pretty much all reviews I've ever read, support that new AI models are better than their prior iterations.
ChatGPT 4 was way better than 3 -- wouldn't you agree? And 4o hallucinates less than 4. 5 even less than 4o, plus there's much less sycophancy. It still hallucinates, too much for my liking, but it's better than 3 or 4.
As for Claude, Sonnet is way better than Haiku. I mean, just ask those two models the same question, and I think you'll agree that Sonnet gives a better answer than Haiku. And Opus is even better than Sonnet. Opus 4 in particular seems like a big step over Opus 3 (or any Sonnet or Haiku) in both hallucinations and sycophancy. I was busy and missed the two days when I could have played with Fable, and obviously I've never tried Mythos, but the reviews are that they are big improvements.
And that's without getting into the advanced of agentic AI. Claude Code and Claude Cowork are, in my view, amazing technologies that blow prior iterations out of the water.
Gemini, all versions, sucks, that much I agree with.
But I think a lot of the anti-LLM folks are judging based on the free version of Gemini and have never tried, eg, Opus 1M set on max. To be clear, even that still isn't good enough to write Wikipedia articles without careful human review. When I personally recently tested Opus 1M max on summarization, it failed miserably. But I do think they're getting better. We'll have to wait to find out if there's a ceiling and where it is. Levivich (talk) 16:42, 17 June 2026 (UTC)[reply]
Here's the thing; is the average Wikipedia editor going to pay for the better models? No offense, a very small portion of AI's userbase actually pays for the better models. The jump from ChatGPT 3 to 4 was definitely huge, but the jump from 4 to anything else has been relatively minor with the problems of AI still looming large. Claude is obviously an outlier here, but I cant imagine that Anthropic can keep this up much longer, as all the other AI companies at some point have had to scale back on free model quality, ads baked into the AI and much else. Also, users with AI subscriptions (specifically Claude) can use an amount of tokens much more expensive then the actual cost of the subscription. There is no way that they aren't operating at a cost deficit, and a pretty bad one, too. I personally predict that AI will get more powerful, but will become more expensive, and the free tiers will become even more of a joke then they already are. As most people use the free tiers, don't expect AI improvements to be really visible, as only some will have access to said improvements. On a side note, I am very skeptical of what Anthropic has said Mythos can do, it feels like a very baseless train of hype. Ilov3gam3z (talk) 17:05, 17 June 2026 (UTC)[reply]
I admit, I agree with every single word of that comment. You know, one thing that could happen but will probably never happen, is for the WMF to get free access to the highest quality paid tier AI for trusted editors, similar to the Wikipedia Library. Since the AI companies already pay the WMF for access to Wikipedia, you'd think a deal could be made for them to give us access to "the good stuff" for free. Never gonna happen tho, because I don't think the community wants it. Levivich (talk) 17:44, 17 June 2026 (UTC)[reply]
Flagship LLM makers pay licensing fees for academic content they use for training (though I think in some cases they received official permission for free). It varies a bit company to company, but both OpenAI and Anthropic take copyright and licensing seriously. Just-a-can-of-beans (talk) 20:51, 17 June 2026 (UTC)[reply]
pay licensing fees - Have we forgotten that one time a big-time AI company downloaded all of anna's archive a huge book piracy site? Ilov3gam3z (talk) 21:57, 17 June 2026 (UTC)[reply]
I could see the WMF and maybe Anthropic or Google teaming up on something of the sort but personally I just wouldn't see the use case and would probably never use it. Sure, the train of logic that goes "if you cant beat them, join them" has some good applications, (and I am talking specifically about using AI while the platform is already being flooded by AI misinformation) this is not really one of them. Fighting AI hallucinations with AI hallucinations is like fighting radiation with more radiation, not fighting fire with fire (which, misnomer, you CAN fight fire quite effectively with fire, but I digress). This is not to say AI has some okay applications at times, for all the hate on AI overviews in Google search, (which is semi-justified as when it comes to anything relatively niche, Gemini implodes) it does sometimes lead me to a Stack Overflow or Reddit post that does, in fact, solve the problem. I recently turned AI overviews off with extensions, though, as over time it kind of did this oh, it's really bad!' 'oh, it's really good!' 'oh, it's even worse! thing. This does not mean I am for the proposal, though, this is simply just a bit of nuance. Ilov3gam3z (talk) 18:15, 17 June 2026 (UTC)[reply]
Usage cases might include research, checking scripts for bugs, proofreading, maybe some agentic stuff (eg for vandal or sock fighting). Levivich (talk) 19:03, 17 June 2026 (UTC)[reply]
As I have addressed under another post you made that says basically the same thing, source prioritization is relatively specific to Google Gemini, and I haven't seen any other western flagship have that problem for years. Just-a-can-of-beans (talk) 20:53, 17 June 2026 (UTC)[reply]
is the average Wikipedia editor going to pay for the better models?
They are not, which is why I suggested mandating the specific models to be used. In my opinion, anything below the specified models (Claude Sonnet or GPT-5.4+) is unsuitable even for text generation with a provided source. That being said, I noticed in your previous post that you have not actually used these models or other advanced ones. You may be surprised by how big of a step up they are. If we were to set a standard for Claude Opus or GPT Pro, these models are even capable of inline quality checks when instructed to do so and given a set of quality standards (which Wikipedia thankfully has in ample supply) Just-a-can-of-beans (talk) 20:09, 17 June 2026 (UTC)[reply]
The only models good enough to meet Wikipedia standards are the paid ones, and not everyone can pay. The amount of tokens that would be used if this was to be implemented in the way some have suggested (official Wikipedia AI partnership) would cost a lot to say the least. Also, I do not have a deep understanding of the paid models as I have not used them frequently, but I have used them on occasion. Ilov3gam3z (talk) 20:24, 17 June 2026 (UTC)[reply]
When used via API, the average prompt with Claude Sonnet or GPT-5.4 costs a few cents. As an example, the diff I linked in my original post, where it edited a section after analyzing an academic PDF, this cost me about $0.09 with Claude Sonnet; I ran GPT-5.4 simultaneously (selecting the Claude output because it was better) and that one was even cheaper, being about $0.04. Paid, yes, but not prohibitively expensive as you might expect. This was done via OpenRouter.
An official partnership like that wouldn't even really be about the token cost unfortunately, but rather about the training cost, which is very resource intensive. But that's really not necessary: a strong system prompt with a stock-standard model will produce the kind of result you're thinking about. There aren't many people out there capable of writing such a thing, I suppose, but I very much doubt I'm the only Wikipedia editor who knows how to do it. Just-a-can-of-beans (talk) 20:49, 17 June 2026 (UTC)[reply]
But we can't be sure a official partnership would happen. Going simply based on the idea of specific models w/ specific prompts, this would most likely require people to pay for these models themselves. Most people will not do this, and do I simply don't see the point. Ilov3gam3z (talk) 21:50, 17 June 2026 (UTC)[reply]
This would be an absolute nightmare. NO. First of all, AI still makes hallucinations, the idea that it has gotten 'better' is a lie, it can simply hide it better with dubious sources. Only allowing specific models would make yet ANOTHER backlog of work needed to be done by volunteers, as well as a 'Wikipedia prompt' being volatile and requiring constant changes (more work for volunteers). Also AI has a weird tone that the best prompt can't fully fix, that will sound weird enough to be a turnoff to a good many people. Just no. Ilov3gam3z (talk) 13:26, 15 June 2026 (UTC)[reply]
I haven't seen anyone else comment on this yet, but I'd also like to add that the writing style in the Claude contribution is a little out of step with encyclopedic tone. It's subtle, not glaring, and humans do write like this, especially those with academic backgrounds who are accustomed to writing in this style. —Myceteae🌈 (talk) 14:47, 15 June 2026 (UTC)[reply]
I do wonder if some of that is due to my own edits. I tend to over-clarify in my writing. I just felt that the initial output was a bit too technical for the average reader. Just-a-can-of-beans (talk) 20:19, 17 June 2026 (UTC)[reply]
Could very well be. It's difficult in articles like this, which are highly technical and where there is little "lay" literature on the topic. This is why it's a pervasive problem for human- and LLM-written articles on many topics. —Myceteae🌈 (talk) 20:41, 17 June 2026 (UTC)[reply]
I think you're erroneously assuming here that the Wikipedia userbase want to integrate LLMs into the creative process, and have simply been forced to put a pause on that due to the technical issues. I don't believe that to be the case.
As others have said, sentiments like "Wikipedia is by humans, for humans" are becoming more and more popular as the rest of the internet becomes steadily subsumed by identical-sounding AI-generated prose. Our goal is not to create the most comprehensive encyclopedia as fast as possible. Our goal is to create an open-source repository of human knowledge.
Just today I was googling to find some information about a problem and I found at leazt 5-6 articles from different sites all with the exact same heading format; "Problem X, What it is, the risks, and solution tips". One of them said something like "Fire remains a primary risk of throwing lit cigarettes on thr carpet", with the AI-ptose "remains" managing to imply, somehow, that the act of throwing lit cigarettes on the carpet may somehow later have a different primary risk. It was basically impossible for me to find information about what I was looking for that actually seemed to be written by a human.
In an age where everybody's writing their scripts, listicles and help forums with AI, Wikipedis remains (see what I did there?) a bastion of actual human effort, and actual human achievement. There are many people like myself who believe no matter how good AI gets at writing for Wikipedia, we still shouldn't use it. In a dead internet where bot-generated traffic now makes up the majority of activity (according to Cloudflare), let's have Wikipedia be a hub of life. The day Wikipedia articles start sounding like every other piece of soulless machine-generated prose inundating the internet these days is, I think, the day I finally stop using these kinds of peer-to-peer websites altogether. I've already been driven off every other social media because of it.
In the words of Pope Leo,"We must, then, avoid the “Babel syndrome,” namely the idolatry of profit that sacrifices the weak, a uniformity that neutralizes differences, and the pretense that a single language — even a digital one — can translate everything, including the mystery of the person, into data and performance."Athanelar (talk) 06:13, 16 June 2026 (UTC)[reply]
I'm sorry but I do not think that it is appropriate to use Wikipedia as a platform for activism, including activism about human vs machine content. I think that it is only appropriate to attempt to create the most comprehensive, thorough, well-sourced, complete, and useful free-access encyclopedia on earth; limiting this effort for personal belief is just not appropriate. The exact same line of thinking could be used to argue that common people shouldn't be allowed to edit Wikipedia without showing some credentials first, and I think you'll agree that this is contrary to the fundamental nature of the site. Framing Wikipedia as a resource that has rules on who or how it can be written is not appropriate, it should just be about what is written.
And, to address the first paragraph, no I do not think most editors want to use LLMs, I just think that they're a valuable tool that can be used to greatly increase individual editors' productivity, and that a blanket ban is a net detriment compared to regulated use. Just-a-can-of-beans (talk) 21:01, 17 June 2026 (UTC)[reply]
Framing Wikipedia as a resource that has rules on who or how it can be written is not appropriate, it should just be about what is written. But this is obviously not true, and obviously never could be true. We restrict contribution by editors with conflicts of interest, paid or otherwise. We have rules and norms about disruptive editing, we have a whole list of things Wikipedia is not, most of which are arbitrary and based on the idea of what sort of encyclopedia we want to create rather than being based on any specific meritocratic argument. Even our fundamental basic requirement, "notability," represents the deliberate decision to create a selective encyclopedia as opposed to an indiscriminate one.
There is no reason why "Wikipedia is not AI generated" can't go right alongside "Wikipedia is not indiscriminate," "Wikipedia is not a democracy" etc. Athanelar (talk) 21:16, 17 June 2026 (UTC)[reply]
And we have lots of rules about which sources can be used, when, how, and under what circumstances. And a great many content policies and guidelines. —Myceteae🌈 (talk) 21:27, 17 June 2026 (UTC)[reply]
But aren't all of those about the quality of the articles themselves? Disruptive editing is obvious, and CoIs are similarly banned not for the fundamental ethics of the matter, but because they introduce a strong element of bias that detracts from page quality. There are also exceptions to CoI when it could improve mainspace content, such as allowing individuals to edit pages about themselves under certain circumstances, and having a system for allowing paid edits. Notability criteria keep pages and Wikipedia itself cohesive and focused, which is necessary for content to truly be able to inform readers about the important details. A blanket ban on LLM use is different, in that it punishes how a page is written, not the eventual results on that page. Is it not a bit unreasonable to have a blanket ban here, but not on paid editing? Just-a-can-of-beans (talk) 21:31, 17 June 2026 (UTC)[reply]
But aren't all of those about the quality of the articles themselves? They are precisely about maintaining a certain idea of "quality" which is not objective, but rather deliberately decided upon by Wikipedia's foundational principles and the ongoing consensus of its community.
You could argue, for example, that conflict of interest editors are exactly who we would want to write our articles about companies and the likes; these companies are literally willing to pay people to make sure these articles stay up to date with the latest information about the company's organisation, products and services etc. That might be very valuable if we were a different encyclopedia with different values. But we have decided, as a matter of principle, that we are not a directory or catalog and that we'd rather our articles be based on what people wholly unrelated to the company has to say. That is, again, not objectively "better" than the alternative, it's a subjective judgement based on the values of the project.
All of these things reflect the fact that Wikipedia has a culture, ethos and values, and that our only goal is not simply to collate as much information as possible as fast as possible.
Now, if you want to say "Wikipedia's values shouldn't exclude AI-generated text" that's one thing, but arguing that Wikipedia is somehow an objective judge and shouldn't include or exclude things based on judgements of philosophy or value certainly doesn't stand up to scrutiny. Athanelar (talk) 21:48, 17 June 2026 (UTC)[reply]
p.s., Is it not a bit unreasonable to have a blanket ban here, but not on paid editing? I actually would wholeheartedly support a blanket ban on paid editing, too. I have long argued that people who are only here because they've been paid to write promotional content (and that is, unsvoidably, what the purpose of paid editing ususlly is) are definitionally not here to build an encyclopedia. I'd support very limited carveouts for, say, educational institutions who employ a paid Wikipedian-in-Residence (with the distinction being that someone being "a paid Wikipedia editor" should be fine, but being paid to write specifically about a person/organisation really shouldn't be) Athanelar (talk) 21:51, 17 June 2026 (UTC)[reply]
First of all, the paid editing tangent is a whatabout-ism. Secondly, just for clarity, I do not object to AI in the research process of editing, nor having AI make a rough draft you manually source, fix the tone of to sound like you and double check and remove hallucinated content. I am simply against doing AI editing with this much of a lack of human guardrails. Ilov3gam3z (talk) 22:46, 17 June 2026 (UTC)[reply]
What about finding sources yourself and using an LLM to help determine the most common themes and facts shared between them, then generating an outline, and then the article piece by piece while a human verifies each step of the way? ScottishFinnishRadish (talk) 00:13, 18 June 2026 (UTC)[reply]
It's a small distinction, yes, but it is an important one. I am fine with AI assisting humansbut I am not fine withhumans assisting AI. This proposal is an example of the latter, not the former. Ilov3gam3z (talk) 00:19, 18 June 2026 (UTC)[reply]
I think so long as specific claims about what a computer program can and cannot do are considered an article of religious faith, we are not going to make much progress here. Sometimes a computer program can do something really well; sometimes it cannot. You have to look and see to have a worthwhile opinion. jp×g🗯️08:12, 16 June 2026 (UTC)[reply]
You can call it "religious faith" or you can call it "principle." Wikipedia has its five pillars and its mission statement and a whole cultural ethos as to what it is and is not for which informs decisions about its policies and guidelines. The point is that whether or not these programs are "good" at what they do should not necessarily be the (only) deciding factor as to whether and how we use them. Athanelar (talk) 08:18, 16 June 2026 (UTC)[reply]
Flagship LLMs have been fed virtually every English language academic database at this point, and Opus in particular is capable of accurately quoting specific lines with correct DOI citations purely from memory, without any web searching (it is not reliable enough for me to recommend using it like this, which is why I recommended a reference-provided text generation setup).
Google Gemini, even on its premium versions, does have the problem of treating Reddit and other non-academic sources as authoritative information sources. This is why I omitted it from my recommendations. I consider this a Gemini-specific issue that does not apply to Claude Sonnet+ or GPT-5.4+ Just-a-can-of-beans (talk) 20:17, 17 June 2026 (UTC)[reply]
As an AI patroller, I will directly address the implication that some editors who use LLMs to generate article content (not research, not summarise, generate) article content will do so in a careful enough manner to ensure policy compliance. Find me a single case of an experienced editor being brought to WP:AINB and not having masses of issues turn up in their articles. One single case. Then look at comparatively the amount of articles that are indisputably slop and the amount of time it's taken to clean those up, and compare that to the amount of time it saves you, personally, to make an article which theoretically passes all the PAGs.
I don't think you realise the scale of the problem here. From the few times I've run my AI edit summary log, just looking at the people stupid enough to copy-paste their chatbot's suggestions into the edit summary box, we're talking about high two digits / low three digits per day of editORS, not just edits. Without the ability to revert on sight without excessive debate and verification, and you should be as aware as I am that LLMs are the world's greatest sealioners, the result is a mathematical certainty.
It may surprise some to learn that I have zero ideological slant against LLMs. I use them avidly in my own work and research, and indeed, my Wikipedia patrolling tasks. LLMs are a specialised tool which can be very useful in some circumstances, but are actively harmful in the vast majority of circumstances. Article generation is not something LLMs are good at, period, and this is well verified by thousands and thousands of experiments by people claiming to have varying degrees of LLM and Wikipedia competency. If you find a way to do it perfectly, I suggest that you send us your arXiv preprint. Fermiboson (talk) 17:31, 20 June 2026 (UTC)[reply]
You asked for a case. There's two articles. What if I preferred to use my volunteer time in that way? I think incredibly overly-detailed articles on professional wrestling and transformers with poor quality in-universe sources are a waste of time, but that's how some editors prefer to spend their time. It's no one's place to tell another editor who is contributing constructively that they can't. Wikipedia already got significantly fucked by missing the shift to mobile. We lost an entire generation of editors and we're continuing to lose out on potential editors because the mobile interface is garbage. That's on the WMF. LLMs and other AI tools are how an increasing portion of people interact with the Internet and now the community is going to lose the next generation of potential editors. That's going to be on us. Wikipedia is already bleeding with declining editor counts and falling traffic which leads to even fewer potential editors. Maybe educating people on constructive LLM use would slow that down a bit, rather than the Wikipedia immune system going after editors. Our immune system is good and I've blocked dozens of editors for LLM abuse but we're developing arthritis. ScottishFinnishRadish (talk) 21:43, 20 June 2026 (UTC)[reply]
I'm not aware of instances where we've blocked someone who was adding non-problematic LLM-generated content? The problem as I see it is that people come here, start adding problematic LLM-generated content, get warned and mass reverted, and then get demoralised and leave (ofc some continue past the warning and get blocked). What we can do about that (other than being nice about it or surfacing NOLLM earlier), irdk. But the hypothetical unproblematic, undisclosed LLM use goes undetected anyway, so an AI ban is pretty much just on problematic use.
If you're arguing that if/when LLMs get to a level where they can crap out FAs, we should reverse the ban to stop biting newbies, why would we then need loads of new editors when we can just have bots with a few human fact-checkers/managers? What's the reasoning for allowing some LLM use but not all? What's the benefit of having an LLM-using editor instead of a skilled AI agent (managed at a distance)? (sorry if I've misunderstood) Kowal2701 (talk, contribs) 22:34, 20 June 2026 (UTC)[reply]
What we can do about that (other than being nice about it or surfacing NOLLM earlier), irdk. We can educate them on how to use an LLM constructively, the same way we educate people on OR, SYNTH, RS, and how to format citations. But the hypothetical unproblematic, undisclosed LLM use goes undetected anyway, so an AI ban is pretty much just on problematic use. LLM use has to be disclosed, as I did on the two articles I created using LLMs, and that constructive use is now disallowed. Telling people they have to break the rules to contribute isn't a good way to handle it why would we then need loads of new editors when we can just have bots with a few human fact-checkers/managers? Because the workflow that I used requires a significant amount of time, similar to that of writing an article from scratch. Editors still have to find and read sources, verify everything, check for close paraphrasing and copyvio, and everything else that goes into creating quality articles. If someone wants to contribute usefully that way rather than the way someone else does they shouldn't be prohibited. Some people prefer doing research and reviewing rather than writing wholesale, and I think that's fine. ScottishFinnishRadish (talk) 22:52, 20 June 2026 (UTC)[reply]
I like the notion of adding WP:LLMRESP to AI warn templates (though they're already fairly cluttered, I'd also like to add m:List of Wikipedias because it's often non-fluent English-speakers).Btw WP:LLMDISCLOSE is an essay. I'll think on the rest, but (looking to the near future) I can't see the logic in allowing LLM-generated content with human review, but not unreviewed/liberal LLM use or agentic LLM-generated content, assuming the premise that there no concerns over core PAG compliance. If LLMs had already hit their ceiling, it's a different conversation, but I think that if we don't privilege human-written content, there'll become no reason to have human writers.
Assuming the premise that LLMs have hit their ceiling, part of the reason NOLLM is so blunt is because it's aimed at CIR LLM users who might see the nuanced "you must review" as permissible, but aren't capable of doing proper review (which is loads of people rn, esp. people not proficient in English). I don't think it's possible to address that while permitting the editors you describe, and there's a large backlog of AI cleanup as it is Kowal2701 (talk, contribs) 23:46, 20 June 2026 (UTC)[reply]
Of the potential new editors who are discouraged from editing by our LLM policy, I would bet the vast, vast majority would not (and would never) use LLMs with the apparent time and care you took to construct those articles (I would also note that @Fermiboson was asking for cases of experienced editors brought to AINB). This is absolutely the case already in academia, where LLM-generated, error-laden submissions to journals have skyrocketed. If thousands of senior academics whose reputations are at stake aren't sufficiently checking LLM summaries of experiments they conducted in fields they are experts in, why would we expect anonymous editors with unknown qualifications to behave any better for Wikipedia articles? JoelleJay (talk) 11:20, 21 June 2026 (UTC)[reply]
Malacca dilemma as produced had that strange llm mixture of errors mixed with close paraphrasing. Whether they are all gone now I am not sure, but it is not an example of an llm work that ended up with few issues. CMD (talk) 00:53, 21 June 2026 (UTC)[reply]
Just my 2c, I think a compromise we'll most likely end up with will be to allow LLM-generated content by someone with an LLM user right, but it'd always need to be disclosed and the criteria for granting the right would be strict. It'd also probably be stigmatised somewhat, similarly to how paid editing currently is, because it contradicts the 'hard work for no reward' editing culture we have that produces mutual respect and collegiality. I expect (hope) widespread use to always be a red line Kowal2701 (talk, contribs) 20:05, 20 June 2026 (UTC)[reply]
What I would like to see is an AI specially trained (by the AI vendor, not just user trained) to be as much like a human Wikipedia editor as possible, trained to avoid doing the kind of things we criticize in other AIs. Call it "Wikipedia mode" with a bunch of warnings on the AI's page about it being a start point for a human, not something to cut and paste. If they could actually make something good, imagine the PR value.
Best implementation of this idea I have seen so far, although I do fear this may be a bit of a hassle in general. We are getting on just fine without LLM's and AI in general, although we are having some editor retention and acquisition problems, but I don't feel we are at a tipping point where we need editors to be 'assisted' by AI to help. Ilov3gam3z (talk) 19:12, 15 June 2026 (UTC)[reply]
Frankly, if the editors we're failing to retain are the kinds of people who teachers report can't write a one-paragraph essay without turning to their chatbot of choice, I'm not losing any sleep over it. I don't think our goal should be to make Wikipedia editing accessible to the most intellectually lazy segment of the population. Athanelar (talk) 06:25, 16 June 2026 (UTC)[reply]
We are getting on just fine without LLM's and AI in general
I don't think this is true, it's more like "we are barely treading water beneath the deluge of AI edits past and present."
This is almost exactly what I have proposed. When given a robust system prompt, a flagship LLM is capable of doing this. Running this on an unmodified flagship would almost certainly produce better results than a model trained from the ground up for Wikipedia use, unless that model was a relatively basic remix of an existing flagship. Such a thing could be made theoretically but would be somewhat costly and Wikipedia would be expected to foot the bill, so I don't think that's a realistic path, unfortunately. Just-a-can-of-beans (talk) 20:13, 17 June 2026 (UTC)[reply]
Now that LLMs, if not AIs, have become a hotter topic than before, I can't help wonder whether now is the right time to close this discussion as failed attempt to circumvent or make the community reconsider the WP:LLM rule. Indeed, I made a response there about laserdisc inspiring and then being superseded by DVDs, especially in popularity. George Ho (talk) 19:34, 15 June 2026 (UTC); edited, 18:27, 17 June 2026 (UTC)[reply]
Nobody has yet answered the question that I posed many months ago: what do LLMs train on when thay have run out of human-generated content? Phil Bridger (talk) 18:50, 16 June 2026 (UTC)[reply]
Western flagships are pouring enormous amounts of money into human training, to avoid LLM items as training material. The reasoning is rather simple: the gaps in the initial LLM's outputs, if used as training material, will only multiply in later iterations.
Suggesting changes to policies is not an "attempt to circumvent" those policies and it's rather ridiculous to characterize it as such. Levivich (talk) 16:09, 17 June 2026 (UTC)[reply]
All of these are consumer-grade LLMs with minimal processing power, unsuitable for professional work of any kind. I specifically rejected the use of them in my proposal, for a reason. Just-a-can-of-beans (talk) 20:22, 17 June 2026 (UTC)[reply]
Well done George, but please provide a summary of what the LLMs said given that 2 of the links need additional input before they can be read. In any case, anyone who reads this discussion can see that the overall sentiment is far from positive. So LLMs just confirmed the obvious. Yesterday, all my dreams... (talk) 21:14, 17 June 2026 (UTC)[reply]
Copilot says "low" chance for "full rollback" and "moderate" chance for some sort of relaxation.
ChatGPT says that proposal as written would have "10–20%" chance, but even it also says that the outcome of complete dismissal has "10–20%" probability. Chances of the "modified and partially adopted" outcome are "25–40%". That of the outcome of rejection but also "spark[ing] later clarifications" would be "40–50%".
Google Gemini predicted "very low chance of success".
No you have not violated any policies, because you are reporting LLM output. That has now given me a new idea, which I am sure is the subject of a few master theses right now: "How often do LLMs agree?" Regardless of accuracy, do they agree on most issues? If they do not, which is probably the case, then that is a point against them. Yesterday, all my dreams... (talk) 05:35, 18 June 2026 (UTC)[reply]
I too once believed that well-crafted prompts combined with careful review by subject-matter experts could lead to quality content. Then we had the case of Esculenta (talk · contribs), who I considered to be pretty much the pinnacle of competence and trustworthiness, and who nonetheless turned out to have pervasive source-text integrity issues across their thousands of LLM-assisted edits (most of which still haven't been reviewed and cleaned up). That experience taught me that even when a user says they are aware of the hazards of LLM-assisted editing and that they are carefully reviewing the output, we still have to closely scrutinize the results, and the man-hours it takes to do so far outweighs the efficiency improvement for the original editor. You may feel you are getting good results much faster, but actually you are just offloading the hours to other editors, and editor-hours of people willing to wade through others' LLM-contributions is a precious scarce resource these days. Please stick to using LLMs to find sources and guide research, and please continue to read those sources and write quality content yourself. We can revisit this question in 2030 once we've finished cleaning up the messes from all the "competent" LLM users who went before you. -- LWGtalk(VOPOV)00:42, 18 June 2026 (UTC)[reply]
Esculenta's process differs from Just-a-can-of-beans's proposal in a number of important ways but this raises another issue that I haven't seen discussed here: close paraphrasing and WP:COPYVIO. This is already a challenge in many niche or highly technical fields where there the literature is limited and rife with jargon. I've seen a few discussions over the past year or so about this particular issue (like this one), noting that this is a challenge even when not using LLMs. I admit I don't have experience with using LLMs as proposed but I would expect this to be a problem when feeding a single source to a model and asking it to summarize. —Myceteae🌈 (talk) 15:44, 18 June 2026 (UTC)[reply]
The only way to adequately check LLM output for copyvio and close paraphrasing is to have carefully read and internalized both the sources and the LLM output, which calls into question the claimed time savings, since this careful reading and thought makes up most of the time spent when editing without LLMs. If the parts of editing that the LLM is claimed to replace normally make up 30% of the time spent editing, yet you claim the LLM speeds up your editing by 80%, I can only conclude that quality is being sacrificed. -- LWGtalk(VOPOV)18:11, 18 June 2026 (UTC)[reply]
And even if you check all the sources that the LLM listed, it's a leap to presume that it had not absorbed and regurgitated information from a source that it did not include in the listed sources. -- Nat Gertler (talk) 19:10, 18 June 2026 (UTC)[reply]
LLMs can and will experience context drift, especially when the provided documents are large. Forcing it to provide source snippets to support blocks of generated text is only useful as far as you can personally evaluate the fidelity, so if someone doesn't actually understand the topic deeply enough to write about it on their own, they may not be able to recognize misalignment. Plus the more rigidly you constrain the model to specific texts, the more likely it is to mislabel context. JoelleJay (talk) 14:14, 19 June 2026 (UTC)[reply]
A lot of the narrative around use of AI on Wikipedia has a sort of social justice/WP:RIGHTGREATWRONGS feeling that is unrelated to the goal of creating a free encyclopedia. Of course we should use any tool to that end. Anyone whose goal is to make an encyclopedia "by humans, for humans" is firstly ignoring the fact that this is an electronic project with spellcheckers and a ton of bots that fix various minor errors, and secondly importing a goal that is not the goal set forth in the statement of purpose of this project. Now, obviously it is a bad idea to have a Grokipedia-like fully automated function of gathering potentially dubious sources and crafting an article out of them. However, LLMs are just fine at taking sources provided to them through good old-fashioned human research and drafting a sentence or a paragraph summarizing the gravamen of those sources. In a very short time, it will be impossible to tell the difference in writing, and it has been pointed out to me more than once that merely being a good writer now makes one suspect of being an LLM. BD2412T00:13, 21 June 2026 (UTC)[reply]
I don't see it as RGW so much as existential: the minute LLMs can write summaries as good as humans (and that minute may already be here) is the minute Wikipedia becomes obsolete. Which means Wikipedia editors become useless. That's what the anti-LLM folks are fighting against: their own obsolescence. I'm not sure I'd characterize Wikipedia's existential fight for existence as RGW. Levivich (talk) 00:17, 21 June 2026 (UTC)[reply]
I feel as if this is a bit of a strawman. As an anti-LLMs'-in-Wikipedia editor, I am not worried in the slightest about being replaced. What a ridiculous idea; AI edits are hallucinatory, copyvio ridden, deep into the uncanny valley when it comes to style and cannot for the life of itself comprehend Wikipedia markup, templates and all the like. No, I (and many others, I might add) am worried about the quality of the encyclopedia. Quantity matters much less.
There is a reason the Library of Babel is only used on the internet as a fun gadget; there is too much quantity of information to find any quality information. Ilov3gam3z (talk) 00:35, 21 June 2026 (UTC)[reply]
Well, for one, there's a fundamental difference between spell-checking tools or bots and generative AI. I don't think that distinction needs to be explained further... For two, the error rate with current LLMs is way too high, especially when considering the volume at which such errors would be introduced and the likelihood of them flooding niche topics that would inevitably go for years without expert evaluation. An editor who has zero understanding of some specific technical topic isn't going to try to write a summary of it, while an editor with limited background in the topic may write on it and may make mistakes (and often these will be relatively predictable mistakes, as anyone who has graded exams might have noticed). Permitting any leeway in LLM use would both expand the pool of editors contributing on topics they have no/limited expertise in and enormously increase the volume of their edits. Even if contribution rate somehow stayed constant, allowing LLMs to summarize even short tracts of text would still degrade the confidence reviewing editors would have in source-content fidelity, meaning each assessment would take more time. If the only goal is to create as many encyclopedia articles as possible, then we're already beaten by LLMs. The people who don't care whether their information is human- versus AI-generated already just use chatbots as their search engines or rely on Gemini overviews, both of which are heavily influenced by existing Wikipedia articles. The greatest value we can provide now is our assurance that content is strictly composed by humans. JoelleJay (talk) 12:53, 21 June 2026 (UTC)[reply]
Re: The greatest value we can provide now is our assurance that content is strictly composed by humans, well then, let's ban use of spell-checkers. Let's turn off all the maintenance bots and prohibit the use of sources found with a search engine. Hell, let's ban the use of electronics altogether, and write Wikipedia with pencils and paper. BD2412T19:20, 21 June 2026 (UTC)[reply]
Not going far enough there. Pencils can be erased, paper decays and is flammable. If it isn't carved on stone tablets, you can't trust it. --GRuban (talk) 19:25, 21 June 2026 (UTC)[reply]
So apparently you do need a primer on how vastly different spellcheckers are from generative AI? Maybe if you are too unfamiliar with these technologies to recognize why they are incomparable you should step back from this discussion. JoelleJay (talk) 10:19, 22 June 2026 (UTC)[reply]
The leading generative AI platforms can literally be used as a spellchecker. You can give it a block of text and ask it to identify typos and it will. Better yet, it will also identify correctly spelled but contextually wrong words (e.g., there/their confusion). What we have here is an exhortation that since hammers can be used to kill people, we should be prohibited from using them to hammer nails. BD2412T19:20, 22 June 2026 (UTC)[reply]
This is semantics. We are not discussing the usage of AI in spell-checking here. Also there have been cases of AI spell-checking incorrectly, so this isn't the gotcha that you think it is. Ilov3gam3z (talk) 20:49, 22 June 2026 (UTC)[reply]
Show me one instance of an AI getting the spelling of a word wrong, outside of being told to write something intentionally containing misspelled words. BD2412T21:09, 22 June 2026 (UTC)[reply]
Fine. Small things, like it's vs its' or bigger things like, for example, what if an article has an Indian English tag? I don't exactly think that AI is going to replace it's z's with s's without being told, and I don't think most people will tell it too. Ilov3gam3z (talk) 23:41, 22 June 2026 (UTC)[reply]
On the other hand, you made a typo in your comment there, and yet you're still allowed edit :-) Anyway, if the problem with LLMs was "it's" vs "it's" or "colour"/"color," nobody would be talking about banning LLMs. This of course isn't about spellchecking, and I think this exchange illustrates the problem with the entire "written by humans" argument: 1. humans make mistakes, too, and 2. humans use technology when they edit (which I think was the point of bringing up spellcheckers). It's not as simple as "humans good machine bad," it's a question of whether the technology creates too many mistakes to be helpful, a question of which technology editors should and shouldn't use, or even of how they should and shouldn't use a particular technology. Levivich (talk) 00:37, 23 June 2026 (UTC)[reply]
In my experience LLMs will change z's and s's and do other engvar changes. I've had it happen in both directions. Doesn't happen every time, just something to watch out for if using. CMD (talk) 02:51, 23 June 2026 (UTC)[reply]
This discussion is about a proposal to generate biomedical articles with LLMs, not about using them for copyediting. Of course LLMs can perform spellchecking... as mentioned below, we already have different rules for this as it's (supposed to be) a separate function from the generative capabilities of LLMs. JoelleJay (talk) 13:13, 23 June 2026 (UTC)[reply]
I am so SOOOOO sorry if I place this here, but I am scared that new socks are going to invade Wikipedia talk:Long-term abuse/Salebot1 (and it may get create protected) or that nobody may reply once I place the edit in, so here's the explanation. In the sandbox, I made twoedits——one based off YouTube and the other on a Fortnite Fandom wiki——about researching Salebot1's minions' attitude, much like how they copypaste content from websites related to Angry Birds Stella and place that nonsense on a bunch of (actually, the most searched) articles. This is why I'm researching them. The most surprising part is that Salebot1 socks' actions actually get logged into the edit filter. These socks keep appearing, and if you see the new socks (like 45(Redacted) or AntiCompositeNumber(Redacted)), please do not report them to WP:AIV nor to WP:UAA as they have gross usernames.
Respectfully, what are you asking? I can not tell. I especially don't get your advice to not report them to WP:AIV nor to WP:UAA. How exactly should we deal with them if not via these two methods? 45dogs (they/them) (talk page)(contributions)19:45, 15 June 2026 (UTC)[reply]
I guess, but it's all pretty unclear. Isn't LTA designed to handle these things? What weight are we supposed to give to one editor's request that we not report suspicious activity related to this particular abuser? —Myceteae🌈 (talk) 15:29, 22 June 2026 (UTC)[reply]
The need to report these accounts in an easy and quick manner far outweighs the risk posed by usernames created by this LTA, IMO. An admin can also just revdel afterward if really needed. 45dogs (they/them) (talk page)(contributions)15:40, 22 June 2026 (UTC)[reply]
Well... I use Special:Log very very often (and came across these sock puppets at least one time, and reported like ten of them), which is why I decided to research this. Seems that now SB1 socks are now searching for PvZ2 stuff and place it on several iPhone articles.
Sorry if I called 45dogs, it's because one sockpuppet's username (specifically the one that starts with "45") contained the N-word. The other one (starting with "AntiCompositeNumber") contained another offensive slur. – SimpleObjects-9ei 🏖️/☀️/🥵 (🌎 CentralAuth) 15:43, 22 June 2026 (UTC)[reply]
How to report an edit war on Wikidata
[I apologize if this is the wrong place (if you feel this discussion can be moved to a more appropriate place, please feel free to move it)] Does anyone know in which venue an edit war happening on Wikidata can be reported? The page d:Q921634 has been vexed for weeks with an unsourced map that gets constantly removed and then reuploaded under a different name on Commons, but I don't know where I can signal it. Grufo (talk) 18:46, 15 June 2026 (UTC)[reply]
@Grufo: That is not what I intended. The advice I pointed you to is about what to do before reporting to a notice board. Only if you have been unsuccessfull in trying to settle your dispute with the other editor(s), then you need to contact an appropriate noticeboard or talk page on Wikidata. The Wikidata Administrator's noticeboard is a likely place to do that. Donald Albury20:38, 15 June 2026 (UTC)[reply]
@Donald Albury: Sorry if I misinterpreted. The situation is a bit more complicated than that. I had already engaged with these accounts at Talk:Fraxinetum#Map of Fraxinetum, and on Latin Wikipedia I had to block them due to vandalism, since they were blanking (#1, #2) the equivalent of our {{Disputed}} and {{Wikify}} templates (I assume due to the fact that these were displayed at la:Fraxinetum). I believe the situation at this point is beyond any possibility of settling. What would you suggest? --Grufo (talk) 21:02, 15 June 2026 (UTC)[reply]
@Grufo, I suppose you can take your pick but since the question was How to report an edit war on Wikidata and the locus of the issue is presently on Wikidata, Wikidata:Wikidata:Administrators' noticeboard would seem to make the most sense, as two other editors have already suggested. For any noticeboard, I suggest reading the guidance (headers or banners) at the top which usually give a good indication of the type of issues that should be reported there and may link to relevant policies, guideline, or alternative venues. —Myceteae🌈 (talk) 19:16, 16 June 2026 (UTC)[reply]
You are right, Myceteae. But thinking about this case more thoroughly made me realize that making it a point about Wikidata might be too narrow. I mean, for months these accounts have been repeatedly uploading this unsourced map about Fraxinetum, which repeatedly got deleted, claiming that in the Middle Ages there was an emirate in the middle of Europe. It might really not be a Wikidata issue (my bad for thinking it was), but rather a crosswiki one. --Grufo (talk) 03:59, 17 June 2026 (UTC)[reply]
I defer to you, as you have more experience with cross-wiki issues and with this particular problem than I do. Editors should take care to find the proper venue for their concerns, as you are doing, but in my experience a good-faith post to an active noticeboard often gets the attention of someone who can help even if another venue is technically more tailored to the issue. This is of course not an invitation to editors to post willy-nilly to the most high profile forum they can think of, and it's clear from this thread that you wouldn't read it that way. In the pat when I've needed help and been unsure about the best place to seek it, I've often stated that and have had mostly good results with that approach. —Myceteae🌈 (talk) 17:10, 17 June 2026 (UTC)[reply]
I agree with you Myceteae. I can only add that in some rare cases the proper venue itself is not so obvious and a brainstorming about it can help. So thank you. --Grufo (talk) 22:21, 17 June 2026 (UTC)[reply]
Absolutely. I see no problem with seeking initial guidance here and actually think it was a good approach. But at some point one must just decide to make a report somewhere, or not. It sounds like you have as good a handle on this issue and plausible venues as anyone and have decided to move forward with Antispam. I hope this gets the proper attention. —Myceteae🌈 (talk) 23:12, 17 June 2026 (UTC)[reply]
Grufo, there seem to be at least three issues here: two of them are being addressed by others, but you need to address the immediate issue. Please decide whether this is a Wikidata or a cross-wiki issue (it doesn't matter much if you make the wrong decision), follow the advice you have been given and WP:BE BOLD. Phil Bridger (talk) 21:01, 17 June 2026 (UTC)[reply]
There is a Wikidata issue. But since for a while there has been an enwiki issue, a lawiki issue, and there is still a wikicommons issue ongoing, I believe this might be better dealt globally. As soon as I have a second I will post on meta:Wikiproject:Antispam. --Grufo (talk) 22:16, 17 June 2026 (UTC)[reply]
Updates: For now I have resolved by asking for page protection of d:Q921634 at d:Wikidata:Administrators' noticeboard. Still the crosswiki issue remains, but I really don't have time now to go through all the global edits of these accounts and fill a report. If the problems continue m:Wikiproject:Antispam will become the only way to go (although I should have done it already months ago). --Grufo (talk) 21:36, 23 June 2026 (UTC)[reply]
That is a very good idea, Guy Macon. I think what could be added is a section concerning crosswiki incidents. I am afraid I cannot help with that just yet, because I am still looking for answers myself. --Grufo (talk) 04:02, 17 June 2026 (UTC)[reply]
Post any partial answers or answers you couldn't find on the help page talk. Or we could use the old standby, post completely wrong information and watch as 5 people who wouldn't answer the question reply with the correct answer... (That was a joke. Do not actually do that.) --Guy Macon (talk) 04:10, 17 June 2026 (UTC)[reply]
:) If a malicious user (or a group of users) gets coordinated to do crosswiki vandalism, it would be stupid from each of our projects to act separately. There are a few people working on crosswiki spam, but they are relatively hard to find. So, simply mentioning meta:Wikiproject:Antispam in a dedicated paragraph might be useful. My two cents. --Grufo (talk) 04:28, 17 June 2026 (UTC)[reply]
You are right of course. But let me point out that "coordinated and distributed" plans are hard to detect in general. As we speak, there are large computer security projects to protect financial organizations against these. Coordinated distribution can be both physical and temporal, and hard to detect. But we should do what we can anyway. I still wish some bots would be used. Yesterday, all my dreams... (talk) 15:28, 17 June 2026 (UTC)[reply]
The place for cross-wiki issues is Meta:, I think. Guy's idea looks good: we get lots of similar questions asked here but there's not much we can say except "don't ask here". Phil Bridger (talk) 20:35, 17 June 2026 (UTC)[reply]
Another reason why the WMF should never decide to add AI-generated content to Wikipedia
The following is currently a non-problem -- the WMF isn't anywhere near the point where they would consider such a thing, and German courts can't order a US foundation around -- but things change. Imagine a future where AI gets really really good and a major AI vendor decides to donate computer time to Wikipedia for the PR value.
"A court in Germany has ruled that Google is legally responsible for false information generated by its AI Overviews, treating those summaries as Google's own words rather than merely search results. The case began after Google's AI falsely linked two publishing companies to scams and dishonest business practices, even though the cited sources did not make those claims. The court rejected Google's argument that users should verify AI answers themselves, ruling that the company is responsible because it creates and controls the AI-generated summaries. The decision could have major consequences for Google and other AI companies by making them legally liable when their systems produce false or defamatory information." --Source
All other issues aside, the largest problem with AI is accountability. Humans need to verify the outputs, check the sources, and make sure it isn't pure slop. Doing this is barely easier then just creating the content organically, although it does offer some advantages in terms of determining what content to include and how to structure it. Unfortunately, people want to use it to replace the need to think and fact check, so here we are. GeogSage (⚔Chat?⚔) 05:07, 18 June 2026 (UTC)[reply]
I'd have hoped it was obvious that I can't just publish libel about people and get away with it because I used AI and not everything you read on the Internet is true, but it's good to have a court confirm that and strike down Big Tech's argument that it's special and above the law. Certes (talk) 10:59, 18 June 2026 (UTC)[reply]
Guy, yes, but that is one of 10 different reasons for not using them. Remember the David Letterman Late Show Top Ten List? Perhaps someone should write an essay in that style. It would be fun. Please see my comment above regarding "How often do LLMs agree?" I am sure a few theses on that will be written soon. If they do not agree, which is to be trusted? A Confusion matrix would be very interesting. By the way, my lack of faith in current LLMs does not originate from my lack of subject knowledge. The reverse is true. I published my first paper on AI before before cell phones existed and before the world wide web. So my hesitations have a serious basis. The neural net structures most of these systems use are inherently probabilistic, and hence error prone. But that is another story. Yesterday, all my dreams... (talk) 05:46, 18 June 2026 (UTC)[reply]
Post script: Please do not rely too much on the Confusion matrix article. Now that I have looked through it, I see various issues there. The editors who did over 50% of the edits are gone, and ips have caused problems. I mentioned some problems on the talk page there. Yesterday, all my dreams... (talk) 06:00, 18 June 2026 (UTC)[reply]
Post script 2. Now we have another reason for not using LLMs in Wikipedia. Earlier today, Google AI quoted the Wikipedia lede on Confusion matrix almost verbatim. A few minutes after I had touched up the lede and improved it with a source Google AI changed, and ignored my ref about audiology. It then seems to have used some material from Geeksforgeeks! But most importantly it IGNORED my talk page comments about article quality. So these system currently ignore article quality comments and use whatever there is, and may mix it with low quality websites. Yesterday, all my dreams... (talk) 11:05, 18 June 2026 (UTC)[reply]
I don't think we can expect AI scrapers to read and understand talk page comments then follow their suggestions, especially as not all comments are objective or even accurate. Certes (talk) 12:38, 18 June 2026 (UTC)[reply]
I would expect a good AI system to look at my comment on the confusion matrix talk page and see if there is any value in it. And there is, given that l specifically mentioned Ryszard S. Michalski. A good AI system would look him up and recognize that the article was missing his work. Please look at Michalki's talk page and see what a fan said. That comment should have been ignored by AI but my comment had value given the link I provided. A simple analysis of his work shows that he was a pioneer. Alas illness did not treat him well. Yesterday, all my dreams... (talk) 12:54, 18 June 2026 (UTC)[reply]
My theory is that "a good AI system" does not currently exist, that one will most likely exist some time in the future, and that everything we decide based upon the AIs we are seeing now will have to be reevaluated. Until then, I am firmly in the "no AI on Wikipedia" camp. Should the day arrive where in nearly every case an AI-generated online encyclopedia gives better results than we humans can create maybe my position will change. Keep your eyes on aicyc.org, wikigen.ai, and any new project like them. Not Grokipedia, though. That one appears to have been created specifically to push an agenda. I could say more, but this editorial[6] says it better. --Guy Macon (talk) 19:22, 18 June 2026 (UTC)[reply]
More than that, Wolpert's work establishes that even "good" AI systems (whatever that means) will inevitably differ on various outputs. So your "theory" is actually a fact at this point. Yesterday, all my dreams... (talk) 19:50, 18 June 2026 (UTC)[reply]
Hmmmm. Different humans editing Wikipedia also have different outputs. I am not seeing any connection between having different outputs and being bad. (The AIs are indeed currently very very bad, but not for that reason). --Guy Macon (talk) 20:37, 18 June 2026 (UTC)[reply]
David Letterman style top 10 reasons for having no LLM content in Wikipedia
1. Per Guy, legalities.
2. Per myself, no attention to source quality, as in confusion matrix above.
3. The work of David Wolpert, specially the no free lunch theorem, among other results. This means that each LLM makes trade offs and hence different LLMs will inevitably give different answers because there is no perfect learning algorithm.
4. Per LWG above, out of control copy vio problems.
I think I have said enough on this issue, and will "say no more" and move on. Could a couple of you please turn this list into an essay? And could you do me a favor by dedicating it to Michalki given his initial efforts on the subject? (Coi, I knew him). Thanks. Yesterday, all my dreams... (talk) 20:44, 18 June 2026 (UTC)[reply]
8. if I have to hear one more time about how blah aimed to enhance blah and highlights the importance of fostering blah then I will stab myself to death by aiming a highlighter at my lungs, then take photos of the crime so my foster family can enhance them in the darkroom Gnomingstuff (talk) 20:17, 19 June 2026 (UTC)[reply]
Larry Sanger proposing WikiProject Intellectual Diversity
Honestly I'd recommend extending this to all sex and porn articles. The frequent invocation of WP:GRATUITOUS suggests other articles would be examined under this as well, depending on the outcome. I pointed this out in the talk page there, and it seemed to anger people who accused me of "derailing", but I truly cannot comprehend how the decision made for that page (on the basis of explicit images, not amount of images) would not set a precedence for other related articles; one other editor already suggested that outcome. Ringtail Raider (talk) 20:10, 20 June 2026 (UTC)[reply]
Can you be specific about which related articles you believe would be implicated by the result of the ongoing RfC? Regardless, I agree that this discussion should benefit from as many eyes as possible: the discussion involves questions about extreme and sexually explicit art involving children and animals. If you want a more generalized result, there can always be a WP:PROPOSAL at a later date. But the current discussion is already far advanced and I think is already serving as a bellwether to reinforce certain limits this community already tacitly endorses. SnowRise let's rap13:22, 22 June 2026 (UTC)[reply]
Some images in this genre contain identifiable neotenous features (i.e., childlike proportions of the head relative to the body, proportions of the eyes relative to the head, length of limbs relative to the torso, proportions of mouth and cheeks relative to the face). BD2412T18:39, 22 June 2026 (UTC)[reply]
because I know the show, I know that if you read all the creator's info and the like, the shows principle characters are all meant to be young adults (21 and older), and that they also have models for much younger characters. That all said, that requires background knowledge that we cannot expect a reader to know. And it was ostensibly a show aimed at young kids. As such to anyone not familiar with the show any images ftom thus are going to fall very very close into what would be absolutely unacceptable images. It approaches the same problem lolicon has, in that you get all these "all girls are 18 or older" subtexts (which i just checked only as two very tame far from explicit examples). I've already !voted by for thus article, only one image, the current top one is really appropriate considering all other concerns here. Masem (t) 21:08, 22 June 2026 (UTC)[reply]
Some images in this genre contain identifiable neotenous features is very different to "the specific images under discussion depict children". The clear consensus of editors, including ones knowledgeable about the show and other relevant subject matter, in multiple discussions, is that these specific images are not CSAM or otherwise problematic for related reasons. Note this is not the same as saying the images are appropriate for Wikipedia (I have not expressed an opinion on that and don't intend to), I just feel strongly that the decision should be made based on what the images actually depict and the manner in which they depict it rather than matters that are not relevant to the discussion. Thryduulf (talk) 21:56, 22 June 2026 (UTC)[reply]
"Note that SnowRise appears to about the only editor who believes the images under discussion involve children." Without meaning to sound short, I think you need to re-review that discussion: I am far from the only person in that thread who feels the images represent children or something so child-like in presentation that it makes no difference. And there are probably more who do feel the same way, but were contented to rest their opppose !votes (the vast majority of respondents do strenuously oppose inclusion for one reason or another) on the WP:offensive content and image use policy grounds. That said, I agree substantially with the rest of your thoughts here. I would call these images not CSAM, but "simulated CSAM". They certainly don't qualify for the criminal definition of CSAM in the U.S., because SCOTUS has previously ruled that art simulating child sex abuse is not CSAM. However, note that the courts are already indicating willingness to re-evaluate this standard now that AI is capable of creating realistic looking simulacrums. Regardless, whether the work in question appears to be a child, or is based on character known to be a child (as is the case in this instance), is very much at the heart of the analysis of the appropriateness of the content, and there are policy, safety, UCoC, and TOU implications all over the place here that make those particular images non-starters. SnowRise let's rap05:00, 23 June 2026 (UTC)[reply]
I'm not sure of the apt forum for this, but why does audio files with captions pop up full screen in mobile without the option to simply play it without captions and not have it pop up every time. Compare UK and Ukraine. One of them full-screens with the subtitles and the other has none so it does not. Can this be avoided? Using Chrome on an iPhone. ~2026-34629-56 (talk) 10:46, 12 June 2026 (UTC)[reply]
I do not see an immediate way to disable displaying substitles on a user setting level nor on specific Wikipedia pages. The feature is described at mw:Extension:TimedMediaHandler, which has limited maintenance. I do think it is a good default to display Closed Captaions if they are available. ~ In solidarity 🦝 Shushugah (talk) 13:06, 13 June 2026 (UTC)[reply]
Currently visible on the front page inside {{In the news}} RD, the name Ciarán Ó Lionáird is wrapped in {{avoid wrap}} which gives <spanclass="avoidwrap"style="display:inline-block;">. On mobile, this name appears in a smaller font size than the other names following / surrounding. (Not reproduced in desktop browser tools responsive emulation). Chowmein 🥡 (talk) 08:09, 15 June 2026 (UTC)[reply]
Strange, that's what I used originally. I just checked on a second iPhone also using Safari and it appears small there as well. Chowmein 🥡 (talk) 19:47, 16 June 2026 (UTC)[reply]
Browsers try to be smart about what they think is important and what is not for web pages that they don't think were designed for mobile resolutions. When you use the desktop website on mobile, that is one such case.
In such cases, content they guess is important will be bigger and content they guess is not will be smaller. I would guess that setting a span to inline-block is one signal they use. Functionally, the only way to fix this is to use a more responsive skin. Izno (talk) 01:40, 18 June 2026 (UTC)[reply]
See the Mozilla Developer Network (MDN) page on the text-size-adjust CSS property for an overview of how some mobile browser engines will adjust font sizes for legibility. (In short, pages are rendered on a canvas larger than the device's actual width (unless the page specifies otherwise), scaled down to fit the screen, and the font size adjustments are made for legibility.) The MDN page links to really old (thus possibly out-of-date) pages describing the behaviour for mobile Safari, Chrome, and Gecko (Firefox). (HTML pages using modern responsive designs explicitly tell the browser to use the device width and an initial scaling factor of 1, which disables the font adjustment algorithm.) You could try setting the text-size-adjust / -webkit-text-size-adjust property for specific elements in your your common.css file, but to be honest, I think that'll just lead to a lot of pain trying to fight the font adjustment algorithm, so I don't recommend it. isaacl (talk) 14:15, 18 June 2026 (UTC)[reply]
Very interesting. I wonder if long term the maintainers of Vector would be interested in disabling this behavior. Fascinating to learn it's Safari trying to be helpful. Thank you! Chowmein 🥡 (talk) 01:20, 22 June 2026 (UTC)[reply]
As I understand it, the Vector2022 skin was designed following modern responsive design principles, but it's disabled (so the old style render-on-a-larger-canvas-and-resize approach is used by the device) pending a community consensus to enable it. I suspect the design team would rather work with the community on improving the responsive design to the point where it gains community support to be enabled.
Note it's not just Safari. All small-screen browsers follow some procedure to render pages that were never designed to fit on a small screen in a way that keeps them as legible as possible. isaacl (talk) 01:38, 22 June 2026 (UTC)[reply]
@TurboSuperA+ what browser are you using? Where the red dots are unicode characters that aren't the basic U+20 space character but are U+200B (zero width space) or U+20260 (word joiner), so I'm guessing your browser is highlighting these to you. Nthep (talk) 18:51, 16 June 2026 (UTC)[reply]
Double backspace erased it (when a single wouldn't). I've never seen it before. I wanted to make sure I know what it was before I break something. Thank you! TurboSuperA+[talk]18:57, 16 June 2026 (UTC)[reply]
Hello everyone, I'm following up on the April announcement about the Parsoid migration as a heads-up about the completion of this work ahead of next week.
Parsoid has been the default parser on the English Wikipedia mobile web for the past month, serving nearly two-thirds of traffic, and many users have opted in since the April announcement. That, combined with our confidence framework, makes us confident that Parsoid is ready for the next phase for English Wikipedia and will be generally available soon.
Before we complete the transition to Parsoid for desktop, we encourage you to opt in, if you haven't already, and test your workflows to raise your concerns or issues you might have found that haven't surfaced in our tests and previous user feedback. To report bugs and issues, please look at our known issues documentation, and if you found a new bug, please report it through the "Report Visual Bug" link in the right sidebar, or create a Phabricator ticket and tag the Content Transform Team in Phabricator.
The documented known issues were considered non-blockers to the rollout due to their severity or impact and are being prioritized by our team for resolution as soon as possible once rollouts are complete.
Thanks for pointing that out. We are reviewing that extension behavior with/without Parsoid. If you have any test cases identified that point to an error, please let us know. After an initial analysis, the code represented by the comment does work with Parsoid in its current state but would prevent features we are planning for the future. Also, that type of issue would surface in the visual diff test so it doesn't seem to be a blocker to the roll-out. If it's a quick fix, though, we will do it before the roll-out. MSantos (WMF) (talk) 07:10, 23 June 2026 (UTC)[reply]
I find it strange that phab:T221028 is not even mentioned in the known issues list or in the instructions page even though it's a change that breaks the links to many pages (like /) outside the main namespace. To me, such an issue should be enough to delay the migration until it is fixed but I guess we move fast and break things in these parts. Warudo (talk) 10:38, 19 June 2026 (UTC)[reply]
Thanks for pointing that out. We lost track of it over the years, and it's a very subtle change that can be tricky on visual diff testing. An initial analysis identified that this is not broken on the main namespace, so our sample didn't catch this type of behavior in the other namespaces. Either way, we are prioritizing this, but considering it not a blocker to the roll-out.
Our curated list of known issues is based on severity and impact that surfaced over visual diff testing in the past year or so. In case you believe this list is missing an important issue, please let us know. MSantos (WMF) (talk) 07:15, 23 June 2026 (UTC)[reply]
Yes, I agree with SD0001 that extensions in use on Wikipedia need to get a review for support in Parsoid (PageAssessments may not be the only one).
Section editing transcluded things is one of the biggest pain points remaining. There are some other bad display things as well, like how on mobile captions are display flex. There are existing tasks for these. English Wikipedia could use a round or two of visual delta testing for the N most-popular pages.
As I think I have said elsewhere, please make a dedicated location for English Wikipedia feedback when this goes live. We tend to be very noisy and I don't want VPT being swamped with all the potential issues.... Izno (talk) 23:29, 19 June 2026 (UTC)[reply]
The dedicated location for English Wikipedia feedback is a great idea and I haven't seen it before. I'll soon let you know where we can transfer that discussion to. Thanks for the suggestions and feedback.
Regarding the extension support audit: we have this tracking task for extensions support on Parsoid. However, Parsoid support legacy extensions as well and for some extensions we are working around the parser hooks and re-targeting the legacy parser while the extension doesn't use the Parsoid extension API, that means that these extensions, despite not converted to Parsoid yet will work normally with Parsoid during the roll-out.
That being said, the visual diff testing is another way we validate there's not something broken with the extensions. Of the test sample, 5% come from top-ranked pages, 10% come from the RC stream, 85% from the dump. For enwiki, we have run tests multiple times over the last year. The most recent run tested against about 39K titles across all namespaces. About ~14K from article namespace, and ~25K from everywhere else (10K user talk, ~5.5K talk, 2.5K user, and so on).
These tests would have surfaced issues with extensions, global gadgets, and scripts. What we can't test is specific user workflows with personal gadgets, scripts, etc. MSantos (WMF) (talk) 07:25, 23 June 2026 (UTC)[reply]
How do I stop seeing Category removal/copying/addition in my watchlist? I have Category changes unchecked in my Type of change filter. Am I misunderstanding? Masato.harada (talk) 17:01, 18 June 2026 (UTC)[reply]
@Masato.harada: Are you watching the category page or the categorized pages? The setting only applies to the former. If you watch an article then there is no way to hide edits which only change the categories. PrimeHunter (talk) 17:12, 18 June 2026 (UTC)[reply]
As that comment-thread is long, I'll highlight the comment at phab:T399175#12035047 which gives a summary of how the constructive/precise feedback is welcome, and that there will soon be more iterations to many of the icons based on everyone's feedback. There's another task at phab:T427868 ("Icon refinement follow ups") collecting those quick follow up changes. HTH. Quiddity (WMF) (talk) 20:01, 18 June 2026 (UTC)[reply]
As someone who agrees with the many users who have expressed disappointment at the phab discussion, I'm especially interested in whether there could be a way for editors to opt-out of the recent changes (going back to what it was yesterday, in other words), until further improvements are made. I saw at the phab discussion that someone has created this: [7], [8], which didn't work for me. If there could just be an opt-in/opt-out button added to user preferences (either Appearance or Gadgets), that would be very helpful. --Tryptofish (talk) 21:26, 18 June 2026 (UTC)[reply]
I doubt they would commit to having two different versions of the icons for eternity, which is what you'd need for a preference. However someone has created User:Pattersonuwu/OldIcons.css which can be installed as a workaround. One way to install it would be to add this to your common.js file: importStylesheet('User:Pattersonuwu/OldIcons.css');. There might also be a way to @import it into your common.css file, but I haven't tested that. –Novem Linguae (talk) 00:37, 19 June 2026 (UTC)[reply]
Thanks, both of you. That's what I linked to in my comment. Doing it with the common.js file worked for me, and I'm happy now. --Tryptofish (talk) 20:58, 19 June 2026 (UTC)[reply]
I would recommend the common.css method since it should prevent a brief visual flash of the new icons. But anyway, glad this was helpful :) –Novem Linguae (talk) 08:02, 20 June 2026 (UTC)[reply]
I tried that just now, and the css approach doesn't work for me. I switched back to the js approach, and while I do notice that brief flash, it doesn't bother me particularly. I don't know why putting it in css has no effect for me, while js does (current version of Firefox, Legacy Vector skin), but I'm satisfied. --Tryptofish (talk) 19:52, 20 June 2026 (UTC)[reply]
Thanks so much for explaining that. I simply used the "copy" button in the documentation to copy what I then pasted into my css file, so that should be corrected. It looked a bit "off" to me at the time. Maybe I'll try it again if the brief flash at the beginning starts to annoy me. --Tryptofish (talk) 23:38, 20 June 2026 (UTC)[reply]
They're data URLs, so the actual image data is contained within them, rather than pointing to a location on the web. There are pros and cons to this approach. isaacl (talk) 05:51, 20 June 2026 (UTC)[reply]
Yeah, DownTriangle now looks like some Windows Vista/7/8/8.1 (RT) & Windows Server 2012/2012 R2 shenanigans (the dropdown button which you would see on the bottom right of the desktop). It looks EXACTLY like that, just that the Wikipedia version is black. I do not use Watchlist, but why they would resize downTriangle like x0.5 times tinier? And, even better, who asked for this? There shall be justice if any user is upset with the new icon update. – SimpleObjects-9ei 🏖️/☀️/🥵 (🌎 CentralAuth) 23:33, 18 June 2026 (UTC)[reply]
Also, just occasionally to let you guys know, the release notes for MedaWiki 1.47/wmf.7 (first deployed 16 June 2026) shows the following line which I'll show below:
The person you mentioned is just the deployer. Someone else is the one redrawing the icons. More info in this ticket.
They do seem to be responding to our feedback and willing to adjust the icons that we don't like. So we may not want to make too big of a stink about this. Front end changes will always be more controversial and subjective than back end changes. –Novem Linguae (talk) 14:44, 21 June 2026 (UTC)[reply]
Izno, I don't see how you can deny that this (and the other two below) are ITSTHURSDAY issues. They all appeared with the latest MediaWiki revision. I have a fourth issue to report. For many years now, on category pages, the entries under the "Subcategories" heading (if one exists) are preceded by a little triangle, which normally points right, but points down when a parent cat is expanded to show its children. As of the new MediaWiki, this triangle has got much smaller, and is now too small to distinguish the right-pointing triangle from the down-pointing one. I'm not going to moan and wait while phab tickets are ignored, I'll do something about it. This CSS rule will restore the previous size:
I did not deny that it was a Thursday issue. I disagreed that it made sense to group all of these sections together strictly on the basis that they are Thursday issues. They are all more-or-less distinct issues that are coincidentally appearing at the same time and as such will have naturally different resolution paths, which we should allow to archive at the usual arbitrary rate individually.
Is there a place where we can read the "changelog" to find out why things were changed? I'm not opposed to change, it'd just be nice to have a heads-up/explanation. TurboSuperA+[talk]05:19, 20 June 2026 (UTC)[reply]
We can choose from a bunch of different themes, why not choose the icons, too? People are using custom javascript and css to change the icons to the old ones, but it doesn't have to be that hacky. Give us a radio button in theme settings, and Robert is your mum's brother. TurboSuperA+[talk]09:47, 22 June 2026 (UTC)[reply]
I think problem is the technical debt and maintenance cost that will be associated with keeping multiple version of different icons around is significantly higher compared to the upside of we avoid a bit of bikeshedding discussion every five or so years. Sohom (talk) 23:22, 22 June 2026 (UTC)[reply]
Is there any issue with keeping old icons (and making them available via a user preference), but simply not updating them and using new icons when an old one isn't available? Technically speaking, that would just be loading one additional CSS file. sapphaline (talk) 06:31, 23 June 2026 (UTC)[reply]
It's technical debt, now every single developer making frontend changes will need to test two different versions to make sure their code works (make that X more versions every time icons change). On top of that these CSS files must be updated to keep in line with modern web standards. None of this applies to a userscript. And maintaining this is a significant overhead compared to bikeshed icons a bit every few years or so. Sohom (talk) 07:29, 23 June 2026 (UTC)[reply]
"CSS files must be updated to keep in line with modern web standards" - like what standards? Monobook still works despite not changing its layout (and the way this layout works) since 2004. sapphaline (talk) 07:39, 23 June 2026 (UTC)[reply]
The CSS standard is the standard I was referencing. The best practices surrounding CSS keep evolving as the standard evolves almost all the time. Monobook still works despite not changing its layout (and the way this layout works) since 2004. -- Right, you do realize that is not because "somebody wrote it and it kept working", but rather developers have had to go out of their way to keep it working by fixing bugs/maintaining compatibility with the rest of the interface and in general spending a significant amount of time maintaining it, trying to preserve compatibility with the older layout. (what Novem points to is the tip of that iceberg). To give you a example, the way the gradient on top bar in classic Vector looks has been rewritten atleast 3-4 times to keep up the with the CSS standards of the times since I joined despite remaining looking the same over time. Sohom (talk) 07:53, 23 June 2026 (UTC)[reply]
The "view | edit | history | purge" links on template documentation look incorrect, like [ | history ]. See Template:Template link for an example. It persists across Vector 2022, Vector legacy, and Monobook, but looks fine in Timeless. I'm guessing this is a WP:THURSDAY issue? Any help would be appreciated :) Best, HouseBlaster (talk • he/they)20:10, 18 June 2026 (UTC)[reply]
Yes, it's a Thursday issue, and one that I am to be blamed for (at least for requesting it, I didn't do the work). Izno (talk) 20:15, 18 June 2026 (UTC)[reply]
Is the change from T268900 stable-ish? As in, should I start updating the userscripts that were affected, or would you recommend waiting a bit? I don't see any linked tickets/tasks on Phabricator and nothing pointing to future changes in comments, but maybe there's relevant discussion elsewhere that you know about. —andrybak (talk) 10:49, 23 June 2026 (UTC)[reply]
I've noticed that, starting today, images using upright instead of thumb, are massive. An example of this is the images in the table on Mandurah line. The images were normal size yesterday. What's up with that? Steelkamp (talk) 08:05, 19 June 2026 (UTC)[reply]
I'm seeing the same problem with a copy of that table, plus a few more examples, at my sandbox. The upright option does not appear to be applied unless thumb is present. – Jonesey95 (talk) 14:55, 19 June 2026 (UTC)[reply]
@ABreault (WMF) Sorry, I meant phab:T424596, which was responsible for that invalid CSS (that's what I get for having too many tabs open at once). I think there is a stray "@" character in the patch that was rolled out, but I put more details in the task. --Ahecht (TALK PAGE)16:22, 19 June 2026 (UTC)[reply]
I replied on ticket. While it is true there is invalid CSS here, I am now wondering if this rule should be deleted and making this the default behaviour. We should not be making users download large megabytes images and hiding that fact by scaling them down in CSS. Jdlrobson (talk) 17:23, 19 June 2026 (UTC)[reply]
@Jonesey95: It's been documented for far longer than three years; something similar was added to WP:EIS over seventeen years ago. The earliest mention that I can find was added at 21:15, 14 June 2009 (UTC), the text at that time being "must be used along with the 'thumb' or 'thumbnail' parameter". It's been amended a few times since, such as to add frameless - which wasn't a valid option until later that year. --Redrose64 🌹 (talk) 00:04, 20 June 2026 (UTC)[reply]
I use that functionality a lot and now it doesn't work. I've reported this at phabricator for whatever that's worth and am posting this here as a general notification.
Looking for some Quarry assistance... Trying to write a query that list every Infobox template AND the number of transclusions that each has. Doesn't seem to be working... Any help apprecaited!
SELECTp.page_titleAStemplate_name,COUNT(tl.tl_from)AStransclusion_countFROMpagepLEFTJOINtemplatelinkstlONp.page_id=tl.tl_target_idWHEREp.page_namespace=10ANDp.page_titleLIKE'Infobox%'-- Starts with "Infobox"ANDp.page_titleNOTLIKE'%/%'-- Excludes any title containing a slash "/"ANDp.page_is_redirect=0-- Exclude redirect templatesGROUPBYp.page_id,p.page_titleORDERBYtransclusion_countDESC;
{{Skip to top and bottom}} covers content in the bottom right corner on Vector 2022, as can be seen at the help desk. This is bad, as it can make text hard to read, and obstruct links. I propose either A: moving the button to the bottom left corner (demoed in the sandbox), or B: hiding it entirely in Vector 2022. I understand Matrix originally moved the buttons into the content area to stop them covering links, but that doesn't seem to happen for me. My first preference is A, but if it does cover links, then I would support B instead. Danski454 (talk) 02:58, 21 June 2026 (UTC)[reply]
This matter comes up occasionally at Template talk:Skip to top and bottom, and as seen in the most recent thread there, has also come up on this page in the past. The problem is that we don't know (we cannot know) what might be behind the buttons, so we cannot position the buttons into some blank space or otherwise harmless area.
I still think that, rather than making everyone else hide it on a small random set of pages, people who want this should make a user script or gadget that would add it for themselves to every page. Or maybe even a browser extension to add it on every website. Anomie⚔12:23, 21 June 2026 (UTC)[reply]
I've removed the template from WP:HD (partly as a test to see if anyone objects). If we can't find somewhere harmless to put it, then I would support removing it from other pages, and marking the template deprecated. Danski454 (talk) 14:07, 21 June 2026 (UTC)[reply]
Can we please require a space after a URL in a template parameter?
I work with reference templates quite a lot, and in quick succession, and it is a minor but persistent annoyance to me that sometimes it is not easy to see exactly where a URL ends and the next parameter begins because there is no space before the next pipe. I think it would be trivially easy to have a rule that a URL in a template with parameters separated by pipes should have a space before the pipe, and have a bot go around and add those spaces. BD2412T03:02, 21 June 2026 (UTC)[reply]
There is a Harv error: duplicate target for CITEREFPollard2006 in History of fascism. It has to do with two chapters by the same author in a book edited by someone else. I can't see how to fix it. Can anyone help? Thanks, DuncanHill (talk) 21:40, 21 June 2026 (UTC)[reply]
Add |anchor-year=2006a or |anchor-year=2006b to the appropriate {{harvc}} templates. Change the matching {{sfnp}} templates to use those disambiguated anchor years.
No. User pages created at Meta do have a cross-wiki display, but transclusion of arbitrary pages or templates does not work. Izno (talk) 23:27, 21 June 2026 (UTC)[reply]
Is it normal for Wikipedia edits to take a long time to save?
I have a Dell XPS 13 9380 (2019 model) running Windows 11. My problem is that when I click "Publish changes" after making an edit, it takes like 15-20 seconds for my edits to go through. I'm not sure if this is a normal amount of time to be waiting before my changes go live. When I browse and click links, including the edit button, it loads pretty quickly. The only problem is with saving my edits. I am using source editor. My browser is Google Chrome. I have 8 GB of RAM, my CPU is an Intel Core i5-8265U, and my storage is 238 GB. My question is whether this is normal for a computer and if it is not, what I should do about it. Interstellarity (talk) 23:10, 21 June 2026 (UTC)[reply]
Save time is not a function of your computer. It is a function of the network between your computer and the WMF's computers, and a function of the WMF's computers. Izno (talk) 23:28, 21 June 2026 (UTC)[reply]
The biggest time of a save is spend in parsing and converting the new version to HTML. The bigger the page the longer the save will take, because it has to spend more time converting saving, understanding and validating the wikitext and then converting it to HTML and caching it. The next person seeing the article will then (most of the time) get a shorter page rendering time as some of the time has already been spent by you. Anonymous users get their results from an even faster cache, because it doesn't have to take into account user specific things like account name, preferences, etc. The solution is either massive changes to how wikitext works (we really should, but there is no way people would ever agree to it), or showing you the old version after you save, or simply make the page smaller. While the speed of your computer and your internet is a factor in submitting and rendering the new page, and also scales with the size of the article, the time spent at the serverside is generally a larger ratio of the total time. —TheDJ (talk • contribs) 14:40, 22 June 2026 (UTC)[reply]
@1brianm7 for some reason the file isn't pulling through from Commons as you can see with the 0 x 0 size. I've tried purging the file but with no luck. Nthep (talk) 07:32, 23 June 2026 (UTC)[reply]
I just tried reuploading the file with a normal PDF, as I wondered if it had been caused by me uploading the PDF with text, but it appears to have broken the file anymore. Before I did that, the front page of the file had started appearing in the article, no longer appearing as File:Is Lindbergh a Nazi?.pdf in article text, but the PDF feature was still broken. Since reuploading it, it is back to appearing as File:Is Lindbergh a Nazi?.pdf1brianm7 (talk) 07:43, 23 June 2026 (UTC)[reply]
The alerts icon next to my username at the top right of the screen shows that I have one notification, but it is greyed out. When I click on it, it reports "failed to fetch notifications". Please assist me in getting rid of this, thank you. --Viennese Waltz06:48, 22 June 2026 (UTC)[reply]
I don't know if this is just me, but over the last week or so {{reflist}} doesn't put references into columns. The odd behaviour is that setting a column width of 30em causes the references to be in columns, but 30em is meant to be the default so it shouldn't cause a change. This is a problem that used to plague the use of references/ tags but I thought that was fixed. -- LCU ActivelyDisinterested«@» °∆t°10:10, 22 June 2026 (UTC)[reply]
I use the desktop site on mobile (Chrome on Android), using the vector 2010 skin. The odd part is the split behaviour, setting the default shouldn't change how it works. -- LCU ActivelyDisinterested«@» °∆t°10:28, 22 June 2026 (UTC)[reply]
I checked on desktop site on mobile Chrome on iPhone with vector 2010 skin and I don't get the issue. I guess wait and see if anyone else is experiencing the same issue. KylieTastic (talk) 13:34, 22 June 2026 (UTC)[reply]
Im wondering if something upstream has made a change that is checking my screen aspect ratio when formatting the references in the page, and is overriding my request for the desktop site when it comes to how references are displayed. I know they've been working in that area. -- LCU ActivelyDisinterested«@» °∆t°13:39, 22 June 2026 (UTC)[reply]
Are there more than 10 references in the reference list you're looking at? The default behavior doesn't add columns until after that. Otherwise, giving specific details as to what page you're looking at, and any other details that might be relevant, would help people look. Anomie⚔11:11, 22 June 2026 (UTC)[reply]
Thousands of reference, I'm well aware of the default behaviour. Any, and all, pages. This isn't an isolated incidence but every page I've look at over the last week or so. -- LCU ActivelyDisinterested«@» °∆t°12:25, 22 June 2026 (UTC)[reply]
Yes {{reflist|30em}} makes columns but {{reflist}} doesn't. I was expecting these to have the same behaviour. I remember a discussion about the use of <reference>...</reference> and that it doesn't apply sizing using the same method as {{reflist}}, but I think that was fixed. That used to produce the same inability to produce columns correctly. -- LCU ActivelyDisinterested«@» °∆t°13:37, 22 June 2026 (UTC)[reply]
phab:T334941 got fixed by having Vector 2022 set 27em rather than 30em. Later, {{reflist}} was changed to apply the font size in the same way that <references /> does, but it intentionally handles specified widths like {{reflist|30em}} in a way that gives the same column width that it did previously. That's in part to not break 2-columns on Vector 2022 where {{reflist|30em}} had worked before but wouldn't with the new method (i.e. the same reason that phab:T334941 was fixed by lowering it to 27em for Vector 2022). Anomie⚔00:02, 23 June 2026 (UTC)[reply]
But still why was Vector 2022 changed and not the incorrect behaviour of reflist, it seems like a weird bodge. Any chance this can be fixed by some personal CSS? -- LCU ActivelyDisinterested«@» °∆t°21:29, 23 June 2026 (UTC)[reply]
In Vector 2022 with its default settings, <references /> would display only one column when people expected two. That's why things were changed for that skin. {{reflist}} was changed because people were complaining about differences between it and <references /> that were holding up implementation of this RFC; reducing the differences was a way to resolve that. As for personal CSS, you might try something along the lines of .mw-references-columns{column-width:27em!important;}. Anomie⚔23:15, 23 June 2026 (UTC)[reply]
According to a recent API query (matching title and timestamp), Special:Diff/1357030472 caused List of state roads in Malaysia to exceed the WP:EXPENSIVE limit. But I am completely paralyzed as to how one would go about resolving it. I can see that there are new calls to {{Flag}}, {{JKR}}, {{JKR(T)}}, but going down the transclude-chain to the modules that ultimately implement them, I do not see any of the obvious tells for expensiveness. So what's going on here? Artoria2e5🌉13:57, 22 June 2026 (UTC)[reply]
Oddly, testing in a sandbox the {{JKR(x)}} functions are incrementing the expense count by 1 but {{JKR}} does not. So that accounts for 521 out of the 526. As for why, I can't see a reason as they look be be pretty much the same. KylieTastic (talk) 14:40, 22 June 2026 (UTC)[reply]
{{JKR}}, {{JKR(T)}} and similar templates say: "If the proper image does not exist on this wiki or Wikimedia Commons, the template will display the route number in italics until the image is uploaded". Some images are assumed to exist with code in Module:Road data/strings/MYS, probably for efficiency after somebody saw they do exist. Others use 1 expensive parser function of 500 allowed to test for existence. The JKR templates call {{jct}} which accepts a |noshield=yes parameter to not display an image and omit the ifexist check on the image. The JKR templates don't pass on such a parameter so it cannot be used now but it could be added with |noshield={{{noshield|}}} in the jct calls. Then List of state roads in Malaysia could say |noshield=yes in some of the JKR calls where no shield is currently displayed. It would mean a shield is not automatically added later if an image is uploaded. PrimeHunter (talk) 15:13, 22 June 2026 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I have long been kicking around the idea of refactoring the way that Template:Location map works specifically in infoboxes and want to solicit some feedback on the idea.
The problem
Every implementation of pushpin maps in an Infobox is different. There are numerous different parameters used to define the base map including: |map=, |pushpin_map=, |location_map=, |locmapin= and |map_type=. This makes it very difficult to go from one Infobox to another as you never know what parameters to use. The same issue applies to other aspects of the pushpin map such as the label, caption, label position, relief, etc. If you compare this to Template:Infobox mapframe, every single Infobox that uses a mapframe uses the exact same parameter names. Want to change the marker? That will always be set via |maprame-marker=. The zoom? Always|mapframe-zoom=. Doesn't matter what Infobox you are on.
A solution
What I would like to do is create a new entry point to Module:Location map, probably {{#invoke:Location map|infobox_location_map}}, that would allow for calling the location map (aka the pushpin map) in an Infobox and keeping the parameter names the same across every Infobox. That way, whether you are using {{Infobox settlement}}, {{Infobox airport}} or {{Infobox military installation}} the parameter names would all be the same. Just like Template:Infobox mapframe, I would also create a template for documentation (see {{Infobox mapframe/doc/parameters}}) so that documentation would be consistent across Infoboxes as well.
Implementation
Make no mistake, this would be a HUGE undertaking. It would involve refactoring close to 100 templates and then doing bot runs to clean up the hundreds of thousands of transclusions of those templates. Setting aside how much work it will be for a moment (and I am happy to undertake these clean ups...) my question is: "Is it worth it"? Is achieving consistency across Infoboxes and making it easier to go from one Infobox to another worth the effort here? I would argue it absolutely is, but I want to hear other inputs.
On the subject of whether it's worth it: Templates are a tool to ensure that we have consistency between articles. There's a reason we have a standardized infobox module that we use. There's a reason we use {{cite web}} when referencing web sources. I think it makes sense to have consistency between similar templates, especially when those templates are doing the exact same thing. An editor should not need to know 10 different ways to invoke a map just because they work across multiple areas of expertise on the project. As an example, if I'm working on the infobox of a racetrack and then a church later in the day, I shouldn't have to know that the racetrack infobox uses {{{track_map}}} and the church infobox uses {{{monastery map}}}.
Based on a few recent instances of negative reactions to some template changes, I can safely predict that there will be at least some opposition to some of these changes. I think that the burden will be on us as template editors to prove why the new standardized map systems will be better. We should prove to them why it's worth re-learning how to use the templates that they're accustomed to, and why they should support the cleanup effort that will ensue after said template change occurs.
If this is implemented, I think something that will ease the maintenance burden moving forward is very clear wording in previews that says "You have used {{{old parameter}}}, which is no longer supported, please use {{{other parameter}}} instead." The current wording of "deprecated parameters" is somewhat unclear to an amateur editing an infobox. In unknown parameter cleanup, we see this somewhat often. Someone sees a parameter named {{{foobar}}} and wants the label on it to read Foobars, not realizing that the {{{label}}} has {{Pluralize from text}} applied to it. They change {{{foobar}}} to {{{foobars}}} and the article gets chucked into an "unknown parameters" maintenance category.
Well as one of the editors who has had suffered a right royal pain in the ass every time I have tried to make what seemed a trivial change to the mapping in an infobox, I totally endorse this proposal. 𝕁𝕄𝔽 (talk) 18:40, 22 June 2026 (UTC)[reply]
I think this makes sense, but I feel like I'm missing something about the implementation. Why does this require a new entry point to Module:Location map? Isn't this just a matter of editing the templates to use consistent parameter names?
Also, separate from that question, template parameters have aliases sometimes, right? To ease the transition, would it make sense to set it up so that editors using each infobox template can use either the old parameter names or the new standardized parameter names? Justin Kunimune (talk) 22:12, 22 June 2026 (UTC)[reply]
@Justinkunimune: I have not yet dived into the code so a new entry point may ultimately not be needed. The tricky part is how to make this new idea work without breaking anything else. That is why I might opt for a new entry point so that I can use the existing code but also customize it to fit. Gotta make sure that uses of {{Location map}} that are not in an Infobox continue to work when this is all done. Not 100% certain as to the how just yet, but I have a number of ideas.
As to your second question about aliases, that is 100% accurate and exactly how this will work. If we move forward with this, once the coding is done and we start the roll it out, we will deprecate the old parameter names in favor of the new names that are decided upon. Then we will do a bot run to clean them all up and only then will the old existing aliases be removed. Translation: at NO POINT should any pages be affected for the reader. This is all backend code refactoring that would only be a noticeable different if you are editing. Zackmann (Talk to me/What I been doing) 22:18, 22 June 2026 (UTC)[reply]
What about removing pixel map size while you are at it? MOS (manual of style) already says that images are supposed to be default size.
Images could be under 250px size. (250px is the default image width) An sub 250px image would be more likely as an non-free image.
I do not see an map being smaller than 250px wide. I ran an SQL query for an sub 250px image on commons with "map" in the name, and gave up once it had ran for 15 minutes. Mapframe would not be smaller than 250px as it uses maptiles. You would want to support countries like Norway and Vietnam that are thin and long, but that is what upright is for. See also Module_talk:InfoboxImage/Archive_2#Help_with_improving_default_image_sizes for an previous discussion. Snævar (talk) 23:35, 22 June 2026 (UTC)[reply]
@Snævar: I'm wary of removing functionality as part of this changeover. In my experience, when you mix a refactor with actual substantial changes, the project collapses. Someone objects to the change and so the refactor never occurs. While I don't disagree with your point about size vs upright, I would note that almost every Infobox has a |image_size= still.
That all being said, this changeover will make the eventual removal of |pushpin_map_size= much easier as all we have to do is remove support from the new entry point for this and poof, all transclusions no longer use it. I just think that removal warrants further discussion. Zackmann (Talk to me/What I been doing) 23:43, 22 June 2026 (UTC)[reply]
The technical details here are a bit over my head, but I'm extremely in favor of standardizing and simplifying things like this. Sounds like it would take some work up-front, resulting in things being more streamlined in the future. I'm all for it. Jessicapierce (talk) 01:42, 23 June 2026 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
You may be seeing a banner we recently added that specifically shows to users who have not confirmed the email address on their account. If that's what you are seeing, then it means you likely never clicked on the link to confirm your email address that was sent when you first created your account. In that case, you should follow the link to confirm your email address.
Wikipedia has a high rate of users in this situation, as we haven't historically required users to complete email confirmation before allowing them to edit. But it's not a good situation for those users to be in, since they're going to be more likely to get locked out of their account if the email isn't something they actually control, and the day ever comes where they lose their credentials or get challenged to paste in a code from their email to log in. EMill-WMF (talk) 02:32, 23 June 2026 (UTC)[reply]
A little background in case you are still unsure what it's about: At some time you gave an email address which is stored at Special:Preferences. At the time Wikipedia automatically sent a mail to that address and asked you to click a link to confirm you have access to mail sent to the address, but the link was never clicked. If you don't receive a mail after using Special:ConfirmEmail then try setting another address at Special:Preferences. It's optional to set an email address. PrimeHunter (talk) 08:20, 23 June 2026 (UTC)[reply]
@GoodDay: You aren't asked to log out and it doesn't work if you do. Just enter your username and password to confirm you are GoodDay. It's a security measure so somebody else cannot change your email address if they get access to a device where you are logged in. PrimeHunter (talk) 20:30, 23 June 2026 (UTC)[reply]
I'm glad you resolved it for yourself. I do at least want to be on record here for the thread, that we strongly recommend you add a confirmed email, rather than remove it.
I mentioned above that accounts are at higher risk of lockout with an unconfirmed email. The risk is way, way higher with no email at all, as there's not even a way to reset your password. We also can't use email challenges to protect your account from takeover. So you are free to remove your email, but just know that there are risks and it is not recommended for most accounts. EMill-WMF (talk) 22:09, 23 June 2026 (UTC)[reply]
Thanks! Should also add this mainly happens when I'm using something like Quillbot to make ONLY changes to spelling and grammar. I NEVER use its generative AI. I tested it with a non-AI extension called Harper and had the same thing happen. Wolfcolallc (talk) 03:53, 23 June 2026 (UTC)[reply]
@Wolfcolallc those kinds of tools are known to work very badly with editable HTML (which is what Visual Editor is). There's a lot of browser dependent magic that is needed in these things and then on top of that there's even more magic needed to keep wikitext and html in sync. —TheDJ (talk • contribs) 09:26, 23 June 2026 (UTC)[reply]
The top right of VisualEditor has a pencil icon which can switch to the source editor where some tools work better. I suggest to use both "Show preview" and "Show changes" before saving. The latter can reveal unwanted source code changes. PrimeHunter (talk) 09:39, 23 June 2026 (UTC)[reply]
I’ll try that! I’m also just not using the auto-fix features anymore and noticed that I’m not having the same issue. Wish it worked but it is what it is. Wolfcolallc (talk) 20:03, 23 June 2026 (UTC)[reply]
Template usage
Hi,
I've posted these questions in the Wikibooks Reading Room and after about 24 hr received no response.
(1) A template declared in my account namespace works. Declared in the book namespace it doesn't work. Both cases are demonstrated in my User:PeterEasthope/sandbox. Declaration in the book is more direct; better not to depend upon an individual account. Ideas? Thx.
(2) If the desktop browser window is narrowed or the sandbox is viewed on a smartphone, the display is as illustrated here. How can the black perimeter frame be shrunk automatically to fit the background color boxes?
Hi @PeterEasthope, each Wikimedia wiki is independent and templates are specific to their own wiki (though some common templates get cloned on multiple wikis). And the Books namespace exists only on Wikibooks sites (I think). Unless there are Wikibooks regulars also watching this page, I think you just have to wait patiently for help at the Wikibooks page. —In solidarity with Wiki Workers United · ClaudineChionh (she/her · talk · email) 05:10, 23 June 2026 (UTC)[reply]
Wikibooks has no namespace called "Book" or "Books". I guess it's an unofficial name for their main namespace. If you transclude from mainspace then you need a colon in front to avoid transcluding from the template namespace. Somebody fixed it in [13]. I don't know whether wikibooks:Oberon/ThreeBoxes is considered appropriate use of mainspace at Wikibooks. Wikipedia wouldn't use mainspace for that. PrimeHunter (talk) 07:55, 23 June 2026 (UTC)[reply]
The problem is that the categories are getting speedy moved from their existing names that largely had the word district in them, without any corollary effort to update the template accordingly. So it's not that it's making incorrect assumptions about the names, it's that it's generating and transcluding exactly the names it's coded to use, but somebody moved the category within the past couple of days before one of these appears, so the old name stays a populated redlink. But since not all of the "People from X District" or "People from X (district)" categories have been moved yet, there's a high risk of breaking other unmoved categories in the process, which is why I'm not generally prepared to try to muck with the template coding myself and keep having to recreate the non-empty redlinks as categoryredirects pending other fixes by people with more expertise. Bearcat (talk) 12:09, 23 June 2026 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
Growth features are now available at Wikidata. This update enables access to Mentorship (if configured), Impact module, the Help Panel, and a simplified Newcomer Homepage (without Suggested Edits). Wikidata administrators are still configuring the features through Community Configuration.
Updates for editors
The special page Special:RangeCalculator has been created. It allows users to find an IP range without needing to rely on external tools. Until now, this tool was only available to CheckUsers. [15]
Sub-referencing is a new MediaWiki feature that allows editors to reuse references with different details. It will be deployed to most small and medium-sized Wikipedia language versions on June 23. The FAQ lists possible actions to take on your wiki to support the deployment. Check the rollout plan for the next deployment steps. [16]
Starting next week, users will get a notification when they are blocked or unblocked from editing, or if this block changes. [17]
Starting next week, abuse filters that are set to "require CAPTCHA verification" will begin to also affect users with the skipcaptcha right, which includes most autoconfirmed users. Bots are exempted. This change only affects edits that trigger an abuse filter. The skipcaptcha right will continue to exempt users from having to solve CAPTCHAs in the ordinary course of using the wikis. [18]
Reference documentation for the Lift Wing API has moved from the API Portal to the interactive REST Sandbox.
On June 22 I marked some pages with speedy because I needed the respective titles to be cleared out for other pages to be moved to them. I didn't note down the pages where I added speedy. Would anyone be so kid to give me their list? Thanks! (Please ping.) Gikü (talk) 18:19, 23 June 2026 (UTC)[reply]
There are a large number of infoboxes that include information about how to best access the location via public transit and/or the nearest parking facility. These values would, to me, appear to be direct violation of the fact that Wikipedia is not a guidebook at best and at worst would seem to be promotional information which serves nothing but to promote the best way to reach a certain location.
I will also quote from MOS:INFOBOXPURPOSE that The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article. I question what encyclopedic value exists in listing what metro or bus stop is nearest to a certain building?
Comment my first thought is that for some articles, whether there is public transport and/or parking is a key aspect. Certainly whether a public airport has public transport access is a very important aspect of the topic. Thryduulf (talk) 22:35, 22 May 2026 (UTC)[reply]
An alternative reading of that stat is that the parameter is only being used where it is key information - exactly as it should be. Thryduulf (talk) 23:59, 22 May 2026 (UTC)[reply]
Comment I think it's just unnecessary in general since several buildings, tourist attractions, airports, restaurants, etc. have public transit access. Aspifi (talk) 22:59, 22 May 2026 (UTC)[reply]
As transportation facilities, airports seem to be in a different class than the others listed here. Public transit and parking are connections at airports (just as they are for train stations), not merely access; we should keep them (and use the parameters much more widely). I'm neutral about the others. Pi.1415926535 (talk) 23:02, 22 May 2026 (UTC)[reply]
Prefer to keep. I'm mostly on board with the other discussions, but there are cases where public access is indeed well reported and well noted, and in such cases, I think it should be kept. However, it should be used sparingly and only in non-controversial cases. I'm just not quite on board with blanket removing it. guninvalid (talk) 02:02, 23 May 2026 (UTC)[reply]
The downside is that its debated on whether including parking/public transit is considered promotional or not. Aspifi (talk) 04:09, 23 May 2026 (UTC)[reply]
Well, this should be a solved problem already then perhaps?
Comment While I agree that using the param for nearby transit/parking would be inappropriate, if the transit/parking directly serves the location in question I would argue it would be appropriate. For example, the usage in Ottawa Macdonald–Cartier International Airport would be appropriate because the station was built to serve that location, and perhaps saying the rough number of parking spots may also be fine. There is also the option of being vague, for example saying a simple "Yes/No" for parking, or saying "Buses" for public transit. JumpytooTalk04:10, 23 May 2026 (UTC)[reply]
It could be used to highlight an unusual aspect of the place in question, for example a mall having no (or very little) parking at all. And there would also be sources noting that aspect in such case, which would meet the WP:DUE. JumpytooTalk04:38, 23 May 2026 (UTC)[reply]
CommentWP:NOTTRAVELGUIDE, the relevant part of WP:NOTGUIDE, does not explicitly cite transportation links as part of its remit. I agree that an excessive discussion of transport routes would be a NOTGUIDE vio, but a simple one-off mention of the nearest transport links in the infobox does not seem to be against the 'letter of the law' here. Athanelar (talk) 04:27, 23 May 2026 (UTC)[reply]
While it is not directly mentioned in NOTTRAVELGUIDE itself, I still think it's promotional. If someone from Florida wants to know if a tourist attraction in Arizona offers free parking, they are expected to check the place's website, not use an encyclopedia. Aspifi (talk) 02:16, 24 May 2026 (UTC)[reply]
Comment I can't say I see how including public transit information, in and of itself, could be considered promotional information. There are ways that it could be written promotionally, but those can be handled accordingly. XtraJovial (talk • contribs) 17:21, 23 May 2026 (UTC)[reply]
Comment I can't imagine this ever being due/non-guidebook information for the infobox. If there is something unique about the public transit for these subjects it'd probably need to be covered by prose regardless. Traumnovelle (talk) 20:43, 23 May 2026 (UTC)[reply]
How is it encyclopaedic? If I am reading about a performance venue in another country the public transit access is the least of my interest. If someone is wanting to travel to one they should consult the website of the venue itself. Traumnovelle (talk) 01:41, 24 May 2026 (UTC)[reply]
Oppose argument per Traumnovelle. It's not encyclopedic because it's not notable information. Someone living in Texas is not expecting an article about a mall in Maryland like Marley Station Mall to tell them that their parking options are free because the average shopper is not going to spend three hours driving into another state just to arrive at a destination. As an editor who has done work on several articles about shopping malls and entertainment venues in the U.S. and some in Canada, is not crucial at all for the average building, especially office buildings. Aspifi (talk) 02:00, 24 May 2026 (UTC)[reply]
It is e.g. notable when opera/concert reviewers in The New York Times, who are not used to on-site parking, remark on their surprise of seeing Washington venues surrounded by parking lots. -- Michael Bednarek (talk) 03:16, 24 May 2026 (UTC)[reply]
Disagree - The average reader does not need to know that a building has a specific number of parking lots, let alone if it's free or not. Compare it to amusement parks where you need tickets; several events need tickets. Aspifi (talk) 02:03, 24 May 2026 (UTC)[reply]
WP:IAR !keep then, and never thought I'd ever IAR first time over something like this. I really like having these here now that I've actually noticed them. But you're right, 100%. I got no counter argument. I had genuinely no idea these are omnipresent on Wikipedia. The first team I thought of was the Padres just now, and sure enough on Petco Park, there it is. And I see it as being encyclopedia worthy because it's also really just a little bonus mission-specific ==See also== that gives you for that article as an example:
I dunno. I still remember the entire bottom third of my childhood bedroom closet that was just paper encyclopedias with text so small my now-aged eyes shudder in terror thinking of. Hundreds of pounds of books read cover to cover. Some rather sketchy back to the 30s, 50s. But it's 2026 and soon 2036, and what ought to be gets updated too sometimes. Keep. (Sorry, I was on the fence prior.) — Very Polite Person (talk/contribs)02:52, 24 May 2026 (UTC)[reply]
Subsuming parking access and/or public transit access under WP:PROMO seems to be casting a very wide net. One wonders if by such logic any kind of transportation or accessibility information would count. I think we need to define WP:PROMO narrower than that. And I generally think that WP:NOTTRAVELGUIDE requires a lot of detail (cherrypicking one cafe is WP:UNDUE another policy) not one or two mentions. Jo-Jo Eumerus (talk) 08:45, 24 May 2026 (UTC)[reply]
Keep - It's a real stretch to consider transit info WP:PROMO. I think we can dismiss that concern outright. WP:NOTGUIDEBOOK is closer, but I don't think a straight reading of that really applies here either. The text of that guideline is concerned almost entirely with explaining that Wikipedia should not make recommendations to users. (For example, list a city's best restaurants.). That's a worthwhile guideline, but I don't think it applies. To anyone who lives in a city, specifying what transit line a thing is on is a practical way of specifying a location. We include GPS coordinates, but "on the green-line" is a more human way of conveying that same information. It's not instructions or suggestions to the reader, it's location information. ApLundell (talk) 21:39, 24 May 2026 (UTC)[reply]
"It's location information" Why do you think someone out of state wants to know how to get to a tourist attraction in Florida using an encyclopedia? I am going to quote WP:NOTTRAVEL directly: "while Wikipedia has descriptions of people, places, and things, an article should not read like a "how-to" style owner's manual, cookbook, advice column (legal, medical or otherwise), or suggestion box. This includes tutorials, instruction manuals, game guides, and recipes. Describing to the reader how people or things use or do something is encyclopedic; instructing the reader in the imperative mood about how to use or do something is not." Aspifi (talk) 21:52, 24 May 2026 (UTC)[reply]
What part of stating "this airport is served by the city's metro" or "this theatre has on-site parking" is instructing the reader in the imperative mood about how to use or do something? People who live outside the state of Florida but who might consider a trip there are not the only people reading encyclopaedia articles about things in Florida that could be tourist destinations. Thryduulf (talk) 22:26, 24 May 2026 (UTC)[reply]
If you are confident in your position, you don't have to reply to every single person who disagrees with you. I believe there is also a policy about that.
Anyway, my position is unchanged. I continue to disagree that mentioning a transit line is "how to" style content or any other form of recommendation to the reader. To me, that assertion seems obviously incorrect, for reasons I've already explained. ApLundell (talk) 23:23, 24 May 2026 (UTC)[reply]
It isn't describing how to do things, though, it's neutrally giving them information on transit links, which are encyclopedic information.
Keep per my comment above. Per Thryduulf and ApLundell, Mentioning public transit connections is not instructing readers how to do anything. It's just mentioning them. Editors have to go out of their way to convey such information in a manner that goes against WP:PROMO or WP:NOTGUIDE anyway, and we already have methods to handle that. XtraJovial (talk • contribs) 00:38, 25 May 2026 (UTC)[reply]
Keep these, at least in most of the infoboxes, but especially for the airports. I think they will often not be appropriate to use, but the parameter should be there for the situations in which it is appropriate. Saying that the Louvre is almost on top of a subway stop is not giving tourists directions; it's telling readers what's underneath that big glass pyramid of a skylight. WhatamIdoing (talk) 04:48, 26 May 2026 (UTC)[reply]
Comment, I am not sure of the value of a parameter for parking, but I can see how the public transport parameter could be useful. If the infobox for a London landmark has the nearest rail/underground station, I would probably be able to visualise whereabouts in the city it is quite easily without having to zoom in/out on the map. EdwardUK (talk) 18:42, 26 May 2026 (UTC)[reply]
Keep. I don't agree that listing the existence of public transportation access is PROMO or NOTGUIDE. If consensus were to reach that it is, I would agree with Very Polite Person that we should WP:IAR. I could see the value of having all of these public transit connections in the template because here is really the only place on the web that all of this info could be centrally listed. That would be very helpful for someone who is trying to research that, for example. So I think it does have potential encyclopedic value, even if you're someone in Texas looking up a place in Arizona. Parking could theoretically be PROMO so I think that should be treated case by case, but this conversation is about public transportation and I don't consider parking to be in that category anyway. Edittttor (talk) 20:45, 26 May 2026 (UTC)[reply]
Keep, partially per Edittttor and partially per VPP. Public transit connections are often useful for locating a place within a city. I know if you told me which transit lines connect to a place in the city I live in that would be much more useful for envisioning where it is than coordinates. However, also, I think this information is useful enough that I'd favor an IAR override of WP:NOTTRAVELGUIDE even if it was unambiguously covered. I don't think it is, though. Loki (talk) 21:51, 26 May 2026 (UTC)[reply]
Keep, with the caveats mentioned by guninvalid and Jumpytoo. I don't think PROMO is a significant risk here, but there is a risk that excessive or trivial parking/transit information could have WP:NOTGUIDE or WP:DUE issues. That said, it's easy enough to think of various situations where transit access information is pertinent or noteworthy, with the result that I don't think it'd be helpful to proactively warn against including it. ModernDayTrilobite (talk • contribs) 17:01, 28 May 2026 (UTC)[reply]
Keep the public transport information for two reasons. The first is already expressed by XtraJovial regarding whether such information violates WP:NOT in the first place. The second is that I worry about the wider implications to the article text. Per MOS:INFOBOXPURPOSE, as mentioned in the opening statement, The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article. If the information is inappropriate for mentioning in the infobox as a simple listing for violating WP:NOT, by extension it would imply such information should not be mentioned in the article at all in an elaborated prose manner. And I cannot possibly support opening up an opportunity for a blanket removal such that Changi Airport does not mention Changi Airport MRT station at all, or that Trafford Centre does not include The Trafford Centre tram stop, per WP:COMMONSENSE if not for anything else. S5A-0043🚎(Talk)02:59, 29 May 2026 (UTC)[reply]
Comment - While this info may be relevant and DUE to include in the article, the infobox is different. The infobox should be summarising key details, not trying to cram in the whole article. Detail like this can be included in the body of the article without having to be in the infobox. Of course - if it isn't in the article body (and appropriately referenced) then it shouldn't be in the infobox either).Nigel Ish (talk) 09:23, 29 May 2026 (UTC)[reply]
Remove in most cases. In some cases the transit access is noteworthy, such as an arena that has its own subway station directly below it, a college that has a train station named for it, an airport where its integration into the transit network is key to its purpose. But in most cases these infobox params are heavily overused, being used to just note the nearest transit access that might be blocks away. Helpful if you're trying to navigate to that location, but not encyclopedic. See for example Washington Monument, which links to a metro station hundreds of yards away, or The Cloisters, which links 2 subway stations that are half a mile away and 3 bus lines that happen to pass nearby. Toohool (talk) 16:12, 31 May 2026 (UTC)[reply]
As a note to anyone else who misreads as I did "remove" is not being used here to mean "remove the parameter", rather "keep the parameter but remove most uses of it in articles". Thryduulf (talk) 16:36, 31 May 2026 (UTC)[reply]
Keep This would not be a meaningful improvement and the existing infobox parameters are non-intrusive and would not violate WP:GUIDEBOOK.LivinAWestLife (talk) 10:15, 2 June 2026 (UTC)[reply]
Suggestion. This is probably not notable as encyclopaedic content but it is useful to some readers. Wikimedia already has a place for this sort of travel information, Wikivoyage. How about we remove it from Wikipedia but routinely link Wikivoyage instead? That way we keep Wikipedia encyclopaedic while still making it easy for people who want that sort of useful information to find it. (BTW, I strongly disagree that listing public transport is in any way promotional. It's not like bigging up a specific taxi company or something.) --DanielRigal (talk) 10:32, 2 June 2026 (UTC)[reply]
Keep as a small amount of information like this does not make the article a guidebook. We may even have whole articles about bus stops, and most train stations and airports. When there are topics not notable in themselves, but supported by stuiable sources, then it can be included. Mentioning a provider name is not promotion if the coverage is due. So for example if one bus company is mentioned, then perhaps all the others should be included. But for a parking lot, perhaps we don't need to mention that it is operated by Wilson Parking. Graeme Bartlett (talk) 11:55, 2 June 2026 (UTC)[reply]
Keep both the transit and parking parameter (which perhaps would have benefited from a separate thread) per the arguments above — this is significant encyclopedic information that meets WP:LEADWEIGHT in some but not all circumstances, and it should be retained so it can be used in those circumstances. It does not inherently make Wikipedia promotional or a guidebook. I will note that the parking parameter, at least at {{Infobox building}}, is explicitly scoped to on-site parking, not nearby unaffiliated parking, and this ought to be the case anywhere the parking parameter is used. Sdkbtalk20:30, 14 June 2026 (UTC)[reply]
Lean keep. As others have mentioned, stating the public transport access is not promotion, otherwise, every single mention of any company would already have been considered “promotion”.
While Wikipedia isn't a guide book, I believe just a quick mention of the connections, which is basically those few lines in the infoboxes, are fine. And some pages rely on these train stations to explain their location!
The problem I’m seeing is that such mentions are unencyclopedic, which could be easily resolved via a tone revision. Additionally, not all pages about a place have a Wikivoyage equivalent, so there wouldn’t be a place to mention such connections other than the page on Wikipedia.
And about the parking spots? (idk why some people are mentioning it even though this is only about public transit access) I’m neutral about it, fine to keep if there’s a source available. Hason-LEK-SIN ● Let’s chat! ● My contribs10:36, 22 June 2026 (UTC)[reply]
Lean keep. I can see the NOTGUIDE argument and can sorta see the PROMO concerns but that seems like a stretch. Detailed information on how to get to a location or about the cost of parking would be inappropriate but the straightforward infobox params seem potentially useful and otherwise harmless, and can reasonably be considered part of the basic information about a place. I don't see the benefit of removal nor any evidence of harm. —Myceteae🌈 (talk) 16:27, 22 June 2026 (UTC)[reply]
Replace the link “Content portals” with “Wikiprojects” in Main Page
Replaced the link to the Portals space with a link to the Wikiprojects in Main Page.
Background
Since 2017, The portal space continually lose space on Wikipedia, motivated by low readership and poor maintenance, WP:PWP and Wikipedia:Arbitration/Requests/Case/Portals#Community_discussion_recommended were ignored by the community. Analyze this graph [20]. Portals have been losing views in the last years. There have been many discussions about this, but the fact is that, after years, the status quo of the portal space, a skeuomorphic version of 1990s websites, remains the same. It is unclear what the purpose of this tool and the attempts to improve the portals don't seem to be moving in a solid direction (transclusions, for example, have solved some problems and created others).
Wikipedia:Contents/Portals is itself a very outdated page in terms of layout and content when compared to the others linked in the same template. Its last edition was in 2022, while the others have had recent editions, and unlike the others it doesn't use any modern styling tools like .css.
Wikiprojects are also largely neglected, but on the other hand, they do not face the same existential crisis as the portals, with many users calling for their elimination. And they have never been given a prominent spot on the main page. Some users felt that linking to them on the main page might be a good idea and could help revitalize the space.
Per Wikipedia:Portal#Purposes of portals"Providing bridges between reading and editing, and between the encyclopedia proper and the Wikipedia community, via links to pages in project space...", Portals are failing miserably in their mission, so this proposal serves to disintermediate, directing readers from the main page directly to the Wikiprojects.
Support either, with a preference for 1. WikiProjects can get editors engaged by helping them find a sense of community, and are generally much more active than portals. The directory would help prospective editors find relevant WikiProjects faster instead of having to go through the information page (more disintermediation). Chaotic Enby (in solidarity · talk · contribs) 18:43, 10 June 2026 (UTC)[reply]
Lean oppose. I'll be honest, I find portal somewhat baffling and don't spend much time with them. That said, the pageviews statistics you shared shows that all of these continue to get >2,000 views/month, which is more than many articles. WikiProjects serve a strictly behind-the-scenes purpose. Some WikiProject pages provide something of an overview of their content area but most don't. I don't follow the logic that WikiProjects are a good replacement for Portals on the main page, but perhaps there are separate arguments to add the project links. Outlines strike me as a better replacement for Portals, though these have their problems and detractors, too, and I'm not necessarily suggesting this. —Myceteae🌈 (talk) 01:40, 11 June 2026 (UTC)[reply]
Hiding our "behind-the-scenes" pages is exactly what worries me, as it creates an artificial wall between readers and editors. Why shouldn't readers get to know how the encyclopedia is made and how they can help too? Chaotic Enby (in solidarity · talk · contribs) 08:02, 11 June 2026 (UTC)[reply]
I have some initial reservations about sending tons of new editors to WikiProjects but I'm open to the idea and broadly supportive of increasing participation. In one of the discussions that the OP linked (Wikipedia:Village pump (idea lab)/Archive 79#WikiProjects in Main Page) the handful of participants seemed more or less supportive of linking WikiProjects on Main but the conversation stalled in discussing issues that may or may not need to be addressed prior to publicizing the projects in this way. Editors there noted that WikiProjects (like Portals) have varying degrees of maintenance and activity and that there are two different directories (Wikipedia:WikiProject Council/Directory and Wikipedia:WikiProject Directory) which might be linked to. Both directories were felt to (possibly) be in need of cleanup and it was not clear which would be better to link to from Main. It was noted that publicizing WikiProjects on Main could be broadly aligned with the WikiProjects 2.0 objectiveWikipedia-wide recommitment to WikiProjects. After leaving my initial response, I read WP:PWP and some of the other essays and discussions on the topic of Portals. I was largely responding to the framing—that WikiProjects are a substitute for Portals and that we should link to one or the other from Main. I would decouple the decisions and assess the merits of linking to project and Portals independently. For some editors, part of the assessment may be that WikiProjects and Portals accomplish similar goals and linking both is redundant if one does so better. But I see them as having quite different functions and purposes and don't think it should be one or the other. If Portals are such a mess, we shouldn't link to them regardless of whether there is a replacement. If the goal is to find a replacement then Wikipedia:Contents or Wikipedia:Contents/Outlines seem more similar in function and purpose. If editors want to promote WikiProjects in this way, we should move that discussion forward whether or not we continue to link Portals. —Myceteae🌈 (talk) 14:56, 11 June 2026 (UTC)[reply]
From the last big discussion about Wikipedia:Contents, the impression seems to be that the community does not know what to do with it as a whole. How do the pae views for portals compare with the Contents pages in general? Separately to portals, I'm hesitant to promote WikiProjects as many of those are dead too. CMD (talk) 02:34, 11 June 2026 (UTC)[reply]
Support any, 1 is the best. First of all, some seem to have brought up other Wikipedia's, but we are our own project and really the information brought up is tangential. Secondly, portals are an absolute confusing mess (built on the WikiProject system which is already a bit messy and has been proposed major changes many times over the years) that aren't really helpful. I can find out about things similar to what I am reading, by, ya'know, clicking the blue links everywhere. Ilov3gam3z (talk) 11:55, 12 June 2026 (UTC)[reply]
Why not both? I don't think the best answer to "this system isn't working as intended" is necessarily "let's throw it out completely". While I admittedly haven't used portals much myself, I think conceptually they're a great idea, and we could lean into them as a gateway to the Wikipedia-diving "rabbit holes" that people love so much. We could then additionally integrate portals and relevant Wikiprojects: portals could have links to relevant Wikiprojects in their subject areas, and the relevant Wikiprojects could take up the maintenance of the portal. Portals could even act like a "homepage" for these Wikiprojects, helping to bridge the gap between readers and editors. Athanelar (talk) 05:55, 16 June 2026 (UTC)[reply]
One thing I have seen people say is that portals failed due to proliferation: 10 core portals can easily be maintained, but 500+ are doomed. I wonder if something like that happens with wikiprojects as well. Military history, film, medicine, video games, and maybe a dozen others all chug along, but most are barely existing. I suspect that folding all of the topic wikiprojects (not RX, GOCE, WiR, URA, etc.) and all of the topic portals into a small subset with reader-facing portals would strengthen both the wikiprojects and the portals, but I also don't think that plan would get consensus. Rjjiii (talk) 02:47, 17 June 2026 (UTC)[reply]
There are other key differences. Projects are intended to be self-directed and self-sustained, and not reader-facing. Inactive or minimally active WikiProjects are (mostly) harmless whereas poorly maintained Portals may contain outdated or frankly erroneous information. —Myceteae🌈 (talk) 15:53, 17 June 2026 (UTC)[reply]
Oppose. It may be instructive to look at the main page of other wikipedias.
French has a link to Portails thématiques top and centre in the header (where English Wikipedia's portal links used to be)
German links to its eight top level portals such as Geographie, bold top and centre
Spanish has a main page box listing and linking to over 50 of its main portals
Dutch links its top ten portals in the header, with a bold link to their portal of the week
Portuguese links to the a list of portals and directly to its nine broadest portals
English already makes portals far harder to find than in other major wikipedias (hence the lower page views), and there's no reason to hide them further. Certes (talk) 17:35, 11 June 2026 (UTC)[reply]
Regarding "poor maintenance", I think part of the solution is streamlining and automating portal maintenance where possible. If you check out Portal:FOSS, it is using {{top7}} and {{portal content}} which draw styling from a Portal-specific style sheet. Another part of the solution is narrowing down the portals. I think a start to that (and I may try something to this effect when I have the time) is to create clear criteria for deleting/keeping portals. Rjjiii (talk) 02:53, 17 June 2026 (UTC)[reply]
For future reference, can you please provide an overview of the specific discussion to which you are drawing attention, and a direct link? Without this, it's hard to know why this notification might be of interest. You may also wish to review Wikipedia:Canvassing § Appropriate notification. Your co-operation is appreciated. isaacl (talk) 17:04, 16 June 2026 (UTC)[reply]
Yes, the page describes circumstances when it may be appropriate to post a notification on a village pump page, but not all discussions should have corresponding notifications, as that would swamp the village pump pages. isaacl (talk) 17:52, 16 June 2026 (UTC)[reply]
These notifications certainly could have been improved but I hardly see any concern for canvassing here. Content assessments and GA status are broad topics that (may) impact the entire project. Combining notifications about two different discussions of related topics looks to me like an attempt to reduce the number of threads on this page. —Myceteae🌈 (talk) 23:42, 16 June 2026 (UTC)[reply]
I didn't express any concerns regarding notifications with the intent to bias the discussion. As I stated, it's not a scaleable approach to post notifications about every discussion to the village pump pages, and being vague about the discussions doesn't improve scaleability. isaacl (talk) 01:09, 17 June 2026 (UTC)[reply]
I would like to propose creating a Soroban Template and Module for Japanese Wikipedia and Wikisource.
Many Japanese soroban books contain abacus diagrams. A reusable template would help editors display these diagrams clearly and consistently without uploading many separate images.
The template could support rod numbers, bead values, and unit dots, similar to other diagram templates.
This would be useful for soroban articles, old textbooks, and Wikisource transcriptions.
Here are books from the NDL Digital Collection that could benefit from this template.
Articles about the history of places when the places do not have articles
There are many articles about a specific event that happened to a structure or a similar location, but no article about the location itself. In cases where the event is a major part of the location's history, I propose reworking the articles about the history into articles about the location on a case-by-case basis.
This could be done by adding content and then renaming the article after it covers the entire subject, or creating a new article about the location and then merging the event article into it. Thebiguglyalien (talk) 22:24, 18 June 2026 (UTC)[reply]
My first thought is that the approach would be similar to WP:1E and that, as you suggest, it would be a case-by-case assessment. But it is reasonable to have a somewhat consistent approach where possible. If a building, bridge, etc. is primarily notable for one event, some expanded history/background could still be in-scope for an article about said event. On the other hand, in an article about (and named for) the place it may be appropriate to dedicate the bulk of the coverage to a particular incident. —Myceteae🌈 (talk) 23:00, 18 June 2026 (UTC)[reply]
You can add a "Background" section to the event article, and create a redirect from the building/structure to the section in the event article. The redirect can be linked to the WikiData item and categorised. Fences&Windows19:06, 19 June 2026 (UTC)[reply]
Only if you consider the building/structure to be the main topic. If the main topic is the event, then the building/structure is the subtopic. Also, notable events can occur in non-notable (or marginally notable) buildings. Blueboar (talk) 18:15, 20 June 2026 (UTC) Blueboar (talk) 21:57, 19 June 2026 (UTC)[reply]
That would be an interesting (if subjective) statistic to collect. I suspect many TA reverts are self-reverts (or reverts by parent when they see what their little darling has done). Any preventative measure would be easy to evade. Certes (talk) 08:48, 19 June 2026 (UTC)[reply]
Agreed. And even if I (subjectively) think that a particular revert was "wrong", that doesn't necessarily mean it was disruptive. Good-faith reverts by editors who don't have the full context are a dime a dozen. I also agree this would be easy to evade, especially by determined bad actors. A "revert" can be accomplished by simply deleting text. It would be strange to say that temp accounts can only add text and I'm not even sure that capability is possible. —Myceteae🌈 (talk) 03:51, 20 June 2026 (UTC)[reply]
A banned user is currently at large. Typically they edit as a TA, correctly get reverted, try again* and get reverted again. The starred edit is a TA undo (of the first revert) with the Reverted tag. Example target: James Wattana. Certes (talk) 13:14, 20 June 2026 (UTC)[reply]
Doesn't seem like a good idea to me. Most bad edits are not reverts. A revert just takes you back to an earlier version, usually a more stable one, one that's had more opportunities to be examined. --Trovatore (talk) 00:54, 20 June 2026 (UTC)[reply]
Agreed. Of course reverts can be problematic—any edit can be—but by definition they are just restoring something that was already there. —Myceteae🌈 (talk) 03:45, 20 June 2026 (UTC)[reply]
A very ill-thought-out proposal. Even experienced contributors self-revert for multiple legitimate reasons, and preventing TAs from doing the same is effectively ruling out self-correction. Or at least, it would be, if it wasn't so easily worked around. A bad fix for the wrong problem. AndyTheGrump (talk) 13:25, 20 June 2026 (UTC)[reply]
I believe the proposal is contrary to the purpose of Wikipedia as an open platform. In running an encyclopedia such as this, while devoted to it's mission, things that can't be adressed or are hard to adress arise. Anyone being able to edit unless special circumstances aply is a pillar of Wikipedia as per Wikipedia:5P4 "Wikipedia is free content that anyone can use, edit, and distribute". The issue of TA reverts as far as I see is nowhere near severe enough to further narrow the intrepretation of this pillar, because restrictions have been increasing all the time as it is. Finfixer (talk) 14:46, 23 June 2026 (UTC)[reply]
Proposal for a new WikiProject Intellectual Diversity
Okay, this is a bit of radical idea even by my standards but hear me out. I think we should retire the name "Move" for renaming pages and call it "Rename" instead. Meaning on the sidebar of articles it should be changed to "Rename" (by changing MediaWiki:skin-action-move and all similar pages, including updating the documentation such as Wikipedia:Moving a page).
Why?
It is quite confusing to newcomers and newbies. I do outreach and it's always confusing to them. I think it can make contributing more welcoming to new users and remove one small cognitive burden on them.
Everywhere else on the internet it's called "rename". Even in wiki-world, for renaming users, it's called rename and not "moving users".
It is hard to translate and causes confusion (phab:T294188#12035015 and phab:T429657#12036692) and in many languages such as Russian, it's already translated to "Rename" instead of "Move"
It has contributed to people picking really unsuitable icons for this action (see phab:T294188). It's currently which doesn't make any sense to me.
There is no need to make technical changes (unless I'm missing something super obvious), nothing would break when we change the labels only and we have had the precedent of renaming thins before (image -> file, "save" button -> "publish" button). The ticket for it is phab:T429657. Ladsgroupoverleg17:49, 20 June 2026 (UTC)[reply]
Support, given the greater ambiguity of "move", which can also apply to merely moving content within an article, or to various other meanings of Move. BD2412T18:19, 20 June 2026 (UTC)[reply]
Support per nom, although we have to keep into consideration that all of the move-related templates and processes (like Wikipedia:Requested moves) might have to be adapted for consistency, and also the tools relying on them such as Twinkle. A bit more ambitious that it appears on the surface, but definitely doable. Chaotic Enby (in solidarity · talk · contribs) 18:26, 20 June 2026 (UTC)[reply]
Comment Rename seems like a clearer name for moving within a namespace. What about other cases, e.g. Draft:Foo to article Foo in mainspace? Perhaps that really is a move rather than just a rename. As an analogy, some operating systems distinguish between renaming a file (change the filename only) and moving it to a different directory (folder) or device. Certes (talk) 18:44, 20 June 2026 (UTC)[reply]
@Certes That is valid but I looked at the data and it seems it most moves are inside one namespace (74% of moves in English Wikipedia are inside one namespace see phab:T429657#12035947). I was thinking that it the special page and the help page could start with something like "Rename the page or move it between namespaces" but the label for it could be Rename as it's more newcomer friendly + it's the majority of cases. Ladsgroupoverleg19:26, 20 June 2026 (UTC)[reply]
that is all renaming still, with different implied permissions. Restrictions for renaming might be name collision, topic protected, salted, namespace restrictions etc and no name will capture all of the technical scoping there. New editors will continue to be confused by WP:IMAGEIMAGE And HELP:IMAGE among other namespaces. ~ In solidarity 🦝 Shushugah (talk) 22:20, 20 June 2026 (UTC)[reply]
We don't have a "rename" for pages - this is literally a move, especially for cross name space moves. Moving between namespaces can be significant for multiple reasons - we shouldn't pretend it is something it is not. — xaosfluxTalk19:01, 20 June 2026 (UTC)[reply]
Quite frankly, actions that change the substantive title of a page should be considered separate from actions that change the namespace of a page. BD2412T19:18, 20 June 2026 (UTC)[reply]
This makes some sense. Even if it's the same process from a technical standpoint, there is an operational difference between moving between namespaces and changing the title of an article (or any other page). "Renaming" Draft:Foo to Foo sorta minimizes what's being done. —Myceteae🌈 (talk) 19:44, 20 June 2026 (UTC)[reply]
On the technical level, even moves between namespaces is still just a rename. The page id stays the same and page_title (basically the label of the page) changes. One could argue if wikipedia were a book, that would mean we are moving an entry from page 123 to page 456 but WP:PAPER. On "we shouldn't pretend it is something it is not." We do that all the time for the sake of usability. For example, deletion of a page is not really deleting it. It's just hiding it. Ladsgroupoverleg19:30, 20 June 2026 (UTC)[reply]
Or to the table of contents or an index or afterward or supplementary material or endnotes or forward… The namespace both defines and is defined by the type of content, its purpose and function. When we move something to a different namespace we are reclassifying it in a way that is meaningfully different than a mere name change. Whether or not it's useful of worthwhile to maintain a difference in the lingo, I'm not sure. —Myceteae🌈 (talk) 20:38, 20 June 2026 (UTC)[reply]
Comment: There is a lot I like about and agree with in this proposal. I've gotten quite used to our jargon but even I occasionally find it awkward. I sometimes find utility in conceptualizing it as a move, for example when multiple subpages will be impacted or, as another editor has raised, when switching from one namespace to another. Of course there are other ways to convey this, and just calling it a move actually doesn't really do this, and none this applies to article title changes, which are probably most relevant to most editors. —Myceteae🌈 (talk) 19:48, 20 June 2026 (UTC)[reply]
support way more accessible to the general population. Should have been done 20 years ago. May suggest also taking some inspiration from Commons, which turns the link onto a request for renaming form for those without the permissions. —TheDJ (talk • contribs) 21:50, 20 June 2026 (UTC)[reply]
Comment: "Rename" could overlap with the term "rename the user", which might still cause potential confusion. Are there any considerations for using alternative terms, such as "relocate" or "retitle" other than the term "rename"? Hakimi97 (talk) 00:01, 21 June 2026 (UTC)[reply]
If changing most (if not all) instances of move in the software really is as ambitious as you said in your first comment in this thread, then chances are, this would be a big enough chance to warrant listing on T:CENT. Although, the move feature is very visible like I said above, so I think I have changed my mind, and will go list it at T:CENT per WP:BOLD. - BlueEleephant (talk · contribs) 01:06, 21 June 2026 (UTC)[reply]
Cautiously supportive. Not sure if any other issues will arise, but the namespace issue does not bring me to oppose. For the purposes of most users, the namespace is indicated through the name. Neither word seems intrinsically more technically correct. CMD (talk) 00:46, 21 June 2026 (UTC)[reply]
Oppose. Don't fix what isn't broken. I sincerely doubt that this is seriously confusing to new editors or that a common word in the English language can be construed as jargon. There should be a consistency in naming page moves that are within the same namespace and those that are between different namespaces - and "rename" does not meaningfully apply to those between namespaces.Katzrockso (talk) 01:16, 21 June 2026 (UTC)[reply]
Eh. I think that "move" represents the idea of page names being "locations", which is how the software works. A title is a fixed location that a page is "moved" to. Changing to "rename" might solve some confusion, but it's only temporary confusion – any editor wanting to rename a page should understand the process and ramifications first, and that includes the verbiage, to a lesser extent. This is a well-intentioned proposal, but it will create a lot of work: requested moves becomes "requested renames", for example. Rename review (RRV?🚐) Page mover would need to be "Page renamer". If we went full-steam on this, it would result in confusion when looking at past discussions using different shortcuts and jargon. If we opt for a half-measure, it will cause immediate confusion, which is counterproductive. ASUKITE01:27, 21 June 2026 (UTC)[reply]
Oppose Moving can be far more complex than just renaming. On the other hand, renaming is technically a move so it would be better to call it that. Masem (t) 01:36, 21 June 2026 (UTC)[reply]
Support clearer for newcomers, consistent with virtually everything else within a computer system (we don’t move Word Documents, we rename them, as an example), and in the extremely rare cases where renaming a page is complex, it’s really only long-standing power users who are doing it, so it’s not like this will confuse them. TonyBallioni (talk) 02:48, 21 June 2026 (UTC)[reply]
Support per TonyBallioni. The work involved to implement this is a one-off task which is very well worth doing given the significant conceptual improvement that it provides to newcomers. MichaelMaggs (talk) 03:53, 21 June 2026 (UTC)[reply]
Weakoppose (was convinced by Godsy). When I first learned of moving I was also confused why it wasn't called renaming, as (it seemed) it was just changing the title. As I learned more I reconceptualized it as moving the page and its history to a new URL, which is why a copy-paste move is not equivalent. Like Asukite I find that more accurate to the way moving works, and don't think the transition cost is worth it anyway. Sophocrat (talk) (from an alternative account) 04:11, 21 June 2026 (UTC)[reply]
Comment: if this passes, there should be a full list of pages, categories, templates, and tools that need to be updated so we won't end up with inconsistent terms. Gonnym (talk) 04:24, 21 June 2026 (UTC)[reply]
Strong oppose - This would require a vast amount of change to the infrastructure surrounding page moves, which should not be understated. Many templates, categories, policy, guidelines, essays, and even a user right. Depending on the implementation, it might even affect userscripts and modules. Anyone wishing to go beyond a surface level understanding of a page 'rename' would have to understand the move concept to read any discussion about the topic that has taken place in the last 25 years. It also minimizes the concept of redirection; what is left behind during a move is extremely important. It will likely collide in spots with user renaming infrastructure. The benefit is purely semantical (and neither way of saying it is obscure or wrong); the burden on the community to implement this is extremely high. If one cannot come to an understanding regarding what is a page move, then they probably should not be moving a page anyhow. — Godsy (TALKCONT)04:49, 21 June 2026 (UTC)[reply]
It's just effort though. Compared to how much time people spent being confused, it probably pales to that. By this metric, almost anything that we want to change will become an unsurmountable mountain. Are we really letting a bit of effort block us from achieving relatively 'simple' changes ? That seems pretty defeatist to me. —TheDJ (talk • contribs) 14:48, 22 June 2026 (UTC)[reply]
Maltazarian expands on the matter well below. This is not 'a bit of effort' but rather a grand undertaking. That aside, how much 'confusion' move terminology may or may not cause is largely anecdotal (at least what has been presented so far). The squeaky wheel gets the grease anyhow; e.g. those who are new and understand the move system without issue are unlikely to show up at the teahouse and praise our process (and they could very well be in the vast majority). Who is to say this will actually move levels of confusion in any particular direction? Any change is 'just effort'; what needs to be determined is whether the effort is worth it. The bar for that has no where near been met in this case. I had a well-simmered retort to your defeatist accusation, but I am going to refrain as it would be unproductive. — Godsy (TALKCONT)01:24, 23 June 2026 (UTC)[reply]
Oppose. As others have noted, this is not just a matter of adjusting some guidelines, but would require an actual code rewrite of the Wikimedia software itself, because the tools and user rights use "move", not "rename", all to fix something which is not actually broken. And from my point of view, nothing is wrong with the "move" idiom. It isn't just changing the title of the page, it is moving the location of the page to a new URL. Sławomir Biały (talk) 08:17, 21 June 2026 (UTC)[reply]
I'm not sure I understand this. What software exactly needs rewriting? As people pointed out, Mediawiki internally still calls admins sysop and as someone who knows Mediawiki well, I say that we can do this without a single line of code change in Mediawiki. Of course, we can do clean ups later but they are nice-to-haves and not really required (as sysop vs admin). Even then, there is no need to rewrite anything. For example, MovePage class would need renaming but we (devs) rename classes all the time. Ladsgroupoverleg15:11, 21 June 2026 (UTC)[reply]
Oppose - while I understand the issues with newcomers (it certainly confused me early on), I frankly view it as an "if it ain't broke, don't fix it" situation. Firstly, on a technical basis, its more accurate, per above. Secondly, it would require an enormous amount of technical modifications that simply aren't worth it for what seems to be something that can be explained in under 30 seconds. A comment I would like to make however is that as a Wiki-archaeologist, I know that the term "syop" was used in Wikimedia software way back in the day, before eventually being moved to administrator. Did this require a massive technical change, or was it just softcoded in (i.e, were/are the terms syop and administrator harcoded or does Wikimedia code still uses "syop", but have the word administrator softcoded on top)? — Knightoftheswords10:49, 21 June 2026 (UTC)[reply]
i think but not 100% sure that the code technically still uses syop but it was changed on the user facing side to be administrator not sure how much technical changes were done to change the user facing name Isla🏳️⚧ 12:07, 21 June 2026 (UTC)[reply]
Would it convince you if I take responsibility for doing the work? let's say it's a lot of work both on-wiki and software, just drop it on me and I do it. If I miss anything, ping me or talk page message and I get to it.
Oppose at least for now. The suggested benefits do not seem to outweigh the amount of work that would be required, and the scope of that work isn't even entirely clear. I'm particularly not convinced by phab:T294188 as a "benefit"; if the people making UIs don't understand things well enough to choose a good icon, I think renaming the things is just hiding the real problem. Anomie⚔12:41, 21 June 2026 (UTC)[reply]
FWIW I originally suggested it on phab:T294188 as something that should be done because it is a frequent issue for translating from English to other languages (‘move’ isn’t a common word for the sense of renaming a page to a new location everywhere), so I don’t think it relates just to whether the icon for it is good or not. There are more benefits than that, so it’s not about ‘hiding’ that problem. stjn17:40, 22 June 2026 (UTC)[reply]
The title of phab:T294188 is literally The icon for "Move" is far from intuitive. It was brought up in the proposal here specifically in relation to the icon. Whatever other concerns you have with translations (and IMO those could probably be better solved by explaining in the qqq message than by hoping that one single word is always clearer than another one), it's not really on topic for that task. Anomie⚔23:26, 22 June 2026 (UTC)[reply]
Requiring every message related to moves to mention in its documentation that moves actually mean renames but enWP community is too anal about changing it because of hysterical raisins is a solution, but probably not the solution. Hopefully what we’ll end up on eventually is that enWP continues to call it moves (as it seems this is the emerging opinion) while the overall MediaWiki localisation switches to renames. Because at the end of the day the word rename is just objectively clearer than the word move because it has no semantic ambiguity, even if some languages might prefer to continue to translate its meaning as ‘move’ instead. stjn23:37, 22 June 2026 (UTC)[reply]
I suppose someone could be that petty. 🙄 Or we could use a much more useful qqq message. Personally, I hope what we end up with is dropping this suggestion based on a handful of people's assertions, rather than wasting a ton of time changing the name for what seems to be very hypothetical benefit. No matter how often you assert that "rename" is "objectively clearer" despite many others here finding it inaccurate for many types of moves. Anomie⚔23:45, 22 June 2026 (UTC)[reply]
It is objectively clearer for the purposes of localisation, which is what I was referring to. Your personal grudge against Amir (which on the substance I somewhat agree with, for the record, having called the thumbnail size diktat ‘the most destructive interface change in a long time’) doesn’t change the fact that having less semantic ambiguity is better for interface translation, and adding a template about it in every move-related message (it’s not like it’s just one of them, it’s probably at least a hundred) is a much more messy (and unfortunately forgettable) solution. Talk about being petty :-) stjn23:54, 22 June 2026 (UTC)[reply]
I suppose MediaWiki:Movepagetext actually needs to be rewritten to never use the word ‘rename’ there given what some people here seem to suggest in regards to cross-namespace renaming :-) stjn01:38, 23 June 2026 (UTC)[reply]
Oppose Title (Name) is under WP:TITLE, move is under WP:MOVE, they are subtly different inquiries: to paraphrase, one is, is this the best title (name) for this subject, the other is, should this subject be anywhere else but here. Or 'name' is substance, move is process.-- Alanscottwalker (talk) 12:59, 21 June 2026 (UTC)[reply]
Comment. Information on page names is under WP:PNAME. To summarize what one can read over there, a page name is often the same as the page's main title, but the page title is, well, a title. A page name is also often part of the URL, and encoding seems to make the distinction matter. To make matters worse, we have concepts of namespace, pagename, and fullpagename. Not sure I'd go so far as to say none of this is broken. We should try to accommodate feedback from our outreach team, and focus on documentation first. In my experience, users who need help find the "move" menu option might also need help was it renamed "rename".Selbstporträt (talk) 15:57, 21 June 2026 (UTC)[reply]
Oppose. As a frequent commenter at the Teahouse, it is true that this can be confusing for newcomers but this isn't just a simple matter of renaming this process. Some things are actually page moves(from one namespace to another) and not a rename, and this would create confusion on the other side. 331dot (talk) 15:42, 21 June 2026 (UTC)[reply]
Oppose Its not really a rename, although renaming the article that is part of the process. Per above, there is a movement process as its physical move within the db, so it wouldn't be accurate to rename it. A lot of these process name are well thought out back in the day and shouldn't be messed with. scope_creepTalk16:42, 21 June 2026 (UTC)[reply]
Moving a page is not like renaming a file on a computer, primarily because it leaves a redirect behind, which is another reason to keep using the term "move". For example, when you physically move to a new home, you usually can get your mail forwarded to your new address, much like how the old title redirects to the new title. SuperPianoMan9167 (talk) 14:17, 22 June 2026 (UTC)[reply]
Unless you as a renamer decide not to leave a redirect, or unless the content model disallows redirects (CSS, and sanitised CSS pages). This feels more like some pseudo-intellectualisation of what is actually happening. stjn17:42, 22 June 2026 (UTC)[reply]
Oppose, while I like the Idea and have to admit that the terminology confused me when I started as well - it would just plainly be false. According to my understanding, what happens on a technical level is much closer to a move than a rename, even if the result is basically that. In agreement with WP:SPADE I think it makes more sense to call the feature what it actually is, if it were just a rename, e.g. logs would not be affected, therefore I think even for newbies it would be better to call it move than to explain why the "rename" is more than just that, as a matter of fact I think it would be harder to understand some things such as automatic redirect creation and round-robin moves. Best, Squawk7700 (talk) 20:43, 21 June 2026 (UTC)[reply]
Oppose: Whilst I can sympathise that the term can be confusing for new editors, it is representative of the entire process, not just the aspect of renaming the article or page. The edit history is also moved in the case of drafts being moved into mainspace, with the same being true of the talk page and talk page history. It is a "move" in its entirety, not just a mechanism for renaming a page. 11WB (talk) 20:50, 21 June 2026 (UTC)[reply]
Conditional support if this happens the word 'move' should still be applied somewhere for cross-namespace changes. For example, Where currently on the move page you have (namespace) (name), you could separate these into two lines where the namespace is branded as "move to other namespace". This would also be a convenient place to add a warning that cross-namespace moves are even more drastic. If this is not possible for technical reasons or not supported then I oppose. JacobTheRox(talk | contributions)21:43, 21 June 2026 (UTC)[reply]
Since they're currently in the same mediawiki menu, if I understand it correctly would require a fundamental recode of the actual software + since this discussion can only create local consensus it would require the old menu to be preserved as well as an option for all the other wikis. In my opinion I would like to see that developer time rather spend on things that improve the editing experience in a more effective way. Best, Squawk7700 (talk) 21:54, 21 June 2026 (UTC)[reply]
Oppose per 331dot basically. It's interesting to note the choice made by other wikis: es.wiki and de.wiki basically use "Move/Transfer" but fr.wiki uses "Rename". Pichpich (talk) 23:36, 21 June 2026 (UTC)[reply]
Oppose Renaming is for users, and changes the username. Moving is for pages, and can change the namespace, the title, or both, in an effort to relocate the page to another location. I'm not really concerned by the amount of work here, so much as: what is the need here? The Phabricator discussion linked has some discussion about logos. Why do we need logos? Does Special:MovePage not sufficiently explain the action of moving a page? EggRoll97(talk) 04:34, 22 June 2026 (UTC)[reply]
Like 331, I'm not convinced that there's a need. There's a chance it might be changed if the string was truly better, but based on the high number of "oppose" !votes I don't think there's gonna be a change anytime soon. --ABx11 (she/they | formerly TheAuroraBorealis | In solidarity) 04:52, 22 June 2026 (UTC)[reply]
Strong support for moves within a single namespace. These are obviously renames in practice, and inertia is not a good reason to keep a name that's plainly bad. Neutral for moves between namespaces, as those actually are "moving" from one namespace to another. Loki (talk) 05:06, 22 June 2026 (UTC)[reply]
Support The UI should be clear for new users. In most other languages I'm aware of, this is already called rename ('hernoemen' in Dutch Wikipedia for instance). Changing the interface term is quite easy, and updating the help pages shouldn't be too much work. People working with new editors frequently have to explain how to rename articles and that's an unnecessary burden. Power users might disproportionaly have a bit of a tech background, but most new users do not and will be confused by this word. In solidarity, —Femke (talk) 🐦 10:58, 22 June 2026 (UTC)[reply]
Oppose for a few reasons.
The current level of confusion is that new editors have to say "ah, renaming is done by moving a page". I'm a relatively new editor and this is one of the least confusing parts of wikijargon. If we make this change we cause confusion due to old edit summaries and discussions using the term "Move" and the fact some moves are more than just renames, and if you say we should separate "Rename" and "Move" I certainly don't see how that would make new editors less confused.
We are not considering the other side of the translation coin. I feel it's likely that doing this will cause new translation issues.
You can change the bad icon without changing this.
Workload. How much? Unclear. There is no plan available here. Part of the workload will figuring out what the rest of the workload is. It is not just changing labels. We have to update (including a lot of moving, or renaming I suppose) templates, other pages, bots, scripts and do it in a smooth way to not screw up the workflow of WP:RM. Template:Old moves is a fun one. It's used on 35,000+ talk pages to show what a closer put down as the outcome of an RM discussion. Change the template, then the outcome parameter of the template doesn't make sense anymore, and if you change that then the stated outcome in the template doesn't match the stated outcome in the close, and if you change that you'd be changing another editor's signed talk page post, and you wouldn't be able to say "it's okay we're only changing the bolded outcomes" as those are usually written alongside closing rationales that often mention moving in some way.
It sounds less cool to say I'm a page renamer than to say I'm a page mover. Unserious objection, obviously.
Something I forgot to mention: editors used to the idea of a page being "moved" and titles actually being "locations" (which is actually a really good way of thinking about it) have to do a bunch of relearning. As someone who does a lot of page moving it's not going to fun to deal with the muscle memory and how natural it has become for me to refer to it as moves.
Also, it's perhaps worth considering that if an editor is so new that they don't know what moving a page means they likely should not be moving pages. Is it really a problem if a new editor with the idea to move a page has to ask how it works? Instead of potentially seeing "Rename", hitting it and boldly going forth without having read any guidance, they ask for help, get directed to read WP:MOVE, which has a part about whether or not it's okay to move a page placed before instructions on how to move a page. ⹃Maltazarianᚾparleyinvestigateᛅ14:30, 22 June 2026 (UTC)[reply]
Oppose because it's less technically accurate ("moving" is a better abstraction because changing a page title moves the page contents to another URL, leaving behind a redirect at the old title by default), will require a lot of work for very little benefit (every instance of, e.g. requested moves must be changed to something like "requested renaming"), and it introduces new potential for confusion with username changes. SuperPianoMan9167 (talk) 14:11, 22 June 2026 (UTC)[reply]
This is what I mean when I say that we would be creating a workload to figure out how much of a workload we are creating. It is very unclear just how much we need to do and I don't like blindly supporting an idea without knowing what it actually entails. ⹃Maltazarianᚾparleyinvestigateᛅ14:32, 22 June 2026 (UTC)[reply]
@Ladsgroup Is a mediawiki dev with a long history of contributing to the project, so I'm fairly sure he is aware of this and would be willing to help ease this through on the software side. Sohom (talk) 15:50, 22 June 2026 (UTC)[reply]
Kind of missing the forest for the trees here. The point is that there are all kinds of things that can cause issues and we don't know about them, let alone have plans to deal with them, yet we are going headfirst into this. ⹃Maltazarianᚾparleyinvestigateᛅ16:59, 22 June 2026 (UTC)[reply]
To tell the truth, given his record lately with other changes and ignoring or disregarding feedback, that makes me more wary of this proposed change rather than less. Anomie⚔23:32, 22 June 2026 (UTC)[reply]
oppose. I find the conceptual metaphor behind "moving" pages useful, even if technically under the hood "renaming" may be more precise. For example, the whole idea that when you "move" a page you then have a "redirect" from the old title to the new one – calling that a redirect (a thing that "directs" you to a different "place") is consistent with the metaphor that different titles are different "locations"; the old page still exists but it is no longer at the one "place" but at another – hence it has been "moved". That has always felt quite natural to me. (Of course I also agree with the argument of too much work for too little clearly defined gain). Fut.Perf.☼14:49, 22 June 2026 (UTC)[reply]
Oppose for two reasons. The first is a general "If it ain't broke, don't touch it." I have seen no indication that this is particularly confusing to people, at least not for long. However, the second reason is that touching it will break it, or at least make it less accurate. Renaming is one possible reason to use the move tool, but not the only one. If you move something from draft to mainspace (or vice versa), to userspace, etc., you are not just renaming it, you are moving it from one namespace to another, and that is a frequent use of the move tool as well. Calling it "rename" would obfuscate that use of it and not even accurately describe its function. SeraphimbladeTalk to me15:37, 22 June 2026 (UTC)[reply]
Support: I don't get the software argument. In the software, page titles aren't just pregenerated locations you can just fill in either. That implies a degree of specific object-oriented stuff that is simply not there. The article is not a property of some title object, the title is a field property of the article. Simple as that. For "moving" out of namespaces, I don't see an issue with making it clear that the move is technically just a rename. Just like how we call administrators "sysops", we can still refer to renaming with the "moving" metaphor in discussions. In solidarity, Aaron Liu (talk) 15:52, 22 June 2026 (UTC)[reply]
Just like how we call administrators "sysops", we can still refer to renaming with the "moving" metaphor in discussions. Then why not just refer to moving as renaming in discussions as is? SuperPianoMan9167 (talk) 15:56, 22 June 2026 (UTC)[reply]
Oppose. The term "move" is more transparent about what's taking place at a software level. Concepts like WP:ROUNDROBIN moves, the persistence of redirects after (most) moves, etc., make intuitive sense in a framework where pages are moved from one location to another, and much less sense in a framework where static pages are simply renamed. "Renaming" can be a useful shorthand for introducing the concept to users who are unfamiliar with the RM space and are looking to have simple moves pushed through, but making it the primary title for the process loses clarity in a way that I think will hurt as much as it helps. ModernDayTrilobite (talk • contribs) 19:06, 22 June 2026 (UTC)[reply]
Oppose. I see a lot of potential hassle for something of very dubious benefit. Could it have been named "rename" from the outset? Sure, and it would have been perfectly fine to do so, but it was named "move" instead, and I can't imagine anyone is really going to be that confused by it. –Deacon Vorbis (carbon • videos) 19:20, 22 June 2026 (UTC)[reply]
Oppose lots of moving/adjusting for no concrete benefit. Yes, some things on Wikipedia are not named completely intuitively, or delineated completely appropriately, or whatever. But has any newcomer editor really thought "I can't stand that they call this function moving!" and left the project? ~~ AirshipJungleman29 (talk) 19:59, 22 June 2026 (UTC)[reply]
Me, initially. The first time I wanted to edit Wikipedia I wanted to rename a page, spent an hour trying to figure out why I couldn’t edit the page title and “rename page on Wikipedia” wasn’t giving any hits, and eventually I got so fed up with the interface that I just gave up on editing for several years, since it seemed way too complicated. – Closed Limelike Curves (talk) 20:17, 22 June 2026 (UTC)[reply]
Just checked and WP:Moving a page shows up today, but under that name (with no mention of "renaming" whatsoever). I'm not sure if this is a change in Google's search algorithm or (more likely) some variant of confirmation bias/functional fixedness on my part. If you're used to a functionality being called "rename" everywhere else, it's very easy to skip right past the link labeled "moving a page" without stopping to realize "wait, that's logically equivalent to what I want to do".
Oppose per 331dot. I understand nom's argument, and while I agree with it, simply renaming the tool to rename doesn't make sense in the case of, say, draftification. You move a page throughout namespaces, not rename it.The confusion problem does exist though. Perhaps there could be a more simple tool for beginners? Some kind of wrapper of Special:Move. EatingCarBatteries(contribs | talk)22:43, 22 June 2026 (UTC)[reply]
Indeed, there should be barriers to actually carrying out a move. Making the policies and procedures easier to understand is another matter. —Myceteae🌈 (talk) 15:36, 23 June 2026 (UTC)[reply]
That's more or less my view but I am giving some weight to editors here who say they spend a lot of time at Teahouse or mentoring newbies, and that the terminology is a frequent source of confusion. It is surely true, in isolation, that learning what move means is not difficult, though this does not mean there is no benefit to simplifying our terminology. Taking a broader view, the totality of jargon and wiki-speak is a barrier even to editors with some experience under their belts, and any simplification may be beneficial. All that said, I'm not at full support, but I'm not sure I have a good reason for it. —Myceteae🌈 (talk) 17:07, 23 June 2026 (UTC)[reply]
I agree that the totality of wikijargon is a barrier, but, as I said in my main reply, as someone who has relatively recently had to learn wikijargon I feel this was one of the least confusing parts, and one that arguably makes a lot of sense being called what it is. I think focus should instead be directed at cutting down on the wikijargon that that can't be said for, and primarily on aspects of it that act as barriers to activities that we would like new editors to easily and intuitively jump into without having to consult more experienced editors. ⹃Maltazarianᚾparleyinvestigateᛅ17:33, 23 June 2026 (UTC)[reply]
Oppose (conditional): Within same namespace, changing to "Rename" is OK. But don't change it if it can't be done while keeping "Move" for across namespaces (which I guess is mostly just for drafts -> main; P.S. - I'm interested if anyone knows other use cases for cross namespace moves). This must be how Ken Thompson and Dennis Ritchie felt about introducing mv to Unix. cases. Good points made by I agree with JacobTheRox(talk | contributions), Loki (talk), & Maltazarianᚾparley\/investigateᛅ.Theo wiki user (talk) 01:00, 23 June 2026 (UTC)[reply]
Common cross-namsepace moves include: User → most others (userspace drafts of article content, templates, project pages, etc), Main → user/draft (draftification) and Wikipedia → Main (fixing a common mistake when attempting to publish a draft is to move it to the Wikipedia namespace instead, although this is less common now than it used to be). Wikipedia ↔ Help (reorganisation, etc) is less common but isn't too infrequent, obviously mistaken moves to and creations in can apply to almost any pair of namespaces; before draftspace existed drafts were written in the Wikipedia talk: namespace and then moved to main when expected. Obviously in all cases talk pages get moved to the corresponding talk namespace alongside the content pages. Thryduulf (talk) 01:19, 23 June 2026 (UTC)[reply]
Strongly support renaming intra-namespace moves to renames since it is the more appropriate term. weakly support namespace to namespace moves, if it is not technically possible to distinguish these moves to intra-namespace renames.FoxOutOfRange07:15, 23 June 2026 (UTC)[reply]
Also, I do not think the fact that it isn't broken does not mean that we shouldn't improve on things. If that was the argument for all possible improvements to the wiki then we would not get anything done except reacting to issues, and being reactive rather than proactive is a bad thing... FoxOutOfRange07:20, 23 June 2026 (UTC)[reply]
Support, changing it would make it more intuitive and demystify the editor experience for new editors. Overall it would streamline things and help reduce the pressure that too much jargon could create. Atakes Ris (talk) 10:01, 23 June 2026 (UTC)[reply]
Comment. The current name is technically more correct but it is true that it confuses some people. I see that we have tried to ensure that people mistakenly looking at the wrong guides (e.g. WP:RENAME) are pointed towards the correct ones (e.g. WP:MOVE) but I wonder if there is more we can do to avoid confusion e.g. having a template for a little banner that explains the terminology in one or two simple sentences and links to the correct guide. That said, I also wonder whether inexperienced editors should be encouraged to do their own moves anyway. It's quite easy to do it wrong and make a mess. It is something I occaisionally see people asking for help with because they either did it wrong, and aren't sure how to fix it without making it worse, or they are just not sure whether they did it right. --DanielRigal (talk) 10:39, 23 June 2026 (UTC)[reply]
(edit conflict) Oppose. Having read all of the above, I'm convinced that this will cause a very significant amount of disruption for only a very small benefit at most (and is actually more likely to be overall neutral). Insead, improving the documentation, inclduing making it clear that renaming is carried out by moving, will unquestionably achieve the desired goals without causing any disruption and will almost certainly bring additional benefits too. Changes to documentation (in some cases greater changes) would be needed if we carried out this proposal anyway, so the effort to do this is required either way. Finally, moving or renaming pages is inherently disruptive in almost all cases, when done properly this disruption is vastly outweighed by the benefits of the move but when done incorrectly it's a net negative. For this reason we want there to be a small barrier to moving/renaming so that new editors acting in good faith but unaware of policies, guidlines and conventions don't unintentionally cause disruption by unnecessarily and/or incorrectly renaming a page. There being no prominent "rename" button but requiring people to search for how to achieve it provides this small barrier and gives us a chance to educate them before they accidentally cause disruption - assuming they can find the documentation, which will be an issue whatever it's called (and where improving it comes in). An editor causing disruption, regardless of their intent, is far more likely to be driven away from the project as a consequence than editors who can't figure out how to rename a page, can't find our documentation and choose not to ask. Thryduulf (talk) 10:48, 23 June 2026 (UTC)[reply]
Support. There is, as far as I can think of, any reason to not use self-explanatory terminology where possibe. Article moving is often, but not always, renaming. I believe the actions other than renaming should continue under "move", but the tools use for renaming and the associated rules for such use should be called "renaming". Finfixer (talk) 14:49, 23 June 2026 (UTC)[reply]
neutral To me the two terms are synonyms, i don't think it really matters. I find all but the first bullet point of the why section uncompelling. Move is common computer terminology for this operation (e.g. Unix mv command). Arguably move does have connotations of a file system metaphor, which isn't really the metaphor we use on wiki. I don't think how other languages translate the term should have any bearing on what the english translation is. Translation is never a 1:1 mapping. And last of all, people choosing a bad icon has nothing to do with what the action is literally called. Icon choice should follow semantic meaning. If someone choses an icon based on looking up the word in the dictionary and then choosing the wrong sense of the word, that is on them. Bawolff (talk) 15:09, 23 June 2026 (UTC)[reply]
Oppose While there's nothing wrong with the idea of using "rename" to refer to this process, I don't see "move" as wrong either. It's likely that making this change would create more confusion, not less. 162 etc. (talk) 15:17, 23 June 2026 (UTC)[reply]
Oppose. "Rename" is, in my estimation, inaccurate; even within a namespace, we really are moving the pages to a new location, not simply renaming them. This is illustrated in the manual histmerge process; if we delete a page at one title and then move/rename another title on top of it, the previous page's edit history is still there, and if that's all undeleted, then the edit history of the previous page will be mixed into the edit history of the new page. To me, the analogy of the new title being a "place" where we are moving an edit history is much clearer; if it were "renaming", my intuition would be that the edit histories would stay separate, that the pages are still separate, and simply now have the same name. Writ Keeper⚇♔15:14, 23 June 2026 (UTC)[reply]
Strong support – As an ex-newbie myself, calling what we do "moving" a page is ridiculous. We literally just rename it. It is so simple and not even that inaccurate. You can say a page was renamed to a new title, and the page history of the old title is now the history of the new title. Ridiculous. FaviFake (talk) 19:44, 23 June 2026 (UTC)[reply]
Can we please require a space after a URL in a template parameter?
Copied from WP:VPT, as I am told this is not a technical question. I work with reference templates quite a lot, and in quick succession, and it is a minor but persistent annoyance to me that sometimes it is not easy to see exactly where a URL ends and the next parameter begins because there is no space before the next pipe. I think it would be trivially easy to have a rule that a URL in a template with parameters separated by pipes should have a space before the pipe, and have a bot go around and add those spaces. Another editor suggested there that it would be good to have a space before all pipes, which I would agree with as well. BD2412T21:47, 21 June 2026 (UTC)[reply]
Support both space between url and pipe, and space before all pipes in these templates (reader, I am that other editor). I believe, as an editor who does a lot of fixing other people's citation errors, that these changes would tend both to make error detection easier, but also to make it harder to make the error in the first place. Both of these are highly desirable results. DuncanHill (talk) 21:52, 21 June 2026 (UTC)[reply]
If an editor uses citer.toolforge.org, it includes spaces before the pipes. How do other cite formatting tools that people use behave? Schazjmd(talk)23:27, 21 June 2026 (UTC)[reply]
Support although I don't mind too much either way (I already format my references with a space before pipes but not after them). It doesn't seem particularly disruptive, so if it helps other editors with their editing I'm alright with it, and I'm fairly sure it would be relatively simple to have a bot go around fixing references to follow this format. Also, if we're going to require a space between the end of a URL and a pipe we should also be requiring it before all pipes as it would just make references look goofy to insist on doing it for just one parameter. ⹃Maltazarianᚾparleyinvestigateᛅ12:23, 22 June 2026 (UTC)[reply]
To be clear I would still support the proposal even if it only applies for the URL parameter for the same reasons as I would otherwise (other editors say it would help them edit so let's do it). ⹃Maltazarianᚾparleyinvestigateᛅ15:15, 23 June 2026 (UTC)[reply]
Agree with the rationale and support a general presumption that spaces before pipes are helpful to editors, and support including the addition of spaces as part of editing tool processes. (A bot running around fixing only this may run into WP:COSMETICBOT concerns, but rolling it into other tools should shift this over time.) CMD (talk) 12:40, 22 June 2026 (UTC)[reply]
Support This is an absolute minimum if you want the markup to be editor friendly. I find that white space makes editing easier. My preference is one parameter per line, aligned, but even adding one space is an improvement. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:26, 23 June 2026 (UTC)[reply]
Oppose per WP:CITEVAR. If an editor prefers an article's citation templates to be formatted more tightly (for instance because it makes it easier to skip past citations when reading article source text) then we should respect that preference. Also because imposing extra formatting requirements on citations makes human editing much more difficult and imposes unnecessary bot churn and watchlist clutter, for something that is totally unnecessary. —David Eppstein (talk) 18:44, 23 June 2026 (UTC)[reply]
Strong oppose to "spaces before all pipes". This would mean lots of linebreaks within the otherwise nice and uncluttered {{sfn}}'s. I can't see any advantage to enforcing this for templates used within the main text. —Kusma (talk) 18:48, 23 June 2026 (UTC)[reply]
{{ill}} is another example where added whitespace would decrease readability instead of increasing it. Not all templates are the same. —Kusma (talk) 18:59, 23 June 2026 (UTC)[reply]
I read several of the replies as applying this to all pipes in all templates. Anyway, I generally oppose us having guidelines for how to use whitespace in wikitext; while certainly my indentation style and date formatting choices are superior to those of other editors, the spirit of WP:ENGVAR and WP:CITEVAR seems much more helpful to editors to me than bot-enforced uniformity. If bots enforce a particular style, it should be my style. —Kusma (talk) 19:27, 23 June 2026 (UTC)[reply]
Looking back at it I suppose I have to agree it is ambiguous. I certainly did not intend to suggest it must apply to all templates. I meant that if we apply it to the URL parameter of a template then we should also apply it to the rest of the parameters of that template.
As for the spirit of ENGVAR and CITEVAR: I prefer having consistency over trying to adapt to each articles own little idiosyncrasies in situations where it is feasible to do so (uniform spelling is out of the picture, for example). ⹃Maltazarianᚾparleyinvestigateᛅ20:12, 23 June 2026 (UTC)[reply]
Support This is what I am currently doing when I manually create or edit full citations. And, @Kusma:, I interpret this as applying to full citations, not to sfns. Donald Albury19:02, 23 June 2026 (UTC)[reply]
The manual of style is not a personal preference, nor does it deal with the presentation of things that have exactly zero impact on the reader. Thryduulf (talk) 20:51, 23 June 2026 (UTC)[reply]
Support – Nominator makes a good point, I myself hate having to identify where the next parameter begins. Of course, if this passes, I very strongly support this rule being enforced by a bot, otherwise it would just become a silly suggestion for the few editors who will know about it. Simple solution to a simple problem. FaviFake (talk) 19:52, 23 June 2026 (UTC)[reply]
A bot editing six million Wikipedia articles to make changes that do not affect the HTML output is not a "simple solution" to the problem that the OP is sometimes confused while reading wikitext. —Kusma (talk) 20:02, 23 June 2026 (UTC)[reply]
It's entirely a personal preference. Some people find spaces more readable, some people find compact code more readable, some people just don't care. Neither is more objective than the other. We don't enforce a consensus for single or double spaces after full stops because it is a personal preference that makes exactly zero difference to readers. Thryduulf (talk) 20:54, 23 June 2026 (UTC)[reply]
Idea lab
Too many vague edit summaries when creating redirects
This is a problem caused by some people who don't know about WP:AES and think they always need to type something in the edit summary box. If you check the list of recently created redirects you will basically always see summaries like "Redirect." or "Created redirect" or something just as unhelpful that goes against WP:SUMMARYNO. On the other hand, if these editors just left the summary blank then an automatic summary would have been generated which includes the target. You can see how bad this can get with something like this where checking which of these redirects fails WP:FORRED is probably 10 times slower that what it could have been. I proposed an edit filter to fix this in EFR but they sent me here. So, how do we fix this? How can we make it so we can always tell what the target of a redirect is by looking at the edit summary? Warudo (talk) 17:19, 30 May 2026 (UTC)[reply]
When I create redirects I usually state the reason for creation rather than the target as that's what I find helpful at RfD where I already know the target. I can see why you would find the target useful in the creation summary though. My first thought as to a solution is for the software to append the redirect target as/in a manner similar to a tag. I haven't a clue how easy that would be to program though. I agree though that an edit filter prohibiting summaries that don't include the target isn't the right solution. Thryduulf (talk) 17:51, 30 May 2026 (UTC)[reply]
It depends on the kind of redirect. If it's a {{R from short name}} like Special:Permalink/1339839836 or a {{R to disambiguation page}} like Special:Permalink/1339428536 then it is helpful. But if it is a {{R from alternative language}} like the examples above then just saying for example "Created redirect to subject's name in Hebrew" is less helpful than "Redirected page to [name of subject]" because I can already see the name is in Hebrew but I can't read it to see if it's obviously a valid FORRED or if I need to look at the target article to find affinity.
Also, while not including the target can sometimes create problems, there's no harm from including the target every time. Special:Permalink/1339839836's sumamry could just as easily have been "new redirect form a short name of Horatio Arthur Yorke". So, even though I understand that my original proposal seems draconian, I don't see why it's not the right solution or why an edit filter "would end up being disruptive" as User:Daniel Quinlan asserted without any explanation. Warudo (talk) 18:25, 30 May 2026 (UTC)[reply]
But more importantly that all of that, getting the developers to fix this in the software level, while it is almost certainly the best solution, is going to be much slower than simply making an edit filter and that's assuming they will get to it eventually. Alternatively, we can make the filter now, ask the developers to fix the issue on phabricator and disable the filter after they do. Warudo (talk) 18:44, 30 May 2026 (UTC)[reply]
Filters interrupt the editing workflow so they should generally be reserved for more serious issues, not constructive good-faith edits. Given a notification after attempting to save their edit, many users will simply abandon the edit, or make an incorrect WP:EFFPR report that someone will have to handle, rather than read the notification and fix their edit. The right place to address this is in the editor (perhaps as part of Wikipedia:Edit check), but it needs careful design and testing to avoid similar downsides, which is why I suggested VPI rather than a direct feature request. Daniel Quinlan (talk) 19:52, 30 May 2026 (UTC)[reply]
All I can say to that is WP:CIR. If editors choose to abandon an edit instead of fixing an easily fixable problem with it because they can't or refuse to read an error message, that's on them. Warudo (talk) 20:29, 30 May 2026 (UTC)[reply]
That's a very ableist (for want of a better term) view. Error messages are scary and unless very carefully written often hard to interpret for those who don't already know what they need to do. What is trivial for very experienced editors like you are I is absolutely not for the majority of contributors. Every barrier to making an edit decreases the likelihood of the edit being completed (WhatamIdoing has stats on this I believe), so minimising barriers is important and intentional ones should be reserved for actual problems not just nice to haves. Thryduulf (talk) 20:43, 30 May 2026 (UTC)[reply]
But what about the user experience of the rest of us? Editors who do this make the interface more difficult for us to use by obscuring information. I don't think I have much more to say because having a conversation is much harder after the -isms start flying around, but why are we only focusing on the UX of people who can't or won't follow instructions? Warudo (talk) 21:00, 30 May 2026 (UTC)[reply]
I guess I am guilty of this since my last redirect creations were with the summary "Create", "create", "Create redirect", and "create redirect". Preventing constructive edits from happening because they don't have an edit summary never happens and would end up being disruptive. think they always need to type something in the edit summary box I have a preference checked that literally makes me verify that I meant to submit an edit with no edit summary. It is manifestly more difficult for me to edit if I do not submit an edit summary. I just tried to make a redirect with no edit summary and it stopped me from doing so. 1brianm7 (talk) 18:51, 30 May 2026 (UTC)[reply]
I have a preference checked that literally makes me verify that I meant to submit an edit with no edit summary that is actually disabled when creating redirects because the automatic summary is good enough (unless you use the 2017 editor). This is actually the reason I stopped using the 2017 editor because I also have this setting enabled. Warudo (talk) 18:58, 30 May 2026 (UTC)[reply]
Well, I am using the 2017 editor, so I guess that's why it happened. I have created 11 redirects in 2026, which really isn't enough to justify moving to a worse editor. 1brianm7 (talk) 21:04, 30 May 2026 (UTC)[reply]
... but teacher has always said to never leave a blank edit summary! I too have a user script that alerts me to a blank summary. If there is an automatic feature that is designed to make a better edit summary, then the edit summary box should clearly and dramatically indicate this. Not sure how that would work technically, but the edit UI needs to be very clear when/if a blank summary is encouraged — GhostInTheMachinetalk to me11:03, 21 June 2026 (UTC)[reply]
My practice varies. I typically leave the edit summary blank when I think the basis for creating the redirect is likely to be obvious or uncontroversial. Otherwise I will typically provide a brief explanation or rationale in my edit summary, like Thryduulf. I would have told you I usually include the target when I write my own edit summary but in looking at my history, I see I often omit this. I agree it's helpful when the target is included in the edit summary for the redirect creation (and every subsequent retargeting). At RfD and when assessing redirects on my own, I find the history of prior targets and the explanations are both helpful. For most redirects it may not make a huge difference but for those that have more than a few edits, it is helpful to be able to quickly see when, where, and why the redirect was targeted without having to click through each revision. If the target can automatically be appended for redirect creation (and retargeting?) without erasing the editor's own edit summary, that would be great. But I wouldn't want to lose the ability to add my own edit summary. I'm have no idea what the technical implementation would look like nor have I thought through all the implications of a mass, automated process. As an aside, I will try to remember to include the target when creating my own redirects. —Myceteae🍄🟫 (talk) 18:55, 30 May 2026 (UTC)[reply]
I don't understand the problem. When I look at that list of contributions that you linked, I just hover over the redirect title and the popup shows me the article it targets. (I think that's from Wikipedia:Tools/Navigation popups.) That seems just as effective as having the target in an edit summary. Schazjmd(talk)21:04, 30 May 2026 (UTC)[reply]
Oh sorry, my bad. I enabled page previews but not navigation popups in my testing. When I enabled the gadget it also worked in those pages. Still, a gadget that is not enabled by default is hardly a solution. I'm not looking to just solve the issue for myself here. Warudo (talk) 21:35, 30 May 2026 (UTC)[reply]
It sounds like the issue is being able to see the redirect target without opening the page; nav popups helps with that. I don't think it's very likely that the community will approve an edit filter or any other means of enforcing a specific type of edit summary. It is not burdensome to enable the gadget. Schazjmd(talk)21:40, 30 May 2026 (UTC)[reply]
The issue is being able to see the redirect target without opening the page at a glance. The gadget still takes time to use because you have to hover over the link. More importantly vague summaries go against WP:SUMMARYNO so there is still an issue to solve here. Warudo (talk) 21:45, 30 May 2026 (UTC)[reply]
"a gadget that is not enabled by default is hardly a solution", if the scenario is one that ordinary editors encounter. A gadget that is very widely used by the tiny fraction of experienced editors who do this kind of work is an acceptable solution. It sounds like this is a problem that can be solved via documentation. The FAQ might look like this:
Q: If someone doesn't link the redirect in an edit summary, then I have to actually look at the page. This wastes my time.
I'm guilty of this also. Looking at my last 44 redirect creations (which date back to 2018, which I suppose is when the tags started getting added):
17 of them have an edit summary consisting solely of "created redirect"
1 was essentially "created redirect" along with some thoughts about undeleting the history of a deleted article that was under the redirect.
19 of them were page moves and have the automatic summary generated with a page move, often along with some additional detail.
The remaining ones generally seem to give some reason why I felt the redirect was appropriate, such as,
Redirect from typo.
Make it easier for people who can't remember the word.
created redirect from a NN company to its notable founder
created redirect from one island that does not have an article to the article on the chain of islands of which it is the largest.
created redirect for anyone looking for information on her
Department of university
I did not include the target in any of the ones that weren't a result of page moves. Would it be helpful to include the target? Which would be more helpful, the target, the reason, or both? ~ ONUnicorn(Talk|Contribs)problem solving22:05, 3 June 2026 (UTC)[reply]
Adding the target could be very useful if the software changes aren't too onerous. It could be prepended to the manual edit summary, rather like a section link often is when we edit a section of a normal page. Of course, the section header is added by seeding the edit summary box, which wouldn't work here because that appears before we reveal the target (or even that the page will be a redirect). Certes (talk) 22:27, 3 June 2026 (UTC)[reply]
Is there any indication of what the default edit summary would be if left blank? I don't think I've ever created a redirect, and if I didn't know for sure that an automatic one would be created, I almost certainly would never have thought to leave it blank. If there were some kind of preview of what the automatic summary will generate, or perhaps a button to fill in the summary with a generated version with the necessary details, it would prevent me from writing a less helpful version. I'm not sure what's possible there from a technical perspective though. I'd imagine any time an edit summary is generated (are there other cases?) it should be displayed to the user before they submit, otherwise it's always going to feel like a gamble. dylansan (talk) 19:23, 4 June 2026 (UTC)[reply]
Good point. It was certainly a surprise the first time I created a redirect forgetting to add an edit summary and found that I'd written an essay. I assumed that I'd accidentally pasted the page text into the edit summary box (and felt relieved that nothing confidential or embarrassing had been in my clipboard). More people might use this feature if it were discoverable. Certes (talk) 19:56, 4 June 2026 (UTC)[reply]
Thank you. I'm glad it's documented. I do think it's not enough to be documented somewhere. I think most users are going to be unaware of this unless it happens by mistake. An indication while making the edit would be more helpful. dylansan (talk) 21:02, 4 June 2026 (UTC)[reply]
Yeah, this is a good point. Editors rightfully have it in their head that they should always leave an edit summary and to keep it short and as others have noted some get an alert when they don't enter something, and that alert apparently doesn't account for edits that will generate one automatically when left blank. —Myceteae🌈 (talk) 20:08, 4 June 2026 (UTC)[reply]
@Ahecht Thank you! I tested your script and it is very helpful. However, a problem I found is it only has access to the current target of the redirect. So, when a redirect is created targeting A and is later retargeted to B, your script will have "new redirect to B" next to the first edit, which is misleading example (4th entry). The phrasing needs some tweaking to reflect that what is shown is the current target, not what the target right after the edit. Warudo (talk) 17:27, 16 June 2026 (UTC)[reply]
@Warudo Yeah, I just discovered that too. I started a draft of a version that might work for old revisions at User:Ahecht/sandbox/Scripts/RedirectTagID.js, but it's not very straightforward to get the edit time from the contributions page. The same limitation applies to using popups, as suggested above, but I still changed the output to say "New redirect (currently to Foo)" --Ahecht (TALK PAGE)17:36, 16 June 2026 (UTC)[reply]
@Ahecht That fixed the problem but it also made the tool more unreliable. I haven't run across API rate limits yet but when I check my own redirects a bunch of pages don't have a listed redirect and I see logs like "RedirectTagID: Invalid value "2026-06-1T14:16:00Z" for timestamp parameter "rvstart"." in the console. Warudo (talk) 22:06, 16 June 2026 (UTC)[reply]
I think the redirects where the tool fails are the ones that were created in the first 9 days of any month. The tool seems to handle days with 1 digit incorrectly. Warudo (talk) 22:10, 16 June 2026 (UTC)[reply]
@Warudo Should be working now. The only ones in your contributions that it fails on are cases where the redirect was malformed (e.g. return [[Module:Sandbox]], #REDIRECT [[Hololive Production#Holostars English]\n, or #REDIRECTG [[Template:Di-no_source-notice]]). --Ahecht (TALK PAGE)23:19, 16 June 2026 (UTC)[reply]
@Ahecht The script also fails if an rcat appears right after the redirect markup, as in #REDIRECT [[Dmitry Ioffe]]{{R to transliteration|he}} from דמיטרי יופהדמיטרי יופה which, along with some other such redirects (see console) appears in [21]. Warudo (talk) 12:18, 22 June 2026 (UTC)[reply]
The issue isn't the rcat being right after the redirect. The issue is that the first edit to that page was just {{R to transliteration|he}} without the redirect code, and the edit adding the redirect occurred within the same minute. Since the contribution page doesn't include seconds, there's no way for the script to tell which edit is being referred to.
@Warudo Actually, I figured out a way around it by grabbing the revid on RecentChanges as well. It should work now in almost every case except if the page was moved and then recreated after the redirect was created. --Ahecht (TALK PAGE)16:42, 22 June 2026 (UTC)[reply]
I've created phab:T428112 with the initial goal of getting an understanding of whether something like a tag or appending the target to the edit summary is at all practical (and if so which). Knowing that will be very useful in focusing this discussion and there are too many unknowns at present. Thryduulf (talk) 00:09, 4 June 2026 (UTC)[reply]
I can't be the only one who is prone to typos and other errors in edit summaries, as in this example where I tried to be helpful by providing both the redirect target and the reasoning. Just adding this to the list of reasons why it would be helpful if the tags for redirect creation and retargeting automatically specified the target(s) regardless of what the editor puts in the edit summary. —Myceteae🌈 (talk) 20:16, 10 June 2026 (UTC)[reply]
Problem with newcomers leaving Wikipedia
Sorry, if this is not the right place to ask this. This is not an idea (but it may lead into one). In Polish Wikipedia we have a project led by Wikimedia Polska called WP:NOWI (nowi in Polish means new, but in a form that implies people) where we're working on increasing retention of Wikipedia users. We can share what we did and what the effect was when the project ends if someone is interested.
My question is if this is not a problem in English Wikipedia and what you do to make more newcomers stay?
We've noticed that some users don't contact their mentors when their article is reverted. We assume that they didn't know why and just left the project. The same happened when the article was proposed for deletion (in PL called DNU) and the person didn't contact their mentor. Those are our hypotheses. If someone is interested, my analysis in Jupyter Notebook is on my GitHub [22] (sorry, the comments and README are in Polish).
This is a major problem on enwiki. In my personal opinion, it's among the biggest problems we face. Mentorship especially doesn't seem to have much effect. I currently have about 800 mentees assigned to me, I get about one question every few days, and none of my mentees have reached an edit count of 500. Thebiguglyalien (talk) 21:36, 3 June 2026 (UTC)[reply]
Given that the number of editors who reach 100 edits is quite small (according to Wikipedia:Wikipedians, about top 1% of all users, top 2.5% of users who've made at least one edit), I didn't expect the mentorship program to have a huge effect, though I hoped it would have a small one. For reference, the number of editors who reach 500 edits is about top 0.25% of all users, and top 0.75% of users who've made at least one edit. isaacl (talk) 02:02, 4 June 2026 (UTC)[reply]
I think it does have a small one, but my impression is that the vast majority of new account creations aren't created with "I want to be a Wikipedian" in mind. Those I see on my talkpage usually make one comment and then disappears, but not all. Many newbies want to do something they probably can't, COI-thing or whatever, and when they learn that, they bugger off. Gråbergs Gråa Sång (talk) 03:54, 4 June 2026 (UTC)[reply]
The idea many people decide one day that "I want to be a Wikipedian" seems a bit silly to me. That is something that people might decide after getting a taste of working on Wikipedia. GeogSage (⚔Chat?⚔) 04:23, 4 June 2026 (UTC)[reply]
It took me 7 years to start making passable edits! There are definitely some of us who did not know how Wikipedia was actually going to go for them. Momonowa (talk) 15:52, 15 June 2026 (UTC)[reply]
I personally made my account to correct a typo here and there when reading Wikipedia. It took 3 years before I dived in deeper and became a daily-editing "Wikipedian" Athanelar (talk) 06:29, 16 June 2026 (UTC)[reply]
There are some major issues with retention for sure, but I think solutions fail to grasp how the majority of people end up being editors, and how Wikipedia policy gets in the way of that. Most people don't decide one day to start editing Wikipedia as a hobby, they have a goal in mind or want to fix some small mistake/omission.
For example, Wikipedia:Conflict of interest means we often discourage people who are most interested/knowledgeable in a topic from editing it. While this is often for good reason as it could otherwise be promotional, most cases of COI I've seen have been from people who were very obviously new editors and therefore very sloppy. Rather then trying to salvage their work and gently nudge it into compliance (if possible), COI slams them. If you look at the page for COI, it states COI is a problem because:
On Wikipedia, editors with a conflict of interest who unilaterally add material tend to violate Wikipedia's content and behavioral policies and guidelines. The content they add is typically unsourced or poorly sourced and often violates the neutral point of view policy by being promotional and omitting negative information. They may edit war to retain content that serves their external interest. They may overuse primary sources or non-independent sources, and they may give too much weight to certain ideas.
I propose this isn't necessarily because of COI, but because these editors are new. I got accused of COI on one of my early articles for a person I've never met (at the time, I was going through the textbooks on my shelf and trying to make pages for authors who appeared more then once in my collection), mostly for including stuff that wasn't necessarily noteworthy or standard on other bios (in hindsight, with more then 12000 edits, partly because the other editors were not very nice). Wikipedia policy, MOS, and the grey area where certain things are unwritten standards is hard to learn. The bait that could draw many new editors, making or expanding an article for someone or something they are connected to, ends up biting them and framing their early edits as bad because of COI, not because they are new editors learning the process. People don't want to necessarily start out on articles they have no "interest" in, but maybe after working on such an article, they would decide to stick around. I point this out partly because the COI policy seems to be counter to WP:OUTING policy (demanding people declare a COI very well could put them in the awkward position of needing to choose between lying, and outing themselves), which is much more important in my opinion.
Other issues pertain to the general culture around Wikipedia. For example, people who are used to spending time on Reddit might not realize until it is to late that common internet behavior/language is frowned upon or even blockable on Wikipedia. While the rules around civility are certainly important, the policies and rules (as well as how they are enforced) are very White, western, and neurotypical, and force conversation to be more like a BBQ with the HR department or a white collar company then how researchers organically collaborate IRL. Even if new editors aren't blocked/banned, the gamification of these rules can leave a bad taste in their mouth and cause them to leave. GeogSage (⚔Chat?⚔) 03:49, 4 June 2026 (UTC)[reply]
When mentees ask me about creating articles, especially if COI seems likely, I always add an if about COI (and explain it in plain English instead of using acronyms like COI). There's also been an occasion or two where they seemed competent enough that I mentioned they might consider editing as a hobby. I doubt they'll take me up on it, but it might be a numbers game. And to your other point, we really need to enforce WP:BITE very strictly. However much we endorse WP:CIVIL, WP:BITE needs to be a few degrees higher. Thebiguglyalien (talk) 17:53, 4 June 2026 (UTC)[reply]
I agree, bite needs to be more seriously considered. I've tried taking a "blunt" approach when I see a new editor making a mess if they push back, but this is mostly because experience says if I don't broadside right away the discussion gets out of hand. Essentially: "You're edits are not appropriate because _________. I suggest you read ____ before making changes." I believe we are too quick to apply penaltlies though, and that we probably need to be a bit more adult when it comes to dealing with difficult personalities in general. GeogSage (⚔Chat?⚔) 22:16, 5 June 2026 (UTC)[reply]
A lot of people will turn up at Wikipedia because they know something about a subject, and spot an error. This is a good entry-route, but can lead to bruising interactions with other editors. We need to be careful about accusing people of conflicts of interest merely because they are experts. WP:EXPERT is more applicable than WP:COI but both are sometimes brandished thoughtlessly. EXPERT also doesn't match the reality of articles on specialist technical subjects. We need to avoid throwing acronyms at new editors because it makes it look as though we care more about wikilawyering than making the encyclopedia good ("Ha! You may know about photosynthesis, but what do you know about WP:XYZ?? Back off newbie! I have wikiknowledge of which you can only dream..."). In the coming few years, we'll need to be careful about accusing newcomers of AI: it's increasingly difficult to tell the difference a human imitating AI and AI imitating humans.
Another very off-putting problem is gatekeeping: it's all too common for an editor's first efforts to be reverted with a rather patronising comment that the new editor is new, and therefore doesn't know what they're doing; the current version of the article has been stable for 10 years, and therefore all change is wrong. In fact, of course, the current article has been stable for 10 years because its creator has politely bludgeoned into submission anyone who attempted to change it. The determined newbie editor will come back and say that contrary to the accusation, they actually do know about the subject. Their further efforts are then reverted again, this time with a link to WP:EXPERT, and a comment that whatever they know to be Right is Wrong because it's merely what they Know. You either know too little, or too much... So they come back a third time, this time citing good secondary review articles, and it gets reverted again, on the grounds that (a) the review articles are irrelevant because they discuss a subtly different concept to the exact subject matter of the article, and (b) with a polite suggestion that the newbie editor is unqualified to edit the article because they show bias by using reviews of which they are aware (and that might have been written by someone with whom they are acquainted). At this point, the average newbie will decide that Wikipedia articles are vanity-items for their creators, and the whole thing is a waste of time. Elemimele (talk) 16:57, 9 June 2026 (UTC)[reply]
Showing no evidence for this and with the understanding that it may have been hashed out to death in the past, my impression is that there are a few trends in the project that gradually increase friction for newcomers by making it more difficult to make substantial edits that stay sustained in the article. Without edits that are sustained, newcomers lose the important sense of self-efficacy (that they can translate free time spent editing to impact on an article) and then they quit.
Examples of these trends:
1. Instruction creep: More policies, a bigger precedent body, and a more mature editor culture (in terms of unwritten rules, etiquette, etc.) means that the skill floor needed to make a substantial edit stay sustained gradually increases.
2. Less collaborative editor culture: In a normal organization where employees can't easily leave their job, less collaborative, tenacious people can and do get pushback for not being good team players. On wikipedia, the job is free time. That means that it's easier to quit than to push back on an un-collaborative person. The result is that on Wikipedia specifically, those editors tend to survive more, on average. Over time, the average long-time editor is more tenacious and in my eyes less willing to collaborate because the environment silently rewarded tenacity: If making the other person silently give up and go away is rewarded (because you get your way), then that's the editor base that you'll get after a long enough period. By now, I think that the average newcomer is far less tenacious than the average long-time editor, so the result is that in an inevitable disagreement, the long-time editor gets their way and the newcomer leaves.
3. Less open culture: Extended confirmed restrictions are an example of this. I think this one is a lesser issue than the ones above because it's focused on specific topic areas, but it still contributes. It's hard to reconcile the myth of "an open encyclopedia" with the fact that most hot-button topics are practically locked to newcomers. For a casual newcomer, getting 500 edits seems like a herculean task if they extrapolate from their first edit, which may have taken a few minutes to read the article, notice some mistake, and then fix it. If I was told that I need to spend e.g. 500* 4 minutes = 33 hours to be able to edit some article, I'd think lol k and go do something else with those 33h of free time.
How to fix: #1 and #3 are frankly complicated. #2 is difficult because of a scale surveillance and enforcement problem: From a project-wide perspective, uncollaborative behavior is a death by a thousand paper cuts where many small unfriendly interactions make many newcomers leave. Frankly, I wonder if setting up AI that scans all editor interactions and scores people's behavior for collaborativeness might be useful, along with producing exemplars as evidence for the score. It's not technically difficult to set up, and it can just act as an alert queue for interactions that likely led a newcomer to leave (one can test that by the last few interactions of a newcomer, who they worked with and what happened). The main issue might be cost, but I think a selective trial run could be inexpensive to try out. spintheer (talk) 21:48, 12 June 2026 (UTC)[reply]
A triangular graphic representing a "hierarchy of disagreement" from clear refutation to mere vituperation, based on the essay "How to Disagree" by Paul Graham.
I think that we can look at Hierarchy of Disagreement to see the problem. When dealing with new editors, some experienced editors start by contradicting them and then never actually offer a counterargument. New editors respond with name-calling, and then the experienced editors respond to the new editor's tone without addressing the point. On Wikipedia, accusing someone of being an expert or looking "involved" is just a thinly veiled ad hominem.
I started editing Wikipedia because I found an error on a page, I was looking for citations for a publication I was working on and figured the Wikipedia article might have some useful ones. The main problem I've seen with experts is they are used to writing to expert audiences, and citing certain technical things for them is like citing the sky is blue. Then, when a citation is demanded, they don't actually know where to find it because it is so deeply engrained as common knowledge that no one in their discipline has cited the fact in decades.
In the coming few years, we'll need to be careful about accusing newcomers of AI: it's increasingly difficult to tell the difference a human imitating AI and AI imitating humans. I spoke to a journal editor a few years ago about AI detection, and he said they were running all the submissions through a checker and desk rejecting the ones that came back as using AI. I told him to take something he wrote from before AI was a thing and check it, and it returned with a number that would have caused a desk rejection. Turns out, academics have a way of speaking that AI is really good at mimicking as it was trained on a lot of open peer-reviewed publications. Wikipedia also has a way of writing, and AI was trained on Wikipedia. This will be a huge problem in the future.
The worst Wikilawyering I've encountered was on an article I originated where several editors decided they wanted it a certain way, even though I had researched policy and found the way I was doing it was acceptable. The problem was formatting and layout of the page, not even content related. A few admins were mixed in the bunch, and they essentially told me that they were doing it because that is the way they like it, and then went through other articles I made and applied the changes. They then tagged other articles I wrote with multiple tags, and nominated a page I originated for deletion that ultimately was not deleted. Really turned me off from the Wikipedia community, still sour about it, and again in hindsight, I don't think they had a leg to stand on besides 3 against 1 new editor. I'm the one who originated the pages, and I've stopped thinking about expanding them at this point because of this interaction.
I spoke to a journal editor a few years ago about AI detection, and he said they were running all the submissions through a checker and desk rejecting the ones that came back as using AI. I told him to take something he wrote from before AI was a thing and check it, and it returned with a number that would have caused a desk rejection.
I have never seen anyone make a claim like this and actually provide proof of the text that supposedly did this.
Actually, wait, no, I saw it once. That person was a blogger who previously wrote an article about how they use AI in their writing process. Gnomingstuff (talk) 05:45, 11 June 2026 (UTC)[reply]
I used ZeroGPT on random open-access science journal articles from 2016, I checked five articles and got scores between 1% and 39% (at 35% and 39% ZeroGPT describes the text as mostly human written but containing contributions from an AI; at 4% and below it describes it as human-written, I didn't get any results between 4% and 35% in my sample). I don't know what threshold the editor GeogSage talked to was using, but the claim is certainly believable. Thryduulf (talk) 09:51, 11 June 2026 (UTC)[reply]
I didn't think to keep a record of that unfortunately (I don't even remember which journal it was and I'm on a different machine to then so can't reconstruct it from browser history). I think I googled something like "open access science journal 2016". I know I picked studies from different fields (or what appeared to me to be different fields based on the title) and used the abstract and first section up to the maximum length allowed for free (iirc the list of articles was sorted by date). Thryduulf (talk) 19:47, 16 June 2026 (UTC)[reply]
I ran a couple of my Wikipedia articles through one of the free online detection websites during an early discussion about LLMs. One of them was declared to be highly likely to be AI-generated. (I no longer remember which one, but there may be a link in one of the talk (WT:) pages.) Now: that was then, and the detectors might be better now, and free websites are often worth what you paid for them, etc., but it made me wary of trusting them. Maybe they mostly work, but a 1% false-positive rate applied to 100,000 edits would mean 1,000 edits wrongly flagged. WhatamIdoing (talk) 05:03, 14 June 2026 (UTC)[reply]
My Masters thesis is from 2019 and is considered 3% GPT with zerogpt. Within the body of the document, in more technical sections, the number goes a bit up. For example, the line "H0; There is no statistically significant difference between the performance of the" comes back as AI. A few years ago, the number was higher when I checked. Grammarly currently detects zero AI in it, but earlier this year did say there was something or other that looked like AI. One concerning thing is Grammarly only detects my Abstract as 100% plagiarism, so someone could get the rest of my thesis past it and publish it as their own if it was the only plagiarism checker. @Thryduulf, this was a few years ago now, but I believe they were using a 10% hard cutoff, but the editor would use discretion if it was lower, so a 1% detection could have resulted in a desk rejection if the editor felt it look particularly egregious. Go play with old peer-reviewed publications, if you do it for any amount of time you'll find old publications that come back as AI-written. GeogSage (⚔Chat?⚔) 05:32, 14 June 2026 (UTC)[reply]
I think we need to look beyond raw numbers. Do we want to retain new editors? Yes - if they are helping us to have well researched and well written articles … No - if they are producing crap. Blueboar (talk) 12:31, 11 June 2026 (UTC)[reply]
If someone is actively trying to be helpful and willing to learn, we can teach them not to produce crap if we have some patience. GeogSage (⚔Chat?⚔) 05:33, 14 June 2026 (UTC)[reply]
Hi. Alas the situation does not look so good with respect to technical articles. We can teach newcomers how to edit pages that do not require deep knowledge, but many of those people who know technical topics have played with Wikipedia or done serious work in the past 10 years then left. I am surprised how many have left. I did a few fixes to Theory (mathematical logic) the other day, then went to see who had edited it before. The top 3 editors who had done about 60-70% of the edits (and all seemed to know the subject) are no longer here. Two stopped a few years ago, the other was blocked for other reasons. And the wannabe logicians have made a mess of some issues. Good intentions, but low on knowledge. So the situation is highly time sensitive. As the experts get tired and leave very few newcomers have expertise to replace them. I was pleasantly surprised to see the young and bright User:JoaoFrancisco1812 do good edits, but he is an exception in the logical space. So time is not on our side. Sorry, but that is how it is. Yesterday, all my dreams... (talk) 09:27, 15 June 2026 (UTC)[reply]
I see a trend here. They left or got blocked, probably because of hostility (WP:BITE). On PL wiki we want to engage mentors more, so they look up the mentees instead of just waiting for questions that may never come.
I had this idea to list all mentees and their latest edits using the template that transludes Special:Contributions.
I plan to create a bot on PL Wiki that will keep the list in sync when new mentees join. This way mentors could, once a week, go through the list and see if anything needs their attention.
I do a similar thing for people during trainings about Wikipedia to monitor their activity, but I do this by hand. jcubic (talk) 14:56, 15 June 2026 (UTC)[reply]
Sorry, but that was not the trend. Please look at the facts. The user CBM was an admin and gave it up because of lack of time, he said. Then he stopped editing later. Greg Bard was blocked for copy vio. I am not sure why the other one left but fights were not the reason. They had all been long term editors and the subject of logic does not invite big and repeated fights. Now if you feel like writing a bot please see Wikipedia:Bot requests. I requested a bot to generate data about departed users so we could analyze it. It would be nice if you would write that. Cheers. Yesterday, all my dreams... (talk) 17:33, 15 June 2026 (UTC)[reply]
If I have working code on PL Wiki, I will think about adding it to En Wiki. Will probably write a different thread to know if anyone is interested. jcubic (talk) 17:39, 15 June 2026 (UTC)[reply]
One issue I've seen on issues I'm fairly well versed on is a strong Dunning–Kruger effect. If you have one expert on a topic, unless the rest of Wikipedia is willing to be open to the idea they are wrong, the expert has an uphill battle to fight. The editors who have a limited background on the topic think they have a stronger grasp of it then they actually do, and because of Wikipedia policy regarding WP:BLUDGEON, it is extremely easy for a few people to overwhelm an expert editor, and then actively use Wikipedia rules to tell the expert to shut up. Makes it pretty hard to keep motivated when you put a significant amount of time and effort into something, only to have it overruled by a local consensus that has almost no idea about what they are talking about. 1,000 editors arguing with one expert on a topic doesn't make those 1,000 editors correct, but good luck pointing that out.
That is certainly true for some topics, but not all. How many novices have even heard of Tennenbaum's theorem which gets about 10 views a day. CBM seems to have just written most of that with no conflicts. I am sure everyone and his uncle has an expert opinion on psychology or economics. But in high energy physics or the obscure parts of math logic the novices do not even know how to spell the article titles. Alas some experts who joined 10 to 15 years ago have all worn out, by fatigue not just fights. And the supply of young experts is limited. The smart ones want to start a billion dollar AI company, not do anonymous unpaid work. C'est la vie. Yesterday, all my dreams... (talk) 20:32, 15 June 2026 (UTC)[reply]
To look at your question from a purely numbers standpoint, we can make some ballpark back of the napkin estimates to see the problem. First, assume experts are equally likely to become Wikipedia editors as the general population. Looking at the tables on Wikipedia:List of Wikipedians by number of edits, only about 1 in 5 editors have made more then 10 edits. Generally speaking, even if we snag an expert, the chances of them staying around are already pretty low. Looking at Wikipedia:Wikipedians, there are 16 million accounts that have edited Wikipedia. Assume that the 2011 demographic numbers at Wikipedia:Wikipedians/Demographics still holds, roughly 20% of those will be U.S. citizens, so 3,200,000 accounts (limiting for U.S. cause the numbers are a bit easier to get). The U.S. population is roughly 341,784,857, so assuming everyone who has edited Wikipedia is still alive, roughly 0.936% of the population has an account that has edited Wikipedia. You can then apply that to say, the number of Americans with a doctoral degree of some sort is (roughly 2%, so roughly 6,835,697 people), so all things being even, roughly 63,982 Americans with a doctoral degree should have edited Wikipedia at some point. If you split this number up by discipline, the numbers will be shockingly low. Looking back at the table, 1 in 1,000 editors has made 10,000 edits, so without some outside influence, we can expect 64 doctoral level editors from the U.S. to have made 10,000 edits. Obviously confounding variables make this ballpark guesstimate have pretty enormous error margins, but even if you triple that it still is a fairly small number across all disciplines. GeogSage (⚔Chat?⚔) 21:28, 15 June 2026 (UTC)[reply]
Not a fan of Fermi problems? Understandable. I was taught to guestimate as part of designing a broader experiment to answer a question. Essentially, start with broad estimate, refine the number, then use that to formulate your hypothesis. Then design an experiment, gather observations, and compare them to the initial estimate. GeogSage (⚔Chat?⚔) 22:55, 15 June 2026 (UTC)[reply]
Another issue is that of "extremely occasional" edits by experts. Over time, I had seen some advanced and nice edits by User:Tillmo eg the creation of the page Institutional model theory which novices could not even begin to edit except for typos. But he does 5 to 7 edits per year at best! Can we get new young editors to work on those pages? I have not seen them. We are seriously short of experts. Yesterday, all my dreams... (talk) 21:26, 15 June 2026 (UTC)[reply]
Why do newcomers leave? I would not even attempt to hazard a guess. It would be pure speculation without multiple focus group studies, which we can not easily perform, given no access to the departed, so to speak. What experienced marketing people would tell you is: never guess, study the market and the participants. So we can all guess for ever, based on our limited samples of interactions, but I have no idea who will be proven right if we have access to the motives of the users. We could contact those with emails, but not so easy. So let it be as it may. Yesterday, all my dreams... (talk) 22:31, 12 June 2026 (UTC)[reply]
I did not know about the MIA page. When I looked at it my first reaction was: this needs multidimensional analysis. Then something funny happened. I looked at the multi-D page and saw that it was really short with just 2 sources and would probably make John Tukey laugh because it totally ignores his work. Then I saw that over 50% of the edits were by User:Wikiant who stopped editing in 2018! That page needs help. But the MIA page needs to go into a database so multi-D views can be used. I wonder who has time to do it. Yesterday, all my dreams... (talk) 02:10, 13 June 2026 (UTC)[reply]
By the way, having looked more at the MIA page, I have serious doubts about the completeness and accuracy of the data there. There is a lot of data, a good deal of it entered by ip edits. A simple bot can generate that page correctly every month. Yesterday, all my dreams... (talk) 06:12, 14 June 2026 (UTC)[reply]
That page was never intended to be comprehensive. I believe it was begun by editors who missed particular friends, collaborators or sparring partners; over the years it may have been added to somewhat more objectively or systematically, but it’s certainly unsuitable for analysis beyond individual anecdotes or ‘case studies’.—Odysseus147922:14, 15 June 2026 (UTC)[reply]
...A bot that automatically emails editors with more then 100 edits who have not edited in 12 months with a survey could provide some pretty useful data... Like, worthy of a peer-reviewed publication. GeogSage (⚔Chat?⚔) 22:45, 15 June 2026 (UTC)[reply]
There's been a lot of research done in the past, and the main reason for a promising new editor to quit is that their first good-faith attempt was reverted. The best thing you could do to retain editors was to fix the problems they created. This means, e.g., looking at a fairly bad edit with a fairly bad source, and thinking "Oh, they're right: This article was missing information about ____. Let me see if I can find a good source and fix this up". Instead, what we mostly do is say "You didn't do it perfectly on the first try – revert!" WhatamIdoing (talk) 05:06, 14 June 2026 (UTC)[reply]
As an RC patroller, I think that this is a very important issue that I myself do without meaning anything about it. I'd honestly be fine going on an RC patrol tool (even one where the entire job is to revert vandalism) mainly to find bad but good-faith edits and make them good again. In solidarity,FantasticWikiUser(Ts and Cs)13:21, 16 June 2026 (UTC)[reply]
From my perspective as someone who joined Wikipedia in 2024, newcomers are probably too afraid to make a mistake or not seem professional, as their edit mistakes are forever kept in an article's edit history. So some kind of spotlight effect or such is turning new users away. This effect is amplified if their edit gets reverted on an article about their local history and area. QuadrangleDinglePingle (talk) 07:17, 14 June 2026 (UTC)[reply]
On the 8th and 9th June, I decided to make a quick test by putting some accounts into a word processor and seeing what happened. This is what they've done.
Kaffe453 - Doing quite well. None of their edits were reverted, but they weren't welcomed either. I welcomed them just now.
Madein100 - Was welcomed and not reverted, but added links to articles over and over again.
RetlawStnaj - 2 edits, one on May and one on 8th June. No reverts, no welcomes.
Fizzymelonjuice - Did newcomer tasks without reverts on 9th June. On the 14th, they were welcomed and made another edit.
I speak only for myself, but I really wasn't inclined to stick around after my bad experience with ANI and the J.K. Rowling article (in fact I resigned myself top reading due to the reception I got, especially from one particular Wikipedian). I went to the J.K. Rowling article, hoping to find out about her transphobia, and found nothing, which I thought odd for a featured article. Having been an IP editor/reader for a long while, I knew about talk pages and pages like Administratrator's Noticeboard/incidents (and enjoy reading them as well as policies. I'm one of those people who likes to see how the sausage is made), though not entirely how they worked. I read through the talk page, which was in the middle of a very contentious featured article review, and found some serious WPO:OWN issues, what I perceived as throwing out policies because they might make Rowling look bad and "it's a featured article", and what I saw as other rulebreaking. I thought I would take it to ANI to get things on track, and while it was rightly closed as a content dispute, the call to ban me from the noticeboard, the constant pestering from one user to explain how I had come across that board (IIRC. May be misremembering), and, in the aftermath, the perceived unapologetic approach to what I saw and still see as a major case of WP:BITE, instead of acknowledging that maybe they had gone too far in trying to do so, directing me to an area I had no interest in, let's just say that I wasn't exactly interested in sticking around if a newbie could be treated like that without even a slap on the wrist. That the J.K. Rowling article was ultimately defeatured did make me happy, but it was too little, far too late to bring me back at that point--Lover of lgbt literature (talk) 22:35, 14 June 2026 (UTC)[reply]
Revision history statistics
The page information external tool "Revision history statistics" shows editor activity measured in several different ways. What is missing is any count of article text deleted. When an article is overlong and full of questionable content (uncited, off-topic, hyperbole, etc.), deleting material may be more important than adding new content, yet it is given no recognition in the statistics. This seems to be an omission. ThoughtIdRetiredTIR21:25, 6 June 2026 (UTC)[reply]
I guess they're talking about the Xtools page history (linked as "page statistics" on the history tab), e.g. [25] for the random article I got. It shows the top 10 editors by added text and by authorship, but the only thing related to deletion it shows is the single edit that resulted in the greatest reduction in page size. Thryduulf (talk) 20:58, 9 June 2026 (UTC)[reply]
Yes, was just putting together the answer: At the bottom of Information for "Wikipedia:Village pump (idea lab)"[26] you see "External tools", the second one down is "Revision history statistics" with the link [27] . ThoughtIdRetiredTIR21:06, 9 June 2026 (UTC)[reply]
OK, we can see the amount of deleting that one editor does, but not the activity of an efficient editor who deletes a lot of material in a very small number of edits. In your example, Hipal has made 57 edits and so appears in the list for you to investigate further. Suppose another editor had deleted much more text, but overall made just 5 edits; the deletion activity would be completely invisible.
Furthermore, there is no clue in [28] that Hipal has made any deletions. You have to do a manual search to find the information that you have highlighted.
The point I am making, if it needs reiterating, is that this tool tells us all about those who add text to Wikipedia and nothing (readily accessible) about those who delete material that should not be here. Reporting added text, when an encyclopedia is meant to be concise (summary style), is perhaps a little off-key when not balanced with showing deletion activity.
We know that deletions happen, from the ups and downs of the graph of article size (at the bottom of the page linked immediately above). The questions "who does this?" and "what do they delete?" are difficult to answer without laborious study of an article. ThoughtIdRetiredTIR08:25, 14 June 2026 (UTC)[reply]
https://xtools.wmcloud.org/pageinfo/en.wikipedia.org/Feng_shui#top-editors shows the first 20 by default; if you want to see the full list, then a link is provided immediately after the 20th entry. If you click it, it expands to 200; if you click it again, it expands even further. Every editor of that page is listed, but you have to click to reveal the less frequent ones.
I asked a question at WP:Help Desk#What links here and discovered a very useful tool called WikiNav that gives link statistics. A number of experienced users were also unaware of it, and some were surprised that it exists. I find the information it provides eye opening.
Could ask @MusikAnimal to add it to the "analysis" submenu of the MoreMenu gadget, as I suggested in that earlier discussion. A lot of editors use the gadget, and it being available from the menu would immediately make it widely available and convenient to use. – Scyrme (talk/solidarity) 17:31, 10 June 2026 (UTC)[reply]
The issue is that for privacy reasons, the tool only works for popular-ish articles, and for a limited number of languages. MoreMenu can be configured to handle the language bit but it won't know if the tool supports a given article or not, so many times the link won't work. That said I do hope to maybe one day integrate WikiNav data (and a link to WikiNav for the visualizations) directly into https://pageviews.wmcloud.org. — MusikAnimaltalk19:52, 10 June 2026 (UTC)[reply]
That is my impression. WikiNav doesn't work when pageviews are too low, but I don't know what the cut-off is, and it would be nice if it just said that rather than returning a cryptic error. —Myceteae🌈 (talk) 21:40, 10 June 2026 (UTC)[reply]
Agreed, I find it quite useful. I've learned about its strengths and weaknesses by using it and reading what other editors have to say about it in discussions, mostly RMs. I've developed my own sense of how to use it alongside other tools but I know there are gaps in my understanding. As I suggested down below, it would be helpful if we had an essay or information page describing how it works and addressing good use cases and pitfalls/limitations. This could include a broader discussion of Clickstreams. —Myceteae🌈 (talk) 14:25, 11 June 2026 (UTC)[reply]
The underlying data is cut off at ten clickthroughs per page pair per month. So if there are nine clicks from A to C, and eleven from B to C, the data will only report the eleven B to C. If all pairs are below ten, then we get nothing at all. Unlike standard pageviews data, it seems to ignore any traffic through redirects (which can be significant for some pages) and is only available for 40 specific projects - I think this is the 40 largest WPs by traffic, but not 100% sure how they're selected.
I've just done a quick check on the clickstream dumps for recent months - roughly speaking in any given month about 80% of en.wiki page titles have data, but it's not consistent month on month. I would guess overall it is about 70% reliably having data and the rest being "...maybe, depending on recent traffic" (or recent page-moves, etc).
The flat cutoff of 10 pairs means that as we look at smaller wikis, they will have an increasingly higher dropout rate; one of the smallest datasets is for Malayalam, ml.wiki, and that has data for less than 30% of page titles in April. Andrew Gray (talk) 17:02, 11 June 2026 (UTC)[reply]
Yes, I have noticed that it works in some cases and not others. But I have realized several things with this tool, as is. So it is much better to have it as is rather not. As for other languages, let us start with the largest Wiki, English language. A journey of a thousand miles begins with ... one language. Thanks Yesterday, all my dreams... (talk) 20:10, 10 June 2026 (UTC)[reply]
WMF has recently reduced its rate limits for some API calls. It is possible that publicising a tool might cause many people to try it out simultaneously and hit the newly lowered caps. Ideally, the frustrated tool would then explain why it is unhappy, but that may not always happen. Certes (talk) 10:25, 17 June 2026 (UTC)[reply]
Certes, as I said above, I shall make no further comment on WikiNav. But I do feel that I owe you a thank you for your initial comment on the help desk. So thank you, and I am done. Cheers. Yesterday, all my dreams... (talk) 15:18, 17 June 2026 (UTC)[reply]
I learned about it by participating in a lot of RMs, where it is often used. I assume most editors learn about on- and off-wiki tools and resources in a piecemeal fashion by participating in discussions. I like the idea of spreading the word. I provide some ideas in reply above but otherwise I'm not sure what the best way to do this is. An essay, information page, or how-to guide that describes WikiNav and some of its pitfalls, à la Wikipedia:Search engine test and Wikipedia:Pageview statistics, may or may not increase visibility, but would be of benefit to the community. —Myceteae🌈 (talk) 21:58, 10 June 2026 (UTC)[reply]
Just chiming in to say thanks for mentioning the timeouts on the graphs and I appreciate the patience but these should hopefully be fixed now. Glad that you all are finding it useful! @WhatamIdoing is right that it's in a bit of a maintenance-mode state but we try to make fixes/improvements where we can. Isaac (WMF) (talk) 21:15, 17 June 2026 (UTC)[reply]
And let me add, I hope that WMF continues to support WikiNav. I find it quite useful and see it cited with some regularity at RM and other venues. —Myceteae🌈 (talk) 21:18, 17 June 2026 (UTC)[reply]
New User Tutorial
I would like to suggest adding some kind of relatively comprehensive tutorial for people who are interested in getting involved that shows where everything is. Simple things like how to make citations using the visual editor would go a long way. Something that guides through where to post and where to reply and simply what buttons to push would not only make a more welcoming environment and encourage people to register, but would also avoid mistakes and confusion. Simple ignorance can quickly escalate into conflict.
I don't know if I'm putting this in the right place right now or not because no such tutorial exists. I saw a suggestion that included this, but had no way (that I could see) to reply to it. Idacticus (talk) 06:46, 13 June 2026 (UTC)[reply]
The guided tours are an absolutely brilliant idea. I hope we can get some experienced hands to write them. It's frustrating not knowing where any of the buttons are or what they do, and confusing trying to figure out how to use the various community and talk pages. I can't be the only person that gets discouraged from contributing when there's such a big learning curve. As soon as I'm confident with operating this setup, I'll write a tour. Once we have them written, it's a matter of implementing them for new users. Idacticus (talk) 00:49, 19 June 2026 (UTC)[reply]
Auto-citing a source using VisualEditor, small
This old gif doesn't show the up-to-date interface colors, but I think it will show you what you need to know about the most popular way to add a citation in the visual editor.
I have a draft RFC at User:BilledMammal/NC minimization project that I plan to open next month. The intent is to start address the ludicrous number of naming conventions we have, by proposing we demote twelve of the least impactful.
I'm opening an initial discussion here to determine whether there are any I've included that I am wrong about - that have to be kept - or if there are any I have missed that should be demoted. I have deliberately omitted some with low impact, as I prefer to address those with mergers in stage two of this project, if stage one is successful.
My initial impression is that your analysis frequently treats explicitly linked references in RM discussions as the sole (or at least by far the most important) factor determining whether a convention is useful to maintain. That is an overly narrow view imo, as it neglects to account for cases where a naming convention guidance is uncontroversially followed to the extent that RMs have not been needed in the topic area. Thryduulf (talk) 11:47, 16 June 2026 (UTC)[reply]
I agree, this is overly narrow. I have had the thought that it would be interesting to review actual article titles against various NCs to see which are most often followed in practice. Even with this, there is a risk of making broad conclusions based on superficial analysis. Some topic areas are subject to more scrutiny than others. Also, some NCs or other guidelines may be frequently cited because they are controversial. Not every guideline that gets linked in an RM wins the argument. I'll have to look more closely at the proposal before offering additional opinions. I think there is something worth looking at here but I'm skeptical of the approach initially. —Myceteae🌈 (talk) 17:24, 16 June 2026 (UTC)[reply]
When there are very few references - just a couple a year, or in some cases far less than one a year - I do think that's the most important criteria, as it is strong evidence that the guideline is basically useless. It is possible that some of these naming conventions are uncontroversially followed to the extent that RMs have not been needed in the topic area, but that is why I've listed this here to help identify such conventions, and I also believe that if they are uncontroversially followed then in general WP:CONSISTENT should be sufficient.
I would do away with a lot more of these than are proposed, and rely on just one policy/guideline, but I also recognise that many people seem to want to have everything spelt out for them. Phil Bridger (talk) 19:01, 16 June 2026 (UTC)[reply]
Regarding baseball players, by "get rid of" do you mean eliminating the separate page, but leaving the naming conventions in place? If so, I agree the content shouldn't be duplicated on multiple pages. I don't agree with the proposal in the draft RfC to demote the conventions themselves. My understanding is that they were all devised to handle real cases that came up, so they might as well be written down in one place rather than left behind in the mist of time. isaacl (talk) 01:41, 17 June 2026 (UTC)[reply]
Is there some issue created by having 80 naming convention pages that have the guideline tag on them that having 68 won't cause? Katzrockso (talk) 01:55, 17 June 2026 (UTC)[reply]
68 naming conventions is bad - it's WP:CREEP, WP:BURO, and makes it difficult for new (and even experienced) editors to participate - but 80 is worse. It's not a solution by itself, but it is the first stage of a project that I hope will make our naming conventions far more manageable. BilledMammal (talk) 06:57, 17 June 2026 (UTC)[reply]
Fair point. This would be a 15% reduction in NCs, which is meaningful even if one thinks there are still too many left. —Myceteae🌈 (talk) 16:24, 17 June 2026 (UTC)[reply]
What's the advantage to reducing these to essay status? I'm firmly in favour of reducing instruction creep so that guidelines become more readable and less imposing. But if anything, I think short naming conventions separated from Wikipedia:Article titles help in that way. I don't see the problem with them briefly codifying consensus, given we should be aiming towards standardisation as enwiki becomes more mature. Where there's consensus that can be codified, it should be codified as long as isn't creepy. If these guidelines don't reflect current editorial consensus, then that's a much greater issue. J947 ‡ edits02:50, 17 June 2026 (UTC)[reply]
I think codifying any consensus contributes to WP:CREEP. In some cases it is necessary, but in most cases it isn't.
I just don't see what distinction it makes to demote to essay. This feels to me like putting too much faith in our bureaucracy. It's a sheet of paper that everybody follows anyhow, and the guideline status makes it clear that everybody does follow it. It's not that they're hard to understand either. In solidarity, Aaron Liu (talk) 16:39, 17 June 2026 (UTC)[reply]
This is a good point. Topic-specific naming conventions are mentioned multiple times throughout WP:AT, including the initial description of 'consistency' at WP:CRITERIA, and are nicely listed in the {{naming conventions}} infobox right at the top. Maybe some of the shortest, most straightforward, and least controversial NCs are some of the best. CREEP is a real concern but it can be tough to balance that with the value of concise, uncontroversial documentation of actual consensus. —Myceteae🌈 (talk) 16:21, 17 June 2026 (UTC)[reply]
I feel like this is a fair reservation in some cases, but some of the guidelines add little to nothing to other ones, and only our conventions much harder to parse for any new editor. We don't exactly distinguish between NCs that are constantly being applied with those that are applied once in a blue moon. We have to also consider new editors aren't really able to quickly identify and discard excess information in the guidelines in the way we in this discussion are able to. As they aren't familiar with NCs it will be far from obvious to new editors that some of the guidelines are just rewording other guidelines, and if they do realize it seems very similar they may think they're missing something because there isn't any reason to have a guideline that says the same thing another guideline does. It wastes time and contributes to unnecessary confusion. ⹃Maltazarianᚾparleyinvestigateᛅ17:29, 17 June 2026 (UTC)[reply]
I have no problem with eliminating conventions that are just repeating broader conventions, but for the rest, I don't see how those make conventions harder to parse. I'm also not sure how often newcomers would need up deal with naming conventions. Naming conventions seems like one of those areas where correcting newcomers doesn't drive them away thanks to how uncontroversial (following them, not making them) it is. In solidarity, Aaron Liu (talk) 22:33, 17 June 2026 (UTC)[reply]
Plus it doesn't matter that much if a new editor isn't initially aware of the non-controversial naming conventions for a given topic (unless they immediately start creating many articles at once). If it's an active area of interest, interested editors will move the article and let the new editor know ("hey, just letting you know for the next time"). Learning by example is very common. isaacl (talk) 22:42, 17 June 2026 (UTC)[reply]
But I think most do learn by example, either by stumbling across WP:RM or when their preferred title is changed or disputed at AFC or by someone boldly moving a page or some other process or discussion. Or they start reading about policies and guidelines first, before encountering NCs "in the wild". In that case they will either encounter WP:Article titles first, where NCs are referenced multiple times and listed in the infobox. Or they will first stumble on a specific NC, where they will see the same infobox listing all the other NCs and the Article titles policy. On one hand, I do think the sheer number of policies and guidelines is intimidating and that newbies are prone to getting discouraged when all their early edits are met with a deluge of WP:UPPERCASE. On the other hand, NCs are a fairly "contained" family of guidelines and so if the goal is just help newbies learn about them, the present organization would seem to accomplish this. And a newbie may still feel discouraged and overwhelmed by links to WP:CONSISTENT and a dozen other articles that illustrate a pattern that used to be codified in a naming convention. —Myceteae🌈 (talk) 23:50, 17 June 2026 (UTC)[reply]
Regarding using uppercase jargon: I just get disappointed at the extent that all-caps jargon terms are used. I appreciate there are times when it provides significant expressive conciseness, but the vast majority of the time, it doesn't. Some editors have expressed the view that learning the jargon is part of joining the community, but I think other forms of initiation are more worthwhile to promote. Unfortunately, most of the community seems to feel that using jargon is a net benefit. isaacl (talk) 00:52, 18 June 2026 (UTC)[reply]
Sure, but getting rid of some of the wholly unnecessary ones feels like a net positive considering we're not getting any use out of them.
As for the comment about uppercase jargon: yes, it is true, it takes some getting used to, but in my personal experience it's alright as long as there are wikilinks to the thing being referenced. ⹃Maltazarianᚾparleyinvestigateᛅ03:24, 18 June 2026 (UTC)[reply]
Yeah, I didn't mean to digress into the pros and cons of UPPERCASE so much an engage with the impact to new editors particularly. I'm open to the idea of trimming the list of NCs but I'm not on board with the proposal in its current state. Some could probably be condensed with others but I'm not sure there's a "home" for all of them. I see an important distinction between those which are redundant or WP:CREEPy and those which may not reflect consensus. If we "downgrade" some of them to advice pages or mark them as historical, that may suggest they no longer reflect consensus, which may lead to confusion or open up fresh disputes about long settled titles. —Myceteae🌈 (talk) 03:44, 18 June 2026 (UTC)[reply]
I was thinking over why the Manual of Style has historically been so contentious while these naming conventions (as far as I know) generally haven't been and I think maybe the missing element is "applicability". Naming conventions for ancient Romans aren't applicable to most editors, who don't have to know what they are or even that there is a naming convention. If you're one of the few editors writing new articles about ancient Romans, you'll probably find your way to the others pretty quickly, and everyone will have some background knowledge about why the conventions are justified. On the other hand, if some editors start revising MOS:DASH, the guidance there is applicable to just about any editor, and you need to be cognizant of it to understand why Mexican–American War doesn't seem consistent with Franco-Prussian War. I think WP:CREEP carries much more weight in the latter situation than in the former. Choess (talk) 01:02, 19 June 2026 (UTC)[reply]
I think we need to do more to connect new users to the corresponding groups of editors with common shared interests, so they can help guide people on established norms. I think the best bet is for the auto-assigned mentor to point users to the right discussion pages. But how to get communication going between mentors and their assigned users has so far been a hard problem; the question to mentor ratio has been reportedly very low. Hopefully any users who have trouble finding the right guidance page and aren't asking their mentor will still create new pages and then be able to learn by example. isaacl (talk) 00:43, 18 June 2026 (UTC)[reply]
A feature request: Syncing the cursor between Source Editor and Preview window (like Chrome Inspect)
Hi everyone,
I had a thought while going back into editing (after a while i was absent) some long articles recently.
Right now, when using the split-screen/side-by-side view with the Source Editor and Live Preview, navigating back and forth, while trying to pin-point an exact location can get a bit frustrating. If I'm looking at a specific paragraph or an infobox in the preview side, I have to manually scroll and hunt through sometimes hundreds of lines of wikitext to find where it actually sits in the code.
I was wondering if it's possible to implement a cursor-level synchronization, similar to how the Chrome Developer Console works when you use "Inspect Element".
The best option would be if it work both ways:
If I click on a paragraph or a citation in the Live Preview, the cursor in the Source Editor would instantly jump to that same line in the code or highlight it some how
And if I place my cursor on a line of the wikitext, that part should automatically scroll into view and maybe also get a highlight in the preview window.
I think this might prevent a lot of small errors and would be very helpful for editors that go through large amounts of material while editing and dealing with big templates, infoboxes, or massive articles where it's super easy to get lost and confused in the code.
Has this been discussed or proposed before? I went over the archives but couldn't find any prior similar suggestions, or maybe its already there with a gadget or something similar that im not yet aware of? Would love to hear your thoughts Happypenguins82 (talk) 13:15, 17 June 2026 (UTC)[reply]
When I'm jumping between a preview and the source code I usually use ctrl+F on a portion of prose without a wikilink. A few words is usually unique within a particular article. CMD (talk) 13:44, 17 June 2026 (UTC)[reply]
I'm actually doing the exact same thing :)
It is a lifesaver, but it still feels a bit clumsy and slows down the flow. It gets especially confusing when you're dealing with really big articles, or when you're trying to find the exact spot inside big infoboxes or long citation templates where text search is a bit more of a headache.
That's why I thought an automated function would be rally useful… but naturally only if its technically achievable, it would save all those extra steps and just make everything much much smoother.Happypenguins82 (talk) 15:05, 17 June 2026 (UTC)[reply]
Our tool is a lightweight user-facing early warning system which alerts users when conversations are getting heated, based on research which shows that giving users a gentle nudge can help de-escalate tense conversations. The tool will provide an estimate of whether or not the discussion looks to be getting tense (i.e., likely to deteriorate into violations of the Wikipedia:No personal attacks policy)
Since last October, we have talked with several members of the community (some which are collaborators on the project Barkeep49L235) to refine this tool, and we’re interested in launching a larger user study.
Through participatory design, taking into account ongoing discussions on other tools like Tone Check, we have designed the tool to empower the user, while leaving all decisions in their hands: the tool does not make any edits and does not suggest text. (We are seeking more contributors who would be willing to test these tools long-term!)
Information page: https://en.wikipedia.org/wiki/User:Laerdon/ConvoCompass
Would be excited to discuss with anyone interested in this thread; we envision ConvoWizard as a prototype for a future user-facing tool that editors who frequently engage in discussions could include in their everyday workflow, and are curious as to how this might fit in alongside the many other tools that editors already use. Laerdon (talk) 16:10, 17 June 2026 (UTC)[reply]
I've noticed that many glossary articles have the problem of beginning the title with "Glossary of" but also including "terms" or "terminology" in the title. Such examples currently include:
and so on. Including wording such as "terms" or "terminology" in the case of these articles not only makes the titles longer (unideal per Wikipedia:CONCISE), but is also poor English. A glossary is by definition already a list of terms or terminology, so adding such words is completely redundant. This is the equivalent of eg. titling a map of Germany as a "map of German places". If the above titles were corrected, they would read:
However, I am unsure on how to perform such a mass correction, as it appears that many tens of articles are named in this way (based on my searches). I would like to know other people's thoughts on these titles and if/how they can be changed. ―Howard • 🌽3323:11, 23 June 2026 (UTC)[reply]
WMF
Abstract Wikipedia goes somewhat live and already hosts unattributed enwiki copies...
The extremely expensive, buggy and ill-thought out "Abstract Wikipedia" has gone live after many, many years, and already it hosts an "article" which not only go against the very purpose of it (putting a complete English article in html is not the way to get automated Wikidata-based translation to 300+ languages), but also creates an unattributed enwiki copy[30]. Not that I am able to get it to load completely, it only returns a few sentences and then nothing happens (which is better than the many errors other pages generate, usually either "Reached max retries. Try again later." or "Wikifunctions returned a failed response: Error in evaluation" or simply "Page not found" when going from "history" to "read" or "page"...). Why this pre-alpha thing has been released to the world is not clear, why the WMF would think it conceptually is a good or feasible idea even less so. Fram (talk) 10:05, 25 March 2026 (UTC)[reply]
Also see [31], it looks like it’s just going to be another Anglo-project, how tf are non-English speakers supposed to develop the wiki's policies when everything is only done in English. It’s a project that’s specifically not meant to be Anglo and is irrelevant to en.wiki. It should be put on ice until people can discuss via the functions or there’s some kind of multilingual support Kowal2701 (talk, contribs) 11:12, 25 March 2026 (UTC)[reply]
Abstract + wikifunctions is 2 sides of the same coin. And if wikifunctions has this many issues still, then abstract shouldn't have been launched as a "beta". The most basic things don't work yet: e.g. take a random page, click on "edit source" or "view history", then click on "page" or "read"... error, every single time. This is not some obscure thing, this is basic functionality for the whole site, and it doesn't work. Type a page you know exists in the search bar (e.g. Cape Verde), the first result in the dropdown is the Abstract Wikipedia page (see the AW at the end), click it, and again you get the "page not found".
This is probably a simple switch somewhere, but the total lack of care displayed by whoever decided that this was ready to go public is staggering.
As for the multi-language aspect, the core business of Abstract... Q143, Esperanto.
"Esperanto is the languages of internationality. An Esperanto is a languages." (sic!)
In French, this gives "espéranto langue international" plus an error (the title doesn't get translated..., international(e) should be female, the verb has disappeared, ...)
In Dutch, it becomes "taal internationaal". No error, but missing most of the poor original.
Q21, "England is a country in United Kingdom." (sic). In Spanish, this gives "Unable to render this fragment due to an unknown error. ", in Swedish "The rendering service is temporarily unavailable. Please, try again later. " in Italian "Wikifunctions returned a failed response: Reached time limit in orchestrator", in Portuguese "Wikifunctions returned a failed response: Error in evaluation", and in Thai "England is a country in United Kingdom." I'm sure it will work wonders in the small languages for which it is intended though!
I wonder how many employees have worked on this the past 10 years instead of on Phabricator and the wishlist... Fram (talk) 19:49, 25 March 2026 (UTC)[reply]
Most Western companies, and the WMF is no exception, would work better with half the people on twice the salary. But we would have to have a different attitude to work for that to succeed. Phil Bridger (talk) 20:07, 25 March 2026 (UTC)[reply]
Thanks for the link. The team bios seem somewhat telegraphic. Are any of them "hot shot" programmers? And they seem pretty happy. In the commercial world, best software is written by developers who are pushed to the limit. But not for me to dive into details of the team. Yesterday, all my dreams... (talk) 14:40, 26 March 2026 (UTC)[reply]
best software is written by developers who are pushed to the limit
Your word was "best", not most widespread. I heavily disagree that this is the Microsoft development process, and in any case, the market share of all Windows systems combined had been precipitously declining for years now because of how bad it is. The attempt by the WMF to do the development process you propose is Knowledge Engine (search engine) and the surrounding turnover. Aaron Liu (talk) 12:36, 30 March 2026 (UTC)[reply]
As a former programmer who's experienced severe, life-impeding burnout from overwork twice in her career, I can't disagree more strongly with the notion that "the best software is written by developers who are pushed to the limit". — Hex•talk11:37, 28 April 2026 (UTC)[reply]
best software is written by developers who are pushed to the limit. Assuming the limit here is a tight deadline, I would argue that software death marches do not result in great software. Tight deadlines result in insufficient time to write quality code. Quality is sacrificed to (try to) meet the deadline. Not to mention the impact on team morale and work-life balance caused by pressure and overtime. –Novem Linguae (talk) 22:51, 28 April 2026 (UTC)[reply]
I checked my browser console when viewing the OP's link and there were over 65 requests to the API! As of last week, the WMF (I'm presuming a different team which didn't talk to this one) has decided to limit unregistered users to 1000 requests per hour. Total, across all projects. That includes search suggestions, DiscussionTools previews, VisuaEditor, etc. So about 30 page views for you, and then every project breaks unless you have an account! Suffusion of Yellow (talk) 20:12, 25 March 2026 (UTC)[reply]
What I don't understand is how we are meant to make an "abstract Wikipedia" that is automatically translated to every language when the very design of the site is so centered around English. In abstract:Help:How to create an article I see a reference to a function called "Article-less instantiating fragment" which creates sentences like "Paris is a city". However, in some languages (e.g. Greek) such a sentence needs an article so the result will be ungrammatical unless a different function is used. Thankfully it seems like someone noticed this issue because the actual page for Paris, abstract:Q90, uses a different function called "defining role sentence" which doesn't have the same problem. But if basic stuff like this is wrong in the documentation, I don't have much faith in the project. In fact, pages like abstract:Q667 (south) still use this "article-less instantiating fragment" function. Warudo (talk) 11:36, 27 March 2026 (UTC)[reply]
Actually, I found abstract:Abstract Wikipedia:Useful functions for article composition which apparently says that "article-less instantiating fragment" is a good fit for sentences like "Nairobi is a city". It absolutely isn't. Again, it's article-less in English and several other languages but not all of them. While I'm not a linguist myself, it really feels like this system was designed without consulting experts. Warudo (talk) 11:40, 27 March 2026 (UTC)[reply]
It seems to me to be referring to the fact that it doesn't require an article in English. It may or may not require an article in any other language you care to mention, so this seems to be a very anglocentric point of view. Phil Bridger (talk) 17:32, 28 March 2026 (UTC)[reply]
No, that's definitely not it! Article-less and article-ful have different semantic meanings (the term article here seems to confuse a lot of people who do not understand the project, which I suppose means it needs a rename). All of these examples would use "article-less" (despite the fact that two of them have indefinite ones):
Golf is a sport
El golf es un deporte
The United States is a country
യുണൈറ്റഡ് സ്റ്റേറ്റ്സ് ഒരു രാജ്യമാണ്
And all of these examples would use "article-ful":
A bird is a dinosaur
Un ave es un dinosaurio
These are saying two fundamentally different things irrespective of language. Wikifunctions is already equiped to handle this distinction. Feeglgeef (talk) 18:28, 28 March 2026 (UTC)[reply]
I don't see any great difference between "Golf is a sport" and "A bird is a dinosaur" apart from the presence/absence of an article in English. Please explain. Phil Bridger (talk) 19:18, 28 March 2026 (UTC)[reply]
Because golf is a singular thing and there are many birds. Article-less is about one thing, article-ful is about a collection. Feeglgeef (talk) 19:57, 28 March 2026 (UTC)[reply]
Then the name of the function should refer to proper and non-proper nouns, rather than articles. The point was that the name of the function is based on English language thinking. TietoTeekkari (talk) 07:58, 4 June 2026 (UTC)[reply]
"Article-less and article-ful have different semantic meanings". But then why are these semantic meanings not mentioned in the documentation of f:Z26039? Instead the function's documentation says Makes a sentence of the form "X is a Y" e.g "Nairobi is a city.", i.e. it takes an entity (X) and its class (Y) and states that it is an entity of that class. What are the semantic differences with f:Z26095? In case you think this is a small problem, it really isn't. Look at the Japanese translation of this documentation (a language that does not use articles). The translator had to use an English example to explain what the function does because in their language the concept does not really exist. Indeed, as far as the users are concerned, these functions are in fact defined in terms of whether the sentences they generate require an article in English. The semantic difference behind that is hidden to them. Warudo (talk) 22:33, 28 March 2026 (UTC)[reply]
Also, by the way Abstract:Q30 currently says "United States is a country. United States is a republic. Washington, D.C. is the capital of United States." So, I guess the article-less function was not the correct one to use in this case. Warudo (talk) 23:36, 28 March 2026 (UTC)[reply]
I've already said this above, but the "article" being referred to here is a indefinite one (a/an) at the front. definite articles (the) have no semantic meaning and therefore are to be added on a language-by-language basis. Feeglgeef (talk) 00:40, 29 March 2026 (UTC)[reply]
Definite article = "the", Indefinite article = "a/an". Also that's not true. The definite article has semantic meaning. It means that we are referring to a specific member of a group and not to the concept in general. In this case, "United States" means any states that are united, which would also include e.g. the Mexican United States. The United States on the other hand are a specific set of states that are united, in this case, the United States of America. Warudo (talk) 00:49, 29 March 2026 (UTC)[reply]
We already have the distinction between the concept of a federation and the example in North America seperated by Wikidata. Some languages (like Malayalam, as in the example) do not use an article in front of the United States. Eventually, the function will be able to handle automatically adding a definite article. Feeglgeef (talk) 14:09, 29 March 2026 (UTC)[reply]
Ok, to be fair, you're right. The generated sentence is wrong but that can be attributed to an incomplete implementation of f:Z26039 rather than a logic error in abstract:Q30 itself.
Still, there are several questions that remain. First, why are the semantics of the two functions defined in terms of English grammar? You said, Article-less is about one thing, article-ful is about a collection. but as I've said above, that's not how it's described in the documentation. But more importantly, if that's the difference between them then why are two different functions for "article-less" and "article-ful instantiating fragment" given to the user in the first place? Why don't you expose a single "instantiating fragment" function that checks if its input has a subclass of (P279) statement in Wikidata? If yes, use an indefinite article, if not, don't use one.
Just FYI, editing your own comments after someone has already answered without indicating the changes is considered bad practice in the English Wikipedia. Not a big deal in this case as you were just fixing a mistake but keep it in mind in the future. Warudo (talk) 14:47, 29 March 2026 (UTC)[reply]
@Feeglgeef no, your statement is plain wrong. This is how 6 sentences above will be translated to Russian (browser machine translation, but it's a correct translation): As you can see, all 6 cases uses exactly the same grammar construction, because Slavic languages has no articles and they don't provide meanings, that is provided by articles in Germanic languages. We, native Russians, believe that this semantic meaning simply does not need to be conveyed. MBH (talk) 18:24, 21 May 2026 (UTC)[reply]
You have to accommodate the languages that don't, though. The names of the function have been thankfully changed now to "subject is instance of" vs "class is subclass of". These are different things, even if they look the same in Russian. Feeglgeef (talk) 18:30, 21 May 2026 (UTC)[reply]
The copy of enwiki is attributed now, and the project is not doomed because one user fails to abide by copyright law or to make a quality article.
As for the beta release, it's impossible to debug or improve without community content, so I'm not sure what you'd have the WMF do. Feeglgeef (talk) 17:03, 28 March 2026 (UTC)[reply]
"one user fails to abide by copyright law or to make a quality article." Not a single user has made a "quality article", which is hardly possible with the current setup. And the actual intention of the project, automatic translation to small languages, is just not happening.
Random "article"[33] translation to French: "Wikifunctions returned a failed response: No matching lexeme for item in language"
Random "article"[34], translation to Italian: "Wikifunctions returned a failed response: Number of arguments mismatch"
Random "article"[35] translation to Spanish: "(en) Bahrain is a country in Middle East." Hey, I can understand Spanish!
Random "article"[36] translation to Dutch: "Brussel is the hoofdstad of België." THE hoofdstad? Yep, clearly not a problem with the use of articles...
Random "article"[37] translation to French: "Paris est une ville. Wikifunctions returned a failed response: Error in evaluation" Translating two sentences was a challenge of course.
Random "article"[38], no translation: "Wikifunctions returned a failed response: Could not acquire WASI runner within time limit" and "Wikifunctions returned a failed response: No matching lexeme for item in language" and "Unable to render this fragment due to an unknown error."
You state "As for the beta release, it's impossible to debug or improve without community content, so I'm not sure what you'd have the WMF do." which is absolute nonsense. You don't do a public release of such extreleky buggy software, and you don't call it a beta either. The errors found so far are not edge cases where mass testing is necessary, but things a developers + QA team should easily have found. WMF should, for a $6 million + project, have some people on board who understand what this project is intended for and can test it before it is released as a beta. The release of a severely immature project where even the most basic fundamentals are being questioned is irresponsible. Then again, the decade-long development seems to have been irresponsible as well. Fram (talk) 10:19, 29 March 2026 (UTC)[reply]
Fram, you have more than enough examples now. Item 17 is disastrous and tells me that the entire system needs a rewrite following a redesign of the architecture. But that would be throwing good money after bad. I predict that there will be no remedy for this project anytime soon. Once the underlying software architecture has problems 1 million bandaids placed on it will be no cure. Yesterday, all my dreams... (talk) 12:32, 29 March 2026 (UTC)[reply]
None of these problems are architectural. All of these are the result of the work of a few (like less people than that participated in this topic) community contributors. Feeglgeef (talk) 14:17, 29 March 2026 (UTC)[reply]
So there is no Wikidata item for "is a" in French, but this thing will be able to handle translations to languages with very few editors somehow? And "it knows how to say the words in Dutch", er, no: "the" (or "is the") is English, not Dutch. Again, it can't even translate that most basic building block to a language with a large editing base. As for 19, I have no idea how "unknown error" and a failed time limit are the responsibility of Wikidata contributors, nor how a translation tool was ever tested by the developers if the most basic aspects are missing in French, Spanish, Dutch, ...
Someone at the WMF was aware that translation (and specifically translation to languages with very small user bases) was the intention of this tool, right? Because it sure doesn't look that way. I don't see how they can have tested this at an alpha-level to give it the green light to go to beta, if if can't even handle these basic things. Blaming it on Wikidata contributors is rather rude, the developers/testers should have added things like "is a" or "the" or ... in major languages (both the ones I just tested, but also completely different ones with other scripts and grammar) to Wikidata. I assume these people have some fluency in Wikifunctions and Wikidata editing, and in languages and translation? Seems a prerequisite for such a project... Fram (talk) 15:30, 29 March 2026 (UTC)[reply]
Question: How many people who work on Google Translate are linguists? Please answer to yourself before you read further. Answer: zero. We have all learned long ago that fiddling with linguistic constructs will end in one place: the shelf that holds the Aspirin bottle. So please do not assume that as a requirement. Their problems are much deeper and architectural in nature. They should have never used Wikifunctions, given that they are crowd sourced. Alas the key issue is that we can all huff and puff for ever but we have no control on what WMF does. So maybe we should all take an Aspirin and move on. Yesterday, all my dreams... (talk) 16:22, 29 March 2026 (UTC)[reply]
Google Translate is not entirely human-made though, but is based on computer-learning (statistics, deep learning and brute force basically). Abstract is based on "humans will build it all", which, while admirable, then requires humans with very specific skills. And "we can all huff and puff for ever but we have no control on what WMF does" is false, we have forced them to shelve things like Flow and Gather. Fram (talk) 16:49, 29 March 2026 (UTC)[reply]
I know exactly how G-translate works. Thanks. My point was/is that the crowd sourced paradigm works for text input but not for software. The world is moving towards automatic software generation now, so crowd sourcing will be inherently inefficient and error prone. But I think I have said enough now. No more comments from me here. You are right in objecting to the project but time will tell how much power you have over WFM. Cheers Yesterday, all my dreams... (talk) 22:57, 29 March 2026 (UTC)[reply]
How many people who work on Google Translate are linguists? Why are you using Google Translate as an example? Do you know how many mistakes Google translate makes when translating to and from languages other than English? For some reason English homographs throw it off completely. I've seen it do stuff like this where I asked it to translate a verb that means "to bear" and it came up with a word for the mammal. Even ignoring the fact that English is clearly used as an intermediate language here even though it isn't suited for this purpose (probably not by design but because of the way Google translate was trained), why on Earth is Google translate translating a verb as a noun in the first place? I think stuff like this shows how Frederick Jelinek's quote is outdated and is leading us astray at this point. Warudo (talk) 16:53, 29 March 2026 (UTC)[reply]
There is no implementation of the function in Dutch. The Abstract Wikipedia team has not added an implementation in Dutch because the community is responsible for creating the function in Dutch, and nobody has created the function in Dutch.
Essentially, how the current English implementation is to string together the first concept with "is the" with the second concept with "of" with the third concept. The function can get the Dutch terms for the concept, but it does not know how to string the words together because nobody who speaks Dutch has told it how. This is not something that the WMF can magically fix. Eventually, when the project is older than a week, somebody will implement it in that language, and in Malayalam, and Dagbani, and Massa, and Southern Altai, and Dusun. Feeglgeef (talk) 21:49, 29 March 2026 (UTC)[reply]
Please see my last response to Fram. Anyway, time to cool off and move on before someone busts an artery here. You will be glad to know that I shall make no further comments here. Now, in what language shall I say goodbye? Yesterday, all my dreams... (talk) 23:02, 29 March 2026 (UTC)[reply]
"when the project is older than a week"? It's a decade old or thereabouts, Wikifunctions specifically was created in 2020 and launched in 2023. But sure, some Southern Altai Wikipedian will go to Wikidata to translate everything that is needed, then go to Wikifunctions to translate all necessary functions into the grammatically correct version of their language (assuming naively that the used function can be one-on-one transformed to one in their language for every use of it), just so they can then autocreate stilted article stubs instead of either writing them directly, which would require a lot less effort and give a lot more satisfaction, or using an online translation tool to translate an existing Wikipedia article to give them much easier results. Totally realistic. Fram (talk) 07:32, 30 March 2026 (UTC)[reply]
When I go to this totally not-alpha project, to the page we are discussing[39], and click on "defining role sentence in English as string" (which should apparently go to abstract.wikipedia.org/view/en/Z28109), I am taken to the Abstract Wikipedia Main page[40]. Please explain to me again how this has been sufficiently tested and was ready to be opened to the wider public? Fram (talk) 08:39, 30 March 2026 (UTC)[reply]
"by putting several sentences into a single paragraph, the paragraph as a whole is being run, may cause time-outs, and will be cached. Instead, if, for now, you put one sentence into each fragment, caching and evaluation can be more spread out and should allow for more content. Eventually we want to fix that"[41] Gee, why would you fix the bug where putting more than one sentence into a paragraph makes it even more likely you will get a timeout error? Fram (talk) 15:55, 30 March 2026 (UTC)[reply]
Probably a few years of pointing out both the immediate and the fundamental issues. The work of developers, testers and product managers. Once the grant and endowment money stops flowing, and some quarterly or yearly goals can be checked on some paperwork, the drive to continue this will stop. At best/worst to keep whatever exists at the time running and let some volunteers play with it for a few more years before completely stopping it (see the soon to be closed down Wikinews). At least with Gather, Flow, ... we could point out that it was actively, directly negatively impacting enwiki (and other wikis): here it is only money and developer time disappearing down the drain. Fram (talk) 14:16, 31 March 2026 (UTC)[reply]
For what it's worth I would like to see them continue as the issues pointed out do not seem to be systematic (with the platform design) but an incredibly horrible implementation of it. I do agree that the state of the project seems at best alpha. Aaron Liu (talk) 14:37, 31 March 2026 (UTC)[reply]
The systemic issue is the belief that English grammar rules can be copied one-on-one to all other languages. We have e.g. functions for "use this the" and " use with a/an" and "use without either", which even within English is problematic (e.g. sometimes you need X is the capital of Y, and sometimes X is the capital of the Y, like with United Kingdom): but in other languages half the cases of a certain English function may use one construction, and the other half uses another construction, and this needs somehow to be built into the simply English function. I'm simplifying things here, but I hope yo get my drift.
Purely on a word level this whole construction works somewhat theoretically, but requires a massive amount of work which is exactly the problem for the small languages where this is supposedly built for. On a sentence/paragraph level though, I don't believe this will ever work (for simple cases for related languages, yes, but not in general). If this is pushed through regardless, we will probably end with new Scots and Greenlandic version catastrophes, but then on a larger scale. The setup and performace issues are just the icing on the cake. Fram (talk) 15:05, 31 March 2026 (UTC)[reply]
The ideal would be to store everything in context-free language, and then generate sentences in the target language by applying a set of rules. When I was a grad student in Linguistics lo these many years ago I wrote my dissertation on one aspect of Deep structure and surface structure. From my experience trying to figure out what some of the rules are in (my idiolect of) English for a limited subset of syntactical structure, it will take a very large and hard to maintain set of rules with extensive exceptions just for English. My mind boggles at the concept of doing that for all the currently spoken languages of the world. Donald Albury16:35, 31 March 2026 (UTC)[reply]
Indeed. At the moment, they produce the article [42] "New Jersey is an U.S. state." I presume the "an" comes from an "an before a-e-i-o-u" rule, which doesn't deal with the many exceptions to that rule. And this is a very simple example, in the main development language. Fram (talk) 16:45, 31 March 2026 (UTC)[reply]
The systemic issue is the belief that English grammar rules can be copied one-on-one to all other languages. You'd think that people would have learned from the failure of this approach when it was applied to Wikidata. Some editors wanted a property to express the relation "X is the mayor of Y". So they just made a property called "of". They then found out that the property was not only difficult to translate to certain languages but it also evolved into a monster that modeled many different, sometimes contradictory relations (which is kind of bad when the whole point of a database is to be machine readable) and it ultimately required a huge effort from the community to get rid of it.
Yet now, the abstract Wikipedia editors are doing the same things, defining their functions in terms of English grammar constructs and not the underlying logical relations those constructs represent. Warudo (talk) 17:21, 31 March 2026 (UTC)[reply]
All of these rules assume that an English grammar rule is also 1 rule in another language. "Article-less instantiating fragment" will sometimes need to be translated with, and sometimes without an article (even if the remainder of the grammar is the same). If this can be done with one function, then there was hardly any need to have different functions with or without article in English surely? And this is a very simple and basic example. So how is this solved? Fram (talk) 20:28, 1 April 2026 (UTC)[reply]
Article-less does not mean what you think it means here. The name is confusing and should probably be changed, but, for example "Golf is a sport" and "El golfo es un deporte" (both use article-less, despite the fact that the latter has an article) have the same meaning, but "A bird is a dinosaur" and "(The) bird is a dinosaur" have two very different meanings, even if, say, Bulgarian does not make the distinction. The distinction between article-less and article-ful is not actually articles. Feeglgeef (talk) 20:37, 1 April 2026 (UTC)[reply]
So if you start from an article which doesn't make a distinction, and go to a language that does make a distinction, you're screwed? If in your example the base language would have been Bulgarian, and you went to English, sometimes the Bulgarian function should give "the" in English, and sometimes "a", which depends on context. And all of this is still between very comparable languages basically. If the base article is for some sentence / meaning "article-less" and the target language "article-full" (or vice versa), you have a problem, no matter how you call these functions. Fram (talk) 20:48, 1 April 2026 (UTC)[reply]
I get the feeling that Feeglgeef is a little out of their depth here, but there's nobody with any decision-making authority at the WMF willing to rescue them. Phil Bridger (talk) 21:52, 1 April 2026 (UTC)[reply]
Based on your replies in this thread, it seems you are unwilling to assume good faith of either your conversational partners or the functionaries (pun intended) of the wiki in question. Why not just ignore it, if you feel it is consigned to failure? Arlo James Barnes19:09, 11 April 2026 (UTC)[reply]
You actually don't "start from an article which doesn't make a distinction", because all Abstract Wikipedia articles are supposed to be abstract. All articles are required to make the same distinction and all distinctions necessary for every single language (even if some languages ignore them) because they are all written in abstract language. There is no English or Bulgarian base, nor translating here. Feeglgeef (talk) 22:07, 1 April 2026 (UTC)[reply]
That, again, makes no sense. Because in English, "a bird" and "the bird" have two different meanings (but refer to the same Wikidata item), you need a different function than for "golf" (the sport), which has in English one meaning for that Wikidata item. But still you claim that the functions, the whole approach, are language-independent, as if these issues in English are the same across all languages for the same words. If Abstract Wikipeda were truly language-independent, you wouldn't need the article-less and article-full functions. And that's still only at the word level, and doesn't go into sentence- and paragraph structures and countless other quirks, irregularities, ... Anyway, it looks so dumb that after all this time, apparently there isn't a function yet to start sentences/articles with an article; we get things like "Bible is a religious text." for an article specifically about the Judeo-Christian Bible (not about the general word). And finding out how things actually work for Abstract articles is very opaque as well, I have no idea where the "suns" instead of "stars" comes from in [43] "Stars are sources of light. Stars contain metals. Suns shine."
Oh well, the WMF team doesn't respond here, but they seem to read it, as some of the most stupid errors get fixed after they are reported here at least. Fram (talk) 07:44, 2 April 2026 (UTC)[reply]
Wikipedia has articles about more than 20 million topics in more than 300 languages. But none of these languages alone allow access to the knowledge about these 20 million topics (...) Abstract Wikipedia does that without relying on AI. Each step of the way remains under human control, and is accessible and editable by the volunteers. I doubt volunteers will create articles about 20 million topics in "this thing" (and with 108 active editors, as there are now, it seems completely impossible to arrive at any place).
Looking at this article, it seems that a software-generated summary (yes, there is software other than AI) automatically combining some data from all language editions of Wikipedia, plus Wikidata and Commons, and using machine translation when needed (for machine translation, AI usage is usually not bad, and free and open source AI software also exists), would do a far better job.
In addition, if the point is to avoid AI, I don't understand why it says "Generated text" (who generated it?). Sorry if I am too critical (of course, I appretiate the efforts of the people who are working on the project), but I don't believe this adds anything new to the Wikimedia ecosystem: it looks as made for consumption by a machine, not by humans, so maybe it would be better if it was also mostly machine-generated.
The idea of joining the knowledge from all Wikipedia language editions (plus Wikidata and Commons, and, for some articles, also Wikisource, Wikivoyage, etc) is a very good one (and one I had thought about many times), but I think that a "global search" feature with integrated machine translation, and some way to access the combined data from multiple sources, would be the only way to achieve that. MGeog2022 (talk) 19:46, 8 June 2026 (UTC)[reply]
I doubt volunteers will create articles about 20 million topics. Yes, exactly. There's no chance we ever surpass enwiki or other major language Wikipedias, as abstract articles take much more time to write than normal articles, and there's much less chance for onboarding new contributors.
In addition, if the point is to avoid AI, I don't understand why it says "Generated text" (who generated it?). Sorry if I am too critical (of course, I appretiate the efforts of the people who are working on the project), but I don't believe this adds anything new to the Wikimedia ecosystem: it looks as made for consumption by a machine, not by humans, so maybe it would be better if it was also mostly machine-generated. It was made for the consumption of humans who speak only small-to-mid sized languages.
Machine translation might be worth consideration for a future project, it's been used, for example, on Caesar DePaço to circumvent a court order, but writing content in an abstract (instead of concrete) language means we don't have to deal with information loss (see the whole "Google translate 100 times" thing).
If you click through the endless errors and finally try to see a translated article, you get monstrosities like "Ein Äpfel ist eine Frucht."[44] or even worse " Bisexuelles lieben Fraus. Bisexuelles lieben Manns."[45]
People from the WMF, could you please clarify: before releasing this as a supposedly beta product, which tests did you run? Which articles have you created, with which functions, and tested for which languages? Fram (talk) 13:16, 8 April 2026 (UTC)[reply]
@Sannita (WMF): as someone who seems to be closely involved, but of course feel free to put this through to whoever is better placed to answer this. I also notice that most activity on Abstract seems to come from an editor who was indef blocked on enwiki for CIR / timewasting, and is now running some AI-generated tool to create non-working pages (like this 193K monstrosity[46]-) and to change working pages (no matter how bad they were) into non-working ones (e.g changing this into this ("Wikifunctions returned a failed response: Error in evaluation"), across a lot of pages. While I think the project should be abandoned as a waste of time and money, it shouldn't be done by mass-vandalizing the work of the editors there. Fram (talk) 16:30, 10 April 2026 (UTC)[reply]
Thanks for your comment. A discussion has been opened, and the bot runner decided to pause their edits. We'll sort this out the wiki way. Sannita (WMF) (talk) 21:59, 10 April 2026 (UTC)[reply]
@Fram We did some limited tests in a controlled environment, but doing so can only help you so much in identifying potential problems. We are learning a lot by releasing the beta project (because this is still a beta), and we'll improve from there. Sannita (WMF) (talk) 10:28, 11 April 2026 (UTC)[reply]
Thanks, but no, this is not a beta, this is barely an alpha, the thing is unworkable for all but the simplest sentences, terribly slow, had the most basic errors when released. Using volunteers as cheap/sheep testers on a $6 million+ project which hasn't been thought through, hasn't been tested, and has in its utopic, unrealistic ideals been overtaken by reality anyway, is old school WMF which I hoped had been left behind after previous such failures.
After the omnipresent "Reached max retries. Try again later.", you get a plethora of errors. A 2-sentence "article" gives "Wikifunctions returned a failed response: Reached time limit in orchestrator", basic English words give "Wikifunctions returned a failed response: No matching lexeme for item in language" (but this will work for languages with barely any editors somehow), other articles give "Wikifunctions returned a failed response: Error in evaluation", "Wikifunctions returned a failed response: Could not acquire WASI runner within time limit", "Wikifunctions returned a failed response: Reached rate limit in orchestrator"
And the things that do "work" give results like "Australian continent is a continent in the Earth. Australian continent contains Australia." (German translation of that last line: "Australien contains Australien.") Or the extremely basic issue that when you translate an article, you would expect the title of the article to be the first thing that gets translated, even in alpha-stage. No such luck. This thing is supposed to be used to create articles and translate them into manu languages, but not a single decent example has been produced so far. A "beta" product which simply can not produce an acceptable end product just isn't tested to even the most basic standards and should never have been released. And a project where the actual requirements don't seem to have been thought through, and where the results (if the wanted end result was ever reached) would probably make the Greenlandic and Scots disasters look like minor blips, should have been stopped much, much earlier, before so much money and time was wasted. Fram (talk) 17:44, 11 April 2026 (UTC)[reply]
The wrong way
I just don't get how they are going along and spending money on something so ill-thought out and poorly executed. Let's ignore for now the basic questions of "is this feasible, which competencies or expertises do we need to think this through, what is the best approach", the slight issue that reality (LLMs) has somewhat changed the whole environment this needs to be thought about, and the basic recurring problem that a completely untested, very buggy environment has been released as a beta for everyone to play with without any guidance. But why are they (WMF and editors) now going further with this in the most inefficient way possible? Everyone creates whatever they like, 99% of what is being made is absolute rubbish that serves no purpose at all. People are creating one- or two-sentence stubs for all countries which all have the same issues.
A logical, productive way of dealing with this project (apart from the most logical one of pulling the plug) would be to start with one article, take e.g. the lead from enwiki (or dewiki or whatever), and build the necessary structure (Abstract + Functions + Wikidata) to create this and translate this in 5 wildly different languages. Step by step, sentence by sentence, until you have a basic set of functions for this kind of article, and have an idea if it will work.
Second steps might then be either testing the same for a related article (say, test 1 was a country, take another country and see if the functions are all transferable or if there are things you missed), or doing the same "build from scratch" for a different topic (say, a biography).
That way, you build a structure, a set of reusable and needed blocks you can refine later on, and at the same time learn a lot of "don't do this" pitfalls and issues. And after you have done this for the 5 or 10 most common types of articles, you actually have a tested, usable, beta environment (or you have realised it won't work at all, or it will work in theory but the work to get things right for a more obscure language isn't worth the hassle).
Instead, we get articles[47] directly using the function "English plural"[48], really useful for an abstract, language-independent project. Or more commonly "articles" consisting of random repetitive sentences like "Reproduction is a biological process. Reproduction is a type of process. A reproduction is a biological process. A reproduction is a creation. Animal reproduction is the part of of reproduction. Plant reproduction is the part of of reproduction. Human reproduction is the part of of reproduction."[49]
Oh well, at least I learned that "An information is a knowledge."[50] or "biseksualiteit ∈ {seksuele oriëntatie}" in Dutch or still "Bisexuelles lieben Fraus. Bisexuelles lieben Manns." in German [51]. Note how here and on all other pages, the actual title doesn't get translated? This is not something the article creators can help, this is something which should have been included by the WMF as a basic element (assuming they realised what Abstract Wikipedia was intended for) but is missing.
Anyone minimally familiar with the history of Linguistics or Computer Science as disciplines should be aware that the core premise of the project was investigated and discarded decades ago (and anyone who has studied at least one language that isn't super closely related to their native language should be able to quickly come to similar conclusions). There is no universal deep structure across languages. Why was this ever greenlit? This is about as useful as funding new studies in Lysenkoismsigned, Rosguilltalk05:51, 3 June 2026 (UTC)[reply]
New dashboard
The WMF has launched a dashboard to follow the progress of Abstract Wikipedia [52]. It has e.g. a list of articles which work in any language! Well, most of them have no actual text translated through functions, just Wikidata items without any sentence-building, so yes, these work, they just aren't articles... The ones that do try to have actual sentences and supposedly work are e.g. Brussels[53], full text "Brussels is the capital of Belgium." This gets translated as "Brussel is the hoofdstad of België." in Dutch, which isn't correct Dutch. "Bruxelles is the capitale of Belgique." in French is equally wrong, as is the German "Brüssel is the Hauptstadt of Belgien." It doesn't work at all in e.g. Romanian, Moldavian. Anyway, I guess the function "defining role sentence in English as string" should perhaps not be used in Abstract Wikipedia, and items which use it should not be said to be working in any language, as the naturally don't. Something like "list of cities in Belgium"[54] gives a result in English, and keeps running endlessly when I try it in Dutch or French. So not really "working". It looks as if not a single actual article can be said to be working in all or even most languages, making the dashboard rather meaningless. Fram (talk) 11:49, 8 May 2026 (UTC)[reply]
From reading the Abstract Wiki, it also seems like there is no way to utilize the past tense, which um… seems a bit critical in an encyclopedia. ExtantRotations (talk) 18:34, 8 May 2026 (UTC)[reply]
On the plus side, they have introduced endless repetition, which makes for much better reading. At the moment, the article for New Year's Day reads in full: "New Year's Day is a public holiday. New Year's Day is part of the public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, public holidays in Australia, and public holidays in Australia." Fram (talk) 12:10, 22 May 2026 (UTC)[reply]
Somehow, they have made this dashboard worse. It now has a section for "Articles ready to publish in English". What this means is "Wikidata Qnumbers we have created in Abstract but don't exist in enwiki", not that these pages are in any way either wanted in enwiki, nor that they are actually "articles" which are "ready". This includes things like [55] "Evaluating the biological validity of European river typology systems with least disturbed benthic macroinvertebrate communities", ne of the thousands (millions) of scholarly articles with a Wikidata entry, but also [56] Blake Lemoine, apparently a software engineer, where the complete "article" exists of three identical links to research.google, but the link gives a "page not found". Ih yes, this is so ready to be published to enwiki. Other "articles" we are apparently missing is [57]"interaction", full text "An interaction is an effect.An interaction is an effect.An interaction is an effect." Oh look, a Picasso painting we are missing[58]. Actually, no, we have it at Three Musicians (Picasso)
I don't even want to try to guess what the next section on the dashboard, "Quick wins in English", is supposed to be about. "Add a label to California"? "Pending fixes in English", explanation "All items where English is the blocker", e.g. "photon" needs a label.
Mind you, that's not even the most bizarre or optimistic thing on that dashboard. At the very bottom, there is a section for "Almost there — English is the only thing missing
Already usable in the most other languages. One English edit gives each near-universal coverage." Well, perhaps not. [59]Giza is not one English edit away from anything, Giza (or any Abstract "article") shouldn't use the function "defining role sentence in English as string" because "in English" is not really what Abstract is about.
While for English these things won't be published here and we see the problems from miles away, for small languages (the intended target) this is another dramatic Scots Wikipedia scenario waiting to happen, but this time pushed directly by the WMF.
According to the latest newsletter about Abstract, all that is left is improving Abstract and integrating it into language Wikipedias (the horror), but as of now, "Abstract Wikipedia can compose articles from functions on Wikifunctions". Bizarrely, despite this claim, not one actual article has been composed, only a few collections of loose, short, often ungrammatical sentences, which in a few cases can even be translated in even worse sentences in very few languages. But oh well, what can one expect from a newsletter which claims "Abstract article pages now show the label of the Wikidata item alongside the QID in the page title. " when in reality, for a week or so now, what is actually shown next to the Wikidata label is the letters "ltr" in grey. When you click on them, you get the text "copied!", and you have literally copied the text "ltr". Brilliant! Even things that barely worked before have since become worse, the page "Paul Cézanne"[60] now shows "<a href="https://abstract.wikipedia.org/wiki/Q17277950">The Card Players</a>" instead of the links to Wikidata it had. Also errors like "Reached max retries. Try again later. Retry" have reappeared.
Let's be clear: "Franz Schubert is a composer in Austria. Franz Schubert is a pianist. Franz Schubert is a teacher." is not an article. "Wikifunctions returned a failed response: Invalid key" is not an article. "Organism is a part of of population. Organism is a part of of group of living things." is not an article. "Roman Empire is an empire." is not an article. "2 is a small number." is not an article. "List of French artists is a Wikimedia list article." is not an article (why would anyone think that this is the kind of text wanted in any language wikipedia?) "August is a calendar month. August is part of the Swedish calendar, Swedish calendar, and Swedish calendar." is more than an article, it's a mantra. "A Citrus × limon is a useful plant." is the full article about the Lemon.
And the translations... "Organisme is an onderdeel van of populatie." is not a Dutch sentence. "2 is een ." is not a Dutch sentence. "Franz Schubert est un enseignant ou enseignante." is what you get when you start from English as the norm for all languages. "August is a calendar month. August is part of the schwedischer Kalender, schwedischer Kalender, and schwedischer Kalender." is supposedly a German article. "{citroen} ⊆ {nuttige plant}" is supposedly a Dutch article.
I clicked on random article, the first one I saw was Homer:
Homer is a poet. Homer is an author. Homer is a writer. Homer is a human whose existence is disputed. Homer is a conceptual character. Homer is the part of of Greek mythology.
What I don't get is, they don't have support for past tense yet. Whatever, they'll add it eventually, I hope. So, why are they making abstract articles that need it? Warudo (talk) 20:35, 1 June 2026 (UTC)[reply]
Partially reminds me of caveman speak: If horse go walk, cart also go walk. You see, force from horse leg on ground push on rock, then normal force push horse leg in opposite direction, cause horse to move small amount, for each time horse leg push on rock. Rope tied to horse neck move with horse, and is connected to cart with wheels. Cart wheel spins if moved in same direction as wheel is facing, which glide across rock, but still exert normal force due to gravity. Therefore, if horse go walk, cart also go walk.
For what it's worth, the Homer abstract article was created by the editor who did this. As harsh as it may be to say, this is the level of quality we are used to seeing from this editor, both here and in the abstract Wikipedia. Warudo (talk) 19:04, 2 June 2026 (UTC)[reply]
They were blocked for CIR/wasting community time and (how do I put this politely) I couldn't agree more with that description. Anyhow, most of the slop problems Fram is pointing to were caused by them, so I don't see how that justifies shutting down the whole project. Feeglgeef (talk) 03:51, 3 June 2026 (UTC)[reply]
Not true though. Going over the issues in my above posts, the "ltr" instead of the Qnumber is obviously a WMF technical mistake (and a failure of whoever wrote the newsletter). The "articles" I randomly picked: Paul Cézanne "2", August, the Picasso painting, New Year's Day, Giza, ... all not edited by that blocked editor. And there are plenty of articles I could have picked, I don't think "Australian continent is a continent in the Earth.Australian continent is a component of Earth's surface.Australian continent contains Australia." or its Spanish translation "(en) Australian continent is a continent in the Earth.Australia is a componente of superficie terrestre." (note that the middle sentence simply disappeared, perhaps a blessing) is an indication that the issues are due to one bad editor and not to a terrible project. Bisexuality, in German, is first an error and then "Bisexuelles lieben Fraus. Bisexuelles lieben Manns." Not touched by the blocked editor. this is not created by the blocked editor. The "Italian" article "Holy Week is a liturgical season. Settimana Santa is part of the anno liturgico." is not edited by them. Obviously it would be best if you mass deleted the embarrassing creations by that editor (full article: "A current is a current.A current is an electricity."), but it wouldn't solve any of the fundamental issues. Fram (talk) 07:37, 3 June 2026 (UTC)[reply]
And it's not like this is the only editor who writes articles about dead people. "William Shakespeare is a playwright from Kingdom of England." Has not been touched by that this editor either. Warudo (talk) 11:22, 3 June 2026 (UTC)[reply]
@Fram Thank you for the continued updates, which are rather amusing, if in a morbid way... Would you be interested in starting an RfC on Meta on putting an end to this madness? If anyone has any better ideas, I'd be happy to hear them. Toadspike[Talk]11:49, 2 June 2026 (UTC)[reply]
I normally don't edit Meta, and I fear that many people who hang out around there are more inclined to let such projects continue no matter what. Fram (talk) 12:17, 2 June 2026 (UTC)[reply]
For what it's worth I agree with Toadspike and would like to see an RfC on meta. It might be true that this bias exists there, but Abstract is such a one-of-a-kind, unmitigated disaster that I believe it would not apply in this case. Choucas 🐦⬛12:29, 2 June 2026 (UTC)[reply]
Not the right process; you're thinking of m:Proposals for closing projects.For what it's worth I think there's something worthwhile to come out of this; to resolve the fundamental problem the articles look to be moving towards using functions that express specific meanings rather than grammar. I definitely agree that the WMF is hopelessly overstating its progress, as Fram has meticulously documented.I would support some kind of discussion to make WMF be accurate when assessing the level of progress on the project. An RfC might be able to do that but I'm not sure if purely WMF communication matters can be subject to an RfC. In solidarity, Aaron Liu (talk) 12:40, 2 June 2026 (UTC)[reply]
I have some strong opinions about the content created by a couple contributors. This one was the original unattributed enwiki cop[y] Fram had originally mentioned. In addition to Csisc, there's also User:Immanuelle, who was blocked here for WP:CIR. Generally I think they share a need to do something now, though at this stage these contributions are unhelpful and frankly actively disruptive. Feeglgeef (talk) 23:45, 8 June 2026 (UTC)[reply]
Clarifications from WMF?
Coming from huwiki, I've been trying to understand the scope and progress of Abstract Wikipedia, and I want to say first that Frem's updates in this thread have been more informative than the project's own pages on Meta. Thank you for that.
That itself points to my concern. This is an enormous and complex undertaking with many moving parts. A project of this size depends on community buy-in, so it needs to communicate its scope, progress, and decision-making clearly and regularly. Right now I don't think it does. If you read meta:Abstract Wikipedia and its subpages, much of it appears out of date, and the current scope and state are not stated anywhere in a way an ordinary editor can quickly grasp. You could say they're rather abstract. Additionally the original project proposal did not lay out the alternative solutions considered for the individual problem statements, nor any cost-benefit analyses. From what I've been able to piece together there were more readily available approaches, that could have delivered usable results by now (not including the recent advancements of LLMs). Checking the pages and the Wikimedia Board minutes it is also unclear what changes of direction have been discussed or approved since the initial 2020 resolution, or under what criteria the project would be judged unfeasible to continue. This is important, cause this is a highly ambitious project that, without clear guardrails, could go on indefinitely.
In this thread serious concerns were raised, and it's shocking that so far no one from the project has responded to these. I can only add to those, I agree that the project cannot really be described as an "early beta": after reading through pages of Abstract Wikipedia documentation, I still have no idea how I, as an editor, could begin supporting the project and test Hungarian implementations.
Without a clear understanding of what is happening and why, community discussion is effectively blocked. So that this does not sink without a reply, I'd like to ask the project leads to respond:
Current state and scope: What is the precise, current scope and phase of the project? What is the progress on the tasks, which of these are done from the initial 30 months plan? What is still prototype or research?
Supporting a language: Is there a documented, step-by-step path for a language community to add or improve support for its language? Concretely, what could a non-English editor do today to help with testing?
Documentation: Given that the Meta pages appear outdated, is there another current, plain-language page stating scope, status, and roadmap? Could Meta be updated?
Regular review: Since the Board's approval (the resolution of 22 May 2020), what changes of direction have been discussed or approved, and by whom? Are there defined milestones or off-ramps, and what criteria would lead the Foundation to conclude the project is not feasible to continue? How does the Board assure itself that the project remains on track and worth its cost, and what would have to be true for it to decide otherwise?
Resources and partial wins: Approximately what has been spent on the project to date, and how is the continued resource commitment justified against other Foundation and community priorities? What concrete, independently useful results has the project delivered so far (with examples)?
And @NGunasena (WMF): if you could comment on, or connect us with someone who can say more about the Board's thinking and its insight into the project's actual progress (questions 4–5), I'd be grateful.
To be clear, I'm raising this in good faith, I want the project to succeed, and clear communication from the stakeholders is a precondition for the community to participate. Boro (talk) 11:32, 7 June 2026 (UTC)[reply]
Not WMF, but for #2, you could look at which functions are commonly used on abstractwiki (e.g. f:Z28016) and learn to contribute to them. I am aware this is a tall ask and if you want to, I could help you. In solidarity, Aaron Liu (talk) 14:17, 7 June 2026 (UTC)[reply]
Thank you for the offer, but it's a taller ask than it looks. Hungarian is an agglutinative language that uses vowel harmony. The simple "defining" structure you linked (X is the Y) does exist in Hungarian, but the neutral, encyclopedic version doesn't use a definite article at all, while the variant that does carries extra contextual meaning. So it's unclear which needs to be used here: match the intention or the definition? The correct rendering needs helper functions to get the morphemes right, and research groups in MT and linguistics are still working on tools to do this reliably for all possible cases. I'm not an expert in this field, so I don't feel comfortable writing semi-correct functions to make this work. I've already seen students pick up incorrect uses from AI output, so getting this wrong at scale could affect the language itself.
From the Meta page this seems to fall under "Task P2.9: Renderer for a language from another family". But I can't find any notes on whether that was evaluated, and with what results and to what extent, before moving forward with the project. As I understand it, the majority of its benefit is supposed to come precisely from supporting non-Indo-European languages, so checking more than one language family seems essential. Boro (talk) 20:10, 7 June 2026 (UTC)[reply]
My understanding of Hungarian isn't the best, but from what I remember, isn't just a rearranging of the words? So it'd be literally "Budapest Hungary's capital" (Budapest Magyarország fővárosa). Feeglgeef (talk) 21:09, 7 June 2026 (UTC)[reply]
Not quite, főváros is the base word, +a/+e is a suffix, that can change form based on the word: capital of → fővárosa (főváros), sibling of → testvére (testvér), older brother of → bátyja (báty), younger brother of → öccse (öcs), mother of → anyja (anya). Also all these sentences are valid, but subtly different in their meaning: (1) Budapest Magyarország fővárosa, (2) Magyarország fővárosa Budapest (3) Budapest Magyarországnak a fővárosa (with definitive article). Boro (talk) 22:03, 7 June 2026 (UTC)[reply]
If it doesn't use a definite article, then the output should not have a definite article. I think how this is supposed to work is that each function outputs the construct with the intended meaning no matter what the grammar is. In solidarity, Aaron Liu (talk) 18:15, 8 June 2026 (UTC)[reply]
I'm not WMF staff, but as a volunteer I'm one of the most active users on abstractwiki and a functioneer on Wikifunctions.
Currently, on the Abstract Wikipedia wiki, which is in beta, users are able to create basic stub articles that render in English and often other languages. Wikifunctions is no longer in beta and is generally usable, P1.1 through P1.13 and P1.18 though P1.19 are things I'm able to do on the wiki right now. The plan listed for Abstract Wikipedia is very different from what it seems is actually being implemented, so I can't comment on progress there.
Somewhat. I do believe we need much better documentation, but f:Help:Contents has a few pages that are good starting points. I have helped and am willing to help others with the process of creating localized versions of functions.
I don't believe so, unfortunately.
I'm not sure, as again I'm not WMF staff.
On results, we've seen some use by smaller-language Wikipedias and small-and-mid-sized Wiktionaries of using Wikifunctions like templates. As mentioned before, Wikifunctions is also useful on its own and has a large catalogue of functions.
"users are able to create basic stub articles" for extremely low bars of "basic" and "stub" (and "create" for that matter, many editors don't seem capable of this, the learning curve is quite steep).
" that render in English and often other languages. " Very rarely, actually. But feel free to give us a few examples of what you consider basic Abstract stubs and which languages they render in. Take for example Australia[61], which probably comes the closest to an actual article. When I try to translate it to German (and after a very long wait), I get 5 errors, and a mixture of German sentences, English ones, and mixed ones like "The Einwohnerzahl of Australien was 27614411 in 2025." Same when I try it in French, 6 errors (4 different ones), mixed languages. But at least in English you get an article that reads as if some dumb robot compiled it, with the first five (obviously very short) sentences starting "Australia is", and ending with varied but hradly correct ones like "Melbourne is the most population urban area in Australia." Or let's look at the most recent one you created, Labrador Retriever[62]. Full text: "A Labrador retriever is a dog." Capitalization is hard apparently. Dutch translation: "{labrador retriever} ⊆ {hond}". Another one you created, 6-7[63], doesn't even work in English ("Wikifunctions returned a failed response: Reached recursion limit in orchestrator") Mount Everest[64]: "Mount Everest is a mountain of China–Nepal border.". Frenglish: "Everest is a montagne of frontière entre la Chine et le Népal." Swedish: "Mount Everest is a berg of ." Spanish: "Everest is a montaña of Frontera entre China y Nepal."
So no, both creating decent stubs and rendering them in other languages doesn't really work, even when one of the most experienced Abstract editors creates them. Fram (talk) 09:32, 8 June 2026 (UTC)[reply]
It's crazy that the resources of the WMF are going into this hopeless and pointless black hole instead of fixing actual problems that the community have been highlighting for years. It would be fun if it wasn't tragic Ita140188 (talk) 09:42, 8 June 2026 (UTC)[reply]
Yes. It's time to pause development on Abstract (to avoid the embarrassment of cancellation) and redeploy the engineers to process community tech requests. That's not as good a result as retaining the staff with relevant experience, but it's a start. Certes (talk) 13:01, 8 June 2026 (UTC)[reply]
You're a one trick pony, Fram. We get it. Some of the articles on Abstract Wikipedia are not great. But if one billion useless articles were added to the English Wikipedia, I wouldn't call for it to be shut down. The fact that you can find articles that look bad doesn't mean the project needs to be shut down. As for your examples, they do not disprove (in fact, they prove) my intentionally conservative statement, users are able to create basic stub articles that render in English and often other languages (emphasis mine). Feeglgeef (talk) 15:07, 8 June 2026 (UTC)[reply]
If you would look at article after article on enwiki that looked like this, you would be right to call for it to be shut down though. And it's not a case of "I can find articles", I picked recent ones created (or in the case of Australia edited) by you specifically, as last time you complained that some examples came from an editor who is blocked on enwiki (but not on Abstract).
But I see that you consider these rather dreadful examples as "basic stubs" and the abysmal translations as evidence that they "often render in other languages" and provide no better examples, so I presume that this "one trick pony" (WP:NPA) somehow found representative examples and you won't point to some better Abstract articles instead. Fram (talk) 15:42, 8 June 2026 (UTC)[reply]
Firstly, I'm sorry for the "one trick pony" comment. I had meant it as a comment on the lack of variation in your evidence, and should have framed it as such.
Here's a decent article, abstract:Q1186. It's a basic stub (the information would be useful) and renders correctly in both English and Bangla, thus meeting all of the criteria I gave. Feeglgeef (talk) 16:25, 8 June 2026 (UTC)[reply]
Thanks. Why does it give the population in 1961? It's less than half of the current population, so hardly good information to include here. Fram (talk) 16:31, 8 June 2026 (UTC)[reply]
That's especially weird considering that not only does Wikidata have a figure from 2017 but it is also marked with preferred rank. Warudo (talk) 16:33, 8 June 2026 (UTC)[reply]
I've fixed it such that it will use preferred statements first. Unfortunately, despite the fact that I've requested it multiple times, there's no way to fully clear the cache, meaning the Kerala article is stuck with the old value. But it will work for new instances, like Illinois, which I just created. Feeglgeef (talk) 16:48, 8 June 2026 (UTC)[reply]
Seeing the working examples led me to think that, at the reader level, this is something that ArticlePlaceholder was already capable of: surfacing Wikidata facts about a topic with no local article. For topics that do have an article, inline Wikidata item calls can keep those facts current on its own (though the editing experience could be smoother). All in all, I don't see why sentence generation is worth all this effort, when easier paths were open to achieve essentially the same benefit. Boro (talk) 22:37, 8 June 2026 (UTC)[reply]
There're certain things only articles can do, like document the history of how something happened. I don't really see any advantages of ArticlePlaceholder over just referencing Wikidata when you do need to switch wikis. In solidarity, Aaron Liu (talk) 01:51, 9 June 2026 (UTC)[reply]
You described yourself as one of the most active users on abstractwiki and a functioneer on Wikifunctions, so I do not find it unreasonable for Fram to look at your articles and point at the glaring and massive issues there. Maybe being able to find articles that look bad means little, but are we even able to find articles that look good though? Or is the bar so low that "good" by Abstract Wiki standards just means "not broken in a thousand obvious ways"? You have to admit that from an exterior point of view, things really look dire, and the fact that there is not even more than one outdated meta page in terms of documentation does not bode well in terms of perspective. And that is even without getting into the immense issue that the basic premise of the project is based on disproved linguistics, as has been pointed out elsewhere. Choucas 🐦⬛16:04, 8 June 2026 (UTC)[reply]
I do agree that things might look dire from an external point of view, but, as I've been trying to show, Abstract Wikipedia is a viable project. It just needs more time, and, ideally, better technical support. I do agree with those above that Dr. Vrandečić is overstating our progress. Feeglgeef (talk) 16:56, 8 June 2026 (UTC)[reply]
Personally I think it's worthwhile to explore this avenue with the aim of making imperfect 'universal stubs' that serve as placeholders while small wikis are developing, but the design of abstract wiki is frankly amateurish, the team appear to be incredibly out of their depth. Why has wikifunctions been primarily based on English/Indo-European languages when there'll be practically no new wikis in languages closely related to English? Do we know if any professional linguists were consulted (the mastermind behind it sure as hell isn't one)? Why was this not done by experts? How on earth has $6 million been spent? On what? How has this gotten through so many checks and meetings? Kowal2701 (talk, contribs) 21:08, 8 June 2026 (UTC)[reply]
I'm open to the possibility that there could be a way to write articles using a lingua franca that is amenable to translation to many different languages. But I have strong doubts about Abstract Wikipedia being viable as a crowdsourced project using Wikifunctions as the lingua franca. isaacl (talk) 00:17, 9 June 2026 (UTC)[reply]
The lack of documentation means people have to (re)invent the wheel when they want to write things and, at least some of them are not good at it. Consider abstract:Q246463 where the editor who made it wanted to use a pronoun instead of repeating the name of the article subject, so they passed it (Q6091500) to the function that generates the second sentence. There are two problems with this. One, it leads to the awkward phrase "of it" instead of "its". But more importantly, it doesn't work for languages other that English because grammatical gender is different between languages. What is the equivalent of "it" in French, which doesn't have neuter? Or worse, what would happen in a language where neuter exists, but the word for "shrine" is not neuter? Warudo (talk) 17:08, 8 June 2026 (UTC)[reply]
This is a problem as well. Wikifunctions (and, by extention, Abstract Wikipedia) has a very steep learning curve, so we have a few users who understand it deeply and everyone else, who barely understand it at all, which makes it very hard to find contributors, whereas the English Wikipedia has a remarkably flat learning curve and a very high ability to specialize. Feeglgeef (talk) 17:19, 8 June 2026 (UTC)[reply]
This is the part that makes me ambivalent about the WMF's involvement. I think it's worthwhile doing research in understanding ways to capture information based on commonalities in language. It's not clear to me, though, that crowdsourcing is an effective way to generate an encyclopedia of articles written in a lingua franca with a programming-like syntax. Without the crowdsourcing aspect, I don't think the project is a good fit for the strengths of the Wikimedia Foundation. isaacl (talk) 17:42, 8 June 2026 (UTC)[reply]
I'm reading through this again and that "Dutch translation" in particular scares me because of how wrong it is on multiple levels. First of all, is returning math notation really helpful? Wouldn't an error be better here so there's no illusion of support? But more importantly, no matter how smart the person who came up with this workaround felt, it is still wrong! "{labrador retriever} ⊆ {hond}" means that the singleton set {labrador retriever} is a subset of the singleton set {hond} which is obviously false. It should be "labrador retriever ⊆ hond" or, more explicitly, "{x|x ∈ labrador retriever} ⊆ {x|x ∈ hond}". If after all this time, people who work on this stuff cannot handle what are essentially instance of (P31) (∈) and subclass of (P279) (⊆) correctly how can we expect this project to ever succeed? Warudo (talk) 10:35, 13 June 2026 (UTC)[reply]
Hello @Boro, and thank you for your good faith inquiry.
I agree with you that the project pages for Abstract Wikipedia could use an update. We will spend some time in the near future to do so, thank you for pointing that out. We have mostly focused our progress report through our weekly newsletter. We have been keeping the newsletter up for more than 250 editions now, and I am sure you would be able to find most of the answers to your questions in the updates. But I admit that sorting through so many newsletters to find the one answer you are looking for is not the best solution.
Here is the current status of the project, in a very short overview:
Wikifunctions launched almost three years ago (July 28, 2023). The project has a growing community, and there are now more than 4000 functions created. The speed of function creation is increasing.
Wikifunctions function calls can be embedded in almost all Wiktionaries, as well as Dagbani, Bengali, Igbo, Hausa and Malayalam Wikipedia. This allows editors to call a centralized store of functions to produce outputs, instead of having to create and maintain them locally in each wiki. An example is here, where the German declension table comes from Wikifunctions. If more Wikipedia language editions would like to have this functionality, please let us know. We are currently prioritizing article integrations and are planning to revisit embedded Wikifunctions at a later date, but let us know your feedback.
From Wikifunctions, we are able to access data from Wikidata. This includes most statements about items, and most lexicographic data. This allows the community to create functions using the rich lexicographic data in Wikidata, or using population numbers from Wikidata directly, etc.
Abstract Wikipedia is in early beta, and we made it available live to enable learning, testing, and iteration. We want to co-create this project with our communities, including on how NLG functions evolve. Here’s an example that was just working as I write this, a short article about the year 1234 in English and in German. We also want to see how the system performs with real traffic to make it more stable and responsive. We are listening to feedback and releasing improvements every week.
Now you might object that the Hungarian article about 1234 is better than our abstract article (for example, it doesn’t call 1234 a Gregorian year even though it’s a Julian one), and you’d be right. Our scope, however, isn't to replace existing articles, but to fill in gaps where they currently exist, particularly in language editions with a smaller community.
In a few months, this will be possible when language communities will be able to integrate Abstract Wikipedia articles into their Wikipedias. We hope by then such errors will be fixed, and more content will be possible. This will be the last major piece of the puzzle, and once in place, we will work closely with communities to discover missing capabilities, bottlenecks, and potential for improving the contributor interfaces. We will create feedback loops to ensure the product evolves to support community needs. We will assess how effective Abstract Wikipedia is at addressing multilingual content parity, and make further decisions on next steps from there.
We are fully aware that this is only addressing a small part of the questions here. Our suggestion is that we will summarize the constructive criticism and concerns to kick off a discussion page on Meta, and answer the questions there. This discussion here has surfaced great suggestions and criticisms which we want to address. We want to take this input seriously, but it will take some time, and we can then continue this conversation on Meta, where it is visible for all communities.
"making it much easier to start a local version of the article, instead of writing it from scratch or translating from another language. " That I doubt. It's not as if for these smaller languages, things will magically work if you have the right Abstract article and the right functions. Even completely ignoring the language structure issues (a pretty big issue in itself), people will need to navigate Abstract and Wikidata, add labels and lexemes, and who knows what else. Even a simple "article" like the rather useless 1234 linked here, gives 6 errors when translating to smaller languages like Nahuatl (and 2 errors for French), with the errors not really helping to knw what needs to be done.
Why you believe this can be integrated in any Wikipedia in a few months time is beyond me, sounds more like a KPI that needs to be met than an actual good plan. Publishing one or two symbolic "articles" from Abstract to some language and then celebrate this as a major milestone and a proof that it works, when in reality next to nothing has been achieved and questions about the fundamentals are completely ignored, does not give any confidence.
As for the Wikifunction, it looks to be wrong or at the very least oversimplified. A rather different table is given e.g. here or here or here.
Having basic information wrong - as in the 1234 example or several other examples listed here - is not filling in a gap on smaller projects it's spreading misinformation. I would not expect information from abstract to be 100% correct. Or even as correct as the average enwiki article or the average article on some other large project. But I would expect it to have basic information correct. And I would expect it to be reasonably intuitive for someone who spots an error to be able to correct it, which if I understand things correctly, would mean some kind of easy connection back to Wikidata. Best, Barkeep49 (talk) 15:59, 9 June 2026 (UTC)[reply]
How is that a easier way to populate articles for smaller languages compared to automatic translation from a bigger language and basic copyediting? It seems to me this would require a lot more work for a much worse result compared to the basic way that worked until now Ita140188 (talk) 07:59, 10 June 2026 (UTC)[reply]
They seem to have the wrong idea that when you have an abstract article and working functions, all you have to do is change the language and you have an article. Without even going into the grammar issues with many languages, it ignores the work needed in Wikidata to get everything you need for a certain language. Hence, in the 1234 example given, the 2 errors for France and the 6 for Nahuatl. It also ignores the complete instability of Abstract: if I go to 1234 (in English) now, instead of the text I saw yesterday I get "Wikifunctions returned a failed response: Invalid orchestrator result". Finally, it ignores that probably you will find more people interested in actually writing articles in their language, than people navigating 3 or 4 environments (Abstract, Functions, Wikidata, and Wikipedia) to copy someone else's creations, certainly when they can (for many, not all languages) much more easily copy creations to their language through online translation tools.
The only use case where I see this making sense is from a push-concept, where people from Abstract "push" translations (in languages they don't understand) to all Wikipedia languages where a certain topic doesn't exist yet. This obviously is a disaster waiting to happen, and should be opposed by all possible means. Fram (talk) 08:16, 10 June 2026 (UTC)[reply]
Even for the example at wikt:hr:Wort this is painfully useless at scale, since the construction and further editing of {{#function:Z29055|L2206|}} requires knowing that there is a Wikifunctions page called f:Z29055 and a Wikidata page called d:Lexeme:L2206. It is abhorrent that instead of doing something along the lines of mw:Multilingual Templates and Modules, millions of dollars from the Endowment (source here) are being spent on this website that’s extremely hard and annoying to use, and is impossible to edit without JavaScript. stjn15:05, 10 June 2026 (UTC)[reply]
@Sannita (WMF): can you give us clarity if there are future funds being planned to be sunk/invested into this project? Like many people above, I'm sceptical this can ever work at scale, and feel that small communities deserve better. In solidarity, —Femke (talk) 🐦 16:08, 10 June 2026 (UTC)[reply]
To be fair, there's no good reason to call {{#function:Z29055|L2206|}} directly from mainspace. Functions that editors will use often should be wrapped in templates precisely so editors don't have to memorize the ZID. As for the LID, you can open Wikidata on another tab and look up the lexeme to get its ID. It doesn't sound that bad. Warudo (talk) 16:14, 10 June 2026 (UTC)[reply]
I think if someone provides that as an example of the potential usefulness of Wikifunctions, I am going to judge it on its merits. And the merits here are entirely unconvincing (what you are describing in itself is extremely tedious), especially compared to investing in the less pie in the sky ideas that you can use the regular editing interface for (Wikifunctions and Abstract Wikipedia in themselves are a good example of how badly the website would be run if WMF developers ever forgot that to truly serve knowledge to everyone, we need to be HTML-first). stjn18:11, 10 June 2026 (UTC)[reply]
Clearly not. I can't believe that there is nobody that can say anything useful here, so can only conclude that the non-reply is because they have been ordered not to communicate with us plebs. What do we know anyway? Phil Bridger (talk) 16:42, 18 June 2026 (UTC)[reply]
@Phil Bridger, as of this message in this thread you have made nine comments. With them, you have managed to: - Imply every WMF employee answering about Abstract Wikipedia would be engaging in bad faith because their salary depends upon not fixing issues; - Suggest that the WMF workforce is so lazy that the place would run better after firing half of them; - Belittle (twice) an editor who made the error of trying to address your concerns in good faith; - Dare any of the hundreds of WMF employees to come spar with you; - Suggest their limited answers are actually due to a marching order because they despise the community. I want Abstract Wikipedia, a flawed project based on an erroneous assumption and no community to carry it, to be abandoned shortly as much as anyone here, including you presumably. I also think communicating with the community should be a bigger part of the responsibilities of WMF employees. Nevertheless, I do not believe dealing with your constant, pointless, and toxic abuse is part of that. Either engage in good faith to find solutions, or control yourself. If what you need is a place to vent, find another one, because aside from lashing out and poisoning this already heated conversation further, you have accomplishing nothing. Choucas 🐦⬛19:24, 18 June 2026 (UTC)[reply]
Thank you. I'm operating in good faith here. Everyone here wants what's best, and, even without AGF, we wouldn't have spent countless hours contributing to Wikimedia projects if we didn't. Feeglgeef (talk) 21:24, 18 June 2026 (UTC)[reply]
Thank you. However, I get the feeling that Feeglgeef is a little out of their depth here, but there's nobody with any decision-making authority at the WMF willing to rescue them wasn't particularly kind, nor did it have anything to do with the merit of my argument. I understand that this community has a poor relationship with the WMF (I don't particularly like them either!), but that doesn't mean that Abstract Wikipedia has zero potential in any form, and just because I believe in that potential doesn't make me a mindless WMF droid. Feeglgeef (talk) 21:59, 18 June 2026 (UTC)[reply]
@Feeglgeef, @Phil Bridger Can both of y'all take it down a notch. Calling folks mindless WMF droids or insinuating that they are lazy or bad faith assumption because they have been ordered not to communicate with us plebs is definitely not okay. Sohom (talk) 07:21, 19 June 2026 (UTC)[reply]
True, but the people in charge of the project posting halftruths at best and then ignoring all follow-up questions isn't really okay either, and causes the irritation that shines through in some ill-tempered remarks here. Fram (talk) 07:36, 19 June 2026 (UTC)[reply]
I have my own misgivings that roughly align with yours (I've tried contributing to Abstract Wikipedia and found it extremely hard to do so -- much harder than the cost of machine translation or even writing something from scratch in my native language). However, I don't think Sannita is talking in half-truths, I think WMF (as an org) does believe that they can create a system that can: "make it much easier to start a local version of the article, instead of writing it from scratch or translating from another language." and the approach they are taking is to first build out the whole pipeline first and only then measure whether operating Abstract Wikipedia causes production outages, whether or not editors find it easier to write articles in Abstract Wiki-lang (for the lack of a better term) and whether the effort of learning to write Abstract Wiki-lang is worth the trade-off of being able to write a few dozen linguistic rules (or whether that is even possible at scale). cc @Femke's call out of whether future funds will be invested, my understanding is that the team is still on grant runway and my understanding is that they do plan on measuring whether or not Abstract Wikipedia is viable this year (actually maybe @DVrandecic (WMF) or @ATsay-WMF would be better placed to answer that specific question?) Sohom (talk) 08:20, 19 June 2026 (UTC)[reply]
Comments like "We did some limited tests in a controlled environment, but doing so can only help you so much in identifying potential problems. We are learning a lot by releasing the beta project (because this is still a beta), and we'll improve from there. " are half-truths at best, with words like "limited" or "beta" doing an awful lot of heavy work here.
"Abstract Wikipedia is in early beta, and we made it available live to enable learning, testing, and iteration. " is also a dubious statement. Like has been said, it was an untested alpha, where the WMF really dropped the ball quite dramatically, with the most logical conclusion that some KPI or deadline had to be met. Even the examples given for the use of Functions and Abstract were and are very dubious. At the moment, 1234[65] gives me "Wikifunctions returned a failed response: Error in the function call API". In other major languages, for the same article, I get errors like "Wikifunctions returned a failed response: Invalid executor response", "Wikifunctions returned a failed response: No matching lexeme for item in language", and "Wikifunctions returned a failed response: Argument value error". Fram (talk) 09:00, 19 June 2026 (UTC)[reply]
But nobody called anyone a "mindless WMF droid". The only use of anything like that term was by Feeglgeef saying that they were not a "mindless WMF droid". But I see that my words here will be twisted beyond recognition. Phil Bridger (talk) 07:40, 19 June 2026 (UTC)[reply]
How is this better than AI?
I know it's popular in wiki-land to hate on anything related to AI, and in particular LLMs, but I look at what Abstract does and I look at what the LLM-driven translation tools do, and I just don't see the point of what we're doing. Our goal is to be able to take an article written in one language and allow somebody who does not read that language to read the article in a language they do know. The LLM tools do that today. They're not perfect, but they're good enough for most purposes, and they'll only get better over time.
I don't mind investing WMF money in research projects. There is value in adding to our understanding of how information is stored and processed, and exploring better ways we can deliver that information to our readers. Abstract and Functions is about that, so I'm happy that we've explored what's possible. But given the progress LLMs have made over the past few years, and the current state of what Abstract appears to be able to deliver, I'm just not seeing how this has a chance of becoming a viable product. That's not to say the experiment was a failure. A failure would be "we haven't learned anything". But we have learned something, which is that "this approach to automatic translations doesn't appear to be the way to go". RoySmith(talk)13:00, 19 June 2026 (UTC)[reply]
AI translation has a tendency to be confidently incorrect, but AI is certainly more accurate than using buggy functions and blaming it on the community. ~2026-34629-56 (talk) 15:52, 19 June 2026 (UTC)[reply]
It's a record of data and not AI. If WMF steers this in the right direction and invests the resources and work in the right places (which they are surprisingly failing to do for a project that they so champion) then the articles have the capacity to be much better than AI. In solidarity, Aaron Liu (talk) 17:31, 19 June 2026 (UTC)[reply]
How? Why would WMF be able to translate into obscure languages without the help of one or two linguists of those languages? Someone will have to translate all lexemes for these languages, add all labels for these languages, check the output of Abstract, and then give the green light. We need to be certain that they are native speakers or very fluent in the language, to avoid a Scots scenario. And all that to translate an Abstract article which will probably be worse (language, completeness, ...) than enwiki, dewiki, jawiki... and not adapted to the target language (see e.g. the example of 1234, which doesn't take into account any other year system). LLMs won't do all of these things either, but for a fair number of languages it will already produce a result which is as good as can be expected from Abstract, but without all the additional effort described. How will Abstract ever be better at those things? Fram (talk) 18:15, 19 June 2026 (UTC)[reply]
Exactly, that's what they would need to do (the advantage is deterministic outputs). It's worrying that the infrastructure for what they need to do is in such an alpha-at-most state. In solidarity, Aaron Liu (talk) 18:59, 19 June 2026 (UTC)[reply]
"LLMs won't do all of these things either" is such an understatement by the way. They have no understanding of the things they translate at all, which is pretty bad for an encyclopedia because we use technical terms whose translation is not always straightforward. For example, in some languages a field is called a "body" (presumably the ones that borrowed the term from French). My native language, Greek, is one of them. Guess what Google translate does when I ask it to translate Field (mathematics) ([66]). It switches between the correct term (σώμα) and the literal translation of "field" (πεδίο) between paragraphs. To no one's surprise, it sticks to the wrong word most of the time and it also uses the wrong word in the title. "Field" is far from unique in this. While checking this and other articles, I saw words like function, matrix, ideal, differentiation, infinitesimal, domain etc. get mistranslated too. That is in addition to all the other things it butchers along the way ("general quintic equations" -> "general quantum equations"?? in the field article) as well as grammatical mistakes even a complete novice wouldn't make ("Εάν η συνάρτηση είναι διαφορίσιμο(??) στο a" in derivative[67]). It's not a google exclusive problem either. In my testing with DeepL it didn't do much better. Also, since I mentioned French earlier, here is a French example where Lie ring turns into "ring of lies" (I don't speak French so I verified this with Wiktonary): [68]. Warudo (talk) 20:04, 19 June 2026 (UTC)[reply]
To be clear the point of my comment is that the only translation that is worth considering is one done by humans. I understand why people want to compare abstract Wikipedia to LLMs but I think that comparison misses the point. Even if abstract Wikipedia reaches a point where it is able to produce LLM level output, which I feel would be nothing short of a miracle, it would not be anywhere near good enough to consider using. Warudo (talk) 20:10, 19 June 2026 (UTC)[reply]
Incorrect word choice is hardly limited to computers. People do it too. I used to work with a guy from Cuba who, while fluent in English, never quite mastered the difference between "in" and "on" (they're both "en" in Spanish). The phone would ring, he would answer it, and hand it to me: "Bob is in the phone for you". Oddly enough, "in the phone" actually makes more sense, but that's not the correct English idiom.
I read a lot of text related to checkuser actions in various languages. It didn't take long for me to figure out that "doll" was just Google Translate's way of saying "sockpuppet" in Spanish, and so on for other languages and other bits of wiki-jargon. In the end, it really isn't a big deal. It was obvious from the get-go that "doll" wasn't the right word but I quickly figured out what it meant and ultimately there was no real hit to my cross-wiki reading comprehension.
I expect the same is true of "field" for you. You recognized that πεδίο didn't make sense, but you figured it out and now that you know what it means, so what if it's not the correct word? Languages evolve. Hardly a day goes by on the internet without me being reminded that I'm no longer one of the cool kids because they're using words I've never heard of before and I have to resort to Urban Dictionary to figure out what they're talking about. Is it really fair that we hold the LLMs to a higher standard that we hold ourselves? RoySmith(talk)20:52, 19 June 2026 (UTC)[reply]
Let's assume I didn't speak English and elwiki didn't have an article on fields. I'd read the translated enwiki article, see that the term is called "πεδίο" (this is the term that appears most, the other terms are probably translation errors) and move on. Except what if I then wanted to go look for more information outside Wikipedia? I'd then pick up my mathematics textbook, check the index and only find results about scalar fields and vector fields (which are called πεδία in Greek) but nothing about the algebraic structure. What I'm missing is that I'm looking in the wrong place. If only I knew what it was actually called. Then I want to learn what an ideal is. Google translate said it's called "ιδανικό" [69]. Huh, there's nothing here? If only I'd known the word is "ιδεώδες". And on and on it goes. So, ultimately, you can't look things up on your own because you don't know what they are called so you're stuck asking the AI about them. You also can't really discuss these concepts with others because your idiolect is completely different from theirs. And before you call this hyperbole, I'll let you know that google translate also mistranslates "associative" in the field article. So even if you try to tell your interlocutor the definition of the thing you're talking about, you're still out of luck unless they speak English and guess what happened.
You also underestimate just how confusing things can get. In the translation of ideal (ring theory), the term "right ideal" (which is supposed to be δεξιό ιδεώδες) turns into something that basically means "correct ideal" (σωστό ιδανικό) and "proper ideal" (which is supposed to be γνήσιο ιδεώδες) into something that means "suitable ideal" (κατάλληλο ιδανικό). So someone who doesn't speak English and does not know why these error happened will try to figure out why a right ideal is correct and a left one isn't and what a proper ideal is suitable for. Warudo (talk) 22:38, 19 June 2026 (UTC)[reply]
I feel your pain. My particular peeve is symbols. If I read in an article: and don't know what that symbol is, how do I even begin to look it up? Claude actually does a good job if I copy-paste the markup, I get back "The notation: F \ {0} means "the set F, with the element 0 removed." which at least gets me pointed in the right direction. But to get back to my original point, "they're good enough for most purposes". Failing to correctly translate some terms in advanced math articles doesn't negate that. RoySmith(talk)23:01, 19 June 2026 (UTC)[reply]
If by "better" you mean produce better translations in theory, in essence this is pitting a rules-based translation system where the rules are explicitly programmed by humans versus a black box where a program adjusted its tuning parameters by itself that control how translation is done from input to output. One example is the world's strongest chess program, Stockfish, which originally had a human-crafted evaluation function, then introduced a trained neural network, and now has dropped the human-crafted evaluation function. However games have a very specific ultimate evaluation method – did the program win – which I suspect makes it easier for the network to evolve to a state where it wins more often. I think human language translation has more training challenges, and it's not as clear to me that a program self-training could in a theoretical perfect world do a well as an explicit set of rules.
From a practical standpoint, though, codifying rules to capture all nuances is very difficult. And even to the extent it's possible, it's not clear that there are enough people interested in working on it in a crowdsourced project. So while the black box may produce OK translations only some percent of the time, that might still offer a better cost-benefit ratio than getting Wikifunctions to meet the same level of quality. isaacl (talk) 02:51, 20 June 2026 (UTC)[reply]
We are planning to trial an "incident reporting" form here for the next two months, after some smaller-scale deployments on Portuguese Wikipedia and several other wikis. After discussing with functionaries, the trial will start small (visible to 5% of users) and we plan to coordinate with functionaries along the way to agree on the right points to expand visibility.
The incident reporting form is designed to do two things:
Help less experienced community members more easily report potentially bad behavior to the community-managed place that can best deal with it.
For more rare and severe cases, it provides a form to directly report imminent threats of harm to the WMF Trust and Safety team.
This trial will be primarily focused on calibrating the first use case: helping editors report potentially bad behavior, without overloading the system. Registered editors, who have at least one edit and are unblocked and have a verified email, can click a "Report" button on a discussion page. Eligible editors who have Discussion Tools enabled can click a "Report" button on a particular comment. The editor can then choose the category of behavior at issue, and then be directed to a location chosen by that wiki's community for that category. There are screenshots of these interactions at the bottom of this post.
For the last few weeks, we've been working with functionaries to figure out what categories are most needed for English Wikipedia, and to identify the right destinations to point users for those categories.
Based on those conversations, we've made some changes to the categories from what we have deployed elsewhere, to optimize this trial for English Wikipedia, given your community's longstanding policies and processes for dispute resolution. We've further supported functionaries for the last couple of weeks as they've configured the form's behavior for the community and prepared supporting material for end users. Special thanks go to CaptainEek in particular for spending significant time writing and editing material for this trial.
During the trial, we will focus on monitoring the volume of new reports, checking that reports are routed correctly, and identifying any immediate issues. We will be coordinating closely with all community members to fix bugs if they arise, and to otherwise streamline the process. For example, we are exploring some ways to tighten the user experience and help people more directly submit their reports, which we may deploy and measure during the trial as well. We expect to gradually increase user visibility over the next two months.
We welcome your thoughts. If you'd like to talk to us off-wiki, the easiest way to reach us is on Discord.
1. The "Report" button, as shown in the Tools menu (see arrow).
2. The "Report" button, as shown in the overflow menu in a comment thread (for users with the Discussion Tools beta feature enabled).
3. The full set of categories of potentially unwanted behavior that an editor can pick from.
4. Support information for users reporting potential bullying.
5. Support information for users reporting potential sockpuppetry.
Thanks for that folks! For those who are interested, the system is locally customizable in two ways, which I spent the last month or so working on. Special:CommunityConfiguration/ReportIncident allows us to configure various options and links. This query shows all mediawiki pages that we may locally edit to localize text. Typo and link fixes are welcome; all other edits should obviously be discussed as these are full protected media wiki pages with wide transclusion. You may test out the incident reporting system at Event talk:Sandbox (it is not currently enabled in any other namespace); be cognizant that the system is live and unless you are listed as an end-to-end tester, your button clicks may be logged/your emergency reports may be sent. Eric and his team are working on building the tool out more, and they tell us that having test data will help build the tool out more effectively; the next step is hopefully to include a baked in reporting form or pre-filled form templates. CaptainEekEdits Ho Cap'n!⚓18:22, 29 April 2026 (UTC)[reply]
Additionally, what is the best place to discuss and ask questions? For example, I see that AIV is not listed in "How to report obvious spam", but is listed lower for vandalism – is there a reason for that? It could be very helpful to have a documentation page and a talk page for this feature, if that isn't already the case.Other question I'm having (sorry!), for reporting hateful content, Open a new thread on the appropriate noticeboard for routine and public incidents may give the impression to the reporter that their concerns are dismissed as "routine", is there a better wording or is my fear unfounded? Chaotic Enby (talk · contribs) 15:41, 30 April 2026 (UTC)[reply]
First, yes, I agree having a centralized project/talk page would be good; I can set one up this evening. Second, the trouble with that line is that the wording isn't customizable per category, so every option that has a report to the appropriate noticeboard link has to have the same wording (for now at least). But I agree I had a hard time thinking of wording that worked in most general scenarios; we could probably just remove "routine". CaptainEekEdits Ho Cap'n!⚓15:58, 30 April 2026 (UTC)[reply]
This seems like a cool idea, but if I understand correctly the "Report" button doesn't actually create a report? That seems misleading. I was expecting it to ask the user to fill out a form which would automatically post to ANI when submitted. Toadspike[Talk]12:13, 30 April 2026 (UTC)[reply]
You do understand correctly. This mismatch has been a source of feedback from the U4C and Steawrds from the start of the project. Eventually that is the goal but that won't be happening soon. However, there is now work being done to allow communities to choose email as an option for some report types. So if we sent people to say the OS queue for doxxing that would generate an actual report. And work has been completed on allowing communities to use a URL with parameters meaning we could do some prefill work at least to generate an actual notice out of the system. But yes an Incident Reporting System that only generated a report in one very narrow case (emergency) for a long time has been and continues to be a weakness of the system. Best, Barkeep49 (talk) 14:24, 30 April 2026 (UTC)[reply]
In that case, as a temporary measure, is there an option to bold the links to where editors can report? Given how the text can easily fill a page, it can be helpful to prevent editors from getting lost in the sea of links. Chaotic Enby (talk · contribs) 15:50, 30 April 2026 (UTC)[reply]
When I last tried on test wiki, bolding did not work (using markup or html); however some changes to allow code to work in some places have been made so I'll test it again and see about bolding links CaptainEekEdits Ho Cap'n!⚓19:20, 30 April 2026 (UTC)[reply]
@EMill-WMF, @MAna (WMF), is it possible to add horizontal rule in between the sections? It was not apparent that there are multiple forms for the different reporting/noticeboard venues because visually the noticeboard header and the form labels are similar. i.e. – robertsky (talk) 15:37, 30 April 2026 (UTC)[reply]
Hi, I'm not sure I understand what you're looking when mentioning multiple forms for different reporting/noticeboard venues, are you referring to how these are configured via Community Configuration? MAna (WMF) (talk) 17:42, 30 April 2026 (UTC)[reply]
Just to update - this incident reporting form is now live on English Wikipedia, though for now, the report link is only visible to 5% of users. EMill-WMF (talk) 19:30, 8 May 2026 (UTC)[reply]
Hi, we have a new update. The trial has been running in 5% for a week now, and the numbers are quite small, so we're planning to raise this to 20% on Friday.
Soon afterward, we'll be adding a new feature to the tool to make things more direct for users. For categories where the community wants reports to go to an email address, we're incorporating a web form into the tool that will let the user submit the report from there and it will send it to that email address on their behalf. MAna (WMF) (talk) 17:35, 14 May 2026 (UTC)[reply]
No, it's not general purpose - if the community specifies that reports of a certain type should go to a specific email, this form will appear and will send the contents to that email. It's more similar to how emergency reporting already works in the tool, which sends the contents to a specified (WMF) email address. EMill-WMF (talk) 18:47, 14 May 2026 (UTC)[reply]
Hi all, we have now enabled direct reporting to email destinations. For categories where the community has configured an email address as the reporting destination, users can now submit their report directly through a web form.
Now that we’ve deployed this change, after discussion with functionaries, we’re planning to increase visibility to 60% of enwiki users. MAna (WMF) (talk) 16:13, 3 June 2026 (UTC)[reply]
Thank you to everyone for their work to make this happen! Can we get a better default text at MediaWiki:Reportincident-unacceptable-behavior-footer? The first sentence is a tautology—of course unacceptable behavior is not tolerated. Even removing is not tolerated would be a substantial improvement: {{SITENAME}} is a community where [[Foundation:Special:MyLanguage/Policy:Universal Code of Conduct#3 – Unacceptable behaviour|unacceptable behavior]] is managed by the community of experienced users. (I know we can customize this locally, but this should be a global change.) Best, HouseBlaster (talk • he/they)02:33, 7 June 2026 (UTC)[reply]
Hi all, the trial has now been running at 60% visibility, and we have continued monitoring it closely. Based on our conversations with functionaries, we have enabled IRS in the Wikipedia namespace, and are planning to increase visibility to 100% of eligible users this week. MAna (WMF) (talk) 08:11, 17 June 2026 (UTC)[reply]
Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on May 8. Please help translate.
Highlights
Community Wishlist discussion: Product & Technology introduced changes meant to increase the number and complexity of wishes fulfilled, including the disbanding of the Community Tech team. They are engaging in discussions about a proposed direction for the wishlist from community members. Includes ways to structure annual voting, better tracking of wishes, removing focus areas, and staffing updates.
Digital Public Goods: The Wikimedia Foundation has become a member of the Digital Public Goods Alliance (DPGA).
Better bot detection: A trial of hCaptcha on several Wikipedias, including English, French, and Japanese, showed it can effectively detect and deter bad-faith automated activity, on its own and by giving checkusers and stewards signals to look into. Based on these results, hCaptcha will be rolled out across all wikis. See the project page for technical information about the implementation and privacy protections.
Example of the Attribution Framework recommendations.
A better way to give credit: The Wikimedia Attribution Framework and API makes it simple for developers to fairly credit volunteer contribution. When anyone encounters Wikimedia content, we want them to know that it comes from our projects, and they are invited to participate.
Baby Globe joins the Reading Challenge: The Android and iOS Wikipedia apps released the 25-day reading challenge, to drive readers engagement through reading milestones. To track their reading streak during the challenge, users can add a widget featuring Baby Globe to their home screen.
Account security: The Foundation is technically enforcing that all privileges that enable users to take security- or privacy-sensitive actions can only be held by users who have enabled two-factor authentication. Logging in with passkeys is quicker than logging in without two-factor authentication. In addition, logged-in users can see a banner encouraging them to confirm their email address. These changes secure individual accounts as well as communities and the wikis.
Incident reporting form: The Foundation began a trial on English Wikipedia of the incident reporting form. 60% of unblocked logged-in users see a new Report button, allowing them to report conduct issues.
Encouraging account creation: Following a successful account creation experiment, an improved logged-out edit warning message will be deployed to all Wikimedia wikis this week. The change will only affect logged-out users on mobile web who open an editing session.
Wikimedia Android App: The Wikipedia Android App is at the Phase 1 of redesigning its Home Feed. The new feed includes two tabs: Community, featuring refreshed Explore content, and For You, with personalized reading recommendations based on reader interests and activity. The For You feed refreshes daily with updated suggestions.
Reading Lists feature: The Foundation is conducting an experiment to show the reading lists feature, which is still in development, to logged-out mobile readers to test whether it encourages account creation at a higher rate compared to the watchstar button. The experiment was launched on May 18 on German, Spanish, Italian, Portuguese, Polish, Dutch, Turkish, and Urdu wikis, and will run for a month.
A design mockup of what the share card looks like.
Testing Suggestion Mode: Suggestion Mode was released as an A/B test for newcomer editors on the mobile website at ~15 Wikipedias. The experiment will measure its impact on the proportion of newcomer mobile web edit sessions that result in constructive (un-reverted) article edits. It will also evaluate the feature’s impact on editor retention and monitor changes in revert and block rates.
Wikifunctions now supports Wikidata references: References in Wikidata statements are now available on Wikifunctions, and you now can use external links in Wikifunctions-generated citations. This allows the use of more than 1.3 billion references available in Wikidata and adding them as citations to individual statements in Abstract Wikipedia.
Pilot wikis adopting Abstract Wikipedia: The Abstract Wikipedia team has identified five potential pilot wikis to assess their interest in adopting abstract articles on their wikis. The pilots are Malayalam, Bengali, Dagbani, Arabic, and Indonesian Wikipedia. If your community is interested in becoming a pilot, let us know on Meta.
Latest experiments: An upcoming experiment is testing whether we can serve readers better when a footnote click in read mode shows the full bibliographic information rather than flying them to the reference list. See all live, upcoming, and completed experiments in Product & Technology.
Tech News: The latest highlights from Tech News weeks 20, 21, 22, 23 include an experiment to test a new Share Card feature that allows readers to create visually engaging cards from Wikipedia articles and share them online See also the 92 community submitted tasks that were resolved over the last two weeks.
Tech blog moved to Diff: The migration of the Techblog to Diff is now complete: 138 posts going back over a decade have been successfully migrated. Diff is now happy to welcome technology-focused blog posts with renewed vigor.
What’s new in the Wikipedia Library: Access to the American Psychological Association was renewed and collections from the Harvard Business Review and Swiss Media Database (Swissdox) are now available to editors who are eligible for The Wikipedia Library.
New course on WikiLearn: A free self-paced online course, designed for researchers who want to make their field more visible on Wikipedia, was launched on WikiLearn. Share "Wikipedia for Researchers” if you work with early-career researchers, teach in an academic institution, or support open knowledge communities.
Wiki Mentor Africa: The first edition of Wiki Mentor Africa - Women Tech Summit brought together over 315 registered participants across Africa to learn, explore, and grow in tech together.
Let's Connect Learning Clinic: If you missed it, you can now watch the recording of the Let's Connect Learning Clinic "How to support up-and-coming groups in the movement as a long-time Wikimedian" with Wikimedistas El Salvador.
Sharing the Form 990s: The Wikimedia Foundation and the Wikimedia Endowment published their Form 990s, covering the fiscal year that ran from July 2024 to June 2025. The Form 990 is an annual form required of all nonprofit organizations in the United States. You can read the highlights on Form 990 for the Foundation and Form 990 for the Endowment on Meta-Wiki.
Wikimedia Enterprise: Wikimedia Enterprise's free API accounts gets a substantial upgrade across the Snapshot and On-demand APIs, including free access to Structured Contents Snapshots.
Board selection process: The Wikimedia Foundation Board of Trustees is reviewing and improving how it selects new members. The goal is to ensure that there is the right mix of expertise and community representation on the board. Join the conversation on 16 June at 17:00 UTC, and share your ideas on the talk page.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. If you have feedback or suggestions about the bulletin, let us know at foundationbulletinwikimedia.org. For questions about the Wikimedia Foundation's work, contact us!
Not often you see an organization proclaim "we're improving X by disbanding the team dedicated to X." 😂 There are better ways to say that, like "redistributing resources and workload from a single team to multiple teams." Levivich (talk) 04:47, 10 June 2026 (UTC)[reply]
Well, you'll certainly be able to say "the amount of wishes fulfilled has finally settled at a consistent level" if you burn the house to the ground in the interest of efficiency. EggRoll97(talk) 05:29, 10 June 2026 (UTC)[reply]
The necessary resources are being redistributed onto the unemployment queue. I try to assume good faith and hope that the workload will be redistributed efficiently, but I fear that it may quietly disappear in favour of shinier projects. Certes (talk) 08:30, 10 June 2026 (UTC)[reply]
Hello, not sure if this is the best place to post this so pls lmk if elsewhere is better.
I really like the recent social media campaign WMF is running lately, where interesting things about/on Wikipedia are being introduced. While these are all great, they're very readership focused and a little surface level.
Imo what would be really helpful is if WMF made entertaining explainers about how Wikipedia works. E.g. this kind of format: [71]
For example, a really wide misunderstanding is whether Wikipedia has "mods"; many incorrectly assume Wikipedia admins are basically like Reddit mods: all-powerful and with strong control over Wikipedia's content. At least for the English Wikipedia, that's not true. Vids could be made to address this misconception. Would need multiple vids on this topic, spread out over time; it's so widespread and information takes time to disseminate.
Other possible topics include:
Explaining how article deletions/deletion nominations work (also really misunderstood)
Introducing the various parts of Wikipedia, like talk pages, the Teahouse, etc
Introducing various interesting tools Wikipedians use, like anti-vandal stuff, Twinkle, and AutoWikiBrowser.
The WMF is currently running banners with the text:
17 June: Wikipedia still can't be sold We're sorry we've made several attempts to reach you, but it's Wednesday, 17 June, and we still need some help. If Wikipedia is useful to you, please take a minute to protect its future with a $2.75 donation today. Most readers don't donate; only 2% do. Wikipedia is run by a nonprofit, not by a billionaire. So if Wikipedia has given you $2.75 worth of knowledge, please give. Any contribution helps, whether it's $2.75 or $25.
In the past, we produced a consensus that banners that state or imply any of the following are not considered appropriate on the English Wikipedia:
Wikipedia's existence or independence is under threat or dependent on donations
Donated funds are used primarily to support Wikipedia and/or its volunteer editors
Readers should feel obliged to donate regardless of their means ("guilt tripping")
I don't believe that these current banners comply with this consensus. I'm hopeful the WMF can resolve this quickly; I will post to the talk pages of a few relevant employees, asking them to comment. BilledMammal (talk) 07:25, 17 June 2026 (UTC)[reply]
Could you expand on why you believe this is against community consensus? Compared to the ads of old, I think this passes muster but maybe I'm missing something. In solidarity, —Femke (talk) 🐦 07:56, 17 June 2026 (UTC)[reply]
The most problematic text seems to be "protect its future", where "it" clearly means "Wikipedia". That could be read as suggesting firstly that a substantial part of any donation would go to Wikipedia, and secondly that Wikipedia is $2.75 short of being able to survive without it. However, the implication is indirect and less deceptive than previous banners. Certes (talk) 10:16, 17 June 2026 (UTC)[reply]
@Certes: A substantial part does go towards Wikipedia, cc the Annual Plan breakup. Regarding the original question, I personally align with Femke and RoySmith in that I don't think the banner breaks consensus given the context of the guidelines (which were primarily made for a different category of much more egregious banners) Sohom (talk) 16:42, 17 June 2026 (UTC)[reply]
Complaining about a banner is a different bar from "banner violates past consensus, needs to be resolved quickly" (which is the tone of this discussion). One is "lets have a dialog" another implies "do this now, or else". Sohom (talk) 19:41, 17 June 2026 (UTC)[reply]
@Black Kite Could you explain what part of this is deceptive? (When you answer, one thing to keep explicitly keep in mind that the funding situation has significantly changed since 2022 when this consensus was obtained, WMF does spend 77% of it's budget on volunteers, a majority of which goes to English Wikipedia, and unlike in 2022, donations are actually on a downward trend and WMF is actually now increasingly turning to long-term donors to continue funding itself -- while it still has a fair bit of money around, it is not infinite and the lack of any donations will indeed lead to insecure future at some point, especially in a climate where we are competing with billionare led ventures like Grokipedia). Sohom (talk) 20:15, 17 June 2026 (UTC)[reply]
"...take a minute to protect its future with a $2.75 donation today". Nothing is going to happen if you don't donate $2.75, and neither is it if no-one else does either. That was the reason the first clause was agreed the last time we had this discussion. Black Kite (talk)20:26, 17 June 2026 (UTC)[reply]
Collectively if no-one else does either is a problem. I remember doing some back of the napkin math, at our current spend rate, I think we have roughly 1.5 to 2 years assuming everyone immediately stops donating. This is obviously not a dooms-day, we pack up tomorrow scenario, but it's not "if nobody donates we will be around for 10 more years" scenario either and the "nobody really has to worry about donating" scenario that you are laying out. Sohom (talk) 20:49, 17 June 2026 (UTC)[reply]
Nothing is going to happen if you don't donate $2.75, and neither is it if no-one else does either. How exactly do you think WMF pays its employees and its bills for running its data centres? – SD0001 (talk) 16:47, 18 June 2026 (UTC)[reply]
I'm sorry, SD, you're just plain misinformed about where the money comes from. The way it works is the good wiki fairy comes along and waves her magic wand. That keeps the disks spinning and the bits flowing and enlightens repressive regimes around the world about freedom of information so we don't have to waste any effort defending our editors in court. It also makes hotel rooms and airline tickets drop from the sky so volunteers can get scholarships to wikimania. And as the wiki fairy walks along the beach, gold coins grow out of her footprints in the sand; these go to funding local affiliates to keep their education and outreach programs afloat.
All we need to do is join hands and think happy thoughts in a big group hug so the wiki fairy will come and save us. Until then, I'm willing to put up with a few banners. RoySmith(talk)17:26, 18 June 2026 (UTC)[reply]
Do we have any detail on this 77% figure? It's one I've not seen before, and I am really struggling to see where $150 million is being spent on volunteers this year. It feels much, much less. Certes (talk) 20:41, 17 June 2026 (UTC)[reply]
Thank you. That's interesting. I'm particularly heartened to see that the Annual Plan actually mentions Wikipedia – an improvement on the last one I read. It's always difficult to categorise spending. "Investment in Technology" (48%) includes issues such as management of scraper bots, which is a very welcome function but not one directly aimed at volunteers. Presumably it also covers developments such as Abstract Wikipedia which fewer volunteers might prioritise. We certainly appreciate the work of the community tech team which this item has funded in previous years. Certes (talk) 21:05, 17 June 2026 (UTC)[reply]
Presumably it also covers developments such as Abstract Wikipedia which fewer volunteers might prioritise., it does, I had written up a guide about the current annual plan to contextualize what is planned for next year. It's a bit out of date, but it should be relatively accurate and Abstract Wikipedia is a fairly small portion of the pie. A lot of WMF's current spending is on making it easier for intermediate editors learn to become competent editors, make readers stay around for longer and a chunk to help admins fight vandalism effectively (outside fighting scrapers itself and making sure we have high availability) Alongside that you have work being done to make Toolforge more user friendly and making existing APIs better so that folks can reuse content without taking down Wikipedia itself. Sohom (talk) 04:18, 18 June 2026 (UTC)[reply]
I support the banner ad program and the current language. It is a reasonable, unobtrusive, and voluntary option for meeting the organization's financial needs... ensuring that Wikipedia can persist long into the future as an independent source of information about the world. They tried letting the community run the ship on the fundraising a few years back and it imploded. Clearly this is not something that the "consensus" is equipped to handle. Ice Vest (talk) 22:57, 17 June 2026 (UTC)[reply]
Is no one else irked by We're sorry we've made several attempts to reach you? That's the kind of nagging tone that turns me off any appeal from a charity or non-profit if I get it in a phone call/voicemail or in the post. It sure feels like "guilt-tripping" to me. —In solidarity with Wiki Workers United · ClaudineChionh (she/her · talk · email) 23:00, 17 June 2026 (UTC)[reply]
But are they truly sorry? Wouldn't someone who was genuinely apologetic about having contacted me refrain from doing so again? Certes (talk) 11:11, 18 June 2026 (UTC)[reply]
These banners that are asking for donations and making false claims about the website going bankrupt is "misleading and unacceptable" and is being used as a scare tactic to force editors to donate. These banners represent nothing but corporate greed and lies.
The platform's fundraising strategy faces considerable public and internal critique:
Substantial Reserves: Financial statements reveal the Wikimedia Foundation holds hundreds of millions of dollars in cash and investments, meaning it is not in danger of shutting down.
Aggressive Language: Critics, and even some veteran Wikipedia editors, argue that the banners misleadingly imply the site is on the verge of going offline if readers do not donate immediately.
Organizational Growth: A large portion of the budget goes toward expanding the Foundation’s bureaucratic footprint and funding adjacent non-profit grants rather than just maintaining the core website.
Hello @~2026-35699-89: could you share what you see in those banners? They should not imply bankruptcy is near.
Just so you know, the Foundation has stopped its grant programme for knowledge equity. Having reserves is a good thing given how tumultuous the world is now I'd say. In solidarity, —Femke (talk) 🐦 18:26, 18 June 2026 (UTC)[reply]
This is exactly what i saw: 18 June: Wikipedia still can't be sold
We're sorry we've made several attempts to reach you, but it's Thursday, 18 June, and we still need some help. If Wikipedia is useful to you, please take a minute to protect its future with a $2.75 donation today. Most readers don't donate; only 2% do. Wikipedia is run by a nonprofit, not by a billionaire. So if Wikipedia has given you $2.75 worth of knowledge, please give. Any contribution helps, whether it's $2.75 or $25. ~2026-35699-89 (talk) 05:43, 19 June 2026 (UTC)[reply]
Changes to the Codex Icon Library
I am disappointed to report thatThe user interface icon library will be updated later this week or next week. Most of the ~300 icons have been slightly refined and ~30 new icons have been added. These changes improve the icons to make them more consistent and comprehensible, and provide more visual balance when they are used in groups.
Despite the claim that these updates will make the interface more consistent and comprehensible, I think quite a few of the designs are poorly thought out, overly simplified, and missing some of the clarity from the icons they are replacing. Frustratingly we're losing a couple of beloved icons like the classic UserTalk into a version which is.. well, honestly just awful in comparison.
I know it feels like I am an old grump just hating on change. I genuinely don't mind refinements to UX when it's thought out well, but I do see a lot of the new icons as a real downgrade. It's also mildly frustrating that there wasn't much community involvement in this process, considering it'll impact the look and feel of the site we use, however small. qcne(talk)17:29, 17 June 2026 (UTC)[reply]
+1 but also I feel like people engage in copyright pedantry when they say that can be present in both editors no issue (well, not any more with this new, worse icon version, but you get my point) but as soon as you include it on a random page, then it needs the full MIT licence linked somewhere to be fine to use. stjn18:59, 17 June 2026 (UTC)[reply]
In one place it's part of the software and can be presumed to be covered by the software's licensing. In the other it's part of the content, not covered by the software's licensing. Anomie⚔22:38, 17 June 2026 (UTC)[reply]
It is pretty questionable that images that are entirely template-generated like that case are an open and shut ‘part of the content’ just depending on their position in the interface (or the method of addition? does a JS-added image need to also adhere to MIT licence by linking? would something added via OOUI methods need to adhere to that?). stjn22:46, 17 June 2026 (UTC)[reply]
"Position in the interface" doesn't really matter. "Method of addition" is more relevant. An image added by content JS or CSS should be attributed when the image's license requires it, while images that are part of the OOUI software would be covered by that software's license. Probably a good rule of thumb (i.e. let's not get into nitpicking edge cases) would be that if the image is coming from Commons or a local enwiki upload then it should likely be linked if the license requires attribution, while if it's loaded from some MediaWiki path then it's covered by being part of the software. Yes, even if it's the same underlying image data. Anomie⚔12:12, 18 June 2026 (UTC)[reply]
Some of the icons were genuinely good changes (I liked the overall idea of combining filled and outlined icons to establish importance through weight), but the overall set feels very hit-or-miss. I'd be happy with keeping most of the current ones and adapting those that could do well with an outline/fill pair without having to redo the whole thing.Best example that comes to mind is the message icon set: adding an outlined version could easily be done without changing the whole thing and creating whichever cursed abomination the new "thanks" (UserTalk) button is.In general, I would say the focus on having a consistent outline width hurts the icon set more than it helps it, leading to awkward icons (such as the Article, HalfBright or SpecialPages ones, to name a few) or sometimes just straight-up overflows (ArticleNotFound, or Keyboard being all keys and no board). Icon symbolism also gets lost: SpecialPages previously had a star and UserRights a cogwheel, but both now get a more obscure asterisk, despite PageSettings keeping the cogwheel.These (and many others) really makes this feel like a downgrade in terms of having a consistent scheme. Most of it does feel caused by the focus on keeping every icon as an outline with a consistent thickness, which itself wasn't really necessary, but some are certainly odd choices beyond that. Chaotic Enby (in solidarity · talk · contribs) 18:39, 17 June 2026 (UTC)[reply]
Anyone know of a way to undo the new icon changes and restore the old icons? Can this be done with an alternate skin or a bit of CSS? Levivich (talk) 01:19, 21 June 2026 (UTC)[reply]
Wishlist program in the future (17 June WMF update)
Hi everyone -- I posted the below update on the separate page about the wishlist, but also wanted to copy it over here to increase its visibility for people who are interested. I think that the separate page might be better for discussion than here on VPWMF.
Hi all -- following up from June 11, I just posted an update on Meta about how we're thinking about the wishlist program going forward, after discussing ideas and concerns with some users with extended rights (thank you!) and hearing the comments from the many volunteers who have been writing on pages like this one and elsewhere. This update proposes some of the broad strokes for the future, and it includes open questions that I'm hoping volunteers will weigh in on. We'll keep discussing and posting updates to clarify details. Please speak up on here or on the talk page on Meta with your thoughts -- we want to shape a wishlist program that will deliver what volunteers need. -- MMiller (WMF) (talk) 20:34, 17 June 2026 (UTC)[reply]
Wikimedia Foundation Bulletin 2026 Issue 11
Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on June 5. Please help translate.
Simplifying account creation: The Foundation is working on improving the account creation process to reduce potential friction for newcomers to create an account. Improvements include making "Create Account" icon more prominent on mobile, simplifying the registration form, and introducing real-time username validation.
New U4C members elected: The Universal Code of Conduct Coordinating Committee (U4C) has new members and has two remaining vacancies in Middle East & North Africa and Sub-Saharan Africa.
Wikimania conference program: The Wikimania 2026 program is now live! Take a moment to review the program, and, if you are logged in, you can mark your "must see” sessions with a star to start building your personal schedule. Register for a virtual ticket here, if you haven't signed up yet.
Screenshot showing the Explore Feed refresh in the Wikipedia app (from the Community tab entry point)
App Explore feed: The redesigned App Explore feed, now called "Home", has been released to all Android users. The update introduces a refreshed feed experience along with the first set of new content modules, including Did You Know, Places of Interest, Random Article, and a new end-of-feed experience. Additional content and improvements are planned in future releases.
Wikipedia games: The Which came first? daily trivia game is now available in the beta version of the Wikipedia iOS app in English, German, French, Portuguese, Russian, Spanish, Arabic, Chinese, and Turkish. The game uses historical events from Wikipedia’s “On This Day” content and challenges readers to guess which of two events happened first.
Reusing references: Sub-referencing, a new MediaWiki feature that allows editors to reuse references with different details, has been rolled out to Group 1 wikis and French Wikipedia following a successful pilot phase.
Article guidance: The Article guidance feature is being tested with some editors creating new articles on the Simple English, French, and Turkish Wikipedias. The experiment will soon begin on the Arabic and Bangla Wikipedias as well. The outlines guide less experienced editors in creating high-quality articles. A quick guide to markups used in outlines can be found on this page. Example outlines that can be adapted and instructions for how to adapt them are on this section of the project page.
Mobile Page Previews: The Page Previews experiment on mobile web has concluded with the decision not to roll out the feature. The results showed no statistically significant impact on reader retention – the primary success metric. Page Previews, which are already available on desktop and in the apps, display a thumbnail, lead paragraph, and link to the full article when readers tap a blue link.
Wikifunctions: You can now add images to Abstract Wikipedia and the loading and display of test results when viewing Functions has been improved.
Wikidata: The Foundation is migrating the Wikidata Query Service (WDQS) away from the Blazegraph backend since it no longer scales efficiently with Wikidata’s growth. The migration will take place in several phases. Here is the timeline.
Growth features: Growth features are now available at Wikidata! Wikidata administrators are still configuring the features through Community Configuration, but this update enables access to Mentorship (if configured), Impact, the Help Panel, and a simplified Newcomer Homepage (without Suggested Edits).
Mentors' management: The Growth team will soon provide a system to automatically suspend or remove inactive mentors from the list of mentors. Communities can already start configuring the process in the Community Configuration.
CollaborativeContributions: If you need help setting up the Collaborative Contributions and the Goal setting features, check out these video guides. These features allow you to view which edits are made during an event and allows the group to track progress against a goal with a public progress bar. Learn more.
Latest experiments: An upcoming experiment is testing whether we can serve readers better when a footnote click in read mode shows the full bibliographic information rather than flying them to the reference list. See all live, upcoming, and completed experiments in Product & Technology.
Tech News: The latest highlights from Tech News week 24 and 25 include how the user interface icon library is being updated. Most of the ~300 icons have been slightly refined and ~30 new icons have been added. See also the 62 community submitted tasks that were resolved over the last two weeks.
Digital Safety: Join a conversation about Using AI Safely. It'll explore risks & concerns of using AI tools in personal and organisational contexts and practical strategies to reduce those risks. It will take place at 03:30 UTC & 14:30 UTC on June 26. This session is not about using AI to edit Wikipedia. It's focused entirely on safe personal and organisational use.
Don't Blink: Read the latest developments from around the world about protecting the Wikimedia model, its people and its values. Highlights include exploring the implications that new child safety regulations have on privacy online.
Grantmaking strategy & Affiliate model: Members of the Global Resources Distribution Committee (GRDC) and the Affiliations Committee (AffCom) met to advance two key movement initiatives: the development of a new Grantmaking strategy and a refreshed Affiliate Model. They produced initial proposals and advanced work on both initiatives ahead of broader conversations planned for Wikimania 2026.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. If you have feedback or suggestions about the bulletin, let us know at foundationbulletinwikimedia.org. For questions about the Wikimedia Foundation's work, contact us!
The new Google search has been announced a few days ago (their blog, but also reported by virtually every major source). This would basically mean that already this year our audience would shrink from being part human, part AI to being fully AI, no humans will read Wikipedia. This probably should have some consequences for what we are doing (you know, tastes of AI and humans are still different, though they seem to be converging very quickly). I have not seen this being discussed in the Wikimedia universe, and I would appreciate some links if someone is aware of such discussions. In the unlikely case it has not been discussed, we probably should start a discussion here. Thanks. Ymblanter (talk) 11:26, 23 May 2026 (UTC)[reply]
My reading of the blog: "blah blah agentic coding blah blah intelligent search blah blah AI Mode blah blah Gemini 3.5" etc. Really there's nothing new announced that doesn't already exist in Gemini itself. SuperPianoMan9167 (talk) 16:58, 23 May 2026 (UTC)[reply]
Meh. Still seems to just be anthropomorphism: Note that none of this tells us whether language models actually feel anything or have subjective experiences.SuperPianoMan9167 (talk) 17:29, 24 May 2026 (UTC)[reply]
Also, Anthropic has a strong incentive to claim that their models have become sentient, because then they can make money off of marketing themselves as "promoting AI welfare". (Yes, I am an AI skeptic.) SuperPianoMan9167 (talk) 17:32, 24 May 2026 (UTC)[reply]
To understand these models’ behavior, anthropomorphic reasoning is essential. is the part I thought might interest you, anthropomorphism as a tool for alignment. Aside from just trying to understand what is happening inside these networks with their interesting circuit structures, it seems to be about finding ways to align the values and preferences that influence their behavior with ours. I'm a skeptic by nature and training, but I think it's okay to use familiar words as stand-ins for emergent behavior that we don't understand produced by a bunch of vectors. Sean.hoyland (talk) 18:28, 24 May 2026 (UTC)[reply]
My understanding they are going to get rid of the search feed, so that people would not be able to get to the websites in one click. This pretty much means they will not be getting to us. There are ways around this, for example (just throwing up smth) supporting DuckDuckGo which is currently does not provide the search of a quality comparable to Google. I am sure there are other solutions, but if we do nothing we just lose 99% of our direct audience. Ymblanter (talk) 17:32, 23 May 2026 (UTC)[reply]
It seems timely to explore the consequences if Alphabet abandon the longstanding arrangement that Google indexes and presents Search links to websites.
While incoming traffic to WP and other sites is the first victim, there are other consequences. Take the longstanding understanding that new unpatrolled pages are unindexed; avoiding hoax/nonsense from being surfaced was in everyone's interest when search accuracy was the thing, but in this new sloppy world, is that exclusion being respected by LLM bots, including those using the Enterprise API?
And for editors here, Findsources for Notability checking is primarily linking Google Search. Is that sustainable if it returns Gemini slop? Would appending udm=14 maintain the prior norm? Or should it be parameterized to the user's preferred search engine? Or seek a Wikipedia Library type arrangement with Kagi, for example? AllyD (talk) 11:13, 24 May 2026 (UTC)[reply]
Thanks. This is indeed one thing, another thing is that whether a page looks nice to a human (and whether it is the case for desktop/mobile, different resolutions etc) becomes largely irrelevant, only the content. May be not even interlinking the pages. Ymblanter (talk) 16:04, 24 May 2026 (UTC)[reply]
And, as another consequence, I understand that it looks like red tape for some users, but Commons becomes more important under these conditions than Wikipedia (in any major language). Ymblanter (talk) 16:08, 24 May 2026 (UTC)[reply]
Probably "will not be able" is too strong, if they are determined they will. But most will be not even interested at clicking at the links. Ymblanter (talk) 06:50, 25 May 2026 (UTC)[reply]
I think this is the main threat: People will not be interested in clicking on the links, because they'll get their question answered without needing to click. WhatamIdoing (talk) 18:52, 26 May 2026 (UTC)[reply]
My reading is this is what they are going to do this Summer, and this is not yet the end of the project because the LLMs need to get the information elsewhere, and Wikipedia is still the best source of structured information which is still being added on a regular basis, but, as I said in the opening statement of this thread, we will have to adapt to the fact that we will not get any human readers, only LLM readers.--Ymblanter (talk) 06:47, 27 May 2026 (UTC)[reply]
My main worry is how AI manipulates information on controversial topics. I have tested this with queries like "Gaza genocide" at various times in the last 2 years. I prefer just regular web search and access to the open web. But in 50 years, the new generation might not know what the open web is.... 🐈Cinaroot03:44, 26 May 2026 (UTC)[reply]
According to Google's own AI, "Users, tech critics, and researchers have documented a measurable decline in Google Search quality ... from a mix of aggressive monetization ... and the disruptive introduction of AI features." [72]Certes (talk) 15:29, 26 May 2026 (UTC)[reply]
I think the complaints about Google Search are correct, but I think it's more complicated than that. I've used DuckDuckGo as my main web search engine for a few years. I find that the quality is adequate for most everyday, low-stakes purposes (e.g., finding a business's website or looking up a word/place/product that's mentioned in something I'm reading). But I find Google to be better if I'm looking for more complex things (e.g., a specific news article whose title I have, finding something relevant when I ask for information from slightly wrong keywords). What's annoying with all of them is that when I search for exact phrases (e.g., a quotation from a source), they may not find the thing that I want, and they always throw in things that I don't want.
That's an interesting idea, though obviously not great for finding reliable sources. I use DuckDuckGo (Bing with a false beard) but it's also going down the AI route, presenting "Learn about..." summaries as if they were Wikipedia leads. Certes (talk) 09:17, 27 May 2026 (UTC)[reply]
Humans will continue reading Wikipedia, in the same way they will continue reading many other websites (the sites that will be really damaged by this will be minor ones that almost nobody knows, and it's a pity anyway).
Wikipedia is the largest reference work ever written, and also the most read one (yes, this will continue to be so, since LLMs and search engines are not written works). Even if, eventually, most people don't want to read more than three lines of AI-generated content, the ones who choose to retain their brains despite having AI available, would want to continue reading, and Wikipedia is a very interesting work to be (of course, partially) read.
AI summaries are very useful to get quick facts, and they are no problem, since WMF's money doesn't come from clicks. When you need detailed information or a permanent written work whose content doesn't change every time you perform the search, you click on the link (that still exists, even in Google's AI mode) and come here.
Two Wikipedia essays that I think can help you to highlight why Wikipedia is not just a tool to search for information, as search engines or AI-powered search are, but it is information in itself (disclaimer: they were both written mostly by me):
Google's announced that site owners will soon be able to opt out being in the AI overviews and AI Mode. They're currently rolling this feature out to "a subset of website owners in the UK" before hopefully rolling it out worldwide. Hopefully, this should mean Wikipedia should stop appearing in the summaries. Of course, there will still be other sites that don't opt out, and the summaries will still be at the top of the search results, but it's a step forward at least. CheeseAndJamSamdwich (talk) 18:32, 3 June 2026 (UTC)[reply]
Is it? We know that Wikipedia's info on a topic is likely to be accurate and NPOV, unlike much else out there. The reader, and thus society at large, is better served if Wikipedia's content is not hidden from them. PamD19:54, 3 June 2026 (UTC)[reply]
Google is rolling this out in the UK initially, because they have to. It's not clear how best to respond. One way is to deny Google our content, hope that other outlets do likewise and that this makes the AI slop so visibly bad that no one uses it and Google withdraws it. The WMF may not go along with that, because it might result in losing income from Google (which they don't need, but that's another story). A more pessimistic assumption is that AI will creep in whatever we do, so we should minimise the enshittification by allowing Google to use our content rather than replace it by a less objective source. Certes (talk) 20:31, 3 June 2026 (UTC)[reply]
That raises the interesting if slightly mischievous idea of dumping all our unwanted AI crawler traffic on those who reuse our content without giving anything back. Certes (talk) 14:58, 4 June 2026 (UTC)[reply]
If our content is free, the AIs will still be trained on it; opting out from this seems like it will just suppress explicit links to the site in question from being highlighted in discussion, rather than preventing AI from training on it. So this would make our content invisible to end users while still being the main corpus for AI training signed, Rosguilltalk21:46, 3 June 2026 (UTC)[reply]
Google's move is terrible for the internet, but we have our own mission. I'd advocate for something nearly the opposite from opting out: give Google a sweet Wikimedia Enterprise deal granting it easy access to current data in exchange for very clear attribution, linking, etc. The worst case scenario is Wikipedia not being part of those AI summaries, the second-to-worst case scenario is being part of those AI summaries and people having no idea it's from Wikipedia. — Rhododendritestalk \\ 20:48, 3 June 2026 (UTC)[reply]
There are no circumstances whatsoever when it would be appropriate to offer Google (or any other business) 'a sweet Wikimedia Enterprise deal' in return for proper attribution. That'd basically be paying them to conform to the terms of use they are already supposed to be complying with, and an active inducement to non-compliance by anyone seeking a similar deal. AndyTheGrump (talk) 21:31, 3 June 2026 (UTC)[reply]
The legal obligations are those specified by the CC BY-SA license, but the Wikimedia Attribution Framework provides tools for more in-depth attribution (cf. the page for AI assistant reuse). It neatly separates essential elements of attribution required by the license from additional trust signals such as the number of editors and the last update, and even a call to action to contribute. Having an API deal with Google or other companies conditional on this more in-depth attribution could be a great way to keep Wikipedia relevant in AI overviews. Chaotic Enby (in solidarity · talk · contribs) 15:10, 4 June 2026 (UTC)[reply]
Google already steals our content and doesn't give proper attribution with it's little "infobox" on the side of its search results. The implementation of this has varied over the years but it's been a terrible thing for Wikipedia because it prevents traffic from coming to the site because Google gave them the information they wanted already. It actively harmed our user base growth in my opinion. Jason Quinn (talk) 20:45, 11 June 2026 (UTC)[reply]
Google already steals our content and doesn't give proper attribution All you need for proper attribution is a URL and a link to the CC BY-SA 4.0 license. SuperPianoMan9167 (talk) 23:41, 11 June 2026 (UTC)[reply]
I see the argument for attribution but would we want Wikipedia's name slapped on an AI's misunderstanding of what Wikipedia says? What if it misconstrues our content into something defamatory that we never said? Attribution could lend false credibility to the AI's garbage while redirecting the brickbats for its mistakes towards us. --DanielRigal (talk) 19:41, 18 June 2026 (UTC)[reply]
There is many-year edit war in this category about - should it be put into Category:Films about dinosaurs? I think - obviously not, because, even if birds are dinosaurs' descendants according to cladistics, in common language birds and dinosaurs are disjoint sets. In last 6 years, there is one user - Randy Kryn - who many times adds birds into dinosaurs category after many users remove it. I propose to decide here that this category should not be in dinosaurs category (and block users, who will add it to dinosaurs again). MBH (talk) 16:29, 6 June 2026 (UTC)[reply]
This isn't a dispute resolution board. See WP:DR for that. And messages along the lines of "I'm right and they're wrong" aren't a good way of getting uninvolved parties to join in. IMO it seems like a natural parent category to me. Not like Randy (courtesy ping Randy Kryn) is proposing to rename the category. Anyone looking for birds still gets birds. Also IMO categories are rarely worth fighting about -- better to write an article on a bird documentary. While we're off-topic for VPM, I'll recommend Listers: A Glimpse Into Extreme Birdwatching, a wonderful birding documentary by/for people who don't really understand birding. :) — Rhododendritestalk \\ 17:05, 6 June 2026 (UTC)[reply]
It's obvious to me that it won't be possible to convince him otherwise. What do you propose to do next in this case if the opponent disagrees with you? Without referring to the huge rule, just in your own words. The category discussion page is probably almost unwatched, so discussing it there won't lead to anything either. MBH (talk) 17:16, 6 June 2026 (UTC)[reply]
As explained above, WP:DR outlines the procedures. However, from your description it looks like the plan would be to start a discussion at a wikiproject (presumably one about birds, with a notification on one about dinosaurs). The discussion would not mention other editors, just say there is a disagreement and give brief, concrete examples (link to article + discussion + category). If the discussion results in a clear consensus, revert contrary changes (once only!) with a link to the discussion. If problems, post on user's talk asking why they don't think they are editing against consensus. If not satisfied with response, post at WP:ANI with a claim that an editor is editing against consensus. If there is no clear consensus, start an WP:RFC with a neutral, clear question. Johnuniq (talk) 02:51, 7 June 2026 (UTC)[reply]
@Pppery Thanks. So, could someone remove "Films about birds" from "Films about dinosaurs" and probably block Randy Kryn to edit this category? MBH (talk) 20:25, 7 June 2026 (UTC)[reply]
I already did remove the category. I'm not going to issue any blocks myself; I'm far too involved to do so and promised to stay away from this kind of block in my RfA. * Pppery *in solidarity20:39, 7 June 2026 (UTC)[reply]
I'm not actually sure that CfD established a full consensus on the pop culture categories, since its resolution involved a subcategory (since renamed, I believe), and currently Category:Birds is in a series of clade categories named in Latin that tops out at Category:Dinosaurs by classification and then Category:Dinosaurs, and while there was some agreement that birds and dinosaurs in pop culture aren't necessarily helpful to define cladistically, I don't think it was the focus, so it might be a good idea to have a focused CfD specifically on the film categories. Sesquilinear (talk) 20:55, 7 June 2026 (UTC)[reply]
The applicability of that CfD is that if "Films about birds" is already under a subcategory of "films about dinosaurs" then it shouldn't be in "films about dinosaurs". There is clearly nothing resembling consensus in that CfD that "birds aren't dinosaurs" or something. — Rhododendritestalk \\ 02:15, 8 June 2026 (UTC)[reply]
Well I certainly don't want to. :) I like birds and I like dinosaurs, but I very much don't like categorization. I guess, just in case it's useful, I oppose any categorization decision made on the basis of "birds aren't dinosaurs" but don't want a say in the finer points of categorization hierarchy. — Rhododendritestalk \\ 02:29, 8 June 2026 (UTC)[reply]
Birds are descended from dinosaurs, but are not themselves dinosaurs. Just as Homo Sapiens is descended from something dozens of millions of years ago, but is not that thing. Phil Bridger (talk) 21:39, 7 June 2026 (UTC)[reply]
Only in the colloquial sense. Birds are theropod dinosaurs. Humans descended from early mammals, and are still mammals. Humans are not Australopithecus just as birds are not Velociraptor, but humans are mammals and birds are dinosaurs. You don't evolve your way out of your ancestry. The above CfD wasn't closed as "birds aren't dinosaurs", but as "it shouldn't be directly in the dinosaurs category, because it is already in the dinosaurs category, several subcategories down". — Rhododendritestalk \\ 02:12, 8 June 2026 (UTC)[reply]
Ah thank you, I went up the Primate taxonomy tree instead. Looks like we do have a good comparative example. CMD (talk) 04:02, 8 June 2026 (UTC)[reply]
The main point here is that birds are dinosaurs (not "descended" from dinosaurs or "somewhat" dinosaurs, 100% dinosaurs and have been since they became birds), and films about birds are also films about dinosaurs. There is no difference except in the two words, and dinosaurs on Wikipedia are classified as two types: Avian dinosaurs and non-avian dinosaurs. The non-avian dinosaurs perished 68 million years ago while the avians, over 11,000 species of birds, went on to dominate, along with bats, Earth's airspace. Although there is disagreement here, past decisions have been heavily weighed down by editors insisting that birds are not dinosaurs, comments which should have been ignored. The use of the humans as monkeys, and other mammal comparisons, would only be accurate if humans were the only mammals left, and have been the only mammals that survived an extinction event and flourished for 68 million years. Thanks. Randy Kryn (talk) 12:55, 8 June 2026 (UTC)[reply]
And there was I, innocently thinking that the "en" in some Wikimedia projects meant "English", when it turns out that it really means "cladistic jargon". Phil Bridger (talk) 22:25, 8 June 2026 (UTC)[reply]
That's what I mean, those who don't believe that birds are dinosaurs would never include the categories being discussed here, and in order to do so they must ignore Wikipedia and use personal bias in a serious context (trying to get someone blocked is pretty serious, no?). Wikipedia recognizes that birds are dinosaurs, which is pretty much all we have to know to include films about birds in the category films about dinosaurs. WP:Common sense. Randy Kryn (talk) 10:20, 9 June 2026 (UTC)[reply]
Your main argument appears to be that the existence a scientific definition of a word causes the lay definitions to not exist. That's not how language works, but I think that what we would need to resolve this in your favor is some reason to believe that non-technical, non-expert readers would not be confused or even believe that Wikipedia had an error, if they found Daffy Duck in the same category/tree as a baby apatosaurus. WhatamIdoing (talk) 06:49, 10 June 2026 (UTC)[reply]
Well, this fellow is a joy and quick with blocking fellow Wikipedians. No, I did not revert "several more..." but I did revert MBH again because MBH started this discussion to resolve the matter and yet is reverting to enforce their opinion. Listing films about birds in the category films about dinosaurs is as logical as listing Category:Sun in Category:Stars. They're the same topic. Randy Kryn (talk) 10:13, 9 June 2026 (UTC)[reply]
Am I missing something? It seems like WP:CATDEF is clear on the matter: an article belongs in a category if RS regularly refer to them as thus. While it may be true that birds are dinosaurs, the question is whether the citations in articles about birds also regularly refer to them as being about dinosaurs. If so, then put it in. If not, then it's WP:SYNTH to put together "Category X is about Y. RS says Y is Z. So Category X is about Z." EducatedRedneck (talk) 15:43, 16 June 2026 (UTC)[reply]
I don't think that the spirit of WP:SYNTH really stretches to cover analytic truths, i.e., statements that are true simply because of the meaning of the words in them. It's not WP:SYNTH to use a source that says "X is a bachelor" to support the statement "X is unmarried", or to use a source that says "Y was born in Brooklyn" to support "Y was born in New York City". Now, in the latter case we'd probably put the article into Category:People from Brooklyn, which is a subcategory of Category:People from the New York metropolitan area. Doing that isn't WP:SYNTH, even if none of the sources explicitly say "New York metropolitan area". Stepwise Continuous Dysfunction (talk) 20:56, 16 June 2026 (UTC)[reply]
This is probably the wrong place for this but I don't know where else to ask: Does anyone else remember or use a tool which you could input the name of an article into and it would find other articles which mention that article but which don't have it linked? I've been searching for ages but I can't remember what it was called or if it even still exists. FishandChipper🐟🍟05:47, 8 June 2026 (UTC)[reply]
that would actually insert the links for you too Do you mean a tool that would edit the articles that mention the specified string on your behalf to insert links? I am pretty sure AutoWikiBrowser could do that, but I may be misunderstanding what you said. - BlueEleephant (talk · contribs) 16:39, 8 June 2026 (UTC)[reply]
Yes, thank you Edward. I would hope that you can negotiate a higher API limit (or multiple keys if that's infeasible) since you are providing a widely used service rather than just doing something expensive for your own ends. Certes (talk) 09:53, 9 June 2026 (UTC)[reply]
There are currently 10 infoboxes that use |alma_mater= in their code. Most of these also have |education=. This seems very confusing and un-necssary to me. When does one use |alma_mater= vs |education=? I am proposing that we simplify things and remove |alma_mater= entirely, merging any existing values with |education=. In the event that a given Infobox does not have |education=, I am proposing replacing |alma_mater= with |education= for consistency. This will not be a trivial task. Bots can certainly help, but ultimately will likely require a lot of manual edits.
Important note, {{Infobox sportsperson}} & {{Infobox person}} have dozens of wrappers calling them so this issue will affect hundreds of thousands of pages.
Merge to "education" parameter. Just using "education" whether what's known is precise or imprecise seems less confusing and easier for downstream consumers to parse. And "alma mater" seems like a phrase readers are less likely to be familiar with. -- Beland (talk) 20:21, 13 June 2026 (UTC)[reply]
Merge "alma mater" to "education". It's functionally the same thing but the "education" parameter is more flexible and more understandable. Dclemens1971 (talk) 20:40, 13 June 2026 (UTC)[reply]
Perhaps “Alma Mater” is used to indicate that the person not only attended, but graduated and received a diploma/degree from the school? Someone who attended Harvard for a year (but dropped out) could Harvard under “education”, but not “Alma Mater”? Blueboar (talk) 22:26, 13 June 2026 (UTC)[reply]
Er, no, actually, that's not the distinction that the documentation makes; it thinks alma_mater is for if the specific degree is unknown, and non-graduates generally don't have any college listed (with exceptions). Regardless, "education" can handle all these cases. -- Beland (talk) 22:46, 13 June 2026 (UTC)[reply]
Yeah, the guidance is kind of goofy. We're supposed to use education when we know the specific degree. {{Infobox officeholder}} has slightly different guidance and says education can even include with whom the officeholder trained. In both cases, if we only know the name of the institution but not the degree or other details, alma_mater is suggested. I see the logic but it doesn't seem particularly helpful. I looked at all 10 of these and the guidance is either similar or absent for most of these. And I just learned that there is MOS guidance on these. —Myceteae🌈 (talk) 23:31, 13 June 2026 (UTC)[reply]
If someone dropped out of Harvard, we can write |education=Harvard University (dropped out). If someone received a PhD from Harvard, we can write |education=Harvard University (PhD). We do not need |alma_mater=. Khiikiat (talk) 23:02, 13 June 2026 (UTC)[reply]
Bill Gates is the canonical example given in the documentation for a few of these templates and MOS:INFOEDU, and that is exactly how his article handles it. Although {{Infobox person}} currently says |alma_mater= should used while the MOS is silent on this. —Myceteae🌈 (talk) 23:49, 13 June 2026 (UTC)[reply]
Merge|alma_mater= to |education= per Zackmann's proposal. We do not need |alma_mater=. It is an entirely redundant parameter. Khiikiat (talk) 23:00, 13 June 2026 (UTC)[reply]
Merge|alma_mater= to |education=. The Bill Gates case uses education (since at least 4 June 2024). Alma mater is more common in American English [73]. Education should be preferred per MOS:COMMONALITY. We should also avoid redundancy in infobox parameters. Cinderella157 (talk) 02:34, 14 June 2026 (UTC)[reply]
Merge "alma mater" to "education". One is clear and easily understood. The other is very confusing, particularly "the last-attended higher education institution", especially in fields and countries where multiple institutions are relevant and where many graduates have subsequent qualifications from universities, some vocational (e.g. Graduate Diplomas in Law or Postgraduate Certificates in Education) , some taking courses for personal interest. For instance which was Gerald Gardiner, Baron Gardiner's "alma mater" - Magdalen College, Oxford where he took a Law degree before a lifelong career in the law (reaching the very top as Lord Chancellor) or the Open University where he took a Social Sciences degree in his mid 70s? Timrollpickering (talk) 11:01, 14 June 2026 (UTC)[reply]
Merge|alma_mater= to |education=. I agree with the prior rationales stated. While I had some hesitation, the more I think about this the more I confirm my initial sense that this is redundant and unhelpful. Cinderella157's additional point re: MOS:COMMONALITY provides additional support for this. —Myceteae🌈 (talk) 00:45, 15 June 2026 (UTC)[reply]
Hey all, second try at this! WikiLatinos is currently launching a campaign around the World Cup (which is already underway): Wiki Loves Fútbol. We'd like to enable a banner in the US for two weeks during the event, inviting people to edit topics around Latin American culture and the sport, as well as broader themes like culture and immigration in the US. Here's the list of target articles, and here's the Commons contest. Our overall goal is to reach as many people as possible with our mission using the love for the sport to do some edits. If anyone has objections to enabling the campaign, this is the place to voice them. Thanks! Oscar_. (talk) 23:04, 15 June 2026 (UTC)[reply]
Interested editors can see the CentralNotice campaign request on Meta-Wiki. The campaign at the requested settings would show this banner to all readers and editors in the United States for a duration of two weeks. It would appear a maximum of 3 times per browser-ish (it's cookie-based) per week, so 6 impressions over the course of the campaign. Best, Vermont (🐿️—🏳️🌈) 00:17, 16 June 2026 (UTC)[reply]
Even with the World Cup going on here and the Latin American connection, leading with fútbol (soccer) and restricting the ad to the US is an odd combination if you ask me. Sesquilinear (talk) 22:21, 16 June 2026 (UTC)[reply]
The connection is pretty well explained at Event:Wiki Loves Fútbol. The World Cup is a highly relevant event with special cultural significance among Latinos in the host countries and worldwide. Now obviously, the World Cup is significant in many countries or cultures, but this has special relevance in the 2026 host countries. The World Cup is a hook to generate edits to a particular topic area. Sort of like using Pride Month to generate edits for LGBTQ+ topics, broadly defined. —Myceteae🌈 (talk) 22:34, 16 June 2026 (UTC)[reply]
Connecting to Wikipedians in other languages/countries
Hello: I edit voluntarily, but also am a COI editor (the disclosure which you can find on my user page). I have recently been approached by someone who lives in the US but has media coverage in Dutch dating back to the 1990s. I suggested they inquire about a page on the Netherlands Wikipedia site. Similarly, I just spoke to someone in China in the same situation. Is there a way to connect these people with the Netherlands/Dutch, and Chinese wikipedia community, respectively? I appreciate any feedback and advice for them. Thank you, LeepKendall (talk) 21:36, 15 June 2026 (UTC)[reply]
Health Challenge 2026 - invitation and consent for CentralNotice
I would like to invite you to the now happening article writing challenge focused on health - Health Challenge 2026. Just write articles in (any) Wikipedia (ideally from the focus articles), list them on the challenge page and you may win valuable prizes (of course, beyond helping the next generation of global health ;)
Also, I would like to show a banner in this Wikipedia until the end of June 2026. You can see details at MetaWiki CentralNotice request. If you agree, just write here that you agree and I will carry the rest.
I thought we had some guideline about the inclusion (or not) of complete charts, but I can't find it. We have Wikipedia:Record charts, but that deals with which charts to include (and how) on pages about artists or records. But is there any guidance about whether the many pages like Billboard Year-End Hot Rap Songs of 2008, copying one chart completely, are acceptable or not? Fram (talk) 14:52, 17 June 2026 (UTC)[reply]
Note:The RFC is actually about Wikipedia:Superfluous bolding explained. The full location is: Wikipedia talk:Superfluous bolding explained#Request for Comment: enforcement. The RFC question is: Should this guideline be applied to every article? Are there any considerations we need to make for how this guideline is applied on different topics? @Qwerty123M, please be careful when leaving RFC notices to clearly state the page where the discussion is taking place/the page that the RFC applies to. Editors always need to click the link to "the discussion page" to see the full details but many editors quickly scan Village Pump (and similar venues) to see whether a topic is something they would be interested in and listing a completely unrelated page is unhelpful. —Myceteae🌈 (talk) 15:22, 22 June 2026 (UTC)[reply]
Following two weeks of the feature being in beta, the Reader Growth team is planning to roll out the Image Browsing feature to make it easier for logged-out mobile web readers to discover images in Wikipedia articles. This feature, which will go live this week, is part of our investment in reversing Wikipedia's decline in readership and satisfying the surveys of global internet users who report "more images/photos" on Wikipedia as a top reader request.
These screenshots show the carousel experience as well as the more deep-dive zoom effect.
The feature will add a carousel of an article's images just above the article lead paragraph. The feature will only be shown on articles with three or more images larger than 100px in both width and height, and only on mobile. The carousel is configurable by editors, who can decide to exclude images from the carousel or exclude articles from the feature entirely.
We added the following improvements to the feature in response to community feedback:
Controls for editors to exclude specific images from appearing in an article's carousel. To exclude individual images from an article, editors can add class=noviewer, which will also exclude that image from being shown in MediaViewer, or class=notpageimage, which will do the same and, in addition, exclude that image from use in thumbnails shown in search or link previews.
Controls for editors to exclude specific articles from getting the carousel at all. To remove the image carousel from an article, editors can add the magic word __NOMEDIAVIEWERCAROUSEL__.
A setting enabling logged-in users to turn off the image carousel for their account. This can be found by opening the hamburger menu at the top of any mobile web page to go to Settings → User preferences → Appearance.
Community members helped us find these bugs during the beta period, which have been fixed:
The image carousel needing to be suppressed when viewing diffs or revision history
Special characters in src causing images to be dropped from the carousel incorrectly
Instances of broken image exclusion logic
Errors causing article pages not to load
We are also grateful to everybody who has commented in a VPP discussion Image Browsing, and image hiding or has taken an interest in this project thanks to that discussion.
We started testing this feature in November 2025, originally with six wikis (Arabic, English, French, Indonesian, Vietnamese, and Chinese). Results were promising. We saw a high portion of readers tapping to engage with the carousel (7.8 - 8.7%, compared to the typical <5%) and statistically significant improvement in the percentage of readers coming back to the wiki after seeing the feature. We followed this up with a beta rollout in which we resolved 16 bugs as ~700 people tested the feature. We now feel confident that a full rollout for logged-out readers on mobile web will help more people enjoy reading Wikipedia and looking at images. After we deploy, we'll continue to monitor data and your feedback.
As we roll out to all logged-out readers, we invite you to try out and share your thoughts on the following experiences for logged-out readers on mobile web:
The image carousel
Option for editors to exclude specific images from the carousel for an article
Option for editors to remove the carousel from an article as needed on a per-wiki basis
Option for logged-in readers/editors to set their preferences to remove the carousel for themselves across all pages
We welcome thoughts on the opportunities you see with Image Browsing and consuming multimedia on wiki in general at the project talk page.
Hey, yes, in the wikicode - VE doesn't have any input field for adding classes. These classes look just like parameter values, so for example: [[File:Foo.jpg|thumb|Caption|class=notpageimage]]. SGrabarczuk (WMF) (talk) 13:18, 23 June 2026 (UTC)[reply]
You are aware that the image carousel doesn't "add more images" (what readers apparently wanted), just puts in a very obnoxious place, pushing the actual encyclopedic text down to prettify things? Please make this opt-in, not opt-out, and don't push WMF-designed layout over the layout created by the page writers.
It seems as if you have put more value on "what do readers want" (and then, like I said, not even translating this correctly to a change) and less on "what do people actually use Wikipedia for", where the #1 was "o fact check something", followed by learning, keeping oneself informed, and so on. For fun / to pass the time were way down the line. Why then has it been decided that making it more fun, more like a pastime, and less like a place to fact-check something, to learn something, was the way to go?
Added to this are all the issues with the Carrousel itself, as outlined in my reply to the announcement of the Beta test. Please don't roll this out, or at worst do it as an opt-in. Fram (talk) 13:46, 23 June 2026 (UTC)[reply]
RFC about AI-generated content in Wikimedia Commons
Comment: The best way to use AI I've found is as a reviewer. A prompt I've used is "You are an expert of ______ known for being harsh, precise, and demanding. You are asked to peer-review the following text: ____." Another is "You are an expert of _____ asked by a colleague to proof read their writing. Review the following draft and provide recommendations for improvement: ____." I use these as a filter before sending text off to be proofread by a human. I've found that changing "a colleague" to "your student" sometimes gives better results, but not always. This is the kind of use I can see AI being helpful with on Wikipedia, not generating original text. Fundamentally, Wikipedia was likely used to train most if not all of these models, so we're just feeding Wikipedia back into itself if we use it to liberally to generate new content. GeogSage (⚔Chat?⚔) 08:48, 14 June 2026 (UTC)
Agree —Myceteae🌈 (talk) 17:37, 22 June 2026 (UTC)
You are invited to join the discussion at Wikipedia talk:WikiProject Council § Proposing a new WikiProject Intellectual Diversity. George Ho (talk) 06:29, 19 June 2026 (UTC)
Resolved
Moved to Module talk:Location map § Proposal to refactor the way Template:Location map works in Infoboxes
Courtesy pings: Joy, JMF, Jonesey95, Hike395, Primefac, Gonnym, Jessicapierce, GreenLipstickLesbian, Johnuniq, Phuzion, Plastikspork who I feel may have opinions on this, but of course ALL inputs welcome!! --Zackmann (Talk to me/What I been doing) 17:39, 22 June 2026 (UTC)
Zackmann (Talk to me/What I been doing) 18:52, 22 June 2026 (UTC)
View all 32 community-submitted tasks that were resolved last week.
12th & Imperial 
which doesn't make any sense to me.
Done. - BlueEleephant (talk · contribs) 01:14, 21 June 2026 (UTC)
... but teacher has always said to never leave a blank edit summary! I too have a user script that alerts me to a blank summary. If there is an automatic feature that is designed to make a better edit summary, then the edit summary box should clearly and dramatically indicate this. Not sure how that would work technically, but the edit UI needs to be very clear when/if a blank summary is encouraged — GhostInTheMachine talk to me 11:03, 21 June 2026 (UTC)
Courtesy link: Template talk:Infobox country § Religion in Infobox country —Myceteae🌈 (talk) 02:40, 20 June 2026 (UTC)
1. The "Report" button, as shown in the Tools menu (see arrow).
2. The "Report" button, as shown in the overflow menu in a comment thread (for users with the Discussion Tools beta feature enabled).
3. The full set of categories of potentially unwanted behavior that an editor can pick from.
4. Support information for users reporting potential bullying.
5. Support information for users reporting potential sockpuppetry.
.png)
wikimedia.org. For questions about the Wikimedia Foundation's work, contact us!
can be present in both editors no issue (well, not any more with this new, worse icon version, but you get my point) but as soon as you include it on a random page, then it needs the full MIT licence linked somewhere to be fine to use. stjn 18:59, 17 June 2026 (UTC)
Note: There is guidance on using these parameters at MOS:INFOEDU. I will place a notice at Wikipedia talk:Manual of Style/Infoboxes about this discussion. —Myceteae🌈 (talk) 23:32, 13 June 2026 (UTC)
.svg&file=20260530181755!The_Plastic_Man_Comedy-Adventure_Show_(logo).svg){kind=link}
