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.

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)

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)

@Stefan Kühn: , I have not responded before since I am not sure how this constitutes a similar problem, or what action you expect other users to take on behalf of your project. My own case is less about the exact nationality of specific locations; and more about hatnote definitions of these categories in general.

As nobody has yet voiced any opinion on the subject matter, I'm resolved to wait a bit longer. --Enyavar (talk) 11:29, 2 June 2026 (UTC)

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:

1. The template would be used for categories like Our World in Data maps of Oceania showing 1947 data, right?
2. 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)

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:

• {{Category description/Maps by continent and century shown}}
• {{Category description/Maps by continent and decade shown}}
• {{Category description/Maps by continent and year shown}}

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)

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)

But first, we need to categorize the OWiD maps. I populated the 1940s structure with a few hours of Cat-a-lot, but there is a catch: all these maps currently have the template {{Map showing old data|year=1942}}. For the 1940s alone, removing that template means manually editing 17'500 files. We must use a bot to do these edits, I think. The algorithm, for all ~75'000 maps of Asia would be roughly as follows:

• for all files in [[Category:Our World in Data maps of Asia]]
  • if "{{Map showing old data|year=YYYY}}" occurs in the file:
    • take the YYYY as a variable to insert "[[Category:Our World in Data maps of Asia showing YYYY data]]" //** a single category for the location and year of the map **//
      • if that inserted category does not yet exist: create it with "{{Category description/Our World in Data maps by continent and year}}" //** (as helpfully provided by Reinhard)**//
    • take the file name as the variable topicname and strip File: and , Asia, YYYY.svg (or ,Asia,YYYY.svg) from that variable
    • 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 **//
    • remove all occurences of "{{Map showing old data|year=YYYY}}", ""[[Category:YYYY maps of Asia]]" and "[[Category:Our World in Data maps of Asia]]"
  • (else leave the file alone)
• repeat the same with "Africa", "Europe", ["North America" or "NorthAmerica" would need to be mapped onto "North America"], "Oceania", and so on.

I do not know how exactly to program a bot, but I think this would do the trick, not only to create and populate the categories for continent-by-year, but also to have distinct categories for each topic. Right now, I don't think the latter exist yet. --Enyavar (talk) 19:51, 8 March 2026 (UTC)

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)

Could we talk about pure blank pieces of paper?

We're just populating Category:MLS real estate blank cards, which collects together blank cards, entirely white blanks apart from being perforated on the left hand side. Some users are reluctant to see these types of blank images deleted as they are part of groups of other stuff, but that seems a weak solution to the issue of whether Commons needs to host every page of documents or books which were scanned as separate images. More usefully these can be compiled as pdfs or djvu documents with only pages with photos and illustrations as correctly in scope separate Commons hosted image files.

Note, in this particular collection of MLS cards there are also "blanks" which have nothing but a filled in footer, identical and duplicating footers on other cards about the same estate that are not blank. In a literal way, we are not classifying these as blanks even if, uninteresting. This indicates that these completely blank pages are printer chuck pages between reports, not indicating anything meaningful. BTW, identifying blanks was a side-effect of finding photos for MLS real estate cards with photos, no extra processing time was needed.

In general Commons does not host files "that contain nothing educational other than raw text" with some exceptions, based on potential usefulness on other projects or obvious 'historical' educational value. These are a lower standard than that, because they don't even have meaningful raw text. For now, we seem to be by passing the policy of OOS/Scope and if these blanks are to become exceptions, we should have a consensus to reword the policy. Fæ (talk) 10:11, 16 July 2026 (UTC)

FWIW, the origin of the "raw text" thing was mainly to say "no, you can't take your article that was rejected from Wikipedia, put it in a PDF, and upload it here." - Jmabel ! talk 17:47, 16 July 2026 (UTC)

Plus not being a host for coding... I guess the way to reduce this question of policy to the basics and the long term mission, is to think of the reasoning in a deletion request based on a scope rationale of no discernible educational value of the individual file. If there is an counter rationale of a blank being a "placeholder" in a multi-page document, then that's why what should be hosted is a multi-page document of clear value, rather than a set of individual images, the weakest of which could be deleted any time in the future. Fæ (talk) 18:43, 16 July 2026 (UTC)

I fully agree. We should not have all these "(page XY)" files. Merging them into one PDF should be more suitable for scanned documents. I do not think that many files would run into problems with the file size limit. GPSLeo (talk) 19:11, 16 July 2026 (UTC)

+1 to that. I also raised that concern previously e.g. here. Documents should in my opinion ideally be uploaded in a document format - that being a single PDF instead of countless individual images. The main problem is that Commons is simply not at all designed to properly deal with this style of media storage - example: let's compare this random item, "1929 Appointment Diary of Mayor William Jackson". If we search for it on the source site, we get it as a single & as first result, that being the entire book consisting of 380 individual scans. If we do the same search on Commons, we get almost 400 results - all the individual pages, in a completely random order, with no useful structure to view the entire work whatsoever. The source ohiomemory.org stores the entire work also as single image files, with the difference that their software ("ContentDM") is actually capable of properly presenting these files. (To be fair, our MediaWiki software is not even at all intended to be used as a mass digital media archive (IIIF whats that), but I digress)
Note that this style of uploading multi-page works as individual images is absolutely nothing limited to DPLA uploads, it has been widely used in a variety of mass uploads (on many tens of millions of files). For example, the first duplicates of this empty file with 1,600 duplicates have been introduced in 2007 by bulk "individual page book" uploads. ~TheImaCow (talk) 20:14, 16 July 2026 (UTC)

Speaking of Category:MLS real estate cards with photos, we're creating more dead-end categorization? None of the ones I spot-checked contained categories related to date taken, location, type of building, style of architecture, etc. RadioKAOS / Talk to me, Billy / Transmissions 22:38, 16 July 2026 (UTC)

Picking out the cards which include photos at all is a first step. The majority of images in the collection are non-photographic, e.g. cards containing a diagram of the lot, textual information about the property, or blank cards as shown above. Omphalographer (talk) 22:57, 16 July 2026 (UTC)

Without saying what should be done, I do note that where we have a document stored as individual pages, there is quite a bit we could do with templates to make that more sanely navigable. - Jmabel ! talk 01:54, 17 July 2026 (UTC)

When the sorting in this case example is done, I might analyse exactly why these blank pages exist. Given the massive automated cover page cropping we've been doing to get rid of Google cover pages from pdfs, and another task to crop out pure white blank pages in the front of some book collections, there's an easy and uncontroversial precedent to compare with for 'terminal' blank pages which is probably what is happening here.

Maybe what we need to have sensible rewording of policy, is these exemplars settled in an uncontroversial way as our 'case book'. Consensus is then based on simple facts and precedent. Fæ (talk) 08:55, 17 July 2026 (UTC)

As highlighted, it's worth forming a view based on the parent category of 185,038 files, rather than the still populating sub category with c.500 files in it. Not sure I understand exactly what 'dead-end categorization' is, we do need source categories so that volunteers and bots can search across the large category as a specific type of 'sample space' or do smart category intersections using standard tools. These are useful in their own right and the intention is not to empty a source category. Fæ (talk) 08:59, 17 July 2026 (UTC)

How big would a composite document be? ShakespeareFan00 (talk) 18:55, 17 July 2026 (UTC)

Too big. There are 185,038 files in the category, with a total size of nearly 293 GB. Omphalographer (talk) 22:40, 17 July 2026 (UTC)

Rather than everything in an impossible document, this particular collection seems to be broken into regions for the agent. In https://digital-collections.columbuslibrary.org/digital/collection/p16802coll36/id/179579 there are 122 cards, several are blanks and a few are photos, so that would be a small 122 page PDF if 'compiled'. If the photos are automatically broken out, there's nothing else of interest apart from text notes and some rough sketches of road layouts. These may be of interest to someone researching the modern development history of the local area, but very, very unlikely to be of general interest on Commons or for transclusion to Wikipedia articles.

