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)

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)

Agreed completely. The presence of a date and a location should not be sufficient to consider a file "categorized" - those categories tell us nothing about what is actually in a photo or how it could be used. Omphalographer (talk) 23:00, 7 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)

i didnt pay attention to how you implemented this. i thought your module got the results directly from the whole database somehow, but actually from lists you generated. but with such long lists and only less than 0.1% of a list gets shown on the pages, i dont think it's urgent or necessary to keep updating the lists frequently. even an annual update is enough. RoyZuo (talk) 15:03, 4 August 2026 (UTC)

i'm curious how you generated the video list. many of them are not "featured media" or motd. how did you find these files of good quality? RoyZuo (talk) 17:16, 4 August 2026 (UTC)

There wasn't enough featured media, so i added in any video that is in use on a wikimedia wiki (excluding meta, outreach, wikimania, mediawiki.org or a chapter wiki) Bawolff (talk) 17:48, 4 August 2026 (UTC)

no objection to Bawolff's Commons:Explore pages so far. i think an edit request to the main page template can be submitted. RoyZuo (talk) 07:41, 11 August 2026 (UTC)

i'm in favor. Lets at least try it ! —TheDJ (talk • contribs) 07:51, 11 August 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)

I think that COM:REDUNDANT deletion policy should be more precise. The detailed policy is based on a talk page (Commons talk:Superseded images policy), and I believe this makes things too subjective. When a file is deleted, it should be because it can't be hosted in Commons. A file being available in other file format does not make it unsuitable for Commons. For example, if a file is uploaded tomorrow, and it is redundant to a file that has been here for a time, this is a redundant file whose deletion is unlikely to cause any harm. But if a file has been here for years, and a new, identical file with higher quality is uploaded, then the older file would become the less preferred option for that image, it can be clearly labeled as redundant, lower quality, even obsolete and not recommended to be used, but it should never be deleted because of this. Maybe its uploader took a lot of care in specifying where it came from, or even had its license reviewed, and maybe the new file is the opposite case, and is at risk of eventually being wrongfully deleted. Also, it's possible that the old file was in use in a Wikipedia article for years, and then, users browsing the history of that article can't see a good image, with a valid license, that was part of those past versions of the article.

Fortunately, I believe that the basic ideas behind the current COM:REDUNDANT policy are in line with these thoughts, and they are being applied in such way, it's only that they are not expressed in writing. Generally, I think that Commons should have a written policy stating the goal of not deleting any files whose presence makes no harm. For example, a very low quality photo of a species of bird (for which we already have far better images), if uploaded tomorrow, it must be deleted as out of scope (there is a good reason for it: to prevent Commons from being flooded with very low quality images that don't add anything useful; the deletion of the recently uploaded, bad quality image is highly unlikely to cause any harm). But if that very same image was uploaded in 2004, it should just be tagged as obsolete with a template. Perhaps that image was in use in a Wikipedia article for 20 years, and by deleting it we make the Wikimedia ecosystem worse, not better: by deleting it, we are destroying a part of our own history, without any need to do it, and it's completely senseless. MGeog2022 (talk) 19:19, 8 August 2026 (UTC)

These examples are different to the mostly pure text we are concerned about. The unbundled books being uploaded as single unconnected scans of pages by the DPLA are not in use, nor have been proven to be useful compared to cropping out images, maps etc. from the original book. Books get uploaded in PDF for good reasons of readability, access and reusability. Fæ (talk) 06:29, 9 August 2026 (UTC)

@Fæ, yes, this would be a case where the deletion would be justified: to avoid lots of new redundant files that wouldn't add anything useful, unless a specific page is needed to be used in a Wikipedia article or the like. My thought about this is similar for Wikipedia articles: I think the so-called deletionism is really terrible (unless the article was created for self-promotion or the like). I understand that not everything is notable, and that some new articles need to be rejected, based on consensus. I would say that I am not an inclusionist, while being an anti-deletionist: I'm only a "rejectionist", and I have the same view for out of scope or redundant files in Commons: reject new files that aren't needed, but don't delete history. MGeog2022 (talk) 11:01, 9 August 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)

but metadata is useful for it's own sake, right? Jerimee (talk) 18:32, 4 August 2026 (UTC)

In theory, but most of the useful work done on wikis is motivated by a particular use case. Arlo James Barnes 19:50, 8 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)

@Nakonana: I like that idea. I think a system of tiers (graphic/sensitive/mild content) or toggles (nudity, sexually suggestive content, gore, violence) would be an improvement. Right now it seems to be either/or: something is too risqué for public view or it's not. ReneeWrites (talk) 07:29, 6 August 2026 (UTC)

