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.

Water pump in the village of Jestřebice, Czech Republic. [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive Proposal to promote COM:TAIV as policy (8 September 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)

September 20

Are galleries still useful?

From time to time I come across galleries while I'm trying to access the corresponding category. Most of those that I encounter haven't been updated in the last 10 years, if not longer. Are they still useful, or could we consider mass deleting them? Are there any examples of useful galleries that are still being actively maintained? Thanks. Mike Peel (talk) 21:41, 20 September 2026 (UTC)

Mohandas K. Gandhi and John Ruskin may not have been updated recently, but I believe that they are still useful. Yann (talk) 21:43, 20 September 2026 (UTC)

They're showing photos from >70 years ago or so, and they are hiding many photos from the categories (I'd look at Category:Mohandas K. Gandhi by year and Category:Portraits of John Ruskin for most of what those galleries are showing). If the summaries are useful, couldn't we just move them to the top of those categories? Thanks. Mike Peel (talk) 21:48, 20 September 2026 (UTC)

The vast majority are not useful, and never were. Their only real usefulness is in providing a guide to larger categories to aid navigation; even then, galleries on the category page are often better. The Gandhi gallery page is not particularly useful; it seems to be a random collection of image without any clear relevance, and it does not provide subcategory links to help navigate the main category. Pi.1415926535 (talk) 21:59, 20 September 2026 (UTC)

Agree with @Mike Peel, they're pretty useless, as they almost never get updated with new, usually much better, photos. Because wikipedia links to commons are usually to the galleries, it means that wikipedia editors often don't realise there are newer better photos that they're not seeing. They also rarely get updated for inaccuracies (e.g. photos of misidentified organisms, the category usually gets corrected when the photo is re-identified, but any gallery page use frequently doesn't). So they are not just superfluous, but are also actively harmful. Delete the lot, particularly for categories where new photos are regularly being added (e.g. plant and animal species, places, etc.). @Yann's examples of deceased people (where there are not going to be new photos) are the only cases where galleries could remain useful. - MPF (talk) 22:59, 20 September 2026 (UTC)

I hadn't seen the "gallery on the category page" pattern before - and I like it. Perhaps we should experiment with applying that to more gallery pages? Omphalographer (talk) 23:09, 20 September 2026 (UTC)

They're certainly not for every scenario, but I agree they certainly could work on more categories. Two caveats:

• They work best when there's a clear division into subcategories for which a single image is useful for identification or finding a relevant file. Two good examples are Category:MBTA Green Line rolling stock and Category:Bridges by type. Categories where most important files are not in subcategories, where the subcategories are obvious (such as by-color subcategories), or where a single image would not be sufficient/useful (such as by-year subcategories) would not work well.
• Because users need to be able to get to the category contents easily, more than ~10 images starts to get very clunky. A partial-width gallery like on Category:Bridges by type can mitigate that, but it requires scrolling to see all the images, and seems to have to be hard-coded.

Pi.1415926535 (talk) 00:39, 21 September 2026 (UTC)

No, I do not agree: gallery pages are certainly not useless at all and the use of gallery pages is much broader than only providing a guide to larger categories to aid navigation, even if they are not updated on a regular basis. I use them also to find proper categories, they might not be even a subcategories of the same main category. As a not native English speaker, I often have trouble to find categories about specific subjects and words we did not learn at school, for instance about architectural elements or herbs and spices. Or to find a castle in a file with only "castle somewhere in the Netherlands" as a description. Or find the correct categories for members of our royal family who have the same name (many Willem van Oranje-Nassau, 2x Prins Hendrik, 2x Wilhelmina van Pruisen). See my User page for examples. And someone else has set up a gallery page to use it as a slide show during a real life presentation.

So please, let's keep them. Or propose a stricter set of rules for deleting useless ones. Otherwise this discussion will not get a clear conclusion. JopkeB (talk) 14:28, 26 September 2026 (UTC)

Mohandas K. Gandhi and John Ruskin cannot be replaced by current categories. They show a selection of the best images ordered chronologically. There is no way to do that with current MediaWiki categories. Yann (talk) 07:41, 21 September 2026 (UTC)

• The header question cannot be answered with a blanket yes or no. Legacy galleries from early Commons that aspired to be what categories became are generally not useful. Galleries with explanatory text illustrating specific points sometimes are quite useful. -- Infrogmation of New Orleans (talk) 00:46, 21 September 2026 (UTC)

Even if not maintained, this is not a justifiable cause for deleting any content (galleries included). Possible solutions are updating them, or, if not feasible, adding a template to warn the user that the content is not up to date. As for examples of good, useful galleries, just look here, here or here. In addition, Wikimedia Commons Atlas of the World is based on galleries (in my opinion, this would deserve its own Wikimedia project, but that's another story: it's at Commons, it's based on galleries, and it's needed, though it should be better known and have a better quality).

Another question is for some specific galleries, especially if they have a really bad, simple content and their name matches with a category. But definitely, no, not all galleries deserve being deleted, that idea sounds really terrible: any deletion must be case by case. MGeog2022 (talk) 13:00, 21 September 2026 (UTC)

This is a recurring bad idea that shows up here from time to time, and it's always rejected (for very good reasons). Should it be added here? MGeog2022 (talk) 13:08, 21 September 2026 (UTC)

I support adding it to Commons:Recurring proposals.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:12, 21 September 2026 (UTC)

I support adding it to Commons:Recurring proposals as well. Each time it feels like an attack to a precious thing I value much. JopkeB (talk) 15:58, 26 September 2026 (UTC)

I think the are wildly underutilized and potentially very useful. If you haven't already done so, have a look at Commons:Galleries and, especially, at the examples given there. We could use a lot more like those. - Jmabel ! talk 21:55, 21 September 2026 (UTC)

Perhaps reviving Commons:Featured galleries? We "only" need criteria. JopkeB (talk) 16:01, 26 September 2026 (UTC)

A system of sticking notices on gallery pages like "This gallery page has had no new content for 10 years" might be useful. It could be illuminating to create a view count report, as galleries of historic artworks might effectively be created and finalised years ago, but seen by large enough numbers to be of 'realistic educational value' in its own right. A page that nobody has looked at for 5 years, yes that could be worth marking as "This gallery page is no longer in use/archived" notice but I doubt there's any appetite to delete these. Fæ (talk) 10:49, 22 September 2026 (UTC)

It depends on the type of gallery. Some of them don't need any updating (a certain book or work of art, a closed collection of items, etc), while for some others, updating can make them better, but it's not strictly needed (for example, List of dog breeds: while new breeds may be recognised, I think that, in 21st century, it's highly unlikely that someone could eventually consider this gallery as outdated). MGeog2022 (talk) 12:25, 22 September 2026 (UTC)

I would find a notice like This gallery page is basically just a bunch of random images very useful. A notice like that would probably end up doing away with a considerable number of our current galleries. Hjart (talk) 12:43, 25 September 2026 (UTC)

I feel the same for numerous galleries, and I am likewise wondering about their purpose when they are the primary target of wikidata (instead of the corresponding category). There exist, however, also useful galleries that provide some overview that is otherwise hard to achieve. Here are some examples (all created and maintained by myself): Les vitraux de l'église Notre-Dame de Saint-Lô (this is not a selection but the whole set in properly sorted order), Carrowmore Megalithic Cemetery (provides references for various numbering schemes and sorts all pictures accordingly, this is helpful when trying to identify new uploads), East Window of St. Nicholas's Church of Ireland, Dundalk (stained glass window with a very complex history). --AFBorchert (talk) 11:15, 22 September 2026 (UTC)

Is there a way these galleries can be better highlighted? They sort of just hide on the Commons. I've only ever seen these when I stumble upon them through a given files 'usage on Commons' section. Let's look at an example, Gallery/Toronto is a pure time capsule from 15-20 years ago. I'd be happy to keep it up to date, but if no one is going to be able to easily find it what's the point? Could galleries be promoted in categories, the same way the gallery promotes the category at the very top? The link to the gallery in the category is hidden under 'Pages in category "Toronto"'. Most people probably have no idea this is a link to a gallery, as there is zero mention of so. If we want people to use these and browse them, we have to make them easier to find. I'd agree that they are underutilized and have potential for many cases. PascalHD (talk) 23:31, 24 September 2026 (UTC)

I think a template to bring people from a category to an appropriate gallery or galleries when they exist would be fine; I would very much hope, though that if we introduce that it only gets added when the gallery is at least moderately good.

I would be all for introducing a notion of Featured Galleries. I think it would probably get some people who are driven by getting things up to "featured" level to think a bit more about galleries. - Jmabel ! talk 07:55, 25 September 2026 (UTC)

Galleries definitely are still usefull. People just need to understand which purposes they're actually good for, and unfortunately lots of our past contributors did not. Galleries which are basically just a bunch of random images are admittedly not usefull, while galleries which helps me understand and navigate complex category trees definitely are usefull.

I've created a fair number of galleries, primarily to aid my own need for a quick overview over various things. Examples are Niels Hansen Jacobsen, Kongens Nytorv, Skibbroen (Ribe) and Løgumkloster. Hjart (talk) 12:34, 25 September 2026 (UTC)

I don't think they are generally useful (though they could be). Personally I wish the wikis allowed more images and the gallery would live there. Don't see the value in deleting them without a replacement though. BrokenSegue 22:54, 27 September 2026 (UTC)

@Mike Peel Considering the considerable number of touristy photos all named "At London..." and similar, that you're currently dumping into Category:London and other base categories, why do you really care about a few galleries? Hjart (talk) 14:32, 28 September 2026 (UTC)

@Hjart: I responded to your 'touristy photos' point at [1]. I'm coming at this topic from multiple perspectives... I created {{Wikidata Infobox}} and I operate User:Pi bot to add sitelinks from Wikidata (and hence Wikipedias) to Commons categories, and I'm trying to figure out how galleries fit in there. I also frequently come across galleries when I'm working through the backlog of categorising my photos, and they are, um, not too helpful there. And lastly, I'm trying to figure out what works best for users of Commons, particularly given my background in Wikimedia governance and the accessibility of Commons contents was a topic that came up frequently in discussions there (where galleries have pros and cons vs. categories). Thanks. Mike Peel (talk) 19:58, 3 October 2026 (UTC)

Thanks for the responses, but I'm still looking for a good example of a gallery here. There have been some nice examples here for very specific topics, but none of the examples so far have good multilingual support, and none of them are up to date with the best photos that Commons has available. The best examples I've seen here would be good Wikipedia galleries, but they still hide the richer collections we have here in categories. They also don't match the quality of the galleries that I normally encounter here, where they haven't been updated in a decade or so. So the examples raised here are probably the best we have, but not the average? Thanks. Mike Peel (talk) 23:26, 23 September 2026 (UTC)

For history or visual arts, there're definitely many useful galleries: Metropolitan Museum of Art, Cappella degli Scrovegni (Padua), Villa of the Mysteries (Pompeii). They indeed have issues, but most of them should not be mass-deleted. It's hard to find super-fancy galleries, as galleries are not featured, so there's little motivation for users to put effort in them. Even if the gallery is outdated, it serves some purpose by arranging images in certain way, such as by room or section in the museum, something the categories don't provide without manual sort keys. New quality images don't arrive fast enough to make this serious issue. In other areas, like cities or nature, outdated or useless galleries might be more problematic. MSDN.WhiteKnight (talk) 11:22, 24 September 2026 (UTC)

they still hide the richer collections we have here in categories: this is unavoidable: galleries can't include all the files we have (they can't even include all the better ones). But their existence should never be interpreted as "you don't need to look at related categories at all". {{Gallery page}} template should do a good job in preventing this. MGeog2022 (talk) 12:30, 24 September 2026 (UTC)

