Commons:Village pump/Proposals

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

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/07.

COMMONS DISCUSSION PAGES

• Commons Help desk
• Village pump (general discussion)
  • Copyright
  • Proposals
  • Technical
• Graphics and photography discussion
  • Photography critiques
  • Image improvement
    • Illustration workshop
    • Map workshop
    • Photography workshop
    • Video and sound workshop
• Categories for discussion
• Undeletion requests
• Deletion requests
• Volunteer Response Team/Noticeboard
• Translators' noticeboard
• Work requests for bots

---

• Contact administrators
  • Vandalism
  • User problems (Dispute resolution)
  • Blocks and protections
• Bureaucrats' noticeboard
• CheckUser requests
• Oversight requests

---

• Telegram
• IRC ^webchat
• Commons mailing list (archive)
• Commons' bugs on Phabricator

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

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

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)

I guess nothing Οἶδα (talk) 20:12, 18 August 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)

CC 1.0 template cleanup

• Find and replace existing uses of {{CC-BY}} and {{CC-by}} with {{Cc-by-1.0}}
• Find and replace existing uses of {{CC-BY-sa}} and {{CC-by-SA}} with {{Cc-by-sa-1.0}}
• Perhaps add a category and/or notice and/or maintenance template to indicate those files originally lacked a license version?
• Redirect {{CC-BY}} and {{CC-by}} to {{Cc-by}} (warning template)
• Redirect {{CC-BY-sa}} and {{CC-by-SA}} to {{Cc-by-sa}} (warning template)

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

•  Support as proposer. - Alexis Jazz ^{ping plz} 19:00, 1 July 2026 (UTC)

 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)

 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)

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)

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)

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

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)

Correct. There's no "or later" in CC 1.0. - Alexis Jazz ^{ping plz} 19:12, 2 July 2026 (UTC)

 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)

•  Oppose for files already tagged. Unless we have convincing evidence that nothing else could have been meant based on all publicly released licence versions and the history of the work, we should not assume licence features. I'm open to warnings, but should they be in the templates, the editnotices, the upload forms, etc.? Workshop the workflow for ease of understanding? TheFeds 10:12, 14 July 2026 (UTC)
• Agree broadly with TheFeds above. We should not replace recent tagging of CC-by with a twenty year obsolete CC-by-1.0. Again, do we actually have many of these? Andy Dingley (talk) 10:16, 14 July 2026 (UTC)
  • Andy Dingley, TheFeds, yes we do have those. So what should we do? Delete them? We can't redirect any template without doing something about existing uses. Create {{Cc-by-1.0-grandfathered-initially-unversioned}} or something? - Alexis Jazz ^{ping plz} 13:12, 14 July 2026 (UTC)
    • We have which? Twenty year old CC-by? Or recent unversioned CC-by? I see this as being significantly different groups, and should be treated differently. Andy Dingley (talk) 15:31, 14 July 2026 (UTC)
      • Andy Dingley, we can't reliably separate one from the other. - Alexis Jazz ^{ping plz} 20:12, 14 July 2026 (UTC)
        • We can bright line them into three groups. Old ones (before CC 2.0's release?) in which case they're clearly 1.0 (and I think we should leave them that way). Recent, in which case we agree that these should be converted to 4.0 (but we'd have to haggle a date). Those in the middle, where we still have an issue. 4.0 is pretty old now, maybe we'll just not have too many in the middle (we really do need to count these before we go any further). Andy Dingley (talk) 21:03, 14 July 2026 (UTC)
          • Andy Dingley, We can bright line them into three groups.
            Are you volunteering to do the sorting? This is a technical problem, not a policy problem. - Alexis Jazz ^{ping plz} 07:37, 15 July 2026 (UTC)
            • What is the sorting?

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)

Andy Dingley,

• CC-BY (724 results)
• CC-by (452 results)
• CC-BY-sa (0 results)
• CC-by-SA (80 results)

Will you sort them by date? - Alexis Jazz ^{ping plz} 11:01, 15 July 2026 (UTC)

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)

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)

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)

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

        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)

•  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)
•  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)
•  Support: we need to clear up these ambiguous templates. – Howardcorn33 (💬) 09:46, 5 August 2026 (UTC)

CC by-all

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)

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)

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)

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)

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)

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

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)

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)

https://dumps.wikimedia.org/other/mediawiki_content_current/enwiki/2026-07-01/xml/bzip2/enwiki-2026-07-01-p83232764p83590118.xml.bz2 ~2026-43161-26 (talk) 14:48, 5 August 2026 (UTC)

This is not the page to talk about dumps format. The XML dumps are meant to record MediaWiki system metadata in xml, not page metadata. Its primarily meant as a backup format, not a format for querying. Depending on what you are doing, there might be a different data stream that is more suited to your needs. Bawolff (talk) 00:15, 12 August 2026 (UTC)

Silly me. Since XML is intended for, (and one of the most common), communications formats, I assumed the dumps existed for a purpose other than backup. There is no need in complexifying a backup by doing conversion to XML. There's lots of standard file transfer mechanism for transferring binary files. (Including base64 encoding for transfer over HTML.)

Is there some other purpose I should know about as to why the convertion of the MediaWiki system metadata into XML? ~2026-45478-68 (talk) 21:40, 20 August 2026 (UTC)

