Jump to content

Commons:Village pump/Proposals

Add topic
From Wikimedia Commons, the free media repository
< Commons:Village pump
Latest comment: 26 minutes ago by Wilfredor in topic Make fpc-voter a gadget

Shortcuts: COM:VP/P • COM:VPP

Welcome to the Village pump proposals section

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

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

 

Start a new discussion

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

Restrict category creation to registered users

[edit]
Latest comment: 11 days ago19 comments9 people in discussion

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

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

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

For context, read:

As I wrote to them on my talk page:

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

to which they responded

"I stand by what I did."

and

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

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

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

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

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

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

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

Category PAGE creation ? or category creation ?

Category PAGE creation. Adding a category to a file is not the same as creation of that category Οἶδα (talk) 18:22, 17 June 2026 (UTC)Reply
A weary  Support. The current state of affairs is that, from a procedural perspective, it is dramatically easier for users to create category structures (e.g. creating category pages and populating those categories) than for other users to abolish those categories. We've seen repeated waves of bad category creations by IPs / temporary accounts in certain topic areas involving fictional characters and children's film and TV series. While these changes certainly could be made using a registered account, the use of multiple temporary accounts makes it much more difficult to identify which categories were affected and revert the changes. One typical example from a few years ago was Commons:Categories for discussion/2024/05/Category:Films by character. Omphalographer (talk) 20:01, 17 June 2026 (UTC)Reply

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

I guess nothing Οἶδα (talk) 20:12, 18 August 2026 (UTC)Reply
There has to be something. Οἶδα (talk) 19:54, 27 August 2026 (UTC)Reply

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

[edit]
Latest comment: 9 days ago56 comments20 people in discussion

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

This proposal is intended to ban

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

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

CC 1.0 template cleanup

[edit]

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

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

CC by-all

[edit]

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

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

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

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

[edit]
Latest comment: 7 days ago23 comments16 people in discussion

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

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

Option 1 - Modify CSD F8

Addition below, in red:

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

Option 2 - New CSD

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

Discussion

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

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

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

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

XML dump <text> has non-xml metadata

[edit]
Latest comment: 18 days ago12 comments8 people in discussion

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

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)Reply
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)Reply
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)Reply
...
[[category:French military personnel of the Peninsular War]]</text>
... ~2026-43049-96 (talk) 22:31, 4 August 2026 (UTC)Reply
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)Reply
  • 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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply

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

[edit]
Latest comment: 4 days ago40 comments16 people in discussion
Tracked in Phabricator
Task T270855

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

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

Subtopic: JPEG XL use cases

[edit]

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

Layers! Nosferattus (talk) 17:05, 1 September 2026 (UTC)Reply

Subtopic: Prioritizing JPEG XL vs. AVIF

[edit]

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

Both? Bedivere (talk) 02:01, 3 September 2026 (UTC)Reply
i think, commons should look at what the newest best cameras and phones support, to decide what formats it should support, coz most images contributed are taken by cameras and phones.
i checked w:Canon EOS R1 w:Sony α1 II iphone 18 samsung s26. they all support jpg, raw and w:HEIF.
from this perspective, HEIF might be the one to spend resources on. RoyZuo (talk) 08:37, 3 September 2026 (UTC)Reply
should ask people in canon, sony, fujifilm, samsung, apple... what formats they use in 10 years; to what format the industry moves from jpg. RoyZuo (talk) 08:44, 3 September 2026 (UTC)Reply
To my knowledge, most Android smartphones use Google's Ultra HDR format, which encodes a gain map in the metadata of a regular JPEG file. It's designed so that incompatible devices can simply ignore the gain map and render the image as SDR. Apple also uses gain-mapped formats. There is an open source tool that can convert Ultra HDR JPEG and Apple HDR HEIC images to HDR10 AVIF or OpenEXR.
The problem with HEIC is patent restrictions, so we can't accept it per COM:PS/FT. Qzekrom (talk) 14:12, 3 September 2026 (UTC)Reply

References

[edit]

References

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

Video on Commons