• I personally think it will never be useful, and we have to make plans of doing away with it. It is unnecessary work to maintain and keep up to date; effort that could be used elsewhere. And even if a magician of a Wikimedian somehow does keep everything up to date, we should ask - why? Who is the audience for these random galleries hidden in Commons? Commons users themselves? I have been here since 2008 and have never found them useful. With automated capabilities coming in (like structured commons), in addition to existing Categories, this is just unnecessary work and maintenance. Mass tagging galleries that it needs to be updated is just going to reduce the quality of Commons as a whole. I hope this wont be dumped as a recurring proposal, because it is about time something is done about it. Cheers, Rehman 12:59, 24 September 2026 (UTC)

  Just look at many of the comments above, and the examples they provide. The argument for mass deletion is like mass deleting all JPEG images because some of them are bad, copyvios or out of scope: destroying everything because some problems exist. For example, where do we place the only wiki atlas Wikimedia has, then? The fact is this already is a recurring proposal that has always been rejected. I'm thinking about a good recurring proposal that keeps being rejected in Wikipedia. Changes to policies are generally rare here: if they are not changed for the good, I hope at least they are also not changed for the bad. MGeog2022 (talk) 13:28, 24 September 2026 (UTC)

  And I can't know who (other than me) is the audience of such galleries, but I can tell you that it does exist: look here or here (or the visits counter for any other gallery). In fact, their number of visits is higher than for the categories with the same name (it could be argued that it's because the gallery takes attention away from the category, though): see here and here, respectively. MGeog2022 (talk) 13:38, 24 September 2026 (UTC)

• I find them useful when they sort documents or images in chronological order. --RAN (talk) 23:04, 24 September 2026 (UTC)

  Another advantage of galleries over categories is when putting files together as part of a whole. Categories are attributes of files: you can't know what files belonged to a category in the past by looking at the history of the category (in fact, you can't in any way, as far as I know). If you have a fixed set of files and want to present them as a whole, galleries are far better way to ensure the integrity of the whole. If somebody improperly adds or removes an element from the set (mistake, vandalism, etc), fixing it is as easy as reverting to the previous version of the gallery (it could even be done by someone who is completely unfamiliar with the collection). With a category, you would need to know the full set of elements that belong to the category, and their respective file names in Commons, to be able to solve the problem. So galleries have a good advantage over categories when integrity of a collection matters. MGeog2022 (talk) 12:53, 25 September 2026 (UTC)

  I made some edits to Commons:Galleries to highlight their advantages and to try to express more clearly that they are not in conflict with categories. MGeog2022 (talk) 13:18, 25 September 2026 (UTC)

Gallery pages do not have to be multi-lingual to be useful. Commons is multi-lingual itself, so the creator of a gallery page is alowed to create gallery pages in any single languge, or two (for example mother tongue and English), or put links to Wikidata-items to be multi-lingual (I have seen the last type, but do not remember were; and it is quite a lot of extra work, so I did not yet use them). It depends on the purpose of the gallery page which language(s) you use. JopkeB (talk) 14:44, 26 September 2026 (UTC)

Wouldn't the 'better' (but monolingual) galleries being mentioned here better serve readers if they were on that language version of Wikipedia rather than on Commons? Thanks. Mike Peel (talk) 21:32, 25 September 2026 (UTC)

The purpose of the better gallery pages is to aid other commons contributors and wikipedians, not ordinary readers of wikipedias. In 2024 I created Børsen for exactly that purpose. During the first month after the fire, it reached almost a thousand views, and I'm convinced that it helped a lot of wikipedians gain a much better idea of what this was all about, than they would have had from merely trying to make sense from the content of the categories. It has a bit of Danish text, because at that time I still didn't have sufficient experience to avoid that. Hjart (talk) 07:56, 26 September 2026 (UTC)

@Hjart, that's your personal opinion, but, for example, I don't share that view, and I don't know what the community thinks about this on average. In Wikimedia projects, all content that is not in user or talk pages, or in pages whose name begins with the project's name as a prefix (that is, in Wikimedia Commons, pages prefixed with "Commons:"), is supposed to be for the public, not only for internal community use. I had never thought about galleries as mainly for internal use (for example, some of them are linked from Wikipedia articles). One thing is that they can be very useful for the community, and a very different one is to think this is their only purpose. MGeog2022 (talk) 10:19, 26 September 2026 (UTC)

@MGeog2022 All galleries that I create or contribute to, are squarely aimed at giving (mostly German) tourists to i.e. Thisted a quick idea of what to see here and where to put their photos as well as give wikipedians a basic starting point for new and/or expanded wikipedia articles. I don't have a problem with wikipedia end readers accidently stumbling upon them, but I don't really see a point in trying to present anything to them. Hjart (talk) 11:50, 26 September 2026 (UTC)

@Hjart, it depends on the type of gallery and other factors. Wikipedia readers who are curious about more images about a place or a topic, may browse the associated category from Wikipedia's link to Commons, and, from there, they may arrive to the gallery. In fact, for a quick view of a selection of images, the gallery would usually be better than its associated category. But there is no problem: a well-made gallery created with Wikipedia editors in mind, will also be a good one for Wikipedia readers. MGeog2022 (talk) 19:15, 26 September 2026 (UTC)

@MGeog2022 "Usually"... Only maybe a handful of the gallery pages in i.e. Category:Gallery pages of churches in Denmark are actually worth visiting. The vast majority of them are straight-up nuisances and really just good for hiding the underlying categories.

Creating a good gallery page requires serious experience and effort. Hjart (talk) 06:49, 27 September 2026 (UTC)

@Hjart, for galleries not hiding their associated categories, {{Gallery page}} template can do a good job. MGeog2022 (talk) 09:00, 27 September 2026 (UTC)

@MGeog2022 That template doesn't make them worth visiting at all. Hjart (talk) 09:07, 27 September 2026 (UTC)

@Hjart, obviously not, but at least it allows the reader to know that additional images are available in the associated category, so the category isn't "hidden" anymore. MGeog2022 (talk) 09:24, 27 September 2026 (UTC)

@Mike Peel: at least for en-wiki, gallery pages like this are not in scope. I believe the same is true for es-wiki and probably most others. Would I like to see people make these more multi-lingual? Absolutely. Is that on my persona list of priority work? No, it is not, I am majorly backlogged, plus bogged down with admin and quasi-admin tasks. - Jmabel ! talk 14:37, 26 September 2026 (UTC)

@Mike Peel, it depends on the case. A small number of images is likely to be accepted in Wikipedia as a gallery, but Wikipedia usually rejects larger galleries, while these ones can find a place in Commons. In addition, it's easier to maintain and update a gallery in all its supported languages when it is at a single, centralized place, such as Commons, when compared with doing the same across multiple Wikipedia editions. MGeog2022 (talk) 10:29, 26 September 2026 (UTC)

@Mike Peel: In es.wikipedia photo galleries are generally frowned upon, since according to their rules they should be hosted in Wikimedia Commons instead («Evita insertar excesivas imágenes en un mismo artículo. Las galerías deben añadirse en Commons y no en los artículos, y deben enlazarse desde el artículo usando la plantilla {{commons}}.»). Strakhov (talk) 13:44, 26 September 2026 (UTC)

It is always interesting how quickly Commoners say "Wikipedia should do this" and how quickly Wikipedias answer in kind. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 11:30, 1 October 2026 (UTC)

@Gone Postal A lot of contributors are both Commoners and Wikipedians. Hjart (talk) 14:25, 1 October 2026 (UTC)

This feels like a chicken-and-egg situation. If Commons had never offered galleries, would Wikipedias have hosted them there instead? I've mostly been on the side of removing galleries from Wikipedia articles in the past on the basis that Commons should have that role instead, but I'm not sure if we are delivering that. Thanks. Mike Peel (talk) 20:05, 3 October 2026 (UTC)

• It depends on the purpose. A gallery with a clear scope like Flags of the Soviet Republics is useful; a broad topic generally isn’t. --Dronebogus (talk) 08:17, 2 October 2026 (UTC)

