You don't need permission from anyone here to create a developer account. Go to https://idm.wikimedia.org/signup

Please try to file these tickets further in advance of the event; deploys of this sort are unlikely to get done on the weekends and the first available backport window at https://wikitech.wikimedia.org/wiki/Deployments isn't until two-three hours into the event.

Also are self-redirects a common-enough problems to bother with a special page? My inclination is no.

This is deep into https://en.wikipedia.org/wiki/Garbage_in,_garbage_out territory and doesn't need to be handled specially IMO; if the wiki is in an invalid state then you get invalid output.

Also note that there are no deploys between now and June 8, so this is unlikely to get done (at least for the June 8 event). You have "event coordinator" rights on your account, which should let you create accounts for participants while logged in regardless of the rate limit.

https://de.wikipedia.org/w/index.php?oldid=4609030&title=Diskussion:Hexe still reproduces for me.

I would be inclined to close this as a duplicate of T384167

Oh, and, in case it's useful, here's another example of everything put together:

It seems to have been marked as active since May 2 for me.

This is the fault of the website - if I disable JavaScript and load the website that genuinely is its title. Perhaps reFill (or Zotero, or Citoid) could filer out the garbage input and not GIGO it, though.

Sorry, I forgot Phabricator ate characters at the end of links. The URL I meant to post was https://pt.wikibooks.org/wiki/Especial:Todas_as_p%C3%A1ginas/Thread%3A (a list of all pages in the LQT thread namespace). And it seems that mistake has led you pretty far astray, sorry

LPL Essential (LPL Essential 2025 Apr-Jun: CX) is a milestone of LPL Essential so a task can't be in both. It's a bug in phaultfinder that it can't find tasks in a milestone of the project that they should be in.

• securepoll_cookie_match is used on the vote details page to display the securepoll-cookie-dup-list message. Do the scrutineers actually rely on this?
• securepoll_msgs is used for translation of vote options. That entire system could probably be rewritten to read from a wiki page instead.
• securepoll_questions is where the actual questions voters see are stored, which is probably needed and I can't think of anywhere to merge it.

I ran into repeated import timeouts when running https://www.mediawiki.org/wiki/User:Flow_cleanup_bot. But I was importing pages even larger than that, and found about 40MB to be the sweet spot when importing things there - any larger would end up failing.

See https://www.mediawiki.org/wiki/Gerrit/Tutorial for how to properly submit patches for review.

Per https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_220#My_question:_WHYYYYYYY%3F%3F%3F, it seems like the source of this rule is in the WikimediaMessages dark mode CSS, not local code.

First off, any LQT page that isn't any flavor of archive can probably safely be converted to Flow and archived using the convertLqtPageOnLocalWiki.php script. This means it somehow escaped all of the mess without ever being touched.

Here's an example of what I was trying to refer to:

It's referring to the standard process of importing from oldwikisource.

https://commons.wikimedia.org/wiki/File:Can_Couples_Find_Perfect_Places_In_Aberdeen-_-_S11_Ep6_-_Full_Episode_-_Location,_Location,_Location.webm seems to have uploaded successfully anyway.

every wiki has its own localized name

I would think the discussion should have been formally closed before filing here.

If by frozen you mean https://github.com/wikimedia/operations-mediawiki-config/blob/bb48e35598c79ef5dc0524973c9d3ac35336f604/wmf-config/liquidthreads.php#L6 then the script would do nothing because the way freezing is implemented is by forcibly making all LQT pages not actually LQT (wgLiquidThreadsAllowUserControl = false disables the useliquidthreads parser function).

Yes it is.

That looks like a separate task; this is LiquidThreads, that is FlaggedRevs

My guess is that it counts as more than 90 days old because it was originally created in draftspace more than 90 days ago.

This is caused by https://www.mediawiki.org/wiki/Help:Extension:Kartographer#Groups_for_Wikivoyage not being supported on incubator.

Anything left to do here?

How about on changing the error message to include the first arg:

Related to the Collection book renderer functionality which no longer exists.

This is (IMO) not a duplicate of T379460: MediaWiki\Api\ApiUsageException: ⧼abusefilter-warning-filter-48⧽.

I think of the "merge-target" and "merge" logs as the same log entry displayed in two different ways, not two different log entries.

There's a real software change that would be done if there were infinite resources to do things: only show "merge-target" logs when viewing the logs for a specific page, and not the logs for a specific user (or all logs). That should be tracked on Phabricator somewhere, even though I don't plan to code it and don't expect anyone else to.

The move bug is probably completely unrelated to the histmerge bug and should be split to a different task.