[edit]
Latest comment: 5 days ago29 comments9 people in discussion

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

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)Reply
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)Reply
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)Reply
@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)Reply
@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)Reply
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)Reply
No I do not. Don (talk) 21:32, 10 August 2026 (UTC)Reply
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)Reply
Our local TV broadcaster still produces in 1080i50 oder i60 and an awful bitrate :D --PantheraLeo1359531 😺 (talk) 09:33, 9 August 2026 (UTC)Reply

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

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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
I don't think its fair to call upload wizard a third party tool Bawolff (talk) 06:30, 15 August 2026 (UTC)Reply
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)Reply
Just to be clear, i mean Special:UploadWizard not special:upload Bawolff (talk) 17:54, 15 August 2026 (UTC)Reply
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)Reply
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)Reply
Perhaps some inspiration can be taken from w:Wikipedia:WikiProject Wiki Makes Video Bawolff (talk) 23:50, 22 August 2026 (UTC)Reply
@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)Reply

I have run a series of tests over the last 2 weeks to explore options when uploading large videos, or what is considered to be large by current Wiki standards. The ability to overwrite IMHO is tannimount to making the process work simple and consistant. For example: I have a video that is uploading now. It was shot 4k 24 fps MP4 (H.264/AVC) it was 9.58 gig raw at 27 min. I tried to compress it first via the export tool in Premiere to WebM but the resulting video was 5.6 gig, still too large to upload. Next I exported it as a 1080 H.264/AVC file, reducing the file size from 9.58 to 4.07 gig. After the second layer of compression it was only 563.69 mb. It seems video2commons has the ability for self recovery during failed uploads as I have had files I did some digging around and was able to isolate a way to add a overwrite option to video2commons.

This series of steps is exactly what discourages many people from contributing. The process feels frustratingly clunky—almost like returning to the era of single-speed CD-ROMs and QCIF video at 176x120 pixels, the postage-stamp-sized video of 30 years ago.

I recently came across a discussion about MP4 support from a year ago. It was constructive and productive, but it seemed to accomplish nothing in the end.

I have looked into the parts of Video2Commons that can recover during the final server-side compression phase and successfully load a file after multiple failures. However, the system still rejects existing filenames in both the browser and the worker.

I have code for an overwrite option in Video2Commons. The necessary changes are straightforward:

Allow the MediaWiki “exists” warning. Remove the backend rejection of existing files. Stop the front end from requiring a unique filename.

The result would allow a contributor to upload a revised version under the same filename, creating a new revision while preserving the file’s history.

If someone is willing to apply the patch and test it, I would be glad to provide the code. This could make Video2Commons substantially more practical for contributors who regularly revise and improve their media. --Don (talk) 23:52, 1 September 2026 (UTC)Reply

Someone needs to explain the thought process behind restricting overwriting of larger videos.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:15, 2 September 2026 (UTC)Reply
It is counterproductive. Photo contributors are free to upload at will, it seems like a simple fix. Don (talk) 22:45, 2 September 2026 (UTC)Reply

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

[edit]
Latest comment: 13 hours ago16 comments9 people in discussion

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

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

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

