User talk:Matma Rex

Help test better mass message delivery

Hi. You're being contacted as you've previously used global message delivery (or its English Wikipedia counterpart). It doesn't feel so great to be spammed, does it? ;-)

For the past few months, Legoktm has built a replacement to the current message delivery system called MassMessage. MassMessage uses a proper user interface form (no more editing a /Spam subpage), works faster (it can complete a large delivery in minutes), and no longer requires being on an access list (any local administrator can use it). In addition, many tiny annoyances with the old system have been addressed. It's a real improvement! :-)

You can test out MassMessage here: testwiki:Special:MassMessage. The biggest difference you'll likely notice is that any input list must use a new {{#target:}} parser function. For example, {{#target:User talk:Jimbo Wales}} or {{#target:User talk:Jimbo Wales|test2.wikipedia.org}}. For detailed instructions, check out mw:Help:Extension:MassMessage.

If you find any bugs, have suggestions for additional features, or have any other feedback, drop a note at m:Talk:MassMessage. Thanks for spamming! --MZMcBride (talk) 05:25, 1 October 2013 (UTC)

Beginning of MassMessage, end of EdwardsBot

Hi. You're being contacted as you're listed as an EdwardsBot user.

MassMessage has been deployed to all Wikimedia wikis. For help using the new tool, please check out its help page or drop a note on Meta-Wiki.

With over 400,000 edits to Wikimedia wikis, EdwardsBot has served us well; however EdwardsBot will no longer perform local or global message delivery after December 31, 2013.

A huge thanks to Legoktm, Reedy, Aaron Schulz and everyone else who helped to get MassMessage deployed. --MZMcBride (talk) 02:36, 22 November 2013 (UTC)

Translation of Module namespace name

Hello, Matma Rex! I'm an administrator at ro.wiki and I would like to localize the name of the Module namespace. The page https://www.mediawiki.org/wiki/Help:Namespaces#Localisation directs me at https://translatewiki.net/w/i.php?language=ro&module=namespace&title=Special%3AAdvancedTranslate, but I can't find the Module namespace there. I also found the page Lua deployments/Localization of Module, but I see you closed it because the issue https://bugzilla.wikimedia.org/show_bug.cgi?id=46082 is resolved. How should we translate the name of the Module namespace now? Have a happy new year, Rsocol (talk) 18:26, 31 December 2013 (UTC)

The translations should be "Modul" and "Discuție Modul". Thanks, Rsocol (talk) 05:31, 3 January 2014 (UTC)

See also Stewards' noticeboard#Renaming namespaces and https://translatewiki.net/wiki/Support#Rename_module_namespace_40423. Rsocol (talk) 05:37, 3 January 2014 (UTC)

Letter petitioning WMF to reverse recent decitions

The Wikimedia Foundation recently created a new feature, "superprotect" status. The purpose is to prevent pages from being edited by elected administrators -- but permitting WMF staff to edit them. It has been put to use in only one case: to protect the deployment of the Media Viewer software on German Wikipedia, in defiance of a clear decision of that community to disable the feature by default, unless users decide to enable it.

If you oppose these actions, please add your name to this letter. If you know non-Wikimedians who support our vision for the free sharing of knowledge, and would like to add their names to the list, please ask them to sign an identical version of the letter on change.org.

• Letter to Wikimedia Foundation: Superprotect and Media Viewer
• Letter on change.org

I'm notifying you because you participated in one of several relevant discussions. -Pete F (talk) 22:13, 20 August 2014 (UTC)

Global user page migration

Hello Matma Rex. Synchbot deleted your local user pages on all wikis as requested. You can see the full log on your archive page. :) —Pathoschild 03:34, 22 February 2015 (UTC)

Editinterface rights expired

Hello, your editinterface rights have expired. Please start a new request on SRGP to refresh them. Thanks for the work you've done over the past year with them! Ajraddatz (talk) 04:48, 2 June 2015 (UTC)

@Ajraddatz: Thanks for the reminder, did it now. Matma Rex (talk) 17:59, 3 June 2015 (UTC)

When next week's Tech News issue doesn't exist

Hey, thanks for adding something for next week's issue. Feel free to initiate the next issue if you need it for some reason – less risk of me (or someone else) missing the hidden item and leaving it there for the translators in the wrong week. (: You could also add it to the talk page, either of the issue being prepared or just the general Tech News talk page. /Johan (WMF) (talk) 14:31, 28 June 2018 (UTC)

The Community Wishlist Survey

Hi,

You get this message because you’ve previously participated in the Community Wishlist Survey. I just wanted to let you know that this year’s survey is now open for proposals. You can suggest technical changes until 11 November: Community Wishlist Survey 2019.

You can vote from November 16 to November 30. To keep the number of messages at a reasonable level, I won’t send out a separate reminder to you about that. /Johan (WMF) 11:24, 30 October 2018 (UTC)

Your temporary access has expired

Hello, the temporary global access you requested has expired. Just to let you know that If you want it back, feel free to open a new request on stewards' global permission request page on Meta-Wiki later. Please ask me or any other steward if you have any questions. Thank you! — regards, Revi 18:59, 28 February 2019 (UTC)

Your temporary access is going to expire soon