Thanks all, this is really helpful. I'm wondering if it's worth having a Commons:Requests for comment on this topic to try to resolve it properly rather than it continuing as a lingering issue (@JopkeB: I hear you with people attacking things you care about, I've been there, and that's not what I'm trying to do here). What I'm hearing is that we shouldn't get rid of galleries completely, but we should probably have some sort of quality assessment of them, is that reasonable? I'm also hearing that the most useful galleries are where we have broad coverage of the topic and it's useful to highlight specific media files. Does anyone want to defend the existence of narrower galleries - for example, Hals Kirke? (as a random gallery from Category:Gallery pages of churches in Denmark mentioned just above.) Thanks. Mike Peel (talk) 19:43, 3 October 2026 (UTC)

@Mike Peel: re the most useful galleries are where we have broad coverage of the topic and it's useful to highlight specific media files, I'm not really that interested in discussing whether these are "the most useful" galleries, but there are useful galleries that do not fit this description, including at least two, both my work, that are explicitly mentioned in Commons:Galleries: Floating the Skagit River from Marblemount to Rockport and Seattle and the Orient. Each of these does something useful that categories could not do readily (if at all) and which probably would not be welcome in any Wikipedia. The latter arguably could be done in Wikisource, but the text is the least interesting part of the document—a bunch of Chamber of Commerce-style puffery—so transcribing it for Wikisource would involve a large, mostly wasted, effort. - Jmabel ! talk 21:55, 3 October 2026 (UTC)

@Mike Peel The gallery Hals Kirke, like so many other similar galleries, appears to be basically just doing what categories exists to do. There's absolutely no point in defending that. I find that kind of gallery annoying and unhelpful too. Hjart (talk) 01:15, 4 October 2026 (UTC)

I do not agree with Hjart. For me these kind of galleries are useful. The category has a subcategory about the interior. And in the gallery page you can see in a glance an overview of both the exterior and the interior. That is the value for me of this gallery page. You do not have to click, as you should to see images of both categories. And the categories contain more than 10 files (the subcategory even more than 20). Then for me it is OK to have a gallery page.

I get much more annoyed by a gallery page:

• With only a few images; the lower limit is now two images; for me the limit may be higher, for example five. Perhaps such a gallery can be moved to the category if they might be useful there (like showing images of a male, female and juvenile of an animal). And/or:
• Of a category with only a few images and no subcategory; I do not see the value of such a gallery. "Few" can be "less than twenty".

 Support the proposal of Mike Peel to have some sort of quality assessment. Therefor we need criteria. Let's discuss them here. I propose the two here right above. Do you agree? Does anyone know others? JopkeB (talk) 05:36, 4 October 2026 (UTC)

Most of us, when we see a gallery like Hals Kirke, just want to quickly skip it to check what newer images might be contained in the related categories. To be useful it must be clearly designed to better present complex things in ways that categories can clearly not do. Hjart (talk) 13:08, 4 October 2026 (UTC)

I'm generally fine with deleting galleries that has less than 5 images, or when there's less than 12 images in category. We might need some exceptions for galleries that have specific way to organize limited amount of images. For example, if the purpose of the gallery is to show three altar panels in their physical order, it by design would have only three images. MSDN.WhiteKnight (talk) 10:46, 8 October 2026 (UTC)

Galleries without real "extra-added value" should be deleted, I think. However, there are numerous galleries that I created or contributed to whose deletion I'd consider vandalism. Just some examples:

• Churches_in_Landkreis_Ravensburg
• Frescos in Basilika St. Martin (Weingarten)
• Stadtmauer Nürnberg
• Epitaph Friedrich Humpis (Pfarrkirche Pfärrich)

--Anvilaquarius (talk) 10:11, 14 October 2026 (UTC)

i think there're two questions here:

1. whether the commons link showing up next to wikipedia articles etc. should be commons gallery pages, i.e., whether the sitelink on wikidata can be commons gallery pages.
2. whether commons gallery pages are useful (in showing a collection of files).

the pages are themselves quite harmless, other than being extra pages in the database.

the commons link in the sidebar going to the gallery page, this is quite often annoying, because as users said, the pages are often outdated and not well curated.

however, a potentially simple solution, is to change the sidebar link to always go to the category. then users can keep making galleries, and users intending to go to the categories can always go straight there. everyone is happy. RoyZuo (talk) 18:21, 15 October 2026 (UTC)

FWIW, when the Wikidata-based approach to interwiki linking came in, there was a lot of discussion of this. Commons was a bit of a "red-headed stepchild" in that discussion (and remains so), because we are the only WMF wiki where "main space" is not really where the main content is. - Jmabel ! talk 18:02, 16 October 2026 (UTC)

October 01

Category:Categories of Portugal by setting

Some Categories of Portugal by setting, are not refreshing—not even with a full refresh—and always show as empty, even though they contain categories and/or files — Preceding unsigned comment added by JotaCartas (talk • contribs) 15:49, 1 October 2026 (UTC)

 Comment, most likely the same problem as Commons:Village pump/Technical#Category gallery count shows negative number. The problem seems to be resolved, but if there are still errors, they can be solved by purging the subcategory. Thanks. Tvpuppy (talk) 23:14, 19 October 2026 (UTC)

October 14

Editing talk pages of banned users?

Is this a good edit?

Should DR notices be posted to the user talk: pages of banned users? I can see @Streetr4: 's point here, but also there are many people (I was one) who might have that page still on their watch lists and might also be interested to see the DR notice (I certainly was). It seems impractical (even if not inappropriate) to stop the auto-notification tools still posting there.

I don't think we should do this. Just let the posts build up, as usual. Auto-archive them if, like Russavia, there's an awful lot of them. I would note also that we don't protect such pages. Andy Dingley (talk) 21:57, 14 October 2026 (UTC)

As the editor mentioned, I saw that the page had already been cleared a couple times before then and that the deletion request seemed like it would be quickly resolved. I don't really have a preference on the talk pages of blocked users, so I'd also say leave the notice if you think that's what should be done. Streetr4 (talk) 00:14, 15 October 2026 (UTC)

I check deletion requests on the talk pages of users (even those who have been banned). Removing those is bad not because it harms banned users (they are already banned), but because it harmes those who are not banned. But a good faith error of somebody removing it should not be much of a problem. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 09:37, 15 October 2026 (UTC)

Here's some practical advice, as someone who has done this several times in the long ago. Take a look at the syntax for User:ArchiverBot and be bold and add the template to pages that are unusable due to length, especially where transcluded templates no long work because there are too many.

Nobody has ever been punished for doing this practical bit of maintenance. I would however be extra extra cautious and avoid accounts that are WMF office blocked, these are better touched by admins only, though technically anyone can still edit the talk page unless they have had page protections changed due to serious abuse. Fæ (talk) 11:10, 17 October 2026 (UTC)

October 15

Keeping arbitrary/non-descriptive titles of artworks by non-notable artists as file names

Some file movers seem reluctant to change file names that are obviously “meaningless or ambiguous” (per criterion 2) if they are perceived as being the title of an artwork (per Commons:File naming: The title given to a work of art by the artist that created it is considered appropriate, even if the name has nothing to do with what is depicted (for example, many works of Dadaism)). Obviously I would not suggest changing File:Duchamp Fountaine.jpg to “picture of a urinal”. But File:All Those Things That Held Me Back Are Behind Me Now (33350888876).jpg (warning: nude butt) is not a notable artwork by a notable artist; it’s a random photo by a non-notable photographer. Nonetheless user:TommyG refused to move it from the artist’s title to something descriptive. This is in blatant contrast to File:Dealing with bullies colored.jpg, clearly the title of an artwork, getting changed to “File:Cartoon of people falling into a giant's mouth (color).jpg”; no special privilege was given to the artist’s title there (mover was user: Inertia6084). I don’t think there is any reason whatsoever for this difference; just two different file movers applying policy differently. However I think either policy is unclear and should be made clear on this matter, or I’m missing something. Personally I believe this should only apply to artworks by notable artists, and this is likely what the title was intended to refer to. If it is not intended to apply solely to works by notable artists, then who or what does it apply to? Would the ad absurdum presumption not be that any file name provided by the original author is a valid title of an artwork given by the artist and therefore should not be changed? If Eric Cartman uploads a photo of a bird he took and decides to call it “Shitty McPooPoo”, do we have to keep that as the file name because it is the title given to the photograph by the artist? --Dronebogus (talk) 12:28, 15 October 2026 (UTC)

I am not a file mover, but I would not move File:Dealing with bullies colored.jpg without at the very least leaving the original title as part of the name. I feel that moving files is very destructive and disruptive. I would support clarification to what file movers are expected to do, in general old name must be obviously wrong for me to ever request renaming or expect for the request to be completed, I go so far that I do not even request renaming of files that I have uploaded a while ago, that I think were named incorrectly, unless it was an obvious error, and then I fix both structure of the name as well as that obvious error. I like your example of File:Shitty_McPooPoo.jpeg by Eric Cartman (tm), I think I would not request the renaming of that file if I were to come across that. I would edit description and categories, but keep the name. If Eric Cartman were to contribute to Commons I would consider that a victory, because although there would be some angry people, overall the total number of freely licenced media is increasing.

So with all that said, I would support the change, that allows moving files when there is: a) Request from an uploader made within 3 days, b) Original file name is autogenerated nonsense like IMG12345.JPG, c) Contains slurs (but not simply profanity), or d) Is being moved in a way that preserves the original title.

But this is just my approach, I am also interested other points of view. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 13:14, 15 October 2026 (UTC)

In my opinion there is way to many file renaming requests that are completely unnecessary. There really is no need to describe the image in minute details in the file name. In this case, the original photographer have chosen a specific name, and I see no reason why we should not honor that. If your goal is to make it easier to find this image among the millions of other images on Wikimedia Commons, I suggest using the category system as well as providing a thorough description for the file is the way to go. TommyG (talk) 13:23, 15 October 2026 (UTC)

It's disappointing to see a filemover who refuses to follow our file renaming guidelines. These renames fall clearly under Criterion 2, specifically part 7 of the footnote: Names that are not meaningless, but do not describe the file: Contains a coherent description or message that do not describe the subject of the file. Just because a Flickr user used a nonsense name upon upload, and a Commons user imported the file without doing basic curation, does not mean we are obligated to keep the nonsense name forever. Pi.1415926535 (talk) 13:33, 15 October 2026 (UTC)

Why did you specifically choose to exclude the continuation of that section of the rules? I'll leave the rest of that section here for you: Does not apply in cases where the name of the file is the title given to a work of art by the artist that created it, even if the name has nothing to do with what is depicted (for example, many works of Dadaism). TommyG (talk) 13:41, 15 October 2026 (UTC)

Because this isn't a file that we have as a "work of art". It's a random portrait by a non-notable photographer; if it even is in scope, it is as a functional illustration, not as a piece of art by a notable artist. Flickr filenames are also more akin to captions on social media; in most cases, they should not be assumed to be the actual title of a work. Pi.1415926535 (talk) 13:52, 15 October 2026 (UTC)

It is clearly a work of art. It wasn't uploaded to commons or created by the photographer because they wanted to create an objective, educational illustration of a nude woman. There would be much better ways to accomplish that. If you look at the other of the same photographers images that has been uploaded, there is no doubt that they fall squarely within the Fine-art nude photography genre. TommyG (talk) 15:04, 15 October 2026 (UTC)

I think it’s more important to ask what a file will likely be used to illustrate. A picture of a notable painting will likely be used to illustrate that painting, so just the title of the painting will do; a picture of a non-notable painting will likely be used to illustrate the output of the artist, so the file name should be “[title] by [artist]; an example like the nude photograph being discussed is going to be used as a generic example of a work in a given genre, so maybe “[title] ([genre])” would be most appropriate; and finally an image that will be used primarily to illustrate the depicted subject should not include a specialized title at all. Dronebogus (talk) 16:02, 15 October 2026 (UTC)

Some observations and some thoughts. 1) "P20221214AS-000027c (52650425362)" would be an example of an arbitrary file title. "All Those Things That Held Me Back Are Behind Me Now" is not an arbitrary file title, it is a considered deliberate title. 2)Titles can be (certainly not always are, but can be) a part of the work. Duchamp's "Fountaine" is indeed an example of this. 3)File titles on Commons are not required to be simple descriptions of what is most obviously visible. (Certainly they *can* be. They are not required to be only that an never anything else.). 4) Given those points, when an artist or photographer gives their work what is clearly a considered and deliberate title, that should be a consideration on Commons. This is not to say that the creator's title is sacred, nor that it should never be modified. Creator's titles can be indications of the creator's thoughts, their intentions in creating or capturing the image, or context. 5) So given these points, what to do? It looks like another of those pesky situations where we have to use judgement, balancing various factors. (For my self, for example, sometimes when there are factors that make the photograph's title in some way awkward, inappropriate, or unusable for Commons, I move the title to the file description, noting that it was the photographer's original title.). Cheers, -- Infrogmation of New Orleans (talk) 14:30, 15 October 2026 (UTC)

It looks like another of those pesky situations where we have to use judgement, balancing various factors or instead of navel-gazing we could just amend this to refer to notable artists. People would not expect a picture of the Mona Lisa to be titled “sitting woman with enigmatic smile”, nor would they expect a vore fetish image to be titled “dealing with bullies”. Things should quite simply be titled what you would expect them to be titled. Dronebogus (talk) 14:44, 15 October 2026 (UTC)

Why? Why is it so important to you that this file has a name that you prefer over the one that the original artist chose? And who should we nominate to be on the committee that decides what is and isn't art or who is or isn't an artist? It would be much better if everyone would just stop obsessing over file names. TommyG (talk) 14:57, 15 October 2026 (UTC)