My feeling about this example of 185,000 images is that they are just space fillers. If Wikimedia Commons is going to claim an eventual "one trillion free images" it would be rather cruddy if half of that is blanks and fairly useless nonsense that could be held in 1/100th the number of documents. Fæ (talk) 10:15, 23 July 2026 (UTC)

File:DE CDB 1 18 285.jpg has many 1-pixel duplicates --PantheraLeo1359531 😺 (talk) 13:40, 23 July 2026 (UTC)

Amazing. Why were these created? Fæ (talk) 18:49, 23 July 2026 (UTC)

I feel compelled to also add a few cents into the discussion of blank pages. In 2023 a major part of the archives of Gallica (National Library of France) was uploaded to commons, and a lot of that content still awaits categorization. Many of the scans from Gallica are named "(2 of 3)" - which would be the image file - and the other two pages are "(1 of 3)" and "(3 of 3)" respectively, these two are the blank pages into which the actual content is sandwiched. Keeping a whole category specifically for that one content image and those two blanks is not a good use of our category system; and so a group of few editors removes blanks from scanned compilations of Gallica and recategorize the remaining file based on the content. The same is done for full Gallica book scans: A category with 300 files is quite often just 150 content files and the rest are blank pages that only contribute to longer loading times and the frequent loading errors when the book category is opened. Some tenthousand blank pages are kept in Reverse sides from Gallica, and the reasoning behind keeping them is that future editors might be interested in the blank pages: Check for (rare) marginal notes, look up why so many pages are "missing" from the larger book categories.

That was the setup why I feel involved, now here's my thoughts: Commons as a project does not strictly NEED these blank pages. We could summarily delete them all (after checking that no blank page was accidentally placed in the category... it has happened before) and not lose anything valuable. But on the other hand, the project is set up in a way that we would not really delete the content, we'd just hide it from public view. The database is not getting any smaller from deletion. Which means, there is no harm in keeping the blanks in the open for the vague purposes that they may have, like I outline above.

Still, these blanks are an unavoidable byproduct of mass-uploads, and if there is a good reason to remove them, I'd have no objection. --Enyavar (talk) 18:13, 30 July 2026 (UTC)

Thanks for the example. These seem to have a clear rationale to keep, because the frequency of finding notes on the back looks high. However, if the frequency were quite low, there could have been a stronger rationale to delete blanks, for the benefit that exceptions with potentially useful notes would be easier to find for readers.

BTW, it's often said that "deletions don't save server space", but that's not the only benefit to Wikimedia Commons of deleting unnecessary files. These deletions speed up searches, reduce clutter and 'spam' in results and make the chances that readers and reusers will find something useful much more likely. Folks are normally searching commons for useful photos or images, not 80 separate images of text pages from state council minutes from 20 years ago that happen to match a search word. Fæ (talk) 18:36, 30 July 2026 (UTC)

Should we start Banning or Blocking .webp images?

Should we start banning or blocking .webp images from being uploaded on commons? Obviously the format was created for use on websites and i have not come across a single .webp images here which was free and its usually void of EXIF data (which is what it was designed for) so cannot be guaranteed as a free image and no real photographer will ever convert their images to this format intentionally so all in all, all .webp images are not free, so why do we allow them?. Atleast with .svg and other vector formats, its not photographs that are converted into them so are nearly always free and in public domain. I'm not sure if a discussion regarding this ever took place on commons and if not, why? at the very best, we could force a warning to anyone uploading .webp to confirm the image was "taken" by them and to warn them why .webp images are not a trusted format and should not be uploaded, atleast with .png, we can confirm if they were taken off a video, webp images are also hard to reverse search so will become an issue for admins and licence reviewers in the future to verify their authenticity. ....--Stemoc 06:33, 22 July 2026 (UTC)

Yes, I agree with that assessment. At least 99% of WEBP images uploaded to Commons are copyright violations. I don't know of any device which output images in WEBP format by default. And I don't see the benefit for Commons to use it. At the very least, it should be restricted to users with some advanced rights (like MP3). Yann (talk) 07:07, 22 July 2026 (UTC)

Oppose No, @Yann ISRO and other images from India are uploaded under Webp format and thus blocking and banning should not be very good for those images Abdullah1099 (talk) 03:23, 3 August 2026 (UTC)

 Support — Draceane ^talk_contrib. 07:18, 22 July 2026 (UTC)

 Support conditional upload ban. Grant only to the admins/sysops, template admins, and autopatrolled users the privilege (not right) of uploading images with w:en:WebP format. Do note that tagging problematic files has become slow due to problems when searching images using Google Lens, see this comment of mine. That's why slowing down problematic content uploading is crucial, if we cannot eliminate it completely. I'll also add that a couple of WebP uploads, likely from regions like the Indian Subcontinent, West Asia, and Africa, are personal images that are out of COM:SCOPE. One previous discussion: Commons:Village pump/Proposals/Archive/2023/11#Restrict_webp_upload？. JWilz12345 (Talk|Contributions) 07:37, 22 July 2026 (UTC)

 Comment I have come across many images that were free and in WebP format, such as those copied from US Government websites. I think it'd be a shame if we couldn't have copies of images from NASA or from the USACE here, amongst others. I could support requiring some level of permissions here before being allowed to upload them, such as is done with MP3, but I don't think an outright ban would be the best plan. PeterCooperJr (talk) 12:54, 22 July 2026 (UTC)

The first image listed is available as a PNG at the source site - . (And it's a somewhat blurry photo, possibly captured from a video stream; nothing would be lost by converting it to a JPEG.) Omphalographer (talk) 22:20, 22 July 2026 (UTC)

Yeah, that probably wasn't the best example, it was just the first thing that popped up in my search of PD-USGov webp files. Just in general, WebP is an open format, that organizations and individuals can (and have) provide useful images in. PeterCooperJr (talk) 22:45, 22 July 2026 (UTC)

 Comment While it has been my own policy to convert WEBP images to JPEGs before uploading, yes, I have run into a fair number of PD images that download as WEBP. - Jmabel ! talk 22:51, 22 July 2026 (UTC)

 Comment WEBP has its use in tracking problematic files, as WEBP ≈ copyvio is often true. But that doesn't consider workloads of people patrolling files. On the other hand, a ban would encourage some people to simply convert their copyvios into the inconspicuous JPEG format. A middle ground could perhaps indeed be found in enforcing some restrictions, autopatrol as for MP3 could work. Regards, Grand-Duc (talk) 01:35, 23 July 2026 (UTC)

 Comment Maybe only allow upload with higher user rights. I sometimes upload WebP files from a CC0 website :) --PantheraLeo1359531 😺 (talk) 13:42, 23 July 2026 (UTC)

•  Comment Possibly only block if claimed as "own work". (As Jmabel notes, some archival public domain images can be found online only as webp - I too generally convert them to jpg or png before uploading.). -- Infrogmation of New Orleans (talk) 14:08, 23 July 2026 (UTC)
• As for JWilz12345. We can accept these from trusted users. Otherwise we're better without, because (and only because) of the copyvio likelihood. I don't see 'own work' claims as a useful discriminator here. Andy Dingley (talk) 14:15, 23 July 2026 (UTC)

•  Strong oppose - ISRO and many other images from India are uploaded in .webp format and they very like the format. It would be very problematic for uploading as there is a good backlog of ISRO images that are not uploaded to commons and all are .webp images. Also i don't understand why .mp4 and .mp3 videos are not allowed to upload on commons as they are one of the more common use format for Video.

Abdullah1099 (talk) 03:37, 3 August 2026 (UTC)

@Abdullah1099 MP3 files are actually allowed, see COM:MP3. However, you must have autopatrolled user rights first, considering that a huge chunck of MP3 media already existing online are not in the public domain or under a commercial or free licensing. For MP4, see Commons:Requests for comment/MP4 Video. JWilz12345 (Talk|Contributions) 03:47, 3 August 2026 (UTC)

 Support, as others have already mentioned, the right should be granted starting at Autopatroller or even Patroller level. זיו「Ziv」 • For love letters and other notes 18:13, 23 July 2026 (UTC)

