Commons:Village pump

Shortcut: COM:VP

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

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

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

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

Thatched water pump at Aylsham, Norfolk [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive RfC: Should Commons ban AI-generated images? (3 January 2025) Costumed character files (14 October 2024) Was the closure of the deletion discussion concerning the current lede image for Philippe Pétain proper under Commons policy? (22 September 2024) Third-party images published by the National Weather Service (26 August 2024) Commons:Requests for comment/Hosting of free fonts in Commons (18 July 2024) How do we organize categories by date (14 May 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Template: View   ■ Discuss    ■ Edit   ■ Watch

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

January 24

Vector 2022 will be the default skin

A two-minute video about Vector 2022

Hello. We are the Wikimedia Foundation Web team. We are here to announce that the Vector 2022 skin will become the default desktop skin here on 10 February. We will gladly answer your questions, concerns, or additional thoughts! We will also help you adjust things which Vector 2022 may not be compatible with. Check out our FAQ – you will find many useful answers there.

If you are using Vector legacy skin, you may find yourself receiving the Vector 2022 skin. You may select Vector legacy as your global preference to avoid seeing the change. Logged-in users can at any time switch to any other available skins, or stay with Vector 2022 and enjoy choosing between its light and dark mode. Users of other skins will not see any changes.

Why are we changing the skin now

For technical reasons (listed below), we need to deploy the skin soon. After deployment, we will continue discussing issues and questions about the interface, and we'll be ready to work with you on various issues like gadget compatibility.

More details on why we need to deploy the skin now

• Due to releases of new features only available in the Vector 2022 skin, our technical ability to support both skins as the default is coming to an end.  Keeping more than one skin as the default across different wikis indefinitely is impossible. This is about the architecture of our skins. As the Foundation or the movement in general, we don't have the capability to develop and maintain software working with different skins as default. This means that the longer we keep multiple skins as the default, the higher the likelihood of bugs, regressions, and other things breaking that we do not have the resources to support or fix.  
• Vector 2022 has been the default on almost all wikis for more than a year. In this time, the skin was proven to provide improvements to readers while also evolving. After we built and deployed on most wikis, we added new features, such as the Appearance menu with the dark mode functionality. We will keep working on this skin, and deployment doesn't mean that existing issues will not be addressed. For example, as part of our work on the Accessibility for Reading project, we built out dark mode, changed the width of the main page back to full (T357706), and solved issues of wide tables overlapping the right-column menus (T330527).
• Vector legacy's code is not compatible with some of the existing, coming, or future software. Keeping this skin as the default would exclude most users from these improvements. Important examples of features not supported by Vector legacy are: the enriched table of contents on talk pages, dark mode, and also temporary account holder experience which, due to legal reasons, we will have to enable. In other words, the only skin supporting features for temporary account holders (like banners informing "hey, you're using a temp account") is Vector 2022.

How to request changes to the skin

We are guessing that some of you may want to see some changes to the skin. We are still improving Vector 2022 and the overall reading experience. If you have a feature request or a bug report, we encourage you to comment here or open a ticket in Phabricator. We will decide on the priority of these requests alongside our regular processes after deployment. Some fixes may be done via gadgets or user scripts, too.

About the skin

Global preferences

We encourage you to try out Vector 2022 by going to the Appearance tab in your preferences and selecting it from the list of skins. Getting used to it may take a few days, and that's the standard for interface changes.

Details about the skin

Vector 2022 is the modernized version of the currently default skin Vector legacy. It is the default on almost all Wikimedia wikis (there are about 10 left now). Most of the active editors use it and do not opt out of the skin at statistically noticeable rates despite easy access to the opt-out link. (Check the source here.)

[Our 2022 answer to why is a change necessary] When the current default skin was created, it reflected the needs of the readers and editors as these were in 2010. Since then, new users have begun using the Internet and Wikimedia projects in different ways. Although there were changes to features the skin supported, the structure, navigation, visual layout, and overall readability of the skin did not change. The old Vector does not meet the current users' needs.

[Objective] The objective for the Vector 2022 skin is to make the interface more welcoming and comfortable for readers and useful for advanced users. It introduces a series of changes that aim to improve problems new and existing readers and editors were having with the old skin. It draws inspiration from previous user requests, the Community Wishlist Surveys, and gadgets and scripts. The work helped our code follow the standards and improve all other skins. We reduced PHP code in the other available skins by 75%. The project has also focused on making it easier to support gadgets and use APIs.

[Changes in a nutshell] The skin introduces changes to the navigation and layout of the site. It adds persistent elements such as a sticky header and table of contents to make frequently-used actions easier to access. It also makes some changes to the overall styling of the page. The analysis of the data collected concluded that these changes improve readability and usability, and save time currently spent in scrolling, searching, and navigating – all of which can be interpreted to create an easier reading experience. The new skin does not remove any functionality currently available on the old Vector skin. On wikis with this skin as the default, there are no negative effects to page views, account creation, or edit rates. On our project pages you will find findings and results in a nutshell.

A summary of findings and results

• On average, 87% of logged-in users on our early adopter wikis (incl. French Wikipedia) continue to use the new skin once they try it.
• The sticky header makes it easier to find tools that editors use often. It decreases scrolling to the top of the page by 16%.
• The new table of contents makes it easier to navigate to different sections. Readers and editors jumped to different sections of the page 50% more than with the old table of contents.
• The new search bar is easier to find and makes it easier to find the correct search result from the list. This increased the amount of searches started by 30% on the wikis we tested on.
• The skin does not negatively affect page views, edit rates, or account creation. In fact, there is observational evidence of increases in page views and account creation across partner communities.

How can editors change and customize this skin?

• We make it possible to configure and personalize our changes. We are happy to work with volunteers with technical skills who would like to create new gadgets and user scripts. So far, many gadgets and user scripts have been built by volunteer developers. These aspects include making the background gray, turning off sticky elements, bringing back the old table of contents, and more. We encourage you to check out our repository for a list of currently available customizations and changes, or to add your own.
• In Vector 2022, logged-in and logged-out users can change the font size and color scheme based on their individual needs. Dark mode is now available for logged-in users of Vector 2022, and we would like to make it available to logged-out users as soon as most articles are dark-mode friendly.

How will we go through the change

• Wiki page: we would like to kindly suggest creating a page similar to English Wikipedia's w:WP:V22. It may explain the basics like how to opt-out or customize the skin.
• CentralNotice banner for logged-in users: before and shortly after deployment, we will display a banner announcing the change. It will be linking to Commons:Vector 2022 if you decide to create such a page. Otherwise, it will be linking to this announcement. This should limit the confusion and the number of repetitive questions about the change.

If you think there are any significant technical issues, let us know – perhaps we've missed something. We're looking forward to your comments and reactions from readers after deployment. Thank you! OVasileva (WMF) and SGrabarczuk (WMF) (talk) 01:06, 24 January; Unarchiving to keep this here SGrabarczuk (WMF) (talk) 19:20, 14 February 2025 (UTC)

January 27

Upcoming Commons conversation about impact and funding model on February 5

Hello everyone! The Wikimedia Foundation will be hosting the fourth and last round of a series of community calls to help prioritize support efforts from Wikimedia Foundation for the 2025-2026 Fiscal Year.

The purpose of these calls is to support community members in hearing more from one another - across uploaders, moderators, GLAM enthusiasts, tool and bot makers, etc. - about the future of Commons. There is so much to discuss about the general direction of the project, and we hope that people from different perspectives can think through some of the tradeoffs that will shape Commons going forward.

Our fourth and last call will focus on impact and funding model. One vision of Wikimedia Commons is for it to be primarily a repository of images for use on Wikipedias. In this world, the Wikimedia Foundation might focus on building components in Wikipedia that bring images into articles and Commons, maybe assisted by machine learning tools for editors. Another vision for Wikimedia Commons is one in which the project is an offering in its own right, and users share, discover, and utilize media content for its own independent value. In this world, investments would be needed to make it easier to search and discover media on the Commons website itself, including through: structured data on images, machine assisted tagging, more storage capacity and scale, investing in APIs that reusers would want, and workflows for educators to discover visual materials for their class.

Each of these directions would likely involve bringing in new volunteers and partners aligned with that focus. A different revenue model would also need to be explored to support substantial new development work. We would not invest in both, but only in one of them. Does it make sense to invest in bringing content from Commons into Wikipedia or focus on developing Commons into an offering in its own right?

The call will take place at two different time slots:

•  The first one will be on February 5, at 08:00 UTC, and it will be hosted on Zoom by Senior Director of Product Management Runa Bhattacharjee; you can subscribe to it on Meta;
•  The second one will be on February 5, at 16:00 UTC, and it will be hosted on Zoom by Chief Product & Technology Officer Selena Deckelmann; you can subscribe to it on Meta.

If you cannot attend the meeting, you are invited to express your point of view at any time you want on the Commons community calls talk page. We will also post the notes of the meeting on the project page, to give the possibility to read what was discussed also to those who couldn’t attend it.

If you want, you are invited to share this invitation with all the people you think might be interested in this call.

We hope to see you and/or read you very soon! Sannita (WMF) (talk) 11:50, 27 January 2025 (UTC)

Repeating what I have just said in reply to this, on Telegram:

This is a false dichotomy. Commons has always been both, and - as we are a good way into our third decade - it is disappointing (indeed, alarming) that the Foundation do not realise this.

That said, "building components in Wikipedia that bring images into articles" would be an investment in Wikipedia, not in Commons.

Why do WMF suggest "focus on developing Commons into an offering in its own right", when Commons is already an offering in its own right?

And why is "machine assisted tagging" still being proposed, after previous experiments doing that have been shown to be damaging?

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:19, 27 January 2025 (UTC)

Hi, Yes, I mostly agree. The WMF does not take Commons seriously. It is a shame that, more than 20 years after Commons was created, there is still not a technical team dedicated to fix and improve issues pertaining to multimedia content (especially videos, sounds, DjVu and PDF for books, 3D, etc.). These are the things relevant for Commons. What are we invited to discuss otherwise? Yann (talk) 12:51, 27 January 2025 (UTC)

+1 — Rhododendrites ^talk |  18:23, 27 January 2025 (UTC)

@Pigsonthewing @Yann @Rhododendrites Thanks for your comments. I relayed them to the team and we are discussing your feedback. Please, remember that the format we suggest is just "food for thought", and it doesn't reflect actual suggestions of actions to be undertaken. We just want to discuss broadly topics and gather feedback on them, while exploring the difficulties of each approach. Sannita (WMF) (talk) 13:17, 29 January 2025 (UTC)

@Sannita (WMF)

We would not invest in both, but only in one of them.

What does "invest" mean here? No new development, or also cutting ongoing things (like Charts) or even stopping fixing bugs? Ainali (talk) 13:43, 27 January 2025 (UTC)

@Ainali Thanks for the question. In this "food for thought" experiment, we are evaluating which way to go in funding Commons. This does not mean "No new development, or also cutting ongoing things (like Charts) or even stopping fixing bugs": bug fixing will stay, but development might be adjusted to the direction that community decides to take towards the future of Commons. Please remember that this is just a discussion, and it doesn't reflect actual suggestions of actions to be undertaken soon. Sannita (WMF) (talk) 13:20, 29 January 2025 (UTC)

If it is not actual suggestions, then just call it a day and don't waste the time. There is plenty of concrete stuff worthy investing time for staff to discuss. Ainali (talk) 21:35, 29 January 2025 (UTC)

With all due respect, "bug fixing will stay" implies that WMF is actually engaging in bug fixing currently. The lack of attention to maintenance is appalling. Right now it feels like WMF only wants to engage in big splashy projects you can write a press release about, but is uninterested in the less glamorous work of crossing t's and dotting i's that make a product actually usable. Bawolff (talk) 17:07, 31 January 2025 (UTC)

@Bawolff To be fair, the Structured Content team did bug fixing this year related to UploadWizard, even though I do recognise there has been a harder luck with feature requests and similar requests. Sannita (WMF) (talk) 15:13, 3 February 2025 (UTC)

And yet, when the second highest ranked item in the technical needs survey was that uploads were unstable and intermitently did not work, they were no where to be found. The entire point of upload wizard is to upload things and yet there was no monitoring of upload success rates, no attempt to diagnose and triage user reported errors, nothing. If you are running a media repository, being able to upload things reliably is a core competency, one that the Wikimedia foundation seems incompetent to maintain. Bawolff (talk) 06:23, 4 February 2025 (UTC)

I have to agree with bawolff on this. Bug fixing in a niche area and letting go of the rest is not bug fixing to most people. It's like saying you are dieting during breakfast, but indulge throughout the rest of the day and gaining weight overall. That's not how dieting works. However. It is disingenuous, and the foundation should know better. —TheDJ (talk • contribs) 10:20, 4 February 2025 (UTC)

@Sannita (WMF)

A different revenue model would also need to be explored to support substantial new development work.

Is this a new thing, that individual projects now should come up with a revenue model? I have never heard of any revenue model for individual projects at the WMF other than general fundraiser. Perhaps just add a link to background info about this new direction? Ainali (talk) 13:45, 27 January 2025 (UTC)

As I understood that this is not only about funding the basic software development but also funding some content generation. Unlike at Wikipedia and Wikidata contributing to Commons can come with very high costs for camera equipment and sometimes travel costs. In rich regions like Europe and Nord America that is not a huge problem as there are many people able to use their personal money but in many regions this is not the case. I would really like if we could fund people to get better hardware. I would also like if we could pay professionals to make photos for Commons in cases where volunteers can not generate such content like photos from war areas. Currently we totally depend on government sources in this field. GPSLeo (talk) 18:55, 27 January 2025 (UTC)

I'm going to put something very simply: if Commons is reduced to a role in supporting Wikipedia, I will almost certainly leave the project and probably Wikimedia projects in general. I've put nearly 20 years of my life into this project, treating it as something like an unpaid full-time job, and certainly not as building just a tool for Wikipedia. If that is being terminated, I'm done. - Jmabel ! talk 19:07, 27 January 2025 (UTC)

I agree with the points that GPSLeo and Jmabel make, Commons is a media repository, we do support other Wikimedia projects in this, but our primary role is to be a repository. Reducing Commons to an appendage of Wikipedia would be a mistake. My uploads are intended to help Commons as a repository, most of them are not intended to be used for Wikipedia articles but can supplement them if needed. And we definitely should look into paying professionals for media where volunteers might not be able to go. Also in my opinion, Commons should also be able to do EDPs for public artworks and architecture since FoP (and secondarily URAA) is such a big challenge for retaining media in some countries. Abzeronow (talk) 20:35, 27 January 2025 (UTC)

I had an idea of creating a new media agency that

1. works professionally (like Reuters, AFP, BBC...)
2. licenses its works as PD or ccbysa (like VOA)
3. gets funding like WMF.

Basically an alternative BBC(which has services not only in English but plenty of languages)/VOA/RFERL with WMF-style funding (crowdfunding) instead of licence fee or US govt money. RoyZuo (talk) 14:35, 29 January 2025 (UTC)

@RoyZuo: Good luck with that.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:30, 29 January 2025 (UTC)

I also agree with many of the critical comments here and for Commons to be considered supported as something more than a host for Wikipedia. However, I think the main issue is that it's barely used. Various things can improve how well it can be used like improvements to the MediaSearch and enabling heavily-used files to be shown at the top of categories but again such improvements and the point of the site itself only becomes tangible if it's actually known and used. Most category pages barely get any views and aren't indexed, neither are videos. This needs seo-type efforts, investigations, and outreach-type efforts (as described in the link). Well-organized files here still aren't that useful. Using category pages is a pain to newcomers with all the subcategories and so many unsorted files being in them assuming people find their way to Commons at all which WMF made sure to be super unlikely via hiding categories and showing media files in an intermediary Wikipedia page instead of Commons directly (undoing these two things would also help visibility). Bringing media content from here into Wikipedia seems like a good idea but it's not an either or thing and both things can be combined – e.g. by showing a panel of related media files with a [more media] button at the bottom of the article or improving the visibility of the Commons cat template for a start. Prototyperspective (talk) 17:03, 31 January 2025 (UTC)

Is it Wikimedia Foundation or Wikipedia Foundation?

"One vision of Wikimedia Commons is for it to be primarily a repository of images for use on Wikipedias." Does that mean WMF is gonna downplay not only Commons but also wiktionary, wikisource, etc.? RoyZuo (talk) 22:38, 27 January 2025 (UTC)

It's probably just one of the inevitable side effects of Commons not doing it's own funding drives. If Wikipedia is where all the donations come from then everything else is obviously going to play second fiddle to it. Commons not having it's own domain doesn't help either. I don't know how many people both on Commons and IRL who thought this is just a subpage of Wikipedia. I can't say I blame them. But if Commons is or ever becomes it's own project then I think both of those things should be prioritized on here. Especially the site being hosted on it's own domain separate from Wikimedia.org. --Adamant1 (talk) 02:34, 29 January 2025 (UTC)

@Ainali @GPSLeo @Jmabel @RoyZuo @Adamant1 Thank you for your comments, I'm sending them to the team for appropriate evaluation. As I said above, please remember that the format we suggest is just "food for thought", and it doesn't reflect actual suggestions of actions to be undertaken. We just want to discuss broadly topics and gather feedback on them, while exploring the difficulties of each approach. Sannita (WMF) (talk) 13:21, 29 January 2025 (UTC)

Sincerely, I don't care if Commons is considered as an independent project or as part of Wikipedia. If what people know well is "Wikipedia", it could even be better for Commons to be something like "Wikipedia media collection", and it could be taken into better consideration, being a part of WMF's flagship product. Of course, provided that this does not diminish the consideration of all the media files that are not used from other wikis, and its usefulness as a media repository for different purposes. The same about other WMF projects, such as Wikisource, that could become something such as "Wikipedia Library", and that name could make it better known. I'm not necessarily advocating using the Wikipedia name in all or most WMF projects, but, if for some kind of marketing-like purposes, everything should revolve around Wikipedia, this would be a way for a win-win situation. Specially, for Commons, since Wikipedia needs Commons as a component (otherwise, it would be a text-only encyclopedia). MGeog2022 (talk) 20:49, 29 January 2025 (UTC)

I agree that the WMF should focus more on Commons (as it is one of the most important projects). Progress changes fast and the WMF muss adapt this progress so that media can be used here, no matter if its a basic 2D image or a modern immerse video/3D model (whatever) --PantheraLeo1359531 😺 (talk) 16:35, 31 January 2025 (UTC)

Why is everything with WMF a community call now a days? The people who attend such calls are almost certainly going to be non-representative. Video calls, even if recorded, generally fade away from memory rather quickly. It seems like a really poor way to engage with the community. Bawolff (talk) 17:17, 31 January 2025 (UTC)

@Bawolff It is one of the ways we planned to do outreach to the community, despite all of its limitations such as timing and availability of people. There will be other opportunities, on- and off-wiki, to continue give feedback, such as the upcoming discussions for WMF Annual Plan. Moreover, there is the talk page of the conversation that can be used for feedback on the topic raised, or on topics that are at heart for you. Sannita (WMF) (talk) 15:16, 3 February 2025 (UTC)

I think you misunderstand the nature of my objection. Bawolff (talk) 06:10, 4 February 2025 (UTC)

I'm not entirely sure what you mean with this either Bawolff .. The calls are just a new method that was offered as a way of adding a more interactive and specifically a more intense and focused way of engaging with the community. —TheDJ (talk • contribs) 10:25, 4 February 2025 (UTC)

I very much agree with Bawolff. And I do not find it a "more intense and focused way". A structured argument map about what to do or change and what do prioritize would be a more focused way than the conventional discussion (which is pseudonomyous texts on a Wikimedia project discussion page(s)). Prototyperspective (talk) 12:34, 4 February 2025 (UTC)

With intense and focused, I mean a practical period of engagement time. I do not argue that this makes everyone feel included. But I think that such on wiki discussions have proven relatively pointless and by extension thus a waste of very valuable time. This community cannot make choices and it cannot accept choices that the foundation makes for them. 'Do all the things' is not a choice that is realistic. We can talk for weeks but that mostly will lead to the same amount of nothing getting done. At least if I have a calendar item that I can plan into my week, I can focus my engagement and get to the same amount of nothing burger. Having multiple methods of engagement is useful because it allows different people to participate. —TheDJ (talk • contribs) 13:44, 4 February 2025 (UTC)

You don't need to look any further than to the Commons:Requests for comment/Technical needs survey. Once the well-supported requests there have been implemented there could be more discussion about how to better prioritize things albeit the "Media formats, editing, and display" focus area is now at spot #3 in the Community Wishlist. It's a nothingburger because the WMF wastes funds instead of developing and building technical development capacity. Discussion is basically pointless because of that, not because the "community cannot make choices" which as shown is false. Prototyperspective (talk) 14:25, 4 February 2025 (UTC)

@TheDJ You're right. I was frustrated and expressed myself poorly. The reasons I don't like these calls are multiple. A) It feels like these calls are structured and framed to get certain answers and not others. (I suppose that is unavoidable to some extent, but i feel like its structured in a way that it won't get to the crux of the main issues or represent fairly mainstream views). B) the opaqueness in the structure feels like its open to selective interpretation. There is very few controls to prevent someone from taking away whatever they want from these conversations instead of the actual views expressed. Its difficult to even figure out what views were expressed. I wouldn't want to participate in something if it turned out just to be an exercise in manufacturing consent. C) honestly i find the framing of the most recent call kind of insulting. Additionally when attending the in person session at WCNA, i felt at certain instances WMF was taking credit, at least a bit, for activity that volunteers primarily did, which soured me on the whole thing.

To be fair. All this is a hard problem, and i don't have a solution for how to do community consultations in a fair but reasonably efficient manner. It feels like the community and the WMF are miles apart in understanding each other here. Its not just disagreement; I think there is a fundamental lack of understanding between both sides. Productive cooperation can still happen amidst disagreement, but not unless both sides understand the why's and what's of each other's positions. Bawolff (talk) 17:40, 4 February 2025 (UTC)

@Bawolff I understand your frustration, and I'm sorry we're still at this point in the relationship between WMF and the community(/ies). For what is worth, we do not actively look for "certain answers and not others", we are actually looking for all feedback possible, in order to elaborate a better strategy for Commons. As for "taking away whatever [we] want from these conversations", I can assure you - as someone who is involved in both organising the calls, and producing the notes at the end of the meetings - that the final result respects 100% what is said in the calls, and that we do not change its content to favor anyone, not even WMF. I hope this helps in creating a better understanding between us. After all, I have only my word to convince you that we're doing this in good faith, and with the interest of the community at heart. Sannita (WMF) (talk) 18:42, 4 February 2025 (UTC)

Now that the Taliban is back in power should Afghanistan still be considered part of Berne-World?

When I first started contributing here there were about half a dozen countries that, because they weren't part of the international agreements on copyright, images taken there weren't protected by copyright.

At least that is how I understood it at the time.

War-torn Afghanistan was one of those countries. And, for many years, images taken in Afghanistan were considered public domain here. At least that is how I remembered it.

Then someone noticed a press release, from the office of the President of Afghanistan, saying there were plans to get Afghanistan on-board Berne-World. That press release was more than six months old. It was argued that all WMF projects should anticipate Afghanistan joining Berne-World, and immediately treat images from Afghanistan as if they were protected by International Intellectual Property Agreements.

My understanding was this was premature. My understanding was two of the three steps Afghanistan would have to take were legislative steps:

1. The Afghan legislature had to pass a law providing intellectual property rights to creators, within Afghanistan, that was consistent with the intellectual property rights in all other nations that were part of Berne-World.
2. The Afghan legislature had to pass another law indicating it agreed to abide by those international property rights agreements, so that all the intellectual property rights of content creators from other nations were protected by Afghan law.
3. And finally, Afghan officials would have to enforce the rights of intellectual property rights holders, including foreigners. Afghan newspapers would no longer be allowed to use any old international images they wanted with bothering with licensing, credit and payments to rights holder.

It took about five years, but the legislature did, eventually, pass those laws. My personal opinion was that we should not have started treating Afghan images as if they were protected by copyright until the legislature passed those laws.

Well, what about the status of Afghan images in 2025?

The Afghan legislature did pass those laws, about fifteen years ago.

IANAL, but I think that, legally, Afghan images are no longer protected by copyright if Afghan law enforcement officials are ignoring those laws.

I thought the policy to treat Afghan images as if they were protected by copyright as soon as there was an indication Afghanistan might join Berne-World was, frankly, disrespectful.

The Taliban would never have signed on to Berne-World, as they did not believe in Progress.

But there are other groups who don't believe in Progress. Old order Mennonites, Amish and Hutterites, for instance. Old order Mennonites and Amish wear the same kind of clothing people wore when their churches were founded. If they had their own country there would be no copyright protection there, either. Geo Swan (talk) 12:41, 27 January 2025 (UTC)

Afghanistan is currently a member of the convention [1]. GPSLeo (talk) 12:50, 27 January 2025 (UTC)

Please do not conflate irrelevant things: Mennonites and Amish, peaceful out of modern society cultures with violent Taliban repression. Also what is the law, and how it is applied are two different things. There are a lot of places where copyright laws are seldom or poorly applied. Should we start hosting content from these places because the culture and the judiciary system do not work as in the Western world? Yann (talk) 12:58, 27 January 2025 (UTC)

Rules are rules. But maybe the Berne convention will be repealed within the next 20 years. Things become discarded so fast these days --PantheraLeo1359531 😺 (talk) 16:40, 27 January 2025 (UTC)

Until Afghanistan takes steps to withdraw from Berne, it should be considered as under that treaty. URAA date would not be changed regardless. Abzeronow (talk) 19:36, 27 January 2025 (UTC)

Well, until they are allowed to withdrawn from Berne would be more accurate Trade (talk) 16:57, 1 February 2025 (UTC)

January 29

Attempting sort of a super-FAQ

Commons:How to. I've given this a running start. So far I've worked on about 5-1/2 sections. I'd be glad for others to edit what I've written (it's probably too much my particular voice), take on sections of their own, add headings for sections we need that I didn't think of. Also, if people think this is just wrongheaded, I'd appreciate hearing that sooner rather than later. - Jmabel ! talk 05:29, 29 January 2025 (UTC)

Making a lot of progress here. The one question where I don't know where to begin myself is, for GLAMs, If we upload content, how can we track its reuse? If someone else can answer that, either here or by writing the section there, it would be greatly appreciated. - Jmabel ! talk 03:17, 2 February 2025 (UTC)

I wrote a short section on tracking reuse, but I'm not familiar working with GLAM projects themselves, so I'm not sure if they have more specific needs (or more specific tools available to them) compared to regular users. ReneeWrites (talk) 23:55, 2 February 2025 (UTC)

This is now out of the "under construction" phase, though of course further edits are welcome, especially if people can think of other things people often want to do here and find themselves confused as to where to start. I'm hoping this might be a good place to refer people for certain recurring questions on the help desk, and might even be worth linking from the "welcome" template. I'm probably not the one to formally propose the latter, since I'm the one who started the page. - Jmabel ! talk 21:50, 5 February 2025 (UTC)

Balancing Uploader Requests vs. Descriptive Filenames?

This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 11:00, 7 February 2025 (UTC)

What's your take on this file naming dilemma? When an original uploader requests to change a descriptive filename to a less meaningful one, should we prioritize COM:FR#FR1 (respect original uploader's request) or COM:FR#FR2 (avoiding meaningless names)? How do you balance respecting the uploader's wishes with maintaining clear, descriptive filenames? I'm curious to hear your thoughts on the best approach in this situation. SimmeD (talk) 11:57, 29 January 2025 (UTC)

@SimmeD: I think File:Ardea cinerea A7R04867 (51957702865).jpg is a good example of how a compromise was reached. The original uploader wishes the files to retain their original code, but Commons policy is pretty clear that the original file name File:A7R04867 (51957702865).jpg is in violation of our naming policies, regardless of how the uploader feels about them. The code can be appended to a name that complies with the naming policy, but it can't be the filename in its entirety. ReneeWrites (talk) 12:27, 29 January 2025 (UTC)

@SimmeD: My usual approach as a filemover is that I will honour most criterion-1 requests, but will decline them if the new name would immediately be eligible for renaming under some other criterion. So in the example above, I decided that the inclusion of the species name was enough to mean that criterion 2 didn't apply and so I renamed the file as requested by the uploader. On the other hand, when the uploader asked for File:Hochhaus Wintergartenstrasse, Leipzig, 12-06-30 by ralfr 11.jpg to be renamed back to File:12-06-30-leipzig-by-ralfr-11.jpg I declined the request because the proposed name was so ambiguous that it could immediately be renamed again under criterion 2. --bjh21 (talk) 17:22, 29 January 2025 (UTC)

I am too a filemover. And I even happened to decline COM:FR#FR1 requests when the uploader wanted to change the filename from one in Latin script to IIRC Kanji / Kana, as the latter can be read only by a minority of Wikimedians and potential re-users. So: "FR1" is, for me, never higher than other criteria (FR2 or FR3), and I often deliberately changed a FR1 requested name to something else, often adding a shot date, location or motif (scientific) name. Regards, Grand-Duc (talk) 04:25, 1 February 2025 (UTC)

Thanks for everyone's comments. I'll take them to heart and think about them if a situation arises. SimmeD (talk) 20:12, 3 February 2025 (UTC)

January 30

Renaming multiple files

This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 11:01, 7 February 2025 (UTC)

65 file names contain the typo Trafala, which should be Tarfala. This includes all currently existing file names containing "Trafala," most of which begin "Valley between Trafala," with a few exceptions. The captions and descriptions have already been corrected. (Example 1, example 2.)

Do I simply request that they all be renamed one by one, or is there a way that's more convenient for file movers? I don't wanna clog the backlog with a bunch of individual requests unless it's necessary.

Sinigh (talk) 15:36, 30 January 2025 (UTC)

I have a script for this and will correct the names the next days. GPSLeo (talk) 16:48, 30 January 2025 (UTC)

That is indeed a more convenient way. :) Thanks! Sinigh (talk) 17:09, 30 January 2025 (UTC)

 Done all corrected now. GPSLeo (talk) 19:02, 1 February 2025 (UTC)

