Jump to content

Commons:Village pump/Proposals

Add topic
From Wikimedia Commons, the free media repository

Shortcuts: COM:VP/P • COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Proposals/Archive/2026/08.

COMMONS DISCUSSION PAGES
Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?

 

Start a new discussion

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 5 days and sections whose most recent comment is older than 30 days.

Restrict category creation to registered users

[edit]
Latest comment: 2 days ago26 comments13 people in discussion

Why is it that unregistered users are allowed create category pages without restriction? File uploads are limited to registered users and yet category creation remains fully open, despite being a high-impact action that serves as the foundation of Commons' organizational structure. Categories are the primary way to organize and find files on Commons and are much harder to patrol at scale when created anonymously. The current system we have relies entirely on subsequent patrolling and maintenance by editors rather than prevention. But from what I am seeing on my end, that cleanup is not actually occurring. The categories simply remain. Regardless of how much they clutter the system and actively make it harder for readers to find meaningful media. The sheer scale of category creations makes maintenance extremely difficult to impossible. And unlimited IP/temporary account creations are not serving the project to that end. There was a similar proposal in 2024: Commons:Village_pump/Proposals/Archive/2024/06#Prevent_IP_addresses_from_creating_categories, to which Jmabel reponded:

I'd first want to see evidence that, in general, IPs are bad at creating categories, not that one person bad at creating categories happened to be editing without logging in.

Well, firstly, I disagree with the premise that this can be simply quantified in the form of some illusive, concise summary proving what IPs "generally" do. Even if individual edits vary widely, as I'm sure they would even for file uploads if unregistered users were permitted to do so, the underlying issue is still the maintenance burden and editor accountability. Secondly, I disagree because there is one user who has singlehandedly splintered the festival topic area on Commons into literally thousands of excessively narrow categorization layers that make navigating media harder not easier. And they purposely do this while logged out, which they have admitted is a deliberate act of deception in order to gratify their personal project of creating so many subcategories, which they say is caused by their autism and OCD. And they have not stopped to this day, despite repeatedly suggesting they had committed to doing so. 3x blocked on Wikipedia and miraculously not blocked on Commons despite a truly endless backlog of tendentious, soft disruption and sockpuppetry.

For context, read:

As I wrote to them on my talk page:

Not every event should be divided into categories for every moment of that event. This level of subdivision is excessive and unhelpful. Most images depict the same group of people together at the event, so splitting them into these extremely narrow categories clutters categorization rather than improving it. It makes finding relevant images harder, not easier. Commons categories are designed to help users navigate a collection of media files efficiently without fragmenting the content unnecessarily. Not every event or group of people needs its own sub-subcategory, especially when the visual content overlaps heavily. These overly specific categories are really just serving what has clearly been your personal categorization project here rather than the broader Commons userbase. Wikimedia Commons is not a personal archive. Categories should reflect meaningful groupings. Not any one editor's detailed breakdown of every event moment or participant. They should be kept simple, consistent, and easy to understand. Please reconsider this approach and focus on categories that genuinely help users find images without excessive fragmentation. Because I am honestly having a problem with these categories you created. Look at all of the [People at event] categories you created like Category:People at the 2025 Cannes Film Festival. All of the files in the parent Category:2025 Cannes Film Festival are already people at the event. The entire category consists of attendees, which makes this level of categorization useless and then results in this incomplete and even at times circular levels of categorization. When you have countless categories and subcategories for "events", "premiere", "photocall", "press conference", "panel" etc etc etc then other high-level strands like "People at" you then require a level of intersection that just contains all the same files. You are making users click through many layers to find images that are often very similar or even identical in content. This is outrageous and needs to stop. I completely understand the mindset that led you to make these, but it has not helped navigation. For example, I see no reason why a file like Dakota Fanning, Kristen Stewart 16.jpg needs any more categorization than Category:The Runaways screening at South by Southwest 2010 and Category:Dakota Fanning in 2010 and Category:Kristen Stewart in 2010. And often times, the screenings and other sub-"events" categories you have created contain so few files that there's really no reason to even create them in the first place. Commons is not intended to mirror the structure of a festival schedule, press packet, or red carpet lineup. Overcategorizing by every appearance, panel, or moment at an event turns Commons into an overly literal recreation of event programming rather than an easily navigable collection of media files grouped by the clearest visual attributes and most useful contextual non-visual attributes. These deeply nested categories serve you rather than Commons users, and create a significant maintenance burden for other editors. Cleaning up, merging, or navigating these structures takes time and effort that could be better spent improving actual file data, descriptions, or correcting errors. It would be more effective to limit event-related subcategories to clearly distinct and well-populated groupings, like a major press event or photocall if there are enough files to justify it. At this point, many of these categories probably need to be reviewed, merged, or deleted. If you're serious about improving Commons, then we need to start by going back through these all of these over-nested categories, all of which you deliberately created only through IP hopping sockpuppets, and seeing which ones actually serve a purpose and which can be rolled back.

to which they responded

"I stand by what I did."

and

"You're right. It actually does serve me."

I agree a single case isn't "evidence" on its own, but this ability is granted universally to all unregistered users, not just one individual. And I'm not proposing restriction based on a single case. We should be doing so based on the inherent difference between registered accounts and unregistered ones. The latter makes it harder to evaluate patterns of behavior in category creation at scale and only adds to the workload that is frankly not even being done. And if file uploads are limited to registered users due to abuse and maintenance concerns, then what exactly is the rationale for treating category creation differently when categories can also be spammed, misused and require ongoing cleanup from a system that is honestly slow as molasses? There is only so much attention that can be paid to the millions of corners of this website. So how exactly does unrestricted category creation serve the users attempting navigate the massive media library here or the editors working hard to maintain it for said users? Οἶδα (talk) 23:11, 16 June 2026 (UTC)Reply

We should not ban temp accounts from creating categories. We should just ban them entirely. We do not have the capacity to patrol their edits and need the capacity for more important tasks. GPSLeo (talk) 04:47, 17 June 2026 (UTC)Reply
@Οἶδα: it's late here, and I'm tired, and that was long, so maybe I misread, but at a quick read you seem to be saying that temporary accounts should be banned from creating categories because a user who is not a temporary account (or, perhaps, several such users) is (/are) overly splitting categories by date. (FWIW, I agree that overly splitting by date is bad.) If that is what you are saying, then the logic escapes me. What does this have do do with whether TAs can create categories? - Jmabel ! talk 07:14, 17 June 2026 (UTC)Reply
No, I am not suggesting that restricting category creation to registered users will completely fix the instance I outlined above and stop registered users from excessively splitting. Nor did I say that it should be the basis for restricting unregistered users. It is simply an extreme example of a user whose unregistered category creations number in the thousands and have become impossible deal with let alone track down. You are free to skip over that example. Because I believe the rest of what I wrote made it clear that I am not saying what you've condensed my post down to. As I said, we should be doing so based on the inherent difference between registered accounts and unregistered ones. The latter makes it harder to evaluate patterns of behavior in category creation at scale and only adds to the workload that is frankly not even being done. How does this help the project here?
There is great inconsistency that exists throughout the category system, as categories are rapidly created by anyone and everyone, at any name they choose, with little done to maintain them, and to an unfathomable degree if we're being honest. It feels insulting as someone involved in improving categorization on Commons to be routinely confronted with a scale of unhelpful categories that I am unable to remedy. Especially from the onslaught of users who are simply duplicating encylopedic categorizations from corresponding categories on English Wikipedia. Any amount of progress I could make feels as if it is easily offset by all of the categories being created all the time. The category system here is like a wild west that is endlessly large and not exactly attended-to, to say the least. So I'll ask again: how exactly does unrestricted category creation serve the users attempting navigate the massive media library here or the editors working hard to maintain it for said users? Do we honestly believe that we have the capacity to patrol all of these creations, let alone actually merge/delete/rename the ones that require it? When Commons:Categories for discussion is so backlogged to the point of outright uselessness? It is a black hole where things go to sit for literally years. So is there an articulable reason for why file uploads are limited to registered users and yet category creation remains completely unrestricted? Οἶδα (talk) 08:18, 17 June 2026 (UTC)Reply
  1. i think everything is unrestricted except file uploads are restricted.
  2. "I disagree with the premise that this can be simply quantified..." ofc it can be quantified. someone could show the monthly stats how many categories were created by ip/temp accounts, and how much percentage of them were deleted. even better would be, do the same for registered users and compare the two.
  3. https://commons.wikimedia.org/w/index.php?title=Special:Contributions&end=&namespace=all&newOnly=1&start=&tagfilter=&target=85.115.0.0%2F16&offset=&limit=500 indeed, many of these intersection cats (crossing a person and an event, when the number in each is tiny) are useless. all these files should just be put under 2 separate cats for the person and the event.
  4. from my experience, i've not seen such massive bad categories from ip/temp, but rather quite often from certain registered users. it might be just the area i work with. maybe your area has more problems from ip/temp. some stats will show us if it's really a problem for all ip/temp.
RoyZuo (talk) 10:38, 17 June 2026 (UTC)Reply

someone could show the monthly stats how many categories were created by ip/temp accounts, and how much percentage of them were deleted

I feel like this implies a level of attention and swfit handling that is simply not happening in the world of categories on Wikimedia. Because so much of the unhelpful categorization added here is not obvious spam but rather overfragmentation that requires deeper consideration of the available media and comprehensively collecting together for upmerging. Unless I am sorely mistaken, and I don't believe I am, I don't see that meaningfully being taken on. As I said above, that cleanup is not actually occurring. The categories simply remain. They are not being deleted as you say. So that cannot be accurately measured in that way.

indeed, many of these intersection cats (crossing a person and an event, when the number in each is tiny) are useless

And that is all from before the Checkuser/AN discussion. They have not remotely stopped. I have no way of tracing all of these categories Timmy96 creates because they are spread across the entire project and only discoverable upon clicking through deeply nested categories. I can only come across one by chance and notice the temp account history. Such as ~2026-34854-38 (talk · contribs) and ~2026-26281-63 (talk · contribs). And so I just give up.
But again, I'm not saying it will stop registered users from excessively splitting categories. But unregistered accounts having the ability absolutely makes it harder to evaluate patterns of behavior in category creation at scale and only adds to the workload that is not even being done. So I'll ask again: how exactly does unrestricted category creation serve the users attempting navigate the massive media library here or the editors working hard to maintain it for said users? Do we honestly believe that we have the capacity to patrol all of these creations, let alone actually merge/delete/rename the ones that require it? If the answer is no, then why are we actively making it even harder for ourselves to improve the project here? If only "massive bad categories" that are obvious spam from IP/temps rises to the level of considering adding a restriction upon category creation on Commons then I may as well be done. If that is where the bar is set, then perhaps I should accept that this issue is simply not one that Commons is interested in addressing. Because obvious spam is easily detectable. Unhelpful, excessive categories that actively worsen navigation between the collection of media here are far far far more insidious and damaging to overall navigation here. And much harder to deal with. Οἶδα (talk) 19:10, 17 June 2026 (UTC)Reply
I think you also have to realize that your proposal will also block good constructive category creations from temp accounts. So that is why it is important to do a research/analysis on the percentage of "good" and "bad" category creations from temp accounts. This allows us to decide whether your proposal is worth it to "sacrifice" the good category creations.
For example, let's say 70% category creations are good and 30% are bad, then I would say your proposal can be considered. But, if 99% of them are good, and only 1% are bad, then your proposal might not be worth it. Thanks. Tvpuppy (talk) 22:35, 18 June 2026 (UTC)Reply
Then I think you also have to realize that restricting file uploads already blocks "good constructive" creations from temp accounts. That is not reason in itself to not apply a restriction. And I'm suggesting that the metric being proposed to "research/[analyze]" this is ultimately flawed and impossible to actually account for "good" and "bad" in such a way. Most cats are not obviously "bad" to the point of swift deletion. They are structurally redundant, duplicative, or excessive. That is not something you can easily classify in a simple percentage metric, yet all of it causes an incredible amount of clutter on Commons. A large number of individually "valid" but excessive or redundant categories still actively harm the project when they fragment topics beyond what the community is realistically able to maintain and remedy. Meaning they simply remain. And even if we assume a high proportion of constructive edits from IP/temp accounts, that doesn't change the core issue being the impossible maintenance workload needed to correct that navigation hindrance and our inability to actually identify problem category creations when they are spread across the entire project and across a horde of disparate IPs/temps. So it's less about "Are unregistered users worse than registered users?" but rather "Is the unrestricted creation of categories something we are actually able to patrol and correct at scale under current maintenance conditions?" Because, as of right now, the obvious answer appears to be no, regardless of who is creating them. But as I said: unregistered accounts having the ability absolutely makes it harder to evaluate patterns of behavior in category creation at scale and only adds to the workload that is not even being done. Does anyone actually disagree with that? No? So then why are we actively making it even harder for ourselves to improve the project here when it's already completely swamped...
I do not believe the "sacrifice" could ever be that big when category creation is so impactful and registration is so easy. Is it so much to ask that category creation, which remains the primary way to find and organize files on Commons and is therefore arguably as consequential as the file creation (which is restricted), be attributable in a way that actually supports meaningful oversight and cleanup across the project? Οἶδα (talk) 05:54, 20 June 2026 (UTC)Reply
Wait, could it be that the restriction of file uploads to registered users is not solely because of disruption, but also because of issues with attribution? It's way less ideal to credit an image to a random string of numbers, and makes it harder or even impossible to reach out and negotiate or clarify licensing terms when people are anonymous. This is technically true for text, but you can always rewrite text to rid of copyright issues. Can't do the same with media that easily. HyperAnd [talk] 08:56, 20 June 2026 (UTC)Reply
my personal habits now: dont care whether a category is redundant, or has a weird title.
because, com:cfd is nearly broken. the direct consequence of wiki's "consensus building" is a time sink. cfd cannot effectively deal with any sorts of problems or disagreement. and it wastes a lot of time. so i avoid sending categories to discussion or deletion.
more importantly, i have pretty good tools that let me browse and find files about any topic, so i dont give a shit about problematic categories.
take a look at Help:Gadget-DeepcatSearch, for which i have plans to greatly expand its functions.
utilising mw:Help:CirrusSearch, particularly deepcategory, incategory, insource, nearcoord, filetype, filesize, filewidth... when i want to look at any topic (be it a location, a person, an event), i go to its category page, and from there i do a search instead of expanding and clicking the subcats. RoyZuo (talk) 15:18, 20 June 2026 (UTC)Reply
grim but true Οἶδα (talk) 04:07, 20 July 2026 (UTC)Reply
Category PAGE creation ? or category creation ? Because a category is just a specific link on a page and exists eternally. They do not require having contents and do not require having a page. Deleting a category is just the process of emptying it and deleting the page associated with it, but the category technically keeps existing and you can immediately add something to it again. In that sense, you cannot disallow creation of categories similar to how you cannot forbid people to insert any other type of redlink. —TheDJ (talk • contribs) 12:16, 17 June 2026 (UTC)Reply
with regards to the concerns by TheDJ: Category page creation could be restricted. But I see little sense in doing so for IP users: the most prolific category-splitters are in my experience long-time autoconfirmed users. Sometimes, I notice category splits into basically atomized categories, which I consider a bad idea, since I like lumping as long as there are no patterns that require a split-off. But that does not mean that my view on the matter is necessarily correct in all cases. If IP (or new) users have a good idea about creating a category, why not allow them? We already have the latent practice that experienced users may just abolish and redirect/delete "bad" categories that were created by IPs, without the need of an CfD. If that practice is not allowed by the rules, the rules should be changed to codify the practice.
... Redlink creation needs to remain. Either, the redlinked categories do make sense, and patrollers/confirmed editors can then go on and create the page. Or, the redlinked categories are already existing under a different name, then it can be considered to create a category-redirect. Or, the redlinked categories make no sense, but even then they can be replaced with the correct category. We need to allow assigning redlinked categories, to everyone.
... The idea of banning temp accounts altogether appears to be a bit too radical in my opinion - Commons should remain open. --Enyavar (talk) 13:55, 17 June 2026 (UTC)Reply
The primary function of Commons is uploading files, and that has always (AFAIK) required registration. I don't think it's particularly radical to propose that other secondary functions of the site require registration as well.
Creating redlinks to categories isn't something which we have the ability to technically restrict without preventing users from editing at all (which I don't think is on the table); by "category creation", what I think TheDJ implicitly means is indeed category page creation. Omphalographer (talk) 19:07, 17 June 2026 (UTC)Reply

Category PAGE creation ? or category creation ?

Category PAGE creation. Adding a category to a file is not the same as creation of that category Οἶδα (talk) 18:22, 17 June 2026 (UTC)Reply
A weary  Support. The current state of affairs is that, from a procedural perspective, it is dramatically easier for users to create category structures (e.g. creating category pages and populating those categories) than for other users to abolish those categories. We've seen repeated waves of bad category creations by IPs / temporary accounts in certain topic areas involving fictional characters and children's film and TV series. While these changes certainly could be made using a registered account, the use of multiple temporary accounts makes it much more difficult to identify which categories were affected and revert the changes. One typical example from a few years ago was Commons:Categories for discussion/2024/05/Category:Films by character. Omphalographer (talk) 20:01, 17 June 2026 (UTC)Reply
Perhaps tangential, but what if category names were checked against a regex at time of creation in a similar manner to how the upload wizard stops you from uploading 'DSCN1011.JPEG'? That wouldn't cover all overcatting, but specific name antipatterns could be restricted. Arlo James Barnes 17:44, 23 September 2026 (UTC)Reply

The problem will not be solved by exchanging a few opinions and leaving the matter there. It is no less an issue. What can be done? Οἶδα (talk) 04:23, 7 August 2026 (UTC)Reply

I guess nothing Οἶδα (talk) 20:12, 18 August 2026 (UTC)Reply
There has to be something. Οἶδα (talk) 19:54, 27 August 2026 (UTC)Reply
Still relevant Οἶδα (talk) 20:41, 8 September 2026 (UTC)Reply
I want to keep this alive and moving forward somehow Οἶδα (talk) 04:45, 23 September 2026 (UTC)Reply
 Support I don't think anonynous edits should be disabled entirely, but I do think that page and category creation should only be possible with an account, just like on Wikipedia, as page creations here are almost useless compared to Wikipedia, while still allowing trolling. Dabmasterars [EN/RU] (talk/uploads) 16:25, 23 September 2026 (UTC)Reply
 Agreed! -- Tuválkin ✉ ✇ 19:16, 23 September 2026 (UTC)Reply
 Support - Ooligan (talk) 20:01, 3 October 2026 (UTC)Reply
If we can agree on this, how do we advance it into practice? Οἶδα (talk) 17:58, 30 September 2026 (UTC)Reply

No longer allow some CC 1.0 or problematic licenses for new licensing

[edit]
Latest comment: 4 hours ago60 comments23 people in discussion

7 years ago, we disallowed GFDL only for new uploads; should we ban some problematic Creative Commons licenses?

This proposal is intended to ban

Thanks. JaydenChao (talk) 07:23, 29 June 2026 (UTC)Reply

 Support That these should be deprecated or discouraged. ―Justin (koavf)❤T☮C☺M☯ 13:27, 29 June 2026 (UTC)Reply
 Question What is the actual problem with these licenses that is considered sufficiently serious that we should reject otherwise acceptable works solely because they are released under them? I understand why GFDL was deprecated for new uploads, as it creates practical and legal complexities. However, licenses such as CC BY-SA 1.0 seem relatively harmless in comparison. We already do not encourage their use through our upload tools, so what practical issue would be solved by outright refusing new uploads (not just new "own works") under these licenses? Is there a concrete legal or operational problem that these older CC licenses create, or is this primarily about encouraging the use of newer license versions? --Jonatan Svensson Glad (talk) 13:48, 29 June 2026 (UTC)Reply
Unfortunately, some of the wording in earlier CC licenses creates loopholes and vagaries that can result in some bad outcomes. See Commons:Copyleft trolling and in particular, Commons:Copyleft_trolling#Forced_watermarking for a very specific example. ―Justin (koavf)❤T☮C☺M☯ 13:55, 29 June 2026 (UTC)Reply
There's also a problematic clause in all versions of the CC 1.0 and 2.x licenses: "You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement." Depending on how one interprets this clause, it could be understood to prohibit uses of CC 1.0/2.x media which would otherwise be permitted, e.g. displaying them on a password-protected web site or distributing them in an encrypted archive (both "technological measures which control access"). This clause was removed in CC 3.0. Omphalographer (talk) 22:46, 1 July 2026 (UTC)Reply
CC BY-SA 1.0 doesn't have a compatibility mechanism, so derivatives of a BY-SA 1.0 licensed work must be licensed under that exact license, not BY-SA 4.0. Qzekrom (talk) 15:58, 10 September 2026 (UTC)Reply
  •  Support to discourage the use of CC-1.0 for all new contributors uploads but we should only have an exception for works that were licensed CC-1.0 at a time then CC-2.0 didn’t exist or not yet in mainstream use. As a free-use repository, can we ban a free-use license? Bidgee (talk) 16:14, 29 June 2026 (UTC)Reply
 Strong oppose First of all you have given absolutely no reasons at all in this proposal. CC-SA without BY is important to provide a sharealike license without attribution which is more free and CC-SA and other licenses without BY was retired not because of any actual problems with them but because of "Inadequate demand". There are more than 4,500 files in Category:CC-SA-1.0 and there was no solution suggested to provide for that situation.
If you want an actual problem with the 1.0 CC licenses it is that they contain a warranty from the licensor that they own all rights which can be dangerous and it doesn't have "later version" clause. However there was a discussion 5 years ago and there was no consensus to deprecate it and more importantly {{Cc-sa-2.0-jp}} is the solution to this problem as it is 2.0 version license that fix the above 2 problems and probably should be compatible with CC-BY-SA 3.0 and 4.0. No one has given a single problem with {{Cc-sa-2.0-jp}} and there is absolutely no reason not to accept it. If it was to be deprecated it should be only if a new share alike license without attribution was created. 999REAL 💬 ⬆ 16:30, 29 June 2026 (UTC)Reply
Why is the Japanese licence (which CC withdrew over twenty years ago) any better? Andy Dingley (talk) 17:40, 29 June 2026 (UTC)Reply
1.0 CC licenses contains a warranty from the licensor that they own all rights which can be dangerous and they don't have "later version" clause. {{Cc-sa-2.0-jp}} is a 2.0 version license and fixes these 2 problems in the text of the license. Again, it was retired not because of any actual problems but because of "Inadequate demand" 999REAL 💬 ⬆ 18:02, 29 June 2026 (UTC)Reply
But why the Japanese version? Is this just because the Japanese set preserved a CC-sa into 2.0, when others retired it after 1.0? It was dumped and never added to CC 2.0, but for some arcane reason beyond my knowledge, the Japanese team were slow to action this, so they had preserved its existence.
If you compare the deeds though, they're identical between 1.0/en and 2.0/jp
We can take these as a reasonable statement of intent by CC as to the meaning of these two licences.
There are differences between the legal code statements of the two licences. These are the full definition of their licence.
Most obviously, they are not simply translations. In particular, 2.0/jp shall be interpreted in accordance with Japanese law. I don't have a translation of the Japanese legal code, but if there's some specific aspect of it that you see as relevant, perhaps you can point us to it? Andy Dingley (talk) 19:10, 29 June 2026 (UTC)Reply
  • Do we have any CC 1.0 licences? Do we have new ones arriving? Of these 'new' ones, how many are new to us, but their licences are old enough to be reasonable legacies from the CC 1.0 era? Without being able to answer even this much, I can't see any case to be talking about banning anything. Andy Dingley (talk) 17:39, 29 June 2026 (UTC)Reply
  •  Oppose for multiple reasons – I've yet to see past threads raising an issue about (mis)use of the v1.0 licenses themselves similar to GFDL. Also, there was no consensus to deprecate the 2.0 JP at the moment, and I don't see that happening soon. Also, I've yet to see evidence of such licenses becoming frequent tools for copyleft trolls to use. Furthermore, even when proven, the banning of GFDL has left wary copyright holders with no other alternatives except CC 1.0 versions. Let's not favor this at this time. —George Ho (talk) 19:11, 29 June 2026 (UTC)Reply