•  Oppose Some uploads are copyvios, but there is not enough reason for a full ban. You say that “no real photographer will ever convert their images to [webp]”, but Commons is not only for photographs. Some illustrations will look ugly if you write them as jpeg even in good quality, and are unnecessarily large size if you write them as png. We do need a more modern format (or two really, since webp is a hybrid with separate lossy and lossless modes) even if adoption is slow. – b_jonas 07:57, 25 July 2026 (UTC)

  SVG is best for illustrations. A diehard editor (talk) 16:34, 25 July 2026 (UTC)

•  Oppose - Users who upload .webp images are not going to give up uploading, just because the filetype is blocked. Banning a filetype only invites the offending users to switch to a different file format (which would be .png natively, but also conversions into .jpg and .gif), and that just makes it harder to identify potential copyvios, because the files are going to be encoded differently than the original on the internet. --Enyavar (talk) 18:33, 30 July 2026 (UTC)
•  Strong oppose EU Space website now exclusively uses WEBP format for image of the day that are imported by my bot. vip (talk) 18:37, 1 August 2026 (UTC)

AI query

What is wrong with this image? File:KewSparkle24-34.jpg Faces seem AI, but rest of set seems ok. No Swan So Fine (talk) 20:04, 24 July 2026 (UTC)

Looks like an editing attempt that went totally wrong. GPSLeo (talk) 21:11, 24 July 2026 (UTC)

Deletion request seems the right step. It's unclear why this is so weirdly AI generated and can be deleted as that's not declared and it's not of realistic educational value. Fæ (talk) 21:21, 24 July 2026 (UTC)

Listed for deletion. -- Infrogmation of New Orleans (talk) 21:45, 24 July 2026 (UTC)

My guess is that these photos were taken in low-light conditions, and the camera (probably a cell phone) is doing a bad job of inferring details from what is probably an extremely dark, noisy source image. Omphalographer (talk) 21:54, 24 July 2026 (UTC)

Can "Adobe Photoshop Camera Raw 17.0.1 (Macintosh)" do this?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:58, 24 July 2026 (UTC)

The only other awful ones are File:KewSparkle24-29.jpg and File:KewSparkle24-27.jpg. No Swan So Fine (talk) 22:09, 24 July 2026 (UTC)

The filter on modern smart phone cameras applies a smoothing effect that's similar to the surface blur filter in Photoshop. This creates an artificial smoothness/sharpness, but it doesn't distort images in the way shown here. ReneeWrites (talk) 23:42, 24 July 2026 (UTC)

@ReneeWrites: I'm not sure a phone camera couldn't distort like this. See File:Down North 02.jpg (which I took with a phone). I believe it is close to the limit of acceptable distortion of this sort, but it does seem to be the same sort of distortion. - Jmabel ! talk 05:20, 25 July 2026 (UTC)

The smartphone camera on blurry or extremely zoomed-in images smoothes out areas, creating a kind of blotchy/posterized effect. It is a kind of distortion, but it's different from what we see here. ReneeWrites (talk) 22:37, 25 July 2026 (UTC)

Has anyone got experience of auto detection of odd untagged AI images/enhancements like this? It feels like this is something that could be usefully mass tagged if there's a reliable way of doing it. --Fæ (talk) 07:55, 25 July 2026 (UTC)

An experimental search for "Adobe Photoshop Camera Raw 17.0.1 (Macintosh)" was not much use for detection. The random handful selected from other uploaders looked okay rather than hyper-corrected. See https://quarry.wmcloud.org/query/107666 Fæ (talk) 08:09, 25 July 2026 (UTC)

@Fæ: Sorry I'm such a newbie with AI...Is this AI? File:Folklore soeur dans une ruelle de paris.webp It was uploaded to Wiki Loves Folklore which is annoying if it was. What is best practce if I encounter AI suspected images? No Swan So Fine (talk) 15:46, 27 July 2026 (UTC)

If it looks bad, put it up for deletion. Any image that is visibly AI and not in use or of *obvious* value is safe to put up for a deletion discussion on ground of being out of scope COM:OOS. Nobody would take such a DR in bad faith, it's more housekeeping; and yes, the example you give looks terrible. Fæ (talk) 15:50, 27 July 2026 (UTC)

Category: July 2026 in Amsterdam

Lately, I've noticed that this category is invariably overwritten by "Photographs taken on etc." if more photos were taken that day. I have no objection to this, but the first category was visible to everyone (and mentioned Amsterdam), while the second is invisible (and doesnot mention where the picture was taken). To see which photos are in it, you need to know the exact date, but you cannot retrieve them together. Is this intended (as it currently stands)? It seems better to me to simply continue the category "July 2026 in Amsterdam" and add "Photographs taken on" as an extra public or hidden category.Ceescamel (talk) 09:52, 25 July 2026 (UTC)

I repeatedly raised this topic before, without much success. Ymblanter (talk) 13:03, 25 July 2026 (UTC)

@Ceescamel: what you describe as "better" is how I always do it when adding {{Taken on}}. But I have no idea why the "Photographs taken on [DAY]" categories aren't simply made visible. Nor why, now that we have Template:World cat, they aren't all implemented with that template. - Jmabel ! talk 19:40, 25 July 2026 (UTC)

I'm also not sure why "Photographs taken by day" categories aren't visible. I would be in favor of changing that, I feel like that would solve a lot of issues related to this topic. ReneeWrites (talk) 22:32, 25 July 2026 (UTC)

+1 on making the by day categories visible. Nakonana (talk) 09:45, 26 July 2026 (UTC)

Considering the revision history of the source template {{Photographs taken on navbox}}, this may be a bit more controversial than it looks. Arguments for or against seem to boil down to whether to regard these categories as meta or topical. If unhidden, I hope this will not be abused as a shortcut to clear out Category:Uncategorized files and that more descriptive categories will still be applied too. --HyperGaruda (talk) 05:43, 30 July 2026 (UTC)

Agreed that this absolutely should not count as a reason to remove Category:Uncategorized files. Question: has there been a problem with people adding a category that is clearly nothing like a main category for a picture, removing Category:Uncategorized files, and not substituting some more specific indicator of needing further categorization? - Jmabel ! talk 17:22, 30 July 2026 (UTC)

Sorry, had a bit of a brainfart. I've been going through the unhidden Category:2015 photographs of Suriname lately, where many of its files, like File:Downtown Paramaribo (23486740169).jpg have only had a country&date category since their upload almost 10 years ago. And then all those unidentified plants in the equally unhidden Category:2016 in the United States, yet there is no way to search for them, let alone identify them, unless one stumbles upon that category by accident. To me, these files are essentially lost do the dark depths of Commons. --HyperGaruda (talk) 07:21, 1 August 2026 (UTC)

Forgot to mention: if hidden and it is the only category, at least a bot will now flag it as uncategorized, giving it a chance of being noticed and categorized properly. --HyperGaruda (talk) 07:25, 1 August 2026 (UTC)

Replace main page links to search links

Today during Unpopular Talks it was proposed to replace links currently using technical and kind of confusing categories like Category:Images (something that is mostly text), with something that shows actual media to our readers.

This idea seems to have received warm feedback from the people on site (on Wikimania). So let's fix it :)

(a) The basic idea would be to replace the image link etc with a generic search of a specific type, like so:

• images
• video
• audio

Works best for images and video.

(b) Another option is to vary the links for different languages: images, search for "en" – this could maybe search using the current user's language, which should kind of give local images (most of them would be local; for example, "pt" might show a periodic table at the top, but still better than a generic category).

What do you think? Shall we engage? ;) Nux (talk··dyskusja) 21:19, 25 July 2026 (UTC)

my attempt is at commons:explore (the selection of images will change everytime you purge the page or if you wait enough time) Bawolff (talk) 23:10, 25 July 2026 (UTC)

I think step one would be to decide (1) who is the intended audience for those links and (2) what are we trying to communicate to them. -Jmabel (talk) 22:44, 25 July 2026 (UTC)

1) Intended audience is mostly new users and users unfamiliar with Commons. Other people know their way around and can find categories if they need to.