Hello Matma Rex. You were granted temporary global permissions which is going to expire in a few days (17 March 2020). Just to let you know that if you want to continue with the access, you need to request an extension on stewards' global permission request page on Meta-Wiki. Please ask me or any other steward if you have any questions. Thank you! —MarcoAurelio (talk) 11:52, 1 March 2020 (UTC)

Your temporary access has expired

Hello, the temporary global access you requested has expired. Just to let you know that If you want it back, feel free to open a new request on stewards' global permission request page on Meta-Wiki later. Please ask me or any other steward if you have any questions. Thank you! --—Thanks for the fish! ^{talk•contribs} 20:33, 30 March 2020 (UTC)

A barnstar for you!

		The Community Wishlist Survey Barnstar
		For completing the wish proposal: Improve plain-text change tag selector! NRodriguez (WMF) (talk) 21:30, 3 March 2022 (UTC)

NRodriguez (WMF) (talk) 21:31, 3 March 2022 (UTC)

Reminder to vote now to ratify the Wikimedia Movement Charter

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Dear Wikimedian,

You are receiving this message because you previously voted in the 2021 Movement Charter Drafting Committee (MCDC) election.

This is a reminder that if you have not voted yet on the ratification of the final Wikimedia Movement Charter draft, please do so by July 9, 2024 at 23:59 UTC.

You can read the final text of the Wikimedia Movement Charter in your language. Following that, check on whether you are eligible to vote. If you are eligible, cast your vote on SecurePoll.

On behalf of the Charter Electoral Commission,

RamzyM (WMF) 15:24, 5 July 2024 (UTC)

Notice of Patch Demo Wikis Cleanup

You are receiving this message because there is/are wiki(s) on Patch Demo associated with your account. Per our records, the patches associated with them have been merged or abandoned. In an effort to manage space and ensure our systems have the capacity to continue providing the best service and experience for our users, we will be auditing and deleting wikis with merged or abandoned patches on Friday, March 14 2025.

Please refer to the list of wikis we will be deleting [1] and if you wish to keep any of the ones that belong to you, edit the table accordingly before Thursday, March 13 2025 11:59PM UTC. If we do not hear from you by then we will assume you are not opposed to this action and will proceed as planned. EBomani-WMF (talk) 22:20, 6 March 2025 (UTC)

Notice of expiration of your global-interface-editor right

Hi, as part of Global reminder bot, this is an automated reminder to let you know that your global permission "global-interface-editor" will expire on 2025-07-13 13:11:53. If you want to renew this right, please file a request at SRGP. In other languages: click here Leaderbot (talk) 19:41, 6 July 2025 (UTC)

Join us for “Many Tongues, One Movement: Voices Across Languages”!

Hello Matma Rex,

We’re excited to invite you to an inspiring global virtual gathering: the first Capacity Exchange Translat-a-thon.

Together with Language Diversity Hub, the Capacity Exchange (CapX) team will host its first Translation Marathon dedicated to ensuring linguistic equity in access to this amazing tool aimed to connect Wikimedians.
If you enjoy contributing to Wikimedia projects through translating and adapting content into different languages, this event is for you! Join us in the celebration of the multilingual spirit of the Wikimedia Movement at an event where communities that contribute in diverse languages will be able to share local knowledge and collaborate across borders.
Many Tongues, One Movement: Voices Across Languages

• Date: December 6, 2025
• Time: 12 PM (UTC) - Check the event page for your local timezone
• Location: Online (Meta-Wiki + live session links)

Register for the Event here

If you can’t join the live event, you can still contribute to the translations! Edits will be counted for two weeks, until December 20th. And everyone who participates will receive a special badge to display on their CapX profiles.

Strengthen your collaboration through CapX

We invite you and your community to join the Capacity Exchange (CapX), a Wikimedia community-built platform for connecting, collaborating, and exchanging skills with peers across the movement.

CapX helps Wikimedians and organizations find each other, share expertise, and build stronger, more connected communities.

Whether you’re an individual contributor, a user group, a community initiative or an affiliate, CapX helps you grow through knowledge exchange.

Sign up to CapX

More information

→ Explore the CapX platform: capx.toolforge.org
→ Read: User Guide & FAQ
→ Watch: Meet the Capacity Exchange video
→ Join our Telegram community chat: CapX Telegram Group

If your community, usergroup or affiliate would like to have a CapX organization profile, please reach out at capx@wmnobrasil.org, and we’d be delighted to support you.

With warm regards,
Joris Darlington Quarshie
Outreach Facilitator,
Capacity Exchange Project – Wikimedia Brasil

MediaWiki message delivery (talk) 14:55, 13 November 2025 (UTC)

Gerrit

Hello! I'd like to ask if you're interested in continuing to be added as a reviewer on my Gerrit changes. Most of the code is in JavaScript, since I have more experience with it, and the rest is in PHP. Thank you. IKhitron (talk) 18:30, 21 December 2025 (UTC)

@IKhitron Hi, I don't mind it :) I was happy to see your name on Gerrit. I didn't have time to review it yet, since I had a busy week or two, but I'm having a look now. Matma Rex (talk) 21:27, 22 December 2025 (UTC)

Thanks a lot. IKhitron (talk) 21:28, 22 December 2025 (UTC)

