Commons:VPP
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/02.
- 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?
| SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 5 days and sections whose most recent comment is older than 30 days. | |
Mass upload proposal
I'm searching for a way to upload a big batch of pictures; to do it myself or help from an experienced user to upload them.
The source website: catza.net
The licence: CC BY 3.0
The author: Heikki Siltala
The text from the website on attribution: The All photos © Heikki Siltala. The photos are immediately available both for non-commercial and commercial uses under the Creative Commons Attribution 3.0 License. There is no need to get a more specific permission or to pay money. The attribution is Heikki Siltala or catza.net.
The ideal way would be to automatically file the pictures by its description. For example this picture (https://catza.net/en/view/code/MCO_g_09_22/172054/) has the description: Escape's Rihanna, JW [MCO g 09 22] . album RuRok cat show Helsinki 2011-04-23 . cat Escape's Rihanna . breeder Escape's . FI . breed MCO . lens Sigma 85mm f/1.4 EX DG HSM . f/1.8 . 1/125 s . ISO 2000 . 85 mm . 12:21:57 . id 172054
So it can be uploaded as: Name: Escape's Rihanna, JW - MCO g 09 22.jpg
== {{int:filedesc}} ==
{{Information
| Description = {{en|Escape's Rihanna, JW [MCO g 09 22] . album RuRok cat show Helsinki 2011-04-23 . cat Escape's Rihanna . breeder Escape's . FI . breed MCO . lens Sigma 85mm f/1.4 EX DG HSM . f/1.8 . 1/125 s . ISO 2000 . 85 mm . 12:21:57 . id 172054}}
| Date = 2011-04-23
| Source = https://catza.net/en/view/code/MCO_g_09_22/172054/
| Author = [https://catza.net/ Heikki Siltala]
| Permission = All photos © Heikki Siltala. The photos are immediately available for both non-commercial and commercial uses under the Creative Commons Attribution 3.0 License. There is no need to get a more specific permission or to pay money. The attribution is Heikki Siltala or catza.net. The earlier www.heikkisiltala.com is also allowed.
}}
== {{int:license-header}} ==
{{CC-BY-3.0}}
[[Category:Photographs by Heikki Siltala (Catza)]]
[[Category:EMS Code g 09 22]]
[[Category:Helsinki cat show 2011]]
If possible the breed category could also be assigned through this code list: https://catza.net/en/list/breed/a2z/
What would be the best way to approach this upload? YukiKoKo (talk) 10:45, 25 February 2026 (UTC)
- @YukiKoKo: Hi, and welcome. COM:BATCH would be a good place to start. Please see what Yann needed to do in Special:Diff/1171701501 to mitigate the effects of your headings and templates, and avoid that need in the future. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:04, 25 February 2026 (UTC)
- @YukiKoKo: You indicated, you wanted to try yourself. I would recommend to have a look at: Commons:Pattypan --Schlurcher (talk) 07:50, 26 February 2026 (UTC)
- I've made a request for batch uploading (https://commons.wikimedia.org/wiki/Commons:Batch_uploading/Catza), so I will first wait how that will turn out. But I will have a look at Pattypan in case the batch uploading feature isn't possible. YukiKoKo (talk) 11:52, 27 February 2026 (UTC)
- @YukiKoKo: You indicated, you wanted to try yourself. I would recommend to have a look at: Commons:Pattypan --Schlurcher (talk) 07:50, 26 February 2026 (UTC)
- I would just manually upload useful photos instead. Photos like aren't really useful and photos like and require an evaluation of the local freedom of panorama laws. There are also a lot of duplicates like and with one just being a redundant (in terms of educational value) black and white of the same image. Traumnovelle (talk) 22:22, 2 March 2026 (UTC)
--missing sig as for Gnan (A)garra
Narrow scope for AI on Commons
With the recent adoption of Commons:AI images of identifiable people as a guideline, along with the increasing scrutiny and backlash against generative AI technology, I think we should consider restricting the uploading of AI to only situations where it is strictly necessary. More formally I propose adopting the following scope guidelines for AI generated content on Commons and amending Commons:AI-generated media to include and reflect the following:
Any AI generated or modified file on Commons must meet at least one of the following requirements:
1. It is an independently notable work or part of an independently notable work
2. It is currently being used per the principles of COM:INUSE
3. It is the only example of the output of a particular piece of software (for example, Sora or Grok) or type of output (for example, music or video). Dronebogus (talk) 01:50, 1 March 2026 (UTC)
Oppose, I don't think it is a good idea for now, since it would require significant changes to Commons:AI images of identifiable people when it has just recently been adopted as a guideline, and specific aspects of the text are still being discussed in its talk page. Thanks. Tvpuppy (talk) 02:36, 1 March 2026 (UTC)
- @Tvpuppy: with respect, that’s a weak reason to oppose something. Obviously the old policy would be superseded by and folded into the new one since COM:AIIP is very short and covers a narrower part of the same topic in a very similar way. Dronebogus (talk) 06:12, 2 March 2026 (UTC)
Support per nom. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 03:01, 1 March 2026 (UTC)
Oppose I still think something I proposed over a year ago would be very much in scope and should happen. I pretty much avoid using generative AI myself so this is a "proposing someone else should do this," but here goes.- We should identify anywhere between half a dozen and 100 different reasonably specific things that a reasonable person might ask AI to generate, e.g. "a photorealistic depiction of New York's Times Square in 1965," "a photorealistic depiction of a macaque," "an anime-style representation of Oliver Twist," "a watercolor of a European dragon," "a 32-bar musical passage in the style of Beethoven." These could be more specific if that works better. Then roughly every three months, or when a particular engine puts out a new release, we would give these same queries to a number of currently available AI engines and upload both their initial creations and what possibly better result a human can get by tweaking in dialog with the AI, with that dialog being part of the documentation. Over time, I imagine we would develop a very good history of the evolution of this technology. I would think that should certainly be in scope, and much more useful than the haphazard stabs people have taken at this sort of thing.
- This is an example of what would be precluded by the proposal here, and I imagine that is not the only thing that would be worth doing that would involve using AI. - Jmabel ! talk 03:41, 1 March 2026 (UTC)
- @Jmabel: doesn't the current framework of policies and guidelines already see for that some AI generated media are permitted on Commons in any case, even under the assumption that in the future, new additions are unwanted on SCOPE reasons? Namely, I'm thinking along the lines of COM:IAR and COM:PORN. And isn't there a wording in law texts that is only slightly more permitting than a direct and strict prohibition, something like a "shall not" vs. a "must not"?
- So, we could say that AI generated media are generally unwanted / not allowed / out of scope (similar to the rule for new uploads in PORN) but with a comparable small circumventing exception, which would allow only evidently good material actually enhancing our collections, using such a "shall-based" wording.
- Your example of an upload series with an actual "storyboard" and a well-thought concept would and should be permitted in any case as it it designed and shows for providing actual technological knowledge, and not by a small amount (barring developments in court decisions which could outlaw AI for our purposes).
- I'm not fundamentally opposed to an AI tool usage. In fact, in my family, we have already used AI generated imagery several times to enhance me son's homework to good effects (and the Microsoft Image Generator that we used is also good for laughs when it e.g. blocks a totally inconspicuous German prompt containing the word "Wolfsrudel", "wulf pack", I think because of Nazi associations - replacing it with "mehrere Wölfe", "several wolves", and leaving the remainder unchanged made the prompt work). But I wouldn't never think about using these tools to produce media for Commons, in my opinion, they simply don't fit with our aims, besides a few limited exceptions. Regards, Grand-Duc (talk) 05:31, 1 March 2026 (UTC)
- I don't see where the proposal offers any leeway here. COM:PORN doesn't really say anything about limiting porn: "Low-quality images of x that do not contribute anything educationally useful to our existing collection of images are not needed on Wikimedia Commons." is true for any value of x.--Prosfilaes (talk) 05:46, 1 March 2026 (UTC)
- (cross-posted) @Grand-Duc: unless I am misreading, and I do not think I am, Dronebogus's proposal here would absolutely bar what I am suggesting, so I am opposing the proposal. In terms of allowance for this sort of thing
It is the only example of the output of a particular piece of software (for example, Sora or Grok) or type of output (for example, music or video)
is much narrower than what I am suggesting here. - As I've said before, at least at the current state of generative AI I'm pretty skeptical about the use of AI imagery to illustrate anything other than the topic of AI imagery, but Dronebogus's proposal seems possibly even a bit narrow for illustrating AI imagery in Wikipedia. Do we really mean to say that we can have no pool of illustrations of what can be done with a given AI tool beyond what is already in use in existing articles, not even something that illustrates a capability that might not otherwise be obvious? And is this going to be the one area in which Commons has no virtually no interest in content of historical interest (the history of the development of generative AI)? Because that would seem to be a consequence of adopting this proposal as it stands. - Jmabel ! talk 05:53, 1 March 2026 (UTC)
- @Jmabel: You are looking for unreasonable reasons to oppose a reasonable proposal. If someone actually did whatever you’re proposing they would presumably put it in an article, no? Then it would be COM:INUSE and not a violation. Dronebogus (talk) 05:54, 1 March 2026 (UTC)
- @Dronebogus: No, they would not (mostly) be put in an article. I can't think of anywhere that files on Commons that amount to a large data set are all put in an article somewhere else. A good example of this (not AI-related) that I'm (slowly) curating at the moment is Category:Images from the Prosch Albums, an early 20th-century collection of mostly 19th-century photographs, mainly of Seattle, with comments by Thomas Prosch. Most of these will never make it into an article, partly because for many of them if we wanted just the photographic image (not his hand-written notes), we have a better print elsewhere. If you want, I could provide numerous other examples of content we absolutely should have on Commons that is never likely to find its way into any of our "sister projects." - Jmabel ! talk 05:45, 2 March 2026 (UTC)
- I think an exception for illustrating AI even if not INUSE could be added to the guidelines, but I’m not sure how to word it. I want Commons to be able to provide illustrations on the topic of AI art, but I don’t want AI art to be used outside of AI related topics. The purpose of this proposal is to try to stop the latter before it happens while acknowledging and working around the necessity of the former. Dronebogus (talk) 05:58, 2 March 2026 (UTC)
- @Dronebogus: we can limit how AI-generated content on Commons is categorized, but we cannot limit how other projects use our content. - Jmabel ! talk 18:52, 2 March 2026 (UTC)
- They won’t use AI if we don’t host it. Dronebogus (talk) 00:30, 3 March 2026 (UTC)
- @Dronebogus: we can limit how AI-generated content on Commons is categorized, but we cannot limit how other projects use our content. - Jmabel ! talk 18:52, 2 March 2026 (UTC)
- I think an exception for illustrating AI even if not INUSE could be added to the guidelines, but I’m not sure how to word it. I want Commons to be able to provide illustrations on the topic of AI art, but I don’t want AI art to be used outside of AI related topics. The purpose of this proposal is to try to stop the latter before it happens while acknowledging and working around the necessity of the former. Dronebogus (talk) 05:58, 2 March 2026 (UTC)
- @Dronebogus: No, they would not (mostly) be put in an article. I can't think of anywhere that files on Commons that amount to a large data set are all put in an article somewhere else. A good example of this (not AI-related) that I'm (slowly) curating at the moment is Category:Images from the Prosch Albums, an early 20th-century collection of mostly 19th-century photographs, mainly of Seattle, with comments by Thomas Prosch. Most of these will never make it into an article, partly because for many of them if we wanted just the photographic image (not his hand-written notes), we have a better print elsewhere. If you want, I could provide numerous other examples of content we absolutely should have on Commons that is never likely to find its way into any of our "sister projects." - Jmabel ! talk 05:45, 2 March 2026 (UTC)
Oppose "It is the only example of the output of a particular piece of software" feels absolutely putative. There is basically no case, besides a unique 2D piece of artwork, where two examples isn't better than one. As Jmabel says, chronologically and by subject are valuable views into how a generative AI produces files. We shouldn't demand that one file an old version of Grok got hilariously wrong is the only image we'll store here.--Prosfilaes (talk) 05:46, 1 March 2026 (UTC)
- @Prosfilaes: the “only one example” clause could be amended to include versions of a piece of software— i.e. baz by Grok 1.0.jpg is not incompatible with baz by Grok 1.7.jpg Dronebogus (talk) 06:06, 2 March 2026 (UTC)
Oppose I didn't understand item 3 in requirement. Please rephrase it. Gryllida (talk) 07:37, 1 March 2026 (UTC)
- I don’t know what doesn’t make sense. It states that one potential rationale for keeping an AI-generated or modified file would be that no other files exist demonstrating the output of the software used to generate it, and/or there are no other AI files of the same media type (ex. Audio or video). For example, if baz.jpg was the only file generated by foo.AI, or baz.mp4 was the only AI video on Commons, then it would be in scope because no other examples or foo.AI outputs were available on Commons or no other examples of AI videos were on commons. Dronebogus (talk) 20:29, 1 March 2026 (UTC)
Oppose No need for this censorship of a production method and tool increasingly common throughout society. No right to force the bias or opinions of a few as repressive restrictions onto all, instead of looking at the case(s) at hand via standard procedures and existing policies. Prototyperspective (talk) 21:19, 1 March 2026 (UTC)
- No need for this imposition of non-human-created slop on a project that features human-created human-curated works that provide an educational resource increasingly common throughout society. No right to force the pro-AI POV, bias, or opinions of one AI advocate to open the floodgates to all AI advocates. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:10, 1 March 2026 (UTC)
- No need to use the files if you don't like them. And it's not pro-AI POV bias, I just don't wish for this novel increasingly common production method to be censored indiscriminately. And floodgates is a false description. You could start working on the actual flood of 92,000 files Category:All media needing categories as of 2021 instead of forcing your censor-things-I-don't-like attitude onto others when there is no genuine problem so far or flood at all. Prototyperspective (talk) 22:15, 1 March 2026 (UTC)
- The flood is already here; Category:AI-generation related deletion requests is just what we've been able to catch since 2022-12-03. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:48, 1 March 2026 (UTC)
- If you look at how many AI files are on Commons overall, that's a tiny percentage and low fraction...e.g. much fewer than the uncategorized files of just one year or various kinds of useless photos, such as blurry photos or mundane photos of nothing in particular showing things there's thousands of photos of already etc. Moreover, the policy proposed here would rather increase rather than reduce the amount of work and for no reason. At least it wouldn't really help with this and low quality files by noncontributors can already even be speedy deleted. There's also lots of low-quality drawings and logos, yet drawings and logos aren't all banned. Prototyperspective (talk) 10:32, 2 March 2026 (UTC)
- @Prototyperspective: So let's just ban all AI-generated content - less work, much brighter line. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 19:15, 2 March 2026 (UTC)
- Goes back to what I said there. Also people don't need to make these DRs and spend any time on them, I understand that you do not recognize any usefulness of any media produced in this way (basically called a bias) but it doesn't mean it doesn't exist, and third we'd get far more uploads with it not being declared & labelled as made using AI so it could just as well be more work. Fourth, we don't ban lots of other things with more DRs or where the fraction of useful files is low such as Category:MobileUpload-related deletion requests, Category:Nudity and sexuality-related deletion requests, etc. Things can already be easily deleted and often speedily so. Why should we ban a notable organization's logo just because it's made in a low-budget method that uses novel tools for example? But let's not continue this discussion. Prototyperspective (talk) 22:15, 2 March 2026 (UTC)
- @Prototyperspective: So let's just ban all AI-generated content - less work, much brighter line. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 19:15, 2 March 2026 (UTC)
- If you look at how many AI files are on Commons overall, that's a tiny percentage and low fraction...e.g. much fewer than the uncategorized files of just one year or various kinds of useless photos, such as blurry photos or mundane photos of nothing in particular showing things there's thousands of photos of already etc. Moreover, the policy proposed here would rather increase rather than reduce the amount of work and for no reason. At least it wouldn't really help with this and low quality files by noncontributors can already even be speedy deleted. There's also lots of low-quality drawings and logos, yet drawings and logos aren't all banned. Prototyperspective (talk) 10:32, 2 March 2026 (UTC)
- The flood is already here; Category:AI-generation related deletion requests is just what we've been able to catch since 2022-12-03. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:48, 1 March 2026 (UTC)
- No need to use the files if you don't like them. And it's not pro-AI POV bias, I just don't wish for this novel increasingly common production method to be censored indiscriminately. And floodgates is a false description. You could start working on the actual flood of 92,000 files Category:All media needing categories as of 2021 instead of forcing your censor-things-I-don't-like attitude onto others when there is no genuine problem so far or flood at all. Prototyperspective (talk) 22:15, 1 March 2026 (UTC)
- No need for this imposition of non-human-created slop on a project that features human-created human-curated works that provide an educational resource increasingly common throughout society. No right to force the pro-AI POV, bias, or opinions of one AI advocate to open the floodgates to all AI advocates. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:10, 1 March 2026 (UTC)
Comment - at the present time, the biggest issue I'm seeing with AI-generated content is users "retouching" photos using ChatGPT, Gemini, Apple Photos Cleanup, or other similar AI tools before uploading them to Commons. What's most in need of change right now is the user messaging around this issue, not policy - something as simple as "if you're going to upload an AI image, please upload the original first, and don't upload AI images of people" would be a huge help. Omphalographer (talk) 03:20, 4 March 2026 (UTC)
- +1 - Jmabel ! talk 03:23, 4 March 2026 (UTC)
- Maybe if this doesn’t pass we just ban AI enhancement? Dronebogus (talk) 11:12, 4 March 2026 (UTC)
- The problem is not editing with AI tools itself. The problem is how people do this. Removing a lens flare or dirt on the sensor with an AI tool in Photoshop or CaptureOne is fine. Uploading a photo to ChatGPT for the same purpose is not, as ChatGPT might change anything and not just what you wanted to be changed. GPSLeo (talk) 18:37, 4 March 2026 (UTC)
- I agree with GPSLeo. There are already a fair number of good, specialized, AI-based graphics tools, but the attempts at general-purpose tools have largely shown that it is relatively easy to build an artificial bullshit artist, and much harder to (at least for now) to build an artificial expert. - Jmabel ! talk 21:42, 4 March 2026 (UTC)
- @Jmabel: I still remember bullshit artist en:User:Bad article creation bot. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:11, 4 March 2026 (UTC)
- Maybe then, if it’s not already mandatory, make it required to upload the original alongside the retouched version and disallow overwriting a non-AI modified image with an AI modified one. Any AI retouched image without the original available should be speedy deleted. Dronebogus (talk) 04:43, 5 March 2026 (UTC)
- Uploading the original for every file only because someone routinely runs a dust spot removal over all files seems to be completely exaggerated. Such a rule would be hard to fit with the workflow of most photographers. GPSLeo (talk) 05:27, 5 March 2026 (UTC)
- We could work out a common-sense exception for trusted users who upload professional grade photography and provide detailed specifications on their hardware (i.e. cameras) and software (i.e. what AI tool they used and how). I think 99% of cases where it’s even evident AI has been used are your average joe shmoe single-upload user putting a grainy 100px historical image through slop.ai to make it 200% more betterer and inadvertently adding Bigfoot into the image. Dronebogus (talk) 06:31, 5 March 2026 (UTC)
Uploading the original for every file only
one could require them to upload the untouched original as the first version and only upload modified ones as new revisions of the file. In the file history section users can then still see the other version(s). Prototyperspective (talk) 11:56, 5 March 2026 (UTC)workflow of most photographers
: still, all things being equal, barring copyright or personality rights issues, it is certainly best practice for documentary photography to make your original photo, straight from the camera, available (and, typically, overwrite that with the preferred version). I'll admit I'm not 100% on doing that myself, but I'm close. And that is entirely independent of AI-driven tools, which I don't use. Typical examples: File:Nicolae Tonitza - Portretul lui Gala Galaction (Omul unei lumi noi) (1919-1920).jpg, File:Ithaca, NY - W State Street, looking west from S Cayuga Street.jpg. I would not require this, but it certainly can be a lot clearer than a verbal description of retouching. - Jmabel ! talk 00:02, 6 March 2026 (UTC)
required to upload the original
: that would completely eliminate anything from third parties. - Jmabel ! talk 23:49, 5 March 2026 (UTC)- I was referring to those uploads where the original is by the user who uploads or the user has access to it. If the unedited original is not available to them because only the modified version was posted online that obviously makes it sth that can't be expected from them. Users that forgot doing so could be asked to upload it as a new revision and then revert the revision. Prototyperspective (talk) 11:25, 6 March 2026 (UTC)
- Uploading the original for every file only because someone routinely runs a dust spot removal over all files seems to be completely exaggerated. Such a rule would be hard to fit with the workflow of most photographers. GPSLeo (talk) 05:27, 5 March 2026 (UTC)
and much harder to (at least for now) to build an artificial expert
that's the wrong way to use these tools – they are not there for any of the expertise, the expertise should be about 100% in the human who uses these tools in often sophisticated ways, not in the tool. Prototyperspective (talk) 11:54, 5 March 2026 (UTC)
- From what I've seen some users say in response to DRs, part of the problem is that many consumer AI tools (including, but not limited to, ChatGPT) simply don't behave predictably when processing images. Sometimes they'll do an acceptable job of retouching an image - e.g. removing dust and scratches, colorizing black and white photos, adjusting levels and contrast - and sometimes they'll go off the rails and completely recreate an image from "memory", introducing changes in the content of the image. It's not clear what controls how these tools will behave, or if it's even possible to reliably control them. And unless we can give users specific, reliable advice on how to use these tools responsibly, the safest option will be to advise against using them. Omphalographer (talk) 22:13, 4 March 2026 (UTC)
- As an example: the uploader of File:201A Tube characteristics.png used a "text recognition" feature in (Microsoft) "Word with Copilot" which replaced all the labels in the chart with nonsense. (Worse: it wasn't even the usual unreadable text - most of it was contextually appropriate nonsense, making the problem harder to notice.) The original has been uploaded now, but you can compare to the modified version in file history. Omphalographer (talk) 03:19, 5 March 2026 (UTC)
Removing a lens flare or dirt on the sensor with an AI tool in Photoshop or CaptureOne is fine. Uploading a photo to ChatGPT for the same purpose is not, as ChatGPT might change anything and not just what you wanted to be changed
this comes from inexperience with these tools – valid point in principle but there are now tools where you can select the part of the image to change and describe how so it does the same as those other tools, just much easier, low-budget, quicker and often better. Prototyperspective (talk) 11:55, 5 March 2026 (UTC)
- I agree with GPSLeo. There are already a fair number of good, specialized, AI-based graphics tools, but the attempts at general-purpose tools have largely shown that it is relatively easy to build an artificial bullshit artist, and much harder to (at least for now) to build an artificial expert. - Jmabel ! talk 21:42, 4 March 2026 (UTC)
- The problem is not editing with AI tools itself. The problem is how people do this. Removing a lens flare or dirt on the sensor with an AI tool in Photoshop or CaptureOne is fine. Uploading a photo to ChatGPT for the same purpose is not, as ChatGPT might change anything and not just what you wanted to be changed. GPSLeo (talk) 18:37, 4 March 2026 (UTC)
Oppose I think we're doing ok with the slow accretion of guidelines and best practices regarding AI. This seems like far enough to be a non-starter. It is currently being used
kind of doesn't make sense without an additional exception, as nothing is in use at the time of upload, but it must be in scope to be uploaded. — Rhododendrites talk | 14:48, 5 March 2026 (UTC)- I agree the proposal is DOA in its current form, but this discussion has resulted in a lot of constructive criticism I’ll apply to a revised version. I still absolutely believe Wikimedia needs to take a hard line against generative AI (just like crypto and all the other toxic, kleptocrat-driven web 3.0 bullshit being forced down our throats). But we also need to talk about generative AI in an educational context. I want Commons to have a broadly anti-AI policy written down that also accommodates the necessity of hosting AI generated content to illustrate and discuss such content in a way that feels sensible and doesn’t rely on either being extremely vague or extremely specific. Dronebogus (talk) 14:58, 5 March 2026 (UTC)
- Millions of people and lots of countries and their education systems etc think differently. There is no reason to make Commons very biased in one way or the other and exclude lots of content or take a political stance on this. Your view of this novel technology is your opinion. Prototyperspective (talk) 15:05, 5 March 2026 (UTC)
- You are literally the only person I’ve ever encountered passionately defending AI generative garbage who doesn’t appear to have an economic stake in it. The broad consensus of the general online public that actually bothers to voice an opinion is that nearly all generative AI technology and output sucks. I’d say it’s a solution in search of a problem, but that’s too generous. It’s a “solution” to the “problem” of needing humans to produce creative works. And before you say “it gives people who can’t do x a chance to do x”— that’s a feature of being human, not a bug. If you can’t do x you either learn or ask someone else! That’s like the idea behind Wikimedia! Generative AI as it currently stands is directly contrary to this idea of human beings sharing knowledge and skills! Dronebogus (talk) 15:15, 5 March 2026 (UTC)
- That doesn't surprise me – related concepts are 'echo chamber', 'filter bubble', and 'confirmation bias'. And that's not the online consensus at all which is a bad way to assess consensus anyway. Generative AI as it currently stands is directly supportive of the idea of human beings sharing knowledge and skills as more people have access to better idea/concept visualization and more media depictions can finally enter the public domain/creative commons. Prototyperspective (talk) 15:18, 5 March 2026 (UTC)
- (Edit conflict) Well, this opinion is shared by a lot of people. We need to be very cautious about such generalizations. The dominant discourse is pro-AI, but it doesn't mean the majority of people are pro-AI. At the very least, most people I know are very skeptical or critical about AI. I don't know how we should formulate Commons policies about AI, but we should keep an independent and critical view about it. Yann (talk) 15:18, 5 March 2026 (UTC)
- The dominant discourse is pro-AI if by “dominant” you mean “rich and loud”. If you look at social media, comments sections, youtubers, artists, people on this very website, it’s overwhelmingly negative. Dronebogus (talk) 15:21, 5 March 2026 (UTC)
- If I look outside of reddit and Wikipedia, it's nuanced and/or positive. In any case, that's a bad way to gauge the public view; for example there are people stoking up divisions and polarizations, paid commenters, algorithms that drive disagreement and upset, etc etc. It doesn't matter either way what the majority opinion on this is. We don't censor lots of other things that people don't like – people are free to hate these things and not use them.
“rich and loud”
the loud ones are the ones being hyperbolic nonnuanced haters of anything that has anyhow to do with generative AI. Prototyperspective (talk) 15:27, 5 March 2026 (UTC)people stoking up divisions and polarizations
because they are voicing their honest dislike of this technology and what it’s doing to art and culture?paid commenters
Yes, I’m sure there’s big money to be made trashing big tech’s new favorite thing in the whole world, something that basically prints money for free.It doesn't matter either way what the majority opinion on this is
public opinion does actually matter.We don't censor lots of other things that people don't like
I’m not saying we should censor it, but just like how w:wp:gratuitous states we shouldn’t use explicit images to illustrate non-explicit subjects I don’t think we should use AI to illustrate topics unrelated to AI.hyperbolic nonnuanced haters of anything that has anyhow to do with generative AI.
I don’t hate or disapprove of generative AI 100%, if w:Neuro-sama counts as generative AI. And while I don’t exactly like that he used it, ZUN also used AI in the latest Touhou game and took pains to demonstrate how to use it in an ethical manner that doesn’t negate the importance of real, serious human contribution. Dronebogus (talk) 17:11, 5 March 2026 (UTC)- I was giving examples why it's not a good idea to base things on personal subjective impressions of online opinion. There's financial interests for and against various kinds of AI uses and AI uses in general. And if we censored away everything we feel is widely disliked we may be moving to censoring videos of sexual intercourse, homosexuality, fetishes, religious desecration, and political caricatures next. And claiming you are not saying/proposing sth does not make it so. Prototyperspective (talk) 17:59, 5 March 2026 (UTC)
- FWIW, I'm pretty neutral on the long-term potential of generalized AI, but so far we are at a phase similar to when Ambrose Bierce remarked about electricity circa 1890 that so far it had been shown that it could pull a streetcar better than a candle and light a room better than a horse. - Jmabel ! talk 00:10, 6 March 2026 (UTC)
- Yes, I feel the same way. Only it’s worse than just inferior; it’s actively harmful. AI as a concept has potential, but right now it’s being applied fast-and-loose in places it doesn’t need to be applied, or places it could be applied responsibly but isn’t. It’s more like how back in the early-mid 20th century we thought we’d be warming our hands by a lump of radium in the fireplace— yeah, radioactivity is useful, but not like THAT. Thank god no-one started putting radium fireplaces in homes by default like every tech corporation is doing with AI in everything. Dronebogus (talk) 06:07, 6 March 2026 (UTC)
- Okay so how much have you used latest AI? I felt like this about LLMs (because they just parrot things to sound plausible, not accurate) but these aren't LLMs and it's not about how we feel. I doubt you have used them for coding, diagrams, creative ideas you didn't have time for, or specific images you have in mind spending hours to create them. In this area often feels like people have super strong opinions and extensive advise to give but little experience or data underneath it. I'm not saying it's not harmful or that it isn't currently overdone but knee-jerk reactions to e.g. companies scrambling to put AI into everything where it's not needed/wanted/useful or sensationalist media coverage relating to some real issues aren't helping and additionally would further the perception that they're entirely useless and a problem when reality is more nuanced than that. Prototyperspective (talk) 11:34, 6 March 2026 (UTC)
- I was just thinking about how generative AI is like nutrient paste in RimWorld: maybe you don’t care relying on nutrient paste puts talented, passionate chefs out of a job because now everyone can be a “chef” at the push of a button. Maybe you can justify the space wasted by the room-sized dispenser by pointing out a regular stove uses slightly more electricity and is far less efficient in its output. Maybe you think a human cooking a delicious meal is functionally identical to the dispenser grinding up the ingredients into flavorless mush. Maybe you even like nutrient paste and know lots of people who do. But the fact is most people hate eating nutrient paste. They don’t like seeing a freezer stocked with nutrient paste meals. They don’t like biting into their food and finding out it’s actually just paste. They don’t forced out of their cooking jobs they spent years honing and getting replaced by “nutrient paste engineers” (which isn’t a real job in RimWorld just like how “prompt engineer” isn’t a real job IRL). You can start your own colony with a cult of transhumanism that mandates that everyone eat nutrient paste, and attract lots of like-minded nutrient paste eaters to your colony, but most of us at the Wikimedia colony would just like to eat real human food. Dronebogus (talk) 12:07, 6 March 2026 (UTC)
- Why would one eat nutrient paste if the other tastes better.
If one has the option for both in a specific case like say a specific meal occasion (such as a lunch during travel on day xy) I see no reason for why to pick it. Especially when both meals are equivalent or the nutrient paste is better because eg it's healthier and tastes better then why the heck should I be forced to only eat the manmade dish with other options being prohibited? If you think for cases where both are available the latter is intrinsically better due to being manmade/handmade the traditional way then you're free to have this opinion but shouldn't insist on everybody adopting the same view. Btw, the ideas/philosophy has some resemblance to this. Prototyperspective (talk) 12:27, 6 March 2026 (UTC)- That’s the thing: nutrient paste can technically meet your colonists’ raw nutritional requirements, and extremely efficiently too, but it tastes disgusting unless you are an ascetic who doesn’t care about taste or have adopted a pro-nutrient paste ideology. To use a real world example: the w:dilberito, which was basically real life nutrient paste. It was supposed to be the next big thing in food. It (supposedly) provided everything your body needed, but it apparently tasted awful. It was only acceptable fare to people who can eat without concern for taste (and maybe like two people who actually enjoyed it). The point is AI generated content may be able to technically meet the minimum requirements of whatever it’s being used for, but most people think it’s about as palatable as nutrient paste or a diberito. And putting AI in an article or whatever is like putting nutrient paste it in a meal at a restaurant— you can order something else, but if I wanted this meal I have to eat the paste as part of it. Dronebogus (talk) 12:50, 6 March 2026 (UTC)
most people think it’s about as palatable as nutrient paste or a diberito
you think that. I don't. Millions and probably most people don't, in my country I think and it seems to be most people. Regardless of what they think, we shouldn't censor things based on taste. There's country where homosexuality is punished and acceptance of it a minority view. That files are on Commons don't mean they have to be used. It's not technical requirements but holistic all-criteria requirements which is more broad than making some criteria you personally are a fan of about production methodology a critical decisive top criteria. Prototyperspective (talk) 12:54, 6 March 2026 (UTC)millions and probably most people
uh, citation needed. I at least have anecdotal evidence a lot of people do not like AI. I can point out English Wikipedia, the biggest Wikimedia site by far and one of the biggest websites on the planet, has a laundry list of policies, essays, and guidelines on AI that are mostly negative. I could point out the lengthy “concerns” section on the AI boom article, or the existence of w:AI slop as a concept and term. I could point out the extremely negative reaction to uses of AI in the media, like w:It's the Most Terrible Time of the Year, or the backlash against w:Théâtre D'opéra Spatial. You are relying on a silent majority that possibly doesn’t even exist, and comparing hostility towards AI generated content (a new and highly controversial concept/technology) to intolerance of homosexuality (a natural, healthy behavior among humans and animals that nevertheless results in people getting marginalized, hurt, and killed by ignorant individuals and societies). Dronebogus (talk) 13:10, 6 March 2026 (UTC)- I'd say citation needed for your claims. Given that millions use these tools, it's not a stretch or near-self-explanatory. But again it's not about and should not be about what the dominant or >50% majority contemporary opinion on a subject is. I'm sadly well aware that the existence of the term "AI slop" is what many people believe is what can settle debates or a strong point or just slightly convincing. The majority goes about their day and either uses the tools at work or for fun or daily life things and/or doesn't bother about how Wikimedia projects handle this. I'm not "relying" on them because again majority taste and sentiment aren't what matters. Prototyperspective (talk) 13:29, 6 March 2026 (UTC)
- Okay, let’s assume you’re right that, yes, a majority of people like or don’t care about AI. A non trivial minority really does not like it. There is no offense to either camp in using exclusively human made files in the vast majority contexts. However the anti-AI camp is offended by the use of AI and the pro-AI camp’s use of it and subsequent justification of it; both parties come out unsatisfied and hostile toward each other with no real benefit to show for it. So human content is a win for both parties and AI is a lose for both parties. Dronebogus (talk) 13:44, 6 March 2026 (UTC)
- I'd say citation needed for your claims. Given that millions use these tools, it's not a stretch or near-self-explanatory. But again it's not about and should not be about what the dominant or >50% majority contemporary opinion on a subject is. I'm sadly well aware that the existence of the term "AI slop" is what many people believe is what can settle debates or a strong point or just slightly convincing. The majority goes about their day and either uses the tools at work or for fun or daily life things and/or doesn't bother about how Wikimedia projects handle this. I'm not "relying" on them because again majority taste and sentiment aren't what matters. Prototyperspective (talk) 13:29, 6 March 2026 (UTC)
- That’s the thing: nutrient paste can technically meet your colonists’ raw nutritional requirements, and extremely efficiently too, but it tastes disgusting unless you are an ascetic who doesn’t care about taste or have adopted a pro-nutrient paste ideology. To use a real world example: the w:dilberito, which was basically real life nutrient paste. It was supposed to be the next big thing in food. It (supposedly) provided everything your body needed, but it apparently tasted awful. It was only acceptable fare to people who can eat without concern for taste (and maybe like two people who actually enjoyed it). The point is AI generated content may be able to technically meet the minimum requirements of whatever it’s being used for, but most people think it’s about as palatable as nutrient paste or a diberito. And putting AI in an article or whatever is like putting nutrient paste it in a meal at a restaurant— you can order something else, but if I wanted this meal I have to eat the paste as part of it. Dronebogus (talk) 12:50, 6 March 2026 (UTC)
- Why would one eat nutrient paste if the other tastes better.
- I was just thinking about how generative AI is like nutrient paste in RimWorld: maybe you don’t care relying on nutrient paste puts talented, passionate chefs out of a job because now everyone can be a “chef” at the push of a button. Maybe you can justify the space wasted by the room-sized dispenser by pointing out a regular stove uses slightly more electricity and is far less efficient in its output. Maybe you think a human cooking a delicious meal is functionally identical to the dispenser grinding up the ingredients into flavorless mush. Maybe you even like nutrient paste and know lots of people who do. But the fact is most people hate eating nutrient paste. They don’t like seeing a freezer stocked with nutrient paste meals. They don’t like biting into their food and finding out it’s actually just paste. They don’t forced out of their cooking jobs they spent years honing and getting replaced by “nutrient paste engineers” (which isn’t a real job in RimWorld just like how “prompt engineer” isn’t a real job IRL). You can start your own colony with a cult of transhumanism that mandates that everyone eat nutrient paste, and attract lots of like-minded nutrient paste eaters to your colony, but most of us at the Wikimedia colony would just like to eat real human food. Dronebogus (talk) 12:07, 6 March 2026 (UTC)
- FWIW, I'm pretty neutral on the long-term potential of generalized AI, but so far we are at a phase similar to when Ambrose Bierce remarked about electricity circa 1890 that so far it had been shown that it could pull a streetcar better than a candle and light a room better than a horse. - Jmabel ! talk 00:10, 6 March 2026 (UTC)
- I was giving examples why it's not a good idea to base things on personal subjective impressions of online opinion. There's financial interests for and against various kinds of AI uses and AI uses in general. And if we censored away everything we feel is widely disliked we may be moving to censoring videos of sexual intercourse, homosexuality, fetishes, religious desecration, and political caricatures next. And claiming you are not saying/proposing sth does not make it so. Prototyperspective (talk) 17:59, 5 March 2026 (UTC)
- If I look outside of reddit and Wikipedia, it's nuanced and/or positive. In any case, that's a bad way to gauge the public view; for example there are people stoking up divisions and polarizations, paid commenters, algorithms that drive disagreement and upset, etc etc. It doesn't matter either way what the majority opinion on this is. We don't censor lots of other things that people don't like – people are free to hate these things and not use them.
- The dominant discourse is pro-AI if by “dominant” you mean “rich and loud”. If you look at social media, comments sections, youtubers, artists, people on this very website, it’s overwhelmingly negative. Dronebogus (talk) 15:21, 5 March 2026 (UTC)
- (Edit conflict) Well, this opinion is shared by a lot of people. We need to be very cautious about such generalizations. The dominant discourse is pro-AI, but it doesn't mean the majority of people are pro-AI. At the very least, most people I know are very skeptical or critical about AI. I don't know how we should formulate Commons policies about AI, but we should keep an independent and critical view about it. Yann (talk) 15:18, 5 March 2026 (UTC)
- That doesn't surprise me – related concepts are 'echo chamber', 'filter bubble', and 'confirmation bias'. And that's not the online consensus at all which is a bad way to assess consensus anyway. Generative AI as it currently stands is directly supportive of the idea of human beings sharing knowledge and skills as more people have access to better idea/concept visualization and more media depictions can finally enter the public domain/creative commons. Prototyperspective (talk) 15:18, 5 March 2026 (UTC)
- You are literally the only person I’ve ever encountered passionately defending AI generative garbage who doesn’t appear to have an economic stake in it. The broad consensus of the general online public that actually bothers to voice an opinion is that nearly all generative AI technology and output sucks. I’d say it’s a solution in search of a problem, but that’s too generous. It’s a “solution” to the “problem” of needing humans to produce creative works. And before you say “it gives people who can’t do x a chance to do x”— that’s a feature of being human, not a bug. If you can’t do x you either learn or ask someone else! That’s like the idea behind Wikimedia! Generative AI as it currently stands is directly contrary to this idea of human beings sharing knowledge and skills! Dronebogus (talk) 15:15, 5 March 2026 (UTC)
- Millions of people and lots of countries and their education systems etc think differently. There is no reason to make Commons very biased in one way or the other and exclude lots of content or take a political stance on this. Your view of this novel technology is your opinion. Prototyperspective (talk) 15:05, 5 March 2026 (UTC)
- I agree the proposal is DOA in its current form, but this discussion has resulted in a lot of constructive criticism I’ll apply to a revised version. I still absolutely believe Wikimedia needs to take a hard line against generative AI (just like crypto and all the other toxic, kleptocrat-driven web 3.0 bullshit being forced down our throats). But we also need to talk about generative AI in an educational context. I want Commons to have a broadly anti-AI policy written down that also accommodates the necessity of hosting AI generated content to illustrate and discuss such content in a way that feels sensible and doesn’t rely on either being extremely vague or extremely specific. Dronebogus (talk) 14:58, 5 March 2026 (UTC)
In addition to Dronebogus says, with which I totally agree, we cannot say that AI-generated and human generated content are a “free” choice. Because AI use is cheap and easy for the end-user, many people are tempted to use it. But it is neither free or easy for the society in general. This is not a competition on equal terms. Yann (talk) 13:51, 6 March 2026 (UTC)
- It's not a competition to begin with. Computer use is neither free or easy for the society in general. Prototyperspective (talk) 13:59, 6 March 2026 (UTC)
- It gets easier and, measured in money, cheaper every day - to the point were you can just talk to a device and ask it to have media generated along your guidelines. The upload to Wikimedia is just a formality. So, no argument here. Alexpl (talk) 21:52, 6 March 2026 (UTC)
- That is speculation and is currently not true except if quality and accuracy are none of your criteria and/or if it's sth quite simple. I did not make a new 'argument' there but just addressed 2 claims in the prior comment and showed how these are basically false. If it gets easier and cheaper to create good-quality useful visual illustrations for subjects where these would be useful then that's great. Prototyperspective (talk) 22:05, 6 March 2026 (UTC)
- That is the core of your misconception— that AI art is good, even disregarding personal taste. AI art is frequently full of errors and “hallucinations”. Even if accurate it simply doesn’t inspire trust among anyone with critical thinking skills who have seen the utter BS it has spit out in the past. So going back to the nutrient paste analogy, it’s like there being a non-zero chance of the nutrient paste containing toxic waste to make it seem more substantial. A human chef might cook food badly or improperly, resulting in anything from a lousy meal to food poisoning, but they won’t put toxic waste in your food and lie about it meeting your nutritional requirements. Dronebogus (talk) 11:00, 7 March 2026 (UTC)
- I don't want Prototyperspective and his ilk piping in the electronic version of toxic waste. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:08, 7 March 2026 (UTC)
- That is the core of your misconception— that AI art is good, even disregarding personal taste. AI art is frequently full of errors and “hallucinations”. Even if accurate it simply doesn’t inspire trust among anyone with critical thinking skills who have seen the utter BS it has spit out in the past. So going back to the nutrient paste analogy, it’s like there being a non-zero chance of the nutrient paste containing toxic waste to make it seem more substantial. A human chef might cook food badly or improperly, resulting in anything from a lousy meal to food poisoning, but they won’t put toxic waste in your food and lie about it meeting your nutritional requirements. Dronebogus (talk) 11:00, 7 March 2026 (UTC)
- That is speculation and is currently not true except if quality and accuracy are none of your criteria and/or if it's sth quite simple. I did not make a new 'argument' there but just addressed 2 claims in the prior comment and showed how these are basically false. If it gets easier and cheaper to create good-quality useful visual illustrations for subjects where these would be useful then that's great. Prototyperspective (talk) 22:05, 6 March 2026 (UTC)
- It gets easier and, measured in money, cheaper every day - to the point were you can just talk to a device and ask it to have media generated along your guidelines. The upload to Wikimedia is just a formality. So, no argument here. Alexpl (talk) 21:52, 6 March 2026 (UTC)
- For the venue of a revised proposal mentioned above (14:58, 5 March 2026 (UTC)), I would encourage making a global RFC page. With the right timing and preparation, you can use m:CentralNotice, too. I think a broad restriction (or acceptance) of AI-generate media is a wider issue than just Commons. Of course, Commons editors can be invited to comment on it. I'm happy to help drafting an RFC like that. whym (talk) 09:32, 10 March 2026 (UTC)
Oppose - I disagree with attempts by Commons to dictate scope over other projects, i.e. weakening COM:INUSE. That discussion needs to happen with the projects, either at individual project level (as is happening already, e.g. Germany) or with a global RFC as suggested above. To me this is very different than the legitimate non-scope restrictions that are imposed on other projects such as copyright and dignity (which was recently boosted for AI with COM:AIP). -Consigned (talk) 21:50, 21 March 2026 (UTC)
FYI: there is a similar AI/Scope related proposal at Commons talk:Project scope#Proposed change: excluding images do not comply with COM:AIP from COM:INUSE rules. -Consigned (talk) 22:04, 21 March 2026 (UTC)
Oppose Completely arbitrary ban and an blatant example of American culture war nonsense being enforced on Commons--Trade (talk) 02:40, 24 March 2026 (UTC)
- This isn’t “American culture war nonsense”. Anti-AI backlash isn’t limited to the United States, and wouldn’t be wrong even if it was. “If in doubt, blame the Americans” isn’t a good argument and is quite frankly xenophobic and offensive. Dronebogus (talk) 12:58, 24 March 2026 (UTC)
- It's not nearly as large in other countries and virtually nonexistent in many countries. And there are studies/reports that the polarization on this and concerns about gen AI are remarkably large in the U.S. Prototyperspective (talk) 13:01, 24 March 2026 (UTC)
- The US has a population of over 340 million, the most populous in the core anglosphere and the third most populous in the world. The opinions of 4% of the world’s population are not nothing. Dronebogus (talk) 13:07, 24 March 2026 (UTC)
- Sure. Nobody said it's nothing. Prototyperspective (talk) 13:17, 24 March 2026 (UTC)
- The US has a population of over 340 million, the most populous in the core anglosphere and the third most populous in the world. The opinions of 4% of the world’s population are not nothing. Dronebogus (talk) 13:07, 24 March 2026 (UTC)
- It's not nearly as large in other countries and virtually nonexistent in many countries. And there are studies/reports that the polarization on this and concerns about gen AI are remarkably large in the U.S. Prototyperspective (talk) 13:01, 24 March 2026 (UTC)
- This isn’t “American culture war nonsense”. Anti-AI backlash isn’t limited to the United States, and wouldn’t be wrong even if it was. “If in doubt, blame the Americans” isn’t a good argument and is quite frankly xenophobic and offensive. Dronebogus (talk) 12:58, 24 March 2026 (UTC)
Legitimacy of usages
I had a look at the files currently nominated for deletion. I think the main problem are files, they are clearly out of scope, but are used on some small wiki. Many of these wikis seem to lack a proper patrolling system to detect these problematic edits. If there is no solution for better patrolling processes on these small wikis, we have to discuss (globally) that we can apply our in use policy only to larger wikis, to protect our project. GPSLeo (talk) 18:57, 25 March 2026 (UTC)
- Yes, I think there should be a global AI cleanup project on meta. That’s why I’ve been cataloging every “in use” file on a userpage by its relative legitimacy of use. Dronebogus (talk) 19:11, 25 March 2026 (UTC)
- 1. The currently nominated files are not a fair representation of such files – Dronebogus seems to have selected lots of files where there is some use but the image is of fairly low quality so one agree on the immediate particular file 2. however, it's important to still see beyond agreeable individual cases and look at principles; COM:INUSE is an important policy. No need to waste people's time on a tiny number of files that don't cause any issues either; the bigger issue is the controversy/polarizations/inconsistencies and time-wasting than having a few bad files here with 1 pageview per month.
- .
- If one wanted to undermine some policy all what one would need to do is make agreeable individual cases. Then one can undo policy. There are lots of illustrations of this in the real world when it comes to state laws and policies. I don't think anybody is trying that here but the effect remains the same – it's very important to separate between agreeable cases and principles. It's important to safeguard principles and keep things consistent. .
- There is zero problem with having a small handful you think are totally useless and of bad quality and not deleting them because they're used. There are over 70,000 files in Category:All media needing categories as of 2023, lots of which blurry or useless diagrams of chaotic shapes or whatever and this also goes for files in categories. There is no real problem; most of the files currently nominated are going to get deleted and 80% of those are among the worst-quality AI files. No need to panic and throw policies, principles, neutrality, community-decision-making and caution overboard for basically nothing and with no need. INUSE also applies to smaller projects and a thoughtful approach would be things like better engaging with people on those projects as I've suggested several times such as pinging authors of those articles or even in some case where the image is for example a hoax (not just AI images btw) or extremely low quality, removing the file right away and waiting some time afterwards before deletion. Again, people drop & perforate policies and principles so easily – I don't even want to think about where the project will be in say 3 decades at this rate. And additionally, people misunderstand that the issue of AI images is not special – there are millions of people with views other than yours and not all of these nominated files that are in use were better not used. Understand that in matters of contention, there are multiple sides, each with potentially valid points or views, not just yours even if you have a very strong opinion.
- Basically, there is no need for and no net benefit in undermining the principle of COM:INUSE – or the foundations of any other principle – just to delete a few objected-to low-quality files among the millions. There are easier ways that don't require that, even removing the uses.
- Prototyperspective (talk) 19:59, 25 March 2026 (UTC)
- @GPSLeo, Dronebogus and to whom it may concern: I wrote down some thoughts in meta:User:Grand-Duc/RfC draft generative AI media. Regards, Grand-Duc (talk) 20:14, 25 March 2026 (UTC)
Support. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:19, 26 March 2026 (UTC)
Proposal: Allow file movers to delete single-revision redirects during file moves
8 support, 0 oppose, consensus for giving the delete-redirect right to filemovers. Phabricator ticket Add "delete-redirect" right to filemovers on Wikimedia Commons has been opened. Regards, ZI Jony (Talk) 13:11, 26 March 2026 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I would like to propose adding the delete-redirect right to the file mover user group on Wikimedia Commons. This would allow file movers to delete single-revision redirects when they block a file move.
Background
On Wikimedia Commons, file renaming is performed by users with the file mover or sysop right. However, when the destination title already exists as a redirect, the move can fail even if that redirect is trivial.
In such situations, file movers must request administrator assistance to delete the redirect and complete the move. In many cases, these redirects are:
- created automatically by previous file moves
- redirects with only one revision
- redirects with no meaningful history or content
Despite being technically trivial, these situations require administrator intervention, which creates unnecessary delays and additional administrative work.
Existing precedent
Similar issues have been discussed in the context of page moves on other Wikimedia projects. MediaWiki development work has recognized that single-revision redirects generally have no meaningful history and can safely be removed when they block a move operation.
The purpose of the delete-redirect capability is not to grant general deletion powers, but to allow the system to remove trivial redirects automatically during a move action.
Proposed change
Grant the delete-redirect user right to the file mover group on Wikimedia Commons.
In practice, this would allow file movers to delete redirects only when all of the following conditions are met:
- The file is a redirect.
- The redirect has only one revision.
- The deletion occurs as part of a file move operation.
- The redirect would otherwise block the move.
This would not grant file movers general file/page deletion rights.
Benefits
This change would:
- reduce routine administrator workload
- speed up routine file renaming
- eliminate many trivial admin requests
- make the file mover workflow more efficient
Commons contains millions of files and frequent renaming requests. Allowing file movers to resolve these minor redirect conflicts directly would streamline maintenance without introducing meaningful risk.
Safeguards
The proposal is intentionally limited:
- Only single-revision redirects can be removed.
- The deletion occurs only within the move process.
- File movers would not gain general deletion rights.
Request
I would like to gather community feedback on whether the file mover group should be granted the delete-redirect right for this limited purpose.
If there is consensus, a configuration change could be requested via Phabricator. Regards, ZI Jony (Talk) 08:44, 5 March 2026 (UTC)
Comments
- Just a few questions:
- Which problem would be solved? Unlike articles on WP file names can be / are trivial on Commons. There may exist a zillion files of a woodpecker, differing by a number, situation, action of the bird, etc. If renaming is blocked, one could add a number to the file name.
- Can this have disadvantages? Such as wheelwarring about a filename? Regards, Ellywa (talk) 11:32, 7 March 2026 (UTC)
- Ellywa, thanks for raising these points.
- I agree that this situation is probably not very common, and the proposal is not meant to solve a large systemic problem. It is more about handling those occasional cases where a technically trivial redirect blocks a move and requires unnecessary admin intervention.
- For example, in the current request to rename File:2020 New Jersey Question 1 results by county.svg to File:2020 New Jersey Question 1 results map by county.svg, the destination title already exists as a redirect pointing back to the original file. Even though this redirect has no meaningful history, the move cannot proceed unless an administrator deletes it first, or the administrator does so themselves.
- This is exactly the kind of situation the proposal tries to address. The redirect is simply a leftover technical artifact, but resolving it still requires admin involvement.
- Of course, a file mover could choose a slightly different name instead, but in cases where the requested title is the most accurate or natural one, it would be helpful if trivial single-revision redirects like this could be removed as part of the move process.
- So while the case may be rare, the idea is to make these small maintenance tasks smoother and reduce minor admin requests when the redirect involved has no real content or history. Regards, ZI Jony (Talk) 06:51, 8 March 2026 (UTC)
- A filemover could move the redirect itself to an intermediate name (without leaving another redirect), then move the original file (again without leaving a redirect), then move the intermediate name redirect to the original source name of the move, changing it to point to the new name. Certainly, being able to delete that redirect then do an normal move is easier, and maybe leaves a better history, so if the safeguards can be implemented to not delete redirects with history (I have little idea about that) it's probably fine. But seems to me like it's still possible to avoid involving admins even now. Carl Lindberg (talk) 19:40, 8 March 2026 (UTC)
- Carl Lindberg, thank you for explaining that workaround. You are correct that it is technically possible to complete the move without admin involvement by moving the redirect to an intermediate title and then performing a sequence of moves. However, in practice that approach has a few drawbacks.
- First, it requires several additional steps compared to a normal move. Instead of one straightforward move, the file mover has to perform multiple moves and carefully manage redirects in between. For routine file renaming work this quickly becomes cumbersome.
- Second, it can make the page history less clear. Multiple intermediate moves may create a more complicated history that is harder to follow later, whereas deleting a trivial single-revision redirect and performing a normal move keeps the history cleaner and easier to understand.
- Third, while the workaround avoids direct admin involvement at that moment, it still creates extra maintenance work overall. File movers need to spend additional time performing the workaround, and sometimes the intermediate redirects created during the process may later require cleanup anyway.
- The intention of this proposal is simply to allow file movers to resolve these very limited situations in a straightforward way when the blocking redirect has only a single revision and no meaningful history. It would not grant general deletion rights, but would remove the need for workarounds or small admin requests in these cases.
- So while the workaround exists, the proposal aims to make the workflow simpler and cleaner for those occasional cases where a trivial redirect blocks a file move. Regards, ZI Jony (Talk) 13:11, 9 March 2026 (UTC)
- Can the software even detect (at the relevant time) that there is a single-revision redirect and allow a user who does not normally have deletion rights to make a deletion? If this requires a non-trivial software change by a WMF engineer, that would seem to me to be wildly out of proportion to any benefit here, especially given how little resource WMF is devoting to support for Commons overall. - Jmabel ! talk 20:59, 9 March 2026 (UTC)
- @Jmabel: I know for sure, from my DE-WP experience, that you could for years overwrite a redirect page that only consist of a single revision when doing a page move. Look at this recent example from a few minutes ago. So, any needed code is extant, I think. Regards, Grand-Duc (talk) 21:11, 9 March 2026 (UTC)
- Jmabel, As far as I understand, this would not require any new or complex software development. MediaWiki already has logic to detect when the target page of a move is a redirect and how many revisions it has. The proposal is simply about allowing the existing
delete-redirectcapability to be used by the file mover group during a move operation. - In other words, the software already checks the revision count of redirects when handling moves. The idea here is that if the redirect has only one revision and it blocks the move, the system could allow the redirect to be removed automatically as part of the move action. If the redirect has more than one revision, then the normal process would still apply, and an administrator would be required to delete it.
- So the scope is intentionally very narrow: it would only work during a move action and only for single-revision redirects. It would not grant general deletion rights.
- For related background and technical discussion, see T239277. Regards, ZI Jony (Talk) 10:15, 10 March 2026 (UTC)
- Jmabel, As far as I understand, this would not require any new or complex software development. MediaWiki already has logic to detect when the target page of a move is a redirect and how many revisions it has. The proposal is simply about allowing the existing
- @Jmabel: I know for sure, from my DE-WP experience, that you could for years overwrite a redirect page that only consist of a single revision when doing a page move. Look at this recent example from a few minutes ago. So, any needed code is extant, I think. Regards, Grand-Duc (talk) 21:11, 9 March 2026 (UTC)
- Ellywa, Jmabel, and Carl Lindberg: would you like to give your opinions? Regards, ZI Jony (Talk) 00:30, 16 March 2026 (UTC)
- As long is it isn't a big resource ask (and it seems it isn't), I don't care a lot. I just hope that anyone who starts deleting stuff actually knows what they are doing. I wouldn't give a lot of slack to someone who did this and deleted redirects that should have been kept. - Jmabel ! talk 02:12, 16 March 2026 (UTC)
- My question about wheelwarring around a file name has not been answered. Currently there are 1,754 filemovers. If a few of them start warring it will result in more workload for the admins than doing some handwork for renaming. There is no way how we can be certain that all these people will stick to the rules about renaming. Perhaps filemovers who need more possibilities can apply for adminship. Ellywa (talk) 07:39, 16 March 2026 (UTC)
- If a few of them start warring they will lose their filemover privileges. Period. - Jmabel ! talk 17:31, 16 March 2026 (UTC)
- Thanks Jmabel, that’s a fair point, and I agree. The intention here is to keep this limited to very clear-cut cases, so it stays low-risk and doesn’t create extra work. Regards, ZI Jony (Talk) 09:27, 17 March 2026 (UTC)
- Ellywa, thanks for following up. Let me address the wheel-warring concern directly. This proposal is limited to single-revision redirects with no meaningful history, which are typically just technical leftovers from earlier moves/creation. In that sense, it does not expand the scope of *what* can be contested in naming, only removes a technical step (admin deletion) in cases where the redirect itself has no substantive value. If filemovers were to start warring over filenames, that would already be an issue under current practice, regardless of this change. This proposal does not introduce a new type of conflict, but only changes how a trivial redirect is handled during a move. As with other filemover actions, expectations around appropriate use remain the same, and misuse (including repeated or contested moves) can already lead to the removal of the permission. So the safeguard here is behavioural enforcement, which already exists today. In short, the proposal reduces a small amount of technical friction, but does not change the underlying rules or increase the scope for disputes. Regards, ZI Jony (Talk) 09:27, 17 March 2026 (UTC)
- If a few of them start warring they will lose their filemover privileges. Period. - Jmabel ! talk 17:31, 16 March 2026 (UTC)
- My question about wheelwarring around a file name has not been answered. Currently there are 1,754 filemovers. If a few of them start warring it will result in more workload for the admins than doing some handwork for renaming. There is no way how we can be certain that all these people will stick to the rules about renaming. Perhaps filemovers who need more possibilities can apply for adminship. Ellywa (talk) 07:39, 16 March 2026 (UTC)
- As long is it isn't a big resource ask (and it seems it isn't), I don't care a lot. I just hope that anyone who starts deleting stuff actually knows what they are doing. I wouldn't give a lot of slack to someone who did this and deleted redirects that should have been kept. - Jmabel ! talk 02:12, 16 March 2026 (UTC)
Support
Support Schlurcher (talk) 08:17, 8 March 2026 (UTC)
Support with the proposed safeguards. Tvpuppy (talk) 11:55, 8 March 2026 (UTC)
Support. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:59, 8 March 2026 (UTC)
Support. Rehman 15:43, 8 March 2026 (UTC)
Support --Wolfy13399 (talk) 14:54, 11 March 2026 (UTC)
Support HurricaneZetaC 21:15, 11 March 2026 (UTC)
Support Shaan SenguptaTalk 03:07, 12 March 2026 (UTC)
Support, I'm already used to this feature from DE-WP. It's hardly ever source for problems AFAIK, and I'm willing to support changes that better the processes surrounding filemoves (especially when speaking about redirects left after a COM:FR#FR3 "erroneous filename" move, like wrong species names in biology). Grand-Duc (talk) 11:57, 17 March 2026 (UTC)
Oppose
- --
Neutral
- --
- The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Feature Request: Revert back to the original vector 2010 design.
The new layout is horible. I understand that it came out around late 2022 for new users to read better using the website, but lets face it, it came out during a mass pandemic back when everyone was stuck inside and DEPRESSED. Also most people still have family computers (including my family) so if the redesign is related in responce to everyone trying to access wikipedia from their iphones there's an APP for that. Also the entire point of the website is for education, right? So the new design actually defeats the point of using the website to begin with. The 2022 layout actually removes side links and those fold out bars on the bottom of wikipedia pages so that you can't learn more about a topic, which prevents you from learning more something, and redesigning it would not only look horible but given the current design might not even be possible. Plus more people have started going back to the original color design by repainting their homes, so why should wikipedia be any different?
Plus, changing the current design to the vector 2010 skin would be extremly easy and wouldn't require that much effort.
If you want to support this arguement, do this: Download the old wiki or old wiki redirect extension on either google chrome or mozilla firefox.
See what layout you find better, the original one with the quick links on the side and the information tabs at the bottom of the website, or the current design.
Ok let me make a point about a few arguements I might get.
"You're just resistant to change"
Depending on where you live, you may have noticed other people repainting their houses with the color design for the same reason, because they couldn't deal with the grey modern design that just looks horrible.
Also there's a psychologcal effect of the more minimalist designs, and even if the claim is that the design helps new users read because there's less space, like I mentioned before, wikipedia came out with their own app on the iphone YEARS ago.
There's no difference between a high school student using wikipedia for history class and the guilded age and my annoying younger cousins learning how to use the using website on the family computer like I did when I was really little.
"The current skin helps reading comprehension for new (younger) users because there's less stuff on the website"
Actually, there's no difference between someone in high school using wikipedia for class and newer users using it for school. I learned how to use the internet on the family computer, so what's the difference?
"You can just change the website back to the old design on your account"
Not everyone is good with computers and knows how to do that. Plus, wikipedia stops people from creating an account on ANY public internet, so even if you go to your local library and try to create an account or do that at school, it doesn't work.
If you have to use the built in email feature on wikipedia to create a new account so that you can change the design and the new design slows down you from learning anything, you're probably going to end up with your parents getting pissed off because you got an F on your report card as a result.
"The people that work at the company that maintains wikipedia can just add the features found in the original design and use that on the current skin"
Not Exactly.
The new design not ontly prevents you from adding the links on the side of the website, but it would also look horible.
Which slows down you from learning anything anything where the original design from 2010 didn't and had the features like side links or popout tabs on the bottom of the page.
Also when was the last time you actually saw someone using wikipedia in high school? I haven't seen anyone use it at my school. Jelleyjelly (talk) 02:18, 6 March 2026 (UTC)
- Only a small fraction of people use the app instead of mobile Web and this is Commons, not Wikipedia where an even lower fraction uses the Commons app. I think proposals would have more likelihood of getting implemented if you were requesting specific changes to the new skin or some new configurability for it by which Commons could adjust how it looks. Could you describe/name very briefly (this is a long post), which exact things you don't like about the new UI? The sidebar is there by default unless it has been hidden. Prototyperspective (talk) 11:39, 6 March 2026 (UTC)
- The current design is generally speaking insainly difficult to navigate where the original is much easier to use and isn't in your face. I don't think there's a good way to fix the current design.
- Original (vector2010):
- Current: ~2026-14584-69 (talk) 00:44, 7 March 2026 (UTC)
- Well the TOC on the side does make it easier to navigate and closing the right or both panels in your screenshots would solve the narrow space issue. Prototyperspective (talk) 21:32, 8 March 2026 (UTC)
2022 layout actually removes side links and those fold out bars on the bottom of wikipedia pages
, @Jelleyjelly perhaps you are on mobile view? I assume you are referring to English Wikipedia and I can still see the "side links" and the "fold out bars on the bottom" using the desktop view of the new 2022 layout, so they definitely did not remove them. Thanks. Tvpuppy (talk) 15:29, 6 March 2026 (UTC)- Yeah but the vector 2010 skin had a directory of links, not a drop down menu with a ton of stuff removed and that made it easy to use ~2026-14584-69 (talk) 00:48, 7 March 2026 (UTC)
- @~2026-14584-69: It didn't support dark mode as well. However, if you want to go back to using it like it was in 2010-2021, you may use "useskin=vector" in the command line (with "?" or "&" as appropriate) or set your appearance/rendering preferences as a logged-in user in Special:Preferences#mw-prefsection-rendering. YMMV as a temporary account; incognito, I get "Please create an account to change preferences". — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:21, 7 March 2026 (UTC)
- Ok yeah but what about everyone else that's either not great with computers or doesn't know how to do that? Why not just make it the default, not just for people like me that use the useskin=vector all the time? ~2026-14584-69 (talk) 03:18, 7 March 2026 (UTC)
- @~2026-14584-69: That would not be progress. I resisted the new looks for a while in favor of Monobook, but dark mode won me over. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:38, 7 March 2026 (UTC)
- Yeah but not all browsers have dark mode. Also even if that were true, why not make an extension that has dark mode with the vector 2010 skin? ~2026-14678-29 (talk) 13:50, 7 March 2026 (UTC)
- this would be sick. -Nard (Hablemonos) (Let's talk) 14:34, 7 March 2026 (UTC)
- Yeah but not all browsers have dark mode. Also even if that were true, why not make an extension that has dark mode with the vector 2010 skin? ~2026-14678-29 (talk) 13:50, 7 March 2026 (UTC)
- @~2026-14584-69: That would not be progress. I resisted the new looks for a while in favor of Monobook, but dark mode won me over. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:38, 7 March 2026 (UTC)
- Ok yeah but what about everyone else that's either not great with computers or doesn't know how to do that? Why not just make it the default, not just for people like me that use the useskin=vector all the time? ~2026-14584-69 (talk) 03:18, 7 March 2026 (UTC)
- @~2026-14584-69: It didn't support dark mode as well. However, if you want to go back to using it like it was in 2010-2021, you may use "useskin=vector" in the command line (with "?" or "&" as appropriate) or set your appearance/rendering preferences as a logged-in user in Special:Preferences#mw-prefsection-rendering. YMMV as a temporary account; incognito, I get "Please create an account to change preferences". — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:21, 7 March 2026 (UTC)
- Yeah but the vector 2010 skin had a directory of links, not a drop down menu with a ton of stuff removed and that made it easy to use ~2026-14584-69 (talk) 00:48, 7 March 2026 (UTC)
Oppose You can change your preferred skin in preferences. Regarding sidelinks and "fold out bars" (I guess you are talking about navigation boxes), you can still move the sidelinks to sidebar and navboxes are still visible on Vector 2022. Nemoralis (talk) 12:54, 9 March 2026 (UTC)
Oppose Seeing from a UX POV: I approve that Wikipedia/WMC needs a more modern UI to create an impression on the users that Wikipedia becomes more modern (psychological effect: people often think something is modern when it looks more modern). Anyway, if you demand another design, you can change it as proposed before --PantheraLeo1359531 😺 (talk) 16:29, 9 March 2026 (UTC)
Oppose I personally am not a fan of new vector, but i think its more important that all wikimedia sites are consistent. Bawolff (talk) 15:24, 29 March 2026 (UTC)
- Couldn't you just change the skin to the old vector 2010 on all wikipedia sites? ~2026-19467-86 (talk) 17:06, 29 March 2026 (UTC)
Oppose A fixed-width layout is better for many reasons, not just readability. Covid has nothing to do with it.--Strainu (talk) 09:30, 31 March 2026 (UTC)
Possible upload: Leipzig address books
Hi all,
I’ve compiled a list of public-domain Leipzig address books from the digital collections of the SLUB Dresden. They cover 1830–1937 and total about 100 pdfs. They grow with population, with the 1937 edition containing about 2000 pages.
My plan would be to upload them to Commons (with attribution to SLUB) as PDFs with included OCR (they are in Fraktur so require some fiddling in Tesseract, I still haven't gotten it to recognize ligatures like tz, etc.). Just being able to search them is I think tremendously useful. I would then like to create Wikisource index pages so that the OCR can be improved.
Before starting, I wanted to check whether:
- these are already uploaded somewhere I may have missed
- there is a preferred format (PDF vs DjVu)
- there are recommendations for batch upload tools or workflows.
I am working from a data set that looks like:
https://gist.github.com/amundo/85d2cbff9efc7e17e384c767a310b1d4
Thanks! Babbage (talk) 15:51, 6 March 2026 (UTC)
- @Babbage Hier are already some files from the SLUB Category:Documents by Sächsische Landesbibliothek – Staats- und Universitätsbibliothek Dresden --PantheraLeo1359531 😺 (talk) 17:23, 10 March 2026 (UTC)
- Thanks PantheraLeo1359531 😺. I looked through the category but didn’t find any address books there. Babbage (talk) 14:16, 11 March 2026 (UTC)
- I don't know if there is an official format preference, but PDF is far more widespread. OpenRefine is a mass-upload tool, but needs some knowledge to use --PantheraLeo1359531 😺 (talk) 17:23, 10 March 2026 (UTC)
- Thanks again. My current plan is to use Tesseract with Fraktur to try to get decent OCR and then upload the output as PDFs. Babbage (talk) 14:18, 11 March 2026 (UTC)
- If it is not about several ten thousand files, it would not be a huge problem if there are some duplicates. They can be deleted afterwards. OCR is highly appreciated :) --PantheraLeo1359531 😺 (talk) 15:02, 11 March 2026 (UTC)
- Thanks again. My current plan is to use Tesseract with Fraktur to try to get decent OCR and then upload the output as PDFs. Babbage (talk) 14:18, 11 March 2026 (UTC)
Allow the INDEX/NOINDEX magic words in file namespace
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The NOINDEX magic word makes it possible to instruct search engines not to index a particular page. On English Wikipedia the NOINDEX magic word is ineffective on articles in mainspace that are older than 90 days. According enwiki's noindex template documentation this is because articles that are so terrible they shouldn't be indexed should be userfied/draftified/deleted. On Commons, the "main" namespace is the File: namespace, but that has a different scope from Wikipedia's article namespace. Not every file page is notable here, and we can't userfy/draftify file pages.
For example, when a user uploads a selfie for their user page, they may wish for search engines not to index it because it's simply not relevant. Maybe a jolly selfie being the first hit would be an unfavorable impression for potential employers who search for their name. Or if a humorous file that's used on a project page but unintentionally shows up in an unrelated search on search engines, the community should have some control over the noindex directive. - Alexis Jazz ping plz 08:37, 26 March 2026 (UTC)
Allow the INDEX/NOINDEX magic words in file namespace: votes
Request a configuration change to enable the INDEX/NOINDEX magic words in the file namespace on Commons.
Support as proposer. - Alexis Jazz ping plz 08:37, 26 March 2026 (UTC)
Support Abzeronow (talk) 01:29, 27 March 2026 (UTC)
Support but we'll need a clear guideline on when it may be used. I don't want to see people NOINDEXing someone else's photo to promote their own, etc. - Jmabel ! talk 03:49, 27 March 2026 (UTC)
Oppose such a feature only creates problems. Every content on this platform should be searchable with internal and external search engines. GPSLeo (talk) 06:08, 27 March 2026 (UTC)
Oppose no need for this and only causing extra workload, misuses, and issues. --Prototyperspective (talk) 14:22, 27 March 2026 (UTC)
Oppose Per my comment in VRTN. Nemoralis (talk) 14:31, 27 March 2026 (UTC)
Oppose everyone knows that when they upload a file here its been freely released. I dont see any reason a selfie for use on a user page warrants not being searchable especially as it on the user page to be seen. For the those very occassional time when a user needs personal protection admins can be asked quietly to delete a photo. Gnangarra 14:35, 27 March 2026 (UTC)
Oppose per Gnangarra; and because there is no evidence that there is an existing problem to which this is a solution. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:52, 27 March 2026 (UTC)
Oppose We are not a general purpose file host. If people are not happy with their content being shared they should find somewhere else to upload it. Bawolff (talk) 15:01, 29 March 2026 (UTC)
Comment From a technical level, I believe "noindex" on the file description page would not work. Search engines identify images by their URL, e.g. the thumbnail URL on upload.wikimedia.org, and they discover these in context of web pages that embed those images. The associated search terms are mostly determined by the text on those web pages (i.e. words on your user page, and words on the category page) and the words in the filename. The "File" description page is (for the most part) just another web page that displays the image, it is not the image itself. No-indexing the "File" page would not "noindex" the original file on upload.wikimedia.org, nor would it no-index every thumbnail size of the image on upload.wikimedia.org. You would instead need to prevent discovery by no-indexing every article, user page, category, etc where the image may be displayed on Commons. And, on any other wikis. And, on any other websites that may embed or hotlink the image.
Uploading a selfie and displaying it on your user page is akin to uploading an avatar in most other software (discussion forum, Flickr, Phabricator, social media, etc). If your account (and avatar) should not be associated in public with your real name, then you should use a username that is not your real name, and not mention your real name in your user page, image filename, and file description page. --Krinkle (talk) 02:41, 30 March 2026 (UTC)
Allow the NOINDEX magic word in file namespace: discussion
Discuss details for this proposal here.
- im not sure it would actually work. the noindex is on the page and there isnt really a way to apply it to a file easily. so while it would hide the image page from indexing, it wouldnt hide the image itself from indexing. —TheDJ (talk • contribs) 06:59, 27 March 2026 (UTC)
- TheDJ, in my experience, Google Images never returns a result with merely a deep link to an image. (whether other image search engines can I don't know) But even if it did, without the keywords from the file page it would be considerably less likely to be returned as a result. - Alexis Jazz ping plz 12:20, 27 March 2026 (UTC)
- yeah but as soon as you put it anywhere else, an article a project namespace page.. it would return. I think that might cause confusion. —TheDJ (talk • contribs) 13:03, 27 March 2026 (UTC)
- Even if the image is simply in a category, that'll probably get indexed too unless the category has explicitly been noindexed as well. I'd agree that noindexing images is probably futile. Omphalographer (talk) 16:54, 27 March 2026 (UTC)
- Omphalographer, Google images never seems to return an image for being used on a category page (let me know if you can find an example where it does), and categories may not contain the keywords needed for an image to show up. - Alexis Jazz ping plz 07:55, 28 March 2026 (UTC)
- It doesn't do so often, but it can. Try searching for images with the keyword "CommonsRoot"; when I tried this, it came up with thumbnails of some images which were (mis)categorized there. (This is, obviously, a contrived example, but it shows that image thumbnails do get picked up from category pages.) Omphalographer (talk) 17:39, 28 March 2026 (UTC)
- Thanks, I've never seen that before. It is still much less likely to get images in a search result without a file page, but apparently it is possible, so I stand corrected on that. - Alexis Jazz ping plz 12:31, 29 March 2026 (UTC)
- @Alexis Jazz Our category pages are often scoring better than the individual file pages it seems. I haven't really figured out why this is yet, but it might be because the search indexers care more about the strength of the link path getting you to an image than about the image itself.. And as file description pages don't have very good link paths (it's not a natural destination for people), category pages (just as articles) are contributing a lot to their SEO score right now as the next best thing. Pure speculation however. There's also the issue where it might be that the content of the information table is mostly ignored because it is a table, so the category pages might have more SEO scoring words on it than most file description pages (yes this is a major problem, but hard to investigate as i'm not a WMF employee). —TheDJ (talk • contribs) 18:30, 31 March 2026 (UTC)
- It doesn't do so often, but it can. Try searching for images with the keyword "CommonsRoot"; when I tried this, it came up with thumbnails of some images which were (mis)categorized there. (This is, obviously, a contrived example, but it shows that image thumbnails do get picked up from category pages.) Omphalographer (talk) 17:39, 28 March 2026 (UTC)
- Omphalographer, Google images never seems to return an image for being used on a category page (let me know if you can find an example where it does), and categories may not contain the keywords needed for an image to show up. - Alexis Jazz ping plz 07:55, 28 March 2026 (UTC)
- Even if the image is simply in a category, that'll probably get indexed too unless the category has explicitly been noindexed as well. I'd agree that noindexing images is probably futile. Omphalographer (talk) 16:54, 27 March 2026 (UTC)
- yeah but as soon as you put it anywhere else, an article a project namespace page.. it would return. I think that might cause confusion. —TheDJ (talk • contribs) 13:03, 27 March 2026 (UTC)
- TheDJ, in my experience, Google Images never returns a result with merely a deep link to an image. (whether other image search engines can I don't know) But even if it did, without the keywords from the file page it would be considerably less likely to be returned as a result. - Alexis Jazz ping plz 12:20, 27 March 2026 (UTC)
- The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Allow the Upload Wizard to automatically convert MP4 to WebM
We at Wiki Med have built the ability to automatically convert MP4 to WebM during upload via the Upload Wizard.
Is this something the Commons community is willing to accept? Ie has the position changed since the 2014 RfC? --Doc James (talk · contribs · email) 09:05, 29 March 2026 (UTC)
Summary
- Summary written by TheDJ, community developer that developed the current video player in use and has been following a/v in our community since 2007
The current discussion focuses on if and how we should allow people to upload MPEG-4 (mp4) files, the most popular and most common video formats and used by most recording devices. The discussion does NOT concern itself with playback in this format. Playback is separate from upload and storage and has an existing separate solution where people will always receive audio/video in an alternate format.
This discussion measures people's opinions about;
- Allow upload and then autoconvert into a free format before storing and making the file public in free formats (as proposed by Wiki Med and Doc James)
- Allow upload and store that file (preserving original quality) but only make it public in free formats.
- Do not allow uploads (status quo)
The idea behind using autoconversion is that it would be a low-risk and cheap or gratis way to allow uploads of MPEG-4. Possibly it doesn't even require a license at all, or gratis/low cost license might be obtainable by Wikimedia Foundation (to be determined later). Preserving the original but not making it public, is a similar option but it might be slightly more difficult to get legal clearance or a license for.
In-depth background
MPEG-4 is a set of standards for audio and video fileformats (how to store and combine audio and video in a file) and codecs (compression techniques for audio and video to reduce their size). Commons has so far not used nor accepted MPEG-4 uploads. This is because MPEG-4 is often considered to not be a completely Free format (in the sense of Free software) which is generally how we build the important parts of Wikipedia, Commons and MediaWiki. Using Free formats is an ideological choice that we as a community, think allows for maximum independence and reuse. It explains why we use Creative Commons and GPL as licenses of the works and the software. However this ideology is not absolute. We allow fair use on some wikis such as English Wikipedia and many of our community happily use macOS or Windows. We also use lots of hardware that has licensing fees incorperated into their price (every internet router, every phone). There are areas where we choose or have to interface with a non-free world.
With "not completely Free", we mean that the MPEG-4 standards are subject to patents by the companies that developed the standards. A patent is an exclusive right, allowing these companies to charge others for the usage of what they created. They do this via a collective licensing organization that levies fees that a user of the technology is required to pay. The MPEG-4 organizations have given consumers a default gratis license for most types of non-commercial usage, however commercial companies, hosting platforms and hardware manufacturers do not have such a default gratis license. This is what makes MPEG-4 more complex for us and why so far we have simply avoided it.
In order to be able to host, decode and (not discussed here) especially encode MPEG-4, the Wikimedia Foundation MIGHT be required to obtain a license in order to facilitate parts of the solutions discussed here. Organizations like Youtube, Instagram and Netflix all have such licenses. All this follows a discussion in 2014, where the licensing organizations offered WMF a gratis license, but we as a community could not find agreement that allowed the foundation to accept this license. It is uncertain if the licensing bodies would offer us a gratis license to decode or host files again and if we even need one to begin with for these particular solutions beings discussed. Figuring this out is already an expensive proces, which is why the foundation would want to know if we are interested in this.
The patents of SOME parts of MPEG-4 (the older ones) have mostly expired around the world. The newer ones (h264, h265 etc) have not yet. When a consumer sees an mp4, it is most likely to be of this newer type. As a consumer you have no easy way to distinguish between old and new mp4 as they all use the same file extension. It is possible to detect and treat these files differently during upload, but it requires some implementation from WMF/MediaWiki's side, but with most mp4 now being of the newer type, distinguishing between the older and the newer might not be so relevant to this discussion.
Disputes about patents are common. Up to 2006, there was a BIG problem with GIF files which led to the creation of PNG. This GIF issue is largely responsible for our early choice in avoiding these types of patented media formats. However, even technology that does not have patents can still cause problems. This week Dolby sued Snap Inc. (Snapchat) about usage of the 'patent-free' AV1 (which Commons currently accepts). Just because a technology claims to be patent-free, does not mean you are insulated from being dragged into a court (It is similar to copyright in that regard). This raises the question if being very sensitive or careful about patents is useful at all for the goals we are trying to achieve.
This discussion thus combines questions about:
- principles / ideology of our community
- legal risks
- consumer behavior and expectations
- technical implementation options and costs
Allow auto conversion
Comment: This is support for the idea generally, with a number of specific mechanisms being possible, including convection on upload with file uploaded as [[My_video.webm]]. Or conversion on playback as discussed below.
Support Will be nice not to have to use third party converter tool. Doc James (talk · contribs · email) 09:05, 29 March 2026 (UTC)
Support Agree with Doc James, not needing to use a third party which can be expensive or limiting in what can be concervted would be good Gnangarra 10:05, 29 March 2026 (UTC)
Support all in one and (at least) easier (if we still cant allow mp4) --GioviPen GP msg 12:06, 29 March 2026 (UTC)
Strong support. This remove the burden from the end user in using their own devices or computers doing the conversion. —exec8 (talk) 12:09, 29 March 2026 (UTC)
Support UW already directs users to v2c. This would just make the process smoother. Rkieferbaum (talk) 12:14, 29 March 2026 (UTC)
Support Thanks for the development – I think it's useful; more developments are needed. --Prototyperspective (talk) 16:09, 29 March 2026 (UTC)
Support It would help especially new users and people who are not codec experts. At least older codecs that can be packed into MP4 should lose patent protection soon, but until then, we need a user-friendly alternative --PantheraLeo1359531 😺 (talk) 17:43, 29 March 2026 (UTC)
Yes!!!! JayCubby (talk) 20:13, 29 March 2026 (UTC)
Support This is game-changing. Is it fundamentally different from video2commons? —Justin (koavf)❤T☮C☺M☯ 05:36, 30 March 2026 (UTC)
Support This is the need of the hour. Many users have faced issues during recent WLF edition due to commons not accepting MP4 files and shall end dependency on external/internal tools for contribution. --✝iѵɛɳ२२४०†ลℓк †๏ мэ 05:59, 30 March 2026 (UTC)
Support support and help the contributions and facilitate to upload videos on commons Dzkouslavia (talk) 12:39, 30 March 2026 (UTC)
Strong support Tausheef Hassan Auntu ✉Talk? 12:56, 30 March 2026 (UTC)
Support Finally! Billions of learners and readers will benefit! Ocaasi (talk) 15:24, 30 March 2026 (UTC)
Support YES PLEASE ... If we can make it work via the Commons app so much the better Lajmmoore (talk) 15:28, 30 March 2026 (UTC)
Support Yes, yes, absolutely yes. Lirazelf (talk) 15:45, 30 March 2026 (UTC)
Strong support Yes please! Ambrosia10 (talk) 16:52, 30 March 2026 (UTC)
Strong support About time! I uploaded several videos through v2c and that interface was a pain to navigate through. It lacks error messages if it fails to successfully process and seemingly video upload being "stuck" according to the progress bar despite not actually stuck. OhanaUnitedTalk page 18:21, 30 March 2026 (UTC)
Strong support Raymond (talk) 20:24, 30 March 2026 (UTC)
Strong support --JPF (talk) 20:41, 30 March 2026 (UTC)
Strong support // Martin K. (talk) 21:12, 30 March 2026 (UTC)
Support -- Regards, ZI Jony (Talk) 01:11, 31 March 2026 (UTC)
Support, more straightforward, less time consuming, less complicated than the current methods (e.g. converting it on your own or doing it using v2c). Thanks. Tvpuppy (talk) 02:01, 31 March 2026 (UTC)
Support This would definitely be a game-changer and save us a lot of time. At times, the status quo comes as a demotivation. signed, Aafi (talk) 06:55, 31 March 2026 (UTC)
Support We need it! -Theklan (talk) 07:33, 31 March 2026 (UTC)
Strong support —Matthias Süßen (talk) 07:41, 31 March 2026 (UTC)
Strong support — Nabin K. Sapkota (talk) 08:07, 31 March 2026 (UTC)
Support --Ameisenigel (talk) 08:16, 31 March 2026 (UTC)
Strong support Sir Amugi (talk) 08:55, 31 March 2026 (UTC)
Strong support B722N (talk) 09:10, 31 March 2026 (UTC)
Support In case the proposal below is not approved, this is an acceptable middle ground.--Strainu (talk) 09:28, 31 March 2026 (UTC)
Strong support TCY (talk) 09:44, 31 March 2026 (UTC)
Support --Frank Schulenburg (talk) 12:48, 31 March 2026 (UTC)
Support Por favor --Oscar_. (talk) 15:12, 1 April 2026 (UTC)
Support - long overdue. Thanks. Mike Peel (talk) 20:47, 1 April 2026 (UTC)
Support. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 20:51, 1 April 2026 (UTC)
Support Easy and frictionless sharing of video content is vital. We should be self-consciously making things easier for people who create videos to make them available on Commons.Carwil (talk) 10:38, 2 April 2026 (UTC)
Strong support - This will increase the quantity of videos being uploaded into Wikimedia Commons if one does not have to go through any other softwares just to get a video converted to WebM from MP4 for upload. Kambai Akau (talk) 14:12, 2 April 2026 (UTC)
Support As far as I understand, this is basically just integrating video2commons into the upload wizard, right? If so, yes please. — Rhododendrites talk | 14:35, 2 April 2026 (UTC)
Support This would significantly lower the barrier for contributors, especially those working in low-resource environments where access to reliable conversion tools is limited. Integrating this into the upload workflow would make video contributions more accessible, efficient, and scalable. —Lomoraronald (talk) 14:42, 2 April 2026 (UTC)
Strong support - - Emha (talk) 07:05, 3 April 2026 (UTC)
Allow uploading MP4 files (and convert to WebM for playback)
Uploaded as [[My_video.mp4]].
This would be similar to how formats like TIFF are handled, where you upload the file but it's converted to a different format for viewing. The original file is still retained.
Support I supported allowing uploading of MP4 files in the 2014 RFC and I still support that now. When the patents expire, we will want to have the original files, before they went through a lossy transcoding step. We already have the technical infrastructure for transcoding for display, whereas there is no support for transcoding on upload. -- Tim Starling (talk) 00:41, 30 March 2026 (UTC)
Support If we have legal clearance and community consensus to allow converting MP4 files on WMF production servers, then I recommend we build on the transcode implementation we have today (which generates derivatives post-upload, through the MediaWiki JobQueue). This means we fund and maintain one mechanism, rather than two, and keeps the overall system simpler. --Krinkle (talk) 02:05, 30 March 2026 (UTC)
Support If the WMF is good with this so am I Doc James (talk · contribs · email) 05:20, 30 March 2026 (UTC)
Support If it is legally doable --PantheraLeo1359531 😺 (talk) 10:34, 30 March 2026 (UTC)
Support If Legal is okay with this. When patents expire we may be able to unlock the originals. - Alexis Jazz ping plz 10:53, 30 March 2026 (UTC)
Support no reason not to. Rkieferbaum (talk) 11:58, 30 March 2026 (UTC)
Strong support If it is legally doable Tausheef Hassan Auntu ✉Talk? 12:57, 30 March 2026 (UTC)
Support I see no reason not to and many benefits from doing it this way! Ocaasi (talk) 15:24, 30 March 2026 (UTC)
Support Agree with comments above and support this approach. Ambrosia10 (talk) 16:54, 30 March 2026 (UTC)
Support if it's possible, I support. Warmglow (talk) 17:44, 30 March 2026 (UTC)
Strong support Raymond (talk) 20:24, 30 March 2026 (UTC)
Strong support per User:Fuzheado's idea that Wikimedia should be more about media, and MP4 will be a gamechanger once we can publicly show those, for now transcoding to formats that we can use will do. Abzeronow (talk) 04:24, 31 March 2026 (UTC)
Support this would be a good move. -Theklan (talk) 07:36, 31 March 2026 (UTC)
Strong support —Matthias Süßen (talk) 07:40, 31 March 2026 (UTC)
Strong support - Nabin K. Sapkota (talk) 08:08, 31 March 2026 (UTC)
Support --Ameisenigel (talk) 08:19, 31 March 2026 (UTC)
Strong support Sir Amugi (talk) 08:54, 31 March 2026 (UTC)
Strong support It's high time to allow formats used in the real world.--Strainu (talk) 09:27, 31 March 2026 (UTC)
Strong support TCY (talk) 09:45, 31 March 2026 (UTC)
Strong support Amir (talk) 10:04, 31 March 2026 (UTC)
Strong support if we can get the patent license sorted. I prefer this option over the other. I don't think from a legal perspective they are fundamentally different and I prefer to preserve originals. —TheDJ (talk • contribs) 10:32, 31 March 2026 (UTC)
Support --Frank Schulenburg (talk) 12:48, 31 March 2026 (UTC)
Support --Kiraface (talk) 13:03, 31 March 2026 (UTC)
Support What is important is the video is uploaded without any use of 3rd party processing either online or on user's computer or devices without loss on quality (frame rate, video resolution). --exec8 (talk) 13:58, 31 March 2026 (UTC)
Support --Mounir TOUZRI (talk) 07:43, 1 April 2026 (UTC)
Support - makes sense. Thanks. Mike Peel (talk) 20:47, 1 April 2026 (UTC)
Support. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 20:51, 1 April 2026 (UTC)
Support - Kambai Akau (talk) 14:16, 2 April 2026 (UTC)
Support This is complex, and this seems like a good a place as any to articulate my understanding. We have a spectrum of options: (a) status quo (only allow current free formats, rely on external tools to convert); (b) allow uploading of mp4, convert to webm, discard the mp4; (c) allow uploading of mp4, convert to webm, store the mp4 behind the scenes somewhere but don't offer it to the public; (d) allow uploading of mp4, convert to webm for playback, and allow user downloading of the mp4. This section is for D, the above section is for B. The others are mentioned elsewhere. If I understand correctly, none of these cases involve realistic liability for our individual end users, right? It's all about, on one hand the degree of compromise of our free/open ideals, and on the other hand the kind of responsibilities the WMF would bear. And we're not making a decision here as much as showing the WMF what we want. If that's all correct, I say D>C>B>A. Only accepting formats that almost no devices actually output is one reason why Commons does so poorly as a source of video. Every Android, GoPro, Windows, Nikon, Canon, Olympus, Panasonic, and Sony device outputs mp4, not webm or ogv. The free/open - usability tension always requires some sort of compromise, but the conditions for video on Commons makes the current situation feels too tilted towards the former. — Rhododendrites talk | 15:04, 2 April 2026 (UTC)
- I would say that is correct description of the situation. The main thing is that in the past WMF was forbidden by the community from purchasing a license to allow us to take in MP4 files. The change from the status quo is that this would authorize WMF to investigate the patent situation and acquire a license if it makes sense to do so (i.e. the terms aren't to onerous). That doesn't mean it will neccesarily happen; perhaps the patent owner wants a billion dollars, we are just opening the path here. As a minor nit pick i would say the status quo is not external tools but toolforge. I have no idea how that works legally; it is still a WMF server either way. It seems like toolforge admins just decided they didn't need a patent license. Hopefully they were correct as that would make everything easier. Bawolff (talk) 17:28, 2 April 2026 (UTC)
Support Easy and frictionless sharing of video content is vital. We should be self-consciously making things easier for people who create videos to make them available on Commons.--Carwil (talk) 22:40, 6 April 2026 (UTC)
Disallow MP4 files
Status quo.
- I actually want mp4s in Wikimedia as soon as possible, but I can make the case against to help discussion.
- We should not allow mp4 uploads now because doing so would require that we incorporate patented / non-free technology in the Wikimedia platform for the first time to convert from mp4 to free formats. Also, mp4 patents expire on 9 September 2027, so if we wait a year, then we get the same benefit without the compromise for non-free software. If I am wrong about the date, then someone please correct me by supporting my request for info on the date to the Wikimedia Foundation at meta:Community_Wishlist/W524 Bluerasberry (talk) 16:48, 31 March 2026 (UTC)
- Bluerasberry, The mp4 container can use various codecs, and HEVC/h.265 won't expire anytime soon. Another argument to disallow can be an increase in copyvios, though that could be mitigated by restricting mp4 to specific user groups. - Alexis Jazz ping plz 19:03, 31 March 2026 (UTC)
- I think the best counter-argument, is that if we take in patented codecs, but spit out free formats, we are increasing the market penetration of free formats, a net good (if you subscribe to that ideology). Better to provide support for those who want to transition to free formats, than to take a rigid interpretation that excludes everyone who isn't already fully on board. The counter-argument is that we could become dependent on whatever licensing terms are provided, and perhaps the patent holders will change their mind at a later date and make terms more onerous. If we've become dependent on the workflows enabled by this we might be stuck. Similarly it is kind of a violation of the right to fork, as other people would not be able to setup the same system without also paying for the patent license. It also provides income for patent pool holders which further encourages other people to form patent pools for other technology thus perpetuating the system. Bawolff (talk) 22:03, 31 March 2026 (UTC)
Discussion
- We can restrict this functionality to specific user groups if desired. Doc James (talk · contribs · email) 09:09, 29 March 2026 (UTC)
- How does this work? The conversion requires much computation resources, people would have to wait up to multiple hours to proceed with the upload process. And we are currently not able to block uploads to the stash, what makes this a possible vulnerability for denial of service attacks. GPSLeo (talk) 09:38, 29 March 2026 (UTC)
- User:Bawolff can you provide further details? Doc James (talk · contribs · email) 14:14, 29 March 2026 (UTC)
- I could go into details about the convert during upload proposal, however WMF folks have indicated a strong preference not to do that, so i'm not sure there is much point to talk about it here. The only way that approach is even possibly happening is if community is strongly in favour of it and views it as the only viable solution. Unless something changes we should probably view that approach as rejected. Bawolff (talk) 17:13, 30 March 2026 (UTC)
- For reference, m:Have the patents for H.264 MPEG-4 AVC expired yet? (not quite yet) and H.265 MPEG-4 HEVC (won't expire for years to come) are the two most common video codecs in MP4. I don't know if Wikimedia can implement this without licensing patents.
Also see Commons:Deletion requests/Files in Category:MP4 files for an experiment of what gets uploaded when .mp4 is allowed. - Alexis Jazz ping plz 12:26, 29 March 2026 (UTC)- As stated User:Alexis Jazz we can restrict this to specific users. Doc James (talk · contribs · email) 14:12, 29 March 2026 (UTC)
- The question is, should we allow it despite the patents (With either the WMF purchasing a license if neccessary or perhaps using them under generally available terms if applicable. IANAL, but the wikipedia article seems to say you dont need a license if the video is publicly available free of charge for H.264 and H.265 although AAC is less clear. I dont really know what the details would be, the question is predicated on WMF figuring out what would be needed legally and doing it if it wasn't too costly.) If the patents were expired we probably wouldnt be having this convo. Bawolff (talk) 14:59, 29 March 2026 (UTC)
- @Alexis Jazz What about m:Have the patents for MPEG-4 Visual expired yet?? That patent expires in less than 4 months (on July 19, 2026). Considering how slow discussions take place on Commons, the patent may have expired by the time this proposal is closed. OhanaUnitedTalk page 18:25, 30 March 2026 (UTC)
- OhanaUnited, w:MPEG-4 Visual (aka MPEG-4 Part 2, usually referring to MPEG-4 ASP, popular implementations being w:XviD and w:DivX) can exist in an MP4 containers, but is rare. Phones or cameras that record video in MPEG-4 ASP are >15 years old and probably used AVI containers, though some used 3GP. (who remembers that?) Pirates used AVI (or sometimes w:Matroska) and streaming (back in the day) used ASF (well, kinda, Microsoft MPEG-4 Version 3 was not strictly MPEG-4 compliant) or .MOV. By the way, w:MPEG-2 (even older) can also exist in an MP4 container, but that's even rarer. There is phab:T358266 to use MPEG-4 Visual to improve playback on older iOS devices. Note that odd bugs like phab:T209560 may surface. - Alexis Jazz ping plz 19:30, 30 March 2026 (UTC)
- @Alexis Jazz What about m:Have the patents for MPEG-4 Visual expired yet?? That patent expires in less than 4 months (on July 19, 2026). Considering how slow discussions take place on Commons, the patent may have expired by the time this proposal is closed. OhanaUnitedTalk page 18:25, 30 March 2026 (UTC)
- How does this work? The conversion requires much computation resources, people would have to wait up to multiple hours to proceed with the upload process. And we are currently not able to block uploads to the stash, what makes this a possible vulnerability for denial of service attacks. GPSLeo (talk) 09:38, 29 March 2026 (UTC)
- I think we need to answer a slightly different question here. So we built a modification to upload wizard/stash that would basically do the same thing as video2commons (conversion during the upload pipeline and throw away the original asset). WMF came back and said this seems way too complicated and kind of pointless (they are correct if you ignore the politics around file patents in our movement). Their preferred solution (if we are going to enable mp4) would be to enable mp4 as a media format and just transcode it to webm. So you upload an mp4 file, it creates File:MyFileName.mp4, all the transcodes are webm but the original file is still mp4. Possibly with the twist that we disable the download original file link (but still retain the original file asset on the server). So the question is: Should we enable upload of potentially patented formats like MP4 (including H.264, H.265 and AAC) as long as it is converted to a free format for display and it is legally feasible (with WMF perhaps obtaining a patent license if deemed neccesary and the benefits pragmatically outweigh the costs). If so, should we allow download of the original file or restrict it, and do we need any other restrictions like limiting it to a specific user group.. Bawolff (talk) 14:50, 29 March 2026 (UTC)
- @Bawolff: Yes, and only restrict if we are legally obligated to. I wrote phab:T393348#11762152 to that end. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:35, 29 March 2026 (UTC)
- If it is done this way, I think it would be a great feature. I think we should start with the same limits we have for mp3 files. GPSLeo (talk) 15:43, 29 March 2026 (UTC)
- @GPSLeo: Right, the Autopatrol minimum in Special:AbuseFilter/192 should be copyable to a new filter, assuming that the abuse filter can understand what Bawolff wants to do. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:23, 29 March 2026 (UTC)
- I made a section for this option. Bawolff (talk) 20:45, 29 March 2026 (UTC)
- @GPSLeo noted a valid concern, above (09:38, 29 March 2026 [UTC]). So, while I would support the notion of not being forced to do manual conversions, doing that server-side may indeed be problematic. But what about a tool that activates and runs client-side while uploading, maybe in Javascript, in a browser, be that a desktop or mobile version? Or integrated into the Commons app? It would remove the potential for DOS attacks and still eliminate the need to manually do conversions before thinking about uploading. Regards, Grand-Duc (talk) 10:46, 30 March 2026 (UTC)
- Bawolff, just curious: in the next few years the patents for h.264 and LC-AAC will expire, but newer codecs will take much longer, never mind future codecs. Do you think it'll be possible to unlock the h.264/LC-AAC files when the patents expire while keeping original files that use newer codecs locked? - Alexis Jazz ping plz 11:02, 30 March 2026 (UTC)
- Its possible to allow some codecs and not others. However it can be difficult from a ux perspective to explain to the user why some mp4 are allowed and not others. But yes, that is indeed an option. Bawolff (talk) 16:17, 30 March 2026 (UTC)
- Bawolff, I meant (not sure if that got across) downloading of the original files. - Alexis Jazz ping plz 20:01, 30 March 2026 (UTC)
- IANAL, but i assume that you do not need a patent license to simply offfer the files for download, this is more a purity thing about how much we want to stick to FSF-style burn all software patents ideology. So what we actually do on that front is up to the communuty imo. That said, yes we could probably work some system where H.264 can be downloaded but other codecs cant be. Bawolff (talk) 22:32, 30 March 2026 (UTC)
- Bawolff, now that I think about it, isn't HEIC a bigger fish to fry? - Alexis Jazz ping plz 00:18, 31 March 2026 (UTC)
- IANAL, but i assume that you do not need a patent license to simply offfer the files for download, this is more a purity thing about how much we want to stick to FSF-style burn all software patents ideology. So what we actually do on that front is up to the communuty imo. That said, yes we could probably work some system where H.264 can be downloaded but other codecs cant be. Bawolff (talk) 22:32, 30 March 2026 (UTC)
- i already have a patch locally that does this, with an allowlist of codecs. But it's a bit of a mess because codec names as extracted by id3 is a bit of a mess. —TheDJ (talk • contribs) 10:28, 31 March 2026 (UTC)
- Bawolff, I meant (not sure if that got across) downloading of the original files. - Alexis Jazz ping plz 20:01, 30 March 2026 (UTC)
- Its possible to allow some codecs and not others. However it can be difficult from a ux perspective to explain to the user why some mp4 are allowed and not others. But yes, that is indeed an option. Bawolff (talk) 16:17, 30 March 2026 (UTC)
- IMHO, it would be great if the conversion would be done in the user side using some WASM adhoc tool. —Ismael Olea (talk) 15:46, 30 March 2026 (UTC)
- One issue with this is that it requires users to keep the upload page open for the duration of the upload. This could be several hours. Bawolff (talk) 16:20, 30 March 2026 (UTC)
- I think it sounds better than the experience will be indeed. I'd caution against it. Just think of how easily your phone will kill the browser because it ran out of memory or cpu etc etc.. I don't think it's a very good user experience and it will be hard to explain properly to users. —TheDJ (talk • contribs) 10:30, 31 March 2026 (UTC)
- My thoughts on patent licensing are at phab:T157614#11769174. -- Tim Starling (talk) 02:41, 31 March 2026 (UTC)
- This whole discussion could really use a summary statement at the top. I feel like I've seen debates over containers and codecs and conversations (oh my!) regarding mp4 in the past, but don't remember (a) the details we have to consider, or (b) how we arrived at the status quo. For example, it would be useful to separate the legal, ethical, and technical considerations for a general audience. Otherwise, I offer an ignorant "sure, doing what video2commons does during the upload process is great" and also "sure, supporting more extensions is great". — Rhododendrites talk | 19:43, 31 March 2026 (UTC)
- @Rhododendrites I have written a summary —TheDJ (talk • contribs) 09:52, 2 April 2026 (UTC)
- Thanks, TheDJ. Very helpful. The complexities of patents, codecs, containers, and conversions still feel above my pay grade, but I suppose at this point if we're really just signalling to the WMF that we want MP4 [storage/conversion] support, that's an easier ask. — Rhododendrites talk | 14:34, 2 April 2026 (UTC)
- I think that is a correct assessment and I think that some of these elements are so complex, that we probably shouldn't focus too much on them at this stage. —TheDJ (talk • contribs) 14:40, 2 April 2026 (UTC)
- The codec situation is very complicated. On top of the different codecs, some codecs have profiles which sometimes can have different patent situations. So its not just sub-formats but sub-sub-formats (personally im a bit unclear if that applies to encoding only or both encoding & decoding). Probably the only relavent part to this discussion is that H.264 (aka AVC) is expiring soon-ish. H.264 is one of the more popular codecs of MP4, and most cell phones have a burried option where you can configure them to record in this codec even when its not the default. Some people might argue we should just wait it out if we are this close. But i think its a mess to try to explain to the user that this type of mp4 works well a different one doesnt, and that is not even counting the audio situation. Bawolff (talk) 17:43, 2 April 2026 (UTC)
- @TheDJ Thanks for summary. As a nit pick though, are they still offering a free license for non commercial use? They recently restructured their licensing fees and seem to have dropped all mentions of that. FWIW i think its unlikely there is a meaningful difference patent wise between the two approaches. I think the impetus behind the convert at upload time idea is more like a vegan who doesn't want to be in the same room as the meat. Bawolff (talk) 17:35, 2 April 2026 (UTC)
- Its not really clear. But from my reading, we would essentially have to pay for our own decoding (as we have not paid for this via ffmpeg), or we can buy GPUs that include the patent license. If we don't host mp4, we definitely could not count as a streaming service. We also don't sell anything (they talk about selling all over the place). And they have deminimis exceptions. So.. we would fall into a very small bucket that they probably won't really know what to do with if we ask them. But thaat also makes it unpredictable. —TheDJ (talk • contribs) 18:40, 2 April 2026 (UTC)
- Thanks, TheDJ. Very helpful. The complexities of patents, codecs, containers, and conversions still feel above my pay grade, but I suppose at this point if we're really just signalling to the WMF that we want MP4 [storage/conversion] support, that's an easier ask. — Rhododendrites talk | 14:34, 2 April 2026 (UTC)
- not sure if anyone has raised these:
- only mp4? the same can be done for mov, wav, etc. maybe? and also audio formats? (v2c despite its name also takes care of audio to audio conversion.)
- i have no knowledge on codec. i vaguely remember that some people say re-encoding videos may not be a bad idea coz phone videos often have much higher size per unit time because they have bad compression? so converting the original mp4 might be better in some cases?
- RoyZuo (talk) 11:51, 6 April 2026 (UTC)
- @Rhododendrites I have written a summary —TheDJ (talk • contribs) 09:52, 2 April 2026 (UTC)
Alternate consideration
Perhaps an alternative is to limit it to trusted users with demonstrated need by making the authority to upload mp4 via the uploaded wizard conditional on having a userright assigned. All others can still use video2commons or convert off site. Gnangarra 12:49, 1 April 2026 (UTC)
- I think that is an orthogonal question Bawolff (talk) 18:15, 1 April 2026 (UTC)
- I think we worry about restricting mp4 uploads when mp4s themselves are publicly viewable. There is a case to be made that we should not restrict though given that it is the video format that most people use. Abzeronow (talk) 02:36, 2 April 2026 (UTC)
WMF legal position
I have asked the WMF if they would provide us a legal position on MP4 to permit this to move forward. Doc James (talk · contribs · email) 17:16, 4 April 2026 (UTC)
- Doc James, on 3 April they responded that they are looking into it and it has their attention. Due to time constraints they didn't know yet when they could issue a comment. - Alexis Jazz ping plz 15:33, 6 April 2026 (UTC)
Video2commons requirement waiver
v2c is currently limited to only autoconfirmed users with 50+ edits.
could we introduce an additional condition to bypass the 50 edit requirement if needed? for example, by being autopatrol (which can be temporarily granted). https://github.com/toolforge/video2commons/issues/222 is the proposal on github.
i have seen sometimes new users upload videos when they participate in contests like com:wlm. now afaict 50 edits is a hard requirement that must be met.--RoyZuo (talk) 21:03, 6 April 2026 (UTC)
- RoyZuo, I was thinking about this just yesterday. How about allowing manually COM:Confirmed (and/or autopatrolled) users to use the tool without edit count requirements? - Alexis Jazz ping plz 22:32, 6 April 2026 (UTC)
Rename Template:YouTube CC-BY
youtube changed their licence in aug 2025, so now Template:YouTube CC-BY is only applicable to files before that.
can we please rename the template so it's clear this template only covers the youtube cc by licence before aug 2025? something like "Template:YouTube CC-BY (before August 2025)" or "Template:YouTube CC-BY 3.0"? RoyZuo (talk) 21:57, 6 April 2026 (UTC)
- RoyZuo,
wouldn't a template parameter be neater?On second thought, different licenses maybe should have separate templates. Maybe an overarching template that requires the publication date to automatically select the right template? - Alexis Jazz ping plz 22:23, 6 April 2026 (UTC)
