Commons:Village pump/Proposals

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

Shortcuts: COM:VP/P • COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Proposals/Archive/2025/11.

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

Please note

• One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
• Have you read the FAQ?
  
  

 

Start a new discussion

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

Adjust DR notice

Template:Idw

such that:

1. the 1st link from the top is the link to the actual DR (instead of Commons:Deletion requests now).
2. add some more visible signs that users should click that link and comment in the DR (instead of on their user talk pages). for example, something like

☞ <DR link> ☜

Reason: I notice that sometimes newbies reply under these talk page notices rather than going to the actual DR, so putting that link as the 1st should minimise this problem.

Here's a draft:

Some contents have been nominated for deletion at

☞ Commons:Deletion requests/Files in Category:1 ☜

This is a deletion request for the community to discuss whether the nominated contents should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

... RoyZuo (talk) 18:48, 16 September 2025 (UTC)

I think it would help if you can make a draft on how the new layout could look like. GPSLeo (talk) 19:43, 16 September 2025 (UTC)

•  Support It's a good idea in theory. Although like GPSLeo I'd like to see an example of how the new layout would look but the current template could definitely be clearer. --Adamant1 (talk) 00:45, 17 September 2025 (UTC)
•  Support moving from "its entry" to a bigger link as proposed; I'm open to any wording/formatting in case other options are discussed. -Consigned (talk) 10:47, 19 September 2025 (UTC)

Draft

A page has been nominated for deletion at Commons:Deletion requests/File:HK SW 上環 Sheung Wan 皇后大道中 Queen's Road Centra… This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much! If you created this gallery, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

I have created a draft template at {{Idw/en/sandbox}}, following the draft suggested by RoyZuo above. Feel free to change it as the discussion continues. Thanks. Tvpuppy (talk) 02:42, 17 September 2025 (UTC)

 Support - Jmabel ! talk 03:20, 17 September 2025 (UTC)

I would support this, but I notice the language "If you created this gallery". Deletion requests most commonly apply to a single image. Should the language of the notice be tweaked further? -- Ikan Kekek (talk) 06:06, 17 September 2025 (UTC)

That sentence was copied from the current template {{Idw/en}}, and the word “gallery” is just the default word used when it is viewed at the template page. When it is actually used, it will change according to the namespace of the nominated file. Thanks. Tvpuppy (talk) 12:25, 17 September 2025 (UTC)

Great! And  Support, accordingly. -- Ikan Kekek (talk) 16:00, 17 September 2025 (UTC)

I would put the link in a button in mw-ui-progressive style to be even more visible: Commons:Deletion requests/Files in Category:1 GPSLeo (talk) 08:06, 20 September 2025 (UTC)

+1 - Jmabel ! talk 17:52, 20 September 2025 (UTC)

I have changed the draft to include the button as you proposed, and I agree it is now more visible. Thanks. Tvpuppy (talk) 23:45, 20 September 2025 (UTC)

I don't expect the notification to be changed more then it has at this point but it would be cool if there something in it about how files aren't actually deleted and that the uploader can do an undeletion request. Since I don't know how many misunderstandings and/or confrontations I've gotten into because people don't know that their files aren't actually deleted and there's an appeal process. --Adamant1 (talk) 00:40, 21 September 2025 (UTC)

Is the emoji still necessary? It seems redundant to the blue button. (And to be honest, it makes it a bit like a spam email.) Also, length can be an issue. File names can be too long for a button (or a link that looks like a button anyway). It would be nice to use an ellipsis when the button label is too long. whym (talk) 03:16, 21 September 2025 (UTC)

You’re right, I don’t think the pointing emojis are necessary now since the button is very visible already, so I removed them from the button.

I also added a character limit for the DR title displayed on the button that will add an ellipsis for overlong titles. I’m not sure what will be a good limit, so at the moment I have set it to 50. You can see the changes in the example above. Thanks. Tvpuppy (talk) 18:30, 23 September 2025 (UTC)

1. my design is using the underline and the fingers to induce a strong subconscious urge to click the link.
2. the button is more prominent, but it breaks the design. to retain that visual link, the phrase "linked request" should be boxed up in the same style. still, it's also not obvious to new users that the blue box/button is actually a link.
3. however, my personal preference is to avoid css styles as long as it's not necessary. the fingers were part of unicode 1.1 introduced in 1993, so they should work just like most letters for most users even if they have really outdated devices, or their software stripped the website of anything but raw text, or they cannot load anything but the text for whatever reason, etc.

RoyZuo (talk) 16:26, 24 September 2025 (UTC)

