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)

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)

Opinions on preserving orthophotos on Commons

An editor has requested comment from other editors for this discussion. If you have an opinion regarding this issue, feel free to comment below.

Jump to English

--PantheraLeo1359531 😺 (talk) 11:50, 13 June 2026 (UTC)

Addendum: I recently get notifications that orthophotos are used and cropped for Wiki projects, so there is resonance in usage --PantheraLeo1359531 😺 (talk) 11:50, 13 June 2026 (UTC)

I have no doubt that they are of value; the question should be phrased as whether they are of enough value to merit the storage costs and other overhead. That cannot be answered intelligently without a good estimate of the costs and overhead involved. - Jmabel ! talk 22:20, 14 June 2026 (UTC)

157TB is actually ridiculously large, so this is worth discussing. However it feels like a WMF Ops view would be sensible. If there are server systems that 'park' very large collections differently when not actively in use, it would be illuminating in assessing the types of 'cost'. This discussion seems premature while the phab discussion is on-going as the options for compression might make a game changing difference. Past experience of the TIFF wrapper indicates that it is often a terrible way to store lossless images due to huge file sizes. There are alternative formats but as the storage challenge is important to get right, it would be super if some practical test examplars could inform discussion before mass changes are agreed. Fæ (talk) 02:59, 15 June 2026 (UTC)

BTW on "large", if using HDD arrays, storage for over 250 TB would be around $500 a year in capital and running cost, based on online estimates. Even if I am misunderstanding and the reality is ten times that, it's not a lot compared to employing one full time Ops person. Fæ (talk) 03:18, 15 June 2026 (UTC)

The problem with TIFF is that lossless files in TIFF used LZW when that patent business came down, and combined with the massive options TIFF offers, many groups used TIFF with no compression for archiving. TIFF files can be seamlessly recompressed to LZW or Deflate/Zip compression, and doing so with File:Nighthawks_by_Edward_Hopper.png (an 87 MB file) produces 84MB or 80MB files. (LZW is more standard, Deflate is a bit higher compression but only supported in 21st century TIFF products.) If you remove the interlacing from the PNG file, it drops to 73MB. Either way, the largest is 20% larger than the smallest, and both of those are PNG versions.--Prosfilaes (talk) 04:14, 15 June 2026 (UTC)

Here we are talking about geodata raster tiles. These tiff files are often very good to compress. The problem is that the compression can not be done directly to the file as this causes problems with GIS software. GPSLeo (talk) 06:07, 15 June 2026 (UTC)

We had a test lab project called Commons Archive that had a similar function, but it was not maintained and eventually deleted. If someone were willing to maintain Commons Archive again, then I think it would be a valuable addition. ―Justin (koavf)❤T☮C☺M☯ 06:10, 15 June 2026 (UTC)

