Jump to content

Wikipedia:Village pump (WMF)

From Wikipedia, the free encyclopedia
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The WMF section of the village pump is a community-managed page. Editors or Wikimedia Foundation staff may post and discuss information, proposals, feedback requests, or other matters of significance to both the community and the Foundation. It is intended to aid communication, understanding, and coordination between the community and the foundation, though Wikimedia Foundation currently does not consider this page to be a communication venue.

Threads may be automatically archived after 14 days of inactivity.

Behaviour on this page: This page is for engaging with and discussing the Wikimedia Foundation. Editors commenting here are required to act with appropriate decorum. While grievances, complaints, or criticism of the foundation are frequently posted here, you are expected to present them without being rude or hostile. Comments that are uncivil may be removed without warning. Personal attacks against other users, including employees of the Wikimedia Foundation, will be met with sanctions.

« Archives, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13

Temporary accounts: Post deployment

[edit]

After deployment

[edit]

Now deployed! ~2025-31082-27 (talk) 08:15, 4 November 2025 (UTC)[reply]

This appears to have been our last ever IP edit: Special:Diff/1320371783
(I'm the same person as the previous message, but I closed my incognito tab between that message and this one. When I tried to post this in my new incognito tab, I saw the message "Visitors to Wikipedia using your IP address have created 1 accounts in the last 24 hours, which is the maximum allowed in this time period. As a result, visitors using this IP address cannot create any more accounts at the moment." Isn't the limit meant to be 6 accounts per 24 hour period?) ~2025-30907-85 (talk) 08:26, 4 November 2025 (UTC)[reply]
I believe there's a rate limit of one every ten minutes. (Testing ping to ~2025-30907-85, hope this works) Perfect4th (talk) 08:29, 4 November 2025 (UTC)[reply]
This appears to be a bug. We're looking into it. There is a limit of 1 every 10 minutes with a maximum of 6 temp account creations allowed every 24 hours. -- NKohli (WMF) (talk) 09:30, 4 November 2025 (UTC)[reply]
This is now fixed via https://phabricator.wikimedia.org/T409161 KHarlan (WMF) (talk) 12:23, 4 November 2025 (UTC)[reply]
Things like Wikipedia:Sockpuppet investigations/~2025-31011-02 and Wikipedia:Sockpuppet investigations/~2025-30821-77 show that many editors don't seem to be aware of temporary accounts being deployed. Should we send the mass-message to everyone? Children Will Listen (🐄 talk, 🫘 contribs) 13:09, 4 November 2025 (UTC)[reply]
I threw up a message on MediaWiki:Recentchanges-summary. Sohom (talk) 13:18, 4 November 2025 (UTC)[reply]
Yeah, I don't think I would have been aware either if I didn't watch some admin talk pages many years ago. In other issues, I'm interested to see how LTA behavior will change in response to this. For example, will Andrew5 start clearing his cookies or use throwaway accounts instead (as I personally believe he already has, but this isn't a place to discuss that in detail)? wizzito | say hello! 13:22, 4 November 2025 (UTC)[reply]
Also want to clarify sth: IP ranges/addresses that are currently blocked are unable to create temporary accounts, correct? wizzito | say hello! 13:32, 4 November 2025 (UTC)[reply]
They usually aren't, except if file an unblock request on their user talk page (but in this case they can only edit their user talk page and only as long as the option to block talk page access isn't enabled) -> phab:T398673. Johannnes89 (talk) 17:44, 4 November 2025 (UTC)[reply]
Special:IPContributions/122.171.23.189 is exactly what I was concerned about way above. Never made it to AIV because it was three different accounts so they never got warned enough. ScottishFinnishRadish (talk) 15:28, 4 November 2025 (UTC)[reply]
Also worth noting this was the first temporary account I looked at. Bodes well for how this will work in practice. ScottishFinnishRadish (talk) 15:36, 4 November 2025 (UTC)[reply]
This also adds significantly more time than I originally estimated. As a for instance, you need another page load to go from the temporary user IP contribution page to the IP contribution page if you want to use twinkle to place a block. ScottishFinnishRadish (talk) 16:33, 4 November 2025 (UTC)[reply]
That sounds like a description of a feature request to the Twinkle developers. RoySmith (talk) 16:41, 4 November 2025 (UTC)[reply]
Sounds like something that probably should have been addressed before a major rollout. This isn't a minimum viable product situation, this is the production environment on one of the top 10 visited websites in the world, and this seriously affects anti-abuse efforts which are entirely undertaken by volunteers. ScottishFinnishRadish (talk) 16:45, 4 November 2025 (UTC)[reply]
Doesn't blocking a TA autoblock the IP address? SuperPianoMan9167 (talk) 16:46, 4 November 2025 (UTC)[reply]
WP:AUTOBLOCK: There is an internal autoblock expiry time variable, which is set to 24 hours, meaning that autoblocks that are automatically applied will only last for that amount of time and will expire afterwards.
That's just another issue, you have to look at the IP to see the history of editing to determine how long a block should be. It essentially adds a "check the IP" step to every temporary account block, which then adds an additional "Legacy IP edits" step to see the history from the IP, as the IP editing history is on a different page than the IP editing history since temporary accounts were created. Luckily this task only has to be completed ~10,000 times a month, so adding 30 seconds to a minute only adds 80-160 hours of volunteer burden a month. ScottishFinnishRadish (talk) 16:52, 4 November 2025 (UTC)[reply]
Why do you need to do that? When you encounter a vandalizing account you also don’t perform CU to check if there are other sockpuppets. Just block the TA indefinitely like any regular vandal account and only care about their IP / IP range if you observe a pattern of abusive behavior with multiple TA. Johannnes89 (talk) 16:55, 4 November 2025 (UTC)[reply]
The vast majority of reports at AIV were IPs. I look at the history of each to determine the correct block length. The point is to prevent disruption, not to allow someone to vandalize until they are blocked (assuming they're not changing their temporary account to avoid scrutiny and never get blocked) every 24 hours. ScottishFinnishRadish (talk) 17:09, 4 November 2025 (UTC)[reply]
You should treat vandalizing TA the same way as vandalizing accounts. If you would issue an indefinite block for a regular account, do the same with the TA. There's no point looking up the IP unless you suspect long-term abuse. Just as we rely on autoblock when it comes to blocking regular vandal accounts, autoblock is also sufficient in most cases when it comes to TA vandals.
To put things in perspective, some stats from other large wikis on IP reveal usage in the last 24 hours, based on Special:Log/checkuser-temporary-account:
  • ~20x on plwiki
  • ~90x on zhwiki
  • ~100x on jawiki
  • ~150x on dewiki
  • ~170x on itwiki
  • ~330x on frwiki (but ~200 of those from a single non-admin patroller who seems to use IP reveal much more often than anyone else on any project I've seen so far)
Those numbers used to be higher when TA got introduced on each project but after some time people realized that they need to look up the IP less often than we thought in the pre-TA time. Johannnes89 (talk) 18:07, 4 November 2025 (UTC)[reply]
You should treat vandalizing TA the same way as vandalizing accounts. If you would issue an indefinite block for a regular account, do the same with the TA. There's no point looking up the IP unless you suspect long-term abuse. That's entirely incorrect. If we're trying to prevent disruption then checking the editing history of the IP is a must. That log is also very inaccurate, I just checked the IPContributions page, revealing the temp accounts, of half a dozen IPs and it logged a single action. As I said, literally the first TA I looked at today was abusing the ability to reset their account to commit personally targeted bigoted vandalism. They had far surpassed the point where they would have been at AIV, but due to the way temp accounts work, they hadn't been reported. ScottishFinnishRadish (talk) 18:42, 4 November 2025 (UTC)[reply]
Entirely incorrect? That's precisely what Wikipedia:Temporary accounts#Impact for administrators says and matches my experience dealing with TA for almost half a year on my home wiki.
There's simply no need to check the IP for every TA just to make sure they haven't been operating other TA's on the past – based on your way of thinking you would also run CU on every vandalizing account just to make sure they haven't used other vandal accounts?
I would be curious to see which TA you are talking about (we could also continue discussing the specific example offwiki). Personally targeted bigoted vandalism that sounds to me like a something people could report no matter how many times the TA vandalized. Blocking one TA would have stopped the vandal due to autoblock – no matter how many other TA they created (blocking old TA once the vandal has moved on already is also not needed by the way, they can't re-used old TA once they abandoned them). Johannnes89 (talk) 19:01, 4 November 2025 (UTC)[reply]
SFR linked the specific IP in the first comment he made in this section. Izno (talk) 19:06, 4 November 2025 (UTC)[reply]


Is there really no way to see ips short of tracking down the edit on recentchanges or the watchlist? Nothing in history or diffs or Special:Contributions (for the temp account - though at least on that, I get the ipinformation collapsed box, with everything except the ip itself), and even turning on autoreveal doesn't do anything. —Cryptic 17:18, 4 November 2025 (UTC)[reply]
@Cryptic Show IP is displayed for me in page histories, user contributions, and in diffs. Sam Walton (talk) 17:22, 4 November 2025 (UTC)[reply]
Apparently skin-specific. hist, contribs, diff. —Cryptic 17:26, 4 November 2025 (UTC)[reply]
I can’t tell what skins work or don’t work. Doug Weller talk 14:00, 5 November 2025 (UTC)[reply]


Way up above, I was one of several people to express concerns about the fact that IP addresses are only stored for ninety days. I just found and reverted some fairly severe vandalism from May last year; if temporary accounts had been used then, that edit would've been even harder to track down without going to the article in question and checking the page history. Here's what happened; today I came across an IP address on my watchlist that turned out to be part of a problematic school IP range, 168.212.0.0/16. I noticed that the range had been blocked several times. I know many people wouldn't go to the lengths of doing this, but I audited all edits from that range since the expiry of the last block in April 2024, which is how I found that vandalism among other things that escaped the three-month window. I messaged the admin who had previously blocked the range and he re-blocked it. These sorts of problems are why I think that with temporary accounts the way they are now, we should be more severe with blocks of school IP addresses, because by default they'll be firehoses of vandalism. Feel free to move this message if it'd be more suitable somewhere else. Graham87 (talk) 15:19, 8 November 2025 (UTC)[reply]

And some of our worst IP hopping vandals, including this one, are just blasting right through temporary accounts; I hoped this rollout would help stop some of these people, given that cookies are connected to accounts now, but oh well... wizzito | say hello! 23:55, 11 November 2025 (UTC)[reply]
One thing we should have done was made people unable to log out of temporary accounts unless they forced it themselves (e.g. clearing browser cookies). This would have probably stopped some vandalism. wizzito | say hello! 00:07, 12 November 2025 (UTC)[reply]
You can log out of a temporary account??? CMD (talk) 02:25, 12 November 2025 (UTC)[reply]
It looks like you can by going to Special:UserLogout RoySmith (talk) 02:32, 12 November 2025 (UTC)[reply]
Another fun fact: it looks like a TA gets created when you try to make an edit, even if it fails. In my case, I opened an incognito window, tried to edit WP:Sandbox and hit an edit conflict. Ended up creating a TA with zero contributions and zero log entries. RoySmith (talk) 02:50, 12 November 2025 (UTC)[reply]
We need to create a temp account for anything that can generate a log entry. On the positive side, perhaps this will be more useful as a signal when examining a temporary account (e.g. for https://phabricator.wikimedia.org/T409396) KHarlan (WMF) (talk) 07:13, 12 November 2025 (UTC)[reply]
Yeah, there's an "Exit Session" link in the top right corner. This is top level in Vector 2010 and in a menu in Vector 2022. –Novem Linguae (talk) 14:33, 12 November 2025 (UTC)[reply]
Is there a reason we want this, and is there any indication to the TAs that if they do not exit session it will boot them out anyway in 90 days? CMD (talk) 14:57, 12 November 2025 (UTC)[reply]
The link shows 15 edits, with 14 of them by one account and 1 edit by another account. Are there other accounts associated with this vandal? For vandals who change IPs, is the activity you've linked to similar to what one would have seen with legacy IP edits, the difference being that the activity is partially obscured because there are two different accounts externally visible, rather than a single IPv6 /64 range? KHarlan (WMF) (talk) 07:18, 12 November 2025 (UTC)[reply]
KHarlan (WMF), there are 3 TAs on that range, not 2. 45dogs (they/them) (talk page) 07:29, 12 November 2025 (UTC)[reply]
You are right, sorry about that. Yes, the first edited over the course of ~60 minutes, then a second account edited once ~90 minutes after the first one stopped editing, and a third one created 11 minutes after the second one. KHarlan (WMF) (talk) 07:33, 12 November 2025 (UTC)[reply]
KHarlan (WMF) The thing is: the first TA was blocked a minute after that 60 minute period. Another account showed up about 2 hours after that and kept on editing, presumably because the user was able to switch to another device or simply... log out? wizzito | say hello! 09:58, 14 November 2025 (UTC)[reply]
The former solution would have been to block the /64 from the beginning, which would have prevented the edits from 20:09 - 20:56 from being made. wizzito | say hello! 09:59, 14 November 2025 (UTC)[reply]
Or even block the IP in general, since only one IP on the /64 was used for all 15 edits. Given how IPv6 works, it suggests to me like the vandal just logged out to avoid scrutiny instead of switching devices. wizzito | say hello! 10:02, 14 November 2025 (UTC)[reply]

Twinkle and Special:Block aside

[edit]
In response to Wikipedia:Village pump (WMF)#c-ScottishFinnishRadish-20251104163300-ScottishFinnishRadish-20251104153600

As an aside, long-term I think we will want to move away from using Twinkle for blocks and have everyone use Special:Block. I wrote the Twinkle block module 10 years ago as a way to block and issue a talk page template at the same time. That was the extent of it. Over the past decade, we've painfully been trying to maintain feature parity with Core. Now we're at a point where it's the opposite, and Core is missing functionality that's in Twinkle (phab:T392857). It will still be a "while", but the plan is to continue on with that effort and eventually there will be no need for Twinkle at all.

I guess just keep this in mind. Anything that you think Twinkle does better, please file a task or let me know, and we'll get it tracked. Ultimately I hope that, apart from browsing contributions or checking talk pages, admins will never need to leave Special:Block to do their job. — MusikAnimal talk 19:01, 4 November 2025 (UTC)[reply]

Twinkle's present killer feature are prefills and templates. It's also convenient that it's a dialog rather than a whole separate page. Izno (talk) 19:09, 4 November 2025 (UTC)[reply]
The dialog is the big thing. I'd rather never open special:block and take action from a dialog on the contribs page. ScottishFinnishRadish (talk) 19:14, 4 November 2025 (UTC)[reply]
+1 KevinL (aka L235 · t · c) 19:18, 4 November 2025 (UTC)[reply]
This is one of those things that happens 10,000+ times a month, so seconds add up to hours pretty quick. From the contribs page, it takes about 3-5 seconds to block through twinkle, including selecting the reason filling out the template. Just having to click and load Special:Block would double that time, and that's without filling things out, and then placing the template. ScottishFinnishRadish (talk) 19:25, 4 November 2025 (UTC)[reply]
A dialog is great, but it can't give you all the information you need with such limited space. For example, Twinkle only reports if there was any past block and gives only one set of details (and even then there are bugs!). I suspect most of us want to see the full log if there were any previous blocks. Special:Block does this, and likewise for any active range blocks.
The templates, prefills etc. are part of phab:T392857. That would indeed be a requirement if we were ever to retire Twinkle. Fortunately virtually ever wiki has this or a similar workflow, so it seems it's time to bring it to Core! :) Once we have that, I suspect you'll find Special:Block just as convenient as it will be designed as a "one-stop shop" for all things blocking. Heck, we could even throw in the contributions there in another accordion.
Anyway, fret not, as this is a long ways away. We'd need design and user research, a full product treatment, etc. Besides, Twinkle is a gadget which we as a community are free to continue to use and maintain. I just don't know if I will be able to maintain it, is all! The multiblocks project was a massive effort. I didn't have it in me to parity that in Twinkle. Especially after hearing the affirmation from @Novem Linguae, I figure engineering resources are better spent on Special:Block so that all wikis get the same benefits. — MusikAnimal talk 03:11, 5 November 2025 (UTC)[reply]
Yes, I almost framed it as that big for me also. Special:Block isn't especially slow if it had the parity of prefill/template, but having to make the context switch Sucks. Izno (talk) 19:27, 4 November 2025 (UTC)[reply]
Oh yeah, the other big feature: Twinkle drops a block notice on the talk page. Izno (talk) 00:15, 5 November 2025 (UTC)[reply]
What Izno and SFR said, essentially. Unfortunately for you, the software you wrote is good as hell and everybody finds it more usable than the other thing... jp×g🗯️ 22:24, 4 November 2025 (UTC)[reply]
Which is also software he wrote. Either way he's a winner! ScottishFinnishRadish (talk) 22:26, 4 November 2025 (UTC)[reply]

Another Twinkle feature for sending a message to IP users is (was) the Shared IP notice. One could use the WHOIS link to fill out the name of the owning org. I guess this feature is no longer meaningful. But if a shared IP is blocked, how would an editor from that IP be able to know this in advance? David Brooks (talk) 22:42, 4 November 2025 (UTC)[reply]

Distinguishing individual accounts

[edit]

The very, very similar temp account names make it a lot harder to spot the same editor in e.g. recent changes (not always easy with IPs, but at least often a lot easier than it is now). I didn't spot the pattern of edits from here in recent changes, would probably have been easier before today. Fram (talk) 16:15, 4 November 2025 (UTC)[reply]

This seems like a perfect opportunity for some add-on script which assigns colors to TA account names in the various listings. Perhaps as a hash of the account name, so they're stable across listings. I'm guessing it would be a no-brainer for somebody who is good at javascript. RoySmith (talk) 16:20, 4 November 2025 (UTC)[reply]
Adding such a script to mw:Trust and Safety Product/Temporary Accounts/Repository might be valuable for other projects. There’s already a script for highlighting the last three digits of TA user names in order to make it easier to spot edits from the same TA. Johannnes89 (talk) 17:00, 4 November 2025 (UTC)[reply]
I'll try to make that. Aaron Liu (talk) 17:07, 4 November 2025 (UTC)[reply]
It looks like in both RecentChanges and RevisionHistory the TA accounts have class=mw-tempuserlink, so you can key off that. RoySmith (talk) 17:12, 4 November 2025 (UTC)[reply]
Or, instead of colors, add an Identicon. RoySmith (talk) 17:26, 4 November 2025 (UTC)[reply]
I don't think these are easy to distinguish at such small sizes. Aaron Liu (talk) 17:56, 4 November 2025 (UTC)[reply]
Remember that a non-negligible number of people is colour-blind. Phil Bridger (talk) 11:16, 9 November 2025 (UTC)[reply]
It's not like there's a requirement for only one script though. A person with normal color vision could use a color-based script, one with color blindness but good acuity could use an icon-based script, etc. Anomie⚔ 15:14, 9 November 2025 (UTC)[reply]
I agree. I was trying to prompt those with more technical knowledge than I have to do even more work. Phil Bridger (talk) 15:55, 9 November 2025 (UTC)[reply]
One lunch later: User:Aaron Liu/TemporaPaint.js currently would give a text color. Sometimes the differences are small, though, so I plan to later add an inverted background color (which should also help readability a little) and maybe use a different hash function. Aaron Liu (talk) 17:54, 4 November 2025 (UTC)[reply]
Fixed color inversion. Aaron Liu (talk) 18:02, 4 November 2025 (UTC)[reply]
Hmmm. Some of the color combinations don't work very well, making the underlying text impossible to read. RoySmith (talk) 22:45, 4 November 2025 (UTC)[reply]
I made a simpler version with just CSS. It works at Special:RecentChanges even with Live Updates. It's keyed off the last digit, and all my color combinations have a contrast greater than 5.13: Special:Contribs/~2025-31439-70, Special:Contribs/~2025-31439-71, Special:Contribs/~2025-31439-72, Special:Contribs/~2025-31439-73, Special:Contribs/~2025-31439-74, Special:Contribs/~2025-31439-75, Special:Contribs/~2025-31439-76, Special:Contribs/~2025-31439-77, Special:Contribs/~2025-31439-78, Special:Contribs/~2025-31439-79. VectorWorld (talk) 13:57, 5 November 2025 (UTC)[reply]
I've made my own version, User:Seercat3160/ColourfulTemporaryAccounts, as a fork of yours. It has (in my opinion) better colours, and it works on pages that update (e.g. recent changes). I've made a comparison table on my documentation page, if anyone would like to take a look. Seercat3160 (talk) 10:40, 9 November 2025 (UTC)[reply]
As one of the many colour-blinds :) I've created my own text-based version that gives the temp user a replacement human-readable username. It's deterministic so a user should always get given the same username each time they're seen (although there is a risk of collisions, such that two users might be given the same name, albeit quite unlikely.) User:JeffUK/VerboseTemporaryAccounts.js - Wikipedia JeffUK 09:41, 11 November 2025 (UTC)[reply]
Very cool. I was actually considering writing this myself but you've done a better job at it than I could. I've added it to my comparison table for anyone interested. Seercat3160 (talk) 09:55, 11 November 2025 (UTC)[reply]
@Seercat3160 You should add de:Benutzer:Aka/tempkontfett.js to your table. --Ahecht (TALK
PAGE) 18:10, 12 November 2025 (UTC)[reply]
@Ahecht: Done. Seercat3160 (talk) 21:57, 12 November 2025 (UTC)[reply]
I created another CSS-only version (see User:isaacl/style/temporary-account-names) that inserts a bi-colour square next to temporary account names on history pages, and next to links to contributions from temporary accounts. It uses a very simplistic heuristic to detect links so it may produce false positives or negatives. (The implementation is subject to change as I gain more experience with it.) isaacl (talk) 04:24, 14 November 2025 (UTC)[reply]
I added a mockup to the documentation page that roughly shows how it looks on signatures. isaacl (talk) 00:17, 15 November 2025 (UTC)[reply]
Yeah, I came back after a break to do a little recent changes patrolling and honestly thought someone had set a few thousands bots on us....!. There needs to be a 'Temporary User' notification somewhere on the Temp user pages, Contribution pages, and Talk pages, to make it abundantly clear that this is a temporary user User contributions for ~2025-32507-53 - Wikipedia, and that this is not. User contributions for -2025-40404-6O - Wikipedia. It should also be clear from the signature that the IP user is a temporary account, or I can easily see people getting very confused about who they're talking to, a load of temporary users with nearly identical names commenting on an article, for instance, is going to be very hard to parse; requiring a user script to be manually installed to patch this is not acceptable, this will confuse new (and returning, source:me) users who won't know they need to do that.. JeffUK 10:39, 10 November 2025 (UTC)[reply]

Autoblocks

[edit]

Before temporary accounts were introduced, most IP blocks used to be anon. only, which means they don't affect registered users operating under that IP/range. However, if a temporary account gets blocked, it'll autoblock any registered user using the same IPs for 24 hours (unless the admin unchecks autoblock, which most aren't right now). I'm not sure if this'll cause significant problems, but I'm putting it out here so people can be aware. Children Will Listen (🐄 talk, 🫘 contribs) 04:44, 5 November 2025 (UTC)[reply]

Blocked from Draft namespace

[edit]
Tracked in Phabricator
Task T409366

Logged out editors can no longer create draft articles. See Wikipedia:Village pump (technical)#Page creation disabled in DRAFTspace for temp accounts?. --Ahecht (TALK
PAGE) 23:04, 5 November 2025 (UTC)[reply]

Resolved
a patch has been pushed in the recent backport window. temp accounts now should be able to create draft articles. – robertsky (talk) 08:18, 6 November 2025 (UTC)[reply]

Active users jump

[edit]

The Special:ActiveUsers count (NUMBEROFACTIVEUSERS) which appears on the Main Page has sharply jumped in the last few days, from around 115 thousand on November 3 to 140 thousand on November 7, because temporary accounts are now included, but IP addresses have not been listed. This number will probably fluctuate a lot in the future, because of how easy it is to create a new temporary account, so it could be more consistent with the magic word's previous behaviour to exclude them from the count. Xeroctic (talk) 08:35, 7 November 2025 (UTC)[reply]

T339291: Should temp users be counted as registered & active users on Special:Statistics? is a related task. KHarlan (WMF) (talk) 08:38, 7 November 2025 (UTC)[reply]
They also show at Special:ListUsers (also different from IP addresses), so they may need removing from that count/list as well. Xeroctic (talk) 13:57, 7 November 2025 (UTC)[reply]
I used their appearance in the listusers page to help make the entry about them at Wikipedia:Wikipedia records. Temporary accounts have user ID numbers, etc., just like registered users. Graham87 (talk) 14:45, 8 November 2025 (UTC)[reply]

User page missing any identifier that accounts are temporary

[edit]

For IP users it's quick and easy to tell that you're looking at an IP user, for temporary accounts they're indistinguishable from a normal account, unless you happen to know that a ~2 in the name means temporary. Requiring this special knowledge is a developer hack not a robust user-friendly solution. We need "Temporary User" in big letters on the Temporary Users' User Page, Talk Page, Contributions, and default signature, for this to even be remotely workable. JeffUK 10:44, 10 November 2025 (UTC)[reply]

The user info card does show a different icon for temporary accounts compared to regular accounts. 45dogs (they/them) (talk page) 21:28, 10 November 2025 (UTC)[reply]

Thank you to Trust & Safety Product Team

[edit]

@NKohli (WMF): I know some people hate temporary accounts and the rollout has had some hiccups (which isn't surprising for such a huge technical change), but personally I think this is a change for the better, both from a privacy and legal compliance perspective. Despite the roll-out bugs, I think this feature could easily have been a total disaster if the Trust & Safety Product Team had not spent the past six years carefully planning its implementation, along with all the supporting tools that were needed for mitigating its impact. This is probably the biggest technical change to Wikipedia in the past decade and despite some predictions otherwise, the sky is not yet falling. So I would like to say thank you to the Trust & Safety Product Team for your hard work and collaboration with the community to roll out this monumental change. That is all. Nosferattus (talk) 08:10, 12 November 2025 (UTC)[reply]

TSP's (now PSI's) work on mw:Extension:SecurePoll has also been very helpful. They're a great team. –Novem Linguae (talk) 19:22, 12 November 2025 (UTC)[reply]

Assessment of an old time regular's experiment with TAs

[edit]

I didn't want to write an alternative version but was invited here to share my experience. I will simply link the impression that I posted when deciding to stop using TAs for now. The outgoing IP address of the system in use is about to be changed, so I'll just share it now: [1]. The title was humorous, not polemic. Thanks. ~2025-35304-53 (talk) 14:20, 27 November 2025 (UTC)[reply]

Would you prefer banning anonymous edits instead of temporary accounts?

[edit]

The discussion above about temporary accounts is quite heated. It's clear that there is some opposition, but I'd like to know if it's a majority of editors or just a couple of loud critics. I don't think it will change anything, as WMF never asked our opinion and made it clear that it will introduce temporary accounts regardless of what we say, but I think it is important to register what our opinion is. Furthermore, I think both alternatives are undesirable, but the legal situation forces us to choose one of these paths, so I'm asking a simple yes/no question to focus the debate and facilitate counting. Tercer (talk) 08:57, 8 October 2025 (UTC)[reply]

How will asking the same question in the same forum, read by the same audience, enable you to determine whether it is "a majority of editors or just a couple of loud critics"? --Elmidae (talk · contribs) 09:49, 8 October 2025 (UTC)[reply]
The question hasn't been explicitly asked before. We have lots of back and forth above, about several different subjects. And yes, I'm interested in the opinion of the editors that participate in this forum, who haven't expressed it clearly or didn't participate in the above discussion (that includes you). If you want to advertise this topic in other forums to get a wider participation that would be great. Tercer (talk) 10:06, 8 October 2025 (UTC)[reply]
Like Elmidae, I have not contributed to the "Temporary accounts rollout" thread and do not plan to. WP:PETITION disfavors such yes/no questions "since they not only encourage the community to avoid meaningful discourse and engagement, but also limit their scope to only one initially-stated opinion or preference with little or no opportunity for discussing and reconciling competing or opposing points of view." Even if you had 60% of a whopping 1000 respondents to vote for banning IP edits rather than introducing temporary accounts, that would be insufficient for our consensus-based model. ViridianPenguin🐧 (💬) 17:09, 8 October 2025 (UTC)[reply]
What is definitely insufficient for our consensus-based model is WMF's imposition of temporary accounts without asking for our opinion or giving us any alternatives.
A cornerstone of our consensus-based model are WP:RfCs, which do involve asking editors what their opinion is. Perhaps I should have started one straight away instead of trying to gather opinions informally. Then at least I wouldn't have had two responses that are only talking about format instead of the subject matter. Tercer (talk) 17:38, 8 October 2025 (UTC)[reply]
Decisions of the WMF are exempt from consensus. SuperPianoMan9167 (talk) 14:43, 9 October 2025 (UTC)[reply]
I think we're asking this question too early. I think we should let temporary accounts roll out, then if it goes poorly, someone will likely propose an RFC to ban logged out editing at that time. However, WMF has rolled out temporary accounts to most other wikis now, and those wikis haven't imploded. I think that is good evidence that temporary accounts won't create a vandalism catastrophe, and that we can continue to permit logged out editing. –Novem Linguae (talk) 00:47, 9 October 2025 (UTC)[reply]
As a matter of fact I believe that editors should make the decisions about Wikipedia, not WMF. It is not too early, it is too late, because the decision has been made without our input and will be implemented regardless. As for the other wikis, we have seen feedback only from a single editor from a single wiki, and it was very negative. That's not good evidence, but it is evidence of the opposite of what you claim. Tercer (talk) 09:19, 9 October 2025 (UTC)[reply]
@Tercer: The vast majority of WMF wikis have already implemented temporary accounts. As an administrator at en.wikibooks, I can express a positive experience. JJPMaster (she/they) 16:29, 14 October 2025 (UTC)[reply]
I can confirm that is also the case with Wikibooks and Meta-Wiki (I hold admin privileges on both projects). Codename Noreste (discuss • contribs) 16:36, 14 October 2025 (UTC)[reply]
Thanks for chiming in. Can you elaborate on what was positive about it? Tercer (talk) 16:52, 14 October 2025 (UTC)[reply]
Specifically, the addition of IP info variables to AbuseFilter has been quite beneficial. JJPMaster (she/they) 11:33, 21 October 2025 (UTC)[reply]
Reacting once an implosion has occured is too late. How is a community going to recover from said implosion anyway?
In phab:T364073 the Lithuanian Wikipedia disabled Content Translate because it had so many edits that the admins could not keep up.
Writing that, temporary accounts are not that bad. If an temporary account vandal ip hops without invalidating the account one ban is enough, while one ban per ip, or an rangeblock (if the ip's are close enough together without collateral damage) would be needed now. Tempoarary account vandals become hard when they invalidate their accounts. I checked the Norwegian Wikipedia in June/July and compared ip's in months of last year compared to temporary accounts in the same month of this year. I found out the ratio hovers around 1:1, with occasional spikes to 2 temp accounts per ip. That spike is normal to me, because temp accounts only exist for 90 days maximum. For an IP hopping, temporary account invalidator, there is always IP auto-reveal mode which shows for admins IP's in recent changes as they are shown now for a limited time. Snævar (talk) 13:58, 9 October 2025 (UTC)[reply]
Please stop talking about banning IP edits until the new system has had a six months trial. People have tried banning IPs in the past and it gets quickly shot down. Repeating the half-baked proposal is counterproductive because it biases people such that they reflexively vote no next time, rather than examine the issue yet again. Johnuniq (talk) 00:56, 9 October 2025 (UTC)[reply]
What about "Please stop talking about introducing temporary accounts until we do a six months trial of banning IP edits"? Unlike temporary accounts, that would be very easy to implement, and very easy to reverse, so we could actually have a trial. You know very well that temporary accounts is not a trial, it will not be revisited after six months.
And frankly, there's nothing "half-baked" about banning IP edits. It's technically simple, and has been done already. What else do you need to consider it fully baked? Tercer (talk) 09:23, 9 October 2025 (UTC)[reply]
All discussion prior to implementation will be entirely overshadowed by what actually happens when they're implemented. Either they will work out ok or they will make it to difficult to counter disruptive editing and will have to be limited somehow. Realistically I don't believe there is enough evidence to say for certain what will happen, but given the feedback I've seen from the WMF and the experience of other smaller Wikis I think it should be ok. -- LCU ActivelyDisinterested «@» °∆t° 19:52, 9 October 2025 (UTC)[reply]
I don't think the impact will be large, but I'm certain it will be unambiguously negative. And I think that when Wikipedia is under attack from very powerful people, including the US government, WMF should be making the life of malicious actors harder, not easier. Tercer (talk) 19:50, 10 October 2025 (UTC)[reply]
While I’m not a fan of temporary accounts for LTA/sock-tracking purposes (IP geolocation is a cornerstone of linking accts to sockmasters), banning IP edits altogether would be a horrible idea - for every two-bit vandal, there’s a productive contributor that just didn’t want to or hasn’t decided to create an account yet. Hell, half of the recent USHL season pages have been maintained by an IP who’s filling a valuable gap in WP:NHL. The Kip (contribs) 02:13, 11 October 2025 (UTC)[reply]
Thank you for being the only person who deigned to answer the question I was asking, even if you disagree with me. Tercer (talk) 08:39, 11 October 2025 (UTC)[reply]
Yes, I am in favor of banning IP edits and temporary accounts. All editors should be required to create an account connected to a verified email address or phone number. Anyone can still edit and vandalism practically ceases to exist. 216.126.35.228 (talk) 17:14, 14 October 2025 (UTC)[reply]
This just defeats the whole point of all Wikimedia projects, in which anyone else can edit. If votes were allowed here, I would be strongly opposed to banning all unregistered edits, and strongly support the introduction of temporary accounts. Codename Noreste (discuss • contribs) 22:26, 14 October 2025 (UTC)[reply]
@Codename Noreste: How would requiring a verifiable account defeat the whole point to create a repository of the entire sum of human knowledge which anyone can edit? Anyone can create an account. 216.126.35.228 (talk) 16:37, 15 October 2025 (UTC)[reply]
Principles aside, I invite you to check out Citizendium and see how that worked out. 184.152.65.118 (talk) 01:34, 3 November 2025 (UTC)[reply]
Just to note, not all Wikimedia projects allow for non-registered accounts to edit. --Super Goku V (talk) 15:03, 3 November 2025 (UTC)[reply]
Let's see how the "temporary accounts" bit works out, first, once the dust settles. If it works okay and there's not a major increase in vandalism and abuse, then the temporary accounts thing is still not good, and it would've been better to keep IPs, but if it's not causing massive headaches, then it is what it is. If it is causing major headaches and we do see a noticeable spike in vandalism, socking, LTA activity, etc., then we'll have to decide on next steps at that point, which may involve restricting or disabling anonymous editing. But let's wait until we actually have the data, rather than just speculation. Seraphimblade Talk to me 22:58, 14 October 2025 (UTC)[reply]
Even if 99% of Wikipedia editors support disabling IP/temporary account editing, I believe the WMF will still have the final say on whether to implement this change (and I believe they've stated before that they will not get rid of IP/temporary account editing). Some1 (talk) 23:03, 14 October 2025 (UTC)[reply]
Counter-example: Portuguese Wikipedia turned off IP editing years ago. –Novem Linguae (talk) 12:43, 15 October 2025 (UTC)[reply]
Some statistics [2] which might be helpful evaluating TA rollout on enwiki. I've checked those stats for my home wiki after TA deployment and everything seemed fine. Johannnes89 (talk) 21:36, 4 November 2025 (UTC)[reply]
Strongest possible oppose to either, frankly. I would not be here if it were not for IP editing, and I know many of our greatest editors started out as IP addresses. I think this whole temporary account thing is dumb, but that is outside the scope of this. We've been doing this for over 20 years and it's worked fine. That's all. Lynch44 16:52, 2 November 2025 (UTC)[reply]
I disagree that it's worked fine, both from a privacy and legal perspective. Nosferattus (talk) 07:22, 12 November 2025 (UTC)[reply]
Not opposed to the idea, but I currently don't support it at the moment. If I had responded last week, I might have been more supportive to banning IP edits over the temporary account program, but Sohom posted a research article in the discussion above that does indicate with evidence that there are costs to prohibiting non-registered edits, so I do have concerns. --Super Goku V (talk) 15:09, 3 November 2025 (UTC)[reply]
I think this would be a bad idea, anonymous users are , on the whole, a net positive, and adding friction to the "Spot issue with article > Fix issue with article" process is going to reduce the quality of articles on the whole. I would not like "Spot issue with the article > Try to edit it > Get told you have to register > Lose interest" I would much rather see a more integrated, proactive solution to getting people registered, something like, the 'submit' page for any anonymous edit giving you a 'Now select a username and password' page, with a prominent 'skip' option. ("Spot issue with the article > edit it > register or not.") If having something like that in place, we find that the number of temporary users reduces significantly (with an equivalent increase in registrations), then we can review. This is how a lot of e-commerce sites do it, as they too are motivated to get the value (fixing pages/buying stuff) without adding friction, but also would like you to register if you don't mind thank you very much. JeffUK 11:38, 10 November 2025 (UTC)[reply]
@JeffUK IP users were never anonymous, to start with. In fact, they were the opposite of that. IP editing is a privacy and security breach which should have never been allowed, now or back in 2001 when the risks were already perfectly known. Darwin Ahoy! 09:29, 10 December 2025 (UTC)[reply]
None of my comment hinges on their anonymity, or otherwise. But ok. JeffUK 19:54, 14 December 2025 (UTC)[reply]
I have long considered the idea of temporary accounts to be unnecessary technical debt that only adds confusion to anti-abuse mechanisms. It's long past time that we followed other websites' leads in requiring registration. The fact that it is fairly easy to get access to the IP information means the privacy gains are not great; cutting off access to it also assumes catching such leakers in the first place, which is not happening if said IP address information was leaked privately and can't be discovered by us.--Jasper Deng (talk) 08:24, 15 November 2025 (UTC)[reply]
The fact that it is fairly easy to get access to the IP information means the privacy gains are not great Before temp accounts, everybody could see an unregistered editor's IP. Now, it's 1000 people for English Wikipedia globally. Regarding the ease of getting to the threshold, see {{Registered editors by edit count}}. SGrabarczuk (WMF) (talk) 11:17, 15 November 2025 (UTC)[reply]
The barrier is still much lower than virtually any other website. It's also a poor metric given the manual nature of this process. Jasper Deng (talk) 17:56, 15 November 2025 (UTC)[reply]
It's better than what it was before. The barrier to seeing IPs used to be nothing. Everyone saw logged-out editors' IP addresses even if they didn't want to. There's zero reason to know the IP address of a logged-out constructive contributor; the main benefit of attributing logged-out edits to IPs in the first place was that it made tracking vandals easier.
If we instead required registration for everyone, good-faith logged-out contributors would likely lose interest if they saw that they had to make an account. The bad-faith editors could just as easily vandalize after taking the 10 seconds to register. So requiring registration would be a net negative to the project.
SuperPianoMan9167 (talk) 19:27, 15 November 2025 (UTC)[reply]
Registered-only is even better in the privacy regard, so that is not an argument in favor of the current situation. And, the amount of registrations we get shows that good-faith users still will register, so that is not an argument either.
We always have to balance good-faith contributions with the feasibility of anti-abuse mechanisms. By your argument, we should allow open proxy editing as well. Jasper Deng (talk) 19:48, 15 November 2025 (UTC)[reply]
We can and do allow good-faith contributors to edit via open proxy by granting WP:IPBE. In most cases, open proxies are abused for vandalism and block evasion so much that it is dangerous to leave them unblocked. SuperPianoMan9167 (talk) 19:53, 15 November 2025 (UTC)[reply]
I understand IPBe, having been on this project for 17 years, thank you very much (while you have not been here for even a year). You know what I mean.
A bad-faith user's ability to obtain new accounts by simply clearing cookies or even refusing them outright is an obvious vulnerability here, and with this change we have lost our ability to easily detect obvious rangeblocks by looking at the IP addresses they use, outside /64's. And, even when bad-faith users do register usernames, they often do so with usernames that give themselves away (see any WP:LTA category), something they would still have to do if registration is required. Jasper Deng (talk) 19:59, 15 November 2025 (UTC)[reply]
(edit conflict) Oh, I'm sorry; I didn't realize you probably knew about IPBE already. I see your point. SuperPianoMan9167 (talk) 20:05, 15 November 2025 (UTC)[reply]
No, the majority of IP or edits made from a user without an account are in good faith. Best wishes, Macaw*! 00:48, 20 November 2025 (UTC)[reply]
While I am not yet a firm yes to banning anonymous editing, I am leaning in that direction. I think there should be a community wide discussion of the impact of the temp accounts, and in particular their effect on vandalism and impact on counter vandalism efforts. That said, I think we need to wait at least six months in order to get a clear picture that is more than just anecdotal reports. -Ad Orientem (talk) 01:26, 28 November 2025 (UTC)[reply]
I’ve changed my mind on the topic. I don’t think temporary accounts change much of anything. It’s still just unregistered users, just a bit more private. It’s still an issue. Additionally I don’t like the false sense of security it gives people who are like oh my ip isn’t visible. But it is to like pretty much everyone. Even socks. It’s barely any work. Best wishes, Macaw*! 02:35, 28 November 2025 (UTC)[reply]
Oppose per The Kip. sapphaline (talk) 09:59, 16 December 2025 (UTC)[reply]

Replacing our CAPTCHA with a new bot detection service, part 2: editing

[edit]

Hello again from the Wikimedia Foundation Product Safety and Integrity team. As you may remember, we've been integrating a new bot detection service, with the goal of replacing the current CAPTCHA with something that can hold up better against modern bots and other automated activity.

In our previous message about the hCaptcha account creation trial, we mentioned that we would expand this trial to include editing for higher-risk sessions. We are now ready to begin this next phase of the trial.

We are still running the account creation trial and collecting data, and we are seeing good initial results. Some bots are getting stopped from creating accounts, and humans rarely see a challenge at all. As expected, not all bots will get challenged either, and some can be subtle – but as the checkuser team recently shared, we've been able to use hCaptcha's data to help checkusers find and respond to those bots as well. We’ll share more about data from both account creation and editing after the trial concludes.

We'll now be taking the same approach to higher-risk editing. Here's how that will work:

  • This will affect logged-out editors making their first edit, temporary account users, and non-autoconfirmed users. In other words, all sessions that don't have the skipcaptcha right.
  • Like with account creation, this will work primarily invisibly. Most visitors (around 99.9%) will never see a challenge to solve at all.
  • However, if an AbuseFilter that uses the showcaptcha consequence is triggered, this will always show an hCaptcha challenge to the user.

We will be enabling this on wikis which are already participating in the hCaptcha account creation trial, over the course of the next few weeks. First, we’ll deploy this week to idwiki, jawiki, and ptwiki. Shortly after, we’ll deploy to fawiki, zhwiki, and trwiki. Finally, we will deploy shortly after that to frwiki and enwiki.

To learn more, see our previous discussion here or the project page. As always, if you'd like to talk to us, comment here or find us on Discord. Thanks! EMill-WMF, KHarlan (WMF), SGrabarczuk (WMF) (talk) 14:33, 17 November 2025 (UTC)[reply]

What happens to the people who have JavaScript disabled? Would they simply not be able to edit? Children Will Listen (🐄 talk, 🫘 contribs) 14:42, 17 November 2025 (UTC)[reply]
This is a good question and I am curious to hear as well. In the interim, I'll point out that (a) the great majority of internet websites require JS for their captchas; (b) legitimate no-JS users are a vanishingly small slice of the internet use pie; and (c) under this current implementation we should be able to exempt legitimate no-JS users from hCaptcha upon request by giving them the "confirmed" user group (which comes with skipcaptcha), though I imagine that skipcaptcha might someday move out of confirmed to some higher group. Best, KevinL (aka L235 · t · c) 16:11, 17 November 2025 (UTC)[reply]
In a sense there is, global CAPTCHA exemption, though that isn't local and is only assigned by stewards. Tenshi! (Talk page) 16:19, 17 November 2025 (UTC)[reply]
@ChildrenWillListen sessions which do not have the skipcaptcha right, and do not have JavaScript enabled, will not be able to submit the wikitext form. (The same thing applies to Special:CreateAccount.) From our instrumentation, of sessions from users without skipcaptcha who successfully save edits with the wikitext editor, about ~0.6% of the sessions do not have JavaScript loaded at form submission time. Disallowing no JS edits from higher risk sessions (those without skipcaptcha) is one of the tradeoffs needed to be able to use hCaptcha for improved bot detection and mitigation in the editing path. KHarlan (WMF) (talk) 17:10, 17 November 2025 (UTC)[reply]
Thanks for sharing this, all. As a CU, I've been impressed by what hCaptcha has helped us with even with just account creation, and I think enabling it on editing will add a lot of value. Best, KevinL (aka L235 · t · c) 16:01, 17 November 2025 (UTC)[reply]
Here someone talked about age details in the hCaptcha TOS, do these indeed apply? Sjoerd de Bruin (talk) 19:17, 17 November 2025 (UTC)[reply]
@Sjoerddebruin Thanks for flagging that comment. No, the use of hCaptcha isn't imposing any age requirements on our users. We always understood the age provisions in the ToS to apply specifically to their customers (like us) and not end users. But their one merged terms of service did have some imprecision in how they expressed that.
I just replied to the comment there to say the same, and to point to hCaptcha's newly updated terms, which added a "if you are registering an account" qualifier to that clause, for avoidance of doubt. EMill-WMF (talk) 03:33, 18 November 2025 (UTC)[reply]
Please humour me - I'm not up with all the latest technical details of web programming - but why would anyone today disable JavaScript? Phil Bridger (talk) 20:33, 17 November 2025 (UTC)[reply]
Some privacy-minded folks, virus-paranoid folks, or folks that just don't like a bunch of layout thrashing use browser add-ons such as NoScript to disable all JavaScript. –Novem Linguae (talk) 22:22, 17 November 2025 (UTC)[reply]
Wikipedia is significantly smoother, faster and less obnoxious when scripting is disabled! Almost every major browser vulnerability occurs via script. Johnuniq (talk) 00:09, 18 November 2025 (UTC)[reply]
Some adherents to the free software movement (such as Richard Stallman) block/refuse to run nonfree, non-trivial JavaScript through extensions like LibreJS, while still allowing free or trivial JavaScript. This includes the nonfree, heavily obfuscated JavaScript used by hCaptcha. I am not aware of any instance up until this point where Wikipedia used nonfree JavaScript, other than possibly that time in 2019 when Wikimedia used Cloudflare to defend against a DDoS attack. OutsideNormality (talk) 02:10, 22 November 2025 (UTC)[reply]
I just did a test with a spoofed browser configuration and the AbuseFilter "showcaptcha" mode, and apparently if hCaptcha thinks you are a bot, it will let you solve the CAPTCHA, but your edit will never submit no matter what you do, showing cryptic error messages. Pretty smart. Also, the text CAPTCHAs were different this time, asking questions like "What do we sit on at a desk?" (my question is: do these text CAPTCHAs support other languages?). OutsideNormality (talk) 20:45, 23 November 2025 (UTC)[reply]
That doesn't sound like expected behavior. If you file a ticket with some details, we'd be happy to take a look into it. EMill-WMF (talk) 23:12, 23 November 2025 (UTC)[reply]
@OutsideNormality thanks for flagging this issue. I filed T410863: hCaptcha: SiteKey mismatch error on "always challenge" workflow. To answer your question, yes, the text challenges are available in other languages. KHarlan (WMF) (talk) 09:46, 24 November 2025 (UTC)[reply]

So what should a legitimate no-JS user do to edit Wikipedia now (except enabling JS)? Would requesting an account and confirmed/global CAPTCHA exemption rights with it be enough? sapphaline (talk) 13:18, 18 November 2025 (UTC)[reply]

Btw, for some reason there's no "Request an account" link on the account creation page. sapphaline (talk) 13:20, 18 November 2025 (UTC)[reply]
@SGrabarczuk (WMF): @KHarlan (WMF):? sapphaline (talk) 09:37, 19 November 2025 (UTC)[reply]
Is there some urgency in your question requiring you to ping them within 24 hours? Sjoerd de Bruin (talk) 10:08, 19 November 2025 (UTC)[reply]
@Sapphaline In the current configuration, users who have "skipcaptcha" right (autoconfirmed users, which is a fairly low bar to clear) can continue to edit without JavaScript. KHarlan (WMF) (talk) 22:00, 19 November 2025 (UTC)[reply]
I'm asking about account creation and obtaining this right. sapphaline (talk) 22:05, 19 November 2025 (UTC)[reply]
Then yes, you would either need to request an account be created for you, with that right. Or, you would need to enable JavaScript for account creation, and making the edits involved in obtaining that right, before being able to disable it. EMill-WMF (talk) 00:51, 20 November 2025 (UTC)[reply]
  1. outsourcing captchas to a third party is a great way for that party to collect massive amounts of data to sell to advertisers.
  2. hcaptchas are made with generative ai, and the answers are used to train generative ai.
  3. see the terms of service didn't read for hcaptcha for what you're agreeing to when you run hcaptcha.

ltbdl (talk) 15:26, 27 November 2025 (UTC)[reply]

Planned short test of mobile banners promoting the Wikipedia app

[edit]

Hello,

The Wikimedia Foundation’s Communications and Product teams would like to implement a small test on centralized notice banners to encourage more people to download and use the Wikipedia app. It will be a simple banner, targeting logged out mobile users and will run for just a few days, starting on December 15. The goal is to get more people using the app so that they become more engaged with Wikipedia in the long term. This is increasingly important as our Wikipedia traffic is changing, and it is part of our Foundation’s annual plan. If you have any questions or concerns, please let us know. Thank you so much.

--ARamadan-WMF (talk) 18:16, 20 November 2025 (UTC)[reply]

Is the rate of app downloads decreasing significantly? We should probably have a specific reason for implementing another advertising banner, as these seem to be somewhat unpopular within the community. ✨ΩmegaMantis✨blather 02:48, 21 November 2025 (UTC)[reply]
@ARamadan-WMF Are you sure that "get[ting] more people using the app [will cause them to] become more engaged with Wikipedia in the long term"?
I prefer web browsing over apps. (I don't understand why, for example, Home Depot even HAS an app. Browsing their inventory and ordering online works perfectly well from a web browser. Similarly, when reading The New York Times online, their web page nags you to use their app. Why? Reading the NYT using a web browser is perfect, in my opinion.)
Reading plus editing Wikipedia on a tablet and also a Windows PC, using a browser, is a great experience for me. I read WP using my phone. I don't generally edit from my phone, but some long-term editors do. Does using the app really drive engagement, and how can you tell? David10244 (talk) 05:06, 21 November 2025 (UTC)[reply]
@David10244: Are you sure that "get[ting] more people using the app [will cause them to] become more engaged with Wikipedia in the long term"?: Apparently the Wikipedia mobile app has games that are supposed to keep people engaged now. T400512 says they're going to add even more in the future. Children Will Listen (🐄 talk, 🫘 contribs) 23:23, 23 November 2025 (UTC)[reply]
Note most of these new features only come to Android in the first place. Sjoerd de Bruin (talk) 08:39, 24 November 2025 (UTC)[reply]
@ChildrenWillListen OK, thanks for that info. (Personally, I dislike games on mobile devices, but of course people do have their own preferences.) Are people really "engaging" with Wikipedia if they are playing games? Even if the games are hosted within the app, time spent playing the games is time not really spent engaging with WP...
Oh well, we don't need to drag this out. David10244 (talk) 07:21, 4 December 2025 (UTC)[reply]
@ARamadan-WMF: I haven't used it in while, but if the app restricts editing or has missing features compared to mobile web (due to underdevelopment) it should make it clear that mobile web is better for that task. Otherwise, you are pushing Wikipedia-lite: a watered down, crappy version of Wikipedia and people will disengage entirely out of frustration. There must be a list of restrictions somewhere (or the app is better in every way?) that you have evaluated before pushing the app with a banner.
@David10244: not that I am a proponent of a Wikipedia app, given the development costs, but apps can have more features compared to the web. From my hazy understanding, apps can:
  • allow easier payments (didn't the WMF just announce you can donate from the app using Google/Apple pay?)
  • securely store the number page visits locally (the WMF is developing donation banners based on number of views)
  • Allow users to upload a photo in a free file format when your phone uses a proprietary format
  • Send push notifications to your device (e.g. you have new messages), etc
Commander Keane (talk) 08:36, 21 November 2025 (UTC)[reply]
2 isn't planned to my understanding. Sohom (talk) 04:38, 28 November 2025 (UTC)[reply]
I don't like mid-thread posting, but here goes...
@Sohom Datta maybe I am confused or didn't explain it well, but on on mediawiki.org: "The apps already locally store and surface the user's reading history" and in relation to the new banner placement widget, "Readers will be able to [...] choose how often they want to be reminded, based on the number of articles they read". Commander Keane (talk) 10:39, 28 November 2025 (UTC)[reply]
It is not "securely" stored so much as available due to the nature of such apps, but sure. Sohom (talk) 15:42, 28 November 2025 (UTC)[reply]
@Commander Keane Hmmm. I can see some of that, but:
  • Payments: You can pay from Web pages. I buy stuff all the time online. Some web pages accept Google Pay and Applepay.
  • Web pages could do different donation banners server-side, or with cookies.
  • I certainly don't want push notifications, but to each their own...
David10244 (talk) 07:29, 4 December 2025 (UTC)[reply]
Ironically, I am leaving this comment using a mobile browser because the app doesn’t allow access to any of these notice boards. ~2025-35367-57 (talk) 14:11, 21 November 2025 (UTC)[reply]
I am leaving this comment from the app after the reading comment above. With an account I can manually leave a comment here by editing the wikitext of the whole page. I don't see any "reply" buttons anywhere though.
A streamlined way to upload freely licensed photos would be a great addition to the app and one of the few clear advantages to editing on a phone (while we are apparently trying to get people to download the app). Right now (on Android using the official app), I have to switch over to the Commons app and it's all but clunky. I imagine it's also a more straightforward addition than improving the mobile's editing interface. Rjjiii (ii) (talk) 20:17, 28 November 2025 (UTC)[reply]
Maybe the IOS app lags behind in capabilities? I tested logging in and there is no way to navigate to these boards; the Home page simply scrolls endlessly back in time. ~2025-37129-61 (talk) 23:21, 28 November 2025 (UTC)[reply]
Ah, okay, then yes they are different. On Android, if you open a new tab it begins on the Main Page. This may be coming to IOS as well, because I think that new tabs only started showing the Main Page this year. Rjjiii (ii) (talk) 05:43, 30 November 2025 (UTC)[reply]
@Rjjiii (ii) So the app has lagged behind the functionality of the Web page for many years then, if the Main Page is just now coming to the app! 🙂 David10244 (talk) 07:32, 4 December 2025 (UTC)[reply]
@Rjjiii (ii) I would hate not seeing the Reply buttons! David10244 (talk) 07:30, 4 December 2025 (UTC)[reply]
  • Aside from the editing issues mentioned above, the app also mostly ignores the main page content which our community has decided to show on any given date. Aside from the featured article, it substitutes its own things without community approval, such as having a Most-viewed article section, using the Commons featured picture of the day instead of our choosen WP:POTD, and replacing our set of anniversary articles with its own OTD that isn't vetted or necessarily on our list. I've no idea who curates that, but I don't think we should be promoting something that fights against the community's editorial decisions. It also sucks in incoming links from browsers, making it more difficult to view the project on the Web even if you want to.  — Amakuru (talk) 07:29, 28 November 2025 (UTC)[reply]
    That's terrible, and should be discussed at an RfC at VPP, and then probably removed from the app. I thought the WMF didn't do content and left that to the wikipedia's? At the very least they should be able to tell us how / by whom the sections on the App main page are created, and why they don't use the local ones. I don't have the app so haven't checked this, I do remember the reluctance they had to remove the Wikidata short description from it: I hope any necessary changes this time will be quicker and in a more collaborative spirit. Fram (talk) 09:10, 28 November 2025 (UTC)[reply]
    @Amakuru, @Fram It is very hard at a technical level to exactly extract the on-this-days section of the main page in a reliable manner due to it's free flowing nature, as a result to my understanding of what the underlying code is going for a compromise, it is parsing November 28 (today), using the much more standardized format of those pages to serve chronological information from the page. The first OTD entry on the app is "Over seven hundred civilians are massacred by the Ethiopian National Defense Force and Eritrean Army in Aksum, Ethiopia" which corresponds to a community generated entry on November 28. For what it's worth, I don't think there is a conflict with the communities editorial decisions here, the content being shown here is community generated and is prominently linked to in the first link in our OTD section. This is not WMF generated content, it is literally content we have decided is good enough to link from the main page. Sohom (talk) 16:47, 28 November 2025 (UTC)[reply]
    There is a huge difference between content linked from the main page, and content shown on the main page. Basically, this gives vandals a clear method to vandalize the main page on the App. Fram (talk) 16:52, 28 November 2025 (UTC)[reply]
    I personally don't buy this argument, if content is one click away, people going to the page, through mind you the literal first link on OTD will have a pretty bad impression of Wikipedia anyway. Not to mention that this concern is effectively the same threat model as if somebody where to vandalize a DYK or OTD and the preview of the article showing up on hover on the main page, however, we as a community typically do not fully protect DYKs or OTDs. For what it's worth, I think there are mitigations against this kind of scenarios, in that I think there is aggressive caching and if the code sees a empty page, they will revert to showing a cached version + the app randomizes and caches which entry folks see, and so the chances of a person vandalizing the page and it immediately showing up on the main page are pretty slim. Sohom (talk) 17:03, 28 November 2025 (UTC)[reply]
    The clickthrough is minimal compared to the impressions the main page gets though. Vandalizing a linked page will reach a few dozen people or so (assuming the vandalism is up for a few minutes), vandalizing the main page reaches thousands of people in the same timeframe, and is much worse for PR as well. I don't know about the caching and whether that helps (though the "empty page" is a very uncommon type of vandalism). Would probably be best to test this (not with vandalism, but by constructively changing some text which is visible on the App main page, and seeing how long it takes to change on the main page). Fram (talk) 17:23, 28 November 2025 (UTC)[reply]
    Hmm, I went to edit November 28, and realized that it seems to be protected under pending changes, that would make it much harder to get vandalism over to the main page for today. (it might be instantaneous for us cause both of us would bypass pending changes). Sohom (talk) 17:57, 28 November 2025 (UTC)[reply]
    The incoming link issue has been a particularly pernicious issue for me, the only obvious end-user solution for it is to delete the app which is presumably not what is wanted. CMD (talk) 09:17, 28 November 2025 (UTC)[reply]
    I really like some of the app landing page features, and some of the editorial(!) decisions like the POTD and OTD can be refreshing. However, the 17 fair use images shown (I stopped scrolling after a few days worth of feed), often cropped and with no way to tell they do not have a free licence, was disappointing. I am guessing there were 17 fewer fair use images on the Main page during that period.
    I think the app is getting ignored by the community and, for better or worse, pushed by the WMF. Commander Keane (talk) 10:58, 28 November 2025 (UTC)[reply]
    It seems that POTD corresponds to c:Commons:Picture_of_the_day. – robertsky (talk) 11:24, 28 November 2025 (UTC)[reply]
    I agree the incoming links issue has been one of the reasons I have the app set to never open wikipedia links, and Android somehow still disobeys me sometimes :(. Sohom (talk) 16:52, 28 November 2025 (UTC)[reply]
    I tried the app the other day, it is dreadful. How they do the lead image is really strange, and some of the features don’t make sense. The app should be designed with the community, idk what they think they’re doing Kowal2701 (talk) 12:39, 28 November 2025 (UTC)[reply]
    @Kowal2701, Please provide actionable feedback, what exactly is "dreadful", why is it so ? What is "strange" about the lead image? Sohom (talk) 16:50, 28 November 2025 (UTC)[reply]
    First off it's horrendously impractical for editing, I could list dozens of things but it's very clear it's not intended to be used by editors so I won't waste my time. I deleted it after 10 minutes. Just on the tabs:
    • the Explore tab, I don't understand what they were going for. The Main Page is carefully curated, idk why it wouldn't be kept (the layout is ugly and monochrome as well). For something called Explore, I'd expect them to use Wikipedia:Contents, or propose random topics for people for people to learn about, or whatever. Something that actually lets the reader explore the encyclopedia, ie. where they can navigate themselves rather than getting random articles on Polish towns etc.
    • Places is an interesting idea, but what is its purpose? Is it for Americans to learn geography? Why is it only limited to settlements, administrative divisions, and landmarks? Why are administrative divisions presented as a point? Could it be tied into country outlines (eg. Outline of Myanmar)?
    • The others, sure they make sense, I wouldn't really use them or find them helpful other than "Search"
    On the app, it just isn't a wiki anymore. I can't edit any of the tabs. I don't like the personalisation. The lead image appears as a banner at the top, and the infobox is collapsed under "Quick facts". It boggles my mind that the team working on this thinks they can redesign everything without community consensus, especially when it's done so poorly. The website is brilliant, just copy that over and maybe add a couple more features for exploring, that's all that needs to be done. It being awful for editing also means we'll get less new editors, which is what we really need to have begging banners for. A "reader" version and an "editor" version that people can switch between might make more people aware of their ability to edit and make it more accessible so they try it out. This being said, the idea of prioritising the app is great, it bypasses Google's LLMs, but the execution and process was very poor. Kowal2701 (talk) 17:23, 28 November 2025 (UTC)[reply]
    I've been somewhat involved in discussions related to the Android app so I can give you the high-level "why" of the design choices. Back in the day of Vector, when the app was first created our UI, infoboxes, image placement, warnings and even our main page sucked on mobile, taking up often more space than was available on mobile. As a result, the team at the foundation had to make certain optimizations/tradeoffs (like hiding the infobox, lifting the lead image etc), and changes to the layout of a variety of elements to get it to work on mobile. Since then, there has been significant improvement in our ability to serve mobile-first content, particularly due to collaborations between technical editors and WMF teams to overhaul and improve Wikipedia's templates and user interfaces to be mobile oriented. There is still a significant amount of work to be done before we can get to your standard of "hey they could just put the website into the app" and for folks to be happy with it (not to mention that even then, a significant amount of engineering will be required to replicate mobile-web-only features using Java code).
    To a few of the more specific points, the explore tab was developed to copy the essential features of the current main page back when showing the main page wasn't a option, similarly, the way the "places" feature works is that it uses your geolocation to find articles close to you, unfortunately, we only use coordinates in administrative divisions and such, limiting the feature. To the point of using outlines, our outlines are free flowing and outside of using a LLM, there is not a lot of ways to extract structured data that can be used to augment this features through outlines. I can see a situation where we use Wikidata to augment some of this data, but such uses have been frowned upon by the community back in the day (see also short description), which is why I think the app avoids it Sohom (talk) 17:52, 28 November 2025 (UTC)[reply]
    To that point, @ARamadan-WMF, is there a place we can leave feedback on the design of the Android app? Sohom (talk) 17:59, 28 November 2025 (UTC)[reply]
    Thank you. The technical aspects are beyond me, I just find the website on mobile pretty good all considering (on iOS btw). I can understand some of the design changes like collapsing the infobox, I just wish things like this were run past the community, like in batches. This project operates by consensus. I'm sure WMFers see it as given that some in the community are going to rage against anything they do, but involving the community at earlier stages would negate a lot of that. Kowal2701 (talk) 18:19, 28 November 2025 (UTC)[reply]
    I installed the App. It gave me Dutch as default language, but allowed me to another language. But after adding English, the app hecame quite a mess with the two languages mixed. I thought I would get some switch to see enwiki only or nlwiki only, but no, I got something unwanted. I have removed it again, as it also interfered with my standard Wikipedia editing on the phone here. Not a fan... Fram (talk) 19:10, 28 November 2025 (UTC)[reply]
    Eh no I agree, the "using different languages" thing is weird for me as well. It's always given me English though, maybe it picks the language based on location now ? Sohom (talk) 19:44, 28 November 2025 (UTC)[reply]
    I got Lao, Italian, and Arabic IIRC Kowal2701 (talk) 19:57, 28 November 2025 (UTC)[reply]
    Well for one, the talk page button isn’t easily accessible while reading a page, you have to click the “more items” ellipses to find it. Worse, the “learn more about this page” link appears as broken HTML, making it vastly less likely for app users to click in and read it. There’s no ability to access category pages, and the notice boards are completely walled off from the IOS app. ~2025-37100-27 (talk) 23:43, 28 November 2025 (UTC)[reply]
    No VisualEditor (and the joys of visual citation insertion, etc), no access to Help desk/Teahouse (without pushing you to the web on Android, ~2025-37100-27 suggest zero access on iOS). Not suitable for new editors. Not suitable for experienced editors. There are more limitations.
    I thought the app was just a bit of fluff that the WMF was going to half-develop because cash was slushing around. Without VisualEditor (a 13 year regression) and Noticeboards (a 21 year regression) it is. Minor landing page issues, as discussed above, are not my major concern. If the WMF intends to make the app equivalent to mobile web then I am on board. I will test, and file bugs/features 'till the cows come home. We all could.
    If it going to remain dreadful, then I would like to keep editors on mobile web (and lets face it, mobile desktop), or push them away from the app ASAP. This would not involve a mobile banner promoting the app. I do think the reading experience is superior on the app. But people read Wikipedia because those before them have edited to create that content. Appealing to financial reasoning: over time, you will get less and less donations with less and less editors. Commander Keane (talk) 01:04, 29 November 2025 (UTC)[reply]

Hi all, thank you for the thoughtful questions and concerns raised here. My name is Jaz, and I am the Lead Product Manager for the Mobile Apps Team.

The banner is intended to be a time-limited test that would only be shown to logged-out mobile readers on Japanese Wikipedia (in Japan) December 15-16 and English Wikipedia (in South Africa and India) December 15-18. The purpose is to understand whether a simple banner can help raise awareness that the Wikipedia app exists, especially among new readers, and if those readers retain at the same rate as readers that discover the app organically through the app stores.

Why do we want to drive more traffic to the apps?

Our broader goal is to help new and existing readers return to Wikipedia because they find it a compelling place to learn. To address this we want to experiment with ways that help new generations of readers find Wikipedia useful, return frequently and eventually become the editors we need to keep the projects healthy.

There are two shifts in reader behavior that are driving this:

  • The number of people visiting Wikipedia, and the ways that they visit, have been changing for several years, with fewer people arriving to the site through external search engines.
  • Based on our existing data, we know that readers on the apps return more frequently and engage more while they are reading than readers on the mobile web, thanks in part to built-in platform features. Readers who install the app tend to come back more often and explore more content directly on the platform. However, install rates are stagnant and primarily come through organic searches in the app store.

In short: We think that having people come to us through a platform we control, instead of mostly through search where we have no way to ensure we remain as visible as we have been, is key to remaining a vital, viable movement. This is a small test to see if this could be one way of helping that.

Because long-term sustainability depends on new readers returning and eventually becoming editors, as outlined in the Wikimedia Foundation’s annual plan and the Readers work, we want to connect people with the reading environment where they are most likely to stay engaged. For new generations there is a higher tendency to rely more on mobile apps and personalized experiences when learning online.

The difference between apps and mobile web

Several people raised very valid concerns about the apps not fully matching mobile web functionality. This is correct, and we want Web to remain the primary environment for editing workflows that are not supported, or are less than ideal, in the app. For users interested in editing on the apps, we will ensure that easy and intuitive ways to transfer over to the web are available: We want readers to be able to easily use the apps for all the things the apps do well, and lead editors to the web for editing. If you are interested in efforts to improve mobile web editing you can read more here.

On the apps, we want to focus on the needs of readers who prefer mobile-native experiences and are accustomed to personalization, like enabling readers to pick topics they want to see more, showing them trends in their reading patterns or notifying them if they haven’t met a reading goal. This shift allows the apps to focus on what they are uniquely good at, including reading on the go, offline capabilities, personalization that respects privacy, push notifications, and other mechanisms like widgets that help readers return more consistently.

Why do some features vary by platform?

I see there is a question of why some features are on one platform but not another. The way our team works is to see if a feature performs well on one platform before bringing it to the other so we are being thoughtful about where we put our time and energy and not scaling features that do not work or aren’t desired. Tabs is a recent example of a feature that was originally released on Android and highly requested by iOS app users, so we prioritized releasing it there recently. You can see a similar approach to Year-in-Review which was only available on iOS last year but is currently available on both platforms this year, with improvements based on feedback the team received.

How can you get involved?

We welcome ongoing feedback about the apps, especially from editors who use them or want to use them more effectively. App development is shaped by community input through Village Pump discussions, project pages, the support email channel, and app reviews. You can leave feedback at any time on our discussion page and stay informed by subscribing to the app newsletter. I’ve tried to respond to all of the great feedback here, but will also take a pass at individual comments again and will respond inline if I missed something over the next few days.

Ultimately our goal is to run this test thoughtfully, learn if it increases retained installs, and discuss the results with you all to determine if efforts like these could support the overall health of Wikipedia’s reader and editor ecosystem. If the apps are not personally your preferred platform or you do not have strong opinions about their direction, that is okay, we understand we have a diverse community with diverse preferences and interests, that’s what makes it so great. The web teams also regularly welcomes feedback on how to improve the mobile and desktop web experiences for readers and editors.

But the key thing is this: The internet is changing and fewer readers are finding their way to Wikipedia, or come less often, because search traffic doesn’t work the way it did in 2003 or 2014 or even 2021. This means we have less chances of making more people edit. We want to find ways to make it easier for readers to return to our articles. This is a small, limited experiment to see if this can help readers return. If we can make readers come to our own platform, and return, then we can send them to the mobile web for editing, keeping our ecosystem healthy. JTanner (WMF) (talk) 20:21, 2 December 2025 (UTC)[reply]

Thank you. Is there anything on the app that pushes/nudges people into editing on the website? Another concern is that a lot of people make their first edits by correcting spelling errors etc. while reading, if the app is cumbersome for editing it'll drive away would-be-editors and would mean people who get into 'full-on' editing slowly and gradually are lost since it's a big step to visit the website purely to edit. Could the 'edit' button on the app redirect to the web? Kowal2701 (talk) 20:55, 2 December 2025 (UTC)[reply]
Hi @Kowal2701, thank you for this question. You’re right that many people make their first edits while reading, and we don’t want the app to make that harder. Some experienced editors have told us they want to be able to make small, quick edits directly in the app using wikitext, while others prefer to be redirected to the mobile web and use VisualEditor. We want to strike the right balance so both groups are supported and are able to execute handoffs seamlessly between platforms. A part of us exploring this problem space is also determining the best approach and timing for sending new editors to mobile web. We want to provide a good user experience.
From a technical standpoint, the app currently sends people to the web for certain workflows, so redirecting the edit button when it’s the preferred experience is absolutely possible. At the moment we are gathering existing research on this topic, and early next year we’ll reach out to request feedback. I’ll make sure you’re notified so you can participate in shaping the path forward. In the meantime you’re welcome to subscribe to the related Phabricator task where you'll get automatic updates via email and can weigh in along the way. JTanner (WMF) (talk) 22:50, 2 December 2025 (UTC)[reply]
Hi @OmegaMantis, @ChildrenWillListen, @Sjoerddebruin, @Sohom Datta, @Commander Keane, @Rjjiii (ii) tagging to ensure you were able to see my reply. Looking forward to talking with you more. JTanner (WMF) (talk) 23:05, 2 December 2025 (UTC)[reply]
Thanks for the ping. So the app is a reading companion (with fringe benefits like push notifications). That is fine. As I said above, the reading experience is better than browser and I can see the WMF's motivation. Maybe I will end up using the app for reading Wikipedia too :-).
Ideas to evolve readers to editors:
  • phab:T409603 (as mentioned above) is a priority - put a VisualEditor browser link at the top of the wikitext edit box, and a link back to the app once the edit is completed. As mentioned, the wikitext editor is for experienced editors but it is probably a good idea to show the wikitext when they hit the pencil for responsiveness and so they know that Wikipedia can be edited by them - and after the shock of seeing 2025 wikitext they can retreat to the palatable VE. Or maybe they will give it a go in the app.
  • There absolutely needs to be a link to a help page, with the forums (on browser, DiscussionTools is essential) and editing documentation. Whether that is Help:Contents or a newly tailored page I don't know.
  • Somehow, each article's talk page (and what it is for) needs to be easier to find than right at the bottom. Possibly at the top of the collapsed right side bar. I know years ago got the community rejected the software feature for people to report errors and it got removed, but new editors are hesitant to make changes and more likely to ask on a talk page.
  • Allow users to curate the content in games. After they play, have a "write your own question" link. I have always wanted games for Wikimedia projects, and they are wikis after all. The user supplied content system does not need to be sophisticated.
  • Given the editing limitations on the app, the community could leave a talk page message for anyone that has edited using the app and not progressed to browser and let them know about browser and its advantages. And how to disable the OS deeplinking (app launching when clicking a link), that is mentioned above.
  • Put the tagline "the free encyclopedia that anyone can edit" on the landing page. Given the fall in Main page views, I thought it would disappear forever. Anecdotally, the idea that anyone can edit and everyone is a volunteer has never been effectively conveyed.
  • I am not sure how the new user on-boarding works with the app, but I assume we get them to mobile web efficiently somehow for the dashboard, mentorship etc.
Commander Keane (talk) 11:05, 4 December 2025 (UTC)[reply]

WMF banner fundraising campaign starts today

[edit]

Hi all, The WMF banner fundraising campaign for logged-out users on English Wikipedia in Australia, Canada, Ireland, New Zealand, the UK, and the US will start at 9:00 UTC today. You can find more information on the Community Collaboration page. Best, JBrungs (WMF) (talk) 06:26, 1 December 2025 (UTC)[reply]

Death by AI?: Will large language models diminish Wikipedia

[edit]

Authors: Christian Wagner and Ling Jiang

Published: 2025 in Journal of the Association for Information Science & Technology (Volume 76, Issue 5, Pages 743-751)

In this article, the authors argue that with the expansion of large language models and the ability of AI systems to automatically generate text, the value of Wikipedia is at risk of declining. The primary reason, they claim, is a reduction in human contributors’ motivation. Wikipedia is built on voluntary participation and the “altruistic, volunteer-driven” will of its users. In other words, most of the content is created by individuals who contribute without compensation. When users sense a kind of “AI competition”—that is, when they see that AI can produce content without their effort—the motivation to edit articles or add new material diminishes, leading to a drop in human participation.

As human participation declines, Wikipedia becomes increasingly dependent on AI-generated content or AI-assisted activity. This can produce a “vicious cycle”: fewer contributors → fewer readers → lower quality or freshness of content → reduced attractiveness → even fewer contributors. This cycle may gradually result in stagnation or “content decay.”

Reduced diversity of sources: With fewer human contributors, niche topics, less-represented languages, and non-mainstream or local perspectives may receive less coverage. This undermines the diversity and comprehensiveness of the encyclopedia. Slower updates: Without active editors, articles may be updated less frequently, errors may persist, and new developments across fields may be insufficiently reflected. Exclusive reliance on AI carries risks: the content may become more superficial, incomplete, or error-prone, because machines reproduce data rather than deliberately reviewing, analyzing, verifying sources, and validating claims.

The authors conclude that the real threat to Wikipedia is not merely AI-generated content, but the decline of human motivation to contribute. If this trend continues, Wikipedia may gradually become “a shadow of its former self”—a space lacking the collective engagement, diversity, and accuracy that once defined it. In other words, “death by AI” does not mean the literal disappearance of Wikipedia, but rather a loss of value, dynamism, and public trust.

The authors pose several questions to the Wikimedia Foundation and the Wikipedia community:

* Can human participation be preserved through mechanisms that align with Wikipedia’s ethical principles and community norms?

* Could the use of AI as an assistive tool (rather than a complete replacement) serve as a viable solution?

* How can the quality, diversity, and timeliness of articles be ensured—especially in languages with smaller contributor communities?

Perhaps this topic has already been discussed in various forms, but I am raising it because I am certain it is a fundamental question for many other users and contributors, and it deserves attention. Pereoptic Talk✉️   15:55, 3 December 2025 (UTC)[reply]

this paper is... not good. the main problem is that it seems to mistake all bot edits for generative AI, and all human edits for non-AI, so the entire argument is just dead on arrival. and then there's stuff like:
  • "In the age of generative AI, Wikimedia thus addresses emerging challenges through strategic community design and adaptive governance (Kraut & Resnick, 2012)." - lol, lmao
  • "Furthermore, Wikipedians also engage in collective endeavors to mitigate the negative impacts of bot use and sustain high-quality human contributions such as the Wikipedia Education Program engaging college students for long-lasting contributions" -- no comment
  • "Elsewhere deletionist writer bots (Livingstone, 2016) became a source of frustration" -- what the fuck is a "deletionist writer bot"? (answer: it isn't anything, the paper is garbling this interview about a mass article creation bot, i.e., the near exact opposite.)
Gnomingstuff (talk) 03:46, 4 December 2025 (UTC)[reply]
@Gnomingstuff: This article is only a starting point for initiating a discussion about the impact of AI on Wikipedia. We should avoid Focalism. Instead of focusing on insignificant details, it is better to concentrate on the overall issue. The important question here is whether AI systems have directly influenced the pattern of Wikipedia usage or not.
The issue is not the important role Wikipedia currently plays in AI systems; rather, as the article itself notes, the core concern is the decline in contributors. Evidence shows that due to the rise of artificial intelligence, people’s visits to websites have dropped sharply (For example, this trend is evident in Google.)—and this implies that Wikipedia’s readership is also decreasing. When users do not visit Wikipedia, they either do not realize that the platform can be edited, or even if they do, the lack of engagement reduces any motivation to correct or update content. Such individuals shift from being potential contributors to becoming mere consumers (i.e., readers of AI-generated content), and this dynamic is exactly what the article highlights:
fewer direct readers → fewer contributors → lower quality or freshness of content → reduced attractiveness → even less participation.
And this is without even considering AI-generated content that users themselves add to Wikipedia. Studies show that about 5% of newly created content on Wikipedia is already produced by AI. In other words, in the future, AI systems will rely on a Wikipedia in which a substantial portion of the content has also been generated by AI.
It is true that AI cannot produce original knowledge and depends on primary sources. But, in fact, Wikipedia is also not a producer of scientific knowledge—it aggregates it. Current AI models cannot replace journalists, reporters, or researchers who produce first-hand content, yet they perform the very function Wikipedia serves: gathering information from primary and secondary sources. The difference is that Wikipedia depends on voluntary human editing, while AI can perform this aggregation far more quickly.
Unfortunately, I am not sure what the Wikimedia Foundation is currently focusing on, but just a month ago they published an article on AI and Wikipedia that reads more like a desperate appeal to AI companies to support Wikipedia: *“In the AI era, Wikipedia has never been more valuable.”* These developments will inevitably affect future generations of users who are supposed to be drawn into contributing to Wikipedia. Pereoptic Talk✉️   11:01, 4 December 2025 (UTC)[reply]
The impact of AI has been discussed on en.wiki and in the WMF for a couple of years now. Drawing in contributors has been a topic of discussion even before then. En.wiki have a couple of llm-related policies already, more can be found at WP:LLM. CMD (talk) 11:23, 4 December 2025 (UTC)[reply]
Is this comment itself generated with AI? Gnomingstuff (talk) 14:52, 4 December 2025 (UTC)[reply]
@Gnomingstuff: No, I wrote these comments myself. I am a Persian speaker and use translation tools to write better. Grammarly says this message is structurally correct. I don't know why when talking about AI, some people try to tarnish the image with these false and absurd accusations of these opinions. Is the level of discussion high? Are the technical terms or references to cognitive biases surprising? I wonder where these paranoid opinions come from. Pereoptic Talk✉️   16:06, 4 December 2025 (UTC)[reply]
Grammarly uses AI. Which means that in this case I correctly picked up on what it does, namely, the Markdown formatting around links.
I wonder where these comments that are like "I used AI, but why are you saying I used AI?" come from. Gnomingstuff (talk) 16:09, 4 December 2025 (UTC)[reply]
Also, don't ping me. Gnomingstuff (talk) 16:09, 4 December 2025 (UTC)[reply]
"Generated with AI" has a different meaning than used AI for error correction. I take it you mean it's a message that AI generated and there's no human thought behind it. Pereoptic Talk✉️   16:22, 4 December 2025 (UTC)[reply]
I initially reverted this comment as LLM-generated due to the fabrication of quotes not present in the source. Pereoptic reverted, though those issues do not seem to have been fixed. I encourage readers to treat the above summary with caution. Toadspike [Talk] 00:33, 5 December 2025 (UTC)[reply]
Thank you for prompting us to think about whether AI poses a risk to contributor motivation, @Pereoptic. I don’t think we’ve met yet - I’m Sonja, and I lead the Contributor Product teams at the Foundation. We’ve recently published a blog post about the decline in traffic we’ve seen over the past year, and the question of motivation is an important one we’re trying to tackle to turn that trend around. AI may play a role in this, but there are a lot of other aspects that contribute to it as well. We’ve outlined some of these issues in a strategy draft around the current state of contributing, centered around 3 areas that we plan to focus on with our 4 WMF Contributor Product teams over the coming years. We’d love to get feedback on that draft, and in particular, I’m interested to hear from you what it is that motivates you to continue editing on the wikis today, and what would you need to still feel motivated to edit a few years from now, especially with the rise of AI? SPerry-WMF (talk) 17:50, 5 December 2025 (UTC)[reply]
@SPerry-WMF: Nice to meet you and talk to you and Thank you for the educational points you raised (I appreciate the post you wrote and the project you initiated, and I’d be glad to help in this regard.). I had really been waiting for such a deep and well-informed answer. I brought up this discussion because the project needs to take action in order to continue and survive in the coming years, considering the changes that have occurred on the Internet and the shifting paradigms of this space.
I am an active contributor on my local Wikipedia (Persian Wikipedia) and am one of the few active users working in the medical field there (of course, my contributions to technical topics are also significant; for example, I participated in the Wiki Hackathon 2025). My main motivation for editing Wikipedia is that, in addition to contributing content, I can first read the material myself. The content I read in reliable sources—and then use to write Wikipedia articles—stays in my memory longer. This means that, besides writing Wikipedia, I also read it and increase my knowledge. But there is a problem: this may be a personal experience, and new contributors may not join Wikipedia with such a motivation.
Like the English Wikipedia, Education program is still active on Persian Wikipedia, and we have restored it. As one of the trainers and speakers in the workshops we hold to promote Wikipedia in universities, I use Adam Smith’s “invisible hand” concept to motivate students. This means that if the owner of a restaurant gives you a bowl of soup for free along with the main course, it is not out of pure kindness or generosity but rather an attempt to encourage you to visit again. Because it benefits you (you received a free bowl of soup) and it benefits the owner (you may return to the restaurant), individual interests invisibly guide you toward an outcome that benefits the collective.
In these workshops, I highlight Wikipedia’s personal benefits alongside its collective and public value. For example, in addition to contributing to Wikipedia, you gain access to a valuable resource such as the Wikipedia Library, which helps you find more material to study. Another point I emphasize is that Wikipedia can serve as your sandbox for learning how to write scientific articles and develop academic and scientific thinking. (This was true for me as well in the early stages, as I became familiar with scientific literature through Wikipedia.) It can help you pursue your scientific and research goals. In some cases, I even mention Wikipedia’s collaborative and international events, which allow you to exchange experiences and knowledge with contributors from other communities and cultures—an enjoyable and enriching activity. However, the methods I have proposed are not feasible for many non-academic participants, and new ideas and solutions need to be put forward to generate further discussion and debate on this issue. This is especially true for our wiki because the Persian-speaking community (compared to the English Wikipedia) is made up of developing countries and individuals may face certain constraints to participation (such as long working hours, economic hardship, etc.).
Sorry for the rambling. The issue of maintaining contributions and increasing those contributions is a very important issue. This means escaping the algorithm or ignoring the risks that may jeopardize the continuity of the project. This is crucial because Wikipedia, like many institutions like Westinghouse or academic institutions that have been around for a long time (although Wiki is different from commercial companies), has the ability to adapt to progress and technology. There are two possible futures for Wikipedia. Either it changes itself with the new conditions, or if it cannot keep up with them, it is forgotten. Pereoptic Talk✉️   15:28, 7 December 2025 (UTC)[reply]
Could you respond to the concern regarding fabricated quotes above? ~2025-31733-18 (talk) 18:35, 7 December 2025 (UTC)[reply]
Of course, I did not start this discussion to talk about my personal experiences or to promote my wiki (I am afraid that, as happened at the beginning of the discussion when they complained about minor issues, some users might say, “So what does this have to do with us?”). It simply responded to the question you raised.
My main goal in creating this discussion was, first, to find out whether the Foundation has a solution to the problem of declining user numbers and what contribution I and other users can make in this regard. This is important because the golden period for taking action to find solutions and adapt Wikipedia to the new Internet ecosystem might be now, before the project faces a sharp decline in participation and page views.
For example, over the long lifespan of Wikipedia, the trend in the number of new registered user has been downward, and this data is statistically significant. A similar pattern is visible in the statistics for all editors. A probabilistic explanation also suggests that if the graph continues to follow the same behavioral regime, based on the fact that the number of edits and active contributors remained constant during the same period of time then in the future edits per user will increase while the number of users will decrease, meaning that even future active users will have to participate more actively than current active users in order for the total number of edits to remain constant and a drop in the number of edits can be expected in the future. Pereoptic Talk✉️   17:10, 8 December 2025 (UTC)[reply]
Thank you so much for all this detail, @Pereoptic! I agree with you that we should feel a sense of urgency to turn these trends around and ensure our projects are sustainable long-term, and hearing different perspectives on things like what motivates you to edit are really helpful for us to ensure that we're not too biased towards one particular problem space or wiki as we try to address these challenges over the coming years with our strategy. It's good to hear that The Wikipedia Library and collaborative events are strong motivators for you - I agree! In fact, we just recently deployed a new feature you might be interested in on the CampaignEvents extension that lets you attribute an edit to a specific event as part of a collaboration. SPerry-WMF (talk) 22:48, 10 December 2025 (UTC)[reply]

Wikimedia Foundation announces new CEO, Bernadette Meehan

[edit]

From the Wikimedia Foundation:

The Wikimedia Foundation Board of Trustees has appointed Bernadette Meehan as the new CEO of the Wikimedia Foundation. She will officially join on January 20, 2026. Current CEO Maryana Iskander will stay in her role until then for a seamless handoff.

Bernadette has spent her career in roles dedicated to mission driven and public service work. Most recently, she served as the U.S. Ambassador to Chile from 2022-2025. Prior to her ambassadorship, she served as Executive Vice President for Global Programs at the Obama Foundation, where she designed and led international leadership programs spanning Africa, Asia-Pacific, Europe, Latin America, and South Asia. You can read more about her background below and the announcement to the media here.

Bernadette joins the Foundation at an important moment, on the cusp of Wikipedia’s 25th birthday. The world is facing unprecedented social, technological, regulatory and generational shifts. How people search and find information is being transformed. As Wikipedia’s influence has grown, so too has the importance of ensuring that people and decision makers understand its model and contribute to its future. Now more than ever, we need to increase awareness about the Wikimedia projects, and Bernadette will be the right leader to guide the Foundation in this new era.

qcne (talk) 19:00, 9 December 2025 (UTC)[reply]

Hello, I don't know anything about the qualifications for Wikimedia CEOs in the past, but are they usually Wikimedia editors or community figures? What does Ms. Meehan's career have to do with the Wikimedia movement specifically? ✨ΩmegaMantis✨blather 20:32, 9 December 2025 (UTC)[reply]
@OmegaMantis The trend has been for CEOs to be executives with non-profit experience, with no Wikipedia editing experience. As CEO they would direct priorities, strategy, budgets, policy, etc of the Foundation, so would have some removed impact on the English Wikipedia. qcne (talk) 20:37, 9 December 2025 (UTC)[reply]
Ah, ok. Thanks for the quick response! ✨ΩmegaMantis✨blather 20:38, 9 December 2025 (UTC)[reply]
I don't think we have ever had a CEO who was a Wikimedia editor or community figure in any real sense. We have also never had a board member with any experience creating an encyclopedia in academia or commercial publishing. The nearest was Sue Gardner, the longest-serving CEO (and many would say the best), from December 2007 to May 2014. She is a Canadian journalist, previously "the director of the Canadian Broadcasting Corporation's website and online news outlets". One thing all WMF CEOs share (Meehan will be the 6th) is being women. Johnbod (talk) 22:20, 9 December 2025 (UTC)[reply]
Interesting that User:Feelingfancyfree created the article Bernadette Meehan and was a blocked as a sock a few months later, followed by paid editing revelation. Is there anymore to this story? Asking for a friend.​ CNC (talk) 02:19, 10 December 2025 (UTC)[reply]
As an ambassador she was notable on her own right, so I do not see any issues with this. The article was properly sourced. Ymblanter (talk) 21:30, 10 December 2025 (UTC)[reply]
As a spokeswomanperson for the National Security Council you mean, but ok. CNC (talk) 21:37, 10 December 2025 (UTC)[reply]

Wikimedia Foundation Bulletin 2025 Issue 23

[edit]
Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on November 21. This will be the final bulletin for 2025 and we'll be back in late January 2026 with the next issue. Please help translate.

Upcoming and current events and conversations
Let's Talk continues

  • CEO appointment: The Wikimedia Foundation Board of Trustees has appointed Bernadette Meehan as the new CEO of the Wikimedia Foundation. She will be meeting communities around the puzzle globe when she officially joins on January 20, 2026.
  • Wikipedia's 25th birthday party: Join the virtual celebration for games, prizes, musical performances, volunteer spotlights, data visualization, surprise guests and more. January 15 at 16:00 UTC. Register on Meta.
  • Wikimedia Foundation Board of Trustees: Join the next Conversation with the Trustees on December 11 at 17:30 UTC.

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

  • Wishathon: 15 patches were written and 5 merged, as part of a Wishathon for the Community Wishlist. One wish from the community was completed ("Preview page with this template" should not work with pages that do not transclude the template), and three more now have a clearer path forward.
  • Activity Tab on Mobile App: The Wikipedia iOS app is running an experiment that replaces the History tab with a redesigned Activity tab. This new tab surfaces personalized insights about reading, editing, and donations — all stored locally on your device for privacy. The goal is to see whether the new experience increases engagement and retention among logged-in readers.
  • Wikipedia Year in Review in Apps: The Wikipedia Year in Review 2025 is now available for the iOS and Android apps. This year introduces new personalized insights, updated reading highlights, and refreshed designs.
  • Add a Link: A feature that suggests links to be added to articles based on a prediction model, Add a link, has been deployed at Japanese, Urdu and Chinese Wikipedias. While this feature has already been available on most Wikipedias, the prediction model could not support certain languages. A new model has now been developed to handle these languages, and it will be gradually rolled out to other Wikipedias over time.
  • Abstract Wikipedia: The second round of voting on the name of Abstract Wikipedia concluded with Abstract Wikipedia as the top-voted name with 100 votes, followed by Wikigenerator with 91 votes. The name for the wiki project will now remain Abstract Wikipedia.
  • Anti-vandalism tool: Automoderator, now has the option to choose between two machine learning models to power the software on wikis using the tool.
  • Tools to support newcomers: Newcomers failing to add a citation to support added content has been one of the most common mistakes on Wikipedia. Reference Check, a tool that prompts them to add a citation before publishing an edit, has gone live for an A/B test on English Wikipedia.
  • Tech News: Latest updates from Tech News week 48 and week 49 include the Foundation working on improving the text and presentation of the Verification Email sent to new users to make them more welcoming, useful, and informative; and two new wikis being created: a Wikipedia in Toki Pona and a Wikiquote in Nigerian Pidgin.
  • Infrastructure: Unifying our mobile and desktop domains achieved 20% faster mobile response times, improved SEO, and reduced infrastructure load.

Annual Goals Progress on Volunteer Support
See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog · WikiLearn News · list of movement events

  • Legal win in France: Wikimedia Foundation secures crucial legal win in France against legal attacks on freedom of speech.
  • CEE Hub: Overview of three years of growth, learning, and regional impact of CEE Hub.
  • Don't Blink: The latest developments from around the world about protecting the Wikimedia model, its people and its values.
  • Digital Violence: How the Wikimedia movement is responding to digital gender based violence.
  • Wikimedia Research Showcase: The next research showcase will feature a special panel on "Experimentation on Wikipedia" and will take place on December 10 at 17:30 UTC.

Annual Goals Progress on Effectiveness
See also: Progress on the annual plan

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

Foundation statements


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

Subscribe or unsubscribe · Help translate

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


MediaWiki message delivery 04:50, 11 December 2025 (UTC)[reply]

Wikipedia’s 25th birthday party on January 15

[edit]

Hiyas. Sharing an invite to Wikipedia’s 25th birthday party, happening on January 15 at 16:00 UTC. It’ll be an hour-long virtual event with trivia, prizes, musical performances, dramatic readings, spotlights on editors, and special guests. The event will be live-interpreted in 6 languages and streamed to Eventyay and Wikipedia’s YouTube. You can register for the event to save the date and get updates, and please let me know if you have questions :) RAdimer-WMF (talk) 20:48, 11 December 2025 (UTC)[reply]

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