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)

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)

Descriptions are not visible in categories or other lists of files. Omphalographer (talk) 20:11, 10 June 2026 (UTC)

This has been superseded with Commons:Bots/Work_requests#Book_renaming. Having done 17,000 renames to try out the method, it retrospectively does the same type of naming as the most recent IA uploads. As the internetarchive is driven by volunteers, there's always uncertainty in how good mass actions like this are going to be, though collections like the mentioned MHL are done by one curator sticking to a sensible pattern. Anyway, it can be done but with a little care to check it does not create a mess. --Fæ (talk) 20:58, 10 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)

OK, that makes sense. Thanks. — W.andrea (talk) 18:56, 10 June 2026 (UTC)

Deployment of Legal and Safety Contacts Link in the Footer of Your Wiki

Hello community,

The Wikimedia Foundation has provided a single legal and safety contact page, to be linked in the footer of your wiki, to ensure access to accurate legal information. This is a regulatory requirement.

We have already rolled out links to English, German, Italian, Spanish Wikipedias and other wikis and we will deploy to your wiki soon.

Please read more on the project page and leave any comments in this thread or on the talk page. –– STei (WMF) (talk) 17:20, 9 June 2026 (UTC)

Good. Those have been terribly hard to find. - Jmabel ! talk 04:38, 11 June 2026 (UTC)

Which license to use by conferences?

I participated to an EPF conference and the organisers make the pictures taken during the conference available free of use.

Quote: SwissTransfer link with pictures taken by our photographers. You are free to use these photographs in any external communication. This link is valid for one month. :End Quote

https://www.epf.eu/wp/epf-confereepf-conference-2026-advancing-sustainable-passenger-mobility-across-europe/

Wich license should I use?

PS: There is Category:European Passengers' Federation (EPF) (my own pictures in past conferences)

Smiley.toerist (talk) 09:31, 10 June 2026 (UTC)

If someone is bold, they could say that this quote authorisation amounts to {{Copyrighted free use}}. But we should apply COM:PRP, which makes that statement from whoever insufficient for our purposes. It would be better if you could get a clear license name, maybe a statement that the media are made available under e.g. the CC-By-SA 4.0. I would actually refrain from a Commons upload for now. Regards, Grand-Duc (talk) 10:50, 10 June 2026 (UTC)

I am a member of the organisation wich organized this conference and know most of organizers personaly, so it would be no problem to confirm the authorisation. At the conference itself the policy about the availibility of the presentation slides and pictures taken was make public. There are lots of pictures of the speakers/presentations. Most of the speaker names are in the conference agenda, but if their is doubt who is in the picture I can ask.Smiley.toerist (talk) 09:39, 11 June 2026 (UTC)

@Smiley.toerist: you will have to make sure that the conference organisers actually have the intellectual property rights that the photographers own at first when making their images. They can be transferred, but that transfer must be documented, in writing. Furthermore, this rights transfer must allow for a free license. Ideally, any conference photographer did transfer "all economic exploitation rights" (or made a rights transfer with a wording of similar or broader meaning) to the conference organisation. That way, it's within the purview of you and your colleagues to grant a license (as the photographers did transfer that right beforehand). Regards, Grand-Duc (talk) 14:34, 11 June 2026 (UTC)

Its not our business to investigate if the internal paperwork of the organisation is correct. The photographers where not professionals, but members who where tasked to take pictures of the event, for use by the organiser. So wil ask the organiser to confirm a cc-by-sa-4.0 license, wich I will be using.Smiley.toerist (talk) 12:14, 12 June 2026 (UTC)

Per C:PCP, it is our business. The conference took place in Maastricht so Dutch copyright law ("auteursrecht") applies and that is pretty straightforward: Rights stay with the author unless it's explicitly transferred. You have to provide proof that's the case if you have the organizers provide the license. Probably better to have the individual photographers provide a license for the photos they took. Multichill (talk) 19:34, 12 June 2026 (UTC)

We do accept the GLAM claims that what they released to us, is public domain. (Unless we have evidence it is not). And if an organisation claims its pictures are free to use, we dont accept it. We are splitting hairs now and being more catholic than the pope.Smiley.toerist (talk) 22:01, 12 June 2026 (UTC)

