Wiki Educationdashboardforwikipediaediting Projects

Commons:Village pump January 02 History maps of Europe 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. - For the first point, there are two proposals, the first is the current " 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) - @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 ! talk 18:49, 2 January 2026 (UTC) - 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) - Categories denoted as old, or historic, are not terribly useful. Much better to put dates on them.

Rathfelder (talk) 17:05, 15 January 2026 (UTC) - 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. - The term "historic maps" that can denote both, has rightfully fallen (mostly) into disuse. --Enyavar (talk) 16:23, 17 January 2026 (UTC) - Categories denoted as old, or historic, are not terribly useful. Much better to put dates on them.

Rathfelder (talk) 17:05, 15 January 2026 (UTC) - 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. - @Enyavar: I'm trying to understand the first point.

A couple of questions that may help me understand: 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) February 22 Maps from Our World in Data 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. Thanks in advance. --Universalis (talk) 19:15, 22 February 2026 (UTC) - 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) - +1 to Prototyperspective. - Jmabel ! talk 20:39, 22 February 2026 (UTC) - 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. - With at least 300'000 OWiD maps already existing and no end in sight, I would really like to delegate all of these maps into specific OWiD-categories for each continent and year.

My suggestion for File:Annual co2 cement, North America, 1764.svg would be Our World in Data maps showing North America in 1764 or Our World in Data maps of North America in 1764. These year-categories would themselves be categorized under Our World in Data maps showing 1764 and Our World in Data maps of North America in the 18th century. - 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) - 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) 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)- So what do folks want us to do? Doc James (talk · contribs · email) 09:00, 26 February 2026 (UTC) - 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) - If you'd like to these could be subcategorized in the maps by year cats...I tried to keep them as flat as possible to enable viewing all the relevant files on one page, have easier to understand standardized cat names, and not start deep nesting that can cause queries and scans to break.

Many hundreds of files would be moved. If there is agreement and no objections, should they be named Category:Our World in Data maps of the world showing 2014 data or Category:OWID maps of the world showing 2014 data or Category:Maps of the world showing 2017 (OWID) or Category:Our World in Data maps of the world showing 2014 or Category:2014 Our World in Data maps of the world or Category:2014 maps of the world (OWID) or sth else?

(It's mostly maps of the world that I'd move.) Prototyperspective (talk) 12:40, 26 February 2026 (UTC) - 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. - Following that idea, we could go with Our World in Data maps of <region> showing <year> data .

Taking an existing map like File:States involved in state based conflicts, Oceania, 1947.svg, one would assign Our World in Data maps of Oceania showing 1947 data instead of the current three categories Our World in Data maps of Oceania, Maps showing 1947 and 1947 maps of Oceania. That new category would itself be categorized directly under the existing three categories it replaces. - 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) - Yah I think doing this in an automated fashion should be fairly easy. This would be subcategories of what main category?

Doc James (talk · contribs · email) 19:01, 28 February 2026 (UTC) - [[: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) - Plan was to categorize once the initial uploads are completed, which will not be until this fall.

And work on the 1.8 million or so files at that point. Doc James (talk · contribs · email) 19:18, 28 February 2026 (UTC) - 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) - Here is my suggestion: Maps of Oceania in the 1940s anro (talk) 22:18, 3 March 2026 (UTC) - I can happily come up with a suggestion for a template based on the Navigation by system. But first let me make sure I understand correctly: - The template would be used for categories like Our World in Data maps of Oceania showing 1947 data, right?

Would we also have Our World in Data maps of Oceania showing 1940s data (decade) and Our World in Data maps of Oceania showing 19th-century data (century) as parent and grandparent of the year category? - Thanks --Reinhard Müller (talk) 09:07, 4 March 2026 (UTC) - Thanks Reinhard, regarding #1 yes that is idea. {{OWiD maps showing|Africa|175|8}} --> Our World in Data maps of Africa showing 1748 data{{OWiD maps showing|Oceania|194|7}} --> Our World in Data maps of Oceania showing 1947 data- 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) - Thanks Reinhard, regarding #1 yes that is idea. - Plan was to categorize once the initial uploads are completed, which will not be until this fall. And work on the 1.8 million or so files at that point. Doc James (talk · contribs · email) 19:18, 28 February 2026 (UTC) - [[: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) - Yah I think doing this in an automated fashion should be fairly easy. This would be subcategories of what main category? Doc James (talk · contribs · email) 19:01, 28 February 2026 (UTC) - 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: - If you'd like to these could be subcategorized in the maps by year cats...I tried to keep them as flat as possible to enable viewing all the relevant files on one page, have easier to understand standardized cat names, and not start deep nesting that can cause queries and scans to break. Many hundreds of files would be moved.

If there is agreement and no objections, should they be named Category:Our World in Data maps of the world showing 2014 data or Category:OWID maps of the world showing 2014 data or Category:Maps of the world showing 2017 (OWID) or Category:Our World in Data maps of the world showing 2014 or Category:2014 Our World in Data maps of the world or Category:2014 maps of the world (OWID) or sth else?

(It's mostly maps of the world that I'd move.) Prototyperspective (talk) 12:40, 26 February 2026 (UTC) - 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) - So what do folks want us to do?

Doc James (talk · contribs · email) 09:00, 26 February 2026 (UTC) I have now created: - Templates - {{Category description/Our World in Data maps by continent and century}} - {{Category description/Our World in Data maps by continent and decade}} - {{Category description/Our World in Data maps by continent and year}} - Example use - Category:Our World in Data maps of Oceania showing 20th-century data - Category:Our World in Data maps of Oceania showing 1940s data - Category:Our World in Data maps of Oceania showing 1947 data - Category:Our World in Data maps of the world showing 1947 data 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. Please let me know what you think. --Reinhard Müller (talk) 09:52, 6 March 2026 (UTC) - 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) - @Reinhard Müller: Thanks a lot! This is even easier to apply than I thought. I populated three continents for the 1940s (Africa, Asia, Oceania) and also the world. - 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. - @Universalis, Prototyperspective, Jmabel, and Doc James: when you check the bolded links... does this new structure look okay? --Enyavar (talk) 15:22, 8 March 2026 (UTC) - Very nice. Are you using a bot to apply this? Or have you tried Help:Gadget-CategoryBatchManager?

Doc James (talk · contribs · email) 16:46, 8 March 2026 (UTC) - Thanks for the feedback! - 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. - FWIW, this is now also fixed. --Reinhard Müller (talk) 19:51, 9 March 2026 (UTC) - 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) - 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) - I have created: - 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) - 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) - Thanks for the feedback! - 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) - Very nice.

Are you using a bot to apply this? Or have you tried Help:Gadget-CategoryBatchManager? Doc James (talk · contribs · email) 16:46, 8 March 2026 (UTC) - 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 meansmanuallyediting 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)**// - if that inserted category does not yet exist: create it with " - take the file name as the variable topicname and stripFile: and, Asia, YYYY.svg (or,Asia,YYYY.svg ) from that variable - insert " [[Category:Our World in Data maps showing ||topicname]] " //** for example Category:Our World in Data maps showing Absolute change co2, neatly collecting ~1800 files like this one or ~200 files like this one: a single category for the topic of the map, to have them all easily assembled **//- 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 **// - if that inserted category does not yet exist: create it with " - remove all occurences of " {{Map showing old data|year=YYYY}} ", ""[[Category:YYYY maps of Asia]] " and "[[Category:Our World in Data maps of Asia]] " - take the YYYY as a variable to insert " - (else leave the file alone) - if " - repeat the same with "Africa", "Europe", ["North America" or "NorthAmerica" would need to be mapped onto "North America"], "Oceania", and so on.

for all files in - 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) 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 !

