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 Categorization of SVG files (13 February 2025) 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)

This is great news! I've been using Vector 2022 here for over a year now without issue, and it's important that Commons looks the same to users as the other Wikimedia projects. Thanks. Mike Peel (talk) 19:25, 10 February 2025 (UTC)

Personally I'm hating it.StarTrekker (talk) 07:06, 11 February 2025 (UTC)

I think I don't like some things either. However, it takes some time to get used to it and afterwards one likes it more than the prior skin. It would be good to name some things that may be problematic if there are any so it could get improved upon. For example, I think it may make the links to the Welcome and Community portal pages and possibly a few other things like the link to the page information page with the Pageviews link too hard to find. Prototyperspective (talk) 13:18, 11 February 2025 (UTC)

I think the links to the Wikipedia articles are now too hidden, especially for users not very familiar with the site. I think the Wikipedia article of the language the user has configured with a fallback to the English article if there's no article in that language should be linked well-visibly, for example right before the category description at the top of the page. Prototyperspective (talk) 18:14, 12 February 2025 (UTC)

It has been around for a quite long time in Wikipedia and other wikis. Software changes are often disruptive at first, but once you get used to them, you don't want to go back. MGeog2022 (talk) 18:30, 12 February 2025 (UTC)

Amazingǃ Comfortable visual consistent across the projects. Thanks. Ong Kai Jin (talk) 13:02, 11 February 2025 (UTC)

@OVasileva (WMF) @SGrabarczuk (WMF): I think it makes sense as a whole. But there are a couple of things that I don't understand and that I think are relevant to all readers and users. I suppose this has been discussed before.

• I don't really see how other Wikimedia projects are "Tools." I doubt readers will look for them there. It also doesn't seem ideal to have to scroll in a drop-down menu, in a lot of cases. Why not a separate "In other projects" tab?
• In the file namespace, perhaps the "Download," "Use this file" etc menu shouldn't be to the right of the previewed filed, since it can overlap awkwardly with the default position of the "Appearance" settings. Or is it an intentional choice that "Appearance" can overlap with other elements?

Sinigh (talk) 14:18, 11 February 2025 (UTC)

I've seen Appearance panel was overlapped on right side. [1] -- Great Brightstar (talk) 05:39, 16 February 2025 (UTC)

• I've just edited Commons:File_renaming to match the new skin. Is the "More" menu completely replaced by "Tools"? CMD (talk) 08:28, 16 February 2025 (UTC)

  Yes, I can see the "Rename" link in the "Tools" menu after logged in. -- Great Brightstar (talk) 17:43, 17 February 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)

Agreed Trade (talk) 03:34, 10 February 2025 (UTC)

And there's another concern, that the small star version of the revolution flag has closer resemblence to what the transitional government actually uses in diplomatic occasions, so that's the more important issue. —— Eric Liu_（Talk） 09:03, 10 February 2025 (UTC)

I think this is a sensible way forward. I'd only add that the wait time should not be long. The longer the wait time, the more jury-rigged workarounds are put in place to get the revolution flag to display, which will then have to be corrected back to the proper name. Wburrow (talk) 15:36, 17 February 2025 (UTC)

February 03

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)

February 04

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)

A sockpuppet account again: ApMalResbmou Tonuyz (talk · contribs) 興華街 (Hing Wah Street) - 💬 - 📝 06:24, 10 February 2025 (UTC)

A sockpuppet account again: Safoule 2558 LausldM (talk · contribs) 興華街 (Hing Wah Street) - 💬 - 📝 07:15, 17 February 2025 (UTC)

As this is primarily an issue on Commons (if it is really an issue at all), Commons:Administrators'_noticeboard/User_problems#User uploading own pictures over multiple usernames should be sufficient. I have no idea why this discussion had to be moved to Meta. By the way, I also agree with RoyZuo. --Robert Flogaus-Faust (talk) 14:34, 17 February 2025 (UTC)

@Robert Flogaus-Faust As I know someone did mentioned this problem long ago but ended up with no actions to block the user. Even if someone mentioned this problem in the future, I think solving this in Commons alone would only do zero effort to stop this up. And also, @RoyZuo, as the user did not mention any reason (by now) to create sockpuppets for just uploading photos, the prediction of that user whether it was doing malicious actions is currently unknown. But the only prediction is that the user would not like to be disturbed or informed by any communities here on Commons. For me, in particular, strange names are already suspicious to represent a user given that multiple strange usernames were used over the past few years (over 600). 興華街 (Hing Wah Street) - 💬 - 📝 10:58, 18 February 2025 (UTC)

So there is still no proof at all, just a ton of suspicion. The admins on Commons have not taken any action against the user so far in spite of at least two attempts from you to get this user blocked. So your idea is very recent and IMO wrong that solving this on Commons would not help. Tracking the accounts in the sockpuppet category is sufficient. I suggest that you prove that the user is malevolent or a vandal before taking any further actions. And I also suggest that no admin action is required at the moment (as discussed on Commons). Sorry. --Robert Flogaus-Faust (talk) 11:26, 18 February 2025 (UTC)