@Bawolff: I like the result as shown in the examples. (One quibble: "Media contains" is a much less accurate statement than "depicts".) Anything to say about overhead? Also, we'd presumably want to add all of this also to templates such as {{Art photo}}, etc. - Jmabel ! talk 05:45, 12 August 2026 (UTC)Reply
Personally I've always thought "depicts" sounded very stilted which is why i went with the other wording, but i'm not particularly attached to that, so am happy with making the column header be anything. As for overhead, my main worry is that currently it only shows non hidden categories (which i'm also not sure if that is the right thing to do), but the way it figures out if a category is hidden creates a template link, which the DBAs probably wouldn't like. I think there may be alternate solutions for that (involving scribunto changes) we could explore if this idea gets popular support. It would also create a lot more cross linking to Wikidata, which i'm assuming is ok, but dont actually know. If the proposal gets support, it would probably make sense to discuss with user:Ladsgroup before actually implementing. Bawolff (talk) 06:34, 12 August 2026 (UTC)Reply
I agree that "depicts" is a little awkward, but using the term "contains" implies that statements should be added for anything which is visible at all in a photo or video, rather than only for things which are significant to the media file. By way of example: File:Obama and Biden await updates on bin Laden.jpg contains laptop computers, coffee cups, and neckties, but depicts none of those things. Omphalographer (talk) 17:35, 12 August 2026 (UTC)Reply
I believe Depicts is the right terminology. Making a distinction between primary (most important) and secondary ("background") items on a picture can be easily and clearly made via the "prominent" qualifier. --Geert Van Pamel 20:23, 19 August 2026 (UTC)Reply
Perhaps it makes sense to start with {{Art photo}} as a less used template before going on to the super widely used {{Information}}. One blocker here, is to distinguish between hidden and normal categories without overstuffing the number of teplatelinks, we need https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1325415 merged. Alternatively we could just display all categories without distinguishing between normal and hidden ones. Bawolff (talk) 19:38, 19 August 2026 (UTC)Reply
 Oppose Depicts, and categories are longtime "standard" functions of Wikimedia Commons. There is a strategy to work more with digital metadata in the Structured Data on Commons, and going away from templates containing text in order to more easily find media files/images. We don't want to further confuse the volunteers with yet another way of entering metadata. --Geert Van Pamel 20:06, 19 August 2026 (UTC)Reply
@Geertivp I'm confused by your comment. Nothing here is proposing a new way of entering metadata. Bawolff (talk) 20:19, 19 August 2026 (UTC)Reply
Then I understand you are proposing to duplicate the information about categories and depict statements in the {{Information}} template? I believe the current form is already too cluttered; I believe you will further confuse the reader. And there exist 100 (?) other templates beside {{Information}}. --Geert Van Pamel 20:28, 19 August 2026 (UTC)Reply
Just to clarify to ensure we aren't talking past each other since I'm not entirely sure how to interpret the word "duplicate" in your sentence. The proposal is to display categories & depicts information with the information box on the image description page. The proposal is just to alter how stuff is displayed. There would be no change to the wikitext on the image page.
I think the existing system is extremely confusing to the reader and a major reason why SDC is largely not being adopted at commons. Readers expect information to all be in one place formatted consistently, not spread throughout the page using very different UIs. Bawolff (talk) 20:55, 19 August 2026 (UTC)Reply
very good job. tysm.
 Support using this until commons has better native display of data.
for "media contains", 3 ideas:
  1. maybe "shows" instead of "contains"
  2. maybe the template can be smart enough to tell what kind of file it is, and so switches accordingly, "image/video/pdf shows" "audio contains"...
  3. or use "file" instead of "media" coz media could be a bit ambiguous.
RoyZuo (talk) 17:12, 12 August 2026 (UTC)Reply
 Support looks useful and fits nicely. I think the label is not that important as long as it is translatable and good enough for both images and videos. Nux (talk··dyskusja) 20:18, 12 August 2026 (UTC)Reply
 Oppose We don't need to make the information template longer, thus pushing the important license information even lower on the page. Depicts statements in particular I find to be particularly low-value; as far as I'm concerned, they just duplicate the description and categories. It's also confusing to show categories in a location different from where they can be edited, and depicts on a completely different tab from editing. Pi.1415926535 (talk) 22:32, 19 August 2026 (UTC)Reply
  1. "...pushing the important license information even lower on the page..." 🤷‍♀️ the template can simply be tweaked to display licence info stored in sdc on top then.
  2. i find it more confusing that sdc is on a different tab that requires clicking. i'm a user not an editor: i want to see depicts but i rarely edit them. only a handful of people ever would edit sdc of a file, but thousands of users would see them.
  3. sdc display in users' chosen languages, regardless of what language (unintelligible to them) of the description might be.
RoyZuo (talk) 20:23, 20 August 2026 (UTC)Reply
 Oppose per Pi.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:32, 19 August 2026 (UTC)Reply
 Support - And get rid of categories while we're at it. Nosferattus (talk) 23:25, 7 September 2026 (UTC)Reply

Repeal Orphan Works policy

[edit]
Latest comment: 12 days ago33 comments13 people in discussion

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[4] 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)Reply