talk 20:53, 8 March 2026 (UTC)- 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) - I added the above request to Commons:Bots. --Enyavar (talk) 16:03, 12 March 2026 (UTC) March 06 Help needed to close 6,323 Category for Discussion cases 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) 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) - A backlog like this is a disgrace. Will nobody think of the poor nominators? Laurel Lodged (talk) 14:10, 6 March 2026 (UTC) - 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) - 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) - 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) - 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) - 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) - Good idea. Joshbaumgartner had already set up Category:Category discussions by topic in mid 2024.

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) - 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) - 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) - @Prototyperspective: I believe you can edit multiple cats at once with AWB, but I don't recall that I've ever done it, not a tool I've used recently. - Jmabel ! talk 20:47, 16 March 2026 (UTC) - some are just missions impossible unless the right person interested and capable in that task can be found. - for example Commons:Categories for discussion/2025/01/Category:Gothic jewellery seems pretty straight forward.

we just need 2 categories, 1 for gothic as a style and 1 for the things related to goths the ethnic group, but it contains many files and subcategories. to distinguish and separate them takes a lot of time for people without that specific knowledge. RoyZuo (talk) 15:31, 7 March 2026 (UTC) - also the problem plaguing many cat names will vanish when cats can be like wd items which can take on multilingual labels, descriptions and aliases. - we dont need to settle on a single title.

technical solutions and infrastructure upgrade are much needed for commons. RoyZuo (talk) 15:40, 7 March 2026 (UTC) - 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. - On English Wikipedia there was a recent thread about CfDs (started by Pppery) and there there are only about 250 open CfDs.

Maybe one could see if they're doing some things to get more CfDs closed faster other than ENWP simply having more category-pageviews and more contributors. Prototyperspective (talk) 13:06, 22 March 2026 (UTC) - At least Commons' backlog is going down. Enwiki's has been going up overall and briefly exceeded 300 several times over the last few days. * Pppery * it has begun... 15:04, 22 March 2026 (UTC) - Maybe this is useful and maybe we could/should have a page like this on Commons too: en:User:Qwerfjkl/How to close CfD discussions.

Prototyperspective (talk) 15:39, 27 March 2026 (UTC) - Things are going down again – it's at 6,271 categories that have a CfD now. Thanks to everyone involved, and I'd like to thank especially Deltaspace42 who is doing a remarkable effort on the CfDs as far as I can see (seeing many closes of CfDs I have watchlisted). Will update the chart soonish.

An issue with the applied quantification is that it does not show the 'number of open CfDs' but the 'number of categories with open CfDs' and some CfDs relate to lots of categories with tags being on each.

However, some users also create lots of separate CfDs about the same topic for each of the affected category so the number of open CfDs wouldn't necessarily be better, even more so since prioritizing the CfDs that have hatnote tags on lots of categories makes some sense and nothing is stopping contributors to close or participate in these first. I'll probably rename the chart to make it clearer which count it shows.

Nevertheless, if somebody knows of a way to get data of the number of open CfDs over time, please comment. It looks like every month back to Dec 2015 has at least one open CfD except for a few months in 2017 which have been finished. - - - I encourage everyone to take a glance over one or a few months of CfDs to see whether there's any you have some input for.

It's often not discussion that are specific to some subject where barely anybody other than people interested/knowledgable in that topic could say something constructive but also various other types of complications and issues that need resolving. Prototyperspective (talk) 23:10, 2 April 2026 (UTC) March 10 Do you want to help, to categorise 80,000 media needing categories as of 2021, please? We are currently categorizing all media needing categories as of 2021. We have started one year ago at 125,000 files to be categorized.

Progress is now taking up momentum, as shown in Category talk:All media needing categories as of 2021. However, the task is getting increasingly more difficult, because the 'low hanging fruit' have been harvested by now. Do you want to help us? If so, please check out the Commons:WikiProject Minimum One Category. leave a comment about your approach or your achievement either here or on the relevant discussion pages.

NearEMPTiness (talk) 02:09, 10 March 2026 (UTC) - With 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) - 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) - 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) - 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) - 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) - 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) - Prototyperspective (talk) 00:33, 28 March 2026 (UTC) - 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) - I've created a wish about the mentioned guidance/facilitation of better categorization at upload: W526: Guidance/facilitation of categorization of files at upload in UploadWizard (voting open). This could reduce the number of new under- and uncategorized files substantially. Further ideas could be added to the talk page and the wish could then be extended if there are some things to add.

Prototyperspective (talk) 17:48, 22 March 2026 (UTC) We reached the halfway point, by reducing all media needing categories as of 2021 from 125,000 to 62,500 files. Now we need more volunteers please for categorising the reminder. The objective is, to add the final category, please, not only the Category:Unidentified men. Ideally, we shouldn't all get stuck at letter A by working alphabetically from A to Z, but start somewhere in between and use the hints shown on Commons:WikiProject Minimum One Category.

Do you want to help, and/or do you have an idea, how to do this more effectively? NearEMPTiness (talk) 14:02, 3 April 2026 (UTC) March 14 Blurring NSFW images 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) - This is very difficult to build, if it should work on every display of a thumbnail.

GPSLeo (talk) 21:09, 14 March 2026 (UTC) - 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) - 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) - 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) - 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) - 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) - 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) - @Some1: 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) - What's wrong with allowing people to blur/hide NSFW images? No one is forcing anyone to turn the option on. Some1 (talk) 22:54, 14 March 2026 (UTC) - I just now submitted a "wish" for this at the Community Wishlist page. Hopefully the WMF developers see it.

https://meta.wikimedia.org/wiki/Community_Wishlist/W522 Some1 (talk) 01:06, 15 March 2026 (UTC) - 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) - 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) - 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) - 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) - It works well on reddit and there is no reason to believe it wouldn't work here. Prototyperspective (talk) 13:55, 16 March 2026 (UTC) - 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) - What's wrong with allowing people to blur/hide NSFW images? No one is forcing anyone to turn the option on. Some1 (talk) 22:54, 14 March 2026 (UTC) - Oppose. NSFW is subjective. This is a baby globe problem. JudeHalley (talk) 03:26, 15 March 2026 (UTC) - That is not much of a problem.

NSFW-blurring works well on reddit and it could work well here too especially if one does not assume it has to be perfect. Prototyperspective (talk) 13:56, 16 March 2026 (UTC) - MediaWiki:Gadget-NSFW.js is related, it should be in your settings under gadgets with a checkbox to enable. No guarantee on that it will block everything NSFW.

Snævar (talk) 16:59, 15 March 2026 (UTC) - Issues with this gadget: - I could not find it in the gadget preferences - 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 - Prototyperspective (talk) 13:36, 17 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) - Issues with this gadget: - 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) - 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) - i thought about this reddit i just read https://www.reddit.com/r/berlin/comments/14rhjvb/comment/jqskkea/ 😂 RoyZuo (talk) 08:30, 16 March 2026 (UTC) - 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) - 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) - 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) - 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) - 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) - It’s if we can get a local ai to scour the images for gore genitalia . This would be simple Cyberwolf (talk) 16:09, 19 March 2026 (UTC) - 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) - Apple has a pretty good system. Deepcleer https://deepcleer.com/product/image https://aws.amazon.com/rekognition/content-moderation/ Rekognition Cyberwolf (talk) 16:44, 19 March 2026 (UTC) - Apple has a pretty good system. Deepcleer https://deepcleer.com/product/image - 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) - It’s if we can get a local ai to scour the images for gore genitalia .

This would be simple Cyberwolf (talk) 16:09, 19 March 2026 (UTC) - 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) - 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) - Oppose I see no need for this. ReneeWrites (talk) 14:28, 16 March 2026 (UTC) - Support if it is in personal space of users as they enable, Oppose if it is global. modern_primat ඞඞඞ ----TALK 20:04, 16 March 2026 (UTC) - Can we not run the images through an image detector system which can detect gore blood and human genitalia ?