Having different categories of reasons to blur seems good, for example some people prefer not to look at photos of people who have died, which could be infer-able from depicts statements. Arlo James Barnes 19:45, 7 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)

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) This, sadly, is how I came to have mis-assigned Wikimedia Commons content descriptor (P14416)→Sexualized nudity, erotica or ecchi (Q138829111) to Jmabel's not sexualized and rather SFW (in my opinion) examples. I added the statement to all files in Category:Topless_sitting_women. I read what Pi.1415926535 wrote about concerns that those with power wish to designate as "inappropriate" to further their own aims and I'm yet to be convinced. Their point about it being difficult to implement at scale is well taken, and I have to agree there is no universal definition of NSFW. It seems a bit early to write the whole thing off as censorship classification; there are presently only 3,400 files with any value at all for Wikimedia Commons content descriptor (P14416). Here is a link to the property proposal; I don't see that anyone has posted it yet. Jerimee (talk) 18:30, 4 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)

We should just have multiple items: one for "general nudity", one for "partial nudity" and one for "sexualized nudity". GPSLeo (talk) 18:44, 4 August 2026 (UTC)

Gentle reminder: not all nudity is sexual; not all sexuality involves getting naked. Content descriptors are intended to represent broad categories of objectionable content (such as sexually explicit content), not just degrees of nudity. Omphalographer (talk) 07:33, 5 August 2026 (UTC)

well taken, but the content is *not* necessarily objectionable, merely sensitive Jerimee (talk) 18:42, 5 August 2026 (UTC)

@Jerimee: I don't understand that last remark, is there a negative missing somewhere? Depending where it is placed, you could mean to opposite things: "not necessarily objectionable, merely sensitive" or "necessarily objectionable, not merely sensitive". Since it's not clear what content you are referring to, it's hard to guess. - Jmabel ! talk 23:42, 5 August 2026 (UTC)

yup *not* necessarily Jerimee (talk) 01:28, 6 August 2026 (UTC)

I think that there needs to be considerable standardization of content descriptors. Unfortunately there aren't any websites that offer a "controlled vocabulary" of sorts for content descriptors (meaning, there aren't external links that connect "depictions of nudity" content descriptors between film ratings and video game ratings, for example). I think that looking at existing content descriptors for other websites, and then making Commons content descriptors based on what they have in common, might be a better approach than arbitrarily creating content descriptors that may have vague meanings. ForeverFlying (talk) 21:59, 4 August 2026 (UTC)

oh I didnt think of that; I bet there is a librarian or library system that does have some kind of practical rubric. Maybe NYPL? At the very least one would expect libraries to be well versed in balancing the needs of children with a commitment to free speech. Jerimee (talk) 22:53, 4 August 2026 (UTC)

There's the film ratings board properties, perhaps something could be cobbled together from that; but they'd only directly apply to movie files hosted at Commons. Arlo James Barnes 19:43, 7 August 2026 (UTC)

Which country's (or countries') ratings would you apply? Or would it be all of them? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:06, 7 August 2026 (UTC)

