Jump to content

Commons:Village pump/Proposals

Add topic
From Wikimedia Commons, the free media repository
< Commons:Village pump
Latest comment: 58 minutes ago by Jmabel in topic LLM use in discussion

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

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.

Allow the Upload Wizard to automatically convert MP4 to WebM

[edit]
Latest comment: 9 days ago144 comments71 people in discussion

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

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
    Great summary thedj, what is the next step? --SJ+ 05:07, 16 June 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

Increase data maximum of (tabular) data pages

[edit]
Latest comment: 23 days ago7 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

Thanks, this is also a good example! --PantheraLeo1359531 😺 (talk) 18:48, 1 June 2026 (UTC)Reply

The template "Logo" is confusing.

[edit]
Latest comment: 22 days ago6 comments4 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
I had this confusion once. I think {{Logo}} should contain something like, This is a logo of an organisation... Maybe we can use {{Trademark}} for reference. There are logos which are in PD, yet can have some other form of protections like TM. There can also be logos which has some kind of restrictions, just not enough to not host here. (There is something more that I wish to say but can't find the correct words. Later, if I am able to). Shaan SenguptaTalk 10:48, 30 May 2026 (UTC)Reply
I would like to list the template "Logo" for discussion. In my opinion, it shouldn't redirect to "Logo above threshold of originality". Candidyeoman55 (talk) 10:56, 30 May 2026 (UTC)Reply
 Support -Consigned (talk) 00:09, 3 June 2026 (UTC)Reply

Project scope rewrite

[edit]
Latest comment: 22 days ago6 comments5 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
For news, that could very well go to Wikibooks instead. SVG-image-maker (talk) 20:29, 2 June 2026 (UTC)Reply

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

[edit]
Latest comment: 13 days ago8 comments5 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
currently 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
Pinging User:Fæ would be a great idea, except they have been more or less inactive for 5 years now, and they also never knew that these categories would ever come up. Also, the people who invented these categories, probably "just" intended to order an overflowing "books about archaelogy"-category by some objective criterium. Also, those categories are much younger than the uploads within them. And that is the whole issue: We have categorizers seeing huge amounts of files in some topic-categories, and then working at cross-purposes to "clean up the mess" by creating a subcategory jungle to hide the mess within.
I will not claim that I have never had bad ideas with categories, but my overall intention is to have easily-understood categories that one can browse to find the content one wants to find.
Oh, and "a bit time-consuming" is a bit of an understatement. I will NOT be the person to manually input combinations similar to the following string, for MILLIONS (!!) of books: [[Category:1877 books about archaeology]] [[Category:1877 books about Naples]] [[Category:1877 books from Leipzig]] [[Category:1877 German-language books]] [[Category:German-language books about archaeology]] [[Category:German-language books about Naples]] [[Category:German-language books from Leipzig]] [[Category:Books about Naples from Leipzig]] [[Category:Books about archaeology from Leipzig]] [[Category:Books about archaeology in Naples]] [[Category:1877 in archaeology of Naples]] [[Category:German-language archaeology in Naples]] If not inputting 12+ combination-categories instead of 5 basic categories is considered lazy or an error, then I'm doubting this project.
@Strakhov, so I gather that the terms are "publication date" (property): time (value in datetime format)". That's nice to know, I'll keep using that terminology from now on. Our basic problem is that most book files are not (sufficiently) categorized at all. And will never be, at the current rate. Take this file, it has been at the receiving end of added structured data already (so we know the width and height of the scan in pixels), but SD cannot tell when and where it has been published. Much less, what the content of the file is, or who the author is. Now imagine that the SD-bot could read the template and add the respective properties, not using WD-items either, but with the specific datatype: text. That doesn't even need to be an interpretation of the text, it would suffice to have "Publisher" (property): "London : Printed for Gale, Curtis, and Fenner ..." (text) Having that information translated from the template into SD would be a phenomenal first step. Because once that bot-run is finished, other users could refine this with queries. The first move would be to remove the "London :" part of the text value of hundreds of thousands of files, and instead assign "Publication location" (property): "London" (item). And at a later point, someone else could reassign "Publisher" (property): "Gale, Curtis, and Fenner" (text format, if not item).
But if SD can only be applied to content that was already fully categorized? Then I think we should lobby the Foundation to develop us tools for the book template and forget about SD for books. The book-template has more structure and more data. --Enyavar (talk) 16:15, 19 May 2026 (UTC)Reply
I can only agree. We have hundreds of thousands of books, most of them poorly categorized. I don't have a solution. Anything done manually is only a drop in the ocean. So only improvement which can be done with a bot is welcome. Yann (talk) 17:15, 19 May 2026 (UTC)Reply
As stated above - The scale of this issue is MASSIVE, millions of files. If we could get a bot to run what Enyavar is proposing, it may give us something to work with. Is there a way to work with some of the book templates that are there (although again, drop in the ocean)? I am also under no illusion that the information on the uploaded files is always correct or even available. But it's ballpark, which may be more than what we have. I would personally love to be able to just use our current search for a book name and get all editions/files from it that we have, but even that is not working very well. Let me know if there is anything I can do. -- Deadstar (msg) 11:46, 1 June 2026 (UTC)Reply
Have a look at Commons:IA books and Commons:Bots/Work_requests#Book_renaming for more/related on the topic. -- Deadstar (msg) 06:44, 11 June 2026 (UTC)Reply

Gadget list cleanup

[edit]
Latest comment: 7 days ago6 comments2 people in discussion
all the pages to check
  1. Mediawiki:Gadget-Gallerypreview
  2. Mediawiki:Gadget-Slideshow
  3. Mediawiki:Gadget-ZoomViewer
  4. Mediawiki:Gadget-CollapsibleTemplates
  5. Mediawiki:Gadget-popups
  6. Mediawiki:Gadget-fastcci
  7. Mediawiki:Gadget-edittop
  8. Mediawiki:Gadget-addsection-plus
  9. Mediawiki:Gadget-OldEdittools
  10. Mediawiki:Gadget-NoUploadWizard
  11. Mediawiki:Gadget-ImprovedUploadForm
  12. Mediawiki:Gadget-Watchlist-wo-uploads
  13. Mediawiki:Gadget-VIAFDataImporter
  14. Mediawiki:Gadget-HidePostEdit
  15. Mediawiki:Gadget-CropTool
  16. Mediawiki:Gadget-VideoCutTool
  17. Mediawiki:Gadget-ImageMapEdit
  18. Mediawiki:Gadget-Favorites
  19. Mediawiki:Gadget-RotateLink
  20. Mediawiki:Gadget-RenameLink
  21. Mediawiki:Gadget-CategoryAboveAll
  22. Mediawiki:Gadget-CategoryAboveBelowImage
  23. Mediawiki:Gadget-Long-Image-Names-in-Categories
  24. Mediawiki:Gadget-GlobalUsageUI
  25. Mediawiki:Gadget-DisableImageAnnotator
  26. Mediawiki:Gadget-GalleryFilterExtension
  27. Mediawiki:Gadget-LargerGallery
  28. Mediawiki:Gadget-ImageStackPopup
  29. Mediawiki:Gadget-ACDC
  30. Mediawiki:Gadget-Hide-Captions
  31. Mediawiki:Gadget-Compact-Captions
  32. Mediawiki:Gadget-Collapse-Captions
  33. Mediawiki:Gadget-HideStructuredDataTab
  34. Mediawiki:Gadget-Stockphoto
  35. Mediawiki:Gadget-UTCLiveClock
  36. Mediawiki:Gadget-LocalLiveClock
  37. Mediawiki:Gadget-search-new-tab
  38. Mediawiki:Gadget-diffGreenBlue
  39. Mediawiki:Gadget-DiffOldStyle
  40. Mediawiki:Gadget-PrettyLog
  41. Mediawiki:Gadget-ExtraTabs2
  42. Mediawiki:Gadget-rightsfilter
  43. Mediawiki:Gadget-contribsrange
  44. Mediawiki:Gadget-WatchlistNotice
  45. Mediawiki:Gadget-historyNumbered
  46. Mediawiki:Gadget-ThreadedDiscussions
  47. Mediawiki:Gadget-typographyrefreshoverride
  48. Mediawiki:Gadget-markAdmins
  49. Mediawiki:Gadget-Wdsearch
  50. Mediawiki:Gadget-advanced-search
  51. Mediawiki:Gadget-MyGallery
  52. Mediawiki:Gadget-linkscount
  53. Mediawiki:Gadget-scrollUpButton
  54. Mediawiki:Gadget-externalsearch
  55. Mediawiki:Gadget-TabularImportExport
  56. Mediawiki:Gadget-Infobox
  57. Mediawiki:Gadget-MoreMenu-local
  58. Mediawiki:Gadget-fuzzyeverywhere
  59. Mediawiki:Gadget-owidslider
  60. Mediawiki:Gadget-ThumbnailPurger
  61. Mediawiki:Gadget-purgetab
  62. Mediawiki:Gadget-GalleryDetails
  63. Mediawiki:Gadget-AddInformation
  64. Mediawiki:Gadget-WhatIsThat
  65. Mediawiki:Gadget-AjaxQuickDelete
  66. Mediawiki:Gadget-QuickDelete
  67. Mediawiki:Gadget-UserMessages
  68. Mediawiki:Gadget-GoogleImagesTineye
  69. Mediawiki:Gadget-GoogleImagesTineyeMobile
  70. Mediawiki:Gadget-RegexMenuFramework
  71. Mediawiki:Gadget-VisualFileChange
  72. Mediawiki:Gadget-Adiutor
  73. Mediawiki:Gadget-Cat-a-lot
  74. Mediawiki:Gadget-HotCat
  75. Mediawiki:Gadget-Glamorous
  76. Mediawiki:Gadget-Searchnotincat
  77. Mediawiki:Gadget-CatScan2-link
  78. Mediawiki:Gadget-DeepcatSearch
  79. Mediawiki:Gadget-Geocodecattodo
  80. Mediawiki:Gadget-WikiMiniAtlas
  81. Mediawiki:Gadget-LocatorTool
  82. Mediawiki:Gadget-BiDiEditing
  83. Mediawiki:Gadget-ShortLink
  84. Mediawiki:Gadget-EoMagicalConversion
  85. Mediawiki:Gadget-MyLangNotify
  86. Mediawiki:Gadget-LanguageSelect
  87. Mediawiki:Gadget-DeferredDisplay
  88. Mediawiki:Gadget-QInominator
  89. Mediawiki:Gadget-QICvote
  90. Mediawiki:Gadget-PictureOfTheYearEnhancements
  91. Mediawiki:Gadget-DelReqHandler
  92. Mediawiki:Gadget-instantDelete
  93. Mediawiki:Gadget-autodel
  94. Mediawiki:Gadget-CleanDeleteReasons
  95. Mediawiki:Gadget-LicenseReview
  96. Mediawiki:Gadget-PermissionOTRS
  97. Mediawiki:Gadget-RTRC
  98. Mediawiki:Gadget-modrollback
  99. Mediawiki:Gadget-botRollback
  100. Mediawiki:Gadget-UdelReqHandler
  101. Mediawiki:Gadget-EditRequest
  102. Mediawiki:Gadget-Restore-a-lot
  103. Mediawiki:Gadget-Twinkle
  104. Mediawiki:Gadget-morebits
  105. Mediawiki:Gadget-select2
  106. Mediawiki:Gadget-userRightsManager
  107. Mediawiki:Gadget-GlobalUsage
  108. Mediawiki:Gadget-SettingsUI
  109. Mediawiki:Gadget-SettingsManager
  110. Mediawiki:Gadget-editDropdown
  111. Mediawiki:Gadget-JStack
  112. Mediawiki:Gadget-libAPI
  113. Mediawiki:Gadget-libUtil
  114. Mediawiki:Gadget-libCommons
  115. Mediawiki:Gadget-libJQuery
  116. Mediawiki:Gadget-libWikiDOM
  117. Mediawiki:Gadget-JStack
  118. Mediawiki:Gadget-libGlobalReplace
  119. Mediawiki:Gadget-libCat
  120. Mediawiki:Gadget-progressDialog
  121. Mediawiki:Gadget-jquery.badge
  122. Mediawiki:Gadget-jquery.blockUI
  123. Mediawiki:Gadget-jquery.in-view
  124. Mediawiki:Gadget-jquery.fullscreen
  125. Mediawiki:Gadget-jquery.mousewheel
  126. Mediawiki:Gadget-jquery.rotate
  127. Mediawiki:Gadget-ImageStack
  128. Mediawiki:Gadget-CommonsDashboard
  129. Mediawiki:Gadget-WatchlistNotice.core
  130. Mediawiki:Gadget-jquery.jqplot
  131. Mediawiki:Gadget-math.seedrandom
  132. Mediawiki:Gadget-AnonymousI18N
  133. Mediawiki:Gadget-tipsyDeprecated
  134. Mediawiki:Gadget-AddFileCaption
  135. Mediawiki:Gadget-AddFileDescription

all the pages to check.--RoyZuo (talk) 10:58, 17 June 2026 (UTC)Reply

[edit]

Special:Preferences#mw-prefsection-gadgets many gadgets have no links.

MediaWiki:Gadgets-definition should be updated so that every gadget has at least one link [[mediawiki talk:gadget-xx.js]]. 19:02, 18 May 2026 (UTC)

all gadgets are listed at MediaWiki:Gadgets-definition. each [[mediawiki:gadget-xx]] should be updated to use Template:Gadget-desc with at least one link [[mediawiki talk:gadget-xx.js]].--RoyZuo (talk) 15:39, 20 May 2026 (UTC)Reply

Can you make a concrete list of changes and request an edit at MediaWiki_talk:Gadgets-definition using {{Edit request}}? whym (talk) 11:22, 20 May 2026 (UTC)Reply
i just realised i made a mistake by assuming the links were created from MediaWiki:Gadgets-definition.--RoyZuo (talk) 15:39, 20 May 2026 (UTC)Reply
if they dont already have any links to their js, gadget page, help page, talk page... then replace with
{{gadget-desc|1={{subst:PAGENAME}}|self={{subst:FULLPAGENAME}}|name={{subst:PAGENAME}}|talk=MediaWiki talk:{{subst:PAGENAME}}.js}}
this provides each gadget with a most basic link to MediaWiki talk:PAGENAME.js .
ofc, it'd be much better if more detailed description is given for each. RoyZuo (talk) 10:18, 27 May 2026 (UTC)Reply

Default gadgets

[edit]

i just noticed that MediaWiki:Gadget-owidslider.js is a new default gadget, but it's not correctly indicated with the little d in Special:Preferences#mw-prefsection-gadgets like MediaWiki:Gadget-Slideshow is.

all should be tidied up such that all default gadgets are correctly identified.--RoyZuo (talk) 10:58, 17 June 2026 (UTC)Reply

Need help writing COM:Arguments to avoid in deletion discussions

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

Honestly, surprised this hasn't been created yet, considering a lot of reasons on the Wikipedia page of the same name also apply here. For now, I copied the text from the aforementioned enWP page (at least the parts that make sense in the Commons context) and changed certain text to fit more with Commons. I don't have nearly enough experience with deletion requests to write a whole page with common fallacies, though. That's why I'm asking for help. It could be anything, adding new entries, improving existing ones, creating missing templates and redirects.

Not sure if this is the right place to post it, but in my opinion the page would be very helpful if supplemented with more Commons-specific examples. Dabmasterars [EN/RU] (talk/uploads) 20:05, 19 May 2026 (UTC)Reply

Another argument to avoid is "this logo is trademarked™️®" because Commons only cares about "copyright ©". For trademarks we have {{Trademark}}. Nakonana (talk) 10:47, 25 May 2026 (UTC)Reply
few quick notes:
1. Per nom can be acceptable when nominator provides a copyright based rationale. If a country doesn't have FOP for buildings and it's a photo of a new building in that country, then that's all the Rationalle we need.
2. Bad quality can actually be part of a valid deletion rationalle in some cases, with com:PENIS violations in particular.
3. I've never seen "per majority", but have seen "per above". it's less useful than a "per nom" most of the time, but depending on the user, can actually change the outcome of a DR
And just a note about commons DR's vs Enwiki: Enwiki only has one article on giraffes, but commons can have as many giraffe photos as it wants. Most DRs that aren't closed after 7 days are due to either a borderline scope issue, uncerntianty on obscure copyright law in a country that doesn't have a lot of online resources, or some other copyright/eithical issue. Outside of AI generated files, there's a lot less at stake at a commons DR (most of the time).
All the Best -- Chuck Talk 00:57, 20 May 2026 (UTC)Reply
The proposal already has info on "per nom" being useful in specific cases, I should probably add to it. Same with bad quality, it can be valid if the image is superseded, though I'll note the nudity aspect, as very few files are deleted due to low quality unless they're nudity-related. I'm also thinking about having a section about using guidelines without explanation, such as citing "copyvio" or "porn" without reasoning. Dabmasterars [EN/RU] (talk/uploads) 08:23, 20 May 2026 (UTC)Reply
Agree with that last ("copyvio" or "porn"). Those are particularly bad when they are all that the original nomination says. - Jmabel ! talk 13:43, 20 May 2026 (UTC)Reply
Also saying "duplicate" or "superseded" without naming the relevant second/updated file. Nakonana (talk) 10:42, 25 May 2026 (UTC)Reply
in addition, there's a designated duplicate template. (it shouldn't be used on SVG v raster debates, but otherwise saves a lot of time and effort). All the Best -- Chuck Talk 19:13, 25 May 2026 (UTC)Reply
 OpposeI don't think it is needed, don't import bureaucracy from en Isderion (talk) 19:32, 25 May 2026 (UTC)Reply