Then require all new images to mark if they are nsfw I’ve seen scary shit on here https://commons.wikimedia.org/w/index.php?title=File:Alligatoah_-_2019160210053_2019-06-09_Rock_am_Ring_-_1975_-_AK8I2744.jpg&action=history Literal gore was mass mentioned to users I support this to keep people from unintentionally seeing that shit Cyberwolf (talk) 15:41, 19 March 2026 (UTC)- 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 - I will propose a system a binary table - 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)- If a simple binary rating system is implemented. I believe it would work Cyberwolf (talk) 16:04, 19 March 2026 (UTC) - That's the easy part. The hard part is getting everyone to agree on what the specific categories actually mean, and what specific categories to use. Is File:Crocifisso Giovanni Teutonico o Paolo Moerich Duomo di Salò.jpg depicting violence?

Is File:Leuconotopicus villosus mating.jpg depicting sex, Do File:Topless female model.jpg, File:Michele Merkin 1.jpg, File:Namibie Himba 0720a.jpg, File:Paul Gauguin - Fatata te Miti (By the Sea) - Google Art Project.jpg all get rated the same way? I'm not saying these questions don't have answers, some of them obvious (I included the File:Leuconotopicus villosus mating.jpg one as a silly argument that I'm sure someone at some point will make despite being obvious), however someone still has to actually propose the categories, define them and get everyone to agree the definitions are reasonable.

Bawolff (talk) 16:40, 19 March 2026 (UTC) - I would also propose a scale then so no one has to really agree Cyberwolf (talk) 16:45, 19 March 2026 (UTC) - And for the Jesus on the cross would be a 1 on my scale Cyberwolf (talk) 16:47, 19 March 2026 (UTC) - 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) - Yeah true but id assume a scale would see more support Cyberwolf (talk) 16:49, 19 March 2026 (UTC) - 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) - 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) - 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) - "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?

I don't think anyone cares how narrow the criteria is just as long as the feature actually gets off the ground Trade (talk) 02:42, 24 March 2026 (UTC) - 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) - How is this scope?

I think it's narrow enough to avoid the slippery slope arguments @Bawolff: - Sexual acts - Sexualized nudity or erotica - Graphic violence, mutilation or corpses - Medical or surgical gore - --Trade (talk) 21:23, 25 March 2026 (UTC) - 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) - Wikimedia Commons content descriptor Here, you can join the proposal and explain more about your gadget and why this is something useful for Commons (obviously anyone reading this can also show up to voice their protest if they want) @Bawolff: --Trade (talk) 02:32, 30 March 2026 (UTC) - 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) - How is this scope? I think it's narrow enough to avoid the slippery slope arguments @Bawolff: - 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) - 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.

Prototyperspective (talk) 21:22, 19 March 2026 (UTC) - 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) - I would also propose a scale then so no one has to really agree Cyberwolf (talk) 16:45, 19 March 2026 (UTC) - That's the easy part. The hard part is getting everyone to agree on what the specific categories actually mean, and what specific categories to use.

Is File:Crocifisso Giovanni Teutonico o Paolo Moerich Duomo di Salò.jpg depicting violence? Is File:Leuconotopicus villosus mating.jpg depicting sex, Do File:Topless female model.jpg, File:Michele Merkin 1.jpg, File:Namibie Himba 0720a.jpg, File:Paul Gauguin - Fatata te Miti (By the Sea) - Google Art Project.jpg all get rated the same way?

I'm not saying these questions don't have answers, some of them obvious (I included the File:Leuconotopicus villosus mating.jpg one as a silly argument that I'm sure someone at some point will make despite being obvious), however someone still has to actually propose the categories, define them and get everyone to agree the definitions are reasonable. Bawolff (talk) 16:40, 19 March 2026 (UTC) - If a simple binary rating system is implemented.

I believe it would work Cyberwolf (talk) 16:04, 19 March 2026 (UTC) - Lets say i want to set my preferences as no gore. Violence no genetailia no sex 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) - I think this thread appears more relevant after Commons:Village_pump#c-WMFOffice-20260319222200-Office_action:_Removal_of_file. - A blur filter, or a system of different access levels for different groups of users, is better than censorship. RoyZuo (talk) 09:11, 22 March 2026 (UTC) - Australia have the power to dictate what we are and are not allowed to host.

Blurring has no bearing on that Trade (talk) 02:30, 24 March 2026 (UTC) - Yes Cyberwolf (talk) 13:13, 23 March 2026 (UTC) 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) - I do have one question: would uncategorized images be automatically blurred?

JudeHalley (talk) 11:58, 24 March 2026 (UTC) - 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) - I dont think anyone wants that Trade (talk) 03:41, 30 March 2026 (UTC) 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) - that would require them to actually tell Wikipedia and Commons apart so unlikely Trade (talk) 03:18, 26 March 2026 (UTC) - 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) - If the options are between age verification or geoblocking countries with such laws, i would much prefer the later Trade (talk) 03:41, 30 March 2026 (UTC) - Same but such shouldn't be provoked nor aided via unexpected gore and NSFW files and not even having an option to have such files blurred.

Prototyperspective (talk) 12:27, 30 March 2026 (UTC) - If the options are between age verification or geoblocking countries with such laws, i would much prefer the later Trade (talk) 03:41, 30 March 2026 (UTC) March 17 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) - Pinging @Jason Lagos as filemover. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:10, 17 March 2026 (UTC) - Hi Smiley.toerist, - 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) - Thanks for the info. I still get a gut feeling about this, as I use the station frequently. Midi and Sud are French synonyms but of different origin and feel. see https://monkkey.fr/questions-betes/life/sud-france-midi/?cn-reloaded=1 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) - 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?

Jason Lagos (talk) 15:07, 17 March 2026 (UTC) - 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) - Whatever you choose for the main category, please ensure subcategories are consistently (re)named, as per the Commons:Categories#Universality principle. Cluttering a watchlist is not a reason to ignore policies.

HyperGaruda (talk) 06:50, 19 March 2026 (UTC) - 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) - @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) - 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) - 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) - OK - thanks again for the feedback. I have paused all these railway stations moves to give you some respite. Anyway, the bulk is mostly done (Brussels North, South, Central, West, Chapel, Congress, Luxembourg, and Airport). Any future moves will (hopefully) be less impactful for you, as those categories usually contain fewer than 50 pictures each.

Jason Lagos (talk) 09:04, 24 March 2026 (UTC) - The backlog from 22/23 march is revolver.Smiley.toerist (talk) 09:50, 27 March 2026 (UTC) - Great - thanks for the update! Jason Lagos (talk) 15:58, 28 March 2026 (UTC) - The backlog from 22/23 march is revolver.Smiley.toerist (talk) 09:50, 27 March 2026 (UTC) - OK - thanks again for the feedback. I have paused all these railway stations moves to give you some respite. Anyway, the bulk is mostly done (Brussels North, South, Central, West, Chapel, Congress, Luxembourg, and Airport).

Any future moves will (hopefully) be less impactful for you, as those categories usually contain fewer than 50 pictures each. Jason Lagos (talk) 09:04, 24 March 2026 (UTC) - 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) March 19 {from YouTube} using archive.today links Template:From YouTube is using archive.today links which should be removed | enwiki banned them last month after they ddosd and tampered with web pages Cyberwolf (talk) 14:52, 19 March 2026 (UTC) - Commons is not Wikipedia. Two archive links may be better than just one idk (may depend on how well the archival of IA works for YT videos).

