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

People of Ngadisan (Java, Indonesia) are filling their cans at the village pump. The old well is defunct and replaced by a water tap. [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive Commons:Village pump#Help needed to close 6,323 Category for Discussion cases (9 March 2025) User talk:CommonsDelinker/commands#Replace images with .svg version (5 August 2025) Category talk:Heroes' Cemetery in the Philippines#RfC: Cemetery name (18 July 2025) Hosting of free fonts in Commons (18 July 2024) 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)

May 23

Geographic distribution of featured pictures

open Category:Featured pictures on Wikimedia Commons in wikimap.

as of 2026, among the files with coordinates, the area around blue banana accounts for roughly 10 times more files than any other region of similar sizes.--RoyZuo (talk) 17:31, 23 May 2026 (UTC)

I think some NRW contributors did a great job here :) --PantheraLeo1359531 😺 (talk) 08:06, 24 May 2026 (UTC)

https://xkcd.com/1138/ is doing some of the work there. It's a rich and populated area in Europe. – b_jonas 11:39, 27 May 2026 (UTC)

the unusual thing is there are not as many images from usa east coast or west coast. RoyZuo (talk) 12:13, 2 June 2026 (UTC)

May 25

WMF Community Tech disbanded, 6 people laid off.

• meta:Community Wishlist#May 20, 2026: Community Tech becomes a program
• meta:Talk:Community Wishlist#May 20 update
• en:Wikipedia:Village pump (WMF)#WMF Community Tech team has been disbanded, engineers laid off

In another case of the WMF making decisions without the community, WMF has disbanded Community Tech, and laid off six people. This continues a trend in which community wishes and needs are ignored by WMF. Now the system pits Commons against other projects to get quality of life improvements or to improve our situation with needed tools. I doubt whatever WMF has in mind to replace CommTech will actually get us the kind of technical support we actually need. I agree with User:Novem_Linguae that wishlists need to go back to yearly and individually ranked so it can be shown to WMF what urgently needs to be improved upon. I am also concerned about WMF laying off longtime community members that actually understand the community. I don't like WMF removing that kind of expertise from their staff. I worry about the kind of work culture that the WMF might be fostering by firing well-qualified and well-liked people and by actively working against any kind of dissent. WMF seems to be responding in a familiar pattern as noted by User:Rutebega you see the same recurring themes: The WMF makes a decision behind closed doors without consultation. They announce the decision late or not at all before implementation. When the community pushes back, they act like they're the ones being blindsided. They claim confidentiality and make general statements without addressing the community's core concerns. They say they are listening and request questions and feedback from the community, to which they have no intention of responding. They sometimes go as far as to issue a non-apology without accountability or any specific commitments. They claim to want to be more responsive and transparent, but it's just part of the charade. This is their strategy of crisis management: waiting it out, saying as little as possible, making empty promises, taking no direct action, and sequestering the last hardliners in some farce of a listening committee, where their complaints can be ignored more directly.

And so, here at Wikimedia Commons, what should our response to this be? Abzeronow (talk) 04:29, 25 May 2026 (UTC)

Incredibly alarming news, especially considering the possibility being discussed on enwiki that this was union-busting. Since there's already a long discussion on enwiki that we don't need to replicate here, I would suggest that Commons follow any community actions that enwiki takes, of which disabling fundraising banners seems to be the most likely. Pi.1415926535 (talk) 04:47, 25 May 2026 (UTC)

This is really devastating and disappointing. We have several tools to be included, and this is an unnecessary fallback --PantheraLeo1359531 😺 (talk) 08:48, 25 May 2026 (UTC)

WMF is a deal with the devil we can’t escape from because without it there’s literally no Wikimedia. They don’t care about their editor base and never will because they rake in gazillions of dollars by pretending the biggest educational website on the planet is struggling to keep the lights on and selling out to data-hungry tech giants. We are just free labor that is endlessly replaced with a neverending supply of naive idealists so it’s not like it would even matter if we all went on strike or something. What point is there in a “response”? Dronebogus (talk) 09:49, 25 May 2026 (UTC)

Maybe we should protest that --PantheraLeo1359531 😺 (talk) 14:56, 25 May 2026 (UTC)

WMF is full of well-intentioned people, from conversations I've had with current and former employees, they recognize that the lack of trust is a problem, which makes their actions even more frustrating. Yes, their fundraising is misleading, but they do fund people which is a necessary thing. The point of a response is to show that the community believes that they are wrong and should listen to us. I brought this up to both inform the community (since some may not have heard) and to ask the community what we want to do about this issue. I'm willing to follow through with what the community decides. If we decide to follow enwiki's lead, then I'll do what I can to see it through including relaying what the community says to WMF during Wikimania. If I need to start taking this matter to social media, I will do so. Abzeronow (talk) 03:17, 26 May 2026 (UTC)

