@RoyZuo would appreciate, if you could test this next week btw. I think this is what you wanted, but it would be good to get confirmation that it works as desired.

Reached out to the users:
https://commons.wikimedia.org/wiki/User_talk:Schlurcher#SDC_added_by_UploadWizard
https://commons.wikimedia.org/wiki/User_talk:Rkieferbaum#SDC_added_by_UploadWizard

I can use formatMetadata class of the TimedMediaHandler to essentially get the data from the substructure of metadata that we extract with id3 etc. It works quite well to simply display data (instead of reordering and storing as top level metadata inside the metadata structure. It is dependent on the stored data remaining somewhat consistent for versions of the metadatareaders, but i think thats ok.

subtitles requires CORS, so setting crossorigin=anonymous attribute might fix that.

In T259141#12293126, @IKhitron wrote:

I was going to create a new task about removing the printable mode link from a special page that has nothing to print. I believe there is no need for this now, it will be removed anyway?

I notices some test cases are failing with:

Why we are seeing (more of) this now on Special:UploadStash is due to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1326448 which changed how Special:UploadStash in particular works.

In T129433#12399094, @CDekock-WMF wrote:

Unfortunately we are not in a position to make any more art or resize existing art for this task

ping @Ladsgroup and @Zabe making sure this is on your radar.

Interruptions that require editing information can occur for a multitude of reasons:

• Abusefilter
• Spamblacklist
• Title blacklist
• Captcha
• SDC failure

Of these only Captcha is reasonably handled honestly (its relatively new)

@Soda do you know if the uploaders of these files were ever informed ?

Do we have any of the tool/bot devs that have implemented these SDC props before ? A review by them might be useful as they know what to pay attention to in this area.

How about we lift that progress section (bar + count) to above the buttons? Makes more logical sense to me. Maybe hide it using visibility, so that we don't have a layout jump ?

In T187844#12387802, @Amdrel wrote:

The following Gerrit topic has all of the patches: https://gerrit.wikimedia.org/r/q/topic:%22T187844%22

Hmm. wondering if we should also remove the old file rotation logic and the filereader fallback and just fallback to thumbnails that are serverside rendered...
That basically means that a certain lineage of browsers around 2019-2021, would no longer get thumbnails before the upload stage, but it does simplify the code for these, which now each have 2 fallbacks.

Took quite some effort to figure out how to better identify these to assess the scope and i'm still not 100% sure this is a correct query, but

In T439616#12377726, @Bawolff wrote:

SHA1 is broken, so that isn't impossible, although it does seem unlikely in context.

Ran some AI analyses. This file revisions have the same sha1, which shouldn't be possible.

This is fixed, but I think CargoUtils in general needs a rewrite to make use of the new database domain concept, which provides exactly the functionality that Cargo was attempting to implement.

The root cause of this issue (however the error might be handled) might be due to 561753416ca3, by @aaron where a fallback path was dropped:

This speciesbox emits a lot of linebreaks for table rows that are not used. (incorrect if conditions in the template i presume). As use mdy dates does substitution magic on the page content, I suspect that has something to do with it.

Right. So the claim is that there is an issue with aiohttp TLS1.3 support in combination with AWS firewall.

I mean.. we could try lowering the amount of elements on that page, but i wouldn't be surprised if it were just one or two uploads causing this either.

I think the question is, do we change the html of the frameless mode of Kartographer to emulate the frameless mode of mw:File media ?

Fallout from T414338: [Hypothesis] WE5.4.12: Identify the provenance of image requests (FY25-26)

This seems like fallout from T414338: [Hypothesis] WE5.4.12: Identify the provenance of image requests (FY25-26)

In T436072#12330131, @etz wrote:

Architecture Note: Native Player Layout

Per T436142: Assess ML v0 TTS prototype, the frontend implementation will use native HTML5 audio wrapped in custom Codex controls, rather than TMH. All button layouts and design specs can be built strictly with Codex components without constraints imposed by TMH's default video player container.

A user is reporting:

This might be related to T287149: Cargo ignores DB schema in Postgres. For Cargo no schema is set at all, causing the connector schema to defaults to null. This will then cause a 'current schema' lookup. If the fallback (public) schema has been deleted, there will be no fallback schema at the postgres level and you will crash as 'null' is not a valid argument to setCoreSchema()

This has been open for 4 years, and i don't think there is enough information here to be able to figure out what the cause was, without additional reports that have not occured. Let's close for now.

This was fixed by T372169: Refactor NameTableStore to avoid complex onAtomicSectionCancel() callback

So next steps... First of all i propose we enable the chunked support by default on testwikis. I don't think that will give us much useful extra information, so I think we can decide to enable it on some common pilot wikis like:

• itwiki
• plwiki
• fawiki
• jawiki
• ptwiki

Or we can go bolder and simply switch Commonswiki, where i think we will at least get more usable data, even though it's default upload flow is UploadWizard.

One option is just adding the dependcy to the general skins modules of each of the skins. Not super nice and correct, but probably less intrusive ?

The problem here is that the presence of footer icons are skin specific. This styling however is applied to ALL footer buttons. There is however no existing overall skin module that we can easily add the codex button styles to and have the footer logic depend on. The logical solution is adding such a module, but that seems quite a bit of overhead.

Isn’t the problem simply that it is using xml::welformedhtmlfragement and instead of an html variant of that function ? (Probably doesn’t exist yet)

Was fixed in February

Actually, looking more into this, i think this is still how it works. it's now moved into WikiMap::getCurrentWikiId() (which still doesn't include the schema). And DatabaseDomain::getId is more like the identity of the connection, not of the wiki, which does include the schema.

https://commons.wikimedia.org/wiki/File:Rotating_LG_Wing_hinge-tefk_cceqtM.webp shows a small glitch happening in the thumbnail. This has to do with the order of the ImageMagick parameters. I'm working on a small follow up patch for thumbor.

This was fixed with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContributionScores/+/1166468

assuming things didn't break harder. 6 years ago now, so i don't think there's much use in keeping this open.

This is now in DatabaseDomain::getId() and that includes schema. 847b91bf1fd

The remainder of this was fixed with 55ce4782819