@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)Reply
@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)Reply
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)Reply
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)Reply
@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)Reply
@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 [5]. 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)Reply
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)Reply
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[6]. 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)Reply
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)Reply
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)Reply
  • 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.
  • 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)Reply
 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)Reply
 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)Reply
  • 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)Reply
    @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)Reply
    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)Reply
    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 [7].
    • 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[8].
    • 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 [9][10] something that is enforced in Gallica [11] 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)Reply
  •  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)Reply
  •  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)Reply
    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)Reply
  •  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)Reply
  •  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)Reply
 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)Reply
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)Reply
@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)Reply
@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)Reply
Fair enough. Friniate (talk) 17:59, 16 August 2026 (UTC)Reply
 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)Reply
  •  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)Reply

Adding a timespan filter to WikiMap

[edit]
Latest comment: 18 days ago2 comments2 people in discussion

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

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

Idea: Implicit Wikidata infobox for Wikimedia Commons categories

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

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

@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)Reply
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)Reply
This should be solvable with some CSS without making any changes to the Wikitext of pages. GPSLeo (talk) 20:42, 19 August 2026 (UTC)Reply

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

[edit]
Latest comment: 7 days ago4 comments3 people in discussion

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

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

@Doc James: I see that the original village pump proposal was archived without being closed. What was the outcome? Qzekrom (talk) 15:06, 31 August 2026 (UTC)Reply
@Qzekrom: It should have been successful.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 19:38, 31 August 2026 (UTC)Reply
User:Qzekrom and User:Jeff G. Was not sure if we had other tools that did this, so we added it here [13] Doc James (talk · contribs · email) 03:47, 1 September 2026 (UTC)Reply

Restricting overwriting of deleted files to users with higher user right privileges

[edit]
Latest comment: 7 days ago4 comments3 people in discussion

As per my experience on reviewing recently undeleted images of Saudi buildings due to recent acceptance of architectural FoP in that country, I have encountered multiple instances of mostly users with red-linked user names overwriting decent versions of files. For example, File:Kingdom_Tower.jpg, in which the decent image file was overwritten by Hamed1122 (talk · contribs) who uploaded a probable copyvio version (considering they were a serial copyvio user per Commons:Deletion requests/Files uploaded by Hamed1122).

Another example, during the time File:Quba Mosque - panoramio.jpg was in its deleted state before two days ago, يحيى الزعبي 2025 (talk · contribs) probably grabbed the local enwiki copy and uploaded it here while claiming own work. Not only this user disregarded the prior noFoP status in Saudi Arabia (before August 2026), but also they committed an act of plagiarism. I had to request undeletion of prior versions so that I can revert all contributions by يحيى الزعبي 2025 . Do note the user has similar username pattern as Al Quran Al Kareem 2026 (talk · contribs) who also committed some act of overwriting deleted images of Saudi buildings by uploading local enWiki copies of those images here while claiming authorships. Their actions before partial FoP introduction has caused inconvenience for reviewers like me.

I suspect these regular users with red-linked user pages ignored the red boilerplate warnings indicating a file with the same name was previously deleted. They ignored the links to relevant DR pages explaining the situation. Whether their ignorances are intentional or accidental doesn't matter.

To prevent similar instances in the future for images of buildings and monuments from other countries, I propose restricting the ability of overwriting deleted files (file names in which when visiting gives a red boilerplate notice and explanation) to users with higher privileges of user rights. Whether autoconfirmed or (better) autopatrolled rights is up to the community to decide. I suggest autopatrolled, since Hamed1122 created account on July 23, 2015 and continued to upload copyvio files, including one instance of overwriting a decent deleted file in October that same year, which is already within the territory of the autoconfirmed users.

As a secondary advantage, it saves time for regular admins at COM:SPLIT. By establishing such restrictions, they could now deal with requests to split versions of live image files, not the requests to split versions of image files that became possible due to overwriting when those files were still in their deleted state. JWilz12345 (Talk|Contributions) 01:16, 31 August 2026 (UTC)Reply

 Oppose This proposed change would add an extra step for me when I move a file because it's an old logo or outdated, and someone wants to upload the current version to that file name. Creation protection is something I can do to deleted file names already. I'd rather do that than make this proposed change. Abzeronow (talk) 02:13, 31 August 2026 (UTC)Reply
