Gadget to hide NSFW images

LLM use in discussion

Restrict category creation to registered users

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:

• Commons:Administrators' noticeboard/User problems/Archive 124#Timmy96
• Commons:Requests for checkuser/Case/Timmy96
• User talk:Οἶδα#From Timmy96

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)

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)

@Οἶδα: 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)

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)

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)

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)

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)

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)

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)

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)

grim but true Οἶδα (talk) 04:07, 20 July 2026 (UTC)

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)

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)

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)

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)

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 (e.g. . 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)

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

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

This proposal is intended to ban

• Template:Cc-by-1.0
• Template:Cc-by-1.0-fi
• Template:Cc-by-1.0-il
• Template:Cc-by-1.0-nl
• Template:Cc-by-sa-1.0
• Template:Cc-by-sa-1.0-fi
• Template:Cc-by-sa-1.0-il
• Template:Cc-by-sa-1.0-nl
• Template:Cc-sa-1.0
• Template:Cc-sa-1.0-fi
• Template:Cc-sa-1.0-nl
• Template:Cc-sa-2.0-jp
• Template:Cc-pd

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

 Support That these should be deprecated or discouraged. ―Justin (koavf)❤T☮C☺M☯ 13:27, 29 June 2026 (UTC)

 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)

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)

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)

•  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)

 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)

Why is the Japanese licence (which CC withdrew over twenty years ago) any better? Andy Dingley (talk) 17:40, 29 June 2026 (UTC)

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)

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

• https://creativecommons.org/licenses/sa/1.0/deed.en
• https://creativecommons.org/licenses/sa/2.0/jp/deed.en

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.

• https://creativecommons.org/licenses/sa/1.0/legalcode.en
• https://creativecommons.org/licenses/sa/2.0/jp/legalcode.ja

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)

• 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)
•  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)

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)

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)

• weak oppose. I dont think the problems are severe enough to outright ban. They should certainly be discouraged though. Bawolff (talk) 02:07, 30 June 2026 (UTC)

 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)

 Support, see Commons:Deletion requests/Template:Cc-sa-layout.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:22, 30 June 2026 (UTC)

•  Strong oppose We should not reject otherwise freely licensed works merely because the chosen free license is older or less than ideal, absent a clear and significant legal or operational problem that outweighs our mission of accepting freely licensed content. --Jonatan Svensson Glad (talk) 10:57, 30 June 2026 (UTC)

  Per Jonatan --PantheraLeo1359531 😺 (talk) 16:27, 1 July 2026 (UTC)

•  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)

 Oppose in strongest possible terms. Being overly restrictive is not helpful. PARAKANYAA (talk) 07:48, 18 July 2026 (UTC)

 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)

Require people uploading their own photos taken with digital cameras to include the file with its original exif data.

I've been seeing instances where people steal copyrighted photos and upload them as their own work. An example of this is File:Darline Graham 2026.jpg which was taken by Sean Rayford then stolen and uploaded by William Bartlett who did not take this photo.

I propose requiring people who upload their own photos taken with digital cameras to upload the photo with its original exif data. News organizations usually remove this data from photos on their websites. So if the photo doesn't have that, it should be a red flag. Please let me know what you think about this. Minermatt122514 (talk) 00:39, 14 July 2026 (UTC)

@Minermatt122514: Enforcing the presence of EXIF may cause privacy issues. Furthermore, most if not all license reviewers are already sensitised about EXIF, the lack thereof or inconsistencies within. I don't think that we need a policy about this. Regards, Grand-Duc (talk) 01:15, 14 July 2026 (UTC)

We can allow people to remove or replace location data or serial numbers. But we should not allow wiping of the entire metadata. GPSLeo (talk) 04:10, 14 July 2026 (UTC)

I think some editing software tends to remove at least some EXIF data without asking or informing the editor. A professional might notice it or be aware of it, but I don't think that we can expect hobby photographers to even know what EXIF data is. Nakonana (talk) 08:58, 14 July 2026 (UTC)

1. If someone really wants to commit fraud, you can completely fake EXIF data.
2. There are editing tools, especially but not exclusively on phones, that strip all meaningful EXIF data. Some strip EXIF entirely, others leave nothing but an indication of what tool was used for the editing, etc.
3. Not every image is initially created with digital photography.

Jmabel ! talk 05:58, 14 July 2026 (UTC)

 Oppose; I didn't make that overt before. - Jmabel ! talk 17:18, 30 July 2026 (UTC)

 Oppose as unworkable, also useless. Andy Dingley (talk) 09:10, 14 July 2026 (UTC)

 Oppose unworkable, unrealistic. This suggestion has the problem of boiling down the world to 2 situations, 2 possibilities as if there actually are just 2. Thats a recipe for disaster. —TheDJ (talk • contribs) 09:33, 14 July 2026 (UTC)

 Oppose per Grand-Duc and the opposes above.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:50, 14 July 2026 (UTC)