Template problem (Cdw)

It looks like there is something wrong with Template:Cdw/layout; probably the problem results from subst'ing {{Cdw}} or some even higher-level template. The resulting link to the category for discussion is fine, but recently the link to the CfD discussion has consistently been broken. You can find an example at User talk:Infrogmation. - Jmabel ! talk 19:43, 30 January 2025 (UTC)

Yep. The same happened to me. I mentioned it both here and here. Kind regards, Alavense (talk) 17:06, 31 January 2025 (UTC)

January 31

Syrian flag, redux

I see that Commons:Village_pump/Archive/2024/12#Syrian flag has once again fallen off of this page due to inactivity, and with absolutely no resolution as to how to move forward. I think it is absolutely unacceptable that File:Flag of Syria.svg continues to show the flag of the toppled Assad regime, but that is how things are going to be until we reach some sort of agreement. My several efforts to move this forward have been rebuffed, including [`https://commons.wikimedia.org/w/index.php?title=File:Flag_of_Syria.svg&diff=prev&oldid=974819463 this revert] by Ericliu1912. I agreed not to fight over that on the basis that the revert was temporary. It is now five weeks later. - Jmabel ! talk 22:04, 31 January 2025 (UTC)

Well, I told you there would be complications :-) Rudolph Buch (talk) 22:33, 31 January 2025 (UTC)

