This page is used for discussions of the operations and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2026/03.
Please note:
If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.
Purposes which do not meet the scope of this page:
For questions about copyright, technical matters, or help that does not relate to the general Commons community as well as proposals, please see the other discussion boards linked in the blue panel at the top.
SpBotarchives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.
January 02
History maps of Europe
Latest comment: 1 month ago6 comments4 people in discussion
Hi, I would like to discuss the description in all categories of the scheme "Maps of <country> in the <x>th century" (see for example Italy, Belgium, Spain, Poland). There are three different points about the current system I would like to invite comments on:
the wording of the definition in the first paragraph of the hatnote
whether or not to include "you may also be looking for similar maps" (second and third paragraph) of the description
whether or not to re-include a distinction between history maps (in this category group) vs. old maps (not in this category group)
For the first point, there are two proposals, the first is the current "Maps showing all or most of the territory (geographic area) of modern-day <country> - as the lands were in the 8th century (701-800 CE)" which I would prefer to replace with a simple "This category is about maps of the history of <country> in the 8th century (701-800 CE)", given that "modern-day territories" are not always the same as they were in the respective century. Another critism of mine is that "all or most" excludes history maps that only cover smaller parts of the country in question.
For the second point, my argument is that these paragraphs are not necessary, since the links to the Atlas project should be included in the respective parent category (i.e. "Maps of the history of <country>"), which is also linked via template.
For the third point, I find it essential to point out that Commons has always distinguished "current", "history" and "old" maps, formulated in Template:TFOMC: "history" maps include this map of Poland in the 16th century (created recently, depicting the past) but "old" maps include this 16th-century map of Poland (created to depict the present, back then). There are certain grey areas where these categories DO overlap, especially "old history maps", but in quite many cases they don't. The respective category names are quite similar and can be confused, so I would suggest to mention this right in the category description.
I've put my own opinion in italics to explain why I think this requires debate, but I would like for people to check out the scheme examples for themselves, and judge on their own. Peace, --Enyavar (talk) 08:11, 2 January 2026 (UTC)Reply
@Enyavar: I'm trying to understand the first point. A couple of questions that may help me understand:
Would there be no such thing as "maps of Germany" for any date before 1866? Or would we take "Germany" before that date to mean the German-speaking world (and, if so, would that include areas where the rulers spoke German, but most of their subject did not)? or what? (Similarly for Italy.)
Similarly: would there be no such thing as maps of Poland or Lithuania between 1795 and 1918? If so, what would we call maps of that area in that period?
I could easily provide a dozen similar examples, but answers to those two will at least give me a clue where this proposes to head. - Jmabel ! talk18:49, 2 January 2026 (UTC)Reply
Thanks for that question, our categories about "history of" do not really care for nation states existing. Germany's history begins quite some time before it became a nation in the 19th century, and Polish history did not stop during the times of division: Poland in the 19th century is unquestionably a valid category. Our history categories generally imply that people know the limits of a subject without exact definitions.
Your question is getting to the reason why I am uncomfortable with the current hatnote/definition of these categories. I have not checked for all countries in Europe, but I'm quite confident: We do not define the subject of "Maps of the history of Poland" with a hatnote. We do not define "Poland in the 16th century" either. So why would we define the combination subcategory of the two so narrowly and rigidly, that only 6 out of 26 files currently in the category even match that (unreasonable) definition? (And of course, Poland/16th is just a stand-in here, I would argue the same for Spain/12th and Italy/8th and all others)
I would even be okay with no definition at all, besides a template notice (my third point) that "maps of <country> in Xth century" is about history maps, and old maps have to be found in "Xth-century maps of <country>". --Enyavar (talk) 04:53, 3 January 2026 (UTC)Reply
Please read the original post, that is not a comment on the actual questions of this topic. Old maps are not the topic here, this is about history maps (i.e. Maps showing history of specific countries/centuries) regardless of when they were produced.
In our Commons:WikiProject Postcards we have the similar problem. Is this a "old postcard of the German Empire" or a "Postcard of Germany". There we are mostly agree, that today people often search for postcards be the locations of today. So many former German towns are now Polnish towns and so we are categorized this postcards under the polnish name of the town. See also Commons:WikiProject_Postcards#Categories. Best regards --sk (talk) 12:29, 12 February 2026 (UTC)Reply
February 22
Maps from Our World in Data
Latest comment: 19 days ago30 comments7 people in discussion
A suggestion in regards with the maps from Our World in Data: remove from each map the category <year> maps of the world.
These maps weren't published in the years referenced. In addition, it could make the categories of <year> maps of the world more easy to browse.
As with other files in these categories, that's the year of the data. This categorization has large usefulness to find and update outdated images used on Wikipedia. And the category title does not imply that's the year the map was made. Prototyperspective (talk) 20:13, 22 February 2026 (UTC)Reply
I have been meaning to say something about these maps, and this is a good occasion. User:Universalis is right that these maps were not created in that year, and it IS practice on Commons to understand "<year/decade/century> maps" being the maps created in that timeframe, not the maps showing that timeframe - the latter would be better placed under "maps showing <year/decade/century>".
User:Doc James, who is creating the majority of recent OWiD maps that concern what might be called history, is producing them by the thousand each day, at least as far as I can observe. For 2026-02-24 I just checked and saw 5000 edits, most if not all of them creating and categorizing OWiD statistics/maps usually looking like this (1947), this (1664) and this (1800). That is an enormous output and just for example 1764 maps of North America is currently dominantly OWiD maps and I suspect that this is true for basically all year-maps-of-world/continent right now. Case in point: the categories for 1444 maps of Africa, 1445 maps of Europe or 1446 maps of Asia don't even exist right now, but they are already filled with OWiD maps.
The titles I suggest above are up for debate. Is it more practical to use "Our World in Data maps" or can it be shortened to "OWiD maps" ? Also, should it be "showing" (as per our category branch "maps showing <year>") or should it just be "of" ? --Enyavar (talk) 03:58, 25 February 2026 (UTC)Reply
Sure we can adjust the categories however folks wish. We have additionally build a tool to help with more fined toned mass categorization. See Help:Gadget-CategoryBatchManager.
With respect to numbers, yes have uploaded about 600K so far and it looks like I am maybe a third done, so maybe 1.2 million more to go. Will likely not finish until this fall. Doc James (talk · contribs · email) 06:03, 25 February 2026 (UTC)Reply
and it IS practice on Commons to understand "<year/decade/century> maps" being the maps created in that timeframe, not the maps showing that timeframe this is an inaccurate statement. Look into any of these categories of years of the recent few decades and you'll notice how what you said is false. What you said applies to old maps and there usually the data shown is not known better than year of map made or the same. Prototyperspective (talk) 13:47, 25 February 2026 (UTC)Reply
In 2014, it has been decided that "<year> maps" should essentially be empty disambiguations, and we should use "maps created in <year>" and "maps showing <year>" instead. Practically, this rule has never been enforced, and has lead to many simmering debates ever since. I'm striking my quarrelsome nitpicks from my previous comment, in order to focus on the suggestion at hand: Creating special categories for OWiD maps. Okay? --Enyavar (talk) 11:04, 26 February 2026 (UTC)Reply
Doc James has stated above that we are going to have about ~1'800'000 maps once the current run of creating these files is finished. And I don't even think that will be the end of it. So I agree, we need to have a good standardized cat structure, and I am willing to hear if Doc James also has input on good names, or input on which names are less good. With that lead:
As far as I can see, we do have the following seven regions over which these maps are distributed: "the world", "Africa", "Asia", "Europe", "North America", "Oceania", "South America". These are the seven most common frames I noticed so far, please correct me if there are more. "World" is probably going to be a bit larger, but I don't think we should neglect the other regions, which are all going to be equally densely filled.
Now, thinking about the best name structure. I would prefer to pre-fix the data source, similarly to how we do it with other major map providers like "OpenStreetMap maps of...", "USGS maps of...", "ShakeMaps of earthquakes in...": The most important qualifier gets frontloaded. For easy manual input, I would prefer the name "OWiD maps of...". However, the categories are unlikely to get assigned manually, and it is much easier to understand what the acronym means when it is written out. So right now, I would tend to go with the general Our World in Data maps of... as the prefix, then followed with the seven (?) regions identified above.
Afterwards comes the suffix. Prototypeperspektive suggested ... showing <year> data, my own ideas leaned towards ... in <year> or ... showing <year>. These suggestions all look equally good to me. Prototype's suffix has the advantage of pointing out that these maps are data-driven and not cartography-driven. So I think that would be best.
If the above suggestion seems agreeable... how difficult is it for Doc James to change the automated exports and the templates that are currently in use? And would you be able to do an automated re-categorization of all the already existing files? Would you need help? --Enyavar (talk) 18:54, 28 February 2026 (UTC)Reply
[[:category:Our World in Data maps of <region> showing <year> data]] would be subcategory of [[:category:Our World in Data maps of <region>]], [[:category:Maps showing <year>]] and [[:category:<year> maps of <region>]]. At a later point, I would like to reshape the last of the three parent categories to bring the OWiD maps under the 20th-century/1940s branches of <region>. With the example above, there is currently no sufficient subdivision of Maps of the history of Oceania, but the idea is creating Maps of Oceania in the 20th century and Maps of Oceania in the 1940s, and that would again be a subcategory of Oceania in the 1940s... But I think that work would not affect the OWiD-maps and their templates itself. --Enyavar (talk) 19:13, 28 February 2026 (UTC)Reply
You are currently categorizing them upon upload by two mechanisms, one is the template:Map showing old data, the other is assigning regular categories. Right now, neither of these mechanisms is a bespoke template designed for OWiD content.
I can imagine a template that works like {{OWiD maps showing|Africa|1758}} that would create the categories we contemplated above, including links to skip forward/backward and also links to skip to the other continents/world extent. If we used such a template to create the category framework discussed above, couldn't you adapt your exporting automatism once that exists? I can only image it would take less work later.
Before I attempt working on such a template myself, I'm asking a few users who I suspect have more routine in templating, @Clusternote, AnRo0002, and Reinhard Müller: My question is how you would go about it: templates for the file descriptions; templates for creating these categories; or both? Are there pitfalls I am not aware of? We are talking here about ca. 2 million standardized files ranging from very few around the year 1021 to an abundance of such files for 2021, with hundreds of files per year per continent in 1834 already. The maps are optimized to be used in slider-frames elsewhere; for Commons I'm more concerned with handling the categorization. Thanks in advance! --Enyavar (talk) 21:51, 3 March 2026 (UTC)Reply
As for #2 I would have suggested "... showing the 1940s" and "...showing the 20th-century" as parent categories. But you're right, I talked above about "<year> data" so "<decade>s data" and "...<century> data" would be the logical consequence. Now I'm less sure about the format. I am not married to the idea of requiring the "data" suffix, but as long as the template could be made, I see no real problem. @Prototyperspective: , what do you think about "Our World in Data maps of Oceania showing 20th century data being the respective category on the century level? Enyavar (talk) 19:11, 5 March 2026 (UTC)Reply
The usage of the templates is super easy, no need for any parameters specifying the continent or the year, they take everything they need to know from the name of the category they are used in.
The names of the continents are automatically translated using Wikidata labels. The first part of the title and the text above and below the navigation blocks are just examples. These can be used as an explanation for the category which is centrally maintained and must only be changed once if something should be changed, and if the texts are final, we can also make them translatable.
P.S. Looking at the currently existing category tree about maps, I really think that the OWiD categories shouldn't be in Category:1947 maps of Oceania or Category:1940s maps of Oceania. For centuries, we already have Category:Maps of Oceania in the 20th century, and I think it might be a good opportunity to introduce these categories also on a decade and year level. If you want, I can also create the templates for "Maps by continent and century/decade/year shown". And/or whatever you consider useful for building the correct parent structure for the OWiD categories. --Reinhard Müller (talk) 14:37, 6 March 2026 (UTC)Reply
The decade-template for the world in the 1940s did not work (lua template cannot find "the world"), I hope this can be fixed. Aside from that it looks pretty great. Sorry, two more nitpicks, some links only appear once some other part of the structure has been fully built up. The year-ribbon only shows up once the decade-category is in place; and it seems as if the decade template only shows up once the century-category is in place? Also, I think that the subcategories could be sorted with a space (" ") instead of the "@".
I agree with your proposal that instead of "1947 maps of Oceania" we should have "Maps of Oceania in 1947" which would be the "maps showing"-version. "Maps of Oceania in 1947" would be a subcategory of "Maps showing 1947", "Oceania in 1947", "Maps of Oceania in the 1940s" respectively. This category would then hold the OWiD maps and all maps that show Oceania in 1947 through the historian's lens, similar to how we already have Maps of Poland in the 16th century (see also one thread above...) and Maps of the world in the 1940s.
I fixed "the world" (ooh, it feels good to write this ;-))
It is generally true that the template works best when the categories are created top down (i.e. first the centuries, then the decades, then the years). Still the navigation ribbons should appear even if the parent category does not exist (yet), I will have to investigate why they don't. But for the addition of the correct parent categories for new categories, it is important anyway that the parents pre-exist.
I have (years ago) thought a lot about the question of logical sort keys, currently they are used very inconsistently across commons. I've even made a page summarizing my thoughts which you may or may not agree with. About this specific case, I think the space is widely used for meta categories (Blah blah by xyz) and should be reserved for that, and that the @ has the advantage of being sorted after all the other special characters, so if for example the category key "*" is before the alphanumeric subcategories, it is also before the numeric subcategories if the numeric are sorted as @. In the end I don't think in our case it makes much of a difference as long as all the subcategories use the same key so they are sorted correctly - which is taken care of by the template.
About the "Maps of Oceania in 1947", would you want to also create them right now? Should I create a {{Category description/Maps by continent and year}} (and decade and century), and adapt the OWiD templates to the new parents?
I don't use a bot, and I think that the CategoryBatchManager can add parent categories, but not a template. But since you don't have to change a single letter when copying the template from one category to a similar one, it can be done very fast. --Reinhard Müller (talk) 18:02, 8 March 2026 (UTC)Reply
About the "Maps of Oceania in 1947" - yes, you could create a template for that, as well. We already have parts of that, but right now they were created in a manual fashion: North America/1770s and Asia/18th and Europe/11th. I'm not yet fully eager and ready to apply this structure as long as the other treat about #History maps of Europe is still unresolved. But having the templates prepared now might help later. Once those maps-per-continent-shown-by-year exist, the OWiD template would be switched from "1940s maps of Asia"+"Maps showing the 1940s" --> "Maps of Asia in the 1940s" and so on. --Enyavar (talk) 19:51, 8 March 2026 (UTC)Reply
I have not (yet) changed the parent categories for the OWiD categories. Please just let me know when I should do that.
Also please don't forget that the texts above and below the navigation ribbons are just placeholders (in the OWiD templates and the new templates), and they should be finalized before the templates are widely used. --Reinhard Müller (talk) 22:02, 8 March 2026 (UTC)Reply
Looks great; thanks very much. I just don't know how complete these cats currently are and will be. They could be made complete via deepcategory category intersections and moving files with cat-a-lot. Prototyperspective (talk) 18:22, 9 March 2026 (UTC)Reply
But first, we need to categorize the OWiD maps. I populated the 1940s structure with a few hours of Cat-a-lot, but there is a catch: all these maps currently have the template {{Map showing old data|year=1942}}. For the 1940s alone, removing that template means manually editing 17'500 files. We must use a bot to do these edits, I think. The algorithm, for all ~75'000 maps of Asia would be roughly as follows:
for all files in [[Category:Our World in Data maps of Asia]]
if "{{Map showing old data|year=YYYY}}" occurs in the file:
take the YYYY as a variable to insert "[[Category:Our World in Data maps of Asia showing YYYY data]]" //** a single category for the location and year of the map **//
if that inserted category does not yet exist: create it with "{{Category description/Our World in Data maps by continent and year}}" //** (as helpfully provided by Reinhard)**//
take the file name as the variable topicname and strip File: and , Asia, YYYY.svg (or ,Asia,YYYY.svg) from that variable
if that inserted category does not yet exist: create it with "[[Category:Our World in Data maps by topic]]" //** in many cases, better names might be found, but that cleanup can be handled afterwards manually where needed **//
remove all occurences of "{{Map showing old data|year=YYYY}}", ""[[Category:YYYY maps of Asia]]" and "[[Category:Our World in Data maps of Asia]]"
(else leave the file alone)
repeat the same with "Africa", "Europe", ["North America" or "NorthAmerica" would need to be mapped onto "North America"], "Oceania", and so on.
I do not know how exactly to program a bot, but I think this would do the trick, not only to create and populate the categories for continent-by-year, but also to have distinct categories for each topic. Right now, I don't think the latter exist yet. --Enyavar (talk) 19:51, 8 March 2026 (UTC)Reply
For the 1940s alone, removing that template means manually editing 17'500 files: I haven't been following all of this, but why manually? - Jmabel ! talk20:53, 8 March 2026 (UTC)Reply
True, the bot run would also touch those files. I just wanted to emphasize that so many files cannot be realistically processed manually, and then formulated how I think this could be automated. I struck the word in my earlier response. --Enyavar (talk) 22:21, 8 March 2026 (UTC)Reply
Help needed to close 6,323 Category for Discussion cases
Latest comment: 4 days ago14 comments8 people in discussion
There is a large and growing backlog of open CfDs. It would be great…
if more people would participate in these discussions to move them toward closability and
if more admins or CfD/backlog-experienced users would to go through CfDs to close closable discussions (if there is a way to filter these for discussions with 3+ participants, that would be useful)
CfDs over time – this chart was made possible by generative AI and uses data of scraped from Wayback Machine archives of Category:Categories for discussion via a new tool
The oldest open discussions are from 2015. If you have any ideas how to increase participation or more easily solve more CfDs, please comment. For example, maybe there is a way to see CfDs for subjects one is interested/knowledgable in or users could identify users relevant to CfDs and ping them from there to get these to participate (e.g. top authors of the linked Wikipedia articles identified via XTools).
CfDs shouldn't be closed for the sake of it prematurely though – the reason for why they have been started should really be solved before they're closed – sometimes this requires some restructuring, renaming or categorization work. For info about CfDs, see Commons:Categories for discussion. Prototyperspective (talk) 13:55, 6 March 2026 (UTC)Reply
Perhaps we can categorize CfDs like we categorize DRs, so people who are only interested in a specific subject can browse CfDs relating to that subject more easily. Thanks. Tvpuppy (talk) 15:19, 6 March 2026 (UTC)Reply
Good idea. Joshbaumgartner had already set up Category:Category discussions by topic in mid 2024. However, it can be difficult to categorize CfDs into these as these topic categories probably would need to be and are very broad where deepcategory fails. This probably is part of the reason for why the current subcategories are very incomplete and contain just few CfDs (which means that cat is currently not very useful and also doesn't seem to be used much so far). For example, when trying to find more than the 1 CfD currently in the Culture-related CfDs, this search does not show any CfDs and neither does this search. Prototyperspective (talk) 18:38, 9 March 2026 (UTC)Reply
Indeed, it was an attempt to do exactly that, but as a manual process it isn't going to be useful unless broadly adopted as part of the CfD process and probably needs some better gadgetry to make it user friendly for nominators to categorize their CfD from the start. Josh (talk) 01:11, 10 March 2026 (UTC)Reply
Agree. Adding some functionality to a widely-used gadget or a gadget in general may not be needed for this to be broadly adopted: one could have a bot auto-categorize the CfDs and then then better-populated by topic cat could maybe be made more visible in various ways so more people use these. Since the deepcat queries break, I don't know how that could be done theoretically – maybe via petscan or quarry or the Commons SPARQL query service. Prototyperspective (talk) 12:46, 10 March 2026 (UTC)Reply
I agree that categorizing CfDs could be useful, both for users to find them to comment, and for admins to find them to close. (That's especially true where the discussion hinges on specific knowledge bases, or is conducted in non-English languages.) I don't love the idea of canvassing users, even by neutral/automated criteria, unless it's strictly opt-in.
Like many other tasks, the CfD backlog is mostly due to a shortage of admin time. (Experienced non-admin users can also close discussions, and I think it's a great place to learn admin for those considering the mop, but obviously they are not able to delete categories when needed.) There's also a notable lack of tools to efficiently work with CfDs, which means that the workload for a given CfD is substantially higher than a DR. I can close DRs or process speedies on my phone in a few spare minutes on the bus, but closing CfDs requires my laptop and a longer block of time.
Tool to close CfDs - it should be one click to add {{Cfdh}}, {{Cfdf}}, etc, just like it is with DRs.
Tool to rename all categories in a category tree, and move associated files
Tool to add/remove CfD notices on all categories in a given category tree
There are some other less common but time-consuming CfD closure tasks that would benefit from tools. For example, sometimes we decide to merge two category trees with identical structures but different names, or to upmerge a large swath of categories. Having to work through these can make a single CfD close take hours.
Some of these may exist in some form on enwiki or other wikis, which could reduce the work required from "write from scratch" to "localize to Commons". Given the importance of the CfD process and the limited capacity of volunteer developers, I really think these should be developed and maintained by the WMF. Pi.1415926535 (talk) 20:31, 6 March 2026 (UTC)Reply
Opt-in notifications of CfDs aren't feasible I think – a related idea however would be to maybe post about categories of CfDs on WikiProject pages about that broad subject.
Regarding the shortage of admin time maybe an approach could be to get more sufficiently experienced users to help with closing CfDs. Only a fraction of CfDs involve cat deletion and one can also delete these by renaming the category without leaving a redirect in many of these cases.
More tools for CfDs would be great – or probably CfD-features in existing tools like Twinkle. To your useful list of missing features, I'd add a tool to modify many category pages at once similar to VisualFileChange. I've asked about it at Commons:Village pump/Technical#Editing many categories at once and this could also be used for the add/remove CfD notices on all categories in a given category tree functionality. I'd like to note though that afaik most CfDs are not held back by this but rather by a lack of user input or nobody closing the closable CfDs. Prototyperspective (talk) 14:27, 16 March 2026 (UTC)Reply
Since the thread was started, the backlog has been reduced to 6311 – not much of a change but it's good to see that the direction currently is downward, not further up. Maybe what could help are summaries of the outstanding issues/question for bundles of stale CfDs. However, that probably doesn't scale above a hundred or so CfDs and most CfDs are rather short. A way to connect people knowledgable/interested in a certain topic with open CfDs in that area seems like a better way forward. If CfDs were categorized by broad topic, this would however still require users to proactively go to that category and see if it has any CfDs of interest to them.
Uncategorized files over timeWith the increasingly large numbers of uncategorized files, I think there needs to be some thought and work on how to address this at scale / effectively without consuming so much volunteer time. One idea is to better aid and facilitate uploaders to categorize their files at upload as outlined in Commons talk:WMF support for Commons/Upload Wizard Improvements#Guidance/facilitation of categorization; another idea would be to have tools suggest categories based on file-title, description, metadata, and content, similar to User:Alaexis/Diffusor.
On a related note, ultimately all of this is largely a two-stage process where adding initial category/ies is stage 1 and diffusion into more specific categories is stage 2; categorization can be improved a lot if initial category/ies are set if the one/s set is/are about the main topic/usefulness/uniqueness of the file. Probably both stages need some development.
.
I've created the chart on the right a few days ago using some new tool that I coded with the help of AIs – does somebody know how to get data for between mid 2015 and early 2024 or why there is this quick rise from 2012 to 2015 but a decline by 2024? Prototyperspective (talk) 12:58, 10 March 2026 (UTC)Reply
The "two-stage process" that you describe is certainly helpful, e.g. by using Category:Unidentified by topic, but I am even more proud about files that I can categorize to their final location. In many cases, this might involve creating a new category for a person, of which a Wikipedia article exists in any language. This new category will, initially, most often contain only one file, but it can be inter-wiki-linked to the relevant Wikipedia articles via Wikidata. GLAMorous is a powerful tool, to find uncategorized photos of persons, of which a Wikipedia article exists. Until a suitable bot will be programmed, these photos have to be categorized manually one-by-one, please. NearEMPTiness (talk) 02:29, 11 March 2026 (UTC)Reply
Just my two cents... I think it is the job of the uploader to choose a suitable category/categories. The "penalty" for not doing so, is that an image will remain unnoticed, and is unlikely to be used in a Wikipedia article. Trying to think of a suitable category is a nice way to pass the time, certainly. But we're looking at about 1000 uncategorized images per day, and I consider myself lucky if I can find a category for more than a handful. Regards, MartinD (talk) 20:27, 12 March 2026 (UTC)Reply
If we find 200 volunteers, who will categorise at least 5 files per day, we will proceed faster than the uploaders of uncategorized files, especially if some of the volunteers will do more than 10 files a day. NearEMPTiness (talk) 20:31, 13 March 2026 (UTC)Reply
Good point but there's also good counterpoints to this. These include that 1) many of these files are copyvios or would be good to delete for other reasons (like being blurry) so going over them is useful 2) often, categorization is hard depending on the file so it may need some Commons contributor to cat it properly 3) many of these files were just transferred from Flickr or other sites – these aren't just original content of the uploads so it's not the file creator who failed at that and many of especially these files are quite useful but missing in the cats which is a disadvantage to Commons and in Commons' interest to address.
The aforementioned guidance in the UploadWizard could involve showing the info that the image is less likely / easy to be found and used if there is no proper category set. Prototyperspective (talk) 23:23, 16 March 2026 (UTC)Reply
And also while the uploader should do it, they don't necessarily know why or what a fitting category may be. Thus, better guidance/help with categories within the UploadWizard would be beneficial.
Additionally, it doesn't have to be specific categories or changes on individual files – instead of concluding contributors should not categorize uncategorized files, a better skeptical conclusion I think would be…
to limit things more to or prioritize categorizations of whole batches. For example, one can enter search terms and categorize dozens of files at once and more patterns like that would be great on the project page marked in yellow above.
and to categorizes lots of files at once at a glance without going into the details of the specifics – for example maps into Category:Unidentified maps and photos of landscapes into Category:Unidentified locations (here note that the photos should be about the locations, not about other things like specific events or specific objects that just happen to be at locations that are unidentified)
Latest comment: 1 day ago61 comments18 people in discussion
Is there a feature on the Wikimedia Commons that allows people to hide/blur NSFW images (images depicting nudity, gore, etc.)? If not, should we implement such a feature? Some1 (talk) 16:44, 14 March 2026 (UTC)Reply
This is a perennial suggestion. Even if technically feasible, the very large amount of volunteer work needed to tag images, and the vastly cultural and personal ranges of what would be NSFW, make it unlikely to be effective. If there are images you personally do not want to see, the suggestions at en:Help:Options to hide an image should be easy to implement on Commons as well. Pi.1415926535 (talk) 21:56, 14 March 2026 (UTC)Reply
Tagging images would be as easy as adding them to a new 'NSFW' category or the like. And there should be an easier way for editors to hide/blur these images without to log in and mess with the common.js or .cs. Like how Google search has the 'SafeSearch' option that one could turn on to blur explicit images. With all the age verification laws cropping up around the world lately, there is a possibility that one day, the Commons will be affected. It's better to be prepared than to scramble when the time comes. Some1 (talk) 22:08, 14 March 2026 (UTC)Reply
We have 136 million files. Adding this proposed category would require checking every one of them - a workload equivalent to about 1/8 of all edits ever performed on Commons (and about 1/5 performed by humans) - with no actual benefit to Commons. The automated systems used by sites like social media platforms have significant false positive and false negative rates, as well as significant biases introduced by their training sets, and would not be suitable for use here.
Unlike social media sites, Commons users also understand that there is no universal definition of NSFW. It depends massively on cultural norms, personal views and comfort levels, context of individual files, and what those with power wish to designate as "inappropriate" to further their own aims. Things as diverse as nudity, interpersonal acts like sex or kissing, depictions of religious figures, depictions of people, speech and symbols representing certain views, medical imagery, and animal behaviors may be NSFW to some people and not to others. Many governments would wish to designate files showing protests of dissenting views, the existence of LGBTQ+ people, and the existence of disabled people as NSFW because they represent contradictions to their ideology.
As I've written before when this topic came up, there may be some subject areas where an opt-in filter might have definable criteria, a relatively low chance of use for censorship, and a feasible number of files to check. Nazi symbols is a likely example. But those represent a very small subset of anyone's NSFW definitions. There is plenty of Category:Content-control software out there for those who wish to control what they see. Pi.1415926535 (talk) 23:12, 14 March 2026 (UTC)Reply
I think you're letting the perfect become the enemy of the good. There are plenty of files on Commons which any reasonable person would consider NSFW - e.g. photos of human genitalia, images and videos specifically described as pornography, or those Panteleev photos (you know the ones). We don't need to review every single image; simply tagging images which are already in categories which identify it as likely to be objectionable could get us a lot of the way there. Omphalographer (talk) 02:16, 15 March 2026 (UTC)Reply
Your definition of what NSFW would be likely be different from what someone in Dubai would consider NSFW or someone in Singapore. Governments and organizations would want us to put everything related to LGBTQ+ behind a NSFW filter, Israel would consider pro-Palestinian protest images NSFW, etc. Nudity is also a cultural specific matter. Abzeronow (talk) 03:13, 15 March 2026 (UTC)Reply
Easy: The WMF can add an option that allows individual readers/editors to checkmark certain categories they themselves want included in NSFW filter. Some1 (talk) 03:26, 15 March 2026 (UTC)Reply
I think individual opt-in filters would be fine to have. The problem is how to implement this. The thumbnails on gallery pages are requested directly from the media server without a request on the file page content. GPSLeo (talk) 05:36, 15 March 2026 (UTC)Reply
We just deleted a video on order from the Australian internet censorship organization. COM:CENSOR is de facto not in force anymore Trade (talk) 21:53, 23 March 2026 (UTC)Reply
It works with structured data statements but so far not all or most NSFW files have these set
It does not blur NSFL files such as images showing torn open dead human bodies
I'm not sure how it works – I think it would be best if it worked like on reddit where it blurs the file content and that one can see the individual file by clicking on a button on the image
Support improvements to this gadget and making it easily enable via the preferences and then some thoughtful discussion on whether and which additional things could be done (example: making the gadget usable to logged-out readers). Prototyperspective (talk) 16:39, 17 March 2026 (UTC)Reply
Comment This keeps coming up, but we never get a coherent, concrete proposal, or even a good list of the considerations for a system that would support this without imposing censorship on those who do not want it, or a set of options on what we might consider supporting. I'd be very open to a serious discussion on this front, but it is almost impossible to react intelligently to what is little more than a hand-wave. - Jmabel ! talk23:08, 15 March 2026 (UTC)Reply
Comment People often talk about this as if its a technical problem. It really isn't. The moment we start doing this we have to define what is and is not NSFW. Nobody wants to open that can of worms. The technical problems are trivial comparatively. Bawolff (talk) 23:09, 15 March 2026 (UTC)Reply
Comment I don't think anyone has suggested full-out censorship. Even the OP just requested hiding/blurring. But especially the "Search Media" function should be configurable to have personal settings that blur certain images that come up while searching. The image would then only be displayed, when actively clicking on it. Which images would be blurred? All images from the category that you as a user have determined to be nsfw for yourself, for example all media in Category:Human sexuality or category:Violence (if you consider war paintings and pictures of swords as too obscene). --Enyavar (talk) 11:43, 16 March 2026 (UTC)Reply
Makes sense. Currently, category:Violence would be way too broad to be usable for this. Moreover, it would need some sort of caching as the dynamic deepcategory search operator breaks on such large categories. Prototyperspective (talk) 14:00, 16 March 2026 (UTC)Reply
Just directly in those categories or also subcategories. If you include subcategories, to what depth? Like this isn't as simple as you are making it out to be. Bawolff (talk) 18:48, 16 March 2026 (UTC)Reply
This is the main problem: We would need to store huge index lists of these files to not slow down image loading when enabling such filters. GPSLeo (talk) 19:51, 16 March 2026 (UTC)Reply
Honestly, I don't even think that part is that big an issue (or at the very least there are solutions to that problem). The real challenge is coming up with the list in the first place. Bawolff (talk) 15:55, 19 March 2026 (UTC)Reply
Do you have a specific AI system in mind? AI isn't magic, it still requires making decisions about what type of content the AI thinks is gore or genitalia. On top of that AI adds complications by often focusing on the wrong things (e.g. There was a famous AI system to identify NSFW photos that turned out to just be identifying photos where the subject was wearing lipstick). Bawolff (talk) 16:20, 19 March 2026 (UTC)Reply
I will propose a system Media is requested from thumbnail media server sending an id 0 or 1 for safe search on or make it into a binary for selective Each image will be assigned a “rating” or classification as nsfw
a binary table
Gore
Violence
Non sexual depictions of genetailia
Sex
Etc
Etc
Etc
Etc
yes
1
1
1
1
1
1
1
1
no
0
0
0
0
0
0
0
0
Lets say i want to set my preferences as no gore. Violence no genetailia no sex That would become 01000 The server would let violence through like body cam footage Cyberwolf (talk) 16:03, 19 March 2026 (UTC)Reply
You would still have to agree on the scale then. There is no way to do any sort of collaborative rating without deciding on a rubric. Bawolff (talk) 16:48, 19 March 2026 (UTC)Reply
You make the flawed assumption that it has to be perfect. It's not perfect on reddit. It works on reddit. It's used on reddit. It can work here. Your first two examples are not NSFW. And one can readily discuss and refine criteria, types of cases etc or even just let people edit and work with whatever results there is. E.g. which SD depicts are set which is how the gadget currently works. Prototyperspective (talk) 18:17, 19 March 2026 (UTC)Reply
I don't think it has to be perfect, I do think there has to be some shared agreement on the categories or at least a straw man proposal of what the definitions of the categories should be. Eventually people will fight over what should be in which categories, if the definitions of the categories boil down to WP:IDONTLIKEIT, the fighting will just never end. Reddit works by moderators making arbitrary, unappealable decisions. If people want that system, that's fine, but they should actually explicitly propose that. As far as the gadget goes, I'd say its fine if that's what people want but those depict categories are only correlated with what people generally mean by NSFW so I'm not sure people will actually be happy with it as a NSFW filter. In general I don't object to any of these idea so much as object to people hand waving all the details away. I just want people to make specific proposals detailed enough that they could actually in principle be implemented, so that we have something to actually debate the merits over. Bawolff (talk) 18:40, 19 March 2026 (UTC)Reply
I don't think there will be much of an issue. Just define what should be blurred as NSFW and what doesn't. There aren't really any new categories or structured data – basically things already exist and one would only need to decide which to blur when the user turns on some NSFW toggle. Afaik things on reddit are blurred by whole subreddits blurring all posts by default, e.g. Videos of human sexuality would have all its files blurred, and less often are other kinds of posts marked as NSFW by the person posting based generally on common sense (probably <2% is mods tagging posts NSFW retroactively also based on loose common sense). A proposal consists largely of technicalities of how to make blurring files based on user preference possible and secondarily ways to identify which posts to blur where what's currently used by the gadget are a set of structured data tags. If this is implemented, discussion can follow which SD tags to put under NSFW if and how to make it possible to specify exceptions (individual files and files that also have specific SD) and how to tag all the relevant files (most or at least many do not have these SD tags set and they could be set via the categories). Prototyperspective (talk) 21:22, 19 March 2026 (UTC)Reply
"Just define what should be blurred as NSFW and what doesn't" Why would an impossibly comprehensive list be needed in order to have such a feature on the first place?
Can't we just start with "close-up photos of veiny, human penises" and then later add more to the list as time progresses after community consensus on Commons:Village pump/Proposals?
Sure, but someone needs to actually do that. Make a category of things that should be blurred, or an SDC property, or a template to put on image pages, or just a wiki page that lists all the images to blur or whatever. The technology part is easy, all it needs is some way to know if an image should or should not be blurred. I personally think creating such a list is politically difficult, but if you disagree, i'd suggest to prove me wrong by making the list. I promise that if someone makes a list of all the NSFW images, i will make a gadget to blur the images. Bawolff (talk) 04:09, 24 March 2026 (UTC)Reply
How is this scope? I think it's narrow enough to avoid the slippery slope arguments @Bawolff:
My concern is not that it is a slippery slope per se (It of course can be), my concern is that nobody will be able to come up with an actual list of files that meet the metric (due to political infighting or community indifference). What I'm suggesting is that if someone actually creates a category (or some other means of listing files) containing all the "Sexual acts" images (etc), I'll happily make a gadget to blur them all. Bawolff (talk) 21:34, 25 March 2026 (UTC)Reply
A bit of different angle. In Persian Wikipedia, there have been many attempts of abusing NSFW concept (and "think of the children") to censor educational images. To the point of trying to hide the statue of David (!!) or may I show you this entertaining incident where the state TV blurred logo of AS Roma. So I don't have any issue with showing nudity or eroticism or even "porn" as long as it's educational. What do I have issues with is gore. And not old pictures from WWII or Vietnam war, but high resolution videos/pictures of people getting beheaded or dying by ISIS or similar. It makes me physically sick. I don't have an easy solution but I wish those at least get some sort of blur filter like Telegram (or maybe we could reduce the resolution? just thinking out loud). Surely we don't need to see details of someone being beheaded to learn about actions of ISIS? I don't know. Amir (talk) 00:39, 20 March 2026 (UTC)Reply
I wish we could have a serious discussion about this just for once without the unserious slippery slope arguments. Constantly having to throw photos of nudity into arbitrary subcategories is tedious busywork--Trade (talk) 02:26, 24 March 2026 (UTC)Reply
In the gadget and if something else was implemented: no, obviously not. There's far too many uncategorized files. For blurring the SD and the categories would be used. One could however also blur files with certain terms in the file title or description (such as 'sex' or 'beheading') if the file does not yet have any categories set. Prototyperspective (talk) 12:15, 24 March 2026 (UTC)Reply
Judging by how the discussion above is going and reading through Commons:Village_pump#Office_action:_Removal_of_file below, it seems like age-verification requirements are more likely to be implemented on the Wiki Commons way before any optional filters. Since there's no blurring features here for NSFW content, and since age verification laws are all the rage nowadays, I wonder if the governments will ever force the Commons to mark certain images as 18+ and then require users to undergo age verification with a logged-in account before they're able to view such images or files. Some1 (talk) 02:16, 26 March 2026 (UTC)Reply
Age verification would be extremely detrimental to the Wikimedia movement as a whole as age verification is essentially a restriction on free speech, and would be a violation of the privacy of our contributors. And I have talked to former and current WMF lawyers about this, I have been told that Wikipedia could be construed as being under laws governing social media if those laws are broadly written. Abzeronow (talk) 03:08, 30 March 2026 (UTC)Reply
Latest comment: 3 days ago13 comments4 people in discussion
I dont agree with the move. While 'Midi' can be translated to 'South'. In French it is more usual to use the word 'sud' for South, 'Midi' is more a general term for a region in the south, not a direction. Midi is not used in rail passenger communication. Smiley.toerist (talk) 13:03, 17 March 2026 (UTC)Reply
I simply harmonised the Wikimedia category with the Wikipedia article, where this discussion already took place back in 2010 (see Talk:Brussels-South railway station). Please check WP's naming conventions for Brussels, where it is clearly stated that if an English name exists or it can be easily anglicised, that name should be used. For Brussels' railway stations, the names "Brussels-South", "Brussels-North", "Brussels-Central", etc. were chosen for the sake of neutrality and consistency. All the other variants (e.g. Brussels-Midi, Brussels-Zuid, etc.) are mentioned in the Wikidata entry. Jason Lagos (talk) 13:37, 17 March 2026 (UTC)Reply
Midi is midday and at 12 oclock the sun is in the south. I think we can change the main category, but keep all subcategories. And certainly not change file-names. These refer massively to Midi or Zuid. Functionaly it is the main station. A lot passengera get confused and try to get of at Brussel Central for train connections. The German hauptbahnhof is much clearer.Smiley.toerist (talk) 14:28, 17 March 2026 (UTC)Reply
Thanks for your quick reply. I am well aware of the origin and meaning of "Gare du Midi", as I am myself Brusselian and francophone. ;-) It is true that the name causes some well-known confusion for international passengers, for the reason you mentioned. Again, the point of renaming the category was for consistency with the established conventions on Wikipedia.
Regarding your suggestions, I fully agree with you that we should not rename the files, as that would not make sense.
For the subcategories, I am more neutral, with a preference for moving them as well to match the head category. Would you see any reasons not to?
I would certainly give priority to first changing the station headcategories. The subcategories are less necessary and create a lot of churn. I have lots of images of the South station in my followlist.Smiley.toerist (talk) 10:38, 18 March 2026 (UTC)Reply
Thanks HyperGaruda - I agree. Right now, Category:Train stations in Brussels is a bit of a mess consistency-wise, with some entries named "xxx train station", others "xxx railway station", and others "xxx station", in contradiction to the principle you linked to. Some also use the (less common) Dutch name, instead of the (more common) French one, contrary to WP:NCBRUSSELS. Jason Lagos (talk) 13:24, 19 March 2026 (UTC)Reply
@Smiley.toerist: I am happy to continue the renaming process as I am familiar with these guidelines, as well as the specifics of Brussels' stations (i.e. regular railway stations vs. multimodal hubs requiring a more general "station" name). Ideally, they should match the corresponding WP categories to maintain a harmonised naming system across the project. In any case, creating a lot of "churn" should not hinder progress if the guidelines request it. Jason Lagos (talk) 13:26, 19 March 2026 (UTC)Reply
The churn is not trivial. As you are not yet a trusted user, lots of mutations are marked as to check in my followlist. I have bigg followlist (28.547) as I try to keep track of every file I uploaded. (started in 2008). As I have uploaded a lot Brussels rail pictures, I now have to increase the followlist parameters the last entries from 250 to 500. I want to keep this list clean and have to manualy Mark as checked each file. This takes time and I cant keep up. Would someone please give Jason to status of trusted, so that that there are not massive amounts of to check files? Smiley.toerist (talk) 09:42, 23 March 2026 (UTC)Reply
Archive today was using users ips to launch a ddos attack. It’s a security risk. The webmaster tried to generate ai porn of a blogger and extortion him with it from ars technica Archive.today maintainer sent threatsPatokallio told Ars today that he is pleased by the Wikipedia community’s decision. “I’m glad the Wikipedia community has come to a clear consensus, and I hope this inspires the Wikimedia Foundation to look into creating its own archival service,” he told us.In emails sent to Patokallio after the DDoS began, “Nora” from Archive.today threatened to create a public association between Patokallio’s name and AI porn and to create a gay dating app with Patokallio’s name. These threats were discussed by Wikipedia editors in their deliberations over whether to blacklist Archive.today, and then editors noticed that Patokallio’s name had been inserted into some Archive.today captures of webpages.“Honestly, I’m kind of in shock,” one editor wrote. “Just to make sure I’m understanding the implications of this: we have good reason to believe that the archive.today operator has tampered with the content of their archives, in a manner that suggests they were trying to further their position against the person they are in dispute with???” End quote. If this doesn’t justify a full cleansing of it here I don’t know what does Cyberwolf (talk) 15:28, 19 March 2026 (UTC)Reply
If I'm not mistaken one can readily edit that template. You could remove the link and see if somebody complains. I think one archive link is enough but as said I don't know much about IA YT archiving. Prototyperspective (talk) 18:19, 19 March 2026 (UTC)Reply
+1. The vast majority of archive.today links from this template simply land on a useless "no results" page anyway, as the site does not archive content without an explicit request to do so. Can someone please mark this template for translation so that we can start rolling out this change? Omphalographer (talk) 21:26, 19 March 2026 (UTC)Reply
Everything archive.today is accused of is very convenient for creating moral panic. But in reality it doesn't even come close to outweighing its benefits. We don't have enough archive services to throw them away. There are many websites that aren't preserved in other archives. Or that even don't preserve properly in other archives. Pages with embedded posts or other complicated features often are not saved (properly or at all) in Wayback Machine, but are saved in archive.today. Blindly removing links to archive.today would create a great harm to the project. Sneeuwschaap (talk) 00:55, 22 March 2026 (UTC)Reply
You are right, in the particular case of YouTube videos Wayback Machine is better than Archive.today. It saves not only descriptions, but sometimes even the videos themselves. Sneeuwschaap (talk) 23:26, 22 March 2026 (UTC)Reply
I appreciate the desire to archive for future reference, but relying on a site that has shown a willingness to co-opt users' systems to attack others is beyond irresponsible. Archive.today and related sites need to be blacklisted. — Huntster (t@c)13:39, 22 March 2026 (UTC)Reply
Maybe, current manager of Archive.today can be somewhat mentally unstable. Nevertheless, the service works for 14 years. And in the first years it automatically archived all links which appeared in various language versions of Wikipedia. And it contains many archives of currently dead pages which were not saved by other services. And for many websites it is incomparably better than other archives. Does the co-opting users' systems for attacks continue till now? Last time when I have read about it, the site was said to send requests with the interval of 50 minutes — in other words, practically never. Evidently, this is/was a temporary stupidity, triggered by an attempt of doxing of the site owner. Such stupidities are very convenient for criticizing and inevitably cause a moral panic, but in reality they are negligible compared to benefits of the service. Sneeuwschaap (talk) 23:26, 22 March 2026 (UTC)Reply
I think you are confusing a "moral panic" for a "moral reckoning". Moral panic implies that there is not actually an issue at the heart of the community's concern. There is absolutely an issue here, and it's much more than a "temporary stupidity". The developer of the archive leveraged its widespread use to aim a DDOS attack at someone they dislike, threatened to change information in the archive in order to slander perceived enemies, and has basically been throwing a fit since this became public knowledge. We underestimate the damage done at our own peril. Honestly, we should never have allowed such a tenuous and legally dubious archive service to become so essential to any Wiki project; we should've seen something like this coming from a mile away. 19h00s (talk) 23:36, 22 March 2026 (UTC)Reply
Reckoning must be rational, not moral. The fact is that the service has been providing verifiability of many sources for many years. In many cases, with no alternatives. With no evidence of harm to the users. And with no evidence of change of information on any archived pages which have realistic educational value. Throwing a fit and threats of creating a public association between a doxer's name and a porn are very terrible, but are not relevant to the case. Sooner or later the doxing-triggered scandal will end, but the archive service will remain. Sneeuwschaap (talk) 19:57, 23 March 2026 (UTC)Reply
It's clear that you are unwilling or unable to see the bigger picture here. This is an independently operated archive service with no external (or even internal) mechanisms for oversight. The person running the archive service has explicitly shown that they are comfortable leveraging and modifying the archive to turn it into a kind of weapon. We cannot in good faith send people to that archive anymore when we know their use of the service could be powering an attack on a third party AND when we have reason to doubt the authenticity of material within that archive. The service may "remain", as you say. But it's no longer a trustworthy archive. It's a liability. 19h00s (talk) 13:30, 24 March 2026 (UTC)Reply
I inform you that in wiki projects we discuss content, not the contributors. So your thoughts about what I am unwilling or unable to see are of no interest here. The known cases of modifying the archive are restricted to a particular conflict and name of a non-notable person. This gives no reason to doubt the authenticity of any encyclopedically significant materials. Or provide, please, examples of modifying archives which are educationally valuable and used in Wiki projects. Is there at least one example among more than 695,000 links? What about the attack on a third party, I wrote above that there are no reasons to think that attack of significant intensity continues till now. It was clear from the beginning that it is a temporary phenomenon. Modifying and attacks are very shameful, they are excellent targets for criticism. Everybody will say how terrible they are. There are far fewer people who will say how good it is to store hundreds of thousands of educationally valuable pages. But contributors of the encyclopedic project must weigh the harms and benefits. Sneeuwschaap (talk) 10:21, 25 March 2026 (UTC)Reply
I'm discussing the content of your responses. And that content clearly shows that you are unwilling or unable to see the bigger picture. 19h00s (talk) 11:38, 25 March 2026 (UTC)Reply
This is not moral panic. I’m not sure what you are talking about. The webmaster created revenge porn (which in the us is a crime in all 50 states) of his critics. Which is unacceptable. This is not moral panic Cyberwolf (talk) 12:37, 23 March 2026 (UTC)Reply
You clearly didn’t read the article i sent and my reasoning. He has no morals “Moral panic” No? There is a ocean sized line between right and wrong It is wrong to use your users on your website without their knowledge to commit an cyberattack You put users at risk for service termination. It is wrong to create ai porn of someone to attack them (crime in the eu and the us) Your defense crumbled already give up The internet doesn’t forget Archive today’s trust is 0 it doesn’t matter the functionality of the website. It matters that the webmaster used Wikipedia and others to funnel people into his cyberattack The archivetoday links are gone Cyberwolf (talk) 15:43, 23 March 2026 (UTC)Reply
In discussions in encyclopedic projects, I prefer to think in other categories than "defense", "crumbled", "give up" and other war-related stuff. Also, I prefer not to stretch my replies with multiple line breaks to fill the entire screen. Also, statements are normally confirmed by links. Especially accusations like "created revenge porn". Sneeuwschaap (talk) 19:57, 23 March 2026 (UTC)Reply
You either don't see the difference between creating and threats of creating, or simply did not read your own link, claiming that it was I who didn’t read It. Wonderfully. Sneeuwschaap (talk) 09:42, 25 March 2026 (UTC)Reply
This video consisted of security camera footage of a graphic murder, reuploaded from a shock site. It was not in educational use on the Wikimedia projects. The video title suggested that its creator (on the origin site) may have originally attempted to link the violence to illegal immigration, but there was no evidence of it actually being used as political speech.
Our preferred approach is to first give community members an opportunity to evaluate content under your own policies, e.g. COM:EDUSE, but circumstances didn’t permit that in this specific and thankfully very rare case. In the future, we will endeavour to ensure the regulator understands and can accommodate that kind of community governance.
While removing the footage in this case seems like the obvious choice, given its lack of use in articles and very questionable educational value, it does raise questions about the place of other footage on Commons that graphically depicts recent murders whose value isn't necessarily so clear-cut. A pertinent example is File:Hamas members attacking civilians in Kibbutz Mefalsim, Israel (October 2023).webm, showing a man (with his face blurred) killed by being shot in the head at close range and subsequently profusely bleeding after falling to the ground. This file was kept after a deletion discussion due to the widespread view that the footage was public domain due to being CCTV Commons:Deletion requests/File:Hamas members attacking civilians in Kibbutz Mefalsim, Israel (October 2023).webm, and is now used in over 20 Wikipedia articles in over a dozen language versions. If the Australian government had requested that this file had been deleted instead, would the WMF reaction have been different? Should footage like this be hosted on Commons to begin with? Hemiauchenia (talk) 23:26, 19 March 2026 (UTC)Reply
I'm personally curious why the Australian government thinks they have jurisdiction over a CCTV video taken from the US. For transparency reasons, I would also love to see documentation of their reasons for the takedown. Abzeronow (talk) 03:34, 20 March 2026 (UTC)Reply
It's because the material on Wikimedia is published/viewed in Australia. The government of a country rules what is published or otherwise happens in that country. Commons often deals with matters of copyright, which is special because treaties establish a fiction that, in matters of copyright, material on the internet is deemed published in the country of the server, which is why Wikimedia often ignores copyright other than the U.S. (It's more complex. Also, courts have found ways to circumvent that by using tort laws.) But in matters other than copyright, there is no such fiction and the normal principle remains. It is then a matter of the ways by which the country enforces its laws. If nothing else works, it can require the service providers to block access. -- Asclepias (talk) 14:08, 20 March 2026 (UTC)Reply
If this is a particular case in that the Australian government ordered the takedown just because it could be viewed in the country, then the file should be restored as Wikimedia should not be bowing to censorship requests from any government. If it is a case that an Australian national or an Australian affiliate would face legal troubles if not removed, then obviously that is a defensible takedown. It would still be reprehensible behavior from Australia's government but then I wouldn't think in that case that restoration would be right. So we should have more details about the reasons for the takedown so this doesn't seem like WMF meekly acquiescing to a tyranny, which would have a chilling effect on the speech of Wikimedia. Abzeronow (talk) 03:33, 21 March 2026 (UTC)Reply
It's certain that the Australian body required the removal of the video because it could be viewed in Australia. See section 109(1)(c) of the Act: "(c) the material can be accessed by end-users in Australia". The other conditions of section 109(1) also apply. "(a) material is, or has been, provided on [...] a designated internet service" (""service" includes a website" per the definition in section 5 of the Act). And ""(b) the Commissioner is satisfied that the material is or was class 1 material". The Commissioner was likely satisfied since at least a one-minute video of the matter was banned by the Australian Classification Board on 29 September 2025 in the case number "esafety INV-2025-05602". In a FOIA release (see at the bottom of this pdf), the specific reasons are redacted. The unredacted part of the decision merely quotes the criteria from the classification scheme. In short, the relevant part is likely that it depicts "cruelty, violence or revolting or abhorrent phenomena in such a way that they offend against the standards of morality, decency and propriety generally accepted by reasonable adults". The Wikimedia version of the video was 5 minutes. With that, the Commissioner likely gave Wikimedia a "removal notice" per section 109 of the Act. So, at least, we can guess reasonably that that was the context. From there, the WMF, applying its policy, apparently evaluated that there were risks. As you say, absolutely, the WMF should give more details.
Asclepias, so if the UAE complains about Category:Alcohol advertisements everything in that category will be oversighted? I agree with Abzeronow. If any country takes issue with content on Wikimedia that is legal in the US and which the community refuses to remove, that country will have to filter their own internet (and several do). - Alexis Jazzping plz03:47, 21 March 2026 (UTC)Reply
So if Iran demanded Commons to take down highly illegal "Zionist Imperialist propaganda" would Commons obey that as well? Trade (talk) 17:52, 21 March 2026 (UTC)Reply
A request from the w:Australian government! So errr it came from w:Anthony Albanese personally? Since you're not mentioning any particular department or subdivision.. WMFOffice, so why exactly was the file deleted? Was it a copyright violation? Seems unlikely, you have no reason to take that down without a DMCA takedown request, which the Australian government probably didn't file. Did it fail COM:EDUCATIONAL? Who knows, but if WMFOffice were to start vetoing community decisions we'd have a serious problem. Did the file violate some US COM:PERSONALITY right? If that was the issue, you'd have told us. Did this particular video end up on w:en:List of films banned in Australia which states the sale, distribution, public exhibition and/or importation of RC material is a criminal offense punishable by a fine up to A$687,500 and/or up to 10 years imprisonment. Such penalties do not apply to individuals, but rather individuals responsible for and/or corporations distributing or exhibiting such films to a wider audience? In 2025 they banned "Videos featuring deaths of Charlie Kirk, Iryna Zarutska and Chandra Nagamallaiah". So I guess File:Charlie Kirk Assassination View.webm (NSFW) was maybe illegal in Australia (they banned two particular clips, I don't know which ones, and the ban for the clips of Kirk was later lifted) Barrister is the UK/NZ/Ireland/Australia term for lawyer. But the user page of the uploader doesn't seem to declare their country of residence. If this is the reason, how did the AU government work out that Illegitimate Barrister fell under their jurisdiction? Is this why Legal is so vague, because they can't disseminate personal info? Or is this just coincidence? This would explain why the upload log was scrubbed though. Edit: what was I thinking, linking to their enwiki upload log?? Our attorneys determined that the order applied to the Foundation under our policy for determining applicable law. That doesn't mean anything, does it? but circumstances didn’t permit that in this specific and thankfully very rare case. I know you think you're explaining yourself but you're really not. we ask that you not reinstate the file and instead address questions to the Legal team via email, at legal@wikimedia.org. Directing questions to your email (which will simply be answered with "we can't talk about that" - been there, done that) is just a transparency pretense. If the reason is what I think it is, I'd have preferred a notice from WMFOffice like: "We deleted File:An illegal Cuban migrant beheads a motel owner in Dallas, Texas (10 September 2025).webm in response to a request from authorities to reduce the exposure of the uploader and local Wikimedia chapters to legal consequences. This is an office action, do not reinstate" - Alexis Jazzping plz05:33, 20 March 2026 (UTC)Reply
I'm wondering if it was from the eSafety Commissioner (eSafety)? This page highlights what is illegal and restricted but why just this file? There are others here that fail eSafety's illegal and restricted online content classes (1 and 2). The vagueness from the WMF leaves us with more questions than answers.
I'm certainly not saying this file should have been kept, but I just find it odd for a foreign government to get involved with something that didn't happen within that country, nor hosted there. This is a concern as what other content could be treated like this? The files (photographs/videos) from the wars that are currently happening overseas next? Bidgee (talk) 12:00, 20 March 2026 (UTC)Reply
" but I just find it odd for a foreign government to get involved with something that didn't happen within that country, nor hosted there." Why not? If Commons obeys the order then there is literally any reason for them not to do that Trade (talk) 17:53, 21 March 2026 (UTC)Reply
It likely has to do with something like this, or more generally this. I'm guessing the WMF received something like a removal notice described there and that, according to their policy, the WMF considered that there might be "risks of project blocking [...] and/or monetary risks" in case of non-compliance. The Australian document hints that compliance can be required within 24 hours of the notice, which may be what the WMF alludes to by "circumstances didn’t permit". -- Asclepias (talk) 12:34, 20 March 2026 (UTC)Reply
The thing is, EDUSE is sometimes explained as files in use in any of the Wikimedia sites. Those files are in minority of the total files on commons. Even if we just counted files in categories where none of the files are in use, in order to facilitate choice of a different picture of the same subject, I am predicting a 54% removal rate of all files on commons. This is based on the first 1000 results from this query:
@Dabmasterars: Why would we care about a request…: If you rephrase that as "Why would we care about possibly being the subject of legal action in Australia, and how would we weigh that against one file of, at best, marginal educational value?" I think the answer as to why we would care becomes self-evident (even if the decision which way to go does not). Clearly this was a legitimate question, whatever you think of the answer. - Jmabel ! talk19:41, 29 March 2026 (UTC)Reply
As much as i never want to view these files, it does seem like NSFL files can sometimes serve an educational purpose, more so if they are documenting an atrocity that people deny happened. Bawolff (talk) 15:52, 20 March 2026 (UTC)Reply
It stands for "Not safe for life". Sometimes its used as a term for images you don't want to look at because they are disturbing or violent or something else other than sexually explicit vs NSFW which commonly means the image is pornographic. Bawolff (talk) 20:50, 20 March 2026 (UTC)Reply
It's objectionable how large that educational value is and whether it outweighs the problems of the file. Specifically, I think such files are much more likely for the value/benefits/plausible-use to outweigh the issues if things in the area #Blurring NSFW images are implemented/improved so that one does not accidentally stumble upon such videos (or even autoplaying gifs) and maybe doesn't see it without first unblurring.
I think it has already been mentioned that the file could be renamed if the title was found to be inaccurate or missing important info or otherwise inappropriate. Prototyperspective (talk) 11:03, 22 March 2026 (UTC)Reply
How does only showing the video when explicitly requested protect the personality rights of the people depicted in the video? GPSLeo (talk) 11:50, 22 March 2026 (UTC)Reply
Fair point but misaddressed to my comment to which this issue/point does not really relate. Instead of addressing this in detail or arguing in one way or another, I'd just like to note that there's all kinds of war photography and -videos that document the horrors of wars as well as war crimes that depict dead people as well as people getting killed on Commons. Prototyperspective (talk) 12:50, 22 March 2026 (UTC)Reply
But we only should host these files if they do not violate the rights of anyone. This means that in many cases we can only host a partially blurred version anyways. That we might want to save the original version to make it available in some decades, when they are old enough, has the same challenges as undeletion when copyright expires. GPSLeo (talk) 13:20, 22 March 2026 (UTC)Reply
Like the inflammatory title or not but this is very clearly a relevant file depicting a highly publicised and notable event. This could severely harm our ability to host CCTV files of high-profile crimes --Trade (talk) 17:42, 21 March 2026 (UTC)Reply
Fr this is just plain out embarrasing. I've seen users get called out for refusing to show up on their AN complaints thread and you can't even be bothered for an entire week @WMFOffice: --Trade (talk) 00:54, 27 March 2026 (UTC)Reply
On the office action, I agree with those above that we could use some additional details about the justification. On the educational value of clips depicting graphic violence, IMO unless the file documents an incident with clearly documented public interest, it does seem like there's a good case for deletion on COM:PEOPLE grounds if not COM:SCOPE. Like [CONTENT WARNING]a non-notable police shooting. Others are more complicated, like someone apparently being accidentally killed by a brick, which happens off-camera, but with disturbing audio and the names of those involved in the description. That one is probably an EDUSE problem first and COM:PEOPLE second. As an aside, I found these by searching for the website name and not user uploads, but the same user uploaded all of them. Possibly this could be solved with a request not to import any further files of non-notable incidents from sites like watchpeopledie? — Rhododendritestalk | 02:51, 27 March 2026 (UTC)Reply
I think the fact that Commons is now governed by Australian law is a much bigger deal than a couple of probably out of scope videos. Considering this isn't a DR, this feel rather off topic--Trade (talk) 05:44, 27 March 2026 (UTC)Reply
Hi all - I was one of the several lawyers and Trust & Safety staff that worked on this notice from the Australian eSafety Commissioner.
Some of you have justifiably asked whether the outcome would have been the same if the files or the jurisdiction had differed. The answer is: no, it often wouldn’t be (and you can see that for yourselves in the Transparency Reports). We look at each case individually, balancing merits and risks.
Commons is an educational project; we’re an educational charity. That means having to think carefully about how any action we take (or inaction) would affect the viability of the Projects, and their value to society. We consistently deploy vast resources (at least vast for us; our whole team is dwarfed by others) to defending takedowns (again as the Transparency Report will attest, as does some of our blogging, e.g. here and here), but we also have to think clearly about the actual merit of defending each one: Are we likely to lose, and what would be the short term and long term consequences of that, for everyone? And is it worth that, from a human rights perspective?
That analysis is especially important in the current legal environment we spoke about, here and earlier, here, which has become quite different from the one we all grew up in.
And as we said originally: the community should be the main assessor of educational value. We’re sorry that in this case you didn’t get a chance to specifically consider it. Instead, we had to look at indirect factors, like the video’s lack of current, meaningful educational use. This sometimes happens, but we strive to keep it to a minimum. We're looking at options to ensure more time for a community review. There may be cases where some of you think something does have some educational value, but our legal assessment of the broader situation still weighs in favour of an Office Action. But those cases should be extremely rare, so long as EDUSE is being diligently defined and applied by the community. That’s because community standards are often stricter than legal standards. PBradley-WMF (talk) 10:14, 27 March 2026 (UTC)Reply
Thank you for the additional context. However, I want to stress that actions like this risk creating a chilling effect on the Commons community. When content is removed via Office action without sufficient transparency, it becomes difficult for contributors to understand where the boundaries lie in practice. That uncertainty can discourage uploads and discussions around borderline but potentially educational material, especially in areas such as documentation of violence, war crimes, or other sensitive but historically relevant events. In that regard, I would strongly encourage the Foundation to publish the underlying takedown request, in redacted form if necessary, similar to how DMCA notices are routinely disclosed. Greater transparency would allow the community to better assess both the legal reasoning and the broader implications for Commons' scope and governance. I would also appreciate clarification on a forward-looking scenario: if the community were to determine, now or in the future, that this specific file (or similar material) does in fact meet the educational use threshold, would that assessment carry any weight against such legal requests? Or would the existence of an applicable removal order effectively override community consensus regardless of educational value? Relatedly, it would be helpful to understand how such cases should be treated in downstream contexts, for example if the removal itself becomes notable as part of broader discussions around Foundation governance, legal compliance, or government pressure. In such a case, could the material be reconsidered for inclusion under a clearly contextualized, encyclopedic purpose? --Jonatan Svensson Glad (talk) 12:09, 27 March 2026 (UTC)Reply
I am confused as the others. You say it was an external take down request, but your arguments are that the file was deleted as the community was not able to enforce the terms of use. Of course external requests can inform you about files they should be deleted as terms of use violations anyways. Was this file deleted as a terms of use violation or because of an external take down request? If it is the second one why is the conversation not published as usual? GPSLeo (talk) 14:54, 27 March 2026 (UTC)Reply
Re: "your arguments are that the file was deleted as the community was not able to enforce the terms of use": We're sorry if that was the impression given by our post - that wasn't what we aimed to get across. We're informing the community that we removed a file before the community had an opportunity to consider its own policies first, and that this is something we regret, because it's a very valuable function. If something we said in particular gave you the opposite impression, let us know and we can perhaps clarify it. PBradley-WMF (talk) 17:26, 27 March 2026 (UTC)Reply
Question: If Australian eSafety Commissioner demands File:Charlie Kirk Assassination View.webm taken down would you comply with that as well? Trade (talk) 00:04, 28 March 2026 (UTC)Reply
@PBradley-WMF: I also agree with Jonatan that there needs to be a publication of the Takedown request. Allowing a government ministry to take down a file without any discussion from the community is a free speech violation and will have a chilling effect on our contributors especially those who live in countries with repressive governments. If you won't release the takedown request (in redacted form is fine if privacy is a concern), then I will ask what my venues of appeal to overturn this decision are. (So far I have refrained from taking this to social media) Abzeronow (talk) 02:59, 30 March 2026 (UTC)Reply
March 21
User license-reviewed their own uploads
Latest comment: 2 days ago15 comments6 people in discussion
I just came across many files uploaded by user DarwIn, but their license were also reviewed by the same user, DarwIn.
Per Commons:License review#Instructions for reviewers, it states "reviewers may not review their own uploads unless the account is an approved bot...Reviews by image-reviewers on their own uploads will be considered invalid.". Perhaps I am missing something, since I understand the user is an admin here and also a VRT member, so maybe there is an exception to this restriction for admins and VRT members?
Fortunately, the license of the files I checked appears to be valid, and I trust the licenses were reviewed by DarwIn correctly, so I don't think there should be any files that needed to be deleted. The issue is just that possibly the license review on these files are invalid.
Not sure how many files are affected by this issue, but I think there is potentially a lot, since a quick search seems to show the user has reviewed more than a thousand videos. This is why I am asking here for advice on what to do. Thanks. Tvpuppy (talk) 02:56, 21 March 2026 (UTC)Reply
I suppose someone could go through and re-review them. I am not volunteering.
In my defense, it should be noted that the license was actually reviewed by the video2commons tool, or else they wouldn't be uploaded at all, as the tool blocks uploads with an invalid license. So I supposed a second review was not needed (as a bot had actually already reviewed it), and since the Youtube reviewer bot, which used to mark those here, was not working at the time, it would only add to the backlog unnecessarily, so I marked them as reviewed myself, something which from what I recall didn't use to be problematic some time ago. DarwinAhoy!01:38, 29 March 2026 (UTC)Reply
Video2Commons can check that someone claimed a license on YouTube, but signoff by a human reviewer suggests they found that claim at least plausible. It's not hard to see why we stopped allowing people to self-review. (Personally, I'm not sure that was necessary for admins, but I still understand the logic.) - Jmabel ! talk19:47, 29 March 2026 (UTC)Reply
In recent years we've had several deletion requests for files claiming that the license was done unintentionally or without approval. Are human reviewers supposed to take consideration for that too? Trade (talk) 03:44, 30 March 2026 (UTC)Reply
@Trade: They're supposed to do the best they can, and competence is required. If, for example, you see that a Disney YouTube site operated from Papua New Guinea has offered a license for an entire song sequence from Frozen, you should probably find that highly suspect. I would say that anyone who did not find that suspect is probably not qualified to be a license reviewer. - Jmabel ! talk04:37, 30 March 2026 (UTC)Reply
Comment until some time a decade or so ago, this self-review was actually allowed for admins, so I guess it is possible that DarwIn, who has been around for a long time, might not know current policy for this. I could probably make a similar mistake about policy on en-wiki where I am an admin, but not particularly active. - Jmabel ! talk04:14, 27 March 2026 (UTC)Reply
Thanks for the info, I think your explanation is very plausible. By the way, I have now created the category Category:Files self-reviewed by DarwIn (re-review needed) and added the problematic files to it. I have started to go through them and re-reviewing these files, but as you can see, as of writing, there are 1,729 files in the category, so if anyone wants to help out, it would be greatly appreciated. Thanks. Tvpuppy (talk) 19:56, 27 March 2026 (UTC)Reply
@Tvpuppy Hello. That episode happened years ago, but from what I remember, the review bot stopped working for some reason, so I started reviewing those myself, as they were not controversial and were actually already also verified by the video2commons app. I don't think any of those should be controversial, and those uploaded with video2commons, which should be the vast majority, were already verified by the tool used for the upload. At the time I didn't think it would be controversial in any way, but apparently it is, so I apologize for it. It was totally in good faith (and I doubt anything controversial will come out of that). DarwinAhoy!01:30, 29 March 2026 (UTC)Reply
@Jmabel hello, that was the case indeed. I used to review those myself as they were not controversial cases, to not add to the backlog, as it was the use some time ago. Apparently it changed, so I'll leave it to others to verify the license. DarwinAhoy!01:21, 29 March 2026 (UTC)Reply
"Old" for people
Latest comment: 4 days ago7 comments4 people in discussion
I can see keeping these high-level categories for things that relate specifically to a phase of life--people at senior centers, for example, or an over-60 athletic event--but if we are going to categorize known, named individuals by their age, we should straight-out categorize them by their age in years, not a designation like "old." - Jmabel ! talk21:44, 21 March 2026 (UTC)Reply
I think categories about people should be plain, not categorized categories. All information can be retrieved from Wikidata without having the inaccuracies our category system creates. GPSLeo (talk) 08:57, 22 March 2026 (UTC)Reply
I don't know what you refer to with "All information" but there's many things regarding people not on Wikidata that is available on Commons. Then even for those things available in Wikidata, it's not always set by the Wikidata infobox so one would need to request some change to it to have it add a category. Then not all people files have their own category to begin with. Lastly, even for those cases where the files are in a dedicated category with a linked Wikidata item, the item's data is often very incomplete. Prototyperspective (talk) 10:54, 22 March 2026 (UTC)Reply
The particular age is not always known. The WD infobox here defines old as 60+. I think this is useful and a parent cat like that is useful even if the age was known for all the people. There are also categories about 'young people' with the same issue. It's a valid issue but not a real problem and clearly not outweighing the rationale for having these cats and their benefits/usefulness as far as I can see. For example, it prevents other cats from being cluttered. And see Category:Young people, Category:Young adults, etc. Prototyperspective (talk) 11:54, 27 March 2026 (UTC)Reply
This seems to be headed several ways that do not particularly address my original point. There is no reason to use this word in this manner in this context. - Jmabel ! talk04:16, 27 March 2026 (UTC)Reply
March 22
Can we automate adding categories for files with an exact date?
Latest comment: 3 days ago12 comments6 people in discussion
For photographs, the best way to do that is via {{Taken on}}, not an explicit category. And, either way, a bot won't be able to pick a category by location and date, which is what we typically want (at different degrees of granularity for location in various parts of the world). - Jmabel ! talk22:23, 22 March 2026 (UTC)Reply
"Taken on" is a template for photographs and places files in the "Photographs taken on [date]" categories. News articles would need their own template, although it could be a derivative of the "taken on" template with some slight adjustments. ReneeWrites (talk) 12:30, 23 March 2026 (UTC)Reply
Please remember that our (Commons) category system is already heavily stretched to the brink of being barely technically viable. The sysadmins only recently have bought us a bit of additional time, but things like “categories for every day in the history of time for each of the files we have” would be a VERY bad idea and will run the risk of getting technically ignored (and this useless) by sysadmins when required when the choice is having working servers vs working categories. —TheDJ (talk • contribs) 22:32, 25 March 2026 (UTC)Reply
This is the first time I read about Commons running out of categories. I've been personally lobbying against one-file category atomizations for a long while already, but I was motivated not by technical concerns so far, but by creating meaningful groupings of similar files. And I do still believe that one of these meaningful groupings is having day-categories. Right now, we have day-categories for every single day in the 21st century. AND: most of them with dozens of subcategies as well: I would roughly estimate about ~400k subcategories of date-categories just for the 21st century? Aside of the 21st, we also have day-categories for most days in the 20th century and lots of days in the 19th. Further back, only days with notable events have categories right now.
RAN has created this thread probably in support for this other one, and my back-on-the envelope calculation for categories for every newspaper-cat in the last 325 years is: 325*365.25*(~10? 25?) = 1M-2.5M categories, as the utmost upper end of that calculation. While that is certainly a sizeable number, it could be narrowed down to just ~200k additional categories if we don't subdivide by language as the current proposal stands.
Could you please state your concerns in that other thread, and provide a more detailed explanation (or link to one) about this technical problem Commons might have? --Enyavar (talk) 23:58, 25 March 2026 (UTC)Reply
@ReneeWrites and @RAN: Technically, without any indication otherwise, all of our uploads were "published on" the date of upload. {{Published on}} should take note of that and add the appropriate category automatically, regardless of filetype. Pinging @Gone Postal as author of that template. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:16, 28 March 2026 (UTC)Reply
"Published on" is intended for works that have an actual known publication date established by a publisher, rather than the date a file was uploaded here. There are a lot of templates that add dates to file types automatically, such as {{Taken on}} or {{According to EXIF data}} for photographs. For files where only the upload date is known, we have {{Upload date}}. I added a description to the "Published on" template to make this distinction more clear. ReneeWrites (talk) 13:29, 28 March 2026 (UTC)Reply
"This category page should not hold any files."
Latest comment: 6 days ago7 comments5 people in discussion
Currently disambiguation categories say: "This category page should not hold any files." but most disambiguation categories do contain files because there are images and news articles that cannot be disambiguated without more information. There may be a John Smith in a news article/image, but no clue as to which John Smith. Should the warning mention that any images in the category need further disambiguation? I want to make sure people do not remove the files because of the wording. RAN (talk) 20:53, 22 March 2026 (UTC)Reply
All of those files in disambiguation categories are problems waiting to be solved, and clear out the disambiguation category. But perhaps a rewording about should be diffused to zero or some such might be more appropriate. - Jmabel ! talk22:25, 22 March 2026 (UTC)Reply
+1 – this needs a change at Template:Disambig; specifically Template:Disambig/en for the English version. Additionally, it would be good if a page about disambiguation that explains what it is was linked. Apparently none such exists or did I just not find it? Commons:Disambiguation redirects to an essay. Alternatively, one could add a section to Commons:Categories requiring diffusion and then redirect to that section. I think it would be useful because the page could explain things for people interested/confused and offer some backlog links and help, etc. Prototyperspective (talk) 13:28, 24 March 2026 (UTC)Reply
The text says "should not" (describing the desired ideal state), not "must not" (describing a prohibition). I see no reason to change it, but NearEmptiness's suggestion is okay. So a +1 on that one.
Some background, I often add files to disambigs purposefully, for example when there are more people with the same name, like David Adams or when I am not able to do the disambiguation myself because doing so would require further research. I trust the wiki principle of someone else with more knowledge to step in later. But those potential others won't know that a proper category is missing when it doesn't even show up on the disambiguation page. People should not remove that category from a file just to achieve an empty disambig page; instead they should group the files about the same person into new categories that are then linked on the disambig. When that is not possible, the files should remain there - potentially for a long time. --Enyavar (talk) 12:30, 25 March 2026 (UTC)Reply
The issue is that "should not" here is ambiguous so a certain fraction of readers probably misunderstand it and to a certain fraction it causes unnecessary confusion/required-investigation regarding what is meant. Prototyperspective (talk) 13:22, 25 March 2026 (UTC)Reply
The wording has to be clear enough that people stop removing the images from the category unless they are further disambiguated. I only came across the problem after seeing images deleted, instead of further disambiguated. Some images may require a lot of research, or there is still not enough info today, but maybe in the future. A similar problem is removing red linked name categories. They should be added to surname categories, instead of deleted. In some cases the full name of the person depicted may only appear in the red link. --RAN (talk) 23:03, 25 March 2026 (UTC)Reply
March 25
Question about original flag creations and COM:EDUSE
Latest comment: 6 days ago8 comments4 people in discussion
For the past couple decades, Wikimedia commons has been a magnet for amateur vexilologists to upload their original creations, usually either country flags that never existed or political flags that have never been used by any organisation or movement. Just as an example of the latter, see the category and various sub-categories for anarchist flags, which are full of original creations without any real-world usage. It seems to me that many of these files would not be realistically useful for educational purposes, as they would inherently serve a limited number of purposes, namely to mislead readers into believing this flag was associated with a certain subject or to promote the artist's original work. On various languages of Wikipedia, it has become a perennial issue for some projects, as artists try to push their original work onto articles or well-meaning people add a Wikicommons-hosted flag to an article (thinking it to be a real representation of the subject) despite it never having been used in real life or even outside Wikicommons.
I wanted to ask the community about this, as it seems to me that many of these flags fall firmly outside the project scope and liable to deletion, albeit up to consideration on a case-by-case basis. Would such original creations fit the criteria for deletion? Or will they likely be left up? In the latter case, is there any way to flag such uploads as original creations beyond the "Own work" field in the description? Cheers. Grnrchst (talk) 12:55, 25 March 2026 (UTC)Reply
Thanks for posting these, I wasn't aware of these deletion categories. Seems like it's a lot more common for such requests to result in deletion than a keep. --Grnrchst (talk) 13:37, 25 March 2026 (UTC)Reply
The categories are just scratching the surface, I'm afraid. There's probably thousands more deletion requests for fictitious flags, as well as a lot that get speedily deleted as personal images (i.e. "Flag of The Kingdom of My Backyard", etc). Omphalographer (talk) 19:23, 25 March 2026 (UTC)Reply
I've just come across the enormous category for special or fictional flags and it seems like this goes way deeper than I'd imagined. I also found this decade-old discussion, so I'm far from the first to flag this as an issue. Perhaps a clearer policy about this specific area needs developing, or at least more bold action might need to be taken. --Grnrchst (talk) 14:53, 25 March 2026 (UTC)Reply
Several users have over the decades contributed to the deletions of thousands of "special" flags of all kinds, each, and I count myself among them (still coming a bit short of 2000 DRs, regularly covering several flags at once though). Most of the "special" flags you see remaining here, are actually the "better" ones: those that are in use within at least one wikimedia project ("in-use" overrules "out-of-scope") and those where other users have hesitated because there is at least a flimsy source, etc. This is why we have not wholesale-deleted all of the content in the categories you pointed out.
The existing policies are sufficient in my opinion, but I agree that our current measures are rather stop-gap and that bolder action can easily be taken. Please volunteer to check the individual flags for being out-of-use AND out-of-scope, and then file the DRs. A tip: check if the same user has uploaded more fantasy files as well, the typical fake-nation has images of the flag, the coat of arms, maps, pictures of the monarch, diagrams... the whole shibang.
tl;dr: yes a lot has been done, and your help is appreciated. Whatever you do, do not forget to be kind and respectful since most flags come from different people often not aware of our policies. BEst --Enyavar (talk) 17:45, 25 March 2026 (UTC)Reply
Thanks for the thorough response! I'll be sure to help check for flags that are both out of use and out of scope. I've already gone ahead and collected together the fictitious anarchist flags I noticed into their own category, which should at least help with sorting the wheat from the chaff in that area. I will of course be respectful of the people involved; in fact, I'm quite impressed by quite a few for their artistic capabilities, I just worry this isn't the right medium for their creations (i.e. commons is not a personal web host). --Grnrchst (talk) 21:57, 25 March 2026 (UTC)Reply
Help name the photographer
Latest comment: 4 days ago7 comments5 people in discussion
Latest comment: 3 days ago10 comments5 people in discussion
I'm trying to crop File:Daytona Cubs P4060068.JPG using CropTool2 to just be the scoreboard as it's got advertisements on the bottom of the image, but when I try to save the image it says "Upload failed! [api] Received error: abusefilter-disallowed : ⧼abusefilter-warning-file-overwriting⧽". Any help? I have no idea what filter I could be tripping. RteeeeKed (talk) 01:03, 26 March 2026 (UTC)Reply
@RteeeeKed I assume you have selected "Overwrite" instead of "Upload as new file" in CropTool2. Per Jeff G. above, if you want to overwrite files, you need to be autopatrolled to be able to do it. For more details, please see COM:OVERWRITE.
Only minor crops are allowed for overwriting, but in this case it may be suitable to overwrite if you are cropping the possibly unfree advertisement at the bottom. Thanks. Tvpuppy (talk) 01:33, 26 March 2026 (UTC)Reply
@Tvpuppy: In this case, I think perspective correction and outright removal / blurring of the possibly unfree advertisements would be justified. CropTool2 can't do most of that anyway. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:58, 26 March 2026 (UTC)Reply
Not really. Gamweb, who uploaded it, hasn't been active in a decade, so I can't really get their permission to overwrite. I'll upload a modified version under a different filename; if someone thinks the original should be DR'd, I'll leave that to them. - Jmabel ! talk18:04, 27 March 2026 (UTC)Reply
My feeling, looking at those IDs, is that not just the ] is misplaced but actually the majority of the |id= shouldn’t be there – instead of |id=SUARTgpCaNw?si=jvFt1sM7AU7d2wzu Deguchi Natsuki at Biore] it should probably just be |id=SUARTgpCaNw? But I haven’t yet figured out where the gadget is taking this from. Lucas Werkmeister (talk) 13:07, 28 March 2026 (UTC)Reply
I think in this part, index6 needs to account not just for \n but also for ? (and probably &), to slice off the si= tracking parameter? But I don’t know the gadget, so I’m hesitant to just try editing it without knowing how it works. Lucas Werkmeister (talk) 13:10, 28 March 2026 (UTC)Reply
I also think that var index6 = idtemp.indexOf('\n'); asumes the line ends with a \n but in this case the end is the ]. So we might need to stop at both variants ']', '\n'. --MGA73 (talk) 11:49, 29 March 2026 (UTC)Reply
yes. i think there're very rare instances where that si tracing parameter should be retained. a bot should be created to sanitise youtube links wherever this was not removed. RoyZuo (talk) 18:46, 29 March 2026 (UTC)Reply
@RoyZuo: you say there are "rare instances" where it should be retained, but a bot should remove it. How will a bot identify those "rare instances" and leave them alone? - Jmabel ! talk19:50, 29 March 2026 (UTC)Reply
I don't think there is any reason to keep it. But it could probably check if someone manually added it back and then not remove it REAL💬⬆17:43, 31 March 2026 (UTC)Reply
Okay I tried but it did not work. So perhaps we should use a regex instead since the ID should always be 11 char long. So either (/v=([A-Za-z0-9_-]{11})/) or if we want to catch alternatives (/(?:v=|youtu\.be\/|embed\/|shorts\/)([A-Za-z0-9_-]{11})/). I suggested it on MediaWiki talk:Gadget-LicenseReview.js so feel free to Comment. --MGA73 (talk) 15:56, 30 March 2026 (UTC)Reply
March 28
Uploading screenshots of Wikipedia
Latest comment: 2 days ago4 comments4 people in discussion
@Like the windows: Screenshots are derivative works, insofar as they are works at all. Each copyrightable contribution needs to be credited and licensed. (For the Wikipedia text, the crediting can be done via a link, since the history is visible there, but it would probably be most appropriate to account for any licensing of images.) If your own contribution includes some copyrightable modification, you can claim that as "own work", though obviously just screenshotting does not normally create a copyright. Jmabel ! talk01:16, 29 March 2026 (UTC)Reply
Dynamic generated results such as weather grafics, departures boards, etc, are not creative works. However it nearly imposible to remove al the logo's etc wich are copyrighted.Smiley.toerist (talk) 10:27, 29 March 2026 (UTC)Reply
It depends on what you're asking about – it's not considered fully or mostly own work. I don't know what's best to put into the author and source fields; I usually select Own work in the Upload wizard which puts {{Own work}} in there and via edit specify and that it's a screenshot which I made and specify of which page it is, sometimes with a little note like 'see article revision history'.
This Café meetup will be approximately two hours long. Attendees may choose to attend only for a part. Please see the Café page for more information, including how to register.
Are informations behind an unifying template still recognizable by bots?
Latest comment: 2 days ago1 comment1 person in discussion
I'm interested in adding the fact that Geneviève Hasenohr found parts of chapter 77 and 78 in the manuscript Valenciennes 239. Instead of modifying each page taking part in the image series File:Marguerite Porete, Mirouer des simples âmes, Chantilly BDC MS0157, 011 f.5v-6r.jpg, I would like to create a template for this series, call it in each image description and make the change in one single place, namely in the newly created template.
User:SchlurcherBot is gradually adding structured information to the images in the series and I fear that a template will mess up this process. Additionally, I don't want to have other bots treat the files as files without license data when such a template will be present - the license situation is clear and I don't want to cause havoc because the files get automatically deleted.
So, in short: is it safe to introduce a "template detour" which allows for efficient editing and still keeps the bots happy? --TLD35 (talk) 10:02, 29 March 2026 (UTC)Reply
March 30
{{US states}}
Latest comment: 16 hours ago8 comments4 people in discussion
Would anyone complain if {{Clickable map of USA Category}} was added to this template? Commons is a site with a large international audience and i feel showing people where the state they are looking for is located would make the site more user friendly towards those outside of North America Trade (talk) 04:14, 30 March 2026 (UTC)Reply
I lean against this (it could get pretty cluttered, have a look at Maryland), but it might be OK if the map could be placed inside the box, justified either left or right. - Jmabel ! talk04:42, 30 March 2026 (UTC)Reply
If you'd like the situation to change, you could support the wish. If you have other feedback on the wish, that's welcome too. Note that a large fraction of Commons visitors is already on mobile and the problem described here is not limited to Commons categories but also all or most uses of <gallery> in Wikipedia articles and elsewhere (including when viewed through the Wikipedia app). Prototyperspective (talk) 18:08, 30 March 2026 (UTC)Reply
I experimented a bit during the recent hackathon, with modifying the category view. You can find video here: https://www.youtube.com/watch?v=MkC7_HTIYhA I used a packed view, with full width images in mobile. I moved the other link types to the bottom and made the description collapsible. It was very much a hack, but i wanted to spur some people to reconsider what the category view should be. overall reaction was enthusiastic. —TheDJ (talk • contribs) 14:00, 31 March 2026 (UTC)Reply
Interesting; thanks for doing this and I like this too except that I think the file titles kind of need to be shown by default with just an option to hide these (so they only show when hovered). Note that the titles could be trimmed to only display the full title at hover so they take only little and consistent page height.
Latest comment: 34 minutes ago2 comments2 people in discussion
If we had the image of a historical list with 1,000 people, that we also had wikidata entries for, would we create 1,000 categories for that list? RAN (talk) 04:49, 1 April 2026 (UTC)Reply
_cases_over_time_on_Commons.png)
Oppose. We can't cater to everyone. What if my workplace was at the Taliban? See COM:CENSOR. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:53, 14 March 2026 (UTC)
Support improvements to this gadget and making it easily enable via the preferences and then some thoughtful discussion on whether and which additional things could be done (example: making the gadget usable to logged-out readers). Prototyperspective (talk) 16:39, 17 March 2026 (UTC)
Comment This keeps coming up, but we never get a coherent, concrete proposal, or even a good list of the considerations for a system that would support this without imposing censorship on those who do not want it, or a set of options on what we might consider supporting. I'd be very open to a serious discussion on this front, but it is almost impossible to react intelligently to what is little more than a hand-wave. - Jmabel ! talk 23:08, 15 March 2026 (UTC)
_Berlin_09.jpg)
wikimedia.org. Thank you. On behalf of the Legal team, -- Wikimedia Foundation office (talk) 22:22, 19 March 2026 (UTC)
.jpg)
_-_Google_Art_Project.jpg){kind=link}
_and_others.jpg){kind=link}
.png){kind=link}