If we are concerned to make it look good without CSS (I'm not sure we should be), we could include the fingers but have CSS hide them when it styles the button. - Jmabel ! talk 19:55, 24 September 2025 (UTC)

I like that Commons is usable from text browsers, but I don't think they are a priority, mainly because Commons is a media (often, graphical media) repository. In a text browser I use (w3m), the main link of Template:Idw/en/sandbox is bold, underlined, and horizontally centered. I personally think that is enough. If people feel strongly about using the emoji, it could perhaps be included in the link (instead of outside), though. whym (talk) 08:54, 18 October 2025 (UTC)

I propose to accept the current draft as the stable version for now. I realize RoyZuo might still be unhappy, but I'm afraid it looks like they are in the minority. Further tweaks can be discussed after that, perhaps at the talk page. whym (talk) 10:50, 15 November 2025 (UTC)

i'm not unhappy. i'm just pointing out design considerations that i believe are more foolproof, robust and simplistic. the identical styles of a link and the underline serve as a visual cue to click the link.

now a button and the underline dont form the visual cue. RoyZuo (talk) 10:57, 15 November 2025 (UTC)

The rest of MediaWiki (Vector skin) is styled like the draft, though. Emoji is not part of the styling. whym (talk) 11:11, 15 November 2025 (UTC)

 Support -- Ooligan (talk) 16:15, 22 November 2025 (UTC)

Is current limitation of cross-wiki uploads sufficient?

We recently enabled the limitation of cross-wiki uploads to users who are autoconfirmed on Commons. This reduced the uploads of copyright violations and out of scope content using this tool a lot. I now had a look at the current uploads from users whose account is three days old. This shows that there are still more problematic than good uploads. I looked at the last 100 Uploads: 30 of these uploads are definitely fine, 21 are obvious copyvios, 21 are definitely out of scope including 6 self promotion photos with also unclear copyright. The other 28 are unclear with some requiring VRT confirmation on copyright or local evaluation if a that bad quality graphic should be in the article. I therefore want to discuss if we need to limit this tool even more to only autopatrolled users. As only 3 of the last 500 uploads using this tool were from autopatrolled users this would be a de facto ban of the tool. GPSLeo (talk) 08:13, 2 October 2025 (UTC)

Do you have perchance data about the geographic provenience of the still-problematic uploads? Are there any obvious socio-demographic trends visible, are there any language editions especially prone for copyvio uploads?

I fear the the WMF won't take it gladly if the tool gets de facto banned, so more fact-based granularity in restrictions would be needed, if possible. That said, I'm fine with a restriction to "autopatrolled" in order to effectively stymie first copyvios and then OOS media. Regards, Grand-Duc (talk) 08:34, 2 October 2025 (UTC)

I will look if I can analyze the data in relation to this. The amount of uploads per project looks like a simple representation of the project size. I also noticed that uploads on non Wikipedia Wikis (Meta and Wikidata) were fine with all 14 from the last 500. GPSLeo (talk) 09:04, 2 October 2025 (UTC)

I created a dataset from the last 30 days with the number of files uploaded per Wiki and the amount of these files they are already deleted. GPSLeo (talk) 09:43, 2 October 2025 (UTC)

Autopatrolled on which wiki? On Commons? This might be too restrictive. For example, autopatrolled is given manually on Commons and I only got it when I had over 100,000 edits. If I remember correctly, I've even seen users with over 500,000 edits on here who still were not autopatrolled. Nakonana (talk) 05:41, 4 October 2025 (UTC)

Thank you for the datamining, GPSLeo. The dataset would IMHO support a further restricting of cross-wiki uploads to everything that is as bad or worse than the current all-Wiki average, meaning Incubator, AR, EN, ES, PL and RU, with FR data providing the cutoff. Then, we / you(?) do the same datamining in, let's say, 6 months (to catch possible avoidance movements). The other Wikis can currently keep the current status. Regards, Grand-Duc (talk) 06:07, 4 October 2025 (UTC)

Restricting by rights on an other Wiki is technically not possible at the moment. GPSLeo (talk) 07:20, 4 October 2025 (UTC)

Wasn't the restriction enforced by a filter? I thought that filtering for strings (like Cross-wiki upload from XY Wikipedia) would be possible. Regards, Grand-Duc (talk) 07:42, 4 October 2025 (UTC)

There is global_user_editcount in abusefilter which could be used as proxy? --Zache (talk) 10:41, 5 October 2025 (UTC)

This could be an option. Maybe with a requirement of 500 global edits? GPSLeo (talk) 14:00, 5 October 2025 (UTC)

@GPSLeo: No, I don't think it's sufficient. Granularly restricting by source wiki would work, if the filters could be configured that way. On the other side of the coin, all users who can cross-wiki upload here can also upload directly here if they want, bypassing any restriction passed here (source wiki or autopatrolled-here only); it's not a high barrier to public participation.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:58, 4 October 2025 (UTC)

The "other side" is not really a counter-argument, if you were thinking that way. I think that even low barriers are helpful, in the same train of thought as modified or blocked DNS records are widely employed for anti-piracy motions. They are not hard to bypass at all, but likely deter casual downloaders. So, if upload restrictions continue to be enforced, we'll also likely deter people who would possibly commit casual copyvios. Regards, Grand-Duc (talk) 04:25, 5 October 2025 (UTC)

Based on the short discussion and some statistical evaluation I would propose the the following limitation that would have prevented 2/3 of the deleted files to be uploaded.

Proposal: We limit the use of the cross-wiki upload tool to users who are (auto)confirmed on Commons and have more than 100 global edits. We do not discriminate based on the project. GPSLeo (talk) 09:34, 6 October 2025 (UTC)

I don't like the idea of cross wiki uploads at all, given all the negative issues that have surfaced, but limiting it as proposed seems good to me. Bedivere (talk) 12:16, 6 October 2025 (UTC)

What are some of those negative issues that have surfaced? whym (talk) 12:11, 9 October 2025 (UTC)

users disproportionally uploading copyright violations instead of good contributions. Bedivere (talk) 19:37, 14 October 2025 (UTC)

What made you believe that it's "disproportionally" so? Can you share data or other evidence to help others see what you see? I did some comparison against general uploads before [1][2] (quarry:94356, quarry:94443), and I found no significant difference there. whym (talk) 08:58, 18 October 2025 (UTC)

I posted about this on AN before I saw this. A lot of the files I see uploaded "while editing an article" are copyright violations, and many of the files that are good don't actually get added to the article. They just sit here uncategorized. Geoffroi 23:20, 4 November 2025 (UTC)

But how do you know if the amount of copyright violation is disproportionate there, or if it's just that there are many copyright violations on Commons in general, regardless of the upload method? As I mentioned, my data indicates the latter answer.

The lack of categorization is a separate issue, which my data mentioned above doesn't deal with (and I don't think it is what is primarily discussed in this section's proposal). Maybe a better solution for that is a bot to remind them for adding categories? whym (talk) 06:09, 9 November 2025 (UTC)

If you give more people the ability to upload images for the articles they're interested in, and simply the awareness that it's easily possible, you'll get more copyright violation images of notable people. As for the category and usage issue with good images, a lot of new users won't be able to figure out proper categories or how to place the image in an article. That's probably just how it is. Geoffroi 19:12, 9 November 2025 (UTC)

I think you are the only person who bring up notable people in this thread. How do you argue that it is the relevant? I'm not saying there is no such images at all, but I don't know if they constitute a significant enough amount in CWU, or CWU is particularly used to make such uploads. whym (talk) 00:33, 23 November 2025 (UTC)

How many good uploads would that have blocked? --Carnildo (talk) 21:18, 7 October 2025 (UTC)

!votes (limit cross-wiki uploads to confirmed on Commons and >100 global edits)

•  Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:59, 6 October 2025 (UTC)
•  Oppose seems to me to defeat the main purpose of cross-wiki uploads: that inexperienced users don't have to deal with two sites when developing content for one of our sister projects. "Confirmed on Commons" requires that they have actively edited Commons. Perhaps I could be convinced otherwise, but that is certainly how this strikes me. - Jmabel ! talk 15:01, 6 October 2025 (UTC)

  Perhaps the purpose of cross-wiki uploads was a mistake in the first place Trade (talk) 00:14, 15 November 2025 (UTC)

•  Support --Trade (talk) 20:37, 9 November 2025 (UTC)
•  Support – Most concerning is whether temporary accounts would circumvent one of the existing abuse filters. Also, I'm worried about Autoconfirmed and non-(Auto)confirmed users previously or still using temporary accounts. George Ho (talk) 21:09, 12 November 2025 (UTC); expanded, 21:13, 12 November 2025 (UTC); edited, 04:05, 13 November 2025 (UTC)
  • @George Ho: I don't follow any of that. How would a temporary account circumvent an abuse filter that would otherwise apply? And I totally don't get your second point: what scenario causes you to worry? - Jmabel ! talk 22:28, 12 November 2025 (UTC)

    Sorry for making unclear rationale. I just voted and mentioned "temporary accounts" because they've been released recently. Also, I'm also worried about sockpuppetry becoming harder to trace with temporary accounts hiding IP addresses currently. Also, I didn't want the whole abuse filter to be in vain, i.e. totally useless. I'll strike out the whole (unclear) rationale if you want me to. George Ho (talk) 22:59, 12 November 2025 (UTC)

    • @George Ho: Not asking you to strike it, just explain why you think the interaction of temporary accounts, cross-wiki uploads, and abuse filters creates special problems. As far as I can tell the main problems with cross-wiki uploads stem from user confusion and incompetence, not from anything malicious. And I don't see how temporary accounts would make things any harder to trace: for one thing, admins and a few dozen others will still be able to see the IP addresses if we need to, but for another each given temporary account will be stable for a reasonable period of time. A blocked IP will still be blocked, an IP disguised by a temporary account will still be readily trackable for its activity. You seemed to be suggesting these will somehow trick abuse filters, and I don't see the scenario. - Jmabel ! talk 00:10, 13 November 2025 (UTC)
      • Everything you said about the main problems with cross-wiki uploads and temporary accounts has made me reconsider the rationale I struck out just now.
        just explain why you think the interaction of temporary accounts, cross-wiki uploads, and abuse filters creates special problems Right now, I can't think one legitimately anymore. I'm more of an old-fashioned or old-school type, somewhat. I'm not very innovative when it comes to newer introductions, like temporary accounts. I mean, I've never thought about inventing such accounts... or other ways to legitimately hide IP addresses besides being a registered user.
        Well, I've been more concerned about how many edits would make that account promoted or something, like non-confirmed accounts becoming (auto)confirmed. However, then I read mw:Help:Temporary accounts, realizing now that such accounts last ninety days and that edits can't be transferred to registered accounts at all. Shows how "too" opinionated I am, like sports commentators I've seen onscreen. George Ho (talk) 04:04, 13 November 2025 (UTC)

      Now I remember: logged-out users still can't upload, right? George Ho (talk) 04:09, 13 November 2025 (UTC)

      @George Ho Yes, you can't upload while logged out, and I have tested it for good measure. Tvpuppy (talk) 04:50, 13 November 2025 (UTC)

•  Support What I see with these cross-wiki uploads is a lot of people reading articles about notable people and then uploading copyright violation images of those notable people or uploading good images that they don't know how to categorize or add to the article. I don't mind sorting through uncategorized images, but many of these uploaders are doing their first edits to a Wikimedia project, so something better could be done to help new users do constructive uploads and add freely licensed images to articles. Geoffroi 21:23, 12 November 2025 (UTC)

  Let's be honest. A lot of these are experienced Wikipedia editors who simply does not care as long as the article on their home Wiki gets illustrated without having to deal with the stringent Fair use policies Trade (talk) 00:13, 15 November 2025 (UTC)

  A lot of the copyvios I tag from these cross-wiki uploads aren't added to the corresponding article, something an experienced user would easily know how to do. Geoffroi 00:20, 15 November 2025 (UTC)

  Also, why wouldn't experienced users who want to upload a copyvio just upload them to Commons directly? I'm not seeing much gaming of license/source/author details either, as I would expect from experienced users. Geoffroi 00:25, 15 November 2025 (UTC)

•  Support -- Ooligan (talk) 16:29, 22 November 2025 (UTC)
•  Oppose Insufficient evidence to support yet. I appreciate Data:Cross-Wiki-Data.tab but how does it compare against non-cross-wiki uploads? We need baselines to compare and see if the proposal matches the severity of the alleged problem. (Or for that matter, to see if the current restriction matches it) whym (talk) 00:38, 23 November 2025 (UTC)

Are "Sum of all paintings" project galleries welcome on wiki commons?

Continuing and summing up a debate started on the administrators' noticeboard:

The Sum of all paintings project contains around a thousand pages, which are wikidata-backed automated lists (edited by Listeriabot) acting as galleries for paintings either made by specific artists or belonging to a certain museum. As was explained to me recently by @Jameslwoodward, gallery pages belonging to the Sum of all paintings project do not conform to COM:Galleries since they do not use <gallery></gallery> tags and a simple caption, and would better be placed on WP. This would imply the deletion of all existing or at least all new pages created using the Sum of all paintings preferred format, the reason why all the non-conforming lists were not deleted before being that their existence and non-conforming structure hadn't been noticed.

My two main arguments for the modifying of the COM:Galleries guidelines in order to allow the preservation of the project on wiki commons are:

• Similar lists on WP are entirely user-made, the commons lists are based on wikidata entries, and are thus completely different (compare this to this, 90 vs around 360 entries). Even copypasting the commons lists to WP would require scrutiny of a thousand lists of different artists in tens of different languages, to check that every entry unique to each project has properly been added to the final WP list.
• The commons lists are in fact duplicates of similar lists found on wikidata (compare here to here). The commons lists are however, due to the structure of commons, much easier to find, as they are properly placed in each painter's Paintings category. By comparison the wikidata lists are only accessible through this category and nowhere else, which is impossible to reach if one is not aware of the existence of the Sum of all paintings project. I must stress that this ListeriaBot automated list is actually one of its kind on the entirety on the Internet: there's basically no other website that present such a detailed global catalogue of paintings, which is much better ordered than the Paintings category, and much more complete than the lists present on WP, as it is wikidata-backed. I think it is in the interest of the scope of the project to make this list as easy to find as possible, which will not be the case if it can be found only on wikidata.

Pinging all previous participants to the discussion : @Jameslwoodward, Yann, Edelseider, Jmabel, and Schlurcher: , pinging contributors to Sum of all paintings project :@Mateus2019, Niketto sr., and Tzim78: , as their work would be affected by the debate. Ostrea (talk) 10:00, 11 October 2025 (UTC)

 Support Yes, these galleries are obviously useful. Yann (talk) 10:02, 11 October 2025 (UTC)

 Support. Edelseider (talk) 10:03, 11 October 2025 (UTC)

 Support. We should be more flexible with galleries including supporting wikidata-based tables. --AFBorchert (talk) 10:21, 11 October 2025 (UTC)

 Support Don't see why wouldn't. Prototyperspective (talk) 12:00, 11 October 2025 (UTC)

 Support One of the examples of a good gallery page long present at COM:Galleries does not use the <gallery> tag at all: Pronunciation of Dutch municipality names. Perhaps we should explicitly add one of these as another such example so that there is no doubt in the future. - Jmabel ! talk 12:56, 11 October 2025 (UTC)

 Support per Yann --Mateus2019 (talk) 13:04, 11 October 2025 (UTC)

 Support Especially comments by AFBorchert and Yann including suggestion by Jmabel. -- Ooligan (talk) 20:05, 11 October 2025 (UTC)

I fail to see what needs to be changed.

How are those pages not acceptable under the current version of Commons:Galleries?

No text and no one say a gallery (or a photo album as a synonym) must be made using <gallery> tags. RoyZuo (talk) 21:20, 11 October 2025 (UTC)

https://www.oxfordlearnersdictionaries.com/definition/english/gallery "a collection of pictures". RoyZuo (talk) 21:21, 11 October 2025 (UTC)

As I said at AN, "I don't understand why Commons should host pages that belong on WP -- there are many pages very similar to these on WP, so why should these be here rather than there? We are a repository for images and other media. We explicitly reject anything that looks like encyclopedic content, so allowing these pages will require not only a change to COM:Galleries, but also to Commons:Project scope." .     Jim . . . (Jameslwoodward) (talk to me) 12:59, 11 October 2025 (UTC)

• support - agree this seems like a good use of gallery pages, and support modifying the guideline accordingly — Rhododendrites ^talk |  13:53, 11 October 2025 (UTC)

 Support per Yann, as also stated on the noticeboard --Schlurcher (talk) 15:41, 11 October 2025 (UTC)

•  Comment @Jameslwoodward, Yann, Edelseider, Jmabel, and Schlurcher: As you might know, I started SOAP in 2014 and I'm probably still one of the more active contributors (wonder why User:Ostrea didn't ping me). We have lists at d:Category:WikiProject sum of all paintings creators and some other places. Back in 2021 User:Mateus2019 started copying these pages to Commons ([3] [4]). Felt more like quantity over quality. I'm quite unhappy how it looks now, so I'm with Jim on this one: In the current form these are not galleries and have no place on Commons. So if we are going to do this, we should change them to galleries like I did on Paintings by Johannes Vermeer. Make good looking galleries or delete them. Multichill (talk) 18:39, 11 October 2025 (UTC)

  The reason's simple: your and your bots' contributions to the project have been of course immense, but I do not think you have ever, except the improvement you've recently created, contributed to a Commons Sum of all paintings page, and the history of these pages were my only way to find out who is involved at all in this slice of the Commons side of the project. It was either this or pinging the first 10 members in the SOAP participants list...

  I have to say the change you're suggesting does look superior to the rather detailed but dry lists we have now... if there's consensus on using it instead of the current format, perhaps a change of rules wouldn't even be needed at all to solve the situation Ostrea (talk) 22:33, 11 October 2025 (UTC)

  @Multichill: It looks good; does this format still provide a decent approach to having a bot maintain it, and does it provide a decent way of indicating pictures for which we do not have images? - Jmabel ! talk 02:33, 12 October 2025 (UTC)

  @Ostrea: it's a wiki project so I created Commons:WikiProject sum of all paintings and Category:WikiProject sum of all paintings a long time ago. We have to look at the category. Probably just have a (hidden) tracker category to keep an overview of automatically updating galleries.

  @Jmabel: I found Category talk:Paintings by Piet Mondrian (pl), bit of a weird place. Had to patch the template so that it now shows File:No-Image-Placeholder-landscape.svg if no image is available.

  Other people also in favor of changing these into real galleries instead of changing our policies? Multichill (talk) 12:32, 12 October 2025 (UTC)

  If we currently do not consider foto-focused lists like Paintings by Édouard Manet - Wikimedia Commons as Galleries, then I'm in favor of changing our policies. In my understand they are. If there is an option to improve their visuals in this case, even better, but this is a separate discussion. As I understand from AN this started as a scope and policy discussion and imho this should not have been the case. --Schlurcher (talk) 12:46, 12 October 2025 (UTC)

  @Schlurcher: These big table lists have no place on Commons in the gallery namespace in the current form. What's the point of having an exact copy of d:Wikidata:WikiProject sum of all paintings/Creator/Édouard Manet here?

  If we go back to the original proposal:  Oppose updating Commons:Galleries to accept these big table lists. Multichill (talk) 13:18, 12 October 2025 (UTC)

 Support They look like a form of gallery to me. I don't see we need a change of project scope at all -- these are not primarily encyclopedic text, nor really even primarily of text. They are simply a listing of images with a bit more factual information about them. If we need a change of wording to COM:Galleries to allow these, then do it. Wikipedia seems to disdain image galleries (en:WP:GALLERY) thinking they are more of a Commons thing. These can't move to WP since they would likely just be deleted under their policy, that they should be moved to Commons. I think these are firmly inside Common's scope. It's just another way to display the media we have -- the images are the focal point. However, if the data is already stored on Wikidata, using a method to query that data and generate galleries that way (as opposed to copying the data) is probably preferable. Carl Lindberg (talk) 22:04, 14 October 2025 (UTC)