GLAM institutions are (often) used to deal with intellectual property rights and have (often) some expertise in it. This cannot be reliably surmised for some associations organising conferences (unless it's e.g. a conference by attorneys in IP law). Regards, Grand-Duc (talk) 22:18, 12 June 2026 (UTC)

The law does not apply automaticaly for employees or volonteers working for an organisation. If people having a working relationship (employment) with the organisation get an assignment to take pictures for the organsation, the organisation gets the full authorship rigths, unless otherwise specified.Smiley.toerist (talk) 11:45, 14 June 2026 (UTC)

@Smiley.toerist: for employees or contractors that varies by country, and I'm not offhand aware of any country where volunteering for an organization would automatically assign them your copyrights. It certainly does not in the U.S. - Jmabel ! talk 22:15, 14 June 2026 (UTC)

In practice, volunteers and employees, will be wel advised to mention any restrictions, payments etc on their pictures, before they take the pictures. If there are limitations, the employer wil ask somebody else to do the work. If they demand their legal rigths afterwards, they wil jeopardise their work relationships with their employers. So these rigths are more theoretical. In practice most of these things are done informaly. Professional photographers wil make their conditions clear before any fotosession.Smiley.toerist (talk) 11:01, 16 June 2026 (UTC)

And, in practice, if an organization wishes to obtain copyrights in a situation like this, they would also do well to have contract terms to that effect. I've done a moderate amount of photography (in the U.S.) as a contractor in situations like this. I can't remember ever having to sign over copyrights, though I've certainly signed over very liberal usage rights, even sometimes including that I do not have to be credited on use by the organization itself. - Jmabel ! talk 18:28, 16 June 2026 (UTC)

Is it worth running OCR on full newspaper pages?

Is it worth running OCR on full newspaper pages like: File:"Scenes Taken at Huge $2,000,000 Pier Fire" Evening Vanguard, January 7, 1924.jpg, or just hope someone in the future breaks it down into the individual news articles? The Library of Congress does entire pages but it is of limited usefulness. --RAN (talk) 16:14, 11 June 2026 (UTC)

That's something for Wikisource to care about. Bedivere (talk) 22:37, 12 June 2026 (UTC)

Here's a sample of what an OCR does with it, so probably not worth the effort as the output is so buggy.

ye

MONDAY,    J ANUARY:   1

ief Congratulated for
Coolnezs Under -
* Fire
Officer Mer of the’ Venice police |.
‘ce turmed in the alarm of the |
ean Park fire yesterday at 9:50 |
m. when he phoned.tc Captain {
go.at the station hore, news: of |
spreading disaster.
here was troubje on the police |
@phone atid Officer De Villa, of |
D motor¢ycle corps rushed to the |
@cpartment and got Engine |
. 2-cf Company. No. 1 away in|
16 to be first at the blaze.
oung McCauslang, son of Chief
Police H. H.  McCausland,  who |
at the station, sped cn the |
nds of putting in an emergency. :

for every officer cn the force
turn get.               -.
The first consideration of: the of-
rs and orders given by Captain
go were for the roping off of
» lines ‘to keep the sight secing
blic: out’ of the fighting zones.
vaptain. Lingo drew on his ex-
ience af September 1912, when
was chief of police of the Ven-
force’ to tackle the early
ases of the work at the fire. -

ief of Police H. H. McCaus- |
hd, whd w

If you want to research how it can be done, this was using pytesseract with an "automated page segmentation" setting, more info. Fæ (talk) 20:14, 14 June 2026 (UTC)

• It is imperfect, as is the OCR done by the Library of Congress at Chronicling America. I tend to find better OCR at Newspapers.com. Newspapers.com reran all their OCR recently using newer software. You can pick out a person's name in your example, and that just might be what someone is looking for. Otherwise the few thousand newspaper page images we already host, are just decorations. --RAN (talk) 22:21, 15 June 2026 (UTC)

Who can help to categorise the 22,000 media items from 2022?

In the category All media needing categories as of 2022 are approximatels 22,000 items that need to be categorised. In February 2025, there were still 80,000 – so we are making good progress. Experience shows that the final quarter is particularly difficult and requires not only knowledge of categorisation but also the ability to read foreign characters. Tips on this can be found in the WikiProject Minimum One Category. Who is able and willing to help with this, or has a good idea on how it can be done most effectively? --NearEMPTiness (talk) 07:03, 13 June 2026 (UTC)

While I appreciate the intention, I am not sure I fully agree with some of the results of the previous round. I noticed a lot of files moved from one pile of uncategorized mess to another pile of essentially uncategorized mess (now in two flavours: Category:Unidentified locations and Category:Unidentifiable locations). Fine if it is combined with some generic category to describe the subject, but not as the only category (e.g. File:DSC 0147 (35990764463).jpg could have at least gone into some building category if one does not know it is Category:Osaka Castle). --HyperGaruda (talk) 08:39, 13 June 2026 (UTC)

I agree, looking Category:Unidentifiable locations, I can clearly see some images literally has the locations in their filename. For example:

• File:Darhal Valley.jpg
• File:East Shore Park.jpg
• File:Gate D of banshankari metro.jpg
• File:Lohajung Village with snow in January.jpg

So, not sure why these are "unidentifiable", and not placed in the correct category in the first place. Thanks. Tvpuppy (talk) 09:54, 13 June 2026 (UTC)

Yes, the objective is, to put the files into the most appropriate category, not only into an unidentified category. However, even the latter is useful, for instance, when an expert is needed to identify animals or plants. NearEMPTiness (talk) 12:13, 13 June 2026 (UTC)

• Category:Unidentified men has the same problem, the person may be identified in the caption or the image title, and is just missing a category for a person. --RAN (talk) 22:25, 15 June 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.

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

Flat lists

Do we have a category that contains all the flat-list categories? RAN (talk) 15:39, 14 June 2026 (UTC)

Sorry if this seems pedantic or rude, but I'm not sure how to word this. Can't you easily answer your own question by going to a flat category (e.g. Category:Surnames (flat list)) and seeing yourself that it is in Category:Flat categories? Is there something that I'm missing? ―Justin (koavf)❤T☮C☺M☯ 15:41, 14 June 2026 (UTC)

• Probably because we call the concept "flat lists" and we call the categories "Category:Flat categories". Solved with a new and simple redirect, Category:Flat lists redirecting to Category:Flat categories. --RAN (talk) 21:00, 15 June 2026 (UTC)

Photo challenge April 2026 results

Fair grounds: Entries • Votes • Scores

Rank	1	2	3
image
Title	Giradabo at Tibidabo amusement park in Barcelona	Lunapark, Krynica Morska, Poland	Swing ride at the Wurstmarkt Dürkheim
Author	IM027	BogTar201213	F. Riedelio
Score	13	13	10

Wooden bridges: Entries • Votes • Scores

Rank	1	2	3
image
Title	Bridge on the beach	Pont en bois sur une rivière entre le Dorgun nuur et le volcan Khorgo, Mongolie, Juillet 2008 - Wooden bridge over a river between Dorgun nuur and the Khorgo volcano, Mongolia, 7/2008	Wooden Bridge over the Elz in Wittenweier, Germany
Author	Nocomentapapun	Jean-Marie Vugnon (2)	Kmtextor
Score	13	9	7

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)

Dashed lines in GEOJSON pages?

Is it possible to add dashed lines to a GEOJSON map data page? If it is possible, how? If it isn't possible, how could the feature be implemented? —TheGinger68 ↗ 20:38, 14 June 2026 (UTC)

Styling in these maps are defined in the simple style spec, and there’s no provision therein for dashed lines. Opening an issue on that GitHub page might get the right people to start thinking about it, but I’m not the one to be promising anything on that front. BMACS1002 (talk) 04:43, 16 June 2026 (UTC)

It’s been an open feature request for a long time. I wouldn’t be surprised if another existing implementation of the specification implements a dash pattern option unilaterally though. Minh Nguyễn ^💬 04:58, 16 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)