Yep, those file pages do not exist (as such, it got no license, etc.) Happen from time to time, no idea why. There were some bugs in the past.
However, these files were uploaded on 5 September 2024, so whatever bug is probably still there.

This problem also exists for DuckDuckGo. Also videos on Commons are not shown in the videos tab of search engines. I don't think there is any other as important Commons issue. See Community Wishlist proposal Do something about Google & DuckDuckGo search not indexing media files and categories on Commons with 3 concrete things that could be done.

@Winston_Sung: Removing task assignee as this open task has been assigned for more than two years - See the email sent to task assignee on October 11th.
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!

Some users, including me, browse and edit with Javascript turned off sometimes. It drastically reduces your bandwidth. On a slow connection, everything is faster, and on an expensive one, everything is cheaper. So I strongly prefer a solution that doesn't discriminate against people with worse internet access, by making it harder for them to get metadata on an image file.

At some point I made a script as a test to see if it was possible to locate files also on Commons. It started as a one-time-run on a tiny wiki. Then another one... I also tried it on a larger wiki like uk.wiki that have 115 k files. It works but you have to configure it manually for each wiki and I imagine that it creates some traffic on the server so it should pobably not be run too often.

There are two different problems mentioned here as I understand it:

Change #1084920 had a related patch set uploaded (by Alistair3149; author: Alistair3149):

[mediawiki/core@master] Use smallest size in wgThumbLimits for file history thumbnail

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

Change #609798 abandoned by Reedy:

[mediawiki/core@master] Add img_deleted column

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

I also wonder if we're trying to do much. It's already evident we don't have enough engineering resource to move some of these tickets. If the goal is to serve SVG files to be rendered in the client, then we should probably stick to SVG 1 and if there are weird text issues, then it is incumbent on the uploader to fix - use a common font, convert text to shapes, etc. I'm just an punter not an employee, so maybe I'm wrong, but it seems to me that the overall scope is ultimately to provide vector diagrams to illustrate an encyplopædia. Maybe we don't need to get too fancy :) It sure would be nice to have SVG music snippets T49578 for example, some time this decade.

In T40010#10259652, @RazrFalcon wrote:

but resvg's loss of Yevhenii Reizner, who had been doing about 9/10 of the work from the beginning, is a serious threat to its future

Funnily enough, when I've started working on resvg around 2017, librsvg was dead/abandoned for more than a decade, which was one of the reasons behind resvg creation.
And like a year later, 2018ish, librsvg authors started a rewrite to Rust, which revitalized the library.

but resvg's loss of Yevhenii Reizner, who had been doing about 9/10 of the work from the beginning, is a serious threat to its future