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/08. 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.

A village pump in Cork, Ireland [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive Policy update for AI content (23 June 2026) Policy update for Renaming of Pdf and DjVu files (14 August 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)

August 13

Removing women from categories

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

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

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

+1 Caffeinated Chihuahua (talk) 05:42, 16 August 2026 (UTC)

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

1. Category:Zohran Mamdani is under Category:21st-century male politicians of New York City which is somewhere under Category:Male politicians of the United States.
2. Category:Politicians of the United States in 2025 has no male or female subcats, and contains women like Category:Pam Bondi in 2025 Category:Kristi Noem in 2025.

what's your point? what's the problem? RoyZuo (talk) 14:17, 15 August 2026 (UTC)

And as we argue this, Category:Memoirists from the United States is being systematically split in to male and female memoirists. - Jmabel ! talk 04:44, 25 August 2026 (UTC)

Draft proposal

[This could either be an addition to COM:OVERCAT or a separate project page; either way, it effectively modifies OVERCAT.]

Nutshell: As a general rule, categories that intersect individuals' gender, ethnicity, religion, or sexuality with some other category should be non-diffusing categories. There are some exceptions to this, which are addressed below.

Rationale: Regardless of intentions, the introduction of categories such as Category:Female guitarists or Category:Jewish classical musicians can lead to ghettoization. Fundamentally, a female guitarist or a Jewish cellist does exactly the same thing as a male guitarist or Russian Orthodox cellist, but when they are sectioned out like this they are separated from their peers based on a characteristic that is irrelevant to the matter at hand. Some of the unwelcome results are:

• One ethnicity is singled out this way, separating them from basically everyone else in their field. Because they are somewhat separated out, they are overlooked for other diffusions of the main category, so they are never categorized by nationality, genre of music, etc.
• In an overwhelmingly male (or overwhelmingly female) field women (or men) are ghettoized with similar effect.
• Diffusing a category by sexual orientation can be particularly pernicious, because it requires you to know something not necessarily obvious about a person to find them in the categorization system, and because there are likely to be very large numbers of people of no publicly declared sexuality.

There are valid reasons to have categories such as Category:Female guitarists or Category:Jewish classical musicians, but they should be implemented as non-diffusing categories.

What does non-diffusing mean? We will need a paraphrase of text from en:WP:Categorization#Non-diffusing subcategories, including our policy on tagging these. Note that we already have {{Non-diffusing subcategory}}, but it is not heavily used.

Exceptions:

The following may be diffused by gender:

• actors
• dancers
• vocalists

The following may be diffused by religion:

• clergy
• missionaries
• theologians
• saints or other venerated individuals, diffused to the religion or religions that venerate them

other exceptions?

Jmabel ! talk 04:10, 15 August 2026 (UTC)

Years ago I remember proposals regarding the same. In general I think that Commons should allow the user to find intersections of categories, rather than having categories intersected by the editors. I upload many stamps, there are categories for stamps by colour, and there are also categories for the stamps by subject, and also for the stamps by face value, and finally by their country. I would hate to see Category:Red stamps of Russia 2026 with the cost 80 that are self-adhesive but do not depict any females while at the same time depicting groups of singers. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 04:23, 15 August 2026 (UTC)

I would just ban intersection categories in general and only define some exceptions. GPSLeo (talk) 05:06, 15 August 2026 (UTC)

Is there a reasonable technology which allows to find intersections of categories for those who need them? What if a person does need to only find Missionaries who are having sex in Missionary position or only those women on photographs who are male? ℺ Gone Postal (〠 ✉ • ✍ ⏿) 11:01, 15 August 2026 (UTC)

If you are looking for photos there is PetScan. When you want a list of people with a given set of properties, you should query on Wikidata and follow the link from Wikidata to category with the photos of this person. GPSLeo (talk) 11:32, 15 August 2026 (UTC)

There is a way to search WikiData using SPARQL. Caffeinated Chihuahua (talk) 05:41, 16 August 2026 (UTC)

makes no sense at all.

why "actors dancers vocalists" are exceptions, but not film directors, choreographers, musicians (instrument players)...? different people in the same job (drama, dance, music) but treated differently? RoyZuo (talk) 14:13, 15 August 2026 (UTC)

These are all performance-based occupations which revolve around the performer's appearance, and where performers are frequently chosen for a job based on their gender. The same principles would apply for athletes and fashion models, for instance. Omphalographer (talk) 20:28, 15 August 2026 (UTC)

that's gonna open more cans of worms.

how gender plays a role in an occupation is complicated and different from one to another.

the idea that actors/performers are hired according to gender, has plenty of counterexamples, e.g. Takarazuka Revue (Q586430): Japanese all-female theatre troupe Q17065438: onnagata (Q2425502): male actors who impersonate women in Japanese kabuki theatre.

then there're jobs that are imbalanced in terms of gender ratio (but to varying degrees in different countries or historical periods), including but not limited to domestic worker (Q54128): person who works within the scope of a residence butler (Q833899): domestic worker in charge of all the household staff nurse (Q186360): type of health care provider school teacher (Q2251335): teacher in primary and secondary education butcher (Q329737): craftsman responsible for the preparation and sale of meat bus driver (Q829020): profession... does the job requirement cause the imbalance? or is it specific cultures, customs and traditions? is gender a factor in hiring? is gender a factor in carrying out of duties?...

for example, for some people and cultures today, female drivers are nothing special. some socialist countries started training female drivers many decades earlier https://www.bbc.com/news/world-asia-china-51116035 . but for some other people and cultures, some would have arguments for why women cannot hold the job of driver, like physique, stamina and whatnot https://www.bbc.com/news/uk-england-birmingham-48367181 https://english.news.cn/20221230/18339a051965424490e9708fde3193c1/c.html . then commons would have to deal with all sorts of arguments before it can decide whether it's useful and reasonable to separate files about a certain occupation by gender. RoyZuo (talk) 22:41, 15 August 2026 (UTC)

there's also a problem with nouns that have a gender, e.g. Category:Governesses Category:Seamstresses Category:Waitresses Category:Actresses. how are those handled?

just like someone said, i also think that intersection cats should simply abolished, so things like Category:Buildings by city by country by material by color get broken up into basic pieces "building" "city" "material" "colour".

but until people agree on that, i dont think there's anything effective in stopping certain users from creating these flaky layers of categories. RoyZuo (talk) 17:49, 15 August 2026 (UTC)

But aren't you then requiring a picture of a green pair of gloves to go under both Green objects and Gloves instead of just Green gloves, thus overloading the more general cats? Arlo James Barnes 22:32, 15 August 2026 (UTC)

1. there's no "overloading". it's perfectly fine if a cat contains millions of files.
2. there's no "more general cats". all should be "general cats" that deal with exactly only 1 aspect. categorise files to answer five Ws (Q368722): questions whose answers are considered basic in information-gathering, but dont combine those answers to create cats like Category:France photographs taken on 2026-05-01. this one mixes where, what, when. problems of this specific one have been raised in 2016 Commons:Categories for discussion/2016/10/Category:September 2007 Finland photographs.

RoyZuo (talk) 22:57, 15 August 2026 (UTC)

I agree that the personal cats could benefit from non-diffusion (and we already have categories like that, the 'flat list' cats which don't allow substructure), but to make it the default I think goes too far the other way. The whole point of categories is that they knit together in such a way, otherwise we would only use/need the structured data statements to describe each file. Arlo James Barnes 01:26, 16 August 2026 (UTC)

On the exchange above between User:Gone_Postal and GPSLeo: I don't really think this particular discussion is the place to make an entirely different proposal that would completely redefine how Commons uses categories. Feel more than free to make a distinct proposal of your own, but it seems you are arguing "don't refine the current approach because I'd like to do everything almost completely differently," and that just really isn't fair, it's a derailing. In case you do plan to make a proposal along those lines, though, I want to point out a use case you may not be considering, where I think the current category approach performs particularly well: when a user starts, not from a rationally formed query, but from one of our files, and thinks "this isn't exactly what I want, but it's close." Right now, they can navigate from the file to a category that seems like it might be promising, and possibly from that to parent and child categories. I would hope that any proposed replacement for the current approach to categories takes that use case into consideration.

@RoyZuo: yes, there are some small number of cases where even for these types of performers, their gender is irrelevant, but I hope you would agree that these are relatively rare cases. Even some of your examples could as easily be seen as counterexamples: the Takarazuka Revue is an all-female troupe, which is pretty much a defining factor for it. Yes, many of their performers play male roles, but that doesn't change the fact that the members of the troupe actually being women is a defining factor in these performances.

Imbalance in gender ratio may be a reason to have a gender-specific subcat for those who are the exception to the rule, but it is absolutely not a reason to make that a diffusing subcat, quite the opposite. The latter is precisely the "ghettoization" problem this proposal is intended to address.

It is possible that the now mostly historical role of a governess might be another case that would call for an exception. Category:Waitresses, however, is simply a gendered subcat of Category:Waiters (with no corresponding specifically male subcat) and with possibly a few edge-case exceptions, waiters and waitresses do the same work. We could arbitrarily make it an exception here, but it would only be because in this case the English language is not our friend. - Jmabel ! talk 23:31, 15 August 2026 (UTC)

I really do like your counterexample of a person finding one file and then searching for another. It is definitely something to consider, and I do not think that there was an attempt to "derail" anything, only placing the discussion in a wider context in order to not make many small patches. At its current point I don't think that going the route of only the top level categories is a good approach, simply because the search function is not a replacement for the specific categories. The reason why I didn't vote for the proposal is because I do not know exactly how to approach this at this moment so that: 1) It will be useful for users 2) It will not create more work for editors 3) It will not need to be immediately reworked again. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 04:47, 16 August 2026 (UTC)

In general, this is a very good proposal, but I do not agree with any of the "exceptions". If you are going to say that male vocalists are not vocalists because they are hired for a particular vocal range, you might as well go straight to "bass, tenor, soprano" etc. categories. Likewise they say that Ginger Rogers did everything Fred Astaire did, but backwards and in heels, so how could you say that Ginger Rogers was not a legitimate dancer. And how could you categorize someone like Augustine by denomination, or some of the missionaries who were primarily notable as linguists.

Categories help editors find images. Removing already marginalized groups from broad categories will make them even less discoverable.

I would support implementing the "non-diffusing" parts now. It seems like the "exceptions" need more work before they can be agreed on. Caffeinated Chihuahua (talk) 05:37, 16 August 2026 (UTC)