There's some information at mw:Manual:Importing XML dumps about how to use the XML dumps. If you're trying to query page categories, there are probably easier ways to do it as others have said. Sam Wilson 04:20, 21 August 2026 (UTC)

In particular, for categories, there is a dump of just categories in SQL format - https://dumps.wikimedia.org/enwiki/latest/enwiki-latest-categorylinks.sql.gz . For lighter weight querying there is also https://quarry.wmcloud.org/ Bawolff (talk) 05:19, 21 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, the primary objection, appears to be feeding into Alphabet's hypocritical standards 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. 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. Right now Alphabet is proverbially telling another dubious promise to Charlie Brown that it will hold the football. Don't let them, once completing the compatibility tech. 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)

  +1 --PantheraLeo1359531 😺 (talk) 16:13, 5 August 2026 (UTC)

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)

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)

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)

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)

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. 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 the Reference Implementation which is controlled by probably the most monopsony "non-profit" consortium ever. JPEG XL uses a 3-clause BSD license, 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)

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)

References

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)

I disagree with the second one; that people can add them later, doesn't mean that they will, and requiring anything uploaded to have some description is good. Yes, Chinese and Korean use fewer characters to convey the same concept, which means the limit impacts them more heavily, but I'd like to see examples. Pulling some numbers from meta:List_of_Wikipedias_by_sample_of_articles which apparently come from comparing biblical translations, in inverse size relative to English, Arabic is 1.0, Hebrew 1.2, Russian 1.4 and the only languages higher than that (in the somewhat limited sample) are Japanese (1.9), Korean (2.5) and Chinese (3.7). Even if it is an issue, you could bring them into rough parity by doubling the measured length of a Hangul syllable and quadrupling the measured length of a Han ideograph.--Prosfilaes (talk) 01:05, 6 August 2026 (UTC)

Tracked in Phabricator
Task T220474

this shows how euroamericancentric things are. this new user (registered less than half a year ago) could recognise the problem so soon, yet the problem remains unsolved for a decade and some user still argues it's not a problem. 🤷 RoyZuo (talk) 07:56, 6 August 2026 (UTC)

1. this shows how euroamericancentric things are. Firstly, Wikimedia Foundation is an organization in the US; secondly, the "euroamericancentric" Latin alphabet system is "well known and undisputed that the Latin alphabet has its origin in the Greek alphabet". (Libertini, Giacinto. 2022. “Cuma and the Origin of the Latin Alphabet.” Archivio Afragolese. Accessed August 6, 2026. English version: [1]). At that time, there was not the term the West.
2. It has nothing to do with my experience to find out this simple problem.

Note: do not continue on this topic as it is not the point of discussion. Kaap bij Sneeuw (talk) 16:46, 6 August 2026 (UTC)

User:CommonsDelinker/commands

lower protection of User:CommonsDelinker/commands a bit to template protected so that slightly more people can work on User talk:CommonsDelinker/commands/Category moves.

or, more sysops just work on it plz. RoyZuo (talk) 09:01, 6 August 2026 (UTC)

OK, will cut down the catmove queue over the next few days. Abzeronow (talk) 13:56, 7 August 2026 (UTC)

Modify the Deletion Requests to allow subscriptions

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 [2] [3]. I can fix the gadget and change requests for the current month [4]. 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)

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

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

This should be solved in the subscribe feature. Everything else might break other older tools. GPSLeo (talk) 14:50, 7 August 2026 (UTC)

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)

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)

Video on Commons

Video on commons is too overlooked. The fact that FM noms are 30 days and the nominal number of voters the FM page seems to get, I would like to suggest we do more to promote content, perhaps something similar to the Monthly photo challenge we need a Monthly video challenge to encourage content producers' contributions and increase participation in the Featured media section with both creators and critics alike. I have some ideas for topics and would be willing to help run it.

I suggest we start with a Commons:Video_challenge. Don (talk) 07:36, 8 August 2026 (UTC)

Also the current file cap is IMHO too small. I created a 3 min 4k file that was rejected for being oversize. Hard drive space is a preminum sure but the low size allowance for uploads restricts the uploader to 1080 max if the file is more then a couple of minutes long. No one really uses 1080p footage in film production. 4k at 24 or 30 is commonplace. --Don (talk) 17:11, 8 August 2026 (UTC)

The limit to 5 GB per file is unlikely to be changed anytime soon. Most feature length movies fit within that size, so I think we have to do with it. Yann (talk) 17:40, 8 August 2026 (UTC)

I was rejected with a 1.3 gig file yesterday and had to reapply another layer of compression Don (talk) 19:30, 8 August 2026 (UTC)

@Don, have you reviewed Commons:File types#Highest resolution and phab:T275889#7722572? I use User:Rillke/bigChunkedUpload.js (doc at User talk:Rillke/bigChunkedUpload.js) for big uploads.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:47, 8 August 2026 (UTC)