2) We should be trying to communicate that we have a lot of media of different types. Nux (talk··dyskusja) 23:23, 25 July 2026 (UTC)

So you believe it's new end users, rather than new contributors? Wondering if that is general agreement; I've never really given it much thought, myself. But if that's the case, then I agree that categories are a poor choice. - Jmabel ! talk 00:10, 26 July 2026 (UTC)

i would go with its for anyone who wants to browse the commons collection instead of look for a specific file. I think that can be both old and new users, but probably an emphasis on newer users. Bawolff (talk) 04:12, 26 July 2026 (UTC)

I agree. Having a link to a search page would both allow browsing through everything and easily refine search to browse through topics. Nux (talk··dyskusja) 06:50, 27 July 2026 (UTC)

yes i raised the same thing just months ago Commons:Village_pump/Archive/2026/03#c-RoyZuo-20260305150400-Change_links_on_main_page.

Bawolff's Commons:Explore pages are very nice replacements.

the search result links could get quite stale (depending on how frequent and how many commons files get "assessment"). also assessment for videos is still not implemented, with phab:T419131 triaged LOW 🤷 and waiting forever. RoyZuo (talk) 10:35, 30 July 2026 (UTC)

Yeah, you're right. The search page might be problematic for sounds and videos, and using videos without review could easily expose someone to NSFW stuff (I know we don't want to censor stuff, but you know, practical reasons).

As long as Bawolff's Explore module is updated regularly, I think that might be a better solution. @Bawolff, do you already have a bot updating the JSON files, or is that something planned for the future? If that's working, then I'd be in favor of replacing the main page links with links to Explore. Nux (talk··dyskusja) 11:02, 30 July 2026 (UTC)

There is no bot yet. Mostly because nobody was really using it so there didn't seem much point. If people start actually using it, I can make a bot. Note that no attempt is made to remove NSFW images, and some featured pictures are arguably nsfw, however that is usually the type of nsfw people care less about. Bawolff (talk) 12:19, 30 July 2026 (UTC)

What are the inclusion standards for obscure pride flag/symbol designs?

We have a lot of little-known/used/recognized sexuality and gender identity flags and symbols. Commons is very tolerant in its scope, and doesn’t care about “notability” in the enwiki sense of only allowing things that are substantially covered by the mainstream media and scholarly publications. Most scope-based deletions target quality and redundancy more than anything else. So where do we draw the line for files that are neither low quality nor redundant, that have at least a hypothetical educational utility, but take the form of abstract symbols that require widespread adoption to have any meaning whatsoever? Is anything made up by anyone fine? Does it require a 3rd-party source, no matter how flimsy? Does it need to be covered by at least a reliable source? Do we need (at the opposite extreme of no standards whatsoever) Wikipedia-level sourcing requirements proving notability? A major concern here is whether we should allow citogenesis-style creation of original designs or only document existing ones. Commons is generally more skeptical of original content if it lacks obvious educational utility. My personal stance is that we should maybe make an exception to our “no such thing as notability” philosophy here, and require either at least one mainstream/scholarly source documenting a design and/or at least two or three alternative sources that are independent from each other and the creator. We shouldn’t gatekeep based on enwiki standards, but we’re also not a place for anyone to dump their cool new design for an examplesexuality or placeholdergender pride flag. Dronebogus (talk) 07:17, 26 July 2026 (UTC)

 Agree, I've seen files being kept that should by all rights have been deleted for being out of scope due to having no realistic educational value. ReneeWrites (talk) 07:57, 26 July 2026 (UTC)

We already have an exception: Commons is not a hosting website for personal art, nor is it a place for advertising / activism. Pride flags have been deleted on that basis. If a flag isn't in use by any group, then it's just personal art.

If you want to read a lengthy case of someone, who uploaded such flags, even getting blocked for the out of scope uploads and failing in getting the files undeleted and themselves unblocked, see this unblock request for example. Nakonana (talk) 14:09, 26 July 2026 (UTC)

Rather than 'mainstream', it would be friendlier to say realistically in use and published as such. There are special style Pride based flags, badges or logos for protest groups and social groups. There are also anti-LGBTQ type flags, again it can be useful to have a record of these, so long as there is a history of being realistically in reasonably wide use, not an individual on a disruption campaign.

I'll share this VP thread in our WMLGBT+ user group (which has its own Pride style emblems on Commons...), though worth noting that inclusion/exclusion of rainbow flags is a recurring discussion. Fæ (talk) 21:17, 26 July 2026 (UTC)

I've brought a number of these files up for deletion in the past, e.g. Commons:Deletion requests/Files uploaded by Nonbinary-Naturalist. A standard test I've proposed for inclusion of identity/pride flags is that they should only be kept if it can be demonstrated that the flag is recognized as representing some group, by people who are outside that group. Omphalographer (talk) 00:29, 27 July 2026 (UTC)

I think it’s unreasonable to require people outside a certain group to recognize something for it to be legitimate, especially given sexual and gender minorities are discriminated against and the further from “normal” society they are the less likely they are to receive any recognition or discussion outside their own group. A symbol should be widely adopted within a community, and sources from within the community should be acceptable to demonstrate that. Dronebogus (talk) 00:36, 27 July 2026 (UTC)

I agree with Dronebogus here. The bar for these should be pretty low (as it should be for political flags and emblems), but there should be some evidence of "real-world" use extending beyond the person who created the flag and their personal friends. When a single individual claims to have created the flags for a dozen different sexual orientations, I for one get pretty skeptical. - Jmabel ! talk 01:49, 27 July 2026 (UTC)

Rather than a hypothetical discussion, a case book would be a practical approach. It would establish the types of image that raise questions, and help to define what counts as reasonable educational value for these emblems or flags. Perhaps there are some useful deletion discussions with varied results that illustrate the current community consensus? Fæ (talk) 04:01, 27 July 2026 (UTC)

You are welcome to check out Category:LGBT related deletion requests for precedents Dronebogus (talk) 04:26, 27 July 2026 (UTC)

The deletions are useful to review. Certainly it is not controversial to delete unused and not notable pure fictional flags, user created works with no evidence of being in use, and "solo" works where the only evidence is one person creating a flag and using it by themselves. In one of the deletions a flag with Confederate symbolism was mentioned as having been seen in use, and had there been supporting links to video or photos of it in use, that might have been sufficient for a keep result.

In general I doubt there's much of an issue as the numbers involved are quite small compared to wider discussions about flags and maps. Fæ (talk) 04:41, 27 July 2026 (UTC)

Commons do care a bit about notability in the sens that we often need a source (for copyright, for scope, etc.). An image can be obscure (and we have millions of pictures like little chapels in the mountains that no-one heard about) but we need to know where it comes from, what it is about, etc. and it relies on sources. In the recent deletions I've seen a lot of comments around that (more or less directly) and I think we should focus on that. Also, the source can give information about the author and thus about copyright (some flags are pretty simple and under TOO but not always, more data would help). Cheers, VIGNERON (talk) 12:09, 27 July 2026 (UTC)

Category:Sinners seems to be a bit of a mess.

It seems to act as if it's for a German musical group (but presumably not the metal band which is at Category:Sinner (band)), but also contains other images which seems to be depicting persons who have commited Christian sins. StarTrekker (talk) 13:04, 26 July 2026 (UTC)

11 files is few enough that this could be resolved manually, such as by moving the band's files to Sinners (rock band); then Sinners can redirect to Sins. Arlo James Barnes 22:31, 26 July 2026 (UTC)

That’s a good idea Dronebogus (talk) 04:24, 27 July 2026 (UTC)

COM:SCOPE vs COM:AIIP

Not sure of the best way to move this forward: there was a discussion at Commons talk:Project scope/Archive 4#Proposed change: excluding images do not comply with COM:AIP from COM:INUSE rules that ran from December to March about whether COM:SCOPE took precedence over COM:AIIP or vice versa. It was archived with no action, and it remains ambiguous what view Commons takes on AIIP images which are in use on other projects. Some DRs keep them when the guidelines are pointed out, others delete them.