@Caffeinated Chihuahua: I think you may be misunderstanding at least one aspect of this. You write If you are going to say that male vocalists are not vocalists and that is not at all what this proposal is saying. We already have Category:Male vocalists and Category:Female vocalists as subcats of Category:Vocalists, and they will remain so.

Also, FWIW, "bass, tenor, soprano" etc. are useful for talking about people with Western Classical vocal training, and less so the farther you get from that. I don't think those terms could usefully be applied to Tuvan throat singing, nor even to many rock vocalists.

Categories are primarily about helping people find things, and only secondarily about ontology. - Jmabel ! talk 07:01, 16 August 2026 (UTC)

Just implement w:en:WP:ALLINCLUDED. Trying to delineate every possible exception is a fool's errand that only ensures we will never reach consensus. w:en:WP:ALLINCLUDED leaves plenty of wiggle room for common sense exceptions. Let's not make the perfect the enemy of the good. Nosferattus (talk) 22:16, 16 August 2026 (UTC)

How can we make this happen? Caffeinated Chihuahua (talk) 02:53, 20 August 2026 (UTC)

i think users should analyse for what purposes is the cat system being used, then you will understand why some users create categories for this and that.

then users can think and decide whether these uses should be fulfilled by the cat system, or whether there are better solutions than using/abusing the cat system; or whether the cat system should be modified. RoyZuo (talk) 18:23, 20 August 2026 (UTC)

 Support Jmabel's draft proposal. I don't see any reason why w:wp:ALLINCLUDED shouldn't also apply to Commons. Currently, subcategories based on gender etc are incredibly inconsistent and sometimes confusing. Better to keep things simple: its harder to miscategorise with this proposal, and less likely to lead to othering. LetmeEditit (talk) 18:45, 22 August 2026 (UTC)

• I  Support the adoption of w:en:WP:ALLINCLUDED on Commons. I  Oppose trying to explicitly list all the exceptions (see my comments further up). Nosferattus (talk) 10:34, 23 August 2026 (UTC)

  @Nosferattus: I'm fine with not attempting to explicitly list exceptions, but I would at least like to include examples: that diffusing by gender makes sense for vocalists, but not instrumentalists, and for actors, but not for directors; that diffusing by religion make sense for clergy, but not for politicians? - Jmabel ! talk 04:51, 25 August 2026 (UTC)

  Sure, listing some examples is fine, IMO. Nosferattus (talk) 05:41, 25 August 2026 (UTC)

   Support proposal by Jmabel to include the given examples as well as per Nosferattus and if possible, adopt or adapt https://en.wikipedia.org/wiki/en:WP:ALLINCLUDED to avoid othering per LetmeEditit -- Ooligan (talk) 02:06, 8 September 2026 (UTC)

  If I want to see images of vocalists, why should I have to choose between looking at male vocalists or female vocalists? It does not make any sense to make the person looking for images jump through more hoops and more layers of subcategories. If they want to refine their search, let them do it themselves instead of creating artificial barriers and hiding them in layers of subcategories. Likewise with religion, it does not make any sense to me that, say missionaries, are hired on the basis of appearance so should be hidden under more categories. This opens up a can of worms for other occupations as well, and does not help with discoverability. I would rather encourage people to add more categories, than take them away. Caffeinated Chihuahua (talk) 06:59, 1 September 2026 (UTC)

See also

• Commons:Categories for discussion/2025/02/Category:SVG by subject

August 23

trying to log in from a new device

It was just now forced to request an e-mail to be sent to me, which read:

it looks like you are trying to log in from a new device on Wikimedia Commons

which is correct. It is also true that I will connect from whichever device I want or need and that’s nobody else’s business. If my username and password combo checks, that should be quite enough. Kindly advice on how to turn off this unnaceptably meddling feature in my Wikimedia account preferences. I’m well aware some people opt to outsource the management of their passwords to disparate parties, but I have been the sole custodian of my own passwords since 1984 and I plan to go on doing so. -- Tuválkin ✉ ✇ 14:08, 23 August 2026 (UTC)

@EMill-WMF. RoyZuo (talk) 15:07, 23 August 2026 (UTC)

This is a mandatory security feature, and has been in place since early 2025. Why we made it mandatory and how it works are described here.

If you find it inconvenient as a practical matter, I'd encourage you to take a minute to enable two-factor authentication, and then add one or more passkeys. This disables the email checks, and if you add a passkey then you should be able to do passwordless login. For many users, that makes the login process simpler than it was than before they turned on 2FA in the first place. EMill-WMF (talk) 18:35, 23 August 2026 (UTC)

It's an interesting post though T408383 is more interesting to read.

Is there somewhere that explains whether emails sent back to confirm it's you using your device are held by the WMF, for how long and for what purposes they might be used? I'm thinking about all the header data that email providers stick on to emails that most volunteers will not be aware of. Thanks

PS for Commons volunteers unaware, there is another trusted approach for recovering your account, see {{User committed identity}}. This works even if you do lose your phone and your email address gets blocked. Fæ (talk) 19:15, 23 August 2026 (UTC)

No email is sent back, so there is nothing for WMF to keep. The way this works is that WMF send you an email with a code, and then you use the code during login. Without taking a position on if this feature is a good idea or overkill, the fundamental problem it tries to solve is that to keep your account secure, requires the user to not give out their password to randoms (reuse their password on sketchy websites), however if they do the consequences tend to effect other people (especially if they have advanced privs) not the person who failed to secure their password. So there is a mismatch between who is responsible and who pays the cost, which is problematic. This tension leads to a lot of suboptimal solutions. Bawolff (talk) 21:01, 23 August 2026 (UTC)

If I misplace my password or foolishly share it with anyone, they my account should be suspended, immediately and without appeal. And the same goes for anyone. Everybody’s right to be logged in from whetever device they want seamlessly and without forcing them to jump through arbitrary hoops is more important than whatever downstream concerns. (The situation described in T408383 is nerve-chilling.) -- Tuválkin ✉ ✇ 23:04, 23 August 2026 (UTC)

And yet when it happens, nobody blames the user and everyone blames WMF for allowing them to be stipid. Classic problem of externalities. WMF just follows their incentives. Personally i think it should only apply to admin accounts. They can do real damage that is annoying, vs a normal account which is mostly no different from any other vandal. Bawolff (talk) 08:50, 24 August 2026 (UTC)

(Incidently, be very welcome back!) -- Tuválkin ✉ ✇ 22:37, 23 August 2026 (UTC)

EMill-WMF says that «This is a mandatory security feature», which, being factual, will dictate my leaving this project. Further advice about TFA and other assorted mesaures of purported computer security I am returning back to sender unopened. I don’t care for borging-together my phone number with my WMF or other accounts for online activites. I find it inconvenient in practice and unacceptalble on ethical grounds: If I forget my password that’s my fault and I don’t expect a non-meatspace outfit to even care about it, let alone forcing me to join this kind of babysitting effort — for which the WMF presumes to snoop whether I’m conecting from the same device as yesterday or not. As far as I’m concerned, that kind of information should not even be stored, let alone used for anything. -- Tuválkin ✉ ✇ 22:53, 23 August 2026 (UTC)

It sounds like you have larger issues with this feature that we probably can't fix for you.

But so you know, none of the 2FA methods require a phone number. You can use an open source TOTP app, or a security key, or really anything that complies with TOTP or WebAuthn. The WebAuthn spec also makes it so the website isn't storing anything that could be connected to other websites, even if you were to use the same device across them. EMill-WMF (talk) 23:26, 23 August 2026 (UTC)

TOTP? Did you miss the bit about me being the sole custodian of my own passwords? That should be an universal expectation, of course. And yet you (here meaning the WMF) presume the opposite — that all users are irresponsible and inept. How’s that for a «larger issue»? I am very invested in my work in Commons, but it is not a meatspace outfit: It should need to know nothing about me iRL than my username and the password I chose for it. If they match upon login, let me in; if not, don’t. Stay out of my choice of devices, my timezones, my typing gait biomechanics, and whatever other feature wannabe spooks think up next. -- Tuválkin ✉ ✇ 00:02, 24 August 2026 (UTC)

TOTP is just a fancy password except the password is chosen for you instead of you chosing the password. Yeah there is a whole app ecosystem surrounding it, but nobody is forcing you to use an app. It does not need to know anything about you IRL. You do not need to use any specific device. Hell, if you were really patient and enjoyed doing large amount of math, you could use pencil and paper. Bawolff (talk) 08:55, 24 August 2026 (UTC)

About this bit: «the password is chosen for you instead of you chosing the password». Herein lies the whole deal breaker: I will always chose my own passwords. All I want and need is to authenticate myself by means of my username and password — from whichever device I want, at the time and place of my liking — and the W.M.F. will log me in if my username + password are a good match, without any further consideration. Is this impossible for the W.M.F.? Please someone answer and be clear about it: If the answer is yes (as suggested by this), I wont be contributing for long. -- Tuválkin ✉ ✇ 20:12, 30 August 2026 (UTC)

You are making assumptions here which are not accurate. As a user, you never interact with your TOTP secret directly, so there is no purpose in allowing it to be selected by a user.

Moreover: as a Commons editor and administrator, you are expected to take appropriate precautions to secure your account. In this day and age, that means using some form of two-factor authentication - whether that be email confirmation, TOTP, or a passkey - in addition to your password. If this is unacceptable to you, I would recommend that you resign your extended rights to mitigate the risk you pose to the project. Omphalographer (talk) 20:36, 30 August 2026 (UTC)

Thanks for the smarmy condescension — it’s made extra funny (or maybe tragic) when you use it to defend the indefensible: No, I wont resign any rights because you say so (feel free to raise the matter in AN/U — it should be enlightening). No, 2FA is not good security. No, I will not blindly follow a trend just because it’s what most do «in this day and age» (that’s why I’m not voting to put fascists in office, unlike so many of my countrymen (yes, mosty men)). As said I will go on as before, with the procedings and precautions that keep my account secure — which include neither 2FA nor TOTP but rather (as wer’re talking acronymese) just TCP/IP and the always necessary AGF. -- Tuválkin ✉ ✇ 20:06, 1 September 2026 (UTC)

Obviously nothing is impossible. However WMF made a decision and it wasn't the decision you wanted. The merits (or lack thereof) is besides the point. The decision is made and it is extraordinarily unlikely this decision will be reversed. What you do in response is up to you. Bawolff (talk) 01:30, 31 August 2026 (UTC)