Thank you very much for the patch approval. There are three more patches ready, for extremely small patches, it took five minutes to write them. When two more people answer to this gerrit question in the section topic, I will be able to add everybody that agreed to the reviewers list. IKhitron (talk) 21:56, 22 December 2025 (UTC)

Wow. Thanks again a lot. But I'm curios, how did you know what to do in the patch demos, I did not publish the instructions yet? IKhitron (talk) 22:11, 22 December 2025 (UTC)

@IKhitron Well, all I had to do was to make some edits, watchlist a page, and have a look at Special:GlobalWatchlist, right? It was easy enough to figure out from your commit messages and the linked tasks, and the patches were indeed simple. Matma Rex (talk) 22:43, 22 December 2025 (UTC)

I see. Yes, it's easy. But no, all this was already done on Alice's account, with possible cases. IKhitron (talk) 22:50, 22 December 2025 (UTC)

Oh… I don't think I looked at your demos for them, I just tested them myself. I'll keep that in mind to save some time in the future! Matma Rex (talk) 23:00, 22 December 2025 (UTC)

Wikimedia Hackathon Northwestern Europe 2026

Hello! I came across your name on a previous Wikimedia hackathon participant page, so I thought you might be interested in this.

We're organizing the Wikimedia Hackathon Northwestern Europe 2026, taking place on 13–14 March 2026 in Arnhem, the Netherlands. It's a two-day, in-person hackathon for technical Wikimedians from the region.

Since you've attended a hackathon before, you already know how valuable these events can be for collaboration, learning, and getting things done together. We'd love to have you join us!

Apply here – registration closes mid-January or when full.

Feel free to reach out if you have any questions. Hope to see you in Arnhem! Daanvr (talk) 17:49, 12 January 2026 (UTC)

Beta Cluster

Hello. First thing, let me thank you again for all you're doing for Global Watchlist on Gerrit in last weeks, I'm very grateful. I'm here to ask for your advice. There is one patch in WIP, entry structure rebuild, you still had no time to answer in the Phab task, that I do not want to merge to master when it will be ready. I just do not know what will happen with it in real, big wikifarm, with different kinds of wikis. And as we could see yesterday, Testwiki is too late. What do you thing about the possibility to merge this specific change to Beta Cluster, when and only when it will be completely ready? If there are mistakes, we could see them before the deployment and fix in time. For example, I expect uncertainty on Wikidata in this new change, and there is no way to test it in Patch Demo, but Beta Cluster has its own Wikidata. I consider even to add to this change a couple of lines for another small Wikidata-directed task, it fits the theme, so it will be tested together. And yes, Beta Cluster Meta has Global Watchlist, connected to the rest of the cluster by its own CentralAuth. What do you think? Thank you in advance. IKhitron (talk) 08:38, 21 January 2026 (UTC)

@IKhitron That sounds alright to me, however, note that deployment to the Beta Cluster is normally automatic – if I approve a patch on Gerrit, and it gets merged into the Git repository, then a few minutes later is gets deployed to the Beta Cluster by an automated job (https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/How_code_is_updated). This job can be stopped, and the code can be deployed manually, but this will prevent other changes from being automatically deployed.

Given the above, I think the easiest way to test on Beta Cluster is to just approve the patch on Gerrit, so it will be deployed there automatically. You'll have a few days to test and submit any additional patches before the production deployment starts on the next Tuesday (https://wikitech.wikimedia.org/wiki/Deployments/Train). Does that sound okay? Matma Rex (talk) 18:54, 21 January 2026 (UTC)

Thank you.
a few minutes later is gets deployed to the Beta Cluster by an automated job
Didn't know that, it's great.
Does that sound okay?
If I would work alone I would say yes, but I don't know when anyone (probably you) approves the change, it can be hours before Tuesday morning branch cut. I can't tell you "check it in specific day", it's just rude. And also, if I find a problem, and since the moment I wrote fix until Tuesday morning there is nobody to approve the fix, because I can't tell "check it in specific day" again, it's another problem. Especially taking into account that it will be a big change, and it will take time to approve it. So, I don't know what to say. IKhitron (talk) 19:01, 21 January 2026 (UTC)

I can still review it whenever I want, and only click the big button later. Just make a note on the patch that it should be merged after a branch has been cut to give more time for testing, nothing rude about it, it's a fairly common practice for patches that are risky or require a complex setup to test. I'll make sure to be available to review any follow-up patches if they are needed (or, in the worst case, we can always revert the patch and try again next week). Matma Rex (talk) 22:02, 21 January 2026 (UTC)

Great. Thanks a lot! IKhitron (talk) 22:05, 21 January 2026 (UTC)

In this case, is there a chance for me to make the other Wikidata task in a new change, or it's too much to ask? Thank you. Because I just thought about it, it looks very simple, but I can't test it even a little before the review, Wikibase is needed for just to see how it runs. IKhitron (talk) 22:42, 21 January 2026 (UTC)

Yeah, sure. Matma Rex (talk) 13:48, 22 January 2026 (UTC)

Great, thanks. IKhitron (talk) 13:54, 22 January 2026 (UTC)

thanks for passkeys & webauthn work phab:T358771

