Commons:Village pump
|
This page is used for discussions of the operations and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2026/08. Please note:
Purposes which do not meet the scope of this page:
Search archives: |
| Legend |
|---|
|
|
|
|
|
| Manual settings |
| When exceptions occur, please check the setting first. |
 A village pump in Burkina Faso [add] | |||||||||||||||
| |||||||||||||||
 |
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days. |
January 02
History maps of Europe
Hi, I would like to discuss the description in all categories of the scheme "Maps of <country> in the <x>th century" (see for example Italy, Belgium, Spain, Poland). There are three different points about the current system I would like to invite comments on:
- the wording of the definition in the first paragraph of the hatnote
- whether or not to include "you may also be looking for similar maps" (second and third paragraph) of the description
- whether or not to re-include a distinction between history maps (in this category group) vs. old maps (not in this category group)
- For the first point, there are two proposals, the first is the current "
Maps showing all or most of the territory (geographic area) of modern-day <country> - as the lands were in the 8th century (701-800 CE)
" which I would prefer to replace with a simple "This category is about maps of the history of <country> in the 8th century (701-800 CE)
", given that "modern-day territories" are not always the same as they were in the respective century. Another critism of mine is that "all or most" excludes history maps that only cover smaller parts of the country in question. - For the second point, my argument is that these paragraphs are not necessary, since the links to the Atlas project should be included in the respective parent category (i.e. "Maps of the history of <country>"), which is also linked via template.
- For the third point, I find it essential to point out that Commons has always distinguished "current", "history" and "old" maps, formulated in Template:TFOMC: "history" maps include this map of Poland in the 16th century (created recently, depicting the past) but "old" maps include this 16th-century map of Poland (created to depict the present, back then). There are certain grey areas where these categories DO overlap, especially "old history maps", but in quite many cases they don't. The respective category names are quite similar and can be confused, so I would suggest to mention this right in the category description.
- For the first point, there are two proposals, the first is the current "
I've put my own opinion in italics to explain why I think this requires debate, but I would like for people to check out the scheme examples for themselves, and judge on their own. Peace, --Enyavar (talk) 08:11, 2 January 2026 (UTC)
- @Enyavar: I'm trying to understand the first point. A couple of questions that may help me understand:
- Would there be no such thing as "maps of Germany" for any date before 1866? Or would we take "Germany" before that date to mean the German-speaking world (and, if so, would that include areas where the rulers spoke German, but most of their subject did not)? or what? (Similarly for Italy.)
- Similarly: would there be no such thing as maps of Poland or Lithuania between 1795 and 1918? If so, what would we call maps of that area in that period?
- I could easily provide a dozen similar examples, but answers to those two will at least give me a clue where this proposes to head. - Jmabel ! talk 18:49, 2 January 2026 (UTC)
- Thanks for that question, our categories about "history of" do not really care for nation states existing. Germany's history begins quite some time before it became a nation in the 19th century, and Polish history did not stop during the times of division: Poland in the 19th century is unquestionably a valid category. Our history categories generally imply that people know the limits of a subject without exact definitions.
- Your question is getting to the reason why I am uncomfortable with the current hatnote/definition of these categories. I have not checked for all countries in Europe, but I'm quite confident: We do not define the subject of "Maps of the history of Poland" with a hatnote. We do not define "Poland in the 16th century" either. So why would we define the combination subcategory of the two so narrowly and rigidly, that only 6 out of 26 files currently in the category even match that (unreasonable) definition? (And of course, Poland/16th is just a stand-in here, I would argue the same for Spain/12th and Italy/8th and all others)
- I would even be okay with no definition at all, besides a template notice (my third point) that "maps of <country> in Xth century" is about history maps, and old maps have to be found in "Xth-century maps of <country>". --Enyavar (talk) 04:53, 3 January 2026 (UTC)
- Categories denoted as old, or historic, are not terribly useful. Much better to put dates on them. Rathfelder (talk) 17:05, 15 January 2026 (UTC)
- Please read the original post, that is not a comment on the actual questions of this topic. Old maps are not the topic here, this is about history maps (i.e. Maps showing history of specific countries/centuries) regardless of when they were produced.
- The term "historic maps" that can denote both, has rightfully fallen (mostly) into disuse. --Enyavar (talk) 16:23, 17 January 2026 (UTC)
- Categories denoted as old, or historic, are not terribly useful. Much better to put dates on them. Rathfelder (talk) 17:05, 15 January 2026 (UTC)
- Thanks for that question, our categories about "history of" do not really care for nation states existing. Germany's history begins quite some time before it became a nation in the 19th century, and Polish history did not stop during the times of division: Poland in the 19th century is unquestionably a valid category. Our history categories generally imply that people know the limits of a subject without exact definitions.
- @Enyavar: I'm trying to understand the first point. A couple of questions that may help me understand:
In our Commons:WikiProject Postcards we have the similar problem. Is this a "old postcard of the German Empire" or a "Postcard of Germany". There we are mostly agree, that today people often search for postcards be the locations of today. So many former German towns are now Polnish towns and so we are categorized this postcards under the polnish name of the town. See also Commons:WikiProject_Postcards#Categories. Best regards --sk (talk) 12:29, 12 February 2026 (UTC)
- @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)
February 22
Maps from Our World in Data
A suggestion in regards with the maps from Our World in Data: remove from each map the category <year> maps of the world.
These maps weren't published in the years referenced. In addition, it could make the categories of <year> maps of the world more easy to browse.
Thanks in advance. --Universalis (talk) 19:15, 22 February 2026 (UTC)
- As with other files in these categories, that's the year of the data. This categorization has large usefulness to find and update outdated images used on Wikipedia. And the category title does not imply that's the year the map was made. Prototyperspective (talk) 20:13, 22 February 2026 (UTC)
- +1 to Prototyperspective. - Jmabel ! talk 20:39, 22 February 2026 (UTC)
- I have been meaning to say something about these maps, and this is a good occasion. User:Universalis is right that these maps were not created in that year,
and it IS practice on Commons to understand "<year/decade/century> maps" being the maps created in that timeframe, not the maps showing that timeframe - the latter would be better placed under "maps showing <year/decade/century>". - User:Doc James, who is creating the majority of recent OWiD maps that concern what might be called history, is producing them by the thousand each day, at least as far as I can observe. For 2026-02-24 I just checked and saw 5000 edits, most if not all of them creating and categorizing OWiD statistics/maps usually looking like this (1947), this (1664) and this (1800). That is an enormous output and just for example 1764 maps of North America is currently dominantly OWiD maps and I suspect that this is true for basically all year-maps-of-world/continent right now. Case in point: the categories for 1444 maps of Africa, 1445 maps of Europe or 1446 maps of Asia don't even exist right now, but they are already filled with OWiD maps.
- With at least 300'000 OWiD maps already existing and no end in sight, I would really like to delegate all of these maps into specific OWiD-categories for each continent and year. My suggestion for File:Annual co2 cement, North America, 1764.svg would be Our World in Data maps showing North America in 1764 or Our World in Data maps of North America in 1764. These year-categories would themselves be categorized under Our World in Data maps showing 1764 and Our World in Data maps of North America in the 18th century.
- The titles I suggest above are up for debate. Is it more practical to use "Our World in Data maps" or can it be shortened to "OWiD maps" ? Also, should it be "showing" (as per our category branch "maps showing <year>") or should it just be "of" ? --Enyavar (talk) 03:58, 25 February 2026 (UTC)
- Sure we can adjust the categories however folks wish. We have additionally build a tool to help with more fined toned mass categorization. See Help:Gadget-CategoryBatchManager.
- With respect to numbers, yes have uploaded about 600K so far and it looks like I am maybe a third done, so maybe 1.2 million more to go. Will likely not finish until this fall. Doc James (talk · contribs · email) 06:03, 25 February 2026 (UTC)
and it IS practice on Commons to understand "<year/decade/century> maps" being the maps created in that timeframe, not the maps showing that timeframe
this is an inaccurate statement. Look into any of these categories of years of the recent few decades and you'll notice how what you said is false. What you said applies to old maps and there usually the data shown is not known better than year of map made or the same. Prototyperspective (talk) 13:47, 25 February 2026 (UTC)- So what do folks want us to do? Doc James (talk · contribs · email) 09:00, 26 February 2026 (UTC)
- In 2014, it has been decided that "<year> maps" should essentially be empty disambiguations, and we should use "maps created in <year>" and "maps showing <year>" instead. Practically, this rule has never been enforced, and has lead to many simmering debates ever since. I'm striking my quarrelsome nitpicks from my previous comment, in order to focus on the suggestion at hand: Creating special categories for OWiD maps. Okay? --Enyavar (talk) 11:04, 26 February 2026 (UTC)
- If you'd like to these could be subcategorized in the maps by year cats...I tried to keep them as flat as possible to enable viewing all the relevant files on one page, have easier to understand standardized cat names, and not start deep nesting that can cause queries and scans to break. Many hundreds of files would be moved. If there is agreement and no objections, should they be named Category:Our World in Data maps of the world showing 2014 data or Category:OWID maps of the world showing 2014 data or Category:Maps of the world showing 2017 (OWID) or Category:Our World in Data maps of the world showing 2014 or Category:2014 Our World in Data maps of the world or Category:2014 maps of the world (OWID) or sth else? (It's mostly maps of the world that I'd move.) Prototyperspective (talk) 12:40, 26 February 2026 (UTC)
- Doc James has stated above that we are going to have about ~1'800'000 maps once the current run of creating these files is finished. And I don't even think that will be the end of it. So I agree, we need to have a good standardized cat structure, and I am willing to hear if Doc James also has input on good names, or input on which names are less good. With that lead:
- As far as I can see, we do have the following seven regions over which these maps are distributed: "the world", "Africa", "Asia", "Europe", "North America", "Oceania", "South America". These are the seven most common frames I noticed so far, please correct me if there are more. "World" is probably going to be a bit larger, but I don't think we should neglect the other regions, which are all going to be equally densely filled.
- Now, thinking about the best name structure. I would prefer to pre-fix the data source, similarly to how we do it with other major map providers like "OpenStreetMap maps of...", "USGS maps of...", "ShakeMaps of earthquakes in...": The most important qualifier gets frontloaded. For easy manual input, I would prefer the name "OWiD maps of...". However, the categories are unlikely to get assigned manually, and it is much easier to understand what the acronym means when it is written out. So right now, I would tend to go with the general
Our World in Data maps of...
as the prefix, then followed with the seven (?) regions identified above. - Afterwards comes the suffix. Prototypeperspektive suggested
... showing <year> data
, my own ideas leaned towards... in <year>
or... showing <year>
. These suggestions all look equally good to me. Prototype's suffix has the advantage of pointing out that these maps are data-driven and not cartography-driven. So I think that would be best. - Following that idea, we could go with
Our World in Data maps of <region> showing <year> data
. Taking an existing map like File:States involved in state based conflicts, Oceania, 1947.svg, one would assign Our World in Data maps of Oceania showing 1947 data instead of the current three categories Our World in Data maps of Oceania, Maps showing 1947 and 1947 maps of Oceania. That new category would itself be categorized directly under the existing three categories it replaces. - If the above suggestion seems agreeable... how difficult is it for Doc James to change the automated exports and the templates that are currently in use? And would you be able to do an automated re-categorization of all the already existing files? Would you need help? --Enyavar (talk) 18:54, 28 February 2026 (UTC)
- Yah I think doing this in an automated fashion should be fairly easy. This would be subcategories of what main category? Doc James (talk · contribs · email) 19:01, 28 February 2026 (UTC)
- [[:category:Our World in Data maps of <region> showing <year> data]] would be subcategory of [[:category:Our World in Data maps of <region>]], [[:category:Maps showing <year>]] and [[:category:<year> maps of <region>]]. At a later point, I would like to reshape the last of the three parent categories to bring the OWiD maps under the 20th-century/1940s branches of <region>. With the example above, there is currently no sufficient subdivision of Maps of the history of Oceania, but the idea is creating Maps of Oceania in the 20th century and Maps of Oceania in the 1940s, and that would again be a subcategory of Oceania in the 1940s... But I think that work would not affect the OWiD-maps and their templates itself. --Enyavar (talk) 19:13, 28 February 2026 (UTC)
- Plan was to categorize once the initial uploads are completed, which will not be until this fall. And work on the 1.8 million or so files at that point. Doc James (talk · contribs · email) 19:18, 28 February 2026 (UTC)
- You are currently categorizing them upon upload by two mechanisms, one is the template:Map showing old data, the other is assigning regular categories. Right now, neither of these mechanisms is a bespoke template designed for OWiD content.
- I can imagine a template that works like
{{OWiD maps showing|Africa|1758}}that would create the categories we contemplated above, including links to skip forward/backward and also links to skip to the other continents/world extent. If we used such a template to create the category framework discussed above, couldn't you adapt your exporting automatism once that exists? I can only image it would take less work later. - Before I attempt working on such a template myself, I'm asking a few users who I suspect have more routine in templating, @Clusternote, AnRo0002, and Reinhard Müller: My question is how you would go about it: templates for the file descriptions; templates for creating these categories; or both? Are there pitfalls I am not aware of? We are talking here about ca. 2 million standardized files ranging from very few around the year 1021 to an abundance of such files for 2021, with hundreds of files per year per continent in 1834 already. The maps are optimized to be used in slider-frames elsewhere; for Commons I'm more concerned with handling the categorization. Thanks in advance! --Enyavar (talk) 21:51, 3 March 2026 (UTC)
- Here is my suggestion: Maps of Oceania in the 1940s anro (talk) 22:18, 3 March 2026 (UTC)
- I can happily come up with a suggestion for a template based on the Navigation by system. But first let me make sure I understand correctly:
- The template would be used for categories like Our World in Data maps of Oceania showing 1947 data, right?
- Would we also have Our World in Data maps of Oceania showing 1940s data (decade) and Our World in Data maps of Oceania showing 19th-century data (century) as parent and grandparent of the year category?
- Thanks --Reinhard Müller (talk) 09:07, 4 March 2026 (UTC)
- Thanks Reinhard, regarding #1 yes that is idea.
{{OWiD maps showing|Africa|175|8}} -->Our World in Data maps of Africa showing 1748 data{{OWiD maps showing|Oceania|194|7}} -->Our World in Data maps of Oceania showing 1947 data- As for #2 I would have suggested "... showing the 1940s" and "...showing the 20th-century" as parent categories. But you're right, I talked above about "<year> data" so "<decade>s data" and "...<century> data" would be the logical consequence. Now I'm less sure about the format. I am not married to the idea of requiring the "data" suffix, but as long as the template could be made, I see no real problem. @Prototyperspective: , what do you think about "Our World in Data maps of Oceania showing 20th century data being the respective category on the century level? Enyavar (talk) 19:11, 5 March 2026 (UTC)
- Thanks Reinhard, regarding #1 yes that is idea.
- Plan was to categorize once the initial uploads are completed, which will not be until this fall. And work on the 1.8 million or so files at that point. Doc James (talk · contribs · email) 19:18, 28 February 2026 (UTC)
- [[:category:Our World in Data maps of <region> showing <year> data]] would be subcategory of [[:category:Our World in Data maps of <region>]], [[:category:Maps showing <year>]] and [[:category:<year> maps of <region>]]. At a later point, I would like to reshape the last of the three parent categories to bring the OWiD maps under the 20th-century/1940s branches of <region>. With the example above, there is currently no sufficient subdivision of Maps of the history of Oceania, but the idea is creating Maps of Oceania in the 20th century and Maps of Oceania in the 1940s, and that would again be a subcategory of Oceania in the 1940s... But I think that work would not affect the OWiD-maps and their templates itself. --Enyavar (talk) 19:13, 28 February 2026 (UTC)
- Yah I think doing this in an automated fashion should be fairly easy. This would be subcategories of what main category? Doc James (talk · contribs · email) 19:01, 28 February 2026 (UTC)
- Doc James has stated above that we are going to have about ~1'800'000 maps once the current run of creating these files is finished. And I don't even think that will be the end of it. So I agree, we need to have a good standardized cat structure, and I am willing to hear if Doc James also has input on good names, or input on which names are less good. With that lead:
- If you'd like to these could be subcategorized in the maps by year cats...I tried to keep them as flat as possible to enable viewing all the relevant files on one page, have easier to understand standardized cat names, and not start deep nesting that can cause queries and scans to break. Many hundreds of files would be moved. If there is agreement and no objections, should they be named Category:Our World in Data maps of the world showing 2014 data or Category:OWID maps of the world showing 2014 data or Category:Maps of the world showing 2017 (OWID) or Category:Our World in Data maps of the world showing 2014 or Category:2014 Our World in Data maps of the world or Category:2014 maps of the world (OWID) or sth else? (It's mostly maps of the world that I'd move.) Prototyperspective (talk) 12:40, 26 February 2026 (UTC)
- In 2014, it has been decided that "<year> maps" should essentially be empty disambiguations, and we should use "maps created in <year>" and "maps showing <year>" instead. Practically, this rule has never been enforced, and has lead to many simmering debates ever since. I'm striking my quarrelsome nitpicks from my previous comment, in order to focus on the suggestion at hand: Creating special categories for OWiD maps. Okay? --Enyavar (talk) 11:04, 26 February 2026 (UTC)
- So what do folks want us to do? Doc James (talk · contribs · email) 09:00, 26 February 2026 (UTC)
I have now created:
- Templates
- {{Category description/Our World in Data maps by continent and century}}
- {{Category description/Our World in Data maps by continent and decade}}
- {{Category description/Our World in Data maps by continent and year}}
- Example use
- Category:Our World in Data maps of Oceania showing 20th-century data
- Category:Our World in Data maps of Oceania showing 1940s data
- Category:Our World in Data maps of Oceania showing 1947 data
- Category:Our World in Data maps of the world showing 1947 data
The usage of the templates is super easy, no need for any parameters specifying the continent or the year, they take everything they need to know from the name of the category they are used in.
The names of the continents are automatically translated using Wikidata labels. The first part of the title and the text above and below the navigation blocks are just examples. These can be used as an explanation for the category which is centrally maintained and must only be changed once if something should be changed, and if the texts are final, we can also make them translatable.
Please let me know what you think. --Reinhard Müller (talk) 09:52, 6 March 2026 (UTC)
- P.S. Looking at the currently existing category tree about maps, I really think that the OWiD categories shouldn't be in Category:1947 maps of Oceania or Category:1940s maps of Oceania. For centuries, we already have Category:Maps of Oceania in the 20th century, and I think it might be a good opportunity to introduce these categories also on a decade and year level. If you want, I can also create the templates for "Maps by continent and century/decade/year shown". And/or whatever you consider useful for building the correct parent structure for the OWiD categories. --Reinhard Müller (talk) 14:37, 6 March 2026 (UTC)
- @Reinhard Müller: Thanks a lot! This is even easier to apply than I thought. I populated three continents for the 1940s (Africa, Asia, Oceania) and also the world.
- The decade-template for the world in the 1940s did not work (lua template cannot find "the world"), I hope this can be fixed. Aside from that it looks pretty great. Sorry, two more nitpicks, some links only appear once some other part of the structure has been fully built up. The year-ribbon only shows up once the decade-category is in place; and it seems as if the decade template only shows up once the century-category is in place? Also, I think that the subcategories could be sorted with a space (" ") instead of the "@".
- I agree with your proposal that instead of "1947 maps of Oceania" we should have "Maps of Oceania in 1947" which would be the "maps showing"-version. "Maps of Oceania in 1947" would be a subcategory of "Maps showing 1947", "Oceania in 1947", "Maps of Oceania in the 1940s" respectively. This category would then hold the OWiD maps and all maps that show Oceania in 1947 through the historian's lens, similar to how we already have Maps of Poland in the 16th century (see also one thread above...) and Maps of the world in the 1940s.
- @Universalis, Prototyperspective, Jmabel, and Doc James: when you check the bolded links... does this new structure look okay? --Enyavar (talk) 15:22, 8 March 2026 (UTC)
- Very nice. Are you using a bot to apply this? Or have you tried Help:Gadget-CategoryBatchManager? Doc James (talk · contribs · email) 16:46, 8 March 2026 (UTC)
- Thanks for the feedback!
- I fixed "the world" (ooh, it feels good to write this ;-))
- It is generally true that the template works best when the categories are created top down (i.e. first the centuries, then the decades, then the years). Still the navigation ribbons should appear even if the parent category does not exist (yet), I will have to investigate why they don't. But for the addition of the correct parent categories for new categories, it is important anyway that the parents pre-exist.
- FWIW, this is now also fixed. --Reinhard Müller (talk) 19:51, 9 March 2026 (UTC)
- I have (years ago) thought a lot about the question of logical sort keys, currently they are used very inconsistently across commons. I've even made a page summarizing my thoughts which you may or may not agree with. About this specific case, I think the space is widely used for meta categories (Blah blah by xyz) and should be reserved for that, and that the @ has the advantage of being sorted after all the other special characters, so if for example the category key "*" is before the alphanumeric subcategories, it is also before the numeric subcategories if the numeric are sorted as @. In the end I don't think in our case it makes much of a difference as long as all the subcategories use the same key so they are sorted correctly - which is taken care of by the template.
- About the "Maps of Oceania in 1947", would you want to also create them right now? Should I create a {{Category description/Maps by continent and year}} (and decade and century), and adapt the OWiD templates to the new parents?
- I don't use a bot, and I think that the CategoryBatchManager can add parent categories, but not a template. But since you don't have to change a single letter when copying the template from one category to a similar one, it can be done very fast. --Reinhard Müller (talk) 18:02, 8 March 2026 (UTC)
- About the "Maps of Oceania in 1947" - yes, you could create a template for that, as well. We already have parts of that, but right now they were created in a manual fashion: North America/1770s and Asia/18th and Europe/11th. I'm not yet fully eager and ready to apply this structure as long as the other treat about #History maps of Europe is still unresolved. But having the templates prepared now might help later. Once those maps-per-continent-shown-by-year exist, the OWiD template would be switched from "1940s maps of Asia"+"Maps showing the 1940s" --> "Maps of Asia in the 1940s" and so on. --Enyavar (talk) 19:51, 8 March 2026 (UTC)
- I have created:
- I have not (yet) changed the parent categories for the OWiD categories. Please just let me know when I should do that.
- Also please don't forget that the texts above and below the navigation ribbons are just placeholders (in the OWiD templates and the new templates), and they should be finalized before the templates are widely used. --Reinhard Müller (talk) 22:02, 8 March 2026 (UTC)
- About the "Maps of Oceania in 1947" - yes, you could create a template for that, as well. We already have parts of that, but right now they were created in a manual fashion: North America/1770s and Asia/18th and Europe/11th. I'm not yet fully eager and ready to apply this structure as long as the other treat about #History maps of Europe is still unresolved. But having the templates prepared now might help later. Once those maps-per-continent-shown-by-year exist, the OWiD template would be switched from "1940s maps of Asia"+"Maps showing the 1940s" --> "Maps of Asia in the 1940s" and so on. --Enyavar (talk) 19:51, 8 March 2026 (UTC)
- Thanks for the feedback!
- Looks great; thanks very much. I just don't know how complete these cats currently are and will be. They could be made complete via deepcategory category intersections and moving files with cat-a-lot. Prototyperspective (talk) 18:22, 9 March 2026 (UTC)
- Very nice. Are you using a bot to apply this? Or have you tried Help:Gadget-CategoryBatchManager? Doc James (talk · contribs · email) 16:46, 8 March 2026 (UTC)
- But first, we need to categorize the OWiD maps. I populated the 1940s structure with a few hours of Cat-a-lot, but there is a catch: all these maps currently have the template
{{Map showing old data|year=1942}}. For the 1940s alone, removing that template meansmanuallyediting 17'500 files. We must use a bot to do these edits, I think. The algorithm, for all ~75'000 maps of Asia would be roughly as follows:- for all files in
[[Category:Our World in Data maps of Asia]]- if "
{{Map showing old data|year=YYYY}}" occurs in the file:- take the YYYY as a variable to insert "
[[Category:Our World in Data maps of Asia showing YYYY data]]" //** a single category for the location and year of the map **//- if that inserted category does not yet exist: create it with "
{{Category description/Our World in Data maps by continent and year}}" //** (as helpfully provided by Reinhard)**//
- if that inserted category does not yet exist: create it with "
- take the file name as the variable
topicnameand stripFile:and, Asia, YYYY.svg(or,Asia,YYYY.svg) from that variable - insert "
[[Category:Our World in Data maps showing ||topicname]]" //** for example Category:Our World in Data maps showing Absolute change co2, neatly collecting ~1800 files like this one or ~200 files like this one: a single category for the topic of the map, to have them all easily assembled **//- if that inserted category does not yet exist: create it with "
[[Category:Our World in Data maps by topic]]" //** in many cases, better names might be found, but that cleanup can be handled afterwards manually where needed **//
- if that inserted category does not yet exist: create it with "
- remove all occurences of "
{{Map showing old data|year=YYYY}}", ""[[Category:YYYY maps of Asia]]" and "[[Category:Our World in Data maps of Asia]]"
- take the YYYY as a variable to insert "
- (else leave the file alone)
- if "
- repeat the same with "Africa", "Europe", ["North America" or "NorthAmerica" would need to be mapped onto "North America"], "Oceania", and so on.
- for all files in
- I do not know how exactly to program a bot, but I think this would do the trick, not only to create and populate the categories for continent-by-year, but also to have distinct categories for each topic. Right now, I don't think the latter exist yet. --Enyavar (talk) 19:51, 8 March 2026 (UTC)
For the 1940s alone, removing that template means manually editing 17'500 files
: I haven't been following all of this, but why manually? - Jmabel ! talk 20:53, 8 March 2026 (UTC)- True, the bot run would also touch those files. I just wanted to emphasize that so many files cannot be realistically processed manually, and then formulated how I think this could be automated. I struck the word in my earlier response. --Enyavar (talk) 22:21, 8 March 2026 (UTC)
- I added the above request to Commons:Bots. --Enyavar (talk) 16:03, 12 March 2026 (UTC)
August 11
'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)
- 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)
- 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)
- Here's a list of crests/ arms - I'll be uploading an example of each in due course. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 18 August 2026 (UTC)
- That would be good for cross-referencing how coats of arms are meant to look, I think. – Howardcorn33 (💬) 19:25, 18 August 2026 (UTC)
- Here's a list of crests/ arms - I'll be uploading an example of each in due course. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 18 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)
August 13
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)
- Category:Zohran Mamdani is under Category:21st-century male politicians of New York City which is somewhere under Category:Male politicians of the United States.
- Category:Politicians of the United States in 2025 has no male or female subcats, and contains women like Category:Pam Bondi in 2025 Category:Kristi Noem in 2025.
- what's your point? what's the problem? RoyZuo (talk) 14:17, 15 August 2026 (UTC)
Draft proposal
[This could either be an addition to COM:OVERCAT or a separate project page; either way, it effectively modifies OVERCAT.]
Nutshell: As a general rule, categories that intersect individuals' gender, ethnicity, religion, or sexuality with some other category should be non-diffusing categories. There are some exceptions to this, which are addressed below.
Rationale: Regardless of intentions, the introduction of categories such as Category:Female guitarists or Category:Jewish classical musicians can lead to ghettoization. Fundamentally, a female guitarist or a Jewish cellist does exactly the same thing as a male guitarist or Russian Orthodox cellist, but when they are sectioned out like this they are separated from their peers based on a characteristic that is irrelevant to the matter at hand. Some of the unwelcome results are:
- One ethnicity is singled out this way, separating them from basically everyone else in their field. Because they are somewhat separated out, they are overlooked for other diffusions of the main category, so they are never categorized by nationality, genre of music, etc.
- In an overwhelmingly male (or overwhelmingly female) field women (or men) are ghettoized with similar effect.
- Diffusing a category by sexual orientation can be particularly pernicious, because it requires you to know something not necessarily obvious about a person to find them in the categorization system, and because there are likely to be very large numbers of people of no publicly declared sexuality.
There are valid reasons to have categories such as Category:Female guitarists or Category:Jewish classical musicians, but they should be implemented as non-diffusing categories.
What does non-diffusing mean? We will need a paraphrase of text from en:WP:Categorization#Non-diffusing subcategories, including our policy on tagging these. Note that we already have {{Non-diffusing subcategory}}, but it is not heavily used.
Exceptions:
The following may be diffused by gender:
- actors
- dancers
- vocalists
The following may be diffused by religion:
- clergy
- missionaries
- theologians
- saints or other venerated individuals, diffused to the religion or religions that venerate them
other exceptions?
Jmabel ! talk 04:10, 15 August 2026 (UTC)
- Years ago I remember proposals regarding the same. In general I think that Commons should allow the user to find intersections of categories, rather than having categories intersected by the editors. I upload many stamps, there are categories for stamps by colour, and there are also categories for the stamps by subject, and also for the stamps by face value, and finally by their country. I would hate to see Category:Red stamps of Russia 2026 with the cost 80 that are self-adhesive but do not depict any females while at the same time depicting groups of singers. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 04:23, 15 August 2026 (UTC)
- I would just ban intersection categories in general and only define some exceptions. GPSLeo (talk) 05:06, 15 August 2026 (UTC)
- Is there a reasonable technology which allows to find intersections of categories for those who need them? What if a person does need to only find Missionaries who are having sex in Missionary position or only those women on photographs who are male? ℺ Gone Postal (〠 ✉ • ✍ ⏿) 11:01, 15 August 2026 (UTC)
- If you are looking for photos there is PetScan. When you want a list of people with a given set of properties, you should query on Wikidata and follow the link from Wikidata to category with the photos of this person. GPSLeo (talk) 11:32, 15 August 2026 (UTC)
- There is a way to search WikiData using SPARQL. Caffeinated Chihuahua (talk) 05:41, 16 August 2026 (UTC)
- Is there a reasonable technology which allows to find intersections of categories for those who need them? What if a person does need to only find Missionaries who are having sex in Missionary position or only those women on photographs who are male? ℺ Gone Postal (〠 ✉ • ✍ ⏿) 11:01, 15 August 2026 (UTC)
- makes no sense at all.
- why "actors dancers vocalists" are exceptions, but not film directors, choreographers, musicians (instrument players)...? different people in the same job (drama, dance, music) but treated differently? RoyZuo (talk) 14:13, 15 August 2026 (UTC)
- These are all performance-based occupations which revolve around the performer's appearance, and where performers are frequently chosen for a job based on their gender. The same principles would apply for athletes and fashion models, for instance. Omphalographer (talk) 20:28, 15 August 2026 (UTC)
- that's gonna open more cans of worms.
- how gender plays a role in an occupation is complicated and different from one to another.
- the idea that actors/performers are hired according to gender, has plenty of counterexamples, e.g. Takarazuka Revue (Q586430): Japanese all-female theatre troupe Q17065438: onnagata (Q2425502): male actors who impersonate women in Japanese kabuki theatre.
- then there're jobs that are imbalanced in terms of gender ratio (but to varying degrees in different countries or historical periods), including but not limited to domestic worker (Q54128): person who works within the scope of a residence butler (Q833899): domestic worker in charge of all the household staff nurse (Q186360): type of health care provider school teacher (Q2251335): teacher in primary and secondary education butcher (Q329737): craftsman responsible for the preparation and sale of meat bus driver (Q829020): profession... does the job requirement cause the imbalance? or is it specific cultures, customs and traditions? is gender a factor in hiring? is gender a factor in carrying out of duties?...
- for example, for some people and cultures today, female drivers are nothing special. some socialist countries started training female drivers many decades earlier https://www.bbc.com/news/world-asia-china-51116035 . but for some other people and cultures, some would have arguments for why women cannot hold the job of driver, like physique, stamina and whatnot https://www.bbc.com/news/uk-england-birmingham-48367181 https://english.news.cn/20221230/18339a051965424490e9708fde3193c1/c.html . then commons would have to deal with all sorts of arguments before it can decide whether it's useful and reasonable to separate files about a certain occupation by gender. RoyZuo (talk) 22:41, 15 August 2026 (UTC)
- These are all performance-based occupations which revolve around the performer's appearance, and where performers are frequently chosen for a job based on their gender. The same principles would apply for athletes and fashion models, for instance. Omphalographer (talk) 20:28, 15 August 2026 (UTC)
- there's also a problem with nouns that have a gender, e.g. Category:Governesses Category:Seamstresses Category:Waitresses Category:Actresses. how are those handled?
- just like someone said, i also think that intersection cats should simply abolished, so things like Category:Buildings by city by country by material by color get broken up into basic pieces "building" "city" "material" "colour".
- but until people agree on that, i dont think there's anything effective in stopping certain users from creating these flaky layers of categories. RoyZuo (talk) 17:49, 15 August 2026 (UTC)
- But aren't you then requiring a picture of a green pair of gloves to go under both Green objects and Gloves instead of just Green gloves, thus overloading the more general cats? Arlo James Barnes 22:32, 15 August 2026 (UTC)
- there's no "overloading". it's perfectly fine if a cat contains millions of files.
- there's no "more general cats". all should be "general cats" that deal with exactly only 1 aspect. categorise files to answer five Ws (Q368722): questions whose answers are considered basic in information-gathering, but dont combine those answers to create cats like Category:France photographs taken on 2026-05-01. this one mixes where, what, when. problems of this specific one have been raised in 2016 Commons:Categories for discussion/2016/10/Category:September 2007 Finland photographs.
- RoyZuo (talk) 22:57, 15 August 2026 (UTC)
- I agree that the personal cats could benefit from non-diffusion (and we already have categories like that, the 'flat list' cats which don't allow substructure), but to make it the default I think goes too far the other way. The whole point of categories is that they knit together in such a way, otherwise we would only use/need the structured data statements to describe each file. Arlo James Barnes 01:26, 16 August 2026 (UTC)
- But aren't you then requiring a picture of a green pair of gloves to go under both Green objects and Gloves instead of just Green gloves, thus overloading the more general cats? Arlo James Barnes 22:32, 15 August 2026 (UTC)
On the exchange above between User:Gone_Postal and GPSLeo: I don't really think this particular discussion is the place to make an entirely different proposal that would completely redefine how Commons uses categories. Feel more than free to make a distinct proposal of your own, but it seems you are arguing "don't refine the current approach because I'd like to do everything almost completely differently," and that just really isn't fair, it's a derailing. In case you do plan to make a proposal along those lines, though, I want to point out a use case you may not be considering, where I think the current category approach performs particularly well: when a user starts, not from a rationally formed query, but from one of our files, and thinks "this isn't exactly what I want, but it's close." Right now, they can navigate from the file to a category that seems like it might be promising, and possibly from that to parent and child categories. I would hope that any proposed replacement for the current approach to categories takes that use case into consideration.
@RoyZuo: yes, there are some small number of cases where even for these types of performers, their gender is irrelevant, but I hope you would agree that these are relatively rare cases. Even some of your examples could as easily be seen as counterexamples: the Takarazuka Revue is an all-female troupe, which is pretty much a defining factor for it. Yes, many of their performers play male roles, but that doesn't change the fact that the members of the troupe actually being women is a defining factor in these performances.
Imbalance in gender ratio may be a reason to have a gender-specific subcat for those who are the exception to the rule, but it is absolutely not a reason to make that a diffusing subcat, quite the opposite. The latter is precisely the "ghettoization" problem this proposal is intended to address.
It is possible that the now mostly historical role of a governess might be another case that would call for an exception. Category:Waitresses, however, is simply a gendered subcat of Category:Waiters (with no corresponding specifically male subcat) and with possibly a few edge-case exceptions, waiters and waitresses do the same work. We could arbitrarily make it an exception here, but it would only be because in this case the English language is not our friend. - Jmabel ! talk 23:31, 15 August 2026 (UTC)
- I really do like your counterexample of a person finding one file and then searching for another. It is definitely something to consider, and I do not think that there was an attempt to "derail" anything, only placing the discussion in a wider context in order to not make many small patches. At its current point I don't think that going the route of only the top level categories is a good approach, simply because the search function is not a replacement for the specific categories. The reason why I didn't vote for the proposal is because I do not know exactly how to approach this at this moment so that: 1) It will be useful for users 2) It will not create more work for editors 3) It will not need to be immediately reworked again. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 04:47, 16 August 2026 (UTC)
In general, this is a very good proposal, but I do not agree with any of the "exceptions". If you are going to say that male vocalists are not vocalists because they are hired for a particular vocal range, you might as well go straight to "bass, tenor, soprano" etc. categories. Likewise they say that Ginger Rogers did everything Fred Astaire did, but backwards and in heels, so how could you say that Ginger Rogers was not a legitimate dancer. And how could you categorize someone like Augustine by denomination, or some of the missionaries who were primarily notable as linguists.
Categories help editors find images. Removing already marginalized groups from broad categories will make them even less discoverable.
I would support implementing the "non-diffusing" parts now. It seems like the "exceptions" need more work before they can be agreed on. Caffeinated Chihuahua (talk) 05:37, 16 August 2026 (UTC)
- @Caffeinated Chihuahua: I think you may be misunderstanding at least one aspect of this. You write
If you are going to say that male vocalists are not vocalists
and that is not at all what this proposal is saying. We already have Category:Male vocalists and Category:Female vocalists as subcats of Category:Vocalists, and they will remain so. - Also, FWIW, "bass, tenor, soprano" etc. are useful for talking about people with Western Classical vocal training, and less so the farther you get from that. I don't think those terms could usefully be applied to Tuvan throat singing, nor even to many rock vocalists.
- Categories are primarily about helping people find things, and only secondarily about ontology. - Jmabel ! talk 07:01, 16 August 2026 (UTC)
- Just implement w:en:WP:ALLINCLUDED. Trying to delineate every possible exception is a fool's errand that only ensures we will never reach consensus. w:en:WP:ALLINCLUDED leaves plenty of wiggle room for common sense exceptions. Let's not make the perfect the enemy of the good. Nosferattus (talk) 22:16, 16 August 2026 (UTC)
See also
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)
- very good tool tysm.
- also, in that very old phab task people can see that the same idea has been repeatedly raised over the years! that shows how commonsensical it is and how urgently users need it. RoyZuo (talk) 14:07, 15 August 2026 (UTC)
- Something that bothers me is that I commented on this script in the same ticket and someone responded reactively instead of productively, I have repeatedly requested access to the git repository to contribute a Pull Request directly in the uploadwizard to solve this problem, but I have not received a response for this access after months of trying Wilfredor (talk) 13:52, 17 August 2026 (UTC)
- @Wilfredor "I have not received a response for this access". Gerrit access is open to anyone. There is only special permissions required for MERGE access (this is a community decision). See Gerrit/Tutorial for documentation on how to use Gerrit. The biggest roadblock for volunteers is generally finding people to review the code. —TheDJ (talk • contribs) 14:35, 17 August 2026 (UTC)
- I am talking specifically about this access, and I have written to this email trying to restart my access: idm-help@wikimedia.org Wilfredor (talk) 14:56, 17 August 2026 (UTC)
- @Wilfredor do you mean that you have lost access to your Wikimedia Developer account ? —TheDJ (talk • contribs) 19:24, 17 August 2026 (UTC)
- Yes, the last time I had one was over a decade ago, back in the Toolserver era. Wilfredor (talk) 14:09, 18 August 2026 (UTC)
- If I try to create one with my username "wilfredor," it tells me it already exists. Wilfredor (talk) 14:09, 18 August 2026 (UTC)
- @Wilfredor: Can you operate on the assumption that you created it long ago, and then you lost your password? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:22, 18 August 2026 (UTC)
- Yes, but when using the "lost my password" option, no email for the reset ever arrives Wilfredor (talk) 20:00, 18 August 2026 (UTC)
- @Wilfredor then the easiest option seem to be to create DevWilfredor or any similar combination that is free for taking :) (personally I use EcceNux for ssh/git) Nux (talk··dyskusja) 20:25, 18 August 2026 (UTC)
- I didn't want to lose my account, nor did I want to create another user profile and email address. Wilfredor (talk) 21:28, 18 August 2026 (UTC)
- @Wilfredor then the easiest option seem to be to create DevWilfredor or any similar combination that is free for taking :) (personally I use EcceNux for ssh/git) Nux (talk··dyskusja) 20:25, 18 August 2026 (UTC)
- Yes, but when using the "lost my password" option, no email for the reset ever arrives Wilfredor (talk) 20:00, 18 August 2026 (UTC)
- @Wilfredor: Can you operate on the assumption that you created it long ago, and then you lost your password? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:22, 18 August 2026 (UTC)
- @Wilfredor do you mean that you have lost access to your Wikimedia Developer account ? —TheDJ (talk • contribs) 19:24, 17 August 2026 (UTC)
- I am talking specifically about this access, and I have written to this email trying to restart my access: idm-help@wikimedia.org Wilfredor (talk) 14:56, 17 August 2026 (UTC)
- @Wilfredor "I have not received a response for this access". Gerrit access is open to anyone. There is only special permissions required for MERGE access (this is a community decision). See Gerrit/Tutorial for documentation on how to use Gerrit. The biggest roadblock for volunteers is generally finding people to review the code. —TheDJ (talk • contribs) 14:35, 17 August 2026 (UTC)
- Something that bothers me is that I commented on this script in the same ticket and someone responded reactively instead of productively, I have repeatedly requested access to the git repository to contribute a Pull Request directly in the uploadwizard to solve this problem, but I have not received a response for this access after months of trying Wilfredor (talk) 13:52, 17 August 2026 (UTC)
August 14
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)
- Do you have a link to that old discussion? Andy Dingley (talk) 11:43, 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)
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)
Thanks for your comments. From my point of view, it is effective, to search with GlamTools for files that are already used in an article, or to check Commons:WikiProject Minimum One Category for further hints. Basically, a larger number of volunteers would simplifiy the task. NearEMPTiness (talk) 04:47, 16 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)
- I think it depends on the type of map. As we have vector data maps should only be uploaded as files if it is really needed. For simple maps without a legend I would not add it to the file itself. For every map with a legend I would add the sources of the data directly to the file. I would not add the composer directly to the file for the use cases we have here usually. GPSLeo (talk) 19:12, 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)
Okay, so I gather (from the responses so far) that there has not been a proposal (made in the past) to mandate that information such as creator or data source be depicted in the images of new, full maps uploaded to Commons. That's good to know. I wasn't suggesting that it become a guideline; I was simply curious. It appears that the equivalent information in the file's Description page is sufficient. Noleander (talk) 21:31, 14 August 2026 (UTC)
- Here is a example where I included the source in the file: File:DWD RADOLAN and stations precipitation southern Germany 2024-05-30 to 2024-06-03.png. GPSLeo (talk) 21:38, 14 August 2026 (UTC)
- Thanks for that example. That is exactly what the other person was suggesting: that the creator (and data source, etc) be identified in the map's image (in addition to the Description page). I think the reasoning for the proposal was that the map image should conform to professional map guidelines and the creator is permanently named in the map itself. That way, the creator is known, even if the map file gets separated from its Commons Description page. Noleander (talk) 21:44, 14 August 2026 (UTC)
- @GPSLeo thanks for the example. There is unfortunately an immediate problem with that image, which is that Commons is a multilingual project. Daten is a German word and it cannot be translated in the image. It could be translated in the description. Nux (talk··dyskusja) 23:53, 15 August 2026 (UTC)
- i think you have a good point.
- most if not all professional maps produced before the internet have names and years on them.
- it makes sense that modern maps, even svg maps created by commons users, should follow that convention. RoyZuo (talk) 14:04, 15 August 2026 (UTC)
- It does make it necessary to l10n the file instead of relying on the i18n of leaving it uninscribed. Arlo James Barnes 22:34, 15 August 2026 (UTC)
August 15
File needs to be fixed
This file isn't playing and needs to be fixed. PublicDomainFan08 (talk) 08:49, 15 August 2026 (UTC)
- This is a large video file and Commons is quite poor at coping with videos over 1GB. If you want to try re-uploading, do so using one of the urls, such as the internet archive version. I tried with the 2GB IA version, but the mediawiki system gave up before it finished. Fæ (talk) 12:57, 15 August 2026 (UTC)
- it looks like the file was not converted to webm properly Bawolff (talk) 17:03, 15 August 2026 (UTC)
Clean up old requests
Commons:Audio and video requests; Commons:Pronunciation files requests and its many different versions, contain many old, unattended requests. maybe they could all be merged into commons:File requests?--RoyZuo (talk) 15:00, 15 August 2026 (UTC)
Support Arlo James Barnes 22:35, 15 August 2026 (UTC)- Support I'm also wondering if file requests could be organized similarly to Commons:Deletion requests, in that there are several subpages that are included in one main page, and the subpages could then be organized by topic? That way there could still be categorization by file type or topic if desired but everything could still be in a central location. Perhaps archiving topics would be easier too. ForeverFlying (talk) 02:24, 16 August 2026 (UTC)
- @ForeverFlying all request are already on Commons:Deletion requests/2026/08 which is quite long might I add and also you cannot subscribe to them which is problematic. Nux (talk··dyskusja) 17:36, 16 August 2026 (UTC)
- That's true, I hadn't thought of that. ForeverFlying (talk) 18:00, 16 August 2026 (UTC)
- @ForeverFlying all request are already on Commons:Deletion requests/2026/08 which is quite long might I add and also you cannot subscribe to them which is problematic. Nux (talk··dyskusja) 17:36, 16 August 2026 (UTC)
User stat tools
i'm gonna make a template that aggregates links to tools that analyse or compile stats about a user. i know these. could you please add more?
- https://glamtools.toolforge.org/
- https://ptools.toolforge.org/uploadsum.php
- https://wikimap.toolforge.org/
- https://commons.wikiscan.org/users
- https://xtools.wmcloud.org/
RoyZuo (talk) 15:00, 15 August 2026 (UTC)
- https://quarry.wmcloud.org/ can also execute queries about one user's uploaded files like amount of data, but only with SQL --PantheraLeo1359531 😺 (talk) 17:44, 15 August 2026 (UTC)
August 16
Any way to enforce need for US copyright tags?
A lot of media on Commons lacks the necessary US copyright tags and only shows a foreign copyright tag. Is there any way we can make it so that way media with a foreign copyright tag appears in a category if it lacks the needed US copyright tag. It really isn't optional, but a lot of people are treating it that way. Aplucas0703 (talk) 00:14, 16 August 2026 (UTC)
- Perhaps we could create a version of {{No license since}} called {{No US license since}}, for files which specify that the work is of foreign origin but fail to provide a justification for public domain status under US law, such as {{PD-US-expired}}, {{PD-US-unpublished}}, {{PD-1996}}, or {{PD-URAA-simul}}. – Howardcorn33 (💬) 11:34, 16 August 2026 (UTC)
- In many cases files that don't have a US license could have one, so it's largely a housekeeping issue. And even those that should be deleted need a DR and not a speedy because of the peculiarities of URAA (and also because many local wikipedias accept them locally). So, if we want to add a tag it's fine, but I think it'd be detrimental to delete those files after 7 days as we do with files without any license. Friniate (talk) 17:48, 18 August 2026 (UTC)
- And by the way, there have been cases in which it was decided that for specific categories (buildings) there was no need to add also a US license template, so for those files we'd need more templates. Friniate (talk) 17:50, 18 August 2026 (UTC)
- Then in that case there can be a template that says: "No US Tag Needed" and that lays out exceptions to the need for a US tag. Aplucas0703 (talk) 20:55, 18 August 2026 (UTC)
- Yes sure, my point is only that if you want to make mandatory the presence of a US tag everywhere, then we have to create them, because Template:FoP-US and Template:PD-US-architecture for example are only for American buildings and when I tried to use them on an Italian building I got reverted very quickly. Friniate (talk) 22:19, 18 August 2026 (UTC)
- Even for photos of buildings, you still need to prove that the photo is in the public domain in the United States. Aplucas0703 (talk) 00:50, 19 August 2026 (UTC)
- Yes sure, my point is only that if you want to make mandatory the presence of a US tag everywhere, then we have to create them, because Template:FoP-US and Template:PD-US-architecture for example are only for American buildings and when I tried to use them on an Italian building I got reverted very quickly. Friniate (talk) 22:19, 18 August 2026 (UTC)
- Then in that case there can be a template that says: "No US Tag Needed" and that lays out exceptions to the need for a US tag. Aplucas0703 (talk) 20:55, 18 August 2026 (UTC)
- And by the way, there have been cases in which it was decided that for specific categories (buildings) there was no need to add also a US license template, so for those files we'd need more templates. Friniate (talk) 17:50, 18 August 2026 (UTC)
- In many cases files that don't have a US license could have one, so it's largely a housekeeping issue. And even those that should be deleted need a DR and not a speedy because of the peculiarities of URAA (and also because many local wikipedias accept them locally). So, if we want to add a tag it's fine, but I think it'd be detrimental to delete those files after 7 days as we do with files without any license. Friniate (talk) 17:48, 18 August 2026 (UTC)
August 17
User script for Trove article images
Tim Sherratt has written a Tampermonkey script for downloading from Trove, the Australian archive, images of newspaper articles (from which, subject to copyright, photographs can then be extracted).
I have tried it and (subject to the caveats he states, about its slowness) it works well.
He describes it in "A new way of downloading Trove newspaper images". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:07, 17 August 2026 (UTC)
Photos by day by Australian state
~2026-43571-17 (talk · contributions · Move log · block log · uploads · Abuse filter log) has been creating subcategories for Australian states by day, despite most of these only ever having a very small number of photos. This seems excessive to me, and makes the daily categories harder to navigate. I know that some, such as Category:Australia photographs taken on 2026-02-08, have lots of photos, but as the vast majority of those are taken in the same state (i.e. Mapillary photos in South Australia) I don't think that diffusing is going to help. (I've left a message for the user on their temp account talk page.) Sam Wilson 23:03, 17 August 2026 (UTC)
- There seems to be a lot of those:
- Category:Photographs by date by country. I don't think that should be useful, you should be able to derive this from structural data... But using structural data is not easy... Nux (talk··dyskusja) 23:32, 17 August 2026 (UTC)
- That kind of intersection category is not useful. If the TA continues, I will take administrative action. Pi.1415926535 (talk) 23:56, 17 August 2026 (UTC)
- Thanks! I forgot to mention, one big source of these categories is {{Taken on}}, and the
|location=parameter there specifically says it's for the country. Sam Wilson 00:37, 18 August 2026 (UTC)- Then perhaps the template should be modified to not do that? Categories by country by date provide extremely little practical value, especially for modern photos. There is probably more time being spent by users maintaining these categories than time spent browsing them. Omphalographer (talk) 00:45, 18 August 2026 (UTC)
- I don't personally like the country-by-date categories, but there's some argument for their utility. Sub-national-division-by-date categories, like these categories being created by the TA, are almost never useful. Pi.1415926535 (talk) 00:54, 18 August 2026 (UTC)
- @Omphalographer: Whether we should have the country-by-date categories is a separate question, I think. This is about the sub-country divisions, which certainly if the country ones are over the top then they also are. But anyway, it seems like we're all in agreement, and User:~2026-43571-17 seems to have given up for the time being (although there's of course now lots of clean up to do). Sam Wilson 03:33, 18 August 2026 (UTC)
- Then perhaps the template should be modified to not do that? Categories by country by date provide extremely little practical value, especially for modern photos. There is probably more time being spent by users maintaining these categories than time spent browsing them. Omphalographer (talk) 00:45, 18 August 2026 (UTC)
- @Pi.1415926535: They're still doing it, and they keep reverting me on File:Anglesea Fremantle 01.jpg. Sam Wilson 12:57, 18 August 2026 (UTC)
- I support some sort of administrative action on this TA. It appears they are unwilling to be collaborative with others, since they are refusing to engage on their talk page or here in this thread, while continuing the behavior in question. Thanks. Tvpuppy (talk) 21:11, 18 August 2026 (UTC)
- Thanks! I forgot to mention, one big source of these categories is {{Taken on}}, and the
- That kind of intersection category is not useful. If the TA continues, I will take administrative action. Pi.1415926535 (talk) 23:56, 17 August 2026 (UTC)
- I would rather see the by-day categories stay at the national level. I could imagine (I haven't looked) that there might be enough photos for Sydney or Melbourne to handle those specially, but I don't think there is any gain in a breakdown by state, other than a dopamine hit for the person categorizing them.- Jmabel ! talk 00:03, 18 August 2026 (UTC)
August 18
CropTool vs. Geograph template
I used CropTool to crop File:Houses on Calton Hill - geograph.org.uk - 1944687 (cropped).jpg from File:Houses on Calton Hill - geograph.org.uk - 1944687.jpg.
.jpg){kind=link}
The latter uses {{Geograph from structured data}}, which has carried over to the new image, where it finds no data and causes warning messages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 18 August 2026 (UTC)
- @Pigsonthewing The original file uses SDC data for its information, and I don't think CropTool will transfer any SDC data to the cropped files. So, you will need to manually, or perhaps use the MoveClaim Tool, to transfer the SDC data over to the cropped file. Thanks. Tvpuppy (talk) 20:57, 18 August 2026 (UTC)