Thanks for your clarity. I’d point out that although the WMF had to walk back some of its worst decisions a few times due to community pressure, most times it walked back a few steps less than it had originally stepped forth, and in some cases it didn’t even budge. So, it’s what it is. Right now I’m typing this on my laptop after some time “in the provinces up north”. I’ll log off and later log in from my desktop — or at least I will try. Will this be the last time my account login is accepted? We’ll see. -- Tuválkin ✉ ✇ 20:26, 1 September 2026 (UTC)

Ultimately though this decision is not unpopular. There is probably more support for it than opposition across the Wiki-verse (perhaps not represented in this thread but we are talking about this decision years after the fact). WMF has certainly backed down based on community pressure in the past sometimes, but the community has to broadly agree at the very least. For example, if this issue was put to an RFC on meta, i think its more likely that WMF's side would win. A handful of voices isn't going to convince them of anything. Bawolff (talk) 00:53, 6 September 2026 (UTC)

@Tuvalkin you're not alone in this opposition. See Taylor 49's comment at mw:Talk:Product Safety and Integrity/Account Security. JWilz12345 (Talk|Contributions) 23:42, 23 August 2026 (UTC)

Thanks! -- Tuválkin ✉ ✇ 00:02, 24 August 2026 (UTC)

i also share a similar opinion: Commons:Village_pump/Technical/Archive/2026/07#c-RoyZuo-20260705092000-hCaptcha_problem;_more_widely,_privacy_and_surveillance.

if wmf and all wmf sites can gain my confidence by adopting necessary reforms to aim for better governance, i would have no problem about my data being stored and these nuisance things.

but the fundamental problem is wmf is opaque and many sysop+ users are not held accountable for their abuse. and you wanna surveil all users? RoyZuo (talk) 07:16, 24 August 2026 (UTC)

Let's draw the distinction between well meaning employees and contractors for the WMF and a system of good governance for stuff like privacy for volunteers. What we certainly can all agree on is that explaining what this is about and providing re-assurance that data about user logins is necessary so that everyone has a firm written commitment this user data is: (1) not retained or analysed by the WMF (2) the objective is solely to stop accounts being hijacked or other spelled out types of misuse only as far as needed to protect volunteers (3) users are never tracked by WMF staff, devs, stewards etc. using this system of cookies and device tracking.

If the WMF can't provide this re-assurance, then volunteers can and should presume that they are being tracked using this data, and the data could present a future hazard if leaked, hacked or accidentally shared or sold to AI systems. Fæ (talk) 09:08, 24 August 2026 (UTC)

If people are worried about WMF tracking them, I feel like people are focusing on the wrong system. i'd point that tracking people is the entire point of checkuser. Checkuser retains data (including logins and device info) for 90 days. Analyzing it is the checkuser's main job. Login data also gets stored in logstash (i think for 30 days, not sure. 90 at most). Then there is more obscure and restricted systems like wikitech:Data Platform/Data Lake/Traffic/Webrequest. If you want to be conspiratorial, there are the new varnish JWTs which are used to rate limit AI scrapers and was the first time unique identifiers were introduced for logged out users but is impossible to really audit from the outside how they are used. Bawolff (talk) 09:59, 24 August 2026 (UTC)

The answer here is not "other stuff exists" or "(something, something) conspiracy theory". It is an expectation on the WMF to explain how data tracking volunteers for the Wikimedia websites is governed. As you say Checkuser data is supposed to be erased, permanently, for legal reasons, after 90 days. If a trusted Checkuser is found to have kept their own records of this data after 90 days, they shall have the checkuser rights removed and potentially sanctioned by the community or banned by the WMF office for misusing the system (this is not hypothetical, it has happened, it will no doubt happen again). Similarly if an employee or contractor keeps or accesses user data which is supposed to be deleted after 90 days, they shall be in breach of their contract.

It is noticeable that no such reassurance has been given in this thread about the retention of device tracking data. If none is given anywhere, then the presumption can and should be that the data is retained indefinitely for any future purpose, because there is no legal constraint.

This is not a conspiracy theory, these are basic observations about security and privacy. Thanks. Fæ (talk) 10:09, 24 August 2026 (UTC)

My point was mostly: why worry about a hypothetical tracking system, when they openly admit to an actual one? Based on your comment, I take it you meant permanently retained by "retained". I originally thought you meant stored at all, even temporarily.

In regards to checkusers, the official policy actually states that in "rare" cases checkusers are allowed to retain your data for as long as reasonably necessary (beyond 90 days) if it is needed to fight vandalism. I agree that WMF should be willing to justify how they use data, but at the same time if they are going to respond in an official capacity, they probably deserve a few business days to get their answer together. In the mean time, no harm discussing it, since most of the info is already public anyhow. As far as "conspiracy theory" comment goes, i stand by my opinion that some of the comments in this thread have been hyperbolic, accusing WMF of tracking people in ways that simply isn't possible. Bawolff (talk) 10:44, 24 August 2026 (UTC)

To try and make a clear statement - the email authentication checks don't rely on storing anything on our servers about devices, and use the IP data we already have (and already delete).

It's built on an extension called LoginNotify. The "device" part of it is a cookie (loginnotify_prevlogins) that is stored locally, separate from the session cookie, to indicate only whether a device has been successfully logged in from in the past. It isn't associated with the actual account that was used to login from it, and it can be cleared like any other cookie as the user wants. It's mentioned on our cookie statement and is deleted after 180 days.

For the IP part of it, it is pulling from data stored by the CheckUser extension, which (as bawolff mentioned) is already captured for a variety of contributor actions, has an oversight structure around it, and is removed after 90 days (as mentioned in our data retention guidelines, which apply across WMF). So it's using the data we already need to have to run the wikis as they are. EMill-WMF (talk) 19:06, 24 August 2026 (UTC)

btw, partly because of all these wmf nonsense, i started using w:LibreWolf specifically for wmf sites. i'm not tech savvy enough to know how well its Resist Fingerprinting (RFP) works, but i hope it does mitigate some of these intrusions. RoyZuo (talk) 07:29, 24 August 2026 (UTC)

I still use Firefox on my laptop, having switched from Edge in circa May this year and I have to contend to periodic "nerd"-style commands on PowerShell to hard-uninstall Edge after every instance of forced installation, guided by Gemini AI. Will stay on Firefox for sometime, considering LibreWolf isn't yet popular to many data security-oriented netizens here. I have been using Brave on my phone since last year, kicking Samsung Browser out. JWilz12345 (Talk|Contributions) 07:41, 24 August 2026 (UTC)

To the best of my knowledge, WMF is not doing any of the things that resist fingerprinting is meant to resist. At best hcaptcha might (i honestly dont know what hcaptcha does) but hcaptcha is not activated for logged in users. At most it might be activated during login, but only if there are a bunch of failed login attempts. Bawolff (talk) 08:45, 24 August 2026 (UTC)

p.s. I would also add that for people who are worried about fingerprinting and are using firefox, firefox also has a resist fingerprinting option that i believe is mostly similar to librewolf's (im not super familiar with the details). it is just a lot more hidden than librewolf's. Bawolff (talk) 09:14, 24 August 2026 (UTC)

@Bawolff I don't have any concerns on hCaptcha by WMF at this moment. The more pressing concerns are the barrage of online age verification proposals being enacted or proposed worldwide disguised as online/socmed safety laws for minors. The fact that Wikipedia got almost categorized as "Category 1" (only to narrowly escape, for now) under the UK version of the said laws, Online Safety Act of 2023, is somehow disturbing. Imagine that even Wikipedia contributors/users who are based outside UK would need to verify their ages, by virtue of the UK law provisions. It is an utter threat to the foundation of Wikimedia community as a whole. Note that I'm not making this up; it is written at w:en:Wikipedia:Wikipedia Signpost/2026-07-13/Special report: "While the Wikimedia movement as a whole is deeply committed to advancing online safety, the concern has been that, should Wikipedia be deemed a 'Category 1' website, it would be subjected to measures that would interfere with users' privacy and editing rights. For example, Category 1 sites will need to build an identity registration system and then restrict the rights of users, worldwide, if they don't 'voluntarily' register their real ID. This threatens Wikipedia's core values of privacy, safety and community moderation." JWilz12345 (Talk|Contributions) 10:07, 24 August 2026 (UTC)

I also worry about this and the direction internet regulation is going. Bawolff (talk) 10:09, 24 August 2026 (UTC)

@Bawolff: we here, might be among the next. Renewed calls after the w:en:2026 Zamboanga City school shooting. Per the Daily Tribune article, there have also been calls to ban "online games and websites that promote graphic, violent, and distressing crime-related content, including the True Crime Community." Without specific wording to differentiate public interest platforms (e.g. Wikimedia sites) from the likes of Gorebox or TCC, Wikimedia platforms might end up becoming collateral inclusions. Do note that English Wikipedia articles on Columbine, Sandy Hook etc. contain extensive and detailed accounts of the events that might be misconstrued as providing "distressing crime-related content." Additionally, WikiCommons is hosting a few images that may be misconstrued as "distressing crime-related content," notably those media files that the Turkish court Muğla 2nd Criminal Judgeship of Peace once ordered to be taken down. JWilz12345 (Talk|Contributions) 06:30, 26 August 2026 (UTC)

@User:Tuvalkin: I strongly disgree with that change for reasons elaborated on elsewhere (ie pressuring wikimedians into Gugl and overconsumption, two inherently malicious phenomenons). A TOTP client is available. You can run it on your old offline 80486 laptop, or on your moron phone (via some emulator). Taylor 49 (talk) 09:52, 30 August 2026 (UTC)

@Bawolff@RoyZuo well expect the (un)expected as they say. These articles, from Daily Tribune and from ABS-CBN News, must be read in full and some inference and connection between the two must be made. Meta and Discord are the next to be given measures designed to keep the youth from ill effects of online media. One should also take both Wikimedia Foundation's problems in UK (Ofcom's "watchlist" designation on them) and the successful Indonesian measure on Wikimedia Indonesia chapter (which proves that an ASEAN country is not willing to allow a US-hosted platform to escape responsibility over their content being shown to ASEAN viewers/readers). Perhaps one may also remember WMF's warning on Commons administration with regards to this Turkish court order on a CCTV image of a school sh//ting incident in Turkiye. JWilz12345 (Talk|Contributions) 12:35, 1 September 2026 (UTC)

Hopefully, Wikimedia umbrella (Wikimedia Commons, Wikipedia etc.) isn't one of the "other platforms" aside from social media. JWilz12345 (Talk|Contributions) 17:38, 1 September 2026 (UTC)

August 25

A script for renaming and describing files from Special:ListFiles