i think most image/chat apps other than the phone's native cam app make no exif. for example, if i open the cam inside instagram, have the setting "save story image to phone", and take a photo to post as ig story, then the saved photo has no exif. the same goes for whatsapp, telegram, etc. RoyZuo (talk) 10:16, 30 July 2026 (UTC)

 Oppose Privacy concerns. --Rosenzweig τ 18:09, 30 July 2026 (UTC)

 Oppose Removal of EXIF data is occasionally warranted because of privacy concerns. And these concerns go beyond location data and serial numbers. Sometimes the complete removal of EXIF (and other metadata) is the safest option. --AFBorchert (talk) 15:47, 31 July 2026 (UTC)

 Oppose While EXIF information is nice to have, it should not be mandatory. It's not always a copyvio, some people just like their privacy or even shoot with film cameras. PascalHD (talk) 02:47, 1 August 2026 (UTC)

 Oppose per all the above. EXIF is easily faked. I also have digital copies of some of my early digital images, with no EXIF, where the originals are lost. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:20, 1 August 2026 (UTC)

 Oppose, see Commons:Administrators' noticeboard/User problems/Archive 131#OtikolenoiL uploads for the reason. JWilz12345 (Talk|Contributions) 11:45, 4 August 2026 (UTC)

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

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

•  Support Either as proposer. The Squirrel Conspiracy (talk) 07:15, 15 July 2026 (UTC)
•  Support F8. --Krd 07:18, 15 July 2026 (UTC)
•  Support F8 but would say, "This criteria also includes newly uploaded raster images that duplicate an older existing vector file." to avoid "exact duplicate" disputes. Glrx (talk) 15:35, 15 July 2026 (UTC)
•  Support F8. ―Justin (koavf)❤T☮C☺M☯ 16:51, 15 July 2026 (UTC)
•  Oppose Raster and vector files are totally different. We should therefore keep both of them. This of course only applies if both versions have sufficient quality and not to any logo that was uploaded as compressed jpg. GPSLeo (talk) 18:06, 15 July 2026 (UTC)
  • But MediaWiki software generates PNGs of various sizes for every SVG. Why are other raster graphics useful in addition to these? ―Justin (koavf)❤T☮C☺M☯ 18:21, 15 July 2026 (UTC)

    A PNG generated out of and SVG is still not the same as an original PNG where you have guaranteed control over every single pixel. GPSLeo (talk) 19:10, 15 July 2026 (UTC)

•  Comment there seems to be an assumption here that (1) the subject is appropriately represented with a vector file and (2) that the SVG is "good", e.g. not an inefficient, thinly disguised raster file wrapped in an SVG. - Jmabel ! talk 20:35, 15 July 2026 (UTC)

• 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)

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)

• And meanwhile you've already speedied the otherwise OK raster version? - Jmabel ! talk 23:34, 15 July 2026 (UTC)

  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)

•  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)
•  Support F8, I'd flagged these as F8 in the past until one was rejected. --Belbury (talk) 16:29, 16 July 2026 (UTC)
•  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)
•  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)

  @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)

  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)

•  Support either.Jonteemil (talk) 19:36, 20 July 2026 (UTC)
•  Support either, but prefer adding to F8. --Nux (talk··dyskusja) 19:57, 28 July 2026 (UTC)
•  Support F8 with simpler wording Tausheef Hassan Auntu ✉Talk? 09:22, 29 July 2026 (UTC)
•  Support adding to F8, but with shorter wording per Omphalographer. Thanks. Tvpuppy (talk) 20:46, 1 August 2026 (UTC)

Preferably link to legal texts in official websites

Commons:Copyright rules by territory and all country pages and all the templates under Category:PD-Gov license tags often link to legal texts, but many to wipo.int websites. However, many countries have online versions of their legal texts. Links to these official pages should be preferred wherever they are publicly accessible. RoyZuo (talk) 17:27, 19 July 2026 (UTC)

There are advantages and disadvantages. WIPO cares specifically about copyright, so their repositories are easy to follow when you're looking for that. It can also have links to past versions and translations. Not every country has an equivalent resource. Of course WIPO isn't the government of that country. Were there specific examples you had in mind? TheFeds 09:04, 20 July 2026 (UTC)

These aren't mutually exclusive. I see the value in linking to the government site (where available) and I see the value in linking to WIPO. ―Justin (koavf)❤T☮C☺M☯ 20:25, 3 August 2026 (UTC)

