Commons:Village pump

Shortcut: COM:VP

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓

COMMONS DISCUSSION PAGES Commons Help desk Village pump (general discussion) Copyright Proposals Technical Graphics and photography discussion Photography critiques Image improvement Illustration workshop Map workshop Photography workshop Video and sound workshop Categories for discussion Undeletion requests Deletion requests Volunteer Response Team/Noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems (Dispute resolution) Blocks and protections Bureaucrats' noticeboard CheckUser requests Oversight requests Telegram IRC webchat Commons mailing list (archive) Commons' bugs on Phabricator Welcome to the Village pump This page is used for discussions of the operations and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2025/12. Please note: If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias. Have you read our FAQ? For changing the name of a file, see Commons:File renaming. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer). Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam. Purposes which do not meet the scope of this page: Please do not make deletion requests here: use the relevant process for it instead. For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump. To ask for image improvement, see: Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. To ask for video or audio improvement, see Commons:Graphic Lab/Video and sound workshop. For translation requests, please post at Commons:Requests for translation. For media requests, please post at Commons:File requests. For questions about copyright, technical matters, or help that does not relate to the general Commons community as well as proposals, please see the other discussion boards linked in the blue panel at the top. Search archives:     Start a new discussion

Legend
In the last hour
In the last day
In the last week
In the last month
More than one month
Manual settings
When exceptions occur, please check the setting first.

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

Centralized discussion See also: Village pump/Proposals   ■ Archive Commons:Village pump/Proposals#Temporary account IP viewer policy (6 September 2025) User talk:CommonsDelinker/commands#Replace images with .svg version (5 August 2025) Category talk:Heroes' Cemetery in the Philippines#RfC: Cemetery name (18 July 2025) Discussion on Copyright law of North Korea (16 March 2025) Hosting of free fonts in Commons (18 July 2024) Template: View   ■ Discuss    ■ Edit   ■ Watch

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

December 04

Community Wishlist – Voting open for Commons-related Wishes!

Recently, voting was enabled in the Community Wishlist. It's the successor to the prior Wishlist Surveys and unlike these runs indefinitely. It's a place for the global Wikimedia community/ies to submit feature proposals, ideas for innovations, and requests to get important bugs fixed.

There are many Commons-related wishes in the Wishlist so I'd like to call on you all to browse the wishes, read the ones you find interesting and vote on the ones you find important. Better to not postpone it. Here's some I'd like to highlight after having read all of the 410+ wishes:

• Show categories on mobile – categories on files are very useful but if you use a smartphone to access Commons like around half of users, you can't see them
• Open the Wikimedia Commons file page directly – when opening an image on Wikipedia, it doesn't open a Commons page (the file page) but shows a intermediary Wikipedia page that does not have the categories; this means we get far fewer visits and far fewer people learn about Commons
• A proper audio player – e.g. up-to-date audio versions of Wikipedia articles can be provided now for many articles and could probably double Wikipedia reads but only with a modern player & well-visible audio
• Do something about Google & DuckDuckGo search not indexing media files and categories on Commons – after some work on this videos on Commons are showing in Google's Videos tab but there's more

.

• Add machine translated category titles on WMC – titles are short and by translating them people searching the Web in their own language can also find the Commons cats
• Add a date range filter to Special:MediaSearch
• Suggest media set in Wikidata items for their Wikipedia articles – if you find good media on Commons, just add it once to the WD item and it can trickle down into the Wikipedias
• Video & audio chapters (jump to timestamp)
• When searching Commons, if there is a category with same or very similar title, show a hint/link
• In Commons category deepcategory view mode (wall of images), allow easily filtering offtopic subcats – basically what is needed for a wall-of-images view for categories including subcategory contents
• A way to see why a file is somewhere underneath a specific category (tool to show cat-path)
• Support full colour 3D models on Wikimedia projects – currently it's only STL files without textures
• When searching Commons, under "Categories and Pages" show the category for the search term – basically search results are bad if you look for category/ies, not galleries
• …

• 
  How the audio player could look (bottom panel) after clicking play (desktop)
• 
  audio player for a Spoken Wikipedia audio via audio-chapters (mobile)
• 
  Video on Commons now showing in Google (success)
• 
  Opening an image on Wikipedia in a new tab or with this button does not show the Commons page

If you have questions about any wishes there, ask on the wish talk pages or check if things have already been clarified there. Currently, software development by the WMF is rather low but maybe that changes in the future so voting can still have an impact. You could also name some wishes you find important but weren't mentioned here.

There also is a tag for wishes called 'Multimedia and Commons' by which you can filter the table. Alternatively, you could enable this script and use the category page. However, note that some wishes relevant to Commons don't have the tag because they relate to basically all projects.

The wishlist is based on a new MediaWiki extension. In this Wishlist, there are 'focus areas' which used to be the only things you could vote on until recently. You could additionally vote on these, especially the focus area most related to Commons:

• Focus area 8: Media formats, editing, and display

Prototyperspective (talk) 23:32, 4 December 2025 (UTC)

I think people underestimate how many of these are political wishes not technical ones. Sometimes I feel like people feel they are powerless due to lack of technical know how, but so many of these are stuck on either getting everyone to agree or hammering out ambigious details, which is something anyone can in theory do. e.g. Show category on mobile - would take 10 seconds to change, the real issue is the mobile team came to the unfathomable conclusion that it would be a bad thing. Open image pages on commons. Also pretty easy, i think that one is stuck on most people not caring one way or another, of course the real question is how does this play with media viewer. Machine translation of titles sounds pretty spicy (My personal view is that this is the wrong solution to a real problem). Anyways, 90% of the battle is figuring out what you want and convincing everyone else to agree. Bawolff (talk) 06:53, 5 December 2025 (UTC)

how many of these are political wishes not technical ones. I don't know if you're referring to the wishes in this Wishlist in general or the wishes I linked or a mix – if the second, wishes that aren't about technical changes but about policy-changes get archived there. Some haven't yet been archived but I think by now all of these have comments on the talk page basically asking for it to be archived. It's relatively few that haven't yet been archived. political wishes not technical ones when you say that, you claim they're only "political" – but they rather have political/policy/group-decision-making aspects. Often, these aspects are already elaborated in the wish or on its talk page. If not, I suggest you add the info there. Ultimately, wishes are about getting certain things done / problems solved. If there's also political things that need addressing or be done, then wish creators and supporters are certainly interested in discussing these there and getting them done as well.

• so many of these are stuck on either getting everyone to agree or source? I think they're stuck because there's very little software development and apparently relatively little interest to do any of the many things that could be done to increase it. Only some are stuck on these as well but obviously things like that don't get solved by themselves but need the political aspects to be clarified and then addressed. If 30% of wishes were implemented, one finds another 40% to be infeasible or quite unimportant, then it would be much easier and flow naturally to narrow in on the remaining 30% to find which of these are stuck on political issues and then work on addressing these. This is how I'd imagine the impact of more software development: as WMF would solve more critical bugs, boring but important issues, and more issues in general, people get freed up to and can dive more into suggested innovations and extend Wikimedia. The first step is more development.
• …or hammering out ambigious details That's why I always tried to include potential solution(s) in the wishes and add ideas on how to solve it to the talk pages of wishes that don't have such technical info despite that the wishlist is/was intended to be problem-focused. More details can be hashed out on the talk pages in regards to how things could be done in practice. I also had one user mail me, saying they're developing a script that aims to solve one of the wishes. Details don't get hammered out by themselves, it needs people to think about them and discuss them – this is what the wishes and their talk pages are for too.
• would take 10 seconds to change, the real issue is the mobile team came to the unfathomable conclusion that it would be a bad thing Exactly! So they should do it. It has been asked for many times, the community certainly wants it – it has been the top #1 wish of the Commons Technical survey, is a heavily-followed code issue, and was the top #3 supported wish in the 2023 global Wikimedia Community Wishlist survey. The WMF just ignores it and doesn't even feel the need to give any explanation why they are doing so (they didn't even say that they concluded this). Afaik, they only said Unfortunately, our key partner, the Web team, will not tackle this wish now. The importance of categories to readers must be researched further to prioritize this wish instead of other pending wishes. I strongly disagree with that. Moreover, if they want to do further research before implementing this, then do it.
• Also pretty easy, All the better. So it should rank high on feasibility and ease of implementing. on most people not caring one way or another Hence the wish and the ability to support it. Wikimedia community often shoots itself in the foot. Here we're keeping Commons down for no reason. If you like Commons to be better known and used more + wikilink in file descriptions to not be redlinks + categories to show on file pages at least when on desktop, then I strongly suggest users support this wish. However, most users aren't much aware of this and haven't thought about it. I don't know why you say this as if it was a caveat or downside of the wish: that it may be easy to implement is an advantage and that people in your mind don't care about it, is basically the point of the wish. the real question is how does this play with media viewer No, that's not the real question. Why would it? If you think things like that, I always suggest you (also) raise it on the wish talk page where it potential issues can be addressed. The MediaViewer actually does link to the Commons file page directly – it works how it should. One clicks the "More details" button and it takes you to the Commons file page. It's just that the other file links haven't been adjusted.
• Anyways, 90% of the battle is figuring out what you want and convincing everyone else to agree If this hypothesis was true, then nearly all top 15 wishes of the past years' wishlists would have been implemented. It's far from that. Either way, the wishes – including the voting and the talk page discussions – are one part of that.