@Rudolph Buch: I've honestly forgotten: are you advocating some particular solution, or are you just here to remark that this is difficult? Because I do not believe that leaving things as they are is an appropriate solution. - Jmabel ! talk 02:39, 1 February 2025 (UTC)

It may be one of those situations where ‘leaving things as they are ’ is not good, but any action from our side is even worse. As a matter of policy, Wikipedias can trust Commons not to make content changes to linked files. The exception is Template:Current, but the flags are not marked with this template. With the idea of a central flag update, Commons has imposed a problem on itself that it cannot solve and that it does not have to solve within the scope of its role. I believe that it is the local Wikipedia´s job to keep their articles updated, not Common´s. If they want dynamic content updates based on validity periods, they should make use of Wikidata, which is better suited to handle that. Rudolph Buch (talk) 12:02, 1 February 2025 (UTC)

OK, so I guess we could now: (1) add a "1980" variant to all the Country data Syria templates (~110s); (2) notify all communities which use Flag of Syria.svg, including an SOP on how to manually clean up the remaining local flag variant usage; (3) wait for a period of time for the communities to prepare as much as possible; (4) implement the redirect change. —— Eric Liu_（Talk） 09:52, 4 February 2025 (UTC)

February 01

Invicta (Airline) - not a straightforward rename problem?

