Deployed and tested, see https://wikidata.beta.wmflabs.org/wiki/Q526807?uselang=en

I think there should be some sort of criteria for evaluating what is a good split. Neither extreme is good: One file gets too large and translators cannot focus, but on the other hand too many files makes it harder for developers to add/update messages as they need to be aware of all of the available groups.

Immediate ideas about groups to divide:

• log messages
• language converter
• namespace messages (nstab, etc.)
• user rights (action-, right-)
• ignored messages

enwiki should be done besides T393237.

Ah thanks!

Anything left to do here

Stage 2 still has to run on s1, but that should take less than a day (I'll do it after stage 1 of T381599 is finished on s1).

Is it finally done in s1/s8?

Mentioned in SAL (#wikimedia-operations) [2025-04-30T00:05:39Z] <zabe@deploy1003> Finished scap sync-world: Backport for [[gerrit:1139577|enwiki and commons: Increase revision-slots cache expiry again (T183490)]] (duration: 13m 45s)

Mentioned in SAL (#wikimedia-operations) [2025-04-29T23:58:43Z] <zabe@deploy1003> zabe: Backport for [[gerrit:1139577|enwiki and commons: Increase revision-slots cache expiry again (T183490)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-04-29T23:51:53Z] <zabe@deploy1003> Started scap sync-world: Backport for [[gerrit:1139577|enwiki and commons: Increase revision-slots cache expiry again (T183490)]]

Change #1139577 merged by jenkins-bot:

[operations/mediawiki-config@master] enwiki and commons: Increase revision-slots cache expiry again

https://gerrit.wikimedia.org/r/1139577

Change #1139577 had a related patch set uploaded (by Zabe; author: Zabe):

[operations/mediawiki-config@master] enwiki and commons: Increase revision-slots cache expiry again

https://gerrit.wikimedia.org/r/1139577

Change #1112092 abandoned by C. Scott Ananian:

[mediawiki/core@master] Return status of T2529 hack down preprocessing chain

Reason:

abandoned in favor of an alternate approach

https://gerrit.wikimedia.org/r/1112092

Change #1133212 merged by jenkins-bot:

[mediawiki/extensions/GlobalBlocking@REL1_43] Maintenance: Add script to globally (un)block

https://gerrit.wikimedia.org/r/1133212

Change #1133212 had a related patch set uploaded (by Reedy; author: Tks4Fish):

[mediawiki/extensions/GlobalBlocking@REL1_43] Maintenance: Add script to globally (un)block

https://gerrit.wikimedia.org/r/1133212

Given that, I think we can resolve this task as:

1. The code causing these extra actor rows has been fixed in e209ae5a07cade91fb7a1d5320e9e6c6a8168bc9
2. No more of these rows appear to exist elsewhere

In T385734#10700705, @Ladsgroup wrote:

I wrote this horrible thing to get rid of the rows:

for i in $(seq 1 410);
do
   id=$(db-mysql db1223 testwiki -ss -e "select actor_id from actor where actor_user not in (select user_id from user) limit 1;")
   if [ "${id:0:1}" == "1" ]; then
       db-mysql db1223 testwiki -ss -e "delete from actor where actor_id = $id limit 1;"
       echo $id
   fi
   sleep 1
done

It's empty now:

[email protected][testwiki]> select * from actor where actor_user not in (select user_id from user);
Empty set (0.144 sec)

Anything else needed from your friendly neighborhood DBAs?

I don't think so. Thanks for that!

I wrote this horrible thing to get rid of the rows:

for i in $(seq 1 410);
do
   id=$(db-mysql db1223 testwiki -ss -e "select actor_id from actor where actor_user not in (select user_id from user) limit 1;")
   if [ "${id:0:1}" == "1" ]; then
       db-mysql db1223 testwiki -ss -e "delete from actor where actor_id = $id limit 1;"
       echo $id
   fi
   sleep 1
done

Change #1117573 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] WikiPageUpdaterTest: Use StatsFactory::newUnitTestingHelper()

https://gerrit.wikimedia.org/r/1117573