Thanks for your feedback; basically maybe the political aspects are underestimated (which imo would suggest that the impact of votes & discussions are also underestimated). Prototyperspective (talk) 13:12, 5 December 2025 (UTC)

Perhaps I'm just sad how it feels like things have devolved to the community begging WMF for tidbits. I guess that is the natural consequence of more and more development happening by WMF instead of being more community oriented. I do think (with the exception of the mobile category one) that the higher you get on the wishlist the more technical and less political things become, because to make it to the top of the vote list, you need more universal agreement to get everyone to vote for it. Bawolff (talk) 17:28, 5 December 2025 (UTC)

@Prototyperspective I do think you underestimate some of the social bits of this. There is not simple 'just doing it'. Just doing things affects hundreds of other people. "if this hypothesis was true, then nearly all top 15 wishes of the past years' wishlists", those people represent just a fragment of the userbase and generally none of the other stakeholders affected by the change. Please vote, please show your interest, all of that is sorely needed, and it DOES influence things. —TheDJ (talk • contribs) 12:55, 8 December 2025 (UTC)

Maybe but many or most of these are welcome by users with no significant objections to having the proposed functionality added. The high number of wishes clearly indicate that users would like to have what's proposed. I've voted on a lot of wishes already. Voting doesn't seem to have much impact so far though as again just a fraction of the highest-voted wishes and a very small fraction of overall wishes got implemented so far. Prototyperspective (talk) 16:24, 15 December 2025 (UTC)

December 07

Hatnotes in History maps of Europe