So I just have to convince Jeff G. to change his mind (he, just like mine originally, is sceptical of what this user is doing and want it to be blocked). 興華街 (Hing Wah Street) - 💬 - 📝 05:44, 19 February 2025 (UTC)

@HingWahStreet: I posted to m:Requests for comment/Blatant sockpuppetry in good faith again.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:36, 19 February 2025 (UTC)

A sockpuppet account again: ALB 302 AOE woapsing (talk · contribs) 興華街 (Hing Wah Street) - 💬 - 📝 14:46, 22 February 2025 (UTC)

February 07

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)

You mean they will be deleted on flickr? --PantheraLeo1359531 😺 (talk) 14:47, 8 February 2025 (UTC)

I'm concerned they will be deleted. SeichanGant (talk) 15:16, 9 February 2025 (UTC)

Fyi, @SeichanGant @Trade & @PantheraLeo1359531

• At least three U.S. Government Flickr accounts have already been heavily deleted. Many thousands of photos recently vanished from these sources of Public Domain photos. Unknown 1,000's of photos were never uploaded to Commons from these three Flickr accounts. -- Ooligan (talk) 10:35, 15 February 2025 (UTC)

@Ooligan, which three were deleted? SeichanGant (talk) 17:46, 17 February 2025 (UTC)

Three recently censored U.S. Government Flickr accounts containing Public Domain photographs are below, @SeichanGant.

United States Secretary of Defense Flickr account.

• 37,378 photos on February 1, 2025

https://web.archive.org/web/20250201194336/https://www.flickr.com/photos/secdef [2]

• 84 photos on February 9, 2025

https://web.archive.org/web/20250209065440/https://www.flickr.com/photos/secdef/ [3]

- Note 1 - The total number of photos is found on the top right of the Flickr page, just below The Pentagon photograph.

- Note 2 - This Flickr account was continuously maintained since 2011.

+++++++++++++++

United States Department of the Interior Flickr account.

• 4,978 photos on January 14, 2025

https://web.archive.org/web/20250114213030/https://www.flickr.com/photos/usinterior/. [4]

• 1,096 today.

https://www.flickr.com/photos/usinterior/ [5]

+++++++++++++++

United States Environmental Protection Agency Flickr account.

• 8,225 photos on January 20, 2025

https://web.archive.org/web/20250120123618/https://www.flickr.com/photos/usepagov/ [6]

• 0 photos today.

https://www.flickr.com/photos/usepagov/ [7]

- Note 3 - Nineteen Eighty-Four, Chapter 3, 3rd Wikiquote. -- Ooligan (talk) 09:36, 18 February 2025 (UTC)

Typically you need someone to manage a Flickr account to maintain it Trade (talk) 02:34, 10 February 2025 (UTC)

What would be the best solution? Should one user cover one USGov Flickr account and archive their images here? --PantheraLeo1359531 😺 (talk) 10:41, 15 February 2025 (UTC)

Probably best to suggest it to Commons:Bots/Work requests and see if multiple bots can split the task. Ricky81682 (talk) 05:06, 17 February 2025 (UTC)

Thanks for this suggestion @Ricky81682. Have you had positive results with a bot work request? -- Ooligan (talk) 09:38, 18 February 2025 (UTC)

It's been years but I recall yes when I was incredibly specific with my request. The bot operator has to design the parameters and get approval so they need estimates on the size of the task. Ricky81682 (talk) 06:57, 19 February 2025 (UTC)

Ricky81682, I will go file one immediately. SeichanGant (talk) 17:46, 17 February 2025 (UTC)

February 11

Frame of the {{Decade years navbox}} disappeared

I've found today that in pages using {{Decade years navbox}}, the frame of the navigation boxe is no longer shown (example). The code of the template seems unchanged. Is this being caused by the new appearance setting of commons? --トトト (talk) 08:25, 11 February 2025 (UTC)

It seems so, the template uses {|class="toccolours"}, and I tested it. In the old skin, {|class="toccolours"} displays the frame by default, but in the new skin, the frame will not display by default. Tvpuppy (talk) 09:29, 11 February 2025 (UTC)

toccolours is not guaranteed to be defined. Also this doesn't seem to be a navbox, so the template is misnamed. I advise rewriting it with TemplateStyles. —TheDJ (talk • contribs) 09:52, 11 February 2025 (UTC)

Fixed for now by changing it to class="navbox", which is styled via MediaWiki:common.css, making TemplateStyles unnecessary. (For very heavily used styles, common.css is more efficient than TemplateStyles; this template isn’t that heavily used, but if navboxen are already styled via common.css then we might as well reuse that here IMHO.) Lucas Werkmeister (talk) 20:34, 11 February 2025 (UTC)

