fyi @KCVelaga_WMF has agreed to help us out where he can on the data-wrangling side

Think we've answered everything that needs answering for now, so closing

So with the above code merged we now have

Some baseline numbers for thumbor (from grafana) as of Jul 16 2026 for the last 30 days:
Requests per second

• Mean eqiad: 79
• Max eqiad: 407
• Mean codfw: 57
• Max codfw: 321

Processing time

• Average: 0.75-1s
• p0.5: 0.5-0.7s
• p0.75: 0.8-1s
• p0.95: 1.8-4s (mostly around 2-ish, with spikes)
• p0.99: 4.5-40s (mostly around 5-ish, with spikes)

@Ladsgroup I don't understand what the x-axis is on your graphs

if the PNGs are used to calculate the right SVG size, they could be deleted immediately after

Well not really - if the png is missing when the page gets re-parsed it gets regenerated. We probably don't want this

That's brilliant, thank you @MatthewVernon ! Any chance you could run the same on a bucket that got cleaned up a long time ago, e.g. 0f. Just so we can get a sense of the background growth rate

I don't think those pngs are in fact useless. I might have the sequencing wrong here, but this is how it looks to me ...

That's 7.8M for a container that you've already cleaned up? So there's lots of regeneration happening? Could we get some data for one that has not been cleaned, for comparison?

Added the filters @Samwilson

I don't see a way to distinguish between containers in the metrics ... maybe I'm missing something though?

Update: current frontrunner for an SLO is "75%th percentile latency will be less than or equal to 1.4 seconds for 95% of the quarter". It reflects performance for the last quarter, and our baseline for any changes we make should be "don't make things worse"

Ok I didn't know about that, but even so - fixing the rendering (or writing new code to handle .xcf if we replace thumbor) means not spending time on something else, which is v hard to justify for a format with such a tiny amount of usage. To me it seems a a better use of our resources to deprecate it

In T260286#10354952, @Bawolff wrote:

Just fyi, here is a perma-link to the discussion on commons https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2020/08#RfC%3A_Deprecate_XCF_file_format . It wasn't a popular proposal.

Yeah I think the other user was probably looking at what happens when you select the option "This work was created by someone else and is free to share" - in that case you can select the licence and enter the source etc, because that's the original licence. There is a template https://commons.wikimedia.org/wiki/Template:Own_based that can be used to say "this file is based on this other file" but the other file needs to also be on Commons for it to work so I don't think it'll really work for this?

I actually don't know how this ought to get represented either in the information template or the structured data. @LordBelbury is there an existing convention around this that you know of?

@TheDJ we're doing quite a bit of talking about this right now in the context of media scaling work we're scoping out for July 2026-2027, but have no concrete plan yet.

@IBerker-WMF can you confirm please?

In T414337#11528476, @Tgr wrote:

...

3. Serve images in same-site requests (upload.wikidata.org etc).

Per @Joe this might not be as horrible as it sounds. It does break client caching across sites, though, plus a ton of community tooling probably. In any case, if we take this route, it's mostly SRE work.

Oh sorry - I thought you meant the EditWatchlist page rather than the watchlist itself. @Ladsgroup any thoughts?

Oh dear. Can you give me some more details? Special:EditWatchlist times out when you go directly to it?

Looping in @Cparle, as I might have outdated information on AI-generated content handling on Commons.

I don't know anything more than what you're posted above ¯\_(ツ)_/¯

Hmm - I had intended to work on this myself, and did do some work on it, but I have higher priority things going on right now. Don't know who else might do it, which is why there's no team tagged

AFAICS we don't fit into any of the pricing categories listed on the VIA pricing page, and I expect that a h.264 streaming licence would still be free for us

+1 to @Krinkle - I can't see a compelling justification for the additional complexity being introduced here, and I don't think this approach helps get around any legal issues

@Jeff_G and @GPSLeo there has been a bunch of work on watchlists since the last comment on this ticket - are you still experiencing problems?

Yeah. Lower uptake than we were hoping for! Might be interesting to also run the query for users with over 1k pages in their watchlist?

You're querying users who've had a revision since Jan 1 2024, I was querying users who'd had an edit since Jan 24 2026 - my rationale is that if a user hasn't been active since watchlist labels were deployed they won't even know about the feature, so it doesn't make sense to count them. So my count of active users with large watchlists is 56780 (as opposed to your 114464)

Added some tags, should get picked up in the next wishathon, also will flag it with CommTech to see if anyone can pick it up sooner

And is a prefixed wildcard going to be okay, performances-wise?

Think we'll need to talk to @Ladsgroup

A <bdi> instead of a <span> maintains the directionality though. @Mooeypoo any thoughts?

@GMikesell-WMF how it's displayed on the actual Special:EditWatchlist page is ok now right? The problem is with the modals? That looks like a problem with the codex checkbox, I added a subtask T417979

In T416172#11634338, @Sadads wrote:

I wanted to endorse this request I have always had thousands of articles on my list, and it makes no sense to manually go through and do it. It would be particularly useful to have the search support the various special words in the search index -- (i.e. incategory) so that you could batch edit, based on existing metadata.

@GMikesell-WMF when I said this

Resolved now @Aklapper - thank you!