@Isderion, this isn't bureaucracy, this is a resource for new users. I can't see a benefit from not having it. DR is one of the most confusing areas of the project, and everyone could stand to benefit from reading it. All the Best -- Chuck Talk 17:12, 26 May 2026 (UTC)Reply
Hi, Yes, I think that can be useful. Your choice of usernames make me laugh. Yann (talk) 11:04, 27 May 2026 (UTC)Reply
Can we get a "Closing summaries to avoid in deletion discussions" while we're at it? :/ e.g. "per nom" when the nom presents no policy-based reason, or "per discussion" when the discussion is very unclear. — Rhododendrites talk |  13:54, 27 May 2026 (UTC)Reply
Not sure how useful that would be since the closes are almost all done by admins, but I guess this wouldn't be extra. I don't have enough experience with closing discussions, so that page could be done by someone else. Dabmasterars [EN/RU] (talk/uploads) 14:37, 27 May 2026 (UTC)Reply
 Keep good resource list. At first glance it looked too long, but some things need to be written out. I don't think we need that many shortcuts. --Loved the funny user names!!1! 07:28, 1 June 2026 (UTC)Reply

"Category:Straight-two motorcycle engines"

[edit]
Latest comment: 27 days ago1 comment1 person in discussion

Category:Straight-two motorcycle engines has three sub-categories, two of which seem to duplicate each other. There is a discussion on Category talk:Parallel-twin motorcycle engines, which became dormant in 2017, apparently without reaching a conclusion. I have revived the discussion, and I invite contributions. Motacilla (talk) 22:05, 28 May 2026 (UTC)Reply