1) "Mona Lisa" was not the artist's title of the artwork. "Dealing with bullies" very much is the artist's title of their work. 2) Whether an artist is a highly regarded Renaissance master or someone drawing on DeviantArt, one thing they are equal in is that they have a right to give their art a title of their choosing. If Commons considers their art worth sharing here, the title as part of the work should be respected - if there is some overriding reason why it is impractical to use the artist's title as the title of the Commons file, it should certainly at least be in the file description, clearly identified as the artist's original title. 3) "Things should quite simply be titled what you would expect them to be titled " IMO seems to suggest there is some sort of objective natural title to things, which I see no evidence for. Perhaps you could explain how others can determine how a title is "what you would expect"? -- Infrogmation of New Orleans (talk) 15:19, 15 October 2026 (UTC)

“What you would expect them to be titled” is simply the most common name. With notable artists that’s either the title they gave it or a title given by others like the mona lisa. With non-notable artists there simply is no common name so the file name should be purely descriptive. Of course you can mention the title in the description or caption, or include the title with a more descriptive subtitle. Dronebogus (talk) 15:33, 15 October 2026 (UTC)

So, let me see if I understand this correctly. If we move away from nude photographs and take some other examples:

• "File:Person with writing on body sitting in a black void.jpg"?">
  "File:Alienation.jpg" => "File:Person with writing on body sitting in a black void.jpg"?
• "File:Splotches of yellow, orange, green and blue color.jpg"">
  "File:Alienation photo.jpg" => "File:Splotches of yellow, orange, green and blue color.jpg"
• "File:Block of flats with cars.jpeg"">
  "File:Alienation (220789263).jpeg" => "File:Block of flats with cars.jpeg"
• "File:Blurry black and white image of person with knitted cap.jpg"">
  "File:Lost (23713372054).jpg" => "File:Blurry black and white image of person with knitted cap.jpg"

Personally, my opinion would be that none of these is an improvement TommyG (talk) 15:56, 15 October 2026 (UTC)

And I think at the very least the second two would greatly benefit from a more objective title, since if nothing else it would distinguish two completely unrelated files of completely different subjects. The first is at least trying to convey the abstract concept of alienation, so it could get a pass; the last one is trying to do a similar thing, but worse. The middle two have nothing to do with their titles (the second is probably not even in scope but that’s a different issue). Dronebogus (talk) 16:08, 15 October 2026 (UTC)

And here lies the problem. For me the third image from the left is the best example of Alienation out of these. So the renaming that is suggested would damage the repository of free knowledge, because it would 1) make the file harder to find, 2) alienate the original artist (pun definitely intended), 3) create unnecessary work on volunteers, 4) create unnecessary (even if small) load on the servers. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 16:23, 15 October 2026 (UTC)

A single arbitrary word that does not actually indicate what the photo shows, followed by a sequence of random digits, is about as useless as a filename gets. The community promoted Commons:File naming specifically because of the number of poor filenames being used. Claiming that it somehow does not apply to millions of files simply because they were imported from a social media site is patently ridiculous. Pi.1415926535 (talk) 17:20, 15 October 2026 (UTC)

Fwiw, the "random digits" is a reference to the files source on Flickr. It's a fairly well established practice that images transferred from Flickr should contain this identifier. TommyG (talk) 07:38, 16 October 2026 (UTC)

Who cares? It’s still just a meaningless identifier that makes files difficult to tell apart. Dronebogus (talk) 08:30, 16 October 2026 (UTC)

I do not have a strong opinion on this either way, I was merely explaining what the numbers were, but clearly Pi.1415926535 knew this already. TommyG (talk) 08:41, 16 October 2026 (UTC)

We are debating which image gives off a hugely subjective vibe like a game of Dixit instead of just admitting that none of these images can possibly hope to illustrate a concept with sufficient accuracy to be described as a depiction of that concept first and foremost. They are quite simply depictions of a person with words on them, a bunch of random colors, a block of flats with cars, and a blurry image of a person wearing a cap. None of them should be titled “alienation” or something similarly vague and abstract. A file name is simply a tool for identifying a file and giving you an idea of the content when the file isn’t visible. Dronebogus (talk) 17:45, 15 October 2026 (UTC)

Btw the second photo ("File:Splotches of yellow, orange, green and blue color.jpg") actually depicts a wildfire (see the same landscape with a bit different shaped smoke column in another photo by the same photographer[2]). And going by other photos from that photographer, it's most likely a wildfire in Utah (as they have photos labeled "Carbon County", "Timpanogos Mountains" and "La Sal"). Going by the time of the photo, it's likely the Trail Mountain Fire in Manti-La Sal National Forest. If you look closely at the photo you can clearly make out mountain ranges and the smoke from the fire. It's far more than "Splotches of yellow, orange, green and blue color". (That should also clear the scope question.) Nakonana (talk) 19:17, 16 October 2026 (UTC)

Agree with TommyG. And presumably by Dronebogus's criteria, File:Meher Bababall.png should be renamed "Circle face drawing with letters"; and File:Qiuwen-niang shields your virgin eyes.png should be renamed "Cartoon girl with glasses holding sign". I disagree; I don't think that would improve the situation. -- Infrogmation of New Orleans (talk) 16:47, 15 October 2026 (UTC)

I’m not suggesting every image needs to be turned into a description for the visually impaired; I’m saying that if a title is completely arbitrary and doesn’t describe the image in any meaningful way, and the title is not a notable identifier of the subject, it should be given a descriptive title instead. The examples discussed are things like an image titled “Alienation” showing a block of flats with cars; a cartoon of people falling into a giant’s mouth titled “dealing with bullies”; and a photo of a nude standing woman titled “All Those Things That Held Me Back Are Behind Me Now”. The “counter examples” you provided are specific characters, and the titles are “[character]” or “[character is doing thing]”. File:Mickey Mouse.svg is a similar depiction of a specific character; it wouldn’t make sense to retitle it “cartoon mouse with a ship’s steering wheel”. If a subject has a proper name and is widely recognized by that proper name, that proper name is a suitable filename even if it’s not a “title” per se. Other examples would be the Eiffel Tower (not “big metal tower”), K2 (not “mountain”), or Tom Cruise (not “man with dark hair”) Dronebogus (talk) 17:27, 15 October 2026 (UTC)

Alienation is a common term used for people who live in "hive buildings", it is well established, but here comes a file mover who has somehow missed the memo and renames the file to "Block of flats with cars" and all of the sudden nobody will find this image, because it is a very poor illustration of a block of flats and even worse illustration of cars. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 04:24, 16 October 2026 (UTC)

Huh? "Alienation" is a term describing an emotion which might be felt by people in the place depicted by the photo. It is not a "common term" for the apartment-dwellers themselves - I don't think it has that meaning at all. One would never describe a person as e.g. "an alienation". Omphalographer (talk) 05:07, 16 October 2026 (UTC)

Second this. Gone Postal’s argument is absolutely nonsensical. By this logic a common term for vore fetish images is “dealing with bullies” and a common term for nude women is All Those Things That Held Me Back Are Behind Me Now. Dronebogus (talk) 08:36, 16 October 2026 (UTC)

It's not for the apartment-dwellers themselves. It is for the concept of people living in "hive buildings". Well spotted @Omphalographer! I should have been more clear. I am no longer interested in this discussion, however, because I no longer believe that it is in good faith. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 15:45, 16 October 2026 (UTC)

With non-notable artists — what do we do if such an artist becomes notable one day and then people start to reference their work under the incorrect, Commons-created name instead of the actual title given by the artist? Nakonana (talk) 17:17, 16 October 2026 (UTC)

I think Rhondodendrites’s suggestion of is the primary educational value of this media the artwork itself or what it happens to depict is superior to my original suggestion of notability, but it’s nonetheless unlikely that people will start referring to anything by its Commons filename. Most people probably don’t realize we even exist as a separate entity from Wikipedia; our project is very much behind the scenes and therefore filenames are largely for the benefit of users, not outside audiences. Dronebogus (talk) 18:16, 16 October 2026 (UTC)

Per TommyG. You might not like the title, but it's a title that the artist specifically chose. Not just as some random typing of camera file IDs, but as a deliberate creative decision. We should respect this. Andy Dingley (talk) 19:22, 15 October 2026 (UTC)

It’s not about respect or creative decisions; it’s about the utilitarian purpose of a file name to identify and describe a file. Wikimedia Commoms is not a museum or gallery for amateur artists to have their work presented exactly as they originally intended but rather an educational repository that should make potentially useful depictions of things as easy to find as possible. Once again, if the chosen title of a file is sacred and intrinsic then why even allow the renaming of files with “meaningless or ambiguous” titles? Dronebogus (talk) 20:00, 15 October 2026 (UTC)

As Andy Dingley implies, we allow renaming of files with "meaningless or ambiguous" titles first and foremost for camera file IDs. We have categories to make files easy to find. Filenames are ultimately arbitrary ids for identifying the files, and it's nice that they're readable and not confusing or misleading, but changing the chosen title of an artistic work is simply pointless.--Prosfilaes (talk) 03:04, 16 October 2026 (UTC)

It’s not “simply pointless” if it makes a file easier for reusers to find and identify. The original name of the vore fetish image I mentioned earlier, “dealing with bullies”, says nothing about the actual content and if someone was going by the title alone they might think the file was about how to realistically deal with bullying. Dronebogus (talk) 08:40, 16 October 2026 (UTC)

It doesn't make it easier for reusers to find or identify. That's what categories and structured data are for. As for the vore fetish image, that would be quite the foolish move. Yes, File:Purple beautyberry, October 2015 - Stacking.jpg could be an image showing the stacking for cases of berries for shipping, but anyone assuming that would be wrong, because that's not what stacking means in this context. "dealing with bullies" could meaning anything, including apparently eating them, but a poster of how to appropriately deal with bullies and a photo of a drive-by shooting would be in my list of possibilities. Be reasonable and look at the picture before making any assumptions about it.--Prosfilaes (talk) 03:21, 17 October 2026 (UTC)

The purple beautyberry example is still fundamentally an image of beautyberries. “Dealing with bullies” could as you yourself said depict anything and therefore seems textbook ambiguous. If a title could refer to literally anything and is not the common name of an artwork it should be changed. Dronebogus (talk) 11:54, 17 October 2026 (UTC)

I’m not sure if we’ve had this discussion before – we probably have long ago. But is a file name even considered to be the same as a legally binding title of a work within the meaning of copyright? I recall that back in the days of CC 3.0 and earlier versions – when the title had to be mentioned when reusing a work – this interpretation was rejected and a Title line was included in the file description template. However, I’ve noticed that this is rarely used. When importing files from Flickr, I almost always change file names that don’t make sense into something meaningful, and I’ve never received any complaints. It may also be confusing that the upload tool apparently makes no distinction between title and file name. -- Herbert Ortner (talk) 20:28, 15 October 2026 (UTC)

This whole issue has strong Treachery of Images/Haddocks' Eyes vibes. Dronebogus (talk) 20:31, 15 October 2026 (UTC)