@Jeff G. I have an ornate amount of experience in that field, Media Development Inc. was my company 30 years ago and it was a crazy time to say the least. I have spent over an hour tinkering with the chunk upload tool and am going to take a break after not being able to get it running. :(

The uncompressed file was 1.4g, I compressed it with H.264 then was able to load video video2commons to get around the 100mg cap. No matter what you do, laying a layer of compression will reduce the quality of the uploaded file. Don (talk) 21:21, 8 August 2026 (UTC)

Do you have a graphics card that allows converting in AV1? This might be faster instead of uploading an MP4 file to V2C --PantheraLeo1359531 😺 (talk) 09:32, 9 August 2026 (UTC)

No I do not. Don (talk) 21:32, 10 August 2026 (UTC)

If chunked upload tool is giving you problems, you can try using UploadWizard which also has a 5GB. Its unfortunate all the tools are janky for large uploads. Bawolff (talk) 00:00, 12 August 2026 (UTC)

Our local TV broadcaster still produces in 1080i50 oder i60 and an awful bitrate :D --PantheraLeo1359531 😺 (talk) 09:33, 9 August 2026 (UTC)

It is very easy to create some video, but actually quite hard to do it well in a way that is reusable with broad applicability. We should encourage narrative quality and universality over duration and resolution in a way that is not analogous to our handling of images. A photo contains a limited amount of information, and has subject matter relevance to whatever is depicted. A video depicting the same thing can serve the same purpose when reduced to its individual frames, but for a reuser, actually finding and then presenting that content is a high-effort task compared to a photo. Alternatively, a video can spend runtime on depicting or communicating a concept, but that narrative form is less likely to be in congruity with reuse in another work (language is an obvious case). Assessing the quality and conformance to project scope is a high-effort task for video in a way that it is not for photos. More file size is barely relevant to that process. TheFeds 02:09, 10 August 2026 (UTC)

Agreed - creating high-quality videos which are readily usable in educational content is hard; most videos uploaded by users have limited applicability. Focusing on specific use cases for video - down to the level of specific Wikipedia articles that would be improved by a video of a specific thing happening - is much more likely to yield useful results than wide-open prompts like "the ocean". Omphalographer (talk) 03:54, 10 August 2026 (UTC)

With the sheer number of social media selfie video takers surly we can come up with more focused ideas, the Ocean was just a starter topic, looking for others consensus. Sure, we can provide some direction and have videos made that augment pages already written. If a picture is worth a thousand words, 30 frames a second at 4K is priceless. Don (talk) 08:31, 10 August 2026 (UTC)

Since I have my new camera with better image stabilization, I find it useful to take videos while walking through events. This works well with 4K120, but also possible with 8K30 which allows HQ image extraction --PantheraLeo1359531 😺 (talk) 16:15, 10 August 2026 (UTC)

Pretty much all of the video I've shot has been the equivalent of photos, short videos (usually under a minute) where something was better captured in video than in a photo (a waterfall, animal behhavior, a space that could only otherwise be captured in a panorama). They are not really intended as finished product so much as fragments that could be incorporated into something larger.

That said: two things I would really like to see more of are (1) solid interviews of people of encyclopedic importance. We could really use a video equivalent of the WikiPortraits project (and, yes, this involves a lot more than technical ability). (2) Video used as a way to document oral cultures and other notable cultural/subcultural phenomena that are not routinely covered in what Wikipedia considers "reliable sources." - Jmabel ! talk 20:09, 10 August 2026 (UTC)

I disagree with regard to the upload limits. In order to load over 100 megs your required to use the chunk uploader, we are limiting that to advanced users that understand how to use the Java scripts, something I am only learning now myself and frankly speaking I have written a few good tools, I was never able to get the Chunk uploader to work. file size is totally relevant to that process, and your average user would not use it. Perhaps we run the program at first quarterly. @Jmabel is spot on. I have others from the film business that might be willing to do instructional videos on film production. Request curated edited content, not just random clips? Again, I am just thinking out loud here. Don (talk) 21:31, 10 August 2026 (UTC)

So perhaps streamlining the upload process would allow video uploads to be more user friendly in terms of size constraints. As technology evolves so will frame sizes for wider (8k) and wider hence larger and larger files will only continue to expand. An 8K master for the Granlibakken-style Commons videos, @ 200–300 Mbps HEVC, gives you a 3–4.5 GB two-minute H.265 master.

4K/24 aerial footage with forests, trees and lots of fine detail, I target about 90–120 Mbps H.265 for a high-quality archival/export copy.

That means roughly 1.2–1.8 GB for two minutes.

As the video is ultimately converting the H.265 master to AV1 WebM for Wikimedia Commons, I'd actually recommend keeping a substantially higher-quality H.265 intermediate—perhaps 150–200 Mbps—and letting AV1 do the final compression. That minimizes generation loss before the Commons encode.

The one tool I have been able to use, Video2Commons works but does not allow overwrites to replace original files as you see on other media.

More idea on contributions would or thoughts on the proposal would be helpful. Thanks Don (talk) 02:26, 14 August 2026 (UTC)

I usually encode my videos in AV1 via GPU in highest quality settings, similar to the original recording bitrate --PantheraLeo1359531 😺 (talk) 06:57, 14 August 2026 (UTC)

I was really just showing that at 100 megs as an upload cap before being required to use a third party tool like Video2Commons or the Chunk Uploader, is problematic and now that Walmart sells 8K video cameras for around one hundred and fifty dollars : ACTITOP Digital Camera for Photography 8K 88MP Autofocus WiFi Vlog Dual-Lenses Camera for YouTube with 32GB Card,16X Digital Zoom Touch Screen Video Camera - Walmart.com the file size issue will hit a wall. Even a high bitrate 4K video is about 6 minutes with the layered compression I describe above.

Nevertheless, who has ideas on how to be more inviting to commons video producers and creators? Most of the cameras (if not all) that are used by our more regular photographers, take video too. Should we perhaps create a video workshop? Don (talk) 00:53, 15 August 2026 (UTC)

I don't think its fair to call upload wizard a third party tool Bawolff (talk) 06:30, 15 August 2026 (UTC)

Good point, but I have not been able to get it to work on anything over 100 mb Don (talk) 17:08, 15 August 2026 (UTC)

Just to be clear, i mean Special:UploadWizard not special:upload Bawolff (talk) 17:54, 15 August 2026 (UTC)

I think Commons (also given its frustrating technical limitations when it comes to video) is best suited for short videos that show "a specific thing happening", as Omphalographer said. It's what I occasionally do - for example, when I was at the Schauinslandbahn gondola lift's upper station, I thought that a short video showing a cabin arriving would fit a Wikipedia article nicely, so I filmed File:Schauinslandbahn bergstation.webm and added it to German Wikipedia's article. That's the kind of video I think we should encourage people to make and upload here. As evil as platforms such as YouTube might be, for long-form educational videos they just work better. Gestumblindi (talk) 17:00, 16 August 2026 (UTC)

I have spent a good amount of time researching and uploading videos over the last few days. I was at long last able to get my computer to export WebM files as long as the files are not too large to start in Premiere. My 4k drone footage is shot raw and takes a lot of time to process into WebM so I am experimenting with exporting to raw AVI, then transcoding to WebM via Video2commons. The downside of this is I cannot overwrite the file using the video2commons upload tool. The Special:UploadWizard, special:upload, the chunk uploader all failed to load an overwriting file. As a video producer it is important to see your work on the target page and be able to correct it for proper display. Video is a valuable tool. Sure, the workload and flow can be frustrating, but the results are well worth the effort. Back to my original question: The site has very little in the way of supportive info; I,E, workshop type of pages to help teach users how to work with video and make short clips that augment the pages that the videos rest on. How do we entice contributors to use the "video switch" on the cameras that each of them holds? Don (talk) 21:55, 22 August 2026 (UTC)

Perhaps some inspiration can be taken from w:Wikipedia:WikiProject Wiki Makes Video Bawolff (talk) 23:50, 22 August 2026 (UTC)

@Bawolff, I reviewed the page and it has some great content and things that might be more applicable to Commons users then your regular EN authors. IMHO only having 15 subscribers in 10 years and an average of 1 view a day, as shown in the logs it was never properly promoted or provided with exposure to go anywhere.

Commons users are more creative, and we are used to the workflow of creating actual content. Since 2012 a lot has happened in terms of ease of creation, of quality videos. IMHO The WikiProject Wiki Makes Video initiative on English Wikipedia failed primarily due to structural, technical, and cultural friction between text-first Wikipedia editors and video creators.

Understanding those failure points is key to making video projects thrive natively on Wikimedia Commons.

Why "Wiki Makes Video" Failed on English Wikipedia

• Strict Article Formatting & Placement Rules: English Wikipedia articles prioritize text and static lead images. Inline video embeds often broke desktop/mobile page layouts, leading text editors to remove or revert them as "distracting."
• High Technical Friction & Codecs: Wikipedia historically struggled with video transcoding. Requiring open-source, non-proprietary formats (like WebM and Ogg) created massive barriers for creators shooting in standard ProRes, MOV, or MP4 formats.
• Text-Centric Culture: Wikipedia’s core editor base evaluates contributions through prose, citations, and neutral text. Video was often treated as secondary or decorative rather than as a primary encyclopedic source.
• Siloed Project Scope: The project attempted to produce fully finished, highly edited "documentary-style" mini-films. These were difficult to keep updated as article text evolved, causing videos to quickly become outdated or misaligned with changing article text.

Wikimedia Commons is a media repository, not an encyclopedia. Its culture and mission prioritize visual preservation, high technical quality, and reusable assets over textual narratives.

• Focus on Raw & B-Roll Clips over Finished Documentaries:
  • On Commons, high-value video consists of crisp, well-composed, focused clips (e.g., a 15- to 60-second clip of a Harbor 20 tacking downwind, a specific manufacturing process, or an aerial overview).
  • Re-users, Wikipedia article editors, and third-party media creators prefer raw, modular B-roll that they can easily splice or embed.
• Target "Featured Video" Status Natively on Commons:
  • Engage directly with the Commons Featured Video (FV) community rather than Wikipedia WikiProjects.
  • Focus on technical merit: high bitrate, smooth stability (like steady drone pans), proper exposure, accurate color grading, and native audio or license-compliant sound.

I find video editing and the creative process fulfilling and relaxing, but I have been doing it since the days of the Video Toaster in 1990. Many of the FP contributors use the Adobe interface of Photoshop and the hop to Premiere or other open source editing tools such as Kdenlive, Olive Video Editor & Shotcut all have similar functions and interfaces.

That program was clearly well intended. The structural, technical, and cultural friction between text-first Wikipedia editors and video creators does not happen here on Commons, as a group we are creators or critics but never text first editors. Perhaps we retry that here on Commons after setting down a few book ends for contributions to the project? Don (talk) 00:37, 23 August 2026 (UTC)

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

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)

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

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)

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)

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)

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)

 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)

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

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)

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)

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)

 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)

 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)

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)

 Oppose per Pi.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:32, 19 August 2026 (UTC)