Can I request a formal retrospective review of that discussion - either interpreting and applying its outcome, or judging that it was made in the wrong place so carries no weight and should be restarted elsewhere? Belbury (talk) 09:58, 27 July 2026 (UTC)

Commons has a history of not being good at gaining a consensus on policy changes. Glaringly awful examples can help get volunteers more interested in the problem. Is there a central category, or categorizing template, that can be required, or by maintenance actions enforced, to apply to all AI images of identifiable people? Fæ (talk) 13:08, 27 July 2026 (UTC)

Extremes of each case would maybe be File:HÀ LÊ.jpg (a clearly very bad AI upscale of a named person) and File:Alireza Ahmadi Teyfekani.png (an AI altered or generated portrait which some projects would consider acceptable). Both are currently in use on other projects. Some admins would delete both files under COM:AIIP if they went to a DR, considering but disregarding the usage; others would keep both as COM:INUSE, considering but disregarding the low quality.

Category:AI-generated media of real people is a category for relevant files, Category:AI images of identifiable people related deletion requests for past DRs. Belbury (talk) 15:40, 27 July 2026 (UTC)

Looking at Project scope/Archive 4 § Proposed change: excluding images do not comply with COM:AIP from COM:INUSE rules, I don't see an emerging consensus. I see some mentions of COM:DIGNITY and suggestions that COM:AIP, like COM:DIGNITY, is more of a subsection of COM:PEOPLE rather than competing with COM:SCOPE (or, more specifically, with COM:INUSE). Some people go further, arguing that the Commons community should not overrule what Wikipedia editors find useful (and so COM:AIP must not overrule COM:SCOPE/INUSE). Others say COM:SCOPE is broken and Commons already rules against some images even when they are used (which is true, but COM:SCOPE does mention some explicit exception like for COPYVIO, and COM:SCOPE does also explicitly mention COM:PEOPLE as an overriding factor for INUSE). A note here that both COPYVIO and PEOPLE is mostly about legal bindings so things that would come from WMF terms of use anyway (this is also mentioned in the discussion). I've also seen concerns that it is too early to make COM:AIP a rule that would outweigh other rules, as there would perhaps have to be a vote to add COM:AIP explicitly to COM:SCOPE, but COM:AIP is not yet final. It also seems that only a minority of users think genAI is universally bad (or close to being universally not useful); most seem to say genAI is a concern to take into account and mark clearly.

A side note from Wikimania (which just finished): I saw and listened to two panels on AI with perspectives from different countries, and also various other talks (some about scientific research and some about community discussions about AI in different contexts). As I understand it:

• dewiki might be the closest to having a genAI ban (mostly allowing it for research),
• on frwiki, genAI is not advised for creating good articles but is not specifically banned (I guess the summary was: use it, but check it),
• enwiki's ruling is still pending, and it is trying to be a global steward of rules for other small wikis,
• plwiki decided not to have specific rules for the moment, but you can get blocked for overusing AI (much like for overusing any other automated tool).

In summary: At the moment, I think opinions are close to being split down the middle (at least among active users on Commons): some people think that images using genAI for identifiable people are mostly fine as long as Wikipedia editors think they are fine (COM:INUSE being more important than COM:AIP); others think genAI is, in many cases, AI slop or just not useful, and that if local projects want to store such images, each of them should store them separately (in which case COM:AIP would probably have to be mentioned in COM:INUSE).

Next steps: So I think the best thing would be either to wait for policies around AI to become clearer (which might not happen this year) or to create a vote/RfC that is widely communicated (pumps/bistros/bars on all wikis). This will affect many communities, almost none of which think AI is inherently bad. A vote on a separate page would be best (perhaps something like meta:Requests for comment/The future of Abstract Wikipedia, but maybe with a slightly more NPOV summary). As an outcome of the vote, make COM:AIP a rule and mention it in COM:INUSE as an explicit exception XOR change AIP to explicitly mention that it does not overrule COM:INUSE.

I hope this is a good summary Nux (talk··dyskusja) 14:55, 28 July 2026 (UTC)

The initial pump proposal to create the COM:AIIP guideline is also split (in the few comments where INUSE is mentioned) on whether it would obviously override INUSE, or obviously wouldn't. There doesn't seem to have been a clear consensus on the question.

Is there no established process or fallback to apply, when a new guideline interacts ambiguously with existing policy? As a user I don't know whether Commons wants me to flag these files for deletion, or wave them through.

If shifting the interpretation from "AIIP maybe overrides INUSE or maybe doesn't" to an unambiguous "AIIP always overrides INUSE" seems like a big question that would need cross-wiki discussion, and if a shift to "INUSE overrides AIIP" wouldn't (as this wouldn't affect other projects), could that be a sign that the interpretation should default to the latter until the big cross-wiki question is actually raised? Belbury (talk) 16:50, 28 July 2026 (UTC)

I don't have much experience with how this works in practice on Commons, but I know a lot about the rules and guidelines on plwiki, and I assume practical handling is similar. When the rules are not clear, it means that, depending on the specific case, an admin may rule one way or the other (which was also shown in the discussion on Common). This gives admins more freedom when making rulings, but it also places a greater burden on them in the long run. For example, Abzeronow voted for COM:AIP, but, based on common sense, restored some GenAI images because they were covered by INUSE in contrast to what COM:AIP suggest. So based on votes for COM:AIP you cannot say that COM:AIP is more important then COM:INUSE. That probably doesn't help you ;)...

So, after reading the discussion, I think you can say the following for now:

• COM:AIP requires disclosing when an image is generated by AI.
• When an AI image is used in many Wikipedia articles, you probably should not remove it based on COM:INUSE.
• When an AI image is also problematic under COM:DIGNITY, you should probably remove it.
• When an AI image is rarely used or not clearly marked, it's up to an admin to decide if COM:AIP or COM:INUSE is more important.

Nux (talk··dyskusja) 19:26, 28 July 2026 (UTC)

Do you mean by "remove" deleting the file on Commons (so it's not just removed from articles on sister projects while kept on Commons)? Assuming yes, those seems like things most of us can support as a common ground. And I think "most of us" is the best we can do here, realistically speaking. whym (talk) 10:12, 30 July 2026 (UTC)

Yes, by "remove" I meant "delete on Commons". Having rules on Commons that require local wikis to upload the file locally is problematic because it kind of defeats the purpose of Commons. Commons is, after all, a place where we upload a file once and use it everywhere, which saves space (good for servers) and effort (good for humans ;)). So that is why I think there would have to much wider vote/discussion before a rule like that is implemented (so before we decide AIP is more important then INUSE). Nux (talk··dyskusja) 11:12, 30 July 2026 (UTC)

Deleting single-page JPGs "redundant" to PDFs

Recently, some editors began a project of converting series of JPGs of multi-page works that had been uploaded by bot into single PDFs and then requesting deletion of the orginals, which were uploaded by bot. I wanted raise the issue here, as it is spread across several DRs, but it seems like a discussion is warranted. See examples here, here, here, here (and there are more, some deleted, some not). There are a few concerns:

• JPG->PDF conversion is inherently lossy, and retaining originals does not preclude still creating the PDFs if they are desired
• Increased complexity to avoid re-uploading these files, when the original has had its file name and extension changed (how to then detect that the file is already on Commons, if the sha1 hash no longer matches)
• No possibility of future updates from the institution, since the bot would typically sync any changes to the original JPGs to their file pages in Commons, but now cannot do so for a generated PDF
• Difficulty for reusers in the projects outside of Wikisource, since it is not generally user-friendly to add a single page of a PDF on Commons to a Wikipedia article, like it was for the original JPG

I am trying to weigh what the value is of performing these deletions, versus maintaining the files as they in the original repository, and I have not found much in policy about this type of situation. While project scope does say something about PDFs being permitted "only in appropriate cases", it does not suggest that having converted scan files to PDF renders the originals OOS (as is being suggested). This seems to fall under the COM:REDUNDANT section of deletion policy, which doesn't clearly state such redundant files should be deleted other than "you will need to provide reasons why a particular file is inferior to the alternative version" (without stating which would be considered inferior in this case)—but I did find the old discussion at Commons talk:Superseded images policy which seems to indicate a lot of opposition to deleting original files that others converted to an alternative format just because they were superseded. There was also a past VP discussion about keeping PDF and DjVu duplicates, which is analogous because it generally established that different stakeholders could have different reasons for preferring different formats, and there is not a harm in co-existence of the versions in such cases. I think a wider conversation would be good. Dominic (talk) 17:07, 28 July 2026 (UTC)