I saw that Passkeys were announced Tech News #5 (2026) . Thanks for all the help and effort working on webauthn & Passkeys phab:T358771 Tonymetz (talk) 23:14, 27 January 2026 (UTC)

Script Publisher - Community Wishlist 2022 implementation update

Hello Matma Rex,

I hope you are doing well. I am reaching out regarding the Community Wishlist Survey 2022 proposal you supported: “A bot or gadget to publish public Git repo to a gadget or user script”

Over the past few months, I have been working on implementing this as a Toolforge-based OAuth application called Script Publisher. The goal is to provide a web-based interface that allows users to publish JS/CSS files from a public Git repository (e.g., GitHub) directly to user scripts or gadget pages, with explicit preview and confirmation before publishing.

Current project links:

1. Toolforge deployment (work-in-progress MVP): https://script-publisher.toolforge.org/
2. Source code (public repository): https://gitlab.wikimedia.org/toolforge-repos/script-publisher/
3. Initial demo prototype: https://wikipublisher.vercel.app/

The tool currently supports:

• Public repository fetching
• File selection (JS/CSS)
• Mapping files to target wiki pages
• Preview before publish
• Manual publish flow (no background automation)

The main blocker now is OAuth approval for JS-editing permissions. WMF security has raised valid concerns around applications that can edit JavaScript pages, especially site-wide JS. The discussion is ongoing here:

1. User_talk:Dev_Jadiya#Script_Publisher
2. https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous#OAuth_permissions

Since you originally supported this wishlist proposal, your technical input and perspective would be extremely valuable. In particular:

• Does the current MVP align with what you expected from this wishlist?
• Are there safeguards you believe are necessary for responsible deployment?
• Would you be willing to share your view in the ongoing Meta discussion?

My intention is not to bypass any security expectations, but to implement this in a way that is aligned with community review standards (similar to bots or interface editors), while keeping the tool transparent, auditable, and limited to user-authorized edits.

Thank you again for supporting the original idea. I would truly appreciate your feedback. Regards, Dev Jadiya (talk) 14:38, 7 February 2026 (UTC)

More work

Hello again. First of all, thank you again for everything you are doing for the Global Watchlist extension. I'm here to report you that yesterday in the evening I finished everything I can do there for now. There is a big job that is waiting for me, that can easily take months, but I can't start until I get an answer on a theoretical question I asked a week ago in some place, I'm stuck without it. Of course, there is nothing that I could do that depends on you specifically, otherwise I would not open this topic at all, it would be rude. So, the question is: is there something you want me to do, for now, in this time I suddenly have, for the extension? Thank you. IKhitron (talk) 08:15, 10 February 2026 (UTC)

@IKhitron Hey. Sorry, I've been really busy over the last week or two. I'll look through your recent work eventually, but if there's anything you want me to look at first, please share a link here – I'm not sure what is the question that you're waiting for. I don't have any requests for you. Matma Rex (talk) 17:44, 10 February 2026 (UTC)

Please don't be. I can expect from people to answer a question quickly and surprised when they don't because it takes seconds. I definitely don't think this about checking code, or writing code, or any other thing that takes time, because people have a lot of other things to do. I do not think I have something above others in particular. But if you want me to, I can collect all the things I'm waiting and give you all the links in the order I need them, so if you have time and want to you can go through this order. And not looking for them between all the mails too. Thank you. IKhitron (talk) 17:51, 10 February 2026 (UTC)

Sorry, totally forgot to answer on this one. I asked there about how to change a system variable on Patch Demo. If and when they answer I will know if I can debug the big work. IKhitron (talk) 18:26, 10 February 2026 (UTC)

@IKhitron If you want to change it for all wikis, you'll want to propose a patch for Patch Demo here: [2] (this is in GitLab, not Gerrit). There isn't much documentation, but you can have a look at existing merge requests for examples. The configuration for GlobalWatchlist is here: [3]

If you want to change a config setting on just one wiki to test something, you can create a Gerrit patch that would change that config setting, mark it as WIP so it doesn't get merged by accident, and create a new Patch Demo using that patch (in addition to the code changes you want to test). There is no way to do this nicely in the interface at the moment. Here's an random example patch like this: [4]

Hope this helps! Matma Rex (talk) 19:40, 10 February 2026 (UTC)

I very appreciate that you wanted to help and answered, even I didn't ask you. I considered to ask, but decided not to waste your time, when you're doing already so much for the extension. I tryed your suggestion, and it did not work. The problem is that I need to change a mediawiki/core variable, such that it will work on every page in the wiki before it loads. I knew about DNM patch, and tryed some, but couldn't find the right place to edit. What I need is to make the Watchlist Labels work on Patch Demo, such that the page Special:WatchlistLabels, for example, will actually work instead of a red message "Watchlist labels do not work on this wiki".

And also, you didn't answer about the links list, so I see it as a no. If I'm wrong or if you change your mind, just say. Thank you. IKhitron (talk) 20:11, 10 February 2026 (UTC)

I had a look at a few patches just now, but I mostly picked the ones that seemed easy to review :) I just missed that question, feel free to send me a list of which ones are most important for you. I'll have a look at them next time.