Ok, so this will probably appear lame compared to the deep technical stuff normally discussed here, but it has all but done my head in, although I now feel I am winning the battle. I'll explain.

Is this Invicta Airways or Invicta International Airlines? You can have two guesses.

There are approximately 30 media items (photos) related to a lesser-known defunct UK airline that operated as Invicta. And around 20 categories and sub-categories more or less related to them and not much else. The problem arises because for half its life this airline operated as Invicta Airways Ltd, and for the other half it adopted a new legal identity as Invicta International Airlines Ltd. Both the main article on en:wikipedia, and here at Commons, have ended up in a muddle, with everything being labelled as International. I am attempting to put this right, but it is not a straightforward rename situation, because approximately half of the images are in the correct categories, whilst the other half need renaming, and new categories creating for them. I cannot imagine there is a bot for that, so I am slogging through the process on a one-by-one basis. Mostly it seems as if there are more categories than images.

An additional complication is that the front-end image selection requires a trained eye, most probably from an aviation geek such as myself, because the differences are subtle, to the extent that they have been overlooked for the past 12 years. For a start, the aircraft colour-schemes are all but identical. The aircraft owned by Invicta Airways are not marked Airways, and the ones that belong to the later airline are not marked Airline - that would just be too helpful LOL. And sometimes the same aircraft appear on both sides of the divide at different times. Nevertheless I have a crystal ball that takes me to the right place. What I do not possess is the skill-set to be 100% sure I am getting the re-categorisation process correct. In fact I am sure I am making a complete xyz$ of it, but I also feel I am making progress, slowly.