• Thank you all for the tips and the edit. But the template became always full-length in the page; it used to be flexible depending on the contents in the box. Isn't there a method to keep it as class="toccolours" but still displaying the frame? There are hundreds of local templates that need to be fixed (example). I am a little annoyed at why WMF did such a skin change which necessitates a large number of edits. --トトト (talk) 23:20, 12 February 2025 (UTC)

  For the frame to be flexible around the content, the width has to be specified as automatic, like this: class="navbox" style="width:auto". Tvpuppy (talk) 01:23, 13 February 2025 (UTC)

• Thanks. I think I've found another solution. How abou not using any CSS class at all? {| style="border-style: solid; border-width:1px; background-color:#f5f5f5;" I have tested it at {{Kitakyushumonth}} (diff) --トトト (talk) 01:37, 13 February 2025 (UTC)

  This is a good idea, but it doesn’t not work for users with dark mode. Tvpuppy (talk) 01:48, 13 February 2025 (UTC)

  Alternatively, I found out that class="catlinks" also works. Tvpuppy (talk) 04:10, 13 February 2025 (UTC)

• Beautiful! With class="catlinks" a fix will become minimal and easy. And it also works with the black skin. If it is OK to letting it be the ultimate solution, I will start fixing the whole lot of navigational templates. --トトト (talk) 09:46, 13 February 2025 (UTC)

  Do know that .catlinks includes a clear:both;, which can be troublesome in some cases. Also, it's again a really hacky solution. Sjoerd de Bruin (talk) 14:05, 13 February 2025 (UTC)

• Currently I see no problem with using class="catlinks" in navigational templates (example, diff). If a problem arises, then I'll think about another coding. 00:25, 14 February 2025 (UTC)トトト (talk) 04:35, 16 February 2025 (UTC)

Making dark mode available for logged out users

Hi, so now that Vector 2022 is available by default, I think we can make dark mode available to all logged out users. I have worked quite hard to help make Commons dark mode compatible, and so have other users through replacing everything with Codex tokens, CSS styling changes etc. You can test dark mode compatibility in beta features and I think it is ready, thoughts? —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 19:47, 11 February 2025 (UTC)

@Matrix: Would you please look into making VFC compatible with dark mode?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 20:28, 11 February 2025 (UTC)

Sure —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 20:42, 11 February 2025 (UTC)

support —TheDJ (talk • contribs) 12:23, 12 February 2025 (UTC)

Yes, please do that as dark mode is important and there are many large issues with the Commons app which already has dark mode. Prototyperspective (talk) 15:41, 12 February 2025 (UTC)

