Allow the Upload Wizard to automatically convert MP4 to WebM

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

Is this something the Commons community is willing to accept? Ie has the position changed since the 2014 RfC? --Doc James (talk · contribs · email) 09:05, 29 March 2026 (UTC)

Increase data maximum of (tabular) data pages

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)

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)

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)

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)

Limit of 4 MiB would already be of huge help :) --PantheraLeo1359531 😺 (talk) 07:33, 24 April 2026 (UTC)

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)

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

The template "Logo" is confusing.

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)

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

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 Sengupta^Talk 10:48, 30 May 2026 (UTC)

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)

 Support -Consigned (talk) 00:09, 3 June 2026 (UTC)

Project scope rewrite

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)

• 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)

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)

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)

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)

For news, that could very well go to Wikibooks instead. SVG-image-maker (talk) 20:29, 2 June 2026 (UTC)

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

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)

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)

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)

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)

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)

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)

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)

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)

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

Commons:Uploading works by a third party

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

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

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

1. i dont see how its content is not already covered by other policy or guideline pages including com:l com:dw...
2. it contains unnecessary, problematic and esoteric jargons such as RTFM.

...

see Commons:Village_pump/Proposals/Archive/2026/02#c-RoyZuo-20260220151200-Grand-Duc-20260218200300. RoyZuo (talk) 11:17, 15 May 2026 (UTC)

Of course, the content of COM:THIRD is already covered elsewhere. That's by design, especially as Jmabel's text is IMO construed in a way to comply to the meaning of the wording "guide-line" by the letter. It's an amalgamation and condensation of information spread over several sources. And this is pedagogically a sound thing: it removes the need for any interested party to search for information morsels among possibly currently non pertinent data. COM:L for instance elaborates on the background of licenses, whereas COM:THIRD simply stresses the actual needs of our project: the actual free license. Similar case for COM:DW: lots of explanations for and about actual use cases there (like toys and pop culture), THIRD focuses upon the main points with the most relevance (broken down to the core: Q, "Somebody else made something, how to proceed? A, "Get a free license release!").

As for why I said "to comply to the meaning of the wording "guide-line" by the letter": for a complex subject, THIRD provides a step-by-step guide along a line of thought. It is necessarily long, as that subject, copyright, has a huge amount of factors that need to be observed.

In February, you wrote: "i think the best method to educate newcomers is to write as succinctly as possible, and make short explanatory videos. that's way more engaging and informative than a long page of texts." I agree to disagree, especially on the point of videos. To explain matters that are fundamentally text-based, videos are IMHO not a really suitable medium. Videos are strong in showing geometric relationships of stuff in a three-dimensional area (e.g. model making or Origami) or for showing "production" processes (painting [think en:Bob Ross], developments and behaviours of living beings [slow motions of e.g. bombardier beetles or snapping shrimps, time lapses of flowers blooming or bamboos sprouting] or physical phenomena [examples: videos on the "Slow Mo Guys" YouTube channel]). But translating textual content into a visual or audiovisual depiction is not really straightforward. Furthermore, a video doesn't present itself for parsing information that may be available in the middle of the presentation. In texts, you can skim-read until you're at a section that holds the info you want, and you can easily stop and and resume your reading at any moment. For videos, you're much more committed to watching because interrupting and going back and forth is not as easy as in reading. The translation from text to visuals and maybe sounds can also be detrimental to memorisation (similar to the sardonical saying "Death by PowerPoint"). And while I agree that a succinct writing is desirable, I didn't see much that wasn't succinct and not needed for the subject while translating THIRD. Copyright isn't something that presents itself very well to gamification, so I'm currently lacking the imagination where THIRD could be made more engaging.

About the critique of "unnecessary, problematic and esoteric jargons": I'd like to see more examples besides "RTFM". That one should be already part of the English or even international vernacular, cf. en:RTFM. I don't really understand this issue at the moment. Regards, Grand-Duc (talk) 15:18, 15 May 2026 (UTC)

 Comment I have no real objection, while I would like to have this page translated to more languages. Yann (talk) 17:34, 16 May 2026 (UTC)

Gadget links

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)

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)

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)

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)

Need help writing COM:Arguments to avoid in deletion discussions

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)

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)

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)

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)

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)

Also saying "duplicate" or "superseded" without naming the relevant second/updated file. Nakonana (talk) 10:42, 25 May 2026 (UTC)

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)

 OpposeI don't think it is needed, don't import bureaucracy from en Isderion (talk) 19:32, 25 May 2026 (UTC)

@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)

Hi, Yes, I think that can be useful. Your choice of usernames make me laugh. Yann (talk) 11:04, 27 May 2026 (UTC)

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)

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)

 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)

"Category:Straight-two motorcycle engines"

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)

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

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)

 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)

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)

See Category:Photographs by month by country. Nakonana (talk) 07:20, 2 June 2026 (UTC)

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)

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)

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

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)

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)

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)

•  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)
  • 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)
    • 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)
      • 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)
•  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)
  • ? 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)
    • 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)

      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)

      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)

      "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)

      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)

      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)

Gadget to hide NSFW images

LLM use 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)

• 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)
• 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)

  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)

  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)

  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)

  @Rhododendrites: in what sense is Google Translate not an LLM? - Jmabel ! talk 23:40, 6 June 2026 (UTC)

  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)

  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)

  Being a guideline doesn't change anything at all about the question. — Rhododendrites ^talk |  03:20, 7 June 2026 (UTC)

 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)

"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)

My intention was that warnings are implied by the word "repetitively". Phillipedison1891 (talk) 02:53, 7 June 2026 (UTC)

•  Support Yes, good. Yann (talk) 22:17, 6 June 2026 (UTC)

 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)

 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)

 Support - good suggestion. -- Karim (talk) 03:31, 7 June 2026 (UTC)

 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)

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)

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)

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)

 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)

Mass rename request

For many years I published under the name D Ramey Logan, I use that in every other file I uploaded. My name is Don Ramey Logan, and I would like to run a script that does a bulk renaming of the files that remain under D Ramey to read Don Ramey. I have thousands of photos and it would save everyone a lot of time and effort if I continue to do it by hand. I have a associate that is willing to do the scripting and run CommonsDelinker to rename my files on projects I want to make sure no one complains and drags them to COM:ANU Any body have any concern? Don (talk) 05:17, 9 June 2026 (UTC)

Are you going to ignore the replies again, like you did at your last post? Commons:Village_pump/Technical#Request_bulk_name_correction Andy Dingley (talk) 11:37, 9 June 2026 (UTC)

I did not understand your comment. I am sorry about that. Your reply was in regard to user cat, not file names. Don (talk) 18:27, 9 June 2026 (UTC)

And this was also at Commons:Administrators'_noticeboard#Mass_rename_requested, where I replied and said I didn't object, but this posting the same issue to multiple places is really inappropriate, and inclines me against the request. - Jmabel ! talk 14:04, 9 June 2026 (UTC)

Sorry but I am still recovering from a near fatal Enterococcus faecalis bloodstream infection from a botched surgery and sleep a lot. I withdraw the request. :( --Don (talk) 22:40, 9 June 2026 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Let's keep the discussion central at Commons:Administrators' noticeboard#Mass rename requested which is probably the best place to discuss this as it mostly concerns power users and already has more comments. - Alexis Jazz ^{ping plz} 06:08, 10 June 2026 (UTC)

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

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)

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)

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)

@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)

There should be a lossless converter at upload I think. Candidyeoman55 (talk) 06:40, 15 June 2026 (UTC)

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)