Repeal Orphan Works policy

It is not difficult to show that a textual application of COM:ORPHAN violates the official COM:LICENSE policy. According to {{Orphan work}}, a work is considered an orphan work' when the author(s) or other right holder(s) is not known or cannot be located. By definition an orphan work has a copyright holder and therefore it is a copyrighted work. Unless a work has a free license, COM:L doesn't allow to host copyrighted works. This might sound an abuse of our definition, but it is not. The EU directive of Orphan Works[5] defines them as works that are still protected by copyright but whose authors or other rightsholders are not known or cannot be located or contacted to obtain copyright permissions.

The policy doesn't allow all orphan works they must either (1) were created before 1931; or (2) were created before the pma duration (required years after the author's death) in the country of origin, which would satisfy {{PD-1996}} if published at the time of creation; or both. The first option is a relaxed version of {{PD-US-expired}}, the second option is a complicated way of stating that if the orphan work is considered an anonymous work it would be in the public domain in both the US and in its country of origin.

The first problem of the policy is that we can choose one of the options at will. It trivially accepts orphan works that are PD in the US, but are protected in its country of origin, violating COM:L. The second problem is that it assumes that every time that there is an author that we don't know when they died, they died shortly after they published the orphan work. This is complete unrealistic. Moreover, if we have two orphan works of the same author we might allow one but not the other, even though the excluded artwork proves that the first one is not PD (assuming N years pma copyright). Things get worse if we actually interpret the "author that cannot be located". The current policy allows uploading an a 1940 artwork of a living French hermit.