CC 1.0 licenses for new works (not new uploads) could be disallowed, there's no good reason to license new works with a 1.0 license.
The question is: is anyone actually using these in 2026? GFDL was being abused as a kind of BY-NC/ND backdoor. (not everyone who used it did so in bad faith, for example, some small wikis had failed to update their default license setting decades ago) Who uses CC 1.0 today? - Alexis Jazz ping plz 20:18, 29 June 2026 (UTC)Reply
How often the v1.0 licenses have been used or popular they've been especially recently should not be a major or the sole reason to favor or oppose the proposal. They're still used somewhat or somehow, but other than potential misuse by copyleft trolls, deprecating the licenses for being seldom used anymore would be, IMO, prejudicial. George Ho (talk) 20:45, 29 June 2026 (UTC)Reply
 Comment if we just do something about {{CC-BY}}, {{CC-by}}, {{CC-BY-sa}} and {{CC-by-SA}} (why are they different from {{CC-BY-SA}} and {{Cc-by}}?) that'll probably solve most of the problem. When searching for recent files, that's what I mostly stumble upon. - Alexis Jazz ping plz 08:36, 30 June 2026 (UTC)Reply
 Support, see Commons:Deletion requests/Template:Cc-sa-layout.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:22, 30 June 2026 (UTC)Reply
  •  Oppose. The licences are sufficiently cromulent. Even the SA ones. Banning them serves to reject a class of free works belonging to or representative of the culture of innocent people, based on the antisocial choices of a few people, and the aversion to conflict of a few others. (There are some detailed issues with CC PD that bear discussion separately, but I'd oppose until that plays out.) Fine to gently discourage the use of these without fearmongering or badgering. TheFeds 10:12, 14 July 2026 (UTC)Reply
 Oppose in strongest possible terms. Being overly restrictive is not helpful. PARAKANYAA (talk) 07:48, 18 July 2026 (UTC)Reply
 Oppose The 1.0 versions are not great because they don't allow cross-usage in derivative works with files using later CC versions, but it's still a perfectly free license and doesn't have near the ramifications or issues that GFDL does. It's certainly discouraged and not recommended, but I see no reason to fully deprecate it. Don't think it's really subject to abuse. Carl Lindberg (talk) 15:05, 31 July 2026 (UTC)Reply
Conditional  Oppose unless Creative Commons org explicitly tells every platform in the world (Wikimedia, Flickr, government websites, et cetera) to stop using these licenses in the strongest sense. In other words, global deprecation in all four corners of the world. CC itself retiring these licenses, but not mandating every platform to deprecate global usages of those, isn't an indication for Wikimedia Commons itself to axe these licenses. JWilz12345 (Talk|Contributions) 04:12, 30 August 2026 (UTC)Reply
 Strong oppose @JaydenChao, There is almost no need of depreciation or banning any of these mentioned retired creative commons. Just put info at the top mentioning "The CC-BY-1.0 license is officially retired by Creative Commons. So, Use of CC-BY 4.0 instead for new upload is appreciated while the older uploads can remain licensed with CC-BY 1.0." Abdullah1099 (talk) 07:04, 11 September 2026 (UTC)Reply
 Oppose unless a good reason for this will be demonstrated. Arguments for case of GFDL (full text of the license and others) isn't applicable for CC licenses. But FAL contains requirement to provide full text of the license, so why not FAL? Evelino Ucelo (talk) 22:14, 5 October 2026 (UTC)Reply

CC 1.0 template cleanup

[edit]

This should prevent accidental use of ancient licenses. - Alexis Jazz ping plz 19:00, 1 July 2026 (UTC)Reply

 Support, with a maintenance template. If a user uploads a file and does not specify which version of a Creative Commons license they have applied to it, we should not state that they used a specific version of that license, and we should certainly not assume that they meant a version of that license which was superseded over 20 years ago. Omphalographer (talk) 22:33, 1 July 2026 (UTC)Reply
 Oppose; we should instead assume the current version of the license they mention as of the date of upload.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:49, 2 July 2026 (UTC)Reply
Jeff G., do you mean for existing files or future uploads, or both?
It seems more reasonable, but especially for existing files I think that's a legal problem. We don't actually know the intention of those uploaders. What if after uploading a file using that redirect they saw the 1.0 license on their file and thought "yes, this is the license for me"? We can't change the license after the fact. There's also a technical issue: I wouldn't even know how to filter by upload date. As far as I know, there's no practical way to do it. Even if there was, crops and imports couldn't be detected correctly. Asking uploaders to change the license version on their files (or give us permission to change it for them) may yield some results for existing files though.
For future uploads, I think the warning template is better. On the warning template, the sentence If you intended to use the original Creative Commons Attribution 1.0 license, replace "cc-by" with "cc-by-1.0". could be removed or relegated to the fine print. - Alexis Jazz ping plz 15:22, 2 July 2026 (UTC)Reply
Agreed. There is legal significance to a user choosing a license for their uploads; we cannot guess at their intent. Omphalographer (talk) 18:10, 2 July 2026 (UTC)Reply
@Omphalographer and @Alexis Jazz: 18 years ago, we embarked on a journey with Commons:GFDL 1.3 relicensing criteria that saw many files relicensed. Could we do something like that again?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:23, 2 July 2026 (UTC)Reply
No, we could not. The GFDL relicensing project relied upon users having chosen to license content under "GFDL 1.2 or later", and the FSF releasing a new version of the license which allowed migration. There is no equivalent practice in Creative Commons license grants. Omphalographer (talk) 18:55, 2 July 2026 (UTC)Reply
Correct. There's no "or later" in CC 1.0. - Alexis Jazz ping plz 19:12, 2 July 2026 (UTC)Reply
 Comment I would personally think that this does not require any type of concensus if done correctly. The first two bullets replace a redirect with the target. That's usually not needed, but should be uncontroversial. Uploaders did not lack to add a license version. They used version 1.0 through the redirect. If they are no longer used, they can be repurposed, like redirected to another warning template. --Schlurcher (talk) 21:05, 2 July 2026 (UTC)Reply
We have nothing (AFAICS) with a CC-by on it: Category:CC-BY Everything is already in some versioned sub-version of this.
Category:CC-BY-1.0 9k of these
Category: CC-BY-1.0+ (from {{Cc-by-4.0,3.0,2.5,2.0,1.0}}) 1,200 of these
Category:CC-BY-3.0,2.5,2.0,1.0 (but not 4.0) 19k of these
Andy Dingley (talk) 09:56, 15 July 2026 (UTC)Reply
Andy Dingley,Will you sort them by date? - Alexis Jazz ping plz 11:01, 15 July 2026 (UTC)Reply
What are we trying to do here? What can we do? (i.e. what's permissible by policy, regarding changing existing licence offers)
The OP posted about licences, and the desire to remove CC 1.0 licences from use. We now seem to be talking about templates, i.e. the means we use to attach those licences to content. These are often unclear, some of these templates are offering licence versions that aren't named in the template call.
So of these, which are we really trying to change? The licences? Or the markup used on image pages? Can we and how far (by our policy restricting this) change the effects of previously applied (but non-specific) templates to restrict or update the versions being attached? Andy Dingley (talk) 22:25, 15 July 2026 (UTC)Reply
On the topic of templates, we have to be conservative with relabelling ambiguous CC BY with CC BY 1.0: for what period did uploaders and licence holders (note those are different!) have constructive notice that CC BY 1.0 was the only possibility? Same goes for CC BY-SA, but possibly with different dates of notice. And beyond that, not much can be done because we don't know what we don't know about the licence. Prohibiting 1.0 is orthogonal to this and won't solve it. TheFeds 23:55, 16 July 2026 (UTC)Reply
I attempted to see whether there were any files uploaded during the period when CC [something] 1.0 licences were the only possible versions—so that we could retag with that justification. CC BY 2.0 originated prior to 2004-06-07. This is a list of the 724 {{CC-BY}} tagged files, and this is the list of the 452 {{CC-by}} files, with oldest creation first. None of them predate CC BY 2.0. We're probably going to have to look up the upload/transwiki history from (mainly) English Wikipedia to find any. TheFeds 20:48, 21 July 2026 (UTC)Reply
        • Can we draw a line in the sand (a point in time) after which unversioned such licenses shall be construed as "the latest version"?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 20:40, 14 July 2026 (UTC)Reply
          If implemented, that point has to be in the future, and only once we adjust the interface to give uploaders notice of that fact. We don't know if someone chose 1.0 (when 2.0 was out) because they prefer something about it, because they didn't yet know a revision existed, or because they didn't even know that licences had versions. And we therefore don't know what their willingness to relicence would be. It's basically copyfraud for us to bait and switch. Also, I know we like CC, but if they do something like GPLv3, automatically choosing the latest version might have serious consequences. TheFeds 23:45, 16 July 2026 (UTC)Reply
  •  Support. {{CC-BY}} redirects to {{CC-BY-1.0}}, and every time the former has been entered on a file, it is the latter license that has been applied, even if the user simply chose {{CC-BY}} out of laziness of not picking a number. It's perfectly reasonable to replace the former with the latter.
    And since we don't want to encourage 1.0, I think it's a good idea to effectively deprecate {{CC-BY}} as a valid license tag and replace it with some kind of warning, instructing the user to choose a version (preferably the most recent version). I'm surprised to see that the warning already exists at {{Cc-by}} - another good reason to do this is to align the outputs of CC-BY, Cc-by, etc - these differences in capitalization should not have different outputs. -Consigned (talk) 00:37, 22 July 2026 (UTC)Reply
  •  Support redirecting the ambiguous-version templates to warning templates. It looks like CC-BY and CC-by were renamed/redirected to 1.0 in 2005, and that is the version that users would see when uploading ever since, so I have no problem converting all existing usages of those to 1.0, and redirecting the templates to the warning version. {{Cc-by}} is already that way. {{Cc-by-sa}} is already a warning template. {{CC-BY-sa}} started life as a redirect to 1.0, and after this discussion started, redirected to the warning template -- I would have assumed that any existing usages should have been explicitly changed to 1.0 before making that change. Likewise, {{CC-by-SA}} seems to have *always* been a redirect to 1.0. So all of these steps seem reasonable -- since 2005, anyone uploading with those ambiguous versions would have seen 1.0 on the upload page. Are there new usages of these templates *since* they were redirected to warning templates? I suppose that may be a risk with files transferred from other wikis that were using that tag name there; unsure of the histories of that template name on the other wikis. Carl Lindberg (talk) 15:05, 31 July 2026 (UTC)Reply
  •  Support: we need to clear up these ambiguous templates. – Howardcorn33 (💬) 09:46, 5 August 2026 (UTC)Reply
  •  Question How many users are accidentally choosing {{CC-BY}} etc. when they upload files? The upload wizard suggests CC BY 4.0 and BY-SA 4.0 as the defaults, as shown in this screenshot. Qzekrom (talk) 16:27, 10 September 2026 (UTC)Reply

CC by-all

[edit]

Why are we doing any of this? Is the axiomatic claim, "The existence of 1.0 licences is bad, and we must try to remove them from existing content" ?

In which case, be aware that {{Cc-by-all}} is available, and used, for new uploads and this encourages the multi-licensing of content under the range 1.0...4.0, as if that is a good thing. If we're suddenly against old licences (or just 1.0), then surely new uploads should be directed strongly to a single current licence generation (4.0) and not offering yet more 1.0 licences. This whole thread is pointless if we're still encouraging new 1.0 licences to be offered on new content. Andy Dingley (talk) 10:03, 15 July 2026 (UTC)Reply

For what it's worth, I would support the deprecation of license templates which apply multiple versions of the same CC license (e.g. {{Cc-by-4.0,3.0,2.5,2.0,1.0}} as redirected to from {{Cc-by-all}}, {{Cc-by-sa-2.5,2.0,1.0}}, etc - see Category:Multi-license license tags for more). I would also support the substitution of these multi-licenses with the single most recent license which they encompass, if possible. As far as I am aware, offering multiple CC license versions in parallel offers no tangible benefit to downstream users of these files. The primary effect of these templates is to make it less clear how files may be reused and what terms apply; we should not enable this. Omphalographer (talk) 22:00, 15 July 2026 (UTC)Reply
I would expect (but am not sure) that the tangible benefit of being able to use a Cc-by-sa 1.0 license when a Cc-by-sa 4.0 license was also available for the same file is if you wanted to create work that combined it with another file offering only Cc-by-sa 1.0. I don't think the licensing terms of the latter file would let you offer the combined, derivative work as Cc-by-sa 4.0, and I believe that without the multi-licensing you could not offer the combined, derivative work as Cc-by-sa 1.0, either. - Jmabel ! talk 23:31, 15 July 2026 (UTC)Reply
What is our formal policy on changing licences on existing content?
If this includes the ability to withdraw any licences previously offered, providing that at least one free licence is still available, then the fix for this is easy. Move {{Cc-by-all}} and {{Cc-by}} to both redirect to CC-by 4.0 alone. They already offered 4.0, we can remove the others at will. Andy Dingley (talk) 22:20, 15 July 2026 (UTC)Reply
I don't believe there is any detailed, general policy for changing licences that has consensus on Commons. Given that any licensee can at any time and without notice rely on any tiny and specific detail of a licence, I can't see how Commons could switch them to a licence without every such detail. Similarly, any licensor could have chosen to offer the work based on such a licence detail, and likewise how can Commons substitute a licence lacking it? There is certainly the proposition that a user may not revoke a licence that they validly placed—but in most cases of purported own work, we AGF instead of actually know that the licence is valid. And irrespective of our house rules, a person might have the legal right to revoke a licence or declare it void under some circumstances—I haven't researched these in detail, but 17 USC §203 termination of licence, unilateral mistake as to the intended licence, error of law rendering licence ultra vires, and gratuitous promise might be relevant, and might not have a uniform application in the law of all relevant places. TheFeds 13:44, 17 July 2026 (UTC)Reply
  •  Oppose I see no problem with multilicensing, at all. They are all valid free licenses, too. This tag will improve compatibility with files that were licensed with 1.0 (combining into derivative works etc.) since that was one of the issues with the 1.0 license (derivative works with other CC versions). We certainly want to discourage new works being only licensed with 1.0, but no problem at all with licensing this way. Carl Lindberg (talk) 14:36, 31 July 2026 (UTC)Reply

New criteria for speedy deletion: Newly uploaded and unused raster images identical to existing vector images

[edit]
Latest comment: 11 days ago26 comments16 people in discussion

I could have sworn I proposed this before, but I don't remember the outcome and I can't find the discussion.

We get with some regularity people uploading raster (.png, .jpg, etc.) logos which we already have vector (.svg) versions of on Commons (and these vectors are often already in use on various projects). I believe deleting these is in the spirit of CSD F8 (Exact or scaled-down duplicate), but not the letter of that criteria. Therefore, I propose one of two options

Option 1 - Modify CSD F8

Addition below, in red:

F8. Exact or scaled-down duplicate
The file is an exact or scaled-down duplicate of an older existing file. The generally accepted rule is to delete the newer duplicate, but that may not always be the case, such as when comparing between a user uploaded file, and a bot uploaded file. For very large files, however, it may be acceptable to have a scaled-down duplicate for accessibility reasons. This criteria also includes newly uploaded raster images that are an exact duplicate of an older existing vector file.

Option 2 - New CSD

F12. Raster image duplicating older vector image
The file is a newly uploaded, unused exact duplicate in a raster format of an older existing file in a vector format. Because vector images can be scaled to any size, the raster image can be any size, as long as it's identical in design to the vector image.

Discussion

  • I don't think either of those change anything.
This is presumably (needs to be stated more clearly?) that this is a static bitmap matching the bitmaps our renderer generates. In which case, it doesn't matter if the subject is 'appropriate' for vectors, it's just going to be equally inappropriate in both files, and it's this duplication that we're looking for.
If the SVG is a wrapped bitmap, then you could raise a DR on the SVG itself. But a speedy would still be valid for the static bitmap because, again, it's a technical duplicate of the bitmap version. Andy Dingley (talk) 21:44, 15 July 2026 (UTC)Reply
I didn't want to get overly wordy in the CSD text, but IMO if the SVG is insufficient quality for use, it should be DRed, at which point there wouldn't be a vector "duplicate". The Squirrel Conspiracy (talk) 21:49, 15 July 2026 (UTC)Reply
  • And meanwhile you've already speedied the otherwise OK raster version? - Jmabel ! talk 23:34, 15 July 2026 (UTC)Reply
    If the two images are sufficiently different (e.g., earlier poor quality SVG versus later good quality PNG), then the speedy predicate is not met because the images are not duplicates. The PNG should not be deleted.
    A poor quality SVG need not be DR'd but rather marked as a fake SVG, bad SVG, or a poor vectorization that needs to be improved. If SVG is an appropriate format for the image, then do not DR it. If a better SVG already exists, then just mark the poor SVG as superseded by the better SVG. Glrx (talk) 05:14, 16 July 2026 (UTC)Reply
  •  Support adding this to F8, with the simpler wording:

    The file is an exact or scaled-down duplicate of an older existing file, or a raster version of an older existing vector image. The generally accepted rule […etc, etc…]

    It has been my experience that F8 deletions of this form were already generally accepted. Omphalographer (talk) 22:05, 15 July 2026 (UTC)Reply
  •  Support F8, I'd flagged these as F8 in the past until one was rejected. --Belbury (talk) 16:29, 16 July 2026 (UTC)Reply
  •  Support F8, as long as the vector image really is a vector image, and not a raster image embedded in an SVG. --Carnildo (talk) 20:58, 16 July 2026 (UTC)Reply
  •  Comment: Is it a duplicate in the sense of sameness, or in the sense of order of derivation? Is it older in terms of creation or upload? (Imagine a sports team logo, for which there exists somewhere a BMP raster from 1999 and a GIF raster from 2009, and on Commons a Commons-user-created SVG from 2019, which means there is also a PNG output of our conversion. Let's further say that the BMP, the GIF and the PNG are each uploaded today as new files, stating their original dates in the description. Which rasters are eligible for speedy deletion, and why?) TheFeds 23:18, 16 July 2026 (UTC)Reply
    @TheFeds: The GIF raster could be deleted as a duplicate. The PNG output would not be saved as a file here. The BMP could be saved for provenance of the SVG file, unless that file has off-wiki provenance. Of course, all would need to be in-scope and free enough for us or below TOO.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:07, 17 July 2026 (UTC)Reply
    It was sort of a trick question to highlight quirks of the proposed rule. If duplicate means sameness, there's no stated mechanism to choose between the BMP, GIF and PNG uploads. (I grant that choosing the oldest raster could be reasonable, but I could certainly imagine arguments about why the implementation details of BMP vs. GIF vs. PNG in the context of a specific file might matter—transparency being the obvious one. And if the retained raster is intended to document the source of the vector, then you'd have to know either which raster file was actually vectorized, or that the vectorizer would have generated the same output with each of the 3 as input—which feels impractical.) If "older existing vector file" refers to upload order, then the result would change if the rasters had been uploaded first (clearly not deletable by the text of the proposed rule). Ultimately I think CSD F8 needs to be simplified to core criteria that are purposeful and minimally ambiguous, rather than tacking clauses on to it. TheFeds 13:04, 17 July 2026 (UTC)Reply
  •  Support either.Jonteemil (talk) 19:36, 20 July 2026 (UTC)Reply
  •  Support either, but prefer adding to F8. --Nux (talk··dyskusja) 19:57, 28 July 2026 (UTC)Reply
  •  Support F8 with simpler wording Tausheef Hassan Auntu ✉Talk? 09:22, 29 July 2026 (UTC)Reply
  •  Support adding to F8, but with shorter wording per Omphalographer. Thanks. Tvpuppy (talk) 20:46, 1 August 2026 (UTC)Reply

It looks like there's a consensus for Omphalographer's version. I'll create an AN thread so an uninvolved admin can close this and implement the change. The Squirrel Conspiracy (talk) 03:11, 1 September 2026 (UTC)Reply

Has the change been implemented already? I checked and I don't see it at COM:CSD. Thanks. Tvpuppy (talk) 01:13, 25 September 2026 (UTC)Reply
Nope. @Tvpuppy: You can do it though. The Squirrel Conspiracy (talk) 01:14, 25 September 2026 (UTC)Reply
I went ahead and added the change. Thanks. Tvpuppy (talk) 01:23, 25 September 2026 (UTC)Reply

Adding JPEG XL as new file format (*.jxl) despite Alphabet's slow-walking

[edit]
Latest comment: 21 days ago43 comments16 people in discussion
Tracked in Phabricator
Task T270855

Let's dispel once and for all this fiction that Chrome (i.e. Alphabet) doesn’t know what it's doing. It knows exactly what it's doing. I find it disheartening to see that post the 2021 thread,[1] the primary objection,[2] appears to be feeding into Alphabet's hypocritical standards[3] when JPEG XL truly was young when it was initially released 13 October 2021, and subsequent self-fulfilling prophecy be it enacted through conflicts of interests of IP or money for Firefox.[4][5] As with all abuse of market dominance, everyone not succumbing to manipulation has been using the high use value good to great effect, which is borne out in the evidence.[6][7] Right now Alphabet is proverbially telling another dubious promise to Charlie Brown that it will hold the football.[8] Don't let them, once completing the compatibility tech.[9] Enable it right away and tell users to enable the experimental JXL support using the Chrome flag in order to prove to Google, and more importantly the public, the "interest from the entire ecosystem", showing Wikipedia, like Apple, won't be bought. Lumbering in thought (talk) 07:04, 4 August 2026 (UTC)Reply

 Support adding jxl support to Commons (uploading, thumbnailing, and displaying).   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:10, 1 September 2026 (UTC)Reply
  •  Support Proposed this before. I agree with the proposal
PantheraLeo1359531 😺 (talk) 11:07, 4 August 2026 (UTC)Reply
I don't understand why the .jp2 jpeg2000 discussion is quoted here ? —TheDJ (talk • contribs) 13:16, 4 August 2026 (UTC)Reply
What? No, Commons should not support a file format to show the bastards what for. As far as I can tell from w:JPEG XL, it's not actually used, so there's no real reason to support it.--Prosfilaes (talk) 04:43, 6 August 2026 (UTC)Reply
I know little about the format, but what matters is 1) Is it free; 2) Does it benefit the project; 3) Does it not cause a detriment to the project; 4) Is the implementation overhead negligible. 1, 2 and 3 all appear to be "yes". 4 is the big question. Without browser support, any implementation would necessarily need to be treated like TIFF files and be converted for display. — Huntster (t @ c) 04:40, 7 August 2026 (UTC)Reply
For almost any file format, it both benefits and is a detriment to the project. It requires more complex support; basically everything that wants to deal with images or the category that file format sits in has to support it to support Wikimedia projects. This is in some ways worst for image formats, because offline Wikis almost always need images, where audio, video, books and 3D formats are usually avoidable. Removing a file format is a nightmare, so any file format we use will be around for the long run; if we add JPEG XL today, even if this is the high point for its use, in 2080 someone may be forced to find tools to deal with one. JPEG and PNG are no-brainers, GIF is historically dominant and well supported, TIFF can be a nightmare of complexity, but is also the dominant archive format and is the format many archives offer the highest quality version in.
I'd prefer to talk about WebP or AVIF or DNG, as people actively have tools to use them and the files are in existence. A new format that almost nobody ever uses will be a thorn in the side of any person trying to deal with the whole archive or a specific file that uses it. Worst case scenario it becomes like DjVu and is a format that Wikimedia uses and is the primary active user, despite not having theoretical advantages over its competitors.--Prosfilaes (talk) 07:00, 7 August 2026 (UTC)Reply
Note: WebP is allowed. Generally speaking, people keep wanting to make jxl happen, they believe there is some sort of conspiracy theory where google is trying to keep the format out of the web (despite the fact they made the format in the first place), but the fact is, its only mildly better than existing options at best (and possibly worse than existing options), and nobody is really using it. If people start using it, then maybe we should allow it, but until then, i don't see the point. Bawolff (talk) 00:19, 12 August 2026 (UTC)Reply
long run
"X designates the series of its image coding standards published since 2000 (JPEG XT/XR/XS), and L stands for "long-term", highlighting the intent to create a future-proof, long-lived format to succeed JPEG/JFIF"
Removing a file format is a nightmare [...] someone may be forced to find tools to deal with one
JPEG and PNG are no-brainers
The codec JPEG XL replaces JPEG with a lossless upgrade path, that to access simply a larger file someone will have to find a JPEG decoder (WEBP having replaced the momentarily explained "shovels") in an offline Wiki is a "no-brainer"? Like TIFF, DjVu in Media Viewer is also shown as a JPEG. This is the "shovels" selling point. Then it's a question whether those, presently unsupported by Alphabet, and original resolution JPEGs, should be replaced. This is a decent comprehensive comparison between AVIF, WEBP, and JPEG XL.[10] JPEG has neither wide-gamut for HDR or the necessary precision to replace lossless file types, which are discouraged in general. The glyph substitution problem of DjVu is a serious defect but it has uncontested rivalry in that it can store multi-page documents. Before I wouldn't have recommended replacing TIFF with JPEG due to narrow-gamut and 8-bit depth. However this is wide and up to 32-bit which accounts for all the info in a TIFF. You may have noticed Wikipedia doesn't find it a big deal to have it be unsupported as long as there are the aforementioned "shovels". Perhaps make the "shovels" AVIF if my plan fails. But we can at least try to have the best of all worlds if we don't cater to AVIF which is worse than even JPEG 2000 for CPU (which harms the environment) and has license problems to be momentarily explained.
AVIF's AOM Patent License 1.0 locks in[11] the Reference Implementation[12] which is controlled by probably the most monopsony "non-profit" consortium ever. JPEG XL uses a 3-clause BSD license,[13] includes the relatively unmanipulative w:Cloudinary as developer and there is an intermediary in the JPEG int'l stds. comm. before Alphabet further manipulates as described earlier. WEBP uses a BSD license but has Alphabet as sole developer. Lumbering in thought (talk) 08:10, 12 August 2026 (UTC)Reply
I'm not sure I understand all that. We support TIFF because we can download a file from an archive, like the LoC, and preserve the original; even lossless conversion can lose embedded data including gamma curves and photographic information. There's really no reason for us to use DjVu instead of PDF except that there's so many files uploaded with it and there are things about it that work better with existing Wikimedia tools. AVIF patent issues are for a different discussion. I don't believe that we should be adding unused formats because they are theoretically better; we should be supporting free formats that people actively want to upload, preferably not requiring conversion just to upload to Commons.--Prosfilaes (talk) — Preceding undated comment was added at 03:14, 13 August 2026 (UTC)Reply
Just want to flag that the BSD license is a copyright license, so it only applies to the libjxl reference implementation. The JPEG XL standard as a system for encoding and decoding images is not subject to copyright (17 U.S.C. § 102(b)), so a copyright license is irrelevant to whether the standard is open (only patents matter here). Qzekrom (talk) 05:37, 30 August 2026 (UTC)Reply
Both Blink (Chromium) and Gecko (Firefox) have announced their "intent to ship" support to their browser engines now, so we will have wide compatibility with JPEG XL files if it gets enabled on Wikimedia wikis. Ultimate Norman (talk) 21:25, 25 August 2026 (UTC)Reply
@Ultimate Norman No we would not have wide support. It would take about 10 years for browsers to get wide support for this (people use 10 year old devices). So no matter what, we are most likely to convert all jpegxl uploads back to plain jpg thumbnails for 10+ years. Possibly, if the conversion is quick enough on the fly, at some point in the future it would be worth swapping the webp thumbnail cache layer with one based on jpegxl via accept header negotiation, but thats about it. There is an enormous difference between supporting uploads of material and serving it up in the same format to all. —TheDJ (talk • contribs) 22:36, 25 August 2026 (UTC)Reply
@TheDJ: Certainly people use 10 year old devices, but is there any evidence that many use 10 year old browsers? I would think that the vast majority have automatic updating turned on for their browser, and many more update with some frequency. - Jmabel ! talk 23:33, 25 August 2026 (UTC)Reply
10 year old devices have generally stopped updating for a couple of years already (although it’s getting better). But there’s a large group of kids and grandparents with hand me down devices of that age indeed. 10 years is sort of the max of what we support, after that usually the security protocols of the web have moved on so far that the devices are no longer able to connect at all. —TheDJ (talk • contribs) 00:16, 26 August 2026 (UTC)Reply
To be clear; Apple devices can’t update their browser, so when the device falls out of support (around 8-10 years) the browser does too. Android devices generally lose their OS updates a lot earlier (4 to 8 years), but have more options to update their browser for longer (and so also can make it to around 10 years). This however does depend on people knowing what they are doing. Most people don’t, they can’t tell their Samsung browser from Google Chrome, so many are stuck with older browsers because they just don’t know better. —TheDJ (talk • contribs) 00:24, 26 August 2026 (UTC)Reply
There is a very long tail of users with old and/or weird web browsers, especially on mobile devices and other nontraditional platforms (smart TVs, video game consoles, etc). This is true for the Internet in general, but is particularly important for core online services like Wikimedia. Omphalographer (talk) 01:31, 26 August 2026 (UTC)Reply
It appears that this change enabling JXL decoding by default was merged into Chromium today. Qzekrom (talk) 02:21, 3 September 2026 (UTC)Reply
 Comment I would like to avoid a holy war between the AVIF and JPEG XL camps, and keep this discussion focused on which format to prioritize adding support for. Both are great formats with HDR and superior compression, and both are open standards managed by industry-wide consortia. Both Chromium and Firefox are adding support for JPEG XL after Google developed a Rust-based codec [1] [2] [3]. Qzekrom (talk) 21:38, 30 August 2026 (UTC)Reply
 Comment This is being pushed kind of hard on phabricator and other off-commons places like the wishlist. However i dont see much support onwiki. For cross reference, i said on phab that i would work on ingestion of avif/jpx/etc only if there is some sort of support on commons for it (either something with 75% support and 10+ users participating, or any discussion that is officially closed as "support"). I obviously don't speak for other devs, but i suspect they feel similarly. Thus I would suggest people who want this focus on convincing fellow commons users instead of spamming devs on phab. Bawolff (talk) 00:52, 31 August 2026 (UTC)Reply
I agree that we need a stronger signal of community sentiment so I'm working on creating a straw poll about this. I think there's a few issues that can be separated:
  1. How many Commons users want to upload AVIF, JXL, or both
  2. If so, which format Commons users would prefer to be prioritized
As for #1, I think there's a strong case that either or both formats would fill an important niche that existing formats already supported on Commons do not (HDR/high-bit-depth images that browsers can actually open), so they're not just "better WebP". It seems to me that there is a lot of latent demand for at least one of these formats to be added, at least among specialist photographers, but users disagree on which format is better. So #2 will likely be more informative. Qzekrom (talk) 06:03, 31 August 2026 (UTC)Reply
  •  Support JPEG XL is now supported by all the major browsers (if only experimentally). There's no harm in allowing uploads in the format even if many people can't view them yet. It's likely that JPEG XL will eventually become the de facto internet image standard (as it is intended to replaces JPEG, PNG, and TIFF). Plus, if we're going to start requiring watermarks on images, it would be nice if we could add the watermarks non-destructively, which JPEG XL supports with layers. Nosferattus (talk) 06:28, 1 September 2026 (UTC)Reply
  •  Support, but without removing support to JPEG/PNG/TIFF within at least 50 years from now. We here are overwhelmingly dependent on mobile Internet connections (SimilarWeb, StatCounter metrics). Android holds the near-monopoly in the mobile internet share here, as can be read here. Perhaps close to 0% use the alternate mobile OS like Linux mobile. The decision to upgrade hardware just to purchase a smartphone with a camera producing JXL images rests upon the users, but it can be challenging for many especially in a country where inflation remains substantially elevated and people/households need to budget between the "needs" (food, utilities, transport/commuting expenses, Internet bills/prepaid expenses, taxes, and renewals of some official IDs) and "wants" (one of which is the desire to buy a high-end phone with a camera producing JXL photos). A regular Pinoy user from w:en:Tondo or a regular Filipino-Chinese user from w:en:Binondo would care more about the challenges of their daily hustle (be it economic and business challenges) and less about the ongoing rivalry between proprietary and FOSS sectors in tech. Their mindsets on tech would either be "does it make my life easier right now?" or "does it make me money today?," and they would only dismiss the JPEG vs JXL / proprietary vs FOSS debates as needless non-Asian noise not conducive to their daily hustles. Despite living in a mixed residential-commercial area, I myself still use my w:en:Samsung Galaxy A20 which I bought in late September 2019. So while I support the addition of more file types/formats (as long as they do not trigger intellectual property headaches for Wikimedia Commons administration), I oppose removal of support for JPEG, PNG and other conventional file types that are heavily used by average internet users here. Until such time that budget or midrange models of phones from Xiaomi, Realme, Samsung, Infinix, Vivo, etc. finally have cameras that produce JXL images. JWilz12345 (Talk|Contributions) 07:25, 1 September 2026 (UTC)Reply
Just to add. Much of East Asian mindset is like "tech is an important appliance for national sovereignties and economies," not as a battleground for Western tech rivalry and format wars, at least within a few more years to come. See this article as an example. JWilz12345 (Talk|Contributions) 07:39, 1 September 2026 (UTC)Reply
To be clear, nobody is removing support for png/jpeg/tiff. That is not on the table. Bawolff (talk) 00:14, 3 September 2026 (UTC)Reply
 Comment Is there anybody who has JPEG-XL who wants to upload it? I don't think we should be predicting what's going to be used in the future, and nobody here has said I have a bunch of files I'd like to upload as JPEG-XL.--Prosfilaes (talk) 10:42, 1 September 2026 (UTC)Reply
There are technical reasons to use JPEG XL over JPEG/PNG/TIFF:
  • The transparency capabilities of PNG with the compression of JPEG
  • Lossless and lossy storage profiles (although this can be confusing)
  • Higher compression (less storage usage both on the computer of the uploader and on the Wikimedia servers)
These are also enabled by WebP however. The unique elements in my opinion are:
  • Higher color accuracy and capabilities that make it better suited as an export format for HDR captured imagery, without having to resort to RAW/DNG (which is multiple factors larger because retains ALL information to edit)
  • Layers (like eps, pdf and djvu)
We have seen several people in the ticket signaling the desire for JPEG XL specifically for the HDR capabilities. —TheDJ (talk • contribs) 11:31, 1 September 2026 (UTC)Reply
@Prosfilaes: If we supported JPEG XL, I would start uploading JPEG XL files tomorrow. The ability to have layers would be extremely valuable to me. Right now, I have to flatten any layered images, which destroys the underlying data. I know lots of image formats have previously been hyped as "the future", but JPEG XL just has too many advantages to ignore and no practical downsides (unlike HEIC, WebP, and JPEG 2000). I would bet money on it becoming the dominant image format over the next 10 years. Nosferattus (talk) 16:22, 1 September 2026 (UTC)Reply
 Support I think we need a HDR image format that can be opened in the browser; both AVIF and JXL fill this niche. The only file format we currently support with HDR capabilities is TIFF, which typically generates much larger files than JPEG (for example, File:Emelio Zapata (edit).tif is an uncompressed image at 16.56 MB whereas File:Emelio Zapata LCCN2014694879.jpg is 2.62 MB) and has to be saved and viewed in another app. Also, per Nosferattus, There's no harm in allowing uploads in the format even if many people can't view them yet. Qzekrom (talk) 14:43, 1 September 2026 (UTC)Reply
Yes, there's always harms in adding a new format. You always add complexity to MediaWiki and any other systems that want to deal in wiki data, you always add potential security holes to all of those systems, you always add the risk of locking in a format that has hit its peak and is shortly on its way to being an obsolete poorly supported relic. There is no escaping those problems, so claiming "there's no harm" just makes more dismissive of your opinion; you can't properly balance costs and benefits if you don't understand there's costs.--Prosfilaes (talk) 08:28, 2 September 2026 (UTC)Reply
I don't know if Nosferattus literally meant no harm, but I will offer my interpretation of how I understood the comment. I believe there are benefits to allowing uploads in [JPEG XL] even if it can't be viewed in most browsers yet - as stated in the Cloudinary article, many scientific and image authoring tools already use JXL in some form (DNG, GeoTIFF, etc.), and JXL got OS-level support in macOS and Linux before Chrome added it back. Importantly, thumbnails won't be in JXL yet - this proposal is about uploading JXL images, and the software will automatically convert them to a format the user's browser can decode as it currently does with TIFF.
Given the potential for HDR images to add value to Wikimedia projects, I believe the benefits of supporting some HDR-capable format (that is, either AVIF or JXL) outweigh the costs, but it's a matter of choosing the right format to add. That's why I've been emphasizing prioritization between JXL and AVIF throughout this discussion thread.
Also, re: ...just makes more dismissive of your opinion - I feel hurt by this remark. Please remember to be civil toward other contributors. Qzekrom (talk) 23:14, 2 September 2026 (UTC)Reply

Subtopic: JPEG XL use cases

[edit]

What use cases for JPEG XL are you most excited about on Wikimedia Commons (e.g. HDR photography, animation, scientific imaging, lossless JPEG upgrade)? Do you have actual JPEG XL files that you would upload, or expect to produce/obtain such files in the near future? Also see this document listing JPEG XL use cases from the JPEG Group. Qzekrom (talk) 15:13, 1 September 2026 (UTC)Reply

Layers! Nosferattus (talk) 17:05, 1 September 2026 (UTC)Reply
I work in importing several files from free sources. Sometimes it happens that the source material is in filetypes like JXL or JP2. Of course, I could convert them, but usually metadata can get lost and if the data amount is >1 TB, downloading to my PC and reuploading takes a lot of time. As long a format is free and open, I see no problem. HDR photography is crucial, as cameras can capture in better dynamic ranges some years ago (or in HDR bracketing). Anyway, JPEG cannot cover the dynamic range of only 256 brightness levels. --PantheraLeo1359531 😺 (talk) 13:21, 11 September 2026 (UTC)Reply

Subtopic: Prioritizing JPEG XL vs. AVIF

[edit]

Given the scarce engineering resources available to add and maintain media format functionality (volunteers + paid staff), how do you think the Wikimedia community should prioritize between JPEG XL and similar formats like AVIF? For example, if you support adding both formats, should JPEG XL or AVIF be added first? Qzekrom (talk) 15:19, 1 September 2026 (UTC)Reply

Both? Bedivere (talk) 02:01, 3 September 2026 (UTC)Reply
i think, commons should look at what the newest best cameras and phones support, to decide what formats it should support, coz most images contributed are taken by cameras and phones.
i checked w:Canon EOS R1 w:Sony α1 II iphone 18 samsung s26. they all support jpg, raw and w:HEIF.
from this perspective, HEIF might be the one to spend resources on. RoyZuo (talk) 08:37, 3 September 2026 (UTC)Reply
should ask people in canon, sony, fujifilm, samsung, apple... what formats they use in 10 years; to what format the industry moves from jpg. RoyZuo (talk) 08:44, 3 September 2026 (UTC)Reply
To my knowledge, most Android smartphones use Google's Ultra HDR format, which encodes a gain map in the metadata of a regular JPEG file. It's designed so that incompatible devices can simply ignore the gain map and render the image as SDR. Apple also uses gain-mapped formats. There is an open source tool that can convert Ultra HDR JPEG and Apple HDR HEIC images to HDR10 AVIF or OpenEXR.
The problem with HEIC is patent restrictions, so we can't accept it per COM:PS/FT. Qzekrom (talk) 14:12, 3 September 2026 (UTC)Reply
As an aside, i thought this article talking about some of the drawbacks to jxl was quite interesting: https://giannirosato.com/blog/post/case-against-jxl/ Bawolff (talk) 05:54, 14 September 2026 (UTC)Reply
It should be based on camera market share and also the availability of freely licenced images in a specific format. Commons is a long term project, so it has to think decades ahead in terms of compatibility as algorithms, patent-expiries and formats develop. Utilizing well established libraries will help reduce the engineering burden, but having to do possibly lossy format shifting just to upload to Commons is something we would want to minimize as formats mature. Ultimate Norman (talk) 13:04, 14 September 2026 (UTC)Reply

