Commons:Village pump

Shortcut: COM:VP

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓

COMMONS DISCUSSION PAGES Commons Help desk Village pump (general discussion) Copyright Proposals Technical Graphics and photography discussion Photography critiques Image improvement Illustration workshop Map workshop Photography workshop Video and sound workshop Categories for discussion Undeletion requests Deletion requests Volunteer Response Team/Noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems (Dispute resolution) Blocks and protections Bureaucrats' noticeboard CheckUser requests Oversight requests Telegram IRC webchat Commons mailing list (archive) Commons' bugs on Phabricator Welcome to the 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/10. Please note: If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias. Have you read our FAQ? For changing the name of a file, see Commons:File renaming. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer). Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam. Purposes which do not meet the scope of this page: Please do not make deletion requests here: use the relevant process for it instead. For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump. To ask for image improvement, see: Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. To ask for video or audio improvement, see Commons:Graphic Lab/Video and sound workshop. For translation requests, please post at Commons:Requests for translation. For media requests, please post at Commons:File requests. For questions about copyright, technical matters, or help that does not relate to the general Commons community as well as proposals, please see the other discussion boards linked in the blue panel at the top. Search archives:     Start a new discussion

Legend
In the last hour
In the last day
In the last week
In the last month
More than one month
Manual settings
When exceptions occur, please check the setting first.

Turkey Beypazarı district Hırkatepe Village pump. [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive Restrict non-confirmed users of all wikis from crosswiki-uploading files to Commons (29 October 2026) Policy update for Renaming of Pdf and DjVu files (14 August 2026) Policy update for AI content (23 June 2026) Template: View   ■ Discuss    ■ Edit   ■ Watch

	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.

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)

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:

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)

This does not need a bot and does not need to edit no file, because the categorization is already made by a template on these same files , File:Death rate smoking, World, 1991.svg is in Category:Maps showing 1991 and that category is not written in its wikitext, it comes from {{Map showing old data}}, which is unprotected, I checked it today, and transcluded on 1,374,067 files, so the template can read the page name and emit the right category alone and the job queue does the rest. I have made the test with #invoke:String|match through action=parse and the names give what they should, World and 1991, North America and 1764, Africa and 1021, and no match for a file outside this corpus, but there is a trap, the covid files like ,Covid cases, Europe, Dec 11, 2020.svg, return Dec 11 as the region and there are more than half a million of them, so it needs a guard that the year in the name is equal to the |year= parameter, which kills them because they carry year=2020-12-11. And there is a second thing that worries me more than the first one, the bot request says to work over the files of Category:Our World in Data maps of Asia, which has 72,558 files, while there are 190,443 files that carry the template and have Asia in the name, and two that I took at random, File:Sugar cane yields, Asia, 1991.svg and File:Tomato yields, Asia, 1961.svg, are not in that category, so if a bot runs as it is asked in first place it does only a part of the work and everybody believes it is finished. I do not propose to save this directly, editing a template on 1.37 million pages queues 1.37 million link updates and the community has to agree before, so I can put the tested code in Template:Map showing old data/sandbox and somebody who knows this corpus better than me confirms the region names. @Enyavar, Reinhard Müller, Doc James, Prototyperspective, and Universalis: Wilfredor (talk) 18:38, 10 September 2026 (UTC)

October 25

Why the extra level of categorization?

I'm not sure if there's a better place to ask this. The standard for road categories such as Category:Florida State Road 417 seems to be to create a subcat Category:Road signs related to Florida State Road 417 which contains Category:Road signs along Florida State Road 417 and Category:Road signs for Florida State Road 417 along other roads. The 'related' category seems to me like a needless extra level of categorization; the two latter cats could simply be under Category:Florida State Road 417. Other examples: Category:Road signs related to New Jersey Route 21 (also contains this extra level per county), Category:Road signs related to Interstate 5 in California, Category:Road signs related to Georgia State Route 400. Can anyone think of a good reason that these exist? NE2 (talk) 16:18, 25 October 2026 (UTC)

Some people just take COM:DIFFUSE too seriously. No idea how this specific categorization appeared though. Ymblanter (talk) 16:35, 25 October 2026 (UTC)

I hope my suggestion isn't considered rude. I'm afraid the main reason for this: it's easy. It's easy to categorize obvious photos depicting simple physical stuff like roads, well known buildings, etc. I think this type of depth of categorization only benefits LLM training in this case. There are other categories that could use thoughtful work on category tree, and adding multiple categories per image. Like Category:Cooking, Category:Rice, Category:Cosmetics, Category:Nutrition, Category:Hygiene, but these need many unobvious decisions. Tupungato (talk) 18:44, 25 October 2026 (UTC)

The middle level here is useless. One more example of some people who do categories being overly driven by ontology rather than by what an end user might find useful. - Jmabel ! talk 20:44, 25 October 2026 (UTC)

Surprised I wasn't tagged in this discussion as I've made a lot of these categories. I was just following what I saw others had going on by continuing the 'related' category. I didn't know it was controversial. Mjrmtg (talk) 21:07, 25 October 2026 (UTC)

I didn't know it was controversial either, and figured you were just going on what others had done. --NE2 (talk) 22:44, 25 October 2026 (UTC)

@Famartin: I think I followed your example in creating categories of "Road signs related to road xxxx" categories. Any thoughts on this subject? Mjrmtg (talk) 23:28, 25 October 2026 (UTC)

It was useful for road categories that I was flooding with photos. The ones which weren’t sign focused go in the main. If the road isn’t highly covered then it’s probably not necessary. Famartin (talk) 23:41, 25 October 2026 (UTC)

The question isn't about the existence of subcategories for signs. The question is why Category:Road signs related to New Jersey Route 19 exists rather than just Category:Road signs along New Jersey Route 19 and Category:Road signs for New Jersey Route 19 along other roads. --NE2 (talk) 23:44, 25 October 2026 (UTC)

Yeah I just realized, see new reply. Famartin (talk) 23:49, 25 October 2026 (UTC)

Oh, I just started at the top of this thread, so let me answer again now that I understand the question better. The reason was to keep the signs related to said road in a single main category. It seemed reasonable at the time, rather than two separate ones in the main. Then those “related to” cats could be grouped in the “signs by road” categories. Famartin (talk) 23:48, 25 October 2026 (UTC)

@Famartin: how does this help the end user? - Jmabel ! talk 04:56, 26 October 2026 (UTC)

I don’t understand the question. How does any categorization help the end user? If you want to search signs by road. Famartin (talk) 11:48, 26 October 2026 (UTC)

@Famartin: and how would that be any harder if the two subcats were both directly in the category for that road? You have to navigate down to those to find any actual signs, whether the intervening category is there or not. - Jmabel ! talk 01:23, 27 October 2026 (UTC)

I suppose it wouldn’t be. But to clarify, it sounds like you are suggesting putting the individual subcats (“road signs along” and “road signs for”) in the main relevant road category, while maintaining the “road signs related to” cats for the higher level “road signs by road” categories. I can’t necessarily argue against that, though I can see someone coming along and seeing the reference to the road in the “road signs related to” category and then adding the relevant road category back in.

Before I go on I do want to make sure everyone understands why those two subcats (“road signs along” and “road signs for”) exist. If not I’ll explain, but I won’t waste space unless requested. Famartin (talk) 02:54, 27 October 2026 (UTC)

I think the question is why does the "relevant" category exist. Why do we group the (“road signs along” and “road signs for”) into the "relevant" category. Mjrmtg (talk) 15:36, 27 October 2026 (UTC)

@Mjrmtg I answered that already. (the "signs by road" category). Famartin (talk) 17:05, 27 October 2026 (UTC)

it sounds like you are suggesting putting the individual subcats (“road signs along” and “road signs for”) in the main relevant road category, while maintaining the “road signs related to” cats for the higher level “road signs by road” categories. I can't speak for what anyone else is suggesting but I am suggesting getting rid of "road signs related to" entirely, and placing "Road signs along" and "Road signs for … along other roads" directly in the category for the road. A category that will only ever contain two other categories is a liability. - Jmabel ! talk 17:35, 27 October 2026 (UTC)

@Jmabel Grouping them together still serves a purpose, and they can include at least one additional category in some instances (route shields for said route), so I would generally disagree. But I'm mostly retired from the road-related material of Wikimedia (at least compared to the large quantities I added 2014-2024), so if there's consensus to bag it, I'll cover my eyes to this matter which I don't participate greatly in any longer. I was just doing what worked for me at the time. Famartin (talk) 17:55, 27 October 2026 (UTC)

@Famartin: still serves a purpose: what is that purpose? - Jmabel ! talk 18:11, 27 October 2026 (UTC)

@Jmabel… I’ve already answered that question above. Please reread my comments. Famartin (talk) 18:25, 27 October 2026 (UTC)