Prototyperspective (talk) 15:08, 19 March 2026 (UTC) - 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 itfrom 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)- 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) - I tried Cyberwolf (talk) 18:53, 19 March 2026 (UTC) - +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) - I have created a request for this over at Commons:Translators' noticeboard. Thanks.

Tvpuppy (talk) 03:16, 21 March 2026 (UTC) - I have gotten most removed except for the reverse script languages Cyberwolf (talk) 12:59, 23 March 2026 (UTC) - I have created a request for this over at Commons:Translators' noticeboard. Thanks. Tvpuppy (talk) 03:16, 21 March 2026 (UTC) - 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) - Archive today was using users ips to launch a ddos attack. It’s a security risk. - Comment, please see related discussion from last month here: Commons:Village pump/Archive/2026/02#archive.today. Thanks. Tvpuppy (talk) 03:13, 21 March 2026 (UTC) - 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) - Good point(s) but do we need it for YouTube videos? Looks like IA has these archived anyway so it was a somewhat redundant link.

Prototyperspective (talk) 10:49, 22 March 2026 (UTC) - 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) - 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) - 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) - 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) - 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) - 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) - 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) - 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) - Again. Sneeuwschaap (talk) 12:38, 26 March 2026 (UTC) - 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) - 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.

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) - 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) - 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) - he created revenge porn of his critic. Cyberwolf (talk) 12:38, 23 March 2026 (UTC) - I think this maybe the actual owner of archivetoday Cyberwolf (talk) 12:39, 23 March 2026 (UTC) - 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) - 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) - 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) - 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) - Sorry that you can’t use this scumbags site Cyberwolf (talk) 15:45, 23 March 2026 (UTC) - 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) - https://arstechnica.com/tech-policy/2026/02/wikipedia-might-blacklist-archive-today-after-site-maintainer-ddosed-a-blog/ Again you didn’t read Cyberwolf (talk) 13:43, 24 March 2026 (UTC)- 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) - Brother.

It doesn’t matter if its an threat or creation its wrong and Wikimedia shouldn’t funnel people into the scumbags site Cyberwolf (talk) 13:16, 25 March 2026 (UTC) - If you make accusations, you must be factually accurate and provide proofs. And I am not your brother. Sneeuwschaap (talk) 12:38, 26 March 2026 (UTC) - Boohoo do you want to die on this hill? Cyberwolf (talk) 12:42, 26 March 2026 (UTC) - @Cyberwolf: drop it. Yes, you are making this personal. Stop. - Jmabel !

talk 04:02, 27 March 2026 (UTC) - Boohoo do you want to die on this hill? Cyberwolf (talk) 12:42, 26 March 2026 (UTC) - If you make accusations, you must be factually accurate and provide proofs. And I am not your brother. Sneeuwschaap (talk) 12:38, 26 March 2026 (UTC) - Brother.

It doesn’t matter if its an threat or creation its wrong and Wikimedia shouldn’t funnel people into the scumbags site Cyberwolf (talk) 13:16, 25 March 2026 (UTC) - 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) - https://arstechnica.com/tech-policy/2026/02/wikipedia-might-blacklist-archive-today-after-site-maintainer-ddosed-a-blog/ - 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) - Good point(s) but do we need it for YouTube videos? Looks like IA has these archived anyway so it was a somewhat redundant link.

Prototyperspective (talk) 10:49, 22 March 2026 (UTC) Office action: Removal of file Hello all, Today, the Wikimedia Foundation removed the file File:An illegal Cuban migrant beheads a motel owner in Dallas, Texas (10 September 2025).webm from Wikimedia Commons in response to a legal order from the Australian government. Our attorneys determined that the order applied to the Foundation under our policy for determining applicable law. 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. Please note that, as an Office action, we ask that you not reinstate the file and instead address questions to the Legal team via email, at legalwikimedia.org. Thank you. On behalf of the Legal team, -- Wikimedia Foundation office (talk) 22:22, 19 March 2026 (UTC) - @WMFOffice: Thank you. The public upload log for that file seems to have gone missing.

It would be useful to know what else the uploader uploaded. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:30, 19 March 2026 (UTC) - Will the letter/email the WMF received be added (even if it has to have redactions? Bidgee (talk) 22:49, 19 March 2026 (UTC) - @Jeff G., it appears the file page was archived over at Internet Archive, so you can check who was the uploader using the archived page. Thanks.

Tvpuppy (talk) 23:37, 19 March 2026 (UTC) - @Tvpuppy: Thanks, per this link the uploader was Illegitimate Barrister, who got the video from watchpeopledie.tv. Perhaps that domain is one worth blacklisting. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:08, 20 March 2026 (UTC) - I don't think any policy allows us to blacklist domains in the absence of any copyright issues Trade (talk) 17:43, 21 March 2026 (UTC) - @Tvpuppy: Thanks, per this link the uploader was Illegitimate Barrister, who got the video from watchpeopledie.tv.

Perhaps that domain is one worth blacklisting. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:08, 20 March 2026 (UTC) - 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) - 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) - 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) - 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) - 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. — Preceding unsigned comment added by Asclepias (talk • contribs) 10:45, 21 March 2026 (UTC) - 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 Jazz ping plz 03:47, 21 March 2026 (UTC) - 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) - 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) - 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) - 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 statesthe 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 Jazz ping plz 05:33, 20 March 2026 (UTC)- 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) - " 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) - 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) - 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: - Snævar (talk) 20:39, 25 March 2026 (UTC) select lt_title, count(cl_from) from linktarget join categorylinks on cl_target_id = lt_id and cl_type = "file" left outer join globalimagelinks on gil_to = lt_title where lt_namespace = 14 and gil_to is null group by lt_title - I'm sorry, but this is just plain retarded. Why would we care about a request from a country where neither the Wikimedia Commons servers are located nor the video was taken?

Though graphic, the video has obvious educational purpose on the article w:Killing of Chandra Nagamallaiah. Per w:WP:NOTCENSORED and COM:NOTCENSORED, the file should be restored as soon as possible, Australian Government be damned.

Dabmasterars [EN/RU] (talk/uploads) 15:28, 29 March 2026 (UTC) - @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 !

talk 19:41, 29 March 2026 (UTC) - @Dabmasterars: 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) - @Bawolff: Is "NSFL" in that last paragraph a typo for "NSFW", or is it a term I'm not familiar with? - Jmabel ! talk 20:48, 20 March 2026 (UTC) - 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) - I will add that to the glossary in Commons:Editor's index to Commons. - Jmabel ! talk 21:11, 20 March 2026 (UTC) - 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) - 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) - 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) - 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) - 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) - The video of Iryna Zarutska was already heavily blurred and Commons deleted it anyways though Trade (talk) 17:44, 22 March 2026 (UTC) - 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) - 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) - 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) 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) - It's worth pointing out the the upload log was not intentionally scrubbed. It's just under an old name prior to a move. see the upload and rename here * Pppery * it has begun...

19:55, 21 March 2026 (UTC) community should decide that it is educational or not. you should undelete the file. modern primat ඞඞඞ ----TALK 20:29, 21 March 2026 (UTC) Internet has made applicability of national laws a legitimate grey area. See the two examples I listed at meta:Talk:Wikilegal/A changing legal world for free knowledge#Probable EU examples to note for (although both cases concern French court decisions and concern intellectual property matter).

JWilz12345 (Talk|Contributions) 07:12, 25 March 2026 (UTC) - Which is why it's so vital for WMF to fight for Wikimedia Commons rather than immediately rolling over Trade (talk) 18:40, 26 March 2026 (UTC) It's been a week now and Wikimedia Foundation office is still ghosting us...--Trade (talk) 18:42, 26 March 2026 (UTC) - 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) - I don't know what you are even expecting here. There isn't any questions here waiting for WMFOffice's response. Bawolff (talk) 08:57, 27 March 2026 (UTC) 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? — Rhododendrites talk | 02:51, 27 March 2026 (UTC) - 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) - 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) - Won't this just encourage the Australian eSafety Commissioner to take down even more files from Commons?