Special:ListFiles shows a hundred of your files at once, which is where you notice that several still carry camera names, that a description is in the wrong language, or that a whole shoot never got its category. Fixing any of it meant opening each file page and coming back.

I wrote a user script that moves the editing into the list. Every row gets a pencil that opens a small form with the file's name, description and categories, read from the file page itself. Above the table there is a bar that adds or removes one category across the ticked files, and one Save that writes every row you edited.

Renaming goes through action=move and leaves a redirect unless you untick it, so it needs the file mover right. The page edits are deliberately narrow: only the description parameter and the category lines change, sort keys are kept, and a save is refused if someone edited the page while the form was open.

Code and documentation: User:Wilfredor/commons-listfiles-editor. It is new, so I would rather hear now about anything that breaks. Wilfredor (talk) 12:34, 25 August 2026 (UTC)

Thank you, very useful! I'm surprised with how well it preforms, it's actually snappier than normal editing! One small bit of feedback: could you remove the renaming section if the user doesn't have the file rename right? Thanks! LetmeEditit (talk) 12:49, 30 August 2026 (UTC)

Done and deployed. Without the file mover right the name, the reason and the redirect box are not built at all, so the form opens with the description and the categories only. It reads the rights rather than the groups, so an administrator outside the file mover group keeps the field. Unticking the redirect needs suppressredirect, and without that right the redirect is written whatever the box says, so that box is now shown only to accounts that can use it. The same update stops a row that has just been saved from still counting as unsaved, which kept the toolbar at "Save 1 edited file" and made the browser ask before leaving the page. Thanks for the report. Wilfredor (talk) 13:47, 4 September 2026 (UTC)

August 26

Colombian judicial decisions: Article 41 of Law 23/1982 and JEP court rulings

I would appreciate some guidance regarding the copyright status on Commons of official judicial decisions issued in Colombia.

The specific case concerns judicial rulings (autos and potentially judgments) issued by the Special Jurisdiction for Peace (JEP), Colombia's transitional justice jurisdiction. These are official judicial decisions issued by its judicial chambers and Tribunal for Peace and published by the JEP itself.

We are exploring the long-term preservation of this corpus and would like to determine whether faithful copies of the official PDFs may be hosted on Wikimedia Commons. — Preceding unsigned comment added by AmiGueko (talk • contribs) 22:47, 26 August 2026 (UTC)

Colombian law

Article 41 of Colombia's Law 23 of 1982 states:

Es permitido a todos reproducir la Constitución, leyes, decretos, ordenanzas, acuerdos, reglamentos, demás actos administrativos y decisiones judiciales, bajo la obligación de conformarse puntualmente con la edición oficial, siempre y cuando no esté prohibido.

In English, approximately:

Everyone is permitted to reproduce the Constitution, laws, decrees, ordinances, agreements, regulations, other administrative acts and judicial decisions, under the obligation to conform exactly to the official edition, provided that it is not prohibited.

The Colombian National Copyright Directorate (Dirección Nacional de Derecho de Autor) describes Article 41 as a limitation allowing any person to reproduce these materials.

This seems different from the general regime for works created by Colombian public employees. Government works in Colombia are not automatically in the public domain; Article 41 creates a specific rule for legislation, administrative acts and judicial decisions.

The Andean Community's Decision 351 does not appear to contain an identical exemption for judicial decisions, although Article 21 permits Member States to establish copyright limitations and exceptions subject to the three-step test. Article 22 also contains specific permitted uses.

Article 2(4) of the Berne Convention additionally provides that it is a matter for national legislation to determine the protection granted to official texts of a legislative, administrative and legal nature.

— Preceding unsigned comment added by AmiGueko (talk • contribs) 22:47, 26 August 2026 (UTC)

United States

The U.S. side appears clearer.

Section 313.6(C)(2) of the Compendium of U.S. Copyright Office Practices states that government edicts include judicial decisions and further states that the Copyright Office will not register a government edict issued by a foreign government.

Commons already reflects this in {{PD-EdictGov}}, which states that an edict of a local or foreign government is in the public domain in the United States and explicitly includes judicial decisions.

Therefore, it appears that {{PD-EdictGov}} could cover the U.S. copyright status of an official JEP judicial decision.

— Preceding unsigned comment added by AmiGueko (talk • contribs) 22:47, 26 August 2026 (UTC)

Question about Colombia / Commons policy

The point on which I would particularly appreciate community input is the Colombian side.

Article 41 gives everyone an express statutory right to reproduce judicial decisions, but it also requires the reproduction to conform exactly to the official edition.

Would this statutory status be sufficient for an official Colombian judicial decision to meet Commons' requirement that a work be free in its country of origin?

More specifically:

1. Should Article 41 be interpreted for Commons purposes as making official Colombian judicial decisions sufficiently free for hosting on Commons, when combined with {{PD-EdictGov}} for the United States?

1. Or is Article 41 only a copyright exception permitting faithful reproduction, while leaving other exclusive rights — particularly adaptation/derivative works — intact, making the documents incompatible with Commons unless the relevant rights holder provides an additional free licence?

1. If Article 41 is sufficient, would it make sense to create a specific template such as a Colombian government-edict / judicial-decision tag rather than using {{PD-Colombia}}, which appears to concern expiration of copyright terms?

1. Would the answer differ between the judicial text itself and additional material embedded in a PDF (for example photographs, maps, illustrations, or other third-party material)?

Our intention would initially be to upload only faithful copies of the official judicial decisions published by the JEP, together with their original source URLs and provenance information.

Before uploading anything at scale, we would like to establish the correct copyright analysis and template combination.

Relevant legal provisions:

• Colombia, Law 23 of 1982, Article 41.
• Andean Community, Decision 351 of 1993, Articles 21–22.
• Berne Convention, Article 2(4).
• U.S. Copyright Office, Compendium, §313.6(C)(2), Government Edicts.
• Commons: {{PD-EdictGov}}.

Thank you for any guidance, particularly from editors familiar with Colombian/Andean copyright law or the treatment of foreign judicial decisions on Commons. — Preceding unsigned comment added by AmiGueko (talk • contribs) 22:47, 26 August 2026 (UTC)

August 27

Proposal of a tool to detect over-categorized files

I am considering creating a small tool or gadget to help identify possible cases of over-categorization. The idea is simple, on a category page, a button such as Check for over-categorization would compare the files directly contained in that category with the files found in its subcategories. If a file is already included in a more specific subcategory, the tool would show it as a possible redundant categorization.

For example, if File:Example.jpg is directly in Category:A, but is also in Category:A1, which is a subcategory of Category:A, the tool would flag it and show the category path.This would initially be read-only, since there are valid exceptions to over-categorization and the final decision should remain with the editor. Later, it could possibly integrate actions similar to Cat-a-lot for removing the parent category after review.

There are already related tools such as DeepcatSearch, PetScan, Cat-a-lot and catpath.js, but as far as I know there is no simple tool focused specifically on answering: which files directly in this category are already categorized somewhere below it? For large category trees, the search depth could be limited or configurable to avoid performance problems. Would this be useful for category maintenance on Commons? Is there already a tool that provides this exact functionality, or a preferred way to implement it? Wilfredor (talk) 21:39, 27 August 2026 (UTC)

I'm a bit wary about this. If we introduce something like this, and if it is going to be used with the intention of taking action, then we need to have a way for users to mark deliberate "OVERCAT" so that it does not keep getting flagged over and over, and/or lead to edit wars.

A few examples of cases where someone could make a deliberate decision that is liable to be detected as OVERCAT:

• flat categories: if there is a deliberate flat category (e.g. Category:Ships by name (flat list)) anywhere in the descent, then unless you have somehow accounted for that you will almost certainly get false positives.
• Street and building: we often make all of the streets a building is on be parent categories of a category for that building. However, any photo that clearly shows both the building and the street will typically be in both categories. E.g. File:2nd Ave looking north from Yesler Way, Seattle, Washington, ca1895 (LAROCHE 317).jpeg has both Category:Second Avenue, Seattle (its chief subject) and categories for a fair number of the visible buildings, most or all of which have Category:Second Avenue, Seattle as parents.
• 2 different people: you can have a category for a specific person in a photo, and also a category related to a different person in the photo that would also be a parent category for that specific person. E.g. in File:2015 State of the City Address (16519383817).jpg, if someone were to add categories for one or two of the members of the Seattle City Council who are visible here, it probably would sitll be correct to keep Category:Members of the Seattle City Council for the many others who are also there.
  • A parallel issue can apply for buildings in a photograph where one building is specifically identified, and doubtless there are other parallel cases.

Also, how will this tool handle the inevitable (if not terribly numerous) "cycles" in the category tree?

Jmabel ! talk 01:51, 28 August 2026 (UTC)

Thanks again Jmabel and yes, fair points. IMHO they change the design rather than rule it out...

• Cycles: The traversal handles them explicitly. The crawl keeps a set of visited categories and never expands the same category twice, with a hard depth limit on top, so loops terminate and not recursing indefinitely. The result also shows the category path used to reach each file, making unusual parent relationships visible.
• Read-only: There would be no edits, maintenance category, public backlog page, or queue for other editors to work through. The output exists only in the browser of the person who ran the tool and disappears when the tab is closed. There is no persistent "flagged" state for editors to dispute and nobody inherits a list to process mechanically.
• Naming: I will drop "over-categorization" from the button. What the tool actually answers is: Which files in this category are also present in one of its subcategories, and through which path? Presenting the result as a violation would invite unnecessary disputes, so the interface should remain descriptive rather than prescriptive.
• Structural false positives: Streets and buildings, a named person inside a group category, or one identified building among many are all cases where the issue comes from the category relationship rather than the individual file. The opt-out should therefore be defined at that level, in an on-wiki list anyone can edit, with two kinds of entries: categories whose files should never be considered for this check, such as Category:Members of the Seattle City Council or Category:Ships by name (flat list), and specific parent and child relationships that should never be reported, such as a street category and the categories for buildings on that street. One entry can then cover thousands of files instead of requiring file-by-file exclusions, and the list belongs to the community rather than to me.
• Flat lists and meta categories: The crawl stops at categories explicitly marked as deliberately flat or as meta categories and does not descend beyond them. If the existing templates are not applied consistently enough for reliable automatic detection, that argues for the explicit exception list above rather than trying to infer intent.
• Depth: The default would be one level, meaning direct subcategories only, configurable up to a small hard cap. Most genuine duplicates are likely to appear one level below the parent, while deeper traversal increasingly encounters the structural cases described above.
• Action mode: I am not proposing Cat-a-lot-style removal or any other editing action as part of this tool. If such functionality is ever considered, it should come back here as a separate proposal, and the exception mechanism should already exist and be populated first.