Proposed restructuring to categories in Category:Photographs by date by country

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

Many of these categories have thousands of subcategories and therefore hard to navigate. I propose restructuring to make these more practical. These include Category:Photographs of Hungary by date, Category:Photographs of Latvia by date, and so on for other countries. The proposed restructuring is like so.

Subcategories of Category:Photographs of Latvia by date

Category:Latvia photographs taken in October 1999
Category:Latvia photographs taken in November 1999
Category:Latvia photographs taken in December 1999
Category:Latvia photographs taken in January 2000
Category:Latvia photographs taken in February 2000
and so on.
Then, the day categories would be subcategories of the month categories.

This would make the categories more navigable and useful. SVG-image-maker (talk) 02:56, 2 June 2026 (UTC)Reply

 Oppose. Adding more tiers of metacategories doesn't make these categories more navigable - it just makes navigating them take more clicking, and adds a bunch of new month/year categories which need to be created and maintained. A better solution would be to add a navigation template to the main category that scrolls to the appropriate starting point for each year, similar to the "contents" templates on e.g. Category:All media needing categories as of 2021. And, more broadly, I don't think very many people actually use these categories, as they're really just a random assortment of unrelated photos; we should prioritize ease of maintenance over ease of navigation. Omphalographer (talk) 04:15, 2 June 2026 (UTC)Reply
