Commons:Village pump/Proposals - Wikimedia Commons

Commons:Village pump/Proposals - Wikimedia Commons
Jump to content
From Wikimedia Commons, the free media repository
Commons:Village pump
Latest comment:
6 minutes ago
by Alexis Jazz in topic
Proposal: Promote Commons:Upscaling to guideline
Community portal
introduction
Help desk
Village pump
proposals
technical
Administrators' noticeboard
vandalism
user problems
blocks and protections
Shortcuts
COM:VP/P
COM:VPP
Welcome to the Village pump proposals section
This page is used for
proposals
relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the
main Village pump
, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with
{{
Section resolved
|1=--~~~~}}
may be archived; for old discussions, see the
archives
; the latest archive is
Commons:Village pump/Proposals/Archive/2026/03
COMMONS DISCUSSION PAGES
Commons Help desk
Village pump (general discussion)
Proposals
Technical
Graphics and photography discussion
Photography critiques
Image improvement
Illustration workshop
Map workshop
Photography workshop
Video and sound workshop
Categories for discussion
Undeletion requests
Deletion requests
Volunteer Response Team/Noticeboard
Translators' noticeboard
Work requests for bots
Contact administrators
Vandalism
User problems
Dispute resolution
Blocks and protections
Bureaucrats' noticeboard
CheckUser requests
Oversight requests
Telegram
IRC
webchat
Commons mailing list
archive
Commons' bugs on Phabricator
Please note
One of Wikimedia Commons’ basic principles is: "Only
free content
is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
Have you read the FAQ?
Start a new discussion
SpBot
archives
all sections tagged with
{{
Section resolved
|1=~~~~}}
after 5 days and sections whose most recent comment is older than 30 days.
Mass upload proposal
edit
Latest comment:
16 days ago
8 comments
6 people in discussion
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 (
) 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:
What would be the best way to approach this upload?
YukiKoKo
talk
10:45, 25 February 2026 (UTC)
Reply
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)
Reply
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)
Reply
I've made a request for batch uploading (
), 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)
Reply
I would just manually upload useful photos instead. Photos like
[1]
aren't really useful and photos like
[2]
and
[3]
require an evaluation of the local freedom of panorama laws. There are also a lot of duplicates like
[4]
and
[5]
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)
Reply
--missing sig as for
Gnan (A)garra
added missing sig. imho you need ending tag to stop spilling into other section(s).
Gnangarra
--
Omotecho
talk
03:38, 2 April 2026 (UTC)
Reply
Omotecho
wasnt my edit
Gnan
garra
08:08, 2 April 2026 (UTC)
Reply
My bad, my eyeglasses must have been fogged. m(_#_)m
Omotecho
talk
02:05, 8 April 2026 (UTC)
Reply
Narrow scope for AI on Commons
edit
Latest comment:
22 days ago
82 comments
17 people in discussion
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)
Reply
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)
Reply
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)
Reply
Support
per nom.   — 🇺🇦
Jeff G.
please
ping
or
talk to me
🇺🇦
03:01, 1 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
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
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)
Reply
(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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
They won’t use AI if we don’t host it.
Dronebogus
talk
00:30, 3 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
Oppose
I didn't understand item 3 in requirement. Please rephrase it.
Gryllida
talk
07:37, 1 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
+1 -
Jmabel
talk
03:23, 4 March 2026 (UTC)
Reply
Maybe if this doesn’t pass we just ban AI enhancement?
Dronebogus
talk
11:12, 4 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
We have so many complaints from good photographers, who want to contribute but fail with the technical difficulties. Requesting them to upload the original and then the editing version would make the process even more complicated.
GPSLeo
talk
07:35, 6 March 2026 (UTC)
Reply
required to upload the original
: that would completely eliminate anything from third parties. -
Jmabel
talk
23:49, 5 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
Would be great to have a list of such tools.
Nakonana
talk
10:58, 2 April 2026 (UTC)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
Sure. Nobody said it's nothing.
Prototyperspective
talk
13:17, 24 March 2026 (UTC)
Reply
Legitimacy of usages
edit
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)
Reply
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)
Reply
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)
Reply
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)
Reply
Support
.   — 🇺🇦
Jeff G.
please
ping
or
talk to me
🇺🇦
01:19, 26 March 2026 (UTC)
Reply
Proposal: Allow file movers to delete single-revision redirects during file moves
edit
Latest comment:
28 days ago
23 comments
12 people in discussion
ACCEPTED:
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)
Reply
The following discussion is closed.
Please do not modify it.
Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Tracked in
Phabricator
Task T421373
RESOLVED
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
edit
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
edit
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
edit
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
edit
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
edit
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
edit
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)
Reply
Comments
edit
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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-redirect
capability 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)
Reply
Ellywa
Jmabel
, and
Carl Lindberg
: would you like to give your opinions? Regards,
ZI Jony
(Talk)
00:30, 16 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
If a few of them start warring they will lose their filemover privileges. Period. -
Jmabel
talk
17:31, 16 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
Support
edit
Support
Schlurcher
talk
08:17, 8 March 2026 (UTC)
Reply
Support
with the proposed safeguards.
Tvpuppy
talk
11:55, 8 March 2026 (UTC)
Reply
Support
.   — 🇺🇦
Jeff G.
please
ping
or
talk to me
🇺🇦
11:59, 8 March 2026 (UTC)
Reply
Support
Reh
man
15:43, 8 March 2026 (UTC)
Reply
Support
--
Wolfy13399
talk
14:54, 11 March 2026 (UTC)
Reply
Support
Hurricane
Zeta
21:15, 11 March 2026 (UTC)
Reply
Support
Shaan Sengupta
Talk
03:07, 12 March 2026 (UTC)
Reply
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)
Reply
Oppose
edit
--
Neutral
edit
--
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.
edit
Latest comment:
24 days ago
17 comments
12 people in discussion
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)
Reply
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)
Reply
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):
[6]
Current:
[7]
~2026-14584-69
talk
00:44, 7 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
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)
Reply
~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)
Reply
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)
Reply
~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)
Reply
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)
Reply
this would be sick. -
Nard
Hablemonos
) (
Let's talk
14:34, 7 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
Not based on a discussion on commons.
Bawolff
talk
17:37, 29 March 2026 (UTC)
Reply
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)
Reply
Allow the INDEX/NOINDEX magic words in file namespace
edit
Latest comment:
17 days ago
20 comments
12 people in discussion
SHALL NOT PASS:
3 support, 6 oppose, not passing. -
Alexis Jazz
ping plz
22:44, 6 April 2026 (UTC)
Reply
The following discussion is closed.
Please do not modify it.
Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)
Reply
Allow the INDEX/NOINDEX magic words in file namespace: votes
edit
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)
Reply
Support
Abzeronow
talk
01:29, 27 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
Oppose
no need for this and only causing extra workload, misuses, and issues. --
Prototyperspective
talk
14:22, 27 March 2026 (UTC)
Reply
Oppose
Per
my comment in VRTN
Nemoralis
talk
14:31, 27 March 2026 (UTC)
Reply
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.
Gnan
garra
14:35, 27 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
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)
Reply
Allow the NOINDEX magic word in file namespace: discussion
edit
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. —
Th
DJ
talk
contribs
06:59, 27 March 2026 (UTC)
Reply
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)
Reply
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. —
Th
DJ
talk
contribs
13:03, 27 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
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). —
Th
DJ
talk
contribs
18:30, 31 March 2026 (UTC)
Reply
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
edit
Latest comment:
4 days ago
137 comments
68 people in discussion
We at Wiki Med have built the ability to automatically convert MP4 to WebM during upload via the Upload Wizard.
[8]
[9]
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)
Reply
Summary
edit
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
edit
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
edit
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)
Reply
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
Gnan
garra
10:05, 29 March 2026 (UTC)
Reply
Support
all in one and (at least) easier (if we still cant allow mp4) --
GioviPen
GP msg
12:06, 29 March 2026 (UTC)
Reply
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)
Reply
Support
UW already directs users to v2c. This would just make the process smoother.
Rkieferbaum
talk
12:14, 29 March 2026 (UTC)
Reply
Support
Thanks for the development – I think it's useful;
more developments are needed
. --
Prototyperspective
talk
16:09, 29 March 2026 (UTC)
Reply
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)
Reply
Yes!!!!
JayCubby
talk
20:13, 29 March 2026 (UTC)
Reply
Support
This is game-changing. Is it fundamentally different from
video2commons
? —
Justin (
ko
vf
05:36, 30 March 2026 (UTC)
Reply
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)
Reply
Support
support
and help the contributions and facilitate to upload videos on commons
Dzkouslavia
talk
12:39, 30 March 2026 (UTC)
Reply
Strong support
Tausheef Hassan Auntu
✉Talk?
12:56, 30 March 2026 (UTC)
Reply
Support
Finally! Billions of learners and readers will benefit!
Ocaasi
talk
15:24, 30 March 2026 (UTC)
Reply
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)
Reply
Support
Yes, yes, absolutely yes.
Lirazelf
talk
15:45, 30 March 2026 (UTC)
Reply
Strong support
Yes please!
Ambrosia10
talk
16:52, 30 March 2026 (UTC)
Reply
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.
OhanaUnited
Talk page
18:21, 30 March 2026 (UTC)
Reply
Strong support
Raymond
talk
20:24, 30 March 2026 (UTC)
Reply
Strong support
--
JPF
talk
20:41, 30 March 2026 (UTC)
Reply
Strong support
//
Martin K.
talk
21:12, 30 March 2026 (UTC)
Reply
Support
-- Regards,
ZI Jony
(Talk)
01:11, 31 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
Support
We need it! -
Theklan
talk
07:33, 31 March 2026 (UTC)
Reply
Strong support
Matthias Süßen
talk
07:41, 31 March 2026 (UTC)
Reply
Strong support
Nabin K. Sapkota
talk
08:07, 31 March 2026 (UTC)
Reply
Support
--
Ameisenigel
talk
08:16, 31 March 2026 (UTC)
Reply
Strong support
Sir Amugi
talk
08:55, 31 March 2026 (UTC)
Reply
Strong support
B722N
talk
09:10, 31 March 2026 (UTC)
Reply
Support
In case the proposal below is not approved, this is an acceptable middle ground.--
Strainu
talk
09:28, 31 March 2026 (UTC)
Reply
Strong support
TCY
talk
09:44, 31 March 2026 (UTC)
Reply
Support
--
Frank Schulenburg
talk
12:48, 31 March 2026 (UTC)
Reply
Support
Por favor --
Oscar_.
talk
15:12, 1 April 2026 (UTC)
Reply
Support
- long overdue. Thanks.
Mike Peel
talk
20:47, 1 April 2026 (UTC)
Reply
Support
.   — 🇺🇦
Jeff G.
please
ping
or
talk to me
🇺🇦
20:51, 1 April 2026 (UTC)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
Strong support
- -
Emha
talk
07:05, 3 April 2026 (UTC)
Reply
Strong support
Bien sûr, as per previous discussion.
--
SJ
18:48, 10 April 2026 (UTC)
Reply
Strong support
about time --
Jarekt
talk
18:50, 10 April 2026 (UTC)
Reply
Strong support
yes please! But it should not be restricted to the upload wizard only, but supported for other upload means (ie. via API), so that mobile apps etc. are easy to support.
Nylki
talk
) 19:49, 10 April 2026 (UTC) (
talk
18:50, 10 April 2026 (UTC)
Reply
Strong support
Tarunno
talk
16:35, 12 April 2026 (UTC)
Reply
Strong support
--
Psubhashish
talk
17:13, 12 April 2026 (UTC)
Reply
Strong support
Gamaliel
talk
19:25, 13 April 2026 (UTC)
Reply
Strong support
Yes yes please. Had this been the standard 15 years ago I would have moved in the direction of video rather than almost completely still pictures.
Jim.henderson
talk
04:49, 15 April 2026 (UTC)
Reply
Strong support
It's a burning need.--
ROCKY
talk
05:53, 16 April 2026 (UTC)
Reply
Allow uploading MP4 files (and convert to WebM for playback)
edit
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)
Reply
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)
Reply
Support
If the WMF is good with this so am I
Doc James
talk
contribs
email
05:20, 30 March 2026 (UTC)
Reply
Support
If it is legally doable --
PantheraLeo1359531 😺
talk
10:34, 30 March 2026 (UTC)
Reply
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)
Reply
Support
no reason not to.
Rkieferbaum
talk
11:58, 30 March 2026 (UTC)
Reply
Strong support
If it is legally doable
Tausheef Hassan Auntu
✉Talk?
12:57, 30 March 2026 (UTC)
Reply
Support
I see no reason not to and many benefits from doing it this way!
Ocaasi
talk
15:24, 30 March 2026 (UTC)
Reply
Support
Agree with comments above and support this approach.
Ambrosia10
talk
16:54, 30 March 2026 (UTC)
Reply
Support
if it's possible, I support.
Warmglow
talk
17:44, 30 March 2026 (UTC)
Reply
Strong support
Raymond
talk
20:24, 30 March 2026 (UTC)
Reply
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)
Reply
Support
this would be a good move. -
Theklan
talk
07:36, 31 March 2026 (UTC)
Reply
Strong support
Matthias Süßen
talk
07:40, 31 March 2026 (UTC)
Reply
Strong support
Nabin K. Sapkota
talk
08:08, 31 March 2026 (UTC)
Reply
Support
--
Ameisenigel
talk
08:19, 31 March 2026 (UTC)
Reply
Strong support
Sir Amugi
talk
08:54, 31 March 2026 (UTC)
Reply
Strong support
It's high time to allow formats used in the real world.--
Strainu
talk
09:27, 31 March 2026 (UTC)
Reply
Strong support
TCY
talk
09:45, 31 March 2026 (UTC)
Reply
Strong support
Amir
talk
10:04, 31 March 2026 (UTC)
Reply
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. —
Th
DJ
talk
contribs
10:32, 31 March 2026 (UTC)
Reply
Support
--
Frank Schulenburg
talk
12:48, 31 March 2026 (UTC)
Reply
Support
--
Kiraface
talk
13:03, 31 March 2026 (UTC)
Reply
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)
Reply
Support
--
Mounir TOUZRI
talk
07:43, 1 April 2026 (UTC)
Reply
Support
- makes sense. Thanks.
Mike Peel
talk
20:47, 1 April 2026 (UTC)
Reply
Support
.   — 🇺🇦
Jeff G.
please
ping
or
talk to me
🇺🇦
20:51, 1 April 2026 (UTC)
Reply
Support
Kambai Akau
talk
14:16, 2 April 2026 (UTC)
Reply
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)
Reply
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)
Reply
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)
Reply
Support
per above. --
Sohom
talk
15:08, 8 April 2026 (UTC)
Reply
Strong support
As an organizer of Wiki Loves Monuments, Wiki Loves Folk, and multiple photowalks, this is one of the most consistent blockers I see for new contributors. Participants shoot video on their phones in MP4 and simply give up when they realize they have to convert before uploading. Auto-conversion in the Upload Wizard would directly increase video contributions from community events.
--
Suyash
Dwivedi
18:50, 8 April 2026 (UTC)
Reply
Strong support
ProtoplasmaKid
talk
14:45, 10 April 2026 (UTC)
Reply
Strong support
--
Houss 2020
talk
10:49, 11 April 2026 (UTC)
Reply
Strong support
Elisabeth Carrera (WMNO)
talk
11:28, 13 April 2026 (UTC)
Reply
Hell yes!
JayCubby
talk
23:48, 18 April 2026 (UTC)
Reply
Strong support
As a participant of Wiki Loves Africa, I have captured wonderful videos that fits the theme this year but I've been having trouble trying to use third party software to convert my files. I had this idea in my and I was so happy that it's been put into consideration when I saw the mail with this discussion.
Chrysella
Disallow MP4 files
edit
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)
Reply
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)
Reply
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)
Reply
Discussion
edit
We can restrict this functionality to specific user groups if desired.
Doc James
talk
contribs
email
09:09, 29 March 2026 (UTC)
Reply
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)
Reply
User:Bawolff
can you provide further details?
Doc James
talk
contribs
email
14:14, 29 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
As stated
User:Alexis Jazz
we can restrict this to specific users.
Doc James
talk
contribs
email
14:12, 29 March 2026 (UTC)
Reply
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)
Reply
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.
OhanaUnited
Talk page
18:25, 30 March 2026 (UTC)
Reply
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)
Reply
My (technically old) media design book from 2017–2019 mentioned AVI, WMA, MOV, and H.262, but not VP9 :P --
PantheraLeo1359531 😺
talk
13:32, 19 April 2026 (UTC)
Reply
PantheraLeo1359531
: Please see
w:VP9
.   — 🇺🇦
Jeff G.
please
ping
or
talk to me
🇺🇦
16:26, 19 April 2026 (UTC)
Reply
I know, but our book just didn't mention it, despite the broad distribution :) --
PantheraLeo1359531 😺
talk
17:01, 19 April 2026 (UTC)
Reply
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)
Reply
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)
Reply
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)
Reply
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)
Reply
I made a section for this option.
Bawolff
talk
20:45, 29 March 2026 (UTC)
Reply
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)
Reply
My concern is addressed by the fact that the transcoding process starts after the upload process finished. This allows us to create filters.
GPSLeo
talk
18:08, 30 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
Bawolff
, I meant (not sure if that got across) downloading of the original files.
Alexis Jazz
ping plz
20:01, 30 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
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. —
Th
DJ
talk
contribs
10:28, 31 March 2026 (UTC)
Reply
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)
Reply
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)
Reply
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. —
Th
DJ
talk
contribs
10:30, 31 March 2026 (UTC)
Reply
Just think about how much it will harm your phone's battery to have the cpu go full tilt for several hours.
Bawolff
talk
16:28, 31 March 2026 (UTC)
Reply
My thoughts on patent licensing are at
phab:T157614#11769174
. --
Tim Starling
talk
02:41, 31 March 2026 (UTC)
Reply
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)
Reply
Rhododendrites
I have written a summary —
Th
DJ
talk
contribs
09:52, 2 April 2026 (UTC)
Reply
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)
Reply
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. —
Th
DJ
talk
contribs
14:40, 2 April 2026 (UTC)
Reply
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)
Reply
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)
Reply
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. —
Th
DJ
talk
contribs
18:40, 2 April 2026 (UTC)
Reply
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)
Reply
We at Wiki Project Med would be happy to support further formats if the community / WMF is okay with that. Was planning on finishing MP4s before looking into further ones.
Doc James
talk
contribs
email
12:16, 6 April 2026 (UTC)
Reply
Wav is already allowed.
Bawolff
talk
13:15, 6 April 2026 (UTC)
Reply
Overview of video file properties
seconds
original mp4 / MB
commons webm (av1/opus) / MB
18
41
24
59
11
27
34
126
39
87
150
172
27
62
86
139
41
93
149
160
14
32
22
69
16
37
26
70
22
49
81
165
339
752
186
25
sum
1180
758
64
i uploaded a bunch of phone shot mp4 thru v2c recently. the converted webm is considerably smaller for one large and long video, but some smaller and shorter videos became bigger webm.--
RoyZuo
talk
10:53, 15 April 2026 (UTC)
Reply
Keep in mind this is going to vary significantly based on encoder settings. Its hard to say if its a fair comparison as you also need to make sure the subjective quality is constant.
Bawolff
talk
20:08, 15 April 2026 (UTC)
Reply
Alternate consideration
edit
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.
Gnan
garra
12:49, 1 April 2026 (UTC)
Reply
I think that is an orthogonal question
Bawolff
talk
18:15, 1 April 2026 (UTC)
Reply
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)
Reply
WMF legal position
edit
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)
Reply
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)
Reply
Perfect thanks for the update. Missed their comment. This by the way is building on a
2019/2020 RfC
which supported allowing MP4 uploads aswell.
Doc James
talk
contribs
email
16:03, 6 April 2026 (UTC)
Reply
Video2commons requirement waiver
edit
Latest comment:
12 days ago
4 comments
3 people in discussion
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).
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)
Reply
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)
Reply
yes "confirmed" is the solution.
RoyZuo
talk
12:38, 12 April 2026 (UTC)
Reply
I'm for the idea of doing something here, but I don't want to give autopatrolled rights to nearly new users. Among other things, it lets them do overwrites, which involve a good understanding of a policy that people new to Commons probably won't even know about. -
Jmabel
talk
18:53, 7 April 2026 (UTC)
Reply
Rename Template:YouTube CC-BY
edit
Latest comment:
16 days ago
6 comments
3 people in discussion
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)
Reply
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)
Reply
Comment
looks like (much to my surprise) only a few hundred files use this, so unless I got that wrong it would be easy to rename and for a bot to replace it everywhere it is used, then delete the old template name. As for name, I would definitely go for Template:YouTube CC-BY 3.0.-
Jmabel
talk
18:57, 7 April 2026 (UTC)
Reply
Jmabel
[10]
says "185627 transclusion(s) found." and
[11]
returns 185,587 results.
Alexis Jazz
ping plz
19:12, 7 April 2026 (UTC)
Reply
Alexis Jazz
Oops. I wonder why "what links here" turned up almost none of that. -
Jmabel
talk
19:43, 7 April 2026 (UTC)
Reply
Heck, if it's all in File space, then the substitution could be done with VFC. -
Jmabel
talk
18:59, 7 April 2026 (UTC)
Reply
Increase data maximum of (tabular) data pages
edit
Latest comment:
5 hours ago
5 comments
4 people in discussion
I am working more with transferring free data to Commons. But sometimes, the datasets are far beyond the recent maximum of 2 Mebibytes. I propose a limit of 32 Mebibyte or a new function for special cases. Splitting it into more pages means more work and the clarity suffers as a result. A recent example by me is the transfer of climate data by the DWD (CC BY-4.0) for a quarter of a century (it is 3 MiB large, in contrast to the 2 MiB limit), the data ranges from 1949 to 2024. Splitting it into every decade is more work and larger tables are no problem, as the desired date can be found by CTRL+F. --
PantheraLeo1359531 😺
talk
16:12, 13 April 2026 (UTC)
Reply
This limit is based on the database structure of MediaWiki, a change to this will be very complex. I would assume even more complex than solving the file size limit.
GPSLeo
talk
17:57, 13 April 2026 (UTC)
Reply
Its actually a pretty arbitrary limit meant to prevent people from doing silly things in normal pages. The actual in database limit is probably either 16MB or 4GB (Some places in the source code have it as a longblob where others have it as a mediumblob). I think the bigger issue is its questionable if storing tabular data in normal pages was a good idea to begin with. But in principle there is nothing hard preventing making
$wgMaxArticleSize
apply differently to the Data namespace, or maybe have the Tabular data content handler transparently compress things before counting the size. I think there is some reluctance among devs of allowing bigger articles just because we kind of always assume pages are relatively small.
Bawolff
talk
22:54, 13 April 2026 (UTC)
Reply
Tabular data is currently designed for smaller datasets. It's not meant to contain everything. It's not a relational database and, it isn't even Excel.
If we get to large sizes, you should start thinking about changing the backing storage in my opinion. Something that is more suited towards indexing and querying huge json documents. But maybe raising the limit to 4MB is doable. However, I don't think the limit is currently configurable per namespace/content model. So that will require quite a few code changes. —
Th
DJ
talk
contribs
09:50, 14 April 2026 (UTC)
Reply
Limit of 4 MiB would already be of huge help :) --
PantheraLeo1359531 😺
talk
07:33, 24 April 2026 (UTC)
Reply
The template "Logo" is confusing.
edit
Latest comment:
8 days ago
2 comments
2 people in discussion
I'm talking about
Template:Logo
. It currently is used for logos to be tagged for speedy deletion. I think it's confusing, and it must be discussed. I can't tag the template for discussion (only administrators can edit it), so I'm bringing attention to this issue here.
Template:Logo above threshold of originality
is clear, but
Template:Logo
is not.
Candidyeoman55
talk
19:47, 15 April 2026 (UTC)
Reply
{{ping|Candidyeoman55]]
Template:Logo
is just a redirect to
Template:Logo above threshold of originality
. Not sure I see the problem. Have you see it used by people who didn't intend that? -
Jmabel
talk
05:00, 16 April 2026 (UTC)
Reply
Rename of
Commons:Criteria for speedy deletion
edit
Latest comment:
6 days ago
1 comment
1 person in discussion
At
Commons talk:Criteria for speedy deletion#Move
I have suggested moving to
Commons:Speedy deletion
Crouch, Swale
talk
10:27, 18 April 2026 (UTC)
Reply
🎵 Webamp on Commons – listen to audio files in a classic Winamp-style player
edit
Latest comment:
5 days ago
1 comment
1 person in discussion
Hi all,
I'd like to propose adopting
Webamp
— a faithful in-browser recreation of Winamp 2 by
Jordan Eldredge
(MIT) — as an opt-in Commons gadget for listening to audio files. A working prototype is already running as a personal user-script and can be tested today by adding this single line to your
Special:MyPage/common.js
importScript
'User:Wilfredor/webamp.js'
);
Source under review:
User:Wilfredor/webamp.js
What it does
Adds a floating
button on every Commons page; clicking opens a draggable Winamp-style player
on top of
the current page (the page itself stays fully visible and usable underneath).
On any audio category page, adds a
Play this category
button next to the title that loads every audio file in the category as a playlist.
Lets each user define personal playlists in JSON at their own
Special:MyPage/webamp-playlists.json
and switch between them from the player's
File
menu.
Persists the active playlist between sessions: reopening the player picks up where you left off.
Why this should be a gadget
Commons hosts a sizeable corpus of audio (musical recordings, oral histories, bird and animal calls, spoken Wikipedia articles, NASA archives, etc.), but the default per-file