References

[edit]

References

  1. ↑ com:Village_pump/Proposals/Archive/2021/03#Commons_should_support_JP2_file_format
  2. ↑ com:village_pump/Proposals/Archive/2024/08#c-Bawolff-20240820003800-PantheraLeo1359531-20240819155200
  3. ↑ https://cloudinary.com/blog/2026-the-year-of-jpeg-xl#_strong_strong_timing_and_interoperability
  4. ↑ https://vale.rocks/posts/jpeg-xl-and-googles-war-against-it#googles-exploitation-of-their-dominance:~:text=This%20rightly%20caused%20an%20uproar
  5. ↑ https://vale.rocks/posts/jpeg-xl-and-googles-war-against-it#why-webp:~:text=Firefox%2C%20which%20receives%20a%20pretty%20decent%20amount%20of%20funding%20from%20Google%2C
  6. ↑ https://cloudinary.com/blog/2026-the-year-of-jpeg-xl#:~:text=JXL%20adoption%20in%20the%20broad%20ecosystem%20%E2%80%94%20photography%2C%20digital%20art%2C%20medical%20and%20scientific%20imaging%2C
  7. ↑ https://cloudinary-marketing-res.cloudinary.com/image/upload/v1773848235/blog-2026_the_year_of_jpeg_xl-1.png
  8. ↑ https://coywolf.com/news/web-development/jpeg-xl-jxl-is-coming-back-to-chrome/
  9. ↑ https://phabricator.wikimedia.org/T270855
  10. ↑ https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg#:~:text=of%20resilience%20against-,generation%20loss,-%2C%20video%20codecs%20are
  11. ↑ https://ipeurope.org/blog/royalty-free-standards-are-not-free-of-costs-av1-as-a-case-study/#:~:text=have%20created%20a-,%E2%80%9Clock%2Din%E2%80%9D,-effect.%C2%A0
  12. ↑ https://aomedia.org/license/patent-license/#:~:text=Reference%20Implementation%20and%20Specification%20are%20provided%20%E2%80%9CAS%20IS%E2%80%9D
  13. ↑ https://fossa.com/blog/open-source-software-licenses-101-bsd-3-clause-license/#:~:text=Modify%20the%20code.%20Developers%20are%20permitted%20to%20update%20or%20rework%20the%20original%20code.

Include categories and depicts in the {{Information}} template

[edit]
Latest comment: 6 days ago25 comments12 people in discussion

One of the things I find frustrating about commons, is that organizational metadata (categories, depicts) is far away from the main file infobox where all the other metadata is. I think its likely that new users will never notice the categories (Or even worse, can't on mobile). Depicts is hidden behind the structured data tab, which i think most users will never click on. Even if they do click on it, all the depicts link goes to Wikidata. Users almost certainly want this metadata to navigate commons images, not see the definition of the term at wikidata.

To that end, I'd like to propose that we include this metadata in the information template. This should better allow users to navigate to similar images.

I have made a proof of concept at Module:Information/sandbox/showcats Bawolff (talk) 00:07, 12 August 2026 (UTC)Reply

@Bawolff: I like the result as shown in the examples. (One quibble: "Media contains" is a much less accurate statement than "depicts".) Anything to say about overhead? Also, we'd presumably want to add all of this also to templates such as {{Art photo}}, etc. - Jmabel ! talk 05:45, 12 August 2026 (UTC)Reply
Personally I've always thought "depicts" sounded very stilted which is why i went with the other wording, but i'm not particularly attached to that, so am happy with making the column header be anything. As for overhead, my main worry is that currently it only shows non hidden categories (which i'm also not sure if that is the right thing to do), but the way it figures out if a category is hidden creates a template link, which the DBAs probably wouldn't like. I think there may be alternate solutions for that (involving scribunto changes) we could explore if this idea gets popular support. It would also create a lot more cross linking to Wikidata, which i'm assuming is ok, but dont actually know. If the proposal gets support, it would probably make sense to discuss with user:Ladsgroup before actually implementing. Bawolff (talk) 06:34, 12 August 2026 (UTC)Reply
I agree that "depicts" is a little awkward, but using the term "contains" implies that statements should be added for anything which is visible at all in a photo or video, rather than only for things which are significant to the media file. By way of example: File:Obama and Biden await updates on bin Laden.jpg contains laptop computers, coffee cups, and neckties, but depicts none of those things. Omphalographer (talk) 17:35, 12 August 2026 (UTC)Reply
I believe Depicts is the right terminology. Making a distinction between primary (most important) and secondary ("background") items on a picture can be easily and clearly made via the "prominent" qualifier. --Geert Van Pamel 20:23, 19 August 2026 (UTC)Reply
Perhaps it makes sense to start with {{Art photo}} as a less used template before going on to the super widely used {{Information}}. One blocker here, is to distinguish between hidden and normal categories without overstuffing the number of teplatelinks, we need https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1325415 merged. Alternatively we could just display all categories without distinguishing between normal and hidden ones. Bawolff (talk) 19:38, 19 August 2026 (UTC)Reply
 Oppose Depicts, and categories are longtime "standard" functions of Wikimedia Commons. There is a strategy to work more with digital metadata in the Structured Data on Commons, and going away from templates containing text in order to more easily find media files/images. We don't want to further confuse the volunteers with yet another way of entering metadata. --Geert Van Pamel 20:06, 19 August 2026 (UTC)Reply
@Geertivp I'm confused by your comment. Nothing here is proposing a new way of entering metadata. Bawolff (talk) 20:19, 19 August 2026 (UTC)Reply
Then I understand you are proposing to duplicate the information about categories and depict statements in the {{Information}} template? I believe the current form is already too cluttered; I believe you will further confuse the reader. And there exist 100 (?) other templates beside {{Information}}. --Geert Van Pamel 20:28, 19 August 2026 (UTC)Reply
Just to clarify to ensure we aren't talking past each other since I'm not entirely sure how to interpret the word "duplicate" in your sentence. The proposal is to display categories & depicts information with the information box on the image description page. The proposal is just to alter how stuff is displayed. There would be no change to the wikitext on the image page.
I think the existing system is extremely confusing to the reader and a major reason why SDC is largely not being adopted at commons. Readers expect information to all be in one place formatted consistently, not spread throughout the page using very different UIs. Bawolff (talk) 20:55, 19 August 2026 (UTC)Reply
very good job. tysm.
 Support using this until commons has better native display of data.
for "media contains", 3 ideas:
  1. maybe "shows" instead of "contains"
  2. maybe the template can be smart enough to tell what kind of file it is, and so switches accordingly, "image/video/pdf shows" "audio contains"...
  3. or use "file" instead of "media" coz media could be a bit ambiguous.
RoyZuo (talk) 17:12, 12 August 2026 (UTC)Reply
 Support looks useful and fits nicely. I think the label is not that important as long as it is translatable and good enough for both images and videos. Nux (talk··dyskusja) 20:18, 12 August 2026 (UTC)Reply
 Oppose We don't need to make the information template longer, thus pushing the important license information even lower on the page. Depicts statements in particular I find to be particularly low-value; as far as I'm concerned, they just duplicate the description and categories. It's also confusing to show categories in a location different from where they can be edited, and depicts on a completely different tab from editing. Pi.1415926535 (talk) 22:32, 19 August 2026 (UTC)Reply
  1. "...pushing the important license information even lower on the page..." 🤷‍♀️ the template can simply be tweaked to display licence info stored in sdc on top then.
  2. i find it more confusing that sdc is on a different tab that requires clicking. i'm a user not an editor: i want to see depicts but i rarely edit them. only a handful of people ever would edit sdc of a file, but thousands of users would see them.
  3. sdc display in users' chosen languages, regardless of what language (unintelligible to them) of the description might be.
RoyZuo (talk) 20:23, 20 August 2026 (UTC)Reply
 Oppose per Pi.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:32, 19 August 2026 (UTC)Reply
 Support - And get rid of categories while we're at it. Nosferattus (talk) 23:25, 7 September 2026 (UTC)Reply
In the same spirit, I’d like to get rid of Wikidata. -- Tuválkin ✉ ✇ 19:04, 23 September 2026 (UTC)Reply
Its kind of funny, i feel like half the people opposing this are opposing because they think it will make wikidata/sdc better and they prefer categories, while the other half are opposing because they feel it will make categories better and they prefer SDC/wikidata. Bawolff (talk) 19:55, 23 September 2026 (UTC)Reply
@Tuvalkin: completely? Get back to having to sync up wikilinks in every single wiki? No centralized repository for (for example) basic information on a work of art, so nowhere to bring in massive info like that when we can get it from a museum database? With all due respect, that seems bizarre. - Jmabel ! talk 21:35, 23 September 2026 (UTC)Reply
It’s meant to be bizarre: I said «in the same spirit». Frankly I’m past explaining why categories, as we have it and on their own, are a good thing in my opinion. Those who don’t understand that, should just ignore categories altogether (and keep them at the very bottom of their pages), just like I ignore most SDC stuff. My riposte about getting rid of of Wikidata, was a modest proposal of the Swiftian kind, but with a je ne sais quoi: The truth is: While suggesting the disappearence of Wikidata is ludicrous and everybody knows it wont ever happen, suggesting the disappearence of categories is very realistic, and people like me, who see them as the mainstay of a Human-curated Wikimedia Commons, realistically shudder at the prospect. -- Tuválkin ✉ ✇ 22:11, 23 September 2026 (UTC)Reply
 Info: It is possible to have the category area of a filepage or catpage at the top of the page: See Preferences, under Gadgets: «Place categories above all other content.» and «Place categories above content, but below image on file description pages.» (I have been using this for more than a decade, with much profit — so I, for one, don’t feel the need for the proposed feature.) Was this fact considered when penning this proposal?
-- Tuválkin ✉ ✇ 19:12, 23 September 2026 (UTC)Reply
l'm aware of the prefence. I do think its an improvement over the default, but it still puts the category metadata separate from the other image info in a place where users are less likely to see it. Second, that works for if you select the preference, but my main concern is i want people who are not users but just browsing commons to be able to navigate to other media on the same topic. For some reason the mobile team has made the ridiculous decision not to show categories on the mobile site (and the interface for SDC is crap on both versions of the site). If someone comes to commons from a google search, or perhaps an attribution link from an external site, i believe they should have links to navigate to other files in the same category. Bawolff (talk) 20:02, 23 September 2026 (UTC)Reply
Agreed totally about the mobile stuff (or long story short, anyway). As for giving categories better visibility to unlogged or unexprienced users, that’s something I’d instinctively support. However, pushing them from the relative obscurity of page bottom upwards to a better seat at the table than the all important copyright notices and assorted vanity templates (which are typically transcluded after {{Information}}) might attract too much unwanted attention to their very existence — and that might inflame the passions of the anti-category crowd: Oh, this photo has 18 categories!, fetch me my pearls and my clutching mittens! So, I dunno; I’d rather lay low. -- Tuválkin ✉ ✇ 22:56, 23 September 2026 (UTC)Reply

A tool / gadget that auto converts file formats to ones accepted by Commons

[edit]
Latest comment: 15 days ago7 comments5 people in discussion

We have universal support for autoconversion from MP4 to WebM within the Upload Wizard.[4] Unfortunately progress on this has been moving slow, so we have added this functionality to our Image Annotation tool and it exists within our Commons:VideoCutTool.

We are looking at adding similar functionality for other file formats like HEIC. Does anyone know we we have tools that support that format currently? Doc James (talk · contribs · email) 18:56, 20 August 2026 (UTC)Reply

@Doc James: I see that the original village pump proposal was archived without being closed. What was the outcome? Qzekrom (talk) 15:06, 31 August 2026 (UTC)Reply
@Qzekrom: It should have been successful.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 19:38, 31 August 2026 (UTC)Reply
User:Qzekrom and User:Jeff G. Was not sure if we had other tools that did this, so we added it here [5] Doc James (talk · contribs · email) 03:47, 1 September 2026 (UTC)Reply
@Doc James: Just tried the tool for the first time for a HEIC upload (with zero need for any annotations), and it saves so much work by no longer requiring manual conversion? Would be extremely helpful to advertise this elsewhere (maybe even in the UploadWizard itself, as with v2c, but I guess at least on COM:FT). (Minor note: Only dates, not datetimes seem to be supported so far in the date field)    FDMS  4    23:00, 19 September 2026 (UTC)Reply
Glad you found it useful. Please spread the word that it exists :-) Was hoping to add this sort of functionality to the upload wizard but seems that might be difficult. Doc James (talk · contribs · email) 00:37, 20 September 2026 (UTC)Reply
 Support We kinda already have this with video2commons, but I wouldn't oppose converting from other non-video files, such as AVIF and HEIC. Dabmasterars [EN/RU] (talk/uploads) 09:30, 20 September 2026 (UTC)Reply

Drop ogv (Theora/Vorbis) from video2commons

[edit]
Latest comment: 2 days ago7 comments7 people in discussion

com:v2c currently offers 4 options:

  1. "ogv (Theora/Vorbis)",
  2. "webm (VP8/Vorbis)",
  3. "webm (VP9/Opus)",
  4. "webm (AV1/Opus)".

i recently noticed https://forums.linuxmint.com/viewtopic.php?t=441049 https://bugzilla.mozilla.org/show_bug.cgi?id=1860492 which means Theora is no longer supported by firefox?

so maybe v2c should stop offering theora?

maybe the community can review all the options and make recommendations on what w:codecs to offer, to be future-proof for some years? RoyZuo (talk) 08:14, 4 September 2026 (UTC)Reply

Do you mean that there's still an option to export Theora? Yeah, we should not be encouraging Theora in new uploads. Qzekrom (talk) 13:45, 4 September 2026 (UTC)Reply
probably a good idea to remove that option from c2v —TheDJ (talk • contribs) 15:33, 4 September 2026 (UTC)Reply
It probably also makes sense to remove vp8 as an export option. Bawolff (talk) 16:53, 4 September 2026 (UTC)Reply
 Support removing Theora and VP8, but only in video2commons. If someone uploads to Commons through the regular upload wizard, it should support these codecs so that videos from other sources don't have to be reencoded. Dabmasterars [EN/RU] (talk/uploads) 09:47, 16 September 2026 (UTC)Reply
 Support per above. Ogv and two mentioned formats are absolutely broken in modern smartphones. Ahri Boy (talk) 00:34, 4 October 2026 (UTC)Reply
Agreed. No reason to convert anything to an obsolescent format. - Jmabel ! talk 00:29, 5 September 2026 (UTC)Reply

Additional discussions about templates of political restrictions

[edit]
Latest comment: 4 hours ago10 comments6 people in discussion

In the past, templates regarding non-copyright restrictions for authoritarian states were created, and discussion concerning them created.

However, there are templates related to political restrictions that have not yet been addressed in the discussion.

I agree that, moving forward, such templates for political restrictions should be created only after reaching a consensus through discussion, and that it is necessary to agree on whether the proposed template is applicable to a liberal state before implementing it.

--Ox1997cow (talk) 13:36, 7 September 2026 (UTC)Reply

I agree that we should have proper legal citations for mentioning non-copyright restrictions in each country, however it should not be up to Commons users to determine whether a country is "authoritarian" or "liberal", or we will quickly run into politically biased debates, especially in the case of hybrid regimes. Rather, we should present information neutrally and cited to exact legal sources. – Howardcorn33 (💬) 11:07, 9 September 2026 (UTC)Reply
@Howardcorn33: I know this is going to sound rhetorical, but wouldn't that mean that many files here would have a dozen or more templates indicating that the file potentially runs afoul of restrictions in countries that have very little freedom of speech? I think the issue really isn't so much "authoritarian" vs. "liberal" as whether for a given country freedom of speech is a strong default, so the few restrictions really require reminders because you are not thinking that way day-to-day. - Jmabel ! talk 05:21, 10 September 2026 (UTC)Reply
In this context, I was speaking of "authoritarian" and "liberal" with regards to freedom of speech laws. Even by that sole measure there are difficult and non-conclusive cases for what we could define as "little" or "strong" freedom of speech. Both the Freedom of Expression Index (2025) of the V-Dem Institute and the Global Expression Report (2025) of Article 19 have numerous marginal cases and differ with each another when measuring the level of freedom of expression by country.
Implementing a limit for non-copyright political restriction templates (NCPRTs) based on the freedom of speech in a country requires Commons to make a judgement of that measure. If we have a consistent standard on which countries may or may not be cited for NCPRTs, then I may support such a proposal. If we do not have such a standard, then I believe the fairest way is to simply permit any and all countries to be cited. – Howardcorn33 (💬) 07:48, 10 September 2026 (UTC)Reply
@Howardcorn33: do I understand that you are proposing that we template every file that could be at issue to use in North Korea? Myanmar? Iran? - Jmabel ! talk 20:22, 10 September 2026 (UTC)Reply
@Jmabel: I am proposing that any and all countries may be cited if we cannot come up with a consistent definition of which countries are "too limiting of free speech". How could we otherwise deal with unclear or controversial cases such as India, Indonesia, Turkey, Ukraine, Israel, or Hungary? If one can come up with an explicit standard for which countries may or may not be cited in NCPRTs, I might find that acceptable, but so far none has been put forth. – Howardcorn33 (💬) 10:00, 11 September 2026 (UTC)Reply
I think i come to the opposite conclusion - this whole thing is a mess and we should just ban all these political restriction templates. The effort and controversy is not worth it. What even is the point of these templates? The original case was swatsikas in Germany, but if you live in Germany you're probably already aware that nazi symbolism is banned, so is the template really helping anyone? Bawolff (talk) 00:03, 17 September 2026 (UTC)Reply
That is a possible conclusion, although probably more difficult to attain a consensus on. But it would be a consistent solution. – Howardcorn33 (💬) 14:16, 17 September 2026 (UTC)Reply
It does make reuse/redistribution not universally applicable or at least more fraught, but then any non-copyright restriction could in theory do that. Arlo James Barnes 20:15, 2 October 2026 (UTC)Reply
I think that templates about some specific insignia or symbols are not problematic and clearly verificable. Templates for unclear cases can be misleading. Evelino Ucelo (talk) 22:01, 5 October 2026 (UTC)Reply

Make fpc-voter a gadget

[edit]
Latest comment: 27 days ago1 comment1 person in discussion

I wrote fpc-voter, a script for Featured picture candidates. It puts Support, Oppose, Neutral, Question, Info, Comment, Request and Withdraw buttons under every open nomination, so you can vote without scrolling down to the edit box and without copying the template by hand. Multi image nominations get one set of buttons per alternative, and you can strike or change your own vote with one click. It writes the same line you would write yourself, on the nomination you are already reading, with your own account. It decides nothing and it touches no other page. It also checks the FPC voter eligibility before showing anything, 10 days and 100 edits per COM:FPC, and if you do not meet it and you are not the nominator you get no vote buttons at all.

Ten accounts other than mine use it today, and every one of them had to be told the line to paste into their own common.js. That is what I would like to change. A gadget is a checkbox in preferences. I have done this before. QICvote, which I wrote in 2018 for the quality image process, is a gadget here and 2,112 accounts have it enabled.

Source is at User:Wilfredor/fpc-voter.js and in a public repository under MIT at gitlab.wikimedia.org/wilfredor2/commons-scripts, with a test suite that runs on every change. Documentation with screenshots is at User:Wilfredor/fpc-voter.

I am not an interface administrator, so if there is support somebody with that right would have to add it. Questions and concerns welcome. Wilfredor (talk) 12:55, 8 September 2026 (UTC)Reply

Proposal to promote COM:TAIV as policy

[edit]
Latest comment: 19 days ago3 comments3 people in discussion

Temporary accounts went live on Commons more than 9 months ago, we should have adopted Commons:Temporary account IP viewer as an official guideline a policy by now. Shaan SenguptaTalk 18:48, 8 September 2026 (UTC)Reply

Support AVIF and/or JPEG XL uploads

[edit]
Latest comment: 21 days ago6 comments4 people in discussion
Tracked in Phabricator
Task T257719

I think enabling uploads of AVIF or JPEG XL (either or both) files to Commons would be beneficial, especially because of their HDR capabilities. We currently don't have an image format with good compression and built-in HDR support - one can upload HDR TIFFs but those are uncompressed and can't be displayed in browsers.

In my opinion, AVIF has the slight edge here - it is already supported in a wider range of browsers; JPEG XL is mainly supported in Safari and can be turned on with Chrome and Firefox feature flags. Since enabling support for a new file format on Wikimedia projects takes considerable engineering effort, I think it's important for us to choose one to prioritize first, although I would like to see both formats eventually supported.

Previous discussion threads about this topic:

This thread is intended to be a companion to the previous JPEG XL thread above. (Note: this link should be updated whenever that thread is archived.) Qzekrom (talk) 05:23, 10 September 2026 (UTC)Reply

There is also a recent deletion request in which a user requested support for animated AVIF images. I think that fully supporting animated images (other than GIF) on MediaWiki is likely to be a heavier lift; this instance currently doesn't display animated WebP even though you can technically upload them, so we are likely to see narrow support for still images in AVIF/JPEG XL enabled first. Correction: MW does display thumbnails for animated WebP images now; see Category:Animated WebP files for a demo. Qzekrom (talk) 05:32, 10 September 2026 (UTC)Reply
@Qzekrom: Strangely enough, I am not getting a thumbnail for File:1Lib1Ref Campaign Video fa.webp (which displays for me in English) or File:ALEGORIA DE LA MUERTE 2.webp.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:12, 10 September 2026 (UTC)Reply
I suggested OpenEXR for HDR imagery, but it was rejected because it was too irrelevant. But I hope this proposal is successful --PantheraLeo1359531 😺 (talk) PantheraLeo1359531 😺 (talk) 18:04, 10 September 2026 (UTC)Reply
@Bawolff: You suggested starting a new discussion thread on Phabricator. I am trying to steer this conversation toward practical considerations and away from format politics. Do you think this thread is the right approach? Qzekrom (talk) 14:21, 14 September 2026 (UTC)Reply
Yes, i think what you are doing is good. My main worry from a dev perspective, is that we do a bunch of work, then when we are done, commons comes back and says we don't want this, and all the effort is wasted. Bawolff (talk) 16:47, 14 September 2026 (UTC)Reply
[edit]
Latest comment: 24 days ago6 comments3 people in discussion

Hey everyone, Is it possible to add a similar way to upload using website gallery link or Id like NASA Id, ESO Id, NOIRLab Id, ESA/Hubble & Webb Id or chandra.cfa.harvard.edu each article image gallery or ESA image pages and others that works similar to Current Flickr uploading process. I hope this should be made a feature as this feature could be helpful for everyone to upload images and can increase the efficiency and further ease of uploading images and can give options to users. Yeah, Similar to Flickr uploading rules can be made like Images with license compatible with Wiki Commons are accepted, 4 or 8 images per batch are allowed, etc. Abdullah1099 (talk) 05:02, 11 September 2026 (UTC)Reply

Community Whishlist link: https://meta.wikimedia.org/wiki/Community_Wishlist/W575 Abdullah1099 (talk) 11:03, 11 September 2026 (UTC)Reply
The process will be like:
  • For images:

1) You first put the web link "https://www.eso.org/public/images/eso0840a/" or id "eso0840a" 2) Then choose the format that are made available like in this jpg or tiff, you can either choose both or one of them (In this case both format) and continue and it will automatically add the details and images and then upload and both images are added like File:Glowing Stellar Nurseries.jpg and File:ESO-RCW120-Phot-40-08-fullres.tif and also link the both files

  • For Batch Upload:

1) Use the https://www.eso.org/public/images/? Or https://www.eso.org/public/images/?&sort=-release_date and then choose the 4 or 8 images from the list such as, eso2208-eht-mwa, eso1907a, eso1322a, eso1740a and then follow the first process mentioned for each images. Abdullah1099 (talk) 06:44, 11 September 2026 (UTC)Reply

Pinging @Fæ, who may have researched this before.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:38, 11 September 2026 (UTC)Reply
Write some code? If the list and metadata can be exported as a json file, preferably using standard fields as used in Commons templates (date, author, permission ...) then any code would be reusable. Some of the standard upload tools might be able to work with that, OpenRefine perhaps, but I only ever use custom python.
If you learn some Python, it's hard to imagine using complex tools instead. Fæ (talk) 15:40, 11 September 2026 (UTC)Reply
@Fæ, Unfortunately i am no were good in coding. So, User experienced in coding can help that's why i request the feature. Also i don't have an Developer account or Gitlab access Abdullah1099 (talk) 16:02, 11 September 2026 (UTC)Reply

Modify the Deletion Requests to allow subscriptions

[edit]
Latest comment: 2 days ago25 comments8 people in discussion
I mean these subscriptions

Hi. I would like to propose changing DR so that anyone can subscribe to discussions they want to follow closely.

I've grown attached to subscriptions, as I get notifications on the most interesting topics, and my watchlist... is too long. I'm sure you can relate to that ;). At the moment, it is only possible to subscribe to level 2 sections (== ... ==), and it doesn't seem like this will change any time soon. DR requests are level 3, so this would need to change to enable subscriptions.

The change would require some structural tinkering, specifically with all existing requests and some gadgets [6] [7]. I can fix the gadget and change requests for the current month [8]. There might be more to do; I'm not sure. E.g. if there are bots that require a specific structure to work, then operators might need to adjust their code. From what I gathered, DeletionRequestArchivist is operated by @Krd now, so this would need to be adjusted if the proposal passes. The current month's name would have to be removed as the top-level header (= August =), but it shouldn't be needed anyway. We could maybe start next month too. I could adjust the gadget to make it automatically switch from level 3 to level 2 when at midnight, that way we could even skip changing existing requests. Nux (talk··dyskusja) 21:39, 6 August 2026 (UTC)Reply

@Nux: While I support what you are trying to achieve, I am still stumbling over the same problem at m:srg. Do you have any thoughts on that?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:39, 7 August 2026 (UTC)Reply
@Jeff G. I'm not familiar with the process for stewards, as I am not one :)... but if there are no special tools for adding and archiving requests, then you can just change ==(.+)== to =$1=. Subs should just work after the change. You will also be able to subscribe to new topics.
If you can also move the "See also" section to the top, adding a new section at the bottom would work better, as you could then use this link to add a section (with a preloaded template and editintro at the top). Some other cleanup of the instructions might be needed, but probably just the srg header. Nux (talk··dyskusja) 15:25, 7 August 2026 (UTC)Reply
This should be solved in the subscribe feature. Everything else might break other older tools. GPSLeo (talk) 14:50, 7 August 2026 (UTC)Reply
At plwiki, I already did a similar migration of some pages, including a much more complicated process we have for DR (hundreds of pages divided into topics). Some of that work required cooperation with malarzpl, our bot magician, but other than that, it went quite smoothly AFAIR. Nux (talk··dyskusja) 15:30, 7 August 2026 (UTC)Reply
any improvement to enable the new features is welcome.
i had briefly looked at this. i found that it's probably the same thing needed to make pages show "Latest comment comments people in discussion" below the heading. the method to make this happen is to add __NEWSECTIONLINK__ , but this might not be ideal, so i gave up. RoyZuo (talk) 20:41, 7 August 2026 (UTC)Reply

There was no opposition here so I will try to make preparations to migrate this weekend. --Nux (talk··dyskusja) 10:48, 12 September 2026 (UTC)Reply

Can you create a list of all deletion request tools you want to update for this change? We need to make sure that no tool is missing. GPSLeo (talk) 11:07, 12 September 2026 (UTC)Reply
@GPSLeo AFAIK situation on COM is good because nomination pages are separated. So content of those pages is not important. There seem to be only two tools that are important here:
There is also wikicordo which might need to be modified in its report analyzer. I say might, because the title processed there doesn't seem to be used. I mean it's only for cleaning up... Just to be sure I created a merge request for wikicordo. Nux (talk··dyskusja) 19:59, 12 September 2026 (UTC)Reply
The closing tools are not the main problem. I am talking about the many ways to make a deletion request. All they need to be changed, otherwise we would have deletion requests looking differently depending on the tool used to make the request and the subscription feature also only working for some requests. GPSLeo (talk) 20:06, 12 September 2026 (UTC)Reply
@GPSLeo AjaxQuickDelete is a DR creator. Nux (talk··dyskusja) 20:09, 12 September 2026 (UTC)Reply
But the other deletion request tools do not use the code of AjaxQuickDelete, they have their own code to create the deletion request page. GPSLeo (talk) 20:11, 12 September 2026 (UTC)Reply
@GPSLeo I don't want to be rude but I asked for providing a list of tools that might need to be changed. You keep saying there are are other tools but you haven't provided any examples. Nux (talk··dyskusja) 20:19, 12 September 2026 (UTC)Reply
Sorry, but where did you ask me to create the list? I asked you to create the list as you suggested to make the change. I still think the change is not necessary as there are other simpler options for the use case. We currently do not tag edits on deletion request pages. We could simply add a tag to every edit to deletion request pages. Then you can just filter on the watchlist. GPSLeo (talk) 20:33, 12 September 2026 (UTC)Reply
@GPSLeo dude. So are there any other tools or not? I asked when I started the topic. When I started the topic I also said what scripts I'm planning to change. Nux (talk··dyskusja) 20:39, 12 September 2026 (UTC)Reply
The tools I am aware of are Commons:Adiutor of course Help:VisualFileChange.js. I do not know how many other scripts exist and are used to make deletion requests. GPSLeo (talk) 20:56, 12 September 2026 (UTC)Reply
OK, thank you. Adiutor is not affect as it is simply using a template. And also even if there are mixed requests it wouldn't be that important as those are still on separate pages. I mean it might look bad, but technically shouldn't be a problem. Nux (talk··dyskusja) 21:46, 12 September 2026 (UTC)Reply

