What are the "thumb steps" incantations exactly ?

In T416620#11590113, @Soda wrote:

What are the "thumb steps" incantations exactly ?

https://www.mediawiki.org/wiki/Common_thumbnail_sizes

Current standard sizes in Wikimedia production: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px

Accessed from wgThumbnailSteps.

They're the values of $wgThumbnailSteps, which are documented at https://www.mediawiki.org/wiki/Common_thumbnail_sizes

I think basically we need to switch from 1024 to 1280px (or 960px I guess, that's closer, but probably most page scans would be better slightly bigger). And I'm not sure how the x2 sizes are handled (that get added to the srcset and loaded by OpenSeadragon).

(oh oops, should've reloaded this task before replying!)

I'm planning to re-enable the rate limit again on Wednesday, this is going to break your stuff. I can try to make the patch right now.

Change #1237972 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/extensions/ProofreadPage@master] Page: Bump the size of pdf thumbnail size to a standard size

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

Change #1237972 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@master] Page: Bump the size of pdf thumbnail size to a standard size

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

Copying over what I mentioned in my +2, TLDR, while the basic functionality is unbroken, there is still a fair bit of functionality that remains broken that will need fixing.

Two points that I noticed:

• The scrset still outputs an image of 2560px (banned) This will subsequently cause OSD to break for larger zooms.

• ProofreadPage allows editors to override the default width, allowing a user-specified width, which allows folks to deal/see/transcribe landscape-style images.

I don't know how many pages use this feature, but we will still be breaking significant editor-facing functionality here.

For point one, I think we need a Mediawiki-level fix since the information/data for the scrset comes from Linker::processResponsiveImages(...), if that outputs the correct values, ProofreadPage should, for the most part, be fine.

For point two, I honestly really don't know what the correct solution here is. My personal thought would be to slow us down a bit and look at how often the parameter is used and whether there are any load-bearing/important use cases and then go from there, but the tone of the ticket/speed of deployment suggests otherwise.

It looks like there are quite a few that use the Width parameter (although that regex is probably not catching them all). Mostly landscape oriented pages, as Soda says.

But I agree that it doesn't look like ProofreadPage is doing anything wrong, and I don't think we need to constrain Index pages to only using the permitted widths. Should File::transform() be making sure it doesn't return a MediaTransformOutput with an invalid width?

PdfHandler class needs a patch to use physicalWidth parameter when building the thumb url path (instead of width). I‌can try to do it too. That being said, pdf files are a very small portion of non-standard sizes and I'm here just trying to avoid breaking user experience.

Change #1238332 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/extensions/ProofreadPage@wmf/1.46.0-wmf.14] Page: Bump the size of pdf thumbnail size to a standard size

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

Change #1238332 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@wmf/1.46.0-wmf.14] Page: Bump the size of pdf thumbnail size to a standard size

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

Mentioned in SAL (#wikimedia-operations) [2026-02-10T13:12:33Z] <ladsgroup@deploy2002> Started scap sync-world: Backport for [[gerrit:1238332|Page: Bump the size of pdf thumbnail size to a standard size (T416620)]]

Mentioned in SAL (#wikimedia-operations) [2026-02-10T13:14:42Z] <ladsgroup@deploy2002> ladsgroup: Backport for [[gerrit:1238332|Page: Bump the size of pdf thumbnail size to a standard size (T416620)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-02-10T13:20:45Z] <ladsgroup@deploy2002> Finished scap sync-world: Backport for [[gerrit:1238332|Page: Bump the size of pdf thumbnail size to a standard size (T416620)]] (duration: 08m 12s)

I'm sorry, what's the situation on this? The ProofreadPage interface on it.wikisource has become awfully unusable in the last days.
Most of the time, the image does not load. The "Transcribe text" tool is also broken as it does not receive a working URI to the image. The console screams many error messages like the following:

GET https://upload.wikimedia.org/wikipedia/commons/thumb/4/4a/Cekhov_-_Novelle%2C_Torino%2C_UTET%2C_1957.djvu/page173-1105px-Cekhov_-_Novelle%2C_Torino%2C_UTET%2C_1957.djvu.jpg net::ERR_ABORTED 429 (Use thumbnail steps listed on https://w.wiki/GHai. Please contact noc@wikimedia.org for further information (a765913))
jquery.js:9940  GET https://upload.wikimedia.org/wikipedia/commons/thumb/4/4a/Cekhov_-_Novelle%2C_Torino%2C_UTET%2C_1957.djvu/page175-1048px-Cekhov_-_Novelle%2C_Torino%2C_UTET%2C_1957.djvu.jpg 429 (Use thumbnail steps listed on https://w.wiki/GHai. Please contact noc@wikimedia.org for further information (a765913))
openseadragon.js:14699 Unsupported image format: //upload.wikimedia.org/wikipedia/commons/thumb/4/4a/Cekhov_-_Novelle%2C_Torino%2C_UTET%2C_1957.djvu/page174-1280px-Cekhov_-_Novelle%2C_Torino%2C_UTET%2C_1957.djvu.jpg
openseadragon.js:14566 No supported image formats found
openseadragon.js:19492 Assertion failed: [Viewport._setContentBounds] bounds.height must be greater than 0

Can someone explain in simple terms what is being done here, or what needs to be done, and when will the situation go back to normal?
Thank you.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PdfHandler/+/1240092 would hopefully fix it. I'm working on it. If you update your browser or use a more standard browser, you should be skipping the rate limit but that will break again once we tighten the rate limit.

Change #1241916 had a related patch set uploaded (by Sohom Datta; author: Sohom Datta):

[mediawiki/extensions/ProofreadPage@master] Make PagelistInputWidget use thumb steps

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

Change #1241916 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@master] Make PagelistInputWidget use thumb steps

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

For point one, I think we need a Mediawiki-level fix since the information/data for the scrset comes from Linker::processResponsiveImages(...), if that outputs the correct values, ProofreadPage should, for the most part, be fine.

Is there an existing task for this? (I can't find one.) It seems that 1.5x is fine (1920px), but there's no 2x. Should we switch to 3840px (e.g. srcset="foo.jpg, foo-1920.jpg 1.5x, foo-3840.jpg 3840w")? I'm not sure how high-density displays decide what to use, but adding the width like that (the w suffix) seems the simplest, short of rendering an extra thumb size.

The HTML is currently something like:

<img src="//upload.wikimedia.org/wikipedia/commons/thumb/9/9e/Hoosier_Lyrics.djvu/page108-1280px-Hoosier_Lyrics.djvu.jpg" decoding="async" width="1280" height="2204" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/9/9e/Hoosier_Lyrics.djvu/page108-1920px-Hoosier_Lyrics.djvu.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/9/9e/Hoosier_Lyrics.djvu/page108-2560px-Hoosier_Lyrics.djvu.jpg 2x" data-file-width="4738" data-file-height="7716" style="display: none;">

It certainly doesn't seem to be ProofreadPage's responsibility to output a valid srcset.

The reason the 2x is being sent instead of the src URL is that the former becomes OpenSeadragon's current image (seemingly without having to actually zoom the image, which I'm not sure but that seems like a bug maybe; isn't it only mean to request that when you zoom? Anyway, a separate issue!).