For a given film file, it would have a relevant board that reviewed it (or didn't, in the case of NR-type 'ratings'). See ShakespeareFan00's comment at Wikidata. In general, I don't think it would be feasible to have groupings like 'board W gave it X rating but board Y gave it Z rating'. Arlo James Barnes 19:39, 8 August 2026 (UTC)

in my opinion, which definitions don't matter so much as the need to just pick a definition and go from there. Bawolff (talk) 19:54, 8 August 2026 (UTC)

That's not how film rating works; each country has their own board. Very few films are only released in one country. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:03, 8 August 2026 (UTC)

In my opinion I think that looking at the current content descriptors for other rating systems, and creating our own criteria based on commonalities between them, would be at least a more comprehensive approach. ForeverFlying (talk) 06:32, 10 August 2026 (UTC)

And moreover, those film ratings are highly subjective, and often focus on factors which are completely irrelevant to Commons like the use of vulgar language, drugs, or alcohol. I don't think there's anything useful to us there. Omphalographer (talk) 18:04, 10 August 2026 (UTC)

Bad action by "Túrelio"

• Cold_District_heating,_schematic_function.svg&action=history
• Cold_District_heating,_schematic_function.svg&action=log
• de.wikipedia
• other file: page=File:Italy_1864_ca.svg&action=log

Taylor 49 (talk) 22:14, 5 August 2026 (UTC)

@Taylor 49: You are going to have to spell out what was "bad" here. I only looked at the first of four items in your list, but it seems reasonable. When a file is deleted as a duplicate, it is perfectly normal to redirect it to the file it duplicated. If that is not the reason for deletion, then the deletion log is misleading. - Jmabel ! talk 23:53, 5 August 2026 (UTC)

It seems unlikely that these SVGs (at least one of which was in use) were actually duplicates of the test SVG. Omphalographer (talk) 00:51, 6 August 2026 (UTC)

Ah, indeed. Looks like an error on Túrelio's part. You really could just have contacted him rather than bring it here, or at least pinged him, but Pinging @Túrelio, you probably want to look into this. - Jmabel ! talk 04:20, 6 August 2026 (UTC)

@User:Jmabel Sure: "Túrelio" deleted at least two files that were both INUSE and INSCOPE, apparently even without any discussion. There should not be any redirects to garbage File:Test.svg. Claiming that something is dupe of File:Test.svg is nonsense. Taylor 49 (talk) 01:08, 7 August 2026 (UTC)

@Taylor 49, why didn't you notify me directly on my talkpage?

Anyway, I've restored File:Cold District heating, schematic function.svg in order to be able to understand what happened back then (deletion was on May 10th!). As you can see from the version-history, the file had been tagged by OptimusPrimeBot as a duplicate of File:Test.svg, which was technically accurate at this time (Test.svg from May 9, 2026: ). My fault seems to be that I didn't check whether the Bot-edit/tagging made sense. Sorry for that.

Now for File:Italy 1864 ca.svg. That file had been tagged by its creator, User:Manlleus, for speedy deletion on december 23, 2024, which I then performed on december 24, 2024.

Generally, FYI: files may be tagged as duplicate of an existing file by the system (MediaWiki) itself, by OptimusPrimeBot (and other Bots) or manually. Duplicate is a speedy-deletion rationale (F8) and does not require discussion. However, as of recently it seems that these Bots sometimes duplicate-tag files which aren't actually duplicates, but that is different issue than the one discussed here.--Túrelio (talk) 07:19, 7 August 2026 (UTC)

The problem is fixed now.

> been tagged by OptimusPrimeBot as a duplicate of "File:Test.svg", which was technically accurate at this time

YES but duplicates of "Test.*" obviously should be excluded from the process. And maybe there should be a harder policy against using "Test.*" in serious wiki pages.

> file had been tagged by its creator, User:Manlleus

Well then the deletion was justified, but not the redirect to "File:Test.svg".

Taylor 49 (talk) 10:34, 7 August 2026 (UTC)

Photo challenge June 2026 results

Bokeh: Entries • Votes • Scores

Rank	image	Title	Author	Score
#1		Domestic pigeon	NBlart23	11
#2		Gruppo di funghi della specie Mycena renati su un ceppo di faggio, in un bosco misto nell'area di Sorano (Toscana)	Albarubescens	8
#3		Greater Flamingo in the evening golden hours of Pulicat,Tamil Nadu	BKadhiravan	7

Street foods: Entries • Votes • Scores

Rank	image	Title	Author	Score
#1		Two men order from a falafel truck during a heavy snowstorm in New York City	Sashimi-b	15
#2		This is a delicious job!	Maryam Yazdanisheldareh	11
#3		Sweetfish skewers being grilled and sold in Ueno Park, Tokyo, Japan.	Ka23 13	8

Congratulations to @NBlart23, @Albarubescens, @BKadhiravan, @Sashimi-b, @Maryam Yazdanisheldareh and @Ka23 13. Sekidoki (aka Taiwania Justo) is speaking (Reception Room) 11:19, 8 August 2026 (UTC)

Using Commons as a cloud service

Hi!

I have discovered thousands of photos uploaded by a cretain user that I really think is totally out of COM:SCOPE. Selfies, the user's house, garden, car. Photos from holiday trips, tomb stones of most likely relatives, etc. etc. To me it looks like some sort of personal "cloud storage", which directly violates COM:HOST. The vast majority of the files are not used anywhere within the Wikimedia system.

What's the next step? Is there a way to list all the unused files, or the opposite, list all the used files? With somewhere between 5500 and 6000 photos, it will take forever to check all of them manually, if they're used or not. Not to mention individually delete request all of them, except the few of them that might be in use.

As of now, I'm not "outing" the username, so try to answer in general terms.

Regards, 1000mm (talk) 14:10, 8 August 2026 (UTC)

PS! If this post is misplaced and should be at COM:HD, feel free to move it, or let me know and I'll post it there instead. Thanks! 1000mm (talk) 14:12, 8 August 2026 (UTC)

@1000mm: You can use a combination of Special:ListFiles for the relevant user and COM:VFC. When you're beginning a batch editing process (the default for me being a DR), you'll see a white question mark on the right below the loaded thumbnails. Click on one of these, and you'll see the number of uses on projects. A zero on grey indicates that (zero uses on projects) any number higher will bei white-on-red and show that the file is used. It doesn't filter between user pages and pages "relevant" for COM:INUSE, as far as I'm aware, though. And the check doesn't survive the loading of more thumbnails in VFC, so you've to load the amount of images you want to process before doing the check. Regards, Grand-Duc (talk) 14:49, 8 August 2026 (UTC)

@Grand-Duc, what an awesome tool!! Thanks a lot.

After a quick check, there's 5741 photos, and ~150 are in use. I have naturally not checked if any of all the unused ones are "relevant". Some are probably, but some of the ~150 are also "irrelevant" or redundant. A gallery wtih 55 photos of a marina in a small Norwegian town, for instance. My browser allowed me to scroll and list all 5741, but a thumbnail didn't load on nearly all of them, so to create deletion request with a bulk of images would need to do segments based on date, I guess.

In addition, I found that the same person have used at least one other username, with 2000+ uploads. Not checked those with the VisualFileChange tool, but the type of photos are very much the same. 😖

1000mm (talk) 15:45, 8 August 2026 (UTC)

@1000mm: Could you disclose the username, now? Such an amount of media and accounts may warrant a review by several people. That's IMHO not snitching, but asking for curating assistance. Regards, Grand-Duc (talk) 16:33, 8 August 2026 (UTC)

Sure. The user I was initially talking about: Special:ListFiles/Ranværing. Six out of seven of the gallery photos in no:Mo i Rana havn is uploaded by Ranværing. However, all seven of them have "Magne Aga" as byline, and the last photo is uploaded by Special:ListFiles/Sandivas. 1000mm (talk) 16:51, 8 August 2026 (UTC)

For what it's worth: VFC does attempt to ignore uses of images in user pages, sandboxes, and drafts. Omphalographer (talk) 16:51, 8 August 2026 (UTC)

Oh, I wasn't aware of that, Omphalographer, thanks, good to know!

And my opinion about the Norwegian images: the external views of cottages, streets, nature, even if not really spectacular by themselves (example), are quite certainly in scope (near the lower threshold for acceptability, sure, but still well within and not straddling the limits). It's similar to Streetview imagery; I got the feel that a Wikimedian endeavoured to provide a more or less complete coverage of a (part of a) municipality at a given date. This is a legitimate ground for providing photos via Commons. The interior shots, on the other hand, are more of a SCOPE issue (-> COM:PERSONAL), and I spotted 4 copyvios too (the calendars with animal photos on them). Regards, Grand-Duc (talk) 17:46, 8 August 2026 (UTC)

I've scrolled through a couple hundred images, and almost everything I've seen are high-quality images which are absolutely in scope, maybe a handful or so which aren't. Most are geotagged & properly categorized too. ~TheImaCow (talk) 17:46, 8 August 2026 (UTC)

i see no reason to delete, especially when the files cover topics about which people rarely upload (e.g. inside their homes) in remote places. i once proposed Commons:Photo challenge/2025 - August - Home interiors but commons still doesnt have enough files on such topics. RoyZuo (talk) 18:10, 8 August 2026 (UTC)

To be honest, I find a bit surprising that you seem to take it so lightly. Yes, of course there are a lot of these images that could be used, but my oh my, there are many that are really of no good use, or simply garbage.

To name a few of the type of photos:

• several images of the same tree in his garden
• several images of his car, often the same angle and location
• several images of a table on the balcony, with different amount of snow
• quite a few images taken late in the evening or at night, that are nearly pitch black
• multiple images of the same couple of gravestones, from various perspectives and at different seasons
• random people appearing in photos, etc. etc.

Obviously uploading everything, or at least a lot, from the camera roll, i.e. using Commons as a cloud service.

COM:HOST: "Although we do host media and images on Wikimedia Commons, all content must be within our project's scope, which requires, among other things, that all media must be realistically useful for an educational purpose. Unless your images areeducationally useful and in the scope of this project, Wikimedia Commons is not a place to store personal photos or files." many of these really aren’t. A couple of examples:

• File:Overlege Wingesvei 4A balkong 20240621 013508.jpg
• File:AMORC 20140906 IMAG0417.jpg
• File:Overlege Wingesvei 4A balkong 20221015 104342.jpg
• File:Overlege Wingesvei 4A hage 20150522 IMAG0455.jpg
• File:Selforssjøen_bru_20200501_111011.jpg

Where’s the realistically usefulness for an educational purpose here? 1000mm (talk) 19:44, 8 August 2026 (UTC)

@1000mm Did you already ask the user about the purpose? We can only guess, an answer by the uploader might be more useful --PantheraLeo1359531 😺 (talk) 19:48, 8 August 2026 (UTC)

File:Selforssjøen_bru_20200501_111011.jpg looks useful (although the accidental finger is not optimal), but would need geocoordinates --PantheraLeo1359531 😺 (talk) 19:49, 8 August 2026 (UTC)

That one was included because of the finger partially covering the lens, yes. 1000mm (talk) 19:50, 8 August 2026 (UTC)

I geotagged it, now someone has to cut off the finger. Ymblanter (talk) 20:01, 8 August 2026 (UTC)

I used the tool with the scissors in the icon :P Arlo James Barnes 20:08, 8 August 2026 (UTC)

@Ymblanter: that sounds painful. - Jmabel ! talk 22:38, 8 August 2026 (UTC)

Some of the photos aren't really in scope, but honestly, it does seem like the guy is actually trying to upload things that would be useful, evidence by the uploading of the occasional photo that is not his which is under Creative Commons and is properly sourced. But either way, I can see the frustration with some of the images. I think some of them are fine to delete, kindly, by explaining that they are out of scope but that the other images are appreciated. Aplucas0703 (talk) 16:49, 11 August 2026 (UTC)

As an aside - if anyone is up for a large categorization/weeding process, Special:Uploads/Sony 19th has nearly 30,000 largely uncategorized photos, mostly of streets and outdoor areas in the Los Angeles area. There are probably some useful photos of notable buildings in there which should be better categorized; there's also a lot of completely unremarkable and/or low quality images which are unlikely to be of any use. Some assistance would be appreciated. :) Omphalographer (talk) 21:03, 11 August 2026 (UTC)

Results of Wiki Loves Folklore 2026 are out!

Greetings! We are thrilled to announce that the winners of Wiki Loves Folklore 2026 have been selected! We are so excited to share these breathtaking images of cultural heritage with you. Thanks to our vibrant global community, this year's campaign was a monumental success: 100,343 media uploaded to Commons 128 countries participated 1,754 passionate uploaders Click here to explore the 2026 Winning Media A massive thank you to all the photographers, jurors, local organizers, and cultural documentarians who helped make Wiki Loves Folklore 2026 a worldwide phenomenon. Your dedication ensures that local traditions and folklore are preserved and shared under free licenses for generations to come. We hope you'll join us again and continue contributing to the campaign next year! Warm regards, Wiki Loves Folklore International Team

--✝iѵɛɳ२२४०^{†ลℓк †๏ мэ} 14:22, 9 August 2026 (UTC)

Edit summary reminder

When editing a page on Commons there is a small field labeled "Edit Summary" or "Summary" under the main edit-box. It looks like this:

Edit summary: 

 

The text written here will appear on the Recent changes page, in the page revision history, on the diff page, and in the watchlists of users who are watching that article. See m:Help:Edit summary for full information on this feature.

Filling in the Edit Summary field greatly helps your fellow contributors in understanding what you changed, so please always fill in the Edit Summary field. If you are adding a section, please do not just keep the previous section's name in the Edit Summary field - please fill in your new section's name instead. Thank you.

This is a repeat on this topic from 2007, and earlier. It would seem that ever increasing, numbers of edits are being made without the courtesy of filling in the Edit summary: field. Is it so hard or unnecessary to show some courtesy here? It's hardly a major task? Why have the field without using it? Chrome amongst others actually can assist with it, so hardly a chore. - Broichmore (talk) 06:32, 11 August 2026 (UTC)

There is also option Prompt me when entering a blank edit summary (or the default undo summary) in Special:Preferences#mw-prefsection-editing. EugeneZelenko (talk) 15:10, 11 August 2026 (UTC)

Is it actually useful to use an edit summary like "new section" when that is already obviously implicit in the edit itself, and it adds nothing more than what is already obvious from the edit?

Edit summaries are useful for content space edits, when their function can't be explained by adding more text to the edit (we don't inline commentary) and the reason for an otherwise unclear edit can be added through them. But this is a talk: space. What needs to be covered in an edit summary here that can't just be included in the edit itself? Andy Dingley (talk) 19:47, 11 August 2026 (UTC)