I feel there is not enough support here for the opposition that was expressed. I guess maybe people on Commons are not using subscriptions... I don't want to force this on the community, even if I personally find subscriptions very useful in today's busy world (: --Nux (talk··dyskusja) 20:45, 27 September 2026 (UTC)Reply

 Question @Nux, are you planning on changing the header level for all archived DRs as well? If not, then what happens if someone creates a new DR on a page with existing archived DRs? Thanks. Tvpuppy (talk) 23:24, 2 October 2026 (UTC)Reply
@Tvpuppy at the moment I don't plan to do any changes. There seems to be little interest in this and some opposition. Nux (talk··dyskusja) 07:47, 3 October 2026 (UTC)Reply

Add frame rate value to video files

[edit]
Latest comment: 8 days ago6 comments6 people in discussion

I think it can be useful if we add the frame rate information to every video on Commons. It makes a huge difference if we have a 4K video with 24 FPS or 120 FPS :3. The metadata should contain the framerate. FFprobe offers options, too.

  • edited version with FPS
    edited version with FPS
  • original without FPS
    original without FPS

--PantheraLeo1359531 😺 (talk) 18:29, 14 September 2026 (UTC)Reply

 Support This is a great example of data which can in principle be added to tracking categories and the structured data by bots. ―Justin (koavf)❤T☮C☺M☯ 19:20, 14 September 2026 (UTC)Reply
 Support This is a good quality of life feature to have, virtually no reason not to do that. Dabmasterars [EN/RU] (talk/uploads) 09:49, 16 September 2026 (UTC)Reply
 Comment I'd argue that the compression (quality) parameters are more important. It's easy to waste a lot of bytes on just pushing a lot of data through. Doing it with quality is much harder (and even harder for 120fps). In general, I agree that video parameters should be available in the metadata section of a file page (where EXIF information goes as well). I don't think we need it in the descriptor. Mostly because more information there, won't really help the general public much in understanding what this is. Heck, most info that there is now isn't even very useful, at most it helps a little bit with upload review. —TheDJ (talk • contribs) 16:05, 18 September 2026 (UTC)Reply
 Support How would variable frame rate videos be handled? Qzekrom (talk) 19:23, 27 September 2026 (UTC)Reply

Place a notice about using speedy deletion in Commons:Categories for discussion

[edit]
Latest comment: 8 days ago11 comments6 people in discussion

Due to the decade-long backlog at Commons:Categories for discussion, I propose we put the following notice on that page, to hopefully reduce the number of easily solvable issues raised there.

The Squirrel Conspiracy (talk) 05:08, 16 September 2026 (UTC)Reply

@The Squirrel Conspiracy: I've made one edit to the above, adding the {{SD|C1}} case. Please feel free either to accept or revert it. - Jmabel ! talk 09:43, 16 September 2026 (UTC)Reply
Jmabel: Thanks! I wound up removing it because both C1 and C2 feed into Category:Other_speedy_deletions#Subcategories, where they're handled the same way, and I want to keep it as simple for people unfamiliar with Commons bureacracy as possible. That said, in a larger documentation of best practices than the mbox can afford, C1 (and G7) absolutely belong. The Squirrel Conspiracy (talk) 02:18, 17 September 2026 (UTC)Reply
 Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:12, 16 September 2026 (UTC)Reply
 Support Nux (talk··dyskusja) 22:46, 16 September 2026 (UTC)Reply
The main advantage of C1, where it applies, is that when that shows up as the reason for deletion it tells other admins that any recreation of this category is probably bad. But I can live without the mention in this context. - Jmabel ! talk 16:47, 17 September 2026 (UTC)Reply
putting it on that page doesnt solve the problem.
this needs to be in the popup from clicking "Nominate category for discussion". i've thought about editing the content of that popup to include copypaste templates for those simple cases, but i've not had the time to figure out where and how. RoyZuo (talk) 07:05, 19 September 2026 (UTC)Reply
i found it. MediaWiki:Gadget-AjaxQuickDelete.js/DiscussCategoryInfo needs to be edited. RoyZuo (talk) 07:06, 19 September 2026 (UTC)Reply
  1. use <syntaxhighlight lang="wikitext" copy></syntaxhighlight> to wrap the codes so they can be easily copied.
  2. add the case where a move of the category is sufficient (anyone can move categories). this comes up a lot when users say the topic is renamed or the title has typos.
RoyZuo (talk) 07:09, 19 September 2026 (UTC)Reply
Interesting idea, but unfortunately this would not work. The render used by the gadget just adds a class mw-highlight-copy and no behaviours like copying is built into the code. I tried with User:Nux/Gadget-AjaxQuickDelete.js/DiscussCategoryInfo and it didn't show any copy buttons. I guess there might be some way to trigger the copy button, but not sure that would work either. In the prompt you set AQD.reason and what is inserted is AQD.tag. So at least from within the message box you would not be able to add different template when nominating.
But perhaps this could be achieved similarly to what is discussed in #Quick options for nominating for deletion. I guess there could be some jQuery Combox to choose which template is inserted to the category page. This could be in separate Speedy deletion tab. We actually have this done on plwiki... But plwiki's AjaxQuickDelete was basically rewritten by Msz2001 so I'm not sure if it would be easy to retro fit it to Commons. Probably not easy. Nux (talk··dyskusja) 21:19, 19 September 2026 (UTC)Reply

 'Oppose STRONGLY - invites abuse/"creative interpretation"; different editors have VERY different ideas of what constitutes "uncontroversial(!). AND this would basically be an expansion of ADMIN powers, since ordinary editors cannot delete. just CLEAR THE BACKLOG via normal procedures. make it a "wikiproject" if you have to. i'm even willing to put some time in on sorting it, if somebody makes the framework. Lx 121 (talk) 02:42, 27 September 2026 (UTC)Reply

Quick options for nominating for deletion

[edit]
Latest comment: 17 days ago19 comments6 people in discussion

I propose updating the deletion nomination gadget to have some selectable pre-made deletion reasons:

  • Copyright violation - General (specify details)
  • Copyright violation - Licensing problems
  • Copyright violation - Derivative of non-free work
  • Copyright violation - Freedom of panorama No freedom of panorama (specify country)
  • Copyright violation - Logo above threshold of originality (specify country)
  • Copyright violation - Not de minimis
  • Out of scope - No educational use
  • Out of scope - Unused file with no likely educational use (thanks Omphalographer)
  • Out of scope - Created as advertisement
  • Out of scope - Test file or spam
  • Out of scope - Low quality, unused upload of nudity (thanks Isaac I Navarro)
  • Personality rights - Photo of a person in a private place without their consent
  • Personality rights - AI-generated image of an identifiable person (thanks Omphalographer)
  • Other - Illegal to host in Virginia
  • Other - Corrupted file
  • Other (specify reason)

I also suggest having invalid rationales that, when selected, don't actually create a deletion request and instead redirect the user to the main page:

  • Other - I don't like this file
  • Other - Trademark violation

Also, make some actions context dependent:

  • Copyright violation - Non-free internet upload (if the source is provided, creates a speedy deletion, otherwise a regular deletion)
  • Other - I am the uploader and want to delete this file (only show if the nominator is the uploader of the file; if the file is less than seven days old, speedy courtesy deletion, unless in use)

In my opinion, this would simplify the deletion process, while also filtering out erroneous nominations made daily. There will also always be a "more details" field to clarify some specific info, as well as a "source" field for certain types of copyright violations. Feel free to discuss improvements or suggest new fields. Dabmasterars [EN/RU] (talk/uploads) 07:00, 16 September 2026 (UTC)Reply

I assume "Freedom of panorama" means "No freedom of panorama", so let's say the latter.
How does "Not de minimis" differ from "derivative of non-free work"?
Jmabel ! talk 09:48, 16 September 2026 (UTC)Reply
  1. Yes, I meant the latter.
  2. Not de minimis is when the work is tagged or appears de minimis but it is debatable, while "derivative of non-free work" is a broader category, for example fan art based on official depictions.
Dabmasterars [EN/RU] (talk/uploads) 10:50, 16 September 2026 (UTC)Reply
Which deletion tool do you mean? I recently learned there are at least two popular ones :) Nux (talk··dyskusja) 21:05, 16 September 2026 (UTC)Reply
I mean the regular one that appears when you click "nominate for deletion". Dabmasterars [EN/RU] (talk/uploads) 18:20, 17 September 2026 (UTC)Reply
Then that is relatively easy to implement (I have some jQuery UI Combobox). Nux (talk··dyskusja) 18:23, 17 September 2026 (UTC)Reply
A few other reasons to consider including:
Omphalographer (talk) 22:26, 16 September 2026 (UTC)Reply
Good call. Dabmasterars [EN/RU] (talk/uploads) 18:59, 17 September 2026 (UTC)Reply
 Support Issac I Navarro (talk) 03:01, 18 September 2026 (UTC)Reply
I support this as the Commons:Mobile app has something similar already under Peer Review when clicking "NO" there are these options of for why:
"It is out of scope because it is"
  • a selfie which is not used in any article
  • totally blurry
  • nonsense, absolutely unusable in any article
  • Other: specify below
and then there is a box to type an answer that is labeled "Justification" Issac I Navarro (talk) 17:15, 18 September 2026 (UTC)Reply
 Support Dronebogus (talk) 03:02, 18 September 2026 (UTC)Reply
@Dronebogus, why? Also, you can't speedy delete a concept. Dabmasterars [EN/RU] (talk/uploads) 16:32, 18 September 2026 (UTC)Reply
Typo Dronebogus (talk) 17:50, 18 September 2026 (UTC)Reply
This may be a somewhat bold suggestion, but would it be worth adding a rationale for nudity? Something along the lines of “Out of scope – superseded by better examples”, based on COM:Nudity#Media better than existing files?
I have used this reasoning in a number of deletion requests where a file was nothing particularly special, had little realistic COM:EDUSE, and was of poor quality, while substantially better examples already existed. Some examples of deletion requests where I have used or seen this reasoning include:
There are also numerous examples that have used Commons:Nudity#New uploads where newer uploads offer little value, particularly when better examples are already available per COM:PENIS. The additional justification field could explain what better alternatives are available.
Issac I Navarro (talk) 22:25, 18 September 2026 (UTC)Reply
That is an interesting suggestion, but I'm not sure if it will help my main cause, which is to both make nominating easier for newcomers and decrease the workflow of other volunteers by shadow-preventing erroneous nominations and speedying up egregious violations. The guideline of "superseded by better files" is enforced very sparingly outside of nudity or other controversial topics, but can cause even more deletion requests if users think "well, I saw a similar higher quality file, so now I must nominate everything else because the text tells me so".
This is why I'm trying to be delicate of what to include and how to frame it. For example, making the reason "Out of scope - Nudity" will make users think any nudity is out of scope, so it should be reframed as something along the lines of "Out of scope - Nudity with no educational purpose", though that one is also a bit vague. Dabmasterars [EN/RU] (talk/uploads) 22:46, 18 September 2026 (UTC)Reply
What about "new low quality upload of human nudity/genitalia" or recently uploaded and unused low quality" etc..? Issac I Navarro (talk) 23:15, 18 September 2026 (UTC)Reply
Sounds better, I'll add an abridged version. Dabmasterars [EN/RU] (talk/uploads) 23:27, 18 September 2026 (UTC)Reply
I think "recent"/"new" may be useful to also include. Issac I Navarro (talk) 23:33, 18 September 2026 (UTC)Reply
 Question From a technical standpoint how difficult would it be for the text to link to the guideline/policy? In addition what about automatically adding categories? Such {{subst:nsdr}}? Issac I Navarro (talk) 23:38, 18 September 2026 (UTC)Reply

Lolicon in general

[edit]
Latest comment: 1 day ago248 comments42 people in discussion

There is a massive thread over at Meta:Wikimedia Forum#Lolicon in general, that was closed and suggested to be moved here by @The Squirrel Conspiracy. In particular, it is to discuss whether lolicon/shotacon content is generally permitted on Commons, and whether there is a meaningful distinction between erotic and pornographic depictions. I am not aware of a formal Commons policy specifically addressing this type of content. Currently there is Commons:Deletion requests/File:Stability Matrix Inference in action.png and Commons:Deletion requests/Files in Category:Super Forbidden Love that are pending. Issac I Navarro (talk) 18:29, 17 September 2026 (UTC)Reply

Sending a ping to the people in that thread on meta: @Stjn@Levivich@Gnomingstuff@Jmabel@PARAKANYAA@JWilz12345@Roxy the dog@Johnuniq@Andrei Romanenko@Thryduulf@MBH@LydiaPintscher@Kordishal@Nux@Myceteae@Gråbergs Gråa Sång@Dabmasterars@19h00s@S Marshall@Tazerdadog@Visviva@Abzeronow@Rosguill@GPSLeo@The Squirrel Conspiracy@Carn@Dronebogus@Amitie 10g@Andrei Romanenko@Arlo Barnes@ExtantRotations@Masem@Rhododendrites@LWG Issac I Navarro (talk) 18:38, 17 September 2026 (UTC)Reply
Thanks for the ping. I am not active on Commons. My involvement with the relevant policies and guidelines on en-wiki is quite limited although I have participated in a few recent discussions, primarily in one discussion about the use of specific images in a specific article. The images were not lolicons but the issues were related. I am aware that en-wiki and Commons have different policies, guidelines, and norms but am not familiar with the specifics. I don't think I have much to contribute to this discussion. I may or may not check back but I do not intend to subscribe. Certainly, if anyone thinks my perspective would be helpful, you may ping me. —Myceteae‍🍄‍🟫 (talk) 19:19, 17 September 2026 (UTC)Reply
I'm also not really involved here. Rules always have unintended consequences so I'm not sure where policy should be, but IMO it is morally wrong to deliberately create and publish sexualized images of children and I ardently wish people in spaces where creating and publishing such images is allowed would nonetheless choose not to create or publish them. If that perspective carries no weight here feel free to ignore me, and please don't ping me again as I have nothing further to say. LWG (talk) 20:34, 17 September 2026 (UTC)Reply
Please don't ping me. If I have comments on a topic I will provide them. I do not need the spam. Gnomingstuff (talk) 03:47, 18 September 2026 (UTC)Reply
In my opinion these images do not have a compelling educational value. I have not seen any kind of argument what they should educate. All thats been said can be told in text.
And finding such images on a platform that is supposed to be educational is highly disturbing. Furthermore this seems like an unnecessary legal risk to me. So I would be strongly of the opinion that it should generally not be allowed. Kordishal (talk) 18:52, 17 September 2026 (UTC)Reply
I already explained most of my points in the Meta Wikimedia thread, so I don't really want to explain it again in full detail.
TLDR: lolicon is legal in the US where Commons servers are hosted; the images illustrate something that wasn't on Commons before (explicit lolicon and loli+shota), hence they're educational. Feel free to argue, but I'll likely keep this position. Dabmasterars [EN/RU] (talk/uploads) 19:03, 17 September 2026 (UTC)Reply
Here’s my opinion as someone who hasn’t spent much time on Commons:
There is one clear reason that these images should not be allowed and that is because at least some of the people designing and uploading them are viewing them as sexual. There is no other reason to store them in a folder called Super Forbidden Love. It does not adequately describe what is in the folder unless you understand the connotations of being attracted to minors ExtantRotations (talk) 22:08, 17 September 2026 (UTC)Reply
Yet, COM:HOSTs, many types of media that people may find disturbing, such as suicide, nudity, violence, among many other various files that are explict that will not be on sister projects. Issac I Navarro (talk) 22:26, 17 September 2026 (UTC)Reply
Sure but does it store suicides in the category “People who deserved it”? Nudity in the category “Sexy MILFs with huge jugs”? Violence in the category of “Personal Wishlist”? ExtantRotations (talk) 22:28, 17 September 2026 (UTC)Reply
We have Category:Suicide by gunshot, and we also have (WARNING NSFW) File:Suicide of R. Budd Dwyer (Part 1).webm. And many other things that people may object to.
If you are referring to the category that the files are in, Category:Super Forbidden Love, that is the title the artist gave this series. Issac I Navarro (talk) 22:38, 17 September 2026 (UTC)Reply
Oh okay, thanks for confirming that the creator definitely made and uploaded them with sexual intent. ExtantRotations (talk) 22:39, 17 September 2026 (UTC)Reply
@ExtantRotations, I did not draw the images, they were done by Casytay and I asked permission to release them under CC BY-SA for use in the w:Shotacon article, as the previous image was mediocre quality. Not sure how intent matters here, as the question is about project scope. Dabmasterars [EN/RU] (talk/uploads) 22:48, 17 September 2026 (UTC)Reply
None of this disproves my point that the images are deliberately sexual. Commons should not host images of minors that are deliberately sexual. End of argument. Goodbye. ExtantRotations (talk) 22:55, 17 September 2026 (UTC)Reply
These aren't real minors, but whatever floats your boat. We all have opinions, and I'm tired of these discussions too. This can't be healthy for me, so I'll work on a Wikipedia draft article instead. Dabmasterars [EN/RU] (talk/uploads) 23:18, 17 September 2026 (UTC)Reply
@ExtantRotations, this is the creator's website Issac I Navarro (talk) 22:53, 17 September 2026 (UTC)Reply
Why would you even think I would click on that? I would rather peel off all my human skin and roll in salt than deep dive into the artist that created these nauseating images ExtantRotations (talk) 22:58, 17 September 2026 (UTC)Reply
FWIW pretty sure the title “Super Forbidden Love” refers to incest between minors, not adult attraction to minors. Dronebogus (talk) 23:06, 17 September 2026 (UTC)Reply
It seems to me the situation here is like the one with abortions: we don't want there to be too many of them, but anyone who needs one should be able to get one.
We have articles about this works of art in Wikipedias. Why shouldn't those articles be allowed to include illustrations? Because someone has become too steeped in Victorian morality or strict religious views? Meh. That’s no argument for Wikipedia. Before changing anything, show that there is actually a problem. ·Carn 07:58, 18 September 2026 (UTC)Reply
 Comment I noticed this pending deletion requests; to note the concern is de minimis.
That being said it is related to this topic. Commons:Deletion requests/File:Hakurei Shrine Reitaisai in Taiwan 3 (1).jpg Issac I Navarro (talk) 16:20, 19 September 2026 (UTC)Reply

More context: the WMF Legal Department has, on at least two occasions, flagged specific content or types of content that are not formally prohibited but that it views as a potential liability for Commons and/or the Wikimedia movement as a whole. The gist is that certain kinds of content dealing with privacy and child safety needs a "really compelling" argument for educational value. That sounds to me not like a categorical exclusion, but the need to (a) apply a more stringent standard for inclusion, and (b) put clearly articulated arguments on the record. In other words, it's not that "lolicon" needs to be banned outright, but that every instance of it needs careful justification as to educational use. As it stands, we commonly get arguments like "Keep per inuse" or "keep per scope" which do not, in my view, hit the target of "really compelling" arguments. FWIW I've compiled those two comments made by WMF Legal at COM:COMPELLING. — Rhododendrites talk |  18:48, 17 September 2026 (UTC)Reply

These are the lolicon-specific discussions I have been able to identify.
 Comment Of the deleted images, Lolicon reference.jpg, Lolicon 002.png and Showered.jpg were deleted because of copyright reasons, not because of the content in question. Dabmasterars [EN/RU] (talk/uploads) 19:07, 17 September 2026 (UTC)Reply
I don't think a catalog of DRs helps this discussion. What's proposed isn't predicated on precedent, and it can only really provide tangents and context-specific quibbles. The active disagreements that led to this proposal are all that's necessary to show the concerns people have, and that it's not unanimous. — Rhododendrites talk |  19:11, 17 September 2026 (UTC)Reply
It seems to me this thread is a means of possibly establishing precedent, since right now each media file is considered on a case-by-case basis although most of the objections to these depictions are as a class of image. Arlo James Barnes 19:25, 17 September 2026 (UTC)Reply
There is Category:Nude children in drawings (that is nonsexualized) and it's sub cats Issac I Navarro (talk) 20:56, 17 September 2026 (UTC)Reply
I appreciate you making a whole new essay, but project scope/in use is a policy and overrides community opinions. I can make my own COM:LOLICON essay defending the content and it would hold as much weight, which is to say barely any. Dabmasterars [EN/RU] (talk/uploads) 22:52, 17 September 2026 (UTC)Reply
Essays don't necessarily constitute policies or policy proposals, they can also serve to clarify elements of policy, or as persuasive writings. If you were to explain your perspective in long form (say in a user subpage) I'm sure people would read it, even if it didn't make its way into policy. Arlo James Barnes 01:48, 18 September 2026 (UTC)Reply

I think it's worth explicitly mentioning wmf:Policy:Wikimedia Foundation Combating Online Child Exploitation Policy#Prohibited content, which states:

Prohibited content includes (but is not limited to) photographs, drawings, renderings, or videos of minors depicting:

  • Nude body with a focus on genital areas, where that image has no obvious educational value aligned with the projects' purpose (see below for more details)
  • Implicit or explicit sexual intercourse with or in proximity of a minor
  • Simulated sexual activity (including if the minor is fully clothed)
  • Masturbation
  • A minor depicted with or engaging in sexual activity with sex toys
  • Other "sexually explicit conduct" as defined in United States law (18 U.S. Code § 2256)

There's a discussion on COM:VP where it has been suggested to narrow the scope to meet a stronger standard of "significant" educational value that cannot be achieved with an alternate image, which I would certainly support — OwenBlacker (talk) 18:57, 17 September 2026 (UTC)Reply

  • The Squirrel Conspiracy has already made their views clear: [9] Those who oppose lolicon are 'concern trolling' on a 'soapbox about nudity again' and they're not only going to NPA like them like this, but also threaten blocks. Andy Dingley (talk) 18:59, 17 September 2026 (UTC)Reply
    To be clear, I am not attacking anyone; merely stating my opinion on this kind of content. This content is illegal in many jurisdictions (including the UK, where I am currently) and even the images in my browser cache would be grounds for prosecuting me for possession of prohibited images of children under section 62 of the Coroners and Justice Act 2009. To give more context here, if I even just google the terms "lolicon" or "shotacon", Google shows me a warning at the top of the page:

    Caution

    Child sexual abuse content is illegal and harmful

    Get confidential help

    If you're worried about your thoughts or behaviour

    Stop it now UK

    Seeking sexually explicit images of children can have serious consequences for yourself and others. If you are worried about viewing sexual images of children or are experiencing urges to do so, you can access anonymous, confidential, and effective help from Stop it now UK.

    Additional accordion sections have titles Find support for victims and Report illegal content.
    And I would suggest that The Squirrel Conspiracy might need to remember to assume good faith and to ensure that he himself is not engaging in personal attacks. — OwenBlacker (talk) 21:27, 17 September 2026 (UTC)Reply
    Says the same thing in the United States see my comments at en:Talk:Shotacon Issac I Navarro (talk) 03:03, 18 September 2026 (UTC)Reply
@OwenBlacker The same link also states in wmf:Policy:Wikimedia Foundation Combating Online Child Exploitation Policy#Situations and content outside the scope of this policy:

Artistic representations of nude children with demonstrable educational value (such as, but not limited to lolicon

So lolicon is allowed, though educational only. Regardless, I have already explained that such images illustrate the explicit side that was not seen on Commons before and are therefore educational. Dabmasterars [EN/RU] (talk/uploads) 19:10, 17 September 2026 (UTC)Reply
I understand that is your argument. I am merely disagreeing with it.
I had not spotted that clause, so thank you for pointing it out. That doesn't mean we can't change Commons' policy however. —  OwenBlacker (talk) 21:04, 17 September 2026 (UTC)Reply
Despite my objections to specific images discussed here and on Meta, I am not a prude and, having read that policy, I think that sort of guideline would be entirely appropriate here. There is no need to ban lolicon/shotacon overall, but there is absolutely a need to crack down on drawings of nude children of this kind according to this WMF policy. stjn[ru] 19:11, 17 September 2026 (UTC)Reply
That same policy also mentions Artistic representations of nude children with demonstrable educational value (such as, but not limited to lolicon, lolita, historical cartoons, drawings, paintings, or photographs (emphasis mine) as Examples of content that may be allowed on our websites because they provide educational, medical, or scientific value in support of Wikimedia's free knowledge mission, albeit In rare cases. So basically the policy is just as annoyingly (perhaps even deliberately) vague as similar laws like the Miller Test that are basically designed to be read as: “per the discretion of persons invested with the power to make relevant decisions” and therefore basically worthless as guidance on whether these images are okay or not. My good faith interpretation is “we want to be able to keep explicit depictions of minors by w:Martin van Maële and w:Franz von Bayros— stuff with obvious historical value; but we also want to block people by fiat for uploading content we don’t want to host that isn’t explicitly illegal.” So they wrote a vague, self-contradictory policy to have it both ways. Dronebogus (talk) 19:17, 17 September 2026 (UTC)Reply

We do have a rule: What Commons is not § Commons is not an amateur porn site. I would agree that this is not enough, though. Most of the pornographic content on Commons is not used in any articles, and its educational value is debatable at best.

We do have to remember that this is an international site. The WMF is, in theory, based in the USA, but its servers are spread across a few countries and also servers are not the most important. Wikimedia sites already have to comply with EU law, most prominently the GDPR and the Digital Services Act. DSA article 28 as I understand might become problematic to Wikimedia. I'm not sure it is worth defending questionable content if children will not be able to view or contribute to Wikipedia at all.

Law aside, Wikipedia and its sister sites are first and foremost about education. We (most of us, myself included) don't want censor stuff that is just eduction. But I think Lolicon is by definition about desire not about eduction. We should avoid hosting minors (children) even in erotic drawings. Sex between minors on images and videos is not something we should be hosting on Commons at all.

So I think the rule should be to remove Lolicon images and videos unless hosting them is required for educational purposes on Wikipedia or its sister sites. Nux (talk··dyskusja) 19:00, 17 September 2026 (UTC)Reply

  • (Edit conflict) I don't see any value in treating some types of pornographic work differently to other types of pornographic work as a class. If an image has educational value (and is appropriately licensed, attributed, etc) it should be hosted on Commons if it is legal for it to be so. This is not to say that all lolicon images have educational value - some do, some don't, but it's impossible to say which for any specific image without looking at that individual image. It should always be presumed that an image that is in use on a project is sufficiently educational to be hosted here. If someone disagrees with that then they need to go to the project where it is in use and get a consensus there to remove and/or change the image first. Thryduulf (talk) 19:09, 17 September 2026 (UTC)Reply
  • You don't think sexualized imagery of children is worth treating differently from sexualized imagery of adults? As for inuse, hard disagree. Anyone can add any image to any page on any project, including millions of pages with no watchers, and without any actual articulated justification. If, when an image goes to DR, that person would like to provide their justification, that can be considered, but while being inuse is a fine baseline to use for what's in scope, it utterly fails to meet the need to put a "really compelling" argument for educational use into words. — Rhododendrites talk |  19:14, 17 September 2026 (UTC)Reply
    We have COM:CENSORED and Commons:Nudity Issac I Navarro (talk) 19:47, 17 September 2026 (UTC)Reply

For a long time there’s been a de facto norm/taboo of just not uploading sexually explicit modern artworks depicting minors. You’ll notice prior to Super Forbidden Love-gate, all lolicon that’s stayed on Commons for a meaningful length of time has been “softcore”— the image of Wikipe-tan that caused Jimbo to have a conniption was almost comically tame, as was the well-known drawing by Kasuga (a lolicon artist from Japan, mind you), as was all the low-quality “freeze peach” troll artwork by Blackshade, as is file:Kaoru271108.png, File:Bottomless sukumizu girl.jpg via “barbie doll anatomy”), as are all of the lolicon images uploaded by Dabmasterars. So maybe we should just codify that? I voted to keep a handful of the SFL pics because they were either softcore themselves or depicted something that had no representation elsewhere (i.e. combined loli/shota art) but to be clear I really don’t think they’re the best examples possible. There are probably ways of depicting combined loli/shota that aren’t sexually explicit. --Dronebogus (talk) 19:37, 17 September 2026 (UTC)Reply

 Agree, I gave a similar view point in the undeletion requests fot thoses files. Issac I Navarro (talk) 19:52, 17 September 2026 (UTC)Reply
Since we are on this topic, could we also define on Commons what lolicon/shotacon are?
It is understood that lolicon is associated with sexualized depictions of childlike characters. At en:Talk:Shotacon#Source, I also pointed to en:Child pornography laws in the United States#1466A - Obscene visual representations of the sexual abuse of children, which states that "a visual depiction of any kind, including a drawing, cartoon, sculpture or painting" that "depicts a minor engaging in sexually explicit conduct and is obscene" or "depicts an image that is, or appears to be, of a minor engaging in ... sexual intercourse ... and lacks serious literary, artistic, political, or scientific value." There is also the w:Dost test to consider.
I think we should be a little more specific about the degree/threshold of what the given childlike imagery actually depicts. For instance, is it due to the appearance that can be easily identified through observable characteristics? Such as the proportions of the head relative to the body and the length of the limbs relative to the torso? I find this to be particularly relevant because other artwork that does not necessarily depict a childlike character can also become subject to this question. For example, in Commons:Deletion requests/File:MLP clop fanart of a pony version of Wikipedia.png, a non-explicit drawing of a cartoon horse was described as pedophilic by the nom. And other arguments to delete based on how the character was drawn and its perceived resemblance to a child. Issac I Navarro (talk) 20:22, 17 September 2026 (UTC)Reply
I think this would have to be decided on a case-by-case basis. The bare minimum standard is “could plausibly be seen as a realistic prepubescent or early pubescent child”— this obviously excludes cartoon horses or characters with adult features like large breasts (including “oppai lolis” like Ilulu from Maid Dragon). Similarly canonical/stated age should not matter (supposedly 500-year-old vampire lolis do not get a pass if they fail step 1, while a supposed 15-year-old with enormous breasts gets a pass because you can change the 5 to an 8 and it’s magically okay) and neither should a character being “aged up” or “aged down” from their canon/typical appearance. Dronebogus (talk) 21:52, 17 September 2026 (UTC)Reply
That would seem reasonable, and I  Support. However, there must be some line somewhere in this sand.
Some are suggesting in this discussion that we change how COM:SCOPE is defined. But if we where to do as some suggest then files such as the ones in Category:Drawings of boys by Malcolm Lidbury, would need to be examined. Issac I Navarro (talk) 22:05, 17 September 2026 (UTC)Reply

I do get the impression that commons has a more permissive attitude that the broader community of projects would be comfortable with. Speaking for myself as an outsider, I was pretty shocked at the "anything goes" attitude that seems to be prevalent here. Tazerdadog (talk) 20:26, 17 September 2026 (UTC)Reply

+1. "No kiddie porn, not even cartoon kiddie porn" is not a difficult or complicated rule to adopt and follow. I'm just one person, but I quit Commons in 2022 over this issue (making a rare exception to post this comment), and I won't upload or participate here until that rule is adopted and followed. I won't have my name associated with smut. Levivich (talk) 21:44, 17 September 2026 (UTC)Reply
I think that is fair to adopt such a rule. However, as I pointed out above it should be clear what is defined as such. So we don't get more deletion requests like we did with the cartoon horse.
There is also Category:Drawings of boys by Malcolm Lidbury, it would seem that if we were to be strict, would these files also need to go? Issac I Navarro (talk) 21:51, 17 September 2026 (UTC)Reply
I never suggested a complete ban on “cartoon kiddie porn”, just no recent depictions of prepubescent or early pubescent children (originally referenced rather unscientifically as “lolicon”) that are sexually graphic in nature. I was also suggesting codifying an existing unwritten rule against that specific category of content, not going after any longstanding extant content. By that logic most of the Super Forbidden Love drawings currently up for deletion, which even the uploader suggested probably go too far, would be deleted (even ones I voted keep on because they seem to be just barely okay by current standards). File:Super Forbidden Love Drawings 32.png would be still fine, as would all the other lolicon and shota stuff not based on a dubious application of FOP (which should just be deleted as copyvios anyway) would stay because none of them show genitalia let alone sexual activity. Showing genitalia should not be an immediate dealbreaker either, as long as the inclusion is incidental to the picture (sort of like how in classical Western art you could see plenty of penises but you’d basically never see an erection or a painting centered explicitly on a penis) Dronebogus (talk) 22:06, 17 September 2026 (UTC)Reply
This is why Wikipedia shouldn’t allow these images, even if they are technically within guidelines; the community loses people who are upset by these images, and gains people who enjoy them. Even if they are created entirely in good faith, Wikipedia should not host images of AI generated minors, complete with instructions on how to generate your own. It is practically begging to be taken advantage of by bad actors. ExtantRotations (talk) 22:18, 17 September 2026 (UTC)Reply
We are not Wikipedia, which is never going to host them anyway if you are referring to enwiki. Dronebogus (talk) 22:26, 17 September 2026 (UTC)Reply
Whoops yes, I said Wikipedia but I meant the Wiki-universe as a whole. I’m not sure what you would call that. ExtantRotations (talk) 22:35, 17 September 2026 (UTC)Reply
Wikimedia Dronebogus (talk) 23:43, 17 September 2026 (UTC)Reply

Raised my opinions on the 2 specific cases that are live in the deletion requests and do not want to repeat those. If there is a proposal here (not clear from the text), it may be being muddied by the understanding/misunderstanding of "Lolicon". What is under deletion discussion is not the existence of Lolicon images on Commons, which I understand as neotenized sexualized or erotic cartoons of unrealistically "youthful" people, that is to say people sometimes in revealing clothing or nude or in sexualized poses, with child-like exaggerated features. If that is a reasonable understanding, then it can be separated from cartoons of figures that are obviously intended to be unclothed or nude children in sexually explicit situations.

The latter it would be safer to say are not Lolicons, do not illustrate Lolicons and are so obviously going to be perceived as CSAM by many viewers that Commons should not host them.

In terms of COM:SCOPE, it is not a credible rationale that such user created or self published media has valid educational value. There are however exceptions, of which none seems to have been put forward, such as historic or cultural artworks, such as political cartoons, which have been published externally, are out of copyright and would add educational value in a realistic way.

Not in a rush to dig out 19th C. examples, too much of a tangent, however it would be sensible to interpret policy to effectively ban user created, self published and AI created sexually explicit artworks that can be perceived as being of children. The interpretation and wording of this Commons based policy can sensibly itself be firmly grounded in the existing consensus of what COM:SCOPE means with regard to educational value and not being a free host for non-educational stuff; this avoids a never ending debate about censorship which would be misplaced.

A diplomatic point, it would do our community here well to happily reach a consensus that preserves the goal of protecting media of educational value, and avoids having WMF legal having to make hard decisions because we can not. --Fæ (talk) 20:27, 17 September 2026 (UTC)Reply

See my comment above, Issac I Navarro (talk) 20:59, 17 September 2026 (UTC)Reply

I support changing COM:SCOPE to have a higher standard for these types of images. Instead of "realistically useful for an educational purpose" I would propose "significantly useful for an educational purpose which cannot be achieved with an alternative image". A big part of what I find objectionable about this is how flimsy the claims of "educational" are - they seem borderline at best. The hard part is describing what "these types of images" means. A first pass might be images where the intention of the creator is to depict a sexualized minor (whether real or imaginary). Bawolff (talk) 21:50, 17 September 2026 (UTC)Reply

If the standard is going to be creator intent, that is pretty much an invitation to call people pedophiles, which is flat-out defamation. Let’s not solve one potential legal issue with another. Dronebogus (talk) 22:08, 17 September 2026 (UTC)Reply
This section is literally entitled "Lolicon in general". I think by definition that involves creator intent. Additionally the image that started this all was clearly done with this intent as we literally have the AI prompt that generated it. Whether or not creating cartoons that intentionally sexualize a minor makes someone a pedophile is something I'm not going to touch. Regardless the intent with which these images are made with is clear and fundamental to the problem at hand. Bawolff (talk) 22:34, 17 September 2026 (UTC)Reply
This section is literally entitled "Lolicon in general". I think by definition that involves creator intent. not really, simply because we can’t get inside the creator’s head. And the people most… passionate about this are definitely not going to make the distinction between “this was made with sexual intent” and “the creator is clearly a pedo”. Adding a hugely subjective component like apparent intent effectively equals adding a moral/emotional slant to the argument. Dronebogus (talk) 23:48, 17 September 2026 (UTC)Reply
  • Thanks for the ping. I'm deeply confused about why a discussion in the wrong place would be closed, instead of moved to the right place. Seems unhelpful and high-handed. My activity on Commons is limited to encyclopaedia-building and I don't understand Commons' rules or policies at all. I do hope someone produces a porn-free fork of Commons that's fit to show to minors, as I would anticipate the full-porn version of Commons being blocked in large parts of the world over the course of the next decade.S Marshall (talk) 22:11, 17 September 2026 (UTC)Reply
@Bawolff, With that type of logic about COM:SCOPE to have a higher standards "significantly useful for an educational purpose which cannot be achieved with an alternative image", I would like you to see the many deletion requests that all ended in keep that are of adult nudity and art in Category:Exey Panteleev-related deletion discussions/kept Issac I Navarro (talk) 22:21, 17 September 2026 (UTC)Reply
I'm not sure I understand your point, I'm proposing a change in policy, so obviously the past would be different. And I'm not proposing that the higher standard apply to sexualized images of adults. Bawolff (talk) 22:30, 17 September 2026 (UTC)Reply
I am pointing out that the files covered by those 90+ deletion discussions have already had their scope concerns. Many of thoses files are not COM:INUSE yet we still COM:HOST them.
My concern is that adopting a substantially higher scope standard in this area (NSFW artwork) could potentially open the door to revisiting files that have previously been considered within scope, as the same general realm as the Exey Panteleev series. I am not necessarily arguing that the proposed standard should apply to sexualized images of adults, but rather pointing out that therr will be a broader scope implication. Issac I Navarro (talk) 22:50, 17 September 2026 (UTC)Reply
Yes I agree that changing the rules has the potential to cause us to revisit decisions of the past. If it didn't, there would be no point to making a rule change. Bawolff (talk) 22:53, 17 September 2026 (UTC)Reply
And yet, the Exey Panteleev series has already been debated and discussed to death. If there is going to be any change in policy, I think we should ensure that it is written in a way that does not inadvertently overturn situations such as the Exey Panteleev. Issac I Navarro (talk) 22:58, 17 September 2026 (UTC)Reply
As much as I would love revisiting Exey Panteleev and hopefully, finally getting those stupid out-of-scope images deleted, we should absolutely not bring unrelated NSFW content of any kind into this discussion. This is clearly supposed to be about whether we should host sexual drawings of children that are legal (if only just barely) in the US but illegal throughout many otherwise fairly liberal countries. The slippery slope potential should be obvious. What we should be aiming for is a three-tier scope approach of “almost anything goes” for SFW content; “only files that fill a meaningful gap in the collection should be kept” for typical NSFW content; “only files with a compelling educational purpose that cannot be substituted” for sensitive or extreme NSFW content (not just explicit cartoon depictions of young children but also things you might find on a shock site like coprophilia or gore, or images that potentially violate the privacy or dignity of depicted subjects) Dronebogus (talk) 23:18, 17 September 2026 (UTC)Reply
@Dronebogus,  Support, I was bringing up those files as a way to keep in mind about other effects a stronger policy may have on existing files. Issac I Navarro (talk) 23:22, 17 September 2026 (UTC)Reply

I want to state that the only reason I support restricting artistic depictions of pubescent/prepubescent children in sexual situations on Commons is because a) it’s already de facto best practice b) because it’s already de facto best practice very few files would be lost c) these files will never realistically be used, so SCOPE is dubious, and d) hosting them is a legal minefield that puts a target on Commons for moral guardians to legally harass us and potentially target us in far more devastating ways, with no real payoff besides “freeze peach”. I do not, as many (most?) users do, have a problem with lolicon/shotacon (or similar “cartoon kiddy porn”) as a concept; I think it’s the definition of a victimless crime if no real children are involved in producing it and fail to see how it can realistically encourage IRL pedophilia if the children depicted are cutesy anime bobbleheads. We need to be very cautious that this doesn’t become a moral crusade to chip away at COM:CENSORED from the inside by initially targeting something almost universally despised. This is a necessary evil IMO, not “about time we got rid of all this gross evil shit”. --Dronebogus (talk) 22:24, 17 September 2026 (UTC)Reply