Doesn’t matter who it’s full of, they could all be saints and bodhisattvas for all I care. Whoever is really in charge clearly doesn’t give a shit. And why should they? What have they possibly got to lose if they piss off a bunch of us little people who are literally volunteering to work for them? It’s not like they are even responsible for our wellbeing. It’s not like we have rights. In all seriousness they have bigger concerns than this, namely protecting Wikimedia from censorship and other legal problems we simply cannot deal with as volunteers. It sucks, I’m not defending their actions or their treatment of the community as expendable, but they have no reason or incentive not to act this way. Because we’re contributors, we’re meant to be expendable. Dronebogus (talk) 09:55, 26 May 2026 (UTC)

Perhaps ENWP editors is. Commons users sure as hell aren't expendable Trade (talk) 19:22, 26 May 2026 (UTC)

Even if all of Commons’s “local” userbase left overnight users would steadily funnel in from the projects it exists to serve. Wikidata would be a similar situation, but even more extreme given its smaller community. The biggest problem would be the sysops, who are already overwhelmed on both projects. Dronebogus (talk) 20:36, 30 May 2026 (UTC)

Individual editors may be expendable, but the editor base as a whole is not. If there are community decisions to start highly-visible protests like blocking fundraising banners, adding counter-banners, or blacking out wikis, that could generate a lot of bad press from the WMF at a time that it's very protective of its public image. (And if they try to overrule community decisions, that's liable to backfire on them.) I don't think the decision-makers at the WMF understand just how poorly the editor community regards them, nor what said community is willing to do. They think they can just wait for the storm to pass. Pi.1415926535 (talk) 20:16, 26 May 2026 (UTC)

"Individual editors may be expendable" It really does depends on the project in question. On less active projects this absolutely does not apply Trade (talk) 20:46, 26 May 2026 (UTC)

Less active projects (particularly less active language editions) are themselves expendable. Wikinews has already been axed, and smaller Wikipedias are slowly being culled. That isn’t necessarily a bad thing, since these projects clearly didn’t have the user bases to maintain an acceptable standard of quality and therefore were not realistically useful. But it goes to show that “expendability” is relative. Dronebogus (talk) 20:30, 30 May 2026 (UTC)

Wikinews had people who wanted to improve it, Wikimedia NYC wanted to remake Wikinews into something better, but the Board of Trustees already decided to kill Wikinews and used the process to kill it. Also Greenlandic Wikipedia was culled because the only sysop didn't want to continue, and there was essentially no user base that was fluent enough to keep it going, and Greenlandic speakers outside of Wikimedia thought that particular Wikipedia was harmful. Abzeronow (talk) 02:40, 31 May 2026 (UTC)

True, language edition culling is really a community process anyway. And while Wikinews was a failure (albeit a noble one), the largely top-down and opaque closure process wasn’t how it should have been done. Dronebogus (talk) 16:07, 31 May 2026 (UTC)

I was just stating that there are good people within WMF, who are making very poorly thought out decisions. Individually, we don't have much power, but collectively, a project can make decisions that WMF will be unable to ignore. As Pi says, I don't think WMF comprehends just how badly this could go for them. Abzeronow (talk) 03:20, 27 May 2026 (UTC)

before people get all riled up, there's a simple question that i dont seem to find in the super long discussions elsewhere.

what is the actual impact of this restructuring by wmf? that means, what's the impact in terms of money and man-hours dedicated to "tech", immediately and in the long run?

if money and time are not reduced, i think it's up to wmf however they want to restructure. RoyZuo (talk) 09:56, 26 May 2026 (UTC)

I agree. I don't even know what was on the community wishlist, and how it was decided they were the wishes of the community. Secretlondon (talk) 16:35, 6 June 2026 (UTC)

Speedy deletion criterion G5

In relation to Commons talk:Criteria for speedy deletion#Content created by a sockpuppet, can COM:G5 be used to delete the original version of a file uploaded by a sockpuppet/LTA that has since been overwritten by another user? EthanL13^{[please ping me]} 19:18, 25 May 2026 (UTC)

@EthanL13: What exactly is the goal here? Complete suppression of the existence of the original upload, hiding the user name of the uploader, hiding the content? - Jmabel ! talk 15:36, 27 May 2026 (UTC)

@Jmabel It would be in the case where there's nothing inherently wrong with the file uploaded, so indeed just hiding the name. EthanL13^{[please ping me]} 15:57, 27 May 2026 (UTC)

Yeah, I think that is the one thing we can't hide with just a revdel, so we would need to delete (and, yes, COM:G5 would be the correct criterion), then undelete everything but that version (and possibly the original wikitext of the upload, though I think there we can hide the uploader name without suppressing entirely). But it seems like a lot of work for some admin to have to go through to try to hide something relatively harmless. Is this really needed on a frequent basis? - Jmabel ! talk 16:03, 27 May 2026 (UTC)

@Jmabel Depends on what you mean. At the moment, not particularly, with only a few files in mind. I also don't intend on going on big upload sprees just for the sake of removing the name, it would only be for cases where there have been necessary overwrites, and where it would be nice to not be giving credit to those who have been purposely breaking the rules here. EthanL13^{[please ping me]} 20:06, 1 June 2026 (UTC)

May 26

Invitation: Discussion on the proposed direction for the Wishlist

You are invited to participate in a discussion about a proposal on the future of the Wishlist from the community. This is in relation to the disbandment of CommTech, related layoffs, and the subsequent discussion. Femke (talk) 05:59, 26 May 2026 (UTC)