Edit summaries are really useful when looking through page history to work out when something happened and who was responsible. Also, when looking through a user's contributions, they can really help to understand what sort of work that user does here. Also, on less experienced but clearly well-intentioned editors, they are often a really good clue which of their edits I'd want to check. (Not so much for the ill-intentioned, whose summaries are likely to be lies.) Less importantly, they are also sometimes a timesaver when going through the changes on a big watchlist. Consistently good editor said they just refined a category, or are reverting vandalism? I often don't even need to click through. - Jmabel ! talk 22:41, 11 August 2026 (UTC)

'The Gazette' - Wikimedian in Residence

From today, I am Wikimedian in Residence at The Gazette (aka The London Gazette).

Please see en:Wikipedia:GLAM/The Gazette for details, and let me know if you have any suggestions or requests. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:13, 11 August 2026 (UTC)

I wonder if the gazette publishes any images... probably not. – Howardcorn33 (💬) 17:18, 11 August 2026 (UTC)

Seems like it does. For anyone with w:WP:TWL, https://newspaperarchive.com/london-gazette-feb-01-1913-p-1 seems to be the most recent page in that particular archive, and https://thegazette.co.uk/London/issue/60017/page/1 at the main site? — Arlo James Barnes 18:29, 11 August 2026 (UTC)