Those categories already exist, if I'm not mistaken, they just follow a different naming pattern (example Category:January 2020 Germany photographs) Nakonana (talk) 07:18, 2 June 2026 (UTC)Reply
See Category:Photographs by month by country. Nakonana (talk) 07:20, 2 June 2026 (UTC)Reply
I actually came across these categories by Google searching "photographs by country".
How would this be any different than en:Category:Years on enwiki? That category is: umbrella category -> century -> individual year.
Commons has a lot of umbrella categories such as Category:Maps. If Category:Maps wasn't an umbrella category, we could very well end up with a jumbled soup, with hundreds of thousands of unsorted files. Umbrella categories really aren't a big deal once you get the hang of them.
I propose a new hierarchial scheme for the photographs by date by country category would be as follows:
Photographs by date by country -> Photographs of [country name] by month -> [Country name] photographs taken on [exact date]. And note that I do not propose a year hierarchy, to make things more manageable.
Let's do some math. Category:Photographs of Latvia by date has 4,511 subcategories currently. These listings only show 200 subcategories at a time, so that's 23 listpages worth of clicking. There are about 30 days in a month, give or take. This means that if the subcategories in Category:Photographs of Latvia by date were by month, then there would only be about 150 subcategories, which could fit into a single listpage.
So this actually means navigating the categories would take fewer clicks. SVG-image-maker (talk) 15:10, 2 June 2026 (UTC)Reply
Category:Latvia photographs taken on 2000-10-14 (for example) is already in Category:October 2000 Latvia photographs, which is in Category:2000 photographs of Latvia, which is in both Category:2000s photographs of Latvia and Category:20th-century photographs of Latvia (someone was a stickler there on the definition of the century). We don't need to replicate that hierarchy a second time. - Jmabel ! talk 21:12, 2 June 2026 (UTC)Reply

Update the final exception of COM:INUSE to reflect changes to guidelines

[edit]
Latest comment: 18 days ago15 comments5 people in discussion

We have a new guideline, COM:AIIP, which extends the principles of COM:PEOPLE to AI-generated media. At COM:INUSE, while the list of examples when files may still be subject to deletion for reasons beyond their scope does say including but not limited to, a simple adjustment to the last item would update it to reflect current guidelines.