Re. the first - it is technically possible to losslessly convert a set of JPEG images to a PDF. I'm sure some tools will recompress the images, but it's not inherent to the conversion.

Re. the last - individual pages of a PDF can be embedded using the syntax [[File:Example.pdf|page=2]]. It's not so difficult that we should need to keep every single-page scan just on the off-chance that someone might want to use it and might not know about this syntax. Omphalographer (talk) 18:27, 28 July 2026 (UTC)

Yes, PDF pages can be embedded that way, but, as I said, it is difficult and most editors do not know how to do this. As far as am aware, it is impossible via VisualEditor on Wikipedia, which is the default editing mode. Dominic (talk) 18:51, 28 July 2026 (UTC)

In precisely zero of the examples given, hosted for several years, each with hundreds or thousands of images of scanned pages extracted from each pdf, has anyone ever used any of the individual jpeg scans of pages.

In the above example of Category:A twentieth century history and biographical record of Laporte County, Indiana, the book is 1,272 pages long and Commons benefits from hosting all the text (and blank pages) in precisely one file, uploaded from the Internet Archive. All the images from the book are available in that category just in case anyone wants to refer to them individually, even though in the six years since the DPLA uploaded all 1,272 pages as separate jpegs not a single volunteer ever has. Only the text and blank pages have been deleted, because they never were of realistic educational value.

The claim about lossless conversion is irrelevant for Internet archive uploads as the original jpg2000 scans are available at the archive should anyone wish to losslessly convert them at maximum resolution to, say, PNG images rather than the apparent DPLA default of compressed jpegs. In practice doing so is fairly useless for text pages, or fairly grainy printed copper plate etchings, as once a jpeg version at, say, around 2000px or 3000px across and at 95% quality is in a PDF, they are perfectly usable on any project, and higher resolutions could only be usable for very high resolution drawing scans, or colour photograph prints, not a thousand pages of pure text.

Interestingly for the Laporte County records all of the images are in the above category as separate jpg files (uploaded by the DPLA but clearly in a compressed format), though re-extraction from the book if anyone wanted them separated is not hard (I see this all the time with volunteers using the standard croptool on uploaded large PDFs originals to create individual image pages with very little effort, thanks to its excellent design).

The assertion that the DPLA are synchronizing details does not hold water for a book edition from 1904 that will never change, and for which the DPLA uploads do not have a currently working source and appear to not be working on fixing broken sources, or even detecting the fact they don't work. Unlike the Internet Archive upload source, which is working fine, if anyone wants to check or access an original scan for free and no barriers to access, unlike the captcha checks that the DPLA link requires and get in the way of any automation by other volunteers.

PS. It is a puzzle as to why the DPLA appear to prefer uploading 1,000 page scans as compressed jpeg images, when on most of the source websites that are referenced, downloading the PDF version is available and would be trivially easy to synchronize. It's bizarre to make claims about millions of images, if a significant fraction of these are "unbundled" books. Given the couple of million large books in our volunteer run COM:IA books projects, it would be trivial to make that ten times the file count, but that feels like the opposite of an open knowledge benefit.

Fæ (talk) 19:31, 28 July 2026 (UTC)

Can you point me to an example of a book where we have page scans but no PDF? I'll take a stab at generating and uploading a PDF as a test case, with the intent of eventually automating the process. Omphalographer (talk) 20:00, 28 July 2026 (UTC)

It varies by source. An interesting one would be 0218f5acda05411627a5166b2477e083. The source has a download all option and these can be bundled into a PDF using a tool or a simple bit of python. Alternatively books like the Scottonian febcb2fbf478fb06e55759f627098e58 have been on the internet archive for years, in that case since 2011 at https://archive.org/details/scottonian1921tole and is available in various formats. However it's worth checking if the pdf is already here on Commons. In many DPLA cases of "unbundled" books, the whole PDF was already here and the project was just creating lots of unrecognized duplicates because there appears to be no checks for that. Fæ (talk) 20:12, 28 July 2026 (UTC)

By accident today I looked at File:St. Mary's Muse (August 1916-August 1917) - DPLA - 8b87c52efef9e02538eec9fdbf0c5ae9 (page 165).jpg, and it turns out that the "DPLA" source, by navigating via the DPLA branded website and passing the CAPTCHA (to ensure automation by us volunteers is impossible), is back to the internet archive! Checking the internet archive reference then showed these pages are taken from St. Mary's Muse (IA stmarysmuse19161917sain).pdf, a 390 page single document that was uploaded in 2020 as part of the unfunded COM:IA books project.

These single page scans and the arguments to keep them all hosted on Commons when we have the original books, is baffling. This feels counter to the mission of Wikimedia Commons, not just for free educational media but open and accessible to readers and without being locked in to "branding" of our free collections. Fæ (talk) 12:05, 29 July 2026 (UTC)

As far as VisualEditor is concerned, that sounds like it should be a feature request. That being said, as Fæ has noted, the overwhelming majority of these books and their pages are not used on any wiki page - I have a hard time getting too concerned about the possibility that it might become marginally more difficult for users to do something that they weren't doing in the first place. Omphalographer (talk) 20:11, 28 July 2026 (UTC)

BTW, while looking at examples, try the file history of File:George Washington's October 3, 1789, Thanksgiving Day Proclamation. - DPLA - 816c30bed65435e864fd1d28cd6d9b00.jpg. This was uploaded in 2018 from Flickr under a different filename.

Bot edits last month adding the branding and the long code, and changing the standard information template, deleting the Flickr link as the still working original source, to a DPLA specific "DPLA metadata" template, do not seem to help Commons in a practical way when the accurate records of this 2018 upload could have been left alone. Fæ (talk) 21:21, 28 July 2026 (UTC)

Community Wishlist entry for adding "depicted" statements to aerial images

I added a wishlist entry:

For a rectified aerial image, find objects likely to be shown and prompt to add 'depicts' statements

Please express your views on that page and/ or the linked Phabricator ticket. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:58, 28 July 2026 (UTC)

Wikimedia Commons content descriptor for "sexualized nudity" etc.

Recently, File:Fremont Solstice Parade 2007 - naked cyclists relax.jpg and File:Fremont Solstice Parade 2007 wall viewing.jpg (both of them photos I took) were tagged with Wikimedia Commons content descriptor (P14416) Sexualized nudity, erotica or ecchi (Q138829111). If these are considered "sexualized nudity" it is hard for me to imagine what photo involving nudity would not be considered "sexualized". If this is a correct us of Q138829111, then we should take the word "sexualized" out of the item name. - Jmabel ! talk 22:11, 28 July 2026 (UTC)

ATTN: User:Jerimee, who added the SDC statement in question. - Jmabel ! talk 22:13, 28 July 2026 (UTC)

I'm also concerned about lack of strict definitions for these properties (Which i suppose is partially my fault for making the user script). The slippery slope is real. (Edit: I wrote the previous before actually looking at the pictures. I'm not even sure this should count as nudity, let alone sexualized nudity) Bawolff (talk) 23:29, 28 July 2026 (UTC)

Would it be possible to use the filename to limit to certain filetypes (for example, excluding audio for which blurring does nothing)? Arlo James Barnes 04:01, 29 July 2026 (UTC)

Why would anyone mark an audio file as containing sexualized imagery?? Bawolff (talk) 04:34, 29 July 2026 (UTC)

I wouldn't rule it out. Consider, for instance, a (hypothetical) recording of a person reading an erotic novel. Just because it isn't visual media doesn't mean that tagging it isn't useful. Omphalographer (talk) 05:37, 29 July 2026 (UTC)