On the broader concern, PetScan and DeepcatSearch can already produce this intersection, so the underlying capability is not new; the difference is reducing the number of steps required to obtain it. I agree that lowering that cost is itself a meaningful change, which is another reason to keep this as a viewer rather than turn it into a cleanup queue. If useful, I can put a prototype on a user subpage and run it against the categories from your examples so we can examine the actual false-positive rate before deciding whether the tool should ever do anything beyond displaying the relationships. Wilfredor (talk) 14:29, 28 August 2026 (UTC)

@Wilfredor: There's a lot to unpack here, and I hope it is OK with you if I focus more on being Devil's Advocate than in trying to work out solutions, which I leave to you. To take up your points:

• Cycles: good, sounds like you've got that one.
• Read-only: glad to hear any actions will be by humans. The one problem with that (and it looks like you've given this some thought) is the danger that a false positive may be reported to a lot of different users if there is no way to head it off, and (in the worst case) that someone eventually "does what the bot seems to want" rather than thinking for themself.
• Naming: agreed.
• Structural false positives: I don't think we are yet on the same page here.
  1. I'm not certain what you mean by saying they are "the issue comes from the category relationship rather than the individual file." Could you expand on that instead of my responding to one or more of my several interpretations of what you could mean?
  2. Category:Members of the Seattle City Council and Category:Ships by name (flat list) are very different from one another.
     • For "members of", ideally we would diffuse this completely, if we had enough content (so that we didn't have just one or two pictures of some council members) and enough knowledge (so that, for example, we could say who each individual is in a picture of the City Council visiting a dam site in the 1930s). The problem comes when we can identify (and have subcats for) some, but not all, of the people depicted. (The street/building situation is analogous: in both cases you have to actually examine what the file depicts to see whether it is OVERCAT or not.)
     • Now that I look more closely, Category:Ships by name (flat list) any other truly flat list doesn't present a problem at all. The only issue (and it won't be detected by a tool like the one you are proposing) is that its subcats all need to be the correct type of categories: categories for individual named ships. The problem would come if it has a subcat like the nonexistent Category:Tugboats by name (flat list), where tugboats would belong in both.
• Flat lists and meta categories (some of the issues her cross over with Structural false positives): I'm not at all sure that meta categories actually require special handling at all: I'd be interested in seeing why you think they do. Similarly, as I remarked above, for flat lists. But there are two things I think are trickier:
  1. Categories that are intended as non-diffusing. For example, we have a discussion going on right now that possibly (with some relatively few exceptions) subcategories for gender should be non-diffusing. If we went that way, it would be appropriate for a category for a person to be in both Category:Guitarists and Category:Female guitarists, but probably we still would not want to have that person category in both Category:Guitarists and Category:Folk guitarists.
  2. Categories like Category:Neighborhoods in Seattle which are "sort of flat" lists. For example, Category:Admiral District, Seattle, Washington is a child of Category:West Seattle, Seattle, Washington, and both of the latter are directly children of Category:Neighborhoods in Seattle. Why? Because the Admiral District is part of West Seattle, so it certainly belongs in Category:West Seattle, Seattle, Washington, but anyone who doesn't know the city well would probably not try to look it up there, so they should be able to find it directly in Category:Neighborhoods in Seattle; it is, after all, a neighborhood in its own right. This is an example of something that I suspect comes up more widely than we might at first think, because almost by definition, most of us are not subject matter experts in a large number of subjects, and it takes a subject matter expert to set it up right so it is easily used by the non-expert.
• Depth: interesting thoughts, certainly a reasonable hypothesis, it will be interesting to see what we find when applying this to actual data.
• Action mode: glad to hear there won't be one!

Jmabel ! talk 02:58, 29 August 2026 (UTC)

@Jmabel: Thanks; your devil's advocate approach was useful. You corrected me on one point, so I'll start there.

You are right about flat lists, I had already mentioned this on the Telegram channel but hadn't updated this thread. The category Category:Ships by name (flat list) contains categories, not files, so the file level comparison my tool performs never applies to it. Your Neighborhoods in Seattle example is the same case: the fact that Admiral District appears both under West Seattle and directly under Neighborhoods in Seattle represents a relationship between categories, whereas the tool only compares files. Neither case requires special handling; the logic for flat lists and metacategories has been removed.

By the phrase "the relationship rather than the file," I meant that for streets and buildings, nothing within the individual file itself triggers the report. Any file present in both Category:Some Building on Second Avenue and Category:Second Avenue, Seattle appears in the report because the second category is a parent of the first. Excluding files one by one doesn't work here; excluding the category pair removes them all. That is a drastic measure; whether a specific file is redundant depends on what it depicts. A photo showing only the building is out of place in the street category, whereas a photo of the building on its street is not. A pair-level exception doesn't allow for that distinction, leading to a trade-off between false positives and false negatives. The tool is designed to display relationships without ever editing anything that is a key principle, and I don't want the output to turn into a cleanup task queue. It is up to the user to decide what the photo represents.

What I believe is your main concern, instead of listing results file by file, I will group them by the category pair that generated them and sort them by quantity. If 400 files from Category:Second Avenue, Seattle are flagged via the same relationship, that counts as a single line item rather than 400 separate findings. A large group is almost structural in nature. It is the isolated result that requires careful scrutiny. This way, the user isn't presented with a long list that invites rote editing, and structural cases are identified as such. Regarding a false positive that reaches many users without the possibility of stopping it, the root cause is the ephemeral nature of the result. There is no record indicating that a pair has already been examined. Therefore, the exception list should be the only persistent element, a Commons page editable by anyone, featuring a "register this pair as expected" button next to each grouping that saves the edit to that page. The first knowledgeable person to identify a structural case would remove it for all subsequent users of the tool.

Non-diffusing categories represent the scenario I hadn't addressed, and I agree that they constitute the difficult part. If the community decides that gender subcategories are non-diffusing, a file's presence in both "Guitarists" and "Female guitarists" would be correct by design, whereas its presence in "Guitarists" and "Folk guitarists" would not; however, the tree structure does not allow for distinguishing between the two cases. When the intent is marked via a template, the tool can detect it; when it exists but is unmarked, the exception list is used. These groupings also highlight connections where the intent exists in practice but was never recorded, which is useful in itself. The category "Seattle City Council members" is not, as you rightly point out, a flat list. The goal here is full diffusion, and the reports arise from partial identification rather than a structural decision. This argues against a blanket exception and supports the aforementioned grouping method, which will display the situation exactly as it is. The next step is to create a read-only prototype using this grouping system, run it on the "Second Avenue, Seattle" and "Seattle City Council Members" categories (as well as on some large trees), and present the figures, reported files, distinct connections, the distribution of results among them, and a manually verified sample. If it turns out that the majority of isolated results correspond to unforeseen structural cases, that would count against the tool; I would rather discover this from the data than through a theoretical debate here. Wilfredor (talk) 13:27, 31 August 2026 (UTC)

@Wilfred:

• I assume "the tool only compares files" means "the tool only compares categories for a file, not parent categories for a category," correct?
• "Excluding files one by one doesn't work here": why not? I wouldn't suggest completely excluding the file, just having a way for the user to note--in a template on the file page--that a particular apparent OVERCAT had been noted and signed off. Template probably should also add a maintenance category so people can readily find these. I agree that this would not lend itself to a centralized list.
• "the tree structure does not allow for distinguishing between the two cases": I don't see anything more difficult in marking this sort of relationship in an exception list than the other.
• I agree with the importance of a prototype and actual data.

Just to be clear: I think this is a reasonable idea. My main concern with it is that I've found we have a fair number of Commons contributors with what I'd consider overly rules-based thinking, as against basic common sense, who may apply this in a manner that will waste a lot of their own time, as well as that of people who undo the resulting bad edits, stirring up tempers on both sides. If we roll this out, it needs to be in conjunction with underlining that OVERCAT is more of a strong rule of thumb than a hard-and-fast rule, and that the end goal remains grouping related files together, not an exercise in ontology. - Jmabel ! talk 20:46, 31 August 2026 (UTC)

• A better term would be removing "redundant" categories. People use overcategorization to mean a few different things, like adding a category of each person mentioned in a pdf book (indexing), or creating categories that are the intersection of two existing categories (left handed female writers). --RAN (talk) 03:44, 1 September 2026 (UTC)

That is true, there are different meanings of overcat, another one that RAN didn't mention yet are case of tagging (a single world map being categorized as a "map of Afghanistan", "map of Algeria", map of "Angola"... i.e. all nations on Earth).

I think that the proposed tool is not urgently needed, but a nice-to-have. As long as the people who use it don't forget to think themselves (and thus also aren't bots). I'm curious about what the tool users may report later: how many of the detected cases are going to be actually deliberate? --Enyavar (talk) 12:31, 1 September 2026 (UTC)

• I would like to see the process automated. It seems a clean up process that automation would be perfect for. We could also use a tool for looking for and making flat lists, where they are currently absent. --RAN (talk) 20:04, 2 September 2026 (UTC) --RAN (talk) 20:04, 2 September 2026 (UTC)

  @Jmabel: , Yes, exactly. When I say the tool only compares files, I mean it checks whether a file located directly in category A is also found at some level below A. It doesn't attempt to detect redundant relationships between the categories themselves. Therefore, cases like flat lists or "Neighborhoods in Seattle" fall outside the scope of this tool's checks.

  Regarding the tagging of individual files, I think you're right. I was trying to avoid adding permanent maintenance templates before knowing how frequently these cases actually occur. However, there are likely two distinct situations: a category relationship that is intentionally non-diffusing, and a specific file where both categories make sense based on what the image shows. A category-level exception might resolve the first case, but not always the second.

  For the prototype, I prefer not to address this just yet. I want to see the actual figures first. If the same false positives keep appearing, we can determine whether it's better to set exceptions at the category level, the file level, or perhaps both.

  @Richard Arthur Norton (1958- ): , I agree regarding automating detection; that is the tool's goal. I am more cautious about automatically removing categories. The category tree indicates that the same file appears in both a parent category and a subcategory, but it doesn't tell us the reason. For example, a photograph might actually show a building and the street, or several people, even if only some of them have their own category. In these cases, automatically removing the parent category could make the categorization worse.

  That’s why I think the first version should be limited to locating the cases, grouping them based on the parent/subcategory relationship, and displaying them to the user. It can also recognize known cases of non-diffusing categories when they are explicitly marked.

  This way, I can test it with real categories and manually review a sample. That should give us a clearer idea of ​​how many results are truly redundant and how many are intentional. If the results show that some cases can be handled automatically without risk, I think the automation of removal as a separate step could be discussed later. And yes, I agree that "redundant parent category" is likely a more suitable term than "over-categorization," since the latter can have several different meanings. The flat list tool also seems useful, but I believe it addresses a different issue, as it focuses on relationships between categories rather than on files appearing at different levels. Wilfredor (talk) 15:31, 3 September 2026 (UTC)