•  Question Would this information be better suited to the Data namespace?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 19:44, 11 October 2025 (UTC)

  @Jeff G.: I don't think so, because (unless I'm missing something) it wouldn't provide thumbnails of the pictures at all. - Jmabel ! talk 02:31, 12 October 2025 (UTC)

  @Jeff G.: the data is actually on Wikidata and is retrieved using a SPARQL query. The gallery is just a nice visual representation of it. Multichill (talk) 12:42, 12 October 2025 (UTC)

 Neutral Personally, I think gallery pages as a whole shouldn’t be hosted here and that most of them should just be deleted. If we want a nice visual overview of "good images" for a topic, that should be handled through a proper gallery view or improved category browsing, not random wiki pages pretending to be galleries. Since that's not what this discussion is about, I'll just !vote Neutral. I don't find these Wikidata-based pages any worse than stuff like Farsta, which honestly just makes Commons look neglected. At least the Wikidata ones maintain themselves. --Jonatan Svensson Glad (talk) 23:08, 14 October 2025 (UTC)

For the record, if gallery pages in general are dropped, I will leave the project. Feel free to hold me to that if it occurs. - Jmabel ! talk 00:12, 13 November 2025 (UTC)

I'd much rather see WMF (or someone) develop proper MediaWiki functionality for curating and displaying high-quality galleries than continue relying on these outdated wikipages with tiny thumbnails. Many of them have fewer than five images and haven't been touched in over a decade. A few are excellent, but most just duplicate the corresponding category, often with even less content. To me, that's not something to defend – it's a symptom of technical debt that we should be moving past, not preserving.