Current:
Photographs of people that do not comply with the relevant guideline.

Revised:
Depictions of people that do not comply with the relevant guidelines.

  • Support as proposer. The existing wording, which is limited to "photographs" and not other depictions like video, does not even adequately capture COM:PEOPLE. Also not opposed to replacing the "relevant" and "guidelines" links with the names of the guidelines. — Rhododendrites talk |  16:00, 4 June 2026 (UTC)Reply
It should be phrased like this:
Depictions of people that do not comply with Commons:Photographs of identifiable people or Commons:AI images of identifiable people.
It's better understandable this way --Isderion (talk) 17:47, 4 June 2026 (UTC)Reply
Sure, that's the "names of the guidelines" possibility I mentioned in my !vote. Is there perhaps a more succinct way, though? Maybe "Depictions of people that do not comply with relevant guidelines on photographs or AI-generated images of identifiable people? — Rhododendrites talk |  17:53, 4 June 2026 (UTC)Reply
  •  Oppose, we've already seen AI-images of Tutankhamun and Cleopatra getting deleted per COM:AIP. Let's not make things worse by actually elevating that guideline to policy. - Alexis Jazz ping plz 17:50, 4 June 2026 (UTC)Reply
    • If you want an exception to AIIP for long-dead people (as I do), go support that on the AIIP talk page. As it stands, however, the nature of AIIP is already an exception to INUSE as an application of COM:PEOPLE. COM:INUSE has simply not been updated to include it yet. I understand some folks don't like that AIIP has become a guideline, but it passed as-is with overwhelming support. — Rhododendrites talk |  17:56, 4 June 2026 (UTC)Reply
      • Some admins treat COM:AIP as if it overrides policy. That's just bad adminship, nothing more, nothing less. The only reason I haven't dragged them to COM:ANU is because I fear revenge. I've done more than my fair share of holding admins accountable. I've seen others (including at least one admin) complain about this, but so far nobody willing to take action. it passed as-is with overwhelming support Enough examples in history of absolutely terrible crap that passed with overwhelming support. It doesn't mean it's good. AIP being a guideline, while not ideal, isn't even the real issue. It being misused to override policy is. - Alexis Jazz ping plz 03:53, 5 June 2026 (UTC)Reply
        • You and Consigned keep saying things like as if it overrides policy. Presumably you're talking about a "conflict" between INUSE and PEOPLE/AIP, right? But that's not a conflict. If something is out of scope, it should be deleted; if something is against PEOPLE/AIP, it should be deleted. They're two different reasons for deletion, and passing one doesn't save a file from being deleted per the other. We need both to be ok to host something. — Rhododendrites talk |  13:03, 5 June 2026 (UTC)Reply
  •  Support changing "photographs" to "depictions", but  Oppose adding AIP. COM:AIP is essentially an application of COM:PEOPLE, per AIP's introduction which twice mentions "legal and moral rights" and links to COM:PEOPLE; this is also evident from the discussions which resulted in AIP's creation which were COM:PEOPLE focused. COM:INUSE and COM:PEOPLE are sound and any inconsistency should be resolved in COM:AIP; in the interim, the policy COM:INUSE trumps guideline COM:AIP. -Consigned (talk) 22:08, 4 June 2026 (UTC)Reply
    • ? The COM:PEOPLE guideline is already an exception to the INUSE policy. Or, more precisely, files can be deleted for reasons other than scope, so INUSE just isn't relevant to a COM:AIP or COM:PEOPLE deletion rationale. Why not document that more clearly? — Rhododendrites talk |  02:37, 5 June 2026 (UTC)Reply
      • COM:PEOPLE documents legal issues, COM:AIP does not. The INUSE exception we are talking about, as written, is for legal issues. COM:AIP is not sufficiently well-written to be added as an exception to INUSE. Is there friction between INUSE and what we prefer to see? Yes. Is there a problem? I think so. Is COM:AIP the solution? Not in a hundred years. - Alexis Jazz ping plz 03:53, 5 June 2026 (UTC)Reply
        There are two separate problems: 1. AI generated or altered files of living people. These files are a legal problem. 2. AI generated files of long dead people. These files are sometimes a moral issue but primarily a problem regarding the educational value. The problem in the second case are small Wikis is insufficient moderation capacities. If projects fail to defend our movement values, we can not support them by hosting their files. GPSLeo (talk) 06:31, 5 June 2026 (UTC)Reply
        GPSLeo, AI generated or altered files of living people. These files are a legal problem.
        No, they're not. For the issue we are talking about (which is not copyright), there is no legal distinction between a human or an LLM wielding a pencil. If depictions of living people were illegal every caricaturist would be in jail as well as many painters.
        Whether consent is required to publish a picture depends on the source country and situation, but this is not an AI-issue as it also applies to real photographs. Often unless the image amounts to defamation there is no legal problem. Photorealistic AI images of living people are legally mostly uncharted territory, but they are not in and of themselves illegal.
        AI generated files of long dead people. These files are sometimes a moral issue but primarily a problem regarding the educational value.
        In most cases we do not need new policy for that. If the file is not in use or we don't get reverted when we unlink their images (always mention on a DR if you've unlinked INUSE files!) we can usually get them deleted as non-notable artworks. If we do get reverted, we can make a report on the administrator's noticeboard of the wiki in question if they have any active administrators. If they don't, we'd have to find a steward and I'm unsure how that typically works out because I don't recall ever doing that. But assuming there is an administrator, the admin will either revert/protect the article to solve our INUSE problem, or they side with the user and we'll have to yield.
        The problem in the second case are small Wikis is insufficient moderation capacities. If projects fail to defend our movement values, we can not support them by hosting their files.
        That is indeed a problem, but not in any way limited to images of people. We need a very kind of different proposal for this. - Alexis Jazz ping plz 12:05, 5 June 2026 (UTC)Reply
        "Legal problem" is not the same as "always illegal". We have a strong application of the precautionary principle in regard to copyright. We should apply this principle in the same way to everything related to personality rights. Yes, we have similar problems with other content too, but AI generated images are by far the largest problem here. GPSLeo (talk) 06:02, 6 June 2026 (UTC)Reply
        COM:PEOPLE is not just about legal issues, and if you would like the exception to only apply to the legal issues it contains, you'll need a proposal like this one. I certainly would not support it. We have furthermore been told by the WMF, in so many words, that even when cases where the law might not be clearly against something, we should be erring more, not less, on the side of enforcing COM:DIGNITY given how complicated those issues are. — Rhododendrites talk |  13:03, 5 June 2026 (UTC)Reply
        It's primarily about legal issues. COM:AIP isn't about legal issues at all. We have furthermore been told by the WMF Can you give a source for this so we can see it in context? - Alexis Jazz ping plz 23:38, 5 June 2026 (UTC)Reply