I believe it is only correct that I set the record straight somewhere (here, for instance), as to what I am trying to achieve, and invite comments. Meanwhile, I will observe that in this case, a picture really is worth a thousand words. WendlingCrusader (talk) 10:20, 1 February 2025 (UTC)

@WendlingCrusader:

1. Yes it's a slog.
2. Normally, we make the older company a subcat of the newer company, and parallel that for subcats. Anything where we are in doubt stays in the category for the newer company.

Jmabel ! talk 19:26, 1 February 2025 (UTC)

@Jmabel

Thankyou - that is most useful confirmation, as it is something I have been working towards already. WendlingCrusader (talk) 11:45, 2 February 2025 (UTC)

Commons Gazette 2025-02

In January 2025, 1 sysop was elected. Currently, there are 182 sysops.

• User:Ratekreel was elected (27/2/2) on 27 January.

---

Edited by RoyZuo.

---

Commons Gazette is a monthly newsletter of the latest important news about Wikimedia Commons, edited by volunteers. You can also help with editing!

--RoyZuo (talk) 23:35, 1 February 2025 (UTC)

February 02

Commons:GLAM

It looks to me like Commons:GLAM and its subpages have barely been touched in years (unless we count vandalism and its reversion), and that much of the advice there falls short of being clear, comprehensive, and current. Anyone with experience in this area care to make a good pass through this and see what you can improve? - Jmabel ! talk 03:21, 2 February 2025 (UTC)

Global ban proposal for Shāntián Tàiláng

Hello. This is to notify the community that there is an ongoing global ban proposal for User:Shāntián Tàiláng who has been active on this wiki. You are invited to participate at m:Requests for comment/Global ban for Shāntián Tàiláng. Wüstenspringmaus _talk 12:07, 2 February 2025 (UTC)

February 03

Reminder: first part of the annual UCoC review closes soon

Please help translate to your language.

This is a reminder that the first phase of the annual review period for the Universal Code of Conduct and Enforcement Guidelines will be closing soon. You can make suggestions for changes through the end of day, 3 February 2025. This is the first step of several to be taken for the annual review. Read more information and find a conversation to join on the UCoC page on Meta. After review of the feedback, proposals for updated text will be published on Meta in March for another round of community review.

Please share this information with other members in your community wherever else might be appropriate.

-- In cooperation with the U4C, Keegan (WMF) (talk) 00:48, 3 February 2025 (UTC)

Brunei Darussalam Newsletter

Hello! I came across the Brunei Darussalam Newsletter, where some of the older issues contain a sidebar on the left side of page 2 that states: "Brunei Darussalam Newsletter is published fortnightly by the Department of Information. It reports on government, social and business events in the country. All money values are expressed in Brunei dollars $, unless otherwise stated. Any information in this newsletter may be reproduced; a clipping of the publication would be appreciated. For free subscription (Excluding postage) write to Information Department, Jalan Stoney, Bandar Seri Begawan 2041, Brunei Darussalam." An example would be here. So my question is whether the term "information" in that specific issue could also apply to images.

This has been previously used in "Category:Ministry of Foreign Affairs (Brunei) News Digest issues". — Preceding unsigned comment added by Pangalau (talk • contribs) 13:52, 3 February 2025 (UTC)

Why vectorize pixel art?

Is there any advantage for images like file:Confused-tpvgames.svg to exist? Aaron Liu (talk) 13:59, 3 February 2025 (UTC)

I guess it's because to avoid blurred images due to antialiasing, if the image would have 32×32 pixels. So it can be scaled freely --PantheraLeo1359531 😺 (talk) 14:17, 3 February 2025 (UTC)

But that is only a problem with the software interpreting the file. With software displaying and scaling the file correctly such a SVG is useless. GPSLeo (talk) 18:55, 3 February 2025 (UTC)