Here’s an example of a really terrible (but amusing) original file name: File:Alligator in my plate.jpg. Can you guess what it depicts? An alligator in someone’s plate? No, it depicts seafood linguini, with shrimps and tub gurnard. So do we respect user:E4024’s artistic intent by keeping the original title, or do we give it an actual descriptive title as user:Jo-Jo Eumerus did that makes it clear what the image depicts without even having to look at it? Do ugly pictures of unappetizing seafood dishes get to be artistic works with inalienable titles, or does that only apply to pretty photographs of apartment blocks and nude models? Dronebogus (talk) 08:52, 16 October 2026 (UTC)

But, is that even a Seafood linguini? That seems to be an assumption made by an anonymous user back in 2018. Also, the original uploader is specifically asking for help to find a more appropriate name in the original description: «Please tell me so I can find the correct categories or change the file name to a more accurate one» TommyG (talk) 12:47, 16 October 2026 (UTC)

Well whatever it is it certainly is not an alligator in someone’s plate. Dronebogus (talk) 12:51, 16 October 2026 (UTC)

I think it might be a haddock? There's something about the eyes. Andy Dingley (talk) 17:34, 16 October 2026 (UTC)

Good one Dronebogus (talk) 18:10, 16 October 2026 (UTC)

It's a tub gurnard, it's in the file description. TommyG (talk) 20:26, 16 October 2026 (UTC)

I'd say neither of the two original file names meet criterion 2 for renaming. To me, criterion 2 means something akin "author randomly smashed on the keyboard" or "very generic" (like "Germany 01") or "too source website-oriented" (like "Panoramio 1234567"). Nakonana (talk) 17:09, 16 October 2026 (UTC)

Then the criterion should be split into three new criteria (with the first being something like “patent nonsense”) instead of “meaningless or ambiguous”, which describes the numerous discussed examples perfectly (if you take “meaningless” to mean “arbitrary and non-descriptive” and “ambiguous” to be “functionally identical to another file”) Dronebogus (talk) 18:09, 16 October 2026 (UTC)

The renaming guideline page gives 8 examples for criterion 2 and neither of the two file names from your opening post fall into the given examples. Going by the given 8 examples, criterion 2 is pretty much about "patent nonsense" or "way too generic". There is no example that concerns itself with titles of artwork not describing the contents of the image. Nakonana (talk) 18:17, 16 October 2026 (UTC)

It doesn’t say it’s limited to patent nonsense or “way too generic”, and once again there is a precedent of renaners using it for titles that are both irrelevant to file content and unimportant to the educational value of the file. If renamers are only supposed to use it for cases where the file name is random characters or something like “dog (123456).jpg” it should be made clear that those are the only intended uses of criterion 2. Dronebogus (talk) 18:24, 16 October 2026 (UTC)

I'm pretty sure criterion 2 has been discussed before. And as far as I remember it is intended for the type of file names listed in the examples — that's why the examples are there to clarify the scope of criterion 2. Nakonana (talk) 19:21, 16 October 2026 (UTC)

Here: [3][4], and there was even an RfC[5]. Nakonana (talk) 19:34, 16 October 2026 (UTC)

What if we just ask "is the primary educational value of this media the artwork itself or what it happens to depict" and use that? Then the Duchamp example is an artwork with a title and not a urinal, and something like File:Hey You! (30559610814) (cropped).jpg is a grouse. I'd prefer that to getting into determinations of notability. It seems like the kind of standard that a typical filemover could use, and we could even add that if a title is removed from the filename, it should remain in the description. — Rhododendrites ^talk |  13:06, 16 October 2026 (UTC)

We can't guarantee that the original title will remain in the file description because file description can be easily changed by anyone, whether they are familiar with any title conservation policy or not. File names on the other hand cannot be changed all that easily. Nakonana (talk) 17:29, 16 October 2026 (UTC)

We don’t need the original title unless it’s important to the educational value of a file. Dronebogus (talk) 18:11, 16 October 2026 (UTC)

Removing the title completely from a work is an act of academic vandalism. It is essential for tracing back sources, including and especially when the original site is down. In many cases, it is a sign of disrespect to the original author. We want to encourage people to make their works reusable, not discourage them from doing so.--Prosfilaes (talk) 03:21, 17 October 2026 (UTC)

If you release your work under a free license compatible with Commons you are giving your consent to having it radically altered without your input. This includes having the title removed or changed. Dronebogus (talk) 11:58, 17 October 2026 (UTC)

Drone, you're in the minority here. Courtesy to the creators of works and easy traceability to the original source, even if long gone, are both important aspects of what filemovers should always consider before acting. BTW, I have been a filemover for 15 years and done a lot of batch file moves. Fæ (talk) 13:28, 17 October 2026 (UTC)

Then that needs to be made clear, that “meaningless or ambiguous” equals “gibberish or redundancy”, and some users here have already seemingly defended redundant generic titles like three images called simply “alienation” with an identifying string of numbers. Dronebogus (talk) 13:32, 17 October 2026 (UTC)

Maybe that's too literal? As a hypothetical "File:Alienation X31415.jpg" could be moved to "File:Cartoon of alien eating a hamburger (Alienation X31415).jpg" making it easy to read what might be found in the image, without losing any tracking or attribution value. So long as titles don't become long sentences, a bit of extra length is fine. Fæ (talk) 13:36, 17 October 2026 (UTC)

you are giving your consent to having it radically altered without your input: you are giving consent for derivative works that do this. As we say in our summary at {{Cc-by-sa-4.0}}, "You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use" (emphasis mine). This would suggest, to me at least, that a change of title ought to be visible. I don't think that's an issue when it's a spelling correction or such, but if someone gave an artistic work a title, that title is at least arguably part of the work. - Jmabel ! talk 15:40, 17 October 2026 (UTC)

It’s just a question of what constitutes an artistic work for our purposes. For example does File:Hey You! (30559610814) (cropped).jpg constitute an artistic work with an intrinsic title? It’s not obviously artistic unlike many of the other examples, but who are we to judge that? Dronebogus (talk) 16:53, 17 October 2026 (UTC)

For a filemover, we would keep the flickr photoid in the title and preferably the original name of the photo. In this case the photographer has a long track record of interesting and potentially high quality photographs, and though these are not artworks they should remain easy to track back to the original Flickr account and photographer. Again these are not hard rules but the principles of traceability and the courtesy of preserving credit are the ethics of renaming files that we expect. Fæ (talk) 17:05, 17 October 2026 (UTC)

Not generating bad names ourselves

Without dealing with the discussion above, maybe we can think about how to not generate bad file names in the first place. There are some very useful tools that create new files with horrible names. Just now somebody has created a crop of my file File:Stamp of Finland - 1990 - Colnect 47297 - Main building of Helsinki University (cropped).jpeg, without opening a file try to guess what crop was made. Is it a single stamp being cropped from a sheet of stamps? Is it the main building of the university cropped from the picture on the stamp? Is it the cancellation mark of the stamp? Is it something else? In either case, the answer "I don't know" is the best one. When I crop something, I do my best to give it a good name, but I see so many people who do not bother. Would it be possible to add a warning to the crop tool to stimulate users to select a better name? ℺ Gone Postal (〠 ✉ • ✍ ⏿) 10:32, 19 October 2026 (UTC)

There is already a (minimal) warning, "Consider updating the filename." It might be good to reword that a bit more expansively, but we are still faced with the fact that many people blast past warnings. Pinging @Doc James any thoughts?- Jmabel ! talk 23:52, 19 October 2026 (UTC)

We also do not want to frustrate people editing either. We could definitely change "Consider updating the filename." to "Please change the name to something more descriptive." Doc James (talk · contribs · email) 00:37, 20 October 2026 (UTC)

I am not sure I agree that the filename suggested by CropTool is always bad. As a rule of thumb, I use that filename whenever I am cropping a border or perform a similar task, and change it whenever I cropped sufficiently selectively that I will also have to update the description and possibly the categories of the file. I think that differentiating a version cropped for use vs uncropped for reference with "(cropped)" appended to the filename is quite a reasonable convention. Felix QW (talk) 07:00, 20 October 2026 (UTC)

It's about 50-50, depending on the nature of the crop. I'd change "Consider updating the filename" to "If the filename is not appropriate for the crop, please use a more descriptive name." - Jmabel ! talk 05:05, 21 October 2026 (UTC)

Copyright claims

to what extent are statements about copyright of commons uploads trusted as is?

there're two big groups of files:

