Commons: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:
Purposes which do not meet the scope of this page:
Search archives: |
| Legend |
|---|
|
|
|
|
|
| Manual settings |
| When exceptions occur, please check the setting first. |
 A village pump in Burkina Faso [add] | |||||||||||||||
| |||||||||||||||
 |
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days. |
November 06
Data graphic resources?
Commons:Free media resources/Datagraphics is a relatively new page for databases with free data graphics like charts that could be uploaded to Commons.
It still only has few sites – do you know of any further ones?
-
Recently added this 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, see Category:Meat Atlas which contains charts and maps about meat consumption (not just in Germany but also worldwide; translatable).
--Prototyperspective (talk) 23:22, 6 November 2025 (UTC)
- Seems like Eurostat could be added: according to this page
The 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. - There also are a few files in Category:Data visualization by Statista – is there a way to search for the subset of files in Statista that are CCBY/CCBYSA?
- May be good to create a Commons: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 the OWIDImporter which is linked on that page. Prototyperspective (talk) 12:03, 13 November 2025 (UTC)
- 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)
- I just added CDC Data Dashboards, Visualizations, and Query Systems – it contains lots of useful visualizations not yet on Commons; maybe somebody can upload some of them
- See also Commons:Village pump/Copyright#Are World Inequality Database data graphics in the public domain? I think it has to be removed again.
- I'm sure there must be at least some more pages of US agencies who publish data visualizations and probably also some of other countries.
- Prototyperspective (talk) 15:52, 26 November 2025 (UTC)
- Well, I can't find and don't know of all the major resources myself. So far the page only has resources I found myself. Is there maybe a tool to scan top sources/websites of files in Category:Data graphics (especially of used files in it)? And I removed the World Inequality Database for the list and made it a permission request to ask for their data graphics to be put under a free license. Prototyperspective (talk) 00:22, 2 December 2025 (UTC)
- Added a few more: Klimadashboard (German-language data graphics about climate change & GHG emissions; as a result of a request at Commons:Permission requests), US-specific government resources (United States Census Bureau visualizations, U.S. Cancer Cases and Death Statistics, U.S. Mortality Data Dashboards, U.S. Bureau of Labor Statistics)
- Are there CCBY data graphics on https://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 for Tableau Public except that I have more doubts there's CCBY ones there.
- Are there any data visualizations in https://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 upload this 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 a map 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.
- Prototyperspective (talk) 22:04, 8 December 2025 (UTC)
- Well, I can't find and don't know of all the major resources myself. So far the page only has resources I found myself. Is there maybe a tool to scan top sources/websites of files in Category:Data graphics (especially of used files in it)? And I removed the World Inequality Database for the list and made it a permission request to ask for their data graphics to be put under a free license. Prototyperspective (talk) 00:22, 2 December 2025 (UTC)
- 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)
November 28
Video and audio plays
Hey All, we at Wiki Med funded software to record how many times a video or audio file has been played and how much of the file gets played. It is live for all users on EU WP currently.[1] Is this something the Commons community would be interested in?
To activate one needs to add to this MediaWiki:Common.js this script[2]. The code itself being here User:Yaron Koren/tmh-engagement.js
Doc James (talk · contribs · email) 03:15, 29 November 2025 (UTC)
- Interesting! How does this compare to the mediaviews tool? Example
- Also see the wishes Analytics missing on Wikimedia Commons and Add view count to videos in the Community Wishlist. Which stats MVC displays seems to be a topic on the talk pages. m:Wiki Loves Broadcast about Category:Videos by Terra X for example claims
Over 90% of [the more than 350 videos] have found their way into Wikipedia articles, raking in more than 3 million views a month
– is this statement false? Prototyperspective (talk) 00:17, 2 December 2025 (UTC)- User:Prototyperspective So the mediaviewer tool is simply listing the number of times the page with the video on it has been loaded. Please note that with lazy load this can be lower than the actual views of the page as on mobile the entire page may not be loaded and thus the video may not be loaded. It is not the number of times the video has had the play button hit. What we have built is the ACTUAL plays and than how much of the video is watched. Doc James (talk · contribs · email) 01:59, 2 December 2025 (UTC)
- I suspected this and also user(s) claimed this was the case, if I remember correctly, on the talk pages of the two linked wishes. However, I could never find any confirmation of this.
- It would be better if the media views tool explained this and I wonder why it doesn't. On the information page of file pages, it's linked to as "Mediaviews Analysis on Toolforge" and that title and the tool name suggest it's plays when it comes to audio & video files. Maybe the subheader at the tools page is supposed to explain it – it says "Comparison of media requests across multiple files".
- Thanks a lot for your involvement in getting this tool developed; I think the two wishes should get the status changed to 'In progress' and then once the tool shows play from all the projects and can be accessed from the info page from all or all big projects to 'Delivered'. I was slightly alienated by seeing various claims about x number of views of the public broadcast videos I mentioned (such as in the Q&A in this video and the WLB pages) as I suspected these numbers are inaccurate and would soon edit the pages to clarify that these are just the views of the articles and that we don't know the number of plays.
- If the tool only shows the plays originating from a few Wikipedias, it's not yet very useful – it really needs to show all or nearly all plays regardless of where the play originated.
- By the way, I hope that low view-counts for high-quality and educationally useful videos and audios (an example for the latter are spoken Wikipedia audios) will hopefully raise understanding of the importance of good indexing in Web search engines (e.g. until recently Google, didn't show videos in the Videos tab even when searching for the exact title of a video on Commons) as well as having a good modern audio player, better visibility of audio files like audio versions of Wikipedia articles, better linking to Commons on Wikipedia (category link and further media and direct linking to Commons file page), and other things like that. Seeing media playcounts can be motivating to contributors (note: I doubt many contributors and visitors will find the link if it will again only be on the Tools page). Prototyperspective (talk) 18:43, 3 December 2025 (UTC)
- Yup the tool is still under development. Activating it here on Commons would be useful. Will start an RFC eventually. Doc James (talk · contribs · email) 20:51, 3 December 2025 (UTC)
- User:Prototyperspective So the mediaviewer tool is simply listing the number of times the page with the video on it has been loaded. Please note that with lazy load this can be lower than the actual views of the page as on mobile the entire page may not be loaded and thus the video may not be loaded. It is not the number of times the video has had the play button hit. What we have built is the ACTUAL plays and than how much of the video is watched. Doc James (talk · contribs · email) 01:59, 2 December 2025 (UTC)
November 29
Is there a bot that adds old style interwikis to wikidata?
I made a lot of categories with interwikis with the intention of them being linked on wikidata. However I am concerned this might not actually work this way. Is there a bot like EmausBot that does the thing? Immanuelle ❤️💚💙 (please tag me) 10:00, 29 November 2025 (UTC)
- Specifically it is subcategories of Category:Toki Pona logograms by word which all have interwikis to toki pona wikipedia. Immanuelle ❤️💚💙 (please tag me) 11:06, 29 November 2025 (UTC)
- It is not working if it does exist Immanuelle ❤️💚💙 (please tag me) 09:58, 4 December 2025 (UTC)
December 03
MP3s are allowed.
Please turn off the warning. Jidanni (talk) 11:50, 3 December 2025 (UTC)
- @Jidanni: It's apparently restricted to users with autopatrol. -- Asclepias (talk) 12:45, 3 December 2025 (UTC)
- Maybe someone from the Mediawiki Foundation could turn it off? Jidanni (talk) 01:45, 4 December 2025 (UTC)
- @Jidanni Per Commons:File types#MP3, MP3 are only allowed to be uploaded by users with the autopatrol (or higher) right. This restriction was introduced by a RFC 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 at COM:RFR. Thanks. Tvpuppy (talk) 02:12, 4 December 2025 (UTC)
- @Jidanni: Can you discuss what kind of mp3s you wish to upload? Sound recordings can be tricky copyright-wise. Abzeronow (talk) 02:28, 4 December 2025 (UTC)
- At least someone should fix the tiny box in Phab:T411579 so people can read the message! Jidanni (talk) 06:45, 4 December 2025 (UTC)
- I guess the issue is that MediaWiki:Abusefilter-warning-mp3 is using table based layout Bawolff (talk) 22:53, 4 December 2025 (UTC)
- At least someone should fix the tiny box in Phab:T411579 so people can read the message! Jidanni (talk) 06:45, 4 December 2025 (UTC)
- 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)
- Maybe someone from the Mediawiki Foundation could turn it off? Jidanni (talk) 01:45, 4 December 2025 (UTC)
December 04
DEMO.MID
Good afternoon! I found this file titled DEMO.MID on the Olidata Recovery Disk for Windows ME, which I actually don't know what famous 90s MIDI software it came from... Could you help me? Thank you! DanielParoliere (talk) 12:32, 4 December 2025 (UTC)
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
- …
-
.png/330px-Proposed_audio_player_for_spoken_Wikipedia_(desktop_version).png)
How the audio player could look (bottom panel) after clicking play (desktop) -
audio player for a Spoken Wikipedia audio via audio-chapters (mobile) -
.png/960px-A_video_on_Wikimedia_Commons_appearing_in_the_Google_Videos_tab_(shown_after_2025_changes_by_Google).png)
Video on Commons now showing in Google (success) -
.png)
Opening an image on Wikipedia in a new tab or with this button does not show the Commons page
.png)
.png)
.png)
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:
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 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, 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)
December 05
favicon.ico too dark at night
https://commons.wikimedia.org/favicon.ico is too dark on dark themed browsers. Possibly due to transparency. Jidanni (talk) 03:23, 5 December 2025 (UTC)
- it just depends on which type of browser, like Opera, Brave, Firefox, Edge, etc. Because I use chrome, I have no problem with it. ₘₒd cᵣₑₐₜₒᵣ ✰ ʜᴀʙʟᴀ ⍟ コントリビューション 23:17, 5 December 2025 (UTC)
December 06
Lat/Lon: DD vs. DMS
Maybe there should be a preference setting, that shows every coordinate pair, in the format preferred by the user.
So if I write {{Location|24.17|120.72}} it will show up in DD, not DMS. Not just for Template:Location, but everywhere, and for all Wikimedia wikis too. Jidanni (talk) 01:32, 6 December 2025 (UTC)
- We have this on en.wp and like 6 people make use of it. I don't really think it is worth it. —TheDJ (talk • contribs) 12:57, 8 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)
Uploading cubemap projections of 360 degree panoramas
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.
As an example, consider, File:Panorama 360 of Basilique Saint-Patrick, Montreal, Quebec, Canada.jpg. In equirectangular projection it looks like
Splitting it up into a cube we get six images like so:
.jpg)
|
|||
.jpg)
|
.jpg)
|
.jpg)
|
.jpg)
|
.jpg)
|
We can then combine them in to a unified view
.jpg/960px-Panorama_360_of_Basilique_Saint-Patrick%2C_Montreal%2C_Quebec%2C_Canada_(up).jpg)
.jpg/960px-Panorama_360_of_Basilique_Saint-Patrick%2C_Montreal%2C_Quebec%2C_Canada_(back).jpg)
.jpg/960px-Panorama_360_of_Basilique_Saint-Patrick%2C_Montreal%2C_Quebec%2C_Canada_(left).jpg)
.jpg/960px-Panorama_360_of_Basilique_Saint-Patrick%2C_Montreal%2C_Quebec%2C_Canada_(front).jpg)
.jpg/960px-Panorama_360_of_Basilique_Saint-Patrick%2C_Montreal%2C_Quebec%2C_Canada_(right).jpg)
.jpg/960px-Panorama_360_of_Basilique_Saint-Patrick%2C_Montreal%2C_Quebec%2C_Canada_(down).jpg)
![[ ]](https://panoviewer.toolforge.org/#Panorama_360_of_Basilique_Saint-Patrick,_Montreal,_Quebec,_Canada.jpg){kind=link}
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 at w: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.
Thoughts? Bawolff (talk) 19:45, 7 December 2025 (UTC)
- 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)
- 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 power w: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 integrate pannellum (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 (See mw: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 like d: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)
- 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)
- 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 from the discussion on their talk page to bring this here.
- Cheers, Sdkb talk 23:51, 7 December 2025 (UTC)
- 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)
- I love it --PantheraLeo1359531 😺 (talk) 19:04, 8 December 2025 (UTC)
- That looks quite interesting. -- SimmeD (talk) 00:02, 9 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)
- 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)
Scans of papyri
In continuation of a previous similar discussion: are scans of papyri (which are completely two-dimensional) I find online free to upload to Commons? for example this one.
Tagging Jmabel who helped me a lot in the previous discussion. פעמי-עליון (talk) 16:52, 8 December 2025 (UTC)
- Looks like a simple technical reproduction to me --PantheraLeo1359531 😺 (talk) 19:08, 8 December 2025 (UTC)
- Fyi, Morgan Library and Museum terms and conditions states, "The Morgan will not grant permission for the reproduction or commercial use of these low resolution downloadable images." -- Ooligan (talk) 03:28, 9 December 2025 (UTC)
- That last sounds to me like an unenforceable non-copyright restriction. That same terms and conditions page also claims the images are all coyrighted, which this image clearly is not. It would apply to anything copyrightable on their site, but cannot apply to public-domain images. This is exactly what {{PD-Art}} is about. - Jmabel ! talk 03:52, 9 December 2025 (UTC)
- Thank you for those details @Jmabel.
- Great discovery @פעמי-עליון. -- Ooligan (talk) 04:35, 9 December 2025 (UTC)
- That last sounds to me like an unenforceable non-copyright restriction. That same terms and conditions page also claims the images are all coyrighted, which this image clearly is not. It would apply to anything copyrightable on their site, but cannot apply to public-domain images. This is exactly what {{PD-Art}} is about. - Jmabel ! talk 03:52, 9 December 2025 (UTC)
- Fyi, Morgan Library and Museum terms and conditions states, "The Morgan will not grant permission for the reproduction or commercial use of these low resolution downloadable images." -- Ooligan (talk) 03:28, 9 December 2025 (UTC)
- If there are follow-up questions, please ask at Commons:Village pump/Copyright. Prototyperspective (talk) 12:08, 9 December 2025 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:08, 9 December 2025 (UTC) Near-empty Category:Statistics about communication
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?
A difficulty and also sth where input here would help is that probably not all of Category:Internet statistics should go into it but only a fraction that is actually about the communication and not e.g. the share of Web browsers used. Prototyperspective (talk) 23:06, 8 December 2025 (UTC)
- Don't forget {{See also cat}} for categories that are related, but neither exactly belongs as a child of the other. - Jmabel ! talk 00:49, 9 December 2025 (UTC)
- 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 as Category:Media statistics.
Prototyperspective (talk) 12:06, 9 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)
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)
Formatting Wikidata query
Hi, In the table of Paintings by Wassily Kandinsky, how to format the result of the WD query so that it looks like this instead of the current one. The external links should be within [ ] avoiding to create an oversize column. Also is the description really useful? It is always "painting by Kandinsky". Yann (talk) 16:42, 9 December 2025 (UTC)
Attention filemovers
Please see Commons:Administrators' noticeboard#Mass rename requests with Criterion #4. Posting here so other filemovers have a chance to weigh in on use and scope of filemoving criterion #4 (harmonizing). Geoffroi 21:21, 9 December 2025 (UTC)
December 10
Your support for colored 3D models on Wikipedia needed
You can show your support for colored 3D models on Wikipedia and Commons here: https://meta.wikimedia.org/wiki/Community_Wishlist/W326. As this topic is becoming more urgent, it should get some attention to finally implement a new file format. Thank you :) --PantheraLeo1359531 😺 (talk) 19:36, 10 December 2025 (UTC)
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)
- 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)
- 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)