Add a modality to keep contested images of commons on Wikipedia
Problem: Sometimes, like it happened to me at Abdürrezzak Bedir Khan an image is nominated for deletion and deleted by a bot.
Proposed solution: Anyone who contests the deletion reasonably, can ask an admin or a file mover to start a bot which automatically loads it up to the wikipedia project in which the image is needed but deletes the contested image from wikipedia commons.
Who would benefit: All editors who contest a deletion of an image on commons with a reasonable argument.
More comments: A good example is also The Burning Giraffe of Salvador Dali. My image was deleted from commons but an image is still included as an image of Wikipedia. I wouldn't know how to upload an image correctly to Wikipedia. Something like a Schlurcherbot for migrating images from Commons to Wikipedias would be great.
I have thought about this problem but generally I side on the "someone will correct the issue at some point if an appropriate file is available". Maybe a bot to notify local talk pages that an image has been deleted (even if for some reason the edit removing the image is insufficient). --Izno (talk) 05:42, 21 January 2022 (UTC)[reply]
This would only be useful for images that would fall under fair-use on Wikipedia, wouldn't it? Because other deletions would be valid and the image should not be allowed to be used on other wikis. Also, don't fair-use images also usually have to be reduced in size (or modified in other ways) to make them eligible for being uploaded to Wikipedia? That would make it hard to have a simple trans-wiki copying system. Note also that the Commons deletion notification bot already notifies talk pages of articles using images that are to be deleted. Anyway, this proposal can definitely proceed to voting, but I just wanted to check that you're happy that it won't run afoul of wiki policies? — SWilson (WMF) (talk) 02:41, 25 January 2022 (UTC)[reply]
Oppose: we cannot automatically determine whether a file that has been deleted on Commons for some reasons still falls within, for example, en.wiki scope. It would be very bad to see easily ported attack images, images without sufficient copyright information for our non-free content criteria, or out of scope images. This affects legal issues as egregious cases could even fall afoul of fair use or piracy law (e.g. a film uploaded as a video). So this tool would have to be restricted to experienced users, who can be trusted to actually check that the image is appropriate for the wiki they want to use the image on, but by that point there is little use case as experienced users should (a) not often have images deleted on Commons and (b) be able to reupload the image without too much trouble. — Bilorv (talk) 10:58, 6 February 2022 (UTC)[reply]
Oppose Better not to tinker with copyright matters. If something belongs somewhere else, the user could be instructed to do so. If the user is unaware of how to achieve that, they can ask for help. — DaxServer (t · c) 11:44, 6 February 2022 (UTC)[reply]
Support For what it's worth, there was once a bot doing this, but it's operator was WMF global banned and no one else took on the task. * Pppery * it has begun 18:40, 28 January 2022 (UTC)
Oppose: we cannot automatically determine whether a file that has been deleted on Commons for some reasons still falls within, for example, en.wiki scope. It would be very bad to see easily ported attack images, images without sufficient copyright information for our non-free content criteria, or out of scope images. This affects legal issues as egregious cases could even fall afoul of fair use or piracy law (e.g. a film uploaded as a video). So this tool would have to be restricted to experienced users, who can be trusted to actually check that the image is appropriate for the wiki they want to use the image on, but by that point there is little use case as experienced users should (a) not often have images deleted on Commons and (b) be able to reupload the image without too much trouble. — Bilorv (talk) 10:58, 6 February 2022 (UTC)