Gadget to hide NSFW images

[edit]
Latest comment: 4 days ago22 comments13 people in discussion

Summary

[edit]

Back at Commons:Village_pump/Archive/2026/03#Blurring_NSFW_images i was asked to make a user script to blur NSFW images (based on structured data). Anyways, i made User:Bawolff/nsfw.js based on a script by User:Putnik. Add mw.loader.load( 'https://commons.wikimedia.org/w/index.php?title=User:Bawolff/nsfw.js&action=raw&ctype=text/javascript'); to meta:Special:MyPage/global.js to test (edit: please see User:Bawolff/nsfw for alternate install instructions that reduce the delay between page load and censoring). I think some people are interested in it being a gadget. Bawolff (talk) 20:39, 5 June 2026 (UTC)Reply

Bawolff, thanks for fixing the issues I reported on User talk:Trade (revision 1226431748). I tested the new version and it works better. It does not appear to work for video thumbnails [3]. - Alexis Jazz ping plz 21:31, 5 June 2026 (UTC)Reply
we do have an issue where special:mediasearch will load thumbnails after you scroll them into view. The gadget will only hide images in initial page load not later dynamically loaded images. Bawolff (talk) 22:53, 5 June 2026 (UTC)Reply
please just make it a gadget then i can try it out and vote if it should be default on/off. RoyZuo (talk) 07:05, 9 June 2026 (UTC)Reply

I'm going to boldly uncollapse the above section. It seems to be collapsed under the belief that the script is under active development. I did fix some things based on Alexis's feedback (Including some of the things mentioned above), but beyond that i don't really have any plans to work further on the script (Unless other people give further feedback). I think the script should be considered done. The main limitation of the script is there is a small delay before images get censored. Obviously that is non-ideal, but there is not much i can do about that and i don't think that should be a blocker to turning it into an optional gadget. Bawolff (talk) 18:53, 8 June 2026 (UTC)Reply

Note: I removed some of the options below that are not possible. Choices that are actually possible are: Do nothing (keep as user script), make it an optional gadget that people can opt into in Special:Preferences, make it a default enabled gadget that people can opt out of in Special:Preferences. Bawolff (talk) 20:30, 10 June 2026 (UTC)Reply
afaicu based on mw:Extension:Gadgets#Options (rights), it's possible to only enable a gadget for a certain group of users.
for example, enabling it only for all autoconfirmed users would have almost the effect of enabling it for registered users but disabling it for unregistered users. RoyZuo (talk) 10:44, 17 June 2026 (UTC)Reply
I actually did just think of a way to prevent the small delay before images are blurred. I made a second script with that approach (Probably a moot point given how this is going). See User:Bawolff/nsfw#Service_worker_variant for details on that. Bawolff (talk) 08:23, 14 June 2026 (UTC)Reply

Make the gadget enabled by default for both users and logged-out visitors alike (opt-out)

[edit]

 Support - Provided that it's reliable in picking up the appropriate structured data. ShakespeareFan00 (talk) 19:54, 18 June 2026 (UTC)Reply

Make the gadget disabled by default. Users can opt in by checking a box in Special:Preferences

[edit]

OK modern_primat ඞඞඞ ----TALK 08:04, 7 June 2026 (UTC)Reply

 Support it's been a perennial thing some users ask for. RoyZuo (talk) 10:45, 17 June 2026 (UTC)Reply
 Support Tausheef Hassan Auntu ✉Talk? 13:00, 20 June 2026 (UTC)Reply

Do not create the gadget. Image blurring should stay strictly as a script only

[edit]

LLM use in discussion

[edit]
Latest comment: 58 minutes ago24 comments14 people in discussion

Following from Commons:Village pump/Archive/2026/05 § LLM use in discussion, I propose to alter Commons:Talk page guidelines to include the following text. This is based on en:WP:AITALK, minimally altered for Commons.

LLM-generated comments: Comments, nominations, and opening statements that are obviously generated (not merely refined) by a LLM or similar AI technology may be struck or collapsed with {{Collapse top}}. In formal discussions, this may result in the speedy closure of irrelevant or disruptive discussions. If a worthwhile conversation has already started, it may be left open. The proposer of a closed discussion may be politely invited to start a new discussion using their own thoughts and words.