@Femke This topic already reached the media: heise.de, [https://cybernews.com/news/wikipedia-editors-threaten-strike-action/

cybernews.com] , theregister.com PantheraLeo1359531 😺 (talk) 17:07, 1 June 2026 (UTC)

The most accurate story might be at Verge, as they've spoken to quite a few of us. Femke (talk) 20:44, 1 June 2026 (UTC)

Mass renaming PDF files

Hi, Any idea how to rename the thousands of PDF files uploaded by Fae without any proper name or category?

• Getty Research Institute
• Medical Heritage Library
• Books from the Biodiversity Heritage Library

— Preceding unsigned comment added by Yann (talk • contribs) 11:22, 26 May 2026 (UTC)

@Yann: could you state a little more broadly what you want to do (in particular, the intended pattern of renaming)? - Jmabel ! talk 15:40, 27 May 2026 (UTC)

Also: Special:Search can work with VFC, but I believe Special:MediaSearch cannot, so the former may be more useful as a first step here. - Jmabel ! talk 15:43, 27 May 2026 (UTC)

@Jmabel: I have renamed manually some files, but there are too many to rename all of them in this way. And the information provided in metadata is scarce. So I don't have a real meaningful answer. Yann (talk) 15:46, 27 May 2026 (UTC)

It would seem that if there is pattern, we could get them into a category and then use MassRename on that category. But without a pattern, this is inherently one-by-one. - Jmabel ! talk 16:04, 27 May 2026 (UTC)