Commons should be focusing on structured and maintainable ways to showcase our media, ideally through automated or database-driven tools that actually reflect what's in Commons, not static pages that depend on manual upkeep. The project deserves better than a patchwork of abandoned "galleries" that neither scale nor represent the richness of our collection. --Jonatan Svensson Glad (talk) 00:42, 13 November 2025 (UTC)

Agree with all you said starting at Many of. The question would be what to do about it. I'd support most of them should just be deleted but think many are quite good and deleting them may not be needed or good if Wikipedia articles didn't link to them instead of the categories. Not sure what you mean at develop proper MediaWiki functionality for curating and displaying high-quality galleries – what do you think is missing? And also there already is such functionality or not – listeria which is used in the galleries this thread is about. Prototyperspective (talk) 00:54, 13 November 2025 (UTC)

•  Support for any such uploads from museums or of artists who can be considered notable in the least restrictive logical meaning of the word. Any problems with categorization or gallery organization are secondary to the obvious benefit of having the images. -- Ikan Kekek (talk) 23:11, 16 November 2025 (UTC)

Update file description page table

I propose giving the file description page table a much needed fresher look! See the example below of File:Official CSS Logo.svg. See the sandbox at Template:Information/sandbox and styles Template:Information/sandbox/styles.css.

Demo [Click to open]