@Matrix: Thanks for doing that work, I'm using dark mode now. I'm noticing that the normal body text on this page is not using the intended color (--color-base / #eaecf0) in dark mode, but a much brighter and less confortable #f8f9fa (compare en:Wikipedia:Village_pump_(technical)). I'm not sure where this is happening, if I manually change the color to things other than #eaecf0 it sticks, but #eaecf0 is transformed to #f8f9fa somehow. – BMacZero (🗩) 19:57, 14 February 2025 (UTC)

@BMacZero: It works perfectly for me. Are you sure it's not a user script or something? —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 16:06, 15 February 2025 (UTC)

@Matrix: Hmm, okay. I tested it on a blank copy of Firefox and I don't think I have any on-wiki appearance stuff. I'll try to dig more. – BMacZero (🗩) 17:23, 15 February 2025 (UTC)

@BMacZero: The only place here using f8f9fa is the top header saying "Welcome to the Village Pump". I can't find anything else. Could you screenshot your browser console showing your CSS? If you need help with this let me know —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 17:47, 15 February 2025 (UTC)

@Matrix: Well this is weird - today the body text is the correct #eaecf0 in Edge, Firefox, and Chrome for me, but section headings are still #f8f9fa in Edge and Chrome (but the correct #eaecf0 in Firefox). It does seem like those are also intended to be #eaecf0, so I grabbed that screenshot in case it's helpful. Pretty bizarre, if you do think it needs to be chased down more let me know if you want anything else.

I will also note that I'm almost certain that subpixel rendering was not working on any of the text yesterday but is working on both the body text and the section header today. – BMacZero (🗩) 07:29, 16 February 2025 (UTC)

Nevermind, --color-emphasized does seem to be intended for the section headings, so I think everything is working correctly on my end now. – BMacZero (🗩) 07:43, 16 February 2025 (UTC)

phab:T386560 created —Matrix(!) _{ping one}^{when replying} {user - talk? - _uselesscontributions} 16:09, 15 February 2025 (UTC)

February 13

Anyone recognize this photographers mark in lower right corner?

File:Rosalind russell.jpg I want to see if they registered or renewed copyrights. RAN (talk) 02:56, 13 February 2025 (UTC)

I can see Ros. 17. That's probably not a photographer's signature but No. 17 of a series of pictures. -- Herbert Ortner (talk) 21:12, 16 February 2025 (UTC)

"The watermark in the bottom right corner of the photo appears to read "Ross 17." This likely refers to the famous classic Hollywood photographer Ernest A. Bachrach, who often signed his portraits with a style similar to this. However, "Ross" could also be a reference to another studio or photographer from that era, such as "Ross Verlag," a well-known German postcard publisher specializing in movie star portraits in the early 20th century." sic ChatGPT JotaCartas (talk) 22:58, 16 February 2025 (UTC)

Help reverting very large files

Due to an issue with ffmpeg, certain AV1 video files (using the grain-synth features) used to fail to transcode. This issue has now been fixed (see File:Zaza (1923).webm, for example).

I have a few videos for which I uploaded a newer, inferior encode while we were waiting for the fix to roll out. I would now like to revert them back to the better AV1-GS encodes (from which the inferior encodes were later made), but I'm running into errors when I try to do the revert. I figure this probably has to do with the large file size. The reverts in question are:

• File:Cyrano de Bergerac (1950).webm - to the version uploaded March 2, 2024
• File:Night of the Living Dead (1968).webm - to the version uploaded March 2, 2024

Would an administrator be able to help revert these files? D. Benjamin Miller (talk) 18:35, 13 February 2025 (UTC)

@D. Benjamin Miller: I tried with the second file (I had visited it before) and got: "Request served via cp1104 cp1104, Varnish XID 377035162" and "Error: 503, Backend fetch failed at Thu, 13 Feb 2025 18:45:22 GMT". Similarly, with the first file, I got: "Request served via cp1104 cp1104, Varnish XID 370271423" and "Error: 503, Backend fetch failed at Thu, 13 Feb 2025 18:51:37 GMT".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:46, 13 February 2025 (UTC)

I get the same error. GPSLeo (talk) 19:15, 13 February 2025 (UTC)

Is there a phab: task yet?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 19:17, 13 February 2025 (UTC)

Error logs:

Wikimedia\FileBackend\FileBackendMultiWrite::doOperationsInternal: failed sync check: mwstore://local-multiwrite/local-public/2/24/Night_of_the_Living_Dead_(1968).webm, mwstore://local-multiwrite/local-public/archive/2/24/20250213183518!Night_of_the_Living_Dead_(1968).webm, mwstore://local-multiwrite/local-public/archive/2/24/20250101022713!Night_of_the_Living_Dead_(1968).webm
[b90a47bf-c3d4-4a3d-92f0-a7958d29f32e] /w/index.php?action=revert&title=File:Night_of_the_Living_Dead_(1968).webm   Wikimedia\RequestTimeout\RequestTimeoutException: The maximum execution time of 200 seconds was exceeded

You might have better luck downloading the old version of the file, and then reuploading with chunked upload. I know that is silly, but that will make the timeout be longer than 200 seconds. Bawolff (talk) 04:35, 14 February 2025 (UTC)

@Bawolff: Where to see this logs? Phương Linh (talk) 15:26, 14 February 2025 (UTC)

Its the private WMF logs. You need special access to see them Bawolff (talk) 17:51, 14 February 2025 (UTC)

@Bawolff and @D. Benjamin Miller: I finally was able to finish reuploading File:Night of the Living Dead (1968).webm and File:Cyrano de Bergerac (1950).webm for you. It seems that chunk size over 10MB contributed to my many failures.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:29, 15 February 2025 (UTC)

Thanks to @Racconish, @D. Benjamin Miller and @Jeff G. for the original and subsequent uploads of these great films here on Commons. Cheers, -- Ooligan (talk) 20:56, 16 February 2025 (UTC)

February 15

Category for passage from street to courtyard

At about this width, it becomes a breezeway.

looking for the commons cat for the thing discussed in https://www.reddit.com/r/architecture/comments/9bxcqd/ask_what_is_such_a_passage_called_that_connects/ , which is said to be "de:wikt:Hauseinfahrt" in german.

also, this pic shows tracks laid with steel plates. any jargon for this?--RoyZuo (talk) 08:03, 15 February 2025 (UTC)

Category:Passageways? (The steel plates are probably just for underground water runoff). --Adamant1 (talk) 08:12, 15 February 2025 (UTC)

The steel plates are for the wheels of motor vehicles or carriages to avoid damage to the tiles on the floor. They are very common in older German mixed residential and industrial/workshop buildings. I do not know if there is a special term for these but something like "Building passageway carriage tracks" could be a reasonable name. I would not use only "tracks" to not mix them with railway tracks. GPSLeo (talk) 09:50, 15 February 2025 (UTC)

@RoyZuo and Adamant1: See also Commons:Categories for discussion/2020/02/Category:Passages (architecture).   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:35, 15 February 2025 (UTC)

Also, if it's wider, it's a breezeway, but I see Category:Breezeways has some that are far narrower than where I think a native speaker would use that term, and should be recategorized as passageways. File:Seattle U - Engineering Building breezeway, looking south 03.jpg (at right) is close to the minimum to be properly a breezeway. - Jmabel ! talk 19:32, 15 February 2025 (UTC)

@Jmabel: Can you change the size of your image so it's not a part of my post? I tried to resize it but nothing happened. Thanks. --Adamant1 (talk) 04:36, 16 February 2025 (UTC)

February 16

Category:Categories by association

The whole category scheme of organizing things by "association" with Category:Categories by association seems rather half-baked and to ambiguous to be meaningful. It also goes against multiple things in Commons:Categories. So I was thinking of either axing it myself or at least started a CfD. But it's pretty well established and the CfD process seems to be totally worthless at this point. So I was wondering what other people think about the whole category scheme.

Just to give a couple of my issues, it's a child of Category:Clubs and societies when most of the subcategories have nothing to do with either one. I could just remove the parent category, but that would just leave Category:Categories by parameter which seems less then ideal. More importantly, it's not really clear what makes two subjects "associated" with each other or how organizing things this way is any different then doing it the 100s of other ways that already exist. I. E. by type, subject, topic, Etc. Etc. Everything in a subcategory is inherently "associated" with everything else in the category anyway. Therefore making something like Category:Categories by association totally pointless to begin with. Anyone else have an opinion about it though? Adamant1 (talk) 04:33, 16 February 2025 (UTC)

Yup, that is a total clusterf***. Also looks like it had nothing to do with clubs and societies for over a decade until W like wiki added that about 2 years ago. I suspect multiple intentions here, some of which might merit categories, but this shouldn't be the name of any of them. - Jmabel ! talk 05:35, 16 February 2025 (UTC)

The "Categories by..." title should be a warning sign. If the only way to sum up the contents of a metacategory is to describe the children as "categories", the category is probably too abstract. Categories on Commons exist to organize files - they shouldn't exist just for the sake of organizing other categories. Omphalographer (talk) 07:47, 16 February 2025 (UTC)

Duplicate Sanborn maps

What should be done with Category:Sanborn Fire Insurance Map from Middletown, Butler County, Ohio, 1901 and Category:1901 Sanborn Fire Insurance Map from Middletown, Butler County, Ohio? I don't have any issues with the images which seem to be from separate sources but I assume to merge the categories. There has been numerous categories organized with either naming convention but rather than a single vote, just a general poll of (a) keep separate; (b) Sanborn first; or (c) 1901 first or (d) something else. — Preceding unsigned comment added by Ricky81682 (talk • contribs) 08:40, 16 February 2025 (UTC)

If they are the "same" images, just from different sources/scans, I think it is useful to (a) keep them separate so we don't just have two slightly different duplicate sets mashed together. But in that case the categories should be renamed to clarify the actual difference between them. – BMacZero (🗩) 01:03, 18 February 2025 (UTC)

February 19

Issue with CfD talk page notifications

The notification message for CfDs that is place on people's talk pages seems to be broken as the link to the CfD is now showing up as "[[{{{2}}}|its entry]]." This has been happening for at least a couple of weeks. I tried to figure out where the issue might be coming from but it's not my area of expertise. I couldn't find the page for the template that sends the messages either. Is there a central board for getting broken templates fixed on here or does anyone know which one might be causing the issue? --Adamant1 (talk) 09:02, 19 February 2025 (UTC)

@Adamant1: Do you have an example diff?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:16, 19 February 2025 (UTC)

@Jeff G.: There's three examples on my talk page. --Adamant1 (talk) 13:53, 19 February 2025 (UTC)

@Adamant1: Thanks. This looks like a standard "Category discussion warning" using {{Cdw/layout}} as a part of {{Cdw}}. It is triggered by the "notify the creator of the category in their activated language" step of the Nominate category for discussion tool in the Tools menu on the sidebar provided by the AjaxQuickDelete gadget. Please make a section on MediaWiki talk:Gadget-AjaxQuickDelete.js, with an indication of the timeframe in which you think it started.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:36, 19 February 2025 (UTC)

February 20

Help for uploading works by a third party

I've written a draft of a help document Commons:Uploading works by a third party, largely inspired by the difficulties that Bloomagiliw experienced trying to do this as a new user. I suspect that their experiences were reasonably typical; all that was unusual was that they articulated more clearly than most the difficulties, frustration, and even near-trauma they encountered.

I'd appreciate further contributions to this new page on two fronts:

1. It's a wiki. Have at it. I'm sure I've overlooked at least one thing that is pretty important: there are so many issues involved, that there is no way I've thought of everything, especially because this is not something I often do.
2. There are two places where we should lay out step-by-step approaches using Commons:UploadWizard. I pretty much never use the wizard myself (I tried it a couple of times, which just confirmed that as an experienced user I'm better off with Commons:Upload), so I'm not the one to guide anyone through it. I would greatly appreciate if someone would flesh out those two sections, currently both marked with ">>>" in the draft document.

Jmabel ! talk 22:26, 20 February 2025 (UTC)

Thanks for this, it will certainly be useful. I already made some edits. See also the talk page.

IMHO this is already too complex. I don't think we should mention FoP or TOO in this page. We should just use simple cases: a picture of a person by another photographer, or getting permission for an artwork from the artist. For cases more complex, send them to the general policies. Yann (talk) 23:16, 20 February 2025 (UTC)

To be honest, I'm not at all unhappy with scaring people off of trying to make this very difficult task the first thing they do. Right now, we have a lot of people who wade in, fail, and then get angry. - Jmabel ! talk 02:40, 21 February 2025 (UTC)

February 21

Upload issues, classic upload form

Hello, since around 30 minutes, I have issues in uploading one of my photos. The servers return a 503:

Service Temporarily Unavailable Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes.

Request served via cp3066 cp3066, Varnish XID 454611988 Error: 503, Backend fetch failed at Fri, 21 Feb 2025 04:53:38 GMT

Request served via cp3066 cp3066, Varnish XID 463153079 Error: 503, Backend fetch failed at Fri, 21 Feb 2025 05:06:05 GMT

What's happening? Regards, Grand-Duc (talk) 06:02, 21 February 2025 (UTC)

@Grand-Duc: That looks like a bug, please see mw:How to report a bug.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 06:31, 21 February 2025 (UTC)

OK. As I retried it just now on another machine, with the same error, I did so: https://phabricator.wikimedia.org/T387007 . Regards, Grand-Duc (talk) 10:59, 21 February 2025 (UTC)

@Grand-Duc: With classic upload form you think of Special:Upload? Just a shot in the dark: How large is the file you intend to upload? As far as I know the classic upload form is not able doing chunked uploads. — Speravir – 01:23, 22 February 2025 (UTC)

Yes, that's what I meant, the special page is advertised as "classic upload form" in: "For experienced users of the classic upload form:

Already know the license, and its copyright tag? Go directly to the main upload form [...]." The file has less than 20MB - in fact, it's this one: File:Englischer Garten Meiningen, Gruftkapelle - 2020-04-22 HBP.jpg. I grudgingly switched to the UploadWizard to (successfully) upload it; I would still prefer to have the option to use my pre-filled {{Information}} template. Is less than 20MB beyond the threshold of chunked uploads? Regards, Grand-Duc (talk) 01:47, 22 February 2025 (UTC)

Mass-archiving of endangered US-government datasets

Hi!

The topic was raised in similar circumstances already, but I stumbled across a reddit thread that might be worth discussing: https://www.reddit.com/r/DataHoarder/comments/1iuhcu8/save_the_maps/.

As the government restructuring and reduction under the Trump presidency progresses, many datasets (up to many terabytes) are at risk. A user commented while adding some useful links to some resources. Several of them should be in public domain as they are created by federal agencies.

How should we deal with the part that is relevant for us?

(Mentioned in this subreddit:

• https://www.ncei.noaa.gov/data/
• https://www.ncei.noaa.gov/pub/data/cirs/climdiv/
• https://droughtmonitor.unl.edu/DmData/GISData.aspx
• https://www.nass.usda.gov/Data_and_Statistics/index.php
• https://search.earthdata.nasa.gov/)

Thanks! --PantheraLeo1359531 😺 (talk) 08:47, 21 February 2025 (UTC)

I wonder what the cost of merely keeping (not producing) those datasets is. The cost of storing that data should be almost negligible for US Federal Government (even after strong budget cuts), so it's striking that public data is being mass deleted. MGeog2022 (talk) 16:32, 22 February 2025 (UTC)

Sure that is striking. It's totally not my own priority on Commons, but I do hope that US contributors to the platform will try to archive that stuff either on other platforms where we will have access, or directly here on Commons.

Also, I do hope that WMF is quickly enough in relocating all Wikimedia datacenters to safe places in Europe before they are nationalized or switched off. --Enyavar (talk) 17:34, 22 February 2025 (UTC)

I agree that keeping those would not cost that much. But I think that many people don't recognise how important it is to archive and preserve files (how much images are flushed into the net, and the uploaders don't think far into the future how to handle historical files). Any some may have concerns that the data could be used against them someday (especially when making dubious claims). And yes, I hope WMF has sufficient backups and copies in the whole world. --PantheraLeo1359531 😺 (talk) 17:45, 22 February 2025 (UTC)

I hope WMF has sufficient backups and copies in the whole world: all text content (including full history) from all WMF wikis (Commons included) is periodically dumped to several mirrors worldwide, but most of them are also in the USA, and one of them is in Russia, which doesn't exactly give too many guarantees either. Out of the USA and Russia, there are only 2 mirrors: 1 in Brazil and 1 in Sweden. If we talk about media files in Commons, things look worse: there are no copies out of the 2 main WMF datacenters, both of them located in the USA (see here and the references section at the bottom of that page).

I think that wiki texts can generally be considered at safe (dumps are continuously downloaded here and there all over the world, at least for Commons, for Wikipedia in the major world languages, and many other specially notable wikis). As for the media files in Commons, this ticket has been waiting for years, with with very little progress.

In the meantime, it seems that Internet Archive continues to host the vast majority of its contents in a few rack cabinets in 2 places in the same seismic area (at least, there is no public information saying otherwise). After the first election of Donald Trump, they proposed to create a full copy of the Archive in Canada: there was no more news about it. After his second election, when it would seem that there should be more serious reasons for concern, there is no news about it either. The risk of earthquakes does not seem to be causing any major concern either.

Returning to Commons, let's hope that nothing happens, but I think more copies around the world would be highly recommended. Human beings usually only learn by making mistakes: I'd say that, if nothing changes, most of Internet Archive is very likely to be lost at some point in this century, since earthquakes will not stop hitting San Francisco, as they have for centuries, and a small fire destroying a group of 4 cabinets is something that can easily happen with or without an earthquake. At that (really sad) moment, a more resilient Archive would likely be built. Commons, having several copies in 2 distant datacenters in safe areas, is very likely to be in place by then, and to contribute many media content to the new archive. And, after that hypothetical catastrophe for the preservation of human knowledge, it's also likely that Commons itself will be mirrored in several more places, for greater security. MGeog2022 (talk) 20:34, 22 February 2025 (UTC)

By the way, if you think that things are bad now, about 5 years ago there were no true backups at all of Commons media files. Files were often lost simply due to bugs in MediaWiki software: no need for earthquakes or totalitarian governments. MGeog2022 (talk) 20:39, 22 February 2025 (UTC)

Just my two cents; I don't think that Commons with its ultra-strict adherence to copyright is really suited to reliably "archive" stuff. We regularly delete media for reasons such as "this 1939 nazi propaganda poster's author is unknown" or "this high quality photo of some building is very good, but some law does not allow commercial use of it". Only one law needs to change that might affect copyright status retroactively and we would be sitting here deleting stuff en masse. I think that the Internet Archive is a lot better for such archiving. ~TheImaCow (talk) 20:57, 22 February 2025 (UTC)

@TheImaCow, files deleted from Commons are not actually removed from WMF servers. They are taken in consideration even for backups, as if they were regular files. Copyvio files are often marked with a future undeletion date when they enter public domain (for example, 2072 or the like). Considering the problems facing Internet Archive, that I exposed above, I think that, for very long term preservation, Commons is far more reliable than Archive is, indeed (unless Archive starts taking backups seriously enough). MGeog2022 (talk) 21:08, 22 February 2025 (UTC)

AI-generated uploader

All of Special:ListFiles/Muskygirl appears to be AI-generated. Could someone tag all the images that violate personality rights for deletion? I'm a bit too lazy right now. Not sure what to do with the other images. Aaron Liu (talk) 20:24, 21 February 2025 (UTC)

They got speedily deleted. Regards, Grand-Duc (talk) 21:29, 22 February 2025 (UTC)

@Grand-Duc But the source is correct; they're just AI-generated. Aaron Liu (talk) 22:32, 22 February 2025 (UTC)

The reasoning for deletion wasn't "bad source", but "copyvio derivative", the images claiming as having been made by AI generative software and said to depict contemporary actresses can only be derived from unfree sources. Regards, Grand-Duc (talk) 23:09, 22 February 2025 (UTC)

Yeah, I realized. I meant to talk about the images without any personality that Artemisia just tagged as lacking a source. Aaron Liu (talk) 23:11, 22 February 2025 (UTC)

Wait, I didn't realize you meant the personality images, sorry. @ArtemisiaGentileschiFan The images don't necessarily satisfy the bad source SD criteria as they're simply AI-generated. Aaron Liu (talk) 22:34, 22 February 2025 (UTC)

@Aaron Liu: The ones I tagged don't seem AI-generated to me. The pants seem to be a photograph superimposed on a background with a paper texture and the gif and images of the necks seem to be cropped photos. ArtemisiaGentileschiFan (talk) 23:35, 22 February 2025 (UTC)

February 22

Actions regarding post-ban of Shāntián Tàiláng

• Shāntián Tàiláng (talk · contribs)

Yesterday this user was globally banned and now the user page was changed by me to indicate this situation (I have preserved all final revisions of the user page created by this user here in Commons, as well as in Meta, Wikiquote and Wikisource). I prefer not to request for a speedy deletion of its user page, because the previous edits seem to have its historic value. Also requesting is that the three-month local block for this user should be extended to indef to match the current ban status of this user. 興華街 (Hing Wah Street) - 💬 - 📝 08:23, 22 February 2025 (UTC)

because the previous edits seem to have its historic value. Maybe it isn't the case here, but if a previously good user suddenly turns to the contrary, it can be because his/her account was hacked, and the user completely lost access to it. In those cases, it would be a good thing that the user's page, talk page, contributions, etc, are indefinitely kept as they were, with all subsequent vandalisms reverted and revision deleted, and the account permanently locked (if there is no way to return the account to the user with due guarantees). I'm probably not the first one to think about this, and maybe this is how it is usually done already. MGeog2022 (talk) 16:25, 22 February 2025 (UTC)

Upcoming Language Community Meeting (Feb 28th, 14:00 UTC) and Newsletter

Hello everyone!

We’re excited to announce that the next Language Community Meeting is happening soon, February 28th at 14:00 UTC! If you’d like to join, simply sign up on the wiki page.

This is a participant-driven meeting where we share updates on language-related projects, discuss technical challenges in language wikis, and collaborate on solutions. In our last meeting, we covered topics like developing language keyboards, creating the Moore Wikipedia, and updates from the language support track at Wiki Indaba.

Got a topic to share? Whether it’s a technical update from your project, a challenge you need help with, or a request for interpretation support, we’d love to hear from you! Feel free to reply to this message or add agenda items to the document here.

Also, we wanted to highlight that the sixth edition of the Language & Internationalization newsletter (January 2025) is available here: Wikimedia Language and Product Localization/Newsletter/2025/January. This newsletter provides updates from the October–December 2024 quarter on new feature development, improvements in various language-related technical projects and support efforts, details about community meetings, and ideas for contributing to projects. To stay updated, you can subscribe to the newsletter on its wiki page: Wikimedia Language and Product Localization/Newsletter.

We look forward to your ideas and participation at the language community meeting, see you there!

MediaWiki message delivery 08:28, 22 February 2025 (UTC)

Method to add photos directly from Google Photos would increase uploads a great deal

Very often when I am looking through my photos on Google Photos I will see a photo it would be great to upload here. But I would need to download it, change the name, add my name and license choices, etc, etc, and frankly it's just too much effort 99̬̤% of the time. If a cooperation could be established with Google, where one of the options when we click on our own photos is to "share this photo on Wikimedia Commons", and it auto-fills our license name/info, allows us to rename the file if we want, and then a quick upload, for individual and groups of photos, I know I would upload much more often and assume many others would as well. I assume Apple has some equivalent photo storage as well. If Commons could approach these companies and see if the development of such a mechanism is a possibility, it could be a boon for the collection of photos here. RaffiKojian (talk) 13:36, 22 February 2025 (UTC)

Yes, this is my main way to upload. Looking at the photo in the Google Photos App, I click the Share button and Share With Commons App. The Commons App talks me through the upload process, asking me for a "Caption" which will actually be the the filename. It offers me a choice of "Depicts" and "Categories" and carries out the upload. Afterwards on the real computer and its browser, I do more categorization, insertion into whatever articles the pic can illustrate, and so forth. Jim.henderson (talk) 14:10, 22 February 2025 (UTC)

Delete duplicate without replacing filename

A file should usually have exactly one name. But there are (often mathematical) files with systematic names, where different names must lead to the same image. Often this is achieved, by uploading duplicates. (E.g. this category contains many duplicates, such as 4-demicube t02 D3 ... 8-demicube t06 D3, 9-demicube t07 D3.) Theoretically, the best solution would be, to upload the file with a neutral name, and then create redirects with the systematic names. (E.g. the neutral name is foo and bar, and the redirects are foo and bar.) But that is tedious and error-prone. Most people will not even consider that, and just upload duplicates. Those could be deleted using {{Duplicate}}. But that would lead to the automatic replacement of the old names in articles. (E.g. I have once marked 6-cube t0 B4.svg as a duplicate of 4-cube t0.svg, which lead to this replacement in the article 6-cube.) I want to propose a parameter for {{Duplicate}}, that will prevent this. (The redirects should go into a category called synonym redirects.) --Watchduck (quack) 14:21, 22 February 2025 (UTC)

Adding support for C2PA metadata to photos uploaded to Commons

A new initiative to help determine the provenance of an image, called “Content Credentials” has recently emerged as one way to help detect AI or otherwise manipulated images. Image editing applications, AI-generation tools, and camera makers are implementing these credentials in their products.

When an image that contains these credentials are uploaded to Wikimedia Commons, Commons should display this metadata alongside the image.

I created a this Phabricator task to consider the technical implementation of this idea. I’d love to hear what others think from a social and administrative perspective.

While few cameras today support this feature I think it would be a good idea to get ahead of things. :) Ckoerner (talk) 21:11, 22 February 2025 (UTC)