With Medical Heritage Library, my suggestion for the algorithm would be: For all files with names like File:Medical Heritage Library (IA...: Search for the {{Book template, then search the parameter |title = . That parameter needs to be abridged at whatever comes first: a dot (end of sentence), a colon, semicolon or paranthesis (interruption in the title) or a word-limit (my suggestion would be ten words, i.e. nine spaces). That abridged title is then to be placed as the new filename, followed by the accession number (IA) of the library, which is already included in the current filename.

For the following titles, I give the proposed titles as quotes where my proposed algorithm would cut them... and the non-abridged title in italics, just to show what would get lost.

• #1: Reasons against the inoculation of the small-pox. (IA b30383699) In a letter to Dr. Jurin. Being a full answer to every thing which etc
• #2: The family physitian, or, A collection of choice, approv'd and (IA b30323058) experienc'd remedies, for the cure of almost all diseases etc
• #3: Polygamia triumphatrix, id est discursus politicus de polygamia auctore Theophilo (IA b30332084) Aletheo [pseud.] [i.e. J. Lyser], cum notis Athanasii Vincentii etc
• #4: Specvlvm mundi. (IA b30331729) Or a glasse representing the face of the world; shewing both that etc
• #5: The wisdom of God manifested in the works of the (IA b30322091) creation: In two parts. viz. the heavenly etc
• #6: A form of common prayer with thanksgiving to God, for (IA b30340895) asswaging the late contagion and pestilence, to be used on etc
• #7: The Lancashire Levite rebuk'd (IA b30341863) : or, a vindication of the dissenters from popery, superstition etc
• #8: Lithotheorikos, sive, nihil, aliquid, omnia, antiquorum sapientum vivis coloribus depicta, (IA b30338827) philosophico-theologicè, in gratiam eorum qui artem auriferam etc
• #9: Natural history of nutrition, life, and voluntary motion (IA b30343781) : containing all the new discoveries of anatomist's, and most etc
• #10: A perfect cure for the King's Evil, (IA b30348584) (whether hereditary or accidental,) by effectual alcalious medicines.

That is admittedly not the most elegant solution, but it would be a vast improvement for all titles from the Medical Heritage library that are currently just displayed as Medical Heritage Library (IA b99999999) --Enyavar (talk) 15:06, 3 June 2026 (UTC)

@Enyavar: I would agree that would be an acceptable set of renamings; however, because it requires reading the page content and then using that to rename the file, MassRename won't help. This would have to be a bot task request. - Jmabel ! talk 19:21, 3 June 2026 (UTC)

Is that a problem? The initial request was "Any idea how". --Enyavar (talk) 12:52, 4 June 2026 (UTC)

@Enyavar: a bot task request would be perfectly appropriate. I'm just saying that unless you are a bot operator, you are probably not going to have an existing bot-like tool that lets you do this yourself. - Jmabel ! talk 18:00, 4 June 2026 (UTC)

"renaming" produces very little benefit. why bother, when the title is in the description? RoyZuo (talk) 10:54, 5 June 2026 (UTC)

Semantic markup

I had a conversation with Andy Dingley, but they said it was "a waste of [their] time", so I'm asking here:

Could someone confirm that semantic markup is not used on Commons? E.g. ‎<em>...‎</em> to indicate emphasis instead of plain italics.

I made an edit that Andy reverted. They said:

... in almost every case when there is an adequate wikitext syntax to use, then that is used rather than HTML. ... This is our practice here on Commons (and Wikimedia projects).

However, regarding "Wikimedia projects", I know for a fact that ‎<em> is preferred on Wikipedia for one; see en:MOS:ITALICS:

The most accessible way to indicate emphasis is with the HTML <em>...</em> element or by enclosing the emphasized text within an {{em|...}} template. Italics markup (''...'', or <i>...</i>) is often used in practice for emphasis, but this use is not semantically correct markup, so emphasis markup is preferred.

On Commons, I did a bit of research for any pages talking about "semantic markup", but I couldn't find any among a bunch of irrelevant pages in the search results. I don't know what would be the equivalent of Wikipedia's manual of style.

• I did notice that {{Em}} exists on Commons, but its documentation was copied from Wikipedia and it doesn't seem to have been tailored for Commons.
• And since my edit was on a "source translation page", I checked the relevant page on MW, mw:Help:Extension:Translate/Page translation administration, but it doesn't seem to have anything relevant, e.g. no mention of "italics" or ''.

— W.andrea (talk) 16:08, 26 May 2026 (UTC)

In practical terms there's no distinction between ''italics'' and <em>. Both get rendered as italic text, and there's no compelling reason to use one over the other. (In particular, there's no real difference in accessibility; screenreaders and other tools are familiar with both tags.) Omphalographer (talk) 20:02, 26 May 2026 (UTC)

But don't forgot screenreaders which may interprete italics (only visual) and emphasize differently --PantheraLeo1359531 😺 (talk) 08:04, 6 June 2026 (UTC)

I'm basically with Andy here. Unless a site is systematic about semantic markup, there is not much use to using it here and there. - Jmabel ! talk 15:45, 27 May 2026 (UTC)

OK, I'm not hearing any reason to not use it. Maybe you would say it's not worth the effort? — W.andrea (talk) 13:12, 1 June 2026 (UTC)

The reason generally not to use it is just to have consistent wikitext markup rather than everyone doing it differently. - Jmabel ! talk 23:31, 1 June 2026 (UTC)

I also use italics for emphasis on discussion pages. You are free to emphasize using emtags.

We all may run into standardization trouble if we mix our methods outside of talk pages. The preference of most editors involves four keystrokes on the same key; the emtag-preference involves twelve keystrokes on five different keys. --Enyavar (talk) 13:03, 4 June 2026 (UTC)

May 27

Why are they not automobile parks

Category:Car parks?? RoyZuo (talk) 18:47, 27 May 2026 (UTC)

Because it's one of many possible and valid names.

OTOH, 'automobile parks' would be an invention that no-one uses. In the country where 'automobile' is in use, they're called 'parking lots' instead. Andy Dingley (talk) 19:10, 27 May 2026 (UTC)

@Andy Dingley: In the US, we also have multilevel structures called 'parking garages', generally in areas with high costs for real estate like Manhattan in New York City and international airports, and charging parking fees by the hour or day. I have heard 'park' used by immigrants as a noun instead of 'parking space' for a single available parking space on a street (sometimes a place to put a vehicle that may not be on the other side of the street for much of that day due to street cleaning regulations that mimic New York City's 'alternate side of the street parking').   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 20:42, 27 May 2026 (UTC)

https://commons.wikimedia.org/wiki/Special:AllPages?from=Automobile&namespace=14 there're many more "invention that no-one uses" including but not limited to Category:Automobile sharing Category:Automobile stickers... RoyZuo (talk) 12:39, 2 June 2026 (UTC)

@RoyZuo: Do you want to go further back to "horseless carriages"?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:43, 2 June 2026 (UTC)

May 31

Warning template on files with overly loud or distorted audio

Is this something we want on Commons? Trade (talk) 02:43, 31 May 2026 (UTC)

There shouldn't be overly loud audio; in theory, audio files should be run at 75% to 80% of maximum volume, to provide them headspace for the loud parts. Overamplified files should cap out at a volume doesn't really justify a warning. There should possibly be an improve template for distorted audio, but there's often nothing anyone can really do.--Prosfilaes (talk) 04:29, 31 May 2026 (UTC)

Do you not think audio and video files should be preserved in their original state as much as possible? Why is it unacceptable to pass off AI upscaled images as the original but not to manipulate the volume level of files? Trade (talk) 17:54, 31 May 2026 (UTC)

@Trade: Because it is much more comparable to (perfectly acceptable) dodging/burning/equalization etc. than it is to the essentially unpredictable changes made by AI. - Jmabel ! talk 03:39, 1 June 2026 (UTC)

Absolute volume of a recording (as opposed to relative volume of the pieces of a recording) has little relation to the original volume of the sound or the volume it will be heard by the user. Works that are individually notable and have been digitally mastered--i.e. basically professional musical pieces--may have notable volumes that shouldn't be tampered with. (Which I'd point out is not something the studios would necessarily follow when doing a rerelease.) I wouldn't even compare it to dodging or burning; amplifying audio is virtually reversible--depending on how it's implemented, sometimes completely reversible.

And the point was the too loud audio shouldn't be a problem. The audio in an audio file should be cranked up, and in a lot of cases, and I believe that's automatically done by many sources like YouTube. I respect audiophiles and wanting to avoid dynamic compression in their classical recordings, but that is a rarity, and even then the top volume of the file should be just below the maximum volume of the file format. If you have your volume set correctly, and the audio of what you're listening to before is set correctly, your next audio file should be able to be significantly louder than the last.--Prosfilaes (talk) 05:24, 1 June 2026 (UTC)

So we are talking only about a uniform change on the entire file rather than passages having issues? Yes, then it is even simpler, more like simply lightening or darkening a whole photo. - Jmabel ! talk 23:34, 1 June 2026 (UTC)

No, the thread here was referring to both instances Trade (talk) 19:12, 3 June 2026 (UTC)

In principle that seems like a reasonable thing to do - do you have any examples which are in scope? Omphalographer (talk) 06:16, 31 May 2026 (UTC)

Request support for Indonesian traditional script sub-codes (id-Arab, jv-Java, etc.) for video subtitles

Hello, I am planning to add video subtitles (SRT) in Wikimedia Commons using Indonesian regional and traditional scripts.

However, the TimedText namespace currently rejects valid BCP 47 script sub-tags like `id-Arab` (Indonesian in Jawi script) or `jv-Java` (Javanese in Hanacaraka). The interface in Phabricator is too complicated for me to navigate.

Could any technical contributor or admin help me open a Phabricator task (tagged under #MediaWiki-Internationalization and #MediaWiki-extensions-TimedMediaHandler) to enable these traditional script codes in MediaWiki core? Thank you very much! --Sdsecret (talk) 05:53, 31 May 2026 (UTC)

Here is the full list of standard BCP 47 language-script codes for Indonesian regional/traditional scripts that need to be enabled for video subtitles (TimedText):

1. Indonesian / Malay in Jawi (Arabic) script: `id-Arab` / `ms-Arab`

2. Javanese in Hanacaraka / Javanese script: `jv-Java`

3. Javanese in Pegon (Arabic) script: `jv-Arab`

4. Sundanese in Sundanese script: `su-Sund`

5. Sundanese in Pegon (Arabic) script: `su-Arab`

6. Buginese / Makassarese in Lontara script: `bug-Bugi` / `mak-Bugi`

7. Balinese in Balinese script: `ban-Bali`

8. Batak in Batak script: `btk-Batk`

9. Sasak in Carakan/Balinese script: `sas-Bali`

10. Rejang in Kaganga/Rejang script: `rej-Rjng`

Enabling these script sub-tags will officially allow us to preserve and document these indigenous and historical scripts in video captions across Wikimedia Commons. Thank you! --Sdsecret (talk) 05:55, 31 May 2026 (UTC)

The subtitle system only supports the languages that MediaWiki supports. So you would have to add the subtags to MediaWiki (and this should also allow them to be used in Wikidata values for instance). In general, this is not an easy task, although I believe it has become slightly easier recently. —TheDJ (talk • contribs) 10:31, 3 June 2026 (UTC)

How to do it? Sdsecret (talk) 12:58, 4 June 2026 (UTC)

Thanks for the explanation, TheDJ. Since navigating Phabricator and submitting a core patch is way beyond my technical skills, could you or any admin here help me open the Phabricator task for this? It would be deeply appreciated if someone could bridge this request to the development team so these 10 Indonesian traditional script sub-tags can be supported. Thank you! Sdsecret (talk) 13:04, 4 June 2026 (UTC)

File:Bikini woman on beach.jpg

Is the new version really better? At least not on my screen. Isderion (talk) 18:49, 31 May 2026 (UTC)

No, absolutely not. Better as a version with a new name. Do not overwrite. Wouter (talk) 19:04, 31 May 2026 (UTC)

No. It's washed out. ―Justin (koavf)❤T☮C☺M☯ 19:11, 31 May 2026 (UTC)

@Solomon203, please stop doing these "Light fixed" overwrites. I have to revert and/or fix all those files properly now. - Alexis Jazz ^{ping plz} 18:03, 1 June 2026 (UTC)

June 01

1 petabyte of freely usable media files

Commons is close to 1 petabyte. Currently, the Special:MediaStatistics reads: "Total file size for all 142,471,025 files: 1,085,665,611,155,968 bytes (987.41 TB)". Congrats. emijrp (talk) 16:52, 1 June 2026 (UTC)

• Let me add a hint: You talk about pebibytes. A pebibyte is equal to 2⁴⁰ bytes or approx. 1.099 petabytes and a petabyte are 1,000 terabytes :) --PantheraLeo1359531 😺 (talk) 17:04, 1 June 2026 (UTC)

  Not really. I meant 1024 TB = 1 PB, thats why I said "is close to". We are not there yet, but will soon. Regards. emijrp (talk) 17:10, 1 June 2026 (UTC)

  That would be 1024 TiB = 1 PiB ;). Prefixes like k, M, G, T and P are SI prefixes with base 1000. The IEC prefixes like ki, Mi, Gi, Ti and Pi are IEC prefixes with base 1024. We cannot confuse the prefixes where a terabyte would be 1024 gigabytes but a teragram would be 1000 gigagram. 🙃 --PantheraLeo1359531 😺 (talk) 18:41, 1 June 2026 (UTC)

  Apparently Special:MediaStatistics has no problem with it, it uses TB, though you can report a bug if you want. emijrp (talk) 18:57, 1 June 2026 (UTC)

It would be great if Arch Mission Foundation could use several of these disks to store that petabyte in this facility, as they did with (the then current content of) English Wikipedia in 2024. Not because I fear a big apocalyptic event happening anytime soon, but as a last safeguard against other things that can (and, sadly, often do) happen. MGeog2022 (talk) 12:05, 3 June 2026 (UTC)

The demands for digital storage will increase fast. So this would be a good thing --PantheraLeo1359531 😺 (talk) 16:04, 4 June 2026 (UTC)

Wiki Indaba 2026 – Scholarships & Program Call now open | Abidjan, November 13–15

Dear Wikimedians,

The call for applications for scholarships and the program of Wiki Indaba 2026 is now open.

This year, the conference will be held in Abidjan, Côte d’Ivoire, from November 13 to 15, 2026, under the theme “Africa’s Future: Knowledge Equity and Innovation”.

Wiki Indaba is the premier gathering of Wikimedians from the African continent and the diaspora. If you have a project, an experience, or an idea to share with the community, now is the time to submit your proposal.

Two applications are available: • Scholarship application → bit.ly/INDABA26_SCHOLARSHIP • Program proposal → bit.ly/INDABA26_PROGRAM

⏳ Deadline: June 30, 2026 at 11:59 PM GMT (for both)

We look forward to welcoming you to Abidjan! Abiba Pauline (talk) 21:36, 1 June 2026 (UTC)

June 02

Less than 4000 media needing categories as of 2021

By now, less than 4000 media needing categories as of 2021, but we got stuck at the letter N and still have to categorize some difficult-to-categorise files in foreign languages. Do you want to contribute, to categorize the reminder, please? NearEMPTiness (talk) 05:11, 2 June 2026 (UTC)

The categorisation of the all media needing categories as of 2021 is nearing completion due to the work of @User:Stefan Kühn, @User:Prototyperspective, @User:Gbawden, @User:ProtoplasmaKid, @User:Krok6kola, @User:Jochen Burghardt and many other non-disclosed contributors. Now, we need to team-up once again, to categorize the media described in foreign languages, please. Should we then tackle all media needing categories as of 2022 or take a break? NearEMPTiness (talk) 04:11, 5 June 2026 (UTC)

I think we’re on the right track. If you look at the statistics, we’ve tagged about 120,000 files in four months. So we’ve reduced the large pile of uncategorized files by an average of about 7,000 files per week. If we all keep this up and don’t lose sight of the goal, we should have only a few files left by the summer of 2027. @NearEMPTiness: Thanks for always being so active in promoting this work. --sk (talk) 07:56, 5 June 2026 (UTC)

@NearEMPTiness (ping) --PantheraLeo1359531 😺 (talk) 15:11, 5 June 2026 (UTC)

We slowly reached the letter S. More help is required, please, to keep the ball rolling. NearEMPTiness (talk) 00:51, 6 June 2026 (UTC)

Clarifying the closing time zone for Photo Challenge submissions and voting

I would like to raise a question regarding the closing time zone used for the Photo Challenge.

Recently, while handling the vote counting process, I noticed an inconsistency between the actual submission deadline and the wording currently used in the challenge pages. In practice, the submission period appears to close at 00:00 AoE on the 1st day of each month. However, the written description in recent months has stated the deadline as 00:00 UTC on the 1st day of each month.

There was also previous advice from experienced Wikimedians suggesting that the voting period should preferably end using AoE time, as this gives contributors around the world a more inclusive and predictable deadline. Nevertheless, the wording used in recent months has mainly referred to UTC.

This creates a potential ambiguity: contributors may understand the deadline differently depending on whether they rely on the actual timing, the page wording, or past practice.

I would therefore like to ask the community to clarify which time zone should be used as the standard closing time for the Photo Challenge:

• Option A: Use 00:00 AoE on the 1st day of each month as the standard closing time.
• Option B: Use 00:00 UTC on the 1st day of each month as the standard closing time.

My own view is that whichever option is chosen, the most important point is that the submission and voting pages should use consistent wording, and that the actual closing mechanism should match the stated deadline. This would help avoid confusion for participants and make future vote counting easier to manage.

Comments and suggestions are welcome, especially from users who have previously helped maintain or close the Photo Challenge pages. This is Taiwania Justo speaking (Reception Room) 13:29, 2 June 2026 (UTC)

how about for simplicity sake just set the deadline to UTC 00:00 2nd of each month? so every contest is always open exactly from 00:00 1st day of current month to 00:00 2nd day of next month UTC? RoyZuo (talk) 15:04, 3 June 2026 (UTC)

Thank you, I think this is a reasonable simplification, and it would certainly be easier to describe and implement than using AoE explicitly.

However, I think the effect is not exactly the same as AoE. Setting the deadline to 00:00 UTC on the 2nd would give some regions additional time beyond the end of the 1st in their local time zone, while AoE is specifically intended to close the contest only after the last time zone has passed the deadline.

Therefore, I would still slightly prefer using AoE if the goal is to handle global time zones fairly. That said, if the community prefers a simpler fixed UTC-based rule, then 00:00 UTC on the 2nd could be a workable compromise. The most important point is that the wording and the actual closing mechanism should be consistent. This is Taiwania Justo speaking (Reception Room) 04:08, 5 June 2026 (UTC)

everything utc would be actually fairer since everyone has the exact same period of time (1 month + 1 day) to submit. RoyZuo (talk) 08:11, 5 June 2026 (UTC)

 Support I don't know as I have an especially strong opinion as long as it's clear, but UTC is the de facto Internet Time Zone (and is generally when things on the front page of Wikimedia sites update), and being open from 0:00 UTC on the 1st day to 0:00 UTC on the 2nd day of the following month is unambiguous and easy to understand. — PeterCooperJr (talk) 20:10, 5 June 2026 (UTC)

@Jarekt: Since you have been involved in maintaining the Photo Challenge, I would appreciate your opinion on this issue, especially on the proposed UTC-based compromise. This is Taiwania Justo speaking (Reception Room) 05:59, 6 June 2026 (UTC)

User:Taiwania Justo, I do not have much of an opinion, I only know that original approach of advertising and enforcing 00:00 UTC resulted with a lot of unhappiness from people (mostly in the US) who think that deadline is at midnight but forget that it is midnight in London and they missed the deadline. I was rejecting large number of entries from last minute submitters and they were not happy. Quietly moving the real deadline by 12 hours, removed most late entries. So in Template:Photo challenge rules I would replace UTC with AoE. --Jarekt (talk) 14:47, 6 June 2026 (UTC)

June 06

Can {{NoFoP-non-buildings-category}} be made?

In Wikimedia Commons, indication of FoP status templates are exist for buildings and public arts categories.

• {{FoP-category}}: For categories of buildings and public arts from a public space in a country that provides Wikimedia Commons-acceptable freedom of panorama
• {{FoP-buildings-category}}: For categories of buildings from a public space in a country that provides Wikimedia Commons-acceptable freedom of panorama for for architectural works only
• {{NoFoP-category}}: For categories of buildings and public arts from a public space in a country that does not provide Wikimedia Commons-acceptable freedom of panorama

After looking at these three templates, I suggest a template, {{NoFoP-non-buildings-category}}.

This is for categories of public arts from a public space in a country that does not provide Wikimedia Commons-acceptable freedom of panorama except for architectural work. (For example, Japan, United States, Finland, etc.)

And, this is intended to integrate {{NoFoP-Japan}}, {{NoFoP-US}}, {{NoFoP-Denmark}}, {{NoFoP-Finland}}, etc.

However, these countries have different criteria for distinguishing between works of arts and buildings.

For example, in Japan, if the exterior of a building, such as the Tower of the Sun, is treated as a work of art, it is treated as such. On the other hand, in the United States, works of art that are included as part of a building and treated as components of the building (e.g., if a column is shaped like a statue) are allowed on Wikimedia Commons.

How about {{NoFoP-non-buildings-category}}? --Ox1997cow (talk) 13:54, 6 June 2026 (UTC)

 Support but rename to something more professional. Suggested {{NoFoP-public art-category}}. Essentially, in all countries that only grant Commons-suitable FoP for images of architecture, almost all kinds of public art are not freely usable in photos, be it sculptures, murals, frescoes, paintings, and graffiti. My suggested wording:

This is a category of a copyrighted artistic work from a public space in a country that only provides Wikimedia Commons-acceptable freedom of panorama to images of architecture and not works of art in public spaces. Please do not upload more photographs or videos of such works, unless their presence is incidental or trivial to the overall image. If the work enters the public domain, please remove this template.

This should also mean redirecting all redundant template headers to this, such as {{NoFoP-US}} and {{NoFoP-Japan}}, and {{NoFoP-Denmark}}.

There is no need to enumerate the names of the countries (I think it's eight) with such FoP rules: Denmark, Finland, Japan, Malawi, Norway, Russia, Taiwan, and the United States. JWilz12345 (Talk|Contributions) 01:27, 7 June 2026 (UTC)

Then, how about {{FoP-buildings-category}} be renamed {{FoP-architecture-category}}? This will resolve the confusion with {{FOP-buildings-category warning}}. Ox1997cow (talk) 03:41, 7 June 2026 (UTC)

No need to rename that. "If it ain't broke, don't fix it," as a popular saying goes. There is no confusion. FoP-buildings-category suits the categories of modern buildings from those eight countries, while the template with warning suits the general categories of countries with no complete FoP (e.g. Azerbaijan and Ukraine, like "Buildings in Baku" or "Churches in Kyiv"). There are no issues in usage of these two as far as I know. JWilz12345 (Talk|Contributions) 04:23, 7 June 2026 (UTC)

Since the names of the templates are similar({{FoP-buildings-category}} and {{FOP-buildings-category warning}}), I thought about changing the name. Anyway, I will make {{NoFoP-public art-category}}. Ox1997cow (talk) 05:02, 7 June 2026 (UTC)

Key for categories of Stolpersteine in Milan, Venice and probably in other cities too

Is it really useful to sort the Stolpersteine by the victim's last name? Because in my opionion it's a mess to leave some stumbling blocks sorted by the victim's last name while others (for example, photos with multiple Stolpersteine) aren't. Andrek02 (talk) 15:21, 6 June 2026 (UTC)

If it can be done consistently, it is presumably useful to bring multiple images of the same stone near each other, and also stones for multiple members of the same family. - Jmabel ! talk 22:28, 6 June 2026 (UTC)

Accidentally overwrote a crop

At File:Lorenzo and Henrietta Music.jpg, I was trying to crop the image and accidentally overwrote instead of uploading the cropped version separately. Can someone please fix this? TenPoundHammer (talk) 15:49, 6 June 2026 (UTC)

@TenPoundHammer: That's not difficult. Simply revert to the starting point (I did this already) and redo the crop. Please mind using the CropTool's Lossless mode to avoid a en:generation loss. Regards, Grand-Duc (talk) 16:23, 6 June 2026 (UTC)

Court Order Concerning Commons Image Related to the 2026 Onikişubat School Shooting

Dear Community Members,

We write to you on behalf of the Legal Department of the Wikimedia Foundation regarding certain developments in Turkey relating to an image currently hosted on Wikimedia Commons concerning the 2026 Onikişubat school shooting.

On April 29, 2026, the Wikimedia Foundation was informed of a takedown order by the Muğla 2nd Criminal Judgeship of Peace, via the Turkish Information and Communication Technologies Authority. The Foundation was directed to take down an image titled "İsa Aras Mersinli, perpetrator of the 2026 Onikişubat school shooting", from Wikimedia Commons. The image is a blurred photograph, sourced from X/Twitter, which - according to its uploader - appears to show İsa Aras Mersinli, the perpetrator of a school shooting that occurred in the Onikişubat district of Kahramanmaraş Province on April 15, 2026. We understand that the image was nominated for deletion on April 15, 2026, and on May 8, 2026, the discussion was closed with a decision to retain the image. The user who closed that discussion concluded  that the image was educationally valuable and did not violate any of the community's applicable policies, including the COM:DIGNITY and the Identification guidelines.

The Foundation took note of the deletion discussion, and we also reached out to a member of the Volunteer Response Team for input. On May 12, 2026, the Foundation filed an appeal before the Higher Court Muğla 1st Criminal Judgeship of Peace. That appeal was subsequently rejected.

As we explore our limited legal options at this stage, we are notifying the community of these developments for two reasons:

• First, to keep you informed: we want to ensure that the community is aware of this development, and what has been done so far by the Foundation.
• Second, to prompt further discussions: we know that the deletion discussion received relatively limited participation, divided opinions, and covered issues not related to the Order (such as the intellectual property rights of CCTV owners). Other community members may have been unaware, and now may feel motivated to have their say. Whether the deletion discussion is reopened or not, your views on the importance of this particular file to the projects can inform our own strategy. Note in particular that other media hosted on Commons is not subject to this Order, and Wikipedia was already preferring to use other photographs. You should also consider the possible consequences of noncompliance with such an order; for now, we will not publicly speculate, but we do want you to understand that what is said and done here could have consequences beyond this particular image.

While we appreciate the reasoning reflected in the late April/early May's deletion discussion, there is also some local context and sensitivities surrounding the image that are worth noting. The investigation into the incident remains ongoing. There are reasons to believe that it was a copycat crime inspired by past shootings. Significant amounts of disinformation, shooter-glorification and calls for further school attacks apparently circulated online. Under Turkish law (including Article 24 of the Turkish Civil Code), the display of graphic or traumatic images may raise concerns relating to personal rights, privacy, and dignity, depending on the circumstances.

In that context, the Radio and Television Supreme Council/RTÜK has issued a public statement concerning content related to the Onikişubat school shooting. In that statement, RTÜK advised that traumatic footage and content violating the privacy of victims, students, or their families should not be broadcast. RTÜK further emphasized the importance of relying on official statements to avoid misinformation and urged media outlets and publications to remain mindful of public sensitivities and the psychological well-being of children.

This Village Pump post is not an instruction or direction for any specific editorial action or outcome. The Foundation fully respects the independence of the Wikimedia community in editorial content-governance matters.

That said, the Order is addressed to Wikimedia, so the Foundation must make its own assessment of its legal obligations, litigation risk, and the broader interests of the Wikimedia projects and the community. Community decisions under the community's own content policies are an essential part of how the projects are governed, and help inform the Foundation's legal strategy. However, these determinations, by themselves, are not binding on the Foundation's assessment of the action(s) it may need to take in response to a court order.

Accordingly, depending on the legal options available and the Foundation's assessment of the risks involved, the Foundation may take appropriate action under the Terms of Use, including an Office Action, where necessary to safeguard the projects, the Foundation, and the Wikimedia community more broadly.

We believe that constructive engagement with the community will help reach a resolution that appropriately considers the educational value of the image as provided under, community governance principles, local legal risks, and the long-term interests of the Wikimedia projects. For reference, please also take a look at the Legal Department's earlier note titled "Educational use rationales for controversial content" (here).

Thanks, BChoo (WMF) (talk) 23:48, 6 June 2026 (UTC)

On behalf of the Wikimedia Foundation's Legal Department