Also, vocabulary note: everyone in this discussion should probably stop using Lolicon, loli, shota, shotacon, child porn and variants, and CSAM and variants since these terms are either vague or diluted/misused. You should state exactly what you’re referring to; ambiguity is the breeding ground of conflict and misuse/abuse of rules. --Dronebogus (talk) 22:31, 17 September 2026 (UTC)Reply

 Comment all the files in Commons:Deletion requests/Files in Category:Super Forbidden Love have been deleted by @JSutherland (WMF). Issac I Navarro (talk) 23:07, 17 September 2026 (UTC)Reply
I think user:PBradley-WMF should be made aware of this, since he started the original discussion on Meta and Joe Sutherland clearly deleted these by Trust and Safety fiat; if T&S thinks we shouldn’t be hosting these, then we shouldn’t be hosting these, and they should provide guidance on explicitly what we shouldn’t be hosting. Dronebogus (talk) 23:22, 17 September 2026 (UTC)Reply
 Agree, if we should not be hosting such files, we should have a clear policy in place. As you pointed out on the DR, we havs other files such as File:Martin Van Maele - La Grande Danse macabre des vifs - 29.jpg. And should have a policy in place that is specific for why these files are/not allowed. Issac I Navarro (talk) 23:28, 17 September 2026 (UTC)Reply
I feel like the File:Martin Van Maele - La Grande Danse macabre des vifs - 29.jpg will get a pass for as long as it’s realistically possible to give it a pass simply because it’s a) a public domain drawing from 1905 by a “real” artist with an Enwiki article and is therefore inherently notable and therefore inherently educational; and b) was a hard-won anti-censorship victory for Commons, marking the point where Jimbo lost his Sun King powers of deletion-by-fiat and Wikimedia became a beacon of free speech against right-wing pearl clutching from Larry Sanger and Fox News. You can’t have a stronger “keep” closure than that. The recently deleted “Super Forbidden Love” images are none of those things and even more graphic to boot. (The Maele drawings also supposedly have some satirical intent but so do some of the SFL images, so that seems like a weak exuse) Dronebogus (talk) 23:41, 17 September 2026 (UTC)Reply
it’s a) a public domain drawing from 1905 by a “real” artist with an Enwiki article and is therefore inherently notable and therefore inherently educational So I wonder: would this mean, in 100 or so years, we'd be OK with Lolita Anime or Boku no Pico being hosted on Commons in order to bolster their articles? -Brainulator9 (TALK) 00:57, 22 September 2026 (UTC)Reply
I think that age shouldn't be a factor outside of copyright rules. We shouldn't give old drawings a pass because they're somehow considered as "art" more than contemporary depictions. Either allow all fictional depictions or ban all fictional depictions. Preferably the former. Dabmasterars [EN/RU] (talk/uploads) 06:28, 22 September 2026 (UTC)Reply
I completely agree with I think that age [of the artwork] shouldn't be a factor outside of copyright rules. Artwork age is completely independent of the only two relevant factors: quality and educational use (in both cases both absolute and relevant to alternatives we do or realistically could host). Thryduulf (talk) 10:35, 22 September 2026 (UTC)Reply
I agree that the age of the work, copyright notwithstanding, should not be a factor in whether to host it, as well as [w]e shouldn't give old drawings a pass because they're somehow considered as "art" more than contemporary depictions. My thought was that since we have articles on these works, as little they may be seen as art, this would give the videos inherent COM:EV, much as File:Debbie Does Dallas.ogv is COM:INUSE for the benefit of w:Debbie Does Dallas (the article). -Brainulator9 (TALK) 18:31, 22 September 2026 (UTC)Reply
@Thryduulf, if you're interested, Wikimedia_Forum#Another_borderline_case?. Gråbergs Gråa Sång (talk) 18:48, 22 September 2026 (UTC)Reply
@Issac I Navarro "We have other files" is not a valid excuse. Project scope and Nudity pages specifically mention files that are better than their alternatives. And, in my opinion, a modern high definition file drawn by a professional artist is going to be better than early 20th century guy's image. Dabmasterars [EN/RU] (talk/uploads) 09:55, 18 September 2026 (UTC)Reply
I've talked to Joe Sutherland before at conferences. I trust his judgement, and this was either legal compliance with California or legal compliance with another country. Trust & Safety doesn't want to act unless they have to. Abzeronow (talk) 00:05, 18 September 2026 (UTC)Reply
I  Support and trust, Trust & Safety's judgment. @Abzeronow I would appreciate getting more details on the specifics here, as it may make some of the back-and-forth above a tad moot. If so, we could instead focus on establishing a specific policy or guideline to address these type of cases going forward. Issac I Navarro (talk) 00:15, 18 September 2026 (UTC)Reply
Also fail to see why it was necessary to delete image 32 of that set, which depicted barely exposed nipples and nothing else. It passes the file:Bottomless sukumizu girl.jpg test if nothing else, unless that file is now unacceptable too, which could lead to a far broader interpretation of what isn’t allowed here. Dronebogus (talk) 23:29, 17 September 2026 (UTC)Reply
I question whether this should set a precedent for revisiting files such as File:Hentai - yuuree-redraw-no-halo.jpg or File:Lesson 1 Private Tutor.jpg. Given these are both long-standing files on Commons, (and I highly doubt they would be deleted) I think we should consider what, within policy, distinguishes these files and supports keeping them. Issac I Navarro (talk) 00:02, 18 September 2026 (UTC)Reply
Both seem patently out of scope because they don’t depict obvious minors. The latter isn’t even sexually explicit and the former shows an anime girl with big boobs and a huge dump truck of a rear end. I don’t think these hypotheticals are really very useful in regard to the situation at hand, which is supposedly whether sexual non-real depictions of minors are okay on Commons. Dronebogus (talk) 00:14, 18 September 2026 (UTC)Reply
I am in total agreement with you. I think these files are perfectly fine. That being said, I do think there should be a distinction. Someone could point to the anime girl and claim that she is wearing secondary school attire. It should be clear that, due to her body proportions, a file such as this would not be affected. Issac I Navarro (talk) 00:25, 18 September 2026 (UTC)Reply
To be somewhat blunt: I think you should stop giving them ideas, even if they are ideas that have already come up in past DRs. Dronebogus (talk) 00:39, 18 September 2026 (UTC)Reply
I know, and see where you are coming from as I share many perspectives you have. However, if the Wiki lawyers actually think this file or others in this realm are not acceptable we shouldn't host them. Issac I Navarro (talk) 00:46, 18 September 2026 (UTC)Reply
Once again, highly doubtful. Getting into “how many angels can dance on a pin” hypotheticals here. Dronebogus (talk) 00:49, 18 September 2026 (UTC)Reply
I picked the anime file deliberately as it is a quality image:
Issac I Navarro (talk) 00:53, 18 September 2026 (UTC)Reply
Hi all, replying briefly to clarify a couple things. First, Trust & Safety never does office actions by fiat, they always have either a standing legal authorization or specific authorization from a lawyer. In this case, we received multiple reports of these files to our inbox for reporting child pornography. While art that clearly doesn't depict a real person is usually not violative of child pornography laws, we determined that this set needed to be removed for violating obscenity, rather than child pornography laws as well as violating our COCEP policy. This is rare (I've been here over a decade and this is the only obscenity-law deletion I can recall, so I do mean rare), and I'll confer with others on the team about being able to share more information about the topic. I also acknowledge that not every image in the set was exactly the same, but they were reported as a combined set and we handled them as such rather than pick through each one to give it a separate review. We'll follow up with a more informational post in a couple business days, but I wanted to acknowledge and clarify what happened. -Jrogers (WMF) (talk) 00:07, 18 September 2026 (UTC)Reply
I think your action was reasonable, but how exactly do you determine if something violates obscenity” if obscenity is, at least in the US (which I assume is the relevant jurisdiction) essentially defined by whether whoever is applying the test thinks it would probably offend most people and isn’t “artistic” enough? Dronebogus (talk) 00:18, 18 September 2026 (UTC)Reply
I'm obviously not going to second guess T&S but I'm honestly now really confused about where the line is drawn between what is and is not acceptable in the WMF's view. Hopefully the detailed post will shed more light, I'd particularly ask that it explains why they were handled as a group rather than individually - I presume that if someone reported, e.g. Category:Topless adolescent girls in art that the images it contained would be considered individually? If so what factors determine which approach is taken? Thryduulf (talk) 01:13, 18 September 2026 (UTC)Reply
@Jrogers Where will I be able to see that post? I want to read the full details of why the files were unilaterally deleted because of some vague "obscenity" clause. Dabmasterars [EN/RU] (talk/uploads) 09:57, 18 September 2026 (UTC)Reply
I think it would serve Commons well to have a policy implementing wmf:COCEP with perhaps some clearer guidance than the Foundation's policy provides. At the moment there are at least some files that may be (or already have been) deleted by office action under COCEP but are arguably not subject to deletion under any Commons policy. That doesn't seem like a great arrangement. In this case I am inclined to think that content that is subject to such a high level of scrutiny over each use is not really freely reusable, nor is it freely reusable with some exceptions (as in illegal-in-specific-country or trademarked content). Rather, it is more analogous to e.g. fair use where each use must be scrutinized individually, and therefore IMO is not appropriate for hosting on Commons. One test for whether something meets COCEP bullet point 2 (where the trouble seems to arise) might be "if you see this image in a Commons category thumbnail, will its educational value be readily apparent?" If not, then that's an obvious reason why inclusion on Commons is going to be an issue. -- Visviva (talk) 00:53, 18 September 2026 (UTC)Reply
I agree with @Arlo Barnes, statement on Commons:Deletion requests/File:Stability Matrix Inference in action.png in reference to how the Geekography case might be analogous. Since we are on the topic of SCOPE. Issac I Navarro (talk) 00:59, 18 September 2026 (UTC)Reply
I just don’t think there’s anything left on Commons where that applies unless you (or rather the legal advisory powers that be) consider the naked AI loli so egregious it cannot remain on Commons (assuming it doesn’t get deleted by the community snyway). Super Forbidden Love was an extreme case that is not likely to happen again. Dronebogus (talk) 01:03, 18 September 2026 (UTC)Reply
 Comment I just also noticed that the file in Commons:Deletion requests/File:Nooshafarin02.jpg was just deleted by JSutherland (WMF). Issac I Navarro (talk) 01:10, 18 September 2026 (UTC)Reply
I would like a detailed explanation there. That file didn’t seem like child exploitation nor obscenity. Dronebogus (talk) 01:12, 18 September 2026 (UTC)Reply
See also Special:Log/JSutherland (WMF) which shows what he has deleted and why (albeit only in broad categories of “DMCA” vs. “legal compliance”). Dronebogus (talk) 01:17, 18 September 2026 (UTC)Reply

With Super Forbidden Love apparently being way over whatever mystery line Wikimedia Trust and Safety uses, thr only images I think are realistically affected here are File:Stability Matrix Inference in action.png (because it technically depicts “uncensored” nudity in the form of bare buttocks and might have ethical issues because AI probably scraped actual CSAM because of course it did) and files in Category:Erotic activities involving children. If you look at the tiny selection of images in Category:Lolicon in anime and manga and the even tinier selection of images in Category:Shotacon in anime and manga (that aren’t blatant copyvios from arguably deliberate misinterpretation of FOP/de minimis laws), everyone depicted is either clothed or shown with “barbie doll anatomy”. --Dronebogus (talk) 00:35, 18 September 2026 (UTC)Reply

I had a similar thought regarding that category. I would like to better understand where that line is being drawn so I have a clearer sense of how to approach future deletion requests. Issac I Navarro (talk) 00:42, 18 September 2026 (UTC)Reply
Sigh, another «Let's ban something» request. What is the point of creating a repository of educational content if we ban stuff here just because it is triggering. The whole subject here triggered me to the point that I had to take a day before I would go to look at these things once the deletion request of Super Fobbiden Love was created, and you know what has happened? The admin has made a decision for me by deleting the images before I could form any opinion. So, I clearl  Oppose any bans on materials apart from those which are not educationally useful in the broadest sense of being educationally useful. I would support any policy that would say somthing like "We can only delete if there is a replacement media or at least a potential replacement". Anyhow, I will not engage with this further, the proposal authors clearly want emotional distress to cause people to react and ban stuff. Hopefully they will fail. Now I go back to productive things, like actually improving Commons. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 04:39, 18 September 2026 (UTC)Reply
Has there ever been a documented and proven case of AI scrapping real csam? Genuinely I keep hearing of this being possible yet if it happened I would imagine people would refer to the actual incident and the model trained on it would be blacklisted no? VivianaAnime (talk) 18:58, 27 September 2026 (UTC)Reply
@VivianaAnime: may I assume "scrapping" => "scraping"? Or did you really mean this in the sense of "throwing away"? - Jmabel ! talk 09:06, 28 September 2026 (UTC)Reply
I meant scraping yes. Minor typo. I've genuinely seen this claim everywhere especially in progressive spaces. I just want proof this actually happened. I've never seen proof of an AI model being trained on csam. I know its theoretically possible but has it actually been verifably shown to be a thing that can occur. VivianaAnime (talk) 03:37, 4 October 2026 (UTC)Reply

This discussion reminds me of the earlier debates about lolicon on Commons. In 2009, Mike Godwin was consulted about a specific lolicon image and, after reviewing it, stated that he did not consider it obscene under the Miller test or child pornography under U.S. law, noting that no actual children were involved. There was also a later discussion with him about obscenity law in general, where he noted that it does not lend itself to general answers.

I think this is worth remembering when considering a broad rule for this category of material. The 2011 Board resolution on controversial content later affirmed that Wikimedia projects are not censored, while also requiring content to be free and educational and supporting user choice and the principle of least astonishment.

So rather than treating the controversial nature of this material as a reason in itself for restricting it, I think the existing framework should remain the starting point, with individual cases considered on their own merits. --Amitie 10g (talk) 16:18, 24 September 2026 (UTC)Reply

Subtopic: Bawolff's proposal from main village pump

[edit]
WITHDRAW:

This proposal has been withdrawn by it's proposer. (non-admin closure) Issac I Navarro (talk) 03:51, 26 September 2026 (UTC)Reply

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Quoting from this village pump discussion:

Commenting here and not meta, because my comment is for Commons policy, not what WMF or wikimedia as a whole should or should not do. I would support a modification to Commons:Scope that images potentially sexualizing a minor don't just need to be "realistically useful for an educational purpose" but should meet a stronger standard of "significant" educational value that cannot be achieved with an alternate image. To put it bluntly, hosting this type of material puts commons in disrepute, we should only do it when its worth it, so that we preserve our ability to host controversial images when they really matter for our mission.

