File has now been imported again to c:File:Philipp Jakob Wieland (1793–1873).jpg and this time it was successful. So bug has been worked around.

I don't really understand what you want. With cat-a-lot you can add, remove or move categories from files. The tool already shows up on file pages and you can there add or remove any category you like, so long the file in question is not a member of the category you want to add and is a member of the category you want to remove. Of course the move function only is available on category pages, because how else would the tool now from which category it should be moved? Or have I missed something? Sorry if I come off as rude.

In T372929#10079039, @Prototyperspective wrote:

Didn't notice it says it automatically creates an edit summary – then ignore the part about Wikidata. I don't think it's good that it does not display the automated edit summary on that page somehow because when the same edit summary field is blank like it's on Wikidata in other Wikimedia projects that people may be used to then there is no edit summary at all. Separate subject.

Your manual edit summaries seem to have been redundant. The automated edit summaries work fine, and I've attached a screenshot.

Are you sure? Both rollbacks and undo edits on Wikidata seem to work fine, edit summary-wise, AFAICT.

Okay, I see. My bad.

I see now that 157 OGG audio files at rowiki are identified as video, see https://ro.wikipedia.org/wiki/Special:Search/file:_local:_filetype:video_fileh:0.

Perfect, thanks. This can probably be closed then?

Thanks for your digging. I think you are right that a general fix is not necessary nor worthwhile to make so it'd be better just to repair this specific file individually. Do you know of any good tool that can repair it?

T282202: MediaViewer is unavailable for WebP originals

@matmarex Can you reproduce this?

@Jdlrobson But the problem arose along with the zooming and search bar issues, so it is very related indeed. Unless there was some very unlikely coincidence that the SVG edit button problem and the search bar/zooming problem arose at the exact same time independently of each other.

In T311795#8144017, @Jonteemil wrote:

Apart from the initial zooming and tiny search bar problem, we who are using the SVGedit tool are also affected by a third problem, namely the edit button when on SVG file pages, such as File:Test.svg is displayed incorrectly. An empty dropdown is shown eventhough the button hasn't been activated which should trigger the dropdown.

@DLynch Okay, so the bug should rather be reported on https://webkit.org/new-bug?

Apart from the initial zooming and tiny search bar problem, we who are using the SVGedit tool are also affected by a third problem, namely the edit button when on SVG file pages, such as File:Test.svg is displayed incorrectly. An empty dropdown is shown eventhough the button hasn't been activated which should trigger the dropdown.

@DLynch The screen recording is identical on Safari, Chrome and Firefox apps. Is it really possible that all three browsers have the exact same problem?

@DLynch Are you able to see the screen recording I uploaded?

Here is a screen recording I made. The zooming works as expected when I press on Subject or Summary but not when I lastly press on the Description box.

@matmarex Can this be closed? It works as expected both on testwiki and enwiki now.

Are https://upload.wikimedia.org/wikipedia/commons/thumb/5/56/Christopher_Street_Day_Koeln_2022_033.webm/800px--Christopher_Street_Day_Koeln_2022_033.webm.jpg and https://upload.wikimedia.org/wikipedia/commons/thumb/5/56/Christopher_Street_Day_Koeln_2022_033.webm/320px--Christopher_Street_Day_Koeln_2022_033.webm.jpg supposed to display different images? (Which they do for me at least)

I'm not getting HTTP500. I am however getting another frame of the video than what is rendered as the JPG preview, which also seems weird.

@Tacsipacsi Aha, gotcha.

@matmarex I mean the prefixed colon is necessary. What isn't is the doubling of the pagename.

Okay, how can their info be updated in the search index then?

https://commons.wikimedia.org/wiki/Special:Search/filemime:audio/webm still lists a bunch of videos so this can't be fixed, or am I wrong?

I have resaved the smaller files using the CropTool which was a successful workaround but the ones with 100MB+ were to big so they still remain unrendered.

Okay, so to sum up, this is no Thumbor issue, but rather an issue with the GIF mimetype?

@Aklapper You think that's related?

@Krinkle You are listed as co-creator of GUC along with Luxo who is retired since 2014. Have you got the ability and time to fix this or know someone who might?

@NguoiDungKhongDinhDanh You're correct. I guess only enwiki and Commons are affected by this. Should still be fixed nonetheless.

I'm assuming https://commons.wikimedia.org/w/index.php?title=File%3AOBA_BiztKotv_CMYK_2011.tif also would be an example of a file affected by this bug.

Pinging @AntiCompositeNumber as always when I find strange files.

@jcrespo @AntiCompositeNumber Given that nothing has happened since october, should I just ask the uploaders or any user to reupload?

I figured this was a more precise title.