@Jmabel... to help you I'll quote myself: "those “related to” cats could be grouped in the “signs by road” categories" (which they are, at least those I've created. Don't know about what others have done). If you are on some sort of mission to make me agree that they don't serve a purpose, then you're barking up the wrong tree. I've been holding back on this one, but I'm gonna say it now: Why are you here in this conversation? Other than your admin status, you seem to have no purpose since road-related content does not appear to be an area you contribute in. Famartin (talk) 18:30, 27 October 2026 (UTC)

So split the current "signs by road" categories into "signs along road" and "road signs for" categories. Have two metacats rather than one at each level we currently have a "signs by road" category, rather than an extra layer of category for each road. Slightly less convenient for editors, but more convenient for end users. - Jmabel ! talk 18:42, 27 October 2026 (UTC)

@NE2 @Ymblanter@Tupungato@Jmabel@Mjrmtg A few comments ago I already said that I wasn't going to fight removing them if it was consensus. This matter is distracting me more than I prefer, so from this point, please leave me out of whatever you feel like doing. Have a nice day. *DO NO TAG ME AGAIN*. Famartin (talk) 18:46, 27 October 2026 (UTC)

October 26

Server switch - Your wiki will be read-only for a short time soon

Read this message in another language • Please help translate to your language

The Wikimedia Foundation will switch the traffic between its data centers. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster.

All traffic will switch on 28 October. The switch will start at 15:00 UTC.

Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.

A banner will be displayed on all wikis 30 minutes before this operation happens. This banner will remain visible until the end of the operation. You can contribute to the translation or proofreading of this banner text.

You will be able to read, but not edit, all wikis for a short period of time.

• You will not be able to edit for up to an hour on Wednesday 28 October 2026.
• If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.

Other effects:

• Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
• We expect the code deployments to happen as any other week. However, some case-by-case code freezes could punctually happen if the operation require them afterwards.
• GitLab will be unavailable for about 90 minutes.

This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule.

Please share this information with your community.

Trizek_(WMF) 14:00, 26 October 2026 (UTC)

Seeing odd outages now, including 503 errors inconsistently when replying and failures when uploading. Are these related, just several hours before forecast? --Fæ (talk) 04:22, 28 October 2026 (UTC)

Searching for short file names while patrolling?

I do variety of patrolling activities. One of them recently has been identifying bad file names (as per policy). I thought it would be helpful to be able to find files with exceptionally short names (in certain pattern). I tried regular expressions in search, but it didn't yield expected results. Maybe you can help how to search for files containing the word "nature" or "road" (not necessarily at the beginning of file name) and up to 12 characters in length?--Tupungato (talk) 17:56, 26 October 2026 (UTC)

Query in Quarry. Antti T. Leppänen (talk) 17:25, 27 October 2026 (UTC)

The results seem good, but how to reasonably view the results as thumbnails, preferably workable by Cat-a-Lot? My only quick idea is adding all results to some sort of sandbox category (I'm not sure whether this is accepted?), work from the category, then remove the category.--Tupungato (talk) 18:39, 27 October 2026 (UTC)

Download the results as HTML, copy the list of filenames and put inside <gallery></gallery> in your user subpage, like here. Then you can select each file for Cat-a-Lot by clicking below it. Antti T. Leppänen (talk) 17:32, 28 October 2026 (UTC)

See also COM:User categories. - Jmabel ! talk 03:57, 29 October 2026 (UTC)

Crop Tool working again

Crop Tool is working again; plaudits to User:1Veertje for the patch. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:45, 26 October 2026 (UTC)

• Also working is https://ocr.wmcloud.org/ even though I will now use ChatGPT now for OCR, since it recognizes columns of text automatically. --RAN (talk) 03:11, 27 October 2026 (UTC)

The patch was unrelated, it was just waiting for the buildserver to become available again Bawolff (talk) 18:42, 31 October 2026 (UTC)

October 27

Culture of...

I've been having disagreements with User:Hmains over the use of "Culture of..." categories (and some others, but this is the one that just came to a head), and I don't think we are going to be able to resolve it ourselves, so I'm coming here to get other opinions. I want to make it clear, this is not a personal issue about Hmains, it is an issue about the use of such categories.

I noticed this particular case because Hmains recent edit moved a photo I took, File:Tacoma, WA - Leroy Jewelry clock and neon sign 01.jpg, from Category:Tacoma, Washington to Category:Culture of Tacoma, Washington. (It is also in several other categories, none of them specific to Tacoma).

I don't have a problem with any of the subcats of Category:Culture of Tacoma, Washington, but for most of the individual images there I don't believe that a typical end user looking for any of these would ever think of looking for them in a category related to "culture". I don't see how placing them there (rather than just Category:Tacoma, Washington; I do believe they should be in some category associated with the place they were taken) serves the end user. To my mind, the only one of these images that relates obviously to "culture" is one I just nominated for deletion as a probable copyvio, File:Asymmetrical Symmetry. (27661247940).jpg, which appears to be a photo of presumably copyrighted artwork by Dale Chihuly.)

I'm very concerned with what seems to me to be an near-compulsive diffusion of city/town/etc. categories into broad, ill-defined subcategories, whether the latter make sense for the files in question or not. Poor diffusion is worse than no diffusion. Categorization is not supposed to be an empty exercise in ontology (in this case, very weak ontology); it is supposed to help people find our content. In this case, diffusion of these individual images to this particular category is of no help, and possibly some harm. - Jmabel ! talk 02:47, 27 October 2026 (UTC)

Poor diffusion is worse than no diffusion, I agree. Some of the images that ended in Category:Culture of Tacoma, Washington should rather be in different categories. They'd be better off waiting in main category until someone ends up creating better categories (because typical categories like Shops in Tacoma, Washington don't exist yet). Security cameras, geodesic markers, parcel lockers, street lights, emergency exits don't belong in Culture of Tacoma.--Tupungato (talk) 10:37, 27 October 2026 (UTC)

The concept of diffusion of large categories does not mean that we cannot have bucket categories for convenience. If a location category is being used as a bucket/source category then there's no harm in sub-categories like '19th C. buildings in ...' or 'Protests in ...' holding the same images. This seems a lot better than eating up volunteer time debating the taxonomy philosophy rather than doing more impactful stuff. Fæ (talk) 12:25, 27 October 2026 (UTC)