— Bawolff 06:49 (UTC), 17 September 2026

 Strong support Bawolff's proposal, taking into account both the Wikimedia Foundation's COOEP and the evolving and modernizing rules of the "democratic" countries where the English Wikipedia - the main product of Wikimedia in these countries - has significant access. My perspective as a user based in the Philippines: the page view stats show that there are 79M page views from the Philippines in August 2026 (for ease of reference, there were 2M page views from the Philippines for Wikimedia Commons). While the page views reflect on the number of clicks (not distinct users), the page views for English Wikipedia mean it has significant presence here. This significant presence has a high potential for Wikimedia to be put under the radar of the PH authorities. Take note of the very strict nature of Republic Act 11930, or the Anti-Online Sexual Abuse or Exploitation of Children (OSAEC) and Anti-Child Sexual Abuse or Exploitation Materials (CSAEM) Act of 2022. It does not differentiate a depiction of an actual child and a "computer-generated, digitally or manually crafted image, or graphic of a person who is represented or who is made to appear to be a child as defined herein."[11930/2022 Sec. 3(a)] Since the law does not incriminate non-Filipino individuals residing outside the country, the burden falls on the online platforms. It is certainly not pleasant for the entire Wikimedia umbrella to fall within the bounds of the emerging online ID verification bills and proposals here, considering that a Congressman here has cited Brazil as one of the rationale countries for the implementation of online ID verification before using social media. WMF itself has their own challenges in that country, pleading for discretionary carve-outs since November 2025. While the current focus of the pending online ID verification here in the Philippines is on social media (and possibly online gaming platforms as well as websites "that promote graphic, violent, and distressing crime-related content"), we do not want these measures extended to other platforms with high exposure here. Do note that some legislators are becoming against "discretionary" exemptions on social media (and perhaps soon, more types of online) platforms, with one asserting that such carve-outs (to not use national ID in verifying one's age) only "allow loopholes that could be used to circumvent the implementation of this law." In a nutshell, by supporting Bawolff's proposal, this helps uplift the entire Wikimedia umbrella (comprising Wikimedia Commons, Wikipedia etc.) as a responsible online platform that balances both the educational aims and the responsibility to protect the values of the minors, in accordance with the evolving laws of democracies like the Philippines and with WMF's COOEP. By becoming a responsible platform focused on public interest and public education, Wikimedia will remain exempted from the emerging online ID verification laws and regulations not only here in the Philippines and in Brazil but also beyond. Just to add also: Wikimedia Commons and Wikipedia would just be treated as a single tech entity in the eyes of DICT, CICC, and our legislators, considering how they treated Facebook, Instagram, and Threads as a single entity under w:en:Meta Platforms. JWilz12345 (Talk|Contributions) 02:38, 18 September 2026 (UTC)Reply

"Potentially sexualising a minor" is an unworkably broad term as it encompasses child pornography, lolicon, naturist images, any image featuring (partial) nudity of a minor, minors in swimwear, child and teen beauty contest participants, and much, much more. Such a massive change to Commons' scope is vastly out of proportion to the scale of the issue that the proposal seeks to address. Even if you don't think (m)any of these types of images potentially sexualise minors, nominations like Commons:Deletion requests/File:Playing Hmong children.jpg clearly show that some people do. Thryduulf (talk) 02:59, 18 September 2026 (UTC)Reply
Couldn’t agree more. “Potentially sexualising a minor” is just “depicting a minor” to some people, which will absolutely, inevitably be the first domino in a chain that includes all sex, then all nudity, then all violence, then all graphic medical imagery, pictures of Muhammad, hate speech and symbols, whatever the CCP doesn’t like, LGBT anything, pictures of deceased Australian Aboriginal people, pictures of women with uncovered hair/legs/faces/midriffs, all pictures of women, pictures of shirtless men, pictures of dead humans, pictures of live humans, pictures of dead animals, pictures of meat, pictures of skeletons, trademarked material, trypophobia, every other potential phobia… that last one kind of doesn’t leave anything since there’s a phobia for everything, including everything. Dronebogus (talk) 03:13, 18 September 2026 (UTC)Reply
 Oppose per Thryduulf and Dronebogus. Issac I Navarro (talk) 03:16, 18 September 2026 (UTC)Reply
@Thryduulf child beauty contests are considered by our authorities as illegal. Since 2024, the Council for the Welfare of Children had warned parents and organizers to stop holding any more child beauty contests. Perhaps at the very least, no image of beauty contests for minors held here must be hosted on Wikimedia Commons. JWilz12345 (Talk|Contributions) 03:17, 18 September 2026 (UTC)Reply
The original matter concerned only files specifically related to lolicon and shotacon. Comments like yours is precisely why I brought up the Exey Panteleev series. We also routinely host material that many people find objectionable or disturbing.
The fact that someone finds particular content objectionable does not, by itself, mean that it should be removed from Commons.
This is ridiculous that this is starting to look more like a broader campaign to censor Commons based on subjective objections to the content we host. Issac I Navarro (talk) 03:27, 18 September 2026 (UTC)Reply
Isn’t regular old porn and god knows what else illegal in the Philippines? We are not going to bend over backwards to appease unreasonable authorities. This isn’t being America-centric; it’s only applying US law because the US actually has the strong free speech protections necessary for Wikimedia to work. If we accepted the laws of every country where Wikimedia is legally available as equally valid, we would also be bending over backwards to Saudi Arabia and Russia. Dronebogus (talk) 03:29, 18 September 2026 (UTC)Reply
@Dronebogus so it isn't an issue of yours if one day DICT and CICC decides to order a siteblock of the entire Wikimedia umbrella for failure to remove content objectionable under the PH laws? JWilz12345 (Talk|Contributions) 04:34, 18 September 2026 (UTC)Reply
Or put in another way, once Sec. Aguda of DICT and the head of CICC Renato "Aboy" Paraiso found one single good rationale that nullifies Wikimedia's "public interest and educational projects" claim, they might add "high exposure websites" to the expanding categories of platforms and websites requiring users to verify their identities before using. Do note the PH authorities are proactive and are not as lazy as the Turkish authorities who didn't follow up on the Turkish school shooting image takedown request months before. JWilz12345 (Talk|Contributions) 04:42, 18 September 2026 (UTC)Reply
Why would Philippines law be relevant for the purposes of this discussion? Commons is hosted by the Wikimedia Foundation, (as pointed out above our servers are hosted in th United States) and the relevant legal framework would presumably depend on jurisdiction. Issac I Navarro (talk) 04:46, 18 September 2026 (UTC)Reply
@Issac I Navarro as long as a website or a platform is highly accessible in the Philippines and can be accessed by minors, it must comply with PH laws in the eyes of the Philippine w:en:Department of Information and Communications Technology (DICT) and the w:en:Cybercime Investigation and Coordinating Center (CICC). While the current focus of the authorities are social media and online gaming services, at least legislator cited Brazil as one of the role model countries for the proposed online ID verification law. WMF themselevs are currently dealing with Brazilian authorities for potential carve-outs to exempt the Wikimedia platforms from mandated online ID verification rules. JWilz12345 (Talk|Contributions) 04:53, 18 September 2026 (UTC)Reply
And COM:CENSOR. We host many things that are not "allowed" in other countries. Issac I Navarro (talk) 04:57, 18 September 2026 (UTC)Reply
Music with a certain BPM is banned as un-Chechen or un-Islamic or some shit in Chechnya. Do we ban music with a certain BPM on Commons to appease Chechen authorities? Dronebogus (talk) 10:14, 18 September 2026 (UTC)Reply
@Issac I Navarro we are objecting to the proposal?
@JWilz12345 I don't know which authorities you mean by "our" but they are legal in many parts of the world, and, by implication, also yours prior to 2024. Commons includes many pictures of images depicting activities that are legal in some parts of the world. File:Redneck Revolt Armed Demonstration.jpg would be highly illegal in the United Kingdom for example. Thryduulf (talk) 03:27, 18 September 2026 (UTC)Reply
I agree with you fully. This whole matter is getting ridiculous. It is an attempt to try and censor Commons. Issac I Navarro (talk) 03:32, 18 September 2026 (UTC)Reply
You're being a bit misleading here. The activity depicted in the image would be illegal to carry out in the UK, but the image itself is certainly not. What we are concerned about here is situations where some images are illegal to possess and/or view - not any situation where laws differ. Omphalographer (talk) 03:34, 18 September 2026 (UTC)Reply
@Thryduulf "our" - PH authorities. The distribution of those images on the screens of devices here is one such infraction of this law. JWilz12345 (Talk|Contributions) 04:32, 18 September 2026 (UTC)Reply
@Thryduulf My comment was my first thoughts on this, i think you make a fair point that we need to be a little more specific here to make this proposal workable. (Although i disagree with how far some of the other commenters take it suggesting that any rule is impossible - there will always be judgement calls that is why we have the DR process) Bawolff (talk) 03:54, 18 September 2026 (UTC)Reply
I agree there will always be judgements regarding where something falls in relation to a line, but we get to choose where the line is drawn. JWilz12345 seems to want to draw it at the point were no person will ever see an image that is illegal or culturally or religiously forbidden for them to see, which is fine in the abstract but as pointed out by others that would leave Commons unable to host anything that abstract art. That sounds hyerbolic but there is at least one human jurisdiction or culture that has laws, taboos or similar about everything else. Thryduulf (talk) 08:52, 18 September 2026 (UTC)Reply
I'm less concerned with the legal aspect - i think that is WMF's job so i leave it to them. The question to be answered is what type of repository do we want commons to be. Much of this material is extremely taboo in western society (If anyone wants to call me culturally imperialist for this, so be it), to the point that hosting this material may degrade Commons' ability to be generally useful for an educational purpose, which is supposed to be the whole point. In some cases that may be worth it. My concern is with examples of this media that are only marginally useful at best. The cost benefit ratio just doesn't make sense. I'm not saying full ban, just a stricter interpretation of what is in scope, what counts as using commons as a web host, etc in accordance with the significantly higher reputational "cost" of hosting these files. Bawolff (talk) 10:41, 18 September 2026 (UTC)Reply
Before someone cries “COM:CENSOR” or “freeze peach”, I would like to once again point out we currently have roughly zero explicit modern depictions of obvious minors in obviously sexual situations. So even a “full ban” on content like Super Forbidden Love would really have no tangible immediate effect. Dronebogus (talk) 10:43, 18 September 2026 (UTC)Reply
@Bawolff I'm not saying there shouldn't be a line. I'm saying that the line proposed here is the wrong place to draw it, and I have explained why that is. If we assign arbitrary units to an axis and state that drawing the line at zero means there are no restrictions at all, and drawing the line at 100 means that no images are allowed then everyone will agree that the line should be drawn somewhere between those extremes. The line is currently very fuzzy and sometimes appears to be about 2 or 3 and other times somewhere around 10-20. Applying the principles JWilz12345 proposes universally would draw the line somewhere around 95. My preference would be for a line somewhere in the vicinity of 2-5. Thryduulf (talk) 11:07, 18 September 2026 (UTC)Reply
 Strong support. I am not a Commons editor but after reading the many threads spread across the projects about this issue, it's pretty clear that sexualised depictions of fictional minors require substantially more than ordinary Commons scope.
A narrowing of the guideline to include a higher threshold of significant/compelling educational value which cannot be achieved with an alternative image is the right thing to do.
Modern, self-published, AI-generated content in this area is especially difficult to justify under that standard. Historically significant or genuinely irreplaceable content with educational value could still qualify. qcne (talk) 17:11, 19 September 2026 (UTC)Reply

This, more or less, is the starting point, yes -- to include WMF Legal's "really compelling educational use" standard in COM:SCOPE. But as they've said, it's applicable beyond potentially sexualizing a minor and also includes privacy, violence, etc. IMO what makes the most sense is to present those three categories and a link to COM:COMPELLING where we can update more specific guidance as it becomes available. — Rhododendrites talk |  13:42, 22 September 2026 (UTC)Reply


 I withdraw my nomination I withdraw my suggested proposal. I'd leave the matter to more experienced Commons and Pinoy users in dealing with the expanding age verification laws and proposals globally, including here in the Philippines. JWilz12345 (Talk|Contributions) 10:35, 24 September 2026 (UTC)Reply

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


@JWilz12345: strictly speaking, https://newsinfo.inquirer.net/1954017/dswd-body-urges-halt-to-beauty-contests-for-minors not saying that child beauty pageants is illegal, just the Counsill issued warnings about riscs. It also not means that making or distribution of photos is illegal. Don't spread misinformation, please. Evelino Ucelo (talk) 10:39, 3 October 2026 (UTC)Reply

Subtopic 2: Commons:Lolicon guideline or section

[edit]

The thing that pisses me off most in all these related conversations, aside from @JSutherland unilaterally removing files until consensus is reached in DR, is that there are currently no formal rules that dictate lolicon/shotacon, so the complaints of the files being against the rules have no standing. Literally anything can happen. We have a whole category for lolicon, but some files are more controversial than others. I suggest making a full on guideline on lolicon, or at least a subsection of other pages, such as Nudity. That way, there is a concrete set of rules that dictate which content is okay. Obviously, creating a page like this would require a proper consensus of what should and shouldn't be allowed, which is currently absent as discussors here have vastly different opinions, so I decided to create a topic where you can suggest ideas of what to write.

Now, I would propose for all lolicon to be allowed, including explicit ones, as it has an educational purpose and is legal in the US (see my previous comments), but it is clear that a large chunk of people in this convo do not share the same view. So feel free to suggest your ideas here. Dabmasterars [EN/RU] (talk/uploads) 08:59, 18 September 2026 (UTC)Reply

Pinging everyone except for stjn and Gnomingstuff, as they requested not to ping them, as well as some editors not well versed into Commons policies: @JWilz12345, @Thryduulf, @Dronebogus, @Issac I Navarro, @Bawolff, @Gone Postal, @Visviva, @Jrogers, @Abzeronow, @Fæ, @ExtantRotations, @Levivich, @Tazerdadog, @Rhododendrites, @Nux, @OwenBlacker, @Andy Dingley, @Arlo Barnes, @Kordishal, @PARAKANYAA, @Jmabel, @The Squirrel Conspiracy, @Masem and @Gråbergs Gråa Sång. Dabmasterars [EN/RU] (talk/uploads) 08:59, 18 September 2026 (UTC)Reply
The deletions were not for Lolicons existing. Please stop rewriting events to fit this narrative.
The issue is AI created or self published depictions which are clearly seen as CSAM violations. It would be better to back off for a few days and let this case settle down. Any policy clarification is going to need a consensus and is best underpinned on a case book, in fact a case book might result in no extra clarification needed (see how DM relies on a case book), not one extreme case with an otaku narrow vision. Fæ (talk) 09:16, 18 September 2026 (UTC)Reply
This is true, the discussion was started because of the AI file. However, the Super Forbidden Love files were also brought up and have also prompted numerous arguments for and against them. This is why I want a guideline/section, to outline the rules on lolicon front and center, because, chances are, someone else might upload lolicon in the future under the same "it's not explicitly banned, so it is fully allowed within current policies" thoughts as I did. And I'm not trying to rewrite events. If I wanted to rewrite them, I'd just make the page myself with it catering exclusively to my opinions instead of initiating a proper discussion. Dabmasterars [EN/RU] (talk/uploads) 09:49, 18 September 2026 (UTC)Reply
I mean really? You've added porn to Commons that shows children having sex, what did you expect? What was your educational intention when uploading this? In which article did you expect to use that whole storyboard? I'm asking honestly, because I don't want to assume stuff. Nux (talk··dyskusja) 09:06, 18 September 2026 (UTC)Reply
My intention was to illustrate a more explicit side of lolicon, which is currently the most prevalent side if you look at most images tagged as "loli" on Pixiv or Baraag. It serves the same purpose as all the other niche genre examples I also uploaded (such as vore-disposal). Now, most of the latter are in use, but Commons cares about the potential usefulness too. If there would be an article about lolicon porn specifically, or at least a section in the regular lolicon page, then the images are right here to illustrate that.
Point is, every single image I upload on Commons has a purpose. Despite my account being only about 1.5 years old, I am a prolific enough contributor to know most policies and guidelines and understand what should and should not be done. I have a whole folder of freely-licensed Newgrounds porn: I could upload it all if I wanted, but I'm not going to due to most of the files not fitting project scope, as well as some that are fan art that borders the line and are likely PCP-worthy. Lolicon currently has no formal guidelines, and judging on the fact that it has a whole category as well as the countless deletion requests on these images that were kept, I assume it is allowed per the current policies and guidelines. Dabmasterars [EN/RU] (talk/uploads) 09:40, 18 September 2026 (UTC)Reply
@Dabmasterars you can write about it, you don't need to illustrate it. Obviously you should not attempt to illustrate child pornography in pictures, not sure why you think you should illustrate it in drawings. This is just silly to me. Nux (talk··dyskusja) 15:21, 18 September 2026 (UTC)Reply
Personally, I don't think we need any rules other than those that apply to all files (educational purpose, appropriately licenced, legal to host), but if there is to be anything then just slightly tweaking COM:NUDITY to refer to drawings rather than photographs seems sufficient. Thryduulf (talk) 09:12, 18 September 2026 (UTC)Reply
Surely that page needs to refer to photographs. But it could mention children, and drawings/whatever of children. Gråbergs Gråa Sång (talk) 09:31, 18 September 2026 (UTC)Reply
I meant copying it and tweaking it for the purposes of this guideline, sorry that wasn't particularly clear. Thryduulf (talk) 09:36, 18 September 2026 (UTC)Reply
Got it. But COM:NUDITY should mention children, and link to something on that if possible. Gråbergs Gråa Sång (talk) 09:56, 18 September 2026 (UTC)Reply

I think there is value in Commons being able to illustrate the topic, but much as with "normal human penises" it is something where most images should not be welcome. We should have a relatively small, well-curated set of images.

As to the remarks to the effect of "but this content could get someone in trouble in my country": well, so could pictures of swastikas in half of Europe, of women wearing short skirts in several Arab countries, of Falun Gong symbols in Russia and China, any picture showing pubic hair in Japan, maps that show Pakistani claims in Kashmir in India, etc. One of the reasons that Wikimedia chooses on an ongoing basis to host in the U.S. is precisely that the U.S. is a relatively low-censorship country, and I would hope that if that ceases to be the case for the U.S. WMF would begin hosting elsewhere. There is no point to undercutting that by saying "but we won't host any media that could get someone in trouble somewhere else." - Jmabel ! talk 09:54, 18 September 2026 (UTC)Reply

That a good point. Countless images of penises are uploaded every day, but only the highest quality ones are kept. Category:Human penis has over a thousand files in itself and its subcategories, while Lolicon in anime and manga and Shotacon in anime and manga categories have less than fifty combined. I would understand if the deletion of the files I uploaded was due to there being more professional looking ones, but that is not the case. And the comparison of symbols/concepts illegal in other countries that are still hosted on Commons illustrate why catering to US laws is the right way to go. Dabmasterars [EN/RU] (talk/uploads) 10:11, 18 September 2026 (UTC)Reply
One of the problems is that other countries are starting to assert themselves and are starting to make Wikimedia obey their couuntry's laws (Australia successfully took down a decapitation video; Indonesia forced Wikimedia to abide by internet registration laws, etc.) How long until the Philippines demands that Commons obeys their laws as User:JWilz12345 points out or be blocked in the country? Until Australia takes down more files that are illegal in Australia? Some countries might want make examples out of U.S. hosted websites to assert that all content must obey their laws. Abzeronow (talk) 03:01, 19 September 2026 (UTC)Reply
Then we create region locked versions with this template blocking the censored images, only the message is customized (i.e. “Crikey! Can’t show that on an Aussie website!” “Waduh! Can’t show that on an Indonesian website!” “Naku! Can’t show that on a Filipino website!” It’s stupid but it would be a funny way to give the finger to their censorship systems and sho we weren’t complying willingly. Dronebogus (talk) 10:29, 19 September 2026 (UTC)Reply
As funny as it would be to go the South Park way of handling things, it goes against the "Commons is not censored" policy and I still feel like there is a better solution than regional censorship. If we're gonna give a middle finger to the other countries, we might as well pull out completely. That would hopefully create enough backlash for the governments to rethink their laws, though I also understand that that is an extremely optimistic and unlikely scenario. Dabmasterars [EN/RU] (talk/uploads) 10:45, 19 September 2026 (UTC)Reply
There is certainly a precedent in community blackouts and Wikimedia refusing to compromise in order to get unblocked on the Chinese mainland. Dronebogus (talk) 11:05, 19 September 2026 (UTC)Reply
This is absolutely not a hill that anyone should be willing to die on. Even proposing doing a blackout so that you can upload CSAM drawings is insane. Pedophiles ("lolicons") should not feel welcome on this website, simple as that. ArtemisiaGentileschiFan (talk) 04:53, 20 September 2026 (UTC)Reply
I agree that Commons should not be a place that supports and encourages bad faith actors attempting to abuse this project. As we already have policies such as COM:CSAM and COM:CHILDPROTECT that make that clear. I have also made my personal position on this matter very clear and state it again; that I find this subject matter deeply disturbing, and I very much COM:DONTLIKE it. I find it to be the utmost disgusting.
Yet, the way I feel about the subject is separate from what Commons current policies actually say. And putting aside how I might feel, there is the question of COM:INUSE, COM:EDUSE. If anything, several deletion request outcomes including the one in 2010, has reinforced the principle that Commons is not COM:CENSOR.
To the best of my knowledge there is currently, not a policy or guideline that prohibits this particular type of material. On that note, it doesn't even seem to be a prevent issue that Commons even has; given how old Commons is and how this issue to this explicit scale hasn't been discussed to this level until now.
Commons does have a guideline concerning COM:Nudity, and the question of what falls within COM:SCOPE has been discussed to death. That is also why I brought up the Exey Panteleev series before, to better illustrate just how Commons sees scope and what falls under it's standards.
The important point is that Commons hosts a lot of material depicting many subjects that may be illegal, offensive, disturbing, shocking, and over all just very unpleasant things. Many of these files may be prohibited on sister projects because of their respective policies/guidelines, while Commons still COM:HOSTs them.
Furthermore, I don't think the issue is whether this is a “hill anyone should die on,” or whether anyone wants to make pedophiles actually feel welcome. I know I don't.
Yet, Commons need to uphold the precedents that it has. If the WMF actually finds the files illegal then Commons should implement such a policy. I will fully support, ultimately Trust & Safety stepping in might have been the best thing. I am of the position that we should wait for more feedback from the WMF until making a stronger stance Issac I Navarro (talk) 06:16, 20 September 2026 (UTC)Reply
I wasn’t really talking about “CSAM drawings” (a bizarre concept since drawings can’t exa be abused) or even lolicon, but rather the progressively extreme cases that are being spitballed around like images child beauty pageants hypothetically being blocked in the Philippines. But Wikimedia was willing to “die on the hill” of allegedly hosting child porn 16 years ago. Multiple times, actually. Dronebogus (talk) 13:42, 20 September 2026 (UTC)Reply

I think the guidelines should be a clearer version of what I described earlier: 1) do not upload explicit artwork of clearly pubescent or prepubescent children. 2) “explicit” is described as “showing nudity or partial nudity and having a clear focus on explicitly rendered genitalia and/or sexual activity”. 3) “pubescent or prepubescent children” is described as “showing human or humanoid subjects who are unambiguously minors due to lack of physical development associated with puberty.” 4) context clues may be taken into account to ascertain subject age, but should not be the sole determinant. Wearing clothing associated with minors or being depicted in a location or situation associated with minors is not enough. 5) stated/canonical age does not matter, though if an explicit artwork somehow includes mention of a subject being underage in either description, caption, data, categorization, or the work itself the offending content must be removed immediately or the artwork deleted. --Dronebogus (talk) 10:08, 18 September 2026 (UTC)Reply

So if I upload an image of nude muscular clearly adult men (let's assume the image is in use) and say that "they're 5 years old" in the description, that is somehow grounds for deletion? And do non-photograph drawings count as unambiguosly minors? If yes, then why are we catering to that definition? It's legal in the US, so there must be another explanation if we're doing a hard ban on this. And the fact that someone already mentioned a 1900s drawing of children that would technically be against your proposed guidelines. This line of thinking is, in my opinion, flawed. I don't know, maybe I misunderstood you, or maybe you haven't clarified things enough. Dabmasterars [EN/RU] (talk/uploads) 10:23, 18 September 2026 (UTC)Reply
1) The example provided about the “5-year-old” nude man sounds like wildly implausible trolling just to see if a guideline “works” ad absurdum (which it is). 2) drawings count if they pass guideline 3. That’s kind of the whole point, and what I meant by ”artwork”. 3) I guess there should be a guideline 6 exempting historical public domain art from the guidelines. Basically I want to prevent another Super Forbidden Love situation but maintain pretty much all existing content relating to lolicon, shotacon, and similar genres/depictions. Once again, Super Forbidden Love might have been the first legitimate, good-faith, explicit lolicon or shotacon upload in Wikimedia Commons history (I don’t count the alleged fop/de min cases I recently DR’d or the like one troll upload of a Fate hentai doujin I can remember from 2021). Uploading this kind of content is obviously extremely taboo and almost never happens, and it’s apparently considered a legal liability by trust & safety, so making a formal ban on recent explicit depictions of obvious minors (i.e. exactly what SFL is) would not even touch edge cases like the naked AI loli image up for deletion or the one SFL drawing I proposed keeping as non-explicit. Dronebogus (talk) 10:40, 18 September 2026 (UTC)Reply
Dronebogus, that sounds like a clear proposal, would adding another factor from the w:Dost test may be helpful.
1. Whether the focal point of the visual depiction is on the child's genitalia or pubic area.
2. Whether the setting of the visual depiction is sexually suggestive, i.e., in a place or pose generally associated with sexual activity.
3. Whether the child is depicted in an unnatural pose, or in inappropriate attire, considering the age of the child.
4. Whether the child is fully or partially clothed, or nude.
5. Whether the visual depiction suggests sexual coyness or a willingness to engage in sexual activity.
6. Whether the visual depiction is intended or designed to elicit a sexual response in the viewer.
In addition, since you are specifically referring to humanoid characters, I think the proposal should point out cases such as the one (I mentioned above) involving the cartoon horse, and how something like that is not a concern. If identifiable traits are going to be a factor, perhaps the proposal should explicitly define what thoses characteristics are.
Such as the absence of developed human body proportions (as you point out pubescent), the relative length of the limbs compared with the body, and other features that make the character distinctly non-human or otherwise not readily identifiable as a human child. Issac I Navarro (talk) 15:32, 18 September 2026 (UTC)Reply
"developed human body proportions" is a hugely problematic criterion. there are ALL KINDS of stylised artistic depictions of humans (& "humanoids") that DO NOT FIT these standards.
what about DWARVES for one easy example?
actually, this question would apply for both fictional dwarves & adult humans of unusual body-proportions, so NOW you've got issues around "ableism", body standards, etc.... do you SEE THE PROBLEM YET? Lx 121 (talk) 11:07, 27 September 2026 (UTC)Reply

if this is a legal issue, we obviously should follow the law.

(a) In General.—Any person who, in a circumstance described in subsection (d), knowingly produces, distributes, receives, or possesses with intent to distribute, a visual depiction of any kind, including a drawing, cartoon, sculpture, or painting, that—

(1)
(A) depicts a minor engaging in sexually explicit conduct; and
(B) is obscene;

[...]

or attempts or conspires to do so, shall be subject to the penalties provided in section 2252A(b)(1), including the penalties provided for cases involving a prior conviction.

— 18 U.S. Code § 1466A

in the usa, obscenity is defined by the miller test:

It has three parts:

  • Whether "the average person, applying contemporary community standards", would find that the work, taken as a whole, appeals to the prurient interest;
  • Whether the work depicts or describes, in a patently offensive way, sexual conduct or excretory functions specifically defined by applicable state law (the syllabus of the case mentions only sexual conduct, but excretory functions are explicitly mentioned in the majority opinion);
  • Whether the work, taken as a whole, lacks serious literary, artistic, political, or scientific value.

— wikipedia: Miller test

commons should use the miller test in developing a "lolicon" guideline, in line with 1466A. ltbdl (talk) 18:47, 18 September 2026 (UTC)Reply

@Ltbdl, we could also look at w:Ashcroft v. Free Speech Coalition and w:United States v. Williams (2008).
The links to w:Miller test, and w:Miller v. California. Issac I Navarro (talk) 18:57, 18 September 2026 (UTC)Reply
ashcroft deals with the cppa, which is unrelated to 1466A (although it deals with the same subject matter), so i'm not sure i see the relevant. williams deals with "pandering" and is similarly irrelevant to the discussion at hand. ltbdl (talk) 19:09, 18 September 2026 (UTC)Reply

Personally, I would support banning lolicon and shotacon files unless they have significant educational value. Cartoon depictions of sexualized children may be legal in the U.S, but it is not in many countries, and we both want to avoid driving away those who are disgusted by the presence of this, and not attract those to whom lolicon and shotacon appeals to. Given the external threats to the Wikimedia movement, protecting the reputation of Commons is more important than ever, and hosting lolicon and shotacon without strict guidelines would damage our reputation. Abzeronow (talk) 03:45, 19 September 2026 (UTC)Reply

@Abzeronow perhaps I must accept the reality that there is some chance of Wikimedia Foundation platforms becoming eligible for the proposed regulation of social media and online use through online ID verification, even if it is very remote for now. The officials and authorities here are renewing their calls for limited access of minors to social media since we just had the third school shooting incident connected to excessive online access to w:en:True Crime Community forums. But as I said earlier, the platforms currently being dealt with by the authorities here are social media, online gaming, end-to-end encrypted messaging platforms, and fringe websites that host disturbing content like TCC-glorifying websites and platforms. Now, the ball is in the court of the Brazilian ANPD, if they would grant WMF the discretionary carve-out (as a "public good" and public educational service) or not. ANPD's decision may affect Wikimedia's image in the w:en:Global South in the midst of expanding online ID verification laws and bills. Do note that Representative w:en:Brian Poe Llamanzares has explicitly mentioned Brazil as one of the model countries for the online ID verification bills here to restrict minors' access on social media platforms: "Llamanzares noted that similar identity verification frameworks have already been implemented in other nations like Brazil." Hopefully Brazil grants that critical carve-out for Wikimedia, so that WMF would have the legal baggage and basis to show to the government officials of countries in the Global South, including the ASEAN area, that Wikimedia is a non-profit public educational organization in which their platforms have no advertising and do not use content-dictating algorithm. JWilz12345 (Talk|Contributions) 11:49, 19 September 2026 (UTC)Reply
From a session I attended at Wikimania, the person who handles Brazilian stuff sounded optimistic, so maybe things will be fine. Identity verification is a threat to free speech and to Wikimedia though, it should be watched carefully. Abzeronow (talk) 01:16, 20 September 2026 (UTC)Reply
@Abzeronow (also ping some interested parties here @Dabmasterars@Bawolff@Grand-Duc@Tvpuppy@Fæ) as I said, the PH authorities are indeed very proactive and not as lazy as the Turkish court and authorities that requested takedown of CCTV images of a Turkish school shooting incident months before. Just today, they issued a 24-hour ultimatum vs. w:en:Reddit and w:en:Discord, warning that no satisfactory response within the 24-hour period will result to the restrictions of their operations in the country. The responses should cover "enhanced safety standards, rapid-response mechanisms, and age-verification or age-assurance measures." Again, we just had the 3rd NVE-related school shooting violence in just a span of four months. JWilz12345 (Talk|Contributions) 06:50, 22 September 2026 (UTC)Reply
DISCLAIMER: I used Gemini AI response here: To your question: Yes, Philippine authorities are moving past the distinction of whether a platform is traditionally "Big Tech" or not. Their primary trigger for regulatory action has shifted entirely to operational risk and localized harm, specifically when platforms host content or facilitate networks allegedly unsuitable for children. Will Wikimedia be targeted next? Unlikely, but not impossible. Because Wikipedia does not feature private messaging infrastructure, algorithmic amplification of harmful content, or private chat rooms, it does not fit the "high-risk grooming or violence coordination" profile that brought down the hammer on Reddit, Discord, and Roblox. However, if a major controversy regarding local disinformation, cyber-terrorism documentation, or strict age-unsuitable material occurs on a Wikipedia page, the CICC’s sweeping mandate means they could theoretically demand compliance under the same "public safety online" umbrella. For now, though, the CICC is strictly hunting platforms with features that enable real-time child exploitation and anonymous coordination. JWilz12345 (Talk|Contributions) 07:08, 22 September 2026 (UTC)Reply
There are many countries that don't like what we COM:HOST. However, COM:NOTCENSORED. Why should we be deleting files of beauty pageant in order to appease? Issac I Navarro (talk) 07:13, 22 September 2026 (UTC)Reply
"Disinformation" and "age unsuitable material can be literally anything. Does that mean we should ban all porn from Commons, even if it's in use and educational? Does it mean we should delete criticism of the Phillipines because they consider it "disinformation"? This is why I say not bow down to external pressure from governments. Dabmasterars [EN/RU] (talk/uploads) 07:18, 22 September 2026 (UTC)Reply
Thank you for telling me I can ignore that response. Dronebogus (talk) 13:55, 22 September 2026 (UTC)Reply
@Abzeronow at the very least, I don't need to get "concerned" for now. A prominent Internet rigjts group, Democracy.net.ph, condemned the DICT/CICC announcement, warning that their measures on Discord and Reddit are veering the country closer to the approach of the communist mainland China: the w:en:Great Firewall model. Several Pinoy Redditors have also took note of this and suggested circumvention techniques that could help. JWilz12345 (Talk|Contributions) 15:28, 22 September 2026 (UTC)Reply
Perhaps Wikimedia can be exempted as an "enterprise, workplace, or professional collaboration tool" under Section 3(b)(vi) of Senate Bill 2424, considering that Wikipedia, Wikimedia Commons, Wiktionary, and other Wikimedia platforms are collaborative platforms that build freely-licensed professional products for education (Wikipedia), media (Commons), dictionary (Wiktionary), etcetera. The interactions of Wikimedians in talk pages are mainly for collaborative purposes. "Social media platform" is defined (under (d) of the same section) as "any internet-based service, application, website, or computer program primarily intended to enable online social interaction among users and to allow content sharing thereon." "Age-restricted social media platform," per (b), means "any electronic service where (1) The primary purpose, or a significant purpose, is to facilitate online social interaction between two or more end-users; (2) The service enables users to link to, communicate with, or otherwise interact with other users; or (3) The service permits users to create, upload, publish, share, or post content accessible to other users." We can defend Wikimedia Commons as a collaborative platform in which users upload media meant for serious, professional, and realistic educational and/or global research use and not for accumulation of personal clout and fame (like "followers of User:JohnDoe"; no following function on Wikimedia Commons AFAICT). JWilz12345 (Talk|Contributions) 05:04, 23 September 2026 (UTC)Reply
Wikimedia sites do feature private messaging infrastructure: special:emailuser. Arlo James Barnes 17:48, 22 September 2026 (UTC)Reply
Yeah, but it's a bit optional, idk if that matters. And you can't message TA:s at all, which arguably are the bulk of people. Gråbergs Gråa Sång (talk) 17:50, 22 September 2026 (UTC)Reply
I agree that a ban on this kind of content is a good idea. It seems like people in support of loli material have gotten far too comfortable here and on enwiki. It does not matter if it's technically legal in some jurisdictions, common sense should win out here. We should not give any tolerance about this kind of thing, it's a threat to the safety and reputation of this community. ArtemisiaGentileschiFan (talk) 04:58, 20 September 2026 (UTC)Reply
Adopting a zero-tolerance policy to drive out people you perceive to “support loli material” because it’s “common sense” is the wrong approach to the wrong issue. Dronebogus (talk) 14:38, 20 September 2026 (UTC)Reply
External pressure should not be a deciding factor in this argument, see COM:EXTERNAL. Dabmasterars [EN/RU] (talk/uploads) 11:35, 22 September 2026 (UTC)Reply

No to a "lolicon" guideline or section. At issue are illustrated or AI-generated sexualized depictions of children. No need to use that subculture's jargon to distinguish between varieties of it. — Rhododendrites talk |  13:32, 22 September 2026 (UTC)Reply

Only one of the mentioned files is AI-generated, SFL files are all drawn by Casytay. Also, it's not just a jargon: there is a legal difference between a photograph and a fictional drawing, the latter being protected under First Amendment due to having no real victims. Dabmasterars [EN/RU] (talk/uploads) 13:38, 22 September 2026 (UTC)Reply
There are US-laws that treat photos and drawings of kids having sex the same: 18 U.S. Code § 1466A - Obscene visual representations of the sexual abuse of children Gråbergs Gråa Sång (talk) 13:55, 22 September 2026 (UTC)Reply
Only one of the mentioned files is AI-generated - I just mentioned both. it's not just a jargon: there is a legal difference between a photograph and a fictional drawing Yes, it is just jargon. We can talk about drawings without having a "lolicon" guideline. the latter being protected under First Amendment due to having no real victims - As you've argued confidently over and over and over again. — Rhododendrites talk |  14:05, 22 September 2026 (UTC)Reply

Subtopic 3: workshopping an actual guideline on sexually explicit non-real depictions of obvious minors

[edit]

Creating a new section because there’s clearly support for a such a guideline but the exact wording isn’t formulated yet. The current discussion needs to shift away from the why to the how, especially since the “why” frequently devolves into moral-legal arguments and navel-gazing. Dronebogus (talk) 14:45, 20 September 2026 (UTC)Reply

I suggest that we wait for more feedback from the WMF. However, I did agree with and suggest this above. Issac I Navarro (talk) 14:56, 20 September 2026 (UTC)Reply
@Dronebogus, how is your subtopic different from #Subtopic 2: Commons:Lolicon guideline or section directly above? Dabmasterars [EN/RU] (talk/uploads) 15:07, 20 September 2026 (UTC)Reply
Subtopic 2 is basically just filled up with people discussing such a policy in the abstract and arguing why it should be implemented, not discussing what it should actually look like Dronebogus (talk) 15:09, 20 September 2026 (UTC)Reply
Sure thing. I don't know my exact solution, but it will certaintly allow files like SFL (including explicit ones) as long as they're educational or in use. I'll come up with a full text later. Dabmasterars [EN/RU] (talk/uploads) 15:16, 20 September 2026 (UTC)Reply
(Edit conflict) Before getting too into detail, I think it would be beneficial to start a high level and agree a framework around which the guideline is built. To that end I think some of the key questions are:
  1. Should this guideline (which I agree will be beneficial if worded well) cover only humans, both humans and anthropomorphised non-humans or all minors?
    I don't think the third option would produce a useful guideline as it would be too diverse. While there might be a useful guideline to be had around the second I am not convinced that having one guideline cover both cases would be helpful. If it is agreed to take this approach I think starting with the guideline for humans will be better as pretty much every relevant question I can immediately think of has clearer answers.
  2. Should we have separate guidelines on realistic and obviously not realistic depictions or cover them both in one?
    My first thought is that as realism is a spectrum not a binary that a single guideline is probably the better option, but that realism is one factor that should be included in the consideration of individual images.
  3. What is the purpose of this guideline? Preventing harm to real minors? Preventing legal harm to the project? Protecting reputational harm to the project? Preventing harm to people who might view such images? Something else?
    This does sort-of touch on the "Why" question @Dronebogus rightly asks us to move away from but I don't think it is possible to both avoid it completely and come up with a useful guideline: before it is possible to create a guideline that achieves its aims, we need to first know what the aims are.
    I think we can all agree that preventing harm to real minors is a Good Thing, however it is not universally agreed that sexually explicit depictions of non-real minors does actually ham real minors. At the broadest level there seem to be two basic questions:
    • Does the creation or viewing of such material directly harm real minors?
    • Does the creation or viewing of such material indirectly harm real minors?
    The most sober and detailed arguments I've seen regarding the first are best summarised as "mostly no, but possibly if depictions are based on real minors" although the latter depends on detail such as whether a real person is identifiable and what "based on" means in a specific case.
    One argument in support of the the images causing indirect harm is that the creation and viewing of sexually explicit depictions of non-real minors encourages the creation and viewing of sexually explicit depictions of real minors. However others argue that that they discourage the creation and viewing of such images of real minors. Last time I looked (admittedly a while back) I was not able to find any actual evidence that supported or refuted either argument. One comment from (iirc) an academic talking about a related question was that there was almost no appetite to conduct such research and that it would be very difficult (at best) to design a study that would gain the approval of an ethics committee. Thryduulf (talk) 15:29, 20 September 2026 (UTC)Reply
The “why” is a complex of overlapping reasons, some of which are more legitimate than others. The biggest is the legal implications. My personal reason is banning explicit content of this nature would simply implement an already existing best practice that’s existed for years without really being questioned. Dronebogus (talk) 15:46, 21 September 2026 (UTC)Reply
I have given it some thought how the additional wording may be used. To be very specific on the characteristics of what should be excluded. That being infancy, childhood, and adolescencey should be understood as general indicators of a character's apparent developmental stage. (Rogol AD, Roemmich JN, Clark PA. Growth at puberty. J Adolesc Health. 2002 Dec;31(6 Suppl):192-200. doi: 10.1016/s1054-139x(02)00485-8. PMID: 12470915. defines puberty).
As Dronebogus suggests public domain works that have historical significance would not fall under this.
I was thinking we could have the specific wording to define a child as:
Some common physical characteristics of human and bipedal like characters who appear to be young should not be uploaded to Common, include, but are not limited to: the new uploads of an image that depict a child in a explicit way. The specific features of a child as listed below.
  • a) A large head-to-body ratio with the head appearing proportionally larger than it would on a typical adult.
  • b) Shorter or relatively small limbs, including shorter arms and legs and less pronounced muscle definition. (For a/b I was looking at https://www.artistsnetwork.com/art-mediums/drawing/figure-drawing-how-to-draw-a-child to see what feature we should specifically excused/define.)
  • c)A rounded face with softer facial features.
  • d) Limited development of sexual characteristics associated with puberty, such as but not limited to facial hair or pronounced breasts.
