Where to look for files deleted by administrators on Wikimedia?

Hi all,

I got the following warnings like below when I tried to upload an image file to the WikiMedia Commons with OpenRefine:

MediaWiki error while editing [Warning]: The file upload action returned the 'Warning' error code. Warnings are: {was-deleted="Dura-Europos_archival_photograph,YUAG_negative_number_1938'5561a~01-object-id-9287.jpg", duplicate-archive="Dura-Europos_archival_photograph,YUAG_negative_number_1938'5561a~01-object-id-9287.jpg"}

I think I uploaded these images before, but they were later deleted by someone not me, I just wonder where I can check for the deletion record, and if these images have been found duplicated with other images already on the commons, what are those images.

Appreciate help of any kind!!


I can't explain the eroor message, but it looks like a file with that name never has been deleted on Commons: Deletion log - Wikimedia Commons

You can see deletion requests on your discussion page.

It looks like quite some messages were posted there and you did not notice them, @AleFang. Normally, unless you have configured your Wikimedia account differently, you should get email notifications about new messages that get posted on your talk page. Did those end up in a spam folder, perhaps, or did you disable them on purpose?

Perhaps you are not the only OpenRefine user who does not get notified about talk page messages: there might be people who only log in to the Wikibase via OpenRefine and visit the Wikibase itself without being logged in.

Because it's quite important to be responsive to such messages when doing batch imports, I wonder if OpenRefine itself should notify users about unread messages on their talk page, in its own UI. That could be a safety measure against people continuing to upload without getting feedback about what they do. But I don't know to what extent it's doable (not sure if there is an API to check for unread messages).

1 Like

Not really an answer to the question but you seems to don't really know how Commons works, so here some advice:

  • please read and answer to the messages on your Commons talk pages, this is very important, otherwise, more files will be deleted and worst case scenario, you may end block on Commons
  • never, never, never re-upload a previously deleted file (this is a waste of time for you and for the community on Commons, and it's an other reason for blocking a Commons account)
  • alway give the very basic information about the photo : the lack of these informations are the reason that caused the deletion and block the undeletion.

We're here if you have any questions.


That would work if such messages would be immediate, but deletion notifications usually arrive only days (sometimes week) after an upload.
Instead, better guidance on what data must be added in the schema would be a possibility. Like a clear and very stern warning if one uploads files without any of the following basics: date, source, creator, license/copyright, and wikitext.

I've seen this phenomenon before (new Commons users omitting these fields, resulting in deletions) and I've already created an issue for it: Prevent users from uploading and give warnings during upload if certain basic metadata and Wikitext criteria aren't met · Issue #95 · OpenRefine/CommonsExtension · GitHub

My intention with this was to avoid the situation we are witnessing here, of someone doing follow-up uploads even though people have flagged problems with previous uploads.
So I am imagining that before any batch is uploaded, the user could be warned of new messages on their talk page, so that they are aware of problems that were brought up by their previous uploads. That does not require messages to be immediate. Is that clearer?

The existing QA system can be improved to catch more issues with uploads, but that system will always have its limits. There will always be deeply flawed uploads for which the system does not detect any issue. So it's not a substitute for making sure that OpenRefine users are able to communicate with the community on-wiki.

Also, adding more QA checks often requires adding more parameters to the manifest, because those QA checks do not necessarily apply to all instances. Say, there might be wikis were people are not expected to specify a license when uploading, because all the contents on the wiki are available under the same license. The more parameters we add to the manifest, the more likely it is that those get out of sync with the practices on the wiki.