Open main menu

Wikimedia Commons β

Commons talk:Criteria for speedy deletion

This talk page is automatically archived by ArchiveBot. Any sections older than 60 days are automatically archived. Sections without timestamps are not archived.

Criteria codes instead of criteria numbersEdit

I suggest we change the criterion numbers listed in this article to the criterion codes used by the {{SD}} template. E.g. Instead of listing them as 1., 2., 3. we should use G1, G2, G3. That way users don't even need to click on the link to the list of criteria codes to see them; they can just scroll down. I don't see any significant downside.

Note that I already made a presumably non-controversial change to the mention of this template to say {{SD|<criterion code>}} with an example, since I was confused by the previous text {{SD|<criterion number>}} which I presumed meant I could just use something like {{SD|7}} (which won't work).WinTakeAll (talk) 03:11, 24 March 2016 (UTC)

No opinions against it, so I went ahead and made this small change.WinTakeAll (talk) 19:42, 3 April 2016 (UTC)
   Strong oppose This page is already complicated enough. Also, the codes are not good for anything. If you want to nominate a page (or file, ...) for speedy deletion, you should use a text reason and not one of these more or less meaningless codes. --Didym (talk) 20:13, 3 April 2016 (UTC)
   Strong support . It clearly makes things simpler, and not the contrary. Saves the editor from typing sentences. Rehman 13:22, 4 April 2016 (UTC)
  •    Oppose Deletion templates should have readable names, not gibberish codes. --Stefan2 (talk) 19:52, 4 April 2016 (UTC)
  •    Support , some folks not including me use the criterion codes, and changing n to Gn in the "general" section as used in {{SD|Gn}} is harmless for others + useful for these users. Ditto Fn, Tn, Un. And whatever these users like for gallery != general (maybe A?), category != commons (maybe P as in project?). Be..anyone (talk) 17:10, 6 April 2016 (UTC)
  • Support Standardized text is useful. Anyone who wants to write their own prose should be able to do so, but since so often deletion rationales for many files are the same, it is useful to have a shorthand. In English Wikipedia this system worked well, and that is supporting evidence that a similar notation might be similarly effective here. Blue Rasberry (talk) 20:52, 19 July 2016 (UTC)
  •    Oppose i see no need. --Steinsplitter (talk) 16:42, 2 December 2016 (UTC)

F9 criteria updateEdit

Current Updated
9. Embedded data
The file contains additional embedded data in the form of a password protected archive.
9. Embedded data
The file contains additional embedded data in the form of a password protected archive. If the information can be lossless removed without impacting the rendered image in any way, preserve the new version while deleting the earlier version.

Proposed update intends to address files that are unusually large. This isn't intended to remove metadata and other important features of files and instead focuses on removing the junk data. -- とある白い猫 ちぃ? 16:28, 2 December 2016 (UTC)

I would generally agree with this, with a big caveat. I understand that sometimes software might add some data to a file, however this would be expected to be in the form of identifiable (if not readily parseable) tags (exif, icc profiles, or whatever). That stuff, while it might easily be malicious if we cannot parse it, could conceivably be explained and thus would merit simple removal. I have not seen a believable explanation for data appended to the end of a JPEG, and as such that greatly reduces the amount of good faith I feel able to assume. I doubt such files in general can be assumed to be created by the uploader. Storkk (talk) 20:51, 2 December 2016 (UTC)
@Storkk: While I have revdel a few of the 'egregiously' large cases after losslessly removing the excess data without trying to id it (like, where it was over 50MB), I think we should word this in such a way that we apply it (revdel) only to when we actually 'know' there is an embedded archive. See File:Briefmarke LindauerHuette 6S.jpg... this is a useful file, but the original version contained a 7z archive (which contained a PDF brochure for the ski resort, for some very strange reason). If we know there is an embedded file we need to delete it, one way or the other, to discourage people from abusing Commons to distribute illicit material this way. Reventtalk 01:29, 4 December 2016 (UTC)
However (as was pointed out by Dispenser Adobe Fireworks uses PNG as a 'native' file format, and includes non-image data about layers, paths, history, etc in private EXIF fields, so they are 'absurdly large overhead' legitimately. Reventtalk 01:31, 4 December 2016 (UTC)

@Revent: perhaps we are talking slightly at cross-purposes, but I think it would be prudent to be quite wary of large data inside of undocumented tags until they have been explained. So Fireworks PNG are probably OK, but incredibly large ICC profiles, unexplained binary metadata tags, etc. we should probably strongly consider stripping/re-compressing and revdel'ing. And I've seen no plausible innocent explanation at all for binary data that's simply appended to the end of the file. That should raise extreme suspicion, IMO. Storkk (talk) 17:40, 4 December 2016 (UTC)

@Storkk: I think we've just saying it differently.... if there actually 'is' such suspicious data, yes, we should make it go away, my point is more that sometimes simple 'large overhead' is just due to something like not checking the 'optimize' button when saving a jpeg, and we should probably avoid being accusatory toward people unless we actually 'know' it's something suspicious, and not just inefficient or broken. Reventtalk 03:49, 5 December 2016 (UTC)
@Revent: Sorry, I'm not sure how to answer that except to re-iterate my first reply to the proposal above. Weird tags embedded: OK, just remove them, not of-themselves damning, and not of-themselves a reason to speedily delete the whole file. Unparseable binary data appended to the end of the file I think is by itself extremely suspicious (is this where we disagree?). I still have yet to see an innocent explanation for that, and someone has to deliberately put it there. The JPEG's compression level is tangential, I guess that's why your reply has puzzled me. Storkk (talk) 14:55, 7 December 2016 (UTC) edited to add "Unparseable"... 7z files with clearly non-copyvio inclusions I agree are recompress, revdel candidates Storkk (talk) 14:58, 7 December 2016 (UTC)
@Storkk: Optimization of a jpeg has nothing to do with it's compression level... it's just how efficiently the compressed data is stored. The point I am making is that we need to word this in such a way that we don't end up with people deleting, or rev-del, images and accusing people, explicitly or not, of being 'bad actors' merely because optimizing the image made it a lot smaller, without knowing that it specifically 'was' excessively large because of the various suspicious factors you named. As a test of this point, I just took an 15MP image of, literally, a blank neutral white painted wall with my cellphone camera. 'jpegtran -copy all -optimize' then reduced the file size by about 15%.. and this was not a specifically formulated test case, just me taking a photo of the wall by my front door. I'm just saying we should try our best to make sure that people aren't considering such images as 'suspicious' just because they are easily shrunk by significant amounts, especially since the first 5-10% of compression of a jpeg makes a huge difference. Just resaving the image in Gimp as 100% (it was at 93%) without optimization made the 'overhead' well over a megabyte. Reventtalk 21:49, 7 December 2016 (UTC)
@Revent: Can we agree for the purposes of this conversation to disregard entirely the actual JPEG image data (and also any parseable Exif/IPTC/other metadata tags)? We are still, I think, getting hung up on that. Storkk (talk) 22:32, 7 December 2016 (UTC)
@Storkk: I think you are misunderstanding me. I quite agree with deletion of files with large amounts of unexplained data outside of the image itself. I'm merely concerned that we word this in such a way that people who do not know how to specifically identify the existence of such data are not using this to speedily delete files like the image I discussed above and then accusing the uploaders of acting in bad faith. Reventtalk 22:59, 7 December 2016 (UTC)
@Revent: I agree that we should not allow or encourage that. Sorry if I misunderstood you. I don't think I have advocated the use of jpegtran (or pngcrush or whatever) as a basis for discriminating good from bad, and I would strongly agree that it should not be. Storkk (talk) 23:28, 7 December 2016 (UTC)

Speedy deletion of **empty** categoriesEdit

Categories may become empty by accident, or because files or subcategories that should be there are not present in it.

I'm totally opposed to any form of "speedy deletion" (without even leacing any redirect, really a deletion creating red links!) for these categories that were really meant to have content.

I've seen people recategorizing contents agressively, deleting significant differences (e.g. redirecting contents related to former countries or regions, or their historic documents, to a new different region: this is NOT the same topic at all), and then leaving empty categories which were abusively deleted with speedy deletion.

Empty categories are NOT in scope of Speedy deletion per the rules. Stop this ! This is clearly an abuse by some users using their privilege to delete content that has to be recreated from scratch (the deletion even hides the history completely, it's not simple to recreate them).

Speedy deletion is meant for abusive contents breaking strong policies (e.g. copyright issues) or for files/galleries/categories created by error with a bad name. This is not the case of most empty categories.

Instead of deleting them, please use redirects (or category redirects), keeping the history, so that these can be reverted easily. Stop deleting the page history abusively when there was absolutely no breach of policies. Or at least use the more formal proposals for deletion, so that users can discuss this.

Most of pages/categories that were "speedy deleted" were poorly checked: those doing that have left many red links everywhere, and broken the navigation in many pages. They cause difficulties for the maintenance and will finally fill up many other maintenance categories where these broken links are listed.

Admins that abuse their deletion privilege for bad reasons (notably empty categories) without discussing it (and not even reading this criterai page) or checking what they are breaking, should have their admin privilege revoked. They don't help this wiki, they just break it !! verdy_p (talk) 17:33, 2 May 2017 (UTC)

We can have a discussion about changing the current policy or about how it's applied, but I think you need to calm down a bit first. Shouting and calling other users aggressive or abusive is not helpful. I have a really hard time picturing admins spitefully deleting categories while laughing maniacally like Dr. Evil at their own power. The statement that empty categories are not candidates for speedy deletion according to the current rules is factually incorrect. COM:CSD#G1, COM:CSD#C1 and COM:CSD#C2 all contain provisions for this. LX (talk, contribs) 17:48, 2 May 2017 (UTC)
@Verdy p: Can you give us an example of a category that shouldn't have been deleted so we can better understand what you mean? --99of9 (talk) 00:06, 3 May 2017 (UTC)
Almost all categories for former French regions before 2015: they have been deleted and their content incorrectly merged to the new region, mixing their distintive history.
There are countless examples on Commons were this occurs: people are moving categories in hurry as soon as there's an adminsitrative change, and frequently this is controversial.
Note that former French regions in 2015 are likely to be restored soon as they were before their merge (the two presidential candidates have shown that this merge has failed and want to cancel this law and restore the independance of regions, or allow diufferent groupings: this was discarded under Valls ministry, but the national and regional parliaments have highly criticized this decision), and they have not disappeared completely in many other domains (even if their regional councils have merged, there are other topics not r,elated to these councils), and we have tons on documents on Commons that clearly make the distinctions between former regions (photos, buildings, statistics, maps, elected people, culture...) but still very few related to the new regions as a whole. This means that both kinds of regions have to coexist (even if we can subcategorize old regions into the new ones, we MUST NOT empty them). verdy_p (talk) 13:44, 3 May 2017 (UTC)
  • Comment I think there is an issue here, as admins tend to shoot-on-sight with empty categories if they get tagged with {{speedy}}. One persistent problem is deletion of moved categories, which have the {{category redirect}} removed and tagged for deletion - think of the situation with OSX.
Another example would be Category:Grave of Yulian Markowski, which was moved to Category:Grave of Julian Markowski at Lychakiv Cemetery. If Yulian is an acceptable variant on his name, then that category should have been retained as a redirect. This indicates to me we need a way of getting admins to look for a target and create redirects instead of deleting.
This would also address Verdy p's concerns - if a merge happens it should leave behind redirects (and page histories). If they are unmerged in the future, all that needs doing is reverting to the last edit prior to the redirect.--Nilfanion (talk) 01:47, 4 May 2017 (UTC)
I've taken a snapshot from the deletion log (User:Nilfanion/Category deletions) and will analyse it, that will take some time. My gut feeling is being being empty should not be a deletion reason by itself, and if it is empty we should look to see if a redirect is sensible. If now, for instance its got a spelling error, then delete away.
Verdy p's complaint is about ones like Category:Gates in Midi-Pyrénées.--Nilfanion (talk) 11:34, 4 May 2017 (UTC)
Not just this category, I saw people moving ENTIRELY the contents for the former French regions themselves and then speedy deleting the categories themselves, without informing anyone); but there are plenty of examples with countries/regions that have more or less recently have administrative changes: these speedy deletion cancels their past history, as if the topics had never existed, and merging cannot be redirected category content is not easy to revert when the category has been speedy-deleted by admins that hurry on speedy deletion requests (and just leave a comment "as per COM:SP" which is absiltuely not giving this reason as valid). Speedy deletion of empty categories is clearly invalid, unless there's an obviuous typographic error and the initial name was very incorrectly chosen (this often comes from the first author that made an error), or the content or title was offensive/abusive, in all other case, a normal deletion request may be queried, but {{category redirect}} should almost always used instead (contents may then be moved but this is still easily reversible: all is kept visible in the page history, and at least we can still search and find the former names that have MANY references of valid uses when the former regions were official.
If any region or country had an official status, there's NEVER any good reason to delete them, as if they had never existed! This just complicates later the new imports of documents related to them, that are hard to categorize correctly, or these new files are left compeltely uncategorized as importers don't know where to put them and have never created any category page: the just use the import tools and select some broadly relevant categories, and this adds much maintenance work for others to recategorize these new contents that should have easily fallen in the former (deleted) categories. verdy_p (talk) 16:13, 4 May 2017 (UTC)
Yes, not just that one there are dozens of examples. Current policy clearly states all empty categories may be speedy deleted. I don't think that is right, but it is current policy - so its valid.
As for these actual categories, we need to careful with them as we don't want them used for new uploads. If I see a gate in Lourdes, take a photo and upload it, we do not want me to put it in Category:Gates in Midi-Pyrénées but in Category:Gates in Occitanie. That's the current unit, we want photos in there. A redirect is probably appropriate for Midi-Pyrénées, as it was been merged into a larger unit. If Midi-Pyrénées had been split between Occitanie and Nouvelle-Aquitaine, deletion would be only valid option.
We aren't wiping Midi-Pyrénées from existence by deleting cats like Gates in Midi-Pyrénées from existence. The category for Midi-Pyrénées itself still exists, and there is no reason to change that. Certain other categories relating to it should also be kept, such as Category:Maps of Midi-Pyrénées. @99of9:, anything you wish to add to that?--Nilfanion (talk) 09:29, 7 May 2017 (UTC)
I agree with my quick reading of what Nilfanion wrote. Category redirects can be put in place where appropriate. I don't think the loss of the category history is a big deal, since categories hardly ever have much history. --99of9 (talk) 04:31, 8 May 2017 (UTC)
I don't remember specific examples right now, but I've seen this happen dozens of times, maybe a hundred times, over the last 10 years: A user deletes a category, with no edit summary reason other than "empty category", or tags it for speedy with no other reason than "empty category", and it usually turns out that the same user emptied it 30 seconds earlier and caused the situation, usually with some batch tool, instead of bringing the category to discussion. Sometimes the category was well-populated. The user never discloses being the one that emptied the category, let alone a reason why the category was emptied: Their "reason" for why it was emptied is always just the self-justifying "empty category". It's a massive dodge around the general requirement to discuss controversial deletions, and one of the cases where Commons policy that "Administrators should take care not to speedy delete pages or media except in the most obvious cases" is summarily ignored: No administrator ever questions anymore why a plausible category, even a long-standing one, has suddenly become empty without even a redirect. (Maybe someone can search for my name involving empty category speedies, but I can't find anything right now; I know I've pointed it out in the past though.) Somewhere long ago I believe the guideline was that speedy deletion was only for categories that had been empty for 7 days or something, and somehow this requirement got wiped out; it was before the "formal" COM:CSD reasons came into effect. CSD needs to be changed to remove empty categories from "new" speedy deletion criteria G1: The empty-category situation isn't the same and has never been the same situation on Commons. Speedy deletion for being an empty category shouldn't be available to the user who emptied the category; if there's a good speedy reason, then the user should be able to cite one of the other speedy reasons. Otherwise, it can and should go to discussion. --Closeapple (talk) 05:07, 8 July 2017 (UTC)

Photos of children with geolocationEdit

I've just tagged a kid's selfie with geotags for deletion. As a matter of child protection shouldn't photos of children with geotags be speedy deleted?

Perhaps with an exception where the tag is explicitly for a past event where the geotagging wouldn't result in any ongoing ability to locate the child, e.g. reportage of the bombing at the en:Ariana Grande concert. Cabayi (talk) 11:58, 7 July 2017 (UTC)

As a general rule, that seems very sweeping and rather pointless. LX (talk, contribs) 16:11, 7 July 2017 (UTC)
ACK: We've got COM:SELFIE, I don't really see the need to speedy delete things like this. --El Grafo (talk) 20:46, 7 July 2017 (UTC)

My two cents:

This is obviously about when a little girl named Shelly uploads a selfie called Shelly.jpg with a geolocation at the mall, then creepy guy with black van can say "Hi, you are Shelly, right? I'm your uncle, your Mom is sick. Trust me. I know your name. Come quick into the van. "

I think Cabayi is right, but do we need a policy for it? They must be spotted case-by-case.

LX says "sweeping" and "pointless". We may not be talking about new policy here. Just what admins ought to do.

El Grafo says we've got COM:SELFIE. That doesn't address anything like this. Correct me if I'm wrong.

When I see the next little Shelly.jpg with geolocation, I'm speedy tagging it. You can decline the speedy if you wish.

Anna Frodesiak (talk) 23:29, 7 July 2017 (UTC)

If the photograph is within COM:SCOPE (which should filter out most selfies), and the topic of the photograph isn't tied to its location, wouldn't it be less destructive to strip the EXIF geocoding, add {{Location withheld}} to the page text, and then suppress the old version like we do with certain copyright violations that have been blurred out? --Closeapple (talk) 05:29, 8 July 2017 (UTC)
Yes, if there is a geolocation problem, that can be stripped out rather than being fully deleted. But as mentioned, most such files would fail COM:SCOPE in the first place, of which COM:SELFIE is a part, which would be the real deletion reason (even if not speedy). I can't imagine there would be any real opposition to stripping the geolocation if somehow the file was in scope. Carl Lindberg (talk) 16:30, 21 January 2018 (UTC)

Corrupt filesEdit

I think there should be a speedy deletion criterion for corrupt files, as there is at enwiki. The same can also be done for missing or empty files for the same reason. Corrupt/missing/empty files have no use whatsoever and must be removed as you may have done on your computer. LaundryPizza03 (talk) 04:00, 17 January 2018 (UTC)

Hi. Yes, I agree we need some sort of criteria for irrecoverable corrupt files... You might be interested in this past thread. Cheers, Rehman 05:49, 17 January 2018 (UTC)
Why can't they go to regular Commons:Deletion requests? Are these issues really so frequent that they would clog up the deletion request queue? As for each issue:
  • Many users are not qualified to declare what constitutes a "corrupt" file without a discussion. Commons has had many files in the past that someone reported as broken, and it turned out they were not broken: Either the user's browser was behaving strangely, or the thumbnail was cached badly, or the MediaWiki software just generated an incomplete or broken thumbnail (which means that other users will say it's "broken" also without trying to figure out why). Images with print-ready CMYK color mapping instead of RGB color mapping sometimes get nominated for deletion because they are showing stripes or weird colors on Commons, but the weird effect is a MediaWiki thumbnail/resizing problem, and the uploaded file itself is correct; many of those CMYK files are the kind of high-resolution, high-quality photographs we want the most on Commons, and many image-conversion programs will produce an RGB derivative image suitable for wiki use.
  • We already have criteria F7 for empty files. (However, zero-length files or descriptions without uploads happen occasionally when an upload tool fails: Usually the file is uploaded properly soon after. And rarely, someone uses a batch upload tool that creates description pages en masse, then uploads the files afterwards. If it's been more than an hour or two since the page was created, and there is no file, that probably indicates that it has been abandoned, though.) --Closeapple (talk) 06:56, 17 January 2018 (UTC)
Yes, contrary to my initial reply, Closeapple's comment makes total sense. A criteria will be useful only if it could be proven that we have such deletions more frequently. Rehman 09:50, 19 January 2018 (UTC)


Due to Commons:Deletion requests/File:Rachel Kushner 2015 01.jpg (histlogsabuse log) I’d clarify that this criterion can’t be applied when an external resource certainly existed once in the past, but no more. May an anonymous Google Inc. employee force a Commons image under speedy deletion? Moreover, under very creative interpretation much of media here and here can be subjected to speedy due to on-the-ground “deletion” by ISIL and Islamic Emirate of Afghanistan, respectively. Incnis Mrsi (talk) 17:18, 8 March 2018 (UTC)

You are correct. I've added clarification on this. Rehman 02:42, 9 March 2018 (UTC)

Crossnamespace redirectsEdit

I notice cross-namespace redirects are specified for speedy deletion, yet we have had a guideline specifically allowing them since 2009 until now [1], but the guideline has never been revoked by consensus discussion. The discussion creating the guideline showed consensus for allowing them at the time. I'd like to request a link to the discussion which resulted in this policy being adopted, so I can understand better why this discrepancy arose. --Robert.Allen (talk) 21:53, 1 May 2018 (UTC)

Agreed, redirects from galleries to categories were allowed. I think the policy here was for other, nonsensical cross-namespace redirects and was not meant to overrule that other policy. Commons talk:Criteria for speedy deletion/Archive 1#Redirects, and some other sections there, mentions that. I think the change to Commons:Galleries should be reverted. That represents a change to long-standing practice -- rather, this policy should mention that practice (much like the en-wiki R2 criteria does). Carl Lindberg (talk) 01:26, 2 May 2018 (UTC)
The current practice is in line with the deletion policy, that is, many administrators will speedy delete these cross namespace redirects. A redirect from a non existing gallery to a category makes no sense. A link to a gallery should be red if there is no gallery. If you want to link to the category, just link to the category. Jcb (talk) 15:16, 2 May 2018 (UTC)
I don't think it is a good idea to delete these redirects, since more than just being harmless, they can be useful and do make sense. Converting them from a blue link that is useful to readers to a red link that is not useful is not an improvement. In the file descriptions, we often have links to the author or other names mentioned there, because not every reader will know to look at the list of categories at the bottom of the page. Plus it can put the link into a context which tells the reader why the name is of interest. It simplifies the links in the description if the category namespace does not have to be added as a prefix in a piped link. If in the future someone updates the redirect to a gallery page, it is linked automatically. In the past, another advantage was that the name would show up in the search field dropdown without the user having to append the Category prefix and/or execute the search (although it does seem the drop down has been improved, so this is no longer the case). --Robert.Allen (talk) 16:17, 2 May 2018 (UTC)
The exception allowing for gallery -> category predates this policy page. There is good reason for it to be grandfathered in, as Category-space is effectively Commons mainspace. Incoming links from other projects will be a major source of these links to these redirects. Those will not show them as a redlink, inviting a fix by an editor. Without a fix that no-one knows to make, any reader following the link gets dumped onto a non-page on Commons. A cross-space redirect to the relevant category is a better outcome. This particular exception should be included into CSD policy to stop trigger-happy admins.--Nilfanion (talk) 17:56, 2 May 2018 (UTC)
It has always been OK to replace simple galleries with redirects to the associated category if the gallery added nothing over the category (i.e. had all images in the category, with no captions, etc.). The galleries are often the incoming links from Wikipedia pages and the like. Deleting those redirects can break the links on Wikipedia articles and similar. If someone wants to work on a better gallery, they can replace the redirect. That was the policy agreed to in 2009 and has not changed since, as far as I know. This page failed to mention the exception, but that is the problem which should be fixed. Even en-wiki (where a lot of this policy was drawn from) allows redirects from main space to certain other namespaces. It makes sense for us too. Carl Lindberg (talk) 06:30, 3 May 2018 (UTC)
Till now only a guideline was cited in favor of accepting these redirects, while the official policy does not. If Wikipedia wrongly links to galleries, these links should be fixed instead. This argument is moot anyway since we have Wikidata, which shows a link to the category at Commons when it exists. Jcb (talk) 14:36, 3 May 2018 (UTC)

Proposal to modify the criteria for "Unused and implausible, or broken redirect"Edit

In view of the comments above, I propose we add the following exception to item 2 of General reasons:

However, a gallery title can be redirected to a corresponding category and such cross-namespace redirects are not subject to speedy deletion.

--Robert.Allen (talk) 17:21, 3 May 2018 (UTC)

  • No, of course no. No reason to bring back workarounds from our ancestors that make no sense anymore. If we would have wanted such a redirect for every category, we could have requested a software change to redirect all non-existing gallery pages to a category. If a Wikipedia article links to a non-existing gallery page, fix that link instead. Jcb (talk) 17:59, 3 May 2018 (UTC)
User:Jcb, I actually like your suggestion to request a software change to redirect all non-existing gallery pages to a corresponding category [if one exists]. If you were to propose it, I would support it. --Robert.Allen (talk) 03:44, 7 May 2018 (UTC)
  •    Support I don't think they harm anything, and can help. Additionally, "fixing" them means editing other projects, rather than preserving existing functionality here -- the deletions can then break other projects through no fault of their own. Part of the idea of the redirects was so that a better gallery could be created in the future without having to change the Commons links on articles in other projects. For Commons, galleries and categories are more similar in purpose than any other project, and so the cross-namespace redirect makes more sense here. Furthermore, this has been standard practice for a long time, and to me there should instead be a consensus to change the other way. But affirming it here would not hurt. Carl Lindberg (talk) 01:49, 4 May 2018 (UTC)
You are wrong on several points. "For Commons, galleries and categories are more similar in purpose than any other project" is not true of course, which you, as a long term user, are expected to know. Then, the "this has been standard practice for a long time" part is also opposite to reallity. I often come accross situation where one user keeps recreating the same cross namespace redirect, while it has been speedy deleted already by several different admins, sometimes even 4 or 5 different admins for the same page. The long standing practice is that those links get deleted, where only a handful of users seems to have the counterproductive hobby to create them. The current, long standing practice is in line with the deletion policy and this reason for speedy deletion is already one of the standard reasons in the deletion interface for over 7 years. Jcb (talk) 08:23, 4 May 2018 (UTC)
Well, the above policy was made without any consensus to overturn the previous consensus to allow them -- this point was made as part of a large policy page which was overall very good, but missed discussing that point in particular to my mind, meaning that was an omission here in the first place (which admins, no doubt, have then followed). So the claim that this policy, by way of being a policy but without any specific overriding of the previously-existing consensus, should overturn that consensus purely because it was labeled policy (and not because there was a discussion about it showing a new consensus), is a bit specious. Secondly, this vote then is about changing the policy in question, so the argument that it shouldn't be changed because that's the way it is now doesn't work either. I don't see much of a problem with those particular links, so I don't see the need to speedy delete them, and am in favor of the proposed exception to the speedy delete policy. Perhaps the original 2009 discussion was ingrained more in my mind, but I don't see where that consensus was ever overturned, other than by back door here. Carl Lindberg (talk) 02:22, 5 May 2018 (UTC)
A broader discussion will be needed, long standing standard practice is not going to be changed by a short talkpage chat like this. Jcb (talk) 06:33, 5 May 2018 (UTC)
  •    Support Especially when these were accepted prior to CSD being written; and that was because of the perceived benefits already described. More practically why delete them? What actual benefit is there? Jcb, please demonstrate the benefit of not adding the exception, or the harm of having these redirects. The fact there have been creation/deletion cycles is evidence that this exception would be useful - it would save unproductive time. If editors want to create them, why stop them?--Nilfanion (talk) 05:02, 5 May 2018 (UTC)
The assumed benefits are basically outdated by changes in the software since. Wikipedia articles link to categories via de Wikidata links in the left menu. For navigation purposes the gallery namespace is not needed and not meant. And "the fact there have been creation/deletion cycles is evidence that this exception would be useful" is a nonsensical argument of course. Jcb (talk) 06:24, 5 May 2018 (UTC)
Nope. The most prominent links to Commons are not the Wikidata-powered links in the sidebar. They are the links provided to sister projects in the body of the article, usually via template links near the end. Those links do not use the wikidata information, and while they could be improved are likely to dump readers into gallery space instead of taking them to a useful category. More to the point, this is not about mass creation of these redirects. Its about removal of them from the speedy deletion criteria, which in turn authorises mass deletion of long-standing links. They shouldn't be deleted unless their need has been negated, in practice not in theory only.--Nilfanion (talk) 13:16, 5 May 2018 (UTC)
  • Oppose. I understand Robert's good intentions, but I strongly share Jcb's concerns that allowing mass gallery-to-category redirects is primitive and creates a larger (and more complicated) mess in the long run. If we really need something of that nature, we might as well get the software modified. Galleries and Categories are two entirely separate namespaces; we shouldn't treat it as opposite sides of the same coin. Rehman 07:44, 5 May 2018 (UTC)
User:Rehman, This could be about grandfathering and protecting the small number of existing redirects. Speedy deleting them breaks blue links which are not being repaired. Or, if the existing blue links were modified to link to the categories before the redirects were deleted, I would have much less problem with deleting the redirects. Also, instead of simply deleting the old guideline [2], perhaps the guideline could mention that such redirects were formerly allowed, but have been deprecated due to changes to Wikimedia software. After all, the guideline has been there since at least 2009. --Robert.Allen (talk) 14:10, 5 May 2018 (UTC)
For instance, the modification could read something like this: "Existing redirects of gallery titles to corresponding categories are not subject to deletion until all incoming links have been modified to link to the target category." --Robert.Allen (talk) 14:42, 5 May 2018 (UTC)
User:Rehman, this does not have to be about creating lots of redirects where they don't exist -- just not deleting the ones which have been there a while. For many topics, say France or Marseille, we have a curated gallery which is a much better introduction to a topic than a category. For those, the links from the Wikipedia articles are best sent to the galleries, not the category. The fact that Wikidata can't do that is a technical limitation and means that Wikidata is not as functional as it could be. There are times in the past where the category became better than the gallery, and so the gallery was turned into a redirect. We should *not* be breaking links in other projects and then tell them to go fix them, when they were not broken to begin with -- we should be supporting what the other projects have. The policy could simply be that creating new redirects is discouraged, but redirects should not be speedy deleted if they have existed over X amount of time, or were previously a legitimate gallery, or have existing links from other projects. I don't have an issue speedy-deleting a newly-created redirect which was never a gallery and does not have links from other projects. Carl Lindberg (talk) 14:50, 5 May 2018 (UTC)
Hello Robert and Carl. Thanks for the descriptive response. Yes you are correct; my oppose is only for creation of new redirects, and not supporting the deletion of existing/old ones that were once a valid gallery. Your suggestions to amend the text in existing policy/ies to reflect this view makes sense.
Separately (i.e. no impact to this discussion), I will try and see if we could get a bot to do a scan, to figure out how many gallery-to-category redirects are in existence. Just to get an overview of scale of the situation. At the same time, it may also be helpful to keep an eye on Commons:Structured data, which may or may not impact gallery/category relationships.
Furthermore, with regards to Wikidata not being able to link to Galleries, it can be done :) The gallery page should be entered on the right panel instead of in statement format (in this example, a gallery could be linked by replacing the category link added in the sidepanel). Best regards, Rehman 04:22, 7 May 2018 (UTC)

Gallery DAB pagesEdit

Jcb (talk · contribs) has deleted some gallery DAB pages, with the reason of being "single image or empty", they then said that they don't belong in the gallery namespace, I don't see why not, isn't that just like how DAB pages work on WP. Note that on WP, w:WP:A1/w:WP:A10 doesn't apple to DAB pages. Crouch, Swale (talk) 10:50, 4 May 2018 (UTC)

It is indeed how it works on Wikipedia, but you are here on Commons, not Wikipedia. Note that a recent UDR for such a DAB in wrong namespace was closed as 'not done'. Jcb (talk) 10:54, 4 May 2018 (UTC)
Where is that request, and how do we get people to the galleries, what should be at Columbus, should it redirect to Christopher Columbus or Columbus, Ohio then? Crouch, Swale (talk) 12:33, 4 May 2018 (UTC)
That request is here. There is no need for Columbus to be a blue link. The DAB is where it should be: Category:Columbus. Jcb (talk) 12:38, 4 May 2018 (UTC)
Then how do we DAB the galleries, I can't see why there shouldn't also be a DAB in the gallery space, just like at WP, the DAB at Category:Columbus (which I created) is for the categories. Crouch, Swale (talk) 12:43, 4 May 2018 (UTC)
We do not DAB the galleries. Galleries are there to help presenting the files we have on a specific theme. They are not there for naviation purposes. Christopher Columbus can be reached from Category:Christopher Columbus. At en:Christopher Columbus in the left menu there is a link to Category:Christopher Columbus in the 'in other projects' section. Jcb (talk) 14:34, 4 May 2018 (UTC)
How else do we index them then? Wikipedia has a DAB at w:Columbus and at w:Category:Columbus. I think that we need to review how we deal with categories and mainspace DABs, that is do we include links to categories on mainspace DABs. Crouch, Swale (talk) 06:40, 6 May 2018 (UTC)
Commons does not have 'mainspace' like Wikipedia. They namespace without prefix is gallery namespace. Jcb (talk) 10:37, 6 May 2018 (UTC)
If there are several disambiguated galleries a DAB mage must exist under the unqualified name, otherwise they can't be found under the basic name and will create disputes over which one to have under the unqualified name, Mercury for example. Which one should be there? Crouch, Swale (talk) 08:07, 18 June 2018 (UTC)
Gallery pages are found from the category. Navigation goes via categories at Wikimedia Commons. Jcb (talk) 14:40, 18 June 2018 (UTC)
Return to the project page "Criteria for speedy deletion".