I was looking at some of https://pmc.ncbi.nlm.nih.gov/articles/PMC10477785/ diagrams that they use to illustrate body proportions. There is also https://design.tutsplus.com/tutorials/human-anatomy-fundamentals-drawing-different-ages--cms-21905 that I found to be specific for drawing styles of child proportions. Any thoughts or notes on things that should be changed or added? Issac I Navarro (talk) 19:50, 21 September 2026 (UTC)Reply
This suggestion is intended to fall under Dronebogus' proposal 3 Issac I Navarro (talk) 19:53, 21 September 2026 (UTC)Reply
@Arlo Barnes@Dabmasterars@Gråbergs Gråa Sång, I noticed that you been working on Commons:Nudity/children, any thoughts or suggestions for this (above)? Issac I Navarro (talk) 01:46, 23 September 2026 (UTC)Reply
I don't really have grand plans for it, just seems like the sort of thing a bunch of different people need to be slightly dissatisfied with until they can put their finger on it and make or propose the needed edit. A redirect I created today, COM:jurisdiction leads to COM:general disclaimer, where I noted a reference or two to the Universal Declaration of Human Rights. While international law is pretty different than national law despite being based in it, it's interesting to me that Article 26 of the UNDHR starts with "Everyone has the right to education." and concludes with "Parents have a prior right to choose the kind of education that shall be given to their children." The latter seems reminiscent of the demands of the parental rights movement, although given that the Declaration is from 1948 it's probably ahistorical to connect those moments in history without intervening events. Anyway, that's all to say that there is much verbiage that could apply here, but what is actually useful for Commons' purposes? Arlo James Barnes 03:23, 23 September 2026 (UTC)Reply
Not atm. Gråbergs Gråa Sång (talk) 08:00, 23 September 2026 (UTC)Reply
@Issac I Navarro: your definition of a child is bound to fail if it contains your bullet points a and b (with "a large head-to-body ratio with the head appearing proportionally larger than it would on a typical adult." and "shorter or relatively small limbs, including shorter arms and legs and less pronounced muscle definition.") Please take a look at en:Chibi (style) or visit any video game or similarly-themed merchandise shop selling en:Funko wares. You'll find figurines of e.g. Albus Dumbledore, Gandalf or Severus Snape that actually fulfil your definition with a large head-to-body ratio and short limbs, despite unequivocally being representations of adult characters. You can't even rely upon the depiction of a en:baby schema in humans, as exactly that is at times an aim to reach for aesthetic surgeons or naturally occurring in people past the age of majority. Regards, Grand-Duc (talk) 09:53, 23 September 2026 (UTC)Reply
@Grand-Duc, I appreciate the feedback. I added a and b to be helpful indicators. You are absolutely right about the chibi, and funko styles.
When typing it up, I had the thought all the traits below had to be defined to some degree. I wanted to draft something that would be easy to read and easy to grasp. If I was to add a clause above stating that "all these factors must present but not limited to:" would that fix the issue? Or should this whole idea be scrapped? Issac I Navarro (talk) 10:05, 23 September 2026 (UTC)Reply
By cutting out a and b would that fix the issue? Issac I Navarro (talk) 10:07, 23 September 2026 (UTC)Reply
Probably yes. And it could be a useful thing to put in a reference to the en:Convention on the Rights of the Child it defining a child as any human below the age of 18. That must not be a strict limit, older teenagers have legally already some rights about their likenesses, but as an international baseline, it should serve well. And we should avoid any definition of a child based upon physical or visual characteristics alone (safe for blatantly evident cases, nobody could mistake a toddler for being an adult, for instance). Regards, Grand-Duc (talk) 10:15, 23 September 2026 (UTC)Reply
Also "looks like a child" isn't the be-all per policy and law, hence we don't see w:Traci Lords early work around these days. Gråbergs Gråa Sång (talk) 10:10, 23 September 2026 (UTC)Reply
Lasty, for some of my final thoughts; I thought that since something like this indicator I drafted could be a subsection of a larger definition. The context clues of the other text would be obvious that it is not about chiibi. I drafted it with Dronebogus' 3 in mind "pubescent or prepubescent children” is defined as “showing human or humanoid subjects who are unambiguously minors due to lack of physical development associated with puberty.”" Issac I Navarro (talk) 10:14, 23 September 2026 (UTC)Reply
I think there should be examples of things that are generally exempt, namely chibi characters, “oppai lolis”, depictions of canonical minors that don’t look like minors, “shortstack” characters, etc. Dronebogus (talk) 19:15, 23 September 2026 (UTC)Reply
 Oppose this standard FAILS the test for "chibi" & various other stylised/caricature drawings. (as already partly stated above) & what about "caricatures of adults as minors"? like trump's head on a baby-toddler body (or baby-doll), perhaps with a fully load diaper or with excrement (or if you want to bowdlerise it slightly, a string of bs-sausages) coming out of his mouth?, just for one rich political-cartoon example? & WHAT ABOUT SOUTH PARK? (aka "south america" rn) Lx 121 (talk) 03:02, 27 September 2026 (UTC)Reply
@Lx 121 You may find Commons:Nudity/children, and it's Talk interesting. In addition to it's proposals below. Issac I Navarro (talk) 03:13, 27 September 2026 (UTC)Reply


My personal proposal is:

1) do not upload explicit non-real depictions of clearly pubescent or prepubescent children.
2) “explicit” is defined as “showing nudity or partial nudity and having a clear focus on explicitly rendered genitalia and/or sexual activity”.
3) “pubescent or prepubescent children” is defined as “showing human or humanoid subjects who are unambiguously minors due to lack of physical development associated with puberty.”
4) context clues may be taken into account to ascertain subject age, but should not be the sole determinant. Wearing clothing associated with minors or being depicted in a location or situation associated with minors is not enough.
5) stated/canonical age does not matter, though if an explicit artwork somehow includes mention of a subject being underage in either description, caption, data, categorization, or the work itself the offending content must be removed immediately or the artwork deleted.
6) non-real explicit depictions of obvious minors old enough to be in the public domain are not covered by this guideline.


--Dronebogus (talk) 14:53, 20 September 2026 (UTC)Reply
We could more or less copypaste the text at Policy:Wikimedia_Foundation_Combating_Online_Child_Exploitation_Policy#Prohibited_content and the following section. Gråbergs Gråa Sång (talk) 15:10, 20 September 2026 (UTC)Reply
Except that policy doesn’t explain why the Martin van Maele drawings of children engaging in sexual acts are somehow okay and exempt from consideration. Granted my proposal doesn’t either, but it makes it clear they and files like them somehow are exempt. Dronebogus (talk) 15:13, 20 September 2026 (UTC)Reply
It's "okay" because Wikimedia Commons is biased towards old content. Seemingly anything goes, while modern high quality depictions get rejected for policies that aren't as often applied to old art. Your idea of specifically excluding it is just unfiltered bias. Dabmasterars [EN/RU] (talk/uploads) 15:20, 20 September 2026 (UTC)Reply
I’m simply reflecting what biases were already there. My proposal is absolutely the most conservative, being drawn around existing content more or less precisely. The reason for that is the same reason you shouldn’t try to build in a minefield but also shouldn’t expand the same minefield into safe areas. Dronebogus (talk) 15:24, 20 September 2026 (UTC)Reply
Afaict, that policy is from 2024. If you point those pics out to WMF legal, maybe they'll delete them at this point in time. My reading of that policy is that even if "they provide educational, medical, or scientific value in support of Wikimedia's free knowledge mission", they are disallowed if they include the "Prohibited content" stuff. Gråbergs Gråa Sång (talk) 15:36, 20 September 2026 (UTC)Reply
I don’t think they will because they pass the miller test and the “clearly educational” text by illustrating the work of a notable artist. Dronebogus (talk) 15:38, 20 September 2026 (UTC)Reply
Whatever the WMF legal position, it would be interesting to know. Afaict from some I just looked at, a lot (perhaps most) of the Martin van Maele pics on Commons seem to be unproblematic. Gråbergs Gråa Sång (talk) 15:53, 20 September 2026 (UTC)Reply
"humanoid" is problematic. that covers a range from chimps & bonobos, etc., to (some) furries & mythological creatures like gargoyles, deamons, etc.
for that matter, what do we do about mythological/folkloric/religious depictions that would technically violate the cited standards? (like ganymede just for one easy-obvious example. i'm sure there are plenty of other instances, across human cultures, across history) Lx 121 (talk) 10:41, 27 September 2026 (UTC)Reply
for that matter CONTEXT is also HUGELY important here, in general. what if it's a cartoon-comic of a person describing their own life experiences? or a textbook depiction to explain/educate/warn? or a fictional work that depicts such activities negatively? "one size fits all" just doesn't cover such contingencies. Lx 121 (talk) 11:19, 27 September 2026 (UTC)Reply
Just asking: the child pornography as penned in en:Josephine Mutzenbacher would be OK to host under the proposed guideline? It's old, notable by itself, PD and subject to notable commentary (de:Mutzenbacher-Entscheidung), so most obviously within Commons' scope. At least it's good enough for me to reject any blanket ban, a case-by-case dealing is the only option IMO. Regards, Grand-Duc (talk) 09:04, 21 September 2026 (UTC)Reply
Nobody cares about text anymore unless it involves gay people and it’s in a school library. Dronebogus (talk) 15:14, 21 September 2026 (UTC)Reply
Perhaps a question for w:bar:Text Dischkrian:Start? Arlo James Barnes 22:10, 21 September 2026 (UTC)Reply
Case by case is the only option, I'm afraid. Also, the fact that the file is old enough to be public domain should only be relevant to the copyright status. If we want to illustrate controversial topics, we need good examples, and old does not automatically mean good. Dabmasterars [EN/RU] (talk/uploads) 22:24, 21 September 2026 (UTC)Reply
Okay then. You wanna hear my two cents? Well, I propose separating real photographs of minors (as well as realistic depictions) and non-realistic depictions (including lolicon and non-realistic 3D models) into two separate camps. The former should be deleted on sight if it is verified is sexual, while the latter should be determined by the project scope (including COM:INUSE and potential future use) just like regular porn. By this definition, files in Category:Super Forbidden Love should get undeleted regardless of their explicitness, with the only ones that stay deleted being the ones that have little educational value. The perceived realism should be determined by a case by case basis; when in doubt, COM:PCP applies. Any questions? Dabmasterars [EN/RU] (talk/uploads) 11:52, 22 September 2026 (UTC)Reply
Per my recollection, you won't get most or any of the deleted Category:Super Forbidden Love pics past Policy:Wikimedia Foundation Combating Online Child Exploitation Policy, "Prohibited content" section. I suggest you drop the effort to get any pics of kids having sex, masturbating etc uploaded to any WMF project. Gråbergs Gråa Sång (talk) 12:31, 22 September 2026 (UTC)Reply
[edit]

Hi everyone,

This is a follow up to our previous post, hopefully providing some more information about our COCE Policy, currently applicable law, and the overall environment. It's a bit long, so I made it into its own subtopic on this discussion. But if I have erred in where to put it, please feel free to move it around as you think best.

US obscenity law: The standard for determining obscenity in the US hasn’t changed in many years and is still based on the Miller test - although it is receiving increased attention (and criminal law reforms) in response to the generative AI revolution (see for instance California Penal Code section 311.11(2), amended in early 2025 to explicitly criminalize the distribution of “digitally altered or artificial-intelligence-generated data depicting what appears to be a person under 18 years of age, engaging in or simulating sexual conduct”, if you know that the material is obscene).

The Miller standard is, however, intentionally very vague and asks three subjective questions that reflect overall social sentiment. These are

  1. Does the work appeal to prurient interest (meaning is it for sexual arousal)?
  2. Does the work depict sexual or excretory content in a patently offensive way?
  3. Does the work lack serious literary, artistic, political, or scientific value?

If the answer to all 3 questions is yes, then it’s obscenity (and a crime in the US as a result). If any of them are a no, then it’s not obscenity. Because these are inherently fuzzy questions and the answers may differ, The Foundation generally treats this as a very high standard: many, many works don’t fit. Most medical anatomy photographs, for example, aren’t for the prurient interest, while many historical works have serious literary or artistic value because of their age and the insight they offer into the lives of people in the past. And a lot of drawings that are in the Barbie doll style or similar aren’t patently offensive. And of course, different people are going to have different views of what’s patently offensive. On this point, it does matter to some extent whether we get complaints and how many complaints we get: A work that generates a lot of complaints is one piece of evidence towards finding that it’s patently offensive.

In the case of the removals we did, our view is that the extremely graphic depiction of obviously young people engaged in sexual acts fit all three factors. The community discussion was also procedural: few people were really making any case for the works having any sort of serious educational value (using educational as a shorthand for the 4 things from the Miller test). As I mentioned in my earlier post, we did also take the works as a set, leaving only a couple that didn’t depict any sexual acts at all.

Our COCE Policy: Since the law here is vague, we’ve tried to make a policy that goes into more specifics and aims to strike the right balance between identifying prohibited material and the needs of our projects including the need to educate people about sexual topics and related cultural topics. We didn’t use the exact same words as the Miller test, but you can see us going towards approximately the same end: we say that things like lolicon are okay, in rare cases, if they have “demonstrable educational value.” In practice, that means they need a strong case for their educational value, not just a vague possibility that they might be useful. We also think educational value can start dropping off with redundant images: having a few borderline images in various styles on Commons that are needed for use in articles about artistic styles and trends can be educational, but collecting more than a few becomes less so. The educational goal is to help the reader understand what’s being discussed, and that rarely requires more than a handful of examples.

Gratuitous examples might be particularly unwelcome, too: it’s a longstanding principle of the Wikimedia projects that content should be presented to readers in such a way as to respect their expectations of what any page or feature might contain. This also links back to the “educational purpose” analysis I just mentioned: careful selection and presentation of content can also maximize the range and number of education settings in which it can be presented. That can significantly enhance one image’s educational value compared to another.

Finally, a separate section of the COCE Policy also prohibits content that promotes, supports or encourages child exploitation. The “Super Forbidden Love” images, due to their design and content, raise very serious questions regarding the intentions of persons involved in the creation and distribution of those images.

Global laws: In addition to the US law rules, we wrote in 2024 about the way that many new internet regulations are structured to reach beyond the borders of the countries that write them. Many of them go beyond the US obscenity law position; for example, the vast majority of the 48 signatories to the Council of Europe’s Convention on the Protection of Children against Sexual Exploitation and Sexual Abuse, a.k.a. Lanzarote Convention, explicitly include sexualised drawings of children in the scope of their child pornography laws (Article 20(2): “the term “child pornography” shall mean any material that visually depicts a child engaged in real or simulated sexually explicit conduct or any depiction of a child’s sexual organs for primarily sexual purposes”. The treaty’s many signatories had the option of excluding “simulated representations (...) of non-existent children”, but our understanding is that only a small minority of countries have done so. Many jurisdictions also (or in the alternative) require a more vague sort of legal analysis that considers risks to society and what sorts of risk mitigation systems are in place. While the applicability of these laws to specific images has to be determined case by case, it is worth looking at here. One of the reports to us related to Dabmasterars uploads came from an EU trusted flagger organization. Being a trusted flagger doesn’t mean we have to do whatever they tell us and they can definitely make mistakes. As an example, without going into specifics here, we are currently legally defending a different image which features child nudity, that we believe is a rare case where there is very substantial educational merit and that was misclassified by a trusted flagger and a country’s authorities. But, we are required by the EU DSA, which we do think applies to us, to pay attention to reports from Trusted Flagger entities and ensure that we give them priority review. And this whole structure is pretty new: the DSA went into effect in 2023 and it took most organizations a year or two to deal with all the bureaucracy necessary to be a trusted flagger. We might expect more of these reports in the future over borderline illegal content. This makes having a clearly articulated educational value even more important because it’s the educational value that gives us the basis to pushback on takedown demands.

One final note: many experienced Commons users were reasonably concerned about liability and reputational risks that people (and the project as a whole) might face in connection with the series of images we deleted here. We are aware that originally, a Commons admin removed them. The way that admin did it prompted understandable questions about the community’s current deletion procedures. Even so, at least as a matter of the COCE Policy and applicable law, we think that admin was trying to do the right thing and want to offer our thanks for them and anyone who chooses to help deal with this kind of content on the Wikimedia projects.

I hope all this is helpful info. -Jrogers (WMF) (talk) 00:31, 23 September 2026 (UTC)Reply

Thank you, for the feedback. Issac I Navarro (talk) 00:35, 23 September 2026 (UTC)Reply
Thank you for the detailed response. I shall read it again when I'm more awake but at least at a first read level it appears to answer at least most questions I had. Thryduulf (talk) 01:12, 23 September 2026 (UTC)Reply
Why did you delete File:Nooshafarin02.jpg? It was a still of a topless adolescent girl from a mainstream film, which this poster is based on. Does that mean everything in Category:Topless adolescent girls is illegal? That seems like a troubling precedent if so. Dronebogus (talk) 01:39, 23 September 2026 (UTC)Reply
I'd be more concerned that you want blanket retention of topless pictures of adolescent girls. Spartaz (talk) 16:35, 1 October 2026 (UTC)Reply
Don’t personalize a discussion like this. Dronebogus (talk) 16:39, 1 October 2026 (UTC)Reply
If the cap fits... Spartaz (talk) 13:58, 2 October 2026 (UTC)Reply
Both this comment and the comment Dronebogus called out are, at best, unhelpful, and at worst deeply inappropriate. It is never appropriate to personalise disputes, let alone to double down on doing that. It's fortunate for you that I am not an uninvolved administrator. Thryduulf (talk) 14:23, 2 October 2026 (UTC)Reply
but it's ok to equate my reasonable comment about society's perception of obscenity being a social construct and therefore liable to change with the way the Taliban oppress women or the Russian government persecutes lgbti+ people? Spartaz (talk) 16:32, 2 October 2026 (UTC)Reply
That's a comment on your argument not a comment on you as a person. If you cannot see the difference then you need to learn to see it if you wish to contribute to discussions. Thryduulf (talk) 20:40, 2 October 2026 (UTC)Reply
I am pretty sure that Dronebogus says about blanket deletion, not blanket retention. It is different things. Evelino Ucelo (talk) 10:51, 3 October 2026 (UTC)Reply
Spartaz, I agree with Thryduulf, let's not get into ad hominem stuff. Might be better to not engage if you can't keep your comments limited to Dronebogus's arguments. Abzeronow (talk) 03:10, 4 October 2026 (UTC)Reply
Can we hat this thread? It seems off topic. Issac I Navarro (talk) 03:26, 4 October 2026 (UTC)Reply
Perhaps because some setting or context. But clarification still be good thing for transparency. Evelino Ucelo (talk) 10:24, 3 October 2026 (UTC)Reply
Thank you, this helps. Gråbergs Gråa Sång (talk) 03:41, 23 September 2026 (UTC)Reply
Thank you, the Miller test is indeed very vague for artwork which is subjective. - Knowledgekid87 (talk) 14:53, 23 September 2026 (UTC)Reply
@Jrogers, does a file being in use count as "demonstrable educational value"? Dabmasterars [EN/RU] (talk/uploads) 16:19, 23 September 2026 (UTC)Reply
As long as we do not have global editorial standards I would say no, only being in use on some project is not sufficient here. GPSLeo (talk) 05:21, 26 September 2026 (UTC)Reply
Agree. And sometimes the uploader and creator is the person who added it on other projects, that's fairly obviously not a good criteria. Gråbergs Gråa Sång (talk) 10:42, 26 September 2026 (UTC)Reply
DISAGREE strongly - "in-use" (on other wm projects) is a primary purpose, function,& part of WMC, & COMMONS SCOPE. IF a file is in-use, & it is not copyvio or otherwise illegal, then you must sort things of on the OTHER wm project first, BEFORE deletion here. Lx 121 (talk) 02:39, 27 September 2026 (UTC)Reply
It is deeply disturbing how many people are unwilling to accept changing cultural standards and expectations. Obscenity is broadly a cultural construct and we don't need a lady Chatterley type trial to establish a changing boundary. Spartaz (talk) 16:38, 1 October 2026 (UTC)Reply
“It is deeply disturbing how many people are unwilling to accept changing cultural standards and expectations” would you tell that to the gays shoved back in the closet by Russia’s anti-LGBT law and the women shoved out of the public space by the Taliban? Is every reactionary social movement actually just “changing cultural standards and expectations”? Dronebogus (talk) 16:43, 1 October 2026 (UTC)Reply
Are you asking whether I'm still beating my wife? On the subject of deeply disturbing, it's concerning how you immediately reached for the "equating this kind of content with gay people" card. Equating society's right to consider material sexualising young people as obscene with people demonising lgtbi+ people or persecuting women in Afghanistan is just... Weird. You need to get into the real world a bit more. Spartaz (talk) 13:56, 2 October 2026 (UTC)Reply
Does "demonising lgtbi+ people or persecuting women in Afghanistan" mean actual actions against them or fictional drawings of demonization that don't harm anyone directly? Dabmasterars [EN/RU] (talk/uploads) 14:36, 2 October 2026 (UTC)Reply
(Reposted from noticeboard) I was making a hyperbolic, ad absurdum comparison that had nothing to do with you as a person. I wasn’t saying “if you think sexualized images of children are obscene you’re a bigot just like these examples”, and certainly not implying you were a homophobe or a misogynist; I was drawing a comparison between your appeal to social values changing to be more conservative on nude minors and sexual depictions of fictional minors and the arguments these people use to advance their patently unreasonable (from a progressive western point of view) positions. You seem to see the increased criminalization of this kind of imagery as a good thing, protecting society from obscenity and sexual degeneracy; but I see it as a moral panic targeting either innocuous material or victimless crimes and creating a chilling effect on free speech). Similarly supporters of the Russian anti-gay law would say they were protecting society from obscene and degenerate behavior. Tl;dr I was trying to say “don’t appeal to society’s mercurial definition of acceptability, especially when it comes to the de-liberalization of certain laws and values, to justify cracking down on things you don’t support; because that same argument can be used to crack down on things you do support”. I’m sorry if it came across as comparing you to, or implying you were the moral equivalent of, the Taliban. Dronebogus (talk) 19:56, 2 October 2026 (UTC)Reply
Excuse me? It is not "deeply disturbing how many people are unwilling to accept changing cultural standards and expectations." It is in fact normal that people object to cultural standards changing; rules our culture has set changing is alienating in many cases, and to people who have internalized those rules, wrong. This goes double when we aren't talking about just cultural standards, but cultural standards embedded into laws. For example, there was a publication about London's prostitutes, a review/guidebook, that was published for decades and then around 1800, saw the publisher arrested for obscenity. Whatever you say about such things, the law shouldn't silently change to make what was once legal illegal.
And all this further stuff is just moving the goal posts, because you didn't really mean that; you meant "It is deeply disturbing how many people are unwilling to accept changing cultural standards and expectations in directions I approve of". Which is an entirely different and more unreasonable assertion.--Prosfilaes (talk) 02:00, 4 October 2026 (UTC)Reply
Obscenity should only be defined legally. We have other guidelines and policies that help us with moral rights and creepshots. I'm less concerned about what dictators think, and more concerned about bureaucrats in democracies that have stricter laws on the depiction of children and also on the depiction of extreme violence. Abzeronow (talk) 03:24, 4 October 2026 (UTC)Reply
There is a RfC at en:Talk:Lolicon#RfC Should this be characterized in relation to CSAM?, where I cited some sources from the United Nations calling it: "In particular, Japan has been singled out as a major producer of sexually exploitative representations of virtual children in subgenres of manga comics, anime (cartoons), computer graphics." Issac I Navarro (talk) 03:30, 4 October 2026 (UTC)Reply
Unambiguously yes. If you disagree that the use is educational and that there is no possible educational use, then remove it (ideally with consensus) first. Thryduulf (talk) 11:19, 26 September 2026 (UTC)Reply

Subtopic 6: Historical materials

[edit]

Since this has turned into a giant topic-cluster on 'nudity & minors' (& the whole pile-on has got unmanageably long to read through entirely) has anyone made the necessary carve-outs for historical, & artistic materials (like old photographs, historic-ancient sculpture, mythology, old textbooks, & for that matter, for nudism/naturism/fkk, etc.) ?

because, in the assorted policy change proposals that i see scattered around in "here" (& on the related, subsequent discussions), there doesn't seem to be very much mention of those considerations? Lx 121 (talk) 02:53, 27 September 2026 (UTC)Reply

No matter how much detail Commons documents go into, it also comes down to common sense. Recently made images will usually be under more scrutiny than those made a long time ago, nonsexual nudity is generally contrasted with obscenity or prurience -- although of course opinions vary. And I think nothing has really changed since the thread started except most of a category of comic pages mentioned above was deleted, thus adding a case study. Arlo James Barnes 07:35, 27 September 2026 (UTC)Reply

improve handling of wrong exif location

[edit]
Latest comment: 8 days ago10 comments3 people in discussion

I checked some files in Category:Ambiguous location in EXIF (~53000 files) and found two main cases:

In the first case, if this is a parsing problem, any idea where to request a fix?

In both cases neither {{GPS EXIF}} nor {{GPS EXIF ambiguous}} are of any help and should be omitted completely (there is no semantic difference between files with location as above and files without any exif location). For above cases, files having one of these two templates already, remove them. Both need a script that can evaluate Exif accordingly.

Rationale: Uploaders rarely do care and for the community it's too much. So in general it will not happen and the marker {{GPS EXIF ambiguous}} is of no use. Having to mark all files that do not have sound location with Category:Location not applicable is manual work just to conform to the bots. We should concentrate on files, where there is a realistic chance to get proper locations. In many cases files are embedded into a category with {{Object location}}, which is sufficient also for the file. Btw. requesting {{Location}} is quite error prone, it is easier to request {{Object location}} in {{GPS EXIF ambiguous}}.

For the first case, where real location info is likely, consider to add {{Location possible}} instead of {{GPS EXIF ambiguous}}.

@Multichill and Rkieferbaum: who handle these cases and could easily improve handling. best --Herzi Pinki (talk) 20:03, 18 September 2026 (UTC)Reply

@Herzi Pinki Both issues are problems in the original uploads. For the first one, the image claims "17056881.853375/17056881.853375" (aka, a couple of spins around the world). For the second 0/0. Both are technically allowed values on a globe. Unlikely to be correct, but difficult to distinguish as they are technically valid. Are you asking the bot maintainers to recognize these 2 very specific situations and to treat them differently ? It's often difficult for bots to make assessments of valid but unlikely data, as that is purely a human interpretation (and one of the reasons why we don't make that assessment in MediaWiki software either). The valid data was provided, and this is the claim being made by the image producer (consciously or not). —TheDJ (talk • contribs) 20:43, 18 September 2026 (UTC)Reply
I'm considering to optimise the workforce assignment. We can fill up maintenance categories for slavishly following principles, or we can do productive and meaningful work. (0/0) is almost never a valid location, just a default, and images that are at (0/0) can be georeferenced by the uploading user. For your example of "17056881.853375/17056881.853375" (it is only that value, not similar ones) the parsing can be improved to yielding a value in [(-180, +180)/(-90, +90)], but I doubt that we can spin around the globe for latitude, latitudes outside [-90,+90] are not well defined. Google maps, btw, does not recognise a value of 17056881.853375/17056881.853375 as a coordinate. Performing the mod operation gives -> 81.853375/81.853375 ->
Camera location81° 51′ 12.15″ N, 81° 51′ 12.15″ E Kartographer map based on OpenStreetMap.View all coordinates using: OpenStreetMapinfo

,

which is in the north polar ocean and also quite unlikely that we have any images at that very location. After all, it is just a proposal. --Herzi Pinki (talk) 21:11, 18 September 2026 (UTC)Reply
Bots should automatise standard processes, not create endless work for humans. --Herzi Pinki (talk) 21:18, 18 September 2026 (UTC)Reply
if you look at "17,056,881° 51′ 12.15″ N", the 2nd half "51′ 12.15″ N" looks quite similar in format to the actual latitude of Bruges, 51° 12′ 32″ N. maybe it's not 51′ 12.15″ N but "51 degrees 12.15 seconds N" or "51 degrees 12 seconds 15 thirds N". RoyZuo (talk) 06:52, 19 September 2026 (UTC)Reply
the actual cam location is roughly 51.21175, 3.2262 or 51°12'42.3"N 3°13'34.3"E .
maybe that's just a coincidence, or gps drift then corrupted data. RoyZuo (talk) 07:24, 19 September 2026 (UTC)Reply
@RoyZuo: seems to be constructed: see
  • Milan
    Milan
  • Vienna
    Vienna
  • Helsinki
    Helsinki
  • Berlin
    Berlin
  • Malmö
    Malmö
  • Venice
    Venice