1. author = uploader, and source = template:own
2. source and author are both well documented (e.g. imports from other organisations' websites/social media)

however, sometimes files fall out of these two groups. uploaders make a claim that the author is their spouse/parent/child/friend... and they have the permission to upload the files under the chosen licences.

how does commons community view these claims? if they are not trusted, what additional proof is needed? RoyZuo (talk) 18:02, 15 October 2026 (UTC)

In cases of minors of which the guardian executes the upload, it's legally the same as "own", at least when speaking of people below any age limits where one can begin to make contracts. The others: it'll likely be strictly case-by-case and depending upon circumstantial evidence and the discretion of the admin, license reviewer or patroller. I really doubt that there can be any kind of common rule or guide. Regards, Grand-Duc (talk) 18:28, 15 October 2026 (UTC)

Ah, and any matter of proof is a VRT task. Grand-Duc (talk) 18:28, 15 October 2026 (UTC)

I have two different views here (five Jews, six opinions): As an admin, I always advise that people make the situation on upload as "clean" as possible, and eEven in situations where I personally would assume good faith, once someone has challenged an image on the basis of insufficient evidence of license, as an admin I have to support Commons policy. Personally, I think we place an over-heavy burden in some respects, and that the precautionary principle goes farther than I would want to go.

Examples:

• I'd be much more inclined than Commons currently is to accept it when notable people upload a photo of themself taken by someone else, identify the photographer and assert that they have been granted broad enough rights to allow dissemination. I'd certainly want an explicit assertion of that, and take very seriously anyone who claimed that the photo was their work and that they did not grant such rights, but I'd make an assumption of good faith. Currently, Commons does not do so.
• Old photos from a family album are often orphaned works because no one remembers which family member took the photo. Unless we are dealing with very notable people (e.g. a childhood photo of a future monarch or major pop star), those photos probably have no economic value. In any context other than Wikimedia projects, I would readily use such a photo with a "courtesy of" credit and expect to deal with the vanishingly small possibility that some other family member, etc., has a clear claim on the copyright and wishes to enforce it. Currently, Commons does not do so.

Jmabel ! talk 18:37, 16 October 2026 (UTC)

one point i forgot to mention, is that obviously both the uploader and the alleged author are not public figures. if either one of them are, it's not difficult to obtain some form of verification.

my scepticism is on the logic behind certain users' demand for "additional proof". when the uploader's statement is questioned, "additional proof" is nothing but another statement from a person behind the internet. it's not any more verifiable than the uploader's statement. RoyZuo (talk) 09:23, 17 October 2026 (UTC)

There are factors that could be checked, especially when speaking about cropped or altered imagery: a JPEG directly out of camera, a raw file, EXIF with a name, a description of the circumstances of the shot... I hope that VRT could be a non-public venue for contributors unwilling to post this kind of somewhat private info publicly; but such data is certainly able to serve as circumstantial evidence fostering authorship claims. Regards, Grand-Duc (talk) 09:55, 17 October 2026 (UTC)

October 16

Senate Bill 2424 and House Bill 11566 from the Philippines concerning online safety for children

Resources: Senate Bill 2424 and House Bill 11566.

Both pending bills aim to ensure "safety of children" in the Philippines, away from "harmful" Internet content most especially social media and other high-risk websites and platforms. This is made possible by age verification or age assurance measures.

Senate Bill 2424 key provisions

• Section 3(h) defines a social media platform as "an electronic service that primarily facilitates online social interaction, enabling two (2) or more users to link, communicate, or interact with each other, or allows them to create, upload, publish, share, or post content accessible to other users."
• Section 3(c) defines a covered social networking function as "a feature of an electronic service that enables users to establish or maintain social connections; communicate or interact with other users beyond communications strictly necessary for the underlying service; participate in public, semi-public, or discoverable communities; maintain friend, follower, subscriber, or similar user connections; or create, upload, publish, stream, share, distribute, access, or view user-generated content, including livestreamed content, made available by other users."
• Section 3(d) defines harmful content as "online content, including livestreamed content, that: (1) constitutes or facilitates sexual abuse, exploitation, or trafficking of children; (2) depicts, promotes, encourages, facilitates, or provides instructions for ongoing or graphic violence, suicide, or self-harm; or (3) directly encourages, facilitates, or provides instructions for conduct presenting an imminent and substantial risk of death or serious physical injury to a child."
• Section 3(e) defines high-risk digital services as "social media platforms and online gaming services with covered social networking functions, such as but not limited to, Meta Platforms, Roblox, and Gorebox."
• Section 6 provides a restricted list of exempted platforms, but with one major caveat. With underlines added by me here as emphasis:

The following digital services and functions shall not be subject to the provisions of this Act:

(a) Electronic mail services;
(b) Private messaging services limited to private or closed communications which do not feature any public, semi-public, or discoverable, community-based, follower-based, or other social networking functions;
(c) Online gaming services, primarily for gameplay whose communication or similar functionalities or features are strictly incidental to such gameplay: Provided, That covered social networking functions offered by such services shall not be excluded from the coverage of this Act: Provided, further, That the functionalities or features including voice or text chat, shall be subject to the age restrictions and age-assurance requirements under this Act: Provided, finally, That child safety measures shall also attach to the gameplay functions when made accessible to children, taking into account their differing and evolving capacities;
(d) Educational platforms used for instruction, learning, assessment, or school administration, where access is limited to students, teachers, school personnel, parents, or other authorized users and user interaction is limited to legitimate educational purposes;
The Department of Education (DepEd), Commission on Higher Education (CHED), and Technical Education and Skills Development (TESDA) shall issue joint guidelines on the standards and procedure for certification. The Department of Information and Communications Technology (DICT) shall maintain and publish on its website, a consolidated list of certified platforms and services, which shall be updated every quarter.
(e) Digital news services; and
(f) Enterprise, workplace, or professional collaboration services where access is limited to members or authorized users of an organization and which do not provide public or discoverable covered social networking functions.

The foregoing exclusions shall apply only to the service or function described herein and shall not exempt any covered social networking function that would otherwise fall within the coverage of this Act.

• Section 5 states:

No child shall be permitted to register, create, access, use, or maintain an account on any high-risk digital service. This prohibition is absolute and shall not be waived by parental or guardian consent, authorization, or supervision, under any circumstance.
In the case of an online gaming service or other electronic service that offers both covered social networking functions and functions not so covered, the minimum age requirement shall apply only to the former and not to the entirety of the platform or service.

• Section 3(b) defines a child as "a person below eighteen (18) years of age."

House Bill 11566 key provisions

• Section 3(r) defines a social media platform as "any internet-based service, network, application, website, or software whose purpose is to facilitate online social networking or allow the creation, sharing, or dissemination of user-generated content. The term shall not include the following: (1) Electronic mail services; (2) Short messaging services: (3) Private messaging services without public or discoverable social networking functions; (4) Educational platforms and enterprise, workplace, or professional collaboration tools, approved by the Department of Education (DepEd) or other national government agencies concerned; (5) Digital news services; and (6) Government digital services."
• Section 3(s) defines a user-generated content as "any information, material, or content created, uploaded, posted, transmitted, shared, streamed, published, or otherwise made available by a user through a digital service, including text, images, photographs, audio, video, livestreams, software, comments, messages, and other forms of digital expression."
• Section 3(g) defines a functionally equivalent digital service as "a digital service that is not nominally a Social Media Platform but performs core social-networking, content-sharing, communication, user-interaction, livestreaming, or substantially similar functions and presents child online safety risks substantially similar to those addressed under this Act."
• Section 3(h) defines harmful or prohibited content as "content that promotes, glorifies, encourages, facilitates, or provides instructions for violence, self-harm, violent extremism, including nihilistic violent extremism and other emerging forms thereof, sexual abuse and exploitation, or other conduct that constitutes a serious and foreseeable risk to the safety or well-being of children, or contains deepfake or synthetic media that realistically simulate, fabricate, modify, or imitate the appearance, voice, likeness, actions, or statements of a real or fictional person, object, or event for the purpose of misinformation."
• For Coverage (Section 4), with underlines added by me here as emphasis::

This Act shall apply to all Digital Platforms that are accessible, offered, or made available to users in the Philippines, regardless of their place of incorporation, principal place of business, or location of their servers.
For purposes of this Act, an Online Gaming Platform shall be covered only with respect to its social, communication, content-sharing, livestreaming, user-interaction, recommender, or other interactive features and functionalities. Nothing in this Act shall be construed to diminish, exclude, or transfer the existing jurisdiction, regulatory authority, or enforcement powers of Philippine Amusement and Gaming Corporation, the Games and Amusements Board, the Movie and Television Review and Classification Board, or other competent government agencies over matters within their respective mandates, except to the extent expressly provided in this Act with respect to child online safety risks arising from covered social or interactive functionalities.
Coverage under this Act shall be determined by the Office created under Section 8 herein based on the actual functions, features, and risks of a service, rather than solely on its name, stated purpose, business model, or manner of marketing. The said Office may make a written determination of coverage based on such statutory criteria and standards, subject to notice, due process, and applicable remedies in accordance with this Act.

• Section 8 refers to the duties and responsibilities of the to-be created SAFE Kids Office ("Office for Safe and Friendly Environment for Kids in Digital Spaces").
• Section 5 states:

No Social Media Platform, Functionally Equivalent Digital Service, Application Distribution and Operating System Provider, or Online Gaming Platform with respect to its social, communication, content-sharing, livestreaming, user-interaction, or other interactive features and functionalities, shall allow a person below thirteen (13) years of age to create, register, maintain, or use an account or otherwise access such service or features.
Upon determining or becoming aware that an account is being maintained or used by a person below thirteen (13) years of age, the Digital Platforms shall, without undue delay, disable the account and take reasonable, proportionate, and privacy-preserving measures to prevent its continued use or recreation.

• Section 6 allows children and teens (aged 13 to 17) to retain accounts, subject to parental consent, but they are restricted from viewing or utilizing the following features: "(a) Harmful or Prohibited Content; (b) Advertisements; (c) Recommendations; (d) Communications and interactions; (e) Livestreaming; (f) Endless scrolling; (g) Short-form video feeds or “shorts”; (h) Behavioral profiling; (i) Unnecessary collection or sharing of personal information; (j) Purchases; (k) Gambling-like mechanisms; and (l) Other features or practices that may pose reasonably foreseeable and material risks to the safety, health, privacy, development, education, sleep, or well-being of children."

My informative notes

One can notice the extensive usage of "or" conjunction instead of "and" when defining what website or platform is a social media platform. Using the Senate Bill version as example: "an electronic service that primarily facilitates online social interaction, enabling two (2) or more users to link, communicate, or interact with each other, or allows them to create, upload, publish, share, or post content accessible to other users." This means, even if a website does not have the primary function to facilitate social interaction online, a website or platform that allows 2 or more users to share, create, or publish content that can be read by other users is deemed a social media. The House Bill has a nearly identical definition, utilizing "or" instead of "and" in connecting the two important clauses defining a social media platform. Wikimedia platforms like Wikimedia Commons are likely covered by the specific definitions.

The House Bill provides an additional safeguard in case a platform fails the usual characteristic of a social media platform, in the form of "functionally equivalent digital service." The definition also uses "or," not "and": a digital service that is not nominally a Social Media Platform but performs core social-networking, content-sharing, communication, user-interaction, livestreaming, or substantially similar functions and presents child online safety risks substantially similar to those addressed under this Act.

The Senate bill's definition of a covered social networking function also uses "or" and not "and": "a feature of an electronic service that enables users to establish or maintain social connections; communicate or interact with other users beyond communications strictly necessary for the underlying service; participate in public, semi-public, or discoverable communities; maintain friend, follower, subscriber, or similar user connections; or create, upload, publish, stream, share, distribute, access, or view user-generated content, including livestreamed content, made available by other users."

It remains to be seen if the DICT would be rigid in interpreting "or" or give flexibility to treat "or" as an "and." Flexibility would exempt Wikimedia from age verification mandate under the Senate Bill (but may not be under the House Bill due to "functionally equivalent digital service" term.

From the Senate Bill's Section 6, educational platforms would be given exemptions, but only if those are certified by three government agencies that administer education in all levels (DepEd for pre-school to high school, CHED for tertiary/college, and TESDA for technical-vocational), and the condition is that "access is limited to students, teachers, school personnel, parents, or other authorized users and user interaction is limited to legitimate educational purposes." The list of the certified educational platforms would be updated by the country's information and communications technology agency (DICT) every quarter. Moreover, the concluding paragraph of that section does not exempt the "social networking functions" of the exempted platforms. Again, the Senate bill defines this as "a feature of an electronic service that enables users to establish or maintain social connections; communicate or interact with other users beyond communications strictly necessary for the underlying service; participate in public, semi-public, or discoverable communities; maintain friend, follower, subscriber, or similar user connections; or create, upload, publish, stream, share, distribute, access, or view user-generated content, including livestreamed content, made available by other users."

Reddit forum

H.B. 11566 - SAFE KIDS ACT encompasses more than Social Media. It includes Banning Children from Using Operating Systems. This also means EVERY WEBSITE (that requires account-creation) will have consistent Age Assurance Checks to prove users are not minors. They also need license to operate in PH. Here are the relevant excerpts from the post by "territorialfantail":

• Functionally Equivalent Digitial Service (idk the definition is VERY VAGUE maybe Twitch, Youtube, and most art and fiction sites, Deviantart, pixiv, photobucket, flickr, etc).
• Basta (in Tagalog, English is: It's just that) anything that has "information, material, content that is created, uploaded, posted, transmitted, shared, streamed, published, or other wise made available by a user through a digital service, including text, images, photographs, audio, video, livestreams and other forms of digital expression" WILL NOT BE ALLOWED TO BE ACCESSED BY CHILDREN.
• One of the questions: How about non-profit websites such as archives and wikis that do not use ads and do not generate revenue? Are they part of this Ban as well? What if they do not have the framework for Age Assurance Checks? How would they able to establish a business license here? Would they ban archives from the PH Web? What about preservation of lost media? What about preservation of history and of stories? Or are we not allowed this also?

Note, Flickr mentioned by territorialfantail as among the possible platforms covered by the definition of "functionally equivalent digital service." As well as DeviantArt and Photobucket. The user also asks if "wikis" and non=profit websites (but allow user accounts and user interactions) are also covered.

Final informatory note from me

Both Senate Bill 2424 and House Bill 11566 are still pending harmonization. Both have been passed on third and final readings in their respective chambers of Congress. Due to noticeable differences between two versions, they will be harmonized in a bicameral session. Furthermore, both measures still require the DICT to create implementing rules and regulations (IRR) within 90 days from the effectivity of the law (Section 27 of Senate Bill, Section 41 of House Bill) even after the president's signature, with participation from all concerned government and law enforcement agencies, child safety and psychiatric associations, the National Youth Commission, recognized child rights orgs, and other stakeholders.

_ JWilz12345 (Talk|Contributions) 15:50, 16 October 2026 (UTC)

October 17

5000 media needing categories as of 2023

By now, 5000 media are listed in Category:All media needing categories as of 2023. A small team of volunteers started categorizing them in February 2025, when still 95,000 files had to be categorized. Now we look for experienced Wikipedians, who categorize the remainder file by file. Do you want to help us, please, or do you have a recommendation, how others could do this more efficiently? --NearEMPTiness (talk) 08:54, 17 October 2026 (UTC)

Now, we got stuck at the letter "L" and need more volunteers, please. --NearEMPTiness (talk) 01:21, 21 October 2026 (UTC)

any interest in AI assisted categorization? i've been considering working on a tool that suggests categories given image content, text, date and coordinates. BrokenSegue 01:27, 21 October 2026 (UTC)

I'd say over 1000 files done in 3 days is pretty good progress, assuming most of those have been done well. - Jmabel ! talk 05:07, 21 October 2026 (UTC)

A lot of the remaining files have names in languages other than English. I see quite a few in various Romance languages; native speakers of some of those languages might make some progress pretty quickly. - Jmabel ! talk 05:10, 21 October 2026 (UTC)

@BrokenSegue: I think that AI will be very useful for such tasks in future, at least to give suggestions. From my point of view, it will be even more useful for the backlogged 2025 and 2026 categories than for those of 2023, because in 2023, the low hanging fruit such as sunsets, beaches, diagrams and charts have already been harvested. Please consider describing your concept on Commons:WikiProject Minimum One Category. --NearEMPTiness (talk) 06:55, 21 October 2026 (UTC)

If anyone can read unusual alphabets, please check the blue box in the right-hand-side column of Category:All media needing categories as of 2023 and also Category:Uncategorized files by language of description. NearEMPTiness (talk) 07:01, 21 October 2026 (UTC)

That is great! However there are about 400K files are still uncategorized, and even more uncategorized files are undiscovered due they are uploaded with other mass upload tools such as Flickr2Commons etc as they don't add the Uncategorized template when uploaded without categories. 6D (talk) 04:18, 22 October 2026 (UTC)

There's an ongoing, large-scale abuse of adding files with clearly identified people or places into "Unidentified" categories, adding no other categories, and walking away calling the file categorized. Are categorization drives like this (I've seen quite a few on this page in recent times) encouraging this abuse? RadioKAOS / Talk to me, Billy / Transmissions

Regarding uploading images of an abandoned radar station

Hello yall, A couple years ago, I went to Lefkada and made my way to the abandoned radar station and took some pictures. However, due to it being basically a military installation, I don't know whether I am allowed to upload pictures of the site, even though I have seen other people on the Internet do it, such as in Google maps, while the area is also fully visible on satellite images and not blurred. I'd like some advice on this matter if possible. Thanks! Oakchris1955 (talk) 12:01, 17 October 2026 (UTC)

I think we have to see it from different aspects. First of all: You probably entered private property, so you would need permission from the property owner. I think things like copyright protection on buildings is irrelevant here. As the radar station is abandoned, so longer in use, I do't think it is a photograph-restricted military installation. As Commons only cares about copyright, you are solely responsible for the other aspects :3. Hope that helps! --PantheraLeo1359531 😺 (talk) 12:10, 17 October 2026 (UTC)

Not sure about Greece, but e.g. in Poland there are lots of abandoned military installations in the woods, and it's fine to take pictures of them and upload them AFAIK. Many of them are even museums. I would be hesitant if there were any "no photography" or "restricted area" signs, though. Nux (talk··dyskusja) 12:10, 17 October 2026 (UTC)

It's fine. Specifically, the Greece authorities do not enforce a photography ban there, nor is it banned to walk around the site. There's no copyright issue (e.g. special rules about permits for ancient sites), nor in reality any other legal issue. Fæ (talk) 12:11, 17 October 2026 (UTC)

Category:Military operations by country by war

Is anyone able to get rid of the error messages (and the red/maintenance categories)? They seem to be triggered by “war”. --Leyo 21:03, 17 October 2026 (UTC)

Fixed, there shouldn't be displaying any more errors for that category page. Thanks. Tvpuppy (talk) 22:29, 17 October 2026 (UTC)

October 18

October 2026 Wikimedia Café: legal issues on Commons, and WMF Board selection process

Hello! There will be two Wikimedia Café discussion opportunities in October. In a change from the usual Café practice, this month's sessions will have different topics. Anyone who meets the Café attendance criteria is welcome to attend either or both sessions.

Session A will happen on Saturday, 24 October 2026 at 15:00 UTC (timestamp converter), at a time friendly to the Americas, Africa, and Europe. This session will feature Wikimedia Foundation lawyer Phil Bradley-Schmieg. We will discuss legal issues on Wikimedia Commons, including complexities of international law. (I am hoping that in a future month, a similar Café session will be offered at a time friendly to Asia and the Pacific.)

Session B will happen on Sunday, 25 October 2026 at 03:00 UTC (timestamp converter), at a time friendly to Asia and the Pacific, we will discuss proposed changes to how Wikimedia Foundation Board candidates are selected. The latest proposals are much different from the earlier July 2026 proposals. The due date for feedback on current proposals is 27 October, and Wikimedians are welcome to participate on the proposal talk page regardless of Café attendance.

Please see the Café page for more information, including how to register!

To subscribe or unsubscribe for Café notices on your talk page please go here.

༄ᨒ𖠰 Pine (✉) 06:10, 18 October 2026 (UTC)

Imagery of DPRK/USA from the 1990s

The United States had several exchanges with North Korea. Jimmy Carter travelled to Kim Il-Song and Madeleine Albright had talks with North Korean politicians. Are there changes that public domain or free images exist from the DPRK and USA from the 1990s that are not on Commons yet? --PantheraLeo1359531 😺 (talk) 11:46, 18 October 2026 (UTC)

Carter appears to have gone to North Korea in 1994, but not found any photos on Commons. I see his trip to Seoul in photos from the 80s. If there's a source it would be a neat upload if the photographs are official. Fæ (talk) 16:31, 18 October 2026 (UTC)

The image of Jimmy Carter and Kim Il-Song at [6], credited to Rodong Sinmun, would seem to be {{PD-North Korea-exempt}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:56, 18 October 2026 (UTC)

• Another verison, whose caption translates to "front page of the June 18, 1994, issue of Rodong Sinmun".
• Color version, attributed "KCNA" (Korean Central News Agency).

Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:16, 18 October 2026 (UTC)

Albright & KJI in 2000, credited "DPRK's Foreign Language Publishing House". Likely also NK-ineligible. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:38, 18 October 2026 (UTC)

fuller version, also colour Credited AP but clearly the same image. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:42, 18 October 2026 (UTC)

Thank you for you analysis :) --PantheraLeo1359531 😺 (talk) 06:46, 19 October 2026 (UTC)

I did some research, too. https://picryl.com/search?q=state%252Bmadeleine%252Balbright has some public domain claimed images, but wasn't able to check yet. --PantheraLeo1359531 😺 (talk) 06:49, 19 October 2026 (UTC)

How would this photograph fall under {{PD-North Korea-exempt}}? The template makes no mention of photography. – Howardcorn33 (💬) 18:50, 19 October 2026 (UTC)

It refers to "works". Photographs are works.

See also the various images in Category:PD-North Korea-exempt. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:49, 19 October 2026 (UTC)

The template includes as works not protected by copyright "documents for state management", "current news" and "information data", nothing about photography. – Howardcorn33 (💬) 19:53, 19 October 2026 (UTC)

Per here, Carter's 1994 visit to North Korea was as a private citizen as a negotiator, not as a government official. Any photos I could find from the meeting are credited to the Carter Center, which is an NGO unaffiliated with the US government and as such their photos are not in the public domain. – Howardcorn33 (💬) 19:50, 18 October 2026 (UTC)

Someone could contact the Carter Center to try to get something free-licensed. - Jmabel ! talk 20:30, 18 October 2026 (UTC)

That would be marvelous! Could somebody do this? Or is there a wishlist page on Commons where you can hand over that wish? :) --PantheraLeo1359531 😺 (talk) 06:47, 19 October 2026 (UTC)

Commons:Permission requests appears to have a long, neglected backlog, so I'm not sure there is any useful way for someone to ask for someone else to do this. - Jmabel ! talk 23:55, 19 October 2026 (UTC)

Thank you, maybe I will find another idea :) --PantheraLeo1359531 😺 (talk) 08:00, 20 October 2026 (UTC)