What's the TWL URL for your 1913 link, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:39, 12 August 2026 (UTC)

Do you mean https://access-newspaperarchive-com.wikipedialibrary.idm.oclc.org/gb/middlesex/london/london-gazette/1913/02-01 or a different URL? I see it is labelled 'The Middlesex Gazette, a weekly constitutional journal' so perhaps it is misfiled in the archives of the daily London Gazette. — Arlo James Barnes 14:47, 12 August 2026 (UTC)

That's certainly not the Gazette in question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:07, 12 August 2026 (UTC)

I haven't seen any photographs, but am in the process of confirming.

Of course, each page scan is published as an image. We have a few in Category:The London Gazette and yesterday I created Category:Edinburgh Gazette and, just now, Category:Belfast Gazette, and uploaded sample images for each. I don't plan a bulk import, though. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:45, 12 August 2026 (UTC)

Update: The Gazette team tell me the only other images they're aware of are royal coats of arms, one postage stamp (date of publication not recalled), and this simple diagram of a coffin which was used a few times. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:19, 12 August 2026 (UTC)

Public domain photo of Robert Johnson

I believe I have ascertained the first truly public domain photo of the legendary musician Robert Johnson. It is a 1937-1938 self-portrait in a photo booth that was never published until 2020. I have uploaded two copies, one is the highest quality scan I could find of the book cover (cropped to remove the letters), and the second is what I believe is the initial physical print of the photo.