all having the same broken exif data, these are just taken from the files by User:Nemo bis: ~1880. So there will be more. (don't know how to search for exif data) best --Herzi Pinki (talk) 10:54, 19 September 2026 (UTC)Reply

Not satisfied: AI says: The value 17056881.853375 is a well-known bogus GPS coordinate. It is automatically embedded into EXIF metadata by certain Panasonic Lumix cameras when they fail to establish a GPS satellite lock before capturing an image. It stems from the camera writing the maximum buffer value 16777215 (0xFFFFFF) for degrees and minutes. - which is a good explanation for the value. I'm still proposing to handle this value and (0/0) differently than others. Not to remove the responsibility for uploaders to correct their erroneous coordinates, but to ease the task for maintainers. One way would be to split {{GPS EXIF}} or {{GPS EXIF ambiguous}} into these three cases. best --Herzi Pinki (talk) 16:09, 26 September 2026 (UTC)Reply

Also: {{Object location}} should be considered a good replacement for missing / wrong {{Location}}. The former is easy to read from maps, while the later is almost impossible to get correctly. --Herzi Pinki (talk) 16:12, 26 September 2026 (UTC)Reply

Some images like File:Kwaliteitswerk.jpg just pretend to contain geo-info in exif: nördl. oder südl. Breite: nördl. Breite and östl. oder westl. Länge: östl. Länge, and no numerical values. --Herzi Pinki (talk) 14:06, 27 September 2026 (UTC)Reply

Ban AI generated content depicting nude people

[edit]
Latest comment: 4 hours ago50 comments26 people in discussion

In an attempt to start solving some of the problems currently discussed, I propose to add the following rule to Commons:Nudity:

  • "All AI generated content depicting nude people that is not in use is considered out of scope."

AI generated content is not suitable for educating about biology, anatomy or diversity. These files therefore lack an educational value. Additionally, the training material used to create these images is primarily based on nude people in sexual situations; this creates a problematic bias. With such a simple rule, we also do not need to discuss the age of fictive people. GPSLeo (talk) 06:11, 19 September 2026 (UTC)Reply

I don't really think that solves the problem. If the image in question that started this all was drawn by hand, i dont think that would have changed anything. That said, having a rule like this is a start, it will help prevent the deluge of gross spam that is undoubtedly coming and there is basically no valid educational use case for AI generated nudes. So I  Support, but i hope this isn't the only policy change that comes out of this debate. Bawolff (talk) 06:44, 19 September 2026 (UTC)Reply
 Support AI is famously bad at generating pixels depicting correct anatomy, so I would agree. It got better, but there still problems especially in cheaper and older AI models... But those old AI models are also exactly what is unlocked and able to generate nudity at all. Nux (talk··dyskusja) 09:50, 19 September 2026 (UTC)Reply
 Strong oppose we wouldn’t be able to depict w:Generative AI pornography, which is one of the more notable uses of generative AI. GPSLeo has been having a pro-censorship conniption after the recent incident where they weren’t allowed to speedy delete in-scope files using blatantly incorrect rationales. Dronebogus (talk) 10:39, 19 September 2026 (UTC)Reply
iDronebogus please don't make this personal. Also, the images were removed anyway. Nux (talk··dyskusja) 12:40, 19 September 2026 (UTC)Reply
It’s not “personal” when it’s obvious what the motivation is: if you can’t win within the rules, change the rules to win for you. Dronebogus (talk) 13:22, 19 September 2026 (UTC)Reply
@Dronebogus belive me, you don't want to go there. You can assume a lot about people that are upload porn to Commons. And most would not be good things. Let's not play this game. Nux (talk··dyskusja) 13:29, 19 September 2026 (UTC)Reply
Maybe I shouldn’t have commented on what I think the intent here is. But it’s clear this is part of a pattern of unacceptable behavior from GPSLeo: first they deleted controversial images in a wildly out of process msnner, then they expressed the opinion that such content isn’t worth keeping anyway, now they try to create a novel framework to enable sysops to delete controversial images more easily. Dronebogus (talk) 13:40, 19 September 2026 (UTC)Reply
Also, every image in w:Generative AI pornography is actually erotic and non-nude people. So I don't see the problem. Nux (talk··dyskusja) 12:43, 19 September 2026 (UTC)Reply
The Russian page has nude AI sex used as an example, though that one was not added by me. Dabmasterars [EN/RU] (talk/uploads) 12:50, 19 September 2026 (UTC)Reply
Which only shows that you can illustrate this articles without explicit images. Nux (talk··dyskusja) 13:22, 19 September 2026 (UTC)Reply
File:Reverse ekiben sex position.png is not explicit? Gråbergs Gråa Sång (talk) 17:47, 20 September 2026 (UTC)Reply
@Gråbergs Gråa Sång it is, but it is only used on one wiki and not the biggest one. Nux (talk··dyskusja) 17:56, 20 September 2026 (UTC)Reply
So only enwiki is important now? Coming from someone with 54,000+ edits on Plwiki? Dronebogus (talk) 15:42, 21 September 2026 (UTC)Reply
The proposal had a carve out for in-use files, so I don't think your objection makes sense. Bawolff (talk) 05:45, 20 September 2026 (UTC)Reply
Oh, I completely missed that part too. I still feel a blanket ban is unwarranted since most non-educational use AI tends to get deleted anyway, but the guideline technically allows that Stability Matrix image to exist (in use), so I won't argue much against that. Dabmasterars [EN/RU] (talk/uploads) 09:16, 20 September 2026 (UTC)Reply
I think most if not all unused AI files should just be deleted anyway. The nudity category actually has a much higher-than-average number of in-use files— nearly 100%, actually, with the unused one already up for deletion as out of scope. What problem is this proposal addressing again? Dronebogus (talk) 15:39, 21 September 2026 (UTC)Reply
 Oppose Subject to way too much interpretation. If the main issue is to avoid AI generated unwanted or intrusive photorealistic "declothing" of real people and especially minors, then propose a clarification and make it grounded in real deletion request outcomes. This may take a bit of work and analysis, but it's a great way to make a policy change meaningful and operationally realistic. Counter examples - AI re-drawings of famous historic artworks might be valid content if they have a footprint of public impact, AI manipulated restorations might be valid if the original works are unusable quality, AI anonymization might be useful to ensure non-notable people are not reverse searchable (not just faces but things like tattoos are an incredibly easy way to track unclothed people online ...) if these cases are too hypothetical, good, we don't need a policy change until there are deletion requests that illustrate the case. Fæ (talk) 11:29, 19 September 2026 (UTC)Reply
 Strong oppose per Drogus. We already have guidelines on AI images that should apply here. If the image has a clear educational purpose (including being in use) and is not based on an existing photograph (since that would require consent), it should remain on Commons. If it isn't educational and was uploaded for trolling, vandalism or other non-educational purpose, it's going to get deleted anyway per the aforementioned AI guideline. Your proposal will do nothing new against out of scope AI files, while redacting genuine informative material. Dabmasterars [EN/RU] (talk/uploads) 11:43, 19 September 2026 (UTC)Reply
 Strong oppose I think I have said everything worthwhile on my opinion at Meta, en-Wiki (on the AI pornography and Shotacon) and here on Commons in both deletion (1, 2) requests that spawned from this whole matter, the undeletion/and COM:AN, as well as above in lolicon in general and suggested waiting at Nudity.
In summary, I agree with Dronebogus' rationale. This proposal seems to be a way of moving the goalpost. Issac I Navarro (talk) 15:45, 19 September 2026 (UTC)Reply
 Support. As you said, AI is incapable of creating images with any realistic educational value (especially compared to normal photos or illustrations, which Commons had an abundance of) so there is no reason for it to be used. As such, AI images of this kind are inherently out of scope. ArtemisiaGentileschiFan (talk) 05:06, 20 September 2026 (UTC)Reply
 Support, as COM:NUDITY mentioned, we should host files depicting nudity if they are "significantly different and better than existing files". I agree with GPSLeo that AI generated nudity images are inherently "not suitable for educating about biology, anatomy or diversity". It doesn't seem these images are significantly useful if they are only useful for depicting "Generative AI pornography", as discussed above. I also agree that this change in policy should not override COM:INUSE. Thanks. Tvpuppy (talk) 23:15, 20 September 2026 (UTC)Reply
 Support "If we don't allow AI porn we won't be able to show AI porn" is an incredibly weak and obviously circular argument. AI porn has no educational value, and there is no reason for Commons to show AI porn. Commons should not be pornwiki: there are better uses for this platform than cataloguing every kind of porn on the Internet. And like others above, this is proposal addresses just the tip of the iceberg; I hope Commons makes more changes to policy to de-pornify it and make it a more respectable and reputable platform. It would be more popular if it didn't cater to the lowest lows of the internet. Levivich (talk) 00:05, 21 September 2026 (UTC)Reply
 Support Some of this is already redundant with other Commons guidelines like COM:AIIP if it is of a real person, but I also agree with Levivich, there is no educational value in AI porn. There are other websites for that. Media that depicts nudity or human sexuality should be curated, because having media that has educational value is increasingly going to be important in an international climate that shows ongoing hostility to LGBTQ+ people and media. As a queer person myself, I definitely understand that anything involving human sexuality requires nuance. However, we should stop this trend of uploading non-educational AI porn in which for example an uploader wants to push the envelope on policy. Abzeronow (talk) 04:18, 21 September 2026 (UTC)Reply
There is no “trend”, unless you count one user who recently uploaded a bunch of obviously OOS AI porn slop. There are seven images in Category:AI-generated nudity and subcats. Two of them aren’t even erotic. None of them are related to queer people. “Think of the queers” is the progressive inverse of “think of the children”; and it’s even stupider because queer people have won more rights by attacking oppressive frameworks, not acquiescing to them. I am saying this as the biggest AI hater on Commons. This isn’t about AI; this is about censorship via attacking the lowest of low-hanging fruit. That is the only policy envelope being pushed here. Dronebogus (talk) 15:35, 21 September 2026 (UTC)Reply
 Oppose I'm quite conflicted here. On the one hand, I'm of the opinion that all AI-generated images should be banned from Commons, unless they can be definitively proven to have been generated by a model where 100% of the training data is under a free license. Anything else is a derivative work of copyrighted materials, and us ignoring that is contrary to Commons' mission. On the other hand, I'm very uncomfortable with editors cherry picking subjects they find distasteful and trying to exclude those from the project scope. Unlike COM:AIIP, which was put in place to protect against a novel harm not covered by existing policy, I fail to see the novel harm here. Which is to say, why are we treating AI-generated pornography any different from non AI-generated pornography? Commons:Nudity#New_uploads works for both AI and non-AI images for sifting out new, low-quality content. Commons:CSD#G3 works for removing attack porn (which was a thing since photoshop, long before AI). And speaking as an admin that patrols the abuse filter for new AI images, the overwhelming majority of AI-generated images aren't pornographic; there's not such a high volume of them that we need a special rule. I don't see why we need this specific call-out. Ultimately, while I imagine I'd generally support deletion for such images in COM:DRs, I'm opposing this proposal because I don't like the implementation or the precedent it sets. The Squirrel Conspiracy (talk) 05:33, 21 September 2026 (UTC)Reply
I agree with you that we should just delete all not used AI-generated content and that we need a global policy that limits the usage of AI generated content in all Wikis. But I am not sure if we get a majority for this. Therefore, I decided to go with this proposal for now, as I think we get a majority for this. GPSLeo (talk) 17:39, 21 September 2026 (UTC)Reply
This is not a majority vote, this is a discussion. The result will largely be based on consensus. Dabmasterars [EN/RU] (talk/uploads) 17:49, 21 September 2026 (UTC)Reply
This is the proposal board. Decisions on this page are made through majority votes. GPSLeo (talk) 19:57, 21 September 2026 (UTC)Reply
Huh, interesting. I'm not that active on these proposal pages, so that's good to know. With how Support and Oppose votes are mostly equal, I am interested in the outcome. Though I still feel like consensus-driven compromises are usually the best solutions, especially since some people here suggest the Ai nudity policy to be below COM:INUSE in terms of priority, while others may disagree. Minute details like these may differ a lot. Dabmasterars [EN/RU] (talk/uploads) 21:45, 21 September 2026 (UTC)Reply
 Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:48, 21 September 2026 (UTC)Reply
@Jeff G. Please elaborate on your take. This is a discussion, not voting. Dabmasterars [EN/RU] (talk/uploads) 17:53, 21 September 2026 (UTC)Reply
@Dabmasterars: I was !voting on a proposal to "Ban AI generated content depicting nude people". I support said proposal, as proposed, per the many supports above. Why didn't you question them?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 19:33, 21 September 2026 (UTC)Reply
 Support. a reasonable restriction for a type of upload with little to no educational value. this is simply a somewhat stricter form of COM:PENIS ltbdl (talk) 17:06, 21 September 2026 (UTC)Reply
 Oppose I'm broadly against both of these. But this seems a badly contrived intersection, to try and delete 'something', when what we really need are clearer rules based on what's wrong with AI, and what's wrong with COM:PORN. Accepting failures to do either of these and just going for the intersection because it's easier to express something that catches some of what we'd like -- well, it's not really enough. It's also too easy to slide around, by arguing that if both aren't clearly met, then the rule doesn't apply. Andy Dingley (talk) 19:03, 21 September 2026 (UTC)Reply
 Oppose Bit too general an argument right now, i will  Support banning of AI generated porn images of "real people", those should never be allowed... Once this AI boom slows down, then we can decide what is and what isn't relevant and out of scope...--Stemoc 03:40, 22 September 2026 (UTC)Reply
Good point, I agree. Especially since pornographic deepfakes of real, unconsenting people are illegal in a bunch of US states. Dabmasterars [EN/RU] (talk/uploads) 06:23, 22 September 2026 (UTC)Reply
 Weak oppose. I think this is a pretty reasonable proposal, but I am persuaded by the point raised above that there is no currently-existing problem that it solves. And it is easy to hypothetically imagine instances of AI-generated nudity that would have a reasonable educational use, e.g. to show the evolution of AI-generated nudity over time, even if not in use. So I would default to not adding a rule, even a sensible one, when there is not an actually-existing problem to be solved. -- Visviva (talk) 03:56, 22 September 2026 (UTC)Reply
  •  Oppose as per TSC. I oppose most if not all AI generated materials. These are IMO not educational EXCEPT in particular cases such as those creepy brainrot characters or the AI slops uploaded by Trump to social media which somehow get media coverage. But this proposal does have a moral component I do not agree with. I'm all for a massive ban on AI stuff given certain exceptions. --Bedivere (talk) 04:34, 22 September 2026 (UTC)Reply
  •  Oppose per The Squirrel Conspiracy. I think that in practice, most problematic cases of this are already covered by COM:PENIS, and anything that wouldn't be covered by that probably would be an edge case for this ban. Gnomingstuff (talk) 07:25, 22 September 2026 (UTC)Reply
 Oppose. I would support a rule addressing AI-generated nudity involving identifiable real people, but I oppose applying the same restriction to clearly fictional depictions, such as illustrations (including but not limited to cartoon, comic or manga/anime). I would be even more concerned about applying it to artistic representations, where the Miller test's third prong considers whether the work, taken as a whole, lacks serious literary, artistic, political, or scientific value.
I don't think a blanket rule is necessary. The existing policies and guidelines already provide a framework for considering scope and the educational value of nudity. Also keep in mind that Wikimedia projects are not censored. Amitie 10g (talk) 07:43, 24 September 2026 (UTC)Reply
 Comment In general, I worry about poorly thought out policies being rushed through the Commons proposal process, with the implementation details and exceptions to be figured out later.
I've noticed a trend: every few months, someone proposes a new blanket policy that specifically targets AI content but overcorrects for the actual problem that it purports to solve. Earlier this year, Commons:AI images of identifiable people was instituted on the grounds that such AI-generated images pose ethical issues about consent, and quickly became a rationale for deleting AI images of historical figures who were clearly dead. A subsequent proposal on the talk page to carve out images of "people no longer living" did not gain consensus.
More recently, there has been a proposal to require an "in-image" indication (watermark) on certain AI images. Some users have raised the objection that a watermark baked into the image degrades its usefulness to the end user and to other Wikimedia projects, but others have been dismissive of that issue; one person in that discussion opined that applying a "destructive process" to slop is a good thing. My sense is that the general proposal appears to have gotten strong support but there may be no consensus on whether a non-destructive or destructive alteration is preferred.
Historically, I have put a lot of my trust in the consensus process that undergirds Wikimedia projects. It is hard for me to maintain that trust when policy decisions are based on moral panic and not careful reasoning from first principles. Qzekrom (talk) 06:40, 27 September 2026 (UTC)Reply
Getting a consensus takes time and should be founded on a wealth of evidence at a level that a policy with serious consequences should have. Though there are a few dramatic allegations, the push-back we see here helps reassure the wider community that Commons does not create serious policy changes based on unserious or knee-jerk moral panic from a few well meaning folks. Meanwhile, if any images are felt by anyone to be either unlawful or counter to the intent of current policies on nudity or give the appearance of CSAM, it helps all of us if deletion requests are created as we need better case books.
It would be great if admins more often were prepared to delete on sight and use the undelete process to discuss why speedy deletions of some of these images is within policy. Most of the community do not want to have to look at potential CSAM just to discuss the case when an admin can put the why of it in words. Fæ (talk) 07:20, 27 September 2026 (UTC)Reply
respectfully disagree, re: 'It would be great if admins more often were prepared to delete on sight and use the undelete process to discuss why speedy deletions of some of these images is within policy. Most of the community do not want to have to look at potential CSAM just to discuss the case when an admin can put the why of it in words.' - i'm not a big fan of "blind faith". if it's not a clear case for urgent/due dillgence csd as illegal, then it SHOULD be subject to community review & discussion, whether it's sexual content, or any other "controversial" subject. Lx 121 (talk) 11:00, 27 September 2026 (UTC)Reply
I think we mostly agree here, it's those clear due diligence cases that admins should feel empowered to handle up front and justify afterwards. Keep in mind that such cases are very rare. Fæ (talk) 11:35, 27 September 2026 (UTC)Reply
 Oppose - for a wide array of the reasons already given. Lx 121 (talk) 02:21, 27 September 2026 (UTC)Reply
 Support - AI generated nudity is considered without consent and out of scope. This would be very problematic in future keeping of such content. Ahri Boy (talk) 17:18, 3 October 2026 (UTC)Reply
Consent is only really a problem with deepfakes, while (currently) all AI nudity on Commons does not use a specific likeness. Also, almost all of it is in use, which means it is automatically in scope. Dabmasterars [EN/RU] (talk/uploads) 19:13, 3 October 2026 (UTC)Reply
 Oppose I struggle to see what this does that COM:AIIP and COM:NUDITY do not. Why it imposes an even stronger burden than NUDITY is also strange; dropping your pants for Commons and putting a prompt for nudity into an LLM for Commons seem about the same difficulty to me. Based5290 :3 (talk) 01:01, 5 October 2026 (UTC)Reply
 Oppose this rule will not solve any real problems, but will create some barriers for potential legitimate cases, such as illustrations about AI itself. Current policies are sufficient. Evelino Ucelo (talk) 21:53, 5 October 2026 (UTC)Reply

Commons:Nudity/children

[edit]
Latest comment: 3 days ago25 comments11 people in discussion

Please: in the following discussion (and pretty much anywhere else except perhaps COM:ANU), would people please refrain from commenting on what they consider to be other users' prudery or, on the other hand, moral degeneracy, and stick to the policy matter at hand and what is good for the site, and why? - Jmabel ! talk 13:12, 2 October 2026 (UTC)Reply

Another spin-off of the lolicon-discussion above, this one is for any nude children, photo, drawing, sculpture, whatever. I suggest it as a guideline, but I can also slap an essay-template on it. Opinions, Commoners? Gråbergs Gråa Sång (talk) 19:28, 22 September 2026 (UTC)Reply

Currently the page is exclusively lolicon-focused, but I won't mind having both real and fictional nudity being mentioned, as long as they are clearly separated (i.e. lolicon has it's own section). Also, if this would be a guideline and not an essay, then the actual concrete set of rules would require hard consensus or at least some clarification from the WMF, which should be in just two days (one week after the meta discussion start). Dabmasterars [EN/RU] (talk/uploads) 20:06, 22 September 2026 (UTC)Reply
No, it's not. Lolicon is mentioned but not the focus of the text. Read it again. And no matter if we call this a guideline or something else, the WMF-policy remains. As does 18 U.S. Code § 1466A - Obscene visual representations of the sexual abuse of children, which states among other things "It is not a required element of any offense under this section that the minor depicted actually exist.". Gråbergs Gråa Sång (talk) 20:09, 22 September 2026 (UTC)Reply
This edit removing the WMF policy's second group of exceptions caught my eye. There is definitely something to be said for deleting it, as that seems to be where a lot of trouble arises, and pretty much just leaves us with cases where the "really compelling educational use" could be expected to be self-explanatory. On the other hand, I would be surprised if the Commons community were to endorse a significantly more exclusionary position than the Foundation's. Also, on more of a side note: if this is to be an essay/guideline that we might want to refer people with varying tolerances to, for my part I would suggest that it might be best to forego any exemplary images in this case. -- Visviva (talk) 00:34, 23 September 2026 (UTC)Reply
@Visviva I removed it since the same copypaste is in the first paragraph. Dabmasterars started the page mostly empty, I added some stuff, Arlo Barnes moved it, Dabmasterars added more stuff... Gråbergs Gråa Sång (talk) 03:09, 23 September 2026 (UTC)Reply
While the two items read very similarly, if you look at the corresponding section in the Foundation policy there is a bullet point that excepts "media with demonstrable educational value (such as, but not limited to lolicon, lolita, historical cartoons, drawings, paintings, or photographs)". To be clear, I think removing this bullet point is probably an improvement in terms of having a clear and enforceable policy. However, that improvement would come at the cost of excluding some "demonstrably educational" content that had been considered within scope. -- Visviva (talk) 05:25, 23 September 2026 (UTC)Reply
I'm ok with not having "examples" visible if that's the general preference (I was thinking of going the other way with "napalm girl" too), but I hope you're ok with wikilinking them. Gråbergs Gråa Sång (talk) 03:19, 23 September 2026 (UTC)Reply
That seems fine to me. It's only the risk of surprise on opening the page that had me a little concerned. -- Visviva (talk) 05:25, 23 September 2026 (UTC)Reply
I gave you a ping above. Regarding my suggestion in adding onto and being specific to define a child. Would you consider this useful to add to this? Issac I Navarro (talk) 03:30, 23 September 2026 (UTC)Reply
I don't think we should go into such definitions here, less is more, and there is plenty of ambivalence already. WMF-policy goes with "minors — that is, people under the age of 18." To quote one WP-editor: "Not every Wikipedia guideline has to look like a Russian novel banged a tax code." The more you add, the more there is to disagree on, and no matter how we write it, case-by-case will still be plenty, but perhaps somewhat less and/or shorter. Gråbergs Gråa Sång (talk) 03:55, 23 September 2026 (UTC)Reply
I made this addition: [12] Gråbergs Gråa Sång (talk) 10:06, 23 September 2026 (UTC)Reply
I would propose having it as an essay rather than as a policy or guideline. An essay can provide an interpretation of the existing policies and explain how they may be applied in these cases, without creating a new local rule or overriding the Foundation's policy. Amitie 10g (talk) 00:21, 24 September 2026 (UTC)Reply
 Oppose strongly in present wording. (& why are we having the mega-meta debate AGAIN all of a sudden? IF we are going to do this, then there really needs to be notice to all editors & headers promoting the discussions. otherwise this is just a kade-klatsch of the ppl who regularly hang out @ cvp. )
THIS paragraph has all kinds of problems with the wording:
'For this guideline to apply to unrealistic depictions of minors, the depicted subjects should generally be obviously pubescent or prepubescent children, showing human or humanoid subjects who are unambiguously minors due to lack of physical development associated with puberty, in particular primary and secondary sex characteristics. Context clues may be taken into account to ascertain subject age, but are not the sole determinant. Wearing clothing associated with minors or being depicted in a location or situation associated with minors is not necessarily enough. Stated/canonical age does not matter, though if an explicit artwork somehow includes mention of a subject being underage in either description, caption, data, categorization, or the work itself the offending content must be removed immediately or the artwork deleted.'
& how exactly is this WHOLE policy debate going to affect commons HUGE collections of historical images, artworks, etc. depicting nude minors or "people of indefinite age" (to summarise the above, quoted, paragraph)? (not to mention old textbooks, nudism/naturism lifestyle, etc.?)
Lx 121 (talk) 02:19, 27 September 2026 (UTC)Reply
Convoluted reasoning trying to set up tests to make it easier to keep potentially questionable material seems antithetical to using common sense but I guess that is the point. Sigh. Spartaz (talk) 16:41, 1 October 2026 (UTC)Reply

Add a software to detect and auto tag any vectors containing rasters inside of them.

[edit]
Latest comment: 10 days ago8 comments6 people in discussion

It will help with replacing them when possible. Candidyeoman55 (talk) 14:11, 23 September 2026 (UTC)Reply

 Support: And when it exists, coordinate to add {{FakeSVG}} or {{BadSVG}} to the affected filepages. -- Tuválkin ✉ ✇ 18:51, 23 September 2026 (UTC)Reply
And also add them to every other Wikimedia project with local files. Candidyeoman55 (talk) 19:15, 23 September 2026 (UTC)Reply
Storing this in metadata (so searchable in quarry and also accessible in lua modules) and automatically putting some sort of warning text on the image page (like we do with SVGs with SMIL animations), is easy, but automatically adding a tracking category is much harder. Bawolff (talk) 07:09, 25 September 2026 (UTC)Reply
 Oppose. There are valid reasons for SVG images to contain embedded raster images; not all such images need to be replaced. I wouldn't necessarily be opposed to detecting SVG files which contain only a raster image, but that isn't what was proposed. Omphalographer (talk) 08:19, 25 September 2026 (UTC)Reply
wWe also need to especially detect fake SVGs. Candidyeoman55 (talk) 08:57, 25 September 2026 (UTC)Reply
 Support the autotagging with a template like {{Unreviewed SVG with raster elements}} for further review by a human. How to implement it? Via bot maybe? Amitie 10g (talk) 09:38, 25 September 2026 (UTC)Reply
  •  Oppose This issue is subtle. The names {{Fake SVG}} and {{Bad SVG}} are also loaded. The presence of a bitmap image in an SVG file ({{Bad SVG}}) does not prove a misuse of the SVG format. There are photographic images with vector labels: File:LuettePalatineUvula.svg (with translations). The photo is never intended to be vectorized, but the SVG format is appropriate for the labels. A {{Fake SVG}} file consists of only a raster image, but that does not mean it should be immediately replaced with a bitmap. The Fake SVG tag can be looked at as an invitation to improve the SVG. Most of Category:Fake SVG are good candidates for vectorization. The last thing I want to see is those files having their content extracted to a JPEG or PNG file and the original file deleted because the logical next step is to mark the bitmap file as {{Convert to SVG}} and then maybe a new SVG being made down the road. The penalty for embedding a bitmap into an SVG file is small: about 33% larger size (6 bytes are encoded in 8 bytes). Making a new bitmap file has a storage cost of 75%. Some {{Fake SVG}} files are just photographs that should not have been made into SVG files, but it does not hurt to just let them be. There are some legit vector SVG files that should be bitmap files. Somebody made some QRCode examples into SVG files, and that caused some bloat. There are also some unicorn files that are legit vector files but have display:none (invisible) bitmap elements. Glrx (talk) 19:41, 25 September 2026 (UTC)Reply

Redirect/merge Commons talk:Threshold of originality to Commons:Village pump/Copyright

[edit]
Latest comment: 6 days ago7 comments4 people in discussion

I am not suggesting that Commons talk:Threshold of originality gets removed altogether. I just believe that it should just be a page for discussing the concept of threshold of originality, and any questions about, e.g. whether a media file fails or passes the threshold of originality should instead be asked over at Commons:Village pump/Copyright. Changing the note at that page to clarify that would suffice, in my opinion. Oakchris1955 (talk) 07:33, 25 September 2026 (UTC)Reply

I'm a little worried on a "slippery slope" basis about redirecting a "Commons talk" category like this. - Jmabel ! talk 10:47, 25 September 2026 (UTC)Reply
 Oppose: Commons talk:Threshold of originality should be held for discussions about the page, while keeping Commons:Village pump/Copyright for general discussion about copyright, while relevant discussion about TOO could be moved to the TOO talk page. Amitie 10g (talk) 14:27, 25 September 2026 (UTC)Reply
In that case, can't the talk page be kept but the note on the top of it (and Commons:Threshold of originality) be changed to be explicit about posting TOO-related questions in Commons:Village pump/Copyright? There's no reason for people having such a question to post something in the talk page and wait weeks or months for an answer when they can get the much more quickly from the village pump. Yes, I know that the note on both pages says that, but, in my opinion, is should specify that Commons talk:Threshold of originality exists only for discussing the content of Commons:Threshold of originality and not for requesting feedback on whether others think a media file passes or fails the TOO. Oakchris1955 (talk) 14:35, 25 September 2026 (UTC)Reply
@Oakchris1955: sure, feel free to post a prominent notice at the top of the talk page. - Jmabel ! talk 13:36, 26 September 2026 (UTC)Reply
✓ Done I updated both Commons:Threshold of originality and Commons talk:Threshold of originality to strongly recommend that community feedback on whether a work meets the TOO be posted over at Village pump/Copyright. Oakchris1955 (talk) 17:46, 29 September 2026 (UTC)Reply
 Oppose but like, why? Dronebogus (talk) 07:37, 27 September 2026 (UTC)Reply

Allow autopatrollers to delete own files if not in use and uploaded less than a week ago

[edit]
Latest comment: 4 hours ago24 comments19 people in discussion

I suspect this will be a controversial proposal, but here goes.

This weekend I was at Wiki con north america. During it User:Dominic had an interesting comment. He mentioned that one of the difficulties with mass uploads is that there is a lot of pressure to be perfect because you can't fix your own mistakes but have to bother an admin. If you are doing a large upload, even tiny mistakes can create a lot of work, as e.g. 0.5% of 20,000 files is still 100 files. Even if you try very hard, its basically impossible to be 100% perfect, and mass uploaders would like to be able to fix problems themselves instead of becoming a nuisance on admins.

Given we will almost always delete an unused file as a courtesy if asked by the uploader within 7 days, is there really any harm to allowing users to delete their own files if it meets the courtesy deletion criteria? If we limit it to autopatroller then we would have some assurance that it only applied to good faith users. In the event of disputes, admins could always undelete the file and remove the user's autopatrol rights. Bawolff (talk) 06:28, 28 September 2026 (UTC)Reply

  • Strong support Excellent suggestion. When I uploaded the 1.7 million SVGs for the Our World in Data Visualizations, I created some in error and wish I would have been able to fix them myself. Doc James (talk · contribs · email) 03:11, 29 September 2026 (UTC)Reply
  • Support This would be helpful to ease the admin maintenance burdens with speedy deletions. Aude (talk) 03:13, 29 September 2026 (UTC)Reply
  • This seems reasonable and good, but I wonder what the technical hurdles might be. Is there any precedent for a user group having the ability to delete only a user-specific subset of files? -- Visviva (talk) 04:05, 29 September 2026 (UTC)Reply
  • Support in principle: Helpful for any uploader, and I'll also note its particular usefulness for WikiPortraits. Our photographers are often uploading hundreds of files at a time from a given event, which inevitably produces some G7 deletion requests shortly after upload (accidental uploads, copyrighted material in a photo, non-notable subject requests deletion, etc.). However, one technical concern is that it's easy for an uploader to turn a used file unused. Say I upload a photo and someone adds it to a Wikipedia article, and then a couple days later I decide I want it deleted. I could theoretically remove it from the Wikipedia article myself and then immediately delete it. We sort of already have this issue today, in which a user can remove usage and then tag for speedy deletion, but at least in that case there's a bit of time lag + admin review. ~Kevin Payravi (talk) 06:09, 29 September 2026 (UTC)Reply
  •  Support; if this is not technically possible, I believe we could achieve much the same effect with a new template and a filter that limits addition of that template to Autopatrolled and to files/pages less than 7 days old; the template would stick the file/page in a category whose contents an admin (or possibly even a bot) could delete without further review. I think the necessary mechanisms for all of that exist. - Jmabel ! talk 08:23, 29 September 2026 (UTC)Reply
 Support, but beware that unbundling the delete function is one of Commons:Recurring proposals.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:32, 29 September 2026 (UTC)Reply
 Comment Originally i said autopatrol, but given the context, it actually probably makes more sense to give it to both bots and autopatrol, not just the autopatrol group. Bawolff (talk) 14:50, 29 September 2026 (UTC)Reply
 Comment As far as I'm aware, there is no software support for these restrictions at the present time. Whether WMF would be able to implement them is questionable. Omphalographer (talk) 18:15, 1 October 2026 (UTC)Reply
Should this pass, i intend to implement the necessary changes. (There is of course no garuntee the change gers accepted, but i think its likely it would) Bawolff (talk) 18:18, 1 October 2026 (UTC)Reply
  •  Support Jmabel's template suggestion Unbundling delete, but only for files (which is separate from only the file namespace, because of redirects), but only for your own uploads, but only for a specific window of time, seems like a technical nightmare. Jmabel's template proposal is a much better solution. We can have a bot check whether the template was placed in time, whether it's an actual file or not, and whether the file is in use or not, and automatically delete files if they pass all those checks, or kick it to Category:Other speedy deletions for manual processing if it fails any of those checks. The Squirrel Conspiracy (talk) 23:57, 1 October 2026 (UTC)Reply
  •  Support Per TSC and Jmabel, this could be done by a bot. I'm more than happy to make a proof of concempt/demo on my bot. All the Best -- Chuck Talk 00:04, 2 October 2026 (UTC)Reply
  •  Support Good for accidental uploads or unexpected errors --PantheraLeo1359531 😺 (talk) 06:49, 2 October 2026 (UTC)Reply
 Support Useful idea as proposed. Ahri Boy (talk) 02:49, 5 October 2026 (UTC)Reply
 Support for files as proposed. Could also help reduce the queue of files requested for speedy deletion due to other reasons, such as file corruption (a speedy deletion request which I requested a few days ago for a file I uploaded less than a minute prior, for example). ForeverFlying (talk) 05:22, 5 October 2026 (UTC)Reply
 Support but only in form of "template and bot". Such bot can perform necessary checks, can be easily stopped if something will run not as expected, add categories, etc. Evelino Ucelo (talk) 18:43, 5 October 2026 (UTC)Reply
  •  Support In theory, this could be misused. Hypothetical case: Someone uploads a really useful image and it's already in use, then they change their mind, remove the image from the articles where they were in use, and then delete it here as "not in use". But I think that's really mostly hypothetical. As for the technical side, I can't judge whether the conditions as described by The Squirrel Conspiray would be a "technical nightmare" or maybe actually easily implemented by someone with the necessary programming skills. So I'm neutral on the question "actual deletion vs. template and bot solution". Gestumblindi (talk) 18:55, 5 October 2026 (UTC)Reply
    doing it via mediawiki would be a very very bad idea. A bot using the current template will work, but with the caveat that if someone tags someone else's G7 on their behalf then an admin has to delete it as the bot can't intelegently parse a diff for approval, and if we allowed other users to G7 each others files, we just unbundled the delete tool. All the Best -- Chuck Talk 19:54, 5 October 2026 (UTC)Reply
    Can you expand on why you think it would be a bad idea to do it in MediaWiki? I don't really care which approach is taken, but I don't understand the objection to doing it in MediaWiki. Bawolff (talk) 20:55, 5 October 2026 (UTC)Reply
    It will include complex checks in base software. Better approach is to perform this task in separate script. Evelino Ucelo (talk) 21:38, 5 October 2026 (UTC)Reply

Speedy report system for CSAM and similar files

[edit]
Latest comment: 2 hours ago5 comments4 people in discussion

On Commons we are often told not to report suspected CSAM or other inappropriate depictions of minors openly, but there is no obvious on-wiki route to discreetly inform the people in charge of dealing with this stuff of a concern. Therefore I think it would be useful if a clearly labeled gadget was added by default to the sidebar that allowed users to send a confidential anonymous report to trust & safety (or whoever) if they encounter A) suspected child sexual abuse or exploitation material, or B) underage users uploading explicit files of themselves (which is much more common and probably far less of a serious concern). Dronebogus (talk) 19:05, 5 October 2026 (UTC)Reply

This is already in development: mw:Product Safety and Integrity/Incident Reporting System. GPSLeo (talk) 19:12, 5 October 2026 (UTC)Reply
@Dronebogus: I think that the Wikimail of User:Oversight Commons is such a discreet contact option, and oversighters should be able to mount a good first response against CSAM. Regards, Grand-Duc (talk) 20:05, 5 October 2026 (UTC)Reply
I don’t have nor want an attached/assosiated email account Dronebogus (talk) 20:07, 5 October 2026 (UTC)Reply
Nor should unregistered users be expected to create an account to report problematic content. Omphalographer (talk) 00:28, 6 October 2026 (UTC)Reply
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=1283620585"