The label doesn't specify "imagery", and erotic/pornographic audio does exist. ReneeWrites (talk) 07:39, 29 July 2026 (UTC)

True, but my understanding is that the property was introduced to patch a sort of UX hole: that when you do a search on Commons, media are displayed including those that may be surprising; so it is good to have a method to blur potentially controversial images in such views, but then when the file page is opened it displays as normal. But an audio file would already have to be opened to access the contents, and hopefully the filename and description would be clear enough for controversial audio that anybody playing it knows what they are getting themselves into. Arlo James Barnes 06:59, 1 August 2026 (UTC)

I would agree with removing "sexualized" from the label, if we're going to apply this to any and all nudity anyway. Pinging @Trade: as they worked on the label on Wikidata. I also wonder about the inclusion of the word "ecchi", which broadens the scope to include softcore content such as pin-ups, which doesn't typically get censored. ReneeWrites (talk) 07:37, 29 July 2026 (UTC)

Just change it to “nudity”. There is no objective definition of erotica or ecchi, or what makes nudity “sexualized”, and nudity is NSFW no matter what the context is. Content descriptions should primarily be a utilitarian feature to prevent you from accidentally encountering explicit content in an inappropriate situation, not a warning that something might cause offense because of its lewd and lascivious intent or whatever. Dronebogus (talk) 09:27, 29 July 2026 (UTC)

Even if you narrow it down to "nudity" we still have lines to draw. Which of the following should be tagged?

Jmabel ! talk 19:24, 29 July 2026 (UTC)

And we've come up on the issue that I warned would happen - that there is such significant personal and cultural variation in subjective definitions, right down to what defines "nudity", that attempting to classify images as "NSFW" or "SFW" is inherently unworkable. Pi.1415926535 (talk) 19:49, 29 July 2026 (UTC)

This is one of the reasons I would actually prefer that the tag be restricted to clearly and intentionally sexualized content. Images on Commons don't exist in a vacuum; we can infer quite a bit of intent from the context that images originated from, and from the way they are described and categorized. Omphalographer (talk) 19:50, 29 July 2026 (UTC)

I would also prefer restricting the tag to intentionally sexualized content, or at least content likely to be construed as such (intent can be hard to work out). Offhand, I don't remember working anywhere that any of the 5 in my gallery above would have been problematic (though I suppose that in some of the workplaces a large blow-up of one over your desk might have been an issue). The same certainly applies to the "wall viewing" case in my original example; I could imagine the "naked cyclists relax" case being an issue, but simply for nudity (if you look closely, there is a partially visible penis, probably the most "taboo" body part in many Western cultures) than for anything about it being "sexualized." - Jmabel ! talk 21:37, 29 July 2026 (UTC)

The problem of having to draw arbitrary lines exists regardless. Whether we tag all nudity (sexualized or not), but don't tag erotic content with dressed-up subjects (such as fetish content), or we tag sexualized content, leaving alone non-sexualized nudity, but the question becomes if we want to include technically-SFW erotica such as pin-ups and ecchi. ReneeWrites (talk) 07:29, 30 July 2026 (UTC)

@ReneeWrites: I don't think any reasonable rule for this can draw clear line. Do you think it is clear which of the examples in the gallery I posted would be considered "nudity" (and, if so, which)? Because I think even that requires a judgement call. (The reason I say "reasonable rule" is that of course we could draw an unreasonable rule with a clear line, e.g. "no human flesh below the neck except hands" or such.) - Jmabel ! talk 17:34, 30 July 2026 (UTC)

@Jmabel: "I don't think any reasonable rule for this can draw clear line." - I agree with this, which is why I was against implementing this content descriptor when it was first discussed, and I would be in favor of phasing it out now that it's here. It doesn't appear to have been defined before it was created and put in use. As for your question: I think all the images in the gallery except the shoulder would qualify as "nudity", but none contain sexualized nudity. ReneeWrites (talk) 19:29, 30 July 2026 (UTC)

@ReneeWrites: sounds like we are basically in agreement about the difficulties.

Besides the difficulty: I can go either way on having a tag, but if it includes a lot of basically innocuous content, it becomes a liability. - Jmabel ! talk 21:22, 30 July 2026 (UTC)

Could the descriptor maybe be refined? Like: "sexual content", "sexually suggestive content including/excluding nudity", "nudity in sexual context", "nudity in non-sexual context", "nudity in art"...? And then people could choose for what degree of SFW they want to sign up by individually opting in/out on the above classifications? Nakonana (talk) 09:33, 2 August 2026 (UTC)

If we're defining "NSFW" as "US American PG13-friendly", then I'd guess that all the example images except for the shoulder photo would be NSFW. Facebook is operating with the PG13 standard and they are known to even censor nudity in ancient Greek and Roman statues. Nakonana (talk) 09:24, 2 August 2026 (UTC)

"a large blow-up of one over your desk might have been an issue" Is the desk in Kabul or Amsterdam? (rhetorical question; no answer expected). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:39, 1 August 2026 (UTC)

If you reread, I was writing about my own experience of workplaces. I have, for example, worked remotely with a team from Lahore, and I was certainly aware of what was behind me on Zoom calls. So not so far from your Kabul example, in that one case. - Jmabel ! talk 22:28, 1 August 2026 (UTC)

I personally disagree that all nudity is nsfw. I suppose different people having different views is part of why these discussions go in circles, but i do find it odd how it always seems like commons has 2 extremes: Those who dont want anything, no matter how extreme or disturbing, to be censored, and those who would censor stuff that wouldn't even get a PG rating at an anerican cinema. Bawolff (talk) 19:42, 29 July 2026 (UTC)

In this case, I don't think that a gadget or userscript which isn't turned on by default could be considered censorship. Prudery, perhaps, but if an individual has the capability to adjust their own experience of Commons, who is being harmed? Arlo James Barnes 20:55, 1 August 2026 (UTC)

The endless infighting is a potential harm. However i do think if people want a certain type of media hidden, but the gadget hides different media, that is a harm. I'm not opposed to a gadget (i wrote the gadget after all), but it should do what it says on the tin. Bawolff (talk) 21:15, 1 August 2026 (UTC)

I agree these don't seem sexualized to me. User:Infrogmation had a similar concern. I would prefer a more abstract value like "potentially NSFW." A more strictly accurate value like "toplessness" might work as well. I think Bawolff's script still works if the relevant property is set to "no value" but, that's not really semantically valid. I've been ill and haven't been able to review and respond. Jerimee (talk) 15:48, 2 August 2026 (UTC)

Editing metadata/deleting files?

Hi! I just noticed that there are my personal information in the metadata in some older files I uploaded. I would rather not have those information staying public. Is there a way to edit the metadata to erase those fields specifically, or is deleting the files the right way to go here? I believe none of those files are used on any Wiki projects. TurquoiseGoose (talk) 09:03, 29 July 2026 (UTC)

@TurquoiseGoose: The metadata fields can't be edited manually, you'd have to upload a new version of the file without the metadata to overwrite the old one. The old metadata will still exist on the previous version, but will no longer show up on the page. To remove the old version from public view entirely you can place the {{Bad data revdel}} template on the file to have it deleted. ReneeWrites (talk) 11:36, 29 July 2026 (UTC)

Who can help to categorise the 60,000 media as of 2023?

So far, we have reduced the files in Category:All media needing categories as of 2023 from 95,000 to 60,000. Now we need more volunteers please, to reduce this number to zero. Who can help categorising the rest manually by going through the files one by one? Or can you make a suggestion, please, on how to do this more effectively, based on the guidance in Commons:WikiProject Minimum One Category? — Preceding unsigned comment added by NearEMPTiness (talk • contribs) 07:18, 31 July 2026 (UTC)

Proposal: Moratorium on the deletion of photographs from Ukraine

I propose an immediate moratorium on the deletion of freely licensed photographs taken in Ukraine when the sole or principal reason for deletion is the absence of a Commons-compatible freedom of panorama exception under Ukrainian law.

This proposal is not based on the mistaken assumption that deletion permanently destroys a file. Deleted files can be restored through processes such as Commons:Undeletion requests, including when the copyright in the depicted work eventually expires.