Regarding WatchlistLabels on Patch Demo, I see your attempt: [5]. I guess the problem is that config changes to core have to be made in several places – for example, like this: [6] (yes, this is stupid and annoying). For a Patch-Demo-only patch, you can instead put the override at the end of includes/Setup.php, like this: [7]. Matma Rex (talk) 22:19, 10 February 2026 (UTC)

Thanks a lot. I'll check the comments in one of the changes, and try the Setup.php tomorrow. Also, will make the rebases. About the list, in "send" I believe you mean send in mail. Very well, will do.

UPD: Done, one phabricator comment and two changes. Thank you.

UPD UPD: The system variable works. Thanks a lot! IKhitron (talk) 22:29, 10 February 2026 (UTC)

Multiple sites

Hi. Thanks again for all you're doing. I'm here to tell you about something that I did and you may find it useful. Until now the Patch Demo did not allow to show more than one site for the Global Watchlist, the local one. It's because the extension does not support path-oriented wikifarms. So, the only way was to check the changes for one site and to hope it will work fine for many. But the job I'm working on now, that I mentioned you earlier, needs many sites just to be sure it works at all. I can't expand the extension to support the path-oriented wikifarms, though I want to, because I do not know a way to get an entry point for Foreign Action API just from the site URL. So today I wrote a DNM change that breaks the sites validation on php side and adds API entry points for Patch Demo hard-coded on javascript side. It will never be merged, so it shows wrong links everywhere, but it was very helpful for me to check if a change works, I found and fixed three errors. So, if you need or will need this change to check the extension, be aware of it. It shows the watchlists for wikis wiki2 to wiki9 in opening the Special page on wiki1 in wikifarm. IKhitron (talk) 20:31, 14 February 2026 (UTC)

One question, if you will. It's the same issue, though it doesn't look like this. You told I can ask you to hold the +2 for some changes and to release it in particular day of the week. For the change I finishing now I'd like to do something different. Is there a way to open it to review when it will be ready, but that you'll hold it not until a particular day, but until the follow up change will be ready? I think the first one could really frighten the users without the second one, so it will be much better to deploy them together, when the second one will be ready. The reasons I'm not doing them altogether in the same change are: a) they take care for different things; b) if I would not be able to solve the second one, which is always possible in this task, the first one still be ready; and 3) it would be better for me to change the second one, if needed, knowing the comments of the reviewers and the edits they asked me to do in the first one, to be able to adjust the second one. So, what do you say? Thank you in advance. IKhitron (talk) 20:18, 15 February 2026 (UTC)

Yeah, sure. Matma Rex (talk) 00:00, 16 February 2026 (UTC)

Thanks a lot. IKhitron (talk) 07:27, 16 February 2026 (UTC)

Thank you and we have a problem

Hello. Thanks a lot for approving the labels patch. I'm glad you accept the concept, it means I can start with a php side work on this. I'm also glad you finally could find some time for it in between other things you do every day, and you do a lot, I can see your name in so many places in every-day's mail. So it's understandable that you could forgot this conversation. We spoke about holding with the merge until after the second half is approved so they can be deployed at the same time. I would stop the merge if I wouldn't sleep in this time. So, what can we do now:

1. Ignore this and hope people that already use labels (not so many, I believe, the labels are just at there beginning).
2. Revert this patch temporarily.
3. Try to approve the second half patch very quickly. I oppose this one because rush will bring problems and missed issues for sure.

What do you prefer? Also, I tried to check the first half you just approved on Beta Cluster to be sure it's fine and unfortunately discovered my provider was blocked from Beta Cluster. I created phab:T422238 and really hope there will be enough time to check the patch until Monday evening branch cut.UPD: Checked, it's fine. Thank you very much once again for everything you are doing for the extension. IKhitron (talk) 08:55, 3 April 2026 (UTC)

Indeed I forgot, I'm sorry. To be honest, the patch I approved worked great and it felt quite complete :) I don't think we need to revert it. Matma Rex (talk) 20:49, 3 April 2026 (UTC)

Very well. No problem, I understand you have a lot on your mind. But I'm not going to say a word in Tech News until the second half is deployed. IKhitron (talk) 20:57, 3 April 2026 (UTC)

Rate limits

Hi. I'm starting to think the incoming global rate limits will kill the extension. I do not believe I am able to rewrite the whole code in php, and "do not make more than 3 concurrent requests" is way too small number for us. What do you think? (It does not mean I'm asking you not to check the gerrit changes, if you have time, of course, (-: ).
N3: Got an answer there. Could be some problems in regular mode and many problems in Live updates mode, but looks like the extension will survive. IKhitron (talk) 12:55, 2 March 2026 (UTC)

Well, looks like I'm going to start coding a lot tomorrow to do it in time. Oh, dear.
UPD: I reviewed the JavaScript files in repository. This is what I suggest:
1) Leave all the random API calls in JavaScript. For example, unwatch page or mark page as seen.
2) Move all systematic API calls to php. It includes those.
3) Get watchlist. One call to php which splits the array to 500-entries chunks, makes as much calls as needed and returns the result in one piece.
4) Possibly EntitySchema calls.
5) Probably "mark label as seen calls".
What do you think? IKhitron (talk) 19:19, 2 March 2026 (UTC)