We might amend the policy to exclude the problematic cases, but I can only imagine a tangled way of saying that we accept an orphan work if either (1) it is PD assuming publication date is creation date (2) the author is unknown and something similar to {{PD-old-assumed}} applies. Günther Frager (talk) 00:39, 14 August 2026 (UTC)

@Günther Frager: I find myself extremely confused as to what you are proposing here. What exactly in our policies or guidelines do you want to remove? What, if anything, do you want to substitute for that? - Jmabel ! talk 05:50, 14 August 2026 (UTC)

@Jmabel: What exactly in our policies or guidelines do you want to remove? I want to remove COM:ORPHAN. What, if anything, do you want to substitute for that? with nothing. If someone wants to upload what it is described as orphan work, i.e. non-anonymous works lacking precise authorship information, then it should satisfy {{PD-old-assumed}} or similar as was always the case. Of course, for US works you the only requirement is {{PD-old}} {{PD-US-expired}}. Günther Frager (talk) 07:21, 14 August 2026 (UTC)

This makes only slightly more sense. COM:ORPHAN is a shortcut. Do I take it you are saying you want to remove the section "Old orphan works" on the page Commons:Licensing? But then you go on to say Of course, for US works you the only requirement is {{PD-old}}, which I believe is absolutely wrong. PD-Old is neither necessary nor sufficient for U.S. works. (It's also a deprecated template.) A work published in 1939 by an author who died the following year would not yet be PD in the U.S. A work published in 1929 by an author who lived into the 2000s would be public domain. - Jmabel ! talk 19:01, 14 August 2026 (UTC)

There isn't much issue with US works. We only need the date of publication. Whether we know something about the author or not doesn't change much the copyright status. The issue is therefore mostly with non-US works with uncertain author(s). For many cases for old works, we only know either the author's initials, pseudonym, or partial name, or nothing. In these cases, it may not be sufficient to find when the author died. These are orphan works where we need a relax policy. Yann (talk) 19:09, 14 August 2026 (UTC)

@Yann: one slight correction to that: if a work was published no later than 2002, then for U.S. law we only need the date of publication. - Jmabel ! talk 23:24, 14 August 2026 (UTC)

@Jmabel: Thanks for pointing out the inconsistency, I meant {{PD-US-expired}}. I mixed it up as I usually upload works with {{PD-old-auto-expired}}. I get the point that we would like to relax the requirement, my argument is that the current requirements are absurd. The policy is not specific for old photos, it applies to all kind of works, and it not only covers authors that are likely dead but also living ones. According to the current policy it is OK to go to the Canadian repository for orphan works and upload any artwork published before 1931, for example a painting by Hal Ross Perrigard (1891-1960) published in 1928 [6]. It is not difficult to see that it is a plain copyright violation in Canada. An hypothetical case would be if the paintings of Pablo Picasso were considered orphan works, then we would be allowed to upload a large number of his paintings including the iconic Guernica that he painted in 1937 and will enter the French public domain in 2044. Notice that even {{PD-old-assumed}} would wrongly consider many early works of Picasso in the PD. How would you reformulate the requirements of COM:ORPHAN to avoid these problems? Günther Frager (talk) 20:16, 14 August 2026 (UTC)

The point is that it is absurd to use the same criteria for one-hundred-year old pictures and for recent ones. For recent ones, I agree that we should assume that it is under a copyright unless proved otherwise. For a 1926 picture, this is nonsense. There is a very high chance that the image is in the public domain, and we should assume so unless proved otherwise. Yann (talk) 23:30, 14 August 2026 (UTC)

Let's assume the photo was taken in France (I have better data for the U.S. but their copyright law doesn't help). The borderline year for PD in France is today 1955 (let's ignore war extensions). The average life expectancy in France in 1955 was 68.4 years[7]. So an average Monsieur Dupont was 39 years old in 1926. Why do you think it is absurd that a 39 or younger years old person couldn't take a photo in 1926? Besides the policy assumes that a 1945 photo created in France is fair game. Günther Frager (talk) 00:57, 15 August 2026 (UTC)

There are several different, intersecting issues in dealing with orphaned works. I could imagine us choosing to refine the current policy, but I think it is already pretty close to what we want.

The issues I see; I might be missing something, of course:

• U.S. vs. source country. Almost certainly, the only copyright laws we must follow in terms of what we publish are those of the United States. While Internet sites, of course, have a global reach, it seems to be accepted that for copyright purposes they have a single "location". Therefore, we need to be concerned with U.S. law as a matter of strict legality; any abiding by copyright laws of other countries is always a matter of courtesy. (We happen to try to abide by they copyright laws of what we consider to be the relevant source countries for works; we ignore the laws of other countries; one of those is just as arbitrary as the other in terms of law.)
• Commercial vs. non-commercial (and, in particular, non-commercial educational). While as a matter of policy, we attempt to host only materials that can by used commercially, legally we would certainly be considered a non-profit educational organization. If we accidentally cross that line into things that cannot be used commercially, it could be a legal problem for reusers, but probably not for us. In particular, I've literally never heard of a legal case where a non-commercial educational organization got in trouble for publishing what they reasonably believed to be an orphaned work, and the warning template we already use probably makes things sufficiently clear for reusers.
• Various meanings of "orphan work": as far as I know, we do not apply the policy under discussion here to allow hosting works of a known author with a known death date but whose works are still clearly copyrighted in their home country, merely because we do not know who would be the current holder of the copyright (your Perrigard case). We apply it for works where authorship is unclear, or a known author's death date is unknown and, in the latter case, if we know they were alive at some certain date later than the work in question, we respect that. For example, if someone in France was born in 1900, created and published a work in 1925, and is known to have lived at least until 1970, we would not allow uploading that simply because the precise date of their death is unknown.

Jmabel ! talk 23:54, 14 August 2026 (UTC)

Again, if we know precisely who is the author, and when s/he died, the copyright status is easy. All the issues are when we do not know precisely who is the author (e.g. a 1920s picture by some family member, but who exactly?), or a 1920s postcard made by an obscur photographer only known as J.D. These are orphan works, and that's where we need a different policy than requiring the exact name and date of the author. Yann (talk) 00:40, 15 August 2026 (UTC)

• Almost certainly, the only copyright laws we must follow in terms of what we publish are those of the United States. You are confusing US law with Commons official policy. We can under U.S. law host CC-BY-NC-ND works, but we don't allow them by policy. We require PD in country of origin by policy. My life would be easier if the only allowed tag were {{PD-US-expired}}.
  • (1) No, I am not confusing laws with policy. In the case of NC-ND works, that is policy, and comes from the WMF level, where they stipulated that Commons may not have an Exemption Doctrine Policy. (2) My life would be easier if the only allowed tag were {{PD-US-expired}}. That would not allow us to host U.S. government works, nor any CC-licensed works! Simple, but not very useful.
• Commercial vs. non-commercial same issue as previous points. Commons aims to have other users apart from Wikipedia. If we welcome non-comercial artworks, we will be flooded with uploaders but we will lack downloaders.
  • My point was only that this is a policy decision (from WMF), not a decision driven by law. - Jmabel ! talk 16:59, 15 August 2026 (UTC)
• Various meanings of "orphan work" the policy links to the en.wiki definition: An orphan work is a copyright-protected work for which rightsholders are positively indeterminate or uncontactable and {{Orphan works}} defines it as The author(s) or other right holder(s) of this work is not known or cannot be located. If we don't want to apply this meaning, then we should state which definition of "orphan work" we allow. Günther Frager (talk) 12:32, 15 August 2026 (UTC)
  • True as far as it goes, but what I am saying is that there are various reasons why a work can be orphaned, and in practice we do not treat those identically. - Jmabel ! talk 16:59, 15 August 2026 (UTC)

 Oppose We are already much too strict regarding old pictures, with unrealistic requirements. We should relax the policy for old pictures, not making it even more paranoid. Honesty, I am fed up with this kind of attitude, which is completely detrimental to the project. Yann (talk) 09:39, 14 August 2026 (UTC)

 Oppose per Yann as too strict. We don't want to be "more Catholic than the Pope".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:47, 14 August 2026 (UTC)

• Category:Orphan works has less than 200 files in it. Are they really so problematic? Can you name some specific examples? Nemo 21:09, 14 August 2026 (UTC)

  @Nemo bis: This is a really good question! I can respond with another question, does it make sense to add a policy that violates core policies COM:L, COM:EVID, COM:PCP that we are supposed to break to just add 166 files? Your question already invalidates the the only opposing argument that without this policy we are too restrictive. The problem is not how many files have the {{Orphan work}} tag, but what kind of files does this policy allows to upload.

  But if you are a data-driven person, you will find that almost 60% of the photos come from a single Flickr album. On this album all the photos don't need the relaxed conditions of COM:ORPHAN, something like "PD-US-expired-assumed" or "PD-US-no-notice-assumed" would suffice. With a bit more of statistics you will find out that 80% of the uploads come from the same uploader that by some random chance is the one that proposed the policy . On the remaining files, you will find that some are works that are copyrighted in their (European) country of origin, but are PD in the US, and with many there is little evidence that they are actually orphan works. I stated a DR but since COM:ORPHAN is a policy that allows to upload copyrighted works without free licences, I decided to point out the problem in the policy before continuing . Günther Frager (talk) 23:22, 14 August 2026 (UTC)

  What do you mean by "evidence that they are actually orphan works"? By definition an orphan work is a work where copyright holders cannot be found. It cannot be comprehensively proven that no copyright holders survive (cf. w:en:Russell's teapot); it's also possible to show results of a search according to a certain standard of due diligence. Nemo 19:53, 17 August 2026 (UTC)

  What do you mean by "evidence that they are actually orphan works"? The sentence starts with On the remaining files, so I meant that there are files in the category that show little or lack of evidence that the copyright holders cannot be located. Some examples:

  • File:Voluntad (1928).webm apart from not being in the public domain in Spain (80 years pma) as the director died in 1953, the archive is a restored version and if you look of this info you will find that the son of the producer, the likely copyright holder, provided the original copy [8].
  • File:ABC.VI.1913.01.jpg again no public domain in Spain (author died in 1975) and the caricature was published in the magazine Blanco y Negro (still on print and renamed to ABCD Las Artes y Las Letras in 2005). Not only the publisher remains in business, Ricardo Martínez Ibáñez, a grandson of the artist, is still alive[9].
  • File:Affiche de la Compagnie Franco Roumaine de Navigation Aérienne 1922.jpg the artwork is signed by Torlotin and it is part of an ad by CFRNA, one of the companies that merged into Air France in 1933, see en:CFRNA. Air France it is still in business. Moreover, the artwork is sold claiming that the copyright holder is Musée Air France [10][11] something that is enforced in Gallica [12] as it claims Rights: restricted use (convention 2018-188-423). As there is no COM:EVID of the death of author, the claim it is in the French public domain is also dubious.
  • File:Girl with flowers, October 1966.jpg photo from a Flickr account that claims he found the photo somewhere and that in the back it is dated 1966. The back of the photograph is not available, so it is difficult see if the back said 1966 or © 1966 Joe Doe. Notice that uploading front and back is what we use as evidence for US press photos.

  Günther Frager (talk) 11:28, 18 August 2026 (UTC)

•  Support: I find it difficult to reconcile the existing orphan works policy section with more well established conventions such as COM:EVID. Commons should opt for legal clarity to the fullest extent possible. – Howardcorn33 (💬) 11:04, 16 August 2026 (UTC)
•  Oppose the complete repeal especially if this means that we stop assuming that publication date was shortly after creation date unless we have evidence of the contrary,  Support limiting the policy to the cases in which the author is unknown, and not also those where the author can not be located. I think that we should also add a due diligence requirement, which is present in most legislations about orphan works. I'm neutral on the requirement for the countries of origin, even if I don't think that it's so unreasonable to treat these as anonymous works if we really don't find any information about the author.--Friniate (talk) 13:01, 16 August 2026 (UTC)

  We should also speciy in the template that if other copyright licenses can be used, then we should use them instead of this template. Friniate (talk) 13:03, 16 August 2026 (UTC)

•  Support per proposal and Howardcorn33. With {{PD-old-assumed}}, we already have a similar policy for works which are at least 120 years old. If, like in Yann's example of the 1926 photo, you want to have the same for works which are 100 years old (similar to what the German wikipedia has), try to achieve a consensus to change the 120 years in that policy to 100 years. Do not introduce a new policy to further muddle and complicate things. --Rosenzweig τ 14:19, 16 August 2026 (UTC)
•  Strong support Oh, that "policy" which was introduced in 2023 with insufficient discussion, and was never really practicable. I actually drafted a proposal to discuss it in late 2023, but then it sat on my harddisk and I didn't follow up on it. For what it's worth, this is my 2023 text:

• Background:
• For a long time, we had no "clean" way to accept old works where it seems very likely that they are in the public domain, though we have insufficient information on authorship and publication history to be certain. Often, blanket templates such as {{PD-old}} were used even though the formal requirements were not met, which led to unpredictable outcomes of deletion requests. After a thorough community discussion in 2017, we introduced {{PD-old-assumed}} with a cautious approach: assumption of public domain in countries with a copyright term of a certain amount of years after the death of the author (known as pma, template's default: 70 years) only if the work was created over 120 years ago. For works that have also been published in the US more than 95 years ago (that is, currently before 1928), we now also have the combined tag {{PD-old-assumed-expired}}.
• In June 2023, Yann proposed a further-reaching policy to allow "old orphan works". The proponent himself closed the rather short discussion in August as "accepted" and introduced COM:L#Old orphan works to the policy page.

To me, this is problematic, as the "old orphan works" policy seems to contradict the restrictions of PD-old-assumed. If we determine that something is an "orphan work" (on which grounds exactly? - a question then asked by Rosenzweig, and User:LPfi pointed out that it wouldn't be that easy), according to this policy, it can be uploaded when it was created before 1928 or if "the works were created before the pma duration in the country of origin, which would satisfy {{PD-1996}}, if published at the time of creation (e.g. works created before 1946 for 50 years pma countries, if the URAA date is 1996)." Especially the latter provision is confusing in my opinion - if I read this correctly, in the example it's assumed that the author died no later than 1945 if a work was published before 1946, which isn't realistic if it's only a few years before 1946 - that's exactly why PD-old-assumed was created with such a cautious term.

It is my opinion that the discussion for the proposal that led to the introduction of COM:L#Old orphan works had too few participants and wasn't thorough enough, so I'm opening this new discussion asking for ideas on how to remedy the inconsistency created. I have no concrete proposal as yet, though I must confess that I would be in favor of removing COM:L#Old orphan works altogether, as I don't think it's well thought through. If others are of the same opinion, I would start a formal proposal for this.

Gestumblindi (talk) 14:34, 16 August 2026 (UTC)

 Oppose While the current orphan-work exception isn't ideal, I certainly think there is a place for a relaxed policy on orphaned works that we are legally allowed to host. The common-sense criterion would be that the covered orphan works should be those for which (1) the copyright most likely has expired or (2) somebody being aware of their copyright would similarly be very unlikely. The former is mostly covered by PD-old-assumed & co, but there are also works that aren't that old, but are likely to be out of copyright as anonymous works. To formalise the criteria, discussion is needed. One important class of works are photos in family albums – most of those can be regarded as anonymous (claims about authorship have to be raised during the anonymous term, at least over here). –LPfi (talk) 17:01, 16 August 2026 (UTC)

But the attempt of this 2023 policy to create something all-encompassing for "old orphan works" doesn't really work, it's not without reason that we have a variety of templates for anonymous works depending on the circumstances. Gestumblindi (talk) 17:31, 16 August 2026 (UTC)

@Gestumblindi But bringing evidence that a work is really anonymous is really difficult...

Moreover I think that it's important to formalize in a policy the idea that we usually presume that the date of publication is near to the date of creation unless we have evidence of the contrary. Friniate (talk) 17:53, 16 August 2026 (UTC)

@Friniate: That's something I agree with, "that we usually presume that the date of publication is near to the date of creation unless we have evidence of the contrary", and I would absolutely support a policy that just clearly states this - but not this "orphaned old works" policy as it's phrased now. Gestumblindi (talk) 17:56, 16 August 2026 (UTC)

Fair enough. Friniate (talk) 17:59, 16 August 2026 (UTC)

 Oppose I think it is a great idea to demand evidence, but there is no reason to demand that this evidence is beyond all doubt. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 18:01, 16 August 2026 (UTC)

•  Support repeal, because of lack of specific consensus to override or to favourably interpret COM:EVID and COM:PCP policies, and no evident consensus in original discussion about the precise scope (which definition of orphan works, what if there is a legal regime for orphan works in that country, which presumptions are valid as to the kind of work or kind of photographer/painter/creator, what should we assume about inheritance, etc.). I am not opposed in principle to accepting more works or varying project scope, and I think the existing discussion is a fine first step in surfacing important concepts and pain points. Ultimately, many orphan works are likely under valid copyright for which we have no evidence, and our mere lack of evidence is the weakest kind of evidence of lapse into the public domain. We don't even have a great way explain, defensibly and in a general copyright sense, what is going on. TheFeds 21:09, 17 August 2026 (UTC)

Adding a timespan filter to WikiMap

WikiMap is a good tool to show images. But it has its limits. When too much images are taken within a place, only a limited selection is shown. An example is the Brandenburg gate. To manage better in crowded places, I would like to propose a timespan filter. This allows searching for images taken until 1950 or during the pandemic. -- PantheraLeo1359531 😺 (talk) 19:01, 16 August 2026 (UTC)

i think you need to ask @DB111. RoyZuo (talk) 20:27, 20 August 2026 (UTC)

Idea: Implicit Wikidata infobox for Wikimedia Commons categories

We’re all very familiar with the {{Wikidata Infobox}} template. It’s extremely useful. Why should we have to manually add the Wikidata infobox template to every single Wikimedia Commons category? Shouldn’t the infobox be displayed automatically whenever the Wikimedia Commons category is linked to a Wikidata item? --Geert Van Pamel 14:52, 17 August 2026 (UTC)

@Geertivp: Where, exactly, should it automatically be positioned, given that having it come first does not always work well with other templates? - Jmabel ! talk 23:58, 17 August 2026 (UTC)

Yes, this might be a potential problem, I agree... but in 99% of the cases positioning of the infofox at the top of the page should normally work? If it won't properly work automatically in certain cases, then a {{Wikidata Infobox}} should be inserted manually in the body text to overrule the automatic placement? Automatic generating of the infobox should avoid the huge manual work that we have to do currently by physically inserting the infobox template in each and every category... --Geert Van Pamel 20:32, 18 August 2026 (UTC)

This should be solvable with some CSS without making any changes to the Wikitext of pages. GPSLeo (talk) 20:42, 19 August 2026 (UTC)

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

We have universal support for autoconversion from MP4 to WebM within the Upload Wizard.[13] 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)