Example taken from File:Official CSS Logo.svg at Template:Information/sandbox/testcases.

DescriptionOfficial CSS Logo.svg	English: The primary rebeccapurple logo of the CSS specification.
Date	12 November 2024
Source	https://github.com/CSS-Next/logo.css/blob/main/css.svg
Author	Javi Aguilar and The CSS-Next Community Group
Repository InfoField	https://github.com/CSS-Next/logo.css/
Nominal resolutions InfoField	Primary (1000px x 1000px) and small (32px x 32px)
File types InfoField	.avif, .ico, .png, .svg, .webp
Permission ( Commons:Reusing content outside Wikimedia">Reusing this file)

Waddie96 (talk) 22:32, 19 October 2025 (UTC)

We already have {{Information field}} when parameters beyond the usual set are needed. The vast majority of files do not need additional fields (and quite frankly, neither does this file). Pi.1415926535 (talk) 02:01, 20 October 2025 (UTC)

@Pi.1415926535 Hi it's got nothing to do with additional parameters, it's got to do with styling it and refreshing it's look a much needed fresher look. Read again 😄 Waddie96 (talk) 03:41, 20 October 2025 (UTC)

Just FYI the info box is malformed when viewed in a mobile browser on a smartphone in portrait orientation. It looks fine in landscape orientation. I'm also wondering how it would be affected if the text is in another language and has a significantly different length than English. Nakonana (talk) 16:38, 2 November 2025 (UTC)

•  Oppose The existing style works perfectly fine, the new one is less accessible, and any possibility that this change would break any of the myriad of components held together with duct tape and prayers that make up the back end of this site far outweighs aesthetic concerns. The Squirrel Conspiracy (talk) 00:29, 29 October 2025 (UTC)

 Oppose Restyling currently not needed and this isn't much better even if the border was added and the license info moved out of the box again (2 issues with this). Prototyperspective (talk) 09:16, 29 October 2025 (UTC)

Proposal: Add AI-powered visual search for Wikimedia Commons

Hello everyone,

I would like to propose adding an (AI-powered visual search) feature to Wikimedia Commons. Currently, Commons search only works through text-based queries (titles, categories, or structured data). However, many users may have an image but not the exact keywords to describe it.

This new feature would allow users to upload or paste an image, and the system would use AI-based image recognition (such as similarity search or image embeddings) to find visually related files within Commons.

Benefits:

• Improves discoverability of media content.
• Helps editors find similar or duplicate files.
• Useful for GLAM, educational, and research purposes.
• Enhances structured data tagging and metadata accuracy.

A Phabricator task has been created for technical discussion and tracking: 👉 T408018 – Add AI-powered visual search for Wikimedia Commons images

Community feedback is welcome — please share your thoughts and suggestions below. If there’s consensus, the idea can be supported more strongly on Phabricator to attract developer attention.

Thank you! —GoldenJDM (talk) 19:53, 22 October 2025 (UTC)

AI tends to be very computationally expensive. Why would there be any advantage to doing this specifically within Commons to using existing free external tools? - Jmabel ! talk 03:03, 23 October 2025 (UTC)

I don't see the benefit for such software. The lead in AI-based searching that Google and OpenAI already have is most likely uncatchable, there's a gadget in your preferences that you can activate for image-based searches, or what should be the en:killer feature for such a search function here? Regards, Grand-Duc (talk) 03:12, 23 October 2025 (UTC)

I don't think this is needed much or would have a big impact or usefulness. Additionally, it doesn't seem readily possible now or in the near future but would take a lot of resources and effort to implement. Furthermore, there already is Google Images reverse search and Tineye as well as Commons category and Commons search, making this is more or less redundant. There also is a wish in the Community Wishlist about what you're describing: W212: Search Wikipedia with image or sketch search.

More useful would be a way to describe what one is looking for to some AI assistant which then tells you categories and/or a few files that match your description. This is one potential application of the many applications of wish W442: Adopt Wikipedia-trained WikiChat LLM & make it learn about help pages & categories to help newcomers also in the Community Wishlist. When it comes to duplicate files, there already is a check for similar files in the UploadWizard for example and it's not a plausible way what you're suggesting could be used efficiently.

To put things short, I don't think your idea is worth the effort but thanks for thinking about how Commons could be made better via technical development. Prototyperspective (talk) 15:15, 23 October 2025 (UTC)

The last time we tried this it was a huge loss of money, developer and volunteer time: See Commons:Structured data/Computer-aided tagging. GPSLeo (talk) 15:35, 23 October 2025 (UTC)

That this implementation was seriously flawed / low-quality doesn't mean the concept can't work well. However, this is about something entirely different than what's proposed here. Prototyperspective (talk) 15:47, 23 October 2025 (UTC)

In principle, some sort of image similarity or content recognition search would be great to have. But the ultimate deciding factor is going to be technological feasibility - the set of images on Commons is exceptionally large (currently 129M), and a lot of the typical tools for this sort of task will be unsuitable at that scale. (CLIP is probably not what you want; it's geared towards identifying broad classes of objects like "this image may contain a person", which are too broad to be useful on Commons.)

@GoldenJDM - this is probably a better fit for the meta:Community Wishlist than Phab, as it's not immediately actionable and requires planning. Omphalographer (talk) 01:26, 25 October 2025 (UTC)

 Support. As a note here, when making these types of proposals I think it is important to distinguish between Generative AI (GenAI) and other types of AI (or other concepts like CBIR, which is what is used to reverse image search and doesn't necessarily involve machine learning).

I am personally building a MediaWiki gadget tool that will allow users to reverse image search from a filename or URL using multiple engines like Google Lens, Google Classic, Bing, Yandex and TinEye (there is already a similar gadget that does this: GoogleImagesTineye).

I agree however that an engine to search within Commons would be pretty neat. There are multiple open source engines listed on List of CBIR engines that we could possibly look into. See also: Reverse image search.

I do agree this is better suited for the Community Wishlist. @GoldenJDM I can help you drafting a wish if needed. It's moon (talk) 00:16, 29 October 2025 (UTC)

It would likely be declined as a duplicate of the wish I linked above.
If you think this is important, the right place to file a Support vote would be that wish page. As a technical proposal, it's probably not most relevant on this page (instead of VP/T and the Wishlist).
The best place to add info on how it could be implemented would be the talk page of that wish, albeit currently too few people go through Commons-related wishes and their talk pages. If you're currently working on that, the wish could maybe be set to "In progress". Prototyperspective (talk) 09:30, 29 October 2025 (UTC)

That wish is about implementing a Sketch Search, where you draw something, and it gives results of images with the object or concept you drew. While it's similar and could be related, it's not exactly the same as a CBIR engine, where the input is an image sample and it gives links to where the same image can be found. You would typically not use a Sketch Search to search for duplicates. That doesn't mean both wishes could be put into the same focus area later on though. It's moon (talk) 19:28, 29 October 2025 (UTC)

No, the wish is about two things: image search and sketch search. Admittedly, the former part is not well-written and so far extensive edits of wishes aren't done by anybody else other than the wish's initial creator so it may possibly be best to submit a new wish and then let it be declined as duplicate and then merge the wish text into the existing wish.

I meant to point out here the issue that GoldenJDM is talking about searching for images that are loosely similar while TinEye only shows exact duplicates as well as variants that are very similar (such as the same image with extra text on top). However, Google Image search / Lens also show similar images. Now you're saying this would be just about finding duplicate images. I don't think there is much of a need for a duplicate image finder on Commons where the functionality is limited to that (e.g. given that the UploadWizard already does that) and it's not what GoldenJDM wrote about at around visually related files within Commons. Prototyperspective (talk) 00:15, 30 October 2025 (UTC)

What I was trying to say is that Sketch Search tools aren't as accurate and don't usually work like CBIR tools, but I didn't mean to say the tool would be used exclusively for duplicates (sorry, I didn't write that part properly -but I do agree it could also be used for related files-).

Also, when talking about duplicates, the idea would be to find the same image uploaded with a different resolution or compression. I believe UploadWizard only finds exact duplicates (correct me if I'm wrong).

Writting a new wish so that it gets closed and merged with the already existing one sounds like a solid plan. It's moon (talk) 10:26, 30 October 2025 (UTC)

Thanks for explaining. I believe UploadWizard only finds exact duplicates (correct me if I'm wrong). I think it also finds further duplicates but I don't know to what degree and this thread will likely clarify it: Commons talk:WMF support for Commons/Upload Wizard Improvements#Duplicate detection. Prototyperspective (talk) 12:20, 30 October 2025 (UTC)

Maybe an AI tool, not run by Wikipedia, would be the more responsible use of our very limited resources. For the increasingly dependent folk who cant do without. Alexpl (talk) 13:47, 29 October 2025 (UTC)

Stricter blocking policy for copyright violations

We still have a huge problem with blatant copyright violations where people upload some photo they found on the internet as their own work. Currently these users are warned multiple times and get blocked for two weeks. After the block they continue with uploading copyright violations. I think we should be more strict and only give one warning. If there are blatant copyright violations after the first warning they should be partially blocked infinitely from uploading files. They should be able to appeal immediately if they explain that they now understand the rules. This process is only valid for blatant copyright violations like wrong own work claims, "source: internet" or source links to obviously non free content. This should not apply to content where the uploaded assumed it would be public domain (also if it is not) or derivative work and FOP problems. GPSLeo (talk) 12:36, 26 October 2025 (UTC)

simply  Strong oppose. modern_primat ^{ඞඞඞ ----TALK} 19:43, 26 October 2025 (UTC)

then put more admins here to cope with workship. modern_primat ^{ඞඞඞ ----TALK} 19:44, 26 October 2025 (UTC)

+ if people get banned then sock puppetery will thrive. current system of blocking for copyvio is good. modern_primat ^{ඞඞඞ ----TALK} 17:45, 27 October 2025 (UTC)

I think the people who upload copyright violations in that way are not the same people who create sockpuppets to continue with their project disruption. The users who are to be blocked from uploading with this rule do not know what Wikimedia is. GPSLeo (talk) 19:16, 27 October 2025 (UTC)

we'll see. hayırlısı olsun. modern_primat ^{ඞඞඞ ----TALK} 05:43, 28 October 2025 (UTC)

•  Strong support, thanks to GPSLeo for pointing this out.--Kadı Message 23:22, 26 October 2025 (UTC)

 Support, having reported overlooked mass copyvios in the past where the uploader turns out to have a talk page of warnings and earlier short blocks that they've waited out, not noticed, or not understood.

The time likely needed for the user to familiarize themselves with relevant policies and adjust their behaviour of an initial week-long block makes sense in nuanced situations where a user might be applying a policy wrongly or interacting inappropriately, while being an otherwise productive Commons user, but it doesn't seem applicable to someone who is claiming "own work" or "public domain" on clearly copyrighted content, and making no constructive contributions. Belbury (talk) 10:09, 27 October 2025 (UTC)

 Support - in my opinion, copyright violations are, at large, one of the most prominent dangers (if not outright number 1) to the integrity of the project. Strong signals like blocks (and knowing + applying en:WP:UBCHEAP for people appealing them) are sensible tools to deal with such uploads. Regards, Grand-Duc (talk) 21:15, 27 October 2025 (UTC)

•  Strong support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:06, 28 October 2025 (UTC)

 Comment Is it possible to partially block a user to prevent them from uploading new files, while still allowing them to edit file descriptions? If so, that seems like it could be a really useful tool to get users to fix licensing information on their uploads before letting them upload more files. Omphalographer (talk) 22:15, 28 October 2025 (UTC)

This is exactly what I propose: Only block them from uploading. This is possible, they still can edit in the file namespace but they can not upload new files. GPSLeo (talk) 22:54, 28 October 2025 (UTC)

is there a reason why this isnt the norm already Trade (talk) 01:29, 3 November 2025 (UTC)

• I started out wanting to weak oppose this, since my own start to this community was uploading copyvios. But when I got a "stop or you'll be blocked"-type message, I actually started to respond on my talk page in order to get a better understanding. When I began writing to oppose a stricter blocking policy, it was because I wouldn’t want to block the next me.

I think every copyvio warning should automatically count as a clear "stop" notice – something unambiguous that the user can't miss amongst all the other boxes that must have already been left from previous deletion warnings (since that is why they are now getting a "stop" warning). But after writing this, I realized that what I was going to propose is almost the same as what's already being proposed here, so  Support.

However, I'd also like to propose a wider overhaul of how we notify users about copyright violations. Compare it to how vandalism warnings work on enwiki: short, conversational messages that invite the user to reply and ask questions, rather than long templates stacked with dense policy text. It's important information, and everything is super-important to know, follow, repeat in their sleep...(/joking aside...) The current system, with multiple boxes repeating similar warnings, doesn't really encourage dialogue or learning. A simplified, human approach could help new users understand why their upload was a problem and how to do better, rather than just overwhelming them with boxes upon boxes, a "stop" box in the middle followed by more boxes. --Jonatan Svensson Glad (talk) 23:07, 28 October 2025 (UTC)

• Supporting it in principle or in spirit but only for actually severe cases like people only or nearly only uploading copyright violations and continuing with it after the block expired. However, I think this can easily backfire and be misinterpreted if not codified well such as blocking users who actually uploaded a copyright violation once in a while and got warned and then accidentally did it again, e.g. because they forgot months later or didn't notice. So I think the phrasing should be well thought through, quite specific and well-written where "for blatant copyright violations like wrong own work claims, "source: internet" or source links to obviously non free content" is not yet sufficient.

Prototyperspective (talk) 09:22, 29 October 2025 (UTC)

If the sources to non free content are so obvious then why cant a filter pick them up Trade (talk) 01:27, 3 November 2025 (UTC)

 Support, the partial block should be such that compels the user to respond to the talk page notice. Maybe we should broaden the partial block scope and include File space as a whole. Bcoz if it is a vandal, the second stop (after not being able to upload) will always be files. I agree with @GPSLeo that continued upload of blatant copyvios after first warning should attract a partial indefinite and not temporary block. I also like @Josve05a's proposals regarding TP notices. Thank you. Shaan Sengupta^Talk 07:39, 3 November 2025 (UTC)

• I think any form of intentional dishonesty (e.g. editing an image to hide its source) should be an indefinite ban. Traumnovelle (talk) 06:02, 7 November 2025 (UTC)
  • Agreed. But I'm much more skeptical of the value of blocking a new user over what may be an honest mistake or two. - Jmabel ! talk 23:48, 7 November 2025 (UTC)

  What do you mean with editing an image to hide it's source? Trade (talk) 20:56, 9 November 2025 (UTC)

  A typical example would be taking a stock photo, deliberately editing out a watermark, and claiming it as own work. Omphalographer (talk) 21:54, 9 November 2025 (UTC)

  So if someone did the exact same thing but didn't bother to remove the watermark that would not count as intentional dishonesty in your opinion? Trade (talk) 23:35, 9 November 2025 (UTC)

• What if the user name / user page / contribution history contains what looks like a copyright holder's name, even if the file is available on the internet? Would sysops be responsible for checking those indications before immediately indef-blocking? Shoult it be "blocked until proven legitimate"? I think this "blatant" can be hard to define. A "Disney rep" uploading a recent Disney character might be hard to believe, while a lesser known company might be more willing to do a CC release for visibility. whym (talk) 06:22, 9 November 2025 (UTC)
• Rather  Oppose. I think this addresses an issue the wrong way. The problem is not supposedly lenient admins who let people upload copyright violations. The issue is the lack of people checking real serious copyright violations. Quite of number of people spend a lot of time looking for potential copyright violations in borderline cases, including URAA. But very few people take care of the serious cases (files copied from social media and random websites). In consequence, these copyright violations are not checked, and the violators can continue uploading them. If the priority is changed to serious violations, violators would be warned early, and blocked soon after. Yann (talk) 21:14, 9 November 2025 (UTC)

  The two issues are connected, though. If we're giving social media copyright violators four chances instead of one, the few users who are patrolling for that kind of copyright violation will have to find and verify and report them four times. That spreads their efforts even more thinly.

  There's also (as I understand it) no mechanism for anyone to be alerted that a user who's come out of a temporary block for blatant copyvios has started uploading files again, so it is just going to be luck whether anyone notices a copyvio-only account resuming activity, each time. Belbury (talk) 12:34, 20 November 2025 (UTC)

  For information, my practice is the following: less than 5 copyright violations -> simple warning, more than 5 copyright violations -> last warning. Then one-week block if still uploading after the last warning, and 3-months block if still uploading after one-week block. But I often discover users with 20+ copyright violations and no warning. So what do you suggest in such cases? Yann (talk) 16:26, 20 November 2025 (UTC)

  Oh, that's a point, I wasn't counting warnings among the "chances" above. So as things are, we're often giving blatant copyvio uploaders five or six opportunities to upload problematic content, including before the first and final warnings, and I think we should (as I think GPSLeo is suggesting) only ever give them two: one warning (at whatever level), then an indef block if they continue to upload copyvios. Belbury (talk) 16:49, 20 November 2025 (UTC)

  Is anyone stopping you from only giving one warning Trade (talk) 05:58, 21 November 2025 (UTC)

  I'll sometimes start with a final warning if the user has multiple batches of copyvio deletion notices on their talk page, at least weeks apart, but no first warning. Belbury (talk) 10:18, 21 November 2025 (UTC)

•  Weak oppose. I support a block after one warning, but I don't think the first block should be indefinite unless the uploader seems to be a vandal or spambot. On Wikivoyage, we normally use a system of escalating blocks, starting with 3 days, then 2 weeks, then 3 months, and then indefinite. However, I feel like admins are really overworked on Commons and struggling to catch up to problems, so I think the first block being a week and the second block being indefinite would be fine. -- Ikan Kekek (talk) 23:18, 16 November 2025 (UTC)

COM:PHOTOCONSENT and VRT

When releasing the rights of photographs via VRT (COM:CONSENT) I believe there should be a way for photographers to confirm they have consent from people depicted in the photography as well (COM:PHOTOCONSENT). Then VRT members should be able to place {{Consent}} on the picture itself and there should also be {{consent|pending}} (which would be used by uploaders, in a similar way to {{Permission pending}}). It's moon (talk) 06:25, 28 October 2025 (UTC)

How should we geocode moving shots?

This is a continuation of a discussion started at Commons talk:Geocoding, about how to geocode videos where the camera and/or subject moves during recording. Such media has a dimension of time and therefore there's more than one location associated. Some ways could be to tag the location of recording start, or make the geocode imprecise enough to cover the entire recording area?

And regardless of which option if any we choose, perhaps we should also tag all such instances to make them machine-detectable and in case of future expansion of geocoding capabilities. I've made a suggestion for how that could look at {{Location variable/sandbox}}.

So my questions are: 1) What should be standard practice for geocoding media with multiple locations? 2) Should we tag such cases in any way? Rose Abrams (talk) 13:50, 28 October 2025 (UTC)

I think the simple location parameter for the template and structured data should be the staring location. The full track could be stored as geojson or tabular data. I think both data formats are suitable but we have to decide which one we use. I think storing as table would be better as tables have less overhead for this very simple list of points we want to store. GPSLeo (talk) 15:36, 28 October 2025 (UTC)

It probably needs at least a gadget and rather some change to the default Commons code to enable specifying the coordinates for varying locations. However, probably not many would do this, e.g. because they don't have the coordinates. Having a template may be good enough for now. I support having the proposed template.

Another approach that may be complementary would be to set the categories and then specify the timings that the category is about via some new qualifiers for categories feature that works similar to the sortkey (e.g. Category:Eiffel tower/0:25-1:01) as proposed here: Commons:Village pump/Proposals/Archive/2024/09#Qualifiers for categories (which parts of videos). For example, when a video shows multiple places of a city like various sightseeing spots, one could set them with qualifiers. Same for a video from a train driving through multiple train stations etc etc. These categories are linked to a Wikidata item with coordinates and one could identify categories as being 'location-categories' for example also via the Wikidata items. Prototyperspective (talk) 20:56, 1 November 2025 (UTC)

Equivalent file extensions

There are multiple file extensions that are currently allowed on Commons that are redundant: .jpg can be used interchangeably with .jpeg (you can simply rename the file extension, they are both exactly the same thing). The same goes for .tif / .tiff, .mpg / .mpeg (and .mid / .midi). I think to prevent duplicates and improve consistency, only one variant (probably the shortest one) should be enabled, and uploaders should be asked to rename files to the preferred extension (or alternatively, Commons should update the file extension automatically if that is possible to configure). It's moon (talk) 23:13, 28 October 2025 (UTC)

 Support Commons should update the file extension automatically if that is possible to configure and the shorter more common file extensions should be used like jpg. But oppose asking uploaders to rename some files mainly because this can be problematic when many files are uploaded at once. Prototyperspective (talk) 09:18, 29 October 2025 (UTC)

 Support --Trade (talk) 18:59, 4 November 2025 (UTC)

webp to png converter

There are several online, how about having out own. At one time we were discouraging webp files, how about our own internal converter? RAN (talk) 17:04, 31 October 2025 (UTC)

We already have a converter, you can just request a thumbnail of the same size as the original file and you will get a file converted to png. GPSLeo (talk) 17:45, 31 October 2025 (UTC)

We really ought to get an mp4 to webm converter before any other file types Trade (talk) 18:59, 4 November 2025 (UTC)

Maybe that would be better filed at Commons talk:WMF support for Commons/Upload Wizard Improvements. Prototyperspective (talk) 20:44, 1 November 2025 (UTC)

Adding locations to institutions by default, instead of believing in "global brands"

I made my argument at Institution talk:National Gallery of Art, Washington DC, c+p here:

The name "National Gallery of Art" is generic and doesn't say much. I am oftentimes lucky to know immediately, which of all the museums in the world is meant here; but every other museum is the one that houses the national treasures of art, and its native name can be translated to "National Gallery of Art" (or "Metropolitan Museum" for that matter; only the shorthand logogram MET makes it unique). It appears more like hybris to think of the one in Washington as being unique and globally unambiguous, it is not. (Another prominent example would be National Gallery)

I would suggest, that institutions with generic names like that have to be specified by default by its location, city or nation, as it seems to be already, but it is not displayed as such in the templates for the objects. It can't be that hard to do, since a click clarifies already, but it is an unnecessary click to far already; WP is not guesswork. It is like omitting "cm" using the globally used metric system, because, Americans, you should know... It is not much more than to believe the marketing and the impact of allegedly global brands; its just advertisement, not reality. MenkinAlRire (talk) 06:27, 21 November 2025 (UTC)

Even the Louvre or the Hermitage have this problem of the inherent expectation, that everyone knows. Like WP becoming more and more academic, a sort of gentrification, the implicitness of meaning is not understood without the knowledge the WP should not expect as given, but to provide it, so that everyone can learn about it, instead of being (or have the feeling of) being excluded by the know-it-all. MenkinAlRire (talk) 07:10, 21 November 2025 (UTC)

@MenkinAlRire: I'm not sure exactly which use(s) of the unqualified names you are complaining about, but my guess is that you are looking at the text atop the Wikidata Infobox, drawn from Wikidata, which has the policy of not using qualifiers in the names. Thus , Category:Freeport, Maine, Category:Freeport, Texas. You really have to also look at the description in the line under than to make sense of it; that is how Wikidata disambiguates.

If you meant something else, could you be more specific? - Jmabel ! talk 19:53, 21 November 2025 (UTC)

Hi, @Jmabel, thx for the reply.If you look for example here: File:Madonna_of_Auvilliers_Louvre_RF1352.jpg

There is no mention at all, where the Louvre and with it the object is located, except it is said in the description (as I always do), or you know already, that the Louvre is in Paris, and not in Abu Dhabi (wink, wink, there is a namesake...).

I find it unnescessarily feeble not to mention the city of the museum (immediately, not via another click, and here, in this case, hovering over the link doesn't clarify either).

To take an example from the NGA: File:Giovanni Bellini, Portrait of a Venetian Gentleman, c. 1500, NGA 395.jpg. If you don't know about the Samuel H. Kress Collection, and you never saw a picture of the museum before (like me), even with the photograph, there is no mention of its location, it could be the Louvre off-shoot as municipal museum of Abu Dhabi (what do I know?).

(A lesser compelling example, take this Category:Tetramorph with Symbols of the Evangelists, Pilaster from the Parapet of a Pulpit, MET 21.101. Absolutely nowhere the city is mentioned. It is not exactly what I initially meant. But if you try to find out and look for a promising link, since there is no WP link, you go to Category:Medieval Italian architectural sculptures in the Metropolitan Museum of Art. Maybe you already catch my drift: it needs three! more cat levels to get to "Italian sculptures in the United States", now you get to know for the first time in this constellation, that the MET is in the USA, that's something, but east coast, west coast...? etc)

I know, the argument could be, WMC is the machine room, wikidata the administration or whatever, but that's not the case. I get more and involved with WMC and even wikidata, the longer I edit in WP and upload photographs. If you want to have the WP as a an totally open structure with more or less equal rights and insides, depth of reach(?), and not a split between the ones who control the matrix and the users, who think they have control.

I really don't know, if this isn't just my thinking and my problem. I would hope and expect at least, otherwise. MenkinAlRire (talk) 22:02, 21 November 2025 (UTC)

Maybe some of the misunderstanding came from knowing what I learned just now, that clicking the link opens a sub-window, where it says loud and clear: Washington DC (That's nice!). But this is not always the case (not even often, I suspect). And if a new tab or window has to be opened (band-width!) it is already too much. But it would certainly be not too much, to add to every institution the city (and nation) it is located in. For that you didn't have to alter just some lines of programming. MenkinAlRire (talk) 22:12, 21 November 2025 (UTC)

@MenkinAlRire: If you hover the mouse over "Louvres Museum", do you not see "art and archaeology museum in Paris, France"? - Jmabel ! talk 00:41, 22 November 2025 (UTC)

@Jmabel, thanks again. Yes, you are right, and it does the same with the MET, NGA, and even the Wallraf Richartz Museum gives away its location in the link. OK, it might be that in the case of File:Madonna_of_Auvilliers_Louvre_RF1352.jpg metioned above, I hovered over "inventory", where the link isn't the same as over "Louvre".

You probably want to suggest, that its like that with every institution. Then I would rest my case (for now,-/), and I have to thank you for your patience. MenkinAlRire (talk) 14:27, 22 November 2025 (UTC)