Hi. Personally, I would wait and see if GlobalWatchlist ends up actually exceeding any rate limits for anyone. It would take a lot of requests to exceed "a few thousand per user per hour". Maybe the live mode could cause trouble if you leave it running in the background, but perhaps that could be fixed by just making it query less often (it is apparently hardcoded to checking every 7500 ms, or 8 times per minute).

In general it wouldn't hurt to make the extension do fewer API queries and make it send them sequentially rather than concurrently, but right now I don't think this is an emergency. Matma Rex (talk) 20:33, 2 March 2026 (UTC)

Are you sure? I'm afraid we do not do this in time, and people will start get failures, and we even do not know this. As for now one page refresh needs many requests for the watchlists retrieving (I think it's until 1000 answers in API, but not sure), so it's until 20 calls per site. I have about 40 sites in mine, it's 800. On mobile or tablet (which are most of the users), changing browser tab forth and back even for a second needs to call everything again. It can easily be 8000 in hour for me at least once a week, and I never use live updates. I can write the change now and we will decide if and when to deploy it, but we have know tools to know if the users get failures or not. And if they do, they will leave the extension and never come back, probably. Of course, at least 80% of users outside Live updates mode will never hit the limits, but the extension should work for everyone. I do not see one user with Live updates that does not hit the limits, actually. IKhitron (talk) 20:43, 2 March 2026 (UTC)

I just played with Special:GlobalWaitchlist a little. I only see it make one API query per site... why would it make more? That probably could be fixed.

If it makes only one API request per site, and the live updates are slowed down a bit (maybe one per minute?) there is probably no problem. At least not for people with fewer than 80 sites on their list. DKinzler (WMF) (talk) 21:16, 2 March 2026 (UTC)

...oh I see, it's paging through the results. Is that really needed? I'm a bit confused about what it's doing. DKinzler (WMF) (talk) 21:18, 2 March 2026 (UTC)

OK, here is the approximated list, @DKinzler (WMF). I can be wrong in details. Number per site (and somebody asked me last week about adding 1065 sites, the entire Wikimedia).

1. A call for each wllimit=max entries in Action API, because it can return a continue parameter after every 500 entries.
2. A call for every 50 elements in Wikibase site.
3. A call for every EntitySchema element.
4. User can click "unwatch/rewatch a page", API call for each click, two for the fast mode.
5. User can click "mark page as seen", API call for each click.
6. User can click "mark site as seen" or "mark all as seen". Until now it was one call for each click. But now there are Watchlist Labels, so to mark all pages in a specific label we should make an API call for each page. I hope that phab:T417357 will be resolved, and it will be one call again, but until then it can take time, and even then there will be a watchlist with pages that do not have any label assigned.

IKhitron (talk) 21:30, 2 March 2026 (UTC)

I'm not really sure, it depends on how many is "a few" thousand, but even in the worst case, you'll just have to take a 1 hour break from your global watchlist.

I agree though that we should have better tools to know how often this happens, and not just rely on users to report it. On the GlobalWatchlist side, you could log API errors with mw.errorLogger.logError (examples), which goes to Logstash on our sites. Maybe the rate limiting service itself could also provide some debugging information, but I don't know enough to say how that should look. Matma Rex (talk) 21:30, 2 March 2026 (UTC)

Can you explain why just not to create an internal API point and forget about this? Fortunately, I know how to do this, I created one a month ago for a first version of local time change. I think it's better than the user will see problems. What are the cons? IKhitron (talk) 21:33, 2 March 2026 (UTC)

I'm not against it, but it adds complexity. Matma Rex (talk) 23:05, 2 March 2026 (UTC)

In this case, we can consider a third option, beyond doing it and not doing it. It is "doing it so for sure there will be no failures and removing it in a couple of months", for example, if the loggers you mentioned say it's redundant. IKhitron (talk) 23:11, 2 March 2026 (UTC)

A couple of things I thought about after the night.

1. Maybe it looks like I want to do this. So I really don't. But even more I do not want to happen even once for one user a failure because of limits, so I do not see any choice.
2. If we do not do this, is there even a way to get a logger for the JavaScript side? As far as I know, the php side can send logs so we can read them, but the JavaScript sends them to the console. Couldn't find anything here.
3. While I'm waiting for your answer, I'm starting to work, aiming on the third option, add, check and maybe remove. In the case we do not do this, I just worked for nothing. Better than losing time and being unprepared if we do do this.

Thank you. IKhitron (talk) 07:27, 3 March 2026 (UTC)