Trade (talk) 11:57, 27 March 2026 (UTC) - 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) - Thanks @Jonatan Svensson Glad - we're raising the transparency point (amongst others) with the eSafety Commissioner, and we'll revert back once we've made a decision on this. To your (and other commentators') points: 1. We'll refrain from committing here and now to action/inaction on hypotheticals, because the analysis factors we mentioned above can vary substantially between cases, and over time. 2. We don't want to discourage discussions, nor valuable uploads - quite the contrary.

To your question "would [the community's educational use] assessment carry any weight against such legal requests", that was already answered in earlier posts: the community's carefully-balanced views about educational value vs possible harms (including to vulnerable users) are very relevant, but they will also not be the sole consideration when there's a legal dimension. 3.

To the last question you raised: we're aware of the argument, and we have tried it at least once, recently; but that was an extraordinary case, and so far, it's unclear how successful it will be. Note that courts might not always be very receptive about such arguments (more common in journalism privacy lawsuits), out of concern about encouraging artificial attempts to exploit the Streisand effect.

So we're sympathetic to the argument, but at the same time, it's not always the case that things can go from "illegal" to "legal" just because people talked - even very loudly - about them. PBradley-WMF (talk) 10:17, 1 April 2026 (UTC) - You mentioned you are raising the transparency issue with the eSafety Commissioner. Could you share (even approximately) when you expect a response, and whether WMF has also considered or initiated an internal merits review or appeal under section 220 of the Online Safety Act?

Jonatan Svensson Glad (talk) 11:57, 1 April 2026 (UTC) - Yes, we certainly considered the provision, and others besides. We have not initiated those processes. - With apologies, I'm not able to offer a reliable time estimate for a public authority's response to extra-statutory queries. PBradley-WMF (talk) 13:18, 1 April 2026 (UTC) - You mentioned you are raising the transparency issue with the eSafety Commissioner.

Could you share (even approximately) when you expect a response, and whether WMF has also considered or initiated an internal merits review or appeal under section 220 of the Online Safety Act? --Jonatan Svensson Glad (talk) 11:57, 1 April 2026 (UTC) - Thanks @Jonatan Svensson Glad - we're raising the transparency point (amongst others) with the eSafety Commissioner, and we'll revert back once we've made a decision on this. To your (and other commentators') points: 1.

We'll refrain from committing here and now to action/inaction on hypotheticals, because the analysis factors we mentioned above can vary substantially between cases, and over time. 2. We don't want to discourage discussions, nor valuable uploads - quite the contrary.

So we're sympathetic to the argument, but at the same time, it's not always the case that things can go from "illegal" to "legal" just because people talked - even very loudly - about them. PBradley-WMF (talk) 10:17, 1 April 2026 (UTC) - 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) - 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) - This no answer to my question: Is the deletion based on our terms of use or based on an external demand?

GPSLeo (talk) 18:20, 27 March 2026 (UTC) - 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) - 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) - @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) March 21 User license-reviewed their own uploads I just came across many files uploaded by user DarwIn, but their license were also reviewed by the same user, DarwIn.

Here are just some of the videos I randomly sampled from Category:Videos by Agência LUSA: - File:Portugal disponível para formar pilotos mas descarta envio de F-16.webm - File:Pizarro agradece promulgação e fará em breve convites para direção do SNS.webm - File:AmadoraBD quer chegar a todos os públicos da banda desenhada.webm 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) - I suppose someone could go through and re-review them. I am not volunteering. - @DarwIn: you're an admin here, you should know this isn't the way this is supposed to be done.

Jmabel ! talk 06:41, 21 March 2026 (UTC) - +1 --Polarlys (talk) 09:36, 21 March 2026 (UTC) - +1 — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:00, 21 March 2026 (UTC) - 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. Darwin Ahoy!

01:38, 29 March 2026 (UTC) - 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 ! talk 19:47, 29 March 2026 (UTC) - 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) - @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 !

talk 04:37, 30 March 2026 (UTC) - 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) - 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 ! talk 19:47, 29 March 2026 (UTC) - 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 !

talk 04:14, 27 March 2026 (UTC) - 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) - @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). Darwin Ahoy! 01:30, 29 March 2026 (UTC) - Going forward, unless something extraordinary is found, can we have Video2Commons automatically review videos it converts? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:36, 29 March 2026 (UTC) - I support the suggestion, as it would reduce unnecessary bureaucracy. Darwin Ahoy!

01:40, 29 March 2026 (UTC) - @DarwIn: Would COM:VPP be the right place for a discussion of and !voting on that, or a subsection here? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:45, 29 March 2026 (UTC) - I support the suggestion, as it would reduce unnecessary bureaucracy. Darwin Ahoy! 01:40, 29 March 2026 (UTC) - Going forward, unless something extraordinary is found, can we have Video2Commons automatically review videos it converts? — 🇺🇦Jeff G.

ツ please ping or talk to me🇺🇦 01:36, 29 March 2026 (UTC) - @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). Darwin Ahoy! 01:30, 29 March 2026 (UTC) - @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. Darwin Ahoy! 01:21, 29 March 2026 (UTC) - 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) "Old" for people Speaking as, no doubt, one of the roughly oldest 10% of participants here, I seriously question the value and appropriateness of categories like Category:Old men and Category:Old women.

It is--and almost inevitably will remain--unevenly applied (e.g., to pick two people my age at the relevant times) neither of these is an ancestor category of Category:Bernie Sanders in 2012 or Category:Richard Nixon in 1984, but it is for Category:Nancy Reagan in 1992 and Category:Donald Trump in 2017. And why am I not surprised that Eartha Kitt at 80, in the last year of her life, is not described as old, whereas Annie Liebovitz in her late 50s does.

And I don't think the answer is to apply it more objectively. 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 !

talk 21:44, 21 March 2026 (UTC) - "we should straight-out categorize them by their age in years" Your examples already do that Trade (talk) 21:55, 21 March 2026 (UTC) - @Trade: No they do not. For example, Category:Nancy Reagan in 1992 is categories in Category:Old women of the United States in 1992 not Category:71-year-old human females, and even if it were, that is in turn in Category:Old women by age, whereas it could simply be in Category:Women by age.

And, yes, I'm aware that during part of the year she would have been 70, but one look at Category:71-year-old human females will show you that has not been taken into consideration for 96 other similar categories and 13 photos. - Jmabel ! talk 06:50, 22 March 2026 (UTC) - 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) - 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) - 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) 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 !

talk 04:16, 27 March 2026 (UTC) March 22 Can we automate adding categories for files with an exact date? We currently have a bot that formats dates, can it also add that date to a category? RAN (talk) 20:39, 22 March 2026 (UTC) - 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 ! talk 22:23, 22 March 2026 (UTC) - But we need it for news articles, doing it by hand is time consuming and incomplete. I see that {{Taken on}} will add a date category, so perhaps automate {{Taken on}} where we have a full date.

RAN (talk) 23:54, 22 March 2026 (UTC) - "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) - Turns out this template already exists: {{Published on}}, which automatically puts a file in the main date category, see for example File:OJ C 202501943 of 2025 - BG Bulgarian.pdf being placed in Category:2025-04-14.

ReneeWrites (talk) 14:59, 23 March 2026 (UTC) - 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) - Turns out this template already exists: {{Published on}}, which automatically puts a file in the main date category, see for example File:OJ C 202501943 of 2025 - BG Bulgarian.pdf being placed in Category:2025-04-14. ReneeWrites (talk) 14:59, 23 March 2026 (UTC) - "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) - 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) - Pinging @TheDJ: as I don't believe they got a notification for this message.

