In T437349#12410429, @Yodin wrote:

[..] unfortunately PDF exports seem to have stopped working again on enws and frws (haven't checked other languages), [..]

In T437349#12410429, @Yodin wrote:

I run into this problem when trying to reupload this file. The workaround with uploading a nulledit (just changing metadata) didn't help. While I get the outdated version in Germany, I am able to download the correct version from a server in New York City. Try to download the original file. The correct sha256sum of the most recent upload is 8696b9c48d60c0b39a1324cd358c3eda77f93166c7ed374232c3c4baa816bae4. The very first upload has defb9c72963847fbba65fb8ec955dd9fc3d3a0394d5724753c9c22af70ae9ddf.

@TheDJ I am not familiar with the architecture and the algorithms of the protection system against unwanted scraping. To me it appears quite likely that the amount of traffic from a particular site can play a role, causing the tool to work or to fail for some sites. But it appears to me very likely that the gadget failures are linked to the protection system. Regard the gadget: I am not the author of the gadget or anyhow involved in its development. However, downloading and uploading the image to submit them to various reverse searches as suggested by @matmarex do not appear to be the straightforward solution. I think it would be better to be able within the gadget to generate image URLs that are subsequently accepted by protection system. My point is that Wikimedia Commons and its defense against copyright violations is a critical part of the infrastructure. This perspective should be IMHO taken into account when designing and updating the protection system.

As explained by @RoyZuo above, we have at Wikimedia Commons a serious problem if the gadget that supports image reverse search on Google Lens, TinEye and Yandex doesn't work. Right now, TinEye and Yandex work but Google Lens fails as it is unable to access the images. I am not responsible for the gadget but as one of the admins at Commons I can tell you that this gadget is absolutely essential to fight against copyright violations. We delete about 2000 copyvios every day and we cannot do this efficiently if Google Lens cannot be conveniently queried. Hence, some solution is required such that this gadget can pass URLs that are subsequently not blocked when the respective services download them.

Associated dicussion at Commons: https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical#Upload_problem

This problem reappears as of now repeatedly on Commons.

I think that this can now be closed as resolved.

This has now been fixed by the author of this tool, see https://commons.wikimedia.org/w/index.php?title=User_talk:Dschwen&oldid=551241765#Zoomviewer

I am one of the two users who has currently a problem with OTRS ticket notifications.

I've now (some hours laster) reattempted the deletion and it worked now. Any idea or insight what happened?

file looks at the beginning of a file. Example:

I just run into this problem when I today tried to upload this JPEG file. Despite being a correct JPEG file it appears to be considered as a corrupted part of a multi-volume ZIP archive by the unzip utility of info-zip.org:

This is complex as the Commons category system is far deeper than any other category system. Take as example Category:Cathédrale Notre-Dame de Chartres (which is not even linked to Q180274 as preference was given to the gallery page which is of no real importance to Commons. This category comes with subcategories like Category:Exterior of Cathédrale Notre-Dame de Chartres, Category:Portals of Notre-Dame de Chartres, Category:Royal portal of Cathédrale Notre-Dame de Chartres, and finally even Category:Right bay of Royal portal of Cathédrale Notre-Dame de Chartres, all properly nested in this order. It seems unpractical to link all these categories to Wikidata items. If you look at these cases, you see a stem, i.e. "Cathédrale Notre-Dame de Chartres" (which is in French as it is considered a proper noun) and various general specializations like "exterior of", "portals of" etc. We need an approach to tackle these composite category names by defining naming schemes which should be translated instead of translating each category individually.

And the addition of the latest "thanks you" enables a new kind of vandalism. Check the log of new users and you will notice that offending user names are not uncommon. In combination this opens the possibility to thank a victim using an offending user name such that the user name appears in the victim's profile.

One of the major problems of this feature is that pictures are taken out of context and associated with this "profile". Imagine a moslem editing https://de.wikipedia.org/wiki/Mohammed who is possibly not happy to see his name and profile associated with a depiction of Muhammad. Likewise you might imagine that someone edits an article with lead images that depict genitals. You see examples for this on Lila's talk page at Meta.

A bounce was delivered in case of ticket 2015020910006133 with following error message: