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.

Village pump in India. [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 11

'The Gazette' - Wikimedian in Residence

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

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

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

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

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

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

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

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

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

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

Here's a list of crests/ arms - I'll be uploading an example of each in due course. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 18 August 2026 (UTC)

That would be good for cross-referencing how coats of arms are meant to look, I think. – Howardcorn33 (💬) 19:25, 18 August 2026 (UTC)

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)

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)

See also

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

A script for describing a batch before it finishes uploading

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

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

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

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

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

very good tool tysm.

also, in that very old phab task people can see that the same idea has been repeatedly raised over the years! that shows how commonsensical it is and how urgently users need it. RoyZuo (talk) 14:07, 15 August 2026 (UTC)

Something that bothers me is that I commented on this script in the same ticket and someone responded reactively instead of productively, I have repeatedly requested access to the git repository to contribute a Pull Request directly in the uploadwizard to solve this problem, but I have not received a response for this access after months of trying Wilfredor (talk) 13:52, 17 August 2026 (UTC)

@Wilfredor "I have not received a response for this access". Gerrit access is open to anyone. There is only special permissions required for MERGE access (this is a community decision). See Gerrit/Tutorial for documentation on how to use Gerrit. The biggest roadblock for volunteers is generally finding people to review the code. —TheDJ (talk • contribs) 14:35, 17 August 2026 (UTC)

I am talking specifically about this access, and I have written to this email trying to restart my access: idm-help@wikimedia.org Wilfredor (talk) 14:56, 17 August 2026 (UTC)

@Wilfredor do you mean that you have lost access to your Wikimedia Developer account  ? —TheDJ (talk • contribs) 19:24, 17 August 2026 (UTC)

Yes, the last time I had one was over a decade ago, back in the Toolserver era. Wilfredor (talk) 14:09, 18 August 2026 (UTC)

If I try to create one with my username "wilfredor," it tells me it already exists. Wilfredor (talk) 14:09, 18 August 2026 (UTC)

@Wilfredor: Can you operate on the assumption that you created it long ago, and then you lost your password?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:22, 18 August 2026 (UTC)

Yes, but when using the "lost my password" option, no email for the reset ever arrives Wilfredor (talk) 20:00, 18 August 2026 (UTC)

@Wilfredor then the easiest option seem to be to create DevWilfredor or any similar combination that is free for taking :) (personally I use EcceNux for ssh/git) Nux (talk··dyskusja) 20:25, 18 August 2026 (UTC)

I didn't want to lose my account, nor did I want to create another user profile and email address. Wilfredor (talk) 21:28, 18 August 2026 (UTC)

August 14

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

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

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

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

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

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

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

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

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

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

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

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

Apologies for not working on this as much as I did previously, I have been working on AI cleanup on enwiki mostly Gnomingstuff (talk) 04:12, 23 August 2026 (UTC)

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

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

Thanks for your comments. From my point of view, it is effective, to search with GlamTools for files that are already used in an article, or to check Commons:WikiProject Minimum One Category for further hints. Basically, a larger number of volunteers would simplifiy the task. NearEMPTiness (talk) 04:47, 16 August 2026 (UTC)

August 15

File needs to be fixed

This file isn't playing and needs to be fixed. PublicDomainFan08 (talk) 08:49, 15 August 2026 (UTC)

This is a large video file and Commons is quite poor at coping with videos over 1GB. If you want to try re-uploading, do so using one of the urls, such as the internet archive version. I tried with the 2GB IA version, but the mediawiki system gave up before it finished. Fæ (talk) 12:57, 15 August 2026 (UTC)

it looks like the file was not converted to webm properly Bawolff (talk) 17:03, 15 August 2026 (UTC)

You can try this an as upload tool https://image-annotation-tool.wmcloud.org/ It should convert from MP4 and is supposed to have a 2 GB upload limit. Doc James (talk · contribs · email) 21:39, 21 August 2026 (UTC)

User stat tools

i'm gonna make a template that aggregates links to tools that analyse or compile stats about a user. i know these. could you please add more?

• https://glamtools.toolforge.org/
• https://ptools.toolforge.org/uploadsum.php
• https://wikimap.toolforge.org/
• https://commons.wikiscan.org/users
• https://xtools.wmcloud.org/

RoyZuo (talk) 15:00, 15 August 2026 (UTC)

https://quarry.wmcloud.org/ can also execute queries about one user's uploaded files like amount of data, but only with SQL --PantheraLeo1359531 😺 (talk) 17:44, 15 August 2026 (UTC)

@RoyZuo, this tool maps a user's files using this Quarry query as input. It is vibe-coded, but the bugs have mostly been beaten out and it works well with prolific uploaders. See here for discussion.

Example at Data:Charlesjsharp uploads Africa.map. JayCubby (talk) 21:47, 19 August 2026 (UTC)

August 16

Any way to enforce need for US copyright tags?

A lot of media on Commons lacks the necessary US copyright tags and only shows a foreign copyright tag. Is there any way we can make it so that way media with a foreign copyright tag appears in a category if it lacks the needed US copyright tag. It really isn't optional, but a lot of people are treating it that way. Aplucas0703 (talk) 00:14, 16 August 2026 (UTC)

Perhaps we could create a version of {{No license since}} called {{No US license since}}, for files which specify that the work is of foreign origin but fail to provide a justification for public domain status under US law, such as {{PD-US-expired}}, {{PD-US-unpublished}}, {{PD-1996}}, or {{PD-URAA-simul}}. – Howardcorn33 (💬) 11:34, 16 August 2026 (UTC)

In many cases files that don't have a US license could have one, so it's largely a housekeeping issue. And even those that should be deleted need a DR and not a speedy because of the peculiarities of URAA (and also because many local wikipedias accept them locally). So, if we want to add a tag it's fine, but I think it'd be detrimental to delete those files after 7 days as we do with files without any license. Friniate (talk) 17:48, 18 August 2026 (UTC)

And by the way, there have been cases in which it was decided that for specific categories (buildings) there was no need to add also a US license template, so for those files we'd need more templates. Friniate (talk) 17:50, 18 August 2026 (UTC)

Then in that case there can be a template that says: "No US Tag Needed" and that lays out exceptions to the need for a US tag. Aplucas0703 (talk) 20:55, 18 August 2026 (UTC)

Yes sure, my point is only that if you want to make mandatory the presence of a US tag everywhere, then we have to create them, because Template:FoP-US and Template:PD-US-architecture for example are only for American buildings and when I tried to use them on an Italian building I got reverted very quickly. Friniate (talk) 22:19, 18 August 2026 (UTC)

Even for photos of buildings, you still need to prove that the photo is in the public domain in the United States. Aplucas0703 (talk) 00:50, 19 August 2026 (UTC)

@Aplucas0703 These were all photos of buildings that fell under the US FoP (or were built before 1990), the only reason why I couldn't use a US tag is that apparently those templates are being used only for American buildings, but that is only because of Commons' categorization reasons, there's no reason to think that an American court wouldn't apply US FoP also towards foreign buildings. If your proposal is to delete PD foreign buildings built less than 95 years ago, then my comment would become a strong oppose. Friniate (talk) 09:43, 19 August 2026 (UTC)

That's not what I just said. As I said, the photo requires a US tag, not the building. Aplucas0703 (talk) 14:55, 19 August 2026 (UTC)

@Aplucas0703 Oh, ok, you meant the copyright of the photographs themselves? That was fine, they were all own works uploaded by Wikimedians. This was the discussion I was referring to: as you can read there was no reason why we should doubt that those buildings (or at least DW of them) are free under the US copyright law, but nevertheless there was no usable US license, so, if you want to enforce your proposal also to PD foreign buildings (and PD foreign stamps, and I'm sure other categories of objects that I can't remember right now) we first need to create new US license templates. Friniate (talk) 15:01, 19 August 2026 (UTC)

I'd be perfectly fine with making that new template for those cases on photos of the work or even applying the {{FoP-USA}} tag if we determine that to be sufficient (even if confusing). Could add a note to it or other related tags stating that it could be applied to a foreign building to show its US status, even if not in the United States. Aplucas0703 (talk) 17:03, 19 August 2026 (UTC)

Yes, yes, my point was only practical: before requiring users to do something we must actually put them in the position of being able to do it ;-) Friniate (talk) 17:19, 19 August 2026 (UTC)

I feel that it might be helpful to have some concrete examples, or specific types of media where there is a particular risk that an item that is PD in the source country might not have that designation respected under US law. Perhaps it would make sense to focus on those areas in particular. Are there, for example, situations where a building photo is FOP in a source country but would still carry copyright risk in the US? -- Visviva (talk) 04:20, 19 August 2026 (UTC)

Say a person uploads Dylan Thomas's poems. They are public domain in the United Kingdom (origin) because it is more than 70 years after his death. It is still copyrighted in the United States because 95 years have not elapsed since publication.

Many corporate works abroad expire after 50 years at their origin countries (The Philippines, for example) but are protected for 95 years in the United States. Aplucas0703 (talk) 04:45, 19 August 2026 (UTC)

And then why restricting this discussion to just US copyright law? Do we need to map every file to assert every copyright laws in the world? Certainly no. IMHO, the copyright for the file from its source is sufficient. Otherwise it will be very complex to upload files in Commons if they must be asserted against hundreds of copyright laws for files whose protection in fact do not originate from most of these juridictions. The licencing tag may/should include its origin (and date of application, plus some other protections like personal rights or ad hoc database rights). Then each licence source can be assessed automatically to see if they match the US copyright (which is not even universal every in US, for some states or territories and in specific domains!). If we need the "US exception", it's only because the file will be hosted by Commons in US (but Wikimedia alerady has exceptions in many projects so that contents for other countries are not excluded). The US "fair use" is also not recognized internationally and considered abusive in many countries as it violates their protected rights. And the fact that US extends the copyright to longer periods than the original copyright is a nuisance in Commons (e.g. contents which have fallen public domain in the Philippines would be blocked in Commons if US law is applied to them and so these contents cannot be used in Wikimedia; the solution is of course to make sure these contents are explicitly stating that they originate from the Philippines that have liberated these contents; any extended protection added by US would impair contents publication from he Philippines, complicating a lot the contributions and free reuse in Commons for the Philippines even if they are perfectly legal there, if some Philippines corporation unfairly makes claims in the US against any reuse of free Philippines content outside the Philippines). For me the licence tag explicitly stating the country of origin and date is sufficient to display a correct licence that will restrict their reuse ONLY in the US, but NOT in the Philippines or elsewhere. The international conventions and treaties are clear about that: the origin is more important than every other rules and this is what Wikimedia should enforce (i.e. NOT the US local laws). IF we enforce the US law only, we immediately create a severe bias in Wikimedia, favoring contents originating ONLY from the US and excluding all other countries.verdy_p (talk) 05:21, 19 August 2026 (UTC)

The discussion restricted to US copyright law because Commons is hosted in the US, which does not apply the rule of shorter term. That makes a US copyright tag a necessity. The fact that it would be unfair for it to be a copyright violation does not change the laws we have to follow. Aplucas0703 (talk) 07:10, 19 August 2026 (UTC)

As Aplucas stated, yes, Commons has to comply with both US copyright law and the law of the source country (if different). This is a fundamental policy of the website as stated in Commons:Licensing. – Howardcorn33 (💬) 08:34, 19 August 2026 (UTC)

Conditional  Support only in cases where the interaction with US law is at high risk, like concerning old/vintage photos (PD-old-expired/PD-old-assumed/PD-US no notice and other similar things). These are typically not authored by Flickr users, Panoramio users, or Wikimedia users themselves. For freely licensed images taken by Wikimedians, Flickr users, or Panoramio users themselves, case-to-case basis. High risk ones that may need US tags include uploaders' images of paintings, drawings, bottle labels, newspaper pages, films/TV programs, logos, and product packaging (I'll leave to other users regarding choice of depicted object needing third tag [which is the US copyright tag]).

For users' images of buildings, I support an exemption in policy requiring compliance to both the US law and the law of the country. Instead, for users' own images of buildings, the copyright law of the country of the building's physical location is solely taken into account. Two main reasons. One thing, you'll complicate things to users in countries where the local laws are of strong emphasis, like Filipino users. An average Pinoy user does not care of the building's status in the US, and instead defaults to the building's status here in the Philippines. Another thing, there is virtually zero interaction risk under US law in exploiting buildings. The US FoP law came from AWCPA, which garnered criticisms from the minority group of scholars and architects like Architect Clark Thiel and lawyer Jane Ginsberg. They claimed the amendment law wasn't strongly protective of architect's extended and moral rights. However, this is actually advantageous, in the sense that Commons can exploit buildings with no conditions. The US FoP (Sec. 120a) does not mandate attribution of architects, nor it does mandate that buildings' image integrity are respected. Therefore, I do not see the need to mandate PD/FoP US architecture tags to images of copyrighted buildings from yes-FoP countries as well as images of public domain buildings in all countries, unless there is a major change in US law that requires architects to be attributed and the buildings in the images to be depicted as they are found by the photographers or re-users. This hypothetical change won't happen soon in my opinion. For images of buildings by the Commons/Flickr/Panoramio users themselves, the photo creators' license tags as well as the specific YesFoP country's FoP tag or PD tag suffice. Use only both {{FoP-US}} and {{PD-US-architecture}} on images of buildings physically located on US soil (including American external territories like Guam, Northern Marianas, and Puerto Rico). Images of buildings are at very low interaction risk under US law (again, because: no need for attribution, no need to respect the integrity of the buildings, no need to meet the "depicted building should be as it is found there"). JWilz12345 (Talk|Contributions) 15:49, 19 August 2026 (UTC)

Some more clarity, what I meant in the "very low interaction risk" with US law, is that the lack of a specific US tag to "own work" images of copyrighted buildings from yesFoP countries or public domain buildings of all countries (own work images taken by Wikimedians, Flickr users, Panoramio users) outside US does not endanger re-users within the US. Without the US specific tags on images of Tokyo Skytree (supposedly eligible for FoP-US) or the Roman Colosseum (supposedly eligible under PD-US-architecture), all Americans can freely exploit these in any way. Are they at risk under US law? None, because Sec. 120(a) of the US copyright law does not mandate citing the names of the architects or respecting the visual images of the buildings. Furthermore, there are no strong moral rights for architects under US law, as opposed to those in most of the other countries. Building owners in the US can freely disfigure the facades of, manipulate the appearances of, or even destroy the buildings they own without clearancces from the architects, something that the Ukrainian or Saudi (2026) law forbid. No strong moral rights for architectural works under US law, and no conditions under Title 17/Sec.120(a). This is why I see the users' own work images of yes-FoP countries' buildings or all countries' public domain buildings as practically under zero risk of interaction with US law. JWilz12345 (Talk|Contributions) 16:05, 19 August 2026 (UTC)

@JWilz12345 I think we should just make a tag variant that says its an architectural work in the public domain in the foreign country and explains that we don't apply US copyright to those buildings (for listed reasons) and that it is thus okay for the United States. That way if we make a category showing which files are missing a US copyright tag with an applied foreign tag, it can be removed from the backlog needing processing. Aplucas0703 (talk) 17:30, 19 August 2026 (UTC)

I'm not at all getting why people think we need a tag that lets us say that a particular building does not raise issues with U.S. copyright law, given that no building raises issues with U.S. copyright law. - Jmabel ! talk 01:22, 20 August 2026 (UTC)

Agree completely on this point. At most, a short hat-note at the top of the parent category "Buildings in the United States" explaining that situation. Tagging every single building in the USA seems a substantial waste of effort without benefit. -- Infrogmation of New Orleans (talk) 01:35, 20 August 2026 (UTC)

@Infrogmation I don't think anyone has proposed requiring the tag on all (or any) US buildings? Aplucas0703 (talk) 01:41, 20 August 2026 (UTC)

@Jmabel Most foreign copyright tags require a US copyright tag; this satisfies that for potential maintenance purposes being proposed here. Aplucas0703 (talk) 01:36, 20 August 2026 (UTC)

@Aplucas0703 I propose making an exemption to the Commons rule that mandates all foreign copyright tags requiring US copyright tags. In the case of images of modern buildings found in countries with suitable FoP rules and images of public domain buildings in all countries outside US, no US copyright tag is required since there is very low-risk of issues under US law for wanton exploitations of photos of buildings. Any user living in the US do not need to be notified of US copyright status of the buildings hosted here.

Re: problems faced by maintenance, I suggest all maintainers should focus on high-risk group of works, most of which are not wholly produced by the uploaders (or Flickr/Panoramio users) themselves. As I said, the high-risk tier includes old/vintage photos, paintings and drawings, and pages of books/novels/documents, and stills or screenshots of video games/TV broadcasts/films. However, I'd consider non-Japanese logos as low-risk too and we do not need to consider US status, since COM:TOO US is clear that US has a very high bar of threshold of originality for logos. Japanese logos might be under medium-risk since COM:TOO Japan implies a ToO slightly higher than that of US ToO standard.

So, I'd  Support two types of works that exempt the requirement of a US copyright tag: "own work" photos of copyrighted buildings from yesFoP countries or PD buildings of all countries outside US (taken by Wikimedia/Flickr/Panoramio users), and non-US logos except Japanese logos. JWilz12345 (Talk|Contributions) 02:29, 20 August 2026 (UTC)

We can fix this problem entirely by just setting up the category to check to see if at least one license is valid in the United States. This could mean a US public domain tag or any other copyright license tag (incl. Creative Commons, etc.) that is valid for the United States. Since photos of the structures still need a valid tag for the photo, this takes care of that problem entirely. Only photos lacking a license valid in the United States would appear.

Ideally we could enforce this requirement on all new uploads automatically just like we do for uploads missing any license. If we wanted we could create a new delayed speedy deletion tag for missing a US license as originally suggested. For older uploads it could provide a 30 day (or even 90 day) period to repair the issue and a shorter period of 7 days on new uploads. Aplucas0703 (talk) 04:06, 20 August 2026 (UTC)

Besides buildings, there's also the issue of foreign works not protected in the country of origin (for example foreign stamps), for whom we do not enforce US copyright. So we'd need first to do other templates similar to Template:Not-free-US-FOP.

I  Oppose a speedy deletion criterion, there are too many works without a US license, the vast majority of whom I expect to be fine (almost all the PD-old ones for example), such a requirement would deprive us of perfectly fine images because of an housekeeping issue. Isn't there a way to automatically block the upload of new files without a US-license template? Friniate (talk) 09:33, 20 August 2026 (UTC)

@Friniate I disagree entirely blocking all new uploads just because of the lack of US copyright template. As I said, there is absolutely no need for US copyright tags on "own work" images of buildings (except those physically located in the US), and possibly non-Japanese logos (since based on my experience on reading CRT pages it seems Japan has a higher bar of ToO compared to US ToO). Remember we seem to forgot the whole point on what audience WikiCommons serves. WikiCommons is meant to serve readers and reusers globally, not just Americans alone. Adding too many tags to low-risk images (users' own images of buildings, non-Japanese logos) is a sign of excessive bureaucracy disguised as compliance to the US law, despite the fact that US law is clear on low-risk works. No American will ever be sued by wanton exploitation of buildings, and architects do not have moral rights over American public users exploiting photos of their works (as long as 17/Sec 120 stays the same for all time). Confine only the use of multi-copyright tags (perhaps third, fourth, fifth and so on representing US copyright status) to, as I repeat, high/medium-risk works or objects, such as paintings, old photos, and others that I mentioned above. For copyrighted public monuments that are usually objects of w:en:Wiki Loves Monuments contests of yes-FoP ones, {{Not-free-US-FOP}}. JWilz12345 (Talk|Contributions) 10:59, 20 August 2026 (UTC)

@JWilz12345 I was just trying to avoid a requirement involving speedy deletions. Blocking automatically the uploads seems better to me than deleting everything after 30 days, and with speedies that are even untraceable so we'll never be able to undelete those images when copyright expires. Maybe we can block the uploads but with an exemption for certain categories, I don't know, but I certainly prefer any solution that avoids unnecessary speedy deletions. Friniate (talk) 11:18, 20 August 2026 (UTC)

Moreover blocking uploads will encourage hopefully the uploaders to seek help at village pumps, so that we can help them. Friniate (talk) 11:20, 20 August 2026 (UTC)

@Friniate noted. As I said, I suggest exemptions to at least two low-risk works or objects: a) modern buildings from yesFoP countries and public domain buildings from all countries outside the US (provided that the photos are own works of Wikimedia, Flickr, and/or Panoramio users), and b) non-US logos except Japanese ones. For others, I do not oppose having US copyright tag as a mandatory requirement. For example, Japanese logos must also be PD in the US, since Japanese ToO level is higher than that of the US. JWilz12345 (Talk|Contributions) 11:23, 20 August 2026 (UTC)

Yes yes, I was not disagreeing with you, I'm just trying to find a solution that doesn't throw out the baby with the bathwater. Friniate (talk) 11:29, 20 August 2026 (UTC)

Once again, we're getting way too caught up on a single thing here. A photo of a building ALWAYS requires a license valid in the US because ALL PHOTOS require valid licenses in the US. If it doesn't have a single valid license in the US, that's a problem. When a work is ineligible for copyright in its home country, the tag does not say that it is necessary to have a US tag, and therefore the tag counts as valid in the US. Aplucas0703 (talk) 15:38, 20 August 2026 (UTC)

When I process old files, they were originally under German copyright, which is often stricter in protection lengths --PantheraLeo1359531 😺 (talk) 18:36, 20 August 2026 (UTC)

Well no. We do not need to have a US tag for all buildings. We only need a US tag 1. for public domain documents, and we do not need one for files under a Creative Commons license; 2. for derivative works (e.g. artworks). Yann (talk) 19:33, 20 August 2026 (UTC)

@Yann We don't upload buildings to Commons. We upload photos of them, and all photos require a tag valid in the US, whether it's a US public domain tag or Creative Commons tag (which is a copyright license valid in the US). Aplucas0703 (talk) 19:51, 20 August 2026 (UTC)

Sorry, but no. We do not need a US tag for pictures of buildings, because 1. old buildings are not under a copyright in USA, 2. new buildings are under a freedom of panorama exemption. Let's not create unnecessary bureaucracy when it is not needed. Yann (talk) 20:15, 20 August 2026 (UTC)

@Yann So can I just start uploading other people's photos of buildings posted on Flickr today without their permission then? Aplucas0703 (talk) 20:28, 20 August 2026 (UTC)

I think that it very much depends if we want to track also DWs or not. If we say "if there is a PD-own, it is sufficient", then we won't have the issue with buildings, since all the photos will have a license (for the photograph) that will be valid also in the US. But that for example won't solve the issue with foreign PD stamps and other categories of objects that are not protected in their countries of origin and on which we don't enforce US copyright. So you'll need a template for these cases nevertheless.

Anyway the biggest issue IMHO is how we intend to oblige people to use US license templates. Friniate (talk) 20:35, 20 August 2026 (UTC)

That's my point. Any photo on Commons has to have a license valid in the US (for the photo itself), so the problem vanishes. We're not trying to catch FoP issues here, just ones where someone failed to put a license for the file.

As for how we oblige, I'd say like any other file. A notification to the user telling them that they need to add a US tag and why and directing them to a list of options they can choose from. If they uploaded with a foreign copyright tag they can certainly learn how to add a US tag. Aplucas0703 (talk) 20:48, 20 August 2026 (UTC)

@Aplucas0703 I see two problems:

1. You're proposing to enforce this policy also towards existing files if I understand correctly. A user who is inactive since, let's say, an year, won't see your warning and we'll end up deleting perfectly fine files.
2. A file without any license is likely to be copyrighted. In most cases it's a photo taken from the net without any care about the copyright situation. That's why the current system for files without any license makes sense. A file with a valid license for the country of origin but without a US license it's the opposite: it's a file that in most cases is free (even in the US). So IMHO creating a system under which we'll automatically speedy delete it it's not worthy. So I agree with a warning (even added by a bot), both on the file and on the user's talk page, but then I think that we still need an human to review the situation and open a DR, without any automatic (or semi-automatic) system.

Friniate (talk) 11:03, 21 August 2026 (UTC)

 Comment There are a few separate issues that have been raised above, but have been jumbled together in a way that makes this very hard to discuss.

1. There are important differences between a license and a PD tag. A license is virtually always worldwide. It would be very difficult to construct a scenario where a piece of intellectual property has a license acceptable to Commons that is not valid in the U.S. A PD tag, on the other hand, is always specific to some jurisdiction or jurisdictions.
2. There are a small number of scenarios where Commons has agreed to host classes of images that are not entirely clean in terms of U.S. copyright law. Most of these have had lengthy discussion and reached a consensus. Yes, these are exceptions to our usual policy and yes, they smack of an Exemption Doctrine Policy that Commons is not supposed to have, but presumably if the Foundation had a problem with these decisions we would have long since heard about it, and if they represented a real-world problem it would have long since manifested itself in the form of a series of DMCA takedown notices. There are two cases I can think of, both alluded to above; there might be something else that I'm not thinking of.
   • Photographs of 2-dimensional or 3-dimensional artworks where permitted by the relevant local FoP laws.
   • Reproductions of currency and/or postage stamps of countries that permit that.

In all of these cases, we will host the image even if the artwork/currency/postage stamp is, or might be, copyrighted in the U.S. If the image in question is more than just a faithful reproduction of a two-dimensional work, then the derivative work needs a license or (rarely) a US PD tag. About the only case I can think of in which a US PD tag is likely is if the derivative work is a photo (or video, etc.) by a U.S. government employee working abroad.

Obviously, for these artwork/currency/postage stamp cases, no "clean" U.S. tagging is possible, especially not one that would give a clean grounds for commercial reproduction. And that's OK. - Jmabel ! talk 04:56, 21 August 2026 (UTC)

The issues here have gotten far too jumble to navigate at this point. The original question was if we could create the maintenance tools and deletion tags for uploads missing a US-valid license, and it has ballooned well past that original question now. Aplucas0703 (talk) 14:53, 21 August 2026 (UTC)

August 17

User script for Trove article images

Tim Sherratt has written a Tampermonkey script for downloading from Trove, the Australian archive, images of newspaper articles (from which, subject to copyright, photographs can then be extracted).

I have tried it and (subject to the caveats he states, about its slowness) it works well.

He describes it in "A new way of downloading Trove newspaper images". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:07, 17 August 2026 (UTC)

Photos by day by Australian state

~2026-43571-17 (talk · contributions · Move log · block log · uploads · Abuse filter log) block user has been creating subcategories for Australian states by day, despite most of these only ever having a very small number of photos. This seems excessive to me, and makes the daily categories harder to navigate. I know that some, such as Category:Australia photographs taken on 2026-02-08, have lots of photos, but as the vast majority of those are taken in the same state (i.e. Mapillary photos in South Australia) I don't think that diffusing is going to help. (I've left a message for the user on their temp account talk page.) Sam Wilson 23:03, 17 August 2026 (UTC)

There seems to be a lot of those:

Category:Photographs by date by country. I don't think that should be useful, you should be able to derive this from structural data... But using structural data is not easy... Nux (talk··dyskusja) 23:32, 17 August 2026 (UTC)

That kind of intersection category is not useful. If the TA continues, I will take administrative action. Pi.1415926535 (talk) 23:56, 17 August 2026 (UTC)

Thanks! I forgot to mention, one big source of these categories is {{Taken on}}, and the |location= parameter there specifically says it's for the country. Sam Wilson 00:37, 18 August 2026 (UTC)

Then perhaps the template should be modified to not do that? Categories by country by date provide extremely little practical value, especially for modern photos. There is probably more time being spent by users maintaining these categories than time spent browsing them. Omphalographer (talk) 00:45, 18 August 2026 (UTC)

I don't personally like the country-by-date categories, but there's some argument for their utility. Sub-national-division-by-date categories, like these categories being created by the TA, are almost never useful. Pi.1415926535 (talk) 00:54, 18 August 2026 (UTC)

@Omphalographer: Whether we should have the country-by-date categories is a separate question, I think. This is about the sub-country divisions, which certainly if the country ones are over the top then they also are. But anyway, it seems like we're all in agreement, and User:~2026-43571-17 seems to have given up for the time being (although there's of course now lots of clean up to do). Sam Wilson 03:33, 18 August 2026 (UTC)

@Pi.1415926535: They're still doing it, and they keep reverting me on File:Anglesea Fremantle 01.jpg. Sam Wilson 12:57, 18 August 2026 (UTC)

I support some sort of administrative action on this TA. It appears they are unwilling to be collaborative with others, since they are refusing to engage on their talk page or here in this thread, while continuing the behavior in question. Thanks. Tvpuppy (talk) 21:11, 18 August 2026 (UTC)

@Samwilson: I've blocked the underlying IP from page creation. Let me know if anything else is needed. Pi.1415926535 (talk) 16:53, 19 August 2026 (UTC)

@Pi.1415926535 there're lots of this kind of stuff like Category:Photographs of Main-Taunus-Kreis by date Category:Wertheim photographs taken on 2007-08-10. see who created those? RoyZuo (talk) 18:06, 20 August 2026 (UTC)

I would rather see the by-day categories stay at the national level. I could imagine (I haven't looked) that there might be enough photos for Sydney or Melbourne to handle those specially, but I don't think there is any gain in a breakdown by state, other than a dopamine hit for the person categorizing them.- Jmabel ! talk 00:03, 18 August 2026 (UTC)

 Done I cleaned up Category:Australia photographs taken on 2026-02-08 --PantheraLeo1359531 😺 (talk) 17:36, 20 August 2026 (UTC)

August 18

CropTool vs. Geograph template

I used CropTool to crop File:Houses on Calton Hill - geograph.org.uk - 1944687 (cropped).jpg from File:Houses on Calton Hill - geograph.org.uk - 1944687.jpg.

The latter uses {{Geograph from structured data}}, which has carried over to the new image, where it finds no data and causes warning messages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 18 August 2026 (UTC)

@Pigsonthewing The original file uses SDC data for its information, and I don't think CropTool will transfer any SDC data to the cropped files. So, you will need to manually, or perhaps use the MoveClaim Tool, to transfer the SDC data over to the cropped file. Thanks. Tvpuppy (talk) 20:57, 18 August 2026 (UTC)

It very cautiously started transferring SDC in recent updates: depict statements can now be curated before the upload is completed. I decided this on my own, since I was already adding interface elements to curate categories. There might need to be a broader discussion on what SDC should be moved forward by default and how much expansion the curation after the crop is suitable. I've had some request to make the category curation as expansive as cat-a-lot. Vera ^(talk) 05:47, 19 August 2026 (UTC)

Please avoid "hiding" information in SDC. It's a lot easier on reusers, other tools, other volunteers if SDC stuff only duplicates what is in the wikitext somewhere. Fæ (talk) 07:09, 19 August 2026 (UTC)

That ship sailed a long time ago. Holding data in a structured form is always going to be preferable to doing so using free text. The best practice of don't repeat yourself also applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:14, 19 August 2026 (UTC)

I think at some point commons needs to decide if it wants to do this whole SDC thing or not. The status quo of basically duplicating metadata in both places seems really bad and kind of worst of both worlds. In the long term we should pick a method and stick with it. Bawolff (talk) 21:38, 19 August 2026 (UTC)

"Depicts" like the category list, is tricky, because a subject may be cropped out of the image, or made prominent where it originally was not. The same for "caption". But creator, date, location (usually; there are edge cases) and camera details, etc are consistent.

It might be possible to detect that, say, only 10% or less of the image is lost, and assume that all SDC persists. Or to have a "Has the subject(s) of the image changed?" check-box. Or to add cropped images to a "Cropped images needing SDC check" category (perhaps via a template), which experienced CropTool users can then remove. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:05, 21 August 2026 (UTC)

Thank you I'm aware of the cause, and the solution. My point is that we direct inexperienced users to use CropTool, yet there is no advice or warning for them about this issue, which is likely to occur with increasing regularity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:10, 19 August 2026 (UTC)

August 19

"Information and education only"

I want to upload this video (or a still frame of it) from the European Commission Audiovisual Service using the relevant license, but it states in the conditions of use that its for "Information and education only". Does Commons fall under this use? Hsnkn (talk) 04:55, 19 August 2026 (UTC)

@Hsnkn: Commons as project itself is educational, yes, but you can't upload media with such restrictions nevertheless. This is because any file hosted here has to be free and must fulfil the requirement of re-usability for any and all purposes, including commercial endeavours. Please refer to COM:Licensing for further details. Regards, Grand-Duc (talk) 05:26, 19 August 2026 (UTC)

Understandable. Looking at the shotlist section, only the "Exterior view of the Breydel building, in Brussels" from 0:08 to 0:13 is marked as educational, while the other parts don't have any copyright restrictions written. Would this mean that anything in video that isn't in that timeframe is permissible for uploading? Hsnkn (talk) 05:53, 19 August 2026 (UTC)

Yes. If you are going to make this a mini project, then it would be sensible to make sure the evidence about which parts are freely licensed is well presented and preferably linked to archive.org as permalinks. Video is complicated, so keep in mind music, graphics, screenshots, artworks that might be in the background can be problems for copyright. However if you've made reasonable efforts, nobody would blame you if an upload were challenged for something you missed. Fæ (talk) 07:07, 19 August 2026 (UTC)

Actually I wasn't thinking about editing the video, just uploading a screenshot. Hsnkn (talk) 07:31, 19 August 2026 (UTC)

@Hsnkn: I took a peek at the {{EC-Audiovisual Center}} tag, apparently, it's designed to call for a license review. That's helpful. So, I'd suggest that you upload your extracted video still with that licensing tag, and please do not forget to mention the timestamp from where your image is taken. Then, come back here and show the link to your upload - I am (and Fæ too) a license reviewer, and if nobody beats me to it, I'll make the review.

And if I'm not mistaken, the video is actually a legit CC-By file, that statement "Scopes : Information and education only" is seemingly outside the licensing statement and thus irrelevant for the copyright status. Regards, Grand-Duc (talk) 08:08, 19 August 2026 (UTC)

Here it is. Hsnkn (talk) 21:58, 19 August 2026 (UTC)

@Hsnkn: I've provided the review. And, just as a side note, as I saw you cropped the image: I would always recommend to use the lossless mode of the CropTool, not the precise mode if it can be avoided. The reason is: using the precise mode engenders a new encoding which causes en:generation loss in lossy file formats like JPEG. The lossless mode doesn't do that, it keeps the encoding that's already present. Regards, Grand-Duc (talk) 09:24, 20 August 2026 (UTC)

ohiomemory.org

Commons currently has over 64,000 images of various kinds, including page scans and screenshots from "Ohio Memory". Unfortunately the website terms of use page spell out a number of conditions that do not meet Wikimedia Commons policies. For example:

One-Time Use.
The right to reproduce materials held in the collections of the Ohio History Connection is granted on a one-time basis only, and only for private study, scholarship or research. Any further reproduction of this material is prohibited without the express written permission of the Ohio History Connection.

Use Agreement.
Materials are reproduced for research use only and may not be used for publication, exhibition, or any other public purpose without the express written permission of the Ohio History Connection. Reproduction of any materials that are a part of Ohio History Connection’s collection without submission of a request for reproduction to Ohio History Connection, using the organization’s forms for such requests, is prohibited. Reproduction of any materials submitted by or owned by any institution participating in the Ohio Memory program without that institution’s permission is prohibited.

We have an example deletion request at Deletion requests/Files found with 2052def8d8d0287275ea8e069f7bf5e2, though general comments about what should be done to either clarify copyright or delete all images from this source would be welcome here. Fæ (talk) 14:38, 19 August 2026 (UTC)

The source has plenty of uploads which are obviously public domain regardless of their claims, eg.:

• File:Catherine Cooper Hopley with turtle.jpg
• File:Amos Sutton Hayden portrait photograph.png
• File:Sardis Birchard, 1871 engraving by Alexander Hay Ritchie.jpg

Any deletion request would have to be selective enough to at least exclude such images. – Howardcorn33 (💬) 14:46, 19 August 2026 (UTC)

Yes, though I'm thinking that a simple search for works stating publication after 1931 could be a starting point, though a non-controversial deletion request could be everything from this source claimed as published after 1977. Fæ (talk) 14:59, 19 August 2026 (UTC)

To be truly non-controversial would be to start at publication after February 1989, but post-1930 is probably more acceptable as a starting point. – Howardcorn33 (💬) 15:03, 19 August 2026 (UTC)

As an experiment, populating Category:2020 publications from ohiomemory. Looking at a couple of photographs these seem specifically created with a public domain dedication, but it needs checking each time. There are a lot of Covid related documents, these were published by state agencies, which do not automatically make them copyright free based on Ohio state copyright legislation. Without specific releases these can be rationalized for deletion. There are also more generic documents like File:Semi-annual report - for the period (2020-07-01 to 2020-12-31) - DPLA - 8c0b7139c2173ffe8269c29b58f87bda.jpg which are probably out of scope for Commons but in addition there is no required copyright statement and though it is a government document, it is an Ohio State government document not a federal work, so may have copyright, plus the source quoted no longer exists so this front cover screenshot is very unhelpful in providing any evidence of a copyright release.

It's messy. Fæ (talk) 15:36, 19 August 2026 (UTC)

The literal first image in that category is clearly not from 2020. I hope there isn't further such miscategorization. – Howardcorn33 (💬) 15:53, 19 August 2026 (UTC)

That's not a surprise, this is a basic search looking for 2020 anywhere, so the Women in Red category was picked up even though this had nothing to do with date of publication. In fact these particular uploads are incredibly difficult to filter on as the wikitext has been made deliberately blank by the DPLA. Even worse in the samples looked at so far, the SDC data doesn't have anything accurate to say about publication dates, even though the publication may have the year (2020) in the title.

It's messy. Fæ (talk) 18:45, 19 August 2026 (UTC)

Sample DR based on this filtering, entirely manual confirmation, so unfortunately it's not going to be possible to do this for the tens of thousands of uploads in this painstaking way. This is wrong, the *burden of proof* for copyright must be on the uploader, not everyone but the uploader.

1. Deletion requests/Files in Category:DPLA AR no source
2. Deletion requests/Files in Category:DPLA auditor of state bulletin ohiomemory
3. Deletion requests/Files in Category:DPLA Consumer Advocate ohiomemory
4. Deletion requests/Files found with "Ohio--Census
5. Deletion requests/Files found with "Combating COVID-19." ohiomemory

--Fæ (talk) 19:04, 19 August 2026 (UTC)

Updating authorship of 1.7 million files

We have had folks from UN agencies request that we add them to the author line when they are providing the underlying data for an OWID graph. We would like to make a bunch of edits like this.

Basically replacing the author "Our World in Data" with the Source line as listed in the accompanying reference such as this which is "AQUASTAT - FAO's Global Information System on Water and Agriculture, FAO, via World Bank (2026) – processed by Our World in Data". Any concerns? Doc James (talk · contribs · email) 17:25, 20 August 2026 (UTC)

@Doc James: Is their request about the author, or the required attribution, or both? - Jmabel ! talk 05:07, 21 August 2026 (UTC)

The plan is to adjust the author line like this... so we mention the source of the data https://commons.wikimedia.org/w/index.php?diff=1262506461 Doc James (talk · contribs · email) 05:13, 21 August 2026 (UTC)

@Doc James: That isn't what I asked. I'm trying to understand if this lengthy string is now requested by the relevant UN agencies as the required attribution for the CC licenses. - Jmabel ! talk 06:13, 21 August 2026 (UTC)

Their request is reasonable IMO. Currently attribution of them is two clicks rather than one click away. So I have no issue with adding this. Doc James (talk · contribs · email) 06:18, 21 August 2026 (UTC)

That still doesn't answer my question. So I guess I'll just get to what I am driving at, without knowing whether it is relevant or not. If they want this as an attribution, and they are not just asking for this in the "author" field on Commons, I strongly suggest that we also add it explicitly as an attribution parameter in the template for the CC license for the file. Otherwise, reusers are very likely to get this wrong. - Jmabel ! talk 06:40, 21 August 2026 (UTC)

Not sure what you mean? Can you show me an example? Doc James (talk · contribs · email) 06:46, 21 August 2026 (UTC)

Author is: who is the copyright holder (by ownership or by creation). Attribution: how and who do you (per the license) want to be advertised for credit.

What Jmabel is trying to determine, is which of these need needs to be updated. One of them, or both. The copyright of the graph image is with OWD (if it even is copyrightable as a pure data visualization), the pure data is not copyrightable (in most jurisdictions). So they just want the data source to be known to people (as part of their license requirement, irrespective of copyright owners). So that is attribution. In practice, we treat our own author field as a random data collection (not just copyright owner, but also sourcing and sometimes attribution or an entire Wikidata subgraph rendering) so we might as well update it there as well. —TheDJ (talk • contribs) 08:52, 21 August 2026 (UTC)

The author is not necessarily the copyright holder. We have many images with a named creator, whose copyright is held by their employer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:52, 21 August 2026 (UTC)

The license is CC-BY and the version of that deed linked to states You must give appropriate credit, provide a link to the license, and indicate if changes were made.
it then also states No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
So a technical reading of this is that care should be taken to define precisely who the creator (author) was and that should be presented in a way that is unambiguously the legal attribution required. The implication is that someone could be sent take down notices if they do not get that attribution precisely correct. Additional information like any changes or who processed it later can be added but that's not the legally required attribution. My guess is that is what is wanted, fair credit to later processors but not legal constraints as those changes are intentionally minor.

There's a potential twist here (feel free to ignore this observation, it's getting hypothetical but it illustrates possible downstream questions) as there could be cumulative attributions (despite in theory the license ruling them out) depending on whether changes made infer enough creativity to require their own attribution. If this is what is wanted because the formats of charts is thought to be creative work by those that design and implement them, that's fine, but we might need to spell out the different parts to the attribution that would be legally required. A twist that probably does not exist here is that additional work does not have to have the same copyright, so that could be less restrictive, like CC0 or more like CC-BY-SA. Ugh, there's another twist around data, but that's a can of regional copyright worms that I don't want to open. --Fæ (talk) 08:33, 21 August 2026 (UTC)

So both OWID and the UN agencies would be happy to have both listed in the author line on Commons as they see themselves both as contributing to the authorship of these graphs. What is legally required, I am not sure. But regardless of what is required I think adding them both to the author line is reasonable per User:TheDJ explanation "we treat our own author field as a random data collection (not just copyright owner, but also sourcing and sometimes attribution" Doc James (talk · contribs · email) 17:32, 21 August 2026 (UTC)

@Doc James: With 1.7 million files, you definitely want to get these changes right the first time, whatever "right" may mean. Using your example of File:Agricultural water as a share of total water withdrawals, World, 2022 (cropped).svg, and going by the above, it is possible that besides the edit to the author field they would really want the license tag to read "{{cc-by-4.0|attribution=AQUASTAT - FAO's Global Information System on Water and Agriculture, FAO, via World Bank (2026) – processed by Our World in Data}}", which produces:

If that's what they want, let's make sure we get it right in a single pass through this large set of files. If you're not sure, then it would be worth asking again before a massive batch job starts. - Jmabel ! talk 20:39, 21 August 2026 (UTC)

Thanks that makes sense. Will reach out. Doc James (talk · contribs · email) 20:43, 21 August 2026 (UTC)

Is the intention to use the exact same text on all 1.7 million files? Or is "AQUASTAT - FAO's Global Information System on Water and Agriculture, FAO" just one example of several? If the latter, how many variants are there? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:55, 21 August 2026 (UTC)

No, the plan is to go to the source in question for the image in question and use either "Data source" in the caption or "Source" in the metadata on OWID. See here for example[1] were it would be "National statistical organizations and central banks, OECD national accounts, and World Bank staff estimates (2026) – processed by Our World in Data"

We have already updated the OWID SVG upload tool to do this going forwards. Doc James (talk · contribs · email) 20:57, 21 August 2026 (UTC)

You haven't really answered what I asked.

I also note that it appears that the image in your first example is a crop, and that the text you want to include is what was cropped from the original. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:12, 21 August 2026 (UTC)

Q: "Is the intention to use the exact same text on all 1.7 million files?" Answer: "No". Q: "how many variants are there?" Answer: "Lots I imagine, likely a few housand anyway" Doc James (talk · contribs · email) 21:37, 21 August 2026 (UTC)

@Doc James: My apologies for adding to the already impressive level of pedantry in this thread, but it seems to me that the UN agencies should be properly credited as the source of the data, not as authors of the infographics, which were created by Our World in Data. These are very different things from a copyright perspective, and I think it would be unfortunate to muddle them together. What's worse is that the wording in your example seems to give primary attribution for the infographic to the UN agency, while listing Our World in Data almost as an afterthought "– processed by Our World in Data". From a copyright perspective, Our World in Data is probably the only copyright holder for that graphic and thus the only party that technically needs to be attributed for the CC license. In my opinion, it would make much more sense to list the UN agency explicitly as the source of the data in the author or source fields (or even using the 'other fields' field) and leave the licensing template unchanged (or if we do want to set an explicit attribution, set it to 'Our World in Data'). Do you think that would be acceptable to the agencies in question? Nosferattus (talk) 10:24, 23 August 2026 (UTC)

August 21

Philippine proposed law: House Bill 9981 of 20th Congress

The PDF file of this bill

I felt it is best to share this House Bill here, since that it hasn't been incorporated in the law yet. This House Bill concerns granting a new threshold for AI-generated works. As the proponent stated, "this Bill addresses this gap by amending R.A. 8293 to introduce distinct legal thresholds. It explicitly clarifies that while purely AI-generated materials belong in the public domain, AI-assisted works are protectable only to the extent of the human author's creative control, modification, and arrangement. It also introduces a mandatory disclosure mechanism during registration to maintain transparency and protect the integrity of the intellectual property system."

It proposes to add a new Section 172.4 under the current PH copyright law, to be read as:

172.4. Copyright in AI-Assisted Works. – AI-assisted works shall be eligible for copyright protection, subject to the following conditions:
(a) Protection shall only extend to the original elements of human expression, arrangement, selection, or modification added by the natural person, and shall not cover the underlying AI-generated content itself.
(b) To determine eligibility, the Bureau of Copyright shall apply the 'De Minimis Non-Curat Lex' standard to the AI's contribution. If the AI-generated portions are mechanical, automated, or subordinate to the independent creative execution of the human author, the work as a whole is copyrightable.
(c) Prompt engineering alone, consisting of standard descriptive commands or strings of text, shall not satisfy the threshold of original human authorship unless accompanied by substantial post-generation modification, arrangement, or creative synthesis by the natural person.

It may likely institutionalize de minimis for the first time as a copyright concept here in the Philippines, something that isn't for a very long time, considering that fair use is a usual standard by the courts in testing the claimed infringement. However, it instead applies de minimis in the context of the degree of AI's contribution. De minimis isn't formally recognized as a copyright concept here, but rather is a term in customs duties and tax-exempt employee benefits. JWilz12345 (Talk|Contributions) 15:01, 21 August 2026 (UTC)

August 22

Angel with devil or demon

Do we have a category for an image of an angel with a devil or demon? I would think something like that should be a parent to categories like Category:Saint Michael beating the Devil but also to images like File:Cabin in the Sky (1943 film poster).jpg, which is actually why I thought of it. - Jmabel ! talk 00:47, 22 August 2026 (UTC)

There's also the popular shoulder angel/devil trope a la file:CaptMarvelAdventures31.jpg... Arlo James Barnes 04:07, 22 August 2026 (UTC)

Yes, the Cabin in the Sky example is like that, even if they are not on the shoulders. - Jmabel ! talk 04:22, 23 August 2026 (UTC)

Demolition or Demolitions - in "country name"?

I accidentally created Category:Demolition in the Philippines without knowing that Category:Demolitions in the Philippines exists, using the Japanese categories as the template. Category:Demolition in Japan. What is the standardized category naming for demolition/s? JWilz12345 (Talk|Contributions) 08:25, 22 August 2026 (UTC)

I'd lean toward "demolition" (the activity) rather than "demolitions" (individual projects of demolishing things). For example, a demolition firm or demolition equipment would fit under the former, but not the latter. - Jmabel ! talk 04:24, 23 August 2026 (UTC)

There must be unified rules for all countries' categories. JWilz12345 (Talk|Contributions) 05:14, 23 August 2026 (UTC)

Difference between Category:People on boats vs Category:People in boats?

Is there a difference between those two categories or are they just two different phrasings to express one and the same thing? If they are the same, then which one would be the more common phrasing and which should be a redirect? Nakonana (talk) 08:42, 22 August 2026 (UTC)

For canoes and small barges the distinction is moot, but for larger vessels there are definitely separate interiors and 'topsides'. Arlo James Barnes 23:32, 22 August 2026 (UTC)

Native American English speaker: this is a distinction without a difference to me. Even in the case that Arlo mentions of someone being topside, I could just as easily say that he's "in a boat" and someone in the guts of the boat is "on a boat". ―Justin (koavf)❤T☮C☺M☯ 23:42, 22 August 2026 (UTC)

Also a native American English speaker: I would certainly never say someone was "on" a canoe or small rowboat. Once you get even up to a liferaft or a very small sailboat, they become pretty interchangeable. Much larger than that and "on" is almost inevitable (you'd never say someone was "in" a cruise ship or a merchant vessel, though oddly now that I think of it you could for a submarine). So if we intend to cover that whole range, the choice is pretty arbitrary. - Jmabel ! talk 04:33, 23 August 2026 (UTC)

Aside: that submarine case is weird. You can equally say "Chuck lived in/on a submarine for six months" but probably not "Chuck lived in the U.S.S. Nautilus for three months," once you bring in the name it has to be "on" even though it's a submarine. English is weird. - Jmabel ! talk 04:33, 23 August 2026 (UTC)

Now that you've mentioned the canoe example I realize that German actually also makes this distinction. Looks like this is more complex than I thought. Nakonana (talk) 19:18, 23 August 2026 (UTC)

I agree that 'in' is the more generic/ambiguous usage, so I'd redirect that to 'on', and if it is necessary to specify then people inside boats could be used. Arlo James Barnes 17:56, 23 August 2026 (UTC)

CCTV images related to the killing of Brian Thompson

Several images in the category Category:Killing of Brian Thompson are of an individual caught on CCTV in December 2024 who was suspected of carrying out the killing of Brian Thompson. Since the recent guilty plea of Luigi Mangione to the killing, his English Wikipedia article and his Wikidata entry use an image from the CCTV footage and explicitly identify him as Mangione. Can Commons now also explicitly identify the individual in the CCTV footage as Mangione in file descriptions and move the images into the category Category:Luigi Mangione? – Howardcorn33 (💬) 09:59, 22 August 2026 (UTC)

Unlike Wikipedia, files on Commons are a snapshot. There's no expectation or 'by design' that media uploaded with descriptions or file names correct at the time of upload would ever be updated; though they can if a volunteer wants to, preferably adding information and preserving the nature of the record of the original upload. However certainly moving categories around to be a more accurate taxonomy is a conventional thing to do. Fæ (talk) 13:22, 22 August 2026 (UTC)

If it were to be mentioned in the description, it should be something like "later identified as". - Jmabel ! talk 04:45, 23 August 2026 (UTC)

MIME Type Problems upload jpg file

I try to upload this file. But the uploader doesen't want to upload it, as it has the wrong MIME type. I tried to change it from jpg to jpeg (all lowercase letters) but that doesn't help. Can some body tell me how the file extension should be correctly?--Sanandros (talk) 19:51, 22 August 2026 (UTC)

I downloaded the file from https://media.defense.gov/2023/Feb/16/2003162697/-1/-1/0/230212-A-LU981-003.JPG and took a look at it with a HEX editor, looking for the en:Magic number (programming) for JPEG. The starting FF D8 is actually present, so I can't provide any other clues as for why the upload fails. JPEG should be correct when going by the innards of the file. Maybe you could try a new download? It's not excluded ATM that your file is corrupted. Or past your {{Information}} contents that you wish to use here, I could try an upload myself, Sanandros. Regards, Grand-Duc (talk) 20:14, 22 August 2026 (UTC)

Ja ein neuer Download hat geklappt siehe File:Arctic Forge 23 Logo 230212-A-LU981-003.jpeg. thx. Falls ich gewusst hätte dasst du so schnell reagieren würdest hätte ich gleich beim Forum gefragt.--Sanandros (talk) 20:30, 22 August 2026 (UTC)

@Sanandros: Bite bitte. :-) Ich habe VP und Forum beide auf der Beobachtungsliste und war eh vor dem Bildschirm, daher die schnelle Reaktion. Grüße, Grand-Duc (talk) 21:19, 22 August 2026 (UTC)

August 23

Show Wikidata item P18 usage alongside "File usage"

Currently the image file File:The hand that will rule the world.jpg shows wikipedia usage, but it is does not show wikidata usage (typically P18 image property), unless you go to "global usage". I believe this should be more prominent. This is not an issue of too many links, for example File:Tarifmappe Haustarifvertrag Volkswagen.jpg links to 3 Wikipedia pages but doesn't show Wikidata still, even though d:Q163887 links to it via P18 image property Shushugah (talk) 08:45, 23 August 2026 (UTC)

I see it is mentioned in File:Tarifmappe_Haustarifvertrag_Volkswagen.jpg#globalusage which makes me think it is an issue of database syncing, and which wikis are sorted first when there are too many mentions. Is there a way to sort/personalize the hierarchies of wikis shown? My hunch is most users want to see their home wikis first, and perhaps multi-lingual wikis because they are less common/have a global value, whereas language specific wikis are specific? Shushugah (talk) 10:01, 23 August 2026 (UTC)

It's there, just like any other sister wiki; it's just that when a certain limit is exceeded, it won't all end up on the first page. - Jmabel ! talk 17:44, 23 August 2026 (UTC)

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)

@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)

Deletion of History categories

Just asking, WHY are we now systematically speedy-deleting "History of" categories? "History of stuff" should be a thing we want to keep, not to delete? After all, this is history, and we want to preserve it and keep knowing about it, don't we?

History is not simply another synonym of "black-and-white photographs". Sure, in some cases it may look like that, but following up on that assumption, that means non-photograph documents are just shoved back into the main category of the subject, or into "art of" the subject, versus "other documents about" subject. Sorry if I'm singling out just one editor here, but I do have noticed several other occurences of similar practices like that in the previous months. Sadly, I cannot search to find deleted history categories... because they are apparently deleted.

I do hope that I don't get sophistry in response, like "everything is history if you just think long enough about it". We already decided to abolish all "historical images of" categories and merge them back into "history of", and now we destroy the history categories themselves? As if there is nothing that distinguishes an artwork from the 17th/18th century from an artwork of the 21st?

References

--Enyavar (talk) 15:12, 23 August 2026 (UTC)

Regardless of your rejection in the last paragraph, in my view, "historical" is not a meaningful distinction. "17th-century" is meaningful. "21st-century" is meaningful. Use those. To a 20-year-old, even the early 21st Century presumably looks like "history"; for others of us, the decolonization of Africa is living memory. - Jmabel ! talk 17:51, 23 August 2026 (UTC)

Stuff is surprisingly historical when it's from the 6th century. Subjective categories are a time sink best avoided. Fæ (talk) 19:04, 23 August 2026 (UTC)

Jmabel, what do you do when you cannot determine the year a photo was taken, except "between 1880 and 1910" - which century are you placing that photo in? Both? Or do you create a category "photos of the Taj Mahal by millenium"? With regards to pottery from "between the 3rd and the 6th century", does this mean the pottery is from all three centuries at the same time? And please be my guest, look at History of Lyon and tell me how all this content can be neatly categorized into other subcategories of the place so that we can delete the history-category and avoid all this pretend-confusion about what history means. --Enyavar (talk) 04:39, 24 August 2026 (UTC)

Balack and white?

I was an er, interesting choice to put the above in a category for black and white images. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:00, 23 August 2026 (UTC)

I've since found further examples, including a watercolour painting added to a category for black and white photographs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:24, 24 August 2026 (UTC)

Related, a constant mild irritation, why do folx use "Men" in categories but rather than "Women" use "females". My mother used to say "female what, cats?". Eg. Category:Men with microscopes vs. Category:Females with microscopes. --Fæ (talk) 09:34, 24 August 2026 (UTC)

True, but those folx claim "we've always done it that way". You may want to remain blissfully unaware of Female humans' health, Male humans and other such CfDs in the recent years... a.k.a. "no girl has ever been a woman". But that's offtopic here. --Enyavar (talk) 15:26, 24 August 2026 (UTC)

UK govt falsely claims photography of people in public is illegal

UK Home Office issues incorrect guidance that "In the UK, you should not take pictures or videos of someone without their permission", and that doing so could lead to arrest. This is contrary to the law, and to their own police guidance. They even tell people to report being photographed in public to the police.

Reported in "The Home Office Needs To Get Photographic Law Right". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:38, 23 August 2026 (UTC)

LOL. Side-bar. Once I was stopped by a police officer when taking shots on my 'proper' camera of the cast ironwork at one of London's oldest train stations. I was polite and mostly amused, having recently read up on the legislation. I quizzed him if there were special reasons to stop me, then if this was a public space. He resorted to mentioning the terrorism act, but crumbled and let me carry on, mostly due to my raised eyebrows and asking exactly what part of the act would necessitate me not taking photos at that moment when there was no incident. He even let me take a portrait photograph of him; which I politely requested.

Anyway, I rarely take shots with people, and if anyone genuinely does not want to be personally photographed I am always courteous and reassuring that I respect their wishes. If anyone runs into threats of arrest, please make careful notes of exactly what words they use, remain excessively polite, follow their orders but preferably take video and publish on YouTube later, there's lots of photographers in the UK that will be interested in what the police think the law is. As for "Home Office" guidance, considering they are run by Shabana Mahmood, sure, their documents are going to be absolute pants. --Fæ (talk) 18:55, 23 August 2026 (UTC)

Isn't it similar in other European countries (like Germany[2][3]? And in Japan, too? You may photograph (large) groups of people per the logic that any individual in the group will be "de minimis", so to speak. But if you are photographing single individuals (or small groups) then you actually need to ask people for permission (even outside in public, unless the people in question are public people like politicians, performers, famous people). And yeah, going by the law, a prison sentence is possible under certain circumstances in case of violation. Nakonana (talk) 16:27, 24 August 2026 (UTC)

If what you say about Germany and Japan is true, then, no that is not similar to the UK, where no such restrictions apply. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:34, 24 August 2026 (UTC)

August 24

Proposal for making Template:No watermarks 1% more understandable and friendlier

Hi :) Join this talk about a widely used warning:

See also: Template talk:No watermarks/en.

Thanks! bozz (talk) 12:43, 24 August 2026 (UTC)

Chunked uploading support

There's been some progress made to allow chunked uploading from Special:Upload (instead of just UploadWizard). This should long term be able to replace User:Rillke/bigChunkedUpload.js and bring this functionality to all wikis by default. You can currently test this by using the 'usechunked' url parameter Special:Upload?usechunked=1. This should give an increased upload limit. I'd love for people to give it some testing, so that eventually this can become the default for all wiki's. It should only kick in if you do an upload above 100MB. The open ticket for this feataure development is T74768. Let me know what you think and if you encounter any problems. —TheDJ (talk • contribs) 14:06, 24 August 2026 (UTC)

Re-examination of the colors of the flag of Taiwan (Republic of China)

It has been 17 years since the colors of the flag of the Republic of China/Taiwan were 'finalized'. They were based on sources available to Wikipedians at the time. I think there are more than enough new sources for us to re-examine this issue again.

1. The Ministry of the Interior's and the Presidential Office's Illustrator masters.

In 2011 and 2014 respectively, Taiwan's Interior Ministry and Presidential Office released an example of the national flag in .ai format. Both are identical in color, with the only differences being their image size, it would seem. As the original files were made using a CMYK format and the exact color profile is not saved, I cannot say definitively what display is necessarily correct. I have, however, managed to narrow down the likelihood of the color profile being Japan Color 2001 Coated, considering how close its output is compared to the government's JPEG preview of the same AI file. Blue is C100-M80-Y0-K20 and Red is C0-M100-Y100-K5; which when converted into sRGB with the Japan Color 2001 profile yields #003686 for blue and #DF0012 for red. The presidential office's JPEG version yields #003487 and #DE0011 respectively. This aligns with the Ministry of Interior's recommendations.

2. Web logos

taiwan.gov.tw uses #CF1400 and #000095 for its main logo; later it uses #E60012 #0B3190 in its 'About Taiwan' section. The Presidential Office uses Wikipedia's present color palette in its logo. However, it also uses this color palette in a section about the national flag: #DF0012 and #013686. Please take note of how close this is is to the Ministry of Interior's color specifications.

3. Photographic evidence

1, 2; and many others show generally darker colors, not neon red and blue. While it's true that photographs are not perfect given lighting conditions, the pattern still remains.

4. Conclusion

The Ministry of the Interior has already provided color specifications, multiple masters/examples and the like. The presidential office has provided an example which aligns with the MoI's specifications. Other sources may use alternative colors, but we have actual color specifications and numerous examples prepared by the Taiwanese government which all have nearly identical colors.

5. Display

Current colors & proposed colors

• 
  Current colors
• 
  Proposed colors, from the Presidential Office

Please give comments and thoughts below.