ReneeWrites (talk) 18:56, 27 March 2026 (UTC) - I will use {{Published on}} moving forward, we just need a way to automate past entries. Update: {{Published on}} does not add a category, it will need to be modified to work like {{Taken on}}. --RAN (talk) 17:23, 27 March 2026 (UTC) - The dates are only added automatically if the file is a PDF, unfortunately. For images, those would still need to be added manually.

ReneeWrites (talk) 18:54, 27 March 2026 (UTC) - @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) - "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) - @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) - The dates are only added automatically if the file is a PDF, unfortunately. For images, those would still need to be added manually. ReneeWrites (talk) 18:54, 27 March 2026 (UTC) March 25 Help name the photographer I can't match the logo to any known photographer in Wikidata, can anyone help? File:Lt. Col. Gregory Mikhailovich Lukyanov (1848-1919) and others.jpg RAN (talk) 22:56, 25 March 2026 (UTC) - It looks like "C. Schulz" to me Category:Carl Schulz (photographer)?

REAL 💬 ⬆ 00:01, 26 March 2026 (UTC) - Looks like the name you got is right, can you make out the city under the name? --RAN (talk) 00:28, 26 March 2026 (UTC) - It definitely starts with "Nach". Could it be the Czech city Nachod? Or something abbreviated. Nakonana (talk) 18:11, 26 March 2026 (UTC) - "Carl Schulz" is quite plausible; do we have any other instance of him using this mark? - Jmabel !

talk 01:57, 26 March 2026 (UTC) - Is the photographer of any particular importance or even just relevant there? Prototyperspective (talk) 13:00, 27 March 2026 (UTC) - For pretty much any professional photographer, there are good reasons to track their work. Someone could easily be writing about that person at some point, and it is worth making their work easily found. See, for example, categories like Category:Photographs by Peterson & Brother or Category:Photographs by Asahel Curtis, or for that matter Category:Photographs by W.L.

Dahl (employed as a photographer by the city of Seattle). - Jmabel ! talk 17:55, 27 March 2026 (UTC) March 26 Can't crop image 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) - Would probably be good to move to Commons:Village pump/Technical. Prototyperspective (talk) 01:11, 26 March 2026 (UTC) - @RteeeeKed: Hi, and welcome. I am sorry to inform you that you have triggered Special:AbuseFilter/290. The proposal to "Limit file overwriting to users with autopatrol rights" was accepted with many supports and one weak oppose 15:19, 23 September 2023 (UTC). After an implementation problem in phab:T345896 and testing, Special:AbuseFilter/290 went live with the Disallow action 09:35, 28 October 2023 (UTC). Please read MediaWiki:abusefilter-warning-file-overwriting.

You may request COM:AP at COM:RFR when you think you are ready (once you have made more than 500 useful non-botlike edits); having that should allow you to overwrite. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:29, 26 March 2026 (UTC) - @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) - @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) - Is this solved then?

Prototyperspective (talk) 13:00, 27 March 2026 (UTC) - 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 ! talk 18:04, 27 March 2026 (UTC) - File:Daytona Cubs P4060068 - perspective adjusted, cropped out ads.jpg. - Jmabel !

talk 18:11, 27 March 2026 (UTC) - You can still see the URL of one of the advertisers at the bottom. Trying to crop it out myself, I get the same error. RteeeeKed (talk) 19:02, 28 March 2026 (UTC) - You didn't say how tight a crop you wanted, I cropped it to my taste. - If you do not have autopatrol then, no, you still will not be able to overwrite. - Jmabel !

talk 01:11, 29 March 2026 (UTC) - You can still see the URL of one of the advertisers at the bottom. Trying to crop it out myself, I get the same error. RteeeeKed (talk) 19:02, 28 March 2026 (UTC) March 27 Leave a ] when reviewing License Review gadget leave a ] when reviewing sources with the format of [url xxxx ]. Can some sysop or interface sysop consider to automatically remove this "]" by code when identified?

Lemonaka (talk) 18:48, 27 March 2026 (UTC) - @Lemonaka: A diff would help clarify what you are talking about. - Jmabel ! talk 19:20, 27 March 2026 (UTC) - Special:Diff/1187721073, Special:Diff/1187721301 and Special:Diff/1187721486 Lemonaka (talk) 19:22, 27 March 2026 (UTC) - I looked at the code for about 10 minutes trying to trace it back, but nothing leaps at me. @Lucas Werkmeister and MGA73: any idea? @Lemonaka: if you don't get anything here, this might better be a question for COM:VP/T. - Jmabel !

talk 04:45, 28 March 2026 (UTC) - 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)- I think in this part, index6 needs to account not just for\n but also for? (and probably& ), to slice off thesi= 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)- @Lucas Werkmeister and Lemonaka: That last sounds entirely reasonable. - Jmabel ! talk 17:07, 28 March 2026 (UTC) - 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)- But if we want to slice off the si= we also need to add '?' as a stop. But in File:20260319 Natsuki Deguchi 11.jpg it is still there and it seems to work. --MGA73 (talk) 11:52, 29 March 2026 (UTC) - But if we want to slice off the - I also think that - si= is just a Youtube tracking parameter it should be removed from all links - @Lucas Werkmeister and Lemonaka: That last sounds entirely reasonable. - Jmabel !

talk 17:07, 28 March 2026 (UTC) - REAL 💬 ⬆ 16:06, 29 March 2026 (UTC) - 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) - @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 !

talk 19:50, 29 March 2026 (UTC) - 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) - @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 ! talk 19:50, 29 March 2026 (UTC) - 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) - I think in this part, - My feeling, looking at those IDs, is that not just the - I looked at the code for about 10 minutes trying to trace it back, but nothing leaps at me. @Lucas Werkmeister and MGA73: any idea?

@Lemonaka: if you don't get anything here, this might better be a question for COM:VP/T. - Jmabel ! talk 04:45, 28 March 2026 (UTC) - Special:Diff/1187721073, Special:Diff/1187721301 and Special:Diff/1187721486 Lemonaka (talk) 19:22, 27 March 2026 (UTC) 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) March 28 Uploading screenshots of Wikipedia Are screenshots of Wikipedia considered own work or the editors'? --Like tW (talk, contribs, 🇧🇬 BG) 21:38, 28 March 2026 (UTC) - @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 ! talk 01:16, 29 March 2026 (UTC) - 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) - 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'.

In any case, this query shows up to 9236 files are marked as own work and are or include Wikipedia screenshots (note: some have been edited such as to add a red rectangle highlighting a part of the page; and for some the screenshot is only a part of a broader file): deepcategory:"Wikipedia_screenshots" incategory:"Self-published_work".

Prototyperspective (talk) 15:59, 29 March 2026 (UTC) March 29 Upcoming Wikimedia Café meetup regarding the the 2026-2027 Wikimedia Foundation Annual Plan ↠Pine (✉) 04:42, 29 March 2026 (UTC) Are informations behind an unifying template still recognizable by bots? 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) March 30 {{US states}} 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) - Convenience links: {{US states}}, {{Clickable map of USA Category}}. - Jmabel !

talk 04:39, 30 March 2026 (UTC) - 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 ! talk 04:42, 30 March 2026 (UTC) - I weakly object due to the fact that the map omits the territories and the District. —Justin (koavf)❤T☮C☺M☯ 05:41, 30 March 2026 (UTC) - Can't we just not use it for territories and the District?

Trade (talk) 07:04, 30 March 2026 (UTC) - @Trade: Then we might need {{Clickable map of Continental USA Category}} or perhaps {{Clickable map of Continental US Category}}. One might prefer "lower 48 US States", though. Other than the small size, what would keep the District of Columbia out of such a map? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:18, 30 March 2026 (UTC) - It would then be out of sync with {{US States}}, which is not just about the states.