October 19

Copyright artworks

There are a large number of closeup pictures of pieces of art London, England that were created in 2013 located in Category:Labyrinth (Art on the Underground) by number. This is the English Wikipedia page about the artworks. Would I be right in thinking that these are all copyright violations? If not, what am I missing? Thanks. -10mmsocket (talk) 12:17, 19 October 2026 (UTC)

You are probably right - these don't seem to be covered by UK FoP as they appear to be "graphic works" as understood in UK law. There's probably an argument to be made that we could keep on threshold of originality grounds, but I would say these are most likely copyrightable in the UK. 19h00s (talk) 12:44, 19 October 2026 (UTC)

→ Deletion requests/Files in Category:Labyrinth (Art on the Underground) by number. Fæ (talk) 13:36, 19 October 2026 (UTC)

Thank you so much for that. 10mmsocket (talk) 15:03, 19 October 2026 (UTC)

Renaming photos of cosplays

REcently I tried renaming this file, because the title mentions only Batman, but in the image there are plenty of cosplays and Batman isn't even the more prominent. The user @Ooligan rejected my request because, as he said "current name is not meaningless or ambiguous". I would argue it's a lot ambiguous, since the title imply in the image everyone is a cosplayer of Batman. Can the title be changed? If so, by which criterion? Mikirito 07 (talk) 19:37, 19 October 2026 (UTC)

The others are also characters from or primarily associated with the world of Batman, so I'd say the current title is fine. --HyperGaruda (talk) 20:02, 19 October 2026 (UTC)

The Question (the character on the right) isn't from or primarily associated with the world of Batman, and it's a pretty prominent subject in the picture. Mikirito 07 (talk) 20:11, 19 October 2026 (UTC)

P.S. I also requested renaming this file, because the title mentions only the cosplays of Batman villains, but in the picture there are only three Batman villains, a Batman cosplayer and a Wonder Woman cosplayer. The request has also been declined. Mikirito 07 (talk) 20:13, 19 October 2026 (UTC)

