eswiktionary finished migrating a bit more than a week ago.

renamed your wikitech account, can you try attaching it to your global account now?

This is T378289: SUL accounts with unattached Wikitech accounts auto-creating unattached accounts on other wikis.

In T213295#10299616, @Marostegui wrote:

In T213295#10299543, @Zabe wrote:

In T213295#10299168, @Marostegui wrote:

In T213295#10156934, @Zabe wrote:

Partialy resolved by closing the wiki.
It was decided anyway that wikis wont be deleted anymore.

Was it actually closed? I still see it on s4.dblist

Yes. Closing a wiki basically just means locking a wiki from edits or any other write operations for anyone besides stewards, sysadmins, global interface editors and staff. It does not delete anything from the db.

I am aware of those implications

Closing a wiki has no real advantage from a technical perspective, we are mostly doing it when wikis have no longer anything happening on them besides vandalism in order to reduce the workload of fighting that vandalism.

I don't know what is the exact procedure but I would have expected it to go to closed.dblist. For us (DBAs) it does make a difference, because if it keeps showing in up s4.dblist it means we still have to do maintenance on it (mostly schema changes) whereas if it is on closed dblist we don't have to.

In T213295#10299168, @Marostegui wrote:

In T213295#10156934, @Zabe wrote:

Partialy resolved by closing the wiki.
It was decided anyway that wikis wont be deleted anymore.

Was it actually closed? I still see it on s4.dblist

In T376749#10287086, @Urbanecm_WMF wrote:

In T376749#10286228, @Zabe wrote:

For information about future phases, please see: Flow Deprecation Timeline

This information is not accessible for anyone not at the WMF (btw thats the majority of people in the wikimedia movement). Could you make it more accessible please?

Thank you for the note, @Zabe. The information from that link is already public, but the description (somewhat unhelpfully) only links the private spreadsheet. You can find the deprecation timeline outlined at
https://www.mediawiki.org/wiki/Structured_Discussions/Deprecation#Deprecation_timeline.

In addition to the timeline, the spreadsheet also includes Flow usage data (which were used to decide which wikis belong to phase 0, which got migrated as part of this task). The usage data were compiled in T352174 and published under https://people.wikimedia.org/~urbanecm/growth-team/T352174_flow_per_day_per_page_20231206.html.

Hope this helps!

In T299387#8938230, @Ladsgroup wrote:

[...]
I ran the moveToExternal.php on any wiki that had stubs and now only these are left with unresolved stubs:

arwiki
commonswiki
dewiki
enwiki
enwikibooks
eswiki
frwiki
itwiki
nlwiki
plwiki

I guess @tstarling would like to take at that (I'm focused on finishing legacy encoding instead)

For information about future phases, please see: Flow Deprecation Timeline

I am not completely sure what you are trying to show. The effect is known and by design. If you want the design to change, feel free to make suggestions at T138145.

Wiki is live

wiki has been created

CentralAuth shows the date of the creation of the global account. That is the case for everyone, you will find no account where it shows a date older than 2008. This is by design.

Wiki is live

wiki has been created

You already uploaded the file yourself through video2commons: https://commons.wikimedia.org/wiki/File:TNE_97_TERFDom,_Roman_Salutes_and_Red_Flags.webm

scap got rolled back to a non-broken version: https://sal.toolforge.org/log/-KWmQpIBFk7ipym_zJBT

In T45646#10187162, @hashar wrote:

The copyright message has been removed from languages/i18n/qqq.json by the localization updates in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1076561/2/languages/i18n/qqq.json . That got force merged since the banana checker failed with:

Running "banana:core" (banana) task
>> 1 message lacks documentation in qqq.json:
>> * copyright

The copyright message is deprecated by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1075597 and replaced by copyright-footer, history_copyright and copyright-footer-history. I guess the qqq message should have been kept.

In T363538#10143084, @Bugreporter wrote:

Note: after moswiki is created, cleanupTitles should be run in wikis still have MOS: pages in main namespace (the second list of T363538#10123348) so that such pages can be recovered.

wiki has been created

In T374641#10142621, @Ladsgroup wrote:

I'll be traveling next week. If @Zabe doesn't beat me to it, I'll finish it.

wiki has been created

wiki has been created

wiki has been created

wiki has been created

Partialy resolved by closing the wiki.
It was decided anyway that wikis wont be deleted anymore.

The migration fully finished on mediawikiwiki.

running on group0 now

ok. we are getting a few Failed to load data blob from Unable to fetch blob at tt:37634. Use findBadBlobs.php to remedy. for revision 38113. If this problem persist, use the findBadBlobs maintenance script to investigate the issue and mark bad blobs. on test2wiki (e.g. 8097e557-8104-41da-84b9-1e2572987e49). But we also have:

In T183490#10137898, @Ciencia_Al_Poder wrote:

Since MCR is part of core and ExternalStorage is part of core (T362566), why was the migration script created on the WikimediaMaintenance extension instead of being in core?

In T373668#10120652, @Zabe wrote:

tbh I would just mark them as bad on beta cluster.

I think the https://wikitech.wikimedia.org/wiki/SRE/Clinic_Duty/Access_requests#Modify_LDAP_groups section should also be updated.

Sure, can do that.

Should be easy to fix

tbh I would just mark them as bad on beta cluster.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1026933

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1017374

I think running

UPDATE content SET content_address = CONCAT('es:', content_address) WHERE content_address LIKE 'DB%';

should fix the issue.

Its not caching. You missed to add the es: prefix.

Likely the same as T373668.

So yeah. There are apparently fully duped rows in the content table (besides the autoincrement id) which is not supposed to happen in MCR but still is the case.

Ok. There are now some revisions which are broken. Sadly its quite a few, but on the other hand it at least is less than 1% or so. The reasons moves are broken is because the latest revision of https://test.wikipedia.org/wiki/Template:Redirect_template is broken, which is it tries to load. But it is only a random symptom and not interesting in itself.

updated the old vector logo

In T368712#10094845, @Wargo wrote:

Favicon not generated.