The former is high quality, but is somewhat awkwardly cropped to eliminate the book title. The latter is the uncropped photo but is low quality. If anyone can find a HQ scan of the photo without the lettering, I would be thankful. – Howardcorn33 (💬) 22:31, 11 August 2026 (UTC)

Removing women from categories

Hello, I noticed that Mary Louisa Gow was moved from Category:Painters from England to Category:Female painters from England. https://commons.wikimedia.org/w/index.php?title=Category:Mary_Louisa_Gow&diff=prev&oldid=420189141 Is this correct? There have been some other women moved the same way, at least one a politician. I am seeing that https://commons.wikimedia.org/wiki/Category:Zohran_Mamdani_in_2025 is in a "politicians" type category and not in a "male politicians" category or "Asian politicians" category. I don't see any help files about this. Thank you. Caffeinated Chihuahua (talk) 02:10, 13 August 2026 (UTC)

I've brought up this "ghettoization" issue about once a year, but it seems the splitters always win. I continue to believe that either (1) we should hand gender as orthogonal to other categorization, intersecting only where gender is very significant (vocalists, actors, sportspeople, maybe a handful of other areas) or that we should make an exception to COM:OVERCAT where subcat'ing by gender (and probably by ethnicity) should not remove something from the parent cat. - Jmabel ! talk 02:40, 13 August 2026 (UTC)

In my opinion, w:en:WP:ALLINCLUDED seems like it would be a reasonable model to adopt on Commons, particularly the bit about how [s]ubcategories defined by gender, ethnicity, religion, and sexuality should almost always be non-diffusing subcategories. Simple user utility would seem to favor this outcome, even if the issue of othering/ghettoization were not also present. -- Visviva (talk) 21:23, 13 August 2026 (UTC)

Agreed with both the above comments. In the short term, making gender, ethnicity, religion, and sexuality non-diffusing seems incredibly logical - it will never be possible to fully diffuse by these, especially because they aren't always disclosed by the subject. (Gender, religion, and sexuality can also change over time.) Pi.1415926535 (talk) 22:11, 13 August 2026 (UTC)

Janwikifoto, Daniel Aufgang

This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 06:29, 14 August 2026 (UTC)

I'm not at all sure this is the best place to ask this, but I can't think where else.

I happen to have run across File:P b b9dn631 0751.jpg, uploaded as "own work" by User:Janwikifoto, who stopped editing a few years ago for unknown reasons. In this edit, User:Photo Archives (later blocked as a sockpuppet, but someone the majority of whose edits seem to have been good), placed this in Category:Photography by Daniel Aufgang, a widely-traveled Flickr user. I would guess that this was simply a mistake, that Janwikifoto and Daniel Aufgang are two completely different people, and the category should be removed. Does anyone else know more? FWIW, User:Janwikifoto is a "verified account". - Jmabel ! talk 02:48, 13 August 2026 (UTC)

