Jump to content

Commons:Village pump/Proposals

Add topic
From Wikimedia Commons, the free media repository

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

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

 

Start a new discussion

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



Mass upload proposal

[edit]
Latest comment: 8 days ago9 comments7 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 (https://catza.net/en/view/code/MCO_g_09_22/172054/) has the description: Escape's Rihanna, JW [MCO g 09 22] . album RuRok cat show Helsinki 2011-04-23 . cat Escape's Rihanna . breeder Escape's . FI . breed MCO . lens Sigma 85mm f/1.4 EX DG HSM . f/1.8 . 1/125 s . ISO 2000 . 85 mm . 12:21:57 . id 172054

So it can be uploaded as: Name: Escape's Rihanna, JW - MCO g 09 22.jpg 


== {{int:filedesc}} ==
{{Information
| Description    = {{en|Escape's Rihanna, JW [MCO g 09 22] . album RuRok cat show Helsinki 2011-04-23 . cat Escape's Rihanna . breeder Escape's . FI . breed MCO . lens Sigma 85mm f/1.4 EX DG HSM . f/1.8 . 1/125 s . ISO 2000 . 85 mm . 12:21:57 . id 172054}}
| Date           = 2011-04-23
| Source         = https://catza.net/en/view/code/MCO_g_09_22/172054/
| Author         = [https://catza.net/ Heikki Siltala]
| Permission     = All photos © Heikki Siltala. The photos are immediately available for both non-commercial and commercial uses under the Creative Commons Attribution 3.0 License. There is no need to get a more specific permission or to pay money. The attribution is Heikki Siltala or catza.net. The earlier www.heikkisiltala.com is also allowed.
}}

== {{int:license-header}} ==
{{CC-BY-3.0}}

[[Category:Photographs by Heikki Siltala (Catza)]]
[[Category:EMS Code g 09 22]]
[[Category:Helsinki cat show 2011]]

If possible the breed category could also be assigned through this code list: https://catza.net/en/list/breed/a2z/

What would be the best way to approach this upload? YukiKoKo (talk) 10:45, 25 February 2026 (UTC)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 (https://commons.wikimedia.org/wiki/Commons:Batch_uploading/Catza), so I will first wait how that will turn out. But I will have a look at Pattypan in case the batch uploading feature isn't possible. YukiKoKo (talk) 11:52, 27 February 2026 (UTC)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 Gnangarra 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
Hello and thanks. The best approach would be to create a new Batch upload request at Commons:Batch uploading and then think about how more Commons contributors could be made aware and motivated to help implementing these requests. One could for example write a scraper for the website and then use some of the mass-upload tools to get them all uploaded. Prototyperspective (talk) 10:33, 8 May 2026 (UTC)Reply

Allow the Upload Wizard to automatically convert MP4 to WebM

[edit]
Latest comment: 4 days ago139 comments70 people in discussion

We at Wiki Med have built the ability to automatically convert MP4 to WebM during upload via the Upload Wizard.[6][7]

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.

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.

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
Please make that restriction Trade (talk) 02:05, 12 May 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. OhanaUnitedTalk 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. —TheDJ (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. —TheDJ (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 —TheDJ (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. —TheDJ (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. —TheDJ (talk • contribs) 18:40, 2 April 2026 (UTC)Reply
    not sure if anyone has raised these:
    1. 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.)
    2. 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. Gnangarra 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
[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

Video2commons requirement waiver

[edit]
Latest comment: 17 days ago6 comments4 people in discussion

https://github.com/toolforge/video2commons/blob/f481dbb119aa1e018afb0b2a2f3dcf97a2f1664f/video2commons/frontend/app.py#L244

v2c is currently limited to only autoconfirmed users with 50+ edits.

could we introduce an additional condition to bypass the 50 edit requirement if needed? for example, by being autopatrol (which can be temporarily granted). https://github.com/toolforge/video2commons/issues/222 is the proposal on github.

i have seen sometimes new users upload videos when they participate in contests like com:wlm. now afaict 50 edits is a hard requirement that must be met.--RoyZuo (talk) 21:03, 6 April 2026 (UTC)Reply

I support some option for an override. This situation just came up for me in my staff capacity. Sdkb talk 16:57, 29 April 2026 (UTC)Reply
I submitted a pull request https://github.com/toolforge/video2commons/pull/370 . RoyZuo (talk) 17:13, 29 April 2026 (UTC)Reply

Increase data maximum of (tabular) data pages

[edit]
Latest comment: 1 day ago6 comments5 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. —TheDJ (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

Being able to host 16 MB would be nice. For example, it would allow people to upload a CC-BY-4.0-licensed-table with the population of every populated place in Spain every year and use that data on Wikipedia by extracting cells with Module:Tabular data. Strakhov (talk) 21:15, 15 May 2026 (UTC)Reply

The template "Logo" is confusing.

[edit]
Latest comment: 7 days ago3 comments2 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

@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
fixed ping - Jmabel ! talk 22:25, 8 May 2026 (UTC)Reply

Rename of Commons:Criteria for speedy deletion

[edit]
Latest comment: 28 days ago1 comment1 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: 1 day ago3 comments2 people 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 <audio> player makes browsing those collections painful — listeners have to click each file individually and there is no concept of a queue.
  • Treating a category as a playlist turns Commons categories into something usable for actual listening, the same way galleries make image categories usable for browsing.
  • As a gadget, it can be discovered and toggled from Special:Preferences#mw-prefsection-gadgets without users needing to touch JavaScript.
Proposed setup
  • Code lives at MediaWiki:Gadget-Webamp.js, mirroring (and replacing) the current user-script after review.
  • Entry in MediaWiki:Gadgets-definition under Browsing (or wherever the community prefers), opt-in / off by default.
  • UI strings moved out of the script into MediaWiki:Gadget-Webamp-* i18n messages (the prototype currently mixes English and Spanish labels; this would be cleaned up before promotion).
  • Webamp itself is loaded from unpkg.com on demand, only when the user first clicks the player button — zero overhead on regular browsing. If the community prefers to avoid an external CDN, the minified bundle (~1 MB) could be vendored on-wiki as a companion page (MediaWiki:Gadget-Webamp-bundle.js); I'm happy to prepare that variant if requested.
Notes & limitations
  • Plays anything the browser's <audio> element supports: OGG Vorbis, FLAC, WAV, Opus, MP3.
  • The player lives inside the page (not a popup window), so audio does not survive a full page navigation — that is a hard browser limitation. Opening any other Commons page reopens the player and the last playlist with a single click; the playlist itself is preserved in localStorage.
  • Renders into its own isolated <div>; the rest of the page remains fully interactive underneath.
  • Upstream project: github.com/captbaritone/webamp (MIT).
What I'm asking for
  1. General feedback on whether the community wants this as a gadget.
  2. Technical/security review of User:Wilfredor/webamp.js before any move into gadget space.
  3. A decision on the external-CDN question (load from unpkg.com vs. host the bundle on-wiki).
  4. An interface admin willing to deploy the gadget pages once consensus is reached.

Thanks! Wilfredor (talk) 14:55, 18 April 2026 (UTC)Reply

I can review the gadget code and upload it as a gadget once there are no objections. Nemoralis (talk) 03:10, 7 May 2026 (UTC)Reply
This post is almost a month old, I suspect there are no objections Wilfredor (talk) 20:16, 15 May 2026 (UTC)Reply

Proposal: Promote Commons:Upscaling to guideline

[edit]
Latest comment: 1 day ago31 comments12 people in discussion

Should Commons:Upscaling be promoted to guideline status? — Rhododendrites talk |  19:49, 23 April 2026 (UTC)Reply

Survey (upscaling)

[edit]
  •  Support as proposer. Issues associated with upscaling come up frequently on Commons. While many recent conversations focus on AI, and indeed AI-based upscaling tools introduce errors that traditional pixel sampling methods do not, the subject extends beyond AI, hence a stand-alone guideline makes sense. The guideline does not articulate firm rules, but discourages upscaling in general, and AI-based upscaling in particular, while allowing for standard exceptions. This is meant to be a starting point for a new guideline, not a final version; additional tweaks can always be made afterwards. — Rhododendrites talk |  19:49, 23 April 2026 (UTC)Reply
 Support as written or with Jmabel's change 1202473787.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:33, 23 April 2026 (UTC)Reply
 Support as written. I made one very minor edit for clarity to a passage I'd authored; I hope that is OK. If either of the two people who'd already voted (Pinging @Rhododendrites, Jeff G. has a problem with that edit, they should feel free to revert me. - Jmabel ! talk 22:07, 23 April 2026 (UTC)Reply
 Support as written. (Though we should probably clarify that this applies only to raster images - vector images can be scaled arbitrarily.) Pi.1415926535 (talk) 22:25, 23 April 2026 (UTC)Reply
Is scaling of vector images ever called "upscaling"? My understanding is upscaling necessarily involves the introduction of new information, so is relevant only to rasters. TEMPO156 (talk) 02:33, 24 April 2026 (UTC)Reply
 Support as written, this is creating an enormous amount of confusion and cleanup work, and usually detracts from educational value rather than adding to it. At the very least we need to be strict about requiring disclosure, though I also support the general discouragement of pointless use. I'd like us to consider whether we should also request that the model used (in the case of AI upscaling; I think it could be overkill to ask for software for more traditional methods) be provided by the uploader in the source information. TEMPO156 (talk) 02:30, 24 April 2026 (UTC)Reply
 On hold Reads well in English. As a guidance it should be availible in more than only English language. Can we at least set it up as a translatable page prior to promotion to Guidance? --Schlurcher (talk) 06:09, 24 April 2026 (UTC)Reply
That objection is reasonable, please let us provide at least a few translations here.
Another note, the nutshell text could be a bit more clear and to the point: I would expect many users to overread and misunderstand the meaning of "Most upscaled images are out of scope...": That is rather passive and weak language. Still passive, but pointing out user responsability: "Users are advised to not upload upscaled images on Commons, with exceptions..." or imperative: "Do not upload upscaled images, except when..." - just suggestions, maybe there are other ways to bring the message across. --08:46, 24 April 2026 (UTC) Enyavar (talk) 08:46, 24 April 2026 (UTC)Reply
@Enyavar and @Schlurcher: Translations will help. Imperative can help the most down the road.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:45, 24 April 2026 (UTC)Reply
Fair point. It's weak mainly because there are exceptions. IMO things like the nutshell text are suitable to work out after promotion to guideline -- is it a dealbreaker? — Rhododendrites talk |  14:12, 24 April 2026 (UTC)Reply
Great point, Schlurcher. I'm not experienced in setting things up for translation -- if you know how to do that, is that something you'd mind doing? — Rhododendrites talk |  14:10, 24 April 2026 (UTC)Reply
@Rhododendrites: I've requested help from the experts already earlier today: Commons:Translators' noticeboard#Commons:Upscaling Schlurcher (talk) 14:29, 24 April 2026 (UTC)Reply
Much appreciated. I should've done that. — Rhododendrites talk |  14:31, 24 April 2026 (UTC)Reply
Just as an update, Schlurcher, it has been set up for translation and translated into one other language so far (Chinese). — Rhododendrites talk |  23:58, 4 May 2026 (UTC)Reply
Changing to  Support. As my earlier concerns were addressed. --Schlurcher (talk) 06:42, 5 May 2026 (UTC)Reply
 Oppose Unfortunately some users treat guidelines as policy, and this one has a few issues which I'll detail below. - Alexis Jazz ping plz 12:57, 24 April 2026 (UTC)Reply
 Support with the understanding that it is guideline, not policy, and common-sense exceptions may apply. Phillipedison1891 (talk) 14:47, 15 May 2026 (UTC)Reply

Discussion (upscaling)

[edit]
Open this in mediaviewer. It's upscaled, and it's still tiny.

Consider the following:

  • This new guideline (which may get interpreted as policy or get promoted to policy in the future) doesn't grandfather in existing files, putting an unknown number of files at risk of deletion, even if the uploader is long gone, and we may fail to understand why the image was upscaled to begin with.
  • When superimposing text on an image, scaling up the image allows for higher resolution text.
  • When creating a derivative work that combines images (for example a collage), this proposal would force scaling everything down to the lowest common denominator. This is far more harmful than scaling up one of the images.
  • MediaWiki will not upscale for thumbnails of small raster images. As demonstrated, this makes for readability issues regarding captions and may not fit nicely in infoboxes.
  • People can set a different value for their default thumbnail size.
  • MediaViewer shows originals. If the original is very very tiny, too bad. You'll get massive black borders.

File:Gholam Reza Jalali 2017 (cropped).jpg is a file I uploaded, and it's upscaled. Of course this was a simple linear/bicubic/lanczos (don't remember) upscale. No additional detail, no hallucinations. Provided the original is also uploaded, there's no actual problem with pixel doubling/tripling/quadrupling and linear/bicubic/lanczos scaling.

Upscaling incorporated
This is as big as it's gonna get! I don't believe it's a crime if someone decided to inflate this to 200×200px. (yes SVG would be better in this particular case but that's not the point) Wow, long captions on small images are a really bad idea.

File:Mary Gay Scanlon, official portrait, 2018.jpg exists by virtue of upscaling, and it's widely used. This isn't one image. It's three images that I carefully stitched together. The bioguide image is only 175 × 263, the Facebook images were higher resolution crops. Combined they make a high resolution complete portrait. Pixel peepers may notice that the edges of the image (mostly out of focus anyway) are blurry.

Generally recommending against upscaling is fine, but use cases do exist. Treating all generative upscaling as "original artworks" (which is what they are, and which would make them fail COM:SCOPE in many cases), now that's a different discussion. - Alexis Jazz ping plz 12:57, 24 April 2026 (UTC)Reply

When superimposing text on an image, scaling up the image allows for higher resolution text. - The need to accommodate text seems like a reasonable addition to the guideline as plausible use case. Maybe you could recommend language to that end?
When creating a derivative work that combines images - Another rare but plausible use case I wouldn't be opposed to including.
Most of the other objections seem covered by allowing COM:INUSE exceptions. What we don't need are people uploading a bunch of upscaled images with no discernible use. Anyone can upscale an image on their own, up to the size they need. Picking a random bigger size (or multiple bigger sizes) for them just in case doesn't seem like a useful exercise. But certainly if a Wikimedia project wants a bigger version of an image for an infobox, etc., that's already covered. — Rhododendrites talk |  14:20, 24 April 2026 (UTC)Reply
@Rhododendrites, the proposed text requires "demonstrable consensus on a Wikimedia project to upscale a specific image for use on that project" which is a far higher standard than INUSE. I'll have to think about how changes to your proposal could be worded, but in its current state it's not acceptable to me. - Alexis Jazz ping plz 14:47, 24 April 2026 (UTC)Reply
That language was written with the many terrible AI upscaled images that have been in use on Wikimedia projects in mind. I'd gone around and removed several of those from enwiki myself, but some persisted in other languages where there were no apparent watchers of the articles. The idea wasn't to create an unusually high bar for the "old-fashioned" manner of upscaling with regard to inuse. Is "demonstrable" the biggest holdup? All of this said, after posting about the draft version of this guideline in multiple venues over the past few weeks, with mostly just positive feedback, I'm inclined to let this play out as-is. Again, this is meant as a starting point for the guideline, not a final version. — Rhododendrites talk |  14:59, 24 April 2026 (UTC)Reply

If I understand Alexis Jazz correctly, they are mainly concerned with very small images that they try to coax into at least thumbnail-sized imagery, which they want to continue to produce without first asking for a major consensus in each case's discussion page. If crazy rule-sticklers of the future demand to see majority votes on whether or not the article of Jalali may be illustrated with that image, then Alexis should be rightly worried. So yeah, that seems to have been largely overlooked, pardon the pun.
Think about it: Scaling up very tiny images to a thumbnail-size image (when done carefully, so that no speculative content gets added), should not be precluded by the guideline. I would propose another fundamental exception to the two that currently exist: "Exceptions to these rules include:

  • a demonstrable consensus ... etc. [marginal note: this even allows heavily AI-altered upscale versions, for example to illustrate our Upscaling guideline or an article about upscaling itself - I think this is why it is worded that way]
  • "a demonstrable need for an upscaled version of a low-resolution file to illustrate a subject in a Wikimedia project - this requires a faithful semblance between original and upscale version" [marginal note: faithful semblance are the key words here. I am neither a native speaker nor a lawyer, so I appreciate help to find better wording that would exclude examples like Pretti and Kulthum, but include the likes of Scanlon and Jalali. I would argue that the text resolution case is included in this provision, too.]
  • "upscaled images where the upscaled version is the only accessible version."

So, in this proposal I added another major exception which should placate Alexis Jazz. This second provision does not require a consensus, it requires only a single person stating that there is a need for such an upscaled image. The spirit of this provision is that when other users in that project disagree with the use of the upscaled image, the first person can be overruled by consensus and it is demonstrated that the upscaled version may not have been needed, after all. Subsequently, it may as well get deleted from Commons (but it also may not, if nobody poses a DR). There are multiple potential loopholes in the proposed second provision and we should all think about it carefully. I would say that it is in the spirit of the guideline to protect upscaled images like those of Mary Scanlon and Gholam Jalali when strictly needed. It is not in the spirit of the guideline however to host a multitude of upscaled/downscaled duplicates, for example to cover different thumbnail sizes. With regards to the final points of Jazz, I am more critical: Reasonable illustration is one thing; but if the software cannot properly display small images, then the software needs to be adapted - not the images. If a user sets his default thumbnail size to 500px, and it results in a visual unappealing non-upscaled image with a fat black border, I say again that's their own fault, and that they should cope. Same for the ill-fated MediaViewer - I configured that garbage out of my user experience. --Enyavar (talk) 20:35, 24 April 2026 (UTC)Reply

I suspect that at this point we may have two reasonable choices here:
  1. Pass the guideline with an "elastic clause" about there being a number of cases where upscaling is either inevitable or at least acceptable, and plan to flesh that out later through normal discussion.
  2. Postpone a vote till we can sort that out.
I'd opt for the first. I don't see a lot of these examples as very controversial, and I'm pretty sure we'd get consensus on them, but I'd rather move more rapidly to adopt a guideline on the main point which is that we really don't want a ton of upscaled images, especially not badly AI-upscaled images.
By the way, the FCA Darmstadt case brings to mind another case where we simply are not dealing with issues of photographic accuracy: a mainly decorative background for an infographic. For example, event posters within the Wikimedia community are typically uploaded to Commons. I don't see any problem if one of those used an upscaled image as part of its design. - Jmabel ! talk 23:40, 24 April 2026 (UTC)Reply
Jmabel, I understand your desire to move quickly, I too hate AI upscales in educational settings with a passion. But implementing guidelines with issues is a bad idea. I hope I'll find the time tomorrow to make a proposal of my own that has been sitting the shelf for a while. @Rhododendrites, I understand seeing my criticism now "after posting about the draft version of this guideline in multiple venues over the past few weeks, with mostly just positive feedback" must be frustrating. I don't think I've seen any of those, I'm not quite omnipresent. @Enyavar, I respect your train of thought about the software needing to be adapted. That is a solid point in theory. In practice many feature requests will rot for literally over a decade on Phabricator/Community wishlist though. It's just not practical. - Alexis Jazz ping plz 00:57, 25 April 2026 (UTC)Reply
@Alexis Jazz: There's an handy way to solve the grandfathering issue: use the first time of ChatGPT being available to the general public as threshold date (November 2022). Anything uploaded before and where upscaling happened is not subject to the proposed strict rules, anything younger is, to combat these iterations of AI slop. Regards, Grand-Duc (talk) 00:07, 25 April 2026 (UTC)Reply
Did ChatGPT start producing AI slop upscaled images in November 2022 already? And even if so, why is that the reason that I may no longer retouch images in Gimp for perspective correction? No, I don't think we should bake any specific dates into a guideline about which type of content is allowable and which is not. --Enyavar (talk) 06:21, 25 April 2026 (UTC)Reply
@Enyavar: I may no longer retouch images in Gimp for perspective correction? What are you referring to? The page is quite specific in calling that out as an exception. I know because I wrote that part. - Jmabel ! talk 03:10, 26 April 2026 (UTC)Reply
My example (perspective correction) is on the whitelist only thanks to the Incidental expansion section - the rest of the page and especially the summary condemns upscaling In general. We want to combat sloppy AI use (which needs to be blacklisted as false/disinfo). We also want to prevent unnecessary upscaling of regular photos to 4K resolution (mostly for space-preservation and project scope reasons, not because it is false) but on this issue we're wading into a grey zone already. Alexis Jazz wants to know how large that grey zone really is, and have provisions that make it less arbitrary to decide which reading of the text is used. So, do we want to prevent upscaling of tiny images to thumbnail-size? Do we want to prevent upscaling of thumb-nail-sized images (200px) to regular-sized ones (less-than-1k)? I think these uses of upscaling may be allowed if the image is needed to illustrate a subject in a way that the original cannot, as long as the upscaled image's content is a faithful semblance of the original.
So we don't need a grandfather clause, we need clear wording on what is allowable. --Enyavar (talk) 12:20, 26 April 2026 (UTC)Reply
We do need to be particularly cautious about the use of generative AI tools for upscaling small images, given the potential that the AI model will introduce details which weren't present in the original. Traditional interpolation-based scaling techniques are much less prone to this type of failure and should be preferred for this task. Omphalographer (talk) 03:16, 28 April 2026 (UTC)Reply
A better threshold date would be August 2022, with the release of Stable Diffusion. --Carnildo (talk) 23:37, 27 April 2026 (UTC)Reply

Encyklopedie Známek

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

Dílem autora vzniká Autentická osobní kniha s Filatelistickou sbírkou nesoucí Historickou pravdu a zároveň tak snad tvoří odkaz pro generaci budoucí 🐝 ITják Patrik (talk) 21:19, 25 April 2026 (UTC)Reply

@ITják Patrik are you trying to advertise the mentioned encyclopedia? Or what exactly is it that you would like to discuss here? Nakonana (talk) 12:41, 26 April 2026 (UTC)Reply

Cropping with "book" template

[edit]
Latest comment: 14 days ago6 comments2 people in discussion

We've had a series of conflicting requests over what CropTool should do with the {{Book}} template when extracting images from a PDF. On the one hand, a crop of a file that uses {{Book}} is almost never still a book. On the other, there seems to be no simple, systematic transformation that CropTool could do that would produce something more useful.

For the most recent relevant discussion that I'm aware of, see Special:PermanentLink/1206649512#About_a_CropTool_bug (exchange among Alex brollo, Bawolff, Pigsonthewing and myself. Right now it looks like its simply broken but, understandably, Bawolff would like to know what is actually desired before attempting a solution. I'd like to see if we can form a consensus.

The discussion linked in the previous paragraph raises several possibilities as to what CropTool could do; I'd like to see if one of these stands out as most popular.

  1. Just leave the template as it is and do the usual CropTool things with {{Extracted images}} / {{Extracted from}}. (E.g. the minimal bug fix from where we stand.) Advantage: simplicity. Disadvantage: unless the user edits, resulting crop is almost certainly initially misdescribed and not marked for any sort of fix.
  2. Like 1, but also add a maintenance category (possibly via a template) so that these are more easily spotted. Advantage: (slightly less) simplicity, more chance of followup. Disadvantage: resulting crop is still initially misdescribed, though with a slightly better apparatus for followup.
  3. Like 2, definitely done with a template. Template also adds parameters for name of the account that used CropTool and a date. Advantage: allows searches that might further facilitate followup. Disadvantage: resulting crop is still initially misdescribed, though with a yet better apparatus for followup.
  4. Like 3, but have the template create further maintenance categories sorting these by month and by responsible user. Advantage: stronger support for followup. Disadvantage: resulting crop is still initially misdescribed, and template/category aspect gets a little complicated.
  5. Like 4, but with a bot (maybe opt-in) to remind user on their user talk page if the "book" template is still there 24 hours (or whatever) after the crop. Advantage: yet stronger support for followup. Disadvantage: resulting crop is still initially misdescribed, and we are definitely out of the realm of simplicity.
  6. [This is paraphrased from Alex brollo, who may want to reword] CropTool would provide a preview of the file information page in an editable textbox, allowing the user to fix errors if any or even to completely rewrite the text as, for example, {{Information}} or {{Artwork}} before saving. Advantage: allows (but presumably does not force) fixing things on the spot. Disadvantage: if the user doesn't want to deal with it there and then, makes them go through an extra step and provides no apparatus for later followup; also, probably about a complex to implement as #4.
  7. #6 could be combined with any of #2-5. The text in the editable textbox could reflect one of #2-4, and the bot mentioned in #5 would still be a possibility.

I know that's a lot of cases, but a quick straw poll could help work out where to go with this. - Jmabel ! talk 20:25, 1 May 2026 (UTC)Reply

@Jmabel There about 1400 files into Category:Pages using Information template with parsing errors, I'm trying to classify them. By now I found these variants:
  1. pages with balanced curly brackets, coming usually from contributors mistakes;
  2. pages with unbalanced curly brackets:
    1. pages lacking first rows of a Book or Information template, coming usually from a bugged CropTool upload;
    2. pages lacking last rows of a Book or Information template, coming from unknown issues.
Group 2.1 usually can be fixed by BrolloBot. Alex_brollo Talk|Contrib 17:50, 2 May 2026 (UTC)Reply
issue sorted out by an edit above
@Alex brollo: I don't follow from your numbering above which would be "Group 1.1" - Jmabel ! talk 17:59, 2 May 2026 (UTC)Reply
@Jmabel: Ouch... Groop 2.1, I fixed my mistake. I apologyze. Alex_brollo Talk|Contrib 18:18, 2 May 2026 (UTC)Reply

Straw poll

[edit]

Project scope rewrite

[edit]
Latest comment: 1 day ago5 comments4 people in discussion

Commons:Project scope#Excluded educational content needs some clarification and rewrite.

News, general weather reports, and the like.

journalistic photos audios and videos are all within the scope. there are also many files/pages related to weather, such as typhoon maps, temperature and precipitation data... RoyZuo (talk) 19:12, 2 May 2026 (UTC)Reply

  • Should be OK here if it is in an inherently image or multimedia form, but (for example) we don't want someone personally creating and uploading a "talking head" newscast. - Jmabel ! talk 03:53, 3 May 2026 (UTC)Reply
This section is meant to refer to text only. Climate and weather data and maps were always considered as in scope. GPSLeo (talk) 06:08, 3 May 2026 (UTC)Reply
for people who already know it, yes.
but for new users, they might get the wrong idea and do not upload. RoyZuo (talk) 09:27, 5 May 2026 (UTC)Reply
Why not just remove the line? Wikinews has been closed recently. Until then, Wikinews meant that 1) supportive materials displayed on Wikinews pages were automatically in scope on Commons, and 2) text content that would be in scope of Wikinews would be excluded from Commons to avoid duplication. Regarding point 1, I think it makes sense to keep them for now - we might want to clarify that Commons continues to host content that was in scope because of Wikinews pages. (We could revisit it after a few years, though.) Regarding point 2, while the duplication won't happen now, and some of that kind of text content may be accepted on other sister projects, Commons doesn't have to make extra space for it in my opinion. Over all, my understanding is this leaves us in a neutral position - we don't have to treat news content and supportive content for news differently, so no complete acceptance nor complete rejection. whym (talk) 03:45, 15 May 2026 (UTC)Reply
[edit]
Latest comment: 13 days ago1 comment1 person in discussion

See Commons talk:Featured galleries (initial proposal at Commons:Village pump#Featured galleries?) LetmeEditit (talk) 10:48, 3 May 2026 (UTC)Reply

Disallow upload of new .xcf files

[edit]
Latest comment: 5 days ago13 comments8 people in discussion

.XCF is a image file format used by the GIMP image editor to represent an image editing project, analogous to PSD for PhotoShop. Historically, this format has been supported by MediaWiki as an image file type. There are a small but nonzero number of these files on Commons (currently around 1703); see Special:Search/filemime:image/x-xcf for a list.

Per phab:T196054, some of the libraries used by MediaWiki are unable to open XCF files created by Gimp 2.10 or later; these files appear with empty thumbnails, or fail to render thumbnails at all. Gimp 2.10 was released in March 2020, so, unless users are using a 7+ year old version of GIMP, any newly created XCF files they upload to Commons cannot be used on Wikimedia projects.

Beyond this, though, XCF is not a great format for use on wikis. It is a project file format, not just an image like a JPEG or PNG. As such, it can contain material which is only visible in GIMP (like hidden layers or content outside the viewport) and which cannot be practically reviewed on Commons. Additionally, the files cannot be opened directly in the browser or on mobile devices, and typically require GIMP to be viewed on desktop computers.

As such, I'd like to propose that we disallow the upload of new files in this format, either by making a request at Phabricator or by adding an edit filter to block the upload of these files. Users should be encouraged to instead upload images in standard image formats such as JPEG or PNG.

Omphalographer (talk) 19:33, 7 May 2026 (UTC)Reply

 Oppose. @Omphalographer: Newer versions of GIMP have an option to save without the more efficient 2.10 compression. We could just require use of that option.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:21, 7 May 2026 (UTC)Reply
The option may exist, but people aren't using it - try sorting the results of the search I linked by creation date. Probably >95% of uploads fail to render. Omphalographer (talk) 20:32, 8 May 2026 (UTC)Reply
 Comment is there any advantage of XCF over TIFF for Commons' purposes? - Jmabel ! talk 20:03, 8 May 2026 (UTC)Reply
XCF files keep information (layers, etc.) which TIFF files do not. Yann (talk) 20:05, 8 May 2026 (UTC)Reply
TIFF handles layers fine, in my experience. Is there something XCF can do with layers that TIFF can't? - Jmabel ! talk 22:28, 8 May 2026 (UTC)Reply
@Jmabel: Sorry, I didn't see your answer. It seems to me that a TIFF file can contains several images, i.e. several versions of the same image, or different images altogether, but these are not layers like XCF can store. Or may be I am wrong... Yann (talk) 19:50, 11 May 2026 (UTC)Reply
I know Adobe uses layer transparency in TIFF, but it might be non-standard. - Jmabel ! talk 20:14, 11 May 2026 (UTC)Reply
Layers are really just several images put together plus some metadata about how they interact. XCF goes beyond just layers though. Bawolff (talk) 21:09, 11 May 2026 (UTC)Reply
  • .xcf should only be used/uploaded as a project file for other Commons users to create derivatives. But many of the existing files seem to be using .xcf accidentally.
    I wasn't aware that TIFF can handle layers. Guess we could simply use TIFF for this purpose. - Alexis Jazz ping plz 22:48, 8 May 2026 (UTC)Reply
 Oppose Great to see xcf files are a supported file-type. Standard format of the open source GIMP unlike the proprietary Photoshop and great for transparency, editability, collaboration, etc. However, looks they are heavily underused. Prototyperspective (talk) 23:33, 8 May 2026 (UTC)Reply
 Oppose I think filetypes should only be disallowed if there are grave issues like security issues (e.g. malicious code), or legal problems. On the other hand, I would love to see allowing BLEND files, but there, code is also a problem --PantheraLeo1359531 😺 (talk) 08:25, 11 May 2026 (UTC)Reply
I think its a good thing that people can upload an xcf as a sort of source code of the file, to allow people to make further edits to it later. I dont think display of xcf really matters. Bawolff (talk) 15:52, 9 May 2026 (UTC)Reply

Storing model predictions in structured data

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

I'm not a particularly active common user so please forgive me if this is out of line or an obviously bad idea.

I've seen and worked on many projects that tried to re-use commons data for various projects. Generally these projects want to filter out nudity (and maybe other categories of content). To do this we can run the images through a model that predicts if it contains nudity. But it seems to me that this information would be useful to other people interested in commons. To that end I thought we could contribute back the model score to commons via structured data (maybe make a new property for the particular model being used or something more complicated). A bot could be made to score the most prominent images.

This could potentially also be used for other model prediction tasks. For example, ShieldGemma 2 can categorize an image into the categories Sexual, Dangerous and Violence.

I appreciate that similar proposals have seen push back over fears about censorship. This would be a totally optional piece of data re-users could tap into. Also, such models have greatly improved since 2017.

To be clear I'm only asking if storing such data in this way is ok. I can handle the creation of a bot and the actual subsequent work/compute if people are ok with it. If the data is bad for a particular image people can just delete it.

BrokenSegue 14:54, 11 May 2026 (UTC)Reply

@BrokenSegue: I'm neither supporting nor opposing this at this time. May I suggest that you conduct an experiment of running this on, say, 2500 random files and publish the results so that the Commons community has a chance to weigh in on whether they think this score would be useful? - Jmabel ! talk 18:23, 11 May 2026 (UTC)Reply
As for the means of storage: yes, if we were to add scores like this, that would seem to be the correct mechanism, but I'd really want to see something where adding scores from a particular system requires approval. The possible censorship risks aren't only with respect to nudity or violence: I could imagine someone wanting to add something highly politicized, or targeting an ethnic group, etc. - Jmabel ! talk 18:27, 11 May 2026 (UTC)Reply
ok. I will produce a sample. I was imagining each model would have to be approved one by one (not just arbitrary model scores). BrokenSegue 19:21, 11 May 2026 (UTC)Reply
Ok I ran a model against a bunch of images. You can see the random results here User:BrokenSegue/NSFW-Test but because there were so few actual NSFW images in that set I also ran it against a selected set of images which you can see here User:BrokenSegue/NSFW-Test-Nudes. It's definitely not perfect but any vague concept like "nsfw" or "porn" or even "nudity" will have shades of gray (and obviously just errors). BrokenSegue 05:17, 12 May 2026 (UTC)Reply
The small number of nudes in the random sample means it's a good representation of how the model will handle Commons images at large. Setting a threshold of 0.1, by my count there are two clear true positives, one debatable true positive, five clear false positives, one debatable false negative, and 491 clear true negatives. Raising the threshold to 0.5 eliminates all but one false positive, but turns the debatable positive into a debatable negative; raising it to 0.9 eliminates the false positives but also one of the true positives. Overall, it's doing what I'd expect: most positive results are false positives simply because true positives are so rare in the underlying data. --Carnildo (talk) 21:56, 12 May 2026 (UTC)Reply
I think there's still value even if we set the threshold to 0.9 even if it misses many true positives. BrokenSegue 04:15, 13 May 2026 (UTC)Reply
Wikimedia Commons content descriptor (P14416) has recently been created for this purpose. HyperAnd [talk] 07:49, 12 May 2026 (UTC)Reply
oh thanks! @Bawolff: I'm curious if you think there's an opportunity to merge these efforts. I can produce a mass list of model predicted NSFW images. Though personally I would prefer to also store the scores (we could add that as a qualifier along with a qualifier indicating the labeling was done using a model like in File:Lucy_by_Bystro.jpg, I can handle that proposal process). BrokenSegue 14:01, 12 May 2026 (UTC)Reply
@BrokenSegue: I think adding a score to each image is a really bad idea. Adding Wikimedia Commons content descriptor (P14416) as a flagging to those that fall into the topic constraints of this new property is a better idea, that I could support. In cases where such a flagging is performed, it could be helpful to add the score as a qualifier along. --Schlurcher (talk) 14:49, 12 May 2026 (UTC)Reply
oh yeah the score would be a qualifier on the content descriptor statement (along with determination method -> identifier of the model used) BrokenSegue 14:57, 12 May 2026 (UTC)Reply
@BrokenSegue: It seems useful, but I would hope whatever process we have to get these into SDC will allow a human to override the identification of a given file as potentially needing to be blurred on this basis. There needs to be an established process for overriding false positives.
Also: could we try this on one other batch of photos? Could you run this on the files that are directly in Category:Figureheads of women? I'd really be interested to see how it scores those. - Jmabel ! talk 05:02, 13 May 2026 (UTC)Reply
sure thing. I'll run that.
And yeah for overriding anyone could just delete the statement from the structured data. BrokenSegue 13:21, 13 May 2026 (UTC)Reply
@Jmabel: User:BrokenSegue/NSFW-Test-Figureheads. But I don't want to get too over-indexed on this particular model. There are many of them and I chose this one kinda arbitrarily. In this sample a 0.9 threshold labels a single image as NSFW. BrokenSegue 13:32, 13 May 2026 (UTC)Reply

Leveraging SD for book categorizations (PDFs, déjavus, categories, )

[edit]
Latest comment: 5 hours ago4 comments3 people in discussion

I am sorry about the desolate state of our current categorization schemes for books. Millions of digitized books are currently hosted on Commons. And well-meaning categorizers/patrollers have begun categorizing them, according to the many available criteria and metadata available for most of these books.

We do have options: Books by language (objective criterium), Books by author/publisher (objective as well), Books by date (typically: publishing date, objective), Books by title (there are issues with translated books), Books by subject (highly subjective criterium, but also the most valuable one(!), see below), Books by location (WILD mixes of "currently in a library in", "published in" and "about subject in"), Books by color (no kidding, sigh), Books by type/genre (often more specialized variants of "subject", and just as relevant/valuable)...

The issues with Books by subject are fairly obvious. Let's take "about medicine" for example, there are sub-subjects like "about medicinal plants", "about surgery", "about Cholera", "physician biographies" and so on. How to make these fine distinctions of topic is entirely up to user discretion, and I'm not arguing to change that, as long as the grouping makes some sense. (Even niche subjects should group together more than a single book.)

Where I am critical of our current system, is when we mix-and-match our categorization criteria. I think it makes sense to couple publishing dates and publishing locations, as in 1852 books from London. All these books should still be categorized by other criteria, of course, and I personally favor "by author" and "by subject" as the most relevant other categories any books should have. Problems may arise when the date gets coupled with the subject, like "1852 books about medicine": this example requires "... about surgery" as additional category, to remain categorized by some subject, after medicine has fallen to medicine-by-year. When that is not done, a book will not get finer categorization (by subject, language...) unless found and categorized by accident. The same problem again with medical books: "...by language". This book is about medicine, but in French, so obviously it will not be further subcategorized by medical subject, location or date. Meanwhile this book is about medicine, but from France, so it will not be subcategorized by language, medical subject or date, either. Meanwhile this book is about medicine, but specialized in surgery, so among all the medical books, it will not be subcategorized by language or date. The same is true for all kinds of other subjects: German-language books about World War I (language+subject) and 1933 books about World War I (date+subject) are cannibalizing each other and completely prevented further subcategories like Books about medicine in World War I and Books about naval warfare in World War I (more specialized sub-subject groupings that would actually be of interest). There are French-language books about Italy that are simultaneously Books about Naples, but will only be categorized into one of the two specialized "books about Italy"-categories and never the other. And so on.

The resulting category trees in which I have to search for a 19th-century Italian book about surgery are literally hap-hazard as a result. The book I'd hope to find may be categorized (and rightly!) as a "book about surgery", it may be "1892 books from Rome", it may be "1892 works in Italy", it maybe it may be "19th-century Italian-language books", it may be "Books in the New York Public Library", it may be "1892 books about medicine", or it may be uncategorized altogether except from being filed by an accession number in the "Medical Heritage Library". Who knows. And it's not as if the Search function would yield better results.

The only way I can think of, that could help disentangling this mess, would be Structured Data, but the current process of adding SD is even more hap-hazard than the categories. With some luck, a file has been assigned one or two entries of SD, and maybe the pairs of statement/value were chosen and used correctly. Assigning SD takes a multitude of time compared to assigning a category, too. What I'd like to see is: When clicking on "Structured Data", the user can switch away from the current standard formula that allows to input a free association of random structured data properties. The option that I imagine, would be the choice to switch to a "book formula". That formula would preferably come pre-filled with all structured data that is available from the Book-Template which is available in the file description:

  • |author = :Roose, Robson, 1848-1905 / :Royal College of Physicians of Edinburgh from the template gets automatically translated into Q36180 (writer): Roose, Robson or Q482980 (author): Roose, Robson, or Q138951094 (authored by): Roose, Robson. The Royal College would likewise get a second author-entry.
Important note: someone familiar with SD needs to codify the name of the prefered standard qualifier/property/statement/descriptor or however the Wikidatians call the name that describes the value. That way, regular non-SD/non-WD people can be enabled to just fill in the author(s) name(s) and not choose the wrong qualifier by accident. They would only be able to mess up the data entry itself. In the above case, it should be changed by the editor into "Robson Roose"; and the editor would need to decide whether or not the "Royal College of" is really a co-author. Many books do have many "authors" listed in the template that were actually just publishers, book owners or original authors of an adapted work; but that would be up to the user to decide.
  • |publisher = London : H.K. Lewis gets automatically translated into Q1361759 (place of publication): London and Q2085381 (publishing house): H.K. Lewis
Note again: it is important that the correct qualifiers in the "book formula" are preset and cannot be changed. If the data taken from the template is wrong for some reason, the user doing the input should preferably change it. But: An imperfect value of "H.K. Lewis" or "H. K. Lewis" or "HKL" etc. that is just a text entry not matching any wikidata entry, is still more valuable than NO value at all; and a later editor can still change it into the evidently correct one, which is in this case probably Q121027510 (H. K. Lewis & Co. Ltd.).
  • |publication date = 1888 gets automatically translated into Q1361758 (date of publication): 1888.
Again a note: periodicals may often have wrong entries, like the date of the first issue. In general, the template does provide good data however, and again, a possibly incorrect date can be changed by a another editor later, and should in my opinion be preferable to no date at all.
  • Subject... Hm. In my chosen example, |description = are multiple lines, and only the final line has any valuable information for this field - it reads
    Subjects: Gout     . My suggestion would be to automatically input the property Q26256810 (topic): Gout. The user should be allowed to indicate multiple subjects: A book about Clergymen in the British Naval Forces during WW1, would require multiple topics: "Anglican priests / Royal Navy / World War I".
  • |language = English should be automatically translated into Q315 (language): English or Q34770 (language): English or maybe Q118779961 (publication language): English or whatever the correct qualifier is deemed to be right, by those who understand SD.

Those six above would be the most important metadata that users should be prompted to input. Obviously, "Title" and "subtitle" are also essential properties, but they would just be filled with free text (unless every book title gets their own wikidata entry, I have no idea?). There are additional available parameters in the description page template for books, but those are situational and would more often be empty than filled: "illustrator" is only important for illustrated books; "volume" and "series title" for books/series with more than one file; "source", "accession number", "OCLC" and "permission" must be provided by the institutional digitizers and cannot be determined later.

The benefit: Books that have that hypothetical structured metadata, are not just eminently more searchable, they can also be crawled by some book-bot that automatically assigns the missing categories.

And if this idea works with books, other groups of files can similarly be structrured and then get categorized. --Enyavar (talk) 18:44, 11 May 2026 (UTC)Reply

Books about archaeology are currently sorted either by language or by year. Nota bene: never both, EITHER-OR. To find a book about the archaeology in a specific country, I have to check all language-subcategories AND all year-subcategories.
This is the peak of absurdity. --Enyavar (talk) 10:20, 16 May 2026 (UTC)Reply
Paradoxically I guess it's much easier to obtain structured data from categories than from strings in Book-Template parameters. By the way, date properties in Wikidata (such as publication date aka P577) don't use items but a specific datatype: time. Strakhov (talk) 12:03, 16 May 2026 (UTC)Reply
urrently sorted either by language or by year. Nota bene: never both, EITHER-OR. Sounds like an error by the people who are uploading them, and one that should not be terribly hard to fix, though a bit time-consuming. If a small number of people (or bots) are repeatedly responsible for this, you might try pinging them here and see if they will help clean this up. - Jmabel ! talk 17:08, 16 May 2026 (UTC)Reply

Publicizing Commons:Uploading works by a third party as guideline, II

[edit]
Latest comment: 4 hours ago5 comments3 people in discussion

Commons:Uploading works by a third party

Hello, there was an exchange about this subject in February 2026. Here's the archive link: Commons:Village_pump/Proposals/Archive/2026/02#Publicizing_Commons:Uploading_works_by_a_third_party_as_guideline (I wanted to actually transclude it, but that would have added an archive message box among other things, so it'll remain as plain link).

I wanted to inform you that the German translation of Commons:Uploading works by a third party is henceforth done (no machine translation, fully manually). The EN source page seems to lack some code for adding the ninth section "Resolved issues" to the translated page, otherwise, the remainder is done. Can we proceed or should there be even more translations done before that prospective guideline gets passed? Regards, Grand-Duc (talk) 11:07, 15 May 2026 (UTC)Reply

Ah, I should ping the then involved people - @Yann, Jmabel, Abzeronow, HyperAnd, and RoyZuo: , regards, Grand-Duc (talk) 11:11, 15 May 2026 (UTC)Reply

  1. i dont see how its content is not already covered by other policy or guideline pages including com:l com:dw...
  2. it contains unnecessary, problematic and esoteric jargons such as RTFM.
...
see Commons:Village_pump/Proposals/Archive/2026/02#c-RoyZuo-20260220151200-Grand-Duc-20260218200300. RoyZuo (talk) 11:17, 15 May 2026 (UTC)Reply
Of course, the content of COM:THIRD is already covered elsewhere. That's by design, especially as Jmabel's text is IMO construed in a way to comply to the meaning of the wording "guide-line" by the letter. It's an amalgamation and condensation of information spread over several sources. And this is pedagogically a sound thing: it removes the need for any interested party to search for information morsels among possibly currently non pertinent data. COM:L for instance elaborates on the background of licenses, whereas COM:THIRD simply stresses the actual needs of our project: the actual free license. Similar case for COM:DW: lots of explanations for and about actual use cases there (like toys and pop culture), THIRD focuses upon the main points with the most relevance (broken down to the core: Q, "Somebody else made something, how to proceed? A, "Get a free license release!").
As for why I said "to comply to the meaning of the wording "guide-line" by the letter": for a complex subject, THIRD provides a step-by-step guide along a line of thought. It is necessarily long, as that subject, copyright, has a huge amount of factors that need to be observed.
In February, you wrote: "i think the best method to educate newcomers is to write as succinctly as possible, and make short explanatory videos. that's way more engaging and informative than a long page of texts." I agree to disagree, especially on the point of videos. To explain matters that are fundamentally text-based, videos are IMHO not a really suitable medium. Videos are strong in showing geometric relationships of stuff in a three-dimensional area (e.g. model making or Origami) or for showing "production" processes (painting [think en:Bob Ross], developments and behaviours of living beings [slow motions of e.g. bombardier beetles or snapping shrimps, time lapses of flowers blooming or bamboos sprouting] or physical phenomena [examples: videos on the "Slow Mo Guys" YouTube channel]). But translating textual content into a visual or audiovisual depiction is not really straightforward. Furthermore, a video doesn't present itself for parsing information that may be available in the middle of the presentation. In texts, you can skim-read until you're at a section that holds the info you want, and you can easily stop and and resume your reading at any moment. For videos, you're much more committed to watching because interrupting and going back and forth is not as easy as in reading. The translation from text to visuals and maybe sounds can also be detrimental to memorisation (similar to the sardonical saying "Death by PowerPoint"). And while I agree that a succinct writing is desirable, I didn't see much that wasn't succinct and not needed for the subject while translating THIRD. Copyright isn't something that presents itself very well to gamification, so I'm currently lacking the imagination where THIRD could be made more engaging.
About the critique of "unnecessary, problematic and esoteric jargons": I'd like to see more examples besides "RTFM". That one should be already part of the English or even international vernacular, cf. en:RTFM. I don't really understand this issue at the moment. Regards, Grand-Duc (talk) 15:18, 15 May 2026 (UTC)Reply
 Comment I have no real objection, while I would like to have this page translated to more languages. Yann (talk) 17:34, 16 May 2026 (UTC)Reply

Allow non-controversial deletions by non-administrators

[edit]
Latest comment: 1 day ago9 comments6 people in discussion

The deletion request backlog currently stands at 10929 open requests. Many of these requests are non-controversial but have been in limbo for (in some cases) months due to the huge workload for sysops on here. I propose to create a group for trusted users, similar to the file mover and image reviewer groups that already exist. This role would grant the delete right (but not undelete). There would be strict rules allowing people in this role to delete content in much more limited circumstances than is allowed for administrators. This would be in the spirit of the current provision allowing non-administrators to close non-controversial requests as kept. As a starting point, I suggest the following criteria:

  1. The deleter must not be the one who nominated the file for deletion.
  2. The deletion request must have been open at COM:DR for 14 days (twice as long as the standard minimum period), and
  3. The deletion request must not have received any votes for  Keep.
  4. The file must not be COM:INUSE.

The only wrinkle is whatever software security risk is inherent in the delete ability. I think it's a good idea to take some of the routine deletion workload off of administrators, so they have more time to focus on other tasks that require a greater level of community trust. Phillipedison1891 (talk) 14:40, 15 May 2026 (UTC)Reply

 Comment in a non-controversial case, you don't have to be an admin to close a DR. From Commons:Deletion requests: "Non-admins may close a deletion request as keep if they have a good understanding of the process, and provided the closure is not controversial." This includes deciding the DR as "keep" when the nominator is now in agreement.
If a non-admin decides that DR as delete, then an admin still has to do the actual deletion. We could easily create a category for DRs that are closed as "delete", which would call admins' attention to these; maybe add subcats for who closed the DR, so admins can more easily decide if that is someone they simply trust, or they'll want to do one last review. This might be a better approach than giving deletion rights to more people. - Jmabel ! talk 15:58, 15 May 2026 (UTC)Reply
I read the quoted passage as allowing non-admins to close a uncontroversial request as keep, but never as delete. Phillipedison1891 (talk) 16:07, 15 May 2026 (UTC)Reply
Deletion requests by uploader's shortly after upload (for files that are not in use) seem like ideal candidates either for such a deletion category or for non-admin-deletions as they would actually qualify for speedy deletion but were just mistakenly tagged for a regular deletion.
Netcopyvios might also be good candidates. Nakonana (talk) 17:27, 15 May 2026 (UTC)Reply
One of the main reasons against this was, that there are simply no users we would trust with such a right (except the G7 self delete), but not with full admin rights. There are also huge backlogs they only require rollback and patrol rights to work on them, but no one is doing this. GPSLeo (talk) 18:06, 15 May 2026 (UTC)Reply
Probably a no for me. Along with blocking, deletion is the most sensitive button we have around here. The RfA process is in large part an evaluation of a candidate's judgment to make those closures, and that's in part why standards can be strict. If someone wants to propose unbundling deletion from the admin toolkit and create a new role that can close DRs without e.g. blocking, that's fine, but no to having users with no prior vetting close DRs except in cases of utterly uncontroversial (procedural) keeps. If an admin still has to be involved (as with doing the actual deletion), it's still the admin who is fundamentally responsible for the act of deletion, which means they have to form their own judgment anyway and no time is actually saved (basically the point Jmabel made, which is also one of the reasons proposals for unbundling typically fail (at least over on enwp)). — Rhododendrites talk |  18:22, 15 May 2026 (UTC)Reply
From my perspective, there are a lot of rights in the standard sysop bundle that present a far more severe risk than the ability to delete. browsearchive, deletedtext, deletedhistory give access to stuff that may have been deleted for privacy reasons, editinterface can turn the entire site into a phishing operation, and many more. If we want to lower the threshold for adminship and recruit more, that's fine, but the current situation where standard deletion cases hang around for six months or longer is not sustainable. Phillipedison1891 (talk) 18:53, 15 May 2026 (UTC)Reply
Sorry, by sensitive I mean the things that tend to most influence requests for adminship (like a "sensitive issue"), not the sensitivity of the actual data. — Rhododendrites talk |  18:57, 15 May 2026 (UTC)Reply
  1. just make more people sysops.
  2. to let the community be comfortable with making more people sysops, some reforms are needed (i think en:User:Larry_Sanger/Nine_Theses#8._End_indefinite_blocking. has many good ideas.)
    1. change sysops to temporary positions, or
    2. appoint new sysops only temporarily (like probation).
  3. also a long shot is if commons can use some software that's better suited for managing a large amount of files.

    commons as a media repository is just like the library of congress / british library, or a stock/news photo agency like getty / afp pictures, or a user-generated content website like flickr, yet deletion/undeletion, which is crucial to managing files, especially for users who have contributed a large number of files, is restricted to 200 sysops, most of which are not actually very active. (special:permalink/1214362291 in this stat, the top 20 names have a combined score exceeding 90% of the total. Total score of everyone: 53,965. 90% threshold: 48,568. Cumulative score of top 20: 48,570. The cutoff occurs at: 20. Jmabel (473).)

    can you imagine only 20 people managing showing/hiding files to the public at loc/bl? getty/afp, which have thousands of journalists worldwide contributing thousands of images every day? flickr allows every user to manage their own files.

    an example on how unsuitable the current software is: batch "delete" is done using MediaWiki:Gadget-DelReqHandler.js or some other tool. it's not a built-in functionality of the software. users have to build all kinds of tools (MediaWiki:Gadgets-definition#AuthorizedUsers) on their own to maintain this website.

    compare that to https://www.flickr.com/photos/organize . easily edit, tag, change viewing permission, delete... in batches. pretty sure for getty/afp etc. their websites and internal systems also have decent batch editing tools.

RoyZuo (talk) 20:42, 15 May 2026 (UTC)Reply
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=1215080478"