The problem is that restoration may only become legally possible seventy years after the death of the architect, sculptor or other author, as described at Commons:Copyright rules by territory/Ukraine.

In many cases, the author is unknown, their date of death cannot be established, or they are still alive. The photograph may consequently remain unavailable for a century or longer.

By then, the people who knew the place may be dead, communities may have been displaced, the subject may have been destroyed, and the social and historical context required to understand the image may have disappeared. A file preserved invisibly in a deletion archive is not serving education, research, public memory or cultural preservation.

Restoring an image after the history surrounding it has been forgotten is not meaningful preservation. It is preservation after relevance.

ESO astronomy pictures

Hey everyone, I want to know why the site doesn't allow to upload images from ESO Flickr account like for example https://www.flickr.com/photos/esoastronomy/55321043227/in/dateposted/ Abdullah1099 (talk) 05:03, 2 August 2026 (UTC)

@Abdullah1099 sure you can. Don't know about terms on Flickr, but you can upload images from the official website providing that you will provide proper attribution (state source and author). See: https://www.eso.org/public/about-eso/privacy/ Nux (talk··dyskusja) 09:52, 2 August 2026 (UTC)

Pasted wrong link :), this has copyright info: https://www.eso.org/public/copyright/ Nux (talk··dyskusja) 09:53, 2 August 2026 (UTC)

@Nux bro, I know that Images can be uploaded from ESO Website but what about ESO Flickr account. Also i want can request VRTS for a Template:Copyrighted free use images Abdullah1099 (talk) 13:42, 2 August 2026 (UTC)

coz User:Hedwig in Washington blacklisted it special:diff/370891134. see Commons_talk:Questionable_Flickr_images/Archive_5#c-BevinKacon-2019-08-26T19:00:00.000Z-ESO_Account. RoyZuo (talk) 18:28, 2 August 2026 (UTC)

I don't think this Flickr account should be blacklisted. Is there any way to remove it from blacklist Abdullah1099 (talk) 01:41, 3 August 2026 (UTC)

@Abdullah1099 please be asolutely sure that the files are not already on Commons before trying to import ESO pictures from Flickr. My bot systematically import all pictures from their website in quasi real time so there is a huge probability that you will import a duplicate if you import files from their Flickr account. vip (talk) 07:34, 3 August 2026 (UTC)

I know that @Don-vip, I just want to know why it is not allowed as in theory Flickr can also be used as source for ESO images by there official ESO Flickr account Abdullah1099 (talk) 07:39, 3 August 2026 (UTC)

@Abdullah1099 just find the files you want to upload on the official site. Flickr has lower quality images as is shown with examples under the link posted by Roy. Nux (talk··dyskusja) 09:10, 3 August 2026 (UTC)

Yeah @Nux, Thanks i know that and i am kind of ok with it Abdullah1099 (talk) 09:14, 3 August 2026 (UTC)

Personality rights for children in PD US DoD photographs?

Looking at some mass uploads of DoD related photographs, and raising an album for possible out of scope duplicates, raises a secondary question I am unsure about and would welcome feedback, especially if a good consensus to refer to already exists!

The specific photograph is up for deletion, but the pdf of the album is not. Should we be concerned about photographs like this, which are not "historic" but within the last 30 years, are not outdoors or at obvious large public events but in this case might be at indoor gym training and where the subject would not have expected to give consent? Further the specific date and name of the photographer is not recorded, despite these being part of a military archive. There are other photos in this same album of younger people, ages probably about 2 to 6 years, where they could not possibly have consented or potentially understood they were being photographed and would later be published.

The related DR is here, please keep in mind that DR is on Scope grounds, not personality rights or copyright, and copies of all photos would remain on Commons, just the jpg duplicates are up for deletion not the pdf.

Note more generally, that in my own upload projects are a very large collection of DVIDs and DoD related photographs, I have no idea at this point how to identify which have detailed portraits of children, however the use of AI to help with subject identification and estimating age is making this possible for volunteers to work out and better retrospectively classify if this is a hosting problem for Commons. Fæ (talk) 14:16, 2 August 2026 (UTC)

In the example the subject looks at the camera. I would therefore assume that there was consent for publication. It is not something like a birthday party where the people might assume the photos to be used only within family and friends. GPSLeo (talk) 15:00, 2 August 2026 (UTC)

Given the age of these photos (I think they're substantially older than Fæ estimated), these children are probably in their 40s or 50s by now, if not older. Coupled with the fact that the photos will remain publicly accessible through DPLA / DVIDS, I wouldn't get too concerned about the personality rights issue. Omphalographer (talk) 15:57, 2 August 2026 (UTC)

The date at the source is given as "10/2/1994 - 1999". So the photographs in the album may be 27 to 32 years old^*. There's no estimation, these are the dates in the archive. I'll add a second image better to illustrate the younger models used. There issue is there cannot be consent at that age, further the archive has no record about consent or even a named photographer, despite this being recent enough to expect the models to still be living.

^*Recognizing some inconsistencies I'm doubting this analysis. Effectively these are like badly organized shoe boxes of holiday photos with years written on the label, however with so little information, like a named photographer or specific dates, there seems reason to distrust even these date ranges. If we are going to make assumptions about personality rights or similar, all the information needs to be taken as effectively absent. --Fæ (talk) 16:40, 2 August 2026 (UTC)

But they are definitely government works and therefore public domain? If they are that bad organized my main concern would be that DPLA does not have the rights to publish these files as public domain. GPSLeo (talk) 17:23, 2 August 2026 (UTC)

Keep in mind that on a military base, especially before the ramp-up of contractors in the 2000s, just about everyone likely to be around with a camera is a government employee. - Jmabel ! talk 00:58, 3 August 2026 (UTC)

This particular album has family accommodation, family events and portraits of families with children. There is no information on the archive record for who took these photographs, it could easily have been someone living on the base who was not a government employee but married to one. It is another assumption that the photographs were taken by the same person, given the unreliability of the dates which is the only consistent bit of information, but even that has been shown to be wrong. Fæ (talk) 06:12, 3 August 2026 (UTC)

Personality rights in the U.S. are very limited. Mostly, they have to do with not implying an endorsement of a product or company; some states have rules against certain kinds of deepfakes, but there is nothing at a federal level. As long as we are not talking about CSAM (and clearly in these examples we are not), I'm not aware of anything that makes a legal distinction for photographs of people who are underage, so unless someone's got something they can point to, any issue of this sort would be one of Commons policy, not one based in personality rights. - Jmabel ! talk 00:52, 3 August 2026 (UTC)

I thought Commons:Personality rights was a useful reference and does not limit Commons to only being concerned about extremes like CSAM. The statement "A child or a person judged incompetent by a court of competent jurisdiction should be considered with even greater care, as they probably cannot give valid consent even if they appear to." is relevant and is clearly how organizations like NSPCC define these situations, refer to the section on consent at https://learning.nspcc.org.uk/online-safety/photographing-filming-children. These photos may have been taken 30 to 50 years ago, but these same considerations apply if the sources we are harvesting have no records about consent, or who took the photograph, or the date, or the context. Everything being assumed is just that, assumptions in the absence of facts, which is not a good basis for judging if there has been appropriate consent from a child. Fæ (talk) 06:08, 3 August 2026 (UTC)

If the photo had first been posted by a random person, I might share the concern about consent, but presumably the DoD made such evaluations before posting. - Jmabel ! talk 00:56, 3 August 2026 (UTC)

@Jmabel: with Personality rights in the U.S. are very limited, you're certainly right, but only for scenes shot in the US, no? It's funny that this issue about personality rights came up again, as I opened Commons:Deletion requests/Files in Category:2 girls in Japan which includes File:Navy Misawa sailors participate in Career Day 140328-N-DP652-002.jpg and File:Brought together through music 130420-M-PZ610-505.jpg. Both are DoD images from a foreign base used by the US. I harbour the apprehension that US military photographers may operate only with US laws in mind, not regulations from abroad. Regards, Grand-Duc (talk) 07:04, 3 August 2026 (UTC)