I personally think that this is not what Commons is for. Sure if there is a specific need to upload a file in a certain context. but we can't host all of this. Don't forget that it is not just the raw data. each images is a page, and revisions, and links to categories (which are already a problem). A dedicated archive is a much better fit for this than a general purpose media hosting service inside of a Wiki. So if people want to do this (which I'm not against) then make a website for it that specializes (technology wise) in being an archive for this. —TheDJ (talk • contribs) 09:10, 15 June 2026 (UTC)

I wasn't aware these existed, but this could be incredibly useful on the projects as tiles for the template:maplink tool. (the currently used tiles are an ancient version of the tiles from OpenStreetmap, With that kind of usage, I think hosting these would be within the Commons remit. Milliped (talk) 09:41, 15 June 2026 (UTC)

I can understand the raised concerns, and it's without a doubt a huge dataset. Of course, the most important aspect is the archiving itself, so the images are preserved. If it is only about the archiving as such, argumenting to keep it on Commons may be challenging and difficult.

However, when considering the diverse use cases across Wikimedia projects, I see substantial value in hosting them here. If we, for example, have coordinates of a Wikidata item and the bounding box of an orthophoto, we could link the image to the respective Wikidata item where the orthophotos contains the motif. Orthophotos are also useful as illustrations for Wikivoyage and of course, Wikipedia. A single image may contain hundreds or even thousands of potentially notable objects.

I think one major disadvantage of a pure archive is its rigidity. Discovering, reusing, and integrating content into Wikimedia projects becomes significantly more difficult or even restricted. Commons, on the other hand, is built around accessibility, reuse, categorization, and interconnection.

As geographic landmarks are distributed across the territory, we have a high information density with useful resolution, even in sparsely or unhabitated areas. And in some cases, orthophotos may be the only imagery we can get for illustration, particularly where ground-level photography is difficult or where drone usage is restricted or prohibited.

I would also emphasize that Commons itself has evolved considerably over time. It started primarily as a repository for relatively simple image files by hobby photographers, but has since expanded to support video, audio, structured data, multilingual media, 3D models, and immersive formats such as spherical panoramas, up to professional photographs and historical GLAM material. Commons increased its diversity of media, where orthophotos are a next (logical) step. In that sense, they do not simply add more files to Commons—they add a new dimension to what Commons can represent and support. It enriches Commons, as it allows a new dimension of media.

Many Wikipedia contributors feel the frustration when they are lacking media. Some areas may not cover an eager Wikipedian, who could drive a longer route and take pictures. As Commons has a narrow scope with only hosting very free usable media, acquiring media is hard. The fact that there is high-quality media outside, useful for the Wiki movement, is a big chance in my eyes. So or so, if the ongoing compression is done, we also have a decrase in disk usage, which is also a positive aspect coming into this discussion. --PantheraLeo1359531 😺 (talk) 19:39, 15 June 2026 (UTC)

I suspect that the biggest hurdle here is that Commons is not well suited to indexing so many basically parallel files. Our approach of having a distinct file page for each file may not work well here; at the very least, some sort of templating is in order. I'm wondering about whether there may be some potential here of placing descriptive metadata in a database (something much more efficient for table-like data than Wikibase) and drawing from that on demand via templating. I'm out the door and don't have time right now to flesh this out, but just wanted to jot this down I'll try to expand on it later if no one beats me to it. - Jmabel ! talk 20:15, 15 June 2026 (UTC)

The concept of a "class" of files with no filepage apart from a single common one, because they are effectively records in a database sounds great. How a possible new namespace (the current 'data' space is near redundant) or closer ties to wikidata could help bypass this traditional system needs some careful thought. A clever solution and I like it; is it "wikimedia.commons", that's the fundamental wiki design discussion that drops out. Fæ (talk) 11:17, 17 June 2026 (UTC)

Generally, I'm open towards hosting orthophotos. We already host batch uploads of ISS flyovers, which are thousands of files, usually unsuitable for encyclopedic usage. And yet, there are the shining 1% examples of these files being useful to illustrate WP, which is why we host them.

Jmabel's idea of templating is worth thinking about. There is also the idea to store the images in a database that enables tiling, mosaicking and pyramidizing... as is generally done with large geographic datasets these days. We should also consider to which extent we want to store orthophoto timelines: Early orthophoto archives already exist for the 1940s; more recently in Germany I know that new sets of Orthofotos (DOP) are produced regularly. Depending on the area, every two years or five years. So our templates should allow skipping towards older/newer photos of the same area, ideally by naming the sets alike. Which needs masterful standardization.

Also, how are we going to deal with cropping? There are some people who will absolutely run the crop tool day and night to crop their favorite features from the DOP imagery: Just check out this example or this one. I'm near-certain that some users will locate and crop DOP images to illustrate for example their WP articles on local churches. That is okay, we want church articles to be illustrated with DOPs - but wouldn't it be better to do so with a WMS framework similar to the existing WikiMap, so that Common's doesn't have to host hundreds of additional cropped files per original DOP? I'm not up to date on the technical possibilities, but dynamic CSS cropping is what I would prefer.

We need to plan ahead, I think. For example with Sanborn maps, there are no functions that enable skipping from a 1888 survey to the following 1908 survey. If a connection can be made between two timeframes, users have to find and connect the files themselves. With maps, georeferencing etc could solve some issues, but the maps are already uploaded without georeferences, which actually applies to most maps. Measures now have to be taken after the fact of twenty years of uploaded material, which hinders standardization. Similarly in the case of #Maps from Our World in Data, Doc James has not for a day stopped uploading maps into a frankly crappy category scheme that was never meant for what it is currently (ab)used for. We even have agreement on how the category scheme/framework needs to look like, but still we only got the promise that proper categorization will be done. Eventually. Hopefully. Once the current plan of 2 million uploaded maps is completed. Maybe by someone else. A bot. Or by myself on my lonely own, for the next twenty years. Who knows.

All I'm saying that we should carefully consider how the new material can be organized, and before it is uploaded. --Enyavar (talk) 14:51, 17 June 2026 (UTC)

 Support This sounds to be a good idea to me --PantheraLeo1359531 😺 (talk) 14:15, 24 June 2026 (UTC)

ultimately, i don't think we should make decisions based on scaling concerns. If the DB schema is running into scaling issues, WMF should invest money into sharding or whatever is needed. Yes resources are finite and resources spent on one thing are resources that cannot be spent on another. However we are no longer in a shoe string budget and having lots of pages is the core functionality of wiki software. This is not an area we should ask the community to make trade offs in. Bawolff (talk) 16:05, 20 June 2026 (UTC)

"This is of interest to science and research and goes far beyond the Commons principle of “educational value”"—I fail to see how anything "of interest to science and research" can be said to go "far beyond the principle of educational value". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 20 June 2026 (UTC)

I think the orthopods should just go to Internet Archive. Take one of procedures of grants, namely adding files if an majority of the files will be linked on a WMF project. Some arguments: First, Commons was started after several Wikipedia versions had the same free files. There is an wikitech mailing list message on this. Archival was not the goal of founding commons. Second, WMF sites like pictures of specific locations, so the orthopod pictures would be edited anyway. Third, creating an free Internet Archive account does unlock some files on their website, whether orthopods are included I do not know. Snævar (talk) 14:11, 23 June 2026 (UTC)

"orthopods" => "orthophotos", I presume. I saw that last as a diff in its own right and did a proper Emily Litella: "What's all this about orthopedic surgeons and the Internet Archive?" - Jmabel ! talk 22:15, 23 June 2026 (UTC)

I think this argumentation lays too much on the mere archival issue. Apart from the problems that IA is (potentially) facing, I would like to remeber on how the files can interact with Wiki projects.

Of course, single croppings can be useful, but they often lose the broader spatial context contained in the full orthophoto. A cropped image may illustrate a single object, whereas the complete orthophoto can document an entire area and the relationships between its features.

The IA primarily covers the preservation as such. But on the other hand, Commons can add metadata like geo-tagging, aerial coverage of areas (and across the timeline) and more. This makes discovery, reusing looking up and maintenance easier. If we just dump altogether in the IA, searching will become harder (especially for not versatile users).

Also, the imagery contains a lot of data. This data can enrich Wikidata. It allows us to verify locations, measure distances and areas, document the development of settlements over time, and provide spatial context for countless geographic objects. Things can be validated AND rechecked. The point is that we do not just archive them; we make them interactive and useful within the Wikimedia ecosystem. That is a significant added value.

In short: The key difference is that on Commons we do not merely preserve the files. We make the files discoverable, reusable, and connected to the wider Wikimedia ecosystem. That additional layer of interaction is a significant advantage over a solely archival solution. The topics hang together. --PantheraLeo1359531 😺 (talk) 14:39, 24 June 2026 (UTC)

These are good points. The tool I proposed here would make adding the metadata more easy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:18, 24 June 2026 (UTC)

Seems fine to me, with the added information. Snævar (talk) 18:49, 24 June 2026 (UTC)

Commons was not explicitly created to permanently preserve files, while Internet Archive was. Then, you see that files in Commons have at least 8 copies in 2 datacenters, with thousands of km between them, that even deleted files aren't physically removed from servers nor backups, and we have deleted files marked as "undelete in 2055" or the like, that WMF has more money than it needs, even if it stored several times the total size it stores, etc. And that, ten years ago, Internet Archive had an infrastructure that had most of its content continuously one step from disaster, and there is no truly reliable information that can make us 100% confident that the current situation is far more better ("a copy in Canada", but some sources say it's a full copy, while others say it's only partial).

So, maybe, decades from now, history will provide an interesting example to learn from it. Those who wanted to preserve everything forever, didn't care about the physical means to achieve that, and a catastrophic loss happened. While Commons, without having long-term preservation explicitly in mind, followed the minimal standard backup practices and kept lots of media files preserved for future generations, even without being its primary intention. That's why I think that long-term thought should be present in Commons: we are almost there, probably, just inertia will preserve all the files currently in Commons for the next century (even most deleted files, while not publicly visible). On the other hand, Internet Archive will need to improve a lot in many ways from its 2016 situation, to be close to achieving the same goal. MGeog2022 (talk) 14:01, 25 June 2026 (UTC)

I think that the diskspace is not a problem for any still images. Ie. global storage market is focusing on storing for example video which will take one magnitude more space than images and this will drive storage capacity up and prices down per TB. So my vote is keep. --Zache (talk) 14:12, 25 June 2026 (UTC)

Photo challenge April 2026 results

{{Commons:Photo challenge/2026 - April - Fair grounds/Winners}}
{{Commons:Photo challenge/2026 - April - Wooden bridges/Winners}}

Congratulations to @IM027, @BogTar201213, @F. Riedelio, @Nocomentapapun, @Jean-Marie Vugnon (2) and @Kmtextor. This is Taiwania Justo speaking (Reception Room) 15:56, 14 June 2026 (UTC)

Once again I have disabled display of the templated images, as the templates cause significant horizontal scrolling.

I thought this had already been resolved. We have ample means of displaying images without horizontal scrolling, not least <gallery>. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 20 June 2026 (UTC)

SDC constraint for flickr

example File:" Fot.Andrew Skowron (47949298598).jpg.

published in (P1433)

The value for published in should not be one of the following: Flickr...

since such sdc has been written to a lot of files, to fix the constraint is either remove the constraint or change this sdc model, i guess. or just pretend we dont see this constraint... RoyZuo (talk) 20:07, 16 June 2026 (UTC)

 Comment, the constraint for Flickr was added by @Trade on 9 June 2026, with the explanation: "larger work that a given work was published in" Social media websites are not works.

I'm not familiar with this Wikidata property, but it sounds like perhaps the property was misapplied for the image. Thanks. Tvpuppy (talk) 20:21, 16 June 2026 (UTC)

The point where we have to argue whether or not Flickr is the same thing as a book or a magazine is the point where any semblance of logic went straight out of the window. Trade (talk) 15:22, 17 June 2026 (UTC)

I don't think anyone is arguing whether or not Flickr is the same thing as a book (obviously not). I think the important thing is to discuss what to do when the property has already been misapplied to many Flickr images already. Thanks. Tvpuppy (talk) 15:38, 17 June 2026 (UTC)

the problem is published in (P1433) is "larger work that a given work was published in, like a journal, a website, a collection, a book or a music album" so why certain websites should not be allowed?

unless there's a general consensus that this constraint is reasonable, it should not be added, especially since a data model has been made to use it for millions of files. RoyZuo (talk) 15:06, 20 June 2026 (UTC)

The "larger work" should be something which is generally considered to be a single collective work. The entirety of all files on Flickr are not such a work. Omphalographer (talk) 17:13, 20 June 2026 (UTC)

Duplicates or overwriting of scans at the Internet Archive.

• File:A dictionary of the English language- in which the words are deduced from their originals, and illustrated in their different significations by examples from the best writers - to which are (IA 0037263X1.nlm.nih.gov).pdf (edit|talk|history|links|watch|logs)
• File:Medical Heritage Library (IA 0037263X1.nlm.nih.gov).pdf (edit|talk|history|links|watch|logs)
• https://archive.org/details/0037263X1.nlm.nih.gov

Can anyone diagnose why these versions exist for the same book and unique IA number? If there's a mass pattern we might need to add cross references. Same resolution scans, but different PDF size. Fæ (talk) 15:13, 17 June 2026 (UTC)

This has not been solved as to the root cause, however on the presumption that something odd has changed on how IA is compressing the pdf versions, there is extra care being taken to avoid duplicate IA IDs. Fæ (talk) 07:22, 20 June 2026 (UTC)

Which Copyleft Licence is Suitable for an SVG?

Some of you might enjoy this blog post by User:Edent:

https://shkspr.mobi/blog/2026/06/which-copyleft-licence-is-suitable-for-an-svg/

Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:29, 20 June 2026 (UTC)

I have read this person's blog before and think it's interesting and instructive. I would disagree that an SVG file is a piece of software, as it's a document, just like any other XML document, which could be XHTML or MathML or an RSS feed, etc. What a particular program chooses to do with that document and how it interprets instructions in it is up to that program. His point about embedded scripts is certainly correct, but the same is true of HTML documents or PDFs: by this definition, what are clearly documents aren't documents or they cease to be documents when including scripts, which is pretty absurd to me. That said, it's an interesting perspective and one I respect; I think it's worth reading and considering for sure. ―Justin (koavf)❤T☮C☺M☯ 13:02, 20 June 2026 (UTC)

"Document" includes types of file with various possible ways to inject behaviours. In terms of expectations for threats, it makes sense to treat them as software. Though the focus was copyright, the way Terence describes SVG as something that creates images rather than being an image is useful framing for other formats, as the same can be said about HTML or wikicode which create text on a page. At this moment as script kiddies can talk to an AI to create exactly the right injected "code" to, say, invisibly change the way their essay might fudge AI detection tools, or an image on Commons might be listed by later search engines, it's a hot issue without easy solutions. Fæ (talk) 13:29, 20 June 2026 (UTC)

All of this is 0s and 1s and so any computer program could take this as instructions to execute some code somehow someday, so you are correct that when it comes to certain kind of threat modeling, documents that can include executable code or scripts are definitely a different thing than documents that can't, but to your point that the original discussion is about copyright and what kind applies, when someone makes an SVG file, that person is making a creative work. Even if it includes animation or dynamic interactive elements, it's still an attempt to make an image, so the kinds of protections that relate to it are/should be (in my non-legal scholar opinion) those of a creative work. It's hard to say where this would end if we treated documents as software: are macros the same thing? What about spreadsheets that have pivot tables? Also, not sure what your HTML comment was about LLMs. ―Justin (koavf)❤T☮C☺M☯ 13:48, 20 June 2026 (UTC)

you could also ask if the colour profiles in jpg files are software Bawolff (talk) 14:20, 20 June 2026 (UTC)

Or, to take it to the point of absurdity: are the LZ codes in a compressed PNG image a 'program'? They are, after all, a sequence of 'instructions' which are 'executed' to reconstruct the image.

Realistically: the GPL should not be applied to images, regardless of the file format. The license presumes that the subject of the license exists as textual "source code" which is compiled into "object code" before being executed on a computer. It is not at all clear how these terms would be applied to an image; even if one creatively interprets those terms (e.g. treating the SVG text as "source code" and a PNG rendering of it as "object code"), it's not at all clear what that means for reuse of the image. Omphalographer (talk) 21:42, 20 June 2026 (UTC)

if the point of the blog post is that software with source code should be GPL not cc-by-sa, then i think svgs should still be cc-by-sa. It is extremely rare that SVGs have a concept of source code separate from object code. GPL in general is kind of unclearly defined when it comes to interpreted languages that are typically sent to the client (e.g. is sending JS to the browser "distributing" the software). Bawolff (talk) 14:14, 20 June 2026 (UTC)

Yes, if you send a copy of the program to the user, it's distributing the software. I don't see what's ambiguous about that.--Prosfilaes (talk) 19:33, 22 June 2026 (UTC)

Template By colour

Hello, could the link to the category in template {{By colour}} be changed from Foo by color to Foo by colour. You end up with red links such as Category:Doors in England by color rather than Category:Doors in England by colour. To get the color variant template {{By color}} is available. Keith D (talk) 19:50, 20 June 2026 (UTC)

There is a problem here, but it would need to be solved by checking for existence of categories, not by fixing UK categories by breaking the analogous categories for the U.S., Canada, Australia, Ireland, France, Russia, etc. - Jmabel ! talk 02:42, 21 June 2026 (UTC)

It is just the link that is incorrect because it pipes "Foo by Colour" to a category "Foo by color". If you want the link to category "Foo by color" then you should be using template {{By color}} not {{By colour}}. Keith D (talk) 19:06, 22 June 2026 (UTC)

The "by colour" template is used on almost a thousand pages (the "by color" template is used on multiple thousands) and not all of them use British English spelling. The template fix is fairly straightforward, but I think the correct template should be applied first. Making the change now would be premature, as it could result in links breaking on potentially hundreds of pages. ReneeWrites (talk) 23:53, 22 June 2026 (UTC)

File renaming involving a change of a biological taxon

Apparently, COM:FR does not deal with cases where a picture of a plant or animal has a name that incorrectly refers to a particular taxon in the biological nomenclature. Of course, by itself, it is desirable to change the incorrect name into the correct one. However, sometimes the picture is already in use on one or more projects as an illustration for the incorrect taxon. Just changing the name of the file on Commons, followed by an bot renaming the file on the projects involved, leads to an awful result. In many cases the project still shows the wrong image, often with the original incorrect description below it. In fact, Commons itself can be among those projects, when the picture is used in the infobox of the incorrect category page or on a page showing a selection of images of the incorrect taxon.

In my view a reasonable solution would be an extension of the guideline COM:FR, requiring that cases where the use of an image to be renamed would become incorrect are solved (by changing or removing it) before the file name is changed. This could be done by anyone who feels competent to do so:

• the user making the request;
• any user who is willing to assist;
• the file renamer.

I have seen examples of all three possibilities and they seem all fine to me. What we should try to avoid are the cases where just a file name is changed, but the incorrect information on projects remains. Unfortunately, I have seen examples of those too. Would the solution I suggest be acceptable? --MarcoSwart (talk) 21:13, 20 June 2026 (UTC)

I'm not sure why this is any different from the situation where any other factual error is corrected in a filename, where the factual error might be relevant to how the file is used. And I don't see why renaming should specifically be the last step in the process of fixing a factual error. - Jmabel ! talk 02:47, 21 June 2026 (UTC)

Criterion 3 on COM:FR mentions that misidentified biological taxa are an acceptable reason to rename files. As for whose responsibility it is to correct misinformation on other projects, that is harder to say, since such a guideline would apply outside of Commons, which is not usually something Commons policies and guidelines address. --ReneeWrites (talk) 23:34, 22 June 2026 (UTC)

Recategorization of Wikipedia's anniversaries

Hi everyone, I was just working on organizing the categories for Wikipedia's 25th anniversary in the Netherlands, and that's when I noticed something. There is a category named Category:Wikipedia Day 2026 (which links to Category:Wikipedia 25) and Category:25th birthday of Wikipedia (which also links to Category:Wikipedia 25). However, this is not the case for almost all other Wikipedia anniversaries. To give an example: we have Category:Wikipedia 5, Category:Wikipedia Day 2006, and Category:5th birthday of Wikipedia. Category:Wikipedia 5 links to Category:Wikipedia Day 2006, but Category:5th birthday of Wikipedia stands on its own and has different content. How does this work exactly? What's the difference between Wikipedia Day followed by a year, a birthday of Wikipedia, and Wikipedia followed by a age? It seems to me that it would be better to put everything into a single category for the overview (with the other two categories linking to it), but what would be the best name for that category?

1. Category:Wikipedia [age]
2. Category:Wikipedia Day [year]
3. Category:[ordinal number of age] birthday of Wikipedia

I would appreciate hearing your opinions. Kind regards, Perquirius (talk) 17:16, 21 June 2026 (UTC)

I think the "Wikipedia Day" formulation is probably easiest to maintain over time, and the least error-prone. My least favorite is Wikipedia [age], where I'd never guess the meaning from the category name. - Jmabel ! talk 22:35, 21 June 2026 (UTC)

Thank you! I will change everything to "Category:Wikipedia Day [year]". Kind regards, Perquirius (talk) 13:43, 26 June 2026 (UTC)

Never mind. It's too much work to do this manually, since I don't know how to do it all at once. Kind regards, Perquirius (talk) 13:46, 26 June 2026 (UTC)

I'll propose this in a CfD. It's not tough to do, but the people who created the affected categories need to be notified and have a chance to object. - Jmabel ! talk 02:51, 27 June 2026 (UTC)

Thank you, Jmabel! Kind regards, Perquirius (talk) 08:29, 27 June 2026 (UTC)

This is really obviously an AI-enhanced image, right?

File:Peter Sotos NYC.jpg I don't think it could be more obvious. Yet at the deletion request (Commons:Deletion requests/File:Peter Sotos NYC.jpg) the uploader denies it. I want to get a second opinion on whether this is an AI image. PARAKANYAA (talk) 12:52, 22 June 2026 (UTC)

I'd say it certainly looks edited, there's a cutout style to it as if the person has been pasted into a different background. Aesthetically it looks sharply upscaled at smaller sizes but blurry at larger ones, so I'd guess there was some AI in the mix.

The uploader says I took this picture myself in 2009 with a camera. I took a photo of that [physical print] picture with an iPad in 2026., so the issue probably lies in that unusual extra step of taking a photo of a photo. Perhaps the iPad camera was trying to enhance what it thought it was looking at (if it had two camera lenses and was trying to blur out "the background" as if it was taking a photo of a person in real life?), or the user pressed a button for "enhance this image" without thinking of that as involving any AI. Belbury (talk) 13:30, 22 June 2026 (UTC)

This image does not appear to have been generated or substantially processed by AI image models. As Belbury mentioned, it may have gone through some processing by the iPad's camera, or during the upscaling process, but there doesn't appear to have been any more extensive modification. A proper scan of the photo (or a photo of it taken with a better camera) would certainly be preferable. Omphalographer (talk) 16:26, 22 June 2026 (UTC)

The face is very clearly AI-enhanced, and as Belbury said it "looks sharply upscaled at smaller sizes but blurry at larger ones, so I'd guess there was some AI in the mix", post processing does not get you whatever that is. PARAKANYAA (talk) 16:48, 22 June 2026 (UTC)

• There are plenty of digital processing artefacts that could explain this without it necessarily being 'AI'. Nor does that even matter: We don't have any blanket ban on AI use, for either generation or for image processing.

If you look at the policies we do have (such as COM:AIIP), what is this in breach of? It's never going to get a 'quality image' award, but does that change anything at a DR? Andy Dingley (talk) 17:20, 22 June 2026 (UTC)

Might be in breach of failing to indicate retouching. - Jmabel ! talk 19:34, 22 June 2026 (UTC)

Jmabel, the lopsided nose (which, based on other photos on the internet, is not what he looks like) may be incompatible with COM:PEOPLE#Defamation? - Alexis Jazz ^{ping plz} 20:02, 22 June 2026 (UTC)

Does not appear to be AI, but obviously tampered with. For one, his nose is lopsided. The background has almost certainly been swapped out, characteristics of a photo taken of a photo do not extend to the background. It looks like a botched photoshop job. - Alexis Jazz ^{ping plz} 19:04, 22 June 2026 (UTC)

FWIW, compare http://thefanzine.com/interview-with-peter-sotos-2/. - Jmabel ! talk 19:34, 22 June 2026 (UTC)

uploading beyoğlu to commons

hello there!

we are planning a project for the upcoming fall to visit, photograph, and upload to commons about istanbul's beyoğlu district and its surroundings, organize existing categories, and promote wikipedia and commons. the details will be finalized over the time. we will be applying for a rapid grant for this project. if anyone has experience in this area and would like to share their insights, they can reach out to me and kızıl. --Zemxer (talk) 19:22, 22 June 2026 (UTC)

Please help collect metadata wrong links

e.g. File:Bintulu Medical Centre.jpg#metadata has a wrong link to w:MI4 instead of w:Xiaomi Mi 4.

please write down any other such problematic links in the table. i will correct all of them together.

note:

1. the correct link does not have to be enwp, but could also be commons category page (e.g. Category:Xiaomi Mi 4), wikidata item (e.g. Xiaomi Mi 4 (Q17413058)), commons category page of the manufacturer company (e.g. Category:Xiaomi smartphones (Xiaomi brand))... whatever you see fit.
2. if it links to special:search page on enwp, in other words it's not created on enwp yet, you can simply create a redirect from the link to the actual article of the phone or the phone series or the phone manufacturer. no need for me to fix it here on commons.

   only links to wrong articles or disambiguation pages need fixing.

RoyZuo (talk) 19:49, 22 June 2026 (UTC)

The Biodiversity Heritage Library might be at risk

Hi! A couple days ago, I find this Guardian article. It contains 64M pages of historical works of species and nature. Unfortunately, due to sparse fundings, it's online access is at risk. As it offers many historical and valuable arts, it is (mainly) public domain and educationally useful. I don't know how much Commons covered it yet, but it may be an important preservation project to transfer files from there. All the best!

Addendum: Commons seems to have about 305k files from there: Biodiversity Heritage Library --PantheraLeo1359531 😺 (talk) 08:09, 23 June 2026 (UTC)

I believe most (all?) of the files in the Biodiversity Heritage Library are hosted on the Internet Archive (along with millions of other, non BHL items), while the BHL interface provides indexing and search functions. So the Internet Archive is the repository/backup, but is itself vulnerable to occasional attacks or outages rendering the BHL non-functional as explained here. Also, importantly, not all content on BHL or Internet Archive is under a free license. --Animalparty (talk) 00:40, 24 June 2026 (UTC)

As the uploader of most of what we host from the BHL, we are significantly constrained by copyright. A search on IA shows that around 14% of the BHL collections can conservatively meet the free license requirement. A 'refresh' is running which adds at least approx 6,000 documents; this could be an underestimate depending on how many additional older (19th C) items have been shared with IA.

A key difference between Commons and IA is that we are not allowed to use JPG2000 format which is how the pages scanned by the BHL are archived as a lossless format. Embedded in the pdfs uploaded are very slightly more compressed JPEG format versions of these scans. This is not noticeable to the eye, but it's a technically uncomfortable point if Commons is supposed to host archive quality versions. Discussions and tests on this are in the VP archive from several years ago. (Note phab:T13871 where Brooke (WMF at the time) stated "If there's a strong interest in JPEG 2000 -- such as an institution desiring to share a large number of original files in this format -- then we could probably have WMF Legal do some more thorough research. But historically there's been little demand so far.")

If someone thinks there's a large amount of BHL content on IA that has been missed which *definitely* meets COM:L, like early U.S. federal works, drop a note about it on my talk page. --Fæ (talk) 01:31, 26 June 2026 (UTC)

Template:NSFW-Art

Sorry if I'm posting it in the wrong place, but I'm not sure what is the purpose of this template created by @Amogus502. I guess it is a sort of preventative measure against unwarranted deletion requests, though I'm not sure how effective it sould be. it can't be a disclaimer since that is already covered by the general disclaimer. It is also worth noting that a similar Template:Pornography was removed by @Jameslwoodward due to being "vague" after a deletion request started by @Dronebogus. Not sure if nominating this like the other template is a good idea, so I'd figure we should discuss the template with the person who created it as well as people who were against a similar template, plus others. Dabmasterars [EN/RU] (talk/uploads) 13:39, 23 June 2026 (UTC)

I agree that {{Pornography}} is rather vague, although it was somewhat different from mine, whose scope is more defined and less broad, as I'm aware that not all drawings of nude people need such templates. I'm also aware that this is problematic, so I'll  Wait for more comments. Amogus502 (talk) 16:11, 23 June 2026 (UTC)

Commons:Village_pump/Proposals#c-Bawolff-20260605203900-Summary_2

a very recently user-made script could blur nsfw files according to users' own preferences.

so users need not worry about files being sent to deletion, because if that script becomes widely adopted, users who dont like certain files can just turn on the blur. RoyZuo (talk) 18:04, 23 June 2026 (UTC)

Great! Then could we deprecate the template and tagging it for speedy deletion (T2)? Amogus502 (talk) 18:35, 23 June 2026 (UTC)

Delete that tenplate, it’s not useful and redundant to the general disclaimer. Dronebogus (talk) 00:18, 24 June 2026 (UTC)

Don't we have Wikimedia Commons content descriptor (P14416) for this, now? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:41, 24 June 2026 (UTC)

RFC about AI-generated content in Wikimedia Commons

You are invited to participate in a request for comment on Wikimedia Commons about a policy update for AI content. This may affect files that are uploaded to Wikimedia Commons for use on this project. Thank you. Codename Noreste (talk) 17:11, 23 June 2026 (UTC)

(This message was sent to Commons:Txokoa and is being posted here due to a redirect.)

Problems related to geographic categorisation

i'd like to ask if the community has written about/summarised the common problems related to geographic categorisation, and how we tackle the problems. that is, suppose we have a pair of coordinates (3, 9) and the name of its location "foo", over time:

1. foo came into existence at a certain point of time, let's say 1888.

   do we categorise an image of (3, 9) in 1777 under cat:foo?

2. the boundary of foo could change, so (3, 9) are inside the boundaries of foo only for a certain period of time (let's say 1999 to present).

   should an image of (3, 9) in 1900 be in cat:foo?

3. the name foo could change.
4. it's correct that (3, 9) lies inside foo right now, but what happens in future if that is no longer the case, because one of the above (boundary change, name change or formation/dissolution) happens?

similar problems also exist for wikidata and sdc. for example, suppose File:Sudan Juba cattle on street.jpg had location of creation (P1071) set to sudan in 2005, but then history was such that south sudan became independent in 2011, so where the image was taken is no longer sudan. what to do about this? solutions i can think of:

1. set qualifier "point in time"
2. remove the statement and replace it with the current correct one

if #1 is used, then a question is: is boundary change kept track of in wikidata?

if #2 is used, it's technically illogical, because a photo could not have been taken in south sudan in 2005. technically it was taken in "what was then sudan" or "what is now south sudan". RoyZuo (talk) 18:41, 23 June 2026 (UTC)

Comment: I think it can be useful to have categories that relate both to the legal jurisdiction at the time and those of the present day. For example, if an image shows Lviv in 1900, it is useful to have categories that relate both to Ukraine and to the Austro-Hungarian Empire; if an image shows Seattle in 1870, it is useful to have categories that relate both to Washington State and Washington Territory; etc.

Some of these cases (e.g. the Lviv one) can raise a lot of political sensitivities). Others (e.g. the Seattle one) really only raise issues of (1) ontology and (2) helping people find media. - Jmabel ! talk 22:30, 23 June 2026 (UTC)

I favor including images from a certain location broadly in the relevant categories, even if the political boundaries have changed. Categories are our main navigation tool so a a user looking for images in a certain location should not have to jump to a category tree of another country. "<location> by year" metacategories can be limited to only include the relevant political categories. MKFI (talk) 07:18, 24 June 2026 (UTC)

How should we get photos of famous people, which are decent?

I mean decent resolution and good enough the subject will be at least okay with it. So we won't get more cases like Zara Larsson, I mean, complaining about their photos here.

I'm not sure if a very good one can be taken. One of the very good was Charlie Kirk's one, taken by Gage Skidmore. The photo was so good it was made his profile picture. — Preceding unsigned comment added by Candidyeoman55 (talk • contribs) 17:28, 24 June 2026 (UTC)

Commons:WikiPortraits is a project addressing this. It's also getting more common to be able to find a reasonable quality video still on YouTube, where a person has been interviewed or hosted by a channel or institution that releases its video content under a CC licence.

It would also be great if more people (both celebrities and people who reply on social media to celebrities) were aware that posting a selfie to social media is enough, so long as it has the right licence statement on it. --Belbury (talk) 17:38, 24 June 2026 (UTC)

The best best way is always to make the photo yourself. If you need some accreditation to attend an event as photographer ask you local chapter for assistance. GPSLeo (talk) 18:17, 24 June 2026 (UTC)

But then don’t be a (unintentional) creep about it. There’s been a few embarrassing situations where the person felt uncomfortable by the way they were asked for a photo. Please exercise the utmost level of care and consideration, these people have to deal with stalkers all the time and at first glance, such a request can easily be mistaken for stalking or otherwise invasive behavior. —TheDJ (talk • contribs) 22:45, 24 June 2026 (UTC)

When famous people are on a stage there are always many photographers. This why I suggested to go to such events and not to ring at the door of the persons home. GPSLeo (talk) 04:40, 25 June 2026 (UTC)

A few remarks here:

• The Zara Larsson situation was an outlier: we've had plenty of "decent" images of her for a long time but also lots of efforts in her en-wiki article to insert copyvios, fake images, etc., and to opt for oddly uncomplimentary choices from among what we've already got. I don't really love the one we've ended up with in the Infobox at en-wiki (too specific to particular stage makeup, not likely to be useful to identify her in any other context) but I gather she likes it better, and at least we could form a consensus.
• While I think we should generally want the prominently-featured photos in an article to be reasonably complimentary, we are not part of someone's publicity apparatus, and we are not compelled always to pick the photo that the subject (or their representative) likes best. Sometimes that results in a very bland, generic head shot or stylized performance photo that fails almost completely to capture the person, whereas we may have some much better portraits of them.
• Nothing against WikiPortraits, they are doing a lot of good work, but people sometimes seem to see this particular group as now being the be-all and end-all. This isn't the place to go into where my aesthetic for my own photography differs from their prevailing aesthetic, but I'll say that there are a lot of excellent photos on Commons shot in a lot of different styles, and we're the richer for it. - Jmabel ! talk 02:15, 25 June 2026 (UTC)

The Zara Larsson situation doesn't really seem to be about getting a decent photo, but more about the person wanting to be represented a specific way. To me at least, the old photo looks more complimentary than the current one, but it seems reasonable enough to follow the person's wishes when they are reasonable and not misleading, which seemed to be the case in that situation. However, I don't see how we could possibly avoid that situation, its not really possible to read the subject's mind, and I don't think there was anything objectively wrong with the old photo. There are lots of Wikipedia articles with much worse photos. The only thing I think we reasonably could do differently is somehow promote to people that if they don't like their photo they should first complain on the talk page and if necessary donate an alternative, instead of complaining on tiktok. Bawolff (talk) 05:26, 25 June 2026 (UTC)

just a random idea.

how about making a toolforge app, that's like a passport photo maker? a simplest way to streamline the whole process of submitting a selfie, from registering an account to taking the selfie to uploading to having it properly categorised.

there are a lot of people's wp articles without pics, for example many athletes (in not very commercial sports) and professors. if there's such an app, and when the infoboxes on wp have no pics they provide a link to this app, maybe when the subjects see their empty profiles they are quite likely happy to upload selfies. RoyZuo (talk) 09:07, 25 June 2026 (UTC)

The hardest part is for anybody reasonably famous, you probably need to go through VTRS or otherwise get them to prove they really are who they say they are and are actually licensing the photo. Bawolff (talk)

i was thinking of the webapp using the phone/laptop camera to take a photo. i'm not sure how hard it is to cheat that with a fake.

and these photos can be uploaded to a buffer to wait for commons users to approve. ask them to submit a photo from third party sources (e.g. news articles) for cross corroboration to make checking easy.--RoyZuo (talk) 22:35, 25 June 2026 (UTC)

Commons:Harassment

Hi, This is an essential policy of Commons, and I am very surprised that it is not yet translated. Please help. Yann (talk) 07:12, 26 June 2026 (UTC)

+ Commons:No personal attacks, Commons:Civility. Yann (talk) 13:39, 26 June 2026 (UTC)

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

This is BChoo (WMF) (talk · contribs) writing on behalf of the Wikimedia Foundation's legal department. We wanted to follow up on the discussion now archived at Commons:Village pump/Archive/2026/06#Court Order Concerning Commons Image Related to the 2026 Onikişubat School Shooting.

Omphalographer (talk · contribs) asked if we could share the content of the takedown order, the WMF's objection, and/or the rejection of the objection. I have uploaded the 24 April 2026 takedown order and the 13 May 2026 rejection of the objection to Foundation Wiki (personal data redacted, in Turkish). We hope this is helpful. BChoo (WMF) (talk) 20:13, 26 June 2026 (UTC)

Thanks for this. ―Justin (koavf)❤T☮C☺M☯ 20:21, 26 June 2026 (UTC)

Thanks for following up on this! I have to admit I don't read Turkish myself, but I do hope that the text of the order will help inform discussions surrounding it. Omphalographer (talk) 20:41, 26 June 2026 (UTC)

Is there a reason this can't be hosted on Commons? I dont know if Turkey typically copyright's it's court documents Trade (talk) 22:05, 26 June 2026 (UTC)

Part of Law No. 5846: Art. 31. The reproduction, distribution, adaptation or exploitation in any other form of laws, bylaws, regulations, notifications, circulars and court decisions that have been officially published or announced is permitted.

My reading is that the documents at wmf can be copied to Commons and could be transcribed and translated via wikisource ({{Legislation-TR}}), if anyone wants to try? --Fæ (talk) 09:21, 27 June 2026 (UTC)

So from my amateur understanding the Turkish judgeship demands the file to be taken down for being in violation of "Law No. 5651, Article 8" which applies to things such as "obscenity, suicide encouragement and child abuse". In the second PDF the judgeship changes their reasoning to "Article 8/A" which is a law that allows for the state to prohibit media that "threatens the national security and public order" such as "terrorist propaganda", "blueprints for terror attacks", "incitements to riots" and similar things --Trade (talk) 22:16, 26 June 2026 (UTC)