Special:AbuseFilter/12

Wouldn't it be good if we have one filter that tracks removal of deletion templates only, to combat uploaders or socks thereof to remove deletion taggings of their files, and one that tracks removals of any other template? Jonteemil (talk) 19:33, 20 July 2026 (UTC)

Turn Commons:RemoveGPS from a user script into a gadget

Would like to have the option for people to turn on the functionality of Commons:RemoveGPS through preferences. This was build by User:Yaron_Koren. Doc James (talk · contribs · email) 09:28, 24 July 2026 (UTC)

 Support Abzeronow (talk) 05:35, 25 July 2026 (UTC)

 Support I see TheDJ reviewed this, so I don't see why not :). Also, the concept seems to have received a lot of nods in the room during the UnPopular Opinions at the recent Wikimania. I would love to have something similar integrated into UploadWizard too (as I understand that might come later). Nux (talk··dyskusja) 19:53, 28 July 2026 (UTC)

•  Support Tausheef Hassan Auntu ✉Talk? 09:24, 29 July 2026 (UTC)

XML dump <text> has non-xml metadata

What the heck?!!? :O Why isn't the text metadata done as XML tags???? ~2026-42877-76 (talk) 20:22, 3 August 2026 (UTC)

Can you provide any context for this at all? E.g. how would I replicate this error? This is likely the sort of thing that needs to be excavated to phab:. ―Justin (koavf)❤T☮C☺M☯ 20:24, 3 August 2026 (UTC)

E.G. Using this regex search on a dump:

grep "\[\[category:" enwiki-2026-07-01-p83232764p83590118.xml

will yield lots of a lines like:

...

[[category:French military personnel of the Peninsular War]]</text>

...

There's lots of variations of this. Things like embedded URLs or things bounded by {{ }} instead of [[ ]]

They are metadata instructions/information buried within the XML dump <page>...<text>...

Why something like <text> ... <category>French military personnel of the Peninsular War</category>...</text> ~2026-43049-96 (talk) 22:21, 4 August 2026 (UTC)

I see that the Web Commons: Village pump/Proposals web page stripped out text from my E.G. example: Here's the line with embed characters typed by me.

...

[[category:French military personnel of the Peninsular War[[</text>

... ~2026-43049-96 (talk) 22:29, 4 August 2026 (UTC)

...

[[category:French military personnel of the Peninsular War]]</text>

... ~2026-43049-96 (talk) 22:31, 4 August 2026 (UTC)

Well, I'm at my wit's end. I recommend posting to phab: if you think this is a problem. Maybe someone smarter than me can address this and whatever issues this may be somehow causing you. ―Justin (koavf)❤T☮C☺M☯ 22:34, 4 August 2026 (UTC)

• Do you have a URL for that supposed XML document? A process to create one?

I note the enwiki- prefix in it. Is this a Wikipedia problem, rather than a Commons one?

It's also about twenty years since anyone cared about XML. Many supposed generators for it are no longer working correctly or well-formedly. Andy Dingley (talk) 23:13, 4 August 2026 (UTC)

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

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)

•  Support Proposed this before. I agree with the proposal

PantheraLeo1359531 😺 (talk) 11:07, 4 August 2026 (UTC)

I don't understand why the .jp2 jpeg2000 discussion is quoted here ? —TheDJ (talk • contribs) 13:16, 4 August 2026 (UTC)

•  Support Yes, also JP2 and DNG, please! JayCubby (talk) 20:41, 4 August 2026 (UTC)

Advice

I have some advices on the design of Wikimedia Commons.

1. Users may directly search the titles of files in File List.
2. The system should abandon the design of minimum limit of strings (words) inputted in the description. Firstly, people can input strings they wish after the file is uploaded, therefore it is not useful; secondly, it creates obstruction for some scripts, e.g. Chinese characters, Korean, many syllabaries, abjads, the reason is: these scripts use less strings (to be shorter).
3. For Upload Wizard, it is recommended to give more tips and guides to users when choosing the licenses. For example, COM:FOP or the copyright law in the US. These two parts are difficult to understand, especially for a person who is not professional.

Kaap bij Sneeuw (talk) 14:22, 4 August 2026 (UTC)

Further more: not showing the bad category names when choosing in Upload Wizard. Kaap bij Sneeuw (talk) 14:28, 4 August 2026 (UTC)

@Kaap bij Sneeuw: If you don't propose any fixes, this section is misplaced.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:57, 4 August 2026 (UTC)

If you consider more appropriate, you may move this to COM:VPT. Kaap bij Sneeuw (talk) 15:03, 4 August 2026 (UTC)

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