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: 1 day 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: 8 days ago138 comments69 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
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: 9 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: 15 days ago5 comments4 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

The template "Logo" is confusing.

[edit]
Latest comment: 18 hours 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: 21 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: 2 days ago2 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

Proposal: Promote Commons:Upscaling to guideline

[edit]
Latest comment: 4 days ago30 comments11 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

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: 13 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: 6 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: 4 days ago4 comments3 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
[edit]
Latest comment: 6 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: 43 minutes ago9 comments7 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
  • .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
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
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=1211254617"