The issue I think Jmabel is trying to raise here is that files are being moved out of these "bucket categories" and into unintuitive subcategories where they are less likely to be found (e.g. Revision #1292198762). If the category was simply being added, I agree that wouldn't be as much of an issue. Omphalographer (talk) 02:14, 2 November 2026 (UTC)

I agree it's not useful to categorize shop neon sign under "Culture of ...". It could be left in town category, or dumped into "Buildings in ..." if there's need to diffuse it. But it's hard to blame user as this sign is an element of exterior design and Category:Exterior design is categorized under Category:Culture via long chain of parent categories. "Culture" in broadest sense includes anything made by humans so we probably need some sort of guidelines, otherwise many users will naturally run into this issue. I also constantly find that i need some dumping ground for pictures of building exteriors, and end up dumping into "Buildings in ...". But i'm not sure is it better than keeping in town root category. MSDN.WhiteKnight (talk) 08:20, 29 October 2026 (UTC)

I'm not saying it's ontologically wrong: I'm saying that it is a liability to an end user trying to find such a thing. Unless you know Commons categorization very well, it's not a place you'd ever think to look. - Jmabel ! talk 18:49, 29 October 2026 (UTC)

The ontology implied by high-level abstract Commons categories like Category:Culture is, quite frankly, bizarre and incoherent. It should not be taken as a model. Omphalographer (talk) 23:56, 1 November 2026 (UTC)

And now an even more extreme example: Hmains created Category:Culture of Skagit County, Washington to which he added a single file: File:Sign entering Skagit County on Washington State Route 9 northbound.jpg. (1) This has little to do with culture, and most people wouldn't look for it there; (2) why not create a category Category:Signs in Skagit County, Washington? I'd guess we'd have at least half a dozen files to put there, maybe 5 times that, and we have parallel categories for the majority of counties in the state. - Jmabel ! talk 17:43, 27 October 2026 (UTC)

In fact, I see more than half a dozen in Category:Signs in Washington (state) (just ones with "Anacortes" or "Concrete" in their file names; I'm sure there are more). - Jmabel ! talk 17:58, 27 October 2026 (UTC)

@Hmains: could you please have a look at the above? My issue here came out of a disagreement we had, and you have not commented here at all. - Jmabel ! talk 06:51, 1 November 2026 (UTC)

This was the first time/place I heard about anything wrong with my culture categoriztion. And certainly the first time I read that editors must not place images directly in a culture category without first seeing or creating a sub-category. I thought that categorizaiton was an iterative process. An editor does the best they can based on what they know or see in Commons, to be followed by others who do the same, and that nothing is fixed in place from original or subsequent edits. Certainly no requirment that an editor must always create sub-categories here or do a different edit altogether, in anticipation that a different editor might choose to do so. So I am quit baffeled about what do to here. Thanks Hmains (talk) 17:39, 1 November 2026 (UTC)

The problem is: this isn't a rules-based thing, it's a matter of thinking about the actual purpose of things. Any time you change categories in a way that involves removal of categories, you have to think about "Does this make it easier or harder for an intelligent person with no specialized knowledge of Commons categorization to find this if it's what they are looking for?"

On one particular issue here: I'll create Category:Signs in Skagit County, Washington, since it would clearly be useful. - Jmabel ! talk 17:59, 1 November 2026 (UTC)

The purpose of Commons categorization is to aid reader in their search for images? And this is what I do. We obviously have differeren ideas on how readers use Commons. I don't see where there is a standard that editors must think a particular way or else suffer. Hmains (talk) 21:55, 1 November 2026 (UTC)

@Hmains: a good number of experienced editors have weighed in here, and unless I'm missing something they have all more or less agreed with me, with some slight shadings of opinion. I would think that would at least give you pause. If it were the other way around, it would certainly give me pause. - Jmabel ! talk 07:25, 2 November 2026 (UTC)

It does. I will be more careful. I hope you will continue to help me with your notices to me. Thanks.Hmains (talk)

Low quality photographs of the Moon

What are your thoughts on low (or lowish) quality photographs of the Moon? I mostly mean photos taken from Earth with devices like mobile phone, where Moon is less than 5% of the crop. Are they needed at all (especially photos of the type "white smudgy dot against black background")? And if they shouldn't be removed, would it be reasonable to create separate category/categories? There is a big category Category:Photographs of the Moon, currently 1,294 images. Some of the images might be diffused into country categories, but I'm thinking maybe it's better to move them to some catch-all category like "Remote photographs of the Moon" or "Wide angle photographs of the Moon"? Examples of photos I'm talking about:

Small Moons

• 
  File:Luna llena en Armenia (14645050729).jpg
• 
  File:Luna24.JPG
• 
  File:Lune de l'esturgeon en août 2022 (2).jpg
• 
  File:Moon (196851361).jpeg
• 
  File:Moon - panoramio (8).jpg

--Tupungato (talk) 09:30, 27 October 2026 (UTC)

For me „remote“ means only „taken from distance“, which would apply to almost all moon images 🌙 --PantheraLeo1359531 😺 (talk) 18:09, 27 October 2026 (UTC)

…except those taken by astronauts or rovers on (or approaching, or leaving) the surface of the moon.

Yeah, for pictures of the moon, "remote" is the default. - Jmabel ! talk 18:14, 27 October 2026 (UTC)

That's why I suggested "Wide angle photographs of the Moon" as well (and I'm open to alternatives). But what do you think about the concept of such category?--Tupungato (talk) 18:31, 27 October 2026 (UTC)

 Support Ja :3 --PantheraLeo1359531 😺 (talk) 18:39, 27 October 2026 (UTC)

By phase seems the most prominent criterion by which to diffuse, but 1300 photos is less than I expected, although there are already subcats. Arlo James Barnes 20:19, 27 October 2026 (UTC)

A lot of the "white smudgy dot against black background" type photos should probably be deleted. This is an extremely common photographic subject, so we can afford to be selective. (I'd also suggest that we only use by-country subcategories when terrestrial objects are visible - otherwise, we end up with photos like File:Full Moon (45552566161).jpg getting buried in these subcategories where they're unlikely to be found.) Omphalographer (talk) 20:24, 27 October 2026 (UTC)

I created a Deletion Request for 92 bad quality moons: Commons:Deletion requests/Low quality images of the Moon --Tupungato (talk) 08:57, 28 October 2026 (UTC)

Noted on my talk page, but the nominations failed to notify which files were relevant to the user being notified. Apparently I uploaded at least one of these, but I have no context and nobody wants to click on 92 photographs to find out. Fæ (talk) 10:27, 28 October 2026 (UTC)

How to know which is the 150 millionth file?

I noticed the number of upload files in Commons is approaching 150 million, and I wondered how would we know which file it is? I know there must be some way since I found this image File:DW 188 Smolnica.jpg had been indicated as the 100 millionth file back in 2023. Does anyone know what method was used back then? Thanks. Tvpuppy (talk) 10:39, 27 October 2026 (UTC)

Do these stats account for deleted files? Tupungato (talk) 11:55, 27 October 2026 (UTC)

This is in practice a political decision. There are many reasons why the specific image at that precise upload count is fuzzy and if you go through the VP archives, there have been long discussions as to why. I upload around 2,000 large educational files a day, using a laptop and home internet, so putting in a bid to get the badge! Fæ (talk) 12:30, 27 October 2026 (UTC)

Now that has me wondering what the 100 millionth was. Zatoicy (talk) 14:35, 27 October 2026 (UTC)

100,000,000th File:DW 188 Smolnica.jpg. Shall we say, not the most interesting photo? Fæ (talk) 15:01, 27 October 2026 (UTC)

Could have been worse if it turned out to be a random mediocre Panoramio or Flickr import. Anyway, I'm somewhat surprised this file has almost no usage.--Tupungato (talk) 15:53, 27 October 2026 (UTC)

We are past the milestone. Congratulations! Tupungato (talk) 12:34, 27 October 2026 (UTC)

Clearly we got old. We're not even excited about such round numbers any more. :-) Nemo 19:32, 28 October 2026 (UTC)

Journal PDF Upload Question

Can the PDFs of the four issues of a journal published in Hong Kong in 1872 and 1873 be uploaded? Its editor, Nicholas Belfeld Dennys, died in 1900, and the identities of many of its authors (who, judging from their wording habits, appear to have been mostly British) are unknown. According to Template:PD-HK, the period of 50 years from the end of the calendar year in which the author dies has ended, or if the work is of unknown authorship (unless the identity of the author becomes known), then the period of 50 years from the end of the calendar year in which the work was first made (or, if made available to the public, the period from the end of the calendar year in which it was first so made available) has ended, and the work has entered the public domain. SKBNK (talk) 16:44, 27 October 2026 (UTC)

@SKBNK: I would think that is safely {{PD-old-assumed}} {{PD-US-expired}}. - Jmabel ! talk 17:45, 27 October 2026 (UTC)

It's mathematically "almost certain" to be public domain. However for wikilawyers among us, there are some caveats. It is a joint publication so in theory the death dates of every contributor would need to be worked out, which is often impossible. If any author died at an extremely old age, the life+50 rule should be considered as, say, if someone lived to 120 (this is a good rule of thumb) and published in 1872 when they were 18, then copyright expired in 2024. We would count that as 99.99% public domain? If published posthumously then the copyright clock started on the publication date, which should be 100% PD I guess. Any modern additions to the text, or transcriptions/translations may add different copyright.

For millions of uploads of books in my projects, 1875 is extremely safe as a default mass upload cut-off date and 1895 is extremely safe for most countries. If I stick to that I can upload a million books and only a handful will ever be challenged. In some countries dates like 1944 can be a safe cut off. If in doubt navigate through COM:CRT.

Conclusion, go ahead and upload, nobody is going to get upset if it turns out it's a massively unlikely copyright issue. Fæ (talk) 19:53, 27 October 2026 (UTC)

This is exactly why we have {{PD-old-assumed}}. - Jmabel ! talk 02:02, 28 October 2026 (UTC)

Yes, though that template is not based on a RFC, instead Michael closed the VP discussion it is based on recommending this have more work and there be a 'range of guidelines'. No doubt I have used the assumed template, but it's not normal for my mass uploads because it's a bit fuzzy in interpretation. Note I commented in that discussion in 2017. (Though to be fair, I have absolutely no memory of it.) Fæ (talk) 04:04, 28 October 2026 (UTC)

October 28

Russian State Library catalogs

Can someone help me check some Russian State Library catalogs if they can access? I need to confirm three records

• [貴州省少數民族習俗圖冊，附説略] [Рукопись] : [список] : [2册]. - [中國] [Китай], [1732-1797年] [между 1732 и 1797]. [Кн. 1]: [上册] [Рукопись] : [список]. - [中國] [Китай], [1732-1797年] [между 1732 и 1797]. - 85+I [из них 3 чист.] л. : цв. ил.; 37,0 х 25,0 x 4,3 см.
• [貴州省少數民族習俗圖冊，附説略] [Рукопись] : [список] : [2册]. - [中國] [Китай], [1732-1797年] [между 1732 и 1797]. [Кн. 2]: [下册] [Рукопись] : [список]. - [中國] [Китай], [1732-1797年] [между 1732 и 1797]. - 85+I [из них 3 чист.] л. : цв. ил.; 37,0 х 25,0 x 4,3 см.
• Китай. - 惠州府潮州府圖 = 惠州府湖州府圖 [Рукопись] : [список]. - [中國] [Китай], [1804-1857年間] [между 1804 и 1857]. - 73+IV [из них 1 чист.] л. : цв.; 34,0 х 31,2 х 2,0 см.

but the site appear down for days. — PacmanD (talk) 00:18, 28 October 2026 (UTC)

Yes, the pages load for me. — Arlo James Barnes 01:08, 28 October 2026 (UTC)

Thank you! PacmanD (talk) 04:03, 28 October 2026 (UTC)

Rather than the site being down you might be experiencing a geo-blocking problem. Using VPN would help in such a case. Nakonana (talk) 18:39, 28 October 2026 (UTC)

Significant change in file pages; is this deliberate?

No more overt listing of available file sizes (or even of what size the file is, unless you go down to look at the File History). "Download" and "Share this File" buttons. No "Add a note" button. Is this a deliberate UI change, something that glitched my settings, or what? Jmabel ! talk 04:57, 28 October 2026 (UTC)

Oh, wait, the file size stuff is there, just farther down the page, after the categories (I use an option that brings up to near the image). Other questions still stand. - Jmabel ! talk 04:59, 28 October 2026 (UTC)

It's a skin thing, apparently nothing changed for Monobook, I didn't spot anything out of the ordinary for me. Regards, Grand-Duc (talk) 06:19, 28 October 2026 (UTC)

Vector (2022) skin and show hidden categories are all I have set, and the filesize is part of the original file details at the top as normal. Fæ (talk) 10:37, 28 October 2026 (UTC)

I'm also Vector (2022). - Jmabel ! talk 15:13, 28 October 2026 (UTC)

I also use the Vector (2022) skin but the Stockphoto gadget still doesn't work. Achmad Rachmani (talk) 15:30, 28 October 2026 (UTC)

It's worth trying a different browser, it's *possible* that there's some CSS tool, autotranslation plug-in or similar that is confusing things. If you have custom scripts here or globally via meta, it may be worth switching those off too. Fæ (talk) 19:06, 28 October 2026 (UTC)

I don't know how to switch off "Download" and "Share this file" buttons using custom scripts. Achmad Rachmani (talk) 05:46, 29 October 2026 (UTC)

@Achmad Rachmani: In your common.js:

button.stockphoto-icon-download {display:none;}
button.stockphoto-icon-share {display:none;}

It would have been nice of them to give the buttons unique IDs rather than rely on a class that someone might reuse elsewhere, but it should still work - Jmabel ! talk 19:22, 29 October 2026 (UTC)

@Jmabel: I created my own common.js but both of these buttons still appear due to unexpected tokens like opening curly bracket. Achmad Rachmani (talk) 22:22, 29 October 2026 (UTC)

@Achmad Rachmani: The common.js looks fine to me; I'm not sure what you mean by "unexpected tokens like opening curly bracket." Could you reword that with more precision? (i.e. where are these tokens; unexpected by whom; if this is part of an error message then from what, and what exactly does it say; etc.) - Jmabel ! talk 05:26, 30 October 2026 (UTC)

@Jmabel: Tokens are in line 1; unexpected by myself; this is part of an error message, therefore it's from column 32, and it says syntax (Peast) and parsing (ESLint) errors; can't replace unexpected symbol with any other. Achmad Rachmani (talk) 08:14, 30 October 2026 (UTC)

@Achmad Rachmani: Weird. I have it in my common.js and it works for me. Maybe someone else can help. Jmabel ! talk 00:55, 31 October 2026 (UTC)

@Jmabel: I created my own common.css by copying content from my own common.js so I can't reuse any files. Achmad Rachmani (talk) 01:56, 31 October 2026 (UTC)

Of course! I'm sorry, I told you to put it in your common.js and I meant common.css. Mea maxima culpa. All good now? - Jmabel ! talk 02:10, 31 October 2026 (UTC)

@Jmabel: Yes, all good now. My common.css was my best solution. Achmad Rachmani (talk) 16:15, 1 November 2026 (UTC)

OpenClimbing aerial photography project for Wikimedia Commons

We are preparing a CEE Hub Rapid Fund application for OpenClimbing, an open-source climbing platform built on Wikimedia Commons and OpenStreetMap.

OpenClimbing contributors have already uploaded more than 1,000 climbing-related images to Wikimedia Commons. We would now like to improve the quality of climbing-wall photography, especially in places where a clear view of the rock face cannot be obtained from the ground because of trees, terrain, rivers, or perspective.

We are proposing to purchase a lightweight drone and use it to create freely licensed photographs of climbing areas for Wikimedia Commons. We plan to contribute at least 100 new high-quality photographs during the grant period and continue using the equipment for further Commons contributions afterwards.

The photographs can also be used for interactive climbing topos. Climbing routes and other structured data are stored in OpenStreetMap, while the source photographs remain openly available on Wikimedia Commons.

We have already experimented with aerial photography and photogrammetry using a borrowed drone, including a textured 3D model of a real climbing wall: https://zbycz.github.io/openclimbing-3d/v2/

Our main focus for this grant is high-quality 2D photography. In the future, once Wikimedia Commons supports textured 3D models, we would also like to explore publishing photogrammetric climbing-wall models there.

The drone would be managed as OpenClimbing project equipment. By arrangement, it would also be available to active OpenClimbing and Wikimedia contributors for similar documentation work, subject to safe and legal operation.

OpenClimbing: https://openclimbing.org

Open-source repository: https://github.com/jvaclavik/openclimbing

Feedback is welcome, especially regarding the use of Wikimedia Commons and the proposed equipment-sharing approach.

Jvaclavik (talk) 08:59, 28 October 2026 (UTC)

Good stuff in your contributions. I can only suggest improving file names, by adding even short description in English. So, instead of Hostivařská skalka - Pravá stěnka.jpeg I would propose Hostivařská skalka - Pravá stěnka (Czech Republic).jpeg or Hostivařská skalka - Pravá stěnka - climbing rock.jpeg, so that there is any English language context in the file name itself. But this is not essential. --Tupungato (talk) 10:17, 28 October 2026 (UTC)

No file by this name exists, but when trying to reupload it is there.

I uploaded File:Κοινοτική βρύση Παναγιάς Πεδιάδος 20251207 0955.jpg but no preview is available an there is a not that No file by this name exists, but you can upload it (it was uploaded via UploadWizard along with File:Κοινοτική βρύση Παναγιάς Πεδιάδος 20251207 0945.jpg which has no issue). I tried to reupload it via UploadWizard and I got a note that the new file is a duplicate of the apparently non existent file. (Apparently the same issue happened to File:DSC 0027 copya.jpg). C messier (talk) 12:58, 28 October 2026 (UTC)

Apparently that was a cache issue. C messier (talk) 16:05, 28 October 2026 (UTC)

File displays fine for me. -- Infrogmation of New Orleans (talk) 16:41, 28 October 2026 (UTC)

October 29

Upload Wizard

Anyone else notice for over a week now, you can no longer "add a specific public domain tag" in the upload wizard? RAN (talk) 02:32, 29 October 2026 (UTC)

Yes. I have been unable to write in the specific template for some reason. I hope this issue is fixed soon. – Howardcorn33 (💬) 07:39, 30 October 2026 (UTC)

I have just noticed this issue also. I hope it is resolved soon. Sp1nd01 (talk) 11:58, 3 November 2026 (UTC)

Requesting community feedback regarding Template:Cities of Morocco

Hello everyone. I'm requesting community feedback, especially more experienced users, on how to proceed with a disagreement concerning Template:Cities of Morocco. I have created the template months ago, and as I anticipated objections to the inclusion of cities and towns located in Western Sahara, I included note ackonwledging the disputed nature of their location (see old version of the template). Unfortunately, @Koavf had other opinions, and proceeded to removing them from the template with the comment "Removing cities not in Morocco". I believe this position is problematic as it is not in line with Commons:NPOV which states that:

It is not the role of Commons to adjudicate on subject-matter disputes

The cities and towns in question are administered by Morocco. It's an undisputable fact, regardless of one's position on the sovereignty dispute or whether one characterizes Morocco's presence as an "occupation". Including them in a navigational template, with an explicit note about their disputed status, does not imply that Commons or Wikimedia recognizes Moroccan sovereignty.

In the discussion page, Koavf made additional comments to justify his objection, some of which I believe were factually incorrect (e.g. that the ICJ stated that Morocco's control over the region was "military occupation", or that the United Nations General Assembly still views it as such). I have responded with links to actual UN resolutions, but I don't want to reproduce the whole discussion here, so please feel free to read it, as well as the content of the links, and draw your own conclusions. In any event, I don't think the UN's position should be the sole determinent on how Commons organizes navigational templates.

In an effort to find compromise, I have made a new proposal for an alternative template format with a separate section for towns located in Western Sahara. Unfortunately, Koavf dismissed this proposal as "bad", without providing substantive feedback or suggesting an alternative.

Given that we have been unable to reach an agreement, and that we already had similar disagreements on other Wikimedia projects, I believe it would be more productive to seek broader community input.

My question to the community is: Would including cities and towns in Moroccan-administered Western Sahara in a separate, explicitly labeled section of this navigational template be consistent with Commons' neutrality policy? Or perhaps the earlier format with an asterix and a note at the bottom? Or is there a better approach that would acknowledge both the territorial dispute and the practical administrative reality?

I would welcome constructive feedback, particularly from editors familiar with Commons policies and the handling of disputed territories in categories and navigational templates.

Best regards! Ideophagous (talk) 07:38, 29 October 2026 (UTC)

You've been around for a few years, so I'm unsure if you have started RFCs. With the existing attempts at resolution this may be better as an RFC. They can also be unsatisfactory and take a long time to get anywhere, but more often they can provide an adequate summary of views and if closed independently those parties most affected can hopefully park the debate.

Commons has a long history of our open Scope itself being the cause of dispute for maps, flags, territories. By definition these are political images and it's not obvious how to host images for all political views or how to categorize them. Sometimes it's okay to create a 'disputed' category or in other cases the qualifier is 'historical' or 'political', the idea being that those words are more accurate for more people than not using them.

If you do follow up with an RFC, get the other parties to provide input to the RFC, but if not, it's helpful to write the RFC in plain English, using highly credible sources, and links to past discussions, without presuming voters will understand anything of the politics or complex issues of sovereignty. Fæ (talk) 08:59, 29 October 2026 (UTC)

Hi! Thanks for the feedback. I have created RFCs on the English Wikipedia, but never on Commons. I will check how RFCs work here, and will proceed with that option soon, assuming the issue doesn't get resolved in the meantime. Ideophagous (talk) 09:19, 29 October 2026 (UTC)

Slight follow up, it can be helpful to tidy up wikidata too. If the associations on wikidata are accurate based on official sources added there, it's "easy" to list out cities this way, and even have wikidata directly populate info boxes in categories on Commons. Before creating an RFC it would be worth quietly auditing if wikidata is up to date and nobody will stop you updating it. Fæ (talk) 09:55, 29 October 2026 (UTC)

Any chance this could be resolved by having a separate listing within the template (separated by a horizontal bar) for "Moroccan-controlled cities in the disputed territory of Western Sahara" or some such? I can certainly see why some would find it offensive to list them simply as "Morocco". - Jmabel ! talk 19:27, 29 October 2026 (UTC)

I don't think we need a navigational box that lists occupied territory like this. If you need a navbox for cities in Western Sahara, just make one. ―Justin (koavf)❤T☮C☺M☯ 20:56, 29 October 2026 (UTC)

That would not reflect NPOV, since Western Sahara is a disputed territory, most of which is administered by Morocco, not a universally recognized independent country. Neither unconditional recognition of Moroccan sovereignty over Western Sahara nor categorical rejection of Morocco's territorial claims represents the full range of international positions. Many governments have adopted more nuanced positions, supporting Morocco's autonomy proposal as a basis for negotiations without formally recognizing Moroccan sovereignty (e.g. France, UK, USA, Israel, Spain (page 372)...). The most recent UN resolution on the matter encouraged negotiations on the basis of Morocco's autonomy plan. Others have explicitly recognized Moroccan sovereignty, while some recognize the Sahrawi Arab Democratic Republic. It would therefore be inappropriate for Commons to treat any one of these positions as an uncontested fact. Ideophagous (talk) 06:14, 30 October 2026 (UTC)

NPOV does not require us to represent every conceivable perspective. If it did, there would be no way to even make a template like this. I'm sure there are some Moorish Science cranks who believe that they are sovereign citizen free men on the land who are members of the Almoravid Empire, so they claim New York City as a part of Morocco or something. Palestine isn't Israel, Crimea isn't Russia, Western Sahara isn't Morocco. ―Justin (koavf)❤T☮C☺M☯ 14:46, 30 October 2026 (UTC)

Comparing the officially documented positions of major governments, including the US and France, to fringe theories is hardly reasonable. Nor is presenting your own preferred interpretation of a disputed territorial status as an unquestionable fact.

The cities in question are administered by Morocco, not by the SADR. That is a verifiable fact, independent of the sovereignty dispute. My proposal explicitly acknowledges that dispute rather than attempting to resolve it. How exactly does including these cities in a separately labeled section violate Commons:NPOV? Ideophagous (talk) 18:27, 30 October 2026 (UTC)

If you read some of the official government statements by Turkmenistan or North Korea or Israel, you will see claims that are equally absurd: being a government does not make what you say reasonable. We should not make listings of cities of occupied territory that insinuates that it is part of the territory of the occupier. ―Justin (koavf)❤T☮C☺M☯ 18:45, 30 October 2026 (UTC)

So are the official positions of France, the UK, the US and Spain, among others (all linked above in official government sources), all equally unreasonable? These are not fringe claims, but documented diplomatic positions held by major governments. You are of course free to disagree with them, but that doesn't make your own interpretation of the territorial dispute an uncontested fact.

More importantly, my proposal explicitly distinguishes cities in Western Sahara from those in undisputed Moroccan territory, and acknowledges their disputed status. How exactly does that constitute an endorsement of Moroccan sovereignty? Ideophagous (talk) 18:59, 30 October 2026 (UTC)

You keep on asking me questions about claims I never made. I didn't say that you were breaking NPOV. I didn't say that I had an uncontested fact. Again, I've asked to give me an example of an uncontested fact and you can't seem to do it. Please stop with these weird irrelevant red herrings that you insert into the conversation to make it seem like I wrote any of the absurd things you are imputing to my argument. If you just respond to what I write instead of something I didn't, we could have a productive conversation. Can't wait for your example of an uncontested fact. I also reject your premise that there are "major" governments who "count" and "minor" ones that I guess don't. ―Justin (koavf)❤T☮C☺M☯ 19:07, 30 October 2026 (UTC)

@Jmabel That's what my last proposal does. Please check it and let me know what you think. Ideophagous (talk) 05:23, 30 October 2026 (UTC)

Looks reasonable to me, but I don't have any particular subject matter expertise. - Jmabel ! talk 05:38, 30 October 2026 (UTC)

Hello @Fæ. The Wikidata entry for Dakhla for example lists both "Morocco" and "Western Sahara" as countries with proper qualifiers, and the same should apply for all settlements within Western Sahara. There have been disputes about this topic on Wikidata over the years (as well as vandalism and POV pushing on both sides of the issue), and the solution was always to keep both as I mentioned (see this talk page for one of the recent discussions, and its continuation on the Administrator's notice board). I haven't checked those objects for a while, but I hope they still reflect consensus. Ideophagous (talk) 05:41, 30 October 2026 (UTC)

Interesting, thank you. As wd has an evolved consensus, that bodes well for here too. Fæ (talk) 10:40, 30 October 2026 (UTC)

You could also just rename the template to „Cities in Morocco and Western Sahara“. Then there is no dispute what is included and what is not. GPSLeo (talk) 06:31, 30 October 2026 (UTC)

That would be fine as well. Ideophagous (talk) 07:19, 30 October 2026 (UTC)

Special license review for unarchivable sources

Should we set up a new license review template/category/etc. specifically for content taken from (currently live) sources which can not be archived properly by major web archival services (eg. Internet Archive, Ghost Archive, Megalodon)? This came to my attention when I was trying to upload this photo taken from Vimeo. Although Megalodon thankfully archived the Vimeo source containing evidence of permission, the former two could not, and I realized that many other sources could also be unarchivable for future license reviewers to verify.

For such cases, could we create a template (akin to {{LicenseReview}}, or perhaps add a parameter to it) indicating that a file's source could not be archived, is at risk of link rot, and thus may require priority in license verification? – Howardcorn33 (💬) 08:35, 29 October 2026 (UTC)

I think this would be a good idea. I just recently had a situation (not relevant to licensing, but highly relevant to sourcing) where for the entire Category:Act Black: Posters from Black American Stage & Screen, the museum radically trimmed back the web page for the show when the show ended, and even appears to have gotten the Web Archive to change their content for the earlier state of the site. In this case there is no licensing issue, because I only uploaded public domain materials, but if there had been, I would now have no evidence. - Jmabel ! talk 19:31, 29 October 2026 (UTC)

Geolocation Cologne in 1951

It would be usefull reconstruct the exact location. A clue are the overhead lines (tram or regional railway).Smiley.toerist (talk) 11:33, 29 October 2026 (UTC)

Can't tell you 100% location, because it was heavily redeveloped. But you can see the railway station edge on the right. 50.94035082134486, 6.96275599259924 is a likely location more or less. --Tupungato (talk) 12:01, 29 October 2026 (UTC)

I suspect the overhead lines are of the Rheinuferbahn. See http://www.bilderbuch-koeln.de/Fotos/altstadt_nord_liniennetzplan_der_kvb_von_1952_streckennetzplan_historisch_50er_jahre_vorortbahn__431271. And it looks like the space by the railway station was used as a bus station.Smiley.toerist (talk) 12:37, 29 October 2026 (UTC)

Structure on the right edge looks like the SW-end of Hohenzollern Bridge. --Raugeier (talk) 12:40, 29 October 2026 (UTC)

The cathedral, the Dom-Hotel (in the background on the left) and the railway bridge (Hohenzollernbrücke indeed, as Raugeier wrote) make the situation pretty clear ... in theory. Practically though, I still cannot really imagine what it looked like in post-war reality. After the construction of Römisch-Germanisches Museum, Museum Ludwig, Philharmonie, and the stairs leading down to the river, the situation has been so much different for 40–50 years by now.

There is a contradiction in the image descriptions. The short caption reads like this:

René Defonseca heeft met zijn vrouw een autorit naar Keulen gemaakt. Op de achtergrond de kathedraal die beschadigd was door de oorlog.

Whereas the extended description says the opposite:

René Defonseca heeft met zijn vrouw (afgebeeld) een autorit naar Keulen gemaakt. Op de achtergrond de kathedraal die niet beschadigd was door de oorlog. (...)

Is resolved. I never understood the need for double description. The first description is copied from the main description by the upload script and never updated.Smiley.toerist (talk) 18:56, 29 October 2026 (UTC)

In any case, this is a most interesting image! It would be good to get more historic images like this. -- Martinus KE (talk) 14:13, 29 October 2026 (UTC)

There are interesting gems in family albums, but you need to dig them out, between the more personal stuff (baby pictures, portrets and the like). There are a lot of the more personal pictures being out of scope for the Commons, but they can be uploaded to geneaological websites for public use (for family searches). A usefull byproduct are some pictures wich can be used in the Commons. In the Geni website, the same picture can be seen in: https://www.geni.com/photo/view?album_type=photos_of_me&id=6000000219307800829&photo_id=6000000228416097870&position=0 Smiley.toerist (talk) 18:56, 29 October 2026 (UTC)

Out-of-date Wikimedia documentation

I just removed a link to File:Illustrating Wikipedia brochure.pdf from an English-Wikipedia help page, because it is badly out-of-date.

Do we have a template and/ or category for such files, to indicate that they are stale? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:33, 29 October 2026 (UTC)

{{Historical}} Fæ (talk) 12:57, 30 October 2026 (UTC)

Join Us in Organizing Wiki Loves Folklore 2027 in Bangladesh!

Hello everyone,

Wiki Loves Folklore is an international media contest held annually on Wikimedia Commons from 1 February to 31 March. The contest aims to document and celebrate the rich cultural diversity and folk traditions of communities around the world. We would love to organize Wiki Loves Folklore in Bangladesh 2027 and invite interested Wikimedians and volunteers from Bangladesh to join us in making it a success! We are looking for volunteers who would like to contribute to the following activities:

• Reviewing uploads and helping maintain their quality
• Supporting the jury process
• Categorizing media files on Wikimedia Commons
• Writing and improving file descriptions

If you are interested in volunteering or helping coordinate the contest in Bangladesh, please reach out to me via email using this user’s email functionality. Let’s work together to document, preserve, and share Bangladesh’s rich folklore and cultural heritage with the world! Thank you, and looking forward to collaborating with you all.

– Nokib Sarkar (talk) 15:44, 29 October 2026 (UTC)

October 30

Policy for AI content: Vote for consolidated policy text

All five scopes in the Commons:Requests for comment/Policy update for AI content got a clear majority of votes. Please vote on the consolidated policy text here. GPSLeo (talk) 17:33, 30 October 2026 (UTC)

Main subject at Category:Unidentified automobiles in the United Kingdom

So a couple of days ago I removed Category:Unidentified automobiles in the United Kingdom from the images below as the vehicles in those images aren't the main subjects, @Pigsonthewing: very much disagreed with this, @Andy Dingley: replied saying there was no such requirement

So I'd like to ask the community if the vehicles below should be identified or not?

I believe the main subjects for these images are the streets themselves and not every intricate detail in them, Thanks, --–Davey2010^Talk 23:41, 30 October 2026 (UTC)

Gallery view

--Fæ (talk) 09:52, 31 October 2026 (UTC)

Feedback

Fully agreed. "Unidentified" categories are maintenance categories for files where it is important that something be identified, and where it is feasible for someone to do so. They should not be used for objects which are clearly incidental, or ones which cannot practically be identified. The cars in a photo like File:John Ball Birmingham City Centre walk 6 - 1960s - 33.jpg would be quite difficult to identify - most of them are only partially visible and/or are very small, and the photo would not be a useful addition to categories for the specific models. Omphalographer (talk) 04:36, 31 October 2026 (UTC)

And in other cases, while the vehicles are not the main subject, neither are they incidental. At worst, they are secondary and can still be identified (relatively easily, by someone with the requisite knowledge), and usefully so.

In some cases, we may have no other contemporary image of the vehicle in everyday use, as opposed to in preservation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:02, 31 October 2026 (UTC)

In some images I've randomly clicked the cars were indeed very prominent (whether intentionally or not). They were in or close to the foreground and took up chunk of image space. In those cases I'd definitely also put them in identification categories.

However, in some other images I've clicked, the cars were very small and blurry so that I don't think that it would be realistic to identify them.

It's a case by case decision. Nakonana (talk) 13:59, 31 October 2026 (UTC)

With regards to "incidental": I'm thinking of some other images I've seen in "unidentified" categories where the unidentified object was truly incidental. One example I encountered while looking into these images was File:Wasdag in Mali (Afrika) gewassen kleren liggen te drogen, Bestanddeelnr 916-7570.jpg, which was previously in Category:Unidentified automobiles from 1960s because a few cars were barely visible in the background of a photo of people washing clothes by a river. Not only is there no realistic hope of identifying those blurry car-shaped blobs, but they are essentially irrelevant to the photo. No use of the photo would ever need to know what those cars were. Omphalographer (talk) 17:23, 31 October 2026 (UTC)

 Comment this would be much clearer with a gallery element than with a list of filenames. I, for one, am certainly not going to click in on dozens of files to make a judgement. - Jmabel ! talk 01:01, 31 October 2026 (UTC)

My apologies Jmabel, I have a lot going on IRL and simply didn't think of a gallery, Fae has very kindly created one, Thanks, --–Davey2010^Talk 10:40, 31 October 2026 (UTC)

• As he did in the discussion on his talk page, Davey2010 continues to either misunderstand or to misrepresent the issue at hand. That the vehicles are not the main subject of the images in question is not in dispute. The issue is that he believes that only images where the vehicle is the main subject should be categorised as "unknown vehicle", and I have said there is no such requirement for a vehicle to be the main subject in order for that category to be applied. I asked Davey2010 for evidence of a consensus to the contrary, and he has provided none. I have asked him twice to revert his edits, he has not yet done so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:58, 31 October 2026 (UTC)

  I mean I did say to you right at the very start I'd start a discussion at COM:TALK to seek other people's opinions so why you're going down the personal attack route and "I have asked him twice to revert his edits, he has not yet done so" route I'll never know, I would respectfully ask that you allow people to have their say without bludgeoning every reply here, I've made my point that I don't believe every car in a street needs categorising and you very much disagree with that.... So let others have their say. –Davey2010^Talk 14:30, 31 October 2026 (UTC)

  You did not. At the very start, your response, in full, was "I disagree; the main subject here are the streets themselves, There's no close-ups of the vehicles that we can say 'Yes that's clearly the main subject here'"

  Only after I subsequently challenged your dependence on the "main subject of the image", and asked you to provide evidence of a discussion where consensus for such a requirement was reached (none was forthcoming), did you offer to start this discussion.

  I'm not sure where you're seeing personal attacks; there are none in any of my posts; nor have I "bludgeoned every reply", so please get the beam out of your own eye.

  My statement was (and remains) correct: you have still not reverted the challenged edits. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:04, 31 October 2026 (UTC)

  Fair point but either way a discussion was initiated was it not ? Why would I revert when I've initiated a discussion here though?

  You have bludgeoned every reply here, Correct and until this discussion is resolved and consensus formed I shan't be reverting myself,

  You're a very hostile guy - you should probably work on that. –Davey2010^Talk 22:18, 31 October 2026 (UTC)

  You have bludgeoned every reply here-Retract that falsehood. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:52, 31 October 2026 (UTC)

  Why? You've just demonstrated it. Andy Dingley (talk) 23:22, 31 October 2026 (UTC)

  Other than my own, and yours, there have been ten replies in this section; I have posted replies to five of them, not ten, and none of my replies are "bludgeoning".

  BTW, "you very much disagree with [not every car in a street needs categorising]" is also a lie. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:41, 1 November 2026 (UTC)

  Your constant bludgeoning is not limited to per-post responses. By your choice of phrasing, setting things in terms of 'that is a lie' you are personalising something that should be an obviously objective decision and trying to turn it into a popularity contest between you and Davey. This is not an unusual tactic for you, you have done it for years. Which is strange, as it never seems to work out for you. Andy Dingley (talk) 13:14, 1 November 2026 (UTC)

I kinda agree with both sides. On one hand, it might be useful to have the cars identified, at least in some of the images where they can be considered secondary subject (not incidental). On the other hand, this clutters maintenance category where main task is to identify and categorize subjects in images with no description or poor description. There are probably hundreds of thousands of photos of UK streets featuring unidentified automobiles. Should they all be identified? Should we attempt to identify all tree species on images of city streets, where the tree is distinctly visible? --Tupungato (talk) 13:40, 31 October 2026 (UTC)

False comparison: Not all trees can be visually idetified in the way that automobiles can. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:01, 31 October 2026 (UTC)

Thanks to Fae for making this possible to skim.

In my view: a mixed bag. For some of these, any identification of a car would be incidental, but for some it would be relevant: e.g.

• 
• 

These were presumably not at all intended as photos of vehicles, but they can usefully serve that purpose, or be cropped to serve that purpose.

Also: the farther back in time we go, the fewer photos we tend to have of any particular vehicle, so I'd be much more interested in identification on these than in an equivalent contemporary photo. - Jmabel ! talk 19:28, 31 October 2026 (UTC)

Neither of those are of any use as images of the vehicle. We have much better, of both. The first has some use for showing this less well-known vehicle (they were a rusty piece of junk and almost all scrapped within a few years) at use in its day. The second is one of the most common and easily recognised UK vehicles, to this day. It was ubiquitous for decades and adding a specific identification of it is thus of pointless value.

Also, you're a bit late to talk about categorization on these two. It was done days ago. Andy Dingley (talk) 13:18, 1 November 2026 (UTC)

You categorised File:John Ball Birmingham City Centre walk 7 - 1960s - 02.jpg after it was removed from the "unidentified vehicles" category in question, showing that its removal from that category was wrong.

The vehicles in File:John Ball Birmingham City Centre walk 6 - 1960s - 31.jpg remain unidentified; which is why Davey2010 should revert his edit as requested (and why he should have done so the first time he was asked to do so). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:07, 1 November 2026 (UTC)

@Andy Dingley: Presumably these were here as examples of an issue, rather than because these particular files are terribly important. - Jmabel ! talk 18:03, 1 November 2026 (UTC)

?? You're the one who chose them.

These photos (as all but one seem to agree) are of street scenes where the cars are a very much secondary topic. It is not worth putting them into some already overloaded workflow of 'things that must be identified'. We seem agreed on that. There are a handful of them where the vehicle does happen to be sufficiently central and visible, and also perhaps not quite so mundane, as to be worth identifying. By chance, you seem to have picked out two images where one of them had such an image. Everyone is, of course, welcome to ID the other one too, but I'm not going to bother. Andy Dingley (talk) 18:29, 1 November 2026 (UTC)

On the off chance that you are not deliberately misreading me, I meant the original set of photos. I picked out two examples that looked to me like the sort of thing where I would not have removed the "unidentified automobiles" category. I did not look through to what is there current status, because that wasn't the question being asked. - Jmabel ! talk 07:30, 2 November 2026 (UTC)

My mistake, I thought you were referring to the two directly above.

If there are any photos in the large set that justify 'unidentified automobiles', then by all means add that. I don't see any real disagreement over any of this.

I can't see any that do justify it. The right-hand of the two above is (as noted) just too poor a photo of too common an example to be worth adding the category to it. It bloats the set of many images we already have with another one that adds nothing. The one on the left (and a whole bunch of others) doesn't need it, because I already identified the subjects days ago and went past this 'tag them as unidentified, make it someone else's problem, then walk away congratulating oneself for being such a valuable Wikipedian' to do it right instead. If I missed any that anyone else feels are still worth it, then feel free. Andy Dingley (talk) 16:30, 2 November 2026 (UTC)

• Can we clarify here, is this a question about inclusion criteria for when a topic is worthy of categorization, or is it to keelhaul Davey for his lèse-majesté of the mighty Andy Mabbett? Because if it's the first, we're done here. Sensible people have all been largely in agreement and we're good to go. Andy Dingley (talk) 13:14, 1 November 2026 (UTC)

October 31

Geogroup wikimap (toolforge) running very slow

Geogroup wikimap (toolforge) has for the last few days been running very slow; files added to or removed from a category are not added to or removed from the category's map for a couple of hours or more. Until this started, the change in the map was effectively instantaneous. When using the map to find files for recategorising, this slows down the work drastically. Anyone know if the map can be speeded up again, please? - MPF (talk) 00:36, 31 October 2026 (UTC)

Yesterday, it didn't even work at all --PantheraLeo1359531 😺 (talk) 09:33, 31 October 2026 (UTC)

Please add links. —TheDJ (talk • contribs) 15:01, 31 October 2026 (UTC)

Distinction between cosplay and impersonation for categorization purposes

Right now, we categorize impersonation of real people separately from (or as subcategory in some configuration of) cosplay of real people. The distinction between these two things isn't clear to me, and I'm tempted to say that there simply isn't one, or at least nothing meaningful enough that we can judge just by a picture. However, I'm not actually sure myself on how this should be resolved. I wouldn't be opposed to all "Cosplay of [person]" categories being redirected/renamed to "[person] impersonators", with Category:Impersonators being filed under Category:Cosplay, potentially. But, I want to hear thoughts from other people before moving forward since I'm not really sure. Thanks yall. OmegaFallon (talk) 18:52, 31 October 2026 (UTC)

Also, related: the term "cosplay" seems to me very dubious for anything earlier than about 1990s (maybe a little earlier in a specifically fandom context). It might just be because I'm old, but to me it implies something part of or downstream of sci fi / fandom culture. Someone wearing a Nixon mask in 1973 is not, to me, "cosplay". - Jmabel ! talk 19:33, 31 October 2026 (UTC)

My impression is that "cosplay" implies a fictional character. A person dressed up as Luke Skywalker is engaging in "cosplay"; a person dressed up as Elvis is an "Elvis impersonator". (Or we could cut the Gordian knot by describing both as "people wearing Luke Skywalker / Elvis costumes".) Omphalographer (talk) 20:40, 31 October 2026 (UTC)

Topic in country

Looking at Category:Ruins in the United States by state, it's pretty clear something is messed up in Template:Topic in country, but that then leads into some highly iterative further template calls. Can anyone work out what is going on here? - Jmabel ! talk 21:21, 31 October 2026 (UTC)

Managed to track down one of the erroneous cats to Template:Topic_by_country/continent line 72. It appears the issue has something to do with {{Resolve category redirect}}. OmegaFallon (talk) 03:10, 1 November 2026 (UTC)

Scratch that; it's something to do with the {{{prop|}}} {{{countrycont1|}}} {{{byparby|}}} parameters. OmegaFallon (talk) 03:23, 1 November 2026 (UTC)

November 01

SDC description

we need com:sdc properties for descriptions.

in addition to the need for a property for description about what the file shows (which is not the insufficient com:File captions), we also need a property for authors' notes about files. for example, i need to add a note explaining a file's exif time is 1 hour off local time due to dst. that theoretically isnt "description" of what the file is about, but rather detail about the making-of. RoyZuo (talk) 02:49, 1 November 2026 (UTC)

How prominent do people have to be in an image to merit a category?

Hmains recently added Category:People of San Juan County, Washington to File:Moran - Mt. Constitution toward Mt. Pickett.jpg; he and I have been disagreeing a lot lately about categories on my photos, and I don't want this to start getting into edit wars; I'm looking for third opinions here.

This category seems wrong to me on two counts. One is that the people are so incidental in this photo that I wouldn't (and didn't) add a category for people at all. The other is that they are described as being somehow of the largely rural county where this photo was taken. Mount Constitution is basically a tourist destination; the chance that they had any connection to the county beyond visiting it on vacation is slim. If I was going to attach a "people" category to this (which I deliberately had not done) it would have been Category:Tourists in Washington (state).

Thoughts? - Jmabel ! talk 06:59, 1 November 2026 (UTC)

Same as cars. Logical OR union of any of the following:

• Are the people central to the photo? Are they compositionally important to it, as a photo?
• Are the people central to the context of the photo? e.g. Are they monks at a temple, where a scope-focussed view would want us to illustrate the role of those monks in that temple?
• Are the people significant, as people? Would they be photographed in isolation, and would that alone make such a photo important? This can be moderated by how frequently they're photographed otherwise, and by the quality of the representation in each case. Obama is highly notable, Obama visiting East Podunk School is notable (to East Podunk at least), but it's not likely to be an important photo of Obama unless it's somehow exceptional. Andy Dingley (talk) 12:51, 1 November 2026 (UTC)

"It depends": how interesting would it be to study them in that picture?

For example, I include even fairly unprominent sightings of children in WWII photos in the Category:Children in World War II because even if they were just in the huge audience of a military parade, the parade is still something that they got to see and were exposed to, and knowing that would be interesting for a researcher who is studying how children experience times of war, in what aspects of war they are being involved in and in which not, and how aware they might have been of a war that was happening outside their direct vicinity.

In your given example I'm not quite seeing the appeal of studying the depicted people. It looks like tourist at a touristy place. While tourists might be an interesting subject for some researcher specializing in tourism, those particular tourist don't appear to provide much information. They aren't doing anything unusual, they are not traveling in a particular kind of way (~bus tourists, mass tourism) etc., so I'm really not sure what a researcher could learn from that picture. Nakonana (talk) 13:29, 1 November 2026 (UTC)

Agreed on both points. "People of [place]" does not mean any people in that place; it means specific, identifiable people who are from (or strongly associated with) that place. These categories are typically used as parents for categories for individual people, or for photos of notable people who don't have their own categories yet. A category describing the people as "tourists" is far more descriptive and useful, even if it doesn't specify the location as precisely. Omphalographer (talk) 16:23, 1 November 2026 (UTC)

This is the first I heard of any problem with my categorizing ordinary people images at a place. I can stop doing this of course. Thanks all. Hmains (talk) 17:24, 1 November 2026 (UTC)

WRT "People of [place]" does not mean any people in that place; it means specific, identifiable people who are from (or strongly associated with) that place": categories such as Category:People in France are subcategories of Category:People of France. I see nothing wrong hierarchically wise. I think those "strong associations/origin associations" in Commons are managed through "Category:People from..." or even "Category:Births in..." categories, instead of "Category:People of..." ones, which are the broadest. Strakhov (talk) 17:39, 1 November 2026 (UTC)

The sort of "strong association" I'm thinking of is people like Emperor Norton. He was born in London, but lived in San Francisco, California for much of his life and is best known as a (colorful) figure of that city. It would not be reasonable to deny him membership in "people of San Francisco" simply because he was born elsewhere. Omphalographer (talk) 02:25, 2 November 2026 (UTC)

That is a perfectly good reason to categorize him in "People of San Francisco", indeed, unless a more appropiate subcategory is found. Who say he shouldn't? On the other hand he should not be categorized in the subcategory "Category:Births in San Francisco", nor in "Category:People in San Francisco" (that includes depictions of human beings located in San Francisco, since presumably he was not always there). To the extent of my knowledge, "People of" categories are generally understood as people related to in a broad meaning (as the Wikimedia Commons equivalent of Wikidata's P1792). That meaning includes the association between Emperor Norton and San Francisco... and many others. Strakhov (talk) 08:52, 2 November 2026 (UTC)

Sadhguru photo correct date

Time may not be important for some, but here we want have it and correct, incl. Sadhguru. --Mykhal (talk) 19:24, 1 November 2026 (UTC)

It is confusing that the {{Information}} and {{Photograph}} templates do not have separate parameters for the date of creation, date of publication, and date of upload. I hope this may be rectified somehow. – Howardcorn33 (💬) 19:42, 1 November 2026 (UTC)

FWIW, I see no need to keep the upload date in the wikitext. It's in the file history. - Jmabel ! talk 07:51, 2 November 2026 (UTC)

Permissibility of US military documents that were released under a restrictive Distribution Statement

(I don't know if this is the right place to ask about this, but then the copyright village pump doesn't seem like the right place either since all US government works are copyright-free by default. The only prior discussion I've been able to find is one asking whether a restrictive Distribution Statement amounts to a declaration of copyright via the backdoor, with the answer being "No".)

Most US military documents I've encountered are either silent as to security classification, formerly classified documents that were later declassified for public consumption, or released for public consumption by default under Distribution Statement A ("Approved for public release: distribution is unlimited" or some variant thereof). There are, however, various documents in existence which are technically unclassified but were published under a more restrictive Distribution Statement which, depending on the wording, only allows DOD/DOW components, US government agencies in general, and/or US government contractors to access the document (an official list/chart of all such Statements can be found here).

Examples of documents which were published under a restrictive Distribution Statement (typically Distribution Statement C) and are currently uploaded here include:

• All files belonging to Category:United States Army Field Manual 5-250
• File:FM 3-05.70 (FM 21-76) Survival - May 2002.pdf
• File:FM 3-05.20 (FM 31-20) Special Forces Operations - 2001.pdf
• File:TC 18-01 Special Forces Unconventional Warfare - November 2010.pdf
• File:FM 3-05.201 Special Forces Unconventional Warfare Operations - 2003.pdf
• File:FM 3-05 (FM 100-25) Army Special Operations Forces - 2006.pdf
• File:FM-31-20-5-Special-Reconnaissance-Tactics-Techniques-Procedures-For-Special-Forces.pdf
• File:FM-24-19-Radio-Operators-Handbook.pdf
• File:Improvised explosive device defeat -- Fmi3-34-119.pdf

I was going to provide a list of documents that were published under a restrictive Distribution Statement and have yet to be uploaded here, but ultimately I did not so. Suffice it to say that the documents I was going to list were all historical in nature, did not bear any classification statement other than the Distribution Statement, and, for the most part, were later superseded by documents published under Distribution Statement A.

The question I have is whether any current or future uploads are allowed here despite the original documents having been published under a restrictive Distribution Statement. - Dvaderv2 (talk) 20:41, 1 November 2026 (UTC)

@Dvaderv2: Clearly this would be a non-copyright restriction, and it is not a personal privacy restriction or any of the other few that Commons normally counts. Are you arguing that we are violating some law by hosting these (if so, precisely what law)? Or are you raising some other issue? That is: on the face of it, I don't see this as violating any of our policies, unless there is a legal issue, and I don't see the legal issue. - Jmabel ! talk 07:55, 2 November 2026 (UTC)

At random I took a closer look at FM 3-05. This has no source on the upload, which is a problem, however the document is available at https://archive.org/details/fm-3-05.201-special-forces-unconventional-warfare-operations-2003. If there's something to be done here, it would be finding reliable sources to quote on the file pages where they are missing. In the example case the DOD made it public, i.e. not leaked from a contractor or a possibly faked document, so there was no reason to withhold it under the distribution level. Per others views, if officially released, there's nothing to discuss here, however if a document has no source it should be questioned, and (rarely) might even be reasonable to delete under COM:PRP.

Qualifying this analysis just because on the internet archive something looks like an official upload, still does not mean it is. In the example the user behind the army upload was armyguy42, someone who runs a youtube channel unconnected to the DoD. For a highly credible permanent release, more research than this is probably needed. Fæ (talk) 12:42, 2 November 2026 (UTC)

How should these AI images be tagged

File:Shannon Dolan, Chargé d'affaires ad interim at the U.S. Embassy in the United Arab Emirates.png

File:Dave Williams, Chargé d'affaires at the U.S. Embassy in Maldives.png

File:Laura Brown, Chargé d'affaires at the U.S. Embassy in Brunei.png

The images above are AI, I'm certain of this because the metadata contains this "Actions Software Agent Name : gpt-image" and some other indicators that the images were generated/modified with AI. I haven't generated these myself, these are official portraits that came directly from U.S. embassy sites. File:Jonathan P. Howard, U.S. Chargé d'affaires ad interim in the Office of Sudan Affairs.jpg and File:Neil Hop, Chargé d'affaires for the U.S. Mission to Yemen.jpg were also clearly generated/modified by AI, but that information doesn't seem to be present in the metadata. COM:AIIP says that altered images must have a link to the original, but I can't find the original image on any of these sites, I also don't know if the alteration was upscaling or editing something in the image. To me it's more likely that the images were upscaled. In this case, would it be safe to assume the images were upscaled and tag the photo with {{AI upscaled}} or since there's no evidence of an original image, treat them like they were wholly generated with AI? Streetr4 (talk) 21:26, 1 November 2026 (UTC)

You could reach out to the embassy's press contact and explain the issues. Maybe they could dig up the originals? JayCubby (talk) 20:52, 2 November 2026 (UTC)

November 02

Some duplicates

I’d like to point out two users who have uploaded some duplicates; you can decide which images to keep.

• https://commons.wikimedia.org/wiki/Special:ListFiles/Devo_Vagabond
• https://commons.wikimedia.org/wiki/Special:ListFiles/Jacqke

Micione (talk) 01:18, 2 November 2026 (UTC)

November 03

Conflicting licenses

Is this a good edit? I've seen images that have different licenses for different elements of the image, but this image is just a screenshot that hasn't added anything on top of the Wikipedia screenshot. I'm heavily leaning towards this being a good edit but I want to verify before I remove other conflicting licenses on images in Category:All Wikimedia screenshots. Streetr4 (talk) 16:43, 3 November 2026 (UTC)