The caption 'blah blah blah for automated' suggests Janwikifoto was using automation to upload the photos; is it possible that the source was a Flickr post? Arlo James Barnes 18:04, 13 August 2026 (UTC)

@Jmabel: They're different people. Daniel Aufgang is Canadian, Janwikifoto is Swedish. I noticed a few more files in the category added by Photo Archives, such as File:P (252448165).jpeg which is credited to Tomasz Tom. So there are probably more photos miscategorized. I will take a more thorough look at this later. ReneeWrites (talk) 18:21, 13 August 2026 (UTC)

@ReneeWrites: thanks! Does this mean you plan to follow this up and I can let go of it? - Jmabel ! talk 19:32, 13 August 2026 (UTC)

@Jmabel: Yes! I had some errands to run, but I'm back now. ReneeWrites (talk) 20:23, 13 August 2026 (UTC)

@ReneeWrites: so you will be removing this category where it is wrong? - Jmabel ! talk 20:42, 13 August 2026 (UTC)

@Jmabel:  Done --ReneeWrites (talk) 21:04, 13 August 2026 (UTC)

A script for describing a batch before it finishes uploading

I put together a user script for uploads of a few hundred files at a time. The Upload Wizard sends every file to the stash before it opens the Describe step, so with a big batch you end up watching a progress bar before you can type anything, and if something goes wrong halfway you can lose the session.

This one works the other way round. You pick the files, you write descriptions, categories and licence straight away, and a queue uploads each file and publishes it as soon as its own metadata is ready. What you typed is kept in the browser database, so a reload or a dropped connection does not lose it. You can also tick a group of files and copy one file's metadata onto all of them. It uses the same category autocomplete widget the Upload Wizard uses, so that part should feel familiar.

There is a button under "Select media files to share" on Special:UploadWizard, and a link in the toolbox on other pages. Code and documentation are at User:Wilfredor/commons-batch-uploader.

It is new and lightly tested, so I would rather hear now about anything that breaks. Wilfredor (talk) 11:47, 13 August 2026 (UTC)

For context, this was reported in 2012 as phab:T39462, "Allow providing image information (categories/description) while still uploading". Fourteen years later it is still open, and still filed as low priority. That a need this basic has gone unaddressed for so long is frankly difficult to understand, and it is fair to ask what priority it has actually had. I stopped waiting and wrote the script above. Wilfredor (talk) 11:54, 13 August 2026 (UTC)

How to categorize 45,000 media needing categories as of 2023?

How to categorize 45,000 media needing categories as of 2023 most efficiently? I think that more volunteers will be required, because it is unlikely that this can be done automatically. Most low hanging fruit such as sunsets, beaches, diagrams, charts and maps have already been categorized, and now we need your expertise, please, to allocate the most appropriate categories to these files. Could you help, please, or at least leave a comment, please, how to tackle this task more efficiently? --NearEMPTiness (talk) 05:23, 14 August 2026 (UTC)

Why would you expect this to be significantly different than the prior years, which have been done reasonably successfully? As far as I can tell, the rate of progress has been about the same here. - Jmabel ! talk 06:05, 14 August 2026 (UTC)

I have a feeling that more and more uncategorized media are being uploaded each year, and that more volunteers and/or more efficient procedures are required, to tackle the backlog. Putting some files in a temporary category, such as category:unidentified men might be a solution, hoping that someone, who is interersted in identifying them, can do this more easily that by scrolling to 45,000 files showing all sorts of media. --NearEMPTiness (talk) 06:47, 14 August 2026 (UTC)

We need to improve categorization at, or immediately after, upload time. The tools are the same as I remember them for the last twenty years! How have we had so little progress here?

We need a strong incentive to categorize. Such as speedy deletion of uploaded and uncategorized content a day after upload, with massive warnings at upload time. Will we really lose anything? Obviously that can only work if categorization is at least vaguely useful, so this should also be incentivised to reduce mis-categorization. Dumping new content into 'objects', 'people', 'landscapes' ('influencers' and 'digital creators' too?) or any category that's already over-populated should likewise generate strong warnings.

WMF clearly have no interest in any technical support to do any of this. Andy Dingley (talk) 10:43, 14 August 2026 (UTC)

I remember proposing making category field compulsory when uploading a file, maybe one year ago or so. The proposal received mostly negative votes, with voters arguing that miscategorized files were a bigger problem than uncategorized ones. I agree that people who don't categorize their uploads are highly likely to miscategorize them, if categorization is compulsory. But maybe miscategorization is not such a big problem, in the sense that miscategorized files are easily detected when looking at a category, and they are few at each individual category. This is a complex issue and I don't have a clear viewpoint.

