This is reproducible from https://en.wikipedia.org/w/api.php?action=query&list=allusers&formatversion=2&auactiveusers=1&aulimit=max.

I think we should just remove override list as it's feature creep. It's not used for any kind of election as far as I know. Once it's gone, "Eligibility list" and "Exclusion list" would be fine labels (when complemented with a helptip).

SDZeroBot ran into this error 3 times today. The emails were in fact received according to the end-user. However, self-cc mails were not received and the bot got php-mail-error code from the API.

Also, most identity platforms allow configuring multiple callback URLs.

I'd suggest changing "consumer"/"client" to be consistently be "client". OAuth 2 is the present and the future. We shouldn't worry about the OAuth 1 terminology.

In T315893#12149445, @stjn wrote:

It’s very easy to mischaracterise the opposition as being about ‘change aversion’ when the problem is that DiscussionTools developers imposed a poorly thought out change by their privileged access on a subset of the pages and the action views and now you guys refuse to reconsider its impact or to consult with the community about it.

probably no need of the "Types of grants being requested" radiobox (why would one an owner-only authonly or authonlyprivate consumer?)

Came up with a quick (but working) patch for this. Happy to abandon if Platform team would prefer to work on this instead!

In T315893#12127566, @Esanders wrote:

Given the lack of requests for translating the separator I don't think that is a priority for now, and while our APIs are mostly tolerant of additional whitespace, they would not handle different separators so it would be a vastly more complicated undertaking and beyond the scope of this task.

In T315893#12126870, @DLynch wrote:

It's more complicated than just making it a per-wiki setting, but it reacting based on the current user's chosen language is what stjn and I were talking about with that colon-separator patch earlier today. Because of the mentioned issues with colon-separator we'd probably want to make a new message specifically for this purpose instead, but the patch already shows what would need to be done for that.

I too get this sometimes (but for notifications instead of alerts).

These properties now appear in Level 4 Working Draft (https://www.w3.org/TR/css-backgrounds-4/#background-position-longhands).

Minimum browser versions required for new features:

If we are doing this, we should just expose it to all users. I don't get what's so private about gadget preferences and beta feature opt-ins. Everyone can already see what user scripts someone is using. If anything, it'll improve transparency.

All done from the above list. It actually does work without making text changes if the page content model was correct and we want to set the revision content model to match that, but not the other way round.

In T413944#11514491, @Pppery wrote:

My guess is that someone who has editcontentmodel access on the wiki might be able to fix this by trying to make an edit through the API with an explicit content model parameter of wikitext. At one point that worked, although later refactoring may have broken it.

In T31398#12056577, @MusikAnimal wrote:

How hard would it be to make this use CommunityConfiguration? It's basically a tailored JSON editor just like all the other CC modules, so it's almost odd for it not to be in CC.

I do think Gadgets should not hard-depend on CommunityConfiguration, though. For tests, you can skip on the file level (outside the class structure) if the test class uses a trait that lives in CC.

I would suggest keeping it to Safari 12/iOS 12. Raising the requirements all the way to Safari 16.4/iOS 16.4 seems a bit drastic as the only feature we gain from them is regexp lookbehinds, which isn't particularly interesting.

In the middle of a complex module, you don't always know the data type of a variable. Logging it is one way to check its type, but if the logger fails with a cryptic error message, it isn't helpful.

From https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1107096:

Assuming this would involve a Vue frontend invoking a backend API, I'd suggest making the APIs stable (not internal). That would enable setting up deployment pipelines for modules and gadgets triggered directly within GitLab CI.

In T425752#11987649, @tstarling wrote:

Each deployment has a set of packages. Saving [[MediaWiki:Packages.json]] creates one new deployment. Creating a deployment requires the creation of one produnto_package_deployment row per deployed package. That's just the way the 1:N relationship is stored. I don't think it's a problem that needs to be solved. It's only 8 bytes per row.

For the record, the primary fix was to remove use of an expensive template in securepoll-voter-name-local message.

I think we could do this for importScript and importStylesheet, removing the need to track relations via wikitext comments. SyntaxHighlight can also be adjusted to make the importScript arg a clickable link similar to how we do it for Lua require().

Weird. Why does GadgetDefinitionContentHandler::fillParserOutput get called at all for invalid content?

Hi @aranyap, similar to T402145, could you review and approve this one too?

The table doesn't have any user identifiers, so I don't see a way.

It's because of style="border:none; background:transparent;" applied locally on the <syntaxhighlight> tag.

I think I've been noticing this for a longer time. Noticed it with https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1222740 today (which was a child of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1222739). PS12 was marked as having a merge conflict. There weren't actually any conflicts. Gerrit itself recognized PS13 as a rebase-only change.

In T386436#11994855, @stjn wrote:

Ah, it doesn’t support cases like https://ru.wikipedia.org/wiki/Модуль:Вложенный_список#L-10 or https://ru.wikipedia.org/wiki/Модуль:NumberOf#L-376 which is why I thought it’s not currently implemented. Apologies.

Ideally I think we would use global: 'update' flag in the actions=options request and avoid action=globalpreferences altogether. But that also seems buggy as setting the option to the default value removes the global preference, activating the local preference which may not necessarily be set to the default.

I've seen this happen too. In my case, it was somehow disabled in GlobalPreferences. Enabling it from the toolbar button doesn't stick.

PopulateVoterListJob was removed altogether in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SecurePoll/+/1164696 / T397565.

This feature was removed altogether in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SecurePoll/+/1164696 / T397565.

In https://gerrit.wikimedia.org/r/c/operations/puppet/+/1298329/comments/9648a202_f275769a, @Ladsgroup wrote:

I'd also would need a sign off from the privacy team

(I forgot I had already created a task for this!)

In T423547#11923739, @jrbs wrote:

Unfortunately I can't seem to use the file with importGlobalVoterList.php because it's too big for k8s (I think that's what this means):

In T425752#11961758, @tstarling wrote:

The repo viewer only shows deployed versions, and deploying is a privileged action, done by editing [[MediaWiki:Packages.json]].

We should also think about what happens when someone spams or posts libel on a gitlab repo. An onwiki admin should be able to make it go away, ideally with no knowledge of using gitlab. See also: https://en.wikipedia.org/wiki/User:Risker/Risker%27s_checklist_for_content-creation_extensions

Many of these can be deleted following T423547.

For User:Ambouzella, the nodejs script saw 297 edits. PHP saw 297 + 3 flow edits, getting them to the 300 mark. I suspect the same is the case for most of the users in the first list.

Okay. So Aka_sektor does indeed have 88 Flow edits:

In T423547#11910004, @jrbs wrote:

Thanks @SD0001 - only two errors in the file:

2026-05-07 22:13:04.530 ERROR: [s5] [urwikisource] Error while connecting: Access denied for user 's56852'@'%' to database 'urwikisource_p'
2026-05-07 22:13:04.531 ERROR: [s5] [urwikisource] Failed: Access denied for user 's56852'@'%' to database 'urwikisource_p'

@jrbs You can use sudo su - to become root, which avoids linux file mode issues.

In T413462#11489613, @Tacsipacsi wrote:

The problem with this is that, unlike the migration of SyntaxHighlight from GeSHi to Pygments, there is no “new” and “old” implementation: an interface allows multiple implementations to co-exist, so extension A should be “backward-compatible” (I quote this because it’s not really backward due to the lack of “new” and “old”) with extension B, but at the same time extension B should also be “backward-compatible” with extension A.

Grant Joe access to voterlists.wmcloud.org shell