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 thearchives; the latest archive isCommons: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, pleasedo not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Onlyfree content is allowed." This is a basic rule of the place, as inherent as theNPOV requirement on all Wikipedias.
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:
For questions aboutcopyright,technical matters, orhelp that does not relate to the general Commons community as well asproposals, please see the other discussion boards linked in the blue panel at the top.
It still only has few sites – do you know of any further ones? - Recently addedthis resource but it's mostly just German-language data graphics. It would be great if somebody could upload the graphics from there that aren't yet on Commons. Until now, doing so was just in my private todos but I may never get to uploading more of these. For an example, seeCategory:Meat Atlas which contains charts and maps about meat consumption (not just in Germany but also worldwide; translatable).
Seems likeEurostat could be added: according tothis pageThe copyright for the editorial content of this website, which is owned by the EU, is licensed under the Creative Commons Attribution 4.0 International licence. There probably are more sites like it and maybe somebody here knows of or can find more.
May be good to create aCommons:Batch uploading request for these if that's anyhow possible (and it's probably possible to scrape the sites in structured ways even if they don't have APIs). For Our World in Data, the batch uploading is done semi-manually/automatically via theOWIDImporter which is linked on that page.Prototyperspective (talk)12:03, 13 November 2025 (UTC)Reply
I've heard NOAA is another resource for charts but I could not find a page on their site for finding and/or searching these – does somebody know? There probably are quite a few more government agencies with lots of data graphics.Prototyperspective (talk)21:25, 19 November 2025 (UTC)Reply
Are there CCBY data graphics onhttps://observablehq.com and if so how to find/link them? There are many user-made charts I think and I don't know if there's a way to see CCBY-licensed ones. Same forTableau Public except that I have more doubts there's CCBY ones there.
Are there any data visualizations inhttps://data.worldbank.org/ that aren't also in OWID or in a more complete/up-to-date version in OWID? For example, if I try to uploadthis data visualization about prevalence of anemia in pregnant females as SVG I get this error in the UploadWizard (and also can't edit the svg in a text editor):This SVG file contains an illegal namespace "http://www.w3.org/1999/xhtml" and when I download it as PNG just a corner of the image is visible and for JPG it's entirely blanks. However, OWID has amap that I just uploaded for the year 2023 while this is for 2019. Since many OWID visualizations are based on WB data, I wonder if there's any WB visualizations that aren't also visualized via OWID software. For example, I've noticed that OWID maps are always at most at the country level but never at higher resolution than that so maybe this or another site has also such choropleth maps.
@Jidanni PerCommons:File types#MP3, MP3 are only allowed to be uploaded by users with the autopatrol (or higher) right. This restriction was introduced by aRFC on Commons, so this isn't something we can just "turn it off". So, please use another acceptable file type, such as ogg, or consider applying for autopatrol right atCOM:RFR. Thanks.Tvpuppy (talk)02:12, 4 December 2025 (UTC)Reply
I opposed it when it was introduced and still oppose it, most definitely for this user level. It would be different if it was auto confirmed (or extended confirmed like on some wikis). I do think this is a thing we should look at. We have very little between auto confirmed and image reviewer. We are missing something like extended confirmed, or better, established community member, based on contributions on other wikis. It would be good to have something that identifies experienced community members from experienced Commons users... —TheDJ (talk •contribs)13:06, 8 December 2025 (UTC)Reply
December 04
Community Wishlist – Voting open for Commons-related Wishes!
Latest comment:5 days ago5 comments3 people in discussion
Recently, voting was enabled in theCommunity 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 andvote 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
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 israther 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 enablethis script and usethe 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 ona 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:
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)Reply
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-makingaspects. 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 thingsdone / problemssolved. 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 themany 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 suggestedinnovations 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 thetop #1 wish of the Commons Technical survey, isa heavily-followed code issue, and was thetop #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 saidUnfortunately, 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, thendo 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 politicalaspects are underestimated (which imo would suggest that the impact of votes & discussions are also underestimated).Prototyperspective (talk)13:12, 5 December 2025 (UTC)Reply
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)Reply
@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)Reply
December 06
Lat/Lon: DD vs. DMS
Latest comment:5 days ago2 comments2 people in discussion
Maybe there should be a preference setting,that shows every coordinate pair, in the format preferred by the user.
Latest comment:12 hours ago14 comments3 people in discussion
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 compareItaly,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 toguide 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 thehistory subsection may be linked inCategory: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 followingAdditional 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...", butthis 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)Reply
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 beingshown 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 asWikimedia 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)Reply
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 !talk03:07, 8 December 2025 (UTC)Reply
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 tonot discuss the fourth+final issue here, becausethat 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)Reply
I generally agree withUser: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)Reply
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 asCategory: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., theAtlas of Poland (the history section of which tracks the territory that evolved into modern-day Poland) and the partially overlappingAtlas 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 asMaps 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 ofcountry 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)Reply
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 actuallyno 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)Reply
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. theCategories 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 inCategories 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 atOld 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 inMaps 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 arenot 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)Reply
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)Reply
@Jmabel: - so here you have it. Istill would argue that this thread must be strictly limited to the question(s) of the hatnote(s) on thehistory maps of Europe by century categories that I formulated above. Do you have a suggestion how to mediate the issue?
@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.
@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)Reply
@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)Reply
Uploading cubemap projections of 360 degree panoramas
Latest comment:5 days ago8 comments6 people in discussion
User:Sdkb recently requested I seek further discussion on this.
Recently I've been uploading cube map projections of 360 panorama images (phptospheres) as alternative versions of the image. Most of these images are currently in equirectangular format, which projects the entire 360 degree view into a single rectangle. This causes distortions similar to how a map of the earth is distorted as you cannot project a sphere on to a 2D rectangle without distortion, thus you can't really use the images directly unless you are doing so for artistic effect. Mostly they are used with{{Pano360}} to link to a viewer on toolforge. I've been uploading an alternative version of these images, where instead of one image they become 6, one for each direction - up, down, left, right, front, back (or up, down, north, south, west, east if you prefer).
The reason for doing this, is that the projected images are easier to work with on wiki without special software support. I view it somewhat similar to cropping an image for better use in an article. Like any derrivitave image, if the original changes the derrivatives would also need to be reuploaded. The six views can be used independently if applicable since they don't have distortion, however the main reason is that they can be joined together with templates to give an immersive view directly on wiki. Sometimes this is called cubeapping, because its as if your camera is inside a cube and these would be the faces of a cube.
Note, enwiki has a more complex viewer template that is better.
On english Wikipedia there is a gadget that provides a more interactive viewer. It does have some limitations though in that it doesn't support pinch to zoom or dynamic level of detail loading, but is quite a bit better than the pure wikitext commons template i used above. You can see it atw:Template:cubemap viewer. So far its been used on 34 articles. Its also been copied to fawiki and kowiki
Previously 360 panoramas were used on articles by having an external link to the panoviewer tool, but i think there is benefit to having a viewer directly in the article. It still links to the toolforge tool for a full screen view.
I'm very impressed with the cubemap viewer template you linked to, great job! I wonder though what's the reason the 360 panoviewer can't be placed directly in an article like the cubemap viewer?ReneeWrites (talk)20:23, 7 December 2025 (UTC)Reply
The basic answer is that I took this approach because all it involved was creating a template which i could do all by myself with no permissions or approvals, which is pretty freeing. The enwiki template does use a gadget, however that gadget was already approved to powerw:template:Calculator, so it already existed and was live. There's something to be said about the Wiki-way of just being bold, is very motivating.
To integratepannellum (That's the library panoviewer uses) there is basically two approaches. The first is proper integration with MediaWiki, which in the ideal world would be the best option.User:TheDJ has been on and off working on this for years (Seemw:User:TheDJ/panoviewer for his work). I'm a bit unclear how much he is still working on it in the present. Getting custom MediaWiki extensions deployed on Wikimedia is often very politically difficult as a volunteer contributor. Its possible, and people have done it, but its an exhausting, uncertain process, and WMF seems to be even more reluctant these days about that sort of thing than it was in the past. Anyways, I wish anyone pursuing that the best of luck, it is definitely the ideal outcome, but I also think its unlikely to happen any time soon, and I don't really want to be involved with the politics of getting something deployed, as that's not really the sort of thing I like to do. Maybe if it wins the community wishlist that would get some momentum behind it.
The second approach would be a gadget for specifically embedding pannellum. It would probably be a large gadget, historically that would have been less than ideal, but with the advent of category gadgets, maybe that's less of a concern now. Of course someone would have to make such a gadget which might be a non-trivial effort, but at the same time not super hard (There are some previous attempts at just iframing toolforge liked:MediaWiki:Gadget-Panoviewer.js however that is not really what i mean. I think a proper tool would embed the viewer directly in the page and not just iframe toolforge). I think panellum has a native "pyrimid" image format, which is what it considers ideal and the panoviewer toolforge tool converts images to that in the background. In gadget form that wouldn't be viable, but it seems like panellum also supports normal equirectangular images, just without as much support for zooming in.Bawolff (talk)03:33, 8 December 2025 (UTC)Reply
Just to give an update on the other route that Bawolff was talking about. The basic status is at:User:TheDJ/panoviewer. The tool works, but there are some downsides. Primarily... it's still an issue to deal with large resolution images. That really needs tiling (like the Panoviewer toolforge tool does), but adding a tiling service to Wikimedia is ... PAIN. Secondly, you need some support to override angles etc for when that is not correctly provided by the metadata of the image (pretty common) and ideally serve those up via some sort of private API or something. Either magic words or Wikidata properties are an option for that, but I haven't been able to work on that for a while. Lastly.. the quality of tools in this space is... very low. A lot of the libraries are more suited for special dedicated websites and not so much for bigger websites, that have higher demands on quality and maturity. However, the extension does work, I updated it and verified this two months ago. —TheDJ (talk •contribs)13:18, 8 December 2025 (UTC)Reply
Overall,{{Pano360}} has some very significant limitations, and I'd love to see us using more photospheres overall in Wikimedia projects, so I share the praise for the technical work improving the viewer.
That said, we also currently have very poor infrastructure in place for relating files to one another, which is already a concern with cropped versions, and creating a cubemap results in even more files than a crop (a six-fold increase rather than just a doubling). This has the potential to add substantially to Commons' maintenance burden, especially as the use of photospheres increases over time, since with a cubemap e.g. each additional category has to be added in six places rather than just one.
Trying to think in a future-facing way, I wonder whether adding cubemaps to all 20,000 photospheres on Commons would really make them more accessible to Commons users (in which case it's more justified), or whether we ought to stick to the seemingly more common equirectangular projection format, and focus on technical improvements to the panoviewer rather than the stopgap solution of a cubemap viewer. I don't have a strong enough view about that to !support or !oppose the creation of future cubemaps. But given the number of files affected I do think it's a topic that could use some discussion/attention from interested editors, so I appreciate Bawolff following up fromthe discussion on their talk page to bring this here.
To clarify, i support making new ones on an as needed basis, when a file is being used. I don't necessilary think doing this for every photosphere file makes sense. As you say its a ton of files and if its not being used in an article i don't think there is much benefit.Bawolff (talk)00:32, 8 December 2025 (UTC)Reply
Latest comment:1 day ago6 comments4 people in discussion
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)Reply
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)Reply
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 !talk00:44, 9 December 2025 (UTC)Reply
@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)Reply
If there is no functional bot, is there any way to see which pages do have the legacy interwiki connection links? Not even searching forinsource:"[[tok:" works (and this would only show pages of that particular language). MaybeAllforrous knows more(?)Prototyperspective (talk)10:57, 12 December 2025 (UTC)Reply
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 !talk19:22, 12 December 2025 (UTC)Reply
Latest comment:4 days ago3 comments2 people in discussion
Adoption of communication technologies, World
This cat has a problem that only a small fraction of categories has and it's not really a subject for a CfD: the category scope and title seems fine; it's just that there's many files on Commons that would belong into it but the cat is nearly empty.
Assuming there is indeed no better solution such as merging the cat somehow: could some other user(s) help populating it?
Yes; in this case of Internet statistics I think soon a subcat of that cat should become the subcat of the Statistics about communication and this is why I didn't link that cat as see also.
There's of course also other categories relevant to it where it needs some thought how they relate to each other (make it a subcat, add one of its subcats, create a new subcat and add it, or add files from there and only link cat as see also) such asCategory:Media statistics. Prototyperspective (talk)12:06, 9 December 2025 (UTC)Reply
December 09
Doesen:WP:NBZ apply for Commons? (in regards to South Tyrol/Südtirol/Alto Adige)
Latest comment:1 day ago4 comments4 people in discussion
PerCommons: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)Reply
Seconding Tvpuppy. When I see "ICE", I'm thinking of German bullet trains (akaInterCityExpress, seeFile: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)Reply
Please, use thefull 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)Reply
"HSI" stands for "Homeland Security Investigations" and the people working for them are officially called "HSI criminal investigators"
Please use full names as suggested by @Nakonana. I note that @Tvpuppy's quotation fromCommons: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)Reply
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)Reply
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
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 !talk00:01, 13 December 2025 (UTC)Reply
Formatting Wikidata query
Latest comment:1 day ago10 comments3 people in discussion
Hi, In the table ofPaintings by Wassily Kandinsky, how to format the result of the WD query so that it looks likethis instead of the current one. The external links should be within [ ] avoiding to create an oversized column. Also is the description really useful? It is always "painting by Kandinsky".Yann (talk)16:42, 9 December 2025 (UTC)Reply
This appears to be about the "described at URL" column, unless I've misunderstood the question. Current version appears not to have the "description" column, which seems reasonable. -Jmabel !talk20:03, 11 December 2025 (UTC)Reply
@Yann: If you want it to format just like [number]] you have to write[http://en.rusmuseum.ru/collections/painting-of-the-second-half-of-the-xix-century-beginning-of-xxi-century/artworks/siniy-greben/?sphrase_id=205947] instead of justhttp://en.rusmuseum.ru/collections/painting-of-the-second-half-of-the-xix-century-beginning-of-xxi-century/artworks/siniy-greben/?sphrase_id=205947 (that is, use square brackets). -Jmabel !talk20:08, 11 December 2025 (UTC)Reply
@Yann: I believe SPARQL has a capability where you can get formatting into the return, so the brackets you want would be part of the returned column. I believe you use CONCAT, but I'm not familiar enough with SPARQL to form the query myself. -Jmabel !talk21:30, 11 December 2025 (UTC)Reply
This section is resolved and can be archived. If you disagree, replace this template with your comment.Prototyperspective (talk) 22:04, 12 December 2025 (UTC)
Attention filemovers
Latest comment:4 days ago1 comment1 person in discussion
It's now the top wish in the Wishlist by votes. I also mentioned this wish inthe thread above which briefly summarizes some further listed wishes and includes links to see more Commons-related wishes. I'll mention that a key topic/need is not just filing wishes and supporting them, but also sufficient software development capacity so that (more) wishes are getting implemented such as viawhat's proposed here andhere. Thanks,Prototyperspective (talk)11:50, 11 December 2025 (UTC)Reply
Latest comment:11 hours ago9 comments6 people in discussion
I made a deletion request today and now I receive reply notifications every time a new deletion request is added toCommons:Deletion requests/2025/12/10. The same thing happened when I submitted a request the other day, but it has never happened before then.
Same with me, unsure why adding DR nominations to the dailyCommons: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)Reply
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)Reply
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)Reply
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.
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)Reply
December 11
P1/Sergt. Louis Gargano
Latest comment:2 days ago2 comments2 people in discussion
This section is resolved and can be archived. If you disagree, replace this template with your comment.Prototyperspective (talk) 11:04, 12 December 2025 (UTC)
Car identity to date image
Latest comment:2 days ago2 comments2 people in discussion
What part do you want to edit? The painter information is included fromwikidata, so it needs to be edited there. The description of the painting can be edited right in the summary, there's an edit button next to the summary heading. --talk16:43, 11 December 2025 (UTC)Reply
This section is resolved and can be archived. If you disagree, replace this template with your comment.Prototyperspective (talk) 11:04, 12 December 2025 (UTC)
Unsure how copyright is applied or if it is
Latest comment:1 day ago9 comments4 people in discussion
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)Reply
I see you have uploadedFile: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 toCOM:VRT confirming the status. -Nard (Hablemonos) (Let's talk)18:55, 11 December 2025 (UTC)Reply
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)Reply
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 !talk19:43, 12 December 2025 (UTC)Reply
Correcting errors
Latest comment:1 hour ago10 comments4 people in discussion
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)Reply
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 !talk19:45, 12 December 2025 (UTC)Reply
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)Reply
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 assuch — 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)Reply
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)Reply
@Richard Arthur Norton (1958- ),Prototyperspective, andTuvalkin: NewTemplate:Typo available; test cases atTemplate: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 !talk22:39, 13 December 2025 (UTC)Reply
December 12
Add a Like button to each image
Latest comment:1 day ago6 comments6 people in discussion
Having an "urge" for something is not a good reason. There was a wish in the Wishlist about this where you can see feedback and discussion about this idea:m:Talk:Community Wishlist/W108.
There is a way to "favorite" files publicly using a gadget or to download them into a private local folder. Engagement functionality / indicators for creators and uploaders are: 1. file uses (visible e.g. via the glamorous tool) 2. page-views or media views and 3. featured pictures and other community highlighting.Prototyperspective (talk)11:03, 12 December 2025 (UTC)Reply
You can thank people for edits, which includes the original edit of a file being uploaded. You can also create a gallery in your user space for images you like.ReneeWrites (talk)12:58, 12 December 2025 (UTC)Reply
There is a "Favorite" button which adds images to a personal gallery (and thanks the uploader, iirc). But you might have to enable that button in your settings (Gadgets).Nakonana (talk)17:39, 12 December 2025 (UTC)Reply
Virus
Latest comment:22 hours ago8 comments5 people in discussion
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)Reply
Well, onhttps://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 maliciousper 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)Reply
Try what I have at{{Usurped}}. You can test it withTemplate: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 !talk01:52, 13 December 2025 (UTC)Reply
December 13
List of "good" sources for PD works
Latest comment:32 minutes ago3 comments3 people in discussion
I seem to recall coming across a policy or guideline here with a list of institutional sources where we automatically accept content tagged as public domain, "no known copyright restrictions", etc. I can't seem to find it. Was I hallucinating?Phillipedison1891 (talk)17:01, 13 December 2025 (UTC)Reply
I think there is no such list. Generally all public archives, libraries and museums should have correct copyright information. Every institution of course sometimes has incorrect data in their database.GPSLeo (talk)17:28, 13 December 2025 (UTC)Reply
There are certainly some institutional sources, like the Internet Archive, which we know to be more unreliable than others. (In IA's case, this is because many of their holdings are unverified user uploads.)Omphalographer (talk)23:38, 13 December 2025 (UTC)Reply
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
![[ ]](/mt/?noimg=&dark=on&url=https%3a%2f%2fpanoviewer.toolforge.org%2f%23Panorama_360_of_Basilique_Saint-Patrick%2c_Montreal%2c_Quebec%2c_Canada.jpg){kind=link}
.jpg%26amp%3baction%3dedit%26amp%3bredlink%3d1){kind=link}
.jpg){kind=link}
.jpg){kind=link}
This section is resolved and can be archived. If you disagree, replace this template with your comment.Prototyperspective (talk) 22:04, 12 December 2025 (UTC)_body_returned_home_in_the_Jersey_Journal_on_January_14%2c_1949.png){kind=link}
.png){kind=link}