The prototype is up at User:Wilfredor/commons-subcat-overlap and it only reads, nothing is written and nothing is queued for anybody. It runs by itself when a category is opened and marks the files that are also in a category below it, on the thumbnails the page is already showing, so there is no list to read and no button to press, and a category of nine thousand comes in pages of two hundred where each page answers for itself. The marks separate the findings that something explains from the ones that nothing explains yet, because a file that is below in several subcategories at once is almost always a general view and a file whose own name carries the subject of the category is a file about that category. On the first page of Category:Second Avenue, Seattle there are 200 files, 84 of them are also below, and after that reading only 5 are left with nothing explaining them, while Category:Members of the Seattle City Council gives 13 of 71 and leaves 3. For those few the tool reads the history of each file and asks whether this category was here first while somebody filed the file below later, which is the only shape that looks forgotten, and it paints that one with a border of another colour. Over 22 of them I found 8 where both categories arrived in the same edit, 4 where this category was added afterwards, 1 with the forgotten shape and 9 where the summaries say nothing, and almost all of them are edits of Jmabel, so the data says the same that he said here. Some cleverer readings did not work and are not in the tool, the share of a subcategory that also sits in its parent separates nothing, Wikidata does not record that any of those buildings stands on Second Avenue or that Tim Burgess was in that council, and only 2 of 100 files I sampled carry a depicts statement. User categories are exempt of the rule and the tool says so instead of reporting them. Whether a file really belongs in both categories depends of what the photograph shows, so nothing here is a verdict, and what would help now is Enyavar's question, how many of the results you get turn out to be deliberate. Wilfredor (talk) 17:11, 4 September 2026 (UTC)

We used to do this automatically with User:CategorizationBot, but the category tree grew so large that the tool to find over categorization fell apart and never got fixed.

If you want to implement this again the same wa you have to create a directed graph of the (non-hidden) topic categories. When you have a directed graph, you can can easily find cycles.

If you just want to empty out a high category that already has files in subcategories, Special:CategoryTree might be useful. It seems to have an api entry point that has a depth options https://commons.wikimedia.org/w/api.php?action=categorytree&format=json&category=Haarlem&options={%22depth%22%3A%223%22%2C%22mode%22%3A%22categories%22%2C%22hideprefix%22%3A%22categories%22%2C%22showcount%22%3Atrue%2C%22namespaces%22%3A[14]%2C%22notranslations%22%3A%22%22}&uselang=en&formatversion=2&. So you might be able to use that. Multichill (talk) 12:00, 5 September 2026 (UTC)

Thank you, the part in parenthesis about non hidden categories was useful and it helped me find a real error on my side. On Parque Florestal de Monsanto it was 30 of the 33 results on the page, and on Landschaftspark Duisburg Nord 26 of 55. The figures I posted before do not change. Second Avenue, Seattle has no hidden subcategory and it is still 84 of the 200 files on the first page. About the directed graph and the cycles, that is exactly the thing I am trying to avoid. This tool never keeps the full tree in memory. I took 500 categories at random and the 1543 parents they have between them, and found zero direct loops, so for now I do not see this as a real problem in the way I am using the API. I also measured the categorytree API. It is marked internal in paraminfo and it returns HTML instead of data, which makes it a little less practical for this case. It only really wins when going deeper. Haarlem at depth three returned 441 categories in one request of 2.2 seconds, compared with the roughly 440 requests that a normal crawl would make. So I understand the advantage of categorytree for deeper queries, but for what I am doing now I still do not see enough reason to change the whole approach. Wilfredor (talk) 02:39, 6 September 2026 (UTC)

August 31

Uploading freely-licensed photos from the Macaulay Library