1. It's a nice goal, but "zero errors" is often not possible to achieve, especially if the errors are caused by something outside of your control, like here. Especially when you're doing this in your free time, you shouldn't feel obligated to cover for WMF suddenly introducing new limitations. Ideally we won't cause any problems, but if we do, it's our fault and not yours, and even if GlobalWatchlist is temporarily degraded, the sky won't fall.
2. You can use mw.errorLogger.logError (examples), which goes to Logstash on our sites. You may be able to get access to it (see Logstash#Authentication), but if not, I could query it for what you need and share whatever can be shared publicly. Also, we're now working on T418957 Add client-side logging for non-MediaWiki action API errors (HTTP 429), so it shouldn't be necessary to add the logging separately in GlobalWatchlist.

Matma Rex (talk) 00:03, 4 March 2026 (UTC)

1. Not zero errors, but "not increasing errors". The "GlobalWatchlist is temporarily degraded" is not a problem for me, the problem is "and as a result users escape to Special:Watchlist and do not come back".
2. So, you think, right now, that reducing the speed to one in a minute and using the js Logstash is better than temporarily moving to API point and using the php Logstash? I'm doing as you decide, not because I feel obligated you, but because I trust you, so I'd like to hear this. And also, what will be with label marking and EntitySchema, they can finish the hour quota for Live updates users. I can wait with EntitySchema, even if I don't want to, but I really want to insert labels in production as soon as possible.

Thank you.
UPD: I worked some time, did most the logic. But couldn't find anything like ForeignAPI on php, only getHttpRequestFactory. But when I talked about this, assuming (maybe being wrong) such a simple thing already exists, nobody fixed me. Am I missing something? Thanks. IKhitron (talk) 09:35, 4 March 2026 (UTC)

That simple thing unfortunately doesn't exist, since need for it is rare.

Note that we are currently discussing ways to avoid breaking power-user tools that rely on high numbers of API requests. You will not have to make changes to the extension by next week. Re-thinking how it works would be good in the long run, but it looks like we will adjust the limits that we apply next week to be higher than we originally planned, at least for power users. The current idea is to only apply the stricter limits to "newbie" users, to prevent scrapers from just creating accounts to get the high limits. This is however still under discussion. DKinzler (WMF) (talk) 12:18, 4 March 2026 (UTC)

Thanks, sounds great. IKhitron (talk) 12:20, 4 March 2026 (UTC)

Well, there is a new data: mw:Talk:Wikimedia APIs/Rate limits#The Global Watchlist. Now I can except the changing the live updates rate to a minute, it makes sence noe. Add an internal limit to prevent internal refresh after less then a minute, maybe. But it isn't enough, because sometimes anybody can add hundreds of wikis to the settings. Or 1065, like I told you once about somebody spoke to me. And the rate limits are for all requests of the user, not just one special page. Maybe there is a need to return the maximal wikis count for Wikimedia, and set it to something like 75. What do you think? Of course, none of all this will be applied to the 3.5 phases project I'm continue to work on. Thank you. IKhitron (talk) 22:27, 24 April 2026 (UTC)

UPD: Suddenly, sometimes in May was changed to April 30, 1:00. So, we need to do this until this Monday evening. I've wrote this, hoping you'll have time. Thank you. IKhitron (talk) 12:47, 25 April 2026 (UTC)

Thanks for staying on top of this. Matma Rex (talk) 15:17, 25 April 2026 (UTC)

Sure. Thank you for approving it so fast. I was really affraid you will not see it in time. You disappeared for two weeks, and I wasn't worried, because of the weekend event, I expected you to be back sometimes in the middle of the next week, but it would be too late for this. So I'm glad it achieved your attention. Hope we'll talk about the rest of this issue when you'll have time. IKhitron (talk) 15:38, 25 April 2026 (UTC)

EntitySchema

Hi. Hope you know what to do, with your long time experience in MediaWiki developing. While I'm waiting when you will have some time to answer on the API rate problem above towards April and to check the labels Gerrit change, I'm continuing the routine missions. One of them is to check the already merged changes. Tuesday morning is the time for testwiki train update, so I've checked as always. The RTL change works, but the EntitySchema doesn't. Nothing happens, nothing on console. Nothing at phab:T420479. The Wikibase labels work as usual. And the new change does work fine on Beta Cluster. What do you want me to do? Maybe there is a chance that the version brunch was cut earlier? But both changes appear at mw:MediaWiki 1.46/wmf.21/Changelog#GlobalWatchlist. Don't know how to debug this, especially because as far as I understand, Beta Cluster and production should work the same. Hope you can give some advice. Thank you in advance.
UPD: Now I had an idea. I found an EntitySchema page on Wikidata in the Recent Changes and added to my Watchlist. This page works on testwiki. Now I don't even know what to think. IKhitron (talk) 09:55, 24 March 2026 (UTC)

@IKhitron It works for me on test.wikipedia.org, since that wiki is already on wmf.21: [8], but not yet here on meta.wikimedia.org, since this wiki is still on wmf.20: [9]. I think everything is working as expected. Matma Rex (talk) 17:37, 24 March 2026 (UTC)

Maybe I didn't explain well, sorry, I'll try again. I added an edit on EntitySchema element to test.wikidata.org, and another one to www.wikidata.org. I opened the special page on test.wikipedia.org that have both these sites in the settings. The first edit appears as a regular page, the second one as expected. IKhitron (talk) 17:47, 24 March 2026 (UTC)

Okay, interesting, I could reproduce with https://test.wikidata.org/wiki/EntitySchema:E27 on my watchlist. I think I see why this happens.

I started debugging by looking with the browser dev tools "Network" tab, and I noticed that GlobalWatchlist was not making any requests like https://test.wikidata.org/w/api.php?action=wbsearchentities, which have to be made to look up those labels. I started placing some breakpoints and stepping through them, and I think the bug is here: https://gerrit.wikimedia.org/g/mediawiki/extensions/GlobalWatchlist/+/5877f317fedcd462213011032a7ee7cf0c7ba8ca/modules/specialglobalwatchlist/WikibaseHandler.js#245 – if there are no "normal" Wikibase items to show, we return early, but because of that we never make the requests to fetch EntitySchema item labels.

In other words, if the only Wikidata entries shown are EntitySchema items, we don't fetch their labels. Otherwise we fetch the labels correctly. This probably almost never happens unless you're specifically testing this :D

What we need to do is skip the that.getRawLabels( entityIds ) call, but then continue running the code inside the then( ( rawLabels ) => { ... } ). Matma Rex (talk) 18:24, 24 March 2026 (UTC)

I see. Thanks a lot, I'll reproduce it on Patch Demo and fix it. But the question is the same. Is this OK that the fix change will be a week later? I think it is, because until now there were no labels, and from now there are some labels, which is better, but not good enough. And I should not announce it on Tech News until everything works. But I prefer to do this all only if you agree, of course. IKhitron (talk) 18:31, 24 March 2026 (UTC)

Yes, this seems like a tiny bug fix, it can go out later. Matma Rex (talk) 20:17, 24 March 2026 (UTC)

Great, will do. Thanks a lot for all your help. Didn't think you'll try to debug it by yourself, otherwise I would ask you not to do this, so you'll not waste precious time, but you helped a lot when you did. IKhitron (talk) 20:20, 24 March 2026 (UTC)

Done. IKhitron (talk) 12:48, 25 March 2026 (UTC)

Thank you very much again. I really appreciate you could find time for this. In fact, I have much more ready changes, but I'm holding with opening them to review until you will be able to find some time one day for these two issues I mentioned above, so they will not disturb you. IKhitron (talk) 21:05, 25 March 2026 (UTC)

Hi again. I really wanted not to disturb you until you find some time for the labels change. It's ready for month and a half, and I have a lot to do on phase two and can't, because it depends on your review of this change. But I have no choice, because turns out that the EntitySchema task is still not done, alas. It's not on 50% like the last time, more like 97%, but still. Looks like the replacement is not done on faster browsers on the first Special page load. It works fine on every internal refresh, and sometimes works on the first load, but not always. For example, I tried again the testwiki version today, and it works fine for the Wikidata, but sometimes works on the first load for testwikidata, and sometimes it doesn't. Breakpoints show that when it doesn't, the empty bdi element does not appear on the page yet, meaning, the webpage is not constructed enough. I can see three major solutions. The first is to give up on the multiple replace of all the elements to save time, and replace only the current one, so we should not use the jQuery selector to get it, we already have it in a runtime variable. The second one is to add a MutationObserver to wait for the element to appear. The third one is to make two replacements, instead of one, both with the selector and the variable (in opposite order, so the variable could still be empty). I prefer the third one. My reasons are these: the second solution looks like an overkill, and the third one just better than the first one. What do you think? Thank you. IKhitron (talk) 11:47, 31 March 2026 (UTC)

I'd prefer option 1, it sounds like what I originally suggested in my comment at [10], if you manage to resolve the issues with it you ran into in that comment thread. Option 3 sounds alright too. Please don't do option 2, this code is already complex. Matma Rex (talk) 20:54, 31 March 2026 (UTC)

So, why 1 for you is better than 3, what's your reason? About "manage" I'm not so sure I can check it in 100% before the deployment on a big enough wikifarm like Mediawiki, otherwise I would catch this much earlier, on Patch Demo or on Beta Cluster. IKhitron (talk) 21:01, 31 March 2026 (UTC)

The reason is that it's simpler to do one thing than to do two things, so it's easier for me to understand the code. Matma Rex (talk) 21:05, 31 March 2026 (UTC)

OK, it's your choice, of course, will do. Thank you again for your help. IKhitron (talk) 21:12, 31 March 2026 (UTC)

Done. It was harder that I thought, and as a result of this it made me a problem. I'm working slowly for months on the code improvement, and the new version may or may not cope with this change. So I'll work on it in the future, trying to resolve, and maybe there will be a need to consider again the choice between the three solutions above, we'll see. It does not change anything now, just to tell you there is a chance this issue will pop up again in the future. Thank you. IKhitron (talk) 14:30, 1 April 2026 (UTC)

A hypothetical question

Hi. As I my planning my big project, there is a question popped. I hope you can answer, you know a lot about this stuff. Is this possible to create a new system variable, wgNewvar, such that: 1) It will be false by default, and as such, every new extension installation will read it as false if not set explicitly otherwise, but 2) In every existing extension installation it will be set to true, explicitly or implicitly, to preserve the current state, forever or until it will be explicitly changed? I have a strategy what to do if it is possible and if it isn't, but I need to know which one to use. The "yes" answer will make it much easier. Thank you in advance. IKhitron (talk) 07:36, 10 April 2026 (UTC)

I don't think that's possible. Maybe if your extension had some database tables, then you could introduce a schema change in the new version to distinguish them. Otherwise I'd just add a new variable defaulting to true, and document that it has to be configured in installation instructions. Matma Rex (talk) 15:15, 25 April 2026 (UTC)

I see. Thank you for the explanation. I'll continue to work according to this. IKhitron (talk) 15:40, 25 April 2026 (UTC)