TheWMF section of thevillage pump is a community-managed page. Editors orWikimedia 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.
Discussions of proposals which do not require significant foundation attention or involvement belong atVillage pump (proposals)
This page isnot a place to appeal decisions about article content, which the WMF does not control (except invery rare cases); seeDispute resolution for that.
Issues that do not require project-wide attention should often be handled throughWikipedia:Contact us instead of here.
This board is not the place to report emergencies; go toWikipedia:Emergency for that.
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 areuncivil maybe removed without warning.Personal attacks against other users, including employees of the Wikimedia Foundation, will be met with sanctions.
(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 be6 accounts per 24 hour period?)~2025-30907-85 (talk)08:26, 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]
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, willAndrew5 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]
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]
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]
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]
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.
~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]
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]
Is anyone else getting a weird bug of usernames getting cut across the linebreak in mobile watchlist view? I suspect it might be an issue only for admins and/or editors with temporary account viewer permissions?signed,Rosguilltalk15:46, 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 everythingexcept the ip itself), and even turning on autoreveal doesn't do anything. —Cryptic17:18, 4 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 andreverted somefairly 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 beenblocked 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 amongother things that escaped the three-month window. Imessaged 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, includingthis 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]
Another fun fact: it looks like a TA gets created when youtry to make an edit, even if it fails. In my case, I opened an incognito window, tried to editWP: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]
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]
Thelink 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]
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 TAwas 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]
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]
As an aside, long-term I think we will want to move away from using Twinkle for blocks and have everyone useSpecial: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 leaveSpecial:Block to do their job.—MusikAnimaltalk19: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]
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 wasany 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 ofphab: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 ifI will be able to maintain it, is all! The multiblocks project was a massive effort. I didn't have it in me toparity that in Twinkle. Especially after hearing theaffirmation from @Novem Linguae, I figure engineering resources are better spent on Special:Block so that all wikis get the same benefits.—MusikAnimaltalk03: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]
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]
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]
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 fromhere 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]
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]
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]
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 - WikipediaJeffUK09:41, 11 November 2025 (UTC)[reply]
I created another CSS-only version (seeUser: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]
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 userUser 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..JeffUK10:39, 10 November 2025 (UTC)[reply]
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.ChildrenWillListen (🐄 talk,🫘 contribs)04:44, 5 November 2025 (UTC)[reply]
TheSpecial:ActiveUsers count (NUMBEROFACTIVEUSERS) which appears on the Main Page has sharply jumped in the last few days, from around 115 thousandon 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]
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.JeffUK10:44, 10 November 2025 (UTC)[reply]
@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]
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?
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 areWP: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]
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 theopposite of what you claim.Tercer (talk)09:19, 9 October 2025 (UTC)[reply]
Reacting once an implosion has occured is too late. How is a community going to recover from said implosion anyway?
Inphab: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 alwaysIP 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 voteno 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. --LCUActivelyDisinterested«@» °∆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 recentUSHL season pages have been maintained by an IP who’s filling a valuable gap inWP:NHL.TheKip(contribs)02:13, 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]
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 notgood, 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.SeraphimbladeTalk to me22: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]
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.Lynch4416:52, 2 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 Sohomposted 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.JeffUK11: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.DarwinAhoy!09:29, 10 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]
It's better than what it was before. The barrier to seeing IPs used to benothing. 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.
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 grantingWP: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 anyWP:LTA category), something they would still have to do if registration is required.Jasper Deng(talk)19:59, 15 November 2025 (UTC)[reply]
I unfortunately agree — but I don’t like it. I was a IP editor for multiple weeks before creating an account and I truly think it’s beneficial. I’d hate to block IPs but if it is necessary it is necessary than. I do agree to move it somewhere more visible. I don’t know where though. Have a nice day. I hope I’ll soon get a notification saying that this discussion was moved. Best wishes,Macaw*!01:14, 24 November 2025 (UTC)[reply]
Unfortunately, anonymous editing (whether IP addresses or temporary accounts) does not really work anymore. Many IP addresses are dynamic. The presence of anonymous editing means that semi-protection on thousands of pages and range blocks like 2600:100f:b000::/40 (and even worse, the T-Mobile range block) are necessary. Both of these are arguably worse than prohibiting edits without an account, as they add a time barrier in addition to just five clicks. Requiring accounts is arguably less restrictive than protecting pages or making range blocks. In fact, my range was banned so I had to request an account! In addition, the standards for viewing IP addresses are too low. Any person with 300 edits and 6 months, and some simple work can get the permission. Even ban evaders could get it. These standards are way too low. Also, data from the Portuguese trial shows almost no negative effects from requiring accounts.
While I am not yet a firmyes 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 abit 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]
Inour 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 thecheckuser 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 beenabling 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.
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 (akaL235·t·c)16:11, 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 (akaL235·t·c)16:01, 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.
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 thefree software movement (such asRichard Stallman) block/refuse to run nonfree, non-trivial JavaScript through extensions likeLibreJS, 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 thanpossiblythat 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]
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]
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]
outsourcing captchas to a third party is a great way for that party to collect massive amounts of data to sell to advertisers.
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.
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✨blather02: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 isperfect, 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.ChildrenWillListen (🐄 talk,🫘 contribs)23:23, 23 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...
@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
@Sohom Datta maybe I am confused or didn't explain it well, but onon 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]
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 theMain 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]
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 choosenWP: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 parsingNovember 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 onNovember 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 contentlinked from the main page, and contentshown 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 editNovember 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 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 isdreadful. 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 doingKowal2701 (talk)12:39, 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 useWikipedia: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 awiki 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 itSohom (talk)17:52, 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]
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 throughexternal 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 theWikimedia Foundation’s annual plan and theReaders 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 morehere.
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.
New capabilities we’re exploring on the apps
Explore feed
You are right that the Explore Feed could use an upgrade. We want it to be easy for people to discover content of interest when they are browsing. We have plans to revamp the Explore Feed in May to address some of the gaps that have been raised (for example, surfacing content across wikis in more useful ways). There will be outreach to shape the new explore feed in late January, in the meantime, consider signing up for theapp's newsletter so you can receive updates directly on your talk page.
WikiTrivia game
It is also understandable to have curiosity as to why features like theWikiTrivia game exist. With the challenge of readers coming to Wikipedia for a single question and leaving, simple, low-effort interactions can help people discover articles they might not have found otherwise, which in turn can lead to them to read more and return more often.
WikiTrivia is one example of this and actually leverages theOn This Day page curated by the community. It gives readers an enjoyable way to discover articles that they can then read, save, or share. We havereceived positive feedback and requests for more games through in-app feedback forms, our support emails, project pages,press and play store reviews. Based on the positive feedback anddata from Android, we plan to bring it to iOS as well in 2026.
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 toYear-in-Review which was only available on iOS last year but is currently available onboth 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 ourdiscussion page and stay informed by subscribing to the appnewsletter. 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 forreaders andeditors.
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 relatedPhabricator 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]
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 isHelp: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.
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.PereopticTalk✉️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 garblingthis interview about a mass article creation bot, i.e., the near exact opposite.)
@Gnomingstuff: This article is only a starting point for initiating a discussion about the impact of AI on Wikipedia. We should avoidFocalism. 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 towebsites 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 onWikipedia 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.PereopticTalk✉️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 atWP:LLM.CMD (talk)11:23, 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.PereopticTalk✉️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.
"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.PereopticTalk✉️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 ablog 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 astrategy 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 toget 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 theWiki 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 asthe 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.PereopticTalk✉️15:28, 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 ofnew registered user has been downward, and this data is statistically significant. A similar pattern is visible in the statistics forall editors. A probabilistic explanation also suggests that if the graph continues to follow the samebehavioral 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.PereopticTalk✉️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 anew feature you might be interested in on theCampaignEvents 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
The Wikimedia Foundation Board of Trustees has appointedBernadette 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 theannouncement 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.
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✨blather20: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]
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 wasSue 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]
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 helptranslate.
Upcoming and current events and conversations Let's Talk continues
CEO appointment: The Wikimedia Foundation Board of Trustees hasappointed 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 onDecember 11 at 17:30 UTC.
Activity Tab on Mobile App: The Wikipedia iOS app is running an experiment that replaces the History tab with aredesigned 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: Thesecond round of voting on the name of Abstract Wikipedia concluded withAbstract Wikipedia as the top-voted name with 100 votes, followed by Wikigenerator with 91 votes. The name for the wiki projectwill 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.
Wikimedia Research Showcase: The next research showcase will feature a special panel on "Experimentation on Wikipedia" and willtake place on December 10 at 17:30 UTC.
Annual Plan Progress: A look back at progress made against the planduring the second half of our fiscal year. Up to date regular updates are included in the Foundation Bulletin.
For information about the Bulletin and to read previous editions, see theproject page on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!
Hiyas. Sharing an invite toWikipedia’s 25th birthday party, happening onJanuary 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]
Resolved
wikimedia.org know if you have any feedback or suggestions for improvement!