Apocheir (talk) 20:34, 6 June 2026 (UTC)Reply

  • Shucks! COM:BOLD is neither a policy nor a guideline but redirects to the essay COM:don't be bold. Should be added just now; indeed, I  support this. --George Ho (talk) 20:44, 6 June 2026 (UTC)Reply
  • Given Commons is a more international and multilingual project than the English Wikipedia, is it worth discussing whether (and the extent to which) LLM-based translation should be tolerated? — Rhododendrites talk |  20:59, 6 June 2026 (UTC)Reply
    No, they are even more problematic as people might not even know what they wrote and signed with their name. If you do not speak English, just write in your language and let the reader translate it. GPSLeo (talk) 21:24, 6 June 2026 (UTC)Reply
    Given that Commons is a multilingual project, we should encourage users to use whatever language they are comfortable with, rather than feeling pressured to use English (potentially through an unreliable software translator). Omphalographer (talk) 22:18, 6 June 2026 (UTC)Reply
    Agreed, but the question is whether we remove messages and/or punish someone who opts to use an LLM-based translation tool. AFAIK we do not do that for other translation tools. Translation competency of LLMs is not something I've followed closely, though just anecdotally I feel like I keep hearing from my Spanish and French-speaking friends that LLMs are outperforming Google Translate. That's something I'd be curious to hear from others about, as I am a cliche American who is only fluent in one language. — Rhododendrites talk |  22:32, 6 June 2026 (UTC)Reply
    @Rhododendrites: in what sense is Google Translate not an LLM? - Jmabel ! talk 23:40, 6 June 2026 (UTC)Reply
    I think the technical distinctions are probably getting a little blurry, but when we say "LLM" we tend to be talking about the kind of transformer-based token-by-token predictive stuff while Google Translate uses a specialized neural network based on older machine translation technology. As I do a quick search, I see that Google has started incorporating some LLM features into Translate, so maybe no longer a good metaphor, but that then begs the question: would this prohibit anyone from using Google Translate for communications on Commons? — Rhododendrites talk |  01:18, 7 June 2026 (UTC)Reply
    This is guideline, not policy, and the language here is very soft. Common sense always applies; I don't think we need to be worried about "punishing" people without justification. Phillipedison1891 (talk) 02:55, 7 June 2026 (UTC)Reply
    Being a guideline doesn't change anything at all about the question. — Rhododendrites talk |  03:20, 7 June 2026 (UTC)Reply
 Support as someone who is neurodivergent and sometimes uses generative AI to get an idea of how to effectively communicate something that's in my head. But I don't copy and paste the response; I use it as a starting point to write my own text in my own words.
All Wikimedia projects are built more or less on consensus and good faith. LLMs are very effective at quickly generating authentic human-sounding communication with little to no effort. It's a perfect tool for trolls, agenda-driven individuals, and other bad actors to compromise our community. If someone is clearly and repetitively posting LLM-generated content in discussions, they absolutely should be blocked as disruptive. Copied from previous discussion Phillipedison1891 (talk) 22:07, 6 June 2026 (UTC)Reply
"If someone is clearly and repetitively posting LLM-generated content in discussions, they absolutely should be blocked as disruptive." So you dont think people deserve any warnings to justify a block? Trade (talk) 00:43, 7 June 2026 (UTC)Reply
My intention was that warnings are implied by the word "repetitively". Phillipedison1891 (talk) 02:53, 7 June 2026 (UTC)Reply
 Comment I have posted a courtesy notification on the talk page of everyone who gave a support or oppose vote on the original proposal. Phillipedison1891 (talk) 22:19, 6 June 2026 (UTC)Reply
 Support - However, as I said before in the preliminary debate, there need to be safeguards so that we are not suppressing free speech: This is an international project where writers of all languages are allowed to participate, regularly in auto-translations. If users are flagged/reprimanded falsely for LLM misuse, there should be reasonable ways of recourse, like appealing on the admin noticeboard. And if users are systematically misusing such a new guideline themselves to suppress critics, that should also have consequences. --Enyavar (talk) 22:36, 19 May 2026 (UTC)
 Support ―Justin (koavf)❤T☮C☺M☯ 23:57, 6 June 2026 (UTC)Reply
 Support - good suggestion. -- Karim (talk) 03:31, 7 June 2026 (UTC)Reply
 Support. When posting messages on projects in other languages I often use machine translation (which may or may not use an LLM, I have no idea). But I always mark the translation as such and include the English original. For example Вікіпедія:Кнайпа (адміністрування) (версія 48172310). As discussed above, it's not advised to throw away the original and only post the translation anyway. When it comes to using an LLM to write a comment from scratch, YUCK. I see more and more smart people getting frustrated with AI. As I said on a DR: "If you can't be arsed to write words, why would I?" - Alexis Jazz ping plz 03:38, 7 June 2026 (UTC)Reply
There isn't always an "English original". As I remarked in the discussion Apocheir linked at the top of this section, I'll often use Google Translate in much subtler ways than that: e.g. to see if it can come up with a more apt word than I first chose for something where I'm less than confident, or to verify that my writing in a language where I am decent but short of fluent makes sense by translating back into English, etc. As long as this sort of use continues to be acceptable, I'm OK with this proposal. - Jmabel ! talk 14:41, 7 June 2026 (UTC)Reply
Jmabel, I think that's fine, you're not generating the text that you post. - Alexis Jazz ping plz 11:25, 9 June 2026 (UTC)Reply
  1. are people aware that llm can write in all kinds of styles?
  2. thinking you can detect llm is equivalent to, llm has not passed and will not pass the turing test, which is not true.
i dont even bother vote support or oppose. this kind of proposal is not even enforceable. hence the whole discussion is pointless. RoyZuo (talk) 06:24, 7 June 2026 (UTC)Reply
 Support I voiced support of the language used for enwiki's LLM comment policy, and I'm glad to see it applied here as well. It's nuanced and not overtly punishing for people who use it in good faith, but provides a good foundation for administrators (and other Commoners) to deal with situations where it's not used in good faith. ReneeWrites (talk) 09:25, 7 June 2026 (UTC)Reply
 Comment Another blatant example: Commons:Deletion requests/File:Jefferson Doby.png (Diff ~1237006115). I had just removed it entirely while leaving a comment to link it in the page history. This is almost like ChatGPT using a meatpuppet. We are humans, we shouldn't have to read the fabrications of a robot, let alone argue with them. - Alexis Jazz ping plz 03:21, 25 June 2026 (UTC)Reply