—Justin (koavf)❤T☮C☺M☯ 00:28, 31 March 2026 (UTC) - But the locator is already here?--Trade (talk) 13:39, 31 March 2026 (UTC) - Can't we just not use it for territories and the District?

Trade (talk) 07:04, 30 March 2026 (UTC) UI display of Commons categories on mobile Have you ever visited a Commons category page on mobile?: - On the left, you can see how it looks like (with unused space highlighted) - On the right, you can see how it could look like (a screenshot of the same category in the Commons Android app) I made a wish in the ongoing Community Wishlist about this: W534: Fix the display of Commons categories and Wikipedia article galleries on mobile (voting open).

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) - I had this in mind, too, but always forget to speak up about it, thank you a lot :) --PantheraLeo1359531 😺 (talk) 20:12, 30 March 2026 (UTC) - 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) - 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. - What you built a proof-of-concept of is partly what related wish W413: Larger thumbnails in category views is about. Prototyperspective (talk) 22:55, 31 March 2026 (UTC) only show when hovered — hovering is not possible on mobile.

Nakonana (talk) 10:33, 2 April 2026 (UTC)- Indeed and thanks for the note; on mobile there could be a few pixels of screen height reserved for the title (similar to the Commons app screenshot) that can be trimmed to prevent it to be longer than eg needing more than 1 linebreak where one would need to tap on it on mobile to see the full title. There's images for which the title is redundant but usually or at least often it's useful.

A complication are file-titles in languages other than the one(s) the user understands but this problem is unspecific to mobile and for these cases one could show the caption if available in the user's language (however this still needs/would greatly benefit from language of file titles to be parsed). Note that captions are often not substitutes for file-titles, eg used similar to subheaders (eg info on the legend of a map instead of title a second time).

Prototyperspective (talk) 13:45, 2 April 2026 (UTC) - Is this an android problem? On iOS hovering is possible with specific finger movement. It is of course not super reliable and sometimes results in an accidental click. GPSLeo (talk) 14:58, 2 April 2026 (UTC) On the left [...] On the right [...] — those directions are a bit ironic given that this thread is about Commons' appearance on mobile, because, obviously, there's no left or right but only a "top" and "bottom" ;).

As a mostly mobile user I'm used to the category looks by now (although I'd love to see more info being displayed (like license and author or even categorization) and the thumbnails being a bit larger).- As for, gallery pages, I don't really use them and have no opinion on them.

However, when it comes to the gallery template (as it is used for the photo challenge and in some wiki articles) I'd really love to see this issue fixed: - Nakonana (talk) 10:19, 2 April 2026 (UTC) - Indeed, thanks for pointing it out.

As for, gallery pages I didn't mention gallery pages but maybe they should be mentioned in the wish idk – I don't use them much either so broken uses of the gallery tag at places like the one in your screenshot are what I was primarily referring to with elsewhere atuses of <gallery> in Wikipedia articles and elsewhere . - I don't know if your screenshot should be included in the wish; probably better not (mentioned maybe?). But there should definitely be a bug report on phabricator about it.

I haven't seen this yet since I don't use my smartphone much; will check on mobile later if that also occurs on my device. Could you create the bug report on phabricator? As a mostly mobile user I'm used to the category looks by now (although I'd love to see […] on a related note, things would be much better already if one could conveniently open a Commons page in the Commons app.

With most apps one can choose which app to open a link or open a website with if one has an app installed – for example one can easily open Wikipedia articles currently open in the mobile web browser in the Wikipedia app by selecting Open with -> Wikipedia app.

Then one could switch to the Commons app view of whatever Commons page one is viewing in less than a second.- See W438: When opening a file in the Wikipedia app, enable opening it in the Commons app (should maybe be renamed since it's not only about the Wikipedia app nor only about files). Prototyperspective (talk) 18:51, 2 April 2026 (UTC) - Indeed, thanks for pointing it out.

I'd just like to remind everyone that if we want to change the default gallery type for categories (in general not just mobile) to one of the other existing gallery types like "packed" we can. All we need is some sort of vote to deonstrate that it is the will of the community. Bawolff (talk) 19:45, 2 April 2026 (UTC) April 01 How many people categories is too much?

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) - Yes, everything that has a Wikidata item should also have a category. GPSLeo (talk) 06:02, 1 April 2026 (UTC) - No. If something has a valid wikidata item, then that's a justification for having it here too, against any questions of 'notability' [sic].