@Abzeronow I thought of one more alternate proposal before this, which is granting temporary file undeletion right to a trusted autopatroller in the event of copyright law change in a certain country, provided that the following conditions are met (no exceptions to any of the conditions).
  1. The copyright law change must be beneficial to Wikimedia. Two examples: Commons-suitable Freedom of Panorama regardless of buildings only or also encompassing monuments/sculptures/applied art (but not 2D art which is a more contentious area in FoP rules), and/or change in provision concerning stamps or currency (if the law finally grants public domain status to stamps and currencies).
  2. This copyright law change must be discussed in any of the broad community forums, be it COM:VP or COM:VPC, not COM:AN which I think isn't broad enough. Discussion should span not less than 7 days and not less than 5 participating users (excluding the person who opened the discussion).
  3. Granting of temporary "file undeletion" request must only come after there is concrete consensus that the Commons has accepted the applicability of the law change to Commons with respect to COM:Licensing.
  4. The non-admin or non-sysop user to be given a temporary file undeletion right must have no recent incidence of copyvio record (whether at least a year or more, can be less than 12 months but to be decided by Commons admins).
  5. This user must also have the following qualifications: autopatrolled right for at least 5 years from the year of the temp file undeletion right request (not date of the request, e.g. counted from January 1, 2026) and an image reviewer right for at least 3 years from the year of the temp file undeletion right request.
  6. This user should also had seriously participated in at least 100 relevant deletion requests within the last two years. For example, if they seek temporary undeletion right on the basis of FoP rule change, the user should have participated in 100 FoP-related deletion requests seriously and objectively, either starting well-versed deletion requests (not just simply "No commercial FoP in France. The architect hasn't yet died for more than 70 years. Period.") or commenting in the DRs objectively and not resorting to feelings or personal/hypothetical opinions without backing linked sources/references for their comments.
  7. This user should have the history of treating broken EXIF metadata in more recent images (FBMD, twitter-like transmission codes etc) as serious issues.
  8. Only admins will grant that temporary file undeletion right.
  9. Once granted, the autopatrolled user must exercise fullest responsibility and not abuse the right to undelete files not relevant to the copyright rule or law change (for example, restoring images of the Philippines despite the only relevant change is about images of Saudi Arabian building exteriors; restoring logo or screenshot images despite the only change is about Kosovar FoP or Belgian FoP). Immediately, select admins will monitor them even if they are already autopatrolled. Daily basis monitoring. Non-admin other autopatrolled users can also help in monitoring the user granted with the temporary right.
  10. The user should report to the admins when they are already done undeleting, preferably at COM:AN. If done, the right must be revoked immediately and the user returns as a regular autopatrolled and image reviewer user.
  11. For erring users with this temporary right: only two strikes. First offense, a serious verbal warning with a threat to revocation of temporary right, and last offense: revocation of the right, revocation of autopatrolled and image reviewer right, and permanent non-eligibility to become admin, sysop, bureaucrat, interface admin, or any other higher-tier user right with highest responsibilities.
I don't know if this would be OK for Commons admins. JWilz12345 (Talk|Contributions) 04:30, 1 September 2026 (UTC)Reply
@JWilz12345: This sounds like a good idea, and one I'd like for myself, but historically the WMF and TPTB here have been very reluctant to unbundle the undelete right from Adminship.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:20, 1 September 2026 (UTC)Reply

Drop ogv (Theora/Vorbis) from video2commons

[edit]
Latest comment: 3 days ago5 comments5 people in discussion

com:v2c currently offers 4 options:

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

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

so maybe v2c should stop offering theora?

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

Do you mean that there's still an option to export Theora? Yeah, we should not be encouraging Theora in new uploads. Qzekrom (talk) 13:45, 4 September 2026 (UTC)Reply
probably a good idea to remove that option from c2v —TheDJ (talk • contribs) 15:33, 4 September 2026 (UTC)Reply
It probably also makes sense to remove vp8 as an export option. Bawolff (talk) 16:53, 4 September 2026 (UTC)Reply
Agreed. No reason to convert anything to an obsolescent format. - Jmabel ! talk 00:29, 5 September 2026 (UTC)Reply

Additional discussions about templates of political restrictions

[edit]
Latest comment: 23 hours ago1 comment1 person in discussion

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

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

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

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

Make fpc-voter a gadget

[edit]
Latest comment: 26 minutes ago1 comment1 person in discussion

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

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

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

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

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=1273920774"