Hi, The Macaulay Library has provided options for users to upload bird (or any other organism) photos using a creative commons license. Using a search tool, I can check which photos have which license. CC BY (https://search.macaulaylibrary.org/catalog?licenseId=li5) CC BY SA (https://search.macaulaylibrary.org/catalog?licenseId=li9)

Is it okay to upload photos which I can confirm are CC BY or CC BY SA from these search links given I provide the search link as well? (Example for Atoll Starling: https://search.macaulaylibrary.org/catalog?licenseId=li5&taxonCode=atosta1) Mitsingh (talk) 11:59, 31 August 2026 (UTC)

Yes. Take care to include the profile name of the photographer, the date of the photo and the location as well as the species. These seem like useful bits of info to capture when uploading. Also seeing 'observation details' which can have a lot of extra useful info for the shot.

BTW, try to get the original photo size rather than the 1200 px wide display version. This may not be obvious. E.g. https://cdn.download.ams.birds.cornell.edu/api/v2/asset/635525960/2400

Not sure how to get a version with original metadata either, so there's some more technical work needed on how to download in a way that preserves the metadata that the site shows separately in its site view.

Fæ (talk) 14:33, 31 August 2026 (UTC)

Taking a second look this morning, it's clear that from outside, or logged in, we cannot access original photos with exif data, though the photo pages show a summary of original exif. The original are held on their system, but it would be nice to be polite rather than try to hack around it. My recommended next step would be to write to https://support.ebird.org/en/support/solutions/articles/48001064551-requesting-and-downloading-media and explain that releasing originals of the CC-BY & CC-BY-SA photos to Commons can be done by volunteers and our convention is to provide these for any reuse though most of our users are Wikimedia projects and researchers. There might be a way for them to recommend API access to do that without it being more complex.

Alternatively one can put in a specific request for a few thousand original images that are the priority and it looks like they might be able to email them back, though that's a lot weaker as a solution. --Fæ (talk) 08:03, 1 September 2026 (UTC)

over 35,000 media needing categories tagged since 2023

Since the previous section got archived. Arlo James Barnes 16:43, 31 August 2026 (UTC)

Thanks for the reminder: It’s now under 35 thousand… still a lot og work to do, though! -- Tuválkin ✉ ✇ 20:30, 1 September 2026 (UTC)

September 02

Severe bug in the frontend file cache servers (not serving the effective last version of any original file)

Tracked in Phabricator
Task T425216

There's a severe scheduling bug in the Wikimedia file server cache (for the "original source" files), which does NOT reflect the LAST version of ANY updated file, but ALWAYS serves some previous version BEFORE the last update.

• I think that when a file is updated, the file server cache incorrectly receives an update event much too early, and then updates itself before the file has been actually stored and made available on the file storage server.
• This bug does NOT affect the thumbnail generator which correctly uses the last version and updates the PNG thumbnail correctly, because it receives the update event correctly after the file was actually stored on the file server.
• You can wait for hours or days, there's no way to have the "original source" file made available via its standard (undated) link (e.g. https://upload.wikimedia.org/wikipedia/commons/f/ff/U1CC43.svg, instead of https://upload.wikimedia.org/wikipedia/commons/archive/f/ff/20260902082205%21U1CC43.svg which is supposed to be the link for the version dated 2026-09-02 08:22:05 in the history, but is in fact a link to the version immediately before it!)
• This is NOT specific to this file, in fact I've seen this bug in many other files whose updates were NEVER reflected in their original versions (i.e. not the generated thumbnail which are correct), many days (or months!) after their updates.
• Attempts to fix this by uploading the exact same content has no effect (the frontend considers this is a duplicate upload, and discards the upload). If you upload again the "original file" that you've downloaded from the top of the file history, you are in fact uploading an older version!
• Attempts to fix this by editing the file description page has no effect on this bug. Always, the history shows links to the incorrect (non-thumbnail) dated versions.

This means that we can NEVER correctly update the original files (with the exception of their thumbnails), as we are always serving original files one (or several) versions before!

• The only workaround for now is to upload an additional "nulledit" file (with some "invisible" change, e.g. a non-significant space in SVG files, or in some internal file metadata): this works sometimes, but not always as in the previous example where a nulledit upload was made in an attempt but still used the 2nd version, then a revert which is still served with the 2nd version (but the dated version with the nulledit is correct...). In summary the content of the Wikimedia file cache is completely inconsistant with the effective file versions.
• I found no way to force the frontend file cache servers to download again the effective file version from the backend storage servers (e.g. by appending some dummy query string such as "?action=purge" to the "upload.wikimedia.org" link); the frontend continues to maintain its own old local version (for extremely long time which is constantly extended as long as the file is demanded because the frontend is never informed that there was an update was available, even days, weeks, or months before).
• The bug also affects the "file preview" (e.g. when you click any file in Commons to display the file in "full screen" mode, it also shows an old version).

I consider this synchronization bug (between the inconstant frontend file cache servers, and the backend storage servers which superficially seem correct, as these latter servers are used by thumbnail generators) being severe everywhere in Wikimedia for three major reasons:

• It affects countless files that need to be legitimately updated on Wikimedia Commons, but also files stored in other Wikimedia wikis (e.g. in any localized edition of Wikipedia when these files are not accepted in Commons due to licencing exceptions). The displayed file histories are completely inconsistant! The bug is independant of the file content type (not specific to SVG): this same bug occurs as well for PNG, GIF, JPEG images, as well as PDF or DejaVu documents, or audio and video files!
• Reverting any file to a previous version does not work (except for their generated PNG thumbnails), and files that must be reverted, because of an unexpected error (e.g. from any user that used the wrong filename and unepectedly overwrote the incorrect file), or because of some users voluntarily damaging file contents with abusive uploads (the revert from the file history also does not work, except for the served thumbnails). This creates severe maintenance problems against user abuses or errors, or for any legitimate fixes that may be desirable and needed.
• Transfering any file from Wikipedia to Commons may in fact transfer an old version that was updated on Wikipedia, where the correct last version will be permanently deleted just after the transfer (an no more history available in Commons or in Wikipedia to find the correct last version).

This bug is reproducible everywhere (you can try with your own file, upload it, make a correct file description page with the required licences, date, your author name, and relevant categories, then update the file content several times with successive visible edits, look at the file description page and find a logic to the displayed file history, but don't look just at the displayed list of thumbnails: click each version thumbnail to see the full version and you'll see that they don't match...). -- verdy_p (talk) 08:39, 2 September 2026 (UTC)

Have you opened a Phabricator ticket? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:33, 2 September 2026 (UTC)

I should but before I want to make sure that Wikimedia Commons users are aware of the problem, or if they know a way to workaround the problem. Or if they also experiment the problem (or not), and explain why. For now I don't know what to do. And how much this impacts those using Commons (including those that assume that what Commons displays is correct, and that use bots, or local admins that may perform unexpected admin actions because they trust what is displayed in file histories, and all those that want to perform any kind of maintenance. The ticket on Commons would not be visible so much to many users. This message is an alert to more people (this does not exclude opening a ticket if the problem is serious, or if there are more problems than those I tried to list above with my experiences and attempts; I have experience the problem since months, but could not explain it correctly and did not investigate to find a possible cause and a workaround; this is really a quite old problems and it is in fact architectural within Wikimedia servers and how they are synchronized; this genrally does not affect thumbnails only because thumbnails are generated on request, long after the file upload has been completed: the file description page is regenerated, which contains a link to request a thumbnail, then the user's web browser refreshed the page and starts asking for the thumbnail and the thumbnail generator is instructed to download the new version directly from the backend storage servers, without using any frontend file caches which are already corrupted; then the browser gets the expected thumbnail version, but no one is able to get the original non-thumbnail file.... except if someone else with a different ISP in a different region wants to download the original file from a different front cache server which has still not seen any request for this updated original file; but if the updated file is "popular", requested frequently enough from many parts of the world, there's no chance anyone will ever see the updated version as no Wikimedia frontend cache will ever update itself to reflect the update). verdy_p (talk) 11:37, 2 September 2026 (UTC)

Note that I posted a copy of this message in the Phabricator tracker link T425216 you posted above. This was a separate bug, less critical, but investigations went in the wrong way (thinking that people had problems with their browser cache, or that it was related to some regional CDNs, but visibily the bug is effectively within Wikimedia's domain, on the frontend servers and compeltely independent of users, their location, their browser, or file contents, it is much more serious). verdy_p (talk) 11:45, 2 September 2026 (UTC)

Note also that there has been many source code updates in MediaWiki and in Wikimedia server tools and policies to dramatically limit the work performed by thumbnail generator, and on how original (non-thumbnails) files are served. These were limitations on how often caches can update themselves (to avoid stressing too much the servers). This must have forgotten a frequent case: file contents must remain updatable, and now they cannot be updated reliably. This bug will be probably very tricky to fix (and may cause downtime or severe degradation of performance if not tested properly): these tests for normal operations (forgotten since many months, possibly years) must be developed as well as stress tests (this should be performed first on test servers to limit the damages on Wikimedia) and should become part of the development and deployment process. This could also require the involvment of some internal administrators, and possibly update the usage policies.

But for now, users should be aware that this problem exists. If they want to test it, please don't do that on files updated and maintained by others, or on "popular" files: do that on your own test files or files you uploaded recently and you are actively maintaining. If you have ideas about how to workaround the issue (like those that I tentatively posted above), please post them, this can help others. Don't harness the servers for your own "stress tests", unless you are directly involved in the development and tests for this issue, and you are ready to discuss what you do and document all what you found, and where you tested the behavior (so that all bugs can be tracked exactly in a predicatable way; I suggest you upload these test files not directly on Commons, but on a test wiki, or in a dedicated section of Commons meant for test files with explicit "test" filenames and categories) verdy_p (talk) 13:06, 2 September 2026 (UTC)

Also I wonder why users cannot have their own "sandbox" file for their own tests or their inctremental edits, or even before any upload: a single file (or one per file type if the file extension is needed to correctly set the content type), visible only by them in their own user space. This would be useful before having the possibility to transfer it as a new or updated version of any common file, using a dedicated upload form where they can select the target and submit a commit comment. It would save lot of storage resources and would avoid multiple successive uploads. Users that want to work on their own small collection of files to test trogether could ask for a larger set of personal files. These files would be accessible only in their own user wikipages (i.e. "File:User:(username)/(filename).(ext)", possibly abbreviatable as "File:~~/(filename).(ext)" or just "~~/(filename).(ext)" in galeries accessible only from "User:(username)/(subpage)"; and users should be able to manage their private temporary collection of personal test files, within an acceptable storage policy, in terms of volume or maximum storage time, after which these files could be erased automatically; these files would not necessarily keep a long history of versions, each version counting within the personal storage limit). This could even completely replace the current upload system. This personal storage would be useful notably to see if a file renders correctly, has the correct metrics or internal metadata and fits well with other files within personal test wikipages; a personal test wikipage however would not be necessary as the system would provide automatically some gallery page for the personal collection of files they are working on (if they need to test and work on these files with other users, they could offer them a sharable link, usable by them on the same wiki server: they would just add the offered shared file into their own work collection. In each personal collection, these files could have different local filenames; the server would manage the list of users cooeprating on this workfile so that the list is automatically integrated into the lsit of authors once the file will be really uploaded to the public space; those personal files could also have a file description page, and a local list of categories (displayed only to the user viewing the test file, but still not added to the target category): these categories would be proposed in the public upload form, as well as the description, but if the file is intended for an existing public file, it would be necessary to manually edit and merge these descriptions within the public upload wizzard. Once the file is published by the wizzard, it is removed from the private user's collection (unless the user asks to keep it for more time within his work collection) and user wikipages referencing these private work files could be updated automatically to use the new public file... verdy_p (talk) 13:22, 2 September 2026 (UTC)

Its a known issue, Krinkle is already working on it. The tl;dr: When people added the ?utm parameters to image urls, it confused mediawiki. It correctly handles thumbnails but not original files. Bawolff (talk) 16:49, 3 September 2026 (UTC)

I need help with uploading a png file to Wikimedia

On Special:UploadWizard, I always get

[fbf7d8d9-9f85-4fba-ad04-1c2f6b43de49] 2026-09-02 19:00:33: Fatal exception of type "InvalidArgumentException"

I cleaned my cookies, cash, you name it. Relaunched browser. The error is still there. — Preceding unsigned comment added by LokThimiKhwamSukh (talk • contribs) 19:03, 2 September 2026 (UTC)

The upload wizard is currently down, for all types of files. Hopefully it will be fixed soon. Ymblanter (talk) 19:08, 2 September 2026 (UTC)

Seems to be working fine now (from EU/ESAMS). Nux (talk··dyskusja) 19:52, 2 September 2026 (UTC)

September 03

Help in Category:Falcon 9 by flight

I want to kindly request everyone interested to help in categorising the images present on Category:Falcon 9 Starlink by flights and Category:Launches of Falcon 9. Abdullah1099 (talk)

Template:Countries of Asia

Hello everyone,

In the template {{Countries of Asia}}, the entry for Israel has been removed and replaced with Palestine. I wasn’t able to find the edit that caused this change. Could someone help locate the source of this edit? -- Geagea (talk) 07:06, 3 September 2026 (UTC)

@Geagea: I can't see or understand what you mean or what the issue of {{Countries of Asia}} would be. The template contain these lines: Countries of Asia: Afghanistan ·[...]Indonesia^‡ · Iran · Iraq · Israel · Japan · Jordan [...] - Israel is clearly present in the display I have. There's also Limited recognition: Abkhazia^‡ · Taiwan · Northern Cyprus^‡ · Palestine · South Ossetia^‡ – Other territories:[...], where Palestine is evidently also present. Regards, Grand-Duc (talk) 10:46, 3 September 2026 (UTC)

Well, now it's ok. it was:

Countries of Asia: Afghanistan ·[...]Indonesia‡ · Iran · Iraq · Palestine · Japan · Jordan [...] - Israel is clearly present in the display I have. There's also Limited recognition: Abkhazia‡ · Taiwan · Northern Cyprus‡ · Palestine · South Ossetia‡.

Anyway, we're all good now. Thanks for taking a look. -- Geagea (talk) 10:55, 3 September 2026 (UTC)

I think the template uses the country name from Wikidata, and the problem was the Wikidata item for Israel (d:Q801) was vadanlized yesterday, and the edit had just reverted today. Not sure why the Wikidata item is not protected. Thanks. Tvpuppy (talk) 11:00, 3 September 2026 (UTC)

Thanks, i'be checked WD and it was ok. I didn't thought about checking the history. Thanks. -- Geagea (talk) 13:21, 3 September 2026 (UTC)

The item is protected, the vandal waited to get the confirmed status (and is now globally locked). Ymblanter (talk) 18:04, 7 September 2026 (UTC)

The recognition of Israel is limited too. I certainly do not want to open the can of worms of defining what is limited and what not, but if someone says the template "Countries of Asia" is taking a political stance they may have a point. See:

Palestine recognition

Israel recognition

Regards. Strakhov (talk) 16:40, 7 September 2026 (UTC)

@Strakhov: I think in these cases we have always considered full UN membership as a clincher. - Jmabel ! talk 01:06, 8 September 2026 (UTC)

@Jmabel it is a flawed reasoning. Both Vatican City (Holy See) and Palestine are not full members. They are merely observer states. Vatican City, nevertheless, remains part of {{Countries of Europe}} as a regular country as opposed to state with limited recognition. JWilz12345 (Talk|Contributions) 02:05, 8 September 2026 (UTC)

I "don't have a dog in this fight" with reference to which UN observer states are listed; just that we don't exclude any UNmember states. - Jmabel ! talk 02:23, 8 September 2026 (UTC)

PIP removal requests on "embarrassment"

Recently, I have seen several instances of individuals nominating photos of themselves (no explicit evidence they actually are the person in question) for deletion on the allegation that it causes embarrassment. Commons:Photographs_of_identifiable_people#Removal_requests does state that embarrassment may be a reason for deletion, but does not guarantee this. Now, the claim that a photo causes embarrassment is difficult to assess when looking at these photos, as it is somewhat subjective. However, many such requests concern photos in which there is basically no element of degrading or insulting content. This includes many neutral portrait photos or screenshots taken from videos. We should obviously not cave to every allegation that a photo is embarrassing, as this could quickly become a tool of censorship for individuals wishing to promote a particular image of themselves.

Since COM:PIP does not elaborate on what constitutes embarrassment, can we come up with some guidelines for future deletion discussions? – Howardcorn33 (💬) 09:57, 3 September 2026 (UTC)

I don't know if the nominator being the uploader counts as 'explicit evidence' but it seems appropriate that if someone adds an image to Commons they should be able to subtract it unless that would disrupt reuses on WMF wikis. Outside of that, it sounds more like a matter for the email addresses at meta:Safety Resource Center/Digital Safety. Arlo James Barnes 14:38, 3 September 2026 (UTC)

I am also including cases where the photo was uploaded by a different user from the person depicted on the image. – Howardcorn33 (💬) 15:33, 3 September 2026 (UTC)

The process for the deletion of a picture based on the request of the depicted person always requires the identification of the person. Deleting the photo based on false claim of someone being the subject of the photo would be a massive personality rights violation. GPSLeo (talk) 16:40, 3 September 2026 (UTC)

Should we always require VRT verification for users claiming to be particular individuals in deletion discussions? – Howardcorn33 (💬) 17:09, 3 September 2026 (UTC)

No, VRTS should not be automatic. There are plenty of cases where an unused and unremarkable photo can be quietly deleted in good faith. Requests like "I was the child in this photo and I prefer it to not be online anymore" can be treated respectfully and it benefits the project goals to have a courteous way of handling such requests. If it's in use beyond user pages or just within Commons, especially on a Wikipedia article about a person, or has some objective historical value, then asking a user to go via email (and avoid drawing attention in public) is at that point justifiable and easy to explain if challenged. Fæ (talk) 07:50, 4 September 2026 (UTC)

• Just a few recent ones:

• Commons:Deletion requests/File:Silvia Leal.jpg
• Commons:Deletion requests/File:Shana Pearson dehors Casa Del Popolo.png (BullDoser !)
• Commons:Deletion requests/File:Fa-مجتبی عیسی پور.ogg
• Commons:Deletion requests/File:Anne C, Agungsn, Aesthetic of Me 5-5-2026.png
• Commons:Deletion requests/File:Abendrot Rittersgrün.jpg

I too would welcome a guideline on this. Andy Dingley (talk) 16:53, 3 September 2026 (UTC)

Copyright status about currency of Bulgaria

When Bulgaria replaced to euro, it is still protected by copyright after replaced to euro? However, what is the current situation about Bulgaria and the euro. like Ireland, the currency is copyrighted; But it not mentioned in the section mentioned here, any questions that currency has copyright that should not allowed to upload here due to restrictions from Bulgarian National Bank? TentingZones1 (talk) 12:21, 3 September 2026 (UTC)

National sides of Euro coins are copyrighted, so that would also apply to Bulgaria. Abzeronow (talk) 01:53, 4 September 2026 (UTC)

September 04

Server side error

Some of my recent edits on Wikimedia Commons did not register due to "Server returned error: HTTP 503." In one instance of using VisualFileChange, I had to manually add the request I made because of Error: -- NO TASK DESCR. FOR mdUploaderNotified PLEASE ADD IT -- ##### Server status: 503 - Error:. This server-side problem also extends to editing some pages using source editing, needing a few "TRY AGAIN" clicks. I suspect much of the issues concern uploading of edits, because it seems fine whenever I "download" data like loading any of the pages here (file pages, Commons policy pages, categories, watchlist, galleries etc.). (Very likely, I experienced another "Server returned error: HTTP 503." while saving this topic.) JWilz12345 (Talk|Contributions) 03:06, 4 September 2026 (UTC)

503s are generally transient errors that go away after a few minutes. Bawolff (talk) 16:54, 4 September 2026 (UTC)

1970 Yugoslav film poster with locally redrawn Disney characters

I would appreciate opinions on the copyright status of a 1970 Yugoslav theatrical poster before uploading it.

The poster was issued by Kinema Sarajevo for Remek djela Volt Diznija ("Walt Disney Masterpieces"), a theatrical compilation of eleven Academy Award-winning Disney shorts. Contemporary Yugoslav newspaper listings document the compilation's theatrical release in December 1970.

The poster appears to be a locally produced Yugoslav design rather than a reproduction of a French, American or other Disney campaign poster. Its composition and lettering are original, and the characters appear to have been independently redrawn by a local illustrator in a noticeably simplified, non-professional style rather than reproduced from film frames, model sheets, or existing Disney promotional artwork.

Under the former Yugoslav copyright rules applicable in Bosnia and Herzegovina, works of applied art published before 1 January 1977 had a 25-year term. For works published before 1 January 1971, Commons' Bosnia and Herzegovina copyright guidance indicates that the copyright had already expired before the URAA restoration date.

The issue I am uncertain about is the treatment of the characters depicted in the poster. It includes locally redrawn representations of Mickey Mouse, Pluto, the Three Little Pigs / Big Bad Wolf, Ferdinand the Bull and other characters associated with the films in the compilation.

I am not arguing that the underlying Disney films are public domain. The narrower question is whether an independently drawn 1970 Yugoslav poster, whose own copyright has expired, remains non-free merely because its local illustrator depicted recognizable characters from the advertised films.

In particular:

• the drawings do not appear to reproduce identifiable film frames;
• I have not found evidence that they reproduce Disney model sheets or existing poster artwork;
• the Yugoslav poster has a different composition from the known French/Belgian campaign material for the same compilation;
• the characters appear to have been redrawn locally rather than mechanically copied.

Would Commons treat the surviving character copyrights as preventing upload of the entire poster, or can the poster be considered a public-domain work of applied art where the particular drawings themselves are independently created?

If useful, I can provide a high-resolution scan and side-by-side comparisons with the known foreign campaign posters and film imagery.

Relevant copyright guidance:

• Commons:Copyright rules by territory/Bosnia and Herzegovina
• Commons:Derivative works
• Commons:Character copyrights
• Commons:Fan art

Thank you.
User:Baronmilone, 18:41, 4 September 2026 (UTC)

September 05

Streetcar image

I found an image I want to use of a streetcar here (full image here) and I did some research and I found it in a magazine article from 1964 stating the image was from a former resident of Martinsburg. This was the earliest mention of it. The street railway operated form 1891 to 1893. I don't know if this is copyrighted, it is on Flickr, but I doubt he is the original owner. Wobs100 (talk) 02:41, 5 September 2026 (UTC)

If that U.S. magazine wasn't properly copyrighted, then it is in the public domain. Otherwise, The 1964 magazine is properly copyrighted, see page 3. You'd need to have reasonable evidence of how this photo passed into the public domain (publication before 1931; publication without formalities in the era when that was required in the U.S.; etc.). 1964 first publication with proper authorization by the heirs and a proper copyright notice would mean this will not be in the public domain until 2060, even if the photo is much older. - Jmabel ! talk 04:19, 5 September 2026 (UTC)

And showing that the 1964 publication was not authorized by the heirs would border on impossible; we have no way of knowing whether "Charles Hess" was the photographer's heir or not. - Jmabel ! talk 04:22, 5 September 2026 (UTC)

Ok! Wobs100 (talk) 12:44, 5 September 2026 (UTC)

Photo challenge July 2026 results

Disaster rephotography: Entries • Votes • Scores

Rank	image	Title	Author	Score
#1		Tenement House Rynek 42, Wroclaw, Poland - after World War II Tenement House Rynek 42, Wroclaw, Poland - current state	Krigore	16
#2		Town Hall in Wroclaw - after World War II Town Hall in Wroclaw - current state	Krigore	12
#3		St. John the Baptist Archcathedral, Wrocław, Poland - after World War II St. John the Baptist Archcathedral, Wrocław, Poland - current state	Krigore	11

Puddles: Entries • Votes • Scores

Rank	image	Title	Author	Score
#1		Peafowl mirror image on a puddle	Sindugab	18
#2		A puddle in Warsaw, Poland	Krigore	17
#3		Reflection in a puddle	Gorillo.Chimpo	13

Congratulations to @Krigore, @Sindugab and @Gorillo.Chimpo. Sekidoki (aka Taiwania Justo) is speaking (Reception Room) 06:35, 5 September 2026 (UTC)

A rephotography contest is a clever idea! Congratulations to those who participated. -- Arlo James Barnes 21:21, 5 September 2026 (UTC)

September 07

Wikimedia Commons turned 22

Some ice-cream for the Occasion! EugeneZelenko (talk) 12:35, 7 September 2026 (UTC)

AH thank you for the reminder. Time flies by (so fast D: ) --PantheraLeo1359531 😺 (talk) 16:06, 7 September 2026 (UTC)

Good news! Hope that Commons will live and thrive! Юрий Д.К. 17:10, 7 September 2026 (UTC)

commons-nominator, nominations without leaving the page you are in

I comment here a script I maintain since some time, commons-nominator, because I just added a thing that maybe is useful for more people. In a file page it puts a row of links that nominate the file to FP, QI and VI, each one with its dialog and one single edit per click, and next to them it also schedules a featured picture as Picture of the day in the next free date, sets the picture as the image of its Wikidata item when that item still has none, and searches which English Wikipedia articles the picture could illustrate, which is what a Commons FP needs before it can be a featured picture over there. What I added now is that all this arrives to the category pages too, written over the thumbnails themselves, so you can go through a whole category deciding while you look at the pictures instead of opening them one by one. Every picture that is still not a Quality Image gets a small QI button, in green when the file is already a Featured Picture, because a FP without QI is almost always an oversight and not a decision, on my own files 84 of my 212 featured pictures were missing it. Pressing it opens the normal dialog with the short description already filled from the file, and when you finish you stay in the category. In the FP nomination pages it also adds rename buttons and it warns you about the two open nominations rule before you edit instead of after. It only offers what each process could accept, so it stays quiet on videos, on small images or when your five QI nominations of the day are already used, and it never writes anything without a click. Documentation and installation in User:Wilfredor/commons-nominator, and I read everything that you tell me is wrong with it. Wilfredor (talk) 17:58, 7 September 2026 (UTC)

September 08

Images and files not loading properly on Commons

Hi, I have noticed that when I am uploading pictures and PDFs to Commons recently, they are sometimes not rendering properly when I open the file page. Examples: https://commons.wikimedia.org/wiki/File:Phylloscopus_forresti_-_James_Eaton_-_338161400.jpeg https://commons.wikimedia.org/wiki/File:Pelargopsis_melanorhyncha_-_James_Eaton_-_435252346.jpeg https://commons.wikimedia.org/wiki/File:Photo_Guide_to_the_Lycaenidae_of_Bolivia.pdf Mitsingh (talk) 08:28, 8 September 2026 (UTC)

Can you be more specific ? They look fine to me. I cant know what you think ‘properly’ means. —TheDJ (talk • contribs) 10:37, 8 September 2026 (UTC)

I am sharing some screenshots of what it looks like to me-

https://postimg.cc/MMBfDtyw

https://postimg.cc/BXpLMj1Q

https://postimg.cc/4nbQRNhF Mitsingh (talk) 11:39, 8 September 2026 (UTC)