There is also the possibility that, for all files that are currently uploaded uncategorized, maybe a relatively small % of them would be miscategorized (for example, 20%). People being lazy or unexperienced does not mean they lack common sense. Another thing is that they would be more likely to do a poor categorization, but I think this is clearly a lesser evil when compared to uncategorized or miscategorized files.

A different case is removing all categories from an existing file: my opinion is that this should not be allowed at all. MGeog2022 (talk) 11:26, 14 August 2026 (UTC)

Do you have a link to that old discussion? Andy Dingley (talk) 11:43, 14 August 2026 (UTC)

I've had a quick look just now to my edit history of about 1 year ago, and I haven't been able to find it. The edit history is too long (and it includes many edits to Village Pump), I don't remember the exact date (it could well have been two years ago and not one), and I don't know the exact words of the edit summaries. I'm sorry :( MGeog2022 (talk) 12:31, 14 August 2026 (UTC)

It's worth noting that rather than putting a focus on volunteers uploading their photos, the example of the funded DPLA project has created a far larger backlog of poorly categorized files going back several years and hardly anyone has asked for better categorization up front. In 2025 the bot uploaded 4,358,048 files. Of these 1,567,037 are shown on the database as having visible categories but 2,791,011 still have no visible category, but rely on large hidden source categories like Category:Media contributed by National Archives at College Park - Motion Pictures (which I happen to be looking at for a deletion request), which as a source category has 134,531 files in it. Categorization can be automated, for example my uploads to Early English Books which may have over 67,000 books in it when complete, are gradually retrospectively sorted by publication year in sub-categories. However automated categorization is itself a technical headache of what is going to be meaningful and not artificially hide stuff under complex over sub-categorization for the sake of it. --Fæ (talk) 11:09, 14 August 2026 (UTC)

Some of those hidden categories are still quite useful, and quite specific. I've done some work with the Anefo collection, a large Dutch news image library covering the second half of the 20th century. Just that label alone is quite a good starting point. Which is handy, as it's tens of thousands of images, auto-identifiable by author, date, 75% chance of being in the Netherlands, and the rest depending on parsing a para of description and hoping for a town name. But 'Anefo' alone is so much better than nothing, and so much easier to start from than the images in this post. Andy Dingley (talk) 11:42, 14 August 2026 (UTC)

Request rare illustration of Bananas in Pyjamas

Hello everyone! I am looking for a very rare illustration of four bananas in pyjamas: two wearing the classic blue-and-white striped pyjamas, one in red-and-white, and one in green-and-white. It can be found exclusively in the book Nursery Play Rhymes, illustrated by Jenny Press and published by Video Collection International between 1990 and 1991 (ISBN/EAN: 5014138110062). Does anyone happen to have this book and could upload a scan of this page to Commons? Thanks! DanielParoliere (talk) 11:00, 14 August 2026 (UTC)

See COM:L. Wikimedia Commons can not host any images that are in copyright, as the cartoons would be. Fæ (talk) 12:15, 14 August 2026 (UTC)

Should new, complete maps contain name of creator in legend or margin?

I was talking to someone, and they said that maps in Wiki Commons often violate professional mapping guidelines, because the maps did not identify the creator of the map. (The creator is typically a company, government agency, or individual). They said that high-quality, professional maps contain the identity of the creator embedded in the map itself, typically in a legend or in the margin. I'm pretty sure that is not a requirement for maps in Commons. Question: Has there ever been a proposal that maps in Commons (particularly new, complete maps uploaded to Commons) should contain the identity of the creator somewhere in the map image? Or, more generally, that new, full maps should contain a legend with scale, data source, etc? Noleander (talk) 14:32, 14 August 2026 (UTC)

How this will coexists with Commons:Watermarks? EugeneZelenko (talk) 15:08, 14 August 2026 (UTC)

This guide from ESRI opens with: "A successful design begins with knowing why the map is being made. [...] The topic and intended audience will dictate many of a map's characteristics." which implies that some maps require more details (such as a legend and scale and so on) but others eschew these aspects to better emphasize other facets of the cartographic data being conveyed. Arlo James Barnes 15:11, 14 August 2026 (UTC)

That is what the description is for. The description is actually shown in the corner when you enlarge a picture with the standard media viewer. It is even larger then in most maps which have a tiny copyright information somewhere on the edge. Personally I wouldn't mind a small watermark, but it works differently on Commons, and attribution is quite well done in many cases. Nux (talk··dyskusja) 16:59, 14 August 2026 (UTC)