However it's not a requirement to have one, if it's not considered useful to Commons' own goals. Two obvious examples of this might be a highly notable topic where we just don't have any Commons content for it. Another one (which we've encountered previously) was for team photos, where the team had a wikidata item, as did each individual, but the only Commons content was a single photo of the entire team.

We certainly should not bulk auto-create a bunch of empty Commons categories (that are likely to stay empty) from a script run over Wikidata. Andy Dingley (talk) 16:05, 1 April 2026 (UTC) - No, a photo of some list with people's names on it shouldn't be in the categories of all those people but instead a broader category/ies like 'group xy', and/or 'zy lists of people', or 'characteristics zv', etc.

Or if you want to categorize lists with merely people's names on it, there's no need to discuss hypotheticals here. There's more than enough challenges and backlogs without discussing hypotheticals and I consider this thread solved. Prototyperspective (talk) 12:02, 1 April 2026 (UTC) - +1. The fact that a name appears in a document is not, in and of itself, a good reason to create a category representing that name. Omphalographer (talk) 18:26, 1 April 2026 (UTC) - How is it solved with two contradictory replies?

Is the assumption that your answer is correct, and the other answer is incorrect? --RAN (talk) 15:12, 1 April 2026 (UTC) - Maybe I misunderstood your question as to be about which categories to set on an image of a list while you're asking about whether we should create categories for wikidata items. If the latter is the case, then categories still should not be empty. In either way, this seems to be about hypotheticals and there's more than enough nonhypothetical things to discuss.

Prototyperspective (talk) 15:48, 1 April 2026 (UTC) - And if this is not hypothetical, it would be useful to have a concrete example. But I will venture slightly into hypotheticals. If we had a photo of the entire U.S. Senate of the moment, I would oppose adding a category to that photo for each individual Senator.

If we had a picture of a list of 1000 names of individuals, I would certainly not add categories for the all people named in the list, any more than I would add, for a PDF of a book, a category for every place mentioned in the book. - Jmabel ! talk 18:55, 1 April 2026 (UTC) - Maybe I misunderstood your question as to be about which categories to set on an image of a list while you're asking about whether we should create categories for wikidata items.

If the latter is the case, then categories still should not be empty. In either way, this seems to be about hypotheticals and there's more than enough nonhypothetical things to discuss. Prototyperspective (talk) 15:48, 1 April 2026 (UTC) - Maybe not places, but what about people? In that book pdf, there might be mentioned "Jim Smith" that we have a category already as "James H. Smith". How would someone refind it once the connection has been made?

People have synonyms and researchers need a way to aggregate all the information on a person. I can see not needing to index every mention of George Washington in a book, but some people are more obscure. --RAN (talk) 21:12, 1 April 2026 (UTC) - If the book has substantial coverage of the person, sure, but (for example) I would not want to tag a history of European art with the categories for 583 artists.

If anything, flooding the category with content like this makes it harder to find actually relevant material. - Jmabel ! talk 21:25, 1 April 2026 (UTC) - How would it make info more difficult to find? If I have no interest in the index of a book, I don't look at it. If I need to find someone, I use the index. Text searching has made most indexes redundant, but as pointed out people have synonyms.

RAN (talk) 02:01, 2 April 2026 (UTC) - +1, I think this issue is covered by Commons:Overcat, is it not? My favorite example (not with people, but locations) is that a world map should not be categorized into all hundreds or thousands of location-categories of the places that are shown and/or labelled in that map. Just because one dot in this map is labelled "Lhasa", does not turn that map into a "map of Lhasa", at least in my opinion.

The same logic goes for the hypothetical group photos of large-crows, for long name lists, or bound collections of short-bios. There are reasonable exceptions, but I think that most files with way over 10 categories are cases of overcat/miscat. --Enyavar (talk) 22:05, 1 April 2026 (UTC) - Commons:Overcat deals with redundant categories such as adding Category:Albert Einstein and Category:Physicists from Germany to an image of Einstein, not about properly identifying everyone in an image (or I assume list).

RAN (talk) 01:38, 2 April 2026 (UTC) - If that is so, then I think we should add a point to the Categories' policy about not adding hundreds/thousands of categories to files. Even if we could identify each of the people in this painting by name, I argue that we should only do so in respective crop-outs where those are needed... but not in the larger picture.

Enyavar (talk) 11:52, 2 April 2026 (UTC) - Commons:Overcat deals with redundant categories such as adding Category:Albert Einstein and Category:Physicists from Germany to an image of Einstein, not about properly identifying everyone in an image (or I assume list). --RAN (talk) 01:38, 2 April 2026 (UTC) - @Richard Arthur Norton (1958- ): flooding a category with tangentially relevant files makes genuinely relevant files harder to find. - Jmabel ! talk 20:18, 2 April 2026 (UTC) - +1, I think this issue is covered by Commons:Overcat, is it not?

My favorite example (not with people, but locations) is that a world map should not be categorized into all hundreds or thousands of location-categories of the places that are shown and/or labelled in that map. Just because one dot in this map is labelled "Lhasa", does not turn that map into a "map of Lhasa", at least in my opinion. The same logic goes for the hypothetical group photos of large-crows, for long name lists, or bound collections of short-bios.

There are reasonable exceptions, but I think that most files with way over 10 categories are cases of overcat/miscat. --Enyavar (talk) 22:05, 1 April 2026 (UTC) - How would it make info more difficult to find? If I have no interest in the index of a book, I don't look at it. If I need to find someone, I use the index. Text searching has made most indexes redundant, but as pointed out people have synonyms.

RAN (talk) 02:01, 2 April 2026 (UTC) April 02 Notification of DMCA takedown demand — Brixton riots, 1981 (enwiki) In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the Wikimedia Foundation office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me. The takedown can be read here.

Affected file: To discuss this DMCA takedown, please go to COM:DMCA#Brixton riots, 1981 (enwiki). Thank you! Joe Sutherland (WMF) (talk) 12:37, 2 April 2026 (UTC) Notification of DMCA takedown demand — Dragon Bravo Fire Pyrocumulus In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the Wikimedia Foundation office which should not be undone.

If you have valid grounds for a counter-claim under the DMCA, please contact me. The takedown can be read here. Affected file: To discuss this DMCA takedown, please go to COM:DMCA#Dragon Bravo Fire Pyrocumulus. Thank you! Joe Sutherland (WMF) (talk) 12:48, 2 April 2026 (UTC) Way to find categories with number of files over certain threshold? Apart from manual patrol, is there a reasonable way to find categories with number of files over certain threshold? I sometimes like to unwind performing different patrol actions in Wikipedia.

For example I would like to deep search category Churches in Poland to find all categories that have over 200 files, so that I would clean up main categories of specific churches. I thought PetScan tool might be able to do this, but so far no success. — Preceding unsigned comment added by Tupungato (talk • contribs) 15:02, 2 April 2026 (UTC) Broken Wikimedia image (sizes) This semester and last the embedded Commons images I've long used have been broken.

I was fixing them ad hoc, but today tried to figure out what was going on. It appears that a lot of the sizes that used to be served offsite no longer are? I have a python script, which might've fixed most of the issues, but though I looked I can not find the discussion of what changed and why.

❯ wikipedia-image-embeds-fix.py talks/ Updated 1 links in talks/180-privacy.md 1024px to 960px : https://upload.wikimedia.org/wikipedia/commons/thumb/8/8b/CPT-Proxy.svg/960px-CPT-Proxy.svg.png Updated 1 links in talks/056-brown-learning.md 1024px to 960px : https://upload.wikimedia.org/wikipedia/commons/thumb/f/fc/Laurentius_de_Voltolina_001.jpg/960px-Laurentius_de_Voltolina_001.jpg Updated 5 links in talks/075-darknet.md 512px to 500px : https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/Digital_signature_schema.png/500px-Digital_signature_schema.png 512px to 500px : https://upload.wikimedia.org/wikipedia/commons/thumb/5/55/Bitcoin_Block_Data.svg/500px-Bitcoin_Block_Data.svg.png 512px to 500px : https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Onion_diagram.svg/500px-Onion_diagram.svg.png 1024px to 960px : https://upload.wikimedia.org/wikipedia/commons/thumb/0/06/Iceberg_of_Webs.svg/960px-Iceberg_of_Webs.svg.png 128px to 330px : https://upload.wikimedia.org/wikipedia/commons/thumb/0/06/Iceberg_of_Webs.svg/330px-Iceberg_of_Webs.svg.png Reagle (talk) 20:22, 2 April 2026 (UTC) - Custom thumbnail sizes got entirely removed because of massive crawler traffic. See mw:Common thumbnail sizes for the available sizes.

GPSLeo (talk) 20:38, 2 April 2026 (UTC) April 03 Action Required: Update templates/modules for electoral maps (Migrating from P1846 to P14226) Hello everyone, This is a notice regarding an ongoing data migration on Wikidata that may affect your election-related templates and Lua modules (such as Module:Itemgroup/list ). The Change: Currently, many templates pull electoral maps from Wikidata using the property distribution map (P1846), combined with the qualifier depicts (P180): electoral result (Q19571328). We are migrating this data (across roughly 4,000 items) to a newly created, dedicated property: apportionment diagram (P14226).

What You Need To Do: To ensure your templates and infoboxes do not break or lose their maps, please update your local code to fetch data from apportionment diagram (P14226) instead of the old distribution map (P1846) + depicts (P180) structure. A list of pages was generated using Wikimedia Global Search. Deadline: We are temporarily retaining the old data on distribution map (P1846) to allow for a smooth transition. However, to complete the data cleanup on Wikidata, the old P1846 statements will be removed after May 1, 2026.

Please update your modules and templates before this date to prevent any disruption to your wiki's election articles. Let us know if you have any questions or need assistance with the query logic. Thank you for your help! ZI Jony using MediaWiki message delivery (talk) 17:11, 3 April 2026 (UTC)

People Also Asked

• Commons:Village pump - Wikimedia Commons
• Explore the depths ofwikipedia, one random entry at a time.
• TheProjectHub | JToH's Joke TowersWiki| Fandom
• Wikivoyage
• Actividad dewiki- MoodleDocs
• Explore a Map of Museums Listed in Wikidata - OEGlobal Connect
• dashboard.wikiedu.org vs meta.wikimedia.org Traffic Comparison ...
• dashboard.wikiedu.org vs outreachdashboard.wmflabs.org Traffic ...

Commons:Village pump - Wikimedia Commons?

Commons:Village pump January 02 History maps of Europe 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).

Explore the depths ofwikipedia, one random entry at a 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.

TheProjectHub | JToH's Joke TowersWiki| Fandom?

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.

Wikivoyage?

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.

Actividad dewiki- MoodleDocs?

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 ! talk 18:49, 2 January 2026 (UTC) - Thanks for that question, our categories about "history of" do not really care for nation states existing.