@Alexis Jazz: I don't see that as blatantly coming from a chatbot. What am I missing? (and it seems to me you should ping the person you are accusin here.) - Jmabel ! talk 04:47, 25 June 2026 (UTC)Reply

There has to be a converter from other vector formats to SVG

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

We need a tool to automatically convert other vector formats to SVG perfectly, and from unsupported raster formats to PNG and JPG. For Commons and every Wikimedia project with local uploads. Candidyeoman55 (talk) 12:44, 14 June 2026 (UTC)Reply

Which formats do you have in mind? I can't immediately think of any other vector image formats which are in wide usage. Omphalographer (talk) 19:41, 14 June 2026 (UTC)Reply
The vector formats I talked about are:
  • .ai
  • .eps
  • .cdr
And the raster format is:
  • .avif
There should be a converter for them here. Candidyeoman55 (talk) 20:24, 14 June 2026 (UTC)Reply
@Candidyeoman55: The current state of what we accept and don't accept is at COM:FT.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:57, 15 June 2026 (UTC)Reply
There should be a lossless converter at upload I think. Candidyeoman55 (talk) 06:40, 15 June 2026 (UTC)Reply
Doesn't Inkscape do this already for vector based formats ? Maybe not perfectly, but that's the business of converting files. If you really need to deal with a proprietary format, there is always the option of buying the proprietary software creating it, which definitely has an svg export options these days. —TheDJ (talk • contribs) 09:19, 15 June 2026 (UTC)Reply

Restrict category creation to registered users

[edit]
Latest comment: 4 days ago15 comments9 people in discussion

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

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

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

For context, read:

As I wrote to them on my talk page:

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

to which they responded

"I stand by what I did."

and

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

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

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

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

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

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

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

Category PAGE creation ? or category creation ?

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

Proposed AI deletion criteria.

[edit]
Latest comment: 5 hours ago11 comments10 people in discussion

In order to codify some commonly cited deletion reasons for AI content (with a view to potential AI specific CSD / DR reasons.) I propose the following criteria, to be used against AI generated media. :-

  1. Synthetic depiction of a living person (COM:AIIP);
  2. Synthetic substitute for an obtainable photograph.
  3. Mass-produced generic synthetic output with no human selection.
  4. Misleading synthetic representation
  5. Unverifiable historical reconstruction
  6. Redundant synthetic replacement
  7. Hallucinated details
  8. Promotional AI generation

Thoughts? ShakespeareFan00 (talk) 19:02, 18 June 2026 (UTC)Reply

 Support making these some kind of formal guideline. In particular “Mass-produced generic synthetic output with no human selection” could be a speedy deletion rationale. Dronebogus (talk) 19:07, 18 June 2026 (UTC)Reply
There's a big RfC coming next week. (the 24th to be exact)
We may need additional policy (not guidelines) after that, but having various overlapping proposals in parallel is not a good idea imho. Discussing this to work out some details is fine, but this thread should be moved to COM:VP imho. This is not actionable, and changing core policy is not typically done like this. - Alexis Jazz ping plz 19:51, 18 June 2026 (UTC)Reply
Agree that deletion rationales should be based on policy, not the other way around;  Oppose this specific request. -Consigned (talk) 09:14, 19 June 2026 (UTC)Reply
If there's a pending RFC, then it would be prudent to 'hold. ShakespeareFan00 (talk) 19:53, 18 June 2026 (UTC)Reply
Generally agreed. A few other specific classes of AI images I've frequently nominated for deletion are:
  • AI-generated imitation (or "retouched") historical photographs or artwork
  • Imitation or unofficial emblems
  • Images with grey checkerboard backgrounds, often with weird glitches - this is a common result when users ask AI chatbots to "remove the background" of an image
  • AI-generated infographics - these are problematic because they're often full of text that is practically impossible to correct
  • AI-generated maps, charts, or graphs - which are usually malformed and/or based on no source data)
Omphalographer (talk) 23:22, 18 June 2026 (UTC)Reply
I would add that all newly uploaded and unused AI generated files are out of scope. GPSLeo (talk) 04:40, 19 June 2026 (UTC)Reply
  •  Oppose. It's fine to mention all of these somewhere is problems with AI, but we should have (presumably narrow) specific criteria for what AI-generated images are allowed, not a potentially gameable laundry list of bases on which they are disallowed. - Jmabel ! talk 04:42, 19 June 2026 (UTC)Reply
 Support the idea. We can (and should perhaps) have criteria for both inclusion and exclusion. Sinigh (talk) 08:11, 19 June 2026 (UTC)Reply
  •  Comment: I don't think this proposal is ripe for a !vote. As I suggested in a recent RFC, Commons is many things to many people, and what may be misleading in one context is at least plausibly useful in another. There are the seeds of good ideas here, but some of them probably need to exist in the framework of Wikipedias (with strong editorial policies), rather than Commons itself. Rather than a policy or guideline that ought to be general, what about expressing this as a value judgment in essay form, using some concrete examples to argue how these characteristics are inherently incompatible with featured content or specific kinds of reuse? TheFeds 00:26, 25 June 2026 (UTC)Reply

Commons:Bots/Requests/BorkedBot - Automated image labeling

[edit]
Latest comment: 1 day ago1 comment1 person in discussion

It would be good to have more eyes on this proposal. The tl;dr is "what if we used AI to add provisional content descriptors to images while waiting for humans to catch up".

I expect it to be somewhat controversial, but I think there is value in it if agreement can be reached. BrokenSegue 14:47, 23 June 2026 (UTC)Reply

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