I have the same problem for many my files, for example https://commons.wikimedia.org/wiki/File:%D0%9C%D0%95%D0%92_1883-07.pdf

The mobile watchlist has been disabled in T109277 so the original bug reported here no longer applies. Please feel free to open a new ticket if you are still experiencing this problem in some form today.

In T246901#9724027, @bvibber wrote:

(I see this is also in the Hackathon workboard -- perfect timing! I'll have updates on the patch for folks to test by then but I'll be remote for it. :D)

Let's provisionally call this Resolved. Of course, if people run into this again, they should report here and re-open.

Hmm, i was going by caniuse saying that IE11 was the newest browser that didn't support it, which based on wikitech-l is soon to be grade X. I think thumbs not working in a grade X browser would be reasonable, but you raise a good point about the broader ecosystem.

I was under the impression that we would dynamically send webp thumbnails when the accept: image/webp header was present

I'm going to boldly re-open this for further discussion

Change #1027205 merged by jenkins-bot:

[mediawiki/core@master] Migrate media.thumbnail.stream to statslib

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

@TheDJ if its just that file being broken, I think it makes sense just to leave it the way it is, so I'm going to reclose this bug (but please reopen if you disagree)

Untested, but this seems gold, at least for the Locator Tool:

In T343131#9078661, @Jarekt wrote:

About Template:Dir used on 112M pages, likely dozen times on each page. That template is imbedded in almost every non-lua-based template that shows some text. Lua based templates (like Template:Information and other infoboxes) use mw.language:getDir function. We do have 181k templates on Commons and good fraction of them show something, so it would be a big job to replace that template. The easiest solution would be to add it to "software or parser functions" which would use the current format, the way {{!}} template was replaced by a parser function. Whatever way it is implemented it would be good to keep it in synch with Lua function. Shall we create a ticket for that?

@MarkAHershberger: Removing task assignee as this open task has been assigned for more than two years - see the email sent to all task assignees on 2024-04-15.
Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome! :)
If this task has been resolved in the meantime, or should not be worked on by anybody ("declined"), please update its task status via "Add Action… 🡒 Change Status".
Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator. Thanks!

Images on the beta cluster haven't been happy for a while :/ not sure if the above reported issue is a symptom of some/all:

Whoops, I didn't mean to give it such an alarming title. I should proofread better, sorry about that.

In T353981#9801657, @Bawolff wrote:

I think IFD1 is for the embedded thumbnail (if present) and not the actual image. (ifd1 is irrelavent)

I guess we could have the riff tags override, thry would be source of truth.

Its a little weird we extract the technical data from exif at all.

I think IFD1 is for the embedded thumbnail (if present) and not the actual image.

This image seems better: https://commons.wikimedia.org/wiki/File:Xili_Eco_Park.webp
Clash of exif and xmp perhaps ?

Hmm, something doesn't seem quite right yet.

@Mike_Peel I fixed the template with this change:
https://commons.m.wikimedia.org/w/index.php?title=MediaWiki:Minerva.css&diff=876480738&oldid=876480698&title=MediaWiki%3AMinerva.css&diffonly=1

It's not. It's also not the first time WMF has added hack stylesheets; the original was for adapting some templates to be more friendly for mobile. (They came to understand that these hacks were not generally a good thing.) Now they live in WikimediaMessages, though they used to live in the Minerva skin.

"hack stylesheet" - can you be more specific? That doesn't sound good for the long term.

On enwiki, there is also a defined background-color for .infobox in https://en.wikipedia.org/wiki/MediaWiki:Common.css - but that seems to be OK?

WMF has added a hack stylesheet which takes care of many of the common user-created classes that one might encounter. That is why .infobox is fine.

We don't have as many webp files (26,729) as we have jpgs/pngs (92 million total), so I don't think it is a problem in this case.
Does remind me that we should add an example to the ticket, for the person executing it to check the result.

See also the very old T32961

It doesn't seem we have had a lot of complaints about this. Also "some files" isn't really specific information to go on 9 years later..

This process is now managed at https://commons.wikimedia.org/wiki/MediaWiki_talk:Copyupload-allowed-domains, not Phabricator.