Those are file names, they don't need to be that precise. If you want to describe in detail including people not really facing the camera... Well you can do it in the description. Personally I would not event mention WW in short description. Nux (talk··dyskusja) 22:54, 19 October 2026 (UTC)

Ok, I understand the point. Mikirito 07 (talk) 21:52, 20 October 2026 (UTC)

Mikirito 07, you were advised weeks ago that continued spurious file rename requests might result in a block. Please stop. If you have to ask "by which criterion", that means that the title does not need to be changed. CMD (talk) 00:47, 20 October 2026 (UTC)

I'm sorry, but most of my renamings requests since I was advised has been accepted, so I thought I was doing a good job. Mikirito 07 (talk) 21:53, 20 October 2026 (UTC)

In general it is best to let file name stand if it is not disrupting anything. And these file names are perfectly ok. I do request file renames every so often, but in general the reasonable names like these should not be moved. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 08:40, 20 October 2026 (UTC)

You may also wish to read through the discussion on #Keeping arbitrary/non-descriptive titles of artworks by non-notable artists as file names further up on this page. TommyG (talk) 06:49, 21 October 2026 (UTC)

We try to keep original file names intact as much as possible, as others have pointed out, and as such it's against policy to rename a file to make the title "better" (see COM:FRNOT). A lot of your requests try to make a file name precise, which tends to also make them very long; the sort of information you wish to convey in file names is better suited to its description. Imprecise file names aren't a problem that needs fixing.

If you want to play it safe, and not run afoul of other people or Commons policy on this front, perhaps it's a good idea to focus on file descriptions rather than file names for the time being. ReneeWrites (talk) 09:19, 21 October 2026 (UTC)

October 20

Randomly tagging people's uploads as AI

Hello,

I have recently updated a wikipedia page with a real picture, and a day later, that picture was tagged by someone as being AI. Now the picture has been removed even though I replied to the accusation and proposed more proof.

• The Wikipedia page I updated: https://fr.wikipedia.org/wiki/%C3%80
• My image: File:A_accent_grave_sur_papier.jpg
• The AI tag accusation: Commons:Deletion_requests/File:A_accent_grave_sur_papier.jpg

Now my question is: What am I supposed to do to proof that this is not AI other than what I already told that person?

• On a notebook on my desk, I wrote words in relation with the article.
• I took a couple pictures of that text with the pen visible for style.
• I uploaded the pictures to my PC and selected the one I wanted to use.
• I updated the wikipedia page with that picture.

Thanks in advance. — Preceding unsigned comment added by TrynePlague (talk • contribs) 10:25, 21 October 2026 (UTC)

I've answered in the Commons:Deletion requests/File:A accent grave sur papier.jpg (assuming you were fine with French). Regards, Grand-Duc (talk) 11:53, 21 October 2026 (UTC)

[7] The nomination for deletion is rejected, and the image reinserted into the article. Taylor 49 (talk) 13:09, 21 October 2026 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. 2026-10-21

Does "President Venn Diagram" count as copyrighted or ineligible?

Hello, I wanted to ask about this particular xkcd comic strip, President Venn Diagram. It is just text with a venn diagram, would it be copyrightable or not?

Thanks. — Preceding unsigned comment added by KittyTeggie (talk • contribs)

Any iota of creativity generates copyright. The choice of where to put the text "Eligible to be president" for example, was an artistic choice. It could have been lower or higher. In other words it is protected by the copyright. However, let's say you create a venn diagram with the same categories, but would close this commic and create it from scratch all by yourself. You would be a copyright holder. Text "Eligible to be president" and "Would be a good president" is so short that you simply cannot express it in many other words. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 08:03, 22 October 2026 (UTC)

@Gone Postal: I don't think you are right about "any iota". For example, I could take an American flag and turn the third star from the left upside down, or paint it green. That would not be copyrightable. - Jmabel ! talk 23:28, 22 October 2026 (UTC)

I am not a lawyer, but as I understand it, it would depend on how you were to do it. Let's say that while painting it green you don't just do generic fill-area on GIMP, but create your own brush, decide that you will do it in 7 strokes and then in those 7 strokes paint that star green, that would be copyrightable. Painting with fill-area does not actually preserve any creativity, because you selecting to fill one pixel vs the pixel on the other side of the star will result in the same image. However, in this analogy the concept of filling in one star green is not copyrightable, and somebody else can fill that same star green with the exact same number of stokes, and not violate my copyright because their strokes are different. Now returning back from analogy to this case, we have a venn diagramme of 3 circles, draw them yourself and you will notice that your circles will not be the exact circles that the creator of xkcd drew. Drawing three circle venn diagramme is not copyrightable, asking some tool to generate you three circle venn diagramme is not copyrightable, but drawing a specific 3 circle venn diagramme with text written so that it creates a visual flow of the joke creates the very specific image that is. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 01:48, 23 October 2026 (UTC)

SDC "depicts", especially for people

I've spent way too much time today slogging through issues raised at COM:HD#Is ICE showing up when searching "white supremacists" an intentional choice?. The TA posting there keeps adding more cases, and I'm really not interested in doing all of their legwork. However, they raise a very valid issue, in an area where I rarely work.

To what extent do "depicts" values like right-wing extremism (Q204481), QAnon (Q51213808), conspiracy theory (Q159535), fanaticism (Q489750), fascism (Q6223), antisemitism (Q22649), disinformation (Q189656) belong on photos of politicians? To what extent to "depicts" values like white supremacy (Q698752), fascism (Q6223), brutality (Q2927094), violence (Q124490), deportation (Q379693) belong on photos of reasonably normal arrests by United States Immigration and Customs Enforcement (Q943091), where we do not know the ethnicity of the arrestees, whether these individuals were indeed deported, etc.? I would say not at all. "Depicts" is not supposed to be about the vibe the photo gives us (white supremacy), or what we think of the person in the photo, or what might later have happened (deportation), or what we think the same person might have done on another occasion (brutality). It is supposed to be about what the file depicts, no more, no less. - Jmabel ! talk 04:21, 22 October 2026 (UTC)

While on a personal level I believe that any depiction of ICE is a depiction of fascism, I also think that such personal beliefs will only cause disruption on Commons. Thus it is probably incorrect to add them to a photo of an arrest by ICE. Just like a picture of people sitting around the camp fire holding hands and smiling does not depict "wokeness". I do not use structured data pretty much ever, but I would expect it to be structured (pun intended) in such a way that an automated system can get something from it. this stamp depicts number 6, it depicts an overprint, it depicts Alolph Hitler, it depicts mustache, it depicts right ear; but it does not depict the ideas of Hitler. I can tell you exactly which pixels are right ear of Hitler, but cannot find pixels of anti-semitism or social nationalism. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 07:57, 22 October 2026 (UTC)

A naive method might be to block addition of all Q-numbers which aren't subclass or instance of concrete object (Q4406616), but file:Man Ray 1914.jpg could plausibly be said to depict 1914 (Q2083) even though 1914 itself doesn't look like anything. Arlo James Barnes 14:42, 22 October 2026 (UTC)

Does anyone feel that it would not be reasonable to add a paragraph to this effect at Commons:Depicts#What items not to add, or that I need to go through some more formal process (if so, what?) before doing so? - Jmabel ! talk 23:33, 22 October 2026 (UTC)

Since it is not a guideline page or a policy page, I don't think a formal process is required for this. So, I think it is reasonable to just go ahead and add the paragraph. Thanks. Tvpuppy (talk) 23:37, 22 October 2026 (UTC)

Edited Commons:Depicts at Special:Diff/1290548609#Vibe,_abstractions,_etc.. - Jmabel ! talk 05:36, 23 October 2026 (UTC)

October 22

Central banner for Wiki Loves Food 2026 in India

Wiki Loves Food 2026 in India, a photography contest will take place on Wikimedia Commons from November 1 to November 30, 2026, aiming to enrich content related to food of india. A central notice request has been submitted to reach both registered and non-registered WikiCommons users from India. Thanks. -- Kuldeep (Punjabi Wikimedians) (talk) 15:59, 22 October 2026 (UTC)

How many image are ever in use?

One time someone calculated that 25% of all images are in-use. I thought that sounded too high. I was wondering if someone can calculate again but make sure to not count the ones in use in bot generated galleries. I noticed that some people create galleries for images using a particular license like this: User:Magog the Ogre/PD ineligible/2019 June 1-3. That would inflate the count. We would also have to not count the ones that are nominated for deletion, since they would be used in the gallery view of deletion nominations. Can someone come up with a better count or better definition of usage that avoids deletion debates and bot galleries? RAN (talk) 23:13, 22 October 2026 (UTC)

If "in use" means "in use in other WMF projects" I would guess that it is more like 10%, possibly lower but, no, I don't have a way to determine that either. Maybe something could be done with GLAMourous (once the PHP crisis is worked through)? - Jmabel ! talk 23:43, 22 October 2026 (UTC)

OCR

The website https://ocr.wmcloud.org/ is down for me since yesterday, anyone else having problems? RAN (talk) 23:15, 22 October 2026 (UTC)

Per wikitech:Incidents/2026-10-21 PHP security update/Community, many of the tools and bots have been taken offline, and they are now gradually restoring them. Thanks. Tvpuppy (talk) 23:27, 22 October 2026 (UTC)

Thanks! Yes, I see croptool down too. "no healthy upstream" was the error message. The New York Times archive was also wonky yesterday, so not just the Wiki Universe. --RAN (talk) 23:58, 22 October 2026 (UTC)

October 23

Bug

I have uploaded File:20260723 Pousada de São Tiago (132127).jpg, but the photograph is not shown. There is ‘No file by this name exists, but you can upload it. If a file used to exist, try to purge this page's cache’ only. After clicking ‘purge this page's cache’, the photograph is shown. But after refreshing the page, the photograph is not shown again. --Yumeto (talk) 02:47, 23 October 2026 (UTC)

@Yumeto: Yes. This has been an ongoing problem; several other reports are at COM:Help desk and COM:VP/T. It's some sort of failure to properly sync servers or caches; it will presumably be worked out. - Jmabel ! talk 05:41, 23 October 2026 (UTC)

Renaming Category:Dnistrovskyi Raion, 2020 to Category:Dniester Raion vel sim.

I have nominated Category:Dnistrovskyi Raion, 2020 for discussion with a view to having the category renamed. The discussion may be found at Commons:Categories for discussion/2026/10/Category:Dnistrovskyi Raion, 2020. I am posting a note here about it because the renaming will affect "ten or more categories", which is the threshold for notification according to Commons:Rename a category#Types of renames. 0DF (talk) 13:23, 23 October 2026 (UTC)

Serious sourcing concerns regarding File:Yemeni Civil War.svg

I have raised serious concerns on the file talk page about the reliability of sources used in recent updates to Yemeni_Civil_War.svg and the accuracy of its territorial-control claims. These concerns remain unresolved. I am bringing this here to seek wider community review of the sourcing and disputed areas.

See the existing discussion: https://commons.wikimedia.org/wiki/File_talk:Yemeni_Civil_War.svg امیر میرزازاده (talk) 15:05, 23 October 2026 (UTC)