I'd say both sides have valid complaints in this discussion. While SVG files of e.g. pixel art do circumvent some problems, the SVG files shouldn't categorically supersede PNG files (which they currently don't). Sinigh (talk) 11:08, 4 February 2025 (UTC)

I do not believe there is. There were some QR codes that were converted to SVG. For such images, a bitmap is the compact form. Glrx (talk) 17:15, 4 February 2025 (UTC)

Some may argue that you can take advantage of SVG with animation possibilities, layers, modifying the viewbox and different editing possibilities (adding true color gradients or shadows, etc.) --PantheraLeo1359531 😺 (talk) 20:10, 4 February 2025 (UTC)

FWIW, you can make PNG pixel art scale without the blurring on pages, but you need to use a special template. e.g.

Bawolff (talk) 21:28, 4 February 2025 (UTC)

The PNG is even blurred in the thumbnail view in the "file history" section of its own description page. And as its size is 20x20 MW software does not even offer scaled thumbnails on the description page.

When looking at QR codes in ePapers I see more blurred QR codes than good ones. A problem that would not exist if SVG was the standard for QR codes. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 21:42, 4 February 2025 (UTC)

Just make an upscale PNG for the QR code. PNG has compression for neighboring tiles. Aaron Liu (talk) 22:27, 4 February 2025 (UTC)

Commons could add .filehistory img {image-rendering:pixelated} to MediaWiki:Common.css to fix that (You can put it in your Special:MyPage/common.css to test). There is an issue though in that for many image the other behaviour is better. Arguably though, image types that benefit from the other algorithm are likely to be bigger than the size of the file history preview, so maybe pixelated is a better default choice. Bawolff (talk) 22:42, 4 February 2025 (UTC)

Looking at pages that use File:Confused-tpvgames.svg, it's used in the signature of user TBC (for instance here). The downscaled svg version looks very pixellated, whereas the png version at this size would look more smooth.

Generally speaking when it comes to "which version is better" I just look at a few things: Which one looks better, which one can be more widely applied, and which one has the smaller file size. In many cases, simple bitmap graphics get superseded by their svg counterparts, but in this instance I don't think that is the case. ReneeWrites (talk) 12:01, 5 February 2025 (UTC)

it's pixel art Aaron Liu (talk) 12:36, 5 February 2025 (UTC)

And? ReneeWrites (talk) 14:31, 5 February 2025 (UTC)

It's supposed to "look very pixelated". Aaron Liu (talk) 14:32, 5 February 2025 (UTC)

Maybe I should've used "jagged" or "aliased". The png version is anti-aliased. Here's a visual comparison, svg at the top, png at the bottom. ReneeWrites (talk) 14:43, 5 February 2025 (UTC)

That's interesting. I would have expected the opposite result, if anything, or no difference. Sinigh (talk) 15:45, 5 February 2025 (UTC)

February 04

Deletion request categorization

Hello,

I came into a talk with a fellow Wikimedian about the subject of categorization of FOP-related deletion requests. Sometimes, the outcome is that an offending version gets revision-deleted, but the file itself stays after cropping, here's an example. As far as I understood it, differentiating between "kept" and "deleted" categories has the purpose to keep track of files that could eventually return and get restored should any local legislation change. So, by this logic, it would make more sense to affix "deleted" categories to DR like the example, instead of using the "kept" denominator. JWilz12345, which whom I talked, said to best carry this over here to get more input. So, here we go! Regards, Grand-Duc (talk) 09:34, 4 February 2025 (UTC)

If majority of users agree that in those cases of files that were eventually suppressed/redacted, then I'll also agree: xyz FOP cases/kept → xyz FOP cases/deleted. Anyway, it's more logical. JWilz12345 (Talk|Contributions) 09:43, 4 February 2025 (UTC)

I'll ping Podzemnik (who changed from /kept to /deleted here). JWilz12345 (Talk|Contributions) 10:17, 4 February 2025 (UTC)

I agree that the purpose of the "deleted" category is to bring some FoP photos back one day, so it makes sense to me to categorise those pictures with their deleted versions in the deleted category. Regards, Podzemnik (talk) 18:04, 4 February 2025 (UTC)

If the file is kept, but revisions are deleted for copyright reasons with known expiration, the solution is not to categorize the deletion discussion. The solution is to categorize the file page, e.g. Category:Commons:Files with deleted versions to be restored in 2040, where I categorized a bunch of images that had works by Cecilia Cuțescu-Storck in the background. - Jmabel ! talk 20:33, 4 February 2025 (UTC)

Discussion of sockpuppetry issue for Anonymous Hong Kong Photographer 1 on Meta

Hello. I recently opened a request for comment on Meta regarding sockpuppetry issue of User:Anonymous Hong Kong Photographer 1. You can join the discussion here. 興華街 (Hing Wah Street) - 💬 - 📝 13:48, 4 February 2025 (UTC)

@HingWahStreet: I opined there, thanks!   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:29, 4 February 2025 (UTC)

I reiterate: users should stop being hostile to other users because of their unusual working styles. RoyZuo (talk) 15:06, 4 February 2025 (UTC)

Major restructuring of database tables might require updating some tools

I just wanted to share this here, for all developers who do not subscribe to any of the announce mailing lists. In the coming months MediaWiki will see some major changes to the database structure for tables related to file management. Essentially, if something depends on the image or oldimage tables of the toolforge replicas, or any other sort of database dump, it is likely to require updates to the tool in order to keep working.

With these changes, the information around files will be stored much more similarly to how the page and revisions table keep track of revisions for a page. This is something that has been on the MediaWiki todo list for a long time. The ticket was created in 2011, but really, it was already supposed to happen in 2006. Due to the technical complexity and the fast growth of wikimedia in the 2006-2008 timeframe the change quickly became almost unachievable and increasingly complex afterwards. But now the foundation seems to have acquired the knowledge and experience to execute this long time need. Fixing this should simplify the management of file revisions, making them less susceptible to bugs and inconsistencies, as well as overall making it much easier to work with old and new versions of files from within MediaWiki.

It is advisable that tool maintainers start working on rewriting their tools now, to be able to read from both the new and the old tables, so that you can easily switch your tool when the old tables disappear. If you know of any such tools or tooling, you might want to double check with their maintainer if they are ready for this change. —TheDJ (talk • contribs) 15:16, 4 February 2025 (UTC)

Original description by photographer/author

What's the community's opinion on "original description" given by the author? Some descriptions (as well as file captions) I write include my thoughts that form an integral part together with the visual files. The same goes for non-commons photographers whose works are imported here. When they are deleted or altered sometimes the context of the creation is lost.

Is there / can there be an sdc property for original description?--RoyZuo (talk) 20:34, 4 February 2025 (UTC)

FWIW, so far Commons' policy has generally been to keep original descriptions from GLAMs intact (though of course more information can be added). File:Elliott Bay sunset, probably before 1889 - DPLA - cd9cd454e8804395a00fe402fc987c12 (page 1).jpg is a good example of an image where the original description and title were quite wrong, and I added more accurate information.

We do not currently give such deference to other uploads. I certainly would not want to guarantee to everyone that their original description would be kept: I have seen some wildly misleading, highly opinionated, and even slanderous original descriptions. We have also taken imported from Flickr where the description on Flickr was wildly out of bounds for what would be acceptable on Commons. File:Free Palestine, London.jpg is a good example of that.

My suggestion to anyone who wants to keep their own description intact and available is to first upload to a site such as Flickr where you have complete control of your descriptions, then use that as a source for your upload to Commons, with a link back to that as source.

I'm neutral on adding an SDC value for "original description". I suspect we could use an existing property with a qualifier.

Jmabel ! talk 20:54, 4 February 2025 (UTC)

SDC would not be the right place for this. For certain historical documents (such as uploads from the Bundesarchiv) the original description is kept with a disclaimer for its biases or inaccuracies, but generally speaking if a file's description should be amended in some way, the original version's just somewhere in the file history. ReneeWrites (talk) 14:38, 5 February 2025 (UTC)

That becomes de facto inaccessible to most users. RoyZuo (talk) 23:07, 5 February 2025 (UTC)

I recently started wrapping the original description in {{Original caption}} and preceding it with an improved description, like here. It's not SDC, but could be enough? --HyperGaruda (talk) 07:24, 6 February 2025 (UTC)

SDC inception added by wizard precise to only date

https://commons.wikimedia.org/w/index.php?diff=993670434

"Timestamp +2025-02-04T00:00:00Z Precision 1 day"

even though actually "Date and time of data generation 18:37, 4 February 2025".

is this what the community prefers? RoyZuo (talk) 20:49, 4 February 2025 (UTC)

this uploadwizard feature was introduced sometime between 4 and 14 November 2024. RoyZuo (talk) 20:55, 4 February 2025 (UTC)

Wikidata (and so, I presume, SDC) does not attempt to e more accurate than just the day. This is partly because things are so often not tagged with timezone, or at least not accurately. I'm certainly guilty of that last: I don't reset my camera's clock every time I change timezone, so I could take a picture in Bucharest with a West Coast U.S. timestamp. - Jmabel ! talk 20:57, 4 February 2025 (UTC)

I agree. Camera time settings are very often inaccurate. Probably best to just set the precision to 1 day and the uploader can override if needed. Nosferattus (talk) 14:11, 6 February 2025 (UTC)

Yeah, here is the documentation about the current situation: d:Help:Dates#Hours,_minutes_and_seconds --Zache (talk) 14:37, 6 February 2025 (UTC)

Thx Zache! nvm then. i had the false impression that other bots were adding more precise sdc. turns out all were just precise to date.

cameras that make use of gps record quite reliable time. i dont have data but my wild guess is for new uploads 90+% of phone photos and 50+% camera photos have accurate time settings calibrated by gps or internet. RoyZuo (talk) 15:19, 6 February 2025 (UTC)

Naming of Nvidia GPU categories

(Note: GeForce is the name of the brand itself, not the actual graphic cards model itself)

• NVIDIA GeForce RTX 2060
• Nvidia GeForce RTX 2060
• GeForce RTX 2060
• RTX 2060

Which naming scheme will be the correct one to go with? Trade (talk) 21:49, 4 February 2025 (UTC)

@Trade: I'd go with "Nvidia GeForce RTX 2060". This seems to be the most common naming schema in Category:Nvidia, though not with 100% consistency (especially not in Category:NVIDIA products). ReneeWrites (talk) 22:30, 4 February 2025 (UTC)

I am currently starting a discussion on Wikidata on the naming scheme as well. My hope is that both projects can agree to use the same consistent naming scheme Trade (talk) 22:36, 4 February 2025 (UTC)

Good luck, and feel free to ping me if you start a CfD about it here as well. I'm personally fine with either, but not both at the same time. Whichever one is chosen should be the one consistently used. ReneeWrites (talk) 22:50, 4 February 2025 (UTC)

My personal taste would be the original company name writing (NVIDIA) --PantheraLeo1359531 😺 (talk) 14:17, 5 February 2025 (UTC)

Commons Walkabout: new site for browsing Commons' structured data

Check it out here: Commons Walkabout. Any feedback is welcome. Yaron Koren (talk) 21:53, 4 February 2025 (UTC)

@Yaron Koren: This is a very elegant way of filtering files with a visual interface.

Some additional feedback:

• When selecting items from a large list (e.g. Valued image > location of creation) it gives me the option to write a custom value, but that field disappears the moment it loads the list of available locations. I think it would still be helpful to have that field there, and maybe have it auto-fill in based on which listed locations match.
• The button to go back is labelled "View list of items", which isn't very intuitive.
• It has a filter for "main subject" and "depicts", but after uploading something to Commons the structured data will only ask you what it depicts - and only ask you to add a maximum of 3 labels, presumably to prompt people to think about what the main subjects are rather than add items indiscriminately. So I think it might be better to only have a filter for "depicts"?

ReneeWrites (talk) 22:26, 4 February 2025 (UTC)

Thank you for the feedback! The UI-related comments definitely make sense - I will keep those in mind. The only thing I disagree with is removing "main subject" - I can think of various ways where what is being depicted is different from the main subject; certainly I would think that's true for audio files, where nothing really is being "depicted". Yaron Koren (talk) 00:36, 5 February 2025 (UTC)

I tried it again and it still only returns 6 of 40000++ files with Creator search and none with contributed-by search. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:17, 5 February 2025 (UTC)

It comes up with only 1662 files for location "Berlin" (there are hundred thousends of Berlin images, I alone made more than that). With added filter "publication date" there are none (at least a large number of my uploads have a depicts value that does not contain the publication date, but the date the images or videos were taken at). For example File:FFF Berlin Fahrraddemo 092.jpg contains depicts "Fridays for Future protest in Berlin 6 September 2019" -> d:Q73150789 which contains Location=Berlin and point in time=2019-09-06 C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:27, 5 February 2025 (UTC)

In think the tool uses the query service that is not capable of recursive search. GPSLeo (talk) 06:54, 5 February 2025 (UTC)

Well, the main issue is that that data (location = Berlin, etc.) is on Wikidata, not on Commons; and Commons Walkabout only gets its data from Commons. (Except for the language-specific label of each Q and P item, which it does get from Wikidata.) It would be great if the site queried both - so that you could get every file depicting something that in turn is located in some country, for instance - but unfortunately that's not supported yet. Yaron Koren (talk) 15:36, 5 February 2025 (UTC)

More accurately, for the particular images, the data that would say that the picture was taken in Berlin is neither in SDC nor in Wikidata. @GPSLeo: I suspect you are looking at location (P276). The relevant SDC property would presumably be location of creation (P1071), which I'm sure is way underused. (Do let me know if you already knew that; I know you're an advocate of SDC and have looked at this more than most, so I wouldn't want to presume I know this better than you.)

This gets back to something I've been saying for years: yes, we have the technical means to describe plenty of things in structured data, but the modelling is often unintuitive, is not documented in a manner that would give the average user much of a chance to get it right, and we have an almost complete lack of tools to help anyone through the thicket. - Jmabel ! talk 21:45, 5 February 2025 (UTC)

But even using location of creation (P1071) would not help here as I would never use Berlin (Q64) as a value there but the neighborhood or even the street as the value. GPSLeo (talk) 21:05, 6 February 2025 (UTC)

It works well with depicts. I looked up d:Q117075694 (rail vehicle door) and it works well. However I would like to use combinations such as train doors and d:Q22986165 (swerve-swing door). As seen in Category:Rail vehicles swerve-swing doors.

Location is problematic. I only use location in a depict, if it is relevant. For example for train stations I only use station name in depicts if the station or part of the station is visible. If only a train is visible, and this picture could therefore have been taken anywhere, I use the station name in SD parameter location.Smiley.toerist (talk) 11:18, 7 February 2025 (UTC)

Category:Media from YouTube

Could anyone with a bot help me diffuse this category? I know the categories are placed by the template but surely there must be a workaround because this is an absolutely mess Trade (talk) 22:33, 4 February 2025 (UTC)

I think we need a template like Template:YouTube_CC-BY_screenshot  $999$REAL 💬 ⬆   16:07, 5 February 2025 (UTC)

SDC property on the nature of audio track？

I made videos of something like Category:Automata. I put a piece of music in place of the environmental sound captured. I will explicitly say in description that the music is added in postproduction and not the sound from or around the mechanical device.

I wonder, is there / should there be an sdc property about the nature of audio track of a video? in order to specify: live sound, or mix of sound recorded live and sound recorded elsewhere / at a different time, or purely sound recorded elsewhere / at a different time? RoyZuo (talk) 22:52, 4 February 2025 (UTC)

Not sure, but at least one other relevant question is whether the sound, if not recorded on the spot, is intended as wikt:diegetic or not. - Jmabel ! talk 00:39, 5 February 2025 (UTC)

February 05

Photo challenge December results

Footprints: Entries • Votes • Scores

Rank	1	2	3
image
Title	Hund im Herzen	Pawprints of hares in freshly fallen snow	Track on sand
Author	Ilka Franz	Slottsviken51	Saral Shots
Score	18	13	11

Pastels: Entries • Votes • Scores

Rank	1	2	3
image
Title	A piece of pastel colors rainbow mille crepe cake and a piece of strawberry cream mille crepe cake	Red Arrows flying the "Tornado" manoeuvre in evening light	Foggy morning
Author	Junyu-K	Julian Herzog	BogTar201213
Score	23	10	9

Congratulations to Ilka Franz, Slottsviken51, Saral Shots, Junyu-K, Julian Herzog and BogTar201213. -- Jarekt (talk) 02:40, 5 February 2025 (UTC)

Is there a tool for checking if your image was used on a Wikimedia project?

This is surely vanity, but I find it encouraging to see my uploads being used on Wikipedia and the like. I can go through Special:ListFiles and just check the description pages of each of my uploads, but it’s tedious! And it also shows me images that I added to Wikipedia myself, which is not as encouraging. Does anyone know of a tool that would aggregate this data? If not, is the “File usage on other wikis” list available by some API? I think I could hack together a tool, probably. Theanswertolifetheuniverseandeverything (talk) 11:52, 5 February 2025 (UTC)

@Theanswertolifetheuniverseandeverything: GLAMorous lets you track usage statistics by category and by user. ReneeWrites (talk) 12:07, 5 February 2025 (UTC)

For apis you have prop=globalusage (keep in mind you can use that with generators) for example: https://commons.wikimedia.org/w/api.php?action=query&generator=allimages&gaiuser=Theanswertolifetheuniverseandeverything&gaisort=timestamp&formatversion=2&prop=globalusage&gailimit=max&gulimit=max another option is toolforge wikireplicas contain an sql database with a globalimagelinks table, which you can query at https://quarry.wmcloud.org/ Bawolff (talk) 15:41, 5 February 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 12:55, 6 February 2025 (UTC)

February 06

More on the UK's Online Safety Act

Further to recent discussion of the en:Online Safety Act 2023, this new blog post about the OSA raises some interesting points; not least these statements from Ofcom (the body responsible for enforcement):

Whether you are an adult service that only provides that kind of content, or whether you're a [general service] that doesn't prohibit that kind of content, the requirement is the same: to use age assurance.

and

The requirement is if you allow this type of content, you need to use highly effective age assurance to prevent children from accessing it. [...] The act makes clear that this is now a cost of business to do that type of content and provide that type of content.

and:

If you've got a site that doesn't have any kind of login process [read: or allows access without one, as does Commons], you might consider age-assuring each unique user and doing it each time.

Is anyone (at WMF?) monitoring this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:27, 6 February 2025 (UTC)

A new group for data preservation is emerging

Hi!

You might be interested in a new group that focuses on saving huge loads of data that are at risk to be lost. As its goal is to provide (and) free endangered information, it is similar to the scope of projects like Commons. Take a look here: https://fedihum.org/@SafeguardingResearch. Commons has a similar issue to save CC Sketchfab files before they will be removed soon

Greetings --PantheraLeo1359531 😺 (talk) 18:25, 6 February 2025 (UTC)

Two guidelines contradicting each other

Bjh21 has pointed out that Commons:Ownership of pages and files contradicts COM:OVERWRITE. It tells people to "be bold" in improving images. Unsurprisingly, that advice dates from 2007 and has never been changed to reflect the later COM:OVERWRITE. Also related Commons:Be bold was completely rejected and removed as policy in 2022, replaced by Commons:Don't be bold. I would presume Commons:Ownership of pages and files should be brought in line with COM:OVERWRITE, but (in the spirit of "don't be bold") wanted to check here to see if anyone thinks this needs any discussion.

Also, Commons:Ownership of pages and files gives {{GFDL-self}} as an example of a good license to use. Surely that should be updated. - Jmabel ! talk 22:14, 6 February 2025 (UTC)

 Agree on all points. ReneeWrites (talk) 23:00, 6 February 2025 (UTC)

Given that it's been about 24 hours with no objections, I'm going to risk being bold about this. Jmabel ! talk 22:04, 7 February 2025 (UTC)

This proved to be a rather major edit. I hadn't realized how deep the conflict ran until I started editing. Updating what licenses we refer to should be completely uncontroversial. [https://commons.wikimedia.org/w/index.php?title=Commons:Ownership_of_pages_and_files&diff=next&oldid=995284158 Bringing this in line with COM:OVERWRITE proved to be major—it almost reversed the sense of the section—but I think what I wrote is in line with our current thinking. I won't be surprised if it needs further moderate editing, though. - Jmabel ! talk 23:06, 7 February 2025 (UTC)

February 07

Incorrect wikilink in metadata

Some photos (for example, File:Housefromfield.jpg) are taken using a phone manufactured by Sonim Technologies, Inc. (No enwiki article; web site at [2]). The metadata for these photos looks like this:

Camera manufacturer

Sonim

Which would be okay, except that the text "Sonim" is linked to the enwiki article on Sonim, a Korean singer, not to any article having to do with the company Sonim Technologies. Surprisingly to me, there is no enwiki article for the company. The metadata for some Commons pages (such as File:A 1938 Jerrycan (in original state and restored).jpg) use "Sonimtech"instead of "Sonim", but no such article exists.

As far as I know, the singer Sonim has no relationship with the company Sonim Technologies.

Q1: How can this be corrected? I see nothing in the source for File:Housefromfield.jpg, for example, that shows that linkage.

Q2: I see many such examples in Category:Taken with Sonim mobile phones and its subcategories. I don't know if that's exhaustive. Is there a way of finding all the images that erroneously link to Sonim (i.e., the equivalent to "what links here", but cross-wiki)? TJRC (talk) 02:02, 7 February 2025 (UTC)

You may be interested in taking a look at the {{Exif-make-value}} and {{Exif-model-value}} templates, which are used to form these links. It looks like they have a couple of special cases for certain manufacturers already. Omphalographer (talk) 04:24, 7 February 2025 (UTC)

It's wild, there are French, Arabic, German and Swedish articles on Sonim Technologies but none in English. Someone should translate one of the others.

facepalm w:Wikipedia:Articles for deletion/Sonim Technologies Bastique ^{☎ let's talk!} 05:04, 7 February 2025 (UTC)

I wonder if those should be linked to Wikidata items instead of Wikipedia articles in general. whym (talk) 12:22, 7 February 2025 (UTC)

That'd certainly be better than the current state of affairs, which links directly to the English Wikipedia (regardless of the user's selected language) - but, to do that, we'd need some way to map from the name in the EXIF tags to a Wikidata entity. I'm not sure that exists - there may not be entities at all for individual camera models, in fact. Omphalographer (talk) 18:41, 7 February 2025 (UTC)

Germany according to the far-right agenda

I have drawn a map of Germany according to far-right agenda (e.g. The Republicans, National Democratic Party of Germany, Alternative for Germany...). Is it worth uploading or are there problems? Carnby (talk) 12:45, 7 February 2025 (UTC)

Apart from that you'll get into a quagmire of politics, I fear that's quite the duplicate from the Reich in its borders from 1937 or 1938. Despite that, an upload wouldn't IMHO fail the mandatory Commons scope clause, but I'd advise that you'll name the sources for the claims of borders represented on the map in its description. Better yet, make a colour coding of the claims of those different parties! Regards, Grand-Duc (talk) 13:18, 7 February 2025 (UTC)

Thank you.-- Carnby (talk) 17:05, 7 February 2025 (UTC)

If you include references in the file description (not necessarily in the map itself), like which part is coloured according to whose claim when and where, it'll be a good illustration of the topic.

Commons hosts far many more useless fantasy maps. Your map if backed up by references is surely more valuable than those.

Another potential problem you might wanna consider though, is how comfortable you are about a file related to real-world controversies being associated with you. RoyZuo (talk) 17:20, 7 February 2025 (UTC)

 Info The "Nationaldemocratic Party" has been renamed to "Die Heimat" recently --PantheraLeo1359531 😺 (talk) 19:09, 7 February 2025 (UTC)

Word, category for fruit defect？

is there a professional jargon for this kind of marks on an orange? The dent is not at the top or bottom that each orange has, but in the middle of the fruit. It's not deep enough to reach the pulp. Doesnt seem to fit under existing subcats of Category:Imperfect fruit? RoyZuo (talk) 20:10, 7 February 2025 (UTC)

How to specify rtl

in File:Singapore-Expatriates-1973-74-WUS08223.jpg, i just added a note.

the chinese shop name, in the natural order, is "勝發公司", but as it appears physically, is rtl "司公發勝". how do i record this info accurately in file description / sdc?

like {{templatertl|勝發公司}} rendering 司公發勝, so that both search can read the wikitext correctly as "勝發公司" and humans can see that it matches the picture as "司公發勝"? is there such a template?

another similar problem is chinese text appearing vertically, like File:灣仔 Wan Chai 軒尼詩道 Hennessy Road 東方小祇園 Tung Fong Siu Kee Yuen 霓虹燈招牌 Neon Sign, 2020.jpg. RoyZuo (talk) 21:06, 7 February 2025 (UTC)

Us gov Flickr accounts

Hiball, I apologise ahead for this political post but I think it is worth attention.

The us govt Flickr accounts such as USAiD probably are at risk of deletion. As news say, the employees count have been reduced by 90%.

The files on the flickr accts are listed with copyrighted tag but ID imagine tney proabably are works of the us gov employees themselves.

Possibly treat them as public domain. SeichanGant (talk) 21:46, 7 February 2025 (UTC)