Since September, Ty and me are increasingly stuck in several arguments (essentially this entire page: User talk:Ty's Commons), one of them about the proper definition of history maps.

I will readily admit that Ty is the person who established a uniformed definition of European history maps by century, please compare Italy, Belgium, Spain, Poland, and so on. That level of standardization was in itself an achievement, where I had just created a patchwork-in-progress before. However, I get stomach issues when reading the elaborate hatnotes:

• Territorial definition: Ty has chosen this rigid definition: "map showing all or substantially all of the territory of modern-day <country> - as the lands were in the 16th century (1501-1600 CE)" (example here). This definition has two major problems: relevant history maps of subregions are not "all of <country>", and would by that logic be excluded. The second problem is word "modern-day", indicating that our current borders of today are the only acceptable definition of what may be included in Polish history. So my counter-suggestion has been: This category is about maps of the history of <country> in the 16th century (1501-1600 CE) - no "territory", "all" and "modern-day" involved. Ty refused this in several text walls.
• Atlas links: The second paragraph is the link to the Atlas project. Ty claims that it is important to guide interested users to other curated pages of related content; while I think that the Atlas does not need to be linked in every sub-subcategry. The "Atlas of France" may be linked in "Category:Maps of France", and the history subsection may be linked in Category:Maps of the history of France. However, links to the Atlas are superfluous for each by-century subcategory.
• Even more user guidance: Like the Atlas, so the following Additional maps related to... paragraph. The link is already included in the navigation bar just below, and is self-explanatory there.
• Missing differentiation: An important part that I think needs to be distinguished and explained, is that "old maps" are not "history maps" (in short: this is a "16th-century map of...", but this is a "map of ... in the 16th century"). The similarity of the category names make it important in my opinion to clarify the matter in each category. Ty has for some principled reason removed this part of the hatnote and just places it in the see-also-box.

Ty and me are apparently both frustrated by this matter, so I am hoping for intervention and some comments by other users: What would be the best wording in the hatnotes/definitions for these categories? --Enyavar (talk) 12:55, 7 December 2025 (UTC)

Thanks for your note and apologies for the delay in follow up since I've been involved in another project. I believe we've made progress on a number of issues (as challenging as they've been at times). But I think the matters have warranted considerable attention because we've been addressing overall frameworks that involve a large number of maps related to the histories of our European countries - which are no doubt complex. I'm also especially concerned, as you know, that our categorizations of maps line up as well as they can with both our overall categorization policies (which empahasize a uniform and systematic approach to the handling of our current countries and their histories) - as well as to other parts of Wikimedia Commons categorizations for the histories of our countries (to which maps should be linked).

• Regarding the key remaining issues of territorial definition etc., I will respond shortly regarding these since I haven't had a chance to address your recent proposal. Some of the confusion has been caused by your use of the term territory in a way that is different than what is actually being referred to in the category definitions. From your most recent comments, I appreciate that what you're actually getting at is the handling of regions within the territory - and I will address the proposal regarding these.
• Going forward, I do intend to address the issue of numerous maps being categorized and effectively separated from each other (and from related subject matter) - not based on their subject matter (i.e. the particular region and time they are portraying) - but rather on each map's year of publication. The most important subject matter for maps showing history is the country or territory with which it is associated and the time period of its history being reflected in the map. Indeed no map is particularly valuable if the time period being shown is not clear. It's publication date, licensing status, etc. are properly part of secondary attributes. I think that is consistent with both our file descriptions (which effectively separate subject matter from publication date and licensing), and our overall categorization principles based on subject matter.

The issue is especially true for maps showing history - because these maps generally reflect the contributions of historians who have been focused on aspects of the prior events, which necessarily occurred years or even centuries earlier. In my view (as both a user and contributor of such maps), I believe that for the benefit of users, maps showing France in the 16th century (which is their subject matter) should be categorized together. In particular, users have a need for maps of a particular era or period in a country's history for a variety of purposes - both research as well as articles etc. - and they should be able to readily see the corresponding set of maps with that subject matter together.

Conversely, sequestering maps of related subject matter into completely separate and essentially unpredictable hidden "drawers" - based on they're having been published in 1956 versus 1955, or in 1843 versus 1833 - clearly makes maps much harder to find. And finding some leads users to naturally assume they represent all that's available - even though maps of greater interest (for detail, size, etc,) might be available. Unfortunately, they didn't know in advance that the map of France in the 16th century was actual sequestered away into a category such as "old maps" of France published in 1922. Indeed, related categorization systems based on ambiguous terms such as "old," "old contemporary," "historic," etc. are not considered generally helpful. I see that concerns with these have been raised by other users in the past - but not really addressed - and they do need to be.

• A related but very important issue is accuracy. Relatively new maps may contain better information (or be smaller etc,) - but since they're often not from publications it is often unclear where the overall information used to generate it has been obtained. And even for cases in which a citation has been provided, the actual map and other information from the cited source are often not - making it difficult to know whether the creator accurately reflected what was earlier reflected and published. Conversely, older maps are often quite detailed, but it's possible that later historical information has led to corrections. Seeing maps showing what should be the same basic territory and historical status (including names, borders, internal regions etc.) side-by-side is the best way to determine whether there are inconsistencies. Categorizing these maps together by subject matter then allows users to quickly compare the group, assess their accuracy and relevance, and then select the map or maps that best match their remaining interests (including such additional attributes as publication date and licensing status, level of detail, size, cities included, regional borders, neighboring countries, coloration, etc.).
• Finally, regarding Wikimedia Commons extensive and ongoing atlases of our country's histories (such as Wikimedia Commons: Atlas of Spain ) - which not only reflect contributions from many members of our community but are quite closely related to categories of maps showing the territories and histories of these same countries - I was certainly very surprised by Enyavar's suggestion that cross-references to the Wikimedia Atlases (a project he's made clear he has no interest in despite his frequent involvement with related maps) should actually be effectively suppressed from corresponding categories.

I was even more surprised by his suggested reason for this being that the "Category tree is not primarily supposed to guide Users to potentially useful files."

If the category tree and categorization in general is not primarily supposed to guide (and help) users to find potentially useful files, then I think there are even more signficant conversations to be had. Among them, our overall Wikimedia categorization principles, which are in large part directed to that very goal of helping users to find what they're looking for, would need to be substantially reconsidered and rewritten.

In closing, I will plan to continue these discussions with Enyavar - focusing on our official categorization policy and its agreed principles, consistency across our categorization framework for the histories of countries, and last but most important, enabling users to find what they're looking for even, if they're not familiar with all of the intricacies of European countries and their complex histories. Hopefully the eventual outcome will be improved categorizations of maps, especially for maps reflecting the histories of each of our current countries. Ty's Commons (talk) 15:40, 7 December 2025 (UTC)

This topic was strictly and only about the category hatnotes. On the topic of user guidance, Ty misquoted me in that reply. I hope that you all see why I am hoping for an intervention. --Enyavar (talk) 19:21, 7 December 2025 (UTC)

Enyavar initial post here raised a large number of largely orthogonal issues whose only two common threads are (1) that they have to do with [hatnotes of] maps of Europe and (2) which two people have been disagreeing about them. If I read correctly, Ty's Commons then widened that even further. It is almost unimaginable to me that we can have a coherent discussion about this on a single thread.

At the very least: could we start separate threads to discuss each issue whose answer is independent of the others (or almost entirely so)? Better yet, could we prioritize two or three issues to discuss first (each in a separate thread) so we do not have 8 or 10 simultaneous discussions about maps of Europe? Alternatively (though I guess the two could be combined) could we spin out a project page to discuss these issues, rather than the Village pump? - Jmabel ! talk 03:07, 8 December 2025 (UTC)

Gladly, I see three threads from my own original post. The idea to split them into three distinct threads is fine with me, maybe that can create coherence?

• the wording of the definition in the first paragraph of the hatnote (i.e. the subject definition, currently in all these categories)
• whether or not to include the proposed "user guidance" of the second and third paragraph of the hatnote (currently in all these categories)
• whether or not to re-include the proposed clarification on the distinction between old/history maps into the hatnote (currently absent in all these categories)

"These categories" means all categories in the scheme "Maps of <European country> in the <x>th century", which was a scheme we introduced together last year to create meaningful subcategories for "Maps of the history of <European country>". On background: There was an earlier by-century-scheme ("Maps of <x>th-century <European country>") which we fully converted to the above new scheme. That old scheme was fragmentary and unsuitable to be used together with templates. Another earlier scheme is still partial existent and groups history maps by-periods-by-country, i.e. "ancient period", "medieval period", "modern period", and in some cases additional periods. The period-scheme has obvious definition flaws.

I would like to not discuss the fourth+final issue here, because that topic is already dealt with by a CfD: whether or not history maps according to the above scheme must be made available for each century and each country of Europe, or if neighboring countries (e.g. ancient/medieval Low Countries, Scandinavia, Baltics, Balkans...) can be grouped together by region for practical reasons, and then be connected via redirect. Again, that is part of that linked CfD.

Aside from those four topical issues, I am not aware of more (praxis-related) disagreements between Ty and myself. Ty might disgree? --Enyavar (talk) 04:11, 8 December 2025 (UTC)

I generally agree with User:Jmabel that "Enyavar['s] initial post here raised a large number of largely orthogonal issues". I didn't actually widen it further as it was Enyavar's fourth point entitled "Missing differentiation" that relates to a parallel framework intersecting with this one - for which the issues are substantial (as reflected in my response). I'll separate that further below since it needs to be the subject of an ongoing review but will reference the overall issues from the perspective of this project. (Ty's Commons) (talk) 10:55, 12 December 2025 (UTC)

A. Current framework (Maps of 'Country Abc' in the Nth century)

Regarding the current categories at issue (e.g. Maps of France in the 18th century), I appreciate Enyavar's recognition that "Ty is the person who established a uniformed definition of European history maps by century… That level of standardization was in itself an achievement, where I had just created a patchwork-in-progress before."

Developing a uniform framework for such maps is challenging given the complexity and ever-changing entities that swept back and forth across Europe for two millennia. The framework is essentially anchored by one key touchstone: organization based on the territories (i.e. geographic area) of our current European nations - each of which territories is precisely defined - and each of which is also central to the history of the current nation. That organizational framework not only has the benefit of addressing what's been referred to as the territorial problem (discussed further below), but is also consistent with the treatment of the histories of European and other countries across Wikimedia Commons. In particular, overarching metacategories such as Category:History of Europe by country and its corresponding subcategories are all effectively organized in the same manner (i.e. beginning with our current countries and then categorizing the histories of their territories back through time, typically to the Roman Empire and in some cases beyond).

• For the framework to function and be populated most effectively, the corresponding category definitions need to make clear that it is the territory (geographic area) of each of our existing nations that is the principal focus. That's especially important because in many cases the earlier political entities (both internal and external controlling ones) had varying names as well as evolving and in some cases "revolving" domains. Not only can the current framework readily handle those, it's essentially designed to.
• To use Enyavar's example of various "Polish" entities, these were sometimes much larger than modern-day Poland - including at times not only Lithuania but parts of modern-day Belarus, Ukraine etc. Maps that relate not only to Poland but to the territories of these other current countries form essential parts of each of their histories and should be categorized accordingly. And they are with this organizational framework in two parallel ways: (i) they're reflected in the maps of Poland because they include its territory; and (ii) they're reflected in the various time-relevant categories for Lithuania, Belarus, Ukraine etc. (when and as those territories were included and are therefore reflected in the corresponding maps).
• Such a framework can be applied to readily and systematically categorize each nation's distinct history without having to effectively merge them into that of other nations or into regional agglomerations. So I don't agree with redirecting or otherwise merging any of our nations' categories of maps into those of other countries or regions and don’t believe that's consistent with either the uniform and systematic treatment of countries expressed in our official categorization policy (including the universality principle) - or with the parallel organizational schemes for the histories of our countries such as those referred to above.

The evolutionary changes of associated names and territories (both larger ones and smaller) are as complex as European history is, and so they're also very helpfully noted and illustrated in the corresponding Wikimedia country atlases; including, e.g., the Atlas of Poland (the history section of which tracks the territory that evolved into modern-day Poland) and the partially overlapping Atlas of Ukraine (the history section of which tracks the territory that evolved into modern-day Ukraine). These features combine to provide the organized framework of maps that allows users to both appreciate and easily navigate what would otherwise be a complicated jumble of historic entities and corresponding maps.

Additionally, from each and every category "landing page" such as Maps of Hungary in the 17th century, users can quickly see not only a set of maps depicting its territory (geographic area) at that time, but the link to the corresponding atlas page helps to inform them not only about its territory and evolution but also its time-dependent position within the various larger entities reflected in the maps (such as Hungary's place within the Ottoman empire and then later within the Austrian Habsburg territories). Since the categorization framework also includes a navigational template that Enyavar helped to inspire, users can then easily switch to any other century of interest for Hungary, or to any other European country, for example to see what the Austrian or Czech territories looked like at that time; and soon enough, additional maps for Romania, Serbia, Slovakia, etc.

The principal territorial issues have thus been covered, with one remaining exception - which is what Enyavar refers to as rigid defining language directed to maps showing "all or most" (previously "all or substantially all") of the territory of interest. That language was included to keep the categories closely focused on their subject matter - which is "Maps of country X" (e.g. maps showing France, not maps of Lyon or La Rochelle). Across the framework and within categories, the maps would thus reflect each current nation's territory at the corresponding time - and not become cluttered with maps showing various internal regions, cities or other localities.

Since the categories are only just being developed and populated and so don't yet have that many maps, I could potentially remove the limitation "all or most" from the category definitions going forward, since internal regions can be treated via subcategorization when and as appropriate. But I want to hold off on that at least for now because Enyavar and I are still discussing the issue and, even more importantly, because the best solution will likely be influenced by considerations of a parallel organization of maps that are collected and sorted based essentially on their publication date. These are discussed further below.

In sum, the current system is still being developed and populated but seems to be a valuable way of both organizing and navigating these maps, and is consistent with other frameworks on Wikimedia Commons as well as our categorization policy and associated principles. I plan to get the remaining European countries into the framework so that both I and others can then readily place additional maps into the categories of over time. (Ty's Commons) (talk) 10:55, 12 December 2025 (UTC)

B. Intersection with parallel framework of "Old" maps (collected and categorized based on year of publication)

An orthogonal but pertinent point relates to the last of Enyavar's issues (i.e. so-called "old" maps, which are currently any maps published prior to 1955). The categorizations discussed above should continue to be based on their essential subject matter (i.e. maps showing the applicable territory at the corresponding time) rather than when a map matching the subject matter happens to have been published.

The reason is that if maps showing the relevant subject matter are separated from each other based on year of publication, then not only will users not see the set of relevant maps together, but there is actually no second "set" or parallel grouping at all - because they would be separated not based on the corresponding subject matter but rather on their years of publication, which are scattered over decades and indeed centuries as noted above. What person in their right mind would want to hunt through a very large series of map drawers by publication year or decade - especially when they include both country maps, regional maps and others, showing different but varying time periods? They wouldn't, and they don't need to be. They should be shown maps of the same basic subject matter together so they can quickly see what's available, compare them according to whatever secondary interests they may have, and then choose the one that best suits their interests and needs. (Ty's Commons) (talk) 10:55, 12 December 2025 (UTC)

C. Ongoing considerations related to the parallel "Old maps" framework

The parallel framework of categorizing some maps as "old" based on their having been published more than 70 years ago, itself originated decades ago when the categorization scheme had relevance to separating files that were in the public domain. But the 70 year cut-off no longer accomplishes that - and the issue is now handled separately and methodically through the licensing provisions and otherwise.

In addition, it has been increasingly considered that the use of vague terms such as "old" or "historic" should be discouraged; see, e.g. the Categories for discussion 2024/04 Historic buildings. Key conclusions were as follows:

1. The category name is too vague to be useful.

2. Category names with vague words in the name like "historic..." and "old" should be deleted, not get a redirect or become a disambigious page, to prevent that they are used by unexperienced uploaders. Another opinion is that we should keep some of these categories with very generic titles so that they catch all such files added by clueless users. then other users can sort them into better category. This means that editors should spend time on this kind of maintainance, which is not desirable.

3. Though, we can create Category:Old buildings (or use something like "in the public domain" instead) for buildings that are in the public domain in countries with limited FOP.

4. Perhaps it is even better to develop a page Help:Historic that redirects to Help:Categorisation which we develop to help people to better categorise.

Consensus was reached and the discussion was closed as follows:

Consensus: > Resolved by consensus

Actions:

- Empty and delete categories with "historic" and "old" in titles with no redirection or disambiguation.

- Create categories like "X in the public domain" for PD stuff. / Optional, but create Help:Categorization with Help:Historic as a redirect.

The related issue was also intitially broached in the context of maps in November of last year in Categories for discussion 2024/11 Category:Old Maps. In that Cfd, Enyavar mistakenly suggested that user Sbb was somehow complaining about "maps of <location> by century".

But he was not - and the connection to "location" by century versus time of publication appears to have been added by Enyavar (presumably inadvertently) to what was supposed to be a quote. In fact, consistently with what is being said here, Sbb was referring to the April 2024 Cfd and essentially questioning the maintenance of the category "Old maps," by century (which is inherently redundant). The actual quote and relevant points were as follows:

(Sbb): I used to think that Category:Old maps would include only the maps whose copyright terms were expired. I don't know who has put Category:Maps by century under this category, which should be removed. BTW, categories starting with "historic(al)" or "old" are now discouraged, see Commons:Categories for discussion/2024/04/Category:Historic buildings. But this may or may not be an exception, even though it is a bit redundant to Category:Maps by century, Category:Maps by decade, Category:Maps by year, etc.

As reflected by Sbb and others, the fact that terms such as "old" or "historic" are both questionable and discouraged does pose an issue to be addressed more generally going forward.

Some earlier comments were frankly even more "pointed" - including in response to posts on Enyavar's user page at Old maps categories.

In that case a user noted as follows, in December 2023 (Pi): I don't think recreating Category:Old maps of Boston is a good idea. "Old" and "historical" are vague and subjective terms, which isn't useful for an archive that strives for accuracy. The consensus at Commons:Categories for discussion/2019/09/Category:Historical images was clearly in favor of depreciating "historical" in category names, and I've begun doing so with "old" as well.

The 'response' was as follows: (Enyavar): As suspected. There were seemingly three ignorant voices clamoring for deletion of the whole old maps category tree, which has millions of maps sorted into hundreds of thousands of subcategories. I don't think those three people have categorized any larger amounts of old maps.

In any case, the comments were before the April 2024 consensus discouraging the use of categorization based on concepts such as "historic" or "old." And even if such parallel categories are to be maintained in the coming year(s) for some purposes such as collection or indexing (which I'm not opposed to), that certainly isn't a basis for separating the particular groups of maps being organized here by shared subject matter into one set (but currently only those published after 1955, to be changed again in a couple weeks) - and then leaving the remainder scattered across dozens or even hundreds of potential drawers based on what years the relevant maps happened to have been published in. Not only does that seem crazy but my extensive efforts to assemble relevant maps by subject matter would be effectively gutted, so I would certainly have little if any interest in continuing them.

To Enyavar's credit, I've noticed that following the 2024 consensus, he has increasingly taken a newer tack, including in this more recent post from May 2025 on his user page: Consensus to remove maps by individual year:

(Enyavar): Per the principle with old maps, that the correct location is more important to categorize than the incidental year/month/day of publishing, I re-structured the "old maps of Kansas" by county depicted, unless they actually showed large portions or the whole state.

So the treatment of Kansas started to sound more similar to the treatment of France and other European countries that I've been working on (including the focus on "large portions or the whole state").

Even more pertinent was this one from July 2025 in Maps by Year:

(Enyavar): At least with maps, the exact year of creation is not a prime categorizing criterion (while still important metadata, sure).

Sure, "by year" is the easiest way by far to quickly subdivide large amounts of files, but that level of granularity has no advantage at all for users on Commons. All that you achieve, is having split up a lot of files (of the same type) by some arbitrary factor. In my opinion, you should instead subcategorize by the survey sweeps, which means matching the files by real content. The probably best approach: subcategorize by the geographical subdivisions that are covered in each map.

So overall, I believe that we increasingly agree in principle - which is part of the reason I've continued working on the related project. I do understand that it will be a big task to consider potential revisions of the larger categories - but if there's anything I'm sure of, it's that Enyavar is capable of large-scale recategorizations. I'll also be here to help and to consult in any way I can.

In the meantime, this is another reason that I didn't want to loosen the definition for the current categories referred to above. When they are essentially limited to maps showing entire countries, there are not that many relevant maps (even for major countries such as France or Germany). And it would certainly be illogical and unhelpful for the category showing Maps of France in the 16th century to specifically exclude the small subset that happened to also have been published in the same century. However, if regions, cities and towns were also included then I wouldn't want the categories to be effectively crowded or cluttered so that the main subject matter is distracted. I would therefore suggest that issue to be addressed in future - after there has been further discussion of the "old maps" categorization scheme. We can then also consider related issues in that context, such as whether the term "history" should be used and in what contexts. (Ty's Commons) (talk) 10:55, 12 December 2025 (UTC)

Summary and proposed next steps

1. Regarding the current framework:

For reasons noted above (in the preceding paragraph and in section A) I'll hold off for now on loosening the definition in the current categories in order to keep them as closely focused as possible on their key subject matter of countries. Since there are relatively few maps available, especially for earlier centuries, it makes it even more important that any relevant maps be gathered and presented together.

Once the country categories are set up, I'll turn more attention to retrieving additional maps of relevance - and of course would always appreciate Enyavar's and others' additions of relevant maps.

2. Regarding the parallel "Old maps" framework:

I'll look forward to future discussions regarding the "Old maps" categorization scheme. Since I fully share Enyavar's interest in better organizing our related maps - and it intersects with the current framework - I'd be happy to begin with a bit of offline brainstorming as we've done before once Enyavar has given further thought to possible approaches. I recall he's even considered a more radical 21st century approach in which maps from this century might potentially be categorized differently - the sort of "new" maps aproach that might well make sense. Perhaps we could then come up with a possible plan to be recommended in a separate Cfd directed to the issue. In any case I look forward to helping when and as I can. Best, Ty (Ty's Commons) (talk) 10:55, 12 December 2025 (UTC)

@Jmabel: - so here you have it. I still would argue that this thread must be strictly limited to the question(s) of the hatnote(s) on the history maps of Europe by century categories that I formulated above. Do you have a suggestion how to mediate the issue?

The other subjects that were raised are... not less important, but "parallel", to use your geometry metaphor. All the best, --Enyavar (talk) 15:56, 12 December 2025 (UTC)

@Enyavar: TBH, there is simply more here than I am willing to wade through in an area where I am not all that involved. It would astound me if the substance of this could not be expressed in a third this much text, or less.

I hope someone more active in this area than I will make that paraphrase.- Jmabel ! talk 19:06, 12 December 2025 (UTC)

@Jmabel: Sorry to put you through this, which was not my intention in the first place; but hopefully the basic categorization principles and overall approach makes sense, and I think Enyavar and I largely agree on that. I do think it was important to address the remaining technical points since he raised them; as well as lay out a path for going forward regarding the larger issue of the parallel framework (using publication date as subject matter as discussed in section C) - since he raised that as well with his point called "Missing differentiation" - and it has much broader implications as noted. Those are intended to be the subject of ongoing consideration as proposed in my final point. Ty's Commons (talk) 11:36, 13 December 2025 (UTC)

@Enyavar: You raised issues on the history maps that I think are more than fully addressed but also their intersection with the parallel "old" maps-by-date framework per your fourth item at the start of this discussion. Going forward, the ongoing considerations regarding that parallel framework (as discussed at C) are a much larger issue, as noted - so the final point above suggests a plan for future consideration. Ty's Commons (talk) 11:14, 13 December 2025 (UTC)

December 08

Why is Category:Mute (toki pona) not connecting to tok:nimi:mute as per the interwikis

I thought a bot was supposed to run this and create a wikidata item that links the article and category. Why is the connection not happening? Has this just not been a part of wikimedia commons for a long time? Immanuelle ❤️💚💙 (please tag me) 11:43, 8 December 2025 (UTC)

Neither of these two items seem connected to a Wikidata item but both are connected to each other, I didn't even know that was possible. But if this isn't done automatically, couldn't it still be done manually? ReneeWrites (talk) 20:07, 8 December 2025 (UTC)

It's the old way of connecting, predating Wikidata. Yes, it would be better to create a Wikidata item for this and link them in the normal present-day manner. - Jmabel ! talk 00:44, 9 December 2025 (UTC)

@Jmabel @ReneeWrites yeah it is the old way. Originally sites were all linked like this, and a bot connected them all to wikidata and removed the links. But for almost ten years the bots still ran. The reason I didn't create the wikidata items is that it will be very difficult to create all the items manually. Quickstatements does not work for it. Immanuelle ❤️💚💙 (please tag me) 05:08, 9 December 2025 (UTC)

If there is no functional bot, is there any way to see which pages do have the legacy interwiki connection links? Not even searching for insource:"[[tok:" works (and this would only show pages of that particular language). Maybe Allforrous knows more(?) Prototyperspective (talk) 10:57, 12 December 2025 (UTC)

I believe the following regex-based search should work: insource:/\[\[[a-z]{2,3}(-[a-z][a-z])?:[^\]]+\]\]/gm. But I imagine that is enough of a complex regex to put some detectable burden on the search engine. At the very least, you'd want to narrow it to "Category" space so it doesn't waste time searching through file pages. - Jmabel ! talk 19:22, 12 December 2025 (UTC)

December 09

Does en:WP:NBZ apply for Commons? (in regards to South Tyrol/Südtirol/Alto Adige)

I just reverted a category renaming from Category:Gerichtsplatz Bozen to Category:Piazza del Tribunale (Bolzano) because it changed the language name from German to Italian, and I knew this would likely be a controversial change in South Tyrol. I talked to User:Yeagvr about it and they said they applied en:WP:NBZ to rename the category. So I'm wondering if that is a policy on Commons and what should be our general principle on category names in South Tyrol/Südtirol/Alto Adige? Abzeronow (talk) 00:35, 9 December 2025 (UTC)

Comment: I reverted some of User:Yeagvr's changes of German language categories to Italian language and informed him that (at least on the English wiki) we adhere to en:WP:NBZ. Example: I moved the category to Category:Hydroelectric power station Töll (Algund) after he had moved it to Category:Hydroelectric power station Tel (Lagundo). I did not revert his moves related to the city of Bolzano, as per WP:NBZ that city has a Italian majority and hence uses Italian language (e.g. he moved Category:Oswaldpromenade (Bozen) to Category:Passeggiata di Sant'Osvaldo (Bolzano)). I would also like to know what the policy on commons is for names in South Tyrol. So far I have applied WP:NBZ and upheld that, e.g. when I requested (still pending) that Yeagvr's move of Category:Tschögglberg to Category:Monzoccolo be reverted as per WP:NBZ the four municipalities on the Tschögglberg are 95% to 98% German speaking, hence on the English wiki everything associated with them is in the German language. Thank you, Noclador (talk) 10:53, 9 December 2025 (UTC)

But we could have category redirects in the minority languages, I think. Nakonana (talk) 16:33, 9 December 2025 (UTC)

Yes. - Jmabel ! talk 19:23, 12 December 2025 (UTC)

Government agencies and acronyms

When titling files, descriptions and categories related to US government agencies is it preferred that we use the full name or acronyms?

Examples being:

• FBI/Federal Bureau of Investigation
• ICE/Immigration and Customs Enforcement
• DoJ/Department of Defense

etc Trade (talk) 13:40, 9 December 2025 (UTC)

Per Commons:File naming#Clear, ...it is allowed to use well-known acronyms and initialisms such as NATO, so long as other parts of the name provide sufficient information to identify the subject.... I think acronym FBI is well-known enough, but ICE and DoJ may mean different things other than the US agencies, so you may want to use the full name if the rest of the file name doesn't have enough context. Thanks. Tvpuppy (talk) 14:34, 9 December 2025 (UTC)

Seconding Tvpuppy. When I see "ICE", I'm thinking of German bullet trains (aka InterCity Express, see File:ICE-Logo.svg, Category:ICE train services, Category:ICE network maps etc.). So, keep the international community of Commons in mind. People around the world might know what NATO is, and they probably have heard of the FBI / CIA / NSA in the news or in American movies, but... ICEs are German trains and I wouldn't have a clue what DoJ is if you hadn't written it out (and even after you wrote it out I might still question whether I deciphered the acronym correctly, because, why is it DoJ instead of DoD?). Nakonana (talk) 16:18, 9 December 2025 (UTC)

Yes, @Nakonana that is an error. Department of Defense = DoD or DOD, and DoJ or DOJ = Department of Justice. -- Ooligan (talk) 20:13, 9 December 2025 (UTC)

@Trade, I agree with @Nakonana to "keep the international community of Commons in mind."

Many citizens of the United States are also unfamiliar with these acronyms used in your recent uploads:

HSI

FUGOPS

ERO

Some are found here: Category:Media without a license as of 9 December 2025

Please, use the full names of the U.S. Government agencies. and their separtely named Departments to help searches and categorization. Thanks, -- Ooligan (talk) 10:24, 11 December 2025 (UTC)

"HSI" stands for "Homeland Security Investigations" and the people working for them are officially called "HSI criminal investigators"

Is "HSI criminal investigators" acceptable for you? Trade (talk) 13:11, 11 December 2025 (UTC)

@Ooligan: --Trade (talk) 13:41, 11 December 2025 (UTC)

Please use full names as suggested by @Nakonana. I note that @Tvpuppy's quotation from Commons:File naming#Clear is about NATO- an internationally recognized organization. Domestic U.S. Government agencies and their sub-divisions are not likely known internationally. Since the Commons project is international, please avoid the use acronyms. It can be used together with the full name to aid searches and understanding. For example: U.S. Immigration and Customs Enforcement (ICE)

You may already know that,

FUGOPS = Fugitive Operations of the U.S. Department of Homeland Security and

ERO = Enforcement and Removal Operations (ERO) of the U.S. Immigration and Customs Enforcement (ICE). This acronym is also shared by the U.S. Internal Revenue Service (IRS) for their Electronic Return Originator (ERO) related to eFiling tax returns. One more reason to use full names instead of acronyms.

IPR = National Intellectual Property Rights Coordination Center

Perhaps, when you have time, you will change the files names of your recent U.S. Immigration and Customs Enforcement (ICE) Flickr uploads which include, IPR, ERO, FUGOPS and of course, ICE. Thanks again for asking your questions here. Respectfully, -- Ooligan (talk) 21:19, 11 December 2025 (UTC)

What about the United States Border Patrol? Is "United States Border Patrol agents" appropriate? Trade (talk) 09:09, 12 December 2025 (UTC)

For file names local acronyms are fine as there are unlikely name clashes. For categories the full name should be used. A detailed description should contain both for searchability. GPSLeo (talk) 18:31, 12 December 2025 (UTC)

Yes. -- Ooligan (talk) 17:59, 12 December 2025 (UTC)

There are a few, though, where I'd go the other way. FBI, NASA, and NOAA in the U.S.; ONCE in Spain; CERN in Europe: all of these are far better known by their initialisms and acronyms than by their full names. I'd venture that in all these cases, most people who know these organizations couldn't quickly tell you the full name (maybe the FBI, but not the others). - Jmabel ! talk

Would it be worthwile to just have a list of preferred acronyms somewhere?--Trade (talk) 21:59, 12 December 2025 (UTC)

Not everything needs to be mandatory or forbidden. Length of filename can also be a consideration, and we really do allow a lot of latitude in naming files. I've tended toward longer filenames over time, but if I'm just indicating where a particular artifact was photographed, I'm still more likely to write "MUHBA" in a filename rather than "Museu d'Història de Barcelona", especially since the former is commonly used in English, Spanish, and Catalan, whereas the latter (the official name) is specifically Catalan.

I think it might be useful to have general advice that unless an organization is better known by its acronym/initialism it is better to spell it out, but I think we have to leave it to people to decide which way they go in any particular case. - Jmabel ! talk 00:01, 13 December 2025 (UTC)

Its very easy for people familiar with an acronym to use it, but acronyms are generally a problem for those from other cultures. Can we at least make sure that there is an explanation for all the acronyms? Even something like FBI or NHS may mean something else. Rathfelder (talk) 13:23, 15 December 2025 (UTC)

December 10

Notifications

I made a deletion request today and now I receive reply notifications every time a new deletion request is added to Commons:Deletion requests/2025/12/10. The same thing happened when I submitted a request the other day, but it has never happened before then.

Is there any way to stop and prevent this?

Sinigh (talk) 20:02, 10 December 2025 (UTC)

Same with me, unsure why adding DR nominations to the daily Commons:Deletion requests list now automatically subscribes you to the section, which means I have to click "Unsubscribe" each time when I added DRs to the list. I'm not sure what's the cause for this, but maybe someone else will know what has changed recently. Thanks. Tvpuppy (talk) 20:45, 10 December 2025 (UTC)

The default in special:preferences for automatically subscribe me to things i comment on, was recently changed, so its probably related to that. Bawolff (talk) 20:53, 10 December 2025 (UTC)

There seems to be a bug in the implementation of phab:T295090. I have a huge problem with notifications on every archived mass message sent by me. GPSLeo (talk) 20:57, 10 December 2025 (UTC)

Had the same problem. At the top of the page there is another [unsubscribe] button. If you click that, the notifications stop. Prototyperspective (talk) 23:26, 10 December 2025 (UTC)

Thanks! I don't know what selective amnesia made me forget about that button.

I suppose it's still better for users not to subscribe to those pages by default. Sinigh (talk) 08:05, 11 December 2025 (UTC)

This is due to the subscribe by default setting in the preferences. Are you asking for a way to specify pages to exclude from this behavior? If so, maybe a phabricator code issue would be good so that users can specify the deletions page or that page is by default excluded. Prototyperspective (talk) 10:10, 11 December 2025 (UTC)

The daily DR pages should definitely be excluded by default. That many notifications won't serve any meaningful purpose for most users.

Even with automatic subscription activated, this wasn't an issue before, so something must have been changed recently for this to start happening.

Sinigh (talk) 11:19, 11 December 2025 (UTC)

It's even worse on mobile browser because you don't see the "unsubscribe" button unless you switch into desktop mode. I was already aware of the issue since I had seen this discussion here, but it still took me several minutes just now to figure out how to unsubscribe from the December 13 deletion nominations after I had started a DR. Nakonana (talk) 12:50, 13 December 2025 (UTC)

 Comment, there's a related discussion at Commons:Village pump/Technical#Receiving reply notification when subsequent DRs are added to daily page. Thanks. Tvpuppy (talk) 17:08, 14 December 2025 (UTC)

December 11

Unsure how copyright is applied or if it is

I have found photos of Joanne Segal Brandford's art that I am hoping to be able to use for her article. The art pieces in the photos range from 1967 to 1988 and they are not/never were copy-written (conclusion after search through the different copyright databases and speaking to her friends and family). However, I don't know who took the photos or when the photos were taken. Is the copyright that we care about the one for the art itself (in this case it would be public domain) or do I need to figure out the copyright status of the photo? Thank you in advance for any assistance. Snugglebuns (talk) 18:23, 11 December 2025 (UTC)

• I see you have uploaded File:Bundle by Joanne Segal Brandford.jpg. Photographs of 3D works have their own copyright, and you will need permission from the person who took the photo, in the form of a free license or a public domain dedication. In addition, her artwork may fall under exceptions in US copyright law if it was published before 1989 and never registered for copyright. Make sure you annotate this on the file page, or it is liable to be deleted. If you have communication with her heirs, it might be best to have one of them write an email to COM:VRT confirming the status. -Nard (Hablemonos) (Let's talk) 18:55, 11 December 2025 (UTC)

  That picture is one that was taken by the Smithsonian because that piece is in their collection, the pictures I'm talking about are her other pieces that there aren't photos of anywhere other than in books. Snugglebuns (talk) 19:17, 11 December 2025 (UTC)

  Well, and the scans that I have but those aren't really helpful. I will see if I can get her son to email. Snugglebuns (talk) 19:18, 11 December 2025 (UTC)

  Works (in this case a photograph) by the Smithsonian are not automatically in the public domain. - Jmabel ! talk 20:11, 11 December 2025 (UTC)

  Mainly because they are not always made by government employees. For example, they definitely hire outside photographers. - Jmabel ! talk 19:38, 12 December 2025 (UTC)

• I can see the confusion for the "bundle" image. Usually the SI has the license on the objects page for the image, but it is missing in the metadata and on the page. https://www.si.edu/termsofuse --RAN (talk) 19:18, 11 December 2025 (UTC)

  How do I fix it? Or should I just go ahead and mark it for deletion just to be safe until I can talk to her son again? Snugglebuns (talk) 19:23, 11 December 2025 (UTC)

  • I don't think this is an emergency, but you actually have two copyrights to clear here. The Smithsonian didn't mark this as CC-0, but that may be only because the underlying work is still copyrighted. Once you can sort out the permissin from her son (which we definitely need), you'll probably need to contact the Smithsonian and ask them if they agree that their contribution to this is also CC-0 or PD. - Jmabel ! talk 19:43, 12 December 2025 (UTC)

Correcting errors

We house thousands of news articles not transcribed at Wikisource. Do we have a standardized way to point out errors of fact or typos? RAN (talk) 19:25, 11 December 2025 (UTC)

{{Fact disputed}}? (maybe not, because if it's in the file itself, it is something that can never become "resolved".) Or just part of the description. - Jmabel ! talk 20:13, 11 December 2025 (UTC)

For "errors of fact" in the file content, not title or description, it would be {{Factual accuracy}}. Prototyperspective (talk) 22:40, 11 December 2025 (UTC)

Very good, thought that seems a bit strong for a typo, unless it is in a date, proper name, etc. Should we maybe have something "milder' for things like that? - Jmabel ! talk 19:45, 12 December 2025 (UTC)

Yes, it's not suited for typos. These are currently usually pointed out on the talk page (usually with the user forgetting to ping the uploader which I do whenever I see it). I don't think there's a template or standardized way yet – maybe {{Typo}} could be edited (or moved) and that template be used for that. Prototyperspective (talk) 19:54, 12 December 2025 (UTC)

It looks to me like the only page making any meaningful use of {{Typo}} is File:Utf8test.png. I'm inclined to "subst" it there and then repurpose the template. - Jmabel ! talk 00:15, 13 December 2025 (UTC)

Pinging @Tuvalkin. - Jmabel ! talk 00:18, 13 December 2025 (UTC)

I had even forgotten about that one, thanks for pinging. That {{Typo}} is a formatting template that merely adds wavy red underline to any text. I should have categorized as such — and if I had then maybe it would have met wider use. I renamed it and altered that singe use to match, so please go ahead at repurposing {{Typo}}. -- Tuválkin ✉ ✇ 13:53, 13 December 2025 (UTC)

• I have been adding the text twice, once with the typo and [sic] and a second time corrected, so that someone searching for the correct spelling will find it, and I mark the text as "corrected text". If an error of fact, I will leave a note explaining the error. It seems like we have no standardized way, like Wikisource. Wikisource leaves all errors in place and the error can be discussed in the notes section. --RAN (talk) 02:38, 13 December 2025 (UTC)
  • @Richard Arthur Norton (1958- ), Prototyperspective, and Tuvalkin: New Template:Typo available; test cases at Template:Typo/test, feel free to add more. First time in a while I've coded up a tricky template, took longer than it used to, out of practice. Let me know if there is anything that needs tweaking (more arguments, etc.). Also if you can think of additional appropriate categories for the template, please add them (as NOINCLUDE, of course, unless your intent is to categorize the pages where it is used). - Jmabel ! talk 22:39, 13 December 2025 (UTC)

December 12

Virus

On file File:The-Drowsy-One-Friedrich-von-Amerling.jpg, I was searching sources on "Source/Photographer", look what happens! How to fix that ?--Io Herodotus (talk) 10:20, 12 December 2025 (UTC)

What happens? If there's some issue on the site: if the site is malicious, I suggest you replace the source page with either an archived version in Wayback Machine or another site via image reverse search. (For me it only shows "You’ve enabled HTTPS-Only Mode for enhanced security, and a HTTPS version of www.artclon.com is not available.") Prototyperspective (talk) 11:00, 12 December 2025 (UTC)

Archived versions are the same. The thing is, I don't know where to find a proper source. Io Herodotus (talk) 12:50, 12 December 2025 (UTC)

Well, on https://web.archive.org/web/20130415062657/http://www.artclon.com/artist/friedrich-von-amerling/ you're not bombarded with Chinese-lettered porn site adverts, but that's still something not really serious, trying to offensively sell stuff. Porn-banner filled sites aren't malicious per se, but you should exert good care (and use script blockers: Firefox + NoScript, for instance), as it's at least a sign that the webmaster doesn't care about the security of his adverts. Artclon may have been subject to a domain sale, hence it's not a source anymore. Regards, Grand-Duc (talk) 13:10, 12 December 2025 (UTC)

Shouldnt we have a template for hijacked domains? The dead link template doesnt make sense since the link still works Trade (talk) 00:35, 13 December 2025 (UTC)

I'll try to import en:Template:Usurped. It will still need internationalizing, though. - Jmabel ! talk 01:07, 13 December 2025 (UTC)

Doesn't import simply (hard to kill the link); working on it. - Jmabel ! talk 01:30, 13 December 2025 (UTC)

Try what I have at {{Usurped}}. You can test it with Template:Usurped/testcases. I'd really be happier if there were a way to kill mediawiki's link to the usurped page, but I could not work out a way to do that. At least this now warns. Also, as I said above, internationalization would be good. Please feel more than free to try to improve this. - Jmabel ! talk 01:52, 13 December 2025 (UTC)

December 14

Files under wrong license?

I came across some files like File:Am-tuat 025.jpg which have the wrong license. You can't "only" license a file for Wikimedia Commons, that's against COM:L. However they can be converted to PD-Scan right? —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 15:29, 14 December 2025 (UTC)

@Matrix: Yes. ReneeWrites (talk) 18:30, 14 December 2025 (UTC)

Correct. This license statement should be reviewed (and probably removed) in all instances where it appears - most of the texts hosted by Sacred-Texts are in the public domain. Scanning those texts does not create a new copyright which Sacred-Texts can assert. Omphalographer (talk) 19:49, 14 December 2025 (UTC)

December 15

Are images that were taken from Flickr, but no longer hosted there, eligible for speedy deletion?

See for example: File:Family doing laundry outdside (14071772716).jpg. I believe we addressed this at least once before. When Flickr threatened to delete all your files unless you paid the $89 USD annually, many users deleted accounts as protest, or deleted images to stay under the free limit. --RAN (talk) 00:47, 15 December 2025 (UTC)

No, I don't think they're eligible for speedy deletion in that situation, unless the license was never reviewed. Isn't that partly the point of the FlickReviewer bots, to ensure that if a Flickr account is deleted or the content is deleted (or if maybe one day Flickr goes away entirely), we have evidence that the content was once published there under a free license? 19h00s (talk) 01:00, 15 December 2025 (UTC)

The Wayback Machine has a capture of that page from 2022. Sam Wilson 01:13, 15 December 2025 (UTC)

• The licenses need to be changed, since these are a republishing of historic images, but I don't see them as eligible for speedy. --RAN (talk) 01:17, 15 December 2025 (UTC)
• Of course not. This is completely against the very narrow range where a speedy deletion is performable. I'll remove it.

Even considered as a DR, the fact that it's no longer easily verifiable today doesn't matter. This is why we have the FlickrReviewer bot, to check these things in a trustworthy manner at the time when they are uploaded. Andy Dingley (talk) 01:41, 15 December 2025 (UTC)

I reverted the speedy, but it was immediately re-added. See Commons:Deletion requests/File:Family doing laundry outdside (14071772716).jpg Andy Dingley (talk) 02:06, 15 December 2025 (UTC)

Seems like there are some deeper issues with the Flickr account in question (although I think that should've been clearly linked/explained in the speedy tag rationales). 19h00s (talk) 02:11, 15 December 2025 (UTC)

• They just need a little research . Can someone check if more were nominated for speedy? --RAN (talk) 04:38, 15 December 2025 (UTC)
• Speedy? No. But certainly a DR for that image is reasonable. The license indicated could probably only be valid if the uploader either is very old or had inherited the rights to the photo, and the fact that it looks most likely to be rephotographed in a museum setting makes the latter unlikely. Given that all that was validated at time of upload is that this (unlikely) license was offered on Flickr, we are basically looking at a photo that lacks a plausible license claim, might be PD (but we have no evidence it is), and probably is going to end up deleted unless someone can work out who took it when and in what country (probably U.S., though certainly could be Canada) and when, and what might be its publication history. - Jmabel ! talk 07:23, 15 December 2025 (UTC)

  If you search on simpleinsomnia, it's pretty clear that on their Flickr account they stuck the same license on old works by a lot of photographers; they could not readily have been heir to all of them, and however old they are some of these go too far back to be their own work. The works involved include cabinet cards (always made by professionals), photobooth/strip photos, images in many different formats, etc. - Jmabel ! talk 07:30, 15 December 2025 (UTC)

  @Richard Arthur Norton (1958- ): You could see if other photos of theirs are tagged with "No source since" by searching for "simpleinsomnia" insource:"No source since". It actually looks like an awful lot are tagged that way (191 files). I'm about to go to bed, but probably at this point the best solution is a batch edit with VFC to change these to a regular deletion, which can then be procedurally closed as "keep" because they are pretty diverse and some are almost certainly PD, and then if someone wants to nominate them for deletion, they can do this right (not batching up unrelated photos).

  Pinging @Phillipedison1891 as a courtesy, because it looks to me like he made a mess here. @Phillipedison1891: the absolutely simplest thing is if you would revert your own "No source since" speedies here and start nominating these one-by-one or in reasonable groups. I believe you are the only person who can simply revert rather than turn these immediately into DRs. - Jmabel ! talk 07:40, 15 December 2025 (UTC)

  I apologize for any disruption I inadvertently caused, but reading the relevant policy, I thought the {{No source since}} tag was appropriate. This Flickr account always, always, always just uploads old-looking photos from private sources (antique shops I suspect) without any additional information. I've spot checked quite a few with Google Lens and TinEye and the only matches I can find are those that cite back to that Flickr account. You can see this deletion request where I disclosed this and offered to start a standard deletion request instead. Since this has proven controversial, I have done so. Phillipedison1891 (talk) 15:33, 15 December 2025 (UTC)

• I don't want to get involved in an edit war, but the deletion of the speedy tags are being reversed. See for example: File:Young African American boy standing on a porch (16487759743).jpg. See above for the rationale, that the Flickr account does not count as a source. The Flickr account scanned unique historical images, and is no longer active. I agree that the licenses need to be changed, if they are PD-US or, if they circulated prior to 1930 or never had a copyright registration or renewal prior to 1964 (PD-US-not renewed). I don't believe adding "no source" is correct. We allow, and even encourage people to scan historical images in their collections. The template is {{Photo scan}}. I think this would have been better by starting with a question here at the pump, rather than jumping to speedy deletion. --RAN (talk) 16:14, 15 December 2025 (UTC)
• It looks like all have been migrated to Commons:Deletion requests/Files on User:Phillipedison1891/Simpleinsomnia batch delete in a massive list. One request above was "not batching up unrelated photos". --RAN (talk) 17:38, 15 December 2025 (UTC)

App says I am blocked

If I try to upload using the Commons app on Android, it says I am blocked from editing.

I can edit without issue in my browser, on the same device.

Does anyone else see this issue? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:56, 15 December 2025 (UTC)

Very weird. But your log says you are not banned :) --PantheraLeo1359531 😺 (talk) 12:46, 15 December 2025 (UTC)

Have you tried to log out and then log in again in the app? Ruslik (talk) 19:13, 15 December 2025 (UTC)

No, but when I tried again later in the day, it worked. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:40, 16 December 2025 (UTC)

@Pigsonthewing I don't think you are IP exempt ? Because lots of IP addresses in the mobile space are permanently blocked, either locally or even at the wikimedia global level. Only IP exempt will do to get around that, not matter how long you have been on the website. —TheDJ (talk • contribs) 09:59, 16 December 2025 (UTC)

I was at home, on my own broadband connection. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:39, 16 December 2025 (UTC)

December 17

sr-ec Language Tag in Captions

I noticed this change log in my Watchlist: "Added [sr-ec] caption: Слика "Агонија" (1878), Аугуст Фридрих Шенк". The problem is sr-ec is not a correct language tag; if I understand it correctly, the fully correct tag for Ekavian Serbian would be sr-ekavsk, though sr-Cyrl-ekavsk would be useful for tagging the Cyrillic alphabet. (I'm not confident in this, but AI tells me that the ekavsk is irrelevant here, that sr-Cyrl-ijekavsk would be exactly the same, so probably the best tag would be sr-Cyrl?)

Beyond the problems with the language, I don't see what generated it and how to fix it, as it's part of a caption. Is this an internal thing, where sr-ec is part of a list that was picked off of, or was it an external thing, where sr-ec was typed in by the user? If the latter, where do I fix it? If the former, ergh, I don't know that I want to mess with it, but it really should use standard language tags.--Prosfilaes (talk) 01:35, 17 December 2025 (UTC)

Please see mw:Project:Language policy#Language codes or mw:Manual:Language#Names.php, language codes (e.g. sr-ec) are set internally and can be seen here. Thanks. Tvpuppy (talk) 02:15, 17 December 2025 (UTC)

Also, there's a related discussion about renaming "sr-ec" to "sr-Cyrl" in phab:T117845. Thanks. Tvpuppy (talk) 02:23, 17 December 2025 (UTC)

Should we be restoring information that we know is wrong?

I do not want to get into another edit war, per the complaint "Are images that were taken from Flickr", about restoring speedy deletion tags, that I removed. Should we be restoring information that we know is wrong? See: this edit. We know that the date is incorrect and that the author is incorrect, that is why it is up for deletion. Should we be attempting to fix these obvious errors, or should the errors remain so that the image has to be deleted? RAN (talk) 03:03, 17 December 2025 (UTC)

Both versions (before and after that edit) look problematic to me.

• Edit clearly restores a wrong date and a license we know is invalid. Both bad.
• State prior to edit shows FlickreviewR activity that is unrelated to the PD "license" tag. Also:
  • I would never quote ChatGPT as a source for dating photos. I work with a lot of older materials (mostly for Seattle and Alaska), and I've never found any generative AI to be much better at that than a human who is used to looking at old pictures. It's probably not far off, but as far as I'm concerned, that's on about the level of citing "my cousin Bob". Actual evidence of what year that model of radio or headphones were made would mean something, in that it would give at least an earliest possible date. (Edit removed this.)

I disagree, ChatGPT has access to billions of dated images that "cousin Bob" does not have access to, not the brain capacity to digest billions of images. ChatGPT does not just give a date, it gives the rationale it used to come up with the date. --RAN (talk) 03:36, 19 December 2025 (UTC)

• • What is the point of linking three sites as "other versions" where two of them explicitly credit the same Flickr user as their source, and the other is dated 2025 so it presumably got the photo either from us or from that Flickr user (it gives no credit). (Edit removed this.)

I disagree, "other versions" sound like the perfect place to show where the image is in use. --RAN (talk) 03:36, 19 December 2025 (UTC)

- Jmabel ! talk 06:18, 17 December 2025 (UTC)

Writing a bot

Hello, I having an idea of a bot, here how it works:

1. Get a files (SDC) where this match:

creator (P170)	some value edit Wikimedia username (P4174) <value here> 0 references add reference
		add value

Then change the "some value" to a item that have the same value of Wikimedia username (P4174) in the qualifer.

Could it be possible, even this type of statement match around ~40 million files? DinhHuy2010 (talk) 03:21, 17 December 2025 (UTC)

Can you explain what you're specifically trying to accomplish here? Omphalographer (talk) 03:51, 17 December 2025 (UTC)

Replace the "some value" with a item.

That item must have the same value of Wikimedia username (P4174) with the qualifer

Useful I guess for tracking purpose? DinhHuy2010 (talk) 03:58, 17 December 2025 (UTC)

@DinhHuy2010: I don't see what you think would be more useful, but that may be because I don't see what you are actually proposing. creator (P170) cannot take a string for a value; either you are ignoring that, or your wording is unclear. If the latter, could you show with a {{Statement}} what you propose this should end up looking like? - Jmabel ! talk 06:24, 17 December 2025 (UTC)

@Jmabel

For example, for Jimbo Wales

Before:

creator (P170) some value / Wikimedia username (P4174) Jimbo Wales

After:

creator (P170) Jimmy Wales (Q181) / Wikimedia username (P4174) Jimbo Wales

Either overwrite the statements or create a new statement and mark as preffered and the old statement as deprecated. DinhHuy2010 (talk) 06:48, 17 December 2025 (UTC)

So do this only if there is a Wikidata item for that user? I believe this has been proposed before, and there were people who had Wikidata items but did not want their Wikidata item tied that closely to their activity as a user. And, of course, most users do not have Wikidata items, and probably (in my view at least) shouldn't. - Jmabel ! talk 07:17, 17 December 2025 (UTC)

@Jmabel, proposed before? What does that mean?

Also "And, of course, most users do not have Wikidata items, and probably (in my view at least) shouldn't." does this mean?

Should I continuing to do this anyway? DinhHuy2010 (talk) 07:29, 17 December 2025 (UTC)

This is nothing we can decide on Commons. The rules for items for people are defined in the Wikidata notability policy. This does not include even the most active contributors here unless they have an identifier in external databases. It was discussed to have some kind U-items for users but the implementation was never discussed further. GPSLeo (talk) 09:04, 17 December 2025 (UTC)

I think the obvious solution here is to only do it for people with wikimedia username field set on their wikidata item. If someone doesnt want the association known then i guess it is their responsibility to make sure the association isnt set at wikidata. Bawolff (talk) 17:44, 17 December 2025 (UTC)

@DinhHuy2010: I'm not sure what is unclear to you about my meaning, but I'll try being more verbose. (1) This is not the first time that someone has proposed making this substitution; last time I saw it proposed, several users who have Wikidata items indicated that they would not want their Wikimedia account tied to their real-world identity. (2) The majority of people who upload photos here do not have Wikidata items for themselves as individuals and I believe that is entirely appropriate. Your example works only because Jimmy Wales (Q181) exists for Jimbo. To make this work in general, you have to have a Wikimedia item for every user who uploads. Or maybe the answer to your first question is "yes, do this only if there is a Wikidata item for that user and it is already tied to their account," in which case the rest of what I said is largely moot, though it does raise a different question: if there is a Wikidata item about you, is it possible to opt out of having your account tied to that Wikidata item, if someone else has a citation to document that you are the same person? - Jmabel ! talk 21:37, 17 December 2025 (UTC)

If the user has P4174 set they are already effectively connected. I certainly wouldn't advocate adding that to non-notable people against their will, but i feel like once its set the person is connected. Wanting to not be associated after that point is like uploading an image to commons but demanding it not be used on Wikipedia (to be clear, i dont know specificly what DinhHuy2010 is advocating for, but i would only advocate doing this for people who have an existing wikidata item with P4174 set, leaving the rest to use blank nodes (some value) as they currently do.) Bawolff (talk) 00:08, 18 December 2025 (UTC)

once its set the person is connected: so Commons:Harassment#Posting of personal information would not apply here? That seems wrong to me. - Jmabel ! talk 01:12, 18 December 2025 (UTC)

If someone posts personal information on their user page on another projet, and then it gets an interlanguage link from commons, is that a violation of the policy? As written technically maybe, but i think most people would think that is rediculous. I think this is a similar situation. Note that wikidata does have a policy (according to usage instructions at d:Property:P4174) that using the property to out people at wikidata will result in a block, so it shouldn't have personal information against people's wills. I think its important to respect people's privacy, but if they've voluntarily disclosed it on a wikimedia project, i dont see anything wrong with linking to it. Bawolff (talk) 03:35, 18 December 2025 (UTC)

This has been one of my pet peeves of SDC for a long time. Doing this not only makes sense for how commons ontology is set out, it also makes queries (especially aggregating queries) much more performant on blazegraph. So i think this is a really good idea. Bawolff (talk) 17:42, 17 December 2025 (UTC)

Wikimedia Foundation Product & Technology Initiatives for this Fiscal Year published

Hi all, we have published a list of initiatives that Wikimedia Foundation has decided to take regarding Wikimedia Commons.

Over this fiscal year, Commons has been the focus of several Product & Technology efforts addressing infrastructure scalability, contributor workflows, event organization, multimedia performance, and tool sustainability. These initiatives fall into four broad categories: Infrastructure & Platform Stability; Contributor Experience & Community Workflows; Multimedia & Data Modernization; and Safety, Governance & Responsible Use of Infrastructure.

Together, these initiatives reflect a combination of foundational engineering, contributor-facing product improvements, and long-term sustainability work that reinforce Commons’ role as the movement’s central media repository.

You can read more about them at this page. We are of course welcoming feedback on what you think might be some more initiatives we need to take. You can reply here or on this year's initiatives talk page. Thank you in advance! Sannita (WMF) (talk) 12:15, 17 December 2025 (UTC)

Respectfully, these initiatives (with the possible exception of video2commons work, and maybe the DB stuff depending on how you define "commons") are only tangentially related to commons. Bawolff (talk) 17:40, 17 December 2025 (UTC)

Category:Burials

for example Category:Burials at the Congressional Cemetery.

i think it makes sense to categorise graves/tombs of persons under a cemetery, but not the categories of those persons. RoyZuo (talk) 18:41, 17 December 2025 (UTC)

So you're thinking we shouldn't have categories for where people are buried, only categories like Category:Graves at the Congressional Cemetery that show the actual graves? I guess I can see that, because Commons deals with images, not abstract information. Maybe this is something that was carried over from Wikipedia. -- Auntof6 (talk) 20:39, 17 December 2025 (UTC)

 Support - yes, and those photos can be categorized under the person who's buried there, or under a dedicated category for their gravesite if there's many photos of that subject. Abstract relationships like "where is this person buried" don't need to be represented by Commons categories; Wikidata does a better job of that. Omphalographer (talk) 20:58, 17 December 2025 (UTC)

 Support. I think CfD is a better avenue to discuss this though (crossposted to the Village Pump to get more participants), rather than the other way around. --ReneeWrites (talk) 20:04, 18 December 2025 (UTC)

• Are we going to ensure that the data is already at Wikidata before losing the info? Are we going to create Wikidata entries for those without one? Are we going to create "Category:Grave of ..." for every image of a tombstone that we have? --RAN (talk) 03:29, 19 December 2025 (UTC)

  I would say "maybe" to creating the categories. We don't necessarily need a separate category for every grave, especially if we have only one image for it. -- Auntof6 (talk) 03:35, 19 December 2025 (UTC)

December 18

Small question

How can I delete one of my contributions? Benzekre (talk) 10:57, 18 December 2025 (UTC)

It depends on which type of contribution…an edit, or an upload, or an upload of a new or prior file revision, or a recent upload. Prototyperspective (talk) 15:26, 18 December 2025 (UTC)

@Benzekre: if, as I suspect, you are asking how to get a recently uploaded file deleted, you can tag it with {{SD|G7}}, and it will almost certainly be deleted. This is further explained at Template:My bad upload, if you want to understand a little better. If you are asking something else, then you'll have to be more specific. - Jmabel ! talk 21:21, 18 December 2025 (UTC)

Continuing notifications problem

I filed a deletion request just now, and I was subscribed to the whole December 18 deletion request page rather than just my own deletion request. This was posted here a couple weeks ago, but is still a problem. Geoffroi 18:13, 18 December 2025 (UTC)

See Commons:Village pump#Notifications. It's probably not something that can be solved on Commons's end. Nakonana (talk) 18:45, 18 December 2025 (UTC)

Would it help if I added Commons:Deletion requests to muted pages in notification preferences? Geoffroi 19:18, 18 December 2025 (UTC)

Probably not, because that isn't the page which the notifications stem from - it's the daily subpages like Commons:Deletion requests/2025/12/18. Omphalographer (talk) 19:56, 18 December 2025 (UTC)

December 19

What is this style of wearing a tie called?

What is this style of wearing a tie called? The tie goes over the collar, rather than under the collar. Cravats are a type of tie worn over the collar, but this looks like a standard tie. File:Frank E. Wade, New York Superintendent of State Prisons in 1916.jpg I added Category:Cravats, but not sure. --RAN (talk) 03:52, 19 December 2025 (UTC)

• That's called a stand collar, and it optionally paired with an attachable stiff collar for formal occasions (here is a modern reproduction[1]). Here's another example with tall detachable collars[2] The man in this picture is simply wearing his shirt without the additional collar, which was a common choice. -Nard (Hablemonos) (Let's talk) 06:11, 19 December 2025 (UTC)